Back-End-Dienst-basiertes externes TCP/UDP-Netzwerk-Load-Balancing – Überblick

Externes TCP/UDP-Netzwerk-Load-Balancing von Google Cloud (ab jetzt als Netzwerk-Load-Balancing bezeichnet) ist ein regionaler Pass-Through-Load-Balancer. Ein Netzwerk-Load-Balancer verteilt TCP- oder UDP-Traffic auf VM-Instanzen in derselben Region.

Ein Netzwerk-Load-Balancer kann Traffic von folgenden Quellen empfangen:

  • Jedem Client im Internet
  • Google Cloud-VMs mit externen IP-Adressen
  • Google Cloud-VMs mit Internetzugriff über Cloud NAT oder instanzbasiertes NAT

Das Netzwerk-Load-Balancing hat die folgenden Eigenschaften:

  • Das Netzwerk-Load-Balancing ist ein verwalteter Dienst.
  • Das Netzwerk-Load-Balancing wird mithilfe eines virtuellen Andromeda-Netzwerks und mit Google Maglev implementiert.
  • Die Netzwerk-Load-Balancer sind keine Proxys.
    • Pakete mit Load-Balancing werden von Back-End-VMs mit unveränderter Quell-IP-Adresse empfangen.
    • Verbindungen mit Load-Balancing werden von den Back-End-VMs beendet.
    • Antworten von den Back-End-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe.

Auf dieser Seite wird beschrieben, wie das Netzwerk-Load-Balancing mit einem Back-End-Dienst anstelle eines Zielpools funktioniert. Bisher war für ein Netzwerk-Load-Balancer die einzige Option der auf dem Zielpool basierende Netzwerk-Load-Balancer. Im Vergleich zu Zielpools bieten Back-End-Dienste eine genauere Kontrolle über die Funktionsweise Ihres Load-Balancers.

  • Eine Back-End-Dienstkonfiguration enthält eine Reihe von Werten wie Systemdiagnosen, Sitzungsaffinität, Zeitlimits für Verbindungsausgleich und Failover-Richtlinien. Die meisten dieser Einstellungen haben Standardwerte, die eine einfache Konfiguration erleichtern.
  • Load-Balancing-basierte Netzwerk-Load-Balancer verwenden Systemdiagnosen, die dem Traffictyp (TCP, SSL, HTTP, HTTPS oder HTTP/2) entsprechen, die sie verteilen. Zielpools auf Load-Balancer unterstützen nur Legacy-HTTP-Systemdiagnosen.
  • Back-End-Dienst-basierte Netzwerk-Load-Balancer unterstützen die Verwendung verwalteter Instanzgruppen als Back-Ends. Verwaltete Instanzgruppen automatisieren bestimmte Aspekte der Back-End-Verwaltung und bieten im Vergleich zu nicht verwalteten Instanzgruppen eine bessere Skalierbarkeit und Zuverlässigkeit. Zielpool-basierte Netzwerk-Load-Balancer unterstützen nur nicht verwaltete Instanzgruppen.

Architektur

Das folgende Diagramm veranschaulicht die Komponenten eines Netzwerk-Load-Balancers:

Externer TCP/UDP-Netzwerk-Load-Balancer mit regionalem Back-End-Dienst
Netzwerk-Load-Balancing mit regionalem Back-End-Dienst

Der Load-Balancer besteht aus mehreren Konfigurationskomponenten. Ein einzelner Load-Balancer kann folgende Komponenten haben:

  • Eine oder mehrere regionale externe IP-Adressen
  • Eine oder mehrere regionale externe Weiterleitungsregeln
  • Einen regionalen externen Back-End-Dienst
  • Eine oder mehrere Back-End-Instanzgruppen
  • Eine mit dem Back-End-Dienst verknüpfte Systemdiagnose

Außerdem müssen Sie Firewallregeln erstellen, um Systemdiagnose-Prüfungen für die Back-End-VMs zuzulassen.

IP-Adresse

Für einen Netzwerk-Load-Balancer ist mindestens eine Weiterleitungsregel erforderlich. Die Weiterleitungsregel verweist auf eine einzelne regionale externe IP-Adresse. Regionale externe IP-Adressen sind überall im Internet zugänglich, jedoch von einem Pool, der für jede Google Cloud-Region eindeutig ist.

Wenn Sie eine Weiterleitungsregel erstellen, können Sie den Namen oder die IP-Adresse einer vorhandenen reservierten regionalen externen IP-Adresse angeben. Wenn Sie keine IP-Adresse angeben, verweist die Weiterleitungsregel auf eine sitzungsspezifische regionale externe IP-Adresse. Verwenden Sie eine reservierte IP-Adresse, wenn Sie die Adresse, die Ihrem Projekt zugeordnet ist, wiederverwenden möchten, nachdem Sie eine Weiterleitungsregel gelöscht haben, oder wenn mehrere Weiterleitungsregeln auf dieselbe IP-Adresse verweisen sollen.

Der Netzwerk-Load-Balancing unterstützt sowohl regionale externe IP-Adressen der Standard- als auch der Premium-Stufe. Sowohl die IP-Adresse als auch die Weiterleitungsregel müssen dieselbe Netzwerkstufe verwenden.

Schritte zum Reservieren einer IP-Adresse finden Sie unter Externe IP-Adressen.

Weiterleitungsregel

Eine regionale externe Weiterleitungsregel gibt das Protokoll und die Ports an, über die der Load-Balancer Traffic annimmt. Da Netzwerk-Load-Balancer keine Proxys sind, leiten sie Traffic an Back-Ends über dasselbe Protokoll und denselben Port weiter. Die Weiterleitungsregel in Kombination mit der IP-Adresse bildet das Front-End des Load-Balancers.

Der Load-Balancer behält die Quell-IP-Adressen der eingehenden Pakete bei. Die Ziel-IP-Adresse für eingehende Pakete ist die IP-Adresse, die der Weiterleitungsregel des Load-Balancers zugeordnet ist.

Eingehender Traffic wird einer Weiterleitungsregel zugeordnet, die aus einer bestimmten IP-Adresse, einem Protokoll und Ports bzw. einem Portbereich besteht. Die Weiterleitungsregel leitet dann den Traffic an den Back-End-Dienst des Load-Balancers weiter.

Für einen Netzwerk-Load-Balancer ist mindestens eine Weiterleitungsregel erforderlich. Sie können mehrere Weiterleitungsregeln für denselben Load-Balancer definieren, wie im nächsten Abschnitt beschrieben.

Mehrere Weiterleitungsregeln

Sie können mehrere regionale externe Weiterleitungsregeln für denselben Netzwerk-Load-Balancer konfigurieren. Optional kann jede Weiterleitungsregel eine andere regionale externe IP-Adresse haben. Es können aber auch mehrere Weiterleitungsregeln auf dieselbe regionale externe IP-Adresse verweisen.

Das Konfigurieren mehrerer regionaler externer Weiterleitungsregeln kann für die folgenden Anwendungsfälle nützlich sein:

  • Sie möchten mehr als eine externe IP-Adresse für denselben Back-End-Dienst konfigurieren.
  • Sie müssen verschiedene Protokolle, Ports oder Portbereiche konfigurieren und verwenden dazu dieselbe externe IP-Adresse.

Wenn Sie mehrere Weiterleitungsregeln verwenden, sollten Sie die auf Ihren Back-End-VMs ausgeführte Software so konfigurieren, dass sie an alle externen IP-Adressen der Weiterleitungsregeln des Load-Balancers gebunden wird.

Regionaler Back-End-Dienst

Jeder Netzwerk-Load-Balancer hat einen regionalen Back-End-Dienst, der das Verhalten des Load-Balancers und die Verteilung des Traffics auf seine Back-Ends definiert. Der Name des Back-End-Dienstes ist der Name des Netzwerk-Load-Balancers, der in der Google Cloud Console angezeigt wird.

Jeder Back-End-Dienst definiert die folgenden Back-End-Parameter:

  • Protokoll. Ein Back-End-Dienst akzeptiert entweder TCP- oder UDP-Traffic, aber nicht beides für die IP-Adresse und die Ports, die von einer oder mehreren regionalen externen Weiterleitungsregeln angegeben werden. Der Back-End-Dienst ermöglicht das Senden von Traffic an Back-End-VMs mit derselben IP-Adresse und Ports, an die der Traffic gesendet wurde. Der Back-End-Dienst und alle zugehörigen Weiterleitungsregeln müssen dasselbe Protokoll verwenden.

  • Traffic-Verteilung. Ein Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität. Der Back-End-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert wird und ein Failover-Back-End für den Load-Balancer festgelegt wird.

  • Systemdiagnose. Ein Back-End-Dienst muss eine zugehörige Systemdiagnose haben.

Jeder Back-End-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic auf die erste Netzwerkschnittstelle (nic0) der Back-End-VMs. Back-Ends müssen Instanzgruppen in derselben Region wie der Back-End-Dienst und die Weiterleitungsregel sein. Back-Ends können zonal nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen oder regional verwaltete Instanzgruppen sein.

Back-End-Dienst-basierte Netzwerk-Load-Balancer unterstützen Instanzgruppen, deren Mitgliedsinstanzen ein beliebiges VPC-Netzwerk in derselben Region verwenden, solange sich das VPC-Netzwerk im selben Projekt wie der Back-End-Dienst befindet. Alle VMs innerhalb einer Instanzgruppe müssen dasselbe VPC-Netzwerk verwenden.

Back-End-Instanzgruppen

Ein externer TCP/UDP-Load-Balancer verteilt Verbindungen auf Back-End-VMs, die in verwalteten oder nicht verwalteten Instanzgruppen enthalten sind.

Instanzgruppen können regional oder zonal sein. Der externe TCP/UDP-Load-Balancer ist standardmäßig hochverfügbar. Es sind keine besonderen Schritte erforderlich, um den Load-Balancer hochverfügbar zu machen, da der Mechanismus nicht auf einem einzelnen Gerät oder einer einzelnen VM-Instanz beruht. Sie müssen nur dafür sorgen, dass Ihre Back-End-VM-Instanzen in mehreren Zonen bereitgestellt werden, damit der Load-Balancer mögliche Probleme in einer bestimmten Zone umgehen kann.

  • Regional verwaltete Instanzgruppen Verwenden Sie regional verwaltete Instanzgruppen, wenn Sie Ihre Software mithilfe von Instanzvorlagen bereitstellen können. Regional verwaltete Instanzgruppen verteilen den Traffic automatisch auf mehrere Zonen. Dadurch lassen sich potenzielle Probleme in einer bestimmten Zone vermeiden.

    Hier wird ein Beispiel-Deployment mit einer regionalen verwalteten Instanzgruppe gezeigt. Die Instanzgruppe hat eine Instanzvorlage, die definiert, wie Instanzen bereitgestellt werden sollen. Jede Gruppe stellt Instanzen innerhalb von drei Zonen der Region us-central1 bereit.

    Netzwerk-Load-Balancer mit einer regionalen verwalteten Instanzgruppe
    Netzwerk-Load-Balancing mit einer regionalen verwalteten Instanzgruppe
  • Zonal verwaltete und nicht verwaltete Instanzgruppen Verwenden Sie zonale Instanzgruppen in verschiedenen Zonen (in derselben Region), um sich vor potenziellen Problemen in einer bestimmten Zone zu schützen.

    Hier wird eine Beispielbereitstellung mit zonalen Instanzgruppen dargestellt. Dieser Load-Balancer bietet Verfügbarkeit in zwei Zonen.

    Netzwerk-Load-Balancer mit zonalen Instanzgruppen
    Netzwerk-Load-Balancing mit zonalen Instanzgruppen

Systemdiagnosen

Beim Netzwerk-Load-Balancing wird anhand von regionalen Systemdiagnosen ermittelt, zu welchen Instanzen neue Verbindungen aufgebaut werden können. Der Back-End-Dienst jedes Netzwerk-Load-Balancers muss einer regionalen Systemdiagnose zugeordnet sein. Load-Balancer verwenden den Systemdiagnosestatus, um zu bestimmen, wie neue Verbindungen an Back-End-Instanzen weitergeleitet werden.

Weitere Informationen zur Funktionsweise von Google Cloud-Systemdiagnosen finden Sie unter Funktionsweise von Systemdiagnosen.

Netzwerk-Load-Balancing unterstützt die folgenden Arten von Systemdiagnosen:

Systemdiagnosen und UDP-Traffic

Google Cloud bietet keine Systemdiagnose, bei der das UDP-Protokoll verwendet wird. Wenn Sie Netzwerk-Load-Balancing mit UDP-Traffic verwenden, müssen Sie auf Ihren Back-End-VMs einen TCP-basierten Dienst ausführen, um Systemdiagnose-Informationen bereitzustellen.

Bei dieser Konfiguration erfolgt das Load-Balancing von Clientanfragen mithilfe des UDP-Protokolls und ein TCP-Dienst wird verwendet, um den Systemdiagnoseprüfern von Google Cloud Informationen bereitzustellen. Sie können beispielsweise auf jeder Back-End-VM, die eine HTTP 200-Antwort an Systemdiagnosetests zurückgibt, einen einfachen HTTP-Server ausführen. In diesem Beispiel sollten Sie Ihre eigene Logik verwenden, die auf der Back-End-VM ausgeführt wird, um dafür zu sorgen, dass der HTTP-Server nur dann 200 zurückgibt, wenn der UDP-Dienst richtig konfiguriert ist und ordnungsgemäß ausgeführt wird.

Firewallregeln

Da das Netzwerk-Load-Balancing ein Pass-Through-Load-Balancer ist, steuern Sie den Zugriff auf die Back-Ends des Load-Balancers mithilfe von Google Cloud-Firewallregeln. Wenn Sie Traffic von einer beliebigen IP-Adresse im Internet akzeptieren möchten, müssen Sie eine entsprechende Firewallregel für eingehenden Traffic für das entsprechende Protokoll und die Ports mit dem Quellbereich 0.0.0.0/0 erstellen. Um nur Traffic von bestimmten IP-Adressbereichen zuzulassen, verwenden Sie restriktivere Quellbereiche.

Da das Netzwerk-Load-Balancing Google Cloud-Systemdiagnosen verwendet, müssen Sie immer Traffic aus den IP-Adressbereichen der Systemdiagnose zulassen. Firewallregeln für eingehenden Traffic können speziell für das Protokoll und die Ports der Systemdiagnose des Load-Balancers erstellt werden.

Return-Path

Das Netzwerk-Load-Balancing nutzt spezielle Routen außerhalb Ihres VPC-Netzwerks, um eingehende Anfragen und Systemdiagnoseprüfungen an jede Back-End-VM weiterzuleiten.

Der Load-Balancer behält die Quell-IP-Adressen der Pakete bei. Antworten von den Back-End-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe.

Architektur einer freigegebenen VPC

Mit Ausnahme der IP-Adresse müssen alle Komponenten eines Netzwerk-Load-Balancers im selben Projekt vorhanden sein. In der folgenden Tabelle sind die Komponenten einer freigegebenen VPC für das Netzwerk-Load-Balancing zusammengefasst:

IP-Adresse Weiterleitungsregel Back-End-Komponenten
Eine regionale externe IP-Adresse muss entweder im selben Projekt wie der Load-Balancer oder im freigegebenen VPC-Hostprojekt definiert werden. A Eine regionale externe Weiterleitungsregel muss im selben Projekt wie die Instanzen des Back-End-Dienstes definiert werden. Der regionale Back-End-Dienst muss im selben Projekt und in derselben Region wie die Instanzen in der Back-End-Instanzgruppe definiert werden. Mit dem Back-End-Dienst verknüpfte Systemdiagnosen müssen im selben Projekt und in derselben Region wie der Back-End-Dienst definiert werden.

Traffic-Verteilung

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

  • Wenn Sie kein Failover konfiguriert haben, verteilt ein Netzwerk-Load-Balancer neue Verbindungen zu seinen fehlerfreien Back-End-VMs, wenn mindestens eine Back-End-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 einen Failover konfiguriert haben, verteilt ein Netzwerk-Load-Balancer gemäß einer von Ihnen konfigurierten Failover-Richtlinie neue Verbindungen zwischen VMs in seinem aktiven Pool. Wenn alle Back-End-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.

Verbindungs-Tracking und konsistentes Hashing

Das Netzwerk-Load-Balancing verwendet eine Verbindungs-Tracking-Tabelle und einen konfigurierbaren konsistenten Hash-Algorithmus, um zu bestimmen, wie der Traffic an Back-End-VMs verteilt wird.

Wenn der Load-Balancer einen Eintrag in der Verbindungs-Tracking-Tabelle für ein eingehendes Paket hat, das Teil einer zuvor eingerichteten Verbindung ist, wird das Paket an die Back-End-VM gesendet, die der Load-Balancer ermittelt hat. Das zuvor ermittelte Back-End wurde in der Tabelle zur Nachverfolgung des Load-Balancers aufgezeichnet.

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:

  • Wenn keine Sitzungsaffinität konfiguriert wurde, erstellt der Load-Balancer einen fünf-Tupel-Hash für die Quell-IP-Adresse, den Quellport, die Ziel-IP-Adresse, den Zielport und das Protokoll. Anhand dieses Hashs wird ein Back-End ausgewählt, das derzeit fehlerfrei ist.
  • Wenn Sie eine Option für die Sitzungsaffinität konfiguriert haben, erstellt der Load-Balancer weiterhin einen Hash, aber aus weniger Informationen (wie unter Sitzungsaffinität beschrieben).
  • Wenn das Paket ein TCP-Paket ist oder das Paket ein UDP-Paket ist, bei dem die Sitzungsaffinität auf etwas anderes als NONE festgelegt ist, zeichnet der Load-Balancer das ausgewählte Back-End in seiner Tabelle für die Verbindungsverfolgung auf. Tabelleneinträge für das Verbindungs-Tracking laufen nach 60 Sekunden ab, wenn sie nicht verwendet werden.

Verhalten der persistenten Verbindung

  • TCP-Traffic. Bei TCP-Paketen bestimmt der Systemdiagnosestatus einer Back-End-VM nur die Verteilung von Paketen für neue Verbindungen. Solange eine Back-End-VM Mitglied einer Instanzgruppe bleibt und solange diese Instanzgruppe als Back-End für den Load-Balancer konfiguriert ist, werden Pakete, die Teil derselben TCP-Verbindung sind, an das zuvor ausgewählte Back-End-VM gesendet, auch wenn sich der Systemdiagnosestatus dieser VM zu „fehlerhaft“ geändert hat. Wenn das fehlerhafte Back-End auf Pakete antwortet, wird die Verbindung nicht unterbrochen. Wenn das fehlerhafte Back-End Pakete ablehnt oder nicht darauf reagiert, kann der Client eine neue Verbindung herstellen und für die wiederkehrende Verbindung ein anderes fehlerfreies Back-End auswählen.

    Wenn Sie eine Back-End-VM aus der Instanzgruppe entfernen oder die Instanzgruppe aus dem Back-End-Dienst entfernen, bleiben vorhandene Verbindungen bestehen (wie unter Verbindungsausgleich beschrieben).

  • UDP-Traffic. Da für UDP-Traffic keine Sitzung vorhanden ist, werden standardmäßig alle UDP-Pakete verarbeitet, ohne dass eine Verbindungs-Tracking-Tabelle verwendet wird. UDP-Verbindungen werden nicht in fehlerhaften Back-Ends gespeichert. Wenn jedoch für die Sitzungsaffinität ein anderer Wert als NONE festgelegt ist, werden UDP-Verbindungen (wie TCP-Verbindungen) verfolgt, aber UDP-Verbindungen werden bei fehlerhaften Back-Ends (im Gegensatz zu TCP-Verbindungen) nicht beibehalten.

In der folgenden Tabelle wird zusammengefasst, wann der Load-Balancer Verbindungs-Tracking und das Verhalten der persistenten Verbindung für jedes Protokoll verwendet.

Protokoll Verbindungs-Tracking Dauerhafte Verbindungen bei fehlerhaften Back-Ends
TCP Immer aktiv JA
UDP Standardwert: AUS
Verbindungs-Tracking ist aktiviert, wenn die Sitzungsaffinität
auf einen anderen Wert als NONE festgelegt ist.
NEIN

Optionen der Sitzungsaffinität

Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Back-End-VMs des Load-Balancers. Beispielsweise können Sie neue Verbindungen von demselben Client an dieselbe Back-End-VM leiten, wobei die Konzepte im Abschnitt „Verbindungs-Tracking und konsistentes Hashing“ erläutert werden.

Das Netzwerk-Load-Balancing unterstützt die folgenden Optionen für die Sitzungsaffinität, die Sie für den gesamten regionalen externen Back-End-Dienst (nicht pro Back-End-Instanzgruppe) angeben.

Sitzungsaffinität Konsistente Hash-Methode Verbindungs-Tracking Hinweise
Keine
(NONE)
5-Tupel-Hash 5-Tupel-Tracking nur für TCP Bei TCP ist dies das gleiche wie Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (5-Tupel-Hash).
Für UDP ist das Verbindungs-Tracking standardmäßig deaktiviert.
Client-IP, Ziel-IP
(CLIENT_IP)
2-Tupel-Hash von:
• Quell-IP-Adresse des Pakets
• Ziel-IP-Adresse des Pakets
5-Tupel-Tracking für TCP und UDP Verwenden Sie diese Option, wenn alle Verbindungen von derselben Quell-IP-Adresse über dieselbe Back-End-VM bereitgestellt werden müssen.
Client-IP, Ziel-IP, Protokoll
(CLIENT_IP_PROTO)
3-Tupel-Hash von:
• Quell-IP-Adresse des Pakets
• Ziel-IP-Adresse des Pakets
• Protokoll
5-Tupel-Tracking für TCP und UDP
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (5-Tupel)
(CLIENT_IP_PORT_PROTO)
5-Tupel-Hash 5-Tupel-Tracking für TCP und UDP Bei TCP entspricht dies NONE.
Bei UDP wird mit dieser Option das Verbindungs-Tracking aktiviert.

Verbindungsausgleich

Der Verbindungsausgleich ist ein Vorgang, der auf vorhandene TCP-Sitzungen angewendet wird, wenn Sie eine Back-End-VM aus einer Instanzgruppe entfernen oder wenn eine verwaltete Instanzgruppe eine Back-End-VM entfernt (durch Ersatz, Beendigung, bei Rolling Upgrades oder Herunterskalieren).

Standardmäßig ist der Verbindungsausgleich aktiviert. Wenn diese Option aktiviert ist, bleiben vorhandene TCP-Verbindungen erhalten, bis die VM nicht mehr existiert. Wenn Sie den Verbindungsausgleich deaktivieren, werden bestehende TCP-Verbindungen so schnell wie möglich beendet.

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

Failover

Sie können einen externen TCP/UDP-Load-Balancer konfigurieren, um Verbindungen zwischen VM-Instanzen in primären Back-End-Instanzgruppen zu verteilen und dann bei Bedarf auf Failover-Back-End-Instanzgruppen umzuschalten. 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-End-VMs nicht fehlerfrei sind.

Wenn Sie dem Back-End-Dienst eines Netzwerk-Load-Balancers ein Back-End hinzufügen, ist dieses Back-End standardmäßig ein primäres Back-End. 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 zur Funktionsweise des Failovers finden Sie unter Failover-Übersicht für Netzwerk-Load-Balancing.

UDP-Fragmentierung

Beachten Sie beim Load-Balancing von UDP-Datenpaketen Folgendes:

  • Nicht fragmentierte Datenpakete werden in allen Konfigurationen normal behandelt.
  • UDP-Pakete können fragmentiert werden, bevor Sie in Google Cloud ankommen. Nicht-Google Cloud-Netzwerke können fragmentierte UDP-Pakete verzögern, da sie entweder warten, bis alle Fragmente ankommen, oder ihnen fragmentierte Pakete verwerfen. Google Cloud-Netzwerke leiten UDP-Fragmente weiter, wenn sie eintreffen.

Wenn Sie fragmentierte UDP-Datenpakete erwarten, gehen Sie so vor:

  • 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 sie nicht denselben Zielport haben. Um alle Ports zu konfigurieren, entweder festlegen --ports=ALL mit gcloud oder festlegenallPorts auf True mit der API.
  • Setzen Sie die Sitzungsaffinität auf Keine (NONE). Dies weist darauf hin, dass die Aufrechterhaltung der Affinität nicht erforderlich ist. Deshalb verwendet der Load-Balancer einen 5-Tupel-Hash, um ein Back-End für nicht fragmentierte Pakete und einen 3-Tupel-Hash für fragmentierte Pakete auszuwählen.

Bei diesen Einstellungen werden UDP-Fragmente aus demselben Datenpaket an dieselbe Instanz geleitet, um dort wieder zusammengesetzt zu werden.

Zielinstanzen als Back-Ends verwenden

Wenn Sie Zielinstanzen als Back-Ends für den Netzwerk-Load-Balancer verwenden und fragmentierte UDP-Datenpakete erwarten, verwenden Sie nur eine UDP-Weiterleitungsregel pro IP-Adresse mit Load-Balancing und konfigurieren Sie die Weiterleitungsregel, um Traffic an allen Ports zuzulassen. Dadurch wird gewährleistet, dass alle Fragmente zur selben Weiterleitungsregel gelangen, auch wenn sie nicht denselben Zielport haben. Um alle Ports zu konfigurieren, stellen Sie entweder --ports=ALL mithilfe von gcloud ein oder setzen Sie allPorts mithilfe der API auf True.

Beschränkungen

  • Netzwerk-Endpunktgruppen (NEGs) werden nicht als Back-Ends für Netzwerk-Load-Balancer unterstützt.
  • Back-End-Dienst-basierte Netzwerk-Load-Balancer werden von Google Kubernetes Engine nicht unterstützt.
  • Bei Back-End-Diensten, die mit Netzwerk-Load-Balancern verknüpft sind, gibt die Ausgabe des Befehls gcloud compute backend-services get-health nur die internen IP-Adressen der Back-Ends zurück, nicht die externe IP-Adresse von der Weiterleitungsregel, die den Instanzen zugewiesen.

Nächste Schritte