Clustering et haute disponibilité sous Linux avec Heartbeat

I. Présentation

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). Pour l'exemple, nous suivrons le schéma suivant :

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".

II. Installation

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

III. Configuration

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 :

vim /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 :

vim /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 192.168.1.50

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".

IV. Démarrage du cluster & analyse des logs

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") :

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.

Note : Cette partie n'est pas indispensable à la mise en place du cluster mais permet de mieux comprendre le processus et les échanges entre les serveurs, passez directement à la partie "V. Simulation de panne et récupération & analyse des logs" si cela ne vous intéresse pas.

D'abord sur le serveur actif ("maitre") :

On voit ici qu'il y a une vérification du fichier de configuration, si il semble valide, le système démarre. On remarque au passage l'affichage de la version d'Heartbeat ce qui peut toujours être utile.

On voit ici que le serveur (ici maitre) commence à émettre des Heartbeat (battements de cœurs) en broadcast pour indiquer qu'il est vivant. Dans une configuration plus poussée nous pourrions émettre ces battements de cœur depuis l'interface "eth1" en unicast (à une seule machine) ou en multicast( à un groupe de machine).

On voit ici le début du processus des status. Le but est ici de définir qui est vivant et qui ne l'est pas pour définir qui se chargera d'être actif. On voit donc que le serveur commence par joindre la passerelle afin de vérifier la connectivité de son interface (ici "eth1"). Il déclare ensuite le status de cette interface en "up".

La seconde partie du processus des status consiste ici à établir le status du serveur voisin (membre du cluster avec lui). On remarque ensuite qu'heartbeat utilise un script "status" qui permet de mettre à jour/ changer de status. On voit alors que le "local status" (status du serveur où se situe) est passé en "active". Notre serveur vient de se déclarer maitre du cluster. Il va donc etre en charge de l'IP virtuelle.

On voit ici qu'Heartbeat utilise un deuxième de ses scripts qui permet de vérifier la réponse d'une requête sur l'IP virtuelle.

Après avoir effectué cette vérification, le serveur paramètre donc l'IP virtuelle dans sa configuration grâce à son script "IPaddr".

Note : Ceci est un aperçu des principales informations que l'on peut voir dans les logs des serveurs mis en cluster avec Heartbeat. La plupart des autres procédures auront un format très ressemblant à celui-ci.

V. Simulation de panne et récupération & analyse des logs

Nous allons maintenant simuler un dysfonctionnement dans le cluster en éteignant notre serveur "actif" pour voir si la reprise par le serveur "passif" se fait correctement, nous allons également vérifier les logs pour voir comment les actions sont reçues et menées. Nous voyons alors directement dans les logs les informations suivantes :

On voit ici que le serveur passif détecte que le lien linux1 (serveur maitre "192.168.1.29") ne répond plus, il le considère donc comme "mort" :

Il lance ensuite la reprise du serveur actif en configurant l'IP virtuelle sur son interface comme précisé dans le fichier "/etc/heartbeat/haresources". A ce moment, si l'on fait un "ifconfig" sur le serveur 192.168.1.30, nous allons voir qu'il a bien récupérer l'IP virtuelle sur cluster.

Pour continuer l'exemple d'une production, nous allons rallumer notre serveur 192.168.1.29 (ancien actif) pour qu'il récupère l'IP virtuelle et redevienne le serveur principal comme nous le voulons. Cela est possible grâce à l'option "auto_failback" qui est à "yes". Cela indique que dés que le serveur dit comme "principal" redeviendra "vivant", il prendra à nouveau la fonction et la tête du cluster. L'utilité de ce paramétrage peut dépendre du service hébergé sur les serveurs en cluster.

Note : Je recommande aux très curieux comme moi d'aller voir les différents scripts utilisés lors de ces initialisations et des processus d'Heartbeat, ceux-ci se situent dans "/etc/heartbeat" également. Lire et analyser ces scripts permet de mieux comprendre comment fonctionne le Heartbeat et permet ainsi de mieux le manier et/ou debugger.

Mickael Dorigny Co-founder

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

See Full Bio