[FRsAG] RAID 1 - md1: 70Mo/s - md2: 220Mo/s - ???

Frederic Dumas f.dumas at ellis.siteparc.fr
Mar 20 Aou 12:14:55 CEST 2019


Bonjour à tous,

Peut-être d'autres ont rencontré ce phénomène sur des grappes en RAID1 
logiciel (mdadm) sous Linux et pourront me conseiller.


Deux grappes constituées d'un SSD (/dev/sdb) sur un contrôleur et de 
deux HDD (/dev/sda et /dev/sdd) sur un autre contrôleur:



> /dev/md1:
>            Version : 1.2
>      Creation Time : Sat Aug 17 20:43:32 2019
>         Raid Level : raid1
>         Array Size : 585922560 (558.78 GiB 599.98 GB)
>      Used Dev Size : 585922560 (558.78 GiB 599.98 GB)
>       Raid Devices : 2
>      Total Devices : 2
>        Persistence : Superblock is persistent
> 
>      Intent Bitmap : Internal
> 
>        Update Time : Mon Aug 19 11:17:20 2019
>              State : clean     Active Devices : 2
>    Working Devices : 2
>     Failed Devices : 0
>      Spare Devices : 0
> 
> Consistency Policy : bitmap
> 
>               Name : <sanitized>:1  (local to host <sanitized>)
>               UUID : <sanitized>
>             Events : 20538
> 
>     Number   Major   Minor   RaidDevice State
>        0       8        2        0      active sync   /dev/sda2
>        1       8       17        1      active sync   /dev/sdb1
> /dev/md2:
>            Version : 1.2
>      Creation Time : Sat Aug 17 20:43:50 2019
>         Raid Level : raid1
>         Array Size : 585922560 (558.78 GiB 599.98 GB)
>      Used Dev Size : 585922560 (558.78 GiB 599.98 GB)
>       Raid Devices : 2
>      Total Devices : 2
>        Persistence : Superblock is persistent
> 
>      Intent Bitmap : Internal
> 
>        Update Time : Mon Aug 19 11:17:20 2019
>              State : clean     Active Devices : 2
>    Working Devices : 2
>     Failed Devices : 0
>      Spare Devices : 0
> 
> Consistency Policy : bitmap
> 
>               Name : <sanitized>:2  (local to host <sanitized>)
>               UUID : <sanitized>
>             Events : 12267
> 
>     Number   Major   Minor   RaidDevice State
>        0       8       18        0      active sync   /dev/sdb2
>        1       8       50        1      active sync   /dev/sdd2 



L'option --write-mostly n'est pas utilisée. Elle permet de prioriser les 
accès en lecture sur le SSD. Mais les grappes ont été construites sans 
cette option.


hdparm est le seul outil que je connaisse pour faire un test de débit en 
lecture sur une grappe en particulier, quelque soit le système de 
fichiers au-dessus.


Voilà l'étrange résultat que hdparm renvoie:

> # hdparm -t /dev/md1 /dev/md2 
>
> /dev/md1: (HDD + SSD)
>  Timing buffered disk reads: 216 MB in  3.03 seconds =  71.38 MB/sec
>
> /dev/md2: (SSD + HDD)
>  Timing buffered disk reads: 672 MB in  3.00 seconds = 223.80 MB/sec


/dev/md2 offre le taux de transfert plus ou moins attendu d'un SSD sur 
un lien SATA bridé à 300Mo/s. Par contre, le résultat de /dev/md1 semble 
démontrer que la lecture se fait exclusivement sur le HDD, ignorant 
totalement le SSD. C'est une situation à la fois curieuse et problématique.


Comment expliquer ce phénomène ?


Le seul début de piste auquel je peux penser, c'est que l'ordre 
d'assemblage des grappes n'a pas été le même pour md1 et md2:

/dev/md1 est composée de HDD1 + SDD
/dev/md2 est composée de SDD + HDD2


Quelqu'un a-t-il jamais entendu dire que l'ordre d'assemblage des 
disques dans la grappe pourrait-il avoir une conséquence sur la priorité 
de lecture depuis l'un ou l'autre périphérique ?


D'autres outils de benchmark plus sophistiqués (bonnie++, iozone3...) 
écrivant dans le système de fichiers pour faire leurs tests de 
performance. Comme des volumes logiques LVM sont intercalés entre le 
système de fichiers et les grappes RAID, je n'ai pas de moyen de 
restreindre ces tests à l'une ou l'autre grappe sous-jacente.


Évidemment, sans confirmation par un autre outil de bench, on ne peut 
pas exclure complètement que hdparm renvoie des résultats faussés, pour 
un raison obscure. Mais les valeurs affichées sont quand même signe d'un 
truc bizarre.


J'espère trouver sur la liste quelques indices permettant de comprendre 
et corriger ce "dysfonctionnement".


Merci.



--
Frédéric Dumas
f.dumas at ellis.siteparc.fr





Plus d'informations sur la liste de diffusion FRsAG