Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résoudre les problèmes liés à un Classic Load Balancer : surveillance de l'état de santé

Votre équilibreur de charge vérifie l'état de santé de ses instances enregistrées à l'aide de la configuration de surveillance de l'état par défaut fournie par Elastic Load Balancing ou d'une surveillance de l'état personnalisée que vous spécifiez. La configuration de la vérification de l'état contient des informations comme le protocole, le port de ping, le chemin de ping, le délai de réponse et l'intervalle de vérification de l'état. Une instance est considérée comme saine si elle retourne un code de réponse 200 dans l'intervalle de vérification de l'état. Pour de plus amples informations, veuillez consulter Health des instances de votre Classic Load Balancer.

Si l'état actuel de tout ou partie de vos instances est OutOfService et que le champ de description affiche le message Instance has failed at least the Unhealthy Threshold number of health checks consecutively, les instances n'ont pas réussi la vérification de l'état de l'équilibreur de charge. Voici les problèmes à rechercher, les causes potentielles et les étapes que vous pouvez suivre pour résoudre les problèmes.

Erreur de page cible de vérification de l'état

Problème : une demande HTTP GET envoyée à l'instance sur le port de ping et le chemin de ping spécifiés (par exemple, HTTP:80/index.html) reçoit un code de réponse autre que 200.

Cause 1 : aucune page cible n'est configurée sur l'instance.

Solution 1 : créez une page cible (par exemple, index.html) sur chaque instance enregistrée et spécifiez son chemin comme chemin de ping.

Cause 2 : la valeur de l'en-tête Content-Length dans la réponse n'est pas définie.

Solution 2 : si la réponse inclut un corps, définissez la valeur de l'en-tête Content-Length sur une valeur supérieure ou égale à zéro, ou définissez la valeur de Transfer-Encoding sur « chunked ».

Cause 3 : l'application n'est pas configurée pour recevoir des demandes de l'équilibreur de charge ou pour renvoyer un code de réponse 200.

Solution 3 : vérifiez l'application sur votre instance pour enquêter sur la cause.

La connexion aux instances a expiré

Problème : les demandes de bilan de santé envoyées par votre équilibreur de charge à vos EC2 instances arrivent à expiration ou échouent par intermittence.

Tout d'abord, vérifiez le problème en vous connectant directement à l'instance. Nous vous recommandons de vous connecter à votre instance à partir du réseau en utilisant l'adresse IP privée de l'instance.

Utilisez la commande suivante pour une connexion TCP :

telnet private-IP-address-of-the-instance port

Utilisez la commande suivante pour une connexion HTTP ou HTTPS :

curl –I private-IP-address-of-the-instance:port/health-check-target-page

Si vous utilisez une connexion HTTP/HTTPS et obtenez une réponse autre que 200, consultez Erreur de page cible de vérification de l'état. Si vous pouvez vous connecter directement à l'instance, vérifiez les points suivants :

Cause 1 : l'instance ne peut pas répondre dans le délai de réponse configuré.

Solution 1 : ajustez les paramètres de délai de réponse dans la configuration de vérification de l'état de votre équilibreur de charge.

Cause 2 : l'instance est soumise à une charge importante et dépasse votre délai de réponse configuré pour répondre.

Solution 2 :

Cause 3 : si vous utilisez une connexion HTTP ou HTTPS et que la vérification de l'État est effectuée sur une page cible spécifiée dans le champ de chemin de ping (par exemple, HTTP:80/index.html), la page cible peut prendre plus de temps pour répondre que votre délai d'attente configuré.

Solution 3 : utilisez une page cible de vérification de l'état plus simple ou ajustez les paramètres d'intervalle de vérification de l'état.

L'authentification par clé publique échoue

Problème : un équilibreur de charge configuré pour utiliser le protocole HTTPS ou SSL avec l'authentification principale activée ne réussit pas l'authentification par clé publique.

Cause : la clé publique sur le certificat SSL ne correspond pas à la clé publique configurée sur l'équilibreur de charge. Utilisez la commande s_client pour afficher la liste des certificats de serveur dans la chaîne de certificats. Pour de plus amples informations, veuillez consulter s_client dans la documentation OpenSSL.

Solution : vous devez peut-être mettre à jour votre certificat SSL. Si votre certificat SSL est à jour, essayez de le réinstaller sur votre équilibreur de charge. Pour de plus amples informations, veuillez consulter Remplacer le certificat SSL pour votre Classic Load Balancer.

L'instance ne reçoit pas le trafic provenant de l'équilibreur de charge

Problème : le groupe de sécurité pour l'instance bloque le trafic provenant de l'équilibreur de charge.

Effectuez une capture de paquet sur l'instance pour vérifier le problème. Utilisez la commande suivante :

# tcpdump port health-check-port

Cause 1 : le groupe de sécurité associé à l'instance n'autorise pas le trafic provenant de l'équilibreur de charge.

Solution 1 : modifiez le groupe de sécurité de l'instance pour autoriser le trafic provenant de l'équilibreur de charge. Ajoutez une règle pour autoriser tout le trafic à partir du groupe de sécurité de l'équilibreur de charge.

Cause 2 : le groupe de sécurité de votre équilibreur de charge n'autorise pas le trafic vers les EC2 instances.

Solution 2 : modifiez le groupe de sécurité de votre équilibreur de charge pour autoriser le trafic vers les sous-réseaux et les EC2 instances.

Pour plus d'informations sur la gestion des groupes de sécurité, consultez Configurer des groupes de sécurité pour votre Classic Load Balancer.

Des ports sur l'instance ne sont pas ouverts

Problème : le bilan de santé envoyé à l' EC2 instance par l'équilibreur de charge est bloqué par le port ou un pare-feu.

Vérifiez le problème en utilisant la commande suivante :

netstat –ant

Cause : le port de vérification de l'état ou le port d'écouteur spécifié (s'ils sont configurés différemment) n'est pas ouvert. Les ports spécifiés pour la vérification de l'état et le port d'écoute doivent être ouverts et à l'écoute.

Solution : ouvrez le port d'écoute et le port spécifié dans votre configuration de vérification de l'état (s'ils sont configurés différemment) sur vos instances pour recevoir le trafic de l'équilibreur de charge.

Les instances d'un groupe Auto Scaling ne réussissent pas la surveillance de l'état ELB

Problème : les instances de votre groupe Auto Scaling réussissent la surveillance de l'état Auto Scaling par défaut, mais pas la surveillance de l'état ELB.

Cause : Auto Scaling utilise des contrôles d' EC2 état pour détecter les problèmes matériels et logiciels liés aux instances, mais l'équilibreur de charge effectue des contrôles de santé en envoyant une demande à l'instance et en attendant un code de réponse 200, ou en établissant une connexion TCP (pour un contrôle de santé basé sur le protocole TCP) avec l'instance.

Une instance peut ne pas réussir la vérification de l'état ELB, parce qu'une application s'exécutant sur l'instance connaît des problèmes faisant que l'équilibreur de charge considère l'instance comme étant hors service. Cette instance peut passer avec succès le test de santé Auto Scaling ; elle ne sera pas remplacée par la politique Auto Scaling car elle est considérée comme saine sur la base du contrôle de EC2 statut.

Solution : utilisez la surveillance de l'état ELB pour votre groupe Auto Scaling. Lorsque vous utilisez la surveillance de l'état ELB, Auto Scaling détermine l'état de santé de vos instances en vérifiant les résultats de la surveillance de l'état de l'instance et de la surveillance de l'état ELB. Pour plus d'informations, consultez la section Ajouter les contrôles de santé d'Elastic Load Balancing à votre groupe Auto Scaling dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.