Ü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 den 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 Back-End-Dienst erstellen oder dem Back-End-Dienst ein Back-End 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.

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 den 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 2
  • Alle serverlosen NEGs: Ein oder mehrere App Engine-, Cloud Run- oder Cloud Functions-Dienste
  • Private Service Connect NEGs: Wenn mehr als eine NEG angegeben ist, müssen sich die NEGs in unterschiedlichen Regionen befinden.
  • Eine globale Internet-NEG für ein externes Backend
 EXTERNAL_MANAGED
Klassischer Application Load Balancer Mehrere Global1 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 2
  • Alle serverlosen NEGs: Ein oder mehrere App Engine-, Cloud Run- oder Cloud Functions-Dienste
  • Eine globale Internet-NEG für ein externes Backend
 EXTERN
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 2
  • Eine einzelne serverlose NEG (nur Cloud Run)
  • Eine einzelne Private Service Connect NEG
  • Alle regionalen Internet-NEGs für ein externes Backend
 EXTERNAL_MANAGED
Regionenü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 2
  • Eine einzelne serverlose NEG (nur Cloud Run)
  • Eine einzelne Private Service Connect NEG
 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 2
  • 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 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 2
 EXTERNAL_MANAGED
Klassischer Proxy-Network Load Balancer 1 Global1 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 2
 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
 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
 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
INTERNAL_MANAGED
Externer Passthrough-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
 EXTERN
Interner Passthrough-Network-Load-Balancer 1 Regional, aber für globalen Zugriff konfigurierbar 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
 INTERN
Traffic Director 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
1 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:
2 Bei GKE-Deployments werden gemischte NEG-Back-Ends nur mit eigenständigen NEGs unterstützt.

Back-Ends

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

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 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 gesendet, die sich im Subnetzwerk befindet, das der NEG zugeordnet ist.

Benannte Ports

Das Attribut Benannter Port des Backend-Dienstes gilt nur für Proxy-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:

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 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 dazu, welche Produkte 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 Backend-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Backend, das auf einen Cloud Run-, App Engine-, Cloud 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.
  • Ein Cloud Functions-Feature oder eine Gruppe von Features.
  • 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.

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-Schema (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 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 Traffic Director 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 Traffic Director verwenden.

Tabelle: Protokoll für die Back-Ends
Produkt Protokolloptionen für Backend-Dienste
Application Load Balancer HTTP, HTTPS, HTTP/2
Proxy-Netzwerk Load Balancer

TCP oder SSL

Die regionalen Proxy-Network Load Balancer unterstützen nur TCP.
Netzwerk Load Balancer (Passthrough) TCP, UDP oder UNSPECIFIED
Traffic Director 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.

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 von Traffic Director zusätzlichen Traffic verarbeiten können oder vollständig geladen werden. Google Cloud bietet drei Balancing-Modi:

  • CONNECTION: Legt fest, wie die Last verteilt wird, basierend auf der Gesamtzahl der Verbindungen, die das Backend verarbeiten kann.
  • RATE: Die maximale Zielanzahl 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: Legt anhand der Auslastung der Instanzen in einer Instanzgruppe fest, wie die Last 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 dem Typ des Back-Ends ab.

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

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

In dieser Tabelle werden alle möglichen Balancing-Modi für einen bestimmten Load-Balancer und Backend-Typ zusammengefasst. Außerdem werden die verfügbaren oder erforderlichen Kapazitätseinstellungen angezeigt, die Sie mit dem Load-Balancing-Modus festlegen müssen.

Tabelle: Angabe der der Zielkapazität für Balancing-Modi
Load-Balancer Typ des Back-Ends Balancing-Modus Zielkapazität
  • Application Load Balancer
  • Traffic Director
 Instanzgruppe RATE Sie müssen eine der folgenden Optionen angeben:
  • max-rate pro zonale Instanzgruppe
  • max-rate-per-instance
     (zonale oder regionale Instanzgruppen)
UTILIZATION Sie können optional eine der folgenden Optionen angeben:
  • (1) max-utilization
  • (2) max-rate pro zonale Instanzgruppe
  • (3) max-rate-per-instance
     (zonale oder regionale Instanzgruppen)
  • (1) und (2) zusammen
  • (1) und (3) zusammen
Zonale NEG (GCP_VM_IP_PORT) RATE Sie müssen eine der folgenden Optionen angeben:
  • max-rate pro zonale NEG
  • max-rate-per-endpoint
Hybrid-NEG (NON_GCP_PRIVATE_IP_PORT) RATE Sie müssen eine der folgenden Optionen angeben:
  • max-rate pro Hybrid-NEG
  • max-rate-per-endpoint
  • Globaler externer Proxy-Network Load Balancer
  • Klassischer Proxy-Network Load Balancer
  • Regionalen externen Proxy-Netzwerk-Load-Balancer
  • Regionaler interner Proxy-Network Load Balancer
  • Regionsübergreifender interner Proxy-Network Load Balancer
 Instanzgruppe CONNECTION Sie müssen eine der folgenden Optionen angeben:
  • max-connections pro zonale Instanzgruppe
  • max-connections-per-instance (zonale oder regionale Instanzgruppen)
UTILIZATION Sie können optional eine der folgenden Optionen angeben:
  • (1) max-utilization
  • (2) max-connections pro zonale Instanzgruppe
  • (3) max-connections-per-instance
     (zonale oder regionale Instanzgruppen)
  • (1) und (2) zusammen
  • (1) und (3) zusammen
Zonale NEG (GCP_VM_IP_PORT) CONNECTION Sie müssen eine der folgenden Optionen angeben:
  • max-connections pro zonale NEG
  • max-connections-per-endpoint

Hybrid-NEG (NON_GCP_PRIVATE_IP_PORT)

 CONNECTION Sie müssen eine der folgenden Optionen angeben:
  • max-connections pro Hybrid-NEG
  • max-connections-per-endpoint
Netzwerk Load Balancer (Passthrough) Instanzgruppe 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

Verwenden Sie den Kapazitätsskalierer, um die Zielkapazität (maximale Auslastung, maximale Rate oder maximale Verbindungen) zu skalieren, ohne die Zielkapazität zu ändern.

Die Google Cloud-Referenzdokumentation finden Sie hier:

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

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 Load-Balancing-Richtlinie für Dienste.

Traffic Director und Trafficverteilung

Auch Traffic Director verwendet Back-End-Dienst-Ressourcen. Insbesondere nutzt Traffic Director 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 Traffic Director 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 Traffic Director finden Sie unter Konzepte von Traffic Director.

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

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.

Internen HTTPS-Load Balancer ohne Backend-Untereinstellung vergleichen.
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 und 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.

Vergleich eines internen Passthrough-Network Load Balancers ohne und mit Teilmengeneinstellung.
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 und 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.
  • Sie können das Backend-Dienstprotokoll UNSPECIFIED nicht verwenden.

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, 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:

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
  • Keine (NONE)
  • Client-IP (CLIENT_IP)
  • Generiertes Cookie (GENERATED_COOKIE)
  • Header-Feld (HEADER_FIELD)
  • HTTP-Cookie (HTTP_COOKIE)

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 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.
  • 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)
  • Keine (NONE)
  • Client-IP (CLIENT_IP)
  • Generiertes Cookie (GENERATED_COOKIE)
  • Header-Feld (HEADER_FIELD)
  • HTTP-Cookie (HTTP_COOKIE)

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 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.
  • 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-Balancer1
  • 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
  • Regionalen externen Proxy-Netzwerk-Load-Balancer
  • Regionaler interner Proxy-Network Load Balancer
  • Regionsübergreifender interner Proxy-Network Load Balancer
  • Keine (NONE)
  • Client-IP (CLIENT_IP)
Traffic Director
  • 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)

