Trafficverteilung für interne Passthrough-Network Load Balancer

Auf dieser Seite werden Konzepte zur Verteilung von Traffic durch interne Passthrough-Network Load Balancer erläutert.

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. Dazu ist eine zweiteilige Strategie erforderlich. Zuerst wird ein Back-End mithilfe von Consistent Hashing ausgewählt. Diese Auswahl wird dann in einer Tabelle für das Verbindungs-Tracking aufgezeichnet.

Im Folgenden werden die Auswahl des Back-Ends und das Verbindungs-Tracking beschrieben.

1 Nach einem Eintrag in der Tabelle für die Verbindungsverfolgung suchen

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

• TCP-Paket mit dem Flag SYN:

  • Wenn der Verbindungs-Tracking-Modus des Load-Balancers PER_CONNECTION ist, fahren Sie mit dem Schritt Geeignete 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 Geeignete Back-Ends ermitteln 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-Optionen für die Sitzungsaffinität (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 Pakethashs, der zum Prüfen auf einen vorhandenen Eintrag in der Tabelle zum Nachverfolgen der Verbindung verwendet wird, hängt vom konfigurierten Modus für das Verbindungs-Tracking und der konfigurierten Sitzungsaffinität ab. Weitere Informationen finden Sie in der Tabelle im Abschnitt Modus zur Verbindungsverfolgung.

  • 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 wählt der Load Balancer mit Consistent Hashing ein Backend aus den infrage kommenden Backends aus.

In den folgenden Schritten wird beschrieben, wie Sie ein geeignetes Back-End für eine neue Verbindung auswählen und diese Verbindung dann in einer Verbindungstrackingtabelle aufzeichnen.

2.1 Geeignete Back-Ends identifizieren

Infrage kommende Back-Ends sind die Back-Ends, die für neue Verbindungen infrage kommen. In der folgenden Tabelle wird die Gruppe der infrage kommenden Backends definiert, je nachdem, ob Sie eine Failover-Richtlinie konfiguriert haben.

Failover-Richtlinie	Infrage kommende Back-Ends
	Wenn keine Failover-Richtlinie konfiguriert ist, sind alle konfigurierten Back-Ends primäre Back-Ends. Die Menge der infrage kommenden Back-Ends ist 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 eine Failover-Richtlinie konfiguriert ist, verwendet der Load Balancer Informationen zur Systemdiagnose und die Konfiguration der Failover-Richtlinie, um die Gruppe der infrage kommenden Back-Ends 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 es keine fehlerfreien Failover-Back-Ends gibt, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends. 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 fehlerfrei arbeitenden primären Back-Ends zur Gesamtzahl der primären Back-Ends größer oder gleich dem konfigurierten Failover-Verhältnis ist, bestehen die infrage kommenden Back-Ends aus allen fehlerfrei arbeitenden primären Back-Ends. Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends. Wenn keine fehlerfreien (primären und Failover-)Back-Ends vorhanden sind, hängt die Menge der infrage kommenden Back-Ends ausschließlich von der Konfiguration der Failover-Richtlinie ab: Wenn die Failover-Richtlinie so konfiguriert ist, dass neue Verbindungen unterbrochen werden, wenn alle primären und Failover-Back-Ends fehlerhaft sind, ist die Menge der infrage kommenden Back-Ends 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-Back-Ends fehlerhaft sind, sind die infrage kommenden Back-Ends alle fehlerhaften primären Back-Ends.

2.2 Geeignete Backends für die 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.
• Es gibt keine zonale Übereinstimmung mit der Zone eines kompatiblen Clients.

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

• Funktionsweise von ZONAL_AFFINITY_STAY_WITHIN_ZONE

• Funktionsweise von ZONAL_AFFINITY_SPILL_CROSS_ZONE und Überlaufverhältnis

2.3 Geeignetes Backend auswählen

Der Load-Balancer verwaltet Hashes der infrage kommenden Back-Ends, wobei jeder Backend-Hash einem Einheitskreis zugeordnet ist.

Wenn der Load-Balancer ein Paket für eine Verbindung verarbeitet, die nicht in der Verbindungs-Tracking-Tabelle enthalten ist, berechnet er einen Hash der Paketeigenschaften und ordnet diesen Hash demselben Einheitskreis zu. Anschließend wird ein geeignetes Backend auf dem Umfang des Kreises ausgewählt. Die Menge der Paketmerkmale, die zum Berechnen des Pakethash verwendet werden, wird 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.

• Durch konsistentes Hashing weist der Load-Balancer neue Verbindungen geeigneten Back-Ends so zu, dass Zuordnungsunterbrechungen minimiert werden, auch wenn sich die Anzahl der geeigneten Back-Ends ändert.

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

  • Wenn ein geeignetes Backend hinzugefügt oder entfernt wird, soll durch das Consistent Hashing die Unterbrechung von Zuordnungen zu den anderen geeigneten Backends minimiert werden. Das bedeutet, dass die meisten Verbindungen, die anderen geeigneten Backends zugeordnet sind, weiterhin demselben geeigneten Backend zugeordnet werden.

• Außerdem sorgt das konsistente Hashing dafür, dass der Load-Balancer neue Verbindungen so gleichmäßig wie möglich auf die infrage kommenden Back-Ends verteilt. Für alle möglichen Paket-Hashes, die durch die konfigurierte Einstellung der Sitzungsaffinität definiert werden (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 Back-Ends nachdem das neue Back-End hinzugefügt wurde.

  • 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 vor dem Entfernen des infrage kommenden Back-Ends.

2.4 Eintrag in der Verbindungstracking-Tabelle erstellen

Nachdem ein Backend ausgewählt wurde, erstellt der Load Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle. Der Eintrag in der Tabelle für die Verbindungsverfolgung ordnet die Paketeigenschaften dem ausgewählten Backend zu. Die für diese Zuordnung verwendeten Paketheaderfelder hängen vom konfigurierten Verbindungs-Tracking-Modus und der konfigurierten Sitzungsaffinität ab.

3. Einträge in der Tabelle zur Verbindungsverfolgung verwalten

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

• Inaktive Einträge werden entfernt: Ein Tabelleneintrag für das Verbindungs-Tracking wird entfernt, nachdem die Verbindung inaktiv war. Sofern Sie kein benutzerdefiniertes Leerlauf-Zeitlimit konfigurieren, verwendet der Load Balancer ein standardmäßiges Leerlauf-Zeitlimit von 600 Sekunden. Weitere Informationen finden Sie unter Zeitüberschreitung bei Inaktivität.

• Geschlossene TCP-Verbindungen: Einträge in der Tabelle für das Verbindungs-Tracking 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 Tabelle für das Verbindungs-Tracking prüfen beschrieben wird.

• Verbindungsausgleich bei Failover: Wenn mindestens ein Failover-Backend konfiguriert ist und die Einstellung „Verbindungsausgleich bei Failover“ deaktiviert ist, entfernt der Load-Balancer alle Einträge in der Tabelle für das Verbindungs-Tracking, wenn die Gruppe der infrage kommenden Back-Ends zwischen primären und Failover-Back-Ends wechselt. Weitere Informationen finden Sie unter Verbindungsausgleich bei Failover.

• Verbindungspersistenz auf fehlerhaften Back-Ends: Einträge in der Tabelle für das Verbindungs-Tracking können entfernt werden, wenn ein Back-End fehlerhaft wird. Dieses Verhalten hängt von den Faktoren ab, die unter Verbindungspersistenz bei fehlerhaften Back-Ends beschrieben werden.

  • Wenn ein Eintrag in der Verbindungstracking-Tabelle entfernt wird, weil sich der Zustand eines zuvor ausgewählten Backends von „fehlerfrei“ zu „fehlerhaft“ ändert, werden nachfolgende Pakete für die Verbindung so behandelt, als gehörten sie zu einer neuen Verbindung. Nachdem ein neues geeignetes Backend für die nachfolgenden Pakete ausgewählt wurde, erstellt der Load-Balancer einen Ersatz-Eintrag in der Tabelle für das Verbindungs-Tracking.

  • Ein Ersatz-Eintrag in der Verbindungstrackingtabelle verhält sich genau wie jeder andere Eintrag in der Verbindungstrackingtabelle und unterliegt den Ereignissen und Regeln dieses Schritts.

  • Wenn das zuvor ausgewählte Backend von fehlerhaft zu fehlerfrei wechselt, führt die Änderung der Systemdiagnose allein nicht dazu, dass der Tabelleneintrag für das Verbindungs-Tracking der Ersatzverbindung entfernt wird. Eine Ausnahme tritt ein, wenn mindestens ein Failover-Backend konfiguriert ist und die Einstellung für den Verbindungsausgleich bei Failover deaktiviert ist. Wenn die Änderung des Status der Statusprüfung eines zuvor ausgewählten Backends mit dem Wechsel der Gruppe der infrage kommenden Backends zwischen primären und Failover-Backends zusammenfällt, werden Tabelleneinträge für das Verbindungs-Tracking entfernt.

• Verbindungsausgleich für entfernte, beendete oder gelöschte Back-Ends: Wenn der Verbindungsausgleich für entfernte, beendete oder gelöschte Back-Ends aktiviert ist, werden Einträge in der Tabelle zur Verbindungsverfolgung nach einem konfigurierbaren Zeitlimit für den Verbindungsausgleich entfernt. Der Timeout-Zähler beginnt, wenn der Befehl zum Entfernen, Beenden oder Löschen eines Back-Ends empfangen wird. Wenn der Verbindungsausgleich für entfernte, beendete oder gelöschte Back-Ends deaktiviert ist, werden Einträge in der Verbindungstrackingtabelle 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 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 (besteht aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll) für fragmentierte UDP-Pakete und Pakete aller anderen Protokolle	NONE^1 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

¹ NONE Sitzungsaffinität bedeutet nicht, dass keine Sitzungsaffinität vorhanden ist. Stattdessen bedeutet es, dass die Sitzungsaffinität mit einem 5-Tupel-Hash oder einem 3-Tupel-Hash der Paketmerkmale erfolgt – funktional dasselbe Verhalten wie bei der Einstellung CLIENT_IP_PORT_PROTO.

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 eine beliebige 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, die durch die Sitzungsaffinität definiert sind, sofern sich die Menge der infrage kommenden Backends nicht ändert. Wenn dieselbe Back-End-VM alle Pakete von einem Client verarbeiten soll, die nur auf der Quell-IP-Adresse basieren, 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
• Verbindungspersistenz bei fehlerhaften Back-Ends
• Zeitüberschreitung bei Inaktivität

Verbindungs-Tracking-Modus

In diesem Abschnitt wird beschrieben, wie der Load-Balancer Einträge in seiner Verbindungstabelle 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 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 Standard- und detaillierteste Modus für das Verbindungs-Tracking. Jede Verbindung wird entweder als 5-Tupel-Hash oder als 3-Tupel-Hash von Paketeigenschaften 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: In 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 gewählter Sitzungsaffinität kann der PER_SESSION-Tracking-Modus mehrere unterschiedliche Verbindungen für das Verbindungs-Tracking als eine einzelne Verbindung behandeln. Dadurch wird die Häufigkeit verringert, mit der eine Verbindung als neu betrachtet wird und den Schritten zur Backend-Auswahl unterliegt.

In der folgenden Tabelle sind die folgenden Informationen zusammengefasst:

• Die Paket-Hashes, die für die Backend-Auswahl verwendet werden.
• 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 das Verbindungs-Tracking
		Bei Verwendung des PER_CONNECTION-Tracking-Modus (Standard)	Bei Verwendung des PER_SESSION-Tracking-Modus
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 Fragmentiertes UDP 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 ist aktiviert, 3-Tupel-Hash
CLIENT_IP_PROTO	Alle Protokolle: 3-Tupel-Hash	TCP und nicht fragmentiertes UDP: Verbindungs-Tracking aktiviert, 5-Tupel-Hash Fragmentiertes UDP 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 ist aktiviert, 3-Tupel-Hash	Alle Protokolle: Verbindungs-Tracking ist 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 ist 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 auf fehlerhaften Back-Ends wird gesteuert, ob vorhandene Verbindungen auf einer zuvor ausgewählten Backend-VM oder einem zuvor ausgewählten Endpunkt bestehen bleiben, nachdem das Backend fehlerhaft wird, sofern das Backend in einer Load-Balancing-Instanzgruppe oder einer NEG verbleibt.

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

• DEFAULT_FOR_PROTOCOL (Standard)
• NEVER_PERSIST
• ALWAYS_PERSIST

In der folgenden Tabelle wird zusammengefasst, ob Verbindungen basierend auf fehlerhaften Back-Ends beibehalten werden, abhängig von der Option für die Verbindungspersistenz, der Sitzungsaffinität, dem Verbindungs-Tracking-Modus und dem Protokoll.

Option zur Verbindungspersistenz bei fehlerhaften Back-Ends	Verhalten der Verbindungspersistenz bei fehlerhaften Back-Ends
	Bei Verwendung des PER_CONNECTION-Tracking-Modus (Standard)	Bei Verwendung des PER_SESSION-Tracking-Modus
DEFAULT_FOR_PROTOCOL	TCP:Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten). Alle anderen Protokolle: Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen.	TCP:Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, wenn die Sitzungsaffinität NONE oder CLIENT_IP_PORT_PROTO ist. Alle anderen Protokolle: Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen.
NEVER_PERSIST	Alle Protokolle: Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen.
ALWAYS_PERSIST Diese Option sollte nur für erweiterte Anwendungsfälle verwendet werden.	TCP, UDP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten).	Konfiguration nicht möglich

Wenn die Verbindungspersistenz bei fehlerhaften Back-Ends auf Traffic angewendet wird, bleibt jede Verbindung so lange bestehen, wie ein entsprechender Eintrag in der Verbindungstrackingtabelle vorhanden ist. Weitere Informationen finden Sie im Schritt Einträge in der Tabelle zur Verbindungsverfolgung verwalten.

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 das 5-Tupel-Hash-Verbindungs-Tracking für TCP-Verbindungen in folgenden Situationen:

• 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, 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 Geeignete Back-Ends identifizieren als neue Verbindungen behandelt.)

Zeitüberschreitung bei Inaktivität

Ein Tabelleneintrag für das Verbindungs-Tracking wird entfernt, nachdem die Verbindung für einen bestimmten Zeitraum inaktiv war. Sofern Sie kein benutzerdefiniertes Zeitlimit für Inaktivität konfigurieren, verwendet der Load Balancer ein Standardzeitlimit für Inaktivität 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	Standard-Zeitlimit für Inaktivität	Minimal konfigurierbares Leerlauf-Zeitlimit	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, angehaltene oder gelöschte Back-Ends

Der Verbindungsausgleich bietet eine konfigurierbare Mindestzeit, in der bestehende Verbindungen in der Verbindungstabelle des Load-Balancers bestehen bleiben, wenn einer der folgenden Fälle eintritt:

