David Madore's WebLog: J'essaie le RAID6

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #1937 [older|newer] / Entrée #1937 [précédente|suivante]:

(mercredi)

J'essaie le RAID6

J'ai déjà dû raconter quelque part sur ce blog que je suis obsédé par la préservation de l'information. En particulier, l'idée de perdre des données informatiques est quelque chose contre quoi je veux me garder le plus sérieusement possible. Ça m'est déjà arrivé par le passé, à une époque où les disques durs coûtaient strictement plus qu'une bouchée de pain, et j'ai perdu des fichiers qui m'étaient précieux[#]. Pour mes données les plus précieuses, j'ai un système de sauvegarde où (1) les données sont répliquées par RAID entre plusieurs disques (cf. ci-dessous), (2) elles sont en plus répliquées chaque jour par rsync entre deux ordinateurs distants de 20km (et le point précédent s'applique sur chacun de ces ordinateurs), (3) sur l'un de ces ordinateurs, une copie est faite chaque nuit de tous les fichiers qui ont changé, histoire de pouvoir extraire de vieilles versions si je me rends compte que j'ai fait des changements malencontreux (ceci, en plus du fait que beaucoup de données sont de toute façon sous contrôle de git ; et le premier point s'applique aussi à ces copies), et (4) une fois par an au moins, je fais aussi une copie sur médias optiques, que j'archive. Avec tout ça, je me sens raisonnablement en sécurité.

Le problème, c'est qu'à côté de ces données de grande importante (très grossièrement, tous les fichiers que je crée moi-même), il y en a d'autres, qui ne méritent pas des précautions aussi importantes, ou surtout, qui ne les permettent pas parce que le volume de données est trop important, mais qu'il m'embêterait quand même assez sérieusement de perdre : des tas de choses que j'ai téléchargées sur Internet (ou dont l'effet de rayons cosmiques aléatoires frappant mon disque dur a causé l'apparition), ou encore des choses calculées par des ordinateurs au prix d'heures de calculs que je n'ai pas envie de refaire. Il me faut donc plusieurs niveaux intermédiaires entre les données les plus importantes et les moins importantes (voire, celles qui sont nettoyées automatiquement, comme le contenu de /tmp).

Et un autre facteur qu'il ne faut pas perdre de vue, c'est le temps passé à restaurer les données en cas de problème : parfois les données elles-mêmes n'ont pas vraiment de valeur (comme pour les partitions système : il s'agit d'exécutables Linux qui de toute façon sont disponibles publiquement), mais le temps passé à les récupérer ou à les remettre en place peut justifier qu'on utilise tel ou tel mécanisme de sauvegarde.

J'en viens à RAID : pour ceux qui ne connaissent pas, cet acronym signifie Redundant Array of Inexpensive Disks. L'idée est de partager des données entre plusieurs disques durs de façon soit à augmenter la capacité ou la vitesse, soit à diminuer les risques de pertes de données, soit les deux. En gros, vous avez N disques (ou partitions de même taille sur des disques différents), vous choisissez un niveau de redondance k qui vous protège contre la panne simultanée de k disques, et RAID vous présente l'ensemble comme si vous aviez un seul disque de la capacité totale de Nk disques, et qui peut résister à une défaillance de k disques. En clair, il existe les principaux niveaux suivants :

Lorsqu'on a 4 disques, toutes les possibilités sont représentées là : 0 disque de redondance pour RAID0, 1 pour RAID5, 2 pour RAID6 et 3 pour RAID1. (Je ne parle pas des autres niveaux de RAID, qui, à mon avis, ne sont pas très intéressants — par exemple le RAID10 est du RAID0 au-dessus de RAID1, qui entre 4 disques offre quelque part entre 1 et 2 disques de redondance vu qu'il peut subir la mort de 2 disques à condition que les 2 disques ne soient pas dans le même sous-tableau RAID1.)

En général, on ne choisit pas RAID1 entre un grand nombre de disques, ou, si on le fait, c'est pour des raisons différentes de la seule redondance (par exemple pour le fait que n'importe quel disque peut être lu pour trouver les données, ce qui peut être pratique lors du processus de démarrage). Certains peuvent se dire que RAID6, qui protège contre la panne simultanée de deux disques, est déjà un excès de précautions (quand un disque tombe en panne, on va le changer immédiatement, et il est peu vraisemblable qu'un autre disque tombe en panne pile à ce moment), mais c'est oublier que les pannes ne sont pas des événements indépendants : le même problème (un choc électrique ou mécanique, par exemple) peut causer la mort de plusieurs disques[#2], d'une part, et plus subtilement, l'utilisation du RAID lui-même peut causer la mort d'un disque (lorsqu'on remplace un disque dans un tableau RAID, il se produit une grande activité sur tout le tableau, qui peut accélérer la mort d'un disque) ; sans compter que si on a deux disques issus de la même série, ils peuvent avoir le même défaut de fabrication[#3]. Donc, deux disques de redondance, ce n'est pas forcément un luxe inutile.

Le RAID a aussi quelque chose de très agréable, c'est qu'il est complètement transparent. Si un disque fait une faute de lecture isolée, la couche RAID détecte la faute, lit les données à partir des autres disques, réécrit le secteur défectueux, ce qui cause sa réallocation par le firmware du disque (donc en pratique « la corrige »), et on ne voit qu'un léger délai. Si un disque meurt complètement, la couche RAID finit par se lasser, chasse le disque du tableau (qui devient alors dégradé), et tout continue à fonctionner, et quand vous achetez un nouveau disque pour le remplacer et que vous l'ajoutez au tableau, les données sont automatiquement copiées vers lui pour que le tableau cesse d'être dégradé. Pas besoin de s'embêter à retrouver où on a mis des copies de sauvegarde ou quoi que ce soit.

En contrepartie, RAID n'attrape pas tous les problèmes pour lesquels on fait des sauvegardes. Par exemple, si on efface un fichier malencontreusement, la couche RAID réplique l'effacement sur tous les disques, et ne vous protège pas du tout. Il existe des choses plus sophistiquées, comme des snapshots par copy-on-write (disponibles par exemple, sous Linux, dans BTRFS), mais cela, à son tour, ne vous protège pas contre des bugs du filesystem. Bref, il faut décider quelle assurance on veut, et contre quoi.

On a aussi parfois le choix entre le RAID logiciel ou matériel (c'est-à-dire que certaines cartes mères ou chipsets SATA sont capables de gérer le RAID de façon transparente et de ne présenter au système d'exploitation que l'apparence d'un seul disque). Mon choix est parfaitement clair, et c'est celui du RAID logiciel (celui de Linux : je ne suppose que Windows et Mac OS ont des choses semblables), qui est peut-être légèrement plus coûteux en ressources, mais qui m'offre beaucoup plus de finesse dans la gestion des choses, par exemple celle de convertir de RAID5 vers RAID6 (ou de lancer une vérification) sans passer des heures dans un outil du BIOS, et aussi la garantie que mes données sont stockées sur les disques dans un format connu et documenté, donc qu'elles ne vont pas devenir inaccessibles si ma carte mère meurt.

Comme je l'ai évoqué, il est possible de faire des conversions entre niveaux de RAID, ou entre nombres de disques. Ces conversions (de nouveau, sous Linux et en utilisant mdadm, je ne sais rien des autres OS) se font à chaud : le système continue de fonctionner normalement alors qu'on est en train de convertir, disons, un RAID5 entre 3 disques vers un RAID6 entre 4 disques (ce qui garde la même capacité, et ajoute un disque de redondance, mais nécessite de réorganiser toutes les données du tableau) ; les choses sont même prévues pour qu'on puisse interrompre l'opération et la reprendre plus tard (par contre, dans ce cas, le tableau cesse d'être disponible au moment où on interrompt). Enfin, ça c'est la théorie, parce que sur le noyau que j'utilise (un Linux 3.1.0-rc6[#4]), même si la conversion en elle-même se passe très bien, on ne peut pas dire que ça ne gêne pas le fonctionnement normal du système : j'ai des processus qui restent bloqués indéfiniment (et c'est probablement un bug, pas juste une attente disque devenue plus lente à cause de la conversion, parce que ça a l'air de toucher les processus un peu aléatoirement, et même quand on convertit des tableaux RAID absolument pas utiles au système ni utilisés par les processus qui bloquent). Enfin, ça reste utilisable, la preuve c'est que j'ai pu écrire tout ça sur la machine en question.

Moi je faisais du RAID5 entre 3 disques jusqu'à récemment, et comme j'ai vu qu'il y en a un qui commençait à montrer des faiblesses[#5] (ce qui, s'agissant de RAID5 veut dire qu'il faut le changer immédiatement), je me suis dit, plutôt que bêtement le remplacer, pourquoi ne pas ajouter un nouveau disque et faire du RAID6 sur 4 disques, et je virerai le disque qui faiblit quand il sera vraiment mort, pas au premier signe de faiblesse. En plus, ça me permet d'ajuster plus finement le niveau de RAID entre différentes partitions : il y en a pour lesquelles je reste à RAID5, mais sur 4 disques, pour gagner un peu de place, parce que ce sont des données vraiment peu importantes (un miroir Debian).

Et à part ça… c'est long… Mais qu'est-ce que c'est long ! La conversion du RAID5 sur N disques en RAID6 sur N+1 disques passe par un disque dur supplémentaire (il y a donc 5 disques impliqués dans l'affaire en ce qui me concerne, les détails sont là), vers lequel chacune des données du tableau doit être écrite, puis relue (ça va méchamment l'user, soit dit en passant — heureusement je m'en fous). Et ça se fait au rythme de 5.5Mo/s en moyenne. Et pour convertir 1To, au rythme de 5.5Mo/s, il faut… 50 heures. Voilà pourquoi, depuis maintenant une journée complète et sans doute pour encore aussi longtemps, j'ai 5 disques durs qui moulinent, qui moulinent, qui moulinent.

[#] En particulier, j'ai perdu des petits textes humoristiques que mon papa écrivait à mon sujet (c'est-à-dire, pour se foutre de moi), et qui s'appelaient The Adventures of Altcee : ça me fait de la peine, parce que j'aimerais bien les relire. Il semble qu'il en existe peut-être encore un exemplaire, mais il est sur une disquette 5″¼ et c'est devenu impossible de retrouver un lecteur 5″¼ de nos jours (ou en tout cas un lecteur 5″¼ dont on soit raisonnablement certain qu'il marche et qu'il ne risque pas d'endommager cette disquette si ce n'est pas déjà le cas !). [Ajout : elles ont maintenant été récupérées.]

[#2] J'ai un copain qui peut témoigner du risque lié au fait d'attacher les disques durs dans son boîtier avec des élastiques pour amortir les vibrations.

[#3] Raison pour laquelle j'essaie de faire des tableaux RAID entre disques de fabricants différents. Là, j'ai un Samsung, un Hitachi (le petit nouveau), un Seagate et un Western Digital.

[#4] Je n'aime pas utiliser des noyaux expérimentaux comme ça, mais en l'occurrence je n'avais pas le choix parce que j'étais coincé entre un bug USB des 2.6.38.x et un bug obscur dans le cache de routage dans les 3.0 qui cassait vraiment sérieusement ma config réseau, et pour lequel on ma donné un patch qui ne s'applique qu'au 3.1.

[#5] Dénonçons le coupable : c'est le Seagate. C'est un disque de 1To, et il en est à ~300 secteurs réalloués. Ceci dit, Western Digital mérite aussi un blâme dans l'histoire, pour des histoires expliquées ici par eux-mêmes (et dont l'explication technique détaillée est : ce sont des bouffons).

↑Entry #1937 [older|newer] / ↑Entrée #1937 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées