Übersicht über externes HTTP(S)-Load-Balancing

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie das externe HTTP(S)-Load-Balancing von Google Cloud konfigurieren möchten.

Externes HTTP(S)-Load-Balancing ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen externen IP-Adresse ausführen und skalieren können. Das externe HTTP(S)-Load-Balancing 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 Anwendungsfälle.

Betriebsarten

Sie können das externe HTTP(S)-Load-Balancing in den folgenden Modi konfigurieren:

  • Globaler externer HTTP(S)-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.
  • Globaler externer HTTP(S)-Load-Balancer (klassisch). Dies ist der klassische externe HTTP(S)-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 HTTP(S)-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 Rechte
Globaler externer HTTP(S)-Load-Balancer Verwenden Sie diesen Load-Balancer für externe HTTP(S)-Arbeitslasten mit global verteilten Nutzern oder Back-End-Diensten in mehreren Regionen.
Globaler externer HTTP(S)-Load-Balancer (klassisch)

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, das Traffic an das nächstgelegene fehlerfreie Back-End mit Kapazität weiterleitet und HTTP(S)-Traffic so nah wie möglich an Ihren Nutzern beendet.

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

  • Kompatibel mit GKE über Ingress oder Gateway (vollständig orchestriert).
  • Unterstützt Google Cloud Armor (einschließlich Bot-Verwaltung).
  • Weniger Traffic-Routing-Features.
Eine vollständige Liste der Funktionen finden Sie auf der Seite Load-Balancing-Features.
Regionaler externer HTTP(S)-Load-Balancer

Dieser Load-Balancer enthält viele Features des bestehenden globalen externen HTTP(S)-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, oder wenn die Standard-Netzwerkdienststufe gewünscht wird.

Eine vollständige Liste finden Sie unter Load-Balancing-Features.

Modus bestimmen

Cloud Console

  1. Rufen Sie in der 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 Lastenausgleichstyp Region Netzwerkstufe
    Globaler externer HTTP(S)-Load-Balancer HTTP(S) PREMIUM
    Globaler externer HTTP(S)-Load-Balancer (klassisch) HTTP(S) (klassisch) STANDARD oder PREMIUM
    Regionaler externer HTTP(S)-Load-Balancer (Vorschau) HTTP(S) Gibt eine Region an STANDARD

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 HTTP(S)-Load-Balancer EXTERNAL_MANAGED Global PREMIUM
    Globaler externer HTTP(S)-Load-Balancer (klassisch) EXTERN Global STANDARD oder PREMIUM
    Regionaler externer HTTP(S)-Load-Balancer EXTERNAL_MANAGED Gibt eine Region an STANDARD

Architektur

Die folgenden Ressourcen sind für die Bereitstellung eines HTTP(S)-Load-Balancers erforderlich:

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

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

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

    • Beim HTTPS-Load-Balancing verwendet der HTTPS-Zielproxy SSL-Zertifikate, um seine Identität gegenüber Clients nachzuweisen. Ein HTTPS-Zielproxy unterstützt bis zu einer dokumentierten Anzahl von SSL-Zertifikaten.
  • Der HTTP(S)-Proxy verwendet eine URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Basierend auf der Routingentscheidung leitet der Proxy Clientanfragen an bestimmte Back-End-Dienste oder Back-End-Buckets weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, z. B. Weiterleitungen an Clients.

  • Ein Back-End-Dienst verteilt Anfragen an fehlerfreie Back-Ends. Die globalen externen HTTP(S)-Load-Balancer unterstützen auch Back-End-Buckets.

    • Ein oder mehrere Back-Ends müssen mit dem Back-End-Dienst oder Back-End-Bucket verbunden sein.
  • Eine Systemdiagnose überwacht regelmäßig die Bereitschaft Ihrer Back-Ends. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können.

  • Firewallregeln für Ihre Back-Ends, um Systemdiagnoseprüfungen zu akzeptieren. Regionale externe HTTP(S)-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 HTTP(S)-Load-Balancers. Diese Architektur gilt sowohl für den globalen externen HTTP(S)-Load-Balancer mit erweiterter Trafficverwaltungsfunktion als auch für den globalen externen HTTP(S)-Load-Balancer (klassisch) in der Premium-Stufe.

Komponenten des globalen externen HTTP(S)-Load-Balancers
Komponenten des globalen externen HTTP(S)-Load-Balancers

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen externen HTTP(S)-Load-Balancers.

Komponenten eines regionalen externen HTTP(S)-Load-Balancers
Komponenten eines regionalen externen HTTP(S)-Load-Balancers

Nur-Proxy-Subnetz

Nur-Proxy-Subnetze sind nur für regionale externe HTTP(S)-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 HTTP(S)-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.
  • Back-End-VMs bzw. Endpunkte aller regionalen externen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse des regionalen externen HTTP(S)-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.

  • Weiterleitungsregeln für einen HTTP-Load-Balancer können nur auf die TCP-Ports 80 und 8080 verweisen.
  • Weiterleitungsregeln für einen HTTPS-Load-Balancer können nur auf den TCP-Port 443 verweisen.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von externen HTTP(S)-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 Front-End des Load-Balancers
Globaler externer HTTP(S)-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.
Globaler externer HTTP(S)-Load-Balancer (klassisch) 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 HTTP(S)-Load-Balancer 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 HTTP(S)-Load-Balancing-Weiterleitungsregeln 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 das HTTP(S)-Load-Balancing 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 HTTP(S)-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 Back-End-Dienst oder Back-End-Bucket konfiguriert

Wird nicht von Cloud CDN

Globaler externer HTTP(S)-Load-Balancer (klassisch) 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 Back-End-Dienst oder Back-End-Bucket konfiguriert
Regionaler externer HTTP(S)-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)

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 Back-End verbunden ist. Diese IP-Adressen liegen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16.

  • Die IP-Adresse des Back-End-Systems.

Daher kann ein vorgelagerter Prozess nach dem Back-End 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 Back-End-Sets senden.

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

Die folgende Tabelle gibt den Typ der URL-Zuordnung an, die für das HTTP(S)-Load-Balancing in den einzelnen Modi erforderlich ist.

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

SSL-Zertifikate

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll, das in SSL-Zertifikaten zum Schutz der Netzwerkkommunikation verwendet wird.

Google Cloud verwendet SSL-Zertifikate, um für einen Load-Balancer Datenschutz und Sicherheit von einem Client bereitzustellen. Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

In der folgenden Tabelle wird der Bereich für das SSL-Zertifikat angegeben, das von HTTP(S)-Load-Balancern in den einzelnen Modi benötigt wird:

Load-Balancer-Modus SSL-Zertifikatsbereich
Globaler externer HTTP(S)-Load-Balancer Global
Globaler externer HTTP(S)-Load-Balancer (klassisch) Global
Regionaler externer HTTP(S)-Load-Balancer Regional

Weitere Informationen zu SSL-Zertifikaten finden Sie hier:

Zertifikatmanager

Wenn Sie den globalen externen HTTP(S)-Load-Balancer (klassisch) auf der Premium-Netzwerkdienststufe verwenden, können Sie Certificate Manager zum Bereitstellen und Verwalten Ihrer SSL-Zertifikate über mehrere Instanzen des globalen externen HTTP(S)-Load-Balancers (klassisch) verwenden. Weitere Informationen finden Sie in der Übersicht über Certificate Manager.

SSL-Richtlinien

Mit SSL-Richtlinien können Sie steuern, welche SSL-Funktionen das HTTPS-Load-Balancer mit den HTTPS-Clients aushandelt.

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 SSL-Richtlinien definieren, die steuern, welche SSL-Funktionen vom Load-Balancer ausgehandelt werden, und eine SSL-Richtlinie mit dem Ziel-HTTPS-Proxy verknüpfen.

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 HTTP(S)-Load-Balancer
Globaler externer HTTP(S)-Load-Balancer (klassisch)
Regionaler externer HTTP(S)-Load-Balancer

Back-End-Dienste und -Buckets

Back-End-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Back-End-Dienst an einen oder mehrere verknüpfte Back-Ends weiter. Ein Beispiel für die Einrichtung eines Load-Balancers mit einem Back-End-Dienst und einem Compute Engine-Back-End finden Sie unter Externen HTTP(S)-Load-Balancers mit einem Compute Engine-Back-End einrichten.

Back-End-Buckets leiten eingehenden Traffic an Cloud Storage-Buckets weiter. Ein Beispiel, das zeigt, wie Sie einen Bucket zu einem externen HTTP(S)-Load-Balancer hinzufügen, finden Sie unter Load-Balancer mit Back-End-Buckets einrichten.

In der folgenden Tabelle sind die Back-End-Features aufgeführt, die vom HTTP(S)-Load-Balancing in jedem Modus unterstützt werden.


Load-Balancer-Modus
Unterstützte Back-Ends in einem Back-End-Dienst Unterstützt Back-End-Buckets Unterstützt Google Cloud Armor Unterstützt Cloud CDN. Unterstützt IAP
Instanzgruppen Zonale NEGs Internet-NEGs Serverlose NEGs Hybrid-NEGs Private Service Connect-NEGs
Globaler externer HTTP(S)-Load-Balancer
Globaler externer HTTP(S)-Load-Balancer (klassisch)
bei Verwendung der Premium-Stufe

Regionaler externer HTTP(S)-Load-Balancer

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 HTTP(S)-Load-Balancer und den globalen externen HTTP(S)-Load-Balancer (klassisch) müssen sich alle Back-Ends im selben Projekt befinden, können sich jedoch in verschiedenen VPC-Netzwerken befinden. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFE-Proxysysteme direkt mit Back-Ends in ihren jeweiligen VPC-Netzwerken kommunizieren.
  • Für den regionalen externen HTTP(S)-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 Back-End-Dienst für den Proxy-Load-Balancer konfigurieren, legen Sie das Protokoll fest, über das der Back-End-Dienst mit den Back-Ends 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 native Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Back-End 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.

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 Back-End-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Back-End-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 HTTP(S)-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 Back-End-Dienst gibt eine Systemdiagnose für Back-End-Instanzen an.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit der Traffic Ihre Back-End-Instanzen erreichen kann. Die Firewallregel muss die folgenden Quellbereiche zulassen:

  • 130.211.0.0/22
  • 35.191.0.0/16

Es ist zwar nicht unbedingt erforderlich, jedoch eine Best Practice, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Back-End-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

Die folgende Tabelle gibt den Bereich der Systemdiagnose an, der vom HTTP(S)-Load-Balancing in den einzelnen Modi unterstützt wird.

Load-Balancer-Modus Systemdiagnosetyp
Globaler externer HTTP(S)-Load-Balancer Global
Globaler externer HTTP(S)-Load-Balancer (klassisch) Global
Regionaler externer HTTP(S)-Load-Balancer Regional

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für HTTP(S)-Load-Balancing sind die folgenden Firewallregeln erforderlich:

  • Für die globalen externen HTTP(S)-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 HTTP(S)-Load-Balancer eine Regel zum Zulassen von eingehendem Traffic erforderlich, um den Traffic aus dem Nur-Proxy-Subnetz zu Ihren Back-Ends zuzulassen.
  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Bereichen der Systemdiagnoseprüfungen zuzulassen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht. Für den globalen externen HTTP(S)-Load-Balancer und den globalen externen HTTP(S)-Load-Balancer (klassisch) können Sie Google Cloud Armor verwenden.

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

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

  • Instanzgruppen-Back-Ends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Back-End-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 Back-End-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 HTTP(S)-Load-Balancer
  • 130.211.0.0/22
  • 35.191.0.0/16
Die Quelle des GFE-Traffics hängt vom Back-End-Typ ab:
  • 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
  • SERVERLESS-NEGs und Back-End-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Globaler externer HTTP(S)-Load-Balancer (klassisch)
  • 130.211.0.0/22
  • 35.191.0.0/16
Die Quelle des GFE-Traffics hängt vom Back-End-Typ ab:
  • 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 Back-End-Buckets: Das Produktionsnetzwerk von Google verarbeitet das Paketrouting.
Regionaler externer HTTP(S)-Load-Balancer
  • 130.211.0.0/22
  • 35.191.0.0/16
Das von Ihnen konfigurierte Nur-Proxy-Subnetz.

Architektur einer freigegebenen VPC

Das HTTP(S)-Load-Balancing unterstützt Netzwerke, die eine freigegebene VPC verwenden. Mit einer freigegebenen VPC können Sie die Zuständigkeiten zwischen Netzwerkadministratoren und Dienstentwicklern klar trennen. Ihre Entwicklungsteams können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren und die Netzwerkinfrastrukturteams das Load-Balancing bereitstellen und verwalten. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, das externe HTTP(S)-Load-Balancing 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 IP-Adresse Weiterleitungsregel Zielproxy und URL-Zuordnung Back-End-Komponenten
Globaler externer HTTP(S)-Load-Balancer Eine globale externe IP-Adresse muss im selben Projekt wie der Load-Balancer definiert werden. Die externe Weiterleitungsregel muss im selben Projekt wie die Back-End-Instanzen (im Dienstprojekt) definiert werden. Ein HTTP-Zielproxy oder HTTPS-Zielproxy mit verknüpfter URL-Zuordnung muss im selben Projekt wie die Back-End-Instanzen definiert werden. Ein globaler Back-End-Dienst muss im selben Projekt wie die Back-End-Instanzen definiert werden. Diese Instanzen müssen sich in Instanzgruppen befinden, die als Back-Ends an den Back-End-Dienst angehängt wurden. Mit den Back-End-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Back-End-Dienst definiert sein.
Globaler externer HTTP(S)-Load-Balancer (klassisch)
Regionaler externer HTTP(S)-Load-Balancer Erstellen Sie das erforderliche Netzwerk und die Subnetze (einschließlich des Nur-Proxy-Subnetzes) im freigegebenen VPC-Hostprojekt. Eine regionale externe IP-Adresse muss im selben Projekt wie die Weiterleitungsregel definiert werden. Die externe Weiterleitungsregel kann entweder im Hostprojekt oder in einem Dienstprojekt definiert werden. Das HTTP-Zielproxy oder HTTPS-Zielproxy mit verknüpfter URL-Zuordnung muss im selben Projekt wie die Weiterleitungsregel definiert werden.

Back-End-Dienste und Back-Ends können in beliebig vielen Dienstprojekten erstellt werden. Eine einzelne URL-Zuordnung kann auf Back-End-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet. Die projektübergreifende Dienstreferenz befindet sich in der Vorschau.

Sie können auch alle Load-Balancer-Komponenten und deren Back-Ends in einem einzelnen Dienstprojekt erstellen.

Jeder Back-End-Dienst muss im selben Projekt wie die Back-End-Instanzen definiert werden, auf die er verweist. Diese Instanzen müssen sich in Instanzgruppen befinden, die als Back-Ends an den Back-End-Dienst angehängt wurden. Mit den Back-End-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Back-End-Dienst definiert werden.

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

Bei einem Load-Balancer, der ein serverloses NEG-Back-End verwendet, muss sich der unterstützende Cloud Run-, Cloud Functions- oder App Engine-Dienst im selben Projekt wie die serverlose NEG befinden.

Projektübergreifender Dienstverweis

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

Der projektübergreifende Dienstverweis bietet Dienstentwicklern und Administratoren Autonomie über die Bereitstellung ihrer Dienste über den zentral verwalteten Load-Balancer. Dienstprojektadministratoren verwenden die IAM-Rolle compute.loadBalancerServiceUser, um Zugriff auf Back-End-Dienste in ihren Projekten zu gewähren.

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

Der projektübergreifende Dienstverweis wird für den globalen externen HTTP(S)-Load-Balancer und den globalen externen HTTP(S)-Load-Balancer (klassisch) nicht unterstützt.

Projektübergreifender Dienst, der auf Beispiel 1 verweist: Front-End und Back-End des Load-Balancers in verschiedenen Dienstprojekten

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

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

Front-End und URL-Zuordnung des Load-Balancers im Dienstprojekt
Front-End und Back-End des Load-Balancers in verschiedenen Dienstprojekten

Projektübergreifender Dienst, der auf Beispiel 2 verweist: Front-End des Load-Balancers im Hostprojekt; Back-Ends in Dienstprojekten

Bei dieser Art der Bereitstellung werden das Front-End und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Back-End-Dienste (und Back-Ends) in Dienstprojekten erstellt.

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

Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt
Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt

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

In diesem Modell befinden sich alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt. Dieses Bereitstellungsmodell wird von allen HTTP(S)-Load-Balancern unterstützt.

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

Regionaler externer HTTP(S)-Load-Balancer in einem freigegebenen VPC-Netzwerk
Regionaler externer HTTP(S)-Load-Balancer im freigegebenen VPC-Netzwerk

Load-Balancer und Back-Ends in einem Hostprojekt

In diesem Modell befinden sich das freigegebene VPC-Netzwerk, die Load-Balancer-Komponenten und die Back-Ends im Hostprojekt. Dieses Modell trennt nicht die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung.

Die Konfiguration für dieses Modell entspricht der Konfiguration des Load-Balancers in einem eigenständigen VPC-Netzwerk.

Funktionsweise von Verbindungen im HTTP(S)-Load-Balancing

Verbindungen bei externen HTTP(S)-Load-Balancern

Die globalen externen HTTP(S)-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 Back-End-Dienstkonfiguration kann das Protokoll, mit dem jedes GFE eine Verbindung zu Ihren Back-Ends herstellt, HTTP, HTTPS oder HTTP/2 sein. Bei HTTP- oder HTTPS-Verbindungen wird die HTTP-Version HTTP 1.1 verwendet.

HTTP-Keepalive ist standardmäßig aktiviert, wie in der HTTP 1.1-Spezifikation angegeben. HTTP-Keepalives versuchen, dieselbe TCP-Sitzung effizient zu verwenden. Es gibt jedoch keine Garantie. Das GFE verwendet ein Keepalive-Zeitlimit von 600 Sekunden, das Sie nicht konfigurieren können. Sie können das Zeitlimit für Anfragen/Antworten jedoch 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.

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 des HTTP(S)-Load-Balancings im Lösungsleitfaden "Optimierung der Anwendungskapazität mit globalem Load-Balancing".

Regionale externe HTTP(S)-Load-Balancer-Verbindungen

Der regionale externe HTTP(S)-Load-Balancer ist ein verwalteter Dienst, der auf dem Envoy-Proxy implementiert wird. Der regionale externe HTTP(S)-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 Back-End-Dienstkonfiguration kann das Protokoll, mit dem Envoy-Proxys eine Verbindung zu Ihren Back-Ends 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 verwendet ein Keepalive-Zeitlimit von 600 Sekunden, das Sie nicht konfigurieren können. Sie können das Zeitlimit für Anfragen/Antworten jedoch 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.
  • HTTP(S)-Load-Balancing unterstützt die Antwort HTTP/1.1 100 Continue.

Eine vollständige Liste der Protokolle, die von HTTP(S)-Load-Balancing-Weiterleitungsregeln 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 die globalen externen HTTP(S)-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 Back-End-VM oder des Containers im VPC-Netzwerk.

Für die regionalen externen HTTP(S)-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 Back-End-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 Back-End-VM oder des Containers im VPC-Netzwerk.

Return-Path

Für die globalen externen HTTP(S)-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 HTTP(S)-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 Back-End. 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

Dieser Abschnitt gilt nur für die globalen externen HTTP(S)-Load-Balancer, die mit GFEs implementiert werden.

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Eine Liste der Ports, die in GFEs wahrscheinlich geöffnet sind, finden Sie unter Weiterleitungsregel: Portspezifikationen. Möglicherweise gibt es andere offene Ports für andere Google-Dienste, die auf GFEs ausgeführt werden.

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 für eine Vielzahl von Ports, wenn Ihr Load-Balancer eine IP-Adresse der Premium-Stufe verwendet. 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 verschiedene IP-Adressen des Load-Balancers oder an die IP-Adresse Ihres Load-Balancers an einem Port gesendet werden, der nicht in Ihrer Weiterleitungsregel konfiguriert ist, führen nicht dazu, dass Pakete an die Back-Ends Ihres Load-Balancers gesendet werden. 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 Back-End-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 HTTP(S)-Load-Balancern in den einzelnen Modi Modus verarbeitet wird.

Load-Balancer-Modus TLS-Terminierung
Globaler externer HTTP(S)-Load-Balancer TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Globaler externer HTTP(S)-Load-Balancer (klassisch) TLS wird auf einem GFE terminiert, das sich überall auf der Welt befinden kann.
Regionaler externer HTTP(S)-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

Das externe HTTP(S)-Load-Balancing umfasst zwei verschiedene Zeitüberschreitungstypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das sich danach richtet, wie lange der Load-Balancer auf eine vollständige HTTP-Antwort vom Back-End wartet. Der Standardwert für das Zeitlimit des Back-End-Diensts beträgt 30 Sekunden. Zulässig sind Zeitlimitwerte im Bereich von 1 bis 2.147.483.647 Sekunden.

    Wenn das Zeitlimit für den Back-End-Dienst beispielsweise auf den Standardwert von 30 Sekunden festgelegt ist, haben die Back-Ends 30 Sekunden Zeit, um auf Anfragen zu antworten. Der Load-Balancer wiederholt die HTTP-GET-Anfrage einmal, wenn das Back-End die Verbindung trennt oder das Zeitlimit überschritten wird, bevor Antwortheader an den Load-Balancer gesendet werden. Wenn das Back-End Antwortheader sendet oder die an das Back-End gesendete Anfrage keine HTTP-GET-Anfrage ist, wiederholt der Load-Balancer die Anfrage nicht. Wenn das Back-End überhaupt nicht antwortet, gibt der Load-Balancer eine HTTP 5xx-Antwort an den Client zurück. Ändern Sie für diese Load-Balancer den Zeitlimitwert, wenn Sie mehr oder weniger Zeit für die Beantwortung der Anfragen durch die Back-Ends einplanen möchten.

    Das Zeitlimit für den Back-End-Dienst sollte auf die maximal mögliche Zeit vom ersten Byte der Anfrage bis zum letzten Byte der Antwort für die Interaktion zwischen dem GFE und Ihrem Back-End festgelegt werden. Wenn Sie WebSockets verwenden, sollte das Zeitlimit des Back-End-Dienstes auf die maximale Dauer eines WebSockets, inaktiv oder aktiv, festgelegt werden.

    Unter diesen Umständen sollten Sie dieses Zeitlimit eventuell erhöhen:

    • Sie erwarten, dass HTTP-Antworten von einem Back-End länger dauern.
    • Sie sehen eine HTTP-408-Antwort mit jsonPayload.statusDetail client_timed_out.
    • Die Verbindung wurde zu einem WebSocket hochgestuft.

    Das von Ihnen festgelegte Zeitlimit für den Back-End-Dienst ist ein Best-Effort-Ziel. Dabei ist nicht garantiert, dass die zugrunde liegenden TCP-Verbindungen für die Dauer dieses Zeitlimits geöffnet bleiben.

    Sie können das Zeitlimit für den Back-End-Dienst auf einen beliebigen Wert festlegen. Wenn Sie ihn jedoch auf einen Wert über einen Tag hinaus (86.400 Sekunden) festlegen, bedeutet dies nicht, dass der Load-Balancer so lange eine TCP-Verbindung beibehält. Es kann sein, muss aber nicht. Google startet GFEs regelmäßig für Softwareupdates und routinemäßige Wartungen neu. Dies wird durch das Zeitlimit des Back-End-Dienstes nicht überschrieben. Je länger Sie das Zeitlimit des Back-End-Diensts festlegen, desto wahrscheinlicher ist es, dass Google eine TCP-Verbindung für die GFE-Wartung beendet. Wir empfehlen Ihnen, eine Wiederholungslogik zu implementieren, um die Auswirkungen solcher Ereignisse zu reduzieren.

    Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

    Das Zeitlimit des Back-End-Diensts ist keine HTTP-Leerlaufzeitüberschreitung (Keepalive-Zeitüberschreitung). Es kann vorkommen, dass die Ein- und Ausgabe (IO) des Back-Ends aufgrund eines langsamen Clients, z. B. ein Browser mit langsamer Verbindung, blockiert wird. Diese Wartezeit wird nicht auf das Zeitlimit des Back-End-Diensts angerechnet.

    Bei regionalen externen HTTP(S)-Load-Balancern kann der routeActions.timeout-Parameter der URL-Zuordnung das Zeitlimit des Back-End-Dienstes überschreiben. Das Zeitlimit für den Back-End-Dienst wird als Standardwert für routeActions.timeout verwendet.

  • Ein HTTP-Keepalive-Zeitlimit, dessen Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Dieser Wert kann nicht konfiguriert werden, indem Ihr Back-End-Dienst geändert wird. Sie müssen die von den Back-Ends verwendete Webserversoftware so konfigurieren, dass die darin angegebene Keepalive-Zeitüberschreitung länger als 600 Sekunden ist, damit Verbindungen nicht vorzeitig vom Back-End geschlossen werden. Dieses Zeitlimit gilt nicht für WebSockets. In dieser Tabelle werden die Änderungen veranschaulicht, die erforderlich sind, um Keepalive-Zeitüberschreitungen für häufig verwendete Webserversoftware zu ändern:
    Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Neuversuche

Die Unterstützung von HTTP(S)-Load-Balancing für die Wiederholungslogik hängt vom Modus des externen HTTP(S)-Load-Balancers ab.

Load-Balancer-Modus Wiederholungslogik
Globaler externer HTTP(S)-Load-Balancer

Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl der Wiederholungen, 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-502-, 503- oder 504-Antworten (retryConditions=["gateway-error"]) führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt.

Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

Globaler externer HTTP(S)-Load-Balancer (klassisch)

Wiederholungsrichtlinien können 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 Back-End-Instanz in einer Gruppe vorhanden ist und die Verbindung zu dieser Back-End-Instanz fehlschlägt, beträgt der Prozentsatz fehlerhafter Back-End-Instanzen 100 %, sodass das GFE die Anfrage nicht wiederholt.

Der Load-Balancer wiederholt fehlerhafte GET-Anfragen unter bestimmten Umständen, etwa wenn das Zeitlimit des Back-End-Diensts abgelaufen ist. Wiederholungsversuche sind auf 25 Versuche beschränkt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert. Weitere Informationen finden Sie unter Logging und Monitoring für das HTTP(S)-Load-Balancing.

Fehlgeschlagene Anfragen führen dazu, dass der Load-Balancer die HTTP-Antwort 502 synthetisiert.

Regionaler externer HTTP(S)-Load-Balancer

Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl der Wiederholungen, 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-502-, 503- oder 504-Antworten (retryConditions=["gateway-error"]) 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 Back-End-Antworten, sodass diese das Back-End 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 das externe HTTP(S)-Load-Balancing.
  • Die Anfragemethode lässt keinen Textkörper zu, die Anfrage enthält 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 das externe HTTP(S)-Load-Balancing.
  • Die HTTP-Version ist nicht bekannt.

Traffic-Verteilung

Wenn Sie einem Back-End-Dienst eine Back-End-Instanzgruppe oder NEG hinzufügen, geben Sie einen Balancing-Modus an, der eine Methode zum Messen der Back-End-Last und eine Zielkapazität definiert. Das externe HTTP(S)-Load-Balancing unterstützt zwei Balancing-Modi:

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

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

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

Globaler externer HTTP(S)-Load-Balancer

Bevor ein Google Front End (GFE) Anfragen an Back-End-Instanzen sendet, schätzt das GFE, welche Back-End-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 Back-End-Instanz für jede Anfrage zu optimieren.

Für globale externe HTTP(S)-Load-Balancer (klassisch) wird der Balancing-Modus verwendet, um das bevorzugte Back-End (Instanzgruppe oder NEG) auszuwählen. Der Traffic wird dann nach dem Round-Robin-Verfahren auf Instanzen oder Endpunkte innerhalb des Back-Ends verteilt.

Beim globalen externen HTTP(S)-Load-Balancer erfolgt das Load-Balancing auf zwei Ebenen. Der Balancing-Modus bestimmt die Gewichtung oder den Anteil des Traffics, der an jedes Back-End (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 Back-End-Dienst).

Regionaler externer HTTP(S)-Load-Balancer

Bei regionalen externen HTTP(S)-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 Back-End-Dienst Traffic empfängt, leitet er ihn zuerst an ein Back-End (Instanzgruppe oder NEG) gemäß dem Balancing-Modus des Back-Ends weiter. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß der Load-Balancing-Richtlinie für den Ort auf Instanzen oder Endpunkte in dieser Back-End-Gruppe verteilt.

Hier finden Sie weitere Informationen:

Anfrageverteilung

Ob der Traffic regional oder global verteilt ist, hängt davon ab, welcher Load-Balancer-Modus und welche Netzwerkdienststufe verwendet werden.

Premium-Stufe:

  • Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
  • Wenn Sie einen Back-End-Dienst mit Back-Ends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Back-End-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist. Weitere Informationen zu diesem Vorgang finden Sie auf dieser Seite.

Standardstufe:

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

  • Sie können Back-Ends in derselben Region wie die Weiterleitungsregel konfigurieren. Der hier dokumentierte Prozess gilt weiterhin, aber der Load-Balancer leitet Anfragen nur an fehlerfreie Back-Ends in dieser einen Region weiter.

Ablauf der Anfrageverteilung:

Der Balancing-Modus und die Auswahl des Ziels definieren die Back-End-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG, zonalen Instanzgruppe oder Zone einer regionalen Instanzgruppe. Die Verteilung innerhalb einer Zone erfolgt mit einem konsistenten Hashing für globale externe HTTP(S)-Load-Balancer (klassisch) und kann mithilfe der Load-Balancing-Richtlinie für den Ort für globale externe HTTP(S)-Load-Balancer und regionale externe HTTP(S)-Load-Balancer konfiguriert werden.

GFE-basierte globale externe HTTP(S)-Load-Balancer verwenden den folgenden Prozess, um eingehende Anfragen zu verteilen:

  1. Die externe IP-Adresse der Weiterleitungsregel wird durch Edge-Router an den Rändern des Google-Netzwerks beworben. Jedes Advertising listet einen nächsten Hop zu einem Layer-3/4-Load-Balancing-System (Maglev) auf.
  2. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter. Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
    1. Die URL-Zuordnung wählt einen Back-End-Dienst aus.
    2. Wenn ein Back-End-Dienst eine Instanzgruppe oder GCE_VM_IP_PORT-NEG-Back-Ends verwendet, bevorzugen die GFEs der ersten Ebene GFEs der zweiten Ebene, die sich innerhalb oder in der Nähe der Region mit der Instanzgruppe oder NEG befinden.
    3. Bei Back-End-Buckets und Back-End-Diensten mit Hybrid-NEGs, serverlosen NEGs und Internet-NEGs wählen die GFEs der ersten Ebene GFEs der zweiten Ebene in einer Teilmenge von Regionen aus, sodass die Umlaufzeit zwischen den beiden GFEs minimiert wird.

      Die GFE-Einstellung der zweiten Ebene ist keine Garantie und kann sich je nach den Netzwerkbedingungen und Wartungsaktivitäten von Google dynamisch ändern.

      GFEs der zweiten Ebene erkennen den Status der Systemdiagnose und die tatsächliche Nutzung der Back-End-Kapazität.

  3. Das GFE der zweiten Ebene leitet Anfragen an Back-Ends in Zonen innerhalb seiner Region weiter.
  4. Bei der Premium-Stufe senden GFEs der zweiten Ebene manchmal Anfragen an Back-Ends in Zonen unterschiedlicher Regionen. Dieses Verhalten wird als Spillover bezeichnet.
  5. Das Spillover unterliegt zwei Prinzipien:

    • Ein Spillover ist möglich, wenn alle Back-Ends, die einem GFE einer zweiten Ebene bekannt sind, ausgelastet oder fehlerhaft sind.
    • Das GFE der zweiten Ebene enthält Informationen für fehlerfreie, verfügbare Back-Ends in Zonen einer anderen Region.

    Die GFEs der zweiten Ebene sind in der Regel so konfiguriert, dass sie eine Teilmenge der Back-End-Standorte bereitstellen.

    Das Spillover-Verhalten schöpft nicht alle möglichen Google Cloud-Zonen aus. Wenn Sie Traffic von Back-Ends in einer bestimmten Zone oder einer gesamten Region weiterleiten müssen, legen Sie den Kapazitätsskalierer auf null fest. Wenn Sie Back-Ends für Systemdiagnosen konfigurieren, ist nicht garantiert, dass das GFE der zweiten Ebene Anfragen an Back-Ends in Zonen einer anderen Region weiterleitet.

  6. Beim Verteilen von Anfragen an Back-Ends arbeiten GFEs auf einer zonalen Ebene.

    Bei einer geringen Anzahl von Anfragen pro Sekunde bevorzugen GFEs der zweiten Ebene manchmal eine bestimmte Zone innerhalb einer Region. Dieses Verhalten ist normal und wird erwartet. Die Verteilung der Zonen in der Region ist erst gleichmäßig, wenn der Load-Balancer mehr Anfragen pro Sekunde erhält.

Sitzungsaffinität

Mit der Sitzungsaffinität wird versucht, Anfragen gemäß konfiguriertem Balancing-Modus von einem bestimmten Client an dasselbe Back-End zu senden, wenn das Back-End 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.

HTTP(S)-Load-Balancing bietet die folgenden Typen von Sitzungsaffinität:

In der folgenden Tabelle sind die unterstützten Optionen für die Sitzungsaffinität für jeden Modus des HTTP(S)-Load-Balancings zusammengefasst:

Load-Balancer-Modus Optionen der Sitzungsaffinität
  Client-IP Generiertes Cookie Header-Feld HTTP-Cookie
Globaler externer HTTP(S)-Load-Balancer
Globaler externer HTTP(S)-Load-Balancer (klassisch)
Regionaler externer HTTP(S)-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.
  • HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt nicht das Ausführen des WebSocket-Protokolls über einen einzelnen Stream einer HTTP/2-Verbindung (RFC 8441).
  • HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt keinen Server-Push.
  • Die gRPC-Fehlerrate und das Anfragevolumen sind in der Google Cloud API oder der Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und der Bericht mit den Monitoring-Daten den HTTP-Antwortcode "OK 200".

HTTP/3- und Google QUIC-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 HTTP(S)-Load-Balancer, Cloud CDN und Clients unterstützt.

Zum Beispiel:

  • IETF QUIC ist ein Protokoll der Transportschicht, das eine Überlastungssteuerung ähnlich wie TCP bietet und mit SSL/TLS vergleichbare Sicherheitsfunktionen für HTTP/2 mit verbesserter Leistung bereitstellt.
  • 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 wirkt sich auf Verbindungen zwischen Clients und dem Load-Balancer aus, nicht auf Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.
  • HTTP/3-Verbindungen verwenden das BBR-Protokoll zur Überlastungssteuerung.

Das Aktivieren von 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 HTTP(S)-Load-Balancing in jedem Modus.

Load-Balancer-Modus HTTP/3-Unterstützung
Globaler externer HTTP(S)-Load-Balancer
Globaler externer HTTP(S)-Load-Balancer (klassisch)
Regionaler externer HTTP(S)-Load-Balancer

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 in der targetHttpsProxy-Ressource eines externen HTTP(S)-Load-Balancers als ENABLE konfiguriert ist, enthalten Antworten vom HTTP(S)-Load-Balancer den folgenden alt-svc-Header-Wert:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,
h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,
quic=":443"; ma=2592000; v="46,43"

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

Sie können die HTTP/3-Unterstützung für Ihren Load-Balancer explizit aktivieren, indem Sie quicOverride auf ENABLE setzen.

Wenn Sie HTTP/3 aktivieren, 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.

HTTP(S)-Load-Balancing bietet 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

Die Unterstützung für HTTP/3 und Google QUIC wird den Clients angezeigt. HTTP/3 wird mit einer höheren Priorität beworben. Clients, die beide Protokolle unterstützen, sollten HTTP/3 gegenüber Google QUIC bevorzugen.

Hinweis: TLS 0-RTT (auch als TLS Early Data bezeichnet) wird implizit unterstützt, wenn Google QUIC vom Client ausgehandelt wird. Es wird jedoch nicht unterstützt, wenn HTTP/3 verwendet wird.

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 Front-End-Konfiguration.

  4. Wählen Sie die Front-End-IP-Adresse und den Front-End-Port aus, den Sie bearbeiten möchten. Zum Bearbeiten von HTTP/3-Konfigurationen müssen die IP-Adresse und der Port HTTPS (Port 443) 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 Front-End explizit zu aktivieren.
  3. Wenn Sie mehrere Front-End-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 Front-End explizit zu deaktivieren.
  3. Wenn Sie mehrere Front-End-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.

    Derzeit wird HTTP/3 beworben, wenn Sie NONE auswählen, aber Google QUIC nicht beworben.

    In der 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

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

  • Die auf einem Clientzertifikat basierte Authentifizierung, auch als gegenseitige TLS-Authentifizierung bezeichnet, wird von HTTPS-Load-Balancern nicht unterstützt.
  • 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 Back-End nicht die Erweiterung "Server Name Indication" (SNI), mit Ausnahme von Load-Balancern mit Internet-NEG-Back-Ends. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.
  • Wenn Google Cloud Armor mit dem globalen externen HTTP(S)-Load-Balancer mit erweiterter Trafficverwaltungsfunktion verwendet wird, können bestimmte Interaktionen zwischen Google Cloud Armor-Regeln und EXTERNAL_MANAGED-Back-End-Diensten zu HTTP 408-Zeitüberschreitungen führen, insbesondere wenn Anfragen POST-Textkörper enthalten.
  • Wenn Sie regionale externe HTTP(S)-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 Dienstprojekte in derselben Umgebung einer freigegebenen VPC bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.
  • reCAPTCHA Enterprise for WAF mit Google Cloud Armor wird nur mit dem globalen externen HTTP(S)-Load Balancer (klassisch) unterstützt. Mit dem globalen externen HTTP(S)-Load-Balancer mit erweiterter Trafficverwaltung wird es nicht unterstützt.

Nächste Schritte