Konzepte des internen TCP/UDP-Load-Balancing

Das interne TCP/UDP-Load-Balancing ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer privaten Load-Balancing-IP-Adresse ausführen und skalieren können, die nur für Ihre internen VM-Instanzen zugänglich ist.

Übersicht

Das interne TCP/UDP-Load-Balancing der Google Cloud Platform (GCP) verteilt den Traffic auf VM-Instanzen in derselben Region in einem VPC-Netzwerk unter Verwendung einer privaten, internen IP-Adresse (RFC 1918).

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

Protokolle, Schema und Bereich

Jeder interne TCP/UDP-Load-Balancer unterstützt entweder TCP- oder UDP-Traffic (aber nicht beides).

Ein interner TCP/UDP-Load-Balancer verwendet einen einzigen Back-End-Dienst mit einem internen Load-Balancing-Schema. Das bedeutet, dass Traffic auf der GCP gleichmäßig auf Ihre Instanzen verteilt wird. Traffic aus dem Internet können Sie damit nicht ausgleichen.

Der Bereich eines internen TCP/UDP-Load-Balancers ist regional und nicht global. Das bedeutet, dass ein TCP/UDP-Load-Balancer nicht mehrere Regionen umfassen kann. Innerhalb einer einzelnen Region werden alle Zonen vom Load-Balancer bedient. Weitere Informationen finden Sie unter Regionen und Zonen.

Unter Load-Balancer auswählen und Übersicht über das Load-Balancing finden Sie Informationen zu den Unterschieden zwischen verschiedenen Cloud-Load-Balancern.

Anwendungsfälle

Zugriffsbeispiele

Zugriff auf einen internen TCP/UDP-Load-Balancer in Ihrem VPC-Netzwerk über ein verbundenes Netzwerk erhalten Sie mithilfe von:

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

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

Beispiel für einen dreischichtigen Webdienst

Internes Load-Balancing lässt sich in Verbindung mit anderen Load-Balancern wie dem HTTP(S)-Load-Balancer verwenden. Dabei greift die Webschicht auf den externen Load-Balancer zurück, welcher dann mit Diensten hinter dem internen Load-Balancer arbeitet.

Das folgende Diagramm zeigt ein Beispiel für eine dreischichtige Konfiguration, die externe HTTP(S) und interne TCP/UDP-Load-Balancer verwendet:

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

Funktionsweise des internen TCP/UDP-Load-Balancings

Internes TCP/UDP-Load-Balancing hat die folgenden Eigenschaften:

  • Der Load-Balancer ist ein verwalteter Dienst.
  • Der Load-Balancer ist kein Proxy.
  • Die Implementierung erfolgt über virtuelle Netzwerke.
  • Es gibt kein Zwischengerät und keinen Single Point of Failure.
  • Antworten von den Back-End-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer.

Im Gegensatz zu einem geräte- oder instanzbasierten Load-Balancer beendet das interne TCP/UDP-Load-Balancing keine Verbindungen von Clients. Statt Traffic an einen Load-Balancer und dann an Back-Ends zu senden, wird der Traffic direkt an die Back-Ends gesendet. Die Linux- oder Windows-Gastumgebung der GCP konfiguriert jede Back-End-VM mit der IP-Adresse des Load-Balancers und das virtuelle GCP-Netzwerk verwaltet eingehenden Traffic und skaliert ihn nach Bedarf.

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, 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-Gastumgebung, 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 zur 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. TCP/UDP-Load-Balancer lassen sich auch mit einem bereits bestehendem Legacy-Netzwerk erstellen.

Auf den internen TCP/UDP-Load-Balancer haben nur Client-VMs in der Region Zugriff. Client-VMs im selben VPC-Netzwerk müssen sich in derselben Region befinden, jedoch nicht unbedingt im selben Subnetz, um Pakete an den internen TCP/UDP-Load-Balancer senden zu können. Sie können auch von einem Clientsystem einem anderen Netzwerk aus mit einem internen TCP/UDP-Load-Balancer kommunizieren, solange das andere Netzwerk richtig mit dem VPC-Netzwerk verbunden ist, in dem der Load-Balancer definiert ist. Weitere Informationen finden Sie unter Internes TCP/UDP-Load-Balancing und verbundene Netzwerke.

Hochverfügbarkeit

Der interne TCP/UDP-Load-Balancer ist standardmäßig hochverfügbar. Die Hochverfügbarkeit des Load-Balancers lässt sich nicht speziell einstellen, da das Verfahren nicht auf einem einzelnen Gerät oder einer VM-Instanz basiert.

Die folgenden Best Practices beschreiben, wie Back-End-VM-Instanzen bereitgestellt werden, sodass Sie nicht nur auf eine einzige Zone angewiesen sind:

  • 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 GCP-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 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
• ein load-balancing-scheme des Typs INTERNAL haben,
• ein ip-protocol des Typs TCP oder UDP verwenden, das mit dem protocol des Back-End-Dienstes übereinstimmt, und
• auf ein subnet im VPC-Netzwerk in derselben Region verweisen, in der sich auch der Back-End-Dienst befindet.
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
• ein load-balancing-scheme des Typs INTERNAL haben,
• ein protocol des Typs TCP oder UDP verwenden, das mit dem protocol der Weiterleitungsregel übereinstimmt,
• eine zugehörige Systemdiagnose haben und
• auf Back-Ends in derselben Region verweisen. Back-End-Instanzgruppen können sich in jedem Subnetz der Region befinden. Der Back-End-Dienst selbst ist nicht an ein bestimmtes Subnetz gebunden.
Systemdiagnose Jeder Back-End-Dienst muss eine zugehörige Systemdiagnose haben. Die Systemdiagnose definiert die Parameter, anhand derer die GCP die von ihr 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 die GCP keine Systemdiagnose für UDP-Traffic. Weitere Informationen finden Sie unter Systemdiagnosen und UDP-Traffic.

Interne IP-Adresse

Beim internen TCP/UDP-Load-Balancing wird eine interne, private IPv4-Adresse (RFC 1918) aus dem primären IP-Bereich des Subnetzes verwendet, den 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 oder einer reservierten IP-Adresse wählen.

Weiterleitungsregeln

Beim internen TCP/UDP-Load-Balancing ist mindestens eine interne Weiterleitungsregel in einem Subnetz erforderlich, das sich in derselben Region wie der Back-End-Dienst und die Instanzgruppen (zusammen die Back-End-Komponenten) befindet. Eine interne Weiterleitungsregel muss sich in derselben Region wie der Back-End-Dienst des Load-Balancers befinden und dasselbe Protokoll verwenden.

Mit der Weiterleitungsregel definieren Sie die Ports, über die der Load-Balancer den Traffic annimmt. TCP/UDP-Load-Balancer sind keine Proxys und sie leiten Traffic an Back-Ends an denselben Ports weiter, an denen der Traffic empfangen wird. Sie müssen mindestens eine Portnummer pro Weiterleitungsregel angeben.

Zusätzlich zu den Ports müssen Sie beim Erstellen einer internen Weiterleitungsregel auf ein bestimmtes Subnetz in Ihrem VPC-Netzwerk verweisen. Das Subnetz, das Sie für die Weiterleitungsregel angeben, muss nicht mit einem der Subnetze identisch sein, die von Back-End-VMs verwendet werden. Die Weiterleitungsregel, das Subnetz und der Back-End-Dienst müssen sich jedoch alle in derselben Region befinden. Wenn Sie eine interne Weiterleitungsregel erstellen, wählt die GCP eine verfügbare interne IP-Adresse aus dem primären IP-Adressbereich des von Ihnen ausgewählten Subnetzes aus. Alternativ können Sie eine interne IP-Adresse im primären IP-Bereich des Subnetzes festlegen.

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.

