Ü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. Die meisten Einstellungen haben Standardwerte, die eine einfache Konfiguration für einen schnellen Start 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.

Die Load-Balancer verwenden die Konfigurationsinformationen in der Back-End-Dienstressource für die folgenden Funktionen:

  • Weiterleiten von Traffic an die richtigen Back-Ends, die Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sind. Beachten Sie, dass ein externer HTTP(S)-Load-Balancer so konfiguriert werden kann, dass er einen Back-End-Bucket anstelle eines Back-End-Dienstes verwendet. 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.
  • Festlegen der Sitzungsaffinität.
  • Bestimmen, ob Cloud CDN aktiviert ist (nur externe HTTP(S)-Load-Balancer).
  • Bestimmen, ob Sicherheitsrichtlinien von Google Cloud Armor aktiviert sind (nur externe HTTP(S)-Load-Balancer).
  • Bestimmen, ob der Identity-Aware Proxy aktiviert ist (nur externe HTTP(S)-Load-Balancer).

Sie legen einige Werte fest, wenn Sie einen Back-End-Dienst erstellen. Sie legen andere Werte fest, wenn Sie einem 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:

Die maximale Anzahl der Back-End-Dienste pro Load-Balancer, der Bereich eines Back-End-Dienstes, der Back-End-Typ, den jeder Back-End-Dienst verwenden kann, und das Load-Balancing-Schema eines Back-End-Dienstes hängen vom Load-Balancer-Typ ab:

Load-Balancer-Typ 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, kann aber für globalen Zugriff konfiguriert werden 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 Ressource, auf die ein Google Cloud-Load-Balancer Traffic verteilt. Jeder Back-End-Dienst ist mit einem oder mehreren kompatiblen Back-Ends verknüpft. Es gibt mehrere Arten von Back-Ends:

Wenn Sie einen Back-End-Bucket anstelle eines Back-End-Dienstes verwenden, können Sie außerdem das Cloud Storage-Bucket-Back-End einrichten.

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

Wenn Sie einen Back-End-Dienst erstellen, müssen Sie das Protokoll angeben, das vom Load-Balancer für die Kommunikation mit den Back-Ends verwendet wird. 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

Welche Protokolle gültig sind, hängt vom Typ des Load-Balancers ab. Weitere Informationen finden Sie unter Load-Balancer-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 zu dieser Verschlüsselung auf Netzwerkebene können Sie ein sicheres Protokoll wie SSL, HTTPS oder HTTP/2 (mit TLS) als Back-End-Dienstprotokoll für die GFE-basierten Load-Balancer sowie für internes 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 der Load-Balancer 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 Zertifikat von einer öffentlichen Zertifizierungsstelle signiert werden und die Validierungsanforderungen erfüllen.

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

  • Sie müssen die Back-End-Dienste Ihres Load-Balancers für die Verwendung des SSL- (TLS), HTTPS- oder HTTP/2-Protokolls konfigurieren.

  • Auf Back-End-Instanzen müssen Sie Software so konfigurieren, dass Traffic mit demselben Protokoll wie der Back-End-Dienst bereitgestellt wird. 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.

  • Sie müssen die auf Ihren Back-End-Instanzen ausgeführte Software so konfigurieren, dass sie als SSL- oder HTTPS-Server ausgeführt wird. Konfigurationsanweisungen finden Sie in der Software-Dokumentation Ihrer Back-End-Instanz.

Beachten Sie auch die folgenden Einschränkungen:

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

  • Wenn ein Load-Balancer eine Verbindung zu Back-Ends innerhalb von Google Cloud herstellt, akzeptiert der Load-Balancer jedes Zertifikat, das von Ihren Back-Ends vorhanden ist. Load-Balancer führen keine Zertifikatsprüfung durch. Beispielsweise wird das Zertifikat auch in folgenden Fällen als gültig erachtet:

    • 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 und interne TCP/UDP-Load-Balancer: Back-End-VMs für interne Load-Balancer benötigen keine externen IP-Adressen.

Benannte Ports

Back-End-Instanzgruppen, die mit einem dieser Load-Balancer-Typen verbunden sind, müssen einen benannten Port haben, der dem benannten Port entspricht, den der Back-End-Dienst des Load-Balancers abonniert hat:

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

Jede Instanzgruppe kann mehrere benannte Ports haben. Ein benannter Port erstellt eine Zuordnung von einem Dienstnamen zu einer Portnummer. Wenn der benannte Port einer Instanzgruppe mit dem benannten Port übereinstimmt, den die Back-End-Dienste abonnieren, wird die benannte Portzuordnung für die Instanzgruppe zur Definition der Portnummer verwendet, die der Back-End-Dienst für die Kommunikation mit den Mitglieds-VMs der Gruppe verwendet.

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

