Comment puis-je résoudre les problèmes de session permanente de l'équilibreur Application Load Balancer ?

Lecture de 6 minute(s)
0

J'ai un équilibreur Application Load Balancer qui utilise des sessions permanentes basées sur la durée ou permanentes basées sur les applications. L'équilibreur de charge est configuré pour acheminer toutes les demandes de séance utilisateur vers la même cible. Toutefois, les demandes de séance utilisateur sont acheminées vers différentes cibles.

Brève description

Les sessions permanentes utilisent des cookies pour aider le client à maintenir une connexion à la même instance pendant la durée de vie d'un cookie. L'utilisation de sessions permanentes configure un équilibreur de charge pour lier les séances utilisateur à une instance spécifique. Cela signifie que toutes les demandes d'un utilisateur au cours d'une session sont envoyées à la même instance. Cependant, cette hypothèse concernant la connexion peut entraîner des déséquilibres au fil du temps.

Une session permanente peut échouer si :

  • La cible enregistrée n'a pas généré de cookie
  • Le client n'a pas renvoyé le cookie dans l'en-tête de la demande
  • Les cookies ne sont pas correctement formatés
  • La séance basée sur la durée est terminée
  • La demande de séance passe par plusieurs équilibreurs de charge
  • L'état de la cible est passé à malsain
  • Un service AWS a désactivé la permanence

Remarque : avant de commencer, assurez-vous de consulter la section exigences et considérations dans Sessions permanentes pour votre équilibreur Application Load Balancer.

Solution

Permanence de séance basée sur l’application

1.    Vérifiez les erreurs HTTP avec votre équilibreur de charge. Pour obtenir des instructions, consultez Résoudre les problèmes liés à vos équilibreurs Application Load Balancer.

2.    Pour vérifier les cookies placés sur l'instance backend ou l'équilibreur de charge, exécutez une commande curl similaire à la suivante :

Remarque : remplacez le nom du DNS par le nom de votre équilibreur de charge.

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

Remarque : l'utilitaire Linux curl peut également être installé sur le système d’exploitation Windows.

Exemple de sortie :

...

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

< Set-Cookie:

AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

3.    Pour vérifier que la cible enregistrée a généré un cookie d'application, envoyez une requête HTTP à l'adresse IP de l'instance similaire à la suivante :

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

Exemple de sortie :

...

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

...

4.    Vérifiez que le nom du cookie généré par la cible enregistrée est le même que celui du cookie sur l'équilibreur de charge aux étapes 2 et 3.

5.    Si la cible a généré un cookie d'application et que l'équilibreur de charge a généré un cookie AWSALBAPP, assurez-vous que le client envoie les deux cookies dans les demandes suivantes. Si le client n'inclut pas le cookie d'application ou le cookie AWSELB, la permanence échouera. Pour vérifier que le client envoie les cookies de l'application et d’AWSALBAPP, effectuez une capture de paquets sur le client. Utilisez l'utilitaire tcpdump ou Wireshark pour l'analyse, ou utilisez l'outil de débogage Web du navigateur pour récupérer les informations sur le cookie dans l'en-tête de la demande.

Remarque : si vous travaillez avec AWS Support, vous pouvez recueillir ces informations en générant un fichier HAR. Les fichiers HAR peuvent capturer des informations sensibles, telles que des noms d'utilisateur, des mots de passe et des clés. Veillez donc à supprimer toute information sensible d'un fichier HAR.

6.    Vérifiez vers quelle instance backend l'équilibreur de charge a acheminé la demande. Vous pouvez afficher l'identifiant de l’instance avec les métadonnées de l’instance en exécutant un script similaire au suivant :

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

7.    Consultez vos journaux d'accès Elastic Load Balancing pour vérifier si les demandes d'un même utilisateur sont acheminées vers différentes cibles enregistrées. Pour obtenir des instructions, consultez Journaux d'accès pour votre équilibreur Application Load Balancer.

8.    Vérifiez que l'état de toutes les cibles du groupe cible où la permanence est activée est sain. Si l'état de la cible passe à « malsain », la permanence cesse et l'équilibreur de charge arrête le routage des demandes vers cette cible. Une nouvelle cible saine est ensuite automatiquement sélectionnée par l'équilibreur de charge et établit une session permanente. L'équilibreur de charge continue d'acheminer les demandes vers la nouvelle cible même si l'état est « malsain ». Pour plus d'informations sur les surveillances de l’état, consultez Surveillances de l’état de vos groupes cibles.

9.    Vérifiez les services AWS, par exemple Amazon Elastic Kubernetes Service (Amazon EKS), qui ont pu désactiver la permanence de votre équilibreur de charge. Vérifiez les événements View CloudTrail avec le nom d'API « ModifyTargetGroupAttributes » et l'attribut « stickiness.enabled ».

Permanence de session basée sur la durée

1.    Exécutez une commande similaire à la suivante avec le nom DNS de l'équilibreur de charge afin de vérifier la présence d'un cookie AWSALB dans la réponse :

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

Exemple de sortie :

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

Remarque : si un cookie AWSALB n'apparaît pas dans la réponse, cela signifie qu'il n'y a pas de permanence entre le client et l'instance backend.

2.    Si l'équilibreur de charge a généré un cookie AWSALB, assurez-vous que le client envoie ce cookie dans les demandes suivantes. Si le client n'inclut pas le cookie AWSALB, la permanence ne fonctionnera pas. Pour vérifier que le client envoie le cookie AWSALB, effectuez une capture de paquets sur le client. Utilisez l'utilitaire tcpdump ou Wireshark pour l'analyse, ou utilisez l'outil de débogage Web du navigateur pour récupérer les informations sur le cookie dans l'en-tête de la demande.

Remarque : si vous travaillez avec AWS Support, vous pouvez recueillir ces informations en générant un fichier HAR. Les fichiers HAR peuvent capturer des informations sensibles, telles que des noms d'utilisateur, des mots de passe et des clés. Veillez donc à supprimer toute information sensible d'un fichier HAR.

3.    Vérifiez la durée configurée sur l'équilibreur de charge. Si la période d'expiration du cookie est passée, alors les séances client ne restent plus liées à la cible enregistrée tant qu'un nouveau cookie n'est pas émis par l'équilibreur de charge.

4.    Si votre demande passe par plusieurs équilibreurs de charge, vérifiez que la permanence est activée sur un seul équilibreur de charge. Si plusieurs équilibreurs de charge génèrent un cookie, l'équilibreur de charge remplace le cookie d'origine et le caractère permanent est compromis.

Pour les équilibreurs Classic Load Balancers, consultez Comment puis-je résoudre les problèmes liés aux fonctions de permanence de séance de l’équilibreur Classic Load Balancer ?


Informations connexes

Pourquoi Elastic Load Balancing gère-t-il de manière irrégulière le trafic de mon équilibreur de charge ?

Configuration des sessions permanentes pour votre Classic Load Balancer

Comment configurer des groupes cibles pondérés pour mon Application Load Balancer ?

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans