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

Les informations contenues dans ce billet sont basées sur Ubuntu 18.04 et la version de mdadm incluse dans ses dépôts; au moment de la rédaction des v4.1-rc1. Cela peut être valide ou non pour d’autres versions.

J’ai récemment eu une défaillance soudaine de disque dans mon serveur de fichiers domestique, qui comprend neuf disques dans un tableau mdadm RAID-6. C’est toujours effrayant, mais j’ai eu la chance de trouver rapidement un disque de remplacement qui a déjà été livré le lendemain pour pouvoir commencer la reconstruction.

J’avoue que j’étais un peu trop radin quand j’ai configuré le serveur de fichiers au départ; seulement deux des disques sont de véritables disques NAS (Seagate IronWolf), tandis que les autres sont des disques de bureau (Seagate Barracuda). Sans surprise, c’était l’un des disques de bureau qui avait abandonné (après presque trois ans de service, cependant). Il était complètement mort; Après l’avoir déplacé dans un boîtier USB de bureau, tout ce que j’en ai eu, c’est un bruit de clic inquiétant et ni Ubuntu 20.04 ni Windows 10 n’ont pu le détecter.

Bon, passons à la pièce de rechange (et oui, le nouveau disque que j’ai acheté était un IronWolf, leçon apprise) – aussi effrayant que ce soit de perdre un disque dans un réseau en marche, c’est encore plus effrayant si tu ne connais pas la bonne procédure pour le remplacer. Ce n’est pas la première fois que je dois remplacer un disque défectueux dans un tableau MDADM, mais heureusement c’est tellement rare que je dois généralement chercher les bonnes commandes. Cette fois, j’ai décidé de créer mon propre petit guide pour référence future.

Donc, tout d’abord, quand vous recevez le fameux courriel d’échec de MDADM, vous devez identifier quel disque a échoué. Bien sûr, il vous dira le nom de l’appareil (dans mon cas /dev/sdf), mais il n’est probablement pas évident de quel disque physique il s’agit, car ces noms peuvent changer au démarrage de la machine.

Si vous n’êtes même pas certain du nom de l’appareil qui a échoué, vous pouvez utiliser la commande suivante pour le découvrir (remplacer /dev/md0 par votre périphérique RAID) :

Comme mentionné, dans mon cas c’était /dev/sdf, alors continuons avec ça.

Ensuite, vous pouvez essayer de trouver le numéro de série du disque défectueux en envoyant cette commande :

(si smartctl n’est pas trouvé, vous devez installer le paquet smartmontools sur Ubuntu)

Le numéro de série peut ensuite être comparé à celui sur l’étiquette physique des disques pour déterminer lequel a échoué.

Cette fois, je n’ai pas eu cette chance, cependant. Le disque était complètement mort 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 (ce dont on a vraiment besoin si on veut remplacer soi-même un disque physique, je suppose;-)) et que le serveur fonctionnait bien quand le disque a lâché (et continuait de fonctionner bien grâce à la redondance RAID-6), j’ai opté pour la méthode vraiment primitive, mais en fait très efficace et évidente, qui consiste simplement à copier un gros fichier sur le serveur et à regarder quel voyant du disque dur ne clignotait pas. En quelques secondes, j’avais identifié le coupable.

Avant de retirer le disque physique, il est judicieux d’informer formellement le MDADM de cette intention, en donnant cette commande (remplacez les noms des appareils par les vôtres selon le cas) :

En cas de succès, MDADM répond avec un message disant qu’il a « retiré le disque à chaud », apparemment parce que le périphérique RAID virtuel fonctionne en fait à ce moment-là.

Si un message d’erreur semblable à « appareil ou ressource occupé » échoue, il se peut que MDADM n’ait en fait pas enregistré le disque comme complètement défaillant. Pour que cela fonctionne, lancez cette commande (encore une fois, n’oubliez pas de remplacer les noms des appareils par les vôtres selon le cas) :

Après ça, tu devrais pouvoir retirer l’appareil de la matrice avec la commande précédente.

Maintenant, il est temps de remplacer réellement le disque. Si tu es vraiment, vraiment - vraiment - vraiment certain que ta machine et ton contrôleur supportent le hot swapping, tu pourrais faire ça sans éteindre la machine. Ce serait la bonne façon de faire sur des systèmes de production critiques fonctionnant sur du matériel serveur vrai et approprié dont vous savez pertinemment pouvoir gérer. Mon serveur de fichiers domestique est basé sur une carte mère de bureau grand public avec quelques contrôleurs SATA semi-sans nom dans les emplacements PCIe pour offrir plus de ports SATA.

Bien que SATA devrait généralement supporter le remplacement à chaud, je n’étais pas prêt à prendre de risques dans cette configuration, alors j’ai choisi d’éteindre la machine tout en remplaçant le disque.

Avant cela, c’est une bonne idée de commenter le périphérique RAID dans le fichier /etc/fstab pour qu’Ubuntu n’essaie pas de le monter automatiquement au prochain démarrage, car il pourrait se bloquer et vous forcer à passer en mode récupération à cause de la dégradation de l’array RAID. Ce n’est peut-être pas un gros problème si c’est un système de bureau, mais je fais tourner ce serveur sans interface sans moniteur ni clavier, donc ce serait un peu compliqué.

Après avoir démarré la machine avec le nouveau lecteur brillant installé, utilisez LSBLK ou un autre moyen pour l’identifier. Si tu n’as rien changé d’autre, il aura probablement (mais pas nécessairement) le même nom que le disque que tu as remplacé. Dans mon cas, oui, donc le nouveau s’appelle aussi /dev/sdf.

Comme mon tableau est basé sur des partitions plutôt que sur des périphériques physiques, j’ai dû copier la table de partitions d’un disque fonctionnel vers le nouveau disque pour m’assurer qu’ils sont exactement identiques. Si vous exécutez votre réseau sur des appareils physiques à la place, vous pouvez sauter cette étape.

J’ai utilisé sgdisk à cette fin, en copiant la table de partitions de /dev/sdc vers /dev/sdf. Assurez-vous de remplacer les noms des appareils pour qu’ils correspondent au vôtre, selon les besoins.

Remarquez l’ordre ici : vous indiquez d’abord le « vers »! C’est un peu contre-intuitif pour moi, mais assure-toi juste de bien faire les choses pour éviter une autre panne de disque dans l’array;-)

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

Et maintenant, enfin, le moment est venu d’ajouter le nouveau moteur à l’array et de lancer l’équipe de reconstruction! (Bon, ce n’est pas vraiment une fête, c’est en fait un processus assez lent et déstabilisant parce que tu ne veux vraiment, vraiment pas qu’un autre disque lâche en ce moment. La bière pourrait aider, par contre)

Bref, pour ajouter le nouveau disque à l’ensemble, lancez cette commande (encore une fois, assurez-vous de remplacer les noms des appareils par les viens selon le cas) :

Si tout se passe bien, le disque sera ajouté à l’array sans accroc. Je crois qu’il est en fait ajouté comme « hot spare » par défaut, mais comme ce tableau manque d’un disque (celui qui a lâché), il est immédiatement mis en service et le processus de reconstruction commence.

Vous pouvez garder un œil dessus comme suit :

Ça va probablement prendre un certain temps; sur mon serveur modeste (principalement basé sur du matériel grand public et des disques de bureau, attention), il pouvait atteindre un peu moins de 100 Mo/s. Gardez en tête qu’il s’agit de RAID-6, donc il y a beaucoup de calculs de parité impliqués lors d’une reconstruction; un RAID-10 aurait été beaucoup plus rapide. Cette machine en particulier a un processeur AMD A10 9700E quadricœur (le « E » signifie que c’est un modèle écoénergétique sous-cadencé, c’est-à-dire pas super rapide), juste pour vous donner une idée de ce à quoi vous attendre. Avec les neuf disques de 8 To dans mon installation, la reconstruction complète a pris un peu plus de 24 heures.

Pendant la reconstruction, vous pouvez monter le système de fichiers sur le tableau et l’utiliser normalement si vous le souhaitez, mais je préfère laisser la reconstruction jusqu’à ce que ce soit terminé. Gardez en tête que si un disque tombe en panne, un autre pourrait bientôt suivre, donc vous voulez que la reconstruction se fasse le plus rapidement possible, car vous ne voulez vraiment pas qu’un autre disque lâche pendant ce temps. Donc, ne la surchargez pas avec d’autres IO qui ne sont pas strictement nécessaires.

Une fois que c’est fait, rajoute ça dans ton fichier /etc/fstab, redémarre et profite de tes fichiers :-)