ネクストホップとしての内部パススルー ネットワーク ロードバランサ

内部パススルー ネットワーク ロードバランサは、内部 IP アドレスの背後でサービスを実行し、スケーリングできるリージョン ロードバランサです。内部パススルー ネットワーク ロードバランサは、最終宛先へのパスに沿ってパケットを転送する際のネクストホップとして使用できます。これを行うには、静的ルートでロードバランサをネクストホップに設定します。

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

内部パススルー ネットワーク ロードバランサのネクストホップは、次の場合に役立ちます。

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

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

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

アーキテクチャ

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

複数の NIC への負荷分散。
複数の NIC への負荷分散（クリックして拡大）。

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

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

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

仕様

内部パススルー ネットワーク ロードバランサをネクストホップとして使用するための仕様は次のとおりです。

ルート

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

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

内部パススルー ネットワーク ロードバランサのネクストホップは、次のいずれかの方法で指定できます。

  • 転送ルールの名前とリージョンを使用する
  • 転送ルールの IP アドレスを使用する

内部パススルー ネットワーク ロードバランサのネクストホップを配置できるプロジェクトと VPC ネットワークの詳細については、ネクストホップと機能をご覧ください。

VPC ネットワーク ピアリングを使用して、内部パススルー ネットワーク ロードバランサのネクストホップと静的ルートを交換できます。詳細については、静的ルートの交換オプションをご覧ください。

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

内部パススルー ネットワーク ロードバランサには、2 つの類似した「クライアント IP アドレス」セッション アフィニティ オプションが用意されています。

  • クライアント IP（CLIENT_IP）: パケットの送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュ。内部パススルー ネットワーク ロードバランサがルートのネクストホップではない場合、ロードバランサの転送ルールの IP アドレスに送信されたパケットは共通の宛先 IP アドレス（転送ルールの IP アドレス）を共有します。この状況では、2 タプルハッシュで使用されるアドレスの 1 つは一定になります。構成されたバックエンドの数が変更されず、パケットの送信元 IP アドレスが同一の場合は、この 2 タプルのセッション アフィニティ オプションによって同じバックエンドが選択されます。
  • クライアント IP、宛先なし（CLIENT_IP_NO_DESTINATION）: パケットの送信元 IP アドレスの 1 タプルハッシュ。内部パススルー ネットワーク ロードバランサをネクストホップとして使用する場合、宛先 IP アドレスはルートの destination 属性で指定されたアドレスになるため、多くの場合、宛先 IP アドレスは異なります。この場合、構成されたバックエンドと正常なバックエンドの数が変更されず、すべてのパケットに同じ送信元 IP アドレスがある場合でも、2 タプルハッシュのクライアント IP（CLIENT_IP）セッション アフィニティは同じバックエンドを選択できません（1 つのバックエンドのみが構成されている場合は例外で、このルールは適用されません。）同じ送信元 IP アドレスを持つパケットがを同じバックエンドにルーティングする必要がある場合は、クライアント IP、宛先なし（CLIENT_IP_NO_DESTINATION）セッション アフィニティ オプションを使用する必要があります。

送信先の範囲

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

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

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

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

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

静的ルートのアドバタイジング

静的ルートのプレフィックス（宛先）をアドバタイズするには、Cloud Router のカスタム アドバタイズ モードを使用します。ルート アドバタイズの範囲は、次のようにロードバランサのグローバル アクセス設定によって異なります。

  • グローバル アクセスが無効の場合、内部パススルー ネットワーク ロードバランサは、ロードバランサと同じリージョンにある VM、Cloud VPN トンネル、Cloud Interconnect アタッチメント（VLAN）でのみ使用できます。したがって、静的ルートのプレフィックスのカスタム ルート アドバタイズは、Cloud Router とロードバランサが同じリージョンにある場合にのみ有効です。

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

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

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

詳細については、内部パススルー ネットワーク ロードバランサと接続ネットワークをご覧ください。

オペレーションの順序

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

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

内部パススルー ネットワーク ロードバランサを参照するネクストホップのあるルートを作成した後は、まずそのルートを削除しない限り、ロードバランサを削除できなくなります。具体的には、そのロードバランサをネクストホップとして使用している静的ルートがなくならない限り、内部転送ルールを削除することはできません。

バックエンドの要件

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

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

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

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

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

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

