Interne TCP/UDP-Load-Balancer als nächste Hops

Das interne TCP/UDP-Load-Balancing ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse für das Load-Balancing ausführen und skalieren können. Sie können einen internen TCP/UDP-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:

Ein interner TCP/UDP-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 TCP/UDP-Load-Balancer wird in einem einzelnen VPC-Netzwerk betrieben und verteilt den Traffic an die Netzwerkschnittstellen der Back-End-VMs in diesem Netzwerk.

Architektur

Im folgenden Diagramm dient eine VM-Instanzengruppe von Router-VMs als Back-End für zwei verschiedene Load-Balancer. Das erste interne TCP/UDP-Load-Balancing sendet Pakete an nic0 der Back-End-VMs und das zweite interne TCP/UDP-Load-Balancing sendet Pakete an nic1 auf denselben Back-Ends.

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

Vorteile der Verwendung eines internen TCP/UDP-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 Back-End des Load-Balancers über VPC-Netzwerkrouting mit der MethodeBump-in-the-Wire.

Ein interner TCP/UDP-Load-Balancer als nächster Hop für eine statische Route bietet dieselben Vorteile wie das interne TCP/UDP-Load-Balancing. Die Systemdiagnose des Load-Balancers sorgt dafür, dass neue Verbindungen an fehlerfreie Back-End-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 interner TCP/UDP-Load-Balancer als nächste Hops.

Routen

Sie können eine benutzerdefinierte statische Route erstellen, um TCP-, UDP- und anderen Protokolltraffic an einen internen TCP/UDP-Load-Balancer zu übergeben. Dabei ist der Load-Balancer der nächste Hop für die statische Route. 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 Back-End-VMs von Drittanbietern weiterleitet.

Optionen zum Festlegen des nächsten Hops

Sie haben zwei Möglichkeiten, den Load-Balancer als nächsten Hop festzulegen.

Option zum Festlegen des nächsten Hops Netzwerk für den nächsten Hop Kann in Peering-Netzwerke exportiert werden
Name der Weiterleitungsregel und die Region des Load-Balancers Der Load-Balancer und die Route des nächsten Hops müssen sich im selben VPC-Netzwerk befinden Ja, durch Exportieren benutzerdefinierter Routen (gilt für Routen ohne Instanz-Tags)
Interne IP-Adresse der Weiterleitungsregel Der Load-Balancer als nächster Hop kann sich im selben VPC-Netzwerk wie die Route oder in einem Peering-VPC-Netzwerk befinden Ja, immer exportiert (außer für Routen mit Instanz-Tags)

Client-IP-Sitzungsaffinität

Client-IP-Sitzungsaffinität ist eine verfügbare Sitzungsaffinitätsoption. Es handelt sich um eine Zwei-Tupel-Affinität, die die Quell-IP-Adresse und die Ziel-IP-Adresse als Eingaben für eine Hash-Funktion verwendet.

Wenn Sie einen internen TCP/UDP-Load-Balancer verwenden, ist die Ziel-IP-Adresse die IP-Adresse der Weiterleitungsregel des Load-Balancers. Client-IP-Sitzungsaffinität in diesem Kontext bedeutet, dass Verbindungen von einem Client mit einer konstanten Quell-IP-Adresse an dieselbe Back-End-VM geliefert werden, wenn die Back-End-VM intakt ist.

Wenn dagegen ein interner TCP/UDP-Load-Balancer als nächster Hop für eine statische Route verwendet wird, variiert die Ziel-IP-Adresse, da die Back-End-VMs des Load-Balancers Pakete verarbeiten und an verschiedene Ziel-IP-Adressen weiterleiten. Die Verwendung der Client-IP-Sitzungsaffinität in diesem Kontext führt nicht dazu, dass Pakete von derselben Back-End-VM verarbeitet werden, selbst wenn der Client über eine konstante Quell-IP-Adresse verfügt.

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 TCP/UDP-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 TCP/UDP-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 TCP/UDP-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 TCP/UDP-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 Internes TCP/UDP-Load-Balancing und verbundene Netzwerke.

Reihenfolge von Vorgängen

Sie müssen einen internen TCP/UDP-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 TCP/UDP-Load-Balancer für den 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 TCP/UDP-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.

Back-End-Anforderungen

  • Sie müssen alle Back-End-VMs des internen TCP/UDP-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 TCP/UDP-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

Wenn ein interner TCP/UDP-Load-Balancer als nächster Hop bereitgestellt wird, leitet Google Cloud den gesamten Traffic an allen Ports an die Back-End-VMs weiter, unabhängig von folgenden Bedingungen:

  • Protokoll und Portkonfiguration der Weiterleitungsregel
  • Die Protokollkonfiguration des Back-End-Dienstes

Der interne TCP/UDP-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

  • Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die interne TCP/UDP-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 TCP/UDP-Load-Balancer gesendet werden, verworfen.
  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen TCP/UDP-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. Ein interner TCP/UDP-Load-Balancer mit nächstem Hop und interne Weiterleitungsregeln des TCP/UDP-Load-Balancers mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne TCP/UDP-Load-Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Back-End-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Back-End-Dienste verweisen (verschiedene interne TCP/UDP-Load-Balancer).

  • Gleiches Ziel und mehrere interne TCP/UDP-Load-Balancer als nächsten Hop Wenn Sie zwei oder mehr benutzerdefinierte statische Routen mit demselben Ziel und unterschiedlichen internen TCP/UDP-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 TCP/UDP-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 TCP/UDP-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.

    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
    Gleiches Ziel, unterschiedliche interne TCP/UDP-Load-Balancer als nächste Hops
  • Mehrere Ziele und derselbe TCP-UDP-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 TCP/UDP-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 TCP/UDP-Load-Balancer als nächsten Hop erstellen. Beispielsweise können route-x, route-y und route-z erstellt werden, route-x-copy jedoch nicht.

    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop
    Beispielrouten mit einem gemeinsamen internen TCP/UDP-Load-Balancer als nächsten Hop
  • 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 TCP/UDP-Load-Balancer mit dem Front-End einer Reihe von Appliances verweisen.

  • 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 TCP/UDP-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 Back-End-VMs oder Load-Balancer verwenden, um Traffic zwischen Subnetzwerken im selben VPC-Netzwerk weiterzuleiten, da Subnetzrouten nicht überschrieben werden können.

  • Der interne TCP/UDP-Load-Balancer ist ein Software-definierter Passthrough-Load-Balancer. Pakete werden an Back-End-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 TCP/UDP-Load-Balancer dienen.

Internen TCP/UDP-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)
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 TCP/UDP-Load-Balancer mit nächstem 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 TCP/UDP-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 TCP/UDP-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)
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 Back-End-Appliances in einer verwalteten VM-Instanzengruppe.

Im testing-VPC-Netzwerk hat der interne TCP/UDP-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 TCP/UDP-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)
Traffic mit Multi-NIC-Load-Balancing (zum Vergrößern klicken)

Detaillierte Informationen zur Konfiguration finden Sie unter Load-Balancing für mehrere Back-End-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 interne Weiterleitungsregel für den TCP/UDP-Load-Balancer erstellen.

  • Wenn Sie symmetrisches Hashing auf vorhandenen internen TCP/UDP-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 beim internen TCP/UDP-Load-Balancing 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