Proxmox Ceph : PG bloqués/inactifs — que faire avant que le risque sur les données n’augmente

Modèle mental : ce que signifie réellement « PG bloqué/inactif »

Dans Ceph, les objets vivent dans des Placement Groups (PG). Un PG n’est pas des données en soi ; c’est l’unité de placement et de cohérence. Chaque PG est mappé sur un ensemble d’OSD
via les règles CRUSH. Ceph suit l’état des PG parce que c’est ainsi que le cluster décide : « Puis‑je servir des lectures/écritures en toute sécurité ? » et « Sais‑je qui détient la version la plus récente
de chaque objet ? »

Inactif signifie que le PG ne peut pas actuellement servir d’E/S parce qu’il n’a pas terminé le peering pour atteindre un ensemble acting cohérent (les OSD responsables actuels).
Il peut manquer des OSD, manquer de quorum, ou être bloqué en attente d’historique. Bloqué est une alarme temporelle : le PG est resté dans un état non idéal
(peering, activation, backfilling, undersized, degraded) plus longtemps qu’attendu.

Le piège dangereux est de traiter « inactif » comme un bug unique. Ce n’en est pas un. C’est une classe de symptôme. Parfois la réparation est ennuyeuse (remettre un OSD,
remplacer un disque, restaurer le réseau). Parfois elle est chirurgicale (ajuster les limites de récupération). Parfois elle requiert une décision lourde (réduire temporairement la taille d’un pool,
marquer un OSD out, ou en dernier recours, déclarer des données perdues).

Votre principe d’exploitation sûr : ne changez pas la vision du cluster sur les données tant que vous n’avez pas confirmé pourquoi il ne parvient pas à s’accorder.
Si le PG ne peut pas peerer, c’est généralement parce qu’un participant manque, est incohérent ou trop lent pour répondre. Faites‑le répondre, ou retirez‑le proprement — et seulement après une évaluation claire des impacts.

Blague #1 (court et pertinent) : la récupération Ceph est comme la gestion des bagages d’un aéroport — tout est « éventuellement cohérent » jusqu’à ce que ce soit votre valise qui manque.

États clés des PG que vous verrez dans les clusters Proxmox Ceph

• active+clean : l’état visé.
• active+degraded : les E/S fonctionnent, mais certaines répliques manquent ; la récupération va tenter de réparer.
• active+undersized : l’ensemble acting compte moins d’OSD que la valeur size du pool ; le risque augmente.
• peering / activating : un accord est en cours ; si ça reste là, quelque chose le bloque.
• backfill_wait, backfilling, recovering : mouvement de données ; peut être lent ou bloqué par des throttles/disques pleins.
• stale : le moniteur n’a pas entendu les OSD responsables ; souvent réseau ou hôte indisponible.
• incomplete : Ceph ne trouve pas de données faisant autorité pour le PG ; c’est l’endroit où il faut ralentir et réfléchir.

Ce que « avant que le risque sur les données n’augmente » signifie en pratique

Le risque sur les données augmente quand vous franchissez l’un de ces seuils :

• Plusieurs OSD d’un même domaine de panne (même hôte, même rack, même alimentation) tombent pour des pools en size 3.
• Les PG deviennent incomplete ou inactive pour un pool qui sert des disques de VM et vous continuez d’écrire quand même (ou multipliez les redémarrages forcés).
• Les disques OSD sont proches du plein et vous poursuivez le backfill, provoquant une amplification d’écritures et des échecs d’allocation BlueStore.
• Vous commencez à utiliser des commandes destructrices (ceph pg repair, ceph-objectstore-tool, ceph osd lost) sans preuves.
• Les moniteurs oscillent sur le quorum ; les maps de cluster churnent ; les PG ne parviennent pas à se stabiliser.

Faits et contexte utiles (Ceph et PG)

• Les PG existent pour scaler les métadonnées : Ceph évite des décisions métadonnées par objet en regroupant les objets en PG ; d’où l’importance du nombre de PG pour les performances et la récupération.
• « Peering » est le consensus allégé par PG de Ceph : ce n’est pas Paxos par objet ; c’est un échange d’historique au niveau du PG pour décider du log faisant autorité.
• CRUSH (racines de recherche 2006) : le placement de Ceph repose sur un algorithme déterministe conçu pour éviter des tables de lookup centrales.
• Les flags « nearfull/backfillfull/full » de Ceph sont des garde‑fous : ils existent parce qu’un manque d’espace en pleine récupération peut coincer les PG dans des états déplaisants.
• Le backfill n’est pas « juste copier » : il concurrence les E/S clients, amplifie les écritures et peut exposer des problèmes latents de firmware disque/SSD.
• BlueStore a changé le profil de défaillance : comparé à FileStore, BlueStore a réduit les pénalités de double écriture mais a rendu la santé des périphériques (placement DB/WAL, latence) plus visible.
• Le quorum de mon est une dépendance dure pour les maps : même si les OSD sont « up », l’instabilité des maps peut empêcher les PG de se stabiliser en peering.
• L’autoscaler PG existe parce que les humains sont mauvais en maths de PG : le tuning manuel des PG a causé des incidents évitables pendant des années, surtout après l’ajout d’OSD.
• La planification des scrubs est devenue une discipline d’exploitation : les scrubs détectent des corruptions proches du bitrot, mais des scrubs trop agressifs peuvent ruiner les fenêtres de récupération.

Playbook de diagnostic rapide (vérifications 1/2/3)

Quand des PG sont bloqués/inactifs, vous n’avez pas besoin de plus de dashboards. Vous avez besoin d’un arbre de décision clair.
L’objectif est d’identifier le goulot d’étranglement qui empêche le peering/l’activation, et si vous faites face à une douleur d’availability ou à un risque d’integrity.

Premier : confirmer le périmètre et les états exacts des PG (2 minutes)

• Combien de PG, quels pools et quels états ?
• Est‑ce inactive, stale, incomplete ou juste une récupération lente ?
• Les moniteurs sont‑ils en quorum et stables ?

Deuxième : trouver les participants manquants (5 minutes)

• Quels OSD sont down/out ?
• Sont‑ils down parce que l’hôte est mort, le disque est mort, ou le démon est wedgé ?
• Le réseau est‑il partitionné (heartbeats OSD qui échouent) ?

Troisième : vérifier la capacité et les throttles (5–10 minutes)

• Des OSD sont‑ils nearfull/backfillfull/full ?
• Les réglages de recovery/backfill sont‑ils trop stricts (cluster qui rampe) ou trop permissifs (cluster noyé) ?
• Y a‑t‑il des opérations lentes indiquant un périphérique ou un nœud spécifique ?

Quatrième : décider de la stratégie de récupération (puis agir)

• Si l’OSD est récupérable : ramenez‑le, laissez le peering se terminer, limitez les changements.
• Si le disque OSD est en panne : marquez‑le out, remplacez‑le et rebuild; ne continuez pas à le redémarrer jusqu’à corrompre davantage.
• Si le PG est incomplete : arrêtez d’improviser ; identifiez les OSDs faisant autorité, vérifiez les logs et planifiez. « Forcer » n’est pas une stratégie.

Blague #2 (court et pertinent) : la seule chose plus permanente qu’un tweak temporaire Ceph est le ticket demandant pourquoi il est toujours configuré six mois plus tard.

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

Les commandes ci‑dessous supposent que vous utilisez l’intégration Ceph de Proxmox (donc la CLI ceph est disponible sur un nœud avec keyring admin),
et des services gérés par systemd pour OSD/mon/mgr. Adaptez les noms d’hôtes/IDs à votre environnement.

Tâche 1 : Obtenir le message de santé réel (ne pas deviner)

cr0x@server:~$ ceph -s
  cluster:
    id:     6c2a6d0c-3a7f-4c50-9c90-2d14c5d1f9aa
    health: HEALTH_WARN
            12 pgs inactive
            4 pgs peering
            1 osds down
            37 slow ops, oldest one blocked for 412 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 17m)
    mgr: pve1(active), standbys: pve2
    osd: 24 osds: 23 up (since 3m), 24 in (since 2h)

  data:
    pools:   4 pools, 512 pgs
    objects: 3.1M objects, 12 TiB
    usage:   36 TiB used, 48 TiB / 84 TiB avail
    pgs:     488 active+clean
             12 inactive
             4 peering

Ce que cela signifie : la santé indique déjà s’il s’agit « juste d’une récupération » ou « nous ne pouvons pas servir d’E/S en sécurité ». Les PG inactifs affectent la disponibilité.
Le nombre « osds down » indique un participant manquant ; les « slow ops » signalent un goulot de performance.

Décision : Si des PG sont inactive ou incomplete, priorisez la restauration du peering plutôt que le tuning des performances. Le tuning peut attendre ; la correction ne doit pas.

Tâche 2 : Identifier quels PG sont bloqués et pourquoi Ceph le pense

cr0x@server:~$ ceph health detail
HEALTH_WARN 12 pgs inactive; 4 pgs peering; 1 osds down; 37 slow ops
[WRN] PG_AVAILABILITY: 12 pgs inactive
    pg 1.2f is stuck inactive for 611.243 seconds, current state inactive, last acting [3,7,12]
    pg 2.9a is stuck inactive for 603.991 seconds, current state inactive, last acting [5,9,21]
[WRN] PG_DEGRADED: 4 pgs peering
    pg 1.31 is stuck peering for 503.102 seconds, current state peering, last acting [7,12,18]
[WRN] OSD_DOWN: 1 osds down
    osd.12 is down
[WRN] SLOW_OPS: 37 slow ops, oldest one blocked for 412 sec

Ce que cela signifie : vous avez maintenant des IDs de PG spécifiques et leur dernier acting set. Cet acting set est votre fil d’Ariane.
Si plusieurs PG bloqués partagent un ID OSD, cet OSD est souvent le coupable (ou la victime).

Décision : Pivotez vers les OSD partagés. N’allez pas redémarrer tout et n’importe quoi au hasard.

Tâche 3 : Exporter l’état d’un PG problématique (voir sur qui il attend)

cr0x@server:~$ ceph pg 1.2f query
{
  "state": "inactive",
  "acting": [3,7,12],
  "up": [3,7,12],
  "blocked_by": ["osd.12"],
  "peering_blocked_by": ["osd.12"],
  "info": {
    "last_update": "145'9023",
    "last_complete": "145'9001"
  }
}

Ce que cela signifie : C’est de l’or. Ça vous dit que le PG ne peut pas s’activer parce que osd.12 ne participe pas.
Parfois blocked_by n’apparaît pas ; vous consultez alors les logs de peering et la perf des OSD.

Décision : Concentrez‑vous sur la restauration de osd.12 ou sur son retrait propre (out) si le disque est irrécupérable.

Tâche 4 : Confirmer la topologie et l’état des OSD (up/in/out et mappage hôte)

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         84.00000 root default
-3         28.00000     host pve1
 0   ssd    3.50000         osd.0      up   1.00000  1.00000
 1   ssd    3.50000         osd.1      up   1.00000  1.00000
 2   ssd    3.50000         osd.2      up   1.00000  1.00000
-5         28.00000     host pve2
 3   ssd    3.50000         osd.3      up   1.00000  1.00000
 7   ssd    3.50000         osd.7      up   1.00000  1.00000
12   ssd    3.50000         osd.12    down  1.00000  1.00000
-7         28.00000     host pve3
 5   ssd    3.50000         osd.5      up   1.00000  1.00000
 9   ssd    3.50000         osd.9      up   1.00000  1.00000
21   ssd    3.50000         osd.21     up   1.00000  1.00000

Ce que cela signifie : vous voyez où osd.12 se situe (hôte pve2) et s’il est seulement down ou aussi out.
Dans cet exemple il est down mais toujours in, ce qui bloque certains PG qui en ont besoin pour le peering.

Décision : Allez sur pve2, enquêtez pourquoi l’OSD est down, puis décidez « restart » vs « remplacement ».

Tâche 5 : Vérifier le statut du service OSD et les logs récents sur l’hôte

cr0x@server:~$ ssh pve2 -- systemctl status ceph-osd@12 --no-pager
● ceph-osd@12.service - Ceph object storage daemon osd.12
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 08:14:02 UTC; 2min 11s ago
    Process: 11472 ExecStart=/usr/bin/ceph-osd -f --cluster ceph --id 12 (code=exited, status=1/FAILURE)
   Main PID: 11472 (code=exited, status=1/FAILURE)

Dec 26 08:14:02 pve2 ceph-osd[11472]: bluestore(/var/lib/ceph/osd/ceph-12) _read_bdev_label failed: (5) Input/output error
Dec 26 08:14:02 pve2 ceph-osd[11472]: OSD:init: unable to mount object store
Dec 26 08:14:02 pve2 systemd[1]: ceph-osd@12.service: Failed with result 'exit-code'.

Ce que cela signifie : Ce n’est pas un « Ceph qui fait son cinéma ». C’est une erreur I/O sur le bloc. BlueStore ne peut pas lire son label.
C’est généralement un disque mourant, un chemin de contrôleur cassé, ou un périphérique de remplacement mal câblé.

Décision : Ne vous embourbez pas dans une boucle de redémarrages. Passez aux vérifications de santé du périphérique et à la procédure de remplacement.

Tâche 6 : Vérifier la couche périphérique (SMART, dmesg). Confirmer que c’est bien un problème matériel.

cr0x@server:~$ ssh pve2 -- sudo dmesg -T | tail -n 12
[Fri Dec 26 08:13:51 2025] blk_update_request: I/O error, dev sdd, sector 129024 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 08:13:51 2025] Buffer I/O error on dev sdd1, logical block 16128, async page read
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] Sense Key : Medium Error [current]
[Fri Dec 26 08:13:52 2025] sd 6:0:9:0: [sdd] Add. Sense: Unrecovered read error

Ce que cela signifie : Le kernel confirme des erreurs de lecture non récupérées. Ce n’est pas un problème de réglage.

Décision : Traitez osd.12 comme un hardware défaillant. Marquez‑le out et planifiez son remplacement.

Tâche 7 : Confirmer que les moniteurs sont en quorum et ne basculent pas (les PG ne peuvent pas se stabiliser sans maps)

cr0x@server:~$ ceph quorum_status
{
  "quorum": [0,1,2],
  "quorum_names": ["pve1","pve2","pve3"],
  "quorum_age": 1052,
  "election_epoch": 94
}

Ce que cela signifie : Le quorum est présent et stable (quorum_age ≈ 17 minutes). Bien. Si le quorum basculait, réglez cela en priorité.

Décision : Continuez le remède OSD ; ne poursuivez pas des comportements PG fantômes causés par un churn mon.

Tâche 8 : Vérifier nearfull/backfillfull/full (la capacité peut bloquer la récupération et maintenir les PG bloqués)

cr0x@server:~$ ceph df
--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    84 TiB   48 TiB   36 TiB    36 TiB       42.86
TOTAL  84 TiB   48 TiB   36 TiB    36 TiB       42.86

--- POOLS ---
POOL         ID  PGS  STORED   OBJECTS  USED     %USED  MAX AVAIL
rbd          1   256  9.8 TiB  2.1M     29 TiB   60.42  14 TiB
cephfs_data  2   128  2.0 TiB  0.7M     6.0 TiB  12.50  14 TiB

Ce que cela signifie : L’utilisation brute est correcte. Si vous aviez vu un MAX AVAIL petit pour un pool, ou le raw supérieur à 85 %, vous vous attendriez à des backfills bloqués ou des alertes « nearfull ».

Décision : La capacité n’est pas le blocage ici ; poursuivez le remplacement/retrait d’OSD.

Tâche 9 : Avant de marquer out, voir si le cluster est déjà dégradé/undersized et dans quelle mesure

cr0x@server:~$ ceph osd stat
24 osds: 23 up, 24 in; epoch: e4123

Ce que cela signifie : L’OSD est down mais toujours « in », donc Ceph continue d’essayer de l’utiliser. Cela peut bloquer le peering selon les PG et leur historique.

Décision : Si le disque est mort et ne reviendra pas rapidement, marquez‑le out pour que Ceph remappe et récupère ailleurs.

Tâche 10 : Marquer l’OSD défaillant out (remap contrôlé) et surveiller la récupération

cr0x@server:~$ ceph osd out 12
marked out osd.12.

Ce que cela signifie : Ceph va commencer à remapper les PG qui avaient osd.12 dans leur acting set. Cela déclenche backfill/recovery.

Décision : Si vous manquez de capacité ou si d’autres éléments sont déjà dégradés, envisagez de réduire la charge client ou d’ajuster temporairement les throttles de récupération (prudemment).

