Grundlegendes zu Back-End-Diensten

Ein Back-End-Dienst ist eine Ressource mit Feldern, die Konfigurationswerte für die folgenden Load-Balancing-Dienste von Google Cloud enthalten:

  • Externes HTTP(S)-Load-Balancing
  • Internes HTTP(S)-Load-Balancing
  • SSL-Proxy-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • Internes TCP/UDP-Load-Balancing

Netzwerk-Load-Balancing verwendet keinen Back-End-Dienst.

Die Load-Balancer verwenden die Konfigurationsinformationen in der Back-End-Dienstressource für die folgenden Funktionen:

  • Um Traffic an die richtigen Back-Ends weiterzuleiten, die Instanzgruppen oder Netzwerk-Endpunktgruppen sind.
  • Zum Verteilen des Traffic nach einem Balancing-Modus. Der Balancing-Modus wird im Back-End-Dienst für jedes Back-End einzeln definiert.
  • Zur Überwachung des Back-End-Zustands mithilfe der im Back-End-Dienst festgelegten Systemdiagnose
  • Zur Aufrechterhaltung der Sitzungsaffinität.

Architektur

Die Anzahl der Back-End-Dienste pro Load-Balancer hängt vom Typ des jeweiligen Load-Balancers ab:

Load-Balancer-Typ Anzahl der Back-End-Dienste
Externes HTTP(S)-Load-Balancing Mehrere
Internes HTTP(S)-Load-Balancing Mehrere
SSL-Proxy-Load-Balancing 1
TCP-Proxy-Load-Balancing 1
Internes TCP/UDP-Load-Balancing 1

Jeder Back-End-Dienst enthält ein oder mehrere Back-Ends.

Für einen bestimmten Back-End-Dienst müssen alle Back-Ends entweder Instanzgruppen oder Netzwerk-Endpunktgruppen sein. Sie können einem Back-End-Dienst verschiedene Arten von Instanzgruppen, z. B. verwaltete und nicht verwaltete, zuordnen. Dagegen lassen sich einem Back-End-Dienst nicht Instanzgruppen und Netzwerk-Endpunktgruppen gleichzeitig zuweisen.

Einstellungen für Back-End-Dienste

Für jeden Back-End-Dienst gelten die folgenden konfigurierbaren Einstellungen:

  • Sitzungsaffinität (optional). Normalerweise verwenden Load-Balancer einen Hash-Algorithmus zur Verteilung von Anfragen unter den verfügbaren Instanzen. Im Normalfall basiert der Hash auf der Quell-IP-Adresse, der Ziel-IP-Adresse, dem Quellport, dem Zielport und dem Protokoll (ein 5-Tupel-Hash). Die Sitzungsaffinität wird an den Inhalt des Hash angepasst und es wird versucht, alle Anfragen von einem Client an eine bestimmte Instanz der virtuellen Maschine zu senden.
  • Zeitlimit für den Back-End-Dienst. Dieser Wert wird je nach Typ des verwendeten Load-Balancers und des verwendeten Protokolls unterschiedlich interpretiert:
    • Bei einem HTTP(S)-Load-Balancer ist das Zeitlimit für den Back-End-Dienst ein Anfrage-/Antwort-Zeitlimit, außer für Verbindungen, die auf die Verwendung des WebSocket-Protokolls aktualisiert wurden.
    • Beim Senden von WebSocket-Traffic an einen HTTP(S)-Load-Balancer wird das Zeitlimit für den Back-End-Dienst als die maximale Zeit verstanden, die ein WebSocket – im Leerlauf oder aktiv – geöffnet sein kann.
    • Bei einem SSL-Proxy- oder TCP-Proxy-Load-Balancer wird das Zeitlimit des Back-End-Dienstes als Leerlaufzeitlimit für den gesamten Traffic interpretiert.
    • Bei einem internen TCP/UDP-Load-Balancer wird der Zeitlimitparameter des Back-End-Dienstes ignoriert.
  • Systemdiagnose. Die Systemdiagnose fragt Instanzen, die mit dem Back-End-Dienst verbunden sind, in festgelegten Intervallen ab. Instanzen, für die die Systemdiagnose keine Fehler ermittelt, können neue Anfragen erhalten. Fehlerhafte Instanzen erhalten keine Anfragen, bis sie wieder fehlerfrei sind.

In der API-Ressource des Back-End-Dienstes und im Nutzerhandbuch für das gcloud-Befehlszeilentool finden Sie Beschreibungen der Attribute, die für die Nutzung von Back-End-Diensten zur Verfügung stehen.

