Une grappe RAID 5 tolère la panne d'un seul support de stockage (oui, même si tu as 6 disques, tu n'a pas une tolérance de 3 disques, mais toujours d'un seul disque). Que se passe-t-il si deux disques d'une même grappe foirent quasiment en même temps et s'il n'y a pas de disques de spare que mdadm peut automatiquement utiliser (ou que le rebuild n'a pas eu le temps d'être mené à terme) ?
Je n'ai pas de matériel physique en quantité suffisante pour tester donc j'ai utilisé des machines virtuelles.
Avec VirtualBox, il n'est pas possible d'installer un Debian Stable sur un RAID5 : VirtualBox freeze totalement durant l'installation, à des moments aléatoires : une fois pendant « décompression de wget » durant l'installation de base, une fois pendant la « préparation de Linux », une fois pendant… Il faut killer VirtualBox. De plus, VirtualBox ne sait retirer un périphérique de stockage à chaud.
Avec qemu-kvm + libvirt + virt-manager, l'installation d'un système Deiban Stable se passe bien.
Le problème, c'est que ni virt-manager, ni virsh ne semblent permettre de retirer à chaud un disque dur… Exemple avec virsh (sudo
pour qu'il identifie les VM) : sudo virsh detach-disk <nom_vm> <nom_disque> --persistent
(source), ça ne fonctionne pas : « error: Operation not supported: This type of disk cannot be hot unplugged ». Note : pour trouver le nom du disque, il faut lire le fichier xml de définition de la VM avec virsh dumpxml <nom_vm>
ou less /etc/libvirt/qemu/<nom_vm>.xml
et y trouver quelque chose de la forme : <target dev='sdc'
(ici le nom à utiliser est sdc
).
On se dit qu'on va utiliser le moniteur qemu. Sauf qu'en utilisant virt-manager (et la libvirt), il n'est apparemment pas rendu disponible sur une socket (UNIX ou réseau) : un ps aux | grep qemu
ne met pas en évidence un « -monitor unix:[…] ». Solution : passer par virsh
(source). Exemple : sudo virsh qemu-monitor-command --hmp <nom_vm> 'info block'
pour afficher les périphériques de type block de la VM. On supprime un disque : sudo virsh qemu-monitor-command --hmp <nom_vm> 'drive_del <nom_support>'
(un nom de disque, ça peut être « drive-sata0-0-3 », trouvable avec « info block »). L'information que le disque a été retiré n'est pas remontée au noyau Linux de la VM donc mdadm ne peut prendre aucune mesure alors qu'on voit bien, sur l'hôte, que la date de dernière modification du qcow correspondant au disque retiré ne change pas contrairement aux 3 autres qcow (car on écrit sur la grappe ;) )… Encore plus surprenant, au reboot hard (depuis l'hyperviseur), mdadm ne rebuild pas ce disque, comme si tout c'était toujours bien passé. Et il ne semble pas y avoir d'incohérence des données. :O
Je cherche sur le web, je cherche… et je finis par trouver : le sata hotplug avec KVM est uniquement possible si l'on utilise virtio. Logique. Je change cela dans virt-manager pour chacun de mes disques virtuels. je démarre la VM, je lance un sudo virsh detach-disk <nom_vm> <nom_disque>
. Et, cette fois-ci : « Disk detached successfully ». À la prochaine lecture ou écriture sur la grappe, mdadm virera le disque. \o/
Notons qu'on aurait aussi pu utiliser le trick suivant dans la VM : echo 1 > /sys/block/<disque>/device/delete
. Le résultat est strictement identique à l'arrachage sauvage d'un disque virtio.
Enlevons un deuxième disque. Que se passe-t-il ? À la première lecture ou écriture, / passe en lecture seule. Normal, il y a l'option errors=remount-ro
dans le fstab. Ma partition de test située sur un autre volume logique LVM sur la même grappe RAID, /mnt, est aussi passée en lecture seule à la première écriture que j'ai tentée. Pourtant, dans fstab, elle a uniquement l'option defaults
, qui, d'après le man, n'inclus pas errors=remount-ro
. Même avec l'option errors=continue
, après 2-3 tentatives d'écriture, le système de fichiers est automatiquement remonté en lecture seule. À partir d'ici, il y a donc des bouts de fichiers qui sont perdus, donc des exécutables qui ne peuvent plus être lancés : « Erreur d'entrée/sortie », « Error while loading shared librarie. ». D'autres fonctionnent parfaitement puisque leur contenu est en RAM puisque je les ai utilisés avant d'arracher les disques. Bref, on a de la perte de données avérée. C'est parfaitement cohérent avec les spécifications du RAID 5.
Comme nos disques ne sont pas morts (et n'ont pas de secteurs défectueux ou autre), mais qu'ils ont juste été arrachés, on est dans un cas de figure spécial où l'on peut reconstruire la grappe. Au reboot, mdadm nous informe qu'il n'a pu assembler la grappe car il a marqué deux disques comme étant défectueux. On tombe donc dans l'initramfs. On lance : mdadm -A --scan --force
. Cela a pour objet d'assembler la grappe RAID en réintégrant le dernier disque sorti qui est parfaitement fonctionnel et à jour puisqu'après son retrait, les systèmes de fichiers sont passés en lecture seule. Ensuite, on réintègre le premier disque dur arraché : mdadm --manage /dev/md0 --add /dev/vdd2
(pense à adapter le nom du disque). Forcément, mdadm lance un rebuild : ce disque dur-là n'est plus à jour, il y a eu des écritures depuis son retrait. Il peut aussi être nécessaire de faire un fsck manuel… Je note que errors=continue
est moins sûr que errors=remount-ro
, car il a conduit à la perte du fichier que j'ai essayé d'écrire avant que le système passe en lecture seule.
On peut se demander ce qu'il se passerait si l'on ajoutait une couche de DRBD entre le RAID logiciel et le système de fichiers. J'ai aussi testé ça avec une simple partition mutualisée (point de virtualisation ou autres services compliqués). Si la panne RAID arrive sur le secondaire DRBD, DRBD passe en « UpToDate/Diskless » et l'oos s'accumule. Le primaire DRBD peut toujours écrire et continuer sa vie. Et si jamais la grappe RAID est réparée, alors le DRBD secondaire rattrape son retard. Il n'y a donc pas de perte de fichiers. Si la panne RAID arrive sur le primaire DRBD, DRBD passe en « Diskless/UpToDate ». Il est encore possible d'écrire sur le DRBD : toute l'écriture se fait en réseau. Sur le secondaire DRBD, on voit l'oos augmenter alors qu'il reste à 0 sur le primaire DRBD en panne. Si jamais la grappe RAID est réparée, alors le DRBD primaire rattrape son retard lors d'une synchronisation initiale, avant qu'il faille le nommer primaire et que la réplication se remette en marche. Aucune perte de données à déplorer dans ce cas-là non plus.