Hello, Bienvenue dans ce que beaucoup d'entre nous on du expérimenter une fois... et désolé pour toi!
> 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. Tu as une solution pour résoudre le soucis du pmspare qui n'a plus la bonne taille : - Éteint toute tes VM utilisant le thinpool - Démonte tout ce qui tape dedans - Effectue ensuite un "lvconvert --repair v2cold/data2cold" A noter que cela peut prendre un peu de temps en fonction du CPU/vitesse du disque/taille/utilisation. C'est pas optimal mais je n'ai pas trouvé mieux. Cela devrait te créer un nouveau "data2cold_tmeta" de la même taille que le précédent (qui est déjà augmenté), te mettre l'ancien sous le nom " data2cold_tmeta0" vu comme un LV thin classique (pour backup). Mais surtout cela va te recrée le lvol0_pmspare à la bonne taille (identique à data2cold_tmeta). Je l'ai fais y'a pas une semaine pour résoudre un petit soucis de taille de meta sur un thinpool de 36T. Je l'avais déjà fait une ou deux fois avant. Je n'ai perdu aucune donnée à priori jusqu'ici :-) > augmentation du lv-thin suite à warning sur manque d'espace : lvextend -L +300G v2cold/data2cold Je pense que c'était superflu, d'après ton lvs -a, tu n'utilise que ~52% de data sur les 11.3T que tu as maintenant. Sauf si ce message était dû au fait que tu as réservé plus que les 11T sur l'ensemble des LV thin de tes VM? Si c'est le cas, à toi de voir, si tu ne penses jamais utiliser tous les disques au maximum... Après si tu préfères la sécurité et que ta la capacité disponible! > 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 Si ça fait une semaine qu'elle tape la limitation de meta, possible que le filesystem est pris grave dans la figure en effet. J'ai tapé une seule fois 100% qui a fait tomber des services, j'ai eu de la chance, j'ai rien perdu comme donnée. Mais on a réagit en 15 minutes max. N'oublie pas de supprimer l'ancien LV thin qui n'est plus utilisé pour pas utiliser de la place. Si tu as fait un import de backup depuis l'interface, il va te créer une image disk-1, mais pas supprimer de lui même disk-0 par sécurité. Il faudra penser à supprimer le disk-0 directement en CLI. Je crois qu'elle n'est plus visible en GUI ensuite. > J'ai tenté de calculer la taille des metadata avec la formule <ThinPool Size> / <Chunk Size> * 64 Effectivement c'est une bonne technique, j'avais dû la voir à une époque mais elle m'était sortie de la tête. Même si avec ces calculs je trouve le double de ceux que j'aurais en vrai si je suis mon utilisation actuelle. Je ne sais pas si je suis fatigué et raté quelque chose, possible... Soit un détail m'échappe dans le calcul. Après ça vaut mieux trop que pas assez. Mais n'oublie pas que cela serait les valeurs maximum théorique utilisées et pas l'utilisation actuelle. Mais tu tombes comme moi sur une valeur supérieure à la réalité. Personnellement, j'ai pris l'habitude d'attribuer une volume énorme de metadata, je préfère voir large que trop petit. Typiquement, j'ai mis 10g de meta sur ces machines avec 32 et 36To de thinpool. J'avais une différence de simple au double sur l'utilisation entre les deux machines, je viens de voir que j'ai une en chunk 256K et une en chunk 512K. En vrai je ne sais pas comment c'est possible, je ne me souviens pas comment je les ai créé à l'époque ^^ Si on suit les calculs théoriques du dessus, dans le pire des cas je serais à 8Go max, donc je suis large. En vrai, je serais plutôt vers les 4/5Go. Inutile de dire que dans le second cas avec du chunk 512K, j'aurais plus 5Go théorique et 3Go réel. C'est pas grave, c'est quoi quelques giga de perdu sur autant de To? Pour avoir l'esprit tranquille? Bon toi avec tes 2M de chunk, tu consommeras effectivement largement moins. Donc tu devrais être tranquille maintenant avec tes 11To. > 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...) J'ai testé, cela marche pas trop mal, si tu dépasse le thin_pool_autoextend_threshold% d'utilisation des meta, cela augmente de thin_pool_autoextend_percent% celui-ci. Mais je me suis retrouvé avec un cas étrange où cela augmente le tmeta mais pas le pmspare. Je ne sais pas si c'est volontaire, un bug, un souci de configuration de mon côté. > 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). Compréhensible. Si tu as d'autres thinpool, il faudra sans doute redimensionner tous les tmeta et reconstruire les pmspare. Si les calculs théoriques te semblent un peu étranges par rapport à ce que tu vois, essaye de calculer par rapport à l'utilisation réel (Data% vs Meta%). Tu auras une idée de combien tu auras besoin, par exemple si tu consommes 80% de Meta avec 50% des Data, tu sais qu'il faudra sans doute au moins doubler le tmeta. Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais. Bon courage à toi P.S : Désolé des fôtes, il est tard :-) Johann Le mar. 1 déc. 2020 à 17:12, Pi Droid <pidroi...@gmail.com> a écrit : > 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 > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ >
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
