Installation et configuration d'un cluster Heartbeat V1

1 Introduction

L'idée générale pour assurer la disponibilité d'un service est de faire fonctionner plusieurs machines (deux au minimum) en même temps. Ces machines forment ce qu'on appelle un cluster et chaque machine est un node du cluster. Chacune des machines va vérifier si les autres répondent toujours en prenant le pouls de chacune des autres. Si une machine cesse de fonctionner, les autres assurent le service.

Une fois le cluster configuré, on y accède au travers d'une seule et unique adresse IP qui est celle du cluster; qui lui-même est composé de plusieurs nodes.

Pour pouvoir mettre en place ce genre de technique, nous allons utiliser l'application HeartBeat qui va se charger de surveiller les machines et d'appliquer une série de scripts définis par l'utilisateur si cela s'avère nécessaire (c'est-à-dire si une machine tombe).

2 Préambule

La configuration de tests se compose de deux machines modestes ; twin1 et twin2.

Le cluster sera accessible au travers de l'adresse 192.168.252.205.

2.1 Twin 1

• Maître / Primaire
• Pentium 3 - 500 MHz - 128Mo RAM
• Installation neuve de Debian en mode minimaliste
• Mise à niveau de l'image vers 2.6.18-4-686 (au lieu de 386)
• IP : 192.168.252.200
• Hostname : twin1
• Disque de 13.5Go partagé en 5 partitions (/ de 4.5Go, /srv/prod de 3Go, /srv/intern de 3Go, /srv/other de 2Go et swap de 1Go)

2.2 Twin 2

• Esclave / Secondaire
• Pentium 3 - 700 MHz - 128Mo RAM
• Installation neuve de Debian Stable en mode minimaliste
• Mise à niveau de l'image vers 2.6.18-4-686 (au lieu de 386)
• IP : 192.168.252.201
• Hostname : twin2
• Disque de 10Go partagé en 4 partitions (/ de 3Go, /srv/prod de 3Go, /srv/intern de 3Go et swap de 1Go)

3 Etats des machines

Sur les deux machines, voici ce qui a été fait.

• Installation CD d'installation Debian 4.0 et configuration réseau manuelle.
• Mise à jour de quelques paquets basiques via Internet.

sudo apt-get update
sudo apt-get dist-upgrade

• Mise à niveau du kernel pour profiter du Pentium 3 (pas nécessaire). Après la mise à niveau, un petit redémarrage pour prendre en compte le nouveau kernel.

sudo apt-get install linux-image-2.6.18-686
sudo reboot

4 Installation d'HeartBeat

HeartBeat s'installe très simplement sur une Debian. Le paquet se trouve dans les dépôts standards. Il vous suffit donc de lancer la commande suivante sur les deux machines (Twin 1 et Twin 2) :

sudo apt-get install heartbeat-2

Une fois le service installé, vous obtiendrez une erreur disant que le fichier de configuration ha.cf n'est pas présent. Ce qui est parfaitement normal.

Voyons à présent la configuration basique de HeartBeat.

5 Configuration basique

La configuration d'HeartBeat repose sur 3 fichiers fondamentaux. Durant la configuration basique, je vais vous présenter une configuration minimaliste en vue de poursuivre un but :

• fournir une base minimaliste que vous pourrez adapter à vos besoins au fil du temps.

Les trois fichiers de configuration sont strictement identiques sur les deux machines; chez vous, il convient donc de les copier sur chacune des machines du cluster. Dans notre exemple, il s'agit de Twin 1 et Twin 2.

5.1 ha.cf

sudo vi /etc/ha.d/ha.cf

Voici le fichier ha.cf que j'utilise sur Twin 1 et Twin 2 :

bcast         eth0
 
debugfile     /var/log/ha-debug
logfile       /var/log/ha-log
logfacility   local0
 
keepalive     2
deadtime      10
warntime      6
initdead      60
 
udpport       694
node          twin1
node          twin2
 
auto_failback off
 
apiauth         mgmtd   uid=root
crm             on
respawn         root    /usr/lib/heartbeat/mgmtd -v

Examinons ce fichier de configuration en détails :

• bcast : indique l'interface réseau par laquelle on va effectuer la prise de pouls.
• debugfile : indique le fichier de déboguage à utiliser.
• logfile : indique le log d'activité à utiliser.
• logfacility : indique que l'on utilise la facilité syslog en plus.
• keepalive : indique le délai entre deux battements de pouls. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
• deadtime : indique le temps nécessaire avant de considérer un noeud comme étant mort. Ce temps est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
• warntime : indique le délai avant d'envoyer un avertissement pour les pouls en retard. Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
• initdead : indique un deadtime spécifique pour les configurations où le réseau met un certain temps à démarrer. initdead est normalement deux fois plus grand que deadtime (au minimum). Ce délai est donné par défaut en seconde; pour utiliser les millisecondes, on ajoute le suffixe ms.
• udpport : indique le port à utiliser pour la prise de pouls.
• node : renseigne le nom des machines faisant partie du cluster. Ce nom doit être identique à celui retourné par la commande uname -n.
• auto_failback : indique le comportement à adopter si le node maître revient dans le cluster. Si on met la valeur on, lorsque le node maître revient dans le cluster, tout est transféré sur ce dernier. Si on met la valeur off, les services continuent à tourner sur l'esclave même lorsque le maître revient dans le cluster.
• apiauth : indique que l'uid root à le droit d'administrer à distance via le GUI (celà implique aussi à ajouter root dans le group haresources)
• crm : autorise les connexions distantes
• respawn : le binaire à lancer pour l'ouverture du port pour prise de la main à distance

Personnellement, je préfère la valeur off pour l'auto_failback pour pouvoir faire un retour à la normale manuellement lorsque la charge de production est moins importante. De plus, si le node maître souffre d'un grave problème, on pourrait avoir une boucle de démarrage/extinction qui entraînerait un relais des services de manière incessante. Ce qui peut devenir problématique.

5.2 haresources

Maintenant, nous allons définir le node maître, l'adresse IP du cluster et les services devant être assurés. Dans un premier temps (configuration basique oblige), nous allons uniquement mettre en place l'adresse IP du cluster.

Pour configurer cet aspect de HeartBeat, nous éditons le fichier haresources par le biais de la commande suivante :

sudo vi /etc/ha.d/haresources

ATTENTION : le fichier de configuration des resources doit être STRICTEMENT identique sur chacun des noeuds.

Dans notre exemple, le fichier de configuration des resources ressemble à ceci :

twin1 IPaddr::192.168.252.205

C'est à dire que nous définissons le node maître comme étant twin1 et que l'adresse IP du cluster est 192.168.252.205. Nous allons en rester là pour la configuration basique mais je vous invite à lire la section concernant la configuration avancée pour obtenir plus d'informations.

5.3 authkeys

Le fichier authkeys permet aux nodes de cluster de s'identifier mutuellement. Ce fichier s'édite via la commande suivante :

 sudo vi /etc/ha.d/authkeys

ATTENTION : le fichier de configuration des clés d'authentification doit être STRICTEMENT identique sur chacun des noeuds.

Dans notre exemple, le fichier authkeys ressemble à ceci :

auth 2
1 md5 "cluster twin test"
2 crc

Le mot clé auth indique quel est le système d'identification que l'on va utiliser. Si le lien n'est pas sûr physiquement, il est nécessaire d'utiliser un chiffrement md5 avec une chaîne de clé plus intelligente que celle-ci.

Dans notre cas, il n'y a que les deux twins sur un petit réseau local et donc nous utilisons le système crc.

Une fois le fichier édité, n'oubliez pas de le protéger en introduisant la commande :

sudo chmod 600 /etc/ha.d/authkeys

5.4 Mise en route et premiers essais

Avant de faire nos premiers essais, je vous suggère d'installer un serveur SSH sur chacun des serveurs. Cette page vous guidera pour l'installation du serveur SSH et l'utilisation du client SSH.

Vérifiez si les connexions SSH à chacun des nodes via leur adresse IP propre (192.168.252.200 et 192.168.252.201 dans notre exemple) fonctionnent. Si tel est le cas, nous pouvons faire un petit test.

Lancez le service HeartBeat sur le node maître; à savoir Twin 1 via la commande suivante :

sudo /etc/init.d/heartbeat start

Ensuite, à l'aide de la même commande, activez HeartBeat sur Twin 2.

Vous pouvez maintenant tenter une connexion SSH sur l'adresse du cluster; à savoir : 192.168.252.205 dans notre exemple. Une fois identifié, vous vous rendez compte que l'invite de ligne de commande vous dit que vous êtes sur twin1.

Maintenant, retirez fermement le cordon d'alimentation de Twin 1.

Votre console SSH va vous signaler une erreur (normal... ;-) ).

Relancez une connexion SSH sur l'adresse du cluster; à savoir : 192.168.252.205 dans notre exemple. Le service répond ! Or, Twin 1 est arrêté. Une fois identifié, vous vous rendez comtpe que l'invite de ligne de commande indique :

deimos@twin2:~$

Tout fonctionne. Maintenant, imaginons que Twin 1 revienne dans le cluster (remettez la prise de courant de Twin 1).

Le cluster tourne toujours sur Twin 2. Pour forcer le basculement sur Twin 1 (vu que l'on est en mode auto_failback off), on entre la commande suivante sur Twin 2 :

sudo /etc/init.d/heartbeat restart

Et Twin 1 reprend automatiquement le relais.

6 Configuration plus poussée

La ligne de configuration du fichier /etc/ha.d/haresources telle que définie ci-dessus indique uniquement que le node maître est Twin 1 et que l'adresse IP du cluster est 192.168.252.205. Selon cette configuration, HeartBeat fait le minimum, aucun script ou service n'est lancé ou arrêté sur les différents nodes composant le cluster.

Voyons comment on peut configurer avec plus de finesse le fichier haresources pour certains besoins spécifiques.

6.1 Octroyer plusieurs adresses IP pour le cluster

Nous avons écrit une ligne de ce type lors de la configuration de base :

twin1 IPaddr::192.168.252.205

Ce qui signifie que l'on assigne au cluster l'adresse IP 192.168.252.205. Cependant, on peut imaginer avoir besoin de plus d'une adresse IP pour accéder au cluster. C'est-à-dire que l'on a plusieurs points d'entrée vers le cluster et que chaque point d'entrée (adresse IP) permettra d'accéder au cluster.

Pour ce faire, nous configurons simplement les nodes avec le fichier /etc/ha.d/haresources suivant :

twin1 IPaddr::192.168.252.205 IPaddr::192.168.252.206

Et vous pouvez assigner autant d'adresse IP supplémentaires que l'on désire.

6.2 Spécifier les actions à effectuer

Une fois la configuration basique établie, c'est le node maître (si tout se passe bien) qui fournit les services pour l'extérieur. Si tous vos noeuds sont configurés de manière exactement identique et font tourner les mêmes services en permanence, cela ne pose aucun problème.

Si l'on veut être plus fin dans la configuration des nodes, on indique également les actions à entreprendre dans le cluster lorsqu'un node tombe. Cet aspect est primordial si certains services doivent accéder à des ressources exclusives (c'est-à-dire qu'un seul noeud à la fois peut utiliser une ressource particulière). C'est le cas des disques mirrorés via le réseau (voir RAID-1 over IP) où un seul node peut accéder au disque mirroré en lecture-écriture.

Pour palier ce genre de problème, on peut spécifier des actions à entreprendre en complétant le fichier /etc/ha.d/haresources. Pour spécifier ces actions, on utilise des scripts du style de l'Init System V (ou des scripts supplémentaire de HeartBeat ou encore des scripts fait-maison) pour indiquer ce que le cluster doit faire en cas de basculement d'un node vers un autre.

Prenons un exemple simple (mais non intéressant ;-)) : le service ssh. Le script Init de ce service se trouve dans /etc/init.d/ (ainsi que beaucoup d'autres; apache, inetd, rsync,...). Nous configurons le fichier /etc/ha.d/haresources (sur chacun des noeuds, ne l'oubliez pas !) de la manière suivante :

twin1 IPaddr::192.168.252.205 ssh

Cette ligne indique à HeartBeat les informations suivantes :

• Le node maître est twin1.
• L'adresse IP du cluster est 192.168.252.205.
• Les actions à entreprendre en cas de basculement sont : ssh.

Voyons en détail ce que signifie Les actions à entreprendre sont....

Les scripts utilisés par HeartBeat doivent répondre à 3 commandes : start, stop et status. Ces commandes sont appelées dans les cas suivants :

• start : appelé sur le node sur lequel le cluster vient de basculer.
• stop : appelé sur le node qui vient de tomber.

Donc, imaginons que ce soit Twin 1 qui répond aux requêtes adressées au cluster. Si Twin 1 tombe, HeartBeat exécutes ssh stop sur ce dernier (si c'est possible évidemment) ensuite, HeartBeat bascule l'IP sur Twin 2 et exécute ssh start sur ce dernier.

Dans le cas ssh, cela n'a pas beaucoup d'intérêt mais pour le montage des systèmes de fichiers ou pour simplement envoyer des emails, c'est indispensable.

L'ordre de recherches des scripts est le suivant :

• /etc/ha.d/resource.d/ : qui est installé par défaut et contient un certain nombre de script intéressants.
• /etc/init.d/ : qui est le répertoire d'usage pour le système d'Init System V.

Vous pouvez ajouter des scripts personnels dans /etc/ha.d/resource.d/ mais n'oubliez pas qu'ils doivent être capables de répondre aux commandes start, stop et status.

N'hésitez pas à regarder les quelques scripts se trouvant dans /etc/ha.d/resource.d pour vous en inspirer et savoir comment ils fonctionnent (syntaxiquement parlant).

7 Considérations pratiques

7.1 Concernant la liaison réseau

La solution décrite ci-dessus utilise la bande passante du réseau de manière intensive. Toutes les deux secondes (ou plus fréquemment encore suivant la configuration), chaque node va envoyer un paquet UDP sur chacun des autres nodes. En plus de cela, chaque node répondra à chacun des paquets envoyés. Je vous laisse imaginer le nombre de paquets transitant sur le réseau.

L'idéal est d'avoir des machines avec plusieurs cartes réseaux. Par exemple, nous pouvons utiliser deux cartes réseaux : une carte réseau pour les prises de pouls et une carte réseau pour les services.

Si votre cluster ne se compose que de deux noeuds, alors, il vaut mieux utiliser un câble croisé entre les deux machines afin de ne pas surcharger le réseau de production.

Quoiqu'il en soit, je vous conseille d'utiliser un réseau dédié à la prise de pouls et au basculement des services. Dans le cas contraire, vous allez au devant d'une surcharge de votre réseau de production et les performances vont légèrement chuter.

7.2 Concernant une liaison série complémentaire

Vous pouvez, en plus de la prise de pouls UDP, effectuer une prise de pouls directe via un câble série null modem qui connecte les deux machines. Cette prise de pouls est un complément efficace au réseau dans le cas où une interface réseau viendrait à tomber.

Pour utiliser cette liaison série supplémentaire, vous devez introduire les deux lignes suivantes dans le fichier /etc/ha.d/ha.cf (juste après la ligne bcast eth0) :

baud     19200
serial   /dev/ttyS0

Je n'irai pas plus loin concernant les liaisons séries car je n'ai pas eu l'occasion de les expérimenter. Lors d'un changement de configuration...

Lors d'un changement de configuration du cluster (les 3 fichiers de configuration de HeartBeat), vous devez forcer les processus heartbeat à relire les fichiers de configuration. Veillez toujours à avoir des fichiers de configurations identiques sur les différents noeuds de vos serveurs, sans quoi, le clustering ne fonctionnerait pas.

Pour forcer la relecture des fichiers de configuration, vous entrez la commande suivante sur chaque node du cluster en terminant par le node qui a le contrôle (normalement, le node maître sauf si vous êtes en situation catastrophe). Préparer les consoles et les commandes à l'avance pour que le temps durant lequel les noeuds ont des configurations différentes soit le plus court possible ! :

sudo /etc/init.d/heartbeat reload

Le solution la plus sûre étant de stopper tous les heartbeats, d'appliquer les modifications et de les relancer; mais parfois, les environnements de production ne permettent pas ce genre de chose.

7.3 Plusieurs clusters sur un même réseau

Récemment, j'ai ajouté un cluster supplémentaire sur un réseau dans lequel il y avait déjà un cluster. Cela a posé quelques problèmes (rien de grave, juste des logs gigantesques).

En fait, les noeuds du second cluster recevaient les paquets heartbeat broadcast et ne savaient pas les interprêter. Un message de warning dans la log de heartbeat donnait quelque chose ressemblant à ceci :

Aug  8 06:28:54 nodeprod1 heartbeat[6743]: ERROR: process_status_message: bad node [nodearch2] in message
Aug  8 06:28:54 nodeprod1 heartbeat[6743]: info: MSG: Dumping message with 9 fields
[...]

En fait, les noeuds s'envoiaient des messages en broadcast les uns aux autres sans savoir quoi en faire. Pour résoudre ce problème, il fallait supprimer le broadcast et utiliser soit l'unicast, soit le multicast.

Pour ce faire, il vous suffit de modifier le fichier /etc/ha.d/ha.cf et mettre en commentaire la ligne bcast <interface>. Ensuite, suivant le nombre de noeud de votre cluster (si vous n'avez que deux noeuds, l'unicast est suffisant) vous modifier la configuration.

Pour une configuration en unicast (toujours en suivant l'exemple ci-dessus) sur Twin1, on ajoute la ligne :

ucast eth1 192.168.252.201

Et pour Twin2, on ajoute la ligne :

ucast eth1 192.168.252.200

Pour une configuration en multicast (plus facile pour maintenir les fichiers identiques ou si il y a plus de deux noeuds), on ajoute la ligne suivante (sur les deux noeuds) :

mcast eth1 225.0.0.1 694 1 0
mcast <interface> <groupe multicast> <udp port> <ttl> 0

Le groupe multicast est une adresse que vous choisissez compise entre 224.0.0.0 - 239.255.255.255 par laquelle vos noeuds vont communiquer. Prenez garde à ne pas avoir d'autres systèmes utilisant ce groupe multicast. Le ttl indique le nombre de saut de réseau que le paquet peut effectuer (de 1 à 255). En général, les noeuds sont sur le même réseau et une valeur de 1 est parfaite.

Le zéro qui termine la ligne est un bug dans heartbeat ;-).

8 Ressources

Cluster Haute Disponibilité avec Equilibrage de charge
Documentation Vmware replication on Debian
Documentation on HA on Cent OS
Documentation on HA Load Balancer (With Failover and Session Support) With HAProxy/Heartbeat
How To Set Up A Loadbalanced High-Availability Apache Cluster Based On Ubuntu
Mise en place d'un OpenLDAP multimaitre
The Perfect Load-Balanced High-Availability Web Cluster With 2 Servers Running Xen On Ubuntu
Setting Up A High-Availability Load Balancer (With Failover and Session Support) With Perlbal Heartbeat On Debian