• Eine VM-Instanz wird aus einer Backend-Instanzgruppe entfernt. Das umfasst auch das Verwerfen einer Instanz in einer verwalteten Backend-Instanzgruppe.
• Eine VM wird beendet oder gelöscht. Dies schließt automatische Aktionen wie Rolling Updates oder das Herunterskalieren einer verwalteten Back-End-Instanzgruppe ein.
• Ein Endpunkt wird aus einer Backend-Netzwerk-Endpunktgruppe (NEG) entfernt.

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

Failover

Mit Failover können Sie die Gruppe der infrage kommenden Back-Ends für neue Verbindungen beeinflussen, indem Sie jede Backend-Instanzgruppe oder jedes NEG als primär oder Failover klassifizieren.

Wenn Sie einem Back-End-Dienst eine Instanzgruppe oder NEG hinzufügen, sind die zugehörigen VMs oder Endpunkte standardmäßig primäre Back-Ends und die Instanzgruppe oder NEG ist eine primäre Back-End-Gruppe. Mit Failover können Sie eine Failover-Backend-Gruppe (Instanzgruppe oder NEG) hinzufügen, deren Mitglieds-VMs oder -Endpunkte Failover-Back-Ends sind:

• Für das Failover muss ein Backend-Dienst mindestens eine primäre Backend-Gruppe und mindestens eine Failover-Backend-Gruppe haben.
• Sie können einem Backend-Dienst bis zu 50 primäre Backend-Gruppen und 50 Failover-Backend-Gruppen hinzufügen.

