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 sur AlmaLinux 10 (LVM 2.03.36).

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. Sur RHEL et AlmaLinux 10, lvm2 tire déjà device-mapper-persistent-data ; sur Debian 13, thin-provisioning-tools n'est qu'une recommandation de lvm2, absente d'une installation minimale :

Debian/Ubuntu

sudo apt install thin-provisioning-tools lvm2

RHEL/AlmaLinux

sudo dnf install device-mapper-persistent-data lvm2

Sans ces outils, LVM crée quand même le pool, mais il ne peut plus en vérifier les métadonnées : à chaque activation, il affiche « WARNING: Check is skipped, please install recommended missing binary /usr/sbin/thin_check! ». Un pool dont les métadonnées ne sont jamais contrôlées est un pool dont on découvrira la corruption trop tard. 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

     Thin pool volume with chunk size 64.00 KiB can address at most <15.88 TiB of 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.
     WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger
     automatic extension of thin pools before they get full.
     Logical volume "thinvol" created.

LVM avertit explicitement du sur-engagement et de l'absence de protection, et indique même le réglage qui l'active. 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 39.12
  thinvol 5.00g 11.74

Le pool est désormais rempli à 39,12 % (les 500 Mio écrits, plus les structures de XFS), et le thin volume à 11,74 % 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 thin pool sur-engagé finit par se remplir si ses volumes grossissent tous en même temps. Le test l'a poussé à bout : 1,5 Gio écrits dans thinvol alors que le pool n'en contient que 1,5 au total. Au bout d'une minute, dd échoue sur « No space left on device », et lvs montre le pool plein :

  LV      Attr       Data%  Meta%
  pool0   twi-aotzD- 100.00 25.20
  thinvol Vwi-aotz-- 30.00

Le D de l'attribut signale un pool à court d'espace de données. Le journal du noyau raconte la séquence : « switching pool to out-of-data-space (queue IO) mode », puis 61 secondes plus tard « (error IO) mode ». Ce délai est le paramètre no_space_timeout du module dm_thin_pool, qui vaut 60 secondes, et lvs -o lv_when_full affiche queue, le comportement par défaut.

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 pendant 60 secondes, 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 lv_name,attr,data_percent,metadata_percent vg_data

É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

Les pannes de thin provisioning se lisent dans lvs et dans le journal du noyau. Surveillez l'attribut du pool (un D signale un pool plein), les colonnes Data% et Meta%, et les messages device-mapper: thin de dmesg.

Symptôme	Cause probable	Solution
Required device-mapper target(s) not detected in your kernel	module dm-thin-pool absent	sudo modprobe dm-thin-pool
Check is skipped, please install recommended missing binary /usr/sbin/thin_check!	outils thin manquants	installer thin-provisioning-tools (Debian) ou device-mapper-persistent-data (RHEL)
Écritures bloquées une minute, puis No space left on device	pool saturé (Data% ou Meta% à 100, attribut D)	é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

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

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

FAQ : questions fréquentes sur le thin provisioning LVM

Ces réponses reprennent les questions les plus fréquentes sur le thin provisioning : le sur-engagement, la surveillance du pool et son extension automatique.

Qu'est-ce que le thin provisioning LVM ?

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

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

Comment surveiller le remplissage d'un thin pool LVM ?

Quelle différence entre thin pool et thin volume ?

×

📖 Voir la documentation →