Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Effectivement, bon faut que je cible une sacrée réussite alors :D Voici ce que j'ai fait (uniquement sur data2cold pour l'instant) : - Augmenter encore la taille du metadata : lvextend --poolmetadatasize +224M v2cold/data2cold - Eteindre toutes les VM et containers utilisant le Thinpool - Désactiver le pool : lvchange -an v2cold/data2cold - Désactiver les Thin de ce pool : lvchange -an /dev/v2cold/* - Effectuer ensuite un "lvconvert --repair v2cold/data2cold" - Réactiver le pool : lvchange -ay v2cold/data2cold - Réactiver les Thin de ce pool : lvchange -ay v2cold - Redémarrer les VM et containers correspondants A priori, tout fonctionne ! \o/ Je vais attendre quelques jours avant d'attaquer les deux autres pool (soit le prochain full backup + weekend pour gérer l'interruption de service) Bonus PROXMOX : Pour identifier les anciens LV entre proxmox et les VM (oui j'ai oublié de les identifiés et avec deux LV de même taille, je ne savais plus lequel supprimer ^^), j'ai fait dans la VM : lsblk -o +SERIAL Cela renvoie en SERIAL par défaut : drive- (ex : drive-scsi2) Oui ! Proxmox rajoute un serial par défaut sur chaque disque... pratique non ? (moi je viens tout juste de le découvrir ^^) Encore merci pour vos aides ! Pidroid ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
> @Stéphane > > Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il > s'agissait) Imho, ce fut génial, ça l'est encore dans certains cas. Pas pour notre use-case. > C'est intéressant comme approche votre gestionnaire de cluster (et ca > m'éclaire un peu plus sur le fonctionnement et rôle des metas) Ben dès que t'as du DRBD, mais que tu veux laisser l'humain en priorité et refuser l'automagie "pacemaker/corosync"... Pas trop le choix. Sinon des scripts pour monter et descendre proprement les nodes (ce qu'on faisait jusqu'à présent)... Et laisser l'humain faire le reste. Ganeti nous a inspiré. Ce que l'on code est mille fois plus simple à utiliser mais limité à notre use-case GNU/Linux Debian Xen LVM DRBD. > Pour ma part, je suis encore en mono-server sans HA et j'ai cru > comprendre que Ceph sous Proxmox répondait également à ce besoin. Je CEPH c'est le top mais pour les riches (smile), il parait qu'il faut 4 bécanes pour être vraiment tranquille (j'ai gardé une thread au chaud sur ça par "les gens qui savent" : 3 ne seraient pas assez... Nous, on est pauvre et c'est du DRBD... Et vu notre use-case, c'est très bien en plus. Mais CEPH est à un autre niveau :) -- Be Seeing You Number Six ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Salut, Merci pour ces retours ainsi que toutes ces explications ! Ça me rassure énormément :) @Johann > 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" > > [...] Elle est top cette procédure et les explications qui vont avec aussi :) Merci ! Je vais faire progressivement mes 3 thinpool en commencant par le moins sensible : data2cold > > 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! Effectivement, n'étant pas trop sûr de ce que je faisais, j'ai laissé les anciens LV Thin au cas où... Bien que je n'utilise que ~52%, j'ai probablement dépassé les 11T de provisionné. Vais pouvoir attaquer le ménage bientôt :) > > J'ai tenté de calculer la taille des metadata avec la formule / * 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é. Arf... j'aurai du rajouter la visu pour data0hot et data1middle dans le "lvs -a" et ce dernier est d'ailleurs réalisé a posteriori de la "réparation" (j'aurai du le préciser) data0hot (taille 930G, chunk 512K) : - calculé : 122 Mo - constaté : 120 Mo avec pour usage Data%=64.23 et Meta%=88.02% data1middle (taille 1,64T, chunk 1M) : - calculé : 111 Mo - constaté : 108 Mo avec pour usage Data%=3,02% et Meta%=11,93% Je me suis peut être trompé dans mes calculs. Mais comme tu le précises bien, autant voir large surtout qu'on n'est pas sur les mêmes ordres de grandeur entre Data et Meta > > 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é. Ah ok, du coup j'élimine cette option. Merci. > Dans tous les cas avant manipulation, check l'état de tes backups. On ne sait jamais. Avec l'absence de backup hors-site, j'ai actuellement 3 duplication de backups sur site (ressource2cold... pas top ^^, un sur SoC et un autre sur mon LAB) et je refuse tout crash de météorite, inondation ou incendie sur ces prochains jours (et ceux d'après aussi :P ) @Stéphane Je ne connais pas du tout Ganeti (j'ai été voir un peu de quoi il s'agissait) C'est intéressant comme approche votre gestionnaire de cluster (et ca m'éclaire un peu plus sur le fonctionnement et rôle des metas) Pour ma part, je suis encore en mono-server sans HA et j'ai cru comprendre que Ceph sous Proxmox répondait également à ce besoin. Je m'orienterai probablement vers ce dernier si l'occasion (donc la réussite ^^) se présente. Encore merci à vous, c'est un grand soulagement de savoir que cet incident sera très prochainement clôturé et que j'en ressors grandi... A+ Pidroid ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
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 / * 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,
Re: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
Hello, Depuis plusieurs incidents du genre, je cree tous mes pools avec un meta de 1G, a adapter suivant tes besoins, mais cela tiens depuis plusieurs annees comme cela sans tomber chez nous. C'est sur que ce n'est pas satisfaisant comme reponse, mais chez nous ca marche... Je l'avais ajoute dans la supervision egalement ... A+ Nicolas > De: "Pi Droid" > À: "frsag" > Envoyé: Mardi 1 Décembre 2020 17:11:10 > Objet: [FRsAG] Proxmox 6.3-2 et Pool LVM-Thin > 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 | > 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 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 égaleme
[FRsAG] Proxmox 6.3-2 et Pool LVM-Thin
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 VSizeVFree v2cold 1 11 0 wz--n- 16.37t 1.08t ~# lvs -a v2cold LVVG Attr LSizePool 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-ao4.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 / * 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
