Übersicht über Back-End-Dienste

Ein Back-End-Dienst definiert, wie Cloud Load Balancing Traffic verteilt. Die Back-End-Dienstkonfiguration enthält eine Reihe von Werten, z. B. das Protokoll für die Verbindung mit Back-Ends, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen. Mit diesen Einstellungen können Sie das Verhalten Ihres Load-Balancers genau steuern. Für einen schnellen Einstieg haben die meisten Einstellungen Standardwerte, die eine schnelle Konfiguration ermöglichen. Ein Backend-Dienst ist entweder global oderregional.

Load-Balancer, Envoy-Proxys und proxylose gRPC-Clients verwenden die Konfigurationsinformationen in der Back-End-Dienstressource, um die folgenden Aufgaben auszuführen:

• Weiterleiten von Traffic an die richtigen Back-Ends, die Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sind.
• Verteilen von Traffic gemäß einem Load-Balancing-Modus. Dies ist eine Einstellung für jedes Back-End.
• Bestimmen, welche Systemdiagnose den Zustand der Back-Ends überwacht.
• Angeben der Sitzungsaffinität.
• Prüfen Sie, ob andere Dienste aktiviert sind, einschließlich der folgenden Dienste, die nur für bestimmte Load-Balancer verfügbar sind:
  • Cloud CDN
  • Cloud Armor-Sicherheitsrichtlinien
  • Identity-Aware Proxy
• Legen Sie regionale Back-End-Dienste als Dienst in App Hub fest, das sich in der Vorschau befindet.

Sie legen diese Werte fest, wenn Sie einen Backend-Dienst erstellen oder dem Backend-Dienst ein Backend hinzufügen.

Hinweis: Wenn Sie entweder den globalen externen Application Load Balancer oder den klassischen Application Load Balancer verwenden und Ihre Backends statische Inhalte bereitstellen, sollten Sie Backend-Buckets anstelle von Backend-Diensten verwenden. Weitere Informationen finden Sie unter Backend-Buckets für globale externe Application Load Balancer oder Backend-Buckets für klassische Application Load Balancer.

In der folgenden Tabelle wird zusammengefasst, welche Load-Balancer Backend-Dienste verwenden. Das verwendete Produkt bestimmt auch die maximale Anzahl von Backend-Diensten, den Umfang eines Backend-Dienstes, den unterstützten Backend-Typ und das Load-Balancing-Schema des Backend-Dienstes. Das Load Balancing-Schema ist eine Kennzeichnung, die Google zum Klassifizieren von Weiterleitungsregeln und Backend-Diensten verwendet. Jedes Load Balancing-Produkt verwendet ein Load Balancing-Schema für seine Weiterleitungsregeln und Backend-Dienste. Einige Schemata werden für mehrere Produkte verwendet.

Tabelle: Backend-Dienste und unterstützte Backend-Typen

Produkt	Maximale Anzahl der Back-End-Dienste	Bereich des Back-End-Dienstes	Unterstützte Back-End-Typen	Load-Balancing-Schema
Globaler externer Application Load Balancer	Mehrere	Global	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Alle serverlosen NEGs: Ein oder mehrere App Engine-, Cloud Run- oder Cloud Run Functions-Dienste Eine globale Internet-NEG für ein externes Backend Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: ein oder mehrere Private Service Connect-NEGs	EXTERNAL_MANAGED
Klassischer Application Load Balancer	Mehrere	Global^‡	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends Alle zonalen NEGs: eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Alle serverlosen NEGs: Ein oder mehrere App Engine-, Cloud Run- oder Cloud Run Functions-Dienste Eine globale Internet-NEG für ein externes Backend	EXTERNAL^#
Regionaler externer Application Load Balancer	Mehrere	Regional	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Eine einzelne serverlose NEG (nur Cloud Run) Eine einzelne Private Service Connect-NEG Alle regionalen Internet-NEGs für ein externes Backend	EXTERNAL_MANAGED
Regionsübergreifender interner Application Load Balancer	Mehrere	Global	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Eine einzelne serverlose NEG (nur Cloud Run) Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: ein oder mehrere Private Service Connect-NEGs	INTERNAL_MANAGED
Regionaler interner Application Load Balancer	Mehrere	Regional	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Eine einzelne serverlose NEG (nur Cloud Run) Eine einzelne Private Service Connect-NEG Alle regionalen Internet-NEGs für ein externes Backend	INTERNAL_MANAGED
Globaler externer Proxy-Network Load Balancer	1	Global^‡	The backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^† Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: ein oder mehrere Private Service Connect-NEGs	EXTERNAL_MANAGED
Klassischer Proxy-Network Load Balancer	1	Global^‡	The backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends Alle zonalen NEGs: eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT ^†	EXTERN
Regionaler externer Proxy-Network Load Balancer	1	Regional	The backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT Alle regionalen Internet-NEGs für ein externes Backend Eine einzelne Private Service Connect-NEG	EXTERNAL_MANAGED
Regionaler interner Proxy-Network Load Balancer	1	Regional	The backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT Alle regionalen Internet-NEGs für ein externes Backend Eine einzelne Private Service Connect-NEG	INTERNAL_MANAGED
Regionsübergreifender interner Proxy-Network Load Balancer	Mehrere	Global	The backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends ^* Alle zonalen NEGs: eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT ^* Alle Hybrid-Konnektivitäts-NEGs: Eine oder mehrere NEGs vom Typ NON_GCP_PRIVATE_IP_PORT Eine Kombination aus zonalen und hybriden NEGs: NEGs vom Typ GCE_VM_IP_PORT und NON_GCP_PRIVATE_IP_PORT Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: ein oder mehrere Private Service Connect-NEGs	INTERNAL_MANAGED
Externer Passthrough-Network Load Balancer	1	Regional	Der Backend-Dienst unterstützt eine der folgenden Backend-Kombinationen: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends Alle zonalen NEGs: eine oder mehrere zonale NEGs des Typs GCE_VM_IP	EXTERN
Interner Passthrough-Network-Load-Balancer	1	Regional, aber für globalen Zugriff konfigurierbar	Der Backend-Dienst unterstützt eine der folgenden Backend-Kombinationen: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends Alle zonalen NEGs: eine oder mehrere zonale NEGs des Typs GCE_VM_IP Eine NEG für die Portzuordnung (Vorabversion)	INTERN
Cloud Service Mesh	Mehrere	Global	Each backend service supports one of the following backend combinations: Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends Alle zonalen NEGs: Eine oder mehrere zonale NEGs vom Typ GCE_VM_IP_PORT oder NON_GCP_PRIVATE_IP_PORT Eine Internet-NEG vom Typ INTERNET_FQDN_PORT Eine oder mehrere Dienstbindungen	INTERNAL_SELF_MANAGED

^* Unterstützt IPv4- und IPv6-Instanzgruppen (Dual-Stack) und zonalen NEG-Back-Ends. Zonale NEGs unterstützen Dual-Stack nur bei Endpunkten vom Typ GCE_VM_IP_PORT.

^† Bei GKE-Deployments werden gemischte NEG-Back-Ends nur mit eigenständigen NEGs unterstützt.

^‡ Backend-Dienste, die von klassischen Application Load Balancern und klassischen Proxy-Network-Load-Balancern verwendet werden, sind immer global, entweder in der Standard- oder in der Premium-Netzwerkstufe. In der Standardstufe gelten jedoch die folgenden Einschränkungen:

• Die Weiterleitungsregel und ihre externe IP-Adresse sind regional.
• Alle mit dem Backend-Dienst verbundenen Backends müssen sich in derselben Region wie die Weiterleitungsregel befinden.

^# Es ist möglich, EXTERNAL_MANAGED-Back-End-Dienste an EXTERNAL-Weiterleitungsregeln anzuhängen. EXTERNAL-Back-End-Dienste können jedoch nicht an EXTERNAL_MANAGED-Weiterleitungsregeln angehängt werden. Wenn Sie die neuen Funktionen nutzen möchten, die nur mit dem globalen externen Application Load Balancer verfügbar sind, empfehlen wir Ihnen, Ihre vorhandenen EXTERNAL-Ressourcen mithilfe des Migrationsvorgangs unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren zu EXTERNAL_MANAGED zu migrieren.

Back-Ends

Ein Backend besteht aus einem oder mehreren Endpunkten, die Traffic von einem Google Cloud-Load Balancer, einem von Cloud Service Mesh konfigurierten Envoy-Proxy oder einem proxylosen gRPC-Client empfangen. Es gibt mehrere Arten von Back-Ends:

• Eine Instanzgruppe mit VM-Instanzen. Eine Instanzgruppe kann eine verwaltete Instanzgruppe mit oder ohne Autoscaling oder eine nicht verwaltete Instanzgruppe sein. Mehrere Back-End-Dienste können auf eine Instanzgruppe verweisen, aber alle Back-End-Dienste, die auf die Instanzgruppe verweisen, müssen denselben Balancing-Modus verwenden.
• Zonale NEG
• Serverlose NEG
• Internet-NEG
• Hybrid-Konnektivitäts-NEG
• Private Service Connect-NEG
• NEG für Portzuordnung (Vorabversion)
• Service Directory-Dienstbindungen

Sie können keine Backend-Instanzgruppe oder NEG löschen, die mit einem Backend-Dienst verknüpft ist. Bevor Sie eine Instanzgruppe oder NEG löschen, müssen Sie sie als Backend aus allen Backend-Diensten entfernen, die darauf verweisen.

Instanzgruppen

In diesem Abschnitt wird erläutert, wie Instanzgruppen mit dem Back-End-Dienst funktionieren.

Backend-VMs und externe IP-Adressen

Backend-VMs in Backend-Diensten benötigen keine externen IP-Adressen:

• Bei globalen externen Application Load Balancern und externen Proxy-Network-Load-Balancern kommunizieren Clients mit einem Google Front End (GFE), das die externe IP-Adresse Ihres Load-Balancers hostet. GFEs kommunizieren mit Backend-VMs oder -Endpunkten, indem Pakete an eine interne Adresse gesendet werden, die durch Zusammenführen einer Kennung für das VPC-Netzwerk des Backends mit der internen IPv4-Adresse des Backends erstellt wurde. Die Kommunikation zwischen GFEs und Backend-VMs oder Endpunkten wird durch spezielle Routen erleichtert.
  • Bei Back-Ends von Instanzgruppen ist die interne IPv4-Adresse immer die primäre interne IPv4-Adresse, die der nic0-Schnittstelle der VM entspricht.
  • FürGCE_VM_IP_PORT Endpunkte in einer zonalen NEG können Sie die IP-Adresse des Endpunkts entweder als primäre IPv4-Adresse angeben, die einer beliebigen Netzwerkschnittstelle einer VM zugeordnet ist, oder als beliebige IPv4-Adresse aus einem Alias-IP-Adressbereich, die mit einer beliebigen Netzwerkschnittstelle einer VM verknüpft ist.

• Für regionale externe Application Load Balancer: Clients kommunizieren mit einem Envoy-Proxy, der die externe IP-Adresse Ihres Load-Balancers hostet. Envoy-Proxys kommunizieren mit Backend-VMs oder -Endpunkten, indem Pakete an eine interne Adresse gesendet werden. Diese wird durch Zusammenführen einer Kennung für das VPC-Netzwerk des Backends mit der internen IPv4-Adresse des Backends erstellt.

  • Bei Instanzgruppen-Back-Ends ist die interne IPv4-Adresse immer die primäre interne IPv4-Adresse, die der nic0-Schnittstelle der VM entspricht, und nic0 muss sich im selben Netzwerk wie der Load-Balancer befinden.
  • FürGCE_VM_IP_PORT Endpunkte in einer zonalen NEG können Sie die IP-Adresse des Endpunkts entweder als primäre IPv4-Adresse angeben, die einer beliebigen Netzwerkschnittstelle einer VM zugeordnet ist, oder als beliebige IPv4-Adresse aus einem Alias-IP-Adressbereich, der mit einer beliebigen Netzwerkschnittstelle einer VM verknüpft ist, solange sich die Netzwerkschnittstelle im selben Netzwerk wie der Load-Balancer befindet.

• Für externe Passthrough-Network-Load-Balancer: Clients kommunizieren direkt über die Maglev-Passthrough-Load-Balancing-Infrastruktur von Google mit Back-Ends. Die Pakete werden weitergeleitet und an die Back-Ends gesendet, wobei die ursprünglichen Quell- und Ziel-IP-Adressen beibehalten werden. Back-Ends antworten auf Clients mit Direct Server Return.. Die zum Auswählen eines Back-Ends und zum Verfolgen von Verbindungen verwendeten Methoden sind konfigurierbar.

  • Bei Instanzgruppen-Back-Ends werden Pakete immer an die nic0-Schnittstelle der VM gesendet.
  • Bei GCE_VM_IP-Endpunkten in einer zonalen NEG werden Pakete an die Netzwerkschnittstelle der VM im Subnetzwerk zugestellt, das der NEG zugeordnet ist.

Benannte Ports

Das Attribut Benannter Port des Backend-Dienstes gilt nur für proxybasierte Load Balancer (Application Load Balancer und Proxy Network Load Balancer), die Instanzgruppen-Backends verwenden. Der benannte Port definiert den Zielport, der für die TCP-Verbindung zwischen dem Proxy (GFE oder Envoy) und der Backend-Instanz verwendet wird.

Benannte Ports werden so konfiguriert:

• An jedem Backend einer Instanzgruppe müssen Sie einen oder mehrere benannte Ports mit Schlüssel/Wert-Paaren konfigurieren. Der Schlüssel steht für einen aussagekräftigen Portnamen, den Sie auswählen, und der Wert steht für die Portnummer, die Sie dem Namen zuweisen. Die Zuordnung von Namen zu Zahlen erfolgt einzeln für jedes Backend der Instanzgruppe.

• Im Backend-Dienst geben Sie einen einzelnen benannten Port nur mit dem Portnamen (--port-name) an.

Auf Backend-Basis pro Instanz übersetzt der Backend-Dienst den Portnamen in eine Portnummer. Wenn der benannte Port einer Instanzgruppe mit dem --port-name des Backend-Dienstes übereinstimmt, verwendet der Backend-Dienst diese Portnummer für die Kommunikation mit den VMs der Instanzgruppe.

Sie können den benannten Port beispielsweise für eine Instanzgruppe mit dem Namen my-service-name und dem Port 8888 festlegen:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Dann müssen Sie in der Konfiguration des Backend-Dienstes auf den benannten Port verweisen, wobei --port-name im Backend-Dienst auf my-service-name gesetzt ist:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Ein Backend-Dienst kann bei der Kommunikation mit VMs in verschiedenen Instanzgruppen eine andere Portnummer verwenden, wenn jede Instanzgruppe eine andere Portnummer für denselben Portnamen angibt.

Die aufgelöste Portnummer, die vom Backend-Dienst des Proxy-Load-Balancers verwendet wird, muss nicht mit der von den Weiterleitungsregeln des Load-Balancers verwendeten Portnummer übereinstimmen. Ein Proxy-Load-Balancer überwacht TCP-Verbindungen, die an die IP-Adresse und den Zielport seiner Weiterleitungsregeln gesendet werden. Da der Proxy eine zweite TCP-Verbindung zu seinen Back-Ends öffnet, kann der Zielport der zweiten TCP-Verbindung variieren.

Benannte Ports gelten nur für Instanzgruppen-Back-Ends. Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten, Hybrid-NEGs mit NON_GCP_PRIVATE_IP_PORT-Endpunkten und Internet-NEGs definieren Ports mit einem anderen Mechanismus, nämlich auf den Endpunkten selbst. Serverlose NEGs verweisen auf Google-Dienste und PSC-NEGs verweisen auf Dienstanhänge, indem sie Abstraktionen verwenden, bei denen kein Zielport angegeben werden muss.

Interne Passthrough-Network-Load-Balancer und externe Passthrough-Network-Load-Balancer verwenden keine benannten Ports. Dies liegt daran, dass es sich um Pass-Through-Load-Balancer handelt, die Verbindungen direkt an Back-Ends weiterleiten, anstatt neue Verbindungen zu erstellen. An den Back-Ends zugestellte Pakete behalten die Ziel-IP-Adresse und den Port der Weiterleitungsregel des Load-Balancers bei.

Weitere Informationen zum Erstellen benannter Ports finden Sie in den folgenden Anleitungen:

• Nicht verwaltete Instanzgruppen: Mit benannten Ports arbeiten
• Verwaltete Instanzgruppen: Benannte Ports verwalteten Instanzgruppen zuweisen

Einschränkungen und Richtlinien für Instanzgruppen

Beachten Sie beim Erstellen von Instanzgruppen für Ihre Load-Balancer die folgenden Einschränkungen und Hinweise:

• Platzieren Sie eine VM nicht in mehr als einer Instanzgruppe mit Load-Balancing. Wenn eine VM Mitglied von zwei oder mehr nicht verwalteten Instanzgruppen oder Mitglied einer verwalteten Instanzgruppe und einer oder mehreren nicht verwalteten Instanzgruppen ist, können Sie in Google Cloud jeweils nur eine dieser Instanzgruppen gleichzeitig als Backend für einen bestimmten Backend-Dienst verwenden.

  Wenn eine VM an mehreren Load-Balancern beteiligt sein soll, müssen Sie dieselbe Instanzgruppe als Back-End für jeden der Back-End-Dienste verwenden.

• Wenn Sie bei Proxy-Load-Balancern den Traffic auf verschiedene Ports verteilen möchten, geben Sie die erforderlichen benannten Ports in einer Instanzgruppe an und lassen Sie jeden Back-End-Dienst einen eindeutigen benannten Port abonnieren.

• Sie können dieselbe Instanzgruppe als Back-End für mehrere Back-End-Dienste verwenden. In diesem Fall müssen die Back-Ends kompatible Balancing-Modi verwenden. Kompatibel bedeutet, dass die Balancing-Modi identisch oder eine Kombination aus CONNECTION und RATE sein müssen.

  Folgende Balancing-Modus-Kombinationen sind inkompatibel:

  • CONNECTION mit UTILIZATION
  • RATE mit UTILIZATION

  Dazu ein Beispiel:

  • Sie haben zwei Backend-Dienste: external-https-backend-service für einen externen Application Load Balancer und internal-tcp-backend-service für einen internen Passthrough-Network-Load-Balancer.
  • Sie verwenden eine Instanzgruppe namens instance-group-a in internal-tcp-backend-service.
  • In internal-tcp-backend-service müssen Sie den Balancing-Modus CONNECTION anwenden, da interne Passthrough-Network-Load-Balancer nur den Balancing-Modus CONNECTION unterstützen.
  • Sie können instance-group-a auch in external-https-backend-service verwenden, wenn Sie den Balancing-Modus RATE in external-https-backend-service anwenden.
  • instance-group-a kann nicht in external-https-backend-service mit dem Balancing-Modus UTILIZATION verwendet werden.

• So ändern Sie den Balancing-Modus für eine Instanzgruppe, die als Back-End für mehrere Back-End-Dienste dient:

  • Entfernen Sie die Instanzgruppe aus allen Back-End-Diensten bis auf einem.
  • Ändern Sie den Balancing-Modus für das Back-End auf dem einen verbleibenden Back-End-Dienst.
  • Fügen Sie den anderen Back-End-Diensten die Instanzgruppe wieder als Back-End hinzu, wenn sie den neuen Balancing-Modus unterstützen.

• Wenn Ihre Instanzgruppe mit mehreren Back-End-Diensten verknüpft ist, kann jeder Back-End-Dienst auf denselben benannten Port oder einen anderen benannten Port in der Instanzgruppe verweisen.

• Wir empfehlen, eine automatisch skalierte verwaltete Instanzgruppe nicht mehr als einem Back-End-Dienst hinzuzufügen. Dies kann zu einer unvorhersehbaren und unnötigen Skalierung der Instanzen in der Gruppe führen, insbesondere wenn Sie den Autoscaling-Messwert HTTP-Load-Balancing-Auslastung verwenden.

  • Dieses Szenario wird zwar nicht empfohlen, kann aber funktionieren, wenn der Autoscaling-Messwert entweder ein Messwert für die CPU-Auslastung oder für Cloud Monitoring ist, und nicht mit der Bereitstellungskapazität des Load-Balancers zusammenhängt. Die Verwendung eines dieser Autoscaling-Messwerte verhindert möglicherweise eine fehlerhafte Skalierung.

Zonale Netzwerk-Endpunktgruppen

Netzwerkendpunkte stellen Dienste gemäß ihrer IP-Adresse oder einer Kombination aus IP-Adresse und Port dar und verweisen nicht auf eine VM in einer Instanzgruppe. Eine Netzwerk-Endpunktgruppe (NEG) ist eine logische Gruppierung von Netzwerkendpunkten.

Zonale Netzwerk-Endpunktgruppen (NEGs) sind zonale Ressourcen, die Sammlungen von IP-Adressen oder IP-Adressen und Port-Kombinationen für Google Cloud-Ressourcen in einem einzelnen Subnetz darstellen.

Ein Backend-Dienst, der zonale NEGs als Backends verwendet, verteilt den Traffic auf Anwendungen oder Container, die innerhalb von VMs ausgeführt werden.

Für zonale NEGs sind zwei Arten von Netzwerkendpunkten verfügbar:

• GCE_VM_IP-Endpunkte (werden nur bei internen Passthrough-Network-Load-Balancern und Back-End-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt).
• GCE_VM_IP_PORT-Endpunkte

Informationen zu den Produkten, die zonale NEG-Backends unterstützen, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Weitere Informationen finden Sie unter Übersicht über zonale NEGs.

Internetnetzwerk-Endpunktgruppen

Internet-NEGs sind Ressourcen, die externe Back-Ends definieren. Ein externes Backend ist ein Backend, das in der lokalen Infrastruktur oder in der Infrastruktur von Drittanbietern gehostet wird.

Eine Internet-NEG ist eine Kombination aus einem Hostnamen oder einer IP-Adresse und einem optionalen Port. Für Internet-NEGs sind zwei Arten von Netzwerkendpunkten verfügbar: INTERNET_FQDN_PORT und INTERNET_IP_PORT.

Internet-NEGs sind in zwei Bereichen verfügbar: global und regional. Informationen zu den Produkten, die Internet-NEG-Backends in den einzelnen Bereichen unterstützen, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Weitere Informationen finden Sie unter Übersicht über Internetnetzwerk-Endpunktgruppen.

Serverlose Netzwerk-Endpunktgruppen

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Back-End-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Backend, das auf einen Cloud Run-, App Engine-, Cloud Run Functions- oder API Gateway-Dienst verweist.

Eine serverlose NEG kann für eine der folgenden Dinge stehen:

• Einen Cloud Run-Dienst oder eine Gruppe von Diensten.
• Eine Cloud Run Functions-Funktion oder eine Gruppe von Funktionen.
• Eine App Engine-Anwendung (Standard oder Flex), einen bestimmten Dienst innerhalb einer Anwendung, eine bestimmte Version einer Anwendung oder eine Gruppe von Diensten.
• Ein API Gateway, das Zugriff auf Ihre Dienste über eine REST API bietet, die über alle Dienste hinweg unabhängig von der Dienstimplementierung konsistent ist. Diese Funktion befindet sich in der Vorschau.

Wichtig: Damit sich eine Gruppe von Diensten in derselben serverlosen NEG befinden kann, müssen sie ein gemeinsames URL-Muster haben.

Verwenden Sie zum Einrichten einer serverlosen NEG für serverlose Anwendungen, die ein URL-Muster teilen, eine URL-Maske. Eine URL-Maske ist eine Vorlage Ihres URL-Schemas (z. B. example.com/<service>). Die serverlose NEG verwendet diese Vorlage, um den Namen <service> aus der URL der eingehenden Anfrage zu extrahieren und die Anfrage an den entsprechenden Cloud Run-, Cloud Run Functions- oder App Engine-Dienst mit demselben Namen weiterzuleiten.

Informationen dazu, welche Load-Balancer serverlose NEG-Backends unterstützen, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Weitere Informationen zu serverlosen NEGs finden Sie in der Übersicht über serverlose Netzwerk-Endpunktgruppen.

Dienstbindungen

Eine Dienstbindung ist ein Backend, das eine Verbindung zwischen einem Backend-Dienst in Cloud Service Mesh und einem in Service Directory registrierten Dienst herstellt. Ein Backend-Dienst kann auf mehrere Dienstbindungen verweisen. Ein Backend-Dienst mit einer Dienstbindung kann nicht auf einen anderen Backend-Typ verweisen.

Gemischte Back-Ends

Die folgenden Überlegungen zur Nutzung gelten, wenn Sie einem einzelnen Backend-Dienst verschiedene Arten von Backends hinzufügen:

• Ein einzelner Backend-Dienst kann nicht gleichzeitig Instanzgruppen und zonale NEGs verwenden.
• Sie können jedoch eine Kombination verschiedener Arten von Instanzgruppen für denselben Backend-Dienst verwenden. Beispielsweise kann ein einzelner Backend-Dienst auf eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen verweisen. Ausführliche Informationen dazu, welche Backends mit welchen Backend-Diensten kompatibel sind, finden Sie in der Tabelle im vorherigen Abschnitt.
• Mit bestimmten Proxy-Load-Balancern können Sie eine Kombination aus zonalen NEGs (mit GCE_VM_IP_PORT-Endpunkten) und Hybridkonnektivitäts-NEGs (mit NON_GCP_PRIVATE_IP_PORT-Endpunkten) verwenden, um Hybrid-Load-Balancing zu konfigurieren. Informationen dazu, welche Load-Balancer diese Funktion haben, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Protokoll für Back-Ends

Beim Erstellen eines Back-End-Diensts müssen Sie das Protokoll angeben, das für die Kommunikation mit den Back-Ends verwendet werden soll. Sie können nur ein Protokoll pro Back-End-Dienst angeben. Sie können kein sekundäres Protokoll angeben, das als Fallback verwendet werden soll.

Welche Protokolle gültig sind, hängt vom Typ des Load Balancers bzw. davon ab, ob Sie Cloud Service Mesh verwenden.

Tabelle: Protokoll für die Back-Ends

Produkt	Protokolloptionen für Backend-Dienste
Application Load Balancer	HTTP, HTTPS, HTTP/2
Proxy-Network Load Balancer	TCP oder SSL Regionale Proxy-Network Load Balancer unterstützen nur TCP.
Netzwerk Load Balancer (Passthrough)	TCP, UDP oder UNSPECIFIED
Cloud Service Mesh	HTTP, HTTPS, HTTP/2, gRPC, TCP

Durch das Ändern des Protokolls eines Back-End-Dienstes werden die Back-Ends für einige Minuten über Load-Balancer unerreichbar.

Richtlinie zur IP-Adressauswahl

Dieses Feld gilt für Proxy-Load Balancer. Sie müssen mit der Richtlinie zur IP-Adressauswahl den Traffictyp angeben, der vom Backend-Dienst an Ihre Backends gesendet wird.

Wenn Sie die Richtlinie zur IP-Adressauswahl auswählen, müssen Ihre Back-Ends den ausgewählten Traffictyp unterstützen. Weitere Informationen finden Sie in der Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Die Richtlinie zur IP-Adressauswahl wird verwendet, wenn Sie den Load Balancer-Backenddienst so konvertieren möchten, dass er einen anderen Traffictyp unterstützt. Weitere Informationen finden Sie unter Von Single-Stack in Dual-Stack konvertieren.

Sie können die folgenden Werte für die Richtlinie zur IP-Adressauswahl angeben:

Richtlinie zur IP-Adressauswahl	Beschreibung
Nur IPv4	Senden Sie nur IPv4-Traffic an die Backends des Backend-Dienstes, unabhängig vom Traffic vom Client zum GFE. Es werden nur IPv4-Systemdiagnosen verwendet, um den Status der Backends zu prüfen.
IPv6 bevorzugen	Priorisieren Sie die IPv6-Verbindung des Backends gegenüber der IPv4-Verbindung (sofern ein fehlerfreies Backend mit IPv6-Adressen vorhanden ist). Die Systemdiagnosen überwachen regelmäßig die IPv6- und IPv4-Verbindungen der Backends. Das GFE versucht zuerst die IPv6-Verbindung. Wenn die IPv6-Verbindung unterbrochen oder langsam ist, verwendet das GFE glückliche Augen, um ein Fallback auszuführen und eine Verbindung zu IPv4 herzustellen. Selbst wenn eine der IPv6- oder IPv4-Verbindungen fehlerhaft ist, wird das Backend weiterhin als fehlerfrei behandelt. Beide Verbindungen können vom GFE getestet werden, wobei letztendlich die Augenmerk sich entscheiden, welche sie verwenden möchten.
Nur IPv6	Senden Sie nur IPv6-Traffic an die Backends des Backend-Dienstes, unabhängig vom Traffic vom Client zum Proxy. Nur IPv6-Systemdiagnosen werden verwendet, um den Status der Backends zu prüfen. Es gibt keine Validierung, um zu prüfen, ob der Backend-Traffictyp mit der Richtlinie zur IP-Adressauswahl übereinstimmt. Wenn Sie beispielsweise nur IPv4-Back-Ends haben und Only IPv6 als Richtlinie zur IP-Adressauswahl auswählen, führt die Konfiguration zu fehlerhaften Back-Ends, da der Traffic diese Back-Ends nicht erreicht und der HTTP-Antwortcode 503 an die Clients zurückgegeben wird.

Verschlüsselung zwischen dem Load-Balancer und Back-Ends

Informationen zur Verschlüsselung zwischen dem Load-Balancer und den Back-Ends finden Sie unter Verschlüsselung der Back-Ends.

Traffic-Verteilung

Die Werte der folgenden Felder in der Ressource für Back-End-Dienste beeinflussen verschiedene Aspekte des Back-End-Verhaltens:

• Ein Balancing-Modus definiert, wie der Load-Balancer die Bereitschaft von Back-Ends für neue Anfragen oder Verbindungen misst.
• Eine Zielkapazität, die eine maximale Zielanzahl von Verbindungen, eine maximale Zielrate oder die maximale CPU-Zielauslastung definiert.
• Mit einem Kapazitätsskalierer wird die verfügbare Gesamtkapazität angepasst, ohne die Zielkapazität zu ändern.

Balancing-Modus

Der Balancing-Modus bestimmt, ob die Back-Ends eines Load Balancers oder eines Cloud Service Mesh zusätzlichen Traffic verarbeiten können oder vollständig geladen werden.

Google Cloud bietet drei Balancing-Modi:

• CONNECTION: Bestimmt, wie die Last basierend auf der Gesamtzahl der Verbindungen verteilt wird, die das Backend verarbeiten kann.
• RATE: Die maximale Anzahl von Anfragen (Abfragen) pro Sekunde (RPS, QPS). Der maximale RPS/QPS-Wert kann überschritten werden, wenn alle Back-Ends die Kapazität erreichen oder überschreiten.
• UTILIZATION: Bestimmt, wie die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt wird.

Für jeden Load-Balancer verfügbare Balancing-Modi

Sie legen den Balancing-Modus fest, wenn Sie dem Backend-Dienst ein Backend hinzufügen. Die für einen Load Balancer verfügbaren Balancing-Modi hängen vom Typ des Load Balancers und vom Typ der Back-Ends ab.

Passthrough-Network Load Balancer erfordern den Balancing-Modus CONNECTION, unterstützen jedoch keine Festlegung einer Zielkapazität.

Die Application Load Balancer unterstützen die Balancing-Modi RATE und UTILIZATION für Instanzgruppen-Back-Ends, den Balancing-Modus RATE für zonale NEGs mit GCE_VM_IP_PORT-Endpunkten. und RATE für die Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte). Bei allen anderen unterstützten Back-Ends muss der Balancing-Modus ausgelassen werden.

• Bei klassischen Application Load Balancern wird eine Region basierend auf dem Standort des Clients und der verfügbaren Kapazität basierend auf der Zielkapazität des Load-Balancing-Modus ausgewählt. Dann wird innerhalb einer Region die Zielkapazität des Balancing-Modus verwendet, um den Anteil der Anfragen zu berechnen, die an jedes Backend in der Region gesendet werden sollen. Anfragen oder Verbindungen werden dann nach dem Round-Robin-Verfahren auf Instanzen oder Endpunkte innerhalb des Back-Ends verteilt.

• Bei globalen externen Application Load Balancern wird eine Region basierend auf dem Standort des Clients und der verfügbaren Kapazität basierend auf der Zielkapazität des Load-Balancing-Modus ausgewählt. Innerhalb einer Region wird anhand der Zielkapazität des Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Sie können die Richtlinie für das Dienst-Load-Balancing (serviceLbPolicy) und die Einstellung bevorzugtes Backend verwenden, um die Auswahl bestimmter Backends innerhalb einer Region zu beeinflussen. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

• Bei regionenübergreifenden internen Application Load Balancern, regionalen externen Application Load Balancern und regionalen internen Application Load Balancern wird die Zielkapazität des Balancing-Modus verwendet, um die Anteile der Anfragen zu berechnen, die an jedes Backend (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird. Nur der regionale interne Application Load Balancer unterstützt die Verwendung der Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) und der bevorzugten Backend-Einstellungen, um die Auswahl von spezifischen Back-Ends innerhalb einer Region zu beeinflussen.

Die Proxy-Network Load Balancer unterstützen die Balancing-Modi CONNECTION und UTILIZATION für VM-Instanzgruppen-Back-Ends, den Balancing-Modus CONNECTION für zonale NEGs mit GCE_VM_IP_PORT-Endpunkten und CONNECTION-Balancing-Modus für Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte). Bei allen anderen unterstützten Back-Ends muss der Balancing-Modus ausgelassen werden.

• Bei globalen externen Proxy-Network-Load-Balancern wird eine Region basierend auf dem Standort des Clients und der verfügbaren Kapazität basierend auf der Zielkapazität des Load-Balancing-Modus ausgewählt. Innerhalb einer Region wird anhand der Zielkapazität des Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Sie können die Richtlinie für das Dienst-Load-Balancing (serviceLbPolicy) und die Einstellung bevorzugtes Backend verwenden, um die Auswahl bestimmter Backends innerhalb einer Region zu beeinflussen. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

• Für regionenübergreifende interne Proxy-Network Load Balancer wird zuerst die konfigurierte Region ausgewählt. Innerhalb einer Region wird anhand der Zielkapazität des Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Sie können die Richtlinie für das Dienst-Load-Balancing (serviceLbPolicy) und die Einstellung bevorzugtes Backend verwenden, um die Auswahl bestimmter Backends innerhalb einer Region zu beeinflussen. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

• Bei klassischen Proxy-Network-Load-Balancern wird eine Region basierend auf dem Standort des Clients und der verfügbaren Kapazität basierend auf der Zielkapazität des Load-Balancing-Modus ausgewählt. Anschließend wird innerhalb einer Region die Zielkapazität des Load-Balancing-Modus verwendet, um den Anteil der Anfragen und Verbindungen zu berechnen, die an jedes Backend (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Nachdem der Load-Balancer ein Backend ausgewählt hat, werden Anfragen oder Verbindungen anschließend in zufälliger Reihenfolge auf VM-Instanzen oder Netzwerkendpunkte innerhalb jedes einzelnen Backends verteilt.

• Bei regionalen externen Proxy-Netzwerk-Load-Balancern und regionalen internen Proxy-Network-Load-Balancern wird anhand der Zielkapazität des Load-Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends (Instanzgruppe oder NEG) gesendet werden. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (localityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

In der folgenden Tabelle sind die für jede Kombination aus Load-Balancer und Backend verfügbaren Load-Balancing-Modi zusammengefasst.

Tabelle: Für jeden Load-Balancer verfügbare Balancing-Modi

Load-Balancer	Back-Ends	Verfügbare Balancing-Modi
Application Load Balancer	Instanzgruppen	RATE oder UTILIZATION
	Zonale NEGs (GCE_VM_IP_PORT-Endpunkte)	RATE
	Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte)	RATE
Proxy-Network Load Balancer Globaler externer Proxy-Network Load Balancer Klassischer Proxy-Network Load Balancer Regionaler externer Proxy-Network Load Balancer Regionaler interner Proxy-Network Load Balancer Regionsübergreifender interner Proxy-Network Load Balancer	Instanzgruppen	CONNECTION oder UTILIZATION
	Zonale NEGs (GCE_VM_IP_PORT-Endpunkte)	CONNECTION
	Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte)	CONNECTION
Netzwerk Load Balancer (Passthrough)	Instanzgruppen	CONNECTION
	Zonale NEGs (GCE_VM_IP-Endpunkte)	CONNECTION

Hinweis:

Wenn Sie bei Verwendung des Balancing-Modus UTILIZATION eine schlechte Verteilung des Traffics feststellen, empfehlen wir stattdessen RATE.

Der Balancing-Modus UTILIZATION hängt neben anderen Faktoren von der VM-Instanz oder CPU-Auslastung ab. Wenn diese Faktoren schwanken, berechnet der Load Balancer die Kapazitäten ineffektiv, was häufig zu einer schlechten Verteilung des Traffics zwischen den Backendgruppen führt. Im Gegensatz dazu sendet der Load-Balancer für den Balancing-Modus RATE Anfragen an die Back-End-Gruppe mit der geringsten durchschnittlichen Latenz über die letzten Anfragen oder für HTTP/2 und HTTP/3 werden Anfragen an die Back-End-Gruppe mit den wenigsten ausstehenden Anfragen gesendet.

Wenn die durchschnittliche Auslastung aller VMs, die mit einem Back-End-Dienst verknüpft sind, unter 10 % liegt, bevorzugt Google Cloud möglicherweise bestimmte Zonen. Dies kann passieren, wenn Sie regionale verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen in verschiedenen Zonen und zonale nicht verwaltete Instanzgruppen verwenden. Dieses zonale Ungleichgewicht wird automatisch aufgelöst, wenn mehr Traffic an den Load-Balancer gesendet wird.

Weitere Informationen finden Sie unter gcloud compute backend-services add-backend.

Zielkapazität

Jeder Load-Balancing-Modus verfügt über eine entsprechende Zielkapazität, die einen der folgenden Zielwerte definiert:

• Anzahl Verbindungen
• Rate
• CPU-Auslastung

Für jeden Balancing-Modus ist die Zielkapazität kein Schutzschalter. Ein Load-Balancer kann das Maximum unter bestimmten Bedingungen überschreiten, z. B. wenn alle Back-End-VMs oder Endpunkte das Maximum erreicht haben.

Verbindungsmodus für Verbindungen

Im CONNECTION-Balancing-Modus definiert die Zielkapazität eine maximale Zielanzahl offener Verbindungen. Mit Ausnahme der internen Passthrough-Network-Load-Balancer und externen Passthrough-Network-Load-Balancer müssen Sie eine der folgenden Einstellungen verwenden, um eine maximale Anzahl von Verbindungen festzulegen:

• max-connections-per-instance (pro VM): Durchschnittliche Anzahl von Verbindungen für eine einzelne VM.
• max-connections-per-endpoint (pro Endpunkt in einer zonalen NEG): Die durchschnittliche Anzahl der Verbindungen für einen einzelnen Endpunkt.
• max-connections (pro zonale NEGs und für zonale Instanzgruppen): Ziel der durchschnittlichen Anzahl von Verbindungen für die gesamte NEG oder Instanzgruppe. Verwenden Sie für regional verwaltete Instanzgruppen stattdessen max-connections-per-instance.

In der folgenden Tabelle wird gezeigt, wie mit dem Parameter für die Zielkapazität Folgendes definiert wird:

• Die Zielkapazität für das gesamte Back-End
• Die erwartete Zielkapazität für jede Instanz oder jeden Endpunkt

Tabelle: Zielkapazität für Back-Ends mit dem Balancing-Modus CONNECTION

Backend-Typ	Zielkapazität
	Wenn Sie Folgendes festlegen:	Gesamte Back-End-Kapazität	Voraussichtlich pro Instanz oder pro Endpunktkapazität
Instanzgruppe N Instanzen, H fehlerfrei	max-connections-per-instance=X	X × N	(X × N)/H
Zonale NEG N-Endpunkte, H fehlerfrei	max-connections-per-endpoint=X	X × N	(X × N)/H
Instanzgruppen (außer regionale verwaltete Instanzgruppen) H fehlerfreie Instanzen	max-connections=Y	Y	Y/H

Wie dargestellt, sind die Einstellungen max-connections-per-instance und max-connections-per-endpoint Proxys für die Berechnung einer angestrebten maximalen Anzahl von Verbindungen für die gesamte VM-Instanzgruppe oder das gesamte zonale NEG:

• In einer VM-Instanzgruppe mit N-Instanzen hat die Einstellung von max-connections-per-instance=X dieselbe Bedeutung wie die Einstellung von max-connections=X × N.
• In einer zonalen NEG mit N-Endpunkten hat die Einstellung von max-connections-per-endpoint=X dieselbe Bedeutung wie die Einstellung von max-connections=X × N.

Load-Balancing-Modus

Für den Balancing-Modus RATE müssen Sie die Zielkapazität mit einem der folgenden Parameter definieren:

• max-rate-per-instance (pro VM): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für eine einzelne VM an.
• max-rate-per-endpoint (pro Endpunkt in einer zonalen NEG): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für einen einzelnen Endpunkt an.
• max-rate (pro zonale NEGs und für zonale Instanzgruppen): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für die gesamte NEG oder Instanzgruppe an. Verwenden Sie für regional verwaltete Instanzgruppen stattdessen max-rate-per-instance.

In der folgenden Tabelle wird gezeigt, wie mit dem Parameter für die Zielkapazität Folgendes definiert wird:

• Die Zielkapazität für das gesamte Back-End
• Die erwartete Zielkapazität für jede Instanz oder jeden Endpunkt

Tabelle: Zielkapazität für Back-Ends mit dem Balancing-Modus RATE

Backend-Typ	Zielkapazität
	Wenn Sie Folgendes festlegen:	Gesamte Back-End-Kapazität	Voraussichtlich pro Instanz oder pro Endpunktkapazität
Instanzgruppe N Instanzen, H fehlerfrei	max-rate-per-instance=X	X × N	(X × N)/H
Zonale NEG N-Endpunkte, H fehlerfrei	max-rate-per-endpoint=X	X × N	(X × N)/H
Instanzgruppen (außer regionale verwaltete Instanzgruppen) H fehlerfreie Instanzen	max-rate=Y	Y	Y/H

Wie dargestellt, sind die Einstellungen max-rate-per-instance und max-rate-per-endpoint Proxys für die Berechnung einer maximalen Zielrate von HTTP-Anfragen für die gesamte Instanzgruppe oder die gesamte zonale NEG:

• In einer Instanzgruppe mit N-Instanzen hat die Einstellung von max-rate-per-instance=X dieselbe Bedeutung wie die Einstellung von max-rate=X × N.
• In einer zonalen NEG mit N-Endpunkten hat die Einstellung von max-rate-per-endpoint=X dieselbe Bedeutung wie die Einstellung von max-rate=X × N.

Balancing-Modus „Auslastung”

Der Balancing-Modus UTILIZATION hat keine erforderliche Zielkapazität. Sie haben eine Reihe von Optionen, die vom Backend-Typ abhängig sind, wie in der Tabelle im folgenden Abschnitt zusammengefasst.

Die Zielkapazität max-utilization kann nur pro Instanzgruppe angegeben und nicht auf eine bestimmte VM in der Gruppe angewendet werden.

Der Balancing-Modus UTILIZATION hat keine erforderliche Zielkapazität. Wenn Sie die Google Cloud Console verwenden, um einem Backend-Dienst eine Backend-Instanzgruppe hinzuzufügen, legt die Google Cloud Console den Wert von max-utilization auf 0,8 (80 %) fest, wenn der UTILIZATION-Balancing-Modus ausgewählt ist. Zusätzlich zu max-utilization unterstützt der UTILIZATION-Balancing-Modus komplexere Zielkapazitäten, wie in der Tabelle im folgenden Abschnitt zusammengefasst.

Loading-Modus eines Load-Balancers ändern

Bei einigen Load-Balancern oder Load-Balancer-Konfigurationen können Sie den Balancing-Modus nicht ändern, da der Backend-Dienst nur einen möglichen Balancing-Modus hat. Bei anderen ist es jedoch möglich, den Balancing-Modus zu ändern, da diesen Backend-Diensten je nach verwendetem Backend mehrere Modi zur Verfügung stehen.

Informationen dazu, welche Balancing-Modi für jeden Load-Balancer unterstützt werden, finden Sie in der Tabelle: Für jeden Load-Balancer verfügbare Balancing-Modi.

Balancing-Modi und Einstellungen für die Zielkapazität

Bei Produkten, die eine Zielkapazitätsspezifikation unterstützen, ist die Zielkapazität kein Schutzschalter. Wenn die konfigurierte maximale Zielkapazität in einer bestimmten Zone erreicht ist, werden neue Anfragen oder Verbindungen an andere Zonen verteilt, in denen Anfragen oder Verbindungen nicht mit der Zielkapazität verarbeitet werden. Wenn alle Zonen die Zielkapazität erreicht haben, werden neue Anfragen oder Verbindungen durch Überfüllung verteilt.

Application Load Balancer und Cloud Service Mesh

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Application Load Balancer und Cloud Service Mesh aufgeführt.

Tabelle: Kombinationen aus Balancing-Modus und Zielkapazität für Application Load Balancer und Cloud Service Mesh

Backend-Typ	Balancing-Modus	Spezifikation der Zielkapazität
Instanzgruppen zonal nicht verwaltet zonal verwaltet regional verwaltet	RATE	Sie müssen eine der folgenden Optionen angeben: max-rate  (nur von zonalen Instanzgruppen unterstützt) max-rate-per-instance  (von allen Instanzgruppen unterstützt)
	UTILIZATION	Sie können optional eine der folgenden Optionen angeben: (1) max-utilization (2) max-rate  (nur von zonalen Instanzgruppen unterstützt) (3) max-rate-per-instance  (von allen Instanzgruppen unterstützt) (1) und (2) zusammen (1) und (3) zusammen
Zonale NEGs GCP_VM_IP_PORT Hybrid-NEGs NON_GCP_PRIVATE_IP_PORT	RATE	Sie müssen eine der folgenden Optionen angeben: max-rate pro zonale NEG max-rate-per-endpoint

Proxy-Network-Load-Balancer

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Proxy-Network Load Balancer aufgeführt.

Tabelle: Kombinationen aus Balancing-Modus und Zielkapazität für Proxy-Network-Load Balancer

Backend-Typ	Balancing-Modus	Spezifikation der Zielkapazität
Instanzgruppen zonal nicht verwaltet zonal verwaltet regional verwaltet	CONNECTION	Sie müssen eine der folgenden Optionen angeben: max-connections  (nur von zonalen Instanzgruppen unterstützt) max-rate-per-instance  (von allen Instanzgruppen unterstützt)
	UTILIZATION	Sie können optional eine der folgenden Optionen angeben: (1) max-utilization (2) max-connections  (nur von zonalen Instanzgruppen unterstützt) (3) max-connections-per-instance  (von allen Instanzgruppen unterstützt) (1) und (2) zusammen (1) und (3) zusammen
Zonale NEGs GCP_VM_IP_PORT Hybrid-NEGs NON_GCP_PRIVATE_IP_PORT	CONNECTION	Sie müssen eine der folgenden Optionen angeben: max-connections pro zonale NEG max-connections-per-endpoint

Passthrough-Network-Load-Balancer

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Passthrough-Network Load Balancer aufgeführt.

Tabelle: Kombinationen aus Balancing-Modus und Zielkapazität für Passthrough-Network Load Balancer

Backend-Typ	Balancing-Modus	Spezifikation der Zielkapazität
Instanzgruppen zonal nicht verwaltet zonal verwaltet regional verwaltet	CONNECTION	Sie können keine maximale Anzahl von Verbindungen angeben.
Zonale NEGs GCP_VM_IP	CONNECTION	Sie können keine maximale Anzahl von Verbindungen angeben.

Kapazitätsskalierer

Mit dem Kapazitätsskalierer können Sie die Zielkapazität (maximale Auslastung, maximale Rate oder maximale Verbindungen) skalieren, ohne dabei die Zielkapazität zu ändern.

Hier finden Sie die Google Cloud-Referenzdokumentation:

• Google Cloud CLI: Kapazitätsskalierer
• API:
  • Regional
  • Global

Sie können den Kapazitätsskalierer anpassen, um die effektive Zielkapazität zu skalieren, ohne einen der --max-*-Parameter explizit zu ändern.

Sie können den Kapazitätsskalierer auf einen dieser Werte setzen:

• Der Standardwert ist 1. Das bedeutet, dass die Gruppe bis zu 100 % der konfigurierten Kapazität bereitstellt (je nach balancingMode).
• Der Wert 0 bedeutet, dass die Gruppe vollständig per Drain beendet wurde. Sie bietet 0 % der verfügbaren Kapazität. Sie können die Einstellung 0 nicht konfigurieren, wenn nur ein Backend mit dem Backend-Dienst verbunden ist.
• Ein Wert zwischen 0.1 (10 %) to 1.0 (100 %).

Die folgenden Beispiele veranschaulichen, wie der Kapazitätsskalierer in Verbindung mit der Einstellung der Zielkapazität funktioniert.

• Wenn der Balancing-Modus RATE lautet, die max-rate auf 80 RPS festgelegt und der Kapazitätsskalierer 1.0 ist, dann ist die verfügbare Kapazität auch 80 RPS.

• Wenn der Balancing-Modus RATE lautet, ist max-rate auf 80 RPS festgelegt und der Kapazitätsskalierer ist 0.5, die verfügbare Kapazität ist 40 RPS (0.5 times 80).

• Wenn der Balancing-Modus RATE ist, diemax-rate auf 80 RPS festgelegt ist und der Kapazitätsskalierer 0.0 ist, dann ist die verfügbare Kapazität null (0).

Hinweis: Der Kapazitätsskalierer wird nicht für Back-Ends unterstützt, die keinen Balancing-Modus unterstützen. Dazu gehören Back-Ends wie Internet-NEGs, serverlose NEGs und PSC-NEGs.

Load-Balancing-Richtlinie für Dienste

Eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) ist eine Ressource, die dem Backend-Dienst des Load Balancers zugeordnet ist. Sie können damit die Parameter anpassen, die beeinflussen, wie der Traffic innerhalb der Backends verteilt wird, die einem Backend-Dienst zugeordnet sind:

• Passen Sie den Load-Balancing-Algorithmus an, der verwendet wird, um zu bestimmen, wie Traffic auf Regionen oder Zonen verteilt wird.
• Aktivieren Sie den automatischen Kapazitätsausgleich, damit der Load Balancer Traffic von fehlerhaften Back-Ends schnell leeren kann.

Außerdem können Sie bestimmte Back-Ends als bevorzugte Back-Ends festlegen. Diese Back-Ends müssen für die Kapazität verwendet werden (d. h. die Zielkapazität, die vom Balancing-Modus des Back-Ends angegeben wird), bevor Anfragen an die verbleibenden Back-Ends gesendet werden.

Weitere Informationen finden Sie unter Erweiterte Load Balancing-Optimierungen mit einer Richtlinie für das Dienst-Load Balancing.

Load-Balancing-Richtlinie für den Ort

Bei einem Backend-Dienst beruht die Trafficverteilung auf dem Balancing-Modus und einer Load-Balancing-Richtlinie für den Ort. Der Balancing-Modus bestimmt den Anteil des Traffics, der an jedes Backend (Instanzgruppe oder -NEG) gesendet werden soll. Die Load Balancing-Richtlinie für den Ort (LocalityLbPolicy) bestimmt dann, wie der Traffic auf Instanzen oder Endpunkte innerhalb jeder Zone verteilt wird. Bei regional verwalteten Instanzgruppen gilt die Richtlinie für den Ort für jede einzelne Zone.

Die Load-Balancing-Richtlinie für den Ort wird pro Backend-Dienst konfiguriert. Diese Einstellungen sind verfügbar:

• ROUND_ROBIN (Standardeinstellung): Dies ist die Standardeinstellung der Load-Balancing-Richtlinie für den Ort, bei der der Load Balancer ein fehlerfreies Back-End in Round-Robin-Reihenfolge auswählt.

• LEAST_REQUEST: Ein O(1)-Algorithmus, bei dem der Load Balancer zwei zufällige intakte Hosts und den Host mit weniger aktiven Anfragen auswählt.

• RING_HASH: Dieser Algorithmus implementiert eine konsistente Hash-Funktion für Backends. Der Algorithmus hat die Eigenschaft, dass das Hinzufügen oder Entfernen eines Hosts aus einem Set von N Hosts sich nur auf 1/N der Anfragen auswirkt.

• RANDOM: Der Load-Balancer wählt einen zufälligen intakten Host aus.

• ORIGINAL_DESTINATION: Der Load Balancer wählt ein Backend basierend auf den Metadaten der Clientverbindung aus. Verbindungen werden zur ursprünglichen Ziel-IP-Adresse geöffnet, die in der eingehenden Clientanfrage angegeben ist, bevor die Anfrage an den Load Balancer weitergeleitet wurde.

  ORIGINAL_DESTINATION wird für globale und regionale externe Application Load Balancer nicht unterstützt.

• MAGLEV: Implementiert konsistente Hashfunktion für Backends und kann als Ersatz für die RING_HASH-Richtlinie verwendet werden. Maglev ist nicht so stabil wie RING_HASH, bietet aber schnellere Build-Zeiten von Nachschlagetabellen und Host-Auswahlzeiten. Weitere Informationen zu Maglev finden Sie im Maglev-Whitepaper.

• WEIGHTED_MAGLEV: Implementiert gewichtetes Load Balancing pro Instanz anhand von Gewichtungen, die von Systemdiagnosen gemeldet werden. Wenn diese Richtlinie verwendet wird, muss der Backend-Dienst eine Nicht-Legacy-HTTP-basierte Systemdiagnose konfigurieren. Die Systemdiagnoseantworten müssen das nicht standardmäßige HTTP-Antwortheader-Feld X-Load-Balancing-Endpoint-Weight enthalten, um die Gewichtungen pro Instanz anzugeben. Load Balancing-Entscheidungen werden basierend auf den pro Instanz in den letzten verarbeiteten Systemdiagnoseantworten gemeldeten Gewichten getroffen, sofern jede Instanz ein gültiges Gewicht oder UNAVAILABLE_WEIGHT meldet. Andernfalls bleibt das Load Balancing gleichgewichtig.

  WEIGHTED_MAGLEV wird nur für externe Passthrough-Network-Load-Balancer unterstützt. Ein Beispiel finden Sie unter Gewichtetes Load Balancing für externe Passthrough-Network Load Balancer einrichten.

Das Konfigurieren einer Load Balancing-Richtlinie für den Ort wird nur für Backend-Dienste unterstützt, die mit den folgenden Load Balancern verwendet werden:

• Globaler externer Application Load Balancer
• Regionaler externer Application Load Balancer
• Regionsübergreifender interner Application Load Balancer
• Regionaler interner Application Load Balancer
• Externer Passthrough-Network Load Balancer

Der effektive Standardwert der Load Balancing-Richtlinie für den Ort (localityLbPolicy) ändert sich entsprechend den Einstellungen für die Sitzungsaffinität. Wenn die Sitzungsaffinität nicht konfiguriert ist, d. h., wenn die Sitzungsaffinität den Standardwert NONE beibehält, ist ROUND_ROBIN der Standardwert für localityLbPolicy. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist MAGLEV der Standardwert für localityLbPolicy.

Sie können eine Load Balancing-Richtlinie für den Ort mit der Google Cloud Console, gcloud (--locality-lb-policy) oder der API (localityLbPolicy) konfigurieren.

Cloud Service Mesh und Verteilung des Traffics

Cloud Service Mesh verwendet auch Back-End-Dienst-Ressourcen. Insbesondere nutzt Cloud Service Mesh Back-End-Dienste mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED. Bei einem internen, selbstverwalteten Back-End-Dienst beruht die Trafficverteilung auf der Kombination aus einem Load-Balancing-Modus und einer Load-Balancing-Richtlinie. Der Back-End-Dienst leitet Traffic an ein Back-End gemäß dem Load-Balancing-Modus des Back-Ends weiter. Dann verteilt Cloud Service Mesh den Traffic gemäß einer Load-Balancing-Richtlinie.

Interne selbstverwaltete Back-End-Dienste unterstützen die folgenden Balancing-Modi:

• UTILIZATION, wenn alle Back-Ends Instanzgruppen sind
• RATE, wenn alle Back-Ends entweder Instanzgruppen oder zonale NEGs sind

Wenn Sie den Balancing-Modus RATE wählen, müssen Sie eine maximale Rate, eine maximale Rate pro Instanz oder eine maximale Rate pro Endpunkt angeben.

Weitere Informationen zu Cloud Service Mesh finden Sie unter Cloud Service Mesh-Konzepte.

Backend-Teilmengeneinstellung

Die Backend-Teileinstellung ist eine optionale Funktion, die die Leistung und Skalierbarkeit verbessert, indem jeder der Proxyinstanzen eine Teilmenge der Backends zugewiesen wird.

Die Backend-Teileinstellung wird für Folgendes unterstützt:

• Regionaler interner Application Load Balancer
• Interner Passthrough-Network Load Balancer

Backend-Teileinstellung für regionale interne Application Load Balancer

Vorschau

Dieses Produkt oder diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und -Funktionen sind unverändert verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Der regionenübergreifende interne Application Load Balancer unterstützt die Backend-Teilmengeneinstellung nicht.

Bei regionalen internen Application Load Balancern weist die Backend-Teilmengeneinstellung jeder Proxy-Instanz automatisch nur eine Teilmenge der Backends im regionalen Backend-Dienst zu. Standardmäßig öffnet jede Proxy-Instanz Verbindungen zu allen Backends innerhalb eines Backend-Dienstes. Wenn die Anzahl der Proxy-Instanzen und der Back-Ends beide offene Verbindungen zu allen Back-Ends haben, kann dies zu Leistungsproblemen führen.

Durch Aktivieren der Teileinstellung öffnet jeder Proxy nur Verbindungen zu einer Teilmenge der Backends, wodurch die Anzahl der Verbindungen reduziert wird, die für jedes Backend offen sind. Wenn Sie die Anzahl der gleichzeitig offenen Verbindungen zu jedem Backend reduzieren, kann die Leistung sowohl für die Backends als auch für die Proxys verbessert werden.

Das folgende Diagramm zeigt einen Load-Balancer mit zwei Proxys. Ohne Backend-Teilmenge wird der Traffic von beiden Proxys auf alle Backends im Backend-Dienst 1 verteilt. Wenn die Backend-Teileinstellung aktiviert ist, wird der Traffic von jedem Proxy auf eine Teilmenge der Backends verteilt. Traffic von Proxy 1 wird an die Backends 1 und 2 verteilt und Traffic von Proxy 2 an Backend 3 und 4 verteilt.

Comparing internal Application Load Balancer without and with backend subsetting (click to enlarge).

Sie können den Load-Balancing-Traffic zu den Back-Ends zusätzlich optimieren, indem Sie die Richtlinie localityLbPolicy festlegen. Weitere Informationen finden Sie unter Trafficrichtlinien.

Informationen zum Einrichten der Backend-Teilmengeneinstellung für interne Application Load Balancer finden Sie unter Backend-Teilmengeneinstellung konfigurieren.

Einschränkungen im Zusammenhang mit der Backend-Teilmengeneinstellung für den internen Application Load Balancer

• Die Backend-Teilmengeneinstellung ist zwar so konzipiert, dass alle Backend-Instanzen weiterhin gut ausgelastet sind, sie kann aber zu einer gewissen Verzerrung des Trafficvolumens führen, das jedes Backend erhält. Das Festlegen von localityLbPolicy auf LEAST_REQUEST wird für Backend-Dienste empfohlen, die empfindlich auf die Balance der Backend-Last reagieren.
• Durch Aktivieren oder Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
• Die Backend-Teileinstellung erfordert, dass die Sitzungsaffinität NONE ist (ein 5-Tupel-Hash). Andere Optionen für die Sitzungsaffinität können nur verwendet werden, wenn die Backend-Teilmengeneinstellung deaktiviert ist. Die Standardwerte der Flags --subsetting-policy und --session-affinity sind beide NONE und können jeweils nur auf einen anderen Wert festgelegt werden.

Backend-Teilmengeneinstellung für internen Passthrough-Network-Load-Balancer

Die Backend-Teilmengeneinstellung für den internen Passthrough-Network-Load-Balancer ermöglicht es Ihnen, Ihren internen Passthrough-Network-Load-Balancer zu skalieren, um eine größere Anzahl von Backend-VM-Instanzen pro internem Backend-Dienst zu unterstützen.

Informationen dazu, wie sich diese Einstellung auf dieses Limit auswirkt, finden Sie im Abschnitt „Backend-Dienste“ unter Ressourcenquoten und Limits für Load-Balancing.

Die Teilmengeneinstellung ist standardmäßig deaktiviert, wodurch die Verteilung des Back-End-Dienstes auf maximal 250 Back-End-Instanzen oder Endpunkte begrenzt ist. Wenn der Back-End-Dienst mehr als 250 Back-Ends unterstützen soll, können Sie die Teilmengeneinstellung aktivieren. Wenn die Teilmengeneinstellung aktiviert ist, wird für jede Clientverbindung eine Teilmenge von Back-End-Instanzen ausgewählt.

Das folgende Diagramm zeigt ein skaliertes Modell des Unterschieds zwischen diesen beiden Betriebsmodi.

Internen Passthrough-Network Load Balancer ohne und mit Teilmengeneinstellung vergleichen (zum Vergrößern anklicken).

Ohne die Teilmengeneinstellung ist der gesamte Satz fehlerfreier Back-Ends besser genutzt und neue Clientverbindungen werden gemäß der Traffic-Verteilung auf alle fehlerfreien Back-Ends verteilt. Teilmengeneinstellung setzt Load-Balancing-Einschränkungen ein, ermöglicht dem Load-Balancer jedoch, mehr als 250 Back-Ends zu unterstützen.

Eine Konfigurationsanleitung finden Sie unter Teilmengeneinstellung.

Einschränkungen im Zusammenhang mit der Backend-Teilmengeneinstellung für den internen Passthrough-Network-Load-Balancer

• Wenn die Teilmengeneinstellung aktiviert ist, erhalten nicht alle Back-Ends Traffic von einem bestimmten Absender, auch wenn die Anzahl der Back-Ends gering ist.
• Die maximale Anzahl von Backend-Instanzen, wenn die Teilmengeneinstellung aktiviert ist, finden Sie auf der Seite "Kontingente".
• Für die Teilmengeneinstellung wird nur 5-Tupel-Sitzungsaffinität unterstützt.
• Die Paketspiegelung wird bei der Teilmengeneinstellung nicht unterstützt.
• Durch Aktivieren oder Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
• Wenn lokale Clients auf einen internen Passthrough-Network-Load-Balancer zugreifen müssen, kann die Teilmengeneinstellung die Anzahl der Back-Ends, die Verbindungen von Ihren lokalen Clients erhalten, erheblich reduzieren. Dies liegt daran, dass die Region des Cloud VPN-Tunnels oder des Cloud Interconnect-VLAN-Anhangs die Teilmenge der Back-Ends des Load-Balancers bestimmt. Alle Cloud VPN- und Cloud Interconnect-Endpunkte in einer bestimmten Region verwenden dieselbe Teilmenge. Unterschiedliche Teilmengen werden in unterschiedlichen Regionen verwendet.

Preise für Backend-Teilmengen

Für die Verwendung der Backend-Teileinstellung fallen keine Kosten an. Weitere Informationen finden Sie unter Alle Netzwerkpreise.

Sitzungsaffinität

Mit der Sitzungsaffinität können Sie steuern, wie der Load-Balancer Back-Ends für neue Verbindungen auf vorhersehbare Weise auswählt, solange die Anzahl der fehlerfreien Back-Ends konstant bleibt. Dies ist nützlich für Anwendungen, bei denen mehrere Anfragen eines bestimmten Nutzers an dasselbe Backend oder denselben Endpunkt weitergeleitet werden müssen. Zu diesen Anwendungen gehören in der Regel zustandsorientierte Server, die von der Anzeigenbereitstellung, Spielen oder Diensten mit hohem internen Caching verwendet werden.

Google Cloud-Load-Balancer bieten Sitzungsaffinität auf Best-Effort-Basis. Faktoren wie das Ändern des Status der Backend-Systemdiagnose, das Hinzufügen oder Entfernen von Backends, Änderungen an den Backend-Gewichten (einschließlich Aktivierung oder Deaktivierung des gewichteten Load Balancings) oder Änderungen an der Backend-Auslastung, entsprechend der Messung durch den Balancing-Modus, können die Sitzungsaffinität beeinträchtigen.

Das Load Balancing mit Sitzungsaffinität funktioniert gut, wenn die Verteilung einmaliger Verbindungen angemessen groß ist. Ein angemessen großer Wert bedeutet mindestens ein Vielfaches der Anzahl der Back-Ends. Das Testen eines Load-Balancers mit einer kleinen Anzahl von Verbindungen ermöglicht keine genaue Darstellung der Verteilung von Clientverbindungen zwischen Back-Ends.

Standardmäßig wählen alle Google Cloud-Load-Balancer die Back-Ends mithilfe eines 5-Tupel-Hash-Werts (--session-affinity=NONE) aus:

• Quell-IP-Adresse des Pakets
• Quellport des Pakets (falls im Header des Pakets vorhanden)
• Ziel-IP-Adresse des Pakets
• Zielport des Pakets (falls im Header des Pakets vorhanden)
• Protokoll des Pakets

Bei Passthrough-Load-Balancern werden neue Verbindungen an fehlerfreie Backend-Instanzen oder -Endpunkte (im aktiven Pool, wenn eine Failover-Richtlinie konfiguriert ist) verteilt. Sie können Folgendes steuern:

• Gibt an, ob bestehende Verbindungen auf fehlerhaften Back-Ends bestehen bleiben. Weitere Informationen finden Sie unter Beibehaltung einer Verbindung bei fehlerhaften Backends in der Dokumentation zum internen Passthrough-Network-Load-Balancer und Beibehaltung einer Verbindung bei fehlerhaften Backends in der Dokumentation zu Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern.
• Ob bestehende Verbindungen während eines Failovers und Failbacks beibehalten werden, wenn eine Failover-Richtlinie konfiguriert ist. Weitere Informationen finden Sie unter Beibehaltung einer Verbindung bei Failover und Failback in der Dokumentation zum internen Passthrough-Network-Load-Balancer und unter Verbindungsausgleich bei Failover und Failback in der Dokumentation zu Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern.
• Wie lange bestehende Verbindungen bestehen bleiben können, wenn ein Backend aus dem Load-Balancer entfernt wird. Weitere Informationen finden Sie unter Verbindungsausgleich aktivieren.

Für proxybasierte Load-Balancer: Sofern die Anzahl der fehlerfreien Backend-Instanzen oder -Endpunkte konstant bleibt und die zuvor ausgewählte Backend-Instanz bzw. der Endpunkt nicht ausgelastet ist, werden nachfolgende Anfragen oder Verbindungen an dieselbe Backend-VM bzw. denselben Endpunkt weitergeleitet. Die Zielkapazität des Balancing-Modus bestimmt, wann das Backend ausgelastet ist.

Die folgende Tabelle zeigt die für jedes Produkt unterstützten Optionen für die Sitzungsaffinität:

Tabelle: Unterstützte Einstellungen für die Sitzungsaffinität

Produkt	Optionen der Sitzungsaffinität
Globaler externer Application Load Balancer Regionaler externer Application Load Balancer	Keine (NONE) Client-IP (CLIENT_IP) Generiertes Cookie (GENERATED_COOKIE) Header-Feld (HEADER_FIELD) HTTP-Cookie (HTTP_COOKIE) Zustandsorientierte cookiebasierte Affinität (STRONG_COOKIE_AFFINITY) Beachten Sie außerdem Folgendes: Der effektive Standardwert der Load-Balancing-Ort-Richtlinie (localityLbPolicy) ändert sich entsprechend den Einstellungen für die Sitzungsaffinität. Wenn die Sitzungsaffinität nicht konfiguriert ist, d. h., wenn die Sitzungsaffinität auf dem Standardwert NONE bleibt, ist ROUND_ROBIN der Standardwert für localityLbPolicy. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist MAGLEV der Standardwert für localityLbPolicy. Konfigurieren Sie keine Sitzungsaffinität für den globalen externen Application Load Balancer, wenn Sie die gewichtete Trafficaufteilung verwenden. In diesem Fall hat die Konfiguration der gewichteten Trafficaufteilung Vorrang.
Klassischer Application Load Balancer	Keine (NONE) Client-IP (CLIENT_IP) Generiertes Cookie (GENERATED_COOKIE)
Regionenübergreifender interner Application Load Balancer Regionaler interner Application Load Balancer	Keine (NONE) Client-IP (CLIENT_IP) Generiertes Cookie (GENERATED_COOKIE) Header-Feld (HEADER_FIELD) HTTP-Cookie (HTTP_COOKIE) Zustandsorientierte cookiebasierte Affinität (STRONG_COOKIE_AFFINITY) Beachten Sie außerdem Folgendes: Der effektive Standardwert der Load-Balancing-Ort-Richtlinie (localityLbPolicy) ändert sich entsprechend den Einstellungen für die Sitzungsaffinität. Wenn die Sitzungsaffinität nicht konfiguriert ist, d. h., wenn die Sitzungsaffinität auf dem Standardwert NONE bleibt, ist ROUND_ROBIN der Standardwert für localityLbPolicy. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist MAGLEV der Standardwert für localityLbPolicy. Konfigurieren Sie keine Sitzungsaffinität für den internen Application Load Balancer, wenn Sie die gewichtete Trafficaufteilung verwenden. In diesem Fall hat die Konfiguration der gewichteten Trafficaufteilung Vorrang.
Interner Passthrough-Network-Load-Balancer	Keine (NONE) CLIENT IP, kein Ziel (CLIENT_IP_NO_DESTINATION) Client-IP, Ziel-IP (CLIENT_IP) Client-IP, Ziel-IP, Protokoll (CLIENT_IP_PROTO) Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (CLIENT_IP_PORT_PROTO) Spezifische Informationen zum internen Passthrough-Network-Load-Balancer und zur Sitzungsaffinität finden Sie in der Übersicht über den internen Passthrough-Network-Load-Balancer.
Externer Passthrough-Network Load Balancer^*	Keine (NONE) Client-IP, Ziel-IP (CLIENT_IP) Client-IP, Ziel-IP, Protokoll (CLIENT_IP_PROTO) Client-IP, Client-Port, Ziel-IP, Zielport, Protokoll (CLIENT_IP_PORT_PROTO) Spezifische Informationen zum externen Passthrough-Network-Load-Balancer und zur Sitzungsaffinität finden Sie unter Externer TCP/UDP-Passthrough-Network-Load-Balancer.
Globaler externer Proxy-Network Load Balancer Klassischer Proxy-Network Load Balancer Regionaler externer Proxy-Network Load Balancer Regionaler interner Proxy-Network Load Balancer Regionsübergreifender interner Proxy-Network Load Balancer	Keine (NONE) Client-IP (CLIENT_IP)
Cloud Service Mesh	Keine (NONE) Client-IP (CLIENT_IP) Generiertes Cookie (GENERATED_COOKIE) (nur HTTP-Protokolle) Header-Feld (HEADER_FIELD) (nur HTTP-Protokolle) HTTP-Cookie (HTTP_COOKIE) (nur HTTP-Protokolle)

