6.4 KiB
+++ title = "Réduire un cluster Garage" date = 2023-07-18 [taxonomies] tags = [ "système", "garage" ] +++
Des fois, tu fais des choix douteux. Et des fois, ces choix douteux t’amènent à avoir un cluster Garage bien trop gros par rapport à ton besoin réel.
La situation de départ
La recommandation pour Garage est d’avoir au moins 3 réplicats à travers un cluster. Autrement dit, quelques soient les machines utilisées (puisqu’un cluster peut avoir des machines complètement hétérogènes), il faut au minimum un replication_mode à 3 et du coup 3 machines, idéalement dans 3 zones différentes.
Donc si tu suis la recommandation, tu as monté 3 machines (ou 3 VMs, ou 3 conteneurs LXC, etc…) et comme tu es quelqu’un de prudent, tu en as même rajouté une quatrième qui va servir de gateway pour l’ensemble du cluster. Quand on a effectivement un peu de trafic HTTP, ça peut être intéressant d’avoir une passerelle pour accéder à l’ensemble de données du cluster. Non seulement, ça décharge les machines qui s’occupent du stockage, mais ça permet de bien séparer les rôles stockage et accès.
Et tout le souci est là : 3 machines, ça fait beaucoup et en réalité, 3 VMs ou 3 conteneurs LXC sur la même machine, ça ne sert pas à grand-chose. Donc oui, c’est loin de la recommandation, mais quand on a déjà de la redondance en dessous (NAS, RAID, etc…), ça ne sert pas à grand-chose d’avoir autant de réplicats.
Sauf que passer de la situation décrite à une autre situation n’est pas forcément ce qu’il y a de plus simple à faire non plus.
Et au commencement était la redondance
Première étape, il va falloir arrêter le cluster complet. Ça paraît évident, mais ça mérite d’être rappelé également : il ne vaut mieux pas qu’il y ait des données inscrites dans le cluster au moment où on l’arrête ou où l’on change sa topologie.
Pour commencer, il faut idéalement lancer un scrub sur l’ensemble des données, au moins sur le nœud qui est supposé rester à la fin. Ça se lance assez facilement avec cette commande :
garage repair --yes scrub start
On peut surveiller l’état de cette tâche en allant récupérer le TID correspondant et en regardant derrière la tâche en question :
# garage worker list | grep scrub
5 Busy Block scrub worker 4 4.07% - - -
# garage worker info 5
Task id: 5
Worker name: Block scrub worker
Worker state: Busy (throttled, paused for 0.012s)
Tranquility: 4
Total errors: 0
Consecutive errs: 0
Progress: 4.31%
Persistent errors: 0
Il faut savoir également que cette opération est extrêmement lente et demande pas mal de ressources disques. En effet, l’objectif est bien de vérifier l’intégrité de chaque bloc sur le disque, cela peut donc potentiellement prendre des heures, voire même des jours. Tu peux également voir un facteur amusant là-dedans, la tranquilité de Garage : plus elle est forte, plus Garage va bourrer comme un âne sur les disques.
Bref, quoiqu’il arrive, il vaut mieux le laisser terminer, cela permet de s’assurer que toutes les données sont saines. Si des blocs posent problème, ils seront récupérés depuis d’autres nœuds du cluster, opération bien entendu impossible a posteriori.
Attention Chérie, ça va trancher
Bon, tu t’en doutais mais à un moment, va bien falloir couper. Si tu as un NginX devant la passerelle ou si tu as plusieurs nœuds qui servent de passerelles avec un autre serveur Web devant, l’arrêter permet de simplifier un peu l’opération.
Ça laisse le cluster actif, sans pour autant autoriser les accès en lecture ou en écriture.
Si tu as un processus de sauvegarde de Garage (et tu as grandement intérêt à une avoir un), ça pourrait être une bonne idée de le déclencher maintenant parce qu’on va rapidement passer aux choses sérieuses.
Maintenant suivre une procédure pas vraiment officielle, pour mettre un cluster dans un état pas vraiment recommandé, le tout sans sauvegarde, comment dire… Faut aimer vivre dangereusement !
C’est pas le moment d’avoir les mains qui tremblent
Si l’on en croit la documentation officielle, on peut changer le mode de réplication mais il faut pour cela complètement supprimer le layout courant de tous les nœuds.
La première étape va donc consister à arrêter l’ensemble des nœuds et à supprimer le fichier /var/lib/private/garage/meta/cluster_layout. Le cluster va alors retourner dans son état d’origine, pas en terme de données, mais en terme d’organisation.
Autrement dit, les données ne bougent pas, les métadonnées ne bougent pas (ce qui va permettre à Garage de récupérer toutes ses fonctionnalités sans souci), mais l’ensemble des mécanismes de synchronisation du cluster, de réplication de données entre les membres va être fortement impacté.
Avant de redémarrer le cluster dans son ensemble, nous allons procéder à la modification du replication_mode. Il faut impérativement le changer sur l’ensemble des nœuds du cluster avant de redémarrer. Sous peine d’avoir une situation particulièrement instable.
Dans le fichier /etc/garage.toml, on peut donc passer :
replication_mode = "1"
Une fois la modif faite, on peut redémarrer l’ensemble du cluster, qui sera alors dans son état initial : tous les nœuds se connaissent, ils sont connectés, mais ils ne savent pas quel rôle est le leur.
Du coup, on peut tranquillement assigner un rôle unique à un unique serveur Garage :
# garage layout assign -c 5 -t nouveau -z zone1 2XXXXXXXXXXXXXX # la capacité n’a plus aucune importance ici
# garage layout apply --version 1
Normalement, une fois le layout appliqué, l’ensemble des données devrait de nouveau être disponible sur le seul et unique nœud disponible.
Les autres nœuds disparaîtront quand tu les éteindras, tout simplement.
C’est le moment de vérifier si toutes les données sont effectivement disponibles via S3 (peu importe la méthode, je vous recommande personnellement minio-client et de faire une synchro complète d’un bucket avant d’attaquer le reste).
Conclusage
Bah alors, elle est pas belle et frugale la vie ?