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

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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-, GRE- ICMP- und ICMPv6-Traffic konfigurieren.

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 (DSR).

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.
  • Unterstützung für IPv6-Konnektivität. Netzwerkbasierte Load-Balancer des Netzwerks können sowohl IPv4- als auch IPv6-Traffic verarbeiten.
  • 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.
  • Google Cloud Armor-Integration. Google Cloud Armor unterstützt den erweiterten DDoS-Netzwerkschutz für Netzwerk-Load-Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in GKE erstellen, empfehlen wir die Verwendung des integrierten GKE-Dienstcontrollers, der Google Cloud-Load-Balancer im Namen von GKE-Nutzern bereitstellt. Dies ist mit der auf dieser Seite beschriebenen eigenständigen Load-Balancing-Architektur identisch, mit dem Unterschied, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird.

Zugehörige GKE-Dokumentation:

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 regionale externe IP-Adresse, auf die überall im Internet zugegriffen werden kann.

  • Bei IPv4-Traffic verweist die Weiterleitungsregel auf eine einzelne regionale externe IPv4-Adresse. Regionale externe IPv4-Adressen stammen aus einem Pool, der für jede Google Cloud-Region eindeutig ist. Die IP-Adresse kann eine reservierte statische Adresse oder eine sitzungsspezifische Adresse sein.
  • Bei IPv6-Traffic verweist die Weiterleitungsregel auf einen /96-IP-Adressbereich aus dem externen IPv6-Adressbereich /64 des Subnetzes. Das Subnetz muss ein Dual-Stack-Subnetz sein, wobei ipv6-access-type auf EXTERNAL gesetzt ist. Externe IPv6-Adressen sind nur in der Premium-Stufe verfügbar. Das Reservieren einer regionalen externen IPv6-Adresse wird nur für Instanzen unterstützt. Daher müssen Sie für die Weiterleitungsregel eine sitzungsspezifische IPv6-Adresse verwenden.

Verwenden Sie für die Weiterleitungsregel 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.

Das Netzwerk-Load-Balancing unterstützt sowohl die Standardstufe als auch die Premiumstufe für regionale externe IPv4-Adressen. Sowohl die IP-Adresse als auch die Weiterleitungsregel müssen dieselbe Netzwerkstufe verwenden. Regionale externe IPv6-Adressen sind nur in der Premium-Stufe verfügbar.

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 (entweder eine IPv4-Adresse oder einem IPv6-Adressbereich) und einem Protokoll besteht. Wenn das Protokoll portbasiert ist, wird entweder ein Port verwendet. Bereich(e), alle Ports oder alle Ports. Die Weiterleitungsregel leitet dann den Traffic an den Back-End-Dienst des Load-Balancers weiter.

  • Wenn die Weiterleitungsregel auf eine IPv4-Adresse verweist, ist die Weiterleitungsregel keinem Subnetz zugeordnet. Das heißt, die IP-Adresse stammt von außerhalb eines Google Cloud-Subnetzbereichs.

  • Wenn die Weiterleitungsregel auf eine IPv6-Adresse verweist, muss die Weiterleitungsregel einem Subnetz zugeordnet sein und dieses Subnetz muss (a) ein Dual-Stack-Subnetz sein und (b) --ipv6-access-type muss auf EXTERNAL festgelegt sein.

Für einen Netzwerk-Load-Balancer ist mindestens eine Weiterleitungsregel erforderlich. Weiterleitungsregeln können so konfiguriert werden, dass der Traffic von einem bestimmten Bereich von Quell-IP-Adressen an einen bestimmten Back-End-Dienst (oder eine Zielinstanz) weitergeleitet wird. Weitere Informationen finden Sie unter Trafficsteuerung. Sie können mehrere Weiterleitungsregeln für denselben Load-Balancer definieren, wie unter Mehrere Weiterleitungsregeln beschrieben.

Erstellen Sie zwei Weiterleitungsregeln., wenn der Load-Balancer sowohl IPv4- als auch IPv6-Traffic verarbeiten soll: eine Regel für IPv4-Traffic, die auf IPv4- (oder Dual-Stack-)Back-Ends verweist, und eine Regel für IPv6-Traffic, der nur für Dual-Stack-Back-Ends verweist. Es ist möglich, dass eine IPv4- und eine IPv6-Weiterleitungsregel auf denselben Back-End-Dienst verweisen. Der Back-End-Dienst muss jedoch auf Dual-Stack-Back-Ends verweisen.

Weiterleitungsregelprotokolle

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

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-, GRE-, ICMP- und ICMPv6-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. L3_DEFAULT-Weiterleitungsregeln können nur auf einen Back-End-Dienst mit dem Protokoll UNSPECIFIED verweisen.

Wenn Sie das Protokoll L3_DEFAULT verwenden, müssen Sie die Weiterleitungsregel so konfigurieren, dass Traffic an allen Ports akzeptiert wird. Um alle Ports zu konfigurieren, stellen Sie entweder --ports=ALL mithilfe der Google Cloud-Befehlszeile ein oder setzen Sie mithilfe der API allPorts auf True.

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, GRE,
ICMP/ICMPv6 (nur Echo-Anfrage)
L3_DEFAULT UNSPECIFIED

Mehrere Weiterleitungsregeln

Sie können mehrere regionale externe Weiterleitungsregeln für denselben Netzwerk-Load-Balancer konfigurieren. Jede Weiterleitungsregel kann 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 oder nicht überlappende Ports oder Portbereiche konfigurieren.
  • Sie müssen Traffic von bestimmten Quell-IP-Adressen an bestimmte Load-Balancer-Back-Ends weiterleiten.

Google Cloud erfordert, dass eingehende Pakete nicht mit einer Weiterleitungsregel übereinstimmen. Mit Ausnahme der Weiterleitungsregel für die Trafficsteuerung, die im nächsten Abschnitt erläutert werden, müssen zwei oder mehr Weiterleitungsregeln, die dieselbe regionale externe IP-Adresse verwenden, gemäß diesen Einschränkungen eindeutige Protokoll- und Portkombinationen haben:

  • Eine Weiterleitungsregel, die für alle Ports eines Protokolls konfiguriert ist, verhindert die Erstellung anderer Weiterleitungsregeln mit demselben Protokoll und derselben IP-Adresse. Weiterleitungsregeln, die TCP- oder UDP-Protokolle verwenden, können so konfiguriert werden, dass sie alle Ports verwenden, oder sie können für bestimmte Ports konfiguriert werden. Wenn Sie beispielsweise eine Weiterleitungsregel mit IP-Adresse 198.51.100.1, TCP-Protokoll und allen Ports erstellen, können Sie keine andere Weiterleitungsregel mit der IP-Adresse 198.51.100.1 und dem TCP-Protokoll erstellen. Sie können zwei Weiterleitungsregeln erstellen, die beide die IP-Adresse 198.51.100.1 und das Protokoll TCP verwenden, wenn jede eindeutige Ports oder nicht überlappende Portbereiche hat. Sie können beispielsweise zwei Weiterleitungsregeln mit der IP-Adresse 198.51.100.1 und dem TCP-Protokoll erstellen, wobei die Ports einer Weiterleitungsregel 80,443 und die andere den Portbereich 81-442 verwendet.
  • Pro IP-Adresse kann nur eine L3_DEFAULT-Weiterleitungsregel erstellt werden. Dies liegt daran, dass das L3_DEFAULT-Protokoll alle Ports per Definition verwendet. In diesem Kontext umfasst der Begriff „alle Ports” Protokolle ohne Portinformationen.
  • Eine einzelne L3_DEFAULT-Weiterleitungsregel kann neben anderen Weiterleitungsregeln bestehen, die bestimmte Protokolle verwenden (TCP oder UDP). Die L3_DEFAULT-Weiterleitungsregel kann als letztes Mittel verwendet werden, wenn Weiterleitungsregeln mit derselben IP-Adresse, aber spezifischeren Protokollen existieren. Eine L3_DEFAULT-Weiterleitungsregel verarbeitet Pakete, die an ihre Ziel-IP-Adresse gesendet werden, nur dann, wenn die Ziel-IP-Adresse, das Protokoll und der Zielport des Pakets nicht mit einer protokollspezifischen Weiterleitungsregel übereinstimmen.

    Betrachten Sie zur Veranschaulichung diese beiden Szenarien. Weiterleitungsregeln in beiden Szenarien verwenden dieselbe IP-Adresse 198.51.100.1.

    • Szenario 1. Die erste Weiterleitungsregel verwendet das Protokoll L3_DEFAULT. Die zweite Weiterleitungsregel verwendet das Protokoll TCP und alle Ports. TCP-Pakete, die an einen beliebigen Zielport von 198.51.100.1 gesendet werden, werden von der zweiten Weiterleitungsregel verarbeitet. Pakete mit verschiedenen Protokollen werden von der ersten Weiterleitungsregel verarbeitet.
    • Szenario 2. Die erste Weiterleitungsregel verwendet das Protokoll L3_DEFAULT. Die zweite Weiterleitungsregel verwendet das Protokoll TCP und den Port 8080. TCP-Pakete, die an 198.51.100.1:8080 gesendet werden, werden von der zweiten Weiterleitungsregel verarbeitet. Alle anderen Pakete, einschließlich TCP-Paketen, die an unterschiedliche Zielports gesendet werden, werden von der ersten Weiterleitungsregel verarbeitet.

Auswahl von Weiterleitungsregeln

Google Cloud wählt eine oder null Weiterleitungsregeln aus, um ein eingehendes Paket mithilfe dieses Eliminierungsprozesses zu verarbeiten, beginnend mit der Reihe von Weiterleitungsregelkandidaten, die der Ziel-IP-Adresse des Pakets entsprechen:

  • Entfernen Sie Weiterleitungsregeln, deren Protokoll nicht mit dem Protokoll des Pakets übereinstimmt, mit Ausnahme von L3_DEFAULT-Weiterleitungsregeln. Weiterleitungsregeln, die das Protokoll L3_DEFAULT verwenden, werden bei diesem Schritt nie gelöscht, da L3_DEFAULT mit allen Protokollen übereinstimmt. Wenn das Protokoll des Pakets beispielsweise TCP ist, werden nur Weiterleitungsregeln entfernt, die das Protokoll UDP verwenden.

  • Entfernen Sie Weiterleitungsregeln, deren Port nicht mit dem Port des Pakets übereinstimmt. Die für alle Ports konfigurierten Weiterleitungsregeln werden bei diesem Schritt nie gelöscht, da eine Weiterleitungsregel für alle Ports mit jedem Port übereinstimmt.

  • Wenn die verbleibenden Kandidaten für Weiterleitungsregeln sowohl L3_DEFAULT als auch protokollspezifische Weiterleitungsregeln enthalten, entfernen Sie die L3_DEFAULT-Weiterleitungsregeln. Wenn die verbleibenden Kandidaten für Weiterleitungsregeln alle L3_DEFAULT-Weiterleitungsregeln sind, werden in diesem Schritt keine gelöscht.

  • An dieser Stelle fallen entweder die verbleibenden Kandidaten für Weiterleitungsregeln in eine der folgenden Kategorien:

    • Eine einzelne Weiterleitungsregel, die mit der Ziel-IP-Adresse, dem Protokoll und dem Port des Pakets übereinstimmt, wird zum Weiterleiten des Pakets verwendet.
    • Es verbleiben zwei oder mehr Weiterleitungsregelkandidaten, die der Ziel-IP-Adresse, dem Protokoll und dem Port des Pakets entsprechen. Dies bedeutet, dass die verbleibenden Kandidaten für Weiterleitungsregeln die Weiterleitungsregel für die Trafficsteuerung umfassen (wie im nächsten Abschnitt erläutert). Wählen Sie die Weiterleitungsregel für die Trafficsteuerung aus, deren Quellbereich den spezifischsten CIDR-Bereich (längstes übereinstimmendes Präfix) enthält, der die Quell-IP-Adresse des Pakets enthält. Wenn keine Weiterleitungsregeln für die Trafficsteuerung einen Quellbereich haben, einschließlich der Quell-IP-Adresse des Pakets, wählen Sie die übergeordnete Weiterleitungsregel aus.
    • Null Kandidaten für die Weiterleitungsregel bleiben bestehen und das Paket wird verworfen.

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.

