Proxmox Ceph OSD en panne : Disque vs Réseau vs Service — Identification rapide

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

Quand un OSD tombe, votre rôle n’est pas d’être brillant. Votre rôle est d’être rapide, correct et ennuyeux. Commencez par les questions qui réduisent le plus l’incertitude.

Premier : Le nœud est-il joignable et l’heure est-elle correcte ?

• Vérifier la joignabilité de l’hôte : Pouvez-vous SSH vers le nœud ? Si non, vous ne dépannez pas Ceph ; vous dépannez l’hôte, l’hyperviseur ou le réseau.
• Vérifier l’heure : Si les horloges dérivent, Ceph se comporte comme si vous aviez remplacé la physique par du théâtre d’improvisation. Corrigez NTP avant de poursuivre.

Second : Le processus OSD échoue-t-il, ou est-il en cours d’exécution mais isolé ?

• État du service : Si systemd indique que l’OSD est en boucle de plantage, vous avez probablement des problèmes liés au disque/BlueStore/corruption/authentification. S’il est « active (running) » mais que le cluster le montre down, suspectez le réseau, le pare-feu ou une liaison IP incorrecte.
• Vue Ceph : Comparez ceph osd tree avec le statut systemd. Les désaccords sont de l’or diagnostique.

Troisième : Le disque est-il suffisamment sain pour supporter les E/S du journal/BlueStore ?

• Journaux du noyau : Un coup d’œil à dmesg et journalctl vous dira souvent si le disque génère des erreurs ou des temporisations.
• SMART et temporisations E/S : Si vous voyez des réinitialisations, des temporisations ou des réallocations SMART, arrêtez de redémarrer les démons et commencez à planifier le remplacement.

Conditions d’arrêt (éviter d’empirer)

• Si plusieurs OSDs sont down sur plusieurs hôtes : traitez-le comme un problème réseau ou de configuration cluster jusqu’à preuve du contraire.
• Si un seul hôte perd de nombreux OSDs à la fois : suspectez le HBA/backplane/PSU ou le réseau de cet hôte.
• Si l’OSD clignote (flaps) : supposez des blocages E/S intermittents ou une perte de paquets, pas « Ceph est bizarre ». Ceph est déterministe ; votre matériel ne l’est pas.

Un modèle mental pratique : ce que « OSD down » signifie vraiment

Ceph a deux « vérités » différentes concernant un OSD :

• Ce que pense l’hôte : systemd lance ceph-osd@ID, le processus s’exécute, il peut lire son store, il se lie à une IP et il contacte les monitors.
• Ce que pense le cluster : les monitors suivent les heartbeats des OSD. Si les monitors ne les reçoivent pas dans les tolérances, l’OSD est marqué down. Séparément, un OSD peut être out (exclu du placement des données) même s’il est up.

Donc « OSD down » n’est pas par définition « disque mort ». C’est « le cluster ne peut pas entendre cet OSD de façon fiable ». Cela peut être :

• Disque/E/S : le processus OSD se bloque ou plante parce que les lectures/écritures vers l’appareil BlueStore temporisent.
• Réseau : l’OSD est sain localement mais ne peut pas atteindre les mons ou les pairs (routage, VLAN, MTU, bonding, switch, pare-feu).
• Service/configuration : l’OSD ne démarre pas, ne peut pas s’authentifier (cephx), se lie à la mauvaise adresse ou rencontre un décalage de version/config.

Ce que vous voulez, c’est un ensemble minimal de vérifications qui sépare ces catégories tôt. Tout le reste est du détail.

Idée paraphrasée (Gene Kim, auteur fiabilité/opérations) : « L’amélioration survient quand vous raccourcissez et stabilisez les boucles de rétroaction. » C’est ce que fait ce playbook : des boucles courtes.

Faits et contexte intéressants (réalité Ceph + Proxmox)

1. La logique de “heartbeat” des OSD est centrée sur les monitors. Votre OSD peut être occupé, vivant, et quand même déclaré down si les heartbeats n’arrivent pas à temps.
2. “Down” et “out” sont des leviers différents. down est la détection de santé ; out est le placement des données. Les confondre cause des tempêtes de rééquilibrage auto-infligées.
3. BlueStore a remplacé FileStore parce que le double-écriture et le surcoût des systèmes de fichiers de FileStore ne suivaient pas les attentes de latence des disques modernes.
4. L’algorithme CRUSH de Ceph remonte à des recherches sur les domaines de défaillance contrôlés. C’est pourquoi vous pouvez survivre à la perte d’hôtes ou de racks, à condition que votre topologie soit honnête.
5. Proxmox a intégré la gestion de Ceph pour rendre le stockage hyperconvergé accessible, mais cela rend aussi facile de cliquer jusqu’au problème quand on ne comprend pas le comportement du démon sous-jacent.
6. Les erreurs réseau se déguisent en pannes disque. La perte de paquets peut ressembler à des « opérations lentes » et des temporisations. Un mauvais port de switch a ruiné plus de weekends que des bugs de firmware.
7. Le clignotement d’un OSD n’est généralement pas un hasard logiciel. C’est souvent de l’économie d’énergie, une limitation thermique, des problèmes HBA, ou des liaisons marginales—des choses qui « marchent généralement » jusqu’à un pic de charge.
8. La récupération Ceph peut amplifier les problèmes. Quand un OSD tombe, le backfill/la récupération augmente les I/O et le trafic réseau, ce qui peut pousser des composants marginaux au-delà de leur seuil.

Blague #1 : Le stockage distribué, c’est juste du stockage mono-hôte, plus du réseau, plus du consensus, plus la chance d’avoir tort à trois endroits à la fois.

Tâches de triage : commandes, sorties, décisions (12+)

Voici des tâches pratiques à exécuter sur des nœuds Proxmox (ou depuis un nœud disposant des droits d’administration Ceph). Chaque tâche inclut la commande, ce que signifie une sortie typique, et la décision suivante. Exécutez-les dans cet ordre approximatif sauf si vous connaissez déjà la catégorie.

Task 1: Confirm the cluster sees an OSD down, and which one

cr0x@pve1:~$ ceph -s
  cluster:
    id:     7c2a0d3e-0f8a-4e5a-9a5b-5e9b0c7d3c12
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12 pgs undersized
  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 6h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 12 osds: 11 up (since 4m), 12 in (since 6h)
  data:
    pools:   4 pools, 128 pgs
    objects: 2.1M objects, 8.3 TiB
    usage:   25 TiB used, 40 TiB / 65 TiB avail
    pgs:     12 undersized+degraded

Meaning: This is real: the cluster is warning about at least one OSD down, and PGs are impacted.

Decision: Identify which OSD(s) and which host(s) immediately. Don’t restart random services yet.

Task 2: Map OSD ID to host and device location

cr0x@pve1:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME      STATUS  REWEIGHT  PRI-AFF
-1         65.00000 root default
-3         21.66667     host pve1
 0   hdd    3.61111         osd.0      up   1.00000  1.00000
 1   hdd    3.61111         osd.1      up   1.00000  1.00000
 2   hdd    3.61111         osd.2    down   1.00000  1.00000
-5         21.66667     host pve2
 3   hdd    3.61111         osd.3      up   1.00000  1.00000
...

Meaning: osd.2 is down on pve1.

Decision: Move to the specific host and check the OSD daemon + disk.

Task 3: Check whether the OSD service is running (service vs network split)

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

Dec 26 08:51:22 pve1 ceph-osd[18342]: bluestore(/var/lib/ceph/osd/ceph-2) _read_bdev_label failed: (5) Input/output error
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 08:51:22 pve1 systemd[1]: ceph-osd@2.service: Failed with result 'exit-code'.

Meaning: Not running; and the log screams IO error while reading BlueStore label. That’s usually disk path trouble, not networking.

Decision: Stop restarting; inspect disk/HBA and kernel logs. Prepare for replacement.

Task 4: If it’s running, verify Ceph still calls it down (network suspicion)

cr0x@pve1:~$ systemctl is-active ceph-osd@2
active

Meaning: Locally active. If ceph osd tree still shows it down, it’s often network, auth, or binding.

Decision: Check connectivity to monitors and the OSD’s bound addresses.

Task 5: Pull OSD-specific logs fast

cr0x@pve1:~$ journalctl -u ceph-osd@2 -n 80 --no-pager
Dec 26 08:49:10 pve1 ceph-osd[18011]: starting osd.2 at /var/lib/ceph/osd/ceph-2
Dec 26 08:49:11 pve1 ceph-osd[18011]: bluestore: using bdev /dev/ceph-2/block
Dec 26 08:49:15 pve1 ceph-osd[18011]: heartbeat_map is_healthy_to_peer osd.7 down
Dec 26 08:49:22 pve1 ceph-osd[18011]: slow ops, oldest one is now 31.122s
Dec 26 08:49:29 pve1 ceph-osd[18011]: monclient(hunting): authenticate timed out
Dec 26 08:49:31 pve1 ceph-osd[18011]: unable to talk to monitor
Dec 26 08:49:35 pve1 ceph-osd[18011]: dropped 3 slow requests due to timeout

Meaning: Slow ops then monitor auth timeouts. This could be disk stalls or network issues reaching mons. The “unable to talk to monitor” pushes you toward network, but don’t assume yet.

Decision: Check kernel logs for IO timeouts vs link/MTU issues. One will usually confess.

Task 6: Check kernel ring buffer for disk resets/timeouts (disk split)

cr0x@pve1:~$ dmesg -T | egrep -i 'blk_update_request|I/O error|reset|timed out|nvme|sd '
[Fri Dec 26 08:48:58 2025] sd 6:0:12:0: [sdl] tag#17 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT
[Fri Dec 26 08:48:58 2025] blk_update_request: I/O error, dev sdl, sector 182400 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Fri Dec 26 08:48:59 2025] sd 6:0:12:0: [sdl] rejecting I/O to offline device
[Fri Dec 26 08:49:02 2025] ata12: hard resetting link
[Fri Dec 26 08:49:07 2025] ata12: link is slow to respond, please be patient

Meaning: That’s a drive or link path misbehaving (disk, cable, backplane, HBA). Ceph is only the messenger.

Decision: Treat as hardware incident: stop flapping by marking out (if needed), and schedule replacement/maintenance.

Task 7: Check network link, errors, and drops (network split)

cr0x@pve1:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    981G  744M      0   18422       0  11922
    TX:  bytes packets errors dropped carrier collsns
    904G  701M      0       0       0      0      0

Meaning: Dropped RX packets at the bond level. On a storage network, drops are latency spikes wearing a trench coat.

Decision: Check slaves, switch ports, MTU consistency, and congestion. If drops climb during recovery, you’ve found your bottleneck.

Task 8: Validate MTU consistency (classic Proxmox/Ceph foot-gun)

cr0x@pve1:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

cr0x@pve2:~$ ip link show dev vmbr1 | sed -n '1p'
6: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000

Meaning: MTU mismatch. Jumbo frames on one side and not the other is how you buy “random” timeouts.

Decision: Fix MTU end-to-end (hosts, bonds, bridges, switch ports). Then re-evaluate OSD health.

Task 9: Confirm monitor connectivity from the affected node (network vs auth)

cr0x@pve1:~$ ceph quorum_status --format json-pretty | sed -n '1,40p'
{
  "election_epoch": 88,
  "quorum": [
    0,
    1,
    2
  ],
  "quorum_names": [
    "pve1",
    "pve2",
    "pve3"
  ],
  "quorum_leader_name": "pve1"
}

Meaning: From this node, the CLI can talk to mons. That doesn’t guarantee the OSD can, but it reduces “total network isolation.”

Decision: If the OSD can’t authenticate but CLI can, suspect cephx keyring/permissions or OSD binding to the wrong interface.

Task 10: Inspect which IPs Ceph thinks it should use (binding mistakes)

cr0x@pve1:~$ ceph config get osd public_network
10.10.10.0/24

cr0x@pve1:~$ ceph config get osd cluster_network
10.10.20.0/24

Meaning: Ceph is configured to bind to specific networks. If your host interfaces don’t match (or routes are wrong), the OSD may bind somewhere useless.

Decision: Verify host IP addressing and that both networks exist and route correctly on this node.

Task 11: Verify what address the OSD is advertising

cr0x@pve1:~$ ceph osd find 2
{
  "osd": 2,
  "ip": "10.10.10.11:6806/12345",
  "crush_location": {
    "host": "pve1",
    "root": "default"
  }
}

Meaning: The OSD advertises 10.10.10.11. If that IP is wrong, moved, or now on a different interface/VLAN, peers won’t reach it.

Decision: If this doesn’t match the intended network, fix addressing and restart the OSD cleanly. Don’t “out” it yet unless data risk requires it.

Task 12: Check Ceph “health detail” for immediate clues

cr0x@pve1:~$ ceph health detail
HEALTH_WARN 1 osds down; Degraded data redundancy: 12 pgs undersized
[WRN] OSD_DOWN: 1 osds down
    osd.2 is down
[WRN] PG_DEGRADED: Degraded data redundancy: 12 pgs undersized
    pg 1.2c is undersized+degraded, acting [7,2]
    pg 1.2f is undersized+degraded, acting [2,9]

Meaning: This is the cluster screaming “I’m missing osd.2.” It doesn’t say why, but it tells you impact and urgency.

Decision: If client IO is impacted and you need stability, consider marking the OSD out (with caution) to start recovery—after confirming it’s truly dead or unreachable for a while.

Task 13: Verify the block device mapping for that OSD (disk path accuracy)

cr0x@pve1:~$ ceph-volume lvm list --osd-id 2
====== osd.2 =======
[block]       /dev/ceph-2/block
  type        block
  lv_path     /dev/ceph-2/osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  vg_name     ceph-2
  lv_name     osd-block-3c6f8a1d-9c6e-4ad2-9e4c-5d2c6c4a9f12
  devices     /dev/sdl

Meaning: The OSD depends on /dev/sdl. Now you can check SMART, controller, cabling, and whether /dev/sdl is still present.

Decision: If the device is missing or unstable, stop. Hardware handling time.

Task 14: Quick device presence and latency sanity

cr0x@pve1:~$ lsblk -o NAME,SIZE,MODEL,SERIAL,STATE,ROTA,TYPE,MOUNTPOINT | egrep 'sdl|ceph-2|NAME'
NAME          SIZE MODEL            SERIAL        STATE ROTA TYPE MOUNTPOINT
sdl         3.6T  ST4000NM000A     ZC1ABC12      running    1 disk
ceph--2-osd--block--3c6f8a1d 3.6T                          1 lvm

Meaning: Device exists. Existence is not health, but it’s better than “gone.”

Decision: If service fails with IO errors despite presence, run SMART and check link resets.

Task 15: SMART health check (don’t overinterpret, but do respect it)

cr0x@pve1:~$ smartctl -a /dev/sdl | egrep -i 'Reallocated|Pending|Offline_Uncorrectable|SMART overall|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       39876
  5 Reallocated_Sector_Ct   0x0033   001   001   010    Pre-fail  Always       -       3200
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       88
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       88

Meaning: The drive is effectively telling you it’s leaving. Believe it.

Decision: Replace the disk. Don’t waste time tuning Ceph for failing hardware.

Task 16: If you suspect network loss, test loss and MTU properly (not just ping)

cr0x@pve1:~$ ping -c 5 -M do -s 8972 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
From 10.10.10.11 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 10.10.10.11 icmp_seq=2 Frag needed and DF set (mtu = 1500)
--- 10.10.10.12 ping statistics ---
5 packets transmitted, 0 received, +2 errors, 100% packet loss, time 4081ms

Meaning: Path MTU is 1500 somewhere. Jumbo is not end-to-end.

Decision: Fix MTU configuration before blaming Ceph. Then restart the affected OSD if it bound correctly.

Task 17: If service is failing, inspect BlueStore and FS permissions quickly

cr0x@pve1:~$ ls -ld /var/lib/ceph/osd/ceph-2
drwxr-x--- 5 ceph ceph 4096 Dec 26 08:40 /var/lib/ceph/osd/ceph-2

Meaning: Ownership looks normal. If it’s wrong (root:root or too restrictive), the OSD might crash early.

Decision: Fix permissions only if you can explain how they changed (package scripts, manual edits, restore). Otherwise you risk masking a deeper issue.

Task 18: Check Ceph crash reports for this daemon (often underused, very telling)

cr0x@pve1:~$ ceph crash ls | head
ID                                      ENTITY    NEW
2025-12-26_08:51:22.18342               osd.2     *
2025-12-20_14:11:03.22991               osd.7

cr0x@pve1:~$ ceph crash info 2025-12-26_08:51:22.18342 | sed -n '1,60p'
{
  "crash_id": "2025-12-26_08:51:22.18342",
  "entity_name": "osd.2",
  "utsname_hostname": "pve1",
  "assert_condition": "bdev_label_valid",
  "backtrace": [
    "ceph-osd(...",
    "libc.so.6(..."
  ]
}

Meaning: The crash is recorded and points to a label/BlueStore block device read problem. This supports the “disk path / IO” hypothesis.

Decision: Don’t treat it as “restart fixes it.” Plan hardware swap or BlueStore repair only if you know what you’re doing and have redundancy.

Disque vs réseau vs service : signes révélateurs

Le diagnostic le plus rapide repose sur la reconnaissance de motifs, appuyée par une ou deux commandes de confirmation. Voici les motifs qui comptent en production.

Indicateurs d’un problème disque/E/S

• L’OSD ne démarre pas avec des erreurs BlueStore, « Input/output error », ou « failed to read bdev label ».
• Les journaux du noyau montrent des réinitialisations/temporisations sur le périphérique sous-jacent (réinitialisation de lien SATA, temporisation NVMe, SCSI « rejecting I/O »).
• SMART montre des secteurs réalloués/pending ou un état global FAIL.
• L’OSD clignote sous charge (la récupération/backfill le déclenche). Les disques marginaux s’effondrent quand la charge monte.

Décision pratique : Si les journaux du noyau montrent des temporisations E/S, supposez du matériel défaillant jusqu’à preuve du contraire. Les redémarrages sont des soins palliatifs, pas un traitement.

Indicateurs d’un problème réseau

• Le processus OSD tourne mais Ceph le marque down ; les logs montrent « unable to talk to monitor » ou des timeouts de heartbeat.
• Plusieurs OSDs sont down sur différents hôtes autour du même moment.
• Perte/erreurs de paquets sur les interfaces orientées stockage ; les compteurs du switch augmentent ; le bonding clignote.
• MTU mismatch (jumbo partiellement activé) causant des fragmentations intermittentes ou des pertes silencieuses avec DF activé.
• Routage asymétrique (le réseau public fonctionne, le réseau cluster pas) conduisant à une connectivité partielle étrange.

Décision pratique : Corrigez la perte de paquets avant de « tuner Ceph ». Ceph ne peut pas reconfigurer la physique.

Indicateurs d’un problème de service/configuration

• systemd montre des échecs avec code de sortie sans erreurs E/S au niveau noyau (penser : auth, config, permissions, keyring manquant).
• Erreurs cephx dans le log OSD : « permission denied », « bad key », « authenticate timed out » (peut être réseau aussi, donc validez).
• OSD se lie à la mauvaise adresse après un renommage d’interface, un changement de bridge ou une refonte réseau.
• Décalage de version ou dérive de configuration après des upgrades partiels (fréquent pendant des fenêtres de changement où on n’a « eu le temps » que pour deux nœuds).

Décision pratique : Si c’est un problème de service/configuration, vous pouvez généralement le corriger sans remplacer le matériel—mais seulement après avoir confirmé que le chemin disque est stable et que le réseau est propre.

Approfondissements : voies rapides selon le mode de défaillance

1) Défaillances du chemin disque : le symptôme « OSD down » est le dernier domino

Les OSD Ceph tolèrent très bien la lenteur transitoire—jusqu’à ce qu’ils ne puissent plus. Une fois que les blocages E/S dépassent les tolérances de heartbeat, les monitors déclarent l’OSD down. Parfois le processus OSD est encore vivant, bloqué en E/S, donnant l’impression qu’il « tourne ». C’est pourquoi il ne faut pas s’arrêter au seul statut systemd.

Les défaillances du chemin disque se présentent sous plusieurs formes :

• Défaillance du média : secteurs réalloués/pending, erreurs non récupérables, retries de lecture, problèmes thermiques.
• Défaillance de transport : câble SATA/SAS défectueux, backplane marginal, bugs de firmware HBA, problèmes d’expander.
• Problèmes d’alimentation : rail PSU partagé ou alimentation backplane provoquant des réinitialisations sous charge.
• Effondrement des files d’attente : un disque qui « fonctionne » mais avec des pics de latence catastrophiques (le tueur du stockage distribué).

Que faire quand vous suspectez fortement un problème de chemin disque :

• Collectez les preuves (dmesg, SMART, logs OSD) une fois.
• Arrêtez le clignotement. Le clignotement augmente le churn de récupération, ce qui augmente la charge, ce qui aggrave le clignotement. C’est une boucle de rétroaction perverse.
• Décidez : garder in temporairement si ça revient vite et que vous devez éviter le rééquilibrage, ou marquer out si c’est réellement mort ou dangereux.

Conseil tranché : Si vous voyez des temporisations/réinitialisations répétées pour ce dispositif pendant plus de quelques minutes, marquez l’OSD out et planifiez le remplacement. Le garder in « pour voir si ça se stabilise » revient à parier avec la santé du cluster quand l’avantage de la maison est de 100 %.

2) Défaillances réseau : Ceph est un détecteur de latence qui stocke aussi des données

Ceph est impitoyable avec la latence parce qu’il doit l’être. Si les heartbeats et les messages sont retardés, il doit assumer une défaillance pour préserver la consistance. Cela fait de Ceph un excellent système d’alerte précoce pour les problèmes réseau—à condition de ne pas tirer sur le messager en redémarrant les démons jusqu’à ce que les compteurs se réinitialisent.

Défaillances réseau qui se présentent souvent comme un OSD down :

• Mauvaise MTU entre vmbr/bond, ports de switch ou interfaces VLAN.
• Mauvaise configuration du bonding (LACP sur l’hôte, statique sur le switch, ou inverse), causant des trous intermittents selon le hashing.
• Incohérences de tagging VLAN après des changements de switch.
• Règles de pare-feu bloquant les ports du messenger Ceph (6800–7300 typiques) ou les ports des monitors.
• Congestion et micro-bursts pendant la récupération/backfill.

Moyen rapide de séparer « réseau » de « blocage disque » quand les logs montrent des temporisations : regardez les journaux du noyau. Les blocages disque montrent souvent des messages de périphérique. Les problèmes réseau montrent souvent des paquets perdus, des flaps d’interface, des messages de bonding, ou rien du tout alors que Ceph se plaint. Dans ce dernier cas, regardez les compteurs d’interface et les journaux du switch.

3) Problèmes de service/configuration : les subtils

Les problèmes de service sont là où les humains causent le plus de dégâts parce qu’ils sont confiants. Le disque existe, le réseau pingue, donc l’OSD « devrait » démarrer. Mais Ceph n’est pas un seul binaire ; c’est un ensemble d’identités, keyrings, configs et mappings de périphériques. Brisez-en un, et vous obtenez un OSD qui refuse poliment de fonctionner.

Déclencheurs de service/config fréquents :

• Keyring manquant ou permissions incorrectes sous /var/lib/ceph/osd/ceph-ID/keyring.
• Permissions du répertoire OSD modifiées lors d’une réparation manuelle ou d’une restauration.
• Symlink de périphérique obsolète si les noms udev ont changé et que l’OSD pointe vers un chemin mort.
• Mises à jour partielles provoquant des incompatibilités messenger/protocole ou des hypothèses de config.

Les corrections de service doivent être réversibles. Si vous vous surprenez à « essayer des choses », arrêtez-vous et prenez un snapshot des faits : logs, config, mapping de périphériques. Puis changez une chose, validez, et poursuivez.

Blague #2 : Un OSD qui « a juste besoin d’un redémarrage » ressemble à une imprimante qui « a juste besoin d’un redémarrage »—ce n’est rarement toute l’histoire, juste la partie que vous pouvez faire sans outils.

Trois mini-récits du monde corporate (ce qui a mal tourné, ce qui a marché)

Mini-récit #1 : L’incident causé par une mauvaise hypothèse

Ils avaient un petit cluster Proxmox exécutant Ceph pour les disques de VM. Un OSD est tombé après un redémarrage de maintenance routinier. L’astreinte a regardé ceph -s, vu « 1 osd down », et a supposé que le disque était mort. Raisonnable… si vous aimez avoir tort efficacement.

L’équipe a marqué l’OSD out immédiatement pour « démarrer la récupération ». Cela a déclenché du backfill sur tout le cluster. L’utilisation du réseau a grimpé. La latence a grimpé avec elle. Puis deux autres OSDs ont commencé à clignoter sur d’autres nœuds. Le tableau de bord est devenu un sapin de Noël et les I/O clients ont commencé à stagner de façon intermittente.

La cause racine n’était pas les disques. Le redémarrage avait réordonné les noms d’interface sur cet hôte après une mise à jour du noyau, et la configuration Ceph public network pointait toujours vers l’ancien bridge. L’OSD a démarré, s’est lié à la mauvaise adresse, et est devenu effectivement inaccessible pour les pairs. La « panne disque » était l’histoire que les humains se racontaient parce qu’elle correspondait au symptôme.

Une fois qu’ils ont corrigé la liaison d’interface et redémarré l’OSD, il est revenu instantanément. Mais les dégâts étaient faits : le cluster était déjà en plein rééquilibrage. Ils avaient transformé un problème d’identité OSD en un incident de performance multi-OSD.

Ce qui a changé leur comportement ensuite fut une règle : ne jamais marquer un OSD out avant d’avoir validé des erreurs du chemin disque ou confirmé une isolation réseau soutenue. Cela leur a coûté cinq minutes et leur a économisé des heures par la suite.

Mini-récit #2 : L’optimisation qui s’est retournée contre eux

Une autre équipe voulait « plus de performance » et « moins d’overhead ». Ils ont activé les jumbo frames sur le réseau de stockage. Bonne intention. Ils ont mis à jour les bridges et bonds Proxmox à MTU 9000, mis à jour une paire de ports ToR, testé avec un ping basique, et déclaré victoire.

Des semaines plus tard, lors d’un événement de récupération intense (remplacement planifié d’un OSD), les OSDs ont commencé à tomber les uns après les autres. Les avertissements slow ops se sont accumulés. L’astreinte a vu des timeouts d’authentification monitor et a suspecté des problèmes cephx. Ils ont tourné les clés. Ils ont redémarré des démons. Ils ont même redémarré un monitor. Tout a empiré.

Le coupable était ennuyeux : un chemin switch intermédiaire avait encore MTU 1500 sur une des tranches VLAN. La plupart du trafic « fonctionnait » parce qu’il retombait sur de plus petits paquets, mais certains schémas de messenger Ceph sous charge ont commencé à rencontrer des contraintes de fragmentation. Le ping initial n’utilisait pas DF + grosse charge utile. L’optimisation a créé un mode de défaillance latent qui ne se déclenchait que sous stress—exactement quand vous voulez le moins de surprises.

Après avoir corrigé le MTU de bout en bout et standardisé leur validation (pings DF, compteurs d’interface, vérification des ports de switch), le clignotement s’est arrêté. Les performances se sont aussi améliorées, mais le vrai gain fut la prévisibilité.

Leçon : les optimisations qui reposent sur la justesse à plusieurs couches doivent être traitées comme des migrations de configuration, pas des ajustements. Validez comme un sceptique, pas comme un optimiste.

Mini-récit #3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation exécutait Ceph sur Proxmox avec une procédure de changement stricte que tout le monde se moquait jusqu’à ce que ça compte. Chaque disque OSD avait un mapping enregistré : baie châssis → numéro de série → chemin de périphérique Linux → ID OSD. Ils gardaient aussi un petit stock de disques de rechange identiques et avaient un runbook de remplacement testé.

Quand un OSD est tombé à 14h un mardi (le meilleur genre d’incident), l’astreinte n’a pas deviné. Ils ont exécuté ceph osd tree, mappé l’ID OSD au numéro de série via l’inventaire, puis confirmé avec ceph-volume lvm list et smartctl. SMART montrait des secteurs pending et les logs noyau montraient des réinitialisations. Pas de drame.

Ils ont marqué l’OSD out après confirmation de la panne, ont réglé les flags de récupération pour éviter de saturer les I/O clients, et ont remplacé le disque dans la baie correcte du premier coup. L’OSD de remplacement est monté, a backfillé, et le cluster est revenu à un état clean sans aucune réunion « où est ce disque ? ».

Pas d’héroïsme. Pas de commandes Ceph mystiques. Juste un inventaire précis et un runbook utilisé avant d’en avoir besoin.

