Übersicht über internes TCP/UDP-Load-Balancing

Das interne TCP/UDP-Load-Balancing von Google Cloud ist ein regionaler Load-Balancer, der auf dem Virtualisierungsstacks für das Andromeda-Netzwerk basiert.

Das interne TCP/UDP-Load-Balancing verteilt den Traffic auf interne VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud). Sie können damit Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren. Zugriff darauf ist nur für Systeme im selben VPC-Netzwerk oder für Systeme verfügbar, die mit Ihrem VPC-Netzwerk verbunden sind.

Ein interner TCP/UDP-Load-Balancing-Dienst hat ein Front-End (die Weiterleitungsregel) und ein Back-End (den Back-End-Dienst). Sie können für den Back-End-Dienst entweder Instanzgruppen oder GCE_VM_IP zonale NEGs als Back-Ends verwenden. Dieses Beispiel zeigt Instanzgruppen-Back-Ends.

Allgemeines Beispiel für einen internen TCP/UDP-Load-Balancer
Allgemeines Beispiel für einen internen TCP/UDP-Load-Balancer (zum Vergrößern anklicken)

Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:

Anwendungsfälle

In folgenden Fällen sollten Sie internes TCP/UDP-Load-Balancing verwenden:

  • Sie benötigen einen leistungsstarken Pass-Through-Layer-4-Load-Balancer für TCP- oder UDP-Traffic
  • Wenn der Traffic über TLS (SSL) bereitgestellt wird, ist es zulässig, SSL-Traffic von Ihren Back-Ends und nicht vom Load-Balancer beenden zu lassen. Der interne TCP/UDP-Load-Balancer kann SSL-Traffic nicht beenden.

  • Sie müssen die ursprünglichen Pakete ohne Proxy weiterleiten. Zum Beispiel, wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.

  • Sie haben bereits eine Konfiguration, in der ein Pass-Through-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.

Die internen TCP/UDP-Load-Balancer decken viele Anwendungsfälle ab. Dieser Abschnitt enthält einige allgemeine Beispiele.

Zugriffsbeispiele

In Ihrem VPC-Netzwerk können Sie über ein verbundenes Netzwerk auf einen internen TCP/UDP-Load-Balancer mit Folgendem zugreifen:

  • VPC-Netzwerk-Peering
  • Cloud VPN und Cloud Interconnect

Detaillierte Beispiele finden Sie unter Internes TCP/UDP-Load-Balancing und verbundene Netzwerke.

Beispiel für einen dreischichtigen Webdienst

Sie können das interne TCP/UDP-Load-Balancing zusammen mit anderen Load-Balancern verwenden. Beispiel: Wenn Sie einen externen HTTP(S)-Load-Balancer einbinden, ist der externe HTTP(S)-Load-Balancer die Webebene und baut auf Diensten hinter dem internen TCP/UDP-Load Balancer auf.

Das folgende Diagramm zeigt ein Beispiel für eine Konfiguration mit drei Ebenen, bei der externe HTTP(S)-Load-Balancer und interne TCP/UDP-Load-Balancer verwendet werden:

Dreistufige Webanwendung mit HTTP(S)-Load-Balancing und internem TCP/UDP-Load-Balancing.
Webanwendung mit drei Ebenen mit HTTP(S)-Load-Balancing und internem TCP/UDP-Load-Balancing (zum Vergrößern anklicken)

Webdienst mit drei Ebenen und globalem Zugriff

Wenn Sie den globalen Zugriff aktivieren, können sich Ihre VMs auf Webebene in einer anderen Region befinden, wie im folgenden Diagramm dargestellt.

In diesem Beispiel für eine Anwendung mit mehreren Ebenen wird Folgendes gezeigt:

  • Eine global verfügbare internetorientierte Webebene, bei der der Traffic mit HTTP(S)-Load-Balancing verteilt wird
  • Eine interne Back-End-Datenbankstufe mit Load-Balancing in der Region us-east1, auf die von der globalen Webebene zugegriffen wird.
  • Eine Client-VM, die Teil der Webebene in der Region europe-west1 ist, die auf die interne Datenbankebene mit Load-Balancing in us-east1 zugreift.
Dreistufige Webanwendung mit HTTP(S)-Load-Balancing, globalem Zugriff und internem TCP/UDP-Load-Balancing.
Webanwendung mit drei Ebenen mit HTTP(S)-Load-Balancing, globalem Zugriff und internem TCP/UDP-Load-Balancing (zum Vergrößern klicken)

Interne TCP/UDP-Load-Balancer als nächste Hops verwenden

Sie können einen internen TCP/UDP-Load-Balancer als nächstes Gateway verwenden, an das Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Dazu legen Sie den Load-Balancer als nächsten Hop in einer benutzerdefinierten statischen Route fest.

Ein interner TCP/UDP-Load-Balancer, der als nächster Hop in einer benutzerdefinierten Route bereitgestellt wird, verarbeitet den gesamten Traffic, unabhängig vom Protokoll (TCP, UDP oder ICMP).

Im Folgenden finden Sie eine Beispielarchitektur mit einem internen TCP/UDP-Load-Balancer als nächstem Hop zu einem NAT-Gateway. Sie können Traffic an die Back-Ends Ihrer virtuellen Firewall- oder Gateway-Appliance über einen internen TCP/UDP-Load-Balancer weiterleiten.

NAT-Anwendungsfall (zum Vergrößern klicken)
NAT-Anwendungsfall (zum Vergrößern klicken)

Weitere Anwendungsfälle:

  • Hub-and-Spoke – Austauschen von Routen für den nächsten Hop mithilfe von VPC-Netzwerk-Peering: Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances für den nächsten Hop im hub-VPC-Netzwerk konfigurieren. Routen, die den Load-Balancer als nächsten Hop im hub-VPC-Netzwerk verwenden, können in jedem spoke-Netzwerk verwendet werden.
  • Load-Balancing für mehrere Netzwerkkarten auf den Back-End-VMs

Weitere Informationen zu diesen Anwendungsfällen finden Sie unter Interne TCP/UDP-Load-Balancer als nächste Hops.

Load-Balancing für GKE-Anwendungen

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

Zugehörige GKE-Dokumentation:

Funktionsweise des internen TCP/UDP-Load-Balancings

Ein interner TCP/UDP-Load-Balancer hat die folgenden Merkmale:

  • Er ist ein verwalteter Dienst.
  • Er ist kein Proxy.
  • Die Implementierung erfolgt über virtuelle Netzwerke.

Im Gegensatz zu einem Proxy-Load-Balancer beendet ein interner TCP/UDP-Load-Balancer keine Verbindungen von Clients und öffnet keine neuen Verbindungen zu Back-Ends. Stattdessen leitet ein interner TCP/UDP-Load-Balancer die ursprünglichen Verbindungen ohne Unterbrechung direkt von Clients an die fehlerfreien Back-Ends weiter.

  • Es gibt kein Zwischengerät und keinen Single Point of Failure.
  • Clientanfragen an die IP-Adresse des Load-Balancers werden direkt an die fehlerfreien Back-End-VMs gesendet.
  • Antworten von fehlerfreien Back-End-VMs werden direkt an die Clients und nicht über den Load-Balancer gesendet. TCP-Antworten verwenden die direkte Serverrückgabe. Weitere Informationen finden Sie unter TCP und UDP – Anfrage und Rückgabe von Paketen.

Der Load-Balancer überwacht den VM-Status mithilfe von Systemdiagnoseprüfungen. Weitere Informationen finden Sie im Abschnitt Systemdiagnose.

Die Linux-Gastumgebung von Google Cloud, die Windows-Gastumgebung oder ein entsprechender Prozess konfiguriert jede Back-End-VM mit der IP-Adresse des Load-Balancers. Bei VMs, die aus Google Cloud-Images erstellt wurden, installiert der Gast-Agent (früher die Windows-Gastumgebung oder die Linux-Gastumgebung) die lokale Route für die IP-Adresse des Load-Balancers. Google Kubernetes Engine-Instanzen, die auf Container-Optimized OS basieren, implementieren dies stattdessen mit iptables.

Das virtuelle Google Cloud-Netzwerk verwaltet die Bereitstellung des Traffics und nimmt eine entsprechende Skalierung vor.

Protokolle, Schema und Bereich

Jeder interne TCP/UDP-Load-Balancer unterstützt:

  • Einen Back-End-Dienst mit dem Load-Balancing-Schema INTERNAL und dem TCP- oder UDP-Protokoll (aber nicht beides).
  • Back-End-VMs, angegeben als:
  • Eine oder mehrere Weiterleitungsregeln, die entweder das TCP- oder das UDP-Protokoll verwenden und dem Protokoll des Back-End-Dienstes entsprechen.
  • Jede Weiterleitungsregel mit einer eigenen eindeutigen IP-Adresse oder mehrere Weiterleitungsregeln, die eine gemeinsame IP-Adresse verwenden.
  • Jede Weiterleitungsregel mit bis zu fünf oder allen Ports.
  • Clients in jeder Region, wenn globaler Zugriff aktiviert ist.
  • Clients in derselben Region wie der Load-Balancer, wenn globaler Zugriff deaktiviert ist.

Ein interner TCP/UDP-Load-Balancer unterstützt nicht:

Clientzugriff

Die Client-VM muss sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist. Sie können globalen Zugriff aktivieren, damit Client-VM-Instanzen aus einer beliebigen Region auf Ihren internen TCP/UDP-Load-Balancer zugreifen können.

In der folgenden Tabelle wird der Clientzugriff zusammengefasst.

Globaler Zugriff deaktiviert Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder Interconnect-Anhänge (VLANs) auf den Load-Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. Lokale Clients können über Cloud VPN-Tunnel oder Interconnect-Anhänge (VLANs) auf den Load-Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

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

Wenn ein Clientsystem ein TCP- oder UDP-Paket an einen internen TCP/UDP-Load-Balancer sendet, sind die Quelle und das Ziel des Pakets folgende:

  • Quelle: die primäre interne IP-Adresse des Clients oder die IP-Adresse aus einem der Alias-IP-Bereiche des Clients
  • Ziel: die IP-Adresse der Weiterleitungsregel des Load-Balancers

Daher erreichen Pakete die Back-End-VMs des Load-Balancers mit der Ziel-IP-Adresse des Load-Balancers selbst. Diese Art von Load-Balancer ist kein Proxy. Dies ist das erwartete Verhalten. Entsprechend muss die Software, die auf den Back-End-VMs des Load-Balancers ausgeführt wird, Folgendes tun:

  • Die IP-Adresse des Load-Balancers oder eine beliebige IP-Adresse überwachen (0.0.0.0 oder ::)
  • Überwachung eines Ports, der in der Weiterleitungsregel des Load-Balancers enthalten ist

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

  • TCP ist verbindungsorientiert und interne TCP/UDP-Load-Balancer nutzen die direkte Serverrückgabe. Das bedeutet, dass Antwortpakete von der IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden.
  • Im Gegensatz dazu ist UDP verbindungslos. Standardmäßig werden Rückgabepakete von der primären internen IP-Adresse der Netzwerkschnittstelle der Back-End-Instanz gesendet. Sie können dieses Verhalten jedoch ändern. Wenn Sie beispielsweise einen UDP-Server so konfigurieren, dass er an die IP-Adresse der Weiterleitungsregel gebunden ist, werden Antwortpakete von der IP-Adresse der Weiterleitungsregel gesendet.

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 Hängt von der UDP-Serversoftware ab Die Quelle des anfragenden Pakets

Architektur

Ein interner TCP/UDP-Load-Balancer mit mehreren Back-Ends verteilt Verbindungen auf alle diese Back-Ends. Weitere Informationen zur Verteilungsmethode und zu ihren Konfigurationsoptionen finden Sie unter Traffic-Verteilung.

Sie können Instanzgruppen oder zonale NEGs verwenden, aber keine Kombination aus beiden als Back-Ends für einen internen TCP/UDP-Load-Balancer:

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

Unter Hochverfügbarkeit wird beschrieben, wie Sie einen internen Load-Balancer entwerfen, der nicht von einer einzelnen Zone abhängig ist.

Instanzen, die als Back-End-VMs für TCP/UDP-Load-Balancer verwendet werden, müssen die entsprechende Linux- oder Windows-Gastumgebung oder andere Prozesse ausführen, die gleichwertige Funktionen bereitstellen. Diese Gastumgebung muss den Metadatenserver (metadata.google.internal, 169.254.169.254) zum Lesen von Instanzmetadaten kontaktieren können, damit lokale Routen zum Akzeptieren von Traffic generiert werden können, der an die interne IP-Adresse des Load-Balancers gesendet wird.

Dieses Diagramm veranschaulicht die Traffic-Verteilung auf VMs in zwei separaten Instanzgruppen. Traffic, der von der Clientinstanz an die IP-Adresse des Load-Balancers 10.10.10.9 gesendet wird, wird zwischen den Back-End-VMs in einer der Instanzgruppen verteilt. Von einer der bereitstellenden Back-End-VMs gesendete Antworten werden direkt an die Client-VM zugestellt.

Das interne TCP/UDP-Load-Balancing lässt sich entweder mit einem VPC-Netzwerk im benutzerdefinierten Modus oder im automatischen Modus verwenden. Interne TCP/UDP-Load-Balancer lassen sich auch mit einem bereits bestehenden Legacy-Netzwerk erstellen.

Ein interner TCP/UDP-Load-Balancer besteht aus den folgenden Google Cloud-Komponenten.

Komponente Zweck Anforderungen
Interne IP-Adresse Dies ist die Adresse für den Load-Balancer. Die interne IP-Adresse muss sich im selben Subnetz wie die interne Weiterleitungsregel befinden. Das Subnetz muss sich in derselben Region und demselben VPC-Netzwerk wie der Back-End-Dienst befinden.
Interne Weiterleitungsregel Eine interne Weiterleitungsregel in Kombination mit der internen IP-Adresse ist das Front-End des Load-Balancers. Sie definiert das Protokoll und die Ports, die der Load-Balancer akzeptiert, und leitet den Traffic an einen regionalen internen Back-End-Dienst weiter. Weiterleitungsregeln für interne TCP/UDP-Load-Balancer müssen folgende Voraussetzungen erfüllen:
 • Sie müssen das load-balancing-scheme INTERNAL haben.
 • Sie müssen als ip-protocol entweder TCP oder UDP verwenden, passend zum protocol des Back-End-Diensts.
 • Sie müssen im selben VPC-Netzwerk und in derselben Region wie der Back-End-Dienst auf ein subnet verweisen.
Regionaler interner Back-End-Dienst Der regionale interne Back-End-Dienst definiert das Protokoll, das für die Kommunikation mit den Back-Ends verwendet wird, und gibt eine Systemdiagnose an. Back-Ends können nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen, verwaltete regionale Instanzgruppen oder zonale NEGs mit GCE_VM_IP-Endpunkten sein. Der Back-End-Dienst muss folgende Voraussetzungen erfüllen:
 • Er muss das load-balancing-scheme INTERNAL haben.
 • Er muss als protocol entweder TCP oder UDP verwenden, passend zum ip-protocol der Weiterleitungsregel.
 • Er muss eine zugehörige Systemdiagnose haben.
 • Er muss eine zugehörige Region haben. Die Weiterleitungsregel und alle Back-Ends müssen sich in derselben Region wie der Back-End-Dienst befinden.
• Sie müssen einem einzelnen VPC-Netzwerk zugeordnet sein. Wenn keine Angabe erfolgt, wird das Netzwerk basierend auf dem Netzwerk abgeleitet, das von der Standardnetzwerkschnittstelle der Back-End-VM verwendet wird (nic0).

Obwohl der Back-End-Dienst nicht an ein bestimmtes Subnetz gebunden ist, muss sich das Subnetz der Weiterleitungsregel im selben VPC-Netzwerk befinden wie der Back-End-Dienst.
Systemdiagnose Jeder Back-End-Dienst muss eine zugehörige Systemdiagnose haben. Die Systemdiagnose definiert die Parameter, anhand derer Google Cloud die verwalteten Back-Ends als für den Erhalt von Traffic zugelassen betrachtet. Nur fehlerfreie Back-End-VMs empfangen Traffic, der von Client-VMs an die IP-Adresse des Load-Balancers gesendet wird.
Auch wenn die Weiterleitungsregel und der Back-End-Dienst entweder TCP oder UDP verwenden können, hat Google Cloud keine Systemdiagnose für UDP-Traffic. Weitere Informationen finden Sie unter Systemdiagnosen und UDP-Traffic.

Interne IP-Adresse

Internes TCP/UDP-Load-Balancing verwendet eine interne IPv4-Adresse aus dem primären IP-Bereich des Subnetzes, die Sie auswählen, wenn Sie die interne Weiterleitungsregel erstellen. Die IP-Adresse darf nicht aus einem sekundären IP-Bereich des Subnetzes stammen.

Beim Erstellen der Weiterleitungsregel geben Sie die IP-Adresse für den internen TCP/UDP-Load-Balancer an. Sie können zwischen einer sitzungsspezifischen IP-Adresse und einer reservierten IP-Adresse wählen.

Firewallregeln

Der interne TCP/UDP-Load-Balancer erfordert die folgenden Firewallregeln:

Im Beispiel unter Firewallregeln konfigurieren wird gezeigt, wie Sie beide erstellen.

Weiterleitungsregeln

Mit einer Weiterleitungsregel werden das Protokoll und die Ports angegeben, über die der Load-Balancer den Traffic annimmt. Da interne TCP/UDP-Load-Balancer keine Proxys sind, leiten sie Traffic an Back-Ends über dasselbe Protokoll und denselben Port weiter.

Für einen internen TCP/UDP-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich. Sie können mehrere Weiterleitungsregeln für denselben Load-Balancer definieren.

Die Weiterleitungsregel muss auf ein bestimmtes Subnetz im selben VPC-Netzwerk und in derselben Region wie die Back-End-Komponenten des Load-Balancers verweisen. Diese Anforderung hat folgende Auswirkungen:

  • Das Subnetz, das Sie für die Weiterleitungsregel angeben, muss nicht mit einem der von Back-End-VMs verwendeten Subnetze identisch sein. Das Subnetz muss sich jedoch in derselben Region wie die Weiterleitungsregel befinden.
  • Wenn Sie eine interne Weiterleitungsregel erstellen, wählt Google Cloud eine verfügbare regionale interne IP-Adresse aus dem primären IP-Adressbereich des ausgewählten Subnetzes aus. Alternativ können Sie eine interne IP-Adresse im primären IP-Bereich des Subnetzes festlegen.

Weiterleitungsregeln und globaler Zugriff

Die Weiterleitungsregeln eines internen TCP/UDP-Load-Balancers sind regional, auch wenn der globale Zugriff aktiviert ist. Nachdem Sie den globalen Zugriff aktiviert haben, wird das Flag allowGlobalAccess der regionalen internen Weiterleitungsregel auf true gesetzt.

Weiterleitungsregeln und Portspezifikationen

Wenn Sie eine interne Weiterleitungsregel erstellen, müssen Sie eine der folgenden Portspezifikationen auswählen:

  • Geben Sie mindestens einen und bis zu fünf Ports mit Nummer an.
  • Geben Sie ALL an, um Traffic an allen Ports weiterzuleiten.

Mit einer internen Weiterleitungsregel, die entweder alle TCP-Ports oder alle UDP-Ports unterstützt, können Back-End-VMs mehrere Anwendungen jeweils mit eigenem Port ausführen. Traffic, der an einen bestimmten Port gesendet wird, wird an die entsprechende Anwendung geleitet, und alle Anwendungen verwenden dieselbe IP-Adresse.

Wenn Sie Traffic an mehr als fünf bestimmte Ports weiterleiten müssen, kombinieren Sie Firewallregeln mit Weiterleitungsregeln. Geben Sie beim Erstellen der Weiterleitungsregel alle Ports an und erstellen Sie dann allow-Firewallregeln für eingehenden Traffic, die nur Traffic zu den gewünschten Ports zulassen. Wenden Sie die Firewallregeln auf die Back-End-VMs an.

Nach dem Erstellen einer Weiterleitungsregel kann diese nicht mehr geändert werden. Wenn Sie die angegebenen Ports oder die interne IP-Adresse für eine interne Weiterleitungsregel ändern müssen, müssen Sie sie löschen und neu erstellen.

Mehrere Weiterleitungsregeln für einen einzelnen Back-End-Dienst

Sie können mehrere interne Weiterleitungsregeln konfigurieren, die alle auf denselben internen Back-End-Dienst verweisen. Für einen internen TCP/UDP-Load-Balancer ist mindestens eine interne Weiterleitungsregel erforderlich.

Wenn Sie mehrere Weiterleitungsregeln für denselben Back-End-Dienst konfigurieren, können Sie entweder TCP oder UDP verwenden (nicht beides) und somit Folgendes tun:

  • Weisen Sie dem Load-Balancer mehrere IP-Adressen zu. Sie können mehrere Weiterleitungsregeln mit jeweils einer eigenen IP-Adresse erstellen. Für jede Weiterleitungsregel können alle Ports oder eine Gruppe von bis zu fünf Ports angegeben werden.

  • Weisen Sie dem Load-Balancer eine bestimmte Gruppe von Ports mit derselben IP-Adresse zu. Sie können mehrere Weiterleitungsregeln mit derselben IP-Adresse erstellen, wobei jede Weiterleitungsregel eine bestimmte Gruppe von bis zu fünf Ports verwendet. Dies ist eine Alternative zur Konfiguration einer einzelnen Weiterleitungsregel, bei der alle Ports angegeben sind.

Weitere Informationen zu Szenarien mit zwei oder mehr internen Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse haben, finden Sie unter Mehrere Weiterleitungsregeln mit derselben IP-Adresse.

Wenn Sie mehrere interne Weiterleitungsregeln verwenden, müssen Sie die auf Ihren Back-End-VMs ausgeführte Software so konfigurieren, dass sie an alle IP-Adressen der Weiterleitungsregel oder an eine beliebige Adresse (0.0.0.0/0) gebunden ist. Die Ziel-IP-Adresse für ein über den Load-Balancer zugestelltes Paket ist die interne IP-Adresse, die der entsprechenden internen Weiterleitungsregel zugeordnet ist. Weitere Informationen finden Sie unter TCP und UDP –Anfrage und Rückgabe von Paketen.

