HeartBeat

LinuxHA-Logo

L’installation de Heartbeat sur RHEL6 m’a vraiment cassé les pieds. J’écris ce rapide article pour expliquer comment installer cette solution sur RHEL6.

Tout d’abord, je vous conseille d’installer les dépôts EPEL. Rendez-vous sur le site fedoraproject.org (EPEL), vous y trouverez le package « epel-release » qui vous permettra de les intégrer facilement à yum :

 rpm -iv epel-release-5-4.noarch.rpm

J’ai décomposé au maximum l’installation pour mettre en évidence les dépendances chaînées permettant l’installation de HeartBeat. Ça vous permettra d’identifier rapidement les causes d’un éventuel échec d’installation ou de compilation si vous passez par les sources… Si vous êtes contraint d’installer un .rpm pour pallier à l’absence d’une dépendance sur vos dépôts, je vous suggère d’utiliser la commande yum install plutôt que rpm. Yum tentera de résoudre lui-même les dépendances de ce paquet, ce qui peut vous épargner quelques étapes.

En cas d’absence d’une dépendance sur vos dépôts, allez faire un tour sur l’un de ces sites (le premier est mon préféré) :

  1. http://pkgs.org
  2. http://rpmfind.net
  3. http://rpm.pbone.net/

 Packages à installer

yum install gcc gcc-c++ kernel-devel
yum install libtool libtool-ltdl
yum install cluster-glue-libs-1.0.5-6.el6.x86_64.rpm
yum install cluster-glue-libs-devel-1.0.5-6.el6.x86_64.rpm
yum install perl-TimeDate
yum install cluster-glue-1.0.5-6.el6.x86_64.rpm
yum install cifs-utils libtalloc libtdb quota samba-common samba-winbind samba-winbind-clients libattr libcap popt
yum install resource-agents-3.9.2-21.el6.x86_64.rpm
yum install resource-agents-debuginfo-3.9.2-7.el6.x86_64.rpm
yum install PyXML
yum install heartbeat-libs-3.0.4-1.el6.x86_64.rpm heartbeat-3.0.4-1.el6.x86_64.rpm heartbeat-devel-3.0.4-1.el6.x86_64.rpm

Installation de HeartBeat

Il vous faudra créer le dossier /etc/ha.d/ s’il n’existe pas et faire de même pour les fichiers :

  • ha.cf
  • haresources
  • authkeys

 Authkeys :

Le fichier AuthKeys permet de configurer l’authentification des serveurs impliqués dans le dispositif de haute disponibilité.

auth 1
1 sha1 LesPetitsPédestres

Ha.cf

Le fichier de configuration de HeartBeat n’est pas nécessairement très long. Il peut-être judicieux d’utiliser les FQDN pour vos nodes.

keepalive 2
deadtime 5
#Specify the hearbeat interface and the backup VM IP
ucast eth0 192.168.17.141
#Specify the cluster elements as specified in the /etc/hosts file
node haproxy-1.0x0ff haproxy-2.0x0ff
#default value for auto_failback is "legacy" == warning at startup
auto_failback on
logfile /var/log/ha-log

haresources :

haresources nous permet de définir l’adresse IP virtuelle commune à tous les serveurs du cluster et les services à démarrer lorsqu’un serveur prend la main.

#IP of the VIP
haproxy-1.0x0ff IPaddr::192.168.17.143 haproxy

La ligne se compose de cette manière :

« Master Server» «Virtual IP» « service to launch with HeartBeat »

Les services associés sont exécutés grâce aux scripts présents dans /etc/ha.d/resource.d/ et s’ils ne sont pas trouvés à cet emplacement, dans /etc/init.d .

Attention il est très important de veiller à ce que le script utilisé soit LSB (Linux Standard Base, et non rien à voir avec 0x0ff ;)) compatible !

 Vérification de la compatibilité LSB

Ci après, une copie de la procédure pour tester la compatibilité du script selon les éditeurs de HeartBeat (Tiré de la page http://linux-ha.org/wiki/LSB_Resource_Agents, Cette copie a pour but de pérenniser l’information). Je l’ai traduite, histoire que l’on vienne pas dire que j’ai rien branlé !

Considérons que some_service est un service configuré correctement et pour le moment inactif. La séquence suivante vous aidera à déterminer si le script d’initialisation est compatible LSB :

Start (stopped)

/etc/init.d/some_service start ; echo "result: $?"

    • Le service à t-il démarré ?
    • Est-ce que la commande retourne result: 0 (en plus des informations standards)?

Status (running)

/etc/init.d/some_service status ; echo "result: $?"

    • Le script accepte-il la commande ?
    • Le script indique t-il que le service est démarré ?
    • Est-ce que la commande retourne result: 0 (en plus des informations standards)?

/etc/init.d/some_service start ; echo "result: $?"

    • Le service est-il toujours démarré ?
    • Est-ce que la commande retourne result: 0 (en plus des informations standards)?

/etc/init.d/some_service stop ; echo "result: $?"

    • Le service s’est il arrêté ?
    • Est-ce que la commande retourne result: 0 (en plus des informations standards)?

/etc/init.d/some_service status ; echo "result: $?"

    • Le script accepte-il la commande ?
    • Le script indique t-il que le service n’est  pas démarré ?
    • Est-ce que la commande retourne result: 3 (en plus des informations standards)?

Stop (stopped)

/etc/init.d/some_service stop ; echo "result: $?"

    • Le service est-il toujours arrêté ?
    • Est-ce que la commande retourne result: 0 (en plus des informations standards)?

Status (failed)

Cette étape n’est pas aisé a tester, elle nécessite une inspection manuelle du code. Le script peut optionnellement utiliser un des autres codes (autre que 3) listés dans les spécifications LSB pour indiquer si le service est actif mais en échec.

Dans une telle situation, le cluster est informé du problème. Le service est déplacé vers un autre nœud après que le service défaillant ait été stoppé. L’utilisation de ces codes supplémentaires est encouragée.

 Conclusions

Si la réponse à l’une des questions ci-dessus est no, votre script n’est pas conforme à la norme LSB.

Si vous utilisez Pacemaker resource management, alors vous devez :

  • Adapter le script pour le rendre compatible,
  • Ecrire un OCF Resource Agent basé sur le script existant

Si vous utilisez toujours le mode haresources de HeartBeat, le script devrait fonctionner aussi longtemps que vous suivrez les règles de Heartbeat Resource Agents.