Résoudre en toute sécurité le problème de saturation de l'espace disque lors du provisionnement fin LVM sous SUSE Linux Enterprise

Que devez-vous déterminer avant de changer quoi que ce soit ?

Il faut d'abord déterminer si le pool à allocation dynamique a épuisé son espace de données , son espace de métadonnées , ou les deux. Cette distinction influence le plan de récupération. Un pool à allocation dynamique contient un volume logique de données qui stocke les blocs alloués et un volume logique de métadonnées qui assure le suivi de ces allocations. La taille virtuelle des volumes logiques à allocation dynamique peut dépasser la capacité physique du pool ; c'est le principe de l'allocation dynamique, mais aussi la raison pour laquelle le surdimensionnement doit être surveillé.

La documentation de SUSE Linux Enterprise Server 15 SP7 confirme que les volumes fins allouent de l'espace à partir d'un pool fin à la demande et que la taille virtuelle combinée peut dépasser la capacité de stockage physique disponible. La documentation LVM relative aux pools fins ajoute une règle de fonctionnement importante : étendre le pool avant que l'un Data%ou l' autre Meta%n'atteigne 100 %. Consultez le Guide d'administration du stockage de SUSE Linux Enterprise Server 15 SP7 et le manuel d'allocation dynamique LVM .

1. L'espace de données est-il saturé, ou les métadonnées sont-elles saturées ?

Utilisez lvsdes colonnes spécifiques plutôt qu'une vérification générique de l'espace disque. Un système de fichiers peut indiquer un espace virtuel libre alors que le pool physique sous-jacent est presque saturé.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent

Légende : Le pool mince doit être identifié par ses valeurs Data% et Meta% ; l’espace libre du système de fichiers à lui seul ne permet pas d’afficher l’épuisement physique du pool mince.

Si Data%la valeur est proche de 100, le pool n'a plus de blocs disponibles pour les nouvelles écritures. La documentation LVM officielle indique que des erreurs d'écriture peuvent survenir lorsque le pool de données est épuisé, ce qui peut endommager les systèmes de fichiers. Si la Meta%valeur atteint 100, la réponse est plus prudente car l'épuisement des métadonnées peut rendre incohérents à la fois les métadonnées du pool fin et les systèmes de fichiers.

2. Le groupe de volume possède-t-il encore des étendues physiques libres ?

Voici la prochaine étape. Un pool mince ne peut s'étendre que si son groupe de volumes dispose d'étendues libres, à moins d'y ajouter au préalable du stockage physique supplémentaire.

vgs -o vg_name,vg_size,vg_free
vgdisplay VG_NAME

Légende : La vérification de l’espace libre du VG permet de distinguer une simple extension de pool mince d’un cas nécessitant l’ajout préalable de stockage.

Si le volume de volumes (VG) dispose de suffisamment d'espace libre, vous pouvez généralement étendre le pool fin directement. Si VFreela capacité est nulle ou trop faible, n'essayez pas systématiquementlvextend ; déterminez s'il est possible de supprimer les volumes fins ou les snapshots inutiles, de récupérer des blocs avec la commande « discount » ou d'ajouter un nouveau volume physique.

3. Faut-il arrêter les applications avant la récupération ?

Si le pool est déjà saturé (100 %), arrêtez ou mettez en veille les applications gourmandes en écriture avant d'effectuer des modifications de stockage. Cela réduit le risque que les bases de données, les machines virtuelles, les conteneurs ou d'autres services continuent d'écrire pendant une panne ou une réparation de la couche de stockage.

systemctl stop YOUR_APPLICATION.service
systemctl status YOUR_APPLICATION.service

Légende : La mise en veille des applications limite les écritures supplémentaires pendant la récupération d’un pool fin plein ou endommagé.

Il n'existe pas de liste universelle de services à arrêter. Adaptez-vous à l'architecture de votre charge de travail et à vos procédures de maintenance. Pour les bases de données et les machines virtuelles, privilégiez la méthode d'arrêt ou de mise en veille prise en charge par le produit plutôt que d'interrompre brutalement les processus.

4. Si Data% est plein et que le VG a de l'espace libre, comment étendre le pool ?

