Übersicht über internen Passthrough-Netzwerk-Load-Balancer

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.

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 TCP-, UDP-, ICMP-, ICMPv6-, SCTP-, ESP-, AH- und GRE-Protokolle.
• 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. Einige allgemeine Beispiele finden Sie unter Übersicht: Passthrough-Network-Load-Balancer.

Funktionsweise von internen Passthrough-Netzwerk-Load-Balancern

Ein interner Passthrough-Netzwerk-Load-Balancer hat ein Frontend (die Weiterleitungsregel) und ein Backend (den Backend-Dienst). Sie können für den Backend-Dienst entweder Instanzgruppen oder GCE_VM_IP zonale NEGs als Backends verwenden. Dieses Beispiel zeigt Instanzgruppen-Backends.

Allgemeines Beispiel für einen internen Passthrough-Network-Load-Balancer (zum Vergrößern klicken).

Im Gegensatz zu einem Proxy-Load-Balancer beendet ein interner Passthrough-Netzwerk-Load-Balancer keine Verbindungen von Clients und öffnet keine neuen Verbindungen zu Backends. Stattdessen leitet ein interner Passthrough-Netzwerk-Load-Balancer Verbindungen ohne Unterbrechung direkt von Clients an die fehlerfreien Backends weiter. Antworten von fehlerfreien Backend-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 Backend-Status über 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 INTERNAL und einem unterstützten Protokoll. Weitere Informationen finden Sie unter Back-End-Dienst.
• Backend-VMs, die als eine der folgenden Optionen angegeben werden:
  • Verwaltete und nicht verwaltete Instanzgruppen in einer Region und einem VPC-Netzwerk.
  • Zonale Backend-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, UDP oder L3_DEFAULT (Vorschau) verwenden und dem Protokoll des Backend-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:

• Backend-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 unterstützt der Load-Balancer nur Clients, die sich in derselben Region wie der Load-Balancer befinden. Clients können sich im selben Netzwerk wie der Load-Balancer 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.

Interner Passthrough-Network-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)

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 Backend-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 Backend-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.0 oder ::) ü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 Backend-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 Backend-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 Backend-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 Backend-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 Backend-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	Voraussetzungen
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 Frontend des Load-Balancers. Sie definiert das Protokoll und die Ports, die der Load-Balancer akzeptiert, und leitet den Traffic an einen regionalen internen Backend-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 Backend-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.

Ein interner Passthrough-Netzwerk-Load-Balancer unterstützt nicht:

• Backend-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.

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-type ist auf INTERNAL gesetzt).

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 aus IPv4- oder Quell-IPv6-Adressbereichen der Clients 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 Backend-Dienst verweisen. Der Backend-Dienst muss jedoch auf Dual-Stack-Backends verweisen.

Die Weiterleitungsregel muss auf ein bestimmtes Subnetz im selben VPC-Netzwerk und in derselben Region wie die Backend-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 Backend-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, wobei ipv6-access-type auf INTERNAL gesetzt ist. Der IPv6-Adressbereich /96 wird 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.

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 Backend-Dienst verweisen, indem sie entweder dasselbe Protokoll wie die Weiterleitungsregel oder einen Backend-Dienst mit dem UNSPECIFIED-Protokoll verwenden.

Wenn Sie das Protokoll L3_DEFAULT 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 Backend-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 ALL an, um Traffic an allen Ports weiterzuleiten.

Mit einer internen Weiterleitungsregel, die entweder alle TCP-Ports oder alle UDP-Ports unterstützt, können Backend-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 Backend-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 Backend-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.

Backend-Dienst

Jeder interne Passthrough-Netzwerk-Load-Balancer hat einen regionalen internen Backend-Dienst, der Backend-Parameter und das Verhalten definiert. Der Name des Backend-Diensts ist der Name des internen TCP/UDP-Load-Balancers, der in der Google Cloud Console angezeigt wird.

Jeder Backend-Dienst definiert die folgenden Backend-Parameter:

• Protokoll. Ein Backend-Dienst unterstützt IPv4- und IPv6-Traffic. Wenn das Protokoll ein Konzept eines Ports hat (z. B. TCP oder UDP), stellt der Backend-Dienst Pakete an Backend-VMs am selben Zielport bereit, an den der Traffic gesendet wurde.

  Backend-Dienste unterstützen die folgenden IPv4-Protokolloptionen: TCP, UDP oder UNSPECIFIED.

  Backend-Dienste unterstützen die folgenden IPv6-Protokolloptionen: TCP oder UDP. Das Protokoll des Backend-Dienstes muss mit dem Protokoll der Weiterleitungsregel übereinstimmen.

  Eine Tabelle mit möglichen Kombinationen von Weiterleitungsregeln und Back-End-Dienstprotokollen finden Sie unter Protokollspezifikation für Weiterleitungsregeln.

• Traffic-Verteilung. Ein Backend-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität.

• Systemdiagnose. Ein Backend-Dienst muss eine zugehörige Systemdiagnose haben.

Jeder Backend-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic für Backend-VMs in einem einzelnen VPC-Netzwerk:

• Ein Backend-Typ, eine Region. Backends sind entweder Instanzgruppen oder zonale NEGs (mit GCE_VM_IP-Endpunkten) in derselben Region wie der Backend-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üssen GCE_VM_IP-Endpunkte verwenden.

• Ein VPC-Netzwerk: Jede Instanzgruppe oder jedes NEG-Backend ist mit einem VPC-Netzwerk verknüpft, auch wenn diese Instanzgruppe oder NEG noch nicht mit einem Backend-Dienst verbunden ist. Weitere Informationen dazu, wie ein Netzwerk mit jedem Backend-Typ verknüpft wird, finden Sie unter: Instanzgruppen-Backends und Netzwerkschnittstellen und zonale NEG-Backends und Netzwerkschnittstellen. Der Backend-Dienstressource selbst ist auch ein VPC-Netzwerk zugeordnet, das explizit oder implizit definiert werden kann. Weitere Informationen zum Netzwerk des Backend-Diensts finden Sie unter Netzwerkspezifikation für Backend-Dienste und Netzwerkregeln für Backend-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 nic0 der 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 zusätzliche Netzwerkschnittstellen (nic1 bis nic7) haben, aber jede Netzwerkschnittstelle muss an ein anderes VPC-Netzwerk angehängt werden. Diese Netzwerke müssen sich auch von dem VPC-Netzwerk unterscheiden, das der Instanzgruppe zugeordnet ist.

Zonale NEG-Back-Ends und Netzwerkschnittstellen

Wenn Sie eine neue zonale NEG mit GCE_VM_IP-Endpunkten erstellen, müssen Sie die NEG explizit mit einem Subnetzwerk eines VPC-Netzwerks verknüpfen, bevor Sie der NEG Endpunkte hinzufügen können. Weder das Subnetz noch das VPC-Netzwerk können nach dem Erstellen der NEG geändert werden.

Innerhalb einer bestimmten NEG stellt jeder GCE_VM_IP-Endpunkt tatsächlich eine Netzwerkschnittstelle dar. Die Netzwerkschnittstelle muss sich in dem Subnetzwerk befinden, das der NEG zugeordnet 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 nur einen VM-Namen (ohne IP-Adresse) angeben, erfordert Google Cloud, dass die VM eine Netzwerkschnittstelle in dem Subnetzwerk 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 der VM im Subnetzwerk, das der NEG zugeordnet ist.
• 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 sich in dem Subnetzwerk befinden, das mit der NEG verknüpft ist. Beachten Sie, dass die Angabe einer IP-Adresse redundant ist, da es nur eine einzige Netzwerkschnittstelle geben kann, die sich im Subnetzwerk befindet, das der NEG zugeordnet ist.

Netzwerkspezifikation für Backend-Dienst

Sie können ein VPC-Netzwerk explizit mit einem Backend-Dienst verknüpfen. Verwenden Sie dazu das Flag --network, wenn Sie den Backend-Dienst erstellen. Die Netzwerkregeln für den Backend-Dienst werden sofort wirksam.

Wenn Sie beim Erstellen eines Backend-Dienstes das Flag --network weglassen, verwendet Google Cloud eines der folgenden qualifizierenden Ereignisse, um implizit das zugehörige VPC-Netzwerk des Backend-Dienstes festzulegen. Nachdem sie festgelegt wurde, kann das zugehörige VPC-Netzwerk des Backend-Dienstes nicht mehr geändert werden:

• Wenn der Backend-Dienst noch keine zugehörigen Backends hat und Sie die erste Weiterleitungsregel so konfigurieren, dass sie auf den Backend-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 Backend-Dienst noch nicht auf eine Weiterleitungsregel verweist und Sie das erste Instanzgruppen-Backend dem Backend-Dienst hinzufügen, legt Google Cloud das VPC-Netzwerk des Backend-Dienstes auf das VPC-Netzwerk fest, das dem ersten Instanzgruppen-Backend zugeordnet ist. Dies bedeutet, dass das mit dem Backend-Dienst verknüpfte VPC-Netzwerk das Netzwerk ist, das von der Netzwerkschnittstelle nic0 jeder VM im ersten Instanzgruppen-Backend verwendet wird.

• Wenn der Backend-Dienst noch keine Weiterleitungsregel hat, die darauf verweist, und Sie das erste zonale NEG-Backend (mit GCE_VM_IP-Endpunkten) zum Backend-Dienst hinzufügen, legt Google Cloud den Backend-Dienst für das VPC-Netzwerk fest, das diesem ersten NEG-Backend zugeordnet ist.

Nachdem das VPC-Netzwerk des Backend-Dienstes durch ein qualifizierendes Ereignis festgelegt wurde, müssen alle zusätzlichen Weiterleitungsregeln, Backend-Instanzgruppen oder von Ihnen hinzugefügten zonalen Backend-NEGs müssen den Netzwerkregeln für Backend-Dienste folgen.

Netzwerkregeln für Backend-Dienste

Die folgenden Regeln gelten, nachdem ein Backend-Dienst mit einem bestimmten VPC-Netzwerk verknüpft ist:

• Wenn Sie eine Weiterleitungsregel für den Verweis auf den Backend-Dienst konfigurieren, muss die Weiterleitungsregel ein Subnetz des VPC-Netzwerks des Backend-Dienstes verwenden. Weiterleitungsregeln und Backend-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, d. h. das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 jeder VM in der Instanzgruppe verwendet wird, muss mit dem verknüpften VPC-Netzwerk des Backend-Diensts übereinstimmen.
  • Jede Backend-VM muss eine Nicht-nic0-Schnittstelle (nic1 bis nic7) im VPC-Netzwerk haben, das dem Backend-Dienst zugeordnet ist.

• Wenn Sie zonale NEG-Backends mit GCE_VM_IP-Endpunkten hinzufügen, muss das mit der NEG verknüpfte VPC-Netzwerk mit dem VPC-Netzwerk übereinstimmen, das dem Backend-Dienst zugeordnet ist.

Backend-Teilmengeneinstellung

Die Backend-Teilmengeneinstellung ist eine optionale Funktion, die die Leistung verbessert, indem die Anzahl der Backends begrenzt wird, auf die der Traffic verteilt wird.

Sie sollten die Teilmengeneinstellung nur aktivieren, wenn Sie mehr als 250 Backend-VMs auf einem einzelnen Load-Balancer unterstützen müssen. Weitere Informationen finden Sie unter Backend-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 Backend-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 Backend-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 Backend-Dienst des Load-Balancers ausgewählten VPC-Netzwerk. Hiermit wird simuliert, wie Traffic mit Load-Balancing gesendet wird. Software, die auf Ihren Backend-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 Backend-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	Backend-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 Backend-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 Backend-VMs, wenn wenigstens eine Backend-VM fehlerfrei ist. Wenn alle Backend-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Backends. In diesem Fall leitet der Load-Balancer jede neue Verbindung an eine fehlerhafte Backend-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 Backend-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 Backend und Verbindungs-Tracking

Interne Passthrough-Netzwerk-Load-Balancer verwenden konfigurierbare Algorithmen zur Auswahl von Backend und Verbindungs-Tracking, um zu bestimmen, wie der Traffic an Backend-VMs verteilt wird. Interne Passthrough-Netzwerk-Load-Balancer verwenden den folgenden Algorithmus, um Pakete an Backend-VMs zu verteilen (in seinem aktiven Pool, wenn Sie ein failover konfiguriert haben):

1. Wenn der Load-Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle hat, der den Eigenschaften eines eingehenden Pakets entspricht, wird das Paket an das Backend 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.

2. 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:

   1. Der Load-Balancer wählt ein Backend aus. Der Load-Balancer berechnet einen Hash anhand der konfigurierten Sitzungsaffinität. Anhand dieses Hashs wird ein Backend ausgewählt:

      • Wenn mindestens ein Backend fehlerfrei ist, wählt der Hash eines der fehlerfreien Backends 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 NONE verwendet einen 5-Tupel-Hash der Quell-IP-Adresse, des Quellports, der Ziel-IP-Adresse, des Zielports und des Protokolls im Paket.

      Die Backend-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.

   2. Der Load-Balancer fügt der Tabelle für das Verbindungs-Tracking einen Eintrag hinzu. Dieser Eintrag zeichnet das ausgewählte Backend für die Verbindung des Pakets auf, sodass alle zukünftigen Pakete von dieser Verbindung an dasselbe Backend 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_SESSION und die Sitzungsaffinität ist NONE, oder
      • Tracking-Modus ist PER_SESSION und die Sitzungsaffinität ist CLIENT_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.

Optionen der Sitzungsaffinität

Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Backend-VMs des Load-Balancers. Legen Sie die Sitzungsaffinität fest, wenn Ihre Backend-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 Backend-Dienst und nicht einzeln für jede Backend-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.

Hinweis: Bei internen UDP-Load-Balancern wird das Festlegen der Sitzungsaffinität in der gcloud CLI und in der API unterstützt. Derzeit können Sie die Sitzungsaffinität für UDP-Traffic nicht über die Google Cloud Console festlegen.

Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer für den nächsten Hop

Wenn Sie eine statische Route für die Verwendung eines internen Passthrough-Network Load Balancer mit nächstem Hop konfigurieren, verwendet der Load-Balancer die gleiche Backend-Auswahl und das Verbindungs-Tracking-Methode wie oben erläutert. Die Back-End-Auswahl erfolgt weiterhin über die Berechnung eines Hashs gemäß der konfigurierten Sitzungsaffinität. Mit Ausnahme der CLIENT_IP_NO_DESTINATION-Sitzungsaffinität hängt der Hash für die Backendauswahl teilweise von der Ziel-IP-Adresse des Pakets ab.

Wenn ein interner Passthrough-Network Load Balancer der nächste Hop einer statischen Route ist, ist die Ziel-IP-Adresse nicht auf die IP-Adresse der Weiterleitungsregel des Load Balancers beschränkt. Stattdessen kann die Ziel-IP-Adresse des Pakets eine beliebige IP-Adresse sein, die in den Zielbereich der statischen Route passt.

Wenn die Anzahl der konfigurierten und fehlerfreien Back-End-VMs konstant ist (d. h., wenn das Failover entweder nicht konfiguriert ist oder wenn das Failover konfiguriert ist, aber keine Failover- oder Failback-Ereignisse auftreten), verhält sich der Load Balancer so:

• Wenn es nur eine konfigurierte und fehlerfreie Back-End-VM gibt (im aktiven Pool, wenn das Failover konfiguriert ist), spielt es keine Rolle, welche Sitzungsaffinität Sie verwenden, da alle Hashes der einen Back-End-VM zugeordnet sind.

• Wenn es zwei oder mehr konfigurierte und fehlerfreie Back-End-VMs gibt (im aktiven Pool, wenn ein Failover konfiguriert ist), ist die Wahl der Sitzungsaffinität wichtig:

  • Wenn Sie dieselbe Backend-VM benötigen, um alle Pakete von einem Client zu verarbeiten, basierend auf der Quell-IP-Adresse des Pakets, unabhängig von den Ziel-IP-Adressen des Pakets, verwenden Sie die CLIENT_IP_NO_DESTINATION-Sitzungsaffinität. “ Je nach Traffic-Mustern erhalten einige Back-End-VMs möglicherweise mehr Pakete oder Verbindungen als andere Back-End-VMs.

  • Wenn Sie eine Option für die Sitzungsaffinität verwenden, die nicht CLIENT_IP_NO_DESTINATION ist, wählt der Load-Balancer eine Back-End-VM anhand von Informationen aus, die mindestens sowohl Die Quell-IP-Adresse sowie Die Ziel-IP-Adresse des Pakets enthalten. Pakete, die vom selben Client mit derselben Quell-IP-Adresse, aber unterschiedliche Ziel-IP-Adressen gesendet werden, können an verschiedene Backend-VMs weitergeleitet werden.

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 Einstellung CLIENT_IP_PROTO). Dadurch kann die Sitzungsaffinität aufgeteilt werden und neue Verbindungen für eine Sitzung können ein anderes Backend auswählen, wenn sich der Backend-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ät CLIENT_IP oder CLIENT_IP_PROTO ist, 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.

Backend-Auswahl		Verbindungs-Tracking-Modus
Einstellung für die Sitzungsaffinität	Hash-Methode für die Backend-Auswahl	PER_CONNECTION (Standard)	PER_SESSION
Standard: Keine Sitzungsaffinität NONE	5-Tupel-Hash	5-Tupel-Verbindungs-Tracking	5-Tupel-Verbindungs-Tracking
Client-IP, kein Ziel CLIENT_IP_NO_DESTINATION	1-Tupel-Hash	5-Tupel-Verbindungs-Tracking	1-Tupel-Verbindungs-Tracking
Client-IP 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 CLIENT_IP_PROTO	3-Tupel-Hash	5-Tupel-Verbindungs-Tracking	3-Tupel-Verbindungs-Tracking
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll CLIENT_IP_PORT_PROTO	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 Backends steuert, ob eine vorhandene Verbindung auf einem ausgewählten Backend bestehen bleibt, nachdem dieses Backend fehlerhaft wird (solange das Backend in der konfigurierten Backend-Instanzgruppe des Load-Balancers verbleibt).

Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Backend-VM aus der Instanzgruppe oder die Instanzgruppe aus dem Backend-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_PERSIST
• ALWAYS_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 NONE oder CLIENT_IP_PORT_PROTO ist. 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.

Note: When the load balancer moves a connection from an unhealthy backend, the load balancer creates a new tracking table entry. Der neue Eintrag ordnet die Verbindung basierend auf der konfigurierten Sitzungsaffinität einem anderen Backend zu. Der neue Eintrag bleibt wie jeder andere Eintrag gültig. Wenn das fehlerhafte Backend wieder fehlerfrei ist, führt dies nicht dazu, dass der Tabelleneintrag für das Verbindungs-Tracking entfernt wird (es sei denn, er löst ein Failback aus und der Verbindungsausgleich bei Failover und Failback wurde deaktiviert.

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 Backend-VM, werden neue Verbindungen an die fehlerfreien Backend-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 Backend-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 Backends weiterleiten müssen, verwenden Sie die folgenden Weiterleitungsregel und Backend-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=ALL festzulegen, oder verwenden Sie die API, um allPorts auf True einzustellen.

• Konfiguration des Backend-Diensts: Legen Sie die Sitzungsaffinität des Backend-Diensts auf CLIENT_IP (2-Tupel-Hash) oder CLIENT_IP_PROTO (3-Tupel-Hash) fest, sodass dasselbe Backend 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 Backend-Dienstes auf PER_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 Backends werden nur verwendet, wenn die Anzahl der fehlerfreien VMs in den primären Backend-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 Backend zu einem Backend-Dienst eines internen Passthrough-Netzwerk-Load-Balancers hinzufügen, ist standardmäßig das Backend ein primäres Backend. Sie können ein Backend als Failover-Backend festlegen, wenn Sie es dem Backend-Dienst des Load-Balancers hinzufügen oder den Backend-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

• Sie können die Google Cloud Console nicht verwenden, um einen internen Passthrough-Network Load Balancer mit zonalen NEG-Backends zu erstellen.

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.