ネクストホップとしての内部 TCP / UDP ロードバランサ

内部 TCP / UDP 負荷分散は、内部負荷分散 IP アドレスの背後でサービスを実行およびスケーリングできるリージョン ロードバランサです。内部 TCP / UDP ロードバランサは、最終宛先へのパスに沿ってパケットを転送する際の次のゲートウェイとして使用できます。これを行うには、カスタム静的ルートでロードバランサをネクストホップに設定します。

この設定は、次のような場合に利用できます。

  • 仮想ネットワーク アドレス変換(NAT)アプライアンスとして機能する複数の VM 間でトラフィックを負荷分散する必要がある場合。

  • ロードバランサがデフォルトのルートのネクストホップとして機能する必要がある場合。Virtual Private Cloud(VPC)ネットワークの仮想マシン(VM)インスタンスがインターネットにトラフィックを送信する際に、トラフィックが負荷分散されたゲートウェイの仮想アプライアンスを経由してルーティングされます。

  • バックエンドと同じマルチ NIC VM のセットを使用して、2 つ以上の方向の複数のロードバランサ間でトラフィックを送信する必要がある場合。これを行うには、ロードバランサを作成し、各 VPC ネットワークでカスタム静的ルートのネクストホップとして使用します。各内部 TCP / UDP ロードバランサは、単一の VPC ネットワーク内で動作し、ネットワーク内のバックエンド VM のネットワーク インターフェースにトラフィックを分散します。

複数の NIC への負荷分散(クリックして拡大)
複数の NIC への負荷分散(クリックして拡大)

上の図では、VM インスタンス グループが 2 つの異なるロードバランサのバックエンドとして機能します。このユースケースは共通のバックエンドでネクストホップとしての内部 TCP / UDP ロードバランサといいます。バックエンド VM 上に複数の NIC(ここでは nic0nic1)が負荷分散されているためです。内部 TCP / UDP 負荷分散は、バックエンド VM インスタンスのメイン インターフェース nic0 だけでなく、任意のインターフェースへの負荷分散をサポートしているため、このデプロイは可能です。

一方、2 つの VM インスタンスは、2 つの異なるロードバランサのバックエンドとして機能します。受信トラフィックと送信トラフィックのトラフィック プロファイルが異なる場合は、バックエンドを 2 つ使用できます。このユースケースは異なるバックエンドでネクストホップとしての内部 TCP / UDP ロードバランサといいます。バックエンド VM 上にメイン インターフェース(nic0)のみが負荷分散されているためです。次の図に、この設定を示します。

単一の NIC への負荷分散(クリックして拡大)
単一の NIC への負荷分散(クリックして拡大)

ロードバランサが静的ルートのネクストホップになるような内部 TCP / UDP ロードバランサに TCP および UDP トラフィックを渡すカスタム静的ルートを作成できます。このルートは、サブネット ルートと競合しない限り、デフォルトのルート(0.0.0.0/0)、外部(公開のルーティング可能な)CIDR プレフィックス、または内部 CIDR プレフィックスにすることができます。たとえば、デフォルトのルート(0.0.0.0/0)は、パケット処理のためにサードパーティーのバックエンド VM にトラフィックを振り分けるルートに置き換えることができます。

カスタム静的ルートを使用するには、各 VPC ネットワーク内の VM インスタンスが、関連するロードバランサと同じリージョン内にある必要があります。

Cloud Router がロードバランサと同じリージョンにある場合、Cloud Router のカスタムルート アドバタイズを使用して、このルートを他の接続済みネットワークにアドバタイズできます。詳細については、内部 TCP/UDP 負荷分散と接続されたネットワークをご覧ください。

詳細情報

内部 TCP / UDP ロードバランサをネクストホップとして使用するメリット

ロードバランサを静的ルートのネクストホップにする場合、クライアントはトラフィックをロードバランサまたは各バックエンド VM に送信するように明示的に構成する必要がなくなります。バックエンド VM は、Bump-in-the-Wire(BITW)方式で統合できます。

静的ルートのネクストホップに内部 TCP / UDP ロードバランサを使用すると、内部 TCP / UDP 負荷分散と同じメリットが得られます。ロードバランサのヘルスチェックにより、新しい接続が健全なバックエンド VM に確実に転送されます。マネージド インスタンス グループをバックエンドとして使用すると、自動スケーリングを構成してサービスの需要に基づいて VM のセットを拡大または縮小できます。

仕様

内部 TCP / UDP ロードバランサをネクストホップとして使用する場合の仕様は次のとおりです。

クライアント IP のセッション アフィニティ

クライアント IP セッション アフィニティは利用可能なセッション アフィニティ オプションの 1 つです。これは、送信元 IP アドレスと宛先 IP アドレスをハッシュ関数の入力として使用する 2 つのタプル間のアフィニティです。

内部 TCP / UDP ロードバランサを単独で使用する場合、宛先 IP アドレスはロードバランサの転送ルールの IP アドレスになります。このコンテキストのクライアント IP セッション アフィニティは、一定の送信元 IP アドレスを持つクライアントからの接続が、バックエンド VM が正常な場合に同じバックエンド VM に配信されることを意味します。

一方、静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用する場合、宛先 IP アドレスが変わります。これはロードバランサのバックエンド VM がパケットを処理して別の宛先にルーティングするためです。このコンテキストでクライアント IP セッション アフィニティを使用した場合、クライアントが一定の送信元 IP アドレスを持っていても、パケットは同じバックエンド VM で処理されません。

送信先の範囲

カスタム静的ルートの宛先を、サブネット ルート以上に限定された宛先にすることはできません。限定的になると、サブネット マスクは長くなります。このルールは、ネクストホップが内部 TCP/UDP ロードバランサの場合も含め、すべてのカスタム静的ルートに適用されます。たとえば、サブネット ルートが 10.140.0.0/20 であるとします。カスタム静的ルートの宛先を同じ(10.140.0.0/20)にすることはできません。また、10.140.0.0/22 のように詳細な宛先を指定することもできません。

同じ VPC ネットワークとリージョン

内部 TCP / UDP ロードバランサをネクストホップとして使用するカスタム静的ルートは、次のものに制限されます。

  • 単一の VPC ネットワーク。ロードバランサとカスタム静的ルートは、同じ VPC ネットワーク内にある必要があります。

  • 単一のリージョンまたはすべてのリージョン。グローバル アクセスを構成しない限り、カスタム静的ルートはロードバランサと同じリージョン内のリソースでのみ使用できます。このリージョンに関する制限は、ルート自体が VPC ネットワーク全体のルーティング テーブルの一部であっても適用されます。グローバル アクセスを有効にすると、任意のリージョンのリソースでカスタム静的ルートを使用できます。

オペレーションの順序

ネクストホップとして使用するカスタム静的ルートを作成する前に、内部 TCP / UDP ロードバランサを作成する必要があります。これは、ルートを作成する前にロードバランサが存在しなければならないためです。存在しないロードバランサを参照するルートを作成しようとすると、Google Cloud がエラーを返します。

内部 TCP / UDP ロードバランサ ネクストホップは、転送ルールに関連付けられた内部 IP アドレスではなく、転送ルールの名前とロードバランサのリージョンを使用して指定します。

内部 TCP / UDP ロードバランサを参照するネクストホップのあるルートを作成した後は、まずそのルートを削除しない限り、ロードバランサを削除できなくなります。たとえば、内部転送ルールをネクストホップとして使用しているカスタム静的ルートがすべて削除されるまで、その転送ルールは削除できません。

バックエンドの要件

  • すべての内部 TCP / UDP ロードバランサのバックエンド VM が IP 転送(--can-ip-forward = True)を許可するように構成する必要があります。詳細については、インスタンスとロードバランサのネクストホップに関する考慮事項をご覧ください。

  • バックエンドが Google Kubernetes Engine(GKE)ノードである内部 TCP / UDP ロードバランサをカスタム静的ルートのネクストホップとして使用することはできません。ノード上のソフトウェアは、宛先がクラスタによって管理されている IP アドレスと一致していて任意でない場合のみ、ポッドにトラフィックをルーティングできます。

TCP、UDP、およびその他のプロトコル トラフィックの処理

内部 TCP / UDP ロードバランサをネクストホップとしてデプロイする場合、Google Cloud は、以下の構成にかかわらず、すべてのポート上のすべての TCP と UDP トラフィックをバックエンド VM に転送します。

  • 転送ルールのプロトコルとポート構成
  • バックエンド サービスのプロトコル構成

