Internes HTTP(S)-Load-Balancing und verbundene Netzwerke

Auf dieser Seite werden Szenarien für den Zugriff auf einen internen Load-Balancer in Ihrem Virtual Private Cloud-Netzwerk (VPC) über ein verbundenes Netzwerk beschrieben. Bevor Sie sich die Informationen auf dieser Seite ansehen, sollten Sie mit den Konzepten in der folgenden Anleitung vertraut sein:

VPC-Netzwerk-Peering verwenden

Wenn Sie VPC-Netzwerk-Peering verwenden, um Ihr VPC-Netzwerk mit einem anderen Netzwerk zu verbinden, teilt Google Cloud die Subnetzrouten zwischen den Netzwerken. Über die Subnetzrouten kann der Traffic vom Peer-Netzwerk interne Load-Balancer in Ihrem Netzwerk erreichen. Der Zugriff ist nur möglich, wenn Folgendes zutrifft:

  • Für interne TCP/UDP-Load-Balancer und interne HTTP(S)-Load-Balancer müssen Sie Firewallregeln für eingehenden Traffic erstellen, um Traffic von Client-VMs im Peer-Netzwerk zuzulassen. Firewallregeln von Google Cloud werden nicht zwischen Netzwerken geteilt, wenn VPC-Netzwerk-Peering verwendet wird.
  • Client-VM-Instanzen im Peer-Netzwerk befinden sich in derselben Region wie Ihr interner Load-Balancer, es sei denn, Sie konfigurieren nur für den internen TCP/UDP-Load-Balancer globalen Zugriff. Wenn Sie den globalen Zugriff konfiguriert haben, können Client-VM-Instanzen von jeder Region des Peering-VPC-Netzwerks auf Ihren internen TCP/UDP-Load-Balancer zugreifen. Globaler Zugriff wird nicht für internes HTTP(S)-Load-Balancing unterstützt.

Es ist nicht möglich, mit VPC-Netzwerk-Peering nur einige der internen TCP/UDP-Load-Balancer oder internen HTTP(S)-Load-Balancer selektiv freizugeben. Alle internen Load-Balancer werden automatisch freigegeben. Sie können den Zugriff auf die Back-Ends des Load-Balancers auf folgende Arten beschränken:

  • Für interne TCP/UDP-Load-Balancer können Sie die Firewallregeln für Back-End-VM-Instanzen verwenden.

  • Für interne HTTP(S)-Load-Balancer können Sie die Back-End-VMs oder -Endpunkte so konfigurieren, dass der Zugriff über HTTP-Header gesteuert wird, z. B. X-Forwarded-For.

Cloud VPN und Cloud Interconnect verwenden

Sie können über ein Peer-Netzwerk, das über einen Cloud VPN-Tunnel oder Interconnect-Anhang (VLAN) über Dedicated Interconnect oder Partner Interconnect verbunden ist, auf einen internen Load-Balancer zugreifen. Das Peer-Netzwerk kann ein lokales Netzwerk, ein weiteres Google Cloud-VPC-Netzwerk oder ein virtuelles Netzwerk sein, das von einem anderen Cloud-Anbieter gehostet wird.

Zugriff über Cloud VPN-Tunnel

Sie können über einen Cloud VPN-Tunnel auf einen internen Load-Balancer zugreifen, wenn alle der folgenden Bedingungen erfüllt sind.

Im Netzwerk des internen Load-Balancers

  • Sowohl das Cloud VPN-Gateway als auch der Tunnel befinden sich in derselben Region wie die Komponenten des internen Load-Balancers, es sei denn, Sie konfigurieren nur für den internen TCP/UDP-Load-Balancer globalen Zugriff.

  • Routen leiten den ausgehenden Traffic zurück zum Peer-Netzwerk bzw. Clientnetzwerk. Wenn Sie Cloud VPN-Tunnel mit dynamischem Routing verwenden, beachten Sie den Modus für dynamisches Routing des Cloud VPN-Netzwerks des Load-Balancers. Der Modus für dynamisches Routing bestimmt, welche benutzerdefinierten dynamischen Routen für die Back-Ends verfügbar sind.

  • Für den internen TCP/UDP-Load-Balancer haben Sie Firewallregeln konfiguriert, sodass lokale Clients mit den Back-End-VMs des Load-Balancers kommunizieren können.

Im Peer-Netzwerk

Das Peer-Netzwerk muss mindestens einen Cloud VPN-Tunnel mit Routen zum Subnetz haben, in dem der interne Load-Balancer definiert ist.

Wenn das Peer-Netzwerk ein anderes Google Cloud VPC-Netzwerk ist:

  • Das Cloud VPN-Gateway des Peer-Netzwerks kann sich in einer beliebigen Region befinden.

  • Bei Cloud VPN-Tunneln, die dynamisches Routing verwenden, bestimmt der Modus für dynamisches Routing des VPC-Netzwerks, welche Routen den Clients in den einzelnen Regionen zur Verfügung stehen. Mit dem globalen Modus für dynamisches Routing können Sie konsistente benutzerdefinierte dynamische Routen für Clients in allen Regionen bereitstellen.

Das folgende Diagramm zeigt die wichtigsten Konzepte beim Zugriff auf einen internen Load-Balancer über ein Cloud VPN-Gateway und den zugehörigen Tunnel. Cloud VPN verbindet Ihr lokales Netzwerk über Cloud VPN-Tunnel sicher mit Ihrem Google Cloud VPC-Netzwerk.

Das Diagramm zeigt die Einrichtung eines internen TCP/UDP-Load-Balancers. Beim internen HTTP(S)-Load-Balancer sind Cloud VPN und Cloud Router identisch, aber die Load-Balancing-Ressourcen unterscheiden sich. Das Einrichten eines internen HTTP(S)-Load-Balancers erfordert beispielsweise eine andere Art von Weiterleitungsregel, Ziel-Proxy und URL-Zuordnung.
Internes TCP/UDP-Load-Balancing und Cloud-VPN (zum Vergrößern klicken)
Internes Load-Balancing und Cloud VPN (zum Vergrößern klicken)

Beachten Sie die folgenden Konfigurationselemente, die mit diesem Beispiel verknüpft sind:

  • Im lb-network wurde ein Cloud VPN-Tunnel mit dynamischem Routing konfiguriert. VPN-Tunnel, Gateway und Cloud Router befinden sich alle in us-west1. Das ist dieselbe Region, in der sich die Komponenten des internen Load-Balancers befinden.
  • Firewallregeln für eingehenden Traffic wurden für die Back-End-VMs in den Instanzgruppen ig-a und ig-c konfiguriert. Auf diese Weise können sie Traffic von IP-Adressen im VPC-Netzwerk und vom lokalen Netzwerk empfangen (10.1.2.0/24 und 192.168.1.0/24). Es wurden keine Firewallregeln für abzulehnenden ausgehenden Traffic erstellt. Daher gilt die implizierte Richtlinie zum Zulassen von ausgehendem Traffic.
  • Pakete, die von Clients in den lokalen Netzwerken gesendet werden, zum Beispiel von 192.168.1.0/24 an die IP-Adresse des internen Load-Balancers 10.1.2.99, werden entsprechend der konfigurierten Sitzungsaffinität direkt an eine intakte Back-End-VM wie vm-a2 zugestellt.
  • Antworten, die von den Back-End-VMs wie vm-a2 gesendet werden, werden über den VPN-Tunnel an die lokalen Clients zugestellt.

Informationen zur Fehlerbehebung bei Cloud VPN finden Sie unter Cloud VPN-Fehlerbehebung.

Zugriff über Cloud Interconnect

Es ist möglich, von einem lokalen Peer-Netzwerk, das mit dem VPC-Netzwerk des Load-Balancers verbunden ist, auf einen internen Load-Balancer zuzugreifen. Dafür müssen im Netzwerk des Load Balancers die folgenden Bedingungen erfüllt sein:

  • Sowohl der Interconnect-Anhang (VLAN) als auch der Cloud Router befinden sich in derselben Region wie die Komponenten des Load-Balancers, es sei denn, Sie konfigurieren nur für den internen TCP/UDP-Load-Balancer globalen Zugriff.

  • Lokale Router verwenden gemeinsame geeignete Routen, die als Rücksendepfade für Antworten von Back-End-VMs an die lokalen Clients dienen. Interconnect-Anhänge (VLANs) für Dedicated Interconnect und Partner Interconnect verwenden Cloud Router. Welche dynamischen Routen erlernt werden, hängt vom Modus für dynamisches Routing des Netzwerks des Load-Balancers ab.

  • Für den internen TCP/UDP-Load-Balancer haben Sie Firewallregeln konfiguriert, sodass lokale Clients mit den Back-End-VMs des Load-Balancers kommunizieren können.

Im lokalen Netzwerk muss mindestens ein Interconnect-Anhang (VLAN) mit geeigneten Routen vorhanden sein. Die Ziele der Routen enthalten das Subnetz, in dem der interne Load-Balancer definiert ist. Firewallregeln für ausgehenden Traffic müssen ebenfalls entsprechend konfiguriert werden.

Mehrere Pfade für ausgehenden Traffic

In Produktionsumgebungen sollten Sie mehrere Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge (VLANs) verwenden, um Redundanz zu gewährleisten. In diesem Abschnitt werden die Anforderungen bei der Verwendung mehrerer Tunnel oder VLANs erläutert.

Im folgenden Diagramm verbinden zwei Cloud VPN-Tunnel lb-network mit einem lokalen Netzwerk. Hier werden Cloud VPN-Tunnel verwendet. Dieselben Prinzipien gelten jedoch auch für Cloud Interconnect.

Internes TCP/UDP-Load-Balancing und mehrere Cloud VPN-Tunnel (zum Vergrößern klicken)
Internes Load-Balancing und mehrere Cloud VPN-Tunnel (zum Vergrößern klicken)

Sie müssen jeden Tunnel oder jeden Cloud Interconnect-Anhang (VLAN) in derselben Region konfigurieren wie der interne Load-Balancer, es sei denn, Sie haben für das interne TCP/UDP-Load-Balancing den globalen Zugriff aktiviert. Mehrere Tunnel oder VLANs können zusätzliche Bandbreite bieten oder als Standbypfade dienen, um Redundanz zu ermöglichen.

Beachten Sie die folgenden Aspekte:

  • Traffic kann vom lokalen Netzwerk 192.168.1.0/24 an den Load-Balancer mit equal-cost multipath (ECMP) gesendet werden. Dafür muss das lokale Netzwerk zwei Routen mit gleicher Priorität und dem Ziel 10.1.2.0/24 haben. Ein nächster Hop muss ein anderer VPN-Tunnel sein, der sich in derselben Region wie der interne Load-Balancer befindet.
  • Nachdem die Pakete an das VPC-Netzwerk zugestellt wurden, werden sie vom internen Load-Balancer entsprechend der konfigurierten Sitzungsaffinität an Back-End-VMs verteilt.
  • Die Antworten von Back-End-VMs können nach der Priorität der Routen im Netzwerk über verschiedene Tunnel zugestellt werden. Dafür muss das Netzwerk lb-network zwei Routen jeweils mit dem Ziel 192.168.1.0/24 und einem nächsten Hop haben, der verschiedenen VPN-Tunneln entspricht. Wenn unterschiedliche Prioritäten für die Routen verwendet werden, kann ein Tunnel als Sicherung für die andere Route dienen. Werden dieselben Prioritäten verwendet, werden Antworten über ECMP zugestellt.
  • Von den Back-End-VMs (etwa vm-a2) gesendete Antworten werden den lokalen Clients über den entsprechenden VPN-Tunnel direkt zugestellt. Wenn sich Routen oder VPN-Tunnel aus Sicht von lb-network ändern, wird der ausgehende Traffic möglicherweise über einen anderen Tunnel übertragen. Wenn dabei eine laufende Verbindung unterbrochen wird, kann es vorkommen, dass TCP-Sitzungen zurückgesetzt werden.

Weitere Informationen