Backend-Dienst-basierter externer Passthrough-Network-Load-Balancer – Übersicht

Externe Passthrough-Network-Load Balancer sind regionale Layer-4-Load Balancer, die externen Traffic auf Back-Ends (Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs)) in derselben Region wie der Load Balancer verteilen. Diese Back-Ends müssen sich in derselben Region und demselben Projekt befinden, können jedoch in verschiedenen VPC-Netzwerken sein. Diese Load Balancer basieren auf Maglev und dem Andromeda-Netzwerkvirtualisierungs-Stack.

Externe Passthrough-Network Load Balancer können 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

Externe Passthrough-Network Load Balancer sind keine Proxys. Der Load-Balancer selbst beendet Nutzerverbindungen nicht. Pakete mit Load-Balancing werden unverändert an die Backend-VMs mit ihren Quell- und Ziel-IP-Adressen, ihrem Protokoll und gegebenenfalls Ports gesendet. Die Backend-VMs beenden dann Nutzerverbindungen. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Dieser Vorgang wird als direkte Serverrückgabe (DSR, Direct Server Return) bezeichnet.

Backend-Dienst-basierte externe Passthrough-Network Load Balancer unterstützen die folgenden Features:

  • Backends in verwalteten und nicht verwalteten Instanzgruppen. Backend-Dienst-basierte externe Passthrough-Network Load Balancer unterstützen sowohl verwaltete als auch nicht verwaltete Instanzgruppen als Backends. Verwaltete Instanzgruppen automatisieren bestimmte Aspekte der Back-End-Verwaltung und bieten im Vergleich zu nicht verwalteten Instanzgruppen eine bessere Skalierbarkeit und Zuverlässigkeit.
  • Zonale NEG-Back-Ends. Backend-Dienst-basierte externe Passthrough-Network Load Balancer unterstützen die Verwendung von zonalen NEGs mit GCE_VM_IP-Endpunkten. Mit zonalen NEG-GCE_VM_IP-Endpunkten können Sie Folgendes tun:
    • Leiten Sie Pakete an eine beliebige Netzwerkschnittstelle weiter, nicht nur an nic0.
    • Platzieren Sie denselben GCE_VM_IP-Endpunkt in zwei oder mehr zonalen NEGs, die mit verschiedenen Backend-Diensten verbunden sind.
  • Unterstützung mehrerer Protokolle. Backend-Dienst-basierte externe Passthrough-Network-Load Balancer können TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-Traffic verteilen.
  • Unterstützung für IPv6-Konnektivität. Backend-Dienst-basierte externe Passthrough-Network Load Balancer können sowohl IPv4- als auch IPv6-Traffic verarbeiten.
  • Detailgenaue Steuerung der Trafficverteilung. Ein Backend-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität, dem Verbindungs-Tracking-Modus und dem gewichteten Load-Balancing Der Backend-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert und ein Failover-Backend für den Load-Balancer festgelegt wird. Die meisten dieser Einstellungen haben Standardwerte, die einen schnellen Einstieg ermöglichen.
  • Unterstützung für Nicht-Legacy-Systemdiagnosen. Mit Backend-Dienst-basierten externen Passthrough-Network Load Balancern können Sie Systemdiagnosen verwenden, 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 externe Passthrough-Netzwerk-Load Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.

  • GKE-Integration. 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 externen Passthrough-Network-Load Balancers:

Externer Passthrough-Network-Load Balancer mit einem regionalen Backend-Dienst
Externer Passthrough-Network-Load Balancer mit einem regionalen Backend-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
  • Ein oder mehrere Backends: entweder alle Instanzgruppen oder alle zonalen NEG-Backends (GCE_VM_IP-Endpunkte)
  • 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 internen Passthrough-Network-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-Bereich aus einem Dual-Stack-Subnetz mit einem externen IPv6-Subnetzbereich im VPC-Netzwerk. Externe IPv6-Adressen sind nur in der Premium-Stufe verfügbar. Der IPv6-Adressbereich kann eine reservierte statische Adresse oder eine sitzungsspezifische Adresse sein.

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.

Externe Passthrough-Network-Load Balancer unterstützen sowohl die Standardstufe als auch die Premium-Stufe 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 externen Passthrough-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 Frontend 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 Backend-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 einen IPv6-Adressbereich /96 verweist, muss die Weiterleitungsregel einem Subnetz zugeordnet sein und dieses Subnetz muss (a) ein Dual-Stack-Subnetz sein und (b) einen externen IPv6-Subnetz-Bereich haben (--ipv6-access-type auf EXTERNAL festgelegt). Das Subnetz, auf das die Weiterleitungsregel verweist, kann dasselbe Subnetz sein, das von den Backend-Instanzen verwendet wird. Backend-Instanzen können jedoch bei Bedarf ein separates Subnetz verwenden. Wenn Backend-Instanzen ein separates Subnetz verwenden, muss Folgendes zutreffen:

Für einen internen Passthrough-Network-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 Backend-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 Backend-Dienst verweisen. Der Backend-Dienst muss jedoch auf Dual-Stack-Backends verweisen.

Weiterleitungsregelprotokolle

Externe Passthrough-Network-Load Balancer unterstützen 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 externer Passthrough-Network-Load Balancer TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-Traffic verteilen.

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 Backend-Dienst verweisen, der entweder dasselbe Protokoll wie die Weiterleitungsregel oder ein Backend-Dienst mit dem Protokoll UNSPECIFIED. L3_DEFAULT-Weiterleitungsregeln können nur auf einen Backend-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 externen Passthrough-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 Backend-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 Backend-VMs ausgeführte Software so konfigurieren, dass sie an alle externen IP-Adressen der Weiterleitungsregeln des Load-Balancers gebunden wird.

Trafficsteuerung

Weiterleitungsregeln für externe Passthrough-Netzwerk-Load-Balancer können so konfiguriert werden, dass der Traffic von einem bestimmten Bereich von Quell-IP-Adressen an einen bestimmten Backend-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 Backends, eine andere Backend-Dienstkonfiguration oder beides weiterleiten. Beispiel:

  • Mithilfe der Trafficsteuerung können Sie zwei Weiterleitungsregeln erstellen, die Traffic über zwei Backend-Dienste an dieselbe Backend-Instanzgruppe oder -NEG weiterleiten. Die beiden Backend-Dienste können mit unterschiedlichen Systemdiagnosen, unterschiedlichen Sitzungsaffinitäten oder unterschiedlichen Richtlinien für die Traffic-Verteilungssteuerung (Verbindungs-Tracking, Verbindungsausgleich und Failover) konfiguriert werden.
  • Mit der Traffic-Steuerung können Sie eine Weiterleitungsregel erstellen, um Traffic von einem Backend-Dienst mit niedriger Bandbreite an einen Backend-Dienst mit hoher Bandbreite weiterzuleiten. Beide Backend-Dienste enthalten den gleichen Satz an Backend-VMs oder Endpunkten, das Load Balancing erfolgt jedoch über das gewichtete Load Balancing mit unterschiedlichen Gewichtungen.
  • Mithilfe der Trafficsteuerung können Sie zwei Weiterleitungsregeln erstellen, die Traffic an verschiedene Backend-Dienste mit unterschiedlichen Backends (Instanzgruppen oder NEGs) weiterleiten. Beispielsweise kann eine Backend 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 Backend-Dienst verweist, kann mit einer Weiterleitungsregel für die Trafficsteuerung weitergeleitet werden, die auf einen Backend-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 Backend-Dienst (oder eine Zielinstanz) weiter, der nicht auf die zuvor ausgewählte Backend-VM verweist.
    • Die neu abgeglichene Weiterleitungsregel leitet eine hergestellte Verbindung an einen Backend-Dienst weiter, der auf die zuvor ausgewählte Backend-VM verweist, aber der Backend-Dienst ist nicht für Folgendes konfiguriert:persistente Verbindungen, wenn Backends fehlerhaft sind und die Backend-VM die Systemdiagnose des Backend-Dienstes nicht besteht.
  • Die Sitzungsaffinität kann unterbrochen werden, wenn die neu abgeglichene Weiterleitungsregel eine hergestellte Verbindung an einen Backend-Dienst weiterleitet und der Backend-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 Backend-Dienste verweisen. Wenn sowohl die übergeordnete als auch die Weiterleitungsregel für die Trafficsteuerung auf Backend-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 Backend-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 Backend-Dienst

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

Jeder Backend-Dienst definiert die folgenden Backend-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 Backend-Dienst übergibt Pakete an Backend-VMs, wobei die Quell- und Ziel-IP-Adressen des Pakets, das Protokoll und, falls das Protokoll portbasiert ist, die Quell- und Zielports beibehalten.

    Backend-Dienste, die mit externen Passthrough-Netzwerk-Load-Balancern verwendet werden, unterstützen die folgenden Protokolloptionen: TCP, UDP oder UNSPECIFIED.

    Backend-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 Backend-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität, dem Verbindungs-Tracking-Modus und dem gewichteten Load-Balancing Der Backend-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert und ein Failover-Backend für den Load-Balancer festgelegt wird.

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

  • Backends: Jeder Backend-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic entweder auf Instanzgruppen oder zonale NEGs in derselben Region. Sie können Instanzgruppen oder zonale NEGs verwenden, aber keine Kombination aus beiden als Back-Ends für einen externen Passthrough-Network-Load-Balancer:

    • Wenn Sie Instanzgruppen auswählen, können Sie nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen, regionale verwaltete Instanzgruppen oder eine Kombination von Instanzgruppentypen verwenden.
    • Wenn Sie zonale NEGs verwenden, müssen Sie zonale GCE_VM_IP-NEGs verwenden.

    Jede Instanzgruppe oder jedes NEG-Backend ist mit einem VPC-Netzwerk verknüpft, auch wenn diese Instanzgruppe oder NEG noch nicht mit einem Backend-Dienst verbunden ist. Weitere Informationen dazu, wie ein Netzwerk mit jedem Backend-Typ verknüpft wird, finden Sie unter: Instanzgruppen-Backends und Netzwerkschnittstellen und zonale NEG-Backends und Netzwerkschnittstellen.

Instanzgruppen

Ein externer Passthrough-Netzwerk-Load-Balancer verteilt Verbindungen zwischen Backend-VMs in verwalteten oder nicht verwalteten Instanzgruppen. Instanzgruppen können regional oder zonal sein.

Ein externer Passthrough-Network Load Balancer verteilt den Traffic nur auf die erste Netzwerkschnittstelle (nic0) von Backend-VMs. Der Load Balancer unterstützt Instanzgruppen, deren Mitgliedsinstanzen ein beliebiges VPC-Netzwerk in derselben Region verwenden, solange sich das VPC-Netzwerk im selben Projekt wie der Backend-Dienst befindet. Alle VMs innerhalb einer Instanzgruppe müssen dasselbe VPC-Netzwerk verwenden.

Jede Instanzgruppe ist mit einem VPC-Netzwerk verknüpft, auch wenn diese Instanzgruppe noch nicht mit einem Backend-Dienst verbunden ist. Weitere Informationen zum Verknüpfen eines Netzwerks mit Instanzgruppen finden Sie unter Instanzgruppen-Backends und Netzwerkschnittstellen.

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

    Externer Passthrough-Network-Load Balancer mit einer regional verwalteten Instanzgruppe
    Externer Passthrough-Network-Load Balancer mit einer regional 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.

    Externer Passthrough-Network-Load Balancer mit zonal verwalteten Instanzgruppen
    Externer Passthrough-Network-Load Balancer mit zonal verwalteten Instanzgruppen

Zonale NEGs

Ein externer Passthrough-Network Load Balancer verteilt Verbindungen zwischen GCE_VM_IP-Endpunkten, die in zonalen Netzwerk-Endpunktgruppen enthalten sind. Diese Endpunkte müssen sich in derselben Region wie der Load Balancer befinden. Einige empfohlene Anwendungsfälle für zonale NEG finden Sie unter Übersicht über zonale Netzwerk-Endpunktgruppen.

Endpunkte in der NEG müssen primäre interne IPv4-Adressen von VM-Netzwerkschnittstellen sein, die sich im selben Subnetz und in derselben Zone wie die zonale NEG befinden. Die primäre interne IPv4-Adresse einer Netzwerkschnittstelle einer VM-Instanz mit mehreren NICs kann einer NEG hinzugefügt werden, solange sie sich im Subnetz der NEG befindet.

Zonale NEGs unterstützen sowohl IPv4- als auch Dual-Stack-VMs (IPv4 und IPv6). Sowohl für IPv4- als auch für Dual-Stack-VMs reicht es aus, beim Anhängen eines Endpunkts an eine NEG nur die VM-Instanz anzugeben. Sie müssen die IP-Adresse des Endpunkts nicht angeben. Die VM-Instanz muss sich immer in derselben Zone wie die NEG befinden.

Jede zonale NEG ist mit einem VPC-Netzwerk und einem Subnetz verknüpft, auch wenn diese zonale NEG noch nicht mit einem Backend-Dienst verbunden ist. Weitere Informationen dazu, wie ein Netzwerk mit zonalen NEGs verknüpft wird, finden Sie unter Zonale NEG-Back-Ends und Netzwerkschnittstellen.

Instanzgruppen-Back-Ends und Netzwerkschnittstellen

Das mit einer Instanzgruppe verknüpfte VPC-Netzwerk ist das VPC-Netzwerk, das von der Netzwerkschnittstelle nic0 jeder Mitglied-VM verwendet wird.

  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk für die Instanzgruppe als das VPC-Netzwerk definiert, das von der Netzwerkschnittstelle nic0 der ersten VM-Instanz verwendet wird, die Sie der nicht verwalteten Instanzgruppe hinzufügen.

Innerhalb einer bestimmten (verwalteten oder nicht verwalteten) Instanzgruppe müssen alle VM-Instanzen die nic0-Netzwerkschnittstellen im selben VPC-Netzwerk haben. Jede Mitglieds-VM kann optional zusätzliche Netzwerkschnittstellen (nic1 bis nic7) haben, aber jede Netzwerkschnittstelle muss an ein anderes VPC-Netzwerk angehängt werden. Diese Netzwerke müssen sich auch von dem VPC-Netzwerk unterscheiden, das der Instanzgruppe zugeordnet ist.

Backend-Dienste können Traffic nicht an Instanzgruppenmitglied-VMs auf Schnittstellen verteilen, die nicht nic0 sind. Wenn Sie Traffic über eine nicht standardmäßige Netzwerkschnittstelle (nic1 bis nic7) empfangen möchten, müssen Sie zonale NEGs mit GCE_VM_IP-Endpunkten verwenden.

Zonale NEG-Back-Ends und Netzwerkschnittstellen

Wenn Sie eine neue zonale NEG mit GCE_VM_IP-Endpunkten erstellen, müssen Sie die NEG explizit mit einem Subnetzwerk eines VPC-Netzwerks verknüpfen, bevor Sie der NEG Endpunkte hinzufügen können. Weder das Subnetz noch das VPC-Netzwerk können nach dem Erstellen der NEG geändert werden.

Innerhalb einer bestimmten NEG stellt jeder GCE_VM_IP-Endpunkt tatsächlich eine Netzwerkschnittstelle dar. Die Netzwerkschnittstelle muss sich in dem Subnetzwerk befinden, das der NEG zugeordnet ist. Aus Sicht einer Compute Engine-Instanz kann die Netzwerkschnittstelle eine beliebige Kennung verwenden (nic0 bis nic7). Aus der Perspektive eines Endpunkts in einer NEG wird die Schnittstelle anhand ihrer primären IPv4-Adresse identifiziert.

Es gibt zwei Möglichkeiten, einer NEG einen GCE_VM_IP-Endpunkt hinzuzufügen:

  • Wenn Sie beim Hinzufügen eines Endpunkts nur einen VM-Namen (ohne IP-Adresse) angeben, erfordert Google Cloud, dass die VM eine Netzwerkschnittstelle in dem Subnetzwerk hat, das der NEG zugeordnet ist. Die IP-Adresse, die Google Cloud für den Endpunkt auswählt, ist die primäre interne IPv4-Adresse der Netzwerkschnittstelle der VM im Subnetzwerk, das der NEG zugeordnet ist.
  • Wenn Sie beim Hinzufügen eines Endpunkts sowohl einen VM-Namen als auch eine IP-Adresse angeben, muss die von Ihnen angegebene IP-Adresse eine primäre interne IPv4-Adresse für eine der Netzwerkschnittstellen der VM sein. Diese Netzwerkschnittstelle muss sich in dem Subnetzwerk befinden, das mit der NEG verknüpft ist. Beachten Sie, dass die Angabe einer IP-Adresse redundant ist, da es nur eine einzige Netzwerkschnittstelle geben kann, die sich im Subnetzwerk befindet, das der NEG zugeordnet ist.

Backend-Dienste und VPC-Netzwerke

Der Backend-Dienst ist keinem VPC-Netzwerk zugeordnet. Jede Backend-Instanzgruppe oder zonale NEG ist jedoch wie bereits erwähnt einem VPC-Netzwerk zugeordnet. Solange sich alle Back-Ends in derselben Region und demselben Projekt befinden und alle Back-Ends vom selben Typ (Instanzgruppen oder zonale NEGs) sind, können Sie Back-Ends hinzufügen, die entweder dasselbe oder unterschiedliche VPC-Netzwerke verwenden.

Um Pakete an nic1 bis nic7 zu verteilen, müssen Sie zonale NEG-Back-Ends (mit GCE_VM_IP-Endpunkten) verwenden, da das verknüpfte VPC-Netzwerk einer Instanzgruppe immer dem verwendeten VPC-Netzwerk entspricht, das von der nic0-Schnittstelle aller Mitgliedsinstanzen verwendet wird.

Dual-Stack-Back-Ends (IPv4 und IPv6)

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-Ends 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

Externe Passthrough-Network-Load Balancer verwenden regionale Systemdiagnosen, um zu bestimmen, zu welchen Instanzen neue Verbindungen aufgebaut werden können. Der Backend-Dienst jedes externen Passthrough-Network-Load Balancers muss einer regionalen Systemdiagnose zugeordnet sein. Load-Balancer verwenden den Systemdiagnosestatus, um zu bestimmen, wie neue Verbindungen an Backend-Instanzen weitergeleitet werden.

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

Externe Passthrough-Network-Load Balancer unterstützen die folgenden Arten von Systemdiagnosen:

Systemdiagnosen für anderen Protokolltraffic

Google Cloud bietet außer den hier aufgeführten keine weiteren protokollspezifischen Systemdiagnosen an. Wenn Sie einen externen Passthrough-Netzwerk-Load-Balancer für das Load-Balancing eines anderen Protokolls als TCP verwenden, müssen Sie dennoch einen TCP-basierten Dienst auf Ihren Backend-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 Backend-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 es sich bei externen Passthrough-Netzwerk-Load-Balancern um Passthrough-Load-Balancer handelt, 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).

  • Externe Passthrough-Network Load Balancer verwenden 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 Backend-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 Backend-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 Backend-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 Backend-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. Backend-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

Externe Passthrough-Netzwerk-Load-Balancer nutzen spezielle Routen außerhalb Ihres VPC-Netzwerks, um eingehende Anfragen und Systemdiagnoseprüfungen an jede Backend-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 externen Passthrough-Network-Load Balancers im selben Projekt vorhanden sein. In der folgenden Tabelle sind die Komponenten einer freigegebenen VPC für externe Passthrough-Network-Load Balancer 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 Backend-Dienst muss im selben Projekt und in derselben Region wie die Backends (Instanzgruppe oder zonale NEG) 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 externe Passthrough-Netzwerk-Load-Balancer neue Netzwerkverbindungen verteilen, hängt davon ab, ob Sie ein Failover konfiguriert haben:

  • Wenn Sie kein Failover konfiguriert haben, verteilt ein interner Passthrough-Network-Load Balancer neue Verbindungen an seine fehlerfreien Backend-VMs, wenn wenigstens eine Backend-VM fehlerfrei ist. Wenn alle Backend-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Backends. In diesem Fall leitet der Load-Balancer jede neue Verbindung an eine fehlerhafte Backend-VM weiter.
  • Wenn Sie einen Failover konfiguriert haben, verteilt ein externer Passthrough-Netzwerk-Load-Balancer gemäß einer von Ihnen konfigurierten Failover-Richtlinie neue Verbindungen zwischen fehlerfreien Backend-VMs in seinem aktiven Pool. When all backend VMs are unhealthy, you can choose from one of the following behaviors:
    • (Standardeinstellung) Der Load-Balancer verteilt den Traffic nur auf die primären VMs. Dies wird als letztes Mittel unternommen. Die Backup-VMs sind von dieser letztes-Mittel-Verteilung der Verbindungen ausgeschlossen.
    • Der Load-Balancer verwirft den Traffic.

