La gestion de “volumes logiques” est issue principalement de la demande de besoins de stockage sur de nombreux disques. Un administrateur système est en général soumis à deux contraintes :
Afin de pouvoir concilier sereinement les deux aspects, on a introduit un sytème permettant de créer des lens arbitraires entre les “volumes physiques” (ce qui est concrètement disponible) et les “volumes logiques” (ce qui doit être présenté aux applicatifs et aux utilisateurs).
Il faut un composant noyau et divers outils pour faire fonctionner un gestionnaire de volumes logiques. On note que dans la série 2.6 du noyau Linux un système générique (device mapper) a été créé pour être partagé par différents gestionnaires:
Gestionnaire | Composant noyau | Outils |
---|---|---|
LVM | lvm | lvm |
LVM2 | device-mapper | libdevmapper + lvm2 |
EVMS | device-mapper | libdevmapper + evms |
La préparation “classique” d'un système de fichiers se décompose en général en 3 niveaux distincts :
Pour appliquer le principe de LVM, on voit qu'il nous faut ajouter un mécanisme d'indirection entre les couches bas niveau (disque dur, partitions) et le système de fichier. En d'autres termes, LVM est un outil qui va créer des block device virtuels, utilisables comme des disques ou partitions classiques: on pourra donc réutiliser toutes les notions standards d'administration que l'on connaît.
Il s'agit de la notion centrale de LVM: la première opération lors de la configuration de LVM consiste à créer au moins un Volume Group. Ce dernier se considère de deux points de vue:
/dev/hda1 --\ /--> /dev/vg-filer/eleves --> /mnt/eleves |--> vg-filer --| /dev/hdc --/ \--> /dev/vg-filer/profs --> /mnt/profs
Sous réserve de la création correcte des Physical Volumes (voir ci-dessous), on peut configurer et activer le Volume Group de cet exemple ainsi :
#vgcreate vg-filer /dev/hda1 /dev/hdc #vgchange -ay vg-filer #vgdisplay
Il s'agit des éléments physiques de stockage (à gauche sur le schéma précédent), qui sont des block devices quelconques (en pratique: des paritions ou des disques entiers). Il est toutefois nécessaire d'initialiser ces block devices qui vont être agrégés dans un même Volume Group:
#pvcreate /dev/hda1 #pvcreate /dev/hdc #pvdisplay
Il est également recommandé pour les partitions d'utiliser le type dédié (8e), il permet notamment aux divers composants logiciels non-LVM de reconnaître qu'elles sont utilisées par LVM.
Il s'agit de la partie utile d'un Volume Group, celle où l'on va pouvoir créer nos systèmes de fichiers. L'opération ressemble beaucoup à un partitionnement, elle remplace en effet le découpage au niveau disque mais au niveau logique (en beaucoup plus souple comme nous allons le voir). Par exemple:
#lvcreate -L 50G -n eleves vg-filer #lvcreate -L 10G -n profs vg-filer #lvdisplay
A ce stade nous pouvons donc créer des sytèmes de fichiers, les monter, etc:
#mke2fs -j /dev/vg-filer/eleves #mount /dev/vg-filer/eleves /mnt/eleves
Cette opération est implicite lors de la construction des éléments LVM.
Bien qu'il existe un autre mécanisme (md sous Linux), LVM reste la solution la plus simple pour agréger différents disques ou portions de disques et les présenter comme un block device consolidé. L'intérêt évident réside dans le fait de pouvoir construire des systèmes de fichiers dont la taille n'est pas limitée par le plus gros disque dur disponible du moment.
Il est très simple de rajouter un “Physical Volume” dans un “Volume Group”:
#pvcreate /dev/sda #vgextend vg-filer /dev/sda
Cependant, avant d'être utile, il nous faudra prendre soin de deux autres opérations:
Si étendre un Logical Volume est trivial et sans risque, la modification de la taille d'un système de fichier n'est pas toujours évidente. Peu de systèmes de fichiers sont capables de faire cette opération “à chaud” (ReiserFS, ext3, XFS), il faudra donc souvent démonter le Logical Volume, transformer le système de fichier, puis le remonter:
#umount /mnt/profs #lvextend -L+1G /dev/vg-filer/profs #resize2fs /dev/vg-filer/profs #mount /mnt/profs
L'opération est bien entendu comparable à l'extension, sauf qu'il faut prendre soin de réduire le système de fichier avant le Logical Volume, sous risque de perdre des données.
Attention: certains systèmes de fichiers peuvent êtres étendus, mais non réduits (XFS).
Comme les volumes logiques et physiques sont décorélés, il est possible de déplacer les éléments physiques (disques, etc) sans affecter les applications. En particulier, on peut forcer la migration de données d'un Physical Volume vers un autre.
Par exemple, en supposant qu'il y a assez de place dans le Volume Group auquel il participe, les données du disque sda peuvent être migrés libérant ainsi ce dernier:
#pvmove /dev/sda
On peut bien entendu désigner un endroit précis où migrer les données, etc.
Notez que si le processus est interommpu inopinément (crash, panne de courant), il peut être repris en invoquant simplement la commande pvmove. Il est toutefois possible de perdre quelques blocs (extents) au cours de la panne !
Peut être la fonction la plus sophistiquée, beaucoup n'utilisant LVM que pour cet aspect très demandé pour les sauvegardes. Ce mécanisme permet d'effectuer un “instantané” (une photo) d'un Logical Volume: on crée une “vue en lecture seule” qui nous permet d'explorer le volume comme s'il n'était plus modifié, bien que pour le reste du système il continue à fonctionner normalement.
Ce miracle repose sur la création d'un nouveau Logical Volume spécial:
#lvcreate -L1G -s -n profs-snapshot /dev/vg-filer/profs
Il est important de comprendre que ce volume consomme de l'espace physique (il vous faudra donc des Physical Volume libres): il va contenir l'ensemble des écritures effectuées depuis la création du snapshot (un journal). Ceci a une conséquence importante: si ce volume (snapshot) se remplit complètement, il est automatiquement désactivé, afin que le volume pris en photo puisse continuer à fonctionner normalement.
Certaines documentations citent /proc/lvm, et il est possible que ce répertoire existe sur votre machine. Cependant celui-ci appartient au module noyau lvm (donc LVM1) et non au module device-mapper (LVM2).
Il existe un patch plus ou moins sauvage pour permettre le redimensionnement “à chaud” des systèmes de fichier ext2/ext3: attention il est considéré approximatif et dangereux.
Note: le support du redimensionnement a été officiellement intégré dans ext3 à partir de Linux 2.6.17. Il est toujours fortement recommandé d'avoir un backup du système de fichier sous la main.
Lors de l'assemblage des Physical Volume dans un Volume Group, il est possible de préciser comment l'adressage physique sera effectué :
Ce mode peut être utilisé avec la connaissance de la configuration précise des PV pour améliorer le débit d'accès au LV, par exemple en le répartissant sur des disques ayant des contrôleurs distincts (la bande passante de la connectique finale étant souvent le goulet d'étranglement).
Ceci n'a pas été évoqué dans le cours, mais l'unité d'allocation des PV est le Physical Extent, à l'instar du block pour les disques. Il est souvent à 4Mo par défaut, ceci peut bien entendu avoir un effet d'arrondi inattendu lors de la création des LV.