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 HTTP GET demande envoyée à l'instance sur le port ping spécifié et le chemin ping (par exemple, :80/index.htmlHTTP) 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 TCP établir une connexion :

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

Utilisez la commande suivante pour une HTTPS connexion HTTP ou :

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

Si vous utilisez une HTTPS connexionHTTP/et que vous obtenez une réponse autre que 200, consultezErreur 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 une HTTPS connexion et que le contrôle de santé est effectué sur une page cible spécifiée dans le champ du chemin ping (par exemple,HTTP:80/index.html), la page cible met peut-être plus de temps à répondre que le 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 SSL protocole HTTPS OR avec l'authentification principale activée échoue à l'authentification par clé publique.

Cause : La clé publique du SSL certificat 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 plus d'informations, consultez s_client dans la SSL documentation Open.

Solution : il se peut que vous deviez mettre à jour votre SSL certificat. Si votre SSL certificat est à jour, essayez de le réinstaller sur votre équilibreur de charge. Pour de plus amples informations, veuillez consulter Remplacez le SSL certificat de 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'EC2instance 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 passent pas le ELB test de santé

Problème : les instances de votre groupe Auto Scaling passent avec succès le test de santé Auto Scaling par défaut mais échouent au ELB test de santé.

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 TCP connexion (pour un contrôle de santé TCP basé) avec l'instance.

Une instance peut échouer au contrôle de ELB santé car une application exécutée sur l'instance présente des problèmes qui amènent l'équilibreur de charge à considérer 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 le bilan ELB de santé de votre groupe Auto Scaling. Lorsque vous utilisez le bilan de ELB santé, Auto Scaling détermine l'état de santé de vos instances en vérifiant les résultats du contrôle de l'état de l'instance et du ELB bilan de santé. Pour plus d'informations, consultez Ajouter des bilans de santé à votre groupe Auto Scaling dans le guide de l'utilisateur d'Amazon EC2 Auto Scaling.