Suite à une mise à jour du système du serveur de fichiers (apt-get upgrade), les volumes Glusterfs ne sont plus disponibles (un ou plusieurs volumes par application installée dans le cluster Kubernetes). Résultat : Tout est tombé.
Après analyse, il s’avère que ce n’est pas la mise jour système qui a causéd la panne, mais un problème I/O sur la carte SD du serveur.
Toutes les données Glusterfs sont sur un disque SSD, chiffré et n’ont donc pas été impactées lors de la mise à jour du serveur.
Pas de panique, j’avais déjà testé il y a très longtemps cette procédure. Cela m’évite de conserver une sauvegarde système du serveur de fichiers.
Après un crash, vous pouvez restaurer votre sauvegarde système, et rétablir les services un à un, ou bien repartir from scratch. J’opte toujours pour la solution “from scratch”, je prend soin de sauvegarder périodiquement la configuration des services et de créer des automates d’installation dès le départ. Le serveur de fichiers utilise la distribution Raspbian 64 bits, c’est le moment de passer à la version pure Debian.
Par conséquent, j’ai pris une nouvelle carte SD, sur laquelle j’ai installé la dernière image Debian Bullseye pour Raspberry Pi, les packages “glusterfs” et “cryptsetup”.
Opérations
-
Nouvelle carte SD
-
Installation de l’image Debian Bullseye pour Raspberry Pi sur la carte SD
-
Démarrer le serveur
-
Monter le disque des données Glusterfs (utilisation de “cryptsetup” pour ce dernier, toutes les données sont chiffrées)
-
Récupérer le nom des volumes utilisés par les services, pour çà il faut tenir une liste… Sinon parcourir, les manifests Kubernetes de vos applications, le nom du volume est indiqué dans la partie “Persistent Volumes”
-
Recréer les volumes un à un à partir des données présentes sur le disque, avec le paramètre “force”, vous êtes connecté sur le serveur Gluster :
-
Création du répertoire “/repair” qui va nous servir de point de montage temporaire pour un volume Glusterfs.
-
Création du volume à partir des données existantes :
gluster v create [nom de volume] $(hostname):[Emplacement du volume] forceforce est important ici, confirmer (y), comme le dit l’auteur cette subtilité n’apparaît dans aucune documentation :
The process for creating a new volume from the data of an existing set of bricks from an existing volume is not documented anywhere.
-
-
Démarrage du volume :
gluster v start [nom de volume] -
Montage du volume :
mount -t glusterfs $(hostname):/[nom de volume] /repair -
Puis comme indiqué par l’auteur, dans la procédure de “recovery” :
du -hc --max-depth=1 -
Démontage du volume temporaire :
umount /repair
Exécuter cette opération sur tous les volumes, redémarrer le cluster Kubernetes, les applications ont retrouvé leurs volumes.
Important : A propos de Glusterfs, le support de ce type de volume par Kubernetes a été supprimé à partir de la version 1.27… Pour ne pas tout réinstaller, Kubernetes supporte les volumes NFS et Glusterfs peut exporter ses volumes via NFS… Avant de migrer, il faudra déjà s’assurer, sur la version actuelle de mon cluster Kubernetes, que toutes les applications fonctionnent avec des volumes NFS au travers de Glusterfs, puis finalement, procéder à la mise à jour du cluster Kubernetes. +++