Ü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 Back-End-Dienst ist entweder global oder regional.

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

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

In der folgenden Tabelle wird zusammengefasst, welche Load-Balancer Back-End-Dienste verwenden. Das verwendete Produkt bestimmt auch die maximale Anzahl von Back-End-Diensten, den Umfang eines Back-End-Dienstes, den unterstützten Back-End-Typ und das Load-Balancing-Schema des Back-End-Dienstes. Das Load-Balancing-Schema ist eine Kennzeichnung, mit der Google Weiterleitungsregeln und Back-End-Dienste klassifiziert. Jedes Load-Balancing-Produkt verwendet ein Load-Balancing-Schema für die Weiterleitungsregeln und Back-End-Dienste. Einige Schemas werden von Produkten gemeinsam genutzt.

Tabelle: Back-End-Dienste und unterstützte Back-End-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 Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End (Vorschau)
 EXTERNAL_MANAGED
Klassischer Application Load Balancer Mehrere Global1 Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End
 EXTERN
Regionaler externer Application Load Balancer Mehrere Regional Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End (Vorschau)
 EXTERNAL_MANAGED
Regionenübergreifender interner Application Load Balancer Mehrere Global Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End (Vorschau)
 INTERNAL_MANAGED
Globaler externer Proxy-Network Load Balancer 1 Global1 Der Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Der Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End (Vorschau)
 EXTERNAL_MANAGED
Regionaler interner Proxy-Network-Load-Balancer 1 Regional Der Back-End-Dienst unterstützt eine der folgenden Back-End-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_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 Back-End (Vorschau)
 INTERNAL_MANAGED
Externer Passthrough-Network-Load-Balancer 1 Regional Der Back-End-Dienst unterstützt die folgenden Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends
 EXTERN
Interner Passthrough-Network-Load-Balancer 1 Regional, aber für globalen Zugriff konfigurierbar Der Back-End-Dienst unterstützt eine der folgenden Back-End-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
 INTERN
Traffic Director Mehrere Global Jeder Back-End-Dienst unterstützt eine der folgenden Back-End-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 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 Back-End-Dienste, die von klassischen Application Load Balancern und externen 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 Back-End 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 Back-End-Instanzgruppe oder NEG löschen, die mit einem Back-End-Dienst verknüpft ist. Bevor Sie eine Instanzgruppe oder NEG löschen, müssen Sie sie als Back-End aus allen Back-End-Diensten entfernen, die darauf verweisen.

Instanzgruppen

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

Back-End-VMs und externe IP-Adressen

Back-End-VMs in Back-End-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 Back-End-VMs oder -Endpunkten, indem Pakete an eine interne Adresse gesendet werden, die durch Zusammenführen einer Kennung für das VPC-Netzwerk des Back-Ends mit der internen IPv4-Adresse des Back-Ends erstellt wurde. Bei Back-Ends von Instanzgruppen ist die interne IPv4-Adresse immer die primäre interne IPv4-Adresse, die der nic0-Schnittstelle der VM entspricht. Bei GCE_VM_IP_PORT-Endpunkten in einer zonalen NEG können Sie die IPv4-Adresse des Endpunkts entweder als primäre IPv4-Adresse angeben, die mit einer beliebigen NIC einer VM verknüpft ist, oder als beliebige IPv4-Adresse aus einem Alias-IP-Bereich, die mit einer beliebigen NIC einer VM verknüpft ist. Die Kommunikation zwischen GFEs und Back-End-VMs oder Endpunkten wird durch spezielle Routen ermöglicht.
  • 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 Back-End-VMs oder -Endpunkten, indem Pakete an eine interne Adresse gesendet werden. Diese wird durch Zusammenführen einer Kennung für das VPC-Netzwerk des Back-Ends mit der internen IPv4-Adresse des Back-Ends 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.
    • Bei GCE_VM_IP_PORT-Endpunkten in einer zonalen NEG können Sie die IPv4-Adresse des Endpunkts entweder als primäre IPv4-Adresse der NIC einer VM angeben oder als IPv4-Adresse aus einem Alias-IP-Bereich der NIC einer VM. Dafür muss sich die NIC der VM jedoch im selben Netzwerk wie der Load-Balancer befinden.
  • Für externe Passthrough-Network-Load-Balancer: Clients kommunizieren direkt über die Maglev-Passthrough-Load-Balancing-Infrastruktur von Google mit Back-Ends. Die Pakete werden weitergeleitet und an die nic0-Schnittstelle einer Back-End-VM gesendet, Dabei werden die ursprünglichen Quell- und Ziel-IP-Adressen beibehalten. 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.

Benannte Ports

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

Benannte Ports werden so konfiguriert:

  • An jedem Back-End 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 Back-End der Instanzgruppe.

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

Auf Back-End-Basis pro Instanz übersetzt der Back-End-Dienst den Portnamen in eine Portnummer. Wenn der benannte Port einer Instanzgruppe mit dem --port-name des Back-End-Dienstes übereinstimmt, verwendet der Back-End-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 Back-End-Dienst auf my-service-name gesetzt ist:

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

Ein Back-End-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 Back-End-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 auf Dienstanhänge, die Abstraktionen verwenden, ohne dass ein 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 Back-End für einen bestimmten Back-End-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 Back-End-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/Port-Kombinationen für Google 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 unterstützt).
  • GCE_VM_IP_PORT-Endpunkte

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

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

Internetnetzwerk-Endpunktgruppen

Internet-NEGs sind Ressourcen, die externe Back-Ends definieren. Ein externes Back-End ist ein Back-End, 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-Back-Ends in jedem Bereich unterstützen, finden Sie unter Tabelle: Back-End-Dienste und unterstützte Back-End-Typen.

Weitere Informationen finden Sie unter Internetnetzwerk-Endpunktgruppe.

Serverlose Netzwerk-Endpunktgruppen

Eine Netzwerk-Endpunktgruppe (NEG) ist eine Gruppe von Back-End-Endpunkten für einen Load-Balancer. Eine serverlose NEG ist ein Back-End, 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-Back-Ends unterstützen, finden Sie unter Tabelle: Back-End-Dienste und unterstützte Back-End-Typen.

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

Dienstbindungen

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

Gemischte Back-Ends

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

  • Ein einzelner Back-End-Dienst kann nicht gleichzeitig Instanzgruppen und zonale NEGs verwenden.
  • Sie können jedoch eine Kombination verschiedener Arten von Instanzgruppen für denselben Back-End-Dienst verwenden. Beispielsweise kann ein einzelner Back-End-Dienst auf eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen verweisen. Ausführliche Informationen dazu, welche Back-Ends mit welchen Back-End-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: Back-End-Dienste und unterstützte Back-End-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 Load-Balancing-Schema Protokolloptionen für Back-End-Dienste
Globaler externer Application Load Balancer EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Klassischer Application Load Balancer EXTERN HTTP, HTTPS, HTTP/2
Regionaler externer Application Load Balancer EXTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Regionenübergreifender interner Application Load Balancer
Regionaler interner Application Load Balancer		 INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Externer Proxy-Network-Load-Balancer EXTERN SSL oder TCP
Globaler externer Proxy-Network-Load-Balancer EXTERN TCP oder SSL
Regionaler externer Proxy-Network Load Balancer EXTERNAL_MANAGED TCP
Regionaler interner Proxy-Network Load Balancer INTERNAL_MANAGED TCP
Externer Passthrough-Network Load Balancer EXTERN TCP, UDP oder UNSPECIFIED
Interner Passthrough-Network-Load-Balancer INTERN TCP, UDP oder UNSPECIFIED
Traffic Director INTERNAL_SELF_MANAGED 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 zu diesem Thema 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: Bestimmt die Verteilung der Last anhand der Anzahl gleichzeitiger Verbindungen, die vom Back-End verarbeitet werden können.
  • RATE: Die maximale Anzahl von Anfragen (Abfragen) pro Sekunde (RPS, QPS). Der maximale RPS/QPS-Wert kann überschritten werden, wenn alle Back-Ends die Kapazität erreichen oder überschreiten.
  • UTILIZATION: Bestimmt, wie die Last verteilt wird, basierend auf der Auslastung von Instanzen in einer Instanzgruppe.

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

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

Die Passthrough-Netzwerk-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 Back-End 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 Back-End verwenden, um die Auswahl bestimmter Back-Ends 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 regionalen externen Application Load Balancern, regionalen internen Application Load Balancern und regionenübergreifenden internen Application Load Balancern wird anhand der Zielkapazität des Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends gesendet werden (Instanzgruppe oder NEG) in der Region. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

Die Proxy-Network Load Balancer unterstützen die Balancing-Modi CONNECTION und UTILIZATION für Instanzgruppen-Back-Ends, den Balancing-Modus CONNECTION für zonale NEGs mit GCE_VM_IP_PORT. Endpunkte 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.

  • Für den externen Proxy-Network-Load-Balancer wird eine Region basierend auf dem Standort des Clients und der verfügbaren Kapazität sowie 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 Back-End (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Nachdem der Load-Balancer ein Back-End ausgewählt hat, werden Anfragen oder Verbindungen anschließend in zufälliger Reihenfolge auf VM-Instanzen oder Netzwerkendpunkte innerhalb jedes einzelnen Back-Ends verteilt.

  • Beim regionalen externen Proxy-Network-Load-Balancer und regionalen internen Proxy-Network-Load-Balancer 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 Back-End verfügbaren Load-Balancing-Modi zusammengefasst.

Tabelle: Für jeden Load-Balancer verfügbare Balancing-Modi
Load-Balancer Back-Ends Verfügbare Balancing-Modi
  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer
  • Regionaler externer Application Load Balancer
  • Regionenübergreifender interner Application Load Balancer
  • Regionaler interner 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
  • Regionaler externer Proxy-Network-Load-Balancer
  • Regionaler 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)

Wird nur vom regionalen externen Proxy-Network-Load-Balancer und regionalen internen Proxy-Network-Load-Balancer unterstützt

 CONNECTION
Externer Passthrough-Network-Load-Balancer Instanzgruppen CONNECTION
Interner Passthrough-Network-Load-Balancer 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 regional verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen in verschiedenen Zonen und zonal 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 gleichzeitiger 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
Back-End-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 Instanzgruppe oder das gesamte zonale NEG:

  • In einer 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
Back-End-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 Back-End-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 Back-End-Dienst eine Back-End-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 Back-End-Dienst nur einen möglichen Balancing-Modus hat. Bei anderen ist es jedoch möglich, den Balancing-Modus zu ändern, da diesen Back-End-Diensten je nach verwendetem Back-End 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 Back-End-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
  • Globaler externer Application Load Balancer
  • Klassischer Application Load Balancer
  • Regionaler externer Application Load Balancer
  • Regionenübergreifender interner Application Load Balancer
  • Regionaler interner 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
  • Regionaler externer Proxy-Network-Load-Balancer
  • Regionaler 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)

Wird nur vom regionalen externen Proxy-Network-Load-Balancer und regionalen internen Proxy-Network-Load-Balancer unterstützt

 CONNECTION Sie müssen eine der folgenden Optionen angeben:
  • max-connections pro Hybrid-NEG
  • max-connections-per-endpoint
Interner Passthrough-Network-Load-Balancer 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.
Externer Passthrough-Network-Load-Balancer Instanzgruppe CONNECTION Sie können keine maximale Anzahl von Verbindungen angeben.

Kapazitätsskalierer

Bei bestimmten Proxy-Load-Balancer-Konfigurationen können Sie den Kapazitätsskalierer anpassen, um die effektive Zielkapazität (effektive Zielauslastung, effektive Zielrate oder effektive Zielverbindungen) zu skalieren, ohne einen der --max-*-Parameter explizit zu ändern.

Standardmäßig beträgt der Wert des Kapazitätsskalierers 1.0 (100 %). Sie können den Kapazitätsskalierer auf einen dieser Werte setzen:

  • Genau 0.0, wodurch alle neuen Verbindungen verhindert werden
  • Ein Wert zwischen 0.1 (10 %) und 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, ist max-rate auf 80 RPS festgelegt, und wenn der Kapazitätsskalierer auf 1.0 eingestellt ist, beträgt die effektive Zielkapazität ebenfalls 80 RPS.

  • Wenn der Balancing-Modus RATE lautet, ist max-rate auf 80 RPS festgelegt, und wenn der Kapazitätsskalierer auf 0.5 eingestellt ist, beträgt die effektive Zielkapazität 40 RPS (0.5 times 80).

  • Wenn der Balancing-Modus RATE lautet, ist max-rate auf 80 RPS festgelegt, und wenn der Kapazitätsskalierer auf 0.0 eingestellt ist, beträgt die effektive Zielkapazität null. Ein Kapazitätsskalierer mit dem Wert null entfernt das Back-End aus der Rotation.

Load-Balancing-Richtlinie für Dienste

Eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) ist eine Ressource, die dem Back-End-Dienst des Load Balancers zugeordnet ist. Sie können die Parameter anpassen, die Einfluss darauf haben, wie der Traffic innerhalb der Back-Ends verteilt wird, die einem Back-End-Dienst zugeordnet sind:

  • Passen Sie den Load-Balancing-Algorithmus an, um zu bestimmen, wie der 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 Dienst-Load-Balancing-Richtlinie.

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.

Back-End-Teilmengeneinstellung

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

Die Back-End-Teileinstellung wird für Folgendes unterstützt:

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

Back-End-Teileinstellung für regionale interne Application Load Balancer

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

Bei regionalen internen Application Load Balancern weist die Back-End-Teilmengeneinstellung jeder Proxy-Instanz automatisch nur eine Teilmenge der Back-Ends im regionalen Back-End-Dienst zu. Standardmäßig öffnet jede Proxy-Instanz Verbindungen zu allen Back-Ends innerhalb eines Back-End-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 Back-Ends, wodurch die Anzahl der Verbindungen reduziert wird, die für jedes Back-End offen sind. Wenn Sie die Anzahl der gleichzeitig offenen Verbindungen zu jedem Back-End reduzieren, kann die Leistung sowohl für die Back-Ends als auch für die Proxys verbessert werden.

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

Internen HTTPS-Load-Balancer ohne Back-End-Untereinstellung vergleichen
Internen Application Load Balancer ohne und mit Back-End-Teilmengeneinstellung vergleichen.

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 Back-End-Teilmengeneinstellung für interne Application Load Balancer finden Sie unter Back-End-Teilmengeneinstellung konfigurieren.

Einschränkungen im Zusammenhang mit der Back-End-Teilmengeneinstellung für den internen Application Load Balancer
  • Die Back-End-Teilmengeneinstellung ist zwar so konzipiert, dass alle Back-End-Instanzen weiterhin gut ausgelastet sind, sie kann aber zu einer gewissen Verzerrung des Trafficvolumens führen, das jedes Back-End erhält. Das Festlegen von localityLbPolicy auf LEAST_REQUEST wird für Back-End-Dienste empfohlen, die empfindlich auf die Balance der Back-End-Last reagieren.
  • Durch Aktivieren und Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
  • Die Back-End-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 Back-End-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.

Back-End-Teilmengeneinstellung für internen Passthrough-Network-Load-Balancer

Die Back-End-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 Back-End-VM-Instanzen pro internem Back-End-Dienst zu unterstützen.

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

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

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

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

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 Back-End-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 Back-End-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 Back-End-Dienstprotokoll UNSPECIFIED nicht verwenden.

Preise für Back-End-Teilmengen

Für die Verwendung der Back-End-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 Back-End 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 Back-End-Systemdiagnose, das Hinzufügen oder Entfernen von Back-Ends, oder Änderungen an der Back-End-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 Back-End-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 Back-End-Instanzen oder -Endpunkte konstant bleibt und die zuvor ausgewählte Back-End-Instanz bzw. der Endpunkt nicht ausgelastet ist, werden nachfolgende Anfragen oder Verbindungen an dieselbe Back-End-VM bzw. denselben Endpunkt weitergeleitet. Die Zielkapazität des Balancing-Modus bestimmt, wann das Back-End 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:

  • Einstellungen für die Sitzungsaffinität werden nur erfüllt, wenn die Load-Balancing-Richtlinie für den Ort (localityLbPolicy) auf RING_HASH oder MAGLEV festgelegt ist.
  • 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:

  • Einstellungen für die Sitzungsaffinität werden nur erfüllt, wenn die Load-Balancing-Richtlinie für den Ort (localityLbPolicy) auf RING_HASH oder MAGLEV festgelegt ist.
  • 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
  • Regionaler externer Proxy-Network-Load-Balancer
  • Regionaler 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)

Wenn proxylose gRPC-Dienste konfiguriert sind, unterstützt Traffic Director die Sitzungsaffinität nicht.

1 Diese Tabelle dokumentiert Sitzungsaffinitäten, die von Back-End-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt werden. Zielpoolbasierte externe Passthrough-Network-Load-Balancer verwenden keine Back-End-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:

    • Back-End-Instanzgruppen oder NEGs zum Back-End-Dienst hinzufügen
    • Back-End-Instanzgruppen oder NEGs aus dem Back-End-Dienst entfernen
    • Instanzen zu einer vorhandenen Back-End-Instanzgruppe hinzufügen (dies erfolgt automatisch, wenn Sie das Autoscaling mit verwalteten Instanzgruppen aktivieren)
    • Instanzen aus einer vorhandenen Back-End-Instanzgruppe entfernen (dies erfolgt automatisch, wenn Sie das Autoscaling mit verwalteten Instanzgruppen aktivieren)
    • Endpunkte zu einer vorhandenen Back-End-NEG hinzufügen
    • Endpunkte aus einer vorhandenen Back-End-NEG entfernen
    • Wenn ein fehlerfreies Back-End seine Systemdiagnose nicht besteht und fehlerhaft wird
    • Wenn ein fehlerhaftes Back-End 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 Back-End 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 Back-End-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 Back-End-Instanz weitergeleitet. Client-IP-Affinität ist eine Option für jeden Google Cloud-Load-Balancer, der Back-End-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 Back-End-VM oder denselben Back-End-Endpunkt weiter.

  • Für externe Application Load Balancer lautet das Cookie GCLB.
  • Für regionale externe Application Load Balancer, interne Application Load Balancer und Traffic Director 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 Back-End-Dienste für einen Hostnamen verfügt, teilen alle Back-End-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 Back-End-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 und 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 Back-End-Diensts ein Anfrage-/Antwort-Zeitlimit für HTTP(S)-Traffic.

    Weitere Informationen zum Zeitlimit des Back-End-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 Back-End-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 Traffic Director wird das Zeitlimit-Feld des Back-End-Dienstes (mit timeoutSec angegeben) mit proxylosen gRPC-Diensten nicht unterstützt. Konfigurieren Sie für solche Dienste das Zeitlimit für den Back-End-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 Back-End 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 Back-End-Dienst, dessen Back-Ends Instanzgruppen oder zonale NEGs sind, muss eine zugehörige Systemdiagnose haben. Back-End-Dienste, die eine serverlose NEG oder eine globale Internet-NEG als Back-End 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 Back-End-Dienst mit den Back-Ends 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:

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

  • Wählen Sie Google Cloud Armor-Schutz deaktivieren aus.

Zusätzliche aktivierte Features in der Back-End-Dienstressource

Einige optionale Google Cloud-Features wie Cloud CDN und Google Cloud Armor sind für Back-End-Dienste verfügbar, die von einem globalen externen Application Load Balancer verwendet werden. Google Cloud Armor wird auch bei externen Proxy-Network-Load-Balancern unterstützt.

Weitere Informationen finden Sie unter:

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 Back-End-Dienstressource finden Sie in den folgenden Referenzen:

Nächste Schritte

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

Ähnliche Videos: