Interner Passthrough-Network-Load-Balancer als nächster Hop

Ein interner Passthrough-Network-Load-Balancer ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren können. Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop verwenden, an den Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Dazu legen Sie den Load-Balancer als nächsten Hop in einer benutzerdefinierten statischen Route fest.

Bevor Sie sich die Informationen auf dieser Seite ansehen, sollten Sie mit den folgenden Themen vertraut sein:

• Routenübersicht
• Übersicht über internen Passthrough-Network-Load-Balancer

Ein interner Passthrough-Network-Load-Balancer als nächster Hop ist in den folgenden Fällen nützlich:

• Load-Balancing von Traffic auf mehrere VMs, die als Gateway- oder Router-VMs dienen.

• Verwenden vonvirtuellen Appliances als nächsten Hop für eine Standardroute. Bei dieser Konfiguration senden VM-Instanzen in Ihrem VPC-Netzwerk (Virtual Private Cloud) Traffic über eine Reihe von virtuellen Gateway-VMs mit Load-Balancing an das Internet.

• Traffic über mehrere Load-Balancer in zwei oder mehr Richtungen senden, indem Sie dieselbe Gruppe von Multi-NIC-Gateway- oder Router-VMs als Back-Ends verwenden. Erstellen Sie dazu einen Load-Balancer und verwenden Sie ihn als nächsten Hop für eine benutzerdefinierte statische Route in jedem VPC-Netzwerk. Jeder interne Passthrough-Network-Load-Balancer wird in einem einzelnen VPC-Netzwerk betrieben und verteilt den Traffic an die Netzwerkschnittstellen der Backend-VMs in diesem Netzwerk.

Hinweis: Dieses Feature unterstützt IPv6-Adressen nicht.

Architektur

Im folgenden Diagramm dient eine VM-Instanzengruppe von Router-VMs als Backend für zwei verschiedene Load-Balancer. Der erste interne Passthrough-Network-Load-Balancer sendet Pakete an nic0 der Backend-VMs und der zweite interne Passthrough-Network-Load-Balancer sendet Pakete an nic1 an denselben Backends.

Load-Balancing für mehrere NICs (zum Vergrößern klicken).

Vorteile der Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop

Wenn der Load-Balancer ein nächster Hop für eine statische Route ist, ist in den Gastbetriebssystemen der Client-VMs im VPC-Netzwerk, in dem die Route definiert ist, keine spezielle Konfiguration erforderlich. Client-VMs senden Pakete an das Backend des Load-Balancers über VPC-Netzwerkrouting mit der MethodeBump-in-the-Wire.

Die Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop für eine statische Route bietet dieselben Vorteile wie ein eigenständiger interner Passthrough-Network-Load-Balancer. Die Systemdiagnose des Load-Balancers sorgt dafür, dass neue Verbindungen an fehlerfreie Backend-VMs weitergeleitet werden. Wenn Sie eine verwaltete Instanzengruppe als Back-End verwenden, können Sie das Autoscaling so konfigurieren, dass die Gruppe VMs je nach Dienstanforderung erweitert oder verkleinert wird.

Spezifikationen

Im Folgenden finden Sie Spezifikationen für die Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop.

Routen

Sie können eine benutzerdefinierte statische Route erstellen, um TCP-, UDP- und anderen Protokolltraffic an einen internen Passthrough-Network-Load-Balancer zu übergeben, wobei der Load-Balancer der nächste Hop der statischen Route ist. Die Route kann ein externes (öffentlich weiterleitbares) CIDR-Präfix oder ein internes CIDR-Präfix sein, wenn das Präfix nicht mit einer Subnetzroute in Konflikt steht. So können Sie beispielsweise Ihre Standardroute 0.0.0.0/0 durch eine Route ersetzen, die Traffic zur Paketverarbeitung an Backend-VMs von Drittanbietern weiterleitet.

Vorsicht: Wenn Sie Traffic an Google APIs und Google-Dienste senden, leiten Sie den Traffic nicht über eine VM als nächster Hop oder einen internen Passthrough-Network-Load-Balancer als nächster Hop weiter. Leiten Sie diesen Traffic stattdessen über ein Standard-Internetgateway mit nächstem Hop weiter. Dazu gehört auch Traffic an Google APIs und Google-Dienste, der über den privaten Google-Zugriff gesendet wird.

Optionen zum Festlegen des nächsten Hops

Sie können einen internen Passthrough-Netzwerk-Load-Balancer als nächsten Hop angeben:

• Name und Region der Weiterleitungsregel verwenden
• IP-Adresse der Weiterleitungsregel verwenden

Weitere Informationen zum Projekt und zum VPC-Netzwerk, in dem sich ein interner Passthrough-Netzwerk-Load-Balancer befinden kann, finden Sie unter Nächste Hops und Features.

Sie können statische Routen mit internen Netzwerk-Load-Balancern als nächste Hops über VPC-Netzwerk-Peering austauschen. Weitere Informationen finden Sie unter Optionen für den Austausch statischer Routen.

Hinweis: Ein Load-Balancer, dessen Weiterleitungsregel das Protokoll L3_DEFAULT verwendet, kann nicht der nächste Hop für eine statische Route sein. Wenn diese statische Route erstellt wird, wird der Traffic ohne Rückmeldung verworfen.

Client-IP-Sitzungsaffinität

Interne Passthrough-Network-Load-Balancer bieten zwei ähnliche Optionen der Sitzungsaffinität für "Client-IP-Adressen":

• Client-IP (CLIENT_IP): Ein Zwei-Tupel-Hash der Quell-IP-Adresse und der Ziel-IP-Adresse eines Pakets. Wenn ein interner Passthrough-Network-Load-Balancer nicht der nächste Hop einer Route ist, haben Pakete, die an die IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden, eine gemeinsame Ziel-IP-Adresse: die IP-Adresse der Weiterleitungsregel. In diesem Fall bleibt eine der vom Zwei-Tupel-Hash verwendeten Adressen konstant. Wenn sich die Anzahl der konfigurierten und fehlerfreien Backends also nicht ändert und Pakete identische Quell-IP-Adressen haben, wählt diese Option für eine Zwei-Tupel-Sitzungsaffinität dasselbe Backend aus.
• Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION): Ein-Tupel-Hash der Quell-IP-Adresse eines Pakets. Wenn Sie einen internen Passthrough-Network-Load-Balancer als nächsten Hop verwenden, variiert die Ziel-IP-Adresse häufig, da die Ziel-IP-Adressen durch das Zielattribut der Route angegebenen sind. In diesem Fall kann die Zwei-Tupel-Hash-Sitzungsaffinität Client-IP (CLIENT_IP) nicht dasselbe Backend auswählen, auch wenn sich die Anzahl der konfigurierten und fehlerfreien Backends nicht ändert und Pakete identische Quell-IP-Adressen haben. Eine Ausnahme hiervon ist, wenn nur ein Backend konfiguriert ist. Wenn Pakete mit identischen Quell-IP-Adressen an dasselbe Backend weitergeleitet werden sollen, müssen Sie die Sitzungsaffinitätsoption Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION) verwenden.

Zielbereich

Das Ziel einer benutzerdefinierten statischen Route kann nicht gleich oder spezifischer als eine Subnetzroute sein. Beachten Sie, dass spezifischer bedeutet, dass die Subnetzmaske länger ist. Diese Regel gilt für alle benutzerdefinierten statischen Routen, auch wenn der nächste Hop ein interner Passthrough-Network-Load-Balancer ist. Angenommen, Ihre Subnetzroute ist 10.140.0.0/20. Das Ziel einer benutzerdefinierten statischen Route kann nicht identisch (10.140.0.0/20) und nicht spezifischer sein (10.140.0.0/22).

Gleiches VPC-Netzwerk und gleiche Region

Benutzerdefinierte statische Routen, die interne Passthrough-Network-Load-Balancer als nächste Hops verwenden, sind auf Folgendes beschränkt:

• Ein einzelnes VPC-Netzwerk. Der Load-Balancer und die benutzerdefinierte statische Route müssen sich im selben VPC-Netzwerk befinden.

• Eine einzelne Region oder alle Regionen. Sofern Sie keinen globalen Zugriff konfiguriert haben, ist die benutzerdefinierte statische Route nur für Ressourcen in derselben Region wie der Load-Balancer verfügbar. Diese regionale Beschränkung wird erzwungen, obwohl die Route selbst Teil der Routingtabelle für das gesamte VPC-Netzwerk ist. Wenn Sie den globalen Zugriff aktivieren, ist die benutzerdefinierte statische Route für Ressourcen in jeder Region verfügbar.

Benutzerdefinierte statische Route bewerben

Wenn Sie das Präfix (Ziel) für die benutzerdefinierte statische Route bewerben möchten, können Sie ein Route Advertisement für Cloud Router verwenden. Der Bereich des Route Advertisement hängt von der globalen Zugriffseinstellung des Load-Balancers ab:

• Wenn der globale Zugriff deaktiviert ist, ist der interne Passthrough-Network-Load-Balancer nur für VMs, Cloud VPN-Tunnel und Cloud Interconnect-Anhänge (VLANs) verfügbar, die sich in derselben Region wie der Load-Balancer befinden. Daher ist ein benutzerdefiniertes Route Advertisement für das Präfix einer benutzerdefinierten statischen Route nur sinnvoll, wenn sich der Cloud Router und der Load-Balancer in derselben Region befinden.

• Wenn der globale Zugriff aktiviert ist, ist der interne Passthrough-Network-Load-Balancer für VMs, Cloud VPN-Tunnel und Cloud Interconnect-Anhänge (VLANs) verfügbar, die sich in einer beliebigen Region befinden. Beim globalen dynamischen Routing können lokale Systeme die benutzerdefinierte statische Route aus jeder verbundenen Region verwenden.

In der folgenden Tabelle wird die Zugänglichkeit des Load-Balancers zusammengefasst.

Globaler Zugriff	Dynamischer Routingmodus des VPC-Netzwerks	Load-Balancer-Zugriff
Deaktiviert	Regional	Für Router in derselben Region zugänglich
Deaktiviert	Global	Für Router in derselben Region zugänglich
Aktiviert	Regional	Zugriff von allen Routern in beliebigen Regionen
Aktiviert	Global	Zugriff von allen Routern in beliebigen Regionen

Weitere Informationen finden Sie unter Interne Passthrough-Network-Load-Balancer und verbundene Netzwerke.

Reihenfolge von Vorgängen

Sie müssen einen internen Passthrough-Network-Load-Balancer erstellen, bevor Sie eine benutzerdefinierte statische Route erstellen können, die ihn als nächsten Hop verwendet. Der Load-Balancer muss vorhanden sein, bevor Sie die Route erstellen. Wenn Sie versuchen, eine Route zu erstellen, die auf einen nicht vorhandenen Load-Balancer verweist, gibt Google Cloud einen Fehler zurück.

Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop angeben. Verwenden Sie dazu den Namen der Weiterleitungsregel und die Region des Load-Balancers oder die mit der Weiterleitungsregel verknüpfte interne IP-Adresse.

Wenn Sie eine Route mit einem nächsten Hop erstellt haben, der auf einen internen Passthrough-Network-Load-Balancer verweist, können Sie den Load-Balancer erst löschen, nachdem Sie die Route gelöscht haben. Insbesondere können Sie eine interne Weiterleitungsregel erst dann löschen, wenn keine benutzerdefinierte statische Route diesen Load-Balancer als nächsten Hop verwendet.

Backend-Anforderungen

• Sie müssen alle Backend-VMs des internen Passthrough-Network-Load-Balancers so konfigurieren, dass die IP-Weiterleitung zugelassen wird (--can-ip-forward = True). Weitere Informationen finden Sie unter Überlegungen zum instanzbasierten oder Load-Balancer-basierten Routing.

• Sie können keinen internen Passthrough-Network-Load-Balancer verwenden, dessen Back-Ends GKE-Knoten (Google Kubernetes Engine) als nächster Hop für eine benutzerdefinierte statische Route sind. Software auf den Knoten kann Traffic nur dann an Pods weiterleiten, wenn das Ziel mit einer vom Cluster verwalteten IP-Adresse übereinstimmt, nicht mit einem beliebigen Ziel.

TCP-, UDP- und anderen Protokoll-Traffic verarbeiten

Wichtig: Die Informationen in diesem Abschnitt gelten nur für benutzerdefinierte Routen, die vor dem 15. Mai 2021 erstellt wurden.

Wenn vor dem 15. Mai 2021 eine Route für den internen Passthrough-Network-Load-Balancer als nächster Hop erstellt wurde, leitet der Load-Balancer unabhängig von der Weiterleitungsregel oder der Backend-Dienstkonfiguration nur TCP- und UDP-Traffic an allen Ports an die Backend-VMs weiter. Der übrige Traffic, z. B. ICMP-Pings, wird von der nächsten spezifischsten Route in Ihrem VPC-Netzwerk verarbeitet.

Wenn eine Route, die vor dem 15. Mai 2021 erstellt wurde, noch am 16. August 2021 in Betrieb ist, wird sie automatisch migriert, um den gesamten Protokolltraffic ab dem 16. August 2021 weiterzuleiten.

Wenn ein interner Passthrough-Network-Load-Balancer als nächster Hop bereitgestellt wird, leitet Google Cloud den gesamten Traffic an allen Ports an die Backend-VMs weiter, unabhängig von diesen Faktoren:

• Protokoll und Portkonfiguration der Weiterleitungsregel
• Die Protokollkonfiguration des Backend-Dienstes

Der interne Passthrough-Network-Load-Balancer, der als nächster Hop der Route dient, unterstützt die nahtlose Weiterleitung des gesamten Traffics für Protokolle, die von Google Cloud-VPC-Netzwerken unterstützt werden (z. B. TCP, UDP und ICMP).

Weitere Überlegungen

• Unterstützte Weiterleitungsregeln. Google Cloud unterstützt nur interne Weiterleitungsregeln für Network Load Balancer als nächsten Hop. Google Cloud unterstützt keine Weiterleitungsregeln für den nächsten Hop, die von anderen Load Balancern, Protokollweiterleitungen oder als Private Service Connect-Endpunkten verwendet werden.

• Spezifikationsmethoden sowie das Netzwerk und Projekt für die Weiterleitungsregel. Sie können eine der folgenden Hop-Weiterleitungsregeln angeben. Die von Ihnen verwendete Spezifikationsmethode bestimmt, ob das Netzwerk der Weiterleitungsregel mit dem Netzwerk der Route übereinstimmen muss und in welchem Projekt sich die Weiterleitungsregel befinden kann:

  • Nach Weiterleitungsregelname (--next-hop-ilb) und Region (--next-hop-ilb-region): Wenn Sie eine Weiterleitungsregel als nächsten Hop nach Name und Region angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel muss sich in demselben Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt).

  • Durch Weiterleitung des Links zur Weiterleitungsregelressource: Der Ressourcenlink einer Weiterleitungsregel verwendet das folgende Format: /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, wobei PROJECT_ID die Projekt-ID des Projekts ist, das die Weiterleitungsregel enthält. REGION ist die Region der Weiterleitungsregel und FORWARDING_RULE_NAME ist der Name der Weiterleitungsregel. Wenn Sie eine Weiterleitungsregel für den nächsten Hop über den Ressourcenlink angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt.

  • Durch eine die IPv4-Adresse einer Weiterleitungsregel: Wenn Sie eine Weiterleitungsregel für den nächsten Hop anhand seiner IPv4-Adresse angeben, kann das Netzwerk der Weiterleitungsregel entweder das VPC-Netzwerk der Route oder ein Peering-VPC-Netzwerk sein. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt.

• Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die interne Network Load Balancer als nächste Hops verwenden, werden in allen Regionen programmiert. Ob der nächste Hop verwendet werden kann, hängt von der Einstellung für den globalen Zugriff des Load-Balancers ab. Wenn der globale Zugriff aktiviert ist, ist der Load-Balancer als nächster Hop in allen Regionen des VPC-Netzwerks zugänglich. Wenn der globale Zugriff deaktiviert ist, ist der Load-Balancer als nächster Hop nur in derselben Region wie der Load-Balancer zugänglich. Wenn der globale Zugriff deaktiviert ist, werden Pakete, die aus einer anderen Region an eine Route mit einem internen Passthrough Network Load Balancer gesendet werden, verworfen.

• Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen Passthrough Network Load Balancers bei Systemdiagnosen fehlschlagen, sind die Routen, die diesen nächsten Hop verwenden, noch aktiv. Von der Route verarbeitete Pakete werden gemäß der Trafficverteilung an eines der Back-Ends des nächsten Hop-Load-Balancers gesendet.

• Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden (--purpose=SHARED_LOADBALANCER_VIP), werden nicht unterstützt. Die Network Load Balancer des nächsten Hops und die Weiterleitungsregeln für internen Passthrough Network Load Balancer mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne Passthrough Network Load Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Backend-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Backend-Dienste verweisen (verschiedene interne Passthrough Network Load Balancer).

• Gleiches Ziel und mehrere interne Passthrough Network Load Balancer als nächster Hop. Wenn Sie zwei oder mehr benutzerdefinierte statische Routen mit demselben Ziel und unterschiedlichen internen Passthrough Network Load Balancern als nächste Hops erstellen, verteilt Google Cloud den Traffic nie unter den Load-Balancern als nächste Hops mit ECMP. Wenn die Routen eindeutige Prioritäten haben, verwendet Google Cloud den internen Passthrough Network Load Balancer als nächsten Hop aus der Route mit der höchsten Priorität. Wenn die Routen dieselben Prioritäten haben, wählt Google Cloud trotzdem nur einen internen Passthrough Network Load Balancer als nächsten Hop aus. Wie in der folgenden Abbildung dargestellt, verwendet Google Cloud einen deterministischen internen Algorithmus, um eine Weiterleitungsregel als nächsten Hop (forwarding-rule-a) auszuwählen und andere Routen mit derselben Priorität zu ignorieren.

  

  Google Cloud wählt einen einzelnen nächsten Hop aus, wenn statische Routen mit unterschiedlichen internen Passthrough Network Load Balancern als nächste Hops dieselbe Priorität und dasselbe Ziel haben.

• Mehrere Ziele und derselbe Passthrough Network Load Balancer für den nächsten Hop:

  Mit Instanz-Tags:

  Wenn Sie Instanz-Tags (auch Netzwerk-Tags genannt) verwenden, können Sie denselben internen Passthrough Network Load Balancer als nächsten Hop für mehrere benutzerdefinierte statische Routen mit demselben Ziel und derselben Priorität verwenden.

  Ohne Instanz-Tags: Ohne Instanz-Tags können Sie nicht mehrere benutzerdefinierte statische Routen mit derselben Kombination aus Ziel, Priorität und internem Passthrough Network Load Balancer als nächsten Hop erstellen. Beispielsweise können route-x, route-y und route-z erstellt werden, route-x-copy jedoch nicht.

  

  Statische Routen, die keine Instanz-Tags enthalten, können nicht mit demselben Ziel, derselben Priorität und demselben internen Passthrough Network Load Balancer als nächster Hop erstellt werden.

