Anfrageverteilung für externe Application Load Balancer

In diesem Dokument wird ausführlich beschrieben, wie externe Application Load Balancer Verbindungen verarbeiten, Traffic weiterleiten und die Sitzungsaffinität aufrechterhalten.

So funktionieren Verbindungen

Die externen Application Load Balancer vonCloud de Confiance – global und regional – optimieren das Routing mithilfe von verteilten Proxys (GFEs) oder von Envoy verwalteten Subnetzen. Mit konfigurierbaren Zeitüberschreitungen, TLS-Terminierung und integrierter Sicherheit sorgen sie für die konforme, skalierbare Anwendungsbereitstellung weltweit oder regional.

Verbindungen bei regionalen externen Application Load Balancern

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

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

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

Clientkommunikation mit dem Load-Balancer

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

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

Quell-IP-Adressen für Clientpakete

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

Für die regionalen externen Application Load Balancer:

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

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

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

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

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

Spezielle Routingpfade

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

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

Cloud de Confiance verwendet Subnetzrouten für Nur-Proxy-Subnetze, um Pakete für die folgenden Traffictypen weiterzuleiten:

• Bei Verwendung verteilter Envoy-Systemdiagnosen.

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

TLS-Terminierung

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

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

Zeitüberschreitungen und Wiederholungsversuche

Externe Application Load Balancer unterstützen die folgenden Arten von Zeitüberschreitungen für HTTP- oder HTTPS-Traffic:

Zeitlimittyp und Beschreibung	Standardwerte	Unterstützt benutzerdefinierte Zeitüberschreitungswerte
		Zeitlimit für Backend-Dienst1 Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte 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 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 Proxy des Load Balancers inaktiv sein kann. Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	610 Sekunden
HTTP-Keepalive-Zeitlimit des Back-Ends Die maximale Zeitspanne, die die TCP-Verbindung zwischen dem Proxy des Load Balancers und einem Backend inaktiv sein kann. Dieselbe TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für Backend-Dienste: 10 Minuten (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. Wenn Sie beispielsweise HTTP-Antworten mit dem Statuscode 408 und jsonPayload.statusDetail client_timed_out-Fehlern sehen, empfehlen wir, das Zeitlimit 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. Cloud de Confiance 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.

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

Zeitüberschreitungen bei WebSocket-Verbindungen sind nicht immer mit Zeitüberschreitungen bei Backend-Diensten identisch. Zeitüberschreitungen für WebSocket-Verbindungen hängen vom Typ des Load Balancers ab:

Load-Balancer-Modus	Standardwerte	Beschreibung des Zeitlimits für WebSockets
Regionaler externer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Aktive WebSocket-Verbindungen verwenden nicht die Zeitüberschreitung des Backend-Dienstes des Load Balancers. Inaktive WebSocket-Verbindungen werden geschlossen, wenn das Zeitlimit des Backend-Dienstes überschritten wird. Cloud de Confiance startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgaben neu gestartet oder beendet werden.

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

Client-HTTP-Keepalive-Zeitlimit

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

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

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

Der Standardwert für das HTTP-Keepalive-Zeitlimit des Clients beträgt 610 Sekunden. Bei globalen und regionalen externen Application Load Balancern können Sie das Client-HTTP-Keepalive-Zeitlimit mit einem Wert zwischen 5 und 1.200 Sekunden konfigurieren.

Verwenden Sie eine der folgenden Methoden, um das HTTP-Keepalive-Zeitlimit des Clients zu konfigurieren:

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

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

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

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

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. 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

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

Load-Balancer-Modus

Wiederholungslogik

Regionaler externer Application Load Balancer

Über eine Wiederholungsrichtlinie in der URL-Zuordnung konfigurierbar. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Die maximale Anzahl von Wiederholungsversuchen, die mit der Wiederholungsrichtlinie konfiguriert werden kann, beträgt 25. Der maximal konfigurierbare Wert für perTryTimeout ist 24 Stunden. Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

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

Ungültige Verarbeitung von Anfragen und Antworten

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

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

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

Anfragen verarbeiten

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

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

Antwortverarbeitung

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

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

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

Traffic-Verteilung

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

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

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

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

Regionaler externer Application Load Balancer

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

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

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

Hier finden Sie weitere Informationen:

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

Sitzungsaffinität

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

Regionaler externer Application Load Balancer

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.

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 Back-Ends ä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 externe 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 folgende Typen haben:

• Keine
• Client-IP-Affinität

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 Cloud de Confiance 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.

Cookiebasierte Sitzungsaffinität

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

• Generierte Cookie-Affinität
• HTTP-Cookie-Affinität
• Zustandsorientierte cookiebasierte Sitzungsaffinität

Generierte Cookie-Affinität

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
Globale externe Application Load Balancer	GCLB
Klassische Application Load Balancer	GCLB
Regionale externe 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 sind.

Wenn Sie die generierte Cookie-Affinität verwenden möchten, konfigurieren Sie den folgenden Load-Balancing-Modus und die 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.

HTTP-Cookie-Affinitä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, entspricht 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 sind.

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 zustandsbehaftete 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 sind folgende Voraussetzungen 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.
• Bei globalen externen Application Load Balancern und Classic Application Load Balancern kann die Sitzungsaffinität unterbrochen werden, wenn nach der Änderung des Routingpfads ein anderes Google Front End (GFE) der ersten Ebene für nachfolgende Anfragen oder Verbindungen verwendet wird. Wenn sich der Routingpfad von einem Client im Internet zu Google zwischen Anfragen oder Verbindungen ändert, wird möglicherweise ein anderes GFE der ersten Ebene ausgewählt.

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