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- und ICMP-Traffic konfigurieren. Unterstützung für ESP und ICMP befindet sich in der Vorschau.
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.
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.
Umfang
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 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.
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 können für Load-Balancing von TCP-, UDP-, ESP- und ICMP-Traffic verwendet werden.
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.
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: