Traffic-Verteilung für externe Passthrough-Network Load Balancer

Auf dieser Seite werden Konzepte zur Verteilung von Traffic durch externe 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.

• Connection Tracking wird nicht unterstützt: Wenn die konfigurierte Sitzungsaffinität Connection Tracking für das Protokoll des Pakets nicht unterstützt, fahren Sie mit dem Schritt Geeignete Back-Ends identifizieren fort. Informationen dazu, welche Protokolle für die Verbindungsverfolgung infrage kommen, finden Sie in der Tabelle im Abschnitt Modus für die Verbindungsverfolgung.

• Alle anderen Pakete: Der Load-Balancer prüft, ob das Paket mit einem vorhandenen Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt. Die Granularität des 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 und ob gewichteter Lastenausgleich aktiviert ist.

Failover-Richtlinie	Gewichtetes Load Balancing	Infrage kommende Back-Ends
		Wenn keine Failover-Richtlinie konfiguriert und das gewichtete Load Balancing deaktiviert 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 keine Failover-Richtlinie konfiguriert und der gewichtete Lastenausgleich aktiviert ist, sind die infrage kommenden Back-Ends diejenigen, die aus der ersten der folgenden nicht leeren Gruppen stammen: Alle fehlerfreien Back-Ends mit einem Gewicht ungleich null Alle fehlerhaften Back-Ends mit Gewicht ungleich null Alle fehlerfreien Back-Ends mit dem Gewicht 0 Alle fehlerhaften Back-Ends mit dem Gewicht 0
		Wenn eine Failover-Richtlinie konfiguriert und das gewichtete Load Balancing deaktiviert 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.
		Wenn eine Failover-Richtlinie konfiguriert und das gewichtete Load Balancing aktiviert ist, verwendet der Load Balancer Gewichtungsinformationen, Informationen zur Systemdiagnose und die Konfiguration der Failover-Richtlinie, um die Gruppe der infrage kommenden Back-Ends 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 nicht leeren Mengen stammen: Wenn die Menge der fehlerfreien primären Back-Ends mit Gewichtung ungleich null leer ist, sind die infrage kommenden Back-Ends alle fehlerfreien Failover-Back-Ends mit Gewichtung ungleich null. Wenn die Menge der fehlerfreien Failover-Back-Ends mit Gewichtung ungleich null leer ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit Gewichtung ungleich null. Wenn das Failover-Verhältnis auf 0.0 (Standardwert) festgelegt ist, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit einem Gewicht ungleich null. Wenn das Verhältnis der Anzahl der fehlerfreien primären Back-Ends mit 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 Gewichtung ungleich null. Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends mit Gewichtung ungleich null. Wenn es keine fehlerfreien Back-Ends mit einem Gewicht von mehr als null (primär und Failover) gibt, hängt die Menge der infrage kommenden Back-Ends von der Konfiguration der Failover-Richtlinie ab: Wenn die Failover-Richtlinie so konfiguriert ist, dass neue Verbindungen unterbrochen werden, wenn keine fehlerfreien primären und Failover-Back-Ends mit Gewichtung ungleich null vorhanden 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 getrennt werden, wenn keine fehlerfreien primären und Failover-Back-Ends mit Gewichtung ungleich null vorhanden sind, sind die infrage kommenden Back-Ends diejenigen, die aus der ersten der folgenden nicht leeren Mengen stammen: Alle fehlerhaften primären Back-Ends mit einem Gewicht ungleich null Alle fehlerhaften Failover-Back-Ends mit Gewichtung ungleich null Alle fehlerfreien primären Back-Ends mit Gewicht 0 Alle fehlerfreien Failover-Back-Ends mit Gewichtung 0 Alle fehlerhaften primären Back-Ends mit dem Gewicht 0 Alle fehlerhaften Failover-Back-Ends mit Gewichtung 0

2.2 Zulässiges Backend auswählen

Der Load-Balancer verwaltet Hashes der infrage kommenden Back-Ends, 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 Gewichten mit größerer Wahrscheinlichkeit ausgewählt werden, proportional zu ihren Gewichten.

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 zulässigen Back-Ends so zu, dass Zuordnungsunterbrechungen minimiert werden, auch wenn sich die Anzahl der zulässigen Back-Ends oder deren Gewichte ändern.

  • Der Load-Balancer wählt immer dasselbe infrage kommende Backend für eine Verbindung aus und immer dasselbe infrage kommende Backend für alle Pakete mit identischen Paketmerkmalen, wie durch die Einstellung für die Sitzungsaffinität definiert, in den folgenden Situationen:

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

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

  • Wenn ein geeignetes Backend hinzugefügt oder entfernt wird oder sich sein Gewicht ändert, soll durch konsistentes 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 kein gewichtetes Load Balancing konfiguriert ist, werden ungefähr 1/N mögliche Pakethashes jedem infrage kommenden Backend zugeordnet, wobei N die Anzahl der infrage kommenden Backends ist.

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

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

  • Wenn der Back-End-Dienst zwei infrage kommende Back-Ends hat – das erste mit dem Gewicht 1 und das zweite mit dem Gewicht 4 –, beträgt die Auswahlwahrscheinlichkeit für das erste infrage kommende Back-End 20% (1 ÷ (1+4)) und für das zweite infrage kommende Back-End 80% (4 ÷ (1+4)).

  • Wenn der Back-End-Dienst drei infrage kommende Back-Ends hat – das infrage kommende Back-End a mit dem Gewicht 0, das infrage kommende Back-End b mit dem Gewicht 2 und das infrage kommende Back-End c mit dem Gewicht 6 –, hat das Back-End a eine Auswahlwahrscheinlichkeit von 0 % (0÷(0+2+6)), das Back-End b eine Auswahlwahrscheinlichkeit von 25 % (2÷(0+2+6)) und das Back-End c eine Auswahlwahrscheinlichkeit von 75 % (6÷(0+2+6)).

2.3 Eintrag in der Tabelle für die Verbindungsnachverfolgung erstellen

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

• Wenn die konfigurierte Sitzungsaffinität die Verbindungsnachverfolgung für das Protokoll des Pakets nicht unterstützt, überspringen Sie diesen Schritt.

• Wenn die konfigurierte Sitzungsaffinität die Verbindungsverfolgung für das Protokoll des Pakets unterstützt, wird im erstellten Eintrag in der Verbindungs-Tracking-Tabelle eine Zuordnung zwischen den Paketeigenschaften und dem ausgewählten Backend erstellt. Die für diese Zuordnung verwendeten Paketheaderfelder hängen vom konfigurierten Verbindungs-Tracking-Modus und der konfigurierten Sitzungsaffinität ab.

Informationen dazu, welche Protokolle je nach Konfiguration für das Verbindungs-Tracking verwendet werden können 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 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 Eintrag in der Tabelle für das Verbindungs-Tracking wird entfernt, nachdem die Verbindung 60 Sekunden lang inaktiv war. 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 externen Passthrough-Network Load Balancers definiert den Paket-Hash für die Backend-Auswahl und, basierend auf dem Verbindungs-Tracking-Modus, den Paket-Hash für das Verbindungs-Tracking.

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

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

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

Tracking-Richtlinie für Verbindungen

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

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

Verbindungs-Tracking-Modus

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

• TCP-Verbindungen können immer nachverfolgt werden, unabhängig von den Optionen für die Sitzungsaffinität.

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

• Alle anderen Protokolle wie ICMP und ICMPv6 können nicht über eine Verbindung nachverfolgt werden.

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

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

• PER_CONNECTION: Dies ist der 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)	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: Verbindungsverfolgung 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: Verbindungsverfolgung 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: Verbindungsverfolgung 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: Verbindungsverfolgung aktiviert, 3-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert	TCP, UDP, ESP, GRE: Verbindungs-Tracking aktiviert, 2-Tupel-Hash Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert

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

Verbindungspersistenz auf fehlerhaften Back-Ends

Mit Verbindungspersistenz 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:Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten). ESP, GRE, UDP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, wenn die Sitzungsaffinität nicht NONE ist. Alle anderen Protokolle: nicht zutreffend, da sie nicht über Verbindungs-Tracking erfasst werden können.	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

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

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.

Gewichtetes Load Balancing

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

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

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

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

Weitere Informationen finden Sie unter Gewichtetes Load-Balancing konfigurieren.

Hinweise zum gewichteten Load Balancing

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

• Beim gewichteten Load Balancing kann ein Backend, das Verbindungen mit langer Laufzeit oder Verbindungen mit großen Datenmengen verarbeitet, dem Load Balancer mitteilen, dass die Anzahl der neuen Verbindungen, die es empfängt, reduziert werden soll.

• Beim gewichteten Load-Balancing kann ein Backend, das überlastet ist oder gewartet wird, sich selbst aus der Liste der infrage kommenden 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. Das funktioniert, weil alle Backends mit einem Gewicht ungleich null (unabhängig vom Status der Systemdiagnose) im Schritt Geeignete Backends ermitteln bevorzugt werden.

Beachten Sie beim Load-Balancing Folgendes:

• Wenn sich die Gewichtungen der infrage kommenden Back-Ends häufig ändern, kann sich das gewichtete Load Balancing nachteilig auf die Sitzungsaffinität auswirken. Weitere Informationen finden Sie im Schritt Geeignetes 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 ein eindeutiges Gewicht für jeden Backend-Dienst angeben:

  • Verwenden Sie für jeden Backend-Dienst eine eindeutige HTTP-Systemdiagnose. Für jede Systemdiagnose kann ein eindeutiger Zielport oder request-path-Parameter verwendet werden.

  • Konfigurieren Sie Back-End-Instanzen oder ‑Endpunkte so, dass sie bei jeder Systemdiagnose mit den entsprechenden Gewichtungsinformationen antworten.

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
• Ob Sie Failover allein oder in Verbindung mit gewichtetem Load-Balancing verwenden

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 Cloud de Confiance 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)	Protokolle, die Verbindungen nachverfolgen können: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. Protokolle, bei denen Verbindungen nicht nachverfolgt werden können: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 Verbindungs-Tracking infrage kommen, finden Sie in der Tabelle im Abschnitt Verbindungs-Tracking-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 und Failback ist in den folgenden Szenarien hilfreich:

• Back-End-VMs patchen Vor dem Patchen können Sie primäre Back-Ends mit einem Gewicht ungleich null so konfigurieren, dass Systemdiagnosen fehlschlagen, oder Sie können ihr Gewicht auf null setzen. So können infrage kommende Back-Ends Failover-Back-Ends mit einem Gewicht ungleich null sein. 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, wird durch das Deaktivieren des Verbindungsausgleichs bei Failover und Failback die Wahrscheinlichkeit von Dateninkonsistenzen verringert.

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

Backend-Dienst-basierte externe 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:

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

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

Von einem einzelnen Client aus testen

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

• Wenn die Client-VM kein Back-End des Load-Balancers ist: Neue Verbindungen werden wie in den Schritten unter Auswahl von Back-End 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 externen 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

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