<!DOCTYPE linuxdoc system
[ <!ENTITY CurrentVer "0.90.7">
<!ENTITY mdstat "<TT>/proc/mdstat</TT>">
<!ENTITY ftpkernel "<TT>ftp://ftp.fi.kernel.org/pub/linux</TT>">
<!ENTITY fstab "<TT>/etc/fstab</TT>">
<!ENTITY raidtab "<TT>/etc/raidtab</TT>">
]
>
<!-- Software-RAID HOWTO, version SGML -->
<!-- version originale par Jakob Østergaard, jakob@ostenfeld.dk -->
<!-- traduit par François Romieu, romieu@ensta.fr -->
<!-- Ce document est un documentation libre et gratuite : vous pouvez -->
<!-- la redistribuer et/ou la modifier selon les termes de la licence LDP. -->
<!-- Ce document est distribué dans l'espoir qu'il rendra service et sans -->
<!-- aucune garantie ; sans même une garantie implicite de -->
<!-- possibilité de commercialisation pour un objectif précis. -->
<!-- Consultez la licence LDP pour de plus amples détails. -->
<ARTICLE>
<TITLE>Software-RAID HOWTO
<AUTHOR>Jakob Ø ;stergaard
(<htmlurl
url="mailto :jakob@ostenfeld.dk"
name="jakob@ostenfeld.dk">)
<DATE>v. &CurrentVer ; 19th of January 2000
<ABSTRACT>
Ce document décrit l'utilisation du RAID logiciel 0.90 sous Linux mis
au point par Ingo Molnar et d'autres développeurs. Il s'agit de la
couche RAID qui sera standard pour les versions 2.4.x du noyau Linux et
qui est également disponible sous forme de patches pour la branche 2.2.
La couche d'adaptation RAID 0.90 est disponible sous forme de patches
pour les branches 2.0 et 2.2. De nombreuses personnes la considèrent
comme bien plus robuste que la couche RAID courante.
those kernels.
</ABSTRACT>
<TOC>
<sect> Introduction
<P>
Pour une description de la version antérieure de l'interface RAID
standard dans les noyaux 2.0 et 2.2, reportez vous à l'excellent
document de Linas Vepstas
(<htmlurl url="mailto :linas@linas.org" name="linas@linas.org">)
disponible via le Linux Documentation Project à l'adresse
<htmlurl url="http ://linuxdoc.org" name="linuxdoc.org">.
<P>
<htmlurl name="http ://ostenfeld.dk/~jakob/Software-RAID.HOWTO/"
url="http ://ostenfeld.dk/~jakob/Software-RAID.HOWTO/"> est la page
de référence pour ce HOWTO où les dernières mises à jour seront
disponibles. Ce document a été rédigé par Jakob Ostergaard
à partir de nombreux messages électroniques échangés entre l'auteur
et Ingo Molnar <htmlurl url="mailto :mingo@chiara.csoma.elte.hu"
name="(mingo@chiara.csoma.elte.hu)"> - un des développeurs du RAID - ,
la liste de diffusion linux-raid <htmlurl
url="mailto :linux-raid@vger.rutgers.edu"
name="(linux-raid@vger.rutgers.edu)"> ainsi que diverses personnes.
<P>
La rédaction de ce HOWTO a été motivée par le besoin de documentation
du nouveau système RAID alors que le Software-RAID existant ne
documentait que les versions précédentes. Des fonctionnalités nouvelles
ont notamment été introduites.
<P>
Pour utiliser la nouvelle mouture du RAID avec les noyaux 2.0 ou 2.2, vous
devez récupérer le patch correspondant, par exemple à l'adresse <htmlurl
url="ftp://ftp.fi.kernel.org/pub/linux/daemons/raid/alpha"
name="ftp://ftp.[your-country-code].kernel.org/pub/linux/daemons/raid/alpha">,
ou depuis <htmlurl url="http://people.redhat.com/mingo/"
name="http://people.redhat.com/mingo/">. Les noyaux 2.2 officiels ne
gèrent directement que l'ancien type de RAID et les patches sont donc
nécessaires. <em>L'ancien système RAID des noyaux 2.0 et 2.2 est
buggé</em>. De surcroît, il lui manque d'importantes fonctionnalitées
présentes dans la nouvelle version.
<P>
La nouvelle mouture du RAID est en cours d'intégration dans les noyaux
de développement 2.3.x et sera donc disponible dans la branche 2.4.
Jusqu'à la sortie de celle-ci, il sera nécessaire de patcher manuellement
les noyaux.
<P>
Peut-être esssayerez vous les versions <tt>-ac</tt> du noyau proposées
par Alan Cox pour disposer du RAID. <em>Certaines</em> d'entre elles
incluent le nouveau système et vous épargneront donc l'application de
patches.
<P>
Le HOWTO contient des informations triviales pour ceux qui maîtrisent
déjà les principes des systèmes RAID. Inutile de vous y attarder.
<P>
<sect1> Avertissement
<P>
L'avertissement indispensable  :
<P>
Bien que le fonctionnement du système RAID semble stable chez moi et
chez de nombreuses personnes, cela pourrait ne pas être le cas pour
vous. Si vous perdez vos données, votre emploi, votre femme ou que
vous vous faites écraser par un camion, ce ne sera ni de ma faute, ni
de celle des développeurs. Vous utilisez les fonctionnalités RAID, ainsi
que toutes les informations contenues dans ce documenti, à vos risques
et périls. Il n'y a pas la moindre garantie concernant le
logiciel ou ce document ni la moindre assurance que cela puisse servir
à quoi que ce soit. Sauvegardez toutes vos données avant la moindre
manipulation. Il vaut mieux être prudent que désolé.
<P>
Ceci étant, je dois reconnaitre que je n'ai pas eu de problèmes de
stabilité avec le RAID logiciel, que je l'employe sur quelques
machines et que je n'ai entendu personne évoquer des plantages
aléatoires ou des instabilités avec le RAID.
<P>
<sect1> Prérequis
<P>
Le HOWTO suppose que vous utilisez un des derniers noyaux 2.2.x ou 2.0.x
modifié par le patch raid0145 adéquat ainsi que la version 0.90 des
raidtools ou que vous vous servez d'un 2.3 postérieur à la > 2.3.46,
voire d'un 2.4. Les patches et les outils se trouvent par exemple à  :
<HTMLURL name="ftp://ftp.fi.kernel.org/pub/linux/daemons/raid/alpha"
url="ftp://ftp.fi.kernel.org/pub/linux/daemons/raid/alpha"> ou pour
certains à l'adresse  : <htmlurl url="http://people.redhat.com/mingo/"
name="http://people.redhat.com/mingo/">. Les patches RAID, le paquetage
des raidtools et le noyau doivent s'accorder autant que possible. Il sera
peut-être parfois nécessaire de se restreindre à des noyaux plus anciens
si les patches ne sont pas disponibles pour le dernièr noyau sorti.
<P>
<sect> Motivation du RAID
<P>
Il existe différentes bonnes raisons pour se servir du RAID parmis
lesquelles figurent la possibilité de fusionner plusieurs disques
physiques en un périphérique virtuel plus important, l'amélioration
des performances et la redondance.
<P>
<sect1> Aspects techniques
<P>
Le RAID Linux est adapté à la majeure partie des périphériques de type
bloc. Peu importe que vous utilisiez de l'IDE, du SCSI ou un mélange des
deux. Certains ont également obtenu quelques succès en s'en servant
avec des périphériques de type bloc en réseau (Network Block Device ou
NBD).
<P>
Vérifiez que les bus d'accès aux périphériques sont assez rapides.
Il n'est pas conseillé d'installer 14 disques Ultra Wide sur une même
chaine si chacun d'entre eux peut débiter 10 Mo/s car le bus, lui, ne
dépassera pas les 40 Mo/s.
Vous avez également intérêt à ne pas mettre plus d'un disque par
interface IDE sans quoi les performances ne vont pas être fameuses.
L'IDE n'est pas adapté pour l'accès simultané à plusieurs disques sur
une même interface. Toutes les cartes mères récentes incluent deux
ports et vous pourrez donc configurer deux disques en RAID sans acheter
de contrôleur supplémentaire.
<P>
La couche RAID est indépendante du système de fichier. Vous pourrez donc
y superposer celui de votre choix.
<P>
<sect1> Vocabulaire
<P>
RAID sera employé pour "RAID logiciel Linux". Le document ne traite
pas du RAID matériel.
<P>
Dans la description des configurations, on utilise fréquemment le nombre
de disques et leur taille. <bf>N</bf> désignera le nombre de disques
dans une matrice RAID, les disques de secours étant exclus, <bf>S</bf>
sera la taille du plus petit disque et <bf>P</bf> le débit d'un disque
en Mo/s. Quand on se servira de P, on supposera que les disques ont tous
les mêmes performances (à vérifier).
<P>
Périphérique et disque seront synonymes. En général, les matrices RAID
sont davantage construites avec des partitions qu'avec des disques
complets. La combinaison de plusieurs partitions appartenant à un même
disque ne présente guère d'intérêt et on entendra donc par périphérique
et disque "des partitions sur différents disques".
<P>
<sect1> Niveaux RAID
<P>
Voici une brève description des niveaux de RAID gérés par Linux.
Certaines de ces infos sont basiques mais j'ai fait mention d'éléments
spécifiques à la mise en oeuvre au sein de Linux. Sautez cette section
si vous savez ce qui se cache derrière le RAID. Vous y reviendrez quand
vous aurez des problèmes :o)
<P>
Les patches RAID pour Linux offrent les possibilités suivantes  :
<itemize>
<item> <BF>mode linéaire</BF>
<itemize>
<item> Deux disques et plus sont combinés par concaténation. L'écriture
sur le disque RAID se fera donc d'abord sur le premier puis sur le
second quand il sera plein et ainsi de suite. Il n'est pas nécessaire
que les disques soient de la même taille et, pour tout dire, la taille
n'est ici d'aucune importance.
<item> Il n'y a aucune redondance à ce niveau. Si un disque tombe en
panne, vous perdrez surement toutes vos données. Vous aurez peut être
la chance d'en récupérer une partie si, du point de vue du système de
fichiers, il ne manque qu'un gros bloc consécutif de données.
<item> Les performances en lecture/écriture ne vont pas s'améliorer
automatiquement mais si plusieurs utilisateurs se servent
simultanément du périphérique, il se peut qu'ils accèdent à des disques
différents et que les performances en soient augmentées.
</itemize>
<item> <BF>RAID-0</BF>
<itemize>
<item> Ou "stripe". Semblable au mode linéaire à ceci près que les
lectures et les écritures ont lieu en parallèle sur les disques. Les
disques doivent avoir sensiblement la même taille. Les périphériques se
remplissent progressivement de la même façon. Si l'un des deux est plus
grand que l'autre, l'espace supplémentaire est toujours employé pour la
matrice RAID mais vous n'utiliserez qu'un des deux disques vers la fin.
Les performances en patiront.
<item> Comme en linéaire, il n'y a pas de redondance des données mais
en plus vous ne serez pas capable de récupérer vos données si un
disque tombe en panne. Au lieu de ce qu'il vous manque un gros bloc de
données, votre système de fichiers comprendra de nombreux petits trous.
e2fsck ne sera vraisemblablement pas en mesure de reconstituer quoi que
ce soit.
<item> Les performances en lecture/écriture augmenteront puisque les
lectures et les écritures auront lieu sur les deux disque en même
temps. C'est souvent ce qui motive l'emploi du RAID-0. Si les bus sont
assez rapides, vous pourrez flirter avec N*P Mo/s.
</itemize>
<item> <BF>RAID-1</BF>
<itemize>
<item> Il s'agit du premier mode redondant. Le RAID-1 s'employe à partir
de deux disques auxquels viennent éventuellement se greffer des disques
de secours. Ce mode duplique les informations d'un disque sur
l(es)'autre(s). Bien sûr, les disques doivent être de même taille. Si
un disque est plus grand que les autres, la matrice sera de la taille
du plus petit.
<item> Jusqu'à N-1 disques otés (ou défectueux), les données restent
intactes et si le contrôleur (SCSI, IDE, etc...) survit, la
reconstruction sera immédiatement entamée sur un des disques de secours
après détection de l'anomalie.
<item> Les performances en écriture sont légèrement inférieures à celles
d'un disque unique vu que les données doivent être écrites sur chaque
disque de la matrice. Les performances en lecture sont <em>en
général</em> bien plus mauvaises en raison de la mise en oeuvre au sein
du code d'une stratégie d'équilibrage simpliste. Cependant, cette partie
des sources a été revue pour le noyau 2.4.
</itemize>
<item> <BF>RAID-4</BF>
<itemize>
<item> Ce niveau RAID n'est pas utilisé très souvent. Il s'employe à
partir de trois disques et plus. Au lieu d'effectuer une copie des
informations, on conserve la parité sur un disque et on écrit les
données sur les autres comme on le ferait avec une matrice RAID-0.
Un disque étant dédié à la parité, la taille de la matrice sera
(N-1)*S ou S est la taille du plus petit disque. Comme en RAID-1, les
disques doivent avoir la même taille sans quoi le S précédent
correspondra à celui du plus petit disque.
<item> Si un disque lache, l'information de parité permet de reconstruire
toutes les données. Si deux disques lachent, toutes les données sont
perdues.
<item> On n'utilise pas beaucoup ce niveau en raison du stockage de la
parité sur un disque unique. L'information doit être mise à jour à
<em>chaque</em> fois qu'on écrit sur un des disques, ce qui constitue
un goulot d'étranglement si le disque de parité n'est pas nettement
plus rapide que les autres. Cependant, si vous avez beaucoup de petits
disques lents et un disque très rapide, le RAID-4 peut s'avérer très
utile.
</itemize>
<item> <BF>RAID-5</BF>
<itemize>
<item> Il s'agit surement du mode le plus approprié quand on souhaite
combiner un grand nombre de disques tout en conservant de la
redondance. Le RAID-5 s'employe à partir de trois disques avec
éventuellement des disques de secours. La matrice sera de taille
(N-1)*S, comme en RAID-4. A la différence du RAID-4, l'information de
parité est répartie équitablement entre les différents disques,
évitant ainsi le goulot d'étranglement du RAID-4.
<item> Si un des disques tombe en panne les données restent intactes.
La reconstruction peut commencer immédiatement si des disques de
secours sont disponibles. Si deux disques rendent simultanément l'âme,
toutes les données sont perdues. Le RAID-5 ne survit pas à la
défaillance de plus d'un disque.
<item>Les performances en lecture/écriture s'améliorent mais il est
difficile de prévoir de combien.
</itemize>
</itemize>
<sect2> Disques de secours
<P>
Les disques de secours ne prenent pas part à la matrice RAID jusqu'à
ce qu'un des disques de celle-ci tombe en panne. Quand un disque
lache, il est marqué défectueux et la reconstruction est entamée sur
le premier disque de secours disponible.
<P>
Les disques de secours renforcent donc la sécurité de systèmes RAID-5
qui peuvent être difficilement accessibles. Le système peut
fonctionner pendant un certain temps aec un disque défectueux tant que
le disque de secours assure la redondance.
<P>
Vous ne pouvez être sûr de la survie de votre système en cas de
défaillance d'un disque. La couche RAID peut faire son travail mais
les gestionnaires SCSI peuvent receller des erreurs, les composants
IDE peuvent se bloquer et d'autres phénomènes peuvent se produire.
<P>
<sect1> RAID et swap
<P>
Il n'y a aucune raison d'employer le RAID au dessus du swap pour en
améliorer les performances. Le noyau se charge lui-même d'équilibrer
le swap sur plusieurs périphériques si toutes les partitions ont la
même priorité dans la fstab.
<P>
Un fichier fstab correct ressemble à ce qui suit  :
<verb>
/dev/sda2 swap swap defaults,pri=1 0 0
/dev/sdb2 swap swap defaults,pri=1 0 0
/dev/sdc2 swap swap defaults,pri=1 0 0
/dev/sdd2 swap swap defaults,pri=1 0 0
/dev/sde2 swap swap defaults,pri=1 0 0
/dev/sdf2 swap swap defaults,pri=1 0 0
/dev/sdg2 swap swap defaults,pri=1 0 0
</verb>
Cette configuration permet à la machine de swaper en parallèle avec
sept périphériques SCSI. Aucun besoin du RAID pour ça vu qu'il s'agit
d'une fonctionnalité présente dans le noyau de longue date.
<P>
Le RAID s'emploie pour le swap à des fins de haute disponibilité.
Si vous configurez un système pour démarrer sur un périphérique
RAID-1, le système doit être capable de survivre à une défaillance
de disque. Seulement si le système était en train de swaper sur le
périphérique défectueux, vous allez surement avoir des problèmes.
Swaper sur une matrice RAID-1 aide dans ce genre de situations.
<P>
Il y a eu beaucoup de discussions concernant la stabilité du swap
sous une couche RAID logicielle. Le débat continue car il dépend
fortement d'autres aspects du noyau. A la date de rédaction de ce
document, il semble que swaper via le RAID soit parfaitement stable
<em>à l'exception</em> des phases de reconstruction (i.e. lorsqu'un
nouveau disque est inséré dans une matrice dégradée).
La question ne se posera plus lorsque le noyau 2.4 sortira mais
jusque là, à vous de pousser le système dans ses retranchements afin
de savoir si la stabilité vous satisfait ou bien si vous ne vous
servirez pas du RAID pour le swap.
<P>
Vous pouvez utiliser un fichier de swap sur un système de fichiers
au dessus d'une couche RAID, activer le RAID pour le fichier lui
même ou déclarer un périphérique RAID en tant que swap. A vous de
voir. Comme d'habitude, le disque RAID apparaitra comme un
périphérique de type bloc.
<P>
<sect> Aspects matériels
<P>
Cette section a trait à certaines problèmes matériels qui se posent
lorsqu'on se sert du RAID logiciel.
<P>
<sect1> Configuration IDE
<P>
Le RAID fonctionne avec des disques IDE. On peut d'ailleur obtenir
d'excellentes performances. En fait, compte tenu du prix actuel des
disques et des contrôleurs IDE, le choix de ce matériel est
à examiner lors de la mise en place d'un système RAID.
<itemize>
<item> <BF>Stabilité :</BF> les caractéristiques de tenue des
disques IDE ont jusqu'ici été moins bonnes que celles des disques SCSI.
Aujourd'hui encore, la garantie des disques IDE se cantonne typiquement
à un an tandis qu'elle est de trois à cinq ans pour les disques SCSI.
Bien qu'il soit exagéré d'affirmer que les disques IDE ont une qualité
intrinsèque moindre, il faut reconnaitre que <em>certains</em> disques
auront tendance à tomber en panne plus souvent que leurs équivalents SCSI.
Maintenant, la mécanique est la même pour le SCSI et l'IDE. Il faut
juste rester conscient de ce que tous les disques lachent, un jour ou
l'autre. Il suffit de s'y préparer.
</item>
<item> <BF>Intégrité des données :</BF>autrefois, il n'y avait aucune
garantie que les données écrites sur le disques fussent bien celles
qui avaient été émises sur le bus (pas de vérification de parité ni
de code d'erreur, etc...). Les disques durs IDE conformes aux
spécifications Ultra-DMA effectuent un calcul de vérification sur les
données qu'ils reçoivent. Il devient donc fortement improbable que des
données soient corrompues.
</item>
<item> <BF>Performance :</BF> je ne vais pas m'étendre sur cet aspect
des disques IDE. En résumé  :
<itemize>
<item> les disques IDE sont rapides (12 Mo/s et plus) </ITEM>
<item> le système IDE consomme plus de ressources CPU (mais qui s'en
soucie ?) </item>
<item> n'utilisez qu'<bf>un</bf> disque IDE par adaptateur sans quoi les
performances vont se dégrader.</item>
</itemize>
</item>
<item> <BF>Résistance aux pannes :</BF> le gestionnaire IDE survit
généralement à la défaillance d'un disque IDE. La couche RAID étiquetera
le disque comme défectueux et si vous employez du RAID-1 et au delà, la
machine devrait continuer à fonctionner normalement jusqu'à ce que vous
l'arrêtiez pour les opérations de maintenance. </item>
</itemize>
<P>
Il est <bf>très</bf> important que vous n'utilisiez <bf>qu'un</bf>
disque IDE par nappe. Outre la question des performances, la
défaillance d'un disque provoque généralement le blocage de l'interface.
Avec une configuration RAID qui supporte les défaillances (RAID-1, 4, 5),
la panne d'un disque est supportée mais l'arrêt simultané de deux
disques bloque la matrice. Un bus, un disque, telle est la règle.
<P>
Les contrôleurs PCI IDE ne manquent pas et vous pourrez vous procurer
deux à quatre bus supplémentaires autour de 600 FF. Au vu de la
différence de prix entre les disques SCSI et le disques IDE, je dirais qu'un
système RAID IDE est des plus attractifs si on est prêt à se cantonner
à un nombre de disques relativement peu important (autour de 8 à moins
que l'on ne dispose de suffisamment de connecteurs PCI).
<P>
L'IDE est limité par la longueur des cables lorsqu'il s'agit de mettre
en oeuvre des matrices importantes. Même si votre machine comprend
suffisament de connecteurs PCI il est peu probable que vous puissiez
loger plus de huit disques sans vous heurter à des problèmes de
corruption des données dus à la longueur des cables.
<P>
<sect1> Ajout et suppression de disque à chaud  :
<P>
Le sujet a effectivement chauffé la liste de diffusion linux-kernel il
y a quelques temps. Bien que la fonctionnalité soit présente dans une
certaine mesure, il ne s'agit pas de quelque chose de facile.
<P>
<sect2> Disques IDE
<P>
<bf>N'essayez pas</bf> de manipuler à chaud vos disques IDE !
L'IDE n'est pas prévu pour. Bien sûr, ça se passera peut-être
correctement chez vous si le gestionnaire IDE est compilé en tant que
module (vous utilisez donc un noyau 2.2 et au delà) et que vous le
rechargez une fois le disque remplacé mais vous pouvez tout aussi bien
vous retrouver avec un controleur IDE grillé. Le temps d'arrêt du
système en cas de problème n'aura alors pas grand chose à voir avec
celui d'une maintenance programmée.
<P>
Outre les aspects purement électriques qui détruiront joyeusement votre
matériel, le problème réside en ce que l'interface IDE doit être réexaminée
après que des disques soient échangés. Le gestionnaire IDE actuel ne le
permet pas. Si le nouveau disque est rigoureusement identique à l'ancien,
il se <em>peut</em> que cela fonctionne sans nouvel examen du bus mais,
franchement, vous êtes en train de tenter le diable.
<P>
<sect2> Disques SCSI
<P>
Le matériel SCSI n'est pas davantage prévu pour. Ca <em>peut</em>
néanmoins fonctionner. Si votre contrôleur SCSI est capable de
réexaminer le bus, d'autoriser l'ajout et la suppression de disques,
vous y arriverez peut-être. Je ne vous le conseille vraiment pas mais
ça peut fonctionner. Griller un disque neuf pousse parfois à revoir ses
façons de faire...
<P>
La couche SCSI <bf>devrait</bf> supporter la défaillance d'un disque
mais tous les gestionnaires SCSI n'en sont pas capables. Si le pilote
SCSI accompagne le disque défectueux, pouvoir échanger ce dernier à chaud
est inutile.
<P>
<sect2> SCA
<P>
L'échange à chaud doit être possible mais je ne dispose pas du matériel
nécessaire pour le vérifier et personne ne m'a fait part d'expériences
de ce type. Je ne peux donc pas vous en dire plus.
<P>
Si vous voulez essayer, il vous faudra connaitre le fonctionnement
interne du SCSI et du RAID. Je ne vais pas écrire quelque chose que je
ne peux pas vérifier mais juste vous donner quelques indications  :
<itemize>
<item> partez à la recherche de <BF>remove-single-device</BF> dans le
fichier <BF>linux/drivers/scsi/scsi.c</BF></item>
<item> jetez un oeil à <BF>raidhotremove</BF> et à <BF>raidhotadd</BF>
</itemize>
<P>
Tous les gestionnaires SCSI ne permettent pas l'ajout et la suppression
à chaud. Dans la série 2.2.x des noyaux, les pilotes Adaptec 2940 et
Symbios NCR53C8xx en semblent capables. Toute information concernant les
autres pilotes sera la bienvenue.
<P>
<sect> Configuration du RAID
<P>
<sect1> Configuration générale
<P>
Voici ce que requièrent tous les niveaux de RAID  :
<itemize>
<item> Un noyau, de préférence un 2.2.x ou le dernier 2.0.x. Si la
branche 2.4.x est disponible quand vous lirez ces lignes, servez
vous en.
<item> Les patches RAID. Ils existent généralement pour les noyaux
récents. Les noyaux 2.4.x ne nécessiteront pas de patch.
<item> Les utilitaires RAID.
<item> De la patience, des pizzas et des amph^H^H^H^H substances à la
caféine.
</itemize>
<P>
Tous les logiciels se trouvent sur &ftpkernel; Les outils et les patches
RAID sont dans le répertoire <TT>daemons/raid/alpha</TT>. Le noyau se
trouve dans le répertoire <TT>kernel</TT>.
<P>
Patchez le noyau, configurez le de façon à inclure la gestion du RAID
pour les niveaux qui vous intéressent. Compilez et installez.
<P>
Détarrez, configurez, compilez et installez les outils RAID.
<P>
Jusqu'ici, tout va bien. A présent, si vous redémarrez, vous devriez
avoir un fichier appelé &mdstat;. N'oubliez jamais que ce fichier est
votre allié. Examinez son contenu avec un <TT>cat </TT>&mdstat;.
Il devrait vous confirmer que vous disposez du niveau (personality)
RAID voulu et qu'aucun périphérique RAID n'est actif.
<P>
Créez les partitions que vous souhaitez inclure dans votre matrice RAID.
<P>
La suite des opérations dépend à présent du mode RAID.
<P>
<sect1> Mode linéaire
<P>
On dispose à présent de deux partitions (ou plus) qui ne sont pas
nécessairement de la même taille et que l'on va concaténer.
<P>
Editez le fichier &raidtab; de façon à correspondre à votre configuration.
Pour deux disques en mode linéaire, voici un fichier type  :
<P>
<verb>
raiddev /dev/md0
raid-level linear
nr-raid-disks 2
chunk-size 32
persistent-superblock 1
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
</verb>
On ne peut disposer de disques de secours. Si un disque tombe en panne,
toute la matrice s'effondre. Il n'y a rien à stocker sur un disque de
secours.
<P>
Vous vous demanderez peut-être pourquoi on précise un paramètre
<TT>chunk-size</TT> quand le mode linéaire ne fait que concaténer les
disques en un disque virtuel plus important sans y accéder en parallèle.
Vous avez tout à fait raison. Mettez y une valeur quelconque et pensez
à autre chose.
<P>
On crée la matrice  :
<verb>
mkraid /dev/md0
</verb>
<P>
La commande initialise la matrice, écrit les superblocs persistants
et active le périphérique.
<P>
Jetez un oeil à &mdstat;. Vous devriez y voir que la matrice fonctionne.
<P>
A présent créez un système de fichiers comme sur un périphérique
quelconque, montez le, incluez le dans votre fstab etc...
<P>
<sect1> RAID-0
<P>
On dispose de deux disques (ou davantage) de taille sensiblement égale
dont on veut additionner les capacités de stockage tout en en améliorant
les performances au moyen d'accès simultanés.
<P>
Editez le fichier &raidtab; de façon à correspondre à votre configuration.
Voici un fichier type  :
<verb>
raiddev /dev/md0
raid-level 0
nr-raid-disks 2
persistent-superblock 1
chunk-size 4
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
</verb>
Comme en mode linéaire, il n'y a pas de disque de secours. Le RAID-0
n'offre aucune redondance et la défaillance d'un disque signifie celle
de la matrice entière.
<P>
On exécute  :
<verb>
mkraid /dev/md0
</verb>
La commande initialise la matrice, écrit les superblocs persistants
et active la matrice.
<P>
/dev/md0 est prêt à être formaté, monté et à subir les pires outrages.
<P>
<sect1> RAID-1
<P>
On dispose de deux disques de taille sensiblement égale que l'on
souhaite mettre en mirroir. On peut avoir des disques supplémentaires
que l'on gardera en attente comme disques de secours et qui prendront
automatiquement place dans la matrice si un disque actif tombe en
panne.
<P>
Voici le fichier &raidtab; typique  :
<verb>
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
nr-spare-disks 0
chunk-size 4
persistent-superblock 1
device /dev/sdb6
raid-disk 0
device /dev/sdc5
raid-disk 1
</verb>
Pour prendre en compte des disques de secours  :
<verb>
device /dev/sdd5
spare-disk 0
</verb>
N'oubliez pas d'ajuster la variable nr-spare-disks en conséquence.
<P>
A présent, on peut initialiser la matrice RAID. Son contenu doit être
construit et les contenus des deux disques (sans importance pour
l'instant) synchronisés.
<P>
Exécutez  :
<verb>
mkraid /dev/md0
</verb>
L'initialisation de la matrice démarrera.
<P>
Examinez le fichier &mdstat;. On doit y lire que /dev/md0 a été démarré,
que le mirroir est en cours de reconstruction et y trouver une estimation
de la durée de reconstruction.
<P>
La reconstruction a lieu durant les périodes d'inactivité au niveau des
entrées/sorties. L'interactivité du système ne devrait donc pas en
souffrir. Les LED des disques palpiteront gaiement.
<P>
Le processus de reconstruction est transparent et on peut utiliser
le périphérique RAID pendant cette phase.
<P>
Formattez la matrice pendant la reconstruction. On peut également la monter
et s'en servir. Bien sûr, si le mauvais disque lache à ce moment là, il ne
s'agissait pas d'un jour de chance.
<P>
<sect1> RAID-4
<P>
<bf>Remarque :</bf> je n'ai pas testé personnellement cette
configuration et ce qui suit correspond à ce qui me paraît le plus
vraisemblable.
<P>
On dispose de trois disques ou plus de taille sensiblement équivalente,
l'un d'eux est nettement plus rapide que les autres et on souhaite les
combiner en un périphérique de taille plus élevée tout en conservant
un certain niveau de redondance. En outre, on peut introduire des disques
de secours.
<P>
Fichier /etc/raidtab typique  :
<verb>
raiddev /dev/md0
raid-level 4
nr-raid-disks 4
nr-spare-disks 0
persistent-superblock 1
chunk-size 32
device /dev/sdb1
raid-disk 0
device /dev/sdc1
raid-disk 1
device /dev/sdd1
raid-disk 2
device /dev/sde1
raid-disk 3
</verb>
Les disques de secours sont traités par les lignes suivantes  :
<verb>
device /dev/sdf1
spare-disk 0
</verb>
<P>
La matrice s'initialise comme d'habitude  :
<verb>
mkraid /dev/md0
</verb>
<P>
On se reportera aux options particulières de mke2fs avant de formater
le périphérique.
<P>
<sect1> RAID-5
<P>
On dispose de trois disques ou plus de taille sensiblement équivalente
que l'on veut combiner en un périphérique de taille plus élevée tout
en assurant la redondance des données. On peut introduire des disques de
secours.
<P>
Si on employe N disques dont le plus petit est de taille S, la taille de
la matrice sera (N-1)*S. L'espace manquant sert au stockage des données
de parité (redondance). Si un disque tombe en panne, les données restent
intactes. Si deux disques lachent, toutes les données sont perdues.
<P>
Fichier de configuration /etc/raidtab typique  :
<verb>
raiddev /dev/md0
raid-level 5
nr-raid-disks 7
nr-spare-disks 0
persistent-superblock 1
parity-algorithm left-symmetric
chunk-size 32
device /dev/sda3
raid-disk 0
device /dev/sdb1
raid-disk 1
device /dev/sdc1
raid-disk 2
device /dev/sdd1
raid-disk 3
device /dev/sde1
raid-disk 4
device /dev/sdf1
raid-disk 5
device /dev/sdg1
raid-disk 6
</verb>
Les disques de secours sont traités par les lignes suivantes  :
<verb>
device /dev/sdh1
spare-disk 0
</verb>
Et ainsi de suite.
<P>
Une taille de bloc (chunk-size) de 32 ko est un bon choix par défaut
pour de nombreux systèmes de fichiers. La matrice dérivée du fichier
de configuration précédent est de 7 fois 6 Go soit 36 Go (n'oubliez
pas que (n-1)*s = (7-1)*6 = 36). Il contient un système de fichiers ext2
avec une taille de blocs de 4 ko. Rien n'empèche d'aller au-delà via les
paramètres de bloc de la matrice et du système de fichiers si ce dernier
est plus grand ou s'il doit contenir des fichiers de grande taille.
<P>
A présent, on exécute  :
<verb>
mkraid /dev/md0
</verb>
Normalement les disques devraient s'activer furieusement durant la
construction de la matrice. On examinera le contenu du fichier &mdstat;
pour savoir ce qui se passe.
<P>
Si le périphérique a été créé avec succès, la reconstruction est en
cours. La matrice ne sera pas cohérente tant que celle-ci n'aura pas
pris fin. La matrice est cependant parfaitement opérationnelle (à la
gestion des défaillances près) et on peut déjà la formater et s'en
servir.
<P>
On se reportera aux options particulières de mke2fs avant de formatter
le périphérique.
<P>
Maintenant que le disque RAID fonctionne, on peut l'arrêter ou le
redémarrer via les commandes  :
<verb>
raidstop /dev/md0
</verb>
et
<verb>
raidstart /dev/md0
</verb>
<P>
Au lieu de mettre ces commandes dans les scripts d'initialisation et de
rebooter un milliard de fois pour arriver à tout faire fonctionner,
on lira les paragraphes suivants qui traitent de l'autodétection.
<P>
<sect1> Les superblocs persistants
<P>
Autrefois (TM), les utilitaires RAID analysaient le fichier de
configuration et initialisaient la matrice. Il fallait donc que le
système de fichiers sur lequel figurait le fichier &raidtab; soit
monté  : plutôt pénible pour démarrer sur un système de fichiers RAID.
<P>
L'ancienne approche conduisait de surcroît à des complications pour
monter des systèmes de fichiers reposant sur périphériques RAID. Ils ne
pouvaient être simplement mis dans le fichier &fstab; habituel et
nécessitaient des interventions chirurgicales dans les scripts de
démarrage.
<P>
Les superblocs persistants résolvent ces problèmes. Lorsqu'une matrice
est initialisée avec l'option <TT>persistent-superblock</TT> dans le
fichier &raidtab;, un superbloc de type particulier est écrit au début
de chaque disque prenant part à la matrice. Le noyau est alors capable
d'obtenir directement la configuration de la matrice depuis les disques
qui la composent au lieu de devoir analyser un fichier de configuration
à la disponibilité aléatoire.
<P>
On gardera quand même cohérent le fichier &raidtab; puisqu'on peut en
avoir besoin ultérieurement en cas de reconstruction de la matrice.
<P>
Les superblocs persistants sont obligatoires si on souhaite bénéficier
de l'auto-détection des périphériques RAID au démarrage du système.
On se reportera à la section <bf>Autodétection</bf>.
<P>
<sect1> Taille des blocs (chunk size)
<P>
Ce paramètre mérite quelques explications. On ne peut jamais écrire de
façon rigoureusement parallèle sur un ensemble de disques. Dans le cas
de deux disques sur lesquels on devrait écrire un octet, on pourrait
souhaiter que les quatres bits de poids fort aillent toujours sur le même
disque, ceux de poids faible allant sur l'autre. Le matériel ne le
permet pas. On définit donc de façon plus ou moins arbitraire une taille
de bloc élémentaire qui correspondra à la plus petite quantité de données
"atomique" qui sera écrite sur les disques. L'écriture de 16 ko avec une
taille de bloc de 4 ko provoquera l'envoi du premier et du troisième
bloc de 4 ko vers le premier disque et celui du deuxième et du quatrième
bloc vers le second disque pour une matrice RAID-0 comportant deux
disques. Pour de grosses écritures, la consommation de ressources sera
minimisée par une taille de blocs importante tandis qu'une matrice
composée essentiellement de petits fichiers profitera davantage d'une
taille de blocs réduite.
<P>
Ce paramètre peut être spécifié pour tous les niveaux de RAID, même le
mode linéaire où il n'a aucun effet.
<P>
A vous de modifier ce paramètre, ainsi que la taille de blocs du système
de fichier, pour obtenir les meilleurs performances possibles.
<P>
L'argument de l'option chunk-size dans le fichier &raidtab; précise
la taille en ko.
<P>
<sect2> RAID-0
<P>
Les données sont écrites successivement sur chaque disque par paquets
de <tt>chunk-size</tt> octets.
<P>
Pour une taille de bloc de 4 ko, lors de l'écriture de 16 ko de données
sur un système muni de trois disques, la couche RAID écrira simultanément
4 ko sur chacun des trois disques puis écrira les 4 ko restant sur le
disque 0.
<P>
32 ko semble un bon point de départ pour une majorité de matrices mais
la valeur optimale dépend étroitement du nombre de disques impliqués, du
contenu du système de fichiers et de divers autres facteurs. A vous
d'expérimenter pour trouver la meilleure valeur.
<P>
<sect2> RAID-1
<P>
Pour les écritures le paramètre importe peu vu que les données doivent
être écrites sur tous les disques. Cependant, pour les lectures, il fixe
la quantité de données à lire en une fois depuis un disque. Tous les
disques contenant la même information, les lectures peuvent être
équilibrées d'une façon similaire au RAID-0.
<P>
<sect2> RAID-4
<P>
Lors d'une écriture dans une matrice RAID-4, l'information de parité
doit être mise à jour sur le disque dédié. La taille de bloc spécifie
alors la taille des blocs de parité. Si un octet est écrit dans une
matrice RAID-4, <tt>chunk-size</tt> octets seront lus depuis N-1 disques,
la parité sera calculée et <tt>chunk-size</tt> octets seront écrits sur
le disque de parité.
<P>
Le paramète affecte les performances de la même façon que pour le RAID-0
puisque les lectures fonctionnent de la même façon.
<P>
<sect2> RAID-5
<P>
Le paramètre a la même signification que pour le RAID-4.
<P>
128 ko est une valeur raisonnable. A vous de l'ajuster.
<P>
On se reportera également à la section traitant des options particulières
de mke2fs qui affectent les performances du RAID-5.
<P>
<sect1> Options de mke2fs
<P>
L'option <tt>-R stride=nn</tt> permet à mke2fs d'optimiser l'emplacement
des structures de contrôle spécifiques à ext2 lors du formatage d'un
disque RAID-4 ou RAID-5.
<P>
Si la taille de bloc RAID est de 32 ko, 32 ko de données consécutives
résideront sur un même disque. Si on souhaite construire un systéme de
fichiers ext2 avec une taille de blocs de 4 ko, il y aura 8 blocs de
données consécutifs dans un bloc du tableau. On fournit l'information
à mke2fs de la manière suivante  :
<verb>
mke2fs -b 4096 -R stride=8 /dev/md0
</verb>
<P>
Les performances du RAID-{4,5} dépendent fortement de cette option.
Je ne suis pas sûr de son influence sur les autres niveaux RAID.
Si quelqu'un a des informations à ce sujet, elles seront les bienvenues.
<P>
La taille de bloc ext2 joue <tt>très</tt> fortement sur les performances
du système de fichier. Dès que la taille de ce dernier dépasse quelques
centaines de Mo, une taille de bloc de 4 ko est conseillée (à moins que
le système de fichiers ne doivent stocker de très nombreux petits fichiers).
<P>
<sect1> Autodétection
<P>
L'autodétection permet une reconnaissance automatique des périphériques
par le noyau au démarrage, jsute après l'identification des partitions
usuelles.
<P>
Requis  :
<ENUM>
<item>La gestion de l'autodétection par le noyau.
<item>Les disques RAID doivent avoir été créés avec l'option de persistance
des superblocs.
<item>Les partitions doivent être de type <BF>0xFD</BF> (à positionner
avec fdisk).
</ENUM>
<P>
Remarque  : on vérifiera que la matrice RAID est arrêtée avant de
changer le type des partitions (<tt>raidstop /dev/md0</tt>).
<P>
En suivant les trois étapes précédentes, l'autodétection devrait être en
place. Essayez de redémarrer. Une fois le système initialisé, &mdstat;
doit confirmer que la matrice RAID fonctionne.
<P>
Des messages semblables aux suivants apparaitront au démarrage  :
<verb>
Oct 22 00:51:59 malthe kernel: SCSI device sdg: hdwr sector= 512
bytes. Sectors= 12657717 [6180 MB] [6.2 GB]
Oct 22 00:51:59 malthe kernel: Partition check:
Oct 22 00:51:59 malthe kernel: sda: sda1 sda2 sda3 sda4
Oct 22 00:51:59 malthe kernel: sdb: sdb1 sdb2
Oct 22 00:51:59 malthe kernel: sdc: sdc1 sdc2
Oct 22 00:51:59 malthe kernel: sdd: sdd1 sdd2
Oct 22 00:51:59 malthe kernel: sde: sde1 sde2
Oct 22 00:51:59 malthe kernel: sdf: sdf1 sdf2
Oct 22 00:51:59 malthe kernel: sdg: sdg1 sdg2
Oct 22 00:51:59 malthe kernel: autodetecting RAID arrays
Oct 22 00:51:59 malthe kernel: (read) sdb1's sb offset: 6199872
Oct 22 00:51:59 malthe kernel: bind<sdb1,1>
Oct 22 00:51:59 malthe kernel: (read) sdc1's sb offset: 6199872
Oct 22 00:51:59 malthe kernel: bind<sdc1,2>
Oct 22 00:51:59 malthe kernel: (read) sdd1's sb offset: 6199872
Oct 22 00:51:59 malthe kernel: bind<sdd1,3>
Oct 22 00:51:59 malthe kernel: (read) sde1's sb offset: 6199872
Oct 22 00:51:59 malthe kernel: bind<sde1,4>
Oct 22 00:51:59 malthe kernel: (read) sdf1's sb offset: 6205376
Oct 22 00:51:59 malthe kernel: bind<sdf1,5>
Oct 22 00:51:59 malthe kernel: (read) sdg1's sb offset: 6205376
Oct 22 00:51:59 malthe kernel: bind<sdg1,6>
Oct 22 00:51:59 malthe kernel: autorunning md0
Oct 22 00:51:59 malthe kernel: running: <sdg1><sdf1><sde1><sdd1><sdc1><sdb1>
Oct 22 00:51:59 malthe kernel: now!
Oct 22 00:51:59 malthe kernel: md: md0: raid array is not clean --
starting background reconstruction
</verb>
Il s'agit des messages à l'autodétection des partitions d'une matrice
RAID-5 qui n'a pas été arrêtée correctement (la machine a planté).
La reconstruction a lieu spontanément. Le montage de l'unité est
parfaitement licite puisque la reconstruction est transparente et que
toutes les données sont cohérentes (seule l'information de parité qui
ne sert qu'en cas de défaillance d'un disque est incohérente).
<P>
Les périphériques reconnus automatiquement sont stoppés de même quand le
système s'arrête. Oubliez les scripts d'initialisation et servez vous des
disques /dev/md comme s'il s'agissait de /dev/sd ou /dev/hd.
<P>
C'est aussi simple que ça.
<P>
Les lignes comportant les commandes raidstart et raidstop dans les
scripts d'initialisation ne servent que pour les matrices RAID qui
reposent sur l'ancienne mouture du code. Elles peuvent être supprimées
sans hésitation dans le cadre de matrices RAID qui ont recours à
l'autodétection.
<P>
<sect1> Démarrage sur un disque RAID
<P>
Il existe plusieurs façons de mettre en place un système qui monte
directement sa partition racine depuis un périphérique RAID. Pour
l'instant, seuls les outils d'installation graphiques de la RedHat 6.1
permettent l'installation directe sur une matrice RAID. Il vous faudra
donc surement effectuer quelques manipulations à la main mais il n'y a
là rien d'impossible.
<P>
La dernière version officielle de lilo (21) ne gère pas les disques
RAID et le noyau ne peut donc pas être chargé au démarrage depuis ce
genre de périphériques. Il faudra donc que le répertoire <tt>/boot</tt>
réside sur un système de fichier hors RAID. Afin d'être sûr que le
système démarre quel que soit son état, dupliquez une partition
<tt>/boot</tt> similaire sur chaque disque. Le BIOS sera ainsi
toujours capable de charger les données depuis, par exemple le premier
disque disponible. Il faudra donc que le système ne démarre pas avec un
disque défectueux.
<P>
Avec la RedHat 6.1 est fourni un patch pour lilo 21 qui permet d'accéder
à <tt>/boot</tt> sur du RAID-1. On notera que le patch n'est pas adapté
aux autres niveaux RAID. Le patch est disponible dans tous les mirroirs
RedHat via <tt> dist/redhat-6.1/SRPMS/SRPMS/lilo-0.21-10.src.rpm</tt>.
La version modifiée de lilo acceptera un argument du type
<tt>boot=/dev/md0</tt> dans le fichier <tt>/etc/lilo.conf</tt> et
rendra chaque disque du mirroir utilisable au dénarrage.
<P>
On peut également avoir recours à une disquette de démarrage.
<P>
<sect1> Installer le système de fichiers racine sur une couche RAID
<P>
Deux méthodes sont fournies ci-dessous. A ma connaissance, aucune
distribution ne permet l'installation sur un disque RAID et la
méthode que je suggère suppose que vous installez d'abord le système
sur une partition normale avant de mouvoir les fichiers sur la matrice
RAID une fois l'installation complète.
<P>
<sect2> Première méthode  :
<P>
On dispose d'un disque supplémentaire où on peut installer le système.
<P>
<itemize>
<item> Installez un système normal sur le disque supplémentaire. </item>
<item> Mettez en place un noyau incluant les patches nécessaires pour le
RAID et vérifiez que le système s'initialise correctement avec ce noyau.
Il faudra veiller à ce que le support RAID soit <bf>dans</bf> le
noyau et non sous forme de modules. </item>
<item> A présent, configurez et créez la matrice RAID dont vous comptez vous
servir en tant que racine. Il s'agit de la procédure standard telle que
décrite précédemment dans le document. </item>
<item> Redémarrez le système afin de vérifier que la matrice est détectée
correctement (elle devrait en tout cas). </item>
<item> Créez un système de fichier sur la nouvelle matrice avec mke2fs et
montez la en /mnt/newroot (par exemple). </item>
<item> Copiez le contenu de la racine courante sur le disque RAID. Il existe
différentes façons de faire, par exemple  :
<verb>
cd /
find . -xdev | cpio -pm /mnt/newroot
</verb></item>
<item> modifiez le fichier <TT>/mnt/newroot/etc/fstab</TT> de façon à ce
qu'il pointe vers le périphérique <tt>/dev/md?</tt> adéquat pour la
racine. </item>
<item> Démontez le répertoire <tt>/boot</tt> courant et montez le à la
place en <tt>/mnt/newroot/boot</tt>. </item>
<item> Mettez à jour <tt>/mnt/newroot/etc/lilo.conf</tt> de façon à
pointer vers le bon périphérique. Le périphérique de boot doit
rester un disque normal (non-RAID) mais le disque racine doit pointer
vers la matrice RAID. Ceci fait, exécutez un
<verb>lilo -r /mnt/newroot</VERB>. Lilo ne devrait pas émettre
d'erreurs. </item>
<item> Redémarrez le système et admirez avec quel facilité tout se passe
comme on le souhaite :o) </item>
</itemize>
<P>
Dans le cas de disques IDE, on spécifiera dans le BIOS les disques comme
étant de type ``auto-detect'' pour que la machine puisse redémarrer même
si un disque manque.
<P>
<sect2> Seconde méthode  :
<P>
Cette méthode nécessite l'emploi d'outils RAID et du patch qui autorisent
la directive failed-disk. Il faut donc disposer d'un noyau 2.2.10 ou au delà.
<P>
Il <bf>faut</bf> que la matrice soit au moins de type 1. L'idée consiste
à installer le système sur un disque marqué défectueux du point de vue RAID
puis à copier le système sur la partie restante de la matrice RAID qui
sera considérée comme dégradée avant de réinsérer le disque d'installation
et de déclencher sa resynchronisation.
<P>
<itemize>
<item> Installez un système normal sur un des deux disques (qui fera plus
tard partie de la matrice). Il est important que ce disque ne soit pas le
plus petit sans quoi il ne sera pas possible de l'ajouter à la matrice !
<item> Récupérez le noyau, le patch, les outils, etc... Redémarrez le
système avec le noyau qui est muni de la gestion RAID.
<item> Créez votre matrice en indiquant le disque qui occupe la racine
actuelle comme <tt>failed-disk</tt> dans le fichier <tt>raidtab</tt>
Ne mettez pas ce disque en première position dans le fichier ou vous
aurez du mal à démarrer la matrice. Activez la matrice et mettez y un
système de fichiers.
<item> Redémarrez et vérifiez que la matrice RAID est correctement activée.
<item> Copiez les fichiers de la racine et modifiez les fichiers système du
disque RAID de façon à ce qu'il se référence bien en tant que racine.
<item> Lorsque le système démarre correctement depuis le disque RAID,
modifiez le fichier <tt>raidtab</tt> en emplaçant la directive
<tt>failed-disk</tt> par une directive <tt>raid-disk</tt>. Ajoutez à
présent ce disque à la matrice avec <tt>raidhotadd</tt>
<item> Le système doit à présent démarrer depuis une matrice non-dégradée.
</itemize>
<P>
<sect1> Démarrer le système depuis le RAID
<P>
Pour que le noyau soit capable de monter le système de fichiers racine,
les pilotes des périphériques nécessaires doivent être présents dans le
noyau (NdT : ou chargés via un initrd qui peut également contenir les
modules RAID).
<P>
La façon normale de procéder consiste à compiler un noyau qui inclut en
dur toutes les options RAID nécessaires (NdT : je proteste !).
<P>
La redHat-6.0 étant fournie avec un noyau modulaire qui gère la nouvelle
mouture du RAID, je vais cependant en décrire l'emploi si on souhaite s'en
servir pour démarrer son systéme depuis un volume RAID.
<P>
<sect2> Démarrage avec le RAID modularisé
<P>
Il faut préciser à lilo qu'il doit également charger un équivalent de
ramdisk en sus du noyau au démarrage. La commande <tt>mkinitrd</tt>
permet de créer un ramdisk (ici un initrd) contenant les modules
nécessaires au montage de la racine. Commande type  :
<verb>
mkinitrd --with=<module> <ramdisk name> <kernel>
</verb>
Par exemple  :
<verb>
mkinitrd --with=raid5 raid-ramdisk 2.2.5-22
</verb>
<P>
Ceci garantit que le module RAID adéquat sera disponible au démarrage
lorsque le noyau devra monter la racine.
<P>
<sect1> Mises en garde
<P>
Ne repartitionnez <bf>JAMAIS</bf> un disque qui appartient à une matrice
RAID. Si vous devez modifier la table des partitions d'un disque au sein
d'une matrice, arrêtez d'abord la matrice et repartitionnez ensuite.
<P>
On a vite fait de saturer un bus. Un bus Fast-Wide SCSI courant n'offre
que 10 Mo/s, ce qui est largement en dessous des performances des
disques actuels. Mettre six disques sur un canal de ce type n'apportera
bien entendu pas le gain en performances souhaité.
<P>
L'ajout de contrôleurs SCSI n'est susceptible d'améliorer les performances
que si les bus déjà présents sont proches de la saturation. Vous ne
tirerez rien de plus de deux contrôleurs 2940 si vous n'avez que deux
vieux disques SCSI qui ne satureraient même pas un seul contrôleur.
<P>
Si vous omettez l'option de persistance des superblocs votre matrice ne
redémarrera pas spontanément après un arrêt. Reprenez la création de la
matrice avec l'option correctement positionnée.
<P>
Si la resynchronisation d'une matrice RAID-5 échoue après qu'un disque
ait été oté puis reinséré, l'ordre des disques dans le fichier
raidtab est peut-être le responsable. Essayez de déplacer la première
paire ``device ...'' et ``raid-disk ...'' en début de description de la
matrice.
<P>
La plupart des retours d'erreur observés sur la liste de diffusion
linux-kernel proviennent de gens qui ont procédé à des mélanges douteux
entre les patches et les outils RAID. Si vous utilisez le RAID 0.90,
vérifiez que vous vous servez bien de la bonne version des utilitaires.
<P>
<sect> Test de la couche RAID
<P>
Si vous utilisez le RAID pour améliorer la tolérance aux pannes,
vous voudrez surement tester votre installation afin de vérifier
son fonctionnement. Comment simule-t-on donc une défaillance ?
<P>
En résumé, on ne peut pas à moins de titiller un disque au lance-flammes
pour "simuler" une défaillance. On ne peut pas prévoir ce qui va se passer
en cas de perte d'un disque. Il pourrait très bien verouiller
électriquement le bus et rendre tous les disques sur le bus inaccessibles.
Je n'ai néanmoins jamais entendu d'histoire de ce genre. Le disque signalera
peut-être une erreur de lecture/écriture à la couche IDE ou SCSI qui permettra
à son tour à la couche RAID de gérer la situation avec élégance.
Heureusement, les choses se passent assez souvent ainsi.
<P>
<sect1> Défaillance d'un disque
<P>
Débranchez le disque. Ceci n'est à faire qu'avec le système
<bf>hors-tension </bf>. Inutile de jouer les aventuriers de
l'ajout/suppression à chaud pour vérifier que les données supportent bien
la disparition d'un disque. Arrêtez le système, débranchez le disque et
redémarrez le de nouveau.
<P>
Syslog et &mdstat; permettent de vérifier l'état de la matrice.
<P>
N'oubliez pas que vous <bf>devez</bf> employer du RAID-{1,4,5} pour
que la matrice soit capable de supporter la défaillance d'un disque.
Les modes linéaire et RAID-0 échouent complètement dans ce genre de
situation.
<P>
Une fois le disque rebranché (avec le courant arrêté, merci), on ajoutera
le ``nouveau'' disque au système RAID avec la commande <tt>raidhotadd</tt>.
<P>
<sect1> Corruption de données
<P>
Le RAID, qu'il soit matériel ou logiciel, suppose que si une écriture
ne renvoie pas une erreur, alors elle s'est déroulée normalement. Donc,
si un diseue corrompt les données sans retourner d'erreur, les données
<em>seront</em> corrompues. Bien que ce soit fortement improbable, on ne
peut l'exclure et cela aura pour conséquence la corruption du système de
fichiers.
<P>
Le RAID ne peut rien faire face à ce genre de défaillances et il n'a
pas été prévu pour de toutes façons. Il est donc inutile de déclencher
sciemment des corruptions de données (avec <tt>dd</tt> par exemple) pour
vérifier le comportement de la couche RAID. A moins de modifier le
superbloc RAID, il est vraisemblable que la couche RAID ne remarque
rien mais que le système de fichiers soit détruit.
<P>
Il s'agit du fonctionnement normal du système. Le RAID ne garantit pas
l'intégrité des données. Il permet juste de les conserver si un disque
tombe en panne (pourvu qu'on utilise un niveau de RAID supérieur ou égal
à 1).
<P>
<sect> Reconstruction
<P>
Si vous avez lu le reste du document, vous devez déjà avoir une bonne
idée de la procédure à suivre pour la reconstruction d'une matrice
dégradée. Pour résumer  :
<itemize>
<item> Arrêtez le système.
<item> Remplacez le disque défectueux.
<item> Redémarrez le système.
<item> Utilisez <TT>raidhotadd /dev/mdX /dev/sdX</TT> pour réinsérer le
disque dans la matrice.
<item> Allez prendre un café pendant que la reconstruction s'effectue.
</itemize>
C'est tout.
<P>
Enfin, c'est généralement tout. Sauf si vous jouez de malchance et
que le système RAID est devenu inutilisable à cause de la défaillance
de plus de disques qu'il n'y en a de redondant. Ca risque de se
produire si plusieurs disques résident sur un même bus qui est bloqué par
le disque en panne. Bien qu'en état, les autres disques sur le bus vont
être inaccessibles à la couche RAID et marqués comme défectueux. Pour une
matrice RAID5 où on peut utiliser un disque en secours, la perte de deux
disques ou davantage risque de s'avérer fatale.
<P>
La section suivante est tirée d'une explication que m'a donnée Martin Bene
et présente une méthode possible de récupération dans le cas d'un scénario
catastrophe tel que celui décrit. Elle implique l'emploi de la directive
<tt>failed-disk</tt> dans le fichier &raidtab;. Elle ne pourra donc
fonctionner qu'avec un noyau 2.2.10 et au delà.
<P>
<sect1> Rattrapage d'une défaillance de plusieurs disques
<P>
Scénario  :
<itemize>
<item> un contrôleur rend l'âme et bloque simultanément l'accès à deux
disques ;
<item> tous les disques d'un même bus SCSI sont bloqués à cause d'un même
disque défectueux ;
<item> un cable s'envole pour le grand centre de traitement automatisé.
</itemize>
En bref  : le plus souvent, une panne <em>temporaire</em> se produit sur
plusieurs disques. Les superblocs RAID sont désynchronisés et la matrice
RAID refuse de s'initialiser.
<P>
Une seule chose à faire  : reécrire les superblocs RAID via
<tt>mkraid --force</tt>.
<P>
Pour que ça marche, le fichier &raidtab ; doit être à jour. S'il ne
correspond pas <bf>exactement</bf> à l'organisation des disques et à
leur ordre, ça ne marchera pas.
<P>
Examinez la sortie de syslog produite lors de la tentative de démarrage
de la matrice, vous y releverez le compteur d'évenements pour chaque
superbloc. En général, il vaut mieux laisser de côté le disque avec
le compteur le plus faible, c'est à dire le plus ancien.
<P>
Si vous exécutez <tt>mkraid</tt> sans la directive <tt>failed-disk</tt>,
le thread de récupération va se mettre à fonctionner immédiatement et
commencer à reconstruire les blocs de parité - ce qui est surement un
peu prématuré.
<P>
Avec <tt>failed-disk</tt>, vous préciserez quels disques vous souhaitez
voir actifs et essaierez peut-être différentes combinaisons pour obtenir
les meilleurs résultats. Pendant la reconstruction, ne montez le système
de fichier qu'en lecture seule. J'ai été en contact avec deux
personnes qui s'en sont sorties ainsi.
<P>
<sect> Performances
<P>
Cette partie offre quelques évaluations de performances issues de tests
de systèmes employant le RAID.
<P>
Les tests ont été conduits avec <tt>bonnie</tt> et à chaque fois sur
des fichiers de taille égale à deux fois ou plus celle de la mémoire
physique de la machine.
<P>
Ces tests ne mesurent <em>que</em> la bande passante en lecture/écriture
pour un seul fichier de grande taille. On ne sait donc rien des
performances qu'on observerait avec un serveur web, un serveur de news,
etc... Peu d'applications du monde réel font la même chose que
<tt>bonnie</tt> et bien que ce genre de nombres soit agréable à regarder,
il ne s'agit pas d'indicateurs de performances pour de véritables
applications. On en est loin.
<P>
Concernant ma machine  :
<itemize>
<item> Bi-Pentium Pro 150 MHz</ITEM>
<item> 256 Mo RAM (60 MHz EDO)</ITEM>
<item> trois IBM UltraStar 9ES 4.5 GB, SCSI U2W</ITEM>
<item> Adaptec 2940U2W</ITEM>
<item> un IBM UltraStar 9ES 4.5 GB, SCSI UW</ITEM>
<item> Adaptec 2940 UW</ITEM>
<item> un noyau 2.2.7 avec les patches RAID</ITEM>
</itemize>
<P>
Les trois disques U2W sont connectés au contrôleur U2W et le disque
UW au contrôleur UW.
<P>
Avec ou sans RAID, il ne semble pas possible de tirer plus de 30 Mo/s
du bus SCSI sur cette machine. Je soupçonne que cela vienne de la
vétusté de ce dernier et de la limitation de la bande passante de la
mémoire (Nd : pardon ?).
<P>
<sect1> RAID-0
<P>
<BF>Lecture</BF> correspond à <BF>Sequential block input</BF>, et
<BF>Ecriture</BF> à <BF>Sequential block output</BF>. La taille du fichier
était de 1 Go pour tous les tests. Les test ont eu lieu en mono-utilisateur.
Le gestionnaire SCSI était configuré de façon à ne pas utiliser la queue
de commands SCSI.
<P>
<TABLE>
<TABULAR CA="|l|l|l|l|">
Chunk size | Block size | Lecture ko/s | Ecriture ko/s @@
4k | 1k | 19712 | 18035 @
4k | 4k | 34048 | 27061 @
8k | 1k | 19301 | 18091 @
8k | 4k | 33920 | 27118 @
16k | 1k | 19330 | 18179 @
16k | 2k | 28161 | 23682 @
16k | 4k | 33990 | 27229 @
32k | 1k | 19251 | 18194 @
32k | 4k | 34071 | 26976
</TABULAR>
</TABLE>
<P>
A la lecture de ce tableau il semble que le paramètre chunk-size du RAID
n'ait pas un impact important. Néanmoins, la taille de bloc pour ext2 a
intérêt à être aussi élevée que possible, soit 4 ko (i.e. la taille d'une
page) avec une architecture IA32.
<P>
<sect1> RAID-0 avec queue de commandes SCSI (TCQ)
<P>
La queue de commandes est cette fois-ci activée avec une profondeur
égale à 8. Le reste est inchangé.
<P>
<TABLE>
<TABULAR CA="|l|l|l|l|">
Chunk size | Block size | Lecture ko/s | Ecriture ko/s @@
32k | 4k | 33617 | 27215
</TABULAR>
</TABLE>
<P>
Aucun autre test n'a été mené. L'emploi de la queue de commandes améliore
les performances en écriture mais la différence n'est pas énorme.
<P>
<sect1> RAID-5
<P>
On reprend les mêmes tests.
<P>
<TABLE>
<TABULAR CA="|l|l|l|l|">
Chunk size | Block size | Lecture ko/s | Ecriture ko/s @@
8k | 1k | 11090 | 6874 @
8k | 4k | 13474 | 12229 @
32k | 1k | 11442 | 8291 @
32k | 2k | 16089 | 10926 @
32k | 4k | 18724 | 12627
</TABULAR>
</TABLE>
<P>
Les deux paramètres semblent jouer.
<P>
<sect1> RAID-10
<P>
On désigne sous ce terme la mise en mirroir de disques concaténés ou un
RAID-1 au dessus d'un RAID-0. La taille de bloc est commune à tous les
disques RAID. Je n'ai pas procédé à des tests avec des tailles différentes
bien qu'il s'agisse là d'une configuration tout à fait licite.
<P>
<TABLE>
<TABULAR CA="|l|l|l|l|">
Chunk size | Block size | Lecture ko/s | Ecriture ko/s @@
32k | 1k | 13753 | 11580 @
32k | 4k | 23432 | 22249
</TABULAR>
</TABLE>
<P>
Il n'y a pas eu d'autres tests. La taille des fichiers était de 900 Mo
car les partitions n'offraient que 500 Mo chacune, ce qui ne suffit pas
pour un fichier de 1 Go dans cette configuration (RAID-1 de deux matrices
de 1000 Mo).
<P>
<sect> Remerciements
<P>
Les personnes suivantes ont contribué à la création de ce document  :
<itemize>
<item> Ingo Molnar
<item> Jim Warren
<item> Louis Mandelstam
<item> Allan Noah
<item> Yasunori Taniike
<item> Martin Bene
<item> Bennett Todd
<item> les abonnés de la liste de diffusion Linux-RAID
<item> ceux que j'ai oublié, désolé :o)
</itemize>
<P>
Envoyez vos remarques et suggestions à l'auteur de ce document. Il n'y a pas
d'autre façon d'en améliorer la qualité.
</ARTICLE>
