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-Nutzertraffic am Load Balancer beendet. Eine neue Verbindung leitet den Traffic dann über TCP oder SSL (empfohlen) an das nächstgelegene verfügbare Backend weiter. 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.
In diesem Beispiel wird der SSL-Traffic von Nutzern aus Iowa und Boston auf der Load-Balancing-Ebene terminiert und es wird eine separate Verbindung zum ausgewählten Backend aufgebaut.
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
Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.
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
Führen Sie den Befehl
gcloud compute forwarding-rules describeaus:gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
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
Architektur
Die folgenden Diagramme zeigen die Komponenten globaler und regionaler 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.
Regional
Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen Proxy-Network-Load-Balancers.
Die folgenden Komponenten gehören zu externen Network Load Balancern.
Nur-Proxy-Subnetz
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.
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.
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 unterschiedlichen Ports konfiguriert werden. Daher können Sie mehrere Anwendungen mit separaten benutzerdefinierten Ports an dieselbe virtuelle IP-Adresse des TCP-Proxys 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. Daher können Sie mehrere Anwendungen mit separaten benutzerdefinierten Ports an dieselbe virtuelle IP-Adresse des TCP-Proxys weiterleiten.
In der folgenden Tabelle werden die verschiedenen Arten von Load Balancern verglichen.
| 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 Load-Balancing-Schema: |
Anfragen, die an die GFEs weitergeleitet werden, die dem Client im Internet am nächsten sind. |
| Standard-Stufe | Regionale externe Weiterleitungsregel Load-Balancing-Schema: |
Anfragen, die an ein GFE in der Region des Load-Balancers weitergeleitet werden | |
| Globaler externer Proxy-Network Load Balancer | Premium-Stufe | Globale externe Weiterleitungsregel Load-Balancing-Schema: |
Anfragen, die an die GFEs weitergeleitet werden, die dem Client im Internet am nächsten sind. |
| Regionaler externer Proxy-Network Load Balancer | Premium- und Standardstufe | Regionale externe Weiterleitungsregel Load-Balancing-Schema: |
Anfragen, die an die Envoy-Proxys in derselben Region wie der Load-Balancer weitergeleitet werden. |
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 aufbewahren, indem Sie das Proxyprotokoll auf dem Zielproxy aktivieren.
| 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 unterstützten Backend-Features aufgeführt.
| 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 | ||||
* Wird nur für das SSL-Protokoll unterstützt.
Back-Ends und VPC-Netzwerke
Alle Back-Ends müssen sich in demselben Projekt befinden, können jedoch in verschiedenen VPC-Netzwerken sein. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFE-Proxysysteme direkt mit Back-Ends in ihren jeweiligen VPC-Netzwerken kommunizieren.
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 |
|---|---|---|
| Klassischer Proxy-Network Load Balancer |
|
Diese Bereiche gelten für Systemdiagnoseprüfungen und Anfragen vom GFE. |
| Globaler externer Proxy-Network Load Balancer |
|
Diese Bereiche gelten für Systemdiagnoseprüfungen und Anfragen vom GFE. |
| Regionaler externer Proxy-Network Load Balancer1, 2 |
|
Diese Bereiche gelten für Systemdiagnoseprüfungen. |
1 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.
2 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.
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.
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
Klassische Proxy-Network Load Balancer und regionale externe 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 TCP- oder SSL-Zielproxy 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. |
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
CONNECTIONist, wird die Last anhand der Gesamtzahl der Verbindungen verteilt, die das Backend verarbeiten kann. - Wenn der Load-Balancing-Modus
UTILIZATIONist, wird die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt. Dieser Balancing-Modus gilt nur für VM-Instanzgruppen-Backénds.
Wie der Traffic auf Back-Ends verteilt wird, hängt vom Modus des Load Balancers ab.
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 (global und regional) 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
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 Application Load Balancer in der Premiumstufe nicht mit der Google Cloud Console erstellen. Verwenden Sie stattdessen die gcloud CLI oder die REST API.
Der globale externe Proxy-Network Load Balancer stellt keine TCP-Verbindung zum Backend her, bis der Client Daten an den Load Balancer sendet. Das bedeutet, dass Anwendungen, die zum Senden des ersten Datenpakets vom Server (oder Backend) abhängig sind, nicht funktionieren.
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.
- SSL-Richtlinien verwenden.
- Logging und Monitoring für Proxy-Network Load Balancer.
- GFE-Standorte.