Trafficverteilung für interne Passthrough-Network Load Balancer

Auf dieser Seite werden die folgenden Konzepte beschrieben, damit Sie die Verteilung von Traffic durch interne Passthrough-Network Load Balancer besser verstehen und anpassen können: Sitzungsaffinität, Verbindungs-Tracking, UDP-Fragmentierung und Failover.

Wie ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen verteilt, hängt davon ab, ob Sie ein Failover konfiguriert haben:

• Wenn Sie kein Failover konfiguriert haben, verteilt ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen an seine fehlerfreien Backend-VMs, wenn wenigstens eine Backend-VM fehlerfrei ist. Wenn alle Back-End-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Back-Ends. In diesem Fall leitet der Load Balancer jede neue Verbindung an eine fehlerhafte Back-End-VM weiter.

• Wenn Sie ein Failover konfiguriert haben, verteilt ein interner Passthrough-Netzwerk-Load-Balancer neue Verbindungen zwischen VMs in seinem aktiven Pool gemäß einer von Ihnen konfigurierten Failover-Richtlinie. Wenn alle Backend-VMs fehlerhaft sind, können Sie aus folgenden Verhaltensweisen eine auswählen:

  • (Standardeinstellung) Der Load-Balancer verteilt den Traffic nur auf die primären VMs. Dies wird als letztes Mittel unternommen. Die Backup-VMs sind von dieser letztes-Mittel-Verteilung der Verbindungen ausgeschlossen.
  • Der Load-Balancer ist so konfiguriert, dass Traffic unterbrochen wird.

Die Methode zum Verteilen neuer Verbindungen hängt von der Einstellung der Sitzungsaffinität des Load-Balancers ab.

Der Status der Systemdiagnose steuert die Verteilung neuer Verbindungen. Standardmäßig bleiben TCP-Verbindungen auf fehlerhaften Back-Ends bestehen. Weitere Informationen und Anleitungen zum Ändern dieses Verhaltens finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.

Auswahl von Backend und Verbindungs-Tracking

Interne Passthrough-Netzwerk-Load-Balancer verwenden konfigurierbare Algorithmen zur Auswahl von Backend und Verbindungs-Tracking, um zu bestimmen, wie der Traffic an Backend-VMs verteilt wird. Interne Passthrough-Netzwerk-Load-Balancer verwenden den folgenden Algorithmus, um Pakete an Backend-VMs zu verteilen (in seinem aktiven Pool, wenn Sie ein Failover konfiguriert haben):

1. Wenn der Load-Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle hat, der den Eigenschaften eines eingehenden Pakets entspricht, wird das Paket an das Backend gesendet, das durch den Tabelleneintrag in der Verbindungs-Tracking-Tabelle angegeben wird. Das Paket wird als Teil einer zuvor hergestellten Verbindung betrachtet. Es wird daher an die Back-End-VM gesendet, die der Load-Balancer zuvor ermittelt und in seiner Verbindungs-Tracking-Tabelle erfasst hat.

