Ü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 einfache 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 globale und regionale Back-End-Dienste als Dienst in App Hub-Anwendungen fest.

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 Schemas werden von mehreren Produkten gemeinsam genutzt.

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 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: Eine oder mehrere App Engine-, Cloud Run- oder Cloud Run Functions-Ressourcen Eine globale Internet-NEG für ein externes Backend Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: eine 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: Eine oder mehrere App Engine-, Cloud Run- oder Cloud Run Functions-Ressourcen 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 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 ^† Eine einzelne serverlose NEG (nur für Cloud Run oder Cloud Run Functions der 2. Generation) 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 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 ^† Eine einzelne serverlose NEG (nur für Cloud Run oder Cloud Run Functions der 2. Generation) Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: eine 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 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 ^† Eine einzelne serverlose NEG (nur für Cloud Run oder Cloud Run Functions der 2. Generation) 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-Backends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Backends. ^* 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 ^† Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: eine 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 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 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 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 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 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 Private Service Connect-NEGs: Google APIs: eine einzelne Private Service Connect-NEG Verwaltete Dienste: eine 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 Portzuordnung	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 für Endpunkte 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-Backend-Dienste an EXTERNAL-Weiterleitungsregeln anzuhängen. EXTERNAL-Backend-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, Ihre vorhandenen EXTERNAL-Ressourcen mit dem unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren beschriebenen Migrationsprozess zu EXTERNAL_MANAGED zu migrieren.

Load-Balancer benennen

Bei Proxy-Network Load Balancern und Passthrough-Network Load Balancern ist der Name des Load Balancers immer derselbe wie der Name des Backend-Dienstes. Das Verhalten für die einzelnen Google Cloud Schnittstellen ist wie folgt:

• Google Cloud Console. Wenn Sie einen Proxy-Network Load Balancer oder einen Passthrough-Network Load Balancer über die Google Cloud -Konsole erstellen, wird dem Backend-Dienst automatisch derselbe Name zugewiesen, den Sie für den Load-Balancer-Namen eingegeben haben.
• Google Cloud CLI oder API Wenn Sie einen Proxy-Network-Load-Balancer oder einen Passthrough-Network-Load-Balancer mit der gcloud CLI oder der API erstellen, geben Sie beim Erstellen des Backend-Dienstes einen Namen Ihrer Wahl ein. Dieser Name des Backend-Dienstes wird dann in der Google Cloud Console als Name des Load-Balancers angezeigt.

Informationen zur Namensgebung für Application Load Balancer finden Sie unter URL-Zuordnungen: Namensgebung für Load Balancer.

Back-Ends

