Wie behebe ich Probleme mit der Sitzungs-Stickiness beim Application Load Balancer?

Kurzbeschreibung

Sticky Sessions verwenden Cookies, um dem Client zu helfen, über die gesamte Lebensdauer eines Cookies eine Verbindung zu demselben Ziel aufrechtzuerhalten. Sticky Sessions konfigurieren einen Load Balancer, um Benutzersitzungen an ein bestimmtes Ziel zu binden. Das bedeutet, dass alle Anforderungen eines Benutzers während einer Sitzung an dasselbe Ziel gesendet werden. Diese Annahme über den Zusammenhang kann jedoch im Laufe der Zeit zu Ungleichgewichten führen.

Eine Sticky Session kann aus den folgenden Gründen fehlschlagen:

• Das registrierte Ziel hat kein Cookie generiert.
• Der Client hat das Cookie im Anforderungsheader nicht zurückgegeben.
• Die Cookies sind nicht richtig formatiert.
• Die dauerbasierte Sitzung ist beendet.
• Die Sitzungsanforderung durchläuft mehrere Load Balancer.
• Der Zielzustandsstatus wurde in „fehlerhaft“ geändert.
• Ein AWS-Service hat die Stickiness deaktiviert.

Hinweis: Bevor Sie beginnen, stellen Sie sicher, dass Sie die Abschnitte zu Anforderungen und Überlegungen in Sticky Sessions für Ihren Application Load Balancer lesen.

Lösung

Anwendungsbasierte Sitzungs-Stickiness

1. Prüfen Sie den Load Balancer auf HTTP-Fehler. Anweisungen finden Sie unter Problembehandlung bei Application Load Balancern.

2. Führen Sie einen curl-Befehl ähnlich dem folgenden aus, um nach Cookies zu suchen, die auf der Backend-Instance oder dem Load Balancer platziert wurden. Ersetzen Sie den DNS-Namen durch Ihren Load Balancer-Namen:

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.com

   Hinweis: Sie können das Linux-curl-Hilfsprogramm auch auf dem Windows-Betriebssystem (OS) installieren. Weitere Informationen finden Sie unter curl 8.10.1 für Windows auf der curl-Website.

   Die Ausgabe des curl-Befehls sieht etwa wie folgt aus:

   ...
   < Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/
   
   < Set-Cookie:
   
   AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   
   ...

3. Um zu überprüfen, ob das registrierte Ziel ein Anwendungs-Cookie generiert hat, senden Sie eine HTTP-Anforderung an die Instance-IP-Adresse, die der folgenden ähnelt:

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

   Die Ausgabe für diesen Befehl sieht etwa wie folgt aus:

   ...
   < Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/
   
   ...

4. Stellen Sie sicher, dass der vom registrierten Ziel generierte Cookie-Name der Name des Cookies auf dem Load Balancer aus den Schritten 2 und 3 ist.

5. Wenn das Ziel ein Anwendungs-Cookie generiert und der Load Balancer ein AWSALBAPP-Cookie generiert, überprüfen Sie, ob der Client in nachfolgenden Anforderungen beide Cookies sendet. Wenn der Client weder die Anwendung noch das AWSELB-Cookie enthält, schlägt die Stickiness fehl. Um zu überprüfen, ob der Client sowohl die Anwendung als auch das AWSALBAPP-Cookie sendet, führen Sie eine Paketerfassung auf dem Client durch. Verwenden Sie eine der folgenden Optionen, um die Cookie-Informationen im Anforderungsheader abzurufen:

   **tcpdump ** von der tcpdump-Website
   Wireshark-Dienstprogramm von der Wireshark-Website
   Web-Debugging-Tool für Browser

   Hinweis: Wenn Sie mit AWS Support zusammenarbeiten, erstellen Sie eine HAR-Datei, um diese Informationen zu sammeln. Da HAR-Dateien vertrauliche Informationen wie Benutzernamen, Passwörter und Schlüssel erfassen können, sollten Sie sicherstellen, dass Sie vertrauliche Informationen aus einer HAR-Datei entfernen.

6. Überprüfen Sie die Backend-Instance, an die der Load Balancer die Anforderung weitergeleitet hat. Um Instance-Metadaten zur Anzeige der Instance-ID zu verwenden, führen Sie ein Skript ähnlich dem folgenden aus:

   <?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');echo "instance id = " . $instance_id . "\\xA";?>

7. Um zu überprüfen, ob Anforderungen desselben Benutzers an verschiedene registrierte Ziele weitergeleitet werden, überprüfen Sie Ihre Elastic Load Balancing (ELB)-Zugriffsprotokolle. Eine Anleitung finden Sie unter Zugriffsprotokolle für den Application Load Balancer.

8. Stellen Sie sicher, dass der Zustand aller Ziele unter der Zielgruppe, für die Stickiness aktiviert ist, „fehlerfrei“ ist. Wenn der Zustand des Ziels zu fehlerhaft wechselt, wird die Stickiness unterbrochen und der Load Balancer leitet Anforderungen nicht an dieses Ziel weiter. Ein neues fehlerfreies Ziel wird dann automatisch vom Load Balancer ausgewählt und eine Sticky Session wird eingerichtet. Der Load Balancer leitet weiterhin Anforderungen an das neue Ziel weiter, auch wenn der Zustand fehlerhaft ist. Weitere Informationen zu Zustandsprüfungen finden Sie unter Zustandsprüfungen für Application Load Balancer-Zielgruppen.

9. Suchen Sie nach AWS-Services wie Amazon Elastic Kubernetes Service (Amazon EKS), die möglicherweise die Stickiness in Ihrem Load Balancer deaktiviert haben. Prüfen Sie den CloudTrail-Ereignisverlauf. Verwenden Sie den API-Namen ModifyTargetGroupAttributes und das Attribut stickiness.enabled.

Dauerbasierte Sitzungs-Stickiness

1. Um nach einem AWSALB-Cookie zu suchen, führen Sie einen curl-Befehl aus, der dem folgenden ähnelt. Stellen Sie sicher, dass Sie den DNS-Namen des Load Balancer verwenden:

   [ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

   Die Ausgabe des curl-Befehls sieht etwa wie folgt aus:

   ...
   < Set-Cookie: AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
   ...

   Hinweis: Wenn die Antwort kein AWSALB-Cookie enthält, besteht keine Stickiness zwischen dem Client und der Backend-Instance.

2. Wenn der Load Balancer ein AWSALB-Cookie generiert hat, überprüfen Sie, ob der Client dieses Cookie bei nachfolgenden Anforderungen sendet. Wenn der Client das AWSALB-Cookie nicht einbindet, funktioniert Stickiness nicht. Um zu überprüfen, ob der Client das AWSALB-Cookie sendet, führen Sie eine Paketerfassung auf dem Client durch. Verwenden Sie eine der folgenden Optionen, um die Cookie-Informationen im Anforderungsheader abzurufen:

   **tcpdump ** von der tcpdump-Website
   Wireshark-Dienstprogramm von der Wireshark-Website
   Web-Debugging-Tool für Browser

   Hinweis: Wenn Sie mit AWS Support zusammenarbeiten, erstellen Sie eine HAR-Datei, um diese Informationen zu sammeln. Da HAR-Dateien vertrauliche Informationen wie Benutzernamen, Passwörter und Schlüssel erfassen können, sollten Sie sicherstellen, dass Sie vertrauliche Informationen aus einer HAR-Datei entfernen.

3. Überprüfen Sie die auf dem Load Balancer konfigurierte Dauer. Wenn das Cookie abgelaufen ist, bleiben die Clientsitzungen nicht mehr am registrierten Ziel, bis ein neues Cookie vom Load Balancer ausgegeben wird.

4. Wenn Ihre Anforderung mehrere Load Balancer durchläuft, stellen Sie sicher, dass Stickiness nur auf einem Load Balancer aktiviert ist. Wenn mehr als ein Load Balancer ein Cookie generiert, ersetzt der Load Balancer das ursprüngliche Cookie, und die Stickiness schlägt fehl.

Informationen zu Classic Load Balancern finden Sie unter Wie kann ich Probleme mit der Funktion der Sitzungs-Stickiness bei Classic Load Balancern beheben?

Ähnliche Informationen

Warum leitet Elastic Load Balancing meinen Load Balancer-Verkehr ungleichmäßig weiter?

Konfigurieren von Sticky Sessions für den Classic Load Balancer

Wie richte ich gewichtete Zielgruppen für meinen Application Load Balancer ein?