Trafficverteilung für regionale externe Network Load Balancer mit Passthrough-Funktion

Passthrough-Network Load Balancer verteilen eingehenden Traffic auf verfügbare Backend-Instanzen. In diesem Dokument wird erläutert, wie der Load-Balancer Back-Ends auswählt, Verbindungen verfolgt und Sitzungsaffinität, gewichtetes Load-Balancing und Failover verwaltet.

Wenn Sie wissen, wie alle diese Funktionen zusammenarbeiten, können Sie Ihre Load-Balancing-Konfiguration für eine zuverlässige Leistung und eine effiziente Ressourcennutzung optimieren. Diese Mechanismen sind entscheidend für Anwendungen, die eine Sitzungspersistenz erfordern, da sie ein konsistentes Verhalten bei jeder Nutzerinteraktion ermöglichen.

Auswahl von Backend und Verbindungs-Tracking

Die Auswahl von Backend und Verbindungs-Tracking arbeiten zusammen, um mehrere Verbindungen über verschiedene Backends hinweg auszugleichen und alle Pakete für jede Verbindung an dasselbe Backend weiterzuleiten. Dies wird mit einer zweiteiligen Strategie erreicht. Zuerst wird ein Backend mithilfe einer konsistenten Hashfunktion ausgewählt. Anschließend wird diese Auswahl in einer Verbindungstracking-Tabelle aufgezeichnet.

In den folgenden Schritten werden die Auswahl des Backends und das Verbindungs-Tracking beschrieben.

1 Eintrag in der Verbindungstracking-Tabelle prüfen

Der Load-Balancer ermittelt anhand des folgenden Verfahrens, ob ein per Load-Balancing verteiltes Paket zu einer neuen oder zu einer bestehenden Verbindung gehört:

• TCP-Paket mit dem Flag SYN:

  • Wenn der Verbindungsverfolgungsmodus des Load Balancers PER_CONNECTION ist, fahren Sie mit dem Schritt Zulässige Backends identifizieren fort. Im PER_CONNECTION-Tracking-Modus stellt ein TCP-Paket mit dem SYN-Flag immer eine neue Verbindung dar, unabhängig von der konfigurierten Sitzungsaffinität.

  • Wenn der Verbindungs-Tracking-Modus des Load Balancers PER_SESSION und die Sitzungsaffinität entweder NONE oder CLIENT_IP_PORT_PROTO ist, fahren Sie mit dem Schritt Zulässige Backends identifizieren fort. Im Tracking-Modus PER_SESSION stellt ein TCP-Paket mit dem Flag SYN nur dann eine neue Verbindung dar, wenn eine der 5-Tupel-Sitzungsaffinitätsoptionen (NONE oder CLIENT_IP_PORT_PROTO) verwendet wird.

• Verbindungs-Tracking nicht unterstützt: Wenn die Kombination aus Protokoll und Sitzungsaffinität kein Verbindungs-Tracking unterstützt, fahren Sie mit dem Schritt Geeignete Backends identifizieren fort. Informationen dazu, welche Protokolle für die Verbindungsverfolgung infrage kommen, finden Sie in der Tabelle im Abschnitt Modus für die Verbindungsverfolgung.

• Alle anderen Pakete: Der Load-Balancer prüft, ob das Paket mit einem vorhandenen Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt. Die Granularität des Paket-Hashs, der zum Prüfen auf einen vorhandenen Eintrag in der Tabelle zum Verbindungs-Tracking verwendet wird, hängt vom Verbindungs-Tracking-Modus und der Sitzungsaffinität ab, die Sie konfiguriert haben. Weitere Informationen finden Sie in der Tabelle im Abschnitt Modus für die Verbindungsüberwachung.

  • Wenn das Paket mit einem Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt, sendet der Load Balancer das Paket an das zuvor ausgewählte Backend.

  • Wenn das Paket nicht mit einem Eintrag in der Tabelle zum Nachverfolgen der Verbindung übereinstimmt, fahren Sie mit dem Schritt Geeignete Back-Ends ermitteln fort.

  Informationen dazu, wie lange ein Eintrag in der Verbindungstrackingtabelle erhalten bleibt und unter welchen Bedingungen, finden Sie im Schritt Einträge in der Verbindungstrackingtabelle verwalten.

2. Schritte zur Backend-Auswahl

Bei einer neuen Verbindung verwendet der Load Balancer konsistentes Hashing, um ein Backend aus den infrage kommenden Backends auszuwählen.

In den folgenden Schritten wird beschrieben, wie Sie ein geeignetes Backend für eine neue Verbindung auswählen und diese Verbindung dann in einer Verbindungstracking-Tabelle erfassen.

2.1 Geeignete Backends identifizieren

Zulässige Backends sind die Backends, die neue Verbindungen empfangen können. In der folgenden Tabelle wird die Gruppe der infrage kommenden Back-Ends definiert, je nachdem, ob der Load-Balancer Failover verwendet und ob gewichtigtes Load Balancing aktiviert ist.

Failover	Gewichtetes Load Balancing	Infrage kommende Backends
		Wenn sowohl das Failover als auch das gewichtete Load Balancing deaktiviert sind, sind alle konfigurierten Backends primäre Backends. Die zulässigen Back-Ends sind so definiert: Wenn mindestens ein Backend fehlerfrei ist, besteht die Gruppe der infrage kommenden Backends aus allen fehlerfreien Backends. Wenn alle Back-Ends fehlerhaft sind, besteht die Gruppe der infrage kommenden Back-Ends aus allen Back-Ends.
		Wenn das Failover-Load-Balancing-Feature deaktiviert und das gewichtete Load-Balancing-Feature aktiviert ist, sind die infrage kommenden Backends diejenigen, die aus dem ersten der folgenden Sets stammen, das nicht leer ist: Alle fehlerfreien Back-Ends mit Gewicht ungleich null Alle fehlerhaften Back-Ends mit Gewicht ungleich null Alle fehlerfreien Back-Ends mit Gewichtung 0 Alle fehlerhaften Back-Ends mit dem Gewicht 0
		Wenn die Funktion für das Failover-Load-Balancing aktiviert und die Funktion für das gewichtete Load-Balancing deaktiviert ist, verwendet der Load Balancer Informationen zur Systemdiagnose und die Konfiguration der Failover-Richtlinie, um die zulässigen Backends zu definieren: Wenn mindestens ein Backend (primär oder Failover) fehlerfrei ist, sind die infrage kommenden Backends diejenigen, die aus der ersten der folgenden nicht leeren Mengen stammen: Wenn es keine fehlerfreien primären Back-Ends gibt, sind die infrage kommenden Back-Ends alle fehlerfreien Failover-Back-Ends. Wenn keine fehlerfreien Failover-Backends vorhanden sind, sind die infrage kommenden Backends alle fehlerfreien primären Backends. Wenn das Failover-Verhältnis auf 0.0 (Standardwert) festgelegt ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends. Wenn das Verhältnis der Anzahl der fehlerfreien primären Backends zur Gesamtzahl der primären Backends größer oder gleich der konfigurierten Failover-Quote ist, bestehen die infrage kommenden Backends aus allen fehlerfreien primären Backends. Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends. Wenn keine fehlerfreien (primären und Failover-)Backends vorhanden sind, hängt die Menge der infrage kommenden Backends ausschließlich von der Konfiguration der Failover-Richtlinie ab: Wenn die Failover-Richtlinie so konfiguriert ist, dass neue Verbindungen verworfen werden, wenn alle primären und Failover-Backends fehlerhaft sind, ist die Gruppe der infrage kommenden Backends leer. Folglich verwirft der Load Balancer Pakete für neue Verbindungen. Wenn die Failover-Richtlinie nicht so konfiguriert ist, dass neue Verbindungen unterbrochen werden, wenn alle primären und Failover-Backends fehlerhaft sind, sind die infrage kommenden Backends alle fehlerhaften primären Backends.
		Wenn sowohl die Failover- als auch die gewichteten Load-Balancing-Funktionen aktiviert sind, verwendet der Load Balancer Gewichtungsinformationen, Systemdiagnoseinformationen und die Konfiguration der Failover-Richtlinie, um die Gruppe der infrage kommenden Backends zu definieren: Wenn mindestens ein Backend mit einem Gewicht ungleich null (primär oder Failover) fehlerfrei ist, sind die infrage kommenden Backends diejenigen, die aus der ersten der folgenden Mengen stammen, die nicht leer ist: Wenn die Gruppe der fehlerfreien primären Back-Ends mit einer Gewichtung ungleich null leer ist, sind die infrage kommenden Back-Ends alle fehlerfreien Failover-Back-Ends mit einer Gewichtung ungleich null. Wenn die Menge der fehlerfreien Failover-Back-Ends mit Gewichtung ungleich null leer ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit Gewichtung ungleich null. Wenn das Failover-Verhältnis auf 0.0 (Standardwert) festgelegt ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit einer Gewichtung ungleich null. Wenn das Verhältnis der Anzahl der fehlerfreien primären Back-Ends mit einer Gewichtung ungleich null zur Gesamtzahl der primären Back-Ends größer oder gleich der konfigurierten Failover-Quote ist, bestehen die infrage kommenden Back-Ends aus allen fehlerfreien primären Back-Ends mit einer Gewichtung ungleich null. Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends mit einer Gewichtung ungleich null. Wenn keine fehlerfreien Backends mit Gewichtung ungleich null (primär und Failover) vorhanden sind, hängt die Menge der infrage kommenden Backends von der Konfiguration der Failover-Richtlinie ab: Wenn die Failover-Richtlinie so konfiguriert ist, dass neue Verbindungen getrennt werden, wenn keine fehlerfreien primären und Failover-Backends mit einer Gewichtung ungleich null vorhanden sind, ist die Gruppe der infrage kommenden Backends leer. Folglich verwirft der Load Balancer Pakete für neue Verbindungen. Wenn die Failover-Richtlinie nicht so konfiguriert ist, dass neue Verbindungen verworfen werden, wenn keine fehlerfreien primären und Failover-Backends mit einer Gewichtung ungleich null vorhanden sind, sind die infrage kommenden Backends diejenigen, die aus der ersten der folgenden Gruppen stammen, die nicht leer ist: Alle fehlerhaften primären Back-Ends mit einem Gewicht ungleich null Alle fehlerhaften Failover-Back-Ends mit einer Gewichtung ungleich null Alle fehlerfreien primären Back-Ends mit Gewichtung 0 Alle fehlerfreien Failover-Backends mit Nullgewichtung Alle fehlerhaften primären Back-Ends mit Gewichtung null Alle fehlerhaften Failover-Backends mit Nullgewichtung

2.2 Zulässiges Backend auswählen

Der Load-Balancer verwaltet Hashes der infrage kommenden Backends. Jeder Backend-Hash wird einem Einheitskreis zugeordnet. Beim gewichteten Load-Balancing wird die Zuordnung infrage kommender Backends zum Kreis so geändert, dass Backends mit höheren Gewichten proportional zu ihren Gewichten mit größerer Wahrscheinlichkeit ausgewählt werden.

Wenn der Load-Balancer ein Paket für eine Verbindung verarbeitet, die nicht in der Tabelle für die Verbindungsverfolgung enthalten ist, berechnet er einen Hash der Paketeigenschaften und ordnet diesen Hash demselben Einheitskreis zu. Anschließend wählt er ein infrage kommendes Backend auf dem Umfang des Kreises aus. Die Paketmerkmale, die zur Berechnung des Pakethashs verwendet werden, werden durch die Einstellung für die Sitzungsaffinität definiert. Wenn die ausgewählte Sitzungsaffinität beispielsweise zu einem 2-Tupel- oder 3-Tupel-Hash für die Backend-Auswahl führt, werden alle TCP-Verbindungen von einer Quell-IP-Adresse demselben infrage kommenden Backend zugeordnet.

• Wenn keine Sitzungsaffinität explizit konfiguriert ist, wird standardmäßig die Sitzungsaffinität NONE verwendet.

• Die konsistente Hashfunktion sorgt dafür, dass der Load Balancer neue Verbindungen so zuweist, dass Zuordnungsunterbrechungen minimiert werden, auch wenn sich die Anzahl der infrage kommenden Backends oder deren Gewichtung ändert.

  • Der Load Balancer wählt in den folgenden Situationen immer dasselbe zulässige Backend für eine Verbindung aus und wählt im Allgemeinen immer dasselbe zulässige Backend für alle Pakete mit identischen Paketmerkmalen aus, wie in der Einstellung für die Sitzungsaffinität definiert:

    • Wenn kein gewichtetes Load Balancing konfiguriert ist und sich die Gruppe der infrage kommenden Back-Ends nicht ändert.

    • Wenn das gewichtete Load Balancing konfiguriert ist, und sich die Menge der infrage kommenden Back-Ends nicht ändert und das Gewicht jedes infrage kommenden Back-Ends konstant bleibt.

  • Wenn ein geeignetes Backend hinzugefügt, entfernt oder seine Gewichtung geändert wird, wird durch konsistentes Hashing die Unterbrechung von Zuordnungen zu den anderen geeigneten Backends minimiert. Das bedeutet, dass die meisten Verbindungen, die anderen geeigneten Backends zugeordnet sind, weiterhin demselben geeigneten Backend zugeordnet sind.

• Außerdem sorgt die konsistente Hashfunktion dafür, dass der Load Balancer neue Verbindungen so gleichmäßig wie möglich auf die infrage kommenden Backends verteilt. Für alle möglichen Pakethashes, die durch die konfigurierte Einstellung für die Sitzungsaffinität definiert sind (und insbesondere für alle möglichen Verbindungen, wenn die Sitzungsaffinität zu einem 5-Tupel-Hash für die Backend-Auswahl führt):

  • Wenn kein gewichtetes Load Balancing konfiguriert ist, werden jedem infrage kommenden Backend ungefähr 1/N mögliche Pakethashes zugeordnet, wobei N die Anzahl der infrage kommenden Backends ist.

  • Wenn gewichtetes Load Balancing konfiguriert ist, ist das Verhältnis der möglichen Paket-Hashes, die jedem infrage kommenden Backend zugeordnet werden, ungefähr gleich dem Gewicht eines infrage kommenden Backends geteilt durch die Summe aller infrage kommenden Backend-Gewichtungen.

• Die folgenden beiden Beispiele zeigen, wie sich das gewichtete Load Balancing auf die Auswahlwahrscheinlichkeiten der einzelnen infrage kommenden Backends auswirkt:

  • Wenn der Backend-Dienst zwei infrage kommende Backends hat, wobei das erste die Gewichtung 1 und das zweite die Gewichtung 4 hat, hat das erste infrage kommende Backend eine Auswahlwahrscheinlichkeit von 20% (1÷(1+4)) und das zweite infrage kommende Backend eine Auswahlwahrscheinlichkeit von 80% (4÷(1+4)).

  • Wenn der Backend-Dienst drei zulässige Backends hat – zulässiges Backend a mit Gewichtung 0, zulässiges Backend b mit Gewichtung 2 und zulässiges Backend c mit Gewichtung 6 – hat Backend a eine Auswahlwahrscheinlichkeit von 0 % (0÷(0+2+6)), Backend b eine Auswahlwahrscheinlichkeit von 25 % (2÷(0+2+6)) und Backend c eine Auswahlwahrscheinlichkeit von 75 % (6÷(0+2+6)).

2.3 Eintrag in der Verbindungstracking-Tabelle erstellen

Nachdem ein Backend ausgewählt wurde, erstellt der Load-Balancer einen Eintrag in der Tabelle für die Verbindungsverfolgung, wenn die konfigurierte Sitzungsaffinität die Verbindungsverfolgung für das Protokoll des Pakets unterstützt.

• Wenn die Kombination aus Protokoll und Sitzungsaffinität die Verbindungsverfolgung nicht unterstützt, überspringen Sie diesen Schritt.

• Wenn die konfigurierte Sitzungsaffinität das Verbindungs-Tracking für das Protokoll des Pakets unterstützt, ordnet der erstellte Eintrag in der Verbindungs-Tracking-Tabelle die Paketmerkmale dem ausgewählten Backend zu. Die für diese Zuordnung verwendeten Paketheaderfelder hängen vom Verbindungs-Tracking-Modus und der Sitzungsaffinität ab, die Sie konfiguriert haben.

Informationen dazu, welche Protokolle basierend auf Ihren Konfigurationsoptionen für das Verbindungs-Tracking geeignet sind und welche Paketmerkmale für den Hash in der Verbindungs-Tracking-Tabelle verwendet werden, finden Sie in der Tabelle im Abschnitt Verbindungs-Tracking-Modus.

3 Einträge in der Verbindungstracking-Tabelle verwalten

Der Load Balancer verwaltet die Einträge in der Verbindungs-Tracking-Tabelle, wenn die Kombination aus Protokoll und Sitzungsaffinität das Verbindungs-Tracking unterstützt, gemäß den folgenden Ereignissen und Regeln:

