Ierrea.com es un un espacio donde se recogen procedimientos de un Administrador de Sistemas TIC, relacionados con entornos Virtuales VMware o Hyper-V, Cloud, Storage, Comunicaciones, etc...

Despliegue de Haproxy como balanceador de carga en CentOS 7


Haproxy es una herramienta que nos permite balancear la carga de trabajo entre varios servidores, y dotar al servicio publicado por los servidores de aplicaciones de Alta disponibilidad.

Generalmente se suele usar para balancear tráfico HTTP (Capa7 o aplicación), pero se puede usar para balancear cualquier servicio que funcione bajo el protocolo TCP (Capa4 o transporte). Al repartir o balancear la carga de trabajo entre "n" servidores, éstos podrán operar de una forma más eficiente y a la vez ofrecer un servicio de alta disponibilidad.

Al mismo tiempo, este tipo de diseños nos permite realizar cambios en el aplicativo sin afectar al servicio en producción, y una vez realizados los cambios, subirlos a nuestro nivel de productivo.

Bien, el escenario que planteamos en el laboratorio estará compuesto por tres máquinas. Las tres con sistema operativo CentOS 7 recién instalado, es decir, sin ninguna otra herramienta más.

Una de las máquinas asumirá el rol de balanceador de carga mediante el software Haproxy, y las otras dos serán los servidores Backends o servidores de aplicaciones.

Para llevar a cabo el laboratorio, en los servidores Backends instalaremos un servidor web Apache, y en él publicaremos una web. Los servidores en cuestión serán los siguientes:

  • Haproxy01

  • Srvapp01

  • Srvapp02

En primer lugar instalaremos el software Haproxy en el servidor dedicado para ello.

Esto lo realizaremos ejecutando el comando:

# yum install -y haproxy

A continuación instalaremos Apache en los dos servidores Backend. Para ello ejecutamos el siguiente comando en cada uno de los servidores de aplicaciones:

# yum install -y httpd

Bueno, pues ya con Apache instalado, vamos a crear una página web representativa de cada servidor.

Para modificar la URL por defecto de un servidor Apache, editamos el fichero index.html mediante el comando vim /var/www/html/index.html

... hacemos una simple modificación que nos permitirá identificar en qué servidor web estamos conectados...

Repetimos el proceso en el servidor Srvapp02...

Posteriormente, vemos el estado del servicio httpd (1), lo iniciamos si está detenido (2), y lo configuramos para que arranque de forma automática al iniciar el servidor (3). Para ello ejecutamos los siguientes comandos:

1) systemctl status httpd

2) systemctl start httpd

3) systemctl enable httpd

A continuación, abrimos de forma permanente el puerto 80 en los firewalls de los sistemas Srvapp01 y Srvapp02. Para ello ejecutamos en cada servidor el comando:

firewall-cmd --zone=public --add-port=80/tcp --permanent

... y reiniciamos el firewall para aplicar el cambio mediante el comando:

firewall-cmd --reload

Tras realizar los ajustes anteriores, comprobamos que podemos acceder a la URL por defecto de los servidores Backend (Apache)

Ahora toca configurar el balanceador de carga Haproxy, para que éste vaya distribuyendo los accesos mediante los servidores de aplicaciones o Backends.

Para realizar la parametrización, editaremos el fichero haproxy.cfg del servidor haproxy01 mediante el comando:

vim /etc/haproxy/haproxy.cfg

La parametrización del balanceo de carga de las peticiones recibidas es muy sencilla. Básicamente hay que crear un campo Frontend, donde definiremos el puerto por el que el Haproxy recibirá las peticiones (en este laboratorio utilizaremos el puerto 80), y otro campo Backend, donde definiremos el tipo de balanceo, en este caso estableceremos un balanceo del tipo roundrobin, así como los servidores Backend a los que el Haproxy redirigirá las peticiones.

Más adelante veremos más aspectos configurables en el Haproxy, pero a modo de resumen, el balanceo de las peticiones como tal, lo definiríamos de la siguiente manera:

Bien, una vez parametrizado el haproxy, al igual que con los webservers, iniciamos el servicio haproxy (#systemctl start haproxy) y lo configuramos para que inicie de forma automática junto con el servidor (#systemctl enable haproxy).

También debemos abrir el puerto por el que entraran las peticiones, como ya hemos dicho con anterioridad, éstas vendrán por el puerto 80, de modo que al igual que hemos hecho en los servidores web, ejecutamos los siguientes comandos:

firewall-cmd --zone=public --add-port=80/tcp --permanent

firewall-cmd --reload

Una vez hecho esto, llega el momento de comprobar que el balanceo funciona correctamente. Para ello mediante un navegador web, apuntamos a la ip del Haproxy, y si vamos refrescando el navegador, veremos que la conexión http va cayendo de manera balanceada entre los diferentes servidores Backend.

El balanceo de carga funciona bien, y nos aporta por un lado alta disponibilidad, ya que el servicio continua ante la parada de N servidores Backend, y además nos permite aumentar el rendimiento distribuyendo el servicio entre los servidores de aplicación o Backend.

Pero... ¿qué pasa si un usuario tiene establecida una sesión contra uno de los Backends, se le corta la conexión por el motivo que sea, la restablece y cae en otro de los Backends? ¿Perdería la sesión que tenía establecida? Para dar solución a este supuesto, tenemos que habilitar la opción de configuración de Cookies por sesión.

Para establecer esta parametrización, en la sección de Backends del fichero haproxy.cfg debemos incorporar la línea cookie SERVERID insert indirect nocache, y en cada línea de los servidores backends, agregar check cookie nombre_server

Con este ajuste, el comportamiento será el siguiente:

Cuando un navegador acceda a un Backend mediante el balanceador de carga Haproxy, éste insertará una cookie en los paquetes intercambiados con el cliente, indicando el servidor backend que ha sido elegido por el algoritmo del balanceador de carga. La información que Haproxy inserta en la cabecera de los paquetes devueltos será la siguiente: Set-Cookie: SERVERID=srvapp01

La próxima vez que el cliente haga una consulta, mandará paquetes con esa información en la cabecera, de forma que Haproxy, al ver esa instrucción, le redirigirá directamente al mismo servidor Backend en el que estuvo anteriormente.

Una vez aplicados estos ajustes, podemos comprobar que aunque actualicemos el navegador, siempre estaremos en el mismo backend, en este caso, Srvapp01.

Bueno, y para finalizar el post, veremos cómo habilitar y acceder a las estadísticas del servicio Haproxy. Obviamente es opcional, pero es un servicio que sin duda viene muy bien para tener visibilidad sobre la actividad de los diferentes servidores, la carga de balanceo, la duración de las sesiones, etc...

Como siempre, tendremos que editar el fichero de configuración de la herramienta, haproxy.cfg, y en él, agregar justo debajo de defaults datos como ip:puerto de acceso al servicio, la dirección URI, intervalo de refresco, credenciales de acceso, etc...

A continuación los parámetros establecidos en el laboratorio:

listen admin_stats

bind 192.168.1.190:8080

option forwardfor

option httpclose

stats uri /stats

stats refresh 10s

stats realm HAProxy\ Global\ stats

stats auth admin:password

Tras habilitar las estadísticas, vamos a acceder a ellas atacando a la ip:puerto definida e ingresando las credenciales establecidas.

Podemos comprobar que disponemos de cuatro servidores Backend, la distribución de la carga de las sesiones entres ellos, la duración de las sesiones, y un largo etcétera...

En la siguiente imagen, podemos ver que he "tirado" tres de los cuatro servidores Backend, el sistema de estadísticas lo ha detectado, pero el servicio sigue dándose por medio del único servidor de aplicaciones que todavía sigue "vivo".

Pues este sería es despliegue de un entorno de balanceo de carga mediante Haproxy, que tiene en cuenta las cookies por sesión, y con acceso al módulo de estadísticas...

#Haproxy #CentOS #LoadBalancer

azure-administrator-associate.png
MCSA-Windows-Server-2012-2019.png
VMW-LGO-CERT-PRO-DATA-CTR-VIRTUALIZATION