Proxmox Ceph « mon down/out of quorum » : restaurer les moniteurs et le quorum sans panique

Comment le quorum des moniteurs Ceph échoue réellement (modèle mental)

Les moniteurs Ceph (MON) ne sont pas « juste un autre daemon ». Ils sont la source de vérité du cluster : le monmap (qui sont les moniteurs), l’osdmap (quels OSD existent et où), l’état d’authentification (CephX) et un tas d’état de consensus qui doit être d’accord sur la majorité.

Les moniteurs forment un quorum en utilisant un algorithme de consensus (Ceph a historiquement utilisé une machinerie de type Paxos et a évolué au fil des versions). En termes simples : les moniteurs doivent pouvoir communiquer entre eux de manière fiable et s’accorder sur les dernières maps engagées. S’ils ne le peuvent pas, ils préfèrent cesser d’être autoritaires plutôt que de mentir.

Que signifient généralement « down » et « out of quorum »

• mon down : ce processus de moniteur n’est pas joignable ou ne tourne pas (ou est bloqué au point d’être considéré comme arrêté).
• out of quorum : le processus est actif, mais il ne fait pas partie de la majorité qui s’accorde actuellement sur l’état. Il peut être partitionné, avoir un décalage d’heure, posséder un monmap ancien, ou avoir un store endommagé.
• no quorum : le cluster est effectivement aveugle. Les OSD peuvent continuer à servir des IO existants un moment, mais les changements d’état et le reporting de santé deviennent limités et risqués. Considérez cela comme « arrêtez d’improviser ».

La règle d’or

Ne « réparez le quorum » en supprimant des éléments que lorsque vous savez quel moniteur possède la vérité la plus fraîche. Si vous effacez le mauvais moniteur, vous pouvez transformer une panne récupérable en un projet de reconstruction.

Voici l’état d’esprit opérationnel que je veux que vous adoptiez : les moniteurs forment le plan de contrôle ; les OSD sont le plan de données. Vous pouvez survivre à un plan de données meurtri avec de la redondance. Vous ne pouvez pas survivre à un plan de contrôle qui est à la fois faux et sûr de lui.

Une citation à garder au mur : L’espoir n’est pas une stratégie. — General Gordon R. Sullivan. En exploitation, ce n’est pas une motivation ; c’est un rappel de vérifier avant de changer.

Blague n°1 : Un moniteur Ceph hors quorum, c’est comme un manager absent de la réunion — il envoie encore des e-mails, mais personne ne les prend au sérieux.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Voici la séquence « arrêter l’hémorragie ». Ne commencez pas par reconstruire des moniteurs. Commencez par prouver le mode de panne.

Premier : Y a-t-il un quorum du tout ?

Si au moins un moniteur est en quorum, vous avez une ancre. Si aucun ne l’est, votre travail consiste à identifier le magasin de moniteur survivant le plus autoritaire et à le ramener, pas à créer une nouvelle réalité.

Deuxième : Est-ce un problème réseau ou d’heure qui se déguise en problème Ceph ?

Les partitions réseau et la dérive d’heure sont les deux principales causes de « tout a l’air cassé ». Vérifiez-les avant de toucher les données de mon.

Troisième : Le store du moniteur est-il sain (espace disque, système de fichiers, corruption) ?

Les moniteurs sont sensibles aux événements de disque plein et aux problèmes de système de fichiers. Un moniteur peut être « en cours d’exécution » mais effectivement mort parce qu’il ne peut pas valider des écritures.

Quatrième : Le monmap/FSID est-il incorrect ou obsolète sur un nœud ?

Une erreur fréquente sur Proxmox/Ceph : un nœud conserve une config d’un ancien cluster ou a été réinstallé, et maintenant il parle avec la mauvaise identité en toute confiance.

Cinquième : Considérez la reconstruction/création seulement maintenant

Reconstruire un moniteur est acceptable lorsque vous avez le quorum et que vous remplacez un membre. C’est dangereux lorsque vous n’avez pas de quorum et que vous devinez.

Faits et contexte intéressants (pourquoi les moniteurs sont sensibles)

1. Le nom Ceph vient d’un monstre marin mythologique (Cephalopode). C’est un nom mignon pour un système qui vous mordra si vous faites de l’exploitation négligente.
2. Les moniteurs Ceph ont utilisé un mécanisme de consensus basé sur Paxos pendant des années ; l’objectif de conception est une forte cohérence pour les maps, pas « toujours disponible à tout prix ».
3. La règle du « nombre impair de MONs » n’est pas une superstition. Le consensus majoritaire signifie que 3 MON tolèrent 1 défaillance ; 4 MON tolèrent encore 1 ; 5 tolèrent 2.
4. La dérive d’heure est une panne de premier ordre dans les systèmes distribués. Les moniteurs peuvent refuser de participer si le décalage d’horloge casse les hypothèses de lease/timeout.
5. L’état d’auth CephX est stocké et servi par les moniteurs ; un moniteur avec des keyrings cassés peut provoquer des « erreurs d’autorisation aléatoires » dans le cluster.
6. Les moniteurs stockent des maps critiques sur disque local ; ils ne sont pas « sans état ». Traitez le store d’un moniteur comme une petite base de données répliquée par consensus.
7. L’intégration Proxmox facilite le déploiement, mais elle facilite aussi l’oubli des outils de cycle de vie propres à Ceph (et de leur importance).
8. Historiquement, la « corruption du store mon » provient souvent d’un disque plein, d’une coupure de courant ou de bugs de système de fichiers — rarement d’un « Ceph qui décide d’oublier ».

Tâches pratiques : commandes, sorties attendues et décisions (12+)

Ce sont des tâches réelles que j’exécute pendant un incident. Chacune contient : la commande, ce que signifie la sortie, et la décision suivante. Exécutez-les sur un nœud moniteur sauf indication contraire.

Task 1: Check current quorum view (from any node with ceph.conf + key)

cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_WARN
            1/3 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2 (age 5m), out of quorum: mon3
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 40 TiB / 53 TiB avail
    pgs:     256 active+clean

Signification : Vous avez le quorum (mon1, mon2). mon3 est le patient, pas le chirurgien.

Décision : Réparez/réintégrez mon3 en utilisant le quorum sain. Évitez les opérations « forcées ».

Task 2: If ceph -s hangs, test direct MON connectivity

cr0x@server:~$ timeout 5 ceph -s; echo $?
124

Signification : Le code de sortie 124 = timeout. C’est souvent « pas de quorum » ou le client ne peut pas atteindre les moniteurs.

Décision : Passez aux vérifications réseau/heure et aux logs locaux du moniteur. Ne commencez pas à modifier les maps Ceph depuis un hôte qui ne peut même pas parler aux MON.

Task 3: Identify the monitor endpoints from config

cr0x@server:~$ grep -E '^(fsid|mon_host|public_network|cluster_network)' /etc/pve/ceph.conf
fsid = 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
mon_host = 10.10.10.11 10.10.10.12 10.10.10.13
public_network = 10.10.10.0/24
cluster_network = 10.10.20.0/24

Signification : Vous avez les IP prévues. Si l’IP d’un moniteur a changé, il « existe » mais ne sera jamais trouvé.

Décision : Confirmez ces IP sur chaque nœud. Si elles sont incorrectes, corrigez le réseau/DNS et seulement ensuite touchez à Ceph.

Task 4: Check MON systemd state (is it actually running?)

cr0x@server:~$ systemctl status ceph-mon@mon3 --no-pager
● ceph-mon@mon3.service - Ceph monitor daemon
     Loaded: loaded (/lib/systemd/system/ceph-mon@.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:11:32 UTC; 2min 12s ago
    Process: 18231 ExecStart=/usr/bin/ceph-mon -f --cluster ceph --id mon3 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)

Signification : Ce n’est pas un mystère de quorum ; c’est une défaillance de service sur mon3.

Décision : Lisez les logs, vérifiez l’espace disque, contrôlez le store du mon, puis redémarrez.

Task 5: Read recent MON logs for the real reason

cr0x@server:~$ journalctl -u ceph-mon@mon3 -n 80 --no-pager
Dec 26 09:11:31 mon3 ceph-mon[18231]: mon.ceph-mon@mon3: error opening mon data directory at '/var/lib/ceph/mon/ceph-mon3': No space left on device
Dec 26 09:11:31 mon3 systemd[1]: ceph-mon@mon3.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:32 mon3 systemd[1]: ceph-mon@mon3.service: Failed with result 'exit-code'.

