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 externen Traffic auf VM-Instanzen in derselben Region.

Sie können einen Netzwerk-Load-Balancer für TCP-, UDP-, ESP- und ICMP-Traffic konfigurieren. Unterstützung für ESP und ICMP befindet sich in der Vorschau.

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.
  • Netzwerk-Load-Balancer sind keine Proxys.
    • Pakete mit Load-Balancing werden von Back-End-VMs mit den Quell- und Ziel-IP-Adressen des Pakets, dem Protokoll und den unveränderten Quell- und Zielports angezeigt, wenn das Protokoll portbasiert ist.
    • 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.

Back-End-Dienst-basierte Netzwerk-Load-Balancer haben die folgenden Eigenschaften:

  • Back-Ends in Form verwalteter Instanzgruppen. Back-End-Dienst-basierte Netzwerk-Load-Balancer unterstützen die Verwendung verwalteter Instanzgruppen (Managed Instance Groups, MIGs) 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.
  • Detailgenaue Steuerung der Trafficverteilung. Die Konfiguration eines Back-End-Dienstes enthält eine Reihe von Werten wie Systemdiagnosen, Sitzungsaffinität, Verbindungs-Tracking, Verbindungsausgleich und Failover-Richtlinien. Die meisten dieser Einstellungen haben Standardwerte, die einen schnellen Einstieg ermöglichen.
  • Systemdiagnosen. Back-End-Dienst-basierte Netzwerk-Load-Balancer verwenden Systemdiagnosen, die dem Typ des Traffics (TCP, SSL, HTTP, HTTPS oder HTTP/2) entsprechen, den sie verteilen.

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, mit denen der Load-Balancing-Traffic und die Systemdiagnoseprüfungen die Back-End-VMs erreichen können.

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 es sich bei Netzwerk-Load-Balancern nicht um Proxys handelt, leiten sie Traffic an Back-Ends über dasselbe Protokoll und denselben Port weiter, sofern das Paket Portinformationen enthält. 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, bei einem portbasierten Protokoll, einem oder mehreren Ports, einem Portbereich oder allen Ports 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 unter Mehrere Weiterleitungsregeln beschrieben.

Weiterleitungsregelprotokolle

Das Netzwerk-Load-Balancing unterstützt die folgenden Protokolloptionen für jede Weiterleitungsregel: TCP, UDP und L3_DEFAULT (Vorschau).

Verwenden Sie die Optionen TCP und UDP, um das TCP- oder UDP-Load-Balancing zu konfigurieren. Mit der Protokolloption L3_DEFAULT kann ein Netzwerk-Load-Balancer TCP-, UDP-, ESP- und ICMP-Traffic ausgleichen.

Neben der Unterstützung anderer Protokolle als TCP und UDP ermöglicht L3_DEFAULT auch die Bereitstellung mehrerer Protokolle mit einer einzelnen Weiterleitungsregel. Beispielsweise verarbeiten IPSec-Dienste in der Regel eine Kombination aus ESP- und UDP-basiertem IKE- und NAT-T-Traffic. Mit der Option L3_DEFAULT kann eine einzelne Weiterleitungsregel konfiguriert werden, um alle diese Protokolle zu verarbeiten.

Weiterleitungsregeln mit den Protokollen TCP oder UDP können auf einen Back-End-Dienst verweisen, der entweder dasselbe Protokoll wie die Weiterleitungsregel oder ein Back-End-Dienst mit dem Protokoll UNSPECIFIED (Vorschau) verwendet. L3_DEFAULT-Weiterleitungsregeln können nur auf einen Back-End-Dienst mit dem Protokoll UNSPECIFIED verweisen.

In der folgenden Tabelle wird zusammengefasst, wie diese Einstellungen für verschiedene Protokolle verwendet werden.

