Ü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

Traffic Director verwendet auch Back-End-Dienste. Netzwerk-Load-Balancing verwendet keinen Back-End-Dienst.

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
  • Art 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
  • 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
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 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 oder
  • Eine Internet-NEG
EXTERN
Internes TCP/UDP-Load-Balancing 1 Regional, aber für globalen Zugriff konfigurierbar 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
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
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.

Es sind folgende Protokolle verfügbar:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP
  • gRPC (nur Traffic Director)

Welche Protokolle gültig sind, hängt vom Typ des Load-Balancers bzw. davon ab, ob Sie Traffic Director verwenden. Weitere Informationen finden Sie unter Load-Balancer-Features und Traffic Director-Features.

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

Beim HTTP(S)-Load-Balancing, TCP-Proxy-Load-Balancing und SSL-Proxy-Load-Balancing verschlüsselt Google automatisch Traffic zwischen Google Front Ends (GFEs) und Ihren Back-Ends, die sich in Google Cloud befinden.

Zusätzlich zur Verschlüsselung auf Netzwerkebene können Sie ein sicheres Protokoll als Back-End-Dienstprotokoll verwenden. Zu den sicheren Protokollen gehören SSL, HTTPS oder HTTP/2 (mit TLS). Sie können sie für die GFE-basierten Load-Balancer sowie für das interne HTTP(S)-Load-Balancing und Traffic Director verwenden.

Wenn ein Load-Balancer über ein sicheres Back-End-Dienstprotokoll eine Verbindung zu Ihren Back-Ends herstellt, ist das GFE der SSL- oder HTTPS-Client. Ebenso ist der Proxy der SSL- oder HTTPS-Client, wenn ein clientseitiger Proxy, der mit Traffic Director konfiguriert ist, über ein sicheres Back-End-Dienstprotokoll eine Verbindung zu Ihren Back-Ends herstellt.

In den folgenden Fällen wird ein sicheres Protokoll für die Verbindung mit Back-End-Instanzen empfohlen:

  • Wenn Sie eine prüfbare, verschlüsselte Verbindung vom Load-Balancer (oder Traffic Director) zu den Back-End-Instanzen benötigen.

  • Wenn der Load-Balancer eine Verbindung zu einer Back-End-Instanz außerhalb von Google Cloud herstellt (über eine Internet-NEG). Die Kommunikation mit einem Internet-NEG-Back-End kann das öffentliche Internet übertragen. Wenn der Load-Balancer eine Verbindung zu einer Internet-NEG herstellt, muss das von der Zertifizierungsstelle signierte Zertifikat die Validierungsanforderungen erfüllen.

Beachten Sie die folgenden Anforderungen, um ein sicheres Protokoll zwischen dem Load-Balancer und Ihren Back-Ends zu verwenden:

  • Die Back-End-Dienste Ihres Load-Balancers müssen das SSL (TLS)-, HTTPS- oder HTTP/2-Protokoll verwenden.

  • Software der Back-End-Instanz muss Traffic mit demselben Protokoll wie der Back-End-Dienst bereitstellen. Wenn der Back-End-Dienst beispielsweise HTTPS verwendet, müssen Sie Ihre Back-End-Instanzen für die Verwendung von HTTPS konfigurieren. Wenn Sie das HTTP/2-Protokoll verwenden, müssen Ihre Back-Ends TLS verwenden. Konfigurationsanweisungen finden Sie in der Software-Dokumentation Ihrer Back-End-Instanz.

  • Sie müssen private Schlüssel und Zertifikate auf Ihren Back-End-Instanzen installieren. Diese Zertifikate müssen nicht mit dem SSL-Zertifikat des Load-Balancers übereinstimmen. Installationsanweisungen finden Sie in der Dokumentation der Back-End-Instanz.

  • Die auf Ihren Back-End-Instanzen ausgeführte Software muss als SSL- oder HTTPS-Server ausgeführt werden. Konfigurationsanweisungen finden Sie in der Software-Dokumentation Ihrer Back-End-Instanz.

Bei der Verwendung von Instanzgruppen- oder zonalen NEG-Back-Ends ist Folgendes zu beachten:

  • Wenn ein GFE eine TLS-Sitzung für Back-Ends startet, verwendet das GFE nicht die Erweiterung "Server Name Indication" (SNI).

  • Wenn ein GFE eine Verbindung zu Back-Ends in Google Cloud herstellt, akzeptiert das GFE alle Zertifikate, die von Ihren Back-Ends vorhanden sind. Die GFEs führen keine Zertifikatsprüfung durch. Beispielsweise gilt das Zertifikat auch in folgenden Fällen als gültig:

    • Bei einem selbst signierten Zertifikat.
    • Wenn das Zertifikat von einer unbekannten Zertifizierungsstelle signiert wurde.
    • Wenn das Zertifikat abgelaufen oder noch nicht gültig ist.
    • Wenn die Attribute CN und subjectAlternativeName nicht mit einem Host-Header oder DNS-PTR-Eintrag übereinstimmen.
Weitere Informationen zur Verschlüsselung von Google finden Sie unter Verschlüsselung bei der Übertragung in Google Cloud.

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 über die internen IP-Adressen der primären Netzwerkschnittstelle mit Back-End-VMs oder -Endpunkten. Da das GFE ein Proxy ist, benötigen die Back-End-VMs selbst keine externen IP-Adressen.

  • Für interne HTTP(S)-Load-Balancer, interne TCP/UDP-Load-Balancer und Traffic Director: Back-End-VMs für interne Load-Balancer und Traffic Director benötigen keine externen IP-Adressen.

Benannte Ports

Ein Load-Balancer kann das Front-End auf einer oder mehreren Portnummern überwachen, die in der Weiterleitungsregel des Load-Balancers angegeben sind. Auf dem Back-End kann der Load-Balancer Traffic an dieselbe oder an eine andere Portnummer weiterleiten. Ihre Back-End-Instanzen (Compute Engine-Instanzen) überwachen diese Portnummer. Sie konfigurieren diese Portnummer in der Instanzgruppe und verweisen in der Konfiguration des Back-End-Diensts darauf.

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. Dann verweisen Sie in der Konfiguration des Back-End-Diensts auf den benannten Port.

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.

Für die folgenden Load-Balancer-Typen muss jede Back-End-Instanzgruppe von Compute Engine einen benannten Port haben:

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

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

Sie können den benannten Port beispielsweise für eine Instanzgruppe wie nachfolgend beschrieben festlegen, wobei der Dienstname my-service-name und der Port 8888 lautet:

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

Legen Sie dann --port-name für den Back-End-Dienst auf my-service-name fest:

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

Wichtige Hinweise:

  • Jeder Back-End-Dienst abonniert einen einzelnen Portnamen. Jede der 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.

  • Die aufgelöste Portnummer, die vom Back-End-Dienst verwendet wird, muss nicht mit der von den Weiterleitungsregeln des Load-Balancers verwendeten Portnummer übereinstimmen.

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 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. Um den Traffic auf verschiedene Ports zu verteilen, erstellen Sie die erforderlichen benannten Ports in der einen Instanzgruppe und zwingen Sie jeden Back-End-Dienst einen eindeutig benannten Port zu 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 CPU-Auslastung oder ein Cloud Monitoring-Messwert ist, der keinen Bezug zur Bereitstellungskapazität des Load-Balancers hat. Die Verwendung eines dieser Autoscaling-Messwerte verhindert möglicherweise eine fehlerhafte Skalierung.

Zonale Netzwerk-Endpunktgruppen

Ein Back-End-Dienst, der zonale Netzwerk-Endpunktgruppen (NEGs) als Back-Ends verwendet, verteilt den Traffic auf Anwendungen oder Container, die in VMs ausgeführt werden.

Ein zonaler Netzwerkendpunkt ist eine Kombination aus einer IP-Adresse und einem Port, der auf zwei Arten festgelegt werden kann:

  • Durch Angabe eines IP address:port-Paars wie 10.0.1.1:80.
  • Durch Angabe nur einer IP-Adresse für den Netzwerkendpunkt. Der Standardport für die NEG wird automatisch als Port des Paars IP address:port verwendet.

Netzwerkendpunkte stellen Dienste gemäß ihrer IP-Adresse und ihres Ports dar und verweisen nicht auf eine bestimmte VM. Eine Netzwerk-Endpunktgruppe (NEG) ist eine logische Zusammenstellung von Netzwerkendpunkten.

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 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 finden Sie unter Übersicht über serverlose Netzwerk-Endpunktgruppen.

Trafficverteilung

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 für eine serverlose NEG festlegen können.

Balancing-Modus Unterstützte Load-Balancing-Schemas Unterstützte Back-End-Dienstprotokolle Unterstützte Back-End-Typen Entsprechende Produkte
CONNECTION EXTERNAL
INTERNAL
SSL-, TCP-, UDP-
Protokolloptionen sind durch den Typ des Load-Balancers begrenzt. Beispielsweise verwendet das interne TCP/UDP-Load-Balancing nur das TCP- oder UDP-Protokoll.
Entweder Instanzgruppen oder zonale NEGs, falls unterstützt.
Internes TCP/UDP-Load-Balancing unterstützt z. B. keine zonalen NEGs.
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Internes TCP/UDP-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- und gRPC-Protokolle)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
Beliebiges Protokoll Nur Instanzgruppen. Zonale NEGs unterstützen nicht den Auslastungsmodus.
  • Externes HTTP(S)-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Traffic Director (nur INTERNAL_SELF_MANAGED; HTTP- und gRPC-Protokolle)

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:

  • Die Back-End-Dienste für interne TCP/UDP-Load-Balancer können nur den CONNECTION-Balancing-Modus verwenden.
  • Die Back-End-Dienste für externe HTTP(S)-Load-Balancer, bei denen alle Back-Ends NEGs sind, können nur den RATE-Balancing-Modus verwenden.
  • Die Back-End-Dienste für interne HTTP(S)-Load-Balancer, bei denen alle Back-Ends NEGs sind, können nur den RATE-Balancing-Modus verwenden.
  • Die Back-End-Dienste für SSL-Proxy-Load-Balancer, bei denen alle Back-Ends NEGs sind, können nur den CONNECTION-Balancing-Modus verwenden.
  • Die Back-End-Dienste für TCP-Proxy-Load-Balancer, bei denen alle Back-Ends NEGs sind, können nur den CONNECTION-Balancing-Modus verwenden.

Bei einigen Load-Balancern können Sie den Balancing-Modus ändern, da für ihre Back-End-Dienste mehrere Modi verfügbar sind:

  • Die Back-End-Dienste für externe HTTP(S)-Load-Balancer, bei denen alle Back-Ends Instanzgruppen sind, können den RATE- oder UTILIZATION-Balancing-Modus verwenden.
  • Die Back-End-Dienste für interne HTTP(S)-Load-Balancer, bei denen alle Back-Ends Instanzgruppen sind, können den RATE- oder UTILIZATION-Balancing-Modus verwenden.
  • Die Back-End-Dienste für SSL-Proxy-Load-Balancer, bei denen alle Back-Ends Instanzgruppen sind, können den CONNECTION- oder UTILIZATION-Balancing-Modus verwenden.
  • Die Back-End-Dienste für TCP-Proxy-Load-Balancer, bei denen alle Back-Ends Instanzgruppen sind, können den CONNECTION- oder UTILIZATION-Balancing-Modus verwenden.

Zielkapazität

Jeder Balancing-Modus hat eine entsprechende Zielkapazität, die eine maximale Zielanzahl von Verbindungen, eine maximale Zielrate oder eine maximale CPU-Auslastung definiert. Für jeden Balancing-Modus ist die Zielkapazität kein Schutzschalter. Ein Load-Balancer überschreitet unter bestimmten Bedingungen den Maximalwert. Dies ist beispielsweise der Fall, wenn alle Back-End-VMs oder -Endpunkte diesen Wert erreicht haben.

  • Im CONNECTION-Balancing-Modus definiert die Zielkapazität eine maximale Zielanzahl gleichzeitiger Verbindungen. Sie können eine der folgenden Einstellungen verwenden:

    • max-connections-per-instance (pro VM)
    • max-connections-per-endpoint (pro Endpunkt in einer zonalen NEG)
    • max-connections (pro zonale NEGs und für nicht verwaltete Instanzgruppen für die gesamte Gruppe)

    Wenn Sie max-connections-per-instance oder max-connections-per-endpoint angeben, berechnet Google Cloud das effektive Ziel pro VM oder pro Endpunkt so:

    • (max. Anzahl Verbindungen pro VM * Gesamtzahl der VMs)/Anzahl fehlerfreier VMs
    • (max. Anzahl Verbindungen pro Endpunkt * Gesamtzahl der Endpunkte)/Anzahl der fehlerfreien Endpunkte

    Wenn Sie max-connections angeben, berechnet Google Cloud das effektive Ziel pro VM oder pro Endpunkt so:

    • max. Anzahl Verbindungen/Anzahl fehlerfreier VMs
    • max. Anzahl Verbindungen/Anzahl fehlerfreier Endpunkte
  • Im RATE-Balancing-Modus definiert die Zielkapazität eine maximale Zielrate für HTTP-Anfragen. Sie können eine der folgenden Einstellungen verwenden:

    • max-rate-per-instance (für jede VM)
    • max-rate-per-endpoint (für jeden Endpunkt in einer zonalen NEG)
    • max-rate (für zonale NEGs und zonale nicht verwaltete Instanzgruppen für die gesamte Gruppe)

    Wenn Sie max-rate-per-instance oder max-rate-per-endpoint angeben, berechnet Google Cloud die effektive Zielrate pro VM oder pro Endpunkt folgendermaßen:

    • max. Rate pro VM * Gesamtzahl der VMs/Anzahl fehlerfreier VMs
    • max. Rate pro Endpunkt * Gesamtzahl der Endpunkte/Anzahl fehlerfreier Endpunkte

    Wenn Sie max-rate angeben, berechnet Google Cloud die effektive Zielrate pro VM oder Endpunkt so:

    • max. Rate/Anzahl fehlerfreier VMs
    • max. Rate/Anzahl fehlerfreier Endpunkte
  • Für den UTILIZATION-Balancing-Modus gibt es keine obligatorische Zielkapazität. Sie haben eine Reihe von Optionen, die vom Typ des Back-Ends abhängen, wie die folgende Tabelle zeigt.

