Test du RAID-1 sur OpenSuse

Comme je l’ai décrit dans un précédent article, je souhaitais tester la technologie RAID sur une configuration GNU/Linux OpenSUSE. Dans l’article de la semaine dernière, j’ai présenté comment créer/installer une matrice RAID (RAID array).

Aujourd’hui, j’ai l’intention de voir ce qui se passe lorsqu’un disque dur tombe en panne dans la matrice RAID (RAID array). Elle est sensée protéger intégralement mes données, mais je préfère faire mon Saint Thomas et vérifier par moi-même. Ensuite, je vais aussi tester la manière de rajouter un nouveau lecteur (en remplacement du disque qui est “mort”). A ce moment, je vais aussi en profiter pour changer la taille du disque rajouté (après plusieurs années de fonctionnement, il est probable qu’un disque de remplacement sera une version plus grosse de celui qui est tombé en panne).

Objectifs

La première chose à faire est de simuler la panne d’un disque dur (je n’ai pas eu la possibilité d’attendre quelques mois à quelques années pour obsevrer cet accident et je n’ai pas eu la douteuse chance de le voir réellement arriver sous mes yeux pendant le test). J’ai donc décidé de simplement débrancher l’un des deux disques de la matrice RAID.

Juste pour être certain de bien comprendre l’opération, une matrice RAID est supposée accepter cet incident sans perte de données et en continuant à fonctionner normalement (comme, dans le RAID-1, les deux disques contiennent exactement les mêmes données en double, à part la réduction de la sécurité, la panne d’un disque impose simplement de travailler avec une seule copie des données et sans réduction des fonctionnalités de base). Bien sûr, dans une telle situation il est prévu de remplacer le lecteur en panne par un nouveau disque dur pour restaurer le fonctionnement normal en mode RAID-1.

Je veux m’assurer que :

• Le fonctionnement n’est pas perturbé de manière significative.
• L’insertion d’un nouveau disque est détectée comme une opération de réparation.
• La réparation peut être faite avec une perturbation minimale ; le systême est restauré sans avoir besoin de passer par une longue opération de sauvegarde intermédiaire.

Panne du disque dur

La première chose que j’ai entreprise était de contrôler si je pouvais bien retirer un des disques depuis le centre de configuration YAST de OpenSUSE. Comme je pouvais m’en douter, YAST détecte bien que c’est une opération totalement anormale et ce n’est pas possible sans commencer par retirer la matrice RAID elle-même, ce qui n’est pas mon intention -au contraire. J’en suis donc rapidement revenu à la méthode normale : j’ai arrêté l’ordinateur et physiquement débranché l’un des disques durs, dans l’espoir de voir cet incident reconnu par le logiciel. Cela devrait assez représentatif d’une panne simulée.

Au reboot, l’ordinateur donnait tous les signes apparents du bon fonctionnement. Tout avait l’air parfait (à l’exception d’un message vraiment incompréhensible à propos de l’exécution d’une commande qt, qui semblait sans rapport. Mieur -ou pire- le répertoire /secure (qui abrite la matrice RAID) fonctionne parfaitement alors qu’il lui manque un des deux disques utilisés pour le configurer. C’est ainsi que l’on peut assurer que le premier objectif du RAID-1 est atteint : en cas de panne de l’un des disques, l’ordinateur reste pleinement fonctionnel et aucune donnée n’a été perdue. Mais j’avoue que je reste inquiet de l’absence totale de message d’information. Si je ne m’en préoccupais pas spécifiquement (pour cause de test), je ne saurais pas qu’il y a eu panne et que je dois remplacer le lecteur défaillant.

Néanmoins, si j’utilise la commande cat /proc/mdstat, je pourrais me rendre compte de l’état nouveau de ma matrice RAID : elle tourne sur une patte seulement (elle utilise un disque au lieu de deux), comme on peut le voir ci-dessous.

leakey:/secure # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdb1[0]
16458496 blocks [2/1] [U_]

unused devices:
leakey:/secure #

Afin de faciliter la comparaison, voici également la réponse normale à la même commande cat /proc/mdstat sur une matrice RAID complète :

leakey:/secure # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdd1[1] hdb1[0]
16458496 blocks [2/2] [UU]

unused devices:
leakey:/secure #

En complément, j’ai donc décidé de vérifier l’état de la configuration RAID depuis l’outil de configuration YAST. Voici comment apparaissent les choses :

Et il faut bien admettre que l’absence d’un disque n’est pas plus perceptible si l’on n’y fait pas spécialement attention. Une solution devrait très certainement être présente dans le système d’exploitation ; cela fera peut-être l’objet d’un article ultérieur ici-même.

Utilisation d’une matrice RAID partiellement défaillante

Pour être bien sûr que tout allait bien, j’ai décidé de me lancer dans une exploitation intensive de la matrice RAID-1 (j’ai copié un nombre considérable de fichiers depuis et vers la matrice RAID). A l’évidence, la nouvelle situation de la matrice (panne d’un disque, je le rappelle) n’a aucune influence perceptible. Pour l’essentiel, tout fonctionne comme sur un disque normal. Il suffit de se souvenir que nous sommes simplement revenu à la situation courante d’un disque dur connecté au PC (il n’y a donc plus la fonction de protection supplémentaire qu’apportait le mode RAID-1.

Réparation de la matrice RAID

L’étape suivante étant bel et bien de réparer la marice avec un disque dur neuf, j’ai réinséré un disque dans le système et j’ai rebooté l’ordinateur. La première chose à faire était de s’assurer que le lecteur n’était pas automatiquement inséré dans la matrice sans contrôle humain (il s’agit d’une opération exceptionnelle mais que je préfère voir faite par mes soins attentifs plutôt que par ceux d’un programme incertain).

Je me suis donc rendu dans l’outil de configuration YAST et j’ai lancé l’outil de partionnement. J’y ai eu l’information suivante montrant que la présence du nouveau disque dur était bien reconnue (il vous faudra peut-être rebooter une fois pour arriver à ce point) :

Le disque /md/hdd nouvellement ajouté est facile à repérer, mais rien n’indique ici comment l’insérer dans la matrice RAID-1 nommée md0.

En fait, après une assez longue recherche sur le web, j’ai trouvé la solution pour insérer le disque /md/hdd dans la matrice RAID. Premièrement, il faut partitionner le disque en configuration auto-RAID (pas très surprenant, c’est ce que nous avions fait à la création de la matrice dans l’article précédent). Il faut cliquer sur le bouton Créer... et choisir le disque /dev/hdd que vous voulez partitionner. Choisissez de créer une partition Primaire :

Cela produit un nouveau drive disponible pour une matrice RAID comme on peut le voir sur l’écran suivant :

Mais comme on peut le voir, le drive /dev/hdd1 n’est pas encore rattaché à la matrice md0.

C’est là que les choses se compliquent malheureusement, parce que YAST ne semble pas capable de modifier la matrice RAID à la volée. Tout ce que j’ai pu essayer n’a mené qu’à des messages d’erreur me demandant de détruire la matrice et de la re-créer à partir de zéro (ce que je n’ai pas l’intention de faire, puisque je veux préserver mes données). J’ai donc simplement décidé de demander à YAST d’appliquer ces premières modifications en cliquant sur le bouton Appliquer puis de le quitter pour utiliser la ligne de commande.

Sur la ligne de commande, j’ai pu lancer la commande appropriée qui porte le doux nom de raidhotadd.

leakey:/secure # /sbin/raidhotadd /dev/md0 /dev/hdd1
leakey:/secure #

Remarquez que vous aurez peut-être besoin de vous idnetifier comme root pour lancer une telle commande. Quoi qu’il en soit, vous savez que la commande a bien fonctionné par l’absence de message d’erreur et parce que vous allez voir ou entendre les disques durs qui commencent à reconstruire la matrice en arrière-plan (les LED rouges de fonctionnement des disques dur se mettent à clignoter furieusement ou vont rester allumées pour une période relativement longue -aussi longtemps que nécessaire pour reconstruire la matrice RAID-1). Si vous voulez une meilleure visibiltié, vous pouvez aussi utiliser la ligne de commande :

leakey:/secure # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdd1[2] hdb1[0]
16458496 blocks [2/1] [U_]
[==>.................] recovery = 13.8% (2282816/16458496) finish=9.3min speed=25145K/sec

unused devices:
leakey:/secure #

Ci-dessus, se présente la réponse pour une matrice en cours de reconstruction (13.8% d’avancement). Ci-dessous, se présent une matrice qui vient de finir sa reconstruction.

leakey:/secure # cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 hdd1[1] hdb1[0]
16458496 blocks [2/2] [UU]

unused devices:
leakey:/secure #

Mais si vous ne voulez pas vous laisser ennuyer par ces détails, je vous conseille de simplement patienter en regardant les LED clignoter. Quand elles reviennennt à un état plus calme et plus normal, la reconstruction est finie et vous pouvez utiliser la matrice RAID en toute sécurité.

Conclusion

Au bout de ce test, nous avons pu réparer la matrice RAID-1. Elle a été reconstruite sans perte de données et avec un impact minimal sur le fonctionnement du PC.

Nous avons pu apprendre plusieurs choses de cette expérience :

• La panne d’un disque n’a pas d’impact perceptible sur le fonctionnement de la matrice RAID-1. Nos données sont bien protégées contre une panne de disque.
• La réparation de la matrice RAID-1, même si elle n’est pas très difficile, rest une tâche plus complexe que la création dans une configuration GNU/Linux. Mais c’est faisable même sans grande connaissances informatiques. Et puis, il est toujours possible de faire un backup total des données et de reconstruire la matrice à partir de zéro.

Il est ainsi relativement facile de protéger vos données contre une panne physique d’un disque dur. Mais une distribution GNU/Linux (au moins OpenSUSE 10) et sa fonctionnalité de RAID logiciel gardent des angles vifs ou -tout au moins- plus difficile que pour une configuration purement matérielle (carte spécialisée). Pas impossible, mais on puet souhaiter des améliorations dans le futur.