2. Wenn der Load-Balancer ein Paket empfängt, für das er keinen Verbindungs-Tracking-Eintrag hat, führt der Load-Balancer folgende Schritte aus:

   1. Der Load-Balancer wählt ein Backend aus. Der Load-Balancer berechnet einen Hash anhand der konfigurierten Sitzungsaffinität. Anhand dieses Hashs wird ein Backend ausgewählt:

      • Wenn mindestens ein Backend fehlerfrei ist, wählt der Hash eines der fehlerfreien Backends aus.
      • Wenn alle Back-Ends fehlerhaft sind und keine Failover-Richtlinie konfiguriert wurde, wählt der Hash eines der Back-Ends aus.
      • Wenn alle Back-Ends fehlerhaft sind, wird eine Failover-Richtlinie konfiguriert und die Failover-Richtlinie wird nicht so konfiguriert, dass der Traffic in dieser Situation unterbrochen wird. Der Hash wählt dann eines der primären VM-Back-Ends aus.

      Die Standardaffinität NONE verwendet einen 5-Tupel-Hash der Quell-IP-Adresse, des Quellports, der Ziel-IP-Adresse, des Zielports und des Protokolls im Paket.

      Die Backend-Auswahl kann mithilfe eines Hash-Algorithmus angepasst werden, der weniger Informationen verwendet. Informationen zu allen unterstützten Optionen finden Sie unter Optionen für die Sitzungsaffinität.

   2. Der Load-Balancer fügt der Tabelle für das Verbindungs-Tracking einen Eintrag hinzu. Dieser Eintrag zeichnet das ausgewählte Backend für die Verbindung des Pakets auf, sodass alle zukünftigen Pakete von dieser Verbindung an dasselbe Backend gesendet werden. Ob das Verbindungs-Tracking verwendet wird, hängt vom Protokoll ab:

      Bei TCP- und UDP-Paketen ist das Verbindungs-Tracking immer aktiviert und kann nicht deaktiviert werden. Standardmäßig ist das Verbindungs-Tracking 5-Tupel. Es kann aber so konfiguriert werden, dass es weniger als 5-Tupel umfasst.

      Wenn der Verbindungs-Tracking-Hash ein 5-Tupel ist, erstellen TCP-SYN-Pakete immer einen neuen Eintrag in der Tabelle für das Verbindungs-Tracking.
      
      Das standardmäßige 5-Tupel-Verbindungs-Tracking wird in folgenden Fällen verwendet:

      • Tracking-Modus ist PER_CONNECTION (alle Sitzungsaffinitäten), oder
      • Tracking-Modus ist PER_SESSION und die Sitzungsaffinität ist NONE, oder
      • Tracking-Modus ist PER_SESSION und die Sitzungsaffinität ist CLIENT_IP_PORT_PROTO.

      Weitere Informationen darüber, wann das Verbindungs-Tracking aktiviert ist und welche Tracking-Methode beim Aktivieren des Verbindungs-Trackings verwendet wird, finden Sie unter Verbindungs-Tracking-Modus.

      Außerdem sollten Sie Folgendes beachten:

      • Ein Eintrag in der Verbindungs-Tracking-Tabelle läuft standardmäßig nach 600 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmte. Weitere Informationen zum Anpassen der Zeitüberschreitung bei Inaktivität finden Sie im Abschnitt Zeitüberschreitung bei Inaktivität.
      • Je nach Protokoll entfernt der Load-Balancer möglicherweise Verbindungs-Tracking-Tabelleneinträge, wenn Back-Ends fehlerhaft werden. Weitere Informationen dazu und zum Anpassen dieses Verhaltens finden Sie unter Verbindungspersistenz bei fehlerhaften Back-Ends.

Optionen der Sitzungsaffinität

Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Backend-VMs des Load-Balancers. Legen Sie die Sitzungsaffinität fest, wenn Ihre Backend-VMs Statusinformationen für ihre Clients verfolgen müssen. Dies ist eine gängige Anforderung für Webanwendungen.

Die Sitzungsaffinität basiert auf dem Best-Effort-Prinzip.

Interne Passthrough-Netzwerk-Load-Balancer unterstützen die folgenden Optionen für die Sitzungsaffinität, die Sie für den gesamten internen Backend-Dienst und nicht einzeln für jede Backend-Instanzgruppe angeben.

• Keine (NONE) 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport
• Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION). 1-Tupel-Hash, der nur aus der Quell-IP-Adresse erstellt wird.
• Client-IP (CLIENT_IP). 2-Tupel-Hash von Quell-IP-Adresse und Ziel-IP-Adresse. Externe Passthrough-Netzwerk-Load-Balancer rufen diese Sitzungsaffinitätsoption auf: Client-IP, Ziel-IP.
• Client-IP, Ziel-IP, Protokoll (CLIENT_IP_PROTO). 3-Tupel-Hash von Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll
• Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (CLIENT_IP_PORT_PROTO). 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport

Wenn Sie den Load-Balancer nicht als nächsten Hop für eine benutzerdefinierte statische Route verwenden, muss die Ziel-IP-Adresse eines Pakets mit der IP-Adresse der Weiterleitungsregel des Load-Balancers übereinstimmen, damit das Paket an den Load-Balancer gesendet werden kann. Hinweise zur Verwendung des Load-Balancers als nächsten Hop für eine benutzerdefinierte statische Route finden Sie unter Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer als nächster Hop.

