Auf dieser Seite werden die folgenden Konzepte beschrieben, damit Sie besser nachvollziehen und anpassen können, wie externe Passthrough-Network Load Balancer den Traffic verteilen: Sitzungsaffinität, Verbindungs-Tracking, gewichtetes Load Balancing, Verbindungsentleerung, UDP-Fragmentierung und Failover.
Wie externe Passthrough-Netzwerk-Load-Balancer neue Netzwerkverbindungen verteilen, hängt davon ab, ob Sie ein Failover konfiguriert haben:
- Wenn Sie kein Failover konfiguriert haben, verteilt ein interner Passthrough-Network-Load Balancer neue Verbindungen an seine fehlerfreien Backend-VMs, wenn wenigstens eine Backend-VM fehlerfrei ist. Wenn alle Backend-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Backends. In diesem Fall leitet der Load-Balancer jede neue Verbindung an eine fehlerhafte Backend-VM weiter.
- Wenn Sie einen Failover konfiguriert haben, verteilt ein externer Passthrough-Netzwerk-Load-Balancer gemäß einer von Ihnen konfigurierten Failover-Richtlinie neue Verbindungen zwischen fehlerfreien Backend-VMs in seinem aktiven Pool. When all backend VMs are unhealthy, you
can choose from one of the following behaviors:
- (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 verwirft den Traffic.
Weitere Informationen zur Verteilung von Verbindungen finden Sie im nächsten Abschnitt: Back-End-Auswahl und Verbindungs-Tracking.
Weitere Informationen zur Funktionsweise des Failovers finden Sie im Abschnitt Failover.
Auswahl von Backend und Verbindungs-Tracking
Externe 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.
Externe Passthrough-Netzwerk-Load-Balancer verwenden den folgenden Algorithmus, um Pakete zwischen Backend-VMs zu verteilen (in seinem aktiven Pool, wenn Sie ein Failover konfiguriert haben):
- 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.
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:
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 aus den Backends ausgewählt, die fehlerfrei sind, es sei denn, alle Backends sind fehlerhaft. In diesem Fall werden alle Backends so lange berücksichtigt, wie die Failover-Richtlinie in dieser Situation nicht dafür konfiguriert wurde, den Traffic zu unterbrechen. Die Standard-Sitzungsaffinität,
NONE, verwendet die folgenden Hash-Algorithmen:- Bei TCP- und nicht fragmentierten UDP-Paketen ein 5-Tupel-Hash der Quell-IP-Adresse des Pakets, des Quellports, der Ziel-IP-Adresse, des Zielports und des Protokolls.
- Für fragmentierte UDP-Pakete und alle anderen Protokolle ein 3-Tupel-Hash der Quell-IP-Adresse des Pakets, der Ziel-IP-Adresse und des Protokolls.
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.
Außerdem sollten Sie Folgendes beachten:
Wenn Sie das gewichtete Load-Balancing aktivieren, wird die hashbasierte Backend-Auswahl basierend auf den von den Backend-Instanzen gemeldeten Gewichtungen gewichtet. Beispiel:
- Betrachten Sie einen Backend-Dienst, für den die Sitzungsaffinität auf
NONEgesetzt ist und eine Weiterleitungsregel mit dem ProtokollUDPkonfiguriert wurde. Sind zwei fehlerfreie Backend-Instanzen mit den Gewichtungen 1 und 4 vorhanden, erhalten die Backends 20 %, bzw. 80 % der UDP-Pakete. - Betrachten Sie einen Backend-Dienst, der mit 3-Tupel-Sitzungsaffinität und Verbindungs-Tracking konfiguriert ist.
Die Sitzungsaffinität ist
CLIENT_IP_PROTOund der Modus für das Verbindungs-Tracking istPER_SESSION. Sind drei fehlerfreie Backend-Instanzen mit den Gewichtungen 0, 2 und 6 vorhanden, erhalten die Backends Traffic für 0 %, 25 % und 75 % der neuen Quell-IP-Adressen (die Quell-IP-Adressen für die keine Tabelleneinträge für das Verbindungs-Tracking vorhanden sind). Der Traffic für vorhandene Verbindungen wird an die zuvor zugewiesenen Back-Ends weitergeleitet.
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:
TCP-Pakete. Verbindungs-Tracking ist immer aktiviert und kann nicht deaktiviert werden. Standardmäßig verwendet das Verbindungs-Tracking ein 5-Tupel. Es kann aber so konfiguriert werden, dass es weniger als ein 5-Tupel verwendet. Beim 5-Tupel werden TCP-SYN-Pakete unterschiedlich behandelt. Im Gegensatz zu Nicht-SYN-Paketen werden alle übereinstimmenden Verbindungs-Tracking-Einträge verworfen und es wird immer ein neues Backend ausgewählt.
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_SESSIONund die Sitzungsaffinität istNONE, oder - Tracking-Modus ist
PER_SESSIONund die Sitzungsaffinität istCLIENT_IP_PORT_PROTO.
- Tracking-Modus ist
UDP-, ESP- und GRE-Pakete. Das Verbindungs-Tracking ist nur aktiviert, wenn die Sitzungsaffinität auf etwas anderes als
NONEfestgelegt ist.ICMP- und ICMPv6-Pakete. Verbindungs-Tracking kann nicht verwendet werden.
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 Tabelle für das Verbindungs-Tracking läuft 60 Sekunden ab, nachdem der Load-Balancer das letzte Paket verarbeitet hat, das mit dem Eintrag übereinstimmt. Weitere Informationen finden Sie unter 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 Back-End-VMs des Load-Balancers. Die Sitzungsaffinität wird für den gesamten regionalen externen Backend-Dienst und nicht für jedes Backend angegeben.
Externe Passthrough-Network Load Balancer unterstützen die folgenden Optionen für die Sitzungsaffinität:
- Keine (
NONE) 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport - Client-IP, Ziel-IP (
CLIENT_IP). 2-Tupel-Hash von Quell-IP-Adresse und Ziel-IP-Adresse - 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
Informationen dazu, wie sich diese Optionen der Sitzungsaffinität auf die Back-End-Auswahl und die Methoden des Verbindungs-Trackings auswirken, finden Sie in dieser Tabelle.
Tracking-Richtlinie für Verbindungen
In diesem Abschnitt werden die Einstellungen beschrieben, mit denen das Verhalten der Verbindungsverfolgung externer Passthrough-Network Load Balancer gesteuert wird. Eine Richtlinie für das Verbindungs-Tracking umfasst die folgenden Einstellungen:
Verbindungs-Tracking-Modus
Ob das Verbindungs-Tracking aktiviert ist, hängt nur vom Protokoll des Traffics mit Load-Balancing und den Einstellungen der Sitzungsaffinität ab. Im Tracking-Modus wird der Algorithmus für das Verbindungs-Tracking angegeben, der verwendet werden soll, wenn das Verbindungs-Tracking aktiviert ist. Es gibt zwei Tracking-Modi: PER_CONNECTION (Standard) und PER_SESSION.
PER_CONNECTION(Standard). Dies ist der Standard-Tracking-Modus. Bei diesem Verbindungs-Tracking-Modus wird TCP-Traffic immer über ein 5-Tupel verfolgt, unabhängig von der Einstellung der Sitzungsaffinität. Für UDP-, ESP- und GRE-Traffic ist das Verbindungs-Tracking aktiviert, wenn die ausgewählte Sitzungsaffinität nichtNONEist. UDP-, ESP- und GRE-Pakete werden mit den in dieser Tabelle beschriebenen Tracking-Methoden verfolgt.PER_SESSION. Wenn die SitzungsaffinitätCLIENT_IPoderCLIENT_IP_PROTOist, führt das Konfigurieren dieses Modus zu einem 2-Tupel- und 3-Tupel-Verbindungs-Tracking. Alle Protokolle (außer ICMP und ICMPv6, die nicht über die Verbindung nachverfolgbar sind). Bei anderen Einstellungen für die Sitzungsaffinität verhält sich derPER_SESSION-Modus identisch zumPER_CONNECTION-Modus.
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
( |
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.
Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Back-End-Instanz aus einer Instanzgruppe entfernt oder einen Back-End-Endpunkt aus ihrer NEG entfernt oder die Instanzgruppe oder die NEG vom Backend-Dienst entfernt haben. In solchen Fällen bleiben vorhandene Verbindungen nur bestehen, wie unter Verbindungsausgleich beschrieben.
Die folgenden Optionen für die Verbindungspersistenz sind verfügbar:
DEFAULT_FOR_PROTOCOL(Standard)NEVER_PERSISTALWAYS_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 nach dem Verarbeiten des letzten Pakets durch den Load Balancer ab, das mit dem Eintrag übereinstimmt. Der Wert für dieses Zeitlimit kann nicht geändert werden.
Gewichtetes Load Balancing
Sie können einen Network-Load Balancer so konfigurieren, dass der Traffic auf den Backend-Instanzen des Load Balancers basierend auf den von einer HTTP-Systemdiagnose gemeldeten Gewichtungen mit gewichtetem Load Balancing verteilt wird.
Für das gewichtete Load Balancing müssen Sie Folgendes konfigurieren:
- Sie müssen die Ort-Load Balancer-Richtlinie (
localityLbPolicy) des Backend-Dienstes aufWEIGHTED_MAGLEVfestlegen. - Sie müssen den Backend-Dienst mit einer HTTP-Systemdiagnose konfigurieren. Die Antworten der HTTP-Systemdiagnose müssen das benutzerdefinierte Feld
X-Load-Balancing-Endpoint-Weightdes HTTP-Antwortheaders enthalten, um die Gewichtungen mit Werten von0bis1000pro Backend-Instanz anzugeben.
Wenn Sie dasselbe Backend (Instanzgruppe oder NEG) für mehrere Backend-Dienst-basierte externe Passthrough-Network Load Balancer mit gewichtetem Load-Balancing verwenden, empfehlen wir die Verwendung eines eindeutigen request-path für jede Systemdiagnose des Backends. Dadurch kann die Endpunktinstanz verschiedenen Backend-Diensten unterschiedliche Gewichtungen zuweisen. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen.
Zur Auswahl eines Backends für eine neue Verbindung wird Backends eine strenge Prioritätsreihenfolge basierend auf ihrer Gewichtung und ihrem Systemstatus zugewiesen, wie in der folgenden Tabelle dargestellt:
| Gewicht | Fehlerfrei | Priorität für Backend-Auswahl |
|---|---|---|
| Gewicht größer als null | Ja | 4 |
| Gewicht größer als null | Nein | 3 |
| Gewicht ist gleich null | Ja | 2 |
| Gewicht ist gleich null | Nein | 1 |
Nur die Backends mit der höchsten Priorität kommen für die Backend-Auswahl in Frage. Haben alle in Frage kommenden Back-Ends eine Nullgewichtung, verteilt der Load-Balancer neue Verbindungen zwischen allen zulässigen Back-Ends und behandelt sie, als wären sie alle gleich gewichtet. Beispiele für das gewichtete Load Balancing finden Sie unter Backend-Auswahl und Verbindungs-Tracking.
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 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).
- Ein Back-End wird aus einem Backend-Dienst entfernt.
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
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=ALLfestzulegen, oder verwenden Sie die API, umallPortsaufTrueeinzustellen.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 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 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.