carga de proxy Apache detección de fallos en el servidor back-end equilibrio

Question

Aquí está mi escenario (diseñado por mi predecesor):

Dos servidores Apache que sirven deber proxy inverso para un número de servidores web mixta backend (Apache, IIS, Tomcat, etc.) . Hay algunos sitios para los cuales tenemos varios servidores back-end web, y en esos casos, hacer algo como:

<Proxy balancer://www.example.com> 
    BalancerMember http://192.168.1.40:80 
    BalancerMember http://192.168.1.41:80 
</Proxy> 
<VirtualHost *:80> 
    ServerName www.example.com:80 
    CustomLog /var/log/apache2/www.example.com.log combined 
    <Location /> 
     Order allow,deny 
     Allow from all 
     ProxyPass balancer://www.example.com/ 
     ProxyPassReverse balancer://www.example.com/ 
    </Location> 
</VirtualHost> 

lo tanto, en este ejemplo, tengo un sitio (www.example.com) en el las configuraciones de los servidores proxy, y ese sitio está conectado a uno u otro de los dos servidores backend, 192.168.1.40 y .41.

Estoy evaluando esto para asegurarme de que somos tolerantes a fallas en todos nuestros servicios web (ya he puesto los dos servidores proxy inversos en un clúster IP compartido por este motivo), y quiero asegurarme que los servidores backend de carga equilibrada son tolerantes a fallas también. Pero estoy teniendo problemas para averiguar si la detección de fallas de back-end (y la lógica para evitar el servidor backend fallido) está integrada en el módulo mod_proxy_balancer ...

Así que si 192.168.202.40 falla, Apache detectará esto (I ¿Entenderá si se necesita primero una solicitud fallida) y enrutar automáticamente todas las solicitudes al otro servidor, 192.168.202.41? ¿O continuará equilibrando las solicitudes entre el backend fallido y el backend operacional?

he encontrado algunas pistas en la documentación de Apache para mod_proxy y mod_proxy_balancer que parecen indicar que el no se puede detectar ("MaxAttempts = número máximo de intentos de cesión antes de renunciar.", "Failonstatus = una sola o por comas lista separada de códigos de estado HTTP. Si se establece, esto forzará al trabajador a un estado de error cuando el servidor devuelva cualquier código de estado en la lista. "), pero después de unos días de búsqueda, no he encontrado nada concluyente que diga con certeza que (o al menos "debería") detectar la falla y recuperación de back-end.

Diré que la mayoría de los resultados de búsqueda utilizan el protocolo AJP para pasar el tráfico a los servidores backend, y esto aparentemente admite la detección de fallas, pero mis backends son una mezcla de Apache, IIS, Tomcat y otros , y estoy bastante seguro de que muchos de ellos no son compatibles con AJP. También son una mezcla de Windows 2k3/2k8 y Linux (principalmente Ubuntu Lucid) cajas ejecutando varias aplicaciones diferentes con diferentes requisitos, por lo que los módulos adicionales como Backhand y LVS no son una opción para mí.

También he intentado poner a prueba empíricamente esta función, mediante la creación de un nuevo sitio de prueba como esta:

<Proxy balancer://test.example.com> 
    BalancerMember http://192.168.1.40:80 
    BalancerMember http://192.168.1.200:80 
</Proxy> 
<VirtualHost *:80> 
    ServerName test.example.com:80 
    CustomLog /var/log/apache2/test.example.com.log combined 
    LogLevel debug 
    <Location /> 
     Order allow,deny 
     Allow from all 
     ProxyPass balancer://test.example.com/ 
     ProxyPassReverse balancer://test.example.com/ 
    </Location> 
</VirtualHost> 

Dónde 192.168.1.200 es una dirección falsa que no se ejecuta ningún servidor web, para simular una falla de back-end. El sitio de prueba se sirvió sin problemas para un grupo de máquinas de cliente diferentes, pero incluso con el conjunto de LogLevel para depurar, no vi nada registrado para indicar que detectó que uno de los servidores back-end estaba inactivo ... Y Me gustaría estar 100% seguro de que puedo llevar nuestros backend de carga equilibrada para el mantenimiento (uno a la vez, por supuesto) sin afectar los sitios de producción.

Answer 1

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html sección "Parámetros BalancerMember", propiedad = reintentos:

Si el trabajo de grupo de conexión con el servidor back-end está en el estado de error , Apache httpd no reenviará todas las solicitudes a ese servidor hasta la el tiempo de espera expira. Esto permite que [one] cierre el servidor para el mantenimiento y vuelva a ponerlo en línea más tarde.Un valor de 0 significa siempre reintentar a los trabajadores en un estado de error sin tiempo de espera.

Sin embargo, existen otras condiciones de error que no se detectarían utilizando mod_whatever, por ejemplo, el back-end de IIS ejecutando una aplicación que está inactiva. IIS está activo, por lo que se puede establecer una conexión y leer una página, es solo que la página siempre tendrá un error interno de 500 servidores. Aquí tendrá que usar failonerror para atraparlo y forzar al trabajador a un estado de error.

En todos los casos, una vez que el trabajador está en un estado de error, no se le dirigirá el tráfico. He estado probando diferentes formas de consumir ese primer error y reintentarlo, pero siempre parece haber casos en que una página de error regresa al cliente.

Answer 2

hay una propiedad 'ping' en los 'parámetros' BalancerMember

Leer la documentación que suena como 'ping' ajustado a 500 ms enviará una solicitud antes mod_proxy se dirige a un BalancerMember. mod_proxy esperará 500 ms para una respuesta de un BalancerMember, y si mod_proxy no recibe una respuesta, BalancerMember pasará a un estado de error.

Me cansé de implementar esto, pero no pareció ayudar a dirigir a un BalancerMember en vivo.

<Proxy balancer://APICluster> 
    BalancerMember https://api01 route=qa-api1 ttl=5 ping=500ms 
    BalancerMember https://api02 route=qa-api2 ttl=5 ping=500ms 
    ProxySet lbmethod=bybusyness stickysession=ROUTEID 
</Proxy> 

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html

propiedad Ping le dice al servidor web a "prueba" la conexión con el servidor antes de reenviar la solicitud. Para AJP, hace que mod_proxy_ajp envíe una solicitud de CPING en la conexión ajp13 (implementado en Tomcat 3.3.2+, 4.1.28+ y 5.0.13+). Para HTTP, hace que mod_proxy_http envíe un 100-Continue al backend (solo válido para HTTP/1.1 - para backends que no sean HTTP/1.1, esta propiedad no tiene ningún efecto). En ambos casos, el parámetro es el retraso en segundos para esperar la respuesta. Esta característica se ha agregado para evitar problemas con back-end colgados y ocupados. Esto aumentará el tráfico de red durante la operación normal, lo que podría ser un problema, pero reducirá el tráfico en caso de que alguno de los nodos del clúster esté inactivo o ocupado. Al agregar un sufijo de ms, el retraso también se puede establecer en milisegundos.