Retrouvez cet article dans : Linux Magazine Hors série 18

Alors que des distributions comme Red Hat, ou encore SUSE (ex-SuSE), proposent l’installation directe sur du RAID logiciel, la distribution Debian se voit souvent taxée de retardataire en la matière. Cet article a pour but de présenter une méthode simple pour installer un système Debian GNU/Linux standard puis basculer sur du RAID logiciel.

Les explications qui vont suivre reposent sur l’installation d’une distribution Debian Sarge (actuellement testing) mais sont, à mon goût, très facilement adaptables à n’importe quelle distribution.

Cela inclut les distributions “sources” et, avec un peu de bonne volonté, les installations reposant sur LFS. Les quelques outils nécessaires pour basculer sont intégrés à toutes les distributions sous un nom ou un autre, tout comme les outils de gestion du RAID logiciel présentés dans l’article précédent.
La méthode qui va suivre s’inspire grossièrement des explications données (en allemand) par Marcus Schopen permettant d’installer Debian Woody sur du RAID logiciel. Une bonne partie des manipulations a cependant été revue et personnalisée et Marcus ne devra, bien sûr, être tenu aucunement responsable d’éventuelles erreurs dans le texte qui va suivre.

Pensez à fragmenter le système en partitions de taille raisonnable correspondant à vos besoins

Installation du système

Je considère ici que vous avez pris les dispositions matérielles qui s’imposent quant à l’installation du système.
Je parle, entre autres choses, de la nécessité d’utiliser deux contrôleurs différents pour les éléments du RAID et, bien sûr, des disques de taille identique.
Ce dernier point n’est pas capital puisque le RAID logiciel s’adaptera en fonction du disque (ou partition) le plus petit.
Il serait cependant idiot de perdre de l’espace disque pour rien. Bien évidemment, si vos impératifs de coût imposent l’utilisation de “disque de récup”, vous n’aurez pas le choix...
Bien que l’installation de départ se fera sur un système traditionnel (non-RAID), vous devez prendre en considération le fait que le système, à terme, reposera sur du RAID logiciel. Ceci influe directement sur la nature, le nombre et la taille des partitions que vous allez créer. Pensez à fragmenter le système en partitions de taille raisonnable correspondant à vos besoins. Inutile de créer un système de fichiers /var/www de 2 Go pour un site Web présentant 10 malheureuses photos.
Pensez à la charge système et à vos besoins en RAID logiciel au moment de l’installation des systèmes de fichiers sur les périphériques bloc “normaux”.
Il est également important de respecter l’usage (ancestral ?) consistant à créer une première partition de taille réduite destinée à être /boot. Nous allons en effet “RAIDifier” le système de fichiers monté en /, mais tous les bootloaders ne supportent pas le RAID logiciel. Mais je reviendrai sur ce point par après. Lors de l’étape de partitionnement des disques, veillez à définir, si vos disques sont identiques, des partitions semblables.
Ce n’est pas strictement nécessaire puisque dans l’étape suivante d’installation, vous ne devrez spécifier le point de montage et la création des systèmes de fichiers que pour les partitions du premier disque. Il s’agit simplement d’une sécurité dans la procédure d’installation. Vous partitionnez le premier disque, il y a donc moins de chances que vous fassiez une erreur en tentant de partitionner le second à l’identique.
Si vous y tenez, vous pourrez toujours utiliser sfdisk, cfdisk ou fdisk par la suite pour obtenir les informations de partition d’un disque et les répercuter sur l’autre. Poursuivez l’installation normale de notre distribution Debian Sarge jusqu’à son terme. Vous devez obtenir un système utilisable et parfaitement fonctionnel.

Je vous recommande fortement de mettre à jour ou d’installer un kernel récent post-installation. La configuration de test utilisée ici se base sur un kernel 2.4.22. Le cas du kernel 2.2.x n’est pas pris en compte ici (mais l’article est sans doute adaptable). Installez également dans la foulée le package initrd-tools pour une utilisation ultérieure.

Installation et configuration du RAID logiciel

Nous allons à présent préparer le terrain pour le futur système. Votre système fonctionnel “sur un disque” va se voir ajouter un support RAID logiciel. Cela se fait très simplement en installant le package raidtools2 via apt-get. Normalement, debconf vous demande si vous souhaitez démarrer le RAID au démarrage sur le système. Vous pouvez tranquillement répondre non à cette question, nous démarrerons le RAID bien avant le système dans l’installation définitive...

Jouez à présent de l’éditeur de texte pour vous confectionner un fichier de configuration raidtools correspondant à vos besoins. Référezvous directement à l’article de Lionel Tricon présent dans ce hors série pour plus d’informations sur la manière de configurer le RAID logiciel. Pour le présent article, la configuration est simpliste et le fichier /etc/raidtab contient ceci :

serraiddev              /dev/md0
raid-level              1
nr-raid-disks           2
chunk-size              32
nr-spare-disks          0
persistent-superblock   1
device                  /dev/sdb3
raid-disk               0
device                  /dev/sda3
failed-disk             1

Notre système exemple comporte une partition sda3 montée en / et une sda1 en /boot, sda2 étant une partition de swap. Ayant partitionné le disque sdb de la même manière, notre RAID utilisera tout naturellement sdb3.
Remarquez la ligne failed-disk accompagnant le device sda3. Voilà toute l’astuce de l’installation. Nous définissons un RAID logiciel utilisant sdb3 et sda3.
Cependant, comme sda3 est actuellement monté en / et comporte le système originel en cours d’utilisation, nous le “sortons” du RAID afin que les données ne soient pas touchées par la configuration du RAID.
Une fois le fichier créé, nous pouvons construire le RAID :

# mkraid /dev/md0
handling MD device /dev/md0
analyzing super-block
disk 0: /dev/sdb3, 1726987kB, raid
superblock at 1726912kB
disk 1: /dev/sda3, failed

Bien évidemment, un message vous informe que le device sda3 n’est pas fonctionnel (en raison du failed-disk). Cependant, le RAID est démarré, et vous pouvez poursuivre la procédure de migration du système avec la création du système de fichiers :

# mkfs.ext3 /dev/md0
mke2fs 1.35-WIP (21-Aug-2003)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
215936 inodes, 431728 blocks
21586 blocks (5.00%) reserved for the super user
First data block=0
14 block groups
32768 blocks per group, 32768 fragments per group
15424 inodes per group
Superblock backups stored on blocks:
       32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

Le RAID est maintenant prêt pour recevoir une copie du système actif.

Migration effective

La copie du système, même si les systèmes GNU proposent un grand nombre d’outils, n’est pas aussi triviale qu’il y paraît.
En effet, quiconque a déjà tenté l’expérience s’est heurté aux problèmes liés aux points de montage, ou encore aux pseudo-systèmes de fichiers. Si vous en doutez, tentez donc la commande suivante :

# cp -r /proc /tmp
^C
# ls /tmp/proc/
bus     crypto   driver   fs         kcore     ksyms
misc    net      pci      slabinfo   sysvipc
[...]

Eh oui, /proc n’est pas un vrai système de fichiers, et il est fortement déconseillé de le considérer comme tel.
Hors de question, donc, de le copier du système de fichiers racine actuel vers le futur système reposant sur le RAID logiciel.

Une fois cette considération assimilée, il est facile de contourner le problème. Nous commençons donc par monter le système defichiers dans /mnt/root :

# mount -v /dev/md0 /mnt/root
mount: you didn’t specify a filesystem type for /dev/md0
I will try type ext3
/dev/md0 on /mnt/root type ext3 (rw)

Il ne nous reste plus qu’à nous placer respectivement à la racine de chaque système de fichiers à copier et déclencher la copie.
Ici, je n’ai qu’un système de fichiers à copier, la racine :

# cd /
# find . -xdev | cpio -pm /mnt/root
1603716 blocks

Cette étape est plus ou moins longue en fonction de la taille dusystème de fichiers, de la rapidité des disques, des contrôleurs et du système en général.
L’option -xdev est la partie “magique” de la commande, elle permet de demander à find de ne pas “descendre” sur d’autres systèmes de fichiers. L’option -m de cpio nous permet de conserver la date de modification originelle des fichiers copiés.
Vous devez maintenant posséder, à peu de choses près, un système de fichiers identique sur sda3 et md0. Ce n’est pas strictement identique en raison du fonctionnement permanent du système qui influe sur le contenu des fichiers (logs par exemple).
Notez également, en toute logique, que tout ce que vous allez modifier sur le système en cours d’utilisation ne sera pas répercuté sur le futur système RAID. Je pense, en particulier, à d’éventuels packages oubliés qui seraient installés suite à la copie.

