HAProxy es un software que nos permite balancear carga entre varios servidores. Se suele usar para balancear servicios web, pero puede balancear cualquier servicio que funcione bajo protocolo TCP. En este artículo os vamos a enseñar varias configuraciones de HAProxy incluso que tenga en cuenta las cookies, parece una tontería, pero puede provocar que fallen nuestra web. Imagínate que tienes 2 servidores web -en adelante frontales- cuando el usuario llega por primera vez a tu web lo hace en el frontal-01. Cuando el usuario se registra crea una cookie, el usuario siguen navegando y de repente HAProxy envía el tráfico al frontal-2, en ese servidor no existe la cookie y por tanto le cerrará la sesión :(, configurando adecuadamente HAProxy esto no sucederá.

¿Qué es HAProxy?

HAProxy es un equilibrador de carga ligero con código de fuente abierta. Puede usarlo para la infraestructura de tolerancia a fallas construida u "ocultar" la "ubicación" real del proyecto por razones de seguridad. En este artículo, describiré cómo implementar un equilibrador de carga para un proyecto web, ubicado en dos servidores independientes.

Ventajas de Usar HAProxy

1. Alta Disponibilidad: Redirige el tráfico a servidores disponibles, evitando caídas.
2. Escalabilidad: Maneja miles de conexiones simultáneas con facilidad.
3. Flexibilidad: Compatible con HTTP, TCP y SSL.
4. Monitoreo Integrado: Ofrece paneles para visualizar el rendimiento.

Requerimientos básicos

Si desea utilizar HAProxy, debe asegurarse de que su infraestructura cumpla con las siguientes condiciones:

• Necesita al menos tres servidores: dos de ellos como "servidores centrales" de su proyecto y el último como equilibrador HAProxy;
• Nombre de dominio con registros A "apuntados" a la IP del balanceador;
• El contenido de su sitio web debe "implementarse" en ambos servidores web.

Instalación HAProxy

La configuración mínima para poder balancear carga es de 3 servidores: HAProxy + 2 frontales webs. La ventaja de usar HAProxy es que en cualquier momento puedes añadir más frontales.
Otra de las ventajas de usar HAProxy es que podemos restringir el acceso a los frontales por la IP Pública con lo cual no estarán accesibles directamente. Con los siguientes comandos ya podemos instalar HAProxy.

A grandes rasgos, para poder trabajar con HAproxy en modo proxy inverso, tenemos que entender dos cosas: los Backends y los Frontends

Los Backends son los servidores destino que quieres publicar, en nuestro caso, son los 4 servidores web.

Los Frontend son los puertos de escucha (en nuestro caso el 443 de HTTPs), sobre los que analizarás las peticiones que hagan los usuarios (la web a la quieren acceder), y en base a unos “filtros” (¿quiere ir a azul.jaimepons.com o a rojo.jaimepons.com?) podrás enlazar dichas peticiones con determinados backends.

Vale, tenemos dos servidores, pero… ¿a cuál nos conectaremos realmente?

Aquí interviene el algoritmo de balanceo de carga. Hay varios, y dependiendo del servicio que utilices querrás uno u otro, pero para el ejemplo que nos ocupa utilizaremos el algoritmo Round Robin, es decir, cada nueva petición irá alternándose entre el servidor 1 y el servidor 2.

Cuando tengamos los dos configurados veremos esto:

Fijaos que hay un “Check”. Ese Check lo que hace por defecto HAproxy es validar cada segundo que el servidor web esté activo y respondiendo. Si en algún momento un servidor se “cae”, ya no lo tendrá en cuenta a la hora de enviar peticiones y las peticiones se distribuirán entre los servidores que aún estén disponibles.

Ahora le toca el turno al Frontend. ¡Allá vamos!

Vamos a la pestaña Frontend, creamos uno nuevo y configuramos varias partes. La primera es la IP de escucha (WAN Address), el puerto (443) y el SSL Offloading, es decir, forzamos a que la conexión SSL cliente-servidor termine en el HAproxy (por eso hemos instalado el certificado wildcard *.jaimepons.com aquí). El Name puede ser cualquier cosa.

Ahora llegamos a la parte más importante del Frontend, determinar a qué Backend enviar la petición según la URL que nos estén solicitando.

En ACL (Access Control List) le decimos que cuando el host que nos estén pidiendo coincida con azul.jaimepons.com, la ACL que se activará se llamará “acl_azul”.

Luego en Actions le decimos que cuando la ACL “acl_azul” se active, se mande esa petición al Backend “azul”.

Y lo mismo para rojo.jaimepons.com, no creo que haga falta repetirlo 🙂

Una vez completado todo, guardamos y aplicamos cambios.

Vale, ya tenemos configurados el Frontend y los Backend, ahora falta el último paso, ¡activar HAproxy!, establecer las conexiones máximas por proceso y activar las estadísticas (suuuuuper interesante): Abre Setting y configúralo

HAProxy tiene cuatro secciones esenciales en el archivo de configuración HAProxy. Son global, defaults, frontend, y backend. Estas cuatro secciones definen cómo funciona el servidor en su conjunto, cuáles son sus configuraciones predeterminadas cómo se reciben y enrutan las solicitudes de los clientes a sus servidores de backend.

Formato

Si está utilizando HAProxy Enterprise para conocer sus características avanzadas, el archivo de configuración se puede encontrar en /etc/hapee-1.8/hapee-lb.cfg . Si está utilizando Community Edition, está en /etc/haproxy/haproxy.cfg . Puede comprobar la ruta del fichero de configuración llamando al ejecutable haproxy con el parámetro -c:

# haproxy -c -f /etc/hapee-1.8/hapee-lb.cfg 

La estructura de este archivo es la siguiente:

global                   
    # configuraciones globales 

defaults                
    # valores predeterminados 
              
frontend         
    # interfaz que acepta solicitudes de clientes       
           
backend               
    # servidores que atienden las solicitudes 

Global

En la parte superior de su archivo de configuración HAProxy está la sección global. La configuración en globaldefine ajustes de seguridad y rendimiento en todo el proceso.

• Vamos a explicar los parámetros del siguiente ejemplo:

global                 
     maxconn 50000                
     log /dev/log local0               
     user haproxy               
     group haproxy              
     stats socket /run/haproxy/admin.sock user haproxy group haproxy mode 660 level admin            
     nbproc 2               
     nbthread 4             
     cpu-map auto:1/1-4 0-3             
     ssl-default-bind-ciphers ECDHE-ECDSA-AES256-GCM-SHA384
:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305
:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256
:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384
:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256   
     ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets 

• maxconn

Limita el número máximo de conexiones que HAProxy aceptará. Su propósito es proteger su equilibrador de carga de quedarse sin memoria. Puede determinar el mejor valor para su entorno consultando la guía de tamaños para los requisitos de memoria.

• log

Garantiza que las advertencias emitidas durante el inicio y los problemas que surjan durante el tiempo de ejecución se registren en syslog. También registra las solicitudes. Puede apuntar al socket UNIX tradicional Syslog o journald, listen, /dev/log , o especificar un servidor rsyslog remoto para que los datos de registro se conserven externamente a su servidor de equilibrio de carga. Establezca una instalación de Syslog, que generalmente es local0. Tenga en cuenta que para leer los registros, deberá configurar cualquiera de los demonios syslog, o journald, para escribirlos en un archivo.

• user / group

Las líneas usery groupdicen a HAProxy que elimine los privilegios después de la inicialización. Linux requiere que los procesos sean root para escuchar en puertos inferiores a 1024. También querrá que sus claves privadas TLS sean legibles solo por root . Sin definir un usuario y un grupo para continuar el proceso, HAProxy mantendrá los privilegios de root, lo cual es una mala práctica. Tenga en cuenta que HAProxy en sí no crea el usuario y el grupo, por lo que deben crearse de antemano.

• stats socket

Habilita la API Runtime, que puede usar para deshabilitar dinámicamente los servidores y las comprobaciones de estado, cambiar los pesos de equilibrio de carga de los servidores. Puede obtener más información en Configuración dinámica con la API HAProxy Runtime .

• nbproc / nbthread

Especifica el número de procesos y subprocesos, respectivamente, que HAProxy debe generar al inicio. Esto puede aumentar la eficiencia de su equilibrador de carga. Sin embargo, cada proceso creado por nbproctiene sus propias estadísticas, controles de salud, etc. Los hilos creados con nbthread, por otro lado, los comparten. Puede usar una u otra o ambas configuraciones. HAProxy funciona bastante bien con un solo proceso y subproceso, a menos que esté haciendo muchas peticiones TLS, lo que se beneficia del uso de múltiples núcleos de CPU. Más información en Multithreading en HAProxy.

• ssl-default-bind-ciphers

Enumera los cifrados SSL y TLS que cada directiva bind usará de manera predeterminada. Se puede anular con una configuración más específica agregando el parámetro bind de cifrado de la directiva. Toma una lista de ciphersuites en orden de preferencia. HAProxy seleccionará la primera lista para la petición del cliente, a menos que la opción prefer-client-ciphers esté habilitada. Intente usar la Prueba del servidor SSL de Qualys para ver la calidad de sus cifrados elegidos y qué navegadores podrá admitir.

• ssl-default-bind-options

Configura las opciones SSL / TLS, como ssl-min-verdeshabilitar la compatibilidad con protocolos más antiguos. Por ejemplo, puede elegir aceptar solo conexiones que usen una versión TLS de 1.2 o más reciente.

Defaults

A medida que crece su configuración, el uso de una sección defaults ayudará a reducir la duplicación. Su configuración se aplica a todas las secciones frontendy backend. Puede anular esa configuración por defecto en las secciones que siguen si asigna una propiedad diferente.

Tampoco estás limitado a tener solo uno defaults. Las secciones defaults posteriores anularán las anteriores y restablecerán todas las opciones a sus valores predeterminados.

Por lo tanto, puede decidir configurar una sección defaults que contenga todas sus configuraciones de TCP y luego colocar después su configuracion TCP-only en las secciones frontendy backend. Luego, coloque todas sus configuraciones de HTTP en otra sección defaults y continúe con su configuracion HTTP en las secciones frontendy backend.

• Explicacion de los parámetros con el siguiente ejemplo:

defaults                 
     timeout connect 10s               
     timeout client 30s                 
     timeout server 30s                
     log global                
     mode http                  
     option httplog                 
     maxconn 3000  

• timeout connect / timeout client / timeout server

Configura el tiempo que HAProxy esperará a que se establezca una conexión TCP a un servidor. El sufijo «s» denota segundos. Sin ningún sufijo, se supone que el tiempo está en milisegundos. El timeout client mide la inactividad durante los períodos en los que esperaríamos que el cliente esté hablando o, en otras palabras, que envíe segmentos TCP. El timeout server mide la inactividad cuando esperamos que el servidor de esté hablando. Cuando caduca un tiempo de espera, la conexión se cierra. Tener tiempos de espera razonables reduce el riesgo de que los procesos bloqueados bloqueen conexiones que de otro modo podrían reutilizarse.

Al operar HAProxy en modo TCP, configurado con mode tcp, timeout serverdebe ser el mismo que timeout client. Esto se debe a que HAProxy no sabe de qué lado se supone que está hablando y, dado que ambos se aplican todo el tiempo, tener valores diferentes aumenta la probabilidad de confusión.

• log global

Es una forma de indicar a cada uno de los subsiguientes frontendque utilicen la configuración global log que definió en la sección global. Esto no es necesario para iniciar sesión, ya que se pueden agregar nuevas líneas aquí o en cada frontend. Sin embargo, en la mayoría de los casos en los que solo se usa un servidor syslog, esto es común.

• mode

Define si HAProxy funciona como un simple proxy TCP o si puede inspeccionar los mensajes HTTP de nivel superior del tráfico entrante. La alternativa a la especificación mode httpes usar mode tcp, que opera en el nivel más rápido, pero menos consciente. Si la mayoría de sus secciones frontendy backendusaran el mismo modo, tiene sentido especificarlo en la sección defaults para evitar repeticiones.

• maxconn

Limita el número de conexiones que cada frontend aceptará y, de forma predeterminada, se establece en 2000. Si desea permitir más conexiones, puede aumentarla aquí hasta el valor global maxconn. Por otro lado, es posible que desee utilizar un número que le dé a cada interfaz una parte justa de las conexiones globales.

• option httplog

Le dice a HAProxy que use un formato de registro más detallado al enviar mensajes a Syslog. Por lo general, preferirá option httplogmás que option tcplogen su sección defaults porque cuando HAProxy encuentra un frontendque usa mode tcp, emitirá una advertencia y lo degradará de option tcplogtodos modos.

Si no se especifica ninguno de los dos, se utiliza el formato de registro de conexión, que tiene muy pocos detalles además del cliente y las direcciones IP y los puertos del servidor. Otra opción es definir un formato de registro personalizado con el log-formatentorno, en cuyo caso, option httplogy option tcplogno son necesarios.

Frontend

Cuando coloca HAProxy como proxy inverso frente a sus servidores de backend , una sección frontend define las direcciones IP y los puertos a los que los clientes pueden conectarse. Puede agregar tantas secciones frontend como sea necesario para exponer varios sitios web a Internet. A cada  frontend clave le sigue una etiqueta, como www.mysite.com , para diferenciarla de otras.

• Mostramos el siguiente ejemplo:

frontend www.mysite.com            
    bind 192.168.1.101:80              
    bind 192.168.1.101:443 ssl crt /etc/ssl/certs/mysite.pem                
    http-request redirect scheme https unless {ssl_fc}               
     use_backend api_servers if{path_beg/api/}                 
     default_backend web_servers  

• bind

Permite la escucha de una peticion a una determinada dirección IP y puerto. Se puede omitir la IP para enlazar a todas las direcciones IP del servidor asignando un solo puerto, un rango o una lista delimitada por comas. A menudo utilizará los argumentos ssly crtpara indicar a HAProxy que administre las terminaciones SSL / TLS, en lugar de que sus servidores web lo hagan.

• http-request redirect

La configuración http-request redirect responde al cliente que debe probar una URL diferente. En nuestro ejemplo, los clientes que solicitan su sitio web a través de HTTP no encriptado son redirigidos a la versión HTTPS del sitio.

• use_backend

Elige un grupo de servidores de back-end para responder a las solicitudes entrantes si una condición dada es verdadera. Le sigue una declaración de ACL, como if path_beg/api/, que le permite a HAProxy seleccionar un backend específico basado en algunos criterios, como verificar si la ruta comienza con / api/. Estas líneas no son necesarias y muchas secciones frontend solo tienen una línea default_backend y no tienen reglas de selección especiales.

• default_backend

Se encuentra en casi todos frontendy da el nombre de a que backend enviar el tráfico si una regla use_backend no lo envía a otro lugar primero. Si una solicitud no se enruta por una directiva use_backendo default_backend, HAProxy devolverá un error 503 Servicio no disponible .

Backend

Define un grupo de servidores que serán balanceados en carga y asignados para manejar solicitudes. Agregará una etiqueta de su elección a cada uno backend, como servidores web.

Mostramos el siguiente ejemplo:

 backend web_servers               
     balance roundrobin               
     cookie SERVERUSED insert indirect nocache               
     option httpchk HEAD /              
     default-server check maxconn 20              
     server server2 192.168.1.102:80 cookie server2 

• balance

Controla cómo HAProxy seleccionará el servidor para responder a la solicitud si ningún método de persistencia anula esa selección. Un método de persistencia podría ser enviar siempre un cliente particular al mismo servidor basado en una cookie. Los valores comunes de equilibrio de carga incluyen roundrobin, que simplemente elige el siguiente servidor y comienza de nuevo en la parte superior de la lista nuevamente, y leastconn, donde HAProxy selecciona el servidor con la menor cantidad de sesiones activas.

• cookie

Permite la persistencia basada en cookies. Le dice a HAProxy que envíe una cookie llamada SERVERUSED al cliente y que la asocie con el nombre del servidor que dio la respuesta inicial. Esto hace que el cliente continúe hablando con ese servidor durante la duración de su sesión. Tenga en cuenta que el nombre del servidor se establece con un argumento cookie en la línea server.

• option httpchk

La configuración option httpchk hace que HAProxy envíe verificaciones de estado de Capa 7 (HTTP) en lugar de verificaciones de Capa 4 (TCP) a sus servidores de back-end. Los servidores que no responden no reciben más solicitudes. Mientras que las comprobaciones de TCP tienen éxito si son capaces de establecer una conexión con la IP y el puerto del servidor de backend , las comprobaciones de estado de HTTP esperan obtener una respuesta HTTP exitosa. Las comprobaciones de estado más inteligentes son fundamentales para eliminar los servidores que no responden , incluso si no responden significa simplemente obtener una mala respuesta HTTP como 500 Server Error .

De forma predeterminada, una comprobación de estado de HTTP realiza una solicitud a la ruta raíz, / , utilizando el verbo OPTIONS . Sin embargo, los argumentos especificados aquí se pueden personalizar. HAProxy tratará cualquier verificación que obtenga un código de respuesta 2xx o 3xx para que tenga éxito, aunque también se puede personalizar con una http-checklínea. El uso option httpchkno está restringido a los backends que usan mode http, por lo que los servidores que se comunican usando HTTP se pueden verificar independientemente del modo de proxy.

• default-server

Configura los valores predeterminados para las líneas server, como habilitar comprobaciones de estado, conexiones máximas, etc. Esto puede hacer que su configuración sea más fácil de leer y modificar. Alternativamente, puede especificar estos argumentos en cada server.

• server

El escenario server es el núcleo del backend. Su primer argumento es un nombre, seguido de la dirección IP y el puerto del servidor. Puede especificar un nombre de dominio en lugar de una dirección IP. En ese caso, se resolverá al inicio o, si agrega un argumento resolvers, se actualizará durante el tiempo de ejecución. Si no se especifica el puerto, HAProxy usará el mismo puerto en el que se conectó el cliente, lo cual es útil para puertos utilizados al azar, como para FTP en modo activo.

Aunque agregamos option httpchkpara configurar la comprobación de estado basada en HTTP de nuestros servidores, cada servidor debe optar por las comprobaciones de estado agregando un argumento check. Esto se puede establecer en la línea server o, como hemos hecho en este ejemplo, la línea default-server.

Cada línea server debe tener una configuración maxconn que limite el número máximo de solicitudes simultáneas que se le dará al servidor. En este ejemplo, hemos establecido esto en la línea default-server.

Bloque Listen como alternativa

Como hemos visto, las secciones frontendy backend reciben el tráfico y la envían a un grupo de servidores. También puede usar secciones listen para hacer lo mismo. Esencialmente, combinan la funcionalidad de frontendy backenden una. Puede preferir la legibilidad obtenida al tener secciones separadas frontendy backend, especialmente cuando se utiliza el modo HTTP con sus muchas opciones, o puede favorecer una configuración más concisa, configurandolo con etiquetas listen.

Ejemplo simple usando listen para servir la página de estadísticas de HAProxy :

 listen stats                
     bind *:9999            
     stats enable           
     stats uri /monitor          
     stats refresh 5s 

Configuración de HAProxy para MySQL

Configurar HAProxy para sistemas de gestión de bases de datos es bastante sencillo. A continuación, configuraremos HAProxy para que funcione como distribuidor de conexiones para los proxies de DataSunrise (192.168.1.100:3306, 192.101.1.101:3306, 192.168.1.102:3306).

Después de instalar HAProxy, abra el archivo /etc/haproxy/haproxy.cfg mencionado anteriormente y edite el bloque de configuración ‘listen’ de la siguiente manera:

listen af_mysql_balancer mode tcp bind *:3306 balance leastconn server mysql0 192.168.1.100:3306 check server mysql1 192.168.1.101:3306 check server mysql2 192.168.1.102:3306 check

HAProxy realizará comprobaciones de salud y distribuirá las conexiones de acuerdo con el número de conexiones en el nodo del servidor, dirigiendo al usuario al servidor con la menor cantidad de conexiones.

balance <algorithm> es para seleccionar los algoritmos de balanceo.

Para la lista completa de algoritmos de balanceo, consulte el Manual de configuración de HAProxy.

En caso de que el servidor actualmente usado por un usuario esté caído, la conexión se cerrará. El usuario tendrá que reconectarse y HAProxy abrirá una nueva conexión a la base de datos con el servidor que esté operativo y tenga la menor cantidad de conexiones.

Fuentes:
https://redeslinux.net/guia-completa-pfsense-con-ddns-de-cloudflare-certificados-lets-encrypt-y-haproxy-para-proxy-inverso-y-balanceo-de-carga-de-servicios/

https://www.datasunrise.com/es/informacion-profesional/balanceo-de-carga-con-haproxy/

https://servernotfound.es/haproxy-las-4-secciones-principales/