Übersicht über externen Proxy-Network-Load-Balancer

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie einen externen Network Load Balancer von Google Cloud konfigurieren möchten.

Der externe Proxy-Network-Load-Balancer ist ein Reverse-Proxy-Load-Balancer, der TCP-Traffic aus dem Internet auf VM-Instanzen in Ihrem Google Cloud Virtual Private Cloud-Netzwerk (VPC) verteilt. Bei Verwendung eines externen Proxy-Network-Load-Balancers wird eingehender TCP- oder SSL -Traffic am Load Balancer beendet. Eine neue Verbindung leitet den Traffic dann über TCP oder SSL (empfohlen) an das nächstgelegene verfügbare Backendweiter. Weitere Anwendungsfälle finden Sie unter Proxy-Network Load Balancer – Übersicht.

Mit externen Network Load Balancern können Sie eine einzelne IP-Adresse für alle Nutzer auf der ganzen Welt verwenden. Der Load Balancer leitet den Traffic automatisch an die Back-Ends weiter, die dem Nutzer am nächsten sind.

Im folgenden Beispiel wird der SSL-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.

Cloud Load Balancing mit SSL-Beendigung (zum Vergrößern klicken).

Hinweis: Obwohl externe Proxy-Network Load Balancer HTTPS-Traffic unterstützen können, sollten Sie stattdessen einen externen Application Load Balancer für HTTPS-Traffic verwenden. Externe Application Load Balancer unterstützen eine Reihe von HTTP-spezifischen Features, einschließlich des Routings anhand des HTTP-Anfragepfads und des Balancings nach Anfragerate. Weitere Informationen finden Sie in der Übersicht über externen Application Load Balancer.

Betriebsarten

Sie können einen externen Proxy-Network-Load-Balancer in den folgenden Modi konfigurieren:

• Ein klassischer Proxy-Network Load Balancer ist auf global verteilten Google Front Ends (GFEs) implementiert. Dieser Load Balancer kann so konfiguriert werden, dass er entweder TCP- oder SSL-Traffic mithilfe eines Ziel-TCP-Proxys oder eines Ziel-SSL-Proxys verarbeitet. Auf der Premium-Stufe kann dieser Load Balancer als globaler Load-Balancing-Dienst konfiguriert werden. In der Standardstufe ist dieser Load Balancer als regionaler Load-Balancing-Dienst konfiguriert. Klassische Proxy-Network Load Balancer können auch für andere Protokolle verwendet werden, die SSL verwenden, z. B. WebSockets und IMAP über SSL.
• Ein globaler externer Proxy-Network Load Balancer wird auf global verteilten GFEs implementiert und unterstützt Möglichkeiten der erweiterten Trafficverwaltung. Dieser Load Balancer kann so konfiguriert werden, dass er entweder TCP- oder SSL-Traffic mithilfe eines Ziel-TCP-Proxys oder eines Ziel-SSL-Proxys verarbeitet. Dieser Load Balancer ist als globaler Load Balancing-Dienst mit der Premiumstufe konfiguriert. Globale externe Proxy-Network Load Balancer können auch für andere Protokolle verwendet werden, die SSL verwenden, z. B. WebSockets und IMAP über SSL.
• Ein regionaler externer Proxy-Network-Load-Balancer ist im Open-Source-Softwarestack Envoy implementiert. Er kann nur TCP-Traffic verarbeiten. Dieser Load Balancer ist als regionaler Load Balancing-Dienst konfiguriert, der entweder die Premium- oder die Standardstufe verwenden kann.

Modus bestimmen

Führen Sie die folgenden Schritte aus, um den Modus eines Load Balancers zu bestimmen.

Console

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

   Load-Balancing aufrufen

2. Auf dem Tab Load-Balancer werden der Typ, das Protokoll und die Region des Load-Balancers angezeigt. Wenn die Region leer ist, ist der Load-Balancer global.

   In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

   Load-Balancer-Modus	Load Balancer-Typ	Zugriffstyp	Region
   Klassischer Proxy-Network Load Balancer	Netzwerk (Proxy, klassisch)	Extern
   Globaler externer Proxy-Network Load Balancer	Netzwerk (Proxy)	Extern
   Regionaler externer Proxy-Network Load Balancer	Netzwerk (Proxy)	Extern	Gibt eine Region an

gcloud

1. Führen Sie den Befehl gcloud compute forwarding-rules describe aus:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

2. Prüfen Sie in der Befehlsausgabe das Load-Balancing-Schema, die Region und die Netzwerkstufe. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

   Load-Balancer-Modus	Load-Balancing-Schema	Weiterleitungsregel	Netzwerkstufe
   Klassischer Proxy-Network Load Balancer	EXTERN	Global	Standard oder Premium
   Globaler externer Proxy-Network Load Balancer	EXTERNAL_MANAGED	Global	Premium
   Regionaler externer Proxy-Network Load Balancer	EXTERNAL_MANAGED	Regional	Standard oder Premium

Wichtig: Nachdem Sie einen Load-Balancer erstellt haben, können Sie seinen Modus nicht mehr bearbeiten. Stattdessen müssen Sie den Load-Balancer löschen und einen neuen erstellen.

Architektur

Die folgenden Diagramme zeigen die Komponenten externer Proxy-Network Load Balancer.

Global

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines globalen externen Proxy-Network Load Balancers. Diese Architektur gilt sowohl für den globalen externen Proxy-Network Load Balancer als auch für den klassischen Proxy-Network Load Balancer in der Premium-Stufe.

Komponenten des globalen externen Proxy-Network Load Balancers (zum Vergrößern klicken).

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen Proxy-Network-Load-Balancers.

Komponenten des regionalen internen Proxy-Network Load Balancers (zum Vergrößern klicken).

Die folgenden Komponenten gehören zu externen Network Load Balancern.

Nur-Proxy-Subnetz

Hinweis: Nur-Proxy-Subnetze sind nur für regionale externe Proxy-Network-Load-Balancer erforderlich.

Das Nur-Proxy-Subnetz stellt eine Reihe von IP-Adressen bereit, die Google zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in derselben Region und demselben VPC-Netzwerk teilen einen Pool von Envoy-Proxys aus demselben Nur-Proxy-Subnetz.

Backend-VMs bzw. Endpunkte aller Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.

Zu berücksichtigende Punkte:

• Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
• Die IP-Adresse des Load-Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load Balancers wird durch seine extern verwaltete Weiterleitungsregel definiert.

Weiterleitungsregeln und IP-Adressen

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy und einem Backend-Dienst besteht.

IP-Adressspezifikation Jede Weiterleitungsregel verweist auf eine einzelne IP-Adresse bereit, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Sie können entweder eine statische IP-Adresse reservieren, die Sie verwenden können, oder Cloud Load Balancing eine Adresse für Sie zuweisen lassen. Wir empfehlen, eine statische IP-Adresse zu reservieren. Andernfalls müssen Sie den DNS-Eintrag jedes Mal, wenn Sie eine Weiterleitungsregel löschen und eine neue erstellen, mit der neu zugewiesenen sitzungsspezifischen IP-Adresse aktualisieren.

Portspezifikation Externe Weiterleitungsregeln, die in der Definition dieses Load Balancers verwendet werden, können auf genau einen Port von 1–65535 verweisen. Wenn Sie mehrere aufeinanderfolgende Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Mehrere Weiterleitungsregeln können mit derselben virtuellen IP-Adresse und verschiedenen Ports konfiguriert werden. So können Sie mehrere Anwendungen mit separaten benutzerdefinierten Ports an dieselbe virtuelle IP-Adresse des TCP-Proxys per Proxy weiterleiten. Weitere Informationen finden Sie unter Portspezifikationen für Weiterleitungsregeln.

Damit mehrere aufeinanderfolgende Ports unterstützt werden, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Mehrere Weiterleitungsregeln können mit derselben virtuellen IP-Adresse und unterschiedlichen Ports konfiguriert werden. So können Sie mehrere Anwendungen mit separaten benutzerdefinierten Ports an dieselbe virtuelle IP-Adresse des TCP-Proxys per Proxy weiterleiten.

In der folgenden Tabelle sind die Anforderungen an Weiterleitungsregeln für externe Proxy-Network Load Balancer aufgeführt.

Load-Balancer-Modus	Netzwerkdienststufe	Weiterleitungsregel, IP-Adresse und Load-Balancing-Schema	Routing aus dem Internet zum Frontend des Load-Balancers
Klassischer Proxy-Network Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load-Balancing-Schema: EXTERNAL	Anfragen, die an die GFEs weitergeleitet werden, die dem Client im Internet am nächsten sind.
	Standard-Stufe	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load-Balancing-Schema: EXTERNAL	Anfragen, die an ein GFE in der Region des Load-Balancers weitergeleitet werden
Globaler externer Proxy-Network Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen, die an die GFEs weitergeleitet werden, die dem Client im Internet am nächsten sind.
Regionaler externer Proxy-Network Load Balancer	Premium-und Standard -Stufe ^*	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen, die an die Envoy-Proxys in derselben Region wie der Load-Balancer weitergeleitet werden.

^* Sie können die Google Cloud Console nicht verwenden, um einen regionalen externen Proxy Network Load Balancer in der Premium-Stufe zu erstellen. Darüber hinaus sind für diese Load Balancer in der Google Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie stattdessen gcloud oder API.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von externen Application Load Balancern verwendet werden, mit VPC-Netzwerken verknüpft werden.

Load-Balancer-Modus	VPC-Netzwerkverknüpfung
Globaler externer Proxy-Network Load Balancer Klassischer Proxy-Network Load Balancer	Kein verknüpftes VPC-Netzwerk. Die Weiterleitungsregel verwendet immer eine IP-Adresse, die sich außerhalb des VPC-Netzwerks befindet. Daher ist der Weiterleitungsregel kein VPC-Netzwerk zugewiesen.
Regionaler externer Proxy-Network Load Balancer	Das VPC-Netzwerk der Weiterleitungsregel ist das Netzwerk, in dem das Nur-Proxy-Subnetz erstellt wurde. Sie geben das Netzwerk an, wenn Sie die Weiterleitungsregel erstellen.

Zielproxys

Externe Proxy-Network-Load-Balancer beenden Verbindungen vom Client und erstellen neue Verbindungen zu den Back-Ends. Der Zielproxy leitet diese neuen Verbindungen an den Backend-Dienst weiter.

Je nach der Art des Traffics, den Ihre Anwendung verarbeiten muss, können Sie einen externen Proxy-Network-Load-Balancer entweder mit einem Ziel-TCP-Proxy oder einem Ziel-SSL-Proxy konfigurieren.

• Ziel-TCP-Proxy: Konfigurieren Sie den Load Balancer mit einem Ziel-TCP-Proxy, wenn Sie TCP-Traffic erwarten.
• Ziel-SSL-Proxy: Konfigurieren Sie den Load Balancer mit einem Ziel-SSL-Proxy, wenn Sie einen verschlüsselten Clienttraffic erwarten. Diese Art von Load Balancer ist nur für Nicht-HTTP(S)-Traffic gedacht. Für HTTP(S)-Traffic wird die Verwendung eines externen Application Load Balancers empfohlen.

Standardmäßig behält der Zielproxy die ursprüngliche IP-Adresse und die Portinformationen des Clients nicht bei. Sie können diese Informationen jedoch mithilfe des Proxy-Protokolls für den Zielproxy aufbewahren.

In der folgenden Tabelle sind die Anforderungen an den Zielproxy für externe Proxy-Network Load Balancer aufgeführt.

Load-Balancer-Modus	Netzwerkdienststufe	Zielproxy
Klassischer Proxy-Network Load Balancer	Premium-Stufe	targetTcpProxies oder targetSslProxies
	Standard-Stufe	targetTcpProxies oder targetSslProxies
Globaler externer Proxy-Network Load Balancer	Premium-Stufe	targetTcpProxies oder targetSslProxies
Regionaler externer Proxy-Network Load Balancer	Premium- und Standardstufe	regionTargetTcpProxies

SSL-Zertifikate

SSL-Zertifikate sind nur erforderlich, wenn Sie einen globalen externen Proxy-Network Load Balancer und einen klassischen Proxy-Network Load Balancer mit einem Ziel-SSL-Proxy bereitstellen.

Externe Proxy-Network-Load-Balancer, die SSL-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate:

• Google Cloud bietet zwei Konfigurationsmethoden zum Zuweisen privater Schlüssel und SSL-Zertifikate zu SSL-Zielproxys: Compute Engine-SSL-Zertifikate und Certificate Manager. Eine Beschreibung der einzelnen Konfigurationen finden Sie unter Methoden der Zertifikatskonfiguration in der Übersicht zu SSL-Zertifikaten.

• Google Cloud bietet zwei Zertifikatstypen: selbstverwaltet und von Google verwaltet. Eine Beschreibung der einzelnen Typen finden Sie unter Zertifikat-Typen in der Übersicht zu SSL-Zertifikaten.

Backend-Dienste

Backend-Dienste leiten eingehenden Traffic an ein oder mehrere verknüpfte Backends weiter. Jedes Backend besteht aus einer Instanzgruppe oder einer Netzwerk-Endpunktgruppe und Informationen zur Bereitstellungskapazität des Backends. Die Serving-Kapazität für das Backend kann auf der CPU oder auf Anfragen pro Sekunde (RPS) basieren.

Jeder Load Balancer hat eine einzelne Backend-Dienstressource, die die Systemdiagnose angibt, die für die verfügbaren Backends ausgeführt werden soll.

Änderungen am Backend-Dienst erfolgen nicht sofort. Es kann einige Minuten dauern, bis Änderungen an GFEs übernommen werden. Sie vermeiden Unterbrechungen für Ihre Nutzer weitgehend, wenn Sie den Verbindungsausgleich bei Backend-Diensten aktivieren. Unterbrechungen dieser Art können auftreten, wenn ein Back-End beendet, manuell entfernt oder durch Autoscaling entfernt wird. Weitere Informationen zum Vermeiden von Dienstunterbrechungen mithilfe des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

Weitere Informationen zur Backend-Dienstressource finden Sie unter Backend-Dienste – Übersicht.

In der folgenden Tabelle sind die verschiedenen Back-Ends aufgeführt, die vom Backend-Dienst externer Proxy-Network Load Balancer unterstützt werden.

Load-Balancer-Modus	Unterstützte Backends in einem Backend-Dienst
	Instanzgruppen	Zonale NEGs	Internet-NEGs	Serverlose NEGs	Hybrid-NEGs	Private Service Connect-NEGs	GKE
Klassischer Proxy-Network Load Balancer		Eigenständige zonale NEGs verwenden
Globaler externer Proxy-Network Load Balancer	^*	Endpunkte des Typs GCE_VM_IP_PORT^*
Regionaler externer Proxy-Network Load Balancer		Endpunkte des Typs GCE_VM_IP_PORT	Nur regionale NEGs			Private Service Connect-NEG hinzufügen

^* Globale externe Proxy-Network Load Balancer unterstützen IPv4- und IPv6-Instanzgruppen (Dual-Stack) und zonale NEG-Back-Ends mit GCE_VM_IP_PORT Endpunkten.

Back-Ends und VPC-Netzwerke

Die Einschränkungen, wo sich Back-Ends befinden können, hängen vom Typ des Load-Balancers ab.

Für den globalen externen Proxy-Network Load Balancer und den klassischen Proxy-Network Load Balancer müssen sich alle Backend-Instanzen von Instanzgruppen-Backends und alle Backend-Endpunkte von NEG-Backends im selben Projekt befinden. Ein Instanzgruppen-Backend oder eine NEG können jedoch ein anderes VPC-Netzwerk in diesem Projekt verwenden. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFEs direkt mit Backends in ihren jeweiligen VPC-Netzwerken kommunizieren.

Beim regionalen externen Proxy-Network Load Balancer hängt dies vom Backend-Typ ab.

• Bei Instanzgruppen, zonalen NEGs und NEGs mit Hybrid-Konnektivität müssen sich alle Back-Ends im selben Projekt und in derselben Region wie der Back-End-Dienst befinden. Ein Load Balancer kann jedoch auf ein Backend verweisen, das ein anderes VPC-Netzwerk im selben Projekt wie der Backend-Dienst verwendet. Diese Funktion befindet sich in der Vorabversion. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder ein Network Connectivity Center-Framework konfiguriert werden.

  Definition des Backend-Netzwerks

  • Bei zonalen und hybriden NEGs geben Sie das VPC-Netzwerk beim Erstellen der NEG explizit an.
  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so eingestellt, dass es mit dem VPC-Netzwerk der Schnittstelle nic0 für die erste VM übereinstimmt, die der Instanzgruppe hinzugefügt wird.

  Anforderungen an das Backend-Netzwerk

  Das Netzwerk deines Backends muss eine der folgenden Netzwerkanforderungen erfüllen:

  • Das VPC-Netzwerk des Back-Ends muss genau mit dem VPC-Netzwerk der Weiterleitungsregel übereinstimmen.

  • Das VPC-Netzwerk des Backends muss über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der Weiterleitungsregel verbunden sein. Sie müssen den Austausch von Subnetzrouten so konfigurieren, dass die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den von den Backend-Instanzen oder Endpunkten verwendeten Subnetzen zugelassen wird.

  • Sowohl das VPC-Netzwerk des Backends als auch das VPC-Netzwerk der Weiterleitungsregel müssen VPC-Spokes auf demselben Network Connectivity Center-Hub sein. Import- und Exportfilter müssen die Kommunikation zwischen dem Nur-Proxysubnetz im VPC-Netzwerk der Weiterleitungsregel und den von Backend-Instanzen oder Endpunkten verwendeten Subnetzen zulassen.
  • Bei allen anderen Backend-Typen müssen sich alle Backends im selben VPC-Netzwerk und in derselben Region befinden.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an verschiedene NICs senden möchten, verwenden Sie stattdessen NEG-Back-Ends.

Wenn Sie zonale NEG-Backends verwenden, werden Pakete an die Netzwerkschnittstelle gesendet, die durch den Endpunkt in der NEG dargestellt wird. Die NEG-Endpunkte müssen sich im selben VPC-Netzwerk wie das explizit definierte VPC-Netzwerk der NEG befinden.

Protokoll für die Kommunikation mit den Back-Ends

Wenn Sie einen Backend-Dienst für einen externen Network Load Balancer konfigurieren, legen Sie das Protokoll fest, über das der Backend-Dienst mit den Backends kommuniziert.

• Für klassische Proxy-Network Load Balancer können Sie entweder TCP oder SSL auswählen.
• Für globale externe Proxy-Network-Load-Balancer können Sie entweder TCP oder SSL auswählen.
• Für regionale externe Proxy-Network-Load-Balancer können Sie TCP verwenden.

Der Load Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln.

Firewallregeln

Die folgenden Firewallregeln sind erforderlich:

• Für klassische Proxy-Network Load Balancer eine allow-Firewallregel für eingehenden Traffic, um Traffic von GFEs zuzulassen, um Ihre Back-Ends zu erreichen.

• Für globale externe Proxy-Network-Load-Balancer ist eine allow-Firewallregel für eingehenden Traffic, um Traffic von GFEs zuzulassen, um Ihre Back-Ends zu erreichen.

• Bei regionalen externen Proxy-Network-Load-Balancern ist eine Firewallregel für eingehenden Traffic erforderlich, um Traffic aus dem Nur-Proxy-Subnetz zu Ihren Back-Ends zuzulassen.

• Eine allow-Firewallregel für eingehenden Traffic, um Traffic von den Systemdiagnoseprüfungen zuzulassen, um Ihre Backends zu erreichen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxysebene implementiert. Sie können keine Firewallregeln verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht.

Die Ports für diese Firewallregeln müssen so konfiguriert werden:

• Lassen Sie Traffic zum Zielport für die Systemdiagnose der einzelnen Backend-Dienste zu.
• Instanzgruppen-Backends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Backend-Dienstes und den mit diesem benannten Port verknüpften Portnummern in jeder Instanzgruppe konfiguriert werden sollen. Die Portnummern können je nach Instanzgruppe, die demselben Backend-Dienst zugewiesen ist, variieren.
• Für zonale GCE_VM_IP_PORT NEG-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

In der folgenden Tabelle sind die erforderlichen Quell-IP-Adressbereiche für die Firewallregeln zusammengefasst.

Load-Balancer-Modus	Quellbereiche für Systemdiagnosen	Quellbereiche anfragen
Globaler externer Proxy-Network Load Balancer	35.191.0.0/16 130.211.0.0/22 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:b029::/64	Die Quelle des GFE traffic hängt vom backend type ab: Instanzgruppen und zonale NEGs (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:1::/64
Klassischer Proxy-Network Load Balancer	35.191.0.0/16 130.211.0.0/22	Diese Bereiche gelten für Systemdiagnoseprüfungen und Anfragen vom GFE.
Regionaler externer Proxy-Network Load Balancer ^*, †	35.191.0.0/16 130.211.0.0/22 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:b029::/64	Diese Bereiche gelten für Systemdiagnoseprüfungen.

^*Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.

^†Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuelle oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT für ausgehenden Traffic verwenden.

Wichtig: Achten Sie darauf, dass Pakete aus den vollständigen Systemdiagnosebereichen zulässig sind. Wenn Ihre Firewallregel nur Pakete aus einem Teil der Bereiche zulässt, können Systemdiagnosen fehlschlagen, weil der Load-Balancer nicht mit Ihren Back-Ends kommunizieren kann. Dies führt zu Zeitüberschreitungen bei der Verbindung.

Quell-IP-Adressen

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei TCP-Verbindungen.

Für die klassischen Proxy-Network Load Balancer und globalen externen Proxy-Network Load Balancer:

• Verbindung 1 vom ursprünglichen Client zum Load-Balancer (GFE):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Endpunkt:

  • Quell-IP-Adresse: IP-Adresse aus einem der unter Firewallregeln angegebenen Bereiche

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Für die regionalen externen Proxy-Network-Load-Balancer:

• Verbindung 1, vom ursprünglichen Client zum Load-Balancer (Nur-Proxy-Subnetz):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2, vom Load-Balancer (Nur-Proxy-Subnetz) zur Backend-VM oder zum Endpunkt:

  • Quell-IP-Adresse: eine IP-Adresse im Nur-Proxy-Subnetz, die von allen Envoy-basierten Load-Balancern gemeinsam verwendet wird, die in derselben Region und im selben Netzwerk wie der Load-Balancer bereitgestellt werden.

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Offene Ports

Externe Proxy-Network-Load-Balancer sind Reverse-Proxy-Load-Balancer. Der Load-Balancer beendet eingehende Verbindungen und öffnet dann neue Verbindungen vom Load-Balancer zu den Back-Ends. Diese Load Balancer werden mit Google Front End-Proxys (GFE) weltweit implementiert.

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Wenn Sie einen Portscan ausführen, werden möglicherweise andere offene Ports für andere Google-Dienste angezeigt, die auf GFEs ausgeführt werden.

Aus folgenden Gründen ist die Ausführung eines Portscans für die IP-Adresse eines GFE-basierten Load-Balancers aus Sicht der Prüfung nicht hilfreich:

• Ein Portscan (z. B. mit nmap) erwartet beim Ausführen von TCP-SYN-Tests normalerweise kein Antwortpaket oder ein TCP-RST-Paket. GFEs senden SYN-ACK-Pakete als Antwort auf SYN-Prüfungen nur für Ports, auf denen Sie eine Weiterleitungsregel konfiguriert haben. GFEs senden jedoch nur Pakete an Ihre Backends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an eine andere IP-Adresse oder einen anderen Port gesendet werden, werden nicht an Ihre Backends gesendet.

  GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Mit Google Cloud Armor Standard bieten GFEs immer aktiven Schutz vor volumetrischen und protokollbasierten DDoS-Angriffen und SYN-Floods. Dieser Schutz ist auch dann verfügbar, wenn Sie Google Cloud Armor nicht explizit konfiguriert haben. Ihnen werden nur dann Gebühren in Rechnung gestellt, wenn Sie Sicherheitsrichtlinien konfigurieren oder sich für Managed Protection Plus registrieren.

• Pakete, die an die IP-Adresse Ihres Load-Balancers gesendet werden, können von jedem GFE in der Google-Flotte beantwortet werden. Wird jedoch eine Kombination aus IP-Adresse und Zielport eines Load-Balancers gescannt, wird nur ein einziges GFE pro TCP-Verbindung abgefragt. Die IP-Adresse des Load-Balancers wird keinem einzelnen Gerät oder System zugewiesen. Wenn also die IP-Adresse eines GFE-basierten Load-Balancers gescannt wird, werden nicht alle GFEs in der Flotte von Google gescannt.

Daher können Sie die Sicherheit Ihrer Back-End-Instanzen am besten mit folgenden Methoden prüfen:

• Ein Sicherheitsprüfer sollte die Konfiguration der Weiterleitungsregeln für die Konfiguration des Load-Balancers prüfen. Die Weiterleitungsregeln definieren den Zielport, für den Ihr Load-Balancer Pakete akzeptiert und an die Back-Ends weiterleitet. Bei GFE-basierten Load-Balancern kann jede externe Weiterleitungsregel nur auf einen einzelnen TCP-Zielport verweisen.

• Ein Sicherheitsprüfer sollte die Konfiguration der Firewallregel für Back-End-VMs prüfen. Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Backend-VMs, aber nicht den eingehenden Traffic zu den GFEs. Best Practices finden Sie im Abschnitt Firewallregeln.

Architektur einer freigegebenen VPC

Regionale externe Proxy-Network Load Balancer und klassische Proxy-Network Load Balancer unterstützen Bereitstellungen, die freigegebene VPC-Netzwerke nutzen. Mit einer freigegebenen VPC können Sie die Zuständigkeiten zwischen Netzwerkadministratoren und Dienstentwicklern klar trennen. Ihre Entwicklungsteams können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren und die Netzwerkinfrastrukturteams das Load-Balancing bereitstellen und verwalten. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

IP-Adresse	Weiterleitungsregel	Zielproxy	Backend-Komponenten
Eine externe IP-Adresse muss im selben Projekt wie der Load-Balancer definiert werden.	Die externe Weiterleitungsregel muss im selben Projekt wie die Backend-Instanzen (dem Dienstprojekt) definiert werden.	Der Ziel-TCP- oder ‑SSL-Proxy muss im selben Projekt wie die Backend-Instanzen definiert werden.	Für klassische Proxy-Network Load Balancer muss ein globaler Backend-Dienst im selben Projekt wie die Backend-Instanzen definiert werden. Diese Instanzen müssen sich in Instanzgruppen befinden, die als Backends an den Backend-Dienst angehängt wurden. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen im selben Projekt wie der Backend-Dienst definiert werden. Bei regionalen externen Proxy-Network-Load-Balancern befinden sich die Backend-VMs normalerweise in einem Dienstprojekt. Dort müssen auch der regionale Backend-Dienst und die Systemdiagnose definiert werden.

Hinweis: Globale externe Proxy-Network Load Balancer unterstützen keine Bereitstellungen, die freigegebene VPC-Netzwerke verwenden.

Traffic-Verteilung

Wenn Sie einem Backend-Dienst eine Backend-Instanzgruppe oder NEG hinzufügen, geben Sie einen Load Balancing-Modus an, der eine Methode definiert, mit der die Backend-Last und die Zielkapazität gemessen werden.

Bei externen Proxy-Network-Load-Balancern kann der Balancing-Modus CONNECTION oder UTILIZATION sein:

• Wenn der Load Balancing-Modus CONNECTION ist, wird die Last anhand der Gesamtzahl der Verbindungen verteilt, die das Backend verarbeiten kann.
• Wenn der Load-Balancing-Modus UTILIZATION ist, wird die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt. Dieser Balancing-Modus gilt nur für VM-Instanzgruppen-Backénds.

Die Verteilung des Traffics auf die Back-Ends wird durch den Balancing-Modus des Load Balancers bestimmt.

Klassischer Proxy-Network Load Balancer

Für den klassischen Proxy-Network Load Balancer wird der Balancing-Modus verwendet, um das bevorzugte Backend (Instanzgruppe oder NEG) auszuwählen. Der Traffic wird dann nach dem Round-Robin-Verfahren auf Instanzen oder Endpunkte innerhalb des Back-Ends verteilt.

Verteilung von Verbindungen

Ein klassischer Proxy-Network Load Balancer kann als globaler Load-Balancing-Dienst mit der Premium-Stufe und als regionaler Dienst in der Standardstufe konfiguriert werden.

Der Balancing-Modus und die Auswahl des Ziels bestimmen die Backend-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG, zonalen Instanzgruppe oder Zone einer regionalen Instanzgruppe. Der Traffic wird dann mithilfe einer konsistenten Hashfunktion innerhalb einer Zone verteilt.

Premium-Stufe:

• Sie können nur einen Backend-Dienst haben und der Backend-Dienst kann Backends in mehreren Regionen haben. Für globales Load-Balancing stellen Sie Ihre Back-Ends in mehreren Regionen bereit. Der Load-Balancer leitet den Traffic automatisch an die Region weiter, die dem Nutzer am nächsten ist. Ist eine Region ausgelastet, leitet der Load-Balancer neue Verbindungen automatisch zu einer anderen Region mit freien Kapazitäten um. Bestehende Nutzerverbindungen bleiben aber in der aktuellen Region.

• Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.

• Wenn Sie einen Backend-Dienst mit Backends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Backend-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist.

Standardstufe:

• Google bewirbt die IP-Adresse Ihres Load-Balancers von Points of Presence, die mit der Region der Weiterleitungsregel verknüpft sind. Der Load-Balancer verwendet eine regionale externe IP-Adresse.

• Sie können Backends nur in derselben Region wie die Weiterleitungsregel konfigurieren. Der Load Balancer leitet Anfragen nur an fehlerfreie Back-Ends in dieser einen Region weiter.

Globaler externer Proxy-Network Load Balancer

Beim globalen externen Proxy-Network Load Balancer basiert die Trafficverteilung auf dem Load-Balancing-Modus und der Load-Balancing-Richtlinie für den Ort.

Der Balancing-Modus bestimmt die Gewichtung und den Anteil des Traffics, der an jede Gruppe (Instanzgruppe oder NEG) gesendet wird. Die Load-Balancing-Richtlinie für den Ort (LocalityLbPolicy) bestimmt, wie Load-Balancing auf die Back-Ends innerhalb der Gruppe angewendet wird.

Wenn ein Backend-Dienst Traffic empfängt, leitet er ihn zuerst an ein Backend (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Backends weiter. Nach der Auswahl eines Backends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Backend-Gruppe verteilt.

Hier finden Sie weitere Informationen:

• Balancing-Modus.
• Load-Balancing-Richtlinie für den Ort (Dokumentation für globale Backend Service API)

Verteilung von Verbindungen

Ein globaler externer Proxy-Netzwerk Load Balancer kann als globaler Load Balancing-Dienst mit der Premium-Stufe konfiguriert werden.

Der Balancing-Modus und die Auswahl des Ziels bestimmen die Backend-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG oder zonalen Instanzgruppe. Der Traffic wird dann mithilfe einer konsistenten Hashfunktion innerhalb einer Zone verteilt.

• Sie können nur einen Backend-Dienst haben und der Backend-Dienst kann Backends in mehreren Regionen haben. Für globales Load-Balancing stellen Sie Ihre Back-Ends in mehreren Regionen bereit. Der Load-Balancer leitet den Traffic automatisch an die Region weiter, die dem Nutzer am nächsten ist. Ist eine Region ausgelastet, leitet der Load-Balancer neue Verbindungen automatisch zu einer anderen Region mit freien Kapazitäten um. Bestehende Nutzerverbindungen bleiben aber in der aktuellen Region.

• Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.

• Wenn Sie einen Backend-Dienst mit Backends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Backend-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist.

Regionaler externer Proxy-Network Load Balancer

Bei regionalen externen Proxy-Network-Load-Balancern basiert die Trafficverteilung auf dem Load-Balancing-Modus und der Load-Balancing-Richtlinie für den Ort.

Der Balancing-Modus bestimmt die Gewichtung und den Anteil des Traffics, der an jede Gruppe (Instanzgruppe oder NEG) gesendet werden soll. Die Load-Balancing-Richtlinie für den Ort (LocalityLbPolicy) bestimmt, wie Load-Balancing auf die Back-Ends innerhalb der Gruppe angewendet wird.

Wenn ein Backend-Dienst Traffic empfängt, leitet er ihn zuerst an ein Backend (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Backends weiter. Nach der Auswahl eines Backends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Backend-Gruppe verteilt.

Hier finden Sie weitere Informationen:

• Balancing-Modi
• Load-Balancing-Richtlinie für den Ort (Dokumentation für regionale Backend Service API)

Sitzungsaffinität

Mit Sitzungsaffinität werden alle Anfragen vom selben Client an dasselbe Backend gesendet, wenn das Backend fehlerfrei ist und Kapazität hat.

Externe Proxy-Network Load Balancer bieten die folgenden Arten von Sitzungsaffinität:

• NONE. Es ist keine Sitzungsaffinität für den Load-Balancer festgelegt.
• Client-IP-Affinität: Hiermit werden alle Anfragen von derselben Client-IP-Adresse an dasselbe Backend weitergeleitet.

Failover

Das Failover für externe Proxy-Network Load Balancer funktioniert so:

• Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet.

• Wenn alle Backends innerhalb einer Region fehlerhaft sind, wird der Traffic an fehlerfreie Backends in anderen Regionen verteilt (nur globale und klassische Modi).

• Wenn alle Back-Ends fehlerhaft sind, löscht der Load-Balancer den Traffic.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in Google Kubernetes Engine erstellen, können Sie eigenständige NEGs verwenden, um den Traffic direkt auf Container zu verteilen. Bei eigenständigen NEGs müssen Sie das Service-Objekt erstellen, das die NEG erstellt, und dann die NEG mit dem Backend-Dienst verknüpfen, damit der Load-Balancer eine Verbindung zu den Pods herstellen.

Eine zugehörige Dokumentation finden Sie unter Containernatives Load Balancing über eigenständige zonale NEGs.

Beschränkungen

• Sie können einen regionalen externen Proxy Network Load Balancer in der Premium-Stufe nicht mit der Google Cloud Console erstellen. Darüber hinaus sind für diese Load Balancer in der Google Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie stattdessen die gcloud CLI oder die API.

• Die folgenden Einschränkungen gelten nur für klassische Proxy-Network Load Balancer und den globalen externen Proxy-Network Load Balancer, die mit einem SSL-Zielproxy bereitgestellt werden:

  • Klassische Proxy-Network Load Balancer und globale externe Proxy-Network Load Balancer unterstützen keine auf Clientzertifikaten basierte Authentifizierung, auch als gegenseitige TLS-Authentifizierung bezeichnet.

  • Klassische Proxy-Network Load Balancer und globale externe Proxy-Network Load Balancer unterstützen nur Kleinbuchstaben in Domains in einem Attribut für einen gemeinsamen Namen (CN) oder ein Attribut für einen alternativen Antragstellernamen (SAN) des Zertifikats. Zertifikate mit Großbuchstaben in Domains werden nur zurückgegeben, wenn sie als Primäres Zertifikat im Zielproxy.

Nächste Schritte

• Klassischen Proxy-Network Load Balancer (TCP-Proxy) einrichten.
• Klassischen Proxy-Network Load Balancer (SSL-Proxy) einrichten.
• Globalen externen Proxy-Network Load Balancer (TCP-Proxy) einrichten.
• Globalen externen Proxy-Network Load Balancer (SSL-Proxy) einrichten.

• Regionalen externen Proxy-Network Load Balancer (TCP-Proxy) einrichten.
• Logging und Monitoring für Proxy-Network Load Balancer.

• SSL-Richtlinien verwenden.

• GFE-Standorte.