Introduction a Heartbeat

Nicolas BAILLIF
Elève-Ingénieur Supinfo Océan-Indien
Promotion SUPINFO 2009

Table of Contents
Introduction..........................................................................................................................................2
1 Principe de fonctionnement et matériel recquis................................................................................3
1.1 Principe de fonctionnement.......................................................................................................3
1.2 Matériel recquis.........................................................................................................................3
2 Configuration de Heartbeat...............................................................................................................4
2.1 Paramètres du fichier ha.cf........................................................................................................4
2.2 Paramètres du fichier haresources.............................................................................................5
2.3 Configuration du fichier authkeys.............................................................................................5
Conclusion............................................................................................................................................6
Introduction
De nos jours la disponibilité et la fiabilité des données et composants informatiques est primordial
dans le monde des entreprises. En effet si un serveur tombe en panne ou si un service ne peut plus
etre assuré, les risques sont importants et peuvent représenter de grosses pertes que ce soit en temps,
en profits, mais aussi au niveau du capital confiance acquis auprès des consommateurs. Il existe de
nombreuses façons d'assurer une plus grande disponibilité voire Haute Disponibilité mais nous
allons nous intéresser à Heartbeat, un composant du projet Linux-HA (High-Avaibility Linux).
Disponible pour presque la pluspart des distributions linux connues, Heartbeat permet de sécuriser
le fonctionnement d'un serveur assez facilement, si un serveur tombe en panne, un autre sera utilisé
à la place et assurera les même fonctions que le premier.
1 Principe de fonctionnement et matériel
recquis
Nous allons voir en premier lieux comment fonctionne Heartbeat puis le matériel nécessaire afin de
mettre en place ce système.

1.1 Principe de fonctionnement

L'objectif est de faire fonctionner deux serveurs simultanément, l'un prenant à sa charge le travail de
l'autre en cas de panne de l'un des deux serveurs. Cette solution est assez simple mais aussi peu
couteuse, en effet il suffit de deux machines (au minimum) pour la mettre en oeuvre. Nous avons
par exemeple deux serveurs, ensemble ils forment un cluster :
-serv1 qui utilise l'adresse 10.0.0.9
-serv2 qui utilisent l'adresse 10.0.0.10
Ces "nodes" (ou noeuds) qui composent le cluster forment ensemble le serveur 10.0.0.11. Les nodes
de ce cluster doivent se surveiller mutuellement, cette surveillance ce fait par un cable null-modem
relié au port série de chaque machine. Le premier node va tester le second a intervalle de temps
régulier et cours (pour assurer cette disponibilité), si la limite de temps est dépassée et que le second
node ne repond toujours pas, le premier node prend la place du second en assurant les mêmes
fonctions. Ainsi chacun des deux nodes peut assurer a un moment le service fourni par un serveur.

1.2 Matériel recquis

Pour mettre en place Heartbreak il faut au minimum deux machines serveur fonctionnant sous
Linux (Heartbreak est disponible pour la quasi totalité des distributions connues). La "prise de
pouls" est effectuée via les interfaces réseau avec le protocole UDP. Pour encore fiabiliser le
système il est possible de faire une double "prise de pouls" en ajoutant un cable 'null modem' entre
les serveurs (cable branché en port COM) ou encore une carte reseau de plus dans chaque serveur
afin de les brancher en cable croisé pour ne pas encombrer le réseau global.
Nous connaissons maintenant le principe de fonctionnement de Heartbeat ainsi que le matériel
nécessaire, nous allons voir maintenant comment configurer ce service.
2 Configuration de Heartbeat
La configuration de Heartbeat se fait en deux fichiers de paramètres et un fichier servant à
l'authentification. Le fichier 'ha.cf' contient les éléments de configuration de Heartbeat, 'haresources'
definit les ressources du cluster dont il faut assurer la disponibilité et 'authkeys' qui sert à définir la
méthode d'authentification et les paramètres a utiliser. Ces trois fichiers sont placés dans le
repertoire /etc/ha.d.

2.1 Paramètres du fichier ha.cf

Contenu du fichier :
bcast eth0
baud 19200
serial /dev/ttyS0
debugfile /var/log/ha-debug
logfile /var/logha-log
logfacility local0
keepalive 2
deadtime 10
warntime 6
initdead 60
udport 694
node serv1
node serv2
nice_failback on
Les trois premières lignes du fichiers concernent les interfaces a utiliser, bcast defini l'interface
reseau a utiliser eth0 ou eth1 (si vous dédiez une carte réseau a la prise de pouls" ou autre). Il faut
ensuite définir la vitesse en bauds du port série et le port série. Le second paragraphe de trois ligne
concerne les fichiers de log d'activité.
Le troisième groupe de lignes concerne la configurations des delais :
-keepalive est le délai entre deux "battements de pouls"
-deadtime défini le temps nécessaire avant de déclarer un node comme mort
-warntime est le delai avant d'inscrire un avertissement dans les logs
-initdead est le temps utilisé pour supporter le démarrage d'un node (au minimum deux fois plus
grand que deadtime).
Ces délais sont donnés en secondes, vous pouvez aussi pour une gestion plus précise donner les
délais en millisecondes en mettant derrière les valeurs "ms", exemple : 1500ms.
Les informations supplémentaires sont dans le dernier groupement de ligne :
-udpport défini le port UDP qui sera utilisé pour la prise de pouls
-node est le nom des machines ( ou node ) du cluster
La directive nice_failback peut etre abscente. Dans un cluster de disponibilité il y a un node maître,
si celui-ci est déclaré mort, un aure node prendra le relais. Lorsque le node déclaré mort sera de
nouveau en fonctionnement et détecté comme tel la présence de nice_failback va déterminer le
comportement à adopter. Si elle es presente la machine qui a pris le relai va garder la main sinon le
node maître va reprendre ses fonctions.
Après avoir vu comment configurer le fichier ha.cf nous allons paramétrer le fichier haresources qui
gère les services et la sécurité.
2.2 Paramètres du fichier haresources
Le fichier haresources est situé dans le repetoire /etc/ha.d ,il doit être exactement identique sur
chacun des nodes. Ce fichier est utilisé lorsque le node redevient fonctionnel apres une panne, un
redemmarage ou un arrêt de Heartbeat. Il est important de savoir lors de la configuration de ce
fichier quel service doit être "hautement disponible".
Le fonctionnement de Heartbeat est simple, après la détection du node mort ayant la main, un node
va prendre la place de maître en prenant l'adresse ip du cluster, dans notre cas décrit
précédemment l'adresse 10.0.0.11 va être prise, c'est la phase d'IPAT (IP Adress Takeover). Pour
cela une simple ligne de configuration est necesssaire :
serv1 10.0.0.11
Cette ligne définit serv1 comme maître du cluster et il dessert l'adresse 10.0.0.11
Avec ce fichier il est possible de lancer des scripts répondants aux arguments start,stop et status. Le
fichier etc/ha.d/resource.d installé par défaut contient un certain nombre de scripts dont le but est de
réaliser des actions spécifiques lorsqu'un node devient maître ou lorsqu'un node est déclaré comme
mort.
Voici quelque exemples de scripts présents dans /etc/ha.d/resource.d :
-MailTo : envoie un mail d'avertissement lorsque quelque chose se produit
-Filesystem : permet la gestion d'un periphérique de stockage partagé
-LinuxSCSI : active ou desactive des periphériques SCSI.

2.3 Configuration du fichier authkeys

Ce fichier permet au nodes de s'authentifier afin de s'assurer de la légitimité de leur présence dans le
cluster. authkey ne contient pas beaucoup d'informations, voici differents exemples de ce fichier :
auth 1
1 crc
ou
auth 3
1 md5 "srv pass"
2 crc
3 sha "pass srv"
Ce fichier se compose du mot clef "auth" suivi d'une valeur d'index qui va déterminer quelle ligne
doit être prise en compte. Dans le cas d'une liaison série ou en cable croisé il n'est pas la peine de
s'assurer de l'identité des nodes, mais sinon il es important d'utiliser une methode d'authentification
robuste avec l'utilisation du MD5 (Message Digest version 5) ou SHA (Secure Hash Algorithm).
Ainsi avec le deuxième exemple pour changer de méthode d'authentification il suffit de changer la
valeur de l'index qui suit 'auth'.
Conclusion
Nous avons pu voir à travers la découverte de Hertbeat qu'il peut être a la fois simple et peu couteux
de mettre en place un système de serveur dont la disponibilité serai élevée. En effet Heartbeat nous
permet de détecter un serveur en panne, de nous en informer mais surtout d'en utiliser un autre pour
prendre le relais et cela de facon automatisée et transparente pour l'utilisateur (selon la
configuration des serveurs). La mise en place d'un tel système est assez basique ce qui permet a de
nombreuses PME de béneficer de cette disponibilité tout en restant dans un budget peu important.
Cependant pour une utilisation plus poussée, d'autres services peuvent êtres utilisés de concert avec
Heartbeat comme par exemple Mon qui va détecter non pas le fonctionnement d'une machine mais
le fonctionnement des services de cette machine.