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 Backends 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 effiziente Ressourcennutzung optimieren. Diese Mechanismen sind entscheidend für Anwendungen, die Sitzungspersistenz erfordern, damit sie für jede Nutzerinteraktion ein konsistentes Verhalten beibehalten.

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 bestimmt anhand des folgenden Prozesses, ob ein Paket mit Load Balancing zu einer neuen oder einer vorhandenen 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 Tracking-Modus PER_CONNECTION stellt ein TCP-Paket mit dem Flag SYN 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 wird nicht unterstützt: Wenn die Kombination aus Protokoll und Sitzungsaffinität kein Verbindungs-Tracking unterstützt, fahren Sie mit dem Schritt Zulässige Back-Ends identifizieren fort. Informationen dazu, welche Protokolle für das Verbindungstracking geeignet sind, finden Sie in der Tabelle im Abschnitt Verbindungstracking-Modus.

• 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 Verbindungs-Tracking-Modus.

  • 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 Verbindungs-Tracking-Tabelle übereinstimmt, fahren Sie mit dem Schritt Zulässige Backends identifizieren fort.

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

2. Schritte zur Backend-Auswahl

Für eine neue 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 sind die zulässigen Back-Ends definiert, je nachdem, ob der Load Balancer Failover verwendet und ob gewichtetes 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 Backends mit einer Gewichtung ungleich null Alle fehlerhaften Backends mit einer Gewichtung ungleich null Alle fehlerfreien Back-Ends mit Nullgewichtung Alle fehlerhaften Back-Ends mit Nullgewichtung
		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 Gruppen stammen, die nicht leer ist: Wenn keine fehlerfreien primären Backends vorhanden sind, sind die infrage kommenden Backends alle fehlerfreien Failover-Backends. 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 Back-Ends (primäre und Failover-Back-Ends) vorhanden sind, hängt die Gruppe der infrage kommenden Back-Ends 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 verworfen 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 Gruppe der fehlerfreien Failover-Back-Ends mit einer Gewichtung ungleich null leer ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit einer 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 Back-Ends mit einer Gewichtung ungleich null (primäre und Failover-Back-Ends) vorhanden sind, hängt die Gruppe der infrage kommenden Back-Ends 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 einer Gewichtung 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 von infrage kommenden Backends, wobei jeder Backend-Hash einem Einheitskreis zugeordnet ist. Beim gewichteten Load Balancing wird die Zuordnung der infrage kommenden Backends zum Kreis so geändert, dass Backends mit höheren Gewichtungen proportional zu ihren Gewichtungen mit höherer Wahrscheinlichkeit ausgewählt werden.

Wenn ein Paket für eine Verbindung verarbeitet wird, die sich nicht in der Verbindungs-Tracking-Tabelle befindet, berechnet der Load Balancer einen Hash der Paketeigenschaften und ordnet diesen Hash demselben Einheitskreis zu. Dabei wird ein geeignetes Backend auf dem Kreisumfang ausgewählt. 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-Backend-Auswahl-Hash 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 Backends nicht ändert.

    • Wenn gewichtetes Load Balancing konfiguriert ist, sich die Gruppe der infrage kommenden Backends nicht ändert und die Gewichtung jedes infrage kommenden Backends 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, entspricht das Verhältnis der möglichen Pakethashes, die jedem infrage kommenden Backend zugeordnet werden, ungefähr dem Gewicht eines infrage kommenden Backends geteilt durch die Summe aller infrage kommenden Backend-Gewichte.

• 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 das Verbindungs-Tracking, wenn die konfigurierte Sitzungsaffinität das Verbindungs-Tracking für das Protokoll des Pakets unterstützt.

• Wenn die Kombination aus Protokoll und Sitzungsaffinität kein Verbindungs-Tracking 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 der Verbindung 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 Flag SYN und unterliegt der Verarbeitung, die im Schritt Eintrag in der Verbindungstracking-Tabelle 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 beim 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 Einträge in der Verbindungs-Tracking-Tabelle auf fehlerhaften Backends gemäß den folgenden Regeln:

  • Der Load-Balancer entfernt nicht proaktiv Verbindungs-Tracking-Tabelleneinträge zu einem zuvor ausgewählten Back-End, wenn das Back-End fehlerhaft wird. Stattdessen entfernt der Load Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle, wenn ein nächstes Paket für die Verbindung eintrifft, vorausgesetzt, dass das zuvor ausgewählte Backend fehlerhaft bleibt. 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 die 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 Backends deaktiviert ist, werden die Einträge in der Verbindungstracking-Tabelle entfernt, sobald der Befehl zum Entfernen, Beenden oder Löschen eines Backends 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, 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 (bestehend 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
• Verbindung auf fehlerhaften Backends beibehalten
• 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 sind für alle Sitzungsaffinitätsoptionen immer verfolgbar.

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

• Alle anderen Protokolle wie ICMP und ICMPv6 können für alle Sitzungsaffinitätsoptionen nicht über Verbindungs-Tracking erfasst werden.

Wenn Verbindungs-Tracking möglich ist, bestimmen der Verbindungs-Tracking-Modus, das Protokoll und die Sitzungsaffinität die Paketmerkmale, die für den Pakethash 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 der Modus mit der höchsten Granularität. Jede Verbindung wird entweder als 5-Tupel-Hash oder als 3-Tupel-Hash von Paketmerkmalen 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: Dieser weniger detaillierte Verbindungs-Tracking-Modus verwendet einen Hash, der mit dem Hash der Sitzungsaffinität übereinstimmt. Je nach ausgewählter Sitzungsaffinität kann der PER_SESSION-Tracking-Modus mehrere unterschiedliche Verbindungen für das Verbindungs-Tracking als eine einzige Verbindung behandeln. 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 das 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

Verbindungspersistenz auf fehlerhaften Back-Ends steuert, ob bestehende Verbindungen auf einer zuvor ausgewählten Back-End-VM bestehen bleiben können, wenn die zuvor ausgewählte VM fehlerhaft wird. Für die Verbindungspersistenz auf fehlerhaften Backends muss die Backend-VM Mitglied einer Instanzgruppe oder NEG mit Load Balancing bleiben und die Kombination aus Protokoll und Sitzungsaffinität muss das Verbindungs-Tracking unterstützen.

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 Tracking-Modus PER_CONNECTION (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 auf fehlerhaften Back-Ends nicht 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 Tabellen für das Verbindungs-Tracking 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, angehaltene oder gelöschte Backends

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 (dies umfasst automatische Aktionen wie Rolling Updates oder das Herunterskalieren einer verwalteten Back-End-Instanzgruppe).
• Ein Endpunkt wird aus einer Backend-Netzwerk-Endpunktgruppe (NEG) entfernt.

Der Verbindungsausgleich beim Entfernen, Beenden oder Löschen von Backends ist standardmäßig deaktiviert. 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 lauten.
  • 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-Back-Ends sind VMs oder Endpunkte in einer Instanzgruppe oder NEG, die als Failover-Back-End-Gruppe konfiguriert ist.

Wenn Sie einem Backend-Dienst eine Instanzgruppe oder NEG hinzufügen, ist die Instanzgruppe oder 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 Back-Ends 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).
• Traffic verwerfen, wenn Backends fehlerhaft sind: Ein boolescher Wert, der das Verhalten des Load Balancers als letzte Möglichkeit bestimmt. Das Failover-Verhältnis und die Einstellung Traffic verwerfen, wenn Back-Ends fehlerhaft sind arbeiten mit anderen Faktoren zusammen, um die Gruppe 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 Back-Ends zwischen primären und Failover-Back-Ends 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 eine Zahl festzulegen, die 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 Verbindungs-Tracking unterstützen: 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 Verbindungstracking-Tabelle 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 das Verbindungstracking geeignet sind, finden Sie in der Tabelle im Abschnitt Verbindungstracking-Modus.
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. Auf diese Weise können infrage kommende Backends fehlerfreie Failover-Backends mit einer Gewichtung ungleich null sein. Wenn Sie den Verbindungsausgleich beim Failover deaktivieren, entfernt der Load Balancer die Einträge in der Verbindungs-Tracking-Tabelle, wendet die Schritte zur Backend-Auswahl auf nachfolgende Pakete an und liefert sie an ein anderes geeignetes Backend. Das andere Backend schließt die Verbindung dann mit einem TCP-Reset, sodass Client-VMs schnell eine neue Verbindung zum Load Balancer herstellen können.

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

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 die folgenden Betriebsrichtlinien beachten. 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

Beachten Sie beim Testen eines regionalen externen Passthrough-Network Load Balancers von einem einzelnen Client aus Folgendes:

• 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, wenn 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.