Keepalived — VIP flottante et load balancing sans matériel dédié

Dans les architectures de production, la haute disponibilité (HA) est une exigence fondamentale. Lorsqu’un serveur tombe en panne, le service doit continuer à fonctionner sans interruption perceptible par les utilisateurs. Traditionnellement, garantir cette continuité nécessitait des équipements réseau dédiés et coûteux — commutateurs L4, balanceurs de charge matériels ou appliances propriétaires. Keepalived renverse cette approche en offrant une solution logicielle légère, éprouvée et entièrement gratuite, capable de gérer à la fois la haute disponibilité via VRRP et la répartition de charge via LVS (Linux Virtual Server).

Keepalived s’appuie sur deux mécanismes complémentaires : le protocole VRRP (Virtual Router Redundancy Protocol, RFC 5798) pour la gestion d’une adresse IP flottante (VIP), et le module noyau IPVS pour la répartition de charge au niveau L4. Ensemble, ils permettent à un cluster de serveurs de présenter une adresse IP unique aux clients, avec basculement automatique en quelques secondes en cas de défaillance du serveur maître.

Cet article vous guide à travers l’installation, la configuration et les bonnes pratiques de Keepalived sur Debian 12 (Bookworm) et Ubuntu 24.04 LTS, dans un scénario classique à deux nœuds avec VIP flottante et health checks applicatifs.

Prérequis et architecture cible

Pour suivre cet article, vous aurez besoin de deux serveurs Debian ou Ubuntu sur le même réseau L2, avec des adresses IP fixes. L’exemple ci-dessous utilise :

• lb01 (MASTER) : 192.168.1.10
• lb02 (BACKUP) : 192.168.1.11
• VIP (adresse virtuelle partagée) : 192.168.1.100

Les clients se connectent exclusivement à la VIP. Keepalived s’assure qu’elle est toujours portée par le nœud actif, quel que soit l’état des serveurs physiques. Ce modèle actif/passif est le plus courant ; Keepalived supporte également des configurations actif/actif via plusieurs instances VRRP distinctes.

Installation de Keepalived

Le paquet Keepalived est disponible dans les dépôts officiels Debian et Ubuntu sans source tierce :

sudo apt update && sudo apt install -y keepalived
sudo systemctl enable keepalived

Avant de démarrer le service, deux paramètres noyau sont indispensables. Le premier active le transfert de paquets IP entre interfaces (requis pour LVS), le second permet à un processus de s’attacher à une adresse IP pas encore assignée localement (indispensable pour la VIP lors du démarrage) :

cat >> /etc/sysctl.conf << 'EOF'
net.ipv4.ip_forward = 1
net.ipv4.ip_nonlocal_bind = 1
EOF
sysctl -p

Configuration VRRP — Nœud MASTER (lb01)

Le fichier de configuration principal est /etc/keepalived/keepalived.conf. Voici la configuration complète du nœud maître incluant un health check sur HAProxy :

cat > /etc/keepalived/keepalived.conf << 'EOF'
global_defs {
    router_id LB_MASTER
    notification_email {
        [email protected]
    }
    notification_email_from keepalived@lb01
    smtp_server 127.0.0.1
    smtp_connect_timeout 15
}

vrrp_script chk_haproxy {
    script "/usr/bin/pgrep haproxy"
    interval 2
    weight -20
    fall 2
    rise 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 150
    advert_int 1
    preempt_delay 30
    authentication {
        auth_type PASS
        auth_pass S3cr3tK3y!
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
    track_script {
        chk_haproxy
    }
    notify_master "/usr/local/bin/keepalived-notify.sh MASTER"
    notify_backup "/usr/local/bin/keepalived-notify.sh BACKUP"
    notify_fault  "/usr/local/bin/keepalived-notify.sh FAULT"
}
EOF

Quelques points clés :

• virtual_router_id 51 : identifiant VRRP partagé entre les deux nœuds (identique sur les deux serveurs).
• priority 150 : le maître a une priorité supérieure au backup (100).
• weight -20 : si le script de santé échoue, la priorité baisse de 20, déclenchant le basculement vers le backup.
• advert_int 1 : annonces VRRP envoyées toutes les secondes en multicast (224.0.0.18, protocole IP 112).
• preempt_delay 30 : attend 30 secondes après un redémarrage avant de reprendre la VIP, laissant le temps aux services de démarrer.

Configuration VRRP — Nœud BACKUP (lb02)

La configuration du backup est quasi identique, avec deux différences fondamentales — state BACKUP et priority 100 :

cat > /etc/keepalived/keepalived.conf << 'EOF'
global_defs {
    router_id LB_BACKUP
}

vrrp_script chk_haproxy {
    script "/usr/bin/pgrep haproxy"
    interval 2
    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 S3cr3tK3y!
    }
    virtual_ipaddress {
        192.168.1.100/24 dev eth0
    }
    track_script {
        chk_haproxy
    }
}
EOF

En cas de défaillance du maître (trois annonces VRRP manquées consécutives, soit ≤ 3 secondes avec advert_int 1), lb02 émet un Gratuitous ARP pour revendiquer la VIP et mettre à jour le cache ARP de tous les équipements du réseau.

Script de health check applicatif

Un health check robuste surveille la santé du service applicatif et pas seulement la disponibilité du nœud. Les paramètres fall 2 et rise 2 évitent les basculements intempestifs : le script doit échouer deux fois consécutives avant de déclencher le failover :

cat > /usr/local/bin/check_haproxy.sh < /dev/null; then
    echo "HAProxy process not running" >&2
    exit 1
fi

# Vérifier qu'HAProxy répond sur le port de stats
if ! ss -tlnp | grep -q ':8404 '; then
    echo "HAProxy stats socket not reachable" >&2
    exit 1
fi

exit 0
EOF
chmod +x /usr/local/bin/check_haproxy.sh

Load balancing avec IPVS (LVS)

Keepalived intègre nativement LVS via le module noyau IPVS pour répartir les connexions entre plusieurs backends réels. Ajoutez un bloc virtual_server dans keepalived.conf :

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind NAT
    protocol TCP

    real_server 192.168.1.20 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.1.21 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.1.22 80 {
        weight 2
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

L’algorithme wlc (weighted least connections) distribue préférentiellement le trafic vers le serveur le moins chargé, en tenant compte des poids. Le serveur avec weight 2 reçoit deux fois plus de connexions que les autres. Surveillez l’état du load balancer IPVS avec :

ipvsadm -L -n --stats

Démarrage et vérification

Démarrez Keepalived sur les deux nœuds, en commençant par le backup pour éviter une compétition à l’initialisation :

# Sur lb02 en premier
systemctl start keepalived

# Puis sur lb01
systemctl start keepalived

# Vérification de la VIP sur lb01
ip addr show eth0 | grep 192.168.1.100

# Logs en temps réel
journalctl -u keepalived -f

Test de basculement

Pour valider le comportement en conditions réelles, simulez une panne du maître :

# Sur lb01 — arrêter le service
systemctl stop keepalived

# Vérifier sur lb02 que la VIP a migré (en moins de 3 secondes)
ip addr show eth0 | grep 192.168.1.100

# Observer la transition dans les logs de lb02
journalctl -u keepalived --since "1 minute ago"

La transition est confirmée par ce message dans les logs de lb02 :

Keepalived_vrrp[1234]: VRRP_Instance(VI_1) Transition to MASTER STATE
Keepalived_vrrp[1234]: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth0 for 192.168.1.100

Redémarrez lb01 : sa priorité supérieure (150 contre 100) lui permet de récupérer automatiquement la VIP après le délai preempt_delay.

Bonnes pratiques en production

Authentification VRRP

Utilisez toujours un mot de passe partagé robuste (auth_type PASS) pour empêcher un serveur non autorisé de revendiquer la VIP sur votre réseau. Changez la valeur par défaut immédiatement après l’installation.

Unicast sur les réseaux cloud

Sur les hébergements cloud (Hetzner, OVH, AWS) où le multicast est filtré, remplacez les annonces multicast par unicast en ajoutant dans le bloc vrrp_instance :

unicast_src_ip 192.168.1.10
unicast_peer {
    192.168.1.11
}

Règles de pare-feu nftables

Autorisez le protocole VRRP (protocole IP 112) et les annonces multicast entre les nœuds :

# Autoriser VRRP entre les nœuds du cluster
nft add rule inet filter input ip protocol 112 accept
nft add rule inet filter input ip daddr 224.0.0.18 accept

# Ou avec une règle plus restrictive par source
nft add rule inet filter input ip saddr 192.168.1.11 ip protocol 112 accept

À lire également

• Pacemaker et Corosync — cluster haute disponibilité Linux — pour des clusters multi-nœuds avec gestion avancée des ressources et fencing STONITH.
• DRBD : réplication de blocs entre deux serveurs en temps réel — combiner Keepalived avec DRBD pour assurer à la fois la VIP flottante et la synchronisation des données.
• Tuning kernel Linux — paramètres sysctl essentiels pour la production — optimiser les paramètres réseau complémentaires à votre configuration Keepalived.
• nftables en pratique — remplacer iptables sur Debian/Ubuntu — configurer le pare-feu pour protéger et isoler votre cluster Keepalived.

Références

• Keepalived — Documentation officielle
• RFC 5798 — Virtual Router Redundancy Protocol (VRRP) Version 3
• Linux Virtual Server (LVS) Project
• Kifarunix — Configure Highly Available HAProxy with Keepalived on Ubuntu
• Ubuntu Manpage — keepalived.conf