✎ heartbeat [Wiki ubuntu-fr]

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

{{tag>Hoary Breezy Dapper serveur réseau haute-disponibilité cluster}}

----

====== Heartbeat : cluster de haute disponibilité actif/actif ou actif/passif ======

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

===== Préambule =====

L'article qui suit se base sur une configuration de test identique à l'article concernant [[:drbd|le RAID-1 over IP avec DRBD]].

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.

=== Twin 1 ===

* Maître / Primaire
  * Pentium 3  -  500 MHz  -  128Mo RAM
  * Installation neuve de Hoary en mode minimaliste (option : ''server'' au boot du CD)
  * Mise à niveau de l'image vers 2.6.10-5-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)

=== Twin 2 ===

* Esclave / Secondaire
  * Pentium 3  -  700 MHz  -  128Mo RAM
  * Installation neuve de Hoary en mode minimaliste (option : ''server'' au boot du CD)
  * Mise à niveau de l'image vers 2.6.10-5-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)

=== Etats des machines ===

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

* Installation en mode ''server'' à partir du CD d'installation x86 Hoary 5.04 et configuration réseau manuelle.

* Mise à jour de quelques paquets basiques via Internet.
<code>
sudo apt-get update
sudo apt-get upgrade
</code>
  * 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.

<code>
sudo apt-get install linux-image-2.6.10-5-686
sudo reboot
</code>

===== Installation d'HeartBeat =====

HeartBeat s'installe très simplement sur une Ubuntu Hoary. 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) :

<code>
sudo apt-get install heartbeat
</code>

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.

===== 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 deux buts :
   * fournir une base commune aux articles concernant la haute disponibilité sur le wiki.
   * 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.

=== /etc/ha.d/ha.cf ===

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

<code>
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
</code>

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 nœud 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. Personnellement, je préfère la valeur ''off'' 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. |

=== /etc/ha.d/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 [[:tutoriel:comment_editer_un_fichier|éditons le fichier]] **/etc/ha.d/haresources**.

<note warning>Le fichier de configuration des ressources doit être **strictement** identique sur chacun des nœuds.</note>

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

<code>
twin1 IPaddr::192.168.252.205
</code>

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.

=== /etc/ha.d/authkeys ===

Le fichier **/etc/ha.d/authkeys** permet aux nodes de cluster de s'identifier mutuellement. [[:tutoriel:comment_editer_un_fichier|Éditez-le]].

<note warning>Le fichier de configuration des clés d'authentification doit être **strictement** identique sur chacun des nœuds.</note>

Dans notre exemple, ce fichier ressemble à ceci :

<code>
auth 2
1 md5 "cluster twin test"
2 crc
</code>

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 :

<code>
sudo chmod 600 /etc/ha.d/authkeys
</code>

=== 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. [[:ssh|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 :

<code>
sudo /etc/init.d/heartbeat start
</code>

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 compte que l'invite de ligne de commande indique :

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 :

<code>
sudo /etc/init.d/heartbeat restart
</code>

Et Twin 1 reprend automatiquement le relais.

===== Configuration avancé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.

=== Octroyer plusieurs adresses IP pour le cluster ===

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

<code>
twin1 IPaddr::192.168.252.205
</code>

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 :

<code>
twin1 IPaddr::192.168.252.205 IPaddr::192.168.252.206
</code>

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

=== 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 article [[:drbd|RAID-1 over IP]]) où un seul node peut accéder au disque //mirroré// en lecture-écriture.

Pour pallier 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 moins 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 nœuds, ne l'oubliez pas !) de la manière suivante :

<code>
twin1 IPaddr::192.168.252.205 ssh
</code>

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, le démon HeartBeat qui tourne sur Twin1 y exécute ''ssh stop'' (si c'est possible évidemment), de même le démon HeartBeat qui tourne sur Twin2 s'aperçoit que Twin1 ne répond plus ; il récupère l'IP du cluster et exécute ''ssh start''.

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 recherche des scripts est le suivant :
  * ''/etc/ha.d/resource.d/'' : qui est installé par défaut et contient un certain nombre de scripts 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).

===== Considérations pratiques =====

=== 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 nœuds, 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.

=== 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'') :

<code>
baud     19200
serial   /dev/ttyS0
</code>

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 nœuds 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 nœuds ont des configurations différentes soit le plus court possible ! :

<code>
sudo /etc/init.d/heartbeat reload
</code>

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.

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

<code>
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
[...]
</code>

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 nœuds de votre cluster (si vous n'avez que deux nœuds, 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 : 
<code>
ucast eth1 192.168.252.201
</code>

Et pour Twin2, on ajoute la ligne :
<code>
ucast eth1 192.168.252.200
</code>

Pour une configuration en [[multicast|multicast]] (plus facile pour maintenir les fichiers identiques ou si il y a plus de deux nœuds), on ajoute la ligne suivante (sur les deux nœuds) :
<code>
mcast eth1 225.0.0.1 694 1 0
mcast <interface> <groupe multicast> <udp port> <ttl> 0
</code>

Le groupe multicast est une adresse que vous choisissez comprise entre 224.0.0.0 et 239.255.255.255 par laquelle vos nœuds 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 nœuds 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 ;-).

----

//Contributeur : [[utilisateurs:ostaquet]].//

Merci de recopier le code ci-contre pour prouver que vous êtes humain : W᠎ I A H X Merci de laisser ce champ vide :

Résumé

Note : En modifiant cette page, vous acceptez que le contenu soit placé sous les termes de la licence suivante : CC Paternité-Partage des Conditions Initiales à l'Identique 3.0 Unported