内部 HTTP(S) ロードバランサのプロキシ専用サブネット

このページでは、内部 HTTP(S) 負荷分散のプロキシ専用サブネットを使用する方法について説明します。内部 HTTP(S) 負荷分散の概要については、内部 HTTP(S) 負荷分散のコンセプトをご覧ください。

内部 HTTP(S) ロードバランサは、ネットワークにプロキシのプールを提供します。プロキシは、URL マップ、バックエンド サービスのセッション アフィニティ、各バックエンド インスタンス グループまたは NEG の分散モード、その他の要素に基づいて HTTP(S) リクエストを実行する場所を評価します。

  1. クライアントは、ロードバランサの転送ルールの IP アドレスとポートに接続します。

  2. いずれかのプロキシがクライアントのネットワーク接続を受信して終了します。

  3. プロキシは、NEG 内の適切なバックエンド VM またはエンドポイントと接続を確立します。これは、ロードバランサの URL マップとバックエンド サービスによって決まります。

各ロードバランサのプロキシには内部 IP アドレスが割り当てられます。リージョン内のすべての内部 HTTP(S) ロードバランサのプロキシは、VPC ネットワークのリージョン内のプロキシ専用サブネットから内部 IP アドレスを取得して使用します。このサブネットは、内部 HTTP(S) 負荷分散プロキシ専用として予約されており、他の目的には使用できません。プロキシのみのサブネットでは 64 以上の IP アドレスを指定する必要があります。これは、/26 以下のプリフィックス長に対応します。プロキシ専用サブネットは各リージョンに 1 つあり、VPC ネットワークごとにアクティブにします。

プロキシ専用サブネットを使用するのは、リージョンの内部 HTTP(S) ロードバランサ用に GCP によって作成されたプロキシだけです。プロキシ専用サブネットからは、ロードバランサの転送ルールの IP アドレスは取得されません。また、バックエンド VM とエンドポイントの IP アドレスも、プロキシ専用サブネットから取得されません。

各プロキシは、対応するロードバランサの転送ルールで指定された IP アドレスとポートでリッスンします。プロキシからバックエンド VM またはエンドポイントに送信される各パケットには、プロキシ専用サブネットからの送信元 IP アドレスが含まれています。

次の図に、トラフィック フローの概要を示します。

レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)
レイヤ 7 ベースの負荷分散を使用した内部サービス(クリックして拡大)

プロキシ専用サブネットとロードバランサのアーキテクチャの関係

次の図は、HTTP(S) ロードバランサに必要な GCP リソースを示しています。

内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)
内部 HTTP(S) 負荷分散コンポーネント(クリックして拡大)

図のように、内部 HTTP(S) ロードバランサのデプロイには少なくとも 2 つのサブネットが必要です。

  • ロードバランサの内部管理転送ルール、バックエンド VM の IP アドレス、バックエンド エンドポイントの IP アドレスは、プライマリ IP アドレスの範囲が 10.1.2.0/24 のサブネットを 1 つ使用します。このサブネットは、プロキシ専用のサブネットではありません。サブネットがロードバランサと同じリージョンにある場合、バックエンド VM とエンドポイントに複数のサブネットを使用できます。

  • プロキシ専用サブネットは 10.129.0.0/26 です。

プロキシ専用サブネットの作成

HTTP(S) ロードバランサのサブネットの予約は、サブネットの作成と基本的に同じです。ただし、いくつかのフラグを追加します。

内部 HTTP(S) ロードバランサの転送ルールを作成する前に、ロードバランサのプロキシで使用するプロキシ専用サブネットを作成する必要があります。リージョンのプロキシ専用サブネットを最初に作成せずに内部 HTTP(S) ロードバランサを設定すると、ロードバランサの作成プロセスでエラーが発生します。

内部 HTTP(S) ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。このサブネットは、リージョン内のすべての内部 HTTP(S) ロードバランサによって共有されます。

ネットワークが自動モードかカスタムモードかに関係なく、プロキシ専用サブネットを作成する必要があります。推奨されるサブネット サイズは /24 です。プロキシ専用のアドレスは 256 です。少なくとも /26 にする必要があります(64 個のプロキシ専用アドレス)。

プロキシ専用サブネットを作成するには、gcloud compute networks subnets create コマンドを実行します。

gcloud beta compute networks subnets create SUBNET_NAME \
    --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

各項目の説明は次のとおりです。

  • SUBNET_NAME は、プロキシのみのサブネットの名前です。
  • REGION は、プロキシのみのサブネットのリージョンです
  • VPC_NETWORK_NAME は、サブネットを含む VPC ネットワークの名前です。
  • CIDR_RANGE は、サブネットのプライマリ IP 範囲です。サブネット マスクは 26 以下にします。リージョン内のプロキシに 64 以上の IP アドレスを使用できるようにします。

完全な構成例については、プロキシ専用サブネットの作成をご覧ください。

GCP Console を使用している場合は、以降のセクションで説明するように、Load Balancing の UI でプロキシ専用サブネットを作成できます。

プロキシ専用サブネットからの接続を受け入れるには、バックエンドにファイアウォール ルールを構成する必要があります。詳しくは、ファイアウォール ルールの構成l7-ilb-firewall 構成をご覧ください。

プロキシ専用サブネットのサイズ / アドレス範囲の変更

1 つのリージョンと VPC ネットワークでアクティブにできるプロキシ専用サブネットは 1 つだけです。また、サブネットのプライマリ IP 範囲は拡張可能です。次の手順に従って、プロキシ専用サブネットを変更する必要があります。

  1. 同じリージョンにバックアップのプロキシ専用サブネットを作成します。必要なプライマリ IP 範囲を使用して、gcloud compute networks subnets create コマンドを実行します。

    gcloud beta compute networks subnets create subnet-name \
       --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
       --role=BACKUP \
       --region=region \
       --network=vpc-network-name \
       --range=cidr-range
    
  2. バックアップのプロキシ専用サブネットのプライマリ IP 範囲が含まれるように、バックエンド VM またはエンドポイントに適用する上り許可ファイアウォール ルールを作成または変更します。

  3. 次の gcloud コマンドを実行すると、バックアップ プロキシ専用サブネットをアクティブに昇格し、アクティブなプロキシ専用サブネットに降格できます。

    gcloud beta compute networks subnets update backup-proxy-subnet \
       --role=ACTIVE \
       --drainTimeoutSeconds=connection-draining-timeout<\var>
    

    プレースホルダを有効な値に置き換えます。

    • <var>backup-proxy-subnet</var> は、新しく作成したプロキシ専用サブネットの名前です。
    • <var>connection-draining-timeout<\var> には、GCP が前にアクティブだったプロキシ専用サブネットのプロキシから既存の接続を移行するために必要な時間を秒数で指定します。

    プロキシ専用サブネットをバックアップからアクティブに切り替えても、新しい接続は中断しません。

    • 新しくアクティブになったプロキシ専用サブネットは新しい接続に使用されます。
    • 以前アクティブだったプロキシ専用サブネットは、新しい接続に使用されなくなります。
    • GCP は、以前アクティブなプロキシ専用サブネットのプロキシから既存の接続を削除します。
  4. 接続がタイムアウトしたか、バックエンド VM またはエンドポイントへの接続が以前アクティブだったプロキシ専用サブネットのプロキシから行われていないことを確認したら、次の操作を行います。

    • 以前アクティブだったプロキシ専用サブネットのプライマリ IP 範囲が含まれないように、バックエンド VM またはエンドポイントに適用される上り許可ファイアウォール ルールを変更します。
    • 以前にアクティブだったプロキシ専用サブネット(現在はバックアップ)を削除して、サブネットがプライマリ IP アドレス範囲に使用していた IP アドレスを解放します。

要件と制限事項

プロキシ専用サブネットには、次の制約があります。

  • 1 つのリージョンと VPC ネットワークには、アクティブとバックアップのプロキシ専用サブネットをそれぞれ 1 つずつ作成できます。

  • リージョンとネットワークにプロキシ専用サブネットが作成されていない場合は、バックアップのプロキシ専用サブネットは作成できません。

  • サブネットを更新することで、プロキシ専用サブネットの役割をバックアップからアクティブに切り替えることができます。これにより、GCP は以前アクティブだったプロキシ専用サブネットを自動的にバックアップに変更します。プロキシ専用サブネットの役割を明示的にバックアップに設定することはできません。

  • プロキシ専用サブネットの接続ドレイン期間(drainTimeoutSeconds)内は、プロキシ専用サブネットの役割をバックアップからアクティブに変更できません。

  • 特定のリージョンと VPC ネットワークで最初の内部 HTTP(S) ロードバランサを作成する前に、そのリージョンとネットワークにアクティブなプロキシ専用サブネットが存在している必要があります。

  • プロキシ専用サブネットで IP アドレスが不足している場合、GCP から警告は表示されません。

  1. リージョン専用のバックアップ プロキシ専用サブネットを作成します。

    gcloud beta compute networks subnets create new-l7ibackend-subnet-us-west1 \
       --purpose INTERNAL_HTTPS_LOAD_BALANCER \
       --role BACKUP \
       --region us-west1 \
       --network default \
       --addresses 10.130.0.0/26
    
  2. バックエンド ファイアウォールを更新して、新しいサブネットからの接続を受け入れます。

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.129.0.0/26,10.130.0.0/26
    
  3. 新しいサブネットを更新して、リージョン内のアクティブ プロキシ専用サブネットに設定し、古いサブネットが廃棄されるのを待ちます。

    gcloud beta compute networks subnets update new-l7ilb-ip-range-us-west1 \
       --drain-timeout 1h --role ACTIVE
    

    IP アドレス範囲をすぐにドレインするには、--drain-timeout0s に設定します。サブネット内のアドレスが割り当てられているプロキシへのすべての接続がすぐに終了します。

  4. list コマンドまたは describe コマンドを使用して、ドレインの状態をモニタリングします。ドレインの実行中、サブネットのステータスは DRAINING になります。

    gcloud beta compute networks subnets list
    

    ドレインが完了するまで待ちます。古いプロキシ専用サブネットがドレインされると、サブネットのステータスは READY になります。

  5. バックエンドのファイアウォール ルールを更新して、新しいサブネットからの接続のみを許可します。

    gcloud compute firewall-rules update l7-ilb-firewall \
       --source-ranges 10.130.0.0/26
    
  6. 古いサブネットを削除します。

    gcloud beta compute networks subnets delete l7ilb-ip-range-us-west1 \
       --region us-west1
    

プロキシ専用サブネットの削除

プロキシ専用サブネットを削除すると、プライマリ IP 範囲が解放され、その範囲を別の用途に利用できます。GCP では、プロキシ専用サブネットの削除リクエストを受信すると、次のルールに従って対応します。

  • 同じリージョンと VPC ネットワークに 1 つ以上の内部 HTTP(S) ロードバランサがある場合、アクティブなプロキシ専用サブネットは削除できません。

  • バックアップのプロキシ専用サブネットが同じリージョンと VPC ネットワークに存在する場合、アクティブなプロキシ専用サブネットは削除できません。

より詳細なルールは次のとおりです。

  • 特定のリージョンと VPC ネットワークに内部 HTTP(S) ロードバランサが定義されていない場合は、そのリージョンのプロキシ専用サブネットを削除できます。バックアップのプロキシ専用サブネットが存在する場合は、これを削除してからアクティブなプロキシ専用サブネットを削除します。

  • 特定のリージョンと VPC ネットワークで定義された内部 HTTP(S) ロードバランサが 1 つ以上ある場合、アクティブなプロキシ専用サブネットは削除できません。ただし、バックアップのプロキシ専用サブネットをアクティブな役割に昇格すると、以前アクティブだったプロキシ専用サブネットがバックアップに自動的に降格します。接続が切断された後、バックアップのプロキシ専用サブネットを削除できます。

詳細については、VPC ネットワークのドキュメントのサブネットの削除をご覧ください。

次のステップ