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 :

• la configuration physique de son sytème de stockage: les machines, leurs disques et l'architecture (SAN/NAS, iSCSI, !FiberChannel, etc)

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).

• LVM est apparu autour de 1998. Il a été intégré dans la série 2.4 du noyau Linux et est de ce fait encore très répandu. Il a été principalement développé par Sistina et Redhat.

• LVM2 est l'évolution naturelle de LVM1 (et presque compatible). Elle est intégrée au noyau 2.6, et très couramment “backportée” vers les noyaux 2.4 (comme celui de Debian Sarge).

• EVMS est principalement développé par IBM, et fut longtemps en ballotage avec LVM2 pour être le gestionnaire par défaut dans la série 2.6. Il y a toujours du pour et du contre, EVMS reste une alternative maintenue et reconnue.

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:

• LVM Howto

La préparation “classique” d'un système de fichiers se décompose en général en 3 niveaux distincts :

• Bas niveau: un disque dur physique, qui se présente sous le système comme un block device (ex: /dev/hda)
• Intermédiaire: une partition, c'est-à-dire portion continue du support physique; ceci nous est également préesnté comme un block device (ex: dev/hda1)
• Haut niveau: un système de fichier, qui permet de manipuler naturellement les données; il doit être construit au dessus d'un block device

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:

• d'une part, il agrège différents volumes physiques (donc des disques durs et/ou des partitions) en une seule entité logique dont la capacité de stockage est la somme de ses composants
• d'autre part, son espace logique total peut (et doit) être partitionné pour créer des block devices prêt à l'emploi pour nos systèmes de fichiers

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

• étendre un Logical Volume pour profiter de cet espace physique accru
• étendre le sytème de fichier ad hoc pour profiter de l'extension du Logical Volume

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é :

• soit continu: on passe de la fin d'un PV au début de l'autre
• soit en “striping”: on passe d'un PV à l'autre à chaque bloc suivant (similitude avec le RAID0)

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.