その他の考慮事項

  • サポートされている転送ルールGoogle Cloud では、ネクストホップの内部パススルー ネットワーク ロードバランサの転送ルールのみがサポートされています。Google Cloud では、他のロードバランサ、プロトコル転送で使用される、または Private Service Connect エンドポイントとして使用されるネクストホップ転送ルールはサポートされていません。

  • 指定方法および転送ルール ネットワークとプロジェクト。ネクストホップ転送ルールは、次の 3 つの方法のいずれかを使用して指定できます。使用する指定方法によって、転送ルールのネットワークをルートのネットワークと一致させる必要があるかどうかと、転送ルールを配置できるプロジェクトが決まります。

    次のいずれかの方法を選択し、転送ルールの IP バージョンが、作成する静的ルートの IP バージョンと一致するようにします。

    • 転送ルール名（--next-hop-ilb）とリージョン（--next-hop-ilb-region）を使用: 名前とリージョンでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワークと一致する必要があります。転送ルールは、転送ルールのネットワークを含む同じプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）に配置する必要があります。

    • 転送ルールのリソースリンクを使用: 転送ルールのリソースリンクは、/projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME の形式を使用します。ここで、PROJECT_IDは転送ルールを含むプロジェクトのプロジェクト ID、REGION は転送ルールのリージョン、FORWARDING_RULE_NAME は転送ルールの名前です。このリソースリンクでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワークと一致する必要があります。転送ルールは、転送ルールのネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または共有 VPC サービス プロジェクトに配置できます。

    • 転送ルールの IP アドレスを使用: IPv4 または IPv6（プレビュー）アドレスでネクストホップ転送ルールを指定する場合、転送ルールのネットワークはルートの VPC ネットワーク、またはピアリングした VPC ネットワークになります。転送ルールは、転送ルールのネットワークを含むプロジェクト（スタンドアロン プロジェクトまたは共有 VPC ホスト プロジェクト）、または共有 VPC サービス プロジェクトに配置できます。

  • グローバル アクセスの影響。内部パススルー ネットワーク ロードバランサのネクストホップを使用するカスタム静的ルートは、すべてのリージョンでプログラムされます。ネクストホップを使用できるかどうかは、ロードバランサのグローバル アクセスの設定によって異なります。グローバル アクセスを有効にすると、VPC ネットワークのすべてのリージョンでロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、ロードバランサと同じリージョンでのみロードバランサのネクストホップがアクセス可能になります。グローバル アクセスを無効にすると、内部パススルー ネットワーク ロードバランサのネクストホップを使用して別のリージョンからルートに送信されるパケットは、破棄されます。

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

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

  • 同じ宛先と優先度の複数のルートがあり、ネクストホップの内部パススルー ネットワーク ロードバランサが異なる。Google Cloud は、ECMP を使用して 2 つ以上のネクストホップ内部パススルー ネットワーク ロードバランサ間でトラフィックを分散することはありません。代わりに、Google Cloud は決定論的な内部アルゴリズムを使用して、ネクストホップ内部パススルー ネットワーク ロードバランサを 1 つだけ選択します。このあいまいさを回避するには、ルートごとに一意のネットワーク タグを使用します。

    異なる内部パススルー ネットワーク ロードバランサのネクストホップを使用する静的ルートに同じ優先度と宛先が設定されている場合、Google Cloud は単一のネクストホップを選択します。

  • 同じ宛先、優先度、ネクストホップの内部パススルー ネットワーク ロードバランサを持つ複数のルート。ネットワーク タグがない場合、Google Cloud では、宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップの組み合わせが同じである静的ルートを複数作成することはできません。ネットワーク タグを使用すると、宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップの組み合わせが同じである静的ルートを複数作成できます。

ユースケース

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

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

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

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

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

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

内部パススルー ネットワーク ロードバランサを NAT ゲートウェイへのネクストホップとして使用する

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

NAT のユースケース。
NAT のユースケース（クリックして拡大）。

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

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

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

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

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

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

複数の NIC への負荷分散

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

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

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

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

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

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

対称ハッシュ

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

注:

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

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

  • 対称ハッシュは、内部パススルー ネットワーク ロードバランサでのみサポートされます。

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

    • クライアント IP（CLIENT_IP）
    • クライアント IP とプロトコル（CLIENT_IP_PROTO）
    • クライアント IP、プロトコル、ポート（CLIENT_IP_PORT_PROTO）

    これらの設定の詳細については、セッション アフィニティのオプションをご覧ください。

  • なんらかの理由でユースケースに SNAT が必要な場合は、状況に応じて使用できます。

次のステップ