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

Les renseignements contenus dans cet article sont basés sur Ubuntu 18.04 et la version de mdadm incluse dans ses dépôts ; au moment de la rédaction de la v4.1-rc1. Cela peut être valable ou non pour d'autres versions.

J'ai récemment eu une panne de disque soudaine sur mon serveur de fichiers domestique, qui se compose de neuf disques dans une matrice RAID-6 mdadm. C'est toujours effrayant, mais j'ai heureusement pu trouver rapidement un disque de remplacement qui a été livré dès le lendemain pour que je puisse commencer la reconstruction.

J'avoue que j'ai été un peu trop radin lors de la configuration initiale du serveur de fichiers ; 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 rendu l'âme (après presque trois ans de service, cependant). C'était complètement mort ; après l'avoir déplacé vers un boîtier USB de bureau, tout ce que j'ai obtenu était un clic déconcertant et ni Ubuntu 20.04 ni Windows 10 n'ont pu le détecter.

Eh bien, passons à la pièce de rechange (et oui, le nouveau disque que j'ai acheté était un IronWolf, leçon apprise) - aussi effrayant que soit la perte d'un disque dans une matrice en cours d'exécution, c'est encore plus effrayant si vous ne connaissez pas la procédure correcte pour le remplacer. Ce n'est pas la première fois que je dois remplacer un lecteur défectueux dans une matrice mdadm, mais heureusement, c'est si rare que je dois généralement chercher les commandes appropriées. Cette fois, j'ai décidé de préparer mon propre petit guide pour référence future.

Donc, tout d'abord, lorsque vous recevez le redoutable courriel d'événement d'échec de mdadm, vous devez identifier le lecteur qui a échoué. Bien sûr, il vous indiquera le nom de l'appareil (dans mon cas /dev/sdf), mais il n'est probablement pas évident de savoir de quel lecteur physique il s'agit réellement, car ces noms peuvent changer au démarrage de la machine.

Si vous n'êtes même pas sûr du nom de l'appareil qui a échoué, vous pouvez utiliser la commande suivante pour le savoir (remplacez /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 lecteur défaillant en exécutant 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é aux numéros de série figurant sur l’étiquette physique des disques pour déterminer lequel est en panne.

Cette fois-ci, j'ai pas eu autant de chance. Le lecteur était complètement mort et refusait même de fournir des données SMART ou d'autres données, y compris le numéro de série.

Comme j'avais un accès physique au serveur (ce dont vous avez vraiment besoin si vous comptez remplacer vous-même un disque physique, je suppose ;-)) et que le serveur fonctionnait réellement lorsque le disque est tombé en panne (et a continué à fonctionner correctement grâce à la redondance RAID-6), j'ai opté pour la méthode vraiment primitive, mais en fait très efficace et évidente, consistant simplement à copier un gros fichier sur le serveur et à regarder quel voyant du disque dur ne clignotait pas. En quelques secondes, j'ai identifié le coupable.

Maintenant, avant de retirer le lecteur physique, c'est une bonne idée d'informer formellement mdadm de cette intention, en émettant cette commande (remplacez les noms de périphériques par les vôtres, le cas échéant) :

Si réussi, mdadm répondra avec un message indiquant qu'il a « supprimé à chaud » le lecteur, apparemment parce que le périphérique RAID virtuel est en cours d'exécution à ce moment-là.

Si l'opération échoue avec un message d'erreur semblable à « appareil ou ressource occupé », il se peut que mdadm n'ait pas enregistré le lecteur comme étant complètement en panne. Pour ce faire, exécutez cette commande (encore une fois, n'oubliez pas de remplacer les noms des appareils par les vôtres, le cas échéant) :

Après cela, vous devriez pouvoir retirer l'appareil de la matrice avec la commande précédente.

Il est maintenant temps de remplacer le lecteur. Si vous êtes vraiment, vraiment – vraiment – certain que votre machine et votre contrôleur prennent en charge l’échange à chaud, vous pouvez le faire sans éteindre la machine. Ce serait la voie à suivre pour les systèmes de production critiques fonctionnant sur du matériel de serveur réel et approprié dont vous savez avec certitude qu'il peut le gérer. Mon serveur de fichiers domestique est basé sur une carte mère de bureau grand public avec quelques contrôleurs SATA semi-non nommés dans les emplacements PCIe pour fournir plus de ports SATA.

Bien que SATA devrait généralement prendre en charge l'échange à chaud, je n'avais pas l'intention de risquer quoi que ce soit dans cette configuration, j'ai donc choisi d'éteindre la machine pendant le remplacement du disque.

Avant de faire cela, c'est une bonne idée de commenter le périphérique RAID dans le fichier /etc/fstab afin qu'Ubuntu n'essaie pas de le monter automatiquement au prochain démarrage, car il pourrait se bloquer et vous forcer à passer en mode de récupération en raison de la matrice RAID dégradée. Ce n'est peut-être pas un gros problème s'il s'agit d'un système de bureau, mais j'exécute ce serveur sans tête, sans moniteur ni clavier connecté, donc ce serait un peu compliqué.

Après avoir démarré la machine avec le nouveau lecteur installé, utilisez lsblk ou un autre moyen de l'identifier. Si vous n'avez rien changé d'autre, il portera probablement (mais pas nécessairement ) le même nom que le lecteur que vous avez remplacé. Dans mon cas, c'est le cas, donc le nouveau s'appelle aussi /dev/sdf.

Comme ma matrice est basée sur des partitions plutôt que sur des périphériques physiques, j'ai dû copier la table de partition d'un lecteur fonctionnel vers le nouveau lecteur afin de m'assurer qu'elles sont exactement identiques. Si vous exécutez votre baie sur des périphériques physiques, vous pouvez sauter cette étape.

J'ai utilisé sgdisk à cette fin, en copiant la table de partition de /dev/sdc vers /dev/sdf. Assurez-vous de remplacer les noms des appareils pour qu'ils correspondent aux vôtres, le cas échéant.

Notez l'ordre ici : vous listez le lecteur « à » en premier ! C'est un peu contre-intuitif pour moi, mais assurez-vous simplement de bien faire les choses afin de ne pas avoir une autre panne de disque dans la matrice ;-)

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

Et maintenant, le temps est enfin venu d'ajouter le nouveau disque à la matrice et de lancer la fête de reconstruction ! (Ok, ce n'est pas vraiment une fête, c'est en fait un processus assez lent et déstabilisant parce que vous ne voulez vraiment pas qu'un autre disque tombe en panne à ce moment-là. La bière pourrait cependant aider)

Quoi qu'il en soit, pour ajouter le nouveau lecteur à la matrice, exécutez cette commande (encore une fois, assurez-vous de remplacer les noms de périphériques par les vôtres, le cas échéant) :

Si tout se passe bien, le lecteur sera ajouté à la matrice sans problème. Je crois qu'il est en fait ajouté en tant que « disque de secours » par défaut, mais comme il manque un disque à cette matrice (celui qui est tombé en panne), il est immédiatement mis en service et le processus de reconstruction démarre.

Vous pouvez le surveiller comme ceci :

Ça va probablement prendre du temps ; sur mon modeste serveur (basé en grande partie sur du matériel grand public et des disques de bureau, attention), il était capable d'atteindre un peu moins de 100 Mo/s. Gardez à l'esprit qu'il s'agit d'un RAID-6, donc de nombreux calculs de parité sont impliqués dans une reconstruction ; un RAID-10 aurait été beaucoup plus rapide. Cette machine particulière dispose d'un processeur quad-core AMD A10 9700E (le « E » signifiant qu'il s'agit d'un modèle économe en énergie 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 ma configuration, 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 matrice et l'utiliser normalement si vous le voulez, mais je préfère le laisser à la reconstruction jusqu'à ce qu'elle soit terminée. Gardez à l'esprit que si un disque tombe en panne, un autre peut bientôt suivre, vous voulez donc que la reconstruction soit effectuée le plus rapidement possible car vous ne voulez vraiment pas qu'un autre disque tombe en panne pendant cela. Par conséquent, ne le surchargez pas avec d’autres E/S qui ne sont pas strictement nécessaires.

Une fois terminé, ajoutez-le à votre fichier /etc/fstab, redémarrez et profitez de vos fichiers :-)