DRBD

Distributed Replicated Block Device

apt-get install drbd8-utils drbd8-modules-2.6-686
# ou variante:
apt-get install drbd8-utils drbd8-modules-2.6-vserver-686

Configuration simple

Primary/Secondary (il existe aussi Primary/Primary):

global { 
  usage-count yes;
}
common {
  protocol C;
  syncer { rate 40M; }
  disk { on-io-error detach; }
  startup {
    wfc-timeout 15;
    degr-wfc-timeout 15;
    #outdated-wfc-timeout 15; # not in DRBD 8.0/Lenny
  }
}
resource r0 {
  startup { become-primary-on VM1; }
  on VM1 {
    device    /dev/drbd0;
    disk      /dev/VG0/test;
    address   192.168.101.115:7789;
    meta-disk /dev/VG0/test-drbdmeta[0];
  }
  on VM2 {
    device    /dev/drbd0;
    disk      /dev/VG0/test;
    address   192.168.101.118:7789;
    meta-disk /dev/VG0/test-drbdmeta[0];
  }
}

Méta-données

Si vous utilisez des méta-données externes, vous aurez calculé que le volume dédié n'a pas besoin d'être bien grand.

Cependant, il faut noter que le volume doit être au minimum to 128Mo très précisément, même pour le plus petit volume DRBD.

DRBD par dessus LVM

Snapshots LVM d'un volume DRBD:

• http://thread.gmane.org/gmane.comp.linux.drbd/6175 : en 2004
• http://www.mail-archive.com/drbd-user@lists.linbit.com/msg00277.html : en 2009

Ce que je comprend:

• léger risque d'incohérence du snapshot
• pas de risque d'incohérence des données maîtres

En pratique, pour avoir un backup cohérent à partir du noeud secondaire:

lvcreate -s VG0/test -n test-snapshot -L 5G
mount /dev/VG0/test-snapshot -o ro /mnt/snapshots/test  # ro par parano
# backup avec rsync...
umount /mnt/snapshots/test
lvremove VG0/test-snapshot

Recharger la configuration

Utiliser:

drbdadm adjust r0

Attention: comme indiqué ici, s'il y a un changement dans une section disk, les versions < 8.3.1 lancent une resynchronization complète. Pour éviter cela, passer le primaire en secondaire (donc les deux noeuds en secondaire) avant de lancer adjust; cela implique de démonter toutes les volumes DRBD actifs.

Simuler des erreurs d'entrées/sorties

Cf. http://lists.linbit.com/pipermail/drbd-dev/2009-July/001073.html

+	  The actual simulation of IO errors is done by writing 3 values to
+	  /sys/module/drbd/parameters/
+
+	  enable_faults: bitmask of...
+	  1	meta data write
+	  2               read
+	  4	resync data write
+	  8	            read
+	  16	data write
+	  32	data read
+	  64	read ahead
+	  128	kmalloc of bitmap
+	  256	allocation of EE (epoch_entries)
+
+	  fault_devs: bitmask of minor numbers
+	  fault_rate: frequency in percent
+
+	  Example: Simulate data write errors on /dev/drbd0 with a probability of 5%.
+		echo 16 > /sys/module/drbd/parameters/enable_faults
+		echo 1 > /sys/module/drbd/parameters/fault_devs
+		echo 5 > /sys/module/drbd/parameters/fault_rate

L'exemple occasionne une erreur disque au bout de quelques accès disque.

drbd0: Notified peer that my disk is broken

Gérer des erreurs d'entrées/sorties

Cas 1 (configuration par défaut, mais n'est plus recommandée):

disk { on-io-error pass_on; }

Dans ce cas, les erreurs sont passées au système de fichiers, qui habituellement va se remonter en lecture seule. D'après mes tests, cependant, même avec -o errors=remount-ro, le système de fichiers s'est corrompu avec moult messages de drbd0 mais sans que le système de fichiers ne passe en lecture seule.

Cas 2:

disk { on-io-error detach; }

Dans ce cas le disque continue de fonctionner de manière transparente sur le secondaire, en passant par le réseau (mode "diskless").

Cas 3:

disk { on-io-error call-local-io-error; }

Dans ce cas DRBD appelle un script spécifié via local-io-error.

Montage au démarrage

• Dans /etc/fstab faire attention:
  • de bien faire référence au volume DRBD (pas au volume physique)
  • de ne pas demander un fsck (mettre les deux derniers champs à 0) car drbd n'est pas activé au moment où fstab est utilisé, ce qui va causerait une erreur
• Dans l'ordre de démarrage, positionner les services dépendant de DRBD (ex: vserver) après lui
• Rajouter un script au démarrage pour finir de monter les volumes DRBD, par exemple:

cat <<'EOF' > /etc/init.d/drbdmount
#!/bin/bash
if [ "$1" = "start" ]; then mount -a; fi
EOF
chmod 755 /etc/init.d/drbdmount
update-rc.d -f vprocunhide remove
update-rc.d -f vservers-default remove
# Put it after the 'drbd' init script
update-rc.d drbdmount defaults 75
update-rc.d vprocunhide defaults 80
update-rc.d vservers-default defaults 80

Supervision

La supervision semble n'être prévue que par le biais de Heartbeat/Pacemaker. Quelques événements peuvent être notifiés par l'intermédiaires des handlers, mais pas tous.

La commande drbdsetup /dev/drbd0 events permet de récupérer de manière succinte tous les événements qui se produisent. On peut l'utiliser de manière très rudimentaire dans le script suivant qui tournera en tâche de fond:

#!/bin/bash
for drbdX in /dev/drbd*; do
    (drbdsetup $drbdX events | while read line; do echo $line | mail -s "$(hostname) $drbdX" you@domain.tld; done)&
    sleep 1
done

Faire un killall drbdsetup pour l'arrêter.

Redimensionnement

Voici ci-dessous une procédure de redimensionnement en ligne d'une partition ext3 sur drbd sur LVM ayant des métadonnées drbd externes (c'est à dire sur une autre partition). D'autres cas de figures sont évoqués par la documentation officielle dont est tirée cette procédure: http://www.drbd.org/users-guide/s-resizing.html