Weitere Informationen zur Verteilung von Verbindungen finden Sie im nächsten Abschnitt: Back-End-Auswahl und Verbindungs-Tracking.

Weitere Informationen zur Funktionsweise des Failovers finden Sie im Abschnitt Failover.

Auswahl von Backend und Verbindungs-Tracking

Externe Passthrough-Netzwerk-Load-Balancer verwenden konfigurierbare Algorithmen zur Auswahl von Backend und Verbindungs-Tracking, um zu bestimmen, wie der Traffic an Backend-VMs verteilt wird.

Externe Passthrough-Netzwerk-Load-Balancer verwenden den folgenden Algorithmus, um Pakete zwischen Backend-VMs zu verteilen (in seinem aktiven Pool, wenn Sie ein Failover konfiguriert haben):

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

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

    1. Der Load-Balancer wählt ein Backend aus. Der Load-Balancer berechnet einen Hash anhand der konfigurierten Sitzungsaffinität. Anhand dieses Hashs wird ein Backend aus den Backends ausgewählt, die derzeit fehlerfrei sind, es sei denn, alle Backends sind fehlerhaft. In diesem Fall werden alle Backends so lange berücksichtigt, wie die Failover-Richtlinie in dieser Situation nicht dafür konfiguriert wurde, den Traffic zu unterbrechen. Die Standard-Sitzungsaffinität, NONE, verwendet die folgenden Hash-Algorithmen:

      • Bei TCP- und nicht fragmentierten UDP-Paketen ein 5-Tupel-Hash der Quell-IP-Adresse des Pakets, des Quellports, der Ziel-IP-Adresse, des Zielports und des Protokolls.
      • Für fragmentierte UDP-Pakete und alle anderen Protokolle ein 3-Tupel-Hash der Quell-IP-Adresse des Pakets, der Ziel-IP-Adresse und des Protokolls.

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

      Außerdem sollten Sie Folgendes beachten:

      Wenn Sie das gewichtete Load-Balancing aktivieren, wird die hashbasierte Backend-Auswahl basierend auf den von den Backend-Instanzen gemeldeten Gewichtungen gewichtet. Beispiel:

      • Betrachten Sie einen Backend-Dienst, für den die Sitzungsaffinität auf NONE gesetzt ist und eine Weiterleitungsregel mit dem Protokoll UDP konfiguriert wurde. Sind zwei fehlerfreie Backend-Instanzen mit den Gewichtungen 1 und 4 vorhanden, erhalten die Backends 20 %, bzw. 80 % der UDP-Pakete.
      • Betrachten Sie einen Backend-Dienst, der mit 3-Tupel-Sitzungsaffinität und Verbindungs-Tracking konfiguriert ist. Die Sitzungsaffinität ist CLIENT_IP_PROTO und der Modus für das Verbindungs-Tracking ist PER_SESSION. Sind drei fehlerfreie Backend-Instanzen mit den Gewichtungen 0, 2 und 6 vorhanden, erhalten die Backends Traffic für 0 %, 25 % und 75 % der neuen Quell-IP-Adressen (die Quell-IP-Adressen für die keine Tabelleneinträge für das Verbindungs-Tracking vorhanden sind). Der Traffic für vorhandene Verbindungen wird an die zuvor zugewiesenen Back-Ends weitergeleitet.

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

      • TCP-Pakete. Verbindungs-Tracking ist immer aktiviert und kann nicht deaktiviert werden. Standardmäßig verwendet das Verbindungs-Tracking ein 5-Tupel. Es kann aber so konfiguriert werden, dass es weniger als ein 5-Tupel verwendet. Beim 5-Tupel werden TCP-SYN-Pakete unterschiedlich behandelt. Im Gegensatz zu Nicht-SYN-Paketen werden alle übereinstimmenden Verbindungs-Tracking-Einträge verworfen und es wird immer ein neues Backend ausgewählt.

        Das standardmäßige 5-Tupel-Verbindungs-Tracking wird in folgenden Fällen verwendet:

        • Tracking-Modus ist PER_CONNECTION (alle Sitzungsaffinitäten), oder
        • Tracking-Modus ist PER_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 Backend-Dienst und nicht für jedes Backend angegeben.

Externe Passthrough-Network Load Balancer unterstützen die folgenden Optionen für die Sitzungsaffinität:

  • Keine (NONE) 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport
  • Client-IP, Ziel-IP (CLIENT_IP). 2-Tupel-Hash von Quell-IP-Adresse und Ziel-IP-Adresse
  • Client-IP, Ziel-IP, Protokoll (CLIENT_IP_PROTO). 3-Tupel-Hash von Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll
  • Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (CLIENT_IP_PORT_PROTO). 5-Tupel-Hash von Quell-IP-Adresse, Quellport, Protokoll, Ziel-IP-Adresse und Zielport

Informationen dazu, wie sich diese Optionen der Sitzungsaffinität auf die Back-End-Auswahl und die Methoden des Verbindungs-Trackings auswirken, finden Sie in dieser Tabelle.

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.

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

(NONE)

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 einer ausgewählten Back-End-VM oder einem ausgewählten Endpunkt verbleibt, nachdem das Back-End fehlerhaft wird, solange das Back-End in der konfigurierten Back-End-Gruppe des Load-Balancers (in einer Instanzgruppe oder einer NEG) verbleibt.

Das in diesem Abschnitt beschriebene Verhalten gilt nicht für Fälle, in denen Sie eine Back-End-Instanz aus einer Instanzgruppe entfernt oder einen Back-End-Endpunkt aus ihrer NEG entfernt oder die Instanzgruppe oder die NEG vom Backend-Dienst entfernt haben. In solchen Fällen bleiben vorhandene Verbindungen nur bestehen, wie unter Verbindungsausgleich beschrieben.

Die folgenden Optionen für die Verbindungspersistenz sind verfügbar:

  • DEFAULT_FOR_PROTOCOL (Standard)
  • NEVER_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 Backend weiterhin auf Pakete antwortet, wird die Verbindung so lange fortgesetzt, bis sie zurückgesetzt oder geschlossen wird (entweder durch das fehlerhafte Backend oder den Client).
  • Wenn das fehlerhafte Backend ein TCP-Rücksetzpaket (RST) sendet oder nicht auf Pakete antwortet, kann der Client es mit einer neuen Verbindung versuchen. Der Load-Balancer kann dann ein anderes, fehlerfreies Backend auswählen. TCP-SYN-Pakete wählen immer ein neues, fehlerfreies Backend aus.

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

Gewichtetes Load Balancing

Sie können einen Network-Load Balancer so konfigurieren, dass der Traffic auf den Backend-Instanzen des Load Balancers basierend auf den von einer HTTP-Systemdiagnose gemeldeten Gewichtungen mit gewichtetem Load Balancing verteilt wird.

Für das gewichtete Load Balancing müssen Sie Folgendes konfigurieren:

  • Sie müssen die Ort-Load Balancer-Richtlinie (localityLbPolicy) des Backend-Dienstes auf WEIGHTED_MAGLEV festlegen.
  • Sie müssen den Backend-Dienst mit einer HTTP-Systemdiagnose konfigurieren. Die Antworten der HTTP-Systemdiagnose müssen das benutzerdefinierte Feld X-Load-Balancing-Endpoint-Weight des HTTP-Antwortheaders enthalten, um die Gewichtungen mit Werten von 0 bis 1000 pro Backend-Instanz anzugeben.

Wenn Sie dasselbe Backend (Instanzgruppe oder NEG) für mehrere Backend-Dienst-basierte externe Passthrough-Network Load Balancer mit gewichtetem Load-Balancing verwenden, empfehlen wir die Verwendung eines eindeutigen request-path für jede Systemdiagnose des Backends. Dadurch kann die Endpunktinstanz verschiedenen Backend-Diensten unterschiedliche Gewichtungen zuweisen. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen.

Zur Auswahl eines Backends für eine neue Verbindung wird Backends eine strenge Prioritätsreihenfolge basierend auf ihrer Gewichtung und ihrem Systemstatus zugewiesen, wie in der folgenden Tabelle dargestellt:

