VRRP elimina el punto único de fallo en el balanceo de carga
Configura dos nodos para que el IP virtual flote entre ellos. El failover se resuelve en segundos sin depender de TTL de DNS.
Tienes tres servidores API tras un balanceador. Si muere uno, los otros dos siguen sirviendo tráfico. Pero cuando cae el propio balanceador, todo el sistema queda aislado: los backends están sanos, pero nadie puede alcanzarlos. El problema no es la aplicación, es la puerta de entrada. La solución habitual de añadir un segundo balanceador falla por una razón de red básica: el DNS apunta a una IP fija. Si cambias el registro para que apunte al nodo de respaldo, tienes que esperar a que expiren los TTLs. Eso significa minutos de interrupción real, no un fallo inmediato controlado.
VRRP: quién responde por la IP
VRRP (Virtual Router Redundancy Protocol, definido en RFC 5798) permite que varios nodos compartan una misma dirección IP virtual (VIP). Solo un nodo, el master, responde activamente por esa IP; el resto son backups que permanecen en silencio. El master envía paquetes de anuncio (heartbeats) al multidirección 224.0.0.18, por defecto una vez por segundo, usando el protocolo IP número 112. Como no usa TCP ni UDP, no hay puertos que abrir en el firewall, pero sí hay que permitir el paso del protocolo en las reglas de red.
Si los backups dejan de recibir anuncios durante unos tres intervalos, asumen que el master ha caído. Inician una elección basada en prioridad (rango 1-254, alto gana) y el vencedor reclama la VIP. El tiempo típico de failover está entre 1 y 3 segundos. Un detalle importante: si el nodo recuperado tiene mayor prioridad que el actual, por defecto recuperará la VIP de inmediato (preempt). Desactivar el preempt suele ser más sensato para evitar perturbaciones adicionales si el nodo original sigue inestable (flapping).
Además de mover la IP, VRRP mueve también la MAC virtual (formato 00:00:5E:00:01:XX, donde XX es el ID del grupo). Esto ayuda a los switches a no tener que reaprender la tabla de direcciones durante el cambio. Para forzar la actualización en el resto de la red, el nuevo master envía un Gratuitous ARP, un broadcast no solicitado que avisa que la IP ahora está en su MAC. Eso limpia las cachés ARP vecinas y evita esperas innecesarias por expiración natural.
