Aller au contenu

PG inactive, degraded, inconsistent : diagnostic

Day 2 · ExploiterNiveau 3 · MaîtriserRunbookRédigé · à valider en lab

Objectif : face à des PG qui ne sont pas active+clean, savoir en 10 minutes si les données sont accessibles, s'il faut simplement attendre, agir sur un OSD ou ouvrir un P1. Le diagnostic est en lecture seule et peut être fait par le client ; les actions correctrices (ceph pg repair, mark_unfound_lost, ceph osd lost, modification de min_size) relèvent du MSP selon votre contrat.

Avant de toucher la prod

  • Lire l'état global d'abord : RB-01 (ceph -s, ceph health detail).
  • Vérifier qu'aucune maintenance n'est en cours (nœud redémarré, drapeau noout) : des PG degraded sont alors normaux (RB-02).
  • Ne lancer aucune commande d'écriture (repair, out, destroy, lost, set min_size) tant que la cause n'est pas comprise.

Lire l'état d'un PG

État Signification Données accessibles ? Gravité
active+clean Toutes les copies présentes et à jour Oui Normal
degraded Des objets ont moins de copies que size Oui Normal pendant une panne ou maintenance, sinon P3
undersized Le PG a moins d'OSD assignés que size (aucun OSD disponible pour la copie manquante) Oui si au moins min_size P3 ; permanent si la règle CRUSH ne trouve pas assez d'hôtes
backfilling, recovering, remapped Reconstruction ou déplacement en cours Oui Attendre
peering Les OSD se mettent d'accord sur l'état du PG Bloquées quelques secondes Anormal s'il dure plus de quelques minutes
inactive (dont down, incomplete) Le PG ne sert plus de lectures ni d'écritures Non : VMs figées P1
stale Aucun OSD n'a rapporté l'état du PG récemment : ses OSD sont probablement tous down Non P1
inconsistent Le scrub a trouvé des copies différentes ou illisibles Oui P2 : erreur disque probable

Étapes

1. Lister les PG concernés

Nœud → Ceph → Status : le panneau PGs donne la répartition des états ; cliquer sur l'état de santé pour lire chaque alerte (PG_DEGRADED, PG_AVAILABILITY, OSD_SCRUB_ERRORS, PG_DAMAGED).

ceph health detail                  # PG et OSD en cause
ceph pg dump_stuck inactive         # PG bloqués inactifs
ceph pg dump_stuck unclean
ceph pg dump_stuck stale
ceph pg ls degraded                 # ou undersized, inconsistent…

2. PG degraded ou undersized : trouver l'OSD manquant

ceph osd tree | grep -E 'down|out'       # quel OSD, sur quel hôte
ceph pg 2.1a query | less                # section "up" / "acting" et "recovery_state"
  • OSD down sur un nœud en maintenance : attendre son retour.
  • OSD down sans raison : systemctl status ceph-osd@<id>, journalctl -u ceph-osd@<id> -n 100, smartctl -a. Disque défaillant : RB-03.
  • undersized permanent sans OSD down : la règle CRUSH ne trouve pas assez d'hôtes ou de racks (cluster de 3 nœuds après perte d'un nœud, règle rack mal construite) : ticket MSP.

3. PG inactive, down, incomplete ou stale : ticket P1

ceph pg <pgid> query | grep -A20 recovery_state   # "blocked_by", "down_osds_we_would_probe"

Le champ blocked_by indique les OSD dont le PG a besoin. Si ces OSD sont sur un nœud éteint, le rallumer est souvent la solution. Ne marquez jamais un OSD lost et ne lancez jamais mark_unfound_lost : ces commandes acceptent une perte de données et sont réservées au MSP.

4. PG inconsistent : identifier avant de réparer

ceph health detail | grep inconsistent           # ex. pg 2.1a is active+clean+inconsistent, acting [3,7,12]
rados list-inconsistent-pg ceph-vm
rados list-inconsistent-obj 2.1a --format=json-pretty | less
# Lire "errors" par shard : read_error, data_digest_mismatch, size_mismatch… et l'OSD fautif
smartctl -a /dev/sdX                              # disque de l'OSD fautif
  • Une erreur read_error sur un seul OSD dont le disque montre des secteurs réalloués ou en attente : cas classique. La réparation reconstruit la copie fautive à partir des copies saines. Avec l'accord du MSP (ou par le MSP) : ceph pg repair 2.1a, puis planifier le remplacement du disque (RB-03).
  • Erreurs sur plusieurs OSD, ou data_digest_mismatch sans OSD clairement fautif : ne pas réparer, ticket P2.
  • Après réparation : ceph pg deep-scrub 2.1a pour confirmer.

Vérifications

ceph -s : HEALTH_OK, pgs: 100.000% pgs active+clean. ceph health detail sans OSD_SCRUB_ERRORS ni PG_DAMAGED. rados list-inconsistent-pg ceph-vm renvoie []. VMs qui répondent normalement.

Rollback

Le diagnostic est sans effet. ceph pg repair et ceph pg deep-scrub ne se rollbackent pas mais ne suppriment pas de copie saine lorsqu'une copie fautive est clairement identifiée. mark_unfound_lost et ceph osd lost sont irréversibles : réservés au MSP.

Pièges vus en support

  • Lancer ceph pg repair en boucle sur tous les PG inconsistent sans regarder quel disque est fautif : le disque continue de se dégrader et les erreurs reviennent.
  • Baisser min_size à 1 pour « débloquer » des PG inactifs : les écritures n'existent plus qu'en un exemplaire.
  • Paniquer sur degraded pendant un redémarrage de nœud : c'est attendu, attendre le retour à active+clean.
  • Retirer noout alors qu'un nœud est éteint : reconstruction massive inutile s'il revient dans l'heure.
  • Ignorer un inconsistent isolé : c'est souvent le premier signe d'un disque en fin de vie.

Quand ouvrir un ticket iTop

PG inactive, down, incomplete, stale ou objets unfound : P1 immédiat. inconsistent : P2 (avant toute réparation si vous êtes en N1). undersized persistant sans maintenance en cours : P3. Joindre ceph -s, ceph health detail, ceph osd tree, ceph pg <pgid> query et rados list-inconsistent-obj <pgid> --format=json-pretty le cas échéant.

Ouvrir un ticket iTop

Pour aller plus loin