Pourquoi Elastic Load Balancing indique-t-il “Hors service”?

J’essaie de configurer Elastic Load Balancing (ELB) dans AWS pour séparer les requêtes entre plusieurs instances. J’ai créé plusieurs images de mon serveur Web basées sur la même AMI, et je suis en mesure d’y accéder individuellement et d’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 l’ Status: Out of Service car elles ont échoué à la vérification de l’état de santé. Je suis le plus souvent confus car je peux accéder à chaque instance à partir de son DNS public, mais j’obtiens un délai d’attente lorsque je visite le nom DNS de l’équilibreur de charge.

J’ai essayé de lire tous les documents et de le 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 gérer les cas où toutes les instances situées 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.

    Le correctif suggéré permet de désenregistrer les instances ec2 de l’ELB au lieu de les arrêter et de les réenregistrer lorsque vous recommencez.

    La vérification de l’intégrité est effectuée (par défaut) en accédant à index.html sur chaque instance incorporée dans l’équilibreur de charge. Si vous n’avez pas index.html dans la racine du document, 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 eu ce travail. Le problème concernait les groupes Amazon Security , car je restreignais l’access au port 80 à quelques machines 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 access à mon instance, il entre en 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 tentait d’accéder à mon serveur et voir la réponse que le serveur donne à l’équilibreur de charge.

    J’espère que cela t’aides.

    Si votre serveur Web fonctionne correctement, cela signifie que le bilan de santé passe par une URL qui ne renvoie pas 200.

    Un truc qui fonctionne pour moi: allez sur l’instance, tapez curl localhost: 80 / pathofyourhealthcheckurl

    Après vous pouvez adapter votre URL de contrôle de santé pour toujours avoir une réponse 200.

    Dans mon cas, les règles sur les groupes de sécurité affectés à l’instance et à l’équilibreur de charge n’autorisaient pas le passage du trafic entre les deux. Cela a provoqué l’échec du bilan de santé.

    J’ai fait face au même problème, j’ai changé le protocole Ping de https à SSL .. cela a fonctionné!

     Allez dans Health Check -> cliquez sur Edit Health Check -> changez le protocole Ping de HTTPS à SSL
    
     Cible de Ping SSL: 443
     Délai d'attente 5 secondes
     Intervalle 30 secondes
     Seuil malsain 5
     Seuil de santé 10
    

    Je voudrais vous fournir un moyen général de résoudre ce problème. Lorsque vous avez configuré votre serveur Web comme apache ou nginx, essayez de lire le fichier journal d’access pour voir ce qui s’est passé. Dans mon cas, il signale une 401 error car j’ai ajouté l’authentification de base dans nginx. Bien sûr, comme le rappelle @ivankoni, il se peut que le document que vous vérifiez n’existe pas.

    Je travaillais sur le didacticiel AWS sur l’hébergement d’une application Web et j’ai rencontré ce problème. L’étape 7b indique ce qui suit:

    “Définissez le chemin Ping sur /. Cela envoie des requêtes à votre page par défaut, qu’elle soit appelée index.html ou autre chose.”

    Ils auraient pu mettre la barre oblique dans des citations comme celle-ci “/”. Assurez-vous que vous avez cela dans vos bilans de santé et non pas ce “/”. .

    En ajoutant cela parce que j’ai passé des heures à essayer de le comprendre …

    Si vous avez configuré votre sharepoint terminaison de vérification d’intégrité mais qu’il est toujours Out of Service , cela peut être dû au fait que votre serveur redirige la demande (c.-à-d. En renvoyant une réponse 301 ou 302 ).

    Par exemple, si votre ordinateur d’extrémité est supposé être /app/health/ mais que vous entrez uniquement /app/health (aucune barre oblique de fin) dans le champ de sharepoint contrôle de santé de votre ELB, vous ne recevrez pas de réponse 200. va échouer.

    J’ai eu un problème similaire. Le problème semble avoir été causé par l’utilisation d’un test de santé HTTP et par l’utilisation de .htaccess pour protéger le site par mot de passe.