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 activa alarmas (CPU / Disk IO / DB Conn). Intenté ir al sitio a través de la IP elástica 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 verifiqué que se estaban rotando correctamente. No tengo problemas para acceder a la máquina cuando está "inactiva" a través de SSH y al mirar la lista de procesos veo 151 procesos apache2 que me parecen normales. Reiniciar apache soluciona temporalmente el problema. Esta máquina funciona como un servidor web detrás de un ELB. Cualquier sugerencia sería muy apreciada.
Promedio de utilización de CPU: 7.45%, mínimo: 0.00%, máximo: 25.82%
Uso de memoria Promedio: 11.04%, Mínimo: 8.76%, Máximo: 13.84%
Intercambio de utilización Promedio: N / A, Mínimo: N / A, Máximo: N / A
Utilización de 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 es con la instancia individual de EC2 y no con el ELB. Simplemente no quería descartarlo a pesar de que no pude alcanzar la IP elástica. Sospecho que ELB solo 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" fue tomar una instantánea de la instancia "mala" e iniciar el AMI resultante. No ha bajado desde entonces. Observé la comprobación de estado cuando aún experimentaba problemas y podía acceder a la página de comprobación de estado ( 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, lo marco como la respuesta. Gracias.
Actualización: 2015-05-06 Pensé en volver aquí y decir que parte del problema que ahora creo firmemente era la configuración del control de salud. 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 equilibrador de carga y que el que tenía más problemas tenía un umbral insalubre realmente agresivo y un tiempo de espera de respuesta. Nuestro tráfico tiende a aumentar impredeciblemente y creo que entre los ajustes agresivos de control de salud y los aumentos en el tráfico fue una tormenta perfecta.
Respuestas:
Obtendrá un "Servidor de fondo al máximo" cuando el equilibrador de carga ELB realiza sus comprobaciones de estado y recibe una "página no encontrada" (u otro error simple) debido a una configuración incorrecta (generalmente con el host NameVirtual).
Intente grepping la carpeta de archivos de registro utilizando el agente de usuario "ELB-HealthChecker". p.ej
Esto generalmente le dará un error 4x o 5x que se soluciona fácilmente. por ejemplo, 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.
fuente
Me encontré con este problema yo mismo. Amazon ELB devolverá este error si no hay instancias saludables. Nuestros sitios estaban mal configurados, por lo que la comprobación de estado de ELB estaba fallando, lo que provocó que el ELB eliminara la rotación de los dos servidores. Con cero sitios en buen estado, el ELB devolvió 503 Servicio no disponible: el servidor de fondo está en capacidad
fuente
[EDITAR después de comprender mejor la pregunta] Al no tener experiencia con el ELB, sigo pensando que esto suena sospechosamente como el error 503 que se puede lanzar 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 de las que puede procesar el back-end, las colas de entrada del back-end 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 arroja un 503. Se deduciría que lo mismo podría suceder cuando Apache es el back-end, y el frontend se entrega a un ritmo tal que las colas se llenen.
La solución (hipotética) es dimensionar los conectores de entrada del backend y los conectores de salida de la interfaz. 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 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 completamente que no es directamente aplicable, este enlace contiene una guía de tamaño para el conector Apache. Debería investigar los tecnicismos de la cola 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 Apache, un pico en el tráfico no es la única posibilidad. Si algunas solicitudes se atienden más lentamente que otras, una proporción mayor de esas también puede llevar a que se llenen las colas del conector. Esto fue cierto en mi caso.
Además, cuando esto me sucedió, estaba desconcertado de tener que reiniciar el servicio Apache para no recibir 503: s nuevamente. Simplemente esperar la inundación del conector no fue suficiente. Nunca lo entendí, pero ¿se puede especular en Apache sirviendo desde su caché tal vez?
Después de aumentar el número de trabajadores y la configuración correspondiente de maxclients antes de la bifurcación (esto era Apache multiproceso en Windows que tiene un par de otras directivas para las colas si no recuerdo mal), el problema 503 desapareció. En realidad no hice los cálculos, sino que simplemente modifiqué los valores hasta que pude observar un amplio margen para el consumo máximo de los recursos de la cola. Lo dejé pasar con eso.
Espero que esto haya sido de alguna ayuda.
fuente
puede aumentar los valores del comprobador de estado de elb, de modo que una sola respuesta lenta no extraiga un servidor de elb. es mejor que algunos usuarios obtengan un servicio no disponible, que el sitio esté inactivo para todos.
EDITAR: Podemos escapar sin precalentar el caché al aumentar el tiempo de espera del control de salud a 25 segundos ... después de 1-2 minutos ... el sitio responde como el infierno
EDITAR :: simplemente inicie un montón de bajo demanda, y cuando sus herramientas de monitoreo muestren a la gerencia lo rápido que es, entonces simplemente pague por adelantado RI amazon: P
EDITAR: es posible, una sola instancia registrada de backend elb no es suficiente. simplemente inicie algunos más y regístrelos con elb, y eso lo ayudará a reducir su problema
fuente
Es unos años tarde, pero espero que esto ayude a alguien.
Estaba viendo este error cuando la instancia detrás de ELB no tenía una IP pública adecuada asignada. Necesitaba crear manualmente una Elastic IP y asociarla con la instancia después de lo cual el ELB la recogió casi al instante.
fuente