Interner Application Load Balancer – Übersicht

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie interne Application Load Balancer konfigurieren möchten.

Ein Trusted Cloud by S3NS interner Application Load Balancer ist ein proxybasierter Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer einzelnen internen IP-Adresse ausführen und skalieren können. Der interne Application Load Balancer verteilt HTTP- und HTTPS-Traffic an Back-Ends, die auf einer Vielzahl von Trusted Cloud Plattformen wie Compute Engine, Google Kubernetes Engine (GKE) und Cloud Run gehostet werden. Weitere Informationen finden Sie unter Anwendungsfälle.

Betriebsarten

Dieser Load Balancer ist im regionalen Modus verfügbar und wird im Folgenden als regionaler interner Application Load Balancer bezeichnet. Der Load Balancer ist als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert. Dazu gehören erweiterte Funktionen zur Trafficverwaltung wie Trafficspiegelung, gewichtete Trafficaufteilung, anfrage- oder antwortbasierte Header-Transformationen und mehr. Im regionalen Modus müssen sich Back-Ends in einer einzelnen Trusted Cloud Region befinden. Clients können auf diese Region beschränkt sein oder sich in einer beliebigen Region befinden, je nachdem, ob der globale Zugriff für die Weiterleitungsregel deaktiviert oder aktiviert ist.

Architektur und Ressourcen

Das folgende Diagramm zeigt die Trusted Cloud Ressourcen, die für interne Application Load Balancer erforderlich sind:

Regionaler interner Application Load Balancer

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen internen Application Load Balancers in der Premium-Stufe.

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

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

Nur-Proxy-Subnetz

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-Netzwerk, in dem Sie regionale interne 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 einer Region und einem 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 internen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine intern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.

Weiterleitungsregel und IP-Adresse

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

Angabe der IP-Adresse Jede Weiterleitungsregel verweist auf eine einzelne regionale IP-Adresse, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Sie können entweder eine statische IP-Adresse reservieren, die Sie verwenden können, oder Cloud Load Balancing eine Adresse für Sie zuweisen lassen. Wir empfehlen, eine statische IP-Adresse zu reservieren. Andernfalls müssen Sie den DNS-Eintrag jedes Mal, wenn Sie eine Weiterleitungsregel löschen und eine neue erstellen, mit der neu zugewiesenen sitzungsspezifischen IP-Adresse aktualisieren.

Clients verwenden die IP-Adresse und den Port, um eine Verbindung zu den Envoy-Proxys des Load Balancers herzustellen. Die IP-Adresse der Weiterleitungsregel ist die IP-Adresse des Load Balancers (manchmal auch virtuelle IP-Adresse oder VIP genannt). Clients, die eine Verbindung zu einem Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. Eine vollständige Liste der unterstützten Protokolle finden Sie unter Vergleich der Load-Balancer-Features.

Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus einem Subnetz im selben Netzwerk und in derselben Region wie die Back-Ends stammen.

Portspezifikation. Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe interne IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP- oder Ziel-HTTPS-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 internen Application Load Balancern verwendet werden, hängen vom Modus des Load-Balancers ab.

Regionaler interner Application Load Balancer
Weiterleitungsregel

forwardingRules.insert-Methode
Regionale IP-Adresse

addresses.insert-Methode
Load-Balancing-Schema

INTERNAL_MANAGED
IP-Adresse (optional)

SHARED_LOADBALANCER_VIP
Routing vom Client zum Frontend des Load Balancers

Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können. Backends müssen sich auch in derselben Region wie der Load Balancer befinden.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von internen Application Load Balancern verwendet werden, VPC-Netzwerken zugeordnet werden.

Load-Balancer-Modus VPC-Netzwerkzuordnung
Regionaler interner Application Load Balancer

Regionale interne IPv4-Adressen sind immer in VPC-Netzwerken vorhanden. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie das Subnetz angeben, aus dem die interne IP-Adresse stammt. Dieses Subnetz muss sich in derselben Region und im selben VPC-Netzwerk befinden, in der bzw. in dem ein Nur-Proxy-Subnetz erstellt wurde. Daher besteht eine implizite Netzwerkzuordnung.

Zielproxy

Ein HTTP- oder HTTPS-Zielproxy beendet HTTP(S)-Verbindungen von Clients. Der HTTP(S)-Proxy prüft die URL-Zuordnung, um zu ermitteln, wie Traffic an Back-Ends weitergeleitet wird. Ein Ziel-HTTPS-Proxy verwendet ein SSL-Zertifikat, um sich bei Clients zu authentifizieren.

Der Load-Balancer behält den Host-Header der ursprünglichen Clientanfrage bei. Der Load-Balancer hängt außerdem zwei IP-Adressen 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. Wenn die Anfrage einen X-Forwarded-For-Header hat, werden andere Informationen wie die von Proxys auf dem Weg zum Load-Balancer aufgezeichneten IP-Adressen vor den beiden IP-Adressen gespeichert. Der Load Balancer überprüft keine IP-Adressen, die vor den letzten beiden IP-Adressen in diesem Header liegen.

Wenn Sie einen Proxy als Back-End-Server ausführen, fügt dieser Proxy in der Regel weitere Informationen an den Header X-Forwarded-For an. Dies kann in Ihrer Software erforderlich sein. Die weitergeleiteten Anfragen vom Load-Balancer stammen von einer IP-Adresse im Nur-Proxy-Subnetz. Ihr Proxy auf der Backend-Instanz erfasst möglicherweise diese Adresse sowie die eigene IP-Adresse der Backend-Instanz.

Je nach der Art des Traffics, den Ihre Anwendung verarbeiten muss, können Sie einen Load Balancer mit einem Ziel-HTTP-Proxy oder einem Ziel-HTTPS-Proxy konfigurieren.

In der folgenden Tabelle sind die Zielproxy APIs aufgeführt, die für interne Application Load Balancer erforderlich sind:

Load-Balancer-Modus Zielproxy
Regionaler interner Application Load Balancer

SSL-Zertifikate

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

Regionale interne Application Load Balancer unterstützen selbstverwaltete Compute Engine-SSL-Zertifikate.

URL-Zuordnungen

Der HTTP(S)-Zielproxy verwendet URL-Zuordnungen, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Anhand dieser Entscheidung leitet der Proxy Clientanfragen an bestimmte Backend-Dienste weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, unter anderem das Überschreiben von Headern, das Senden von Weiterleitungen an Clients und das Konfigurieren von Zeitlimitrichtlinien.

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

Load-Balancer-Modus Typ der URL-Zuordnung
Regionaler interner Application Load Balancer regionUrlMaps

Backend-Dienst

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

Bereich des Back-End-Dienstes

In der folgenden Tabelle ist angegeben, welche Backend-Dienstressource und welcher Bereich von internen Application Load Balancern verwendet werden:

Load-Balancer-Modus Ressource für Backend-Dienst
Regionaler interner Application Load Balancer regionBackendServices

Protokoll für Back-Ends

Für Backend-Dienste für Application Load Balancer muss eines der folgenden Protokolle verwendet werden, um Anfragen an Back-Ends zu senden:

  • HTTP, das HTTP/1.1 und kein TLS verwendet
  • HTTPS, das HTTP/1.1 und TLS verwendet
  • HTTP/2, das HTTP/2 und TLS verwendet (HTTP/2 ohne Verschlüsselung wird nicht unterstützt).
  • H2C, das HTTP/2 über TCP verwendet. TLS ist nicht erforderlich. H2C wird für klassische Application Load Balancer nicht unterstützt.

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

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

Back-Ends

Ein regionaler externer Application Load Balancer unterstützt die folgenden Arten von Backends:

  • Instanzgruppen
  • Zonale NEGs
  • Internet-NEGs
  • Hybrid-NEGs

Back-Ends und VPC-Netzwerke

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

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

    Definition des Backend-Netzwerks

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

    Anforderungen an das Backend-Netzwerk

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

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

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

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

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an Nicht-nic0-Schnittstellen (entweder vNICs oder dynamische Netzwerkschnittstellen) senden möchten, verwenden Sie stattdessen NEG-Backends.

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

Backend-Teilmengeneinstellung

Die Backend-Teilmengeneinstellung ist eine optionale Funktion, die von regionalen internen Application Load Balancern unterstützt wird und die Leistung und Skalierbarkeit verbessert, indem jeder Proxy-Instanz eine Teilmenge von Backends zugewiesen wird.

Standardmäßig ist die Backend-Teileinstellung deaktiviert. Informationen zum Aktivieren dieser Funktion finden Sie unter Backend-Teilmengeneinstellung für regionale interne Application Load Balancer.

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. Bei Hybrid-NEGs stammen Systemdiagnosen jedoch stattdessen aus dem Nur-Proxy-Subnetz. Weitere Informationen finden Sie unter Verteilte Systemdiagnosen für Envoy.

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 interne Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie im Abschnitt Systemdiagnosen unter „Load-Balancing-Features“.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von internen Application Load Balancern unterstützt werden:

Load-Balancer-Modus Systemdiagnosetyp
Regionaler interner Application Load Balancer regionHealthChecks

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für einen internen Application Load Balancer sind die folgenden Firewallregeln erforderlich:

  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den zentralen Systemdiagnosebereichen von Google zuzulassen. Weitere Informationen zu den spezifischen IP-Adressbereichen für Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.
  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.

Für die folgenden Bereiche gelten bestimmte Ausnahmen von den Firewallregeln:

  • Traffic aus den Prüfbereichen der Systemdiagnose von Google muss bei Hybrid-NEGs nicht zugelassen werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie Traffic aus den Prüfbereichen der Systemdiagnose von Google für die zonalen NEGs zulassen.
  • Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuell oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT-Gateway verwenden.

Clientzugriff

Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist.

Bei regionalen internen Application Load Balancern müssen sich Clients standardmäßig in derselben Region wie der Load Balancer befinden. Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können.

In der folgenden Tabelle wird der Clientzugriff für regionale interne Application Load Balancer zusammengefasst:

Globaler Zugriff deaktiviert Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

GKE-Unterstützung

GKE verwendet interne Application Load Balancer auf folgende Weise:

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

  • Interne Ingress-Objekte, die mit dem GKE-Ingress-Controller erstellt werden, sind immer regionale interne Application Load Balancer. Der GKE-Ingress-Controller verwendet immer zonale GCE_VM_IP_PORT-NEG-Back-Ends.

Architekturen freigegebener VPCs

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

Subnetze und IP-Adresse Frontend-Komponenten Backend-Komponenten

Erstellen Sie das erforderliche Netzwerk und die Subnetze (einschließlich des Nur-Proxy-Subnetzes) im freigegebenen VPC-Hostprojekt.

Die interne IP-Adresse des Load-Balancers kann entweder im Hostprojekt oder in einem Dienstprojekt definiert werden. Sie muss jedoch ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verwenden. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

 Die regionale interne 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übergreifender Dienstverweis 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 freigegebene 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.

Der Load-Balancer verwendet IP-Adressen und Subnetze aus dem Hostprojekt. Clients können auf einen internen Application Load Balancer zugreifen, wenn sie sich im selben freigegebenen VPC-Netzwerk und in derselben Region wie der Load Balancer befinden. Clients können sich im Hostprojekt, in einem angehängten Dienstprojekt oder in verbundenen Netzwerken befinden.

Interner Application Load Balancer in einem freigegebene VPC-Netzwerk.
Interner Application Load Balancer in einem freigegebene VPC-Netzwerk (zum Vergrößern klicken).

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

Bei einem internen Application Load Balancer, der ein serverloses NEG-Backend verwendet, muss sich der Cloud Run-Sicherungsdienst im selben Dienstprojekt wie der Backend-Dienst und die serverlose NEG befinden. Die Frontend-Komponenten (Weiterleitungsregel, Zielproxy, URL-Zuordnung) des Load-Balancers können entweder im Hostprojekt, im selben Dienstprojekt wie die Backend-Komponenten oder in einem anderen Dienstprojekt in derselben Umgebung mit freigegebener VPC erstellt werden.

Projektübergreifender Dienstverweis

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

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

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

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

Bei internen Application Load Balancern wird der projektübergreifende Dienstverweis nur in Umgebungen mit freigegebene VPC unterstützt.

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

Hinweise zur Verwendung des projektübergreifenden Dienstverweises

  • Sie können nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst regionale Internet-NEG-Backends hat. Alle anderen Backend-Typen werden unterstützt.
  • Trusted Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie also projektübergreifende Dienstverweise verwenden, empfehlen wir, in allen Projekten 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 einer freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load-Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

Frontend und URL-Zuordnung des Load Balancers im Dienstprojekt.
Frontend und Backend des Load Balancers in verschiedenen Dienstprojekten (zum Vergrößern klicken)

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

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

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die Rolle „Nutzer von Compute-Load-Balancer-Diensten“ (roles/compute.loadBalancerServiceUser).

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

Zeitüberschreitungen und Wiederholungsversuche

Interne Application Load Balancer unterstützen die folgenden Zeitüberschreitungstypen:

Zeitlimittyp und Beschreibung Standardwerte Unterstützt benutzerdefinierte Werte
Zeitlimit für Backend-Dienst

Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte einer Anfrage an das Backend sendet, bis das Backend das letzte Byte der HTTP-Antwort an den Load Balancer zurückgibt. Wenn das Backend die gesamte HTTP-Antwort nicht innerhalb dieses Zeitlimits an den Load Balancer zurückgegeben hat, werden die verbleibenden Antwortdaten gelöscht.
  • Für serverlose NEGs in einem Backend-Dienst: 60 Minuten
  • Für alle anderen Backend-Typen in einem Backend-Dienst: 30 Sekunden
Client-HTTP-Keepalive-Zeitlimit

Die maximale Zeitspanne, die die TCP-Verbindung zwischen einem Client und dem verwalteten Envoy-Proxy des Load Balancers inaktiv sein kann. Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.

 610 Sekunden
HTTP-Keepalive-Zeitlimit des Back-Ends

Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem verwalteten Envoy-Proxy des Load-Balancers und einem Backend inaktiv sein kann. Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.

 10 Minuten und 600 Sekunden

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.

Wir empfehlen, das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festzulegen, die das Backend zur Verarbeitung einer HTTP-Antwort erwarten soll. Wenn die auf Ihrem Backend ausgeführte Software mehr Zeit benötigt, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben, empfehlen wir, das Zeitlimit für den Backend-Dienst zu erhöhen.

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. Trusted Cloud garantiert auch 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.

Bei WebSocket-Verbindungen, die mit internen Application Load Balancern verwendet werden, folgen aktive WebSocket-Verbindungen nicht der Zeitüberschreitung des Backend-Dienstes. Inaktive WebSocket-Verbindungen werden nach der Zeitüberschreitung des Backend-Dienstes geschlossen.

Trusted Cloud startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgabenneustarts oder -ersetzungen beendet werden.

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

Console

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

gcloud

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

API

Ändern Sie den Parameter timeoutSec für die Ressource regionBackendServices.

Client-HTTP-Keepalive-Zeitlimit

Das Client-HTTP-Keepalive-Zeitlimit stellt die maximale Zeitspanne dar, die eine TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy inaktiv sein kann. Der Standardwert für das Client-HTTP-Keepalive-Zeitlimit beträgt 610 Sekunden. Sie können das Zeitlimit mit einem Wert zwischen 5 und 1.200 Sekunden konfigurieren.

Ein HTTP-Keepalive-Zeitlimit wird auch als TCP-Leerlaufzeitlimit bezeichnet.

Das Client-HTTP-Zeitlimit des Load Balancers muss 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).

Wenn das Client-HTTP-Keepalive-Zeitlimit abläuft, sendet entweder das GFE oder der Envoy-Proxy ein TCP FIN an den Client, um die Verbindung ordnungsgemäß zu schließen.

HTTP-Keepalive-Zeitlimit des Back-Ends

Interne Application Load Balancer sind Proxys, die eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy und eine zweite TCP-Verbindung zwischen dem Envoy-Proxy und Ihren Back-Ends verwenden.

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

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. So wird sichergestellt, dass der Load Balancer inaktive Verbindungen mindestens 10 Minuten lang aufrechterhält. Danach kann der Load Balancer jederzeit Beendigungs-Pakete an das Back-End senden.

Das Backend-Keepalive-Zeitlimit des Load Balancers muss 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.

Wenn das Backend-HTTP-Keepalive-Zeitlimit abläuft, sendet entweder das GFE oder der Envoy-Proxy ein TCP-FIN an die Backend-VM, um die Verbindung ordnungsgemäß zu schließen.

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;

Wiederholungsversuche

Zum Konfigurieren von Wiederholungsversuchen können Sie in der URL-Zuordnung eine Wiederholungsrichtlinie verwenden. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Der maximal konfigurierbare Wert für perTryTimeout ist 24 Stunden.

Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt.

HTTP-POST-Anfragen werden nicht wiederholt.

Bei wiederholten Requests wird nur ein Log-Eintrag für die endgültige Antwort generiert.

Weitere Informationen finden Sie unter Logging und Monitoring für Application Load Balancer.

Auf verbundene Netzwerke zugreifen

Ihre Clients kann auf einen internen Application Load Balancer in Ihrem VPC-Netzwerk über ein verbundenes Netzwerk zugreifen und zwar mithilfe von:

  • VPC-Netzwerk-Peering
  • Cloud VPN und Cloud Interconnect

Ausführliche Beispiele finden Sie unter Interne Application Load Balancer und verbundene Netzwerke.

Sitzungsaffinität

Die Sitzungsaffinität, die für den Backend-Dienst von Application Load Balancern konfiguriert ist, versucht, Anfragen von einem bestimmten Client an dasselbe Backend zu senden, solange die Anzahl der fehlerfreien Backend-Instanzen oder ‑Endpunkte konstant bleibt und die zuvor ausgewählte Backend-Instanz bzw. der Endpunkt nicht ausgelastet ist. Die Zielkapazität des Balancing-Modus bestimmt, wann das Backend ausgelastet ist.

In der folgenden Tabelle sind die verschiedenen Arten von Optionen für die Sitzungsaffinität aufgeführt, die für die verschiedenen Application Load Balancer unterstützt werden. Im folgenden Abschnitt Arten der Sitzungsaffinität wird jeder Sitzungsaffinitätstyp genauer beschrieben.

Tabelle: Unterstützte Einstellungen für die Sitzungsaffinität
Produkt Optionen der Sitzungsaffinität
  • Keine (NONE)
  • Client-IP (CLIENT_IP)
  • Generiertes Cookie (GENERATED_COOKIE)
  • Header-Feld (HEADER_FIELD)
  • HTTP-Cookie (HTTP_COOKIE)
  • Zustandsorientierte cookiebasierte Affinität (STRONG_COOKIE_AFFINITY)

Beachten Sie außerdem Folgendes:

  • Der effektive Standardwert der Load-Balancing-Ort-Richtlinie (localityLbPolicy) ändert sich entsprechend den Einstellungen für die Sitzungsaffinität. Wenn die Sitzungsaffinität nicht konfiguriert ist, d. h., wenn sie auf dem Standardwert NONE bleibt, ist der Standardwert für localityLbPolicy ROUND_ROBIN. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist der Standardwert für localityLbPolicy MAGLEV.
  • Konfigurieren Sie keine Sitzungsaffinität für den internen Application Load Balancer, wenn Sie die gewichtete Trafficaufteilung verwenden. In diesem Fall hat die Konfiguration der gewichteten Trafficaufteilung Vorrang.

Beachten Sie beim Konfigurieren der Sitzungsaffinität Folgendes:

  • Verlassen Sie sich bei Authentifizierungs- oder Sicherheitsthemen nicht auf die Sitzungsaffinität. Die Sitzungsaffinität, mit Ausnahme der zustandsorientierten cookiebasierten Sitzungsaffinität, kann unterbrochen werden, wenn sich die Anzahl der bereitstellenden und fehlerfreien Backends ändert. Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

  • Die Standardwerte der Flags --session-affinity und --subsetting-policy sind beide NONE und können jeweils nur auf einen anderen Wert festgelegt werden.

Arten der Sitzungsaffinität

Die Sitzungsaffinität für interne Application Load Balancer kann in eine der folgenden Kategorien eingeteilt werden:
  • Hashbasierte Sitzungsaffinität (NONE, CLIENT_IP)
  • Header-basierte HTTP-Sitzungsaffinität (HEADER_FIELD)
  • Cookiebasierte Sitzungsaffinität (GENERATED_COOKIE, HTTP_COOKIE, STRONG_COOKIE_AFFINITY)

Hash-basierte Sitzungsaffinität

Bei der hashbasierten Sitzungsaffinität verwendet der Load-Balancer den Algorithmus für konsistentes Hashing, um ein geeignetes Backend auszuwählen. Mit der Einstellung für die Sitzungsaffinität wird festgelegt, welche Felder aus dem IP-Header zum Berechnen des Hash verwendet werden.

Die hashbasierte Sitzungsaffinität kann die folgenden Typen haben:

Keine

Eine Einstellung für die Sitzungsaffinität von NONE bedeutet nicht, dass es keine Sitzungsaffinität gibt. Das bedeutet, dass keine Option für die Sitzungsaffinität explizit konfiguriert ist.

Hashing wird immer zur Auswahl eines Backends verwendet. Bei einer Einstellung für die Sitzungsaffinität von NONE verwendet der Load-Balancer einen 5-Tupel-Hash, um ein Backend auszuwählen. Der 5-Tupel-Hash besteht aus der Quell-IP-Adresse, dem Quellport, dem Protokoll, der Ziel-IP-Adresse und dem Zielport.

Der Standardwert für die Sitzungsaffinität ist NONE.

Client-IP-Affinität

Die Client-IP-Sitzungsaffinität (CLIENT_IP) ist ein 2-Tupel-Hash, der aus der Quell- und Ziel-IP-Adresse des Pakets erstellt wird. Mit der Client-IP-Affinität werden alle Anfragen von derselben Client-IP-Adresse an dasselbe Backend weitergeleitet, sofern dieses Backend Kapazität hat und fehlerfrei ist.

Beachten Sie bei der Verwendung der Client-IP-Affinität Folgendes:

  • Die Ziel-IP-Adresse des Pakets ist nur dann mit der IP-Adresse der Weiterleitungsregel des Load-Balancers identisch, wenn das Paket direkt an den Load-Balancer gesendet wird.
  • Die Quell-IP-Adresse des Pakets stimmt möglicherweise nicht mit einer IP-Adresse überein, die dem ursprünglichen Client zugeordnet ist, wenn das Paket von einem zwischengeschalteten NAT- oder Proxysystem verarbeitet wird, bevor es an einen Trusted Cloud Load-Balancer gesendet wird. In Situationen, in denen viele Clients dieselbe effektive Quell-IP-Adresse verwenden, erhalten einige Back-End-VMs möglicherweise mehr Verbindungen oder Anfragen als andere.

Header-basierte HTTP-Sitzungsaffinität

Bei der Header-Feld-Affinität (HEADER_FIELD) werden Anfragen basierend auf dem Wert des HTTP-Headers im Feld consistentHash.httpHeaderName des Backend-Dienstes an die Backends weitergeleitet. Damit Anfragen auf alle verfügbaren Backends verteilt werden, muss jeder Client einen anderen HTTP-Headerwert verwenden.

Die Header-Feld-Affinität wird unterstützt, wenn die folgenden Bedingungen erfüllt sind:

  • Die Load-Balancing-Lokalitätsrichtlinie ist RING_HASH oder MAGLEV.
  • Der Backend-Dienst consistentHash gibt den Namen des HTTP-Headers (httpHeaderName) an.

Die Cookie-basierte Sitzungsaffinität kann folgende Typen haben:

Wenn Sie die Cookie-Affinität (GENERATED_COOKIE) verwenden, fügt der Load-Balancer in der Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Header Set-Cookie ein.

Der Name des generierten Cookies variiert je nach Load-Balancer-Typ.

Produkt Cookiename
Regionsübergreifende interne Application Load Balancer GCILB
Regionale interne Application Load Balancer GCILB

Das Pfadattribut des generierten Cookies ist immer ein Schrägstrich (/). Es gilt also für alle Back-End-Dienste in derselben URL-Zuordnung, sofern die anderen Back-End-Dienste auch die Cookie-Affinität verwenden.

Sie können den TTL-Wert (Time to Live) des Cookies mit dem Backend-Dienstparameter affinityCookieTtlSec auf einen Wert zwischen 0 und 1,209,600 Sekunden (einschließlich) festlegen. Wenn affinityCookieTtlSec nicht angegeben ist, beträgt der Standard-TTL-Wert 0.

Wenn der Client das generierte Cookie der Sitzungsaffinität im Cookie-Anfrageheader von HTTP-Anfragen einschließt, leitet der Load Balancer diese Anfragen an dieselbe Back-End-Instanz oder denselben Back-End-Endpunkt weiter, solange das Cookie der Sitzungsaffinität gültig bleibt. Dazu wird der Cookie-Wert einem Index zugeordnet, der auf eine bestimmte Backend-Instanz oder einen Endpunkt verweist. Außerdem wird darauf geachtet, dass die Anforderungen an die Sitzungsaffinität des generierten Cookies erfüllt werden.

Wenn Sie die generierte Cookie-Affinität verwenden möchten, konfigurieren Sie den folgenden Load-Balancing-Modus und die folgenden localityLbPolicy-Einstellungen:

  • Verwenden Sie für Back-End-Instanzgruppen den Balancing-Modus RATE.
  • Verwenden Sie für die localityLbPolicy des Back-End-Dienstes entweder RING_HASH oder MAGLEV. Wenn Sie localityLbPolicy nicht explizit festlegen, verwendet das Load Balancer-Modul MAGLEV als impliziten Standardwert.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Wenn Sie die Cookie-basierte HTTP-Affinität (HTTP_COOKIE) verwenden, fügt der Load-Balancer in der Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Set-Cookie-Header ein. Sie geben den Namen, den Pfad und die Gültigkeitsdauer (Time to Live, TTL) für das Cookie an.

Alle Application Load Balancer unterstützen die cookiebasierte HTTP-Affinität.

Sie können die TTL-Werte des Cookies mit Sekunden, Bruchteilen einer Sekunde (als Nanosekunden) oder beidem (Sekunden plus Bruchteile einer Sekunde als Nanosekunden) konfigurieren. Verwenden Sie dazu die folgenden Parameter und gültigen Werte für den Backend-Dienst:

  • consistentHash.httpCookie.ttl.seconds kann auf einen Wert zwischen 0 und 315576000000 (einschließlich) festgelegt werden.
  • consistentHash.httpCookie.ttl.nanos kann auf einen Wert zwischen 0 und 999999999 (einschließlich) festgelegt werden. Da die Einheiten Nanosekunden sind, bedeutet 999999999 .999999999 Sekunden.

Wenn weder consistentHash.httpCookie.ttl.seconds noch consistentHash.httpCookie.ttl.nanos angegeben sind, wird stattdessen der Wert des Backend-Dienstparameters affinityCookieTtlSec verwendet. Wenn affinityCookieTtlSec nicht angegeben ist, beträgt der Standard-TTL-Wert 0.

Wenn der Client das HTTP-Cookie der Sitzungsaffinität im Cookie-Anfrageheader von HTTP-Anfragen einschließt, leitet der Load Balancer diese Anfragen an dieselbe Back-End-Instanz oder denselben Back-End-Endpunkt weiter, solange das Sitzungsaffinitäts-Cookie gültig bleibt. Dazu wird der Cookie-Wert einem Index zugeordnet, der auf eine bestimmte Backend-Instanz oder einen Endpunkt verweist. Außerdem wird darauf geachtet, dass die Anforderungen an die Sitzungsaffinität des generierten Cookies erfüllt werden.

Wenn Sie die HTTP-Cookie-Affinität verwenden möchten, konfigurieren Sie den folgenden Balancing-Modus und die folgenden localityLbPolicy-Einstellungen:

  • Verwenden Sie für Back-End-Instanzgruppen den Balancing-Modus RATE.
  • Verwenden Sie für die localityLbPolicy des Back-End-Dienstes entweder RING_HASH oder MAGLEV. Wenn Sie localityLbPolicy nicht explizit festlegen, verwendet das Load Balancer-Modul MAGLEV als impliziten Standardwert.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Zustandsorientierte Cookie-basierte Sitzungsaffinität

Wenn Sie die zustandsorientierte cookiebasierte Affinität (STRONG_COOKIE_AFFINITY) verwenden, fügt der Load-Balancer in der Antwort auf die erste HTTP-Anfrage ein HTTP-Cookie in den Set-Cookie-Header ein. Sie geben den Namen, den Pfad und die Gültigkeitsdauer (TTL) für das Cookie an.

Die folgenden Load-Balancer unterstützen die zustandsorientierte cookiebasierte Affinität:

  • Regionale externe Application Load Balancer
  • Regionale interne Application Load Balancer

Sie können die TTL-Werte des Cookies in Sekunden, Sekundenbruchteilen (als Nanosekunden) oder beidem (Sekunden plus Sekundenbruchteile als Nanosekunden) konfigurieren. Die durch strongSessionAffinityCookie.ttl dargestellte Dauer darf nicht auf einen Wert festgelegt werden, der mehr als zwei Wochen (1.209.600 Sekunden) entspricht.

Der Wert des Cookies identifiziert eine ausgewählte Backend-Instanz oder einen ausgewählten Endpunkt, indem die ausgewählte Instanz oder der ausgewählte Endpunkt im Wert selbst codiert wird. Solange das Cookie gültig ist, leitet der Load Balancer Anfragen an die ausgewählte Back-End-Instanz oder den ausgewählten Back-End-Endpunkt weiter, wenn der Client das Cookie der Sitzungsaffinität im Cookie-Anfrageheader nachfolgender HTTP-Anfragen einschließt.

Im Gegensatz zu anderen Methoden für die Sitzungsaffinität gilt Folgendes:

  • Für die zustandsorientierte cookiebasierte Affinität gibt es keine besonderen Anforderungen an den Balancing-Modus oder die Load-Balancing-Richtlinie für den Ort (localityLbPolicy).

  • Die zustandsorientierte Cookie-basierte Affinität ist nicht betroffen, wenn beim Autoscaling einer verwalteten Instanzgruppe eine neue Instanz hinzugefügt wird.

  • Die zustandsorientierte Cookie-basierte Affinität ist nicht betroffen, wenn durch Autoscaling eine Instanz aus einer verwalteten Instanzgruppe entfernt wird, es sei denn die ausgewählte Instanz wird entfernt.

  • Die zustandsorientierte Cookie-basierte Affinität ist nicht betroffen, wenn durch die automatische Reparatur eine Instanz aus einer verwalteten Instanzgruppe entfernt wird, es sei denn, die ausgewählte Instanz wird entfernt.

Weitere Informationen finden Sie unter Verlust der Sitzungsaffinität.

Bedeutung von „0“ als TTL für Cookie-basierte Affinitäten

Alle cookiebasierten Sitzungsaffinitäten, z. B. generierte Cookie-Affinität, HTTP-Cookie-Affinität und zustandsorientierte Cookie-Affinität, haben ein TTL-Attribut.

Eine TTL von null Sekunden bedeutet, dass der Load-Balancer dem Cookie kein Expires-Attribut zuweist. In diesem Fall behandelt der Client das Cookie als Sitzungscookie. Die Definition einer Sitzung variiert je nach Client:

  • Einige Clients, z. B. Webbrowser, behalten das Cookie für die gesamte Browsersitzung bei. Das bedeutet, dass das Cookie über mehrere Anfragen hinweg bestehen bleibt, bis die Anwendung geschlossen wird.

  • Andere Clients behandeln eine Sitzung als einzelne HTTP-Anfrage und verwerfen das Cookie sofort danach.

Verlust der Sitzungsaffinität

Für alle Optionen für die Sitzungsaffinität ist Folgendes erforderlich:

  • Die ausgewählte Backend-Instanz oder der ausgewählte Endpunkt muss als Backend konfiguriert bleiben. Die Sitzungsaffinität kann unterbrochen werden, wenn eines der folgenden Ereignisse eintritt:
    • Sie entfernen die ausgewählte Instanz aus ihrer Instanzgruppe.
    • Beim Autoscaling oder der automatischen Reparatur einer verwalteten Instanzgruppe wird die ausgewählte Instanz aus der verwalteten Instanzgruppe entfernt.
    • Sie entfernen den ausgewählten Endpunkt aus seiner NEG.
    • Sie entfernen die Instanzgruppe oder NEG, die die ausgewählte Instanz oder den ausgewählten Endpunkt enthält, aus dem Backend-Dienst.
  • Die ausgewählte Back-End-Instanz oder der ausgewählte Endpunkt muss fehlerfrei bleiben. Die Sitzungsaffinität kann aufgehoben sein, wenn die ausgewählte Instanz oder der ausgewählte Endpunkt die Systemdiagnosen nicht besteht.
Mit Ausnahme der zustandsorientierten cookiebasierten Sitzungsaffinität gelten für alle Optionen für die Sitzungsaffinität die folgenden zusätzlichen Anforderungen:

  • Die Instanzgruppe oder NEG, die die ausgewählte Instanz oder den ausgewählten Endpunkt enthält, darf nicht voll sein, wie durch die Zielkapazität definiert. Bei regional verwalteten Instanzgruppen darf die zonale Komponente der Instanzgruppe, die die ausgewählte Instanz enthält, nicht voll sein. Die Sitzungsaffinität kann unterbrochen werden, wenn die Instanzgruppe oder das NEG voll ist und andere Instanzgruppen oder NEGs nicht. Da sich die Füllmenge bei Verwendung des Balancing-Modus UTILIZATION unvorhersehbar ändern kann, sollten Sie den Balancing-Modus RATE oder CONNECTION verwenden, um Situationen zu minimieren, in denen die Sitzungsaffinität unterbrochen werden kann.

  • Die Gesamtzahl der konfigurierten Back-End-Instanzen oder ‑Endpunkte muss konstant bleiben. Wenn mindestens eines der folgenden Ereignisse eintritt, ändert sich die Anzahl der konfigurierten Back-End-Instanzen oder Endpunkte und die Sitzungsaffinität kann unterbrochen werden:

    • Neue Instanzen oder Endpunkte hinzufügen:

      • Sie fügen einem vorhandenen Backend-Dienst Instanzen hinzu.
      • Beim Autoscaling für verwaltete Instanzgruppen werden dem Back-End-Dienst Instanzen einer verwalteten Instanzgruppe hinzugefügt.
      • Sie fügen einem vorhandenen Backend-Dienst Endpunkte hinzu.
      • Sie fügen dem Backend-Dienst nicht leere Instanzgruppen oder NEGs hinzu.

    • Wenn Sie eine Instanz oder einen Endpunkt entfernen, nicht nur die ausgewählte Instanz oder den ausgewählten Endpunkt:

      • Sie entfernen eine Instanz aus einem Instanzgruppen-Backend.
      • Beim Autoscaling oder der automatischen Reparatur von verwalteten Instanzgruppen wird jede Instanz aus einem Backend mit verwalteten Instanzgruppen entfernt.
      • Sie entfernen einen Endpunkt aus einem NEG-Backend.
      • Sie entfernen alle vorhandenen, nicht leeren Backend-Instanzgruppen oder NEGs aus dem Backend-Dienst.

  • Die Gesamtzahl der fehlerfreien Backend-Instanzen oder ‑Endpunkte muss konstant bleiben. Wenn mindestens eines der folgenden Ereignisse eintritt, ändert sich die Anzahl der fehlerfreien Back-End-Instanzen oder ‑Endpunkte und die Sitzungsaffinität kann unterbrochen werden:

    • Eine Instanz oder ein Endpunkt besteht die Systemdiagnose und wechselt vom Status „Fehlerhaft“ zu „Fehlerfrei“.
    • Eine Instanz oder ein Endpunkt besteht die Systemdiagnose nicht und wechselt vom Status „Fehlerfrei“ zu „Fehlerhaft“ oder „Zeitüberschreitung“.

Failover

Wenn ein Backend fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Backends weitergeleitet.

In der folgenden Tabelle wird das Failover-Verhalten in den einzelnen Modi beschrieben:

Load-Balancer-Modus Failover-Verhalten Verhalten, wenn alle Back-Ends fehlerhaft sind
Regionaler interner Application Load Balancer

Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.

Der Envoy-Proxy sendet Traffic an fehlerfreie Backends in einer Region anhand der konfigurierten Trafficverteilung.

 Gibt HTTP 503 zurück

Hochverfügbarkeit und regionsübergreifender Failover

Für regionale interne Application Load Balancer

Um Hochverfügbarkeit zu erreichen, stellen Sie mehrere einzelne regionale interne Application Load Balancer in Regionen bereit, die den Traffic Ihrer Anwendung am besten unterstützen. Anschließend verwenden Sie eine Cloud DNS-Standortbestimmung-Routingrichtlinie, um zu erkennen, ob ein Load Balancer während eines regionalen Ausfalls reagiert. Eine Standortbestimmung-Richtlinie leitet Traffic basierend auf dem Ursprung der Clientanfrage an die nächstgelegene verfügbare Region weiter. Systemdiagnosen sind standardmäßig für interne Application Load Balancer verfügbar.

WebSocket-Unterstützung

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

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

Das WebSocket-Protokoll funktioniert so:

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

Wenn die Back-End-Instanz den Statuscode 426 oder 502 zurückgibt, schließt der Load-Balancer die Verbindung.

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

HTTP/2-Unterstützung

HTTP/2 ist eine wesentliche Überarbeitung des HTTP/1-Protokolls. Es gibt zwei Modi für die HTTP/2-Unterstützung:

  • HTTP/2 über TLS
  • HTTP/2-Klartext über TCP

HTTP/2 über TLS

HTTP/2 über TLS wird für Verbindungen zwischen Clients und dem externen Application Load Balancer sowie für Verbindungen zwischen dem Load Balancer und seinen Backends unterstützt.

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

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

Wenn Sie HTTP/2 über TLS verwenden möchten, müssen Sie TLS auf Ihren Back-Ends aktivieren und das Back-End-Dienstprotokoll auf HTTP2 festlegen. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

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 einemTrusted 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 oder HTTPS. Verbindungs-Pooling, eine Optimierung, die die Anzahl dieser Verbindungen bei HTTP oder HTTPS reduziert, ist bei HTTP/2 nicht möglich. Dies kann zu hohen Backend-Latenzen führen, da Backend-Verbindungen häufiger hergestellt werden.
  • HTTP/2 zwischen dem Load Balancer und dem Back-End unterstützt nicht das Ausführen des WebSocket-Protokolls über einen einzelnen Stream einer HTTP/2-Verbindung (RFC 8441).
  • HTTP/2 zwischen dem Load-Balancer und dem Back-End unterstützt keinen Server-Push.
  • Die gRPC-Fehlerrate und das Anfragevolumen sind in derTrusted Cloud API oder der Trusted Cloud Console nicht sichtbar. Wenn der gRPC-Endpunkt einen Fehler zurückgibt, melden die Load-Balancer-Logs und die Monitoring-Daten den HTTP-Statuscode 200 OK.

HTTP/2-Klartext über TCP (H2C)

Mit Cleartext HTTP/2 über TCP, auch als H2C bezeichnet, können Sie HTTP/2 ohne TLS verwenden. H2C wird für beide der folgenden Verbindungen unterstützt:

  • Verbindungen zwischen Clients und dem Load-Balancer. Es ist keine spezielle Konfiguration erforderlich.

  • Verbindungen zwischen dem Load-Balancer und seinen Back-Ends.

    Wenn Sie H2C für Verbindungen zwischen dem Load Balancer und seinen Backends konfigurieren möchten, legen Sie das Backend-Dienstprotokoll auf H2C fest.

H2C-Unterstützung ist auch für Load Balancer verfügbar, die mit dem GKE-Gateway-Controller und Cloud Service Mesh erstellt wurden.

H2C wird für klassische Application Load Balancer nicht unterstützt.

gRPC-Unterstützung

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

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

Um gRPC mit Ihren Trusted Cloud -Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. Dazu erstellen Sie einen Application Load Balancer mit einer der folgenden Konfigurationen:

  • Für unverschlüsselten End-to-End-Traffic (ohne TLS): Sie erstellen einen HTTP-Load-Balancer (der mit einem HTTP-Zielproxy konfiguriert ist). Außerdem konfigurieren Sie den Load-Balancer so, dass er HTTP/2 für unverschlüsselte Verbindungen zwischen dem Load-Balancer und seinen Back-Ends verwendet, indem Sie das Protokoll des Back-End-Dienstes auf H2C festlegen.

  • Für End-to-End-verschlüsselten Traffic (mit TLS): Sie erstellen einen HTTPS-Load-Balancer (konfiguriert mit einem HTTPS-Zielproxy und einem SSL-Zertifikat). Der Load Balancer handelt im Rahmen des SSL-Handshakes HTTP/2 mit Clients aus und verwendet dazu die ALPN TLS-Erweiterung.

    Außerdem müssen Sie dafür sorgen, dass die Back-Ends TLS-Traffic verarbeiten können, und den Load-Balancer so konfigurieren, dass er HTTP/2 für verschlüsselte Verbindungen zwischen dem Load-Balancer und seinen Back-Ends verwendet. Dazu müssen Sie das Back-End-Dienstprotokoll auf HTTP2 festlegen.

    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 Load-Balancer transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

TLS-Support

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

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

Unterstützung von gegenseitigem TLS

Gegenseitiges TLS (Mutual TLS, mTLS) ist ein Branchenstandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. mTLS trägt dazu bei, dass sowohl der Client als auch der Server sich gegenseitig authentifizieren, indem sie überprüfen, ob jeder ein gültiges Zertifikat besitzt, das von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, erfordert mTLS, dass sowohl der Client als auch der Server Zertifikate präsentieren, um die Identitäten beider Parteien zu bestätigen, bevor eine Kommunikation hergestellt wird.

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

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

Beschränkungen

  • Es kann nicht garantiert werden, dass eine Anfrage von einem Client in einer Zone der Region an ein Backend gesendet wird, das sich in derselben Zone wie der Client befindet. Die Sitzungsaffinität reduziert nicht die Kommunikation zwischen Zonen.

  • Interne Application Load Balancer sind nicht mit den folgenden Features kompatibel:

  • Wenn Sie Certificate Manager-Zertifikate mit internen Application Load Balancern verwenden möchten, müssen Sie entweder die API oder die gcloud CLI verwenden. DieTrusted Cloud -Konsole unterstützt keine Certificate Manager-Zertifikate.

  • Ein interner Application Load Balancer unterstützt HTTP/2 nur über TLS.

  • Clients, die eine Verbindung zu einem internen Application Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. HTTP 1.0 wird nicht unterstützt.

  • Trusted Cloud gibt keine Warnung aus, wenn das Nur-Proxy-Subnetz keine IP-Adressen mehr hat.

  • Die interne Weiterleitungsregel, die Ihr interner Application Load Balancer verwendet, muss genau einen Port haben.

  • Wenn Sie einen internen 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 einem anderen Dienstprojekte in derselben freigegebenen VPC-Umgebung bereitgestellt werden. Dieses Problem ist bekannt.

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

Nächste Schritte