Voici ce que requièrent tous les niveaux de RAID :
Tous les logiciels se trouvent sur ftp://ftp.fi.kernel.org/pub/linux Les outils et les patches
RAID sont dans le répertoire daemons/raid/alpha. Le noyau se
trouve dans le répertoire kernel.
Patchez le noyau, configurez le de façon à inclure la gestion du RAID pour les niveaux qui vous intéressent. Compilez et installez.
Détarrez, configurez, compilez et installez les outils RAID.
Jusqu'ici, tout va bien. A présent, si vous redémarrez, vous devriez
avoir un fichier appelé /proc/mdstat. N'oubliez jamais que ce fichier est
votre allié. Examinez son contenu avec un cat /proc/mdstat.
Il devrait vous confirmer que vous disposez du niveau (personality)
RAID voulu et qu'aucun périphérique RAID n'est actif.
Créez les partitions que vous souhaitez inclure dans votre matrice RAID.
La suite des opérations dépend à présent du mode RAID.
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.
Editez le fichier /etc/raidtab de façon à correspondre à votre configuration.
Pour deux disques en mode linéaire, voici un fichier type :
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
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.
Vous vous demanderez peut-être pourquoi on précise un paramètre
chunk-size 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.
On crée la matrice :
mkraid /dev/md0
La commande initialise la matrice, écrit les superblocs persistants et active le périphérique.
Jetez un oeil à /proc/mdstat. Vous devriez y voir que la matrice fonctionne.
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...
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.
Editez le fichier /etc/raidtab de façon à correspondre à votre configuration.
Voici un fichier type :
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
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.
On exécute :
mkraid /dev/md0La commande initialise la matrice, écrit les superblocs persistants et active la matrice.
/dev/md0 est prêt à être formaté, monté et à subir les pires outrages.
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.
Voici le fichier /etc/raidtab typique :
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
Pour prendre en compte des disques de secours :
device /dev/sdd5
spare-disk 0
N'oubliez pas d'ajuster la variable nr-spare-disks en conséquence.
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.
Exécutez :
mkraid /dev/md0L'initialisation de la matrice démarrera.
Examinez le fichier /proc/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.
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.
Le processus de reconstruction est transparent et on peut utiliser le périphérique RAID pendant cette phase.
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.
Remarque : je n'ai pas testé personnellement cette configuration et ce qui suit correspond à ce qui me paraît le plus vraisemblable.
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.
Fichier /etc/raidtab typique :
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
Les disques de secours sont traités par les lignes suivantes :
device /dev/sdf1
spare-disk 0
La matrice s'initialise comme d'habitude :
mkraid /dev/md0
On se reportera aux options particulières de mke2fs avant de formater le périphérique.
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.
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.
Fichier de configuration /etc/raidtab typique :
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
Les disques de secours sont traités par les lignes suivantes :
device /dev/sdh1
spare-disk 0
Et ainsi de suite.
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.
A présent, on exécute :
mkraid /dev/md0Normalement les disques devraient s'activer furieusement durant la construction de la matrice. On examinera le contenu du fichier
/proc/mdstat
pour savoir ce qui se passe.
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.
On se reportera aux options particulières de mke2fs avant de formatter le périphérique.
Maintenant que le disque RAID fonctionne, on peut l'arrêter ou le redémarrer via les commandes :
raidstop /dev/md0et
raidstart /dev/md0
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.
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 /etc/raidtab soit
monté : plutôt pénible pour démarrer sur un système de fichiers RAID.
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 /etc/fstab habituel et
nécessitaient des interventions chirurgicales dans les scripts de
démarrage.
Les superblocs persistants résolvent ces problèmes. Lorsqu'une matrice
est initialisée avec l'option persistent-superblock dans le
fichier /etc/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.
On gardera quand même cohérent le fichier /etc/raidtab puisqu'on peut en
avoir besoin ultérieurement en cas de reconstruction de la matrice.
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 Autodétection.
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.
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.
A vous de modifier ce paramètre, ainsi que la taille de blocs du système de fichier, pour obtenir les meilleurs performances possibles.
L'argument de l'option chunk-size dans le fichier /etc/raidtab précise
la taille en ko.
Les données sont écrites successivement sur chaque disque par paquets
de chunk-size octets.
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.
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.
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.
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, chunk-size octets seront lus depuis N-1 disques,
la parité sera calculée et chunk-size octets seront écrits sur
le disque de parité.
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.
Le paramètre a la même signification que pour le RAID-4.
128 ko est une valeur raisonnable. A vous de l'ajuster.
On se reportera également à la section traitant des options particulières de mke2fs qui affectent les performances du RAID-5.
L'option -R stride=nn 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.
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 :
mke2fs -b 4096 -R stride=8 /dev/md0
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.
La taille de bloc ext2 joue très 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).
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.
Requis :
Remarque : on vérifiera que la matrice RAID est arrêtée avant de
changer le type des partitions (raidstop /dev/md0).
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é, /proc/mdstat
doit confirmer que la matrice RAID fonctionne.
Des messages semblables aux suivants apparaitront au démarrage :
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 reconstructionIl 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).
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.
C'est aussi simple que ça.
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.
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.
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 /boot
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
/boot 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.
Avec la RedHat 6.1 est fourni un patch pour lilo 21 qui permet d'accéder
à /boot 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 dist/redhat-6.1/SRPMS/SRPMS/lilo-0.21-10.src.rpm.
La version modifiée de lilo acceptera un argument du type
boot=/dev/md0 dans le fichier /etc/lilo.conf et
rendra chaque disque du mirroir utilisable au dénarrage.
On peut également avoir recours à une disquette de démarrage.
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.
On dispose d'un disque supplémentaire où on peut installer le système.
cd / find . -xdev | cpio -pm /mnt/newroot
/mnt/newroot/etc/fstab de façon à ce
qu'il pointe vers le périphérique /dev/md? adéquat pour la
racine. /boot courant et montez le à la
place en /mnt/newroot/boot. /mnt/newroot/etc/lilo.conf 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
lilo -r /mnt/newroot. Lilo ne devrait pas émettre d'erreurs.
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.
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à.
Il faut 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.
failed-disk dans le fichier raidtab
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.raidtab en emplaçant la directive
failed-disk par une directive raid-disk. Ajoutez à
présent ce disque à la matrice avec raidhotadd
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).
La façon normale de procéder consiste à compiler un noyau qui inclut en dur toutes les options RAID nécessaires (NdT : je proteste !).
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.
Il faut préciser à lilo qu'il doit également charger un équivalent de
ramdisk en sus du noyau au démarrage. La commande mkinitrd
permet de créer un ramdisk (ici un initrd) contenant les modules
nécessaires au montage de la racine. Commande type :
mkinitrd --with=<module> <ramdisk name> <kernel>Par exemple :
mkinitrd --with=raid5 raid-ramdisk 2.2.5-22
Ceci garantit que le module RAID adéquat sera disponible au démarrage lorsque le noyau devra monter la racine.
Ne repartitionnez JAMAIS 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.
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é.
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.
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.
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.
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.