- vérifier que la ressources est dans l'état connecté (par la commande « cat /proc/drbd », drbd-overview (pour les versions >= 8.015 et 8.3) ou encore « drbdadm cstate <ressource> »). Consulter /etc/drbd.conf pour connaitre le nom de la ressource concernée.

drbdadmin cstate r1

- agrandir la partition sous-jacente sur les deux noeuds (par une même taille)

lvresize -L +10G VGO/part1

- lancer la commande: « drbdadm resize <ressource> » sur le primaire « Cela déclenche une synchronisation de la nouvelle section. La synchronisation est effectuée du noeud primaire vers le noeud secondaire. »

drbdadm resize r1

- « cat /proc/drbd » indique la progression de l'opération:

cat /proc/drbd
(...)
1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
   ns:782562016 nr:0 dw:781184840 dr:390009247 al:7093764 bm:4170 lo:0 pe:20 ua:1 ap:0
   [>...................] sync'ed:  7.2% (9511/10240)M
   finish: 0:22:14 speed: 7,224 (5,964) K/sec
   resync: used:0/61 hits:46590 misses:46 starving:0 dirty:0 changed:46
   act_log: used:0/127 hits:188202446 misses:7423822 starving:4595 dirty:328181 changed:7093764
(...)

- une fois l'opération précédente terminée (c'est peut-être possible avant, mais je ne m'y suis pas risqué), changer la taille du système de fichier avec la commande suivante (où /dev/drbd1 est la partition drbd correspondant à votre ressource):

resize2fs /dev/drbd1

C'est normalement possible à chaud (c'est à dire sans démonter la partition), si votre système de fichiers n'a pas besoin d'être vérifié, sinon il faudra auparavant le démonter et lancer la commande e2fsck -C0 -f /dev/drbd1.

- le redimensionnement est terminé.

Agrandir drbd lorsque le disque physique est trop petit

De prime abord, ça n'est pas possible, il faut forcement que les disques physique permettent le redimensionnement. Cependant, le système drbd se base sur 2 serveurs, il est donc possible de couper la connexion entre les 2 serveurs initiaux (trops petits), de la restaurer avec un 3eme serveur plus grand, (il n'y a donc plus qu'un serveur trop petit), puis, on refait la même opération, on coupe la connexion et on la recrée entre le 3ème et un 4ème serveur. Une fois qu'on se retrouve avec 2 serveurs suffisament grand, on peut appliquer le redimensionnement comme décrit dans le chapitre précedent.

Cas concret: drbd sur 2 serveurs:, le premier a encore de la place, le deuxième est plein. On part de l'hypothèse que le premier serveur est "primary", et est monté. Le changement de serveur de duplication va se faire sans interuption de service.

Première chose, si c'est la première fois que vous manipulez drbd dans ce type de contexte, faites une maquette, ou mieux ayez un drbd de test qui vous permettra de simuler les différentes étapes.

Préparation

• On prépare la configuration drbd sur le serveur 1 (pour le moment elle

reste en commentaire)

• On prépare le 3ème serveur, installation de drbd, création des partitions

LVM, préparation de la configuration drbd (notamment drbdadm create-md <resource>).

• On vérifie que la configuration est juste (les IPs, les ports, les nom de

machine, les devices drbd les devices lvm sur lesquels repose drbd).

• sur le 3ème serveur on commence la mise en marche de drbd:

drbdadm attach <resource>
drbdadm syncer <resource>

• on vérifie que le 3ème serveur est bien en "secondary / inconsistant" (cat /proc/drbd)

Modifications

• sur le premier serveur, on fait un

"drbdadm disconnect <resource>"

• toujours sur le premier serveur on décommente la nouvelle configuration et

on commente l'ancienne (celle qui pointait sur le serveur2). On vérifie que la configuration est consistante:

"drbdadm -d adjust <resource>"

• on vérifie que le premier serveur est bien "primary / uptodate"
• on lance la commande

"drbdadm connect" de chaque côté.

Le premier et le deuxième serveur doivent maintenant se synchroniser (le premier est recopié sur le troisième ce qui va prendre un certain temps).

• pendant ce temps là on peut faire du ménage sur le serveur 2: "drbdadm down <resource>" puis commenter les lignes

de la configuration drbd conrespondante (en cas de redemarrage du serveur 2, le "mauvais" drbd va réessayer de se connecter au serveur 1. Même s'il y a des protections pour ce genre de cas, on évite de tenter le diable).

S'il faut inverser primaire et secondaire, il faut d'abord passer le primaire en secondaire, (donc on a 2 secondaires), puis passer le secondaire en primaire.

Passer un primaire en secondaire referme le "couvercle" c'est à dire que le volume drbd "secondary" n'est plus lisible, ni en lecture ni en écriture. Il faut donc le démonter avant de le passer en "secondary".

Liens

• The DRBD User's Guide
• LVM