Contexte : cluster actif/passif à deux nœuds avec adresse IP virtuelle et bascule automatique d'un service web Apache · Testé sur : Ubuntu Server, Heartbeat, Apache 2 (lab virtualisé à deux nœuds) · Dernière vérification : contenu de 2024 non revérifié
Heartbeat n'est plus développé : ses successeurs sont Pacemaker et Corosync, et le paquet peut être absent des distributions récentes. Ce tutoriel reste utile pour comprendre le principe d'un cluster actif/passif ; pour un nouveau déploiement, voir Cluster Zabbix HA : Pacemaker, Corosync et MariaDB Galera.
¶ Objectif
Monter un cluster de haute disponibilité à deux serveurs Linux avec Heartbeat : un nœud actif sert un site web Apache sur une adresse IP virtuelle ; si ce nœud tombe, le nœud passif récupère l'adresse et le service.
¶ Principe de fonctionnement
Heartbeat (anciennement Linux-HA, « battement de cœur ») est un logiciel de haute disponibilité qui fonctionne sur toutes les distributions Linux. Il gère un cluster d'au moins deux serveurs, appelés nœuds, de configuration matérielle et logicielle identique :
- un nœud actif, le serveur maître du cluster, qui rend le service ;
- au moins un nœud passif, le serveur secondaire, prêt à prendre le relais.
Les nœuds « prennent le pouls » l'un de l'autre en permanence. Si le nœud passif ne sent plus le pouls du nœud actif, il reprend immédiatement l'adresse IP virtuelle et les services. Quand le nœud actif revient, il récupère le relais si l'option auto_failback est activée (voir l'étape 3 et la section « Conserver le nœud de secours après rétablissement »).
¶ Prérequis
- Deux serveurs Ubuntu Server de configuration matérielle et logicielle strictement identique, avec Apache 2 installé (il sert aux tests).
- Les droits
rootsur les deux serveurs (sudo -s). - Plus de 50 Mo d'espace disque libre et un accès à Internet sur chaque serveur.
- Un poste client avec un client SSH et un navigateur web, pour configurer et tester le cluster.
Adresses du lab :
| Élément | Nom | Adresse |
|---|---|---|
| Nœud actif | srv1 |
192.168.122.7 |
| Nœud passif | srv2 |
192.168.122.148 |
| Adresse IP virtuelle du cluster | — | 192.168.122.209/24, sur l'interface enp1s0 |
La première version de ce document décrivait un lab plus ancien (Ubuntu Server 12.04 virtualisé sous VMware Workstation, réseau
172.16.0.0/16, nœuds en172.16.15.100et172.16.15.150, adresse virtuelle172.16.15.50, client Windows XP). Les fichiers ci-dessous correspondent au lab rejoué sur le réseau192.168.122.0/24.
Toutes les commandes et manipulations sont à reproduire sur les deux serveurs, sauf mention contraire. Les exemples sont donnés depuis
srv1.
¶ Étapes
¶ 1. Déclarer les noms d'hôtes
Heartbeat identifie les nœuds par leur nom d'hôte : ils doivent être résolus correctement sur les deux serveurs. Connectez-vous en SSH à srv1, passez en super-utilisateur, puis ouvrez le fichier hosts :
sudo -s
nano /etc/hosts
Sur la ligne 127.0.1.1, indiquez le nom du serveur (srv1), puis ajoutez l'adresse et le nom de l'autre nœud :
127.0.0.1 localhost
127.0.1.1 srv1
192.168.122.148 srv2
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Faites l'équivalent sur srv2 (son propre nom sur la ligne 127.0.1.1, et l'adresse de srv1). Vérifiez ensuite le nom d'hôte complet de chaque serveur :
hostname -f
¶ 2. Installer Heartbeat
apt-get update
apt install heartbeat
La durée de l'installation dépend de la connexion Internet et de la puissance des serveurs.
¶ 3. Créer le fichier ha.cf
Placez-vous dans le répertoire de configuration de Heartbeat et listez son contenu :
cd /etc/ha.d/
ls
Trois fichiers nécessaires au fonctionnement du service n'existent pas encore : ha.cf, authkeys et haresources. Commencez par ha.cf :
nano ha.cf
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 5
warntime 4
initdead 15
udpport 694
ucast enp1s0 192.168.122.7
ucast enp1s0 192.168.122.148
auto_failback on
node srv1 srv2
| Paramètre | Rôle |
|---|---|
debugfile, logfile, logfacility |
Fichiers de débogage et de journal, catégorie syslog |
keepalive |
Intervalle entre deux pulsations, en secondes |
warntime |
Délai après lequel une pulsation manquante déclenche un avertissement |
deadtime |
Délai après lequel un nœud silencieux est déclaré mort |
initdead |
Délai de grâce au démarrage, le temps que le réseau soit prêt |
udpport |
Port UDP des pulsations |
ucast |
Envoi des pulsations en unicast vers chaque nœud, par l'interface indiquée |
auto_failback |
Rend le service au nœud actif quand il revient (on) ou le laisse sur le nœud de secours (off) |
node |
Noms des nœuds du cluster, identiques au résultat de uname -n |
Le contenu doit être strictement identique sur srv2. Restreignez ensuite les droits du fichier :
chmod 600 ha.cf
¶ 4. Créer le fichier authkeys
Le fichier authkeys authentifie les échanges entre les nœuds, ici avec une signature SHA-1 et une clé partagée. Générez une clé aléatoire (par exemple avec openssl rand -hex 20), puis créez le fichier :
nano authkeys
auth 1
1 sha1 <CLE_AUTHKEYS>
La clé doit être strictement identique sur srv2. Ce fichier contient un secret : Heartbeat refuse de démarrer s'il est lisible par d'autres utilisateurs que root.
chmod 600 authkeys
¶ 5. Créer le fichier haresources
Le fichier haresources indique quel nœud porte les ressources par défaut, l'adresse IP virtuelle à créer, l'interface qui la porte et le service à piloter :
nano haresources
srv1 IPaddr::192.168.122.209/24/enp1s0 apache2
srv1: nœud actif par défaut du cluster.IPaddr::192.168.122.209/24/enp1s0: adresse IP virtuelle192.168.122.209en/24(masque255.255.255.0), portée par l'interfaceenp1s0du nœud actif.apache2: service que Heartbeat démarre sur le nœud actif et arrête sur l'autre. Ici, il s'agit d'un cluster web sous Apache.
Le contenu doit être strictement identique sur srv2.
¶ 6. Redémarrer Heartbeat
Pour appliquer la configuration, redémarrez le service sur les deux serveurs :
systemctl restart heartbeat
¶ Vérification
¶ Adresse IP virtuelle
Sur le nœud actif, l'adresse virtuelle doit apparaître sur l'interface enp1s0 :
ip a
¶ État de l'autre nœud
La commande cl_status indique si un nœud distant répond. Depuis srv1, interrogez l'état du nœud passif :
cl_status nodestatus srv2
Le message active signifie que le nœud est opérationnel ; dead signifie qu'il ne répond plus.
¶ Accès au site web
Depuis le poste client, ouvrez un navigateur et saisissez l'adresse IP virtuelle, et non l'adresse de l'un des serveurs : la page servie est celle du nœud actif srv1.
¶ Test de bascule
Simulez la panne du nœud actif, par exemple en arrêtant Heartbeat sur srv1 (ou en éteignant le serveur) :
systemctl stop heartbeat
Rechargez la page dans le navigateur : elle est désormais servie par srv2, grâce à Heartbeat.
La bascule a fonctionné : l'adresse IP virtuelle et Apache sont passés sur le nœud de secours.
En mode
haresources, Heartbeat surveille la présence des nœuds, pas l'état des services : arrêter seulement Apache sur le nœud actif (systemctl stop apache2) ne déclenche pas de bascule. La surveillance des services est l'un des apports de Pacemaker.
¶ Conserver le nœud de secours après rétablissement
Pour que srv2 reste actif après le retour de srv1, passez la ligne suivante de on à off dans ha.cf, sur les deux nœuds, puis redémarrez Heartbeat :
auto_failback off
¶ Dépannage
| Symptôme | Cause probable | Solution |
|---|---|---|
Heartbeat refuse de démarrer et signale un problème sur authkeys |
Droits trop ouverts sur le fichier | chmod 600 /etc/ha.d/authkeys |
| Les deux nœuds se croient actifs | Les pulsations ne passent pas (pare-feu, mauvaise interface dans ucast) |
Ouvrez le port UDP 694 entre les nœuds et vérifiez le nom de l'interface avec ip a |
| Un nœud n'est pas reconnu | Le nom dans node ou haresources diffère du nom d'hôte |
Comparez avec uname -n et corrigez /etc/hosts et les fichiers de Heartbeat |
| Les journaux ne s'affichent pas | Fichiers définis dans ha.cf |
Consultez /var/log/ha-log et /var/log/ha-debug |
¶ Références
- Haute disponibilité et réplication de données avec DRBD, pour répliquer les données entre les nœuds
- Cluster Zabbix HA : Pacemaker, Corosync et MariaDB Galera
- Projet ClusterLabs (Pacemaker et Corosync)
- Adapté d'un tutoriel des CEMÉA (tutos.cemea.org) ; images hébergées par la source.