• Instanz-Tags.

  Sie können Instanz-Tags angeben (auch als Netzwerk-Tags bezeichnet), sodass die Route für den nächsten Hop nur für Clientinstanzen gilt, die mit dem Tag konfiguriert wurden. Dadurch können Sie auswählen, welche Clientinstanzen mit welcher getaggten Route für den nächsten Hop gefüllt werden und an welche Gruppe von Appliances der Traffic weitergeleitet werden soll.

  Sie müssen die verschiedenen Clientinstanzen nicht in separate VPC-Netzwerke unterteilen, die jeweils auf ihre bevorzugten internen Passthrough Network Load Balancer mit dem Frontend einer Reihe von Appliances verweisen.

  Hinweis: Getaggte Routen werden nicht über Peering exportiert oder importiert.

• Mehrere Routen für dasselbe Zielpräfix: Mit Instanz-Tags können Sie mehrere Routen zum selben Ziel mit unterschiedlichen internen Load-Balancern als nächste Hops angeben. Sie können für diese Zielrouten unterschiedliche Instanz-Tags oder unterschiedliche Prioritäten verwenden.

Anwendungsfälle

Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop in mehreren Bereitstellungen und Topologien verwenden.

Beachten Sie für jedes Beispiel die folgenden Richtlinien:

• Jede VM-Schnittstelle muss in einem separaten VPC-Netzwerk sein.

• Sie können keine Backend-VMs oder Load-Balancer verwenden, um Traffic zwischen Subnetzwerken im selben VPC-Netzwerk weiterzuleiten, da Subnetzrouten nicht überschrieben werden können.

• Der interne Passthrough-Network-Load-Balancer ist ein softwarebasierter Passthrough-Load-Balancer. Pakete werden an Backend-VMs ohne Änderungen an den Quell- oder Zielinformationen (Adressen oder Adressen und Ports) gesendet.

  Routing, Paketfilterung, Proxy und Adressübersetzung liegen in der Verantwortung der virtuellen Appliance-VMs, die als Back-Ends für den internen Passthrough-Network-Load-Balancer dienen.

Internen Passthrough-Network-Load-Balancer als nächsten Hop zu einem NAT-Gateway verwenden

Bei diesem Anwendungsfall wird der Traffic per Load-Balancing von internen VMs auf mehrere NAT-Gateway-Instanzen verteilt, die Traffic an das Internet weiterleiten.

NAT-Anwendungsfall (zum Vergrößern klicken).

Hub-and-Spoke: Routen mit nächstem Hop über VPC-Netzwerk-Peering austauschen

Zusätzlich zum Austausch von Subnetzrouten können Sie VPC-Netzwerk-Peering konfigurieren, um benutzerdefinierte statische und dynamische Routen zu exportieren und zu importieren. Benutzerdefinierte statische Routen, die einen nächsten Hop im Standard-Internetgateway haben, werden ausgeschlossen. Benutzerdefinierte statische Routen, die interne Passthrough-Network-Load-Balancer als nächsten Hop verwenden, sind enthalten.

Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances mit nächstem Hop konfigurieren, die sich im hub-VPC-Netzwerk befinden. Gehen Sie dazu so vor:

• Erstellen Sie im hub-VPC-Netzwerk einen internen Passthrough-Network-Load-Balancer mit virtuellen Firewall-Appliances als Back-Ends.
• Erstellen Sie im hub-VPC-Netzwerk eine benutzerdefinierte statische Route und legen Sie als nächsten Hop den internen Passthrough-Network-Load-Balancer fest.
• Verbinden Sie das hub-VPC-Netzwerk mithilfe von VPC-Netzwerk-Peering mit jedem der spoke-VPC-Netzwerke.
• Konfigurieren Sie für jedes Peering das hub-Netzwerk, um dessen benutzerdefinierten Routen zu exportieren, und konfigurieren Sie das entsprechende spoke-Netzwerk, um benutzerdefinierte Routen zu importieren. Die Route mit dem nächsten Hop des Load-Balancers ist eine der Routen, die vom hub-Netzwerk exportiert werden.

Je nach Routingreihenfolge ist der Firewall-Appliance-Load-Balancer mit nächstem Hop im VPC-Netzwerk hub in den Spoke-Netzwerken verfügbar:

• für Clients in derselben Region wie der Load-Balancer, wenn der globale Zugriff deaktiviert ist.
• für Clients in allen Regionen, wenn der globale Zugriff gemäß der Routingreihenfolge aktiviert ist.

Hub-and-Spoke (zum Vergrößern klicken).

Load-Balancing für mehrere NICs

Im folgenden Anwendungsfall sind die Back-End-VMs virtuelle Appliance-Instanzen (z. B. Paketinspektion, Routing oder Gateway-VMs) mit NICs in mehreren VPC-Netzwerken. Diese virtuellen Appliance-Instanzen können kommerzielle Lösungen von Drittanbietern oder Lösungen sein, die Sie selbst erstellen. Bei den virtuellen Appliances handelt es sich um Compute Engine-VMs mit mehreren NICs.

Dieses Beispiel zeigt eine einzelne Gruppe von virtuellen Backend-Appliances in einer verwalteten VM-Instanzengruppe.

Im testing-VPC-Netzwerk hat der interne Passthrough-Network-Load-Balancer eine Weiterleitungsregel namens fr-ilb1. In diesem Beispiel verteilt der Load-Balancer den Traffic an die Schnittstelle nic0.

Im production-VPC-Netzwerk hat ein anderer interner Passthrough-Network-Load-Balancer eine Weiterleitungsregel namens fr-ilb2. Dieser Load-Balancer verteilt den Traffic auf eine andere Schnittstelle; nic1 in diesem Beispiel.

Traffic mit Multi-NIC-Load-Balancing (zum Vergrößern klicken).

Detaillierte Informationen zur Konfiguration finden Sie unter Load-Balancing für mehrere Backend-NICs.

Symmetrisches Hashing

Im vorherigen Beispiel wurde keine Quellnetzwerkadressübersetzung (SNAT, Source Network Address Translation) verwendet. SNAT ist nicht erforderlich, da Google Cloud symmetrisches Hashing verwendet. Das bedeutet, dass Google Cloud denselben Hash berechnet, wenn Pakete zum selben Ablauf gehören. Mit anderen Worten, der Hash ändert sich nicht, wenn Quell-IP-Adresse:port durch Ziel-IP-Adresse:port ersetzt wird.

Hinweise:

• Symmetrisches Hashing wird ab dem 22. Juni 2021 automatisch aktiviert, wenn Sie die Weiterleitungsregel für den internen Passthrough-Network-Load-Balancer erstellen.

• Wenn Sie symmetrisches Hashing auf vorhandenen internen Passthrough-Network-Load-Balancern aktivieren möchten, müssen Sie die Weiterleitungsregel und die Route für den nächsten Hop neu erstellen, wie unter symmetrisches Hashing aktivieren beschrieben.

• Symmetrisches Hashing wird nur bei internen Passthrough-Network-Load-Balancern unterstützt.

• Symmetrisches Hashing wird mit den folgenden Sitzungsaffinitätstypen für die Protokolle TCP und UDP unterstützt:

  • Client-IP (2-Tupel)
  • Client-IP und Protokoll (3-Tupel)
  • Client-IP, Protokoll und Port (5-Tupel)

• Sie können SNAT optional verwenden, wenn Ihr Anwendungsfall dies aus irgendeinem Grund erfordert.

Nächste Schritte

• Informationen zum Konfigurieren eines internen Passthrough-Network-Load-Balancers als nächsten Hop finden Sie unter Internen Passthrough-Network-Load-Balancer für Drittanbieter-Appliances einrichten oder Hub-and-Spoke-Netzwerk mithilfe eines Load-Balancers als nächsten Hop bereitstellen.
• Informationen zum Konfigurieren und Testen eines internen Passthrough-Network-Load-Balancers finden Sie unter Internen Passthrough-Network-Load-Balancer mit VM-Instanzgruppen-Back-Ends einrichten.
• Informationen zur Fehlerbehebung bei Problemen mit dem nächsten Hop und dem internen Passthrough-Network-Load-Balancer finden Sie unter Fehlerbehebung bei internen Passthrough-Network-Load-Balancern.