Service AWS ELB Apache2 503 non disponible: le serveur principal est à pleine capacité
Nous exploitons quelques sites Web depuis l'infrastructure Amazons AWS depuis environ deux ans maintenant et il y a environ deux jours, le serveur Web a commencé à tomber une ou deux fois par jour avec la seule erreur que je puisse trouver étant:
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatch ne déclenche aucune alarme (CPU/Disk IO/DB Conn). J'ai essayé d'aller sur le site via l'IP élastique pour sauter l'ELB et j'ai obtenu ceci:
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Je ne vois rien d'extraordinaire dans les journaux Apache et j'ai vérifié qu'ils étaient correctement tournés. Je n'ai aucun problème à accéder à la machine lorsqu'elle est "en panne" via SSH et en regardant la liste des processus, je vois 151 processus Apache2 qui me semblent normaux. Le redémarrage d'Apache résout temporairement le problème. Cette machine fonctionne comme un simple serveur Web derrière un ELB. Toutes les suggestions seraient grandement appréciées.
Moyenne d'utilisation du processeur: 7,45%, Minimum: 0,00%, Maximum: 25,82%
Moyenne d'utilisation de la mémoire: 11,04%, Minimum: 8,76%, Maximum: 13,84%
Moyenne d'utilisation du swap: N/A, Minimum: N/A, Maximum: N/A
Utilisation de l'espace disque pour/dev/xvda1 monté sur/Moyenne: 62,18%, Minimum: 53,39%, Maximum: 65,49%
Permettez-moi de préciser que je pense que le problème est lié à l'instance EC2 individuelle et non à l'ELB que je ne voulais tout simplement pas exclure, même si je n'ai pas pu atteindre l'IP élastique. Je soupçonne que ELB ne fait que renvoyer les résultats de la frappe de l'instance EC2 réelle.
Mise à jour: 2014-08-26 J'aurais dû mettre à jour cela plus tôt mais le "correctif" consistait à prendre un instantané de la "mauvaise" instance et à démarrer l'AMI résultante. Il n'a pas baissé depuis. J'ai consulté le bilan de santé alors que je rencontrais toujours des problèmes et j'ai pu accéder à la page du bilan de santé (curl http://localhost/page.html) même lorsque j'obtenais des problèmes de capacité de l'équilibreur de charge. Je ne suis pas convaincu que c'était un problème de bilan de santé, mais comme personne, y compris Amazon, ne peut fournir une meilleure réponse, je le marque comme réponse. Je vous remercie.
Mise à jour: 2015-05-06 Je pensais revenir ici et dire qu'une partie du problème que je crois maintenant fermement était les paramètres du bilan de santé. Je ne veux pas exclure qu'ils soient un problème avec l'AMI car cela s'est définitivement amélioré après le lancement de l'AMI de remplacement, mais j'ai découvert que nos contrôles de santé étaient différents pour chaque équilibreur de charge et que celui qui avait le plus de problèmes avait un seuil malsain vraiment agressif et un délai de réponse. Notre trafic a tendance à augmenter de façon imprévisible et je pense qu'entre les paramètres de contrôle de santé agressifs et les pics de trafic, c'était une tempête parfaite. En diagnostiquant le problème, je me suis concentré sur le fait que je pouvais atteindre le point de terminaison du bilan de santé pour le moment, mais il est possible que le bilan de santé ait échoué en raison de la latence, puis nous avions un seuil de santé élevé (pour cette ELB particulière), de sorte qu'il le ferait prenez le temps de voir l'instance comme étant à nouveau en bonne santé.
Vous obtiendrez un "serveur principal à capacité" lorsque l'équilibreur de charge ELB effectue ses vérifications de l'état et reçoit une "page introuvable" (ou une autre erreur simple) en raison d'une mauvaise configuration (généralement avec l'hôte NameVirtual).
Essayez de récupérer le dossier des fichiers journaux à l'aide de l'agent utilisateur "ELB-HealthChecker". par exemple.
grep ELB-HealthChecker /var/log/httpd/*
Cela vous donnera généralement une erreur 4x ou 5x qui est facilement corrigée. par exemple. Les inondations, MaxClients, etc. donnent trop de crédit au problème.
Pour info Amazon: Pourquoi ne pas montrer la réponse retournée de la demande? Même un code d'état aiderait.
Je viens de rencontrer ce problème moi-même. Amazon ELB renverra cette erreur s'il n'y a pas d'instances saines. Nos sites ont été mal configurés, de sorte que le contrôle de santé ELB échouait, ce qui a entraîné la suppression de rotation des deux serveurs par ELB. Avec zéro site sain, l'ELB a renvoyé le service 503 non disponible: le serveur principal est à pleine capacité.
[EDIT après avoir mieux compris la question] N'ayant aucune expérience de l'ELB, je pense toujours que cela ressemble étrangement à l'erreur 503 qui peut être lancée quand Apache fait face à un Tomcat et inonde la connexion.
L'effet est que si Apache fournit plus de demandes de connexion que ce qui peut être traité par le backend, les files d'attente d'entrée du backend se remplissent jusqu'à ce qu'aucune autre connexion ne puisse être acceptée. Lorsque cela se produit, les files d'attente de sortie correspondantes d'Apache commencent à se remplir. Lorsque les files d'attente sont pleines, Apache lance un 503. Il s'ensuit que la même chose peut se produire lorsque Apache est le backend et que le frontend délivre à un rythme tel que les files d'attente se remplissent.
La solution (hypothétique) consiste à dimensionner les connecteurs d'entrée du backend et les connecteurs de sortie du frontend. Cela se transforme en un équilibre entre le niveau d'inondation prévu et le RAM des ordinateurs impliqués).
Donc, dans ce cas, vérifiez vos paramètres maxclients et surveillez vos employés occupés dans Apache (mod_status.). Faites de même si possible avec tout ce que ELB a qui correspond au backlog du connecteur Tomcats, maxthreads etc. En bref, regardez tout ce qui concerne les files d'attente d'entrée d'Apache et les files d'attente de sortie d'ELB.
Bien que je comprenne parfaitement qu'il n'est pas directement applicable, ce lien contient un guide de dimensionnement pour le connecteur Apache. Vous devrez rechercher les détails techniques de la file d'attente ELB correspondante, puis faire le calcul: http://www.cubrid.org/blog/dev-platform/maxclients-in-Apache-and-its-effect-on- Tomcat-pendant-full-gc /
Comme observé dans le commentaire ci-dessous, pour submerger le connecteur Apache, un pic de trafic n'est pas la seule possibilité. Si certaines demandes sont traitées plus lentement que d'autres, un ratio plus élevé peut également entraîner le remplissage des files d'attente de connecteurs. C'était vrai dans mon cas.
De plus, lorsque cela m'est arrivé, j'ai été déconcerté de devoir redémarrer le service Apache afin de ne plus recevoir 503: s. Il ne suffit pas d'attendre l'inondation du connecteur. Je n'ai jamais compris cela, mais peut-on spéculer sur le service Apache à partir de son cache peut-être?
Après avoir augmenté le nombre de travailleurs et les paramètres maxclients pré-fork correspondants (c'était Apache multithread sur Windows qui a quelques autres directives pour les files d'attente si je me souviens bien), le problème 503 a disparu. En fait, je n'ai pas fait le calcul, mais j'ai juste ajusté les valeurs jusqu'à ce que je puisse observer une large marge à la consommation de pointe des ressources de file d'attente. Je l'ai laissé faire.
J'espère que cela vous a été utile.
vous pouvez augmenter les valeurs du vérificateur de santé elb, de sorte qu'une seule réponse lente ne tirera pas un serveur d'elb. il vaut mieux que quelques utilisateurs obtiennent un service indisponible, que le site soit hors service pour tout le monde.
EDIT: Nous pouvons nous éloigner sans préchauffer le cache en augmentant le délai de vérification de la santé à 25 secondes ...... après 1-2 minutes ... le site est réactif comme l'enfer
EDIT :: lancez juste un tas de sur demande, et quand vos outils de surveillance montrent à la gestion à quelle vitesse vous êtes, alors pré-payez RI Amazon: P
EDIT: c'est possible, une seule instance enregistrée de backb elb ne suffit pas. lancez-en quelques autres et enregistrez-les avec elb, et cela vous aidera à affiner votre problème
C'est quelques années de retard, mais j'espère que cela aide quelqu'un.
Je voyais cette erreur lorsque l'instance derrière l'ELB n'avait pas de bonne IP publique assignée. Je devais créer manuellement une adresse IP élastique et l'associer à l'instance, après quoi l'ELB la récupérait presque instantanément.