Gestion de volumes RAID avec LVM

PostĂ© par (page perso) . ÉditĂ© par Davy Defaud et ZeroHeure. ModĂ©rĂ© par ZeroHeure. Licence CC by-sa.
Tags :
47
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 (+1/-0).

    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 (page perso) . ÉvaluĂ© Ă  3 (+0/-0).

      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 (+1/-0).

        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Ă© Ă  3 (+1/-0).

      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Ă© Ă  2 (+1/-0). DerniĂšre modification le 25/05/19 Ă  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 (+1/-0).

        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 (page perso) . ÉvaluĂ© Ă  3 (+1/-0).

    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 (page perso) . ÉvaluĂ© Ă  3 (+1/-0).

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

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

        PostĂ© par (page perso) . ÉvaluĂ© Ă  3 (+0/-0).

        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Ă© Ă  3 (+3/-0).

          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 (page perso) . ÉvaluĂ© Ă  4 (+1/-0).

      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Ă© Ă  7 (+7/-0).

    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 . ÉvaluĂ© Ă  4 (+4/-0).

    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 (+10/-0). DerniĂšre modification le 24/05/19 Ă  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Ă© Ă  5 (+4/-0). DerniĂšre modification le 24/05/19 Ă  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 (page perso) . ÉvaluĂ© Ă  3 (+2/-0). DerniĂšre modification le 27/05/19 Ă  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 (+3/-1).

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


    • [^] # Re: ZFS

      PostĂ© par (page perso) . ÉvaluĂ© Ă  8 (+6/-0). DerniĂšre modification le 24/05/19 Ă  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 . ÉvaluĂ© Ă  2 (+1/-0).

        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 (page perso) . ÉvaluĂ© Ă  4 (+2/-0).

    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 (page perso) . ÉvaluĂ© Ă  2 (+0/-0).

      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 (+0/-0).

        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 (+0/-0).

          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 (+1/-0).

            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 (+0/-0).

              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 (+0/-0).

                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 (+0/-0). DerniĂšre modification le 27/05/19 Ă  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 . ÉvaluĂ© Ă  2 (+1/-0).

                    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 (+0/-0).

                      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 (+1/-0).

                      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 (page perso) . ÉvaluĂ© Ă  2 (+2/-0).

    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Ă© Ă  2 (+2/-0).

    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 (+3/-0).

    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.

Envoyer un commentaire

Suivre le flux des commentaires

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