Comment résoudre les problèmes et corriger les défaillances des surveillances de l'état des Classic Load Balancers ?

Résolution

Elastic Load Balancing (ELB) prend en charge les Application Load Balancers, les Application Load Balancers et les Classic Load Balancers. Pour résoudre les problèmes liés à l'échec des surveillance de l'état du Classic Load Balancer, vous pouvez exécuter le dossier d'exploitation AWSSupport-TroubleshootELBHealthChecks. Le dossier d'exploitation automatise l'analyse des métriques de surveillance de l'état à partir du tableau de bord Amazon CloudWatch et valide les configurations réseau sur le Classic Load Balancer et vos cibles. Pour les cibles gérées par AWS Systems Manager, le dossier d'exploitation fournit des commandes de diagnostic avancées avec conservation facultative des journaux dans Amazon S3. Cette solution s'applique au type de cible de l'instance.

Les instances qui s'exécutent sur des Classic Load Balancers peuvent échouer à la surveillance de l'état pour les raisons suivantes :

Problèmes de connectivité entre l'équilibreur de charge et le backend

• Assurez-vous que le backend autorise le trafic de surveillance de l'état. Pour vérifier les règles de votre groupe de sécurité, consultez la section Règles recommandées pour les groupes de sécurité de l'équilibreur de charge. Pour l'instance principale, consultez la section Groupes de sécurité pour les instances d'un cloud privé virtuel (VPC).
• La liste de contrôle d'accès au réseau (réseau ACL) du sous-réseau où se trouvent l'équilibreur de charge et le backend doit autoriser la surveillance de l'état du trafic. Pour vérifier les règles de contrôle d'accès au réseau, consultez la section ACL réseau pour les équilibreurs de charge dans un VPC.
• Les pare-feux au niveau de l'instance ou du système d'exploitation sur le backend doivent autoriser le trafic entrant et sortant de la surveillance de l'état.
• L'utilisation de la mémoire et du processeur pour l'instance principale doit se situer dans des limites acceptables. Si l’utilisation de la mémoire ou du processeur est trop élevée, ajoutez d'autres backends ou mettez à niveau les backends vers un type d'instance plus important.
• Des ressources supplémentaires doivent permettre de vérifier la surveillance de l'état du trafic. Le backend peut transmettre la demande de surveillance de l'état à une ressource supplémentaire. Si la dépendance supplémentaire ne répond pas ou met trop de temps à répondre, la surveillance de l'état expire et échoue. Assurez-vous que la ressource supplémentaire répond aux demandes de surveillance de l'état.

Problèmes de configuration de l’application

• Assurez-vous que l'application est en cours d'exécution. Par exemple, si vous exécutez Apache sur une instance Linux, utilisez la commande sudo service httpd status pour vérifier qu'Apache est en cours d'exécution.
• L'application doit être en cours d'écoute sur le port de surveillance de l'état. Pour vérifier que le serveur est en état d'écoute pour le port de surveillance de l'état, exécutez la commande netstat -ant sur le serveur. Vérifiez le port de configuration de l'application pour vérifier qu'il est en cours d'exécution. Pour simuler une connexion TCP entre l'équilibreur de charge et le backend, exécutez la commande telnet <backend private IP> <health-check port> sur l'instance. Si la sortie est Connectée, cela signifie que le backend écoute sur le port de surveillance de l'état.
• L'application doit être configurée pour répondre aux demandes avec un en-tête d'hôte personnalisé. Pour les surveillances de l'état HTTP et HTTPS, les Classic Load Balancers définissent l’en-tête sur l'adresse IP privée avec l'interface réseau principale du backend. Ils ont également défini l'agent utilisateur sur ELB-HealthChecker/1.0. Si le backend répond uniquement aux demandes avec un en-tête d'hôte personnalisé ou un agent utilisateur, la demande de surveillance de l'état échoue.
• L'application doit écouter sur l'interface réseau principale du backend. Les Classic Load Balancers se connectent à l'interface réseau principale de l'instance principale. Assurez-vous que l'application écoute sur l'interface réseau principale de l'instance principale. Cela permet au backend d'envoyer une réponse aux demandes de surveillance de l'état.

Réponse « 200 OK » manquante du backend à une demande de surveillance de l'état

• Le chemin de ping doit être valide. Si vous ne configurez pas le fichier spécifié dans le chemin de ping du backend, le backend peut répondre avec 404 Not Found. Cela entraîne l'échec de la surveillance de l'état.
  Remarque : la valeur par défaut du chemin de ping est /index.html. Si vous n'avez pas de fichier index.html sur le backend, créez-en un. Vous pouvez également remplacer la valeur du chemin de ping par un nom de fichier sur le backend.
• Vous n'avez pas correctement configuré la redirection sur le backend. Une redirection mal configurée peut entraîner l'envoi d'un code de réponse 301 ou 302 et l'échec des contrôles de santé. Par exemple, si vous avez une redirection de HTTP/80 vers HTTPS:443 sur le backend, les surveillances de l'état HTTP sur le port 80 échouent. Vous devez remplacer la surveillance de l'état par HTTPS et le port de surveillance de l'état par 443. 
  Remarque : vous pouvez simuler la demande de surveillance de l'état envoyée par l'équilibreur de charge. Utilisez la commande curl suivante à partir d'une instance du sous-réseau associée à l'équilibreur de charge :

  curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page>

Problèmes liés à SSL

• Tous les protocoles et chiffrements doivent correspondre. Pour les surveillances de l'état HTTPS ou SSL, l'équilibreur de charge et le backend doivent utiliser le même protocole et le même chiffrement. Les captures de paquets effectuées sur l'instance principale indiquent les chiffrements et le protocole pris en charge par l'équilibreur de charge. Cela se trouve dans le client hello envoyé par l'équilibreur de charge. L'instance principale enregistrée doit prendre en charge un ou plusieurs chiffrements correspondants et un protocole envoyé par l'équilibreur de charge.
• L'équilibreur de charge n'envoie pas l'en-tête SNI (Server Name Indication) lorsqu'il effectue une surveillance de l'état. Par exemple, la surveillance de l'état est HTTPS/SSL. Si l'instance principale est configurée pour répondre à la liaison SSL en fonction des informations SNI spécifiques, la liaison SSL échoue. Cela est dû au fait que le serveur envoie un RST après le bonjour du client. Configurez le serveur principal pour qu'il réponde quel que soit le SNI. Vous pouvez également utiliser la surveillance de l'état TCP à la place.

Informations connexes

Instances enregistrées pour votre Classic Load Balancer