Les Physical Extend (PE)
Un extend ou « physical extend, aussi appelé PE, est un tout petit morceau d’un groupe de volumes. Au moment de la création d’un vg, le ou les disques placés dans ce groupe de volume sont découpés en morceaux de quelques Mo (4 Mio par défaut). Ensuite, lors de la création d’un volume logique, LVM va utiliser autant de PE que nécessaires pour se rapprocher le plus près possible de la taille demandé. La taille réelle d’un volume logique sera donc toujours un multiple de la taille d’un PE.
L’option ‘-s’ de la commande vgcreate permet justement de modifier la taille des PE. Pourquoi vouloir la modifier ? Historiquement, il y avait un nombre maximum de PE par disque physique. Même si, avec LVM2, ce n’est plus le cas, il est inutile d’utiliser des ressources cpu, et surtout mémoire, en utilisant beaucoup plus de PE que nécessaire. Si vous n’avez qu’un petit espace de stockage à gérer (quelques centaines de Go), la taille par défaut conviendra très bien. Mais si vous voulez manipuler des groupe de volume contenant plusieurs To de donnés, alors il peut être judicieux de choisir dès le départ une taille de PE plus importante (32 ou même 64 Mo par exemple). Attention, si vous faites plusieurs groupes de volumes, essayez toujours de prendre des tailles de PE identiques. Cela vous permettra si nécessaire de fusionner les groupes de volumes. Il est en effet impossible de fusionner (vgmerge) des groupes de volumes ayant des tailles de PE différentes.
La politique d’allocation
Lorsqu’on crée un volume logique (lvcreate), lvm choisit donc des PE disponible pour constituer le nouveau volume. La méthode utilisé pour ce choix est la méthode d’allocation (allocation policy en bon anglais). Je vous conseille d’aller jeter un coup d’oeil au man de lvm sur le sujet. En résumé, la politique par défaut conviendra parfaitement à 99,99% des gens. Il n’y a que dans des cas très, très précis que l’on pourrait vouloir la modifier pour utiliser le mode « contiguous » par exemple. Dans ce mode, un volume logique ne peut être crée que si il est possible d’allouer tous ses PE de façon contigu. On perd donc en grande partie la souplesse de LVM ! Mais on est alors certain de ne pas « fragmenter » le volume.
Résolution de problème
LVM est extrêmement fiable. Vraiment. Il reste forcément encore des bugs à droite à gauche, mais par expérience, il vous sera toujours possible de retrouver vos données quoi que vous fassiez. (Je parle bien sur des problèmes logiciels hein… Si c’est le disque dur qui tombe en panne, la bien sur…) Bref, de très nombreux mécanismes sont mis en place pour tout sécuriser.
L’ensemble des opérations réalisés donne lieu à un archivage des configurations LVM. Vous les trouverez dans : /etc/lvm/archive. La version actuelle de la configuration se trouve elle dans : /etc/lvm/backup. Je vous invite vraiment à jeter un oeil à ces fichiers textes. Ils sont assez simple à comprendre et décrivent très simplement l’organisation du groupe de volume en question. Cette configuration se trouve également dans ce que l’on appelle la VGDA. (Une partie du disque crée lors de la commande pvcreate). Ces informations sont vitales pour le bon fonctionnement de LVM. Il est donc possible de créer 2 VGDA par disques (la première sera crée au début du disque, l’autre tout à la fin). Voir l’option ‘–metadatacopies’ de pvcreate. A l’inverse, il peut d’ailleurs être intéressant pour des problèmes de performance de ne pas créer de vgda sur certains disques, si le groupe de volume contient un très grand nombre de disques physique (Cas de figure possible en entreprise avec de grosses baies de disques etc).
Des commandes très simples à utiliser existent pour les cas d’urgence : vgscan, vgcfgbackup, vgcfgrestore… Cette dernière commande permet, à partir d’un des fichiers de configuration présent dans /etc/lvm/archives (ou backup) de restaurer l’état du disque tel qu’il était à ce moment la. Testé et approuvé !
Enfin, dans les cas les plus désespérés, les informations de ce thread peuvent aussi être utiles. En résumé un PV est toujours constitué de 512 octets (contenu aléatoire) des méta data, puis des données elles mêmes.
LVM et RAID
Il est tout à fait possible d’utiliser LVM sur un volume en RAID logiciel. Une fois que le RAID a été créé, il suffit de le donner à LVM, avec la commande habituelle (pvcreate /dev/md0).
Bien qu’il soit possible de partitionner le raid /dev/md0 comme n’importe quel disque ordinaire (ce qui permet d’obtenir des devices de la forme /dev/md0p1, /dev/md0p2 etc), je vous le déconseille vivement. En effet le but est bien d’utiliser lvm pour découper l’espace, et plus l’ancienne notion de partition physique. De plus, l’utilisation de ces partitions nécessiterait des changements dans la configuration de lvm (filter dans /etc/lvm/lvm.conf). Bref, C’est se vraiment se donner du mal pour rien.
Références
Vous trouverez bien d’autres informations sur les pages suivantes :
http://www.centos.org/docs/5/html/Cluster_Logical_Volume_Manager/index.html
http://www.korben.info/comment-chiffrer-une-partition-systeme-linux-ici-ubuntu.html#comment-164907
Et enfin, toujours pour information et parce que je sens que si je ne l’indique pas cela va me retomber dessus un jour ou l’autre… Merci à toutes les personnes qui se posent des questions sur la ressemblance de contenu entre les pages de ce blog et celles d’ubuntu-fr de lire ceci.