ロードバランサは TCP と UDP のトラフィックのみを処理し、ICMP などの他のトラフィックはすべて無視します。TCP プロトコルまたは UDP プロトコルを使用しないトラフィックは、VPC ネットワーク内の次の最も狭いルートによって処理されます。TCP と UDP 以外のトラフィックのルートには次の特徴があります。

  • ネクストホップとしての内部 TCP/UDP ロードバランサはありません。
  • これらはルーティング順序に従って選択されます。

たとえば、VPC ネットワークに次のルートがあるとします。

  • 宛先: 1.1.1.1/32、ネクストホップ: 内部 TCP/UDP ロードバランサ
  • 宛先: 1.0.0.0/8、ネクストホップ: デフォルトのインターネット ゲートウェイ

ロードバランサと同じリージョン(またはグローバル アクセスが有効な場合は任意のリージョン)にあるクライアントの場合、1.1.1.1/32 宛ての TCP および UDP トラフィックは、内部 TCP/UDP ロードバランサのネクストホップを持つルートを使用します。

非 TCP および非 UDP トラフィック(ICMP ping など)の場合、代わりに 1.0.0.0/8 ルートが使用されます。

その他の仕様

  • 内部 TCP / UDP ロードバランサをネクストホップとして使用しているカスタム静的ルートでは、ネットワーク タグを使用できません。

  • 同じ優先度、同じ宛先、同じ内部 TCP / UDP ロードバランサ ネクストホップを使用して、複数のカスタム静的ルートを作成することはできません。 したがって、同じネクストホップ ロードバランサを持つ複数のカスタム静的ルートには、少なくとも、それぞれ固有の宛先または固有の優先度のいずれかを設定する必要があります。

  • 同じ宛先と優先度を持つ複数のルートのネクストホップとして、異なる内部 TCP/UDP ロードバランサがある場合、Google Cloud はロードバランサ間でトラフィックを分散しません。代わりに Google Cloud は、宛先と一致するすべてのトラフィックのネクストホップとして 1 つのロードバランサのみを選択し、他のロードバランサは無視します。

  • 内部 TCP/UDP ロードバランサをカスタム静的ルートのネクストホップとして使用している場合、内部転送ルールの IP アドレスで --purpose=SHARED_LOADBALANCER_VIP フラグを使用することはできません。これは、共有される内部 IP アドレスが間接的に複数のバックエンド サービスを参照できるためです。

詳細については、ルートの概要をご覧ください。

使用例

内部 TCP / UDP ロードバランサは、複数のデプロイとトポロジで、ネクストホップとして使用できます。

以下に示す例では、次のガイドラインに留意してください。

  • 各 VM インターフェースが、別々の VPC ネットワークにある必要があります

  • バックエンド VM やロードバランサを使用して同じ VPC ネットワーク内のサブネットの間のトラフィックはルーティングできません。サブネット ルートのオーバーライドができないからです。

  • 内部 TCP / UDP ロードバランサは、ソフトウェア定義のパススルー ロードバランサです。ファイアウォール仮想アプライアンスであるバックエンド VM によってのみ NAT とプロキシが実行されます。

NAT ゲートウェイへのネクストホップとして内部 TCP / UDP ロードバランサを使用

このユースケースでは、内部 VM からインターネットにトラフィックをルーティングする複数の NAT ゲートウェイ インスタンスへのトラフィックを負荷分散しています。

NAT のユースケース(クリックして拡大)
NAT のユースケース(クリックして拡大)

ハブアンドスポーク: VPC ネットワーク ピアリングを使用したネクストホップ ルートの交換

サブネット ルートの交換に加えて、VPC ネットワーク ピアリングを構成して、カスタム静的ルートと動的ルートをエクスポートおよびインポートできます。ネットワーク タグを使用する、またはデフォルト インターネット ゲートウェイのネクストホップを持つカスタム静的ルートは除外されます。

次のようにすることで、hub VPC ネットワーク内のネクストホップ ファイアウォール仮想アプライアンスで、ハブアンドスポーク トポロジを構成できます。

  • hub VPC ネットワークで、ファイアウォール仮想アプライアンスをバックエンドとして使用して内部 TCP / UDP ロードバランサを作成します。
  • hub VPC ネットワークで、カスタム静的ルートを作成して、内部 TCP / UDP ロードバランサにネクストホップを設定します。
  • VPC ネットワーク ピアリングを使用して、hub VPC ネットワークを各 spoke VPC ネットワークに接続します。
  • ピアリングごとに、カスタムルートをエクスポートするように hub ネットワークを構成し、カスタムルートをインポートするように対応する spoke ネットワークを構成します。ロードバランサのネクストホップを持つルートは、hub ネットワークがエクスポートするルートの 1 つです。

hub VPC ネットワーク内にある、ネクストホップのファイアウォール アプライアンス ロードバランサは、ルーティング順序に従って、各 spoke ネットワークで使用できます。

ハブアンドスポーク(クリックして拡大)
ハブアンドスポーク(クリックして拡大)

複数の NIC への負荷分散

このユースケースでは、バックエンド VM は複数の VPC ネットワークに NIC を持つ仮想アプライアンス インスタンス(たとえば、ファイアウォール インスタンスや NAT ゲートウェイ)です。ファイアウォール インスタンスと NAT ゲートウェイは、仮想アプライアンスとしてサードパーティによって提供されます。仮想アプライアンスは、複数の NIC を持つ Compute Engine VM です。

この例では、マネージド VM インスタンス グループにある単一セットのバックエンド仮想アプライアンスを示します。

testing という VPC ネットワークで、内部 TCP / UDP ロードバランサには fr-ilb1 という転送ルールがあります。この例で示すロードバランサは、各仮想アプライアンス上の nic0 インターフェースにトラフィックを分散しますが、これはいずれの NIC でも可能です。

production という VPC ネットワークで、異なる内部 TCP / UDP ロードバランサには fr-ilb2 という転送ルールがあります。このロードバランサは異なるインターフェース(ここでは nic1)にトラフィックを分散します。

複数の NIC に負荷分散するトラフィック(クリックして拡大)
複数の NIC に負荷分散するトラフィック(クリックして拡大)

構成の設定についての詳細は、複数のバックエンド NIC への負荷分散をご覧ください。

内部 TCP / UDP ロードバランサを、単一の NIC を持つネクストホップとして使用

前述のユースケースのように、バックエンド VM は複数の VPC ネットワークに NIC を持つ仮想アプライアンス インスタンス(たとえば、ファイアウォール インスタンスや NAT ゲートウェイ)です。

次の例は、2 つのマネージド VM インスタンス グループのバックエンド仮想アプライアンスを示しています。

バックエンドの概要は次のとおりです。

testing から production へのトラフィックの負荷分散インスタンス production から testing へのトラフィックの負荷分散インスタンス
fw-instance-a
fw-instance-b
fw-instance-c
fw-instance-d
fw-instance-e
fw-instance-f

testing から production へのトラフィックは testing という VPC ネットワークで発生します。testing ネットワークでは、内部 TCP / UDP ロードバランサに fr-ilb1 という転送ルールがあります。この例では、指定された network パラメータを含まないバックエンド サービスで、内部 TCP / UDP ロードバランサを使用しています。つまり、各ロードバランサは各バックエンド VM のプライマリ ネットワーク インターフェースにのみトラフィックを配信します。

単一の NIC に負荷分散するトラフィック(<code>testing</code> から <code>production</code> へ)(クリックして拡大)
単一の NIC に負荷分散するトラフィック(testing から production へ)(クリックして拡大)

production から testing へのトラフィックは production という VPC ネットワークで発生します。production ネットワークでは、異なる内部 TCP / UDP ロードバランサに fr-ilb2 という転送ルールがあります。この例でも、指定された network パラメータを含まないバックエンド サービスで、内部 TCP / UDP ロードバランサを使用しています。つまり、各ロードバランサは各バックエンド VM のプライマリ ネットワーク インターフェースにのみトラフィックを配信します。各仮想アプライアンスには nic0 が 1 つしかないため、このデプロイには 2 つ目の仮想アプライアンスが必要です。1 つ目は testing から production への負荷分散、2 つ目は testing から production への負荷分散に使用します。

単一の NIC に負荷分散するトラフィック(<code>production</code> から <code>testing</code> へ)(クリックして拡大)
単一の NIC に負荷分散するトラフィック(production から testing へ)(クリックして拡大)

次のステップ