Pregunta Servicio AWS ELB Apache2 503 no disponible: el servidor de servicios de fondo está a plena capacidad


Hemos estado ejecutando un par de sitios web fuera de la infraestructura de Amazon AWS durante aproximadamente dos años y desde hace aproximadamente dos días el servidor web comenzó a fallar una o dos veces al día con el único error que puedo encontrar:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch no está activando alarmas (CPU / Disk IO / DB Conn). Intenté ir al sitio a través del IP elástico para omitir el ELB y obtuve esto:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

No veo nada fuera de lo común en los registros de Apache y verificé que estaban siendo rotados correctamente. No tengo problemas para acceder a la máquina cuando está "inactiva" a través de SSH y al ver la lista de procesos, veo 151 procesos apache2 que me parecen normales. Reiniciar Apache arregla temporalmente el problema. Esta máquina funciona como un servidor web detrás de un ELB. Cualquier sugerencia sería muy apreciada.

Utilización de CPU       Promedio: 7.45%, Mínimo: 0.00%, Máximo: 25.82%

Utilización de la memoria       Promedio: 11.04%, Mínimo: 8.76%, Máximo: 13.84%

Utilización de swaps       Promedio: N / A, Mínimo: N / A, Máximo: N / A

Utilización del espacio en disco para / dev / xvda1 montado en /       Promedio: 62.18%, Mínimo: 53.39%, Máximo: 65.49%

Permítanme aclarar que creo que el problema está en la instancia individual de EC2 y no en el ELB. No quería descartar eso aunque no pude alcanzar la IP elástica. Sospecho que ELB simplemente está devolviendo los resultados de golpear la instancia EC2 real.

Actualización: 2014-08-26 Debería haber actualizado esto antes, pero la "solución" era tomar una instantánea de la instancia "incorrecta" e iniciar el AMI resultante. No ha bajado desde entonces. Miré el chequeo de salud cuando aún tenía problemas y pude acceder a la página de chequeo de salud (curl http://localhost/page.html) incluso cuando recibía problemas de capacidad del equilibrador de carga. No estoy convencido de que se tratara de un problema de control de salud, pero como nadie, incluida Amazon, puede proporcionar una mejor respuesta, la estoy marcando como la respuesta. Gracias.

Actualización: 2015-05-06 Pensé que volvería aquí y diría que parte del problema que ahora creo firmemente era la configuración del control de estado. No quiero descartar que sean un problema con el AMI porque definitivamente mejoró después de que se lanzó el AMI de reemplazo, pero descubrí que nuestros controles de salud eran diferentes para cada balanceador de carga y que el que tenía más problemas Tenía un umbral inseguro realmente agresivo y un tiempo de espera de respuesta. Nuestro tráfico tiende a aumentar de manera impredecible y creo que entre los ajustes agresivos de control de salud y los aumentos en el tráfico fue una tormenta perfecta. Al diagnosticar el problema, me centré en el hecho de que podía alcanzar el punto final del control de estado en este momento, pero es posible que el control de estado haya fallado debido a la latencia y luego tuviéramos un umbral de salud alto (para ese ELB en particular), por lo que Tómese un tiempo para ver la instancia como sana de nuevo.


36
2017-11-21 21:03


origen


He encontrado más información sobre en: meta.discourse.org/t/… - Andre Mesquita


Respuestas:


Obtendrá un "El servidor de servicios de fondo está a capacidad" cuando el equilibrador de carga ELB realice sus comprobaciones de estado y reciba una "página no encontrada" (u otro error simple) debido a una configuración incorrecta (normalmente con el host NameVirtual).

Intente abrir la carpeta de archivos de registro utilizando el agente de usuario "ELB-HealthChecker". p.ej.

grep ELB-HealthChecker  /var/log/httpd/*

Esto normalmente le dará un error de 4x o 5x que se soluciona fácilmente. p.ej. Inundaciones, MaxClients, etc. está dando demasiado crédito al problema.

FYI Amazon: ¿Por qué no mostrar la respuesta devuelta de la solicitud? Incluso un código de estado ayudaría.


37
2018-02-10 23:28





Acabo de encontrarme con este problema. Amazon ELB devolverá este error si no hay instancias sanas. Nuestros sitios estaban mal configurados, por lo que la comprobación de estado de ELB estaba fallando, lo que provocó que ELB eliminara la rotación de los dos servidores. Con cero sitios en buen estado, el ELB devolvió 503 Servicio no disponible: el servidor back-end está en capacidad.


17
2017-08-14 16:02





[EDITAR después de entender mejor la pregunta] Al no tener ninguna experiencia con el ELB, sigo pensando que esto suena sospechosamente como el error 503 que puede producirse cuando Apache se enfrenta a un Tomcat e inunda la conexión.

El efecto es que si Apache entrega más solicitudes de conexión que las que pueden ser procesadas por el backend, las colas de entrada del backend se llenan hasta que no se puedan aceptar más conexiones. Cuando eso sucede, las colas de salida correspondientes de Apache comienzan a llenarse. Cuando las colas están llenas, Apache lanza un 503. Se seguiría lo mismo cuando Apache es el backend, y el frontend se entrega a una velocidad tal que hace que las colas se llenen.

La solución (hipotética) es dimensionar los conectores de entrada del backend y los conectores de salida del frontend. Esto se convierte en un acto de equilibrio entre el nivel de inundación previsto y la RAM disponible de las computadoras involucradas.

Entonces, cuando esto suceda, verifique la configuración de maxclients y monitoree a sus trabajadores ocupados en Apache (mod_status). Haga lo mismo, si es posible, con lo que sea que tenga ELB que corresponda a la acumulación de conectores Tomcats, maxthreads, etc. En resumen, observe todo lo relacionado con las colas de entrada de Apache y las colas de salida de ELB.

Aunque entiendo perfectamente que no es directamente aplicable, este enlace contiene una guía de tamaño para el conector Apache. Necesitará investigar los aspectos técnicos de la cola de ELB correspondientes, luego hacer los cálculos: http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-on-tomcat-during-full-gc/

Como se observa en el comentario a continuación, para abrumar al conector de Apache, un aumento en el tráfico no es la única posibilidad. Si algunas solicitudes se atienden más lentamente que otras, una proporción mayor de ellas también puede provocar que las colas del conector se llenen. Esto fue cierto en mi caso.

Además, cuando esto me sucedió, me sorprendió que tuviera que reiniciar el servicio de Apache para no recibir 503: s nuevamente. Simplemente esperar que la inundación del conector no fuera suficiente. Nunca me di cuenta de eso, pero ¿se puede especular en el servicio de Apache desde su caché?

Después de aumentar el número de trabajadores y la configuración correspondiente de maxclients antes de la bifurcación (este fue un Apache multihilo en Windows que tiene un par de otras directivas para las colas si recuerdo bien), el problema 503 desapareció. En realidad no hice los cálculos matemáticos, pero solo ajusté los valores hasta que pude observar un amplio margen para el consumo máximo de los recursos de la cola. Lo dejo en eso.

Espero que esto haya sido de alguna ayuda.


5
2017-11-21 21:29



Acabo de darme cuenta de que estás escribiendo que Apache es tu backend. Aún así, los trabajadores, maxclients, etc. jugarían, supongo, sin embargo, mi respuesta es demasiado incorrecta y necesita una reescritura completa. Puedo borrarlo en su lugar. Lección aprendida: lea la pregunta correctamente. - ErikE
Gracias. Para que este sea el caso, ¿tendría que haber un gran aumento en el tráfico? ¿Y una vez dicho el tráfico disminuido no debería apache poder recuperarse? - JSP
En teoría, sí. Sin embargo, cuando esto me sucedió tuve que reiniciar el servicio. Esto me llevó a buscar primero en lugares que no tenían nada que ver con lo que realmente sucedió, pero incluso después de un diagnóstico y una cura adecuados todavía no he podido entender la necesidad de reiniciar el servicio. Silenciosamente sospeché que se debía a la ejecución de Apache en Windows, ya que encontré una referencia de error no relacionada que aparentemente solo surgió con ese combo. Muy extraño en cualquier caso. - ErikE
Y sí, hubo un tráfico que abrumó a los conectores, no espigados (para nosotros) sino demasiado. Era más bien ciertas peticiones que eran más lentas de atender y que en ocasiones eran demasiadas. Después de monitorear un poco y solo aumentar los valores relacionados, los 503 desaparecieron junto con la necesidad de reinicios posteriores. - ErikE


puede aumentar los valores del comprobador de estado de Elb, por lo que, como una sola respuesta lenta, no extraerá un servidor de Elb. Es mejor que algunos usuarios obtengan el servicio no disponible, que el sitio no esté disponible para todos.

EDITAR: Podemos escapar sin precalentar el caché aumentando el tiempo de espera de control de salud a 25 segundos ... después de 1-2 minutos ... el sitio responde como el infierno

EDITAR: simplemente lance un montón de aplicaciones a pedido, y cuando sus herramientas de monitoreo muestren a la gerencia qué tan rápido son, entonces prepague RI amazon: P

EDITAR: es posible, una única instancia registrada de backb elb no es suficiente. simplemente lance unos cuantos más y regístrelos con elb, y eso lo ayudará a reducir su problema


4
2017-11-21 21:57





Es un poco tarde, pero espero que esto ayude a alguien.

Estaba viendo este error cuando la instancia detrás de ELB no tenía asignada una IP pública adecuada. Necesitaba crear manualmente una IP elástica y asociarla con la instancia después de la cual el ELB la detectó casi al instante.


0
2017-08-05 02:36