Tâche 11 : Vérifier la progression de la récupération et si les PG quittent inactive/peering

cr0x@server:~$ ceph -s
  cluster:
    health: HEALTH_WARN
            0 pgs inactive
            18 pgs degraded
            52 pgs recovering
            19 slow ops, oldest one blocked for 98 sec
  data:
    pgs:     442 active+clean
             52 active+recovering
             18 active+degraded

Ce que cela signifie : Le problème immédiat de disponibilité (PG inactifs) est résolu. Vous êtes maintenant en mode récupération. C’est mieux : les E/S fonctionnent, le risque est réduit, le cluster guérit.

Décision : Maintenez la récupération stable. Ne redémarrez pas les OSD « pour accélérer ». Si les slow ops persistent, identifiez le périphérique ou l’hôte lent.

Tâche 12 : Identifier les responsables des slow ops (souvent un OSD ou un hôte)

cr0x@server:~$ ceph health detail | grep -A3 -i slow
[WRN] SLOW_OPS: 19 slow ops, oldest one blocked for 98 sec
    osd.7 has slow ops
    osd.21 has slow ops

Ce que cela signifie : Vous avez maintenant des OSD candidats à inspecter. Les slow ops pendant la récupération sont courantes, mais des slow ops soutenus peuvent garder le peering/la récupération lents ou bloqués.

Décision : Vérifiez les statistiques de perf des OSD et la latence au niveau hôte ; ne montez pas les jeux de réglages de récupération à l’aveugle.

Tâche 13 : Vérifier les compteurs de perf OSD (latence commit/apply)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
0    7                   11
3    9                   14
7    120                 220
21   85                  160

Ce que cela signifie : Les OSD 7 et 21 sont lents par rapport aux autres. Cela peut venir de contention disque, d’une NIC saturée, d’un SSD défaillant, ou d’un problème DB/WAL.

Décision : Enquêtez sur ces hôtes avant d’ajuster quoi que ce soit. Si un OSD est pathologique, la récupération en fera la queue et les PG sembleront « bloqués ».

Tâche 14 : Vérifier rapidement la santé réseau (Ceph est un stockage distribué, pas un disque local déguisé)

cr0x@server:~$ ceph config get osd public_network
10.10.0.0/24

cr0x@server:~$ ssh pve2 -- ping -c 3 10.10.0.11
PING 10.10.0.11 (10.10.0.11) 56(84) bytes of data.
64 bytes from 10.10.0.11: icmp_seq=1 ttl=64 time=0.411 ms
64 bytes from 10.10.0.11: icmp_seq=2 ttl=64 time=0.399 ms
64 bytes from 10.10.0.11: icmp_seq=3 ttl=64 time=0.405 ms

--- 10.10.0.11 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2033ms
rtt min/avg/max/mdev = 0.399/0.405/0.411/0.005 ms

Ce que cela signifie : La latence est basse et stable sur un ping basique. Cela n’atteste pas d’un réseau parfait, mais élimine une partition évidente.

Décision : Si le ping montre des pertes/pics de latence, stoppez. Réparez le réseau d’abord, sinon vous « réparerez » Ceph et creuserez un trou plus profond.

Tâche 15 : Inspecter la liste des PG bloqués en masse (matcher des motifs fait gagner du temps)

cr0x@server:~$ ceph pg dump_stuck inactive
PG_STAT  STATE     UP      UP_PRIMARY  ACTING  ACTING_PRIMARY  LAST_SCRUB  SCRUB_STAMP  LAST_DEEP_SCRUB  DEEP_SCRUB_STAMP

Ce que cela signifie : Si cette sortie est vide, vous avez levé les PG inactifs. Sinon, la liste montre si les mêmes IDs OSD reviennent souvent.

Décision : Des acting sets partagés impliquent un problème d’OSD/nœud spécifique ; des motifs dispersés impliquent réseau/quorum/règles/capacité.

Tâche 16 : Vérifier si des pools sont mal configurés (mismatch size/min_size peut maintenir les PG malheureux)

cr0x@server:~$ ceph osd pool ls detail
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 256 pgp_num 256 autoscale_mode on
pool 2 'cephfs_data' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 autoscale_mode on

Ce que cela signifie : Pour les pools répliqués, size est le nombre de répliques ; min_size est le minimum requis pour servir les écritures.
Si min_size est trop élevé par rapport à la disponibilité OSD actuelle, vous pouvez vous retrouver avec des écritures bloquées ou des PGs malsains pendant une panne.

Décision : Ne baissez pas min_size à la légère. Cela peut maintenir le cluster écrivable, mais augmente le risque. N’utilisez‑le qu’avec acceptation explicite du potentiel de perte de données.

Tâche 17 : Valider que le cluster n’est pas en pause (oui, ça arrive)

cr0x@server:~$ ceph osd dump | egrep 'pause|noup|nodown|noin|nobackfill|norecover|noscrub|nodeep-scrub'
flags nodown,noin,nobackfill,norecover

Ce que cela signifie : Quelqu’un a posé des flags qui empêchent la guérison normale (norecover, nobackfill). Parfois c’est intentionnel pour maintenance. Parfois c’est oublié.

Décision : Si vous n’êtes pas en fenêtre de maintenance contrôlée, retirez les flags. Sinon vos PG resteront dégradés/bloqués indéfiniment.

cr0x@server:~$ ceph osd unset norecover
unset norecover
cr0x@server:~$ ceph osd unset nobackfill
unset nobackfill
cr0x@server:~$ ceph osd unset noin
unset noin
cr0x@server:~$ ceph osd unset nodown
unset nodown

Tâche 18 : Si un OSD est lent, vérifier la saturation IO de l’hôte (sanity rapide)

cr0x@server:~$ ssh pve2 -- iostat -x 1 3
Linux 6.8.12-pve (pve2)  12/26/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.11    0.00    6.24   18.52    0.00   63.13

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1         120.0   310.0  7800.0  21400.0    92.0     8.40   24.10   12.30   28.70   1.20  51.00
sdd              15.0    40.0   800.0   1900.0    84.0    22.10  410.00  380.00  421.00  7.10  98.50

Ce que cela signifie : sdd est à ~98 % d’utilisation avec ~410 ms d’attente. Cela crée absolument des slow ops et prolonge la récupération.

Décision : Si c’est un disque de données OSD, préparez son remplacement. S’il s’agit d’un device DB/WAL partagé par plusieurs OSD, vous avez trouvé votre amplificateur de latence cluster‑wide.

Tâche 19 : Mapper un PG vers les OSD acting puis vers les hôtes (pour corréler les pannes)

cr0x@server:~$ ceph pg map 1.2f
osdmap e4123 pg 1.2f (1.2f) -> up [3,7,18] acting [3,7,18]

Ce que cela signifie : Après avoir marqué osd.12 out, le PG s’est remappé sur un nouvel acting set. Cela devrait éliminer les conditions « blocked_by osd.12 ».

Décision : Si le mapping du PG continue de sauter, suspectez un problème de quorum mon, des OSD qui flapent, ou un réseau instable.

Tâche 20 : Seulement si vous avez des preuves d’incohérence métadonnées : tenter un repair PG (rare, prudent)

cr0x@server:~$ ceph pg repair 1.31
instructing pg 1.31 on osd.7 to repair

Ce que cela signifie : ceph pg repair peut aider si un PG est bloqué à cause de répliques incohérentes. Il peut aussi consommer CPU et I/O et
empirer les choses si le problème sous‑jacent est des OSD manquants ou des disques cassés.

Décision : Lancez repair seulement après avoir restauré un quorum stable et la disponibilité des OSD. Si un OSD manque, repair est généralement de la mise en scène.

Une citation pour garder les mains fraîches : Werner Vogels (idée paraphrasée) : « Tout échoue, tout le temps — concevez et exploitez comme si c’était normal. »

Modes de défaillance qui gardent les PG bloqués

1) Un OSD est down, mais toujours « in », et le PG en a besoin pour peerer

C’est la forme d’incident Proxmox‑on‑Ceph la plus courante : reboot d’un hôte, disque mort, reset de contrôleur, ou crash d’un OSD. Ceph le marque down.
S’il reste « in », certains PG attendront sa participation (surtout si il détenait auparavant des données faisant autorité et que les autres ont besoin de son log pour s’accorder).

Le bon geste dépend de la cause racine :

• Crash du démon, périphérique sain : redémarrer l’OSD, confirmer qu’il reste up.
• Erreurs I/O périphérique : marquer out, remplacer, rebuild. Ne pas continuer à couper/ralumer un disque mourant ; il ne s’améliore pas par rancune.
• Hôte down : restaurer l’hôte/réseau/alimentation d’abord ; décider de marquer out en fonction du MTTR attendu et de la redondance actuelle.

2) Instabilité du quorum mon provoquant un churn constant des maps

Si les moniteurs ne gardent pas le quorum, les osdmap et le mapping des PG peuvent churner. Les PG peerent, puis re‑peerent, puis re‑peerent encore. Vous verrez un peering bloqué,
mais le vrai problème est la gouvernance : le cluster ne peut s’accorder sur la vérité courante.

Les causes racines incluent partition réseau, dérive d’horloge, mons surchargés, ou disques lents hébergeant la BD mon. Dans Proxmox, héberger des mons sur des nœuds très occupés est courant.
Ça marche — jusqu’à ce que ça ne marche plus.

3) Nearfull/backfillfull/full bloque le mouvement et crée des impasses

Ceph se protège contre le manque d’espace en restreignant le backfill et, au pire, les écritures. Si certains OSD sont nearfull, CRUSH peut continuer à placer des données sur
ceux qui restent, les rendant nearfull aussi. La récupération ralentit, et votre « fix » (ajouter de la charge ou redémarrer) empire la situation.

Si vous êtes nearfull et avez des PG inactifs, vos options se réduisent :

• Ajouter de la capacité (la meilleure réponse si faisable rapidement).
• Supprimer des données (uniquement si vous êtes absolument sûr de ce que vous supprimez).
• Ajuster temporairement les ratios full (risqué ; vous échangez des garde‑fous de cohérence contre du temps).

4) Un tuning backfill/recovery qui tourne au masochisme

Les réglages de récupération ne sont pas des boosters de performance. Ce sont des compromis. Si vous rendez la récupération trop agressive, vous pouvez saturer disques et réseaux,
provoquer des timeouts clients, faire sembler des OSD « down » à cause de délais de heartbeat, et bloquer le peering car les participants sont surchargés.

Si vous la rendez trop conservative, vous pouvez étirer une fenêtre de panne de minutes en heures — assez longtemps pour qu’une autre défaillance survienne.
Les clusters n’aiment pas les fenêtres d’exposition longues.

5) Un dispositif pathologique (souvent DB/WAL) empoisonne tout le cluster

BlueStore utilise RocksDB et un WAL. Si le DB/WAL est sur un SSD partagé qui défaillit ou est saturé, plusieurs OSD peuvent devenir « lents mais pas morts ».
C’est le pire : tout est techniquement up, mais les PG ne progressent pas assez vite et les slow ops s’accumulent.

6) Changements CRUSH/règles ou paramètres de pool créent des surprises

Modifier les domaines de panne, les classes de périphérique, ou les règles CRUSH peut déclencher des remaps massifs. Pendant un état dégradé, c’est un excellent moyen de créer un second incident
sans avoir résolu le premier. Si les PG sont inactifs, le cluster est déjà fragile : réduisez le changement, n’augmentez pas.

7) PG incomplete : quand Ceph ne trouve pas de données faisant autorité

incomplete est l’endroit où « incident de disponibilité » devient « incident d’intégrité des données ». Cela peut se produire si trop d’OSD ayant détenu un PG sont partis
(ou marqués lost), ou si les répliques restantes n’ont pas assez d’historique pour s’accorder.

Votre travail est de déterminer si :

• Ces OSD peuvent être ramenés (meilleur scénario).
• Vous pouvez restaurer depuis une sauvegarde/snapshot (souvent le choix business correct).
• Vous devez déclarer des données perdues pour certains PG (dernier recours, décision métier, pas un réflexe CLI).

Trois mini‑récits tirés de la vie en entreprise

Mini‑récit 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne faisait tourner Proxmox avec Ceph sur trois nœuds. Quelqu’un a vu 12 pgs inactive après un reboot de routine lié à une mise à jour du kernel.
Ils ont supposé qu’« inactif » voulait dire « rééquilibrage ». Le ticket helpdesk indiquait « le stockage est lent », donc ils ont traité ça comme un problème de performance.

Ils ont monté les réglages de recovery : plus de backfills, plus de recovery actifs. Ça semblait avancer — plus d’I/O, plus de réseau. Pendant ce temps, le nœud rebooté
avait une NIC revenue en mauvaise vitesse à cause d’un problème d’autonégociation. Les heartbeats tombaient. Les OSD flappaient, sans vraiment tomber proprement.

La mauvaise hypothèse était subtile : croire que Ceph était libre de déplacer des données si besoin. Mais le peering avait besoin d’une adhésion stable d’abord. Le trafic de récupération
accru a rendu la NIC déjà instable encore plus sujette aux pertes de paquets, ce qui a fait paraître plus d’OSD down, ce qui a fait re‑peerer plus de PG. Une belle boucle de rétroaction.

Finalement, ils ont « réparé » le souci en rebootant tout — car rebooter est le solvant universel des mauvaises hypothèses. Le cluster est revenu, mais la récupération a pris plus de temps et
les clients ont vu plus de timeouts qu’avec la correction ennuyeuse : forcer la NIC à la bonne vitesse/duplex, stabiliser les heartbeats, puis laisser le peering se terminer.

La leçon : l’inactivité des PG est souvent un problème d’adhésion, pas de bande passante. Réparez la participation (OSD, réseau, quorum) avant de tuner la récupération.

Mini‑récit 2 : l’optimisation qui s’est retournée contre eux

Une grande entreprise voulait une récupération plus rapide après des pannes de disque. Leur équipe stockage a augmenté la concurrence partout : plus de backfills, plus de threads recovery,
priorité recovery plus haute. Sur le papier, cela réduisait le MTTR en labo.

En production, cela a coïncidé avec un lot de firmware SSD défectueux sur un sous‑ensemble de nœuds. Ces SSD ne tombaient pas en panne net ; ils devenaient lents sous charge d’écriture soutenue.
Le trafic de recovery a forcé ces SSD lents dans leur pire comportement : pics de latence et resets occasionnels.

Une fois qu’un périphérique commence à staller, Ceph fait ce que font les systèmes distribués : il réessaie, met en file, re‑peere, loggue des slow ops. Soudain le cluster n’était pas seulement
en récupération — il attendait collectivement sur une poignée de périphériques techniquement vivants. Les PG ont commencé à coller en peering et backfill_wait parce que le cluster ne pouvait pas garder un rythme stable.

Ils ont annulé le tuning et mis en place une politique : pendant un incident dégradé, la récupération n’est agressive que si la latence des périphériques reste dans un enveloppe définie.
Sinon, on réduit la récupération pour préserver le service et éviter le flapping d’OSD. Cette politique a empêché les futurs « optimisations » de transformer des pannes en effondrements.

La leçon : le tuning de récupération doit être borné par la latence observée, pas par l’optimisme. La concurrence est une arme ; ne la pointez pas vers votre propre pied.

Mini‑récit 3 : la pratique ennuyeuse et correcte qui a sauvé la mise

Une organisation finance avait une discipline de changement rigide pour leur cluster Proxmox Ceph. Ce n’était pas glamour. Ils maintenaient un runbook et exigeaient une
« capture d’écran de la santé du cluster » (en pratique les sorties ceph -s et ceph health detail collées dans le ticket) avant et après maintenance.

Un matin, ils ont vu pgs inactive après le reboot d’un switch top‑of‑rack. L’astreinte a suivi le runbook : vérifier le quorum mon, l’OSD down,
identifier les acting sets partagés, et vérifier la connectivité réseau entre les réseaux public/cluster Ceph. Ils ont trouvé qu’un trunk VLAN n’était pas revenu correctement.

Voici l’ennuyeux : ils n’ont pas redémarré les OSD. Ils n’ont pas touché au tuning de recovery. Ils n’ont rien marqué lost. Ils ont réparé le trunk, attendu que les heartbeats OSD se stabilisent,
regardé les PG peerer, puis surveillé la récupération. L’incident est resté un micro‑épisode de disponibilité, pas un incident de données.

Plus tard, dans le postmortem, ils ont comparé avec un événement similaire quelques mois avant (avant le runbook) où quelqu’un avait marqué un OSD out prématurément,
provoquant une tempête de récupération en heures de bureau. Le runbook n’a pas rendu les ingénieurs plus intelligents. Il les a rendus moins improvisateurs.

La leçon : les processus ennuyeux réduisent les dégâts créatifs. En stockage, la créativité est surcotée.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : « PGs bloqués en peering » après un reboot de nœud

Cause racine : Les OSD flappent car le nœud est revenu avec un réseau dégradé, MTU incohérent, ou problèmes de synchronisation horaire ; le peering ne se stabilise jamais.

Correction : Stabilisez le nœud : vérifiez vitesse/duplex NIC, cohérence MTU, routes/VLANs, et NTP/chrony. Ensuite, redémarrez les daemons OSD affectés si nécessaire.

2) Symptôme : « PGs inactifs » et ceph pg query montre blocked_by osd.X

Cause racine : Cet OSD est down, bloqué, ou trop lent pour répondre, et il est nécessaire pour l’historique de peering.

Correction : Si récupérable : restaurez l’OSD (service + périphérique). Sinon : marquez‑le out et remplacez‑le. Ne lancez pas ceph pg repair pour compenser des OSD manquants.

3) Symptôme : la récupération ne démarre pas, les PG restent dégradés, mais « tout est up »

Cause racine : Des flags cluster comme norecover ou nobackfill ont été posés pendant une maintenance et oubliés.

Correction : Effacez les flags (ceph osd unset ...). Puis surveillez ceph -s pour confirmer que la récupération reprend.

4) Symptôme : explosion de slow ops pendant la récupération ; les OSD commencent à timeout

Cause racine : Concurrence de récupération trop élevée pour le hardware/réseau. Les heartbeats sont retardés, provoquant des flaps OSD et du churn de peering.

Correction : Réduisez la concurrence recovery/backfill. En Proxmox : tunez prudemment, surveillez ceph osd perf, et privilégiez la stabilité du cluster plutôt que la vitesse.

5) Symptôme : PGs bloqués en backfill_wait longtemps

Cause racine : Soit les throttles sont trop stricts, soit il y a un goulot caché : OSD nearfull, OSD cibles lentes, ou contrainte réseau.

Correction : Vérifiez ceph df et ceph osd perf. Corrigez le périphérique lent ou la pression de capacité avant d’augmenter les limites de backfill.

6) Symptôme : PG inactifs/incomplets après plusieurs pannes disque sur le même hôte

Cause racine : Mismatch du domaine de panne. CRUSH pensait que les répliques étaient séparées, mais elles ne l’étaient pas (ou un hôte avait trop d’OSD pour le domaine).

Correction : Réévaluez le domaine de panne CRUSH (host/rack) et la distribution des OSD. C’est une correction de conception, pas un pansement d’incident. Pour l’incident : restaurez les OSD manquants ou restaurez depuis la sauvegarde.

7) Symptôme : PG bloqués après changement de size/min_size ou des règles

Cause racine : Vous avez changé le placement alors que le cluster était déjà malsain ; les remaps se sont empilés sur la récupération.

Correction : Arrêtez de changer les règles pendant la dégradation. Restaurez si c’est sûr, stabilisez la disponibilité des OSD, puis réappliquez les changements en fenêtre contrôlée.

8) Symptôme : Ceph affiche des PG « stale »

Cause racine : Les mons/OSD ne reçoivent pas de heartbeats (partition réseau, gel d’hôte, ou erreur de firewall sur les ports Ceph).

Correction : Réparez la connectivité réseau et la santé des hôtes. Ne marquez pas les OSD stale comme lost à moins d’être prêts pour une déclaration de perte de données définitive.

Checklists / plan pas à pas

Plan pas à pas pour un incident en direct (PG bloqués/inactifs)

1. Geler les changements risqués.
   Arrêtez le tuning, arrêtez « on met à jour vite fait », arrêtez de redémarrer les daemons comme si vous secouiez un distributeur automatique.
2. Capturer la vérité courante.
   Lancez ceph -s et ceph health detail. Sauvegardez les sorties dans le canal/ticket d’incident.
3. Lister les PG bloqués et identifier les OSD acting partagés.
   Utilisez ceph health detail et ceph pg dump_stuck inactive.
4. Confirmer la stabilité du quorum mon.
   ceph quorum_status. Si le quorum est instable, corrigez‑le d’abord.
5. Vérifier l’état et l’emplacement des OSD.
   ceph osd tree et ceph osd stat.
6. Pour un OSD suspect, inspecter service + logs + messages kernel.
   Si vous voyez des erreurs I/O, traitez‑le comme du hardware, pas de l’humeur logicielle.
7. Décider : restaurer vs marquer out.
   Si l’OSD peut revenir vite et proprement, restaurez‑le. Sinon, marquez‑le out et remplacez‑le.
8. Surveiller l’évolution des états PG.
   Votre première condition de succès est « plus de PG inactive ». La seconde est « le nombre de degraded diminue ».
9. Gérer la charge de récupération si nécessaire.
   Si les slow ops et la douleur client sont sévères, réduisez la concurrence de récupération. Si la récupération est trop lente et le cluster stable, augmentez légèrement. Ne passez jamais de 1 à 11.
10. Après stabilisation, traiter la cause racine.
    Remplacez le hardware, corrigez le réseau, et documentez la chaîne de preuves (sorties, logs et décisions).

Checklist de sécurité avant d’utiliser des « outils tranchants »

• Quorum mon stable pendant au moins quelques minutes (pas d’élections rapides).
• Vous pouvez nommer précisément les PG et les OSD impliqués.
• Vous avez vérifié les logs device/kernel pour erreurs matérielles.
• Vous comprenez l’impact des paramètres size et min_size sur la sécurité des données.
• Vous avez un plan de rollback ou au moins une « condition d’arrêt ».
• Les parties prenantes sont informées si vous envisagez ceph osd lost ou de baisser min_size.

Checklist de stabilisation après l’incident

• Effacer les flags temporaires : vérifier l’absence de norecover, nobackfill, noscrub.
• Confirmer que les PG sont active+clean (ou que vous avez un état degraded acceptable avec plan).
• Revoir les outliers de perf OSD (ceph osd perf) et remplacer/réparer les périphériques faibles.
• Vérifier la synchronisation horaire entre nœuds ; Ceph déteste les drames temporels.
• Enregistrer : ce qui a cassé, l’heure de détection, les points de décision, et ce que vous avez changé.

FAQ

1) « PGs bloqués » et « PGs inactifs » sont‑ils la même chose ?

Non. « Bloqué » est une alarme de durée : un PG est resté trop longtemps dans un certain état. « Inactif » est un état : le PG ne peut pas servir d’E/S en sécurité. Inactif est plus urgent.

2) Puis‑je simplement redémarrer les services Ceph sur tous les nœuds ?

Vous pouvez, mais c’est un outil brutal qui cache souvent la cause racine. Si le problème est des erreurs I/O disque, des partitions réseau, ou une instabilité du quorum,
les redémarrages peuvent allonger le peering et augmenter le churn des maps. Redémarrez seulement le composant pour lequel vous avez une preuve.

3) Quand devrais‑je marquer un OSD out ?

Marquez‑le out quand vous avez une raison crédible qu’il ne reviendra pas vite et proprement : erreurs I/O confirmées, crashes répétés, défaillance matérielle hôte,
ou MTTR long. Si ce n’est qu’un reboot court avec des disques sains, il vaut souvent mieux attendre quelques minutes — sauf si vous êtes déjà à un seuil critique.

4) Quelle est la façon la plus rapide de voir ce qu’attend un PG inactif ?

Commencez par ceph health detail pour les IDs de PG et l’acting set, puis ceph pg <pgid> query. Cherchez blocked_by ou les bloqueurs de peering.

5) Dois‑je lancer ceph pg repair quand le peering est bloqué ?

Normalement non. Si le PG est bloqué parce qu’un OSD manque ou que le cluster est instable, repair ne règle pas le participant manquant. Utilisez repair lorsque vous avez des preuves d’incohérence avec tous les OSD requis présents et stables.

6) Que signifie active+undersized pour mes disques VM ?

Cela veut dire que le PG est actif (les E/S peuvent se poursuivre) mais que moins de répliques existent que la valeur size du pool. Le risque est augmenté : une autre défaillance au mauvais endroit peut
rendre les données indisponibles ou perdues. Considérez‑le comme « rouler sur la roue de secours ».

7) Pourquoi les PG se bloquent pendant le backfill alors que le hardware semble correct ?

Raisons courantes : flags/throttles (nobackfill, norecover), contraintes nearfull, ou un OSD beaucoup plus lent que les autres.
La récupération tend à avancer à la vitesse du participant critique le plus lent.

8) Est‑il sûr de baisser min_size pour relancer les écritures ?

Cela peut être nécessaire opérationnellement, mais c’est un compromis délibéré. Baisser min_size permet des écritures avec moins de répliques, ce qui augmente la probabilité
de perte de données si un autre OSD lâche avant la fin de la récupération. Faites‑en un changement documenté, limité dans le temps, avec une sortie claire.

9) Les mises à jour Proxmox causent‑elles souvent des événements PG inactive ?

Les mises à jour en elles‑mêmes ne sont pas la cause ; ce sont les reboots et redémarrages de services. Des reboots en rolling sans vérifier la santé du cluster, ou rebooter plusieurs nœuds Ceph en même temps,
est une méthode fiable pour découvrir de nouveaux états PG.

10) Si j’ai des PG incomplete, que dois‑je faire en premier ?

Arrêtez de faire des changements et concentrez‑vous sur la restauration des OSD manquants qui pourraient contenir des données faisant autorité. S’ils sont perdus, passez au plan sauvegarde/restauration.
Les options « forcer » sont un dernier recours et doivent être traitées comme des décisions métiers, pas un acte de bravoure technique.

Conclusion : étapes suivantes pour réduire la douleur future

Quand des PG sont bloqués/inactifs, le cluster vous dit qu’il ne peut pas compléter une poignée de sécurité critique. Votre travail n’est pas de « faire disparaître l’alerte ».
Votre travail est de restaurer une participation stable : quorum, réseau, disponibilité OSD, et une marge de capacité raisonnable.

Étapes pratiques suivantes :

• Codifiez le playbook de diagnostic rapide dans vos notes d’astreinte : ceph -s, ceph health detail, ceph pg query, ceph osd tree, quorum, capacité, perf.
• Surveillez et remplacez les périphériques lents avant qu’ils ne deviennent « pas morts assez » pour échouer brutalement. Les outliers ceph osd perf sont des signaux précoces.
• Garder le tuning de récupération minimal et limité dans le temps. Si vous devez le changer, enregistrez‑le, posez un rappel et revenez en arrière.
• Concevez des domaines de panne qui reflètent la réalité. La séparation au niveau hôte n’est pas optionnelle quand vos « hôtes » partagent alimentation ou commutateur.
• Pratiquez l’approche ennuyeuse. Preuve, plus petit changement, observer, répéter. Ce n’est pas héroïque. Ça marche.

Si vous retenez une chose : l’inactivité des PG est d’abord une alarme de cohérence, ensuite un problème de performance. Traitez‑la comme telle et vous aurez moins de postmortems « nous avons augmenté le risque ».