Back-End-Dienst

Jeder interne TCP/UDP-Load-Balancer hat einen regionalen internen Back-End-Dienst, der Back-End-Parameter und das Verhalten definiert. Der Name des Back-End-Diensts ist der Name des internen TCP/UDP-Load-Balancers, der in der Google Cloud Console angezeigt wird.

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

  • Protokoll. Ein Back-End-Dienst akzeptiert an den Ports, die durch eine oder mehrere interne Weiterleitungsregeln festgelegt wurden, entweder TCP- oder UDP-Traffic, jedoch nicht beides. Der Back-End-Dienst ermöglicht das Senden von Traffic an Back-End-VMs an denselben Ports, an die der Traffic gesendet wurde. Das Protokoll des Back-End-Diensts muss dem Protokoll der Weiterleitungsregel entsprechen.

  • Traffic-Verteilung. Ein Back-End-Dienst ermöglicht das Verteilen von Traffic gemäß einer konfigurierbaren Sitzungsaffinität.

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

Jeder Back-End-Dienst wird in einer einzelnen Region ausgeführt und verteilt den Traffic für Back-End-VMs in einem einzelnen VPC-Netzwerk:

  • Regionalität: Back-Ends sind entweder Instanzgruppen oder zonale NEGs (mit GCE_VM_IP-Endpunkten) in derselben Region wie der Back-End-Dienst (und die Weiterleitungsregel). Die Instanzgruppen-Back-Ends können nicht verwaltete Instanzgruppen, zonale verwaltete Instanzgruppen oder regionale verwaltete Instanzgruppen sein. Die zonalen NEG-Back-Ends können nur GCE_VM_IP-Endpunkte verwenden.

  • VPC-Netzwerk Alle Back-End-VMs müssen eine Netzwerkschnittstelle in dem VPC-Netzwerk haben, das dem Back-End-Dienst zugeordnet ist. Sie können entweder explizit das Netzwerk eines Back-End-Diensts angeben oder ein implizites Netzwerk verwenden. In jedem Fall muss sich das Subnetz jeder internen Weiterleitungsregel im VPC-Netzwerk des Back-End-Diensts befinden.

Back-End-Dienste und Netzwerkschnittstellen

Jeder Back-End-Dienst wird in einem einzelnen VPC-Netzwerk und in einer Google Cloud-Region ausgeführt. Das VPC-Netzwerk kann implizit oder explizit mit dem Flag --network im Befehl gcloud compute backend-services create angegeben werden.

Bei expliziter Angabe identifiziert das VPC-Flag --network des Back-End-Diensts die Netzwerkschnittstelle auf jeder Back-End-VM, auf der das Load-Balancing des Traffics erfolgt. Jede Back-End-VM muss eine Netzwerkschnittstelle im angegebenen VPC-Netzwerk haben. In diesem Fall können die Kennungen der Netzwerkschnittstelle (nic0 bis nic7) bei den Back-End-VMs unterschiedlich sein. Je nach Back-End-Typ sind weitere Punkte zu berücksichtigen:

  • Instanzgruppen-Back-Ends:

    • Verschiedene Back-End-VMs in derselben nicht verwalteten Instanzgruppe verwenden möglicherweise unterschiedliche Schnittstellenkennungen, wenn jede VM eine Schnittstelle im angegebenen VPC-Netzwerk hat.
    • Die Schnittstellenkennung muss nicht für alle Back-End-Instanzgruppen identisch sein. Sie kann nic0 für Back-End-VMs in einer Back-End-Instanzgruppe und nic2 für Back-End-VMs in einer anderen Back-End-Instanzgruppe sein.
  • Zonale NEG-Back-Ends:

    • Verschiedene Endpunkte in denselben zonalenGCE_VM_IP-NEGs verwenden möglicherweise andere Schnittstellenkennungen.
    • Wenn Sie beim Hinzufügen eines Endpunkts zur zonalen NEG sowohl einen VM-Namen als auch eine IP-Adresse angeben, validiert Google Cloud, dass der Endpunkt eine primäre interne IP-Adresse für die NIC der VM ist, die sich im ausgewählten VPC-Netzwerk des NEG befindet. Fehlgeschlagene Validierungen geben Fehlermeldungen aus, die darauf hinweisen, dass der Endpunkt nicht mit der primären IP-Adresse der VM-NIC im Netzwerk der NEG übereinstimmt.
    • Wenn Sie beim Hinzufügen von Endpunkten zur zonalen NEG keine IP-Adressen angeben, wählt Google Cloud die primäre interne IP-Adresse der NIC im ausgewählten VPC-Netzwerk der NEG aus.

Wenn Sie beim Erstellen des Back-End-Dienstes das Flag --network nicht einschließen, wählt der Back-End-Dienst ein Netzwerk auf folgende Weise aus:

  • Instanzgruppen-Back-Ends:

    • Der Back-End-Dienst wählt ein Netzwerk anhand des Netzwerks der ersten (oder einzigen) Netzwerkschnittstelle aus, die von allen Back-End-VMs verwendet wird. Das bedeutet, dass sich nic0 bei allen VMs in allen Back-End-Instanzgruppen im selben VPC-Netzwerk befinden muss.
  • Zonale NEG-Back-Ends:

    • Wenn der Back-End-Dienst mit einer Weiterleitungsregel verknüpft ist, wird das Netzwerk der Weiterleitungsregel ausgewählt.
    • Wenn keine Weiterleitungsregel vorhanden ist, wird das Netzwerk der verknüpften zonalen NEG ausgewählt. Alle NEGs müssen auf dasselbe Netzwerk verweisen.

Systemdiagnose

Der Back-End-Dienst des Load-Balancers muss einer globalen oder regionalen Systemdiagnose zugeordnet sein. Spezielle Routen außerhalb des VPC-Netzwerks erleichtern die Kommunikation zwischen Systemdiagnosen und Back-Ends.

Sie können eine vorhandene Systemdiagnose verwenden oder eine neue definieren. Die internen TCP/UDP-Load-Balancer verwenden den Systemdiagnosestatus wie unter Traffic-Verteilung beschrieben, um zu bestimmen, wie neue Verbindungen weitergeleitet werden.

Sie können eines der folgenden Systemdiagnoseprotokolle verwenden: Das Protokoll der Systemdiagnose muss nicht mit dem Protokoll des Load-Balancers übereinstimmen:

  • HTTP, HTTPS oder HTTP/2. Wenn Ihre Back-End-VMs Traffic über HTTP, HTTPS oder HTTP/2 bereitstellen, verwenden Sie am besten eine Systemdiagnose, die mit diesem Protokoll übereinstimmt, da HTTP-basierte Systemdiagnosen geeignete Optionen für dieses Protokoll bieten. Die Bereitstellung von HTTP-Traffic über einen internen TCP/UDP-Load-Balancer bedeutet, dass das Protokoll des Load-Balancers TCP ist.
  • SSL oder TCP. Wenn Ihre Back-End-VMs keinen HTTP-Traffic bereitstellen, sollten Sie entweder eine SSL- oder eine TCP-Systemdiagnose verwenden.

Unabhängig vom Typ der erstellten Systemdiagnose sendet Google Cloud Systemdiagnoseprüfungen an die IP-Adresse der Weiterleitungsregel des internen TCP/UDP-Load-Balancers und an die Netzwerkschnittstelle in der vom Back-End-Dienst des Load-Balancers ausgewählten VPC. Hiermit wird simuliert, wie Traffic mit Load-Balancing gesendet wird. Software, die auf Ihren Back-End-VMs ausgeführt wird, muss sowohl auf Traffic mit Load-Balancing als auch auf Systemdiagnoseprüfungen reagieren, die an die IP-Adresse des Load-Balancers gesendet werden. Weitere Informationen finden Sie unter Ziel für Prüfungspakete.

Systemdiagnosen und UDP-Traffic

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

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

Hochverfügbarkeitsarchitektur

Der interne TCP/UDP-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.

Gehen Sie gemäß dieser Empfehlungen vor, um Ihre Back-End-VM-Instanzen in mehreren Zonen bereitzustellen:

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

  • Bei zonal verwalteten Instanzgruppen oder nicht verwalteten Instanzgruppen verwenden Sie für denselben Back-End-Dienst mehrere Instanzgruppen in verschiedenen Zonen (in derselben Region). Die Verwendung mehrerer Zonen schützt vor möglichen Problemen in einer bestimmten Zone.

Architektur einer freigegebenen VPC

In der folgenden Tabelle sind die Komponentenanforderungen für das interne TCP/UDP-Load-Balancing zusammengefasst, das mit einem freigegebenen VPC-Netzwerk verwendet wird. Ein Beispiel finden Sie auf der Seite "Internen TCP/UDP-Load-Balancer auf der bereitgestellten freigegebenen VPC erstellen".

IP-Adresse Weiterleitungsregel Back-End-Komponenten
Eine interne IP-Adresse muss im selben Projekt wie die Back-End-VMs definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne IP-Adresse von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss es auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

Wenn Sie eine interne IP-Adresse in einem Dienstprojekt erstellen und sich das IP-Adress-Subnetz im VPC-Netzwerk des Dienstprojekts befindet, wird der interne TCP/UDP-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet.
Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-End-VMs definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.

Wenn Sie in einem Dienstprojekt eine interne Weiterleitungsregel erstellen und sich das Subnetz der Weiterleitungsregel im VPC-Netzwerk des Dienstprojekts befindet, wird der interne TCP/UDP-Load-Balancer vom Dienstprojekt als lokal betrachtet. Er wird von keinem freigegebenen VPC-Hostprojekt als lokal betrachtet.
Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Back-End-VMs in einem Dienstprojekt. Dort müssen auch der regionale interne Back-End-Dienst und die Systemdiagnose definiert werden.

Traffic-Verteilung

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

  • Wenn Sie kein Failover konfiguriert haben, verteilt ein interner TCP/UDP-Load-Balancer neue Verbindungen an seine fehlerfreien Back-End-VMs, wenn wenigstens eine Back-End-VM fehlerfrei ist. Wenn alle Back-End-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Back-Ends. In diesem Fall leitet der Load-Balancer jede neue Verbindung an eine fehlerhafte Back-End-VM weiter.

  • Wenn Sie ein Failover konfiguriert haben, verteilt ein interner TCP/UDP-Load-Balancer neue Verbindungen zwischen VMs in seinem aktiven Pool gemäß einer von Ihnen konfigurierten Failover-Richtlinie. Wenn alle Back-End-VMs fehlerhaft sind, können Sie aus folgenden Verhaltensweisen eine auswählen:

    • (Standardeinstellung) Der Load-Balancer verteilt den Traffic nur auf die primären VMs. Dies wird als letztes Mittel unternommen. Die Backup-VMs sind von dieser letztes-Mittel-Verteilung der Verbindungen ausgeschlossen.
    • Der Load-Balancer ist so konfiguriert, dass Traffic unterbrochen wird.

Die Methode zum Verteilen neuer Verbindungen hängt von der Einstellung der Sitzungsaffinität des Load-Balancers ab.

Der Status der Systemdiagnose steuert die Verteilung neuer Verbindungen. Eine bestehende TCP-Sitzung wird weiter auf einer fehlerhaften Back-End-VM ausgeführt, wenn die fehlerhafte Back-End-VM die Verbindung noch verarbeitet.

Optionen der Sitzungsaffinität

Die Sitzungsaffinität steuert die Verteilung neuer Verbindungen von Clients zu den Back-End-VMs des Load-Balancers. Legen Sie die Sitzungsaffinität fest, wenn Ihre Back-End-VMs Statusinformationen für ihre Clients verfolgen müssen. Dies ist eine gängige Anforderung für Anwendungen, die den Zustand beibehalten müssen, einschließlich Webanwendungen.

Die Sitzungsaffinität basiert auf dem Best-Effort-Prinzip.

Interne TCP/UDP-Load-Balancer unterstützen die folgenden Sitzungsaffinitätsoptionen, die Sie für den gesamten internen Back-End-Dienst und nicht einzeln für jede Back-End-Instanzgruppe angeben:

Typ Bedeutung Unterstützte Protokolle
Dies ist die Standardeinstellung.

Die Funktionsweise ist die gleiche wie bei IP-Adresse, Protokoll und Port des Clients.

TCP-, UDP-Traffic
Client-IP Verbindungen von derselben Quell- und Ziel-IP-Adresse werden über einen 2-Tupel-Hash basierend auf folgenden Elementen an dieselbe Instanz gesendet:
  • Quelladresse im IP-Paket
  • Zieladresse im IP-Paket
TCP-, UDP-Traffic
Client-IP und -Protokoll Verbindungen von derselben Quell- und Ziel-IP-Adresse und demselben Protokoll werden an dieselbe Instanz weitergeleitet. Dies erfolgt anhand eines 3-Tupel-Hashes der folgenden Elemente:
  • Quelladresse im IP-Paket
  • Zieladresse im IP-Paket
  • Protokoll (TCP oder UDP)
TCP-, UDP-Traffic
Client-IP, Protokoll und Port Pakete werden mit einem Hash gesendet, der anhand der folgenden Informationen erstellt wird:
  • Quell-IP-Adresse des Pakets
  • Quellport des Pakets (falls vorhanden)
  • Ziel-IP-Adresse des Pakets
  • Zielport des Pakets (falls vorhanden)
  • Protokoll
Quell- und Zieladresse sowie Protokollinformationen werden aus dem Header des IP-Pakets abgerufen. Quellport und Zielport, falls vorhanden, werden aus dem Layer-4-Header abgerufen.
Beispielsweise enthalten TCP-Segmente und fragmentierte UDP-Datagrams immer einen Quellport und einen Zielport. Fragmentierte UDP-Datagramme enthalten keine Port-Informationen.
Wenn keine Portinformationen vorhanden sind, ist der Fünf-Tupel-Hash praktisch ein Drei-Tupel-Hash.
Nur TCP-Traffic

Die Ziel-IP-Adresse ist die IP-Adresse der Weiterleitungsregel des Load-Balancers, es sei denn, Pakete werden aufgrund einer benutzerdefinierten statischen Route an den Load-Balancer gesendet. Unter Sitzungsaffinität und interner TCP/UDP-Load-Balancer für den nächsten Hop im nächsten Abschnitt dieses Artikels finden Sie Informationen darüber, wie Sie einen internen TCP/UDP-Load-Balancer als nächsten Hop für eine Route verwenden.

Sitzungsaffinität und interner TCP/UDP-Load-Balancer für den nächsten Hop

Unabhängig von der ausgewählten Sitzungsaffinitätsoption verwendet Google Cloud das Ziel des Pakets. Wenn ein Paket direkt an den Load-Balancer gesendet wird, entspricht das Ziel des Pakets der IP-Adresse der Weiterleitungsregel des Load-Balancers.

Wenn Sie jedoch einen internen TCP/UDP-Load-Balancer als nächsten Hop für eine benutzerdefinierte statische Route verwenden, ist das Ziel des Pakets höchstwahrscheinlich nicht die IP-Adresse der Weiterleitungsregel des Load-Balancers. Bei Paketen mit einem Ziel innerhalb des Zielbereichs der Route führt diese zum Load-Balancer.

Informationen zum Verwenden eines internen TCP/UDP-Load-Balancers als nächsten Hop für eine benutzerdefinierte statische Route finden Sie unter Interne TCP/UDP-Load-Balancer als nächste Hops.

Sitzungsaffinität und Status der Systemdiagnose

Das Ändern des Status der Systemdiagnose für Back-End-VMs kann zu einem Verlust der Sitzungsaffinität führen. Wenn beispielsweise eine Back-End-VM fehlerhaft wird und es mindestens eine andere fehlerfreie Back-End-VM gibt, verteilt ein interner TCP/UDP-Load-Balancer keine neuen Verbindungen an die fehlerhafte VM. Wenn ein Client eine Sitzungsaffinität zu dieser fehlerhaften VM hat, wird er stattdessen zur anderen, fehlerfreien Back-End-VM weitergeleitet, wodurch seine Sitzungsaffinität verloren geht.

Verbindungen von einem einzelnen Client aus testen

Beim Testen von Verbindungen zur IP-Adresse eines internen TCP/UDP-Load-Balancers von einem einzelnen Clientsystem aus sollten Sie Folgendes beachten:

  • Wenn das Clientsystem keine VM ist, für die Load-Balancing durchgeführt wird, also keine Back-End-VM, werden neue Verbindungen an die fehlerfreien Back-End-VMs des Load-Balancers gesendet. Da jedoch alle Sitzungsaffinitätsoptionen mindestens die IP-Adresse des Clientsystems benötigen, werden Verbindungen von demselben Client häufiger als erwartet an dieselbe Back-End-VM verteilt.

    Praktisch bedeutet dies, dass Sie die Trafficverteilung über einen internen TCP/UDP-Load-Balancer nicht genau überwachen können, indem Sie über einen einzigen Client eine Verbindung zu ihm herstellen. Die Anzahl der Clients, die zur Überwachung der Trafficverteilung benötigt werden, hängt vom Typ des Load-Balancers, der Art des Traffics und der Anzahl fehlerfreier Back-Ends ab.

  • Wenn die Client-VM eine Back-End-VM des Load-Balancers ist, werden Verbindungen, die an die IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden, immer von der Client-Back-End-VM beantwortet. Dies geschieht unabhängig davon, ob die Back-End-VM fehlerfrei ist. Dies gilt für den gesamten Traffic, der an die IP-Adresse des Load-Balancers gesendet wird, nicht nur für den Traffic für das Protokoll und die Ports, die in der internen Weiterleitungsregel des Load-Balancers angegeben sind.

    Weitere Informationen finden Sie unter Anfragen von VMs mit Load-Balancing senden.

Failover

Mit dem internen TCP/UDP-Load-Balancing können Sie einige Back-Ends als Failover-Back-Ends festlegen. Diese Back-Ends werden nur verwendet, wenn die Anzahl der fehlerfreien VMs in den primären Back-End-Instanzgruppen unter einem konfigurierbaren Schwellenwert liegt. Wenn alle primären und Failover-VMs fehlerhaft sind, verteilt Google Cloud standardmäßig als letztes Mittel neue Verbindungen nur auf alle primären VM.

Wenn Sie ein Back-End zu einem Back-End-Dienst eines internen TCP/UDP-Load-Balancers hinzufügen, ist standardmäßig das Back-End ein primäres Back-End. Sie können ein Back-End als Failover-Back-End festlegen, wenn Sie es dem Back-End-Dienst des Load-Balancers hinzufügen oder den Back-End-Dienst später bearbeiten.

Eine detaillierte konzeptionelle Übersicht über das Failover im internen TCP/UDP-Load-Balancing finden Sie unter Failover für das interne TCP/UDP-Load-Balancing.

Teilmengeneinstellung

Die Teilmengeneinstellung für interne TCP/UDP-Load-Balancer ermöglicht es Ihnen, Ihren internen TCP/UDP-Load-Balancer zu skalieren, um eine größere Anzahl von Back-End-VM-Instanzen pro internem Back-End-Dienst zu unterstützen.

Informationen dazu, wie sich diese Einstellung auf dieses Limit auswirkt, finden Sie im Abschnitt „Back-End-Dienste“ unter Ressourcenquoten und Limits für Load-Balancing.

Die Teilmengeneinstellung ist standardmäßig deaktiviert, wodurch die Verteilung des Back-End-Dienstes auf maximal 250 Back-End-Instanzen oder Endpunkte begrenzt ist. Wenn der Back-End-Dienst mehr als 250 Back-Ends unterstützen soll, können Sie die Teilmengeneinstellung aktivieren. Wenn die Teilmengeneinstellung aktiviert ist, wird für jede Clientverbindung eine Teilmenge von Back-End-Instanzen ausgewählt.

Das folgende Diagramm zeigt ein skaliertes Modell des Unterschieds zwischen diesen beiden Betriebsmodi.

Vergleich eines internen TCP/UDP-Load-Balancers ohne und mit Teilmengeneinstellung (zum Vergrößern klicken)
Vergleich eines internen TCP/UDP-Load-Balancers ohne und mit Teilmengeneinstellung (zum Vergrößern klicken)

Ohne die Teilmengeneinstellung ist der gesamte Satz fehlerfreier Back-Ends besser genutzt und neue Clientverbindungen werden gemäß der Traffic-Verteilung auf alle fehlerfreien Back-Ends verteilt. Teilmengeneinstellung setzt Load-Balancing-Einschränkungen ein, ermöglicht dem Load-Balancer jedoch, mehr als 250 Back-Ends zu unterstützen.

Eine Konfigurationsanleitung finden Sie unter Teilmengeneinstellung.

Vorbehalte in Bezug auf die Teilmengeneinstellung

  • Wenn die Teilmengeneinstellung aktiviert ist, erhalten nicht alle Back-Ends Traffic von einem bestimmten Absender, auch wenn die Anzahl der Back-Ends gering ist.
  • Die maximale Anzahl von Back-End-Instanzen bei aktivierter Teilmengeneinstellung finden Sie auf der Seite „Kontingente“.
  • Für die Teilmengeneinstellung wird nur 5-Tupel-Sitzungsaffinität unterstützt.
  • Die Paketspiegelung wird bei der Teilmengeneinstellung nicht unterstützt.
  • Durch Aktivieren und Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
  • Wenn Sie die Teilmengeneinstellung über Cloud VPN oder Cloud Interconnect verwenden und auf der Google Cloud-Seite nicht genügend VPN-Gateways vorhanden sind (weniger als 10), verwenden Sie wahrscheinlich nur die Teilmenge der Load-Balancer-Back-Ends. Wenn Pakete für eine einzelne TCP-Verbindung an ein anderes VPN-Gateway weitergeleitet werden, werden Verbindungen zurückgesetzt. Es müssen genügend VPN-Gateways in Google Cloud vorhanden sein, um alle Back-End-Pools zu nutzen. Wenn der Traffic für eine einzelne TCP-Verbindung an ein anderes VPN-Gateway weitergeleitet wird, werden Verbindungen zurückgesetzt.

Beschränkungen

  • Interne TCP/UDP-Load-Balancer unterstützen kein VPC-Netzwerk-Peering. Sie müssen die Weiterleitungsregeln und Back-Ends des Load-Balancers im selben VPC-Netzwerk erstellen.

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.

Nächste Schritte