• Inaktive Einträge werden entfernt: Ein Eintrag in der Tabelle für das Verbindungs-Tracking wird nach 60 Sekunden entfernt, wenn keine neuen eingehenden Pakete von einem Maglev verarbeitet werden. Weitere Informationen finden Sie unter Zeitüberschreitung bei Inaktivität.

• Geschlossene TCP-Verbindungen: Einträge in der Tabelle zum Nachverfolgen von Verbindungen für TCP-Verbindungen werden nicht entfernt, wenn eine TCP-Verbindung mit einem FIN- oder RST-Paket geschlossen wird. Sie werden möglicherweise später als inaktiver Eintrag entfernt. Jede neue TCP-Verbindung enthält immer das SYN-Flag und unterliegt der Verarbeitung, die im Schritt Eintrag in der Verbindungstrackingtabelle prüfen beschrieben wird.

• Wenn Verbindungen beim Failover nicht beibehalten werden: Wenn mindestens ein Failover-Backend konfiguriert ist und die Einstellung für den Verbindungsausgleich beim Failover deaktiviert ist, entfernt der Load Balancer alle Einträge in der Tabelle für das Verbindungs-Tracking, nachdem die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt. Dabei gelten die folgenden Regeln:

  • Der Load Balancer entfernt nicht proaktiv Einträge aus der Verbindungstrackingtabelle, wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt. Stattdessen entfernt der Load Balancer jeden Eintrag in der Verbindungs-Tracking-Tabelle, wenn ein nächstes Paket für die Verbindung eintrifft, vorausgesetzt, dass die Gruppe der infrage kommenden Backends nicht zurückgewechselt wurde.

  • Wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends und zurück wechselt (z. B. von primär zu Failover und dann zurück zu primär) und zwischen den Wechselereignissen keine Pakete für die Verbindung eingegangen sind, wird der Tabelleneintrag für das Verbindungs-Tracking beibehalten, es sei denn, ein anderer Grund oder ein anderes Ereignis entfernt den Tabelleneintrag für das Verbindungs-Tracking.

  Weitere Informationen finden Sie unter Verbindungsausgleich bei Failover.

• Wenn Verbindungen auf fehlerhaften Backends nicht bestehen bleiben: Wenn die Verbindungspersistenz auf fehlerhaften Backends für das Protokoll des Pakets deaktiviert ist, entfernt der Load Balancer Verbindungs-Tracking-Tabelleneinträge auf fehlerhaften Backends gemäß den folgenden Regeln:

  • Der Load-Balancer entfernt Verbindungs-Tracking-Tabelleneinträge zu einem zuvor ausgewählten Back-End nicht proaktiv, wenn das Back-End fehlerhaft wird. Stattdessen entfernt der Load-Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle, wenn das nächste Paket für die Verbindung eintrifft, vorausgesetzt, dass das zuvor ausgewählte Back-End weiterhin fehlerhaft ist. Nachfolgende Pakete für die Verbindung werden als neue Verbindung behandelt, da der Load Balancer ein neues geeignetes Backend auswählt und einen neuen Eintrag in der Verbindungs-Tracking-Tabelle erstellt.

  • Wenn sich der Zustand eines zuvor ausgewählten Backends von fehlerfrei zu fehlerhaft und dann wieder zu fehlerfrei ändert und keine Pakete für die Verbindung eingegangen sind, während das zuvor ausgewählte Backend fehlerhaft war, wird der Tabelleneintrag für das Verbindungs-Tracking beibehalten, es sei denn, der Tabelleneintrag für das Verbindungs-Tracking wird aus einem anderen Grund oder Ereignis entfernt.

• Verbindungsausgleich für entfernte, beendete oder gelöschte Backends: Wenn der Verbindungsausgleich für entfernte, beendete oder gelöschte Backends aktiviert ist, werden Einträge in der Verbindungstracking-Tabelle nach einem konfigurierbaren Zeitlimit für den Verbindungsausgleich entfernt. Die Zeit bis zum Zeitlimit wird ab dem Zeitpunkt gezählt, an dem der Befehl zum Entfernen (Verwerfen), Beenden oder Löschen eines Back-Ends empfangen wird (einschließlich Löschbefehlen, die sich aus dem Herunterskalieren einer verwalteten Instanzgruppe ergeben). Wenn der Verbindungsausgleich für entfernte, beendete oder gelöschte Back-Ends deaktiviert ist, werden Einträge in der Verbindungstracking-Tabelle entfernt, wenn der Befehl zum Entfernen, Beenden oder Löschen eines Back-Ends empfangen wird. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.

Sitzungsaffinität

Die Einstellung für die Sitzungsaffinität eines regionalen externen Passthrough-Network-Load-Balancers definiert den Paket-Hash für die Backend-Auswahl und, basierend auf dem Verbindungs-Tracking-Modus, den Paket-Hash für das Verbindungs-Tracking.

Sie konfigurieren die Sitzungsaffinität für den Backend-Dienst und nicht für jede Backend-Instanzgruppe oder NEG. Die Sitzungsaffinität bestimmt, welche IP- und Layer 4-Header verwendet werden, um einen Hash der Paketmerkmale zu berechnen. Der Hash der Paketmerkmale wird in den Schritten zur Backend-Auswahl verwendet.

Regionale externe Passthrough-Network Load Balancer unterstützen die folgenden Einstellungen für die Sitzungsaffinität.

Hash-Methode für die Backend-Auswahl	Einstellung für die Sitzungsaffinität
5-Tupel-Hash (bestehend aus Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport) für nicht fragmentierte Pakete, die Portinformationen enthalten (TCP-Pakete und nicht fragmentierte UDP-Pakete) OR 3-Tupel-Hash (besteht aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll) für fragmentierte UDP-Pakete und Pakete aller anderen Protokolle	NONE1 ODER CLIENT_IP_PORT_PROTO
3-Tupel-Hash (besteht aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll)	CLIENT_IP_PROTO
2-Tupel-Hash (besteht aus Quell-IP-Adresse und Ziel-IP-Adresse)	CLIENT_IP

Tracking-Richtlinie für Verbindungen

In diesem Abschnitt werden die Einstellungen in der Richtlinie für das Verbindungs-Tracking des Load Balancers beschrieben:

• Verbindungs-Tracking-Modus
• Verbindungspersistenz auf fehlerhaften Back-Ends
• Zeitüberschreitung bei Inaktivität

Verbindungs-Tracking-Modus

In diesem Abschnitt wird beschrieben, wann und wie der Load Balancer Einträge in seiner Tabelle für das Verbindungs-Tracking erstellt. Regionale externe Passthrough-Network Load Balancer unterstützen das Verbindungstracking basierend auf Protokoll und Sitzungsaffinität:

• TCP-Verbindungen können immer nachverfolgt werden, unabhängig von der Sitzungsaffinitätsoption.

• UDP-, ESP- und GRE-Verbindungen können für alle Sitzungsaffinitätsoptionen außer NONE verfolgt werden. Bei der NONE-Sitzungsaffinität können diese Protokolle nicht nachverfolgt werden.

• Alle anderen Protokolle wie ICMP und ICMPv6 können für alle Optionen für die Sitzungsaffinität nicht über die Verbindung nachverfolgt werden.

Wenn das Verbindungs-Tracking möglich ist, bestimmen der Modus für das Verbindungs-Tracking, das Protokoll und die Sitzungsaffinität die Menge der Paketmerkmale, die zum Erstellen des Paket-Hashs in jedem Eintrag der Verbindungs-Tracking-Tabelle verwendet werden.

Der Verbindungs-Tracking-Modus kann einer der folgenden sein:

• PER_CONNECTION: Dies ist der Standardmodus für das Verbindungs-Tracking und bietet die höchste Detailgenauigkeit. Jede Verbindung wird entweder als 5‑Tupel-Hash oder als 3‑Tupel-Hash der Paketmerkmale definiert, je nachdem, ob Portinformationen im Paket vorhanden sind. Nicht fragmentierte Pakete, die Portinformationen enthalten (z. B. TCP-Pakete und nicht fragmentierte UDP-Pakete), werden mit 5-Tupel-Hashes verfolgt. Alle anderen Pakete werden mit 3-Tupel-Hashes verfolgt.

• PER_SESSION: Bei diesem weniger detaillierten Modus für das Verbindungs-Tracking wird ein Hash verwendet, der mit dem Hash für die Sitzungsaffinität übereinstimmt. Je nach ausgewählter Sitzungsaffinität können im PER_SESSION-Tracking-Modus mehrere unterschiedliche Verbindungen für das Verbindungs-Tracking als eine einzelne Verbindung behandelt werden. Dadurch wird die Häufigkeit reduziert, mit der eine Verbindung als neu betrachtet wird und den Schritten zur Backend-Auswahl unterliegt.

In der folgenden Tabelle finden Sie eine Zusammenfassung:

• Die für die Backend-Auswahl verwendeten Pakethashes und
• Die für das Verbindungs-Tracking verwendeten Pakethashes, basierend auf dem Verbindungs-Tracking-Modus, dem Protokoll und der Sitzungsaffinität.

Sitzungsaffinität	Paket-Hash für die Backend-Auswahl	Paket-Hash für Verbindungs-Tracking
		Bei Verwendung des Tracking-Modus PER_CONNECTION (Standard)	Bei Verwendung des Tracking-Modus „PER_SESSION“
NONE (Standard)	TCP und nicht fragmentiertes UDP: 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: 3-Tupel-Hash	TCP:Verbindungs-Tracking aktiviert, 5-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert	TCP:Verbindungs-Tracking aktiviert, 5-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
CLIENT_IP_PORT_PROTO	TCP und nicht fragmentiertes UDP: 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: 3-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentierte UDP-, ESP- und GRE-Anfragen: Verbindungs-Tracking aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentierte UDP-, ESP- und GRE-Anfragen: Verbindungs-Tracking aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
CLIENT_IP_PROTO	Alle Protokolle: 3-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentierte UDP-, ESP- und GRE-Anfragen: Verbindungs-Tracking aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert	TCP, UDP, ESP, GRE:Verbindungs-Tracking aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
CLIENT_IP	Alle Protokolle: 2-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentierte UDP-, ESP- und GRE-Anfragen: Verbindungs-Tracking aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert	TCP, UDP, ESP, GRE:Verbindungs-Tracking aktiviert, 2-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert

Informationen zum Ändern des Verbindungs-Tracking-Modus finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.

Verbindungspersistenz auf fehlerhaften Back-Ends

Mit Verbindungspersistenz bei fehlerhaften Back-Ends wird gesteuert, ob vorhandene Verbindungen auf einer zuvor ausgewählten Back-End-VM bestehen bleiben können, wenn die zuvor ausgewählte VM fehlerhaft wird. Die Verbindungspersistenz bei fehlerhaften Back-Ends erfordert, dass die Backend-VM Mitglied einer Load-Balancing-Instanzgruppe oder NEG bleibt und dass die Kombination aus Protokoll und Sitzungsaffinität das Verbindungs-Tracking unterstützt.

Die folgenden Optionen für die Verbindungspersistenz sind verfügbar:

• DEFAULT_FOR_PROTOCOL (Standard)
• NEVER_PERSIST
• ALWAYS_PERSIST

In der folgenden Tabelle wird das Verhalten der Verbindungspersistenz auf fehlerhaften Back-Ends in Abhängigkeit von der Option für die Verbindungspersistenz auf fehlerhaften Back-Ends, dem Verbindungs-Tracking-Modus, der Sitzungsaffinität und dem Protokoll beschrieben.

Option zur Verbindungspersistenz bei fehlerhaften Back-Ends	Verhalten der Verbindungspersistenz auf fehlerhaften Back-Ends
	Bei Verwendung des PER_CONNECTION-Tracking-Modus (Standard)	Bei Verwendung des Tracking-Modus „PER_SESSION“
DEFAULT_FOR_PROTOCOL	TCP (alle Sitzungsaffinitäten): Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, vorbehaltlich der anderen Ereignisse und Regeln im Schritt Einträge in der Tabelle für das Verbindungs-Tracking verwalten. Alle anderen Protokolle: Verbindungen bleiben auf fehlerhaften Back-Ends nicht bestehen.	TCP (Sitzungsaffinitäten NONE und CLIENT_IP_PORT_PROTO): Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, vorbehaltlich der anderen Ereignisse und Regeln im Schritt Einträge in der Verbindungstracking-Tabelle verwalten. TCP (alle anderen Sitzungsaffinitäten) und alle anderen Protokolle: Verbindungen bleiben auf fehlerhaften Back-Ends nicht bestehen.
NEVER_PERSIST	Alle Protokolle:Verbindungen bleiben nicht auf fehlerhaften Back-Ends bestehen.
ALWAYS_PERSIST Diese Option sollte nur für erweiterte Anwendungsfälle verwendet werden.	TCP (alle Sitzungsaffinitäten); ESP, GRE, UDP (alle Sitzungsaffinitäten außer NONE): Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, vorbehaltlich der anderen Ereignisse und Regeln im Schritt Einträge in der Verbindungs-Tracking-Tabelle verwalten. ESP, GRE, UDP (NONE-Sitzungsaffinität): nicht zutreffend, da sie nicht über Verbindungs-Tracking erfasst werden können.	Konfiguration nicht möglich

Informationen zum Ändern des Verhaltens der Verbindungspersistenz finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.

Verhalten der TCP-Verbindungspersistenz auf fehlerhaften Back-Ends

Der Load Balancer verwendet in den folgenden Situationen das 5-Tupel-Hash-Verbindungs-Tracking für TCP-Verbindungen:

• Wenn Sie den Tracking-Modus PER_CONNECTION (alle Sitzungsaffinitäten) verwenden oder
• Wenn Sie den Tracking-Modus PER_SESSION verwenden und die Sitzungsaffinität entweder NONE oder CLIENT_IP_PORT_PROTO ist.

Wenn der Load Balancer ein 5-Tupel-Hash-Verbindungs-Tracking für TCP-Verbindungen verwendet, beachten Sie die folgenden Verhaltensweisen:

• Wenn das fehlerhafte Backend weiterhin auf Pakete antwortet, wird die Verbindung so lange fortgesetzt, bis sie zurückgesetzt oder geschlossen wird (entweder durch das fehlerhafte Backend oder den Client).
• Wenn das fehlerhafte Backend ein TCP-Rücksetzpaket (RST) sendet oder nicht auf Pakete antwortet, kann der Client es mit einer neuen Verbindung versuchen. Der Load Balancer kann dann ein anderes, geeignetes Backend auswählen. (TCP-SYN-Pakete werden im Schritt Zulässige Back-Ends identifizieren als neue Verbindungen behandelt.)

Zeitüberschreitung bei Inaktivität

Einträge in Verbindungs-Tracking-Tabellen laufen 60 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmt. Der Wert für dieses Zeitlimit kann nicht geändert werden.

Verbindungsausgleich für entfernte, beendete oder gelöschte Back-Ends

Der Verbindungsausgleich bietet eine konfigurierbare Mindestzeit, für die bestehende Verbindungen in der Verbindungstracking-Tabelle des Load Balancers beibehalten werden, wenn einer der folgenden Fälle eintritt:

• Eine VM-Instanz wird aus einer Backend-Instanzgruppe entfernt (einschließlich des Verwerfens einer Instanz in einer verwalteten Backend-Instanzgruppe).
• Eine VM wird beendet oder gelöscht. Dazu gehören auch automatische Aktionen wie Rolling Updates oder das Herunterskalieren einer verwalteten Back-End-Instanzgruppe.
• Ein Endpunkt wird aus einer Backend-Netzwerk-Endpunktgruppe (NEG) entfernt.

Standardmäßig ist der Verbindungsausgleich deaktiviert, wenn Back-Ends entfernt, beendet oder gelöscht werden. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.

Gewichtetes Load Balancing

Das gewichtete Load Balancing beeinflusst, welche Backends in den Schritten zur Backend-Auswahl infrage kommen. Jede Backend-VM oder jeder Endpunkt meldet ihr bzw. sein Gewicht mithilfe einer HTTP-Systemdiagnose und eines benutzerdefinierten Antwortheaders an den Load Balancer. Wenn Sie gewichtetes Load Balancing verwenden möchten, müssen Sie im Backend-Dienst des Load Balancers Folgendes konfigurieren:

• Die Ort-Richtlinie (localityLbPolicy) muss auf WEIGHTED_MAGLEV festgelegt sein.

• Die Systemdiagnose muss eine HTTP-Systemdiagnose sein, die einen speziellen Antwortheader sendet:

  • Der Feldname des Antwortheaders muss X-Load-Balancing-Endpoint-Weight sein.
  • Die Feldwerte des Antwortheaders können zwischen 0 und 1000 liegen (einschließlich).

Weitere Informationen finden Sie unter Gewichtetes Load Balancing konfigurieren.

Überlegungen zum gewichteten Load Balancing

Das gewichtete Load Balancing ist in den folgenden Szenarien nützlich, in denen ein Backend seine vorhandenen Verbindungen weiter verarbeiten kann:

• Mit gewichtetem Load Balancing kann ein Backend, das langlebige Verbindungen oder Verbindungen mit großen Datenmengen verarbeitet, den Load Balancer anweisen, die Anzahl der neuen Verbindungen zu reduzieren, die es empfängt.

• Mit gewichtetem Load Balancing kann sich ein Backend, das überlastet ist oder gewartet wird, selbst aus der Liste der zulässigen Backends für neue Verbindungen entfernen. Dazu sendet das überlastete Backend den Antwortheader X-Load-Balancing-Endpoint-Weight: 0 und kann die Load-Balancer-Systemdiagnose entweder weiterhin bestehen oder nicht bestehen. Dies funktioniert, weil alle Backends mit einer Gewichtung ungleich null (unabhängig vom Status der Systemdiagnose) im Schritt Zulässige Backends identifizieren bevorzugte zulässige Backends sind.

Beachten Sie beim Load Balancing Folgendes:

• Wenn infrage kommende Backends ihre Gewichtungen häufig ändern, kann sich das gewichtete Load Balancing nachteilig auf die Sitzungsaffinität auswirken. Weitere Informationen finden Sie im Schritt Zulässiges Backend auswählen.

• Wenn Sie dieselbe Instanzgruppe oder NEG als Backend von zwei oder mehr Load-Balancer-Backend-Diensten verwenden, können Sie mit der folgenden Strategie für jeden Backend-Dienst eine eindeutige Gewichtung melden:

  • Verwenden Sie für jeden Backend-Dienst eine eindeutige HTTP-Systemdiagnose. Jede Systemdiagnose kann einen eindeutigen Zielport oder request-path-Parameter verwenden.

  • Konfigurieren Sie Backend-Instanzen oder -Endpunkte so, dass sie für jede Systemdiagnose mit den entsprechenden Gewichtungsinformationen antworten.

Failover

Mit der Failover-Funktion können Sie die Gruppe der infrage kommenden Backends beeinflussen, indem Sie Backend-Instanzgruppen oder NEGs und ihre Endpunkte so klassifizieren:

• Primäre Backends sind VMs oder Endpunkte in einer Instanzgruppe oder NEG, die als primäre Backend-Gruppe konfiguriert ist.
• Failover-Backends sind VMs oder Endpunkte in einer Instanzgruppe oder NEG, die als Failover-Backend-Gruppe konfiguriert ist.

Wenn Sie einem Backend-Dienst eine Instanzgruppe oder ein NEG hinzufügen, ist die Instanzgruppe oder das NEG standardmäßig eine primäre Backend-Gruppe. Sie können einem Backend-Dienst bis zu 50 primäre Backend-Gruppen und 50 Failover-Backend-Gruppen hinzufügen.

Wenn Sie die Failover-Funktion aktivieren möchten, müssen Sie den Backend-Dienst des Load Balancers mit den folgenden beiden Optionen konfigurieren:

• Mindestens eine nicht leere primäre Backend-Gruppe
• Mindestens eine nicht leere Failover-Backend-Gruppe

Wenn Failover aktiviert ist, bestimmen die folgenden Faktoren die Gruppe der infrage kommenden Back-Ends:

• Der Systemstatus der einzelnen Backends
• Die Failover-Quote in der Failover-Richtlinie
• Die Einstellung Traffic löschen, wenn Backends fehlerhaft sind in der Failover-Richtlinie
• Ob Sie Failover allein oder in Verbindung mit gewichtetem Load-Balancing verwenden

Failover-Richtlinie

Sie können die folgenden Einstellungen in der Failover-Richtlinie eines Backend-Dienstes anpassen. Die Failover-Richtlinie ist nur relevant, wenn Failover aktiviert ist.

• Failover-Quote: eine Zahl zwischen 0.0 und 1.0 (einschließlich).
• Drop traffic if backends are unhealthy (Traffic löschen, wenn Backends fehlerhaft sind): Ein boolescher Wert, der das Verhalten des Load-Balancers als letztes Mittel bestimmt. Das Failover-Verhältnis und die Einstellung Traffic verwerfen, wenn Back-Ends fehlerhaft sind werden zusammen mit anderen Faktoren verwendet, um die Menge der infrage kommenden Back-Ends zu steuern.
• Verbindungsausgleich bei Failover: Ein boolescher Wert, der steuert, ob Verbindungen auf zuvor ausgewählten Backends bestehen bleiben, wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt.

Failover-Quote

Das Failover-Verhältnis bestimmt, wann die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt. Das Verhältnis kann eine Zahl zwischen 0.0 und 1.0 (einschließlich) sein. Wenn Sie kein Failover-Verhältnis angeben,verwendet Cloud de Confiance den Standardwert 0.0. Es empfiehlt sich, das Failover-Verhältnis auf einen Wert festzulegen, der für Ihren Anwendungsfall geeignet ist, anstatt sich auf diesen Standardwert zu verlassen.

Verbindungsausgleich bei Failover

Verbindungsausgleich bei Failover steuert, ob eine vorhandene Verbindung auf einer zuvor ausgewählten Backend-VM oder einem zuvor ausgewählten Endpunkt bestehen bleibt, wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt.

Der Verbindungsausgleich bei Failover ist standardmäßig aktiviert. In der folgenden Tabelle ist zusammengefasst, ob Verbindungen beibehalten werden, je nach Option für den Verbindungsausgleich bei Failover und Protokoll:

Option „Verbindungsausgleich bei Failover“	Verhalten, wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt
Aktiviert (Standardeinstellung)	Protokolle, die Verbindungen nachverfolgen können:Verbindungen bleiben bestehen, solange ein entsprechender Eintrag in der Verbindungs-Tracking-Tabelle vorhanden ist, wenn die Gruppe der infrage kommenden Back-Ends zwischen primären und Failover-Back-Ends wechselt. Weitere Informationen finden Sie im Schritt Einträge in der Tabelle zur Verbindungsüberwachung verwalten. Protokolle, die nicht für das Verbindungs-Tracking geeignet sind: Verbindungen bleiben nicht bestehen, wenn die Gruppe der infrage kommenden Back-Ends zwischen primären und Failover-Back-Ends wechselt. Informationen dazu, welche Protokolle für die Verbindungsnachverfolgung verwendet werden können, finden Sie in der Tabelle im Abschnitt Modus für die Verbindungsnachverfolgung.
Deaktiviert	Alle Protokolle: Verbindungen bleiben nicht bestehen, wenn die Gruppe der infrage kommenden Back-Ends zwischen primären und Failover-Back-Ends wechselt.

Das Deaktivieren des Verbindungsausgleichs bei Failover ist in den folgenden Szenarien nützlich:

• Back-End-VMs patchen Vor dem Patchen können Sie fehlerfreie primäre Back-Ends mit einer Gewichtung ungleich null so konfigurieren, dass Systemdiagnosen fehlschlagen, oder Sie können ihre Gewichtung auf null setzen. So können infrage kommende Backends Failover-Backends mit einem Gewicht ungleich null sein. Wenn Sie den Verbindungsausgleich bei Failover deaktivieren, entfernt der Load-Balancer Einträge aus der Verbindungs-Tracking-Tabelle, wendet die Schritte zur Backend-Auswahl auf nachfolgende Pakete an und leitet sie an ein anderes infrage kommendes Backend weiter. Das andere Backend schließt dann die Verbindung mit einem TCP-Reset, sodass Client-VMs schnell eine neue Verbindung zum Load Balancer herstellen können.

• Einzelne Back-End-VM für Datenkonsistenz. Wenn Sie sicherstellen müssen, dass die Gruppe der infrage kommenden Back-Ends nicht mehr als eine Mitglieds-VM oder einen Endpunkt enthält, wird durch das Deaktivieren des Verbindungsausgleichs bei Failover die Wahrscheinlichkeit von Dateninkonsistenzen verringert.

Informationen zum Deaktivieren des Verbindungsausgleichs bei Failover finden Sie unter Failover-Richtlinie definieren.

Best Practices und Anleitungen

Sie können einen regionalen externen Passthrough-Network-Load-Balancer optimieren, indem Sie diese Betriebsrichtlinien befolgen. In den folgenden Abschnitten finden Sie technische Anforderungen für die Verwaltung fragmentierter UDP-Pakete und Best Practices zum Testen der Lastverteilung von einem einzelnen Client.

Umgang mit UDP-Fragmentierung

Backend-Dienst-basierte regionale externe Passthrough-Network 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 Cloud de Confiance-VPC-Netzwerk erreichen.
• Cloud de Confiance VPC-Netzwerke leiten UDP-Fragmente direkt bei Eingang weiter (ohne auf alle Fragmente zu warten).
• Nicht-Cloud de Confiance -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:

• Konfiguration der Weiterleitungsregel: Verwenden Sie nur eine UDP- oder L3_DEFAULT-Weiterleitungsregel pro IP-Adresse mit Load-Balancing und konfigurieren Sie die Weiterleitungsregel, um Traffic auf allen Ports zuzulassen. 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.

Von einem einzelnen Client aus testen

Beim Testen eines regionalen externen Passthrough-Network Load Balancers von einem einzelnen Client aus sollten Sie Folgendes beachten:

• Wenn die Client-VM kein Backend des Load Balancers ist: Neue Verbindungen werden wie in den Schritten Auswahl von Backend und Verbindungs-Tracking beschrieben verarbeitet. Im Schritt Zulässiges Backend auswählen erstellt der Load Balancer einen Hash der Paketmerkmale gemäß der Sitzungsaffinität.

  Denken Sie daran, dass alle Optionen für die Sitzungsaffinität mindestens auf der IP-Adresse des Clients basieren. Verbindungen vom selben Client werden möglicherweise häufiger als erwartet an dasselbe infrage kommende Backend verteilt. Daher können Sie die Gesamtverteilung neuer Verbindungen nicht genau modellieren, indem Sie von einem einzelnen Client aus eine Verbindung zu einem regionalen externen Passthrough-Network Load Balancer herstellen.

• Wenn die Client-VM auch eine Backend-VM des Load Balancers ist, werden neue Verbindungen vom Load Balancer überhaupt nicht verarbeitet. Ausgehende Pakete mit der Ziel-IP-Adresse der Weiterleitungsregel des Load Balancers werden lokal im Gastbetriebssystem des Clients weitergeleitet, da eine lokale Route für die Weiterleitungsregel vorhanden ist.

Nächste Schritte

• Informationen zum Konfigurieren eines externen Passthrough-Netzwerk-Load-Balancers mit einem Backend-Dienst nur für TCP- oder UDP-Traffic (mit Unterstützung von IPv4- und IPv6-Traffic) finden Sie unter Externen Passthrough-Netzwerk-Load-Balancer mit einem Backend-Dienst einrichten.
• Informationen zum Konfigurieren eines externen Passthrough-Network Load Balancers für mehrere IP-Protokolle (mit Unterstützung von IPv4- und IPv6-Traffic) finden Sie unter Externen Passthrough-Network Load Balancer für mehrere IP-Protokolle einrichten.
• Informationen zum Konfigurieren eines externen Passthrough-Network-Load-Balancers mit einem zonalen NEG-Backend finden Sie unter Externen Passthrough-Network-Load-Balancer mit zonalen NEGs einrichten.
• Informationen zum Umstellen eines externen Passthrough-Netzwerk-Load-Balancers von einem Zielpool-Backend auf einen regionalen Backend-Dienst finden Sie unter Externen Passthrough-Netzwerk-Load-Balancer von einem Zielpool auf einen Backend-Dienst umstellen.