Signification : Disque plein. Classique. Prévisible. Réparable.

Décision : Libérez de l’espace en toute sécurité, puis exécutez un contrôle de cohérence du système de fichiers si nécessaire, puis redémarrez le MON.

Task 6: Verify filesystem capacity and inode pressure

cr0x@server:~$ df -h /var/lib/ceph/mon/ceph-mon3
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        50G   50G     0 100% /

cr0x@server:~$ df -i /var/lib/ceph/mon/ceph-mon3
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       3276800 220000 3056800    7% /

Signification : La capacité est le problème, pas les inodes.

Décision : Supprimez les fichiers inutiles appropriés (logs, anciens kernels, dump de crash). Ne supprimez pas les fichiers du store du mon par colère.

Task 7: Check time sync (quorum hates time travelers)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-26 09:14:10 UTC
           Universal time: Fri 2025-12-26 09:14:10 UTC
                 RTC time: Fri 2025-12-26 09:14:09
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Signification : Ce nœud est synchronisé.

Décision : Exécutez ceci sur chaque MON. Si l’un affiche « synchronized: no » ou une grande dérive, corrigez NTP/chrony avant de retenter le quorum.

Task 8: Verify MON ports are reachable between monitors

cr0x@server:~$ nc -vz 10.10.10.11 3300
Connection to 10.10.10.11 3300 port [tcp/*] succeeded!

cr0x@server:~$ nc -vz 10.10.10.12 6789
Connection to 10.10.10.12 6789 port [tcp/*] succeeded!

Signification : Les versions modernes de Ceph utilisent 3300 (msgr2) ; la compatibilité plus ancienne utilise 6789 (msgr1). Si ces ports échouent, le quorum ne reviendra pas tant que le réseau/les pare-feu ne seront pas corrigés.

Décision : Si bloqué : corrigez les règles de pare-feu, VLAN, MTU, routage. Si ouvert : passez aux vérifications du store mon.

Task 9: Confirm the MON identity directory exists and permissions are sane

cr0x@server:~$ ls -ld /var/lib/ceph/mon/ceph-mon3
drwxr-x--- 8 ceph ceph 4096 Dec 26 09:02 /var/lib/ceph/mon/ceph-mon3

Signification : Le répertoire existe et appartient à ceph.

Décision : Si la propriété est incorrecte (fréquent après des restaurations manuelles), corrigez-la avant de redémarrer : le moniteur ne s’auto-guérira pas des erreurs de permissions.

Task 10: See who the cluster thinks the monitors are (mon dump)

cr0x@server:~$ ceph mon dump
epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000
min_mon_release 18 (reef)
election_strategy: 1
0: [v2:10.10.10.11:3300/0,v1:10.10.10.11:6789/0] mon.mon1
1: [v2:10.10.10.12:3300/0,v1:10.10.10.12:6789/0] mon.mon2
2: [v2:10.10.10.13:3300/0,v1:10.10.10.13:6789/0] mon.mon3

Signification : mon3 est toujours dans le monmap. Bien. Vous voulez qu’il rejoigne, pas qu’il soit ré-ajouté depuis zéro sauf si nécessaire.

Décision : Si une IP/hostname est incorrecte ici, vous devrez corriger l’adressage (ou, en dernier recours, supprimer/rajouter le moniteur correctement).

Task 11: Check monitor store health hints (fsck is for filesystems; this is for MONs)

cr0x@server:~$ ceph-mon -i mon3 --cluster ceph --mon-data /var/lib/ceph/mon/ceph-mon3 --check
ceph-mon: mon data is consistent

Signification : Le store du moniteur semble suffisamment cohérent pour démarrer.

Décision : Redémarrez le service. Si le check signale une corruption, arrêtez et choisissez une voie de reconstruction plutôt que de redémarrages répétés.

Task 12: Restart the MON and watch it join quorum

cr0x@server:~$ systemctl restart ceph-mon@mon3
cr0x@server:~$ ceph -s
  cluster:
    id:     0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 10s)
    mgr: mon1(active), standbys: mon2
    osd: 12 osds: 12 up, 12 in

Signification : De retour en quorum. Vous avez fini la partie urgente.

Décision : Faites maintenant le suivi : pourquoi le disque s’est rempli ? Ajoutez des alertes et de l’entretien pour que cela ne se reproduise pas un vendredi soir.

Task 13: If no quorum, inspect local mon’s view without contacting the cluster

cr0x@server:~$ ceph-mon -i mon1 --cluster ceph --show_monmap | head
dumped monmap epoch 21
fsid 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
last_changed 2025-12-26T08:58:07.123456+0000
created 2025-11-02T12:12:01.000000+0000

Signification : Vous pouvez lire le monmap depuis le store local. Cela aide à prouver quel store est intact.

Décision : Comparez entre nœuds ; l’epoch le plus récent et un FSID cohérent sont vos indices pour « quel store de moniteur croire ».

Task 14: Confirm FSID matches across Proxmox ceph.conf and mon store

cr0x@server:~$ ceph fsid
0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f

Signification : Si cela renvoie un FSID différent de /etc/pve/ceph.conf, vous mêlez des clusters ou des configurations.

Décision : Arrêtez et réconciliez la dérive de configuration avant de « corriger » autre chose.

Task 15: Validate that the monitor is listening on expected addresses

cr0x@server:~$ ss -lntp | egrep ':(3300|6789)\s'
LISTEN 0      4096         10.10.10.13:3300       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=20))
LISTEN 0      4096         10.10.10.13:6789       0.0.0.0:*    users:(("ceph-mon",pid=19012,fd=21))

Signification : Il est lié correctement. S’il écoute seulement sur 127.0.0.1 ou la mauvaise interface, vous avez trouvé le coupable.

Décision : Corrigez le réseau hôte et/ou les paramètres public_network de Ceph ; redémarrez.

Task 16: Check for firewall policy blocking intra-cluster traffic

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N PVEFW-Drop
-N PVEFW-Input

Signification : Vous avez une posture par défaut DROP. C’est acceptable, mais seulement si les ports Ceph sont autorisés entre les MON.

Décision : Si cela a changé récemment, inspectez les jeux de règles et assurez-vous que TCP 3300 et (si nécessaire) 6789 sont autorisés sur le réseau public Ceph.

Task 17: Proxmox Ceph tooling sanity check (don’t fight your platform)

cr0x@server:~$ pveceph status
Cluster FSID: 0b3d3e6f-6c1a-4b2c-9c11-0c1e9d9e8a2f
MONs: 3, quorum: mon1, mon2, mon3
OSDs: 12 up/12 in
MGR: mon1 (active)

Signification : Confirme la vue de Proxmox avec celle de Ceph.

Décision : Si elles divergent, suspectez une dérive de configuration entre /etc/pve, le /etc/ceph local, et ce que votre CLI utilise réellement.

Voies de récupération : de « un mon down » à « pas de quorum »

Scénario A : Un moniteur down, le quorum existe encore (meilleur cas)

C’est la panne « normale ». Vous avez assez de moniteurs pour maintenir la majorité. Votre objectif est de remettre le moniteur manquant en service ou de le remplacer proprement.

• Corrigez la cause locale (disque plein, service planté, nœud redémarré sur un mauvais kernel, NIC instable).
• Validez la synchronisation temporelle et les ports réseau.
• Démarrez le moniteur et surveillez sa réintégration.

Soyez strict : si un store de moniteur est corrompu, ne continuez pas à le redémarrer en espérant qu’il « finira par marcher ». C’est ainsi que l’on obtient un quorum instable et des flapping chroniques.

Scénario B : Deux moniteurs down dans un cluster à 3 moniteurs (pas de quorum)

Vous êtes maintenant en mode « restaurer la majorité ». Avec 3 MON, il vous faut 2. La récupération la plus sûre ressemble généralement à ceci :

1. Choisissez le nœud moniteur le plus susceptible d’être intact (stockage stable, moins touché, probablement avec un store mon intact).
2. Démarrez proprement ce moniteur et validez son store.
3. Mettez en ligne un second moniteur pour atteindre le quorum.
4. Une fois le quorum rétabli, reconstruisez tout moniteur restant depuis le quorum sain.

Si vous vous contentez de redémarrer les services au hasard, vous pouvez vous retrouver avec chaque moniteur croyant à un monde différent. Les systèmes de consensus ne récompensent pas la danse interprétative.

Scénario C : Tous les moniteurs « up » mais aucun en quorum (flapping de quorum ou split brain)

Cela provient généralement d’une partition réseau ou d’un décalage d’heure. Parfois c’est un mismatch de MTU sur le réseau public Ceph : de petites probes passent, les gros messages échouent, et tout semble « presque joignable ».

Priorisez :

• Vérification de la synchronisation d’horloge entre tous les MON.
• Connectivité bidirectionnelle sur 3300/6789 entre tous les MON.
• Exactitude des interfaces/IP (pas d’IP dupliquée, pas d’entrées ARP obsolètes, pas de surprises VRRP).
• Revue des changements de pare-feu (pare-feu Proxmox ou en amont).

Scénario D : Corruption du store du moniteur (le désagréable)

Si vous avez le quorum, reconstruire un moniteur individuel est routinier : arrêtez-le, mettez de côté son store, recréez-le depuis le quorum, démarrez-le. Si vous n’avez pas de quorum, la récupération de corruption consiste à trouver le store survivant le moins mauvais et reconstituer le quorum à partir de lui.

En pratique, vous ferez l’une des actions suivantes :

• Reconstruire un moniteur depuis un quorum existant (sûr).
• Recréer un nouveau moniteur et le joindre au quorum (sûr si le quorum existe).
• Récupérer le quorum en démarrant le meilleur store survivant et en ajoutant les autres (risqué mais parfois nécessaire).

Blague n°2 : Un store de moniteur corrompu, c’est comme un tableur corrompu — quelqu’un proposera de « le retaper à la main », et cette personne ne devrait pas avoir d’accès production.

Listes de contrôle / plan étape par étape (faites ça, pas des impressions)

Checklist 1 : Quand vous avez encore le quorum (réparer un MON unique)

1. Confirmez l’existence du quorum avec ceph -s. Si ça bloque, basculez sur les diagnostics locaux.
2. Sur le nœud MON en panne : systemctl status ceph-mon@<id> et journalctl -u ....
3. Corrigez la cause racine : disque plein, permissions, NIC down, heure non synchronisée, règle de pare-feu.
4. Exécutez un check du store : ceph-mon -i <id> --check (là où c’est supporté) pour éviter le flapping.
5. Redémarrez le MON et confirmez qu’il écoute (ss -lntp).
6. Confirmez la réintégration dans ceph -s et ceph quorum_status.
7. Faites le suivi : surveillez les tendances d’utilisation disque, ajoutez des alertes, empêchez la récurrence.

Checklist 2 : Quand vous n’avez aucun quorum (restaurer la majorité en sécurité)

1. Arrêtez de changer des choses à l’échelle du cluster. Votre objectif est de trouver un ou deux bons stores de moniteur.
2. Choisissez un nœud candidat « meilleur moniteur » (stockage le plus stable, le moins modifié, probablement avec un store mon intact).
3. Sur chaque nœud MON : vérifiez l’espace disque (df -h), la synchronisation de l’heure (timedatectl), et les erreurs récentes (journalctl).
4. Confirmez la cohérence du FSID entre /etc/pve/ceph.conf et la vue du store local (ceph-mon --show_monmap).
5. Réparez d’abord les partitions réseau (ports 3300/6789). Si les moniteurs ne peuvent pas communiquer, aucune reconstruction ne vous aidera.
6. Démarrez proprement un moniteur. Surveillez les logs. Vous cherchez un comportement de « forming quorum », pas seulement « active (running) ».
7. Mettez en ligne un second moniteur pour atteindre la majorité. Deux MON sur trois forment le quorum.
8. Une fois le quorum rétabli : reconstruisez tout moniteur restant correctement depuis le quorum plutôt que d’essayer de ressusciter un état corrompu.

Checklist 3 : Reconstruire un moniteur lorsque le quorum existe (remplacement contrôlé)

Je ne vous donne pas volontairement une commande « nuke and pave » en un seul appel. Les reconstructions sont sûres lorsque vous les faites délibérément et que vous vérifiez à chaque étape.

1. Vérifiez le quorum et la santé : ceph -s, ceph mon dump.
2. Arrêtez le MON ciblé : systemctl stop ceph-mon@monX.
3. Déplacez le vieux store : renommez le répertoire mon au lieu de le supprimer. Cela vous donne un levier de rollback.
4. Recréez le store du moniteur depuis les maps actuelles du cluster en utilisant l’outillage adapté à votre version Ceph/Proxmox.
5. Démarrez le MON et vérifiez la jonction via ceph -s et ceph quorum_status.

Si votre organisation attend des runbooks, écrivez ceci avec vos vrais IDs de moniteurs et chemins. Rien ne se démode plus vite que « monX » pendant une vraie panne.

Erreurs communes : symptôme → cause racine → correction

1) Symptom: “mon down” after a routine reboot

Cause racine : répertoire de données du moniteur manquant/déplacé, permissions modifiées, ou le nœud a démarré avec un nom d’hôte/ID différent de celui attendu.

Correction : Validez que /var/lib/ceph/mon/ceph-<id> existe et appartient à ceph:ceph. Confirmez que l’ID du moniteur correspond au nom de l’unité de service. Redémarrez et vérifiez l’écoute des ports.

2) Symptom: “out of quorum” but service is active

Cause racine : partition réseau, pare-feu bloquant 3300/6789, mismatch MTU, ou routage asymétrique entre MON.

Correction : Testez la connectivité MON-à-MON avec nc -vz sur 3300 et 6789. Vérifiez le switch/VLAN/MTU, puis les règles de pare-feu. Ne reconstruisez pas des moniteurs pour un problème réseau.

3) Symptom: ceph commands hang or time out from some nodes only

Cause racine : nœuds clients pointant vers des adresses mon obsolètes dans la config, ou DNS retournant des IP différentes. Parfois c’est un bazar dual-stack (IPv6 à moitié configuré).

Correction : Confirmez que mon_host est correct dans la configuration que le nœud utilise réellement. Standardisez sur des IP explicites si votre DNS n’est pas discipliné.

4) Symptom: monitors flap in and out of quorum every few minutes

Cause racine : dérive d’heure, hôte surchargé, perte de paquets intermittente, ou latence disque causant des commits lents.

Correction : Vérifiez timedatectl sur tous les MON. Inspectez dmesg pour les erreurs de stockage. Cherchez du CPU steal ou de l’IO wait. Corrigez la plateforme, pas le symptôme.

5) Symptom: after “fixing” a monitor, Ceph shows the wrong FSID or weird auth errors

Cause racine : clusters mélangés : /etc/ceph/ceph.conf obsolète, mauvais keyring, ou nœud réinstallé et ayant généré une nouvelle config de cluster dans un chemin différent.

Correction : Vérifiez que le FSID dans /etc/pve/ceph.conf et ceph fsid correspondent. Assurez-vous que votre CLI utilise la config et le keyring voulus. Supprimez les configs obsolètes qui masquent celles gérées par Proxmox.

6) Symptom: monitor won’t start, log says “No space left on device”

Cause racine : système de fichiers root plein (souvent logs, dumps de crash, ou sauvegardes stockées localement).

Correction : Libérez de l’espace en toute sécurité. Puis redémarrez. Si le store du moniteur a été impacté, exécutez une vérification de cohérence si disponible et surveillez les erreurs répétées.

7) Symptom: MON starts but immediately exits with store-related errors

Cause racine : corruption de la base de données du moniteur, parfois après une perte de puissance ou des erreurs disque.

Correction : Si le quorum existe, reconstruisez ce moniteur depuis le quorum et gardez l’ancien store comme preuve. Si aucun quorum, identifiez le store le plus intact parmi les moniteurs et restaurez le quorum à partir de lui.

Trois mini-histoires d’entreprise issues du front des moniteurs

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox propre : trois moniteurs, beaucoup d’OSD, et la conviction que « les moniteurs sont légers, donc on peut les mettre n’importe où ». Un moniteur vivait sur un nœud qui exécutait aussi un runner CI bruyant et une stack de métriques qui écrivait comme si on la payait à l’inode.

Une mise à jour du kernel nécessitait une fenêtre de reboot. Le redémarrage s’est bien passé. Puis, dix minutes plus tard, la santé Ceph a dégénéré : un moniteur down, un autre en « slow ops », et le troisième hors quorum. L’astreinte a supposé que c’était un bug Ceph parce que « rien n’avait changé sauf un reboot ». Cette hypothèse a fait perdre la première heure.

La réalité : le reboot a relancé le runner CI, qui a immédiatement saturé le disque sur ce nœud. La latence de commit du moniteur a explosé, les élections ont commencé à expirer, et le quorum est devenu une porte tournante. Rien n’était « cassé » chez Ceph. La plateforme violait le besoin du moniteur pour un IO banal et prévisible.

La correction n’était pas exotique. Ils ont déplacé le runner CI hors de l’hôte moniteur, attribué au moniteur un stockage IO plus rapide, et mis en place des alertes sur l’utilisation du root et la latence disque. La leçon du postmortem était embarrassante de simplicité : les moniteurs sont « légers » seulement si vous n’intimidez pas leurs disques.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Un autre service voulait durcir la sécurité. Ils ont activé une posture de pare-feu stricte sur Proxmox et se sont félicités d’« avoir verrouillé le cluster ». Ça a marché dans le sens où rien d’évident ne cassait immédiatement. Les moniteurs sont restés en quorum pendant des semaines.

Puis un événement de maintenance réseau a provoqué le reboot d’un moniteur. À son retour, il n’a pas pu réintégrer le quorum. Le service tournait, les logs semblaient vaguement réseau, et la santé Ceph hurlait qu’un moniteur était hors quorum. L’équipe a suivi le playbook standard : redémarrer, réinitialiser, même déplacer le répertoire de données du moniteur. Toujours hors quorum.

L’optimisation qui a fait boomerang était subtile : les règles de pare-feu autorisaient les connexions établies mais manquaient d’autorisations explicites pour les ports des moniteurs sur le réseau Ceph. En état stable, tout fonctionnait parce que les sessions étaient déjà ouvertes. Après un reboot, le moniteur devait établir de nouvelles connexions. Il n’a pas pu. Le quorum n’a pas chuté instantanément ; il est tombé quand l’« optimisation » a rencontré un changement d’état réel.

La correction finale a été simple : des règles de pare-feu explicites et auditées autorisant le trafic MON-à-MON sur les interfaces correctes, plus une exigence de revue de changement : « Si vous touchez au pare-feu, validez les ports Ceph entre moniteurs ». Ils ont conservé la posture de sécurité, mais sans compter sur la persistance chanceuse des connexions.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Cette équipe a fait quelque chose de profondément pas héroïque : elle a gardé un petit fichier « facts du cluster » dans leur repo interne. Il listait le FSID Ceph, les IDs des moniteurs, les IPs des moniteurs, les réseaux public/cluster prévus, et l’emplacement des répertoires de données des moniteurs. Il indiquait aussi l’apparence normale de ceph -s et quel hôte est habituellement le manager actif.

Quand un hôte moniteur a subi une défaillance de stockage et un reboot en boucle, l’astreinte n’a pas eu à deviner quels moniteurs existaient ou quelles IP ils devaient avoir. Ils ont vérifié le quorum, confirmé l’identité du moniteur mort, et ont su immédiatement qu’ils avaient encore la majorité. Pas de drame. Ils l’ont traité comme le remplacement d’un membre RAID défaillant : isoler, remplacer, réintroduire.

Le gain secondaire : pendant le remplacement, ils ont évité l’erreur humaine la plus courante — réutiliser accidentellement un ancien ceph.conf d’un autre environnement. Leur fichier « facts du cluster » incluait le FSID. Ils l’ont vérifié avant de commencer. Il correspondait. Ils ont continué.

Ce n’était pas héroïque. C’était ennuyeux. Et ça les a protégés d’une panne où tout le monde apprend la CLI Ceph en lisant des logs comme des feuilles de thé.

FAQ

1) Quel est le nombre minimum de moniteurs que je devrais exécuter ?

Trois. Toujours trois pour des clusters réels. Un est un labo. Deux est un mauvais compromis : vous ne pouvez pas tolérer une défaillance sans perdre le quorum.

2) Pourquoi Ceph insiste-t-il sur un nombre impair de moniteurs ?

À cause du consensus majoritaire. Avec 3, vous pouvez perdre 1. Avec 5, vous pouvez perdre 2. Avec 4, vous pouvez toujours seulement perdre 1, donc vous avez payé une complexité supplémentaire sans plus de tolérance de panne.

3) Puis-je exécuter des moniteurs sur les mêmes nœuds que des OSD ?

Oui, c’est courant. Mais gardez le stockage des moniteurs prévisible : évitez de remplir les disques root, évitez les voisins bruyants, et ne placez pas les stores MON sur des SSD consommateur peu fiables puis ne soyez pas surpris.

4) « ceph -s » bloque. Est-ce que cela signifie automatiquement pas de quorum ?

Pas automatiquement, mais c’est un indice fort. Cela peut aussi signifier que votre nœud ne peut atteindre aucun moniteur à cause d’un pare-feu/DNS/routage. Testez les TCP 3300/6789 vers chaque IP de moniteur depuis le nœud où ça bloque.

5) Est-il sûr de supprimer un répertoire de données d’un moniteur pour le « réinitialiser » ?

Seulement lorsque vous avez le quorum et que vous reconstruisez délibérément ce moniteur précis. Même dans ce cas, déplacez-le d’abord. Supprimer le mauvais store pendant un événement sans quorum est la façon de se fabriquer une panne plus longue.

6) Comment savoir s’il s’agit d’une dérive d’heure plutôt que d’un problème réseau ?

La dérive d’heure produit un chaos particulier : élections intermittentes, « out of quorum » avec une connectivité par ailleurs correcte, et des logs qui se plaignent de timeouts de façon aléatoire. Vérifiez timedatectl sur les MON et corrigez NTP/chrony d’abord. Les problèmes réseau se manifestent clairement par des checks de ports échoués et des problèmes de reachabilité constants.

7) Proxmox change-t-il la façon dont la récupération des moniteurs Ceph fonctionne ?

Les fondamentaux sont les mêmes. Proxmox vous donne des outils pratiques et stocke la config Ceph dans /etc/pve, ce qui est utile jusqu’à ce que vous utilisiez accidentellement un /etc/ceph local obsolète. Votre récupération dépend toujours du quorum, du réseau, de l’heure et d’un monmap correct.

8) Sur quoi dois-je alerter pour éviter des incidents de quorum des moniteurs ?

Utilisation disque sur les hôtes moniteurs (surtout root), état de synchronisation de l’heure, perte/latence de paquets entre moniteurs, et l’état du service ceph-mon@*. Alertez aussi sur « mon down » et « quorum changed » ; ce sont des signaux précoces.

9) Si j’ai perdu deux moniteurs dans un cluster à 3 moniteurs, puis-je « forcer » le quorum avec un seul ?

Parfois on peut contraindre un cluster en modes d’urgence selon la version et l’outillage, mais c’est dangereux et dépend du contexte. Opérationnellement : restaurez un second moniteur à la place. Le consensus majoritaire existe pour vous empêcher de vous engager sur une vérité erronée.

10) Pourquoi le disque plein casse-t-il autant les moniteurs ?

Parce que les moniteurs doivent persister les mises à jour d’état pour être autoritaires. S’ils ne peuvent pas écrire, ils ne peuvent pas participer en toute sécurité. Ce n’est pas que Ceph est fragile ; c’est Ceph qui refuse de mentir.

Conclusion et prochaines étapes

« mon down/out of quorum » ressemble à une catastrophe spécifique à Ceph, mais la plupart des récupérations sont du travail plateforme : corriger la pression disque, corriger l’heure, réparer la connectivité réseau, puis laisser les moniteurs faire leur travail. Si le quorum existe, vous réparez ou reconstruisez un moniteur depuis la majorité saine. Si le quorum n’existe pas, arrêtez d’improviser et concentrez-vous sur la restauration d’une majorité en utilisant les stores de moniteur les plus intacts.

Prochaines étapes qui rapportent :

• Mettez les hôtes moniteurs sur un stockage ennuyeux et fiable et empêchez les root filesystems de se remplir.
• Standardisez et auditez les règles de pare-feu pour les ports MON sur le réseau Ceph.
• Rendez la synchronisation temporelle non négociable : alertez quand un moniteur n’est pas synchronisé.
• Écrivez vos facts du cluster (FSID, IDs de moniteurs, IPs, réseaux). Ce n’est pas glamour. C’est efficace.