Comprobaciones de estado HAProxy y control del downtime

Cuando realizas el load balancing de un servicio es importante asegurarse que los servidores que van a recibir el tráfico están en buenas condiciones para dar respuesta. En este articulo nos enfocamos en un par de mecanismos que HAProxy nos brinda para ello.  

HTTP health checks 

Para habilitar las health checks de cada servidor, al menos la palabra ‘check’ debe colocarse en las lineas del servidor o default-server lines

Pero hablemos del comportamiento predeterminado de HAProxy. Las comprobaciones utilizarán el puerto IP y TCP del servidor para realizar las health check. El intervalo entre dos comprobaciones de estado consecutivas será de dos segundos y su tiempo de espera máximo será el mismo valor, por lo que si no hay respuesta en ese tiempo, se considerará una comprobación no válida. Considerará un servidor como UP después de realizar dos health check válidas consecutivas y considerará un servidor como DOWN después de realizar tres comprobaciones de estado inválidas consecutivas. Solo leerá los primeros 16384 bytes de la respuesta. Todos estos parámetros se pueden cambiar en su configuración.

 

haproxy server state checks

Ahora, lo interesante sobre HAProxy es que puede realizar layer 7 health checks, que son un método más preciso al reenviar tráfico a servidores http. Para habilitar la comprobación de http, solo tienes que usar la opción directiva httpchk dentro del bloque de backend.

backend http_test
 mode http
 balance roundrobin
 option httpchk
 http-check expect status 200

 server Server1 192.168.10.11:80 check
 server Server2 192.168.10.12:80 check

Puedes personalizar esta comprobación un poco más, de este modo:

 option httpchk HEAD / HTTP/1.1rnHost: www.test.netrnUser-Agent: haproxy_check
 http-check expect status 200

Aquí estamos especificando el uso del método HEAD HTTP para guardarnos la respuesta del cuerpo HTTP, seguido del protocolo HTTP y finalmente el encabezado HTTP, que es una cadena concatenada en la que cada parámetro está separado por ‘ r n’ y cada clave / valor por una barra diagonal inversa y un espacio. En este encabezado en particular, hemos configurado el host, que es necesario para verificar un host virtual en el servidor web de destino, y también el user agent para poder identificar esas solicitudes en los registros fácilmente.

Al usar la directiva http-check expect, establecemos una regla de coincidencia para buscar una respuesta válida. Aquí usamos la palabra clave status para marcar solo como respuestas http válidas cuyo código es 200. También podríamos buscar una cadena usando la palabra clave string, aunque esto requiere el uso de un método HTTP GET o POST en lugar de HEAD.

Hay bastantes opciones para ajustar la configuración, pero el objetivo de este artículo no es explicar en profundidad las opciones de este mecanismo de verificación. Puedes obtener más detalles en la documentación de HAProxy.

Slow start mode

El Slow Start mode limita y mide el tráfico reenviado a un servidor que acaba de volver a estar online, y esto lo hace de forma progresiva. Es decir, el servidor obtiene una cantidad de tráfico ascendente a medida que pasa el tiempo dentro de una ventana de tiempo configurada, empieza recibiendo un 0% del tráfico y se incrementa hasta el 100% al final. Esto le permite agregar nuevos servidores sin colapsarlos con una avalancha de solicitudes.

El Slow start mode de HAProxy es muy útil para aplicaciones que dependen de la memoria caché y necesitan un período de calentamiento antes de poder responder a las solicitudes con un rendimiento óptimo, o aplicaciones que tienen un delay de inicio porque pueden necesitar cargar módulos o incluso compilar algunos elementos para inicializar (hello ASP .NET).

Puedes establecer el parámetro slowstart en la línea del servidor dentro del bloque backend o en la default-server line, ya sea en el bloque de back-end o  en el predeterminado. Puedes hacerlo así:

backend https_test
 mode http
 balance roundrobin
 option httpchk HEAD / HTTP/1.1rnHost: www.test.netrnUser-Agent: haproxy_check
 http-check expect status 200
 default-server check ssl verify none slowstart 4m
 
 server Server1 192.168.10.11:443
 server Server2 192.168.10.12:443

Solo acepta un valor de tiempo, y puede usar varias unidades de tiempo distintas: ms (predeterminado), s, m, h, etc.

Es importante tener en cuenta que este modo no se aplica a los servidores cuando se inicia el haproxy o se ha vuelto a cargar después de que se haya modificado la configuración porque se ha agregado un nuevo servidor. Solo se aplica a los servidores que se marcaron previamente como fallidos.

Y bueno, espero que esto sirva para cualquier duda básica que pueda tener sobre los health checks de HAProxy.


Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

2 respuestas

  1. que buen articulo!!! y en español!!!
    Necesito hacer que mi HA compruebe si un servidor esta disponible para dar respuesta (ahi utilizaria lo que aprendí en este post) pero si falla el check deberia reenviar a otro servidor (ej: 10.10.10.10:8080/mensaje_error/) donde se mostraria un mensaje de error. Alguna ayuda o sugerencia?

    1. Hola!

      Para mostrar un mensaje de error cuando no hay servidores disponibles, mi sugerencía es que uses la directiva Errorfile para el código 503 en el backend.

      Solo basta con copiar el archivo 503.http a por ejemplo mi_pagina_personalizada.http, modificar el html a tu gusto y añadir una linea similar a esta en el bloque backend de la configuración.
      errorfile 503 /etc/haproxy/errors/mi_pagina_personalizada.http

      De esta forma cuando no hayan servidores disponibles te mostrará dicha pàgina.

      Saludos!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *