Linux, GPT, LVM et Intel Matrix Storage, j'ai loupé un truc ?

Bonsoir les gens,

En ce moment à mon taf, je suis en train de préparer un serveur pour un site distant (ROBO, Remote Office/Branch Office, comme on dit dans le marketing IT).
C'est une petite machine HP Proliant ML10 Gen9 bien sympathique, qui dispose de 2 HDD de 1 To (*).
Comme c'est de l'entrée de gamme, il n'y a pas de carte RAID hardware mais le chipset et l'UEFI fournissent de l'Intel Matrix Storage. Du fakeraid en somme. Très bien, ça fera l'affaire.

Je configure mon RAID 1 dans l'UEFI, c'est très simple.
Ensuite j'installe mon CentOS 7.4 dessus, aucun soucis.

Une fois sur l'OS, j'ai été agréablement surpris de voir que mon RAID était géré par mdadm. Ceci dit je ne sais pas si c'est pareil sur d'autre marque de chipset qui font du fakeraid… Enfin bref là c'est géré par le "pilote" imsm (pour "Intel Matrix Storage Management" je suppose).

Là où est mon problème c'est que contrairement à un "vrai" RAID hardware (comme j'ai pu touché avec du HP ACU), je vois toujours mes disques individuels (sda et sdb quoi !) en plus de mon volume RAID.
En gros j'ai ça :
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 200M 0 part
├─sda2 8:2 0 1G 0 part
├─sda3 8:3 0 87,8G 0 part
├─sda4 8:4 0 842,6G 0 part
└─md126 9:126 0 931,5G 0 raid1
├─md126p1 259:0 0 200M 0 md /boot/efi
├─md126p2 259:1 0 1G 0 md /boot
├─md126p3 259:2 0 87,8G 0 md
│ ├─centos_serv-root 253:0 0 80G 0 lvm /
│ └─centos_serv-swap 253:1 0 7,8G 0 lvm [SWAP]
└─md126p4 259:3 0 842,6G 0 md
sdb 8:16 0 931,5G 0 disk
├─sdb1 8:17 0 200M 0 part
├─sdb2 8:18 0 1G 0 part
├─sdb3 8:19 0 87,8G 0 part
├─sdb4 8:20 0 842,6G 0 part
└─md126 9:126 0 931,5G 0 raid1
├─md126p1 259:0 0 200M 0 md /boot/efi
├─md126p2 259:1 0 1G 0 md /boot
├─md126p3 259:2 0 87,8G 0 md
│ ├─centos_serv-root 253:0 0 80G 0 lvm /
│ └─centos_serv-swap 253:1 0 7,8G 0 lvm [SWAP]
└─md126p4 259:3 0 842,6G 0 md

Bref tout est visible en double, ou en quadruple même du coup…
Là où ça me gène c'est quand je lance la commande :
$ gdisk /dev/sda (ou sdb)
commande v (pour vérifier si tout est OK avec GPT)

Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.

Identified 1 problems!

J'ai tenté quelques manips pour essayer de réparer cela mais en vain. Sans être expert, je comprends quand même assez bien ce que je fais avec le MBR/GPT en temps normal. Mais là avec ce Matrix Storage je comprends rien, je ne sais pas si tout ce merdier est normal :D

Mais bon bref, je me suis dit que ça devait l'être… après tout j'ai juste configuré le RAID dans l'UEFI et lancé l'installation de CentOS dessus ensuite, je vois pas ce que j'aurais pu merder ! :D

Là où ça devient vraiment bloquant, c'est quand j'ai essayé de créer un volume avec LVM.
Sur la sortie du lsblk ci-dessus, vous voyez sd[ab]4 et leur équivalent md126p4. En fait elle n'y était pas quand j'ai installé l'OS. Je l'ai rajouté post-install avec :
$ gdisk /dev/md/Volume1 (c'est le nom par défaut du volume matrix storage en fait)
=> création d'une partition LVM
$ partprobe
Et voilà ma partition md126p4 qui est apparue.

Donc maintenant je crée un PV :
$ pvcreate --verbose /dev/md/Volume1p4
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
Wiping internal VG cache
Wiping cache of LVM-capable devices
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sda3 was already found on /dev/md126p3.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sdb3 was already found on /dev/md126p3.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because device is used by LV.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because device is used by LV.
Wiping signatures on new PV /dev/md/Volume1p4.
Set up physical volume for "/dev/md/Volume1p4" with 1766975455 available sectors.
Zeroing start of device /dev/md/Volume1p4.
Writing physical volume data to disk "/dev/md/Volume1p4".
Physical volume "/dev/md/Volume1p4" successfully created.

=> donc ça marche, le PV est créé.

Notez les warning bien flippants…
Ils apparaissent à chaque fois que je fais un truc avec du LVM, genre un simple "pvdisplay".

Ensuite je créé un VG :
$ vgcreate --verbose vg_data /dev/md/Volume1p4
WARNING: Not using lvmetad because duplicate PVs were found.
WARNING: Use multipath or vgimportclone to resolve duplicate PVs?
WARNING: After duplicates are resolved, run "pvscan --cache" to enable lvmetad.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sda3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sda4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sdb3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sdb4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because device is used by LV.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because device is used by LV.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because device is in subsystem.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because device is in subsystem.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sda3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sda4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sdb3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sdb4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because of previous preference.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because of previous preference.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because of previous preference.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because of previous preference.
Wiping internal VG cache
Wiping cache of LVM-capable devices
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sda3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sda4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS on /dev/sdb3 was already found on /dev/md126p3.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv on /dev/sdb4 was already found on /dev/md126p4.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because of previous preference.
WARNING: PV MvAtEr-iFlG-JALg-vQSM-ysTs-Ll5c-rcwtTS prefers device /dev/md126p3 because of previous preference.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because of previous preference.
WARNING: PV 51NWk1-HcK9-EsIg-tedh-56Jy-qofs-B1nRCv prefers device /dev/md126p4 because of previous preference.
Cannot use device /dev/md/Volume1p4 with duplicates.

=> impossible de créer un VG

Que pensez-vous de tout cela ?
C'est normal d'avoir des conflits d'UUID comme ça sur des configs Matrix Storage ?

(*) Petite remarque qui n'a aucun lien avec mon post, mais les HDD sont des Seagate "grand public". Donc même pas de TLER pour le RAID. C'est quand même con qu'HP vende des serveurs (livrés de base avec 2 HDD) qui n'ont même pas le minimum syndical pour faire du RAID.

# Masquer les disques gênants ?

Posté par Skanx (site web personnel) le 21 septembre 2017 à 00:36. Évalué à 2.

Salut,
Je ne sais pas dire si le comportement de ton Matrix Storage est normal, mais si tu veux exploiter ton LVM, et éviter les mauvaises manipulations, tu peux masquer les devices membres de ton RAID dans /etc/lvm/lvm.conf (option filter si je me souviens bien).
Sinon, si j'ai bien compris, TLER n'est pas utile avec mdadm (il aurait d'autres critères pour déterminer qu'un disque ne répond plus qu'un contrôleur RAID hardware), peut-être que c'est le cas aussi avec Matrix Storage ? Quoi qu'il en soit, côté fiabilité du disque, c'est moyen de la part d'HPE de fournir des disques grand public dans un serveur…
- [^] # Re: Masquer les disques gênants ?
  
  Posté par WhiteCat le 21 septembre 2017 à 11:11. Évalué à 2.
  
  tu peux masquer les devices membres de ton RAID dans /etc/lvm/lvm.conf (option filter si je me souviens bien).
  
  Génial ! J'ai masqué mon sda et sdb avec l'option "global_filter" et maintenant je n'ai plus de warning et j'ai pu créer mon VG.
  Merci pour l'astuce.
  
  Sinon, si j'ai bien compris, TLER n'est pas utile avec mdadm (il aurait d'autres critères pour déterminer qu'un disque ne répond plus qu'un contrôleur RAID hardware), peut-être que c'est le cas aussi avec Matrix Storage ?
  
  D'après Wikipedia, ça a son importance aussi pour les softraid, bien que ça soit très spécifique à chaque implémentation. Apparemment sous FreeBSD par exemple, ça n'aurait pas d'importance. Avec mdadm, a priori non plus sauf que c'est la pile SCSI de Linux qui a un timeout de 30 secondes par défaut, donc TLER aurait son intérêt quand même.
# ne pas utiliser le raid du bios/uefi

Posté par NeoX le 22 septembre 2017 à 10:55. Évalué à 3.

simplifie toi la vie,
le fakeraid n'apporte rien puisque c'est le pilote dans l'OS qui va faire le boulot,

aussi ne fait pas le raid dans l'UEFI, tu vois alors tes 2 disques au moment d'installer l'OS, et tu configures le RAID à ce moment là,
- [^] # Re: ne pas utiliser le raid du bios/uefi
  
  Posté par WhiteCat le 24 septembre 2017 à 00:58. Évalué à 2.
  
  Oui tu as raison, je crois que je vais partir sur une nouvelle installation complètement en softraid.
  À la base j'avais peur que ça soit compliqué, mais visiblement c'est très simple à installer en RAID 1 depuis anaconda.
  Par contre c'est carrément dommage qu'anaconda crée des tables de partitions MBR au lieu de GPT !
  - [^] # Re: ne pas utiliser le raid du bios/uefi
    
    Posté par WhiteCat le 25 septembre 2017 à 15:09. Évalué à 2.
    
    En fait si, sur le serveur (qui a un BIOS UEFI), la table de partition est bien créée en GPT par anaconda (ce qui est obligatoire pour l'UEFI).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.

# Masquer les disques gênants ?

[^] # Re: Masquer les disques gênants ?

# ne pas utiliser le raid du bios/uefi

[^] # Re: ne pas utiliser le raid du bios/uefi

[^] # Re: ne pas utiliser le raid du bios/uefi