Übersicht über externen Application Load Balancer

In diesem Dokument werden die grundlegenden Konzepte zum Konfigurieren eines externen Application Load Balancers vorgestellt.

Ein externer Application Load Balancer ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Der externe Application Load Balancer verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine, Google Kubernetes Engine (GKE), Cloud Storage usw. gehostet werden, sowie auf externe Back-Ends, die über das Internet oder Hybridkonnektivität verbunden sind. Weitere Informationen finden Sie unter Application Load Balancer: Anwendungsfälle.

Betriebsarten

Sie können einen externen Application Load Balancer in den folgenden Modi konfigurieren:

• Globale externe Application Load Balancer. Dies ist ein globaler Load-Balancer, der als verwalteter Dienst auf Google Front Ends (GFEs) implementiert ist. Der Open-Source-Envoy-Proxy unterstützt erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung, anfrage- und antwortbasierte Header-Transformationen und mehr.
• Klassische Application Load Balancer. Dies ist der klassische externe Application Load Balancer, der in der Premium-Stufe global ist, aber als regionale Standardstufe konfiguriert werden kann. Dieser Load-Balancer ist auf Google Front Ends (GFEs) implementiert. GFEs sind global verteilt und arbeiten über das globale Netzwerk und die Steuerungsebene von Google zusammen.
• Regionaler externer Application Load Balancer Dies ist ein regionaler Load-Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung, Anfrage/Antwort-basierte Headertransformationen und mehr.

Load-Balancer-Modus	Empfohlene Anwendungsfälle	Leistungsspektrum
Globaler externer Application Load Balancer	Verwenden Sie diesen Load-Balancer für externe HTTP(S)-Arbeitslasten mit global verteilten Nutzern oder Backend-Diensten in mehreren Regionen.	Kompatibel mit GKE mithilfe von Gateway (vollständig orchestriert) oder eigenständigen NEGs (manuelle Orchestrierung). Unterstützt die erweiterte Trafficverwaltung Globale externe Anycast-IP-Adressen über Premium-Stufe Kann auf Back-Ends über mehrere Regionen zugreifen Unterstützt Cloud CDN. Unterstützt Google Cloud Armor
Klassischer Application Load Balancer	Dieser Load Balancer ist in der Premium-Stufe global. In der Premium-Netzwerkdienststufe bietet dieser Load-Balancer multiregionales Load-Balancing, versucht, Traffic an das nächstgelegene fehlerfreie Backend mit Kapazität weiterzuleiten, und beendet HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern. Weitere Informationen zur Anfrageverteilung finden Sie unter Trafficverteilung. In der Standard-Netzwerkdienststufe kann dieser Load Balancer Traffic nur an Back-Ends in einer einzelnen Region verteilen.	Kompatibel mit GKE mithilfe von Gateway (vollständig orchestriert), Ingress (vollständig orchestriert) oder eigenständigen NEGs (manuelle Orchestrierung). Unterstützt Google Cloud Armor Weniger Traffic-Routing-Features Eine vollständige Liste der Funktionen finden Sie auf der Seite Load-Balancing-Features.
Regionaler externer Application Load Balancer	Dieser Load Balancer enthält viele Features des bestehenden klassischen Application Load Balancers sowie erweiterte Funktionen für die Trafficverwaltung. Verwenden Sie diesen Load Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen möchten, um beispielsweise Compliance-Bestimmungen zu erfüllen. Dieser Load Balancer kann entweder in der Premium- oder der Standardstufe konfiguriert werden.	Kompatibel mit GKE mithilfe von eigenständigen NEGs (manuelle Orchestrierung) Unterstützt erweiterte Funktionen zur Trafficverwaltung Regionale VIPs in der Standard-Netzwerkstufe Terminiert TLS in einer von Ihnen konfigurierten Region Stellt nur Inhalte aus der konfigurierten Region bereit Eine vollständige Liste finden Sie unter Load-Balancing-Features.

Modus bestimmen

Cloud Console

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

   Load-Balancing aufrufen

2. Auf dem Tab Load-Balancer werden der Typ, das Protokoll und die Region des Load-Balancers angezeigt. Wenn die Region leer ist, ist der Load-Balancer global. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

Load-Balancer-Modus	>Load Balancer-Typ	Zugriffstyp	Region
Globaler externer Application Load Balancer	Anwendung	Extern
Klassischer Application Load Balancer	Anwendung (klassisch)	Extern
Regionaler externer Application Load Balancer	Anwendung	Extern	Gibt eine Region an

gcloud

1. Führen Sie den folgenden Befehl aus, um den Modus eines Load-Balancers zu bestimmen:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Prüfen Sie in der Befehlsausgabe das Load-Balancing-Schema, die Region und die Netzwerkstufe. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

Load-Balancer-Modus	Load-Balancing-Schema	Weiterleitungsregel	Netzwerkstufe
Globaler externer Application Load Balancer	EXTERNAL_MANAGED	Global	Premium
Klassischer Application Load Balancer	EXTERN	Global	Standard oder Premium
Regionaler externer Application Load Balancer	EXTERNAL_MANAGED	Gibt eine Region an	Standard oder Premium

Wichtig: Nachdem Sie einen Load-Balancer erstellt haben, können Sie seinen Modus nicht mehr bearbeiten. Stattdessen müssen Sie den Load-Balancer löschen und einen neuen erstellen.

Architektur

Die folgenden Ressourcen sind für die Bereitstellung eines externen Application Load Balancers erforderlich:

• Bei regionalen externen Application Load Balancern ausschließlich wird ein Nur-Proxy-Subnetz verwendet, um Verbindungen vom Load-Balancer zu den Back-Ends zu senden.

• Eine externe Weiterleitungsregel gibt eine externe IP-Adresse, einen Port und einen HTTP(S)-Ziel-Proxy an. Clients verwenden die IP-Adresse und den Port, um eine Verbindung zum Load-Balancer herzustellen.

• Ein HTTP(S)-Ziel-Proxy empfängt eine Anfrage vom Client. Der HTTP(S)-Proxy wertet die Anfrage mithilfe der URL-Zuordnung aus, um Entscheidungen zum Routing des Traffics zu treffen. Der Proxy kann auch die Kommunikation mithilfe von SSL-Zertifikaten authentifizieren.

  • Beim HTTPS-Load-Balancing verwendet der HTTPS-Zielproxy SSL-Zertifikate, um seine Identität gegenüber Clients nachzuweisen. Ein HTTPS-Zielproxy unterstützt bis zu einer dokumentierten Anzahl von SSL-Zertifikaten.

• Der HTTP(S)-Proxy verwendet eine URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Basierend auf der Routingentscheidung leitet der Proxy Clientanfragen an bestimmte Back-End-Dienste oder Back-End-Buckets weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, z. B. Weiterleitungen an Clients.

• Ein Backend-Dienst verteilt Anfragen an fehlerfreie Backends. Die globalen externen Application Load Balancer unterstützen auch Backend-Buckets. Ein oder mehrere Back-Ends müssen mit dem Back-End-Dienst oder Back-End-Bucket verbunden sein.

• Eine Systemdiagnose überwacht regelmäßig die Bereitschaft Ihrer Back-Ends. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können.

• Firewallregeln für Ihre Back-Ends, um Systemdiagnoseprüfungen zu akzeptieren. Regionale externe Application Load Balancer erfordern eine zusätzliche Firewallregel, damit Traffic vom Nur-Proxy-Subnetz die Back-Ends erreichen kann.

Global

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines globalen externen Application Load Balancers. Diese Architektur gilt sowohl für den globalen externen Application Load Balancer als auch für den klassischen Application Load Balancer in der Premium-Stufe.

Komponenten eines globalen externen Application Load Balancers (zum Vergrößern klicken).

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen Application Load Balancers.

Komponenten eines regionalen externen Application Load Balancers (zum Vergrößern klicken).

Nur-Proxy-Subnetz

Nur-Proxy-Subnetze sind nur für regionale externe Application Load Balancer erforderlich.

Das Nur-Proxy-Subnetz stellt eine Reihe von IP-Adressen bereit, die Google zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie regionale externe Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in derselben Region und demselben VPC-Netzwerk teilen einen Pool von Envoy-Proxys aus demselben Nur-Proxy-Subnetz. Weiter:

• Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
• Backend-VMs bzw. Endpunkte aller regionalen externen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
• Die IP-Adresse des regionalen externen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine extern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.

Wenn Sie zuvor ein Nur-Proxy-Subnetz mit --purpose=INTERNAL_HTTPS_LOAD_BALANCER erstellt haben, müssen Sie den Zweck des Subnetzes zu REGIONAL_MANAGED_PROXY migrieren, bevor Sie andere Envoy-basierte Load-Balancer in derselben Region des VPC-Netzwerks erstellen können.

Weiterleitungsregeln und IP-Adressen

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy, einer URL-Zuordnung und mindestens einem Back-End-Dienst besteht.

IP-Adressspezifikation Jede Weiterleitungsregel stellt eine einzelne IP-Adresse bereit, die in DNS-Einträgen für die Anwendung verwendet werden kann. Ein Load-Balancing für DNS ist nicht erforderlich. Sie können die zu verwendende IP-Adresse entweder selbst angeben oder von Cloud Load Balancing zuweisen lassen.

Portspezifikation Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe externe IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP(S)-Proxy verweisen, solange die gesamte Kombination von IP-Adresse, Port und Protokoll für jede Weiterleitungsregel eindeutig ist. Auf diese Weise können Sie einen einzelnen Load Balancer mit einer freigegebenen URL-Zuordnung als Proxy für mehrere Anwendungen verwenden.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von externen Application Load Balancern verwendet werden, hängen vom Modus des Load-Balancers und von der Netzwerkdienststufe ab, in der sich der Load-Balancer befindet.

Load-Balancer-Modus	Netzwerkdienststufe	Weiterleitungsregel, IP-Adresse und Load-Balancing-Schema	Routing aus dem Internet zum Frontend des Load-Balancers
Globaler externer Application Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
Klassischer Application Load Balancer	Premium-Stufe	Globale externe Weiterleitungsregel Globale externe IP-Adresse Load Balancing-Schema: EXTERNAL ^†	Anfragen, die an das GFE weitergeleitet werden, das dem Client im Internet am nächsten ist.
	Standardstufe	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load Balancing-Schema: EXTERNAL^*	Anfragen, die an ein GFE in der Region des Load-Balancers weitergeleitet werden
Regionaler externer Application Load Balancer	Premium- oder Standardstufe	Regionale externe Weiterleitungsregel Regionale externe IP-Adresse Load-Balancing-Schema: EXTERNAL_MANAGED	Anfragen erreichen Google Cloud über den PoP, der dem Client am nächsten ist. Die Anfragen werden dann über das Premium-Backbone von Google Cloud weitergeleitet, bis sie Envoy-Proxys in derselben Region wie der Load Balancer erreichen.

^* EXTERNAL_MANAGED-Back-End-Dienste können an EXTERNAL-Weiterleitungsregeln angehängt werden. EXTERNAL-Back-End-Dienste können jedoch nicht an EXTERNAL_MANAGED-Weiterleitungsregeln angehängt werden. Wenn Sie die neuen Funktionen nutzen möchten, die nur mit dem globalen externen Application Load Balancer verfügbar sind, empfehlen wir Ihnen, Ihre vorhandenen EXTERNAL-Ressourcen mithilfe des Migrationsvorgangs unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren zu EXTERNAL_MANAGED zu migrieren.

Eine vollständige Liste der Protokolle, die von Weiterleitungsregeln des externen Application Load Balancers in den einzelnen Modi unterstützt werden, finden Sie unter Load-Balancer-Features.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von externen Application Load Balancern verwendet werden, mit VPC-Netzwerken verknüpft werden.

Load-Balancer-Modus	VPC-Netzwerkverknüpfung
Globaler externer Application Load Balancer Klassischer Application Load Balancer	Kein verknüpftes VPC-Netzwerk. Die Weiterleitungsregel verwendet immer eine IP-Adresse, die sich außerhalb des VPC-Netzwerk befindet. Daher ist der Weiterleitungsregel kein VPC-Netzwerk zugewiesen.
Regionaler externer Application Load Balancer	Das VPC-Netzwerk der Weiterleitungsregel ist das Netzwerk, in dem das Nur-Proxy-Subnetz erstellt wurde. Sie geben das Netzwerk an, wenn Sie die Weiterleitungsregel erstellen. Je nachdem, ob Sie eine IPv4-Adresse oder einen IPv6-Adressbereich verwenden, ist der Weiterleitungsregel immer ein explizites oder implizites VPC-Netzwerk zugewiesen. Regionale externe IPv4-Adressen befinden sich immer außerhalb von VPC-Netzwerken. Wenn Sie jedoch die Weiterleitungsregel erstellen, müssen Sie das VPC-Netzwerk angeben, in dem das Nur-Proxy-Subnetz erstellt wurde. Daher hat die Weiterleitungsregel eine explizite Netzwerkverknüpfung. Regionale externe IPv6-Adressbereiche befinden sich immer in einem VPC-Netzwerk. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie das Subnetz angeben, aus dem der IP-Adressbereich stammt. Dieses Subnetz muss sich in derselben Region und im selben VPC-Netzwerk befinden, in der bzw. in dem ein Nur-Proxy-Subnetz erstellt wurde. Es gibt also eine implizite Netzwerkverknüpfung.

Zielproxys

Zielproxys beenden HTTP(S)-Verbindungen von Clients. Mindestens eine Weiterleitungsregel leitet den Traffic zum Zielproxy und der Zielproxy ruft die URL-Zuordnung auf, um zu ermitteln, wie Traffic an Back-Ends weitergeleitet wird.

Der Proxy behält die Groß- und Kleinschreibung im Namen eines Anfrage- oder Antwortheaders nicht unbedingt bei. Beispiel: Der Antwortheader Server: Apache/1.0 könnte auf dem Client als server: Apache/1.0 angezeigt werden.

Hinweis: Bei Internet-Netzwerk-Endpunktgruppen (NEGs) stammen Anfragen vom Load-Balancer aus verschiedenen IP-Bereichen, je nach Art der NEG (global oder regional). Weitere Informationen finden Sie unter Anfragen authentifizieren.

