内部 TCP / UDP 負荷分散の設定

このガイドでは、サンプルを示しながら、Google Cloud の内部 TCP / UDP 負荷分散の基礎について解説します。このガイドに進む前に、次の内容を理解しておいてください。

• 内部 TCP / UDP 負荷分散のコンセプト
• ファイアウォール ルールの概要
• ヘルスチェックのコンセプト

権限

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

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

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

• アクセス制御
• IAM の条件

設定

このガイドでは、内部 TCP / UDP ロードバランサの構成とテストの方法を説明します。このセクションでは、以下の構成方法について説明します。

1. カスタム サブネットを持つ VPC ネットワークのサンプル
2. バックエンド VM への受信接続を許可するファイアウォール ルール
3. 4 つのバックエンド VM :
   • ゾーン us-west1-a の非マネージド インスタンス グループ内の 2 つの VM
   • ゾーン us-west1-c の非マネージド インスタンス グループ内の 2 つの VM
4. 接続のテストに使用する 1 台のクライアント VM
5. 次の内部 TCP / UDP ロードバランサ コンポーネント:
   • バックエンド サービスのヘルスチェック
   • us-west1 リージョンの内部バックエンド サービス。2 つのゾーン インスタンス グループへの接続分散を管理します。
   • ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

この例のアーキテクチャは次のようになります。

内部 TCP / UDP 負荷分散の構成例（クリックして拡大）

注: この例では、非マネージド インスタンス グループを使用しています。本番環境では、マネージド インスタンス グループに示すような、マネージド インスタンス グループを使用します。

ネットワーク、リージョン、サブネットを構成する

このページで説明されているサンプルの内部 TCP / UDP ロードバランサは、lb-network という名前のカスタムモード VPC ネットワークで作成されています。

この例のバックエンド VM とロードバランサのコンポーネントは、次のリージョンとサブネットに存在します。

• リージョン: us-west1
• サブネット: lb-subnet（プライマリ IP アドレス範囲は 10.1.2.0/24）

グローバル アクセスを示すために、この例では別のリージョンとサブネットに 2 つ目のテスト クライアント VM を作成します。

• リージョン: europe-west1
• サブネット: europe-subnet（プライマリ IP アドレス範囲は 10.3.4.0/24）

注: サブネットのネットワーク、リージョン、パラメータの名前は変更できます。ただし、このガイドの以降の手順では、上に示したネットワーク、リージョン、サブネットの各パラメータを使用します。

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

Console

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

gcloud

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

   gcloud compute networks create lb-network --subnet-mode=custom
   

   1. lb-network ネットワーク内に、us-west1 リージョンのバックエンド用のサブネットと、europe-west1 リージョンのグローバル アクセスをテストするための別のサブネットを作成します。

   gcloud compute networks subnets create lb-subnet \
       --network=lb-network \
       --range=10.1.2.0/24 \
       --region=us-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 プローブ システムの IP 範囲からのヘルスチェックを許可するには、ファイアウォール ルールを作成する必要があります。詳細については、プローブの IP 範囲をご覧ください。

Console

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

gcloud

1. 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
   

2. ネットワーク タグ 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:22
   

3. Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。

   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 つの非マネージド インスタンスを使用しています。内部 TCP / UDP 負荷分散のリージョン特性を示すために、2 つのインスタンス グループが別々のゾーン（us-west1-a と us-west1-c）に配置されています。

• インスタンス グループ ig-a には、次の 2 つの VM が含まれています。
  • vm-a1
  • vm-a2
• インスタンス グループ ig-c には、次の 2 つの VM が含まれています。
  • vm-c1
  • vm-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 アドレスにバインドされます。内部 TCP / UDP ロードバランサは、宛先 IP を保持してパケットを配信します。バックエンド VM で実行中のサーバー ソフトウェアが、ロードバランサの内部転送ルールの IP アドレスをリッスンしていることを確認してください。複数の内部転送ルールを設定している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部 TCP / UDP ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。

説明を簡単にするため、これらのバックエンド VM では Debian GNU/Linux 10 を実行します。

Console

バックエンド VM の作成

1. Google Cloud Console で、[VM インスタンス] ページに移動します。
   [VM インスタンス] に移動
2. 次の手順を繰り返し、4 つの VM を作成します。次の名前とゾーンの組み合わせを使用します。
   • 名前: vm-a1、ゾーン: us-west1-a
   • 名前: vm-a2、ゾーン: us-west1-a
   • 名前: vm-c1、ゾーン: us-west1-c
   • 名前: vm-c2、ゾーン: us-west1-c
3. [インスタンスを作成] をクリックします。
4. ステップ 2 に示したように [名前] を設定します。
5. [リージョン] には、us-west1 を選択し、手順 2 に示したゾーンを選択します。
6. [ブートディスク] セクションで、ブートディスク オプションに Debian オペレーティング システムと 10 (buster) バージョンが選択されていることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。

7. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。

   • [ネットワーク] をクリックして、ネットワーク タグ allow-ssh と allow-health-check を追加します。
   • [ネットワーク インターフェース] にある編集ボタン をクリックして、次の変更を行い、[完了] をクリックします。
     • ネットワーク: lb-network
     • サブネット: lb-subnet
     • プライマリ内部 IP: エフェメラル（自動）
     • 外部 IP: エフェメラル

   • [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。スクリプトの内容は 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://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     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
     

8. [作成] をクリックします。

インスタンス·グループの作成

1. Google Cloud Console で、[インスタンス グループ] ページに移動します。
   [インスタンス グループ] に移動
2. 次の手順を繰り返し、それぞれ 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下の組み合わせを使用します。
   • インスタンス グループ: ig-a、ゾーン: us-west1-a、VM: vm-a1 と vm-a2
   • インスタンス グループ: ig-c、ゾーン: us-west1-c、VM: vm-c1 と vm-c2
3. [インスタンス グループを作成] をクリックします。
4. [新しい非マネージド インスタンス グループ] をクリックします。
5. ステップ 2 に示したように [名前] を設定します。
6. [ロケーション] セクションで、[リージョン] に us-west1 を選択し、ステップ 2 で示したように [ゾーン] を選択します。
7. [ネットワーク] に「lb-network」と入力します。
8. [サブネットワーク] に「lb-subnet」と入力します。
9. [VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
10. [作成] をクリックします。

gcloud

1. 次の [VM-NAME] と [ZONE] の 4 つの組み合わせを使用して、下のコマンドを 4 回実行して 4 つの VM を作成します。スクリプトの内容は 4 つの VM ですべて同じです。

   • vm-a1 の [VM-NAME] と us-west1-a の [ZONE]
   • vm-a2 の [VM-NAME] と us-west1-a の [ZONE]
   • vm-c1 の [VM-NAME] と us-west1-c の [ZONE]
   • vm-c2 の [VM-NAME] と us-west1-c の [ZONE]

   gcloud compute instances create [VM-NAME] \
       --zone=[ZONE] \
       --image-family=debian-10 \
       --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://169.254.169.254/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. 各ゾーンに次の 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
   

3. 適切なインスタンス グループに 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-a1 の [VM-NAME] と us-west1-a の [ZONE]
• vm-a2 の [VM-NAME] と us-west1-a の [ZONE]
• vm-c1 の [VM-NAME] と us-west1-c の [ZONE]
• vm-c2 の [VM-NAME] と us-west1-c の [ZONE]

現在の DEBIAN_IMAGE_NAME を取得するには、次の gcloud コマンドを実行します。

gcloud compute images list \
 --filter="family=debian-10"

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://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",
  "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"
    }
  ]
}

クライアント VM の作成

この例では、クライアント VM（vm-client）を、バックエンド（サーバー）VM と同じリージョンに作成します。クライアントを使用するのは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すためです。

Console

1. Google Cloud Console で、[VM インスタンス] ページに移動します。
   [VM インスタンス] に移動
2. [インスタンスを作成] をクリックします。
3. [名前] を vm-client に設定します。
4. [ゾーン] を us-west1-a に設定します。
5. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
   • [ネットワーキング] をクリックして allow-ssh を ネットワーク タグに追加します。
   • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
     • ネットワーク: lb-network
     • サブネット: lb-subnet
     • プライマリ内部 IP: エフェメラル（自動）
     • 外部 IP: エフェメラル
6. [作成] をクリックします。

gcloud

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

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-10 \
    --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
}

ロードバランサのコンポーネントを構成する

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

• ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP 200（OK）レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。

• バックエンド サービス: 内部ロードバランサを介して HTTP トラフィックを渡す必要があるため、UDP ではなく TCP を使用する必要があります。

• 転送ルール: この例では、内部転送ルールを 1 つ作成します。

• 内部 IP アドレス: この例では、転送ルールを作成する際に、内部 IP アドレス 10.1.2.99 を指定しています。

Console

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

1. Google Cloud Console で、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. [ロードバランサを作成] をクリックします。
3. [TCP 負荷分散] で [構成を開始] をクリックします。
4. [インターネット接続または内部専用] で [VM 間のみ] を選択します。
5. [続行] をクリックします。
6. [名前] を be-ilb に設定します。
7. [バックエンドの構成] をクリックして、次の変更を行います。
   1. リージョン: us-west1
   2. ネットワーク: lb-network
   3. [バックエンド] の [新しいバックエンド] セクションで、ig-a インスタンス グループを選択し、[完了] をクリックします。
   4. [バックエンドを追加] をクリックします。[New backends] セクションが表示されたら、ig-c インスタンス グループを選択して、[完了] をもう一度クリックします。
   5. [ヘルスチェック] で、[ヘルスチェックの作成] を選択し、次の情報を入力して、保存をクリックします。
      • 名前: hc-http-80
      • プロトコル: HTTP
      • ポート: 80
      • プロキシ プロトコル: NONE
      • リクエストパス: /。Cloud Console を使用してロードバランサを作成すると、ヘルスチェックはグローバルになります。リージョン ヘルスチェックを作成する場合は、gcloud または API を使用します。
   6. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
8. [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
   1. 名前: fr-ilb
   2. サブネットワーク: lb-subnet
   3. [内部 IP] で [IP アドレスを作成] を選択し、次の情報を入力して [予約] をクリックします。
      • 名前: ip-ilb
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.1.2.99
   4. ポート: [複数] を選択して、ポート番号に「80,8008,8080,8088」と入力します。
   5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
9. [確認と完了] をクリックします。すべての設定を確認します。
10. [作成] をクリックします。

gcloud

1. 新しいリージョン HTTP ヘルスチェックを作成して、ポート 80 で VM との HTTP 接続をテストします。

   gcloud compute health-checks create http hc-http-80 \
       --region=us-west1 \
       --port=80
   

2. HTTP トラフィックのバックエンド サービスを作成します。

   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
   

3. バックエンド サービスに、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
   

4. バックエンド サービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の内部 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 からロードバランサに接続します。セッション アフィニティが設定されていないため、トラフィックは 4 つのバックエンド VM に分散されます。

1. クライアント VM インスタンスに接続します。

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

2. 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 を実行することはできません。このテストではこの想定される動作が示されます。これは、内部 TCP / UDP ロードバランサが、別々のデバイスではなく、仮想ネットワーク プログラミングで実装されているためです。

1. クライアント VM インスタンスに接続します。

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

2. ロードバランサの IP アドレスに対して ping を試行します。レスポンスが返されず、ping コマンドがこの例では 10 秒後にタイムアウトすることに注意してください。

   timeout 10 ping 10.1.2.99
   

負荷分散された VM からのリクエストの送信

このテストでは、ロードバランスされているサーバー VM のバックエンド VM からのロードバランサへのリクエストが、デフォルトでは常に同じ VM によって応答されることが示されます。

内部 TCP / UDP 負荷分散は、ゲスト OS の仮想ネットワーク プログラミングと VM 構成を使用して実装されます。Linux VM では、Linux ゲスト環境によってゲスト OS ルーティング テーブルにルートをインストールしてローカル構成が実行されます。ローカルルートのため、ロードバランサの IP アドレスへのトラフィックは、負荷分散された VM 自体に残ります。（このローカルルートは VPC ネットワークのルートとは異なるルートです。）

注意: 負荷分散されている VM から内部 TCP / UDP ロードバランサへのリクエストは（そのロードバランサのバックエンド サービスでは）使用できません。リクエストは常にリクエストを処理する VM に送信され、ヘルスチェック情報は無視されます。さらに、バックエンドにより、ロードバランサの内部転送ルールで構成されたもの以外のプロトコルと宛先ポートを使用して送信されたトラフィックに対する応答がなされます。

1. バックエンド VM に接続します（たとえば、vm-a1）。

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

   重要: 外部 IP アドレスを削除した場合は、この方法でバックエンド VM に接続することはできません。バックエンド VM に外部 IP アドレスが割り当てられない場合の接続オプションについては、外部 IP アドレスを持たないインスタンスに接続するをご覧ください。

2. IP アドレスまたはサービス名を指定し curl を使用して、ロードバランサにウェブリ クエストを送信します。リクエストを繰り返します。その際、リクエストを処理するバックエンド VM からレスポンスが送信されることに注意してください。vm-a1 からテストするときに想定される応答は常に次のとおりです。 Page served from: vm-a1

   curl http://10.1.2.99
   

3. ローカルのルーティング テーブルを調べて、ロードバランサ自体の IP アドレス（10.1.2.99）に一致する宛先を探します。このルートは内部 TCP / UDP 負荷分散に必須の部分です。これにより、ロードバランサの背後にある VM からのリクエストが常に同じ VM によって応答される理由がわかります。

   ip route show table local | grep 10.1.2.99
   

リクエストを送信するバックエンド VM に、ネクストホップの宛先が独自の負荷分散された IP アドレスである --next-hop-ilb ルートがある場合、このデフォルト動作は適用されません。ルートで指定された IP アドレスを VM がターゲットにすると、別の負荷分散された VM がリクエストに応答できます。

たとえば、--next-hop-ilb が 10.20.1.1 である、192.168.1.0/24 の宛先ルートを作成できます。

これで、ロードバランサの背後にある VM は、192.168.1.1 をターゲットにできます。このアドレスは、ローカルのルーティング テーブルに存在しないため、Google Cloud ルートが適用されるように VM に送信されます。優先度の高い該当する他のルートがなければ、--next-hop-ilb ルートが選択されます。

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

追加の構成オプション

このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。

グローバル アクセスの有効化

サンプルの内部 TCP / UDP ロードバランサのグローバル アクセスを有効にすると、すべてのリージョンのクライアントがアクセスできるようになります。サンプルのロードバランサのバックエンドは、引き続き 1 つのリージョン（us-west1）に配置する必要があります。

グローバル アクセスを構成した内部 TCP / UDP 負荷分散（クリックして拡大）

グローバル アクセスを構成するには、次の変更を行います。

Console

ロードバランサの転送ルールを編集する

1. Google Cloud Console で、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動

2. [名前] 列で、内部 TCP / UDP ロードバランサをクリックします。サンプルのロードバランサの名前は be-ilb です。

3. [フロントエンドの構成] をクリックします。

4. [編集] をクリックします。

5. [グローバル アクセス] で [有効] を選択します。

6. [完了] をクリックします。

7. [更新] をクリックします。

[ロードバランサの詳細] ページで、フロントエンドの構成がリージョン（REGION）で、グローバル アクセスが有効になっていることを確認します。

gcloud

1. サンプルのロードバランサの転送ルール fr-ilb を更新して、--allow-global-access フラグを含めます。

   gcloud compute forwarding-rules update fr-ilb \
      --region=us-west1 \
      --allow-global-access
   

2. 転送ルールでグローバル アクセスが許可されていることを確認します。

   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 クライアントを作成してグローバル アクセスをテストする

Console

1. Google Cloud Console で、[VM インスタンス] ページに移動します。
   [VM インスタンス] に移動
2. [インスタンスを作成] をクリックします。
3. [名前] を vm-client2 に設定します。
4. [ゾーン] を europe-west1-b に設定します。
5. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
   • [ネットワーキング] をクリックして allow-ssh を ネットワーク タグに追加します。
   • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
     • ネットワーク: lb-network
     • サブネット: europe-subnet
     • プライマリ内部 IP: エフェメラル（自動）
     • 外部 IP: エフェメラル
6. [作成] をクリックします。

gcloud

クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは europe-west1-b ゾーンにあり、バックエンド VM と同じサブネットを使用しています。

gcloud compute instances create vm-client2 \
    --zone=europe-west1-b \
    --image-family=debian-10 \
    --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

マネージド インスタンス グループを構成する

この構成例では、非マネージド インスタンス グループが作成されています。内部 TCP / UDP 負荷分散のバックエンドとして、マネージド インスタンス グループ（ゾーンまたはリージョンのマネージド インスタンス グループなど）を使用できます。

マネージド インスタンス グループを使用するには、インスタンス テンプレートを作成する必要があります。この例では、ゾーンの 2 つの非マネージド インスタンス グループを 1 つのリージョン マネージド インスタンス グループに置き換える方法を示しています。リージョンのマネージド インスタンス グループは、複数のゾーンに VM を自動的に作成し、ゾーン間での本番環境トラフィックの分散を容易にします。

インスタンス グループにバックエンド サービスを定義し、ポート名を適切なポートにマッピングできます。ロード バランシング サービスは、名前付きポートにトラフィックを転送します。

マネージド インスタンス グループは、自動スケーリングと自動修復もサポートします。内部 TCP / UDP 負荷分散で自動スケーリングを使用する場合、負荷分散に基づいてスケーリングすることはできません。

この手順では、内部 TCP / UDP ロードバランサのバックエンド サービスを、リージョンのマネージド インスタンス グループを使用して変更する方法を示します。

Console

インスタンス テンプレート

1. Google Cloud Console で、[VM インスタンス テンプレート] ページに移動します。
   VM インスタンス テンプレートに移動
2. [インスタンス テンプレートを作成] をクリックします。
3. [名前] を template-vm-ilb に設定します。
4. マシンタイプを選択します。
5. ブートディスクの場合は、[変更] をクリックし、Debian オペレーティング システムと 10 (buster) バージョンを選択します。
6. [保存] をクリックして、このブートディスクのオプションを保存します。

7. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。

   • [ネットワーキング] をクリックして、次の変更を行います。
     • ネットワーク: lb-network
     • サブネット: lb-subnet
     • ネットワーク タグ: allow-ssh と allow-health-check
   • [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。

   #! /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://169.254.169.254/computeMetadata/v1/instance/name)"
   echo "Page served from: $vm_hostname" | \
   tee /var/www/html/index.html
   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
   

8. [作成] をクリックします。

マネージド インスタンス グループ

1. Google Cloud Console で、[インスタンス グループ] ページに移動します。
   [VM インスタンス グループ] に移動
2. [インスタンス グループを作成] をクリックします。
3. [名前] を ig-ilb に設定します。
4. [ロケーション] で [マルチゾーン] を選択し、[リージョン] を us-west1 に設定します。
5. [インスタンス テンプレート] を template-vm-ilb に設定します。
6. （省略可）自動スケーリングを構成します。インスタンス グループは内部 TCP / UDP 負荷分散のバックエンドであるため、HTTP 負荷分散の使用に基づいたインスタンス グループの自動スケーリングはできません。
7. [インスタンスの最小数] を 1、[インスタンスの最大数] を 6 にそれぞれ設定します。
8. （省略可）自動スケーリングを構成します。自動修復を構成する場合、内部 TCP / UDP ロードバランサのバックエンド サービスで使用されるのと同じヘルスチェックを使用します。この例では、hc-http-80.を使用します。
9. [作成] をクリックします。

gcloud

1. インスタンス テンプレートを作成します。必要に応じて、その他のパラメータを設定します。たとえば、イメージ テンプレートには、マシンタイプを設定します。

   gcloud compute instance-templates create template-vm-ilb \
       --image-family=debian-10 \
       --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://169.254.169.254/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. 次のテンプレートを使用して、リージョンのマネージド インスタンス グループを 1 つ作成します。

   gcloud compute instance-groups managed create ig-ilb \
       --template=template-vm-ilb \
       --region=us-west1 \
       --size=6
   

3. リージョンのマネージド インスタンス グループをバックエンドとして作成済みのバックエンド サービスに追加します。

   gcloud compute backend-services add-backend be-ilb \
       --region=us-west1 \
       --instance-group=ig-ilb \
       --instance-group-region=us-west1
   

4. ゾーンの 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 は、内部 TCP / UDP ロードバランサのみで使用されるため、外部 IP アドレスは削除できます。外部 IP アドレスを削除すると、バックエンド VM から直接インターネットにアクセスできなくなります。

重要: VM から外部 IP アドレスを削除した場合、接続方法が制限されます。外部 IP アドレスを持たないインスタンスに接続するをご覧ください。バックエンド VM からロードバランサの IP アドレスへのリクエストを処理する方法を示すには、外部 IP アドレスをバックエンド VM に残してください。

Console

1. Google Cloud Console で、[VM インスタンス] ページに移動します。
   [VM インスタンス] に移動
2. 各バックエンド VM に対して以下の手順を繰り返します。
3. バックエンド VM の名前（たとえば、vm-a1）をクリックして、VM インスタンスの詳細を表示します。
4. [編集] をクリックします。
5. [ネットワーク インターフェース] セクションで、[編集] ボタンをクリックします。
6. [外部 IP] ポップアップで [なし] を選択して、[完了] をクリックします。
7. [保存] をクリックします。

gcloud

1. インスタンスのゾーンを検索する。たとえば、リージョンのマネージド インスタンス グループを使用している場合、インスタンスごとに次のコマンドを実行してゾーンを判別します。[SERVER-VM] を検索する VM の名前に置き換えます。

   gcloud compute instances list --filter="name=[SERVER-VM]"
   

2. 各バックエンド 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

すべてのポートでトラフィックを受信する

ロードバランサがトラフィックを受け入れるポートは、バックエンド サービスではなくロードバランサの転送ルールによって決まります。各コンポーネントの目的については、コンポーネントをご覧ください。

このサンプルのロードバランサの転送ルールを作成したときに、ポート 80、8008、8080、8088 を構成しました。Apache をインストールする起動スクリプトでも、ポート 443 および 8443 で HTTPS 接続を受け入れるように構成されます。

この 6 つのポートをサポートするには、すべてのポートでトラフィックを受け入れるように転送ルールを構成します。この方法では、バックエンド VM への受信接続を許可するファイアウォール ルールを特定のポートのみを許可するように構成することもできます。

この手順では、サンプルのロードバランサの転送ルールを、すべてのポートでトラフィックを受け入れるルールに置き換える方法を示します。

このセットアップを使用するタイミングの詳細については、共通の IP アドレスを使用した内部 TCP / UDP 負荷分散と転送ルールをご覧ください。

Console

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

1. Google Cloud Console で、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. be-ilb ロードバランサをクリックして、[編集] をクリックします。
3. [フロントエンドの構成] をクリックします。
4. 10.1.2.9 転送ルールにカーソルを合わせ、ゴミ箱アイコンをクリックして削除します。
5. [フロントエンド IP とポートの追加] をクリックします。
6. [新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
   1. 名前: fr-ilb
   2. サブネットワーク: lb-subnet
   3. [内部 IP] で [ip-ilb] を選択します。
   4. ポート: すべて。
   5. [完了] をクリックします。
   6. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
7. [確認と完了] をクリックします。設定を再度確認します。
8. [作成] をクリックします。

gcloud

1. 既存の転送ルール fr-ilb を削除します。

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

2. ポート構成でキーワード 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 アドレスを使用した内部 TCP / UDP 負荷分散と転送ルールをご覧ください。

Console

1. Google Cloud Console で、[転送ルール] ページに移動します。
   [転送ルール] に移動
2. [fr-ilb] を選択します。
3. [削除] をクリックします。
4. [Cloud Load Balancing] ページに移動します。
   [Cloud Load Balancing] ページに移動
5. 内部 TCP / UDP ロードバランサを選択します。この例では be-ilb です。
6. [編集] をクリックします。
7. [フロントエンドの構成] をクリックします。
8. [フロントエンド IP とポートの追加] をクリックします。
9. [新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
   1. 名前: fr-ilb-http
   2. サブネットワーク: lb-subnet
   3. [目的] で [共有] を選択します。
   4. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
      • 名前: internal-10-1-2-99
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.1.2.99
      • [予約] をクリックします。
   5. ポート: [複数] を選択して、ポート番号に「80,8008,8080,8088」と入力します。
   6. [完了] をクリックします。
10. [フロントエンド IP とポートの追加] をクリックします。
11. [新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
    1. 名前: fr-ilb-https
    2. サブネットワーク: lb-subnet
    3. [目的] で [共有] を選択します。
    4. [IP アドレス] で internal-10-1-2-99 を選択します。
    5. ポート: [複数] を選択して、ポート番号に「443,8443」と入力します。
    6. [完了] をクリックします。
    7. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
12. [確認と完了] をクリックします。設定を再度確認します。
13. [更新] をクリックします。

gcloud

1. 既存の転送ルール fr-ilb を削除します。

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

2. 10.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
   

   1. 次のパラメータを使用して 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-west1
   

   gcloud 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 アドレスから作成されたハッシュに基づいてセッション アフィニティを使用するように、内部 TCP / UDP ロードバランサのバックエンド サービスを更新する方法を説明します。

サポートされているセッション アフィニティのタイプについては、セッション アフィニティのオプションをご覧ください。

注: 内部 UDP ロードバランサの場合、セッション アフィニティの設定は、gcloud CLI と API でサポートされています。現在、Cloud Console を使用して UDP トラフィックにセッション アフィニティを設定することはできません。

Console

1. Google Cloud Console で、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. [be-ilb]（この例で作成したバックエンド サービスの名前）をクリックし、[編集] をクリックします。
3. [内部ロードバランサの編集] ページで、[バックエンドの構成] をクリックします。
4. [セッション アフィニティ] ポップアップ メニューからクライアント IP を選択します。
5. [更新] をクリックします。

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"
}

接続トラッキング ポリシーの構成

このセクションでは、バックエンド サービスを更新してロードバランサのデフォルトの接続トラッキング ポリシーを変更する方法について説明します。

接続トラッキング ポリシーには次の設定が含まれます。

• トラッキング モード
• 異常なバックエンドでの接続の永続性
• アイドル タイムアウト

注: Cloud Console を使用して接続トラッキング ポリシーを構成することはできません。代わりに、Google Cloud CLI または REST API を使用してください。

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 つの内部 TCP / UDP ロードバランサに対して複数の転送ルールを作成できることを示すために、2 つ目の IP アドレスと転送ルールを別のサブネットに作成します。転送ルールのリージョンは、バックエンド サービスのリージョンと一致する必要があります。

ファイアウォール ルールに従うと、リージョン内のサブネット内のクライアントは、内部 TCP / UDP ロードバランサの IP アドレスに接続できます。

Console

2 番目のサブネットを追加する

1. Google Cloud Console で、[VPC ネットワーク] ページに移動します。
   [VPC ネットワーク] に移動
2. [VPC ネットワークを作成] をクリックします。
3. [lb-network] をクリックします。
4. [サブネット] セクションで次の設定を行います。
   • [サブネットを追加] をクリックします。
   • [新しいサブネット] セクションに、次の情報を入力します。
     • 名前: second-subnet
     • リージョン: us-west1
     • IP アドレス範囲: 10.5.6.0/24
     • [追加] をクリックします。

2 番目の転送ルールを追加する

1. Google Cloud Console で、[ロード バランシング] ページに移動します。
   [ロード バランシング] に移動
2. be-ilb ロードバランサをクリックして、[編集] をクリックします。
3. [フロントエンドの構成] をクリックします。
4. [フロントエンド IP とポートの追加] をクリックします。
5. [新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
   1. 名前: fr-ilb-2
   2. サブネットワーク: second-subnet
   3. [内部 IP] で [ip-ilb] を選択します。
   4. ポート: 80、443
   5. [完了] をクリックします。
   6. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
6. [確認と完了] をクリックします。設定を再度確認します。
7. [作成] をクリックします。

gcloud

1. us-west1 リージョン内の lb-network ネットワークに 2 つ目のサブネットを作成します。

   gcloud compute networks subnets create second-subnet \
      --network=lb-network \
      --range=10.5.6.0/24 \
      --region=us-west1
   

2. ポート 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"
}

新しい転送ルールをテストする

1. クライアント 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 で処理されることを確認してください。

バックエンドのサブセット化を使用する

構成例では、バックエンド サービスがサブセット化されていません。

この手順では、内部 TCP / UDP ロードバランサのバックエンド サービスでサブセット化を有効にして、より多くのバックエンド インスタンスにスケーリングできるようにする方法を示します。

注意: バックエンドのサブセット化を有効にすると一時的に中断され、既存の TCP 接続が中断される可能性があります。

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
    }
}

次のステップ

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