DRBD (3/5) : fonctionnement et mise en œuvre

[Laurent Caillette]

DRBD fonctionne avec une ressource primaire sur lequel ont lieu les
accès, et une ressource secondaire. On peut promouvoir la secondaire
en primaire uniquement si l'autre est secondaire, ou si la connexion
réseau est perdue. Il n'est pas possible de monter une ressource
secondaire, même en lecture seule (ça va l'être avec DRBD9). Il n'est
pas possible d'avoir deux ressources primaires (enfin si mais activer
cette option invalide le support). Avec DRBD8, on ne peut avoir qu'une
seule ressource secondaire pour une primaire mais DRBD9 en autorise
jusqu'à 32 -- il faut être sûr que le réseau suive-_.


=== Journal d'activité

Dans les métadonnées, on trouve notamment un journal d'activité
("Activity log") qui correspond aux écritures en cours. Le but de
DRBD, c'est qu'une application qui s'arrête brutalement suite à
l'extinction d'un serveur puisse retrouver le même état sur le serveur
d'à côté. N'oublions pas que DRBD simule un périphérique en mode bloc,
et n'a aucune idée de ce que font exactement les applications qui
accèdent au système de fichiers, ni du niveau de concurrence d'accès.
Si on dit à l'application que l'écriture a échoué, elle peut prendre
certaines décisions (comme envoyer un message sur le réseau) qui ne
seraient pas cohérentes avec une écriture réussie, au moment où on
redémarre sur le serveur de secours. DRBD n'en sait rien, donc dans le
doute il fournit un mécanisme transactionnel analogue à la validation
à deux phases ("two-phase commit") des bases de données.


=== Identifiants de génération

Toujours dans les métadonnées, on trouve des identifiants de
génération qui indiquent la version des données en cours. Ceux qui
connaissent git imaginent aussitôt qu'il s'agit d'un pointeur sur un
identifiant d'une entrée dans le journal d'activité. Mais non, cet
identifiant s'avère purement aléatoire. Il y a identifiant de la
génération de données de la ressource primaire, et le dernier
identifiant connu pour la ressource secondaire. L'identifiant de
génération de la ressource primaire ne change que dans deux cas :
- Quand la ressource primaire a réussi une synchronisation.
- Quand la ressource primaire est déconnectée, et qu'on vient
d'effectuer une écriture.
DRBD recopie l'identifiant de ressource primaire dans l'identifiant de
ressource secondaire après une synchronisation réussie. Ce sont ces
identifiants qui vont permettre de savoir où on en est après une
partition réseau. Tant qu'on a la connexion, pas de souci, on peut
dire si on est en phase, mais si on n'a plus la connexion, alors une
écriture sur le primaire crérait une divergeance avec le secondaire.
Si on n'a pas divergé, alors pas besoin de lancer une
resynchronisation complète lors de la reconnexion.

Pas besoin de voir tous les cas de figure, ce qu'il faut retenir c'est
que dans certains cas, DRBD peut se remettre tout seul d'une partition
de réseau parce qu'il détecte que les données n'ont pas divergé. Sinon
ça se termine par une réconciliation manuelle (par exemple en
comparant le contenu des bases de données) mais ça veut dire que
quelque chose ou quelqu'un a promu la ressource secondaire en
ressource primaire, ce n'est pas DRBD qui s'est gaufré.


=== Mise en œuvre

Si on maîtrise LVM et les systèmes de fichiers sur Linux, une mise en
œuvre minimale de DRBD nécessite aussi peu de travail que possible :
10 lignes de fichier de configuration et trois coups de ``drbdadm``.
Ça se teste avec une paire de machines virtuelles dont les volumes
sont correctement configurés. La synchronisation initiale peut prendre
du temps (il n'y a rien de gratuit, ça dépend du réseau et du disque)
mais il y a même des options pour l'éviter.

La partie compliquée réside évidemment dans la bascule vers le volume
secondaire en cas de panne. Là, DRBD offre une option assez
fantastique. Si le disque physique utilisé par le DRBD primaire
rencontre une erreur d'entrée-sortie, alors DRBD bascule en mode
"détaché", c'est à dire que le volume DRBD primaire va écrire et lire
ses données sur le volume secondaire via le réseau. La vie du serveur
se retrouve littéralement accrochée à un fil (le câble réseau) mais
gagne le temps d'intervenir pour changer le disque primaire, par
exemple. Cette fonctionnalité peut justifier à elle seule l'adoption
de DRBD.

Si c'est tout le serveur primaire qui flambe alors que fait-on ? Il
faut promouvoir le secondaire en primaire, monter le volume, et
redémarrer les services (et probablement réassigner une adresse IP).

Comment décider, si ce n'est par une opération manuelle ? Ce sera le
sujet du prochain épisode.