In dieser Tabelle werden alle möglichen Balancing-Modi für einen bestimmten Load-Balancer und Back-End-Typ erläutert. Außerdem werden die verfügbaren oder erforderlichen Kapazitätseinstellungen dargestellt, die Sie in Verbindung mit dem Balancing-Modus angeben 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.
SSL-Proxy-Load-Balancing, TCP-Proxy-Load-Balancing Instanzgruppe CONNECTION Sie müssen eine der folgenden Optionen angeben:
1. max. Anzahl Verbindungen pro zonaler Instanzgruppe
2. max. Anzahl Verbindungen pro Instanz
 (zonale oder regionale Instanzgruppen)
UTILIZATION Sie können optional eine der folgenden Optionen angeben:
1. Maximale Auslastung
2. Maximale Anzahl Verbindungen pro zonaler Instanzgruppe
3. Maximale Anzahl Verbindungen pro Instanz
 (zonale oder regionale Instanzgruppen)
4. 1 und 2 zusammen
5. 1 und 3 zusammen
Zonale NEG CONNECTION Sie müssen eine der folgenden Optionen angeben:
1. max. Anzahl Verbindungen pro zonaler NEG
2. max. Anzahl Verbindungen pro Endpunkt
HTTP(S)-Load-Balancing, internes HTTP(S)-Load-Balancing, Traffic Director Instanzgruppe RATE Sie müssen eine der folgenden Optionen angeben:
1. max. Rate pro zonaler Instanzgruppe
2. max. Rate pro Instanz
 (zonale oder regionale Instanzgruppen)
UTILIZATION Sie können optional eine der folgenden Optionen angeben:
1. maximale Auslastung
2. maximale Rate pro zonaler Instanzgruppe
3. maximale Rate pro Instanz
 (zonale oder regionale Instanzgruppen)
4. 1 und 2 zusammen
5. 1 und 3 zusammen
Zonale NEG RATE Sie müssen eine der folgenden Optionen angeben:
1. max. Rate pro zonaler NEG
2. max. Rate pro Endpunkt

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 einzige Ausnahme ist der interne TCP/UDP-Load-Balancer.

Der Kapazitätsskalierer ist standardmäßig auf 1.0 (100 %) eingestellt. Wenn die aktuelle Auslastung einer Back-End-Instanz beispielsweise 80 % beträgt und die maximale Auslastung auf 80 % festgelegt ist, sendet der Back-End-Dienst keine Anfragen mehr an diese Instanz:

capacity-scaler: 1 * 0.8

Sie können den Kapazitätsskalierer auf 0.0 oder auf einen Wert zwischen 0.1 (10 %) und 1.0 (100 %) festlegen. Ein Skalierungsfaktor von null (0.0) verhindert alle neuen Verbindungen. Sie können die Einstellung 0.0 nicht konfigurieren, wenn nur ein Back-End mit dem Back-End-Dienst verbunden ist.

Kapazitätsskalierung verwenden, wenn zwei Back-End-Dienste ein Instanzgruppen-Back-End gemeinsam nutzen

Wenn zwei Back-End-Dienste dasselbe Instanzgruppen-Back-End verwenden, müssen Sie die Kapazität der Instanzgruppe auf die beiden Back-End-Dienste aufteilen.

Sie können beispielsweise den Kapazitätsskalierer für beide Back-End-Dienste auf 0.5 setzen und jeder Back-End-Dienst erhält 40 % der Kapazität der Instanzgruppe:

capacity-scaler: 0.5 * 0.8

Wenn jeder Back-End-Dienst 40 % der Kapazität der Instanzgruppe verbraucht hat, werden keine Anfragen mehr an diese Instanzgruppe gesendet.

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

Ohne Sitzungsaffinität verteilen Load-Balancer neue Anfragen so anhand eines 5-Tupel-Hash-Werts:

  • IP-Adresse des Clients
  • Quellport des Clients
  • IP-Adresse der Weiterleitungsregel des Load-Balancers
  • Zielport des Load-Balancers
  • Layer-3-Protokoll (TCP-Protokoll für alle Load-Balancer, die Back-End-Dienste verwenden)

Der Balancing-Modus der Back-End-Instanzgruppe oder zonalen NEG bestimmt, wann das Back-End ausgelastet ist. 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.

Die Sitzungsaffinität ist für TCP-Traffic verfügbar, einschließlich der Protokolle SSL, HTTP(S) und HTTP/2. Wenn eine Back-End-Instanz oder ein Back-End fehlerfrei und nicht entsprechend dem Load-Balancing-Modus ausgelastet ist, werden nachfolgende Anfragen an dieselbe Back-End-VM oder denselben Back-End-Endpunkt weitergeleitet. Beachten Sie beim Konfigurieren der Sitzungsaffinität Folgendes:

  • UDP-Traffic hat nicht das Konzept einer Sitzung. Daher ist die Sitzungsaffinität für diese Art von Traffic nicht sinnvoll.

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

  • 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 an Back-End-VMs weiterleitet, die weniger ausgelastet sind. Dadurch wird die Sitzungsaffinität aufgehoben. Verwenden Sie stattdessen den Balancing-Modus RATE oder CONNECTION, um die Aufteilung der Sitzungsaffinität zu reduzieren.

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

Produkt Optionen der Sitzungsaffinität
Internes TCP/UDP • Keine
• Client-IP-Adresse
• Client-IP-Adresse und Protokoll
• IP-Adresse, Protokoll und Port des Clients
TCP-Proxy
SSL-Proxy
• Keine
• Client-IP-Adresse
Externes HTTP(S) • Keine
• Client-IP-Adresse
• Generiertes Cookie
Internes HTTP(S) • Keine
• Client-IP
• Generiertes Cookie
• Header-Feld
• HTTP-Cookie
Netzwerk Das Netzwerk-Load-Balancing verwendet keine Back-End-Dienste. Stattdessen müssen Sie die Sitzungsaffinität für das Netzwerk-Load-Balancing über Zielpools festlegen. Weitere Informationen finden Sie beim Parameter sessionAffinity unter Zielpools.
Traffic Director • Keine
• Client-IP
• Generiertes Cookie
• Header-Feld
• HTTP-Cookie

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 nachfolgende Verbindungen von diesem Client erkennen, anstatt die Verbindung als neu zu behandeln. Beispiel: Ein Client ändert seine IP-Adresse, wenn ein Mobilgerät von einem Netzwerk zu einem anderen wechselt.

Erstellt ein Load-Balancer ein Cookie für eine generierte cookiebasierte Affinität, wird das Attribut path des Cookies auf / gesetzt. Wenn der Pfad-Matcher der URL-Zuordnung ü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 (24 Stunden) festlegen.

Header-Feld-Affinität

Ein interner HTTP(S)-Load-Balancer kann die Header-Affinität verwenden, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Standortrichtlinie 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.

Ein interner HTTP(S)-Load-Balancer kann die HTTP-Cookie-Affinität verwenden, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Standortrichtlinie 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 stattdessen zum Balancing-Modus RATE oder CONNECTION.

Zeitlimit für Back-End-Dienste

Die meisten Google Cloud-Load-Balancer haben ein Zeitlimit für den Back-End-Dienst. Der Standardwert beträgt 30 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.

  • Bei internen TCP/UDP-Load-Balancern hat das Zeitlimit des Back-End-Dienstes keine Auswirkungen.

  • Wenn proxylose gRPC-Dienste konfiguriert sind, unterstützt Traffic Director das Zeitlimit für Back-End-Dienste nicht.

Systemdiagnosen

Jeder Back-End-Dienst, dessen Back-Ends Instanzgruppen oder zonale NEGs sind, muss eine zugehörige Systemdiagnose haben. Back-End-Dienste, die 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 HTTP(S)-Load-Balancing 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.

  • Schutzschaltung
  • Ausreißererkennung
  • Load-Balancing-Richtlinien
  • Cookiebasierte HTTP-Sitzungsaffinität
  • Header-basierte HTTP-Sitzungsaffinität

Weitere Informationen

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