リージョン内部プロキシ ネットワーク ロードバランサは、プロキシベースのリージョン レイヤ 4 ロードバランサです。これにより、同じ VPC ネットワーク内のクライアントまたは VPC ネットワークに接続されているクライアントのみがアクセスできる内部 IP アドレスの背後で TCP サービス トラフィックを実行し、スケールできます。
このガイドでは、マネージド インスタンス グループ(MIG)バックエンドを使用してリージョン内部プロキシ ネットワーク ロードバランサを設定する手順について説明します。
始める前に、リージョン内部プロキシ ネットワーク ロードバランサの概要をご覧ください。
概要
この例では、ロードバランサを使用して、REGION_A
リージョンの 2 つのゾーン マネージド インスタンス グループ内のバックエンド VM に TCP トラフィックを分散させます。この例のサービスは、ポート 110
で応答するように構成された Apache サーバーのセットです。多くのブラウザではポート 110
を使用できないため、テスト セクションでは curl
を使用します。
この例では、以下のデプロイを構成します。
リージョン内部プロキシのネットワーク ロードバランサは、リージョン ロードバランサです。すべてのロードバランサ コンポーネント(バックエンド インスタンス グループ、バックエンド サービス、ターゲット プロキシ、転送ルール)は、同じリージョンに配置されている必要があります。
権限
このガイドに進むには、プロジェクト内でインスタンスを作成してネットワークを変更できる必要があります。そのためにはプロジェクトのオーナーまたは編集者であるか、または次の Compute Engine IAM のロールをすべて持っている必要があります。
タスク | 必要なロール |
---|---|
ネットワーク、サブネット、ロードバランサ コンポーネントの作成 | ネットワーク管理者 |
ファイアウォール ルールの追加と削除 | セキュリティ管理者 |
インスタンスの作成 | Compute インスタンス管理者 |
詳細については、次のガイドをご覧ください。
ネットワークとサブネットを構成する
ロードバランサのバックエンド用とロードバランサのプロキシ用の 2 つのサブネットが存在する VPC ネットワークが必要です。リージョン内部プロキシ ネットワーク ロードバランサはリージョン リソースです。VPC ネットワーク内のトラフィックは、送信元がロードバランサと同じリージョンのサブネット内にある場合、ロードバランサに転送されます。
この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。
ネットワーク。ネットワークは、
lb-network
という名前のカスタムモードの VPC ネットワークです。バックエンドのサブネット。
REGION_A
リージョンのbackend-subnet
という名前のサブネット。プライマリ IP 範囲として10.1.2.0/24
を使用します。プロキシのサブネット。
REGION_A
リージョンのproxy-only-subnet
という名前のサブネット。プライマリ IP 範囲として10.129.0.0/23
を使用します。
この例では、グローバル アクセスを説明するため、別のリージョン(REGION_B)と、プライマリ IP アドレス範囲 10.3.4.0/24
のサブネットに 2 つ目のテスト クライアント VM を作成します。
ネットワークとサブネットを作成する
コンソール
Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワークを作成] をクリックします。
[名前] に「
lb-network
」と入力します。[サブネット] セクションで、[サブネット作成モード] を [カスタム] に設定します。
ロードバランサのバックエンド用のサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前:
backend-subnet
- リージョン:
REGION_A
- IP アドレス範囲:
10.1.2.0/24
- 名前:
[完了] をクリックします。
[サブネットを追加] をクリックします。
グローバル アクセスを示すためにサブネットを作成します。[新しいサブネット] セクションに、次の情報を入力します。
- 名前:
test-global-access-subnet
- リージョン:
REGION_B
- IP アドレス範囲:
10.3.4.0/24
- 名前:
[完了] をクリックします。
[作成] をクリックします。
gcloud
gcloud compute networks create
コマンドを使用してカスタム VPC ネットワークを作成します。gcloud compute networks create lb-network --subnet-mode=custom
gcloud compute networks subnets create
コマンドを使用して、REGION_A
リージョンのlb-network
ネットワークにサブネットを作成します。gcloud compute networks subnets create backend-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=REGION_A
REGION_A は、ターゲットの Google Cloud リージョンの名前に置き換えます。
gcloud compute networks subnets create
コマンドを使用して、REGION_B
リージョンのlb-network
ネットワークにサブネットを作成します。gcloud compute networks subnets create test-global-access-subnet \ --network=lb-network \ --range=10.3.4.0/24 \ --region=REGION_B
REGION_B は、グローバル アクセスをテストするために 2 番目のサブネットを作成する Google Cloud リージョンの名前に置き換えます。
プロキシ専用サブネットを作成する
プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。このプロキシは、クライアントからの接続を終了し、バックエンドへの新しい接続を作成します。
このプロキシ専用サブネットは、lb-network
VPC ネットワークの REGION_A
リージョン内のすべての Envoy ベースのロードバランサで使用されます。
コンソール
Google Cloud コンソールを使用している場合は、しばらく待ってから、[ロード バランシング] ページでプロキシ専用サブネットを作成できます。
プロキシ専用サブネットを今すぐ作成する場合は、次の手順を行います。
- Google Cloud コンソールの [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] に移動 - 共有 VPC ネットワークの名前
lb-network
をクリックします。 - [サブネットを追加] をクリックします。
- [名前] に「
proxy-only-subnet
」と入力します。 - [リージョン] で
REGION_A
を選択します。 - [目的] を [リージョン マネージド プロキシ] に設定します。
- [IP アドレス範囲] に「
10.129.0.0/23
」と入力します。 - [追加] をクリックします。
gcloud
gcloud compute networks subnets
create
コマンドを使用して、プロキシ専用サブネットを作成します。
gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=REGION_A \ --network=lb-network \ --range=10.129.0.0/23
ファイアウォール ルールを作成する
この例では、次のファイアウォール ルールが必要です。
fw-allow-ssh
。ロードバランスされたインスタンスに適用される上り(内向き)ルール。任意のアドレスから TCP ポート22
への SSH 接続を許可します。このルールには、送信元の IP 範囲をより限定的に指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ターゲットタグallow-ssh
を使用しています。fw-allow-health-check
。ロードバランスされているインスタンスに適用される上り(内向き)ルール。Google Cloud ヘルスチェック システム(130.211.0.0/22
と35.191.0.0/16
)からのすべての TCP トラフィックを許可します。この例では、ターゲットタグallow-health-check
を使用しています。fw-allow-proxy-only-subnet
。バックエンドにプロキシ専用サブネットからの接続を許可する上り(内向き)ルール。
これらのファイアウォール ルールがない場合は、デフォルトの上り(内向き)拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
ターゲットタグは、バックエンド インスタンスを定義します。ターゲットタグがない場合、ファイアウォール ルールは VPC ネットワーク内のすべてのバックエンド インスタンスに適用されます。バックエンド VM を作成する場合は、マネージド インスタンス グループの作成の説明に沿って、指定したターゲットタグを忘れずに含めてください。
コンソール
- Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
[ファイアウォール ポリシー] に移動 - [ファイアウォール ルールを作成] をクリックして、SSH 接続の受信を許可するルールを作成します。
- 名前:
fw-allow-ssh
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
0.0.0.0/0
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
22
」と入力します。
- 名前:
- [作成] をクリックします。
- [ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
- 名前:
fw-allow-health-check
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
130.211.0.0/22
と35.191.0.0/16
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
このルールは、ヘルスチェックに使用されているプロトコルとポートのみに制限することをおすすめします。プロトコルとポートにtcp:80
を使用すると、Google Cloud はポート80
で HTTP を使用して VM に接続できますが、ポート443
では HTTPS を使用して VM に接続することはできません。
- 名前:
- [作成] をクリックします。
- [ファイアウォール ルールを作成] をもう一度クリックをして、ロードバランサのプロキシ サーバーがバックエンドに接続できるようにするルールを作成します:
- 名前:
fw-allow-proxy-only-subnet
- ネットワーク:
lb-network
- トラフィックの方向: 上り(内向き)
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-proxy-only-subnet
- ソースフィルタ: IPv4 の範囲
- 送信元 IPv4 範囲:
10.129.0.0/23
- プロトコルとポート:
- 指定されたプロトコルとポートを選択します。
- [TCP] チェックボックスをオンにして、ポート番号に「
80
」と入力します。
- 名前:
- [作成] をクリックします。
gcloud
ネットワーク タグ
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
Google Cloud ヘルスチェックを許可する
fw-allow-health-check
ルールを作成します。この例では、ヘルスチェック プローブからのすべての TCP トラフィックを許可します。ただし、必要に応じてポートの範囲を狭く構成することもできます。gcloud compute firewall-rules create fw-allow-health-check \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
リージョンの Envoy プロキシがバックエンドに接続できるように
fw-allow-proxy-only-subnet
ルールを作成します。--source-ranges
をプロキシ専用サブネットの割り振り範囲に設定します(この例では10.129.0.0/23
)。gcloud compute firewall-rules create fw-allow-proxy-only-subnet \ --network=lb-network \ --action=allow \ --direction=ingress \ --source-ranges=10.129.0.0/23 \ --target-tags=allow-proxy-only-subnet \ --rules=tcp:80
ロードバランサの IP アドレスを予約する
ロードバランサに静的内部 IP アドレスを予約するには、新しい静的内部 IPv4 または IPv6 アドレスを予約するをご覧ください。
マネージド インスタンス グループを作成する
このセクションでは、ロードバランサの REGION_A
リージョンに 2 つのマネージド インスタンス グループ(MIG)バックエンドを作成する方法について説明します。MIG は、この例のリージョン内部プロキシ ネットワーク ロードバランサのバックエンド Apache サーバーを実行する VM インスタンスを提供しています。通常、リージョン内部プロキシ ネットワーク ロードバランサは HTTP トラフィックには使用されませんが、Apache ソフトウェアはテストによく使用されます。
コンソール
インスタンス テンプレートを作成します。Google Cloud コンソールで [インスタンス テンプレート] ページに移動します。
- [インスタンス テンプレートを作成] をクリックします。
- [名前] に「
int-tcp-proxy-backend-template
」と入力します。 - [ブートディスク] が Debian GNU / Linux 10 (stretch) などの Debian イメージに設定されていることを確認します。以降の手順では、
apt-get
などの Debian でのみ使用できるコマンドを使用します。 - [詳細オプション] をクリックします。
- [ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に、
allow-ssh
、allow-health-check
、allow-proxy-only-subnet
を入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
backend-subnet
- ネットワーク:
- [ネットワーク タグ] に、
[管理] をクリックします。[起動スクリプト] フィールドに次のスクリプトを入力します。
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl 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 systemctl restart apache2
[作成] をクリックします。
マネージド インスタンス グループを作成します。Google Cloud コンソールで、[インスタンス グループ] ページに移動します。
- [インスタンス グループを作成] をクリックします。
- [新しいマネージド インスタンス グループ(ステートレス)] を選択します。詳細については、ステートレス MIG とステートフル MIG をご覧ください。
- [名前] に「
mig-a
」と入力します。 - [ロケーション] で [シングルゾーン] を選択します。
- [リージョン] で、
REGION_A
を選択します。 - [ゾーン] で、[
ZONE_A1
] を選択します。 - [インスタンス テンプレート] で
int-tcp-proxy-backend-template
を選択します。 グループ内に作成するインスタンスの数を指定します。
この例では、[自動スケーリング] で次のオプションを指定します。
- [自動スケーリング モード] で [
Off:do not autoscale
] を選択します。 - [インスタンスの最大数] に「
2
」と入力します。
- [自動スケーリング モード] で [
[ポート マッピング] で、[ポートを追加] をクリックします。
- [ポート名] に「
tcp80
」と入力します。 - [ポート番号] に「
80
」と入力します。
- [ポート名] に「
[作成] をクリックします。
手順 2 を繰り返し、次の設定で 2 つ目のマネージド インスタンス グループを作成します。
- 名前:
mig-c
- ゾーン:
ZONE_A2
その他の設定はすべて同じままにします。
- 名前:
gcloud
このガイドの gcloud
の手順は、Cloud Shell または bash がインストールされた別の環境を使用していることを前提としています。
gcloud compute instance-templates create
コマンドを使用して、HTTP サーバーで VM インスタンス テンプレートを作成します。gcloud compute instance-templates create int-tcp-proxy-backend-template \ --region=REGION_A \ --network=lb-network \ --subnet=backend-subnet \ --tags=allow-ssh,allow-health-check,allow-proxy-only-subnet \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://metadata.google.internal/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'
ZONE_A1
ゾーンにマネージド インスタンス グループを作成します。gcloud compute instance-groups managed create mig-a \ --zone=ZONE_A1 \ --size=2 \ --template=int-tcp-proxy-backend-template
ZONE_A1 は、ターゲット Google Cloud リージョンのゾーンの名前に置き換えます。
ZONE_A2
ゾーンにマネージド インスタンス グループを作成します。gcloud compute instance-groups managed create mig-c \ --zone=ZONE_A2 \ --size=2 \ --template=int-tcp-proxy-backend-template
ZONE_A2 は、ターゲット Google Cloud リージョンの別のゾーンの名前に置き換えます。
ロードバランサを構成する
コンソール
構成を開始する
Google Cloud コンソールで、[ロード バランシング] ページに移動します。
- [ロードバランサを作成] をクリックします。
- [ロードバランサの種類] で [ネットワーク ロードバランサ(TCP / UDP / SSL)] を選択し、[次へ] をクリックします。
- [プロキシまたはパススルー] で [プロキシ ロードバランサ] を選択し、[次へ] をクリックします。
- [インターネット接続または内部] で [内部] を選択し、[次へ] をクリックします。
- [クロスリージョンまたはシングル リージョンのデプロイ] で [リージョン ワークロードに最適] を選択し、[次へ] をクリックします。
- [構成] をクリックします。
基本構成
- [名前] に「
my-int-tcp-lb
」と入力します。 - [リージョン] で
REGION_A
を選択します。 - [ネットワーク] で
lb-network
を選択します。
プロキシ専用サブネットを予約する
プロキシ専用サブネットを予約するには:
- [サブネットを予約] をクリックします。
- [名前] に「
proxy-only-subnet
」と入力します。 - [IP アドレス範囲] に「
10.129.0.0/23
」と入力します。 - [追加] をクリックします。
バックエンドの構成
- [バックエンドの構成] をクリックします。
- [バックエンド タイプ] で [インスタンス グループ] を選択します。
- [プロトコル] で、[TCP] を選択します。
- [名前付きポート] に「
tcp80
」と入力します。 - 最初のバックエンドを構成します。
- [新しいバックエンド] で、インスタンス グループ
mig-a
を選択します。 - [ポート番号] に「
80
」と入力します。 - 残りのデフォルト値は変更せずに、[完了] をクリックします。
- [新しいバックエンド] で、インスタンス グループ
- 2 番目のバックエンドを構成します。
- [ADD BACKEND] をクリックします。
- [新しいバックエンド] で、インスタンス グループ
mig-c
を選択します。 - [ポート番号] に「
80
」と入力します。 - 残りのデフォルト値は変更せずに、[完了] をクリックします。
- ヘルスチェックを構成します。
- [ヘルスチェック] で [ヘルスチェックを作成] を選択します。
- ヘルスチェックの名前を
tcp-health-check
に設定します。 - [プロトコル] で、[TCP] を選択します。
- [ポート] を
80
に設定します。
- 残りのデフォルト値は変更せずに、[保存] をクリックします。
- Google Cloud コンソールで、[バックエンドの構成] の横にチェックマークが表示されていることを確認します。チェックマークがない場合は、すべての手順を完了したことを再度確認します。
フロントエンドの構成
- [フロントエンドの構成] をクリックします。
- [名前] に「
int-tcp-forwarding-rule
」と入力します。 - [サブネットワーク] で [backend-subnet] を選択します。
- [IP アドレス] で、以前に予約した IP アドレスを選択します。 LB_IP_ADDRESS
- [ポート番号] に「
110
」と入力します。転送ルールは、宛先ポートが一致するパケットのみを転送します。 - [プロキシのプロトコル] は Apache HTTP Server ソフトウェアでは動作しないため、この例では有効にしないでください。詳細については、プロキシのプロトコルをご覧ください。
- [完了] をクリックします。
- Google Cloud コンソールで、[フロントエンドの構成] の横にチェックマークがあることを確認します。チェックマークがない場合には、前のすべてのステップが完了していることを再度確認してください。
確認と完了
- [確認と完了] をクリックします。
- ロードバランサの構成を確認します。
- 省略可: [同等のコード] をクリックして、ロードバランサの作成に使用する REST API リクエストを表示します。
- [作成] をクリックします。
gcloud
リージョン ヘルスチェックを作成します。
gcloud compute health-checks create tcp tcp-health-check \ --region=REGION_A \ --use-serving-port
バックエンド サービスを作成します。
gcloud compute backend-services create internal-tcp-proxy-bs \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=TCP \ --region=REGION_A \ --health-checks=tcp-health-check \ --health-checks-region=REGION_A
バックエンド サービスにインスタンス グループを追加します。
gcloud compute backend-services add-backend internal-tcp-proxy-bs \ --region=REGION_A \ --instance-group=mig-a \ --instance-group-zone=ZONE_A1 \ --balancing-mode=UTILIZATION \ --max-utilization=0.8
gcloud compute backend-services add-backend internal-tcp-proxy-bs \ --region=REGION_A \ --instance-group=mig-c \ --instance-group-zone=ZONE_A2 \ --balancing-mode=UTILIZATION \ --max-utilization=0.8
内部ターゲット TCP プロキシを作成します。
gcloud compute target-tcp-proxies create int-tcp-target-proxy \ --backend-service=internal-tcp-proxy-bs \ --proxy-header=NONE \ --region=REGION_A
プロキシ ヘッダーをオンにする場合は、
NONE
ではなくPROXY_V1
に設定します。[プロキシのプロトコル] は Apache HTTP Server ソフトウェアでは動作しないため、この例では有効にしないでください。詳細については、プロキシのプロトコルをご覧ください。転送ルールを作成します。
--ports
には、1~65535 から単一のポート番号を指定します。この例では、ポート110
を使用します。転送ルールは、宛先ポートが一致するパケットのみを転送します。gcloud compute forwarding-rules create int-tcp-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION_A \ --target-tcp-proxy=int-tcp-target-proxy \ --target-tcp-proxy-region=REGION_A \ --address=int-tcp-ip-address \ --ports=110
ロードバランサをテストする
ロードバランサをテストするには、ロードバランサと同じリージョンにクライアント VM を作成します。次に、クライアントからロードバランサにトラフィックを送信します。
クライアント VM を作成する
ロードバランサと同じリージョンにクライアント VM(client-vm
)を作成します。
コンソール
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
client-vm
に設定します。[ゾーン] を
ZONE_A1
に設定します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh
」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
backend-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
クライアント VM は、ロードバランサと同じ VPC ネットワークとリージョンに存在する必要があります。同じサブネットまたはゾーンに存在する必要はありません。クライアントは、バックエンド VM と同じサブネットを使用します。
gcloud compute instances create client-vm \ --zone=ZONE_A1 \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=backend-subnet
ロードバランサにトラフィックを送信する
ロードバランサを構成したので、ロードバランサの IP アドレスにトラフィックを送信してテストできるようになりました。
SSH を使用してクライアント インスタンスに接続します。
gcloud compute ssh client-vm \ --zone=ZONE_A1
ロードバランサがバックエンドのホスト名を想定どおりに処理していることを確認します。
ロードバランサの IP アドレスを表示するには、
compute addresses describe
コマンドを使用します。gcloud compute addresses describe int-tcp-ip-address \ --region=REGION_A
IP アドレスをメモしておきます。
ロードバランサにトラフィックを送信します。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
curl IP_ADDRESS:110
追加の構成オプション
このセクションでは、代替および追加の構成オプションを提供する構成例を示します。これらのタスクはすべて省略可です。また、任意の順序で行うことができます。
グローバル アクセスを有効にする
ロードバランサでグローバル アクセスを有効にして、すべてのリージョンのクライアントがアクセスできるようにします。サンプルのロードバランサのバックエンドは、引き続き 1 つのリージョン(REGION_A
)に配置する必要があります。
既存のリージョン転送ルールを変更して、グローバル アクセスを有効にすることはできません。これを行うには、新しい転送ルールを作成する必要があります。また、グローバル アクセスを有効にして転送ルールを作成した後に、これを変更することはできません。グローバル アクセスを無効にするには、新しいリージョン アクセス転送ルールを作成し、以前のグローバル アクセス転送ルールを削除する必要があります。
グローバル アクセスを構成するには、次の変更を行います。
コンソール
ロードバランサの転送ルールを新規作成します。
Google Cloud コンソールの [ロード バランシング] ページに移動します。
[名前] 列で、ロードバランサをクリックします。
[フロントエンドの構成] をクリックします。
[フロントエンド IP とポートの追加] をクリックします。
新しい転送ルールの名前とサブネットの詳細を入力します。
[サブネットワーク] で [backend-subnet] を選択します。
[IP アドレス] は、既存の転送ルールと同じ IP アドレスを選択するか、新しい IP アドレスを予約するか、エフェメラル IP アドレスを使用します。複数の転送ルールで同じ IP アドレスを使用するには、IP アドレスの作成時に IP アドレス
--purpose
フラグをSHARED_LOADBALANCER_VIP
に設定します。[ポート番号] に「
110
」と入力します。[グローバル アクセス] で [有効] を選択します。
[完了] をクリックします。
[更新] をクリックします。
gcloud
--allow-global-access
フラグを使用してロードバランサの新しい転送ルールを作成します。gcloud compute forwarding-rules create int-tcp-forwarding-rule-global-access \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION_A \ --target-tcp-proxy=int-tcp-target-proxy \ --target-tcp-proxy-region=REGION_A \ --address=int-tcp-ip-address \ --ports=110 \ --allow-global-access
gcloud compute forwarding-rules describe
コマンドを使用すると、転送ルールでグローバル アクセスが有効になっているかどうかを確認できます。次に例を示します。gcloud compute forwarding-rules describe int-tcp-forwarding-rule-global-access \ --region=REGION_A \ --format="get(name,region,allowGlobalAccess)"
グローバル アクセスが有効になっている場合、転送ルールの名前とリージョンの出力の後に
True
という単語が表示されます。
クライアント VM を作成してグローバル アクセスをテストする
コンソール
Google Cloud コンソールで [VM インスタンス] ページに移動します。
[インスタンスを作成] をクリックします。
[名前] を
test-global-access-vm
に設定します。[ゾーン] を
ZONE_B1
に設定します。[詳細オプション] をクリックします。
[ネットワーキング] をクリックして次のフィールドを構成します。
- [ネットワーク タグ] に「
allow-ssh
」と入力します。 - [ネットワーク インターフェース] で、次のように選択します。
- ネットワーク:
lb-network
- サブネット:
test-global-access-subnet
- ネットワーク:
- [ネットワーク タグ] に「
[作成] をクリックします。
gcloud
ZONE_B1
ゾーンにクライアント VM を作成します。
gcloud compute instances create test-global-access-vm \ --zone=ZONE_B1 \ --image-family=debian-12 \ --image-project=debian-cloud \ --tags=allow-ssh \ --subnet=test-global-access-subnet
ZONE_B1 は、REGION_B リージョンのゾーンの名前に置き換えます。
クライアント VM に接続して接続テストを行う
ssh
を使用してクライアント インスタンスに接続します。gcloud compute ssh test-global-access-vm \ --zone=ZONE_B1
ロードバランサの IP アドレスを取得するには、
gcloud compute addresses describe
コマンドを使用します。gcloud compute addresses describe int-tcp-ip-address \ --region=REGION_A
IP アドレスをメモしておきます。
ロードバランサにトラフィックを送信します。IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。
curl IP_ADDRESS:110
クライアント接続情報を保持するための PROXY プロトコル
プロキシ ネットワーク ロードバランサは、クライアントからの TCP 接続を終了して、インスタンスへの新しい接続を作成します。デフォルトでは、元のクライアント IP とポート情報は保持されません。
元の接続情報を保持してインスタンスに送信するには、PROXY プロトコル バージョン 1 を有効にします。このプロトコルは、送信元 IP アドレス、宛先 IP アドレス、ポート番号を含む追加ヘッダーをインスタンスへリクエストの構成部分として送信します。
プロキシ ネットワーク ロードバランサのバックエンド インスタンスが PROXY プロトコル ヘッダーをサポートするサーバーを実行していることを確認します。サーバーが PROXY プロトコル ヘッダーをサポートするように構成されていない場合、バックエンド インスタンスは空のレスポンスを返します。
ユーザー トラフィックに PROXY プロトコルを設定する場合は、ヘルスチェックにも設定します。同じポートでヘルスチェックとコンテンツの処理を行う場合は、ヘルスチェックの --proxy-header
がロードバランサの設定と一致するように設定します。
通常、PROXY プロトコルのヘッダーは、ユーザーが読み取り可能な次の形式の 1 行のテキストです。
PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n
次の例は、PROXY プロトコルを示しています。
PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n
上の例では、クライアント IP は 192.0.2.1
、ロード バランシング IP は 198.51.100.1
、クライアント ポートは 15221
、宛先ポートは 110
です。
クライアント IP が不明の場合、ロードバランサは PROXY プロトコルのヘッダーを次の形式で生成します。
PROXY UNKNOWN\r\n
ターゲット プロキシの PROXY プロトコル ヘッダーを更新する
既存のターゲット プロキシで PROXY プロトコル ヘッダーを更新することはできません。PROXY プロトコル ヘッダーに必要な設定で新しいターゲット プロキシを作成する必要があります。次の手順により、必要な設定で新しいフロントエンドを作成します。
コンソール
Google Cloud コンソールの [ロード バランシング] ページに移動します。
- 編集するロードバランサの名前をクリックします。
- ロードバランサの [ 編集] をクリックします。
- [フロントエンドの構成] をクリックします。
- 古いフロントエンドの IP とポートを削除します。
- [フロントエンド IP とポートの追加] をクリックします。
- [名前] に「
int-tcp-forwarding-rule
」と入力します。 - [サブネットワーク] で [backend-subnet] を選択します。
- [IP アドレス] で、以前に予約した IP アドレスを選択します。LB_IP_ADDRESS
- [ポート番号] に「
110
」と入力します。転送ルールは、宛先ポートが一致するパケットのみを転送します。 - [プロキシのプロトコル] フィールドの値を [オン] に変更します。
- [完了] をクリックします。
- [名前] に「
- [更新] をクリックして、変更を保存します。
gcloud
次のコマンドで、
--proxy-header
フィールドを編集し、必要に応じてNONE
またはPROXY_V1
に設定します。gcloud compute target-tcp-proxies create TARGET_PROXY_NAME \ --backend-service=BACKEND_SERVICE \ --proxy-header=[NONE | PROXY_V1] \ --region=REGION
既存の転送ルールを削除します。
gcloud compute forwarding-rules delete int-tcp-forwarding-rule \ --region=REGION
新しい転送ルールを作成し、ターゲット プロキシに関連付けます。
gcloud compute forwarding-rules create int-tcp-forwarding-rule \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=lb-network \ --subnet=backend-subnet \ --region=REGION \ --target-tcp-proxy=TARGET_PROXY_NAME \ --target-tcp-proxy-region=REGION \ --address=LB_IP_ADDRESS \ --ports=110
セッション アフィニティを有効にする
構成例では、バックエンド サービスをセッション アフィニティなしで作成しています。
これらの手順は、バックエンド サービスがクライアント IP アフィニティまたは生成された Cookie アフィニティを使用するように、サンプルのリージョン内部プロキシ ネットワーク ロードバランサのバックエンド サービスを更新する方法を示しています。
クライアント IP アフィニティが有効になっている場合、ロードバランサは、クライアントの IP アドレスとロードバランサの IP アドレス(内部転送ルールの内部 IP アドレス)から作成されたハッシュに基づいて、特定のクライアントのリクエストを同じバックエンド VM に送信します。
コンソール
クライアント IP セッション アフィニティを有効にするには:
- Google Cloud コンソールの [ロード バランシング] ページに移動します。
[ロード バランシング] に移動 - [バックエンド] をクリックします。
- [internal-tcp-proxy-bs](この例で作成したバックエンド サービスの名前)をクリックして、[編集] をクリックします。
- [バックエンド サービスの詳細] ページで、[詳細構成] をクリックします。
- [セッション アフィニティ] で、メニューから [クライアント IP] を選択します。
- [更新] をクリックします。
gcloud
クライアント IP セッション アフィニティを指定して、internal-tcp-proxy-bs
バックエンド サービスを更新するには、次の Google Cloud CLI コマンドを使用します。
gcloud compute backend-services update internal-tcp-proxy-bs \ --region=REGION_A \ --session-affinity=CLIENT_IP
コネクション ドレインを有効にする
バックエンド サービスでコネクション ドレインを有効にすると、トラフィックを処理しているインスタンスの停止、手動削除、オートスケーラーによる削除が発生した場合に、ユーザーに対する中断を最小限に抑えることができます。コネクション ドレインの詳細については、コネクション ドレインの有効化のドキュメントをご覧ください。