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. Dies wird mit einer zweiteiligen Strategie erreicht. Zuerst wird ein Back-End mithilfe von Consistent Hashing ausgewählt. Diese Auswahl wird dann in einer Tabelle für das Verbindungs-Tracking aufgezeichnet.
Die folgenden Schritte beschreiben die Auswahl des Back-Ends und das Verbindungs-Tracking.
1 Eintrag in der Tabelle zur Nachverfolgung der Verbindung prüfen, um ein zuvor ausgewähltes Back-End zu verwenden
Bei einer bestehenden Verbindung verwendet der Load-Balancer die Verbindungs-Tracking-Tabelle, um das zuvor ausgewählte Back-End für diese Verbindung zu identifizieren.
Der Load-Balancer versucht, jedes Paket mit Load-Balancing mit einem Eintrag in seiner Tabelle für das Verbindungs-Tracking abzugleichen. Dazu geht er so vor:
Wenn das Paket ein TCP-Paket mit dem Flag
SYN
ist:Wenn der Modus für das Verbindungs-Tracking des Load-Balancers
PER_CONNECTION
ist, fahren Sie mit dem Schritt Geeignete Backends identifizieren fort. ImPER_CONNECTION
-Tracking-Modus stellt ein TCP-Paket mit demSYN
-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 entwederNONE
oderCLIENT_IP_PORT_PROTO
ist, fahren Sie mit dem Schritt Geeignete Backends identifizieren fort. Im Tracking-ModusPER_SESSION
stellt ein TCP-Paket mit dem FlagSYN
nur dann eine neue Verbindung dar, wenn eine der 5-Tupel-Optionen für die Sitzungsaffinität (NONE
oderCLIENT_IP_PORT_PROTO
) verwendet wird.
Wenn die konfigurierte Sitzungsaffinität die Verbindungsnachverfolgung 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 das Verbindungs-Tracking infrage kommen, finden Sie in der Tabelle im Abschnitt Verbindungs-Tracking-Modus.
Bei allen anderen Paketen prüft der Load-Balancer, ob das Paket mit einem vorhandenen Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt. Das Verbindungstupel (eine Reihe von Paketmerkmalen), das zum Vergleichen des Pakets mit vorhandenen Einträgen in der Tabelle zum Nachverfolgen der Verbindung verwendet wird, hängt vom konfigurierten Verbindungs-Tracking-Modus und der konfigurierten Sitzungsaffinität ab. Informationen dazu, welches Verbindungstupel für das Verbindungs-Tracking verwendet wird, finden Sie in der Tabelle im Abschnitt Verbindungs-Tracking-Modus.
Wenn das Paket mit einem Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt, sendet der Load-Balancer das Paket an das zuvor ausgewählte Backend.
Wenn das Paket nicht mit einem Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt, fahren Sie mit dem Schritt Geeignete Back-Ends ermitteln fort.
Informationen dazu, wie lange ein Eintrag in der Verbindungstracking-Tabelle bestehen bleibt und unter welchen Bedingungen er bestehen bleibt, finden Sie im Schritt Eintrag in der Verbindungstracking-Tabelle erstellen.
2. Geeignetes Backend für eine neue Verbindung auswählen
Bei einer neuen Verbindung wählt der Load-Balancer mit dem konsistenten Hash-Algorithmus 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 ermitteln
In diesem Schritt wird modelliert, welche Back-Ends für neue Verbindungen infrage kommen. Dabei werden der Systemstatus, das gewichtete Load Balancing und die Konfiguration der Failover-Richtlinie berücksichtigt.
In der folgenden Tabelle wird beschrieben, wie sich die Failover-Richtlinie und das gewichtete Load-Balancing darauf auswirken, welche Back-Ends infrage kommen.
Failover-Richtlinie | Gewichtetes Load Balancing | Zulässige Back-Ends |
---|---|---|
Siehe Keine Failover-Richtlinie, gewichtetes Load Balancing deaktiviert | ||
Siehe Keine Failover-Richtlinie, gewichtetes Load Balancing aktiviert | ||
Siehe Failover-Richtlinie konfiguriert, gewichtetes Load Balancing deaktiviert | ||
Weitere Informationen finden Sie unter Failover-Richtlinie konfiguriert, gewichtetes Load Balancing aktiviert. |
Keine Failover-Richtlinie, gewichtetes Load Balancing deaktiviert
Die Menge der infrage kommenden Backends hängt nur von Systemdiagnosen ab:
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.
Keine Failover-Richtlinie, gewichtetes Load-Balancing aktiviert
Die Menge der infrage kommenden Back-Ends hängt sowohl von Systemdiagnosen als auch von Gewichten ab und besteht aus der ersten der folgenden Optionen, die nicht leer ist:
- Alle fehlerfreien Back-Ends mit Gewicht ungleich null
- Alle fehlerhaften Back-Ends mit Gewichtung ungleich null
- Alle fehlerfreien Back-Ends mit dem Gewicht 0
- Alle fehlerhaften Back-Ends mit Gewichtung 0
Failover-Richtlinie konfiguriert, gewichtetes Load Balancing deaktiviert
Die Menge der infrage kommenden Back-Ends hängt von der Konfiguration der Systemdiagnosen und der Failover-Richtlinie ab:
Wenn mindestens ein Backend fehlerfrei ist, wird die Gruppe der infrage kommenden Backends anhand der ersten Bedingung in der folgenden geordneten Liste definiert, die zutrifft:
- 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
(der 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 Back-Ends 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.
- Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends.
Wenn keine fehlerfreien Back-Ends vorhanden sind, wird die Menge der infrage kommenden Back-Ends so definiert:
- Wenn die Failover-Richtlinie des Load-Balancers so konfiguriert ist, dass neue Verbindungen verworfen werden, wenn keine Back-Ends fehlerfrei sind, ist die Menge der infrage kommenden Back-Ends leer. Der Load-Balancer verwirft die Pakete für neue Verbindungen.
- Wenn die Failover-Richtlinie des Load-Balancers nicht so konfiguriert ist, dass neue Verbindungen verworfen werden, wenn keine Back-Ends fehlerfrei sind, sind Systemdiagnosen nicht relevant. Infrage kommende Back-Ends sind alle primären Back-Ends.
Failover-Richtlinie konfiguriert, gewichtetes Load Balancing aktiviert
Die Menge der infrage kommenden Back-Ends hängt von der Konfiguration der Systemdiagnosen, Gewichte und Failover-Richtlinien ab:
Wenn mindestens ein Backend fehlerfrei ist und ein Gewicht ungleich null hat, wird die Gruppe der infrage kommenden Backends anhand der ersten Bedingung aus der folgenden geordneten Liste definiert, die zutrifft:
- Wenn es keine fehlerfreien primären Back-Ends mit einem Gewicht von mehr als null gibt, sind die infrage kommenden Back-Ends alle fehlerfreien Failover-Back-Ends mit einem Gewicht von mehr als null.
- Wenn es keine fehlerfreien Failover-Back-Ends mit einem Gewicht ungleich null gibt, sind die infrage kommenden Back-Ends alle fehlerfreien primären Back-Ends mit einem Gewicht 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 fehlerfrei arbeitenden primären Back-Ends mit Gewichtung ungleich null 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 mit Gewichtung ungleich null.
- Die infrage kommenden Back-Ends bestehen aus allen fehlerfreien Failover-Back-Ends mit einem Gewicht ungleich null.
Wenn es keine fehlerfreien Back-Ends mit einem Gewicht ungleich null gibt, wird die Gruppe der infrage kommenden Back-Ends so definiert:
- Wenn die Failover-Richtlinie des Load-Balancers so konfiguriert ist, dass neue Verbindungen verworfen werden, wenn keine Back-Ends fehlerfrei sind, ist die Menge der infrage kommenden Back-Ends leer. Der Load-Balancer verwirft die Pakete für neue Verbindungen.
Wenn die Failover-Richtlinie des Load-Balancers nicht so konfiguriert ist, dass neue Verbindungen unterbrochen werden, wenn keine Back-Ends fehlerfrei sind, ist die Gruppe der infrage kommenden Back-Ends die erste der folgenden, die nicht leer ist:
- Alle fehlerhaften primären Back-Ends mit Gewichtung ungleich null
- Alle fehlerhaften Failover-Back-Ends mit einem Gewicht ungleich null
- Alle fehlerfreien primären Back-Ends mit dem Gewicht 0
- Alle fehlerfreien Back-Ends mit Gewichtung 0 für das Failover
- Alle fehlerhaften primären Back-Ends mit dem Gewicht 0
- Alle fehlerhaften Failover-Back-Ends mit Gewichtung 0
2.2 Geeignetes Backend auswählen
Der Load-Balancer verwendet konsistentes Hashing, um ein geeignetes Backend auszuwählen. Der Load-Balancer verwaltet Hashes der infrage kommenden Back-Ends, die einem Einheitskreis zugeordnet sind. Beim gewichteten Load-Balancing wird die Zuordnung der infrage kommenden Backends zum Kreis so geändert, dass Backends mit höheren Gewichten proportional zu ihren Gewichten mit größerer Wahrscheinlichkeit ausgewählt werden.
Wenn der Load-Balancer ein Paket für eine Verbindung verarbeitet, die nicht in der Verbindungs-Tracking-Tabelle enthalten ist, berechnet er einen Hash der Paketmerkmale und ordnet diesen Hash demselben Einheitskreis zu. Anschließend wählt er ein geeignetes Backend auf dem Kreisumfang aus. Die Menge der Paketmerkmale, die zum Berechnen des Paket-Hashwerts verwendet werden, wird durch die Einstellung für die Sitzungsaffinität definiert.
Wenn keine Sitzungsaffinität explizit konfiguriert ist, wird standardmäßig die Sitzungsaffinität
NONE
verwendet.Die folgenden beiden Beispiele zeigen, wie sich das gewichtete Load Balancing auf die Auswahl eines infrage kommenden Back-Ends auswirkt:
Wenn der Back-End-Dienst zwei infrage kommende Back-Ends hat, wobei das erste das Gewicht
1
und das zweite das Gewicht4
hat, 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 (infrage kommendes Back-End
a
mit Gewicht0
, infrage kommendes Back-Endb
mit Gewicht2
und infrage kommendes Back-Endc
mit Gewicht6
), hat Back-Enda
eine Auswahlwahrscheinlichkeit von 0 % (0
÷(0+2+6)
), Back-Endb
eine Auswahlwahrscheinlichkeit von 25 % (2
÷(0+2+6)
) und Back-Endc
eine Auswahlwahrscheinlichkeit von 75 % (6
÷(0+2+6)
).
Der Load-Balancer weist neue Verbindungen in Frage kommenden Back-Ends so zu, dass dies möglichst konsistent erfolgt, auch wenn sich die Anzahl der in Frage kommenden Back-Ends oder deren Gewichtungen ändern. Die folgenden Vorteile des konsistenten Hashings zeigen, wie der Load-Balancer geeignete Back-Ends für mögliche neue Verbindungen auswählt, für die keine Einträge in der Verbindungstracking-Tabelle vorhanden sind:
Der Load-Balancer wählt in den folgenden Situationen dasselbe Backend für alle möglichen neuen Verbindungen mit identischen Paketmerkmalen aus, wie durch die Sitzungsaffinität definiert:
Wenn kein gewichtetes Load Balancing konfiguriert ist und sich die Gruppe der infrage kommenden Back-Ends nicht ändert.
Wenn das gewichtete Load Balancing konfiguriert ist, und sich die Menge der infrage kommenden Back-Ends nicht ändert und das Gewicht jedes infrage kommenden Back-Ends konstant bleibt.
Der Load-Balancer verteilt mögliche neue Verbindungen so gleichmäßig wie möglich auf die infrage kommenden Back-Ends:
Wenn kein gewichteter Lastenausgleich konfiguriert ist, wird ungefähr
1/N
möglichen neuen Verbindungen jedem infrage kommenden Backend zugeordnet, wobeiN
die Anzahl der infrage kommenden Backends ist.Wenn gewichtetes Load Balancing konfiguriert ist, ist das Verhältnis der möglichen neuen Verbindungen, die jedem infrage kommenden Backend zugeordnet werden, ungefähr gleich dem Gewicht eines infrage kommenden Backends geteilt durch die Summe aller infrage kommenden Backend-Gewichtungen.
Wenn ein infrage kommendes Backend hinzugefügt oder entfernt wird oder sich sein Gewicht ändert, soll durch das Consistent Hashing die Unterbrechung von Zuordnungen zu den anderen infrage kommenden Backends minimiert werden. Das bedeutet, dass die meisten Verbindungen, die anderen infrage kommenden Backends zugeordnet sind, weiterhin demselben infrage kommenden Backend zugeordnet werden.
2.3 Eintrag für die Verbindungstracking-Tabelle 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 Eintrag in der Verbindungs-Tracking-Tabelle, der erstellt wird, eine Zuordnung zwischen den Paketeigenschaften und dem ausgewählten Backend vorgenommen. 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 per Verbindungs-Tracking verfolgt werden können und welche Paketmerkmale für den Hash verwendet werden, finden Sie im Abschnitt Verbindungs-Tracking-Modus.
Der Load-Balancer entfernt Einträge aus der Tabelle für das Verbindungs-Tracking gemäß den folgenden Regeln:
Ein Tabelleneintrag 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.
Tabelleneinträge für das Verbindungs-Tracking werden nicht entfernt, wenn eine TCP-Verbindung mit einem
FIN
- oderRST
-Paket geschlossen wird. Jede neue TCP-Verbindung enthält immer das FlagSYN
und wird wie im Schritt Eintrag in der Tabelle für das Verbindungs-Tracking prüfen beschrieben verarbeitet.Wenn eine Failover-Richtlinie konfiguriert ist und die Einstellung „Verbindungsausgleich bei Failover und Failback“ deaktiviert ist, entfernt der Load-Balancer alle Einträge in der Verbindungs-Tracking-Tabelle, wenn die infrage kommenden Back-Ends von primären zu Failover-Back-Ends (Failover) oder von Failover- zu primären Back-Ends (Failback) wechseln. Weitere Informationen finden Sie unter Verbindungsausgleich bei Failover und Failback.
Einträge in der Tabelle für das Verbindungs-Tracking können entfernt werden, wenn ein Backend fehlerhaft wird. Dieses Verhalten hängt vom Verbindungs-Tracking-Modus, vom Protokoll und von der Einstellung für die Verbindungspersistenz bei fehlerhaften Back-Ends ab. Weitere Informationen finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.
Einträge in der Verbindungstracking-Tabelle werden nach dem Zeitlimit für den Verbindungsausgleich entfernt, das nach einem Ereignis wie dem Löschen einer Back-End-VM oder dem Entfernen einer Back-End-VM aus einer Instanzgruppe oder NEG auftritt. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.
Sitzungsaffinität
Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Back-Ends des Load-Balancers. Externe Passthrough-Network Load Balancer verwenden die Sitzungsaffinität, um ein Backend aus einer Reihe von infrage kommenden Backends auszuwählen. Dies wird in den Schritten Infrage kommende Backends identifizieren und Infrage kommendes Backend auswählen im Abschnitt Backend-Auswahl und Verbindungs-Tracking beschrieben. Sie konfigurieren die Sitzungsaffinität für den Back-End-Dienst und nicht für jede Back-End-Instanzgruppe oder NEG.
Externe Passthrough-Network Load Balancer unterstützen die folgenden Einstellungen für die Sitzungsaffinität. Bei jeder Einstellung für die Sitzungsaffinität wird konsistentes Hashing verwendet, um ein geeignetes Backend auszuwählen. Die Einstellung für die Sitzungsaffinität bestimmt, welche Felder aus dem IP-Header und den TCP-/UDP-Headern zum Berechnen des Hash verwendet werden.
Hash-Methode für die Backend-Auswahl | Einstellung für die Sitzungsaffinität1 |
---|---|
5-Tupel-Hash (besteht aus Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport) für nicht fragmentierte Pakete, die Portinformationen wie TCP-Pakete und nicht fragmentierte UDP-Pakete enthalten OR3-Tupel-Hash (besteht aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll) für fragmentierte UDP-Pakete und Pakete aller anderen Protokolle |
NONE 2 |
5-Tupel-Hash (besteht aus Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport) für nicht fragmentierte Pakete, die Portinformationen wie TCP-Pakete und nicht fragmentierte UDP-Pakete enthalten OR3-Tupel-Hash (besteht aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll) für fragmentierte UDP-Pakete und Pakete aller anderen Protokolle |
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 |
session affinity
für jeden Zielpool fest.
2 Eine Einstellung für die Sitzungsaffinität von NONE
bedeutet nicht, dass es keine Sitzungsaffinität gibt. Das bedeutet, dass keine Option für die Sitzungsaffinität explizit konfiguriert ist.
Hashing wird immer zur Auswahl eines Backends verwendet. Bei einer Einstellung für die Sitzungsaffinität von NONE
verwendet der Load Balancer einen 5-Tupel-Hash oder einen 3-Tupel-Hash, um Back-Ends auszuwählen. Das ist funktional dasselbe Verhalten wie bei der Einstellung CLIENT_IP_PORT_PROTO
.
Informationen dazu, wie sich die verschiedenen Einstellungen für die Sitzungsaffinität auf die Back-End-Auswahl und die Methoden des Verbindungs-Trackings auswirken, finden Sie in der Tabelle im Abschnitt Modus für das Verbindungs-Tracking.
Tracking-Richtlinie für Verbindungen
In diesem Abschnitt werden die Einstellungen beschrieben, mit denen das Verhalten des Verbindungs-Trackings von externen Passthrough-Network-Load Balancern gesteuert wird. Eine Richtlinie für das Verbindungs-Tracking enthält die folgenden Einstellungen:
- Verbindungs-Tracking-Modus
- Verbindungspersistenz bei fehlerhaften Back-Ends
- Zeitüberschreitung bei Inaktivität
Verbindungs-Tracking-Modus
Wenn die Verbindungsnachverfolgung möglich ist, werden in der Verbindungsnachverfolgungstabelle des Load-Balancers Verbindungstupel in einer Hashtabelle den zuvor ausgewählten Back-Ends zugeordnet. Die Menge der Paketmerkmale, aus denen jedes Verbindungstupel besteht, hängt vom Modus für das Verbindungs-Tracking und der Sitzungsaffinität ab.
Externe Passthrough-Network Load Balancer unterstützen die Verbindungsnachverfolgung basierend auf Protokoll- und Sitzungsaffinitätsoptionen:
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.
Der Modus für das Verbindungs-Tracking bezieht sich auf die Granularität der einzelnen Verbindungstupel in der Tabelle für das Verbindungs-Tracking des Load-Balancers. Das Verbindungstupel kann ein 5-Tupel oder ein 3-Tupel (PER_CONNECTION
-Modus) sein oder der Einstellung für die Sitzungsaffinität entsprechen (PER_SESSION
-Modus).
PER_CONNECTION
: Dies ist der Standardmodus für das Tracking von Verbindungen. In diesem Verbindungs-Tracking-Modus wird ein 5-Tupel-Hash oder ein 3-Tupel-Hash verwendet. Nicht fragmentierte Pakete mit Portinformationen wie TCP-Pakete und nicht fragmentierte UDP-Pakete werden mit 5-Tupel-Hashes erfasst. Alle anderen Pakete werden mit 3‑Tupel-Hashes verfolgt.PER_SESSION
: In diesem Modus für das Verbindungs-Tracking wird ein Hash verwendet, der aus denselben Paketmerkmalen besteht, die auch für den Hash für die Sitzungsaffinität verwendet werden. Je nach gewählter Sitzungsaffinität kannPER_SESSION
dazu führen, dass Verbindungen häufiger mit einem vorhandenen Eintrag in der Verbindungstracking-Tabelle übereinstimmen. Dadurch wird die Häufigkeit reduziert, mit der ein Backend durch den Hash der Sitzungsaffinität ausgewählt werden muss.
In der folgenden Tabelle wird zusammengefasst, wie der Verbindungs-Tracking-Modus und die Sitzungsaffinität zusammenarbeiten, um alle Pakete für jede Verbindung an dasselbe Backend weiterzuleiten.
Backend-Auswahl mit Sitzungsaffinität | Verbindungs-Tracking-Modus | ||
---|---|---|---|
Einstellung für die Sitzungsaffinität | Hash-Methode für die Backend-Auswahl | PER_CONNECTION (Standard) |
PER_SESSION |
Standard
( |
TCP und nicht fragmentiertes UDP: 5-Tupel-Hash Fragmentierte UDP- und alle anderen Protokolle: 3-Tupel-Hash |
|
|
Client-IP, Ziel-IP ( |
Alle Protokolle: 2-Tupel-Hash |
|
|
Client-IP, Ziel-IP, Protokoll ( |
Alle Protokolle: 3-Tupel-Hash |
|
|
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll
( |
TCP und nicht fragmentiertes UDP: 5-Tupel-Hash Fragmentiertes UDP und alle anderen Protokolle: 3-Tupel-Hash |
|
|
Informationen zum Ändern des Verbindungs-Tracking-Modus finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.
Verbindungspersistenz auf fehlerhaften Back-Ends
Die Einstellungen für die Verbindungspersistenz steuern, ob eine vorhandene Verbindung auf einer ausgewählten Back-End-VM oder einem ausgewählten Endpunkt verbleibt, nachdem das Back-End fehlerhaft wird, solange das Back-End in der konfigurierten Back-End-Gruppe des Load-Balancers (in einer 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 werden die Optionen für die Verbindungspersistenz beschrieben und wie die Verbindungen für verschiedene Protokolle, Sitzungsaffinitätsoptionen und Tracking-Modi beibehalten werden.
Option zur Verbindungspersistenz bei fehlerhaften Back-Ends | Verbindungs-Tracking-Modus | |
---|---|---|
PER_CONNECTION |
PER_SESSION |
|
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 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 |
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 ICMP, ICMPv6: nicht zutreffend, da sie nicht über Verbindungs-Tracking erfasst werden können. Diese Option sollte nur für erweiterte Anwendungsfälle verwendet werden. |
Konfiguration nicht möglich |
Verhalten der TCP-Verbindungspersistenz auf fehlerhaften Back-Ends
Wenn eine TCP-Verbindung mit 5-Tupel-Tracking in einem fehlerhaften Back-End bestehen bleibt:
- 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, fehlerfreies Backend auswählen. TCP-SYN-Pakete wählen immer ein neues, fehlerfreies Backend aus.
Informationen zum Ändern des Verhaltens der Verbindungspersistenz finden Sie unter Richtlinie für das Verbindungs-Tracking konfigurieren.
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.
Gewichtetes Load Balancing
Beim gewichteten Load-Balancing für externe Passthrough-Network Load Balancer werden Gewichtungsinformationen verwendet, die von einer HTTP-Systemdiagnose gemeldet werden. Für das gewichtete Load Balancing müssen Sie Folgendes konfigurieren:
- Die Load-Balancer-Richtlinie für den Ort (
localityLbPolicy
) des Backend-Dienstes mussWEIGHTED_MAGLEV
sein. - Für den Backend-Dienst muss eine HTTP-Systemdiagnose verwendet werden.
- Antworten der Systemdiagnose von jeder Backend-VM oder jedem Backend-Endpunkt müssen einen benutzerdefinierten HTTP-Antwortheader enthalten. Der Name des Antwortheaderfelds ist
X-Load-Balancing-Endpoint-Weight
und gültige Feldwerte liegen zwischen0
und1000
.
Wenn Sie dieselbe Instanzgruppe oder NEG als Backend für zwei oder mehr Backend-Dienste verwenden müssen, empfehlen wir die folgende Strategie, damit jede der gemeinsamen Backend-Instanzen oder ‑Endpunkte eindeutige Gewichtungsinformationen für jeden Backend-Dienst bereitstellen kann:
- Verwenden Sie für jeden Backend-Dienst eine eindeutige HTTP-Systemdiagnose. Verwenden Sie beispielsweise einen eindeutigen
request-path
-Parameter für die Systemdiagnose. - Konfigurieren Sie Back-End-Instanzen oder ‑Endpunkte so, dass sie bei jeder Systemdiagnose mit den entsprechenden Gewichtungsinformationen antworten.
Beim gewichteten Load-Balancing werden Backend-VMs oder ‑Endpunkte zuerst nach ihrem Gewicht (größer als null oder gleich null) und dann nach Systemdiagnosen eingestuft. Der Status der Systemdiagnose wird anhand der Erfolgskriterien für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen ermittelt.
Gewicht | Gesund oder ungesund | Rang |
---|---|---|
Gewichtung größer als null | Fehlerfrei | Erste Wahl |
Gewichtung größer als null | Fehlerhaft | Zweite Wahl |
Gewicht ist null | Fehlerfrei | Dritte Wahl |
Gewicht ist null | Fehlerhaft | Vierte (letzte) Wahl |
Weitere Informationen dazu, wie sich das gewichtete Load Balancing darauf auswirkt, welche Back-Ends infrage kommen, finden Sie im Abschnitt Backend-Auswahl und Verbindungs-Tracking in den Schritten Infrage kommende Back-Ends ermitteln und Infrage kommendes Back-End auswählen.
Das gewichtete Load Balancing kann in den folgenden Szenarien verwendet werden:
Wenn einige Verbindungen mehr Daten als andere verarbeiten oder einige Verbindungen länger bestehen als andere, kann die Verteilung der Backend-Last ungleichmäßig sein. Durch die Signalisierung einer niedrigeren Gewichtung pro Instanz kann eine Instanz mit hoher Auslastung den Anteil der neuen Verbindungen verringern und gleichzeitig die bestehenden Verbindungen bedienen.
Wenn ein Backend überlastet ist und die Zuweisung weiterer Verbindungen zum Bruch bestehender Verbindungen führen kann, können solche Verbindungen sich selbst eine Nullgewichtung zuordnen. Durch die Meldung einer Nullgewichtung nimmt eine Backend-Instanz keine neuen Verbindungen mehr an, verarbeitet jedoch weiterhin vorhandene Verbindungen.
Wenn ein Backend vorhandene Verbindungen vor der Wartung schnell bearbeitet, weist es sich selbst eine Nullgewichtung zu. Durch die Meldung einer Nullgewichtung nimmt eine Backend-Instanz keine neuen Verbindungen mehr an, verarbeitet jedoch weiterhin vorhandene Verbindungen.
Weitere Informationen finden Sie unter Gewichtetes Load Balancing konfigurieren.
Verbindungsausgleich
Der Verbindungsausgleich bietet eine konfigurierbare zusätzliche Zeit, damit bestehende Verbindungen in der Verbindungstrackingtabelle des Load-Balancers bestehen bleiben, wenn eine der folgenden Aktionen ausgeführt wird:
- 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. 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 für die oben genannten Aktionen ist standardmäßig deaktiviert. Informationen dazu, wie der Verbindungsausgleich ausgelöst wird und wie Sie ihn aktivieren, finden Sie unter Verbindungsausgleich aktivieren.
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 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:
Konfiguration der Weiterleitungsregel: Verwenden Sie nur eine
UDP
- oderL3_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, umallPorts
aufTrue
einzustellen.Konfiguration des Backend-Diensts: Legen Sie die Sitzungsaffinität des Backend-Diensts auf
CLIENT_IP
(2-Tupel-Hash) oderCLIENT_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 aufPER_SESSION
, damit die Einträge für das Verbindungs-Tracking-Tabellen mit denselben 2-Tupel- oder 3-Tupel-Hashes erstellt werden.
Failover
Sie können einen externen Passthrough-Network-Load Balancer konfigurieren, damit Verbindungen zwischen VM-Instanzen oder Endpunkten in primären Backends (Instanzgruppen oder NEGs) verteilt werden und dann bei Bedarf auf Failover-Backends gewechselt wird. Failover bietet noch eine Methode zur Erhöhung der Verfügbarkeit und ermöglicht gleichzeitig eine bessere Kontrolle darüber, wie Ihre Arbeitslast verwaltet wird, wenn Ihre primären Back-Ends nicht fehlerfrei sind.
Wenn Sie ein Backend zu einem Backend-Dienst eines externen Passthrough-Network-Load-Balancers hinzufügen, ist dieses Backend standardmäßig ein primäres Backend. Sie können ein Back-End als Failover-Back-End festlegen, wenn Sie es dem Back-End-Dienst des Load-Balancers hinzufügen oder den Back-End-Dienst später bearbeiten.
Weitere Informationen dazu, wie Failover für die Back-End-Auswahl und das Verbindungs-Tracking verwendet wird, finden Sie in den Schritten Geeignete Back-Ends identifizieren und Eintrag in der Tabelle für das Verbindungs-Tracking erstellen im Abschnitt Back-End-Auswahl und Verbindungs-Tracking.
Weitere Informationen zur Funktionsweise des Failovers finden Sie unter Failover-Übersicht für externe Passthrough-Network Load Balancer.
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.