L'implémentation d'une infrastructure robuste nécessite souvent l'élimination des points de défaillance uniques (SPOF). Keepalived s'impose comme une solution de référence pour garantir la haute disponibilité. Initialement conçu pour le projet LVS (Linux Virtual Server), il s'appuie sur le protocole VRRP (Virtual Router Redundancy Protocol) pour surveiller les services et assurer le basculement automatique des adresses IP entre plusieurs serveurs.
Principes de fonctionnement de Keepalived
Le mécanisme de basculement (failover) de Keepalived repose sur l'élection d'un nœud Maître (MASTER) et d'un ou plusieurs nœuds de secours (BACKUP). Le fonctionnement suit une logique de battement de cœur (heartbeat) :
- Le nœud MASTER diffuse régulièrement des messages publicitaires via multicast pour signaler sa présence.
- Si le nœud BACKUP cesse de recevoir ces signaux pendant un intervalle défini, il considère que le maître est défaillant.
- Le nœud de secours déclenche alors une procédure de reprise en s'attribuant l'adresse IP virtuelle (VIP).
- Une fois le nœud MASTER rétabli, il reprend généralement son rôle en fonction de sa priorité, et le BACKUP libère les ressources.
Installation du service Keepalived
Le déploiement s'effectue via les dépôts officiels des distributions Linux standards. Voici la commande pour les systèmes basés sur RHEL/CentOS :
yum update -y && yum install keepalived -y
Après l'installation, il est nécessaire d'activer le service pour qu'il démarre automatiquement avec le système :
systemctl enable keepalived
systemctl start keepalived
Configuration de la redondance
La configuration se situe principalement dans le ficheir /etc/keepalived/keepalived.conf. Voici un exemple de configuration différenciée pour un cluster composé de deux nœuds (proxy_01 et proxy_02).
Configuration du Nœud Maître (MASTER)
global_defs {
router_id PROXY_NODE_01
}
vrrp_instance SERVICE_HA {
state MASTER
interface ens33
virtual_router_id 60
priority 150
advert_int 1
authentication {
auth_type PASS
auth_pass sec_pwd_123
}
virtual_ipaddress {
10.0.0.100/24 dev ens33 label ens33:vip
}
}
Configuration du Nœud Esclave (BACKUP)
global_defs {
router_id PROXY_NODE_02
}
vrrp_instance SERVICE_HA {
state BACKUP
interface ens33
virtual_router_id 60
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass sec_pwd_123
}
virtual_ipaddress {
10.0.0.100/24 dev ens33 label ens33:vip
}
}
Dans ces fichiers :
router_id: Un identifiant unique pour le serveur dans le réseau.virtual_router_id: Doit être identique sur les deux nœuds pour appartenir au même groupe.priority: Le nœud avec la valeur la plus élevée devient le MASTER.virtual_ipaddress: Définit l'adresse IP flottante partagée par le cluster.
Surveillance de l'état du service Nginx
Par défaut, Keepalived vérifie si le système d'exploitation fonctionne. Cependant, si le processus Nginx s'arrête alors que le système reste actif, Keepalived ne basculera pas l'IP. Il est donc crucial d'ajouter un script de surveillance (health check).
Voici un script Bash simple capable de monitorer le processus Nginx et d'arrêter Keepalived en cas de défaillance critique, forçant ainsi le basculement :
#!/bin/bash
# Script de surveillance Nginx : check_nginx.sh
while true
do
# Vérifie si le processus nginx est actif
if [ $(pgrep -c nginx) -eq 0 ]; then
echo "Nginx est hors service. Arrêt de Keepalived pour failover."
systemctl stop keepalived
fi
sleep 3
done
Une approche plus intégrée consiste à utiliser la directive vrrp_script directement dans la configuration Keepalived :
vrrp_script check_srv {
script "killall -0 nginx"
interval 2
weight -20
}
vrrp_instance SERVICE_HA {
# ... reste de la config ...
track_script {
check_srv
}
}
Validation de la Haute Disponibilité
Pour tester la configuration, suivez ces étapes :
- Vérifiez la présence de l'IP virtuelle sur le nœud MASTER avec la commande
ip addr show. - Simulez une panne en arrêtant le service Keepalived sur le MASTER :
systemctl stop keepalived. - Observez le nœud BACKUP : il doit instantanément s'attribuer l'adresse IP
10.0.0.100. - Redémarrez le service sur le nœud initial et constatez la reprise de l'IP par le MASTER original (preemption).