^* Diese Tabelle dokumentiert Sitzungsaffinitäten, die von Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt werden. Zielpoolbasierte externe Passthrough-Network-Load-Balancer verwenden keine Backend-Dienste. Stattdessen wird die Sitzungsaffinität für externe Passthrough-Network-Load-Balancer über den Parameter sessionAffinity in Zielpools festgelegt.

Beachten Sie beim Konfigurieren der Sitzungsaffinität Folgendes:

• Verlassen Sie sich bei Authentifizierungs- oder Sicherheitsthemen nicht auf die Sitzungsaffinität. Die Sitzungsaffinität, mit Ausnahme der zustandsorientierten cookiebasierten Sitzungsaffinität, wird unterbrochen, 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.

Arten der Sitzungsaffinität

In den folgenden Abschnitten werden die verschiedenen Arten von Sitzungsaffinität erläutert:

Client-IP ohne Zielaffinität

Die Sitzungsaffinität Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION) ist ein Ein-Tupel-Hash, der nur auf der Quell-IP-Adresse jedes empfangenen Pakets basiert. Diese Sitzungsaffinität ist nur für interne Passthrough-Network-Load-Balancer verfügbar.

Diese Option kann nützlich sein, wenn dieselbe Back-End-VM alle Pakete von einem Client verarbeiten soll, basierend ausschließlich auf der Quell-IP-Adresse des Pakets, ohne Rücksicht auf die IP-Zieladresse des Pakets. Diese Situationen treten in der Regel auf, wenn ein interner Passthrough-Network Load Balancer der nächste Hop für eine statische Route ist. Weitere Informationen finden Sie unter Sitzungsaffinität und interne Passthrough-Network Load Balancer für den nächsten Hop.

Client-IP-Affinität

Die Client-IP-Sitzungsaffinität (CLIENT_IP) ist ein Zwei-Tupel-Hash, der aus der Quell- und Ziel-IP-Adresse des Pakets erstellt wird. Die Client-IP-Sitzungsaffinität ist für alle Google Cloud-Load Balancer verfügbar, die Back-End-Dienste verwenden. Externe Passthrough-Netzwerk-Load-Balancer rufen diese Sitzungsaffinitätsoption auf: Client-IP, Ziel-IP.

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

• Die Ziel-IP-Adresse des Pakets stimmt nur dann mit der IP-Adresse der Weiterleitungsregel des Load Balancers überein, wenn das Paket direkt an den Load Balancer gesendet wird.

• Pakete, die über eine statische Route an einen internen Passthrough-Network Load Balancer als nächsten Hop weitergeleitet werden, haben Ziel-IP-Adressen, die nicht mit der IP-Adresse der Weiterleitungsregel des Load Balancers übereinstimmen. Wichtige Informationen finden Sie unter Sitzungsaffinität und interner Passthrough-Netzwerk-Load-Balancer für den nächsten Hop.

• Die IP-Adresse der Paketquelle stimmt möglicherweise nicht mit einer IP-Adresse überein, die mit dem ursprünglichen Client verknüpft ist, wenn das Paket von einem Zwischen-NAT oder Proxysystem verarbeitet wird, bevor es an einen Google Cloud-Load Balancer gesendet wird. Wenn viele Clients dieselbe effektive Quell-IP-Adresse verwenden, erhalten einige Back-End-VMs möglicherweise mehr Verbindungen oder Anfragen als andere.

Generierte Cookie-Affinität

Wenn Sie die generierte Cookie-basierte Affinität verwenden, fügt der Load Balancer als Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Set-Cookie-Header ein.

Der Name des generierten Cookies hängt vom Typ des Load Balancers ab. Die folgenden Produkte unterstützen generierte Cookies:

Produkt	Cookiename
Globale externe Application Load Balancer	GCLB
Klassische Application Load Balancer	GCLB
Regionale externe Application Load Balancer	GCILB
Regionsübergreifende interne Application Load Balancer	GCILB
Regionale interne Application Load Balancer	GCILB
Cloud Service Mesh	GCILB

Das Pfadattribut des generierten Cookies ist immer ein Schrägstrich (/). Es gilt daher für alle Back-End-Dienste in derselben URL-Zuordnung, sofern die anderen Back-End-Dienste auch die generierte Cookie-Affinität verwenden.

Sie können die Gültigkeitsdauer (Time to Live, TTL) des Cookies zwischen 0 und 1,209,600 Sekunden (einschließlich) mit dem Back-End-Dienstparameter affinityCookieTtlSec konfigurieren. Wenn affinityCookieTtlSec nicht angegeben ist, ist der Standard-TTL-Wert 0.

Wenn der Client das generierte Sitzungsaffinitäts-Cookie im Cookie-Anfrageheader von HTTP-Anfragen einschließt, leitet der Load Balancer diese Anfragen an dieselbe Back-End-Instanz oder denselben Back-End-Endpunkt weiter, solange das Sitzungsaffinitäts-Cookie gültig bleibt. Dazu wird der Cookie-Wert einem Index zugeordnet, der auf eine bestimmte Backend-Instanz oder einen Endpunkt verweist. Außerdem müssen die Anforderungen an die Sitzungsaffinität des generierten Cookies erfüllt sein.

Wenn Sie die generierte Cookie-Affinität verwenden möchten, konfigurieren Sie den folgenden Balancing-Modus und die folgenden localityLbPolicy-Einstellungen:

• Verwenden Sie für Back-End-Instanzgruppen den Balancing-Modus RATE.
• Verwenden Sie für die localityLbPolicy des Back-End-Dienstes entweder RING_HASH oder MAGLEV. Wenn Sie localityLbPolicy nicht explizit festlegen, verwendet der Load Balancer MAGLEV als impliziten Standardwert.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Header-Feld-Affinität

Bei der Header-Feld-Affinität werden Anfragen anhand des Werts des HTTP-Headers im Feld consistentHash.httpHeaderName des Backend-Dienstes an die Backends weitergeleitet. Damit Anfragen auf alle verfügbaren Backends verteilt werden, muss jeder Client einen anderen HTTP-Headerwert verwenden.

Die folgenden Load Balancer verwenden die Header-Feld-Affinität:

• Cloud Service Mesh
• Regionsübergreifender interner Application Load Balancer
• Globaler externer Application Load Balancer
• Regionaler externer Application Load Balancer
• Regionaler interner Application Load Balancer

Die Header-Feld-Affinität wird unterstützt, wenn die folgenden Bedingungen erfüllt sind:

• Die Load-Balancing-Lokalitätsrichtlinie ist RING_HASH oder MAGLEV.
• Der Backend-Dienst consistentHash gibt den Namen des HTTP-Headers (httpHeaderName) an.

Weitere Informationen dazu, welche Produkte die Header-Feld-Affinität unterstützen, finden Sie in der Tabelle: Unterstützte Einstellungen für die Sitzungsaffinität.

HTTP-Cookie-Affinität

Wenn Sie die HTTP-Cookie-basierte Affinität verwenden, fügt der Load Balancer als Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Set-Cookie-Header ein. Sie geben den Namen, den Pfad und die Gültigkeitsdauer (TTL) für das Cookie an.

Die folgenden Produkte unterstützen die Cookie-basierte HTTP-Affinität:

• Alle Application Load Balancer
• Cloud Service Mesh

Sie können die TTL-Werte des Cookies in Sekunden, Sekundenbruchteilen (als Nanosekunden) oder in Sekunden und Sekundenbruchteilen (als Nanosekunden) mithilfe der folgenden Parameter und gültigen Werte für den Back-End-Dienst konfigurieren:

• consistentHash.httpCookie.ttl.seconds kann auf einen Wert zwischen 0 und 315576000000 (einschließlich) festgelegt werden.
• consistentHash.httpCookie.ttl.nanos kann auf einen Wert zwischen 0 und 999999999 (einschließlich) festgelegt werden. Da die Einheiten Nanosekunden sind, entspricht 999999999 .999999999 Sekunden.

Wenn weder consistentHash.httpCookie.ttl.seconds noch consistentHash.httpCookie.ttl.nanos angegeben sind, wird stattdessen der Wert des Backend-Dienstparameters affinityCookieTtlSec verwendet. Wenn affinityCookieTtlSec nicht angegeben ist, ist der Standard-TTL-Wert 0.

Wenn der Client das HTTP-Cookie der Sitzungsaffinität im Cookie-Anfrageheader von HTTP-Anfragen einschließt, leitet der Load Balancer diese Anfragen an dieselbe Back-End-Instanz oder denselben Back-End-Endpunkt weiter, solange das Sitzungsaffinitäts-Cookie gültig bleibt. Dazu wird der Cookie-Wert einem Index zugeordnet, der auf eine bestimmte Backend-Instanz oder einen Endpunkt verweist. Außerdem müssen die Anforderungen an die Sitzungsaffinität des generierten Cookies erfüllt sein.

Wenn Sie die HTTP-Cookie-Affinität verwenden möchten, konfigurieren Sie den folgenden Balancing-Modus und die folgenden localityLbPolicy-Einstellungen:

• Verwenden Sie für Back-End-Instanzgruppen den Balancing-Modus RATE.
• Verwenden Sie für die localityLbPolicy des Back-End-Dienstes entweder RING_HASH oder MAGLEV. Wenn Sie localityLbPolicy nicht explizit festlegen, verwendet der Load Balancer MAGLEV als impliziten Standardwert.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Cookiebasierte zustandsorientierte Sitzungsaffinität

Wenn Sie die zustandsorientierte Cookie-basierte Affinität verwenden, fügt der Load Balancer als Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Set-Cookie-Header ein. Sie geben den Namen, den Pfad und die Gültigkeitsdauer (TTL) für das Cookie an.

Alle Application Load Balancer, mit Ausnahme der klassischen Application Load Balancer, unterstützen die zustandsorientierte cookiebasierte Affinität.

Sie können die TTL-Werte des Cookies in Sekunden, Sekundenbruchteilen (als Nanosekunden) oder in Sekunden und Sekundenbruchteilen (als Nanosekunden) konfigurieren. Die mit strongSessionAffinityCookie.ttl angegebene Dauer darf nicht länger als zwei Wochen (1.209.600 Sekunden) sein.

Der Wert des Cookies identifiziert eine ausgewählte Back-End-Instanz oder einen ausgewählten Endpunkt, indem die ausgewählte Instanz oder der ausgewählte Endpunkt im Wert selbst codiert wird. Wenn der Client das Sitzungsaffinitäts-Cookie im Cookie-Anfrageheader nachfolgender HTTP-Anfragen einschließt, leitet der Load Balancer diese Anfragen an die ausgewählte Back-End-Instanz oder den ausgewählten Endpunkt weiter, solange das Cookie gültig ist.

Im Gegensatz zu anderen Sitzungsaffinitätsmethoden:

• Für die zustandsorientierte cookiebasierte Affinität gelten keine speziellen Anforderungen an den Balancing-Modus oder die Load-Balancing-Richtlinie für den Ort (localityLbPolicy).

• Die zustandsorientierte cookiebasierte Affinität wird nicht beeinträchtigt, wenn durch das Autoscaling einer verwalteten Instanzgruppe eine neue Instanz hinzugefügt wird.

• Die zustandsorientierte cookiebasierte Affinität wird nicht beeinträchtigt, wenn durch das Autoscaling eine Instanz aus einer verwalteten Instanzgruppe entfernt wird, es sei denn, die ausgewählte Instanz wird entfernt.

• Die zustandsorientierte, cookiebasierte Affinität wird nicht beeinträchtigt, wenn eine Instanz durch die automatische Reparatur aus einer verwalteten Instanzgruppe entfernt wird, es sei denn, die ausgewählte Instanz wird entfernt.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Bedeutung einer TTL von null für cookiebasierte Affinitäten

Alle cookiebasierten Sitzungsaffinitäten, z. B. die generierte Cookie-Affinität, die HTTP-Cookie-Affinität und die zustandsorientierte cookiebasierte Affinität, haben ein TTL-Attribut.

Eine TTL von null Sekunden bedeutet, dass der Load Balancer dem Cookie kein Expires-Attribut zuweist. In diesem Fall behandelt der Client das Cookie als Sitzungscookie. Die Definition einer Sitzung variiert je nach Client:

• Einige Clients, z. B. Webbrowser, speichern das Cookie für die gesamte Browser-Sitzung. Das bedeutet, dass das Cookie für mehrere Anfragen verwendet wird, bis die Anwendung geschlossen wird.

• Andere Clients behandeln eine Sitzung als einzelne HTTP-Anfrage und werfen das Cookie sofort danach weg.

Verlust der Sitzungsaffinität

Für alle Optionen für die Sitzungsaffinität für Application Load Balancer und Proxy-Network Load Balancer ist Folgendes erforderlich:

• Die ausgewählte Backend-Instanz oder der ausgewählte Endpunkt muss weiterhin als Backend konfiguriert sein. Die Sitzungsaffinität kann unterbrochen werden, wenn eines der folgenden Ereignisse eintritt:

  • Sie entfernen die ausgewählte Instanz aus ihrer Instanzgruppe.

  • Durch das Autoscaling oder die automatische Reparatur einer verwalteten Instanzgruppe wird die ausgewählte Instanz aus der verwalteten Instanzgruppe entfernt.

  • Sie entfernen den ausgewählten Endpunkt aus der zugehörigen 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 werden, wenn die ausgewählte Instanz oder der ausgewählte Endpunkt die Systemdiagnosen nicht besteht.

• Bei globalen externen Application Load Balancern, klassischen Application Load Balancern, globalen externen Proxy-Network Load Balancern und klassischen Proxy-Network Load Balancern kann die Sitzungsaffinität unterbrochen werden, wenn nach der Änderung des Routingpfads ein anderes Google Front End (GFE) der ersten Schicht für nachfolgende Anfragen oder Verbindungen verwendet wird. Möglicherweise wird ein anderes GFE der ersten Ebene ausgewählt, wenn sich der Routingpfad von einem Client im Internet zu Google zwischen Anfragen oder Verbindungen ändert.

Mit Ausnahme der zustandsabhängigen cookiebasierten Sitzungsaffinität gelten für alle Optionen für die Sitzungsaffinität von Application Load Balancern und Proxy-Network Load Balancern 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 aufgehoben werden, wenn die Instanzgruppe oder NEG voll ist und andere Instanzgruppen oder NEGs nicht. Da sich die Auslastung 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 aufgehoben werden:

  • So fügen Sie neue Instanzen oder Endpunkte hinzu:

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

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

    • Sie entfernen eine Instanz aus dem Back-End einer Instanzgruppe.
    • Durch das Autoscaling oder die automatische Reparatur einer verwalteten Instanzgruppe werden alle Instanzen aus dem Backend der verwalteten Instanzgruppe entfernt.
    • Sie entfernen einen Endpunkt aus einem NEG-Backend.
    • Entfernen Sie alle vorhandenen, nicht leeren Back-End-Instanzgruppen oder NEGs aus dem Back-End-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 aufgehoben 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 es tritt ein Zeitüberschreitungsfehler auf.

Zeitlimit für Backend-Dienst

Die meisten Google Cloud-Load-Balancer haben ein Zeitlimit für den Back-End-Dienst. Der Standardwert beträgt 30 Sekunden. Der maximal zulässige Bereich der Zeitüberschreitungswerte liegt zwischen 1 und 2.147.483.647 Sekunden.

• Bei externen Application Load Balancern und internen Application Load Balancern, die das HTTP-, HTTPS- oder HTTP/2-Protokoll verwenden, ist das Zeitlimit des Backend-Diensts ein Anfrage- und Antwort-Zeitlimit für HTTP(S)-Traffic.

  Weitere Informationen zum Zeitlimit des Backend-Dienstes für jeden Load-Balancer finden Sie hier:

  • Informationen zu globalen externen Application Load Balancern und regionalen externen Application Load Balancern finden Sie unter Zeitlimits und Wiederholungsversuche.
  • Informationen zu internen Application Load Balancern finden Sie unter Zeitlimits und Wiederholungsversuche.

• Bei externen Proxy-Network-Load-Balancern ist das Zeitlimit ein Zeitlimit bei Inaktivität. Wenn Sie mehr oder weniger Zeit vor dem Löschen der Verbindung zulassen möchten, ändern Sie den Zeitlimitwert. Dieses Zeitlimit bei Inaktivität wird auch für WebSocket-Verbindungen verwendet.

• Bei internen Passthrough-Network-Load-Balancern und externen Passthrough-Network-Load-Balancern können Sie den Wert des Zeitlimits des Backend-Dienstes mit gcloud oder der API festlegen, aber der Wert wird ignoriert. Das Zeitlimit für den Back-End-Dienst hat für diese Passthrough-Load-Balancer keine Bedeutung.

• Für Cloud Service Mesh wird das Zeitlimit-Feld des Backend-Dienstes (mit timeoutSec angegeben) mit proxylosen gRPC-Diensten nicht unterstützt. Konfigurieren Sie für solche Dienste das Zeitlimit für den Backend-Dienst mithilfe des Felds maxStreamDuration. Dies liegt daran, dass gRPC die Semantik von timeoutSec nicht unterstützt, die die Zeitdauer angibt, für die auf die Rückgabe einer vollständigen Antwort vom Backend nach dem Senden der Anfrage gewartet werden soll. Das Zeitlimit von gRPC gibt an, wie lange vom Beginn des Streams bis zur vollständigen Verarbeitung der Antwort gewartet werden soll, einschließlich aller Wiederholungen.

Systemdiagnosen

Jeder Backend-Dienst, dessen Backends Instanzgruppen oder zonale NEGs sind, muss eine zugehörige Systemdiagnose haben. Backend-Dienste, die eine serverlose NEG oder eine globale Internet-NEG als Backend verwenden, dürfen nicht auf eine Systemdiagnose verweisen.

Wenn Sie einen Load-Balancer mit der Google Cloud Console erstellen, können Sie die Systemdiagnose bei Bedarf zusammen mit dem Load-Balancer erstellen oder auf eine vorhandene Systemdiagnose verweisen.

Wenn Sie einen Backend-Dienst mit den Backends einer Instanzgruppe oder einer zonalen NEG mit Google Cloud CLI oder der API erstellen, müssen Sie auf eine vorhandene Systemdiagnose verweisen. Weitere Informationen zu Art und Umfang der erforderlichen Systemdiagnose finden Sie in der Load-Balancer-Anleitung in der Übersicht über Systemdiagnosen.

Weitere Informationen finden Sie in den folgenden Dokumenten:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen
• gcloud-Systemdiagnose
• REST API-Systemdiagnose

Zusätzliche aktivierte Features in der Backend-Dienstressource

Die folgenden optionalen Funktionen werden von einigen Back-End-Diensten unterstützt.

Cloud CDN

Cloud CDN nutzt das globale Edge-Netzwerk von Google, um Inhalte näher bei den Nutzern bereitzustellen, was Ihre Websites und Anwendungen beschleunigt. Cloud CDN ist für Backend-Dienste aktiviert, die von globalen externen Application Load Balancern verwendet werden. Der Load-Balancer gibt die Frontend-IP-Adressen und -Ports an, die Anfragen erhalten, und die Back-Ends, die auf die entsprechenden Anfragen antworten.

Weitere Informationen finden Sie in der Cloud CDN-Dokumentation.

Cloud CDN ist nicht mit IAP kompatibel. Sie können nicht für denselben Backend-Dienst aktiviert werden.

Google Cloud Armor

Wenn Sie einen der folgenden Load Balancer verwenden, können Sie Ihren Anwendungen zusätzlichen Schutz hinzufügen, indem Sie Google Cloud Armor während der Erstellung des Load Balancers für den Backend-Dienst aktivieren:

• Globaler externer Application Load Balancer
• Klassischer Application Load Balancer
• Globaler externer Proxy-Network Load Balancer
• Klassischer Proxy-Network Load Balancer

Wenn Sie die Google Cloud Console verwenden, haben Sie folgende Möglichkeiten:

• Wählen Sie eine vorhandene Google Cloud Armor-Sicherheitsrichtlinie aus.
• Akzeptieren Sie die Konfiguration einer standardmäßigen Google Cloud Armor-Sicherheitsrichtlinie mit einem anpassbaren Namen, der Anfrageanzahl, dem Intervall, dem Schlüssel und den Ratenbegrenzungsparametern. Wenn Sie Google Cloud Armor mit einem vorgelagerten Proxydienst wie einem CDN-Anbieter verwenden, sollte Enforce_on_key als XFF-IP-Adresse festgelegt werden.
• Deaktivieren Sie den Google Cloud Armor-Schutz, indem Sie Keine auswählen.

IAP

Mit IAP können Sie eine zentrale Autorisierungsschicht für Anwendungen einrichten, auf die über HTTPS zugegriffen wird. Damit erhalten Sie ein Zugriffssteuerungsmodell auf Anwendungsebene und müssen keine Firewalls auf Netzwerkebene einsetzen. IAP wird von bestimmten Application Load Balancern unterstützt.

IAP ist nicht mit Cloud CDN kompatibel. Sie können nicht für denselben Backend-Dienst aktiviert werden.

Erweiterte Funktionen zur Trafficverwaltung

Informationen zu erweiterten Funktionen zur Trafficverwaltung, die für die mit Load Balancern verknüpften Back-End-Dienste und URL-Zuordnungen konfiguriert werden, finden Sie unter den folgenden Links:

• Trafficverwaltung für interne Application Load Balancer
• Trafficverwaltung für globale externe Application Load Balancer
• Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer

API und gcloudReferenz

Weitere Informationen zu den Attributen der Backend-Dienstressource finden Sie in den folgenden Referenzen:

• API-Ressource für globalen Backend-Dienst

• API-Ressource für regionalen Back-End-Dienst

• gcloud compute backend-services-Seite für globale und regionale Backend-Dienste

Nächste Schritte

Eine Dokumentation und Informationen zur Verwendung von Backend-Diensten beim Load-Balancing finden Sie in den folgenden Abschnitten:

• Benutzerdefinierte Header erstellen
• Externen Application Load Balancer erstellen
• Übersicht über externen Application Load Balancer
• Verbindungsausgleich aktivieren
• Verschlüsselung bei der Übertragung in Google Cloud

Ähnliche Videos:

• Backend-Dienste für globale externe Application Load Balancer konfigurieren