Erstellen Sie eine interne Weiterleitungsregel, die alle Ports unterstützt, um den gesamten Traffic für ein bestimmtes Protokoll (z. B. TCP) an einen einzelnen internen Load-Balancer weiterzuleiten. Dadurch können Back-End-VMs mehrere Anwendungen (eine pro 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 Bedenken haben, Back-End-Anwendungen für alle Ports zu öffnen, richten Sie Firewallregeln in den Back-End-VMs ein, um den Bereich des eingehenden Traffics auf die erwarteten Ports festzulegen.

Weiterleitungsregeln lassen sich nicht mehr ändern, nachdem Sie sie erstellt haben. Wenn Sie die angegebenen Ports oder die interne IP-Adresse einer internen Weiterleitungsregel ändern müssen, löschen und ersetzen Sie die Regel.

Mehrere Weiterleitungsregeln

Sie können mehrere interne Weiterleitungsregeln für denselben internen Load-Balancer konfigurieren. Jede Weiterleitungsregel muss eine eigene eindeutige IP-Adresse haben und darf nur auf einen einzigen Back-End-Dienst verweisen. Mehrere interne Weiterleitungsregeln können auf denselben Back-End-Dienst verweisen.

Die Konfiguration mehrerer interner Weiterleitungsregeln kann nützlich sein, wenn Sie mehr als eine IP-Adresse für denselben internen TCP/UDP-Load-Balancer benötigen oder bestimmte Ports mit verschiedenen IP-Adressen verknüpfen müssen. Wenn Sie mehrere interne Weiterleitungsregeln verwenden, müssen Sie die auf Ihren Back-End-VMs ausgeführte Software so konfigurieren, dass sie an alle erforderlichen IP-Adressen gebunden wird. Das liegt daran, dass die Ziel-IP-Adresse für über den Load-Balancer gelieferte Pakete die interne IP-Adresse der entsprechenden internen Weiterleitungsregel ist.

Informationen zum Erstellen einer sekundären Weiterleitungsregel finden Sie auf der Seite Internes TCP/UDP-Load-Balancing einrichten. In diesem Beispiel werden zwei Weiterleitungsregeln, eine mit 10.1.2.99 und eine andere mit 10.5.6.99, konfiguriert. Die Back-End-VMs müssen so konfiguriert sein, dass sie Pakete an beide diese IP-Adressen empfangen. Eine Möglichkeit dafür besteht darin, die Back-Ends so zu konfigurieren, dass sie an eine beliebige IP-Adresse gebunden sind (0.0.0.0/0).

Back-End-Dienst

Jeder interne TCP/UDP-Load-Balancer verwendet einen regionalen internen Back-End-Dienst. Der Name des Back-End-Dienstes ist der Name des internen TCP/UDP-Load-Balancers, der in der GCP Console angezeigt wird.

Der Back-End-Dienst akzeptiert Traffic, der über eine oder mehrere interne Weiterleitungsregeln an ihn gesendet wird. Ein regionaler interner Back-End-Dienst akzeptiert entweder TCP- oder UDP-Traffic, aber nicht beides, und sendet Traffic an Back-End-VMs an denselben Ports, an die der Traffic gemäß der Weiterleitungsregel gesendet wurde.

Back-End-Dienste müssen mindestens eine Back-End-Instanzgruppe und eine zugehörige Systemdiagnose haben. Back-Ends können nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen oder regionale verwaltete Instanzgruppen in derselben Region sein, in der sich auch der Back-End-Dienst und die Weiterleitungsregel befinden. Der Back-End-Dienst verteilt Traffic an die Back-End-VMs und verwaltet die Sitzungsaffinität, sofern dies konfiguriert ist.

Systemdiagnose

Der Back-End-Dienst des Load-Balancers muss mit einer Systemdiagnose verknüpft werden. Spezielle Routen außerhalb des VPC-Netzwerks werden verwendet, um die Kommunikation zwischen Systemdiagnosen und Back-Ends zu ermöglichen.

Sie können eine vorhandene Systemdiagnose verwenden oder eine neue definieren. Interne TCP/UDP-Load-Balancer senden Traffic nur an Back-End-VMs, die ihre Systemdiagnose-Prüfungen bestanden haben. Wenn jedoch keine der Back-End-VMs die Systemdiagnose-Prüfung besteht, verteilt die GCP den Traffic auf alle Back-End-VMs.

Sie können eines der folgenden Systemdiagnose-Protokolle 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. Beachten Sie, dass 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 von der Art der erstellten Systemdiagnose sendet die GCP Systemdiagnose-Prüfungen an die IP-Adresse des internen TCP/UDP-Load-Balancers und simuliert so die Bereitstellung von Traffic mit Load-Balancing. Software, die auf Ihren Back-End-VMs ausgeführt wird, muss sowohl auf Traffic mit Load-Balancing als auch auf Systemdiagnose-Prüfungen reagieren, die an die IP-Adresse des Load-Balancers selbst gesendet werden. Weitere Informationen finden Sie unter Ziel für Systemdiagnose-Pakete.

Systemdiagnosen und UDP-Traffic

Die GCP bietet keine Systemdiagnose an, 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 ein Load-Balancing von Clientanfragen mithilfe des UDP-Protokolls und ein TCP-Dienst wird verwendet, um den GCP-Systemdiagnose-Probern Informationen bereitzustellen. Sie können beispielsweise auf jeder Back-End-VM, die eine HTTP 200-Antwort an die GCP 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 200 nur dann zurückgibt, wenn der UDP-Dienst ordnungsgemäß konfiguriert ist und ausgeführt wird.

Traffic-Verteilung

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

  • Wenn Sie keinen Failover konfiguriert haben, verteilt ein interner TCP/UDP-Load-Balancer neue Verbindungen zwischen allen seinen fehlerfreien Back-End-VMs, wenn mindestens eine Back-End-VM fehlerfrei ist. Wenn alle Back-End-VMs fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Back-Ends.

  • Wenn Sie einen Failover konfiguriert haben, verteilt ein interner TCP/UDP-Load-Balancer die neue Verbindung zwischen den VMs in seinem aktiven Pool, und zwar gemäß einer von Ihnen konfigurierten Failover-Richtlinie. Sind alle Back-End-VMs fehlerhaft, können Sie den Traffic unterbrechen oder nicht.

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 Traffic-Verteilung für TCP-Traffic ändern, indem Sie eine Option für die Sitzungsaffinität angeben.

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

Optionen für die 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 Optionen für die Sitzungsaffinität, die Sie für den gesamten internen Back-End-Dienst und nicht einzeln für jede Back-End-Instanzgruppe angeben:

  • Keine: Standardeinstellung, die dem Client-IP-Protokoll und -Port entspricht
  • Client-IP: leitet Anfragen eines bestimmten Clients an dieselbe Back-End-VM, und zwar anhand eines Hashwerts, der aus der IP-Adresse des Clients und der Ziel-IP-Adresse erstellt wurde
  • Client-IP und -Protokoll: leitet die Anfragen eines bestimmten Clients an dieselbe Back-End-VM, 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, 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
    • Ziel-IP-Adresse
    • 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. Wenn ein interner TCP/UDP-Load-Balancer ein nächster Hop für eine Route ist, lesen Sie den Abschnitt Sitzungsaffinität und interner TCP/UDP-Load-Balancer für den nächsten Hop.

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

Unabhängig von der ausgewählten Sitzungsaffinitätsoption verwendet die GCP 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 internes 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.

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 geleitet, 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 es sich beim Clientsystem nicht um eine VM handelt, für Load-Balancing durchgeführt wird, also um 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 Traffic-Verteilung ü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 Traffic-Verteilung 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 auch 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 selbst beantwortet. Dies geschieht unabhängig davon, ob die Back-End-VM fehlerfrei ist, und zwar 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 Load-Balancing-Ressourcenkontingente.

Weitere Informationen