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 :

HA01

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

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.

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

HA03

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.

HA04

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

HA06

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

HA07

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.

HA08

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.

HA09

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 :

HA10

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

HA11

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.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Mickael Dorigny

Fondateur d'IT-Connect.fr et d'Information-security.fr. Auditeur sécurité chez Amossys.

    mickael a publié 475 articles sur IT-Connect.See all posts by mickael

    13 réactions sur “Clustering et haute disponibilité sous Linux avec Heartbeat

    • 17/02/2014 à 10:46
      Permalink

      Bonjour,

      Peut-on réaliser (à fin des tests) cette installation sur des VM (Vmware ESXi 5.5 & workstation 9 + Vcenter server) ?

      Cordialement.

      Répondre
      • 17/02/2014 à 11:15
        Permalink

        Bonjour,

        Oui à partir du moment ou tes VM sont sous Linux il est possible de faire une telle infra. Le fait quelles soient virtualisées ne change rien. D’ailleurs ce tutoriel a été fait et testé avec des machines virtuelles. 😉

        Répondre
    • 19/02/2014 à 14:04
      Permalink

      Bonjour, j’ai suivi votre tuto, cependant au moment de lancer heartbeat, j’ai l’erreur:

      starting high-availability services info resource is stopped done.

      Je suis sous VMware player.

      Auriez vous une solution pour ce problème, car cela fait déjà quelques jours que je bloque dessus sans trouver de réponse précise.

      Répondre
      • 19/02/2014 à 14:12
        Permalink

        Bonjour,

        Aurais tu plus d’information dans les logs ? (/var/log/syslog ou /var/log/message, ou des logs heartbeat directement ?). Il s’agit d’une errur [ERROR] ou il est marqué [WARNING] ou [INFO] dans le message ?

        Pour augmenter la verbosité tu peux ajouter « set -v -x » en haut du fichier « /etc/init.d/heartbeat ». Je t’invite à utiliser le forum pour que le problème soit aux yeux de tous et que plus de monde te vienne en aide : http://www.it-connect.fr/forums/cat/unix-linux/application/

        Répondre
        • 19/02/2014 à 14:34
          Permalink

          Merci, je viens de poster un message sur votre forum avec le fichier de log

          Répondre
    • 24/05/2014 à 10:37
      Permalink

      Bonjour,

      Est ce que on peut faire HA avec un squid et squidguard avec cette solution de HA ?

      Répondre
    • 02/12/2014 à 14:00
      Permalink

      Bonjour,

      Le tutoriel est bien écrit cependant je tiens à apporter un bémol sur cette techno.
      Dans mon entreprise nous avons plus d’une centaine de clusters Heartbeat pur ou CRM. Je ne peux que constater après des années d’exploitation que cette solution ne fonctionnent pas à tout les coups en cas de crash d’un serveur. Certains serveurs crash mais continue à répondre au ping ce qui fausse la bascule.
      Je ne saurai vous conseiller de ne pas trop vous y fier surtout pour faire un cluster de BDD …

      Répondre
      • 02/12/2014 à 17:06
        Permalink

        Merci de ta contribution Gamoth !

        J’ai eu à mettre en place cette techno dans le cadre d’un projet de « test » et non d’une mise en production définitive. Je n’ai donc pas de retour d’expérience sur des cas particuliers ou sur de longues périodes. Mais c’est toujours bon à savoir !

        A bientôt,

        Répondre
    • 17/06/2015 à 11:38
      Permalink

      Bonjour Mickael,

      Super tuto, comme d’hab’.

      Mais cela ne fonctionne que sur une seule adresse IP externe, avec les deux serveurs au même endroit?

      Toujours dans le cadre de mon projet – pour rappel: mon-adresse_1.no-ip.org >>> Raspberry Pi en passerelle ssh (avec rinetd) >>> Serveur Master en Debian 8 x64 pour clients chrootés – je souhaite installer un Serveur Slave (identique au Master), distant géographiquement, et qui aura donc mon-adresse_2.no-ip.org pour y accéder.

      Rsync et crontab (pour admin_user) sont opérationnels entre les deux serveurs, actuellement chez moi, avec authorized_keys, mais sur la même adresse no-ip pour l’instant.

      Comme écrit plus haut, je souhaite déménager le Slave et automatiser le basculement sur celui-ci en cas de crash du Master. Ou inversement, « ailleurs » ayant une meilleure bande passante qu’à la maison.

      Comment adapter ton tuto? Y a-t-il autre chose à ajouter, genre IP failover?

      Répondre
    • 22/09/2016 à 16:28
      Permalink

      Bonjour je recherche à customiser les templates mail j’ai vu les variables $1,2,3
      dans :: Mailto

      Mais tout est en anglais; l’idée est d’envoyer des mails à des gens susceptible de ne pas comprendre l’anglais
      pouvez vous m’aider merci

      Répondre
    • 22/09/2016 à 20:49
      Permalink

      Petite astuce au passage.
      Mettre sur le noeud primaire un petit script qui envoie un gratuitous arp.
      A la base, heartbeat était pour des machines qui étaient assez proche et prévoyait donc un « heartbeat » en port série. L’utilisation du port série a quelque peut disparue, et maintenant le « heartbeat » se fait en réseau.

      Imaginons qu’a 1 instant T, le noeud secondaire ne voit pas le noeud primaire(PB réseau), il décide donc de devenir primaire, envoie un gratuitous arp, et puis paf, il revoie son copain qui est toujours primaire, et donc se remet en secondaire.
      Et bah, tous les équipements réseaux au-dessus auront reçu un gratuitous arp qui dit que la VIP est géré par le noeud secondaire, et la, ça marche plus (incident)

      Pour réduire au max la durée de ce type d’incident, si le primaire, dans sa conf ha a un script qui envoie régulièrement un gratuitous arp de sa VIP, on rectifie le tir très vite.

      J’ai appliquée ça a toutes les confs heartbeat a une époque, et j’en entends plus parler.

      Répondre

    Laisser un commentaire

    Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *