Proxmox Ceph HEALTH_WARN : par où commencer le dépannage en toute sécurité

octobre 17, 2025 • février 3, 2026 • Lecture : 31 min • Views: 8

Cet article vous a aidé ?

Vous lancez Proxmox, vous voyez une bannière jaune, et votre cerveau fait exactement la même chose que votre cluster : il commence à s’inquiéter. Le message est « Ceph HEALTH_WARN ». Cela peut être un simple ménage sans conséquence. Cela peut être le premier signe avant une pneumonie.

Le piège est de réagir vite dans la mauvaise direction. Ce guide porte sur des actions sûres : les vérifications qui n’aggraveront pas la situation, les commandes qui disent la vérité, et les décisions que vous pourrez défendre dans un post-mortem.

Ce que signifie réellement HEALTH_WARN (et ce que ce n’est pas)

Ceph health a trois états généraux : HEALTH_OK, HEALTH_WARN, HEALTH_ERR. HEALTH_WARN est le cluster qui vous dit : « Quelque chose n’est pas idéal, mais je fonctionne encore. »

Cela ne veut pas dire « ignorez-le ». Cela ne veut pas non plus dire « paniquez et redémarrez les daemons ». HEALTH_WARN est un seau. Le contenu utile est la liste des avertissements en dessous : nearfull, OSD down, PGs degraded, slow ops, clock skew, mon quorum issues, scrub errors, et une douzaine d’autres façons dont le stockage demande poliment de l’aide.

Deux principes directeurs :

Ceph est une machine à états distribuée. La plupart des « correctifs » visent à le laisser converger (ou à l’aider à converger en toute sécurité).
Vos premiers gestes les plus sûrs sont en lecture seule. Observer, mesurer, puis changer.

Interprétation utile sur le plan opérationnel :

HEALTH_WARN avec I/O stable et sans risque d’indisponibilité des données : planifiez une maintenance, réduisez les risques, n’agitez pas le cluster.
HEALTH_WARN avec impact client (latence, timeouts, VMs bloquées) : considérez-le comme un incident et identifiez rapidement le goulot d’étranglement.
HEALTH_WARN avec PGs « misplaced », « degraded » ou « undersized » : vous êtes à une panne supplémentaire d’un mauvais jour. Priorisez la récupération de la redondance.

Fait terre-à-terre : Ceph, c’est comme un projet de groupe — si vous ne vérifiez pas ce que chacun fait, vous déboguerez des « problèmes de communication » à 2h du matin.

Playbook de diagnostic rapide (première/seconde/troisième étape)

Premier : confirmer ce qui est réellement en panne (commande unique, un écran)

Votre première tâche est de traduire le « jaune » en un ou deux modes de panne spécifiques.

cr0x@server:~$ ceph -s
  cluster:
    id:     7c2f0b7c-9c55-4e2e-8b3f-8c3c7c1d8a2a
    health: HEALTH_WARN
            1 osds down
            2 nearfull osd(s)
            36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops.

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 2h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 12 osds: 11 up, 12 in

  data:
    pools:   2 pools, 256 pgs
    objects: 2.1M objects, 8.2 TiB
    usage:   24 TiB used, 36 TiB / 60 TiB avail
    pgs:     240 active+clean
             12  active+undersized+degraded

Signification : Ce n’est pas un seul problème ; c’est un cluster sous pression. Un OSD est down, quelques-uns sont nearfull (ce qui bride), et il y a des slow ops (douleur visible côté client). Les PGs sont undersized/degraded (risque).

Décision : Traitez cela comme un incident. Concentrez-vous d’abord sur le risque de disponibilité (OSD down → PGs dégradés), puis sur la performance (slow ops), tout en commençant immédiatement à planifier l’atténuation du nearfull.

Second : déterminer si le problème est « control plane » ou « data plane »

Problèmes du plan de contrôle : quorum des mons qui flanche, mgr mort, dérive d’horloge. Problèmes du plan de données : OSDs down, erreurs disque, perte réseau, slow ops, backfill storms.

Si le quorum des mons est instable, ne lancez pas la « réparation » des PGs. Réparez d’abord le quorum.
Si des OSDs sont down, ne poursuivez pas les optimisations de performance. Restaurez les OSDs et la redondance.
Si tous les daemons sont up mais que les slow ops persistent, recherchez latence réseau/disque et paramètres de recovery.

Troisième : identifier le type de goulot en 10 minutes

La plupart des incidents réels avec HEALTH_WARN se résument à l’un des cas suivants :

Pression de capacité (nearfull/full, backfill bloqué, écritures throttlées).
Panne sur un seul nœud (OSD down, hôte redémarré, disque mort, réinitialisation HBA).
Problème réseau (perte de paquets, MTU incorrect, switch congestionné, routage asymétrique).
Tempête de recovery (backfill/rebalance en compétition avec I/O client).
Stockage lent (un OSD ou périphérique ralentit tout le monde).
Problèmes d’horloge (avertissements mon, anomalies d’authentification, flapping étrange).

Règles de sécurité : quoi éviter quand le cluster est jaune

Ceph récompense le calme. Il punit l’improvisation.

1) Ne redémarrez pas les daemons « pour effacer l’avertissement »

Redémarrer mons/mgrs/osds change l’état, déclenche du peering, peut relancer la recovery, et peut vous faire perdre la seule chose que vous aviez : un cluster stable qui se réparait lentement. Ne redémarrez que lorsque vous savez ce que vous corrigez (processus bloqué, boucle de crash confirmée, reset du kernel, etc.).

2) Ne marquez pas des OSDs out à moins d’en avoir l’intention

ceph osd out déclenche le mouvement de données. Sur un cluster chargé, cela peut transformer « un OSD down » en « tout le cluster lent pendant des heures ». Si l’OSD est down à cause d’un problème d’hôte transitoire, remettez-le en ligne avant de le déclarer out.

3) Ne « corrigez » pas le nearfull en changeant les ratios de full en plein incident

Oui, vous pouvez augmenter mon_osd_nearfull_ratio et consorts. Ce n’est pas de la capacité. C’est du déni avec des étapes en plus. Si vous devez ajuster les ratios pour débloquer des écritures d’urgence, traitez-le comme une exception temporaire avec un plan de retour arrière.

4) N’exécutez pas de commandes de réparation agressives sans réflexion

ceph pg repair et les outils au niveau OSD peuvent être pertinents, mais ce ne sont pas une première réponse. Prouvez que vous avez des erreurs de scrub ou des PGs inconsistants, et confirmez que le quorum et le réseau sont stables d’abord.

5) N’optimisez pas la recovery tant que vous diagnostiquez

Changer osd_max_backfills ou osd_recovery_max_active peut aider — mais vous pouvez aussi asphyxier l’I/O client ou surcharger un nœud faible. Diagnostiquez d’abord, ajustez ensuite.

Blague #1 : Si vous êtes sur le point de « juste redémarrer le nœud Ceph », souvenez-vous : le cluster a des sentiments, et il les exprime en trafic de backfill.

Faits et contexte intéressants (Ceph et Proxmox)

Ceph a démarré à UC Santa Cruz comme projet de recherche au milieu des années 2000, visant un stockage auto-gérant à grande échelle. Cet ADN se voit encore : il veut se réparer lui-même, parfois bruyamment.
CRUSH n’est pas un système de fichiers ; c’est l’algorithme de placement qui décide où vont les données sans table de lookup centralisée, d’où la capacité de Ceph à monter en charge sans goulot unique de métadonnées pour le placement d’objets.
Les PGs (placement groups) sont des seaux virtuels utilisés pour gérer la réplication et la recovery. Ce ne sont pas des « partitions » ni des « volumes », mais ils contrôlent le rayon d’impact d’une recovery.
HEALTH_WARN est souvent un signal de capacité, pas forcément de panne. Beaucoup de clusters tournent « correctement » jusqu’à atteindre nearfull, puis la performance s’effondre parce que Ceph bride pour se protéger.
Le modèle de scrub de Ceph est de la médecine préventive : les light scrubs et deep scrubs échangent I/O de fond contre détection précoce de corruption. Désactiver les scrubs revient à enlever les détecteurs de fumée parce que vous n’aimez pas le bip.
BlueStore a remplacé FileStore comme backend de stockage par défaut il y a des années, principalement pour réduire la complexité du journal et améliorer la performance, surtout sur SSD/NVMe.
Réseau public et réseau cluster sont des concepts séparés dans la conception de Ceph : mélanger le trafic client et la réplication/backfill sur le même réseau saturé est une histoire classique de « en test ça allait ».
Proxmox intègre Ceph étroitement (outils pveceph, panneaux de santé UI), mais cela ne change pas le comportement fondamental de Ceph : vous dépannez toujours avec les outils Ceph, pas avec l’ambiance du GUI.
Les avertissements de dérive d’horloge existent pour une raison : les mons se basent sur des timeouts et la logique de quorum ; la dérive temporelle peut ressembler à des pannes et mener à du flapping.

Une citation à garder sur un post-it, parce que c’est comme il faut dépanner les systèmes distribués : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan.

Tâches pratiques : commandes, signification, décision

Ces tâches sont ordonnées du plus sûr/général vers le plus ciblé. Utilisez-les comme une checklist : exécutez, interprétez, décidez. Si vous ne faites qu’une chose de cet article, faites la partie « signification + décision » à chaque fois. C’est ce qui vous empêche d’errer et de provoquer une indisponibilité.

Task 1: Snapshot des détails de santé du cluster

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 osds down; 2 nearfull osd(s); 36 slow ops
[WRN] OSD_DOWN: 1 osds down
    osd.7 down since 2025-12-26T09:01:33.123+0000, last_up 2025-12-26T08:42:10.991+0000
[WRN] OSD_NEARFULL: 2 nearfull osd(s)
    osd.3 is near full at 84%
    osd.9 is near full at 85%
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

Signification : C’est la liste exploitable. Elle vous dit ce que Ceph pense être en panne, avec des IDs et des timestamps.

Décision : Ouvrez une note d’incident. Collez cette sortie. Vous en aurez besoin pour savoir si les choses s’améliorent après vos changements.

Task 2: Vérifier le quorum des monitors et la stabilité du plan de contrôle

cr0x@server:~$ ceph quorum_status --format json-pretty
{
  "election_epoch": 42,
  "quorum": [0,1,2],
  "quorum_names": ["pve1","pve2","pve3"],
  "quorum_leader_name": "pve1",
  "monmap": {
    "mons": [
      {"rank":0,"name":"pve1","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.11:3300"},{"type":"v1","addr":"10.10.0.11:6789"}]}},
      {"rank":1,"name":"pve2","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.12:3300"},{"type":"v1","addr":"10.10.0.12:6789"}]}},
      {"rank":2,"name":"pve3","public_addrs":{"addrvec":[{"type":"v2","addr":"10.10.0.13:3300"},{"type":"v1","addr":"10.10.0.13:6789"}]}}
    ]
  }
}

Signification : Le quorum est sain lorsqu’il est stable et contient la majorité des mons. Si le quorum manque un mon ou oscille, tout le reste devient ambigu.

Décision : Si le quorum est instable : arrêtez-vous et réparez le réseau/temps/santé des hosts mon d’abord. Ne touchez pas à l’état des OSDs ni à la réparation des PG tant que le quorum n’est pas redevenu ennuyeux (stable).

Task 3: Confirmer que le manager est actif et non bloqué

cr0x@server:~$ ceph mgr stat
{
  "active_name": "pve1",
  "num_standbys": 1
}

Signification : MGR fournit des dashboards et une logique d’orchestration (selon les modules). S’il est down, vous perdez en visibilité et certaines automatisations.

Décision : Si aucun mgr actif : restaurez-le, mais ne supposez pas que les problèmes de mgr causent des problèmes d’I/O. C’est généralement de l’observabilité, pas le chemin de données.

Task 4: Identifier quels PGs sont unhealthy et pourquoi

cr0x@server:~$ ceph pg stat
256 pgs: 240 active+clean, 12 active+undersized+degraded, 4 active+peering
data: 8.2 TiB objects, 24 TiB used, 36 TiB / 60 TiB avail
io: 120 MiB/s rd, 45 MiB/s wr, 410 op/s rd, 190 op/s wr

Signification : undersized+degraded signifie que les exigences de réplication ne sont pas remplies. peering signifie que les PGs négocient qui possède quoi ; cela peut être normal brièvement, ou être le signe d’un problème plus profond s’il persiste.

Décision : Si degraded/undersized persiste plus de quelques minutes, trouvez les OSDs manquants et restaurez-les. Si le peering persiste, suspectez une partition réseau ou des flaps d’OSD.

Task 5: Trouver rapidement l’OSD down et son hôte

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         5.45600  root default
-3         1.81900      host pve1
 0    hdd  0.45500          osd.0      up   1.00000  1.00000
 3    hdd  0.45500          osd.3      up   1.00000  1.00000
 7    hdd  0.45500          osd.7    down   1.00000  1.00000
-5         1.81900      host pve2
 1    hdd  0.45500          osd.1      up   1.00000  1.00000
 4    hdd  0.45500          osd.4      up   1.00000  1.00000
 9    hdd  0.45500          osd.9      up   1.00000  1.00000
-7         1.81800      host pve3
 2    hdd  0.45500          osd.2      up   1.00000  1.00000
 5    hdd  0.45500          osd.5      up   1.00000  1.00000
12    hdd  0.45500          osd.12     up   1.00000  1.00000

Signification : Cela vous donne le rayon d’impact physique : quel nœud contient l’OSD down.

Décision : Si c’est un problème d’hôte (plusieurs OSDs down sur un même host), traitez-le comme un incident de nœud (alimentation, kernel, NIC, HBA). Si c’est un seul OSD, c’est probablement un disque ou un chemin HBA défaillant.

Task 6: Vérifier si l’OSD down est réellement « down » ou juste « out »/arrêté

cr0x@server:~$ ceph osd dump | grep -E '^osd\.7|^epoch'
epoch 12872
osd.7 up 0 in 1 weight 0.455 last_clean_begin 2025-12-26T08:40:15.000000+0000 last_clean_end 2025-12-26T08:40:15.000000+0000

Signification : L’OSD est marqué up 0 (down) mais est encore in 1. Ceph s’attend à ce qu’il fasse partie du cluster, mais il ne répond pas.

Décision : Préférez restaurer le daemon/chemin disque pour qu’il redevienne up. Évitez de le marquer out sauf si vous attendez une longue indisponibilité ou un remplacement matériel.

Task 7: Sur l’hôte concerné, vérifier le service OSD et les logs récents

cr0x@server:~$ systemctl status ceph-osd@7 --no-pager
● ceph-osd@7.service - Ceph object storage daemon osd.7
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:02:01 UTC; 3min ago
    Process: 19444 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph (code=exited, status=1/FAILURE)
   Main PID: 19444 (code=exited, status=1/FAILURE)

cr0x@server:~$ journalctl -u ceph-osd@7 -n 80 --no-pager
Dec 26 09:01:58 pve1 ceph-osd[19444]: bluestore(/var/lib/ceph/osd/ceph-7) _mount failed: (5) Input/output error
Dec 26 09:01:58 pve1 ceph-osd[19444]: failed to mount object store
Dec 26 09:02:01 pve1 systemd[1]: ceph-osd@7.service: Main process exited, code=exited, status=1/FAILURE

Signification : Ce n’est pas un problème de « logique » Ceph ; c’est une erreur I/O lors du montage de BlueStore. Pensez disque, contrôleur, câblage, kernel.

Décision : Arrêtez les suppositions et vérifiez les logs matériel et kernel ensuite. Si le disque est en panne, planifiez un workflow de remplacement d’OSD plutôt que des redémarrages répétés.

Task 8: Vérifier les messages kernel pour reset/timeout disque sur ce nœud

cr0x@server:~$ dmesg -T | tail -n 40
[Fri Dec 26 09:01:41 2025] sd 6:0:2:0: [sdc] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Fri Dec 26 09:01:41 2025] blk_update_request: I/O error, dev sdc, sector 918274048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 09:01:43 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Fri Dec 26 09:01:43 2025] ata7.00: failed command: READ DMA
[Fri Dec 26 09:01:44 2025] ata7: hard resetting link

Signification : Le kernel voit de vraies erreurs I/O / resets. Ceph ne peut pas outrepasser la physique.

Décision : Remplacez le disque ou réparez le chemin (HBA, câble, backplane). Si vous ne pouvez pas le faire immédiatement, marquez l’OSD out et commencez une recovery contrôlée (après avoir évalué la capacité du cluster et la marge de performance).

Task 9: Identifier les coupables des « slow ops » et si c’est un ou plusieurs OSDs

cr0x@server:~$ ceph health detail | sed -n '/SLOW_OPS/,$p'
[WRN] SLOW_OPS: 36 slow ops, oldest one blocked for 94 sec, daemons [osd.12] have slow ops

cr0x@server:~$ ceph daemon osd.12 dump_historic_ops | head -n 25
{
  "ops": [
    {
      "description": "osd_op(client.48219:9123 3.2f3a 3:1f9d9b4f:::rbd_data.1a2b...:head [write 0~4194304] ...)",
      "duration": 92.334,
      "initiated_at": "2025-12-26T09:00:11.112233Z",
      "type_data": { "op_type": "write" }
    }
  ]
}

Signification : Ceph vous indique quel daemon bloque les opérations. Si c’est un OSD unique de façon persistante, suspectez ce disque ou son hôte (latence, mise en file, NIC).

Décision : Si un OSD est le point chaud, inspectez ses métriques disque et node-level. Si les slow ops sont répartis sur plusieurs OSDs, suspectez une congestion réseau ou une tempête de recovery.

Task 10: Vérifier la pression de recovery/backfill (le tueur silencieux de performance)

cr0x@server:~$ ceph -s | sed -n '/recovery/,$p'
  progress:
    Global Recovery Event (1m)
      [==========..........] (remaining: 2m)
      recovering, 1.2 GiB/s, 18 objects/s

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    5                   8
1    6                   9
2    5                   8
3    7                   11
4    6                   9
5    5                   8
9    8                   14
12   60                  95

Signification : Une recovery est en cours et un OSD (12) a une latence bien pire. Cet OSD peut devenir l’ancre qui ralentit à la fois la recovery et l’I/O client.

Décision : Si la recovery est en concurrence avec l’I/O de production, limitez la recovery avec précaution. Si un OSD est instable, corrigez-le ou isolez-le avant d’augmenter la vitesse de recovery.

Task 11: Confirmer que le nearfull est réel et trouver les OSDs responsables

cr0x@server:~$ ceph df detail | head -n 40
RAW STORAGE:
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
hdd    60 TiB   36 TiB   24 TiB     24 TiB      40.0
POOLS:
POOL     ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd      1   224  7.8 TiB 2.0M     23 TiB   62.5   11 TiB
cephfs   2   32   0.4 TiB 0.1M     1.1 TiB  18.0   11 TiB

cr0x@server:~$ ceph osd df | sort -k8 -n | tail -n 6
ID CLASS WEIGHT  REWEIGHT SIZE   RAW USE DATA   OMAP META AVAIL %USE VAR  PGS STATUS
3  hdd   0.45500 1.00000  5.5T   4.6T    4.5T   0B  4.0G 0.9T 84.1 1.20 24  up
9  hdd   0.45500 1.00000  5.5T   4.7T    4.6T   0B  4.1G 0.8T 85.2 1.21 26  up

Signification : Nearfull est par-OSD, pas moyenne-cluster. Deux OSDs sont à la limite, probablement à cause d’un déséquilibre CRUSH, d’un mismatch de taille de périphérique, ou d’un ancien out/in ayant causé un placement inégal.

Décision : Si quelques OSDs sont nearfull, n’ajoutez pas de capacité « n’importe où ». Corrigez le déséquilibre (reweight/balancer), ou remplacez des disques plus petits, ou redistribuez avec prudence. Planifiez aussi immédiatement de la marge libre : supprimez/déplacez des données si vous êtes proche du full.

Task 12: Vérifier si le balancer est activé et s’il aide ou gêne

cr0x@server:~$ ceph balancer status
{
  "active": true,
  "mode": "upmap",
  "optimize_result": "no_optimization_needed",
  "last_optimize_duration": "0.000000s"
}

Signification : Le mode upmap peut lisser la distribution sans gros mouvements de données, mais il change quand même les mappings. S’il est désactivé, vous pouvez avoir un déséquilibre à long terme. S’il est activé mais bloqué, vous pouvez avoir des contraintes (nearfull, règles CRUSH mal configurées).

Décision : Si le nearfull est localisé et que le balancer n’avance pas, enquêtez sur CRUSH, les classes de dispositifs, et les poids des OSDs. Évitez de forcer un rebalance agressif pendant la charge maximale.

Task 13: Vérifier la synchronisation temporelle et chercher des avertissements de dérive d’horloge

cr0x@server:~$ ceph health detail | grep -i skew
[WRN] MON_CLOCK_SKEW: clock skew detected on mon.pve2, mon.pve3

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

Signification : Les avertissements de dérive peuvent être causés par un vrai décalage, des VMs suspendues, ou des nœuds surchargés retardant NTP. En pratique, c’est souvent « le nœud est trop occupé pour garder le temps correctement ».

Décision : Si NTP n’est pas synchronisé, corrigez le temps d’abord. Si NTP est OK mais que la dérive persiste, regardez la saturation CPU ou les pauses VM sur les hosts mon.

Task 14: Vérifier les erreurs réseau et paquets perdus sur les interfaces Ceph

cr0x@server:~$ ip -s link show dev eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9123491234  12349123   0     412     0     10123
    TX:  bytes packets errors dropped carrier collsns
    8234123412  11234123   0      95      0     0     0

Signification : Les drops sur le réseau de stockage corrèlent fortement avec slow ops, retards de peering et flaps d’OSD. Les mismatches MTU peuvent ressembler à une perte aléatoire.

Décision : Si les drops/erreurs sont non nuls et augmentent, considérez le réseau comme suspect. Confirmez l’MTU de bout en bout et vérifiez les ports de switch. Ne touchez pas au tuning Ceph pour « réparer » un problème de perte de paquets.

Task 15: Vérifier les flags du cluster qui pourraient bloquer la recovery

cr0x@server:~$ ceph osd dump | grep flags
flags noout,noscrub,nodeep-scrub

Signification : Des flags comme noout peuvent être intentionnels pendant une maintenance, mais ils peuvent aussi garder le cluster dégradé plus longtemps que prévu. noscrub peut masquer des signaux de corruption.

Décision : Si des flags ont été placés pour maintenance et oubliés, retirez-les délibérément quand c’est sûr. Si vous êtes en incident, ne retirez pas les flags sans comprendre pourquoi ils ont été mis.

Task 16: Inspecter un PG spécifique bloqué ou dégradé

cr0x@server:~$ ceph pg dump_stuck inactive | head
PG_STAT STATE             UP            UP_PRIMARY  ACTING        ACTING_PRIMARY
1.2a     inactive         [7,3,12]      7           [7,3,12]      7

cr0x@server:~$ ceph pg 1.2a query | head -n 35
{
  "state": "active+undersized+degraded",
  "up": [7,3,12],
  "acting": [7,3,12],
  "info": {
    "stats": {
      "state": "active+undersized+degraded"
    }
  },
  "recovery_state": [
    {
      "name": "Started/Primary/Active",
      "enter_time": "2025-12-26T09:01:40.000000Z"
    }
  ]
}

Signification : L’acting set du PG inclut l’OSD 7, qui est down. C’est pourquoi le PG ne peut pas atteindre size/min_size.

Décision : Réparez l’OSD 7 ou remplacez-le. Ne perdez pas de temps sur la réparation de PG quand la réplique manquante est la cause réelle.

Task 17: Si vous devez throttler la recovery, faites-le avec intention (et revenez en arrière ensuite)

cr0x@server:~$ ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1'
injected data to osd.0
injected data to osd.1
injected data to osd.2
injected data to osd.3
injected data to osd.4
injected data to osd.5
injected data to osd.9
injected data to osd.12

Signification : Vous avez réduit la concurrence de recovery sur tous les OSDs. Cela peut stabiliser la latence client au prix d’un healing plus lent.

Décision : N’utilisez ceci que lorsque l’impact client est sévère et que vous avez besoin que le cluster redevienne réactif. Créez un rappel pour revenir en arrière à la fin de l’incident, sinon vous serez « mystérieusement lent à récupérer » pour toujours.

Task 18: Vérifier que la réplication/min_size du pool n’est pas suicidaire

cr0x@server:~$ ceph osd pool ls detail | sed -n '1,80p'
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 224 pgp_num 224 autoscale_mode on
pool 2 'cephfs' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on

Signification : Size 3 / min_size 2 est typique. Si min_size est 3, un seul OSD down peut bloquer les écritures. Si size est 2 dans un petit cluster, votre tolérance aux défaillances est plus faible que vous ne le pensez.

Décision : Si les écritures sont bloquées parce que min_size est trop strict par rapport aux risques acceptés, ajustez-le lors d’un changement planifié, pas en plein chaos — sauf si l’impact métier l’impose et que vous le documentez.

Trois mini-récits d’entreprise depuis le terrain

1) Incident causé par une mauvaise hypothèse : « Jaune veut dire sans risque »

Une société SaaS de taille moyenne utilisait Proxmox avec Ceph pour le stockage VM. Ils avaient vu HEALTH_WARN de nombreuses fois — généralement un avertissement de scrub, un OSD nearfull qui disparaissait après un nettoyage, ou un flap d’OSD transitoire pendant des mises à jour kernel. L’habitude en on-call était de lancer ceph -s, hausser les épaules et passer à autre chose sauf si l’UI devenait rouge.

Un vendredi, HEALTH_WARN indiquait un OSD down et quelques PGs dégradés. L’hypothèse fut « la réplication couvre ». Ce n’est pas faux en principe ; c’est faux sur le timing. Le cluster tournait déjà à la limite : forte charge d’écriture, recovery throttlée trop prudemment d’un incident précédent, et un nœud avait des disques légèrement moins bons que les autres.

Pendant le week-end, un second disque sur le même hôte a commencé à générer des pics de latence. L’OSD n’est pas tombé complètement, il est juste devenu assez lent pour déclencher des slow ops. Les clients ont commencé à faire des timeouts. Le stockage était techniquement disponible, mais la performance est devenue une panne. Le métier l’a considéré comme « la plateforme est en panne » car les VMs qui ne peuvent pas écrire ne survivent pas.

Le post-mortem avait une phrase qui comptait : ils avaient traité la perte de redondance comme cosmétique. Les PGs dégradés ne sont pas un ornement ; c’est une horloge qui compte à rebours et qui accélère quand vous êtes déjà stressé.

Ce qui l’a réparé n’était pas héroïque. Ils ont restauré l’OSD down, remplacé le disque défaillant, et — surtout — ajouté une règle : les PGs degraded/undersized déclenchent un incident indépendamment de la couleur. La couleur de l’UI n’est pas votre modèle de risque.

2) Optimisation qui s’est retournée contre eux : « Accélérons la recovery »

Une autre organisation avait des reboots fréquents de nœuds à cause de mises à jour firmware. Ils en avaient marre des temps de recovery longs et ont décidé de « tuner Ceph ». Quelqu’un a augmenté osd_max_backfills et osd_recovery_max_active sur tout le cluster pour que le backfill aille plus vite.

Ça a marché — sur un cluster de staging vide. En production, le même changement transforme chaque reboot en une coupure partielle. La recovery est entrée en compétition avec les écritures et lectures client, saturant les disques et le réseau de stockage. Les pics de latence ont déclenché plus de slow ops. Les slow ops ont provoqué des timeouts. Les timeouts ont généré des retries applicatifs. Les retries ont amplifié la charge. Le tout est devenu un DDoS auto-infligé, mais avec plus de YAML.

Le plus douloureux : les ingénieurs ont interprété les symptômes comme « Ceph est instable après les reboots », alors ils ont redémarré les nœuds encore pour « le remettre en ordre », relançant la recovery à chaque fois. C’est comme ça qu’on transforme un réglage en générateur d’incidents.

La solution : lier le tuning de recovery à l’heure et à la latence observée. Ils ont créé deux profils : conservateur en heures ouvrables, agressif la nuit. Ils ont aussi appris à regarder ceph osd perf et les drops réseau avant de changer quoi que ce soit. La vitesse de recovery n’est pas un plat gratuit ; c’est un échange avec vos utilisateurs.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : « Noout pendant la maintenance, puis le retirer »

Une entreprise réglementée (beaucoup de processus, beaucoup de papier, beaucoup d’avis) a planifié une fenêtre de maintenance pour remplacer un disque défaillant dans un nœud Ceph. Ils ont fait la danse ennuyeuse : mis noout avant de prendre l’hôte hors ligne, enregistré l’heure de début, et assigné une personne responsable de retirer le flag à la fin.

Pendant la fenêtre, un autre nœud a connu un bref problème réseau et a perdu un OSD. Dans beaucoup d’environnements, c’est là que le cluster commence à remanier les données et la maintenance se transforme en une nuit entière de backfill. Mais avec noout, Ceph n’a pas immédiatement décidé que l’OSD temporairement manquant était perdu pour toujours, donc il n’a pas lancé le mouvement massif de données alors qu’ils opéraient déjà avec une capacité réduite.

Ils ont restauré le réseau, remis l’hôte de maintenance en ligne, puis supprimé noout délibérément. Le cluster s’est réparé avec un minimum de drame. Le métier n’a rien remarqué.

Ce n’était pas une ingénierie brillante. C’était de l’hygiène opérationnelle : savoir quels flags existent, quand les utiliser, et — crucial — comment sortir proprement de la maintenance. L’outil le plus précieux de l’équipe ce jour-là fut une checklist.

Blague #2 : La maintenance Ceph sans checklist, c’est comme hot-swapper un disque les yeux fermés — techniquement possible, émotionnellement coûteux.

Erreurs courantes : symptôme → cause profonde → correctif

1) Symptom : « HEALTH_WARN nearfull » et la performance devient étrange

Cause profonde : Un ou quelques OSDs sont nearfull, ce qui pousse Ceph à throttler/se reculer, et la recovery peut être bloquée ou ralentie par les ratios full.

Correctif : Identifiez les OSDs avec le top %use (ceph osd df). Réduisez immédiatement la croissance des données (supprimez/déplacez snapshots/VMs), ajoutez de la capacité, et corrigez le déséquilibre (balancer/weights CRUSH). Évitez les « hacks de ratio » sauf si vous avez besoin d’une fenêtre d’écriture d’urgence temporaire.

2) Symptom : « 1 osds down » mais vous le marquez out immédiatement et le cluster devient lent

Cause profonde : Le marquage out a déclenché un grand rebalance sur des disques/réseau déjà occupés.

Correctif : Si l’OSD peut revenir rapidement, remettez-le en ligne au lieu de le marquer out. Si vous devez marquer out, throttlez la recovery et planifiez le mouvement lorsque la charge client est faible.

3) Symptom : PGs bloqués en « peering » pendant longtemps

Cause profonde : Flapping d’OSD, perte de paquets réseau, ou partition causant un échange d’état incohérent.

Correctif : Vérifiez l’historique up/down des OSDs, les drops réseau, la cohérence MTU, et les logs de switch. Stabilisez le réseau d’abord. Redémarrer des OSDs au hasard prolonge souvent le peering.

4) Symptom : Slow ops centrées sur un OSD

Cause profonde : Le disque de cet OSD est lent, son hôte est surchargé, ou il subit des resets au niveau kernel.

Correctif : Utilisez ceph osd perf pour confirmer, puis inspectez dmesg et les logs de service sur l’hôte. Remplacez le périphérique ou réparez le chemin. Ne « tunez » pas Ceph pour compenser un disque mort.

5) Symptom : Slow ops sur plusieurs OSDs, surtout pendant la recovery

Cause profonde : La recovery/backfill sature le réseau ou les disques. Ou le réseau de stockage est perteux/congestionné.

Correctif : Vérifiez la progression de la recovery, la perf des OSDs, et les drops NIC. Throttlez temporairement la recovery si l’impact client est inacceptable. Réparez le réseau si vous constatez des pertes.

6) Symptom : « MON_CLOCK_SKEW » apparaît de façon intermittente

Cause profonde : Mauvaise ou instable synchronisation temporelle, ou hosts surchargés empêchant une bonne tenue du temps.

Correctif : Assurez-vous que NTP/chrony est actif et synchronisé. Etudiez le CPU steal, la charge, et les pauses VM sur les hosts mon. Les avertissements de temps ne sont pas cosmétiques ; ils corrèlent avec des problèmes de quorum.

7) Symptom : Erreurs de scrub ou avertissements d’« inconsistent PG »

Cause profonde : Incohérence de données détectée pendant un scrub, souvent due à des erreurs disque passées, de la bit rot, ou des recoveries interrompues.

Correctif : Confirmez quels PGs sont inconsistants, assurez la stabilité du cluster, puis lancez une réparation ciblée avec prudence. Enquêtez aussi sur le matériel sous-jacent pour des erreurs silencieuses. Si c’est répandu, traitez la qualité de la flotte matérielle comme l’incident réel.

8) Symptom : Tout semble « up » mais les écritures sont bloquées

Cause profonde : min_size du pool trop strict pour les pannes actuelles, ou le cluster atteint des seuils full, ou certains PGs sont bloqués en undersized.

Correctif : Vérifiez les paramètres de pool, examinez les ratios full, restaurez les OSDs manquants. Ajustez min_size seulement comme un compromis de risque conscient, documenté et idéalement planifié.

Listes de contrôle / plan étape par étape

Checklist A : Premières 5 minutes (sans risque, lecture seule)

Exécutez ceph -s et ceph health detail. Collez les sorties dans votre journal d’incident.
Confirmez le quorum : ceph quorum_status. Si instable, arrêtez et réparez cela en priorité.
Regardez l’état des PGs : ceph pg stat. Identifiez les comptes degraded/undersized/peering.
Trouvez les OSDs down évidents : ceph osd tree.
Vérifiez si le nearfull est par-OSD : ceph osd df.

Checklist B : 15 minutes suivantes (localiser le goulot)

Si un OSD est down, mappez-le à un host et vérifiez systemctl status + journalctl pour cet OSD.
Exécutez ceph osd perf. Trouvez les outliers.
Si des slow ops existent, identifiez quels daemons : ceph health detail et utilisez ceph daemon osd.X dump_historic_ops de façon sélective.
Vérifiez les drops réseau sur les interfaces Ceph : ip -s link. Si les drops augmentent, considérez le réseau comme suspect.
Cherchez des flags oubliés : ceph osd dump | grep flags.

Checklist C : Échelle d’intervention sûre (changer le moins possible)

Restaurer ce qui manque : remettez les OSDs en ligne si le matériel le permet ; corrigez les problèmes d’hôte.
Réduire la douleur client : si la recovery écrase la latence, throttlez-la temporairement (et documentez le changement).
Restaurer la redondance : si le matériel est mort, marquez l’OSD out et commencez le remplacement — seulement après avoir confirmé la marge de capacité et la sécurité du domaine de défaillance.
Traiter la capacité : priorisez l’atténuation du nearfull avant qu’il ne devienne full ; ajoutez de l’espace, rééquilibrez prudemment, supprimez des données si nécessaire.
Réparer seulement avec des preuves : les inconsistances détectées par scrub nécessitent une réparation ciblée après restauration de la stabilité.

Checklist D : Durcissement post-incident (ce que vous auriez souhaité avoir fait avant)

Créez des alertes qui se déclenchent sur degraded/undersized PGs, pas seulement sur HEALTH_ERR.
Baselinez la latence commit/apply des OSDs et suivez les outliers.
Suivez la répartition d’utilisation par OSD (VAR) et enquêtez le déséquilibre tôt.
Documentez les profils de tuning de recovery et quand les utiliser.
Standardisez l’MTU du réseau de stockage et validez-le de bout en bout lors des fenêtres de changement.
Faites de la « suppression des flags de maintenance » une étape requise avec un propriétaire nommé.

FAQ

1) Est-ce que HEALTH_WARN est toujours urgent ?

Non. C’est un niveau de gravité, pas un diagnostic. Certains avertissements sont informatifs (comme des crashes de daemons récents déjà récupérés). D’autres sont des indicateurs pré-faille (nearfull, PGs dégradés). Traitez les PGs degraded/undersized et les slow ops comme urgents car ils correspondent à du risque et de la douleur utilisateur.

2) Dois-je redémarrer les services Ceph quand je vois HEALTH_WARN ?

Pas en premier geste. Un redémarrage change l’état du cluster et peut relancer recovery et peering. Redémarrez quand vous avez des preuves : boucle de crash du daemon, processus bloqué, ou correctif confirmé nécessitant un redémarrage.

3) Quelle est la différence entre « OSD down » et « OSD out » ?

Down signifie non réactif. Out signifie que Ceph ne place plus de données là et va déplacer les données ailleurs. Down peut être transitoire ; out est une décision de politique qui déclenche le mouvement de données.

4) Pourquoi nearfull sur quelques OSDs est important quand le cluster a beaucoup d’espace libre ?

Parce que les écritures Ceph sont contraintes par les périphériques les plus pleins. Si deux OSDs sont nearfull, le placement est contraint, le backfill devient plus difficile, et le cluster peut throttler ou refuser les écritures même si l’utilisation moyenne paraît correcte.

5) Quelle est la méthode la plus rapide pour trouver le goulot : réseau, disque ou recovery ?

Exécutez ceph health detail (ce que Ceph signale), ceph osd perf (qui est lent), et ip -s link (le réseau perd-il des paquets). Ces trois commandes indiquent généralement où regarder ensuite.

6) Puis-je modifier en toute sécurité les paramètres de recovery pendant un incident ?

Oui, si vous le faites comme une mitigation temporaire et que vous savez pourquoi vous le faites. Diminuez la concurrence de recovery pour protéger la latence client ; augmentez-la pour réduire le temps d’exposition quand la charge client est faible et le matériel sain. Enregistrez toujours le changement et revenez en arrière ensuite.

7) Que signifient réellement « active+clean », « degraded », « undersized » et « peering » ?

active+clean : entièrement répliqué, sert l’I/O normalement. degraded : une ou plusieurs répliques manquent. undersized : en dessous du seuil min_size et à risque ; peut bloquer les écritures selon les réglages et l’état. peering : les membres du PG négocient l’état ; un peering prolongé suggère de l’instabilité.

8) Quand dois-je marquer un OSD out plutôt qu’essayer de le remettre ?

Remettez-le si le problème est transitoire (reboot d’hôte, service arrêté, court hic réseau). Marquez-le out si le périphérique/chemin est défaillant ou si vous pensez que l’OSD sera indisponible suffisamment longtemps pour augmenter le risque en attendant. Si vous le marquez out, planifiez la charge de récupération.

9) L’interface Proxmox suffit-elle pour dépanner Ceph ?

L’UI convient pour un aperçu rapide. Pour des décisions qui affectent le mouvement des données et la recovery, utilisez les sorties CLI Ceph. La CLI vous montre les types d’avertissements exacts, les timestamps, et les IDs de daemons dont vous avez besoin.

10) Si je vois des erreurs de scrub, dois-je réparer immédiatement ?

D’abord stabilisez le cluster (quorum, réseau, stabilité des OSDs). Ensuite identifiez quels PGs sont inconsistants et réparez-les spécifiquement. Réparer pendant l’instabilité peut être une perte de temps et parfois aggraver le bruit opérationnel.

Conclusion : prochaines étapes que vous pouvez exécuter demain

Quand Proxmox affiche Ceph HEALTH_WARN, ne le traitez pas comme un problème unique et ne vous fiez pas à la couleur. Traitez-le comme une liste. Votre chemin le plus sûr : capturer ceph health detail, confirmer le quorum, identifier les PGs dégradés et les OSDs down, puis prouver si le goulot est un disque, un réseau, ou une tempête de recovery.

Étapes pratiques :

Rédigez une page runbook on-call qui commence par le Playbook de diagnostic rapide et inclut les commandes que vous utilisez réellement.
Ajoutez des alertes sur les PGs degraded/undersized, les OSDs nearfull, et les slow ops, pas seulement sur HEALTH_ERR.
Décidez (au calme, en journée) de votre politique de tuning de recovery pendant les heures ouvrables vs hors horaires.
Auditez votre réseau de stockage : cohérence MTU, drops, et erreurs de ports switch. Ceph amplifie fidèlement ce que fait votre réseau.
Planifiez une marge de capacité. Les avertissements nearfull Ceph sont des alertes précoces ; traitez-les comme telles.

Ceph est fiable quand vous le laissez être prévisible. Votre travail est de garder le système suffisamment stable pour converger — et d’éviter des « correctifs » qui génèrent plus de mouvement que d’information.