Externes TCP/UDP-Netzwerk-Load-Balancing von Google Cloud (ab jetzt als Netzwerk-Load-Balancing bezeichnet) ist ein regionaler Load-Balancer ohne Proxy.
Mit dem Netzwerk-Load-Balancing wird der Traffic auf VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud) verteilt. Ein Netzwerk-Load-Balancer leitet TCP- oder UDP-Traffic über regionale Back-Ends weiter.
Der Netzwerk-Load-Balancer unterstützt alle Ports. Mit dem Netzwerk-Load-Balancing können Sie TCP- und UDP-Traffic verteilen. Da dies hier ein Passthrough-Load-Balancer ist, beenden Ihre Back-Ends die TCP-Verbindung mit Load-Balancing oder die UDP-Pakete selbst. Sie können beispielsweise einen HTTPS-Webserver auf Ihren Back-Ends ausführen und über ein Netzwerk-Load-Balancing Anfragen an diesen weiterleiten, wobei TLS auf Ihren Back-Ends selbst beendet wird.
Weitere Informationen zu unterstützten Ports finden Sie unter Zusammenfassung zu den Load-Balancern von Google Cloud.
Das Netzwerk-Load-Balancing hat die folgenden Eigenschaften:
- Das Netzwerk-Load-Balancing ist ein verwalteter Dienst.
- Das Netzwerk-Load-Balancing wird mithilfe eines virtuellen Andromeda-Netzwerks und mit Google Maglev implementiert.
- Die Netzwerk-Load-Balancer sind keine Proxys.
- Antworten von den Back-End-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe.
- Der Load-Balancer behält die Quell-IP-Adressen der Pakete bei.
- Die Ziel-IP-Adresse für Pakete ist die regionale externe IP-Adresse, die der Weiterleitungsregel des Load-Balancers zugeordnet ist.
Dies hat folgende Konsequenzen:
Instanzen, die als Back-End-VMs für Netzwerk-Load-Balancer verwendet werden, müssen die entsprechende Linux-Gastumgebung, Windows-Gastumgebung oder andere Prozesse ausführen, die gleichwertige Funktionen bereitstellen.
Die Gastumgebung des Betriebssystems (oder ein äquivalenter Prozess) ist für die Konfiguration lokaler Routen auf jeder Back-End-VM zuständig. Über diese Routen kann die VM Pakete mit einem Ziel empfangen, das mit der IP-Adresse der Weiterleitungsregel des Load-Balancers übereinstimmt.
Bei Back-End-Instanzen, die mit Load-Balancing verteilten Traffic empfangen, muss die Software so konfiguriert werden, dass sie an die IP-Adresse der Weiterleitungsregel des Load-Balancers (oder an eine beliebige IP-Adresse –
0.0.0.0/0) gebunden wird.
Das folgende Diagramm zeigt Nutzer in Kalifornien, New York und Singapur. Sie alle stellen eine Verbindung zu ihren Back-End-Ressourcen "myapp", "test" und "travel" her. Wenn ein Nutzer in Singapur eine Verbindung zum Back-End "USA West" herstellt, geht der Traffic möglichst nahe bei Singapur ein, da der Bereich per Anycast adressiert wird. Von dort wird der Traffic an das regionale Back-End weitergeleitet.
Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:
Protokolle, Schema und Bereich
Jeder interne Netzwerk-Load-Balancer unterstützt entweder TCP- oder UDP-Traffic (nicht beides).
Ein Netzwerk-Load-Balancer verteilt den aus dem Internet stammenden Traffic gleichmäßig.
Der Bereich eines Netzwerk-Load-Balancers ist regional und nicht global. Das bedeutet, dass ein Netzwerk-Load-Balancer nicht mehrere Regionen umfassen kann. Innerhalb einer einzelnen Region werden alle Zonen vom Load-Balancer bedient.
Anwendungsfälle
Unter den folgenden Umständen sollten Sie Netzwerk-Load-Balancing verwenden:
- Sie müssen Load-Balancing für UDP-Traffic oder für einen TCP-Port, der nicht von anderen Load-Balancern unterstützt wird, verwenden.
- Es ist zulässig, dass SSL-Traffic von Ihren Back-Ends und nicht vom Load-Balancer entschlüsselt wird. Der Netzwerk-Load-Balancer kann diese Aufgabe nicht ausführen. Wenn die Back-Ends den SSL-Traffic entschlüsseln, ist die CPU-Last auf den VMs höher.
- Die SSL-Zertifikate des Load-Balancers können Sie selbst verwalten. Von Google verwaltete SSL-Zertifikate sind nur für das HTTP(S)-Load-Balancing und das SSL-Proxy-Load-Balancing verfügbar.
- Sie müssen die ursprünglichen Pakete ohne Proxy weiterleiten.
- Sie haben bereits eine Konfiguration, in der ein Pass-Through-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.
Architektur
Der Load-Balancer besteht aus mehreren Konfigurationskomponenten. Ein einzelner Load-Balancer kann folgende Komponenten haben:
Ein Netzwerk-Load-Balancer hat immer einen Zielpool. Auf den Zielpool können mehrere Weiterleitungsregeln verweisen.
Der Zielpool ist ein Back-End für den Load-Balancer. Damit werden die Back-End-Instanzen angegeben, zwischen denen Traffic verteilt wird. Jede Weiterleitungsregel ist ein Front-End für den Load-Balancer. Beachten Sie, dass die Anzahl der Weiterleitungsregeln und Zielpools pro Projekt begrenzt ist.
Der Netzwerk-Load-Balancer verteilt die Last auf Ihren Systemen gleichmäßig anhand eingehender IP-Protokolldaten wie Adresse, Port und Protokolltyp.
Der Netzwerk-Load-Balancer ist ein Pass-Through-Load-Balancer, sodass Ihre Back-Ends die ursprüngliche Client-Anfrage erhalten. Der Netzwerk-Load-Balancer führt keine TLS-Auslagerung oder -Proxys (Transport Layer Security) aus. Traffic wird direkt an Ihre VMs weitergeleitet.
Wenn Sie eine Weiterleitungsregel für den Load-Balancer erstellen, erhalten Sie eine sitzungsspezifische virtuelle IP-Adresse (VIP) oder reservieren eine VIP, die von einem regionalen Netzwerkblock stammt.
Anschließend ordnen Sie diese Weiterleitungsregel Ihren Zielpools zu. Die VIP ist eine Anycast-Adresse und stammt aus den globalen Points of Presence von Google. Die Back-Ends für einen Netzwerk-Load-Balancer sind jedoch regional. Der Load-Balancer kann keine Back-Ends haben, die sich über mehrere Regionen erstrecken.
Sie können Google Cloud-Firewalls verwenden, um den Zugriff auf die Back-End-VMs zu steuern oder zu filtern.
Der Netzwerk-Load-Balancer überprüft die Quell- und Zielports, die IP-Adresse und das Protokoll, um zu bestimmen, wie Pakete weitergeleitet werden. Bei TCP-Traffic können Sie das Weiterleitungsverhalten des Load-Balancers durch Konfigurieren der Sitzungsaffinität ändern.
Lastenverteilungsalgorithmus
Standardmäßig wird der Sitzungsaffinitätswert auf NONE festgelegt, um Traffic an Instanzen zu verteilen. Cloud Load Balancing wählt eine Instanz anhand eines Hashwerts der Quell-IP-Adresse und des Quellports, der Ziel-IP-Adresse und des Zielports sowie des Protokolls aus. Das bedeutet, dass eingehende TCP-Verbindungen über Instanzen verteilt werden und jede neue Verbindung an eine andere Instanz gehen kann. Sämtliche Datenpakete für eine Verbindung werden an dieselbe Instanz geleitet, bis die Verbindung beendet wird. Bereits bestehende Verbindungen werden beim Load-Balancing-Prozess nicht berücksichtigt.
Unabhängig von der Einstellung der Sitzungsaffinität werden alle Datenpakete für eine Verbindung so lange an die gewählte Instanz geleitet, bis die Verbindung beendet wird. Eine vorhandene Verbindung hat keinen Einfluss auf Load-Balancing-Entscheidungen für neue eingehende Verbindungen. Dies kann zu einem Ungleichgewicht zwischen Back-Ends führen, wenn langlebige TCP-Verbindungen in Gebrauch sind.
Wenn mehrere Verbindungen von einem Client zur selben Instanz geleitet werden sollen, können Sie eine andere Einstellung für die Sitzungsaffinität wählen.
Zielpools
Mit einer Zielpoolressource wird eine Gruppe von Instanzen definiert, die eingehenden Traffic über Weiterleitungsregeln empfangen sollen. Wenn eine Weiterleitungsregel Traffic an einen Zielpool weiterleitet, wählt Cloud Load Balancing basierend auf einem Hash der Quell-IP und ihrem Port sowie der Ziel-IP und ihrem Port eine Instanz aus diesen Zielpools aus. Weitere Informationen zur Verteilung des Traffics auf Instanzen finden Sie weiter unten im Abschnitt Lastenverteilungsalgorithmus.
Ein Netzwerk-Load-Balancer verteilt den Traffic nur auf die primäre Netzwerkschnittstelle (nic0) einer Back-End-Instanz.
Zielpools können nur mit Weiterleitungsregeln verwendet werden, die TCP- und UDP-Datenverkehr handhaben. Für alle anderen Protokolle müssen Sie eine Zielinstanz erstellen. Sie müssen einen Zielpool erstellen, bevor Sie ihn mit einer Weiterleitungsregel verwenden können. Ein Projekt kann bis zu 50 Zielpools enthalten.
Wenn ein Zielpool eine einzelne VM-Instanz enthalten soll, verwenden Sie die Protokollweiterleitung.
Das Netzwerk-Load-Balancing unterstützt Cloud Load Balancing Autoscaler, womit Nutzer anhand der Back-End-Nutzung ein Autoscaling für die Instanzgruppen im Zielpool ausführen können. Weitere Informationen hierzu finden Sie unter Anhand der CPU-Auslastung skalieren.
Weiterleitungsregeln
Weiterleitungsregeln werden gemeinsam mit Zielpools verwendet, um das Load-Balancing zu unterstützen. Sie müssen eine Weiterleitungsregel erstellen, die Traffic an bestimmte Zielpools leitet, um Load-Balancing verwenden zu können. Es ist nicht möglich, den Traffic ohne Weiterleitungsregel über Load-Balancing zu verteilen.
Jede Weiterleitungsregel vergleicht eine bestimmte IP-Adresse, ein bestimmtes Protokoll und – optional – einen Portbereich mit einem einzelnen Zielpool. Wenn Traffic an eine externe IP-Adresse gesendet wird, die von einer Weiterleitungsregel bereitgestellt wird, leitet die Weiterleitungsregel den Traffic an den entsprechenden Zielpool weiter.
Wenn Sie wahrscheinlich fragmentierte UDP-Pakete über Load-Balancing verteilen, bevor sie in Ihrem Google Cloud VPC-Netzwerk eintreffen, lesen Sie Load-Balancing und fragmentierte UDP-Datenpakete.
Mehrere Weiterleitungsregeln
Sie können mehrere regionale externe Weiterleitungsregeln für denselben externen TCP/UDP-Netzwerk-Load-Balancer konfigurieren. Optional kann jede Weiterleitungsregel eine andere regionale externe IP-Adresse haben. Es können aber auch mehrere Weiterleitungsregeln auf dieselbe regionale externe IP-Adresse verweisen.
Das Konfigurieren mehrerer regionaler externer Weiterleitungsregeln kann für die folgenden Anwendungsfälle nützlich sein:
- Sie möchten mehr als eine externe IP-Adresse für denselben Zielpool konfigurieren.
- Sie müssen unterschiedliche Portbereiche oder unterschiedliche Protokolle konfigurieren und dabei dieselbe externe IP-Adresse für einen Zielpool verwenden.
Wenn Sie mehrere Weiterleitungsregeln verwenden, sollten Sie die auf Ihren Back-End-VMs ausgeführte Software so konfigurieren, dass sie an alle erforderlichen IP-Adressen gebunden wird. Dies ist erforderlich, da die Ziel-IP-Adresse für Pakete, die über den Load-Balancer gesendet werden, die regionale externe IP-Adresse ist, die der jeweiligen regionalen externen Weiterleitungsregel zugeordnet ist.
Systemdiagnosen
Systemdiagnosen sorgen dafür, dass Compute Engine neue Verbindungen nur an empfangsbereite Instanzen leitet. Compute Engine sendet Systemdiagnoseanfragen mit der festgelegten Häufigkeit an die einzelnen Instanzen. Wenn eine Instanz die für sie maximal zulässige Anzahl fehlgeschlagener Systemdiagnosen überschreitet, gilt sie nicht mehr als für den Empfang von neuem Traffic geeignet.
Um ein ordnungsgemäßes Herunterfahren und Schließen von TCP-Verbindungen zu ermöglichen, werden bestehende Verbindungen nicht aktiv beendet. Bestehende Verbindungen zu einem fehlerhaften Back-End können jedoch über längere Zeit nicht beibehalten werden. Eine fehlerhafte Back-End-VM sollte so schnell wie möglich für verbleibende TCP-Verbindungen ein ordnungsgemäßes Herunterfahren initiieren.
Mehrere Systemdiagnose-Prober prüfen jedes Back-End gemäß einem konfigurierbaren Prüfintervall. Weitere Informationen finden Sie unter Funktionsweise von Systemdiagnosen.
Wie ein Netzwerk-Load-Balancer Verbindungen verteilt, wenn alle Zielpool-VMs fehlerhaft sind, hängt davon ab, ob Sie einen Sicherungspool konfiguriert haben:
Wenn Sie keinen Sicherungspool konfiguriert haben und alle Back-End-VMs im Zielpool fehlerhaft sind, verteilt der Load-Balancer als letzte Möglichkeit neue Verbindungen zwischen allen Back-End-VMs im Zielpool.
Wenn Sie einen Sicherungspool konfiguriert haben, wird der Traffic an VMs im Sicherungspool weitergeleitet, wenn alle Back-End-VMs im Zielpool fehlerhaft sind. Für Szenarien, in denen VMs im Sicherungspool fehlerhaft sind, lesen Sie die Informationen unter Failover-Bedingungen.
Das Netzwerk-Load-Balancing basiert auf Legacy-HTTP-Systemdiagnosen zur Bestimmung des Zustands der Instanzen. Selbst wenn Ihr Dienst kein HTTP verwendet, müssen Sie auf jeder Instanz einen einfachen Webserver ausführen, den die Systemdiagnose abfragen kann.
Legacy-HTTPS-Systemdiagnosen werden nicht für Netzwerk-Load-Balancer unterstützt und können nicht mit den meisten anderen Arten von Load-Balancern verwendet werden.
Rückgabepfad
Google Cloud verwendet spezielle Routen, die in Ihrem VPC-Netzwerk für Systemdiagnosen nicht definiert sind. Weitere Informationen finden Sie unter Load-Balancer-Rückgabepfade.
Firewallregeln
Systemdiagnosen für Netzwerk-Load-Balancer werden aus diesen IP-Bereichen gesendet. Sie müssen Firewall-Zulassungsregeln für eingehenden Traffic erstellen, wenn Sie Traffic aus diesen Bereichen zulassen möchten.
Netzwerk-Load-Balancing ist ein Pass-Through-Load-Balancer. Das bedeutet, dass die Firewallregeln Traffic von den Quell-IP-Adressen der Clients zulassen müssen. Bei einem zum Internet geöffneten Dienst ist es am einfachsten, den Traffic von allen IP-Bereichen zuzulassen. Wenn Sie den Zugriff beschränken möchten, sodass nur bestimmte Quell-IP-Adressen zulässig sind, können Sie Firewallregeln zur Durchsetzung der Beschränkung einrichten. Sie müssen allerdings den Zugriff über die IP-Bereiche der Systemdiagnose zulassen.
Ein Beispiel für eine Firewallregel und ein Konfigurationsbeispiel finden Sie unter Regeln für Netzwerk-Load-Balancing.
Sitzungsaffinität
Beim Netzwerk-Load-Balancing wird für Back-End-Dienste keine Sitzungsaffinität verwendet. Stattdessen verwenden Netzwerk-Load-Balancer Zielpools für die Sitzungsaffinität.
Weitere Informationen finden Sie beim Parameter sessionAffinity unter Zielpools verwenden.
Load-Balancing und fragmentierte UDP-Datenpakete
Beachten Sie beim Load-Balancing von UDP-Datenpaketen Folgendes:
- Nicht fragmentierte Datenpakete werden in allen Konfigurationen normal behandelt.
- UDP-Pakete können fragmentiert werden, bevor Sie in Google Cloud ankommen. Dabei warten die beteiligten Netzwerke mit der Weiterleitung entweder auf das Eintreffen aller Fragmente, wodurch es zu Verzögerungen kommt, oder sie verwerfen Fragmente. Google Cloud wartet nicht auf alle Fragmente, sondern leitet jedes Fragment weiter, sobald es eintrifft.
Da nachfolgende UDP-Fragmente nicht den Zielport enthalten, können in folgenden Situationen Probleme auftreten:
- Wenn die Zielpool-Sitzungsaffinität auf
NONE(5-Tupel-Affinität) eingestellt ist, werden die nachfolgenden Fragmente möglicherweise verworfen, da der Load-Balancer nicht den 5-Tupel-Hashwert berechnen kann. - Wenn für dieselbe IP-Adresse mit Load-Balancing mehrere UDP-Weiterleitungsregeln bestehen, gelangen nachfolgende Fragmente möglicherweise zur falschen Weiterleitungsregel.
- Wenn die Zielpool-Sitzungsaffinität auf
Wenn Sie fragmentierte UDP-Datenpakete erwarten, gehen Sie so vor:
- Setzen Sie die Sitzungsaffinität auf
CLIENT_IP_PROTOoderCLIENT_IP. Verwenden Sie nichtNONE(5-Tupel-Hashing). DaCLIENT_IP_PROTOundCLIENT_IPbeim Hashing nicht den Zielport verwenden, kann für nachfolgende Fragmente derselbe Hashwert wie für das erste Fragment berechnet werden. - Verwenden Sie nur eine UDP-Weiterleitungsregel pro IP-Adresse mit Load-Balancing. Dadurch wird gewährleistet, dass alle Fragmente zur selben Weiterleitungsregel gelangen.
Bei diesen Einstellungen werden UDP-Fragmente aus demselben Datenpaket an dieselbe Instanz geleitet, um dort wieder zusammengesetzt zu werden.
Freigegebene VPC
In der folgenden Tabelle sind die Komponenten einer freigegebenen VPC für das Netzwerk-Load-Balancing zusammengefasst:
| IP-Adresse | Weiterleitungsregel | Back-End-Komponenten |
|---|---|---|
| Eine regionale externe IP-Adresse muss im selben Projekt wie die Instanzen mit Load-Balancing definiert werden. | Eine regionale externe Weiterleitungsregel muss im selben Projekt wie die Instanzen im Zielpool definiert werden, also dem Dienstprojekt. | Der Zielpool muss im selben Projekt und in derselben Region wie die Instanzen im Zielpool definiert werden. Mit dem Zielpool verknüpfte Systemdiagnosen müssen auch im selben Projekt definiert werden. |
Weitere Informationen
- Mehr zum Konfigurieren eines Netzwerk-Load-Balancers und zum Verteilen von Traffic auf mehrere Apache-Instanzen erfahren Sie unter Netzwerk-Load-Balancing einrichten.