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

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

このページの情報を確認する前に、次のコンセプトを理解しておく必要があります。

内部 TCP / UDP ロードバランサのネクストホップは、次のような場合に有用です。

  • ゲートウェイやルーター VM として動作している複数の VM 全体に、トラフィックを負荷分散する。

  • ゲートウェイ仮想アプライアンスを、デフォルト ルートのネクストホップとして使用する。この構成では、Virtual Private Cloud(VPC)ネットワーク内の仮想マシン(VM)インスタンスが、負荷分散された一連の仮想ゲートウェイ VM を介して、インターネットにトラフィックを送信します。

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

アーキテクチャ

次の図では、ルーター VM の VM インスタンス グループが 2 つの異なるロードバランサのバックエンドとして機能しています。1 つ目の内部 TCP / UDP 負荷分散では、バックエンド VM の nic0 にパケットを送信します。2 つ目の内部 TCP / UDP 負荷分散では、同じバックエンドの nic1 にパケットを送信します。

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

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

ルートが定義されている VPC ネットワークでは、ロードバランサが静的ルートのネクストホップの場合、クライアント VM のゲスト オペレーティング システムに特別な構成は必要ありません。クライアント VM は、Bump-in-the-Wire 方式で、VPC ネットワーク ルーティングを介してロードバランサのバックエンドにパケットを送信します。

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

仕様

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

ルート

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

ネクストホップを指定するオプション

ロードバランサをネクストホップとして指定するには、2 つのオプションがあります。

仕様オプション ネクストホップ ネットワーク ピアリングされるネットワークにエクスポート可能かどうか
転送ルールの名前とロードバランサのリージョン ネクストホップのロードバランサとルートは同じ VPC ネットワーク内にある必要があります。 カスタムルートをエクスポートすることで可能(タグなしのルートに適用)
転送ルールの内部 IP アドレス ネクストホップ ロードバランサは、ルートと同じ VPC ネットワーク、またはピアリングした VPC ネットワーク内に配置できます。 可能。常にエクスポートされます(ただし、タグを持つルートを除く)。

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

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

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

それに対して、静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用する場合、宛先 IP アドレスはさまざまです。これは、ロードバランサのバックエンド VM では、さまざまな宛先 IP アドレスが設定されたパケットを処理して転送するためです。こうした中でクライアント 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 ネットワーク全体のルーティング テーブルの一部であっても適用されます。グローバル アクセスを有効にすると、任意のリージョンのリソースでカスタム静的ルートを使用できます。

カスタム静的ルートのアドバタイズ

カスタム静的ルートの接頭辞(宛先)をアドバタイズするために、Cloud Router のカスタムルート アドバタイズを使用できます。ルート アドバタイズの範囲は、次のようにロードバランサのグローバル アクセス設定によって異なります。

  • グローバル アクセスが無効の場合、内部 TCP / UDP ロードバランサは、ロードバランサと同じリージョンにある VM、Cloud VPN トンネル、Cloud Interconnect アタッチメント(VLAN)からのみ使用できます。したがって、カスタム静的ルートの接頭辞のカスタム ルート アドバタイズは、Cloud Router とロードバランサが同じリージョンにある場合にのみ有効です。

  • グローバル アクセスが有効な場合、内部 TCP / UDP ロードバランサは、任意のリージョンにある VM、Cloud VPN トンネル、Cloud Interconnect アタッチメント(VLAN)から使用できます。グローバル動的ルーティングでは、オンプレミス システムが接続しているリージョンからカスタム静的ルートを使用できます。

次の表は、ロードバランサのアクセス可否についてまとめたものです。

グローバル アクセス VPC ネットワークの動的ルーティング モード ロードバランサへのアクセス
無効 リージョン 同じリージョンのルーターからアクセス可能
無効 グローバル 同じリージョンのルーターからアクセス可能
有効 リージョン 任意のリージョンの全ルーターからアクセス可能
有効 グローバル 任意のリージョンの全ルーターからアクセス可能

詳細については、内部 TCP / UDP 負荷分散と接続されたネットワークをご覧ください。

オペレーションの順序

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

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

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

バックエンドの要件

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

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

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

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

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

ルートのネクストホップである内部 TCP / UDP ロードバランサは、Google Cloud VPC ネットワークでサポートされるプロトコル(TCP、UDP、ICMP など)に対するすべてのトラフィックの転送をシームレスにサポートします。

その他の考慮事項

  • すべてのバックエンドが異常な場合。内部 TCP / UDP ロードバランサのすべてのバックエンドでヘルスチェックに失敗した場合でも、そのロードバランサのネクストホップを使用したルートは引き続き有効です。ルートで処理されるパケットは、トラフィック分配に従って、ネクストホップ ロードバランサのバックエンドの 1 つに送信されます。

  • 共通の内部 IP アドレス(--purpose=SHARED_LOADBALANCER_VIP)を使用する転送ルールがサポートされない。ネクストホップの内部 TCP / UDP ロードバランサと共通の IP アドレスを持つ内部 TCP / UDP ロードバランサの転送ルールは相互に排他的です。1 つのバックエンド サービス(1 つのロードバランサ)のみが確実に参照されるようにするため、ネクストホップの内部 TCP / UDP ロードバランサは、ロードバランサの転送ルールに固有の IP アドレスを使用する必要があります。共通の内部 IP アドレスを使用する転送ルールで、異なるバックエンド サービス(異なる内部 TCP / UDP ロードバランサ)を参照することは可能です。

  • 同じ宛先と複数のネクストホップの内部 TCP/UDP ロードバランサ。異なる内部 TCP / UDP ロードバランサ ネクストホップを使用して、同じ宛先で 2 つ以上のカスタム静的ルートを作成する場合、Google Cloud は ECMP を使用してロードバランサのネクストホップ間でトラフィックを分散しません。ルートの優先度が一意である場合、Google Cloud は、優先度が最も高いルートの内部 TCP / UDP ロードバランサを使用します。ルートの優先度が同じでも、ネクストホップは内部 TCP / UDP ロードバランサを 1 つだけ選択します。後者の状況では、以下の図に示すように、Google Cloud は決定論的な内部アルゴリズムを使用して単一のネクストホップ転送ルール(forwarding-rule-a)を選択し、同じ優先度を持つ他のルートを無視します。

    宛先が同じで、内部 TCP / UDP ロードバランサのネクストホップが異なる場合
    宛先が同じで、内部 TCP / UDP ロードバランサのネクストホップが異なる場合
  • 複数の宛先で、ネクストホップの内部 TCP / UDP ロードバランサが同じ場合。

    タグあり: ネットワーク タグを使用する場合は、同じ宛先と優先度を持つ複数のカスタム静的ルートに同じネクストホップ内部 TCP / UDP ロードバランサを使用できます。

    タグなし: ネットワーク タグがない場合、宛先、優先度、内部 TCP / UDP ロードバランサのネクストホップの同じ組み合わせを持つ複数のカスタム静的ルートを作成することはできません。たとえば、route-xroute-yroute-z は作成できますが、route-x-copy は作成できません。

    共通の内部 TCP / UDP ロードバランサのネクストホップを使用した、タグ付けられていないルートの例
    共通の内部 TCP / UDP ロードバランサのネクストホップを使用した、タグ付けられていないルートの例
  • ネットワーク タグ。ネットワーク タグを指定すると、タグで構成されたクライアント インスタンスにネクストホップ ルートのみを適用できます。これにより、タグ付きのネクストホップ ルートを適用するクライアント インスタンスと、トラフィックをルーティングするアプライアンスのセットを選択できます。

    複数のクライアント インスタンスを別々の VPC ネットワークに分離する必要はありません。それぞれが、アプライアンスのセットをフロントエンドする優先内部 TCP / UDP ロードバランサを指しています。

  • 同じ宛先プレフィックスへの複数のルート。タグを使用すると、異なる内部ロードバランサを持つ同じ宛先への複数のルートをネクストホップとして指定できます。同じ宛先ルートに対して、異なるタグや異なる優先度を使用できます。

ユースケース

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

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

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

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

  • 内部 TCP / UDP ロードバランサは、ソフトウェア定義のパススルー ロードバランサです。パケットは、送信元や宛先の情報(アドレスまたはアドレスとポート)を変更せずにバックエンド VM に配信されます。

    ルーティング、パケット フィルタリング、プロキシ、アドレス変換は、内部 TCP / UDP ロードバランサのバックエンドとして機能する仮想アプライアンス VM が担います。

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

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

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

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

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

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

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

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

  • グローバル アクセスが無効になっている場合は、ロードバランサと同じリージョンのクライアントから使用できます。
  • グローバル アクセスが有効になっている場合は、ルーティング順序に従って、すべてのリージョンのクライアントから使用できます。
ハブアンドスポーク(クリックして拡大)
ハブアンドスポーク(クリックして拡大)

複数の NIC への負荷分散

以下のユースケースでは、バックエンド VM は、複数の VPC ネットワークに NIC を持つ仮想アプライアンス インスタンス(パケット インスペクション、ルーティング、ゲートウェイ VM など)です。こうした仮想アプライアンス インスタンスには、サードパーティ製の商用ソリューションやお客様自身で構築したソリューションがあります。仮想アプライアンスは、複数の NIC を持つ Compute Engine VM です。

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

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

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

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

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

対称ハッシュ

上の例では、ソース ネットワーク アドレス変換(SNAT)は使用されません。Google Cloud では、対称ハッシュが使用されるため、SNAT は必要ありません。つまり、パケットが同じフローに属していると、Google Cloud では同じハッシュが算出されます。言い換えると、送信元 IP アドレスとポートの組が、宛先 IP アドレスとポートの組に変わってもハッシュは同じです。

注:

  • 2021 年 6 月 22 日以降に内部 TCP / UDP ロードバランサ転送ルールを作成すると、対称ハッシュが自動的に有効になります。

  • 既存の内部 TCP / UDP ロードバランサで対称ハッシュを有効にするには、対称ハッシュの有効化で説明されているように、転送ルールとネクストホップ ルートを再作成する必要があります。

  • 対称ハッシュは、内部 TCP / UDP 負荷分散でのみサポートされます。

  • プロトコル TCP と UDP に対しては、次のセッション アフィニティのタイプで対称ハッシュがサポートされています。

    • クライアント IP(2 タプル)
    • クライアント IP とプロトコル(3 タプル)
    • クライアント IP、プロトコル、ポート(5 タプル)
  • なんらかの理由でユースケースに SNAT が必要な場合は、状況に応じて使用できます。

次のステップ