Keepalived s'impose comme un composant essentiel pour garantir la résilience des architectures distributées. Son rôle principal consiste à superviser l'état de santé des serveurs d'application et à orchestrer automatiquement le basculement (failover) en cas de défaillance matérielle ou logicielle. Lorsqu'un nœud devient inaccessible, l'outil le retire dynamiquement du pool actif et le réintègre dès que ses services sont rétablis. Cette approche élimine effiaccement les points de défaillence uniques inhérents aux configurations de routage statique.

Fonctionnement et architecture interne

Le moteur repose sur le protocole VRRP (Virtual Router Redundancy Protocol). Plusieurs hôtes forment un groupe logique avec un rôle de maître et un ou plusieurs rôles de secours. Le maître diffuse périodiquement des signaux de présence (heartbeats) via le multicast. Si un nœud de secours ne reçoit plus ces signaux pendant un intervalle défini, il déclenche une élection basée sur les priorités attribuées pour prendre le contrôle de l'adresse IP virtuelle (VIP).

L'architecture logicielle se décompose en trois sous-systèmes indépendants :

• core : orchestration du processus principal, gestion des signaux système et analyse du fichier de configuration global.
• check : supervision des services cibles via des sondes personnalisées (HTTP, TCP, scripts shell, etc.).
• vrrp : implémentation stricte du protocole de redondance virtuelle et gestion des états maîtres/secours.

Structure de la configuration

La gestion s'effectue via un unique fichier keepalived.conf. Les blocs essentiels sont détaillés ci-dessous.

Bloc global (global_defs)

Définit les paramètres réseau de notification et l'identité du nœud.

global_defs {
   router_id srv-ctrl-01
   notification_email { equipe-ops@entreprise.net }
   notification_email_from alertes@entreprise.net
   smtp_server 10.0.0.50
   smtp_connect_timeout 15
   vrrp_strict
}

Surveillance externe (vrrp_script)

Configure une vérification périodique. En cas d'échec répété, la priorité du nœud est dégradée, forçant un basculement.

vrrp_script monitor_web {
   script "/etc/keepalived/scripts/verify_http.sh"
   interval 3
   weight -25
   fall 2
   rise 1
}

Instance VRRP (vrrp_instance)

Déclare l'instance de redondance, l'interface réseau concernée et la VIP attribuée.

vrrp_instance RES_01 {
   state BACKUP
   interface enp0s3
   virtual_router_id 101
   priority 90
   advert_int 2
   nopreempt
   authentication {
      auth_type PASS
      auth_pass MotDePasseSecurise2024
   }
   virtual_ipaddress {
      192.168.1.250/24
   }
   track_script {
      monitor_web
   }
}

Scénarios d'implémentation

Intégration avec un répartiteur de charge (Nginx / HAProxy)

Pour assurer une disponibilité totale, le script de surveillance doit vérifier le statut du proxy et stopper Keepalived en cas de panne, forçant ainsi le passage au nœud secondaire.

#!/usr/bin/env bash
# Script: /opt/monitoring/proxy_health.sh
TARGET_PORT=80
MAX_ATTEMPTS=3
DELAY=2

check_status() {
   curl -sf --max-time 3 http://localhost:${TARGET_PORT} >/dev/null 2>&1
   return $?
}

for i in $(seq 1 $MAX_ATTEMPTS); do
   if check_status; then
      exit 0
   fi
   sleep $DELAY
done

systemctl stop keepalived.service
exit 1

Le lien avec la configuration VRRP s'opère via le bloc track_script mentionné précédemment.

Protection d'un cluster MySQL

La synchronisation des bases exige une détection précise des pannes d'accès au moteur.

#!/usr/bin/env bash
# Script: /etc/keepalived/db_check.sh
DB_USER="admin_monitor"
DB_PASS="S3curePass!"
RETRIES=2

verify_db_connection() {
   mysql -u "${DB_USER}" -p"${DB_PASS}" -e "SELECT 1;" >/dev/null 2>&1
   return $?
}

for attempt in $(seq 1 $RETRIES); do
   if verify_db_connection; then
      exit 0
   fi
   sleep 1
done

systemctl disable --now keepalived.service
exit 1

L'association de ce script à l'instance VRRP permet un basculement automatique vers le nœud secondaire dès que le moteur de base de données répond de manière incorrecte ou refuse les connexions.

Couplage LVS / Keepalived (Mode DR)

LVS gère la répartition au niveau 4, tandis que Keepalived assure la haute disponibilité du directeur et vérifie l'état des serveurs réels. La configuration du directeur combine les blocs VRRP et virtual_server.

global_defs { router_id lb-director-01 }

vrrp_instance LVS_VIP {
   state MASTER
   interface eth0
   virtual_router_id 200
   priority 110
   advert_int 1
   authentication { auth_type PASS; auth_pass LVS_Key_2024 }
   virtual_ipaddress { 10.20.30.100/24 }
}

virtual_server 10.20.30.100 443 {
   delay_loop 5
   lb_algo wlc
   lb_kind DR
   persistence_timeout 120
   protocol TCP

   real_server 10.20.30.10 443 {
      weight 50
      TCP_CHECK { connect_timeout 5; nb_get_retry 3; delay_before_retry 2; connect_port 443 }
   }
   real_server 10.20.30.11 443 {
      weight 50
      TCP_CHECK { connect_timeout 5; nb_get_retry 3; delay_before_retry 2; connect_port 443 }
   }
}

Pour le mode Direct Routing (DR), les serveurs réels doivent accepter les requêtes destinées à la VIP sans répondre aux requêtes ARP contradictoires. Voici le script d'initialisation réseau à déployer sur chaque backend :

#!/usr/bin/env bash
# Script: /usr/local/bin/setup_lvs_rs.sh
LOCAL_VIP="10.20.30.100"
SUBNET_MASK="255.255.255.255"

ip addr add ${LOCAL_VIP}/${SUBNET_MASK} broadcast ${LOCAL_VIP} dev lo label lo:0
ip route add ${LOCAL_VIP} dev lo:0

sysctl -q -w net.ipv4.conf.lo.arp_ignore=1
sysctl -q -w net.ipv4.conf.lo.arp_announce=2
sysctl -q -w net.ipv4.conf.all.arp_ignore=1
sysctl -q -w net.ipv4.conf.all.arp_announce=2

echo "LVS Real Server configured for VIP ${LOCAL_VIP}"

Une fois appliqué, le flux entrant est distribué par le directeur, mais les réponses empruntent directement le lien réseau vers le client, optimisant ainsi la bande passante du répartiteur.

Gestion de la scission de cluster (Split-Brain)

Le phénomène de split-brain survient lorsque la liaison de communication entre le maître et le secours se dégrade ou coupe. Chaque nœud, estimant que l'autre est inactif, se proclame maître et s'attribue la VIP. Cela engendre des conflits de réponses réseau et une instabilité critique des services.

Stratégies d'atténuation :

• Multiplication des canaux de surveillance : utiliser des liaisons filaires redondantes ou vérifier la connectivité vers une passerelle tierce pour croiser les diagnostics.
• Mécanisme d'arbitrage externe : déployer un nœud témoin (quorum) ou un verrouillage sur stockage partagé pour trancher en cas d'incertitude.
• Contrôle strict du trafic VRRP : s'assurer que le protocole 112 et l'adresse multicast 224.0.0.18 ne sont pas filtrés par les pare-feu intermédiaires ou les politiques de sécurité réseau.