Back-Ends

Sie können mehrere Back-Ends zu einem einzigen Back-End-Dienst hinzufügen. Jedes Back-End ist eine Ressource, auf die ein Google Cloud-Load-Balancer den Traffic verteilt. Es können drei verschiedene Arten von Ressourcen als Back-Ends verwendet werden:

Für einen bestimmten Back-End-Dienst müssen alle Back-Ends entweder Instanzgruppen oder, falls unterstützt, NEGs oder Back-End-Buckets sein. Sie können nicht verschiedene Arten von Back-Ends mit demselben Back-End-Dienst verwenden. Außerdem:

  • Back-Ends für interne TCP/UDP-Load-Balancer unterstützen nur Instanzgruppen-Back-Ends.
  • Wenn ein HTTP(S)-Load-Balancer zwei (oder mehr) Back-End-Dienste hat, können Sie Instanzgruppen als Back-Ends für einen Back-End-Dienst und NEGs als Back-Ends für den anderen Back-End-Dienst verwenden.

Back-Ends und externe IP-Adressen

Die Back-End-VMs benötigen keine externen IP-Adressen.

  • Für HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer: Clients kommunizieren mit einem Google-Front-End (GFE) über die externe IP-Adresse Ihres Load-Balancers. Das GFE kommuniziert mit Back-End-VMs über die internen IP-Adressen ihrer primären Netzwerkschnittstelle. Da das GFE ein Proxy ist, benötigen die Back-End-VMs selbst keine externen IP-Adressen.

  • Für Netzwerk-Load-Balancer: Netzwerk-Load-Balancer leiten Pakete mithilfe der bidirektionalen Network Address Translation (NAT) weiter. Wenn Back-End-VMs Antworten an Clients senden, verwenden sie die externe IP-Adresse der Weiterleitungsregel des Load-Balancers als Quell-IP-Adresse.

  • Für interne Load-Balancer: Back-End-VMs für einen internen Load-Balancer benötigen keine externen IP-Adressen.

Trafficverteilung

Die Werte der folgenden Felder in der Ressource für Back-End-Dienste beeinflussen verschiedene Aspekte des Back-End-Verhaltens:

  • Balancing-Modus: Der Modus für das Load-Balancing-System, mit dem ermittelt wird, wann das Back-End komplett ausgelastet ist. Wenn alle Back-Ends für den Back-End-Dienst in einer Region ausgelastet sind, werden neue Anfragen automatisch an die nächstgelegene Region weitergeleitet, die noch Anfragen verarbeiten kann. Der Balancing-Modus kann auf der Basis von Verbindungen, Back-End-Auslastung oder Anfragen pro Sekunde (Rate) definiert werden.
  • Kapazität: Die Kapazität ist ein weiterer Faktor für die Einstellung des Balancing-Modus. Wenn Sie beispielsweise Ihre Instanzen im Normalfall bei einer Back-End-Auslastung von maximal 80 % ausführen möchten, legen Sie für Ihren Balancing-Modus die Back-End-Auslastung als Kriterium und für die Kapazität 80 % fest. Wenn Sie die Instanzauslastung halbieren möchten, können Sie die Kapazität bei 80 % Back-End-Auslastung belassen und den Kapazitätsskalierer auf 0,5 einstellen. Um den Back-End-Dienst zu entlasten, setzen Sie den Kapazitätsskalierer auf 0 und belassen Sie die Kapazität so, wie sie ist. Weitere Informationen zur Kapazität und Back-End-Auslastung erhalten Sie unter Anhand von CPU oder Load-Balancing-Bereitstellungskapazität skalieren.

Wichtige Hinweise:

  • Wenn die durchschnittliche Auslastung aller Instanzen in Back-End-Instanzgruppen, die mit demselben Back-End-Dienst verbunden sind, weniger als 10 % beträgt, könnte die GCP bestimmte Zonen bevorzugen. Dies kann passieren, wenn Sie verwaltete regionale Instanzgruppen, verwaltete zonale Instanzgruppen und nicht verwaltete zonale Instanzgruppen verwenden. Dieses zonale Ungleichgewicht wird automatisch aufgelöst, wenn mehr Traffic an den Load-Balancer gesendet wird. Die Back-End-Dienste in anderen Regionen haben keinen Einfluss darauf.

Auch Traffic Director verwendet Back-End-Dienst-Ressourcen. Insbesondere nutzt Traffic Director Back-End-Dienste mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED. Für einen internen verwalteten Back-End-Dienst verwendet die Trafficverteilung einen Load-Balancing-Modus und eine Load-Balancing-Richtlinie. Der Back-End-Dienst leitet den Traffic gemäß dem Balancing-Modus des Back-Ends an ein Back-End (Instanzgruppe oder NEG) weiter. Sobald ein Back-End ausgewählt wurde, verteilt Traffic Director den Traffic entsprechend einer Load-Balancing-Richtlinie.

Interne selbstverwaltete Back-End-Dienste unterstützen die folgenden Balancing-Modi:

  • UTILIZATION, wenn alle Back-Ends Instanzgruppen sind
  • RATE, wenn alle Back-Ends entweder Instanzgruppen oder NEGs sind

Wenn Sie den Balancing-Modus RATE auswählen, müssen Sie eine maximale Rate pro Back-End, Instanz oder Endpunkt angeben.

Protokoll für Back-Ends

Beim Erstellen eines Back-End-Dienstes müssen Sie das Protokoll angeben, das für die Kommunikation mit dessen Back-Ends verwendet werden soll. Für einen Back-End-Dienst kann immer nur ein Protokoll genutzt werden. Es ist also nicht möglich, ein sekundäres Protokoll als Fallback festzulegen.

Es sind folgende Protokolle verfügbar:

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

Welches Protokoll jeweils anwendbar ist, hängt vom Typ des von Ihnen erstellten Load-Balancers einschließlich seines Load-Balancing-Schemas ab. Weitere Informationen darüber, welche Protokolle für die Back-End-Dienste eines Load-Balancers verwendet werden können, finden Sie in der Dokumentation zu den einzelnen Load-Balancer-Typen.

Für das Load-Balancing mit Ingress steht auch HTTP/2 als Back-End-Protokoll zur Verfügung.

Durch das Ändern des Protokolls eines Back-End-Dienstes werden die Back-Ends für einige Minuten über Load-Balancer unerreichbar.

Instanzgruppen

Back-End-Dienste und automatisch skalierte verwaltete Instanzgruppen

Automatisch skalierte verwaltete Instanzgruppen sind nützlich, wenn Sie viele Maschinen benötigen, die alle auf die gleiche Weise konfiguriert sind, und Sie je nach Bedarf Instanzen automatisch hinzufügen oder entfernen möchten.

Der Autoscaling-Prozentsatz arbeitet mit dem Back-End-Dienstmodus zusammen. Angenommen, Sie legen für den Balancing-Modus eine Back-End-Auslastung von 80 % fest und belassen den Wert für den Kapazitätsskalierer bei 100 %. Außerdem geben Sie für den Zielwert für Load-Balancing-Nutzung im Autoscaling 80 % an. Wenn die Back-End-Auslastung der Gruppe 64 % (80 % von 80 %) überschreitet, instanziiert das Autoscaling neue Instanzen aus der Vorlage, bis die Auslastung wieder auf etwa 64 % sinkt. Wenn die Gesamtnutzung unter 64 % sinkt, entfernt das Autoscaling Instanzen, bis die Nutzung wieder auf 64 % ansteigt.

Neue Instanzen haben einen Cooldown-Zeitraum, bevor sie als Teil der Gruppe betrachtet werden. Daher kann der Traffic die 80%ige Back-End-Nutzung des Back-End-Dienstes während dieses Zeitraums überschreiten, wodurch überschüssiger Traffic an den nächsten verfügbaren Back-End-Dienst weitergeleitet wird. Sobald die Instanzen verfügbar sind, wird neuer Traffic an sie geleitet. Wenn die Anzahl der Instanzen das von den Autoscaling-Einstellungen zugelassene Maximum erreicht, werden keine Instanzen mehr durch das Autoscaling hinzugefügt, unabhängig von der Nutzung. In diesem Fall wird der zusätzliche Traffic auf die nächste verfügbare Region verteilt.

Automatisch skalierte und verwaltete Instanzgruppen konfigurieren

Zur Konfiguration automatisch skalierter verwalteter Instanzgruppen führen Sie die folgenden Schritte aus:

  1. Erstellen Sie eine Instanzvorlage für Ihre Instanzgruppe.
  2. Erstellen Sie eine verwaltete Instanzgruppe und weisen Sie ihr die Vorlage zu.
  3. Aktivieren Sie das Autoscaling auf der Grundlage der Load-Balancing-Bereitstellungskapazität.

