perfs x4 – optimisation d’un raid5 par la pratique

1. Prologue

tout content d’avoir 3 disques de 2to je me suis empressé de monter un raid5. j’ai naïvement pensé que les performances allaient être exceptionnelles, du fait du striping. M’étant dit que le calcul de parité serait fait par le couple CPU/mémoire et avec la config que j’ai, pas de soucis, je n’aurais que les avantages du striping.

en réalité je me suis retrouvé avec des perfs horribles en écriture, des accès en lecture et en écriture simultanés catastrophiques, des freeze du système allant jusqu’à plusieurs secondes.

pour vous donner une idée, à la louche avec rsync ça donne:
accès en lecture : 120Mo/s
accès en écriture : 80Mo/s
copie d’un fichier : 18Mo/s

Regardons de plus près ce qui ne va pas !
remonter

2. Configuration

– 3 disques 2To modèle Western Digital WD20EARS constituant un raid5 existant.
– 1 disque 2To modèle Hitache Deskstar non utilisé.
– 4Go de mémoire DDR3.
– Quad core 2.9Ghz.
remonter

3. specs et timings WD20EARS et raid5 existant

marque : Western Digital
Modèle : WD20EARS Green
taille : 2000Go (facteur 1000)
rotation : IntelliPower, environ 5400 tr/mns
cache : 64Mo
connectique: SATAII 3Go/s
Advanced Format : oui

hdparm /dev/md0: Timing cached reads:   13650 MB in  2.00 seconds = 6832.74 MB/sec
hdparm /dev/md0: Timing buffered disk reads (offset 1000 GB): 474 MB in  3.00 seconds = 157.76 MB/sec
       56 seeks/second, 17.55 ms random access time

hdparm /dev/sdb: Timing cached reads:   13024 MB in  2.00 seconds = 6518.42 MB/sec
hdparm /dev/sdb: Timing buffered disk reads (offset 1000 GB): 280 MB in  3.02 seconds =  92.67 MB/sec
       54 seeks/second, 18.33 ms random access time

hdparm /dev/sdc: Timing cached reads:   12300 MB in  2.00 seconds = 6156.28 MB/sec
hdparm /dev/sdc: Timing buffered disk reads (offset 1000 GB): 224 MB in  3.02 seconds =  74.26 MB/sec
       58 seeks/second, 17.06 ms random access time

hdparm /dev/sdd: Timing cached reads:   13140 MB in  2.00 seconds = 6576.93 MB/sec
hdparm /dev/sdd: Timing buffered disk reads (offset 1000 GB): 258 MB in  3.01 seconds =  85.73 MB/sec
       57 seeks/second, 17.47 ms random access time

remonter

4. specs et timings Hitachi Deskstar 7k2000 (disque non utilisé)

marque : Hitachi
Modèle : Deskstar 7K2000
taille : 2000Go (facteur 1000)
rotation : 7200 tr/mns
cache : 32Mo
connectique: SATAII 3Go/s
Advanced Format : non

l’ajout du disque hitachi à pris la place /dev/sdb anciennement utilisé par un WD20EARS, ne pas se fier aux assignations de ce document.

hdparm /dev/sdb: Timing cached reads:   14470 MB in  2.00 seconds = 7243.34 MB/sec
hdparm /dev/sdb: Timing buffered disk reads: 354 MB in  3.01 seconds = 117.51 MB/sec
       77 seeks/second, 12.95 ms random access time

remonter

5. qu’est ce qui peut rend ma config si lente ?

l’écriture d’un fichier est répartie sur 2 disques et le calcul de la parité s’écrit sur 1 autre disque.
le calcul de la parité implique la lecture complète des 2 autres secteurs pour s’effectuer.
le système doit certainement avoir à calculer sur quel disque écrire le fichier ou la parité.
pour la parité, 50% de données en plus sont écrites, au lieu d’écrire un fichier de 20Go, 30Go seront donc écrits
remonter

6. les différentes solution d’optimisation

1. – Utiliser un raid hardware ?

Insérer une carte additionnelle ça ajoute un composant, ça augmente donc le nombre de panne hardware possible. Cela rendrait aussi la configuration dépendante d’un chipset. Si on monte un raid matériel on est condamné à utiliser exactement le même modèle de carte raid. Et puis il n’y a pas la même flexibilité avec un raid hardware qu’avec un raid software. Par exemple si un jour je souhaite passer d’un raid 5 à un raid 10, je ne suis pas certain d’y arriver sans perdre les données.
remonter

2. – Activer le mode advanced format

Un disque AF (Advanced Format) utilise des secteurs physique de 4096 octets au lieu des 512 octets habituels. Ce type de disque commence à arriver depuis janvier 2011. Pour les systèmes ne sachant pas utiliser cette norme une couche émulation est présente faisant croire que les secteurs physique font 512 octets, le firmware du disque s’occupe de faire la translation. Activer le mode AF signifie moins d’ECC (Error correcting Code) a calculer/écrire, plus d’espace sur le disque et des accès plus rapides. Pour des secteurs physiques de 512 octets, 50 octets sont dédiés à l’ECC. Pour des secteurs physiques de 4096 octets, 100 octets sont dédiés à l’ECC.

pour se représenter l’éventuel gain du mode AF partons d’un fichier de 1Go, soit 1073741824 octets (1*1024*1024*1024).
disque qui n’est pas AF (ou pas aligné) : 1073741824 / (512 – 50) = 2324116 secteurs écrits
disque AF et aligné dans ce mode : 1073741824 / (4096 – 100) = 268704 secteurs écrits
entre 2.3 million et 270 mille secteurs écrits on gagne forcément en performances, d’ailleurs c’est autant de blocs ECC qui n’ont pas besoin d’être écrits/calculés.

Les disques WD20EARS sont à la norme AF (selon la documentation) mais rien ne permet au système de l’indiquer. En effet, lors de la lecture du type de disque les champs indiquant le mode AF sont étonnamment à zéro. Pour activer le mode AF, il suffit d’aligner le disque, c’est à dire que chaque secteur de début d’une partition doit être un multiple de 8. le secteur 2048 est conseillé en tant que secteur de début (pour une raison que j’ignore) mais vous pouvez tout à fait commencer au secteur 64. La commande « fdisk -lu /dev/sdX » permet de voir le secteur de début utilisé pour un disque, si c’est 2048, alors on est correctement aligné (un multiple de 8 est aussi correct).

INFO: si vous avez un jumper présent sur les pins 7 et 8 de votre WD20EARS alors le secteur de départ devrait être 2047 (63 marche aussi). Si votre disque n’est pas AF, ça ne vous coutera pas grand chose de commencer au secteur 2048 (1Mo d’espace perdu).
remonter

3. – Ajouter un disque dans le raid

Sur 3 disques le raid5 écrit 50% de donnée de plus et perd 33% d’espace utile car il stripe (réparti) les données sur 2 disques et ajoute l’information de parité sur le 3ème.
Sur 4 disques le raid5 écrit 33% de donnée de plus perd 25% d’espace utile car il stripe les données sur 3 disques et ajoute l’information de parité sur le 4ème.
Le rendement de place utile proportionnellement est plus grand, on écrit moins d’information de parité, les calculs sont bien moins nombreux et l’écriture est répartie sur 4 disques ce qui représente des accès plus rapides.

Prenons l’exemple d’un fichier de 36ko.
Sur un raid à 3 disques le fichier va être découpé en 2 blocs de 18ko, un 3ème bloc de 18ko représentant la parité des 2 précédents sera calculé et écrit sur le disque suivant.
Sur un raid à 4 disques le fichier va être découpé en 3 blocs de 12ko, un 4ème bloc de 12ko représentant la parité des 3 précédents sera calculé et écrit sur le disque suivant.

le temps de calcul de la parité sur 2 ou sur 3 fichiers ne devrait pas montrer de grosses différences.
par contre, le gain en écriture a de fortes chances de s’améliorer:
– moins de données écrites par disque: 12ko au lieu de 18ko.
– moins de données écrites au total: 54ko (36ko + 50%) pour 3 disques, 48ko (36ko + 33%) pour 4 disques, soit un delta de 11% ((54-48)*100)/54
– on accède simultanément à 4 secteurs au lieu de 3, ça va forcément plus vite.
remonter

4. – Transformer le raid 5 en raid 10 (tant qu’a rajouter un disque)

C’est à dire répartir l’écriture sur 2 disques, et faire un miroir de tout ça. ça semble tentant car on évite le calcul de parité qui est très pénalisant, les performance vont très nettement s’améliorer mais sur un volume de 8To il ne resterait plus que 4To utiles… On pourrait penser que le raid 10 permet une sécurisation des données sur 2 disques cependant il n’en est rien car même en croisant les disques miroir et les disques stripés sur différents contrôleurs (pour limiter les risques en cas de défaillance), en perdant 2 disques il y a une chance sur deux de tout perdre.

exemple:

controleurA      --     controleurB
    |                       |
stripe A         --     stripe B
miroir B         --     miroir A

Si l’on perd le stripe A et le miroir A, tout est perdu. C’est un cas extrême et il faut vraiment ne pas avoir eu de chance mais le simple fait de réserver 50% d’espace de stockage pour un miroir sans avoir la sécurité de garder ses données si 50% des disques tombent en panne, je ne trouve pas le ratio intéressant (dans mon cas).
remonter

5. – Le système d’économie d’énergie du disque

La gamme « green » de western digital, dont fait partie ma grappe de WD20EARS, suspend la rotation du moteur après 8 secondes d’inactivité ce qui n’est pas très bon pour les performances et tout juste horrible pour la durée de vie du disque.

Pour mettre cette suspension à environ 1 heure, la commande magique est:

# hdparm -S 242 /dev/sdX

à noter que WD recommande aussi de désactiver le Advanced Power Management avec:

# hdparm -B 255 /dev/sdX

Sur mon système hdparm ne peut pas accéder à cette option :/

pour que ce soit persistant, voici ce que j’ai ajouté dans /etc/rc.local

/usr/bin/lshw -C disk -short | \
/bin/grep WD20EARS | \
/usr/bin/awk '{print $2}' | \
while read dsk
do
  /sbin/hdparm -S 242 $dsk
done

remonter

6. – Système de fichier

—–› type du système de fichier
—–› blocksize
—–› journalisation
—–› date d’accès
—–› commit
—–› barrier
—–› indexation des repertoires
—–› extents
—–› multiblock allocation
—–› stride size (option raid)
—–› stripe width (option raid)
—–› xattr
—–› stripe cache
—–› read ahead

1) – – Type du système de fichier

Actuellement, c’est du reiserfs. Le problème de reiserfs, c’est qu’il calcule tout le temps la meilleure place ou stocker les fichiers sur le disque, et quand il n’y a pas d’activité, réorganise tout ça. J’ai principalement des problématiques d’écritures, pas de lecture, pour du stockage de data qui ne bouge que très peu je ne suis pas persuadé que reiserfs soit le mieux placé.

Je manipule des fichiers qui font plusieurs dizaine de Go, je ne peux donc pas utiliser ext2/3 car je risque d’avoir des soucis sur les fichiers plus grand que 16Go.

ext4 sait gérer des fichier de 16To et peut utiliser la notion d’extent (préallocation, espaces disques contigus, toussa) tout comme LVM, ça semble plus performant qu’une structure bloc-à-bloc. Ne serait ce que pour faire un check d’une partition, ext4 sait identifier les parties qui n’ont pas besoin d’être vérifiées (espaces vides) si l’option uninit_bg est activée, sur un filesystème de plusieurs Tera de donnée ça a son importance. Dans un futur proche ext4 saura aussi gérer undelete, c’est du plus.
remonter – Système de fichier

2) – – Choisir son blocksize

Pour s’accorder avec le mode AF et éviter des calculs inutiles le filesystème choisit doit utilise un blocksize de 4k ou du moins un blocksize qui soit un multiple de 4096.
remonter – Système de fichier

3) – – Utiliser la journalisation (ou pas)

Désactiver la journalisation représente énormément d’économie sur les accès disques, journalisation qui est constamment écrite sur les 3 disques, avec la parité etc… en cas de crash s’il y a une corruption du FS, il y a le risque de ne pas pouvoir récupérer les dernières données écrites. Dans mon cas les données ne bougent que très peu, les données très importantes sont en backup ailleurs.

INFO: au début du format ext4 des corruptions de données on été rencontrées lors de reboots sauvage, depuis le kernel 2.6.30 les corruptions ont disparues.

# tune2fs -O has_journal -o journal_data /dev/md1
# e2fsck -C 0 -f /dev/md1
# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 47,8025 s, 42,8 MB/s
2048000000 octets (2,0 GB) copiés, 33,651 s, 60,9 MB/s
2048000000 octets (2,0 GB) copiés, 33,9979 s, 60,2 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,13571 s, 959 MB/s
2048000000 octets (2,0 GB) copiés, 2,08066 s, 984 MB/s
2048000000 octets (2,0 GB) copiés, 2,07972 s, 985 MB/s
rsync
sent 3.41G bytes  received 31 bytes  42.89M bytes/sec

# tune2fs -O has_journal -o journal_data_ordered /dev/md1
# e2fsck -C 0 -f /dev/md1
# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,data=ordered,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 23,958 s, 85,5 MB/s
2048000000 octets (2,0 GB) copiés, 10,6458 s, 192 MB/s
2048000000 octets (2,0 GB) copiés, 10,2342 s, 200 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,18306 s, 938 MB/s
2048000000 octets (2,0 GB) copiés, 2,11021 s, 971 MB/s
2048000000 octets (2,0 GB) copiés, 2,12079 s, 966 MB/s
rsync
sent 3.41G bytes  received 31 bytes  84.19M bytes/sec

# tune2fs -O has_journal -o journal_data_writeback /dev/md1
# e2fsck -C 0 -f /dev/md1
# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 23,792 s, 86,1 MB/s
2048000000 octets (2,0 GB) copiés, 11,0009 s, 186 MB/s
2048000000 octets (2,0 GB) copiés, 10,6677 s, 192 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,22662 s, 920 MB/s
2048000000 octets (2,0 GB) copiés, 2,12417 s, 964 MB/s
2048000000 octets (2,0 GB) copiés, 2,08947 s, 980 MB/s
rsync
sent 3.41G bytes  received 31 bytes  86.32M bytes/sec

# tune2fs -O ^has_journal /dev/md1
# e2fsck -C 0 -f /dev/md1
# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 24,4696 s, 83,7 MB/s
2048000000 octets (2,0 GB) copiés, 11,1997 s, 183 MB/s
2048000000 octets (2,0 GB) copiés, 10,7444 s, 191 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,13533 s, 959 MB/s
2048000000 octets (2,0 GB) copiés, 2,10953 s, 971 MB/s
2048000000 octets (2,0 GB) copiés, 2,04001 s, 1,0 GB/s
rsync
sent 3.41G bytes  received 31 bytes  84.19M bytes/sec

remonter – Système de fichier

4) – – Oublier la date d’accès

à part pour des besoins particuliers on a que rarement besoin de connaitre la date du dernier accès à un fichier. En désactivant la mise à jour des inodes de chaque fichier accédé on gagne beaucoup d’accès disque.
option de montage: noatime,nodiratime
remonter – Système de fichier

5) – – commit

ext4 par défaut effectue un sync (écriture du cache sur le disque, validation de l’écriture) toutes les 5 secondes. Si l’on a pas peur de perdre les 30 dernières secondes d’écriture en cas de crash, on peut positionner le commit à 30 secondes.
option de montage: commit=30

# mount -t ext4 -o noatime,nodiratime,rw,commit=5,nobarrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 23,4979 s, 87,2 MB/s
2048000000 octets (2,0 GB) copiés, 10,36 s, 198 MB/s
2048000000 octets (2,0 GB) copiés, 11,0588 s, 185 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,12775 s, 963 MB/s
2048000000 octets (2,0 GB) copiés, 2,09707 s, 977 MB/s
2048000000 octets (2,0 GB) copiés, 2,06242 s, 993 MB/s
rsync
sent 3.41G bytes  received 31 bytes  86.32M bytes/sec

# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 24,2359 s, 84,5 MB/s
2048000000 octets (2,0 GB) copiés, 10,2009 s, 201 MB/s
2048000000 octets (2,0 GB) copiés, 10,5928 s, 193 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,16176 s, 947 MB/s
2048000000 octets (2,0 GB) copiés, 2,0919 s, 979 MB/s
2048000000 octets (2,0 GB) copiés, 2,06216 s, 993 MB/s
rsync
sent 3.41G bytes  received 31 bytes  84.19M bytes/sec

remonter – Système de fichier

6) – – Le barrier

Le mode barrier bloque l’écriture des données tant que les données précédentes n’ont pas été validées dans le journal. Cela permet une meilleure intégrité des données mais réduit les performances. Je préfère le désactiver.
option de montage: nobarrier

# mount -t ext4 -o noatime,nodiratime,rw,commit=30,barrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 23,3675 s, 87,6 MB/s
2048000000 octets (2,0 GB) copiés, 10,7954 s, 190 MB/s
2048000000 octets (2,0 GB) copiés, 11,397 s, 180 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,19164 s, 934 MB/s
2048000000 octets (2,0 GB) copiés, 2,12867 s, 962 MB/s
2048000000 octets (2,0 GB) copiés, 2,0991 s, 976 MB/s
rsync
sent 3.41G bytes  received 31 bytes  84.19M bytes/sec

# mount -t ext4 -o noatime,nodiratime,rw,commit=30,nobarrier,data=writeback,nouser_xattr /dev/md1 /data
tests écriture:
2048000000 octets (2,0 GB) copiés, 23,8044 s, 86,0 MB/s
2048000000 octets (2,0 GB) copiés, 10,7789 s, 190 MB/s
2048000000 octets (2,0 GB) copiés, 11,1349 s, 184 MB/s
tests lecture:
2048000000 octets (2,0 GB) copiés, 2,20468 s, 929 MB/s
2048000000 octets (2,0 GB) copiés, 2,08303 s, 983 MB/s
2048000000 octets (2,0 GB) copiés, 2,07459 s, 987 MB/s
rsync
sent 3.41G bytes  received 31 bytes  88.57M bytes/sec

remonter – Système de fichier

7) – – Indexation des repertoires

Indexer les répertoires permet un accès plus rapide aux données, sans contrepartie. Faire:

# tune2fs -O dir_index /dev/mdX

Pour un effet rétroactif:

# e2fsck -C 0 -D /dev/mdX

remonter – Système de fichier

8) – – Le stride size (option raid)

C’est le nombre de blocks lus/écrits avant le passage à un autre disque. Le calcul est simple, on prend le « chunk size » (mdadm –detail /dev/mdX) et on le divise par la taille du blocksize (tune2fs -l /dev/mdX) ce qui nous donne: 512 / 4 = 128

# tune2fs -E stride=128

remonter – Système de fichier

9) – – Le stripe width (option raid)

C’est le nombre de blocs utiles utilisés pas le raid. Pour le calculer il faut multiplier le stride size par le nombre de disque utiles (un raid5 de 4 disques c’est 3 disques utiles), ce qui nous donne: 128 * 3 = 384

# tune2fs -E stripe-width=384

remonter – Système de fichier

10) – – Les attributs xattr

On peut gagner un peu en désactivant les attributs étendus, cela évite de labelliser chaque fichier avec des droits d’accès particuliers.
option de montage: nouser_xattr
remonter – Système de fichier

11) – – extents vs bloc-à-bloc

Un extent regroupe/indexe autant de blocs disque que nécessaires afin de former un espace contigu de 128Mo lorsque cela est possible. Cela évite de fragmenter le filesystème, on peut en déduire une meilleure performance que ce soit en lecture ou en écriture.
remonter – Système de fichier

12) – – Le multiblock allocation

Lorsqu’un fichier doit être écrit sur le disque un allocateur de bloc doit être appelé par le système à chaque écriture pour savoir où placer les données. Pour un fichier de 100Mo par exemple, l’allocateur de bloc est appelé 25600 fois (100Mo / 4k). L’option mballloc permet d’allouer plusieurs blocs d’une seule traite, évitant ainsi des appels systèmes toujours couteux.
note: le mode mballoc n’est pour l’instant disponible que dans la version developpement de ext4.
remonter – Système de fichier

13) – – Le stripe cache

Pour calculer le meilleur ratio il faut tester. Pour cela on va purger le cache, paramétrer le stripe_cache par pas de 4096 et écrire un fichier de 2go. Logguer tous les résultats et analyser le temps que ça a pris ainsi que le taux de transfert

# stripe=4096
# while [ "$stripe" -le "40960" ]
do
   sync; echo 3 > /proc/sys/vm/drop_caches
   echo "test stripecache : $pas"
   echo $pas Q /sys/block/md0/md/stripe_cache_size
   dd if=/dev/zero of=/data/stripe_test.2g bs=4k count=500000 2>&1
   echo "---"
   stripe=$(( $stripe + 4096 ))
done |tee -a /tmp/stripe_test.2g.log

le contenu du fichier /tmp/stripe_test.2g.log devrait ressembler à:

test stripecache : 12288
2048000000 octets (2,0 GB) copiés, 35,8733 s, 57,1 MB/s
---

Une fois le meilleur ratio trouvé, ajouter la commande dans le fichier /etc/rc.local
remonter – Système de fichier

14) – – read ahead

Pour calculer le meilleur ratio il faut paramétrer le readahead par pas de 4096 et lire le fichier de 2go précédemment créé. Logguer les rsultats et analyser le temps que ça a pris ainsi que le taux de transfert

# readahead=4096
# while [ "$readahead" -le "40960" ]
do
   echo "test readahead : $readahead
   blockdev --setra $readahead /dev/mdX
   dd if=/data/stripe_test.2g of=/dev/null 2>&1
   echo "---"
   readahead=$(( $readahead + 4096 ))
done |tee -a /tmp/readahead_test.2g.log

le contenu du fichier /tmp/readahead_test.2g.log devrait ressembler à:

test readahead : 12288
2048000000 octets (2,0 GB) copiés, 17,767 s, 115 MB/s
---

Une fois le meilleur ratio trouvé, ajouter la commande dans le fichier /etc/rc.local
remonter – Système de fichier

7. – Optimiser le raid

—–› accélérer la (re)construction du raid
—–› le bitmap
—–› algorithme de répartition de la parité

1) – – Accélérer la (re)construction du raid

Ce n’est pas vraiment une optimisation des perfs directe mais ça peut quand même permettre de gagner pas mal de temps. Utiliser sysctl pour modifier le paramètre kernel suivant:

# sysctl dev.raid.speed_limit_min=50000
# echo "sysctl dev.raid.speed_limit_min = 5000" >> /etc/sysctl.conf

remonter – Optimiser le raid

2) – – Le bitmap

Lorsque qu’une écriture se fait sur le raid, la partie en cours d’écriture est marquée « dirty » et son emplacement est enregistré dans le bitmap. De cette façon si un crash se produit le raid en entier n’a pas besoin d’être resynchronisé, seulement les zones marquées « dirty ». Si comme moi votre raid est un espace de stockage et que votre disque système n’en fait pas partie, déporter le fichier bitmap sur le disque système devrait améliorer grandement les performances.

INFO: Ne faites pas ça sur un raid qui héberge votre système, renseignez vous avant, il y a des arguments à donner à votre chargeur de boot (grub/lilo).

Vu dans les commentaires d’un site:
– Une simple copie d’un fichier avec un bitmap internal ralenti les performances de 75%.
– Mettre un bitmap sur un autre disque, ralenti les performances de 3% seulement.
– Positionner à 64Mo (65536) la taille du fichier bitmap permettrait d’améliorer grandement les performances.

Même s’il est spécifié dans la manpage que c’est risqué de stocker le fichier bitmap sur un autre type de filesystème que ext2 ou ext3 j’ai décidé de le déporter sur du ext4. Si par la suite j’ai des soucis je mettrais l’information ici.

suppression puis déportation du bitmap sur un autre disque:

# mdadm --grow -b none /dev/md0
# mdadm --grow -b /tmp/bitmap.md0 --bitmap-chunk=65536 /dev/md0

remonter – Optimiser le raid

3) – – L’algorithme de répartition de la parité

mdadm gère les algorithmes suivant
– left-symmetric: backward dynamic parity distribution (défaut).
– left-asymmetric: backward parity distribution.
– right-symmetric: forward dynamic parity distribution.
– right-asymmetric: forward parity distribution.

left signifie que les données sont écrites avant les informations de parité, right signifie après.
symmetric signifie que le prochain bloc de donnée qui sera écrit après la dernière information de parité, sera sur le même disque que la parité.
asymmetric signifie que chaque répartition de bloc commence toujours sur le premier disque
rien de mieux qu’un exemple en image:

l’algo left-symmetric est le plus utilisé, je préfère en effet écrire ma donnée avant l’info de parité et je préfère aussi éviter de un changement de disque à chaque nouvelle écriture.
remonter – Optimiser le raid

7. Mise en place

1# remonter le raid en read only pour éviter d’éventuelles bizarreries
2# retirer un des 3 disques du raid5 existant
3# on a maintenant 2 disques de 2To de libre dans la machine.
faire un fdisk sur le disque non utilisé et sur celui retiré du raid en faisant commencer la première partition sur le secteur 2048.
ne pas oublier de créer une partition de type linux autoraid (0xfd)
4# créer un second raid5 avec les 2 disques libres

1# mount -o remount,ro /data
2# mdadm /dev/md0 -f /dev/sde1 -r /dev/sde1

3# fdisk /dev/sdb
3# fdisk /dev/sde

4# mdadm --create /dev/md1 -b /tmp/bitmap.md1 --bitmap-chunk=65536 --level=5 --assume-clean --raid-devices=3 /dev/sdb1 /dev/sde1 missing

état du raid auquel on a enlevé un disque

# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Thu Aug  4 19:00:04 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 : 2
    Persistence : Superblock is persistent

  Intent Bitmap : /tmp/bitmap.md0

    Update Time : Sat Nov  5 04:05:34 2011
          State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : argon:0  (local to host argon)
           UUID : 65912886:57b963c5:e31c80cb:386cd303
         Events : 1723

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
       2       0        0        2      removed

état du raid nouvellement créé

# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Sat Nov  5 04:06:27 2011
     Raid Level : raid5
     Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 3
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : /tmp/bitmap.md1

    Update Time : Sat Nov  5 04:06:46 2011
          State : clean, degraded
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : argon:1  (local to host argon)
           UUID : 169f1b59:460aaa45:906e31a2:ec9f21c4
         Events : 2

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       65        1      active sync   /dev/sde1
       2       0        0        2      removed

1# identifier le nouveau raid
2# l’ajouter dans la configuration
3# formater la partition du nouveau raid
4# désactiver la journalisation
5# monter le nouveau filesystème
6# copier les données contenues dans /data/ vers le nouveau filesystème /mnt/
7# aller faire dodo

1# mdadm --brief --detail  /dev/md1
ARRAY /dev/md1 metadata=1.2 bitmap=/tmp/bitmap.md1 name=argon:1 UUID=169f1b59:460aaa45:906e31a2:ec9f21c4

2# echo 'ARRAY /dev/md1 metadata=1.2 bitmap=/tmp/bitmap.md1 UUID=169f1b59:460aaa45:906e31a2:ec9f21c4 name=argon:1 auto=yes' >> /etc/mdadm/mdadm.conf

3# mkfs.ext4 -m 0 -O large_file -b 4096 /dev/md1

4# tune2fs -O has_journal,dir_index,large_file,extents,uninit_bg -o journal_data_writeback /dev/md1
4# tune2fs -O ^has_journal /dev/md1
4# e2fsck -C 0 -f /dev/md1

5# mount /dev/md1 /mnt

6# rsync --progress -av -h -r /data/ /mnt/

7# while tired > waiting; do some sleep; done

revenir une douzaine d’heure plus tard

sent 2637.79G bytes  received 6.07M bytes  63.68M bytes/sec
total size is 2637.44G  speedup is 1.00

1# démonter l’ancien filesystème et le nouveau
2# modifier /etc/fstab
3# monter le nouveau filesystème à la place de l’ancien
4# vérifier le montage
5# arrêter l’ancien raid
6# et le retirer de la configuration

1# umount /data ; umount /mnt

2# grep /md /etc/fstab
###/dev/md0     /data    reiserfs    auto,noatime,nodiratime,rw,nolog    0    1
/dev/md1     /data    ext4    auto,noatime,nodiratime,rw    0    1

3# mount /data

4# LANG=C df -h /data
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              3.6T  2.4T  1.2T  68% /data

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

6# grep md0 /etc/mdadm/mdadm.conf
####ARRAY /dev/md0 metadata=1.2 bitmap=/tmp/bitmap.md0 UUID=65912886:57b963c5:e31c80cb:386cd303 name=argon:0 auto=yes

on va en profiter pour faire des tests de perf sur le disque en mode non AF et en mode AF

############# MODE NON AF #############|########### MODE AF #################################
| écriture : 2.1Go 19,7343 s, 106 MB/s | écriture : 2.1Go 18,162 s, 115 MB/s                |
| Lecture  : 17,9592 s, 117 MB/s       | Lecture  : 17,8014 s, 118 MB/sl bs=4096k count=500 |
############# MODE NON AF #############|########### MODE AF #################################

on a gagné environ 10M/s en écriture en alignant le disque.

1# on ajoute le disque dans le raid
2# on vérifie
3# on fait la même chose avec le 4ème disque, le fdisk pour alignement, etc…

1# mdadm --manage --add /dev/md1 /dev/sdc1
mdadm: added /dev/sdc1
2# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdc1[3] sde1[1] sdb1[0]
      3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  0.2% (5307708/1953511936) finish=331.6min speed=97892K/sec
      bitmap: 15/15 pages [60KB], 65536KB chunk, file: /tmp/bitmap.md1
3# mdadm --manage --add /dev/md1 /dev/sdd1
mdadm: added /dev/sdd1

on regarde les détails:

# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Sat Nov  5 04:06:27 2011
     Raid Level : raid5
     Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 3
  Total Devices : 4
    Persistence : Superblock is persistent

  Intent Bitmap : /tmp/bitmap.md1

    Update Time : Sat Nov  5 18:14:46 2011
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 2

         Layout : left-symmetric
     Chunk Size : 512K

 Rebuild Status : 0% complete

           Name : argon:1  (local to host argon)
           UUID : 169f1b59:460aaa45:906e31a2:ec9f21c4
         Events : 18729

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       65        1      active sync   /dev/sde1
       3       8       33        2      spare rebuilding   /dev/sdc1

       4       8       49        -      spare   /dev/sdd1

6h30 après, la resynchronisation est terminée, on va maintenant passer d’un raid5 de 3 disques à 4 disques

# mdadm --grow /dev/md1 --raid-devices=4 --backup-file=/tmp/bck
mdadm: Need to backup 3072K of critical section..
mdadm: Cannot set device shape for /dev/md1: Device or resource busy

crotte ça ne fonctionne pas. après recherche, il suffirait de supprimer le bitmap

# mdadm --grow /dev/md1 -b none
# mdadm --grow /dev/md1 --raid-devices=4 --backup-file=/tmp/bck
mdadm: Need to backup 3072K of critical section..
# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.2
  Creation Time : Sat Nov  5 04:06:27 2011
     Raid Level : raid5
     Array Size : 3907023872 (3726.03 GiB 4000.79 GB)
  Used Dev Size : 1953511936 (1863.01 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sun Nov  6 01:15:33 2011
          State : clean, recovering
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

 Reshape Status : 0% complete
  Delta Devices : 1, (3->4)

           Name : argon:1  (local to host argon)
           UUID : 169f1b59:460aaa45:906e31a2:ec9f21c4
         Events : 23644

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       65        1      active sync   /dev/sde1
       3       8       33        2      active sync   /dev/sdc1
       4       8       49        3      active sync   /dev/sdd1
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[4] sdc1[3] sde1[1] sdb1[0]
      3907023872 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  reshape =  0.0% (630272/1953511936) finish=1445.9min speed=22509K/sec

unused devices: <none>
# echo 1445/60|bc -l
24.08333333333333333333

on en a pour 24 heures selon mdstat :/

bonne nouvelle, on peut tout à fait accéder aux données pendant la transition

# mount -t ext4 -o auto,noatime,nodiratime,ro /dev/md1 /data

j’en profite pour augmenter la vitesse de reconstruction pendant que j’y suis
car pour l’instant, ça s’effectue à 22Mo/s seulement

# sysctl dev.raid.speed_limit_min=50000
dev.raid.speed_limit_min = 50000
# cat /proc/sys/dev/raid/speed_limit_min
50000

dans mon cas, ça ne change absolument rien, suis toujours à 22Mo/s :/
une trentaine d’heure plus tard environ, la reconstruction est complète.

il reste une petite partie optimisation à finir concernant ext4 :

pour calculer le stride size, il suffit de diviser le chunk_size du raid, par la taille de bloc.

# mdadm --detail /dev/md1 |grep Chunk
     Chunk Size : 512K
# tune2fs -l /dev/md1 |grep "Block size"
Block size:               4096
# echo "512/4" |bc
128
# tune2fs -l /dev/md1 |grep stride
RAID stride:              128

c’est déjà à la bonne valeur.

pour le stripe width, il faut multiplier le stride size par le nombre de disque utile.
ici, on a un raid5 avec 4 disques, on multiplie donc le stride par 3.

# echo 128*3|bc
384
# tune2fs -l /dev/md1 |grep stripe
RAID stripe width:        256
# tune2fs -E stripe_width=384 /dev/md1
tune2fs 1.41.14 (22-Dec-2010)
Définition de la taille du « stripe width » à 384
# tune2fs -l /dev/md1 |grep stripe
RAID stripe width:        384

bien sur, il ne faut pas oublier de:
1# recréer le fichier bitmap
2# démonter le filesystème (par sécurité)
3# étendre la partition (info: environ 15 minutes pour retailler).
4# remonter le filesystème
5# vérifier

1# mdadm --grow -b /tmp/bitmap.mdX --bitmap-chunk=65536 /dev/mdX

2# umount /data

3# resize2fs /dev/md1
resize2fs 1.41.14 (22-Dec-2010)
En train de retailler le système de fichiers sur /dev/md1 à 1465133952 (4k) blocs.
Le système de fichiers /dev/md1 a maintenant une taille de 1465133952 blocs.

4# mount /data

5# LANG=C df -h /data
Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              5.4T  2.4T  3.0T  45% /data

quelques tests rapides:
écriture : (2,1 GB) copiés, 14,4973 s, 145 MB/s
lecture : (2,1 GB) copiés, 7,6808 s, 273 MB/s

écriture : (10 GB) copiés, 82,7594 s, 127 MB/s
copie : sent 10.49G bytes received 31 bytes 69.68M bytes/sec

# rsync -av --progress -h /data/test.10g /data/TMP/
sending incremental file list
test.10g
     327.45M   3%  100.08MB/s    0:01:39
       1.56G  14%   61.47MB/s    0:02:21
       2.33G  22%   66.66MB/s    0:01:59
       2.98G  28%   69.02MB/s    0:01:46
       3.67G  34%   60.58MB/s    0:01:49
       4.84G  46%   66.45MB/s    0:01:23
       6.22G  59%   66.06MB/s    0:01:03
       7.18G  68%   70.58MB/s    0:00:45
       8.46G  80%   70.16MB/s    0:00:28
       9.31G  88%   62.76MB/s    0:00:18
      10.49G 100%   66.72MB/s    0:02:29 (xfer#1, to-check=0/1)
sent 10.49G bytes  received 31 bytes  69.68M bytes/sec
total size is 10.49G  speedup is 1.00

c’est excellent comparé aux perfs d’avant, je suis tout bonnement passé de 18Mo/s à 70Mo/s.

testons avec un fichier rempli avec autre chose que des zero, j’ai un système linux qui traine dans le coin.

# rsync -av --progress -h /data/isos/UltraOS_v1.0.0.zip /data/TMP/
sending incremental file list
UltraOS_v1.0.0.zip
     331.81M   9%   78.88MB/s    0:00:38
       1.49G  43%   59.51MB/s    0:00:31
       2.24G  65%   56.29MB/s    0:00:20
       2.58G  75%   44.20MB/s    0:00:18
       2.93G  85%   56.19MB/s    0:00:08
       3.26G  95%   60.05MB/s    0:00:02
       3.41G 100%   59.49MB/s    0:00:54 (xfer#1, to-check=0/1)

sent 3.41G bytes  received 31 bytes  61.44M bytes/sec
total size is 3.41G  speedup is 1.00

61Mo/s, c’est beaucoup mieux qu’avant, c’est du x3 voire du x4 en terme de performance directe.

good raid
remonter

8. conclusion

Si l’on a pas besoin de performance pure et que l’on recherche la facilité il faut clairement se tourner vers des solutions propriétaires type synology.
mais si on aime affiner son système et profiter au mieux d’un raid, il faut très clairement l’optimiser. Je retiendrais ce qui m’a le plus « choqué » dans cette recherche d’optimisation, une copie de fichier qui auparavant se faisait à 18Mo/s et bloquait le système. Maintenant c’est du 60Mo/s continu avec des pointes à 75Mo/s et plus aucune latence système, un gain majeur !

La meilleure des optimisations a été :
– Le passage de 3 disque à 4 disques.
– L’utilisation du mode AF.
– L’externalisation du fichier bitmap.
Le reste a aussi permis de gagner beaucoup en performance mais c’est le cumul de toutes les actions qui se voit vraiment. Je ferais d’autres tests plus complet bientôt, que je déposerais ici.

EDIT: mes dernier tests remontent des taux de copie à 86Mo/s, voir le chapitre journalisation ou j’ai ajouté le relevé des taux de transfert.

remonter

9. Récapitulatif

– ajout d’un disque (raid5 à 4 disques)
– recréation de la partition commençant au secteur 2048 (Advanced Format)
– désactivation du système d’économie d’énergie des disques
– changement du système de fichier de reiserfs en ext4
– blocksize positionné à 4096
– journalisation activée
– journalisation format journal_data_writeback
– désactivation de l’access time
– commit positionné à 30 secondes
– barrier désactivé
– indexation des répertoires (b-tree)
– stride size recalculé
– stripe width recalculé
– attributs xattr désactivés
– calcul du meilleur stripe cache
– calcul du meilleur read ahead
– déport du bitmap
– vérification de l’algorithme de parité à utiliser
– utilisation d’extents
– désactivation de l’initialisation des zones vides du FS

création du FS :

# mkfs.ext4 -m 0 -O large_file -b 4096 /dev/md1

options de montage :

rw,noatime,nodiratime,commit=30,nobarrier,data=writeback,nouser_xattr

tuning ext4:

# tune2fs -O dir_index /dev/md1
# e2fsck -C 0 -D /dev/md1
# tune2fs -E stride=128
# tune2fs -E stripe-width=384
# tune2fs -O has_journal -o journal_data_writeback,dir_index,large_file,extents,uninit_bg /dev/md1
# e2fsck -C 0 -f /dev/md1

contenu du fichier /etc/rc.local :

echo 12288 > /sys/block/md1/md/stripe_cache_size
blockdev --setra 12288 /dev/md1

/usr/bin/lshw -C disk -short | \
/bin/grep WD20EARS | \
/usr/bin/awk '{print $2}' | \
while read dsk
do
  /sbin/hdparm -S 242 $dsk
done

exit 0

10. Protocole de tests

Les tests fait avec hdparm sont effectués à partir de l’offset 1000, de façon à ne pas accéder aux premiers secteurs du disque (zone la plus rapide).

# hdparm -tT --offset 1000 /dev/sdX

Pour les tests d’écriture je commence par vider le contenu du cache disque avec la commande sync puis je purge les anciennes entrée pagecache, dentries et inodes. Le taux d’écriture est obtenu avec la commande dd en lui mettant l’argument fdatasync, ce qui lui fait faire un sync complet juste avant de rendre la main. Enfin on écrit vers /dev/null pour vider un éventuel cache supplémentaire créé après dd. on refait ces opérations 3 fois de suite.

Pour les tests d’écriture, un simple dd sur le fichier anciennement créé suffit.

Pour le test rsync, il s’agit d’une copie d’un fichier de 3.41Go dans le même répertoire, je préfère ce type de tests opérationnels plutôt qu’un test de performance brute ne représentant pas réellement l’utilisation qu’on a d’un filesystème.

#!/bin/bash

DIR_TESTS=/data/stress_tests

echo tests écriture:
sync ; echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=${DIR_TESTS}/file_test.2g bs=4k count=500000 2>&1 conv=fdatasync |grep '('
dd if=/dev/zero of=/dev/null bs=4k count=500000 >/dev/null 2>&1

sync ; echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=${DIR_TESTS}/file_test.2g bs=4k count=500000 2>&1 conv=fdatasync |grep '('
dd if=/dev/zero of=/dev/null bs=4k count=500000 >/dev/null 2>&1

sync ; echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=${DIR_TESTS}/file_test.2g bs=4k count=500000 2>&1 conv=fdatasync |grep '('
dd if=/dev/zero of=/dev/null bs=4k count=500000 >/dev/null 2>&1

echo tests lecture:
dd if=${DIR_TESTS}/file_test.2g of=/dev/null 2>&1 |grep '('
dd if=${DIR_TESTS}/file_test.2g of=/dev/null 2>&1 |grep '('
dd if=${DIR_TESTS}/file_test.2g of=/dev/null 2>&1 |grep '('

echo rsync
rsync -av --progress --human-readable --progress --temp-dir=${DIR_TESTS} --stats ${DIR_TESTS}/UltraOS_v1.0.0.zip ${DIR_TESTS}/cloning |grep ^sent

rm ${DIR_TESTS}/cloning

remonter

11. liens

ces liens m’ont servis pour appréhender au mieux cet article.
Un grand merci à tout ces contributeurs indirects.

Western Digital WD20EARS Advanced Format
archlinux – advanced format
WD20EARS-Windows-7-partitioning-and-formatting
wikipedia – mdadm
write intent bitmaps
mdadm tips on Linux software RAID
External bitmap questions
RAID: Data organization and recovery
books.google.fr – Managing RAID on Linux – page 117
Linux and WDC Western Digital Advanced Format
Linux WD EARS Advanced Hard Drive Format
WD HDD lying about 4K sectors
Linux Not Fully Prepared for 4096-Byte Sector Hard Drives
Report: nine 2 TB hard drives!
How to install a WD Advanced Format Drive on a non-Windows Operating System
Raid logiciel sous Linux
Western Digital’s Caviar Green hard drive
Migrating to ext4
ext4 Performance results
seeker v2.0
raid io caclulator

remonter