DRBD (5/5) : conclusion et perspectives

[Laurent Caillette]

Pacemaker et DRBD remettent sur le tapis l'éternelle question de ce
qui doit rester du domaine applicatif, et de ce qu'on doit déléguer à
l'infrastructure et au système d'exploitation.


=== À quel niveau intégrer ?

Le cas s'apparente à celui du serveur Web généraliste contre celui du
serveur Web embarqué. Si on a juste un tas de fichiers statiques à
servir, pourquoi s'embêter avec autre chose qu'un Apache ou qu'un
nginx tout frais sorti de la boîte ? À l'opposé, si on veut faire des
choses avec des WebSockets, il faut une relation étroite avec le
comportement applicatif et le plus simple consiste alors à intégrer le
serveur HTTP dans le code applicatif (d'ailleurs Netty n'envisage rien
d'autre).

L'analogie avec les conteneurs Web a ses limites, car DRBD couvre
beaucoup plus de cas d'utilisation. Par exemple il est utilisable pour
des sauvegardes en quasi temps réel. Avec un peu de configuration, on
peut demander à la machine qui héberge la ressource secondaire de
prendre un instantané LVM, et de remonter l'instantané avant
d'appliquer une sauvegarde incrémentale.

Et pourtant il y a plein de raisons de gérer les sauvegardes au niveau
applicatif ! Par exemple, pour décider du meilleur moment, extraire
des métadonnées pertinentes, ou vérifier l'intégrité des données lors
de la restauration.


=== Pacemaker : limitations de l'approche "boîte noire"

Mais revenons à la haute disponibilité. Lorsque Pacemaker détecte
qu'un nœud faisant tourner un service a planté, il va le redémarrer
ailleurs. Évidemment il s'agit d'un démarrage à froid, qui peut
prendre un temps certain selon la quantité d'état à reconstruire. On a
envie de crier au gâchis, puisqu'on avait eu le temps de monter en
mémoire toutes ces données déjà reçues au rythme de la réplication. Un
autre souci, c'est ne pas pouvoir dédier une machine de secours à
servir des données en lecture seule (mode "esclave"), puisque la
ressource DRBD n'est pas montable. Et même si elle l'était (avec
DRBD9) il faudrait pouvoir requêter une base de données utilisant un
volume en lecture seule dont le contenu change arbitrairement ; aucune
base de donnée relationnelle ne doit supporter ça.

Si on veut intégrer la notion de serveur esclave, il faut que le code
applicatif ait une connaissance minimale de l'état de la grappe. Donc
soit il communique avec Pacemaker (il semblerait qu'il y ait une API
pour ça), soit il prend les commandes en embarquant un produit qui
assure la haute disponibilité. Et là ça peut devenir //très//
compliqué.


=== Difficultés de l'approche "boîte blanche"

D'une part il faut que la logique applicative rentre dans les
contraintes de la réplication. L'idéal c'est de pouvoir décrire l'état
de l'application grâce à une séquence de commandes qu'on réplique au
fil de l'eau, selon le modèle de conception dit du "sourçage
d'événements" ("event sourcing"). Si ce n'est pas possible, il faut
jouer avec des relations de causalité entre sous-séquences
d'événements et plein de trucs sortant du cadre de ce billet. On peut
se faire une idée en lisant l'excellent papier "Dynamo: Amazon's
Highly Available Key-value Store"
http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
et en se demandant comment faire tenir son application favorite de
gestion de chats dans un machin pareil.


=== ZooKeeper

D'autre part, au moins dans le monde Java, il n'y a pas beaucoup de
produits pour aider. On cite souvent "ZooKeeper"
https://zookeeper.apache.org
mais il se destine tout d'abord aux auteurs de conteneurs
d'applications distribuées. Il faut se lever de bonne heure pour
trouver de la logique applicative qui s'appuie directement sur
ZooKeeper.


=== Atomix

Toujours dans le monde Java, on a peut-être un début de lumière du
côté d'"Atomix"
http://atomix.io
qui fournit notamment une implémentation de Raft sur étagère. Le
protocole Raft comporte une caractéristique fabuleuse : il traite dans
le même flux des messages applicatifs et des événements décrivant la
disponibilité des membres de la grappe (en se basant sur un quorum,
tout comme Pacemaker). Si on peut se contenter d'un seul serveur
maître, Atomix pourrait fournir un début de solution, sous réserve
qu'il fonctionne.


=== Le rouleau-compresseur de la conteneurisation

On le voit, la haute disponibilité au niveau applicatif est un sujet
très neuf. Pour l'instant, la mode est aux conteneurs de niveau
applicatif. Docker a popularisé le sujet, mais l'écosystème est en
pleine explosion avec des projets comme CoreOS, Kubernetes, Project
Atomic... Sans parler d'OpenStack et des offres de virtualisation déjà
connues. Tous ces projets bénéficient d'investissements colossaux et
font tout pour devenir la couche d'abstraction au-dessus de toutes les
autres. Il est logique qu'ils poussent des solutions de haute
disponibilité de type "boîte noire", à l'instar de ce que fait
Pacemaker.

On peut se donner quelques années avant que les limitations d'une
telle approche deviennent un fait connu, et que les bibliothèques pour
assurer la haute disponibilité au niveau du code applicatif maturent
dans l'ombre, tranquillement.

Pour en revenir à DRBD -- le sujet initial -- c'est un produit qui
supporte suffisamment de cas d'utilisation pour que chacun puisse y
jeter au moins un coup d'œil.



=== Dédicace

Ce billet fait suite à une formation DRBD assurée par "Netiant"
http://www.netiant.com
, partenaire de LINBIT. Jérôme Martin, le formateur, dispose d'un
savoir encyclopédique sur le sujet des systèmes distribués. Trois
jours ne sont pas de trop pour se faire une image claire du
fonctionnement de DRBD afin de voir toutes les facilités offertes, les
options d'optimisation, et les principaux scénarios de reprise sur
panne.