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@ellis.siteparc.fr