[gull] RAID 1 + LVM (ex: RAID 10)

[Frederic Dumas]

Merci Yves, merci Felix pour vos réponses.


> De toute façon avec des PV LVM partout, les "pvresize", "pvmove" et
> "dd" permettent de laisser libre court à son imagination.


Dans mon premier mail, j'essayai de tout faire à base de RAID 0 et RAID 
1 "niché" (nested). Un avis argumenté, reçu en parallèle aux vôtres, me 
fait abandonner cette approche et partir sur une configuration RAID 1 
seule, avec LVM en sandwich.

Voici le chemin garantissant l'évolution de capacité future proposée par 
l'admin avec lequel j'ai échangé par ailleurs. Je donne ce détail sur la 
liste, pensant que ça pourra être utile à d'autres dans des scénarios 
proches.



  - 1 - Configuration de départ (1200 Go)

        HDD storage: 2 x  750 Go (sda ; sdb)
        SSD storage: 1 x 1200 Go (sdc)

        RAID 1 + LVM


sda = sda1 (150) + sda2 (600) (RAID)
sdb = sdb1 (150) + sdb2 (600) (RAID)
sdc = sdc1 (600) + sdc1 (600) (RAID)
md0 = sda1 + sdb1 RAID1 (150) (EXT4 - Système)
md1 = sda2 + sdc1 RAID1 (600) (LVM)
md2 = sdb2 + sdc2 RAID1 (600) (LVM)
vg1 = md1 + md2        (1200) (LVM)
lv1 on vg1             (1200) (EXT4 - Data)


L'option --write-mostly est activée sur md1 et md2, pour profiter en 
lecture des temps d'accès et taux de transfert très supérieurs du SSD.




  - 2 - Doublement de capacité (2400 Go)

        HDD storage: 1 x  750 Go (sda)
        HDD storage: 1 x 2000 Go (sdb - remplacé)
        SSD storage: 2 x 1200 Go (sdc ; sdd - ajouté)


sda = sda1 (150) + sda2 (600)               UNCHANGED
sdb = sdb1 (150) + sdb2 (600) + sdb3 (1200) NEW
sdc = sdc1 (600) + sdc2 (600)               UNCHANGED
sdd = sdd1 (1200)                           NEW
md0 = sda1 + sdb1 RAID1 (150)               UNCHANGED
md1 = sda2 + sdc1 RAID1 (600)               UNCHANGED
md2 = sdb2 + sdc2 RAID1 (600)               UNCHANGED
md3 = sdb3 + sdd1 RAID1 (1200)              NEW
add md3 to vg1 to grow capacity to 2400
resize lv1 out of vg1 to grow to 2400


Option --write-mostly activée sur md1, md2 et md3.




  - 3 - Triplement de capacité (3600 Go)

        HDD storage: 2 x 2000 Go (sda - remplacé ; sdb)
        SSD storage: 1 x 1200 Go (sdc)
        HDD storage: 1 x 3000 Go (sdd - remplacé)


sda = sda1 (150) + sda2 (600) + sda3 (1200) NEW
sdb = sdb1 (150) + sdb2 (600) + sdb3 (1200) UNCHANGED
sdc = sdc1 (600) + sdc2 (600)               UNCHANGED
sdd = sdd1 (1200) + sdd2 (1200)             NEW
md0 = sda1 + sdb1 RAID1 (150)               UNCHANGED
md1 = sda2 + sdc1 RAID1 (600)               UNCHANGED
md2 = sdb2 + sdc2 RAID1 (600)               UNCHANGED
md3 = sdb3 + sdd1 RAID1 (1200)              UNCHANGED
md4 = sda3 + sdd2 RAID1 (1200)              NEW
add md4 to vg1 to grow capacity to 3600
resize lv1 out of vg1 to grow to 3600


Dans cette hypothèse, l'optimisation --write-mostly perd sa pertinence, 
car je suis obligé de remplacer un des deux SSD par un HDD de 3000Go, 
question de coût. La baisse du prix des SSD invalidera peut-être cette 
hypothèse plus vite que les besoins de stockage sur cette machine. Pour 
l'instant:

  :  md1 et md2 restent des grappes RAID1 HDD + SSD, sur lesquelles
     l'option --write-mostly peut rester activée;

  :  md3 et md4 redeviennent des grappes RAID1 HDD + HDD classiques




  - 4 - Décuplement de capacité

Aller au-delà impose d'installer des disques de capacité supérieure à 
2000Go. Une table GPT est obligatoire pour définir des partitions 
supérieures à cette taille. La table MBR est incompatible.

Pour permettre néanmoins au BIOS d'amorcer GRUB sur la partition système 
de 150Go, il faut garder au moins un disque compatible MBR, donc de 
capacité 2000Go maximum. On perd cependant la redondance d'un amorçage 
de GRUB possible indifféremment sur l'un ou l'autre disque de la grappe 
RAID1 md0.

La carte mère ne possède pas de firmware UEFI.




  - 5 - option --write-behind


Avez-vous une expérience de l'option --write-behind, qui permet dans une 
grappe RAID de considérer les écritures faites même lorsque seul le SSD 
a rendu la main, mais pas encore le HDD ?

Les caches en écriture ont toujours leur inconvénient. Dans le scénario 
ci-dessus, les SSD possèdent un condensateur leur permettant de finir 
toutes les écritures en cas de perte d'alimentation. Au moins un des 
deux disques de la grappe RAID aura des données valides. Reste à 
resynchroniser après l'incident. Donc a baser la sécurité des données 
sur une intervention humaine. N'est-ce pas aller au-delà des ennuis, 
pour un gain en performance difficile à quantifier ?

Connaissez-vous des sources sur le web quantifiant par des tests les 
performances supplémentaires de --write-behind face à différents type de 
charge ?


Merci pour vos avis.



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