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-Netzwerk-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 an den Back-Ends 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 den folgenden Fällen würden Sie einen Passthrough-Network Load Balancer verwenden:
- Sie müssen die ursprünglichen Clientpakete ohne Proxy an die Back-Ends weiterleiten, z. B. wenn die Quell-IP-Adresse des Clients beibehalten werden soll.
- Sie müssen Load-Balancing für TCP-, UDP-, ESP-, GRE-, ICMP- und ICMPv6-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 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 Backend-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-Netzwerk-Load-Balancer sind in den folgenden Bereitstellungsmodi verfügbar.
| Geltungsbereich | Traffic-Typ | Netzwerkdienststufe | Load-Balancing-Schema † | IP-Adresse | Frontend-Ports | Links | |
|---|---|---|---|---|---|---|---|
| Externer Passthrough-Netzwerk-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 | Ein einzelner Port, ein Portbereich oder alle Ports | Architekturdetails |
| Interner Passthrough-Netzwerk-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 | Ein einzelner Port, ein 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 konfiguriert ist, wobei sich seine Back-Ends in derselben Region befinden. 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 zu Architekturdetails und mehr Informationen zu unterstützten Features finden Sie unter Backend-Dienst-basierter externer Passthrough-Network-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 Backend-Diensten migrieren.
Zielpoolbasierte Load-Balancer
Ein Zielpool ist das Legacy-Backend, das von externen Passthrough-Netzwerk-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-Netzwerk-Load-Balancer unterstützen nur externe IPv4-Adressen.
Weitere Informationen finden Sie unter Übersicht über den zielpoolbasierten externen Passthrough-Netzwerk-Load-Balancer.
Interne Passthrough-Netzwerk-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 Virtualisierungsstacks für das Andromeda-Netzwerk. 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 werden einige allgemeine Beispiele aufgeführt.
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.
Dreischichtiger 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 benutzerdefinierten statischen Route fest.
Ein interner Passthrough-Netzwerk-Load-Balancer, der als nächster Hop in einer benutzerdefinierten Route bereitgestellt wird, verarbeitet den gesamten Traffic, unabhängig vom Protokoll (TCP, UDP oder ICMP).
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.
Nächste Schritte
- Ausführliche Architekturinformationen zu internen Passthrough-Network-Load-Balancern finden Sie unter Übersicht über die Architektur des internen Passthrough-Network-Load-Balancers.
- Ausführliche Architekturinformationen zu externen Passthrough-Network-Load-Balancern finden Sie unter Übersicht über die Architektur des externen Passthrough-Network-Load-Balancers.