Ein Backend besteht aus einem oder mehreren Endpunkten, die Traffic von einem Google CloudLoad 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 kompatible Balancing-Modi verwenden. Weitere Informationen finden Sie in diesem Dokument unter Einschränkungen und Richtlinien für Instanzgruppen.
• Zonale NEG
• Serverlose NEG
• Private Service Connect-NEG
• Internet-NEG
• Hybrid-Konnektivitäts-NEG
• NEG für Portzuordnung
• 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 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 Back-Ends von Instanzgruppen 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 Proxy-basierte Load-Balancer (Application Load Balancer und Proxy-Netzwerk-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 bei der Verwendung von Instanzgruppen-Back-Ends Folgendes:

• Eine VM-Instanz kann immer nur einer Instanzgruppe mit Load-Balancing angehören. Eine VM kann beispielsweise Mitglied von zwei nicht verwalteten Instanzgruppen oder Mitglied einer verwalteten und einer nicht verwalteten Instanzgruppe sein. Wenn eine VM Mitglied von zwei oder mehr Instanzgruppen ist, kann nur auf eine der Instanzgruppen von einem oder mehreren Backend-Diensten für Load-Balancer verwiesen werden.

• Dieselbe Instanzgruppe kann von zwei oder mehr Back-End-Diensten verwendet werden. Für jede Zuordnung zwischen einer Instanzgruppe und einem Backend-Dienst kann ein anderer Balancing-Modus verwendet werden, mit Ausnahme der inkompatiblen Kombinationen von Balancing-Modi.

  • Folgende Balancing-Modus-Kombinationen sind inkompatibel:

    • Der Balancing-Modus UTILIZATION ist mit allen anderen Balancing-Modi inkompatibel. Wenn eine Instanzgruppe ein Back-End für mehrere Back-End-Dienste ist, muss sie für jeden Back-End-Dienst den Balancing-Modus UTILIZATION verwenden.

    • Der Balancing-Modus CUSTOM_METRICS ist mit allen anderen Balancing-Modi inkompatibel. Wenn eine Instanzgruppe ein Back-End für mehrere Back-End-Dienste ist, muss sie für jeden Back-End-Dienst den Balancing-Modus CUSTOM_METRICS verwenden.

  • Wenn eine Instanzgruppe entweder den Balancing-Modus UTILIZATION oder CUSTOM_METRICS als Back-End für mindestens einen Back-End-Dienst verwendet, kann dieselbe Instanzgruppe aufgrund der inkompatiblen Kombinationen von Balancing-Modi nicht als Back-End für einen Passthrough-Network Load Balancer verwendet werden, da für Passthrough-Network Load Balancer der Balancing-Modus CONNECTION erforderlich ist.

• Es gibt keinen einzelnen Befehl, mit dem der Balancing-Modus derselben Instanzgruppe für mehrere Back-End-Dienste geändert werden kann. So ändern Sie den Balancing-Modus für eine Instanzgruppe, die das Back-End von zwei oder mehr Back-End-Diensten ist:

  • Entfernen Sie die Instanzgruppe als Back-End aus allen Back-End-Diensten bis auf einen.
  • Ändern Sie den Balancing-Modus der Instanzgruppe für den einen verbleibenden Back-End-Dienst.
  • Fügen Sie die Instanzgruppe den anderen Back-End-Diensten wieder als Back-End hinzu.

Die folgenden Best Practices bieten flexiblere Optionen:

• Vermeiden Sie es, dieselbe Instanzgruppe als Back-End für zwei oder mehr Back-End-Dienste zu verwenden. Verwenden Sie stattdessen mehrere NEGs.

  • Im Gegensatz zu Instanzgruppen kann eine VM einen Endpunkt in zwei oder mehr NEGs mit Load-Balancing haben.

  • Wenn eine VM beispielsweise gleichzeitig ein Backend für einen Passthrough-Network-Load-Balancer und entweder einen Proxy-Network-Load-Balancer oder einen Application Load Balancer sein muss, verwenden Sie mehrere Load-Balancing-NEGs. Platzieren Sie einen VM-Endpunkt in einer eindeutigen NEG, die mit jedem Load-Balancer-Typ kompatibel ist. Ordnen Sie dann jede NEG dem entsprechenden Backend-Dienst des Load Balancers zu.

• Fügen Sie eine automatisch skalierte verwaltete Instanzgruppe nicht mehr als einem Back-End-Dienst hinzu, wenn Sie den Autoscaling-Messwert HTTP-Load-Balancing-Auslastung verwenden. Zwei oder mehr Back-End-Dienste, die auf dieselbe verwaltete Instanzgruppe mit Autoscaling verweisen, können sich gegenseitig widersprechen, sofern der Autoscaling-Messwert nicht mit der Load-Balancer-Aktivität zusammenhängt.

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 NEGs sind zonale Ressourcen, die Kombinationen aus IP-Adressen oder IP-Adressen/Port-Kombinationen fürGoogle Cloud -Ressourcen in einem einzelnen Subnetz darstellen.

Ein Back-End-Dienst, der zonale NEGs als Back-Ends 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 Backend-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 eine Cloud Run-, App Engine-, Cloud Run Functions- oder API Gateway-Ressource verweist.

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

• Eine Cloud Run-Ressource oder eine Gruppe von Ressourcen.
• Eine Cloud Run-Funktion oder eine Gruppe von Funktionen (früher Cloud Run Functions, 2. Generation).
• Eine Cloud Run-Funktion (1. Generation) 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 Ressourcen 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 die Richtlinie zur IP-Adressauswahl verwenden, um den Traffictyp anzugeben, 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 unter 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.

Balancing-Modus, Zielkapazität und Kapazitätsskalierer

Bei Application Load Balancern, Cloud Service Mesh und Proxy-Network Load Balancern geben Sie den Balancing-Modus, die Zielkapazität und den Kapazitätsskalierer als Parameter an, wenn Sie einem Backend-Dienst ein unterstütztes Backend hinzufügen. Die Load Balancer verwenden diese Parameter, um die Verteilung neuer Anfragen oder neuer Verbindungen auf Zonen mit unterstützten Back-Ends zu verwalten:

• Der Balancing-Modus definiert, wie der Load-Balancer die Kapazität misst. Google Cloud hat die folgenden Balancing-Modi:
  • CONNECTION: Definiert die Kapazität basierend auf der Anzahl der neuen TCP-Verbindungen.
  • RATE: Definiert die Kapazität basierend auf der Rate neuer HTTP-Anfragen.
  • IN-FLIGHT ( Vorabversion): Definiert die Kapazität basierend auf der Anzahl der laufenden HTTP-Anfragen anstelle der Rate von HTTP-Anfragen. Verwenden Sie diesen Balancing-Modus anstelle von RATE, wenn die Bearbeitung von Anfragen länger als eine Sekunde dauert.
  • UTILIZATION: Definiert die Kapazität basierend auf der geschätzten CPU-Auslastung von VMs in einer Zone einer Instanzgruppe.
  • CUSTOM_METRICS: Definiert die Kapazität basierend auf benutzerdefinierten Messwerten.
• Die Zielkapazität definiert die Zielkapazitätsnummer.
  • Die Zielkapazität ist kein Schutzschalter.
  • Wenn die Kapazitätsauslastung die Zielkapazität erreicht, leitet der Load-Balancer neue Anfragen oder neue Verbindungen an eine andere Zone weiter, sofern Back-Ends in zwei oder mehr Zonen konfiguriert sind.
  • Globale externe Application Load Balancer, globale externe Proxy-Network Load Balancer, regionenübergreifende interne Application Load Balancer und regionenübergreifende interne Proxy-Network Load Balancer verwenden ebenfalls Kapazität, um Anfragen an Zonen in verschiedenen Regionen weiterzuleiten, wenn Sie Backends in mehr als einer Region konfiguriert haben.
  • Wenn alle Zonen die Zielkapazität erreicht haben, werden neue Anfragen oder neue Verbindungen proportional verteilt.
• Mit dem Kapazitätsskalierer lässt sich die Zielkapazität manuell skalieren. Die Werte für den Kapazitätsskalierer sind wie folgt:
  • 0: Gibt an, dass das Back-End vollständig geleert wurde. Sie können den Wert 0 nicht verwenden, wenn ein Backend-Dienst nur ein Backend hat.
  • 0.1 (10%) – 1.0 (100%): Gibt den Prozentsatz der verwendeten Back-End-Kapazität an.

Passthrough-Network-Load-Balancer verwenden symbolisch den Balancing-Modus CONNECTION, unterstützen jedoch keine Zielkapazität oder keinen Kapazitätsskalierer. Weitere Informationen dazu, wie Passthrough-Network Load Balancer neue Verbindungen verteilen, finden Sie unter:

• Traffic-Verteilung für interne Passthrough-Network Load Balancer
• Traffic-Verteilung für externe Passthrough-Network-Load-Balancer

Unterstützte Back-Ends

Für Application Load Balancer, Cloud Service Mesh und Proxy-Network Load Balancer werden die Parameter für Balancing-Modus, Zielkapazität und Kapazitätsskalierung von den folgenden Backend-Typen unterstützt:

• Instanzgruppen-Back-Ends
• Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten
• Zonale Hybridkonnektivitäts-NEGs

Internet-NEGs, serverlose NEGs und Private Service Connect-NEGs unterstützen die Parameter für den Balancing-Modus, die Zielkapazität und den Kapazitätsskalierer nicht.

Balancing-Modi für Application Load Balancer und Cloud Service Mesh

Die verfügbaren Balancing-Modi für Application Load Balancer- und Cloud Service Mesh-Backends hängen vom Typ des unterstützten Backends und von einer Einstellung für die Traffic-Dauer ab (Vorschau).

Einstellung für die Traffic-Dauer

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Für Application Load Balancer- und Cloud Service Mesh-Backends können Sie optional eine Einstellung für die Traffic-Dauer angeben. Diese Einstellung ist für die Zuordnung zwischen einem unterstützten Backend und einem Backend-Dienst eindeutig. Die Einstellung für die Traffic-Dauer hat zwei gültige Werte:

• SHORT: Empfohlen für HTTP-Anfragen, die mit Antworten von Back-Ends in weniger als einer Sekunde beantwortet werden. Wenn Sie keine Traffic-Dauer explizit angeben, verhält sich der Load-Balancer so, als hätten Sie SHORT angegeben.
• LONG: Empfohlen für HTTP-Anfragen, für die das Backend mehr als eine Sekunde zum Generieren von Antworten benötigt.

Wenn Sie die Traffic-Dauer explizit festlegen möchten, wenn Sie einem Backend-Dienst ein Backend hinzufügen, haben Sie folgende Möglichkeiten:

• Führen Sie den Befehl gcloud compute backend-services add-backend mit dem --traffic-duration-Flag aus.
• Erstellen Sie einen Back-End-Dienst oder aktualisieren Sie einen Back-End-Dienst mit dem trafficDuration-Attribut.

Balancing-Modi für kurze Traffic-Dauer

Wenn die Einstellung für die Traffic-Dauer nicht angegeben oder auf SHORT(Vorabversion) festgelegt ist, hängen die verfügbaren Balancing-Modi für Application Load Balancer- und Cloud Service Mesh-Backends vom Typ des unterstützten Backends ab.

Tabelle:Balancing-Modi für Application Load Balancer- und Cloud Service Mesh-Back-Ends mit der Einstellung für kurze Traffic-Dauer

Unterstütztes Back-End	Balancing-Modus
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Instanzgruppen
Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten
Zonale Hybridkonnektivitäts-NEGs

Balancing-Modi für lange Traffic-Dauer

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Wenn die Einstellung für die Traffic-Dauer LONG ist, hängen die verfügbaren Balancing-Modi für Application Load Balancer- und Cloud Service Mesh-Back-Ends vom Typ des unterstützten Back-Ends ab.

Tabelle: Balancing-Modi für Application Load Balancer- und Cloud Service Mesh-Back-Ends mit der Einstellung für lange Traffic-Dauer

Unterstütztes Back-End	Balancing-Modus
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Instanzgruppen
Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten
Zonale Hybridkonnektivitäts-NEGs

Balancing-Modi für Proxy-Network Load Balancer

Die für Proxy-Network-Load-Balancer-Backends verfügbaren Balancing-Modi hängen vom Typ des unterstützten Backends ab.

Tabelle:Balancing-Modi für Proxy-Network-Load Balancer

Unterstütztes Back-End	Balancing-Modus
	CONNECTION	RATE	IN_FLIGHT	UTILIZATION	CUSTOM_METRICS
Instanzgruppen
Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten
Zonale Hybridkonnektivitäts-NEGs

Spezifikationen für die Zielkapazität

Spezifikationen für die Zielkapazität sind für Application Load Balancer, Cloud Service Mesh und Proxy-Network Load Balancer-Backends relevant, die die Einstellungen für Balancing-Modus, Zielkapazität und Kapazitätsskalierer unterstützen.

Spezifikationen für die Zielkapazität sind für Passthrough-Network Load Balancer nicht relevant.

Verbindungsmodus für Verbindungen

Für Proxy-Network Load Balancer-Back-Ends kann der Balancing-Modus CONNECTION mit einem der folgenden erforderlichen Zielkapazitätsparameter verwendet werden:

Parameter für die Zielkapazität für den Balancing-Modus CONNECTION

Parameter für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-connections Ziel-TCP-Verbindungen pro Backend-Zone
max-connections-per-instance Ziel-TCP-Verbindungen pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Anzahl der TCP-Zielverbindungen pro Backend-Zone zu berechnen.
max-connections-per-endpoint Ziel-TCP-Verbindungen pro NEG-Endpunkt. Cloud Load Balancing verwendet diesen Parameter, um die Anzahl der TCP-Zielverbindungen pro Backend-Zone zu berechnen.

max-connections-Parameter verwenden

Wenn Sie den Parameter max-connections angeben, wird mit dem angegebenen Wert die Kapazität für eine gesamte Zone definiert.

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-connections auf X festlegen, beträgt die zonale Zielkapazität X.
  • Die durchschnittliche Anzahl der Verbindungen pro Instanz beträgt X / h.

• Regional verwaltete Instanzgruppen unterstützen den Parameter max-connections nicht, da sie aus mehreren Zonen bestehen. Verwenden Sie stattdessen den Parameter max-connections-per-instance.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-connections auf X festlegen, beträgt die zonale Zielkapazität X.
  • Die durchschnittliche Anzahl der Verbindungen pro Endpunkt beträgt X / h.

max-connections-per-instance- oder max-connections-per-endpoint-Parameter verwenden

Wenn Sie den Parameter max-connections-per-instance oder max-connections-per-endpoint angeben, verwendet der Load Balancer den von Ihnen angegebenen Wert, um die Kapazität pro Zone zu berechnen:

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-connections-per-instance auf X setzen, ist die zonale Zielkapazität N * X. Dies entspricht dem Festlegen von max-connections auf N * X.
  • Die durchschnittliche Anzahl der Verbindungen pro Instanz beträgt (N * X) / h.

• Wenn Sie für eine regionale verwaltete Instanzgruppe max-connections-per-instance auf X festlegen, berechnet Google Cloud eine zielgerichtete Kapazität pro Zone für jede Zone der Instanzgruppe. Wenn es in jeder Zone insgesamt K Instanzen und h fehlerfreie Instanzen gibt (wobei h ≤ K), werden die Berechnungen so ausgeführt:

  • Die Zielkapazität der Zone ist K * X.
  • Die durchschnittliche Anzahl der Verbindungen pro Instanz in der Zone beträgt (K * X) / h.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-connections-per-endpoint auf X setzen, ist die zonale Zielkapazität N * X. Dies entspricht dem Festlegen von max-connections auf N * X.
  • Die durchschnittliche Anzahl der Verbindungen pro Endpunkt beträgt (N * X) / h.

Load-Balancing-Modus

Application Load Balancer- und Cloud Service Mesh-Backends mit einer nicht angegebenen oder kurzen Einstellung für die Traffic-Dauer (Vorabversion) können den RATE-Balancing-Modus mit einem der folgenden erforderlichen Zielkapazitätsparameter verwenden:

Tabelle: Parameter für die Zielkapazität für den Balancing-Modus RATE

Parameter für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-rate Ziel-HTTP-Anfragerate pro Backend-Zone
max-rate-per-instance HTTP-Anfragerate pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Ziel-HTTP-Anfragerate pro Backend-Zone zu berechnen.
max-rate-per-endpoint Ziel-HTTP-Anfragerate pro NEG-Endpunkt. Cloud Load Balancing verwendet diesen Parameter, um die Ziel-HTTP-Anfragerate pro Backend-Zone zu berechnen.

max-rate-Parameter verwenden

Wenn Sie den Parameter max-rate angeben, definiert der von Ihnen angegebene Wert die Kapazität für eine gesamte Zone.

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-rate auf X setzen, beträgt die zonale Zielkapazität X Anfragen pro Sekunde.
  • Die durchschnittlichen Anfragen pro Sekunde pro Instanz betragen X / h.

• Regional verwaltete Instanzgruppen unterstützen den Parameter max-rate nicht, da sie aus mehreren Zonen bestehen. Verwenden Sie stattdessen den Parameter max-rate-per-instance.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-rate auf X setzen, beträgt die zonale Zielkapazität X Anfragen pro Sekunde.
  • Die durchschnittlichen Anfragen pro Sekunde pro Endpunkt betragen X / h.

max-rate-per-instance- oder max-rate-per-endpoint-Parameter verwenden

Wenn Sie den Parameter max-rate-per-instance oder max-rate-per-endpoint angeben, verwendet der Load Balancer den von Ihnen angegebenen Wert, um die Kapazität pro Zone zu berechnen:

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-rate-per-instance auf X festlegen, beträgt die zonale Zielkapazität N * X Anfragen pro Sekunde. Dies entspricht dem Festlegen von max-rate auf N * X.
  • Die durchschnittlichen Anfragen pro Sekunde pro Instanz betragen (N * X) / h.

• Wenn Sie für eine regionale verwaltete Instanzgruppe max-rate-per-instance auf X festlegen, berechnet Google Cloud eine zonenspezifische Zielkapazität für jede Zone der Instanzgruppe. Wenn es in jeder Zone insgesamt K Instanzen und h fehlerfreie Instanzen gibt (wobei h ≤ K), werden die Berechnungen so ausgeführt:

  • Die Zielkapazität der Zone beträgt K * X Anfragen pro Sekunde.
  • Die durchschnittlichen Anfragen pro Sekunde pro Instanz in der Zone betragen (K * X) / h.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so ausgeführt:

  • Wenn Sie max-rate-per-endpoint auf X festlegen, beträgt die zonale Zielkapazität N * X Anfragen pro Sekunde. Dies entspricht dem Festlegen von max-rate auf N * X.
  • Die durchschnittlichen Anfragen pro Sekunde pro Endpunkt betragen (N * X) / h.

Balancing-Modus während der Fahrt

Vorschau

Dieses Produkt oder diese Funktion unterliegt den Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

Application Load Balancer- und Cloud Service Mesh-Backends mit einer langen Einstellung für die Traffic-Dauer können den IN_FLIGHT-Balancing-Modus mit einem der folgenden erforderlichen Zielkapazitätsparameter verwenden:

Tabelle: Parameter für die Zielkapazität für den Balancing-Modus IN_FLIGHT

Parameter für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-in-flight-requests Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone
max-in-flight-requests-per-instance Zielanzahl der laufenden HTTP-Anfragen pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone zu berechnen.
max-in-flight-requests-per-endpoint Zielanzahl der laufenden HTTP-Anfragen pro NEG-Endpunkt. Beim Load-Balancing wird dieser Parameter verwendet, um die Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone zu berechnen.

max-in-flight-requests-Parameter verwenden

Wenn Sie den Parameter max-in-flight-requests angeben, definiert der von Ihnen angegebene Wert die Kapazität für eine gesamte Zone.

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-in-flight-requests auf X festlegen, beträgt die zonale Zielkapazität X laufende HTTP-Anfragen.
  • Die durchschnittliche Anzahl der laufenden HTTP-Anfragen pro Instanz beträgt X / h.

• Regionale verwaltete Instanzgruppen unterstützen den Parameter max-in-flight-requests nicht, da sie aus mehreren Zonen bestehen. Verwenden Sie stattdessen den Parameter max-in-flight-requests-per-instance.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so ausgeführt:

  • Wenn Sie max-in-flight-requests auf X festlegen, beträgt die zonale Zielkapazität X laufende HTTP-Anfragen.
  • Die durchschnittliche Anzahl der laufenden HTTP-Anfragen pro Endpunkt beträgt X / h.

max-in-flight-requests-per-instance- oder max-in-flight-requests-per-endpoint-Parameter verwenden

Wenn Sie den Parameter max-in-flight-requests-per-instance oder max-in-flight-requests-per-endpoint angeben, verwendet der Load Balancer den von Ihnen angegebenen Wert, um die Kapazität pro Zone zu berechnen:

• Für eine zonale Instanzgruppe mit insgesamt N Instanzen und h fehlerfreien Instanzen (wobei h ≤ N) werden die Berechnungen so durchgeführt:

  • Wenn Sie max-in-flight-requests-per-instance auf X festlegen, beträgt die zonale Zielkapazität N * X laufende HTTP-Anfragen. Dies entspricht dem Festlegen von max-in-flight-requests auf N * X.
  • Die durchschnittliche Anzahl der laufenden HTTP-Anfragen pro Instanz beträgt (N * X) / h.

• Wenn Sie für eine regionale verwaltete Instanzgruppe max-in-flight-requests-per-instance auf X festlegen, berechnet Google Cloud eine zielgerichtete Kapazität pro Zone für jede Zone der Instanzgruppe. Wenn es in jeder Zone insgesamt K Instanzen und h fehlerfreie Instanzen gibt (wobei h ≤ K), werden die Berechnungen so ausgeführt:

  • Die Zielkapazität der Zone beträgt K * X laufende HTTP-Anfragen.
  • Die durchschnittliche Anzahl der laufenden HTTP-Anfragen pro Instanz in der Zone beträgt (K * X) / h.

• Für eine zonale NEG mit N Gesamtzahl der Endpunkte und h fehlerfreien Endpunkten (wobei h ≤ N) werden die Berechnungen so ausgeführt:

  • Wenn Sie max-in-flight-requests-per-endpoint auf X festlegen, beträgt die zonale Zielkapazität N * X laufende HTTP-Anfragen. Dies entspricht dem Festlegen von max-in-flight-requests auf N * X.
  • Die durchschnittliche Anzahl der laufenden HTTP-Anfragen pro Endpunkt beträgt (N * X) / h.

Balancing-Modus „Auslastung”

Application Load Balancer-, Cloud Service Mesh- und Proxy-Network Load Balancer-Instanzgruppen-Back-Ends können den Balancing-Modus UTILIZATION verwenden. NEG-Back-Ends unterstützen diesen Balancing-Modus nicht.

Der UTILIZATION-Ausgleichsmodus hängt von der CPU-Auslastung der VM und anderen Faktoren ab. Wenn diese Faktoren schwanken, berechnet der Load-Balancer die Auslastung möglicherweise so, dass einige VMs mehr Anfragen oder Verbindungen als andere erhalten. Beachten Sie daher Folgendes:

• Verwenden Sie den Balancing-Modus UTILIZATION nur, wenn die Sitzungsaffinität auf NONE festgelegt ist. Wenn Ihr Back-End-Dienst eine andere Sitzungsaffinität als NONE verwendet, verwenden Sie stattdessen die Balancing-Modi RATE, IN-FLIGHT oder CONNECTION.

• Wenn die durchschnittliche Auslastung der VMs in allen Instanzgruppen unter 10 % liegt, verteilen einige Load-Balancer neue Anfragen oder Verbindungen lieber auf bestimmte Zonen. Diese zonale Präferenz wird weniger häufig, wenn die Anfragerate oder die Anzahl der Verbindungen steigt.

Für den Balancing-Modus UTILIZATION ist keine obligatorische Einstellung für die Zielkapazität erforderlich. Sie können jedoch optional eine Zielkapazität definieren, indem Sie einen der in den folgenden Abschnitten beschriebenen Parameter für die Zielkapazität oder eine Kombination von Parametern für die Zielkapazität verwenden.

Parameter für die Zielkapazität für die Auslastung für Application Load Balancer- und Cloud Service Mesh-Backends mit einer nicht angegebenen oder kurzen Einstellung für die Traffic-Dauer

Application Load Balancer- und Cloud Service Mesh-Back-Ends mit einer nicht angegebenen oder kurzen Einstellung für die Traffic-Dauer (Vorabversion) können den UTILIZATION-Balancing-Modus mit einem der folgenden Zielkapazitätsparameter oder einer Kombination von Parametern verwenden:

Tabelle:Parameter und Parameterkombinationen für die Zielkapazität des UTILIZATION-Balancing-Modus für Application Load Balancer- und Cloud Service Mesh-Back-Ends mit einer nicht angegebenen oder kurzen Einstellung für die Traffic-Dauer

Parameter oder Parameterkombination für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-utilization Zielauslastung pro Backend-Zone
max-rate Ziel-HTTP-Anfragerate pro Backend-Zone
max-rate und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone Zielrate für HTTP-Anfragen der Zone
max-rate-per-instance HTTP-Anfragerate pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Ziel-HTTP-Anfragerate pro Backend-Zone zu berechnen.
max-rate-per-instance und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone HTTP-Zielanfragerate der Zone (berechnet aus der HTTP-Zielanfragerate pro VM-Instanz der VMs in der Zone)

Weitere Informationen zu den Parametern für die Zielkapazität max-rate und max-rate-per-instance finden Sie in diesem Dokument unter Modus für die Ratenabstimmung.

Parameter für die Zielkapazität für die Auslastung für Application Load Balancer- und Cloud Service Mesh-Backends mit einer Einstellung für lange Traffic-Dauer

Application Load Balancer- und Cloud Service Mesh-Backends mit einer langen Einstellung für die Traffic-Dauer (Vorschau) können den Balancing-Modus UTILIZATION mit einem der folgenden Zielkapazitätsparameter oder einer Kombination von Parametern verwenden:

Tabelle:Parameter und Parameterkombinationen für die Zielkapazität des UTILIZATION-Balancing-Modus für Application Load Balancer- und Cloud Service Mesh-Back-Ends mit der Einstellung „Lange Traffic-Dauer“ (Vorabversion)

Parameter oder Parameterkombination für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-utilization Zielauslastung pro Backend-Zone
max-in-flight-requests Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone
max-in-flight-requests und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone Zielanzahl der laufenden HTTP-Anfragen der Zone
max-in-flight-requests-per-instance Zielanzahl der laufenden HTTP-Anfragen pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone zu berechnen.
max-in-flight-requests-per-instance und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone Die Zielanzahl der laufenden HTTP-Anfragen der Zone (berechnet aus der Zielanzahl der laufenden HTTP-Anfragen pro VM-Instanz der VMs in der Zone)

Weitere Informationen zu den Zielkapazitätsparametern max-in-flight-requests und max-in-flight-requests-per-instance finden Sie in diesem Dokument unter Balancing-Modus während der Ausführung.

Parameter für die Zielkapazität für die Auslastung von Proxy-Network Load Balancern

Instanzgruppen-Back-Ends von Proxy-Network Load Balancern können den Balancing-Modus UTILIZATION mit einem der folgenden Parameter für die Zielkapazität oder einer Kombination aus Parametern verwenden.

Tabelle:Parameter und Parameterkombinationen für die Zielkapazität des UTILIZATION-Balancing-Modus für Proxy-Network-Load-Balancer-Backends

Parameter oder Parameterkombination für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
max-utilization Zielauslastung pro Backend-Zone
max-connections Ziel-TCP-Verbindungen pro Backend-Zone
max-connections und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone Ziel-TCP-Verbindungen der Zone
max-connections-per-instance Ziel-TCP-Verbindungen pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Anzahl der TCP-Zielverbindungen pro Backend-Zone zu berechnen.
max-connections-per-instance und max-utilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Zielauslastung der Zone TCP-Zielverbindungen der Zone (berechnet aus den TCP-Zielverbindungen pro VM-Instanz der VMs in der Zone)

Weitere Informationen zu den Zielkapazitätsparametern max-connections und max-connections-per-instance finden Sie in diesem Dokument unter Verbindungs-Balancing-Modus.

Balancing-Modus für benutzerdefinierte Messwerte

Für Back-Ends von Application Load Balancern und Proxy-Network Load Balancern kann der CUSTOM_METRICS-Lastenausgleichsmodus verwendet werden. Mit benutzerdefinierten Messwerten können Sie die Zielkapazität anhand von Anwendungs- oder Infrastrukturdaten definieren, die für Sie am wichtigsten sind. Weitere Informationen finden Sie unter Benutzerdefinierte Messwerte für Application Load Balancer.

Für den Balancing-Modus CUSTOM_METRICS ist keine obligatorische Einstellung für die Zielkapazität erforderlich. Sie können jedoch optional eine Zielkapazität mit einem der in den folgenden Abschnitten beschriebenen Parameter oder Kombinationen von Parametern für die Zielkapazität definieren.

Parameter für die Zielkapazität für benutzerdefinierte Messwerte für Application Load Balancer-Backends mit einer nicht angegebenen oder kurzen Einstellung für die Trafficdauer

Application Load Balancer-Back-Ends mit einer nicht angegebenen oder kurzen Einstellung für die Traffic-Dauer (Vorschau) können den Balancing-Modus CUSTOM_METRICS mit einem der folgenden Parameter oder einer Kombination von Parametern für die Zielkapazität verwenden:

Tabelle:Zielkapazitätsparameter und Parameterkombinationen für den CUSTOM_METRICS-Balancing-Modus für Application Load Balancer-Back-Ends mit einer nicht angegebenen oder kurzen Einstellung für die Trafficdauer

Parameter oder Parameterkombination für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
backends[].customMetrics[].maxUtilization Zielauslastung des benutzerdefinierten Messwerts pro Backend-Zone
max-rate Ziel-HTTP-Anfragerate pro Backend-Zone
max-rate und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen Zielrate für HTTP-Anfragen der Zone
max-rate-per-instance HTTP-Anfragerate pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Ziel-HTTP-Anfragerate pro Backend-Zone zu berechnen.
max-rate-per-instance und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen HTTP-Zielanfragerate der Zone (berechnet aus der HTTP-Zielanfragerate pro VM-Instanz der VMs in der Zone)
max-rate-per-endpoint Ziel-HTTP-Anfragerate pro NEG-Endpunkt. Cloud Load Balancing verwendet diesen Parameter, um die Ziel-HTTP-Anfragerate pro Backend-Zone zu berechnen.
max-rate-per-endpoint und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen Ziel-HTTP-Anfragerate der Zone (berechnet aus der Ziel-HTTP-Anfragerate pro NEG-Endpunkt der Endpunkte in der Zone)

Weitere Informationen zu den Zielkapazitätsparametern max-rate, max-rate-per-instance und max-rate-per-endpoint finden Sie in diesem Dokument unter Balancing-Modus RATE.

Parameter für die Zielkapazität für benutzerdefinierte Messwerte für Application Load Balancer-Backends mit langer Trafficdauer

Application Load Balancer-Back-Ends mit einer langen Einstellung für die Trafficdauer können den Balancing-Modus CUSTOM_METRICS mit einem der folgenden Parameter für die Zielkapazität oder einer Kombination aus Parametern verwenden:

Tabelle:Zielkapazitätsparameter und Parameterkombinationen für den CUSTOM_METRICS-Balancing-Modus für Application Load Balancer-Back-Ends mit der Einstellung „Lange Traffic-Dauer“ (Vorschau)

Parameter oder Parameterkombination für die Zielkapazität	Unterstütztes Back-End
	Zonale (verwaltete oder nicht verwaltete) Instanzgruppen	Regional verwaltete Instanzgruppen	Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten	Zonale Hybridkonnektivitäts-NEGs
backends[].customMetrics[].maxUtilization Zielauslastung des benutzerdefinierten Messwerts pro Backend-Zone
max-in-flight-requests Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone
max-in-flight-requests und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen Zielanzahl der laufenden HTTP-Anfragen der Zone
max-in-flight-requests-per-instance Zielanzahl der laufenden HTTP-Anfragen pro VM-Instanz. Cloud Load Balancing verwendet diesen Parameter, um die Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone zu berechnen.
max-in-flight-requests-per-instance und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen Die Zielanzahl der laufenden HTTP-Anfragen der Zone (berechnet aus der Zielanzahl der laufenden HTTP-Anfragen pro VM-Instanz der VMs in der Zone)
max-in-flight-requests-per-endpoint Zielanzahl der laufenden HTTP-Anfragen pro NEG-Endpunkt. Beim Load-Balancing wird dieser Parameter verwendet, um die Zielanzahl der laufenden HTTP-Anfragen pro Backend-Zone zu berechnen.
max-in-flight-requests-per-endpoint und backends[].customMetrics[].maxUtilization Das Ziel wird als Erstes in der Backend-Zone erreicht: Nutzung benutzerdefinierter Zielmesswerte für Zonen Die Zielanzahl der laufenden HTTP-Anfragen für die Zone (berechnet aus der Zielanzahl der laufenden HTTP-Anfragen pro NEG-Endpunkt der Endpunkte in der Zone)

Weitere Informationen zu den Zielkapazitätsparametern max-in-flight-requests, max-in-flight-requests-per-instance und max-flight-requests-per-endpoint finden Sie unter Balancing-Modus während der Ausführung.

Load-Balancing-Richtlinie des Dienstes

Eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) ist eine Ressource, die dem Backend-Dienst des Load Balancers zugeordnet ist. Damit können Sie 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 Optimierungen für 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 (Standard): Dies ist die Standardeinstellung für die Load-Balancing-Richtlinie für den Ort, bei der der Load-Balancer ein fehlerfreies Back-End im Round-Robin-Verfahren auswählt.

• WEIGHTED_ROUND_ROBIN: Der Load Balancer verwendet nutzerdefinierte benutzerdefinierte Messwerte, um die optimale Instanz oder den optimalen Endpunkt im Backend für die Anfrageabwicklung auszuwählen.

• 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 konsistente Hashfunktion 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 Clientverbindungs-Metadaten 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 das gewichtete Load-Balancing pro Instanz mithilfe 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. Entscheidungen zum Load-Balancing werden auf Grundlage der gewichteten Werte pro Instanz getroffen, die in den zuletzt verarbeiteten Antworten auf Systemdiagnosen gemeldet werden, sofern jede Instanz einen gültigen gewichteten Wert oder UNAVAILABLE_WEIGHT meldet. Andernfalls bleibt das Load Balancing gleich gewichtet.

  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
• Globaler externer Proxy-Network Load Balancer
• Regionaler externer Proxy-Network Load Balancer
• Regionsübergreifender interner Proxy-Network Load Balancer
• Regionaler interner Proxy-Network 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 der Standardwert für localityLbPolicy ROUND_ROBIN. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist der Standardwert für localityLbPolicy MAGLEV.

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

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 Bedingungen für Pre‑GA-Angebote im Abschnitt „Allgemeine Dienstbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte und ‑Funktionen stehen in der vorliegenden Form zur Verfügung und bieten möglicherweise nur eingeschränkten Support. Weitere Informationen finden Sie in den Beschreibungen der Produkteinführungsphasen.

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 Back-End-Dienste unter „Kontingente und Limits“.

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-Gewichtungen (einschließlich des Aktivierens oder Deaktivierens 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

Weitere Informationen zur Sitzungsaffinität für Passthrough-Network Load Balancer finden Sie in den folgenden Dokumenten:

• Traffic-Verteilung für externe Passthrough Network Load Balancer
• Traffic-Verteilung für interne Passthrough-Network Load Balancer

Weitere Informationen zur Sitzungsaffinität für Application Load Balancer finden Sie in den folgenden Dokumenten:

• Sitzungsaffinität für externe Application Load Balancer
• Sitzungsaffinität für interne Application Load Balancer

Weitere Informationen zur Sitzungsaffinität für Proxy-Network Load Balancer finden Sie in den folgenden Dokumenten:

• Sitzungsaffinität für externe Proxy-Network Load Balancer
• Sitzungsaffinität für interne Proxy-Network Load Balancer

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 und internen Proxy-Network-Load-Balancern gibt das konfigurierte Zeitlimit für den Backend-Dienst an, wie lange der Load Balancer die TCP-Verbindung offen hält, wenn weder vom Client noch vom Backend Daten übertragen werden. Wenn nach Ablauf dieser Zeit keine Daten übertragen wurden, schließt der Proxy die Verbindung.

  • Standardwert: 30 Sekunden
  • Konfigurierbarer Bereich: 1 bis 2.147.483.647 Sekunden

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

Cloud Armor

Wenn Sie einen der folgenden Load Balancer verwenden, können Sie Ihren Anwendungen zusätzlichen Schutz hinzufügen, indem Sie 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 Cloud Armor-Sicherheitsrichtlinie aus.
• Akzeptieren Sie die Konfiguration einer standardmäßigen Cloud Armor-Sicherheitsrichtlinie mit einem anpassbaren Namen, der Anfrageanzahl, dem Intervall, dem Schlüssel und den Ratenbegrenzungsparametern. Wenn Sie Cloud Armor mit einem Upstream-Proxydienst wie einem CDN-Anbieter verwenden, sollte Enforce_on_key als XFF-IP-Adresse festgelegt werden.
• Deaktivieren Sie den 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.

Funktionen der erweiterten Traffic-Verwaltung

Informationen zu erweiterten Trafficverwaltungsfunktionen, die für die mit Load-Balancern verknüpften Back-End-Dienste und URL-Zuordnungen konfiguriert werden, finden Sie unter:

• 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 während der Übertragung in Google Cloud

Ähnliche Videos:

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