Passthrough-Netzwerk-Load-Balancer sind regionale Layer-4-Passthrough-Load-Balancer. Diese Load-Balancer verteilen den Traffic zwischen Back-Ends in derselben Region wie der Load-Balancer. Wie der Name verrät, sind Passthrough-Network Load Balancer keine Proxys. Pakete mit Load-Balancing werden von Backend-VMs mit den Quell- und Ziel-IP-Adressen des Pakets, dem Protokoll und den unveränderten Quell- und Zielports angezeigt, wenn das Protokoll portbasiert ist. Verbindungen mit Load Balancing werden bei den Backends beendet. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe (DSR).
Das folgende Diagramm zeigt ein Beispiel für die Architektur eines Netzwerk-Load-Balancers.
In folgenden Fällen sollten Sie einen Passthrough-Network Load Balancer verwenden:
- Sie müssen die ursprünglichen Clientpakete ohne Proxy an die Backends weiterleiten, z. B. wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.
- Sie müssen Load-Balancing für TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-Traffic verwenden oder für einen TCP-Port, der nicht von anderen Load-Balancern unterstützt wird.
- Es ist zulässig, dass SSL-Traffic von Ihren Back-Ends und nicht vom Load-Balancer entschlüsselt wird. Der Passthrough-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.
- Sie können die SSL-Zertifikate der Back-End-VM selbst verwalten. Von Google verwaltete SSL-Zertifikate sind nur für Proxy-Load Balancer verfügbar.
- Sie haben bereits eine Konfiguration, in der ein Passthrough-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.
Passthrough-Network Load Balancer sind in den folgenden Bereitstellungsmodi verfügbar.
| Umfang | Traffictyp | Netzwerkdienststufe | Load-Balancing-Schema † | IP-Adresse | Frontend-Ports | Links | |
|---|---|---|---|---|---|---|---|
| Externer Passthrough-Network Load Balancer
Führt Load-Balancing von Traffic von Clients im Internet aus. |
Regional | TCP, UDP, ESP, GRE, ICMP und ICMPv6 | Premium oder Standard | EXTERN | IPv4 und IPv6 | Einen einzelnen Port, einen Portbereich oder alle Ports | Architekturdetails |
| Interner Passthrough-Network-Load-Balancer
Führt Load-Balancing von Traffic innerhalb Ihres VPC-Netzwerks oder der Netzwerke aus, die mit Ihrem VPC-Netzwerk verbunden sind. |
Regional | TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE | Premium | INTERN | IPv4 und IPv6 | Einen einzelnen Port, einen Portbereich oder alle Ports | Architekturdetails |
† Das Load-Balancing-Schema ist ein Attribut für die Weiterleitungsregel und den Backend-Dienst eines Load-Balancers und gibt an, ob der Load-Balancer für internen oder externen Traffic verwendet werden kann.
Externe Passthrough-Netzwerk-Load-Balancer
Externe Passthrough-Network-Load Balancer sind regionale Layer-4-Load Balancer, die externen Traffic auf Back-Ends (Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs)) in derselben Region wie der Load Balancer verteilen. Diese Back-Ends müssen sich in derselben Region und demselben Projekt befinden, können jedoch in verschiedenen VPC-Netzwerken sein. Diese Load Balancer basieren auf Maglev und dem Andromeda-Netzwerkvirtualisierungs-Stack.
Externe Passthrough-Network Load Balancer können 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
Externe Passthrough-Network Load Balancer sind keine Proxys. Der Load-Balancer selbst beendet Nutzerverbindungen nicht. Pakete mit Load-Balancing werden unverändert an die Backend-VMs mit ihren Quell- und Ziel-IP-Adressen, ihrem Protokoll und gegebenenfalls Ports gesendet. Die Backend-VMs beenden dann Nutzerverbindungen. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Dieser Vorgang wird als direkte Serverrückgabe (DSR, Direct Server Return) bezeichnet.
Das folgende Diagramm zeigt einen externen Passthrough-Network Load Balancer, der in der Region us-central1 mit seinen Back-Ends in derselben Region konfiguriert ist. Der Traffic wird von einem Nutzer in Singapur an den Load Balancer in us-central1 (Weiterleitungsregel-IP-Adresse 120.1.1.1) weitergeleitet.
Wenn sich die IP-Adresse des Load-Balancers in der Premium-Stufe befindet, durchquert der Traffic den hochwertigen globalen Backbone von Google mit der Absicht, dass die Pakete den Edge-Peering-Punkt von Google möglichst nah am Client betreten bzw. verlassen. Wenn sich die IP-Adresse des Load-Balancers in der Standardstufe befindet, betritt und verlässt der Traffic das Google-Netzwerk an einem Peering-Punkt, der derjenigen Google Cloud-Region am nächsten ist, in der der Load-Balancer konfiguriert ist.
Die Architektur eines externen Passthrough-Network Load Balancers hängt davon ab, ob Sie einen Backend-Dienst oder einen Zielpool zum Einrichten des Backends verwenden.
Backend-Dienst-basierte Load-Balancer
Externe Passthrough-Netzwerk-Load-Balancer können mit einem regionalen Backend-Dienst erstellt werden, der das Verhalten des Load-Balancers definiert und wie er den Traffic auf seine Backends verteilt. Backend-Dienst-basierte externe Passthrough-Netzwerk-Load-Balancer unterstützen IPv4- und IPv6-Traffic, mehrere Protokolle (TCP, UDP, ESP, GRE, ICMP und ICMPv6), verwaltete und nicht verwaltete Instanzgruppen-Backends , NEG-Back-Ends (Netzwerk-Endpunktgruppe) mit GCE_VM_IP-Endpunkten, detaillierte Steuerelemente für die Trafficverteilung, Failover-Richtlinien und die Möglichkeit, Nicht-Legacy-Systemdiagnosen zu verwenden, die dem Typ des Traffics entsprechen. (TCP, SSL, HTTP, HTTPS oder HTTP/2), den Sie verteilen.
Das Load-Balancing zu Google Kubernetes Engine (GKE) erfolgt mithilfe des integrierten GKE-Dienstcontrollers. Darüber hinaus werden Back-End-Dienst-basierte externe Passthrough-Network Load Balancer mit App Hub unterstützt, das sich in der Vorschau befindet.
Weitere Informationen zur Architektur und zu den unterstützten Funktionen finden Sie unter Backend-Dienst-basierter externer Passthrough-Netzwerk Load Balancer.
Sie können einen vorhandenen zielpoolbasierten Load-Balancer darauf umstellen, einen Backend-Dienst zu verwenden. Eine Anleitung dazu finden Sie unter Load Balancer von Zielpools zu Back-End-Diensten migrieren.
Zielpoolbasierte Load-Balancer
Ein Zielpool ist das Legacy-Backend, das von externen Passthrough-Network Load Balancern unterstützt wird. Mit einem Zielpool wird eine Gruppe von Instanzen definiert, die eingehenden Traffic vom Load-Balancer empfangen sollen.
Zielpoolbasierte Load-Balancer unterstützen entweder TCP- oder UDP-Traffic. Weiterleitungsregeln für zielpoolbasierte externe Passthrough-Network Load Balancer unterstützen nur externe IPv4-Adressen.
Weitere Informationen finden Sie unter Übersicht über den zielpoolbasierten externen Passthrough-Netzwerk-Load-Balancer.
Interne Passthrough-Network-Load-Balancer
Der interne Passthrough-Netzwerk-Load-Balancer verteilt den Traffic zwischen internen VM-Instanzen in derselben Region in einem VPC-Netzwerk (Virtual Private Cloud). Sie können damit Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren. Zugriff darauf ist nur für Systeme im selben VPC-Netzwerk oder für Systeme verfügbar, die mit Ihrem VPC-Netzwerk verbunden sind.
Diese Load Balancer basieren auf dem Andromeda-Netzwerkvirtualisierungs-Stack. Sie unterstützen nur regionale Back-Ends, sodass Sie Ihren Dienst durch Autoscaling über eine ganze Region hinweg vor zonalen Ausfällen schützen können. Außerdem kann dieser Load-Balancer nur in der Premiumstufe konfiguriert werden.
Die internen Passthrough-Netzwerk-Load-Balancer sind für viele Anwendungsfälle vorgesehen. In den folgenden Abschnitten finden Sie einige allgemeine Beispiele.
Zugriff auf verbundene Netzwerke
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
Ausführliche Beispiele finden Sie unter Interne Passthrough-Netzwerk-Load-Balancer und verbundene Netzwerke.
Dreistufiger Webdienst
Sie können interne Passthrough-Netzwerk-Load-Balancer in Verbindung mit anderen Load-Balancern verwenden. Wenn Sie beispielsweise einen externen Anwendungs-Load-Balancer einbinden, ist der externe Anwendungs-Load-Balancer die Webebene und arbeitet mit Diensten hinter dem internen Passthrough-Netzwerk-Load-Balancer.
Das folgende Diagramm zeigt ein Beispiel für eine dreistufige Konfiguration, die externe Anwendungs-Load-Balancer und interne Passthrough-Netzwerk-Load-Balancer verwendet:
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 einem externen Application Load Balancer verteilt wird
- Eine interne Backend-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-west1ist, die auf die interne Datenbankebene mit Load-Balancing inus-east1zugreift.
Interne Passthrough-Netzwerk-Load-Balancer als nächste Hops verwenden
Sie können einen internen Passthrough-Netzwerk-Load-Balancer als nächstes Gateway verwenden, an das Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Dazu legen Sie den Load-Balancer als nächsten Hop in einer statischen Route fest.
Ein interner Passthrough-Network-Load-Balancer mit nächstem Hop verarbeitet Pakete für den gesamten unterstützten Traffic, unabhängig von den Weiterleitungsregeln und Backend-Dienstprotokollen, die Sie beim Erstellen des Load Balancers angegeben haben.
Bei dieser Funktion können IPv4- oder IPv6-Adressen (Vorabversion) verwendet werden.
Im Folgenden finden Sie eine Beispielarchitektur mit einem internen Passthrough-Netzwerk-Load-Balancer als nächstem Hop zu einem NAT-Gateway. Sie können Traffic an die Back-Ends Ihrer virtuellen Firewall- oder Gateway-Appliance über einen internen Passthrough-Netzwerk-Load-Balancer weiterleiten.
Weitere Anwendungsfälle:
- Hub-and-Spoke – Austauschen von Routen für den nächsten Hop mithilfe von VPC-Netzwerk-Peering: Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances für den nächsten Hop im
hub-VPC-Netzwerk konfigurieren. Routen, die den Load-Balancer als nächsten Hop imhub-VPC-Netzwerk verwenden, können in jedemspoke-Netzwerk verwendet werden. - Load Balancing für mehrere Netzwerkschnittstellen (
nic0bisnic7) auf den Back-End-VMs
Weitere Informationen zu diesen Anwendungsfällen finden Sie unter Interne Passthrough-Netzwerk-Load-Balancer als nächste Hops.
Interne Passthrough-Netzwerk-Load-Balancer und GKE
Weitere Informationen zum Erstellen interner Passthrough-Netzwerk-Load-Balancer für Dienste in GKE finden Sie in der GKE-Dokumentation unter Konzepte des LoadBalancer-Dienstes.
Interne Passthrough-Network Load Balancer und App Hub
Ressourcen, die von internen Passthrough-Network Load Balancern genutzt werden, können in App Hub, das sich in der Vorschau befindet, als Dienste bezeichnet werden.
Portzuordnung für Private Service Connect
Portzuordnungsdienste für Private Service Connect verwenden NEGs für die Portzuordnung und haben eine ähnliche Konfiguration wie interne Passthrough-Network Load Balancer. Portzuordnungsdienste sorgen jedoch nicht für Load Balancing von Traffic. Stattdessen leitet Private Service Connect den Traffic basierend auf dem Client-Zielport, der den Traffic empfängt, an Dienstports auf VMs des Diensterstellers weiter.
Wenn Sie Traffic aus demselben VPC-Netzwerk wie der Dienst an einen Portzuordnungsdienst senden, werden die Pakete verworfen.
Weitere Informationen finden Sie unter Portzuordnung für Private Service Connect.
Nächste Schritte
- Detaillierte Informationen zur Architektur interner Passthrough-Network Load Balancer finden Sie unter Übersicht über die Architektur des internen Passthrough-Netzwerk-Load-Balancers.
- Detaillierte Informationen zur Architektur externer Passthrough-Network Load Balancer finden Sie unter Übersicht über die Architektur externer Passthrough-Network Load Balancer.