Vous connaissez déjà LVM, le gestionnaire de volumes logiques qui permet d’agréger et de subdiviser librement vos périphériques de stockage. Eh bien, depuis quelques années, LVM permet également de définir des volumes en RAID.
LVM et RAID, version traditionnelle
Pour utiliser LVM avec du RAID, on utilise d’habitude LVM et MD, qui est l’implémentation du RAID logiciel de Linux. Pour cela, on les empile :
- soit en agrégeant ses périphériques de stockage en un volume RAID, qu’on utilise ensuite comme un volume LVM physique : il s’agit de LVM au‐dessus de RAID ;
- soit, à l’inverse, ce qui est plus compliqué, en agrégeant en RAID des volumes LVM logiques soigneusement définis : il s’agit donc de RAID par dessus LVM.
Manque de souplesse
Outre le côté un peu artificiel de cet empilement, cette solution manque de souplesse pour au moins un cas d’usage. En effet, sur un ordinateur disposant de plusieurs périphériques de stockage, on peut vouloir redonder une partie du système de fichiers en RAID, tout en laissant une autre partie sans redondance pour minimiser son utilisation du stockage. Parmi les usages qui ne méritent pas forcément une telle redondance : des films qu’on a par ailleurs sur DVD, les nouvelles Usenet ou encore des caches de divers logiciels.
Bref, ce cas d’usage passe mal. Avec du LVM sur RAID, c’est tout simplement infaisable. On peut toujours partitionner ses périphériques de stockage pour en utiliser une partie en RAID et l’autre sans, mais on retrouve alors un partitionnement statique. Avec du RAID sur LVM, c’est faisable, mais c’est une solution compliquée à gérer.
Cela passe encore plus mal avec GRUB, qui peut ne pas apprécier cet empilement et ne pas réussir à lire le système de fichiers où il doit aller chercher le noyau à démarrer. On se retrouve alors à utiliser une partition statique dédiée à /boot.
Nous en arrivons donc à cette fonctionnalité de RAID intégrée à LVM.
Rappel sur LVM
Avec LVM, on commence par formater ses périphériques de stockage pour en faire des volumes physiques LVM, ou PV pour physical volumes : ce sont des périphériques bloc, visibles dans /dev, qu’on confie simplement à LVM.
# J’ai deux périphériques, sda et sdb, avec une première partition
# système EFI, et une seconde partition avec l’essentiel de l’espace,
# qui sera utilisé avec LVM
pvcreate /dev/sda2 /dev/sdb2On agrège ensuite un ou plusieurs volumes physiques pour former un groupe de volumes, ou VG pour volume group : contrairement aux volumes physiques, les groupes de volumes ne sont qu’une abstraction de LVM et n’ont, autant que je sache, pas d’existence dans /dev.
# Je donne à mes groupes de volume le même nom que l’ordinateur
vgcreate vg-camembert /dev/sda2 /dev/sdb2On définit ensuite des volumes logiques ou LV pour logical volumes, qui sont des périphériques bloc émulés par LVM, apparaissant dans /dev et prêts à être formatés et montés pour héberger un système de fichiers.
lvcreate --size 10G --name root vg-camembert
mkfs.ext4 -L root /dev/vg-camembert/root
lvcreate --size 50G --name home vg-camembert
mkfs.ext4 -L home /dev/vg-camembert/homeLorsqu’on crée un volume logique, on doit évidemment indiquer dans quel groupe de volumes il sera mis en œuvre, mais on peut également préciser au besoin, sur quel volume physique en particulier – membre de ce groupe de volumes – il sera effectivement stocké. Cette possibilité est déjà utile pour diverses raisons, par exemple si les volumes physiques ont des caractéristiques différentes ; typiquement pour stocker des films sur un gros disque dur lent et son système d’exploitation sur un petit SSD très rapide, le tout sous LVM avec un seul groupe de volumes.
# sda est petit et rapide, parfait pour héberger /
lvcreate --size 10G --name root vg-camembert /dev/sda1
# sdb est gros et moins rapide, ce qui me convient pour /home
lvcreate --size 50G --name home vg-camembert /dev/sdb1RAID intégré à LVM
Au moment de créer un volume logique, on peut donc également indiquer qu’il s’agit d’un volume RAID, en précisant le niveau de RAID et la redondance souhaitée :
# Mieux vaut mettre / en RAID1
# Le --nosync sert à éviter l’inutile synchronisation des données
# initialement présentes
lvcreate --size 10G --name root --type raid1 --nosync vg-camembert
# Soyons fous, /home en RAID0
lvcreate --size 50G --name home --type raid0 vg-camembertOn peut aussi convertir un volume logique existant en RAID, ou à l’inverse, convertir un volume logique RAID en classique, c’est‐à‐dire linéaire — c’est leur vrai nom, ce qui peut être utile en vue d’un changement de périphérique par exemple.
La page de manuel de lvmraid(7) donne toute les informations utiles, en particulier les commandes permettant de lancer une procédure de vérification de la correspondance des données dupliquées :
lvchange --syncaction check vg-camembert/rootAvantages
L’utilisation de la fonctionnalité de RAID intégrée à LVM a l’avantage d’être simple à mettre en œuvre, il n’est ainsi plus nécessaire de se demander dans quel ordre empiler LVM et MD, ou comment organiser tout cela : il suffit d’utiliser LVM comme d’habitude, avec quelques options en plus, le fait d’être en RAID ou non étant simplement une caractéristique de chaque volume logique, qui peut même être changée a posteriori.
Les volumes logiques de type RAID sont également pris en charge par GRUB, de sorte qu’il n’est pas nécessaire de mettre en place une partition /boot séparée.
Aller plus loin
- RAID LVM dans la doc Red Hat (607 clics)
- LVM sur le wiki Gentoo (208 clics)
- Page de manuel de lvmraid(7) (380 clics)
# dm-cache?
Posté par jahman . Évalué à 1.
bonjour,
merci pour le billet, je viens d'ententre parler de dm-cache pour agréger des ssd + dd mecanique, avez vous des retours d'expérience dessus?
++
PS: sans avoir beaucoup chercher non plus, il ne me semble pas y avoir une GUI pour lvm, depuis le temps..
[^] # Re: dm-cache?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Jamais essayé, non, mais dans le même genre, avec LVM, il y a les volumes logiques de type cache-pool, cf
lvmcache(7).[^] # Re: dm-cache?
Posté par dud . Évalué à 1.
J'ai déjà utilisé lvm-cache, cela marche bien, l'impact en terme de performances est important.
Par contre j'avais essayé d'utiliser lvm-cache sur un LV en RAID0 LVM et ça n'avait pas fonctionné, LVM ne semble pas supporter ce genre d'empilement. J'avais dû recourir à md-raid pour implémenter le RAID0.
[^] # Re: dm-cache?
Posté par FantastIX . Évalué à 4.
Les distributions incluent en général, dans leur phase d'installation, un GUI pour LVM. Certes, sorti de l'installation, exit aussi l'interface graphique.
[^] # Re: dm-cache?
Posté par ʭ ☯ . Évalué à 3.
Je vais parler de ce que je connais : avec Mageia, l'interface graphique pour les disques de l'installeur est aussi disponible après dans le Centre de Contrôle Mageia. Il gère tous les exotismes tels LVM, MD, et autres systèmes de fichiers exotiques tels NTFS ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: dm-cache?
Posté par FantastIX . Évalué à 3.
Ça a l'air plutôt sexy. C'est limité à Magéia, je suppose? En tout cas, je trouve pas ça dans portage (Gentoo). Ou alors c'est inclus dans d'autres outils que je ne connais pas…
[^] # Re: dm-cache?
Posté par ʭ ☯ . Évalué à 2.
Oui, c'est aussi l'outil qui est utilisé par l'installeur Classique ou Live, donc très lié à la nébuleuse des forks Mandriva…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: dm-cache?
Posté par Arkem . Évalué à 2. Dernière modification le 25 mai 2019 à 19:43.
Tu ne veux pas plutôt parler de bcache ? Ça permet effectivement d'accélérer des disques mécaniques avec des SSD utilisés comme cache, et sans atteindre les perfs du SSD en usage direct, ça donne une bonne accélération du boot, du lancement de pas mal d'applications, et de tout ce qui nécessite l’accès à de nombreux petits fichiers en général (la taille est paramétrable)
LVM fournit aussi un mécanisme de cache similaire, mais les tests de Phoronix semblent indiquer de moins bonnes performances, mais ça reste très théorique. Tu peux utiliser BCache sur un volume LVM sans problème, en tous cas…
Au passage, je découvre un bug inquiétant sur le même site avec le noyau 5.0 et GCC9 présent sur la Fedora 30 qui incite à un peu de prudence avec les noyaux récents et ce genre de techno…
[^] # Re: dm-cache?
Posté par Arkem . Évalué à 2.
Je me répond à moi-même avec un peu de retard… effectivement, dm-cache semblent être une alternative intéressante à bcache et lvmcache, et les perfs ont l'air meilleurs, mais il faut un disque supplémentaire pour les métadonnées. Je serais aussi intéressé d'en savoir plus si quelqu'un a déjà testé
# Ça tombe à pic
Posté par flan (site web personnel) . Évalué à 3.
Merci pour ce billet, qui tombe à pic pour moi vu que j'avais du RAID à réinstaller.
Du coup, est-ce que Grub comprend tous les types de RAID LVM ? Je pense notamment au RAID 6 (de mémoire, ce n'est pas évident de faire du RAID6 mdadm pour /boot).
Je regrette qu'on ne puisse pas avoir plus de deux disques de parité en RAID6, mais ce n'est pas mieux avec mdadm.
[^] # Re: Ça tombe à pic
Posté par flan (site web personnel) . Évalué à 3.
Petite question subsidiaire : peut-on LUKSer les partitions avant le LVM ?
[^] # Re: Ça tombe à pic
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Oui, on peut, c'est ce que je fais sur mes portables. En revanche, ça ajoute un empilement que GRUB n'apprécie pas trop. De toute façon, lire du LUKS avec GRUB, je n'ai jamais essayé et pas vraiment envie de le faire.
[^] # Re: Ça tombe à pic
Posté par dud . Évalué à 4.
Grub est parfaitement capable de lire un volume LUKS version 1, il y a plusieurs articles sur le net qui détaillent comment placer la partition /boot sur un volume LUKS.
Par contre j'insiste bien sur LUKS version 1, de nombreuses distributions commencent à introduire la version 2 par défaut.
[^] # Re: Ça tombe à pic
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Je ne suis pas sûr de ce que GRUB prend vraiment en charge : pour le RAID1, j'en suis certain, mais pour le reste, il faudrait vraiment essayer.
RAID6, c'est avec deux disques de parité en effet.
# tags LVM
Posté par dud . Évalué à 8.
On peut aussi associer un tag à un volume physique, par ex. @rapide pour un SSD et @lent pour un magnétique, ce qui permet d'éviter de devoir se souvenir du nom précis du device
# BTRFS aussi
Posté par Micromy (site web personnel) . Évalué à 4.
Le raid sous LVM est effectivement un très bonne chose. Je n'avais pas trop investigué quand j'ai fait mon NAS perso en LVM au dessus de RAID (md) l'année dernière, mais j'aurais probablement dû, ça aurait été plus souple effectivement.
Après pour aller plus loin il y a aussi BTRFS. En effet ce "système de fichier" (peut-on encore l'appeler ainsi ???) permet :
- d'être déployé sur plusieurs disques,
- de mettre en place du RAID (0, 1 et 10 réputés fiables ; 5 et 6 encore incertains - voir https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices et https://btrfs.wiki.kernel.org/index.php/RAID56)
- de créer des sous-volumes, limités ou non par des quotas de volumétrie
- de créer des snapshots
Utilisant du BTRFS depuis quelques temps dans un autre contexte, la fiabilité actuelle (hors RAID et disques multiples, non testé) me semble bonne et les dernières mises à jours ont amélioré l'utilisation de l'espace disque par les métadonnées.
Reste les performances qui restent souvent en dessous d'EXT4 ou XFS (voir benchmark sur Phoronix : https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems). Donc à arbitrer en fonction de ses besoins.
[^] # Re: BTRFS aussi
Posté par damaki . Évalué à 10. Dernière modification le 24 mai 2019 à 16:02.
Btrfs marche bien jusqu'a ce qu'il ne marche plus du tout. Et quand ça ne marche pas, btrfs check ne vous sauvera sans doute pas. Pour réparer une partition BTRFS, ne comptez pas sur la doc officielle. Vous allez ajouter votre cas aux dizaines de cas non résolus sur stack overflow et compagnie.
Et si vous avez l'idée de chercher des solutions aux problèmes rencontrés, si votre partition n'est plus montable vous avez perdu.
Les features sont chouettes, mais j'en suis à la 3 ème partition pas récupérable et à 10 To de perdus. Ça n'est pas aux fonctionnalités qu'on reconnait un bon système de fichiers, c'est aux possibilités de restauration quand quelque chose part en sucette.
[^] # Re: BTRFS aussi
Posté par damaki . Évalué à 6. Dernière modification le 24 mai 2019 à 18:36.
Énervement à part, btrfs restore a l'air de faire le taf. La doc de btrfsck était pas aussi bonne la dernière fois que j'avais regardé.
Mais reste qu'après 10 ans à faire de l'administration système Linux pour mes loisirs, le seul filesystem où j'ai eu à me prendre la tête pour des restauration lors de simples pannes d'électricité ou des pannes disque partielles c'est btrfs et c'était sur du Debian stretch. Et je parle pas des données en cours d'écriture lors de la panne de courant mais de la partition elle même.
[^] # Re: BTRFS aussi
Posté par niol (site web personnel) . Évalué à 3. Dernière modification le 27 mai 2019 à 12:46.
Sauf que btrfs raid1 dégradé (avec un dique dur en panne) passe en lecture seule au deuxième boot ce qui rend le changement de disque dur et la resynchronisation beaucoup plus complexe que nécessaire. Il semble qu'il y ai maintenant une solution[1] que je n'avais pas trouvée à l'époque. En tout cas ça m'avait fait revenir à mdadm.
[1] https://unix.stackexchange.com/questions/334228/btrfs-raid1-how-to-replace-a-disk-drive-that-is-physically-no-more-there/496853#496853
# ZFS
Posté par Xavier Poinsard . Évalué à 3.
ZFS le permet aussi (https://zfsonlinux.org/). Surtout il supporte la compression. Du coup j'abandonne progressivement lvm…
[^] # Re: ZFS
Posté par Kerro . Évalué à 9. Dernière modification le 24 mai 2019 à 17:47.
De mon côté j'utilise ZFS également car :
- performances en ZRAID largement supérieures à mdadm et au RAID de LVM
- avoir trouze milles instantanés ne ralentis pas du tout ZFS, alors que ça met LVM à genoux
- compression
- les sous-volumes sont ultra faciles à gérer : il n'y a rien à gérer. Ils se partagent l'ensemble de l'espace de stockage donc on n'a pas à se préoccuper du fait que l'un est trop petit et l'autre trop gros (on peut leur appliquer une limite de taille si besoin, ça prend 10 secondes)
- si j'ai des disques-durs et des SSD ça se débrouille tout seul pour que les lectures soient réparties en fonction de la rapidité/disponibilité des disque (donc majoritairement depuis les SSD). Je crois que mdadm le fait désormais, sinon il faut l'option « write-mostly » mais c'est moins parfait. Je ne sais pas pour LVM
- la duplication vers une autre machine (aka sauvegarde via des instantanés, via logshipping) est juste magique : ça ne transfert que les données modifiées sans avoir à lire tous les fichiers, donc souvent très rapide. TOUTES les données modifiées, quels que soient les changements, même si on a restauré un fichier avec une date et une taille identique, même si on a modifié une métadonnée. Et ça ne bloque pas comme rsync sur les gros fichiers de disques virtuels
- ça fait une vérification de l'intégrité des données chaque semaine (sur Debian au moins) et ça répare tout seul sans marquer un volume physique comme HS tel que le fait mdadm
Il y a probablement des inconvénients, je ne suis pas encore tombé dessus
[^] # Re: ZFS
Posté par legranblon (site web personnel) . Évalué à 2.
Le petit plus que j'avais noté en montant un raid 1 de 3To avec zfs : 10s (pour deux disques de 3 To, oui) de formatage et c'était bon pour la prod, et ca fait sacré bon bout de temps* que ça dure …
# Outils en cas de problème
Posté par Anonyme . Évalué à 4.
Quels outils sont à la disposition de l’admin sys pour comprendre et monitorer ce qu’il se passe et pour réparer quand c’est cassé ?
Parce que mdadm est là depuis suffisamment longtemps pour que tout le monde soit au courant d’où regarder, c’est beaucoup moins le cas pour LVM, BTRFS ou ZFS (qu’on se comprenne, je dis pas qu’il ne faut pas utiliser ces FS, je les utilise moi même).
[^] # Re: Outils en cas de problème
Posté par Pol' uX (site web personnel) . Évalué à 2.
Si tu as un LVM sur un raid, le remontage en cas de casse est au niveau du RAID. Donc pas de différence avec l'usage de mdadm sans LVM.
Adhérer à l'April, ça vous tente ?
[^] # Re: Outils en cas de problème
Posté par damaki . Évalué à 1.
Je ne comprends pas trop. Dans le cas d'un raid logiciel md linux habituel, mdadm permet d'investiguer. mdadm --examine --scan, fait le taf. Il Il est aussi assez facile de retrouver dans le superblock quel disque était à quelle position dans le raid avec mdadm et de retrouver les traces des RAIDs passés. La question était au sujet des outils équivalents du monde LVM. Vu que c'est un raid LVM, ça n'est pas mdadm qui va permettre de l'investiguer, non ?
[^] # Re: Outils en cas de problème
Posté par Arkem . Évalué à 1.
Il me semble qu'une partie du code RAID d'LVM est partagé avec mdadm, donc les outils sont peut-être portable si ce n'est pas déjà fait. Jamais testé, cependant. Je suis plus à l'aise avec le sandwich classique LVM over mdadm…
[^] # Re: Outils en cas de problème
Posté par damaki . Évalué à 2.
La doc sur Debian Stretch est au poil et ça a l'air plutôt simple à manipuler. Il semble que c'était à éviter à l'époque de Wheezy et encore jeune sous Jessie. Avec Debian Buster qui pointe son nez, ça doit être mature depuis le temps.
[^] # Re: Outils en cas de problème
Posté par Arkem . Évalué à 1.
Effectivement, ça à l'air plus agréable à lire que la page de manuel. Je vais y jeter un œil. Merci pour le lien
[^] # Re: Outils en cas de problème
Posté par wismerhill . Évalué à 2.
Heu, c'est la page de manuel, le lien donné par damaki pointe vers manpages.debian.org
[^] # Re: Outils en cas de problème
Posté par Arkem . Évalué à 1. Dernière modification le 27 mai 2019 à 07:49.
Très juste, j'avais lu en diagonale au milieu des infos pour les élections, désolé. Je pensais à la page du manuel principale de LVM, en fait…
[^] # Re: Outils en cas de problème
Posté par Franck Routier (Mastodon) . Évalué à 2.
Une petite discussion en anglais sur les pour et contre du RAID LVM (in english) : https://unix.stackexchange.com/questions/150644/raiding-with-lvm-vs-mdraid-pros-and-cons
En pratique, il semble que mdadm est utilisé en sous-main par LVM pour gérer le RAID. Mais qu'à l'époque de cet échange (il y a deux ans environs), les outils d'administrations de mdadm n'étaient pas utilisables en direct… ça a peut-être évolué. A tester !
[^] # Re: Outils en cas de problème
Posté par damaki . Évalué à 1.
J'étais effectivement tombé sur cet article pour parler de la maturité des raid lvm. C'est à prendre avec de grosses pincettes vu que l'analyse se base sur Debian Jessie. Ensuite, le scénario catastrophe qu'ils décrivent à la fin se passe à peine mieux en raid 1 avec mdadm sur une debian stretch.
J'ai encore eu le cas pas plus tard qu'hier sur un serveur sur lequel un disque dur se retrouve à refuser les lectures et les écritures (sans doute soucis de cablage ou de contrôleur sas). mdadm --re-add a refusé de fonctionné à chaque fois pour remettre le raid sur les rails et j'ai du me fader une reconstruction intégrale les 3 fois avec mdadm --add où ça s'est produit.
[^] # Re: Outils en cas de problème
Posté par benoar . Évalué à 3.
Cet article raconte des conneries : ça n'est pas dmraid qui est utilisé en sous-main, LVM a son propre système de méta-données différent de dmraid, d'où l'incompatibilité des outils d'administration. Cependant, les deux technologies utilisent les devices multiples (MD) du kernel, à travers le device-mapper (DM) pour LVM ; oui, c'est pas pratique d'avoir des noms qui sont juste l'inversion de deux lettres. Bref, les algorithmes sous-jacents des différents types d'assemblage sont la même implémentation, mais la gestion « haut-niveau » est faite par des outils différents.
C'est assez courant dans le kernel, afin de ne fâcher personne et de ne pas trop lancer de flamewar : les choses assez bas niveau sont plus consensuelles que les décisions plus haut niveau, en plus généralement plus liées à l'userspace.
# Packages Grub pour Debian
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 2.
Hello,
J'avais joué à ça il y a quelques temps, les packages que j'avais recompilé pour avoir le support du RAID1 sont là (version jy) :
http://www.lenhof.eu.org/grub_debian/
L'installateur Debian ne supportait pas ça… Donc j'avais créé avec un seul PV, puis recompiler les packages grub, mis ces packages là en hold au niveau dpkg, et puis ensuite mirroré et là cela fonctionnait.
Les quelques bugs reports que j'avais créé à l'époque :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783089
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868268
Et ces 2 là ont été résolus depuis :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782580
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782591
Si quelqu'un a le courage de rebosser sur le sujet et de patcher l'installateur (j'ai un gros doute que cela ait été fait)
A votre bon cœur,
# Pas mal…
Posté par Marcel4567 . Évalué à 1.
Ces nouvelles fonctionnalités sont intéressantes dans certains cas de figures mais ne sont pas révolutionnaire. Le mirroring LVM (équivalent RAID-1) existe déjà depuis longtemps et fonctionne bien, y compris en mode cluster sur un stockage partagé.
La souplesse de LVM permet déjà de faire presque tout. Par exemple j'ai un setup avec 3 HDD en RAID5 avec md et 1 SSD tout seul. En mettant ces deux PV dans le même VG, je peux déplacer mes données entre le RAID5 et le SSD très facilement avec
pvmove.D'après mes tests, la gestion des erreurs et la reconstruction des données est plutôt efficace avec MD, a voir si ça marche aussi bien avec le raid intégré à LVM. En cas de pertes des métadonnées, LVM peut être très capricieux.
# Et faisable en ligne
Posté par benoar . Évalué à 5.
Autre avantage de LVM non cité : la conversion en RAID peut se faire en ligne sur un LV déjà existant ! Ainsi, on peut passer en RAID sans downtime, en live.
Par contre, pour ce qui est gestion dans GRUB, ça fait longtemps que j'ai laissé tomber d'essayer de jouer avec le feu : je le fais à l'ancienne avec un /boot en ext{2,3,4} séparé dans une bonne vieille partition, et tout le reste en LVM. Toutes les distros gèrent ça bien depuis des lustres, et ça évite bien des problèmes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.