Hinweis: Bei internen UDP-Load-Balancern wird das Festlegen der Sitzungsaffinität in der gcloud CLI und in der API unterstützt. Sie können die Sitzungsaffinität für UDP-Traffic nicht über die Google Cloud Console festlegen.

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 Balancer mit nächstem Hop konfigurieren, verwendet der Load-Balancer die gleiche Backend-Auswahl und das Verbindungs-Tracking-Methode wie oben erläutert. 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 hängt der Hash 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 der Verbindungsverfolgung von internen Passthrough-Network Load Balancern gesteuert wird. Eine Richtlinie für das Verbindungs-Tracking umfasst die folgenden Einstellungen:

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

Verbindungs-Tracking-Modus

Im Tracking-Modus wird der Algorithmus für das Verbindungs-Tracking angegeben, der verwendet werden soll. Es gibt zwei Tracking-Modi: PER_CONNECTION (Standard) und PER_SESSION.

• PER_CONNECTION (Standard). In diesem Modus werden TCP- und UDP-Traffic immer pro 5-Tupel verfolgt, unabhängig von der Einstellung der Sitzungsaffinität. Dies bedeutet, dass sich der Schlüssel für das Verbindungs-Tracking (5-Tupel) von der konfigurierten Einstellung der Sitzungsaffinität unterscheiden kann (z. B. 3-Tupel mit der Einstellung CLIENT_IP_PROTO). Dadurch kann die Sitzungsaffinität aufgeteilt werden und neue Verbindungen für eine Sitzung können ein anderes Backend auswählen, wenn sich der Backend-Satz oder ihr Zustand ändern.

• PER_SESSION. In diesem Modus wird TCP- und UDP-Traffic gemäß der konfigurierten Sitzungsaffinität erfasst. Das heißt, wenn die Sitzungsaffinität CLIENT_IP oder CLIENT_IP_PROTO ist, führt das Konfigurieren dieses Modus zu einem 2-Tupel- oder 3-Tupel-Verbindungs-Tracking. Dies kann in Szenarien wünschenswert sein, in denen die Unterbrechung der Affinität teuer ist, und sollte vermieden werden, auch nachdem mehr Back-Ends hinzugefügt wurden.

Die Einstellung für den Verbindungs-Tracking-Modus ist redundant, wenn die Sitzungsaffinität auf NONE oder CLIENT_IP_PORT_PROTO festgelegt ist. Informationen zur Funktionsweise dieser Tracking-Modi mit unterschiedlichen Einstellungen für die Sitzungsaffinität für jedes Protokoll finden Sie in der folgenden Tabelle.

Backend-Auswahl		Verbindungs-Tracking-Modus
Einstellung für die Sitzungsaffinität	Hash-Methode für die Backend-Auswahl	PER_CONNECTION (Standard)	PER_SESSION
Standard: Keine Sitzungsaffinität NONE	5-Tupel-Hash	5-Tupel-Verbindungs-Tracking	5-Tupel-Verbindungs-Tracking
Client-IP, kein Ziel CLIENT_IP_NO_DESTINATION	1-Tupel-Hash	5-Tupel-Verbindungs-Tracking	1-Tupel-Verbindungs-Tracking
Client-IP CLIENT_IP (entspricht der Client-IP, der Ziel-IP für externe Netzwerk-Load-Balancer im Netzwerk)	2-Tupel-Hash	5-Tupel-Verbindungs-Tracking	2-Tupel-Verbindungs-Tracking
Client-IP, Ziel-IP, Protokoll CLIENT_IP_PROTO	3-Tupel-Hash	5-Tupel-Verbindungs-Tracking	3-Tupel-Verbindungs-Tracking
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll CLIENT_IP_PORT_PROTO	5-Tupel-Hash	5-Tupel-Verbindungs-Tracking	5-Tupel-Verbindungs-Tracking

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

Verbindungspersistenz auf fehlerhaften Back-Ends