Trafficsteuerung

Weiterleitungsregeln für Netzwerk-Load-Balancer können so konfiguriert werden, dass der Traffic von einem bestimmten Bereich von Quell-IP-Adressen an einen bestimmten Back-End-Dienst (oder eine Zielinstanz) weitergeleitet wird.

Die Trafficsteuerung ist nützlich für die Fehlerbehebung und für erweiterte Konfigurationen. Mithilfe der Trafficsteuerung können Sie bestimmte Clients an eine andere Gruppe von Back-Ends, eine andere Back-End-Dienstkonfiguration oder beides weiterleiten. Beispiel:

  • Mithilfe der Trafficsteuerung können Sie zwei Weiterleitungsregeln erstellen, die Traffic über zwei Back-End-Dienste an dieselbe Back-End-Instanzgruppe weiterleiten. Die beiden Back-End-Dienste können mit unterschiedlichen Systemdiagnosen, unterschiedlichen Sitzungsaffinitäten oder unterschiedlichen Richtlinien für die Traffic-Verteilungssteuerung (Verbindungs-Tracking, Verbindungsausgleich und Failover) konfiguriert werden.
  • Mithilfe der Trafficsteuerung können Sie zwei Weiterleitungsregeln erstellen, die Traffic an verschiedene Back-End-Dienste mit unterschiedlichen Back-End-Instanzgruppen weiterleiten. Beispielsweise kann eine Instanzgruppe mit verschiedenen Maschinentypen konfiguriert werden, um den Traffic von einer bestimmten Gruppe von Quell-IP-Adressen besser zu verarbeiten.

Die Trafficsteuerung wird mit einem API-Parameter sourceIPRanges für die Weiterleitungsregel konfiguriert. Weiterleitungsregeln, für die mindestens ein Quell-IP-Bereich konfiguriert ist, werden als Weiterleitungsregeln für die Trafficsteuerung bezeichnet.

Eine Weiterleitungsregel für die Trafficsteuerung kann eine Liste von bis zu 64 Quell-IP-Bereichen enthalten. Sie können die Liste der Quell-IP-Bereiche, die für eine Weiterleitungsregel konfiguriert sind, jederzeit aktualisieren.

Für jede Weiterleitungsregel für die Trafficsteuerung müssen Sie zuerst eine übergeordnete Weiterleitungsregel erstellen. Die übergeordneten und die IP-Weiterleitungsregeln für die Trafficsteuerung haben dieselbe regionale externe IP-Adresse, dasselbe IP-Protokoll und dieselben Portinformationen. Die übergeordnete Weiterleitungsregel enthält jedoch keine Informationen zur Quell-IP-Adresse. Beispiel:

  • Übergeordnete Weiterleitungsregel: IP-Adresse: 198.51.100.1, IP-Protokoll: TCP, Ports: 80
  • Weiterleitungsregel für die Steuerung: IP-Adresse: 198.51.100.1, IP-Protokoll: TCP, Ports: 80, Quell-IP-Bereiche: 203.0.113.0/24

Eine übergeordnete Weiterleitungsregel, die auf einen Back-End-Dienst verweist, kann mit einer Weiterleitungsregel für die Trafficsteuerung weitergeleitet werden, die auf einen Back-End-Dienst oder eine Zielinstanz verweist.

Für eine übergeordnete Weiterleitungsregel können zwei oder mehr Weiterleitungsregeln für die Trafficsteuerung sich überlappende, aber nicht identische IP-Quellbereiche haben. Beispielsweise kann eine Weiterleitungsregeln für die Trafficsteuerung den Quell-IP-Bereich 203.0.113.0/24 und eine andere Weiterleitungsregeln für die Trafficsteuerung für dasselbe übergeordnete Element den Quell-IP-Bereich 203.0.113.0 haben.

Sie müssen alle Weiterleitungsregel für die Trafficsteuerungen löschen, bevor Sie die übergeordnete Weiterleitungsregel löschen können, von der sie abhängig sind.

Informationen zur Verarbeitung eingehender Pakete bei der Verwendung von Weiterleitungsregel für die Trafficsteuerung finden Sie unter Weiterleitungsregelauswahl.

Verhalten der Sitzungsaffinität über Änderungen steuern

In diesem Abschnitt werden die Bedingungen beschrieben, unter denen die Sitzungsaffinität unterbrochen werden kann, wenn die Quell-IP-Bereiche für die Weiterleitungsregel für die Trafficsteuerung aktualisiert werden:

  • Wenn eine vorhandene Verbindung weiterhin derselben Weiterleitungsregel entspricht, nachdem Sie die Quell-IP-Bereiche für eine Weiterleitungsregel für die Trafficsteuerung geändert haben, funktioniert die Sitzungsaffinität nicht. Wenn Ihre Änderung dazu führt, dass eine vorhandene Verbindung mit einer anderen Weiterleitungsregel übereinstimmt, dann gilt:
  • Die Sitzungsaffinität wird unter den folgenden Umständen immer unterbrochen:
    • Die neu abgeglichene Weiterleitungsregel leitet eine hergestellte Verbindung an einen Back-End-Dienst (oder eine Zielinstanz) weiter, der nicht auf die zuvor ausgewählte Back-End-VM verweist.
    • Die neu abgeglichene Weiterleitungsregel leitet eine hergestellte Verbindung an einen Back-End-Dienst weiter, der auf die zuvor ausgewählte Back-End-VM verweist, aber der Back-End-Dienst ist nicht für Folgendes konfiguriert:persistente Verbindungen, wenn Back-Ends fehlerhaft sind und die Back-End-VM die Systemdiagnose des Back-End-Dienstes nicht besteht.
  • Die Sitzungsaffinität kann unterbrochen werden, wenn die neu abgeglichene Weiterleitungsregel eine hergestellte Verbindung an einen Back-End-Dienst weiterleitet und der Back-End-Dienst auf die zuvor ausgewählte VM verweist. Die Kombination aus Sitzungsaffinität und Verbindungs-Tracking-Modus führt zu einem anderen Verbindungs-Tracking-Hash.

Sitzungsaffinität über Steuerungsänderungen beibehalten

In diesem Abschnitt wird beschrieben, wie Sie die Unterbrechung der Sitzungsaffinität vermeiden, wenn die Quell-IP-Bereiche für die Weiterleitungsregel für die Trafficsteuerung aktualisiert werden:

  • Weiterleitungsregeln für die Trafficsteuerung, die auf Back-End-Dienste verweisen. Wenn sowohl die übergeordnete als auch die Weiterleitungsregel für die Trafficsteuerung auf Back-End-Dienste verweisen, müssen Sie manuell prüfen, ob dieSitzungsaffinität undVerbindungs-Tracking-Richtlinie die Einstellungen sindidentisch abgeschlossen. Konfigurationen werden von Google Cloud nicht automatisch abgelehnt, wenn sie nicht identisch sind.
  • Weiterleitungsregel für die Trafficsteuerung, die auf Zielinstanzen verweisen. Eine übergeordnete Weiterleitungsregel, die auf einen Back-End-Dienst verweist, kann mit einer Weiterleitungssteuerung verknüpft werden, die auf eine Zielinstanz verweist. In diesem Fall übernimmt die Weiterleitungsregel für die Trafficsteuerung die Sitzungsaffinität- und Verbindungs-Tracking-Richtlinien von der übergeordneten Weiterleitungsregel.

Eine Anleitung zum Konfigurieren der Trafficsteuerung finden Sie unter Trafficsteuerung konfigurieren.

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.

    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.

Wenn der Load-Balancer IPv6-Traffic unterstützen soll, muss der Back-End-Dienst auf Back-Ends verweisen, die die Anforderungen für die Verarbeitung von IPv6-Traffic erfüllen.

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

Wenn der Load-Balancer IPv6-Traffic unterstützen soll, müssen die Back-Ends die folgenden Voraussetzungen erfüllen:

  • Back-Ends müssen in Dual-Stack-Subnetzen konfiguriert werden, die sich in derselben Region wie die IPv6-Weiterleitungsregel des Load-Balancers befinden. Für die Back-Ends können Sie ein Subnetz verwenden, bei dem ipv6-access-type auf EXTERNAL oder INTERNAL gesetzt ist. Wenn Sie ein Subnetz mit ipv6-access-type auf INTERNAL verwenden, müssen Sie für die externe Weiterleitungsregel des Load-Balancers ein separates Dual-Stack-Subnetz verwenden, wobei ipv6-access-type auf EXTERNAL gesetzt ist. Eine Anleitung finden Sie unter Dual-Stack-Subnetz hinzufügen.
  • Back-End-Instanzgruppen müssen für Dual-Stack konfiguriert sein, wobei --ipv6-network-tier auf PREMIUM gesetzt ist. Eine Anleitung dazu finden Sie unter Instanzvorlage mit IPv6-Adressen erstellen.

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.

IP-Adressen für Anfrage- und Rückgabepakete

Wenn eine Back-End-VM ein Paket mit Load-Balancing von einem Client empfängt, sind die Quelle und das Ziel des Pakets:

  • Quelle: die externe IP-Adresse, die einer Google Cloud-VM oder einer im Internet routingfähigen IP-Adresse eines Systems zugeordnet ist, das eine Verbindung zum Load-Balancer herstellt.
  • Ziel: die IP-Adresse der Weiterleitungsregel des Load-Balancers

Da es sich beim Load-Balancer um einen Pass-Through-Load-Balancer (nicht um einen Proxy) handelt, kommen Pakete an, die die Ziel-IP-Adresse der Weiterleitungsregel des Load-Balancers enthalten. Software, die auf Back-End-VMs ausgeführt wird, sollte so konfiguriert werden, dass sie Folgendes tut:

  • IP-Adresse der Weiterleitungsregel des Load-Balancers oder eine beliebige IP-Adresse (0.0.0.0 oder ::) überwachen und sich daran binden
  • Wenn das Protokoll der Weiterleitungsregel des Load-Balancers Ports unterstützt: Einen Port (binden) überwachen, der in der Weiterleitungsregel des Load-Balancers enthalten ist

Rückgabepakete werden direkt von den Back-End-VMs des Load-Balancers an den Client gesendet. Die Quell- und Ziel-IP-Adressen des Rückgabepakets hängen vom Protokoll ab:

  • TCP ist verbindungsorientiert, sodass Back-End-VMs mit Paketen antworten müssen, deren Quell-IP-Adressen mit der IP-Adresse der Weiterleitungsregel übereinstimmen, sodass der Client die Antwortpakete der entsprechenden TCP-Verbindung zuordnen kann.
  • UDP, ESP, GRE und ICMP sind verbindungslos. Back-End-VMs können Antwortpakete senden, deren Quell-IP-Adressen entweder mit der IP-Adresse der Weiterleitungsregel oder mit einer beliebigen zugewiesenen externen IP-Adresse für die VM übereinstimmen. Im Prinzip erwarten die meisten Clients, dass die Antwort von derselben IP-Adresse kommt, an die sie Pakete gesendet haben.

In der folgenden Tabelle werden die Quellen und Ziele für Antwortpakete zusammengefasst:

Traffictyp Quelle Ziel
TCP Die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Quelle des anfragenden Pakets
UDP, ESP, GRE, ICMP In den meisten Anwendungsfällen die IP-Adresse der Weiterleitungsregel des Load-Balancers Die Quelle des anfragenden Pakets

Wenn eine VM eine externe IP-Adresse hat oder wenn Sie Cloud NAT verwenden, ist es auch möglich, die Quell-IP-Adresse des Antwortpakets auf die primäre interne IPv4-Adresse der VM-NIC festzulegen. Google Cloud oder Cloud NAT ändert die Quell-IP-Adresse des Antwortpakets entweder in die externe IPv4-Adresse der NIC oder in eine externe Cloud NAT-IPv4-Adresse, um das Antwortpaket an die externe IP-Adresse des Clients zu senden. Nicht die IP-Adresse der Weiterleitungsregel als Quelle zu verwenden, ist ein erweitertes Szenario, da der Client ein Antwortpaket von einer externen IP-Adresse empfängt, die nicht mit der IP-Adresse übereinstimmt, an die ein Anfragepaket gesendet wurde.

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. Anhand dieses Hashs wird ein Back-End aus den Back-Ends ausgewählt, die derzeit fehlerfrei sind, es sei denn, alle Back-Ends sind fehlerhaft. In diesem Fall werden alle Back-Ends 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 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 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 Back-End 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_SESSION und die Sitzungsaffinität ist NONE, oder
        • Tracking-Modus ist PER_SESSION und die Sitzungsaffinität ist CLIENT_IP_PORT_PROTO.
      • UDP-, ESP- und GRE-Pakete. Das Verbindungs-Tracking ist nur aktiviert, wenn die Sitzungsaffinität auf etwas anderes als NONE festgelegt 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. 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). 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 nicht NONE ist. UDP-, ESP- und GRE-Pakete werden mit den in dieser Tabelle beschriebenen Tracking-Methoden verfolgt.

  • 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 und ICMPv6, die nicht über die Verbindung nachverfolgbar sind). 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
  • Fragmentierte UDP-, ESP- und GRE-Anfragen: 3-Tupel-Verbindungsverfolgung
  • 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
  • Fragmentierte UDP-, ESP- und GRE-Anfragen: 3-Tupel-Verbindungsverfolgung
  • 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
  • Fragmentierte UDP-, ESP- und GRE-Anfragen: 3-Tupel-Verbindungsverfolgung
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert
  • TCP und nicht fragmentiertes UDP: 5-Tupel-Verbindungs-Tracking
  • Fragmentierte UDP-, ESP- und GRE-Anfragen: 3-Tupel-Verbindungsverfolgung
  • Alle anderen Protokolle: Verbindungs-Tracking ist deaktiviert

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 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 oder die Instanzgruppe aus dem Back-End-Dienst entfernen. 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_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).

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

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 Back-End weiterhin auf Pakete antwortet, wird die Verbindung so lange fortgesetzt, bis sie zurückgesetzt oder geschlossen wird (entweder durch das fehlerhafte Back-End oder den Client).
  • Wenn das fehlerhafte Back-End 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 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

Back-End-Dienst-basierte 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 Back-Ends weiterleiten müssen, verwenden Sie die folgenden Weiterleitungsregel und Back-End-Dienstkonfigurationsparameter:

  • Konfiguration der Weiterleitungsregel: Verwenden Sie nur eine UDP- oder L3_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=ALL festzulegen, oder verwenden Sie die API, um allPorts auf True einzustellen.

  • Konfiguration des Back-End-Diensts: Legen Sie die Sitzungsaffinität des Back-End-Diensts auf CLIENT_IP (2-Tupel-Hash) oder CLIENT_IP_PROTO (3-Tupel-Hash) fest, sodass dasselbe Back-End 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 Back-End-Dienstes auf PER_SESSION, damit die Einträge für das Verbindungs-Tracking-Tabellen mit denselben 2-Tupel- oder 3-Tupel-Hashes erstellt 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 einzige UDP- oder L3_DEFAULT-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.
  • 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.
    • Erstellen oder Ändern eines Netzwerk-Load-Balancers, der eine Richtlinie für das Verbindungs-Tracking konfiguriert.
    • Erstellen oder ändern Sie die IP-basierte Trafficsteuerung für eine Weiterleitungsregel.

    Verwenden Sie stattdessen entweder die Google Cloud-Befehlszeile oder die REST API.

  • Netzwerk-Load-Balancer unterstützen VPC-Netzwerk-Peering nicht.

Nächste Schritte