このガイドでは、 Google Cloud内部パススルー ネットワーク ロードバランサの基礎について、サンプルを示しながら説明します。このガイドに進む前に、次の内容を理解しておいてください。
このタスクを Google Cloud コンソールで直接行う際の順を追ったガイダンスについては、[ガイドを表示] をクリックしてください。
権限
このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、次の Compute Engine IAM のロールがすべて必要です。
| タスク | 必要なロール |
|---|---|
| ネットワーク、サブネット、ロードバランサ コンポーネントの作成 | Compute ネットワーク管理者 （ roles/compute.networkAdmin） |
| ファイアウォール ルールの追加と削除 | Compute セキュリティ管理者 （ roles/compute.securityAdmin） |
| インスタンスを作成する | Compute インスタンス管理者 （ roles/compute.instanceAdmin） |
詳細については、次のガイドをご覧ください。
IPv4 専用のサブネットとバックエンドを使用してロードバランサを設定する
このガイドでは、内部パススルー ネットワーク ロードバランサを構成してテストする方法を説明します。このセクションでは、以下の構成方法について説明します。
lb-networkという名前のカスタムモードの VPC ネットワークを使用する例。- IPv4 トラフィックに必要なシングル スタック サブネット（
stack-typeはIPv4に設定）。カスタムモードの VPC ネットワークでシングルスタック サブネットを作成する場合は、サブネットに IPv4 サブネット範囲を選択します。 - バックエンド VM への受信接続を許可するファイアウォール ルール。
- バックエンド インスタンス グループ。この例では、次のリージョンとサブネットにあります。
- リージョン:
us-west1 - サブネット:
lb-subnet（プライマリ IPv4 アドレス範囲は10.1.2.0/24）。
- リージョン:
- 4 つのバックエンド VM: ゾーン
us-west1-aの非マネージド インスタンス グループ内の 2 つの VM と、ゾーンus-west1-cの非マネージド インスタンス グループ内の 2 つの VM。グローバル アクセスを示すために、この例では別のリージョンとサブネットに 2 つ目のテスト クライアント VM を作成します。- リージョン:
europe-west1 - サブネット:
europe-subnet（プライマリ IP アドレス範囲は10.3.4.0/24）
- リージョン:
- 接続のテストに使用する 1 台のクライアント VM。
- 次の内部パススルー ネットワーク ロードバランサのコンポーネント:
- バックエンド サービスのヘルスチェック。
us-west1リージョンの内部バックエンド サービス。2 つのゾーン インスタンス グループへの接続分散を管理します。- ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス。
この例のアーキテクチャは次のようになります。
ネットワーク、リージョン、サブネットを構成する
サンプルのネットワークとサブネットを作成する手順は次のとおりです。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network」と入力します。[サブネット] セクションで、次の操作を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
- 名前:
lb-subnet - リージョン:
us-west1 - IP スタックタイプ: IPv4（シングルスタック）
- IP アドレス範囲:
10.1.2.0/24
- 名前:
- [完了] をクリックします。
- [サブネットを追加] をクリックして、次の情報を入力します。
- 名前:
europe-subnet - リージョン:
europe-west1 - IP スタックタイプ: IPv4（シングルスタック）
- IP アドレス範囲:
10.3.4.0/24
- 名前:
- [完了] をクリックします。
[作成] をクリックします。
gcloud
カスタム VPC ネットワークを作成します。
gcloud compute networks create lb-network --subnet-mode=custom
lb-networkネットワークでus-west1リージョンのバックエンドのサブネットを作成します。gcloud compute networks subnets create lb-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
lb-networkネットワークでeurope-west1リージョンのグローバル アクセスをテストするための別のサブネットを作成します。gcloud compute networks subnets create europe-subnet \ --network=lb-network \ --range=10.3.4.0/24 \ --region=europe-west1
API
networks.insert メソッドに POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks
{
"routingConfig": {
"routingMode": "REGIONAL"
},
"name": "lb-network",
"autoCreateSubnetworks": false
}
subnetworks.insert メソッドに 2 つの POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks
{
"name": "lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"ipCidrRange": "10.1.2.0/24",
"privateIpGoogleAccess": false
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks
{
"name": "europe-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"ipCidrRange": "10.3.4.0/24",
"privateIpGoogleAccess": false
}
ファイアウォール ルールを構成する
この例では、次のファイアウォール ルールを使用します。
fw-allow-lb-access: VPC ネットワーク内のすべてのターゲットに適用される上り（内向き）ルールで、10.1.2.0/24と10.3.4.0/24の範囲にある送信元からのトラフィックを許可します。このルールでは、2 つのサブネットのいずれかにあるクライアントからの受信トラフィックを許可します。これにより、後でグローバル アクセスを構成してテストできます。fw-allow-ssh: ロードバランスされたインスタンスに適用される上り（内向き）ルール。任意のアドレスから TCP ポート 22 への SSH 接続が許可されます。このルールには、送信元 IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲のみを許可するように指定できます。この例では、ターゲットタグallow-sshを使用して、適用する VM を識別させています。fw-allow-health-check: ロードバランスされているインスタンスに適用される上り（内向き）ルール。 Google Cloud ヘルスチェック システム（130.211.0.0/22と35.191.0.0/16）からのトラフィックを許可します。この例では、ターゲットタグallow-health-checkを使用して、適用するインスタンスが識別されます。
これらのファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
コンソール
Google Cloud コンソールで、[ファイアウォール ポリシー] ページに移動します。
サブネット トラフィックを許可するには、[ファイアウォール ルールを作成] をクリックし、次の情報を入力します。
- 名前:
fw-allow-lb-access - ネットワーク:
lb-network - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- [ターゲット]: ネットワーク上のすべてのインスタンス
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
10.1.2.0/24 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
受信 SSH 接続を許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-ssh - ネットワーク:
lb-network - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh - ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
0.0.0.0/0 - プロトコルとポート: [指定したプロトコルとポート] を選択して、[TCP] チェックボックスをオンにし、[ポート] に「
22」と入力します。
- 名前:
[作成] をクリックします。
Google Cloud ヘルスチェックを許可するには、[ファイアウォール ルールを作成] をもう一度クリックして、次の情報を入力します。
- 名前:
fw-allow-health-check - ネットワーク:
lb-network - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check - ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
130.211.0.0/22と35.191.0.0/16 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
gcloud
fw-allow-lb-accessファイアウォール ルールを作成して、サブネットとの通信を許可します。gcloud compute firewall-rules create fw-allow-lb-access \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.1.2.0/24,10.3.4.0/24 \ --rules=tcp,udp,icmpネットワーク タグ
allow-sshを使用して、VM との SSH 接続を許可するfw-allow-sshファイアウォール ルールを作成します。source-rangesを省略すると、Google Cloud は任意の送信元としてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22fw-allow-health-checkルールを作成して Google Cloudヘルスチェックを許可します。gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --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
API
firewalls.insert メソッドに POST リクエストを送信して、fw-allow-lb-access ファイアウォール ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-lb-access",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"10.1.2.0/24", "10.3.4.0/24"
],
"allowed": [
{
"IPProtocol": "tcp"
},
{
"IPProtocol": "udp"
},
{
"IPProtocol": "icmp"
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
firewalls.insert メソッドに POST リクエストを送信して、fw-allow-ssh ファイアウォール ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-ssh",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
firewalls.insert メソッドに POST リクエストを送信して、fw-allow-health-check ファイアウォール ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-allow-health-check",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"allow-health-check"
],
"allowed": [
{
"IPProtocol": "tcp"
},
{
"IPProtocol": "udp"
},
{
"IPProtocol": "icmp"
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
バックエンド VM とインスタンス グループを作成する
この例では、2 つのバックエンド（サーバー）VM を持つ 2 つの非マネージド インスタンスを使用しています。内部パススルー ネットワーク ロードバランサのリージョン特性を示すために、2 つのインスタンス グループが別々のゾーン（us-west1-a と us-west1-c）に配置されています。
- インスタンス グループ
ig-aには、次の 2 つの VM が含まれています。vm-a1vm-a2
- インスタンス グループ
ig-cには、次の 2 つの VM が含まれています。vm-c1vm-c2
4 つのバックエンド VM へのトラフィックがすべてロードバランスされます。
この例と追加の構成オプションをサポートするために、4 つの VM はそれぞれ、TCP ポート 80、8008、8080、8088、443、8443 をリッスンする Apache ウェブサーバーを実行します。
lb-subnet の内部 IP アドレスと外部（公開）エフェメラル IP アドレスがそれぞれの VM に割り当てられます。外部 IP アドレスは後で削除できます。
バックエンド VM がインターネットから Apache をダウンロードでき、また SSH 経由で接続できるため、この例ではバックエンド VM の外部 IP アドレスを使用していますが、これは必須ではありません。
デフォルトでは、Apache は任意の IP アドレスにバインドされます。内部パススルー ネットワーク ロードバランサは、宛先 IP を保持してパケットを配信します。バックエンド VM で実行中のサーバー ソフトウェアが、ロードバランサの内部転送ルールの IP アドレスをリッスンしていることを確認してください。複数の内部転送ルールを構成している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部パススルー ネットワーク ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。
説明を簡単にするため、これらのバックエンド VM では Debian GNU/Linux 12 を実行します。
コンソール
バックエンド VM を作成する
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
次の名前とゾーンの組み合わせを使用して、VM ごとに手順 3 から 8 を繰り返します。
- 名前:
vm-a1、ゾーン:us-west1-a - 名前:
vm-a2、ゾーン:us-west1-a - 名前:
vm-c1、ゾーン:us-west1-c - 名前:
vm-c2、ゾーン:us-west1-c
- 名前:
[インスタンスを作成] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[リージョン] に
us-west1を選択して、ステップ 2 に示したゾーンを選択します。[ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて、[変更] をクリックしてイメージを変更します。
[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と「allow-health-check」を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network - サブネット:
lb-subnet - IP スタックタイプ: IPv4（シングルスタック）
- プライマリ内部 IPv4 アドレス: エフェメラル（自動）
- 外部 IPv4 アドレス: エフェメラル
- ネットワーク:
- [ネットワーク タグ] に「
[管理] をクリックし、[起動スクリプト] フィールドに次のスクリプトを入力します。スクリプトの内容は 4 つの VM ですべて同じです。
#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed[作成] をクリックします。
インスタンス グループを作成する
Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
次の手順を繰り返し、それぞれ 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下の組み合わせを使用します。
- インスタンス グループ名:
ig-a、ゾーン:us-west1-a、VM:vm-a1、vm-a2 - インスタンス グループ名:
ig-c、ゾーン:us-west1-c、VM:vm-c1、vm-c2
- インスタンス グループ名:
[インスタンス グループの作成] をクリックします。
[新しい非マネージド インスタンス グループ] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[ロケーション] セクションで、[リージョン] に
us-west1を選択し、ステップ 2 で説明したように [ゾーン] を選択します。[ネットワーク] で [
lb-network] を選択します。[サブネットワーク] で [
lb-subnet] を選択します。[VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
[作成] をクリックします。
gcloud
次の
[VM-NAME]と[ZONE]の 4 つの組み合わせを使用して、下のコマンドを 4 回実行して 4 つの VM を作成します。スクリプトの内容は 4 つの VM ですべて同じです。VM-NAME:vm-a1、ZONE:us-west1-aVM-NAME:vm-a2、ZONE:us-west1-aVM-NAME:vm-c1、ZONE:us-west1-cVM-NAME:vm-c2、ZONE:us-west1-c
gcloud compute instances create VM-NAME \ --zone=ZONE \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check \ --subnet=lb-subnet \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'各ゾーンに次の 2 つの非マネージド インスタンス グループを作成します。
gcloud compute instance-groups unmanaged create ig-a \ --zone=us-west1-a gcloud compute instance-groups unmanaged create ig-c \ --zone=us-west1-c適切なインスタンス グループに VM を追加します。
gcloud compute instance-groups unmanaged add-instances ig-a \ --zone=us-west1-a \ --instances=vm-a1,vm-a2 gcloud compute instance-groups unmanaged add-instances ig-c \ --zone=us-west1-c \ --instances=vm-c1,vm-c2
API
4 つの VM に対して、次の VM 名とゾーンを使用します。
VM-NAME:vm-a1、ZONE:us-west1-aVM-NAME:vm-a2、ZONE:us-west1-aVM-NAME:vm-c1、ZONE:us-west1-cVM-NAME:vm-c2、ZONE:us-west1-c
現在の DEBIAN_IMAGE_NAME を取得するには、次の gcloud コマンドを実行します。
gcloud compute images list \ --filter="family=debian-12"
instances.insert メソッドに 4 つの POST リクエストを送信して、4 つのバックエンド VM を作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
"name": "VM-NAME",
"tags": {
"items": [
"allow-health-check",
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/[ZONE]/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "VM-NAME",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/PROJECT_ID/zones/zone/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"metadata": {
"items": [
{
"key": "startup-script",
"value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nfile_ports=\"/etc/apache2/ports.conf\"\nfile_http_site=\"/etc/apache2/sites-available/000-default.conf\"\nfile_https_site=\"/etc/apache2/sites-available/default-ssl.conf\"\nhttp_listen_prts=\"Listen 80\\nListen 8008\\nListen 8080\\nListen 8088\"\nhttp_vh_prts=\"*:80 *:8008 *:8080 *:8088\"\nhttps_listen_prts=\"Listen 443\\nListen 8443\"\nhttps_vh_prts=\"*:443 *:8443\"\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://metadata.google.internal/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nprt_conf=\"$(cat \"$file_ports\")\"\nprt_conf_2=\"$(echo \"$prt_conf\" | sed \"s|Listen 80|${http_listen_prts}|\")\"\nprt_conf=\"$(echo \"$prt_conf_2\" | sed \"s|Listen 443|${https_listen_prts}|\")\"\necho \"$prt_conf\" | tee \"$file_ports\"\nhttp_site_conf=\"$(cat \"$file_http_site\")\"\nhttp_site_conf_2=\"$(echo \"$http_site_conf\" | sed \"s|*:80|${http_vh_prts}|\")\"\necho \"$http_site_conf_2\" | tee \"$file_http_site\"\nhttps_site_conf=\"$(cat \"$file_https_site\")\"\nhttps_site_conf_2=\"$(echo \"$https_site_conf\" | sed \"s|_default_:443|${https_vh_prts}|\")\"\necho \"$https_site_conf_2\" | tee \"$file_https_site\"\nsystemctl restart apache2"
}
]
},
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
instanceGroups.insert メソッドに POST リクエストを送信して、2 つのインスタンス グループを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups
{
"name": "ig-a",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups
{
"name": "ig-c",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}
instanceGroups.addInstances メソッドに POST リクエストを送信して、各インスタンス グループにインスタンスを追加します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1",
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a2"
}
]
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c1",
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c2"
}
]
}
ロードバランサ コンポーネントを構成する
この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部パススルー ネットワーク ロードバランサ コンポーネントを構成します。
ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP
200（OK）レスポンスを確認します。詳細については、内部パススルー ネットワーク ロードバランサの概要のヘルスチェックのセクションをご覧ください。バックエンド サービス: 内部ロードバランサを介して HTTP トラフィックを渡す必要があるため、UDP ではなく TCP を使用する必要があります。
転送ルール: この例では、内部転送ルールを 1 つ作成します。
内部 IP アドレス: この例では、転送ルールを作成する際に、内部 IP アドレス
10.1.2.99を指定しています。
コンソール
構成を開始する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
[Create internal passthrough Network Load Balancer] ページで、次の情報を入力します。
- ロードバランサの名前:
be-ilb - リージョン:
us-west1 - ネットワーク:
lb-network
バックエンドを構成する
- [バックエンドの構成] をクリックします。
- IPv4 トラフィックのみを処理するには、[バックエンド] セクションの [新しいバックエンド] で、[IP スタックタイプ] に [IPv4（シングル スタック）] を選択します。
- [インスタンス グループ] で、
ig-cインスタンス グループを選択し、[完了] をクリックします。 - [バックエンドを追加] をクリックし、この手順を繰り返して
ig-aを追加します。 [ヘルスチェック] リストから [ヘルスチェックを作成] を選択し、次の情報を入力して [保存] をクリックします。
- 名前:
hc-http-80 - プロトコル:
HTTP - ポート:
80 - プロキシのプロトコル:
NONE - リクエストパス:
/
Google Cloud コンソールを使用してロードバランサを作成すると、ヘルスチェックはグローバルになります。リージョン ヘルスチェックを作成する場合は、
gcloudまたは API を使用します。- 名前:
続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。
フロントエンドを構成する
- [フロントエンドの構成] をクリックします。
- [新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に「
fr-ilb」と入力します。 - [サブネットワーク] で [
lb-subnet] を選択します。 - [内部 IP の目的] セクションで、[ IP アドレス] リストで [ IP アドレスを作成] を選択して、以下の情報を入力してから [予約] をクリックします。
- 名前:
ip-ilb - IP バージョン: IPv4
- 静的 IP アドレス: ユーザー指定
- カスタム IP アドレス:
10.1.2.99
- 名前:
- [ポート] で、[複数] を選択して、[ポート番号] に
80、8008、8080、8088を入力します。 - 続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。
- [名前] に「
構成を確認する
- [確認と完了] をクリックします。
- ロードバランサの構成を確認します。
- 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
- [作成] をクリックします。
gcloud
新しいリージョン HTTP ヘルスチェックを作成して、ポート 80 で VM との HTTP 接続をテストします。
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80HTTP トラフィックのバックエンド サービスを作成します。
gcloud compute backend-services create be-ilb \ --load-balancing-scheme=internal \ --protocol=tcp \ --region=us-west1 \ --health-checks=hc-http-80 \ --health-checks-region=us-west1バックエンド サービスに、2 つのインスタンス グループを追加します。
gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-a gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-cバックエンド サービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の内部 IP アドレスに
10.1.2.99を指定します。gcloud compute forwarding-rules create fr-ilb \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
regionHealthChecks.insert メソッドに POST リクエストを送信してヘルスチェックを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionHealthChecks
{
"name": "hc-http-80",
"type": "HTTP",
"httpHealthCheck": {
"port": 80
}
}
regionBackendServices.insert メソッドに POST リクエストを送信して、リージョン バックエンド サービスを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices
{
"name": "be-ilb",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a",
"balancingMode": "CONNECTION"
},
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c",
"balancingMode": "CONNECTION"
}
],
"healthChecks": [
"https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/healthChecks/hc-http-80"
],
"loadBalancingScheme": "INTERNAL",
"connectionDraining": {
"drainingTimeoutSec": 0
}
}
forwardingRules.insert メソッドに POST リクエストを送信して転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
ロードバランサをテストする
これらのテストでは、ロードバランサの構成を検証し、想定される動作を確認する方法を示します。
クライアント VM を作成する
この例では、クライアント VM（vm-client）を、バックエンド（サーバー）VM と同じリージョンに作成します。クライアントを使用するのは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すためです。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] に「
vm-client」と入力します。[リージョン] で
us-west1を選択します。[ゾーン] で
us-west1-aを選択します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network - サブネット:
lb-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、バックエンド VM と同じサブネットを使用しています。
gcloud compute instances create vm-client \
--zone=us-west1-a \
--image-family=debian-12 \
--image-project=debian-cloud \
--tags=allow-ssh \
--subnet=lb-subnet
API
instances.insert メソッドに POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances
{
"name": "vm-client",
"tags": {
"items": [
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "vm-client",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/PROJECT_ID/zones/us-west1-a/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
クライアント VM からの接続をテストする
このテストでは、ロードバランサのバックエンド VM からではなく、個別のクライアント VM からロードバランサに接続します。セッション アフィニティが設定されていないため、トラフィックは 4 つのバックエンド VM に分散されます。
クライアント VM インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
curlを使用して IP アドレスに接続するロードバランサへのウェブ リクエストを作成します。レスポンスが異なるバックエンド VM から返ってくることを確認するために、このリクエストを繰り返します。レスポンスを生成する VM の名前が、各バックエンド VM 上で、/var/www/html/index.htmlのコンテンツによる HTML レスポンスのテキストとして表示されます。たとえば、想定されるレスポンスはPage served from: vm-a1やPage served from: vm-a2のようになります。curl http://10.1.2.99
転送ルールは、ポート
80、8008、8080、8088を処理するように構成されています。その他のポートにトラフィックを送信するには、次のように、IP アドレスの後にコロン（:）とポート番号を追加します。curl http://10.1.2.99:8008
内部転送ルールにサービスラベルを追加すると、内部 DNS サービス名を使用してロードバランサに接続できます。
curl http://web-test.fr-ilb.il4.us-west1.lb.PROJECT_ID.internal
ロードバランサの IP アドレスに ping を実行する
このテストでは、ロードバランサの IP アドレスに対して ping を実行することはできません。このテストではこの想定される動作が示されます。これは、内部パススルー ネットワーク ロードバランサが、個別のデバイスではなく、仮想ネットワーク プログラミングで実装されているためです。
クライアント VM インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
ロードバランサの IP アドレスに対して ping を試行します。レスポンスは返されません。この例では、10 秒後に
pingコマンドがタイムアウトします。timeout 10 ping 10.1.2.99
ロードバランスされた VM からリクエストを送信する
このテストでは、バックエンド VM がロードバランサの転送ルールの IP アドレスにパケットを送信すると、リクエストがそれ自体にルーティングされることを示します。これは、バックエンド VM のヘルスチェック状態に関係なく発生します。
内部パススルー ネットワーク ロードバランサは、ゲスト OS の仮想ネットワーク プログラミングと VM 構成を使用して実装されます。Linux VM では、ゲスト環境によって、オペレーティング システムのローカル ルーティング テーブルにロードバランサの IP アドレスのルートが作成されます。
このローカルルートは VM 内にあるため（VPC ネットワーク内のルートではないため）、ロードバランサの IP アドレスに送信されたパケットは VPC ネットワークでは処理されません。ロードバランサの IP アドレスに送信されたパケットは、VM のオペレーティング システムに残ります。
バックエンド VM に接続します（たとえば、
vm-a1）。gcloud compute ssh vm-a1 --zone=us-west1-a
IP アドレスまたはサービス名を指定し
curlを使用して、ロードバランサにウェブ リクエストを送信します。レスポンスは、リクエストを行うバックエンド VM から送信されます。繰り返し行われるリクエストは、同じ方法で応答されます。vm-a1からテストするときに想定されるレスポンスは常に次のとおりです。Page served from: vm-a1curl http://10.1.2.99
ローカルのルーティング テーブルを調べて、ロードバランサ自体の IP アドレス（
10.1.2.99）に一致する宛先を探します。このルートは内部パススルー ネットワーク ロードバランサに必須の部分です。これにより、ロードバランサの背後にある VM からのリクエストが常に同じ VM によって応答される理由がわかります。ip route show table local | grep 10.1.2.99
内部パススルー ネットワーク ロードバランサのバックエンド VM がロードバランサの転送ルール IP アドレスにパケットを送信すると、パケットは常にリクエストを行った VM にルーティングされます。これは、内部パススルー ネットワーク ロードバランサがパススルー ロードバランサであり、このセクションで説明するように、VM のゲスト OS 内にロードバランサの IP アドレスのローカルルートを作成することによって実装されるからです。ロードバランスされたバックエンドがロードバランサの IP アドレスに TCP トラフィックを送信し、トラフィックをロードバランスされていないバックエンドから発信されたように分散する必要がある場合は、リージョン内部プロキシ ネットワーク ロードバランサの使用を検討してください。
詳細については、ネクストホップとしての内部パススルー ネットワーク ロードバランサをご覧ください。
デュアルスタック サブネットとバックエンドを使用してロードバランサを設定する
このドキュメントでは、IPv4 トラフィックと IPv6 トラフィックの両方をサポートする内部パススルー ネットワーク ロードバランサを構成してテストする方法について説明します。このセクションでは、以下の構成方法について説明します。
- このページの例では、
lb-network-dual-stackという名前のカスタムモードの VPC ネットワークを使用します。IPv6 トラフィックにはカスタムモードのサブネットが必要です。 - IPv6 トラフィックに必要なデュアルスタック サブネット（
stack-typeはIPv4_IPv6に設定）。カスタムモードの VPC ネットワークでデュアルスタック サブネットを作成する場合は、サブネットに IPv6 アクセスタイプを選択します。この例では、サブネットのipv6-access-typeパラメータをINTERNALに設定します。このサブネット上の新しい VM には、内部 IPv4 アドレスと内部 IPv6 アドレスの両方を割り当てることができます。手順については、VPC のドキュメントでデュアルスタック サブネットの追加に関する説明をご覧ください。 - バックエンド VM への受信接続を許可するファイアウォール ルール。
- バックエンド インスタンス グループ。この例では、次のリージョンとサブネットにあります。
- リージョン:
us-west1 - サブネット:
lb-subnet（プライマリ IPv4 アドレス範囲は10.1.2.0/24）。サブネットに構成する IPv4 アドレス範囲を選択しますが、IPv6 アドレス範囲は自動的に割り当てられます。Google では、固定サイズ（/64）の IPv6 CIDR ブロックを提供しています。
- リージョン:
- 4 つのバックエンド デュアルスタック VM: ゾーン
us-west1-aの非マネージド インスタンス グループ内の 2 つの VM と、ゾーンus-west1-cの非マネージド インスタンス グループ内の 2 つの VM。グローバル アクセスを示すために、この例では別のリージョンとサブネットに 2 つ目のテスト クライアント VM を作成します。- リージョン:
europe-west1 - サブネット:
europe-subnet（プライマリ IP アドレス範囲は10.3.4.0/24）
- リージョン:
- 接続のテストに使用する 1 台のクライアント VM。
- 次の内部パススルー ネットワーク ロードバランサのコンポーネント:
- バックエンド サービスのヘルスチェック。
us-west1リージョンの内部バックエンド サービス。2 つのゾーン インスタンス グループへの接続分散を管理します。- ロードバランサのフロントエンド用の 2 つの内部転送ルール。
次の図は、この例のアーキテクチャを示しています。
ネットワーク、リージョン、サブネットを構成する
このページで説明されているサンプルの内部パススルー ネットワーク ロードバランサは、lb-network-dual-stack という名前のカスタムモード VPC ネットワークで作成されています。
内部 IPv6 範囲を持つサブネットを構成するには、VPC ネットワーク ULA の内部 IPv6 範囲を有効にします。内部 IPv6 サブネット範囲は、この範囲から割り振られます。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[ VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network-dual-stack」と入力します。このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を行います。
- [プライベート IPv6 アドレスを設定] で、[Configure a ULA internal IPv6 range for this VPC Network] を選択します。
- [内部 IPv6 範囲の割り当て] で、[自動] または [手動] を選択します。
[手動] を選択した場合は、
fd20::/20の範囲内の/48の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。
[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
- 名前:
lb-subnet - リージョン:
us-west1 - IP スタックタイプ: IPv4 と IPv6（デュアルスタック）
- IPv4 範囲:
10.1.2.0/24 - IPv6 アクセスタイプ: 内部
- 名前:
[完了] をクリックします。
[サブネットを追加] をクリックして、次の情報を入力します。
- 名前:
europe-subnet - リージョン:
europe-west1 - IP スタックタイプ: IPv4（シングルスタック）
- IP アドレス範囲:
10.3.4.0/24
- 名前:
[完了] をクリックします。
[作成] をクリックします。
gcloud
新しいカスタムモードの VPC ネットワークを作成するには、
gcloud compute networks createコマンドを実行します。このネットワークのサブネットで内部 IPv6 範囲を構成するには、
--enable-ula-internal-ipv6フラグを使用します。このオプションでは、 Google Cloud が内部 IPv6 サブネット範囲に使用するfd20::/20範囲内の/48ULA 接頭辞を割り当てます。割り当てられる/48IPv6 範囲を選択する場合は、--internal-ipv6-rangeフラグを使用して範囲を指定します。gcloud compute networks create lb-network-dual-stack \ --subnet-mode=custom \ --enable-ula-internal-ipv6 \ --internal-ipv6-range=ULA_IPV6_RANGE \ --bgp-routing-mode=regional
ULA_IPV6_RANGEは、Google が内部 IPv6 サブネット範囲に使用するfd20::/20範囲内の/48接頭辞に置き換えます。--internal-ipv6-rangeフラグを使用しない場合は、Google によってネットワークの/48接頭辞（fd20:bc7:9a1c::/48など）が選択されます。NETWORKネットワーク内に、us-west1リージョンのバックエンド用のサブネットと、europe-west1リージョンのグローバル アクセスをテストするための別のサブネットを作成します。サブネットを作成するには、
gcloud compute networks subnets createコマンドを実行します。gcloud compute networks subnets create lb-subnet \ --network=lb-network-dual-stack \ --range=10.1.2.0/24 \ --region=us-west1 \ --stack-type=IPV4_IPV6 \ --ipv6-access-type=INTERNAL
gcloud compute networks subnets create europe-subnet \ --network=lb-network-dual-stack \ --range=10.3.4.0/24 \ --region=europe-west1 \ --stack-type=IPV4_IPV6 \ --ipv6-access-type=INTERNAL
API
新しいカスタムモードの VPC ネットワークを作成します。
このネットワークのサブネットで内部 IPv6 範囲を構成するには、enableUlaInternalIpv6 を true に設定します。このオプションは、Google が内部 IPv6 サブネット範囲に使用する fd20::/20 範囲内から /48 範囲を割り当てます。割り当てる /48 IPv6 範囲を選択する場合は、internalIpv6Range フィールドを使用して範囲も指定します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks
{
"autoCreateSubnetworks": false,
"name": "lb-network-dual-stack",
"mtu": MTU,
"enableUlaInternalIpv6": true,
"internalIpv6Range": "ULA_IPV6_RANGE",
"routingConfig": {
"routingMode": "DYNAMIC_ROUTING_MODE"
}
}
次のように置き換えます。
PROJECT_ID: VPC ネットワークが作成されているプロジェクトの ID。MTU: ネットワークの最大伝送単位。MTU は、1460（デフォルト）または1500のいずれかです。MTU を1500に設定する前に、最大伝送単位の概要を確認してください。ULA_IPV6_RANGE: Google が内部 IPv6 サブネット範囲に使用するfd20::/20範囲内の/48接頭辞。internalIpv6Rangeの値を指定しない場合、Google はネットワークの/48接頭辞を選択します。DYNAMIC_ROUTING_MODE:globalまたはregionalのいずれか。これは、ネットワーク内の Cloud Router のルート アドバタイズの動作を制御します。詳細については、動的ルーティング モードをご覧ください。詳細については、
networks.insertメソッドをご覧ください。
subnetworks.insert メソッドに 2 つの POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks
{
"ipCidrRange": "10.1.2.0/24",
"network": "lb-network-dual-stack",
"name": "lb-subnet"
"stackType": IPV4_IPV6,
"ipv6AccessType": Internal
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/subnetworks
{
"ipCidrRange": "10.3.4.0/24",
"network": "lb-network-dual-stack",
"name": "europe-subnet"
"stackType": IPV4_IPV6,
"ipv6AccessType": Internal
}
ファイアウォール ルールを構成する
この例では、次のファイアウォール ルールを使用します。
fw-allow-lb-access: VPC ネットワーク内のすべてのターゲットに適用される上り（内向き）ルールで、10.1.2.0/24と10.3.4.0/24の範囲にある送信元からのトラフィックを許可します。このルールでは、2 つのサブネットのいずれかにあるクライアントからの受信トラフィックを許可します。後で、グローバル アクセスの構成とテストを行うことができます。fw-allow-lb-access-ipv6: VPC ネットワーク内のすべてのターゲットに適用される上り（内向き）ルールであり、IPv6 の範囲の送信元からのトラフィックを許可するもの。このルールでは、2 つのサブネットのいずれかにあるクライアントからの受信 IPv6 トラフィックを許可します。後で、グローバル アクセスの構成とテストを行うことができます。fw-allow-ssh: ロードバランスされたインスタンスに適用される上り（内向き）ルール。任意のアドレスから TCP ポート 22 への SSH 接続が許可されます。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグallow-sshを使用して、適用する VM を識別させています。fw-allow-health-check: ロードバランスされているインスタンスに適用される上り（内向き）ルール。 Google Cloud ヘルスチェック システム（130.211.0.0/22と35.191.0.0/16）からのトラフィックを許可します。この例では、ターゲットタグallow-health-checkを使用して、適用するインスタンスが識別されます。fw-allow-health-check-ipv6: ロードバランスされているインスタンスに適用される上り（内向き）ルール。 Google Cloud ヘルスチェック システム（2600:2d00:1:b029::/64）からのトラフィックを許可します。この例では、ターゲットタグallow-health-check-ipv6を使用して、適用するインスタンスが識別されます。
これらのファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
コンソール
Google Cloud コンソールで、[ファイアウォール ポリシー] ページに移動します。
サブネット トラフィックを許可するルールを作成するには、[ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-lb-access - ネットワーク:
lb-network-dual-stack - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- [ターゲット]: ネットワーク上のすべてのインスタンス
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
10.1.2.0/24と10.3.4.0/24 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
IPv6 サブネット トラフィックを許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-lb-access-ipv6 - ネットワーク:
lb-network-dual-stack - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- [ターゲット]: ネットワーク上のすべてのインスタンス
- ソースフィルタ: IPv6 範囲
- 送信元 IPv6 範囲:
lb-subnetに割り当てられた IPV6_ADDRESS - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
受信 SSH 接続を許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-ssh - ネットワーク:
lb-network-dual-stack - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh - ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
0.0.0.0/0 - プロトコルとポート: [指定したプロトコルとポート] を選択して、[TCP] チェックボックスをオンにし、[ポート] に「
22」と入力します。
- 名前:
[作成] をクリックします。
Google Cloud IPv6 ヘルスチェックを許可するには、[ファイアウォール ルールを作成] をもう一度クリックして、次の情報を入力します。
- 名前:
fw-allow-health-check-ipv6 - ネットワーク:
lb-network-dual-stack - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check-ipv6 - ソースフィルタ: IPv6 範囲
- 送信元 IPv6 範囲:
2600:2d00:1:b029::/64 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
Google Cloud ヘルスチェックを許可するには、[ファイアウォール ルールを作成] をもう一度クリックして、次の情報を入力します。
- 名前:
fw-allow-health-check - ネットワーク:
lb-network-dual-stack - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check - ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
130.211.0.0/22と35.191.0.0/16 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
gcloud
fw-allow-lb-accessファイアウォール ルールを作成して、サブネットとの通信を許可します。gcloud compute firewall-rules create fw-allow-lb-access \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --source-ranges=10.1.2.0/24,10.3.4.0/24 \ --rules=allfw-allow-lb-access-ipv6ファイアウォール ルールを作成して、サブネットとの通信を許可します。gcloud compute firewall-rules create fw-allow-lb-access-ipv6 \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --source-ranges=IPV6_ADDRESS \ --rules=allIPV6_ADDRESSは、lb-subnetに割り当てられた IPv6 アドレスに置き換えます。ネットワーク タグ
allow-sshを使用して、VM との SSH 接続を許可するfw-allow-sshファイアウォール ルールを作成します。source-rangesを省略すると、Google Cloud は任意の送信元としてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22Google Cloud IPv6 ヘルスチェックを許可する
fw-allow-health-check-ipv6ルールを作成します。gcloud compute firewall-rules create fw-allow-health-check-ipv6 \ --network=lb-network-dual-stack \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check-ipv6 \ --source-ranges=2600:2d00:1:b029::/64 \ --rules=tcp,udpfw-allow-health-checkルールを作成して Google Cloudヘルスチェックを許可します。gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network-dual-stack \ --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
API
firewalls.insertメソッドにPOSTリクエストを送信して、fw-allow-lb-accessファイアウォール ルールを作成します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-lb-access", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "10.1.2.0/24", "10.3.4.0/24" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" }, { "IPProtocol": "icmp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }firewalls.insertメソッドにPOSTリクエストを送信して、fw-allow-lb-access-ipv6ファイアウォール ルールを作成します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-lb-access-ipv6", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "IPV6_ADDRESS" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" }, { "IPProtocol": "icmp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }IPV6_ADDRESSは、lb-subnetに割り当てられた IPv6 アドレスに置き換えます。firewalls.insertメソッドにPOSTリクエストを送信して、fw-allow-sshファイアウォール ルールを作成します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-ssh", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "0.0.0.0/0" ], "targetTags": [ "allow-ssh" ], "allowed": [ { "IPProtocol": "tcp", "ports": [ "22" ] } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }firewalls.insertメソッドにPOSTリクエストを送信して、fw-allow-health-check-ipv6ファイアウォール ルールを作成します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-health-check-ipv6", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "2600:2d00:1:b029::/64" ], "targetTags": [ "allow-health-check-ipv6" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }firewalls.insertメソッドにPOSTリクエストを送信して、fw-allow-health-checkファイアウォール ルールを作成します。POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls { "name": "fw-allow-health-check", "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack", "priority": 1000, "sourceRanges": [ "130.211.0.0/22", "35.191.0.0/16" ], "targetTags": [ "allow-health-check" ], "allowed": [ { "IPProtocol": "tcp" }, { "IPProtocol": "udp" }, { "IPProtocol": "icmp" } ], "direction": "INGRESS", "logConfig": { "enable": false }, "disabled": false }
バックエンド VM とインスタンス グループを作成する
この例では、2 つのバックエンド（サーバー）VM を持つ 2 つの非マネージド インスタンスを使用しています。内部パススルー ネットワーク ロードバランサのリージョン特性を示すために、2 つのインスタンス グループが別々のゾーン（us-west1-a と us-west1-c）に配置されています。
- インスタンス グループ
ig-aには、次の 2 つの VM が含まれています。vm-a1vm-a2
- インスタンス グループ
ig-cには、次の 2 つの VM が含まれています。vm-c1vm-c2
4 つのバックエンド VM へのトラフィックがすべてロードバランスされます。
この例と追加の構成オプションをサポートするために、4 つの VM はそれぞれ、TCP ポート 80、8008、8080、8088、443、8443 をリッスンする Apache ウェブサーバーを実行します。
lb-subnet の内部 IP アドレスと外部（公開）エフェメラル IP アドレスがそれぞれの VM に割り当てられます。外部 IP アドレスは後で削除できます。
バックエンド VM がインターネットから Apache をダウンロードでき、また SSH 経由で接続できるため、この例ではバックエンド VM の外部 IP アドレスを使用していますが、これは必須ではありません。
デフォルトでは、Apache は任意の IP アドレスにバインドされます。内部パススルー ネットワーク ロードバランサは、宛先 IP を保持してパケットを配信します。
バックエンド VM で実行中のサーバー ソフトウェアが、ロードバランサの内部転送ルールの IP アドレスをリッスンしていることを確認してください。複数の内部転送ルールを構成している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部パススルー ネットワーク ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。
マネージド インスタンス グループを使用している場合は、サブネットワークのスタックタイプが、マネージド インスタンス グループで使用されるインスタンス テンプレートのスタックタイプと一致していることを確認します。マネージド インスタンス グループがデュアルスタック インスタンス テンプレートを使用している場合は、サブネットワークをデュアルスタックにする必要があります。
説明を簡単にするため、これらのバックエンド VM では Debian GNU/Linux 12 を実行します。
コンソール
バックエンド VM を作成する
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
次の名前とゾーンの組み合わせを使用して、VM ごとに手順 3 から 8 を繰り返します。
- 名前:
vm-a1、ゾーン:us-west1-a - 名前:
vm-a2、ゾーン:us-west1-a - 名前:
vm-c1、ゾーン:us-west1-c - 名前:
vm-c2、ゾーン:us-west1-c
- 名前:
[インスタンスを作成] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[リージョン] に
us-west1を選択して、ステップ 2 に示したゾーンを選択します。[ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて、[変更] をクリックしてイメージを変更します。
[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と「allow-health-check-ipv6」を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network-dual-stack - サブネット:
lb-subnet - IP スタックタイプ: IPv4 と IPv6（デュアルスタック）
- プライマリ内部 IPv4 アドレス: エフェメラル（自動）
- 外部 IPv4 アドレス: エフェメラル
- ネットワーク:
[管理] をクリックし、[起動スクリプト] フィールドに次のスクリプトを入力します。スクリプトの内容は 4 つの VM ですべて同じです。
#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed
- [ネットワーク タグ] に「
[作成] をクリックします。
インスタンス·グループを作成する
Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
次の手順を繰り返し、それぞれ 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下の組み合わせを使用します。
- インスタンス グループ名:
ig-a、ゾーン:us-west1-a、VM:vm-a1、vm-a2 - インスタンス グループ名:
ig-c、ゾーン:us-west1-c、VM:vm-c1、vm-c2
- インスタンス グループ名:
[インスタンス グループの作成] をクリックします。
[新しい非マネージド インスタンス グループ] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[ロケーション] セクションで、[リージョン] に
us-west1を選択し、ステップ 2 で示したように [ゾーン] を選択します。[ネットワーク] で [
lb-network-dual-stack] を選択します。[サブネットワーク] で [
lb-subnet] を選択します。[VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
[作成] をクリックします。
gcloud
4 つの VM を作成するには、
[VM-NAME]と[ZONE]にはこれらの 4 つの組み合わせを使用して、gcloud compute instances createコマンドを 4 回実行します。スクリプトの内容は 4 つの VM ですべて同じです。VM-NAME:vm-a1、ZONE:us-west1-aVM-NAME:vm-a2、ZONE:us-west1-aVM-NAME:vm-c1、ZONE:us-west1-cVM-NAME:vm-c2、ZONE:us-west1-cgcloud compute instances create VM-NAME \ --zone=ZONE \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check-ipv6 \ --subnet=lb-subnet \ --stack-type=IPV4_IPV6 \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'
各ゾーンに次の 2 つの非マネージド インスタンス グループを作成します。
gcloud compute instance-groups unmanaged create ig-a \ --zone=us-west1-a gcloud compute instance-groups unmanaged create ig-c \ --zone=us-west1-c適切なインスタンス グループに VM を追加します。
gcloud compute instance-groups unmanaged add-instances ig-a \ --zone=us-west1-a \ --instances=vm-a1,vm-a2 gcloud compute instance-groups unmanaged add-instances ig-c \ --zone=us-west1-c \ --instances=vm-c1,vm-c2
API
4 つの VM に対して、次の VM 名とゾーンを使用します。
VM-NAME:vm-a1、ZONE:us-west1-aVM-NAME:vm-a2、ZONE:us-west1-aVM-NAME:vm-c1、ZONE:us-west1-cVM-NAME:vm-c2、ZONE:us-west1-c
現在の DEBIAN_IMAGE_NAME を取得するには、次の gcloud コマンドを実行します。
gcloud compute images list \ --filter="family=debian-12"
instances.insert メソッドに 4 つの POST リクエストを送信して、4 つのバックエンド VM を作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instances
{
"name": "VM-NAME",
"tags": {
"items": [
"allow-health-check-ipv6",
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/[ZONE]/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"stackType": "IPV4_IPV6",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "VM-NAME",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/PROJECT_ID/zones/zone/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"metadata": {
"items": [
{
"key": "startup-script",
"value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nfile_ports=\"/etc/apache2/ports.conf\"\nfile_http_site=\"/etc/apache2/sites-available/000-default.conf\"\nfile_https_site=\"/etc/apache2/sites-available/default-ssl.conf\"\nhttp_listen_prts=\"Listen 80\\nListen 8008\\nListen 8080\\nListen 8088\"\nhttp_vh_prts=\"*:80 *:8008 *:8080 *:8088\"\nhttps_listen_prts=\"Listen 443\\nListen 8443\"\nhttps_vh_prts=\"*:443 *:8443\"\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nprt_conf=\"$(cat \"$file_ports\")\"\nprt_conf_2=\"$(echo \"$prt_conf\" | sed \"s|Listen 80|${http_listen_prts}|\")\"\nprt_conf=\"$(echo \"$prt_conf_2\" | sed \"s|Listen 443|${https_listen_prts}|\")\"\necho \"$prt_conf\" | tee \"$file_ports\"\nhttp_site_conf=\"$(cat \"$file_http_site\")\"\nhttp_site_conf_2=\"$(echo \"$http_site_conf\" | sed \"s|*:80|${http_vh_prts}|\")\"\necho \"$http_site_conf_2\" | tee \"$file_http_site\"\nhttps_site_conf=\"$(cat \"$file_https_site\")\"\nhttps_site_conf_2=\"$(echo \"$https_site_conf\" | sed \"s|_default_:443|${https_vh_prts}|\")\"\necho \"$https_site_conf_2\" | tee \"$file_https_site\"\nsystemctl restart apache2"
}
]
},
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
instanceGroups.insert メソッドに POST リクエストを送信して、2 つのインスタンス グループを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups
{
"name": "ig-a",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups
{
"name": "ig-c",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}
instanceGroups.addInstances メソッドに POST リクエストを送信して、各インスタンス グループにインスタンスを追加します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1",
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a2"
}
]
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c1",
"instance": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instances/vm-c2"
}
]
}
ロードバランサ コンポーネントを構成する
この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部パススルー ネットワーク ロードバランサ コンポーネントを構成します。
ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP
200（OK）レスポンスを確認します。詳細については、内部パススルー ネットワーク ロードバランサの概要のヘルスチェックのセクションをご覧ください。バックエンド サービス: 内部ロードバランサを介して HTTP トラフィックを渡す必要があるため、UDP ではなく TCP を使用する必要があります。
転送ルール: この例では、IPv4 と IPv6 のトラフィックの内部転送ルールを 2 つ作成します。
内部 IP アドレス: この例では、IPv4 転送ルールを作成する際に、内部 IP アドレス
10.1.2.99を指定しています。詳細については、内部 IP アドレスをご覧ください。構成する IPv4 アドレスを選択しますが、IPv6 アドレスは自動的に割り当てられます。
コンソール
構成を開始する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
[Create internal passthrough Network Load Balancer] ページで、次の情報を入力します。
- ロードバランサの名前:
be-ilb - リージョン:
us-west1 - ネットワーク:
lb-network-dual-stack
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド] の [新しいバックエンド] セクションで、[IP スタックタイプ] に [IPv4 と IPv6（デュアルスタック）] を選択します。
- [インスタンス グループ] で、
ig-aインスタンス グループを選択し、[完了] をクリックします。 - [バックエンドを追加] をクリックし、この手順を繰り返して
ig-cを追加します。 - [ヘルスチェック] リストから [ヘルスチェックを作成] を選択し、次の情報を入力して [保存] をクリックします。
- 名前:
hc-http-80 - 範囲: リージョン
- プロトコル:
HTTP - ポート:
80. - プロキシのプロトコル:
NONE - リクエストパス:
/
- 名前:
- [バックエンドの構成] の横に青いチェックマークが表示されていることを確認します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に「
fr-ilb-ipv6」と入力します。 - IPv6 トラフィックを処理する手順は次のとおりです。
- [IP バージョン] で [IPv6] を選択します。
- [サブネットワーク] で、[
lb-subnet] を選択します。転送ルールの IPv6 アドレス範囲は常にエフェメラルです。 - [ポート] で [複数] を選択し、[ポート番号] フィールドに
80、8008、8080、8088と入力します。 - [完了] をクリックします。
- IPv4 トラフィックを処理する手順は次のとおりです。
- [フロントエンド IP とポートの追加] をクリックします。
- [名前] に「
fr-ilb」と入力します。 - [サブネットワーク] で [
lb-subnet] を選択します。 - [内部 IP の目的] セクションで、[ IP アドレス] リストで [ IP アドレスを作成] を選択して、以下の情報を入力してから [予約] をクリックします。
- 名前:
ip-ilb - IP バージョン: IPv4
- 静的 IP アドレス: ユーザー指定
- カスタム IP アドレス:
10.1.2.99
- 名前:
- [ポート] で、[複数] を選択して、[ポート番号] に
80、8008、8080、8088を入力します。 - [完了] をクリックします。
- 続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。
- [名前] に「
構成を確認する
- [確認と完了] をクリックします。すべての設定を確認します。
- 設定が正しい場合は、[作成] をクリックします。内部パススルー ネットワーク ロードバランサが作成されるまでに数分かかります。
gcloud
新しいリージョン HTTP ヘルスチェックを作成して、ポート 80 で VM との HTTP 接続をテストします。
gcloud compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80HTTP トラフィックのバックエンド サービスを作成します。
gcloud compute backend-services create be-ilb \ --load-balancing-scheme=internal \ --protocol=tcp \ --region=us-west1 \ --health-checks=hc-http-80 \ --health-checks-region=us-west1バックエンド サービスに、2 つのインスタンス グループを追加します。
gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-a gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-cバックエンド サービスの転送ルールを 2 つ作成します。IPv4 転送ルールを作成するときに、IPv4 アドレス用のサブネット内の内部 IP アドレスに
10.1.2.99を指定します。gcloud compute forwarding-rules create fr-ilb \ --region=us-west1 \ --load-balancing-scheme=internal \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1gcloud compute forwarding-rules create fr-ilb-ipv6 \ --region=us-west1 \ --load-balancing-scheme=internal \ --subnet=lb-subnet \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1 \ --ip-version=IPV6
API
regionHealthChecks.insert メソッドに POST リクエストを送信してヘルスチェックを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/regionHealthChecks
{
"name": "hc-http-80",
"type": "HTTP",
"httpHealthCheck": {
"port": 80
}
}
regionBackendServices.insert メソッドに POST リクエストを送信して、リージョン バックエンド サービスを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices
{
"name": "be-ilb",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroups/ig-a",
"balancingMode": "CONNECTION"
},
{
"group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-c/instanceGroups/ig-c",
"balancingMode": "CONNECTION"
}
],
"healthChecks": [
"https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/healthChecks/hc-http-80"
],
"loadBalancingScheme": "INTERNAL",
"connectionDraining": {
"drainingTimeoutSec": 0
}
}
forwardingRules.insert メソッドに POST リクエストを送信して転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb-ipv6",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"ipVersion": "IPV6",
"networkTier": "PREMIUM"
}
forwardingRules.insert メソッドに POST リクエストを送信して転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
ロードバランサをテストする
ロードバランサをテストするには、ロードバランサと同じリージョンにクライアント VM を作成し、クライアントからロードバランサにトラフィックを送信します。
クライアント VM を作成する
この例では、クライアント VM（vm-client）を、バックエンド（サーバー）VM と同じリージョンに作成します。クライアントを使用するのは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すためです。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] に「
vm-client」と入力します。[リージョン] で
us-west1を選択します。[ゾーン] で
us-west1-aを選択します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network-dual-stack - サブネット:
lb-subnet - IP スタックタイプ: IPv4 と IPv6（デュアルスタック）
- プライマリ内部 IP: エフェメラル（自動）
- 外部 IP: エフェメラル
- ネットワーク:
- [完了] をクリックします。
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、バックエンド VM と同じサブネットを使用しています。
gcloud compute instances create vm-client \
--zone=us-west1-a \
--image-family=debian-12 \
--image-project=debian-cloud \
--stack-type=IPV4_IPV6 \
--tags=allow-ssh \
--subnet=lb-subnet
API
instances.insert メソッドに POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances
{
"name": "vm-client",
"tags": {
"items": [
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"stackType": "IPV4_IPV6",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network-dual-stack",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "vm-client",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/PROJECT_ID/zones/us-west1-a/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
接続をテストする
このテストでは、ロードバランサのバックエンド VM からではなく、個別のクライアント VM からロードバランサに接続します。想定される動作は、トラフィックは 4 つのバックエンド VM に分散されることです。
クライアント VM インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
IPv6 転送ルール
fr-ilb-ipv6の説明を取得します。説明のIPV6_ADDRESSをメモします。gcloud compute forwarding-rules describe fr-ilb-ipv6 --region=us-west1
IPv4 転送ルール
fr-ilbの説明を取得します。gcloud compute forwarding-rules describe fr-ilb --region=us-west1
IPv6 接続のクライアントから、次のコマンドを実行します。
$ curl -m 10 -s http://IPV6_ADDRESS:80たとえば、割り当てられた IPv6 アドレスが
[fd20:1db0:b882:802:0:46:0:0/96]:80の場合、コマンドは次のようになります。$ curl -m 10 -s http://[fd20:1db0:b882:802:0:46:0:0]:80IPv4 接続のクライアントから、次のコマンドを実行します。
$ curl -m 10 -s http://10.1.2.99:80プレースホルダを有効な値に置き換えます。
IPV6_ADDRESSは、fr-ilb-ipv6転送ルールのエフェメラル IPv6 アドレスです。
IPv6 専用のサブネットとバックエンドを使用してロードバランサを設定する
このドキュメントでは、IPv6 トラフィックのみをサポートする内部パススルー ネットワーク ロードバランサを構成してテストする方法について説明します。このセクションでは、以下の構成方法について説明します。
lb-network-ipv6-onlyという名前のカスタムモードの VPC ネットワーク。IPv6 トラフィックにはカスタムモードのサブネットが必要です。- IPv6 専用トラフィックに必要な
lb-subnet-ipv6-onlyという名前の内部 IPv6 専用サブネット（stack-typeはIPv6_ONLYに設定）。 - バックエンド VM への受信接続を許可するファイアウォール ルール。
- バックエンド インスタンス グループ。この例では、次のリージョンとサブネットにあります。
- リージョン:
us-west1 - サブネット:
lb-subnet-ipv6-onlyサブネットの IPv6 アドレス範囲は自動的に割り当てられます。Google では、固定サイズ（/64）の IPv6 CIDR ブロックを提供しています。
- リージョン:
- 4 つのバックエンド IPv6 専用の VM: ゾーン
us-west1-aの非マネージド インスタンス グループ内の 2 つの VM と、ゾーンus-west1-cの非マネージド インスタンス グループ内の 2 つの VM。 - バックエンド VM 上の IPv6 TCP サーバー。サーバーは、ロードバランサの転送ルールの指定された VIP と指定されたネットワーク インターフェースで受信接続をリッスンします。サーバーは、受信クライアント接続を受け入れ、レスポンスを送信してから接続を終了します。
- 接続のテストに使用する 1 台のクライアント VM。
- 次の内部パススルー ネットワーク ロードバランサのコンポーネント:
- バックエンド サービスのヘルスチェック
us-west1リージョンの内部バックエンド サービス。2 つのゾーン インスタンス グループへの接続分散を管理します。- IPv6 転送ルール
ネットワーク、リージョン、サブネットを構成する
このページで説明されているサンプルの内部パススルー ネットワーク ロードバランサは、lb-network-ipv6-only という名前のカスタムモード VPC ネットワークで作成されています。
内部 IPv6 範囲を持つサブネットを構成するには、VPC ネットワーク ULA の内部 IPv6 範囲を有効にします。内部 IPv6 サブネット範囲は、この範囲から割り振られます。
後で、このドキュメントの 起動 Bash スクリプトを使用して、バックエンド VM に IPv6 TCP サーバーをインストールするセクションで、内部 IPv6 サブネット範囲を使用して、VPC サブネットから指定されたゲートウェイとネットワーク インターフェースを経由してトラフィックを転送するルーティング ルールを作成します。
コンソール
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network-ipv6-only」と入力します。このネットワークのサブネットで内部 IPv6 アドレス範囲を構成する場合は、次の手順を行います。
- [プライベート IPv6 アドレスを設定] で、[Configure a ULA internal IPv6 range for this VPC Network] を選択します。
- [内部 IPv6 範囲の割り当て] で、[自動] または [手動] を選択します。
[手動] を選択した場合は、
fd20::/20の範囲内の/48の範囲を入力します。範囲が使用されている場合は、別の範囲を指定するように求めるプロンプトが表示されます。
[サブネット作成モード] で [カスタム] を選択します。
[新しいサブネット] セクションで、サブネットに次の構成パラメータを指定します。
- 名前:
lb-subnet-ipv6-only - リージョン:
us-west1 - IP スタックタイプ: IPv6（シングルスタック）
- IPv6 アクセスタイプ: 内部
- 名前:
[完了] をクリックします。
[作成] をクリックします。
gcloud
新しいカスタムモードの VPC ネットワークを作成するには、
gcloud compute networks createコマンドを実行します。このネットワークのサブネットで内部 IPv6 範囲を構成するには、
--enable-ula-internal-ipv6フラグを使用します。gcloud compute networks create lb-network-ipv6-only \ --subnet-mode=custom \ --enable-ula-internal-ipv6 \ --bgp-routing-mode=regional
ipv6-access-typeをINTERNALに設定してサブネットを構成します。これは、このサブネット内の VM に内部 IPv6 アドレスのみを設定できることを示します。サブネットを作成するには、gcloud compute networks subnets createコマンドを実行します。gcloud compute networks subnets create lb-subnet-ipv6-only \ --network=lb-network-ipv6-only \ --region=us-west1 \ --stack-type=IPV6_ONLY \ --ipv6-access-type=INTERNAL
ファイアウォール ルールを構成する
この例では、次のファイアウォール ルールを使用します。
fw-allow-lb-access-ipv6-only: VPC ネットワーク内のすべてのターゲットに適用される上り（内向き）ルールで、すべての IPv6 ソースからのトラフィックを許可します。fw-allow-ssh: ロードバランスされたインスタンスに適用される上り（内向き）ルール。任意のアドレスから TCP ポート22への SSH 接続が許可されます。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグallow-sshを使用して、適用する VM を識別させています。fw-allow-health-check-ipv6-only: ロードバランスされているインスタンスに適用される上り（内向き）ルール。 Google Cloud ヘルスチェック システム（2600:2d00:1:b029::/64）からのトラフィックを許可します。この例では、ターゲットタグallow-health-check-ipv6を使用して、適用するインスタンスが識別されます。
これらのファイアウォール ルールがない場合は、デフォルトの上り（内向き）拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
コンソール
Google Cloud コンソールで、[ファイアウォール ポリシー] ページに移動します。
IPv6 サブネット トラフィックを許可するには、もう一度 [ファイアウォール ルールを作成] をクリックして、次の情報を入力します。
- 名前:
fw-allow-lb-access-ipv6-only - ネットワーク:
lb-network-ipv6-only - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- [ターゲット]: ネットワーク上のすべてのインスタンス
- ソースフィルタ: IPv6 範囲
- 送信元 IPv6 範囲:
::/0 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
受信 SSH 接続を許可するには、[ファイアウォール ルールを作成] をもう一度クリックして、次の情報を入力します。
- 名前:
fw-allow-ssh - ネットワーク:
lb-network-ipv6-only - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh - ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
0.0.0.0/0 - プロトコルとポート: [指定したプロトコルとポート] を選択して、[TCP] チェックボックスをオンにし、[ポート] に「
22」と入力します。
- 名前:
[作成] をクリックします。
Google Cloud IPv6 ヘルスチェックを許可するには、[ファイアウォール ルールを作成] をもう一度クリックして、次の情報を入力します。
- 名前:
fw-allow-health-check-ipv6-only - ネットワーク:
lb-network-ipv6-only - 優先度:
1000 - トラフィックの方向: 上り（内向き）
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check-ipv6 - ソースフィルタ: IPv6 範囲
- 送信元 IPv6 範囲:
2600:2d00:1:b029::/64 - プロトコルとポート: すべて許可
- 名前:
[作成] をクリックします。
gcloud
fw-allow-lb-access-ipv6ファイアウォール ルールを作成して、サブネットとの通信を許可します。gcloud compute firewall-rules create fw-allow-lb-access-ipv6-only \ --network=lb-network-ipv6-only \ --action=allow \ --direction=ingress \ --source-ranges=::/0 \ --rules=allIPV6_ADDRESSは、lb-subnet-ipv6-onlyに割り当てられた IPv6 アドレスに置き換えます。ネットワーク タグ
allow-sshを使用して、VM との SSH 接続を許可するfw-allow-sshファイアウォール ルールを作成します。source-rangesを省略すると、Google Cloud は任意の送信元としてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network-ipv6-only \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22Google Cloud IPv6 ヘルスチェックを許可する
fw-allow-health-check-ipv6ルールを作成します。gcloud compute firewall-rules create fw-allow-health-check-ipv6-only \ --network=lb-network-ipv6-only \ --action=allow \ --direction=ingress \ --target-tags=allow-health-check-ipv6 \ --source-ranges=2600:2d00:1:b029::/64 \ --rules=tcp,udp
バックエンド VM とインスタンス グループを作成する
この例では、2 つのバックエンド VM を持つ 2 つの非マネージド インスタンスを使用しています。内部パススルー ネットワーク ロードバランサのリージョン特性を示すために、2 つのインスタンス グループが別々のゾーン（us-west1-a と us-west1-c）に配置されています。
- インスタンス グループ
ig-aには、次の 2 つの VM が含まれています。vm-a1vm-a2
- インスタンス グループ
ig-cには、次の 2 つの VM が含まれています。vm-c1vm-c2
4 つのバックエンド VM へのトラフィックがすべてロードバランスされます。
コンソール
バックエンド VM を作成する
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
次の名前とゾーンの組み合わせを使用して、VM ごとにこれらの手順を繰り返します。
- 名前:
vm-a1、ゾーン:us-west1-a - 名前:
vm-a2、ゾーン:us-west1-a - 名前:
vm-c1、ゾーン:us-west1-c - 名前:
vm-c2、ゾーン:us-west1-c
- 名前:
[インスタンスを作成] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[リージョン] に
us-west1を選択して、ステップ 2 に示したゾーンを選択します。[ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて、[変更] をクリックしてイメージを変更します。
[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と「allow-health-check-ipv6」を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network-ipv6-only - サブネット:
lb-subnet-ipv6-only - IP スタックタイプ: IPv6（シングルスタック）
- プライマリ内部 IPv6 アドレス: エフェメラル（自動）
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
バックエンド VM では、受信接続をリッスンする IPv6 TCP サーバーを実行する必要があります。ロードバランサを構成した後、このサーバーをバックエンド VM にインストールします。これは、サーバー スクリプトがロードバランサの転送ルールにバインドするソケットを作成するためです。
インスタンス·グループを作成する
Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
次の手順を繰り返し、それぞれ 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下の組み合わせを使用します。
- インスタンス グループ名:
ig-a、ゾーン:us-west1-a、VM:vm-a1、vm-a2 - インスタンス グループ名:
ig-c、ゾーン:us-west1-c、VM:vm-c1、vm-c2
- インスタンス グループ名:
[インスタンス グループの作成] をクリックします。
[新しい非マネージド インスタンス グループ] をクリックします。
ステップ 2 に示したように [名前] を設定します。
[ロケーション] セクションで、[リージョン] に
us-west1を選択し、ステップ 2 で示したように [ゾーン] を選択します。[ネットワーク] で [
lb-network-ipv6-only] を選択します。[サブネットワーク] で [
lb-subnet-ipv6-only] を選択します。[VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
[作成] をクリックします。
gcloud
4 つの VM を作成するには、
[VM-NAME]と[ZONE]にはこれらの 4 つの組み合わせを使用して、gcloud compute instances createコマンドを 4 回実行します。VM-NAME:vm-a1、ZONE:us-west1-aVM-NAME:vm-a2、ZONE:us-west1-aVM-NAME:vm-c1、ZONE:us-west1-cVM-NAME:vm-c2、ZONE:us-west1-c
gcloud beta compute instances create VM-NAME \ --zone=ZONE \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check-ipv6 \ --subnet=lb-subnet-ipv6-only \ --stack-type=IPV6_ONLYバックエンド VM では、受信接続をリッスンする IPv6 TCP サーバーを実行する必要があります。ロードバランサを構成した後、このサーバーをバックエンド VM にインストールします。これは、サーバー スクリプトがロードバランサの転送ルールにバインドするソケットを作成するためです。
各ゾーンに次の 2 つの非マネージド インスタンス グループを作成します。
gcloud beta compute instance-groups unmanaged create ig-a \ --zone=us-west1-a gcloud beta compute instance-groups unmanaged create ig-c \ --zone=us-west1-c適切なインスタンス グループに VM を追加します。
gcloud beta compute instance-groups unmanaged add-instances ig-a \ --zone=us-west1-a \ --instances=vm-a1,vm-a2 gcloud beta compute instance-groups unmanaged add-instances ig-c \ --zone=us-west1-c \ --instances=vm-c1,vm-c2
ロードバランサ コンポーネントを構成する
この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部パススルー ネットワーク ロードバランサ コンポーネントを構成します。
コンソール
構成を開始する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
[Create internal passthrough Network Load Balancer] ページで、次の情報を入力します。
- ロードバランサの名前:
ilb-ipv6-only - リージョン:
us-west1 - ネットワーク:
lb-network-ipv6-only
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド] の [新しいバックエンド] セクションで、[IP スタックタイプ] に [IPv6（シングルスタック）] を選択します。
- [インスタンス グループ] で、
ig-aインスタンス グループを選択し、[完了] をクリックします。 - [バックエンドを追加] をクリックし、この手順を繰り返して
ig-cを追加します。 - [ヘルスチェック] リストから [ヘルスチェックを作成] を選択し、次の情報を入力して [保存] をクリックします。
- 名前:
hc-http-80 - 範囲: リージョン
- プロトコル:
HTTP - ポート:
80. - プロキシのプロトコル:
NONE - リクエストパス:
/
- 名前:
- [バックエンドの構成] の横に青いチェックマークが表示されていることを確認します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に「
fr-ilb-ipv6-only」と入力します。 - IPv6 トラフィックを処理する手順は次のとおりです。
- [IP バージョン] で [IPv6] を選択します。次のセクションで作成する IPv6 TCP サーバーは、転送ルールの VIP にバインドされます。
- [サブネットワーク] で、[
lb-subnet-ipv6-only] を選択します。転送ルールの IPv6 アドレス範囲は常にエフェメラルです。 - [ポート] で [複数] を選択し、[ポート番号] フィールドに
80、8008、8080、8088と入力します。 - [完了] をクリックします。
- 続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。
- [名前] に「
構成を確認する
- [確認と完了] をクリックします。すべての設定を確認します。
- 設定が正しい場合は、[作成] をクリックします。内部パススルー ネットワーク ロードバランサが作成されるまでに数分かかります。
gcloud
新しいリージョン HTTP ヘルスチェックを作成して、ポート 80 で VM との HTTP 接続をテストします。
gcloud beta compute health-checks create http hc-http-80 \ --region=us-west1 \ --port=80バックエンド サービスを作成します。
gcloud beta compute backend-services create ilb-ipv6-only \ --load-balancing-scheme=INTERNAL \ --protocol=tcp \ --region=us-west1 \ --health-checks=hc-http-80 \ --health-checks-region=us-west1バックエンド サービスに、2 つのインスタンス グループを追加します。
gcloud beta compute backend-services add-backend ilb-ipv6-only \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-agcloud beta compute backend-services add-backend ilb-ipv6-only \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-cエフェメラル IPv6 アドレスを使用して IPv6 転送ルールを作成します。
gcloud beta compute forwarding-rules create fr-ilb-ipv6-only \ --region=us-west1 \ --load-balancing-scheme=INTERNAL \ --subnet=lb-subnet-ipv6-only \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=ilb-ipv6-only \ --backend-service-region=us-west1 \ --ip-version=IPV6次のセクションで作成する IPv6 TCP サーバーは、転送ルールの VIP にバインドされます。
起動 Bash スクリプトを使用して、バックエンド VM に IPv6 TCP サーバーをインストールする
この例では、バックエンド VM の Bash 起動スクリプトに次のものが含まれています。
- サブネットから送信されるすべてのパケットを指定されたゲートウェイとネットワーク インターフェース経由で転送するネットワーク コマンド。
- Python サーバー スクリプト（
server.py）。IPv6 TCP サーバーであり、指定された VIP とネットワーク インターフェースで受信接続をリッスンします。受信クライアント接続を受け入れ、レスポンスを送信してから接続を終了します。
Bash スクリプトに次の詳細情報を追加する必要があります。
- ゲートウェイ アドレス
- サブネット範囲
- 転送ルールの VIP
- ネットワーク インターフェース
ゲートウェイ アドレスとサブネット範囲を確認するには、バックエンド VM で ip -6 route show table all コマンドを実行します。起動 Bash スクリプトで使用されるコマンドの詳細については、この構成の付録セクションをご覧ください。
VM インスタンスに起動スクリプトを追加するには、次の操作を行います。
コンソール
前に作成した VM インスタンスのリストで、更新する VM インスタンスをクリックします。
[編集] をクリックします。
[メタデータ] セクションの [起動スクリプト] フィールドに、次のスクリプトを入力します。
#!/bin/bash # Replace these with your actual values. Run the 'ip -6 route show table all' command to find the correct values. GATEWAY_ADDRESS=fe80::57:2ff:fe36:ffbe SUBNET_RANGE=fd20:307:120c:2000::/64 # Add a custom default route to routing table 1. # The following command sends packets to the gateway using the network interface named 'ens4'. sudo ip route add default via $GATEWAY_ADDRESS dev ens4 table 1 # Add a source-based policy routing rule. # The following command adds a rule to route all outgoing packets originating # from a specified subnet. If the source address matches the subnet, # the system uses the default route defined in table 1 to forward the traffic. sudo ip -6 rule add from $SUBNET_RANGE table 1 # Allow the server to bind to a non-local IPv6 address--the VIP of the load balancer. sudo sysctl -w net.ipv6.ip_nonlocal_bind=1 # Overview: # This script sets up a simple IPv6 TCP server using Python's socket library. # The server binds to a specific network interface and listens on a specified Virtual IP (VIP) address and port (default: 80). # It accepts incoming client connections, sends a simple response ("Thank you for connecting"), and then closes the connection. # Key features: # - Uses IPv6 (AF_INET6) for networking. # - Binds to a specific network interface using SO_BINDTODEVICE. # - Handles multiple client connections in a loop. # - Demonstrates basic socket programming concepts like binding, listening, accepting, and sending data. # Note: Replace placeholders like 'FORWARDING_RULE_VIP' and 'ens4' with actual values for your setup. # Write the Python file locally. cat << 'EOF' > server.py # Import the socket library to work with network connections import socket import urllib.request # Fetch the VM hostname from Google Cloud metadata server def get_vm_hostname(): url = "http://metadata.google.internal/computeMetadata/v1/instance/name" req = urllib.request.Request(url, headers={"Metadata-Flavor": "Google"}) with urllib.request.urlopen(req) as response: return response.read().decode() vm_hostname = get_vm_hostname() # Create a socket object for IPv6 and TCP connections # AF_INET6 specifies IPv6, SOCK_STREAM specifies TCP server_socket = socket.socket(socket.AF_INET6, socket.SOCK_STREAM) # Set the SO_REUSEADDR option to allow reusing the address # This is useful to avoid "address already in use" errors when restarting the server server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # Specify the network interface to bind the server to # Replace "ens4" with the name of your network interface interface_name = "ens4" # Get the index of the network interface interface_index = socket.if_nametoindex(interface_name) # Bind the socket to the specified network interface server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, interface_name.encode()) # Bind the socket to an address and port # Replace 'FORWARDING_RULE_VIP' with the actual VIP (Virtual IP) address server_address = ('FORWARDING_RULE_VIP', 80, 0, 0) server_socket.bind(server_address) # Start listening for incoming connections # The argument '5' specifies the maximum number of queued connections server_socket.listen(5) # Print a message indicating that the server is ready to accept connections print(f"Server listening on {server_address}, bound to {interface_name}") # Serve incoming connections while True: client_socket, client_address = server_socket.accept() print(f"Accepted connection from {client_address}") # Generate response body body = f"Thank you for connecting to {vm_hostname}\n" # Construct a proper HTTP/1.1 response response = ( "HTTP/1.1 200 OK\r\n" f"Content-Length: {len(body)}\r\n" "Content-Type: text/plain\r\n" "Connection: close\r\n" "\r\n" f"{body}" ) # Send the response and close the connection client_socket.sendall(response.encode()) client_socket.close() EOF # Make the Python script executable chmod +x server.py # Run the server sudo python3 server.py[保存] をクリックします。
gcloud
起動スクリプトを作成します。
nano startup.sh
次のスクリプトを追加してファイルを保存します。
#!/bin/bash # Replace these with your actual values. Run the 'ip -6 route show table all' command to find the correct values. GATEWAY_ADDRESS=fe80::57:2ff:fe36:ffbe SUBNET_RANGE=fd20:307:120c:2000::/64 # Add a custom default route to routing table 1. # The following command sends packets to the gateway using the network interface named 'ens4'. sudo ip route add default via $GATEWAY_ADDRESS dev ens4 table 1 # Add a source-based policy routing rule. # The following command adds a rule to route all outgoing packets originating # from a specified subnet. If the source address matches the subnet, # the system uses the default route defined in table 1 to forward the traffic. sudo ip -6 rule add from $SUBNET_RANGE table 1 # Allow the server to bind to a non-local IPv6 address--the VIP of the load balancer. sudo sysctl -w net.ipv6.ip_nonlocal_bind=1 # Overview: # This script sets up a simple IPv6 TCP server using Python's socket library. # The server binds to a specific network interface and listens on a specified Virtual IP (VIP) address and port (default: 80). # It accepts incoming client connections, sends a simple response ("Thank you for connecting"), and then closes the connection. # Key features: # - Uses IPv6 (AF_INET6) for networking. # - Binds to a specific network interface using SO_BINDTODEVICE. # - Handles multiple client connections in a loop. # - Demonstrates basic socket programming concepts like binding, listening, accepting, and sending data. # Note: Replace placeholders like 'FORWARDING_RULE_VIP' and 'ens4' with actual values for your setup. # Write the Python file locally. cat << 'EOF' > server.py # Import the socket library to work with network connections import socket import urllib.request # Fetch the VM hostname from Google Cloud metadata server def get_vm_hostname(): url = "http://metadata.google.internal/computeMetadata/v1/instance/name" req = urllib.request.Request(url, headers={"Metadata-Flavor": "Google"}) with urllib.request.urlopen(req) as response: return response.read().decode() vm_hostname = get_vm_hostname() # Create a socket object for IPv6 and TCP connections # AF_INET6 specifies IPv6, SOCK_STREAM specifies TCP server_socket = socket.socket(socket.AF_INET6, socket.SOCK_STREAM) # Set the SO_REUSEADDR option to allow reusing the address # This is useful to avoid "address already in use" errors when restarting the server server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # Specify the network interface to bind the server to # Replace "ens4" with the name of your network interface interface_name = "ens4" # Get the index of the network interface interface_index = socket.if_nametoindex(interface_name) # Bind the socket to the specified network interface server_socket.setsockopt(socket.SOL_SOCKET, socket.SO_BINDTODEVICE, interface_name.encode()) # Bind the socket to an address and port # Replace 'FORWARDING_RULE_VIP' with the actual VIP (Virtual IP) address server_address = ('FORWARDING_RULE_VIP', 80, 0, 0) server_socket.bind(server_address) # Start listening for incoming connections # The argument '5' specifies the maximum number of queued connections server_socket.listen(5) # Print a message indicating that the server is ready to accept connections print(f"Server listening on {server_address}, bound to {interface_name}") # Serve incoming connections while True: client_socket, client_address = server_socket.accept() print(f"Accepted connection from {client_address}") # Generate response body body = f"Thank you for connecting to {vm_hostname}\n" # Construct a proper HTTP/1.1 response response = ( "HTTP/1.1 200 OK\r\n" f"Content-Length: {len(body)}\r\n" "Content-Type: text/plain\r\n" "Connection: close\r\n" "\r\n" f"{body}" ) # Send the response and close the connection client_socket.sendall(response.encode()) client_socket.close() EOF # Make the Python script executable chmod +x server.py # Run the server sudo python3 server.pyメタデータ ファイルを VM インスタンスに追加します。
gcloud compute instances add-metadata VM-NAME \ --metadata-from-file=startup-script=startup.sh
ロードバランサをテストする
ロードバランサをテストするには、ロードバランサと同じリージョンにクライアント VM を作成し、クライアントからロードバランサにトラフィックを送信します。
クライアント VM を作成する
この例では、クライアント VM（vm-client）を、バックエンド（サーバー）VM と同じリージョンに作成します。クライアントを使用するのは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すためです。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] に「
vm-client」と入力します。[リージョン] で
us-west1を選択します。[ゾーン] で
us-west1-aを選択します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network-ipv6-only - サブネット:
lb-subnet-ipv6-only - IP スタックタイプ: IPv6（シングルスタック）
- ネットワーク:
- [完了] をクリックします。
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、バックエンド VM と同じサブネットを使用しています。
gcloud beta compute instances create vm-client \
--zone=us-west1-a \
--image-family=debian-12 \
--image-project=debian-cloud \
--stack-type=IPV6_ONLY \
--tags=allow-ssh \
--subnet=lb-subnet-ipv6-only
接続をテストする
このテストでは、ロードバランサのバックエンド VM からではなく、個別のクライアント VM からロードバランサに接続します。想定される動作は、トラフィックは 4 つのバックエンド VM に分散されることです。
SSH を使用してクライアント インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
IPv6 転送ルール
fr-ilb-ipv6-onlyの説明を取得します。説明のIPV6_ADDRESSをメモします。gcloud beta compute forwarding-rules describe fr-ilb-ipv6-only \ --region=us-west1IPv6 接続のクライアントから、次のコマンドを実行します。
curl http://IPV6_ADDRESS:80
たとえば、割り当てられた IPv6 アドレスが
[fd20:307:120c:2000:0:1:0:0/96]:80の場合、コマンドは次のようになります。curl http://[fd20:307:120c:2000:0:1:0:0]:80
追加の構成オプション
このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。これらは任意の順序で実行できます。
グローバル アクセスを有効にする
サンプルの内部パススルー ネットワーク ロードバランサのグローバル アクセスを有効にすると、すべてのリージョンのクライアントがアクセスできるようになります。サンプルのロードバランサのバックエンドは、引き続き 1 つのリージョン（us-west1）に配置する必要があります。
グローバル アクセスを構成するには、次の変更を行います。
Console
ロードバランサの転送ルールを編集する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
[名前] 列で、内部パススルー ネットワーク ロードバランサをクリックします。サンプルのロードバランサの名前は
be-ilbです。[フロントエンドの構成] をクリックします。
[編集] をクリックします。
[グローバル アクセス] で [有効] を選択します。
[完了] をクリックします。
[更新] をクリックします。
[ロードバランサの詳細] ページで、フロントエンドの構成がリージョン（REGION）で、グローバル アクセスが有効になっていることを確認します。
gcloud
サンプルのロードバランサの転送ルール
fr-ilbを更新して、--allow-global-accessフラグを含めます。gcloud compute forwarding-rules update fr-ilb \ --region=us-west1 \ --allow-global-access
forwarding-rules describeコマンドを使用すると、転送ルールでグローバル アクセスが有効になっているかどうかを確認できます。次に例を示します。gcloud compute forwarding-rules describe fr-ilb \ --region=us-west1 \ --format="get(name,region,allowGlobalAccess)"
グローバル アクセスが有効になっている場合、転送ルールの名前とリージョンの出力の後に
Trueという単語が表示されます。
API
forwardingRules/patch メソッドに PATCH リクエストを送信します。
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb
{
"allowGlobalAccess": true
}
VM クライアントを作成してグローバル アクセスをテストする
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
vm-client2に設定します。[リージョン] を
europe-west1に設定します。[ゾーン] を
europe-west1-bに設定します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network - サブネット:
europe-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは europe-west1-b ゾーンにあり、バックエンド VM と同じサブネットを使用しています。
gcloud compute instances create vm-client2 \
--zone=europe-west1-b \
--image-family=debian-12 \
--image-project=debian-cloud \
--tags=allow-ssh \
--subnet=europe-subnet
API
instances.insert メソッドに POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/europe-west1-b/instances
{
"name": "vm-client2",
"tags": {
"items": [
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/europe-west1-b/machineTypes/e2-standard-2",
"canIpForward": false,
"networkInterfaces": [
{
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/europe-west1/subnetworks/europe-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "vm-client2",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-image-name",
"diskType": "projects/PROJECT_ID/zones/europe-west1-b/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
],
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
VM クライアントに接続して接続性をテストする
接続をテストするには、次のコマンドを実行します。
gcloud compute ssh vm-client2 --zone=europe-west1-b
us-west1 リージョンの vm-client で実施したように、構成されたすべてのポートでロードバランサへの接続をテストします。転送ルールで構成された 4 つのポートで HTTP の接続性をテストします。
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
マネージド インスタンス グループを構成する
この構成例では、非マネージド インスタンス グループが作成されています。内部パススルー ネットワーク ロードバランサのバックエンドとして、代わりにマネージド インスタンス グループ（ゾーンまたはリージョンのマネージド インスタンス グループなど）を使用できます。
マネージド インスタンス グループを使用するには、インスタンス テンプレートを作成する必要があります。この例では、ゾーンの 2 つの非マネージド インスタンス グループを 1 つのリージョン マネージド インスタンス グループに置き換える方法を示しています。リージョンのマネージド インスタンス グループは、複数のゾーンに VM を自動的に作成し、ゾーン間での本番環境トラフィックの分散を容易にします。
マネージド インスタンス グループは、自動スケーリングと自動修復もサポートします。内部パススルー ネットワーク ロードバランサで自動スケーリングを使用する場合、ロード バランシングに基づいてスケーリングすることはできません。
この手順では、内部パススルー ネットワーク ロードバランサのバックエンド サービスを、リージョンのマネージド インスタンス グループを使用して変更する方法を示します。
コンソール
インスタンス テンプレート
Google Cloud コンソールで、[VM インスタンス テンプレート] ページに移動します。
[インスタンス テンプレートを作成] をクリックします。
[名前] を
template-vm-ilbに設定します。マシンタイプを選択します。
[ブートディスク] セクションで、ブートディスク オプションとして Debian GNU/Linux 12 (bookworm) が選択されていることを確認します。必要に応じて、[変更] をクリックしてイメージを変更します。
[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh」と「allow-health-check」を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network - サブネット:
lb-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[管理] をクリックし、[起動スクリプト] フィールドに次のスクリプトを入力します。
#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed[作成] をクリックします。
マネージド インスタンス グループ
Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
[インスタンス グループを作成] をクリックします。
[名前] を
ig-ilbに設定します。[ロケーション] で [マルチゾーン] を選択し、[リージョン] を
us-west1に設定します。[インスタンス テンプレート] を
template-vm-ilbに設定します。省略可: 自動スケーリングを構成します。インスタンス グループは内部パススルー ネットワーク ロードバランサのバックエンドであるため、HTTP ロード バランシングの使用に基づいたインスタンス グループの自動スケーリングはできません。
[インスタンスの最小数] を
1、[インスタンスの最大数] を6にそれぞれ設定します。省略可: 自動修復を構成します。自動修復を構成する場合、内部パススルー ネットワーク ロードバランサのバックエンド サービスで使用されるのと同じヘルスチェックを使用します。この例では、
hc-http-80.を使用します。[作成] をクリックします。
gcloud
インスタンス テンプレートを作成します。必要に応じて、その他のパラメータを設定します。たとえば、イメージ テンプレートには、マシンタイプを設定します。
gcloud compute instance-templates create template-vm-ilb \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check \ --subnet=lb-subnet \ --region=us-west1 \ --network=lb-network \ --metadata=startup-script='#! /bin/bash if [ -f /etc/startup_script_completed ]; then exit 0 fi apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl file_ports="/etc/apache2/ports.conf" file_http_site="/etc/apache2/sites-available/000-default.conf" file_https_site="/etc/apache2/sites-available/default-ssl.conf" http_listen_prts="Listen 80\nListen 8008\nListen 8080\nListen 8088" http_vh_prts="*:80 *:8008 *:8080 *:8088" https_listen_prts="Listen 443\nListen 8443" https_vh_prts="*:443 *:8443" vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html prt_conf="$(cat "$file_ports")" prt_conf_2="$(echo "$prt_conf" | sed "s|Listen 80|${http_listen_prts}|")" prt_conf="$(echo "$prt_conf_2" | sed "s|Listen 443|${https_listen_prts}|")" echo "$prt_conf" | tee "$file_ports" http_site_conf="$(cat "$file_http_site")" http_site_conf_2="$(echo "$http_site_conf" | sed "s|*:80|${http_vh_prts}|")" echo "$http_site_conf_2" | tee "$file_http_site" https_site_conf="$(cat "$file_https_site")" https_site_conf_2="$(echo "$https_site_conf" | sed "s|_default_:443|${https_vh_prts}|")" echo "$https_site_conf_2" | tee "$file_https_site" systemctl restart apache2 touch /etc/startup_script_completed'次のテンプレートを使用して、リージョンのマネージド インスタンス グループを 1 つ作成します。
gcloud compute instance-groups managed create ig-ilb \ --template=template-vm-ilb \ --region=us-west1 \ --size=6リージョンのマネージド インスタンス グループをバックエンドとして作成済みのバックエンド サービスに追加します。
gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-ilb \ --instance-group-region=us-west1ゾーンの 2 つの非マネージド インスタンス グループをバックエンド サービスから切断します。
gcloud compute backend-services remove-backend be-ilb \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-a gcloud compute backend-services remove-backend be-ilb \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-c
バックエンド VM から外部 IP アドレスを削除する
バックエンド VM を作成したときに、起動スクリプトを介して Apache をダウンロードできるように、それぞれにエフェメラル外部 IP アドレスが割り当てられました。バックエンド VM は、内部パススルー ネットワーク ロードバランサのみで使用されるため、外部 IP アドレスは削除できます。外部 IP アドレスを削除すると、バックエンド VM から直接インターネットにアクセスできなくなります。
コンソール
Google Cloud コンソールで、[VM インスタンス] ページに移動します。
各バックエンド VM に対して以下の手順を繰り返します。
バックエンド VM の名前（
vm-a1など）をクリックします。[編集] をクリックします。
[ネットワーク インターフェース] セクションで、ネットワークをクリックします。
[外部 IP] リストで [なし] を選択し、[完了] をクリックします。
[保存] をクリックします。
gcloud
インスタンスのゾーンを検索する。たとえば、リージョンのマネージド インスタンス グループを使用している場合、インスタンスごとに次のコマンドを実行してゾーンを判別します。
[SERVER-VM]を検索する VM の名前に置き換えます。gcloud compute instances list --filter="name=[SERVER-VM]"
各バックエンド VM に対して次の手順を繰り返します。
[SERVER-VM]を VM の名前、[ZONE]を VM のゾーンにそれぞれ置き換えます。gcloud compute instances delete-access-config [SERVER-VM] \ --zone=[ZONE] \ --access-config-name=external-nat
API
各バックエンド VM の instances.deleteAccessConfig メソッドに POST リクエストを送信します。vm-a1 は VM の名前、us-west1-a は VM のゾーンにそれぞれ置き換えます
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instances/vm-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None
予約済みの内部 IP アドレスを使用する
バックエンド VM とインスタンス グループを作成すると、VM インスタンスはエフェメラル内部 IPv4 または IPv6 アドレスを使用します。
以下の手順は、内部 IPv4 アドレスまたは IPv6 アドレスを静的内部 IPv4 アドレスまたは IPv6 アドレスに昇格させ、静的内部 IP アドレスを使用するように VM インスタンスを更新する方法を説明しています。
また別の方法として、次の手順は、新しい静的内部 IPv4 アドレスまたは IPv6 アドレスを予約してから、静的内部 IP アドレスを使用するように VM インスタンスを更新する方法を示しています。
新しい静的内部 IPv4 または IPv6 アドレスを予約する
内部 IPv4 の予約とは異なり、内部 IPv6 の予約では、サブネットワークからの特定の IP アドレスの予約をサポートしていません。代わりに、
/96の内部 IPv6 アドレス範囲は、サブネットの/64の内部 IPv6 アドレス範囲から自動的に割り振られます。
詳細については、静的内部 IP アドレスを予約する方法をご覧ください。
すべてのポートでトラフィックを受信する
ロードバランサがトラフィックを受け入れるポートは、バックエンド サービスではなくロードバランサの転送ルールによって決まります。各コンポーネントの目的については、コンポーネントをご覧ください。
このサンプルのロードバランサの転送ルールを作成したときに、ポート 80、8008、8080、8088 を構成しました。Apache をインストールする起動スクリプトでも、ポート 443 および 8443 で HTTPS 接続を受け入れるように構成されます。
この 6 つのポートをサポートするには、すべてのポートでトラフィックを受け入れるように転送ルールを構成します。この方法では、バックエンド VM への受信接続を許可するファイアウォール ルールを特定のポートのみを許可するように構成することもできます。
この手順では、ロードバランサの現在の転送ルールを削除し、すべてのポートでトラフィックを受け入れる新しいルールを作成する方法を示します。
このセットアップを使用するタイミングの詳細については、共通の IP アドレスを使用した内部パススルー ネットワーク ロードバランサと転送ルールをご覧ください。
コンソール
転送ルールを削除して新しいルールを作成する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
be-ilbロードバランサをクリックして、[編集] をクリックします。[フロントエンドの構成] をクリックします。
10.1.2.9転送ルールの上にポインタを置いて、[削除] をクリックします。[フロントエンド IP とポートの追加] をクリックします。
[新しいフロントエンドの IP とポート] セクションで、次の情報を入力して [完了] をクリックします。
- 名前:
fr-ilb - サブネットワーク:
lb-subnet - 内部 IP:
ip-ilb - ポート: すべて。
- 名前:
続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。
[確認と完了] をクリックして、ロードバランサの構成設定を確認します。
[作成] をクリックします。
gcloud
既存の転送ルール
fr-ilbを削除します。gcloud compute forwarding-rules delete fr-ilb \ --region=us-west1ポート構成でキーワード
ALLを使用する置換転送ルールを同じ名前で作成します。転送ルールのその他のパラメータは同じです。gcloud compute forwarding-rules create fr-ilb \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=ALL \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
forwardingRules.delete メソッドに DELETE リクエストを送信して転送ルールを削除します。
DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb
forwardingRules.insert メソッドに POST リクエストを送信して転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"allPorts": true,
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
すべてのポート設定でトラフィックをテストする
クライアント VM インスタンスに接続し、HTTP 接続と HTTPS 接続をテストします。
クライアント VM に接続します。
gcloud compute ssh vm-client --zone=us-west1-a
4 つのポートすべてで HTTP 接続をテストします。
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
ポート
443と8443で HTTPS 接続をテストします。セットアップ例の各 Apache サーバーは自己署名証明書を使用するため、--insecureフラグが必要です。curl https://10.1.2.99 --insecure curl https://10.1.2.99:8443 --insecure
HTTP リクエスト（4 つのポートすべて）と HTTPS リクエスト（両方のポート）がすべてのバックエンド VM に分散されることを確認します。
2 つの転送ルールを使用して複数のポートでトラフィックを受信する
このサンプルのロードバランサの転送ルールを作成したときに、ポート 80、8008、8080、8088 を構成しました。Apache をインストールする起動スクリプトでも、ポート 443 および 8443 で HTTPS 接続を受け入れるように構成されます。
すべてのポートでトラフィックを受け入れるように単一の転送ルールを構成するという戦略に代わる別の戦略では、それぞれ 5 つ以下のポートをサポートする複数の転送ルールを作成します。
この手順では、サンプルのロードバランサの転送ルールを 2 つの転送ルールに置き換える方法を示します。1 つはポート 80、8008、8080、8088 でトラフィックを処理し、もう 1 つはポート 443 および 8443 でトラフィックを処理します。
このセットアップを使用するタイミングの詳細については、共通の IP アドレスを使用した内部パススルー ネットワーク ロードバランサと転送ルールをご覧ください。
コンソール
Google Cloud コンソールで、[転送ルール] ページに移動します。
[名前] 列で、[
fr-ilb]、[削除] の順にクリックします。Google Cloud コンソールで [ロード バランシング] ページに移動します。
[名前] 列で [
be-ilb] をクリックします。[編集] をクリックします。
[フロントエンドの構成] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
[新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に「
fr-ilb-http」と入力します。 - [サブネットワーク] で [
lb-subnet] を選択します。 - [内部 IP の目的] で [共有] を選択します。
- [IP アドレス] リストで [IP アドレスを作成] を選択し、次の情報を入力して [予約] をクリックします。
- 名前:
internal-10-1-2-99 - 静的 IP アドレス: ユーザー指定
- カスタム IP アドレス:
10.1.2.99
- 名前:
- [ポート] で、[複数] を選択して、[ポート番号] に
80、8008、8080、8088を入力します。 - [完了] をクリックします。
- [名前] に「
[フロントエンド IP とポートの追加] をクリックします。
[新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に「
fr-ilb-https」と入力します。 - [サブネットワーク] で [
lb-subnet] を選択します。 - [内部 IP の目的] で [共有] を選択します。
- [IP アドレス] リストから [
internal-10-1-2-99] を選択します。 - [ポート] で [複数] を選択し、[ポート番号] に
443と8443を入力します。 - [完了] をクリックします。
- [名前] に「
[確認と完了] をクリックして、ロードバランサの構成設定を確認します。
[更新] をクリックします。
gcloud
既存の転送ルール
fr-ilbを削除します。gcloud compute forwarding-rules delete fr-ilb \ --region=us-west110.1.2.99の静的（予約済み）内部 IP アドレスを作成し、その--purposeフラグをSHARED_LOADBALANCER_VIPに設定します。2 つの内部転送ルールが同じ内部 IP アドレスを使用できるようにするには、--purposeフラグが必要です。gcloud compute addresses create internal-10-1-2-99 \ --region=us-west1 \ --subnet=lb-subnet \ --addresses=10.1.2.99 \ --purpose=SHARED_LOADBALANCER_VIP- 次のパラメータを使用して 2 つの置換転送ルールを作成します。
gcloud compute forwarding-rules create fr-ilb-http \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=80,8008,8080,8088 \ --backend-service=be-ilb \ --backend-service-region=us-west1gcloud compute forwarding-rules create fr-ilb-https \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=lb-subnet \ --address=10.1.2.99 \ --ip-protocol=TCP \ --ports=443,8443 \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
forwardingRules.delete メソッドに DELETE リクエストを送信して転送ルールを削除します。
DELETE https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules/fr-ilb
10.1.2.99 の静的（予約済み）内部 IP アドレスを作成し、addresses.insert メソッドに POST リクエストを送信してそのアドレスの目的を SHARED_LOADBALANCER_VIP に設定します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/addresses
{
"name": "internal-10-1-2-99",
"address": "10.1.2.99",
"prefixLength": 32,
"addressType": INTERNAL,
"purpose": SHARED_LOADBALANCER_VIP,
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet"
}
forwardingRules.insert メソッドに 2 つの POST リクエストを送信して、2 つの転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb-http",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80", "8008", "8080", "8088"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
{
"name": "fr-ilb-https",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"443", "8443"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
複数のポート設定でトラフィックをテストする
クライアント VM インスタンスに接続し、HTTP 接続と HTTPS 接続をテストします。
クライアント VM に接続します。
gcloud compute ssh vm-client --zone=us-west1-a
4 つのポートすべてで HTTP 接続をテストします。
curl http://10.1.2.99 curl http://10.1.2.99:8008 curl http://10.1.2.99:8080 curl http://10.1.2.99:8088
ポート
443と8443で HTTPS 接続をテストします。セットアップ例の各 Apache サーバーは自己署名証明書を使用するため、--insecureフラグが必要です。curl https://10.1.2.99 --insecure curl https://10.1.2.99:8443 --insecure
HTTP リクエスト（4 つのポートすべて）と HTTPS リクエスト（両方のポート）がすべてのバックエンド VM に分散されることを確認します。
セッション アフィニティを使用する
構成例では、バックエンド サービスをセッション アフィニティなしで作成しています。
この手順では、クライアントの IP アドレスとロードバランサの内部転送ルールの IP アドレスから作成されたハッシュに基づくセッション アフィニティを使用するように、サンプルの内部パススルー ネットワーク ロードバランサのバックエンド サービスを更新する方法を示します。
サポートされているセッション アフィニティのタイプについては、セッション アフィニティのオプションをご覧ください。
コンソール
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
[be-ilb]（この例で作成したバックエンド サービスの名前）をクリックして、[編集] をクリックします。
[Edit internal passthrough Network Load Balancer] ページで、[バックエンドの構成] をクリックします。
[セッション アフィニティ] リストから [クライアント IP] を選択します。
[更新] をクリックします。
gcloud
クライアント IP セッション アフィニティを指定して、be-ilb バックエンド サービスを更新するには、次の gcloud コマンドを使用します。
gcloud compute backend-services update be-ilb \
--region=us-west1 \
--session-affinity CLIENT_IP
API
regionBackendServices/patch メソッドに PATCH リクエストを送信します。
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb
{
"sessionAffinity": "CLIENT_IP"
}
接続トラッキング ポリシーを構成する
このセクションでは、バックエンド サービスを更新してロードバランサのデフォルトの接続トラッキング ポリシーを変更する方法について説明します。
接続トラッキング ポリシーには次の設定が含まれます。
gcloud
次の gcloud compute
backend-services コマンドを使用して、バックエンド サービスの接続トラッキング ポリシーを更新します。
gcloud compute backend-services update BACKEND_SERVICE \
--region=REGION \
--tracking-mode=TRACKING_MODE \
--connection-persistence-on-unhealthy-backends=CONNECTION_PERSISTENCE_BEHAVIOR \
--idle-timeout-sec=IDLE_TIMEOUT_VALUE
プレースホルダを有効な値に置き換えます。
BACKEND_SERVICE: 更新するバックエンド サービスREGION: 更新するバックエンド サービスのリージョンTRACKING_MODE: 受信パケットに使用される接続トラッキング モード。サポートされている値の一覧については、トラッキング モードをご覧ください。CONNECTION_PERSISTENCE_BEHAVIOR: バックエンドが異常な場合の接続の永続性の動作。サポートされている値の一覧については、異常なバックエンドでの接続の永続性をご覧ください。IDLE_TIMEOUT_VALUE: ロードバランサがエントリに一致する最後のパケットを処理した後で、接続トラッキング テーブルのエントリが維持される秒数このプロパティを変更できるのは、接続トラッキングが 5 タプル未満の場合（セッション アフィニティが
CLIENT_IPかCLIENT_IP_PROTOのいずれかで、トラッキング モードがPER_SESSIONの場合）です。デフォルト値は 600 秒（10 分）です。構成可能なアイドル タイムアウトの最大値は 57,600 秒（16 時間）です。
別のサブネットで転送ルールを作成する
この手順では、1 つの内部パススルー ネットワーク ロードバランサに対して複数の転送ルールを作成できることを示すために、2 つ目の IP アドレスと転送ルールを別のサブネットに作成します。転送ルールのリージョンは、バックエンド サービスのリージョンと一致する必要があります。
ファイアウォール ルールに従うと、リージョン内のサブネット内のクライアントは、内部パススルー ネットワーク ロードバランサの IP アドレスに接続できます。
コンソール
2 番目のサブネットを追加する
Google Cloud コンソールで、[VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[
lb-network] をクリックします。[サブネット] セクションで、次の操作を行います。
- [サブネットを追加] をクリックします。
- [新しいサブネット] セクションに、次の情報を入力します。
- 名前:
second-subnet - リージョン:
us-west1 - IP アドレス範囲:
10.5.6.0/24
- 名前:
- [追加] をクリックします。
2 番目の転送ルールを追加する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
be-ilbロードバランサをクリックして、[編集] をクリックします。[フロントエンドの構成] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
[新しいフロントエンドの IP とポート] セクションで、次のフィールドを設定して [完了] をクリックします。
- 名前:
fr-ilb-2 - IP バージョン: IPv4
- サブネットワーク:
second-subnet - 内部 IP:
ip-ilb - ポート:
80と443
- 名前:
続行する前に、[フロントエンドの構成] の隣に青いチェックマークがあることを確認します。
[確認と完了] をクリックして、ロードバランサの構成設定を確認します。
[作成] をクリックします。
gcloud
us-west1リージョン内のlb-networkネットワークに 2 つ目のサブネットを作成します。gcloud compute networks subnets create second-subnet \ --network=lb-network \ --range=10.5.6.0/24 \ --region=us-west1
ポート 80 と 443 に 2 つ目の転送ルールを作成します。IP アドレスやバックエンド サービスなど、このルールのその他のパラメータは、プライマリ転送ルール
fr-ilbと同じです。gcloud compute forwarding-rules create fr-ilb-2 \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=second-subnet \ --address=10.5.6.99 \ --ip-protocol=TCP \ --ports=80,443 \ --backend-service=be-ilb \ --backend-service-region=us-west1
API
subnetworks.insert メソッドに POST リクエストを送信します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks
{
"name": "second-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"ipCidrRange": "10.5.6.0/24",
"privateIpGoogleAccess": false
}
forwardingRules.insert メソッドに POST リクエストを送信して転送ルールを作成します。
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/forwardingRules
{
"name": "fr-ilb-2",
"IPAddress": "10.5.6.99",
"IPProtocol": "TCP",
"ports": [
"80", "443"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
新しい転送ルールをテストする
クライアント VM インスタンスに接続し、IP アドレスへの HTTP 接続と HTTPS 接続をテストします。
クライアント VM に接続します。
gcloud compute ssh vm-client --zone=us-west1-a
IP アドレスへの HTTP 接続をテストします。
curl http://10.1.2.99 curl http://10.5.6.99
HTTPS 接続をテストします。サンプル設定の Apache サーバー構成では自己署名証明書を使用するため、
--insecureを使用する必要があります。curl https://10.1.2.99 --insecure curl https://10.5.6.99 --insecure
リクエストは、使用されているプロトコル（HTTP または HTTPS）や IP アドレスに関係なく、すべてのバックエンド VM で処理されることを確認してください。
バックエンドのサブセット化を使用する
構成例では、バックエンド サービスがサブセット化されていません。
この手順では、内部パススルー ネットワーク ロードバランサのバックエンド サービスでサブセット化を有効にして、より多くのバックエンド インスタンスにスケーリングできるようにする方法を示します。
1 つのロードバランサで 250 台を超えるバックエンド VM をサポートする必要がある場合にのみ、サブセット化を有効にしてください。
このユースケースの詳細については、バックエンドのサブセット化をご覧ください。
gcloud
次の gcloud コマンドを使用して、be-ilb バックエンド サービスを更新し、サブセット ポリシーを指定します。
gcloud compute backend-services update be-ilb \
--subsetting-policy=CONSISTENT_HASH_SUBSETTING
API
regionBackendServices/patch メソッドに PATCH リクエストを送信します。
PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/be-ilb
{
"subsetting":
{
"policy": CONSISTENT_HASH_SUBSETTING
}
}
Packet Mirroring 用のロードバランサを作成する
Packet Mirroring によって、VPC 内の特定のインスタンスからパケットデータをコピーして収集できます。収集されたデータを使用して、セキュリティの脅威の検出とアプリケーション パフォーマンスのモニタリングに役立てることができます。
Packet Mirroring には、コレクタ宛先のインスタンス グループにトラフィックを分散するために内部パススルー ネットワーク ロードバランサが必要です。Packet Mirroring 用に内部パススルー ネットワーク ロードバランサを作成する手順は次のとおりです。
コンソール
構成を開始する
Google Cloud コンソールで [ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ（TCP / UDP / SSL）] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [パススルー ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- [ロードバランサの名前] に名前を入力します。
- [リージョン] で、パケットをミラーリングする VM インスタンスのリージョンを選択します。
- [ネットワーク] で、パケットをミラーリングするネットワークを選択します。
- [バックエンドの構成] をクリックします。
- [新しいバックエンド] セクションの [インスタンス グループ] で、パケットの転送先となるインスタンス グループを選択します。
- [ヘルスチェック] リストから [ヘルスチェックを作成] を選択し、次の情報を入力して [保存] をクリックします。
- [名前] に、ヘルスチェックの名前を入力します。
- [プロトコル] で [
HTTP] を選択します。 - [ポート] に「
80」と入力します。
- [フロントエンドの構成] をクリックします。
- [新しいフロントエンドの IP とポート] セクションで、次の操作を行います。
- [名前] に名前を入力します。
- [サブネットワーク] で、ミラーリングするインスタンスと同じリージョン内のサブネットワークを選択します。
- [ポート] で [すべて] を選択します。
- [高度な構成] をクリックし、[このロードバランサを Packet Mirroring 用に有効にする] チェックボックスをオンにします。
- [完了] をクリックします。
- [作成] をクリックします。
gcloud
新しいリージョン HTTP ヘルスチェックを作成して、ポート 80 でインスタンス グループへの HTTP 接続をテストします。
gcloud compute health-checks create http HEALTH_CHECK_NAME \ --region=REGION \ --port=80次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェックの名前。REGION: パケットをミラーリングする VM インスタンスのリージョン。
HTTP トラフィックのバックエンド サービスを作成します。
gcloud compute backend-services create COLLECTOR_BACKEND_SERVICE \ --region=REGION \ --health-checks-region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --load-balancing-scheme=internal \ --protocol=tcp次のように置き換えます。
COLLECTOR_BACKEND_SERVICE: バックエンド サービスの名前。REGION: パケットをミラーリングする VM インスタンスのリージョン。HEALTH_CHECK_NAME: ヘルスチェックの名前。
バックエンド サービスにインスタンス グループを追加します。
gcloud compute backend-services add-backend COLLECTOR_BACKEND_SERVICE \ --region=REGION \ --instance-group=INSTANCE_GROUP \ --instance-group-zone=ZONE次のように置き換えます。
COLLECTOR_BACKEND_SERVICE: バックエンド サービスの名前。REGION: インスタンス グループのリージョン。INSTANCE_GROUP: インスタンス グループの名前。ZONE: インスタンス グループのゾーン。
バックエンド サービスの転送ルールを作成します。
gcloud compute forwarding-rules create FORWARDING_RULE_NAME \ --region=REGION \ --network=NETWORK \ --subnet=SUBNET \ --backend-service=COLLECTOR_BACKEND_SERVICE \ --load-balancing-scheme=internal \ --ip-protocol=TCP \ --ports=all \ --is-mirroring-collector次のように置き換えます。
FORWARDING_RULE_NAME: 転送ルールの名前。REGION: 転送ルールのリージョン。NETWORK: 転送ルールのネットワーク。SUBNET: パケットをミラーリングする VM のリージョンのサブネットワーク。COLLECTOR_BACKEND_SERVICE: このロードバランサのバックエンド サービス。
次のステップ
- 基礎知識については、内部パススルー ネットワーク ロードバランサの概要をご覧ください。
- フェイルオーバーに関する重要な情報については、内部パススルー ネットワーク ロードバランサのフェイルオーバーのコンセプトをご覧ください。
- ロードバランサで使用できる DNS 名オプションについては、内部ロード バランシングと DNS 名をご覧ください。
- 内部パススルー ネットワーク ロードバランサのフェイルオーバーの構成の手順と例については、内部パススルー ネットワーク ロードバランサのフェイルオーバーの構成をご覧ください。
- 内部パススルー ネットワーク ロードバランサの Logging と Monitoring の構成については、内部パススルー ネットワーク ロードバランサのロギングとモニタリングをご覧ください。
- VPC ネットワークに接続されたピア ネットワークから内部パススルー ネットワーク ロードバランサにアクセスする方法については、内部パススルー ネットワーク ロードバランサと接続ネットワークをご覧ください。
- 内部パススルー ネットワーク ロードバランサの問題をトラブルシューティングする方法については、内部パススルー ネットワーク ロードバランサのトラブルシューティングをご覧ください。
- ロードバランサの設定をクリーンアップする。
付録: IPv6 Bash スクリプトの基礎知識
このセクションでは、バックエンド VM に IPv6 TCP サーバーをインストールするために使用される Bash 起動スクリプトに関連するさまざまなネットワーキング コマンドについて簡単に説明します。これらの手順を再度実行する必要はありません。ここに記載されている内容は、コンテキストを示すため、理解を深めるために記載されています。
すべての IPv6 ルートを表示します。
ip -6 route show table all
出力は次のとおりです。
fd20:307:120c:2000::/64 via fe80::57:2ff:fe36:ffbe dev ens4 proto ra metric 100 expires 62sec pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium default via fe80::57:2ff:fe36:ffbe dev ens4 proto ra metric 100 expires 62sec mtu 1460 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fd20:307:120c:2000:0:b:: dev ens4 table local proto kernel metric 0 pref medium local fe80::56:24ff:feb1:59b3 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
前の手順の出力から、次の情報を特定します。
- リンクローカル IPv6 アドレス（fe80::/10 で始まる）: 出力例のリンクローカル アドレスは fe80::57:2ff:fe36:ffbe です。このリンクローカル アドレスは、ルーティング テーブル 1 で定義されるデフォルト ルートで使用されます。このデフォルト ルートは手順 2 で作成します。
- /64 サブネット: このサブネットは、ステップ 3 のソースベースのポリシー ルーティング ルールで参照されます。
ルーティング テーブル 1 にカスタム デフォルト ルートを追加します。
次のコマンドは、
ens4という名前のネットワーク インターフェースを使用して、ゲートウェイにパケットを送信します。sudo ip route add default via GATEWAY_ADDRESS dev ens4 table 1
このコマンドを実行すると、デフォルト ルートがカスタム ルーティング テーブル（テーブル 1）に追加され、ens4 インターフェースを介してゲートウェイ
fe80::57:2ff:fe36:ffbeを参照します。ip -6 route show table allコマンドを再度実行すると、出力は次のようになります。default via fe80::57:2ff:fe36:ffbe dev ens4 table 1 metric 1024 pref medium fd20:307:120c:2000::/64 via fe80::57:2ff:fe36:ffbe dev ens4 proto ra metric 100 expires 89sec pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium default via fe80::57:2ff:fe36:ffbe dev ens4 proto ra metric 100 expires 89sec mtu 1460 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fd20:307:120c:2000:0:1::/96 dev ens4 table local proto 66 metric 1024 pref medium local fd20:307:120c:2000:0:b:: dev ens4 table local proto kernel metric 0 pref medium local fe80::56:24ff:feb1:59b3 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
ソースに基づくポリシー ルーティング ルールを追加します。
次のコマンドは、指定されたサブネットから送信されるすべてのパケットを転送するルールを追加します。送信元アドレスがサブネットと一致する場合、システムはテーブル 1 で定義されたデフォルト ルートを使用してトラフィックを転送します。
sudo ip -6 rule add from SUBNET_RANGE table 1
ポリシー ルーティング ルールのリストを表示するには、次のコマンドを実行します。
ip -6 rule show
出力は次のとおりです。
0: from all lookup local 32765: from fd20:307:120c:2000::/64 lookup 1 32766: from all lookup main
from fd20:... lookup 1を含む行は、追加したルールです。このルールは、そのサブネットから発信されるトラフィックにルーティング テーブル 1 を使用するようにカーネルに指示します。サーバーがローカル以外の IPv6 アドレス（ロードバランサの VIP）にバインドできるようにします。
sudo sysctl -w net.ipv6.ip_nonlocal_bind=1