Introducción a Keepalived y su rol en la alta disponibilidad

Keepalived es una herramienta fundamental en entornos de infraestructura crítica, diseñada para garantizar la alta disponibilidad (HA) evitando puntos únicos de fallo. Su nombre indica claramente su propósito: mantener servicios activos mediante mecanismos de conmutación automática. Este sistema se basa principalmente en el protocolo VRRP (Virtual Router Redundancy Protocol), que permite a múltiples servidores coordinarse para ofrecer una dirección IP virtual compartida, asegurando continuidad incluso si uno de ellos falla.

El fundamento: el protocolo VRRP

VRRP fue originalmente concebido para proporcionar redundancia en ruteadores de red. En lugar de depender de un único dispositivo, varios ruteadores pueden formar un grupo virtual, donde uno actúa como maestro y los demás como reserva. El maestro responde por una IP virtual común, y si deja de funcionar, otro nodo asume su rol automáticamente.

Keepalived implementa fielmente este protocolo, extendiéndolo más allá del enrutamiento tradicional hacia la supervisión de servicios como balanceadores HTTP, proxies o bases de datos. Cada grupo VRRP se identifica mediante un VRID (Virtual Router ID), que determina tanto el grupo lógico como la dirección MAC multicast asociada.

Arquitectura interna de Keepalived

Keepalived sigue un diseño modular compuesto por varios componentes clave:

• core: gestiona el proceso principal, carga la configuración y coordina los módulos.
• vrrp: implementa el subproceso VRRPD encargado de enviar anuncios y manejar transiciones de estado.
• check: realiza comprobaciones activas sobre servicios (HTTP, TCP, scripts personalizados).
• libipvs*: interactúa con el plano de datos de LVS (Linux Virtual Server) para gestionar reglas de balanceo.
• libipfwc: facilita operaciones relacionadas con iptables cuando se integra con LVS.

Al iniciarse, Keepalived crea un proceso padre y dos hijos independientes vigilados por un watchdog del sistema:

• Uno dedicado al manejo de VRRP.
• Otro responsable de las verificaciones de salud (health checking).

Si el módulo de salud detecta una falla en un servicio crítico del nodo maestro, notifica al módulo VRRP para que abandone el estado MASTER, elimine la IP virtual y permita que un nodo secundario tome el control. Estructura del archivo de configuración

La configuración de Keepalived se organiza en tres bloques principales dentro de un solo archivo (/etc/keepalived/keepalived.conf):

1. Configuración global

global_defs {
    router_id lb01
    notification_email {
        admin@empresa.com
        soporte@empresa.com
    }
    notification_email_from keepalived@empresa.com
    smtp_server mail.local
    smtp_connect_timeout 60
}

• router_id: Nombre único que identifica al nodo.
• notification_email: Lista de destinatarios para alertas.
• smtp_server: Servidor SMTP usado para notificaciones por correo.

2. Grupos estáticos (opcional)

Permite agrupar múltiples instancias VRRP para que cambien de estado simultáneaemnte:

vrrp_sync_group G_HTTP {
    group {
        VI_HTTP
        VI_DB
    }
    notify_master /scripts/failover_master.sh
    notify_backup /scripts/failover_backup.sh
}

Este mecanismo es útil cuando servicios interdependientes deben migrar juntos durante una conmutación.

3. Instancia VRRP

Define el comportamiento específico de cada grupo de alta disponibilidad:

vrrp_instance VI_HTTP {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 95
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secreto123
    }
    virtual_ipaddress {
        192.168.10.100/24 dev eth0 label eth0:VIP
    }
    track_interface {
        eth0
        eth1
    }
    track_script {
        chk_nginx_weight
    }
}

• state: Estado inicial deseado (MASTER o BACKUP), aunque el ganador final depende de la prioridad.
• interface: Interfaz física donde se anunciará la IP virtual.
• priority: Valor numérico que determina quién será el maestro; mayor valor = mayor preferencia.
• virtual_ipaddress: IPs flotantes añadidas o removidas según el rol actual.
• track_interface: Falla si alguna interfaz listada entra en estado inactivo.
• track_script: Vincula un script externo cuyo resultado afectará la prioridad efectiva.

4. Scripts de monitoreo

Se definen fuera de las instancias y luego se referencian. Permiten evaluar condiciones dinámicas como la disponibilidad de un servicio:

vrrp_script chk_nginx_weight {
    script "/usr/local/bin/check_service nginx"
    interval 3
    weight 15
    timeout 5
}

Si el script devuelve error, la prioridad del nodo disminuye en 15 unidades, posiblemente desencadenando una transición a BACKUP si otro nodo tiene mayor puntuación.

5. Integración opcional con LVS

Aunque no obligatoria, Keepalived puede gestionar directamente reglas de balanceo IPVS:

virtual_server 192.168.10.100 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    persistence_timeout 300
    protocol TCP

    real_server 192.168.10.11 80 {
        weight 100
        inhibit_on_failure
        TCP_CHECK {
            connect_port 80
            connect_timeout 4
            nb_get_retry 3
            delay_before_retry 2
        }
    }

    real_server 192.168.10.12 80 {
        weight 100
        inhibit_on_failure
        HTTP_GET {
            url {
                path /status.html
                status_code 200
            }
            connect_port 80
            connect_timeout 3
        }
    }
}

• lb_kind: Modo de operación — NAT, DR (Direct Routing) o TUN (Tunneling).
• inhibit_on_failure: Evita eliminar el servidor real de IPVS; solo reduce su peso a cero.
• TCP_CHECK / HTTP_GET: Mecanismos flexibles para validar estado del backend.

Ejemplo práctico: clúster Nginx acttivo-pasivo

Nodo primario (lb-primary):

global_defs {
    router_id lb-primary
    notification_email { ops@empresa.com }
    smtp_server localhost
}

vrrp_script chk_nginx {
    script "/opt/scripts/test_nginx.sh"
    interval 2
    weight 30
}

vrrp_instance VI_NGINX {
    state MASTER
    interface ens3
    virtual_router_id 88
    priority 105
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass klave789
    }
    virtual_ipaddress {
        192.168.10.50/24 dev ens3
    }
    track_script {
        chk_nginx
    }
}

Nodo secundario (lb-backup):

vrrp_instance VI_NGINX {
    state BACKUP
    interface ens3
    virtual_router_id 88
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass klave789
    }
    virtual_ipaddress {
        192.168.10.50/24 dev ens3
    }
    track_script {
        chk_nginx
    }
}

Script de verificación /opt/scripts/test_nginx.sh:

#!/bin/bash
if ! curl -f http://localhost/health >/dev/null 2>&1; then
    exit 1
fi
exit 0

Si Nginx falla, el script devuelve error, reduciendo la prioridad efectiva del nodo en 30 puntos, lo cual desencadena una conmutación inmediata.