このガイドでは、サンプルを示しながら、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 ロードバランサの背後にあるアプリケーション インスタンス。ここでは、ファイアウォール アプライアンス ソフトウェアを実行している 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
fw-allow-testing-ssh
ファイアウォール ルールを作成し、ネットワーク タグallow-ssh
を持つ VM への 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
fw-allow-production-ssh
ファイアウォール ルールを作成し、ネットワーク タグallow-ssh
を持つ VM への 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
に設定します。 - [バックエンドの設定] をクリックして、次の変更を行います。
- リージョン:
us-west1
- ネットワーク:
testing
- [バックエンド] の [新しいアイテム] セクションで、
third-party-instance-group
インスタンス グループを選択し、[完了] をクリックします。 - [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
- 名前:
hc-http-80
- プロトコル:
HTTP
- ポート:
80
- プロキシ プロトコル:
NONE
- リクエストパス:
/
。Cloud Console を使用してロードバランサを作成すると、ヘルスチェックはグローバルになります。リージョン ヘルスチェックを作成する場合は、gcloud
または API を使用します。
- 名前:
- 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
- リージョン:
- [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
- 名前:
fr-ilb1
- サブネットワーク:
testing-subnet
- [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
- 名前:
ip-ilb
- 静的 IP アドレス: 選択を許可
- カスタム IP アドレス:
10.30.1.99
- 名前:
- ポート: [単一] を選択して、ポート番号に「
80
」を入力します。 ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。 - 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
- 名前:
- [確認と完了] をクリックします。設定を再度確認します。
- [作成] をクリックします。
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 に展開できます。
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 や macOS ではサポートされていません。
バックエンド 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 負荷分散に関する Stackdriver のロギングとモニタリングの構成については、内部 TCP / UDP 負荷分散のロギングとモニタリングをご覧ください。
- VPC ネットワークに接続されたピア ネットワークから内部 TCP / UDP ロードバランサにアクセスする方法については、内部 TCP / UDP 負荷分散と接続ネットワークをご覧ください。
- 内部 TCP / UDP ロードバランサの問題のトラブル シューティング方法については、内部 TCP / UDP 負荷分散のトラブルシューティングをご覧ください。