Remplacement d'un lecteur défaillant dans une baie mdadm sur Ubuntu

Les informations contenues dans cet article sont basées sur Ubuntu 18.04 et la version de mdadm incluse dans ses dépôts ; au moment de la rédaction, il s’agissait de la version v4.1-rc1. Elles peuvent ne pas être valides pour d’autres versions.

J'ai récemment subi une panne soudaine d'un disque dur sur mon serveur de fichiers domestique, composé de neuf disques en RAID-6 (configuration mdadm). C'est toujours inquiétant, mais heureusement, j'ai pu rapidement me procurer un disque de remplacement qui a été livré dès le lendemain, ce qui m'a permis de commencer la reconstruction.

J'avoue avoir été un peu radin lors de la configuration initiale du serveur de fichiers ; seuls deux disques sont de véritables disques NAS (Seagate IronWolf), les autres étant des disques durs de bureau (Seagate Barracuda). Sans surprise, c'est l'un de ces derniers qui a rendu l'âme (après presque trois ans de bons et loyaux services). Il était complètement hors service ; même après l'avoir branché dans un boîtier USB externe, il n'émettait plus qu'un cliquetis inquiétant et ni Ubuntu 20.04 ni Windows 10 ne parvenaient à le détecter.

Bon, passons à la pièce de rechange (et oui, le nouveau disque que j'ai acheté était un IronWolf, j'ai retenu la leçon). Perdre un disque dans une grappe RAID en fonctionnement est déjà angoissant, mais c'est encore pire quand on ne connaît pas la procédure de remplacement. Ce n'est pas la première fois que je dois remplacer un disque défaillant dans une grappe mdadm, mais heureusement, c'est tellement rare que je dois généralement consulter la documentation. Cette fois-ci, j'ai décidé de rédiger mon propre petit guide pour m'y référer ultérieurement.

Tout d'abord, lorsque vous recevez le fameux e-mail d'erreur de mdadm, vous devez identifier le disque défaillant. Certes, il vous indiquera le nom du périphérique (dans mon cas, /dev/sdf), mais il est souvent difficile de savoir de quel disque physique il s'agit, car ces noms peuvent changer au redémarrage de la machine.

Si vous n'êtes même pas sûr du nom du périphérique défaillant, vous pouvez utiliser la commande suivante pour le découvrir (remplacez /dev/md0 par votre périphérique RAID) :

Comme mentionné, dans mon cas il s'agissait de /dev/sdf, alors continuons avec cela.

Vous pouvez ensuite essayer de trouver le numéro de série du disque défaillant en exécutant la commande suivante :

(Si smartctl est introuvable, vous devez installer le paquet smartmontools sur Ubuntu.)

Le numéro de série peut ensuite être comparé aux numéros de série figurant sur l'étiquette physique des disques pour déterminer lequel est défectueux.

Cette fois-ci, je n'ai pas eu cette chance. Le disque était complètement HS et refusait même de fournir des données SMART ou autres, y compris le numéro de série.

Comme j'avais un accès physique au serveur (indispensable pour remplacer soi-même un disque dur, je suppose ;-)) et que le serveur était en marche au moment de la panne (et continuait de fonctionner correctement grâce à la redondance RAID-6), j'ai opté pour la méthode rudimentaire, mais étonnamment efficace et évidente : copier un fichier volumineux sur le serveur et observer quel voyant du disque dur restait allumé. En quelques secondes, j'avais identifié le coupable.

Avant de retirer physiquement le disque dur, il est conseillé d'informer formellement mdadm de cette intention en exécutant la commande suivante (remplacez les noms de périphériques par les vôtres, le cas échéant) :

En cas de succès, mdadm répondra par un message indiquant qu'il a « retiré à chaud » le disque, apparemment parce que le périphérique RAID virtuel est effectivement en cours d'exécution à ce moment-là.

Si l'opération échoue avec un message d'erreur similaire à « périphérique ou ressource occupé(e) », il se peut que mdadm n'ait pas encore enregistré la panne complète du disque. Pour y remédier, exécutez la commande suivante (n'oubliez pas de remplacer les noms de périphériques par les vôtres le cas échéant) :

Vous devriez ensuite pouvoir retirer le périphérique du réseau à l'aide de la commande précédente.

Il est temps maintenant de remplacer le disque dur. Si vous êtes absolument certain que votre machine et son contrôleur prennent en charge le remplacement à chaud, vous pouvez effectuer l'opération sans éteindre la machine. C'est la méthode à privilégier pour les systèmes de production critiques fonctionnant sur du matériel serveur dédié et fiable, capable de supporter cette opération. Mon serveur de fichiers personnel, quant à lui, est basé sur une carte mère de bureau grand public équipée de deux contrôleurs SATA de marque inconnue installés dans les ports PCIe afin d'augmenter le nombre de ports SATA disponibles.

Bien que le SATA soit généralement censé prendre en charge le remplacement à chaud, je ne voulais prendre aucun risque dans cette configuration, j'ai donc opté pour l'arrêt de la machine pendant le remplacement du disque.

Avant cela, il est conseillé de commenter la ligne relative au périphérique RAID dans le fichier /etc/fstab afin qu'Ubuntu ne tente pas de le monter automatiquement au prochain démarrage. En effet, cela pourrait entraîner un blocage et vous forcer à démarrer en mode de récupération en raison de la dégradation de la grappe RAID. Ce ne serait pas un problème majeur pour un ordinateur de bureau, mais comme mon serveur fonctionne sans écran ni clavier, cela serait plutôt contraignant.

Après avoir démarré la machine avec le nouveau disque dur installé, utilisez la commande `lsblk` ou un autre outil similaire pour l'identifier. Si vous n'avez rien modifié d'autre, il portera probablement (mais pas forcément) le même nom que le disque remplacé. Dans mon cas, c'était le cas : le nouveau disque s'appelle donc également `/dev/sdf`.

Comme mon système de stockage est basé sur des partitions et non sur des périphériques physiques, j'ai dû copier la table de partitions d'un disque fonctionnel vers le nouveau disque afin de garantir leur parfaite correspondance. Si votre système de stockage utilise des périphériques physiques, vous pouvez ignorer cette étape.

J'ai utilisé sgdisk pour cela, en copiant la table de partitions de /dev/sdc vers /dev/sdf. Veillez à remplacer les noms de périphériques par les vôtres, le cas échéant.

Notez l'ordre : vous devez indiquer le disque « to » en premier ! C'est un peu contre-intuitif pour moi, mais assurez-vous de bien le faire pour éviter une autre panne de disque dans la grappe ;-)

Ensuite, pour éviter les conflits d'UUID, générez de nouveaux UUID pour le nouveau lecteur :

Et voilà, le moment est enfin venu d'ajouter le nouveau disque à la grappe et de lancer la reconstruction ! (Bon, ce n'est pas vraiment une fête, c'est plutôt un processus long et stressant, car on ne veut surtout pas qu'un autre disque tombe en panne à ce moment-là. Une bière pourrait peut-être aider.)

Pour ajouter le nouveau disque à la grappe, exécutez la commande suivante (en remplaçant les noms de périphériques par les vôtres, le cas échéant) :

Si tout se passe bien, le disque sera ajouté à la grappe sans problème. Il est ajouté par défaut comme disque de secours, mais comme cette grappe est incomplète (il manque un disque, celui qui a défailli), il est immédiatement mis en service et le processus de reconstruction démarre.

Vous pouvez le surveiller comme ceci :

Cela prendra probablement un certain temps ; sur mon serveur modeste (composé principalement de matériel grand public et de disques durs de bureau, je le précise), j'ai atteint un peu moins de 100 Mo/s. Il faut savoir qu'il s'agit d'un RAID 6, ce qui implique de nombreux calculs de parité lors de la reconstruction ; un RAID 10 aurait été bien plus rapide. Cette machine est équipée d'un processeur quadricœur AMD A10 9700E (le « E » indiquant qu'il s'agit d'un modèle basse consommation sous-cadencé, donc pas très performant), pour vous donner une idée des performances à prévoir. Avec mes neuf disques de 8 To, la reconstruction complète a pris un peu plus de 24 heures.

Pendant la reconstruction, vous pouvez monter le système de fichiers sur la grappe et l'utiliser normalement si vous le souhaitez, mais je préfère laisser la reconstruction se terminer. N'oubliez pas que si un disque tombe en panne, un autre risque de suivre rapidement. Il est donc important que la reconstruction soit aussi rapide que possible pour éviter qu'un autre disque ne tombe en panne pendant ce temps. Par conséquent, ne la surchargez pas avec des opérations d'E/S non essentielles.

Une fois l'opération terminée, ajoutez-le à nouveau à votre fichier /etc/fstab, redémarrez et profitez de vos fichiers :-)