内部 TCP / UDP 負荷分散と接続されたネットワーク

概要

このページでは、VPC ネットワークに接続されたネットワークから、VPC ネットワークの内部 TCP / UDP ロードバランサにアクセスする場合のシナリオを説明します。このページの情報を確認する前に、内部 TCP / UDP 負荷分散のコンセプトを理解しておいてください。

VPC ネットワーク ピアリングの使用

VPC ネットワーク ピアリングを使用して VPC ネットワークを別のネットワークに接続すると、GCP はネットワーク間のサブネット ルートを共有します。このサブネット ルートによって、ピア ネットワークからのトラフィックはネットワークの内部 TCP / UDP ロードバランサに到達できます。ロードバランサへのアクセスが可能なのは、次の条件を満たす場合です。

  • ピア ネットワーク内のクライアント VM が内部 TCP / UDP ロードバランサと同じリージョンにある。
  • 上りのファイアウォール ルールが、ピア ネットワーク内のクライアント VM からのトラフィックを許可している。VPC ネットワーク ピアリングを使用する場合、GCP はネットワーク間でファイアウォール ルールを共有しません

VPC ネットワーク ピアリングを使用して、一部の内部 TCP / UDP ロードバランサのみを選択的に共有することはできません。ただし、ファイアウォール ルールを使用して、ロードバランサのバックエンド VM インスタンスへのアクセスを制限することは可能です。

Cloud VPN と Cloud Interconnect の使用

Dedicated Interconnect または Partner InterconnectCloud VPN トンネルまたは VLAN アタッチメントを介して接続されたピア ネットワークから、内部 TCP / UDP ロードバランサにアクセスできます。ピア ネットワークは、オンプレミス ネットワーク、別の GCP VPC ネットワーク、別のクラウド プロバイダがホストする仮想ネットワークのいずれでもかまいません。

Cloud VPN トンネルを介したアクセス

内部 TCP / UDP ロードバランサのネットワークにおいて次のすべての条件が満たされる場合、Cloud VPN トンネルを介して内部 TCP / UDP ロードバランサにアクセスできます。

  • Cloud VPN ゲートウェイとトンネルが内部 TCP / UDP ロードバランサのコンポーネントと同じリージョンにある。

  • 適切なルートにより、ロードバランサ トラフィックの発生元にあたるクライアントに戻る下りトラフィックのパスが提供されている。動的ルーティングを使用する Cloud VPN トンネルの場合、この目的を果たすカスタム動的ルートの管理には Cloud Router を使用します。静的ルーティングを使用する Cloud VPN トンネルの場合、カスタムの静的ルートが必要になります。カスタムの静的ルートは、GCP Console を使用してトンネルを作成すると自動的に作成されます。

  • 上りファイアウォール ルールでは バックエンド VM へのトラフィックが許可されていて、下りファイアウォール ルールでは、バックエンドからオンプレミス クライアントへレスポンスを送信することが許可されている。

  • ピア ネットワークには、適切なルートの Cloud VPN トンネルが少なくとも 1 つ存在する。ルートの宛先には、内部 TCP / UDP ロードバランサが定義されているサブネットを含め、ルートのネクストホップにはこの VPN トンネルを使用します。具体的な説明は次のとおりです。

    • ピア ネットワークも GCP VPC ネットワークである場合、その Cloud VPN トンネルとゲートウェイは任意のリージョンに配置できます。

    • ピア ネットワーク内のクライアントが、任意のリージョンにある Cloud VPN に接続できるようにするには、その VPN ゲートウェイの Cloud VPN トンネルに、ロードバランサが設置されたネットワークへのルートが存在する必要があります。動的ルーティングを使用する Cloud VPN トンネルの場合は、VPC ネットワークでグローバル動的ルーティング モードが使用されていることを確認してください。これにより、Cloud Router が学習したそのトンネルのカスタム動的ルートを、すべてのリージョンの VM で使用できるようになります。

次の図は、Cloud VPN ゲートウェイとその関連トンネルを介して内部 TCP / UDP ロードバランサにアクセスする場合の主要なコンセプトの関係を示しています。Cloud VPN は、IPsec VPN 接続を使用してオンプレミス ネットワークを GCP VPC ネットワークに安全に接続します。

内部 TCP / UDP 負荷分散と Cloud VPN(クリックして拡大)
内部 TCP / UDP 負荷分散と Cloud VPN(クリックして拡大)

この例に関連する次の構成要素に注意してください。

  • lb-network では、動的ルーティングを使用する Cloud VPN トンネルが構成されている。VPN トンネル、ゲートウェイ、Cloud Router はすべて、内部 TCP / UDP ロードバランサのコンポーネントと同じリージョン us-west1 に配置されている。
  • 上り許可のファイアウォール ルールは、インスタンス グループ ig-aig-c の両方にあるバックエンド VM に適用されるように構成されていて、これらの VM は、VPC 内の IP アドレスからのトラフィックと、オンプレミス ネットワークからのトラフィック(10.1.2.0/24192.168.1.0/24)を受信することができる。下り拒否のファイアウォール ルールは作成されていないため、暗黙の下り許可ルールが適用されている。
  • 192.168.1.0/24 などのオンプレミス ネットワーク内のクライアントから内部 TCP / UDP ロードバランサの IP アドレス(10.1.2.99)に送信されたパケットは、セッション アフィニティの構成に基づいて、vm-a2 などの正常なバックエンド VM に直接配信される。詳しくは、TCP / UDP 負荷分散のコンセプトのページをご覧ください。
  • バックエンド VM(vm-a2 など)からの返信は、VPN トンネルを介してオンプレミス クライアントに送られる。

Cloud Interconnect を介したアクセス

ロードバランサの VPC ネットワークに接続されたオンプレミスのピア ネットワークから、内部 TCP / UDP ロードバランサへのアクセスは、ロードバランサのネットワークで次のすべての条件が満たされる場合に可能になります。

  • TCP / UDP 内部ロードバランサのネットワークにおいて、VLAN アタッチメントと Cloud Router の両方がロードバランサのコンポーネントと同じリージョンにある。

  • バックエンド VM からオンプレミス クライアントへの応答のリターンパスを提供する適切なルートが、オンプレミス ルーターによって共有されている。Dedicated Interconnect と Partner Interconnect の両方の VLAN アタッチメントにおいて、オンプレミス ルーターから学習したルートの管理に Cloud Router が使用されている。

  • 上りファイアウォール ルールでバックエンド VM へのトラフィックを、下りのファイアウォール ルールでバックエンド VM から応答を送信することをそれぞれ許可している。

オンプレミス ピア ネットワークのルーティング ルールとファイアウォール ルールにより、VPC ネットワーク内のバックエンド VM との通信が可能になります。VLAN アタッチメントにアクセスするピア ネットワークのクライアントと、ピア ネットワークが内部 TCP / UDP ロードバランサにアクセスするための Cloud Router は、ロードバランサと同じリージョンに配置する必要はありません。Cloud VPN トンネルを介してロードバランサにアクセスする場合と同じコンセプトが適用されます。

複数の下りパス

前のセクションでは、1 つのトンネルと 1 つの VLAN アタッチメントの例が示されていました。しかし、本番環境では冗長性のために複数のトンネルやアタッチメントが使用されます。このセクションでは、Cloud Interconnect に複数の Cloud VPN トンネルや VLAN アタッチメントを使用して VPC ネットワークをピア ネットワークに接続する場合の要件と推奨事項について説明します。

次の図では、2 つの Cloud VPN トンネルが lb-network をオンプレミス ネットワークに接続しています。ここでは Cloud VPN トンネルが使用されていますが、Cloud Interconnect にも同じ原則が当てはまります。

内部 TCP / UDP 負荷分散と複数の Cloud VPN トンネル(クリックして拡大)
内部 TCP / UDP 負荷分散と複数の Cloud VPN トンネル(クリックして拡大)

このドキュメントで説明するように、内部 TCP / UDP ロードバランサと同じリージョンにトンネルまたは VLAN アタッチメントをすべて配置する構成の場合は、ロードバランサ間とのトラフィック用に同時アクセス可能なパスを複数指定できます。この複数のパスは、追加の帯域幅として提供することも、冗長化のためのスタンバイパスとして機能させることもできます。

次の点に注意してください。

  • Cloud VPN トンネルは、常に特定の Cloud VPN ゲートウェイに関連付けられます。トンネルはゲートウェイなしで作成することはできません。Cloud Interconnect のアタッチメント(VLAN)も Cloud Interconnect に関連付けられています。VLAN アタッチメントと VPC ネットワークをご覧ください。

  • オンプレミス ネットワークに同じ優先順位のルートが 2 つあり、それぞれに 10.1.2.0/24 の宛先 IP アドレスが含まれていて、ネクストホップには内部 TCP / UDP ロードバランサと同じリージョン内の異なる VPN トンネルが指定されている場合、このオンプレミス ネットワーク(192.168.1.0/24)から ECMP を使用してロードバランサにトラフィックを送信できます。

  • パケットが VPC ネットワークに配信されると、内部 TCP / UDP ロードバランサは、セッション アフィニティの構成に従ってバックエンド VM にそれらを振り分けます。

  • 内部 TCP / UDP ロードバランサへの上りトラフィックの場合、VPN トンネルはロードバランサと同じリージョンになければなりません。

  • lb-network に 2 つのルートが 存在し、それぞれに 192.168.1.0/24 の宛先が含まれていて、ネクストホップには異なる VPN トンネルが指定されている場合、ネットワーク内のルートの優先順位に従って、バックエンド VM からのレスポンスを各トンネルを介して送信できます。ルートの優先順位が異なる場合は、一方のトンネルが他方のトンネルのバックアップとして機能します。同じ優先順位を使用する場合は、ECMP を使用してレスポンスが送られます。

  • バックエンド VM からの応答(vm-a2)は、適切なトンネルを介してオンプレミス クライアントに直接送られます。ルートや VPN トンネルが変更された場合、lb-network の視点から見て、下りのトラフィックが別のトンネルを使用することがあります。そのような場合に進行中の接続が中断されると、TCP セッションがリセットされる可能性があります。

次のステップ