Beim Failover wird die Gruppe der infrage kommenden Back-Ends durch die folgenden Faktoren bestimmt:

• Der Systemstatus der einzelnen Backends
• Die von Ihnen konfigurierte Failover-Quote
• Die Einstellung Traffic löschen, wenn Back-Ends fehlerhaft sind

Failover-Richtlinie

Wenn ein Back-End-Dienst mindestens eine primäre Back-End-Gruppe und mindestens eine Failover-Back-End-Gruppe hat, können Sie die folgenden Einstellungen in der Failover-Richtlinie anpassen:

• 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 letzten Ausweg bestimmt. Das Failover-Verhältnis und die Einstellung Traffic verwerfen, wenn Back-Ends fehlerhaft sind wirken zusammen mit anderen Faktoren, 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 konfigurierte 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 keine Failover-Quote angeben,verwendet Google Cloud den Standardwert 0.0. Es empfiehlt sich, die Failover-Quote auf eine Zahl zu setzen, die für Ihren Anwendungsfall geeignet ist, anstatt sich auf diese Standardeinstellung zu verlassen.

Verbindungsausgleich bei Failover

Verbindungsausgleich bei Failover: Hiermit wird gesteuert, 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 wird 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 Verbindungstracking-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 Verbindungsverfolgung 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 und Failback ist in den folgenden Szenarien hilfreich:

• Back-End-VMs patchen Vor dem Patchen können Sie primäre Back-Ends, die intakt sind, so konfigurieren, dass Systemdiagnosen fehlschlagen. So können die infrage kommenden Back-Ends als Failover-Back-Ends verwendet werden. Wenn Sie den Verbindungsausgleich bei Failover und Failback deaktivieren, entfernt der Load-Balancer Einträge aus der Tabelle für das Verbindungs-Tracking, wendet die Schritte zur Backend-Auswahl auf nachfolgende Pakete an und leitet sie an ein anderes infrage kommendes Backend weiter. Das andere Back-End 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 dafür sorgen müssen, dass die Gruppe der infrage kommenden Back-Ends nicht mehr als eine Mitglieds-VM oder einen Mitgliedsendpunkt enthält, verringert das Deaktivieren des Verbindungsausgleichs bei Failover und Failback die Wahrscheinlichkeit von Dateninkonsistenzen.

Informationen zum Deaktivieren des Verbindungsausgleichs bei Failover und Failback finden Sie unter Verbindungsausgleich bei Failover und Failback deaktivieren.

Best Practices und Anleitungen

Sie können den internen Passthrough-Network Load Balancer optimieren, indem Sie diese Betriebsrichtlinien befolgen. In den folgenden Abschnitten finden Sie technische Anforderungen für die Verarbeitung fragmentierter UDP-Pakete und Best Practices für das 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 Google Cloud-VPC-Netzwerk erreichen.
• Google Cloud VPC-Netzwerke leiten UDP-Fragmente direkt bei Eingang weiter (ohne auf alle Fragmente zu warten).
• Nicht-Google Cloud -Netzwerke und lokale Netzwerkgeräte können eingehende UDP-Fragmente bei Eingang weiterleiten, fragmentierte UDP-Pakete verzögern, bis alle Fragmente eingegangen sind, oder fragmentierte UDP-Pakete verwerfen. Weitere Informationen finden Sie in der Dokumentation des Netzwerkanbieters oder der Netzwerkgeräte.

Wenn Sie fragmentierte UDP-Datenpakete erwarten und diese an dieselben Backends weiterleiten müssen, verwenden Sie die folgenden Weiterleitungsregel und Backend-Dienstkonfigurationsparameter:

• Weiterleitungsregel konfigurieren: Verwenden Sie nur eine UDP-Weiterleitungsregel pro IP-Adresse mit Load-Balancing und konfigurieren Sie die Weiterleitungsregel so, dass Traffic an allen Ports akzeptiert wird. Dadurch wird gewährleistet, dass alle Fragmente zur selben Weiterleitungsregel gelangen. Auch wenn die fragmentierten Pakete (mit Ausnahme des ersten Fragments) keinen Zielport haben, wird beim Konfigurieren der Weiterleitungsregel für die Verarbeitung von Traffic für alle Ports auch dieser so konfiguriert, dass UDP-Fragmente ohne Portinformationen empfangen werden. Konfigurieren Sie entweder die Google Cloud CLI, um --ports=ALL festzulegen, oder verwenden Sie die API, um allPorts auf True einzustellen.

• Konfiguration des Backend-Diensts: Legen Sie die Sitzungsaffinität des Backend-Diensts auf CLIENT_IP (2-Tupel-Hash) oder CLIENT_IP_PROTO (3-Tupel-Hash) fest, sodass dasselbe Backend für UDP-Pakete ausgewählt wird, die Portinformationen und UDP-Fragmente (außer dem ersten Fragment) enthalten, für die Portinformationen fehlen. Setzen Sie den Verbindungs-Tracking-Modus des Backend-Dienstes auf PER_SESSION, damit die Einträge für das Verbindungs-Tracking-Tabellen mit denselben 2-Tupel- oder 3-Tupel-Hashes erstellt werden.

Von einem einzelnen Client aus testen

Beim Testen eines internen 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 Geeignetes Backend auswählen erstellt der Load-Balancer einen Hash der Paketmerkmale gemäß der Sitzungsaffinität.

  Beachten Sie, dass für alle Sitzungsaffinitätsoptionen mindestens die IP-Adresse des Clients erforderlich ist. Verbindungen von demselben 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-Netzwerk-Load-Balancer herstellen.

• Wenn die Client-VM auch eine Back-End-VM des Load-Balancers ist, werden neue Verbindungen überhaupt nicht vom Load-Balancer verarbeitet. Ausgehende Pakete mit der Ziel-IP-Adresse der Weiterleitungsregel des Load-Balancers werden aufgrund des Vorhandenseins einer lokalen Route für die Weiterleitungsregel lokal im Gastbetriebssystem des Clients weitergeleitet.

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.