Comment dépanner et réparer les surveillances de l'état défaillantes pour Classic Load Balancer ?

Date de la dernière mise à jour : 08/06/2018

Une ou plusieurs instances derrière my Classic Load Balancer ont échoué aux surveillances de l'état. Quelles sont les causes potentielles de ces échecs et comment puis-je y remédier ?

Brève description

Elastic Load Balancing (ELB) prend en charge Application Load Balancers, Network Load Balancers et Classic Load Balancers. Les instances exécutées sur des Classic Load Balancer peuvent échouer aux surveillances de l'état pour les raisons suivantes :

  • Problèmes de connectivité entre l'équilibreur de charge et le backend
  • Problèmes de configuration de l'application
  • Absence de réponse « 200 OK » du backend pour la demande de surveillance de l'état
  • Problèmes avec SSL, qui provoquent l'échec des surveillances de l'état de HTTPS ou SSL

Solution

Pour dépanner et résoudre les problèmes liés à la surveillance de l'état, procédez comme suit :

Remédiez aux problèmes de connectivité potentiels entre votre équilibreur de charge et votre backend

Assurez-vous des éléments suivants :

  • Le backend autorise le trafic de surveillance de l'état. Pour vérifier vos règles de groupe de sécurité, consultez Règles recommandées pour les groupes de sécurité des équilibreurs de charge. Pour l'instance backend, consultez Groupes de sécurité pour les instances dans un VPC.
  • La liste de contrôle d'accès (ACL) pour le sous-réseau avec l'équilibreur de charge ou le backend autorise le trafic de surveillance de l'état. Pour vérifier les règles ACL pour le sous-réseau avec l'équilibreur de charge et le backend, consultez ACL réseau pour des équilibreurs de charge dans un VPC.
  • Les pare-feu de niveau instance ou système d'exploitation sur le backend permettent le trafic de surveillance de l'état. Assurez-vous que les pare-feu de niveau instance ou système d'exploitation sur le backend autorisent l'entrée et la sortie du trafic de surveillance de l'état.
  • Les ressources de l'instance backend ne sont pas utilisées de manière excessive. Assurez-vous que l'utilisation de la mémoire et de l'UC respecte les limites acceptables. Si l'utilisation de la mémoire ou de l'UC est trop élevée, ajoutez des backends supplémentaires ou mettez à jour les backends vers un type d'instance plus grande.
  • Toutes les ressources supplémentaires autorisent le trafic de surveillance de l'état. La demande de surveillance de l'état doit être transmise à une ressource supplémentaire par le backend. Si la dépendance supplémentaire de répond pas ou tarde trop à répondre, la surveillance de l'état échoue ou son délai expire. Vérifiez que la ressource supplémentaire répond à la demande de surveillance de l'état.

Résolvez les problèmes potentiels de configuration liés à votre application

  • 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 confirmer qu'Apache est en cours d'exécution.
  • L'application écoute sur le port de surveillance de l'état. Pour confirmer que le serveur est en état d'écoute sur le port de surveillance de l'état, exécutez la commande netstat -ant sur le serveur. Vérifiez que le port de configuration de l'application 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 « Connected » (Connectée), le backend écoute sur le port de surveillance de l'état.
  • L'application est configurée pour répondre aux demandes avec un en-tête hôte personnalisé. Pour les surveillances de l'état HTTP et HTTPS, les classic Load Balancer configurent l'en-tête sur l'adresse IP privée avec l'interface réseau principale du backend et l'agent utilisateur sur « ELB-HealthChecker/1.0 ». Si le backend ne répond qu'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 écoute l'interface de réseau principal du backend. Les Classic Load Balancers se connectent à l'interface réseau principale de l'instance backend. Soyez assuré que l'application écoute l'interface réseau principale de l'instance backend, autorisant le backend à envoyer une réponse aux demandes de surveillance de l'état.

Absence de réponse « 200 OK » du backend pour la demande de surveillance de l'état

Assurez-vous des éléments suivants :

  • Le chemin de ping est valide. Si le fichier spécifié dans le chemin de ping n'est pas configuré sur le backend, le backend risque de répondre avec un code de réponse « 404 Not Found » (404 Introuvable) et la surveillance de l'état échouera. Remarque : la valeur par défaut du chemin ping est /index.html. Si vous n'avez pas de fichier index.html sur le backend, créez-en un ou changez la valeur du chemin ping avec un nom de fichier sur le backend.
  • La redirection n'est pas configurée sur le backend. La redirection configurée sur le backend peut aboutir à un code de réponse 301 ou 302, ce qui se traduit par l'échec des surveillances de l'état. 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, sauf si vous modifiez la surveillance de l'état sur HTTPS et le port de surveillance de l'état sur 443. Remarque : vous pouvez simuler la demande de surveillance de l'état envoyée par l'équilibreur de charge à l'aide de la commande curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page> à partir de l'instance dans le sous-réseau qui est associé à l'équilibreur de charge.

Résolvez les problèmes concernant SSL

Assurez-vous des éléments suivants :

  • Tous les protocoles et les chiffrements correspondent. 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 Packet prises sur l'instance backend affichent les chiffrements et protocoles pris en charge sur l'équilibreur de charge dans la commande hello client envoyée par l'équilibreur de charge. L'instance backend enregistrée doit prendre en charge au moins un chiffrement correspondant et un protocole envoyé par l'équilibreur de charge.
  • L'identification de nom de serveur (SNI) n'est pas activée sur le serveur backend. Si la surveillance de l'état est HTTPS/SSL et que SNI est activé sur l'instance backend, l'équilibreur de charge et le backend ne peuvent pas établir de négociation SSL. Cela vient du fait que le serveur backend envoie un RST après la commande hello client. Désactivez le SNI ou utilisez les surveillances de l'état TCP à la place.

Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?