Ceph sous pression : comment j'ai récupéré un cluster Ceph dans Proxmox sans sauvegarde de configuration

Il y a des jours où tout semble contre vous. Ce jour-là, j’ai eu la preuve que Ceph est vraiment robuste. Je crée des clusters Proxmox VE avec ceph depuis plus de 6 ans et aujourd’hui, j’ai vécu une situation qui m’a fait vraiment apprécier la solidité de cette technologie. J’utilise Ceph pour y stocker aussi bien des données que des machines virtuelles. Les machines virtuelles peuvent être légères et simples comme des serveurs web, ou plus complexes comme des serveurs de base de données, mais aussi des machines virtuelles supportant kubernetes et ses pods.

Pour mettre un peu de contexte quant à ce problème, j’ai un cluster Proxmox VE 9.1.x avec trois noeuds (pve1 à pve3) et un cluster ceph squid (19.2.3) installé sur ces machines. Les noeuds sont interconnectés depuis le début, disposent et utilisent le stockage ceph. Ce cluster était à la base initialement installé avec Proxmox VE 8 et ceph quincy 17.

Les deux noeuds pve4 et pve5 sont neufs et ne sont pas encore dans le cluster proxmox ni ceph. Cependant, ces deux noeuds avaient déjà les outils ceph squid installé.

Les problèmes#

Première erreur : avoir installé ceph squid sur les machines pve4 et pve5 avant la mise en cluster. De par la manière dont ceph fonctionne, cela a créé un conflit de configuration entre les différents noeuds. Mais qu’est-ce que ça a provoqué concrètement ?

Quand vous installez ceph sur un noeud, il crée automatiquement un cluster ceph local avec ce noeud comme seul membre. Cela signifie que les deux noeuds pve4 et pve5 avaient chacun leur propre cluster ceph local, avec leur propre configuration et leur propre données. Les ceph_fsid, ceph.conf, etc. étaient différents sur chaque noeud.

En parallèle, le cluster ceph existant sur pve1 à pve3 continuait à fonctionner normalement.

En ayant vu cette mise en place dans le mauvais sens, ceph a alors été désinstallé sur les machines pve4 et pve5 (la commande effectuée sur les deux machines est la suivante : apt purge ceph-* && apt autoremove && rm -rf /var/lib/ceph && rm -rf /etc/ceph).

Une fois les deux machines pve4 et pve5 sans ceph, j’ai commencé l’intégration de pve4 dans le cluster Proxmox ; l’intégration s’est faite sans problème. Fort de cette petite victoire, j’ai lancé l’installation de ceph sur pve4. Lors de la configuration, une question a été posée quant à ceph et ses sous-réseaux publics et internes, en forçant des paramètres. C’est là qu’a commencé le plus gros du problème. Je ne comprends toujours pas pourquoi ni comment le noeud pve4 a réussi à forcer sa configuration dans le cluster ceph existant.

La suite, vous vous en doutez, a été lourde de conséquences. Ayant perdu la configuration du cluster ceph, les noeuds Proxmox ne pouvaient plus accéder au stockage où était stocké les disques des machines virtuelles. Chaque machine virtuelle est alors devenue inaccessible, avec un message de type kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0). Qui dit plus de stockage dit plus de service accessible. La panne s’est propagée à l’ensemble des machines virtuelles et à l’ensemble des services dont ceph était le support de stockage.

Les actions entreprises#

Avant toute chose, il fallait prévenir les utilisateurs de l’incident en cours, s’assurer de l’accès aux sauvegardes des machines virtuelles et ne pas éteindre les noeuds pve. Un rapide état des lieux a été réalisé pour identifier les machines virtuelles impactées (dans mon cas, toutes), et les sauvegardes ont été vérifiées. Mauvaise nouvelle, toute la configuration de ceph, sa crushmap et les clés d’authentification n’ont pas été sauvegardées.

A cet instant, voici l’état des lieux :

• toutes les machines virtuelles sont inaccessibles et en mode kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
• les sauvegardes des machines virtuelles sont accessibles, validées et prêtes à être restaurées
• aucune configuration de ceph n’est disponible
• l’accès à tous les noeuds proxmox est possible via ssh ou interface web

Il faut agir, le temps passe et les utilisateurs sont impactés. Plusieurs pistes ont été explorées pour résoudre le problème :

• installer un nouveau cluster ceph sur les machines pve4 et pve5, et restaurer les machines virtuelles depuis les sauvegardes sur ces noeuds, le temps de réparer ou reconstruire le cluster ceph existant
• récupérer la configuration de ceph depuis un autre noeud proxmox (pve1, pve2 ou pve3)
• déclarer forfait

La première piste est facile pour une reprise rapide, mais nécessite de restaurer toutes les machines virtuelles depuis les sauvegardes, ce qui est chronophage. De plus ça ne rétablit pas le cluster ceph existant. La deuxième piste est complexe mais permet de rétablir le cluster ceph existant avec un risque minimal de perte de données. La troisième piste est la plus simple, avec des conséquences non négligeables.

Partons sur la deuxième piste.

La résolution du problème#

Le fichier de configuration de ceph est stocké dans /etc/pve/ceph.conf. Celui-ci contient les informations de configuration du cluster ceph, notamment les adresses des noeuds ceph, l’identifiant du cluster et les clés d’authentification, entre autres. Le fichier a été écrasé, il a donc été recréé intégralement, en se basant sur la documentation officielle de Proxmox et sur les informations disponibles sur d’autres noeuds proxmox disposant aussi de ceph.

Dans la configuration de ceph qui a été faite dans le cluster Proxmox, chaque noeud dispose d’un moniteur (ceph-mon), d’un manager (ceph-mgr) et de plusieurs osd (ceph-osd). Il y a aussi des ceph-mds pour le support de filesystem cephfs, mais ils ne nous seront pas utiles. Comme c’est à cause du noeud pve4 que le problème est survenu, il faut le retirer du cluster ceph. Le noeud a été mis en mode maintenance (ha-manager crm-command node-maintenance enable pve4), puis la commande de suppression de ceph a été refaite, puis le noeud a été redémarré. Le redémarrage a grandement aidé pour la suite de la procédure.

Une fois pve4 revenu en ligne, il est temps de reprendre la main sur le cluster ceph. Environ une quinzaine de minutes s’est écoulée entre l’état des lieux et ce redémarrage de pve4.

Maintenant, occupons-nous du noeud pve1. Ceph a un accès exclusif à ses ressources (configurations, services, sockets etc.), et vu tous les problèmes rencontrés, la décision a été prise d’éteindre toutes les machines virtuelles du noeud proxmox pve1. Une fois celles-ci éteintes, il faut stopper tous les services ceph du noeud pve1 (systemctl stop ceph.target && systemctl status ceph.target). Maintenant, on peut récupérer la crushmap depuis le ceph-mon du noeud pve1. Voici les commandes à exécuter :

# Extraction directe de la crushmap (binaire compressé) depuis le store local d'un moniteur Ceph
ceph-monstore-tool /var/lib/ceph/mon/ceph-pve1 get crushmap > /tmp/crushmap_dump.bin
# Décompilation de la crushmap en format texte lisible
crushtool -d /tmp/crushmap_dump.bin -o /tmp/crushmap.txt
# Recompilation de la crushmap en format binaire
crushtool -c /tmp/crushmap.txt -o /tmp/crushmap.bin
# Injection de la crushmap dans le cluster ceph
ceph osd setcrushmap -i /tmp/crushmap.bin

La procédure ci-dessus permet de récupérer la crushmap actuelle du cluster ceph et de la réinjecter dans le cluster. Une des forces de ceph est de stocker des métadonnées importantes dans le cluster, comme la crushmap, ce qui permet de retrouver l’état actuel du cluster même après un redémarrage.

Cette crushmap est cruciale pour le bon fonctionnement du cluster, car elle définit la topologie des données dans le cluster (où se trouvent les données, comment elles sont répliquées etc.). Chaque osd, chaque moniteur, chaque mgr stocke cette information. Elle doit être conservée et sauvegardée de manière régulière et sécurisée.

Les commandes se sont toutes exécutées sans erreur. Il est temps de vérifier l’état du cluster ceph. Puisque tout est déjà remis en place ou dans un état instable, le plus simple est de redémarrer les services ceph sur le noeud pve1.

# Redémarrage des services ceph sur le noeud pve1
systemctl restart ceph-mon.target
systemctl restart ceph.target
ceph -s

Une grosse partie du travail est terminée, notamment grâce au résultat de la commande ceph -s qui montre que le cluster est opérationnel. Opérationnel veut dire que le cluster est capable de fonctionner, que les données sont accessibles depuis le noeud pve1, mais il n’est pas encore entièrement stable (état “HEALTH_WARN”).

Il reste à redémarrer les services ceph sur les autres noeuds et à vérifier l’état du cluster. Effectivement, après redémarrage des services ceph sur les autres noeuds, le cluster est stable et l’état est “HEALTH_OK”. Le fichier de configuration /etc/pve/ceph.conf a été resynchronisé avec le cluster, puisqu’il fait partie du dossier /etc/pve/ qui est synchronisé avec tous les noeuds du cluster.

Enfin, il est temps de vérifier que les machines virtuelles fonctionnent correctement et que le cluster est stable. Chaque machine virtuelle a été redémarrée et chaque service a été vérifié. Les utilisateurs ont été informés que le service était de nouveau opérationnel.

Au total, cette opération a pris environ 1 heure, du début de la panne jusqu’à la vérification finale.

La leçon pour une prochaine fois#

Les sauvegardes et leurs vérifications sont importantes :

• Sauvegarder le fichier de configuration /etc/pve/ceph.conf
• Sauvegarder la crushmap de ceph (visible dans l’interface web de Proxmox)
• Ne pas poursuivre le formulaire d’installation de ceph lorsque la page avec le choix des sous-réseaux de communication de ceph s’affiche alors que vous avez déjà une configuration existante dans le cluster

La prise en main de ceph et de Proxmox nécessite une bonne documentation et des tests avant de mettre en production. Son optimisation demande également une connaissance approfondie de l’architecture et des besoins spécifiques du projet.

Les documentations officielles de Proxmox et de Ceph (version Squid) sont un bon point de départ pour comprendre les concepts et les configurations.