Interner Proxy-Network Load Balancer – Übersicht

Der regionale interne Proxy-Network Load Balancer von Google Cloud ist ein proxy-basierter regionaler Load Balancer, der auf der Open-Source-Proxy-Software Envoy und dem Andromeda-Netzwerkvirtualisierungs-Stack basiert.

Der interne Proxy-Network Load Balancer ist ein Layer-4-Load-Balancer, mit dem Sie Ihren TCP-Diensttraffic hinter einer regionalen internen IP-Adresse ausführen und skalieren können, auf die nur Clients im selben VPC-Netzwerk oder Clients zugreifen können., die mit Ihrem VPC-Netzwerk verbunden sind. Der Load Balancer beendet zuerst die TCP-Verbindung zwischen dem Client und dem Load Balancer in einem Envoy-Proxy. Der Proxy öffnet eine zweite TCP-Verbindung zu Back-Ends, die in Google Cloud, lokal oder in anderen Cloud-Umgebungen gehostet werden. Weitere Anwendungsfälle finden Sie unter Proxy-Network Load Balancer – Übersicht.

Betriebsarten

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

• Regionaler interner Proxy-Network Load Balancer. Dies ist ein regionaler Load Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Der regionale Modus stellt sicher, dass alle Clients und Back-Ends aus einer bestimmten Region stammen, was hilfreich ist, wenn Sie regionale Compliance benötigen.

• Regionsübergreifender interner Proxy-Network Load Balancer. Dies ist ein multiregionaler Load Balancer, der als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert ist. Mit dem regionenübergreifenden Modus können Sie Traffic auf global verteilte Backend-Dienste verteilen, einschließlich der Trafficverwaltung, die dafür sorgt, dass der Traffic an das nächstgelegene Backend weitergeleitet wird. Dieser Load Balancer ermöglicht auch Hochverfügbarkeit. Durch die Platzierung von Backends in mehreren Regionen lassen sich Fehler in einer einzelnen Region vermeiden. Wenn die Back-Ends einer Region ausfallen, kann der Traffic auf eine andere Region umgeleitet werden.

  In der folgenden Tabelle werden die wichtigen Unterschiede zwischen regionalen und regionenübergreifenden Modi beschrieben:

  Funktion	Regionaler interner Proxy-Network Load Balancer	Regionsübergreifender interner Proxy-Network Load Balancer
  Virtuelle IP-Adresse (VIP) des Load Balancers.	Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen.	Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen. VIP-Adressen aus mehreren Regionen können denselben globalen Backend-Dienst verwenden.
  Clientzugriff	Zugriff ist standardmäßig nicht global möglich. (Optional) Sie können den globalen Zugriff aktivieren.	Zugriff immer global. Clients aus jeder Google Cloud-Region können Traffic an den Load Balancer senden.
  Back-Ends mit Load Balancing	Regionale Back-Ends. Der Load Balancer kann Traffic nur an Back-Ends senden, die sich in derselben Region wie der Proxy des Load Balancers befinden.	Globale Back-Ends. Der Load Balancer kann Traffic an Back-Ends in jeder Region senden.
  Hochverfügbarkeit und Failover	Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.	Automatisches Failover auf fehlerfreie Backends in derselben oder in unterschiedlichen Regionen.

Modus bestimmen

Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für interne Proxy-Network Load Balancer erforderlich sind.

Nur-Proxy-Subnetz

Im obigen Diagramm stellt das Nur-Proxy-Subnetz 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 einen Envoy-basierten internen Proxy-Network Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. In der folgenden Tabelle werden die Unterschiede zwischen Nur-Proxy-Subnetzen im regionalen und regionenübergreifenden Modus beschrieben:

Load-Balancer-Modus	Wert des Flags --purpose des Nur-Proxysubnetzes
Regionaler interner Proxy-Network Load Balancer	REGIONAL_MANAGED_PROXY Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden Alle regionalen Envoy-basierten Load Balancer in einer Region und einem VPC-Netzwerk verwenden dasselbe Nur-Proxy-Subnetz
Regionsübergreifender interner Proxy-Network Load Balancer	GLOBAL_MANAGED_PROXY Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden Der regionenübergreifende Envoy-basierte Load Balancer muss in jeder Region, in der der Load Balancer konfiguriert ist, ein Nur-Proxy-Subnetz haben. Regionenübergreifende Load Balancer-Proxys in derselben Region und demselben Netzwerk verwenden dasselbe Nur-Proxy-Subnetz.

