Ein interner Passthrough-Netzwerk-Load-Balancer ist ein regionaler Load-Balancer, der auf dem Virtualisierungsstack für das Andromeda-Netzwerk basiert.
Der interne Passthrough-Netzwerk-Load-Balancer verteilt den Traffic auf interne VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud). Sie können damit Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren. Zugriff darauf ist nur für Systeme im selben VPC-Netzwerk oder für Systeme verfügbar, die mit Ihrem VPC-Netzwerk verbunden sind.
Ein interner Passthrough-Netzwerk-Load-Balancer hat ein Front-End (die Weiterleitungsregel) und ein Back-End (den Back-End-Dienst). Sie können für den Back-End-Dienst entweder Instanzgruppen oder GCE_VM_IP zonale NEGs als Back-Ends verwenden. Dieses Beispiel zeigt Instanzgruppen-Back-Ends.
Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:
Anwendungsfälle
In folgenden Fällen sollten Sie einen internen Passthrough-Netzwerk-Load-Balancer verwenden:
- Sie benötigen einen leistungsstarken Pass-Through-Layer-4-Load-Balancer für die Protokolle TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE.
Die Unterstützung für mehrere Protokolle (
L3_DEFAULT) befindet sich in der Vorschau. Wenn der Traffic über TLS (SSL) bereitgestellt wird, ist es zulässig, SSL-Traffic von Ihren Back-Ends und nicht vom Load-Balancer beenden zu lassen. Der interne Passthrough-Netzwerk-Load-Balancer kann SSL-Traffic nicht beenden.
Sie müssen die ursprünglichen Pakete ohne Proxy weiterleiten. Zum Beispiel, wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.
Sie haben bereits eine Konfiguration, in der ein Pass-Through-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.
Die internen Passthrough-Netzwerk-Load-Balancer sind für viele Anwendungsfälle vorgesehen. Dieser Abschnitt enthält einige allgemeine Beispiele.
Zugriffsbeispiele
In Ihrem VPC-Netzwerk können Sie über ein verbundenes Netzwerk auf einen internen TCP/UDP-Load-Balancer mit Folgendem zugreifen:
- VPC-Netzwerk-Peering
- Cloud VPN und Cloud Interconnect
Ausführliche Beispiele finden Sie unter Interne Passthrough-Netzwerk-Load-Balancer und verbundene Netzwerke.
Beispiel für einen dreischichtigen Webdienst
Sie können interne Passthrough-Netzwerk-Load-Balancer in Verbindung mit anderen Load-Balancern verwenden. Wenn Sie beispielsweise einen externen Anwendungs-Load-Balancer einbinden, ist der externe Anwendungs-Load-Balancer die Webebene und arbeitet mit Diensten hinter dem internen Passthrough-Netzwerk-Load-Balancer.
Das folgende Diagramm zeigt ein Beispiel für eine dreistufige Konfiguration, die externe Anwendungs-Load-Balancer und interne Passthrough-Netzwerk-Load-Balancer verwendet:
Webdienst mit drei Ebenen und globalem Zugriff
Wenn Sie den globalen Zugriff aktivieren, können sich Ihre VMs auf Webebene in einer anderen Region befinden, wie im folgenden Diagramm dargestellt.
In diesem Beispiel für eine Anwendung mit mehreren Ebenen wird Folgendes gezeigt:
- Eine global verfügbare internetorientierte Webebene, bei der der Traffic mit einem externen Application Load Balancer verteilt wird
- Eine interne Back-End-Datenbankstufe mit Load-Balancing in der Region
us-east1, auf die von der globalen Webebene zugegriffen wird. - Eine Client-VM, die Teil der Webebene in der Region
europe-west1ist, die auf die interne Datenbankebene mit Load-Balancing inus-east1zugreift.
Interne Passthrough-Netzwerk-Load-Balancer als nächste Hops verwenden
Sie können einen internen Passthrough-Netzwerk-Load-Balancer als nächstes Gateway verwenden, an das 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.
Ein interner Passthrough-Netzwerk-Load-Balancer, der als nächster Hop in einer benutzerdefinierten Route bereitgestellt wird, verarbeitet den gesamten Traffic, unabhängig vom Protokoll (TCP, UDP oder ICMP).
Im Folgenden finden Sie eine Beispielarchitektur mit einem internen Passthrough-Netzwerk-Load-Balancer als nächstem Hop zu einem NAT-Gateway. Sie können Traffic an die Back-Ends Ihrer virtuellen Firewall- oder Gateway-Appliance über einen internen Passthrough-Netzwerk-Load-Balancer weiterleiten.
Weitere Anwendungsfälle:
- Hub-and-Spoke – Austauschen von Routen für den nächsten Hop mithilfe von VPC-Netzwerk-Peering: Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances für den nächsten Hop im
hub-VPC-Netzwerk konfigurieren. Routen, die den Load-Balancer als nächsten Hop imhub-VPC-Netzwerk verwenden, können in jedemspoke-Netzwerk verwendet werden. - Load-Balancing für mehrere Netzwerkkarten auf den Back-End-VMs
Weitere Informationen zu diesen Anwendungsfällen finden Sie unter Interne Passthrough-Netzwerk-Load-Balancer als nächste Hops.
Interne Passthrough-Netzwerk-Load-Balancer und GKE
Weitere Informationen zum Erstellen interner Passthrough-Netzwerk-Load-Balancer für Dienste in GKE finden Sie in der GKE-Dokumentation unter Konzepte des LoadBalancer-Dienstes.
Funktionsweise von internen Passthrough-Netzwerk-Load-Balancern
Ein interner Passthrough-Netzwerk-Load-Balancer hat die folgenden Merkmale:
- Er ist ein verwalteter Dienst.
- Er ist kein Proxy.
- Die Implementierung erfolgt über virtuelle Netzwerke.
Im Gegensatz zu einem Proxy-Load-Balancer beendet ein interner Passthrough-Netzwerk-Load-Balancer keine Verbindungen von Clients und öffnet keine neuen Verbindungen zu Back-Ends. Stattdessen leitet ein interner Passthrough-Netzwerk-Load-Balancer Verbindungen ohne Unterbrechung direkt von Clients an die fehlerfreien Back-Ends weiter.
- Es gibt kein Zwischengerät und keinen Single Point of Failure.
- Clientanfragen an die IP-Adresse des Load-Balancers werden direkt an die fehlerfreien Back-End-VMs gesendet.
- Antworten von fehlerfreien Back-End-VMs werden direkt an die Clients und nicht über den Load-Balancer gesendet. TCP-Antworten verwenden die direkte Serverrückgabe. Weitere Informationen finden Sie unter TCP und UDP – Anfrage und Rückgabe von Paketen.
Der Load-Balancer überwacht den VM-Status mithilfe von Systemdiagnoseprüfungen. Weitere Informationen finden Sie im Abschnitt Systemdiagnose.
Die Linux-Gastumgebung von Google Cloud, die Windows-Gastumgebung oder ein entsprechender Prozess konfiguriert jede Back-End-VM mit der IP-Adresse des Load-Balancers. Bei VMs, die aus Google Cloud-Images erstellt wurden, installiert der Gast-Agent (früher die Windows-Gastumgebung oder die Linux-Gastumgebung) die lokale Route für die IP-Adresse des Load-Balancers. Google Kubernetes Engine-Instanzen, die auf Container-Optimized OS basieren, implementieren dies stattdessen mit iptables.
Das virtuelle Google Cloud-Netzwerk verwaltet die Bereitstellung des Traffics und nimmt eine entsprechende Skalierung vor.
Protokolle, Schema und Bereich
Jeder interne Passthrough-Netzwerk-Load-Balancer unterstützt Folgendes:
- Einen Back-End-Dienst mit dem Load-Balancing-Schema
INTERNALund einem unterstützten Protokoll. Weitere Informationen finden Sie unter Back-End-Dienst. - Back-End-VMs, angegeben als eine der folgenden Optionen:
- Verwaltete und nicht verwaltete Instanzgruppen in einer Region und einem VPC-Netzwerk.
- Zonale Back-End-NEGs (Netzwerk-Endpunktgruppen) mit Endpunkten des Typs
GCE_VM_IP, die sich in derselben Region und demselben VPC-Netzwerk befinden. Endpunkte in der NEG müssen primäre interne IP-Adressen im selben Subnetz und in der gleichen Zone sein wie die NEG.
- Unterstützung für IPv4- und IPv6-Traffic bei Verwendung von Instanzgruppen-Back-Ends.
Zonale Netzwerk-Endpunktgruppen (NEGs) mit
GCE_VM_IP-Endpunkten unterstützen nur IPv4-Traffic. - Eine oder mehrere Weiterleitungsregeln, die entweder das Protokoll
TCP,UDPoderL3_DEFAULT(Vorschau) verwenden und dem Protokoll des Back-End-Dienstes entsprechen. - Jede Weiterleitungsregel mit einer eigenen eindeutigen IP-Adresse oder mehrere Weiterleitungsregeln, die eine gemeinsame IP-Adresse verwenden.
- Jede Weiterleitungsregel mit bis zu fünf oder allen Ports.
- Clients in jeder Region, wenn globaler Zugriff aktiviert ist.
- Clients in derselben Region wie der Load-Balancer, wenn globaler Zugriff deaktiviert ist.
Ein interner Passthrough-Netzwerk-Load-Balancer unterstützt nicht:
- Back-End-VMs in mehreren Regionen
- Load Balancing von Traffic aus dem Internet, es sei denn, Sie verwenden ihn mit einem externen Load-Balancer.
- IPv6-Pakete mit fragmentierten Headern.
Clientzugriff
Standardmäßig müssen sich Clients in derselben Region wie der Load-Balancer befinden. Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist. Sie können globalen Zugriff aktivieren, damit Clients aus jeder Region auf Ihren internen Passthrough-Netzwerk-Load-Balancer zugreifen können.
In der folgenden Tabelle wird der Clientzugriff zusammengefasst.
| Globaler Zugriff deaktiviert | Globaler Zugriff aktiviert |
|---|---|
| Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. | Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. |
| Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load-Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. | Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load-Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden. |
IP-Adressen für Anfrage- und Rückgabepakete
Wenn eine Back-End-VM ein Paket mit Load-Balancing von einem Client empfängt, sind die Quelle und das Ziel des Pakets:
- Quelle: Die interne IPv4-, IPv6- oder die IPv4-Adresse des Clients aus einem der Alias-IPv4-Bereiche des Clients.
- Ziel: die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Weiterleitungsregel verwendet entweder eine einzelne interne IPv4-Adresse oder einen internen IPv6-Bereich.
Da es sich beim Load-Balancer um einen Pass-Through-Load-Balancer (nicht um einen Proxy) handelt, kommen Pakete an, die die Ziel-IP-Adresse der Weiterleitungsregel des Load-Balancers enthalten. Software, die auf Back-End-VMs ausgeführt wird, sollte so konfiguriert werden, dass sie Folgendes tut:
- IP-Adresse der Weiterleitungsregel des Load-Balancers oder eine beliebige IP-Adresse (
0.0.0.0oder::) überwachen und sich daran binden - Wenn das Protokoll der Weiterleitungsregel des Load-Balancers Ports unterstützt: Einen Port (binden) überwachen, der in der Weiterleitungsregel des Load-Balancers enthalten ist
Rückgabepakete werden direkt von den Back-End-VMs des Load-Balancers an den Client gesendet. Die Quell- und Ziel-IP-Adressen des Rückgabepakets hängen vom Protokoll ab:
- TCP ist verbindungsorientiert, sodass Back-End-VMs mit Paketen antworten müssen, deren Quell-IP-Adressen mit der IP-Adresse der Weiterleitungsregel übereinstimmen, sodass der Client die Antwortpakete der entsprechenden TCP-Verbindung zuordnen kann.
- UDP ist verbindungslos, sodass Back-End-VMs Antwortpakete senden können, deren Quell-IP-Adressen entweder mit der IP-Adresse der Weiterleitungsregel oder mit einer beliebigen zugewiesenen IP-Adresse für die VM übereinstimmen. Im Prinzip erwarten die meisten Clients, dass die Antwort von derselben IP-Adresse kommt, an die sie Pakete gesendet haben.
In der folgenden Tabelle werden die Quellen und Ziele für Antwortpakete zusammengefasst:
| Traffictyp | Quelle | Ziel |
|---|---|---|
| TCP | Die IP-Adresse der Weiterleitungsregel des Load-Balancers | Die Quelle des anfragenden Pakets |
| UDP | In den meisten Anwendungsfällen die IP-Adresse der Weiterleitungsregel des Load-Balancers † | Die Quelle des anfragenden Pakets |
† Es ist möglich, die Quelle des Antwortpakets auf die primäre interne IPv4-Adresse der VM-NIC oder einen Alias-IP-Adressbereich festzulegen. Wenn für die VM die IP-Weiterleitung aktiviert ist, können auch beliebige IP-Adressquellen verwendet werden. Nicht die IP-Adresse der Weiterleitungsregel als Quelle zu verwenden, ist ein erweitertes Szenario, da der Client ein Antwortpaket von einer internen IP-Adresse empfängt, die nicht mit der IP-Adresse übereinstimmt, an die ein Anfragepaket gesendet wurde.
Architektur
Ein interner Passthrough-Netzwerk-Load-Balancer mit mehreren Back-Ends verteilt Verbindungen auf alle diese Back-Ends. Weitere Informationen zur Verteilungsmethode und zu ihren Konfigurationsoptionen finden Sie unter Traffic-Verteilung.
Sie können Instanzgruppen oder zonale NEGs verwenden, aber keine Kombination aus beiden als Back-Ends für einen internen TCP/UDP-Load-Balancer:
- Wenn Sie Instanzgruppen auswählen, können Sie nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen, regionale verwaltete Instanzgruppen oder eine Kombination von Instanzgruppentypen verwenden.
- Wenn Sie zonale NEGs verwenden, müssen Sie zonale
GCE_VM_IP-NEGs verwenden.
Unter Hochverfügbarkeit wird beschrieben, wie Sie einen internen Load-Balancer entwerfen, der nicht von einer einzelnen Zone abhängig ist.
Instanzen, die als Back-End-VMs für interne Passthrough-Netzwerk-Load-Balancer verwendet werden, müssen die entsprechende Linux- oder Windows-Gastumgebung oder andere Prozesse ausführen, die gleichwertige Funktionen bereitstellen. Diese Gastumgebung muss den Metadatenserver (metadata.google.internal, 169.254.169.254) zum Lesen von Instanzmetadaten kontaktieren können, damit lokale Routen zum Akzeptieren von Traffic generiert werden können, der an die interne IP-Adresse des Load-Balancers gesendet wird.
Dieses Diagramm veranschaulicht die Traffic-Verteilung auf VMs in zwei separaten Instanzgruppen. Traffic, der von der Clientinstanz an die IP-Adresse des Load-Balancers 10.10.10.9 gesendet wird, wird zwischen den Back-End-VMs in einer der Instanzgruppen verteilt. Von einer der bereitstellenden Back-End-VMs gesendete Antworten werden direkt an die Client-VM zugestellt.
Sie können einen internen Passthrough-Netzwerk-Load-Balancer entweder mit einem VPC-Netzwerk im benutzerdefinierten Modus oder im automatischen Modus verwenden. Sie können auch interne Passthrough-Netzwerk-Load-Balancer mit einem vorhandenen Legacy-Netzwerk erstellen.
Ein interner Passthrough-Netzwerk-Load-Balancer besteht aus den folgenden Google Cloud-Komponenten.
| Komponente | Zweck | Anforderungen |
|---|---|---|
| Interne IP-Adresse | Dies ist die Adresse für den Load-Balancer. | Die interne IP-Adresse muss sich im selben Subnetz wie die interne Weiterleitungsregel befinden. Das Subnetz muss sich in derselben Region und demselben VPC-Netzwerk wie der Back-End-Dienst befinden. |
| Interne Weiterleitungsregel | Eine interne Weiterleitungsregel in Kombination mit der internen IP-Adresse ist das Front-End des Load-Balancers. Sie definiert das Protokoll und die Ports, die der Load-Balancer akzeptiert, und leitet den Traffic an einen regionalen internen Back-End-Dienst weiter. | Weiterleitungsregeln für interne Passthrough-Netzwerk-Load-Balancer müssen folgende Voraussetzungen erfüllen: • Sie müssen das load-balancing-scheme INTERNAL haben.• Sie müssen als ip-protocol entweder TCP oder UDP verwenden, passend zum protocol des Back-End-Diensts.• Sie müssen im selben VPC-Netzwerk und in derselben Region wie der Back-End-Dienst auf ein subnet verweisen. |
| Regionaler interner Back-End-Dienst | Der regionale interne Back-End-Dienst definiert das Protokoll, das für die Kommunikation mit den Back-Ends verwendet wird, und gibt eine Systemdiagnose an. Back-Ends können nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen, verwaltete regionale Instanzgruppen oder zonale NEGs mit GCE_VM_IP-Endpunkten sein. |
Der Back-End-Dienst muss folgende Voraussetzungen erfüllen: • Er muss das load-balancing-scheme INTERNAL haben.• Er muss als protocol entweder TCP oder UDP verwenden, passend zum ip-protocol der Weiterleitungsregel.• Er muss eine zugehörige Systemdiagnose haben. • Er muss eine zugehörige Region haben. Die Weiterleitungsregel und alle Back-Ends müssen sich in derselben Region wie der Back-End-Dienst befinden. • Sie müssen einem einzelnen VPC-Netzwerk zugeordnet sein. Wenn keine Angabe erfolgt, wird das Netzwerk basierend auf dem Netzwerk abgeleitet, das von der Standardnetzwerkschnittstelle der Back-End-VM verwendet wird ( nic0).Obwohl der Back-End-Dienst nicht an ein bestimmtes Subnetz gebunden ist, muss sich das Subnetz der Weiterleitungsregel im selben VPC-Netzwerk befinden wie der Back-End-Dienst. |
| Systemdiagnose | Jeder Back-End-Dienst muss eine zugehörige Systemdiagnose haben. Die Systemdiagnose definiert die Parameter, anhand derer Google Cloud die verwalteten Back-Ends als für den Erhalt von Traffic zugelassen betrachtet. Nur fehlerfreie Back-End-VMs empfangen Traffic, der von Client-VMs an die IP-Adresse des Load-Balancers gesendet wird. |
Auch wenn die Weiterleitungsregel und der Back-End-Dienst entweder TCP oder UDP verwenden können, hat Google Cloud keine Systemdiagnose für UDP-Traffic. Weitere Informationen finden Sie unter Systemdiagnosen und UDP-Traffic.
|
Interne IP-Adresse
Interne Passthrough-Netzwerk-Load-Balancer unterstützen nur IPv4-Subnetze (Single-Stack) und IPv4- und IPv6-Subnetze (Dual-Stack). Weitere Informationen finden Sie unter Subnetztypen.
Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine Weiterleitungsregel erforderlich. Die Weiterleitungsregel verweist auf die interne IP-Adresse:
- Bei IPv4-Traffic verweist die Weiterleitungsregel auf eine IPv4-Adresse aus dem primären IPv4-Subnetzbereich.
- Bei IPv6-Traffic verweist die Weiterleitungsregel auf einen
/96-Bereich interner IPv6-Adressen aus dem internen/64-IPv6-Adressbereich des Subnetzes. Das Subnetz muss ein Dual-Stack-Subnetz mit einem internen IPv6-Adressbereich sein (ipv6-access-typeist aufINTERNALgesetzt).
Firewallkonfiguration
Für interne Passthrough-Netzwerk-Load-Balancer ist die folgende Konfiguration für hierarchische Firewallrichtlinien und VPC-Firewallregeln erforderlich:
- Lassen Sie eingehenden Traffic aus IPv4- oder IPv6-Quellbereichen der Systemdiagnoseprüfungen zu.
- Lassen Sie eingehenden Traffic von Client-IPv4- oder IPv6-Adressbereichen zu.
Weitere Informationen finden Sie unter Firewallregeln konfigurieren.
Weiterleitungsregeln
Mit einer Weiterleitungsregel werden das Protokoll und die Ports angegeben, über die der Load-Balancer den Traffic annimmt. Da interne Passthrough-Netzwerk-Load-Balancer keine Proxys sind, leiten sie Traffic an Back-Ends über dasselbe Protokoll und denselben Port weiter.
Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich. Sie können mehrere Weiterleitungsregeln für denselben Load-Balancer definieren.
Erstellen Sie zwei Weiterleitungsregeln., wenn der Load-Balancer sowohl IPv4- als auch IPv6-Traffic verarbeiten soll: eine Regel für IPv4-Traffic, die auf IPv4- (oder Dual-Stack-)Back-Ends verweist, und eine Regel für IPv6-Traffic, der nur für Dual-Stack-Back-Ends verweist. Es ist möglich, dass eine IPv4- und eine IPv6-Weiterleitungsregel auf denselben Back-End-Dienst verweisen. Der Back-End-Dienst muss jedoch auf Dual-Stack-Back-Ends verweisen.
Die Weiterleitungsregel muss auf ein bestimmtes Subnetz im selben VPC-Netzwerk und in derselben Region wie die Back-End-Komponenten des Load-Balancers verweisen. Diese Anforderung hat folgende Auswirkungen:
- Das Subnetz, das Sie für die Weiterleitungsregel angeben, muss nicht mit einem der von Back-End-VMs verwendeten Subnetze identisch sein. Das Subnetz muss sich jedoch in derselben Region wie die Weiterleitungsregel befinden.
- Bei IPv4-Traffic verweist die interne Weiterleitungsregel auf die regionale interne IPv4-Adresse aus dem primären IPv4-Adressbereich des ausgewählten Subnetzes. Diese IPv4-Adresse kann automatisch ausgewählt werden; alternativ können Sie eine statische (reservierte) IPv4-Adresse verwenden.
- Bei IPv6-Traffic verweist die Weiterleitungsregel auf einen
/96-IPv6-Adressbereich aus dem externen IPv6-Adressbereich des Subnetzes. Das Subnetz muss ein Dual-Stack-Subnetz sein, wobeiipv6-access-typeaufINTERNALgesetzt ist. Der IPv6-Adressbereich/96wird entweder automatisch zugewiesen oder Sie verwenden eine reservierte interne IP-Adresse.
Weiterleitungsregelprotokolle
Interne Passthrough-Netzwerk-Load-Balancer unterstützen die folgenden IPv4-Protokolloptionen für jede Weiterleitungsregel: TCP, UDP oder L3_DEFAULT (Vorschau).
Interne Passthrough-Netzwerk-Load-Balancer unterstützen die folgenden IPv6-Protokolloptionen für jede Weiterleitungsregel: TCP oder UDP.
Mit der Option L3_DEFAULT (Vorschau) können Sie Load Balancing für TCP-, UDP-, ICMP-, ICMPv6-, SCTP-, ESP-, AH- und GRE-Protokolle ausführen.
Neben der Unterstützung von anderen Protokollen als TCP und UDP ermöglicht es die Option L3_DEFAULT (Vorschau), dass eine einzige Weiterleitungsregel gleichzeitig Traffic für mehrere Protokolle weiterleitet. Sie können beispielsweise nicht nur HTTP-Anfragen stellen, sondern auch die IP-Adresse des Load Balancers per Ping kontaktieren.
Weiterleitungsregeln, die die Protokolle TCP oder UDP verwenden, können auf einen Back-End-Dienst verweisen, indem sie entweder dasselbe Protokoll wie die Weiterleitungsregel oder einen Back-End-Dienst mit dem Protokoll UNSPECIFIED verwenden.
Wenn Sie das Protokoll L3_DEFAULT (Vorschau) verwenden, müssen Sie die Weiterleitungsregel so konfigurieren, dass Traffic an allen Ports akzeptiert wird. Um alle Ports zu konfigurieren, stellen Sie entweder --ports=ALL mithilfe der Google Cloud-Befehlszeile ein oder setzen Sie mithilfe der API allPorts auf True.
In der folgenden Tabelle wird zusammengefasst, wie diese Einstellungen für verschiedene Protokolle verwendet werden.
| Traffic für das Load-Balancing | Protokoll der Weiterleitungsregel | Protokoll des Back-End-Dienstes |
|---|---|---|
| TCP (IPv4 oder IPv6) | TCP |
TCP or UNSPECIFIED |
| UDP (IPv4 oder IPv6) | UDP |
UDP or UNSPECIFIED |
| TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE | L3_DEFAULT |
UNSPECIFIED |
Weiterleitungsregeln und globaler Zugriff
Die Weiterleitungsregeln eines internen Passthrough-Netzwerk-Load-Balancers sind regional, auch wenn der globale Zugriff aktiviert ist. Nachdem Sie den globalen Zugriff aktiviert haben, wird das Flag allowGlobalAccess der regionalen internen Weiterleitungsregel auf true gesetzt.
Weiterleitungsregeln und Portspezifikationen
Wenn Sie eine interne Weiterleitungsregel erstellen, müssen Sie eine der folgenden Portspezifikationen auswählen:
- Geben Sie mindestens einen und bis zu fünf Ports mit Nummer an.
- Geben Sie
ALLan, um Traffic an allen Ports weiterzuleiten.
Mit einer internen Weiterleitungsregel, die entweder alle TCP-Ports oder alle UDP-Ports unterstützt, können Back-End-VMs mehrere Anwendungen jeweils mit eigenem Port ausführen. Traffic, der an einen bestimmten Port gesendet wird, wird an die entsprechende Anwendung geleitet, und alle Anwendungen verwenden dieselbe IP-Adresse.
Wenn Sie Traffic an mehr als fünf bestimmte Ports weiterleiten müssen, kombinieren Sie Firewallregeln mit Weiterleitungsregeln. Geben Sie beim Erstellen der Weiterleitungsregel alle Ports an und erstellen Sie dann allow-Firewallregeln für eingehenden Traffic, die nur Traffic zu den gewünschten Ports zulassen. Wenden Sie die Firewallregeln auf die Back-End-VMs an.
Nach dem Erstellen einer Weiterleitungsregel kann diese nicht mehr geändert werden. Wenn Sie die angegebenen Ports oder die interne IP-Adresse für eine interne Weiterleitungsregel ändern müssen, müssen Sie sie löschen und neu erstellen.
Mehrere Weiterleitungsregeln für einen einzelnen Back-End-Dienst
Sie können mehrere interne Weiterleitungsregeln konfigurieren, die alle auf denselben internen Back-End-Dienst verweisen. Für einen internen Passthrough-Netzwerk-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich.
Wenn Sie mehrere Weiterleitungsregeln für denselben Back-End-Dienst konfigurieren, können Sie Folgendes tun:
Weisen Sie dem Load-Balancer mehrere IP-Adressen zu. Sie können mehrere Weiterleitungsregeln mit jeweils einer eigenen IP-Adresse erstellen. Für jede Weiterleitungsregel können alle Ports oder eine Gruppe von bis zu fünf Ports angegeben werden.
Weisen Sie dem Load-Balancer eine bestimmte Gruppe von Ports mit derselben IP-Adresse zu. Sie können mehrere Weiterleitungsregeln mit derselben IP-Adresse erstellen, wobei jede Weiterleitungsregel eine bestimmte Gruppe von bis zu fünf Ports verwendet. Dies ist eine Alternative zur Konfiguration einer einzelnen Weiterleitungsregel, bei der alle Ports angegeben sind.
Weitere Informationen zu Szenarien mit zwei oder mehr internen Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse haben, finden Sie unter Mehrere Weiterleitungsregeln mit derselben IP-Adresse.
Wenn Sie mehrere interne Weiterleitungsregeln verwenden, sollten Sie die auf Ihren Back-End-VMs ausgeführte Software so konfigurieren, dass sie an alle IP-Adressen der Weiterleitungsregel oder an eine beliebige Adresse gebunden ist (0.0.0.0/0 für IPv4 oder::/0 für IPv6). Die Ziel-IP-Adresse für ein über den Load-Balancer ausgeliefertes Paket ist die interne IP-Adresse, die der entsprechenden internen Weiterleitungsregel zugeordnet ist. Weitere Informationen finden Sie unter TCP und UDP – Anfrage und Rückgabe von Paketen.
Back-End-Dienst
Jeder interne Passthrough-Netzwerk-Load-Balancer hat einen regionalen internen Back-End-Dienst, der Back-End-Parameter und das Verhalten definiert. Der Name des Back-End-Diensts ist der Name des internen TCP/UDP-Load-Balancers, der in der Google Cloud Console angezeigt wird.
Jeder Back-End-Dienst definiert die folgenden Back-End-Parameter:
Protokoll. Ein Back-End-Dienst unterstützt IPv4- und IPv6-Traffic. Wenn das Protokoll ein Konzept eines Ports hat (z. B.
TCPoderUDP), stellt der Back-End-Dienst Pakete an Back-End-VMs am selben Zielport bereit, an den der Traffic gesendet wurde.Back-End-Dienste unterstützen die folgenden IPv4-Protokolloptionen:
TCP,UDPoderUNSPECIFIED(Vorschau).Back-End-Dienste unterstützen die folgenden IPv6-Protokolloptionen:
TCPoderUDP. Das Protokoll des Back-End-Diensts muss sich mit dem Protokoll der Weiterleitungsregel abstimmen.Eine Tabelle mit möglichen Kombinationen von Weiterleitungsregeln und Back-End-Dienstprotokollen finden Sie in der Protokollspezifikation für Weiterleitungsregeln.
Traffic-Verteilung. Ein Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität.
Systemdiagnose. Ein Back-End-Dienst muss eine zugehörige Systemdiagnose haben.
Jeder Back-End-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic für Back-End-VMs in einem einzelnen VPC-Netzwerk:
Ein Back-End-Typ, eine Region. Back-Ends sind entweder Instanzgruppen oder zonale NEGs (mit
GCE_VM_IP-Endpunkten) in derselben Region wie der Back-End-Dienst (und die Weiterleitungsregel). Die Instanzgruppen-Back-Ends können nicht verwaltete Instanzgruppen, zonale verwaltete Instanzgruppen oder regionale verwaltete Instanzgruppen sein. Zonale NEG-Back-Ends müssenGCE_VM_IP-Endpunkte verwenden.Ein VPC-Netzwerk: Jede Instanzgruppe oder jedes NEG-Back-End ist mit einem VPC-Netzwerk verknüpft, auch wenn diese Instanzgruppe oder NEG noch nicht mit einem Back-End-Dienst verbunden ist. Weitere Informationen dazu, wie ein Netzwerk mit jedem Back-End-Typ verknüpft wird, finden Sie unter: Instanzgruppen-Back-Ends und Netzwerkschnittstellen und zonale NEG-Back-Ends und Netzwerkschnittstellen. Der Back-End-Dienstressource selbst ist auch ein VPC-Netzwerk zugeordnet, das explizit oder implizit definiert werden kann. Weitere Informationen zum Netzwerk des Back-End-Diensts finden Sie unter Netzwerkspezifikation für Back-End-Dienste und Netzwerkregeln für Back-End-Dienste.
Instanzgruppen-Back-Ends und Netzwerkschnittstellen
Das mit einer Instanzgruppe verknüpfte VPC-Netzwerk ist das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 jeder Mitglied-VM verwendet wird.
- Bei verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe in der Instanzvorlage definiert.
- Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe als das VPC-Netzwerk definiert, das von der Netzwerkschnittstelle
nic0der ersten VM-Instanz verwendet wird, die Sie der nicht verwalteten Instanzgruppe hinzufügen.
Innerhalb einer bestimmten (verwalteten oder nicht verwalteten) Instanzgruppe müssen alle VM-Instanzen die nic0-Netzwerkschnittstellen im selben VPC-Netzwerk haben.
Jede Mitglieds-VM kann optional eine zusätzliche Netzwerkschnittstelle (nic1 bis nic7) in einem VPC-Netzwerk haben, das sich vom VPC-Netzwerk, das der Instanzgruppe zugeordnet ist, unterscheidet.
Zonale NEG-Back-Ends und Netzwerkschnittstellen
Das VPC-Netzwerk, das einer zonalen NEG mit GCE_VM_IP-Endpunkten zugeordnet ist, wird beim Erstellen der zonalen NEG angegeben, bevor Sie ihr Endpunkte hinzufügen.
Innerhalb einer bestimmten NEG stellt jeder GCE_VM_IP-Endpunkt tatsächlich eine Netzwerkschnittstelle dar. Die Netzwerkschnittstelle muss sich in dem VPC-Netzwerk befinden, das mit der NEG verknüpft ist. Aus Sicht einer Compute Engine-Instanz kann die Netzwerkschnittstelle eine beliebige Kennung verwenden (nic0 bis nic7). Aus der Perspektive eines Endpunkts in einer NEG wird die Schnittstelle anhand ihrer primären IPv4-Adresse identifiziert.
Es gibt zwei Möglichkeiten, einer NEG einen GCE_VM_IP-Endpunkt hinzuzufügen:
- Wenn Sie beim Hinzufügen eines Endpunkts sowohl einen VM-Namen als auch eine IP-Adresse angeben, muss die von Ihnen angegebene IP-Adresse eine primäre interne IPv4-Adresse für eine der Netzwerkschnittstellen der VM sein. Diese Netzwerkschnittstelle muss das mit der NEG verknüpfte VPC-Netzwerk verwenden.
- Wenn Sie beim Hinzufügen eines Endpunkts nur einen VM-Namen (ohne IP-Adresse) angeben, erfordert Google Cloud, dass die VM eine Netzwerkschnittstelle in dem VPC-Netzwerk hat, das der NEG zugeordnet ist. Die IP-Adresse, die Google Cloud für den Endpunkt auswählt, ist die primäre interne IPv4-Adresse der Netzwerkschnittstelle im VPC-Netzwerk, das der NEG zugeordnet ist.
Netzwerkspezifikation für Back-End-Dienst
Sie können ein VPC-Netzwerk explizit mit einem Back-End-Dienst verknüpfen. Verwenden Sie dazu das Flag --network, wenn Sie den Back-End-Dienst erstellen. Die Netzwerkregeln für den Back-End-Dienst werden sofort wirksam.
Wenn Sie beim Erstellen eines Back-End-Dienstes das Flag --network weglassen, verwendet Google Cloud eines der folgenden qualifizierenden Ereignisse, um implizit das zugehörige VPC-Netzwerk des Back-End-Dienstes festzulegen. Nachdem sie festgelegt wurde, kann das zugehörige VPC-Netzwerk des Back-End-Dienstes nicht mehr geändert werden:
Wenn der Back-End-Dienst noch keine zugehörigen Back-Ends hat und Sie die erste Weiterleitungsregel so konfigurieren, dass sie auf den Back-End-Dienst verweist, legt Google Cloud das verknüpfte VPC-Netzwerk auf das VPC-Netzwerk fest, das das von dieser Weiterleitungsregel verwendete Subnetz enthält.
Wenn der Back-End-Dienst noch nicht auf eine Weiterleitungsregel verweist und Sie das erste Instanzgruppen-Back-End dem Back-End-Dienst hinzufügen, legt Google Cloud das VPC-Netzwerk des Back-End-Dienstes auf das VPC-Netzwerk fest, das dem ersten Instanzgruppen-Back-End zugeordnet ist. Dies bedeutet, dass das mit dem Back-End-Dienst verknüpfte VPC-Netzwerk das Netzwerk ist, das von der Netzwerkschnittstelle
nic0jeder VM im ersten Instanzgruppen-Back-End verwendet wird.Wenn der Back-End-Dienst noch keine Weiterleitungsregel hat, die darauf verweist, und Sie das erste zonale NEG-Back-End (mit
GCE_VM_IP-Endpunkten) zum Back-End-Dienst hinzufügen, legt Google Cloud den Back-End-Dienst für das VPC-Netzwerk fest, das diesem ersten NEG-Back-End zugeordnet ist.
Nachdem das VPC-Netzwerk des Back-End-Dienstes durch ein qualifizierendes Ereignis festgelegt wurde, müssen alle zusätzlichen Weiterleitungsregeln, Back-End-Instanzgruppen oder von Ihnen hinzugefügten zonalen Back-End-NEGs müssen den Netzwerkregeln für Back-End-Dienste folgen.
Netzwerkregeln für Back-End-Dienste
Die folgenden Regeln gelten, nachdem ein Back-End-Dienst mit einem bestimmten VPC-Netzwerk verknüpft ist.
Wenn Sie eine Weiterleitungsregel für den Verweis auf den Back-End-Dienst konfigurieren, muss die Weiterleitungsregel ein Subnetz des VPC-Netzwerks des Back-End-Dienstes verwenden. Weiterleitungsregeln und Back-End-Dienste können keine unterschiedlichen VPC-Netzwerke verwenden, auch wenn diese Netzwerke über VPC-Netzwerk-Peering verbunden sind.
Beim Hinzufügen von Instanzgruppen-Back-Ends muss eine der folgenden Bedingungen erfüllt sein:
- Das VPC-Netzwerk, das der Instanzgruppe zugeordnet ist und von der Netzwerkschnittstelle
nic0jeder VM in der Instanzgruppe verwendet wird, muss mit dem zugehörigen VPC-Netzwerk des Back-End-Dienstes übereinstimmen. - Jede Back-End-VM muss eine Nicht-
nic0-Schnittstelle (nic1bisnic7) im VPC-Netzwerk haben, das dem Back-End-Dienst zugeordnet ist.
- Das VPC-Netzwerk, das der Instanzgruppe zugeordnet ist und von der Netzwerkschnittstelle
Wenn Sie zonale NEG-Back-Ends mit
GCE_VM_IP-Endpunkten hinzufügen, muss das mit der NEG verknüpfte VPC-Netzwerk mit dem VPC-Netzwerk übereinstimmen, das dem Back-End-Dienst zugeordnet ist.
Back-End-Teilmengeneinstellung
Die Back-End-Teilmengeneinstellung ist eine optionale Funktion, die die Leistung verbessert, indem die Anzahl der Back-Ends begrenzt wird, auf die der Traffic verteilt wird.
Sie sollten die Teilmengeneinstellung nur aktivieren, wenn Sie mehr als 250 Back-End-VMs auf einem einzelnen Load-Balancer unterstützen müssen. Weitere Informationen finden Sie unter Back-End-Teilmengeneinstellung für internen Passthrough-Netzwerk-Load-Balancer.
Systemdiagnose
Der Back-End-Dienst des Load-Balancers muss einer globalen oder regionalen Systemdiagnose zugeordnet sein. Spezielle Routen außerhalb des VPC-Netzwerks erleichtern die Kommunikation zwischen Systemdiagnosen und Back-Ends.
Sie können eine vorhandene Systemdiagnose verwenden oder eine neue definieren. Die internen Passthrough-Netzwerk-Load-Balancer verwenden den Systemdiagnosestatus wie unter Traffic-Verteilung beschrieben, um zu bestimmen, wie neue Verbindungen weitergeleitet werden.
Sie können eines der folgenden Systemdiagnoseprotokolle verwenden: Das Protokoll der Systemdiagnose muss nicht mit dem Protokoll des Load-Balancers übereinstimmen:
- HTTP, HTTPS oder HTTP/2. Wenn Ihre Back-End-VMs Traffic über HTTP, HTTPS oder HTTP/2 bereitstellen, verwenden Sie am besten eine Systemdiagnose, die mit diesem Protokoll übereinstimmt, da HTTP-basierte Systemdiagnosen geeignete Optionen für dieses Protokoll bieten. Die Bereitstellung von HTTP-Traffic über einen internen Passthrough-Netzwerk-Load-Balancer bedeutet, dass das Protokoll des Load-Balancers TCP ist.
- SSL oder TCP. Wenn Ihre Back-End-VMs keinen HTTP-Traffic bereitstellen, sollten Sie entweder eine SSL- oder eine TCP-Systemdiagnose verwenden.
Unabhängig vom Typ der erstellten Systemdiagnose sendet Google Cloud Systemdiagnoseprüfungen an die IP-Adresse der Weiterleitungsregel des internen Passthrough-Netzwerk-Load-Balancers und an die Netzwerkschnittstelle im vom Back-End-Dienst des Load-Balancers ausgewählten VPC-Netzwerk. Hiermit wird simuliert, wie Traffic mit Load-Balancing gesendet wird. Software, die auf Ihren Back-End-VMs ausgeführt wird, muss sowohl auf Traffic mit Load-Balancing als auch auf Systemdiagnoseprüfungen reagieren, die an die IP-Adresse der einzelnen Weiterleitungsregeln gesendet werden. Die Software muss über 0.0.0.0:<port> und nicht über eine bestimmte IP-Adresse reagieren, die einer Netzwerkschnittstelle zugewiesen ist. Weitere Informationen finden Sie unter Ziel für Prüfungspakete.
Systemdiagnosen und UDP-Traffic
Google Cloud bietet keine Systemdiagnose, bei der das UDP-Protokoll verwendet wird. Wenn Sie einen internen Passthrough-Netzwerk-Load-Balancer mit UDP-Traffic verwenden, müssen Sie auf Ihren Back-End-VMs einen TCP-basierten Dienst ausführen, um Informationen aus der Systemdiagnoseprüfung bereitzustellen.
Bei dieser Konfiguration erfolgt das Load-Balancing von Clientanfragen mithilfe des UDP-Protokolls und ein TCP-Dienst wird verwendet, um den Systemdiagnoseprüfern von Google Cloud Informationen bereitzustellen. Sie können beispielsweise auf jeder Back-End-VM, die eine HTTP 200-Antwort an Google Cloud zurückgibt, einen einfachen HTTP-Server ausführen. In diesem Beispiel sollten Sie Ihre eigene Logik verwenden, die auf der Back-End-VM ausgeführt wird, um dafür zu sorgen, dass der HTTP-Server nur dann 200 zurückgibt, wenn der UDP-Dienst richtig konfiguriert ist und ordnungsgemäß ausgeführt wird.
Hochverfügbarkeitsarchitektur
Der interne Passthrough-Netzwerk-Load-Balancer ist standardmäßig hochverfügbar. Es gibt keine speziellen Schritte, um den Load-Balancer hochverfügbar zu machen, da der Mechanismus nicht auf einem einzelnen Gerät oder einer einzigen VM-Instanz beruht.
Gehen Sie gemäß dieser Empfehlungen vor, um Ihre Back-End-VM-Instanzen in mehreren Zonen bereitzustellen:
Verwenden Sie regional verwaltete Instanzgruppen, wenn Sie Ihre Software mithilfe von Instanzvorlagen bereitstellen können. Regional verwaltete Instanzgruppen verteilen den Traffic automatisch auf mehrere Zonen. Dadurch lassen sich potenzielle Probleme in einer bestimmten Zone vermeiden.
Bei zonal verwalteten Instanzgruppen oder nicht verwalteten Instanzgruppen verwenden Sie für denselben Back-End-Dienst mehrere Instanzgruppen in verschiedenen Zonen (in derselben Region). Die Verwendung mehrerer Zonen schützt vor möglichen Problemen in einer bestimmten Zone.
Architektur einer freigegebenen VPC
In der folgenden Tabelle sind die Komponentenanforderungen für interne Passthrough-Netzwerk-Load-Balancer zusammengefasst, die mit freigegebenen VPC-Netzwerken verwendet werden. Ein Beispiel finden Sie auf der Seite „Internen Passthrough-Netzwerk-Load-Balancer auf der bereitgestellten freigegebenen VPC erstellen“.
| IP-Adresse | Weiterleitungsregel | Back-End-Komponenten |
|---|---|---|
| Eine interne IP-Adresse muss im selben Projekt wie die Back-End-VMs definiert werden.
Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne IP-Adresse von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss es auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde. Wenn Sie eine interne IP-Adresse in einem Dienstprojekt erstellen und sich das IP-Adress-Subnetz im VPC-Netzwerk des Dienstprojekts befindet, wird der interne Passthrough-Netzwerk-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet. |
Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-End-VMs definiert werden.
Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist. Wenn Sie in einem Dienstprojekt eine interne Weiterleitungsregel erstellen und sich das Subnetz der Weiterleitungsregel im VPC-Netzwerk des Dienstprojekts befindet, wird der interne Passthrough-Netzwerk-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet. |
Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Back-End-VMs in einem Dienstprojekt. Dort müssen auch der regionale interne Back-End-Dienst und die Systemdiagnose definiert werden. |
Traffic-Verteilung
Wie ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen verteilt, hängt davon ab, ob Sie ein Failover konfiguriert haben:
Wenn Sie kein Failover konfiguriert haben, verteilt ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen an seine fehlerfreien Back-End-VMs, wenn wenigstens eine Back-End-VM fehlerfrei ist. Wenn alle Back-End-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Back-Ends. In diesem Fall leitet der Load-Balancer jede neue Verbindung an eine fehlerhafte Back-End-VM weiter.
Wenn Sie ein Failover konfiguriert haben, verteilt ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen zwischen VMs in seinem aktiven Pool gemäß einer von Ihnen konfigurierten Failover-Richtlinie. Wenn alle Back-End-VMs fehlerhaft sind, können Sie aus folgenden Verhaltensweisen eine auswählen:
- (Standardeinstellung) Der Load-Balancer verteilt den Traffic nur auf die primären VMs. Dies wird als letztes Mittel unternommen. Die Backup-VMs sind von dieser letztes-Mittel-Verteilung der Verbindungen ausgeschlossen.
- Der Load-Balancer ist so konfiguriert, dass Traffic unterbrochen wird.
Die Methode zum Verteilen neuer Verbindungen hängt von der Einstellung der Sitzungsaffinität des Load-Balancers ab.
Der Status der Systemdiagnose steuert die Verteilung neuer Verbindungen. Standardmäßig bleiben TCP-Verbindungen auf fehlerhaften Back-Ends bestehen. Weitere Informationen und Anleitungen zum Ändern dieses Verhaltens finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.
Auswahl von Back-End und Verbindungs-Tracking
Interne Passthrough-Netzwerk-Load-Balancer verwenden konfigurierbare Algorithmen zur Auswahl von Back-End und Verbindungs-Tracking, um zu bestimmen, wie der Traffic an Back-End-VMs verteilt wird. Interne Passthrough-Netzwerk-Load-Balancer verwenden den folgenden Algorithmus, um Pakete an Back-End-VMs zu verteilen (in seinem aktiven Pool, wenn Sie ein Failover konfiguriert haben):
- Wenn der Load-Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle hat, der den Eigenschaften eines eingehenden Pakets entspricht, wird das Paket an das Back-End gesendet, das durch den Tabelleneintrag in der Verbindungs-Tracking-Tabelle angegeben wird. Das Paket wird als Teil einer zuvor hergestellten Verbindung betrachtet. Es wird daher an die Back-End-VM gesendet, die der Load-Balancer zuvor ermittelt und in seiner Verbindungs-Tracking-Tabelle erfasst hat.
Wenn der Load-Balancer ein Paket empfängt, für das er keinen Verbindungs-Tracking-Eintrag hat, führt der Load-Balancer folgende Schritte aus:
Der Load-Balancer wählt ein Back-End aus. Der Load-Balancer berechnet einen Hash anhand der konfigurierten Sitzungsaffinität. Anhand dieses Hashs wird ein Back-End ausgewählt:
- Wenn mindestens ein Back-End fehlerfrei ist, wählt der Hash eines der fehlerfreien Back-Ends aus.
- Wenn alle Back-Ends fehlerhaft sind und keine Failover-Richtlinie konfiguriert wurde, wählt der Hash eines der Back-Ends aus.
- Wenn alle Back-Ends fehlerhaft sind, wird eine Failover-Richtlinie konfiguriert und die Failover-Richtlinie wird nicht so konfiguriert, dass der Traffic in dieser Situation unterbrochen wird. Der Hash wählt dann eines der primären VM-Back-Ends aus.
Die Standardaffinität
NONEverwendet einen 5-Tupel-Hash der Quell-IP-Adresse, des Quellports, der Ziel-IP-Adresse, des Zielports und des Protokolls im Paket.Die Back-End-Auswahl kann mithilfe eines Hash-Algorithmus angepasst werden, der weniger Informationen verwendet. Informationen zu allen unterstützten Optionen finden Sie unter Optionen für die Sitzungsaffinität.
Der Load-Balancer fügt der Tabelle für das Verbindungs-Tracking einen Eintrag hinzu. Dieser Eintrag zeichnet das ausgewählte Back-End für die Verbindung des Pakets auf, sodass alle zukünftigen Pakete von dieser Verbindung an dasselbe Back-End gesendet werden. Ob das Verbindungs-Tracking verwendet wird, hängt vom Protokoll ab:
Bei TCP- und UDP-Paketen ist das Verbindungs-Tracking immer aktiviert und kann nicht deaktiviert werden. Standardmäßig ist das Verbindungs-Tracking 5-Tupel. Es kann aber so konfiguriert werden, dass es weniger als 5-Tupel umfasst.
Wenn der Verbindungs-Tracking-Hash ein 5-Tupel ist, erstellen TCP-SYN-Pakete immer einen neuen Eintrag in der Tabelle für das Verbindungs-Tracking.
Das standardmäßige 5-Tupel-Verbindungs-Tracking wird in folgenden Fällen verwendet:- Tracking-Modus ist
PER_CONNECTION(alle Sitzungsaffinitäten), oder - Tracking-Modus ist
PER_SESSIONund die Sitzungsaffinität istNONE, oder - Tracking-Modus ist
PER_SESSIONund die Sitzungsaffinität istCLIENT_IP_PORT_PROTO.
Weitere Informationen darüber, wann das Verbindungs-Tracking aktiviert ist und welche Tracking-Methode beim Aktivieren des Verbindungs-Trackings verwendet wird, finden Sie unter Verbindungs-Tracking-Modus.
Außerdem sollten Sie Folgendes beachten:
- Ein Eintrag in der Verbindungs-Tracking-Tabelle läuft standardmäßig nach 600 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmte. Weitere Informationen zum Anpassen der Zeitüberschreitung bei Inaktivität finden Sie im Abschnitt Zeitüberschreitung bei Inaktivität.
- Je nach Protokoll entfernt der Load-Balancer möglicherweise Verbindungs-Tracking-Tabelleneinträge, wenn Back-Ends fehlerhaft werden. Weitere Informationen dazu und zum Anpassen dieses Verhaltens finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.
- Tracking-Modus ist
Optionen der Sitzungsaffinität
Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Back-End-VMs des Load-Balancers. Legen Sie die Sitzungsaffinität fest, wenn Ihre Back-End-VMs Statusinformationen für ihre Clients verfolgen müssen. Dies ist eine gängige Anforderung für Webanwendungen.
Die Sitzungsaffinität basiert auf dem Best-Effort-Prinzip.
Interne Passthrough-Netzwerk-Load-Balancer unterstützen die folgenden Optionen für die Sitzungsaffinität, die Sie für den gesamten internen Back-End-Dienst und nicht einzeln für jede Back-End-Instanzgruppe angeben.
- Keine (
NONE) 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport - Client-IP, kein Ziel (
CLIENT_IP_NO_DESTINATION). 1-Tupel-Hash, der nur aus der Quell-IP-Adresse erstellt wird. - Client-IP (
CLIENT_IP). 2-Tupel-Hash von Quell-IP-Adresse und Ziel-IP-Adresse. Externe Passthrough-Netzwerk-Load-Balancer rufen diese Sitzungsaffinitätsoption auf: Client-IP, Ziel-IP. - Client-IP, Ziel-IP, Protokoll (
CLIENT_IP_PROTO). 3-Tupel-Hash von Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll - Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (
CLIENT_IP_PORT_PROTO). 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport
Wenn Sie den Load-Balancer nicht als nächsten Hop für eine benutzerdefinierte statische Route verwenden, muss die Ziel-IP-Adresse eines Pakets mit der IP-Adresse der Weiterleitungsregel des Load-Balancers übereinstimmen, damit das Paket an den Load-Balancer gesendet werden kann. Hinweise zur Verwendung des Load-Balancers als nächsten Hop für eine benutzerdefinierte statische Route finden Sie unter Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer als nächster Hop.
Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer für den nächsten Hop
Wenn Sie einen internen Passthrough-Netzwerk-Load-Balancer als nächsten Hop für eine benutzerdefinierte statische Route verwenden, ist das Ziel des Pakets höchstwahrscheinlich nicht die IP-Adresse der Weiterleitungsregel des Load-Balancers.
Ein Paket wird an den Load-Balancer gesendet, wenn das Ziel des Pakets im Ziel der benutzerdefinierten statischen Route liegt und die benutzerdefinierte statische Route eine anwendbare Route ist.
Alle Optionen für die Sitzungsaffinität (außer Client-IP, kein Ziel) verwenden die IP-Adresse des Ziels des Pakets. Wenn Sie eine benutzerdefinierte statische Route verwenden, deren nächster Hop ein interner Passthrough-Netzwerk-Load-Balancer ist:
Wenn der Load-Balancer nur ein Back-End hat (den aktiven Pool, wenn Sie das Failover konfiguriert haben), wird dieses Back-End von allen Optionen der Sitzungsaffinität ausgewählt. Die Wahl der Sitzungsaffinität spielt keine Rolle, wenn ein einzelnes Back-End (im aktiven Pool) vorhanden ist.
Wenn der Load-Balancer mehrere Back-Ends hat (in seinem aktiven Pool, wenn Sie das Failover konfiguriert haben), wählen Sie eine Option für die Sitzungsaffinität aus (mit Ausnahme von Client-IP, keinem Ziel). Pakete, die vom selben Client an eine IP-Adresse am Ziel der Route gesendet werden, werden nicht unbedingt von demselben Back-End verarbeitet. Dies liegt daran, dass der Sitzungsaffinitäts-Hash aus Informationen berechnet wird, die auch die Ziel-IP-Adresse des Pakets enthalten, bei der es sich um eine beliebige Adresse im Zielbereich der Route handeln kann.
Wenn Sie garantieren müssen, dass dasselbe Back-End alle Pakete verarbeitet, die von demselben Client an eine IP-Adresse am Ziel der Route gesendet werden, müssen Sie die Option Client-IP, kein Ziel für die Sitzungsaffinität verwenden.
Verbindungs-Tracking-Modus
Im Tracking-Modus wird der Algorithmus für das Verbindungs-Tracking angegeben, der verwendet werden soll. Es gibt zwei Tracking-Modi: PER_CONNECTION (Standard) und PER_SESSION.
PER_CONNECTION(Standard). In diesem Modus werden TCP- und UDP-Traffic immer pro 5-Tupel verfolgt, unabhängig von der Einstellung der Sitzungsaffinität. Dies bedeutet, dass sich der Schlüssel für das Verbindungs-Tracking (5-Tupel) von der konfigurierten Einstellung der Sitzungsaffinität unterscheiden kann (z. B. 3-Tupel mit der EinstellungCLIENT_IP_PROTO). Dadurch kann die Sitzungsaffinität aufgeteilt werden und neue Verbindungen für eine Sitzung können ein anderes Back-End auswählen, wenn sich der Back-End-Satz oder ihr Zustand ändern.PER_SESSION. In diesem Modus wird TCP- und UDP-Traffic gemäß der konfigurierten Sitzungsaffinität erfasst. Das heißt, wenn die SitzungsaffinitätCLIENT_IPoderCLIENT_IP_PROTOist, führt das Konfigurieren dieses Modus zu einem 2-Tupel- oder 3-Tupel-Verbindungs-Tracking. Dies kann in Szenarien wünschenswert sein, in denen die Unterbrechung der Affinität teuer ist, und sollte vermieden werden, auch nachdem mehr Back-Ends hinzugefügt wurden.
Die Einstellung für den Verbindungs-Tracking-Modus ist redundant, wenn die Sitzungsaffinität auf NONE oder CLIENT_IP_PORT_PROTO festgelegt ist. Informationen zur Funktionsweise dieser Tracking-Modi mit unterschiedlichen Einstellungen für die Sitzungsaffinität für jedes Protokoll finden Sie in der folgenden Tabelle.
| Back-End-Auswahl | Verbindungs-Tracking-Modus | ||
|---|---|---|---|
| Einstellung für die Sitzungsaffinität | Hash-Methode für die Back-End-Auswahl | PER_CONNECTION (Standard) |
PER_SESSION |
| Standard: Keine Sitzungsaffinität
|
5-Tupel-Hash | 5-Tupel-Verbindungs-Tracking | 5-Tupel-Verbindungs-Tracking |
Client-IP, kein Ziel
|
1-Tupel-Hash | 5-Tupel-Verbindungs-Tracking | 1-Tupel-Verbindungs-Tracking |
Client-IP
(entspricht der Client-IP, der Ziel-IP für externe Netzwerk-Load-Balancer im Netzwerk) |
2-Tupel-Hash | 5-Tupel-Verbindungs-Tracking | 2-Tupel-Verbindungs-Tracking |
Client-IP, Ziel-IP, Protokoll
|
3-Tupel-Hash | 5-Tupel-Verbindungs-Tracking | 3-Tupel-Verbindungs-Tracking |
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll
|
5-Tupel-Hash | 5-Tupel-Verbindungs-Tracking | 5-Tupel-Verbindungs-Tracking |
Informationen zum Ändern des Verbindungs-Tracking-Modus finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.
Verbindungspersistenz auf fehlerhaften Back-Ends
Die Einstellung für die Verbindungspersistenz bei fehlerhaften Back-Ends steuert, ob eine vorhandene Verbindung auf einem ausgewählten Back-End bestehen bleibt, nachdem dieses Back-End fehlerhaft wird (solange das Back-End in der konfigurierten Back-End-Instanzgruppe des Load-Balancers verbleibt).
Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Back-End-VM aus der Instanzgruppe oder die Instanzgruppe aus dem Back-End-Dienst entfernen. In solchen Fällen bleiben vorhandene Verbindungen nur bestehen, wie unter Verbindungsausgleich aktivieren beschrieben.
Die folgenden Optionen für die Verbindungspersistenz sind verfügbar:
DEFAULT_FOR_PROTOCOL(Standard)NEVER_PERSISTALWAYS_PERSIST
In der folgenden Tabelle werden die Optionen für die Verbindungspersistenz beschrieben und wie die Verbindungen für verschiedene Protokolle, Sitzungsaffinitätsoptionen und Tracking-Modi beibehalten werden.
| Option zur Verbindungspersistenz bei fehlerhaften Back-Ends | Verbindungs-Tracking-Modus | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten). UDP: Verbindungen bleiben auf fehlerhaften Back-Ends nicht bestehen |
TCP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, wenn die Sitzungsaffinität UDP: Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen |
NEVER_PERSIST |
TCP-, UDP-Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen | |
ALWAYS_PERSIST
|
TCP, UDP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten). Diese Option sollte nur für erweiterte Anwendungsfälle verwendet werden. |
Konfiguration nicht möglich |
Informationen zum Ändern des Verhaltens der Verbindungspersistenz finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.
Zeitüberschreitung bei Inaktivität
Ein Eintrag in der Tabelle für das Verbindungs-Tracking läuft standardmäßig nach 600 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmte. Dieser Standardwert für die Zeitüberschreitung bei Inaktivität kann nur geändert werden, wenn das Verbindungs-Tracking weniger als 5-Tupel beträgt (d. h., wenn die Sitzungsaffinität entweder als CLIENT_IP oder CLIENT_IP_PROTO konfiguriert und der Tracking-Modus PER_SESSION ist).
Der maximal konfigurierbare Wert für die Zeitüberschreitung bei Inaktivität beträgt 57.600 Sekunden (16 Stunden).
Informationen zum Ändern des Werts für die Zeitüberschreitung bei Inaktivität finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.
Verbindungen von einem einzelnen Client aus testen
Beim Testen von Verbindungen zur IP-Adresse eines internen Passthrough-Netzwerk-Load-Balancers von einem einzelnen Clientsystem aus sollten Sie Folgendes beachten:
Wenn das Clientsystem keine VM ist, für die Load-Balancing durchgeführt wird, also keine Back-End-VM, werden neue Verbindungen an die fehlerfreien Back-End-VMs des Load-Balancers gesendet. Da jedoch alle Sitzungsaffinitätsoptionen mindestens die IP-Adresse des Clientsystems benötigen, werden Verbindungen von demselben Client häufiger als erwartet an dieselbe Back-End-VM verteilt.
Praktisch bedeutet dies, dass Sie die Trafficverteilung über einen internen Passthrough-Netzwerk-Load-Balancer nicht genau überwachen können, indem Sie über einen einzigen Client eine Verbindung zu ihm herstellen. Die Anzahl der Clients, die zur Überwachung der Trafficverteilung benötigt werden, hängt vom Typ des Load-Balancers, der Art des Traffics und der Anzahl fehlerfreier Back-Ends ab.
Wenn die Client-VM eine Back-End-VM des Load-Balancers ist, werden Verbindungen, die an die IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden, immer von der Client-Back-End-VM beantwortet. Dies geschieht unabhängig davon, ob die Back-End-VM fehlerfrei ist. Dies gilt für den gesamten Traffic, der an die IP-Adresse des Load-Balancers gesendet wird, nicht nur für den Traffic für das Protokoll und die Ports, die in der internen Weiterleitungsregel des Load-Balancers angegeben sind.
Weitere Informationen finden Sie unter Anfragen von VMs mit Load-Balancing senden.
UDP-Fragmentierung
Interne Passthrough-Netzwerk-Load-Balancer können sowohl fragmentierte als auch nicht fragmentierte UDP-Pakete verarbeiten. Wenn Ihre Anwendung fragmentierte UDP-Datenpakete verwendet, beachten Sie Folgendes:- UDP-Pakete können fragmentiert werden, bevor Sie ein Google Cloud-VPC-Netzwerk erreichen.
- Google Cloud VPC-Netzwerke leiten UDP-Fragmente direkt bei Eingang weiter (ohne auf alle Fragmente zu warten).
- Nicht-Google Cloud-Netzwerke und lokale Netzwerkgeräte können eingehende UDP-Fragmente bei Eingang weiterleiten, fragmentierte UDP-Pakete verzögern, bis alle Fragmente eingegangen sind, oder fragmentierte UDP-Pakete verwerfen. Weitere Informationen finden Sie in der Dokumentation des Netzwerkanbieters oder der Netzwerkgeräte.
Wenn Sie fragmentierte UDP-Datenpakete erwarten und diese an dieselben Back-Ends weiterleiten müssen, verwenden Sie die folgenden Weiterleitungsregel und Back-End-Dienstkonfigurationsparameter:
Weiterleitungsregel konfigurieren: Verwenden Sie nur eine
UDP-Weiterleitungsregel pro IP-Adresse mit Load-Balancing und konfigurieren Sie die Weiterleitungsregel so, dass Traffic an allen Ports akzeptiert wird. Dadurch wird gewährleistet, dass alle Fragmente zur selben Weiterleitungsregel gelangen. Auch wenn die fragmentierten Pakete (mit Ausnahme des ersten Fragments) keinen Zielport haben, wird beim Konfigurieren der Weiterleitungsregel für die Verarbeitung von Traffic für alle Ports auch dieser so konfiguriert, dass UDP-Fragmente ohne Portinformationen empfangen werden. Konfigurieren Sie entweder die Google Cloud CLI, um--ports=ALLfestzulegen, oder verwenden Sie die API, umallPortsaufTrueeinzustellen.Konfiguration des Back-End-Diensts: Legen Sie die Sitzungsaffinität des Back-End-Diensts auf
CLIENT_IP(2-Tupel-Hash) oderCLIENT_IP_PROTO(3-Tupel-Hash) fest, sodass dasselbe Back-End für UDP-Pakete ausgewählt wird, die Portinformationen und UDP-Fragmente (außer dem ersten Fragment) enthalten, für die Portinformationen fehlen. Setzen Sie den Verbindungs-Tracking-Modus des Back-End-Dienstes aufPER_SESSION, damit die Einträge für das Verbindungs-Tracking-Tabellen mit denselben 2-Tupel- oder 3-Tupel-Hashes erstellt werden.
Failover
Mit einem internen Passthrough-Netzwerk-Load-Balancer können Sie einige Back-Ends als Failover-Back-Ends festlegen. Diese Back-Ends werden nur verwendet, wenn die Anzahl der fehlerfreien VMs in den primären Back-End-Instanzgruppen unter einem konfigurierbaren Schwellenwert liegt. Wenn alle primären und Failover-VMs fehlerhaft sind, verteilt Google Cloud standardmäßig als letztes Mittel neue Verbindungen nur auf alle primären VM.
Wenn Sie ein Back-End zu einem Back-End-Dienst eines internen Passthrough-Netzwerk-Load-Balancers hinzufügen, ist standardmäßig das Back-End ein primäres Back-End. Sie können ein Back-End als Failover-Back-End festlegen, wenn Sie es dem Back-End-Dienst des Load-Balancers hinzufügen oder den Back-End-Dienst später bearbeiten.
Eine detaillierte konzeptionelle Übersicht über das Failover in internen Passthrough-Netzwerk-Load-Balancern finden Sie unter Failover für interne Netzwerk-Passthrough-Load-Balancer.
Kontingente und Limits
Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.
Beschränkungen
- Die Google Cloud Console bietet keine Möglichkeiten zur Ausführung folgender Aufgaben:
- Erstellen oder Ändern eines internen Passthrough-Netzwerk-Load-Balancers, dessen Weiterleitungsregel das
L3_DEFAULT-Protokoll verwendet.
- Erstellen oder Ändern eines internen Passthrough-Netzwerk-Load-Balancers, dessen Weiterleitungsregel das
Nächste Schritte
- Informationen zum Konfigurieren und Testen eines internen Passthrough-Netzwerk-Load-Balancers finden Sie unter Internen Passthrough-Netzwerk-Load-Balancer einrichten.
- Informationen zum Konfigurieren von Cloud Monitoring für interne Netzwerk-Load-Balancer finden Sie unter Logging und Monitoring für interne Passthrough-Netzwerk-Load-Balancer.
- Probleme mit dem internen Passthrough-Netzwerk-Load-Balancer können Sie unter Fehlerbehebung bei internen Passthrough-Netzwerk-Load-Balancern beheben.