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 référentiels ; au moment de la rédaction, v4.1-rc1. Elles peuvent ou non être valables pour d'autres versions.

J'ai récemment eu une panne soudaine d'un disque dur sur mon serveur de fichiers personnel, 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, ce qui m'a permis de commencer la reconstruction.

J'ai admis avoir été un peu radin lors de la configuration initiale du serveur de fichiers ; seuls 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). Il était complètement mort ; après l'avoir déplacé vers un boîtier USB de bureau, tout ce que j'en 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 disque défectueux dans une matrice mdadm, mais heureusement, c'est si rare que je dois généralement rechercher les commandes appropriées. Cette fois, j'ai décidé de préparer mon propre petit guide pour référence future.

Tout d'abord, lorsque vous recevez le redoutable e-mail d'événement d'échec de mdadm, vous devez identifier le lecteur qui est en panne. Bien sûr, il vous indiquera le nom du périphérique (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 du périphérique 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 package 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, je n'ai pas eu autant de chance. Le disque é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 un disque physique vous-même, 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'avais 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) :

En cas de succès, 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 similaire à « périphérique ou ressource occupée », 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 de périphériques par les vôtres, le cas échéant) :

Après cela, vous devriez pouvoir retirer le périphérique de la matrice avec la commande précédente.

Il est maintenant temps de remplacer le disque dur. Si vous êtes vraiment, vraiment – vraiment – certain que votre machine et votre contrôleur prennent en charge le remplacement à chaud, vous pouvez le faire sans éteindre la machine. Ce serait la voie à suivre sur les systèmes de production critiques fonctionnant sur un matériel de serveur réel et approprié dont vous savez avec certitude qu'il peut le gérer. Mon serveur de fichiers personnel est basé sur une carte mère de bureau grand public avec quelques contrôleurs SATA semi-non-name 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. Cela peut ne pas être un gros problème s'il s'agit d'un système de bureau, mais j'exécute ce serveur sans écran ni clavier, donc ce serait un peu compliqué.

Après avoir démarré la machine avec le nouveau disque dur installé, utilisez lsblk ou un autre moyen pour l'identifier. Si vous n'avez rien changé d'autre, il aura probablement (mais pas nécessairement ) le même nom que le disque 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 matrice sur des périphériques physiques, vous pouvez ignorer 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 de périphériques par les 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 de bien faire les choses pour ne pas avoir une autre panne de lecteur dans la matrice ;-)

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

Et maintenant, le moment est enfin venu d'ajouter le nouveau disque à la matrice et de commencer la reconstruction ! (Ok, ce n'est pas vraiment une fête, c'est en fait un processus assez lent et déroutant car 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 :

Cela prendra probablement un certain temps ; sur mon serveur modeste (basé en grande partie sur du matériel grand public et des disques durs de bureau, attention), il a pu atteindre un peu moins de 100 Mo/s. Gardez à l'esprit qu'il s'agit d'un RAID-6, donc il y a beaucoup de calculs de parité impliqués dans une reconstruction ; un RAID-10 aurait été beaucoup plus rapide. Cette machine particulière est équipée 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 de 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 souhaitez, mais je préfère laisser la reconstruction se faire 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 :-)