Einschränkungen und Richtlinien für Instanzgruppen

Da das Cloud-Load-Balancing sehr viele Möglichkeiten bei der Konfiguration des Load-Balancers bietet, kann es auch sein, dass manche Konfigurationen zu einem ungünstigen Verhalten führen. Beachten Sie deshalb die folgenden Einschränkungen und Hinweise, wenn Sie Instanzgruppen mit Load-Balancing erstellen.

  • Stellen Sie keine VM-Instanz in mehr als eine Instanzgruppe.
  • Löschen Sie keine Instanzgruppe, wenn sie von einem Back-End verwendet wird.
  • Ihre Konfiguration wird vereinfacht, wenn Sie eine Instanzgruppe nicht zwei unterschiedlichen Back-Ends hinzufügen. Wenn Sie dennoch eine Instanzgruppe für zwei verschiedene Back-Ends verwenden, ist Folgendes zu beachten:
    • Für beide Back-Ends muss der gleiche Balancing-Modus gelten, entweder UTILIZATION oder RATE.
    • Sie können maxRatePerInstance und maxRatePerGroup zusammen verwenden. Es ist auch möglich, für ein Back-End maxRatePerInstance und für das andere maxRatePerGroup festzulegen.
    • Wenn die Instanzgruppe zwei oder mehr Back-End-Ports bedient, müssen Sie die unterschiedlichen Portnamen in der Instanzgruppe angeben.
  • Alle Instanzen in einer verwalteten oder nicht verwalteten Instanzgruppe müssen sich im selben VPN-Netzwerk und gegebenenfalls im selben Subnetz befinden.
  • Wenn Sie eine verwaltete Instanzgruppe mit Autoscaling verwenden, verwenden Sie im Back-End-Dienst nicht den Balancing-Modus maxRate. Sie können entweder den Modus maxUtilization oder maxRatePerInstance verwenden.
  • Eine automatisch skalierte verwaltete Instanzgruppe kann nicht das Ziel von zwei verschiedenen Load-Balancern sein.
  • Wenn die Größe einer verwalteten Instanzgruppe angepasst wird, sollte die maximale Größe der Gruppe nicht die des Subnetzes übersteigen.

Netzwerk-Endpunktgruppen

Ein Netzwerkendpunkt ist eine Kombination aus einer IP-Adresse und einem Port, der auf zwei Arten festgelegt werden kann:

  • Durch Angabe eines Paars IP address:port wie 10.0.1.1:80.
  • Durch Angabe nur einer IP-Adresse für den Netzwerkendpunkt. Der Standardport für die NEG wird automatisch als Port des Paars IP address:port verwendet.

Netzwerkendpunkte stellen Dienste gemäß ihrer IP-Adresse und ihres Ports dar und verweisen nicht auf eine bestimmte VM. Eine Netzwerk-Endpunktgruppe (NEG) ist eine logische Zusammenstellung von Netzwerkendpunkten.

Ein Back-End-Dienst, der Netzwerk-Endpunktgruppen als Back-Ends verwendet, verteilt den Traffic auf Anwendungen oder Container, die innerhalb von VM-Instanzen ausgeführt werden. Weitere Informationen dazu finden Sie unter Netzwerk-Endpunktgruppen in Load-Balancing-Konzepten.

Sitzungsaffinität

Ohne Sitzungsaffinität verteilen Load-Balancer neue Anfragen gemäß dem Balancing-Modus der Instanzgruppe oder der NEG des Back-Ends. Für einige Anwendungen, z. B. für zustandsorientierte Server, die für Anzeigenbereitstellung, Gaming oder Dienste mit hohem internen Caching verwendet wird, ist es aber erforderlich, dass mehrere Anfragen eines Nutzers zur selben Instanz geleitet werden.

Dies wird durch die Sitzungsaffinität ermöglicht. Dabei wird der TCP-Traffic von einem Client anhand von Parametern wie der IP-Adresse des Clients oder dem Wert eines Cookies ermittelt. Die Anfragen werden dann an eine bestimmte Back-End-Instanz weitergeleitet, wenn das Back-End fehlerfrei ist und entsprechend seines Balancing-Modus genügend Kapazität aufweist.

Die Sitzungsaffinität hat nur geringe Auswirkungen auf den UDP-Traffic, da für UDP eine Sitzung eine einzelne Anfrage und Antwort darstellt.

Die Sitzungsaffinität kann aufgehoben sein, wenn die Instanz fehlerhaft oder überlastet ist. Sie sollten daher nicht von einer durchgehend wirksamen Affinität ausgehen.

Beim HTTP(S)-Load-Balancing funktioniert die Sitzungsaffinität am besten mit dem Balancing-Modus RATE.

Unterschiedliche Load-Balancer unterstützen unterschiedliche Optionen der Sitzungsaffinität, wie in der folgenden Tabelle zusammengefasst:

Load-Balancer Optionen der Sitzungsaffinität
Intern • Keine
• Client-IP-Adresse
• Client-IP-Adresse und Protokoll
• IP-Adresse, Protokoll und Port des Clients
TCP-Proxy
SSL-Proxy
• Keine
• Client-IP-Adresse
HTTP(S) • Keine
• Client-IP-Adresse
• Generiertes Cookie
Netzwerk Das Netzwerk-Load-Balancing verwendet keine Back-End-Dienste. Stattdessen müssen Sie die Sitzungsaffinität für das Netzwerk-Load-Balancing über Zielpools festlegen. Weitere Informationen finden Sie beim Parameter sessionAffinity in Zielpools.

In den folgenden Abschnitten werden zwei gängige Arten der Sitzungsaffinität erläutert.

Client-IP-Affinität verwenden

Die Client-IP-Affinität leitet Anfragen von einer Client-IP-Adresse auf der Basis eines Hash dieser Adresse an dieselbe Back-End-Instanz weiter. Client-IP-Affinität ist eine Option für jeden Google Cloud-Load-Balancer, der Back-End-Dienste verwendet.

Bei Verwendung der Client-IP-Affinität ist Folgendes zu beachten:

  • Die Client-IP-Adresse für den Load-Balancer ist möglicherweise nicht der Ursprungsclient, wenn sich die Adresse hinter NAT befindet oder Anfragen über einen Proxy stellt. Anfragen, die über NAT oder einen Proxy gesendet werden, verwenden die IP-Adresse des NAT-Routers oder des Proxys als Client-IP-Adresse. Dies kann dazu führen, dass eingehender Traffic unnötigerweise auf dieselben Back-End-Instanzen verteilt wird.

  • Wenn ein Client von einem Netzwerk zu einem anderen verschoben wird, ändert sich seine IP-Adresse. Dies kann zur Aufhebung der Affinität führen.

Console


So legen Sie die Client-IP-Affinität fest:

  1. Wechseln Sie in der Google Cloud Console zur Back-End-Konfiguration auf der Load-Balancer-Seite.
    Zur Seite "Load-Balancing"
  2. Wählen Sie das Bleistiftsymbol für Ihren Load-Balancer aus.
  3. Wählen Sie Back-End-Konfiguration aus.
  4. Wählen Sie das Bleistiftsymbol für einen Back-End-Dienst aus.
  5. Wählen Sie im Dialogfeld Back-End-Dienst bearbeiten im Drop-down-Menü Sitzungsaffinität die Option Client IP aus.
    Diese Aktion aktiviert die Client-IP-Sitzungsaffinität. Das Feld Affinitätscookie-TTL ist ausgegraut, da es für die Client-IP-Affinität keine Bedeutung hat.
  6. Klicken Sie für den Back-End-Dienst auf die Schaltfläche Aktualisieren.
  7. Klicken Sie für den Load-Balancer auf die Schaltfläche Aktualisieren.

gcloud


Sie können den Befehl create verwenden, um die Sitzungsaffinität für einen neuen Back-End-Dienst festzulegen, oder den Befehl update, um sie für einen vorhandenen Back-End-Dienst einzurichten. In diesem Beispiel wird die Verwendung mit dem Befehl update veranschaulicht.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip
    

API


Lesen Sie die API-Referenz für Back-End-Dienste.

Wenn Sie die generierte Cookie-Affinität festlegen, gibt der Load-Balancer ein Cookie für die erste Anfrage aus. Bei jeder nachfolgenden Anfrage mit demselben Cookie leitet der Load-Balancer die Anfrage an dieselbe Back-End-VM oder denselben Back-End-Endpunkt weiter.

  • Für externe HTTP(S)-Load-Balancer lautet das Cookie GCLB.
  • Für interne HTTP(S)-Load-Balancer und Traffic Director lautet das Cookie GCILB.

Cookiebasierte Affinität kann einen Client gegenüber einem Load-Balancer genauer als client-IP-basierte Affinität identifizieren. Beispiel:

  1. Bei einer cookiebasierten Affinität kann der Load-Balancer zwei oder mehr Clientsysteme mit identischer Quell-IP-Adresse eindeutig identifizieren. Bei Verwendung der client-IP-basierten Affinität behandelt der Load-Balancer alle Verbindungen von derselben Quell-IP-Adresse, als wenn sie vom selben Clientsystem stammten.

  2. Wenn ein Client seine IP-Adresse ändert, z. B. wenn ein Mobilgerät von Netzwerk zu Netzwerk wechselt, kann der Load-Balancer nachfolgende Verbindungen von diesem Client erkennen, statt die Verbindung als neu zu behandeln.

Erstellt ein Load-Balancer ein Cookie für eine generierte cookiebasierte Affinität, wird das Attribut path des Cookies auf / gesetzt. Wenn die URL-Zuordnung des Load-Balancers über einen Pfad-Matcher verfügt, der mehr als einen Back-End-Dienst für einen bestimmten Host-Namen angibt, teilen alle Back-End-Dienste mit cookiebasierter Sitzungsaffinität dasselbe Sitzungs-Cookie.

Die Lebensdauer der vom Load-Balancer generierten HTTP-Cookies ist konfigurierbar. Sie können sie auf 0 setzen, d. h., das Cookie ist nur ein Sitzungscookie, oder Sie können die Lebensdauer des Cookies auf einen Wert von 1 bis 86400 Sekunden (24 Stunden) festlegen.

Console


So legen Sie die Cookie-Affinität fest:

  1. In der Google Cloud Console können Sie die Cookie-Affinität im Bereich der Back-End-Konfiguration der HTTP(S)-Load-Balancer-Seite ändern.
    Zur Seite "Load-Balancing"
  2. Wählen Sie das Bleistiftsymbol für Ihren Load-Balancer aus.
  3. Wählen Sie Back-End-Konfiguration aus.
  4. Wählen Sie das Bleistiftsymbol für einen Back-End-Dienst aus.
  5. Wählen Sie Generated cookie aus dem Drop-down-Menü Sitzungsaffinität aus, um Cookie-Affinität auszuwählen.
  6. Legen Sie im Feld Affinitätscookie-TTL die Lebensdauer des Cookies in Sekunden fest.
  7. Klicken Sie für den Back-End-Dienst auf die Schaltfläche Aktualisieren.
  8. Klicken Sie für den Load-Balancer auf die Schaltfläche Aktualisieren.

gcloud


Aktivieren Sie die generierte Cookie-Affinität, indem Sie --session-affinity auf generated_cookie setzen und --affinity-cookie-ttl auf die Cookie-Lebensdauer in Sekunden festlegen. Sie können den Befehl create verwenden, um sie für einen neuen Back-End-Dienst festzulegen, oder den Befehl update, um sie für einen vorhandenen Back-End-Dienst einzurichten. In diesem Beispiel wird die Verwendung mit dem Befehl update veranschaulicht.

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400
    

API


Lesen Sie die API-Referenz für Back-End-Dienste.

Sitzungsaffinität deaktivieren

Sie können die Sitzungsaffinität deaktivieren, indem Sie den Back-End-Dienst aktualisieren und die Sitzungsaffinität auf none festlegen oder den Back-End-Dienst bearbeiten und die Sitzungsaffinität auf none festlegen. Sie können auch einen der beiden Befehle verwenden, um die Lebensdauer des Cookies zu ändern.

Console


So deaktivieren Sie die Sitzungsaffinität:

  1. In der Google Cloud Console können Sie die Sitzungsaffinität im Bereich Back-End-Konfiguration auf der Load-Balancer-Seite deaktivieren.
    Zur Seite "Load-Balancing"
  2. Wählen Sie das Bleistiftsymbol für Ihren Load-Balancer aus.
  3. Wählen Sie Back-End-Konfiguration aus.
  4. Wählen Sie das Bleistiftsymbol für einen Back-End-Dienst aus.
  5. Wählen Sie None aus dem Drop-down-Menü Sitzungsaffinität aus, um die Sitzungsaffinität zu deaktivieren.
  6. Klicken Sie für den Back-End-Dienst auf die Schaltfläche Aktualisieren.
  7. Klicken Sie für den Load-Balancer auf die Schaltfläche Aktualisieren.

gcloud


Mit dem folgenden Befehl deaktivieren Sie die Sitzungsaffinität:

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none
    


ODER

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API


Lesen Sie die API-Referenz für Back-End-Dienste.

Verlust der Sitzungsaffinität

Unabhängig vom gewählten Typ der Affinität kann ein Client die Affinität mit der Instanz beispielsweise in den folgenden Fällen verlieren.

  • Die Instanzgruppe hat keine Kapazität mehr und der Traffic muss in eine andere Zone geleitet werden. In diesem Fall könnte der Traffic von bestehenden Sitzungen zur neuen Zone gesendet werden, wodurch die Affinität abreißt. Sie können dieser Situation vorbeugen, indem Sie dafür sorgen, dass Ihre Instanzgruppen genügend Kapazität haben, um alle lokalen Nutzer zu verarbeiten.
  • Durch Autoscaling werden der Instanzgruppe Instanzen hinzugefügt oder daraus entfernt. In beiden Fällen verteilt der Back-End-Dienst die Last neu und das Ziel wird eventuell verschoben. Sie können dieser Situation vorbeugen, indem Sie dafür sorgen, dass die Mindestanzahl an Instanzen, die durch das Autoscaling bereitgestellt wird, ausreicht, um die erwartete Last zu bewältigen, und das Autoscaling dann nur für eine unerwartete Erhöhung der Last verwendet wird.
  • Die Zielinstanz scheitert bei den Systemdiagnosen. Die Affinität geht verloren, da die Sitzung zu einer fehlerfreien Instanz verschoben wird.
  • Der Balancing-Modus ist auf die Back-End-Auslastung eingestellt. Dies kann dazu führen, dass sich die berechnete Kapazität zwischen Zonen ändert und einige Zugriffe an eine andere Zone innerhalb der Region gesendet werden. Dies ist bei geringem Traffic wahrscheinlicher, wenn die berechnete Kapazität weniger stabil ist.
  • Wenn sich die Back-Ends in mehreren Cloud-Regionen befinden und Ihre Clientweiterleitung so konzipiert ist, dass die erste und nachfolgende Anfragen in einer Verbindung von verschiedenen geografischen Standorten aus erfolgen, verlieren Sie möglicherweise die Sitzungsaffinität. Dies liegt daran, dass die zusätzlichen Anfragen möglicherweise an eine andere Cloud-Region weitergeleitet werden, die durch den neuen Ausgangsstandort bestimmt wird.

Einstellung für Zeitlimit konfigurieren

Legen Sie für langlebigere Verbindungen vom Load-Balancer zum Back-End-Dienst ein höheres Zeitlimit als die 30-Sekunden-Standardeinstellung fest.

Console


So konfigurieren Sie die Einstellung für das Zeitlimit:

  1. In der Google Cloud Console können Sie die Zeitlimiteinstellung im Abschnitt Back-End-Konfiguration der HTTP(S)-Load-Balancer-Seite ändern.
    Zur Seite "Load-Balancing"
  2. Wählen Sie das Bleistiftsymbol für Ihren Load-Balancer aus.
  3. Wählen Sie Back-End-Konfiguration aus.
  4. Wählen Sie das Bleistiftsymbol für den Back-End-Dienst aus.
  5. Wählen Sie in der Zeile für die Einstellungen Protokoll, Port und Zeitüberschreitung das Bleistiftsymbol aus, um die Einstellungen zu bearbeiten.
  6. Geben Sie eine neue Zeitüberschreitungseinstellung in Sekunden ein.
  7. Klicken Sie für den Back-End-Dienst auf die Schaltfläche Aktualisieren.
  8. Klicken Sie für den Load-Balancer auf die Schaltfläche Aktualisieren.

gcloud


Wenn Sie die Zeitlimiteinstellung mit dem gcloud-Befehlszeilentool ändern möchten, verwenden Sie den Befehl "gcloud compute backend-services update". Hängen Sie an den Befehl --help an, um ausführliche Informationen zu erhalten.

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]
    

API


Lesen Sie die REST API-Referenz für Back-End-Dienste.

Benannte Ports

Für interne HTTP(S)-, externen HTTP(S)-, SSL-Proxy- und TCP-Proxy-Load-Balancer muss Back-End-Diensten ein benannter Port zugeordnet sein, wenn es sich bei den Back-Ends um Instanzgruppen handelt. Durch Benennung eines Ports wird festgelegt, dass der Load-Balancer diesen konfigurierten benannten Port in der Back-End-Instanzgruppe verwenden soll. Dafür wird dann eine Portnummer übergeben. Diese steht für den Port, über den der Load-Balancer eine Verbindung zu den Back-End-VMs herstellt. Dieser Port kann sich von dem Port unterscheiden, über den Clients den Load-Balancer selbst kontaktieren.

Benannte Ports sind Schlüssel/Wert-Paare mit einem Dienstnamen und einer Portnummer, für die ein Dienst ausgeführt wird. Das Schlüssel/Wert-Paar wird jeweils für eine Instanzgruppe definiert. Wenn ein Back-End-Dienst diese Instanzgruppe als Back-End verwendet, kann er den benannten Port "abonnieren":

  • Für jede Instanzgruppe können bis zu fünf benannte Ports (Schlüssel/Wert-Paare) definiert werden.
  • Jeder Back-End-Dienst für einen HTTP(S)-, SSL-Proxy- oder TCP-Proxy-Load-Balancer, der Instanzgruppen-Back-Ends verwendet, kann nur einen einzigen benannten Port "abonnieren".
  • Wenn Sie einen benannten Port für einen Back-End-Dienst festlegen, muss für alle Back-End-Instanzgruppen mindestens ein benannter Port mit dem gleichen Namen definiert sein.

Benannte Ports können in folgenden Fällen nicht verwendet werden:

  • Für NEG-Back-Ends: NEGs definieren Ports pro Endpunkt. Einer NEG ist kein Schlüssel/Wert-Paar für einen benannten Port zugeordnet.
  • Für interne TCP/UDP-Load-Balancer: Da es sich bei internen TCP/UDP-Load-Balancern um Passthrough-Load-Balancer (keine Proxys) handelt, unterstützen ihre Back-End-Dienste keine Festlegung eines benannten Ports.

Systemdiagnosen

Jeder Back-End-Dienst muss mit einer Systemdiagnose verknüpft sein. Die Systemdiagnose muss vorhanden sein, bevor Sie den Back-End-Dienst erstellen.

Eine Systemdiagnose wird kontinuierlich ausgeführt. Anhand der Ergebnisse wird ermittelt, welche Instanzen neue Anfragen erhalten können.

Fehlerhafte Instanzen erhalten keine neuen Anfragen und werden weiterhin abgefragt. Wenn eine fehlerhafte Instanz eine Systemdiagnose besteht, gilt sie als fehlerfrei und erhält neue Verbindungen.

Weitere Informationen finden Sie in den folgenden Dokumenten:

Ergebnisse einer Systemdiagnose für Back-End-Dienste aufrufen

Nachdem Sie die Systemdiagnosen und den Back-End-Dienst erstellt haben, können Sie die Ergebnisse der Systemdiagnose aufrufen.

Console


So können Sie sich das Ergebnis einer Systemdiagnose für einen Back-End-Dienst ansehen:

  1. Wechseln Sie zur Seite der Load-Balancing-Zusammenfassung.
    Zur Seite "Load-Balancing"
  2. Klicken Sie auf den Namen eines Load-Balancers.
  3. Sehen Sie sich unter Back-End für einen Back-End-Dienst die Spalte Fehlerfrei in der Tabelle der Instanzgruppe an.

gcloud


Verwenden Sie den Befehl backend-services get-health, um die Ergebnisse der aktuellen Systemdiagnose mit dem gcloud-Befehlszeilentool aufzurufen.

gcloud compute backend-services get-health [BACKEND_SERVICE]
    

Der Befehl gibt für alle Instanzen im angegebenen Back-End-Dienst einen healthState-Wert zurück, der entweder HEALTHY oder UNHEALTHY lautet:

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth
      

API


Informationen zu API-Befehlen finden Sie auf der Seite Systemdiagnosen.

Zusätzliche aktivierte Features in der Back-End-Dienstressource

Die folgenden optionalen Google Cloud-Features, die über die Back-End-Dienstressource aktiviert werden, werden in diesem Dokument nicht behandelt:

Sonstige Hinweise

Änderungen an Ihren Back-End-Diensten erfolgen nicht sofort. Es kann einige Minuten dauern, bis Änderungen im gesamten Netzwerk wirksam werden.

Die folgenden Traffic Director-Features werden von Google Cloud-Load-Balancern nicht unterstützt:

  • Schutzschaltung
  • Ausreißererkennung
  • Load-Balancing-Richtlinien
  • Cookiebasierte HTTP-Sitzungsaffinität
  • Header-basierte HTTP-Sitzungsaffinität

Weitere Informationen

Eine Dokumentation und Informationen zur Verwendung von Back-End-Diensten beim Load-Balancing finden Sie in den folgenden Abschnitten: