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

Sie können einen Back-End-Dienst für die folgenden Google Cloud-Load-Balancing-Dienste konfigurieren:

  • Externes HTTP(S)-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Internes TCP/UDP-Load-Balancing
  • Externes TCP/UDP-Netzwerk-Load-Balancing

Traffic Director verwendet auch Back-End-Dienste.

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. Sie können einen externen HTTP(S)-Load-Balancer so konfigurieren, dass ein Back-End-Bucket anstelle eines Back-End-Dienstes verwendet wird. Informationen zur Verwendung von Back-End-Buckets mit externen HTTP(S)-Load-Balancern finden Sie unter Load-Balancer mit Back-End-Buckets einrichten.
  • 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, ob andere Dienste aktiviert sind, darunter:
    • Cloud CDN (nur externe HTTP(S)-Load-Balancer)
    • Sicherheitsrichtlinien für Google Cloud Armor (nur externe HTTP(S)-Load-Balancer)
    • Identity-Aware Proxy (nur externe HTTP(S)-Load-Balancer)

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

Ein Back-End-Dienst ist entweder global oder regional.

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

Das von Ihnen verwendete Produkt, entweder ein Load-Balancer oder Traffic Director, bestimmt Folgendes:

  • Maximale Anzahl der Back-End-Dienste
  • Bereich eines Back-End-Dienstes
  • Arten der Back-Ends, die jeder Back-End-Dienst verwenden kann
  • Load-Balancing-Schema des Back-End-Dienstes
Produkt Maximale Anzahl der Back-End-Dienste Bereich des Back-End-Dienstes Unterstützte Back-End-Typen Load-Balancing-Schema
Externes HTTP(S)-Load-Balancing Mehrere Global1 Jeder Back-End-Dienst unterstützt diese 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 serverlosen NEGs: Ein oder mehrere App Engine-, Cloud Run- oder Cloud Functions-Dienste
  • Eine Internet-NEG
EXTERN
Internes HTTP(S)-Load-Balancing Mehrere Regional Jeder Back-End-Dienst unterstützt diese Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends oder
  • Alle zonalen NEGs: Eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT
INTERNAL_MANAGED
SSL-Proxy-Load-Balancing 1 Global1 Der Back-End-Dienst unterstützt diese Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends oder
  • Alle zonalen NEGs: Eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT oder
  • Eine Internet-NEG
EXTERN
TCP-Proxy-Load-Balancing 1 Global1 Der Back-End-Dienst unterstützt diese Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends oder
  • Alle zonalen NEGs: Eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT oder
  • Eine Internet-NEG
EXTERN
Netzwerk-Load-Balancing 1 Regional Der Back-End-Dienst unterstützt diese Back-End-Kombination:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends
EXTERN
Internes TCP/UDP-Load-Balancing 1 Regional, aber für globalen Zugriff konfigurierbar Der Back-End-Dienst unterstützt diese Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends oder
  • Alle zonalen NEGs: Eine oder mehrere zonale NEGs des Typs GCE_VM_IP
INTERN
Traffic Director Mehrere Global Jeder Back-End-Dienst unterstützt diese Back-End-Kombinationen:
  • Alle Instanzgruppen-Back-Ends: Ein oder mehrere verwaltete, nicht verwaltete oder eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen-Back-Ends oder
  • Alle zonalen NEGs: Eine oder mehrere zonale NEGs des Typs GCE_VM_IP_PORT
INTERNAL_SELF_MANAGED
1 Von HTTP(S)-Load-Balancing, SSL-Proxy-Load-Balancing und TCP-Proxy-Load-Balancing verwendete Back-End-Dienste sind immer global, entweder in der Standard- oder Premium-Netzwerkstufe. In der Standardstufe gelten jedoch die folgenden Einschränkungen:

Back-Ends

Ein Back-End ist eine Gruppe von 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:

Wenn Sie einen Back-End-Bucket anstelle eines Back-End-Dienstes verwenden, können Sie auch ein Cloud Storage-Bucket-Back-End haben.

Sie können nicht verschiedene Arten von Back-Ends mit demselben Back-End-Dienst verwenden. Ein einzelner Back-End-Dienst kann beispielsweise nicht auf eine Kombination aus Instanzgruppen und zonalen NEGs verweisen. 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.

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.

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.

Produkt Load-Balancing-Schema Protokolloptionen für Back-End-Dienste
Externes HTTP(S)-Load-Balancing EXTERN HTTP, HTTPS, HTTP/2
SSL-Proxy-Load-Balancing EXTERN SSL
TCP-Proxy-Load-Balancing EXTERN TCP
Internes HTTP(S)-Load-Balancing INTERNAL_MANAGED HTTP, HTTPS, HTTP/2
Netzwerk-Load-Balancing EXTERN TCP, UDP oder UNSPECIFIED (Vorschau)
Internes TCP/UDP-Load-Balancing INTERN TCP oder UDP
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.

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:

  • Für externe HTTP(S)-Load-Balancer, SSL-Proxy-Load-Balancer und TCP-Proxy-Load-Balancer: Clients kommunizieren über die externe IP-Adresse Ihres Load-Balancers mit einem Google Front End (GFE). Das GFE kommuniziert mit Back-End-VMs oder Endpunkten über eine Kombination aus einer Kennung für das VPC-Netzwerk des Back-Ends und der internen IP-Adresse der VM oder des Endpunkts. Interne IP-Adressen müssen der primären Netzwerkschnittstelle (nic0) des Back-Ends zugeordnet sein. Die Kommunikation zwischen GFEs und Back-End-VMs oder Endpunkten wird durch besondere Routen erleichtert.
  • Für Netzwerk-Load-Balancer werden Pakete zuerst an die externe IP-Adresse des Netzwerk-Load-Balancers weitergeleitet. Der Load-Balancer verwendet dann konsistentes Hashing, um sie an Back-End-VMs weiterzuleiten.
  • Für interne HTTP(S)-Load-Balancer, interne TCP/UDP-Load-Balancer und Traffic Director: Back-End-VMs benötigen keine externen IP-Adressen.

Benannte Ports

Im Back-End leitet der Load-Balancer den Traffic an die Portnummern weiter, die von den Back-End-Instanzen (Compute Engine-Instanzen) überwacht werden. Sie konfigurieren die Portnummer in der Instanzgruppe und verweisen in der Konfiguration des Back-End-Diensts darauf.

Wenn der benannte Port einer Instanzgruppe mit --port-name in der Konfiguration des Back-End-Diensts übereinstimmt, verwendet der Back-End-Dienst diese Portnummer für die Kommunikation mit den VMs der Instanzgruppe.

Die Back-End-Portnummer wird als benannter Port bezeichnet, da es sich um ein Name/Wert-Paar handelt. In der Instanzgruppe definieren Sie den Schlüsselnamen und den Wert für den Port.

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

Wenn Sie mehrere Portnummern für einen benannten Port (z. B. http:80,http:8080) verwenden, müssen diese alle für dieselbe Anwendung gelten. Dies liegt daran, dass der Traffic zwischen allen Ports mit demselben Portnamen ausgeglichen wird. Sie können beispielsweise keinen benannten Port mit den Werten 80 und 443 erstellen. Dies funktioniert nicht, da Port 80 im Allgemeinen TLS nicht unterstützt.

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

Wichtige Hinweise:

  • Jeder Back-End-Dienst abonniert einen einzelnen Portnamen. Jede seiner Back-End-Instanzgruppen muss mindestens einen benannten Port für diesen Namen haben.

  • 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. Allerdings müssen alle Ports dieselbe Anwendung darstellen. http:80,http:8080 funktioniert beispielsweise, http:80,http:443 funktioniert jedoch nicht.

  • Die aufgelöste Portnummer, die vom Back-End-Dienst verwendet wird, muss nicht mit der von den Weiterleitungsregeln des Load-Balancers verwendeten Portnummer übereinstimmen. Ein Load-Balancer überwacht das Front-End auf eine oder mehrere Portnummern, die Sie in der Weiterleitungsregel des Load-Balancers konfigurieren. Die Back-End-Instanzen können verschiedene Portnummern überwachen.

Benannte Ports werden unter folgenden Umständen nicht verwendet:

  • Für zonale NEG- oder Internet-NEG-Back-Ends, da diese NEGs Ports mit einem anderen Mechanismus definieren, nämlich auf den Endpunkten selbst.
  • Für serverlose NEG-Back-Ends, da diese NEGs keine Endpunkte haben.
  • Für interne TCP/UDP-Load-Balancer, da ein interner TCP/UDP-Load-Balancer ein Durchgangs-Load-Balancer und kein Proxy ist. Sein Back-End-Dienst abonniert auch keinen benannten Port.
  • Für Netzwerk-Load-Balancer, da ein Netzwerk-Load-Balancer ein Durchgangs-Load-Balancer und kein Proxy ist und sein Back-End-Dienst keinen benannten Port abonniert.

Weitere Informationen zu benannten Ports finden Sie in der SDK-Dokumentation unter gcloud compute instance-groups managed set-named-ports und gcloud compute instance-groups unmanaged set-named-ports.

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. Inkompatible Kombinationen sind folgende:

    • CONNECTION mit UTILIZATION
    • RATE mit UTILIZATION

    Dazu ein Beispiel:

    • Sie haben zwei Back-End-Dienste: external-https-backend-service für einen externen HTTP(S)-Load-Balancer und internal-tcp-backend-service für einen internen TCP/UDP-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 TCP/UDP-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.

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

  • GCE_VM_IP-Endpunkte
  • GCE_VM_IP_PORT-Endpunkte

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

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.

Zonale Netzwerk-Endpunktgruppen (NEGs) mit GCE_VM_IP_PORT-Endpunkten können als Back-Ends für die folgenden Load-Balancer-Typen verwendet werden:

  • Internes HTTP(S)-Load-Balancing
  • HTTP(S)-Load-Balancing
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing

Traffic Director unterstützt auch zonale NEG-Back-Ends mit GCE_VM_IP_PORT-Endpunkten.

Zonale Netzwerk-Endpunktgruppen (NEGs) mit GCE_VM_IP-Endpunkten können nur als Back-Ends für das interne TCP/UDP-Load-Balancing verwendet werden.

Zonale NEGs werden vom Netzwerk-Load-Balancing nicht unterstützt.

Weitere Informationen finden Sie unter Netzwerk-Endpunktgruppen im Load-Balancing.

Internetnetzwerk-Endpunktgruppen

Internet-NEGs sind globale Ressourcen, die in der lokalen Infrastruktur oder in der Infrastruktur von Drittanbietern gehostet werden.

Eine Internet-NEG ist eine Kombination aus einer IP-Adresse oder einem Hostnamen sowie einem optionalen Port:

  • Ein öffentlich auflösbarer, vollständig qualifizierter Domainname und ein optionaler Port, z. B. backend.example.com:443 (Standardports: 80 für HTTP und 443 für HTTPS).
  • Eine öffentlich zugängliche IP-Adresse und ein optionaler Port, z. B. 203.0.113.8:80 oder 203.0.113.8:443 (Standardports: 80 für HTTP und 443 für HTTPS).

Ein Back-End-Dienst eines externen HTTP(S)-Load-Balancers, der eine Internetnetzwerk-Endpunktgruppe als Back-End verwendet, verteilt den Traffic an ein Ziel außerhalb von Google Cloud.

Weitere Informationen darüber, welche Load-Balancer Internet-NEGs unterstützen, 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- oder Cloud Functions-Dienst verweist.

