DRBD (4/5) : Pacemaker

[Laurent Caillette]

Nous avons vu que DRBD distingue deux types de ressoure : primaire et
secondaire. La ressource primaire est montable comme un périphérique
Unix et supporte les écritures. La ressource secondaire n'est pas
montable (en tous cas pas avec DRBD8). Il ne peut y avoir qu'une
ressource primaire à la fois.

En cas de panne de la machine où se trouve la ressource primaire,
comment promouvoir automatiquement la ressource secondaire en primaire
? Il faut également redémarrer les services, affecter les adresses IP,
etc.

On a toujours le choix d'une opération manuelle, qui n'est pas
forcément la pire des solutions. On pourrait aussi affecter une
machine à la surveillance de la machine hébergeant la ressource
primaire. Si la machine de surveillance détecte que la machine
hébergeant la ressource primaire n'est plus accessible, elle promeut
la machine hébergeant la ressource secondaire. Simple, non ?



=== Quorum

Sauf que si la machine hébergeant la ressource primaire se retrouve
isolée des deux autres, et nous voici avec deux ressources primaires
du fait de la promotion automatique. En vrai, il n'y a pas de solution
naïve. On voudrait centraliser une vision de toute la grappe (cluster)
alors que -- le réseau n'étant pas infaillible -- chaque nœud de la
grappe ne peut avoir qu'une vision partielle.

Comment s'en sortir ? La première étape consiste à définir un groupe
de machines, puis à élire un chef au sein de ce groupe. Le groupe
dépend de la configuration ; disons que tout le monde a la même.
Comment élire un chef si le groupe peut être divisé par une partition
réseau ? En posant comme règle qu'un chef doit être élu à la majorité
absolue, ce qui nécessite de rassembler un nombre minimum d'électeurs,
qu'on appelle //quorum//. Si on a une grappe de 5 serveurs, il suffit
que 3 d'entre eux se voient pour permettre la majorité absolue
(`3/5`). Les deux autres ne peuvent pas réunir le quorum. La formule
c'est que si on veut supporter la perte de ``n`` serveurs, il faut une
grappe de ``2n + 1``.


=== Pacemaker

"Pacemaker"
http://clusterlabs.org/wiki/Pacemaker
est l'outil qui distribue les configuration, s'assure que le quorum
est rassemblé, désigne un chef, et execute sur celui-ci les règles de
fonctionnement de la grappe. Il supporte des règles de ce genre :

<<
- La ressource ``nginx_mysql`` peut s'exécuter sur n'importe quel nœud.
- Elle contient un service ``drbd-master`` de type maître qui
nécessite une ressource ``drbd-slave`` sur un autre nœud.
- À cette ressource on attribue une adresse IP unique.
>>

Là c'est génial, Pacemaker gère tout seul la promotion de secondaire à
primaire pour DRBD.

Et hop ! Nous voici avec une grappe avec de la haute disponibilité. Sans rire.

Il y a quelques contraintes. La plus importante est que les services
acceptent d'être redémarrés, ce qui suppose qu'ils sauvegardent en
permanence tout leur état sur disque. Une autre contrainte c'est que
la restauration de cet état ne prenne pas trop de temps, sinon ce
n'est plus de la haute disponibilité.


=== Matériel

Il y a aussi un équilibre à trouver entre le budget, le nombre de 9
après la virgule qu'on espère pour le taux de disponibilité, la
stabilité des performances, et la capacité de se passer d'intervention
humaine. Même si c'est Google qui héberge, il y aura toujours un gars
qui passera avec son chariot pour ramasser les serveurs morts. Mais ça
reste de la maintenance planifiée, c'est toujours mieux que de se
faire réveiller à 3 heures du matin par un client chinois très fâché.

La maîtrise du matériel permet d'appliquer plein d'astuces qu'on
n'attend pas forcément de la part d'un hébergeur généraliste. Par
exemple :
- Ne pas installer sur la même machine deux disques issus du même lot,
car ils ont tendance à avoir les mêmes défauts.
- Doubler les commutateurs (switches) et utiliser les deux à la fois
en agrégeant les liens réseau (bonding).


=== Tire-moi une balle dans la tête de ce serveur

Lorsqu'un serveur se montre défaillant, on peut le redémarrer, mais il
y a des chances pour que son comportement ne s'améliore pas et qu'il
mette en danger le bon fonctionnement des autres serveurs. Par
exemple, en déclarant une adresse IP réaffectée ailleurs par
Pacemaker, ou en déclarant une deuxième ressource primaire DRBD.

Une solution consiste à désactiver ce serveur, ce qui porte le nom
d'encagement ("fencing"). Une variante de l'encagement s'appelle
"Tire-moi une balle dans la tête de ce serveur" (STONITH, "Shoot The
Other Node In The Head") qui consiste à forcer l'extinction du serveur
défaillant, ce qui marche mieux que de le laisser détecter tout seul
qu'il est défaillant et s'éteindre de son plein gré.

Évidemment si on repose sur une connexion réseau dont justement, la
défaillance est à l'origine du problème, ça risque de faire de sales
trucs. Une autre approche, supportée par Pacemaker, c'est de relier
chaque serveur à l'onduleur des voisins par port série, pour pouvoir
provoquer son extinction même si toute la couche réseau a planté.


=== Hébergement

Quelles sont les chances d'avoir quelque chose qui fonctionne sur une
infrastructure hébergée, que ce soient des serveurs dédiés, ou une
offre de type "nuage" ? Ça dépend. Disons qu'à un bout il y a quelque
chose comme Google AppEngine qui gère tout pour faire une application
d'échange de photos de chats, et de l'autre la solution de téléphonie
ultra-sensible aux latences, qui nécessitera de la couture au petit
point (on peut quand même louer une baie chez un hébergeur pour
bénéficier de locaux adaptés).


=== Pacemaker ou pas ?

Si l'on cherche à bâtir une solution de haute disponibilité, Pacemaker
semble un complément logique à DRBD, puisqu'on se pose un jour ou
l'autre la question de la promotion des ressources, du redémarrage,
etc. Pacemaker n'a pas non plus de caractère obligatoire. On peut
utiliser DRBD comme mémoire de masse répliquée (un SAN à bas coût sur
lequel on peut régler finement toutes les options), ou bien comme une
solution de sauvegarde en temps réel.