In der folgenden Tabelle ist der Typ des Zielproxys angegeben, der für externe Application Load Balancer erforderlich ist.

Load-Balancer-Modus	Ziel-Proxytypen	Vom Proxy hinzugefügte Header	Unterstützte benutzerdefinierte Header
Globaler externer Application Load Balancer	Globales HTTP, globales HTTPS	Die Proxys richten HTTP-Anfrage-/Antwortheader so ein: Via: 1.1 google (Anfragen und Antworten) X-Forwarded-Proto: [http | https] (nur Anfragen) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen) Die Proxys legen auch den X-Cloud-Trace-Context-Header fest, falls er noch nicht vorhanden ist.	Im Backend-Dienst oder Backend-Bucket konfiguriert Wird nicht von Cloud CDN
Klassischer Application Load Balancer	Globales HTTP, globales HTTPS	Die Proxys richten HTTP-Anfrage-/Antwortheader so ein: Via: 1.1 google (Anfragen und Antworten) X-Forwarded-Proto: [http | https] (nur Anfragen) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen) Die Proxys legen auch den X-Cloud-Trace-Context-Header fest, falls er noch nicht vorhanden ist.	Im Backend-Dienst oder Backend-Bucket konfiguriert
Regionaler externer Application Load Balancer	Regionaler HTTP, Regionaler HTTPS	X-Forwarded-Proto: [http | https] (nur Anfragen) Via: 1.1 google (Anfragen und Antworten) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (siehe X-Forwarded-For-Header) (nur Anfragen)	In der URL-Zuordnung konfiguriert

Hinweis: Gemäß RFC 2616 werden die folgenden Hop-by-Hop-Header nicht vom Zielproxy weitergegeben: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding und Upgrade.

Zusätzlich zu den vom Zielproxy hinzugefügten Headern passt der Load Balancer andere HTTP-Header auf folgende Weise an:

• Beim globalen externen Application Load Balancer werden möglicherweise sowohl Anfrage- als auch Antwortheader in Kleinbuchstaben umgewandelt.

  Die einzige Ausnahme bildet die Verwendung globaler Internet-NEG-Backends mit HTTP/1.1. Weitere Informationen dazu, wie HTTP/1.1-Header mit globalen Internet-NEGs verarbeitet werden, finden Sie in der Übersicht über Internet-NEGs.

• Für den klassischen Application Load Balancer werden Anfrage- und Antwortheader nur in Kleinbuchstaben umgewandelt, wenn Sie HTTP/1.1 verwenden. Bei HTTP/1.1 werden Header stattdessen korrekt formatiert. Der erste Buchstabe im Schlüssel des Headers und jeder Buchstabe nach einem Bindestrich (-) werden groß geschrieben, um die Kompatibilität mit HTTP/1.1-Clients zu wahren. Beispiel: user-agent wird in User-Agent geändert und content-encoding in Content-Encoding.

• Einige Header werden zusammengeführt. Wenn mehrere Instanzen mit demselben Headerschlüssel vorhanden sind, z. B. Via, kombiniert der Load-Balancer deren Werte in einer durch Kommas getrennten Liste zu einem einzelnen Headerschlüssel. Es werden nur Header zusammengeführt, deren Werte als durch Kommas getrennte Liste dargestellt werden können. Andere Header wie Set-Cookie werden nie zusammengeführt.

Host-Header

Wenn der Load-Balancer die HTTP-Anfrage stellt, behält der Load-Balancer den Host-Header der ursprünglichen Anfrage bei.

X-Forwarded-For-Header

Der Load-Balancer hängt zwei IP-Adressen, die durch ein einzelnes Komma getrennt sind, in der folgenden Reihenfolge an den Header X-Forwarded-For an:

• Die IP-Adresse des Clients, der eine Verbindung zum Load-Balancer herstellt
• Die IP-Adresse der Weiterleitungsregel des Load-Balancers

Wenn in der eingehenden Anfrage kein X-Forwarded-For-Header vorhanden ist, stellen diese beiden IP-Adressen den gesamten Header-Wert dar.

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Wenn die Anfrage einen X-Forwarded-For-Header enthält, behält der Load-Balancer den angegebenen Wert vor <client-ip>,<load-balancer-ip> bei:

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

Achtung:

Der Load Balancer prüft keine IP-Adressen, die in diesem Header vor <client-ip>,<load-balancer-ip> stehen. Die obigen IP-Adressen können weitere Zeichen enthalten, einschließlich Leerzeichen.

Beim Ausführen einer HTTP-Reverse-Proxy-Software auf den Back-Ends des Load-Balancers kann die Software eine oder beide der folgenden IP-Adressen an das Ende des Headers X-Forwarded-For anhängen:

• Die IP-Adresse des Google Front End (GFE), das mit dem Backend verbunden ist. Diese IP-Adressen liegen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16.

• Die IP-Adresse des Backend-Systems.

Daher kann ein vorgelagerter Prozess nach dem Backend Ihres Load-Balancers einen X-Forwarded-For-Header im folgenden Format erhalten:

<existing-values>,<client-ip>,<load-balancer-ip>,<GFE-IP>,<backend-IP>

Cloud Trace-Support

Trace wird von Application Load Balancern nicht unterstützt. Der globale und der klassische Application Load Balancer fügen den X-Cloud-Trace-Context-Header hinzu, falls er nicht vorhanden ist. Der regionale externe Application Load Balancer fügt diesen Header nicht hinzu. Wenn der X-Cloud-Trace-Context-Header bereits vorhanden ist, wird er unverändert durch die Load Balancer geleitet. Der Load Balancer exportiert jedoch keine Traces oder Spans.

URL-Zuordnungen

URL-Zuordnungen definieren die Zuordnungsmuster für eine Weiterleitung von Anfragen, die auf URLs basieren, an die passenden Back-End-Dienste. Mit der URL-Zuordnung können Sie Ihren Traffic aufteilen. Dazu werden die URL-Komponenten untersucht, damit sie Anfragen an verschiedene Back-End-Sets senden. Ein Standarddienst ist so definiert, dass er alle Anfragen bearbeiten kann, für die es keine bestimmte Host- oder Pfadregel gibt.

In Situationen wie dem Beispiel zum multiregionalen Load-Balancing kann es sein, dass Sie keine URL-Regeln definieren und sich nur auf den Standarddienst verlassen.

URL-Zuordnungen unterstützen mehrere erweiterte Funktionen zur Trafficverwaltung wie Header-basierte Trafficsteuerung, gewichtete Trafficaufteilung und Anfragespiegelung. Hier finden Sie weitere Informationen:

• Trafficverwaltung für globale externe Application Load Balancer

• Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer

In der folgenden Tabelle ist der Typ der URL-Zuordnung angegeben, der von externen Application Load Balancern in den einzelnen Modi benötigt wird.

Load-Balancer-Modus	Typ der URL-Zuordnung
Globaler externer Application Load Balancer	Global
Klassischer Application Load Balancer	Global (nur mit einer Teilmenge der unterstützten Features)
Regionaler externer Application Load Balancer	Regional

SSL-Zertifikate

Externe Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

• Google Cloud bietet zwei Konfigurationsmethoden zum Zuweisen privater Schlüssel und SSL-Zertifikate zu HTTPS-Zielproxys: Compute Engine-SSL-Zertifikate und Certificate Manager. Eine Beschreibung der einzelnen Konfigurationen finden Sie unter Methoden der Zertifikatskonfiguration in der Übersicht zu SSL-Zertifikaten.

• Google Cloud bietet zwei Zertifikatstypen: selbstverwaltet und von Google verwaltet. Eine Beschreibung der einzelnen Typen finden Sie unter Zertifikat-Typen in der Übersicht zu SSL-Zertifikaten.

Der Typ des externen Application Load Balancers (global, regional oder klassisch) bestimmt, welche Konfigurationsmethoden und Zertifikatstypen unterstützt werden. Weitere Informationen finden Sie unter Zertifikate und Google Cloud-Load Balancer in der SSL-Zertifikatsübersicht.

SSL-Richtlinien

SSL-Richtlinien geben die SSL-Features an, die Google Cloud-Load-Balancer beim Aushandeln von SSL mit Clients verwenden.

Standardmäßig verwendet der HTTPS-Load-Balancer eine Reihe von SSL-Funktionen, die eine hohe Sicherheit und umfassende Kompatibilität bieten. Einige Anwendungen erfordern mehr Kontrolle darüber, welche SSL-Versionen und -Chiffren für ihre HTTPS- oder SSL-Verbindungen verwendet werden. Sie können eine SSL-Richtlinie definieren, um die Gruppe von SSL-Features anzugeben, die der Load-Balancer beim Aushandeln von SSL mit Clients verwendet. Darüber hinaus können Sie diese SSL-Richtlinie auf Ihren Ziel-HTTPS-Proxy anwenden.

In der folgenden Tabelle ist die Unterstützung von SSL-Richtlinien für Load-Balancer in den einzelnen Modi aufgeführt.

Load-Balancer-Modus	Unterstützte SSL-Richtlinien
Globaler externer Application Load Balancer
Klassischer Application Load Balancer
Regionaler externer Application Load Balancer

Backend-Dienste

Ein Back-End-Dienst stellt dem Load Balancer Konfigurationsinformationen zur Verfügung, damit er Anfragen an seine Back-Ends weiterleiten kann, z. B. an Compute Engine-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs). Weitere Informationen zu Back-End-Diensten finden Sie unter Übersicht über Back-End-Dienste.

Ein Beispiel für die Einrichtung eines Load Balancers mit einem Backend-Dienst und einem Compute Engine-Backend finden Sie unter Externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

Umfang des Back-End-Dienstes

In der folgenden Tabelle sehen Sie, welche Backend-Dienstressource und welcher Umfang von externen Application Load Balancern verwendet werden:

Load-Balancer-Modus	Ressource für Back-End-Dienst
Globaler externer Application Load Balancer	backendServices (global)
Klassischer Application Load Balancer	backendServices (global)
Regionaler externer Application Load Balancer	regionBackendServices (regional)

Protokoll für Back-Ends

Backend-Dienste für Application Load Balancer müssen eines der folgenden Protokolle verwenden, um Anfragen an Backends zu senden:

• HTTP, bei dem HTTP/1.1 und kein TLS verwendet wird
• HTTPS, bei dem HTTP/1.1 und TLS verwendet werden
• HTTP/2, das HTTP/2 und TLS verwendet (HTTP/2 ohne Verschlüsselung wird nicht unterstützt).

Der Load Balancer verwendet nur das von Ihnen angegebene Protokoll für die Kommunikation mit den Backends. Der Load Balancer greift nicht auf ein anderes Protokoll zurück, wenn er mit dem angegebenen Protokoll für den Backend-Dienst nicht mit den Backends kommunizieren kann.

Das Protokoll des Back-End-Dienstes muss nicht mit dem Protokoll übereinstimmen, das von den Clients für die Kommunikation mit dem Load Balancer verwendet wird. Clients können beispielsweise Anfragen mit HTTP/2 an den Load Balancer senden, der Load Balancer kann aber mit Back-Ends über HTTP/1.1 (HTTP oder HTTPS) kommunizieren.

Backend-Buckets

Back-End-Buckets leiten eingehenden Traffic an Cloud Storage-Buckets weiter. Ein Beispiel, das zeigt, wie Sie einem externen Application Load Balancer einen Bucket hinzufügen, finden Sie unter Load-Balancer mit Back-End-Buckets einrichten. Allgemeine Informationen zu Cloud Storage finden Sie unter Was ist Cloud Storage?

Back-Ends

In der folgenden Tabelle sind die Backends und zugehörigen Funktionen aufgeführt, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.

Load-Balancer-Modus	Unterstützte Back-Ends in einem Back-End-Dienst^*						Unterstützt Back-End-Buckets	Unterstützt Google Cloud Armor	Unterstützt Cloud CDN^#	Unterstützt IAP^#	Unterstützt Diensterweiterungen
	Instanzgruppen^†	Zonale NEGs^‡	Internet-NEGs	Serverlose NEGs	Hybrid-NEGs	Private Service Connect-NEGs
Globaler externer Application Load Balancer
Klassischer Application Load Balancer									Premium-Stufe
Regionaler externer Application Load Balancer

^* Die Back-Ends eines Back-End-Dienstes müssen vom selben Typ sein: alle Instanzgruppen oder alle NEGs desselben Typs. Eine Ausnahme von dieser Regel ist, dass sowohl zonale GCE_VM_IP_PORT-NEGs als auch hybride NEGs für denselben Backend-Dienst verwendet werden können, um eine Hybridarchitektur zu unterstützen.

^† Kombinationen aus zonal nicht verwalteten, zonal verwalteten und regional verwalteten Instanzgruppen werden für denselben Back-End-Dienst unterstützt. Wenn Sie das Autoscaling für eine verwaltete Instanzgruppe verwenden, die ein Back-End für zwei oder mehr Back-End-Dienste ist, konfigurieren Sie die Autoscaling-Richtlinie der Instanzgruppe für die Verwendung mehrerer Signale.

^‡ Zonale NEGs müssen GCE_VM_IP_PORT-Endpunkte verwenden.

^# IAP und Cloud CDN sind nicht miteinander kompatibel. Sie können nicht für denselben Backend-Dienst aktiviert werden.

Back-Ends und VPC-Netzwerke

Die Einschränkungen, wo sich Back-Ends befinden können, hängen vom Typ des Load-Balancers ab.

Für globale externe Application Load Balancer-Back-Ends gilt Folgendes:

• Back-End-Instanzen (für Instanzgruppen-Back-Ends) und Back-End-Endpunkte (für NEG-Back-Ends) können sich in einem beliebigen VPC-Netzwerk innerhalb derselben Organisation befinden. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFEs direkt mit Backends in ihren jeweiligen VPC-Netzwerken kommunizieren.

• Cloud Storage-Buckets sind keinem VPC-Netzwerk zugeordnet. Sie können sich in jedem Projekt innerhalb derselben Organisation befinden.

  Globale externe Application Load Balancer unterstützen auch Umgebungen mit freigegebener VPC, in denen Sie VPC-Netzwerke und die zugehörigen Ressourcen projektübergreifend freigeben können. Bei globalen externen Application Load Balancern müssen Sie jedoch keine freigegebene VPC konfigurieren, um auf Backend-Dienste oder Backend-Buckets aus anderen Projekten in Ihrer Organisation verweisen zu können.

