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

Das interne TCP/UDP-Load-Balancing von Google Cloud ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen Load-Balancing-IP-Adresse, auf die nur Ihre internen VM-Instanzen zugreifen können, ausführen und skalieren können.

Mit internem TCP/UDP-Load-Balancing wird der Traffic unter VM-Instanzen in derselben Region eines VPC-Netzwerks (Virtual Private Cloud) über eine interne IP-Adresse verteilt.

Wie im folgenden Diagramm dargestellt, hat ein interner TCP/UDP-Load-Balancing-Dienst ein Front-End (die Weiterleitungsregel) und ein Back-End (den Back-End-Dienst und Instanzgruppen).

Allgemeines Beispiel für einen internen TCP/UDP-Load-Balancer (zum Vergrößern klicken)
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:

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).
  • Vom Back-End verwaltete und nicht verwaltete Instanzgruppen, die sich in einer Region und einem VPC-Netzwerk befinden.
  • 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

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

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.

Anwendungsfälle

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. Wenn Sie beispielsweise einen externen HTTP(S)-Load Balancer einbinden, ist der externe Load-Balancer die Webebene und arbeitet mit Diensten hinter dem internen Load-Balancer.

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:

Webanwendung mit drei Ebenen mit HTTP(S)-Load-Balancing und internem TCP/UDP-Load-Balancing (zum Vergrößern klicken)
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.
Webanwendung mit drei Ebenen mit HTTP(S) -Load-Balancing, globalem Zugriff und internem TCP/UDP-Load-Balancing (zum Vergrößern klicken)
Webanwendung mit drei Ebenen mit HTTP(S)-Load-Balancing, globalem Zugriff und internem TCP/UDP-Load-Balancing (zum Vergrößern klicken)

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

Weitere Anwendungsfälle

  • Internen TCP/UDP-Load-Balancer als nächsten Hop zu einem NAT-Gateway verwenden: Sie können Traffic an die Back-Ends Ihrer virtuellen Firewall- oder Gateway-Appliance über einen internen TCP/UDP-Load-Balancer weiterleiten.
  • 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.

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. Das virtuelle Google Cloud-Netzwerk verwaltet die Bereitstellung des Traffics und nimmt eine entsprechende Skalierung vor.

Architektur

Ein interner TCP/UDP-Load-Balancer mit mehreren Back-End-Instanzgruppen verteilt Verbindungen zwischen Back-End-VMs in allen diesen Instanzgruppen. Weitere Informationen zur Verteilungsmethode und zu ihren Konfigurationsoptionen finden Sie unter Traffic-Verteilung.

Sie können alle Arten von Instanzgruppen (nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen und verwaltete regionale Instanzgruppen), außer Netzwerk-Endpunktgruppen (NEGs), als Back-Ends für Ihren Load-Balancer 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.

Hochverfügbarkeit

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.

Komponenten

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 (Instanzgruppen) verwendet wird, und gibt eine Systemdiagnose an. Back-Ends können nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen oder verwaltete regionale Instanzgruppen 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 Region der Weiterleitungsregel und alle Back-End-Instanzgruppen müssen mit der Region des Back-End-Diensts übereinstimmen.
 • Er muss 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 VMs in den Back-End-Instanzgruppen erhalten 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 Instanzgruppen in derselben Region wie der Back-End-Dienst und die Weiterleitungsregel. Back-Ends können nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen oder regional verwaltete Instanzgruppen sein.

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

    • 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.
  • Wenn beim Erstellen des Back-End-Diensts nicht das Flag --network einbezogen wird, wählt der Back-End-Dienst ein Netzwerk basierend auf dem Netzwerk 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.

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.

TCP und UDP – Anfrage und Rückgabe von Paketen

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

Wenn der Load-Balancer ein Antwortpaket sendet, hängen die Quelle und das Ziel dieses Pakets 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

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 Traffic unterbrechen.

Standardmäßig wird für die Methode zur Verteilung neuer Verbindungen ein Hashwert verwendet, der aus fünf Informationen berechnet wird: IP-Adresse des Clients, Quellport, IP-Adresse der internen Weiterleitungsregel des Load-Balancers, Zielport und Protokoll. Sie können die Trafficverteilungsmethode für TCP-Traffic ändern, indem Sie eine Sitzungsaffinitätsoption angeben.

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 beim Senden von TCP-Traffic Statusinformationen für ihre Clients verfolgen müssen. Dies ist eine gängige Anforderung für Webanwendungen.

Die Sitzungsaffinität basiert auf dem Best-Effort-Prinzip für TCP-Traffic. Da das UDP-Protokoll keine Sitzungen unterstützt, wirkt sich die Sitzungsaffinität nicht auf UDP-Traffic aus.

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:

  • –. Standardeinstellung, die Client-IP, Protokoll und Port entspricht.
  • Client-IP. Leitet Anfragen eines bestimmten Clients an dieselbe Back-End-VM weiter und zwar anhand eines Hashwerts, der aus der IP-Adresse des Clients und der Ziel-IP-Adresse erstellt wird.
  • Client-IP und Protokoll. Leitet die Anfragen eines bestimmten Clients an dieselbe Back-End-VM weiter und zwar anhand eines Hashwerts, der aus drei Informationen besteht: der IP-Adresse des Clients, der Ziel-IP-Adresse und dem Protokoll des Load-Balancers (TCP oder UDP)
  • Client-IP, Protokoll und Port. Leitet Anfragen eines bestimmten Clients an dieselbe Back-End-VM weiter, und zwar anhand eines Hashwerts, der aus diesen fünf Informationen erstellt wurde:

    • Quell-IP-Adresse des Clients, der die Anfrage sendet
    • Quellport des Clients, der die Anfrage sendet
    • IP-Adresse des Ziels
    • Zielport
    • Protokoll (TCP oder UDP)

    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.

Limits

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

Weitere Informationen