Proxy-Netzwerk-Load-Balancer sind Layer-4-Reverse-Proxy-Load-Balancer, die TCP-Traffic auf Back-Ends in Ihrem Google Cloud-VPC-Netzwerk (Virtual Private Cloud) oder in anderen Cloud-Umgebungen verteilen. Der Traffic wird auf der Load Balancing-Ebene beendet und dann über TCP an das nächstgelegene verfügbare Backend weitergeleitet.
Proxy-Network-Load-Balancer sind nur für TCP-Traffic mit oder ohne SSL vorgesehen. Für HTTP(S)-Traffic empfehlen wir stattdessen die Verwendung eines Application Load Balancers.
Proxy-Network Load Balancer unterstützen die folgenden Features:
- Unterstützung für alle Ports Diese Load Balancer lassen jeden gültigen Port von 1–65535 zu. Weitere Informationen finden Sie unter Angabe von Ports.
- Neuzuordnung von Ports: Der von der Weiterleitungsregel des Load-Balancers verwendete Port muss nicht mit dem Port übereinstimmen, der beim Herstellen von Verbindungen zu seinen Back-Ends verwendet wird. Beispielsweise kann die Weiterleitungsregel den TCP-Port 80 verwenden, während die Verbindung zu den Back-Ends den TCP-Port 8080 verwenden kann.
- Leitet die ursprüngliche Quell-IP-Adresse weiter. Sie können das PROXY-Protokoll verwenden, um die Quell-IP-Adresse und Portinformationen des Clients an die Load-Balancer-Back-Ends weiterzuleiten.
Das folgende Diagramm zeigt ein Beispiel für eine Proxy-Netzwerk-Load-Balancer-Architektur.
Proxy-Network Load Balancer sind in den folgenden Bereitstellungsmodi verfügbar:
Externer Proxy-Network Load Balancer: Führt Load-Balancing von Traffic von Clients im Internet aus. Weitere Informationen finden Sie unter Architektur des externen Proxy-Network Load Balancers.
Bereitstellungsmodus Netzwerkdienststufe Load-Balancing-Schema † IP-Adresse Frontend-Ports Global extern Premium-Stufe EXTERNAL_MANAGED IPv4
IPv6Kann auf genau einen Port von 1–65535 verweisen Klassisch Global in Premium-Stufe
Regional in der Standardstufe.
EXTERN IPv4
IPv6 (Premium-Stufe erforderlich)Regional, extern Premium- oder Standardstufe EXTERNAL_MANAGED IPv4 Interner Proxy-Network Load Balancer: Führt Load-Balancing von Traffic innerhalb Ihres VPC-Netzwerks oder der Netzwerke aus, die mit Ihrem VPC-Netzwerk verbunden sind. Weitere Informationen zur Architektur finden Sie unter Architektur des internen Proxy-Network Load Balancers.
Bereitstellungsmodus Netzwerkdienststufe Load-Balancing-Schema † IP-Adresse Frontend-Ports Regional intern Premium-Stufe INTERNAL_MANAGED IPv4 Kann auf genau einen Port von 1–65535 verweisen Regionsübergreifend intern Premium-Stufe INTERNAL_MANAGED IPv4
† 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. Der Begriff *_MANAGED im Load-Balancing-Schema gibt an, dass der Load-Balancer als verwalteter Dienst auf Google Front Ends (GFEs) oder dem Open-Source-Envoy-Proxy implementiert wird. In einem Load-Balancing-Schema, das *_MANAGED ist, werden Anfragen entweder an das GFE oder an den Envoy-Proxy weitergeleitet.
Externer Proxy-Network Load Balancer
Der externe Proxy-Network Load Balancer verteilt den aus dem Internet kommenden Traffic auf Back-Ends in Ihrem Google Cloud-VPC-Netzwerk, lokal oder in anderen Cloud-Umgebungen. Diese Load Balancer können in einem der folgenden Modi bereitgestellt werden: global, regional oder klassisch.
Externe Proxy-Network Load Balancer unterstützen die folgenden Features:
- IPv6-Beendigung Die externen Load-Balancer unterstützen sowohl IPv4- als auch IPv6-Adressen für Clienttraffic. IPv6-Anfragen von Clients werden auf der Ebene des Load-Balancings beendet und dann über IPv4 an die Back-Ends weitergeleitet.
- TLS/SSL-Auslagerung. Sie haben die Möglichkeit, einen klassischen Proxy-Network-Load-Balancer zu verwenden, um TLS auf der Load-Balancing-Ebene mithilfe eines SSL-Proxys auszulagern. Neue Verbindungen leiten Traffic entweder über SSL (empfohlen) oder TCP zu den nächstgelegenen verfügbaren Back-Ends weiter.
- Bessere Auslastung von Back-Ends Die SSL-Verarbeitung kann sehr CPU-intensiv sein, wenn die verwendeten Chiffren nicht CPU-effizient sind. Sie können die CPU-Leistung maximieren, indem Sie ECDSA-SSL-Zertifikate sowie TLS 1.2 verwenden und bevorzugt die Cipher Suite
ECDHE-ECDSA-AES128-GCM-SHA256für SSL zwischen dem Load-Balancer und Ihren Backend-Instanzen verwenden. - SSL-Richtlinien Mit SSL-Richtlinien können Sie die Features von SSL steuern, die Ihr Load-Balancer mit Clients aushandelt.
- Bessere Auslastung von Back-Ends Die SSL-Verarbeitung kann sehr CPU-intensiv sein, wenn die verwendeten Chiffren nicht CPU-effizient sind. Sie können die CPU-Leistung maximieren, indem Sie ECDSA-SSL-Zertifikate sowie TLS 1.2 verwenden und bevorzugt die Cipher Suite
- Einbindung in Google Cloud Armor. Sie können die Sicherheitsrichtlinien von Google Cloud Armor verwenden, um Ihre Infrastruktur vor DDoS-Angriffen (Distributed Denial of Service) und anderen gezielten Angriffen zu schützen.
- Beendigung von TLS geografisch steuern Der Load-Balancer beendet TLS an global verteilten Orten, um die Latenz zwischen Clients und dem Load-Balancer zu minimieren. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, können Sie mithilfe der Standard-Netzwerkstufe erzwingen, dass der Load-Balancer TLS auf Back-Ends beendet, die sich nur in einer bestimmten Region befinden. Weitere Informationen finden Sie unter Standardstufe konfigurieren.
- Unterstützung für App Hub. Ressourcen, die von regionalen externen Proxy-Netzwerk-Load-Balancern verwendet werden, können in App Hub als Dienste festgelegt werden. Diese befindet sich in der Vorschau.
Im folgenden Diagramm wird der Traffic von Nutzern in Stadt A und Stadt B auf der Load Balancing-Ebene beendet und es wird eine separate Verbindung zum ausgewählten Backend hergestellt.
Weitere Informationen finden Sie unter Übersicht über den externen Proxy-Netzwerk-Load-Balancer.
Interner Proxy-Network Load Balancer
Der interne Proxy-Netzwerk-Load-Balancer ist ein Envoy-Proxy-basierter regionaler Layer-4-Load-Balancer, mit dem Sie Ihren TCP-Diensttraffic hinter einer internen IP-Adresse ausführen und skalieren können, auf die nur Clients im selben VPC-Netzwerk oder Clients, die mit Ihrem VPC-Netzwerk verbunden sind, Zugriff haben.
Der Load-Balancer verteilt TCP-Traffic an Back-Ends, die in Google Cloud, lokal oder in anderen Cloud-Umgebungen gehostet werden. Diese Load-Balancer können in einem der folgenden Modi bereitgestellt werden: regionenübergreifend oder regional.
Interne Proxy-Network Load Balancer unterstützen die folgenden Features:
- Standortrichtlinien. Innerhalb einer Backend-Instanzgruppe oder Netzwerk-Endpunktgruppe können Sie konfigurieren, wie Anfragen an Mitgliedsinstanzen oder -Endpunkte verteilt werden.
- Globaler Zugriff. Wenn der globale Zugriff aktiviert ist, können Clients aus jeder Region auf den Load Balancer zugreifen.
- Zugriff aus verbundenen Netzwerken. Sie können Ihren internen Load-Balancer für Clients aus Netzwerken über das eigene Google Cloud-VPC-Netzwerk hinaus zugänglich machen. Die anderen Netzwerke müssen über VPC-Netzwerk-Peering, Cloud VPN oder Cloud Interconnect mit dem VPC-Netzwerk des Load Balancers verbunden sein.
- Unterstützung für App Hub. Ressourcen, die von regionalen internen Proxy-Netzwerk-Load-Balancern verwendet werden, können in App Hub als Dienste festgelegt werden. Diese befindet sich in der Vorschau.
Weitere Informationen finden Sie unter Übersicht über den internen Proxy-Netzwerk-Load-Balancer.
Hochverfügbarkeit und regionsübergreifender Failover
Sie können einen regionenübergreifenden internen Proxy-Network Load Balancer in mehreren Regionen einrichten, um folgende Vorteile zu erhalten:
Wenn Back-Ends in einer bestimmten Region ausfallen, wird der Traffic ordnungsgemäß auf die Back-Ends in einer anderen Region umgeleitet.
Das Beispiel für die regionenübergreifende Failover-Bereitstellung zeigt Folgendes:
- Ein regionenübergreifender interner Proxy-Network Load Balancer mit einer Frontend-VIP-Adresse in der Region A Ihres VPC-Netzwerks. Die Kunden befinden sich ebenfalls in der Region A.
- Einen globalen Backend-Dienst, der auf die Backends in der Google Cloud-Region A und B verweist.
- Wenn die Backends in der Region A ausfallen, wird der Traffic auf die Region B umgeleitet.
Netzwerkübergreifender interner Proxy-Network Load Balancer mit regionenübergreifender Failover-Bereitstellung (zum Vergrößern klicken) Regionsübergreifende interne Proxy-Network Load Balancer können Ihre Anwendung auch vor kompletten regionalen Ausfällen schützen, indem sie den Traffic von Proxies und Back-Ends in einer anderen Region an Ihren Client weiterleiten.
Das Bereitstellungsbeispiel für Hochverfügbarkeit zeigt Folgendes:
- Ein regionsübergreifender interner Proxy-Network Load Balancer mit Frontend-VIPs in den Regionen A und B Ihres VPC-Netzwerks. Die Clients befinden sich in der Region A.
Sie können den Load Balancer mithilfe von Frontend-VIPs aus zwei Regionen zugänglich machen.
Netzwerkübergreifender interner Proxy-Network Load Balancer mit Hochverfügbarkeitsbereitstellung (klicken Sie zum Vergrößern).
Informationen zum Einrichten einer Hochverfügbarkeitsbereitstellung finden Sie unter:
- Regionenübergreifenden internen Proxy-Network Load Balancer mit VM-Instanzgruppen-Back-Ends einrichten
- Regionenübergreifenden Proxy-Network Load Balancer mit Hybridkonnektivität einrichten