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

内部パススルー ネットワーク ロードバランサは、内部 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 つの方法のいずれかを使用して指定できます。使用する指定方法によって、転送ルールのネットワークをルートのネットワークと一致させる必要があるかどうかと、転送ルールを配置できるプロジェクトが決まります。

    • 転送ルール名(--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 サービス プロジェクトに配置できます。

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

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

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

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

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

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

    インスタンス タグを使用する場合:

    インスタンス タグ(ネットワーク タグともいいます)を使用する場合、同じ宛先と優先度を持つ複数のカスタム静的ルートに同じネクストホップの内部パススルー ネットワーク ロードバランサを使用できます。

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

    同じ宛先、優先度、内部パススルー ネットワーク ロードバランサのネクストホップを使用して、インスタンス タグのない静的ルートを作成することはできません。
  • インスタンス タグ

    インスタンス タグ(ネットワーク タグとも呼ばれます)を指定すると、ネクストホップ ルートはタグを使用して構成されたクライアント インスタンスにのみ適用されます。これにより、タグ付きのネクストホップ ルートを適用するクライアント インスタンスと、トラフィックをルーティングするアプライアンスのセットを選択できます。

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

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

ユースケース

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

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

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

次のステップ