Keepalived para Alta Disponibilidad (VRRP): Guía de Failover de IP y Redundancia de Servicios

Introducción

Keepalived es un componente crítico de infraestructura que proporciona capacidades de alta disponibilidad y balanceo de carga para sistemas Linux utilizando el Protocolo de Redundancia de Router Virtual (VRRP). Como el estándar de facto para implementar failover de IP en entornos empresariales, Keepalived asegura disponibilidad continua del servicio al transferir automáticamente direcciones IP virtuales desde sistemas primarios fallidos a nodos de respaldo saludables en subsegundos.

Las organizaciones que ejecutan servicios críticos no pueden tolerar puntos únicos de fallo. Cuando balanceadores de carga, servidores web, proxies de base de datos o servicios de red experimentan fallos de hardware, caídas de software o requisitos de mantenimiento, Keepalived mantiene sin problemas la continuidad del servicio promoviendo instancias de respaldo sin intervención manual o reestablecimiento de conexión del lado del cliente.

La implementación de Keepalived combina VRRP para gestión de direcciones IP con un framework integrado de verificación de salud que monitorea la disponibilidad del servicio a nivel de capa de aplicación. Este enfoque de doble capa asegura que el failover ocurra no solo cuando los sistemas se vuelven inalcanzables, sino cuando las aplicaciones mismas dejan de funcionar correctamente, proporcionando verdadera alta disponibilidad a nivel de servicio.

Las principales empresas tecnológicas y proveedores de servicios despliegan Keepalived para proteger balanceadores de carga HAProxy, proxies inversos Nginx, clusters de base de datos PostgreSQL, capas de caché Redis y servicios de red personalizados de interrupciones. Su diseño ligero, consumo mínimo de recursos y estabilidad probada en entornos de producción lo hacen ideal tanto para infraestructura bare-metal como virtualizada.

Esta guía completa explora implementaciones empresariales de Keepalived, cubriendo fundamentos de VRRP, verificación avanzada de salud, arquitecturas de failover multi-nivel, patrones de integración con servicios comunes, optimización de rendimiento y metodologías de solución de problemas esenciales para despliegues de producción.

Teoría y Conceptos Fundamentales

Protocolo de Redundancia de Router Virtual (VRRP)

VRRP (RFC 3768/RFC 5798) proporciona asignación automática de direcciones IP a routers o hosts participantes, habilitando failover transparente:

Router Virtual: Una entidad lógica que consiste en múltiples sistemas físicos que comparten un ID de Router Virtual (VRID) y presentan una única dirección IP virtual a los clientes.

Arquitectura Maestro-Respaldo: Un sistema opera como MASTER, poseyendo la IP virtual y respondiendo al tráfico. Los sistemas de respaldo monitorean el MASTER a través de anuncios VRRP y asumen el rol MASTER si el MASTER actual falla.

Mecanismo de Anuncio: El MASTER envía anuncios VRRP multicast (protocolo IP 112) a intervalos configurables (típicamente 1-3 segundos). Los respaldos se promueven a MASTER si los anuncios cesan durante períodos de timeout configurados.

Preempción: Comportamiento configurable que determina si un sistema de mayor prioridad reclama automáticamente el rol MASTER después de recuperarse de un fallo. La preempción previene oscilaciones pero puede deshabilitarse para evitar disrupciones innecesarias.

Cálculo de Prioridad: Cada sistema tiene una prioridad base configurada (1-255). Las verificaciones de salud basadas en scripts pueden ajustar dinámicamente la prioridad efectiva, habilitando lógica sofisticada de failover basada en salud de la aplicación en lugar de solo alcanzabilidad del sistema.

Arquitectura de Keepalived

Keepalived consiste en varios componentes integrados:

Stack VRRP: Implementación central de RFC 3768/5798 proporcionando gestión de IP virtual, envío/recepción de anuncios y transiciones de estado entre estados MASTER/BACKUP/FAULT.

Framework de Verificación de Salud: Ejecuta scripts externos a intervalos configurables, ajustando la prioridad del sistema basada en códigos de salida. Los scripts pueden validar salud de aplicación, conectividad de base de datos, espacio en disco o cualquier criterio personalizado.

Sistema de Notificación: Dispara scripts definidos por el usuario en transiciones de estado (MASTER/BACKUP/FAULT), habilitando integración con sistemas de monitoreo, infraestructura de logging o flujos de trabajo de remediación automatizada.

Gestión de Direcciones IP: Agrega/elimina automáticamente direcciones IP virtuales usando el stack de red del kernel. Soporta transmisión de paquetes ARP/NDP asegurando que los dispositivos de red actualicen asociaciones de direcciones MAC cuando ocurre failover.

Integración LVS: Integración opcional con Linux Virtual Server para balanceo de carga, aunque la mayoría de despliegues modernos usan Keepalived exclusivamente para failover de IP con balanceadores de carga separados como HAProxy.

Proceso de Failover

Entender la secuencia de failover es esencial para optimizar tiempos y confiabilidad:

Detección de Fallo: El nodo BACKUP detecta anuncios VRRP faltantes después de (advert_int × 3) + skew_time
Evaluación de Prioridad: Los nodos restantes comparan prioridades; el más alto se convierte en nuevo MASTER
Transición de Estado: El nuevo MASTER transiciona de estado BACKUP a MASTER
Activación de Dirección IP: El nuevo MASTER agrega IP virtual a la interfaz de red
ARP Gratuito: Difunde paquetes ARP gratuitos actualizando infraestructura de red
Transmisión de Anuncios: El nuevo MASTER comienza a enviar anuncios VRRP
Ejecución de Notificación: El script notify_master opcional se ejecuta

El failover típico se completa en 3-10 segundos dependiendo de la configuración, con despliegues optimizados logrando failover subsegundo.

Requisitos Previos

Requisitos de Hardware

Especificaciones Mínimas del Sistema:

2 sistemas físicos o virtuales para redundancia (3+ recomendado para votación basada en quórum)
1 núcleo de CPU por instancia de Keepalived
512MB RAM mínimo (1GB+ para verificaciones de salud complejas)
Interfaces de red duales recomendadas (redes de gestión y servicio separadas)

Requisitos de Red:

Conectividad de Capa 2 entre nodos Keepalived (mismo dominio de broadcast)
Protocolo IP 112 (VRRP) permitido a través de firewalls y switches
Soporte multicast en infraestructura de red (o configuración VRRP unicast)
Latencia sub-10ms entre nodos para rendimiento óptimo

Asignación de IP Virtual:

Dirección(es) IP reservada(s) en la misma subred que interfaces físicas
Direcciones IP no asignadas a ninguna interfaz física
Registros DNS apuntando a IPs virtuales en lugar de direcciones de nodos físicos

Requisitos de Software

Compatibilidad del Sistema Operativo:

RHEL/Rocky Linux 8/9, Ubuntu 20.04/22.04 LTS, Debian 11/12
Kernel 3.10+ (4.x+ recomendado para optimizaciones de rendimiento de red)

Instalación (RHEL/Rocky):

# Install Keepalived
dnf install -y keepalived

# Enable service
systemctl enable keepalived

Instalación (Ubuntu/Debian):

# Install Keepalived
apt update
apt install -y keepalived

# Enable service
systemctl enable keepalived

Verificar Instalación:

# Check version
keepalived --version

# Verify VRRP support
keepalived --dump-conf

Configuración de Red

Configuración del Firewall:

# Allow VRRP (protocol 112)
firewall-cmd --permanent --add-rich-rule='rule protocol value="vrrp" accept'

# Allow multicast for VRRP advertisements
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" destination address="224.0.0.18" accept'

firewall-cmd --reload

Configuración SELinux (si está en modo enforcing):

# Allow Keepalived to manage network interfaces
setsebool -P nis_enabled 1

# Create custom policy if needed
audit2allow -a -M keepalived_custom
semodule -i keepalived_custom.pp

Parámetros del Kernel:

# Enable IP forwarding (if routing required)
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.d/99-keepalived.conf

# Disable ARP response on all interfaces except designated
echo "net.ipv4.conf.all.arp_ignore = 1" >> /etc/sysctl.d/99-keepalived.conf
echo "net.ipv4.conf.all.arp_announce = 2" >> /etc/sysctl.d/99-keepalived.conf