Die Einstellung für die Verbindungspersistenz bei fehlerhaften Backends steuert, ob eine vorhandene Verbindung auf einem ausgewählten Backend bestehen bleibt, nachdem dieses Backend fehlerhaft wird (solange das Backend in der konfigurierten Backend-Instanzgruppe des Load-Balancers verbleibt).

Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Backend-VM aus der Instanzgruppe oder die Instanzgruppe aus dem Backend-Dienst entfernen. In solchen Fällen bleiben vorhandene Verbindungen nur bestehen, wie unter Verbindungsausgleich aktivieren beschrieben.

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). UDP: Verbindungen bleiben auf fehlerhaften Back-Ends nicht bestehen	TCP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, wenn die Sitzungsaffinität NONE oder CLIENT_IP_PORT_PROTO ist. UDP: Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen
NEVER_PERSIST	TCP-, UDP-Verbindungen bleiben auf fehlerhaften Back-Ends nie bestehen
ALWAYS_PERSIST	TCP, UDP: Verbindungen bleiben auf fehlerhaften Back-Ends bestehen (alle Sitzungsaffinitäten). Diese Option sollte nur für erweiterte Anwendungsfälle verwendet werden.	Konfiguration nicht möglich

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

Note: When the load balancer moves a connection from an unhealthy backend, the load balancer creates a new tracking table entry. Der neue Eintrag ordnet die Verbindung basierend auf der konfigurierten Sitzungsaffinität einem anderen Backend zu. Der neue Eintrag bleibt wie jeder andere Eintrag gültig. Wenn das fehlerhafte Backend wieder fehlerfrei ist, führt dies nicht dazu, dass der Tabelleneintrag für das Verbindungs-Tracking entfernt wird (es sei denn, er löst ein Failback aus und der Verbindungsausgleich bei Failover und Failback wurde deaktiviert.

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

Beachten Sie beim Testen von Verbindungen zur IP-Adresse eines internen Passthrough-Network Load Balancers, der nur einen Client hat, Folgendes:

• 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 (d. h. der Client-VM) beantwortet. 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 wird in den folgenden Fällen auf vorhandene Verbindungen angewendet:

• Eine VM oder ein Endpunkt wird aus einem Backend (Instanzgruppe oder NEG) entfernt.
• Ein Backend entfernt eine VM oder einen Endpunkt (durch Ersetzen, Verwerfen, Rolling Upgrades oder Herunterskalieren).

Der Verbindungsausgleich ist standardmäßig deaktiviert. Wenn diese Option deaktiviert ist, werden bestehende Verbindungen so schnell wie möglich beendet. Wenn der Verbindungsausgleich aktiviert ist, können bestehende Verbindungen für ein konfigurierbares Zeitlimit beibehalten werden, nach dem die Back-End-VM-Instanz beendet wird.

Weitere Informationen zum Auslösen des Verbindungsausgleichs und zum Aktivieren des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

UDP-Fragmentierung

Interne Passthrough-Netzwerk-Load-Balancer können sowohl fragmentierte als auch nicht fragmentierte UDP-Pakete verarbeiten. Wenn Ihre Anwendung fragmentierte UDP-Datenpakete verwendet, beachten Sie Folgendes:

• UDP-Pakete können fragmentiert werden, bevor sie ein Google Cloud-VPC-Netzwerk erreichen.
• Google Cloud VPC-Netzwerke leiten UDP-Fragmente direkt bei Eingang weiter (ohne auf alle Fragmente zu warten).
• Nicht-Google Cloud -Netzwerke und lokale Netzwerkgeräte können eingehende UDP-Fragmente bei Eingang weiterleiten, fragmentierte UDP-Pakete verzögern, bis alle Fragmente eingegangen sind, oder fragmentierte UDP-Pakete verwerfen. Weitere Informationen finden Sie in der Dokumentation des Netzwerkanbieters oder der Netzwerkgeräte.

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

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

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

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

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.

Eine detaillierte konzeptionelle Übersicht über das Failover in internen Passthrough-Netzwerk-Load-Balancern finden Sie unter Failover für interne Netzwerk-Passthrough-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.