Haute disponibilité avec Pacemaker et Corosync

Tout d’abord un bref descriptif de la haute disponibilité:

On appelle « haute disponibilité » (en anglais « high availability ») toutes les dispositions visant à garantir la disponibilité d’un service, c’est-à-dire assurer le bon fonctionnement d’un service 24H/24.

Le terme « disponibilité » désigne la probabilité qu’un service soit en bon état de fonctionnement à un instant donné.

Pacemaker and Corosync

Nous allons tout d’abord installer les 2 outils qui seront nécessaires:  Corosync et Pacemaker.

Corosync va permettre de mettre les serveurs utilisés en cluster et Pacemaker va s’occuper de la gestion des ressources. 

# apt-get install corosync
# apt-get install pacemaker

Passons maintenant à la configuration de Corosync. Le fichier de configuration devra être le même sur chaque noeud

 # nano /etc/corosync/corosync.conf

Il va falloir faire quelques modifications afin d’éviter l’apparition d’erreurs:

token: 5000
token_retransmits_before_loss_const: 20
join: 1000
consensus: 7500
max_messages: 20
secauth: on # We use a key to allow a node to connect to the cluster

Nous allons maintenant définir une interface réseau qui autorisera la communication entre les différents noeuds:

interface {
 ringnumber: 0
 bindnetaddr: 10.10.10.0 // Adresse réseau à adapter selon le cas
 mcastaddr: 226.94.1.1
 mcastport: 5405
 }

Intégrons maintenant le service Pacemaker au cluster de Corosync. 
Assurons nous que le fichier de configuration de Corosync contienne bien les lignes suivantes:

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

On va maintenant s’occuper de l’authentification. Une clé a été générée durant l’installation des packages, il est possible d’en recréer une de cette manière:

# corosync-keygen

Ensuite on va envoyer la clé à/aux autre(s) noeud(s) (dans notre cas nous n’aurons que 2 serveurs, donc 2 noeuds):

# scp /etc/corosync/authkey root@My_other_node:/etc/corosync

La configuration du cluster étant terminée, il faut maintenant activer Corosync:

# nano /etc/default/corosync

On redémarre alors le service:

# /etc/init.d/corosync start

Passons maintenant à la configuration de Pacemaker:

Note : Pour se connecter à la console de Pacemaker, on se contente d’utiliser la commande suivante:  crm_mon -1

Sur n’importe lequel des noeuds, on va se connecter au CLI (Common-Line Interface) pour configurer le cluster de Pacemaker (afin de définir le comportement désiré):

# crm

Il est possible de connaître notre configuration déjà existante en utilisant la commande suivante :

# configure
# show

On exécute ensuite la commande suivante (toujours en mode configure):

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

Stonith est un composant de Pacemaker qui permet au système de redémarrer le serveur qui a échoué. Dans notre cas, ce composant est désactivé. Nous allons également ignoré la perte du quorum  (le nombre minimum de noeuds en ligne afin de permettre la validation  d’une décision). Avec un cluster de 2 noeuds, il n’y a pas de quorum quand un noeud est perdu. L’opération par défaut quand il n’y a pas de quorum est de couper toutes les ressources.

On peut s’assurer de la bonne configuration en utilisant la commande show.
On doit alors forcer la prise en compte des changements sur tous les noeuds en utilisant la commande commit.

Service Actif/Passif

Le service sera lancé et supervisé par Pacemaker, pas besoin de le lancer au démarrage du système. Pour désactiver ce lancement sur une Debian (Squeeze):

# insserv –r –v service

Le service qui sera supervisé devra être installé et configuré de la même manière sur chacun des noeuds.

Le VIP est l’adresse virtuelle utilisée pour accéder aux service avec haute disponibilité. Cette adresse sera ajoutée comme une seconde adresse sur l’interface de notre choix.

Les commandes suivantes doivent être réalisées sur les 2 noeuds (l’adresse IP sera modifiée selon le cas):

# crm configure
# primitive VIP1 ocf:heartbeat:IPaddr2 \
params ip="192.168.1.100" broadcast="192.168.1.255" nic="eth0" cidr_netmask="24" iflabel="VIP1" \
op monitor interval="30s" timeout="20s"
# commit

Une nouvelle interface, appelée eth1: VIP1, vient d’être ajoutée.

Nous allons à présent ajouter le service. Nous nous occuperons ici d’Apache, mais le processus est le même pour d’autres services.
Toujours en mode configure (et sans oublier le commit à la fin), nous ajoutons:

# primitive APACHE ocf:heartbeat:apache \
params configfile="/etc/apache2/apache2.conf" \
op monitor interval="30s" timeout="20s" \
op start interval="0" timeout="40s" \
op stop interval="0" timeout="60s"

Malheureusement, en utilisant la commande show, on peut voir que VIP1 est lancé sur un serveur et qu’Apache l’est sur l’autre. Il faut qu’ils soient lancés sur le même.

Certains changements doivent être faits.
Il faut que le service tourne sur un des noeuds et qu’en cas de perturbation du service, celui-ci passera sur l’autre noeud (après 3 tentatives).

# crm configure
# group APACHE-HA VIP1 APACHE meta migration-threshold="3"
# commit
APACHE and VIP1 are grouped in the APACHE-HA group.

Nous désactivons également l’auto-failback. Le noeud restera en mode passif même lorsque le problème aura été résolu.

# crm configure
# property default-resource-stickiness= « 10 »
# commit

Les tests

On coupe le serveur qui fait tourner le service, les ressources sont transmises à l’autre serveur et reste actives sur celui-ci même si le serveur (anciennement actif) et redémarré.

On pourrait aussi couper Apache. Après la 3ème tentative pour le relancer, le sercice est lancé sur l’autre noeud.
Il faudra alors remettre à zéro le compteur sur le noeud qui a rencontré des erreurs:

# crm resource cleanup APACHE-HA