Wie kann ich Probleme mit der Gebundenheit von Application-Load-Balancer-Sitzungen beheben?

Lesedauer: 5 Minute
0

Ich habe einen Application Load Balancer, der Sitzungen mit dauerbasierter Gebundenheit oder anwendungsbasierter Gebundenheit verwendet. Der Load Balancer ist so konfiguriert, dass er alle Benutzersitzungsanforderungen an dasselbe Ziel weiterleitet. Benutzersitzungsanfragen werden jedoch an verschiedene Ziele weitergeleitet.

Kurzbeschreibung

Gebundenheitssitzungen verwenden Cookies, um dem Kunden zu helfen, über die gesamte Lebensdauer eines Cookies eine Verbindung zur gleichen Instance aufrechtzuerhalten. Die Verwendung von gebundenen Sitzungen konfiguriert einen Load Balancer, um Benutzersitzungen an eine bestimmte Instance zu binden. Das bedeutet, dass alle Anfragen eines Benutzers während einer Sitzung an dieselbe Instance gesendet werden. Jedoch kann diese Annahme über die Verbindung im Laufe der Zeit zu Ungleichgewichten führen.

Eine Sticky Session kann fehlschlagen, wenn:

  • Das registrierte Ziel kein Cookie generiert hat.
  • Der Client das Cookie im Anforderungs-Header nicht zurückgegeben hat.
  • Die Cookies nicht richtig formatiert sind.
  • Die auf der Dauer basierende Sitzung abgelaufen ist.
  • Die Sitzungsanforderung mehrere Load Balancer durchläuft.
  • Der Zielzustandsstatus sich in „ungesund“ verändert hat.
  • Ein AWS-Service die Gebundenheit deaktiviert hat.

Hinweis: Bevor Sie beginnen, sollten Sie den Abschnitt Anforderungen und Überlegungen in Gebundene Sitzungen für Ihren Application Load Balancer durchlesen.

Auflösung

Anwendungsbasierte Sitzungsgebundenheit

1.    Suchen Sie mit Ihrem Load Balancer nach HTTP-Fehlern. Anweisungen finden Sie unter Problembehandlung bei Ihren Application Load Balancern.

2.    Führen Sie einen curl-Befehl aus, der dem folgenden ähnelt, um nach Cookies zu suchen, die auf der Backend-Instance oder dem Load Balancer platziert wurden:

Hinweis: Ersetzen Sie den DNS-Namen durch den Namen Ihres Load Balancers.

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

Hinweis: Das Linux-Curl-Dienstprogramm kann auch unter Windows installiert werden.

Beispielausgabe:

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/

< Set-Cookie:

AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

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

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

Beispielausgabe:

...

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

...

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

5.    Wenn das Ziel ein Anwendungscookie generiert hat und der Load Balancer ein AWSALBAPP-Cookie generiert hat, stellen Sie sicher, dass der Client bei nachfolgenden Anfragen beide Cookies sendet. Wenn der Client entweder die Anwendung oder das AWSELB-Cookie nicht einschließt, schlägt die Gebundenheit fehl. Um zu überprüfen, ob der Client sowohl die Anwendungs- als auch AWSALBAPP-Cookies sendet, führen Sie eine Paketerfassung auf dem Client durch. Verwenden Sie das Dienstprogramm tcpdump oder Wireshark zur Analyse oder verwenden Sie das Web-Debugging-Tool des Browsers, um die Cookie-Informationen im Anforderungs-Header abzurufen.

Hinweis: Wenn Sie mit dem AWS Support arbeiten, können Sie diese Informationen sammeln, indem Sie eine HAR-Datei generieren. HAR-Dateien können vertrauliche Informationen wie Benutzernamen, Kennwörter und Schlüssel erfassen. Entfernen Sie daher alle vertraulichen Informationen aus einer HAR-Datei.

6.    Prüfen Sie, an welche Backend-Instance der Load Balancer die Anfrage weitergeleitet hat. Sie können die Instance-ID mithilfe von Instance-Metadaten anzeigen, indem Sie ein Skript ausführen, das dem folgenden ähnelt:

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

7.    Überprüfen Sie Ihre Zugriffsprotokolle für Elastic Load Balancing, um zu überprüfen, ob Anfragen desselben Benutzers an verschiedene registrierte Ziele weitergeleitet werden. Anweisungen finden Sie unter Zugriffsprotokolle für Ihren Application Load Balancer.

8.    Stellen Sie sicher, dass der Integritätsstatus aller Ziele unter der Zielgruppe, in der Gebundenheit aktiviert ist, gesund ist. Wenn sich der Status des Zielzustands in „ungesund“ ändert, wird die Gebundenheit unterbrochen und der Load Balancer beendet das Weiterleiten von Anforderungen an dieses Ziel. Ein neues funktionstüchtiges Ziel wird dann automatisch vom Load Balancer ausgewählt und er richtet eine Sticky Session ein. Der Load Balancer leitet weiterhin Anforderungen an das neue Ziel weiter, auch wenn der Integritätsstatus „ungesund“ ist. Weitere Informationen zu Zustandsprüfungen finden Sie unter Zustandsprüfungen für Ihre Zielgruppen.

9.    Suchen Sie nach AWS-Services, z. B. Amazon Elastic Kubernetes Service (Amazon EKS), die möglicherweise die Gebundenheit in Ihrem Load Balancer deaktiviert haben. Überprüfen Sie CloudTrail-Ereignisse anzeigen mit dem API-Namen „modifyTargetGroupAttributes“ und dem Attribut „stickiness.enabled“.

Dauerbasierte Sitzungsgebundenheit

1.    Führen Sie einen Befehl ähnlich dem folgenden mit dem DNS-Namen des Load Balancers aus, um in der Antwort nach einem AWSALB-Cookie zu suchen:

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

Beispielausgabe:

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

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

2.    Wenn der Load Balancer ein AWSALB-Cookie generiert hat, stellen Sie sicher, dass der Client dieses Cookie bei nachfolgenden Anfragen sendet. Wenn der Client das AWSALB-Cookie nicht einschließt, funktioniert die Gebundenheit nicht. Um zu überprüfen, ob der Client das AWSALB-Cookie sendet, führen Sie eine Paketerfassung auf dem Client durch. Verwenden Sie das Dienstprogramm tcpdump oder Wireshark zur Analyse oder verwenden Sie das Web-Debugging-Tool des Browsers, um die Cookie-Informationen im Anforderungs-Header abzurufen.

Hinweis: Wenn Sie mit dem AWS Support arbeiten, können Sie diese Informationen sammeln, indem Sie eine HAR-Datei generieren. HAR-Dateien können vertrauliche Informationen wie Benutzernamen, Kennwörter und Schlüssel erfassen. Entfernen Sie daher alle vertraulichen Informationen aus einer HAR-Datei.

3.    Überprüfen Sie die für den Load Balancer konfigurierte Dauer. Wenn das Cookie abgelaufen ist, bleiben die Clientsitzungen nicht mehr an das registrierte Ziel gebunden, bis ein neues Cookie vom Load Balancer ausgegeben wird.

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

Informationen zu Classic Load Balancern finden Sie unter Wie kann ich Fehler im Zusammenhang mit der Funktion für gebundene Sitzungen bei einem Classic Load Balancer beheben?


Ähnliche Informationen

Weshalb leitet Elastic Load Balancing meinen Load-Balancer-Datenverkehr ungleichmäßig weiter?

Konfigurieren von gebundenen Sitzungen für Ihren Classic Load Balancer

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

AWS OFFICIAL
AWS OFFICIALAktualisiert vor 2 Jahren