Trafficverteilung für interne Passthrough-Network Load Balancer

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 Backends und das Verbindungs-Tracking arbeiten zusammen, um mehrere Verbindungen auf verschiedene Backends zu verteilen 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.

Im Folgenden wird die Auswahl von Back-Ends 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 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 PER_SESSION-Tracking-Modus stellt ein TCP-Paket mit dem SYN-Flag nur dann eine neue Verbindung dar, wenn eine der 5-Tupel-Sitzungsaffinitätsoptionen (NONE oder CLIENT_IP_PORT_PROTO) verwendet wird.

• 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 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 Back-Ends ermitteln

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.

Failover	Infrage kommende Backends
	Wenn das Failover-Load-Balancing deaktiviert ist, sind alle konfigurierten Back-Ends primäre Back-Ends. 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 die Funktion für das Failover-Load-Balancing aktiviert ist, verwendet der Load Balancer Informationen aus der 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 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 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.

2.2 Zulässige Backends für zonale Affinität anpassen

Dieser Schritt wird übersprungen, wenn eine der folgenden Bedingungen zutrifft:

• Zonale Affinität ist deaktiviert.
• Der Client ist nicht mit der zonenbasierten Affinität kompatibel.
• Eine zonale Übereinstimmung mit der Zone eines kompatiblen Clients erfolgt nicht.

Wenn die zonale Affinität aktiviert ist, ein Client mit der zonalen Affinität kompatibel ist und eine zonale Übereinstimmung vorliegt, werden neue Verbindungen vom Client an eine angepasste Gruppe von infrage kommenden Back-Ends weitergeleitet. Hier finden Sie weitere Informationen:

• So funktioniert ZONAL_AFFINITY_STAY_WITHIN_ZONE

• Funktionsweise von ZONAL_AFFINITY_SPILL_CROSS_ZONE und Überlaufverhältnis

2.3 Zulässiges Backend auswählen

Der Load-Balancer verwaltet Hashes der infrage kommenden Backends. Jeder Backend-Hash wird einem Einheitskreis zugeordnet.

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-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 ändert.

  • Der Load-Balancer wählt immer dasselbe infrage kommende Backend für eine Verbindung aus. Allgemeiner gesagt wählt er immer dasselbe infrage kommende Backend für alle Pakete mit identischen Paketmerkmalen aus, die durch die Einstellung für die Sitzungsaffinität definiert werden, sofern sich die Menge der infrage kommenden Backends nicht ändert.

  • Wenn ein zulässiges Backend hinzugefügt oder entfernt wird, wird durch konsistente Hashfunktion die Unterbrechung von Zuordnungen zu den anderen zulässigen Backends minimiert. Das bedeutet, dass die meisten Verbindungen, die anderen zulässigen Backends zugeordnet sind, weiterhin demselben zulässigen 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 Sitzungsaffinitätseinstellung 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 ein geeignetes Backend hinzugefügt wird, werden etwa 1/N neue Verbindungen dem neu hinzugefügten Backend zugeordnet. In diesem Fall ist N die Anzahl der Backends nach dem Hinzufügen des neuen Backends.

  • Wenn ein infrage kommendes Backend entfernt wird, werden etwa 1/N neue Verbindungen einem der N-1 verbleibenden Backends zugeordnet. In diesem Fall ist N die Anzahl der Back-Ends, bevor das infrage kommende Back-End entfernt wird.

2.4 Eintrag in der Tabelle zur Verbindungsverfolgung erstellen

Nachdem ein Backend ausgewählt wurde, erstellt der Load Balancer einen Eintrag in der Tabelle für das Verbindungs-Tracking. Der Eintrag in der Verbindungs-Tracking-Tabelle ordnet dem ausgewählten Back-End Paketmerkmale 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 Paketmerkmale für den Hash in der Verbindungstracking-Tabelle verwendet werden, finden Sie in der Tabelle im Abschnitt Verbindungstracking-Modus.

3. Einträge in der Verbindungstracking-Tabelle verwalten

Der Load Balancer verwaltet die Einträge in der Tabelle für das Verbindungs-Tracking gemäß den folgenden Ereignissen und Regeln:

• Inaktive Einträge werden entfernt: Ein Eintrag in der Tabelle für das Verbindungs-Tracking wird nach einer bestimmten Zeit entfernt, wenn keine neuen eingehenden Pakete vom Load-Balancer verarbeitet werden. Wenn Sie kein benutzerdefiniertes Zeitlimit für Inaktivität konfigurieren, verwendet der Load Balancer ein Standardzeitlimit für Inaktivität von 600 Sekunden. Weitere Informationen finden Sie unter Inaktivitäts-Zeitlimit.

• Einträge werden entfernt, wenn die Tabellen zur Nachverfolgung von Clientverbindungen voll sind: Tabellen zur Nachverfolgung von Verbindungen für interne Passthrough-Network-Load-Balancer werden auf Client-Systemen implementiert, z. B. auf einem Host, auf dem eine VM-Instanz ausgeführt wird, einem Host, der einen VLAN-Anhang unterstützt, oder einem Host, auf dem ein Cloud VPN-Tunnel ausgeführt wird. Wenn die Tabelle zum Nachverfolgen der Verbindung eines Clients voll ist, werden die Einträge für die am längsten nicht verwendeten Verbindungen entfernt.

• 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 Flag SYN und unterliegt der Verarbeitung, die im Schritt Eintrag in der Verbindungstracking-Tabelle prüfen beschrieben wird.

• Wenn Verbindungen bei einem Failover nicht beibehalten werden: Wenn mindestens ein Failover-Backend konfiguriert ist und die Einstellung für den Verbindungsausgleich bei 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 derzeit nicht proaktiv Einträge aus der Verbindungstrackingtabelle, wenn die Gruppe der infrage kommenden Back-Ends zwischen primären und Failover-Back-Ends 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 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 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 infrage kommendes Backend auswählt und einen neuen Eintrag in der Verbindungs-Tracking-Tabelle erstellt.

  • Wenn sich ein zuvor ausgewähltes Backend 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, sofern kein anderer Grund oder kein anderes Ereignis den Tabelleneintrag für das Verbindungs-Tracking 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 internen 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.

Interne 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
1-Tupel-Hash (besteht nur aus der Quell-IP)	CLIENT_IP_NO_DESTINATION

Sitzungsaffinität und Load-Balancer als nächster Hop

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 jede IP-Adresse sein, die in den Zielbereich der statischen Route passt.

Die Auswahl eines geeigneten Back-Ends hängt von der Berechnung eines Hashwerts der Paketmerkmale ab. Mit Ausnahme der CLIENT_IP_NO_DESTINATION-Sitzungsaffinität (1-Tupel-Hash) hängt der Hash teilweise von der Ziel-IP-Adresse des Pakets ab.

Der Load Balancer wählt dasselbe Backend für alle möglichen neuen Verbindungen mit identischen Paketmerkmalen aus, wie durch die Sitzungsaffinität definiert, wenn sich die Gruppe der infrage kommenden Backends nicht ändert. Wenn alle Pakete von einem Client von derselben Backend-VM verarbeitet werden sollen, basierend auf der Quell-IP-Adresse und unabhängig von den Ziel-IP-Adressen, verwenden Sie die CLIENT_IP_NO_DESTINATION-Sitzungsaffinität.

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, wie der Load Balancer Einträge in seiner Tabelle für das Verbindungs-Tracking erstellt. Interne Passthrough-Network Load Balancer verfolgen Verbindungen für alle Protokolle, die sie unterstützen, und für alle Optionen für die Sitzungsaffinität.

Der Verbindungs-Tracking-Modus, das Protokoll und die Sitzungsaffinität bestimmen 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: 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 kann der PER_SESSION-Tracking-Modus mehrere unterschiedliche Verbindungen für das Verbindungs-Tracking als eine einzige Verbindung behandeln. Dadurch wird die Häufigkeit verringert, mit der eine Verbindung als neu betrachtet wird und den Schritten zur Back-End-Auswahl unterliegt.

In der folgenden Tabelle sind die folgenden Informationen zusammengefasst:

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

Sitzungsaffinität	Paket-Hash für die Backend-Auswahl	Paket-Hash für die Verbindungsverfolgung
		Bei Verwendung des Tracking-Modus PER_CONNECTION (Standard)	Bei Verwendung des Tracking-Modus „PER_SESSION“