Leçon : les pratiques ennuyeuses évoluent mieux que les gens brillants. Et ils dorment mieux.

Erreurs courantes (symptôme → cause racine → correction)

1) « L’OSD est down, donc le disque est mort »

Symptôme : ceph -s signale 1 OSD down ; les admins planifient immédiatement le remplacement du disque.

Cause racine : L’OSD tourne mais est inaccessible à cause d’un MTU mismatch, d’un problème VLAN ou d’une mauvaise adresse bind.

Correction : Comparez systemctl is-active ceph-osd@ID avec ceph osd tree. Si actif localement mais down dans le cluster, validez le MTU avec un ping DF, vérifiez les drops d’interface, et confirmez l’IP annoncée par l’OSD via ceph osd find.

2) « Redémarrer l’OSD va régler le problème » (amplificateur de clignotement)

Symptôme : L’OSD alterne up/down toutes les quelques minutes ; un redémarrage semble aider brièvement.

Cause racine : Blocages E/S ou réinitialisations de lien sous charge ; redémarrer ne fait que réinitialiser les timers et cache le vrai problème jusqu’au retour de la charge.

Correction : Vérifiez dmesg pour des réinitialisations/temporisations ; vérifiez SMART. Si des signaux matériels existent, arrêtez de redémarrer et planifiez un remplacement. Si des signaux réseau existent (drops/erreurs), corrigez le réseau d’abord.

3) Marquer un OSD out trop tôt

Symptôme : Un OSD down ; l’opérateur le marque out immédiatement ; la performance du cluster chute.

Cause racine : Le rééquilibrage/backfill démarre alors que le problème sous-jacent était transitoire ou réparable (par ex. mauvaise liaison de service). Le trafic de récupération surcharge le cluster, provoquant plus de temporisations.

Correction : Attendez assez longtemps pour confirmer la persistance (minutes, pas secondes), validez la catégorie, et limitez la récupération si l’I/O client est critique. Ne marquez out que lorsque vous êtes sûr que l’OSD ne reviendra pas vite.

4) Jumbo frames activés à moitié

Symptôme : Événements OSD down aléatoires pendant la récupération ; les pings fonctionnent ; les sessions TCP se réinitialisent sous charge.

Cause racine : MTU mismatch à travers bridges, bonds, VLANs ou trunks de switch.

Correction : Standardisez le MTU de bout en bout. Validez avec ping -M do -s 8972 entre tous les nœuds Ceph sur les réseaux concernés. Vérifiez aussi la configuration des switches.

5) Ignorer un disque « presque OK » qui a des pics de latence

Symptôme : Pas de SMART FAIL, mais des slow ops fréquents et des OSD down occasionnels.

Cause racine : Disque/HBA/backplane causant des longues latences intermittentes sans échec complet. Ceph punit la latence tail.

Correction : Utilisez les journaux noyau et les logs OSD pour le timing. Corrélez les événements down avec des blocages E/S. Envisagez de remplacer le composant suspect même sans un résumé SMART dramatique.

6) Changements de pare-feu ou ACL bloquant les ports Ceph

Symptôme : L’OSD démarre mais ne peut pas se connecter aux mons ; les logs montrent des timeouts ; le problème commence après un « durcissement de la sécurité ».

Cause racine : Ports monitor/messenger bloqués ou règles asymétriques entre les nœuds.

Correction : Vérifiez la reachabilité sur les ports requis depuis le nœud OSD vers les monitors et les pairs. Restaurez ou corrigez les règles. La cohérence compte plus que l’intelligence.

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

Checklist A: Triage « quoi est-ce ? » en cinq minutes

1. Exécutez ceph -s et ceph osd tree. Identifiez les IDs OSD et les hôtes.
2. Sur l’hôte : systemctl status ceph-osd@ID et journalctl -u ceph-osd@ID -n 80.
3. Sur l’hôte : dmesg -T | egrep -i 'I/O error|timed out|reset|rejecting I/O'.
4. Sur l’hôte : ip -s link sur les interfaces orientées Ceph ; cherchez des drops/erreurs.
5. Validez le MTU avec un ping DF entre les IP de stockage si les jumbo frames sont activées.

Checklist B: Si ça ressemble à du disque/E/S

1. Confirmez le mapping : ceph-volume lvm list --osd-id ID.
2. Vérifiez SMART : smartctl -a /dev/DEVICE.
3. Vérifiez les erreurs et réinitialisations noyau : dmesg -T.
4. Si confirmé en échec : planifiez le remplacement. Si le clignotement est sévère, marquez out pour stabiliser le placement.
5. Ralentissez la récupération si l’I/O client est critique (coordonnez avec votre équipe, n’improvisez pas en heures de pointe).

Checklist C: Si ça ressemble à du réseau

1. Vérifiez les compteurs d’interface (drops/erreurs) et l’état du lien.
2. Validez le MTU de bout en bout avec des pings DF.
3. Vérifiez l’état du bonding et la cohérence LACP ; assurez-vous que les esclaves ne clignotent pas.
4. Confirmez l’IP annoncée par l’OSD : ceph osd find ID.
5. Corrigez le réseau d’abord, puis redémarrez l’OSD une seule fois, pas dix.

Checklist D: Si ça ressemble à du service/config

1. Vérifiez systemd et les logs pour des erreurs cephx/config.
2. Validez la propriété et la présence du keyring dans le répertoire OSD.
3. Confirmez que les valeurs de config Ceph correspondent aux interfaces et routes réelles.
4. Vérifiez les mises à jour récentes et les décalages de version entre les nœuds.
5. Appliquez un changement à la fois, documentez ce que vous touchez, et restaurez si le symptôme change sans s’améliorer.

FAQ

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

Down est la détection de santé (les monitors ne reçoivent pas les heartbeats). Out modifie le placement CRUSH pour que le cluster cesse d’écrire là-bas et commence la récupération ailleurs.

2) Le service OSD est « active (running) » mais Ceph dit qu’il est down. Comment ?

Le processus peut être vivant mais inaccessible : mauvaise IP bind, isolation réseau, règles de pare-feu, MTU mismatch, ou perte sévère de paquets. Validez l’IP annoncée (ceph osd find) et les drops d’interface.

3) Dois-je redémarrer le service OSD lorsqu’il tombe ?

Seulement après avoir vérifié journalctl et dmesg. Si les logs noyau montrent des temporisations/réinitialisations E/S, redémarrer ne fait qu’aggraver la panne. Réparez le matériel d’abord.

4) Quand dois-je marquer un OSD out ?

Quand vous avez des preuves qu’il ne reviendra pas rapidement (panne matérielle, isolation réseau persistante) et que le garder in cause de l’instabilité. Marquer out déclenche du flux de récupération, donc faites-le délibérément.

5) Un seul disque défectueux peut-il faire tomber plusieurs OSDs ?

Oui, si plusieurs OSDs partagent un HBA, un expander, un backplane, ou si un hôte a des problèmes I/O systémiques. Aussi oui si votre « disque unique » est en réalité un domaine de défaillance partagé que vous n’aviez pas modélisé.

6) Pourquoi les OSDs tombent-ils plus souvent pendant la récupération/backfill ?

La récupération augmente la profondeur d’I/O et le trafic réseau. Des disques, HBAs, câbles ou ports de switch marginaux qui « fonctionnent bien » au repos peuvent s’effondrer sous vraie charge.

7) SMART suffit-il pour déclarer un disque sain ou mort ?

SMART est utile, pas omniscient. Un SMART FAIL est décisif. Un SMART PASS n’est pas une garantie, surtout pour les pics de latence et les problèmes de chemin contrôleur.

8) Comment distinguer un MTU mismatch d’une perte de paquets générale ?

Le MTU mismatch apparaît quand vous utilisez des pings DF avec de grosses charges utiles et recevez « Frag needed and DF set. » La perte de paquets générale se manifeste par des drops/erreurs en hausse et une perte de ping incohérente même pour de petits paquets.

9) Nous avons des réseaux public et cluster séparés. Lequel importe pour un OSD down ?

Les deux peuvent importer. Les OSDs parlent aux monitors sur le réseau public, et utilisent souvent le réseau cluster pour la réplication/backfill. Une défaillance sur l’un ou l’autre peut déclencher le comportement down selon la config et les schémas de trafic.

10) Quelle est la façon la plus sûre de collecter des preuves avant de changer quoi que ce soit ?

Récupérez : ceph -s, ceph health detail, ceph osd tree, systemctl status ceph-osd@ID, journalctl -u ceph-osd@ID, et dmesg -T. Cet ensemble identifie généralement la catégorie.

Prochaines étapes à réaliser réellement

Si vous voulez moins de surprises « OSD down », faites le travail peu glamour :

1. Standardisez votre triage rapide : faites du playbook ci‑dessus votre réflexe par défaut. La constance bat le génie.
2. Renforcez vos hypothèses réseau : validez le MTU de bout en bout, surveillez les drops, et traitez les VLANs de stockage comme des systèmes critiques de production (parce que c’en sont).
3. Inventoriez vos disques sérieusement : mappez ID OSD → numéro de série → baie. Le moment d’apprendre quel disque est lequel n’est pas durant une panne.
4. Réduisez les incitations au clignotement : arrêtez les redémarrages aveugles. Collectez des preuves, décidez disque vs réseau vs service, puis agissez une fois.
5. Entraînez-vous au remplacement d’OSD  quand rien n’est en feu. Le runbook que vous avez déjà utilisé calmement est celui que vous appliquerez correctement sous pression.

L’objectif n’est pas de devenir un sorcier Ceph. L’objectif est d’arrêter de perdre du temps à cause de mauvais diagnostics. Disque, réseau ou service : identifiez vite la bonne catégorie, et le reste devient de l’ingénierie méthodique au lieu d’une danse interprétative.