Weiter:

• Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
• Back-End-VM-Instanzen oder Endpunkte aller internen Proxy-Network Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
• Die IP-Adresse eines internen Proxy-Network Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load Balancers wird durch seine intern 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 Back-End-Dienst besteht.

Clients verwenden die IP-Adresse und den Port, um eine Verbindung zu den Envoy-Proxys des Load Balancers herzustellen. Die IP-Adresse der Weiterleitungsregel ist die IP-Adresse des Load Balancers (manchmal auch virtuelle IP-Adresse oder VIP genannt). Clients, die eine Verbindung zu einem Load-Balancer herstellen, müssen TCP verwenden. Eine vollständige Liste der unterstützten Protokolle finden Sie unter Load-Balancer-Features im Vergleich.

Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus einem Subnetz im selben Netzwerk und in derselben Region wie die Back-Ends stammen. Jede Weiterleitungsregel, die Sie in einem internen Proxy-Network Load Balancer verwenden, kann auf genau einen TCP-Port verweisen. Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus jedem Subnetz im selben Netzwerk und in derselben Region stammen.

Die folgende Tabelle zeigt die Unterschiede zwischen Weiterleitungsregeln im regionalen und regionenübergreifenden Modus:

Load-Balancer-Modus	Weiterleitungsregel, IP-Adresse und Nur-Proxy-Subnetz --purpose	Routing vom Client zum Frontend des Load Balancers
Regionaler interner Proxy-Network Load Balancer	Regional forwardingRules Regionale IP-Adresse Load Balancing-Schema: INTERNAL_MANAGED Nur-Proxy-Subnetz: --purpose REGIONAL_MANAGED_PROXY IP-Adresse --purpose: SHARED_LOADBALANCER_VIP	Sie können den globalen Zugriff aktivieren, damit Clients aus beliebigen Regionen auf Ihren Load Balancer zugreifen können. Back-Ends müssen sich auch in derselben Region wie der Load Balancer befinden.
Regionsübergreifender interner Proxy-Network Load Balancer	Global globalForwardingRules Regionale IP-Adressen Load Balancing-Schema: INTERNAL_MANAGED Nur-Proxy-Subnetz: --purpose GLOBAL_MANAGED_PROXY IP-Adresse --purpose: SHARED_LOADBALANCER_VIP	Der globale Zugriff ist standardmäßig aktiviert, damit Clients aus jeder Region auf den Load Balancer zugreifen können. Back-Ends können sich in mehreren Regionen befinden.

Zielproxys

Der interne Proxy-Network Load Balancer beendet TCP-Verbindungen vom Client und erstellt neue Verbindungen zu den Back-Ends. Standardmäßig bleiben die ursprüngliche IP-Adresse des Clients und die Portinformationen nicht erhalten. Sie können diese Informationen jedoch mithilfe des Proxy-Protokolls aufbewahren. Der Zielproxy leitet eingehende Anfragen direkt an den Backend-Dienst des Load-Balancers weiter.

In der folgenden Tabelle sind die Zielproxy APIs aufgeführt, die für interne Proxy-Network Load Balancer in den einzelnen Modi erforderlich sind:

Zielproxy	Regionaler interner Proxy-Network Load Balancer	Regionsübergreifender interner Proxy-Network Load Balancer
TCP	Regional regionTargetTcpProxies	Global targetTcpProxies

Backend-Dienst

Ein Backend-Dienst leitet eingehenden Traffic an ein oder mehrere verknüpfte Backends weiter. Ein Backend ist entweder eine Instanzgruppe oder eine Netzwerk-Endpunktgruppe. Das Backend enthält Informationen zum Balancing-Modus, um die Vollständigkeit basierend auf Verbindungen zu definieren (oder, nur bei Instanzgruppen-Backends, basierend auf der Auslastung).

Jeder interne Proxy-Network Load Balancer hat eine einzelne Backend-Dienstressource. In der folgenden Tabelle ist der Back-End-Diensttyp angegeben, der von internen Proxy-Network Load Balancer in den einzelnen Modi benötigt wird:

	Regionaler interner Proxy-Network Load Balancer	Regionsübergreifender interner Proxy-Network Load Balancer
Typ des Backend-Dienstes	Regional regionBackendServices	Global backendServices

Unterstützte Back-Ends

Der Backend-Dienst unterstützt die folgenden Arten von Backends:

Load-Balancer-Modus	Unterstützte Backends in einem Backend-Dienst
	Instanzgruppen	Zonale NEGs	Internet-NEGs	Serverlose NEGs	Hybrid-NEGs	Private Service Connect-NEGs	GKE
Regionaler interner Proxy-Network Load Balancer		Endpunkte des Typs GCE_VM_IP_PORT	Nur regionale NEGs			Private Service Connect-NEG hinzufügen
Regionsübergreifender interner Proxy-Network Load Balancer		Endpunkte des Typs GCE_VM_IP_PORT				Private Service Connect-NEG hinzufügen

Alle Back-Ends müssen vom selben Typ sein (Instanzgruppen oder NEGs). Sie können verschiedene Typen von Instanzgruppen-Backends gleichzeitig verwenden. Sie können auch verschiedene Arten von NEG-Backends gleichzeitig verwenden. Sie können jedoch Instanzgruppen- und NEG-Backends nicht zusammen auf demselben Backend-Dienst verwenden.

Sie können zonale und hybride NEGs innerhalb desselben Backend-Dienstes kombinieren.

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.

Protokoll für die Kommunikation mit den Back-Ends

Wenn Sie einen Backend-Dienst für einen internen Proxy-Network Load Balancer konfigurieren, legen Sie das Protokoll fest, über das der Backend-Dienst mit den Backends kommuniziert. Der Load-Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln. Der regionale interne Proxy-Network Load Balancer oder der regionenübergreifende interne Proxy-Network Load Balancer unterstützt nur TCP für die Kommunikation mit den Back-Ends.

Systemdiagnose

Jeder Backend-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Backends überwacht, eine Verbindung vom Load-Balancer zu erhalten. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können. Systemdiagnosen prüfen nicht, ob die Anwendung selbst funktioniert.

Systemdiagnoseprotokoll

Obwohl es nicht erforderlich und nicht immer möglich ist, empfiehlt es sich, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Backend-Dienstes entspricht. So lässt sich beispielsweise mit einer TCP-Systemdiagnose die TCP-Konnektivität zu Back-Ends am genauesten testen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von den internen Proxy-Network Load Balancern in den einzelnen Modi unterstützt werden:

Load-Balancer-Modus	Systemdiagnosetyp
Regionaler interner Proxy-Network Load Balancer	Regional regionHealthChecks
Regionsübergreifender interner Proxy-Network Load Balancer	Global healthChecks

Weitere Informationen zu Systemdiagnosen finden Sie hier:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen

Firewallregeln

Für interne Proxy-Network Load Balancer sind die folgenden Firewallregeln erforderlich:

• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Systemdiagnoseprüfungen von Google zuzulassen.
  • 35.191.0.0/16
  • 130.211.0.0/22
• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.

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.

• GCE_VM_IP_PORT-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

Für diese Load-Balancer gelten bestimmte Ausnahmen bei den Anforderungen an Firewallregeln:

• 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.

Clientzugriff

Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist.

Bei internen Application Load Balancern müssen sich Clients standardmäßig in derselben Region wie der Load Balancer befinden. Sie können den globalen Zugriff aktivieren, damit Clients aus beliebigen Regionen auf Ihren Load Balancer zugreifen können.

Für regionenübergreifende interne Proxy-Load Balancer ist der globale Zugriff standardmäßig aktiviert. Clients aus jeder Region können auf Ihren Load Balancer zugreifen.

In der folgenden Tabelle wird der Clientzugriff für regionale interne Proxy-Network Load Balancer zusammengefasst:

Globaler Zugriff deaktiviert	Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.	Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden.	Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

Architektur einer freigegebenen VPC

Der interne Proxy-Network Load Balancer unterstützt Netzwerke, die eine freigegebene VPC verwenden. 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 interne IP-Adresse muss im selben Projekt wie die Back-Ends definiert werden. Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne IP-Adresse von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.	Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-Ends definiert werden. Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Backend-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.	Der Zielproxy muss im selben Projekt wie die Back-Ends definiert werden.	Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Backend-VMs normalerweise in einem Dienstprojekt. Dort müssen auch der regionale interne Backend-Dienst und die Systemdiagnose definiert werden.

Traffic-Verteilung

Ein interner Proxy-Network Load Balancer verteilt den Traffic so an seine Back-Ends:

1. Verbindungen, die von einem einzelnen Client stammen, werden an dieselbe Zone gesendet, sofern fehlerfreie Back-Ends (Instanzgruppen oder NEGs) innerhalb dieser Zone verfügbar sind und Kapazität haben, wie durch den Balancing-Modus bestimmt. Bei regionalen internen Proxy-Network Load Balancern kann der Balancing-Modus CONNECTION (Instanz- oder NEG-Back-Ends) oder UTILIZATION (nur Instanzgruppen-Back-Ends) sein.
2. Verbindungen von einem Client werden an dasselbe Backend gesendet, wenn Sie die Sitzungsaffinität konfiguriert haben.
3. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß einer Load-Balancing-Richtlinie auf Instanzen (in einer Instanzgruppe) oder Endpunkte (in einer NEG) verteilt. Informationen zu den unterstützten Load-Balancing-Richtlinienalgorithmen finden Sie in der Einstellung localityLbPolicy in der API-Dokumentation für regionale Backend-Dienste.

Sitzungsaffinität

Mit der Sitzungsaffinität können Sie den Backend-Dienst des Load-Balancers so konfigurieren, dass alle Anfragen vom selben Client an dasselbe Backend gesendet werden, sofern das Backend fehlerfrei ist und Kapazität hat.

Der interne Proxy-Network Load Balancer bietet die Client-IP-Affinität, mit der alle Anfragen von derselben Client-IP-Adresse an dasselbe Backend weitergeleitet werden, sofern dieses Backend Kapazität hat und fehlerfrei ist.

Failover

Wenn ein Backend fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Backends weitergeleitet. In der folgenden Tabelle wird das Failover-Verhalten in den einzelnen Modi beschrieben:

Load-Balancer-Modus	Failover-Verhalten	Verhalten, wenn alle Back-Ends fehlerhaft sind
Regionaler interner Proxy-Network Load Balancer	Der Load-Balancer implementiert einen reibungslosen Failover-Algorithmus pro Zone. Anstatt zu warten, bis alle Back-Ends in einer Zone fehlerhaft werden, leitet der Load-Balancer den Traffic an eine andere Zone weiter, wenn das Verhältnis von fehlerfreien zu fehlerhaften Back-Ends in einer Zone unter einem bestimmten Prozentsatz liegt (70%, dieser Schwellenwert ist nicht konfigurierbar). Wenn alle Back-Ends in allen Zonen fehlerhaft sind, beendet der Load-Balancer die Clientverbindung sofort. Der Envoy-Proxy sendet Traffic an fehlerfreie Backends in einer Region anhand der konfigurierten Trafficverteilung.	Beendet die Verbindung
Regionsübergreifender interner Proxy-Network Load Balancer	Automatisches Failover auf fehlerfreie Backends in derselben Region oder in anderen Regionen. Der Traffic wird anhand der konfigurierten Trafficverteilung auf fehlerfreie Backends verteilt, die sich über mehrere Regionen erstrecken.	Beendet die Verbindung

Load-Balancing für GKE-Anwendungen

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

Zugehörige GKE-Dokumentation:

• Containernatives Load-Balancing über eigenständige NEGs

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.

Beschränkungen

• Der interne Proxy-Network Load Balancer unterstützt keinen IPv6-Traffic.
• Der interne Proxy-Network Load Balancer unterstützt keine freigegebenen VPC-Bereitstellungen, bei denen sich das Frontend des Load Balancers in einem Host- oder Dienstprojekt befindet und der Backend-Dienst und die Backends in einem anderen Dienstprojekt sind (auch als projektübergreifende Dienstverweise bezeichnet).

Nächste Schritte

• Regionalen internen Proxy-Network Load Balancer mit einem Instanzgruppen-Backend einrichten
• Regionalen internen Proxy-Network Load Balancer mit einem zonalen NEG-Backend einrichten
• Regionalen internen Proxy-Network Load Balancer mit einem hybriden NEG-Backend einrichten
• Regionalen internen Proxy-Network Load Balancer mit einem Internet-NEG-Backend einrichten
• Messwerte mit Cloud Monitoring ansehen