Como ya dijimos en el artículo anterior, HAProxy, tiene bastantes opciones de configuración (la documentación completa se encuentra en su página de documentación de HAProxy en inglés, las cuales no vamos a discutir en esta nota. Aquí solamente vamos a tratar aquellas que son necesarias para el escenario propuesto).

Pasos para la configuración

La primera parte de la configuración es bastante estándar y tiene que ver con la forma en que trabajará el propio HAProxy. Lo que nos interesa es la segunda parte, que es específica al escenario en cuestión. Con las opciones de “stats” se habilita la generación de estadísticas por parte de HAProxy y se da un usuario/contraseña para accederlo. El acceso es por web a la URL http://192.168.0.123/haproxy?stats.

  • Primero definimos el frontend, indicando que se va a ”bindear” a la IP 192.168.0.123 y puerto 80. En otras palabras, le decimos a HAProxy que escuche en esa IP y puerto.
  • Luego definimos una ACL para distinguir entre dos tipos de tráfico: las peticiones por imágenes y las demás peticiones. Las peticiones por imágenes siempre irán al backend ”imagenes”, que en este ejemplo tiene un solo servidor, backend1 (192.168.0.121).
  • Luego se definen los dos backends, uno para atender las peticiones por imágenes (backend ”imagenes”) y otro para atender todas las demás peticiones (backend ”servidores”).

Para el caso del backend ”servidores” se especifica la cookie donde se mantiene la sesión de PHP, esto es para que el balanceador mantenga la sesión del usuario. El nombre de esta cookie depende del lenguaje de programación y de la aplicación web en particular. Este podría considerarse el caso ”estandar”. El síntoma de que HAProxy no está usando la cookie correcta es que el usuario pierde la sesión,

Pero ¿Qué hace HAProxy con esa cookie -”PHPSESSID” en este caso-?

Dado que HAProxy está entre el cliente y el backend, necesita una forma de saber en que backend está la sesión de cada usuario. Esto lo hace marcando cada cookie de sesión con un identificador de backend. El término ‘‘prefix’‘ que sigue al nombre de la cookie indica que ese identificador de backend debe estar adelante de todos los valores que hay en la cookie.

  • Ahora bien, ¿cuál es el identificador? Más abajo, donde se declaran los backends, dice ‘‘cookie A’‘ y ‘‘cookie B”. Ahí se especifica que el backend1 estará identificado por el valor A y el backend2, por el B. Estos valores son strings, y pueden ser más descriptivos (por ejemplo, ”servidorbk1” y ”servidorbk2′‘, o ‘‘hp1200” y ‘‘dell850”).

Para ver este identificador puede buscar entre las cookies que guarda su navegador web para el sitio donde configuró el backend.

  • El balance indica el algoritmo de balance que utilizará. Por defecto HAProxy utiliza RoundRobin. Sin embargo, como más abajo especificamos un peso para cada servidor, el balance tiene en cuenta el peso de los servidores. Más aún, dado que estamos implementando ”sticky sessions” -conservar la sesión del usuario-, HAProxy va a enviar a un usuario que inició sesión siempre al mismo servidor, aunque el algoritmo de RoundRobin indique otra cosa.

En otras palabras, primero se aplica la configuración de sesiones. Si no hay sesión iniciada, se aplica el peso de los servidores en conjunto con el algoritmo de RoundRobin.

  • Por último se declaran los servidores de backend. Para el primer servidor, backend1, se indica su IP:Puerto, el peso que tiene, el valor que lo identifica en la cookie de sesión y la forma de chequear que está online (se chequea cada 1000 milisegundos que exista el archivo 192.168.0.121/check.txt). Para backend2 la configuración es similar.

Para el backend de imágenes se tiene una configuración parecida, solamente que no requiere el seguimiento de la sesión del usuario. Además, el backend consta de un solo servidor, backend1.

Algunas cosas a tener en cuenta

Primero, el parámetro ”source 192.168.0.123” le indica a HAProxy con qué IP de origen debe realizar el chequeo. Esto sirve en los casos en que HAProxy escucha en todas las IPs del sistema (0.0.0.0) y se quiere precisar con cuál de ellas el servidor debe realizar la petición.

Además, en los logs de los servidores de backend aparecerán las peticiones hechas por HAProxy para el archivo check.txt. Esto si bien no es grave, puede molestar a la hora de verificar y analizar los logs de Apache, por lo que se puede modificar en la configuración del mismo servidor web.

En el siguiente artículo veremos pruebas sobre la instalación, conclusiones y algunos tips.