Ubuntu 24.04 : pool LVM thin à 100 % — sauvez vos VM avant qu’il ne soit trop tard

décembre 14, 2025 • février 3, 2026 • Lecture : 29 min • Views: 14

Cet article vous a aidé ?

Si votre hôte Ubuntu 24.04 exécute des VM sur des LVM thin et que ce thin pool atteint 100 %, le mode d’échec n’est pas « un peu lent ». C’est « les écritures s’arrêtent, les invités se bloquent et votre hyperviseur commence à faire des bruits inquiétants ». Vous n’obtenez pas un compte à rebours gracieux. Vous recevez un pager et une montée d’adrénaline.

Ceci est le playbook que j’aurais voulu voir collé à l’intérieur de la porte d’armoire : comment diagnostiquer ce qui est réellement plein (données ou métadonnées), comment redonner de l’air aux VM sans transformer la récupération en un second incident, et comment empêcher le thin provisioning de se transformer en patinoire fine.

Ce qui se passe réellement quand un thin pool atteint 100%

Le thin provisioning LVM est une idée brillante avec un tranchant : il vous permet de promettre plus d’espace que vous n’en avez physiquement. Ce n’est pas intrinsèquement malveillant — les baies de stockage le font depuis des années — mais cela déplace la défaillance du « moment d’allocation » au « moment d’écriture ». Quand le thin pool manque d’espace, vous ne vous contentez pas d’échouer à créer un nouveau volume. Les VM existantes peuvent soudainement être incapables d’écrire des blocs qu’elles n’avaient jamais écrits auparavant. Cela peut ressembler à des plantages d’applications aléatoires, des remontages en lecture seule, des avertissements de corruption de base de données et des invités passant en lecture seule.

Deux espaces distincts peuvent vous tuer :

Espace données (le grand) : où vivent les blocs des LV thin.
Espace métadonnées (le petit) : la table de mappage qui dit « ce bloc de LV thin correspond à ce bloc physique ».

Quand données est à 100 %, les nouvelles écritures nécessitant une allocation de blocs échouent. Quand métadonnées est à 100 %, la tenue de comptes d’allocation échoue même si vous avez encore de l’espace données. Les deux situations peuvent bloquer les E/S. Les deux peuvent gripper des VM. Les deux sont évitables si vous traitez le thin provisioning comme une substance contrôlée.

Une nuance supplémentaire : un thin pool peut devenir « unhealthy » avant d’atteindre 100 % s’il est fortement fragmenté, s’il contient des snapshots incontrôlés ou s’il est poussé dans des cycles constants d’allocation/libération. Mais 100 % est le titre parce que c’est là que votre marge devient négative et que vous commencez à payer des intérêts.

Blague n°1 : Le thin provisioning, c’est comme le crédit : fantastique jusqu’à ce que vous le maxiez accidentellement avec « juste un snapshot de plus ».

Faits et courte histoire : pourquoi les thin pools se comportent ainsi

Un peu de contexte vous aide à prévoir le comportement au lieu de deviner. Voici des faits concrets et utiles — pas de nostalgie, juste de la mécanique.

Device-mapper thin provisioning (dm-thin) est dans le noyau Linux depuis des années ; LVM thin l’utilise en dessous. LVM ne fait pas de « magie », il orchestre des dispositifs dm-thin.
Les métadonnées sont un LV séparé (souvent nommé comme thinpool_tmeta) parce que les tables de mappage doivent être crash-consistantes et rapides. Manquer de métadonnées peut casser l’allocation même quand les données semblent correctes.
Les thin pools peuvent être sur-engagés par conception : la somme des tailles virtuelles des LV thin peut dépasser la taille physique du pool. C’est l’intérêt — et aussi le piège.
Le support du discard/TRIM a évolué lentement à travers les couches (système de fichiers invité → disque virtuel → hôte dm-thin). C’est maintenant praticable, mais seulement si vous l’activez bout en bout et comprenez le coût en performance.
Les snapshots sont peu coûteux à la création en thin provisioning. C’est pour ça que les gens en font trop. Le coût arrive plus tard quand les blocs divergent s’accumulent.
L’autoextend existe pour les thin pools (via la surveillance LVM et les profils), mais cela n’aide que si le VG a des extents libres ou si vous pouvez ajouter rapidement des PV.
100 % n’est pas une limite polie : dm-thin peut basculer en mode erreur pour de nouvelles allocations. Selon la configuration, les erreurs d’E/S se propagent de façon imprévisible aux systèmes de fichiers et applications.
Il existe des outils de réparation de métadonnées (comme thin_check et thin_repair), mais ce ne sont pas des outils de maintenance routinière. Si vous les utilisez tous les mois, votre processus est le problème.

Il y a un principe de fiabilité à garder visible. Voici une idée paraphrasée de John Allspaw, leader en opérations et fiabilité : idée paraphrasée : les incidents viennent du travail normal dans des systèmes complexes ; blâmer est inutile — comprendre et apprendre est le travail.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Quand le thin pool atteint 100 %, votre tâche est d’arrêter de deviner. Suivez un ordre strict. Chaque étape répond à une question binaire et oriente votre action suivante.

Premier : est-ce l’espace données ou l’espace métadonnées ?

Si données est pleine : vous avez besoin d’espace physique ou de libérer des blocs (TRIM/discard ne vous sauvera pas rapidement à moins que ce soit déjà activé).
Si métadonnées est pleine : vous pouvez souvent étendre rapidement le LV métadonnées (si le VG a de l’espace) et restaurer les allocations.

Second : les écritures échouent-elles maintenant ?

Vérifiez les logs du noyau pour des erreurs dm-thin.
Vérifiez si les invités sont passés en lecture seule ou si des services échouent.

Troisième : qu’est-ce qui consomme l’espace : écritures réelles, snapshots ou blocs obsolètes ?

Regardez l’utilisation par LV.
Identifiez les schémas de croissance des snapshots.
Décidez de supprimer des snapshots, migrer une VM, étendre le pool ou ajouter un nouveau PV.

Le temps compte. Mais « rapide » ne veut pas dire « créatif ». Cela signifie « faire le moins d’opérations risquées qui restaurent de l’espace d’écriture ».

Tâches pratiques (commandes, sorties et décisions)

Ci‑dessous des tâches réelles à exécuter sur Ubuntu 24.04. Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie et la décision à prendre. Exécutez-les en root ou avec sudo. Adaptez les noms de VG/LV à votre environnement.

Task 1: Identify thin pools and their usage

cr0x@server:~$ sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,data_percent,metadata_percent,origin,pool_lv --units g
  VG     LV                 Attr       LSize  Data%  Meta%  Origin Pool
  vg0    thinpool           twi-aotz--  900.00g 99.82  12.44        -
  vg0    thinpool_tdata     Twi-aotz--  900.00g
  vg0    thinpool_tmeta     ewi-aotz--    4.00g
  vg0    vm-101-disk-0      Vwi-aotz--   80.00g 62.10
  vg0    vm-102-disk-0      Vwi-aotz--  120.00g 91.34

Sens : twi- indique un thin pool. Data% est dangereusement élevé (99.82%). Les métadonnées sont correctes (12.44%).

Décision : Considérez ceci comme une urgence d’espace données. Il vous faut immédiatement de la marge : étendez le pool, supprimez des snapshots ou déplacez une VM hors du pool.

Task 2: Confirm the VG has free space to extend

cr0x@server:~$ sudo vgs -o vg_name,vg_size,vg_free,vg_free_count --units g
  VG   VSize    VFree   VFreeCount
  vg0  953.00g   0.00g  0

Sens : Pas d’extents libres dans le VG. Vous ne pouvez pas étendre le thin pool sans ajouter de stockage ou déplacer des données.

Décision : Planifiez l’ajout d’un nouveau PV (nouveau disque/LUN) ou évacuez une ou plusieurs LV thin vers un autre VG.

Task 3: Confirm whether the pool is in trouble mode (kernel messages)

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Dec 29 11:41:20 2025] device-mapper: thin: 253:10: reached low water mark; sending event.
[Mon Dec 29 11:43:02 2025] device-mapper: thin: 253:10: no free space for data block allocation
[Mon Dec 29 11:43:02 2025] blk_update_request: I/O error, dev dm-7, sector 1048576 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Sens : dm-thin échoue des allocations. Les invités vont voir des erreurs d’écriture ou des blocages.

Décision : Arrêtez les écritures non essentielles. Suspendez les jobs de sauvegarde, les créations de snapshot, les tempêtes de logs. Votre priorité est de restaurer de la marge.

Task 4: Find the top thin LVs by used blocks

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent,seg_monitor --sort=-data_percent vg0
  LV             LSize   Data%  Meta%  Cpy%Sync Monitor
  vm-102-disk-0  120.00g 91.34
  vm-101-disk-0   80.00g 62.10

Sens : data_percent par LV thin est le pourcentage des blocs alloués du disque virtuel, pas l’utilisation du système de fichiers à l’intérieur de l’invité.

Décision : Si une VM est un gros producteur d’écritures, envisagez d’arrêter ou de déplacer celle-ci en priorité.

Task 5: Check for snapshots that are quietly eating the pool

cr0x@server:~$ sudo lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent --sort=origin vg0 | sed -n '1,40p'
  LV                    Attr       Origin          LSize   Data%
  thinpool              twi-aotz--                 900.00g
  vm-101-disk-0         Vwi-aotz--                 80.00g  62.10
  vm-101-disk-0-snap    Vri-aotz--  vm-101-disk-0  80.00g  18.43

Sens : Les LV snapshot (Vri-) accumulent les blocs modifiés. Si votre politique de snapshots est négligente, votre pool se remplit comme une baignoire dont le bouchon est collé.

Décision : Identifiez les snapshots non critiques et supprimez-les pour récupérer des blocs (la récupération n’est pas toujours immédiate ; voir les notes sur TRIM plus loin).

Task 6: Check thin pool settings (autoextend and thresholds)

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,lv_size,segtype,seg_monitor,lv_profile vg0/thinpool
  LV       Attr       LSize    Type  Monitor Profile
  thinpool twi-aotz-- 900.00g thin-pool monitored

Sens : « monitored » signifie que lvm2 peut émettre des événements, mais cela ne garantit pas une croissance automatique sauf si c’est configuré.

Décision : Après avoir survécu à l’incident, configurez un profil de thin pool avec autoextend ou mettez en place des alertes externes. Pendant l’incident, ne perdez pas de temps à « tuner ».

Task 7: Check LVM event daemon status (sometimes alerts aren’t happening)

cr0x@server:~$ systemctl status lvm2-lvmpolld lvm2-monitor --no-pager
● lvm2-lvmpolld.service - LVM2 poll daemon
     Loaded: loaded (/usr/lib/systemd/system/lvm2-lvmpolld.service; static)
     Active: active (running)
● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling
     Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled)
     Active: active (exited)

Sens : Les services sont présents. Si vous n’avez jamais reçu d’alertes, vous ne les aviez probablement pas reliées (LVM ne vous alertera pas automatiquement).

Décision : Pour l’instant : concentrez-vous sur la libération d’espace. Plus tard : intégrez à Prometheus/NRPE/ce que vous utilisez.

Task 8: Add a new disk and make it a PV (fastest clean expansion)

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME        SIZE TYPE MOUNTPOINT
sda         1.0T disk
├─sda1        1G part /boot/efi
├─sda2        2G part /boot
└─sda3      997G part
  ├─vg0-thinpool_tdata 900G lvm
  ├─vg0-thinpool_tmeta   4G lvm
  └─vg0-root            80G lvm /
sdb         500G disk

cr0x@server:~$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

Sens : Vous avez un nouveau PV prêt à être ajouté au VG.

Décision : Si c’est un hyperviseur, préférez ajouter de la capacité plutôt que des « nettoyages astucieux » quand le pool est déjà à 100 %.

Task 9: Extend the VG, then extend the thin pool data LV

cr0x@server:~$ sudo vgextend vg0 /dev/sdb
  Volume group "vg0" successfully extended

cr0x@server:~$ sudo lvextend -L +400G vg0/thinpool
  Size of logical volume vg0/thinpool changed from 900.00 GiB (230400 extents) to 1.29 TiB (332800 extents).
  Logical volume vg0/thinpool successfully resized.

Sens : Le pool est plus grand. C’est souvent le moyen le plus propre de « sortir de prison » si vous pouvez ajouter rapidement du stockage.

Décision : Si Data% était ~100 % et que vous voyez des erreurs d’E/S, étendre est la solution la moins risquée. Faites-le d’abord, puis analysez pourquoi cela s’est rempli.

Task 10: If metadata is the problem, extend metadata too

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.10  99.92

cr0x@server:~$ sudo lvextend --poolmetadatasize +2G vg0/thinpool
  Size of logical volume vg0/thinpool_tmeta changed from 4.00 GiB (1024 extents) to 6.00 GiB (1536 extents).
  Logical volume vg0/thinpool_tmeta successfully resized.

Sens : Les métadonnées étaient presque pleines ; vous les avez augmentées. Cela peut immédiatement arrêter les échecs d’allocation.

Décision : Si Meta% est élevé (>80 % soutenu), traitez-le comme une urgence. Étendre les métadonnées est généralement rapide et peu dramatique comparé à une réparation après corruption.

Task 11: Confirm the thin pool is no longer pinned at 100%

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,metadata_percent vg0/thinpool
  LV       LSize    Data%  Meta%
  thinpool 1.29t    76.09  54.12

Sens : Vous avez de la marge. Pas « sûr pour toujours », mais suffisant pour arrêter l’hémorragie active.

Décision : Reprenez les services progressivement. Laissez les sauvegardes en pause jusqu’à ce que vous soyez certain de la stabilité et que vous compreniez le vecteur de croissance.

Task 12: Check whether discards are enabled for the thin pool

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,discards vg0/thinpool
  LV       Attr       Discards
  thinpool twi-aotz-- passdown

Sens : passdown signifie que les discards peuvent être passés au stockage sous-jacent. C’est bien, mais cela ne garantit pas que les invités envoient des TRIM, ni que votre couche d’hyperviseur les transmette.

Décision : Si vous comptez sur le « retour d’espace », validez le TRIM bout en bout. Sinon les thin pools ne font que croître.

Task 13: Check filesystem usage inside the host for log storms (often the trigger)

cr0x@server:~$ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg0-root   78G   71G  3.0G  96% /

Sens : Si la racine de l’hôte est pleine, vous pouvez observer des défaillances en cascade (journald, libvirt, qemu logs). Cela peut provoquer des pertes de VM non liées à la capacité du thin pool — ne les confondez pas.

Décision : Si la racine de l’hôte est presque pleine, libérez-la aussi. Un « thin pool réparé » sur un système de fichiers racine mourant n’est qu’un autre type de panne.

Task 14: Inspect per-VM disk files or LVs from the hypervisor layer

cr0x@server:~$ sudo virsh domblklist vm102
 Target   Source
------------------------------------------------
 vda      /dev/vg0/vm-102-disk-0
 vdb      /var/lib/libvirt/images/vm102-seed.img

Sens : Confirme quels LV sont attachés. Utile quand une VM « écrit mystérieusement » sur un disque différent de celui que vous pensez.

Décision : Si une VM bruyante est mappée sur le thin pool, vous savez maintenant exactement quel LV snapshot/supprimer/migrer/limiter.

Task 15: If you can shut down a VM, punch out its space usage and snapshot count

cr0x@server:~$ sudo lvs -o lv_name,lv_size,data_percent,lv_time,origin vg0 | grep -E 'vm-102|snap'
  vm-102-disk-0        120.00g 91.34  2025-12-28 22:10:14
  vm-102-disk-0-snap   120.00g 44.02  2025-12-29 09:00:11 vm-102-disk-0

Sens : Cela montre si un snapshot récent gonfle rapidement. Beaucoup d’incidents « thin pool soudainement plein » viennent d’un job de snapshot devenu incontrôlé.

Décision : Supprimez le snapshot s’il n’est pas requis pour la reprise/la conformité — après confirmation avec les parties prenantes. S’il est requis, étendez la capacité et corrigez la politique de snapshot plus tard.

Task 16: Delete an unneeded thin snapshot (carefully)

cr0x@server:~$ sudo lvremove -y vg0/vm-102-disk-0-snap
  Logical volume "vm-102-disk-0-snap" successfully removed.

Sens : Le snapshot est parti. La réutilisabilité immédiate de l’espace dépend du comportement des discards et des internals de dm-thin, mais la pression d’allocation baisse généralement.

Décision : Si vous avez supprimé des snapshots et que Data% n’évolue pas rapidement, ne paniquez pas. Concentrez-vous plutôt sur l’arrêt des nouvelles écritures et l’ajout de capacité.

Task 17: Validate thin pool health status

cr0x@server:~$ sudo lvs -o lv_name,lv_attr,health_status vg0/thinpool
  LV       Attr       Health
  thinpool twi-aotz-- ok

Sens : « ok » est ce que vous souhaitez. Si ce n’est pas ok, traitez le pool comme compromis et priorisez sauvegardes/évacuation.

Décision : Si la santé est dégradée, cessez de prendre de nouveaux snapshots et planifiez une fenêtre de maintenance pour vérifier l’intégrité des métadonnées et les erreurs d’E/S.

Tactiques de récupération : choisissez la moins pire des options

Quand le thin pool est plein, vous êtes dans un problème d’optimisation contrainte : réduire le risque, restaurer de la marge d’écriture et préserver la récupérabilité. Le meilleur choix dépend de ce qui est disponible : espace libre dans le VG, disques supplémentaires, un autre hôte ou la possibilité d’éteindre des VM.

Option A (meilleure) : ajouter de la capacité, étendre le pool, puis enquêter

Si vous pouvez attacher un nouveau disque/LUN rapidement, faites-le. Étendre le pool est peu risqué comparé à une chirurgie en direct à l’intérieur des invités. Cela vous donne aussi l’air pour la seconde partie du travail : comprendre pourquoi vous en êtes arrivé là.

Opérationnellement, c’est l’étape « arrêter l’hémorragie ». Vous avez toujours besoin de prévention, mais vos VM cessent de crier.

Option B : évacuer une VM vers un autre datastore

Si vous avez un autre VG/backend de stockage avec de l’espace, déplacer une grosse VM peut acheter du temps. Selon votre stack (libvirt, Proxmox, scripts personnalisés), vous pouvez faire une migration froide (arrêt VM et copie) ou une migration à chaud (si prise en charge). En crise, la migration froide est ennuyeuse et fiable.

Soyez honnête sur la bande passante. Copier 500G à 1 Gbit/s n’est pas une « solution rapide ». C’est un plan pour demain sauf si vous avez de la chance.

Option C : supprimer des snapshots (si vous êtes absolument sûr)

Les snapshots ressemblent à des sauvegardes jusqu’à ce qu’ils ne le soient pas. Si vous supprimez une mauvaise chaîne de snapshots, vous pouvez effacer le seul chemin de retour temporel. Mais si les snapshots sont clairement inutiles (snapshots de test, jobs nocturnes oubliés, templates abandonnés), les supprimer est souvent le levier de récupération le plus rapide.

Ne supprimez pas de snapshots à l’aveugle. Identifiez les propriétaires, vérifiez les fenêtres de changement et confirmez que des workflows de restauration ne dépendent pas d’eux.

Option D : activer/détecter les discards et tenter de récupérer de l’espace

Le TRIM peut aider, mais ce n’est pas un défibrillateur. Si vos invités ont supprimé beaucoup de données sans émettre de discards, votre thin pool peut être plein de blocs morts. Activer le discard peut permettre la récupération d’espace — mais cela peut aussi créer du bruit d’E/S et ne vous ramènera pas forcément de 100 % à un niveau sûr en quelques minutes.

Aussi : tous les systèmes de fichiers invités n’émettent pas automatiquement le trim ; certains nécessitent des fstrim périodiques. Les couches de virtualisation peuvent ignorer le discard sauf si explicitement activées. Les thin pools peuvent transmettre les discards, mais ce n’est qu’un maillon de la chaîne.

Option E (dernier recours) : outils de réparation et intervention sur les métadonnées

Si vous voyez une corruption des métadonnées ou des problèmes de santé sévères du thin pool, vous devrez peut‑être faire des vérifications hors ligne avec thin_check/thin_repair. Ce n’est pas une tâche « faites-la en production à 14h » sauf si votre alternative est la perte totale des données.

Les workflows de réparation varient selon les paquets de distro et le comportement du noyau. Le principe sûr reste : retirer le pool du service, capturer les métadonnées, valider, réparer si nécessaire, et restaurer prudemment.

Blague n°2 : « On va juste lancer thin_repair vite fait » est l’équivalent stockage de « je vais juste redémarrer la base de données, quoi de pire ? »

Trois micro-histoires d’entreprise tirées de la vraie vie

Micro-histoire 1 : L’incident causé par une mauvaise hypothèse

L’équipe a hérité d’un cluster de virtualisation qui « avait plein d’espace ». L’administrateur précédent avait dimensionné les LV thin généreusement — 2–4× ce que les invités utilisaient réellement — et tout le monde appréciait la flexibilité. Les développeurs pouvaient demander des disques plus gros sans ticket d’achat. Personne ne sentait le risque parce que rien n’avait encore cassé.

La mauvaise hypothèse était subtile : ils supposaient que parce que les invités étaient seulement à 40–50 % au niveau système de fichiers, le thin pool devait être sûr. Ils regardaient df dans les VM, pas lvs sur l’hôte. Ils supposaient aussi que les suppressions dans les invités retourneraient automatiquement de l’espace au pool.

Puis une charge CI a changé : les caches d’images de conteneur ont commencé à chasser fort, créant et supprimant de larges couches. Les invités ont libéré de l’espace de leur point de vue. Le thin pool n’a pas récupéré ces blocs parce que le discard n’était pas activé bout en bout.

Le pool a atteint 100 % en heures ouvrées. Un sous-ensemble de VM a gelé sur les écritures. Une VM base de données est passée en lecture seule. La réponse à l’incident a été chaotique parce que l’hôte affichait encore « espace libre » selon les invités. On a débattu avec les graphiques au lieu des logs du noyau.

La réparation a été ennuyeuse : étendre le pool, activer le discard prudemment et changer la surveillance pour alerter sur Data%/Meta% du thin pool, pas l’espace disque des invités. La leçon a marqué parce qu’elle a coûté cher : « espace libre » est un concept en couches, et chaque couche ment à sa manière.

Micro-histoire 2 : L’optimisation qui a mal tourné

Un groupe plateforme a voulu réduire les fenêtres de sauvegarde. Leurs hyperviseurs utilisaient des snapshots LVM thin pour des sauvegardes crash-consistantes : snapshot, monter, copier, supprimer. Quelqu’un a remarqué que les snapshots étaient peu coûteux à créer et a proposé d’augmenter la fréquence pour améliorer le RPO.

Sur le papier, c’était élégant : snapshots fréquents, copies incrémentales plus rapides, moins de données à bouger à chaque fois. En pratique, la charge était intensive en écritures. Les snapshots ont commencé à accumuler rapidement des blocs modifiés. Les copies « incrémentales » n’étaient pas aussi incrémentales que prévu parce que les jeux de données chauds changeaient partout.

L’optimisation s’est retournée contre eux de façon classique : le système est devenu plus complexe et moins prévisible. Data% du thin pool a grimpé lentement, puis brusquement. L’équipe avait des alertes à 95 %, mais la pente était suffisamment raide pour atteindre 100 % entre les vérifications, juste au moment où quelques grandes VM faisaient des montées de version applicative.

Ils ont supprimé des snapshots pour retrouver de l’espace et ont découvert un effet secondaire : les jobs de sauvegarde ont réessayé, recréé des snapshots et ont immédiatement regarni le pool. Le problème n’était pas « les snapshots sont mauvais ». C’était « la concurrence de snapshots non limitée est mauvaise ».

La remédiation finale a été politique : plafonner le nombre de snapshots par VM, sérialiser les opérations de snapshot, définir un ratio max d’overcommit thin. L’équipe a aussi séparé des pools : un pour charges volatiles, un pour bases de données stables. Pas parce que c’est chic, mais parce que limiter le périmètre de panne fonctionne.

Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une application proche de la finance tournait sur un petit ensemble de VM. L’équipe qui la gère n’était pas glamour, mais disciplinée. Ils avaient une routine hebdomadaire : vérifier l’usage du thin pool, valider les sauvegardes, tester une restauration et revoir toute dérive de snapshots.

Ils avaient aussi une règle : chaque hyperviseur disposait d’une procédure documentée « ajout de capacité » avec un stockage pré-approuvé. Quand un pool approchait du seuil d’alerte, ils n’argumentaient pas. Ils ajoutaient la capacité puis analysaient les tendances de consommation après coup.

Lors d’une clôture trimestrielle, la charge a bondi. Les logs ont augmenté, des rapports ont généré des fichiers intermédiaires et un job a doublé temporairement le volume d’écriture. Data% du thin pool a grimpé vite. Leur surveillance a alerté tôt, et l’astreinte a exécuté le playbook sans improvisation.

Ils ont attaché un nouveau LUN, étendu le VG et le thin pool, et ont maintenu l’activité. Pas de moment héroïque, juste une tâche routinière réalisée sous pression. Le post-mortem a été bref parce que le système s’était comporté comme prévu.

Cette équipe n’« évitait » pas les incidents. Elle réduisait la probabilité qu’un incident de capacité devienne une perte de données. En production, c’est ça la compétence.

Erreurs courantes : symptôme → cause racine → correction

Ce ne sont pas des théories. Ce sont les façons dont les thin pools punissent la confiance excessive.

1) Symptom: VMs freeze or go read-only, but host CPU/RAM look fine

Cause racine : dm-thin ne peut pas allouer de nouveaux blocs (données pleines) ou ne peut pas mettre à jour les mappages (métadonnées pleines). Les écritures se bloquent ou échouent.

Correction : Vérifiez lvs Data%/Meta% et dmesg. Restaurez de la marge en étendant le pool ou en supprimant des snapshots ; étendez les métadonnées si Meta% est élevé.

2) Symptom: Guests show plenty of free space, but thin pool is full

Cause racine : Le thin provisioning suit les blocs alloués, pas l’espace libre invité. Les fichiers supprimés ne retournent pas nécessairement des blocs sauf si les discards traversent la pile.

Correction : Activez le discard bout en bout et planifiez fstrim dans les invités quand approprié. Ne comptez pas dessus comme solution d’urgence quand vous êtes déjà plein ; ajoutez de la capacité d’abord.

3) Symptom: Thin pool Meta% climbs faster than expected

Cause racine : Churn élevé : beaucoup de petites écritures aléatoires, de nombreux snapshots ou cycles de création/suppression rapides augmentent la complexité des mappages.

Correction : Étendez proactivement le LV métadonnées. Réduisez le nombre et la durée des snapshots. Envisagez des pools séparés pour les charges à churn élevé.

4) Symptom: You extended the pool but Data% still looks high

Cause racine : Vous avez étendu trop peu, ou les charges actives ont immédiatement consommé l’espace ajouté. Parfois vous avez étendu le mauvais LV (confusion tmeta/tdata).

Correction : Revérifiez lvs -a et confirmez que la taille du LV pool a changé. Limitez/arrêtez temporairement les pires consommateurs pendant que vous regagnez de la marge.

5) Symptom: Snapshot deletion doesn’t “free space” quickly

Cause racine : La récupération dépend de la gestion des blocs et du passage des discards. Aussi, d’autres écrivains peuvent consommer de l’espace en même temps.

Correction : Mesurez à nouveau après avoir arrêté les jobs à haute écriture. Ne basez pas votre plan uniquement sur « j’ai supprimé un snapshot » — associez-le à l’ajout de marge.

6) Symptom: You never got an alert; pool hit 100% silently

Cause racine : Pas de surveillance sur Data%/Meta% du thin pool, ou les alertes étaient trop hautes avec un intervalle trop long.

Correction : Alarmez à plusieurs seuils (par ex. 70/80/90/95) et sur le taux de variation. Traitez les thin pools comme des instruments de vol, pas comme un tableau de bord décoratif.

Prévention : surveillance, politique et choix d’architecture

L’objectif n’est pas « ne jamais remplir un thin pool ». L’objectif est « ne jamais remplir un thin pool de façon inattendue ». Vous voulez du temps pour prendre une décision calme, pas une décision désespérée.

Set a thin overcommit policy (yes, a policy)

Le thin provisioning sans limite d’overcommit est juste du jeu avec une meilleure UX. Décidez de votre tolérance au risque :

Pour des charges mixtes : gardez la somme virtuelle sous ~150–200% de la physique, selon le churn et votre temps de réponse.
Pour CI/build/test volatiles : supposez que la croissance est réelle ; overcommittez moins ou isolez ces VM.
Pour les bases de données : soit ne pas thin-provisionner, soit garder une marge physique généreuse et des limites strictes de snapshots.

Alert on both Data% and Meta% (and on slope)

Data% est l’évidence. Meta% est l’assassin à l’arrière. Alertez aussi sur la vitesse de changement de Data%. Un pool à 85 % qui croît de 1 % par semaine est une tâche de budget. Un pool à 85 % qui croît de 1 % par heure est un incident que vous n’avez pas encore remarqué.

Make snapshot lifecycle a first-class citizen

Les snapshots non bornés sont la faute n°1 des thin pools. Établissez des règles :

Nombre max de snapshots par VM.
Âge max (expiration automatique).
Sérialiser les jobs lourds en snapshots pour éviter les allocations en rafale.

Use discard/TRIM deliberately, not religiously

Le discard peut réduire la croissance d’allocation à long terme et faire que les thin pools se comportent plus comme du stockage « réel ». Il peut aussi ajouter un surcoût. Décidez selon la charge :

Pour des pools SSD/NVMe, le discard vaut souvent le coût.
Pour certains SAN ou baies thin-provisioned, le comportement du discard varie ; testez-le.
Privilégiez le trim planifié (fstrim.timer) plutôt qu’un montage en discard continu pour certaines charges afin d’éviter des pics de latence.

Separate pools by blast radius

Un seul grand thin pool est efficace jusqu’au moment où il ne l’est plus. Une VM runaway peut consommer les derniers pourcents et faire tomber des systèmes sans lien. Séparez les pools pour :

bases de données (prévisibles, à haute valeur, faible tolérance aux stalls)
workloads volatils (CI, espaces de travail, sandboxes développeurs)
staging de sauvegarde (si nécessaire)

Have pre-approved capacity add paths

En entreprise, la partie la plus lente d’un incident de capacité est souvent les approbations d’achat, pas les commandes. Pré-approuvez un mécanisme d’extension d’urgence de disque/LUN. Faites-en une procédure ennuyeuse. L’ennuyeux est rapide.

Listes de vérification / plan étape par étape

Checklist A: When the thin pool is at 95%+ (pre-incident)

Exécutez lvs et confirmez si Data% ou Meta% monte.
Identifiez les principaux consommateurs et tout pic récent de snapshots.
Pausez ou replanifiez les jobs lourds de snapshot/sauvegarde jusqu’à restauration de marge.
Si le VG a des extents libres, étendez le thin pool maintenant (ne pas attendre 100%).
Si le VG est plein, planifiez l’ajout d’un PV ou le déplacement d’au moins une VM hors pool.
Informez les parties prenantes : « Nous sommes en état d’alerte capacité ; action en cours. »

Checklist B: When the thin pool hits 100% (incident mode)

Arrêtez l’amplification des écritures : mettez en pause sauvegardes, automatisations de snapshot, jobs à forts logs si possible.
Confirmez l’utilisation du thin pool et quelle dimension est pleine : lvs Data% vs Meta%.
Vérifiez les logs noyau pour des erreurs d’allocation dm-thin.
Restaurez de la marge :
- Ajoutez un PV et étendez le pool (préféré), ou
- Supprimez des snapshots non essentiels (prudemment), ou
- Evacuez une VM vers un autre datastore.
Vérifiez que le pool est sous les seuils critiques et que la santé est OK.
Réactivez progressivement les jobs mis en pause et surveillez la pente.

Checklist C: After recovery (post-incident hardening)

Documentez la cause racine (changement de charge, job de snapshot, gaps de discard, erreur de capacity planning).
Ajoutez la surveillance Data% et Meta%, avec alertes sur la pente.
Appliquez des politiques de cycle de vie des snapshots et des plafonds.
Décidez d’une stratégie discard et testez-la en fenêtre de maintenance.
Réévaluez le ratio d’overcommit thin et séparez les workloads volatils si nécessaire.
Faites un test de restauration. Pas pour le plaisir — parce que c’est la seule vérification honnête.

FAQ

1) Is “thin pool 100%” always catastrophic?

Pas toujours immédiatement, mais c’est toujours inacceptable en production. Certaines charges peuvent continuer tant qu’elles n’ont pas besoin de nouvelles allocations de blocs. Vous ne contrôlez pas quand cela arrivera.

2) What’s worse: data full or metadata full?

Les deux sont mauvais. Les métadonnées pleines peuvent être plus surprenantes parce que le pool peut encore avoir beaucoup d’espace données. La différence pratique : les métadonnées sont souvent plus faciles à étendre rapidement si votre VG a des extents libres.

3) If I delete files inside a VM, why doesn’t the thin pool shrink?

Parce que l’hôte ne peut pas lire dans la tête de l’invité. Le système de fichiers invité marque les blocs libres en interne, mais à moins qu’il n’émette discard/trim et que ces discards soient transmis à dm-thin, l’hôte considère toujours ces blocs comme alloués.

4) Can I rely on enabling discard to recover from 100%?

Non. Le discard est préventif et joue sur le long terme. Quand vous êtes déjà à 100 %, vous avez besoin d’une marge physique immédiate : étendez le pool ou évacuez des données.

5) Should I stop VMs when the pool is full?

Si des VM échouent activement des écritures, arrêter les plus bruyants peut stabiliser la situation pendant que vous étendez la capacité. Mais préférez une solution qui restaure rapidement la marge ; laisser la production arrêtée pendant que vous débattez n’est pas une stratégie.

6) How much headroom should I keep?

Assez pour pouvoir répondre calmement. Concrètement : alertez tôt (70–80%), traitez 90% comme urgent et évitez d’opérer au‑dessus de 95% sauf si vous aimez l’adrénaline.

7) Do thin snapshots count against the pool even if I never use them?

Oui, car ils accumulent des blocs modifiés. Créer un snapshot est peu coûteux. Le garder pendant des écritures intensives ne l’est pas.

8) Is autoextend a good idea?

C’est utile quand le VG a des extents libres ou que vous avez un moyen automatisé d’ajouter des PV. Ce n’est pas un substitut à la surveillance et ne sert à rien quand le VG est déjà plein.

9) Why does Meta% grow at all—shouldn’t it be stable?

Les métadonnées suivent les mappages. Au fur et à mesure que les allocations augmentent et que les snapshots se multiplient, les métadonnées croissent. Les workloads à churn élevé peuvent gonfler les métadonnées plus vite que prévu.

10) Should databases live on thin provisioning?

Si vous devez, gardez une marge stricte et une discipline sur les snapshots, et surveillez agressivement. Beaucoup d’équipes choisissent la provision épaisse pour les bases afin d’éviter les stalls d’allocation imprévisibles.

Prochaines étapes qui réduisent réellement le risque

Si votre thin pool Ubuntu 24.04 est à ou près de 100 %, ne négociez pas avec la physique. Restaurez d’abord de la marge. Étendez le pool si vous le pouvez. Supprimez des snapshots uniquement quand vous en êtes sûr. Evacuez une VM si nécessaire. Puis — et seulement ensuite — cherchez le pourquoi.

Actions pratiques pour les prochaines 24–48 heures :

Ajoutez la surveillance sur Data% et Meta% via lvs, plus des alarmes sur le taux de changement.
Mettez en place et appliquez techniquement une politique de cycle de vie des snapshots, pas seulement à l’oral.
Validez le discard/TRIM bout en bout dans un test contrôlé ; décidez de planifier fstrim dans les invités.
Définissez un ratio d’overcommit thin maximal et isolez les workloads volatils dans leur propre pool.
Rédigez (et entraînez) le runbook « ajouter un PV et étendre le pool » pour que le prochain astreint ne l’apprenne pas à 3h du matin.

Le thin pool n’a que faire de vos occupations. Il se remplira quand même. Votre travail est de faire en sorte que « plein » soit un événement planifié, pas un incident.