IP failover avec Hearbeat et Pacemaker

modifié le : 13 septembre 2022,
par Guillaume Chéramy
 

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:

  1. deux machines au moins
  2. ayant un réseau configuré
  3. ayant un dns configuré
  4. 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.