sysctl -p /etc/sysctl.d/99-keepalived.conf

Configuración Avanzada

Configuración Básica Maestro-Respaldo

Configuración del Nodo MASTER (/etc/keepalived/keepalived.conf):

global_defs {
    router_id LB_MASTER_01
    vrrp_version 3
    vrrp_skip_check_adv_addr
    vrrp_strict
    vrrp_garp_interval 0
    vrrp_gna_interval 0
}

vrrp_script check_haproxy {
    script "/usr/local/bin/check_haproxy.sh"
    interval 2
    timeout 3
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass SecureVRRPPass123!
    }

    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:1
    }

    track_script {
        check_haproxy
    }

    notify_master "/usr/local/bin/notify_master.sh"
    notify_backup "/usr/local/bin/notify_backup.sh"
    notify_fault "/usr/local/bin/notify_fault.sh"
    notify_stop "/usr/local/bin/notify_stop.sh"
}

Configuración del Nodo BACKUP (/etc/keepalived/keepalived.conf):

global_defs {
    router_id LB_BACKUP_01
    vrrp_version 3
    vrrp_skip_check_adv_addr
    vrrp_strict
}

vrrp_script check_haproxy {
    script "/usr/local/bin/check_haproxy.sh"
    interval 2
    timeout 3
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass SecureVRRPPass123!
    }

    virtual_ipaddress {
        192.168.1.100/24 dev eth0 label eth0:1
    }

    track_script {
        check_haproxy
    }

    notify_master "/usr/local/bin/notify_master.sh"
    notify_backup "/usr/local/bin/notify_backup.sh"
    notify_fault "/usr/local/bin/notify_fault.sh"
    notify_stop "/usr/local/bin/notify_stop.sh"
}

Scripts de Verificación de Salud

Verificación de Salud de HAProxy (/usr/local/bin/check_haproxy.sh):

#!/bin/bash
# Check HAProxy process and functionality

# Check if process is running
if ! pidof haproxy > /dev/null; then
    exit 1
fi

# Check HAProxy stats socket
if ! echo "show info" | socat stdio /run/haproxy/admin.sock > /dev/null 2>&1; then
    exit 1
fi

# Verify at least one backend is available
BACKEND_UP=$(echo "show stat" | socat stdio /run/haproxy/admin.sock 2>/dev/null | \
    grep -v "^#" | grep "UP" | wc -l)

if [ "$BACKEND_UP" -lt 1 ]; then
    exit 1
fi

exit 0

Verificación de Salud de Servicio HTTP (/usr/local/bin/check_http.sh):

#!/bin/bash
# Check HTTP service availability

VIP="192.168.1.100"
PORT="80"
EXPECTED_CODE="200"

# Test HTTP response
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 3 http://${VIP}:${PORT}/health)

if [ "$HTTP_CODE" == "$EXPECTED_CODE" ]; then
    exit 0
else
    exit 1
fi

Verificación de Conectividad de Base de Datos (/usr/local/bin/check_database.sh):

#!/bin/bash
# Check database connectivity through proxy

DB_HOST="192.168.1.100"
DB_PORT="3306"
DB_USER="health_check"
DB_PASS="check_password"

# Test MySQL connectivity
if timeout 5 mysql -h "$DB_HOST" -P "$DB_PORT" -u "$DB_USER" -p"$DB_PASS" \
    -e "SELECT 1" > /dev/null 2>&1; then
    exit 0
else
    exit 1
fi

Hacer scripts ejecutables:

chmod +x /usr/local/bin/check_*.sh

Scripts de Notificación

Notificación de Master (/usr/local/bin/notify_master.sh):

#!/bin/bash
# Actions when becoming MASTER

TYPE=$1
NAME=$2
STATE=$3

LOG_FILE="/var/log/keepalived-notify.log"
ALERT_EMAIL="[email protected]"

{
    echo "$(date): Transitioned to MASTER state"
    echo "Type: $TYPE, Name: $NAME, State: $STATE"
} | tee -a "$LOG_FILE"

# Send notification
echo "Server $(hostname) is now MASTER for $NAME" | \
    mail -s "Keepalived: MASTER Transition" "$ALERT_EMAIL"

# Update monitoring system
curl -X POST http://monitoring.example.com/api/keepalived/master \
    -d "{\"host\": \"$(hostname)\", \"instance\": \"$NAME\"}"

# Execute custom logic (e.g., update DNS, start services)
# systemctl start application-service

Notificación de Backup (/usr/local/bin/notify_backup.sh):

#!/bin/bash
# Actions when transitioning to BACKUP

TYPE=$1
NAME=$2
STATE=$3

LOG_FILE="/var/log/keepalived-notify.log"

{
    echo "$(date): Transitioned to BACKUP state"
    echo "Type: $TYPE, Name: $NAME, State: $STATE"
} | tee -a "$LOG_FILE"

# Stop services that should only run on MASTER
# systemctl stop application-service

Notificación de Fallo (/usr/local/bin/notify_fault.sh):

#!/bin/bash
# Actions when entering FAULT state

TYPE=$1
NAME=$2
STATE=$3

LOG_FILE="/var/log/keepalived-notify.log"
ALERT_EMAIL="[email protected]"

{
    echo "$(date): Entered FAULT state - CRITICAL"
    echo "Type: $TYPE, Name: $NAME, State: $STATE"
} | tee -a "$LOG_FILE"

# Send critical alert
echo "Server $(hostname) has entered FAULT state for $NAME" | \
    mail -s "CRITICAL: Keepalived FAULT" "$ALERT_EMAIL"

# Trigger incident in monitoring system
curl -X POST http://monitoring.example.com/api/keepalived/fault \
    -d "{\"host\": \"$(hostname)\", \"instance\": \"$NAME\", \"severity\": \"critical\"}"

Hacer scripts de notificación ejecutables:

chmod +x /usr/local/bin/notify_*.sh

Configuración de Múltiples IPs Virtuales

Soportar múltiples servicios con IPs virtuales separadas:

vrrp_instance VI_WEB {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass WebVIPPass123!
    }

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_haproxy
    }
}

vrrp_instance VI_DB {
    state MASTER
    interface eth1
    virtual_router_id 52
    priority 101
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass DbVIPPass123!
    }

    virtual_ipaddress {
        192.168.2.100/24
    }

    track_script {
        check_database
    }
}

Configuración VRRP Unicast

Para entornos donde el multicast es problemático:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    # Unicast configuration
    unicast_src_ip 192.168.1.11
    unicast_peer {
        192.168.1.12
        192.168.1.13
    }

    authentication {
        auth_type PASS
        auth_pass SecureVRRPPass123!
    }

    virtual_ipaddress {
        192.168.1.100/24
    }
}

Configuración de Soporte IPv6

vrrp_instance VI_IPV6 {
    state MASTER
    interface eth0
    virtual_router_id 61
    priority 101
    advert_int 1

    virtual_ipaddress {
        2001:db8:1::100/64
    }

    # IPv6-specific gratuitous neighbor advertisements
    garp_master_delay 5
}

Optimización de Rendimiento

Configuración de Failover Agresivo

Minimizar tiempo de failover para servicios críticos:

global_defs {
    vrrp_garp_master_delay 1
    vrrp_garp_master_repeat 3
    vrrp_garp_master_refresh 10
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1  # Advertise every second

    # Fast failure detection
    preempt_delay 0
    garp_master_delay 1

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_service weight -30 fall 1 rise 1
    }
}

Configuración Eficiente en Recursos

Optimizar para entornos con muchas instancias:

global_defs {
    # Reduce resource consumption
    vrrp_check_unicast_src
    vrrp_skip_check_adv_addr

    # Optimize timers
    vrrp_garp_interval 5
    vrrp_gna_interval 5
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 3  # Less frequent advertisements

    # Disable preemption to reduce transitions
    nopreempt

    virtual_ipaddress {
        192.168.1.100/24
    }
}

Configuración de Prioridad Multi-Nivel

Implementar lógica sofisticada de failover:

vrrp_script check_primary_service {
    script "/usr/local/bin/check_primary.sh"
    interval 2
    weight -50  # Large penalty for critical service failure
    fall 2
    rise 2
}

vrrp_script check_secondary_service {
    script "/usr/local/bin/check_secondary.sh"
    interval 5
    weight -10  # Small penalty for non-critical service
    fall 3
    rise 3
}

vrrp_script check_resource_exhaustion {
    script "/usr/local/bin/check_resources.sh"
    interval 10
    weight -30  # Penalty for resource issues
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_primary_service
        check_secondary_service
        check_resource_exhaustion
    }
}

Patrones de Alta Disponibilidad

Alta Disponibilidad de Balanceador de Carga

HAProxy con failover de Keepalived:

Arquitectura: Dos nodos HAProxy con IP virtual compartida

Configuración del Nodo 1:

vrrp_script check_haproxy {
    script "killall -0 haproxy"
    interval 2
    weight -20
}

vrrp_instance LB_VIP {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1

    virtual_ipaddress {
        192.168.1.100/24
    }

    track_script {
        check_haproxy
    }

    notify_master "/usr/local/bin/lb_notify_master.sh"
}

Script de Notificación (/usr/local/bin/lb_notify_master.sh):

#!/bin/bash
# Update DNS or monitoring when becoming master

# Log transition
logger "HAProxy Load Balancer is now MASTER"

# Update monitoring
curl -X POST http://monitoring/api/haproxy/master -d "{\"host\": \"$(hostname)\"}"

# Ensure HAProxy is running and healthy
systemctl is-active haproxy || systemctl restart haproxy

Alta Disponibilidad de Proxy de Base de Datos

PostgreSQL Pgpool-II con Keepalived:

vrrp_script check_pgpool {
    script "psql -h 127.0.0.1 -p 9999 -U health_check -c 'SELECT 1' > /dev/null 2>&1"
    interval 3
    weight -30
    fall 2
    rise 2
}

vrrp_instance PGPOOL_VIP {
    state MASTER
    interface eth0
    virtual_router_id 61
    priority 101
    advert_int 1

    virtual_ipaddress {
        192.168.1.110/24
    }

    track_script {
        check_pgpool
    }

    notify_master "/usr/local/bin/pgpool_promote.sh"
    notify_backup "/usr/local/bin/pgpool_demote.sh"
}

Alta Disponibilidad de API Gateway

Múltiples instancias de API gateway con failover automático:

vrrp_script check_api_gateway {
    script "/usr/local/bin/check_api.sh"
    interval 2
    weight -40
    fall 2
    rise 3
}

vrrp_instance API_VIP {
    state MASTER
    interface eth0
    virtual_router_id 71
    priority 101
    advert_int 1

    virtual_ipaddress {
        192.168.1.120/24
    }

    track_script {
        check_api_gateway
    }

    # Track interface state
    track_interface {
        eth0 weight -50
        eth1 weight -20
    }
}

Monitoreo y Observabilidad

Monitoreo del Estado de Keepalived

Verificar Estado VRRP:

# View Keepalived status
systemctl status keepalived

# Check VRRP instance state
ip addr show | grep -A2 eth0

# View current master/backup state
journalctl -u keepalived -n 50 --no-pager | grep "Entering MASTER\|Entering BACKUP"

Script de Monitoreo:

#!/bin/bash
# /usr/local/bin/monitor_keepalived.sh

LOG_FILE="/var/log/keepalived-monitor.log"
ALERT_EMAIL="[email protected]"

# Check if Keepalived is running
if ! systemctl is-active --quiet keepalived; then
    echo "$(date): Keepalived service is not running" >> "$LOG_FILE"
    echo "Keepalived is DOWN on $(hostname)" | mail -s "CRITICAL: Keepalived Down" "$ALERT_EMAIL"
    exit 1
fi

# Determine current state
CURRENT_STATE=$(journalctl -u keepalived -n 100 --no-pager | \
    grep "Entering MASTER\|Entering BACKUP" | tail -1 | awk '{print $NF}')

# Check if VIP is present (indicates MASTER state)
VIP="192.168.1.100"
if ip addr show | grep -q "$VIP"; then
    STATE="MASTER"
else
    STATE="BACKUP"
fi

echo "$(date): Current state: $STATE" >> "$LOG_FILE"

# Send metrics to monitoring system
curl -X POST http://monitoring.example.com/api/metrics \
    -d "{\"host\": \"$(hostname)\", \"service\": \"keepalived\", \"state\": \"$STATE\", \"timestamp\": $(date +%s)}"

Integración SNMP

Habilitar monitoreo SNMP para Keepalived:

# Install SNMP daemon
dnf install -y net-snmp net-snmp-utils

# Configure SNMP
cat >> /etc/snmp/snmpd.conf << EOF
rocommunity public
syslocation "DataCenter 1"
syscontact "[email protected]"
EOF

systemctl enable --now snmpd

Consultar Keepalived vía SNMP:

# Check VRRP state via SNMP
snmpwalk -v2c -c public localhost VRRP-MIB::vrrpOperState

Exportador Prometheus

Exportador personalizado de Prometheus para métricas de Keepalived:

#!/usr/bin/env python3
# /usr/local/bin/keepalived_exporter.py

from prometheus_client import start_http_server, Gauge
import subprocess
import time
import re

# Metrics
keepalived_state = Gauge('keepalived_vrrp_state', 'VRRP state (1=MASTER, 0=BACKUP, -1=FAULT)')
keepalived_priority = Gauge('keepalived_vrrp_priority', 'Current VRRP priority')

def get_keepalived_state():
    try:
        result = subprocess.run(['journalctl', '-u', 'keepalived', '-n', '50', '--no-pager'],
                                capture_output=True, text=True)

        if 'Entering MASTER' in result.stdout:
            return 1
        elif 'Entering BACKUP' in result.stdout:
            return 0
        elif 'Entering FAULT' in result.stdout:
            return -1
    except Exception as e:
        print(f"Error: {e}")
        return -1

def update_metrics():
    state = get_keepalived_state()
    keepalived_state.set(state)
    # Additional metric collection logic

if __name__ == '__main__':
    start_http_server(9101)
    while True:
        update_metrics()
        time.sleep(10)

Solución de Problemas

Escenario de Cerebro Dividido (Split-Brain)

Síntoma: Ambos nodos creen que son MASTER, causando IPs duplicadas.

Diagnóstico:

# Check VRRP state on both nodes
ip addr show | grep 192.168.1.100

# Verify VRRP communication
tcpdump -i eth0 proto 112

# Check for network partitioning
ping -c 5 other-node-ip

Resolución:

# Verify firewall allows VRRP
firewall-cmd --list-all

# Check for asymmetric routing issues
ip route show

# Restart Keepalived on one node to force resynchronization
systemctl restart keepalived

# Enable VRRP packet logging
echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf
sysctl -p

Oscilación Entre Estados

Síntoma: Transiciones rápidas entre estados MASTER/BACKUP.

Diagnóstico:

# Monitor state transitions
journalctl -u keepalived -f | grep "Entering"

# Check health check script reliability
/usr/local/bin/check_haproxy.sh
echo $?  # Should consistently return 0 or 1

Resolución:

# Increase health check fall/rise thresholds
vrrp_script check_service {
    script "/usr/local/bin/check_service.sh"
    interval 3
    fall 3  # Require 3 consecutive failures
    rise 3  # Require 3 consecutive successes
    weight -20
}

# Increase advertisement interval
vrrp_instance VI_1 {
    advert_int 2  # Slower detection but more stable
}

# Disable preemption to prevent automatic takeovers
vrrp_instance VI_1 {
    nopreempt
}

VIP No Aparece en la Interfaz

Síntoma: La IP virtual no aparece después de transición a MASTER.

Diagnóstico:

# Check Keepalived logs
journalctl -u keepalived -n 100 --no-pager

# Verify interface configuration
ip addr show eth0

# Check for SELinux denials
ausearch -m avc -ts recent | grep keepalived

Resolución:

# Verify interface name in configuration
# /etc/keepalived/keepalived.conf
# virtual_ipaddress {
#     192.168.1.100/24 dev eth0
# }

# Check NetworkManager doesn't interfere
nmcli device set eth0 managed no

# Disable NetworkManager for Keepalived-managed interfaces
cat >> /etc/NetworkManager/conf.d/keepalived.conf << EOF
[keyfile]
unmanaged-devices=interface-name:eth0:1
EOF

systemctl restart NetworkManager keepalived

ARP Gratuito No Actualiza la Red

Síntoma: Los clientes continúan conectándose al antiguo MASTER después del failover.

Diagnóstico:

# Check ARP table on clients
arp -an | grep 192.168.1.100

# Capture gratuitous ARP on switch
tcpdump -i eth0 arp and host 192.168.1.100

Resolución:

# Increase gratuitous ARP frequency
global_defs {
    vrrp_garp_master_delay 1
    vrrp_garp_master_repeat 5
    vrrp_garp_master_refresh 10
}

# Enable ARP caching prevention
echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore

Fallos de Autenticación

Síntoma: Los nodos no forman grupo VRRP a pesar de la configuración.

Diagnóstico:

# Check for authentication mismatch in logs
journalctl -u keepalived | grep -i "authentication"

# Verify password matches on all nodes
grep auth_pass /etc/keepalived/keepalived.conf

Resolución:

# Ensure identical authentication on all nodes
# Passwords are case-sensitive and must match exactly

# Temporarily disable authentication for testing
# authentication {
#     auth_type NONE
# }

# Restart Keepalived
systemctl restart keepalived

Conclusión

Keepalived proporciona capacidades de alta disponibilidad y failover automático de grado empresarial esenciales para eliminar puntos únicos de fallo en infraestructura crítica. A través de la implementación de VRRP, verificación sofisticada de salud y mecanismos flexibles de notificación, Keepalived asegura disponibilidad continua del servicio incluso durante fallos de hardware, caídas de software u operaciones de mantenimiento.

Los despliegues exitosos de Keepalived requieren atención cuidadosa a la configuración de red, confiabilidad de verificaciones de salud y optimización de tiempos de failover. Comprender los fundamentos de VRRP, cálculo de prioridad y comportamiento de transición de estados permite a los ingenieros diseñar arquitecturas robustas de failover apropiadas para requisitos específicos de aplicación y escenarios de fallo.

Las organizaciones deben implementar monitoreo completo de transiciones de estado de Keepalived, resultados de verificaciones de salud y eventos de failover para mantener visibilidad en el comportamiento de la infraestructura de alta disponibilidad. Las pruebas regulares de escenarios de failover, incluyendo fallos planificados y no planificados, validan la corrección de la configuración y aseguran preparación operacional cuando ocurren fallos reales.

A medida que la infraestructura evoluciona hacia arquitecturas contenedorizadas y cloud-native, Keepalived continúa proporcionando valor en entornos híbridos donde el failover tradicional basado en IP complementa plataformas modernas de orquestación, manteniendo su posición como tecnología fundamental para soluciones de alta disponibilidad basadas en Linux.

Keepalived para Alta Disponibilidad (VRRP): Guía de Failover de IP y Redundancia de Servicios

Keepalived para Alta Disponibilidad (VRRP): Guía de Failover de IP y Redundancia de Servicios

Introducción

Teoría y Conceptos Fundamentales

Protocolo de Redundancia de Router Virtual (VRRP)

Arquitectura de Keepalived

Proceso de Failover

Requisitos Previos

Requisitos de Hardware

Requisitos de Software

Configuración de Red

Configuración Avanzada

Configuración Básica Maestro-Respaldo

Scripts de Verificación de Salud

Scripts de Notificación

Configuración de Múltiples IPs Virtuales

Configuración VRRP Unicast

Configuración de Soporte IPv6

Optimización de Rendimiento

Configuración de Failover Agresivo

Configuración Eficiente en Recursos

Configuración de Prioridad Multi-Nivel

Patrones de Alta Disponibilidad

Alta Disponibilidad de Balanceador de Carga

Alta Disponibilidad de Proxy de Base de Datos

Alta Disponibilidad de API Gateway

Monitoreo y Observabilidad

Monitoreo del Estado de Keepalived

Integración SNMP

Exportador Prometheus

Solución de Problemas

Escenario de Cerebro Dividido (Split-Brain)

Oscilación Entre Estados

VIP No Aparece en la Interfaz

ARP Gratuito No Actualiza la Red

Fallos de Autenticación

Conclusión

Latest Video

Get $20 Free Credit