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

  • Globaler externer 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.
  • Klassischer 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.
Klassischer Application Load Balancer

Dieser Load-Balancer ist in der Premium-Stufe global, kann aber als regional in der Standardstufe konfiguriert werden.

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 zum Ablauf der Anfragenverteilung finden Sie unter Trafficverteilung.

In der Standard-Netzwerkdienststufe wird das Load-Balancing regional verarbeitet.

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

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.
    Gehe zu „Load-Balancing“
  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-Support
    Klassischer Application Load Balancer EXTERN Global Standard oder Premium
    Regionaler externer Application Load Balancer EXTERNAL_MANAGED Gibt eine Region an Standard oder Premium

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 Backend-Dienste oder Backend-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 Backends müssen mit dem Backend-Dienst oder Backend-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 des globalen externen Application Load Balancers
Komponenten des globalen externen Application Load Balancers

Regional

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

Komponenten eines regionalen externen Application Load Balancers
Komponenten eines regionalen externen Application Load Balancers

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

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.

Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Damit mehrere Ports unterstützt werden können, 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, die an die Envoy-Proxys in derselben Region wie der Load-Balancer weitergeleitet werden.

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.

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.

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

Load-Balancer-Modus Ziel-Proxytypen Vom Proxy hinzugefügte Header Unterstützte benutzerdefinierte Header Cloud Trace wird unterstützt.
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-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (nur Anfragen)
    Enthält Parameter für Cloud Trace.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen)
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-Cloud-Trace-Context: <trace-id>/<span-id>;<trace-options> (nur Anfragen)
    Enthält Parameter für Cloud Trace.
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (see X-Forwarded-For-Header) (nur Anfragen)
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)

Neben den vom Zielproxy hinzugefügten Headern passt der Load Balancer andere HTTP-Header so an:

  • Für den globalen externen Application Load Balancer werden sowohl Anfrage- als auch Antwortheader immer in Kleinbuchstaben umgewandelt. Beispiel: Host wird zu host und Keep-ALIVE zu keep-alive.

    Die einzige Ausnahme bildet die Verwendung globaler Internet-NEG-Backends mit HTTP/1.1. Weitere Informationen zur Verarbeitung von HTTP/1.1-Headern mit globalen Internet-NEGs 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 in der richtigen Groß- und Kleinschreibung verwendet. 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>

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>

URL-Zuordnungen

URL-Zuordnungen definieren die Zuordnungsmuster für eine Weiterleitung von Anfragen, die auf URLs basieren, an die passenden Back-End-Dienste. 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. Für Anfragerouting gibt Ihnen die URL-Zuordnung die Möglichkeit, den Traffic aufzuteilen. Dazu werden die URL-Komponenten untersucht, damit sie Anfragen an verschiedene Backend-Sets senden.

URL-Zuordnungen, die mit globalen externen Application Load Balancern und regionalen externen Application Load Balancern verwendet werden, unterstützen mehrere Features zur erweiterten Trafficverwaltung wie Header-basierte Trafficsteuerung, gewichtete Trafficaufteilung und Anfragespiegelung. Hier finden Sie weitere Informationen:

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 Übersicht über SSL-Zertifikate.

Gegenseitiges TLS