Gewicht Fehlerfrei Priorität für Backend-Auswahl
Gewichtung größer als null Ja 4
Gewichtung größer als null Nein 3
Gewichtung ist gleich null Ja 2
Gewichtung ist gleich null Nein 1

Nur die Backends mit der höchsten Priorität kommen für die Backend-Auswahl in Frage. Haben alle in Frage kommenden Back-Ends eine Nullgewichtung, verteilt der Load-Balancer neue Verbindungen zwischen allen zulässigen Back-Ends und behandelt sie, als wären sie alle gleich gewichtet. Beispiele für das gewichtete Load Balancing finden Sie unter Backend-Auswahl und Verbindungs-Tracking.

Das gewichtete Load Balancing kann in den folgenden Szenarien verwendet werden:

  • Wenn einige Verbindungen mehr Daten als andere verarbeiten oder einige Verbindungen länger bestehen als andere, kann die Verteilung der Backend-Last ungleichmäßig sein. Durch die Signalisierung einer niedrigeren Gewichtung pro Instanz kann eine Instanz mit hoher Auslastung den Anteil der neuen Verbindungen verringern und gleichzeitig die bestehenden Verbindungen bedienen.

  • Wenn ein Backend überlastet ist und die Zuweisung weiterer Verbindungen zum Bruch bestehender Verbindungen führen kann, können solche Verbindungen sich selbst eine Nullgewichtung zuordnen. Durch die Meldung einer Nullgewichtung nimmt eine Backend-Instanz keine neuen Verbindungen mehr an, verarbeitet jedoch weiterhin vorhandene Verbindungen.

  • Wenn ein Backend vorhandene Verbindungen vor der Wartung schnell bearbeitet, weist es sich selbst eine Nullgewichtung zu. Durch die Meldung einer Nullgewichtung nimmt eine Backend-Instanz keine neuen Verbindungen mehr an, verarbeitet jedoch weiterhin vorhandene Verbindungen.

Weitere Informationen finden Sie unter Gewichtetes Load Balancing konfigurieren.

Verbindungsausgleich

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

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

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

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

UDP-Fragmentierung

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

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

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

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

Zielinstanzen als Back-Ends verwenden

Wenn Sie Zielinstanzen als Back-Ends für den externen Passthrough-Netzwerk-Load-Balancer verwenden und fragmentierte UDP-Pakete erwarten, verwenden Sie nur eine einzige UDP- oder L3_DEFAULT-Weiterleitungsregel pro IP-Adresse und konfigurieren Sie die Weiterleitungsregel so, dass Traffic an allen Ports zugelassen wird. 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 externen Passthrough-Network-Load Balancer konfigurieren, damit Verbindungen zwischen VM-Instanzen oder Endpunkten in primären Backends (Instanzgruppen oder NEGs) verteilt werden und dann bei Bedarf auf Failover-Backends gewechselt wird. Failover bietet noch eine Methode zur Erhöhung der Verfügbarkeit und ermöglicht gleichzeitig eine bessere Kontrolle darüber, wie Ihre Arbeitslast verwaltet wird, wenn Ihre primären Back-Ends nicht fehlerfrei sind.

Wenn Sie ein Backend zu einem Backend-Dienst eines externen Passthrough-Network-Load-Balancers hinzufügen, ist dieses Backend standardmäßig ein primäres Backend. Sie können ein Backend als Failover-Backend festlegen, wenn Sie es dem Backend-Dienst des Load-Balancers hinzufügen oder den Backend-Dienst später bearbeiten.

Weitere Informationen zur Funktionsweise des Failovers finden Sie unter Failover-Übersicht für externe Passthrough-Network-Load Balancer.

Beschränkungen

  • Die Google Cloud Console bietet keine Möglichkeiten zur Ausführung folgender Aufgaben:

    • Erstellen oder Ändern eines externen Passthrough-Network-Load Balancers, dessen Weiterleitungsregel das L3_DEFAULT-Protokoll verwendet.
    • Erstellen oder Ändern eines externen Passthrough-Netzwerk-Load-Balancers, dessen Backend-Dienstprotokoll auf UNSPECIFIED gesetzt ist.
    • Erstellen oder Ändern eines externen Passthrough-Network-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.

  • Externe Passthrough-Netzwerk-Load-Balancer unterstützen kein VPC-Netzwerk-Peering.

Nächste Schritte