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 serveurs 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 :

Remarque : il est possible de travailler avec une adresse IP flottante , comme c’est indiqué dans le schéma ci-dessus ,mais pour mieux comprendre le phénomène de LoadBalancing , Nous aurons donc un serveur actif en et un serveur passif 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 . 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 :

Puis installer le paquet 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 :

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

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 :

Voici un contenu possible :

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

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

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 puis l’IP virtuelle du cluster :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:

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 qui est basée sur eth1 et qu’elle à l’IP qui devrait alors être joignable (par un simple ping). Jetons maintenant un œil du coté de nos logs.

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 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 être 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”.

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 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 , 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 (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.