Pourquoi Elastic Load Balancing signale-t-il "Hors service"?
J'essaie de configurer Elastic Load Balancing (ELB) dans AWS pour fractionner les demandes entre plusieurs instances. J'ai créé plusieurs images de mon serveur Web basées sur la même AMI, et je peux les insérer individuellement et accéder au site via chaque DNS public distinct.
J'ai ajouté chacune de mes instances à l'équilibreur de charge, mais elles reviennent toutes avec le Status: Out of Service car elles ont échoué à la vérification de l'état. Je suis surtout dérouté parce que je peux accéder à chaque instance à partir de son DNS public, mais le délai imparti à chaque visite du nom DNS de l'équilibreur de charge est dépassé.
J'ai essayé de lire tous les documents et de googler, mais je suis coincé. Tout pointeur ou lien dans la bonne direction serait grandement apprécié.
J'ai contacté le support AWS à propos de ce même problème. Apparemment, leur système ne sait pas comment traiter les cas où toutes les instances derrière l'ELB sont arrêtées pendant une période prolongée. Le support AWS peut actualiser manuellement les statuts, si vous en avez besoin immédiatement.
La solution suggérée est de supprimer les instances ec2 de l'ELB au lieu de simplement les arrêter et de les réenregistrer à nouveau.
Le contrôle d'intégrité est effectué (par défaut) en accédant à index.html sur chaque instance intégrée à l'équilibreur de charge. Si vous n'avez pas index.html dans la racine du document d'instance, la vérification de l'état par défaut échouera. Vous pouvez définir un protocole, un port et un chemin personnalisés pour la vérification de l'intégrité lors de la création d'un équilibreur de charge élastique.
Finalement, j'ai réussi. Le problème venait de Amazon Security Groups , car l'accès au port 80 était limité à quelques ordinateurs de ma zone de développement et l'équilibreur de charge ne pouvait pas accéder au serveur Apache sur l'instance. Une fois que l'équilibreur de charge a eu accès à mon instance, il reçoit In Service .
Je l'ai vérifié avec tail -f /var/log/Apache2/access.log dans mon instance, pour vérifier si l'équilibreur de charge essayait d'accéder à mon serveur et pour voir la réponse fournie par le serveur à l'équilibreur de charge.
J'espère que cela t'aides.
Si votre serveur Web fonctionne correctement, cela signifie que la vérification de l'état de santé est effectuée sur une URL qui ne renvoie pas 200.
Un truc qui fonctionne pour moi: allez sur l’instance, tapez curl localhost: 80/pathofyourhealthcheckurl
Après que vous puissiez adapter votre URL de vérification de santé pour toujours avoir une réponse 200.
Dans mon cas, les règles relatives aux groupes de sécurité affectés à l'instance et à l'équilibreur de charge ne permettaient pas le trafic entre les deux. Cela a entraîné l'échec de la vérification de l'état de santé.
J'ai fait face au même problème, j'ai changé le protocole Ping de https à ssl .. ça a marché !
Allez à Health Check -> cliquez sur Edit Health Check -> changez le protocole Ping de HTTPS à SSL
Ping Target SSL: 443 Délai d'attente 5 secondes Intervalle 30 secondes Seuil malsain 5 Seuil sain 10
Ajoutant cela parce que j'ai passé des heures à essayer de comprendre ...
Si vous avez configuré votre point de terminaison de vérification d'intégrité mais que le nom est toujours Out of Service, c'est peut-être parce que votre serveur redirige la demande (c'est-à-dire qu'il renvoie une réponse 301 ou 302).
Par exemple, si votre point de terminaison est censé être /app/health/ mais que vous entrez uniquement /app/health (sans barre oblique) dans le champ du point de terminaison de vérification de l'intégrité de votre ELB, vous n'obtiendrez pas une réponse 200;.
J'ai eu la même erreur, dans mon cas, j'ai dû copier le fichier HTML particulier du compartiment s3 vers l'emplacement "/ var/www/html". Le même code HTML référencé dans le chemin de l'équilibreur de charge.
Le problème résolu après la copie du fichier html.
J'ai eu un problème similaire. Le problème semble avoir été causé par l'utilisation d'un contrôle d'intégrité HTTP et l'utilisation de .htaccess pour protéger le site par mot de passe.
Je travaillais sur le didacticiel AWS sur l'hébergement d'une application Web et j'ai rencontré ce problème. Étape 7b indique ce qui suit:
"Définir le chemin d'accès de ping sur /. Ceci envoie des requêtes à votre page par défaut, qu'elle s'appelle Ou non."
Ils auraient pu mettre la barre oblique entre guillemets comme ceci "/". Assurez-vous que cela figure dans vos bilans de santé et non pas "/". .
Je voudrais vous fournir un moyen général de résoudre ce problème. Lorsque vous avez configuré votre serveur Web tel qu'Apache ou nginx, essayez de lire le fichier journal d'accès pour voir ce qui s'est passé. Dans mon cas, il rapporte 401 error parce que j'ai ajouté l'authentification de base dans nginx. Bien sûr, comme @ivankoni le rappelle, il se peut que le document que vous vérifiez n’existe pas.