Thin provisioning LVM : allouer le stockage à la demande

Le thin provisioning LVM alloue l'espace disque au fur et à mesure des écritures, pas à la création du volume. Vous pouvez ainsi tailler des volumes dont la somme des tailles déclarées dépasse l'espace physique réellement disponible, le fameux sur-engagement. Ce guide montre comment créer un thin pool, y provisionner des volumes, surveiller son remplissage avec le Data%, et configurer l'extension automatique pour éviter la saturation. Pour administrateurs Linux intermédiaires, sur Debian/Ubuntu et RHEL/AlmaLinux. Toutes les sorties proviennent d'un test réel.

Ce que vous allez apprendre

• Distinguer un thin pool d'un thin volume
• Créer un pool et y tailler des volumes sur-engagés avec lvcreate --thin
• Lire le Data% pour suivre la consommation réelle
• Configurer l'extension automatique (thin_pool_autoextend_threshold)
• Comprendre le danger d'un pool plein et le prévenir

Prérequis

Une pile LVM fonctionnelle (voir le guide LVM) et les outils thin installés :

Debian/Ubuntu

sudo apt install thin-provisioning-tools lvm2

RHEL/AlmaLinux

sudo dnf install device-mapper-persistent-data lvm2

Sans ces outils (qui fournissent thin_check), LVM refuse de créer un thin pool. Le noyau doit aussi charger le module dm-thin-pool, présent par défaut sur toutes les distributions récentes.

Thin pool et thin volume : le modèle

Le thin provisioning ajoute un niveau d'indirection. Au lieu de tailler un volume directement dans le Volume Group, on crée d'abord un thin pool (un réservoir d'espace réel), puis on provisionne des thin volumes à l'intérieur de ce pool. Chaque thin volume annonce une taille (sa taille virtuelle), mais ne consomme l'espace physique du pool qu'au moment où des données y sont écrites.

La conséquence directe est le sur-engagement (overcommit) : la somme des tailles virtuelles des volumes peut dépasser la taille réelle du pool, exactement comme une banque prête plus d'argent qu'elle n'a de liquidités, en pariant que tous les clients ne retirent pas tout en même temps.

Créer un thin pool et un thin volume

On crée le pool avec --type thin-pool, puis un volume avec --thin en indiquant sa taille virtuelle via -V :

1. Créer le thin pool (ici 1,5 Gio d'espace réel) dans un VG nommé vg_data :

   sudo lvcreate --type thin-pool -L 1.5G -n pool0 vg_data

     Logical volume "pool0" created.

2. Provisionner un thin volume de 5 Gio virtuels dans ce pool de 1,5 Gio :

   sudo lvcreate --thin -V 5G -n thinvol vg_data/pool0

     WARNING: Sum of all thin volume sizes (5.00 GiB) exceeds the size of
     thin pool vg_data/pool0 and the size of whole volume group (<2.00 GiB).
     WARNING: You have not turned on protection against thin pools running out of space.
     Logical volume "thinvol" created.

LVM avertit explicitement du sur-engagement et de l'absence de protection. Ces avertissements ne sont pas des erreurs : ils rappellent que le suivi du remplissage devient votre responsabilité.

Le sur-engagement en action

C'est ici que le thin provisioning prend tout son sens. La colonne Data% montre l'espace réellement consommé dans le pool, indépendamment des tailles virtuelles déclarées. Juste après la création, tout est à zéro :

sudo lvs -o lv_name,lv_size,pool_lv,data_percent vg_data

  LV      LSize Pool  Data%
  pool0   1.50g       0.00
  thinvol 5.00g pool0 0.00

thinvol affiche 5 Gio alors que le pool n'en contient que 1,5, et pourtant rien n'est consommé. Écrivons 500 Mio de données réelles dans le volume, puis observons à nouveau :

sudo mkfs.xfs /dev/vg_data/thinvol
sudo mount /dev/vg_data/thinvol /mnt/data
sudo dd if=/dev/zero of=/mnt/data/bigfile bs=1M count=500
sudo lvs -o lv_name,lv_size,data_percent vg_data

  LV      LSize Data%
  pool0   1.50g 36.76
  thinvol 5.00g 11.03

Le pool est désormais rempli à 36,76 % (les 500 Mio écrits, plus les métadonnées), et le thin volume à 11,03 % de ses 5 Gio virtuels. Seul l'espace réellement écrit est consommé : c'est tout l'intérêt du thin provisioning.

Le danger : un pool qui se remplit

Un pool plein peut corrompre vos données

Quand le Data% (ou le Meta%) d'un thin pool atteint 100 %, les écritures des volumes sont mises en file d'attente jusqu'à environ 60 secondes (mode queue, par défaut), puis échouent. La documentation officielle prévient qu'un épuisement « risque d'endommager le système de fichiers et nécessite une réparation ». Le cas le plus vicieux est la saturation des métadonnées (Meta%) : le pool devient inutilisable même s'il reste de l'espace de données.

Le sur-engagement n'est donc pas magique : si tous les volumes se remplissent en même temps, le pool sature. La règle est simple : surveiller le Data% et le Meta%, et étendre le pool avant d'atteindre la limite.

sudo lvs -o +data_percent,metadata_percent

Étendre le pool automatiquement

Plutôt que de surveiller à la main, on configure LVM pour étendre le pool tout seul avant qu'il ne sature. Deux directives dans /etc/lvm/lvm.conf, section activation :

activation {
    thin_pool_autoextend_threshold = 80
    thin_pool_autoextend_percent = 20
}

• thin_pool_autoextend_threshold : seuil de déclenchement. À 80, le pool s'étend dès qu'il atteint 80 % de remplissage. La valeur 100 désactive l'extension automatique (minimum accepté : 50).
• thin_pool_autoextend_percent : le pool grandit de ce pourcentage de sa taille à chaque déclenchement.

L'extension repose sur le démon dmeventd, qui reçoit les notifications du noyau et lance lvextend automatiquement. Encore faut-il que le pool soit surveillé :

sudo lvchange --monitor y vg_data/pool0
sudo lvs -o +seg_monitor vg_data/pool0   # doit afficher "monitored"

L'autoextend a besoin d'espace libre

L'extension automatique ne fonctionne que si le Volume Group dispose encore d'espace libre (vgs, colonne VFree). Sur un VG plein, il faut d'abord ajouter un disque avec vgextend. Le thin provisioning ne crée pas d'espace, il en diffère l'allocation.

Quand utiliser le thin provisioning

Le thin provisioning brille quand l'espace déclaré dépasse largement l'espace utilisé, ou quand on multiplie les volumes :

• Snapshots nombreux et peu coûteux : les snapshots fins partagent les blocs du pool au lieu de préallouer une taille fixe.
• Disques de VM et de conteneurs : on provisionne large sans immobiliser le disque. C'est exactement ce que fait Proxmox VE avec son backend LVM-thin, qui supporte snapshots et clones natifs.
• Sur-allocation maîtrisée : donner à chaque service un volume confortable sans acheter le disque total d'avance.

La contrepartie est toujours la même : le monitoring n'est pas optionnel. Un thin pool sans surveillance est une panne qui attend son heure.

Dépannage

Symptôme	Cause probable	Solution
lvcreate --type thin-pool échoue : target not detected	module dm-thin-pool absent	sudo modprobe dm-thin-pool, installer les outils thin
lvcreate refuse : thin_check not found	outils thin manquants	installer thin-provisioning-tools / device-mapper-persistent-data
Écritures qui se bloquent ou échouent	pool saturé (Data% ou Meta% à 100)	étendre le pool (lvextend), ajouter un disque au VG
Le pool ne s'étend pas tout seul	pool non surveillé ou VG plein	lvchange --monitor y, vérifier vgs (VFree)

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Le thin provisioning alloue l'espace à l'écriture, pas à la création.
• Un thin pool (espace réel) contient des thin volumes (taille virtuelle) avec lvcreate --type thin-pool puis lvcreate --thin -V.
• Le sur-engagement autorise une somme de tailles virtuelles supérieure au pool ; le Data% montre le réel.
• Un pool plein corrompt les données : surveiller Data% et Meta%.
• Activer l'extension automatique (thin_pool_autoextend_threshold) et le monitoring (lvchange --monitor y).
• L'autoextend a besoin d'espace libre dans le VG : le thin ne crée pas de disque.

FAQ : questions fréquentes sur le thin provisioning LVM

Qu'est-ce que le thin provisioning LVM ?

Le thin provisioning LVM alloue l'espace disque au fur et à mesure des écritures, pas à la création du volume. On crée un thin pool (espace réel) puis des thin volumes dont la taille déclarée peut dépasser l'espace physique disponible.

C'est quoi le sur-engagement (overcommit) en LVM ?

Le sur-engagement permet de déclarer des thin volumes dont la somme des tailles dépasse la taille réelle du thin pool. On parie que tous les volumes ne se rempliront pas en même temps, comme une banque qui prête plus qu'elle n'a de liquidités.

Que se passe-t-il si un thin pool LVM est plein ?

Quand le Data% ou le Meta% atteint 100%, les écritures sont mises en file d'attente environ 60 secondes (mode queue par défaut) puis échouent. Un pool saturé risque de corrompre le système de fichiers et nécessite une réparation.

Comment surveiller le remplissage d'un thin pool LVM ?

On surveille les colonnes Data% et Meta% avec lvs -o +data_percent,metadata_percent. Pour l'extension automatique, on règle thin_pool_autoextend_threshold dans lvm.conf et on active le monitoring avec lvchange --monitor y.

Quelle différence entre thin pool et thin volume ?

Le thin pool est un volume spécial qui réserve l'espace physique réel et stocke données et métadonnées. Les thin volumes sont créés à l'intérieur du pool : ils ont une taille virtuelle et puisent l'espace réel du pool au moment des écritures.

Pour aller plus loin

• Stockage local Proxmox VE : Le backend LVM-thin pour les disques de VM et conteneurs.
• Préparer la certification RHCSA : LVM et le thin provisioning sont des objectifs d'examen.

×

📖 Voir la documentation →