Dis papa, le serveur il est tout RAID

  • Bon pas besoin d'en faire une tartine, ni d'expliquer les différentes formes de RAID.
  • Ici, je parlerai de deux type de RAID (RAID1 et RAID5), avec trois disques.
    • RAID1 : C'est du mirroring. Chaque disque réplique complètement les autres.
    • RAID5 : Chaque disque perd 33% de sa capacité, afin d'être en mesure de reconstruire un disque tombé en panne. Il faut bien sûr que deux disques soient en état de marche pour reconstruire le troisième.
  • Pour ceux qui veulent tout savoir
    • excellent article de la doc Arch-Linux
    • La doc Arch aborde également le problème du MBR sur les disques modernes, et qui pourrait vous intéresser si vous installer un MS-Windows en RAID. Ceci ne sera pas abordé dans ce billet qui est déja suffisement long comme ça.




La route est droite mais la pente est RAID

  • Il y a différentes façons d'envisager le RAID.
RAID matériel
  • Le RAID matériel se matérialise (haha) sous la forme d'une carte d'extension qui supportera des disques SCSI , IDE ou SATA.
  • Les disques sont reconnus dès le boot par la carte, et le support est transparent pour l'OS qui verra les disques tels que le controleur RAID lui présente.
  • Pas de bol, c'est souvent associé à du matériel bien propriétaire, avec des disques bien spécifiques. Malheur à vous si vous osez utiliser un disque qui n'est pas absolument identique!
  • Bien entendu, les disques de votre array ne seront plus disponibles à la vente au moment où ils auront besoin d'être remplacés.
  • Les processeurs sont aujourd'hui largement plus puissants que les chipsets intégrés des cartes RAID (sauf cartes couteuses pour usages bien spécifiques, voir ci-dessous).
  • N'espérez pas récupérer vos disques avec un controleur RAID différent de celui d'origine.
  • Bref, aucun intêret, si ce n'est pour des cas bien spécifiques. Par exemple, dans le cas de grosses unités RAID montées sur une dizaine de disques. Le bus de la carte RAID sera plus efficace.
  • En réalité, le seul intêret est que le RAID matériel rassure le windozien, pour qui le RAID logiciel évoque la prise en charge foireuse par le bios buggé de sa carte mère Asuxxtoc. Le pauvre homme.


RAID logiciel
  • Pas besoin de matériel coûteux.
  • Le kernel Linux est tout a fait adapté au RAID logiciel, et la mise en oeuvre ne pose pas de problèmes particuliers.
  • On peut mélanger les disques (différents modèles ou constructeurs).
    • C'est même mieux de procéder ainsi, car on considère que les disques de même série vont avoir tendance à tomber en panne... en même temps. C'est d'ailleurs ce qu'on appelle la loi des séries.
  • On peut également mélanger différentes interfaces. Pour mon test, j'avais un disque en IDE, et deux en SATA. (je vous rassure, en prod c'est fait proprement. Les budgets pour la recherche, ce n'est plus ce que c'était, ma bonne dame.)
  • Vous n'êtes même pas obligés d' utiliser des disques de même taille. Il faut bien sûr qu'ils aient une taille suffisante pour contenir la/les partition(s) RAID.
  • En résumé, le RAID logiciel est tellement mieux pour les serveurs (je ne parle pas des grosses fermes de disques) qu'à part pour les fatigués de naissance et les pusillanimes, il s'impose de lui même.




Arch : mise en place d'un RAID logiciel


Situation de départ
  • Vous avez trois disques qui n'ont jamais servis, et vous souhaitez installer une machine sous Arch.
  • Il faut donc commencer par s'occuper de la mise en place du RAID.
  • Vous venez de booter sur le CD d'installation de Arch, et le curseur de la ligne de commande clignote impatiemment…


Partionnement
  • Vous pouvez utiliser cfdisk pour partitionner votre disque, en général disponible par défaut lors des installations.
  • Voici mon schéma de partionnement, avec trois disques sata (sda,sdb,sdc) :
    • sd[a-c]1 : /boot (agrégé en raid1, partition bootable)
    • sd[a-c]2 : / (agrégé en raid5)
    • sd[a-c]3 : swap (non agrégé, hors raid)
  • Note: la partition /boot sera marquée avec le flag bootable sur chacun des disques.
  • Pas la peine de faire trois fois de suite un cfdisk avec les mêmes paramètres.
    • Partionnez le premier disque, puis copiez le partitionnement sur les deux autres (assurez-vous d'opérer sur des disques vides).
    • Avec sfdisk (et non plus cfdisk), nous allons dupliquer les données.
    • sfdisk -d /dev/sda > partitions : pour dumper les infos de partitionnement.
    • sfdisk /dev/sdb < partitions : pour écrire sur le second disque le partitionnement du premier.
    • Vous pouvez vérifier le partitionnement: fdisk -l /dev/sd[a-c]
  • Pour info, le dump est une simple description ascii:

[root@archiso arch]# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=       63, size= 48821472, Id=83, bootable
/dev/sda2 : start= 48821535, size=923833890, Id=83
/dev/sda3 : start=972655425, size=  4112640, Id=82
/dev/sda4 : start=        0, size=        0, Id= 0


création des arrays
  • Nous utilisons mdadm, couteau suisse du Raid.
  • La lecture de sa manpage n'est pas conseillée, elle est obligatoire.
  • Pour créer une array en RAID-1 (partition /boot):

mdadm --create /dev/md1 --level=1 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdc1 --metadata=0.90


  • Pour créer une array en RAID-5 (partition /) :

mdadm --create /dev/md2 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc2


  • Pour vérifier que tout s'est bien passé, deux possibilités:
    • cat /proc/mdstat : le strict minimum.
    • Pour avoir plus de détails:

~# mdadm -q --detail /dev/md[1-2]


  • Dans tous les cas, vous allez voir que les différents disques sont en train de se synchroniser, sauf si vous avez créé des arrays minuscules (dans ce cas, il y a des chances pour que ce soit déja fini).
  • Un exemple de sortie de /proc/mdstat pendant la reconstruction de l'array en RAID-5 (un gros morceau):

Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdc2[3] sdb2[1] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
      [=>...................]  recovery =  9.1% (42417280/461916864) finish=64.2min speed=108744K/sec
      
md1 : active raid1 sdc1[2] sdb1[1] sda1[0]
      24410624 blocks [3/3] [UUU]

  • Vous pouvez bien sûr utiliser votre RAID pendant la reconstruction (sinon, le RAID n'aurait pas grand intêret).




Montage du RAID

  • A noter que cette partie pourra vous resservir hors installation, en cas de gros pépin par exemple.


Schéma du partitionnement RAID
  • Pour chacun des disques:
    • sd[a-c]1 : /boot (agrégé en raid1 sur /dev/md1)
    • sd[a-c]2 : / (agrégé en raid5 sur /dev/md2)
    • sd[a-c]3 : swap (non agrégé, hors raid)


Assemblage des partitions RAID
  • Normalement, un modprobe sur les modules RAID n'est pas nécessaire (ces modules seront chargés lors de la première utilisation de mdadm).
    • Au cas où, voici la liste des modules impliqués : md_mod et raid[456]
  • Avant de pouvoir mounter le RAID, il faut l'assembler (uniquement si vous venez de rebooter sur un système ne prenant pas encore en charge le RAID au moment du boot).

#Assemblage de la partition boot
[root@archiso ~]# mdadm --assemble /dev/md1 /dev/sda1 /dev/sdb1 /dev/sdc1
mdadm: /dev/md1 has been started with 3 drives.

#Assemblage de la partition home
[root@archiso ~]# mdadm --assemble /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2
mdadm: /dev/md2 has been started with 3 drives.


Formatage des partitions
  • Rappel : md1 correspond à la représentation d'un disque complet.
    • On peut rapprocher ce nom de device de sda , qui représente également la totalité du disque.
  • Ici, on veut utiliser le disque complet, donc on formate sans partitionner le device RAID. Exemple:
    • mkfs.ext4 /dev/md1
  • attention au flag HUGE_FILE lors du formatage , il peut poser problème plus tard et est relativement inutile pour l'instant
    • pour les problèmes possibles, voir la section premier boot.
    • HUGE_FILE permet le support de fichiers de plus de 2 teraoctets (nous ne sommes pas prêt d'y arriver, tout comme 640Kb should be enough for everyone).


Montage des partitions.
  • Je n'ai monté que la première partition (root) qui servira à contenir le système.
    • La partition "home" n'a pas d'intêret pour l'instant.

#Montage des partitions
[root@archiso ~]# mount /dev/md1 /mnt


Ajout du swap
  • Le swap est réparti sur les trois disques.

mkswap /dev/sda3 : à faire pour les 3 partitions.

  • On utilise la même priorité pour les 3 partitions de swap (avec -p 0)
    • swapon -p 0 /dev/sda3 /dev/sdb3 /dev/sdc3
  • A noter que le swap n'est donc pas en RAID, donc en cas de claquage d'un disque, il peut se passer des choses bizarres. Le swap ne sert pratiquement plus de nos jours, mis à part pour l'hibernation. Je préférais vous prévenir afin que vous agissiez en connaissance de cause. Faites le chez vous les enfants, mais ne venez pas vous plaindre ensuite!




Installation et configuration du système

  • Il faut maintenant installer les paquets.
  • Dans le cas d'une Arch, il vous faudra au minimum base. Pour le reste, c'est vous qui voyez.
  • Ça y est ? Tous les paquets sont installés ?
  • Nous allons poursuivre la configuration en gardant à l'esprit que votre disque n'est pas encore à la racine, mais simplement mounté dans un tmpfs.


Création de la config mdadm

mv /mnt/etc/mdadm.conf /mnt/etc/mdadm.conf.old
mdadm --examine --scan >> /mnt/etc/mdadm.conf

  • Attention à bien écrire dans le /etc du mount, et non pas dans celui monté en RAM pour l'installation.
  • Gardez précieusement le fichier mdadm.conf original. Il vous servira plus tard pour compléter la configuration (adressse mail pour le monitoring, etc..)
  • le double >> pour la redirection dans mdadm.conf, c'est uniquement dans le cas où vous referiez la manip avec un fichier qui a déja servi.



Autres fichiers à éditer
  • Vous pouvez éditer ces fichiers depuis le menu d'installation de Arch.
    • Il s'agit du menu "Install Packages".
  • Editez au minimum rc.conf pour avoir les locales en français au démarrage.
  • locale.gen : décommenter la locale choisie dans rc.conf
  • Si vous voulez utiliser un ramdisk pour charger les modules RAID (plutôt que de recompiler un noyau avec ledit support), c'est le moment de modifier: /etc/mkinitcpio.conf .
    • mkinitcpio se lance depuis un environnement chrooté, mais Arch se charge fort bien de cette tâche lorsque vous quittez le menu d'édition des fichiers.
  • La configuration de pacman fera l'objet d'un billet à part.
  • N'oubliez pas de changer le mot de passe root.


Sortie de l'installeur
  • Vous pouvez quitter l'installeur.
  • N' installez pas Grub depuis le menu Arch. Nous allons le faire depuis le shell, dès que nous aurons chrooté le RAID.




Installation de GRUB

Chroot du RAID
  • Il nous faut maintenant chrooter pour continuer l'installation

[root@archiso ~]# mount -o bind /dev /mnt/dev
[root@archiso ~]# mount -t proc none /mnt/proc
[root@archiso ~]# chroot /mnt /bin/bash



GRUB sur le premier disque
  • L' opération est détaillée pour le premier disque.
    • Elle sera à refaire pour chacun des disques, afin de pouvoir booter avec n'importe quel disque.
  • Nous installerons GRUB sur les autres disques après le premier boot.
  • Il nous faut commencer par ramener les fichiers de GRUB au bon endroit.
    • cp -a /usr/lib/grub/i386-pc/* /boot/grub/
  • Un petit coup d'oeil à /boot/grub/menu.lst afin de nous assurer que les paramètres par défaut sont corrects...
    • root est sur /dev/sda3. Ce qui est faux. Correction, avec remplacement par /dev/md1.
    • Un autre problème que vous pourriez rencontrer: vous n'avez fait qu'une seule partition racine, avec /boot inclus dedans. Dans ce cas, le noyau est dans /boot, et non pas dans / .
    • Voici ma config grub:

timeout   5
default   0
color light-blue/black light-cyan/blue

title  Arch Linux  [/boot/vmlinuz26]
root   (hd0,0)
kernel /boot/vmlinuz26 root=/dev/md1 ro md=1,/dev/sda1,/dev/sdb1,/dev/sdc1
initrd /boot/kernel26.img


  • Ensuite, nous invoquons grub avec ... grub
  • Et sous l'interface, nous rendons le premier disque bootable

grub> root (hd0,0)
grub> setup (hd0)
grub> quit



Avant de rebooter
  • Assurez vous d'avoir changé le password de root, sinon vous ne pourrez pas utiliser ce compte.
  • Vous pouvez aussi créer un utilisateur : adduser -m toto puis passwd toto


Support par Linux au boot
  • Support par modules
    • Par défaut, votre noyau de distrib a tous les drivers possibles compilés en modules (le noyau serait trop gros avec les drivers compilés en dur).
    • Il faudra donc utiliser une image montée en ram juste après le chargement du noyau, pour utiliser les modules RAID.
    • Je ne détaille pas cette option ici, mais j'ai préparé un billet que je posterai bientôt pour les gens intéressés.
  • Support dans le kernel
    • Le plus facile est de se compiler un kernel avec le support RAID built-in.
    • L'inconvénient est que l'on perd le noyau fourni par sa distribution. Sauf si bien sûr on crée un paquet avec le noyau nouvellement compilé.


Premier boot : alors ça, c'est RAID!

Montage en lecture seule des devices RAID (mdx)
  • Le boot semble bien se passer, tout va très bien Madame la Marquise ... sauf qu'on déplore un tout petit rien.
  • Les partitions md0 et md1 sont montées en lecture seule
    • EXT4-fs (md0) : Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF
  • Mais à part ça, Madame la Marquise, tout va très bien, tout va très bien.


Résolution 1 : bête et méchante.
  • Vous pouvez rebooter sur votre CD d'install, ré-assembler le RAID, et recompiler un noyau avec l'option CONFIG_LBDAF
    • Cette option sert à supporter les fichiers de plus de 2 Tera-octets.
    • Vu que mon RAID est composé de 3*40Go, ceci parait un peu inutile ... nous allons enquêter un peu plus sur ce message.


Résolution 2 : un poil de réflexion.
  • Nous allons inspecter les systèmes de fichiers (cette erreur ne concernant pas le RAID).
  • Reboot avec le CD d'install, et ré-assemblage du RAID. Mais cette fois, pas de recompilation du noyau!
  • tune2fs -l /dev/md1
    • nous voyons le flag HUGE_FILE , qui provoque le problème.
    • répéter l'opération pour md2 (normalement, c'est la même chose si vos partitions ont été créées de la même façon).
  • Nous allons enlever le flag HUGE_FILE
    • tune2fs -O ^HUGE_FILE /dev/md1
    • si nécessaire, répéter l'opération sur les autres unités RAID.
    • vérifier que les opérations ont été répercutées (ex: tune2fs -l /dev/md1 )
  • Lancer un e2fsck sur les devices RAID (ex: e2fsck /dev/md1 )
  • Si tout est ok, reboot !




Dernières opérations après reboot

GRUB sur le disques supplémentaires
  • Il ne nous reste plus qu'à installer GRUB sur les disques restants, afin d'avoir trois disques identiques et substituables.
  • Relancez grub et tapez ces commandes:

grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdc
grub> root (hd0,0)
grub> setup (hd0)
grub> quit



Sauvegarde de la structure des disques
  • Afin de reconstruire rapidement un disque raid, il est utile de sauvegarder sa structure.
    • Il faudra bien sûr un disque de taille identique ou supérieure pour restaurer.

 sfdisk --dump /dev/sda >sfdisk_sda
 sfdisk --dump /dev/sdb >sfdisk_sdb
 sfdisk --dump /dev/sdc >sfdisk_sdc

  • A mettre en lieu sûr. La partition raid devrait faire l'affaire.
  • Pour restaurer, il vous suffira de pratique l'opération inverse.
    • sfdisk /dev/sda < sfdisk_sda



Base de monitoring

/proc/mdstat
  • On commence par utiliser les processus.
  • Pour l'admin, un cat /proc/mdstat suffit.
    • ce n'est pas très pratique pour les scripts.
  • Le strict minimum peut être obtenu facilement:

cat /proc/mdstat | awk '/^md[0-9]/ { dev=$1 } /\[[U_]+\]/ { match($0,/\[[U_]+\]/,state); print dev ":" state[0] }'

  • à adapter selon ce que vous souhaitez en faire.
    • par exemple, cette sortie pourrait être lue avec beuglement de la machine en cas de détection d'un disque en rade.


mdadm
  • On peut utiliser tout simplement mdadm.
    • Il suffit de le placer en mode monitor.

mdadm -F -m toto@foo.com --scan -1 -t

  • Signification des flags:
    • -F : mode monitor.
    • -m : précise le mail où envoyer le rapport.
    • scan
    • -1 : une seule itération et sort (sans ce flag, lancé en daemon).
    • -t
  • Pour recevoir des emails en cas d'alerte, vous avez un paramètre dans mdadm.conf:
    • MAILADDR moi@bigcorp.com




RAID is dead (ou: RAID en rade)

  • Maintenant, simulons une panne afin de nous assurer que tout est d'équerre.


Où sont les disques ?
  • Pour commencer, il faut repérer les ports SATA pour retrouver les disques facilement dans le boitier.
  • Explorons un peu les devices pour retrouver tout ça:
    • /sys/block/sda/device -> ../../../0:0:0:0
    • qui pointe en fait vers
    • /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
  • Nous en déduisons:
    • 1f.2 : controleur sata de sda.
    • target : donne le port pour sda.
  • Pour faire plus court: readlink -f /sys/block/sda/device
    • /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
  • résultat de readlink sur sda, sdb, sdc :

sda: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
sdb: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0
sdc: /sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0


  • Un coup d'oeil sur la carte mère..
    • Sur l'epoxy de la carte mère, il est sérigraphié un libellé à côté de chaque port sata: sata-a, sata-b… jusqu'à sata-d pour ma part.
    • Ces ports sont reliés à des disques. Une étiquette sur le cordon sata côté disque indique: hd0, hd1, hd2.
    • Nous en déduisons assez logiquement que le nommage du controleur sata suit la même progression.
  • host0 pour les deux premiers, logique au vu du branchement physique.
  • Logique et Informatique ne riment que dans le dictionnaire.
    • Nous pouvons vérifier notre théorie en débranchant le premier disque, machine éteinte.
    • Ensuite, nous rallumons la machine en bootant sur le media d'installation ou sur un live-CD (surtout pas sur votre OS à ce stade!).
    • Il ne reste plus qu'à vérifier, en faisant la manipulation ci-dessus. Vous devriez retrouver facilement l'emplacement physique du disque déconnecté.
  • Tout ceci devrait faciliter le remplacement d'un disque grillé, sans avoir besoin de l'horrible méthode essai/erreur.



Simulation d'une panne soft
  • Les possibilités ne manquent pas, avec option électrocution pour les aventuriers de tous les dangers.
    • Pour commencer, j'ai choisi la méthode douce: marquage d'une partition raid en fail, et retrait de celle-ci.


  • Marquage en fail:

# mdadm -f /dev/md1 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md1


  • Retrait de la partition:

# mdadm -r /dev/md1 /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md1


  • Vérification du retrait de sda1 de md1
    • La première partition est arrêtée: _UU

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb2[1] sdc2[2] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md1 : active raid1 sdc1[2] sdb1[1]
      24410624 blocks [3/2] [_UU]


  • Remise en route du raid
    • Auparavant, nous créons un gros fichier sur md1, juste pour rire.
    • dd if=/dev/urandom of=garbage count=1M bs=1K
  • Et nous ajoutons sda1 à l'array md1
    • mdadm -a /dev/md1 /dev/sda1
  • Ça bosse ? Un petit coup d'oeil à mdstat

# mdadm -a /dev/md1 /dev/sda1
mdadm: re-added /dev/sda1

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb2[1] sdc2[2] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md1 : active raid1 sda1[3] sdc1[2] sdb1[1]
      24410624 blocks [3/2] [_UU]
      [>....................]  recovery =  1.2% (293632/24410624) finish=2.7min speed=146816K/sec

unused devices: <none>



Simulation d'une panne hard
  • Cette fois, c'est du sérieux. Terminé les marquages fail, place au tournevis.
  • Éteignons la machine, et retirons le disque correspondant à sda.
  • Nous en plaçons un autre en remplacement.
    • Nous avons vu plus haut comment repérer les disques dans le boitier.
  • Bien entendu, nous n'avons pas pu sortir proprement de l'array raid le disque grillé.
    • Il faut donc rebooter sur un live CD, pour reconstruire l'array.
  • Pas de bol, le nouveau disque inséré est identifié comme étant sdb (les joies de udev).
    • En situation critique, il faudrait donc au plus deux reboots (et les fsck afférents) pour trouver un disque grillé.
  • Dans mon test de restauration, le disque de remplacement avait une capacité très inférieure aux autres disques. Cela ne gêne pas pour du raid soft, et je me suis contenté de reconstruire la partition système.
    • Opérons un fdisk sur un disque faisant partie de l'array, afin de récupérer les valeurs start et end de la ppartition système. Ensuite, nous re-créons la partition sur le disque de remplacement, en utilisant bien sûr les mêmes valeurs.
    • Il y a encore plus simple: si vous aviez sauvé les valeurs de vos partitions raid avec sfdisk, vous pouvez faire l'opération inverse pour initialiser le nouveau disque (il faut cependant qu'il soit de capacité identique ou supérieure aux disques déja présents).
  • Une fois le disque de remplacement paramétré, nous pouvons assembler le raid.
    • Nous commençons par intégrer les deux disques corrects.
    • C'est un assemblage en mode dégradé (d'où le paramètre --run)

~# mdadm --assemble --run /dev/md1 /dev/sda1 /dev/sdc1


  • Normalement, nous obtenons: mdadm: /dev/md1 has been started with 2 drives (out of 3)
  • Un cat /proc/mdstat donne plus de précisions

md1: active raid1 sda1[0] sdc1[2]
     24410624 blocks [3/2] [U_U]


  • Il ne nous reste plus qu'à ajouter le disque de remplacement à l'array:

~# mdadm --add /dev/md1 /dev/sdb1
~# cat /proc/mdstat # indique que le recovery est en cours.


  • Le mount du disque RAID est possible, pour vérifier que tout est bien là.
    • mount /dev/md1 /mnt
  • Attention à éditer mdadm.conf et /etc/fstab sur votre array, si vous n'avez pas restauré toutes les partitions!
  • Rebootons sur notre RAID remis en état.
  • Voilà.
  • Si vous avez fait un test et que vous désirez remettre l'ancien disque, enlevé uniquement durant le test:
    • bootez sur un live CD.
    • agrégez le raid sur les deux disques synchronisés dans le raid.
    • ajoutez le disque (même procédure que ci-dessus).
  • Une astuce pour finir. Vous pouvez très bien faire:

#ici, /dev/sdb1 n'a pas encore été remis dans l'array

~# mdadm --assemble /dev/md1 /dev/sd1 /dev/sdb1 /dev/sdc1
mdadm: /dev/md1 assembled from 2 drives - need all 3 to start it
       (use --run to insist).

~# mdadm --run /dev/md1
mdadm: started /dev/md1

  • Un cat /proc/mdstat montre que sdb est manquant.
    • Il ne reste qu'à ajouter sdb1 à md1, et c'est reparti!



Mais je serai RAID avant qu'il n'ait fini !
  • Vous avez sans doute remarqué que la reconstruction d'une array pouvait prendre un certain temps.
  • Heureusement, il y a moyen d'accélérer les choses.
  • Vous ne voulez rien synchroniser, car vous avez juste déplacé un disque de port SATA sur la carte mère. Ceci peut arriver dans le cas d'un changement de cable par exemple, cable qui sera trop court. Dans ce cas, votre troisième disque contient déja toutes les données et vous n'avez pas besoin de le reconstruire.
    • ATTENTION cette option n'est valable que si vous n'avez pas encore monté le RAID que vous voulez reconstruire. Si vous avez booté sur le RAID ou monté vos disques RAID, c'est fichu, cette option n'est plus valable.
    • Faites un resync du nouveau disque avec l'option ——assume-clean.
  • Un cas plus classique de grande lenteur.
    • Dans un cas plus réaliste, c'est à dire si vous ajoutez un disque neuf, vous serez obligé de tout reconstruire. Mais même dans ce cas, vous pouvez également accélérer les choses.

~# cat /proc/sys/dev/raid/speed_limit_min
1000
~# cat /proc/sys/dev/raid/speed_limit_max 
200000

  • Ceci signifie que pour chaque disque, la limite minimale de reconstruction est de 1mo par seconde. Et la limite haute est de 200mo/s.
  • La limite basse est vraiment peu élevée. On peut l'augmenter.

echo 20000 > /proc/sys/dev/raid/speed_limit_min
 
OU
 
sysctl -w dev.raid.speed_limit_min=20000
 
  • Nous passons ainsi à un objectif de 20mo/s.
    • Ces modifications sont temporaires. Il faudrait placer le sysctl dans un fichier de démarrage pour les rendre résistantes au reboot.
  • Nous disposons également de l'option bitmap, qui accélère la reconstruction.

~# mdadm --grow --bitmap=internal /dev/md0


  • Une fois l'array reconstruite, il faut désactiver l'option.

~# mdadm --grow --bitmap=none /dev/md0


  • Une autre option susceptible d'accélérer les choses est de mounter les partitions avec l'option noatime
    • Cette option n'est pas spécifique au RAID, mais elle accélérera les transactions sur les partitions journalisées avec EXT4.
    • fstab : /dev/md1 / ext4 defaults,noatime 0 1 (partition root)
    • suivi d'un mount / -o remount
    • puis d'un controle avec cat /proc/mounts
  • Un petit exemple de vitesse avec ces paramètres modifiés (speed_limit_min et bitmap):

~# mdadm --grow --bitmap=internal /dev/md1

~# mdadm -a /dev/md1 /dev/sdc5

# cat /proc/mdstat 

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md1 : active raid5 sdc5[3] sda5[0] sdb5[1]
      1718745088 blocks level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  0.5% (4840064/859372544) finish=150.8min speed=94402K/sec
      bitmap: 3/7 pages [12KB], 65536KB chunk




Better RAID than dead

  • Sur ce, j'arrête les jeux de mots faciles. Avant que tout cela ne ressemble au style des admins BSD.
  • Merci d'avoir pris le temps de lire ce long billet (oserais-je parler d'article ?). J'ai passé encore plus de temps à l'écrire.
  • Dernière chose: j'ai utilisé mes notes provenant de l'installation de deux machines. Il se peut que certains devices vers la fin ne correspondent plus à ceux du début. J'ai tout relu et corrigé, bien sûr, mais certains détails ont pu m'échapper.