Paso a paso: Configurar un balanceador de carga NGINX de alta disponibilidad con Keepalived y HAProxy

Un NGINX-Load-Balancer de alta disponibilidad elimina el punto único de fallo en el borde de la red al hacer que dos Linux-nodos proporcionen una IP virtual (VIP) mediante VRRP y ejecuten localmente NGINX y HAProxy para TLS, enrutamiento y comprobaciones de estado. En esta guía práctica describo no solo las configuraciones, sino también las consecuencias operativas, las causas de fallo típicas, comandos de medición y verificación, así como una estrategia de retroceso práctica.

NGINX-Load-Balancer de alta disponibilidad: arquitectura y reparto de responsabilidades

Resumen: Keepalived (VRRP) proporciona una VIP a la que se conectan los clientes. El nodo activo tiene la VIP asignada localmente y responde a ARP. NGINX se encarga de la terminación TLS, la política de cabeceras y los redireccionamientos; HAProxy se ejecuta localmente y realiza comprobaciones de estado precisas y el enrutamiento hacia los backends. Esta separación permite áreas de responsabilidad claras: políticas de TLS y seguridad en NGINX, control de estado y rendimiento en HAProxy.

Requisitos, red y decisiones de diseño

Suposiciones esenciales: ambos Load‑Balancer en el mismo dominio de Layer‑2 (VLAN), VIP dentro de la misma subred, el tráfico VRRP (protocolo IP 112) debe poder fluir entre los hosts. Si las aplicaciones almacenan el estado de sesión localmente, planifique Sticky Sessions o un almacén central de sesiones (p. ej. Redis); de lo contrario los failovers provocarán la pérdida de la información de sesión.

Parámetros de ejemplo

• LB1: 10.10.10.11/24, LB2: 10.10.10.12/24, VIP: 10.10.10.10/24
• Interfaz: eth0, Backends: 10.10.20.21:8080, 10.10.20.22:8080
• DNS: un A‑Record hacia la VIP; el TTL es cuestión de segundos, el failover de la VIP es transparente para los clientes

Instalación: paquetes, servicios, orden

Instale NGINX, HAProxy y Keepalived en ambos nodos. Habilite y arranque los servicios tras las comprobaciones de configuración.

sudo apt-get update
sudo apt-get install -y nginx haproxy keepalived curl iproute2 iputils-arping

sudo systemctl enable --now nginx
sudo systemctl enable --now haproxy
sudo systemctl enable --now keepalived

Ajustes del kernel y de ARP: por qué es importante

Si Linux responde incorrectamente a consultas ARP se produce blackholing de tráfico o split brain. Los siguientes ajustes sysctl reducen respuestas ARP no deseadas; aplíquelos en ambos nodos.

sudo tee /etc/sysctl.d/99-lb-ha.conf >/dev/null <<'EOF'
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
EOF

sudo sysctl --system

Explicación: arp_ignore controla si el sistema responde a consultas ARP para IPs no configuradas localmente; arp_announce influye en qué IP de origen se utiliza en las solicitudes ARP. Ajustes incorrectos permiten al nodo de respaldo responder ARP para la VIP y causan split brain.

HAProxy: capa de backend local, comprobaciones de estado y métricas

HAProxy proporciona comprobaciones de estado robustas (HTTP, TCP, SSL), ajustes de weight y de rise/fall. Use un bind local (127.0.0.1) para que NGINX pueda reenviar internamente. Las estadísticas pueden utilizarse para monitorización o exportarse mediante un Prometheus‑Exporter.

# /etc/haproxy/haproxy.cfg
global
  log /dev/log local0
  tune.maxaccept 1000
  maxconn 50000
  daemon

defaults
  mode http
  option httplog
  timeout connect 5s
  timeout client 60s
  timeout server 60s

frontend fe_local
  bind 127.0.0.1:9000
  default_backend be_app

backend be_app
  balance roundrobin
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2
  server app1 10.10.20.21:8080 check
  server app2 10.10.20.22:8080 check

listen stats
  bind 127.0.0.1:8404
  stats enable
  stats uri /stats

Verifique HAProxy antes de reiniciar:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

NGINX: TLS, rutas de proxy y timeouts

NGINX realiza la terminación TLS. Automatice los certificados (p. ej. certbot/ACME) o utilice su PKI interna. Preste atención a proxy_read_timeout y a los ajustes de buffer para que respuestas largas del backend no bloqueen la conexión.

# /etc/nginx/sites-available/lb.conf
server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name _;
  ssl_certificate     /etc/ssl/certs/lb.pem;
  ssl_certificate_key /etc/ssl/private/lb.key;
  client_max_body_size 50m;
  proxy_read_timeout 120s;
  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:9000;
  }
}

Keepalived: configuración VRRP, script de seguimiento y temporizadores

Keepalived determina qué nodo posee la VIP. Los scripts de seguimiento reducen la prioridad ante fallos de servicio, de modo que un nodo de backup sano pueda asumir. Los valores advert_int y priority regulan el tiempo de conmutación y el orden de preferencia.

Script de seguimiento con códigos de salida

sudo tee /usr/local/sbin/chk_proxy.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Prüft Dienste und lokales HAProxy Health-Endpoint
systemctl is-active --quiet nginx || exit 1
systemctl is-active --quiet haproxy || exit 1
curl -fsS --max-time 1 http://127.0.0.1:9000/healthz >/dev/null || exit 1
exit 0
EOF
sudo chmod 0755 /usr/local/sbin/chk_proxy.sh

Configuración de Keepalived (Master/Backup)

# /etc/keepalived/keepalived.conf (Beispiel MASTER)
vrrp_script chk_proxy {
  script "/usr/local/sbin/chk_proxy.sh"
  interval 2
  timeout 2
  fall 2
  rise 2
  weight -30
}

vrrp_instance VI_10 {
  state MASTER
  interface eth0
  virtual_router_id 10
  priority 110
  advert_int 1
  authentication { auth_type PASS; auth_pass 7f3c9d2a }
  virtual_ipaddress { 10.10.10.10/24 }
  track_script { chk_proxy }
}

# Backup hat priority 100 und state BACKUP

Nota: La autenticación en Keepalived (auth_pass) es un mecanismo sencillo; en redes no seguras debe emplear segmentación de red adicional, ya que VRRP no proporciona criptografía fuerte.

Fuentes de fallo: ARP, funciones del switch, firewalls

Causas comunes de comportamiento inesperado:

• Funciones del switch como Dynamic ARP Inspection (DAI) pueden bloquear los Gratuitous ARP después de un failover — en esas redes es necesaria una configuración del switch.
• La firewall del host o las Cloud Security Groups pueden bloquear el protocolo IP 112 (VRRP) — compruébelo con tcpdump.
• Conntrack (Stateful NAT/Firewall): durante la traducción NAT un failover puede interrumpir conexiones existentes porque la tabla NAT no está presente en el nodo que asume.

Diagnóstico con tcpdump, arping y registros

Comprobaciones útiles para el análisis:

# VRRP traffic beobachten (Protocol 112)
sudo tcpdump -n -i eth0 proto 112

# ARP prüfen
sudo tcpdump -n -i eth0 arp

# GARP senden (nach Failover)
sudo arping -U -I eth0 -c 5 10.10.10.10

# Keepalived logs
sudo journalctl -u keepalived -f

Si tcpdump no muestra paquetes VRRP, a menudo la causa es un firewall o un switch intermedio. Si el GARP del Master no pasa, los clientes aparecen con una asignación MAC antigua en las tablas arp y deben reaprenderla.

Efectos de conntrack y NAT en failover

En entornos con NAT o firewalls stateful, la tabla conntrack es específica por host. Tras un failover del VIP faltan entradas conntrack establecidas en el nodo nuevo, lo que provoca sesiones interrumpidas. Medidas posibles:

• Operar Keepalived con sincronización de conntrack (p. ej. conntrackd) — aumenta la complejidad.
• Aceptar la renovación de conexiones: tolerar reconexiones breves, permitir que los clientes se vuelvan a conectar.
• Considerar una arquitectura Activo/Activo si la continuidad de sesión es crítica.

Aspectos de seguridad y gestión de certificados

Los certificados TLS deben ser idénticos en ambos LBs. Automatice los despliegues con Certbot (ACME) o su PKI interna y valide las claves privadas mediante permisos de archivo. Almacene los certificados versionados en un repositorio de artefactos seguro o en un Secret‑Store.

# Beispiel Certbot (Let's Encrypt) - nicht für private PKI
sudo apt-get install -y certbot
sudo certbot certonly --standalone -d lb.example.com
# Verteilen Sie das resultierende PEM sicher auf beide Nodes (scp/Ansible)

Proceso de despliegue y parches — runbook concreto

Un procedimiento típico y probado para parchear o actualizar la configuración minimiza el riesgo:

1. Plan: comunicar la ventana de mantenimiento, reducir temporalmente las alertas de monitorización.
2. Redirigir el tráfico al backup: detener Keepalived en el Master o reducir su Priority.
3. Validación: en el backup comprobar que el VIP se ha asumido y que latencia/errores son normales.
4. Parchear el Master, probar (comprobar NGINX/HAProxy localmente), reincorporarlo al pool.
5. Parchear el segundo nodo.
6. Comprobaciones posteriores: prueba de failover, Health‑Checks, análisis de logs.

# Beispiel: Traffic auf Backup bringen
# Auf Master:
sudo systemctl stop keepalived
# Auf Backup prüfen:
ip -br addr show dev eth0
sudo curl -I --resolve lb.example.com:443:10.10.10.10 https://lb.example.com/
# Nach Patch:
sudo systemctl start keepalived

Monitorización, métricas y alertas

Métricas importantes que debe supervisar:

• Transiciones VRRP de Keepalived (conmutaciones frecuentes indican inestabilidad)
• Momento de la asignación del VIP y eventos GARP
• Tasas 4xx/5xx de NGINX
• Estado de backends en HAProxy, tiempo de respuesta y encolamiento
• Métricas del sistema: descriptores de archivo, netstat para sockets abiertos, loadavg

Exporte las estadísticas de HAProxy mediante un exporter para Prometheus o use el endpoint de stats interno para reglas de alertas.

Alternativas de diseño avanzadas

Si necesita mayor escalado o disponibilidad global, considere otros patrones:

• Nube pública: un load balancer gestionado evita problemas de ARP/VRRP.
• Anycast/BGP: para distribución global y menor latencia; requiere experiencia en enrutamiento de red.
• Activo/Activo: ambos LB soportan tráfico; requiere sincronización de sesiones o aplicaciones sin estado.

Lista de comprobación antes de la puesta en producción

• ¿VRRP (IP 112) entre los LBs y en la red permitido por firewall/switch?
• ¿Se han establecido y cargado las configuraciones sysctl de ARP en ambos nodos?
• ¿Funciona el Track‑Skript de Keepalived y son válidos los Exit‑Codes?
• ¿Los Health Checks de HAProxy devuelven las respuestas esperadas (200/OK)?
• ¿Los certificados TLS están instalados y sincronizados en ambos nodos?
• ¿Se han comprobado las funcionalidades del switch (DAI, Port Security) y, en su caso, ajustado?
• ¿Se ha configurado monitoring y alerting para transiciones VRRP y la salud del backend?
• ¿Se ha probado el plan de rollback (ip addr add manual, Start/Stop de Keepalived)?

Escollos típicos y contramedidas rápidas

Split Brain: Compruebe los paquetes VRRP, los Auth‑Token, el virtual_router_id y las prioridades. Si los switches tienen DAI activo, configure bindings DHCP/ARP adecuados o agregue las MAC de los LB a la whitelist.

Tiempos de conmutación lentos: advert_interval demasiado grande, caché ARP en clientes/switches o GARP suprimido. Reduzca advert_int y pruebe el comportamiento de envío de GARP, pero tenga en cuenta que intervalos muy cortos generan más tráfico VRRP.

Conclusión y relevancia operativa

Un NGINX‑Load‑Balancer de alta disponibilidad con Keepalived y HAProxy es una solución pragmática para reducir los riesgos de fallo en el perímetro de red. No solo importan ficheros de configuración correctos, sino también ajustes de red y switch, comportamiento ARP, health checks robustos y un proceso de rollout probado. Invierta tiempo en monitoring, runbooks documentados y pruebas periódicas de failover — eso asegura una madurez operativa predecible.

Weiterführende Prüfbefehle (Quick Reference)

# Wer hat die VIP?
ip -br addr show dev eth0 | grep 10.10.10.10 || true

# VRRP‑Traffic live beobachten
sudo tcpdump -n -i eth0 proto 112

# Prüfen ob Keepalived Track‑Skript läuft und Exit‑Code liefert
/usr/local/sbin/chk_proxy.sh && echo OK || echo FAIL

# GARP senden (Master)
sudo arping -U -I eth0 -c 5 10.10.10.10

# HAProxy Stats (lokal)
curl -sS http://127.0.0.1:8404/stats

Seguridad operativa: gestión de configuración, pruebas y recuperación rápida

Tras la puesta en marcha técnica, la gestión de cambios determina la estabilidad a largo plazo. Coloque todas las configuraciones de Keepalived, NGINX y HAProxy en un repositorio Git, versionando las plantillas y generando artefactos idempotentes desde pipelines CI automatizadas. Así se pueden rastrear los rollbacks por commit y evitar drifts de configuración.

Complementos prácticos:

• Canary‑Rollout: distribuya los cambios de config primero al nodo de backup, verifique los health checks y los logs, y luego al master.
• Recuperación rápida: pasos documentados para asignar la VIP manualmente, acceso SSH de emergencia y restauración de configuraciones desde Git minimizan el tiempo de inactividad.
• Detección de fallos avanzada: utilice BFD (Bidirectional Forwarding Detection) junto con VRRP para una detección más rápida de fallos de enlace, especialmente cuando existen requisitos críticos de latencia.
• Segmentación de red: despliegue la señalización VRRP por un HA‑VLAN/VRF dedicado para reducir la superficie de ataque — VRRP no ofrece criptografía fuerte.
• Integración con monitoring: envíe los VRRP‑States, config‑hashes y Config‑Change‑Events a su sistema central de alertas/tickets para que los cambios de configuración sean visibles inmediatamente.

Estos componentes operativos reducen errores humanos, aceleran la recuperación y hacen que la operación del LB sea reproducible y auditable — crucial para soluciones empresariales orientadas a procesos con altos requisitos de disponibilidad.

Para este tema también son importantes Haproxy, la alta disponibilidad y el balanceo de carga en capa 4 y capa 7. El artículo sitúa estos aspectos de forma comprensible y explica qué resulta relevante en la operativa diaria.