内部 TCP / UDP 負荷分散のネクストホップのコンセプト

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

  • 内部専用仮想マシン インスタンスからインターネットへのトラフィックをルーティングできる内部ネットワーク アドレス変換(NAT)ゲートウェイ インスタンスが必要な場合。ネクストホップとしてロードバランサを使用すると、1 つの外部 IP アドレスを使用して複数の仮想マシン インスタンスからトラフィックを送信できます。ただし、インターネットには単一の仮想マシンしか公開されません。

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

概要

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

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

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

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

ロードバランサが静的ルートのネクストホップである場合は、ロードバランサや各バックエンド インスタンスにトラフィックを送信する設定をクライアントに対して明示的に行う必要はありません。バックエンド インスタンスは、Bump-in-the-Wire(BITW)方式で統合できます。

静的ルートのネクストホップに内部 TCP / UDP ロードバランサを使用すると、内部 TCP / UDP 負荷分散と同じメリットが得られます。たとえば、バックエンドはトラフィック需要に応じて適切にスケーリングされるため、高可用性が得られます。

ロードバランサのヘルスチェックにより、新しい接続が健全なバックエンド インスタンスに確実に転送されます。バックエンド インスタンスをマネージド インスタンス グループに追加することで、自動スケーリングを使用してサービスの需要に基づいてインスタンス セットを拡張したり縮小できます。内部 TCP / UDP 負荷分散では内部アドレスが使用されるため、パブリック IP アドレスをインターネットに公開する必要はありません。

仕様

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

  • クライアント IP のセッション アフィニティは、2 つのタプル間(ハッシュ関数のソース IP アドレスと宛先 IP アドレス)のアフィニティです。通常の内部 TCP ロードバランサの場合、宛先 IP アドレスはロードバランサの IP アドレスになり、単一のクライアント VM ソースからのパケットはすべて同じバックエンドに送信されます。宛先アドレスが同じであるためです。内部 TCP ロードバランサが宛先ではなくネクストホップになる場合、異なる宛先 IP アドレスが使用される場合があります。つまり、クライアント IP のセッション アフィニティを設定した場合でも、単一のクライアントからのトラフィックが複数のバックエンドに送信される可能性があります。

送信先の範囲

  • ルートの宛先が内部(RFC 1918)の IP 範囲である場合、宛先はサブネットのルートと同じにしたり、それ以上に設定できません。また、ロードバランサの転送ルールに関連付けられた内部 IP アドレスは、ルートの宛先とは異なるサブネットに属している必要があります。

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

内部 TCP / UDP ロードバランサは、リージョン リソースです。

  • 内部 TCP / UDP ロードバランサとそれをネクストホップとして使用するカスタム静的ルートは、同じ VPC ネットワーク内にある必要があります。

  • 内部 TCP / UDP ロードバランサをネクストホップとして使用するカスタム静的ルートは、ロードバランサと同じリージョン内のリソースでのみ使用できます。 このリージョンに関する制限は、ルート自体が VPC ネットワーク全体のルーティング テーブルの一部であっても適用されます。

ロードバランサはルートより前に作成される必要がある

ロードバランサがすでに存在する場合は、ネクストホップが内部 TCP / UDP ロードバランサであるカスタム静的ルートしか作成できません。存在しないロードバランサを参照するルートを作成しようとすると、ロードバランサ リソースが見つからないというエラー メッセージが表示されます。

ネクストホップが内部 TCP / UDP ロードバランサであるルートを作成した後は、ルートを削除しない限りロードバランサを削除できません。特に、ロードバランサをネクストホップとして使用するルートが存在しない場合を除き、ロードバランサの内部転送ルールの削除が禁止されます。

ルートの制限事項

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

  • GCP のルートの場合と同様に、内部 TCP / UDP ロードバランサのルートには 1 つのネクストホップしか指定できません。たとえば、--next-hop-ilbnext-hop-address の両方のルートを作成することはできません。

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

  • Equal Cost Multi Path(ECMP)ルーティングを使用して、複数の内部 TCP / UDP ロードバランサ間でトラフィックを分散することはできません。つまり、内部 TCP / UDP ロードバランサをネクストホップとして使用して、同じ宛先と優先度のルートを作成することはできません。

詳しくは、ルートの概要をご覧ください。

バックエンド要件

  • 内部 TCP / UDP ロードバランサのバックエンド VM は、IP 転送を許可するように設定する必要があります(--can-ip-forward = True)。詳しくは、ネクストホップとしてのインスタンスをご覧ください。
  • GKE バックエンドは、ネクストホップとして設定された内部 TCP / UDP ロードバランサではサポートされません。

すべての TCP および UDP トラフィック

ネクストホップとして内部 TCP / UDP ロードバランサを使用すると、すべての TCP トラフィックと UDP トラフィックがバックエンド VM に送信されます。これは、バックエンド サービスのプロトコル、転送ルールのプロトコル、転送ルールのポート仕様に関係なく成立します。

ユースケース

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

仮想アプライアンスの一部のユースケースには North-South トラフィックが含まれ、一部のユースケースには East-West トラフィックが含まれます。

North-South は、オンプレミス ネットワークまたは非 GCP VPC ネットワークに接続された GCP VPC ネットワークを意味します。

East-West は、相互に接続された GCP VPC ネットワークを意味します。

Cloud Interconnect(Dedicated または Partner)または Cloud VPN トンネルを使用すると、VPC ネットワークをオンプレミス ネットワークに接続できます。

以下の例では、次の点に注意してください。

  • ファイアウォール インスタンスは、複数の NIC の VM です。 各インターフェースは、同じ VPC ネットワークの別個のサブネットではなく、別個の VPC ネットワーク内に存在している必要があります。バックエンド VM やロードバランサを使用して同じ VPC ネットワーク内のサブネットの間のトラフィックはルーティングできません。サブネット ルートのオーバーライドができないからです。

  • 各ファイアウォールインスタンスのプライマリ ネットワーク インターフェース(nic0)は、内部 TCP / UDP ロードバランサと同じ VPC ネットワーク内にある必要があります。 内部 TCP / UDP ロードバランサは、バックエンド VM のプライマリ ネットワーク インターフェースにのみトラフィックを分散します。

  • ユースケースごとに示した 2 つの図はそれぞれペアになっています。

    • 1 つの図は、North-to-South のトラフィック フローと load balancer 1 を示しています。
    • もう 1 つの図は、South-to-North のトラフィック フローと load balancer 2 を示しています。

    内部 TCP / UDP 負荷分散ではトラフィックが各バックエンド VM の第 1 のネットワーク インターフェース(nic0)にのみ分散されるため、ロードバランサは 2 つ必要になります。

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

NAT ゲートウェイとしてのインスタンス

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

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

負荷分散された仮想アプライアンスを介した North-South トラフィックの例

このユースケースでは、バックエンド VM が複数の VPC ネットワークに NIC を持つファイアウォール インスタンスとして動作しています。これらのファイアウォール インスタンスは、仮想アプライアンスとしてサードパーティによって提供されます。オンプレミス システムは、Cloud VPN または Cloud Interconnect を使用して transit VPC ネットワークに接続されます。

例: オンプレミス ネットワークからの TCP トラフィックと確立されたレスポンス

10.0.5.100 のオンプレミス ノードにより、Compute Engine で実行中の 10.0.3.100 のインスタンスにパケットが送信されています。このパケットは次の図に示すようにルーティングされます。

North-to-South トラフィックの例(クリックして拡大)
North-to-South トラフィックの例(クリックして拡大)

リクエストパス

リクエスト パケットを VM インスタンスに送信するとき、パケットは次のようにルーティングされます。

  1. パケットが、オンプレミス ルーターから transit という名前の VPC ネットワークに向けて Cloud VPN トンネルまたは相互接続のアタッチメント(VLAN)を介して送信されます。10.0.3.0/24 のためのカスタムのルート アドバタイズを使用して、Cloud Router によってルートが提供されます。

  2. パケットは、transit VPC ネットワークに到着すると、10.0.3.0/24 を宛先とするカスタム静的ルートにより、fr-ilb1 転送ルールを使用するロードバランサに送信されます。

  3. GCP 内部 TCP / UDP 負荷分散はそのパケットを、正常なバックエンド VM のプライマリ インターフェース(nic0)に配信します。この例のバックエンド VM は、ファイアウォール仮想アプライアンスです。

  4. フィルタリング機能の実行に加え、ファイアウォール インスタンスにより、オペレーティング システム内で構成されたルーティングを使用してパケットが変更され、送信元ネットワーク アドレス変換(SNAT)が実行されます。SNAT は、パケットの送信元アドレスをファイアウォール インスタンスのセカンダリ ネットワーク インターフェースの IP アドレスに変更します(nic1)。このインスタンスは、production という名前の VPC ネットワーク内に配置されています。この例では、firewall-instance-a がパケットを処理し、ファイアウォール インスタンスがパケットのソースアドレスを 10.0.3.2 に変更しています。

  5. ファイアウォール インスタンスにより内部ルーティング テーブルが参照され、そのセカンダリ インターフェースからパケットが送信されます。

  6. production VPC ネットワーク内のサブネット ルートにより、パケットが 10.0.3.100 のサービス提供側のインスタンスに配信されます。受信パケットには、ファイアウォール インスタンスの nic1 に属する送信元の IP アドレス(10.0.3.2 など)と送信先のアドレス 10.0.3.100 が含まれています。

レスポンスパス

10.0.3.100 のサービス提供側インスタンスからオンプレミス システムに、確立されたレスポンス パケットが返される際、パケットは次のようにルーティングされます。

  1. サービス提供側インスタンスは SNAT が実行された後に受信パケットを受信するため、レスポンス パケットには、10.0.3.100 の送信元、およびファイアウォール インスタンスのセカンダリ ネットワーク インターフェース(nic1)に属する宛先 IP アドレスが含まれています。この例の場合、IP アドレスは 10.0.3.2 です。レスポンス パケットは、対応する受信パケットを配信したのと同じファイアウォール インスタンスに送信されます。このファイアウォール インスタンスに向けて、本番環境 VPC ネットワークのサブネット ルートからパケットが配信されます。

  2. ファイアウォール インスタンスのオペレーティング システム内で構成されたルーティングにより、パケットが変更されます。その際に、宛先ネットワーク アドレス変換(DNAT)が実行され、宛先が 10.0.5.100 に変更されます。ファイアウォール インスタンスにより内部ルーティング テーブルが参照され、パケットがインスタンスのプライマリ ネットワーク インターフェースに渡されます(nic0)。このインターフェースは、transit VPC ネットワーク内に配置されています。

  3. Cloud Router で学習された transit VPC ネットワーク内のカスタム動的ルートにより、Cloud VPN トンネルまたは Cloud Interconnect VLAN を介してオンプレミス ネットワークにパケットが送信されます。

  4. オンプレミス ネットワーク内のルーティングにより、10.0.5.100 のノードにパケットが配信されます。

例: GCP からの TCP トラフィックと確立されたレスポンス

10.0.3.100 のサービス提供側の GCP VM によりパケットが 10.0.5.100 のオンプレミス システムに送信される際、パケットは次のようにルーティングされます。

South-to-North トラフィックの例(クリックして拡大)
South-to-North トラフィックの例(クリックして拡大)

リクエストパス

  1. 本番環境の VPC ネットワークではパケットは、10.0.5.0/24 を宛先とするカスタム静的ルートから fr-ilb2 転送ルールを使用するロードバランサに送信されます。

  2. GCP 内部 TCP / UDP 負荷分散によりパケットは、ファイアウォールのインスタンスである正常なバックエンド VM のプライマリ インターフェース(nic0)に配信されます。

  3. ファイアウォール インスタンスのオペレーティング システム内で設定されたルーティングにより、パケットが変更されます。その際、送信元ネットワーク アドレス変換(SNAT)が実行され、パケットのソースアドレスがファイアウォール インスタンスのセカンダリ ネットワーク インターフェースの IP アドレスに変更されます(nic1)。このインターフェースは、transit VPC ネットワーク内に配置されています。この例では、パケットが firewall-instance-e により処理された場合、送信元 IP アドレスは 10.0.1.6 に変更されます。

  4. ファイアウォール インスタンスにより内部ルーティング テーブルが参照され、セカンダリ インターフェースからパケットが送信されます。

  5. Cloud Router で学習された transit VPC ネットワーク内のカスタム動的ルートにより、Cloud VPN トンネルまたは Cloud Interconnect VLAN を介してオンプレミス ネットワークにパケットが送信されます。

  6. オンプレミス ネットワーク内のルーティングにより、パケットが 10.0.5.100 に配信されます。

レスポンスパス

10.0.5.100 のオンプレミス システムが確立されたレスポンス パケットをサービング GCP VM に返すと、パケットは次のようにルーティングされます。

  1. オンプレミス システムは SNAT が実行された後に受信パケットを受信するため、レスポンス パケットには、10.0.5.100 の送信元 IP アドレス、およびファイアウォール インスタンスのセカンダリ ネットワーク インターフェース(nic1)に属する宛先 IP アドレスが含まれています。この例の場合、IP アドレスは 10.0.1.6 です。オンプレミス ルーターは、対応する受信パケットを配信したファイアウォールインスタンスに、Cloud VPN トンネルまたは相互接続のアタッチメント(VLAN)を介してレスポンス パケットを送信します。このルートは、transit VPC ネットワーク(10.0.1.0/24 など)のための、Cloud Router のアドバタイジング サブネット ルートで提供されます。

  2. パケットが transit 内の VPC ネットワークに到着すると、10.0.1.0/24 を宛先とするサブネットルートにより、ファイアウォール インスタンスのセカンダリ ネットワーク インターフェース(nic1)に属する IP アドレスにパケットが送信されます。この例の場合、IP アドレスは 10.0.1.6 です。レスポンス パケットは、対応する受信パケットを配信したのと同じファイアウォール インスタンスに送信されます。

  3. ファイアウォール インスタンスのオペレーティング システム内で設定されたルーティングにより、パケットが変更されます。その際、宛先ネットワーク アドレス変換(DNAT)が実行されます。その際、パケットの宛先アドレスが 10.0.3.100 に変更されます。ファイアウォール インスタンスにより内部ルーティング テーブルが参照され、パケットがインスタンスのプライマリ ネットワーク インターフェースに渡されます(nic0 )。このインターフェースは、本番環境 VPC ネットワーク内に配置されています。

  4. 本番環境 VPC ネットワーク内のサブネット ルートにより、パケットが 10.0.3.100 のサービス提供側のインスタンスに配信されます。

負荷分散された仮想アプライアンスを介した VPC ネットワーク間接続

前のシナリオと同様に、RFC 1918 の宛先プレフィックスを持つルートがソース VPC ネットワーク transit の VM インスタンスに、内部 TCP / UDP ロードバランサがネクストホップとして追加されます。

East-West トラフィック(クリックして拡大)
East-West トラフィック(クリックして拡大)

内部 TCP / UDP 負荷分散は、VPC ネットワーク production からのトラフィックの場合、別の内部 TCP / UDP ロードバランサの背後で別の負荷分散 VM インスタンスを使用する必要があります。内部 TCP / UDP ロードバランサがサポートするのは、バックエンド VM インスタンスのプライマリ インターフェース(nic0)のみだからです。

West-East トラフィック(クリックして拡大)
West-East トラフィック(クリックして拡大)

ハブとスポーク - VPC ピアリングによるネクストホップ ルートの交換

VPC Network Peering を使用すると、タグがない場合やネクストホップとして定義されたインターネット ゲートウェイがない場合、GCP は静的ルートと動的ルートの両方をエクスポートしてインポートできます。

Spoke VPC ネットワークでピアリングされた Hub VPC ネットワーク内のネクストホップ ファイアウォール仮想アプライアンスで、ハブアンドスポーク トポロジを設定できます。

その後、内部 TCP / UDP ロードバランサをハブ VPC ネットワークのネクストホップ ルートとして設定し、ピアリングした Spoke VPC ネットワークにエクスポートできます。内部 TCP / UDP ロードバランサ ネクストホップ リソースと内部 TCP / UDP ロードバランサ転送ルールリソースは、ハブ VPC ネットワークが所有します。

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

ルーティングの優先順位については、ルーティングの順序をご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...