← évolutif
420-5A4-MT · Module 2 · Semaine 8 · Laboratoire

La haute disponibilité de HAProxy :
Heartbeat et l'IP virtuelle

HAProxy balance la charge, mais qui balance HAProxy ? Deux répartiteurs en cluster, une IP virtuelle qu'ils se passent de main en main, et un battement de coeur qui décide qui est vivant.

Schéma du fonctionnement de Heartbeat entre un serveur actif et un serveur passif
Le principe : le passif surveille l'actif et prend le relais.

1 · Présentation

Heartbeat (LinuxHA) met plusieurs serveurs Linux en cluster pour le fail-over : un serveur « passif » attend, prêt à prendre le relais du serveur « actif » en panne. Le cluster détient une IP virtuelle par laquelle les clients passent, plutôt que par l'IP d'un serveur.

Topologie : deux serveurs HAProxy et l'IP virtuelle partagée
Actif : 192.168.56.40 · Passif : 192.168.56.41 · IP virtuelle du cluster : 192.168.56.49.

Le but simplifié : qu'il y ait TOUJOURS une réponse au ping vers l'IP virtuelle, quel que soit le serveur qui la porte.

Contexte Client Cornucopia

Cornucopia · Application Pratique sur le Terrain

Ce laboratoire technique s'inscrit directement dans l'infrastructure de la ferme maraîchère de Flora et Hazel pour garantir la réactivité et la stabilité de leurs services bio en ligne.
Cas d'Usage Concret

Appliquer les configurations optimisées pour soutenir les pics de consultation des abonnés de la ferme.

2 · Installation

Après avoir vérifié l'interconnectivité des deux serveurs (un simple ping) :

$ sudo apt-get update $ sudo apt-get install heartbeat

3 · Configuration

Les fichiers de configuration doivent être identiques sur les deux serveurs, dans /etc/ha.d (ou /etc/heartbeat, lien symbolique). Trois fichiers suffisent : ha.cf, authkeys et haresources.

Heartbeat préfère identifier les serveurs par leurs NOMS (commande uname -n) plutôt que par leurs IP. Pour les tests, le fichier /etc/hosts fait la résolution; en production, c'est le rôle d'un serveur DNS comme Bind9.
127.0.0.1 localhost 192.168.56.40 haproxy_heartbeat40 192.168.56.41 haproxy_heartbeat41

3.1 · Le fichier ha.cf

$ sudo nano /etc/heartbeat/ha.cf

Sur les deux serveurs :

# Indication du fichier de log logfile /var/log/heartbeat.log # Les logs heartbeat seront geres par syslog, categorie daemon logfacility daemon # On liste tous les membres du cluster (par les noms de preference) node haproxy_heartbeat40 node haproxy_heartbeat41 # Periodicite de controle des noeuds entre eux (en secondes) keepalive 1 # Au bout de combien de secondes un noeud est considere « mort » deadtime 10 # Quelle carte reseau utiliser pour les broadcasts Heartbeat bcast enp0s8 # Adresse du routeur pour verifier la connexion ping 192.168.56.1 # Rebascule-t-on automatiquement sur le primaire s'il redevient vivant ? auto_failback yes
Un « node » est un noeud, donc un serveur membre du cluster. L'auto_failback ramène le service sur le maître dès qu'il redevient opérationnel.

3.2 · Le fichier authkeys

$ sudo nano /etc/heartbeat/authkeys
auth 1 1 sha1 MaClefSecrete

Par sécurité, restreindre les droits du fichier :

$ sudo chmod 600 /etc/heartbeat/authkeys

3.3 · Le fichier haresources

Les actions à mener au basculement : quand un serveur passe de passif à actif, il lit ce fichier. Ici : prendre l'IP virtuelle.

$ sudo nano /etc/heartbeat/haresources
haproxy_heartbeat40 192.168.56.49
Même contenu sur les deux serveurs : le nom du serveur primaire, puis l'IP virtuelle du cluster. Les journaux vivent dans /var/log/daemon.log.

3.4 · Correctif pour Ubuntu récent

Ubuntu ne nomme plus ses interfaces réseau de la même manière, ce qui casse la configuration par défaut de Heartbeat. Sur Ubuntu Server 24.04 LTS et versions ultérieures, installer d'abord :

$ sudo apt install resource-agents-extra

Puis corriger l'interface par défaut :

$ sudo nano /usr/lib/ocf/resource.d/heartbeat/IPaddr

Remplacer OCF_RESKEY_nic_default="eth0" par OCF_RESKEY_nic_default="enp0s8", puis :

$ sudo systemctl restart heartbeat

4 · Démarrage et test

Démarrer le service sur chaque serveur :

$ sudo service heartbeat start $ service --status-all | grep "heartbeat"
[ + ] heartbeat

Le test facile de l'IP virtuelle

$ ping 192.168.56.49
Si ça répond, vous avez réussi ! Sinon, revalider chaque étape et chaque fichier de configuration. (Le document d'origine suggérait aussi de revalider votre choix de carrière - on a barré cette partie.) En passant : ça prend quelques secondes à fonctionner au démarrage.

5 · Faire en sorte que HAProxy utilise l'IP virtuelle

5.1 · Autoriser le binding d'une IP non locale

$ sudo nano /etc/sysctl.conf

Ajouter à la fin :

net.ipv4.ip_nonlocal_bind=1

Application immédiate (ou attendre le prochain démarrage) :

$ sudo sysctl -p

5.2 · Reconfigurer HAProxy sur l'IP virtuelle

$ sudo nano /etc/haproxy/haproxy.cfg

6 · Que fait-on avec WordPress ?

WordPress doit connaître l'adresse par laquelle on le joint : lui donner l'IP virtuelle au lieu de celle qu'il avait jusqu'à maintenant.

Réglages WordPress avec l'adresse IP virtuelle
La dernière pièce : le site vit désormais à l'adresse du cluster, pas à celle d'une machine.

Références d'origine : it-connect.fr - Clustering et haute disponibilité sous Linux avec Heartbeat · howtoforge.com - High availability load balancer with HAProxy and Heartbeat · Document du cours recréé en HTML pour la semaine 8 · Le préalable : le balancement HAProxy avec deux serveurs Varnish.