Ein externer Passthrough-Netzwerk-Load-Balancer ist ein regionaler Layer-4-Load-Balancer. Mit externen Passthrough-Netzwerk-Load-Balancern wird TCP- und UDP-Traffic auf Backend-VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud) verteilt. Ein externer Passthrough-Netzwerk-Load-Balancer kann Traffic von folgenden Quellen empfangen:
- Jedem Client im Internet
- Google Cloud-VMs mit externen IP-Adressen
- Google Cloud-VMs mit Internetzugriff über Cloud NAT oder instanzbasiertes NAT
Abhängig von der Konfiguration der Weiterleitungsregel unterstützt jeder Zielpool-basierte Load-Balancer eine der folgenden Arten von Protokolltraffic:
- TCP
- UDP
- TCP und UDP
Der Bereich des Load-Balancers ist regional und nicht global. Das bedeutet, dass sich alle Backend-Instanzen für einen Netzwerk-Load-Balancer in derselben Region befinden müssen. Sie können Back-Ends in jeder Zone der Region platzieren.
Externe Passthrough-Netzwerk-Load-Balancer unterstützen alle Ports. Sie können einen externen Passthrough-Netzwerk-Load-Balancer verwenden, um Load-Balancing für TCP- oder UDP-Traffic auszuführen. 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 einen externen Passthrough-Netzwerk-Load-Balancer Anfragen an diesen weiterleiten, wobei TLS auf Ihren Back-Ends selbst beendet wird.
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 eigenständigen Load-Balancing-Architektur identisch, mit dem Unterschied, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird. Weitere Informationen finden Sie unter Anwendungen mit Diensten freigeben.
Architektur
Der Load-Balancer besteht aus mehreren Konfigurationskomponenten. Ein einzelner Load-Balancer kann folgende Komponenten haben:
Ein externer Passthrough-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 Frontend für den Load-Balancer. Beachten Sie, dass die Anzahl der Weiterleitungsregeln und Zielpools pro Projekt begrenzt ist.
Der externe Passthrough-Netzwerk-Load-Balancer verteilt die Last auf Ihren Systemen gleichmäßig anhand eingehender IP-Protokolldaten wie Adresse, Port und Protokolltyp.
Der externe Passthrough-Netzwerk-Load-Balancer ist ein Pass-Through-Load-Balancer, sodass Ihre Back-Ends die ursprüngliche Client-Anfrage erhalten. Der externe Passthrough-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 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 Backend-VMs zu steuern oder zu filtern.
Der externe Passthrough-Netzwerk-Load-Balancer prüft die Quell- und Zielports, die IP-Adresse und das Protokoll, um zu festzulegen, wie Pakete weitergeleitet werden. Bei TCP-Traffic können Sie das Weiterleitungsverhalten des Load-Balancers durch Konfigurieren der Sitzungsaffinität ändern. Der externe Passthrough-Netzwerk-Load-Balancer leitet Pakete an die erste Netzwerkschnittstelle (nic0) der Instanzen im Zielpool weiter.
Der Load-Balancer behält die Quell-IP-Adressen der eingehenden Pakete bei. Die Ziel-IP-Adresse für eingehende Pakete ist die regionale externe IP-Adresse, die der Weiterleitungsregel des Load-Balancers zugeordnet ist.
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. Jeder Zielpool wird in einer einzelnen Region ausgeführt und verteilt den Traffic an die erste Netzwerkschnittstelle (nic0) der Back-End-Instanz. Weitere Informationen zur Verteilung des Traffics auf Instanzen finden Sie im Abschnitt Lastenverteilungsalgorithmus.
Die externen Passthrough-Netzwerk-Load-Balancer sind keine Proxys. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Load-Balancer behält die Quell-IP-Adressen der Pakete bei. Die Ziel-IP-Adresse für eingehende Pakete ist die regionale externe IP-Adresse, die der Weiterleitungsregel des Load-Balancers zugeordnet ist. Dies hat folgende Konsequenzen:
Instanzen, die als Backend-VMs für externe Passthrough-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 Backend-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.
Externe Passthrough-Netzwerk-Load-Balancer unterstützen Compute Engine-Autoscaling, mit dem Nutzer anhand der Backend-Nutzung ein Autoscaling für die Instanzgruppen im Zielpool ausführen können. Weitere Informationen hierzu finden Sie unter Anhand der CPU-Auslastung skalieren.
Wenn ein Zielpool eine einzelne VM-Instanz enthalten soll, verwenden Sie die Protokollweiterleitung.
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.
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.
Zielpool-basierte externe Passthrough-Load-Balancer unterstützen die folgenden Protokolle für jede Weiterleitungsregel: TCP oder UDP. Wenn der Load-Balancer den gesamten IP-Protokoll-Traffic weiterleiten soll, müssen Sie einen Backend-Dienst-basierten externen Passthrough-Netzwerk-Load-Balancer verwenden.
Mehrere Weiterleitungsregeln
Sie können mehrere regionale externe Weiterleitungsregeln für denselben externen Passthrough-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. Bei bestehenden Verbindungen zu einem fehlerhaften Back-End kann jedoch nicht garantiert werden, dass sie über längere Zeit aufrechterhalten werden. Sofern möglich, sollten Sie so schnell wie möglich ein ordnungsgemäßes Herunterfahren des fehlerhaftes Back-Ends starten.
Die fehlerhaften Instanzen werden weiterhin durch die Systemdiagnose abgefragt und bei Erreichen der festgelegten Anzahl erfolgreicher Prüfungen wieder in den Pool zurückgeführt. Wenn alle Instanzen als UNHEALTHY markiert sind, leitet der Load-Balancer neuen Traffic an alle vorhandenen Instanzen weiter.
Die externen Passthrough-Netzwerk-Load-Balancer basieren 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 externe Passthrough-Netzwerk-Load-Balancer unterstützt und können nicht mit den meisten anderen Arten von Load-Balancern verwendet werden.
Firewallregeln
Systemdiagnosen für externe Passthrough-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.
Externe Passthrough-Netzwerk-Load-Balancer sind 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 Firewallregeln für externe Passthrough-Netzwerk-Load-Balancer.
IP-Adressen für Anfrage- und Rückgabepakete
Wenn eine Backend-VM ein Paket mit Load-Balancing von einem Client empfängt, sind die Quelle und das Ziel des Pakets:
- Quelle: die externe IP-Adresse, die einer Google Cloud-VM oder einer im Internet routingfähigen IP-Adresse eines Systems zugeordnet ist, das eine Verbindung zum Load-Balancer herstellt.
- Ziel: die IP-Adresse der Weiterleitungsregel des Load-Balancers
Da es sich beim Load-Balancer um einen Pass-Through-Load-Balancer (nicht um einen Proxy) handelt, kommen Pakete an, die die Ziel-IP-Adresse der Weiterleitungsregel des Load-Balancers enthalten. Software, die auf Backend-VMs ausgeführt wird, sollte so konfiguriert werden, dass sie Folgendes tut:
- IP-Adresse der Weiterleitungsregel des Load-Balancers oder eine beliebige IP-Adresse (
0.0.0.0oder::) überwachen und sich daran binden - Wenn das Protokoll der Weiterleitungsregel des Load-Balancers Ports unterstützt: Einen Port (binden) überwachen, der in der Weiterleitungsregel des Load-Balancers enthalten ist
Rückgabepakete werden direkt von den Backend-VMs des Load-Balancers an den Client gesendet. Die Quell- und Ziel-IP-Adressen des Rückgabepakets hängen vom Protokoll ab:
- TCP ist verbindungsorientiert, sodass Backend-VMs mit Paketen antworten müssen, deren Quell-IP-Adressen mit der IP-Adresse der Weiterleitungsregel übereinstimmen, sodass der Client die Antwortpakete der entsprechenden TCP-Verbindung zuordnen kann.
- UDP ist verbindungslos, sodass Backend-VMs Antwortpakete senden können, deren Quell-IP-Adressen entweder mit der IP-Adresse der Weiterleitungsregel oder mit einer beliebigen zugewiesenen IP-Adresse für die VM übereinstimmen. Im Prinzip erwarten die meisten Clients, dass die Antwort von derselben IP-Adresse kommt, an die sie Pakete gesendet haben.
In der folgenden Tabelle werden die Quellen und Ziele für Antwortpakete zusammengefasst:
| Traffictyp | Quelle | Ziel |
|---|---|---|
| TCP | Die IP-Adresse der Weiterleitungsregel des Load-Balancers | Die Quelle des anfragenden Pakets |
| UDP | In den meisten Anwendungsfällen die IP-Adresse der Weiterleitungsregel des Load-Balancers † | Die Quelle des anfragenden Pakets |
† Wenn eine VM eine externe IP-Adresse hat oder wenn Sie Cloud NAT verwenden, ist es auch möglich, die Quell-IP-Adresse des Antwortpakets auf die primäre interne IPv4-Adresse der VM-NIC festzulegen. Google Cloud oder Cloud NAT ändert die Quell-IP-Adresse des Antwortpakets entweder in die externe IPv4-Adresse der NIC oder in eine externe Cloud NAT-IPv4-Adresse, um das Antwortpaket an die externe IP-Adresse des Clients zu senden. Nicht die IP-Adresse der Weiterleitungsregel als Quelle zu verwenden, ist ein erweitertes Szenario, da der Client ein Antwortpaket von einer externen IP-Adresse empfängt, die nicht mit der IP-Adresse übereinstimmt, an die ein Anfragepaket gesendet wurde.
Return-Path
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.
Architektur einer freigegebenen VPC
In der folgenden Tabelle sind die Komponenten einer freigegebenen VPC für externe Passthrough-Netzwerk-Load-Balancer 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. |
Traffic-Verteilung
Wie ein Zielpool-basierter externer Passthrough-Netzwerk-Load-Balancer neue Verbindungen verteilt, hängt davon ab, wie die Sitzungsaffinität konfiguriert wurde.
Sitzungsaffinität
Die Sitzungsaffinität steuert die Hash-Methode, die zum Verteilen neuer Verbindungen von Clients zu den Backend-VMs des Load-Balancers verwendet wird. Zielpool-basierte Load-Balancer verwenden den Parameter sessionAffinity, um die Sitzungsaffinität zu konfigurieren.
Weitere Informationen finden Sie 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 können die beteiligten Netzwerke mit der Weiterleitung auf das Eintreffen aller Fragmente warten, 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
NONE,CLIENT_IP_PROTOoderCLIENT_IP.- Wenn Sie die Sitzungsaffinität auf
NONEsetzen, bedeutet dies, dass die Aufrechterhaltung der Affinität nicht erforderlich ist. Daher verwendet der Load-Balancer einen 5-Tupel-Hash, um ein Backend für nicht fragmentierte Pakete auszuwählen, jedoch einen 3-Tupel-Hash für fragmentierte Pakete. - Wenn Sie die Sitzungsaffinität auf
CLIENT_IP_PROTOoderCLIENT_IPsetzen, werden die Quell- und Zielports nicht für das Hashing verwendet. Daher wird derselbe Hash-Wert sowohl für fragmentierte als auch für nicht fragmentierte Pakete berechnet.
- Wenn Sie die Sitzungsaffinität auf
- 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.
Zielinstanzen als Back-Ends verwenden
Wenn Sie Zielinstanzen als Back-Ends für den externen Passthrough-Netzwerk-Load-Balancer verwenden und fragmentierte UDP-Datenpakete erwarten, verwenden Sie nur eine UDP-Weiterleitungsregel pro IP-Adresse mit Load-Balancing und konfigurieren Sie die Weiterleitungsregel, um Traffic an allen Ports 0 bis 65535 zuzulassen. Dadurch wird gewährleistet, dass alle Fragmente zur selben Weiterleitungsregel gelangen, auch wenn sie nicht denselben Zielport haben.
Beschränkungen
- Sie können die Google Cloud Console nicht verwenden, um zielpoolbasierte externe Passthrough-Network-Load-Balancer zu erstellen. Verwenden Sie stattdessen entweder gcloud oder die REST API.
- Externe Passthrough-Network-Load-Balancer unterstützen kein VPC-Netzwerk-Peering.
Nächste Schritte
- Google Cloud Armor unterstützt den erweiterten DDoS-Netzwerkschutz für externe Passthrough-Netzwerk-Load-Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.
- Informationen zum Konfigurieren eines externen Passthrough-Netzwerk-Load-Balancers und zum Verteilen von Traffic auf mehrere Apache-Instanzen finden Sie unter Externen Passthrough-Netzwerk-Load-Balancer mit Zielpools einrichten.
- To learn how external passthrough Network Load Balancers work with regional backend services instead of target pools, see: