Template:Linux RAID performances

Je ne parlerais des différents Raid, mais vous laisserais plutôt Wikipedia pour cela. Pour l'utilisation d'un RAID software sous Linux, je vous recommande cette documentation. Nous parlerons plutôt des performances puisque c'est le sujet ici. Le RAID 0 est le plus performant de tous les raid, mais il connait évidement ses problèmes de sécurité des données lors de la perte d'un disque.

Le MTBF (Mean Time Between Failure) est également important sur les RAID. C'est une estimation du bon fonctionnement du RAID avant qu'un disque soit détecté comme défaillant.

1 Chunk size

La "Chunck size" (ou taille du stripe ou encore element size pour certains revendeurs) est le nombre (en taille de segments (KiB)) de données écrites ou lues pour chaque périphérique avant le déplacement sur un autre segment. L'algorithme de déplacement utilisé est le Round Robin. La chunk size doit être un entier, multiple de la taille d'un block. Plus la taille des chunk est grande, plus la vitesse d'écriture est rapide sur les données de très grosse capacité, mais inversement est lente sur les petites données. Si la taille moyenne est requêtes IO est plus petite que la taille d'un chunck, la requête sera alors placée sur un seul disque du RAID, annulant tout les avantages du RAID. Réduire la taille de la chunck size, découpera les gros fichiers en plus petits qui seront répartis sur plusieurs disques ce qui améliorera les performances. Cependant le temps de positionnement des chunk sera réduit. Certains matériels ne permettent pas l'écriture tant qu'un stripe n'est pas complet, annulant cet effet de latence de positionnement.

Une bonne règle pour définir la chunk size est de diviser environ la taille des opération IO par le nombre de disques sur le RAID (enlevez les disques de parités si RAID5 ou 6).

Notes

Petit rappel : Raid 0 : Pas de parité Raid 1 : Pas de parité Raid 5 : 1 disque de parité Raid 6 : 2 disque de parité Raid 10 : Pas de disques de parité

Si vous n'avez aucunes idées de vos IO, prenez une valeur entre 32KB et 128KB en prenant un multiple de 2KB (ou 4KB si vous avez des tailles de blocks plus grandes). La chunk size (taille du stripe) est un facteur important sur les performances de votre RAID. Si le stripe est trop large, le raid peut avoir un "hot spot" qui sera le disque qui recevra le plus d'IO et réduira les performances de votre RAID. Il est évident que les meilleures performances sont lorsque les données sont éclatées sur tous les disques. La bonne formule est donc :

Chunk size = average request IO size (avgrq-sz) / number of disks

Pour obtenir la taille des requêtes moyennes, je vous invite à faire un tour sur la documentation sur Systat ou l'on parle d'Iostat et de Sar.

• Pour voir la chunk size sur un RAID (ici md0) :

> cat /sys/block/md0/md/chunk_size 131072

Il est donc ici de 128KB.

Voici une autre façon de le voir :

cat

> cat /proc/mdstat Personalities : [raid10] md0 : active raid10 sdc2[3] sda2[1] sdb2[0] sdd2[2] 1949426688 blocks super 1.0 128K chunks 2 near-copies [4/4] [UUUU]  unused devices: <none>

Ou bien encore :

mdadm

> mdadm --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Sat May 12 09:35:34 2012 Raid Level : raid10 Array Size : 1949426688 (1859.12 GiB 1996.21 GB) Used Dev Size : 974713344 (929.56 GiB 998.11 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent   Update Time : Thu Aug 30 12:53:20 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0   Layout : near=2 Chunk Size : 128K  Name : N7700:2 UUID : 1a83e7dc:daa7d822:15a1de4d:e4f6fd19 Events : 64   Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 2 1 active sync /dev/sda2 2 8 50 2 active sync /dev/sdd2 3 8 34 3 active sync /dev/sdc2

• Il est possible de définir la chunk size à la création du RAID avec l'argument -c ou --chunk. Nous allons également voir comment le calculer au mieux. Utilisons d'abord iostat pour récupérer la valeur avgrq-sz :

iostat

> iostat -x sda 1 5   avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,21 0,00 0,29 0,05 0,00 99,45 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm  %utilsda 0,71 1,25 1,23 0,76 79,29 15,22 47,55 0,01 2,84 0,73 0,14  avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,00 0,00 0,00 0,00 0,00 100,00   Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm  %util sda 0,00 0,00 1,00 0,00 16,00 0,00 16,00 0,00 1,00 1,00 0,10   avg-cpu:  %user  %nice %system %iowait  %steal  %idle 0,00 0,00 0,00 0,00 0,00 100,00

Faisons ensuite le calcul pour obtenir la chunk size en KiB :

echo

> echo "47.55*512/1024" | bc -l 23.77500000000000000000

Nous devons ensuite diviser cette valeur par le nombre de disques (admettons 2) et l'arrondir au multiple de 2 plus proche :

Chunk Size(KB) = 23.775/2 = 11.88 ? 8

Ici la chunk size à mettre est de 8, puisque c'est le multiple de 2 qui se rapproche le plus de 11.88.

WARNING

Rappelez vous qu'il n'est pas conseillé de descendre en dessous de 32K !

Pour créer un raid 0 en définissant la chunk size :

mdadm -C /dev/md0 -l 0 -n 2 --chunk-size=32 /dev/sd[ab]1

2 Stride

Le Stride est un paramètre que l'on passe lors de la construction d'un RAID qui permet d'optimiser la façon dont le filesystem va placer ses blocks données sur les disques avant de passer aux suivants. Avec de l'extXn on peut optimiser en utilisant l'option -E qui correspond au nombre de filesystems blocks dans un chunk. Pour calculer le stride :

Stride = chunk size / block size

Pour un raid 0 ayant un chunk size de 64KiB (64 KiB / 4KiB = 16) par exemple :

mkfs.ext4

mkfs.ext4 -b 4096 -E stride=16 /dev/mapper/vg1-lv0

Certains contrôleurs disques font une abstraction physique des groupes de blocks rendant impossible au kernel de les connaitre. Voici un exemple pour voir la taille d'un stride :

dumpe2fs

> dumpe2fs /dev/mapper/vg1-lv0 | grep -i stride dumpe2fs 1.42 (29-Nov-2011) RAID stride: 16

Ici, la taille est 16 KiB.

Pour calculer le stride, il existe un site web également : http://busybox.net/~aldot/mkfs_stride.html

3 Le Round Robin

Les RAID sans parités permettent de segmenter les données à travers de multiple disques pour augmenter les performances en utilisant l'algorithme Round Robin. La taille des segments est définit à la création du RAID et fait référence à la chunk size.
La taille d'un RAID est définit par le disque le plus petit lors de la création du RAID. La taille peut varier dans le futur si tous les disques sont remplacés par des disques de plus grosse capacité. Une resynchronisation des disques se fera et le filesystem pourra être étendu.

Donc pour le tuning du Round Robin, il vous faut correctement tuner la chunk size et le stride pour que l'utilisation de l'algorithme soit optimale ! C'est tout :-)

4 Les RAIDs à parité

Une des grosses contraintes de performances des RAID 5 et 6 est le calcul des parités. Pour que les données y soient écrites, il faut que le calcul de parité soit effectué sur le raid au préalable. et ce n'est seulement ensuite que la parité et les données peuvent y être écrites.

WARNING

Evitez les RAID 5 et 6 si l'écriture de vos données représentent + de 20% de l'activité

Chaque mise à jour de données requiert 4 opérations de type IO :

1. Les données à mettre à jour sont d'abord lues des disques
2. Mise à jour des nouvelles données (mais la parité n'est pas encore correcte)
3. Lecture des blocks du même stripe et calcul de parité
4. Écriture définitive des nouvelles données sur disques et de la parité

En RAID 5, il est conseillé d'utiliser le cache du stripe :

echo

echo 256 > /sys/block/md0/md/stripe_cache_size

Pour plus d'informations sur les optimisations des RAID : http://kernel.org/doc/Documentation/md.txt. Pour la partie optimisation, regardez les paramètres suivants :

• chunk_size
• component_size
• new_dev
• safe_mode_delay
• sync_speed_{min,max}
• sync_action
• stripe_cache_size

5 Le RAID 1

Le driver RAID effectue une écriture dans le bitmap lorsque des changements ont été détectés depuis la dernière synchronisation. Un inconvénient majeure du RAID 1 est lors d'une coupure de courant, puisque celui ci doit se reconstruire intégralement. Avec la 'write-intent' bitmap,seul les parties qui ont changées auront à être synchroniser, ce qui réduit grandement le temps de reconstruction.

Si un disque tombe en panne et est retiré du RAID, md arrête l'effacement des bits dans la bitmap. Si ce même disque est de nouveau introduit dans le RAID, md n'aura qu'à resynchroniser la différence. Lors de la création du RAID, si l'option '--write-intent' bitmap est combinée avec '--write-behind', les requêtes d'écritures vers des périphériques ayant l'option '--write-mostly' n'attendront pas que les requêtes soient complète avant d'écrire sur le disque. L'option '--write-behind' peut être utiliser pour les RAID1 avec liaisons lentes.

Les nouvelles matrices mdraid prennent en charge l'utilisation de write intent bitmaps. Ceci aide le système à identifier les parties problématiques d'une matrice ; ainsi, au cas où il se produirait un arrêt incorrect, les parties problématiques devront être resynchronisées, et non le disque entier. Cela permet de réduire de manière drastique le temps requis pour effectuer une resynchronisation. Des matrices nouvellement créées auront automatiquement un write intent bitmap ajouté lorsque possible. Par exemple, les matrices utilisées comme swap et les matrices de très petite taille (telles que les matrices /boot) ne bénéficieront pas de l'obtention de write intent bitmaps. Il est possible d'ajouter write intent bitmap aux matrices existant précédemment une fois que la mise à jour sur le périphérique est terminée via la commande mdadm --grow. Cependant, write intent bitmaps n'encourt pas d'impact sur la performance (environ 3-5% sur un bitmap d'une taille de 65536, mais peut augmenter jusqu'à 10% ou plus sur des bitmaps de plus petite taille, tels que 8192). Cela signifie que si write intent bitmap est ajouté à une matrice, il est préférable de conserver la taille relativement grande. La taille recommandée est 65536.

Pour voir si un RAID est bien persistant :

mdadm

> mdadm --detail /dev/md0 /dev/md0: Version : 1.0 Creation Time : Sat May 12 09:35:34 2012 Raid Level : raid10 Array Size : 1949426688 (1859.12 GiB 1996.21 GB) Used Dev Size : 974713344 (929.56 GiB 998.11 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent  Update Time : Thu Aug 30 16:43:17 2012 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0   Layout : near=2 Chunk Size : 128K   Name : N7700:2 UUID : 1a83e7dc:daa7d822:15a1de4d:e4f6fd19 Events : 64   Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 2 1 active sync /dev/sda2 2 8 50 2 active sync /dev/sdd2 3 8 34 3 active sync /dev/sdc2

Pour ajouter le write intent bitmap (interne) :

mdadm

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

Pour ajouter le write intent bitmap (externe) :

mdadm

mdadm /dev/md0 --grow --bitmap=/mnt/mon_fichier

Et pour le retirer :

mdadm

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

Pour définir le disque lent et celui le plus rapide :

mdadm

mdadm -C /dev/md0 -l1 -n2 -b /tmp/md0 --write-behind=256 /dev/sdal --write-mostly /dev/sdbl