Descripción: mod_proxy extensión para balanceo de carga
Estado: Extensión
ModuleIdentifier: proxy_balancer_module
Archivo fuente: mod_proxy_balancer.c
Compatibilidad: Disponible en la versión 2.1 y posteriores

Resumen

Este modulo requiere el servicio de mod_proxy y proporciona equilibrio de carga para todos los protocolos compatibles. Los más importantes son:

El algoritmo del planificador de equilibrio de carga no lo proporciona este módulo, sino otros como:

Por lo tanto, para obtener la capacidad de equilibrio de carga, mod_proxy, mod_proxy_balancer y al menos uno de los módulos de algoritmo del planificador de equilibrio de carga debe estar presente en el servidor.

Advertencia

No habilite el proxy hasta que haya asegurado su servidor. Los servidores proxy abiertos son peligrosos tanto para su red como para Internet en general.

Algoritmo del programador del equilibrador de carga

En la actualidad, hay 4 algoritmos del programador del equilibrador de carga disponibles para su uso: Recuento de solicitudes (mod_lbmethod_byrequests), Recuento de tráfico ponderado (mod_lbmethod_bytraffic), Recuento de solicitudes pendientes (mod_lbmethod_bybusyness) y el recuento de tráfico de latidos (mod_lbmethod_heartbeat). Estos se controlan a través del lbmethod valor de la definición del equilibrador. Ver el ProxyPass directiva para obtener más información, especialmente sobre cómo configurar los Balancer y BalancerMembers.

Pegajosidad del equilibrador de carga

El equilibrador admite la adherencia. Cuando una solicitud se envía mediante proxy a algún back-end, todas las solicitudes siguientes del mismo usuario deben enviarse mediante proxy al mismo back-end. Muchos balanceadores de carga implementan esta función a través de una tabla que asigna las direcciones IP del cliente a los back-end. Este enfoque es transparente para los clientes y los back-end, pero adolece de algunos problemas: distribución de carga desigual si los clientes están ocultos detrás de proxies, errores de adherencia cuando un cliente utiliza una dirección IP dinámica que cambia durante una sesión y pérdida de adherencia, si el desbordamiento de la tabla de mapeo.

El módulo mod_proxy_balancer implementa la adherencia además de dos medios alternativos: cookies y codificación de URL. El suministro de la cookie puede hacerlo el back-end o el propio servidor web Apache. La codificación de URL generalmente se realiza en el back-end.

Ejemplos de una configuración de equilibrador

Antes de profundizar en los detalles técnicos, aquí hay un ejemplo de cómo puede utilizar mod_proxy_balancer para proporcionar equilibrio de carga entre dos servidores back-end: 


    BalancerMember "http://192.168.1.50:80"
    BalancerMember "http://192.168.1.51:80"

ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Otro ejemplo de cómo proporcionar equilibrio de carga con adherencia usando mod_headers, incluso si el servidor back-end no establece una cookie de sesión adecuada: 

Header add Set-Cookie "ROUTEID=.%BALANCER_WORKER_ROUTEe; path=/" env=BALANCER_ROUTE_CHANGED

    BalancerMember "http://192.168.1.50:80" route=1
    BalancerMember "http://192.168.1.51:80" route=2
    ProxySet stickysession=ROUTEID

ProxyPass        "/test" "balancer://mycluster"
ProxyPassReverse "/test" "balancer://mycluster"

Variables de entorno exportadas

Actualmente se exportan 6 variables de entorno:

BALANCER_SESSION_STICKY

A esto se le asigna el stickysession valor utilizado para la solicitud actual. Es el nombre de la cookie o el parámetro de solicitud que se usa para las sesiones fijas.

BALANCER_SESSION_ROUTE

A esto se le asigna el ruta analizado de la solicitud actual.

BALANCER_NAME

A este se le asigna el nombre del equilibrador utilizado para la solicitud actual. El valor es algo como balancer://foo.

BALANCER_WORKER_NAME

A este se le asigna el nombre del trabajador utilizado para la solicitud actual. El valor es algo como http://hostA:1234.

BALANCER_WORKER_ROUTE

A esto se le asigna el ruta del trabajador que se utilizará para la solicitud actual.

BALANCER_ROUTE_CHANGED

Se establece en 1 si la ruta de la sesión no coincide con la ruta del trabajador (BALANCER_SESSION_ROUTE! = BALANCER_WORKER_ROUTE) o la sesión aún no tiene una ruta establecida. Esto se puede usar para determinar cuándo / si se debe enviar al cliente una ruta actualizada cuando se usan sesiones adhesivas.

Habilitación de la compatibilidad con Balancer Manager

Este modulo requiere el servicio de mod_status. El administrador del equilibrador permite la actualización dinámica de los miembros del equilibrador. Puede usar el administrador de balanceo para cambiar el factor de balance de un miembro en particular, o ponerlo en el modo fuera de línea.

Por lo tanto, para obtener la capacidad de administración del balanceador de carga, mod_status y mod_proxy_balancer tiene que estar presente en el servidor.

Para habilitar la administración del equilibrador de carga para los navegadores del dominio example.com, agregue este código a su httpd.conf archivo de configuración


    SetHandler balancer-manager
    Require host example.com

Ahora puede acceder al administrador del equilibrador de carga utilizando un navegador web para acceder a la página. http://your.server.name/balancer-manager. Tenga en cuenta que solo los equilibradores definidos fuera de Los contenedores pueden ser controlados dinámicamente por el Administrador.

Detalles sobre la rigidez del equilibrador de carga

Al utilizar la adherencia basada en cookies, debe configurar el nombre de la cookie que contiene la información sobre qué back-end utilizar. Esto se hace a través del stickysession attribute agregado a cualquiera ProxyPass o ProxySet. El nombre de la cookie distingue entre mayúsculas y minúsculas. El equilibrador extrae el valor de la cookie y busca un trabajador miembro con ruta igual a ese valor. los ruta también debe establecerse en ProxyPass o ProxySet. La cookie puede ser configurada por el back-end o como se muestra en el ejemplo anterior por el propio servidor web Apache.

Algunos back-end utilizan una forma ligeramente diferente de cookie de adherencia, por ejemplo, Apache Tomcat. Tomcat agrega el nombre de la instancia de Tomcat al final de su cookie de identificación de sesión, separada con un punto (.) de la identificación de la sesión. Por lo tanto, si el servidor web Apache encuentra un punto en el valor de la cookie de adherencia, solo usa la parte detrás del punto para buscar la ruta. Para que Tomcat conozca su nombre de instancia, debe configurar el attribute jvmRoute dentro del archivo de configuración de Tomcat conf/server.xml al valor de la ruta del trabajador que se conecta al respectivo Tomcat. El nombre de la cookie de sesión utilizada por Tomcat (y más generalmente por las aplicaciones web Java basadas en servlets) es JSESSIONID (mayúsculas) pero se puede configurar para otra cosa.

La segunda forma de implementar la adherencia es la codificación de URL. El servidor web busca un parámetro de consulta en la URL de la solicitud. El nombre del parámetro se especifica nuevamente usando stickysession. El valor del parámetro se usa para buscar un trabajador miembro con ruta igual a ese valor. Dado que no es fácil extraer y manipular todos los enlaces URL contenidos en las respuestas, generalmente el trabajo de agregar los parámetros a cada enlace lo realiza el back-end que genera el contenido. En algunos casos, puede ser factible hacerlo a través del servidor web utilizando mod_substitute o mod_sed. Sin embargo, esto puede tener un impacto negativo en el rendimiento.

Los estándares de Java implementan una codificación de URL ligeramente diferente. Usan una información de ruta adjunta a la URL con un punto y coma (;) como separador y agregue el ID de sesión detrás. Como en el caso de las cookies, Apache Tomcat puede incluir la configuración jvmRoute en esta ruta info. Para permitir que Apache encuentre este tipo de información de ruta, debe configurar scolonpathdelim para On en ProxyPass o ProxySet.

Finalmente, puede admitir cookies y codificación de URL al mismo tiempo, configurando el nombre de la cookie y el nombre del parámetro de URL separados por una barra vertical (|) como en el siguiente ejemplo:

ProxyPass "/test" "balancer://mycluster" stickysession=JSESSIONID|jsessionid scolonpathdelim=On

    BalancerMember "http://192.168.1.50:80" route=node1
    BalancerMember "http://192.168.1.51:80" route=node2

Si la cookie y el parámetro de solicitud proporcionan información de enrutamiento para la misma solicitud, se utiliza la información del parámetro de solicitud.

Solución de problemas de rigidez del equilibrador de carga

Si experimenta errores de adherencia, por ejemplo, los usuarios pierden sus sesiones de aplicación y necesitan iniciar sesión nuevamente, primero debe verificar si esto se debe a que los back-end a veces no están disponibles o si su configuración es incorrecta. Para conocer los posibles problemas de estabilidad con los back-end, consulte el registro de errores de Apache para ver los mensajes de error del proxy.

Para verificar su configuración, primero verifique si la adherencia se basa en una cookie o en la codificación de URL. El siguiente paso sería registrar los datos apropiados en el registro de acceso mediante el uso de un LogFormat. Los siguientes campos son útiles:

%MYCOOKIEC
El valor contenido en la cookie con nombre MYCOOKIE. El nombre debe ser el mismo que aparece en el stickysession attribute.
%Set-Cookieo
Esto registra cualquier cookie establecida por el back-end. Puede realizar un seguimiento de si el back-end establece la cookie de sesión que espera y en qué valor se establece.
%BALANCER_SESSION_STICKYe
El nombre de la cookie o el parámetro de solicitud utilizado para buscar la información de enrutamiento.
%BALANCER_SESSION_ROUTEe
La información de ruta que se encuentra en la solicitud.
%BALANCER_WORKER_ROUTEe
La ruta del trabajador elegido.
%BALANCER_ROUTE_CHANGEDe
Ajustado a 1 si la ruta en la solicitud es diferente de la ruta del trabajador, es decir, la solicitud no se pudo manejar de forma pegajosa.

Las razones comunes para la pérdida de la sesión son los tiempos de espera de la sesión, que generalmente se pueden configurar en el servidor back-end.

El equilibrador también registra información detallada sobre el manejo de la adherencia en el registro de errores, si el nivel de registro se establece en debug o mas alto. Esta es una manera fácil de solucionar problemas de adherencia, pero el volumen de registro puede ser demasiado alto para los servidores de producción con mucha carga.