Für klassische Application Load Balancer-Back-Ends gilt Folgendes:

• Alle Backend-Instanzen von Instanzgruppen-Backends und alle Backend-Endpunkte von NEG-Backends müssen sich im selben Projekt befinden. Ein Instanzgruppen-Backend oder eine NEG können jedoch ein anderes VPC-Netzwerk in diesem Projekt verwenden. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFEs direkt mit Back-Ends in ihren jeweiligen VPC-Netzwerken kommunizieren.

• Cloud Storage-Buckets sind keinem VPC-Netzwerk zugeordnet. Sie müssen sich jedoch im selben Projekt wie der Load Balancer befinden.

Für regionale externe Application Load Balancer-Back-Ends gilt Folgendes:

• Bei Instanzgruppen, zonalen NEGs und NEGs mit Hybrid-Konnektivität müssen sich alle Backends im selben Projekt und in derselben Region wie der Backend-Dienst befinden. Ein Load Balancer kann jedoch auf ein Backend verweisen, das ein anderes VPC-Netzwerk im selben Projekt wie der Backend-Dienst verwendet. Diese Funktion befindet sich in der Vorabversion. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder ein Network Connectivity Center-Framework konfiguriert werden.

  Definition des Backend-Netzwerks

  • Bei zonalen und hybriden NEGs geben Sie das VPC-Netzwerk beim Erstellen der NEG explizit an.
  • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
  • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so festgelegt, dass es mit dem VPC-Netzwerk der nic0-Schnittstelle der ersten VM übereinstimmt, die der Instanzgruppe hinzugefügt wird.

  Anforderungen an das Backend-Netzwerk

  Das Netzwerk deines Backends muss eine der folgenden Netzwerkanforderungen erfüllen:

  • Das VPC-Netzwerk des Backends muss genau mit dem VPC-Netzwerk der Weiterleitungsregel übereinstimmen.

  • Das VPC-Netzwerk des Backends muss über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der Weiterleitungsregel verbunden sein. Sie müssen den Austausch von Subnetzrouten konfigurieren, um die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zu ermöglichen, die von den Backend-Instanzen oder Endpunkten verwendet werden.

• Sowohl das VPC-Netzwerk des Backends als auch das VPC-Netzwerk der Weiterleitungsregel müssen VPC-Spokes auf demselben Network Connectivity Center-Hub sein. Import- und Exportfilter müssen die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zulassen, die von Backend-Instanzen oder Endpunkten verwendet werden.

• Bei allen anderen Backend-Typen müssen sich alle Backends im selben VPC-Netzwerk und in derselben Region befinden.

  Regionale externe Application Load Balancer unterstützen auch Umgebungen mit freigegebene VPC, in denen Sie VPC-Netzwerke und die zugehörigen Ressourcen für mehrere Projekte freigeben können. Wenn sich der Backend-Dienst und die Backends des regionalen externen Application Load Balancers in einem anderen Projekt als die Weiterleitungsregel befinden sollen, müssen Sie den Load Balancer in einer freigegebenen VPC-Umgebung mit projektübergreifendem Dienstverweis konfigurieren.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an verschiedene NICs senden möchten, verwenden Sie stattdessen NEG-Backends.

Wenn Sie zonale NEG-Backends verwenden, werden Pakete an die Netzwerkschnittstelle gesendet, die durch den Endpunkt in der NEG dargestellt wird. Die NEG-Endpunkte müssen sich im selben VPC-Netzwerk wie das explizit definierte VPC-Netzwerk der NEG befinden.

Systemdiagnosen

Jeder Backend-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Backends überwacht, eine Verbindung vom Load-Balancer zu erhalten. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können. Systemdiagnosen prüfen nicht, ob die Anwendung selbst funktioniert.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Backend-Instanzen erreichen können. In der Regel gehen Systemdiagnoseprüfungen vom zentralen Systemdiagnosemechanismus von Google aus.

Regionale externe Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, sind eine Ausnahme von dieser Regel, da ihre Systemdiagnosen stattdessen vom Nur-Proxy-Subnetz ausgehen. Weitere Informationen finden Sie in der Übersicht zu Hybrid-NEGs.

Systemdiagnoseprotokoll

Obwohl es nicht erforderlich und nicht immer möglich ist, empfiehlt es sich, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Backend-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Im Gegensatz dazu unterstützen regionale externe Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.

Load-Balancer-Modus	Systemdiagnosetyp
Globaler externer Application Load Balancer	Global
Klassischer Application Load Balancer	Global
Regionaler externer Application Load Balancer	Regional

Weitere Informationen zu Systemdiagnosen finden Sie hier:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen

Firewallregeln

Für den Load Balancer sind die folgenden Firewallregeln erforderlich:

• Für die globalen externen Application Load Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um Traffic von Google Front Ends (GFEs) zu Ihren Back-Ends zuzulassen. Für den regionalen externen Application Load Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um den Traffic aus dem Nur-Proxy-Subnetz zu Ihren Back-Ends zuzulassen.
• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Bereichen der Systemdiagnoseprüfungen zuzulassen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load Balancer erreicht. Für den globalen externen Application Load Balancer und den klassischen Application Load Balancer können Sie Google Cloud Armor verwenden, um dies zu erreichen.

Die Ports für diese Firewallregeln müssen so konfiguriert werden:

• Lassen Sie Traffic zum Zielport für die Systemdiagnose der einzelnen Backend-Dienste zu.

• Instanzgruppen-Backends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Backend-Dienstes und den mit diesem benannten Port verknüpften Portnummern in jeder Instanzgruppe konfiguriert werden sollen. Die Portnummern können je nach Instanzgruppe, die demselben Backend-Dienst zugewiesen ist, variieren.

• GCE_VM_IP_PORT-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

In der folgenden Tabelle sind die erforderlichen Quell-IP-Adressbereiche für die Firewallregeln zusammengefasst:

Load-Balancer-Modus	Quellbereiche für Systemdiagnosen	Quellbereiche anfragen
Globaler externer Application Load Balancer	35.191.0.0/16 130.211.0.0/22 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:b029::/64	The source of GFE traffic depends on the backend type: Instanzgruppen und zonale NEGs (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:1::/64 Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Internet-NEGs (INTERNET_FQDN_PORT und INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS-NEGs und Backend-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Klassischer Application Load Balancer	35.191.0.0/16 130.211.0.0/22	The source of GFE traffic depends on the backend type: Instanzgruppen, zonale NEGs (GCE_VM_IP_PORT) und Hybridkonnektivitäts-NEGs (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 Internet-NEGs (INTERNET_FQDN_PORT und INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS-NEGs und Backend-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Regionaler externer Application Load Balancer	35.191.0.0/16 130.211.0.0/22 Bei IPv6-Traffic zu den Back-Ends: 2600:2d00:1:b029::/64 Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.	Das von Ihnen konfigurierte Nur-Proxy-Subnetz.

Wichtig: Achten Sie darauf, dass Pakete aus den vollständigen Systemdiagnosebereichen zulässig sind. Wenn Ihre Firewallregel nur Pakete aus einem Teil der Bereiche zulässt, können Systemdiagnosen fehlschlagen, weil der Load-Balancer nicht mit Ihren Back-Ends kommunizieren kann. Dies führt zu HTTP-502-Antworten.

GKE-Support

In GKE werden externe Application Load Balancer auf folgende Weise verwendet:

• Für externe Gateways, die mit dem GKE-Gateway-Controller erstellt wurden, kann jeder Modus eines externen Application Load Balancers verwendet werden. Sie steuern den Modus des Load Balancers, indem Sie eine GatewayClass auswählen. Der GKE-Gateway-Controller verwendet immer GCE_VM_IP_PORT zonale NEG-Backends.

• Externe Ingresse, die mit dem GKE-Ingress-Controller erstellt wurden, sind immer klassische Application Load Balancer. Der GKE-Ingress-Controller verwendet bevorzugt zonale GCE_VM_IP_PORT-NEG-Back-Ends. Instanzgruppen-Back-Ends werden jedoch ebenfalls unterstützt.

• Sie können zonale GCE_VM_IP_PORT-NEGs, die von GKE-Diensten erstellt und verwaltet werden, als Back-Ends für jeden Application Load Balancer oder Proxy-Network Load Balancer verwenden. Weitere Informationen finden Sie unter Containernatives Load Balancing über eigenständige zonale NEGs.

Architektur einer freigegebenen VPC

Externe Application Load Balancer unterstützen Netzwerke, die eine freigegebene VPC verwenden. Eine freigegebene VPC ermöglicht Organisationen, Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, einen externen Application Load Balancer in einem freigegebenen VPC-Netzwerk zu konfigurieren. Unabhängig vom Bereitstellungstyp müssen sich alle Komponenten des Load-Balancers in derselben Organisation befinden.

Load-Balancer	Frontend-Komponenten	Backend-Komponenten
Globaler externer Application Load Balancer	Wenn Sie ein freigegebenes VPC-Netzwerk für Ihre Back-Ends verwenden, erstellen Sie das erforderliche Netzwerk im freigegebene VPC-Hostprojekt. Die globale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein.	Sie haben folgende Möglichkeiten: Erstellen Sie Backend-Dienste, Backend-Buckets und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) im selben Dienstprojekt wie die Frontend-Komponenten. Erstellen Sie Backend-Dienste, Backend-Buckets und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) in Dienstprojekten. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet. Jeder Backend-Dienst muss im selben Projekt wie die Backends definiert werden, auf die er verweist. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden. Back-Ends können Teil eines freigegebene VPC-Netzwerks aus dem Hostprojekt oder einem eigenständigen VPC-Netzwerk sein, also einem nicht freigegebenen VPC-Netzwerk im Dienstprojekt.
Klassischer Application Load Balancer	Die globale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Host oder Dienstprojekt wie die Back-Ends definiert werden.	Ein globaler Backend-Dienst muss im selben Host oder Dienstprojekt definiert werden wie die Backends (Instanzgruppen oder NEGs). Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.
Regionaler externer Application Load Balancer	Erstellen Sie das erforderliche Netzwerk und das Nur-Proxy-Subnetz im freigegebenen VPC-Hostprojekt. Die regionale externe IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein.	Sie haben folgende Möglichkeiten: Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) im selben Dienstprojekt wie die Frontend-Komponenten. Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) in so vielen Dienstprojekten wie nötig. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet. Jeder Backend-Dienst muss im selben Projekt wie die Backends definiert werden, auf die er verweist. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebenen VPC-Hostprojekt erstellen, aber die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung werden bei diesem Modell nicht getrennt.

Alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt

Das folgende Architekturdiagramm zeigt eine standardmäßige Bereitstellung einer freigegebenen VPC, bei der sich alle Load-Balancer-Komponenten und Backends in einem Dienstprojekt befinden. Dieser Bereitstellungstyp wird von allen Application Load Balancern unterstützt.

Die Komponenten und Back-Ends des Load-Balancers müssen dasselbe VPC-Netzwerk verwenden.

Regionaler externer Application Load Balancer in einem freigegebene VPC-Netzwerk

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

Bei einem Load Balancer, der ein serverloses NEG-Backend verwendet, muss sich der Backend-Cloud Run- oder Cloud Run Functions-Dienst im selben Projekt wie die serverlose NEG befinden.

Für den regionalen externen Application Load Balancer, der die projektübergreifende Dienstreferenz unterstützt, müssen sich außerdem der Backend-Dienst, die serverlose NEG und der Cloud Run-Dienst immer im selben Dienstprojekt befinden.

Projektübergreifender Dienstverweis

Der projektübergreifende Dienstverweis ist ein Bereitstellungsmodell, bei dem sich das Frontend und die URL-Zuordnung des Load Balancers in einem Projekt und der Backend-Dienst und die Backends des Load Balancers in einem anderen Projekt befinden.

Mit projektübergreifenden Dienstreferenzen können Organisationen einen zentralen Load-Balancer konfigurieren und Traffic an Hunderte von Diensten weiterleiten, die über mehrere verschiedene Projekte verteilt sind. Sie können alle Regeln und Richtlinien für das Traffic-Routing zentral in einer URL-Zuordnung verwalten. Sie können den Load-Balancer auch mit einem einzelnen Satz von Hostnamen und SSL-Zertifikaten verknüpfen. Sie können daher die Anzahl der für die Bereitstellung Ihrer Anwendung erforderlichen Load-Balancer optimieren und die Verwaltungs-, Betriebskosten- und Kontingentanforderungen reduzieren.

Wenn Sie für jedes Ihrer funktionalen Teams unterschiedliche Projekte verwenden, können Sie auch eine Trennung der Rollen innerhalb Ihrer Organisation erreichen. Dienstinhaber können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während Netzwerkteams Load-Balancer in einem anderen Projekt bereitstellen und verwalten können. Beide Dienste können über projektübergreifende Dienstreferenzen verbunden werden.

Dienstinhaber können die Autonomie der Freigabe ihrer Dienste aufrechterhalten und steuern, welche Nutzer über den Load-Balancer auf ihre Dienste zugreifen können. Dies wird durch eine spezielle IAM-Rolle mit der Bezeichnung Nutzer von Compute-Load-Balancer-Diensten (roles/compute.loadBalancerServiceUser) erreicht.

Die Unterstützung für projektübergreifende Dienstverweise hängt vom Typ des Load Balancers ab:

• Bei globalen externen Application Load Balancern können das Frontend und die URL-Zuordnung des Load Balancers auf Backend-Dienste oder Backend-Buckets aus einem beliebigen Projekt innerhalb derselben Organisation verweisen. Es gelten keine Einschränkungen für VPC-Netzwerk. Sie können zwar eine Umgebung mit freigegebene VPC verwenden, um eine projektübergreifende Bereitstellung zu konfigurieren, wie in diesem Beispiel gezeigt, dies ist jedoch keine Voraussetzung.

• Für regionale externe Application Load Balancer müssen Sie den Load Balancer in einer freigegebene VPC-Umgebung erstellen. Das Frontend und die URL-Zuordnung des Load Balancers müssen sich in einem Host- oder Dienstprojekt befinden. Die Backend-Dienste und Backends des Load Balancers können auf Host- oder Dienstprojekte in derselben freigegebene VPC-Umgebung verteilt werden.

Informationen zum Konfigurieren der freigegebene VPC für einen globalen externen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Globalen externen Application Load Balancer mit freigegebener VPC einrichten.

Informationen zum Konfigurieren der freigegebenen VPC für einen regionalen externen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Regionalen externen Application Load Balancer mit freigegebener VPC einrichten.

Bekannte Einschränkungen beim projektübergreifenden Dienstverweis

• Der projektübergreifende Dienstverweis kann mit Instanzgruppen, serverlosen NEGs und den meisten anderen unterstützten Backend-Typen verwendet werden. Es gelten jedoch die folgenden Einschränkungen:

  • Bei globalen externen Application Load Balancern können Sie nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst serverlose NEG-Backends mit der App Engine hat.

  • Bei regionalen externen Application Load Balancern können Sie nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst regionale Internet-NEG-Backends hat.
• Der projektübergreifende Dienstverweis wird für den klassischen Application Load Balancer nicht unterstützt.
• Google Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie projektübergreifende Dienstverweise verwenden, empfehlen wir daher, eindeutige Backend-Dienstnamen für alle Projekte in Ihrer Organisation zu verwenden.

Beispiel 1: Load-Balancer-Frontend und -Backend in verschiedenen Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung in einer freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und Backend des Load-Balancers in verschiedenen Dienstprojekten

Beispiel 2: Load-Balancer-Frontend im Hostprojekt und Back-Ends in Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung mit freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt werden.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load Balancers im Hostprojekt (zum Vergrößern anklicken)

Beispiel 3: Load-Balancer-Frontend und -Backends in verschiedenen Projekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, bei der das Frontend und die URL-Zuordnung des globalen externen Application Load Balancers in einem anderen Projekt als der Backend-Dienst und die Backends des Load Balancers erstellt werden. Bei dieser Art der Bereitstellung wird kein freigegebene VPC verwendet und sie wird nur für globale externe Application Load Balancer unterstützt.

Load Balancer-Frontend und ‑Backends in verschiedenen Projekten (zum Vergrößern klicken)

So funktionieren Verbindungen

Verbindungen bei globalen externen Application Load Balancern

Die globalen externen Application Load Balancer werden von vielen Proxys, den sogenannten Google Front-Ends (GFEs), implementiert. Es gibt nicht nur einen Proxy. In der Premium-Stufe wird dieselbe globale externe IP-Adresse von verschiedenen Points of Presence angegeben und Clientanfragen werden an das nächste GFE des Clients weitergeleitet.

Je nachdem, wo sich Ihre Clients befinden, können mehrere GFEs HTTP(S)-Verbindungen zu Ihren Back-Ends initiieren. Von GFEs gesendete Pakete haben Quell-IP-Adressen aus demselben Bereich, der auch von Systemdiagnoseprüfern verwendet wird: 35.191.0.0/16 und 130.211.0.0/22.

Hinweis: Bei Internet-NEGs stammen Anfragen vom Load Balancer aus verschiedenen IP-Bereichen, je nach Typ der NEG (global oder regional). Weitere Informationen finden Sie unter Anfragen authentifizieren.

Abhängig von der Back-End-Dienstkonfiguration kann das Protokoll, mit dem jedes GFE eine Verbindung zu Ihren Back-Ends herstellt, HTTP, HTTPS oder HTTP/2 sein. Bei HTTP- oder HTTPS-Verbindungen wird die HTTP-Version HTTP 1.1 verwendet.

HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. HTTP-Keepalives versuchen, dieselbe TCP-Sitzung effizient zu verwenden. Es gibt jedoch keine Garantie. Das GFE verwendet einen Client-HTTP-Keepalive-Zeitlimit von 610 Sekunden und einen Standard-Back-End-Keepalive-Zeitlimit von 600 Sekunden. Sie können das HTTP-Keepalive-Zeitlimit des Clients aktualisieren, aber das Keepalive-Zeitlimit für das Back-End ist festgelegt. Sie können das Zeitlimit für Anfragen/Antworten konfigurieren, indem Sie das Zeitlimit für den Back-End-Dienst festlegen. Ein HTTP-Keepalive und ein TCP-Leerlaufzeitlimit sind zwar ähnlich, aber nicht identisch. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

Damit das Load-Balancing des Traffics gleichmäßig erfolgt, kann der Load-Balancer eine TCP-Verbindung ordnungsgemäß schließen. Dafür sendet er entweder nach Abschluss einer Antwort, die einen Connection: close-Header enthielt, ein FIN ACK-Paket oder er gibt einen HTTP/2-GOAWAY-Frame nach Abschluss einer Antwort aus. Dieses Verhalten beeinträchtigt keine aktiven Anfragen oder Antworten.

Die Anzahl der HTTP-Verbindungen und TCP-Sitzungen hängt von der Anzahl der GFE-Verbindungen ab, der Anzahl der Clients, die eine Verbindung zu den GFEs herstellen, dem Protokoll zu den Back-Ends und der Zone, in der Back-Ends bereitgestellt werden.

Weitere Informationen finden Sie unter Funktionsweise externer Application Load Balancer im Lösungsleitfaden "Optimierung der Anwendungskapazität mit globalem Load-Balancing".

Verbindungen bei regionalen externen Application Load Balancern

Der regionale externe Application Load Balancer ist ein verwalteter Dienst, der auf dem Envoy-Proxy implementiert wird. Der regionale externe Application Load Balancer verwendet ein freigegebenes Subnetz, das als Nur-Proxy-Subnetz bezeichnet wird, um eine Reihe von IP-Adressen bereitzustellen, mit denen Google Envoy-Proxys in Ihrem Namen ausführt. Das Flag --purpose für dieses Nur-Proxy-Subnetz ist auf REGIONAL_MANAGED_PROXY gesetzt. Alle regionalen Envoy-basierten Load-Balancer in einem bestimmten Netzwerk und einer bestimmten Region nutzen dieses Subnetz gemeinsam.

Clients verwenden die IP-Adresse und den Port des Load-Balancers, um eine Verbindung zum Load-Balancer herzustellen. Clientanfragen werden an das Nur-Proxy-Subnetz in derselben Region wie der Client weitergeleitet. Der Load-Balancer beendet Clientanfragen und öffnet dann neue Verbindungen vom Nur-Proxy-Subnetz zu Ihren Back-Ends. Daher haben die vom Load-Balancer gesendeten Pakete Quell-IP-Adressen aus dem Nur-Proxy-Subnetz.

Abhängig von der Backend-Dienstkonfiguration kann das Protokoll, mit dem Envoy-Proxys eine Verbindung zu Ihren Backends herstellen, HTTP, HTTPS oder HTTP/2 sein. Bei HTTP oder HTTPS lautet die HTTP-Version HTTP 1.1. HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. Der Envoy-Proxy legt sowohl das Client-HTTP-Keepalive-Zeitlimit als auch das Backend-Keepalive-Zeitlimit auf einen Standardwert von jeweils 600 Sekunden fest. Sie können das HTTP-Keepalive-Zeitlimit des Clients aktualisieren, aber das Keepalive-Zeitlimit für das Back-End ist festgelegt. Sie können das Zeitlimit für Anfragen/Antworten konfigurieren, indem Sie das Zeitlimit für den Back-End-Dienst festlegen. Weitere Informationen finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

Clientkommunikation mit dem Load-Balancer

• Clients können mit dem Load-Balancer über das Protokoll HTTP 1.1 oder HTTP/2 kommunizieren.
• Bei einer HTTPS-Kommunikation verwenden moderne Clients standardmäßig HTTP/2. Dies wird auf dem Client gesteuert, nicht auf dem globalen HTTPS-Load-Balancer.
• HTTP/2 lässt sich nicht durch eine Konfigurationsänderung am Load-Balancer deaktivieren. Sie können Clients jedoch so konfigurieren, dass sie HTTP 1.1 anstelle von HTTP/2 verwenden. Verwenden Sie beispielsweise mit curl den Parameter --http1.1.
• Externe Application Load Balancer unterstützen die Antwort HTTP/1.1 100 Continue.

Eine vollständige Liste der Protokolle, die von Weiterleitungsregeln des externen Application Load Balancers in den einzelnen Modi unterstützt werden, finden Sie unter Load-Balancer-Features.

Quell-IP-Adressen für Clientpakete

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei TCP-Verbindungen.

Für den globalen externen Application Load Balancer:

• Verbindung 1 vom ursprünglichen Client zum Load-Balancer (GFE):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Endpunkt:

  • Quell-IP-Adresse: IP-Adresse aus einem der unter Firewallregeln angegebenen Bereiche

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Hinweis: Bei Internet-NEGs stammen Anfragen vom Load-Balancer aus verschiedenen IP-Bereichen. Weitere Informationen finden Sie unter Anfragen authentifizieren.

Für die regionalen externen Application Load Balancer:

• Verbindung 1, vom ursprünglichen Client zum Load-Balancer (Nur-Proxy-Subnetz):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2, vom Load-Balancer (Nur-Proxy-Subnetz) zur Backend-VM oder zum Endpunkt:

  • Quell-IP-Adresse: eine IP-Adresse im Nur-Proxy-Subnetz, die von allen Envoy-basierten Load-Balancern gemeinsam verwendet wird, die in derselben Region und im selben Netzwerk wie der Load-Balancer bereitgestellt werden.

  • Ziel-IP-Adresse: die interne IP-Adresse der Backend-VM oder des Containers im VPC-Netzwerk.

Spezielle Routingpfade

Google Cloud verwendet spezielle Routen, die nicht in Ihrem VPC-Netzwerk definiert sind, um Pakete für die folgenden Arten von Traffic weiterzuleiten:

• Für Systemdiagnosen, mit Ausnahme von verteilten Envoy-Systemdiagnosen. Weitere Informationen finden Sie unter Pfade für Systemdiagnosen.

• Zwischen GFEs und Back-Ends von globalen externen Application Load Balancern und klassischen Application Load Balancern. Weitere Informationen finden Sie unter Pfade zwischen Google Front Ends und Back-Ends.

Google Cloud verwendet Subnetzrouten für nur-Proxy-Subnetze, um Pakete für die folgenden Arten von Traffic weiterzuleiten:

• Bei Verwendung verteilter Envoy-Systemdiagnosen

Für regionale externe Application Load Balancer verwendet Google Cloud Open-Source-Envoy-Proxys, um Clientanfragen an den Load-Balancer zu beenden. Der Load-Balancer beendet die TCP-Sitzung und öffnet eine neue TCP-Sitzung aus dem Nur-Proxy-Subnetz der Region zu Ihrem Backend. In Ihrem VPC-Netzwerk definierte Routen erleichtern die Kommunikation von Envoy-Proxys zu Ihren Back-Ends und von Ihren Back-Ends zu den Envoy-Proxys.

Offene Ports

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Wenn Sie einen Portscan ausführen, sehen Sie möglicherweise andere offene Ports für andere Google-Dienste, die auf GFEs ausgeführt werden.

Beide GFE-basierten Load Balancer – globale externe Application Load Balancer und klassische Application Load Balancer – zeigen immer die Ports 80 und 443 zusammen mit jedem anderen Port an, den Sie in den Weiterleitungsregeln Ihres Load Balancers konfiguriert haben. Wenn Sie jedoch keine Weiterleitungsregel für Port 80 oder Port 443 konfiguriert haben, werden alle an diese Ports gesendeten Verbindungen abgelehnt. Umgekehrt werden regionale externe Load Balancer mit Envoy-Proxys implementiert und zeigen während eines Scans keine zusätzlichen offenen Ports.

Aus folgenden Gründen ist die Ausführung eines Portscans für die IP-Adresse eines GFE-basierten Load-Balancers aus Sicht der Prüfung nicht hilfreich:

• Ein Portscan (z. B. mit nmap) erwartet beim Ausführen von TCP-SYN-Tests normalerweise kein Antwortpaket oder ein TCP-RST-Paket. GFEs senden SYN-ACK-Pakete als Antwort auf SYN-Prüfungen nur für Ports, auf denen Sie eine Weiterleitungsregel konfiguriert haben. GFEs senden jedoch nur Pakete an Ihre Backends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an eine andere IP-Adresse oder einen anderen Port gesendet werden, werden nicht an Ihre Backends gesendet.

  GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Mit Google Cloud Armor Standard bieten GFEs immer aktiven Schutz vor volumetrischen und protokollbasierten DDoS-Angriffen und SYN-Floods. Dieser Schutz ist auch dann verfügbar, wenn Sie Google Cloud Armor nicht explizit konfiguriert haben. Sie werden nur dann in Rechnung gestellt, wenn Sie Sicherheitsrichtlinien konfigurieren oder sich für Managed Protection Plus registrieren.

• Pakete, die an die IP-Adresse Ihres Load-Balancers gesendet werden, können von jedem GFE in der Google-Flotte beantwortet werden. Wird jedoch eine Kombination aus IP-Adresse und Zielport eines Load-Balancers gescannt, wird nur ein einziges GFE pro TCP-Verbindung abgefragt. Die IP-Adresse des Load-Balancers wird keinem einzelnen Gerät oder System zugewiesen. Wenn also die IP-Adresse eines GFE-basierten Load-Balancers gescannt wird, werden nicht alle GFEs in der Flotte von Google gescannt.

Daher können Sie die Sicherheit Ihrer Back-End-Instanzen am besten mit folgenden Methoden prüfen:

• Ein Sicherheitsprüfer sollte die Konfiguration der Weiterleitungsregeln für die Konfiguration des Load-Balancers prüfen. Die Weiterleitungsregeln definieren den Zielport, für den Ihr Load-Balancer Pakete akzeptiert und an die Back-Ends weiterleitet. Bei GFE-basierten Load-Balancern kann jede externe Weiterleitungsregel nur auf einen einzelnen TCP-Zielport verweisen. Für Load-Balancer, die TCP-Port 443 verwenden, wird UDP-Port 443 verwendet, wenn die Verbindung auf QUIC (HTTP/3) aktualisiert wird.

• Ein Sicherheitsprüfer sollte die Konfiguration der Firewallregel für Back-End-VMs prüfen. Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Backend-VMs, aber nicht den eingehenden Traffic zu den GFEs. Best Practices finden Sie im Abschnitt Firewallregeln.

TLS-Terminierung

In der folgenden Tabelle wird zusammengefasst, wie die TLS-Terminierung von externen Application Load Balancern verarbeitet wird.

Load-Balancer-Modus	TLS-Terminierung
Globaler externer Application Load Balancer	TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Klassischer Application Load Balancer	TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Regionaler externer Application Load Balancer	TLS wird auf Envoy-Proxys in einem Nur-Proxy-Subnetz in einer vom Nutzer ausgewählten Region terminiert. Verwenden Sie diesen Load-Balancer-Modus, wenn Sie geografische Kontrolle über die Region benötigen, in der TLS terminiert wird.

Zeitüberschreitungen und Wiederholungsversuche

Externe Application Load Balancer unterstützen die folgenden Zeitüberschreitungstypen für HTTP-/HTTPS-Traffic:

Zeitlimittyp und Beschreibung	Standardwerte	Unterstützt benutzerdefinierte Zeitüberschreitungswerte
		Global	Klassisch	Regional
Zeitlimit für Backend-Dienst^1 Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte einer Anfrage an das Backend sendet, bis das Backend das letzte Byte der HTTP-Antwort an den Load Balancer zurückgibt. Wenn das Backend die vollständige HTTP-Antwort nicht innerhalb dieses Zeitlimits an den Load Balancer zurückgegeben hat, werden die verbleibenden Antwortdaten gelöscht.	Für serverlose NEGs in einem Backend-Dienst: 60 Minuten Für alle anderen Backend-Typen in einem Backend-Dienst: 30 Sekunden Für Backend-Buckets: 24 Stunden (86.400 Sekunden)
Client-HTTP-Keepalive-Zeitlimit Die maximale Zeitspanne, in der die TCP-Verbindung zwischen einem Client und dem Proxy des Load Balancers inaktiv sein kann. (Die gleiche TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) Bei globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der ersten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für einen globalen externen Application Load Balancer und einen klassischen Application Load Balancer: 610 Sekunden Für einen regionalen externen Application Load Balancer: 600 Sekunden
HTTP-Keepalive-Zeitlimit des Back-Ends Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem Proxy des Load Balancers und einem Backend inaktiv sein kann. (Die gleiche TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.) Bei globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der zweiten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für Backend-Dienste: 10 Minuten (600 Sekunden) Für Backend-Buckets: 6 Minuten (360 Sekunden)
Zeitüberschreitung bei Inaktivität einer QUIC-Sitzung Die maximale Zeitspanne, die eine QUIC-Sitzung zwischen dem (nachgelagerten) Client und dem GFE eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers inaktiv sein kann.	Für globale externe Application Load Balancer und klassische Application Load Balancer: Das Zeitlimit bei Inaktivität für QUIC-Sitzungen ist der Mindestwert für die Zeitüberschreitung bei Inaktivität des Clients oder die Zeitüberschreitung bei Inaktivität des GFE (300 Sekunden). Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Die Zeitüberschreitung für die Inaktivität des Clients kann konfiguriert werden.

¹Nicht konfigurierbar für serverlose NEG-Back-Ends. Nicht für Backend-Buckets konfigurierbar.

Zeitlimit für Backend-Dienst

Das konfigurierbare Zeitlimit des Backend-Diensts stellt die maximale Zeitspanne dar, die der Load Balancer auf die Verarbeitung einer HTTP-Anfrage durch das Backend wartet und die entsprechende HTTP-Antwort zurückgibt. Mit Ausnahme von serverlosen NEGs beträgt der Standardwert für das Zeitlimit des Backend-Diensts 30 Sekunden.

Wenn Sie beispielsweise eine Datei mit 500 MB herunterladen möchten und der Wert des Zeitlimits für den Backend-Dienst 90 Sekunden beträgt, erwartet der Load Balancer, dass das Backend die gesamte Datei mit 500 MB innerhalb von 90 Sekunden bereitstellt. Das Zeitlimit für den Backend-Dienst kann auch so konfiguriert werden, dass das Backend seine vollständige HTTP-Antwort sendet. Wenn der Load Balancer in dieser Situation zumindest HTTP-Antwortheader erhalten hat, sendet er die vollständigen Antwortheader und so viel vom Antwort-Body zurück, wie er innerhalb des Zeitlimits für den Backend-Dienst erhalten konnte.

Sie sollten das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festlegen, von der Sie erwarten, dass Ihr Backend sie zur Verarbeitung einer HTTP-Antwort benötigt. Sie sollten das Zeitlimit für den Backend-Dienst erhöhen, wenn die auf Ihrem Backend ausgeführte Software mehr Zeit benötigt, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben. Sie sollten die Zeitüberschreitung beispielsweise verlängern, wenn Sie HTTP-408-Antworten mit jsonPayload.statusDetail client_timed_out sehen.

Das Zeitlimit für den Backend-Dienst akzeptiert Werte zwischen 1 und 2,147,483,647 Sekunden. Größere Werte sind jedoch keine praktischen Konfigurationsoptionen. Google Cloud garantiert auch nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts geöffnet bleibt. Bei globalen und klassischen Application Load Balancern legen GFEs ein effektives maximales Zeitlimit für Backend-Dienste von 86,400 Sekunden (1 Tag) fest. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

Verwenden Sie eine der folgenden Methoden, um das Zeitlimit des Backend-Dienstes zu konfigurieren:

Console

Ändern Sie das Feld Zeitlimit des Backend-Diensts des Load Balancers.

gcloud

Verwenden Sie den Befehl gcloud compute backend-services update, um den Parameter --timeout der Backend-Dienstressource zu ändern.

API

Ändern Sie für einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer den Parameter timeoutSec für die globale backendServices-Ressource.

Ändern Sie bei einem regionalen externen Application Load Balancer den Parameter timeoutSec für die Ressource regionBackendServices.

Die Zeitüberschreitungen für WebSocket-Verbindungen stimmen nicht immer mit den Zeitüberschreitungen für Backend-Dienste überein. Zeitüberschreitungen für WebSocket-Verbindungen hängen vom Typ des Load Balancers ab:

Load-Balancer-Modus	Standardwerte	Beschreibung des Zeitlimits für WebSockets
Globaler externer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Aktive WebSocket-Verbindungen verwenden nicht die konfigurierte Zeitüberschreitung des Backend-Dienstes des Load Balancers. Die Verbindungen werden nach 24 Stunden (86.400 Sekunden) automatisch geschlossen. Dieses Limit von 24 Stunden ist festgelegt und überschreibt das Zeitlimit des Backend-Dienstes, wenn es länger als 24 Stunden ist. Inaktive WebSocket-Verbindungen werden geschlossen, wenn das Zeitlimit des Backend-Dienstes überschritten wird. Wir empfehlen keine Zeitlimitwerte für Backend-Dienste größer als 24 Stunden (86.400 Sekunden), da Google Cloud GFEs regelmäßig für Softwareupdates und andere routinemäßige Wartungen neu startet. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google Cloud TCP-Verbindungen für die Wartung beendet.
Klassischer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Inaktive und aktive Websocket-Verbindungen werden automatisch geschlossen, wenn eine Zeitüberschreitung des Backend-Dienstes auftritt. Wir empfehlen keine Zeitlimitwerte für Backend-Dienste größer als 24 Stunden (86.400 Sekunden), da Google Cloud GFEs regelmäßig für Softwareupdates und andere routinemäßige Wartungen neu startet. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google Cloud TCP-Verbindungen für die Wartung beendet.
Regionaler externer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Für aktive WebSocket-Verbindungen wird nicht die Zeitüberschreitung des Backend-Dienstes des Load Balancers verwendet. Inaktive WebSocket-Verbindungen werden geschlossen, wenn das Zeitlimit des Backend-Dienstes überschritten wird. Google Cloud startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgaben neu gestartet oder beendet werden.

Regionale externe Application Load Balancer verwenden den konfigurierten Parameter routeActions.timeout der URL-Zuordnungen und ignorieren das Zeitlimit des Backend-Dienstes. Wenn routeActions.timeout nicht konfiguriert ist, wird der Wert des Zeitlimits für den Backend-Dienst verwendet. Wenn routeActions.timeout angegeben ist, wird das Zeitlimit des Backend-Diensts ignoriert und stattdessen der Wert von routeActions.timeout als Zeitlimit für Anfragen und Antworten verwendet.

Client-HTTP-Keepalive-Zeitlimit

Das HTTP-Keepalive-Zeitlimit des Clients stellt die maximale Zeitspanne dar, in der eine TCP-Verbindung zwischen dem (nachgelagerten) Client und einem der folgenden Proxys inaktiv sein kann:

• Für einen globalen externen Application Load Balancer oder einen klassischen Application Load Balancer: ein Google Front End der ersten Ebene

• Für einen regionalen externen Application Load Balancer: ein Envoy-Proxy

Ein HTTP-Keepalive-Zeitlimit stellt das TCP-Leerlaufzeitlimit für die zugrunde liegenden TCP-Verbindungen dar. Das Client-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

• Bei einem globalen externen Application Load Balancer beträgt der Standardwert 610 Sekunden. Sie können das Client-HTTP-Keepalive-Zeitlimit mit einem Wert zwischen 5 und 1.200 Sekunden konfigurieren.
• Bei einem klassischen Application Load Balancer ist das HTTP-Keepalive-Zeitlimit des Clients auf 610 Sekunden festgelegt.
• Bei einem regionalen externen Application Load Balancer beträgt der Standardwert 600 Sekunden. Sie können das Client-HTTP-Keepalive-Zeitlimit mit einem Wert zwischen 5 und 600 Sekunden konfigurieren.

Verwenden Sie eine der folgenden Methoden, um den Keepalive-Zeitlimitparameter zu konfigurieren:

Console

Ändern Sie das Feld HTTP-Keepalive-Zeitlimit der Frontend-Konfiguration des Load Balancers.

gcloud

Verwenden Sie den Befehl gcloud compute target-http-proxies update oder den Befehl gcloud compute target-https-proxies update, um den Parameter --http-keep-alive-timeout-sec des HTTP-Ziel-Proxys oder der HTTPS-Ziel-Proxy-Ressource zu ändern.

Hinweis:

Bei einem regionalen externen Application Load Balancer können Sie den Parameter „Keepalive-Zeitlimit“ eines regionalen Ziel-HTTP(S)-Proxys nicht direkt aktualisieren. So aktualisieren Sie den Keepalive-Zeitlimitparameter eines regionalen Ziel-Proxys:

1. Erstellen Sie einen neuen Zielproxy mit den gewünschten Zeitüberschreitungseinstellungen.
2. Spiegeln Sie alle anderen Einstellungen aus dem aktuellen Zielproxy auf den neuen. Bei Ziel-HTTPS-Proxys müssen alle SSL-Zertifikate oder Zertifikatszuordnungen mit dem neuen Zielproxy verknüpft werden.
3. Aktualisieren Sie die Weiterleitungsregeln so, dass sie auf den neuen Zielproxy verweisen.
4. Löschen Sie den alten Ziel-Proxy.

API

Ändern Sie den Parameter httpKeepAliveTimeoutSec für die Ressource targetHttpProxies oder die Ressource targetHttpsProxies.

Hinweis:

Bei einem regionalen externen Application Load Balancer können Sie den Parameter „Keepalive-Zeitlimit“ eines regionalen Ziel-HTTP(S)-Proxys nicht direkt aktualisieren. So aktualisieren Sie den Keepalive-Zeitlimitparameter eines regionalen Ziel-Proxys:

1. Erstellen Sie einen neuen Zielproxy mit den gewünschten Zeitüberschreitungseinstellungen.
2. Spiegeln Sie alle anderen Einstellungen aus dem aktuellen Zielproxy auf den neuen. Bei Ziel-HTTPS-Proxys müssen alle SSL-Zertifikate oder Zertifikatszuordnungen mit dem neuen Zielproxy verknüpft werden.
3. Aktualisieren Sie die Weiterleitungsregeln so, dass sie auf den neuen Zielproxy verweisen.
4. Löschen Sie den alten Ziel-Proxy.

Das Client-HTTP-Zeitlimit des Load Balancers sollte größer sein als das HTTP Keepalive-Zeitlimit (TCP inaktiv), das von nachgelagerten Clients oder Proxys verwendet wird. Wenn ein nachgelagerter Client ein größeres HTTP Keepalive-Zeitlimit (TCP inaktiv) hat als das HTTP Keepalive-Zeitlimit des Clients des Load Balancers, kann eine Race-Bedingung auftreten. Aus Sicht eines nachgelagerten Clients kann eine bestehende TCP-Verbindung länger als der Load Balancer inaktiv sein. Das bedeutet, dass der nachgelagerte Client Pakete senden kann, nachdem der Load Balancer die TCP-Verbindung als geschlossen betrachtet. In diesem Fall antwortet der Load Balancer mit einem TCP-Rücksetzpaket (RST).

HTTP-Keepalive-Zeitlimit des Back-Ends

Externe Application Load Balancer sind Proxys, die mindestens zwei TCP-Verbindungen verwenden:

• Bei einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer ist eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und dem GFE auf der ersten Ebene vorhanden. GFEs der ersten Ebene stellen eine Verbindung zu GFEs der zweiten Ebene her und die GFEs der zweiten Ebene öffnen dann eine zweite TCP-Verbindung zu Ihren Back-Ends.

• Bei einem regionalen externen Application Load Balancer ist eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy vorhanden. Der Envoy-Proxy öffnet dann eine zweite TCP-Verbindung zu Ihren Back-Ends.

Die sekundären TCP-Verbindungen des Load Balancers werden möglicherweise nicht nach jeder Anfrage geschlossen. Sie können offen bleiben, um mehrere HTTP-Anfragen und -Antworten zu verarbeiten. Das Backend-HTTP-Keepalive-Zeitlimit definiert das TCP-Leerlaufzeitlimit zwischen dem Load Balancer und Ihren Backends. Das Backend-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. Das Backend-Keepalive-Zeitlimit des Load Balancers sollte unter dem Keepalive-Zeitlimit liegen, das von Software verwendet wird, die auf Ihren Backends ausgeführt wird. Dadurch wird eine Race-Bedingung vermieden, bei der das Betriebssystem Ihrer Back-Ends TCP-Verbindungen mit einem TCP-Zurücksetzen (RST) schließen kann. Da das Backend-Keepalive-Zeitlimit für den Load-Balancer nicht konfigurierbar ist, müssen Sie Ihre Backend-Software so konfigurieren, dass der HTTP-Keepalive-Zeitlimit (TCP inaktiv) größer als 600 Sekunden ist.

In der folgenden Tabelle sind die Änderungen aufgeführt, die zum Ändern der Keepalive-Zeitüberschreitungswerte für häufig verwendete Webserversoftware erforderlich sind.

Webserversoftware	Parameter	Standardeinstellung	Empfohlene Einstellung
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Zeitüberschreitung bei inaktiver QUIC-Sitzung

Das Zeitlimit bei Inaktivität für QUIC-Sitzungen stellt die maximale Zeitspanne dar, die eine QUIC-Sitzung zwischen dem Client und dem GFE eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers inaktiv sein kann.

Der Wert für das Zeitlimit bei Inaktivität für QUIC-Sitzungen ist der Mindestwert für die Zeitüberschreitung bei Inaktivität des Clients oder die Zeitüberschreitung bei Inaktivität des GFE (300 Sekunden). Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Die Zeitüberschreitung für die Inaktivität des Clients kann konfiguriert werden.

Wiederholungsversuche

Die Unterstützung für die Wiederholungslogik hängt vom Modus des externen Application Load Balancers ab.

Load-Balancer-Modus	Wiederholungslogik
Globaler externer Application Load Balancer	Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl von Wiederholungsversuchen, die mit der Wiederholungsrichtlinie konfiguriert werden kann, beträgt 25. Der maximal konfigurierbare Wert für perTryTimeout ist 24 Stunden. Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen (retryConditions=["gateway-error"]), einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.
Klassischer Application Load Balancer	Die Wiederholungsrichtlinie kann für Verbindungswiederholungen nicht geändert werden. HTTP-POST-Anfragen werden nicht wiederholt. HTTP-GET-Anfragen werden immer einmal wiederholt, solange 80 % oder mehr der Back-Ends fehlerfrei sind. Wenn eine einzelne Backend-Instanz in einer Gruppe vorhanden ist und die Verbindung zu dieser Backend-Instanz fehlschlägt, beträgt der Prozentsatz fehlerhafter Backend-Instanzen 100 %, sodass das GFE die Anfrage nicht wiederholt. Der Load-Balancer wiederholt eine fehlgeschlagene GET-Anfrage, wenn die erste Anfrage fehlgeschlagen ist, bevor Antwortheader von der Backend-Instanz empfangen werden. Bei wiederholten Requests wird nur ein Log-Eintrag für die endgültige Antwort generiert. Weitere Informationen finden Sie unter Logging und Monitoring für externe Application Load Balancer. Fehlgeschlagene Anfragen führen dazu, dass der Load-Balancer die HTTP-Antwort 502 synthetisiert.
Regionaler externer Application Load Balancer	Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl von Wiederholungsversuchen, die mit der Wiederholungsrichtlinie konfiguriert werden kann, beträgt 25. Der maximal konfigurierbare Wert für perTryTimeout ist 24 Stunden. Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

Das WebSocket-Protokoll wird für eingehenden GKE-Traffic unterstützt.

Ungültige Verarbeitung von Anfragen und Antworten

Der Load-Balancer blockiert Clientanfragen und Backend-Antworten, sodass diese das Backend oder den Client aus verschiedenen Gründen nicht erreichen. Einige haben einfach mit der HTTP/1.1-Compliance zu tun und bei anderen geht es darum, unerwartete Daten nicht von oder an die Back-Ends weiterzuleiten. Keine der Prüfungen kann deaktiviert werden.

Der Load-Balancer blockiert für die HTTP/1.1-Compliance Folgendes:

• Es kann die erste Zeile der Anfrage nicht parsen.
• In einer Header fehlt das Trennzeichen ":".
• Der Header oder die erste Zeile enthalten ungültige Zeichen.
• Bei der Inhaltslänge handelt es sich nicht um eine gültige Zahl oder es gibt mehrere Header mit Inhaltslängen.
• Es gibt verschiedene Transferverschlüsselungsschlüssel oder Werte für die Transferverschlüsselung wurden nicht erkannt.
• Es gibt einen nicht unterteilten Textkörper und es ist keine Inhaltslänge angegeben.
• Textkörperblöcke können nicht geparst werden. Dies ist der einzige Fall, in dem einige Daten das Back-End erreichen. Der Load-Balancer schließt die Verbindungen zum Client und Back-End, wenn er einen Block empfängt, der nicht geparst werden kann.

Anfragen verarbeiten

Der Load-Balancer blockiert die Anfrage, wenn eine der folgenden Bedingungen zutrifft:

• Die Gesamtgröße der Anfrageheader und der Anfrage-URL überschreitet das Limit für die maximale Größe eines Anfrageheaders für externe Application Load Balancer.
• Die Anfragemethode lässt keinen Textkörper zu, die Anfrage besitzt jedoch einen Textkörper.
• Die Anfrage enthält die Überschrift Upgrade und die Überschrift Upgrade wird nicht zum Aktivieren von WebSocket-Verbindungen verwendet.
• Die HTTP-Version ist nicht bekannt.

Antwortverarbeitung

Der Load-Balancer blockiert die Antwort des Back-Ends, wenn eine der folgenden Bedingungen zutrifft:

• Die Gesamtgröße der Antwortheader überschreitet das Limit für die maximale Größe eines Antwortheaders für externe Application Load Balancer.
• Die HTTP-Version ist nicht bekannt.

Bei der Verarbeitung sowohl der Anfrage als auch der Antwort entfernt oder überschreibt der Load Balancer möglicherweise Hop-by-Hop-Header in HTTP/1.1, bevor er sie an das gewünschte Ziel weiterleitet.

Traffic-Verteilung

Wenn Sie einem Back-End-Dienst eine Back-End-Instanzgruppe oder NEG hinzufügen, geben Sie einen Balancing-Modus an, der eine Methode zum Messen der Back-End-Last und eine Zielkapazität definiert. Externe Application Load Balancer unterstützen zwei Balancing-Modi:

• RATE, für Instanzgruppen oder NEGs, ist die maximale Anzahl von Anfragen (Abfragen) pro Sekunde (RPS, QPS). Der maximale RPS/QPS-Wert kann überschritten werden, wenn alle Back-Ends die Kapazität erreichen oder überschreiten.

• UTILIZATION ist die Back-End-Auslastung von VMs in einer Instanzgruppe.

Wie der Traffic auf Back-Ends verteilt wird, hängt vom Modus des Load Balancers ab.

Globaler externer Application Load Balancer

Bevor ein Google Front End (GFE) Anfragen an Backend-Instanzen sendet, schätzt das GFE, welche Backend-Instanzen Anfragen empfangen können. Diese Kapazitätsschätzung erfolgt proaktiv und nicht gleichzeitig mit eingehenden Anfragen. Die GFEs erhalten regelmäßig Informationen zur verfügbaren Kapazität und verteilen eingehende Anfragen entsprechend.

Was Kapazität bedeutet, hängt zum Teil vom Balancing-Modus ab. Für den RATE-Modus ist dies relativ einfach: Ein GFE bestimmt genau, wie viele Anfragen es pro Sekunde zuweisen kann. UTILIZATION-basiertes Load-Balancing ist komplexer: Der Load-Balancer prüft die aktuelle Auslastung der Instanzen und schätzt dann eine Abfragelast, die jede Instanz verarbeiten kann. Diese Schätzung ändert sich im Laufe der Zeit, wenn sich die Instanzauslastung und die Traffic-Muster ändern.

Beide Faktoren – die Kapazitätsschätzung und die proaktive Zuweisung – beeinflussen die Verteilung zwischen Instanzen. Daher verhält sich Cloud Load Balancing anders als ein einfacher Round Robin-Load-Balancer, der Anfragen exakt im Verhältnis 50:50 auf zwei Instanzen verteilt. Stattdessen versucht Google Cloud Load Balancing, die Auswahl der Backend-Instanz für jede Anfrage zu optimieren.

Beim globalen externen Application Load Balancern ist das Load-Balancing zweistufig. Der Balancing-Modus bestimmt die Gewichtung oder den Anteil des Traffics, der an jedes Backend (Instanzgruppe oder -NEG) gesendet werden soll. Anschließend wird mit der Load-Balancing-Richtlinie (LocalityLbPolicy) festgelegt, wie der Traffic an Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird. Weitere Informationen finden Sie in der Load-Balancing-Richtlinie für den Ort (API-Dokumentation für den Backend-Dienst).

Beim klassischen Application Load Balancer wird der Balancing-Modus verwendet, um das bevorzugte Backend (Instanzgruppe oder NEG) auszuwählen. Der Traffic wird dann nach dem Round-Robin-Verfahren auf Instanzen oder Endpunkte innerhalb des Back-Ends verteilt.

Anfrageverteilung

GFE-basierte externe Application Load Balancer verwenden den folgenden Prozess, um eingehende Anfragen zu verteilen:

1. Vom Client zum GFE der ersten Ebene Edge-Router bewerben die externe IP-Adresse der Weiterleitungsregel am Rand des Google-Netzwerks. Jedes Advertising listet einen nächsten Hop zu einem Layer-3/4-Load-Balancing-System (Maglev) auf. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter.
   • Bei Verwendung der Premium-Stufe bewirbt Google die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
   • Bei Verwendung der Standardstufe bewirbt Google die IP-Adresse Ihres Load Balancers von Points of Presence, die mit der Region der Weiterleitungsregel verknüpft sind. Der Load-Balancer verwendet eine regionale externe IP-Adresse. Mit einer Weiterleitungsregel der Standardstufe können Sie nur Instanzgruppen- und zonale NEG-Backends in derselben Region wie die Weiterleitungsregel des Load Balancers verwenden.
2. Vom GFE der ersten Ebene zum GFE der zweiten Ebene Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
   • GFEs der ersten Ebene parsen die URL-Zuordnung und wählen einen Backend-Dienst oder einen Backend-Bucket aus.
   • Bei Backend-Diensten mit Internet-NEGs wählen die GFEs der ersten Ebene ein externes Weiterleitungsgateway aus, das dem GFE der ersten Ebene entspricht. Das Weiterleitungsgateway sendet Anfragen an den Internet-NEG-Endpunkt. Damit ist der Anfrageverteilungsprozess für Internet-NEGs abgeschlossen.
   • Bei Backend-Diensten mit serverlosen NEGs und PSC-NEGs (Private Service Connect) sowie Backend-Buckets mit einer einzelnen Region wählen GFEs der ersten Ebene ein GFE der zweiten Ebene in der Region aus, die der Region der NEG oder des Buckets entspricht. Bei multiregionalen Cloud Storage-Buckets wählen GFEs der ersten Ebene GFEs der zweiten Ebene entweder in der Region des Buckets oder in einer Region aus, die so nah wie möglich am multiregionalen Bucket liegt (definiert durch die Umlaufzeit des Netzwerks).
   • Bei Backend-Diensten mit Instanzgruppen, zonalen NEGs mit GCE_VM_IP_PORT-Endpunkten und Hybrid-NEGs informiert das Kapazitätsverwaltungssystem von Google die GFEs der ersten Ebene über die verwendete und konfigurierte Kapazität für jedes Backend. Die konfigurierte Kapazität für ein Backend wird durch den Balancing-Modus, die Zielkapazität des Balancing-Modus und den Kapazitätsskalierer definiert.
     • Standardstufe: GFEs der ersten Ebene wählen ein GFE der zweiten Ebene in der Region mit den Back-Ends enthält.
     • Premium-Stufe: GFEs der ersten Ebene wählen GFEs der zweiten Ebene aus einer Reihe von anwendbaren Regionen aus. Anwendbare Regionen sind alle Regionen, in denen Back-Ends konfiguriert wurden, mit Ausnahme der Regionen mit konfigurierten Back-Ends, die keine Kapazität haben. GFEs der ersten Ebene wählen das GFE der zweiten Ebene in einer anwendbaren Region aus (definiert durch die Umlaufzeit des Netzwerks). Wenn Back-Ends in zwei oder mehr Regionen konfiguriert sind, können GFEs der ersten Ebene Anfragen an andere anwendbare Regionen übertragen, wenn eine Region der ersten Wahl voll ist. Das Spillover in andere Regionen ist möglich, wenn alle Back-Ends in der Region der ersten Wahl ausgelastet sind.
3. GFEs der zweiten Ebene wählen Back-Ends aus. GFEs der zweiten Ebene befinden sich in Zonen einer Region. They use the following process to select a backend:
   • Bei Backend-Diensten mit serverlosen NEGs, Private Service Connect-NEGs und Backend-Buckets leiten GFEs der zweiten Ebene Anfragen an die Produktionssysteme von Google weiter. Damit ist der Anfrageverteilungsprozess für diese Back-Ends abgeschlossen.

   • Bei Backend-Diensten mit Instanzgruppen, zonalen NEGs mit GCE_VM_IP_PORT-Endpunkten und Hybrid-NEGs informieren die Systemdiagnose-Prüfsysteme von Google die GFEs der zweiten Ebene über den Systemdiagnosestatus der Backend-Instanzen oder -Endpunkte.

     Nur Premium-Stufe: Wenn das GFE der zweiten Ebene keine fehlerfreien Backend-Instanzen oder Endpunkte in seiner Region hat, kann es Anfragen an ein anderes GFE der zweiten Ebene in einer anderen anwendbaren Region mit konfigurierten Backends senden. Der Spillover zwischen GFEs der zweiten Ebene in verschiedenen Regionen erschöpft nicht alle möglichen Kombinationen zwischen Regionen. Wenn Sie Traffic von Back-Ends in einer bestimmten Region weiterleiten müssen, anstatt Back-Ends für Systemdiagnosen zu konfigurieren, sollten Sie den Kapazitätsskalierer des Back-Ends auf null setzen, damit das GFE der ersten Ebene die Region im vorherigen Schritt ausschließt.

   Das GFE der zweiten Ebene leitet dann Anfragen an Backend-Instanzen oder Endpunkte in Zonen innerhalb seiner Region weiter, wie im nächsten Schritt erläutert.

