Cómo configurar Keepalived para alta disponibilidad y conmutación por error de IP en CentOS y RHEL

Cómo configurar una conmutación por error para sus servidores proxy Linux con keepalived

Configurar la alta disponibilidad en Linux no siempre es sencillo, especialmente si intentas mantener tus servidores proxy funcionando sin problemas. Podrías notar que si un servidor falla o tu red tiene un problema, tus clientes reciben errores porque la dirección IP no se transfiere correctamente. Ahí es donde Keepalived brilla: se asegura de que un servidor tome el control sin problemas cuando el otro falla, evitando esos molestos tiempos de inactividad. El truco está en configurar VRRP correctamente para que las IP virtuales cambien entre tus servidores. Asegúrate de tener claro qué IP son reales y cuáles virtuales, ya que colocarlas incorrectamente puede provocar todo tipo de caos en la red. Aquí tienes un paso a paso sobre lo que funcionó para configurar un clúster de conmutación por error de Linux con Keepalived, especialmente diseñado para servidores proxy Squid. Hasta ahora, funciona en CentOS 7, y mucho de esto también aplica a las distribuciones basadas en RHEL.

Cómo crear un clúster de conmutación por error con keepalived en Linux

Principios de VRRP y lo que necesita saber

Si nunca has usado VRRP, un resumen rápido: una VIP (IP virtual) es la IP flotante que se mueve entre servidores. Todos conocemos este concepto, pero VRRP lo hace dinámico, así que si tu servidor principal (el principal) falla, el de respaldo toma el control. Utiliza un ID de enrutador virtual (VRID) para evitar conflictos entre grupos, y los números de prioridad determinan qué servidor será el principal. Los paquetes de latido (multidifusión en 224.0.0.18) informan a todos los demás: «¡Hola, estoy conectado!», y si el de respaldo no recibe noticias del principal, interviene. Un aviso: asegúrate de que tu switch admita tráfico multidifusión; de lo contrario, probablemente tendrás problemas. Además, no uses las IP reales como virtuales, ya que si un servidor falla y tu IP se mueve, al volver, podría desconectarse de la red hasta que VRRP se solucione. En algunas configuraciones, esto es extraño, pero evita reutilizar IP reales como VIP para mantener todo limpio.

Paso 1: Instalación de keepalived y configuración básica

• Utilice yum (o yum/dnf ) para instalar:

# yum install keepalived

vrrp_script chk_squid_service { script "/usr/sbin/squid -k check" interval 3 } vrrp_instance proxy_ip1 { state MASTER interface eth0 virtual_router_id 1 priority 255 virtual_ipaddress { 192.168.2.101/24 dev eth0 label eth0:1 } track_interface { eth1 } track_script { chk_squid_service } } vrrp_instance proxy_ip2 { state BACKUP interface eth0 virtual_router_id 2 priority 100 virtual_ipaddress { 192.168.2.102/24 dev eth0 label eth0:2 } track_interface { eth1 } track_script { chk_squid_service } } 

Paso 2: Manejo de la configuración de red y firewall

Antes de activar Keepalived, revise las reglas de iptables. Debe permitir el tráfico VRRP (multidifusión 224.0.0.18/8).Algo como esto:

# iptables -A INPUT -i eth0 -d 224.0.0.0/8 -j ACCEPT # iptables -A INPUT -p vrrp -i eth0 -j ACCEPT

En algunas configuraciones, el firewall predeterminado bloquea esto, así que asegúrese de habilitarlo. No olvide habilitar Keepalived para que se inicie al arrancar:

# systemctl enable keepalived # systemctl start keepalived

Una vez en ejecución, verifique sus interfaces:

# ip a show eth0

Deberías ver tus IP virtuales asignadas a la interfaz una vez que ambos servidores estén en funcionamiento.

Paso 3: Asegúrese de que Keepalived responda a las fallas del servicio y la interfaz

Ese es el punto principal: supervisar tus aplicaciones (como Squid) e interfaces. Así es como se agregan las comprobaciones:

vrrp_script chk_squid_service { script "/usr/sbin/squid -k check" interval 3 } vrrp_instance proxy_ip1 {...track_script { chk_squid_service } } vrrp_instance proxy_ip2 {...track_script { chk_squid_service } } 

Este script se ejecuta cada 3 segundos. Si Squid falla, keepalived declarará el servidor como defectuoso y la VIP se moverá al nodo en buen estado. Es muy útil para detectar problemas como fallos de aplicaciones o interfaces de red que se desconectan.

Paso 4: Prueba de conmutación por error: sí, rompa cosas a propósito

Una vez configurado todo, es hora de hacer pruebas. Desactive eth0 en proxy-serv01 ( ifconfig eth0 downo ip link set eth0 down) y compruebe si proxy-serv02 controla la VIP. Ejecute:

# ip a show eth0

Y mira los registros:

# cat /var/log/messages | grep -i keepalived

Debería ver mensajes que indiquen que el primer servidor entra en estado de FALLO y que el servidor de respaldo cambia a MAESTRO. Al reactivar eth0, el servidor debería volver a cambiar automáticamente, con registros que confirmen el cambio.

Lo mismo ocurre con la simulación de fallas de red externa: deshabilite eth1 y debería ver que keepalived maneja eso (si está configurado con track_interface), cambiando los roles según sea necesario.

No olvides detener Squid manualmente para comprobar el comportamiento a prueba de fallos:

# systemctl stop squid

Los registros mostrarán que keepalived detecta que el servicio está inactivo y cambia las IP en consecuencia.

Resumen

Esta configuración, aunque compleja, resultó sorprendentemente fiable tras algunos ajustes. La clave está en asegurarse de que las IP virtuales no estén vinculadas directamente a interfaces reales y de que las comprobaciones sean precisas. En una máquina, puede que el sistema falle una o dos veces antes de estabilizarse, pero en un entorno de trabajo, suaviza considerablemente los fallos inesperados. Implementar comprobaciones de estado tanto para las interfaces de red como para los servicios de aplicaciones añade una capa de resiliencia que puede ser crucial.

Resumen

• Instalar keepalived con yum install keepalived
• Defina cuidadosamente sus instancias VRRP, establezca prioridades y especifique IP virtuales
• Configurar reglas de firewall para el tráfico de multidifusión
• Agregar controles de estado para aplicaciones e interfaces
• Prueba rompiendo intencionalmente la red y los servicios

Palabras finales

Configurar la alta disponibilidad es un poco complicado, pero una vez que funciona, es un gran alivio. La parte crucial es la monitorización y las pruebas exhaustivas. Esperamos que esto proporcione una base sólida para que la configuración de tu proxy sea resiliente. Es algo que funcionó en diferentes sistemas; espero que esto ayude a reducir el tiempo de inactividad.