Hello,
TL;DR : Comment gérer efficacement les pools LVM-Thin sous proxmox ? sans risque de crash dû à des metadata à 100% ?
Il y a quelque temps, j'avais basculé mes "datastores" Proxmox d'un traditionnel LVM à du LVM-Thin pour diverses raisons (snapshot, clone, overcommitment avec discard ...)
Seulement, voilà, le 23/11/20 la VM 118 de type "NAS" (samba) voit son disque dédié aux données en erreur au fur et à mesure que l'on stocke dessus avec notamment la perte significative de données (Cf plus bas pour les logs) puis fini par basculer régulièrement en read only jusqu'au 29/11/20 (oui... je pense que vous noterez ici la concordance avec un potentiel petit souci de monitoring et je ne vous parle pas de la fin de vie de mon backup hors site chez C14... ).
Après de nombreuses investigations, je découvre que le pool LVM-Thin sur lequel était le LV dédié aux données affiche un taux d'occupation de metadata à 100%.
Quelques infos qui aideront, je l'espère, à la compréhension :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
~# vgs v2cold VG #PV #LV #SN Attr VSize VFree v2cold 1 11 0 wz--n- 16.37t 1.08t
~# lvs -a v2cold LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert data2cold v2cold twi-aotz-- 11.29t 52.09 38.59 [data2cold_tdata] v2cold Twi-ao---- 11.29t
[data2cold_tmeta] v2cold ewi-ao---- 288.00m
[lvol0_pmspare] v2cold ewi------- 128.00m
ressource2cold v2cold -wi-ao---- 4.00t ... vm-118-disk-0 v2cold Vwi-a-tz-- <3.91t data2cold 31.33 vm-118-disk-1 v2cold Vwi-aotz-- <3.91t data2cold 31.05 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Afin de résoudre au plus vite la situation, voici les actions menées : - arrêt de toutes les vm utilisant data2cold - augmentation des metadata pour ce pool via la commande : lvextend --poolmetadatasize +160M v2cold/data2cold - augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold - tentative de redémarrage de la VM 118 en question (boucle de : boot + fsck + test d'écriture) mais ca retombe toujours en erreur. J'en ai conclu (à tort ?) que le LV vm-118-disk-0 de la VM était mort. - création d'un autre LV (vm-118-disk-1) sur ce même pool + restauration de backup et switch entre les deux LV sur la VM - la VM refonctionne à nouveau
Maintenant après vérification, il est nécessaire de restaurer les autres VM également. Seulement voilà... J'aimerai fiabiliser mes pool LVM-Thin... J'ai lu de très très nombreux documents et sites sur le sujet (le plus pertinent et complet à mes yeux pour ceux qui veulent : https://bugzilla.proxmox.com/show_bug.cgi?id=1241 ) et suis "ravi" de voir que je ne suis pas le seul à avoir rencontré ce problème... Pour autant je n'ai pas trouvé de solution fiable et pérenne.
En effet, voici mes conclusions :
- La commande d'augmentation des metadata pour un pool n'est pas la bonne (ou n'est pas complète). Bref, je ne suis pas parvenu à augmenter le lvol0_pmspare alors que ce dernier est nécessaire pour les snapshots et réparations si j'ai bien compris.
- J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Ce qui a donné pour mes 3 pools : data0hot (taille 930G, chunk 512K) : 122 Mo data1middle (taille 1,64T, chunk 1M) : 111 Mo data2cold (taille 11,3T, chunk 2M) : 379 Mo Complètement décorrélé de ce que j'ai sous les yeux...
- J'ai découvert les options thin_pool_autoextend_threshold et thin_pool_autoextend_percent dont l'interprétation varie selon la source (pas oser expérimenter du coup...)
- Ma peur de me retrouver dans une situation encore plus dégradée me rend très réticent à toute expérimentation (heureusement seul data2cold est à refaire pour le moment).
Et ma question : Comment bien gérer les LVM Thin-pool sous proxmox ? Je prends tout autre conseil également !
Merci d'avance,
pidroid
PS : concernant les incidents "monitoring" et "backup hors site", ils seront traités dans les plus bref délais.. je l'espère :-P
###############################################################################
Kern.log de la VM 118:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Nov 29 00:32:17 vm-118 kernel: [ 772.386502] EXT4-fs error (device dm-0): ext4_ext_map_blocks:4321: inode #82575362: comm kworker/u4:1: bad extent address lblock: 122881, depth:$ Nov 29 00:32:17 vm-118 kernel: [ 772.388484] EXT4-fs (dm-0): Delayed block allocation failed for inode 82575362 at logical offset 122881 with max blocks 2048 with error 117 Nov 29 00:32:17 vm-118 kernel: [ 772.388587] EXT4-fs (dm-0): This should not happen!! Data will be lost Nov 29 00:32:17 vm-118 kernel: [ 772.388587] Nov 29 00:32:17 vm-118 kernel: [ 772.426374] sd 2:0:0:2: [sdb] tag#169 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Nov 29 00:32:17 vm-118 kernel: [ 772.426382] sd 2:0:0:2: [sdb] tag#169 Sense Key : Aborted Command [current] Nov 29 00:32:17 vm-118 kernel: [ 772.426384] sd 2:0:0:2: [sdb] tag#169 Add. Sense: I/O process terminated Nov 29 00:32:17 vm-118 kernel: [ 772.426390] sd 2:0:0:2: [sdb] tag#169 CDB: Write(16) 8a 00 00 00 00 00 9d 9e 51 50 00 00 00 08 00 00 Nov 29 00:32:17 vm-118 kernel: [ 772.426393] print_req_error: I/O error, dev sdb, sector 2644398416 Nov 29 00:32:17 vm-118 kernel: [ 772.426472] Buffer I/O error on dev dm-0, logical block 330549546, lost async page write <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<