1. Apéritif

Afin de mettre en œuvre ce qui va suivre, j'ai préparé deux machines virtuelles sous KVM, disons " arnold " et " willy " sous Debian GNU/Linux Squeeze. Bien qu'elle ne soit pas encore publiée, elle est gelée et j'ai donc bon espoir qu'elle ne soit pas aussi retardée que la Woody. Surtout, la prise en charge de DRBD 0.8 et de GFS2 est à un stade bien plus avancé que la Lenny. Les deux machines virtuelles possèdent une patte dans le réseau LAN en 192.168.69.0/24 et une patte dans le réseau de stockage en 192.168.254.0/24.

2. DRBD

2.1. Installation

Depuis la Squeeze, le module noyau drbd est intégré en standard, il n'est donc plus nécessaire de passer par module-assistant pour son installation. On installe juste le nécessaire sur les deux serveurs via un simple :

2.2. Deux nœuds primaires

Par défaut, DRBD ne permet pas de mettre en œuvre le multi-maître. Il faut donc lui spécifier le nécessaire dans les options globales du fichier /etc/drbd.d/global_common.conf.

Il faut donc définir qu'on autorise les deux nœuds à devenir des nœuds maîtres (section net) et ce, dès le démarrage du service (startup). Dans le bloc syncer, on définit le débit maximal du réseau de stockage et la fonction de hash qui s'assurera que les données sont correctement répliquées. On peut utiliser à ce niveau tout algorithme de hash supporté par le noyau.

2.3. Paramétrage du stockage répliqué

Sur chacun des serveurs, on crée un fichier /etc/drbd.d/cluster.res qui contiendra la configuration du stockage partagé. La configuration de DRBD doit être identique sur les deux serveurs, par conséquent le plus simple reste de faire le paramétrage sur un serveur et de copier la configuration via scp.

Le fichier parle de lui-même pour la plupart des éléments de configuration. On définit une ressource DRBD nommée r0, accessible via le périphérique /dev/drbd0. Sur chaque serveur, on définit le périphérique bloc (de taille identique) qui sera répliqué au travers du réseau. meta-disk indique que les métadonnées seront stockées en fin de fichier. Un point plus important est la notion de protocole :

• protocol A considère les données écrites lorsque les données de réplication sont dans le buffer TCP ;
• protocol B considère les données écrites lorsque les données de réplication sont dans le cache disque distant ;
• protocol C considère les données écrites lorsque les données sont écrites sur les deux nÅ“uds du cluster, c'est donc logiquement le plus fiable.

2.4. Alors, ça marche ?

Tout d'abord, il faut créer la ressource drbd à partir de ce qui est spécifié dans les fichiers de configuration précédents. Ceci est fait par le script d'init de drbd, mais il me semble plus intéressant de voir en détail les commandes lancées par ce script au premier lancement sur les deux nœuds :

Si tout s'est bien passé, on peut lancer la synchronisation initiale. À partir de ce moment, les deux nœuds restent en secondaire tant que la synchronisation n'est pas lancée. Celle-ci peut être lancée indifféremment du nœud et l'état d'avancement et de synchronisation est visible dans le fichier /proc/drbd. Quand la synchronisation est terminée, on demande à chaque nœud de passer maître sur la ressource, ce qui n'est pas souhaitable tant que la synchronisation n'est pas terminée.

3. Au tour du système de fichiers

3.1. Un FS clusterisé

Pour utiliser un périphérique de type bloc en lecture/écriture sur plusieurs nœuds, il faut naturellement un système de fichiers prenant en charge le multi-maître, ce que ne sont pas XFS et EXTn. De base, le noyau Linux prend en charge GFS de RedHat et OCFS2 d'Oracle. GFS2 gère les verrous entre les nœuds via DLM, CLVM et CMAN. Commençons par installer les pré-requis et corriger les bogues de packaging :

Une fois les dépendances installées, il faut créer le répertoire /var/run/lvm qui n'est pas créé à l'installation de clvm, puis modifier le fichier d'init /etc/init.d/clvm et modifier la ligne indiquant le chemin du binaire clvmd ainsi : DAEMON=/usr/sbin/clvmd.