Trafficverteilung für interne Passthrough-Network Load Balancer

Auf dieser Seite werden Konzepte zum Traffic-Verteilungsmechanismus interner Passthrough-Network Load Balancer erläutert.

Auswahl von Backend und Verbindungs-Tracking

Die Backendauswahl und das Verbindungs-Tracking arbeiten zusammen, um mehrere Verbindungen über verschiedene Backends auszugleichen und alle Pakete für jede Verbindung an dasselbe Backend weiterzuleiten. Dazu wird eine zweiteilige Strategie verwendet. Zuerst wird mithilfe einer konsistenten Hash-Technologie ein Back-End ausgewählt. Diese Auswahl wird dann in einer Verbindungs-Tracking-Tabelle aufgezeichnet.

In den folgenden Schritten wird der Prozess der Back-End-Auswahl und des Verbindungs-Trackings beschrieben.

1. Prüfen Sie, ob ein Eintrag in der Tabelle zur Nachverfolgung von Verbindungen vorhanden ist, um ein zuvor ausgewähltes Back-End zu verwenden.

Bei einer vorhandenen Verbindung verwendet der Load Balancer die Verbindungs-Tracking-Tabelle, um das zuvor ausgewählte Back-End für diese Verbindung zu ermitteln.

Der Load Balancer versucht, jedes mit Load Balancing versehene Paket mit einem Eintrag in der Tabelle für das Verbindungs-Tracking abzugleichen. Dazu wird der folgende Prozess verwendet:

• Wenn das Paket ein TCP-Paket mit dem Flag SYN ist:

  • Wenn der Verbindungs-Tracking-Modus des Load Balancers PER_CONNECTION ist, fahren Sie mit dem Schritt Geeignete Backends ermitteln fort. Im PER_CONNECTION-Tracking-Modus stellt ein TCP-Paket mit dem SYN-Flag unabhängig von der konfigurierten Sitzungsaffinität immer eine neue Verbindung dar.

  • Wenn der Verbindungs-Tracking-Modus des Load Balancers PER_SESSION ist und die Sitzungsaffinität entweder NONE oder CLIENT_IP_PORT_PROTO ist, fahren Sie mit dem Schritt Geeignete Backends ermitteln fort. Im PER_SESSION-Tracking-Modus stellt ein TCP-Paket mit dem SYN-Flag nur dann eine neue Verbindung dar, wenn eine der 5-Tupel-Optionen für die Sitzungsaffinität (NONE oder CLIENT_IP_PORT_PROTO) verwendet wird.

• Bei allen anderen Paketen prüft der Load Balancer, ob das Paket mit einem vorhandenen Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmt. Das Verbindungs-Tupel (eine Reihe von Paketmerkmalen), mit dem das Paket mit vorhandenen Einträgen in der Verbindungs-Tracking-Tabelle verglichen wird, hängt vom konfigurierten Verbindungs-Tracking-Modus und der Sitzungsaffinität ab. Informationen dazu, welches Verbindungs-Tupel 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 und unter welchen Bedingungen ein Eintrag in der Tabelle für das Verbindungs-Tracking gespeichert bleibt, finden Sie im Schritt Eintrag in der Tabelle für das Verbindungs-Tracking erstellen.

2. Wählen Sie ein geeignetes Backend für eine neue Verbindung aus.

Bei einer neuen Verbindung wählt der Load Balancer mithilfe des Consistent Hashing-Algorithmus ein Back-End aus den infrage kommenden Back-Ends aus dem aktiven Pool 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 Verbindungs-Tracking-Tabelle aufzeichnen.

2.1 Eligible Backends identifizieren

In diesem Schritt wird modelliert, welche Back-Ends neue Verbindungen erhalten können. Dabei werden der Systemstatus und die Konfiguration der Failover-Richtlinie berücksichtigt:

• Keine Failover-Richtlinie: Die infrage kommenden Back-Ends hängen nur von den Systemdiagnosen ab:

  • Wenn mindestens ein Back-End fehlerfrei ist, besteht die Gruppe der infrage kommenden Back-Ends aus allen fehlerfreien Back-Ends.

  • Wenn alle Back-Ends fehlerhaft sind, besteht die Gruppe der infrage kommenden Back-Ends aus allen Back-Ends.

• Failover-Richtlinie konfiguriert: Die infrage kommenden Back-Ends hängen von den Systemdiagnosen und der Konfiguration der Failover-Richtlinie ab:

  • Wenn mindestens ein Backend fehlerfrei ist, besteht die Gruppe der infrage kommenden Backends aus allen fehlerfreien Backends im aktiven Pool.

    • Der aktive Pool kann aus allen fehlerfreien primären Back-Ends oder aus allen fehlerfreien Failover-Back-Ends bestehen. Die Mitgliedschaft im aktiven Pool wird durch das konfigurierte Failover-Verhältnis, die Anzahl der fehlerfreien primären Back-Ends und die Gesamtzahl der primären Back-Ends bestimmt.

    • Unabhängig von der Failover-Quote besteht der aktive Pool aus allen fehlerfreien primären Back-Ends, wenn es keine fehlerfreien Failover-Back-Ends gibt, aber mindestens ein fehlerfreies primäres Back-End vorhanden ist.

  • Wenn es keine fehlerfreien Back-Ends gibt und die Failover-Richtlinie des Load Balancers so konfiguriert ist, dass neue Verbindungen abgelehnt werden, ist die Gruppe der infrage kommenden Back-Ends in diesem Fall leer. Der Load Balancer verwirft die Pakete für die Verbindung.

  • Wenn es keine fehlerfreien Back-Ends gibt und die Failover-Richtlinie des Load Balancers nicht so konfiguriert ist, dass neue Verbindungen unterbrochen werden, sind Systemdiagnosen in dieser Situation nicht relevant. Zu den infrage kommenden Back-Ends gehören alle primären Back-Ends.

2.2 Wählen Sie ein geeignetes Backend aus.

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. Bei der Verarbeitung eines Pakets für eine Verbindung, die nicht in der Verbindungs-Tracking-Tabelle enthalten ist, berechnet der Load Balancer einen Hashwert der Paketmerkmale und ordnet diesen Hashwert demselben Einheitskreis zu. Dabei wird ein geeignetes Backend auf dem Umfang des Kreises ausgewählt. Die Paketmerkmale, die zur Berechnung des Paket-Hashwerts verwendet werden, werden durch die Sitzungsaffinitätseinstellung definiert.

• Wenn keine Sitzungsaffinität explizit konfiguriert ist, ist die Sitzungsaffinität NONE standardmäßig aktiv.

• Der Load Balancer weist neuen Verbindungen infrage kommende Back-Ends so zu, dass dies so konsistent wie möglich erfolgt, auch wenn sich die Anzahl der infrage kommenden Back-Ends ändert. Die folgenden Vorteile von Consistent Hashing zeigen, wie der Load Balancer geeignete Back-Ends für mögliche neue Verbindungen auswählt, die keine Einträge in der Tabelle für das Verbindungs-Tracking haben:

  • Der Load Balancer wählt dasselbe Backend für alle möglichen neuen Verbindungen aus, die die gleichen Paketmerkmale haben, wie von der Sitzungsaffinität definiert, wenn sich die zulässigen Backends nicht ändern.

  • Wenn ein neues infrage kommendes Backend hinzugefügt wird, werden dem neu hinzugefügten Backend etwa 1/N mögliche neue Verbindungen zugeordnet. In diesem Fall ist N die Anzahl der infrage kommenden Back-Ends nach dem Hinzufügen des neuen Back-Ends.

  • Wenn ein infrage kommendes Backend entfernt wird, werden etwa 1/N mögliche neue Verbindungen einem der N-1 verbleibenden Backends zugeordnet. In diesem Fall ist N die Anzahl der Backends vor dem Entfernen des entsprechenden Backends.

2.3 Erstellen Sie einen Eintrag in der Verbindungs-Tracking-Tabelle.

Nach der Auswahl eines Back-Ends erstellt der Load Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle. Der Eintrag in der Verbindungs-Tracking-Tabelle ordnet Paketeigenschaften dem ausgewählten Backend zu. Die für diese Zuordnung verwendeten Paketheaderfelder hängen vom konfigurierten Verbindungs-Tracking-Modus und der Sitzungsaffinität ab.

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 inaktiv war. Sofern Sie kein benutzerdefiniertes Zeitlimit für die Inaktivität konfigurieren, verwendet der Load Balancer ein Standardzeitlimit von 600 Sekunden. 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- oder RST-Paket geschlossen wird. Jede neue TCP-Verbindung trägt immer das SYN-Flag und wird wie im Schritt Nach einem Eintrag in der Tabelle für das Verbindungs-Tracking suchen beschrieben verarbeitet.

• Wenn eine Failover-Richtlinie konfiguriert ist und die Einstellung für den Verbindungsausgleich bei Failover und Failback deaktiviert ist, entfernt der Load Balancer alle Einträge in der Verbindungs-Tracking-Tabelle, wenn sich der aktive Pool während des Failovers oder Failbacks ändert. Weitere Informationen finden Sie unter Verbindungsausgleich bei Failover und Failback.

• Einträge in der Verbindungs-Tracking-Tabelle können entfernt werden, wenn ein Back-End fehlerhaft wird. Dieses Verhalten hängt vom Verbindungs-Tracking-Modus, vom Protokoll und von der Einstellung „Verbindungspersistenz bei fehlerhaften Back-Ends“ ab. Weitere Informationen finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.

• Einträge in der Tabelle für die Verbindungsverfolgung werden nach Ablauf des Zeitlimits für den Verbindungsausgleich entfernt, das nach einem Ereignis auftritt, z. B. nach dem Löschen einer Back-End-VM oder dem Entfernen einer Back-End-VM aus einer Instanzgruppe oder NEG. 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. Interne Passthrough-Netzwerk-Load Balancer verwenden die Sitzungsaffinität, um ein Backend aus einer Gruppe infrage kommender Backends auszuwählen, wie in den Schritten Infrage kommende Backends ermitteln und Infrage kommendes Backend auswählen im Abschnitt Backendauswahl 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.

Interne 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. Mit der Einstellung für die Sitzungsaffinität wird festgelegt, welche Felder aus dem IP-Header und den Headern der Schicht 4 zum Berechnen des Hashwerts verwendet werden.

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

Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer für den nächsten Hop

Wenn Sie eine statische Route für die Verwendung eines internen Passthrough-Network Load Balancers mit nächstem Hop konfigurieren, verwendet der Load Balancer die gleiche Backend-Auswahl und das Verbindungs-Tracking-Methode. Die Back-End-Auswahl erfolgt weiterhin durch das Berechnen eines Hashwerts anhand der konfigurierten Sitzungsaffinität. Mit Ausnahme der CLIENT_IP_NO_DESTINATION-Sitzungsaffinität (1-Tupel-Hash) hängt der Hashwert für die Backendauswahl teilweise von der Ziel-IP-Adresse des Pakets ab.

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

Wenn die Anzahl der konfigurierten und fehlerfreien Back-End-VMs konstant ist (d. h., wenn das Failover entweder nicht konfiguriert ist oder wenn das Failover konfiguriert ist, aber keine Failover- oder Failback-Ereignisse auftreten), verhält sich der Load Balancer so:

• Wenn es nur eine konfigurierte und fehlerfreie Back-End-VM gibt (im aktiven Pool, wenn das Failover konfiguriert ist), spielt es keine Rolle, welche Sitzungsaffinität Sie verwenden, da alle Hashes der einen Back-End-VM zugeordnet sind.

• Wenn es zwei oder mehr konfigurierte und fehlerfreie Back-End-VMs gibt (im aktiven Pool, wenn ein Failover konfiguriert ist), ist die Wahl der Sitzungsaffinität wichtig:

  • Wenn dieselbe Back-End-VM alle Pakete von einem Client verarbeiten soll, basierend ausschließlich auf der Quell-IP-Adresse des Pakets, unabhängig von den Ziel-IP-Adressen des Pakets, verwenden Sie die Sitzungsaffinität CLIENT_IP_NO_DESTINATION. Je nach Traffic-Mustern erhalten einige Back-End-VMs möglicherweise mehr Pakete oder Verbindungen als andere Back-End-VMs.

  • Wenn Sie eine Option für die Sitzungsaffinität verwenden, die nicht CLIENT_IP_NO_DESTINATION ist, wählt der Load-Balancer eine Back-End-VM anhand von Informationen aus, die mindestens sowohl Die Quell-IP-Adresse sowie Die Ziel-IP-Adresse des Pakets enthalten. Pakete, die vom selben Client mit derselben Quell-IP-Adresse, aber unterschiedlichen Ziel-IP-Adressen gesendet werden, können an verschiedene Backend-VMs weitergeleitet werden.

Tracking-Richtlinie für Verbindungen

In diesem Abschnitt werden die Einstellungen beschrieben, mit denen das Verhalten des Verbindungs-Trackings von internen 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

Die Tabelle für das Verbindungs-Tracking des Load Balancers ordnet Verbindungs-Tupel zuvor ausgewählten Backends in einer Hash-Tabelle zu. Die Paketmerkmale, aus denen jedes Verbindungs-Tupel besteht, werden durch den Modus für das Verbindungs-Tracking und die Sitzungsaffinität bestimmt.

Interne Passthrough-Network Load Balancer erfassen Verbindungen für alle unterstützten Protokolle.

Der Verbindungs-Tracking-Modus bezieht sich auf die Detaillierung der einzelnen Verbindungs-Tupel in der Verbindungs-Tracking-Tabelle des Load Balancers. Das Verbindungs-Tupel 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 Verbindungs-Tracking. Bei diesem Verbindungs-Tracking-Modus wird ein 5-Tupel-Hash oder ein 3-Tupel-Hash verwendet. Nicht fragmentierte Pakete mit Portinformationen wie TCP- und nicht fragmentierte UDP-Pakete werden mit 5-Tupel-Hashes erfasst. Alle anderen Pakete werden mit 3-Tupel-Hashes erfasst.

• PER_SESSION. Bei diesem Modus für das Verbindungs-Tracking wird ein Hash verwendet, der aus denselben Paketmerkmalen besteht, die auch für den Hash der Sitzungsaffinität verwendet werden. Je nach ausgewählter Sitzungsaffinität kann PER_SESSION zu Verbindungen führen, die häufiger mit einem vorhandenen Eintrag in der Verbindungs-Tracking-Tabelle übereinstimmen. Dadurch wird die Häufigkeit verringert, mit der ein Backend durch den Sitzungsaffinitäts-Hash 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.

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.

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

Zeitüberschreitung bei Inaktivität

Ein Eintrag in der Tabelle für das Verbindungs-Tracking läuft standardmäßig nach 600 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmte. Dieser Standardwert für die Zeitüberschreitung bei Inaktivität kann nur geändert werden, wenn das Verbindungs-Tracking weniger als 5-Tupel beträgt (d. h., wenn die Sitzungsaffinität entweder als CLIENT_IP oder CLIENT_IP_PROTO konfiguriert und der Tracking-Modus PER_SESSION ist).

Der maximal konfigurierbare Wert für die Zeitüberschreitung bei Inaktivität beträgt 57.600 Sekunden (16 Stunden).

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

Verbindungen für Bereitstellungen mit einem einzelnen Client

Beim Testen von Verbindungen zur IP-Adresse eines internen Passthrough-Netzwerk-Load Balancers, der nur einen Client hat, sollten Sie Folgendes beachten:

• Wenn die Client-VM keine VM ist, für die das Load Balancing aktiviert ist, d. h. sie keine Back-End-VM ist, werden neue Verbindungen an die fehlerfreien Back-End-VMs des Load Balancers weitergeleitet. Da jedoch alle Optionen für die Sitzungsaffinität mindestens auf der IP-Adresse des Clientsystems basieren, werden Verbindungen vom selben Client möglicherweise häufiger als erwartet an dieselbe Back-End-VM verteilt.

  Praktisch bedeutet dies, dass Sie die Trafficverteilung über einen internen Passthrough-Netzwerk-Load-Balancer nicht genau überwachen können, indem Sie über einen einzigen Client eine Verbindung zu ihm herstellen. Die Anzahl der Clients, die zur Überwachung der Trafficverteilung benötigt werden, hängt vom Typ des Load-Balancers, der Art des Traffics und der Anzahl fehlerfreier Back-Ends ab.

• Wenn die Client-VM auch eine Back-End-VM des Load Balancers ist, werden Verbindungen, die an die IP-Adresse der Weiterleitungsregel des Load Balancers gesendet werden, immer von derselben Back-End-VM beantwortet, die auch die Client-VM ist. Dies geschieht unabhängig davon, ob die Back-End-VM fehlerfrei ist. Dies gilt für den gesamten Traffic, der an die IP-Adresse des Load Balancers gesendet wird, nicht nur für den Traffic für das Protokoll und die Ports, die in der internen Weiterleitungsregel des Load Balancers angegeben sind.

  Weitere Informationen finden Sie unter Anfragen von VMs mit Load-Balancing senden.

Verbindungsausgleich

Der Verbindungsausgleich bietet eine konfigurierbare zusätzliche Zeit, damit bestehende Verbindungen in der Verbindungs-Tracking-Tabelle des Load Balancers verbleiben, wenn eine der folgenden Aktionen ausgeführt wird:

• Eine VM-Instanz wird aus einer Back-End-Instanzgruppe entfernt (einschließlich des Verwerfens einer Instanz in einer vom Back-End verwalteten Instanzgruppe)
• Eine VM wird beendet oder gelöscht (einschließlich automatischer Aktionen wie Rolling Updates oder Herunterskalieren einer verwalteten Instanzgruppe im Backend)
• Ein Endpunkt wird aus einer Backend-Netzwerk-Endpunktgruppe (NEG) entfernt

Der Verbindungsausgleich für die oben genannten Aktionen ist standardmäßig deaktiviert. Weitere Informationen zum Auslösen des Verbindungsausgleichs und zum Aktivieren des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

UDP-Fragmentierung

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

Failover

Mit einem internen Passthrough-Netzwerk-Load-Balancer können Sie einige Back-Ends als Failover-Back-Ends festlegen. Diese Backends werden nur verwendet, wenn die Anzahl der fehlerfreien VMs in den primären Backend-Instanzgruppen unter einem konfigurierbaren Schwellenwert liegt. Wenn alle primären und Failover-VMs fehlerhaft sind, verteiltGoogle Cloud standardmäßig als letztes Mittel neue Verbindungen nur auf alle primären VM.

Wenn Sie ein Backend zu einem Backend-Dienst eines internen Passthrough-Netzwerk-Load-Balancers hinzufügen, ist standardmäßig das Backend ein primäres Backend. Sie können ein Backend als Failover-Backend festlegen, wenn Sie es dem Backend-Dienst des Load-Balancers hinzufügen oder den Backend-Dienst später bearbeiten.

Weitere Informationen dazu, wie das Failover für die Backend-Auswahl und das Verbindungs-Tracking verwendet wird, finden Sie im Abschnitt Backend-Auswahl und Verbindungs-Tracking unter Geeignete Backends ermitteln und Eintrag in der Verbindungs-Tracking-Tabelle erstellen.

Weitere Informationen zur Funktionsweise des Failovers finden Sie unter Failover für interne Passthrough-Network Load Balancer.

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.