DRBD réplique au niveau des périphériques de bloc, pour plus d’informations sur son fonctionnement, je vous renvoie à la page Wikipedia de DRBD.

Pré-requis

Ce tutoriel est réalisé avec deux machines sous CentOS 6, celles-ci sont respectivement nommées centos-ha1 (IP : 192.168.1.10) et centos-ha2 (IP : 192.168.1.11), le terme de nœud sera utilisé pour les désigner.
SELinux est désactivé et le port 7789 ouvert au niveau du firewall.

DRBD fonctionnant au niveau bloc, il faut un disque ou une partition dédiée à cela. Dans l’exemple de ce billet, on part d’un groupe de volumes LVM nommé vg_storage avec un unique volume logique lv_storage qui est libre pour créer notre ressource DRBD. Un volume logique étant un périphérique de bloc aux yeux de Linux, cela convient parfaitement. Celui-ci n’a pas besoin (et ne doit pas) d’être formatté.

Installation

Depuis CentOS 6, les paquets DRBD ne sont plus dans les dépots de base, il faut donc ajouter ceux de atRPMS. Pour ce faire, ajouter le fichier atrpms.repo sous /etc/yum.repos.d contenant ceci :

[atrpms]
name=CentOS $releasever - $basearch - ATrpms
baseurl=http://dl.atrpms.net/el$releasever-$basearch/atrpms/stable
gpgkey=http://atrpms.net/RPM-GPG-KEY.atrpms
gpgcheck=1

Vérification de la présence de paquets relatifs à DRBD :

# yum search drbd
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: ftp.plusline.de
* extras: ftp.plusline.de
* updates: mirrors.prometeus.net
========================================= Matched: drbd =========================================
drbd.i686 : Distributed Replicated Block Device.
drbd-kmdl-2.6.32-131.0.15.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.12.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.2.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.4.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-131.6.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.14.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.18.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.18.2.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.24.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.29.1.el6.centos.plus.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.29.1.el6.i686.i686 : Distributed Redundant Block Device.
drbd-kmdl-2.6.32-71.7.1.el6.i686.i686 : Distributed Redundant Block Device.

Nous pouvons installer le paquet drbd ainsi que le module du noyau correspondant au noyau en cours. Je vérifie quel noyau j’ai sur mon système :

# uname -r
2.6.32-71.29.1.el6.i686

J’installe le module correspondant :

# yum install drbd drbd-kmdl-2.6.32-71.29.1.el6.i686.i686

Il faut charger le nouveau module dans le noyau :

# modprobe drbd

Et bien sur on veut qu’il se charge au démarrage de la machine, on ajoute donc cette ligne au fichier /etc/rc.local.

Configuration

La configuration de DRBD se situe sous /etc/drbd.conf, mais pour plus de lisibilité, ce fichier fait appel à ceux situés sous /etc/drbd.d/, la configuration se fait donc d’une part dans global_common.conf pour la configuration commune et dans un fichier r0.res que nous allons créer pour notre nouvelle ressource. Ce nom r0 est arbitraire.
Donc pour commencer, vérifier que le fichier global_common.conf possède les options suivantes :

global {
  usage-count yes;
}
common {
  net {
    protocol C;
    verify-alg sha1;
    csums-alg sha1;
  }
}

L’option protocol C signifie que la réplication s’effectue de façon synchrone. Avec ce mode de fonctionnement synchrone, l’écriture de données n’est considérée terminée que lorsque le nœud secondaire a terminé d’écrire, validant ainsi l’opération. verify-alg sha1 vérifie l’intégrité des données bloc par bloc entre les nœuds. csums-alg sha1 active la synchronisation avec somme de contrôle (checksum). Comme expliqué dans la documentation, la synchronisation n’est pas la même chose que la réplication des périphériques. La seconde se fait en temps réel, c’est le fonctionnement normal de DRBD, alors que la première s’effectue lorsqu’il y a eu perte d’un des deux nœuds (pour quelque raison que ce soit) et une (re)synchronisation est nécessaire.

Il est temps de créer la vraie ressource dans un nouveau fichier r0.res contenant ces informations :

resource r0 {
	on mailsrv-ha1 {
    	address   192.168.1.10:7789;
    	device    /dev/drbd1;
		disk      /dev/mapper/vg_storage-lv_storage;
		meta-disk internal;
  	}
  	on mailsrv-ha2 {
    	address   192.168.1.11:7789;
    	device    /dev/drbd1;
		disk      /dev/mapper/vg_storage-lv_storage;
		meta-disk internal;
  	}
}

Petite explication sur la configuration de cette ressource qui dans son ensemble parle d’elle-même. On définit les deux nœuds avec le mot-clé on suivi du nom de l’hôte. On spécifie l’IP du nœud et le port utilisé – ici 7789. Le périphérique de bloc logique est définit par device suivi du chemin vers celui-ci. Ensuite il faut indiquer la partition de bas niveau sur laquelle le périphérique de bloc logique se posera grace au mot-clé disk suivi de son chemin. meta-disk internal indique que la zone réservée aux données de contrôle sera sur la même partition, toujours au niveau bloc (plus d’informations sur ce sujet sur la documentation officielle).

On voit que certaines options (presque toutes sauf l’IP) sont les mêmes, on peut donc simplifier notre fichier r0.res comme ceci :

resource r0 {
	device    /dev/drbd1;
    disk      /dev/mapper/vg_storage-lv_storage;
    meta-disk internal;
	on mailsrv-ha1 {
    	address   192.168.137.201:7789;
  	}
  	on mailsrv-ha2 {
    	address   192.168.137.203:7789;
  	}
}

Activation de la ressource

Voilà, tout est bien configuré, on peut activer la ressource. Je répète que le système de fichiers de bas niveau /dev/mapper/vg_storage-lv_storage doit être démonté et ne doit pas être formatté. Si tel est le cas, son contenu va de toutes façons être perdu.

On commence par créer les meta-données du périphérique :

# drbdadm create-md r0

Si des erreurs sont retournées, c’est que le système de fichiers existe, on le détruit donc :

# dd if=/dev/zero of=/dev/mapper/vg_storage-lv_storage bs=1M count=128

On relance la commande de création des meta-données. Tout devrait bien se passer, on peut activer la ressource :

# drbdadm up r0

Il faut faire de même sur l’autre nœud. Lorsque la deuxième machine est prête on initialise la première synchronisation par cette commande :

# drbdadm primary --force r0

Alors que se passe-t-il? Lorsque la ressource est activée, les deux nœuds sont marquées comme secondaires, une première synchronisation est nécessaire, on va donc forcer (avec l’option --force) cette opération sur le nœud que l’on veut primaire.

A ce stade, il est possible de vérifier l’état de DRBD par la commande :

# drbd-overview 
  1:r0/0  SyncSource Primary/Secondary UpToDate/Inconsistent C r----- 
	[>....................] sync'ed:  0.6% (53340/53652)M

On voit que la ressource est en cours de synchronisation, suivant la taille de la partition, cela peut être long. On a plus d’info avec :

# cat /proc/drbd 
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by gardner@, 2011-08-26 23:24:30
 
 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:1482108 nr:0 dw:0 dr:1487544 al:0 bm:90 lo:0 pe:2 ua:5 ap:0 ep:1 wo:b oos:53461324
	[>....................] sync'ed:  2.7% (52208/53652)M
	finish: 0:41:59 speed: 21,216 (22,100) K/sec

On voit que le processus de synchronisation est en cours (cs:SyncSource), que le nœud primaire est à jour mais le secondaire est encore dans un étant incohérent (ds:UpToDate/Inconsistent).
Il n’est pas nécessaire d’attendre la fin de la synchronisation pour créer le système de fichiers, donc allons-y, créons un système de fichiers ext4 et montons-le :

mkfs.ext4 -L storage /dev/drbd1
mkdir /mnt/storage
mount /dev/drbd1 /mnt/storage

Le système de fichiers est maintenant utilisable et va être répliqué en temps réel. On peut vérifier l’état de synchronisation :

# cat /proc/drbd 
version: 8.4.0 (api:1/proto:86-100)
GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by gardner@, 2011-08-26 23:24:30
 
 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:56499808 nr:36 dw:1557816 dr:54944894 al:422 bm:3354 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Voilà, c’est fini, notre resource est connectée (cs:Connected), on est sur le noeud primaire (ro:Primary/Secondary) et elle est à jour des deux cotés (ds:UpToDate/UpToDate). Avec drbd-overview on obtient plus d’informations, en particulier sur la taille du stockage :

# drbd-overview 
  1:r0/0  Connected Primary/Secondary UpToDate/UpToDate C r----- /mnt/storage ext4 52G 730M 49G 2%

Toute modification sur la ressource peut se faire en temps réel, après un changement, il faut copier le fichier de configuration sur le second nœud et opérer cette commande (sur les deux nœuds) :

# drbdadm adjust r0

Vérification en ligne automatique

Nous avons vu que l’option verify-alg permet de vérifier l’intégrité des données en ligne, pour faire ce test il suffit d’invoquer la commande :

# drbdadm verify r0

DRBD commence alors la vérification et s’il détecte des blocs non synchronisés, il les marque comme tel et l’inscrit dans le log du noyau. Il est bon d’automatiser cette tâche en l’ajoutant dans le cron. Pour ce faire, ajouter un fichier /etc/cron.d/drbd-verify avec – par exemple – ce contenu :

42 0 * * 0    root    /sbin/drbdadm verify r0

Par ailleurs, si des blocs non synchronisés ont été détectés, il faut les re-synchroniser comme ceci :

drbdadm disconnect r0
drbdadm connect r0

Restauration manuelle après un split-brain

Un split-brain se produit lorsque pour une raison quelconque les deux nœuds se retrouvent déconnectés, lorsque la connectivité revient, DRBD détecte que les 2 nœuds sont en mode primaire, DRBD rompt alors immédiatement la connexion de réplication par sécurité. Après le split-brain, un nœud passe en mode StandAlone et l’autre passe soit en mode secondaire ou en WFConnection. Il est temps d’intervenir.

Pour repartir sans corrompre les données – pour que le primaire sache qu’il est « maitre » – il faut aller sur le (futur) nœud secondaire et le déclarer comme tel, puis on connecte la ressource en lui disant d’oublier ses données :

drbdadm secondary r0
drbdadm connect --discard-my-data r0

On passe sur le primaire que l’on connecte et que l’on déclare primaire :

drbdadm connect r0
drbdadm primary r0

Notre ressource r0 est repartie.

Tester la réplication

Il est temps de tester un peu le fonctionnement de la réplication. Créons un fichier quelconque de 500Mo sous /mnt/storage :

# dd if=/dev/zero of=/mnt/storage/toto.dat bs=10M count=50
50+0 records in
50+0 records out
524288000 bytes (524 MB) copied, 31.4183 s, 16.7 MB/s
# ls -l /mnt/storage/
-rw-r--r--  1 root root 524288000 Sep 22 11:04 toto.dat

Celui-ci devrait maintenant exister également sur centos-ha2, pour le vérifier il faut suivre les étapes suivantes, sur le primaire : démonter le système de fichiers, le passer en secondaire, et sur le secondaire : le passer en primaire et monter le système de fichiers. Cela donne :

[centos-ha1 ~]# umount /mnt/storage
[centos-ha1 ~]# drbdadm secondary r0
 
[centos-ha2 ~]# drbdadm primary r0
[centos-ha2 ~]# mount /dev/drbd1 /mnt/storage
[centos-ha2 ~]# ls -l /mnt/storage
-rw-r--r--  1 root root 524288000 Sep 22 11:04 toto.dat

Tout est parfait, même si cela semble un peu long. Il ne faut pas oublier que le système de fichiers sur le nœud secondaire n’est pas accessible en l’état (il n’est d’ailleurs pas monté). Dans un environnement de production, la manipulation est un peu fastidieuse, c’est pourquoi il vaut mieux utiliser un CRM (Cluster Resource management) – comme Pacemaker – qui fera ce travail automatiquement. Ce sera l’objet d’un prochain article.

^.^

Ressources :

• The DRBD User’s Guide
• Wikipedia : DRBD
• CentOS 6
• Dépôt atRPMS

Je passe sur les détails du comment du pourquoi je m’en suis dépatouillé pour récupérer mes données (229Go de photos et de musique) sur du LVM réparti sur 2 disques avec un disque marqué inexistant. Mais j’ai réussi.
Edoras est d’une part un vieux coucou (Sempron 2400+ avec 1Go de RAM), mais reste très bien pour un petit serveur qui démarre en niveau 3, mais c’est aussi une usine à gaz qui comporte 5 disques : un disque système avec 2 partitions /boot et l’autre en LVM (swap, root et home), un VGdata de 380Go sur 2 disques et un VGraid qui comme son l’indique est un RAID1 sur deux disques SATA de 500Go. Non seulement, j’ai eu ce problème d’inconsistance du VGdata, mais j’avais un des disques du RAID déconnecté. Et ne me demandez pas pourquoi, ce deuxième disque avec un identifiant de partition de type Linux LVM (8e) et non pas Linux RAID auto (fd). Je l’ai donc ré-attribué l’id du système de fichiers comme étant fd. Et j’ai du ré-ajouter le disque au RAID pour le resynchroniser.

Ajout du disque à la pile raid md127 :

# mdadm --add /dev/md127 /dev/sde1
mdadm: added /dev/sde1

Voilà, la synchronisation doit commencer toute seule :

[edoras@edoras ~]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sde1[2] sdd1[0]
 488383936 blocks [2/1] [U_]
 [>....................] recovery = 2.7% (13261248/488383936) finish=137.9min speed=57399K/sec
 
unused devices: <none>

Plus qu’une bonne 130aine de minutes à attendre pour avoir ses données sécurisées de nouveau.

Avant :

$ df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/VG1-LVroot
9,9G  3,7G  5,7G  40% /
/dev/mapper/VG1-LVhome
26G  853M   23G   4% /home
/dev/sdc1             145G   83G   54G  61% /backup
/dev/sdb1             184G  111G   64G  64% /data1
/dev/sda1             236M   29M  195M  13% /boot
/dev/mapper/VGraid-LVraid
459G  216G  220G  50% /raid

D’une part, cela me faisait beaucoup de montages (NFS) sur mes Mac alors que je pouvais – théoriquement – rassembler /backup et /data1 en un seul volume, et d’autre part, je désirais passer en full LVM pour plus de flexibilité.

La limitation des systèmes de fichiers classiques m’imposait d’avoir ces deux partitions séparées, celles-ci étant sur deux disques différents. C’est là que LVM montre sa puissance : la possibilité de créer un groupe de volumes sur les deux disques, soit au final avoir une seule partition virtuelle de 360Go unique sur les deux disques.

Après :

$ df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/VG1-LVroot
9,9G  3,7G  5,7G  40% /
/dev/mapper/VG1-LVhome
26G  855M   23G   4% /home
/dev/mapper/VGdata-LVdata
331G  1,8G  312G   1% /mnt/data
/dev/sda1             236M   29M  195M  13% /boot
/dev/mapper/VGraid-LVraid
459G  275G  162G  63% /mnt/raid

Après avoir déplacé mes données sur un autre disque pour faire la modification, redéfini sdb1 et sdc1 en partition de type 8e (Linux LVM) dans fdisk, j’ai opéré comme suit pour ajouter un groupe de volumes VGdata contenant un unique volume logique LVdata de la totalité de l’espace disponible (je ne détaillerai pas, les étapes ayant été un peu mieux expliquées dans ce billet) :

# pvcreate /dev/sdb1
# pvcreate /dev/sdc1
# vgcreate -s 16M VGdata /dev/sdb1 /dev/sdc1
# lvcreate -l 21462 VGdata -n LVdata
# mkfs.ext3 /dev/VGdata/LVdata
# mkdir /mnt/data
# mount /dev/VGdata/LVdata /mnt/data

Ajout du montage dans fstab :

/dev/VGdata/LVdata	/mnt/data		ext3	defaults	1 2

Cet article parle du RAID logiciel, sur une machine en Fedora 10.

Mise en place d’un RAID 1 logiciel

Je dispose de deux disques SATA 500Go que je désire utiliser en RAID 1, celui-ci fonctionne avec 2 disques (ou plus). Il s’agit d’une simple copie des données d’un disque sur l’autre, de façon transparente. Après avoir installé ces deux disques, je vérifie qu’ils soient reconnus par le système :

$ ls -l /dev/sd*
brw-rw---- 1 root disk 8,  0 déc. 28 21:37 /dev/sda
brw-rw---- 1 root disk 8,  1 déc. 28 21:37 /dev/sda1
brw-rw---- 1 root disk 8,  2 déc. 28 21:37 /dev/sda2
brw-rw---- 1 root disk 8,  3 déc. 28 21:37 /dev/sda3
brw-rw---- 1 root disk 8, 16 déc. 28 21:37 /dev/sdb
brw-rw---- 1 root disk 8, 17 déc. 28 21:37 /dev/sdb1
brw-rw---- 1 root disk 8, 32 déc. 28 21:37 /dev/sdc
brw-rw---- 1 root disk 8, 33 déc. 28 21:37 /dev/sdc1
brw-rw---- 1 root disk 8, 48 déc. 28 21:37 /dev/sdd
brw-rw---- 1 root disk 8, 64 déc. 28 21:37 /dev/sde

Il faut maintenant créer une partition physique sur ces disques et placer l’identificateur de ces partitions comme étant de type Linux RAID, ceci avec fdisk :

