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
<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é.
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/