Préparation au redémarrage

En temps normal, le kernel 2.4 le plus récent installé par Debian utilise l’initrd (init RAM Disk). Sans arriver dans des considérations qui dépassent le cadre de cet article, sachez simplement que l’initrd permet de démarrer le système en deux fois. Le kernel démarre et utilise une image du système monté en RAM. A ce moment, les modules sont chargés depuis le système en RAM, et un certain nombre de services et commandes peuvent être lancés. Ce n’est qu’ensuite que le système “switche” sur le véritable système de fichiers racine et poursuit son démarrage.
L’initrd offre entre autres avantages la possibilité d’obtenir un démarrage plus modulaire en termes de support matériel, mais également pour tout ce qui relève de la préparation du système avant le démarrage effectif.
En cela, initrd constitue la solution idéale pour le démarrage d’un GNU/Linux avec un système de fichiers racine sur du RAID logiciel. En effet, le RAID peut être démarré depuis le système en RAM (avec raidstart) pour ensuite basculer sur le RAID logiciel.

Pour procéder de la sorte, nous sommes aidés dans notre tâche par l’utilitaire mkinitrd permettant la fabrication rapide, simple et semiautomatique d’image initrd. mkinitrd est fourni par le package initrd-tools sur Debian. Les autres distributions semblent avoir plutôt tendance à appeler le package mkinitrd.
Inutile de vous jeter dans le fonctionnement de mkinitrd et d’autopsier le fonctionnement des scripts, le seul fichier de configuration nécessitant une modification pour un système RAID logiciel est /etc/mkinitrd/mkinitrd.conf. Il vous suffit en effet de remplacer :

Une fois une session ouverte en tant que root, vous serez aux commandes d’un système GNU/Linux installé sur une base RAID logiciel

ROOT=probe

par

ROOT=/dev/md0

Aucune autre configuration n’est requise. La simple utilisation du périphérique md0 déclenche l’intégration automatique des binaires et des modules kernel nécessaires à la prise en charge du RAID logiciel. Inutile donc de perdre des heures à comprendre l’utilité de chaque fichier et script de configuration pour tout faire à la main (vécu), mkinitrd se charge de tout le travail pour vous à partir de la simple définition de partition racine. La génération de l’image initrd est des plus simple :

# mkinitrd -o /boot/initrd.img-raid

Vous obtenez votre image initrd. Il est possible de monter cette image en utilisant un périphérique loopback afin de s’assurer que tout est présent pour permettre le support du RAID logiciel. Gageons que mkinitrd a bien fait son travail et que cette vérification est superflue. Il ne nous reste que peu de choses à configurer. Editez maintenant le fichier /mnt/root/etc/fstab. Il s’agit du fichier de configuration des systèmes de fichiers pour le futur système utilisant RAID. Celui-ci nécessite une modification puisque dans l’état actuel il définit la partition sda2 comme étant la racine du système de fichiers. Modifiez donc la ligne en conséquence :

/dev/md0 / ext3 defaults,errors=remount-ro 0 1

Enfin, copiez dans /tmp et éditez le fichier de configuration de lilo présent sur le RAID. Inutile de modifier l’actuel fichier de configuration. Ce n’est pas nécessaire et laisser la configuration actuelle la plus propre possible n’est pas plus mal. Ajoutez une entrée correspondant au kernel en cours d’utilisation et prenant en compte notre image initrd toute fraîche :

image=/boot/vmlinuz-2.4.22-1-586tsc
label=LinuxRAID
root=/dev/md0
read-only
initrd=/boot/initrd.img-raid

Enregistrez le fichier, démontez le système de fichiers en RAID, puis arrêtez le RAID et lancez la réinstallation du bootloader lilo (l’installation de ssans arrêt du RAID ayant été source de problème lors des essais) :

# raidstop /dev/md0
# lilo -C /tmp/lilo.conf
[...]
Added LinuxRAID
[...]

Avant de redémarrer, je vous conseille fortement de lire l’encart (page 50) détaillant l’utilisation du bootloader GRUB. Etre en possession d’une disquette GRUB est toujours un avantage lors d’une modification de la configuration kernel ou du bootloader.
Elle vous permettra bien souvent de rattraper des situations catastrophiques ou tout simplement de démarrer un système en mauvais état.

Prêt pour le grand saut ? Croisez les doigts et redémarrez le système...

Premier démarrage

Au moment du boot lilo, choisissez l’entrée correspondante au démarrage sur le RAID logiciel et voyez les messages défiler. Des informations sur le RAID doivent apparaître :

md: autorun ...
md: considering scsi/host0/bus0/target1/lun0/part3 ...
md: adding scsi/host0/bus0/target1/lun0/part3 ...
md: created md0
[...]
md0: max total readahead window set to 124k
md0: 1 data-disks, max readahead per data-disk: 124k
raid1: device scsi/host0/bus0/target1/lun0/part3 operational as mirror 0
raid1: md0, not all disks are operational — trying to recover array
raid1: raid set md0 active with 1 out of 2 mirrors
[...]
md: recovery thread finished ...
md: ... autorun DONE.

Notre configuration présente dans raidtab fonctionne au démarrage. Tout va bien (ou presque). Si au moment du redémarrage du système vous obtenez un message d’erreur concernant init, pivot root, ou encore une impossibilité de déterminer le type de système de fichiers, il y a de fortes chances qu’une erreur se soit glissée dans vos manipulations.
Le problème peut provenir de l’image initrd ou de la configuration de lilo. Dans tous les cas, vous possédez encore un système viable découlant de la première installation. Utilisez alors GRUB ou une disquette de secours pour démarrer sur le système de départ en utilisant l’initrd d’origine.

Une fois une session ouverte en tant que root, vous serez aux commandes d’un système GNU/Linux installé sur une base RAID logiciel. Mais celle-ci n’est pas 100% fonctionnelle. Les messages au démarrage sont clairs, un périphérique de votre RAID 1 est absent ou pose problème. Un coup d’oeil au pseudo-système de fichiers proc nous le confirme :

# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1
scsi/host0/bus0/target1/lun0/part3[0]
    1726912 blocks [2/1] [U_]
unused devices: <none>

A ce moment, vérifiez l’intégrité du système et son fonctionnement. Si vous avez installé des packages après la copie find/cpio, installez-lez à nouveau. Enfin, alignez la configuration (lilo.conf par exemple) sur le nouveau système afin de tout rendre cohérent. Ceci fait, et après avoir vérifié une dernière fois qu’un retour au précédent système n’est pas nécessaire, vous pourrez intégrer le disque contenant l’installation d’origine dans le RAID (cela détruira les données du disque en question) :

# raidhotadd /dev/md0 /dev/sda3

Vous venez d’intégrer le disque manquant dans md0 et la synchronisation des données va commencer :

# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 scsi/host0/bus0/target0/lun0/part3[2] scsi/host0/bus0/target1/lun0/part3[0]
      1726912 blocks [2/1] [U_]
      [========>............] recovery = 44.8% (775616/1726912) finish=3.4min speed=4651K/sec
unused devices: <none>

Dernière modification, il ne faut pas oublier de changer la configuration du RAID dans le fichier /etc/raidtab afin d’intégrer de base le disque que nous venons d’ajouter “à chaud” :

device /dev/sda3
failed-disk 1

devient

device /dev/sda3
raid-disk 1

Votre configuration est à présent fonctionnelle.

Réflexions

Le système tel qu’il est actuellement configuré permet d’assurer la sécurité des données dans le cas où un disque venait à défaillir. Cependant, on n’oubliera pas de noter que seule la partition sda1 contient à la fois le kernel et l’image initrd (sans oublier le secteur de boot où se trouve lilo).
De ce fait, si le disque sda devenait défaillant, le système ne pourrait sans toute plus démarrer.
Il est possible de partiellement pallier ce problème en utilisant un bootload plus complet que lilo.

