Gestion de volumes RAID avec LVM

Posté par  (site web personnel) . Édité par Davy Defaud et ZeroHeure. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
58
24
mai
2019
Administration système

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/sdb2

On 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/sdb2

On 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/home

Lorsqu’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/sdb1

RAID 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-camembert

On 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/root

Avantages

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

  • # dm-cache?

    Posté par  . É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  (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  . É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  . Évalué à 4.

      PS: sans avoir beaucoup chercher non plus, il ne me semble pas y avoir une GUI pour lvm, depuis le temps..

      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  . É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  . É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  . É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  (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  (site web personnel) . Évalué à 3.

      Petite question subsidiaire : peut-on LUKSer les partitions avant le LVM ?

      • [^] # Re: Ça tombe à pic

        Posté par  (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  . É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  (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  . Évalué à 8.

    mais on peut également préciser au besoin, sur quel volume physique en particulier – membre de ce groupe de volumes – il sera effectivement stocké.

    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  (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  . É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  . É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  (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  . Évalué à 3.

    ZFS le permet aussi (https://zfsonlinux.org/). Surtout il supporte la compression. Du coup j'abandonne progressivement lvm…

    • [^] # Re: ZFS

      Posté par  . É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

  • # Outils en cas de problème

    Posté par  . É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  (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  . É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  . É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  . É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  . É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  . É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  . É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  (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  . É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  . É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  (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  . É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  . É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.