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 vonGoogle Cloud – 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 globalen externen Application Load Balancern

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

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

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

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

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

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

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

Verbindungen bei regionalen externen Application Load Balancern

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

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

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

Clientkommunikation mit dem Load-Balancer

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

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

Quell-IP-Adressen für Clientpakete

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

Für globale externe Application Load Balancer:

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

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

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

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

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

Für die regionalen externen Application Load Balancer:

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

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter 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

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

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

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

• Bei Verwendung verteilter Envoy-Systemdiagnosen.

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

Offene Ports

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

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

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

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

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

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

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

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

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

TLS-Terminierung

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

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

Zeitüberschreitungen und Wiederholungsversuche

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

Zeitlimittyp und Beschreibung	Standardwerte	Unterstützt benutzerdefinierte Zeitüberschreitungswerte
		Global	Klassisch	Regional
Zeitlimit für Backend-Dienst1 Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte 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 Für Backend-Buckets: 24 Stunden (86.400 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 globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der ersten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	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 globalen externen Application Load Balancern und klassischen Application Load Balancern ist der Proxy des Load Balancers ein GFE der zweiten Ebene. Bei regionalen externen Application Load Balancern ist der Proxy des Load Balancers die Envoy-Software.	Für Backend-Dienste: 10 Minuten (600 Sekunden) Für Backend-Buckets: 6 Minuten (360 Sekunden)
Zeitüberschreitung bei Inaktivität für QUIC-Sitzungen Die maximale Zeitspanne, die eine QUIC-Sitzung zwischen dem (nachgelagerten) Client und dem GFE eines globalen externen Application Load Balancers oder eines klassischen Application Load Balancers inaktiv sein kann.	Für globale externe Application Load Balancer und klassische Application Load Balancer: Das Zeitlimit bei Inaktivität für QUIC-Sitzungen ist der Mindestwert für die Zeitüberschreitung bei Inaktivität des Clients oder die Zeitüberschreitung bei Inaktivität des GFE (300 Sekunden). Das Zeitlimit bei Inaktivität für GFE ist auf 300 Sekunden festgelegt. Die Zeitüberschreitung für Inaktivität des Clients kann konfiguriert werden.

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. Google Cloud garantiert auch nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts geöffnet bleibt. Bei globalen und klassischen Application Load Balancers erzwingen GFEs ein effektives maximales Zeitlimit für Backend-Dienste von 86,400 Sekunden (1 Tag). 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
Globaler externer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Aktive WebSocket-Verbindungen verwenden nicht das konfigurierte Zeitlimit für den Backend-Dienst des Load Balancers. Die Verbindungen werden nach 24 Stunden (86.400 Sekunden) automatisch geschlossen. Dieses Limit von 24 Stunden ist fest und überschreibt das Zeitlimit des Backend-Diensts, wenn es mehr als 24 Stunden beträgt. Inaktive WebSocket-Verbindungen werden geschlossen, wenn das Zeitlimit des Backend-Dienstes überschritten wird. Wir empfehlen keine Zeitlimitwerte für Backend-Dienste größer als 24 Stunden (86.400 Sekunden), da Google Cloud GFEs regelmäßig für Softwareupdates und andere routinemäßige Wartungen neu startet. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google CloudTCP-Verbindungen für die Wartung beendet.
Klassischer Application Load Balancer	Zeitlimit für den Back-End-Dienst: 30 Sekunden	Inaktive und aktive Websocket-Verbindungen werden automatisch geschlossen, wenn eine Zeitüberschreitung des Backend-Dienstes auftritt. Wir empfehlen keine Zeitlimitwerte für Backend-Dienste größer als 24 Stunden (86.400 Sekunden), da Google Cloud GFEs regelmäßig für Softwareupdates und andere routinemäßige Wartungen neu startet. Der Wert für das Zeitlimit des Backend-Diensts verzögert keine Wartungsaktivitäten. Je länger der Wert des Zeitlimits des Backend-Diensts ist, desto wahrscheinlicher ist es, dass Google CloudTCP-Verbindungen für die Wartung beendet.
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. Google Cloud startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgaben neu gestartet oder beendet werden.

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

Client-HTTP-Keepalive-Zeitlimit

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

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

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

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

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

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

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

Zeitlimit bei inaktiver QUIC-Sitzung

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

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

Wiederholungsversuche

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

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

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

Ungültige Verarbeitung von Anfragen und Antworten

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

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

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

Anfragen verarbeiten

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

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

Antwortverarbeitung

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

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

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

Traffic-Verteilung

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

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

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

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

Globaler externer Application Load Balancer

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

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

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

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

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

Anfrageverteilung

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

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

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

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

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

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

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

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

Regionaler externer Application Load Balancer

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

Der Balancing-Modus bestimmt die Gewichtung und den Anteil des Traffics, der an jede Gruppe (Instanzgruppe oder NEG) gesendet 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
Globaler externer Application Load Balancer 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. Konfigurieren Sie keine Sitzungsaffinität für den globalen externen Application Load Balancer, wenn Sie die gewichtete Trafficaufteilung verwenden. In diesem Fall hat die Konfiguration der gewichteten Trafficaufteilung Vorrang.
Klassischer Application Load Balancer	Keine (NONE) Client-IP (CLIENT_IP) Generiertes Cookie (GENERATED_COOKIE)

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 die folgenden 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 Google 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.

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.

Alle Application Load Balancer, mit Ausnahme von klassischen Application Load Balancern, unterstützen zustandsbehaftete Cookie-basierte Affinität.

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