Ainsi, GRUB ou sans doute syslinux pourront, en cas de problème se rabattre sur un autre profil de démarrage et charger le kernel et l’image initrd depuis sdb1. Cela peut être fait à l’aide de la directive fallback de GRUB, par exemple.
Il n’en reste pas moins que si le problème est plus important, la machine ne démarrera pas (ou mal), le bootloader et le système restera “en carafe”.
Le RAID logiciel est une solution très intéressante en soi, mais il est important de bien en comprendre les limites.
Une architecture de haute disponibilité ne se limite pas à l’installation de RAID logiciel sur un serveur. Le problème de démarrage que je viens d’exposer est supposé être pris en charge par un autre mécanisme assurant la disponibilité des services.

GRUB, le GRand Unified Bootloader

Lorsque vous modifiez les paramètres de boot système, il peut arriver qu’une faute de frappe, une erreur de lecture ou n’importe quel type de problème empêche le démarrage car le bootloader ne peut charger le kernel Linux. Si la situation est encore plus grave, il est même possible que le bootloader lui-même ne fasse pas son travail ou que les fichiers nécessaires ne soient plus présents.
Si vous n’avez pas prévu de système de secours, c’est la catastrophe, et vous devrez sans doute vous rabattre sur un démarrage via le CD d’installation de la distribution et des manipulations des plus pénibles sur les systèmes de fichiers. L’autre solution est de prévoir un atout : GRUB. Ce bootloader possède, en effet, des fonctionnalités qui vont bien au-delà de ce que proposent les autres utilitaires disponibles.
Non seulement il fait parfaitement son travail de bootloader, tout en étant convivial pour l’utilisateur lambda, mais il constitue  presque un mini-système idéal pour corriger les problèmes de démarrage. Une ligne de commande “Bash like” intégrée vous permet de définir les paramètres de boot de manière interactive. Vous pouvez par exemple, en ce qui concerne Linux, définir l’emplacement du kernel et de l’image initrd et “booter” directement en utilisant ces paramètres.
Comble du raffinement, cette définition de paramètre vous permet d’utiliser la complétion à l’aide de la touche de tabulation, exactement comme avec un shell.Mieux encore, en cas de gros problème de lecture d’une partition et si, par malheur, votre partition montée en /boot était illisible, vous pourriez très facilement charger un kernel de secours depuis un autre endroit. Il s’agira, par exemple, d’une autre partition de type Ext2/3, ReiserFS, Xfs ou même FAT, peu importe.
Et comme si cela ne suffisait pas, il vous serait même possible de charger les éléments manquants depuis le réseau. GRUB est donc un atout majeur en termes de solution de secours. Ainsi, même si vous souhaitez continuer d’utiliser lilo ou un autre bootloader et ne pas “passer à GRUB”, une disquette de boot GRUB pourrait bien devenir quelque chose de précieux.

Créer une telle disquette est relativement simple. Nous créons tout d’abord un système de fichiers VFAT sur la disquette, ceci permet l’accès à la configuration depuis n’importe quelle machine (Unix, Mac, Win), puis nous montons ce système :

# mkfs.vfat -c /dev/fd0
# mount /dev/fd0 /floppy

Nous copions tous les éléments nécessaires à GRUB (les chemins sont ceux d’une installation Debian) :

# cp /usr/lib/grub/i386-pc/* /floppy
# cp /usr/share/doc/grub/examples/menu.lst /floppy

Enfin, nous démontons le système de fichiers et lançons l’utilitaire grub. Après un certain temps d’attente, l’interface interactive se lance et nous nous retrouvons sur le prompt grub. Là, nous utilisons la commande suivante pour installer le secteur de boot GRUB sur la disquette :

grub> install (fd0)/stage1 (fd0) (fd0)/stage2 (fd0)/menu.lst

C’est fini. GRUB est maintenant installé sur la disquette et vous n’avez plus qu’à lire la documentation GNU pour en savoir plus. Gardez précieusement cette disquette et faites-en éventuellement des copies avec dd.
Le fichier de configuration pourra être personnalisé depuis n’importe quel système d’exploitation pouvant monter du VFAT et éditer un fichier texte.

Notez qu’une image de la disquette pourra parfaitement être utilisée pour créer un CD bootable au format El Torito.

Retrouvez cet article dans : Linux Magazine Hors série 18