Infraestructura. En producción, pocas decisiones pesan tanto como la forma de equilibrar conexiones a la base de datos y garantizar alta disponibilidad. Durante años, una organización mantuvo un Global Load Balancer (GLB) en cada webserver para repartir tráfico entre cuatro nodos Galera MySQL. Funcionó, sí, pero a costa de un peaje operativo cada vez mayor: instalar y actualizar en múltiples servidores, ajustar configuraciones repetidas, y reconfigurar a mano cada vez que el clúster crecía. La respuesta ha sido dar un giro: centralizar el balanceo con HAProxy y resolver la conmutación por error con Keepalived.
El resultado no es una promesa, sino un cambio tangible: menos mantenimiento, más fiabilidad y escalado más sencillo. A continuación, el caso técnico, de principio a fin.
Por qué abandonar GLB en cada webserver
La experiencia acumulada dejó claro que el enfoque descentralizado tiene un coste:
- Sobrecarga de mantenimiento. Instalar, configurar y mantener GLB en cada web multiplica el trabajo. Cualquier actualización o cambio —un tiempo de timeout, una nueva política de health-check, una IP añadida— se convierte en una carrera de relevos por todos los hosts.
- Escalado ingrato. Añadir un nodo Galera o crecer en número de backends implicaba tocar GLB en todas las máquinas que hablaban con MySQL.
- Visibilidad fragmentada. El diagnóstico de incidencias se dispersaba entre servidores, logs y estados locales.
La alternativa pasa por centralizar el punto de entrada: dos servidores dedicados con HAProxy al frente del clúster Galera, y Keepalived para exponer una IP virtual (VIP) que “flota” entre ambos. Si uno falla, el otro toma el relevo de inmediato.
La arquitectura: VIP, balanceo y conmutación por error
Esquema actual (resumen):
- Entrada web. Los usuarios llegan a los webservers a través de dos VIP gestionadas con Keepalived (para capa web).
- Conexión a base de datos. Los webservers, a su vez, ya no apuntan a direcciones de cada nodo Galera. En vez de eso, conectan a una VIP específica de MySQL (por ejemplo,
192.168.1.180), también gestionada por Keepalived. - Balanceo con HAProxy. Dicha VIP redirige hacia HAProxy, que reparte conexiones TCP a los cuatro nodos Galera:
192.168.1.81a192.168.1.84. - Alta disponibilidad. Keepalived usa VRRP para mantener la VIP “viva”: si el HAProxy principal cae, el secundario asciende a MASTER y la VIP se mueve sin que las aplicaciones lo noten.
Este diseño concentra el control en un punto claro, mantiene la simplicidad en los webservers (un único endpoint de BD) y añade un mecanismo de failover rápido y predecible.
HAProxy para Galera: TCP puro, health-checks y reparto constante
Para MySQL/Galera, lo adecuado es modo TCP (no L7), round-robin para repartir conexiones, y comprobaciones activas para no dirigir tráfico a nodos en mal estado.
Ejemplo de configuración:
frontend mysql_frontend
bind 192.168.1.180:3306
mode tcp
default_backend galera_backend
backend galera_backend
mode tcp
balance roundrobin
option mysql-check user haproxy
server db1 192.168.1.81:3306 check
server db2 192.168.1.82:3306 check
server db3 192.168.1.83:3306 check
server db4 192.168.1.84:3306 check
Lenguaje del código: CSS (css)Puntos clave del backend:
mode tcp: trata las sesiones como conexiones crudas de MySQL.balance roundrobin: distribución equitativa entre nodos Galera.option mysql-check user haproxy: sondeo nativo de MySQL con un usuario de seguimiento de salud. Si un nodo no responde correctamente, se retira del pool hasta recuperarse.
Este enfoque evita que el tráfico caiga en nodos degradados o en split-brain, y ofrece un punto único para logs, métricas y stats propias de HAProxy.
Keepalived: una VIP, dos HAProxy y VRRP para cubrirse las espaldas
Keepalived implementa VRRP, el protocolo que permite compartir una IP virtual entre hosts y establecer prioridades y roles (MASTER/BACKUP).
Ejemplo (servidor principal):
vrrp_instance VI_MYSQL {
state MASTER
interface eth0
virtual_router_id 53
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass S3cr3t
}
virtual_ipaddress {
192.168.1.180
}
track_script {
chk_haproxy
}
}
Lenguaje del código: PHP (php)Script de salud:
#!/bin/bash
systemctl is-active --quiet haproxy
exit $?
Lenguaje del código: PHP (php)Y se hace ejecutable:
chmod +x /usr/local/bin/chk_haproxy
Cómo funciona: el MASTER anuncia su presencia y mantiene la VIP. Si el script detecta que HAProxy no está activo, la prioridad cae y el BACKUP (con prioridad, p. ej., 90) asciende y toma la VIP. Para las aplicaciones, la IP de MySQL no cambia; el plano de datos continúa.
Beneficios inmediatos: menos piezas que tocar, más fiabilidad y escalado limpio
1) Menos mantenimiento. En lugar de revisar GLB en cada webserver, el equipo administra dos HAProxy y dos Keepalived. Centralización total: un punto para el balanceo, un punto para el failover.
2) Alta disponibilidad real. Si el primer HAProxy falla, Keepalived mueve la VIP en segundos. Ni webservers ni aplicaciones tienen que reintentar hosts en claro; siguen apuntando a una IP.
3) Crecer es trivial. Añadir nodos Galera o más instancias de HAProxy supone tocar una configuración, no veinte. Se reduce el tiempo de cambio y la probabilidad de errores.
4) Observabilidad concentrada. La telemetría del balanceo vive en HAProxy: estadísticas, contadores, errores por backend, sesiones abiertas. Eso simplifica la resolución de incidencias.
Consideraciones operativas: usuarios, permisos y pruebas
- Usuario de health-check. El
mysql-check user haproxyrequiere un usuario con permisos muy limitados en MySQL (lo justo para el ping y autenticación). Recuerda rotar credenciales y evitar privilegios innecesarios. - Pruebas de conmutación controladas. Ejecutar drills de VRRP en ventana de mantenimiento (parar HAProxy en el MASTER, observar failover y failback) gana confianza y evita sorpresas.
- Sesiones y stickiness. En MySQL muchas aplicaciones abren pocas conexiones duraderas (pooling en la app). En esos casos, round-robin hace buen papel. Si la carga depende de tareas muy largas por nodo, amplía los health-checks (tiempos y umbrales) para no sacar un servidor tras un pico puntual.
- IPv4/IPv6 y rutas. En entornos duales, documentar qué dirección usa la VIP para MySQL y qué interfaces escucha HAProxy reduce ambigüedades.
- Seguridad en Keepalived. La autenticación simple (
auth_type PASS) añade una capa básica; en redes compartidas conviene segmentación y controles en switches y routers.
La experiencia: del “cada webserver, su GLB” al “una IP para gobernarlas a todas”
El salto de GLB en cada webserver a HAProxy + Keepalived permite operar la base de datos como un servicio con IP propia, independiente del número de nodos o de su distribución física. El cambio mental es importante: las aplicaciones ya no necesitan saber dónde vive cada MySQL ni hacer listas rotativas de hosts; su palanca es el balanceador.
El equipo que ejecutó la transición lo resume en tres frases: “menos mantenimiento, más disponibilidad, más fácil de escalar”. El clúster Galera sigue siendo el mismo —multi-master y replicación síncrona—, pero el punto de acceso ahora es coherente y tolerante a fallos.
Pasos prácticos para replicar el enfoque
- Inventario y limpieza. Anotar todos los webservers que hoy hablan con MySQL y dónde está el clúster Galera. Consolidar accesos en una única IP de BD para aplicaciones.
- Desplegar dos HAProxy. Preparar hosts dedicados (o VMs) con HAProxy y Keepalived.
- Configurar HAProxy. Añadir frontend en la VIP:3306, declarar backend con los cuatro nodos Galera y health-checks nativos de MySQL.
- Configurar Keepalived (VRRP). Definir la VIP y el script que vigila HAProxy. Ajustar prioridades y anuncios.
- Probar failover. Apagar HAProxy en el MASTER, observar cómo la VIP pasa al BACKUP. Encender de nuevo y comprobar failback.
- Apuntar aplicaciones a la VIP. Cambiar conexión de MySQL en cada webserver a la VIP y retirar GLB locales.
- Monitorización y tuning. Activar stats en HAProxy, ajustar intervalos y timeouts de health-check según la carga real.
Configuraciones de referencia (completas)
HAProxy (fragmento):
global
log /dev/log local0
maxconn 20000
defaults
log global
mode tcp
timeout connect 5s
timeout client 50s
timeout server 50s
option tcplog
frontend mysql_frontend
bind 192.168.1.180:3306
default_backend galera_backend
backend galera_backend
balance roundrobin
option mysql-check user haproxy
server db1 192.168.1.81:3306 check
server db2 192.168.1.82:3306 check
server db3 192.168.1.83:3306 check
server db4 192.168.1.84:3306 check
Lenguaje del código: PHP (php)Keepalived (MASTER):
vrrp_script chk_haproxy {
script "/usr/local/bin/chk_haproxy"
interval 2
fall 2
rise 2
}
vrrp_instance VI_MYSQL {
state MASTER
interface eth0
virtual_router_id 53
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass S3cr3t
}
virtual_ipaddress {
192.168.1.180/24
}
track_script {
chk_haproxy
}
}
Lenguaje del código: PHP (php)Keepalived (BACKUP):
vrrp_instance VI_MYSQL {
state BACKUP
interface eth0
virtual_router_id 53
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass S3cr3t
}
virtual_ipaddress {
192.168.1.180/24
}
track_script {
chk_haproxy
}
}
Lenguaje del código: PHP (php)Lecciones aprendidas
- Centralizar reduce deuda técnica. Un balanceador por webserver es escala humana difícil. Dos HAProxy bien cuidados, no.
- VRRP “pega” tu IP a la disponibilidad. Si se cae el proceso de HAProxy, cae tu prioridad y la VIP pasa a quien sí está sano.
- Galera + HAProxy conviven sin trucos: TCP, round-robin, mysql-check y listo.
- Documentación y runbooks. Escribir los pasos de failover/failback y revisarlos periódicamente ahorra sustos.
Preguntas frecuentes
¿Cómo configurar HAProxy para balancear un clúster Galera MySQL?
En modo TCP, define un frontend ligado a la VIP:3306 y un backend con los nodos Galera (server dbX IP:3306 check). Activa option mysql-check user <usuario> para sondear la salud de cada nodo. Usa roundrobin para repartir conexiones.
¿Cómo funciona Keepalived (VRRP) para exponer una IP virtual de MySQL?
Keepalived crea una VRRP instance con una VIP y prioridades. El nodo con mayor priority y HAProxy sano mantiene la VIP como MASTER. Si cae HAProxy, el BACKUP asciende y toma la VIP, preservando la continuidad en capa de conexión.
¿Qué ventajas tiene HAProxy + Keepalived frente a GLB por webserver?
Menos mantenimiento (dos servidores vs muchos), alta disponibilidad real con VIP flotante, escalado más limpio (añadir nodos afecta a una configuración) y observabilidad centralizada para diagnóstico.
¿Buenas prácticas para health-checks MySQL en HAProxy?
Usar option mysql-check con un usuario mínimo, ajustar intervalos y timeouts según carga real, y vigilar métricas (tiempos de conexión, rise/fall, errores por servidor). Evitar permisos innecesarios en la cuenta de check y rotar credenciales.
En resumen, sustituir GLB en cada webserver por HAProxy + Keepalived ha simplificado de forma notable la operación de un clúster Galera: menos piezas, más disponibilidad y un camino claro para crecer. Para quien administre MySQL en producción, este patrón se ha convertido en una apuesta segura: una IP virtual con VRRP y un balanceador central que hace el trabajo duro.
vía: systemdeveloper
