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

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie einen externen Proxy-Network Load Balancer Trusted 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 IhremTrusted Cloud VPC-Netzwerk (Virtual Private Cloud) verteilt. Bei Verwendung eines externen Proxy-Network-Load-Balancers wird eingehender TCP-Traffic am Load Balancer beendet. Eine neue Verbindung leitet den Traffic dann über TCP oder SSL (empfohlen) an das nächstgelegene verfügbare Backend.

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.

Dieser Load Balancer ist im regionalen Modus verfügbar und wird im Folgenden als regionaler externer Proxy-Network Load Balancer bezeichnet. Der Load Balancer wird als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert. Der regionale Modus sorgt dafür, dass sich alle Clients und Backends in einer bestimmten Region befinden. Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen.

Architektur

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

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.

Angabe der IP-Adresse 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.

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.

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
Regionaler externer Proxy-Network Load Balancer	Premium-	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.

Weiterleitungsregeln und VPC-Netzwerke

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

Load-Balancer-Modus	VPC-Netzwerkzuordnung
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.

Standardmäßig werden die ursprüngliche IP-Adresse des Clients und die Portinformationen im Zielproxy nicht beibehalten. Sie können diese Informationen beibehalten, indem Sie das PROXY-Protokoll für den Zielproxy aktivieren.

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

Load-Balancer-Modus	Netzwerkdienststufe	Zielproxy
Regionaler externer Proxy-Network Load Balancer	Premium- und Standardstufe	regionTargetTcpProxies

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 im Backend-Dienst von externen Proxy-Network Load Balancern unterstützt werden.

Load-Balancer-Modus	Unterstützte Backends in einem Backend-Dienst
	Instanzgruppen	Zonale NEGs	Internet-NEGs	Serverlose NEGs	Hybrid-NEGs	GKE
Regionaler externer Proxy-Network Load Balancer		Endpunkte des Typs GCE_VM_IP_PORT	Nur regionale NEGs

Back-Ends und VPC-Netzwerke

Für Back-Ends regionaler externer Proxy-Network Load Balancer gilt Folgendes:

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

  Definition des Backend-Netzwerks

  • Bei zonalen NEGs und Hybrid-NEGs geben Sie das VPC-Netzwerk explizit an, wenn Sie die NEG erstellen.
  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so festgelegt, dass es mit dem VPC-Netzwerk der nic0-Schnittstelle der ersten 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 konfigurieren, um die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den von den Backend-Instanzen oder ‑Endpunkten verwendeten Subnetzen zu ermöglichen.

• 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 Nicht-nic0-Schnittstellen (entweder vNICs oder dynamische Netzwerkschnittstellen) senden möchten, verwenden Sie stattdessen NEG-Backends.

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. Der Load-Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln. Die externen Proxy-Network Load Balancer unterstützen nur TCP für die Kommunikation mit den Backends.

Firewallregeln

Die folgenden Firewallregeln sind erforderlich:

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

Quell-IP-Adressen

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

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 einem NAT-Gateway 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 Back-Ends gesendet.

  GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Mit 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 Cloud Armor nicht explizit konfiguriert haben. Kosten fallen nur an, 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 unterstützen Bereitstellungen, die freigegebene VPC-Netzwerke 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 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- Zielproxy muss im selben Projekt wie die Backend-Instanzen 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 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.

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äß seinem Balancing-Modus 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 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.

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

• Keine

  Eine Einstellung für die Sitzungsaffinität von NONE bedeutet nicht, dass es keine Sitzungsaffinität gibt. Das bedeutet, dass keine Option für die Sitzungsaffinität explizit konfiguriert ist.

  Hashing wird immer zur Auswahl eines Backends verwendet. Bei einer Einstellung für die Sitzungsaffinität von NONE verwendet der Load-Balancer einen 5-Tupel-Hash, um ein Backend auszuwählen. Der 5-Tupel-Hash besteht aus der Quell-IP-Adresse, dem Quellport, dem Protokoll, der Ziel-IP-Adresse und dem Zielport.

  Der Standardwert für die Sitzungsaffinität ist NONE.

• Client-IP-Affinität

  Die Client-IP-Sitzungsaffinität (CLIENT_IP) ist ein 2-Tupel-Hash, der aus der Quell- und Ziel-IP-Adresse des Pakets erstellt wird. Mit der Client-IP-Affinität werden alle Anfragen von derselben Client-IP-Adresse an dasselbe Backend weitergeleitet, sofern dieses Backend Kapazität hat und fehlerfrei ist.

  Beachten Sie bei der Verwendung der Client-IP-Affinität Folgendes:

  • Die Ziel-IP-Adresse des Pakets ist nur dann mit der IP-Adresse der Weiterleitungsregel des Load-Balancers identisch, wenn das Paket direkt an den Load-Balancer gesendet wird.
  • Die Quell-IP-Adresse des Pakets stimmt möglicherweise nicht mit einer IP-Adresse überein, die dem ursprünglichen Client zugeordnet ist, wenn das Paket von einem zwischengeschalteten NAT- oder Proxysystem verarbeitet wird, bevor es an einen Trusted Cloud Load-Balancer gesendet wird. In Situationen, in denen viele Clients dieselbe effektive Quell-IP-Adresse verwenden, erhalten einige Back-End-VMs möglicherweise mehr Verbindungen oder Anfragen als andere.

Beachten Sie beim Konfigurieren der Sitzungsaffinität Folgendes:

• Verlassen Sie sich bei Authentifizierungs- oder Sicherheitsthemen nicht auf die Sitzungsaffinität. Die Sitzungsaffinität kann unterbrochen werden, wenn sich die Anzahl der bereitstellenden und fehlerfreien Back-Ends ändert. Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

• Die Standardwerte der Flags --session-affinity und --subsetting-policy sind beide NONE und können jeweils nur auf einen anderen Wert festgelegt werden.

Verlust der Sitzungsaffinität

Für alle Optionen für die Sitzungsaffinität ist Folgendes erforderlich:

• Die ausgewählte Backend-Instanz oder der ausgewählte Endpunkt muss als Backend konfiguriert bleiben. Die Sitzungsaffinität kann unterbrochen werden, wenn eines der folgenden Ereignisse eintritt:
  • Sie entfernen die ausgewählte Instanz aus ihrer Instanzgruppe.
  • Beim Autoscaling oder der automatischen Reparatur einer verwalteten Instanzgruppe wird die ausgewählte Instanz aus der verwalteten Instanzgruppe entfernt.
  • Sie entfernen den ausgewählten Endpunkt aus seiner NEG.
  • Sie entfernen die Instanzgruppe oder NEG, die die ausgewählte Instanz oder den ausgewählten Endpunkt enthält, aus dem Backend-Dienst.
• Die ausgewählte Back-End-Instanz oder der ausgewählte Endpunkt muss fehlerfrei bleiben. Die Sitzungsaffinität kann aufgehoben sein, wenn die ausgewählte Instanz oder der ausgewählte Endpunkt die Systemdiagnosen nicht besteht.
• Bei globalen externen Proxy-Network Load Balancern und klassischen Proxy-Network Load Balancern kann die Sitzungsaffinität unterbrochen werden, wenn nach der Änderung des Routingpfads für nachfolgende Anfragen oder Verbindungen ein anderes Google Front End (GFE) der ersten Ebene verwendet wird. Wenn sich der Routingpfad von einem Client im Internet zu Google zwischen Anfragen oder Verbindungen ändert, wird möglicherweise ein anderes GFE der ersten Ebene ausgewählt.

Für alle Optionen für die Sitzungsaffinität gelten die folgenden zusätzlichen Anforderungen:

• Die Instanzgruppe oder NEG, die die ausgewählte Instanz oder den ausgewählten Endpunkt enthält, darf nicht voll sein, wie durch die Zielkapazität definiert. Bei regional verwalteten Instanzgruppen darf die zonale Komponente der Instanzgruppe, die die ausgewählte Instanz enthält, nicht voll sein. Die Sitzungsaffinität kann unterbrochen werden, wenn die Instanzgruppe oder das NEG voll ist und andere Instanzgruppen oder NEGs nicht. Da sich die Füllmenge bei Verwendung des Balancing-Modus UTILIZATION unvorhersehbar ändern kann, sollten Sie den Balancing-Modus RATE oder CONNECTION verwenden, um Situationen zu minimieren, in denen die Sitzungsaffinität unterbrochen werden kann.

• Die Gesamtzahl der konfigurierten Back-End-Instanzen oder ‑Endpunkte muss konstant bleiben. Wenn mindestens eines der folgenden Ereignisse eintritt, ändert sich die Anzahl der konfigurierten Back-End-Instanzen oder Endpunkte und die Sitzungsaffinität kann unterbrochen werden:

  • Neue Instanzen oder Endpunkte hinzufügen:

    • Sie fügen einem vorhandenen Backend-Dienst Instanzen hinzu.
    • Beim Autoscaling für verwaltete Instanzgruppen werden dem Back-End-Dienst Instanzen einer verwalteten Instanzgruppe hinzugefügt.
    • Sie fügen einem vorhandenen Backend-Dienst Endpunkte hinzu.
    • Sie fügen dem Backend-Dienst nicht leere Instanzgruppen oder NEGs hinzu.

  • Wenn Sie eine Instanz oder einen Endpunkt entfernen, nicht nur die ausgewählte Instanz oder den ausgewählten Endpunkt:

    • Sie entfernen eine Instanz aus einem Instanzgruppen-Backend.
    • Beim Autoscaling oder der automatischen Reparatur von verwalteten Instanzgruppen wird jede Instanz aus einem Backend mit verwalteten Instanzgruppen entfernt.
    • Sie entfernen einen Endpunkt aus einem NEG-Backend.
    • Sie entfernen alle vorhandenen, nicht leeren Backend-Instanzgruppen oder NEGs aus dem Backend-Dienst.

• Die Gesamtzahl der fehlerfreien Backend-Instanzen oder ‑Endpunkte muss konstant bleiben. Wenn mindestens eines der folgenden Ereignisse eintritt, ändert sich die Anzahl der fehlerfreien Back-End-Instanzen oder ‑Endpunkte und die Sitzungsaffinität kann unterbrochen werden:

  • Eine Instanz oder ein Endpunkt besteht die Systemdiagnose und wechselt vom Status „Fehlerhaft“ zu „Fehlerfrei“.
  • Eine Instanz oder ein Endpunkt besteht die Systemdiagnose nicht und wechselt vom Status „Fehlerfrei“ zu „Fehlerhaft“ oder „Zeitüberschreitung“.

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 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 derTrusted Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen.Verwenden Sie stattdessen die gcloud CLI oder die API.

• Trusted Cloud übernimmt keine Garantie für die Lebensdauer von TCP-Verbindungen, wenn Sie externe Proxy-Network-Load-Balancer verwenden. Clients sollten Verbindungsabbrüche tolerieren können, die sowohl auf allgemeine Internetprobleme als auch auf regelmäßig geplante Neustarts der Proxys zurückzuführen sind, die die Verbindungen verwalten.

Nächste Schritte

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