Externes TCP/UDP-Netzwerk-Load-Balancing von Google Cloud (ab jetzt als Netzwerk-Load-Balancing bezeichnet) ist ein regionaler Pass-Through-Load-Balancer. Ein Netzwerk-Load-Balancer verteilt externen Traffic auf VM-Instanzen in derselben Region.
Sie können einen Netzwerk-Load-Balancer für TCP-, UDP-, ESP-, GRE- ICMP- und ICMPv6-Traffic konfigurieren.
Ein 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
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.
- Netzwerk-Load-Balancer sind keine Proxys.
- Pakete mit Load-Balancing werden von Back-End-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 von den Back-End-VMs beendet.
- 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 (DSR).
Die folgenden Diagramme zeigen einen Netzwerk-Load-Balancer, dessen Weiterleitungsregel die IP-Adresse 120.1.1.1 hat. Der Netzwerk-Load-Balancer wird in der Region us-central1 konfiguriert, wobei sich die Back-Ends in derselben Region befinden.
Netzwerk-Load-Balancer sind regional und unterstützen nur Back-Ends in derselben Region wie ihre konfigurierten Front-Ends. Pakete an Netzwerk-Load-Balancer können jedoch weiterhin von überall aus dem Internet gesendet werden, unabhängig davon, ob sich die IP-Adresse des Load-Balancers in der Premium- oder Standardstufe befindet. 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.
Im folgenden Diagramm wird der Traffic von einem Nutzer in Singapur an den Netzwerk-Load-Balancer in us-central1 (Weiterleitungsregel-IP-Adresse 120.1.1.1) weitergeleitet.
Im folgenden Diagramm wird der Traffic von einem Nutzer in Iowa an den Netzwerk-Load-Balancer in us-central1 (Weiterleitungsregel-IP-Adresse 120.1.1.1) weitergeleitet.
Geltungsbereich
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 Nicht-TCP-Traffic oder für einen TCP-Port verwenden, 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 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 das HTTP(S)-Load-Balancing und das externe SSL-Proxy-Load-Balancing verfügbar.
- Sie müssen die ursprünglichen Pakete ohne Proxy weiterleiten. Zum Beispiel, wenn die Quell-IP-Adresse des Clients erhalten bleiben soll.
- Sie haben bereits eine Konfiguration, in der ein Pass-Through-Load-Balancer verwendet wird, und möchten sie ohne Änderungen migrieren.
- Sie benötigen erweiterten Netzwerk-DDoS-Schutz für Ihren Netzwerk-Load-Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz mit Google Cloud Armor konfigurieren.
Load-Balancing für GKE-Anwendungen
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.
Zugehörige GKE-Dokumentation:
Architektur
Die Architektur eines Netzwerk-Load-Balancers hängt davon ab, ob Sie einen Back-End-Dienst-basierten oder einen zielpoolbasierten Netzwerk-Load-Balancer verwenden.
Back-End-Dienst-basierter Netzwerk-Load-Balancer
Netzwerk-Load-Balancer können mit einem regionalen Back-End-Dienst erstellt werden, der das Verhalten des Load-Balancers definiert und wie er den Traffic auf seine Back-End-Instanzgruppen verteilt. Back-End-Dienste ermöglichen Funktionen, die mit Legacy-Zielpools nicht unterstützt werden, z. B. Unterstützung für Nicht-Legacy-Systemdiagnosen (TCP, SSL, HTTP, HTTPS oder HTTP/2), Autoscaling mit verwalteter Instanzgruppe, Verbindungsausgleich und konfigurierbare Failover-Richtlinien.
Back-End-Dienst-basierte Netzwerk-Load-Balancer unterstützen IPv4- und IPv6-Traffic. Sie können für Load-Balancing von TCP-, UDP-, ESP-, ICMP- und ICMPv6-Traffic sorgen. Sie können auch Quell-IP-basierte Trafficsteuerung verwenden, um Traffic an bestimmte Back-Ends zu leiten.
Informationen zur Architektur finden Sie unter Netzwerk-Load-Balancer mit einem regionalen Back-End-Dienst.
Sie können auch einen vorhandenen auf dem Pool basierenden Netzwerk-Load-Balancer umstellen, um stattdessen einen Back-End-Dienst zu verwenden. Eine Anleitung dazu finden Sie unter Netzwerk-Load-Balancer von Zielpools zu Back-End-Diensten umstellen.
Zielpool-basierter Netzwerk-Load-Balancer
Ein Zielpool ist das Legacy-Back-End, das von Google-Netzwerk-Load-Balancern unterstützt wird. Mit einem Zielpool wird eine Gruppe von Instanzen definiert, die eingehenden Traffic vom Load-Balancer empfangen sollen.
Zielpoolsbasierte Netzwerk-Load-Balancer unterstützen entweder TCP- oder UDP-Traffic. Weiterleitungsregeln für zielpoolbasierte Netzwerk-Load-Balancer unterstützen nur externe IPv4-Adressen.
Weitere Informationen finden Sie unter Netzwerk-Load-Balancer mit Zielpool-Back-End.
Netzwerk-Load-Balancing mit anderen Google Cloud-Load-Balancern vergleichen
Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten: