HeartBeat ou LinuxHA (High Availability) est un système permettant, sous Linux, la mise en cluster (en groupe) de plusieurs serveurs. C’est plus clairement un outil de haut disponibilité qui va permettre à plusieurs serveurs d’effectuer entre eux un processus de fail-over. Le principe du “fail-over” (ou “tolérance de panne“) est le fait qu’un serveur appellé “passif” ou “esclave” soit en attente et puisse prendre le relais d’un serveur “actif” ou “maitre” si ce dernier serait amené à tomber en panne ou à ne plus fournir un service. Le principe d’Heartbeat est donc de mettre nos serveurs dans un cluster qui détiendra et sera représenté par une IP “virtuelle” par laquelle les clients vont passer plutôt que de passer par l’IP d’un serveur (actif ou passif). Le processus Heartbeat se chargera de passer les communications aux serveur actif si celui-ci est vivant et au serveur passif le cas échéant.

Nous allons donc dans ce tutoriel mettre en place un clustering de serveur qui partageront une même adresse IP virtuelle. Le but (simplifié) étant qu’il y ai toujours une réponse à un ping vers une IP (qui sera l’IP virtuelle du cluster).

Nous aurons donc un serveur actif en 192.168.1.29 et un serveur passif 192.168.1.30 tout deux sous Linux sur lesquels sera installé le paquet Heartbeat et ses dépendances. Nous souhaitons que les clients communiquent avec le serveur via l’IP virtuelle du cluster 192.168.1.50 et non pas vers 192.168.1.29 ou 192.168.1.30. Ce sera au cluster de passer les requêtes à tel ou tel serveur suivant la disponibilité du serveur “maitre“.

Après avoir mis en place les serveurs et s’être assuré de leur inter-connectivité (via un simple ping), nous allons mettre à jours notre liste de paquet :

apt-get update

Puis installer le paquet Heartbeat :

apt-get install heartbeat

Les fichiers de configuration devront être les mêmes sur les deux serveurs membres du cluster et devront se situés dans “/etc/ha.d” (ou “/etc/heartbeat” qui est un lien symbolique vers “/etc/ha.d“). Ces fichiers devront êtres créés car ils ne le sont pas à l’installation d’Heartbeat :

     nano /etc/heartbeat/ha.cf

Note : Il faut savoir qu’Heartbeat préfère travailler avec des noms pour identifier les serveurs membres du cluster plutôt que par l’IP. Pensez donc à préférer les noms de vos serveurs (avec la commande “uname -n“) plutôt que les IP. Une petite astuce pour une mise en place en test est d’utiliser le fichier “/etc/hosts” pour résoudre les noms entre les deux serveurs. Il faut savoir que seul trois fichiers de configurer sont nécessaires à la mise en place d’un cluster de serveur autour d’une IP virtuelle : authkeys, ha.cf et haresources.

Nous mettons donc ce contenu dans le fichier sur les deux serveurs :

# Indication du fichier de log
logfile /var/log/heartbeat.log
# Les logs heartbeat seront gérés par syslog, dans la catégorie daemon
logfacility daemon
# On liste tous les membres de notre cluster heartbeat (par les noms de préférences)
node linux1
node linux2
# On défini la périodicité de controle des noeuds entre eux (en seconde)
keepalive 1
# Au bout de combien de seconde un noeud sera considéré comme "mort"
deadtime 10
# Quelle carte résau utiliser pour les broadcasts Heartbeat (eth1 dans mon cas)
bcast eth1
# Adresse du routeur pour vérifier la connexion au net
ping 192.168.1.1
# Rebascule-t-on automatiquement sur le primaire si celui-ci redevient vivant ? oui*
auto_failback yes

Un “node” est un noeud. Autrement dit un serveur membre du cluster. L’auto_failback permet de rebasculer directement sur le serveur maitre quand il redevient opérationnel après qu’il ai été déclaré comme “mort” (quand il est configuré à “yes“. Nous passons maintenant au fichier “/etc/heartbeat/authkeys“, ce fichier va définir la clé qui permettra d’authentifier un minimum les serveurs membres du cluster entre eux :

nano /etc/heartbeat/authkeys

Voici un contenu possible :

auth 1

1 sha1 MaClefSecrete

Il faut savoir que l’on peut utiliser trois modes de sécurisation dans ce fichier :

-sha1

-md5

-crc

Par sécurité, on sécurise ce fichier en lui mettant des droits plus restreints :

 chmod 600 /etc/heartbeat/authkeys

On passe maintenant au fichier “/etc/heartbeat/haresources” qui va contenir les actions à mener au moment d’un basculement. Plus clairement, quand un serveur passera du status “passif” à “actif“, il ira lire ce fichier pour voir ce qu’il doit faire. Dans notre cas nous allons dire à notre serveur de prendre l’IP virtuelle 192.168.1.50 :

linux1 IPaddr::192.xxx.xxx.xxx/24/eth1

On rappel que le contenu du fichier doit être le même sur les deux serveurs. On indique donc ici le nom du serveur primaire du cluster (linux1 est pour moi “192.168.1.29“) puis l’IP virtuelle du cluster : “192.168.1.50” dans mon cas. Pour information, les logs de Heartbeat se situent comme indiqué dans le fichier de configuration dans le fichier “/var/log/daemon.log“.

Nous allons pourvoir maintenant passer au démarrage de notre cluster, nous verrons par la même occasion l’attribution et l’IP virtuelle. Pour avoir une vue en détail de ce qu’il se passe sur nos serveurs, il est aussi intéressant d’avoir un œil sur les logs de ceux-ci qui se situent, selon notre configuration, dans le fichier “/var/log/heartbeat.log“. Nous saisissons donc sur nos deux serveurs la commande suivante:

  service heartbeat start

Si tout ce passe bien, nous aurons une nouvelle interface et une nouvelle IP lors de la saisie de la commande “ipconfig” sur le serveur actif (“maitre“) :

HA02

On voit donc bien ici que c’est une IP virtuelle (“:0“) qui est basée sur eth1 et qu’elle à l’IP 192.168.1.50 qui devrait alors être joignable (par un simple ping). Jetons maintenant un œil du coté de nos logs.

Retour...