Bei der HTTPS-Kommunikation funktioniert die Authentifizierung normalerweise nur in eine Richtung: der Client überprüft die Identität des Servers. Bei Anwendungen, die den Load-Balancer zum Authentifizieren der Identität von Clients benötigen, die eine Verbindung zu ihm herstellen, unterstützen sowohl ein globaler externer Application Load Balancer als auch ein klassischer Application Load Balancer gegenseitige TLS (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 Trust Store konfigurieren, mit dem der Load-Balancer die Vertrauenskette des Clientzertifikats validiert.

Google Cloud verwendet die Ressource TrustConfig in Certificate Manager, um Zertifikate zu speichern, mit denen der Server das vom Client bereitgestellte Zertifikat prüft. Wenn Sie einen klassischen Application Load Balancer auf der Premium-Netzwerkdienststufe oder einen globalen externen Application Load Balancer verwenden, können Sie den Zertifikatmanager zur Bereitstellung und Verwaltung Ihrer SSL-Zertifikate oder TrustConfig in mehreren Instanzen des Load-Balancers in großem Umfang verwenden. Weitere Informationen finden Sie in der Übersicht zu Certificate Manager.

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

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 und -Buckets

Backend-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Backend-Dienst an einen oder mehrere verknüpfte Backends weiter. 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.

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

In der folgenden Tabelle sind die Backend-Features aufgeführt, die von externen Application Load Balancern in den einzelnen Modi unterstützt werden.


Load-Balancer-Modus
Unterstützte Backends in einem Backend-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 2
Klassischer Application Load Balancer 1
bei Verwendung der Premium-Stufe

Regionaler externer Application Load Balancer 1

1 Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden oder Ingress verwenden

2 Endpunkte des Typs GCE_VM_IP_PORT mit GKE verwenden: Eigenständige zonale NEGs verwenden

3 Nur mit GKE Gateway Controller unterstützt

Hier finden Sie weitere Informationen:

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 den globalen externen Application Load Balancer und den klassischen Application Load Balancer müssen sich alle Backend-Instanzen von Instanzgruppen-Backends und alle Backend-Endpunkte von NEG-Backends 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 Backends in ihren jeweiligen VPC-Netzwerken kommunizieren.
  • Für den regionalen externen Application Load Balancer müssen sich alle Back-Ends im selben VPC-Netzwerk und in derselben Region befinden.

Protokoll für Back-Ends

Wenn Sie einen Backend-Dienst für den Proxy-Load-Balancer konfigurieren, legen Sie das Protokoll fest, über das der Backend-Dienst mit den Backends kommuniziert. Sie können HTTP, HTTPS oder HTTP/2 auswählen. Der Load-Balancer verwendet nur das von Ihnen angegebene Protokoll Der Load-Balancer greift nicht auf eines der anderen Protokolle zurück, wenn er mit dem angegebenen Protokoll keine Verbindung zum Back-End aushandeln kann.

Wenn Sie HTTP/2 verwenden, müssen Sie TLS verwenden. HTTP/2 ohne Verschlüsselung wird nicht unterstützt.

Eine vollständige Liste der unterstützten Protokolle finden Sie unter Load-Balancing-Features: Protokolle vom Load-Balancer zu den Back-Ends.

WebSocket-Unterstützung

HTTP(S)-basierte Load Balancer von Google Cloud bieten eingebaute Unterstützung für 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 Servern. Durch eine HTTP(S)-Anfrage wird der Kanal initiiert. Ausführliche Informationen zum Protokoll finden Sie unter RFC 6455.

Wenn der Load-Balancer eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client gefolgt von einer erfolgreichen Upgrade-Antwort der Back-End-Instanz erkennt, leitet er bidirektionalen Traffic für die Dauer der aktuellen Verbindung über einen Proxy weiter. Wenn die Back-End-Instanz keine erfolgreiche Upgrade-Antwort zurückgibt, schließt der Load-Balancer die Verbindung.

Die Zeitüberschreitung für eine WebSocket-Verbindung hängt vom konfigurierbaren Back-End-Dienst-Zeitlimit des Load-Balancers ab, das standardmäßig 30 Sekunden beträgt. Diese Zeitüberschreitung wird auf WebSocket-Verbindungen unabhängig davon angewendet, ob sie gerade verwendet werden.

Nur bei globalen externen Application Load Balancern und klassischen Application Load Balancern werden WebSocket-Verbindungen nach 24 Stunden automatisch geschlossen. Dieses Limit von 24 Stunden ist nicht anpassbar und tritt unabhängig davon auf,ob die Verbindungen verwendet werden oder ob das Zeitlimit des Backend-Diensts auf einen Wert größer als 86.400 Sekunden festgelegt ist.

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

gRPC mit Ihren Google Cloud-Anwendungen verwenden

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.

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:

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. Beim globalen externen Application Load Balancer und 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
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):
    • 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

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.

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 freigegebenen 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 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 Dienstprojekten. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet und befindet sich derzeit in der Vorschau.

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 freigegebenen 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 freigegebenem VPC-Netzwerk
Regionaler externer Application Load Balancer in einem freigegebenen 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 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

In diesem Modell befinden sich das Frontend und die URL-Zuordnung des Load-Balancers in einem Host- oder Dienstprojekt. Die Backend-Dienste und Backends des Load-Balancers können auf Projekte in der freigegebenen VPC-Umgebung verteilt werden. Auf projektübergreifende Backend-Dienste kann in einer einzelnen URL-Zuordnung verwiesen werden. Dies wird als projektübergreifender Dienstverweis bezeichnet.

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.

Informationen zum Konfigurieren der freigegebenen 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 oder 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 die folgenden Backends hat:

      • Backend-Buckets
      • Serverlose NEGs mit App Engine
      • Globale Internet-NEGs
    • 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 Dienstreferenzen verwenden, empfehlen wir daher, für alle Projekte in Ihrer Organisation eindeutige Backend-Dienstnamen zu verwenden.

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

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung, 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 URL-Zuordnung des Load-Balancers im Dienstprojekt
Frontend und Backend des Load-Balancers in verschiedenen Dienstprojekten

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

Bei dieser Art der Bereitstellung werden das Frontend und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt.

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
Frontend und URL-Zuordnung des Load-Balancers im Hostprojekt

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

Abhängig von der Backend-Dienstkonfiguration kann das Protokoll, mit dem jedes GFE eine Verbindung zu Ihren Backends 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.

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.

Return-Path

Für die globalen externen Application Load Balancer verwendet Google Cloud spezielle Routen, die nicht in Ihrem VPC-Netzwerk für Systemdiagnosen definiert sind. Weitere Informationen finden Sie unter Load-Balancer-Rückgabepfade.

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, werden möglicherweise andere offene Ports für andere Google-Dienste angezeigt, 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 Back-Ends, 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 Back-Ends gesendet. GFEs implementieren Sicherheitsfunktionen wie Google Cloud Armor. Auch ohne Google Cloud Armor-Konfiguration bieten die Google-Infrastruktur und die GFEs gestaffelte Sicherheitsebenen für DDoS-Angriffe und SYN-Floods.

  • 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 in den einzelnen Modi 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 Arten von Zeitüberschreitungen:

Zeitlimittyp und Beschreibung Standardwerte Unterstützt benutzerdefinierte Werte
Global Klassisch Regional
Zeitlimit für Backend-Dienst1

Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte der HTTP-Anfrage an Ihr Backend sendet, bis Ihr Backend das letzte Byte der HTTP-Antwort zurückgibt. Wenn die gesamte HTTP-Antwort nicht innerhalb des Anfrage- oder Antwortzeitlimits an den Load Balancer zurückgegeben wurde, werden die verbleibenden Antwortdaten gelöscht.

Für den WebSocket-Traffic die maximale Dauer des WebSockets, unabhängig davon, ob er inaktiv oder aktiv ist.

  • 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. (Dieselbe 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
2
Backend-HTTP-Keepalive-Zeitlimit
Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem Proxy des Load Balancers und einem Backend inaktiv sein kann. (Dieselbe 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 inaktivem QUIC-Sitzung
Die maximale Zeitspanne, in der eine QUIC-Sitzung zwischen dem (nachgelagerten) Client und dem GFE einer globalen externen Anwendung inaktiv sein kann Load Balancer oder ein klassischer Application Load Balancer.

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. Das Zeitlimit bei Inaktivität des Clients kann konfiguriert werden.

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

2 Die Konfigurationsunterstützung für globale externe Anwendungs-Load-Balancer gilt nicht für WebSocket.

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.

Mit Ausnahme von WebSockets sollten Sie das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festlegen, die das Backend zur Verarbeitung einer HTTP-Antwort erwarten soll. Bei WebSockets hat das Zeitlimit des Backend-Diensts eine andere Bedeutung. Es stellt die maximal mögliche Dauer eines inaktiven oder aktiven WebSockets dar. Sie sollten das Zeitlimit des Backend-Diensts erhöhen, wenn Folgendes zutrifft:

  • Die auf Ihrem Backend ausgeführte Software benötigt mehr Zeit, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben.
  • Sie sehen eine HTTP-408-Antwort mit jsonPayload.statusDetail client_timed_out.
  • Sie benötigen WebSocket-Verbindungen, die länger bestehen bleiben.

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 nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts 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.

  • Websocket-Verbindungen werden nach 24 Stunden automatisch geschlossen. Dies geschieht unabhängig davon,ob sie verwendet werden oder ob das Zeitlimit des Backend-Diensts auf einen Wert größer als 86.400 Sekunden festgelegt ist.

  • Bei einem globalen externen Application Load Balancer oder einem klassischen Application Load Balancer werden Zeitlimits für Backend-Dienste, die größer als ein Tag (86.400 Sekunden) sind, nicht empfohlen, da Google Cloud Google Front Ends regelmäßig für Softwareupdates neu startet und andere routinemäßige Wartungen durchgeführt werden. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten von Google. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google TCP-Verbindungen für die Wartung beendet.

  • Bei einem regionalen externen Application Load Balancer startet Google Cloud 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-Aufgabenneustarts oder -ersetzungen beendet werden.

Regionale externe Application Load Balancer unterstützen den URL-Zuordnungsparameter routeActions.timeout, der das Zeitlimit des Backend-Dienstes überschreiben kann. Wenn routeActions.timeout weggelassen wird, 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.

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

  • Google Cloud Console: Ändern Sie das Feld Zeitlimit des Backend-Diensts des Load Balancers.
  • Google Cloud CLI: 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.
  • API: Ändern Sie bei einem regionalen externen Application Load Balancer den Parameter timeoutSec für die Ressource regionBackendServices.

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. Stattdessen definiert das Backend-Dienst-Zeitlimit eine Gesamtdauer für den WebSocket.

  • 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 ist das HTTP-Keepalive-Zeitlimit des Clients auf 600 Sekunden festgelegt.

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

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. Die HTTP-Keepalive-Zeitlimit des Backends gilt nicht für WebSockets. Stattdessen definiert das Backend-Dienst-Zeitlimit eine Gesamtdauer für den WebSocket.

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 inaktivem 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 die Zeitüberschreitung bei Inaktivität der QUIC-Sitzung ist als Minimum der Zeitüberschreitung bei Inaktivität oder der GFE-Zeitüberschreitung (300 Sekunden) definiert. Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Das Zeitlimit bei 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. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 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. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 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 Überschrift 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.

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.

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.

Traffic-Verteilung

Wenn Sie einem Backend-Dienst eine Backend-Instanzgruppe oder NEG hinzufügen, geben Sie einen Balancing-Modus an, der eine Methode zum Messen der Backend-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 Backend-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, PSC-NEGs (Private Service Connect) und Backend-Buckets wählen GFEs der ersten Ebene eine zweite GFE-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 in einer Region so nah wie möglich an den GFEs der ersten Ebene aus (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:

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:

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

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

HTTP/2-Unterstützung

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

Zum Beispiel:

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

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

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

    Load-Balancing aufrufen

  2. Wählen Sie den Load-Balancer aus, den Sie bearbeiten möchten.

  3. Klicken Sie auf Frontend-Konfiguration.

  4. 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 Drop-down-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 Drop-down-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.

    Derzeit wird HTTP/3 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

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.
  • 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.
  • Sie können einen regionalen externen Application Load Balancer in der Premium-Stufe nicht mit der Google Cloud Console erstellen. Verwenden Sie stattdessen die gcloud CLI oder die API.

Nächste Schritte