Il faut étendre le pool mince lui-même, et non le LV mince virtuel, car le problème provient d'un manque de capacité physique du pool. Par exemple :

lvextend -L +20G VG_NAME/THIN_POOL
lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent VG_NAME/THIN_POOL

Légende : L’extension du pool étroit augmente la capacité physique ; le pourcentage de données qui en résulte devrait diminuer une fois que le nouvel espace sera disponible.

Le manuel d'lvextend documente l'extension directe du pool fin et l' --poolmetadatasizeoption distincte pour les métadonnées. Choisissez un incrément en fonction de votre taux de croissance réel et de la capacité de stockage que vous pouvez réserver. Un exemple fixe ne constitue +20Gpas une recommandation de dimensionnement pour tous les systèmes.

5. Que se passe-t-il si le groupe de volumes ne dispose d'aucun espace libre ?

N'ajoutez du stockage qu'après avoir vérifié que le périphérique de stockage cible est inutilisé et ne contient aucune donnée nécessaire. La création d'un volume physique LVM écrit les métadonnées LVM sur le périphérique sélectionné ; une erreur dans le nom du périphérique peut donc avoir des conséquences désastreuses.

lsblk
blkid

pvcreate /dev/NEW_DEVICE
vgextend VG_NAME /dev/NEW_DEVICE
vgs -o vg_name,vg_size,vg_free

Légende : Lorsque le VG est plein, un nouveau stockage physique peut être ajouté en premier, après que l’administrateur a vérifié le périphérique inutilisé approprié.

La documentation SUSE indique que les groupes de volumes peuvent être étendus par l'ajout de partitions ou de disques entiers. Avant d'effectuer cette opération sur des systèmes multipath, SAN, RAID, chiffrés, en cluster ou hébergés dans le cloud, il est important d'examiner attentivement la topologie de stockage, car le périphérique approprié peut différer du disque brut présenté dans un exemple simplifié.

6. Que se passerait-il si Meta% atteignait 100% ?

Considérez l'épuisement des métadonnées comme une réparation hors ligne plutôt que comme un simple ajout de capacité de stockage. Le manuel LVM sur les pools fins indique clairement que l'épuisement des métadonnées peut entraîner des incohérences entre les métadonnées du pool et le système de fichiers. La procédure de récupération documentée consiste à désactiver le pool, à le réparer lvconvert --repair, à étendre les métadonnées, puis à vérifier le système de fichiers.

Après avoir arrêté les applications, démontez les systèmes de fichiers ou désactivez les volumes logiques légers à l'aide du pool. Suivez ensuite une procédure de maintenance contrôlée similaire à :

lvchange -an VG_NAME/THIN_LV
lvconvert --repair VG_NAME/THIN_POOL
lvextend --poolmetadatasize +1G VG_NAME/THIN_POOL

Légende : Une condition de métadonnées saturées nécessite une réparation hors ligne du pool fin et un espace de métadonnées supplémentaire, et non pas simplement davantage d’étendues de données.

Cette +1Gfigure n'est donnée qu'à titre d'exemple. Le dimensionnement des métadonnées dépend de la taille du pool, de la taille des blocs, de l'utilisation des instantanés et du comportement d'allocation. Après la réparation, consultez les journaux système et utilisez la procédure de vérification ou de réparation spécifique au système de fichiers si des erreurs d'E/S se sont produites. N'exécutez pas un outil de réparation de système de fichiers sans précaution sur un système de fichiers monté.

La suppression de fichiers peut-elle libérer immédiatement un pool de stockage peu volumineux ?

Pas toujours. La suppression d'un fichier libère de l'espace dans le système de fichiers, mais le pool fin ne récupère les blocs physiques que lorsque les informations de suppression lui parviennent. La documentation LVM indique que la commande ` fstrimtrim` peut récupérer ces blocs, tandis que les snapshots peuvent continuer à y faire référence et les empêcher d'être libérés. Si le pool est configuré pour ignorer les blocs supprimés, `trim` ne les récupérera pas.

Lorsque le système de fichiers et la charge de travail le permettent, vérifiez le comportement de rejet et effectuez le nettoyage uniquement lorsque le pool est suffisamment stable pour fonctionner :

lvs -o lv_name,discards VG_NAME/THIN_POOL
fstrim -v /mount/point

La suppression d'anciens snapshots légers peut également libérer de l'espace de stockage lorsque ces snapshots sont les dernières références aux blocs. Vérifiez les exigences de sauvegarde et de conservation avant de supprimer des snapshots.

7. Comment éviter que cela ne se reproduise ?

Activez et vérifiez la surveillance des pools LVM minces et configurez l'extension automatique avec suffisamment de capacité libre dans le VG. LVM en amont utilise dmeventd, généralement via le lvm2-monitorservice, pour réagir lorsque l'utilisation des données ou des métadonnées dépasse le seuil configuré.

systemctl status lvm2-monitor.service
lvs -o+seg_monitor VG_NAME/THIN_POOL
lvchange --monitor y VG_NAME/THIN_POOL

lvmconfig --type full activation/thin_pool_autoextend_threshold
lvmconfig --type full activation/thin_pool_autoextend_percent

Légende : L’extension automatique dépend d’une surveillance active, d’un seuil approprié et d’étendues libres restantes dans le groupe de volumes.

Le manuel LVM indique qu'un seuil de 100 désactive l'extension automatique et que le seuil minimal valide est de 50. Un seuil plus bas laisse à LVM plus de temps pour réagir sur les pools présentant des taux d'écriture très élevés. Le pourcentage d'extension détermine l'ampleur de l'augmentation de la taille du pool lorsque la stratégie est déclenchée.

Une configuration représentative /etc/lvm/lvm.confpourrait être :

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

Ces valeurs sont données à titre d'exemple et ne constituent pas des valeurs par défaut universelles. Dimensionnez la marge de sécurité en fonction du débit d'écriture en rafale, de l'intervalle de surveillance, du délai de provisionnement du stockage et de l'espace libre disponible dans le groupe de volumes. L'extension automatique est inutile si le groupe de volumes est déjà plein.

8. Comment savez-vous que la récupération a réellement fonctionné ?

Vérifiez plusieurs signaux. Le pool doit disposer d'une marge suffisante, le VG doit avoir suffisamment d'espace libre pour la croissance prévue, les applications doivent pouvoir écrire normalement et les journaux ne doivent pas afficher d'erreurs d'E/S ou de métadonnées persistantes liées au pool fin.

lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
journalctl -u lvm2-monitor.service --since "30 minutes ago"

Légende : La récupération est confirmée lorsque l’utilisation du pool dispose d’une marge, que le VG conserve un espace libre utilisable et que la surveillance ne signale aucune erreur d’E/S persistante.

Redémarrez les applications progressivement et surveillez la capacité du pool jusqu'à ce que la charge de travail réelle revienne à la normale. Si Data%celle-ci augmente à nouveau anormalement vite, l'extension du pool a peut-être résolu la panne immédiate sans pour autant régler le problème de planification de la capacité.

Quand faut-il s'arrêter et emprunter une autre voie de récupération ?

Que faut-il éviter ?

• Ne présumez pas que df -hcela prouve qu'une piscine mince dispose d'un espace de stockage physique libre.
• N’initialisez pas un nouveau périphérique pvcreatetant que vous ne l’avez pas formellement identifié comme inutilisé.
• Ne considérez pas l'épuisement des métadonnées comme un problème identique à celui de l'épuisement des données ordinaires.
• Ne vous fiez pas à l'extension automatique sans réserver d'espace libre dans le VG.
• N’exécutez pas de commandes de réparation de système de fichiers sur des systèmes de fichiers montés, sauf si le fournisseur du système de fichiers prend explicitement en charge cette opération.
• Ne désactivez pas la surveillance uniquement pour supprimer les avertissements ; l’avertissement est souvent la dernière occasion d’étendre le pool avant que les écritures n’échouent.

Références officielles et primaires

• Guide d'administration du stockage de SUSE Linux Enterprise Server 15 SP7
• Documentation de SUSE SLES 15 SP7 Expert Partitioner
• Manuel de provisionnement fin LVM
• Manuel LVM lvextend