Différences entre versions de « DRBD »
imported>SylvainBeucler |
imported>SylvainBeucler |
||
Ligne 16 : | Ligne 16 : | ||
protocol C; | protocol C; | ||
syncer { rate 40M; } | syncer { rate 40M; } | ||
+ | disk { on-io-error: detach; } | ||
startup { | startup { | ||
wfc-timeout 15; | wfc-timeout 15; |
Version du 31 octobre 2009 à 12:42
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]; } }
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
.