User Tools

Site Tools


informatique:linux:raid0_sous_linux

This is an old revision of the document!


RAID stripping

Le RAID logiciel sous Linux

Le RAID est un mécanisme de gestion de unités de stockage, qui peut être matériel (via une carte dédiée) ou logiciel (géré par le système d'exploitation ou un driver). Il existe différents type de RAID (0, 1, 5, etc) qui déterminent chacun un mode de gestion. Je ne m'attarde pas là dessus, pour plus d'info, aller voir wikipédia : le RAID.

Installation de Debian avec RAID0

Le but de cet article est de décrire la procédure que j'ai utilisée pour installer une Debian Lenny sur 2 disques dur en RAID0 logiciel avec Linux Software RAID. Mes motivations sont :

  • pas de perte d'espace disque
  • tirer parti des performances maximale avec mon matériel (disques et CPU/carte mère)
  • un RAID logiciel car je n'ai pas de contrôleur RAID matériel

Le RAID0 ne permet pas de redondance ni de récupération des données en cas de crash disque ; qu'à cela ne tienne je fais de la synchronisation régulièrement.

J'ai suivi la doc disponible sur ubuntu-fr : Comment installer ubuntu sur RAID 0

Situation actuelle :

  • 2 disques durs SATA de 1 To chacun

Voici ce que je veux faire :

  • une partition de swap de 1Go
  • un /boot de 1Go aussi
  • un / de 6Go
  • le reste dans /data

Voici le résultat du partitionnement de mes disques (GB = Go) :

/dev/sda
  /dev/sda1 de 1GB   (swap)
  /dev/sda2 de 3GB   (RAID) -> la moitié du futur /
  /dev/sda3 de 996GB (RAID) -> la moitié du futur /data
/dev/sdb
  /dev/sdb1 de 1GB   (ext3) -> /boot (penser à sélectionner "indicateur d'amorçage : présent")
  /dev/sdb2 de 3GB   (RAID) -> l'autre moitié du futur /
  /dev/sdb3 de 996GB (RAID) -> l'autre moitié du futur /data

Je vais ensuite créer 2 volumes RAID0 avec l'installateur Debian :

  • /dev/sda2 et /dev/sdb2 qui formeront le volume /dev/md0
  • /dev/sda3 et /dev/sdb3 qui formeront le volume /dev/md1

NB : La partition /boot ne peut pas être créée sur du raid logiciel pour pouvoir booter dessus ; mais cela ne pose pas de problème de performance car elle n'est plus utilisée une fois la machine bootée.

Création d'un RAID1

à la main

Lister les disques et partitions sur la machine (on doit être root sinon ça n'affiche rien, même pas un message d'erreur) :

sudo fdisk -l | grep Disque
 Disque /dev/sda: 6442 Mo, 6442450944 octets
 Disque /dev/sdc: 1073 Mo, 1073741824 octets
 Disque /dev/sdb: 1073 Mo, 1073741824 octets

On va faire un RAID1 avec les disques /dev/sd{c,d} = on doit créer 2 partitions primaires de type “fd” (Linux raid auto) sur tout l'espace de chaque disque.

⇒ Cela nous donne donc /dev/sdb1 et /dev/sdc1 2 partitions d'environs 1 gigaoctet chacune.

Créer un volume RAID1 ; y rattacher les 2 partitions de 1 Go

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd{b,c}1

cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdb1[0] sdc1[1]
      1044096 blocks [2/2] [UU]
      
unused devices: <none>

On déclare un disque en erreur (“faulty”)

mdadm /dev/md0 --fail /dev/sdb1

cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdc1[1] sdb1[2](F)
      1044096 blocks [2/1] [_U]
      
unused devices: <none>

On retire les disques défectueux du volume RAID

mdadm /dev/md0 --remove failed

cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdc1[1]
      1044096 blocks [2/1] [_U]
      
unused devices: <none>

On ajoute un nouveau disque dans le RAID = le nouveau disque se resynchronise

mdadm /dev/md0 --add /dev/sdb1

cat /proc/mdstat 
Personalities : [raid1] 
md0 : active raid1 sdb1[2] sdc1[1]
      1044096 blocks [2/1] [_U]
      [=>...................]  recovery =  8.7% (91776/1044096) finish=0.3min speed=45888K/sec
      
unused devices: <none>

Puis on formate la nouvelle partition RAID (/dev/md0 en ext3 :

mke2fs -T ext3 /dev/md0

Automatisation du montage :

vi /etc/fstab
 /dev/md0       /mnt/RAID1      ext3    defaults        1 0

Divers

Monitorer son RAID

cat /proc/mdstat 
 Personalities : [raid0] 
 md1 : active raid0 sda3[0] sdb3[1]
       1945696256 blocks 64k chunks
       
 md0 : active raid0 sda2[0] sdb2[1]
       5863552 blocks 64k chunks
       
 unused devices: <none>

On peut avoir plus de détails avec :

mdadm --detail /dev/md1
    /dev/md1:
         Version : 00.90
   Creation Time : Sat Feb  7 12:49:57 2009
      Raid Level : raid0
      Array Size : 1945696256 (1855.56 GiB 1992.39 GB)
    Raid Devices : 2
   Total Devices : 2
 Preferred Minor : 1
     Persistence : Superblock is persistent
 
     Update Time : Tue Feb 10 20:31:42 2009
           State : clean
  Active Devices : 2
 Working Devices : 2
  Failed Devices : 0
   Spare Devices : 0
 
      Chunk Size : 64K
  
            UUID : 9695e8d2:87d83bd5:e070d1d4:842cdf7e
          Events : 0.5
  
     Number   Major   Minor   RaidDevice State
        0       8        3        0      active sync   /dev/sda3
        1       8       19        1      active sync   /dev/sdb3

Créer un volume RAID1 avec un seul disque

Il s'agit ici de créer un RAID 1 avec un seul disque, donc un RAID en défaut (pas de réplication de données mais la machine fonctionne toujours). Cela permet par exemple de préparer une machine avec un seul disque en attendant la livraison du second.

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 missing

→ On créer /dev/md0 en RAID1 en utilisant 2 partitions : /dev/sda1 et une qui manque en temps normal c'est plus utile d'utiliser une 2nde partition

Création d'un raid5 + LVM

Volume RAID 5

Un raid0 avec de la redondance pour la sécurité des données ? C'est un raid5 et c'est ce que je vais tenté (“tenter” car c'est un raid software avec un processeur atom n550, et c'est un processeur un peu léger pour du calcul de parité).

#création du raid 5 avec 3 partitions : /dev/sda1 /dev/sdc1 /dev/sdd1
# --assume-clean permet d'éviter le calcul de parité à la création
mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=3 --assume-clean /dev/sd[abd]1

Il faut attendre un peu le temps de la construction du raid, puis on vérifie :

mdadm --detail /dev/md0
 /dev/md0:
        Version : 1.2
  Creation Time : Tue Feb 15 18:58:18 2011
     Raid Level : raid5
     Array Size : 3907020800 (3726.03 GiB 4000.79 GB)
  Used Dev Size : 1953510400 (1863.01 GiB 2000.39 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent
 
    Update Time : Wed Feb 16 12:32:05 2011
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0
 
         Layout : left-symmetric
     Chunk Size : 512K
 
           Name : ymir2:0  (local to host ymir2)
           UUID : 9c8c8486:625dbdfd:98aa755c:b4266366
         Events : 2
 
    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       49        2      active sync   /dev/sdd1
 
 
# ou :
cat /proc/mdstat
 md0 : active raid5 sdd1[2] sdb1[1] sda1[0]
      3907020800 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
 
 unused devices: <none>

Dans le première commande on pourrait tilter sur la ligne :

     Array Size : 3907020800 (3726.03 GiB 4000.79 GB)

3726.03 GiB alors que je devrait avoir 4 To ? WTF !!

Juste un rappel pour vérifier tout ça :

  • 8 bits = 1 octet (byte en anglais : un octet et one byte c'est pareil !). Les abréviations respectives sont b (bit), o (octet) et B (byte).
  • 1 kB = 1 ko = 1000 octets (bytes). Dans la même logique, 1 MB vaut 1000 kB, 1 GB vaut 1000 MB, etc… : ce sont des puissances de 10 : 1000 c'est 10^3.
  • 1 KiB vaut, lui, 1024 octets (bytes). Dans la même logique, 1 KiB = 1024 B, 1 MiB vaut 1024 KiB, 1 GiB vaut 1024 MiB, etc… ce sont des puissances de 2 (normal pour de l'informatique) : 1024 c'est 2^10.

<note> Les Xi se prononcent kibi (Ki), mébi (Mi), etc… </note>

<note> Les abréviations des kilos sont “k” pour les puissances de 10 et “Ki” pour les puissances de 2. C'est exprès, pour qu'on confonde. </note>

Autant la première notation (B, kB, MB…) est assez classique et facile à calculer :

1 GB = 10^3 MB = 10^6 kB = 10^9 B = 1 000 000 000 bytes

… autant la seconde n'est pas naturelle (pour les hommes en tout cas) :

1 GiB = 2^10 MiB = 2^20 KiB = 2^30 B soit 1 073 741 824 bytes

Ce qui nous amène à la conclusion : 1 GiB “vaut plus” que 1GB. (c'est pour ça que les vendeurs de disques dur comptent en GB, ça gonfle les capacités :) ). Mais les ordinateurs, eux, comptent en puissance de 2, en XiB (kilo, méga, giga, etc…). Donc un disque dur de 1 To (1 TB) acheté dans le commerce ne fait que : 10^12 / 2^40 = 0.909 TiB

Voici la table de conversion entre XB et XiB :

1 TB = 10^12 o => 0.909 TiB
1 GB = 10^9  o => 0.931 GiB
1 MB = 10^6  o => 0.954 MiB
1 KB = 10^3  o => 0.977 KiB

1 TiB = 2^40 o => 1.100 TB
1 GiB = 2^30 o => 1.074 GB
1 MiB = 2^20 o => 1.049 MB
1 KiB = 2^10 o => 1.024 kB

Pour finir la parenthèse, dans mon cas j'ai mon raid5 de 3 x 2 To ; ça donne 4 To de capacité utile, donc 4 x 0.909 = 3.6380 TiB (arrondi) = 3725 GiB : le compte est bon (mais pas à mon avantage).

source : entre autres préfixe binaire sur Wikipédia.


Une fois le raid construit, si tout va bien, il faudra le monter automatiquement au démarrage la prochaine fois :

echo "DEVICE partitions" >> /etc/mdadm/mdadm.conf
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Raid en vrac au reboot

Sous Ubuntu 10.10 cette fois j'ai rencontré un problème lors du reboot car il me montait /dev/md avec 2 disques et /dev/md_d0 avec le dernier. Hideux. Même en retouchant le mdadm.conf celà n'a rien changé. Je suis alors tombé sur ce post sur ubuntuforums qui décrit cette procédure qui a résolu mon problème :

# arrêt du raid triso
mdadm --stop /dev/md_d0
 mdadm: metadata format 00.90 unknown, ignored.
 mdadm: stopped /dev/md_d0
 
mdadm --auto-detect
 
/usr/share/mdadm/mkconf force-generate /etc/mdadm/mdadm.conf
 
update-initramfs -u
 update-initramfs: Generating /boot/initrd.img-2.6.35-25-generic
 
# puis on reboot
init 6

Au redémarrage le volume RAID est monté correctement \o/.

LVM

Création du bousin LVM : déclaration dans l'ordre :

  • d'un volume physique (pv) de 4 To (le raid5)
  • d'un groupe de volume (vg) : on ajoute le pv de 4 To qui sera seul dans son groupe
  • d'un volume logique (lv) : on déclare une partition de 2 To dans le vg de 4 To (on pourra le redimensionner plus tard).
pvcreate /dev/md0
vgcreate md0_vg /dev/md0
lvcreate -L 2T -n data_lv md0_vg

Puis on traite /dev/md0_vg/data_lv comme avec une partition classique :

# formatage en ext4 avec des paramètres optimisés pour le raid..
#(source : http://planet.ubuntu-fr.org/post/2007/10/13/mdadm-raid5)
mkfs.ext4 -m 0 -b 4096 -R stride=8 /dev/md0_vg/data_lv
 
# montage automatique au démarrage :
echo "/dev/md0_vg/data_lv /mnt/data ext4 defaults 0 1" >> /etc/fstab
 
# montage
mkdir /mnt/data
mount /mnt/data

Management du raid

Arrêter/Supprimer le raid :

mdadm --stop /dev/md0
 mdadm: stopped /dev/md0

Supprimer et ajouter un disque dans une grappe raid :

mdadm --manage --remove /dev/md0 /dev/sdd1
 mdadm: hot removed /dev/sdd1 from /dev/md0
 
mdadm --manage --add /dev/md0 /dev/sdd1
 mdadm: re-added /dev/sdd1

Vérifications :

mdadm --detail /dev/md0

mdadm --detail --scan --verbose

Management de LVM

Augmenter un lv

Synopsis : On a un lv /dev/md0_vg/data_lv de 2 To et on veut le monter à 4 To (soit la taille de son vg).

Démonter le volume logique (NB : cette étape n'est pas obligatoire avec le système de fichier que j'utilise (ext4), mais vu que mon serveur n'est pas en prod ça ne me coûte pas plus cher) :

umount /dev/md0_vg/data_lv

Augmenter la taille du lv ; attention sa taille ne doit pas dépasser la taille de son volume group (vg), ni être inférieur sa taille actuelle (sinon on perd des données). Pour le vérifier :

# on regarde a quel vg le lv appartient -> md0_vg
lvdisplay /dev/md0_vg/data_lv
  --- Logical volume ---
  LV Name                /dev/md0_vg/data_lv
  VG Name                md0_vg
  LV UUID                WSTrwM-JLAG-Bu9R-GsHw-XVsT-Dpbo-Zm5imT
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                2,00 TiB
  Current LE             524288
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     4096
  Block device           253:2
 
# on affiche les caractéristique du vg
vgdisplay md0_vg
  --- Volume group ---
  VG Name               md0_vg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               3,64 TiB
  PE Size               4,00 MiB
  Total PE              953862
  Alloc PE / Size       524288 / 2,00 TiB
  Free  PE / Size       429574 / 1,64 TiB
  VG UUID               1g20v1-7HKi-CWtx-D8IP-GS9P-rTfB-nL9WHr

On a bien 3.64TiB au total soit 4 To.

On pourrait déclarer une nouvelle taille de 3.64 TiB (-L 3.64T), ou ajouter 1.64 To (-L +1.64T) - pour toutes les options existantes, consulter le man lvresize - mais on veut la taille totale du vg donc on va être précis et utiliser l'option -l +100%FREE qui indique qu'on ajoute toute la place libre restante du vg :

lvresize -l +100%FREE /dev/md0_vg/data_lv
  Extending logical volume data_lv to 3,64 TiB
  Logical volume data_lv successfully resized

On doit ensuite vérifier l'intégrité du volume logique :

e2fsck -f /dev/md0_vg/data_lv
 e2fsck 1.41.12 (17-May-2010)
 Passe 1 : vérification des i-noeuds, des blocs et des tailles
 Passe 2 : vérification de la structure des répertoires
 Passe 3 : vérification de la connectivité des répertoires
 Passe 4 : vérification des compteurs de référence
 Passe 5 : vérification de l'information du sommaire de groupe
 /dev/md0_vg/data_lv : 11/201326592 fichiers (0.0% non contigus), 12687388/805306368 blocs

Puis on étend le système de fichier :

resize2fs /dev/md0_vg/data_lv
 resize2fs 1.41.12 (17-May-2010)
 En train de retailler le système de fichiers sur /dev/md0_vg/data_lv à 976754688 (4k) blocs.
 Le système de fichiers /dev/md0_vg/data_lv a maintenant une taille de 976754688 blocs.

et on remonte le lv :

mount /dev/md0_vg/data_lv
 
df -Th /mnt/data
 Sys. fich.    Type  Taille  Uti. Disp. Uti% Monté sur
 /dev/mapper/md0_vg-data_lv
             ext4    3,6T  196M  3,6T   1% /mnt/data

Tests et banchmarks

Je vais comparer ici mon ex raid0 avec le nouveau raid5 que je viens de créer. Attention il y a beaucoup de paramètres qui changent donc ces tests ne sont pas très “scientiques”, mais ils donnent un ordre d'idée.

Le raid0 est sur le serveur ymir :

  • raid0 de 2x HDD Samsung Spinpoint F1 1 To (7200 rpm, 32 Mo de cache)
  • le système est installé sur ces disques donc ils ne sont pas idle pendant les tests
  • la partition est formatée en ext3 avec les réglages par défaut

Le raid5 est sur le serveur ymir2 :

  • raid5 de 3x HDD Samsung EcoGreen F4 2 To (5400 rpm, 32 Mo de cache)
  • le raid est monté sur des disques complètement idle, le système étant installé sur un autre disque (un SSD OCZ Vertex 60 Go)
  • la partition est formatée en ext2 avec les réglages indiqués plus haut

Test en écriture

A l'ancienne avec dd

J'utilise ici la commande dd pour créer un ficher de 1 Go et le remplir de 0.

sur ymir2 :

# raid5
dd if=/dev/zero of=/mnt/data/test.data bs=8k count=128k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 12,3638 s, 86,8 MB/s
 
# à titre comparatif, sur le SSD
dd if=/dev/zero of=/tmp/test.data bs=8k count=128k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 6,25596 s, 172 MB/s

sur ymir :

# raid0
dd if=/dev/zero of=/mnt/data/tmp/test.data bs=8k count=128k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 bytes (1,1 GB) copied, 8,66769 s, 124 MB/s

De ces valeurs on peut retenir une chose : l'écriture sur un raid5 nécessite un lourd calcul de parité qui surcharge clairement le processeur (atom n550 pour ceux qui ne suivent pas :)). Mais ça reste jouable vu qu'il a 2 cores + l'hyper threading (ça laisse de la place pour les autres processus).

Test en lecture

Avec hdparm

sur ymir2 :

# raid5
hdparm -t -T /dev/md0
/dev/md0:
 Timing cached reads:   1426 MB in  2.00 seconds = 712.86 MB/sec
 Timing buffered disk reads: 600 MB in  3.01 seconds = 199.55 MB/sec
 
# SSD
hdparm -t -T /dev/sda
/dev/sda:
 Timing cached reads:   1436 MB in  2.00 seconds = 718.36 MB/sec
 Timing buffered disk reads: 506 MB in  3.01 seconds = 168.26 MB/sec

sur ymir :

hdparm -t -T /dev/md1
/dev/md1:
 Timing cached reads:   1152 MB in  2.00 seconds = 575.74 MB/sec
 Timing buffered disk reads:  398 MB in  3.01 seconds = 132.34 MB/sec

Avec dd

On réutilise le fichier précédemment créé et on le lis dans le vent (/dev/null) :

sur ymir2 :

# raid5
dd if=/mnt/data/test.data of=/dev/null bs=8k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 5,23449 s, 205 MB/s
 
# SSD
dd if=/tmp/test.data of=/dev/null bs=8k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 4,3989 s, 244 MB/s

Les valeurs du raid5 sont cohérentes env. 200 MB/s ; ce n'est pas le cas pour le SSD.

Attention : si on refait le “dd” plusieurs fois de suite on risque de calculer la vitesse du cache disque :

# raid5
dd if=/mnt/data/test.data of=/dev/null bs=8k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 octets (1,1 GB) copiés, 1,00804 s, 1,1 GB/s

sur ymir :

# raid0
dd if=/mnt/data/tmp/test.data of=/dev/null bs=8k
131072+0 enregistrements lus
131072+0 enregistrements écrits
1073741824 bytes (1,1 GB) copied, 9,06151 s, 118 MB/s

Étonnant : on a un meilleur débit en écriture qu'en lecture sur ce raid0…

Liens

informatique/linux/raid0_sous_linux.1298749770.txt.gz · Last modified: 2013/10/14 20:54 (external edit)