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