Pacemaker est un outil de gestion de ressources (une VIP, un service) pour vos clusters. Il va gérer la haute disponibilité en s’occupant de leur démarrage, redémarrage, arrêt. La communication entre vos nœuds et la gestion du cluster en lui-même seront assurées par une brique dédiée comme par exemple Corosync (ou une technologie plus ancienne mais dont le nom est plus connu : heartbeat). Grâce à ce couple, il est possible de monter rapidement des clusters à n nœuds et de gérer n’importe lequel de vos services. La seule “contrainte” est d’avoir un script pour lancer votre service qui doit répondre à une commande start, stop et status. Une autre possibilité sympathique : le mode actif/actif. Mais aussi la gestion des quorums, le stonith…

Problèmes rencontrés : rappels

Il faut bien garder en tête que ce n’est pas parce que le service A ou B est dans un cluster qu’il n’y aura plus jamais de problème. Un cluster, de par son concept, peut se retrouver confronté à un problème de taille : le “split-brain”. C’est le principal problème qu’il faut absolument éviter.

• Le “split-brain” peut intervenir quand chaque nœud de votre cluster croit son voisin hors service. Il va alors prendre la main : chaque nœud est donc maître et fournit le service. Les effets de bords peuvent être gênants dès lors qu’on utilise une ressource partagée. Pour se protéger un maximum de ce problème, il est fortement recommandé d’utiliser deux liens réseau différents pour la communication entre les nœuds (ou de faire du bonding).
• Un autre problème possible : quand votre nœud maître rencontre un problème, le cluster “bascule” . Un autre nœud prend la main et devient maître à son tour : il fournit le service. Mais dans quel état est l’autre nœud ? Comment s’assurer qu’il ne fournit pas encore le service au risque de bloquer/corrompre des ressources partagées ? Il n’y a pas vraiment de réponse à ce problème mais une solution, pas forcement évidente à mettre en place : Stonith. Stonith ou “Shoot The Other Node In The Head” ou encore “Shoot The Offending Node In The Head”. C’est une méthode d’isolation d’un nœud (fencing) qui pour une raison ou une autre ne répond plus. L’idée est d’éviter à tout prix le fameux split-brain qui peut amener tous vos nœuds à fournir le même service (ou à ne plus le fournir du tout). Le nœud jugé hors service sera donc, en général, redémarré ou arrêté électriquement (via IPMI par exemple). Voir l’article suivant pour plus d’informations : STONITH Deathmatch Explained.
• Pour finir, un autre point bloquant peut être le quorum : c’est le nombre minimum de nœuds en ligne pour être capable de valider une décision. Dans le cas d’un cluster avec Pacemaker, il faut que plus de la moitié des nœuds soit en ligne. Avec un cluster à deux nœuds, il n’y a plus de quorum dès qu’un nœud est perdu. Il va donc falloir demander à Pacemaker d’ignorer le quorum dans cette situation. Le fonctionnement par défaut quand le quorum n’est pas atteint est de couper toutes les ressources !

• Si vous utilisez des ressources partagées, utilisez Stonith. Si vous le pouvez, utilisez systématiquement Stonith.

• Ignorez la perte du quorum si vous n’en avez pas besoin.

Corosync et Pacemaker

Installation

Nous allons voir ici l’installation et la configuration de Corosync. Corosync va s’occuper de la mise en cluster de vos serveurs. Corosync est disponible dans de nombreuses distributions. Sur une Debian Squeeze, il s’installe via :

apt-get install corosync

Maintenant que la couche de communication entre les nœuds est installée, passons à l’installation de la couche de gestion des ressources. Pacemaker a été intégré dans le projet Debian depuis la Squeeze. Le paquet est également disponible sur d’autres distributions. Pour l’installer sur une Debian Squeeze :

apt-get install pacemaker

Configuration de Corosync

Editer le fichier de configuration de Corosync : /etc/corosync/corosync.conf (ce fichier doit être le même sur l’ensemble de vos noeuds). L’idée est d’augmenter un peu certains timers qui sont un petit peu bas (risque de déclarer un nœud hors service à tort par exemple) :

Il faut maintenant déclarer une interface réseau qui servira à la communication entre vos nœuds. Si vous ne faites pas de bonding, il faudra en déclarer une seconde pour éviter un “split-brain”.

Pour déclarer une interface réseau :

interface {
ringnumber: 0
bindnetaddr: 10.0.0.0
mcastaddr: 226.94.1.1
mcastport: 5405
}

Il vous faudra remplacer/rajouter :

• Votre adresse de réseau au niveau de bindnetaddr. Si par exemple, votre eth0 porte l’adresse IP 192.168.1.10 avec un netmask de 24, renseignez 192.168.1.0.
• Votre adresse de diffusion multicast et son port (ou utiliser celle là).
• Pour rajouter une deuxième interface, rajoutez un deuxième bloc “interface”, incrémentez le “ringnumber” et renseignez l’adresse de votre deuxième réseau ainsi qu’une nouvelle adresse de multicast. Il faudra changer le “rrp_mode” à active : vos deux interfaces réseau fonctionneront en même temps. Si vous mettez le “rrp_mode” à passive, la deuxième interface réseau ne s’activera que si la première est en échec.

Exemple :

rrp_mode: active
interface {
  ringnumber: 0
  bindnetaddr: 10.0.0.0
  mcastaddr: 226.94.1.1
  mcastport: 5405
}

interface {
  ringnumber: 1
  bindnetaddr: 192.168.0.0
  mcastaddr: 226.94.2.1
  mcastport: 5405
}

A savoir : si une de ces interfaces est en erreur, on a un message d’erreur dans les logs :

[TOTEM ] Marking seqid 3608 ringid 1 interface 192.168.0.2 FAULTY
administrative intervention required.

Il peut arriver de devoir remonter l’interface manuellement quand le problème est résolu via corosync-cfgtool -r (c’est le cas si on a désactivé manuellement l’interface). corosync-cfgtool -s vous donne l’état de vos interfaces.

Intégration de Pacemaker

Il faut maintenant rajouter le service Pacemaker dans votre cluster Corosync. Rajoutez le bloc suivant dans votre fichier de configuration Corosync s’il n’a pas été rajouté à l’installation de Pacemaker :

service {
# Load the Pacemaker Cluster Resource Manager
ver: 0
name: pacemaker
}

Authentification

• A l’installation du paquet, une clé a été générée pour authentifier votre nœud sur le cluster. Si vous souhaitez la recréer :

corosync-keygen

• Il faut ensuite envoyer la clé sur les nœuds qui composent votre cluster :

scp /etc/corosync/authkey root@mon_autre_nœud:/etc/corosync

La configuration du cluster est terminée. Activez le démarrage de corosync dans le fichier /etc/default/corosync. Il se démarre ensuite via /etc/init.d/corosync start. Nous verrons plus bas pour la configuration de Pacemaker.

crm_mon

Votre cluster est démarré : vous pouvez vous connecter au moniteur de Pacemaker via la commande crm_mon -1. Vous obtiendrez quelque chose de semblable :

============
Last updated: Fri Sep  9 23:38:26 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
0 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

Cet utilitaire remonte un certain nombre d’informations sur l’état général de votre cluster (nœuds ok, hs, offline ou en standby) mais aussi sur l’état de vos ressources (quel nœud gère quelle ressource, les éventuels problèmes rencontrés lors du lancement ou du monitoring de vos ressources…). Dans cet exemple, on peut lire :

• Last updated et stack : la dernière mise à jour des informations du moniteur et la couche de message utilisée. Openais car Corosync est dérivé d’Openais.
• Current DC : c’est le nœud qui va coordonner les actions sur le cluster. Les autres nœuds remonteront leurs informations au nœud DC. Ce nœud n’est pas nécessairement le nœud “maître” de votre cluster.
• Nodes & votes : le nombre de nœuds et le nombre de votes disponibles pour le quorum.
• Resources configured : le nombre de ressources configurées dans votre cluster.
• Online : la liste des nœuds online. On pourra trouver ici, la liste des nœuds offline ou en stand-by.

Configuration de Pacemaker

Avant de déclarer vos ressources, il faut configurer Pacemaker pour décrire le fonctionnement attendu de votre cluster : action en cas de perte du quorum, utilisation de stonith… Ce sont les deux points que nous allons voir dans l’exemple qui suit.

Pour configurer votre cluster, nous allons nous connecter au cli Pacemaker (sur le nœud de votre choix) via la commande crm :

root@ha-test2:~# crm
crm(live)# help
This is the CRM command line interface program.
Available commands:
	cib              manage shadow CIBs
	resource         resources management
	node             nodes management
	options          user preferences
	configure        CRM cluster configuration
	ra               resource agents information center
	status           show cluster status
	quit,bye,exit    exit the program
	help             show help
	end,cd,up        go back one level

crm(live)#

L’aide via help est disponible pour chaque commande. Passez dans le menu configure et tapez show. C’est votre configuration par défaut.

crm(live)configure# show
node ha-test1
node ha-test2

La liste de vos nœuds est affichée. Une commande edit permet d’éditer ce fichier. On peut aussi utiliser un certain nombre de commandes (voir help) pour modifier le comportement du cluster. On va ici désactiver le stonith et ignorer la perte du quorum : dans votre cli crm, en mode configure, tapez la commande suivante :

property stonith-enabled="false" no-quorum-policy="ignore"

• Vérifiez avec show que la configuration est ok.
• Il faut ensuite pousser les modifications sur l’ensemble des nœuds via la commande commit.

Pour résumer :

crm(live)configure# property stonith-enabled="false" \
	 no-quorum-policy="ignore"

crm(live)configure# show
node ha-test1
node ha-test2
property $id="cib-bootstrap-options" \
	stonith-enabled="false" \
	no-quorum-policy="ignore"

crm(live)configure# commit
WARNING: CIB changed in the meantime: won't touch it!
Do you still want to commit? y

Vous pouvez ignorer le WARNING au moment du commit. Votre cluster est maintenant prêt à recevoir les ressources : Apache, MySQL, DRBD, des VIPs… A suivre dans une série d’articles autour de Pacemaker.

Plus d’informations sur ClusterLabs