Keepalived et VRRP : haute disponibilité réseau sur Linux

En infrastructure, une adresse IP unique sur un serveur est un point de défaillance critique. Dès que ce serveur s'arrête, vos applications deviennent inaccessibles. Keepalived et le protocole VRRP (Virtual Router Redundancy Protocol, RFC 5798) résolvent ce problème en partageant une IP virtuelle entre plusieurs serveurs Linux.

Contrairement aux solutions "brutes" (DNS round-robin, load balancers externes), VRRP offre un basculement automatique en millisecondes sans intervention extérieure — ni DNS, ni configuration cloud.

1. Comment fonctionne VRRP — protocole, rôles master/backup, priorités
2. Installation et configuration Keepalived — déploiement complet sur Debian/RHEL
3. Health checks avancés — TCP, HTTP, scripts custom
4. Keepalived vs Pacemaker/Corosync — quand choisir quoi
5. Dépannage et monitoring — diagnostiquer les problèmes HA
6. Perspectives complémentaires — articles connexes
7. Sources et conclusion

Architecture master/backup et IP virtuelle

VRRP crée une IP partagée (Virtual IP ou VIP) entre deux ou plusieurs serveurs. L'un est master (actif), l'autre backup (en attente). Les clients ne connaissent que la VIP ; ils sont donc transparents au basculement.

┌──────────────────┐
│  Client A        │
│  Client B        │  → VIP 192.168.1.100 (MAC virtuelle)
│  Client C        │
└──────────────────┘
         ↑
         ├─ Trafic vers Master (192.168.1.10) [ACTIF]
         │
         └─ Basculement vers Backup (192.168.1.11) [ATTENTE]

Priorités et élection

• Plage de priorité : 0 à 255
• Valeur par défaut : 100
• Logique : priorité plus élevée gagne → devient master
• Preemption : si elle est activée, un serveur avec priorité supérieure retrouve le rôle master même après basculement

Multicast et advertisements

Keepalived envoie des advertisements VRRP :

• Destination : multicast 224.0.0.18, port 112
• Intervalle par défaut : 1 seconde
• Détection de défaillance : après 3 advertisements manqués (3 secondes par défaut), le backup prend le relais
• TTL : 255 (réseau local uniquement)

Si le master s'arrête, les advertisements cessent, le backup détecte le silence et devient master. Instantanément, la VIP migre vers le nouveau master via gratuitous ARP.

Installation

Debian/Ubuntu :

sudo apt update
sudo apt install keepalived
sudo systemctl enable keepalived

RHEL/CentOS/Rocky :

sudo dnf install keepalived
sudo systemctl enable keepalived

Configuration complète

Fichier : /etc/keepalived/keepalived.conf

Sur le serveur MASTER (192.168.1.10) :

global_defs {
  router_id MASTER_ROUTER
  script_user root
  enable_script_security
}

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

vrrp_instance VI_1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 150
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass P@ssw0rd123
  }
  virtual_ipaddress {
    192.168.1.100/24
  }
  track_script {
    check_app
  }
  notify_master "/usr/local/bin/notify_master.sh"
  notify_backup "/usr/local/bin/notify_backup.sh"
  notify_fault "/usr/local/bin/notify_fault.sh"
  preempt_delay 300
}

Sur le serveur BACKUP (192.168.1.11) :

global_defs {
  router_id BACKUP_ROUTER
  script_user root
  enable_script_security
}

vrrp_script check_app {
  script "/usr/local/bin/check_app.sh"
  interval 2
  weight -20
  fall 3
  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 P@ssw0rd123
  }
  virtual_ipaddress {
    192.168.1.100/24
  }
  track_script {
    check_app
  }
  notify_master "/usr/local/bin/notify_master.sh"
  notify_backup "/usr/local/bin/notify_backup.sh"
  notify_fault "/usr/local/bin/notify_fault.sh"
}

Clés de configuration

Appliquer la configuration

sudo systemctl restart keepalived
sudo systemctl status keepalived

Un serveur peut être up (réachable) mais son application morte. Keepalived surveille tout ça via des scripts.

Check TCP simple

vrrp_script check_http {
  script "/bin/sh -c 'curl -sf http://127.0.0.1:8080/health || exit 1'"
  interval 2
  weight -30
  fall 3
  rise 2
}

• weight -30 : si le check échoue, réduire la priorité de 30 points
• fall 3 : déclarer l'app down après 3 échecs consécutifs
• rise 2 : la déclarer à nouveau up après 2 succès

Check HTTPS avec certificat

vrrp_script check_https {
  script "/bin/sh -c 'timeout 3 openssl s_client -connect 127.0.0.1:443 -servername api.example.com </dev/null 2>&1 | grep -q CONNECTED && exit 0 || exit 1'"
  interval 3
  weight -50
}

Check custom (script shell)

Fichier /usr/local/bin/check_app.sh :

#!/bin/bash
# Vérifier plusieurs conditions
APP_PORT=8080
LOG_FILE="/var/log/app.log"
THRESHOLD_SECONDS=300

# Check 1: Port écoute
netstat -tuln | grep -q ":$APP_PORT " || exit 1

# Check 2: Fichier log pas stale (mis à jour dans les 5 dernières min)
if [ -f "$LOG_FILE" ]; then
  MTIME=$(date +%s -r "$LOG_FILE")
  NOW=$(date +%s)
  DIFF=$((NOW - MTIME))
  [ $DIFF -lt $THRESHOLD_SECONDS ] || exit 1
fi

# Check 3: Processus principal existe
pgrep -f "python /opt/app/main.py" > /dev/null || exit 1

exit 0

Permissions :

sudo chmod +x /usr/local/bin/check_app.sh

Les deux assurent la HA, mais pas au même niveau.

👉 Keepalived = "J'ai deux serveurs web, je veux une VIP qui bascule"

👉 Pacemaker = "J'ai un cluster de 5 nœuds, je dois orchestrer services, base de données, volumes NFS"

Vérifier l'état VRRP

# Sur le master
sudo journalctl -u keepalived -f

# Voir la priorité en temps réel
sudo cat /proc/net/vrrp_sysctl/vrrp_priority

Tcpdump pour voir les advertisements

sudo tcpdump -i eth0 -nn proto 112
# Sortie :
# IP 192.168.1.10 > 224.0.0.18: VRRP advertisement [Priority: 150]

Test de basculement (couper le master)

# Terminal 1 : Monitor les logs du backup
ssh backup-server "sudo journalctl -u keepalived -f"

# Terminal 2 : Couper le master
ssh master-server "sudo systemctl stop keepalived"

# Vérifier :
# - Log backup : VRRP transition BACKUP -> MASTER
# - Vérifier VIP depuis client : ping 192.168.1.100
# - Contrôler MAC : arp 192.168.1.100 (MAC du backup maintenant)

Monitoring SNMP

Keepalived expose des OIDs SNMP. Configurer dans keepalived.conf :

global_defs {
  enable_snmp
  snmp_socket udp:127.0.0.1:161
}

Puis interroger :

snmpget -v2c -c public localhost 1.3.6.1.4.1.9.9.500.1.1.0  # VRRP state

Pour une infrastructure HA robuste, découvrez aussi :

• HAProxy pour clustering HTTP avancé — load balancing stateful
• Pacemaker et Corosync : orchestration cluster complète — au-delà du failover IP
• Nginx comme reverse proxy haute disponibilité — HA L7

• Keepalived Official Manual
• RFC 5798 — VRRP v3 (remplace RFC 3768 v2)
• Linux Foundation — Clustering & HA
• Red Hat Documentation : RHEL Configuring Failover Clustering

Keepalived et VRRP offrent une solution élégante et légère pour la haute disponibilité réseau. Contrairement aux approches DNS ou cloud-natives, le basculement est instantané et autonome, sans dépendance externe.

Bien configuré (priorités correctes, health checks robustes, preempt_delay ajusté), ce duo devient invisible mais indispensable — vos clients ne verront jamais l'interruption.

Chez SHPV, nous déployons Keepalived sur infrastructure critique pour garantir une disponibilité continue du routage et des services d'infrastructure. C'est un élément clé de notre approche HA multi-couches : du réseau à l'application.

Prêt à sécuriser votre infrastructure ? Contactez nos équipes pour une étude de votre architecture HA.