# fdisk /dev/sdd
Puis taper ces commandes pour un disque neuf :
n
p
1
<entrée>
<entrée>
t
fd
w

Faire de même pour le deuxième disque. Au final un fdisk -l devrait donner quelque chose comme ça :

Disque /dev/sdd: 500.1 Go, 500107862016 octets
255 heads, 63 sectors/track, 60801 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000b9726
Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdd1               1       60801   488384001   fd  Linux raid autodetect
Disque /dev/sde: 500.1 Go, 500107862016 octets
255 heads, 63 sectors/track, 60801 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000b9726
Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sde1               1       60801   488384001   fd  Linux raid autodetect

Il est temps de combiner ces deux disques en une seule unité RAID 1, ceci par l’intermédiaire de la commande à tout faire mdadm :

# mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1

La syntaxe est assez explicite : création d’une pile RAID qui sera en md0, de niveau 1 utilisant les 2 disques préparés auparavent. Et voilà, le RAID 1 est crée! Petite vérification :

# mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Dec 28 21:24:39 2008
Raid Level : raid1
Array Size : 488383936 (465.76 GiB 500.11 GB)
Used Dev Size : 488383936 (465.76 GiB 500.11 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Dec 29 08:33:06 2008
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : d6b46a36:85a45c5f:5232c6b9:3d8a986e
Events : 0.8
Number   Major   Minor   RaidDevice State
0       8       49        0      active sync   /dev/sdd1
1       8       65        1      active sync   /dev/sde1

Si la ligne State rapporte bien clean, alors tout est en principe bon.

LVM sur le RAID

Le RAID fonctionne, il faut maintenant l’utiliser. Nous allons gérer md0 avec LVM, en commencant par créer un volume physique, ce qui va initilaiser md0 pour utiliser LVM :

# pvcreate /dev/md0

Ensuite, il faut créer le volume groupe, que j’appelle VGraid. La valeur par défaut du PE (Physical Extent) peut se révéler trop faible pour une grosse matrice RAID. Il est alors possible d’indiquer une taille de PE plus importante avec l’option -s. Leur nombre maximal est approximativement de 65000 et leur taille par défaut de 4Mo, partant delà, il faut prendre la taille du volume et de le diviser par 65000, puis de l’arrondir à l’entier significatif le plus grand le plus proche. Par exemple, pour un volume RAID de 500Go, grosso-modo 500000Mo cela donne : 500000 / 65000 = 7,69, soit 8Mo. Je vais le mettre à 32 pour être plus à l’aise.

# vgcreate -s 16M VGraid /dev/md0

Le VG est désormais crée, il faut maintenant le remplir avec un ou plusieurs volume(s) logique(s). Je vais en ajouter un seul – LVraid – qui prendra la taille du VG. Pour connaître cette taille en PE :

# vgdisplay VGraid
--- Volume group ---
VG Name               VGraid
System ID
Format                lvm2
Metadata Areas        1
Metadata Sequence No  2
VG Access             read/write
VG Status             resizable
MAX LV                0
Cur LV                1
Open LV               1
Max PV                0
Cur PV                1
Act PV                1
VG Size               465,75 GB
PE Size               32,00 MB
Total PE              14904
Alloc PE / Size       14904 / 465,75 GB
Free  PE / Size       0 / 0
VG UUID               D33fbC-w82v-I83g-TAgG-vZaA-8C52-1aVEfr

Et pour le créer :

# lvcreate -l 14904 VGraid -n LVraid

Ceci fait, /dev/VGraid/LVraid (également mappé sous /dev/mapper/VGraid-LVraid) peut être utilisé comme une partition « normale », donc on formate et on monte normalement :

# mkfs.ext3 /dev/VGraid/LVraid
# mkdir /mnt/raid
# mount /dev/VGraid/LVraid /mnt/raid

Notre filesystem est prêt à l’emploi et les données présentes dessus seront mirrorées. Pour connaître l’état de la pile RAID :

# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdd1[0] sde1[1]
488383936 blocks [2/2] [UU]
unused devices: <none>

On voit qu’il est actif. [UU] désigne que les deux disques sont OK. En cas de problème sur un disque, cette info ressemblerait à [_U] ou [U_] suivant le disque défaillant.
Il est également possible de surveiller sa matrice et d’être avertit par email en cas de panne par cette commande :

# mdadm --monitor --mail=root@localhost --delay=1800 /dev/md0 &

A noter que --monitor peut même aller plus loin et lancer un programme ou un script au lieu d’un simple email.