Eine serverlose NEG kann Folgendes darstellen:

  • Einen Cloud Run-Dienst oder eine Gruppe von Diensten mit demselben URL-Muster
  • Eine Cloud Functions-Funktion oder eine Gruppe von Funktionen mit demselben URL-Muster
  • Eine App Engine-Anwendung (Standard oder Flex), einen bestimmten Dienst innerhalb einer Anwendung oder sogar eine bestimmte Version einer Anwendung

Weitere Informationen, einschließlich der Load-Balancer, die serverlose NEGs unterstützen, finden Sie unter Übersicht zu serverlosen Netzwerk-Endpunktgruppen.

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

  • CONNECTION
  • RATE
  • UTILIZATION

Die Optionen für den Balancing-Modus hängen vom Load-Balancing-Schema des Back-End-Dienstes, vom Protokoll des Back-End-Dienstes und vom Typ der mit dem Back-End-Dienst verbundenen Back-Ends ab.

Sie legen den Balancing-Modus fest, wenn Sie dem Back-End-Dienst ein Back-End hinzufügen. Beachten Sie, dass Sie keinen Balancing-Modus festlegen können, wenn Sie serverlose NEGs oder Internet-NEGs als Back-Ends für einen Load-Balancer verwenden.

Balancing-Modus Unterstützte Load-Balancing-Schemas Kompatible Back-End-Dienstprotokolle1 Kompatible Back-Ends2 Entsprechende Produkte
CONNECTION EXTERNAL
INTERNAL
SSL, TCP, UDP
Entweder Instanzgruppen oder zonale NEGs, falls unterstützt.
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Internes TCP/UDP-Load-Balancing
  • Netzwerk-Load-Balancing
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP, HTTPS, HTTP2, gRPC Instanzgruppen oder zonale NEGs
  • Externes HTTP(S)-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • Traffic Director (nur INTERNAL_SELF_MANAGED; HTTP-, TCP- und gRPC-Protokolle)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Keine besondere Einschränkung Nur Instanzgruppen. Zonale NEGs unterstützen nicht den Auslastungsmodus.
  • Externes HTTP(S)-Load-Balancing
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • Traffic Director (nur INTERNAL_SELF_MANAGED; HTTP-, TCP- und gRPC-Protokolle)
1 Protokolle sind je nach Art des Load-Balancers weiter eingeschränkt.
2 Informationen zu den unterstützten Back-End-Typen, z. B. Instanzgruppen und zonale NEGs, finden Sie auf der Seite zu Load-Balancer-Funktionen unter Back-Ends.

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 verwaltete regionale Instanzgruppen, verwaltete zonale Instanzgruppen in verschiedenen Zonen und nicht verwaltete zonale Instanzgruppen verwenden. Dieses zonale Ungleichgewicht wird automatisch aufgelöst, wenn mehr Traffic an den Load-Balancer gesendet wird.

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

Balancing-Modus eines Load-Balancers ändern

Bei einigen Load-Balancern 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.

Load-Balancer Back-Ends Verfügbare Balancing-Modi
HTTP(S)-Load-Balancing Instanzgruppen RATE oder UTILIZATION
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte) RATE
Internes HTTP(S)-Load-Balancing Instanzgruppen RATE oder UTILIZATION
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte) RATE
TCP-Proxy-Load-Balancing Instanzgruppen CONNECTION oder UTILIZATION
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte) CONNECTION
SSL-Proxy-Load-Balancing Instanzgruppen CONNECTION oder UTILIZATION
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte) CONNECTION
Netzwerk-Load-Balancing Instanzgruppen CONNECTION
Internes TCP/UDP-Load-Balancing Instanzgruppen CONNECTION
Zonale NEGs (GCE_VM_IP-Endpunkte) CONNECTION

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 TCP/UDP-Load-Balancer und Netzwerk-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
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
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.

Balancing-Modus-Kombinationen

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.

Load-Balancer Typ des Back-Ends Balancing-Modus Zielkapazität
Internes TCP/UDP-Load-Balancing 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.
Externes TCP/UDP-Netzwerk-Load-Balancing Instanzgruppe CONNECTION Sie können keine maximale Anzahl von Verbindungen angeben.
SSL-Proxy-Load-Balancing, TCP-Proxy-Load-Balancing 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:
  • max-utilization
  • max-connections pro zonale Instanzgruppe
  • 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
HTTP(S)-Load-Balancing, internes HTTP(S)-Load-Balancing, 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:
  • max-utilization
  • max-rate pro zonale Instanzgruppe
  • 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

Kapazitätsskalierer

Sie können optional den Kapazitätsskalierer anpassen, um die Zielkapazität (maximale Auslastung, maximale Rate oder maximale Verbindungen) herunterzuskalieren, ohne dabei die Zielkapazität zu ändern. Der Kapazitätsskalierer wird für alle Load-Balancer unterstützt, die eine Zielkapazität unterstützen. Die einzigen Ausnahmen sind der Netzwerk-Load-Balancer und der interne TCP/UDP-Load-Balancer.

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 die maximale 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 die maximale Auslastung 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 die maximale Auslastung 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.

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.

Sitzungsaffinität

Für einige Anwendungen ist es erforderlich, dass mehrere Anfragen eines Nutzers an dasselbe Back-End oder denselben Endpunkt weitergeleitet werden. Zu diesen Anwendungen gehören zustandsorientierte Server, die von der Anzeigenbereitstellung, Spielen oder Diensten mit hohem internen Caching verwendet werden. Der Nachteil der Sitzungsaffinität besteht darin, dass die Last möglicherweise weniger gleichmäßig verteilt ist.

Die Sitzungsaffinität arbeitet auf Best-Effort-Basis, um Anfragen an das Back-End zu senden, von dem die ursprüngliche Anfrage verarbeitet wurde. Die Sitzungsaffinität ist standardmäßig deaktiviert (--session-affinity=NONE). Wenn die Sitzungsaffinität nicht aktiviert ist, verteilen Load-Balancer neue Anfragen wie unten beschrieben anhand eines 5-Tupel-Hashs:

  • 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

Wenn bei Passthrough-Load-Balancern eine Back-End-Instanz oder ein Endpunkt fehlerfrei ist, werden nachfolgende Anfragen an dieselbe Back-End-VM oder denselben Back-End-Endpunkt weitergeleitet.

Wenn bei proxybasierten Load-Balancern eine Back-End-Instanz oder ein Back-End-Endpunkt fehlerfrei ist und genügend Kapazitäten hat, werden nachfolgende Anfragen an dieselbe Back-End-VM oder denselben Back-End-Endpunkt geleitet. Der Balancing-Modus bestimmt, wann das Back-End ausgelastet ist.

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 ein Back-End die Kapazität erreicht bzw. übersteigt oder fehlerhaft wird.

  • Google Cloud-Load-Balancer bieten Sitzungsaffinität auf Best-Effort-Basis. Faktoren wie das Ändern des Status der Back-End-Systemdiagnose oder Änderungen an der Back-End-Auslastung, die vom Balancing-Modus gemessen werden, können die Sitzungsaffinität beeinträchtigen. 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.

  • Wenn Load-Balancer die Sitzungsaffinität aktiviert haben, erfolgt das Load-Balancing bei einer relativ großen Verteilung eindeutiger Sitzungen gut. Ziemlich groß bedeutet mindestens die Anzahl der Back-End-Instanzen in der Instanzgruppe. Wenn Sie einen Load-Balancer mit einer kleinen Anzahl von Sitzungen testen, wird der Traffic nicht gleichmäßig verteilt.

  • Bei externen und internen HTTP(S)-Load-Balancern kann die Sitzungsaffinität gestört werden, wenn der vorgesehene Endpunkt oder die vorgesehene Instanz das maximale Ziel des 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 beim Load-Balancer eingeht, beansprucht die Sitzungsaffinität den Endpunkt, der mit 1,6 RPS verarbeitet wird.
    • Die neue Anfrage kann an den mittleren Endpunkt mit 0,8 RPS gesendet werden.
  • Weitere Informationen zum Netzwerk-Load-Balancing und zur Sitzungsaffinität finden Sie in der Übersicht über das externe TCP/UDP-Netzwerk-Load-Balancing.

  • Spezifische Informationen zum internen TCP/UDP-Load-Balancing und zur Sitzungsaffinität finden Sie in der Übersicht über das interne TCP/UDP-Load-Balancing.

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