Anschließend legen Sie den benannten Port für den Back-End-Dienst auf my-service-name fest:

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

Hinweis:

  • Jeder Back-End-Dienst abonniert einen einzelnen Portnamen. Daher muss jede seiner Back-End-Instanzgruppen 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 eindeutige 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.

  • Es ist möglich, dieselbe Instanzgruppe als Back-End für mehrere Back-End-Dienste zu verwenden. In dieser Situation müssen alle Back-End-Dienste denselben Balancing-Modus verwenden.

    Dies ist eine komplexe Einrichtung, die nicht immer möglich ist. Beispielsweise kann eine Instanzgruppe nicht gleichzeitig ein Back-End für einen Back-End-Dienst eines internen TCP/UDP-Load-Balancers und eines externen HTTP(S)-Load-Balancers sein. Ein interner TCP/UDP-Load-Balancer verwendet Back-End-Dienste, deren Back-Ends den Balancing-Modus CONNECTION verwenden müssen, während ein externer HTTP(S)-Load-Balancer Back-End-Dienste verwendet, deren Back-Ends entweder den RATE- oder den UTILIZATION-Modus unterstützen können. Da kein Balancing-Modus beiden gemeinsam ist, können Sie nicht dieselbe Instanzgruppe als Back-End für beide Arten von Load-Balancern verwenden.

    • 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 nicht empfohlen, kann aber funktionieren, wenn der Autoscaling-Messwert der verwalteten Instanzgruppe entweder CPU-Auslastung oder ein Cloud Monitoring-Messwert ist, der keinen Bezug zur Bereitstellungskapazität des Load-Balancers hat. Wenn Sie einen dieser Autoscaling-Messwerte verwenden, können Sie die fehlerhafte Skalierung vermeiden, die sich aus dem Autoscaling-Messwert HTTP-Load-Balancing-Auslastung ergibt.

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 Paars IP address:port 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, mit dem der Load-Balancer mögliche Back-Ends für neue Anfragen oder Verbindungen ermittelt.
  • Eine Zielkapazität, die eine maximale Zielanzahl von Verbindungen, eine maximale Zielrate oder die maximale CPU-Zielauslastung definiert.
  • Ein Kapazitätsskalierer, mit dem die insgesamt verfügbare Kapazität angepasst werden kann, 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.

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 Instanzgruppen oder zonale NEGs
  • Externes HTTP(S)-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • Traffic Director
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

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.

Wenn dieselbe Instanzgruppe ein Back-End für mehrere Back-End-Dienste ist, muss sie für jeden Back-End-Dienst denselben Balancing-Modus verwenden. 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 einen.
  • Ä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, sofern sie den neuen Balancing-Modus unterstützen.

Außerdem können Sie dieselbe Instanzgruppe nicht als Back-End für einige Kombinationen von Back-End-Diensten verwenden. Sie können beispielsweise nicht dieselbe Instanzgruppe als Back-End für einen internen TCP/UDP-Load-Balancer verwenden, der nur den CONNECTION-Balancing-Modus unterstützt, und gleichzeitig für einen externen HTTP(S)-Load-Balancer, der entweder den RATE- oder UTILIZATION-Balancing-Modus unterstützt.

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. Mit Ausnahme von internen TCP/UDP-Load-Balancern müssen Sie eine maximale Zielanzahl von Verbindungen mit einer von drei Methoden angeben: Sie können die maximale Anzahl von Verbindungen für jede VM mit max-connections-per-instance oder für jeden Endpunkt in einer zonalen NEG mit max-connections-per-endpoint festlegen. Für zonale NEGs und zonale nicht verwaltete Instanzgruppen können Sie max-connections für die gesamte Gruppe angeben.

    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 müssen eine Zielrate mit einer von drei Methoden angeben: Sie können eine maximale Zielrate für jede VM mit max-rate-per-instance oder für jeden Endpunkt in einer zonalen NEG mit max-rate-per-endpoint angeben. Für zonale NEGs und zonale nicht verwaltete Instanzgruppen können Sie max-rate für die gesamte Gruppe angeben.

    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. Sie können keine Einstellung konfigurieren, die größer als 0.0 und kleiner als 0.1 ist. 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 den Traffic gemäß dem Balancing-Modus des Back-Ends an ein Back-End (Instanzgruppe oder NEG) weiter. Sobald ein Back-End ausgewählt wurde, verteilt Traffic Director den Traffic entsprechend 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 anhand eines 5-Tupel-Hash, der aus der IP-Adresse und dem Quellport des Clients, der IP-Adresse der Weiterleitungsregel und dem Zielport des Load-Balancers sowie dem L3-Protokoll (TCP-Protokoll für alle Load-Balancer, die Back-End-Dienste verwenden) besteht. Der Balancing-Modus der Back-End-Instanzgruppe oder zonalen NEG bestimmt, wann das Back-End ausgelastet ist. Für einige Anwendungen, z. B. für zustandsorientierte Server, die für Anzeigenbereitstellung, Spiele oder Dienste mit hohem internen Caching verwendet werden, ist es aber erforderlich, dass mehrere Anfragen eines Nutzers an dasselbe Back-End oder denselben Endpunkt weitergeleitet werden.

Die Sitzungsaffinität ist für TCP-Traffic verfügbar, einschließlich der Protokolle SSL, HTTP(S) und HTTP/2. Solange eine Back-End-Instanz oder ein Endpunkt gemäß der Definition des Balancing-Modus fehlerfrei bleibt und nicht ausgelastet ist, leitet der Load-Balancer nachfolgende Anfragen an dieselbe Back-End-VM oder denselben Endpunkt weiter. 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.

  • 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 UTILIZATION-Balancing-Modus wird nicht empfohlen, da Ä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 voll sind. Somit kann die Sitzungsaffinität unterbrochen werden. Verwenden Sie stattdessen den RATE- oder CONNECTION-Balancing-Modus, der vom ausgewählten Load-Balancer unterstützt wird, um die Wahrscheinlichkeit einer Unterbrechung der Sitzungsaffinität zu verringern.

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, z. B. wenn ein Mobilgerät von Netzwerk zu Netzwerk wechselt, kann der Load-Balancer über die cookiebasierte Affinität nachfolgende Verbindungen von diesem Client erkennen, statt die Verbindung als neu zu behandeln.

Erstellt ein Load-Balancer ein Cookie für eine generierte cookiebasierte Affinität, wird das Attribut path des Cookies auf / gesetzt. Wenn die URL-Zuordnung des Load-Balancers über einen Pfad-Matcher verfügt, der mehr als einen Back-End-Dienst für einen bestimmten Hostnamen angibt, teilen alle Back-End-Dienste mit cookiebasierter Sitzungsaffinität dasselbe Sitzungs-Cookie.

Die Lebensdauer der vom Load-Balancer generierten HTTP-Cookies ist konfigurierbar. Sie können sie auf 0 (Standard) setzen, d. h., das Cookie ist nur ein Sitzungscookie, oder Sie können 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-Feld-Affinität verwenden, wenn die Load-Balancing-Richtlinie für den Ort RING_HASH oder MAGLEV ist und der konsistente Hash des Back-End-Dienstes den Namen des HTTP-Headers angibt. 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 TCP/UDP-Load-Balancer kann die HTTP-Cookie-Affinität verwenden, wenn die Load-Balancing-Richtlinie für den Ort RING_HASH oder MAGLEV ist und der konsistente Hash des Back-End-Dienstes den Namen des HTTP-Cookies angibt.

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. Ändern Sie für diese Load-Balancer den Zeitlimitwert, wenn Sie mehr oder weniger Zeit für die vollständige Beantwortung der Anfragen durch die Back-Ends einplanen möchten.

  • Wenn die HTTP-Verbindung zu einem WebSocket hochgestuft wird, definiert bei externen HTTP(S)-Load-Balancern das Zeitlimit des Back-End-Dienstes die maximale Zeit, die ein WebSocket geöffnet sein kann, unabhängig davon, ob es inaktiv ist oder nicht.

  • Bei SSL-Proxy-Load-Balancern und TCP-Proxy-Load-Balancern ist das Zeitlimit ein Zeitlimit bei Inaktivität. Ändern Sie für diese Load-Balancer den Zeilimitwert, wenn Sie mehr oder weniger Zeit vor dem Löschen der Verbindung einplanen möchten. Dieses Zeitlimit bei Inaktivität wird auch für WebSocket-Verbindungen verwendet.

  • Interne TCP/UDP-Load-Balancer ignorieren den Wert des Zeitlimits für den Back-End-Dienst.

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 Anfrage-Header sind zusätzliche Header, die der Load-Balancer zu Anfragen hinzufügt.
  • Mit IAP können Sie die Authentifizierung mit einem Google-Konto über einen OAuth 2.0-Anmeldevorgang erzwingen und den Zugriff mithilfe von IAM-Berechtigungen steuern.

Sonstige Hinweise

Die folgenden Features werden nur für interne HTTP(S)-Load-Balancer und Traffic Director unterstützt:

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