[INFORMATION] Heartbeat (clustering)

[TibO]

Salut à tous,

bon je vais faire plusieurs chantiers sur les différentes technos que j'ai pu rencontrer, en faisant une brève présentation et en donnant sur quel contexte j'ai pu l'appliquer, et après j'essaierai de répondre au maximum de questions si vous en avez :)

Si y'a des experts en al matière, je leur demanderai de me corriger si je poste des bétises.

des notions de clustering sont nécessaires à la bonne compréhension de cette introduction :)

Heartbeat :

Heartbeat est une technologie dite de "clustering", c'est à dire qu'elle permet d'avoir un système dit de Haute Disponibilité (High Availability) pour accéder à des services ou des ressources sans risque de perte de service.
Ceci est un C/C d'une doc que j'ai déjà écrite :
Présentation et intérêt

Heartbeat est un logiciel Linux permettant de faire de la haute disponibilité sur un réseau entre plusieurs noeuds.


Explication et mise en place

L'application Zimbra n'étant actuellement supporté que sur la version Dapper (6.06) d'Ubuntu, nous avons commencé par essayer d'installer la version fournie avec les dépots. (la 2.0.6).
Il s'avère que cette version manque de beaucoup de fonctionnalités, et c'est pour cela qu'a été installée la version 2.1.3 en recompilation.


Installation

La page utilisée pour télécharger cette version est la suivante : http://linux-ha.org/download/index.html

Ensuite, dans le dossier dézippé du TGZ, vous avez une application ConfigureMe qu'il faut utiliser avec les flags configure puis make et install.
Si certains paquets manquent à l'installation, faites un
./ConfigureMe configure 2>&1 | more Et dès qu'un paquet apparait comme “missing”, faites un
apt-get install paquet Enfin comme on recompile à la main, il faut créer un group et un user pour heartbeat :
groupadd haclient
useradd -g haclient hacluster
passwd hacluster
Configuration

Une fois l'installation terminée (./ConfigureMe install terminé avec succès), il faut passer à la partie configuration. Il est possible d'utiliser Heartbeat en mode de configuration v1 (fichier haresources) ou en mode v2 (fichier cib.xml). La v1 ne permet pas de faire de surveillance, ce qui explique pourquoi nous allons utiliser la v2 !



Complément : la v1 permet juste de détecter si un noeud est "down" ou "up" et bascule tous les services si une des machines ne répond plus. La v2 permet quant à elle de "monitorer" des services, par exemple, si la machine marche, mais que le process apache se vautre, elle le relance, et si ça ne marche pas, bascule sur le 2e noeud.


Le fichier ha.cf (configuration du démon)


Le mieux est de lire chacune des parties de ce fichier pour comprendre à quoi elles servent. Voici le contenu du fichier ha.cf sur les 2 noeuds de notre cluster (ici : troll et gobelin) :

root@gobelin:~/heartbeat-2.1.3# egrep -v “^#|^$” /etc/ha.d/ha.cf 

bcast eth0 eth2 

coredumps true 

crm on 

debugfile /var/log/ha-debug 

initdead 30 

logfile /var/log/ha-log 

node gobelin troll 

respawn hacluster /usr/lib/heartbeat/dopd 

apiauth dopd gid=haclient uid=hacluster

Voici une explication rapide des différentes fonctions
Ligne de commande Valeur Explication bcast eth0 eth2 Interface(s) sur la(les)quelle(s) seront broadcastées les infos hearbeat coredumps true … crm on Utilisation de la configuration v2 au lieu de v1 debugfile /var/log/ha-debug Nom du fichier de log debug logfile /var/log/ha-log Nom du fichier de log standard initdead 30 Temps d'attente de l'autre noeud au boot du process avant de le considérer comme mort node gobelin troll Noms des noeuds participants au cluster (IL FAUT QU'ILS SOIENT DANS /etc/hosts en cas de problème DNS !!) respawn hacluster /usr/lib/heartbeat/dopd Si jamais le cluster est redémarré, lancement du process dopd pour le split brain apiauth dopd gid=haclient uid=hacluster Infos pour le fork du process dopd Une fois notre fichier créé, il doit être identique sur les 2 noeuds.

Configuration des resources (cib.xml)

Pour la configuration du fichier xml, le plus simple est d'utiliser la GUI fournie à partir des version 2.1.x Pour cela il suffit d'utiliser la commande
hb_gui Si vous êtes en SSH, il vous faut bien sur un serveur X exporté (soit avec la commande ssh -X sous linux, soit avec Exceed ou Cygwin sous Windows).
Voici l'interface Graphique une fois lancée :

Ici vous voyez que tout est déjà configuré. Pour tout configurer, voici l'ordre de fonctionnement : tout d'abord, créer un groupe qui contiendra toutes les resources qui doivent ne tourner que sur un noeud à la fois et qui basculera entièrement lors d'une perte de serveur. Ensuite, créer autant de resources natives dont vous avez besoin, en utilisant à chaque fois un script LSB ou OCF de la liste
[b]L'ordre de création des ressources influe sur l'ordre de leur lancement ! Ne mettez pas une ressource de montage de système de fichier avant une ressource disque par exemple…
Ici on crééra donc dans l'ordre une ressource drbddisk, une resource Filesystem, une resource IpAddr pour l'IP de service et une ressource “apache” utilisée à des fins de test. Exemple de gestion de ressource drbddisk :

Ensuite il faut créer une “Location” qui expliquera à Heartbeat sur quel node se lancer en priorité :

Ensuite la GUI vous indiquera quelles sont les erreurs eventuelles dans les fichiers indiqués dans ha-debugfile et logfile.
Pour utiliser DRBD En tant que ressource, DRBD doit être installé et lancé pour que Heartbeat puisse le gérer.

Je vais de ce pas créer un petit article DRBD pour compliquer les choses :D

N'hésitez pas à poser des questions !

A plus

TibO

[khamlon]

il me semblait que le clustering consiste à lancer un traitement en parallèle sur plusieurs machine ce qui me semble différent de la haute dispo... j'ai loupé un truc?

[TibO]

si c'est exact :)

mais comme on fait appel à une IP de service commune, et que tu ne sais pas sur quelle machine tu travailles, j'ai "confondu" ça avec le clustering.

Au temps pour moi :)

[kristal]

coucou!
en fait, le clustering est juste une méthode d'optimisation définit de "fail over" pour assurer les services même dans le cas d'une défaillance matériel du derveur principal et de "load balancing" si il s'agit de partager une lourde tâche (ou plusieurs requêtes) entre un groupe de serveur travaillant en "synchro". N'est-ce pas?

[Pilo]

oui oui, c'est ça

[TibO]

Nan en fait c'est pas exactement ça. Le clustering c'est du partage de temps processeur pour que tu aies x serveurs, qui n'en paraissent qu'un seul au client, mais qui font tous les calculs ensemble.

Le failover/high availability, c'est ce que je décris ici, à savoir si ça pète d'un côté, ça switch

Le load balancing, c'est par exemple avoir 2 serveurs frontaux pour un meme service, servi par 4 serveurs de travail derrière avec des appels et des tâches réparties selon les dispos et les charges de chaque serveur.