サードパーティアプライアンスのための内部 TCP / UDP 負荷分散の設定

Google Cloud では、高可用性のスケールアウト方式でサードパーティアプライアンスを統合できます。これを行うには、カスタム静的ルートを構成し、ネクストホップを Google Cloud の内部 TCP / UDP ロードバランサに設定します。これにより、ロードバランサは、ヘルスチェックされたサードパーティ VM アプライアンスのプールに宛先プレフィックスのトラフィックを負荷分散できます。

このガイドでは、サンプルを示しながら、内部 TCP / UDP ロードバランサをネクストホップとして構成する方法を説明します。このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトの所有者または編集者であるか、または次の Compute Engine IAM ロールをすべて持っている必要があります。

タスク	必要なロール
ネットワーク、サブネット、負荷分散コンポーネントの作成	ネットワーク管理者
ファイアウォールルールの追加と削除	セキュリティ管理者
インスタンスの作成	Compute インスタンス管理者

詳細については、次のガイドをご覧ください。

共通のバックエンドで内部 TCP / UDP ロードバランサをネクストホップとして設定する

このガイドでは、拡張静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用して、スケールアウトされた仮想アプライアンスを統合する方法について説明します。

このガイドで説明するソリューションでは、Debian Linux と iptables を実行するアプライアンス VM を作成します。サンプルの VM では、パケットフィルタリングは行いませんが、その機能は、この例の iptables 構成を変更するか、別のパケットフィルタリングまたはルーティングソフトウェアを使用することで追加できます。

このセクションでは、次のリソースの構成方法について説明します。

サンプルの VPC ネットワークとカスタムサブネット
バックエンドのアプライアンス仮想マシン（VM）への受信接続を許可する Google Cloud ファイアウォールルール
カスタム静的ルート
接続をテストするための 2 つのクライアント VM
次の内部 TCP / UDP ロードバランサコンポーネント:
- マネージドインスタンスグループ（MIG）内のバックエンド VM
- バックエンド VM に対するヘルスチェック
- バックエンド VM 間の接続分散を管理する us-west1 リージョン内の内部バックエンドサービス
- ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

この例では、複数の NIC への負荷分散で説明されているように、複数のバックエンド NIC への負荷分散を示します。

トポロジの概要は次のとおりです。

内部 TCP / UDP ロードバランシング用のネクストホップマルチ NIC の詳細例（クリックして拡大）

この例で作成するリソースは次のとおりです。

内部 TCP / UDP ロードバランサ（この例では fr-ilb1）の背後にあるアプリケーションインスタンス（この例では iptables を実行している VM）。アプリケーションインスタンスには内部 IP アドレスのみが設定されています。
各アプリケーションインスタンスで can-ip-forward フラグが有効になっています。このフラグを設定しないと、Compute Engine VM がパケットを送信できるのが、パケットの送信元 IP アドレスが VM の内部 IP アドレス、エイリアス IP 範囲の IP アドレス、または VM に解決される転送ルールの IP アドレスと一致する場合に限定されます。can-ip-forward フラグを使用すると、VM はどのような送信元 IP アドレスのパケットも送信できるようになります。
宛先 10.50.1.0/24 とネクストホップがロードバランサの転送ルール fr-ilb1 に設定されたカスタム静的ルート。

トラフィックフローは次の図のようになります。

testing VPC ネットワークには、宛先が 10.50.1.0/24 サブネットのカスタム静的ルートが設定されています。これにより、トラフィックがロードバランサに転送されます。
構成されたセッションアフィニティに基づいて、ロードバランサがいずれかのアプリケーションインスタンスにトラフィックを転送します（セッションアフィニティは TCP トラフィックにのみ適用されます）。

他のユースケースについては、ネクストホップとしての内部 TCP / UDP ロードバランサをご覧ください。

ネットワーク、リージョン、サブネットの構成

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

ネットワーク: この例では、少なくとも 2 つのネットワークが必要です。それぞれに 1 つ以上のサブネットが必要です。各バックエンドサードパーティアプライアンス VM には、VPC ネットワークごとに 1 つずつ、少なくとも 2 つのネットワークインターフェースが必要です。この例のネットワークでは、testing と production というカスタムモードの VPC ネットワークがあります。testing ネットワークには、クライアントとロードバランサがあります。production ネットワークには、宛先のターゲット VM があります。
リージョン: サブネットは us-west1 リージョンにあります。VM インスタンスはゾーンリソースであるため、サブネットは同じリージョン内に存在する必要があります。
サブネット: サブネット testing-subnet と production-subnet は、それぞれ 10.30.1.0/24 と 10.50.1.0/24 のプライマリ IP アドレス範囲を使用します。

ネットワークとサブネットを作成する手順は次のとおりです。

コンソール

testing ネットワークと testing-subnet を作成します。

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
[名前] に「testing」を入力します。
[サブネット] セクションで次の設定を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
  - 名前: testing-subnet
  - リージョン: us-west1
  - IP アドレス範囲: 10.30.1.0/24
  - [完了] をクリックします。
[作成] をクリックします。

production ネットワークと production-subnet を作成します。

Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。

[VPC ネットワーク] に移動
[VPC ネットワークを作成] をクリックします。
[名前] に「production」を入力します。
[サブネット] セクションで次の設定を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
  - 名前: production-subnet
  - リージョン: us-west1
  - IP アドレス範囲: 10.50.1.0/24
  - [完了] をクリックします。
[作成] をクリックします。

gcloud

カスタム VPC ネットワークを作成します。

gcloud compute networks create testing --subnet-mode=custom

gcloud compute networks create production --subnet-mode=custom

us-west1 リージョンの testing ネットワークと production ネットワークにサブネットを作成します。

gcloud compute networks subnets create testing-subnet \
    --network=testing \
    --range=10.30.1.0/24 \
    --region=us-west1

gcloud compute networks subnets create production-subnet \
    --network=production \
    --range=10.50.1.0/24 \
    --region=us-west1

ファイアウォールルールの構成

この例では、次のファイアウォールルールを使用します。

fw-allow-testing-from-both: testing ネットワークのすべてのターゲットに適用される上り（内向き）ルール。このルールは、10.30.1.0/24 と 10.50.1.0/24 両方の IP アドレス範囲にある送信元からのトラフィックを許可します。この 2 つの範囲には、両方のネットワークにある VM のプライマリ内部 IP アドレスが含まれます。
fw-allow-production-from-both: production ネットワークのすべてのターゲットに適用される上り（内向き）ルール。このルールは、10.30.1.0/24 と 10.50.1.0/24 両方の IP アドレス範囲にある送信元からのトラフィックを許可します。この 2 つの範囲には、両方のネットワークにある VM のプライマリ内部 IP アドレスが含まれます。
fw-allow-testing-ssh: testing VPC ネットワークの VM インスタンスに適用される上り（内向き）ルール。このルールは、任意のアドレスから受信する TCP ポート 22 への SSH 接続を許可します。このルールには、送信元 IP 範囲をより限定して指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ファイアウォールルールを適用する VM の識別に、ターゲットタグ allow-ssh を使用します。
fw-allow-production-ssh: production VPC ネットワークの VM インスタンスに適用される上り（内向き）ルール。このルールは、任意のアドレスから受信する TCP ポート 22 への SSH 接続を許可します。fw-allow-testing-ssh ルールのように、送信元の IP 範囲をより限定して指定できます。
fw-allow-health-check: 負荷分散されたサードパーティ製アプライアンス VM 用の上り（内向き）ルール。このルールにより、Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのトラフィックが許可されます。この例では、ターゲットタグ allow-health-check を使用して、適用するインスタンスを識別します。
fw-allow-production-health-check: 負荷分散されたサードパーティ製アプライアンス VM 用の上り（内向き）ルール。このルールにより、Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのトラフィックが許可されます。この例では、ターゲットタグ allow-health-check を使用して、適用するインスタンスを識別します。

これらのファイアウォールルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンドインスタンスへの受信トラフィックがブロックされます。Google Cloud プローブシステムの IP 範囲からのヘルスチェックを許可するには、ファイアウォールルールを作成する必要があります。詳細については、プローブの IP 範囲をご覧ください。

コンソール

Google Cloud コンソールで [ファイアウォール] ページに移動します。

[ファイアウォール] に移動
[ファイアウォールルールを作成] をクリックして次の情報を入力し、テスト VM がテスト用サブネットと本番環境サブネットからパケットを受信できるようにします。
- 名前: fw-allow-testing-from-both
- ネットワーク: testing
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: ネットワーク内のすべてのインスタンス
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 10.30.1.0/24、10.50.1.0/24
- プロトコルとポート: すべて許可
[作成] をクリックします。
[ファイアウォールルールを作成] をクリックして次の情報を入力し、本番環境 VM がテスト用サブネットと本番環境サブネットからパケットを受信できるようにします。
- 名前: fw-allow-production-from-both
- ネットワーク: production
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: ネットワーク内のすべてのインスタンス
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 10.30.1.0/24、10.50.1.0/24
- プロトコルとポート: すべて許可
[作成] をクリックします。
[ファイアウォールルールを作成] をクリックして、テスト環境で受信する SSH 接続を許可するルールを作成します。
- 名前: fw-allow-testing-ssh
- ネットワーク: testing
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート: 指定されたプロトコルとポートを選択して、「tcp:22」と入力します。
[作成] をクリックします。
[ファイアウォールルールを作成] をクリックして、本番環境で受信する SSH 接続を許可するルールを作成します。
- 名前: fw-allow-production-ssh
- ネットワーク: production
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 0.0.0.0/0
- プロトコルとポート: 指定されたプロトコルとポートを選択して、「tcp:22」と入力します。
[作成] をクリックします。
[ファイアウォールルールを作成] をクリックして、テスト環境で Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前: fw-allow-health-check
- ネットワーク: testing
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-health-check
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 130.211.0.0/22 と 35.191.0.0/16
- プロトコルとポート: tcp
[作成] をクリックします。
[ファイアウォールルールを作成] をクリックして、本番環境で Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前: fw-allow-production-health-check
- ネットワーク: production
- 優先度: 1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ: allow-health-check
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲: 130.211.0.0/22 と 35.191.0.0/16
- プロトコルとポート: tcp
[作成] をクリックします。

gcloud

テスト VM が、testing サブネットと production サブネットからパケットを受信できるように、fw-allow-testing-subnet ファイアウォールルールを作成します。

gcloud compute firewall-rules create fw-allow-testing-from-both \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

本番環境 VM が、testing サブネットと production サブネットからパケットを受信できるように、fw-allow-production-subnet ファイアウォールルールを作成します。

gcloud compute firewall-rules create fw-allow-production-from-both \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24,10.50.1.0/24 \
    --rules=all

ネットワークタグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-testing-ssh ファイアウォールルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。
```
gcloud compute firewall-rules create fw-allow-testing-ssh \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```

ネットワークタグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-production-ssh ファイアウォールルールを作成します。

gcloud compute firewall-rules create fw-allow-production-ssh \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

fw-allow-health-check ルールを作成して、testing ネットワークのサードパーティアプライアンス VM に対する Google Cloud ヘルスチェックを許可します。

gcloud compute firewall-rules create fw-allow-testing-health-check \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

fw-allow-production-health-check ファイアウォールルールを作成して、production ネットワークのサードパーティアプライアンス VM に対する Google Cloud ヘルスチェックを許可します。

gcloud compute firewall-rules create fw-allow-production-health-check \
    --network=production \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-health-check \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp

サードパーティ仮想アプライアンスの作成

ここでは、iptables ソフトウェアをサードパーティの仮想アプライアンスとして使用して、インスタンステンプレートとマネージドリージョンインスタンスグループを作成する手順を説明します。

コンソール

複数のネットワークインターフェースを含むインスタンステンプレートを作成する必要があるため、このステップでは gcloud を使用します。Cloud コンソールでは、複数のネットワークインターフェースを含むインスタンステンプレートを現在作成できません。

gcloud

config.sh というローカルファイルを作成し、次の内容を挿入します。

#!/bin/bash
# Enable IP forwarding:
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
md_net="$md_vm/network-interfaces"
nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
# Source based policy routing for nic1
echo "100 rt-nic1" >> /etc/iproute2/rt_tables
sudo ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
sleep 1
sudo ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
sudo ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
# Use a web server to pass the health check for this example.
# You should use a more complete test in production.
sudo apt-get update
sudo apt-get install apache2 -y
sudo a2ensite default-ssl
sudo a2enmod ssl
echo "Example web page to pass health check" | \
tee /var/www/html/index.html
sudo systemctl restart apache2

サードパーティ仮想アプライアンスのインスタンステンプレートを作成します。インスタンステンプレートに --can-ip-forward フラグを追加します。これにより、テンプレートから作成された VM インスタンスが testing ネットワークと production ネットワークの他のインスタンスからパケットを転送できるようになります。
```
gcloud compute instance-templates create third-party-template-multinic \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script="$(< config.sh)"
```
サードパーティ仮想アプライアンスのマネージドインスタンスグループを作成します。このコマンドは、us-west1 内でリージョンマネージドインスタンスグループを作成し、自動的にスケーリングします。
```
gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template-multinic \
    --size=3
```

負荷分散リソースの作成

この手順では、ヘルスチェックとバックエンドサービス、フロントエンドコンポーネントなどの内部 TCP / UDP ロードバランサコンポーネントを構成します。

ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP 200（OK）レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。
バックエンドサービス: この例のバックエンドサービスは TCP プロトコルを指定しますが、ロードバランサがルートのネクストホップの場合、Google Cloud はすべてのプロトコル（TCP、UDP、ICMP）のトラフィックを転送します。
転送ルール: TCP ポート 80 が指定されていても、ロードバランサがルートのネクストホップの場合、TCP ポートまたは UDP ポートのトラフィックがロードバランサのバックエンドに送信されます。
内部 IP アドレス: この例では、転送ルールに内部 IP アドレス 10.30.1.99 を指定します。

コンソール

1 つ目のロードバランサを作成する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
[TCP 負荷分散] で [構成を開始] をクリックします。
[インターネット接続または内部専用] で [VM 間のみ] を選択します。
[続行] をクリックします。
[名前] を ilb1 に設定します。
[バックエンドの構成] をクリックして、次の変更を行います。
1. リージョン: us-west1
2. ネットワーク: testing
3. [バックエンド] の [新しいアイテム] セクションで、third-party-instance-group インスタンスグループを選択し、[完了] をクリックします。
4. [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
  - 名前: hc-http-80
  - プロトコル: HTTP
  - ポート: 80
  - プロキシプロトコル: NONE
  - リクエストパス: /。Cloud コンソールを使用してロードバランサを作成すると、ヘルスチェックはグローバルになります。リージョンヘルスチェックを作成する場合は、gcloud または API を使用します。
5. [セッションアフィニティ] で [クライアント IP] を選択します。
6. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
1. 名前: fr-ilb1
2. サブネットワーク: testing-subnet
3. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
  - 名前: ip-ilb
  - 静的 IP アドレス: 選択を許可
  - カスタム IP アドレス: 10.30.1.99
4. ポート: [単一] を選択して、ポート番号に「80」を入力します。ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。
5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[確認と完了] をクリックします。設定を再度確認します。
[作成] をクリックします。

2 つ目のロードバランサを作成する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
[TCP 負荷分散] で [構成を開始] をクリックします。
[インターネット接続または内部専用] で [VM 間のみ] を選択します。
[続行] をクリックします。
[名前] を ilb2 に設定します。
[バックエンドの構成] をクリックして、次の変更を行います。
1. リージョン: us-west1
2. ネットワーク: production
3. [バックエンド] の [新しいアイテム] セクションで、third-party-instance-group インスタンスグループを選択し、[完了] をクリックします。
4. [ヘルスチェック] で、「hc-http-80」を選択します。
5. [セッションアフィニティ] で [クライアント IP] を選択します。
6. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
1. 名前: fr-ilb2
2. サブネットワーク: production-subnet
3. [内部 IP] で、[静的内部 IP アドレスを予約] を選択し、以下の情報を入力して [予約] をクリックします。
  - 名前: ip-ilb2
  - 静的 IP アドレス: 選択を許可
  - カスタム IP アドレス: 10.50.1.99
4. ポート: [単一] を選択して、ポート番号に「80」を入力します。ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。
5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[確認と完了] をクリックします。設定を再度確認します。
[作成] をクリックします。
production VPC ネットワークにロードバランサのリソースを構成します。

gcloud

新しい HTTP ヘルスチェックを作成して、ポート 80 で VM との TCP 接続をテストします。
```
gcloud compute health-checks create http hc-http-80 \
    --region=us-west1 \
    --port=80
```

us-west1 リージョンに、内部バックエンドサービスを 2 つ作成します。

gcloud compute backend-services create ilb1 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=testing \
    --session-affinity=CLIENT_IP

gcloud compute backend-services create ilb2 \
    --load-balancing-scheme=internal \
    --health-checks-region=us-west1 \
    --health-checks=hc-http-80 \
    --region=us-west1 \
    --network=production \
    --session-affinity=CLIENT_IP

サードパーティの仮想アプライアンスを含むインスタンスグループを、バックエンドとしてバックエンドサービスに追加します。

gcloud compute backend-services add-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

gcloud compute backend-services add-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

内部転送ルールを作成し、バックエンドサービスに接続してロードバランサの構成を完了します。なお、ロードバランサがルートのネクストホップとして使用される場合、ロードバランサのプロトコル（TCP）とポート（80）によって、バックエンドインスタンス（サードパーティの仮想アプライアンス）に転送されるポートとプロトコルが制限されることはありません。
```
gcloud compute forwarding-rules create fr-ilb1 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=testing \
    --subnet=testing-subnet \
    --region=us-west1 \
    --backend-service=ilb1 \
    --address=10.30.1.99
```
```
gcloud compute forwarding-rules create fr-ilb2 \
    --load-balancing-scheme=internal \
    --ports=80 \
    --network=production \
    --subnet=production-subnet \
    --region=us-west1 \
    --backend-service=ilb2 \
    --address=10.50.1.99
```

ロードバランサをネクストホップとして定義する静的ルートの作成

next-hop-ilb で示されるカスタム静的ルートを 2 つ作成します。

コンソール

最初のルートを作成する

Google Cloud コンソールで、[ルート] ページに移動します。

[ルート] に移動
[ルートを作成] をクリックします。
ルートの [名前] に「ilb-nhop-dest-10-50-1」と入力します。
testing ネットワークを選択します。
[宛先 IP の範囲] に「10.50.1.0/24」と入力します。
ルートの [ネクストホップ] で、[内部 TCP / UDP ロードバランサの転送ルールを指定する] を選択します。

ロードバランサの IP アドレスをネクストホップとして指定するには、gcloud CLI または API を使用します。
転送ルール名を指定します。転送ルール名に fr-ilb1 を選択します。
[作成] をクリックします。

第 2 のルートを作成する

[ルートを作成] をクリックします。
ルートの [名前] に「ilb-nhop-dest-10-30-1」と入力します。
testing ネットワークを選択します。
[宛先 IP の範囲] に「10.30.1.0/24」と入力します。
ルートの [ネクストホップ] で、[内部 TCP / UDP ロードバランサの転送ルールを指定する] を選択します。

ロードバランサの IP アドレスをネクストホップとして指定するには、gcloud CLI または API を使用します。
転送ルール名に fr-ilb2 を選択します。
[作成] をクリックします。

gcloud

ネクストホップに各ロードバランサの転送ルールを設定し、それに応じて各宛先範囲を設定した詳細ルートを作成します。

--next-hop-ilb フラグには、転送ルール名または IP アドレスを指定できます。IP アドレスを指定すると、カスタムルートをエクスポートしなくても、この IP アドレスをピア間で学習できます。この例では、最初のルートが IP アドレス 10.30.1.99 を使用し、2 番目のルートが転送ルール名 fr-ilb12 を使用します。

必要に応じて、1 つ以上のルート上のインスタンスタグを指定できます。ルートにネットワークタグを指定すると、特定の VM にルートを適用できます。ネットワークタグを指定しない場合、VPC ネットワーク内のすべての VM にルートが適用されます。この例では、ルートのネットワークタグとして my-network-tag を使用します。

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --tags=my-network-tag

gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

`testing` VM インスタンスの作成

この例では、IP アドレスが 10.30.1.100 の VM インスタンスを testing VPC ネットワークの testing-subnet（10.30.1.0/24）に作成します。

gcloud

次のコマンドを実行して testing-vm を作成します。

gcloud compute instances create testing-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

`production` VM インスタンスの作成

この例では、IP アドレスが 10.50.1.100 の VM インスタンスを production VPC ネットワークの production-subnet（10.50.1.0/24）に作成します。

gcloud

production-vm はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、production-vm は us-west1-a ゾーンにあります。

次のコマンドを実行して production-vm を作成します。

gcloud compute instances create production-vm \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2'

マルチ NIC デプロイに対する負荷分散のテスト

ロードバランサのバックエンドの正常性を確認します。

gcloud compute backend-services get-health ilb1 --region us-west1

gcloud compute backend-services get-health ilb2 --region us-west1

testing VM からの接続をテストします。

gcloud compute ssh testing-vm --zone=us-west1-a

curl http://10.50.1.100

exit

production VM からの接続をテストします。

gcloud compute ssh production-vm --zone=us-west1-a

curl http://10.30.1.100

対称ハッシュの有効化

バックエンドインスタンスにマッピングされたハッシュを計算する場合、Google Cloud では IP アドレスとポートの方向が無視されます。TCP / UDP パケットの算出された一貫性のあるハッシュ値は、パケットの発信方向に関係なく同じになります。これは、対称ハッシュと呼ばれます。

既存の内部 TCP / UDP ロードバランサでこのハッシュ動作を有効にするには、転送ルールとネクストホップルートを再作成する必要があります。

詳細については、対称ハッシュをご覧ください。

転送ルールを削除して再作成する

コンソール

転送ルールを削除して新しいルールを作成する

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
be-ilb ロードバランサをクリックして、[編集] をクリックします。
[フロントエンドの構成] をクリックします。
ポインタを転送ルールの上に置き、 [削除] をクリックして削除します。
[フロントエンド IP とポートの追加] をクリックします。
[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
1. 名前: FORWARDING_RULE_NAME
2. サブネットワーク: SUBNET_NAME
3. [内部 IP] で [IP_ADDRESS] を選択します。
4. ポート: PORT_NUMBER または ALL
5. [完了] をクリックします。
6. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
[確認と完了] をクリックします。設定を再度確認します。
[作成] をクリックします。

gcloud

既存の転送ルールを削除します。

gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
    --region=REGION

同じ名前で代わりの転送ルールを作成します。

gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --load-balancing-scheme=internal \
    --ports=PORT_NUMBER or `ALL` \
    --network=NETWORK_NAME \
    --subnet=SUBNET_NAME \
    --region=REGION \
    --backend-service=BACKEND_SERVICE_NAME \
    --address=IP_ADDRESS

SNAT が不要な場合

前の例で示したように、次のすべてに当てはまる場合、ソースネットワークアドレス変換（SNAT）は必要ありません。

内部 TCP / UDP ロードバランサの転送ルールは、2021 年 6 月 22 日以降に作成された。
転送ルールを参照するカスタム静的ルートは、2021 年 6 月 22 日以降に作成された。
内部 TCP / UDP ロードバランサのバックエンドサービスは、NONE のセッションアフィニティ設定を使用しない。

既存のネクストホップの内部 TCP / UDP ロードバランサルートは、次の手順に沿って操作することで、対称ハッシュを使用するように変換できます。

内部 TCP / UDP ロードバランサのバックエンドサービスが、NONE のセッションアフィニティ設定を使用しないようにします。
同じバックエンドサービスを参照する、代わりの転送ルールを作成します。代わりの転送ルールでは、別の IP アドレスを使用します。
新しい転送ルールを参照する代わりのカスタム静的ルートを作成します。この代わりのルートには、既存のルートよりも高い優先度を設定します。
（以前の転送ルールを参照する）優先度の低い既存のルートを削除してから、以前の転送ルールを削除します。

クリーンアップ

ロードバランサの構成で、バックエンドサービスからバックエンドを削除します。

gcloud compute backend-services remove-backend ilb1 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

gcloud compute backend-services remove-backend ilb2 \
    --instance-group=third-party-instance-group \
    --instance-group-region=us-west1 \
    --region=us-west1

ルーティング経路を削除します。

gcloud compute routes delete ilb-nhop-dest-10-50-1

gcloud compute routes delete ilb-nhop-dest-10-30-1

ロードバランサの構成で、転送ルールを削除します。

gcloud compute forwarding-rules delete fr-ilb1 \
    --region=us-west1

gcloud compute forwarding-rules delete fr-ilb2 \
    --region=us-west1

ロードバランサの構成で、バックエンドサービスを削除します。

gcloud compute backend-services delete ilb1 \
    --region=us-west1

gcloud compute backend-services delete ilb2 \
    --region=us-west1

ロードバランサの構成で、ヘルスチェックを削除します。
```
gcloud compute health-checks delete hc-http-80 \
    --region=us-west1
```
Cloud コンソールを使用した場合、ヘルスチェックはグローバルになります。そのため、コマンドは次のようになります。
```
gcloud compute health-checks delete hc-http-80 \
     --global
```

マネージドインスタンスグループを削除します。

gcloud compute instance-groups managed delete third-party-instance-group \
    --region=us-west1

インスタンステンプレートを削除します。

gcloud compute instance-templates delete third-party-template

gcloud compute instance-templates delete third-party-template-multinic

テストインスタンスと本番環境インスタンスを削除します。

gcloud compute instances delete testing-vm \
    --zone=us-west1-a

gcloud compute instances delete production-vm \
    --zone=us-west1-a

次のステップ

重要な基礎知識について、内部 TCP / UDP ロードバランシングのコンセプトで確認する。
フェイルオーバーに関する重要な情報について、内部 TCP / UDP ロードバランシングのフェイルオーバーのコンセプトで確認する。
内部 TCP / UDP ロードバランサの構成例について、内部 TCP / UDP ロードバランシングの設定で確認する。
内部 TCP / UDP 負荷分散に関する Cloud Logging と Cloud Monitoring の構成について、内部 TCP / UDP 負荷分散のロギングとモニタリングで確認する。
VPC ネットワークに接続されたピアネットワークから内部 TCP / UDP ロードバランサへのアクセスについて、内部 TCP / UDP ロードバランシングと接続ネットワークで確認する。
内部 TCP / UDP ロードバランサの問題のトラブルシューティング方法について、内部 TCP / UDP 負荷分散のトラブルシューティングで確認する。
ロードバランサの設定をクリーンアップする。

サードパーティ アプライアンスのための内部 TCP / UDP 負荷分散の設定

権限

共通のバックエンドで内部 TCP / UDP ロードバランサをネクストホップとして設定する

ネットワーク、リージョン、サブネットの構成

コンソール

gcloud

ファイアウォール ルールの構成

コンソール

gcloud

サードパーティ仮想アプライアンスの作成

コンソール

gcloud

負荷分散リソースの作成

コンソール

gcloud

ロードバランサをネクストホップとして定義する静的ルートの作成

コンソール

gcloud

testing VM インスタンスの作成

gcloud

production VM インスタンスの作成

gcloud

マルチ NIC デプロイに対する負荷分散のテスト

対称ハッシュの有効化

転送ルールを削除して再作成する

コンソール

gcloud

SNAT が不要な場合

クリーンアップ

次のステップ

サードパーティアプライアンスのための内部 TCP / UDP 負荷分散の設定

ファイアウォールルールの構成

`testing` VM インスタンスの作成

`production` VM インスタンスの作成