Nous allons voir dans cet article comment mettre en place une IP "flottante" entre deux serveurs de façon à gérer la disponibilité de services. On va utiliser Heartbeat et Pacemaker sur une distribution Debian.
Heartbeat et Pacemaker
Présentations
Hearbeat va gérer la surveillance de la disponibilité des noeuds d'un cluster et exécute les actions nécessaires lors de la perte d'un noeud. On dis souvent qu'il écoute les "battements de coeur" des serveurs.
Heartbeat peut surveiller les noeuds sur différents types de connexion :
- connexion série
- connexion udp
- unicast
- ping
On défini un noeud comme un des éléments d'un cluster de serveur, ie, un serveur, ou une machine virtuelle.
Pacemaker est chargé de démarrer, arrêter et superviser les ressources du cluster.
Installation
Les prérequis sont les suivants:
- deux machines au moins
- ayant un réseau configuré
- ayant un dns configuré
- ayant l'heure synchronisée
Pour le point 3. il faut que les machines se connaissent niveau DNS, par exemple que node1 puisse pinguer node2. Il faut donc configurer correctement le DNS ou configurer les infos dans le fichier /etc/hosts.
Pour le point 4, le mieux est d'installer ntp sur les deux machines.
Il faut installer les services sur les deux machines :
# apt-get install heartbeat pacemaker
Heartbeat
Configuration
Le fichier de configuration est /etc/ha.d/ha.cf :
autojoin none
bcast eth0
warntime 3
deadtime 6
initdead 60
keepalive 1
node node01
node node02
crm respawn
autojoin : permet de définir qu'aucun noeud autre que ceux spécifiés dans la configuration peuvent rejoindre le cluster ;
bcast : défini que la méthode de communication entre les noeuds est le broadcast sur l'interface eth0. NB : il peut être intéressant pour éviter de "polluer" les réseaux d'avoir une interface dédiée entre les deux machines.
Les 4 paramètres suivant définissent des temps pour que Heartbeat définisse un noeud comme (ces temps sont définis en secondes) :
- peut-être "mort" avec warntime
- confirmé "mort" avec deadtime
- le temps maximum ou Heartbeat attends pour tester si un noeud démarre avec initdead
- le temps entre chaque battements avec keepalive
On définit ensuite la liste des noeuds. NB : heartbeat utilise le "nom court" d'une machine (hostname -s).
crm : définit le style de cluster de management utilisé avec Heartbeat (style 1.x ou 2.x), respaw définit un certain nombre de directives nécessaires
Il faudra recopier ce fichier sur le second noeud.
Secret partagé
Pour authentifier les noeuds dans le cluster on va définir un secret partagé entre chaque machines. Ce secret se trouve dans le fichier /etc/ha.d/authkeys.
Pour le générer :
# ( echo -ne "auth 1\n1 sha1 "; dd if=/dev/urandom bs=512 count=1 | openssl md5 ) > /etc/ha.d/authkeys
# chmod 600 /etc/ha.d/authkeys
Ce fichier doit être recopié sur tout les noeuds du cluster.
Une fois ces fichiers en place on peut redémarrer heartbeat et vérifier que tout fonctionne :
# /etc/init.d/heartbeat restart
# crm_mon -1 |grep Online
Online: [ node01 node02 ]
Ajout de ressources
Pour configurer les services à mettre en place en failover on va utiliser les outils crm.
Pacemaker utilise la notion de resource pour le éléments à configurer sur les noeuds, une resource peut être :
- une adresse IP
- un service tel que nginx, drbd ...
Mise en place d'une IP flottante
On appelle IP flottante une adresse IP pouvant basculer d'une machine à une autre, on parle aussi d'IP failover.
Mon réseau est le 192.168.14.0/24, chaque noeud à déja une adresse IP sur ce réseau. On va rajouter une IP pour l'accès aux services à mettre en haute disponibilité.
# crm configure property stonith-enabled=false
# crm configure property no-quorum-policy=ignore
# crm configure primitive VIP-1 ocf:heartbeat:IPaddr2 params ip="192.168.14.35" nic="eth0:0" cidr_netmask="24" op monitor interval="30s" timeout="20s"
Les deux première commandes appliquent des propriété particulières que nous verrons plus tars.
La commande importante est la troisième qui configure la primitive VIP-1 avec les propriétés suivantes :
IPV : correspond au nom de la ressource
ocf:heartbeat:IPaddr2 : définit le script à utiliser
params ip="192.168.14.35" cidr_netmask="24" nic="eth0:0" : les paramètres pour le script
op monitor interval="10s" : interval de temps de monitoring des ressources
On peut maintenant vérifier que la nouvelle ressource existe dans le cluster :
# crm_mon -1
============
Last updated: Wed Jun 3 08:31:06 2015
Last change: Wed Jun 3 08:30:58 2015 via cibadmin on node01
Stack: Heartbeat
Current DC: node01 (****************************) - partition with quorum
Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff
2 Nodes configured, unknown expected votes
2 Resources configured.
============
Online: [ node01 node02 ]
IPV (ocf::heartbeat:IPaddr2): Started node01
Test
Pour tester le basculement de l'IP sur le second noeud on va passer le noeud actuel en standbye :
# crm node standby node01
On vérifie :
# crm_mon
...
Node node01 (****************************): standby
Online: [ node02 ]
VIP-1 (ocf::heartbeat:IPaddr2): Started node02
L'ip à bien basculée sur l'autre noeud.
On repasse le premier node en actif (online) :
# crm node online node01
On vérifie :
# crm_mon -1
...
Online: [ node01 node02 ]
VIP-1 (ocf::heartbeat:IPaddr2): Started node02
Problème l'IP n'est pas revenue sur le premier noeud. En fait c'est le comportement par défaut, la resource ne revient pas directement sur le noeud sur lequel elle était au début. C'est important par exemple si on gère des serveurs de base de données, pendant le temps que le node1 était down sur le node2 des nouvelles écritures ont pu être faites dans les bases et donc si on reviens automatiquement à la situation de départ lors du redémarrage du node1, les bases sur celui-ci ne sont pas synchronisée, il faut donc une action manuelle pour resynchroniser les bases puis ensuite repasser les ressources sur le node1 avec la commande suivante :
# crm resource migrate VIP-1 node01
On verra qu'il est possible de changer ce comportement en utilisant crm location.
Ces notions seront approfondies plus tard.