Un archivo de configuración de HAProxy es corto comparado con la mayoría del software de servidor, pero decide cómo llega cada solicitud a su aplicación. Si va a poner un balanceador de carga delante de un sitio web o una API como paso hacia una configuración de servidor de alta disponibilidad, o heredó uno que nadie entiende del todo, conviene leer el archivo sección por sección. Esta guía recorre una configuración de HAProxy típica para una aplicación web en las versiones 3.x actuales: qué hace cada parte, qué opciones importan más y los errores que provocan caídas.

Las cuatro secciones de una configuración de HAProxy

  • global define las opciones de todo el proceso: el registro, el usuario con el que se ejecuta HAProxy, los valores predeterminados de TLS y el socket de administración que usa la Runtime API.
  • defaults contiene los ajustes que heredan todas las secciones siguientes, sobre todo el modo, http o tcp, y los timeouts. La falta de timeouts es una causa clásica de conexiones acumuladas, y HAProxy lo advierte al iniciar.
  • frontend describe en qué escucha HAProxy: direcciones, puertos, certificados y las reglas que deciden qué backend recibe cada solicitud.
  • backend enumera los servidores detrás del balanceador, cómo se reparte el tráfico entre ellos y cómo se comprueba su estado.

Después de cada edición, haproxy -c -f /etc/haproxy/haproxy.cfg valida el archivo antes de recargar. Una recarga mediante systemd inicia procesos nuevos con la nueva configuración mientras las conexiones existentes terminan en los anteriores.

Un ejemplo de configuración de HAProxy, en palabras

Una estructura habitual para el sitio web de una empresa con dos servidores de aplicación es esta:

  • Un frontend se enlaza al puerto 80 y redirige cada solicitud a HTTPS, y se enlaza al puerto 443 con ssl y un directorio crt que contiene los certificados.
  • Las reglas del frontend envían las solicitudes cuya ruta empieza con /api a un backend de API y todo lo demás al backend web.
  • Cada backend tiene una línea balance, un health check HTTP y dos líneas server, cada una con la palabra clave check.
  • El frontend agrega el encabezado X-Forwarded-For con option forwardfor y establece X-Forwarded-Proto, de modo que la aplicación registre las direcciones reales de los visitantes y sepa que la solicitud original usó HTTPS.

Este último punto es fácil de pasar por alto. Sin esos encabezados, las aplicaciones detrás del balanceador ven a todos los visitantes como si vinieran de la propia dirección de HAProxy, y algunas crean bucles de redirección porque creen que la solicitud llegó por HTTP sin cifrar.

Cómo elegir un algoritmo de balanceo de carga

  • roundrobin, el valor predeterminado, reparte por turnos y respeta los pesos de los servidores. Es adecuado para solicitudes cortas y similares.
  • leastconn envía las conexiones nuevas al servidor con menos conexiones activas. Es mejor cuando la duración de las solicitudes varía mucho, como en informes, cargas de archivos o conexiones de larga duración.
  • source, o un hash de un encabezado o de una URL, mantiene al mismo cliente o recurso en el mismo servidor. Es útil para cachés y menos para repartir la carga de manera uniforme.

Los pesos permiten que un servidor más grande reciba una parte mayor, y un peso de cero mantiene un servidor configurado sin enviarle solicitudes nuevas.

Ajustes de health check de HAProxy que reflejan la realidad

La palabra clave check por sí sola solo comprueba que un puerto TCP responda, algo que también hace una aplicación caída detrás de un servidor web activo. Un health check HTTP de HAProxy pide una página real: option httpchk junto con http-check send y http-check expect permite solicitar una ruta como /health y exigir el estado 200. Un buen endpoint de salud revisa las dependencias importantes, como la base de datos, sin ser costoso de ejecutar.

Los tiempos se definen por servidor: inter para el intervalo, fall para cuántas comprobaciones fallidas marcan un servidor como caído y rise para cuántos éxitos lo reincorporan. Las comprobaciones demasiado agresivas sacan de servicio a servidores sanos durante una lentitud pasajera; las demasiado lentas siguen enviando visitantes a un servidor caído. Los health checks son una de las primeras cosas que revisamos en una instalación existente de balanceador de carga HAProxy.

Sesiones persistentes de HAProxy y terminación SSL de HAProxy

Si la aplicación guarda los inicios de sesión o los carritos en archivos locales o en memoria, el visitante que llega a otro servidor pierde su sesión. La mejor solución está en la aplicación: guardar las sesiones en un lugar compartido, como Redis o la base de datos. Cuando eso no es posible, las sesiones persistentes de HAProxy usan una directiva cookie en el backend, por ejemplo cookie SERVERID insert indirect nocache, y un valor de cookie en cada línea server. HAProxy fija entonces a cada visitante a un servidor y solo lo mueve si ese servidor falla.

La terminación SSL de HAProxy significa que HAProxy gestiona TLS y pasa HTTP sin cifrar a los servidores por una red privada. Así los certificados quedan en un solo lugar y HAProxy puede leer las solicitudes para enrutarlas. Si el trayecto entre HAProxy y los backends cruza redes que usted no controla, cifre también ese tramo agregando ssl y la verificación de certificados a las líneas server.

Drenar un servidor con la Runtime API de HAProxy

Para un despliegue sin tiempo de inactividad, saque un servidor de la rotación, actualícelo, compruébelo y vuelva a incorporarlo. La API de tiempo de ejecución de HAProxy (Runtime API) lo hace sin editar el archivo. Mediante el socket de administración definido en la sección global, un comando como set server web/app1 state drain impide que lleguen visitantes nuevos a app1 mientras terminan las sesiones existentes, y state ready lo devuelve al servicio. Los scripts de despliegue pueden drenar un servidor de esta manera, esperar a que su número de conexiones llegue a cero y continuar. Los cambios hechos mediante el socket no se escriben en el archivo de configuración, así que los cambios permanentes deben hacerse allí.

El mismo socket y la página de estadísticas integrada muestran el estado de cada servidor y los resultados de los health checks; restrinja ambos a los administradores. Cada directiva y comando se describe en la documentación oficial de HAProxy, organizada por versión.

Preguntas frecuentes: configuración de HAProxy

¿Un solo HAProxy puede atender sitios web y otros servicios?

Sí. Una configuración puede balancear sitios web en modo http y servicios como bases de datos o correo en el modo TCP de HAProxy, cada uno con su propio frontend y backend. En modo TCP, HAProxy deja pasar las conexiones sin leerlas.

¿Qué versión de HAProxy conviene usar?

Una rama de soporte a largo plazo, como la 3.2, en producción. Los paquetes de las distribuciones suelen ir por detrás de las ramas actuales, así que verifique qué versión instala realmente su servidor; el proyecto HAProxy publica sus ramas mantenidas y señala paquetes más recientes para Debian y Ubuntu.

¿Cuántos servidores necesitamos detrás de HAProxy?

Al menos dos para tener redundancia, cada uno capaz de soportar por sí solo el tráfico máximo. De lo contrario, drenar uno para un despliegue, o perder uno por una falla, sobrecarga al otro justo en el peor momento.

¿Está planificando un balanceador de carga o quiere una segunda opinión sobre una configuración existente? Nuestro servicio de instalación y configuración del balanceador de carga HAProxy abarca health checks, terminación TLS y conmutación por error planificados en torno a su aplicación, para empresas en Los Ángeles y más allá. Los backends suelen necesitar atención también; consulte nuestro servicio de optimización del servidor web Apache. Contáctenos con una breve descripción de sus servidores y su tráfico.