4. GFE der zweiten Ebene wählt eine Zone aus. Standardmäßig verwenden GFEs der zweiten Ebene den WATERFALL_BY_REGION-Algorithmus, bei dem jedes GFE der zweiten Ebene bevorzugt Backend-Instanzen oder Endpunkte in derselben Zone auswählt, in der auch das GFE der zweiten Ebene enthalten ist. Da mit WATERFALL_BY_REGION der Traffic zwischen den Zonen auf minimale Anforderungsraten reduziert wird, sendet das GFE der zweiten Ebene möglicherweise ausschließlich Anfragen an Back-Ends in derselben Zone wie das GFE der zweiten Ebene selbst.

   Nur bei globalen externen Application Load Balancern können GFEs der zweiten Ebene so konfiguriert werden, dass sie einen der folgenden alternativen Algorithmen mithilfe eines serviceLbPolicy verwenden:

   • SPRAY_TO_REGION: GFEs der zweiten Ebene bevorzugen keine Backend-Instanzen oder Endpunkte in derselben Zone wie das GFE der zweiten Ebene. GFEs der zweiten Ebene versuchen, den Traffic auf alle Backend-Instanzen oder Endpunkte in allen Zonen der Region zu verteilen. Hierdurch erfolgt eine gleichmäßigere Lastverteilung auf Kosten von erhöhtem Traffic zwischen den Zonen.
   • WATERFALL_BY_ZONE: GFEs der zweiten Ebene bevorzugen die Auswahl von Backend-Instanzen oder Endpunkten in derselben Zone wie das GFE der zweiten Ebene. GFEs der zweiten Ebene leiten Anfragen nur an Back-Ends in verschiedenen Zonen weiter, nachdem alle Back-Ends in der aktuellen Zone ihre konfigurierte Kapazitäten erreicht haben.
5. Das GFE der zweiten Ebene wählt Instanzen oder Endpunkte innerhalb der Zone aus. Standardmäßig verteilt ein GFE der zweiten Ebene Anfragen nach dem Round-Robin-Verfahren auf Back-Ends. Nur für globale externe Application Load Balancer können Sie dies mithilfe einer Load-Balancing-Richtlinie für den Ort (localityLbPolicy) ändern. Die Load-Balancing-Richtlinie für den Ort gilt nur für Back-Ends innerhalb der ausgewählten Zone, wie im vorherigen Schritt erläutert.

Regionaler externer Application Load Balancer

Bei regionalen externen Application Load Balancern basiert die Trafficverteilung auf dem Load-Balancing-Modus und der Load-Balancing-Richtlinie für den Ort.

Der Balancing-Modus bestimmt die Gewichtung und den Anteil des Traffics, der an jede Gruppe (Instanzgruppe oder NEG) gesendet werden soll. Die Load-Balancing-Richtlinie für den Ort (LocalityLbPolicy) bestimmt, wie Load-Balancing auf die Back-Ends innerhalb der Gruppe angewendet wird.

Wenn ein Backend-Dienst Traffic empfängt, leitet er ihn zuerst an ein Backend (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Backends weiter. Nach der Auswahl eines Backends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Backend-Gruppe verteilt.

Hier finden Sie weitere Informationen:

• Balancing-Modi
• Load-Balancing-Richtlinie für den Ort (Dokumentation für regionale Backend Service API)

Sitzungsaffinität

Mit der Sitzungsaffinität wird versucht, Anfragen gemäß konfiguriertem Balancing-Modus von einem bestimmten Client an dasselbe Backend zu senden, wenn das Backend intakt ist und Kapazität hat.

Wenn Sie die Sitzungsaffinität verwenden, empfehlen wir den Balancing-Modus RATE statt UTILIZATION. Die Sitzungsaffinität funktioniert am besten, wenn Sie den Balancing-Modus auf Anfragen pro Sekunde (requests per second, RPS) einstellen.

Externe Application Load Balancer bieten die folgenden Arten von Sitzungsaffinität:

• NONE. Es ist keine Sitzungsaffinität für den Load-Balancer festgelegt.
• Client-IP-Affinität
• Generierte Cookie-Affinität
• Header-Feld-Affinität
• HTTP-Cookie-Affinität
• Zustandsorientierte Cookie-basierte Sitzungsaffinität

In der folgenden Tabelle sind die unterstützten Optionen für die Sitzungsaffinität aufgeführt, die von externen Application Load Balancern unterstützt werden:

Load-Balancer-Modus	Optionen der Sitzungsaffinität
	Keine	Client-IP	Generiertes Cookie	Header-Feld	HTTP-Cookie	Zustandsorientiertes Cookie
Globaler externer Application Load Balancer
Klassischer Application Load Balancer
Regionaler externer Application Load Balancer

Hochverfügbarkeit und Failover

Hochverfügbarkeit und Failover in externen Application Load Balancern können auf Load Balancer-Ebene konfiguriert werden. Dazu werden regionale externe Sicherungs-Application Load Balancer in jeder Region erstellt, in der Sie eine Sicherung benötigen.

In der folgenden Tabelle wird das Failover-Verhalten beschrieben.

Load-Balancer-Modus	Failover-Methoden
Globaler externer Application Load Balancer Klassischer Application Load Balancer	Sie können eine Aktiv/Passiv-Failover-Konfiguration konfigurieren, bei der der Traffic ein Failover auf einen regionalen externen Application Load Balancer zur Sicherung macht. Sie verwenden Systemdiagnosen, um Ausfälle zu erkennen, und Cloud DNS-Routingrichtlinien, um den Traffic weiterzuleiten, wenn der Failover ausgelöst wird.
Regionaler externer Application Load Balancer	Verwenden Sie eine der folgenden Methoden, um eine hoch verfügbare Bereitstellung zu ermöglichen: Sie können eine Aktiv/Passiv-Failover-Konfiguration konfigurieren, bei der der Traffic ein Failover auf einen regionalen externen Application Load Balancer zur Sicherung macht. Mithilfe von Systemdiagnosen können Sie Ausfälle erkennen und mit einer Cloud DNS-Failover-Routingrichtlinie den Traffic weiterleiten, wenn der Failover durch fehlgeschlagene Systemdiagnosen ausgelöst wird. Weitere Informationen finden Sie unter Failover für externe Application Load Balancer. Sie können eine Aktiv/Aktiv-Failover-Konfiguration konfigurieren, bei der Sie mehrere regionale externe Application Load Balancer in Regionen bereitstellen, die den Traffic für Ihre Anwendung am besten unterstützen. Sie verwenden eine Cloud DNS-Standortbestimmung-Routingrichtlinie, um Traffic basierend auf dem Ursprung der Clientanfrage an die entsprechende Region weiterzuleiten. Sie können Systemdiagnosen auch verwenden, um Ausfälle zu erkennen und Traffic nur an die fehlerfreien Load Balancer weiterzuleiten. Weitere Informationen finden Sie unter Hohe Verfügbarkeit für regionale externe Application Load Balancer.

HTTP/2-Unterstützung

HTTP/2 ist eine wesentliche Überarbeitung des HTTP/1-Protokolls. HTTP/2 wird für Verbindungen zwischen Clients und dem externen Application Load Balancer sowie für Verbindungen zwischen dem Load Balancer und seinen Backends unterstützt.

Der Load Balancer verhandelt automatisch HTTP/2 mit Clients als Teil des TLS-Handshakes und verwendet dazu die ALPN TLS-Erweiterung. Auch wenn ein Load Balancer für die Verwendung von HTTPS konfiguriert ist, verwenden moderne Clients standardmäßig HTTP/2. Dies wird clientseitig und nicht auf dem Load Balancer gesteuert.

Wenn ein Client HTTP/2 nicht unterstützt und der Load Balancer für die Verwendung von HTTP/2 zwischen dem Load Balancer und den Backend-Instanzen konfiguriert ist, kann er trotzdem eine HTTPS-Verbindung aushandeln oder unsichere HTTP-Anfragen akzeptieren. Diese HTTPS- oder HTTP-Anfragen werden dann vom Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Damit Sie HTTP/2 verwenden können, müssen Sie TLS auf Ihren Backends aktivieren. Weitere Informationen finden Sie unter Verschlüsselung vom Load Balancer zu Backends.

Maximale Anzahl gleichzeitiger HTTP/2-Streams

Die HTTP/2-Einstellung SETTINGS_MAX_CONCURRENT_STREAMS beschreibt die maximale Anzahl von Streams, die ein Endpunkt akzeptiert, die vom Peer initiiert wurden. Der von einem HTTP/2-Client zu einem Google Cloud-Load-Balancer angekündigte Wert hat quasi keine Bedeutung, da der Load-Balancer keine Streams an den Client initiiert.

In Fällen, in denen der Load-Balancer HTTP/2 für die Kommunikation mit einem Server verwendet, der auf einer VM ausgeführt wird, berücksichtigt der Load-Balancer den vom Server angekündigten Wert SETTINGS_MAX_CONCURRENT_STREAMS. Wenn ein Wert von null angekündigt wird, kann der Load-Balancer keine Anfragen an den Server weiterleiten. Das kann zu Fehlern führen.

HTTP/2-Einschränkungen

• HTTP/2 zwischen dem Load-Balancer und der Instanz kann wesentlich mehr TCP-Verbindungen zur Instanz benötigen als HTTP(S). Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP(S) reduziert, ist bei HTTP/2 derzeit nicht möglich. Dies kann zu hohen Backend-Latenzen führen, da Backend-Verbindungen häufiger hergestellt werden.
• HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt nicht das Ausführen des WebSocket-Protokolls über einen einzelnen Stream einer HTTP/2-Verbindung (RFC 8441).
• HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt keinen Server-Push.
• Die gRPC-Fehlerrate und das Anfragevolumen sind in der Google Cloud API oder der Google Cloud Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und die Monitoring-Daten den HTTP-Antwortcode OK 200.

HTTP/3-Unterstützung

HTTP/3 ist ein Internetprotokoll der nächsten Generation. Es baut auf IETF QUIC auf, einem Protokoll, das aus dem ursprünglichen Google QUIC-Protokoll entwickelt wurde. HTTP/3 wird zwischen dem externen Application Load Balancer, Cloud CDN und Clients unterstützt.

Die Unterstützung von Google QUIC (auch als gQUIC bezeichnet) wurde im April 2023 zugunsten von HTTP/3 gegenüber IETF QUIC entfernt. Beides ist ein IETF-Standard, der gQUIC übertroffen hat.

Genauer gesagt:

• IETF QUIC ist ein Protokoll der Transportschicht, das eine Überlastungssteuerung und Zuverlässigkeit wie TCP bietet und TLS 1.3 für Sicherheit und verbesserte Leistung verwendet.
• HTTP/3 ist eine Anwendungsebene, die auf IETF QUIC basiert und QUIC für die Verarbeitung von Multiplexing, Überlastungssteuerung, Verlusterkennung und Neuübertragung verwendet.
• HTTP/3 startet die Clientverbindung schneller, entfernt Blockierungen der Hauptleitung in Multiplexströmen und unterstützt die Verbindungsmigration, wenn sich die IP-Adresse eines Clients ändert.
• HTTP/3 wird für Verbindungen zwischen Clients und dem Load-Balancer unterstützt, nicht für Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.
• HTTP/3-Verbindungen verwenden das BBR-Protokoll zur Überlastungssteuerung.

HTTP/3 in Ihrem Load-Balancer kann die Ladezeiten von Webseiten verbessern, die erneute Zwischenspeicherung von Videos reduzieren und den Durchsatz für Verbindungen mit höherer Latenz verbessern.

Die folgende Tabelle enthält die HTTP/3-Unterstützung für externe Application Load Balancer in jedem Modus.

Load-Balancer-Modus	HTTP/3-Unterstützung
Globaler externer Application Load Balancer (immer Premium-Stufe)
Klassischer Application Load Balancer in der Premium-Stufe
Klassischer Application Load Balancer in der Standardstufe
Regionaler externer Application Load Balancer (Premium- oder Standardstufe)

So wird HTTP/3 ausgehandelt

Wenn HTTP/3 aktiviert ist, bewirbt der Load-Balancer diese Unterstützung gegenüber Clients. So können Clients, die HTTP/3 unterstützen, versuchen, HTTP/3-Verbindungen mit dem HTTPS-Load-Balancer herzustellen.

• Richtig implementierte Clients greifen immer auf HTTPS oder HTTP/2 zurück, wenn sie keine HTTP/3-Verbindung herstellen können.
• Clients, die HTTP/3 unterstützen, verwenden ihr im Cache gespeichertes Vorwissen der HTTP/3-Unterstützung, um unnötige Umläufe in Zukunft zu vermeiden.
• Aus diesem Grund beeinträchtigen die aktiven oder inaktiven HTTP/3-Einstellungen beim Load-Balancer nicht dessen Fähigkeit, eine Verbindung zu Clients herzustellen.

Unterstützung wird im HTTP-Antwort-Header Alt-Svc beworben. Wenn HTTP/3 aktiviert ist, enthalten Antworten vom Load-Balancer den folgenden Wert für den Header alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Hinweis:

Der Header Alt-Svc bewirbt mehrere Versionen von HTTP/3, um frühere Entwürfe zu unterstützen, die von einigen Clients verwendet werden (z. B. h3-29).

Wenn HTTP/3 explizit auf DISABLE gesetzt wurde, enthalten Antworten keinen alt-svc-Antwortheader.

Wenn Sie HTTP/3 in Ihrem HTTPS-Load-Balancer aktiviert haben, kann Ihr Client unter bestimmten Umständen auf HTTPS oder HTTP/2 zurückgreifen, anstatt HTTP/3 auszuhandeln. Dazu gehören die folgenden:

• Die Clientversion von HTTP/3 ist nicht mit den vom HTTPS-Load-Balancer unterstützten HTTP/3-Versionen kompatibel.
• Der Load-Balancer ermittelt einen blockierten UDP-Traffic oder einen beschränkten Tarif, sodass HTTP/3 nicht funktioniert
• Der Client unterstützt HTTP/3 überhaupt nicht und versucht daher nicht, eine HTTP/3-Verbindung auszuhandeln.

Wenn eine Verbindung auf HTTPS oder HTTP/2 zurückgreift, gilt dies nicht als Fehler des Load-Balancers.

Prüfen Sie vor dem Aktivieren von HTTP/3, ob die zuvor beschriebenen Verhaltensweisen für Ihre Arbeitslasten akzeptabel sind.

HTTP/3 konfigurieren

Sowohl NONE (Standardeinstellung) als auch ENABLE aktivieren HTTP/3-Unterstützung für Ihren Load-Balancer.

Wenn HTTP/3 aktiviert ist, bewirbt der Load-Balancer diese Clients. Dies ermöglicht Clients, die sie unterstützen, eine HTTP/3-Version mit dem Load-Balancer auszuhandeln. Clients, die HTTP/3 nicht unterstützen, handeln keine HTTP/3-Verbindung aus. Sie müssen HTTP/3 nicht explizit deaktivieren, es sei denn, Sie haben fehlerhafte Clientimplementierungen identifiziert.

Externe Application Load Balancer bieten drei Möglichkeiten zum Konfigurieren von HTTP/3, wie in der folgenden Tabelle dargestellt.

quicOverride-Wert	Verhalten
NONE	Unterstützung für HTTP/3 wird Clients angeboten.
ENABLE	Unterstützung für HTTP/3 wird Clients angeboten. Hinweis: TLS 0-RTT (auch als TLS Early Data bezeichnet) wird noch nicht für HTTP/3 unterstützt.
DISABLE	Deaktiviert explizit das Advertising von HTTP/3 und Google QUIC gegenüber Clients.

So aktivieren oder deaktivieren Sie HTTP/3 explizit:

Konsole: HTTPS

Hinweis: Die Einstellung der HTTP/3-Verhandlung wird derzeit nicht auf der Seite der Zielproxys unterstützt und muss durch Bearbeiten der Load-Balancer-Konfiguration konfiguriert werden.

1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

Load-Balancing aufrufen

1. Wählen Sie den Load-Balancer aus, den Sie bearbeiten möchten.
2. Klicken Sie auf Frontend-Konfiguration.
3. Wählen Sie die Frontend-IP-Adresse und den Frontend-Port aus, den Sie bearbeiten möchten. Zum Bearbeiten einer HTTP/3-Konfiguration muss das Protokoll HTTPS sein.

HTTP/3 aktivieren

1. Wählen Sie das Menü QUIC-Verhandlung aus.
2. Wählen Sie Aktiviert aus, um HTTP/3 für dieses Frontend explizit zu aktivieren.
3. Wenn Sie mehrere Frontend-Regeln für IPv4 und IPv6 haben, müssen Sie HTTP/3 für jede Regel aktivieren.

HTTP/3 deaktivieren

1. Wählen Sie das Menü QUIC-Verhandlung aus.
2. Wählen Sie Deaktiviert aus, um HTTP/3 für dieses Frontend explizit zu deaktivieren.
3. Wenn Sie mehrere Frontend-Regeln haben, die IPv4 und IPv6 darstellen, müssen Sie HTTP/3 für jede Regel deaktivieren.

gcloud: HTTPS

Bevor Sie diesen Befehl ausführen, müssen Sie eine SSL-Zertifikatressource für jedes Zertifikat erstellen.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Ersetzen Sie QUIC_SETTING durch einen der folgenden Werte:

• NONE (Standard): ermöglicht Google die Kontrolle darüber, wann HTTP/3 beworben wird.

  HTTP/3 wird beworben, wenn Sie NONE auswählen, aber Google QUIC nicht beworben. In der Google Cloud Console heißt diese Option Automatisch (Standard).

• ENABLE: Bewirbt HTTP/3-Clients.

• DISABLE: Bewirbt HTTP/3 nicht gegenüber Clients.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Ersetzen Sie QUIC_SETTING durch einen der folgenden Werte:

• NONE (Standard): ermöglicht Google die Kontrolle darüber, wann HTTP/3 beworben wird.

  HTTP/3 wird beworben, wenn Sie NONE auswählen, aber Google QUIC nicht beworben. In der Google Cloud Console heißt diese Option Automatisch (Standard).

• ENABLE: Bewirbt HTTP/3- und Google-QUIC gegenüber Clients

• DISABLE: Bewirbt HTTP/3- und Google-QUIC nicht gegenüber Clients

WebSocket-Unterstützung

HTTP(S)-basierte Load Balancer von Google Cloud unterstützen das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Backend verwenden. Der Load-Balancer benötigt zum Weiterleiten von WebSocket-Verbindungen über einen Proxy keine Konfiguration.

Das WebSocket-Protokoll bietet einen Vollduplex-Kommunikationskanal zwischen Clients und dem Load Balancer. Weitere Informationen finden Sie unter RFC 6455.

Das WebSocket-Protokoll funktioniert so:

1. Der Load Balancer erkennt eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client. Die Anfrage enthält die Header Connection: Upgrade und Upgrade: websocket, gefolgt von anderen relevanten WebSocket-bezogenen Anfrageheadern.
2. Das Backend sendet eine WebSocket-Upgrade-Antwort. Die Backend-Instanz sendet eine 101 switching protocol-Antwort mit Connection: Upgrade, Upgrade: websocket-Headern und anderen WebSocket-bezogenen Antwortheadern.
3. Der Load Balancer leitet für die Dauer der aktuellen Verbindung bidirektionalen Traffic über einen Proxy weiter.

Wenn die Back-End-Instanz eine Fehlerantwort mit dem Antwortcode 426 oder 502 zurückgibt, schließt der Load Balancer die Verbindung.

Zeitüberschreitungen für WebSocket-Verbindungen hängen vom Typ des Load Balancers ab (global, regional oder klassisch). Weitere Informationen finden Sie unter Zeitüberschreitung bei Backend-Diensten.

Die Sitzungsaffinität für WebSockets funktioniert wie für jede andere Anfrage. Weitere Informationen finden Sie unter Sitzungsaffinität.

gRPC-Unterstützung

gRPC ist ein Open Source-Framework für Remoteprozeduraufrufe. Es basiert auf dem HTTP/2-Standard. Anwendungsfälle für gRPC sind:

• Hoch skalierbare, verteilte Systeme mit geringer Latenz
• Entwicklung mobiler Clients, die mit einem Cloud-Server kommunizieren
• Entwurf neuer Protokolle, die genau, effizient und sprachunabhängig sein müssen
• Layerdesign, um Erweiterung, Authentifizierung und Protokollierung zu ermöglichen

Um gRPC mit Ihren Google Cloud-Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. So gehen Sie dazu vor:

1. Konfigurieren Sie einen HTTPS-Load-Balancer.
2. Wählen Sie HTTP/2 als Protokoll vom Load-Balancer zu den Back-Ends aus.

Der Load-Balancer verhandelt HTTP/2 mit Clients als Teil des SSL-Handshakes und verwendet dazu die ALPN TLS-Erweiterung.

Der Load-Balancer kann mit einigen Clients weiter HTTPS aushandeln oder unsichere HTTP-Anfragen auf einem Load-Balancer akzeptieren, der für die Verwendung von HTTP/2 zwischen dem Load-Balancer und den Backend-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Sie müssen TLS auf Ihren Back-Ends aktivieren. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Informationen zum Konfigurieren eines externen Application Load Balancers mit HTTP/2 mit Google Kubernetes Engine Ingress oder mit gRPC und HTTP/2 finden Sie unter HTTP/2 für Load-Balancing mit Ingress.

Informationen zur Fehlerbehebung bei HTTP/2 finden Sie unter Fehlerbehebung für HTTP/2 zu den Back-Ends.

Informationen zu Einschränkungen von HTTP/2 finden Sie unter HTTP/2-Einschränkungen.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Zielproxy nur TLS 1.0, 1.1, 1.2 und 1.3, wenn SSL-Requests von Clients beendet werden.

Wenn der Load Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 mit dem Back-End aushandeln.

Unterstützung für gegenseitiges TLS

Mutual TLS (mTLS) ist ein Industriestandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. Sie sorgt dafür, dass sich sowohl Client als auch Server gegenseitig authentifizieren, indem sie überprüft, ob beide ein gültiges Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) haben. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, müssen bei mTLS sowohl der Client als auch der Server Zertifikate vorlegen, um die Identitäten beider Seiten zu bestätigen, bevor eine Kommunikation hergestellt wird.

Alle Application Load Balancer unterstützen mTLS. Bei mTLS fordert der Load Balancer an, dass der Client während des TLS-Handshakes mit dem Load Balancer ein Zertifikat sendet, um sich zu authentifizieren. Sie können einen Zertifikatmanager-Trust Store konfigurieren, mit dem der Load Balancer dann die Vertrauenskette des Clientzertifikats validiert.

Weitere Informationen zu mTLS finden Sie unter Gegenseitige TLS-Authentifizierung.

Beschränkungen

• HTTPS-Load-Balancer senden keine Benachrichtigung zum Schließen close_notify, wenn SSL-Verbindungen beendet werden. Das heißt, der Load-Balancer schließt die TCP-Verbindung, statt einen SSL-Shutdown auszuführen.
• HTTPS-Load-Balancer unterstützen nur Kleinbuchstaben in Domains mit einem gemeinsamen Namen (CN) oder einem alternativen Antragstellernamen (SAN) des Zertifikats. Zertifikate mit Großbuchstaben in Domains werden nur zurückgegeben, wenn sie als Primäres Zertifikat im Zielproxy.
• HTTPS-Load-Balancer verwenden beim Herstellen einer Verbindung zum Backend nicht die Erweiterung "Server Name Indication" (SNI), mit Ausnahme von Load-Balancern mit Internet-NEG-Backends. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

• Wenn Sie regionale externe Application Load Balancer mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an alle anderen Cloud Run-Dienste senden, die in anderen Dienstprojekten in derselben Umgebung einer freigegebenen VPC bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.

• Google Cloud kann nicht garantieren, dass eine zugrunde liegende TCP-Verbindung während des gesamten festgelegten Zeitlimits für den Backend-Dienst geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

• Sie können einen regionalen externen Application Load Balancer in der Premium-Stufe nicht mit der Google Cloud Console erstellen. Darüber hinaus sind für diese Load Balancer in der Google Cloud Console nur Regionen verfügbar, die die Standardstufe unterstützen. Verwenden Sie stattdessen die gcloud CLI oder die API. Verwenden Sie stattdessen die gcloud CLI oder die API.

• Mit Cloud CDN können Sie erzwingen, dass ein Objekt oder Objektset vom Cache ignoriert wird, indem eine Cache-Entwertung angefordert wird. Wenn Sie einen globalen externen Application Load Balancer mit projektübergreifender VPC-Dienstreferenz verwenden, haben Dienstprojektadministratoren standardmäßig nicht die erforderlichen Berechtigungen, Cache-Entwertungen anzufordern. Dies liegt daran, dass die Cache-Entwertung im Frontend-Projekt konfiguriert ist, also dem Projekt mit der Weiterleitungsregel, dem Zielproxy und der URL-Zuordnung des Load-Balancers. Daher können Cache-Entwertungen nur von Hauptkonten ausgegeben werden, die IAM-Rollen zum Konfigurieren von Load-Balancer-bezogenen Ressourcen in den Frontend-Projekten haben (z. B. die Rolle „Compute-Netzwerkadministrator“). Dienstadministratoren, die die Bereitstellung der Backend-Dienste in einem separaten Projekt steuern, müssen mit dem Load-Balancer-Administrator des Frontend-Projekts zusammenarbeiten, um die Cache-Entwertung für ihre projektübergreifenden Dienste auszuführen.

Nächste Schritte

• Informationen zum Bereitstellen eines globalen externen Application Load Balancers finden Sie unter Externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

• Informationen zum Bereitstellen eines regionalen externen Application Load Balancers finden Sie unter Regionalen externen Application Load Balancer mit einem Compute Engine-Backend einrichten.

• Wenn Sie bereits Nutzer des klassischen Application Load Balancers sind und eine neue Bereitstellung mit dem globalen externen Application Load Balancer planen, lesen Sie den Abschnitt Migration – Übersicht.

• Informationen zum Automatisieren der Einrichtung des externen Application Load Balancers mit Terraform finden Sie unter Beispiele für Terraform-Module für externe Application Load Balancer.

• Informationen zum Konfigurieren erweiterter Trafficverwaltungsfunktionen, die mit dem globalen externen Application Load Balancer verfügbar sind, finden Sie unter Übersicht über die Trafficverwaltung für globale externe Application Load Balancer.

• Informationen zum Konfigurieren erweiterter Trafficverwaltungsfunktionen, die mit dem regionalen externen Application Load Balancer verfügbar sind, finden Sie unter Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer.

• Weitere Informationen zum Bereitstellen von Websites finden Sie unter Websites bereitstellen.

• Die Standorte für Google PoPs finden Sie unter GFE-Standorte.

• Informationen zur Kapazitätsverwaltung finden Sie in der Anleitung zur Kapazitätsverwaltung mit Load-Balancing und unter Optimierung der Anwendungskapazität mit globalem Load-Balancing.

• Informationen zum Verwenden von Certificate Manager zum Bereitstellen und Verwalten von SSL-Zertifikaten finden Sie in der Übersicht über Certificate Manager.

• Wenn Sie benutzerdefinierte Logik in den Load Balancing-Datenpfad einfügen möchten, konfigurieren Sie Diensterweiterungs-Plug-ins oder -Callouts.

• Nur für regionale externe Application Load Balancer können Sie Apigee Shadow API Discovery verwenden, um Schatten-APIs (auch als nicht dokumentierte APIs bezeichnet) in Ihrer vorhandenen Google Cloud-Infrastruktur zu finden. Lesen Sie sich die zugehörigen Einschränkungen durch, bevor Sie die Shadow API Discovery aktivieren.