NONE (Standard) ODER 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-Pakete und alle anderen Protokolle:Verbindungs-Tracking ist aktiviert, 3-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: Verbindungs-Tracking aktiviert, 3-Tupel-Hash
CLIENT_IP_PROTO	Alle Protokolle: 3-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentierte UDP-Pakete und alle anderen Protokolle:Verbindungs-Tracking ist aktiviert, 3-Tupel-Hash	Alle Protokolle:Verbindungs-Tracking ist aktiviert, 3-Tupel-Hash
CLIENT_IP	Alle Protokolle: 2-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: Verbindungs-Tracking aktiviert, 3-Tupel-Hash	Alle Protokolle: Verbindungs-Tracking aktiviert, 2-Tupel-Hash
CLIENT_IP_NO_DESTINATION	Alle Protokolle:1-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: Verbindungs-Tracking aktiviert, 3-Tupel-Hash	Alle Protokolle: Verbindungs-Tracking ist aktiviert, 1-Tupel-Hash

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. Für die Verbindungspersistenz auf fehlerhaften Back-Ends muss die Back-End-VM Mitglied einer Instanzgruppe oder NEG mit Load-Balancing bleiben.

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, SCTP (alle Sitzungsaffinitäten): Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, vorbehaltlich der anderen Ereignisse und Regeln im Schritt Einträge in der Verbindungstracking-Tabelle verwalten. Alle anderen Protokolle:Verbindungen bleiben auf fehlerhaften Back-Ends nicht bestehen.	TCP, SCTP (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, SCTP (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.	Alle Protokolle (alle Sitzungsaffinitäten): Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, vorbehaltlich der anderen Ereignisse und Regeln im Schritt Tabelleneinträge für das Verbindungs-Tracking verwalten.	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
• Bei Verwendung des Tracking-Modus PER_SESSION und der Sitzungsaffinität entweder NONE oder CLIENT_IP_PORT_PROTO.

Wenn der Load Balancer das 5-Tupel-Hash-Verbindungs-Tracking für TCP-Verbindungen verwendet, sollten Sie Folgendes beachten:

• 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 infrage kommendes Backend auswählen. (TCP-SYN-Pakete werden im Schritt Zulässige Back-Ends identifizieren als neue Verbindungen behandelt.)

Zeitüberschreitung bei Inaktivität

Ein Eintrag in der Tabelle zur Verbindungsverfolgung wird entfernt, nachdem die Verbindung für einen bestimmten Zeitraum inaktiv war. Wenn Sie kein benutzerdefiniertes Zeitlimit für Inaktivität konfigurieren, verwendet der Load Balancer einen Standardwert von 600 Sekunden (10 Minuten).

In der folgenden Tabelle sind die minimalen und maximalen konfigurierbaren Leerlauf-Zeitüberschreitungswerte für verschiedene Kombinationen von Einstellungen für Sitzungsaffinität und Verbindungs-Tracking-Modus aufgeführt.

Sitzungsaffinität	Verbindungs-Tracking-Modus	Standardzeitlimit für Inaktivität	Minimal konfigurierbares Zeitlimit für Inaktivität	Maximal konfigurierbares Zeitlimit für Inaktivität
Beliebiges Verbindungstupel	PER_CONNECTION	600 Sekunden	60 Sekunden	600 Sekunden
1-Tupel (CLIENT_IP_NO_DESTINATION) 2-Tupel (CLIENT_IP) 3-Tupel (CLIENT_IP_PROTO)	PER_SESSION	600 Sekunden	60 Sekunden	57.600 Sekunden
5‑Tupel (NONE, CLIENT_IP_PORT_PROTO)	PER_SESSION	600 Sekunden	60 Sekunden	600 Sekunden

Informationen zum Ändern des Werts für die Zeitüberschreitung bei Inaktivität finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.

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.

Der Verbindungsausgleich beim Entfernen, Beenden oder Löschen von Backends ist standardmäßig deaktiviert. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.

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 Back-Ends sind VMs oder Endpunkte in einer Instanzgruppe oder NEG, die als primäre Back-End-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-Back-End-Gruppe

Wenn das Failover aktiviert ist, wird die Gruppe der infrage kommenden Back-Ends durch die folgenden Faktoren bestimmt:

• 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

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 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 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)	Alle Protokolle: Verbindungen bleiben bestehen, solange ein entsprechender Eintrag in der Verbindungs-Tracking-Tabelle vorhanden ist, wenn die Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends wechselt. Weitere Informationen finden Sie im Schritt Einträge in der Verbindungstracking-Tabelle verwalten.
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 Backends so konfigurieren, dass sie die Systemdiagnosen nicht bestehen, damit die infrage kommenden Backends fehlerfreie Failover-Backends sein können. 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 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 internen 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

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

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

Von einem einzelnen Client aus testen

Beachten Sie beim Testen eines internen 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 Geeignetes 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 über einen einzelnen Client eine Verbindung zu einem internen 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

• Mehr über das Konfigurieren und Testen eines internen Passthrough-Network-Load-Balancers, der Failover verwendet, unter Failover für den internen Passthrough-Network-Load-Balancer konfigurieren erfahren
• Informationen zum Konfigurieren und Testen eines internen Passthrough-Network-Load-Balancers finden Sie unter Internen Passthrough-Network-Load-Balancer einrichten.