1 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 ist so konzipiert, dass sie unterbrochen wird, wenn sich die Anzahl der bereitstellenden und fehlerfreien Back-Ends ändert. Bei den folgenden Aktivitäten wird die der Sitzungsaffinität unterbrochen:

    • Backend-Instanzgruppen oder NEGs zum Backend-Dienst hinzufügen
    • Backend-Instanzgruppen oder NEGs aus dem Backend-Dienst entfernen
    • Instanzen zu einer vorhandenen Backend-Instanzgruppe hinzufügen (dies erfolgt automatisch, wenn Sie das Autoscaling mit verwalteten Instanzgruppen aktivieren)
    • Instanzen aus einer vorhandenen Backend-Instanzgruppe entfernen (dies erfolgt automatisch, wenn Sie das Autoscaling mit verwalteten Instanzgruppen aktivieren)
    • Endpunkte zu einer vorhandenen Backend-NEG hinzufügen
    • Endpunkte aus einer vorhandenen Backend-NEG entfernen
    • Wenn ein fehlerfreies Backend seine Systemdiagnose nicht besteht und fehlerhaft wird
    • Wenn ein fehlerhaftes Backend seine Systemdiagnose besteht und fehlerfrei wird
    • Für Pass-Through-Load-Balancer: während Failover und Failback, wenn eine Failover-Richtlinie konfiguriert ist
    • Für Proxy-Load-Balancer, wenn ein Backend die Kapazität erreicht oder überschreitet

  • Die Verwendung einer anderen Sitzungsaffinität als None mit dem Balancing-Modus UTILIZATION wird nicht empfohlen. Dies liegt daran, dass Änderungen an der Instanzauslastung dazu führen können, dass der Load-Balancing-Dienst neue Anfragen oder Verbindungen zu Back-End-VMs weiterleitet, die weniger voll sind. Dadurch wird die Sitzungsaffinität aufgehoben. Verwenden Sie stattdessen den Balancing-Modus RATE oder CONNECTION, um die Aufteilung der Sitzungsaffinität zu reduzieren. Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

  • Bei externen und internen HTTP(S)-Load-Balancern kann die Sitzungsaffinität gestört werden, wenn der vorgesehene Endpunkt oder die vorgesehene Instanz die maximale Zielrate ihres Balancing-Modus überschreitet. Dazu ein Beispiel:

    • Ein Load-Balancer hat eine NEG und drei Endpunkte.
    • Jeder Endpunkt hat eine Zielkapazität von 1 RPS.
    • Der Balancing-Modus ist RATE.
    • Derzeit verarbeitet jeder Endpunkt 1,1, 0,8 und 1,6 RPS.
    • Wenn eine HTTP-Anfrage mit Affinität für den letzten Endpunkt auf dem Load-Balancer eingeht, erhebt die Sitzungsaffinität Anspruch auf den Endpunkt, der 1,6 Anfragen pro Sekunde verarbeitet.
    • Die neue Anfrage kann an den mittleren Endpunkt mit 0,8 Anfragen pro Sekunde gesendet werden.

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

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

Client-IP ohne Zielaffinität

Eine Client-IP-Affinität ohne Zielaffinität (CLIENT_IP_NO_DESTINATION) leitet Anfragen von derselben Client-Quell-IP-Adresse an dieselbe Backend-Instanz weiter.

Wenn Sie Client-IP-Affinität ohne Zielaffinität verwenden, beachten Sie Folgendes:

  • Eine Client-IP-Affinität ohne Zielaffinität ist ein Ein-Tupel-Hash, der aus der Quell-IP-Adresse des Clients besteht.

  • Wenn ein Client von einem Netzwerk zu einem anderen verschoben wird, ändert sich seine IP-Adresse. Dies kann zur Aufhebung der Affinität führen.

Eine Client-IP-Affinität ohne Zielaffinität ist nur eine Option für interne Passthrough-Network-Load-Balancer.

Client-IP-Affinität

Mit Client-IP-Affinität (CLIENT_IP) werden Anfragen von derselben Client-IP-Adresse an dieselbe Backend-Instanz weitergeleitet. Client-IP-Affinität ist eine Option für jeden Google Cloud-Load-Balancer, der Backend-Dienste verwendet.

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

  • Die Client-IP-Affinität ist ein Zwei-Tupel-Hash, der aus der IP-Adresse des Clients und der IP-Adresse der Weiterleitungsregel des Load-Balancers besteht, die der Client kontaktiert.

  • Die Client-IP-Adresse für den Load-Balancer ist möglicherweise nicht der Ursprungsclient, wenn sich die Adresse hinter NAT befindet oder die Anfragen über einen Proxy stellt. Anfragen, die über NAT oder einen Proxy gesendet werden, verwenden die IP-Adresse des NAT-Routers oder des Proxys als Client-IP-Adresse. Dies kann dazu führen, dass eingehender Traffic unnötigerweise auf dieselben Back-End-Instanzen verteilt wird.

  • Wenn ein Client von einem Netzwerk zu einem anderen verschoben wird, ändert sich seine IP-Adresse. Dies kann zur Aufhebung der Affinität führen.

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

Wenn Sie die generierte Cookie-Affinität festlegen, gibt der Load-Balancer ein Cookie für die erste Anfrage aus. Bei jeder nachfolgenden Anfrage mit demselben Cookie leitet der Load-Balancer die Anfrage an dieselbe Backend-VM oder denselben Backend-Endpunkt weiter.

  • Für externe Application Load Balancer lautet das Cookie GCLB.
  • Für Traffic Director, regionale externe Application Load Balancer und interne Application Load Balancer lautet das Cookie GCILB.

Die cookiebasierte Affinität kann einen Client gegenüber einem Load-Balancer genauer als die client-IP-basierte Affinität identifizieren. Beispiel:

  1. Bei einer cookiebasierten Affinität kann der Load-Balancer zwei oder mehr Clientsysteme mit identischer Quell-IP-Adresse eindeutig identifizieren. Bei Verwendung der Client-IP-basierten Affinität behandelt der Load-Balancer alle Verbindungen von derselben Quell-IP-Adresse, als würden sie vom selben Clientsystem stammen.

  2. Wenn ein Client seine IP-Adresse ändert, kann der Load-Balancer anhand der cookiebasierten Affinität nachfolgende Verbindungen von diesem Client erkennen, anstatt die Verbindung als neu zu behandeln. Ein Beispiel für das Ändern der IP-Adresse eines Clients ist, wenn ein Mobilgerät von einem Netzwerk in ein anderes wechselt.

Erstellt ein Load-Balancer ein Cookie für eine generierte cookiebasierte Affinität, wird das Attribut path des Cookies auf / gesetzt. Wenn das Tool der URL-Zuordnung zum Abgleich von Pfaden über mehrere Backend-Dienste für einen Hostnamen verfügt, teilen alle Backend-Dienste dasselbe Sitzungscookie.

Die Lebensdauer der vom Load-Balancer generierten HTTP-Cookies ist konfigurierbar. Legen Sie dafür 0 (Standardwert) fest, was bedeutet, dass das Cookie nur ein Sitzungscookie ist. Sie können auch die Lebensdauer des Cookies auf einen Wert von 1 bis 86400 Sekunden (einschließlich 24 Stunden) festlegen.

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

Header-Feld-Affinität

Traffic Director und interne Application Load Balancer können die Header-Feld-Affinität verwenden, wenn die beiden 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.

Traffic Director, globale externe Application Load Balancer, regionale externe Application Load Balancer, globale externe Proxy-Network Load Balancer, regionale externe Proxy-Network Load Balancer, regionenübergreifende interne Application Load Balancer und regionale interne Application Load Balancer können die HTTP-Cookie-Affinität verwenden, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Lokalitätsrichtlinie ist RING_HASH oder MAGLEV.
  • Der konsistente Hash-Wert des Back-End-Dienstes gibt den Namen des HTTP-Cookies an.

Die HTTP-Cookie-Affinität leitet Anfragen an Back-End-VMs oder -Endpunkte in einer NEG anhand des HTTP-Cookies weiter, das im Flag HTTP_COOKIE genannt ist. Wenn der Client das Cookie nicht bereitstellt, generiert der Proxy das Cookie und gibt es in einem Set-Cookie-Header an den Client zurück.

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

Verlust der Sitzungsaffinität

Unabhängig vom ausgewählten Affinitätstyp kann ein Client in folgenden Situationen die Affinität zu einem Back-End verlieren:

  • Wenn die Back-End-Instanzgruppe oder die zonale NEG nicht genügend Kapazität hat, wie durch die Zielkapazität des Balancing-Modus definiert. In dieser Situation leitet Google Cloud den Traffic an eine andere Back-End-Instanzgruppe oder zonale NEG weiter, die sich möglicherweise in einer anderen Zone befindet. Sie können dies umgehen, indem Sie die richtige Zielkapazität für jedes Back-End anhand Ihrer eigenen Tests angeben.
  • Durch Autoscaling werden Instanzen einer verwalteten Instanzgruppe hinzugefügt oder daraus entfernt. In diesem Fall ändert sich die Anzahl der Instanzen in der Instanzgruppe, sodass der Back-End-Dienst Hashes für die Sitzungsaffinität neu berechnet. Sie können dies umgehen, indem Sie darauf achten, dass die Mindestgröße der verwalteten Instanzgruppe eine typische Last bewältigen kann. Autoscaling wird dann nur bei einer unerwarteten Erhöhung der Last durchgeführt.
  • Wenn eine Back-End-VM oder ein Endpunkt in einer NEG bei Systemdiagnosen durchfällt, leitet der Load-Balancer den Traffic an ein anderes fehlerfreies Back-End weiter. Weitere Informationen zum Verhalten eines Load-Balancers, wenn alle Systemdiagnosen seiner Back-Ends fehlschlagen, finden Sie in der Dokumentation der einzelnen Google Cloud-Load-Balancer.
  • Wenn der Balancing-Modus UTILIZATION für Back-End-Instanzgruppen aktiviert ist, wird die Sitzungsaffinität aufgrund von Änderungen bei der Back-End-Auslastung unterbrochen. Sie können dieses Problem mit dem Balancing-Modus RATE oder CONNECTION beheben, je nachdem, welcher Balancing-Modus vom Load-Balancer-Typ unterstützt wird.

Beachten Sie bei der Verwendung externer Application Load Balancer oder externer Proxy-Network-Load-Balancer die folgenden zusätzlichen Punkte:

  • Wenn sich der Routingpfad von einem Client im Internet zu Google zwischen Anfragen oder Verbindungen ändert, wird möglicherweise ein anderes Google Front End (GFE) als Proxy ausgewählt. Dies kann die Sitzungsaffinität beeinträchtigen.
  • Wenn Sie den Balancing-Modus UTILIZATION verwenden – insbesondere ohne definierte maximale Zielkapazität –, wird die Sitzungsaffinität wahrscheinlich bei einem geringen Traffic zum Load-Balancer unterbrochen. Wechseln Sie in den Balancing-Modus RATE bzw. CONNECTION, wenn der ausgewählte Load-Balancer dies unterstützt.

Zeitlimit für Back-End-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:

  • 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 Backend-Dienst hat für diese Passthrough-Load-Balancer keine Bedeutung.

  • Für Traffic Director 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:

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:

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.

Funktionen zur Trafficverwaltung

Die folgenden Funktionen werden nur für einige Produkte unterstützt:

Diese Features werden von den folgenden Load-Balancern unterstützt:

  • Globaler externer Application Load Balancer (Schutzschaltung wird nicht unterstützt)
  • Regionaler externer Application Load Balancer
  • Regionenübergreifender interner Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Traffic Director (wird jedoch nicht für proxylose gRPC-Dienste unterstützt)

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 Backend-Dienst

Nächste Schritte

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

Ähnliche Videos: