Home

Clustering & Haute Disponibilité sous Linux
Mise en place d'un Failover avec Heartbeat
Objectif : comprendre, installer, configurer et tester un cluster HA actif/passif
Objectifs pédagogiques
À la fin de cette séquence, vous serez capable de :

Comprendre le principe de haute disponibilité

Expliquer le fonctionnement d'un failover

Installer et configurer Heartbeat

Mettre en place une IP virtuelle

Analyser les logs du cluster

Simuler une panne et observer la bascule
Pourquoi la Haute Disponibilité ?
Problématique
Un serveur tombe → service indisponible → impact business.
Exemples :
Serveur web
Base de données
Service applicatif interne
👉 En production, l'indisponibilité coûte cher.
Notion de Failover
Définition
Failover = mécanisme automatique de bascule vers un serveur secondaire en cas de panne.
Composants :
Serveur actif (maître)
Serveur passif (esclave)
IP virtuelle commune
Le client ne voit qu'une seule IP.
Présentation de Heartbeat
Heartbeat
Heartbeat (Linux-HA) est un système permettant :
Surveillance mutuelle des serveurs
Détection de panne
Attribution dynamique d'une IP virtuelle
Gestion du statut actif/passif
C'est une solution historique de haute disponibilité sous Linux.
Architecture du Lab
Infrastructure :
Les clients pingent 192.168.1.50.
Pré-requis techniques
Deux serveurs Linux
Interconnexion réseau fonctionnelle
Résolution DNS ou /etc/hosts
Accès root
Avant installation :
Deux serveurs Linux
Interconnexion réseau fonctionnelle
Résolution DNS ou /etc/hosts
Accès root
Test de connectivité :
Installation
Mise à jour :
apt update
Installation :
👉 Même installation sur les deux nœuds.
Structure de configuration
Les fichiers principaux :
/etc/ha.d/ (ou /etc/heartbeat)
Trois fichiers essentiels :
ha.cf
authkeys
haresources
Ils doivent être identiques sur les deux serveurs.
Fichier ha.cf (cœur du cluster)
Rôle :
Définir les membres et les règles de surveillance.
Points importants :
node linux1
node linux2
keepalive 1
deadtime 10
auto_failback yes
Paramètres critiques expliqués
keepalive 1
Fréquence des battements (1 seconde)
deadtime 10
Après 10 secondes sans réponse → nœud considéré mort
auto_failback yes
Retour automatique au primaire si rétabli
👉 Point stratégique en production.
Authentification du cluster
Fichier :
/etc/heartbeat/authkeys
Exemple :
Modes possibles :
sha1
md5
crc
Sécurisation :
chmod 600 /etc/heartbeat/authkeys
Définition de l'IP virtuelle
Fichier :
/etc/heartbeat/haresources
Exemple :
Signification :
linux1 = primaire préféré
192.168.1.50 = IP flottante
Démarrage du cluster
Commande :
service heartbeat start
Vérification :
ip a
L'IP virtuelle apparaît sur le serveur actif.
Analyse des logs
Fichier :
/var/log/heartbeat.log
On observe :
01
Vérification configuration
02
Envoi des battements
03
Détection des statuts
04
Attribution IP virtuelle
Comprendre le mécanisme interne
Processus :
Envoi heartbeat
Vérification voisin
Déclaration statut
Script IPaddr
Activation IP virtuelle
Simulation de panne
Test :
Éteindre serveur actif
Observer logs sur passif
Résultat attendu :
Détection deadtime
Changement statut → active
Récupération IP virtuelle
Vérification post-bascule
Sur serveur secondaire :
ip a
L'IP 192.168.1.50 doit être présente.
Ping depuis client :
Toujours joignable.
Retour du primaire
Si auto_failback = yes :
Le primaire reprend la main
L'IP virtuelle revient automatiquement
Question pédagogique :
👉 Est-ce toujours souhaitable en production ?
Limites de Heartbeat
Important pour professionnaliser la formation :
Solution historique
Remplacée aujourd'hui par :
Pacemaker
Corosync
Pas de quorum avancé
Pas adapté aux clusters complexes
Mais excellent outil pédagogique.
Mise en perspective moderne
Aujourd'hui on utilise plutôt :
Pacemaker + Corosync
Keepalived (VRRP)
Kubernetes HA
Load Balancer + reverse proxy
Heartbeat reste idéal pour comprendre les bases.
Synthèse
Vous avez vu :
Principe HA
IP virtuelle
Failover
Analyse des logs
Simulation de panne
Vous comprenez désormais le fonctionnement d'un cluster actif/passif.