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

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

権限

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

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

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

シングルバックエンド NIC への負荷分散

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

このガイドで説明するソリューションには仮想アプライアンスが統合されています。仮想アプライアンスにトラフィックを送信するために、クライアントを明示的に再構成する必要はありません。この設定ガイドの例では、負荷分散された一連のファイアウォール仮想アプライアンスを介してすべてのトラフィックを送信します。

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

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

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

内部 TCP / UDP 負荷分散のネクストホップシングル NIC の例（クリックして拡大）

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

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

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

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

他のユースケースについては、ネクストホップとしての内部 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 アドレス範囲を使用します。

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

Console

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

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

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

Google Cloud Console で [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-subnet: testing ネットワークのすべてのターゲットに適用される上り（内向き）ルールで、10.30.1.0/24 の範囲の送信元からのトラフィックを許可します。このルールにより、testing-subnet の VM インスタンスとサードパーティ VM アプライアンスの通信が可能になります。
fw-allow-production-subnet: production ネットワークのすべてのターゲットに適用される上り（内向き）ルールで、10.50.1.0/24 の範囲の送信元からのトラフィックを許可します。このルールにより、production-subnet の VM インスタンスとサードパーティ VM アプライアンスの通信が可能になります。
fw-allow-testing-ssh: testing VPC ネットワークの VM インスタンスに適用される上り（内向き）ルール。任意のアドレスからの TCP ポート 22 での SSH 接続の受信を許可します。このルールには、送信元 IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグ allow-ssh を使用して、ファイアウォールルールが適用される VM が識別されます。
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 を使用して、適用するインスタンスが識別されます。

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

Console

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

gcloud

fw-allow-testing-subnet ファイアウォールルールを作成して、サブネットとの通信を許可します。

gcloud compute firewall-rules create fw-allow-testing-subnet \
    --network=testing \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.30.1.0/24 \
    --rules=tcp,udp,icmp

fw-allow-production-subnet ファイアウォールルールを作成して、サブネットとの通信を許可します。

gcloud compute firewall-rules create fw-allow-production-subnet \
    --network=production \
    --action=allow \
    --direction=ingress \
    --source-ranges=10.50.1.0/24 \
    --rules=tcp,udp,icmp

ネットワークタグ 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,udp,icmp

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

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

Console

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

gcloud

サードパーティ仮想アプライアンスのインスタンステンプレートを作成します。インスタンステンプレートに --can-ip-forward フラグを追加します。これにより、テンプレートから作成された VM インスタンスが testing ネットワークと production ネットワークの他のインスタンスからパケットを転送できるようになります。

gcloud compute instance-templates create third-party-template \
    --region=us-west1 \
    --network-interface subnet=testing-subnet,address="" \
    --network-interface subnet=production-subnet \
    --tags=allow-ssh,allow-health-check \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script='#! /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 -H "Metadata-Flavor:Google" $md_net/0/gateway)"
    nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
    nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
    nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
    nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
    # Start iptables:
    /sbin/iptables -t nat -F
    /sbin/iptables -t nat -A POSTROUTING \
    -s "$nic0_gw/$nic0_mask" \
    -d "$nic1_gw/$nic1_mask" \
    -o eth1 \
    -j SNAT \
    --to-source "$nic1_addr"
    /sbin/iptables-save
    # Use a web server to pass the health check for this example.
    # You should use a more complete test in production.
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    echo "Example web page to pass health check" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

サードパーティ仮想アプライアンスのマネージドインスタンスグループを作成します。このコマンドは、us-west1 内でリージョンマネージドインスタンスグループを作成し、自動的にスケーリングします。
```
gcloud compute instance-groups managed create third-party-instance-group \
    --region=us-west1 \
    --template=third-party-template \
    --size=3
```

負荷分散リソースの作成

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

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

Console

ロードバランサの作成とバックエンドサービスの構成

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

gcloud

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

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

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

サードパーティ仮想アプライアンスを含むインスタンスグループをバックエンドとしてバックエンドサービスに追加します。
```
gcloud compute backend-services add-backend ilb1 \
    --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
```

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

静的ルートを作成する場合、next-hop-address を使用してロードバランサの転送ルールの IP アドレスを参照することはできません。next-hop-address を使用すると、Google Cloud はその IP アドレスに割り当てられた VM インスタンスにトラフィックを転送しますが、ロードバランサは VM インスタンスではないからです。ロードバランサをネクストホップとして指定する場合は、この例で示すように next-hop-ilb フラグを使用する必要があります。

Console

Google Cloud Console の [ルート] ページに移動します。
[ルート] ページに移動
[ルートを作成] をクリックします。
ルートの名前として「ilb-nhop-dest-10-50-1」と入力します。
testing ネットワークを選択します。
[宛先 IP の範囲] に 10.50.1.0/24 と入力します。
この機能ではタグはサポートされていません。タグは指定しないでください。
ルートのネクストホップで、[内部 TCP / UDP ロードバランサの転送ルールを指定する] を選択します。
ネクストホップリージョンに us-west1 を選択します。
転送ルール名に fr-ilb1 を選択します。
[作成] をクリックします。

gcloud

ネストホップにロードバランサの転送ルールを設定し、宛先範囲をルート 10.50.1.0/24 に設定して、高度なルートを作成します。

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb1 \
    --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-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=testing-subnet \
    --private-network-ip 10.30.1.100 \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    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
    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-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=production-subnet \
    --private-network-ip 10.50.1.100 \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    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
    systemctl restart apache2'

シングル NIC デプロイに対する負荷分散のテスト

このテストでは、testing VPC ネットワークのクライアント VM から production VPC ネットワークのサンプル VM に接続します。ロードバランサは、ロードバランサの IP アドレスに送信するのではなく、ロードバランサ経由でパケットを宛先 10.50.1.100 に送信するため、ネクストホップとしても使用されます。

この例では、ロードバランサの正常なバックエンドアプライアンス VM の iptables ソフトウェアがパケットの NAT を処理します。

クライアント VM インスタンスに接続します。
```
gcloud compute ssh testing-vm --zone=us-west1-a
```
curl を使用して、宛先インスタンスのウェブサーバーソフトウェアにウェブリクエストを送信します。予想される出力は、宛先インスタンスのインデックスページの内容です（Page served from: destination-instance）。
```
curl http://10.50.1.100
```

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

複数の NIC への負荷分散に説明されているように、負荷分散は複数のバックエンド NIC に展開できます。

内部 TCP / UDP 負荷分散のネクストホップマルチ NIC の詳細例（クリックして拡大）

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,udp,icmp

新しいインスタンステンプレートを作成します。

この設定でヘルスチェックをシームレスに動作させるには、ヘルスチェックの下り（外向き）レスポンスパケットが正しいインターフェースを通るように、ポリシーベースのルーティングを構成する必要があります。ヘルスチェックでは、外部 IP アドレスをヘルスチェックプローブのソースとして使用します。ゲスト OS は、宛先 IP アドレスに基づいて送信 NIC を選択します。宛先 IP アドレスがサブネットの範囲内にない場合、送信 NIC はデフォルトで nic0 になります。このような場合は、ポリシーベースのルーティングを使用して、ネットワークインターフェースごとに個別のルーティングテーブルを構成する必要があります。

ソースベースのポリシールーティングは、Windows や Mac ではサポートされていません。

バックエンド VM テンプレートで、次のポリシールーティングを追加します。ここで、10.50.1.0/24 はロードバランサとマルチ NIC VM の eth1 が使用するサブネットです。デフォルトゲートウェイは 10.50.1.1 です

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-9 \
    --image-project=debian-cloud \
    --can-ip-forward \
    --metadata=startup-script='#! /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")"
    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")"
    # Source based policy routing for nic1
    echo "100 rt-nic1" >> /etc/iproute2/rt_tables
    ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
    sleep 1
    ip route add 35.191.0.0/16 via $nic1_gw dev eth1 table rt-nic1
    ip route add 130.211.0.0/22 via $nic1_gw dev eth1 table rt-nic1
    # Start iptables:
    iptables -t nat -F
    iptables -t nat -A POSTROUTING \
    -s $nic0_gw/$nic0_mask \
    -d $nic1_gw/$nic1_mask \
    -o eth1 \
    -j SNAT \
    --to-source $nic1_addr
    iptables -t nat -A POSTROUTING \
    -s $nic1_gw/$nic1_mask \
    -d $nic0_gw/$nic0_mask \
    -o eth0 \
    -j SNAT \
    --to-source $nic0_addr
    iptables-save
    # Use a web server to pass the health check for this example.
    # You should use a more complete test in production.
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    echo "Example web page to pass health check" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

インスタンスグループを更新します。

gcloud compute instance-groups managed set-instance-template \
    third-party-instance-group \
    --region us-west1 \
    --template=third-party-template-multinic

新しい third-party-template-multinic テンプレートを使用して、マネージドインスタンスグループを再作成します。

gcloud compute instance-groups managed rolling-action replace \
    third-party-instance-group \
    --region us-west1

インスタンスが準備されるまで数分間待ちます。進捗状況を確認するには、list-instances コマンドを実行します。

gcloud compute instance-groups managed list-instances \
    third-party-instance-group \
    --region us-west1

出力は次のようになります。

NAME                             ZONE        STATUS   ACTION  INSTANCE_TEMPLATE              VERSION_NAME                        LAST_ERROR
third-party-instance-group-5768  us-west1-a  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
third-party-instance-group-4zf4  us-west1-b  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
third-party-instance-group-f6lm  us-west1-c  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00

production VPC ネットワークにロードバランサのリソースを構成します。

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

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

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

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

マルチ 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

クリーンアップ

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

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 Console を使用した場合、ヘルスチェックはグローバルになります。そのため、コマンドは次のようになります。
```
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 負荷分散の設定

権限

シングル バックエンド NIC への負荷分散

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

Console

gcloud

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

Console

gcloud

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

Console

gcloud

負荷分散リソースの作成

Console

gcloud

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

Console

gcloud

testing VM インスタンスの作成

gcloud

production VM インスタンスの作成

gcloud

シングル NIC デプロイに対する負荷分散のテスト

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

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

クリーンアップ

次のステップ

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

シングルバックエンド NIC への負荷分散

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

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

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