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 Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß der konfigurierten Sitzungsaffinität, der Verbindungs-Tracking-Richtlinie und den Einstellungen für das gewichtete Load Balancing. Der Back-End-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert und Failover-Back-Ends für den Load Balancer festgelegt werden. Die meisten dieser Einstellungen haben Standardwerte, die einen schnellen Einstieg ermöglichen. Weitere Informationen finden Sie unter Trafficverteilung für externe Passthrough-Network Load Balancer.
  • 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, derGoogle 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.

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 einesGoogle 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, wird die Sitzungsaffinität nicht unterbrochen. 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 die Sitzungsaffinität und Verbindungs-Tracking-Richtlinie die Einstellungen sindidentisch abgeschlossen. Google Cloud lehnt Konfigurationen nicht automatisch ab, 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 Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß der konfigurierten Sitzungsaffinität, der Verbindungs-Tracking-Richtlinie und den Einstellungen für das gewichtete Load Balancing. Der Back-End-Dienst kann auch so konfiguriert werden, dass der Verbindungsausgleich aktiviert und Failover-Back-Ends für den Load Balancer festgelegt werden. Die meisten dieser Einstellungen haben Standardwerte, die einen schnellen Einstieg ermöglichen. Weitere Informationen finden Sie unter Trafficverteilung für externe Passthrough-Network Load Balancer.

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

Der externe Passthrough-Network-Load Balancer ist standardmäßig hochverfügbar. Es gibt keine speziellen Schritte, um den Load-Balancer hochverfügbar zu machen, da der Mechanismus nicht auf einem einzelnen Gerät oder einer einzigen VM-Instanz beruht. Sie müssen nur dafür sorgen, dass Ihre Back-End-VM-Instanzen in mehreren Zonen bereitgestellt werden, damit der Load Balancer mögliche Probleme in einer bestimmten Zone umgehen kann.

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

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

    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, Google Cloud erfordert Google Cloud, dass die VM eine Netzwerkschnittstelle in dem Subnetzwerk hat, das der NEG zugeordnet ist. Die IP-Adresse, die Google Cloudfü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.

Wenn Sie Pakete an eine andere Schnittstelle als nic0 verteilen möchten, müssen Sie zonale NEG-Back-Ends (mit GCE_VM_IP-Endpunkten) verwenden.

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

Wenn der Load Balancer Dual-Stack-Back-Ends verwenden soll, die sowohl IPv4- als auch IPv6-Traffic verarbeiten, beachten Sie die folgenden Anforderungen:

  • 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 ipv6-access-type des Backend-Subnetzes auf INTERNAL gesetzt ist, müssen Sie für die externe Weiterleitungsregel des Load Balancers ein anderes reines IPv6-Subnetz verwenden, bei dem ipv6-access-type auf EXTERNAL gesetzt ist.
  • Back-Ends müssen für Dual-Stack konfiguriert sein, wobei stack-type auf IPv4_IPv6 gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie auch --ipv6-network-tier auf PREMIUM setzen. Eine Anleitung dazu finden Sie unter Instanzvorlage mit IPv6-Adressen erstellen.

Nur IPv6-Backends

Wenn der Load Balancer nur IPv6-Back-Ends verwenden soll, beachten Sie die folgenden Anforderungen:

  • Reine IPv6-Instanzen werden nur in nicht verwalteten Instanzgruppen unterstützt. Andere Backend-Typen werden nicht unterstützt.
  • Back-Ends müssen entweder in Dual-Stack- oder IPv6-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 INTERNAL oder EXTERNAL gesetzt ist. Wenn ipv6-access-type des Back-End-Subnetzes auf INTERNAL gesetzt ist, müssen Sie für die externe Weiterleitungsregel des Load Balancers ein anderes IPv6-Subnetz verwenden, bei dem ipv6-access-type auf EXTERNAL gesetzt ist.
  • Back-Ends müssen für IPv6-only konfiguriert sein, wobei stack-type der VM auf IPv6_ONLY gesetzt ist. Wenn ipv6-access-type des Backend-Subnetzes auf EXTERNAL gesetzt ist, müssen Sie auch --ipv6-network-tier auf PREMIUM setzen. Eine Anleitung dazu finden Sie unter Instanzvorlage mit IPv6-Adressen erstellen.

Reine IPv6-VMs können sowohl in Dual-Stack- als auch in reinen IPv6-Subnetzen erstellt werden. Dual-Stack-VMs können jedoch nicht in reinen IPv6-Subnetzen erstellt werden.

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 Back-End-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 im Abschnitt Systemdiagnosen oben auf dieser Seite 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 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 Google Cloud Standard-VPC-Netzwerk 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 routbaren 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.

Ausgehende Internetverbindung von Backends

VM-Instanzen, die als Backend-Endpunkte eines externen Passthrough-Network Load Balancers konfiguriert sind, können Verbindungen zum Internet herstellen, indem die IP-Adresse der Weiterleitungsregel des Load Balancers als Quell-IP-Adresse der ausgehenden Verbindung verwendet wird.

Im Allgemeinen verwendet eine VM-Instanz immer ihre eigene externe IP-Adresse oder Cloud NAT, um Verbindungen zu initiieren. Sie verwenden die IP-Adresse der Weiterleitungsregel, um Verbindungen von Backend-Endpunkten nur in speziellen Fällen zu initiieren, z. B. wenn VM-Instanzen Verbindungen von und zur selben externen IP-Adresse herstellen und empfangen müssen und Sie außerdem die Backend-Redundanz benötigen, die der externe Passthrough-Network-Load Balancer für eingehende Verbindungen bietet.

Für ausgehende Pakete, die von Backend-VMs direkt an das Internet gesendet werden, gelten keine Einschränkungen für Traffic-Protokolle und -Ports. Auch wenn für ein ausgehendes Paket die IP-Adresse der Weiterleitungsregel als Quelle verwendet wird, müssen das Protokoll und der Quellport des Pakets nicht mit der Protokoll- und Portspezifikation der Weiterleitungsregel übereinstimmen. Eingehende Antwortpakete müssen jedoch mit der IP-Adresse, dem Protokoll und dem Zielport der Weiterleitungsregel übereinstimmen. Weitere Informationen finden Sie unter Pfade für externe Passthrough-Network Load Balancer und externe Weiterleitung von Protokollen.

Außerdem unterliegen alle Antworten auf die ausgehenden Verbindungen der VM dem Load Balancing, genau wie alle anderen eingehenden Pakete, die für den Load Balancer bestimmt sind. Das bedeutet, dass Antworten möglicherweise nicht auf derselben Backend-VM eintreffen, die die Verbindung zum Internet initiiert hat. Wenn die ausgehenden Verbindungen und die ausbalancierten eingehenden Verbindungen gemeinsame Protokolle und Ports verwenden, können Sie einen der folgenden Vorschläge ausprobieren:

  • Synchronisieren Sie den Status der ausgehenden Verbindung zwischen den Backend-VMs, damit Verbindungen auch dann bereitgestellt werden können, wenn Antworten bei einer anderen Backend-VM als derjenigen eintreffen, die die Verbindung initiiert hat.

  • Verwenden Sie eine Failover-Konfiguration mit einer einzelnen primären VM und einer einzelnen Sicherungs-VM. Die aktive Backend-VM, die die ausgehenden Verbindungen initiiert, empfängt dann immer die Antwortpakete.

Dieser Pfad zur Internetverbindung über die Backends eines externen Passthrough-Network Load Balancers ist das standardmäßige beabsichtigte Verhalten gemäß den impliziten Firewallregeln von Google Cloud. Wenn Sie jedoch sicherheitbezogene Bedenken haben, diesen Pfad offen zu lassen, können Sie gezielte Firewallregeln für den ausgehenden Traffic verwenden, um unerwünschten ausgehenden Traffic ins Internet zu blockieren.

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

Externe Passthrough-Network Load Balancer unterstützen eine Vielzahl von Optionen zur Anpassung der Trafficverteilung, darunter Sitzungsaffinität, Verbindungs-Tracking, gewichteter Load Balancing und Failover. Weitere Informationen dazu, wie externe Passthrough-Network Load Balancer Traffic verteilen und wie diese Optionen miteinander interagieren, finden Sie unter Trafficverteilung 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-Network-Load-Balancer unterstützen kein VPC-Netzwerk-Peering.

Preise

Preisinformationen finden Sie unter Preise.

Nächste Schritte