Die folgende Tabelle zeigt die Optionen für die Sitzungsaffinität:

Produkt Optionen der Sitzungsaffinität
Internes TCP/UDP-Load-Balancing • Keine (5-Tupel)
• Client-IP-Adresse, Ziel-IP-Adresse (2-Tupel)
• Client-IP-Adresse, Ziel-IP-Adresse, Protokoll (3-Tupel)
• Client-IP-Adresse, Client-Port, Ziel-IP-Adresse, Zielport, Protokoll (5-Tupel)
TCP-Proxy-Load-Balancing
SSL-Proxy-Load-Balancing
• Keine
• Client-IP-Adresse
Externes HTTP(S)-Load-Balancing • Keine
• Client-IP-Adresse
• Generiertes Cookie
Internes HTTP(S)-Load-Balancing • Keine
• Client-IP
• Generiertes Cookie
• Header-Feld
• HTTP-Cookie
Netzwerk-Load-Balancing • Keine (5-Tupel)
• Client-IP-Adresse, Ziel-IP-Adresse (2-Tupel)
• Client-IP-Adresse, Ziel-IP-Adresse, Protokoll (3-Tupel)
• Client-IP-Adresse, Client-Port, Ziel-IP-Adresse, Zielport, Protokoll (5-Tupel)
Traffic Director • Keine
• Client-IP-Adresse
• Generiertes Cookie (nur HTTP-Protokolle)
• Header-Feld (nur HTTP-Protokolle)
• HTTP-Cookie (nur HTTP-Protokolle)

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

Client-IP-Affinität

Mit Client-IP-Affinität 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.

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 HTTP(S)-Load-Balancer lautet das Cookie GCLB.
  • Für interne HTTP(S)-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.

Header-Feld-Affinität

Traffic Director und ein interner HTTP(S)-Load-Balancer können die Header-Feld-Affinität verwenden, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Richtlinie für den Ort ist RING_HASH oder MAGLEV.
  • Der konsistente Hash-Wert des Back-End-Dienstes gibt den Namen des HTTP-Headers an.

Die Header-Feld-Affinität leitet Anfragen an Back-End-VMs oder -Endpunkte in einer zonalen NEG anhand des Werts des im Flag --custom-request-header genannten HTTP-Headers weiter.

Weitere Informationen zum internen HTTP(S)-Load-Balancing, bei dem die Header-Feld-Affinität verwendet wird, finden Sie unter Übersicht über das interne HTTP(S)-Load-Balancing.

Traffic Director und ein interner HTTP(S)-Load-Balancer können die HTTP-Cookie-Affinität verwenden, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Richtlinie für den Ort 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 zum internen HTTP(S)-Load-Balancing, bei dem die HTTP-Cookie-Affinität verwendet wird, finden Sie unter Übersicht über das interne HTTP(S)-Load-Balancing.

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 von HTTP(S)-Load-Balancing, SSL-Proxy-Load-Balancing oder TCP-Proxy-Load-Balancing 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 unterbrechen.
  • 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 HTTP(S)-Load-Balancern und internen HTTP(S)-Load-Balancern, die das HTTP-, HTTPS- oder HTTP/2-Protokoll verwenden, ist das Zeitlimit des Back-End-Dienstes ein Anfrage-/Antwort-Zeitlimit für HTTP(S)-Traffic. Das Zeitlimit definiert, wie lange der Load-Balancer wartet, bis ein Back-End eine vollständige Antwort auf eine Anfrage zurückgibt. Wenn der Wert des Zeitlimits für den Back-End-Dienst beispielsweise der Standardwert 30 Sekunden ist, müssen die Back-Ends innerhalb von 30 Sekunden eine vollständige Antwort auf Anfragen senden. Der Load-Balancer wiederholt die HTTP-GET-Anfrage einmal, wenn das Back-End die Verbindung trennt oder das Zeitlimit überschritten wird, bevor Antwort-Header an den Load-Balancer gesendet werden. Wenn das Back-End Antwort-Header sendet (auch wenn der Antworttext anderweitig unvollständig ist) oder wenn die an das Back-End gesendete Anfrage keine HTTP-GET-Anfrage ist, wiederholt der Load-Balancer die Anfrage nicht. Wenn das Back-End überhaupt nicht antwortet, gibt der Load-Balancer eine HTTP 5xx-Antwort an den Client zurück. Wenn Sie den Zeitraum ändern möchten, innerhalb dessen Back-Ends auf Anfragen antworten sollen, ändern Sie den Zeitlimitwert.

  • Bei HTTP-Traffic entspricht die maximale Zeit, die der Client zum Senden seiner Anfrage benötigt, dem Zeitlimit des Back-End-Diensts. Wenn Sie die HTTP-Antworten 408 mit dem jsonPayload.statusDetail client_timed_out sehen, bedeutet dies, dass beim Weiterleiten der Anfrage vom Client oder der Antwort vom Back-End kein ausreichender Fortschritt erzielt wurde. Wenn das Problem auf Clients zurückzuführen ist, die Leistungsprobleme haben, können Sie dieses Problem beheben, indem Sie das Zeitlimit für den Back-End-Dienst erhöhen.

  • Für externe HTTP(S)-Load-Balancer und interne HTTP(S)-Load-Balancer definiert das Zeitlimit des Back-End-Diensts die maximale Zeitspanne, für die ein WebSocket geöffnet sein kann, wenn die HTTP-Verbindung auf einen WebSocket aktualisiert wird. Dabei spielt es keine Rolle, ob der WebSocket inaktiv ist oder nicht.

  • Bei SSL-Proxy-Load-Balancern und TCP-Proxy-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.

  • Für interne TCP/UDP-Load-Balancer und Netzwerk-Load-Balancer 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.

  • Wenn proxylose gRPC-Dienste konfiguriert sind, unterstützt Traffic Director nicht das im Feld timeoutSec angegebene Zeitlimit für Back-End-Dienste. 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 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 dem gcloud-Befehlszeilentool 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 Back-End-Dienstressource

Die folgenden optionalen Google Cloud-Features sind für Back-End-Dienste verfügbar, die von einem externen HTTP(S)-Load-Balancer verwendet werden. Sie werden nicht in diesem Dokument, aber auf den folgenden Seiten behandelt:

  • Google Cloud Armor schützt mit Sicherheitsrichtlinien vor DDoS und anderen Angriffen.
  • Cloud CDN ist ein System zur Übermittlung von Inhalten mit niedriger Latenz.
  • Benutzerdefinierte Header sind zusätzliche Header, die der Load-Balancer zu Anfragen hinzufügt.
  • Mit IAP können Sie folgende Aufgaben ausführen:
    • Authentifizierung mit einem Google-Konto mit OAuth 2.0-Anmeldung anfordern
    • Zugriff über IAM-Berechtigungen (Identity and Access Management) steuern

Sonstige Hinweise

Die folgenden Funktionen werden nur von internen HTTP(S)-Load-Balancern und Traffic Director unterstützt. Sie werden jedoch nicht unterstützt, wenn Sie proxylose gRPC-Dienste mit Traffic Director verwenden.

  • Load-Balancing-Richtlinien (localityLbPolicy) außer für ROUND_ROBIN
  • Schutzschaltung außer maxRequests-Feld.
  • Ausreißererkennung

Nächste Schritte

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