Traffic für das Load-Balancing Protokoll der Weiterleitungsregel Protokoll des Back-End-Dienstes
TCP TCP TCP oder UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP oder UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP L3_DEFAULT UNSPECIFIED
ICMP (nur Echo-Anfrage) L3_DEFAULT UNSPECIFIED

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 für dieselbe externe IP-Adresse verschiedene Protokolle und nicht überlappende Ports oder Portbereiche konfigurieren.

Für eine bestimmte IP-Adresse kann eine L3_DEFAULT-Weiterleitungsregel gleichzeitig mit Weiterleitungsregeln mit anderen Protokollen (TCP oder UDP), aber nicht mit einer anderen L3_DEFAULT-Weiterleitungsregel bestehen.

Ein Paket, das bei der IP-Adresse des Load-Balancers eingeht, stimmt nur dann mit einer L3_DEFAULT-Weiterleitungsregel überein, wenn keine spezifischere Weiterleitungsregel verfügbar ist (z. B. für TCP- oder UDP-Traffic). Genauer gesagt, entspricht ein Paket, das an einer IP-Adresse, einem Protokoll und einem Port eingeht, nur dann einer L3_DEFAULT-Weiterleitungsregel, wenn keine anderen Weiterleitungsregeln für diese IP-Adresse vorhanden sind, die mit dem Protokoll und Zielport des Pakets übereinstimmen.

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 Traffic über die IP-Adresse und die Ports (falls konfiguriert), die durch eine oder mehrere regionale externe Weiterleitungsregeln festgelegt werden. Der Back-End-Dienst übergibt Pakete an Back-End-VMs, wobei die Quell- und Ziel-IP-Adressen des Pakets, das Protokoll und, falls das Protokoll portbasiert ist, die Quell- und Zielports beibehalten.

    Back-End-Dienste mit Netzwerk-Load-Balancern unterstützen die folgenden Protokolloptionen: TCP, UDP oder UNSPECIFIED (Vorschau).

    Back-End-Dienste mit dem Protokoll UNSPECIFIED können unabhängig vom Weiterleitungsregelprotokoll mit jeder Weiterleitungsregel verwendet werden. Back-End-Dienste mit einem bestimmten Protokoll (TCP oder UDP) können nur durch Weiterleitungsregeln mit demselben Protokoll (TCP oder UDP) referenziert werden. Weiterleitungsregeln mit dem Protokoll L3_DEFAULT können nur auf Back-End-Dienste mit dem Protokoll UNSPECIFIED verweisen.

    Unter Protokollspezifikation für Weiterleitungsregeln finden Sie eine Tabelle mit möglichen Kombinationen von Weiterleitungsregeln und Back-End-Dienstprotokollen.

  • Traffic-Verteilung. Ein Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß der konfigurierbaren Sitzungsaffinität und Richtlinien für das Verbindungs-Tracking. Der Back-End-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert 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 Netzwerk-Load-Balancer verteilt Verbindungen zwischen Back-End-VMs in verwalteten oder nicht verwalteten Instanzgruppen. Instanzgruppen können regional oder zonal sein.

  • 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 für anderen Protokolltraffic

Google Cloud bietet außer den hier aufgeführten keine weiteren protokollspezifischen Systemdiagnosen an. Auch wenn Sie das Netzwerk-Load-Balancing für das Load-Balancing eines anderen Protokolls als TCP verwenden, müssen Sie dennoch einen TCP-basierten Dienst auf Ihren Back-End-VMs ausführen, um die erforderlichen Informationen zur Systemdiagnose bereitzustellen.

Wenn Sie beispielsweise Load-Balancing für UDP-Traffic ausführen, erfolgt das Load-Balancing von Clientanfragen mithilfe des UDP-Protokolls und Sie müssen einen TCP-Dienst ausführen, um für die Systemdiagnoseprüfer von Google Cloud Informationen bereitzustellen. Zu diesem Zweck können Sie auf jeder Back-End-VM, die eine HTTP 200-Antwort an Systemdiagnoseprüfer zurückgibt, einen einfachen HTTP-Server ausführen. Sie sollten 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. Sie müssen Firewallregeln zum Zulassen von eingehendem Traffic oder eine hierarchische Firewallrichtlinie zum Zulassen von eingehendem Traffic erstellen, um Systemdiagnosen und den Traffic für das Load-Balancing zuzulassen.

Weiterleitungsregeln und Firewallregeln oder hierarchische Regeln zum Zulassen von eingehendem Traffic arbeiten so zusammen: Eine Weiterleitungsregel gibt das Protokoll und (falls definiert) die Portanforderungen an, die ein Paket erfüllen muss, um an eine Back-End-VM weitergeleitet zu werden. Firewallregeln für eingehenden Traffic steuern, ob die weitergeleiteten Pakete an die VM zugestellt oder verworfen werden. Alle VPC-Netzwerke haben eine implizierte Firewallregel zum Ablehnen von eingehendem Traffic, die eingehende Pakete von jeder Quelle blockiert. Das Standard-VPC-Netzwerk von Google Cloud enthält eine begrenzte Anzahl von vorkonfigurierten Firewallregeln zum Zulassen von eingehendem Traffic.

  • Wenn Sie Traffic von beliebigen IP-Adressen im Internet akzeptieren möchten, müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic mit dem Quellbereich 0.0.0.0/0 erstellen. Um nur Traffic von bestimmten IP-Adressbereichen zuzulassen, verwenden Sie restriktivere Quellbereiche.

  • Als bewährte Sicherheitsmethode sollten Ihre Firewallregeln zum Zulassen von eingehendem Traffic nur die von Ihnen benötigten IP-Protokolle und -Ports zulassen. Die Beschränkung der Protokollkonfiguration (und, falls möglich, des Ports) ist besonders wichtig, wenn Sie Weiterleitungsregeln verwenden, deren Protokoll auf L3_DEFAULT festgelegt ist. L3_DEFAULT-Weiterleitungsregeln leiten Pakete für alle unterstützten IP-Protokolle weiter (an allen Ports, wenn das Protokoll und das Paket Portinformationen haben).

  • Das Netzwerk-Load-Balancing verwendet Google Cloud-Systemdiagnosen. Daher müssen Sie immer Traffic aus den IP-Adressbereichen der Systemdiagnose zulassen. Firewallregeln zum Zulassen von eingehendem 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. 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 fehlerfreien Back-End-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 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 Back-End und Verbindungs-Tracking

Das Netzwerk-Load-Balancing verwendet konfigurierbare Algorithmen zur Auswahl von Back-End und Verbindungs-Tracking, um zu bestimmen, wie der Traffic an Back-End-VMs verteilt wird.

Das Netzwerk-Load-Balancing verwendet den folgenden Algorithmus, um Pakete an Back-End-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 Back-End 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 Back-End aus. Der Load-Balancer berechnet einen Hash anhand der konfigurierten Sitzungsaffinität. Dieser Hash wählt ein Back-End aus den Back-Ends aus, die aktuell fehlerfrei sind, es sei denn, alle Back-Ends sind fehlerhaft. In diesem Fall werden alle Back-Ends berücksichtigt, sofern die Failover-Richtlinie nicht so konfiguriert ist, dass Traffic in dieser Situation verworfen wird. 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 Back-End-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 Back-End für die Verbindung des Pakets auf, sodass alle zukünftigen Pakete von dieser Verbindung an dasselbe Back-End 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 ist es 5-Tupel, es kann aber auch mit weniger Tupel konfiguriert werden. Bei einem 5-Tupel werden TCP-SYN-Pakete anders behandelt. Im Gegensatz zu Nicht-SYN-Paketen verwerfen sie alle übereinstimmenden Einträge für das Verbindungs-Tracking und wählen immer ein neues Back-End aus.

        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.
      • UDP- und ESP-Pakete. Das Verbindungs-Tracking ist nur aktiviert, wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist.

      • ICMP-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. Dieser Wert für das Zeitlimit von 60 Sekunden ist nicht konfigurierbar.
      • 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 Back-End-Dienst und nicht für jede Back-End-Instanzgruppe angegeben.

Netzwerk-Load-Balancing unterstützt 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.

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). Das ist der Standard-Tracking-Modus. In diesem Verbindungs-Tracking-Modus wird TCP-Traffic unabhängig von den Einstellungen der Sitzungsaffinität immer pro 5-Tupel erfasst. Bei UDP- und ESP-Traffic ist das Verbindungs-Tracking aktiviert, wenn die ausgewählte Sitzungsaffinität nicht NONE ist. UDP- und ESP-Pakete werden mit den in dieser Tabelle beschriebenen Tracking-Methoden erfasst.

  • PER_SESSION. Wenn die Sitzungsaffinität CLIENT_IP oder CLIENT_IP_PROTO ist, führt das Konfigurieren dieses Modus zu einem 2-Tupel- und 3-Tupel-Verbindungs-Tracking. Alle Protokolle (außer ICMP, das nicht über die Verbindung nachverfolgbar ist). Bei anderen Einstellungen für die Sitzungsaffinität verhält sich der PER_SESSION-Modus identisch zum PER_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.

Back-End-Auswahl Verbindungs-Tracking-Modus
Einstellung für die Sitzungsaffinität Hash-Methode für die Back-End-Auswahl PER_CONNECTION (Standard) PER_SESSION
Standard: Keine Sitzungsaffinität

(NONE)

TCP und nicht fragmentiertes UDP: 5-Tupel-Hash

Fragmentierte UDP- und alle anderen Protokolle: 3-Tupel-Hash

  • TCP: 5-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
  • TCP: 5-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
Client-IP, Ziel-IP

(CLIENT_IP)

Alle Protokolle: 2-Tupel-Hash
  • TCP und nicht fragmentiertes UDP: 5-Tupel-Verbindungs-Tracking
  • Fragmentiertes UDP und ESP: 3-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
  • TCP, UDP, ESP: 2-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
Client-IP, Ziel-IP, Protokoll

(CLIENT_IP_PROTO)

Alle Protokolle: 3-Tupel-Hash
  • TCP und nicht fragmentiertes UDP: 5-Tupel-Verbindungs-Tracking
  • Fragmentiertes UDP und ESP: 3-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
  • TCP, UDP, ESP: 3-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll

(CLIENT_IP_PORT_PROTO)

TCP und nicht fragmentiertes UDP: 5-Tupel-Hash

Fragmentiertes UDP und alle anderen Protokolle: 3-Tupel-Hash

  • TCP und nicht fragmentiertes UDP: 5-Tupel-Verbindungs-Tracking
  • Fragmentiertes UDP und ESP: 3-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
  • TCP und nicht fragmentiertes UDP: 5-Tupel-Verbindungs-Tracking
  • Fragmentiertes UDP und ESP: 3-Tupel-Verbindungs-Tracking
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert

Informationen zum Ändern des Verbindungs-Tracking-Modus finden Sie unter Verbindungs-Tracking-Richtlinie konfigurieren.

Verbindungspersistenz auf fehlerhaften Back-Ends

Die Einstellungen für die Verbindungspersistenz steuern, ob eine vorhandene Verbindung auf einem ausgewählten Back-End verbleibt, nachdem das Back-End fehlerhaft geworden ist (sofern das Back-End in der konfigurierten Back-End-Instanzgruppe des Load-Balancers verbleibt).

Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Back-End-VM aus der Instanzgruppe entfernen oder die Instanzgruppe aus dem Back-End-Dienst entfernen. In solchen Fällen bleiben vorhandene Verbindungen bestehen, wie unter Verbindungsausgleich 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.

Verbindungspersistenz für fehlerhafte 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 NONE oder CLIENT_IP_PORT_PROTO ist.

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-, UDP-Verbindungen bleiben auf fehlerhaften Back-Ends bestehen, wenn die Sitzungsaffinität nicht NONE ist.

ICMP: nicht zutreffend, da ICMP nicht über Verbindungs-Tracking erfasst werden kann.

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 Back-End weiterhin auf Pakete antwortet, wird die Verbindung so lange fortgesetzt, bis sie entweder vom fehlerhaften Back-End oder vom Client zurückgesetzt oder geschlossen wird.
  • Wenn das fehlerhafte Back-End ein TCP-Rücksetzpaket (RST) sendet oder nicht auf Pakete antwortet, kann der Client eine neue Verbindung herstellen. Der Load-Balancer kann dann ein anderes fehlerfreies Back-End auswählen. TCP SYN-Pakete wählen immer ein neues, fehlerfreies Back-End aus.

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

Verbindungsausgleich

Der Verbindungsausgleich wird in folgenden Fällen auf vorhandene Verbindungen angewendet:

  • Eine Back-End-VM wird aus einer Instanzgruppe entfernt.
  • Eine verwaltete Instanzgruppe entfernt eine Back-End-VM (durch Ersetzen, Verwerfen, Rolling Upgrades oder Herunterskalieren).
  • Eine Instanzgruppe wird aus einem Back-End-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

Netzwerk-Load-Balancing verarbeitet sowohl fragmentierte als auch nicht fragmentierte UDP-Pakete. Nicht fragmentierte Datenpakete werden in allen Konfigurationen normal behandelt. 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 jeweiligen Netzwerkanbieters oder der Netzwerkgeräte.

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. Zum Konfigurieren aller Ports legen Sie entweder --ports=ALL über das gcloud-Befehlszeilentool oder allPorts auf True über die API fest.

  • Verwenden Sie eine der folgenden Methoden, um den Back-End-Dienst zu konfigurieren:

    • Sitzungsaffinität und Verbindungs-Tracking deaktivieren. Setzen Sie die Sitzungsaffinität auf NONE. Der Load-Balancer verwendet einen 5-Tupel-Hash, um ein Back-End für nicht fragmentierte Pakete (mit Portinformationen) und einen 3-Tupel-Hash für fragmentierte Pakete (ohne Portinformationen) auszuwählen. Bei dieser Einrichtung können fragmentierte und nicht fragmentierte UDP-Pakete von demselben Client an verschiedene Back-Ends weitergeleitet werden.
    • 2- oder 3-Tupel-Sitzungsaffinität und Verbindungs-Tracking aktivieren. Setzen Sie die Sitzungsaffinität auf CLIENT_IP oder CLIENT_IP_PROTO und den Modus für das Verbindungs-Tracking auf PER_SESSION. Bei dieser Einrichtung werden fragmentierte und nicht fragmentierte UDP-Pakete von demselben Client an dasselbe Back-End weitergeleitet, ohne Portinformationen zu verwenden.

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.

Failover

Sie können einen Netzwerk-Load-Balancer konfigurieren, um Verbindungen zwischen VM-Instanzen in primären Back-End-Instanzgruppen zu verteilen und bei Bedarf auf Failover-Back-End-Instanzgruppen umzustellen. 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.

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.
  • Die Google Cloud Console bietet keine Möglichkeiten zur Ausführung folgender Aufgaben:

    • Erstellen oder Ändern eines Netzwerk-Load-Balancers, dessen Weiterleitungsregel das L3_DEFAULT-Protokoll verwendet.
    • Erstellen oder Ändern eines Netzwerk-Load-Balancers, dessen Back-End-Dienstprotokoll auf UNSPECIFIED gesetzt ist.
    • Konfigurieren einer Richtlinie für das Verbindungs-Tracking für einen Back-End-Dienst.

    Verwenden Sie stattdessen das gcloud-Befehlszeilentool oder die REST API.

Nächste Schritte