Proxmox Ceph Slow Ops : localiser le goulot (disque, réseau ou CPU)

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

Cet article vous a aidé ?

« Slow ops » est la façon dont Ceph vous dit : quelque chose est bouché, et ça ne va pas se déboucher tout seul par politesse.
Dans Proxmox, cela apparaît généralement au moment où quelqu’un migre des VM, restaure une sauvegarde ou lance « juste » un petit clone.
Soudainement vous regardez des avertissements, des graphiques de latence qui ressemblent à un détecteur de mensonges, et des utilisateurs qui demandent pourquoi le « cloud » est lent.

L’astuce est d’arrêter de deviner. Un cluster Ceph est une chaîne : IO client → réseau → file OSD → disque → réplication/codage par effacement → accusés de réception.
Les « slow ops » arrivent là où cette chaîne se remplit. Votre travail est de trouver quelle étape et d’éliminer la contrainte, pas de parcourir au hasard les réglages.

Ce que signifient réellement les « slow ops » dans Ceph (et pourquoi Proxmox les affiche)

Dans Ceph, une « op » est une opération que le cluster doit accomplir : une lecture client, une écriture client, une requête de métadonnées, une étape de peering, un fragment de scrub,
une copie de backfill, une mise à jour de récupération. Quand Ceph alerte sur des « slow ops », il vous dit que certaines opérations ont dépassé un seuil de latence
et sont restées bloquées assez longtemps pour être considérées comme problématiques.

Crucialement, Ceph rapporte les slow ops du point de vue du démon qui attend.
Si un OSD attend son disque, il signale des slow ops. S’il attend des acquittements réseau, il signale des slow ops.
S’il est lié au CPU et ne peut pas planifier le travail, il signale des slow ops. Le symptôme est générique ; la cause ne l’est pas.

Proxmox affiche ces avertissements parce qu’il intègre les contrôles de santé Ceph dans l’interface de statut du cluster et les journaux. C’est utile… et dangereux.
Utile parce que vous êtes alerté tôt. Dangereux parce que beaucoup d’administrateurs le prennent pour un problème Proxmox. Ce n’est pas le cas. Proxmox est le passager.
Ceph est l’appareil. Si vous sentez de la fumée, ne blâmez pas la ceinture de sécurité.

Une citation qui doit vivre dans votre tête lors des incidents : « L’espoir n’est pas une stratégie. » — idée paraphrasée souvent attribuée au management des opérations.
(On évitera le terrier de l’attribution ; l’idée est ce qui compte : mesurer, puis agir.)

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

Premier : confirmer que c’est une vraie douleur, pas un bruit bénin

Vérifier la santé du cluster et où les slow ops sont signalés. Sont-elles sur un seul OSD, un seul hôte, ou partout ?
Vérifier la latence côté client. Si la latence IO des VM est stable et que les utilisateurs sont satisfaits, il se peut que vous observiez un bruit transitoire de récupération.
Vérifier si recovery/backfill/scrub fonctionne intensément. Beaucoup d’événements « slow ops » sont auto-infligés par des réglages de récupération.

Deuxième : identifier la classe de goulot (disque vs réseau vs CPU)

Goulot disque ressemble généralement à : latence commit/apply OSD élevée, forte utilisation du périphérique, longues latences NVMe/SATA, blocages BlueStore, contention WAL/DB.
Goulot réseau ressemble généralement à : RTT msgr élevé, pertes de paquets, retransmissions, latence inégale entre nœuds, switches saturés, mismatch MTU, une NIC saturée.
Goulot CPU ressemble généralement à : threads OSD en état runnable, temps système/softirq élevé, pics ksoftirqd, déséquilibre IRQ, beaucoup de changements de contexte, ceph-osd saturé.

Troisième : isoler la portée, puis arrêter l’hémorragie

Portée : un OSD ? un nœud ? un rack ? un pool ? un client ? Si c’est partout, suspectez le cœur réseau ou la pression de récupération globale.
Arrêter l’hémorragie : limiter la recovery/backfill, suspendre les scrubs pendant les heures de production, déplacer les VM chaudes, ou réduire temporairement la concurrence IO client.
Corriger : remplacer les disques défaillants, corriger le MTU, rééquilibrer les IRQ, séparer réseau public/cluster, déplacer DB/WAL BlueStore sur des périphériques rapides, ajuster les réglages de recovery raisonnablement.

Blague #1 : Les slow ops de Ceph sont comme des embouteillages : ajouter plus de voitures (clients) n’élargit pas la route, ça enrichit juste le vocabulaire d’erreurs de votre tableau de bord.

Faits et contexte intéressants (court, concret, utile)

L’objectif de conception de Ceph était « pas de point de défaillance unique », mais votre firmware NIC, les buffers du switch ou un SSD défectueux peuvent quand même créer un véritable point de douleur.
Le terme « OSD » vient d’object storage device, mais en pratique un OSD est un processus avec des files d’attente, des threads et un comportement de latence qui compte souvent plus que la vitesse brute du disque.
BlueStore a remplacé FileStore car l’approche « système de fichiers sur un système de fichiers » entraînait des surcoûts inévitables et une amplification d’écriture gênante sous charge.
Les monitors (MONs) de Ceph sont petits mais critiques : ils ne servent pas l’IO de données, pourtant la latence des MONs et les problèmes de quorum peuvent bloquer les opérations du cluster et provoquer des ralentissements en cascade.
La « recovery » est une fonctionnalité et une taxe : l’auto-guérison de Ceph est la raison pour laquelle vous l’avez choisi, mais la recovery concurrence l’IO client à moins que vous ne la gériez intentionnellement.
CRUSH (placement des données) est déterministe, ce qui est excellent pour la montée en charge, mais cela signifie aussi qu’une mauvaise description de topologie peut concentrer la charge de façon à créer des souffrances qui semblent aléatoires.
La pile réseau de Ceph (msgr) a évolué dans le temps, et les déploiements modernes utilisent souvent msgr2 ; des mauvaises configurations peuvent apparaître comme des pics de latence plutôt que des pannes évidentes.
Proxmox a rendu Ceph populaire dans les petites structures en simplifiant le déploiement ; c’est pratique jusqu’à ce que vous oubliiez que Ceph reste un système distribué avec des modes de défaillance distribués.

Modèle mental : où la latence se cache (disque, réseau, CPU, ou « travail Ceph »)

Si vous voulez déboguer les slow ops rapidement, arrêtez de penser « Ceph est lent » et commencez à penser « cette file d’attente grossit ».
Chaque slow op est une op qui est entrée dans une file d’attente et n’en est pas sortie à temps.

Goulots disque : le vilain ennuyeux

Les disques échouent bruyamment quand ils meurent. Ils peuvent aussi échouer silencieusement pendant des mois avant cela.
Les erreurs média ne sont pas nécessaires pour que la latence explose. Un disque peut être « sain » et avoir quand même des latences de queue (tail latency) de 50–200ms.
Pour Ceph, la latence tail compte parce que la réplication attend le plus lent des accusés requis.

BlueStore ajoute sa propre saveur : il utilise RocksDB pour les métadonnées, et il se soucie beaucoup du placement WAL/DB et des caractéristiques de latence des périphériques.
Si votre DB/WAL est sur le même périphérique lent que vos données, ou pire, sur un SSD SATA saturé, vous pouvez subir des blocages périodiques qui ressemblent à des problèmes réseau.

Goulots réseau : le vilain sournois

Ceph est bavard. Pas seulement en « j’envoie beaucoup d’octets » ; il exige aussi une latence prévisible et peu de pertes de paquets pour son protocole interne.
Un réseau peut avoir beaucoup de bande passante et être pourtant catastrophique s’il a des micro-bursts, des tempêtes de perte ou un mismatch MTU.

Aussi : votre « réseau public » (clients → OSDs) et votre « réseau de cluster » (réplication/backfill OSD) n’ont pas le même profil de trafic.
Les mélanger n’est pas interdit, mais vous vous exposez à de la contention. Si votre cluster est occupé, la réplication interne peut affamer l’IO client.

Goulots CPU : le vilain moderne

Avec le NVMe et des réseaux rapides, le prochain goulot est souvent le CPU : calculs de checksum, surcharge BlueStore, chiffrement, compression,
et le bon vieux traitement des interruptions. Un hôte peut afficher « seulement » 30% d’utilisation CPU globale et être pourtant saturé là où ça compte : un nœud NUMA,
un cœur traitant les IRQ de la NIC, ou quelques threads ceph-osd en état runnable.

Goulots « travail Ceph » : recovery, backfill, scrub, peering

Ceph effectue des travaux d’arrière-plan pour garder les données sûres et cohérentes. Ce travail est non négociable, mais son taux est négociable.
Des réglages de recovery agressifs peuvent faire paraître un cluster héroïque dans les dashboards tout en étouffant silencieusement l’IO client.
À l’inverse, une recovery trop timide laisse le cluster dégradé plus longtemps, augmente le risque et parfois le travail total.
Vous le gérez. Vous ne l’ignorez pas.

Tâches pratiques : commandes, interprétation de la sortie et décision

Ces tâches sont destinées à être exécutées depuis un nœud Proxmox avec les outils Ceph installés (ou un nœud admin dédié).
Chaque tâche inclut : la commande, un exemple de sortie, comment l’interpréter, et quelle décision prendre ensuite.
Ne lancez pas tout aveuglément en production pendant les heures de pointe. Lancez les bonnes commandes dans le bon ordre.

Task 1: Identify where Ceph thinks the problem is

cr0x@server:~$ ceph -s
  cluster:
    id:     9c6c2d4a-1c3b-4b8d-8a5e-2f2f3b2a7b61
    health: HEALTH_WARN
            17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 7d)
    mgr: mgr1(active, since 6d)
    osd: 36 osds: 36 up (since 7d), 36 in (since 7d)
  data:
    pools:   6 pools, 512 pgs
    objects: 4.8M objects, 18 TiB
    usage:   55 TiB used, 98 TiB / 153 TiB avail
    pgs:     510 active+clean
             2 active+clean+scrubbing
  io:
    client:   620 MiB/s rd, 210 MiB/s wr, 4.2k op/s rd, 1.9k op/s wr

Signification : L’avertissement nomme des démons spécifiques (osd.12, osd.31). C’est de l’or. S’il s’agit toujours des mêmes OSDs, suspectez l’hôte/le disque.
S’il tourne entre beaucoup d’OSDs, suspectez le réseau ou la pression de recovery globale.

Décision : Concentrez-vous d’abord sur les OSDs nommés. Ne commencez pas à toucher aux réglages du cluster avant de savoir si c’est localisé.

Task 2: Read the detailed health output (it contains the “blocked on” clue)

cr0x@server:~$ ceph health detail
HEALTH_WARN 17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
[WRN] SLOW_OPS: 17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
    osd.12 has 9 slow ops, oldest one blocked for 54 sec, committed 0, applied 0
    osd.31 has 8 slow ops, oldest one blocked for 42 sec, committed 0, applied 0

Signification : « committed 0, applied 0 » pointe souvent vers un blocage tôt dans le chemin d’écriture, fréquemment la latence disque/WAL/DB.
Si vous voyez des ops commises mais non appliquées, vous pouvez regarder un autre stade de la chaîne.

Décision : Vérifiez ensuite les compteurs de perf des OSD ; ne touchez pas encore à CRUSH ni aux réglages des pools.

Task 3: Check OSD commit/apply latency (fast signal for disk trouble)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
 12               87.23             132.71
 31               65.10             110.44
  7                2.11               3.05
  8                1.98               2.80
  9                2.45               3.40

Signification : Deux OSDs sont des ordres de grandeur plus lents que les autres. Ce n’est presque jamais un « tuning Ceph ». C’est généralement le chemin disque, le contrôleur,
le firmware, la mise en file d’attente, ou un problème de contention au niveau hôte.

Décision : Passez à l’investigation disque et CPU par hôte pour les hôtes hébergeant ces OSD IDs. Confirmez quel hôte les possède.

Task 4: Map OSD IDs to hosts (stop guessing where to log in)

cr0x@server:~$ ceph osd find 12
{
    "osd": 12,
    "ip": "10.20.10.12:6803/12345",
    "crush_location": {
        "root": "default",
        "host": "pve3"
    }
}
cr0x@server:~$ ceph osd find 31
{
    "osd": 31,
    "ip": "10.20.10.31:6809/23456",
    "crush_location": {
        "root": "default",
        "host": "pve7"
    }
}

Signification : Vous savez maintenant exactement quels nœuds Proxmox inspecter : pve3 et pve7.

Décision : Allez faire des vérifications locales à l’hôte : latence disque, erreurs de périphérique, ordonnanceur IO, gestion des IRQ, pertes NIC.

Task 5: Look for disk latency and saturation on the affected host

cr0x@server:~$ iostat -xz 1 5
Linux 6.8.12-pve (pve3)  12/26/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.24    0.00    6.18    9.80    0.00   71.78

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s  wrqm/s  %util  await  svctm
nvme0n1          42.0   310.0   1800   52600     0.0     0.0   98.7  24.10   0.32
sdb               0.2   120.4      4    2048     0.0     0.0   99.9  87.55   0.41

Signification : %util proche de 100% avec un await élevé hurle « mise en file d’attente du périphérique ».
NVMe à 24ms et SATA/SAS à 87ms d’await ne sont pas heureux pour un Ceph OSD. Notez aussi que %iowait n’est pas négligeable.

Décision : Identifiez quel OSD utilise quel périphérique. Si c’est un seul disque défaillant, planifiez un remplacement.
Si le DB/WAL est sur un périphérique saturé, repensez le placement.

Task 6: Confirm which block devices back the OSD (BlueStore mapping)

cr0x@server:~$ ceph-volume lvm list | sed -n '1,120p'
====== osd.12 =======
  [block]       /dev/ceph-4f3c7f9d-.../osd-block-1a2b3c4d-...
      devices              /dev/sdb
  [block.db]    /dev/ceph-4f3c7f9d-.../osd-db-9f8e7d6c-...
      devices              /dev/nvme0n1p3
  [block.wal]   /dev/ceph-4f3c7f9d-.../osd-wal-11223344-...
      devices              /dev/nvme0n1p3

Signification : Données sur /dev/sdb, DB/WAL sur la partition NVMe. C’est un schéma normal, mais uniquement si le NVMe n’est pas lui aussi surchargé par d’autres OSDs.

Décision : Si plusieurs OSDs partagent un petit périphérique DB/WAL, vous pouvez créer un goulot métadonnées même quand les disques de données vont bien.
Envisagez de dédier plus de capacité NVMe ou de réduire le nombre d’OSDs par périphérique DB.

Task 7: Check kernel logs for “quiet” drive failure signals

cr0x@server:~$ dmesg -T | egrep -i 'blk|nvme|scsi|ata|reset|error|timeout' | tail -n 20
[Thu Dec 26 10:14:02 2025] blk_update_request: I/O error, dev sdb, sector 112394232 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 10:14:02 2025] sd 3:0:8:0: [sdb] tag#218 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK
[Thu Dec 26 10:14:03 2025] sd 3:0:8:0: [sdb] rejecting I/O to offline device
[Thu Dec 26 10:14:05 2025] nvme nvme0: I/O 932 QID 7 timeout, aborting

Signification : Ce n’est pas « Ceph qui fait Ceph ». C’est le noyau qui vous dit que la pile de stockage se casse la figure.
Les timeouts et resets amplifient la latence et créent des slow ops.

Décision : Remplacez ou réinsérez le matériel ; vérifiez le firmware HBA ; déplacez l’OSD du périphérique suspect. Les réglages logiciels sont vains ici.

Task 8: Check Ceph’s own view of disk slowness per OSD (internal metrics)

cr0x@server:~$ ceph daemon osd.12 perf dump | egrep -i 'commit_latency|apply_latency|op_wip|op_queue|bluestore|kv|rocksdb' | head -n 30
    "op_wip": 128,
    "op_queue_age_hist": {
        "avgcount": 4312,
        "sum": 183.221
    },
    "bluestore_kv_commit_lat": 0.084,
    "bluestore_commit_lat": 0.132,
    "bluestore_state_deferred_write": 1

Signification : op_wip élevé signifie backlog. Latence commit BlueStore élevée. Si la latence de commit RocksDB monte, le périphérique DB/WAL est souvent en cause.

Décision : Si le backlog corrèle avec la latence de commit DB, regardez l’utilisation et la latence du périphérique DB et envisagez de déplacer DB/WAL vers des médias plus rapides ou plus nombreux.

Task 9: Determine whether recovery/backfill is the bully in the room

cr0x@server:~$ ceph -s | sed -n '1,120p'
  cluster:
    health: HEALTH_WARN
            17 slow ops, oldest one blocked for 54 sec, daemons [osd.12,osd.31] have slow ops
  data:
    pgs: 480 active+clean
         22 active+clean+remapped+backfilling
         10 active+recovering
  io:
    client: 620 MiB/s rd, 210 MiB/s wr
    recovery: 480 MiB/s, 120 objects/s

Signification : La recovery est intense. Cela ne veut pas dire automatiquement que c’est la cause, mais cela peut absolument amplifier le problème.

Décision : Si la latence client est prioritaire (heures de production), limitez temporairement la recovery/backfill.
Si la sécurité des données prime (redondance dégradée), vous pouvez accepter une latence client plus élevée mais surveillez l’impact utilisateur.

Task 10: Throttle recovery responsibly (and know what you changed)

cr0x@server:~$ ceph osd dump | egrep 'osd_recovery_max_active|osd_max_backfills|osd_recovery_sleep' | head
osd_recovery_max_active 3
osd_max_backfills 1
osd_recovery_sleep 0
cr0x@server:~$ ceph config set osd osd_recovery_max_active 1
cr0x@server:~$ ceph config set osd osd_max_backfills 1
cr0x@server:~$ ceph config set osd osd_recovery_sleep 0.05
cr0x@server:~$ ceph config get osd osd_recovery_max_active
1

Signification : Vous réduisez le travail de récupération parallèle et insérez de petites pauses. Cela stabilise souvent la latence client rapidement, au prix d’une guérison plus lente.

Décision : Si les slow ops disparaissent et que la latence client s’améliore, vous avez prouvé que la pression de recovery contribuait. Gardez-la limitée jusqu’à ce que le cluster soit clean, puis rétablissez.

Task 11: Check the network for drops and retransmits (don’t trust “link up”)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes  packets  errors  dropped  missed   mcast
    98765432109 123456789 0      124      0       1234
    TX:  bytes  packets  errors  dropped  carrier collsns
    87654321098 98765432  0      0        0       0
cr0x@server:~$ nstat -az | egrep 'TcpRetransSegs|IpInDiscards|IpOutDiscards'
TcpRetransSegs            18422
IpInDiscards              91
IpOutDiscards             0

Signification : Les drops RX et les retransmissions TCP corrèlent fortement avec les pics de latence Ceph, surtout sous charge de réplication.
Les pertes peuvent provenir d’une exhaustion des buffers côté hôte, d’une congestion de switch, d’un mismatch MTU provoquant de la fragmentation, ou d’un bond/LACP défectueux.

Décision : Si les pertes augmentent pendant les incidents, réparez le chemin réseau avant de toucher aux tunables Ceph. Vérifiez le MTU bout en bout et les compteurs du switch.

Task 12: Measure network latency between Ceph nodes (simple, but telling)

cr0x@server:~$ ping -c 20 -M do -s 8972 10.20.10.31
PING 10.20.10.31 (10.20.10.31) 8972(9000) bytes of data.
8972 bytes from 10.20.10.31: icmp_seq=1 ttl=64 time=0.385 ms
8972 bytes from 10.20.10.31: icmp_seq=2 ttl=64 time=0.401 ms
8972 bytes from 10.20.10.31: icmp_seq=3 ttl=64 time=3.912 ms
8972 bytes from 10.20.10.31: icmp_seq=4 ttl=64 time=0.392 ms
--- 10.20.10.31 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19022ms
rtt min/avg/max/mdev = 0.361/0.612/3.912/0.802 ms

Signification : Les jumbo frames fonctionnent (pas de « Frag needed »), mais le RTT max grimpe à ~4ms. Sur un réseau de cluster local, c’est suspect.
Des pics sans perte de paquets proviennent souvent de congestion ou de bufferbloat.

Décision : Si les pics RTT corrèlent avec les slow ops, examinez les files d’attente du switch, le QoS, et si le trafic public et cluster partage des uplinks sur-souscrits.

Task 13: Check CPU saturation and softirq pressure on an OSD host

cr0x@server:~$ mpstat -P ALL 1 5 | sed -n '1,80p'
Linux 6.8.12-pve (pve7)  12/26/2025  _x86_64_  (32 CPU)

01:22:10 PM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
01:22:11 PM  all  22.1  0.0  9.8   1.2    0.0  7.9    0.0   59.0
01:22:11 PM   3  18.0  0.0  12.2  0.9    0.0  28.1   0.0   40.8
01:22:11 PM   4  12.1  0.0  10.8  0.8    0.0  25.4   0.0   50.9

Signification : Le softirq est élevé sur des CPUs spécifiques. C’est souvent les interruptions NIC concentrées sur quelques cœurs.
Ceph peut sembler « lié au disque » alors qu’en réalité le CPU ne suit pas pour traiter les paquets.

Décision : Inspectez l’affinité IRQ et RPS/XPS. Envisagez d’isoler les NIC pour le trafic Ceph, d’activer le multiqueue et d’équilibrer les interruptions sur les cœurs.

Task 14: Check for one monitor or manager being slow (control-plane lag can amplify pain)

cr0x@server:~$ ceph mon stat
e3: 3 mons at {mon1=10.20.0.11:6789/0,mon2=10.20.0.12:6789/0,mon3=10.20.0.13:6789/0}, election epoch 98, leader 0 mon1, quorum 0,1,2 mon1,mon2,mon3
cr0x@server:~$ ceph time-sync-status
{
  "time_skew_status": {
    "mon1": "ok",
    "mon2": "ok",
    "mon3": "ok"
  },
  "timechecks": {
    "epoch": 98,
    "round": 21834,
    "round_status": "finished"
  }
}

Signification : Le quorum MON est stable et le décalage d’horloge est correct. Si le décalage horaire est mauvais, vous pouvez obtenir des comportements bizarres et des décisions retardées.

Décision : Si les monitors sont instables, corrigez la synchronisation temporelle et la contention des MONs d’abord. Un plan de contrôle instable rend le débogage du plan de données pénible.

Task 15: Verify whether a specific pool is suffering (crush rules, PG count, EC overhead)

cr0x@server:~$ ceph osd pool stats
pool rbd:     client_io 1200op/s rd, 800op/s wr, 410MiB/s rd, 190MiB/s wr
pool backups: client_io  50op/s rd,  30op/s wr,  20MiB/s rd,  15MiB/s wr
pool cephfs:  client_io 300op/s rd, 200op/s wr,  90MiB/s rd,  20MiB/s wr
cr0x@server:~$ ceph osd pool ls detail | egrep 'pool|crush_rule|size|min_size|pg_num|pgp_num'
pool 1 'rbd' replicated size 3 min_size 2 crush_rule 0 pg_num 256 pgp_num 256
pool 2 'backups' replicated size 2 min_size 1 crush_rule 0 pg_num 64 pgp_num 64

Signification : Le pool chaud est rbd en taille 3. C’est normal. Si les slow ops ne surviennent que pour un pool,
vous pourriez avoir une règle CRUSH qui place les données sur un sous-ensemble d’hôtes, ou un pool EC avec un surcoût CPU élevé.

Décision : Si un pool est le hotspot, validez les règles CRUSH et les classes de périphériques. Ne punissez pas tout le cluster pour la conception d’un seul pool.

Task 16: Correlate slow ops with PG states (peering/backfill can be the trigger)

cr0x@server:~$ ceph pg stat
512 pgs: 480 active+clean, 22 active+clean+remapped+backfilling, 10 active+recovering; 18 TiB data, 55 TiB used, 98 TiB / 153 TiB avail
cr0x@server:~$ ceph pg dump pgs_brief | egrep 'backfill|recover|peering|stuck' | head
1.2a0  active+clean+remapped+backfilling  [12,7,8]  12  12  1012  1012
1.2a1  active+recovering                  [31,9,10] 31  31  980   980

Signification : Les OSDs problématiques font partie de PGs qui backfill/recover activement. C’est une forte corrélation.

Décision : Si les slow ops sont conduits par la recovery, limitez-la (Tâche 10) et/ou marquez temporairement hors service l’OSD le plus problématique si le matériel défaillant est avéré.

Task 17: If a single OSD is sick, check its heartbeat and mark-out decision carefully

cr0x@server:~$ ceph osd tree | egrep 'pve3|osd.12|pve7|osd.31'
-3     2.91089 host pve3
 12    0.97030     osd.12  up  1.00000  1.00000
-7     2.91089 host pve7
 31    0.97030     osd.31  up  1.00000  1.00000
cr0x@server:~$ ceph osd out 12
marked out osd.12.

Signification : Marquer un OSD hors service déclenche un déplacement de données. Si vous le faites en période de pointe, vous pouvez échanger « slow ops » contre « tout est lent ».

Décision : Marquez hors service seulement quand vous avez des preuves de défaillance matérielle ou d’une latence pathologique persistante.
Si vous le faites, limitez la recovery et communiquez l’impact attendu.

Blague #2 : La seule chose plus lente que la recovery Ceph sur un cluster occupé est la réunion où quelqu’un suggère « augmentons juste le nombre de PGs. »

Mini-histoire #1 : l’incident dû à une mauvaise hypothèse

Une entreprise de taille moyenne exploitait Proxmox avec Ceph sur trois nœuds. Tout fonctionnait bien pendant des mois. Puis des « slow ops » sont apparues en heures de production,
surtout quand le job de sauvegarde se lançait. Les graphiques de stockage montraient beaucoup de marge d’IOPS — du moins sur le papier — donc l’équipe a supposé
que Ceph était « simplement trop sensible ».

La mauvaise hypothèse : « Si la bande passante est correcte, le réseau n’est pas en faute. » Ils avaient des liens 10GbE, et des tests iperf entre nœuds semblaient excellents
la nuit. Pendant l’incident, ils se sont concentrés sur les réglages BlueStore et la recovery, parce que c’est ce dont internet parle.
Les slow ops ont persisté et la latence des VM est devenue mauvaise.

Finalement, quelqu’un a fait la chose ennuyeuse : vérifier ip -s link sur le bond Ceph pendant la fenêtre de sauvegarde.
Les drops RX ont augmenté régulièrement. Pas peu. Suffisamment pour importuner. Les ports switch semblaient « up », mais leurs buffers étaient submergés par des micro-bursts :
trafic de sauvegarde, réplication Ceph et IO client partageaient le même uplink, et les files par défaut du switch n’étaient pas adaptées.

La correction fut peu glamour et décisive : séparer le trafic cluster Ceph du trafic public/client (VLANs et ports physiques),
réduire la concurrence des sauvegardes, et garantir la cohérence MTU bout en bout. Les slow ops ont cessé d’être un rituel quotidien.
L’équipe a appris une vérité douloureuse : le stockage distribué n’a pas besoin que votre réseau soit rapide ; il a besoin que votre réseau soit prévisible.

La note post-mortem qui comptait : ils avaient mesuré la bande passante réseau, mais pas la perte ni la latence tail sous charge production.
Ils ont testé l’autoroute à 2h du matin et l’ont jugée sûre pour l’heure de pointe.

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

Un autre atelier voulait accélérer la recovery après une maintenance de nœud. Ils ont lu que plus de concurrency de recovery améliore le temps de guérison,
alors ils ont augmenté les réglages de recovery sur tout le cluster et se sont sentis malins pendant environ une journée.

Puis un redémarrage d’OSD routinier s’est transformé en incident en semaine. La latence client a explosé. Les slow ops se sont accumulés. Le cluster est resté « up » techniquement,
ce qui a empiré la situation : les charges ne tombaient pas proprement ; elles ralentissaient jusqu’à ce que les timeouts et les retries rendent tout plus bruyant.
On a cru que les disques tombaient — jusqu’à ce qu’on réalise qu’ils allaient bien et que le cluster se noyait dans son propre zèle de recovery.

L’optimisation qui a échoué n’était pas « le tuning est mauvais ». C’était « le tuning sans limites est mauvais ».
Ils avaient pratiquement dit à chaque OSD de prioriser le travail de recovery à un niveau qui n’a de sens que lorsque le cluster est inactif.
En production, la recovery a concurrencé l’IO client à chaque étape : lectures pour copier les objets, écritures pour les placer, et réseau pour les répliquer.

La correction a été de traiter la recovery comme une charge planifiée. En heures ouvrées, la recovery était limitée.
Hors heures, elle pouvait tourner plus fort, mais toujours dans des limites observées sûres.
Ils ont aussi commencé à suivre « débit recovery vs latence client » comme un compromis SLO de première classe, pas comme une espérance vague.

La leçon : Ceph fera exactement ce que vous lui demandez — même si ce que vous demandez est « mets mon cluster de production en feu, mais de façon homogène. »

Mini-histoire #3 : la pratique ennuyeuse qui a sauvé la situation

Un environnement réglementé (audits, fenêtres de changement, et des gens qui aiment les tableurs) exploitait Proxmox+Ceph avec une discipline opérationnelle stricte.
Ils n’étaient pas excitants. Ils étaient, cependant, constamment en ligne.

Leur « pratique ennuyeuse » était une base hebdomadaire de latence et d’état : capturer ceph osd perf, iostat hôte, et compteurs de drops réseau
sous une fenêtre de charge connue. Ils n’optimisaient pas sans cesse. Ils surveillaient la dérive.
Quand une dérive était détectée — un OSD qui passait lentement de 2ms à 8ms de apply latency — ils agissaient tôt.

Une semaine, la baseline a signalé un hôte OSD avec des timeouts NVMe croissants dans dmesg, mais sans SMART encore en échec.
Ils ont drainé cet hôte, remplacé le NVMe dans une fenêtre planifiée, et évité un incident qui serait survenu pendant la clôture trimestrielle.
Un mois plus tard tout le monde l’avait oublié, ce qui est le plus grand compliment que l’on puisse faire à une maintenance.

Ils gardaient aussi les throttles de recovery comme une politique documentée, pas un savoir tribal. Quand un OSD tombait inopinément,
l’astreinte avait un bouton sûr déjà prêt à appliquer, plutôt que d’improviser sous pression.

La leçon est agaçante de constance : les opérations ennuyeuses ne sont pas de la paresse. C’est la discipline de ne pas apprendre la même leçon deux fois.

Erreurs courantes : symptômes → cause racine → correction

Ce ne sont pas des théories. Ce sont les erreurs qui se présentent à 3h du matin, le pager en guise de chapeau.

1) Slow ops sur quelques OSDs seulement

Symptômes : ceph osd perf montre 1–3 OSDs avec une latence commit/apply 10–100x plus élevée ; les avertissements nomment les mêmes démons.
Cause racine : Un disque défaillant, une voie HBA, un goulot DB/WAL partagé, ou un problème de contention au niveau hôte.
Correction : Mapper OSD → hôte/périphérique ; vérifier iostat et dmesg ; remplacer le matériel ou déplacer DB/WAL ; éviter le tuning cluster-wide.

2) Slow ops partout pendant recovery/backfill

Symptômes : Beaucoup d’OSDs signalent des slow ops ; les PGs montrent backfill/recovering ; le débit recovery est élevé ; la latence client augmente.
Cause racine : Concurrency de recovery trop agressive pour votre matériel/réseau ; mélange trafic client et cluster sur des liens oversubscrits.
Correction : Limiter recovery/backfill ; séparer les réseaux si possible ; planifier la recovery lourde hors heures ouvrées quand faisable.

3) Slow ops plus drops RX ou retransmissions

Symptômes : ip -s link montre des drops ; nstat montre des retransmissions TCP ; ping RTT spike sous charge.
Cause racine : Congestion, bufferbloat, mismatch MTU, hashing bond/LACP incorrect, bugs driver/firmware NIC, erreurs de port switch.
Correction : Vérifier le MTU bout en bout ; vérifier les compteurs du switch ; fixer le mode du bond ; équilibrer les IRQ ; envisager des réseaux Ceph séparés.

4) « Les disques semblent inactifs » mais Ceph est toujours lent

Symptômes : iostat montre un %util modéré ; la latence apply Ceph est élevée ; le softirq ou le temps système est élevé.
Cause racine : Goulot CPU (gestion d’interruptions, checksums, chiffrement), problèmes de localité NUMA, déséquilibre IRQ.
Correction : Rééquilibrer les interruptions ; vérifier le multiqueue ; réserver des cœurs suffisants pour Ceph ; éviter la surallocation CPU avec des VM sur les nœuds OSD.

5) Slow ops en pics sans erreurs évidentes

Symptômes : Le cluster est globalement correct, mais la latence se dégrade périodiquement ; aucune erreur disque claire.
Cause racine : Scrubs d’arrière-plan au mauvais moment, compactations RocksDB, ou VMs voisin bruyant saturant les ressources de l’hôte.
Correction : Programmer les scrubs ; assurer une marge pour les périphériques DB/WAL ; isoler le trafic Ceph ; placer prudemment les charges bruyantes.

6) « On a augmenté les PGs et les performances ont empiré »

Symptômes : Plus de PGs, plus d’utilisation mémoire, plus de surcharge CPU ; OSDs plus occupés ; augmentation des slow ops.
Cause racine : Nombre de PGs dépassant ce que le cluster peut gérer ; surcharge méta ; coûts de peering et maintenance accrus.
Correction : Utiliser un dimensionnement PG sensé ; réduire le nombre de PGs s’il est excessif ; se concentrer sur les goulots matériels et le placement, pas sur « plus de shards ».

7) Les « requêtes lentes » CephFS qui se déguisent en slow ops générales

Symptômes : Clients CephFS lents ; MDS signale des requêtes lentes ; RBD peut rester correct.
Cause racine : MDS sous-dimensionné en CPU/RAM, trop de caps, ou charge métadonnées intensive sans tuning.
Correction : Monter en capacité MDS, les positionner sur des hôtes fiables, et séparer le pool de métadonnées CephFS sur des périphériques plus rapides si nécessaire.

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

Checklist A: Triage en 10 minutes

Exécuter ceph -s et ceph health detail. Noter quels démons et l’âge de la plus ancienne slow op.
Exécuter ceph osd perf. Identifier si c’est localisé (quelques OSDs) ou systémique (beaucoup d’OSDs élevés).
Vérifier l’état des PGs avec ceph pg stat. Si recovery/backfill est actif, noter le débit de recovery.
Sur les hôtes affectés, exécuter iostat -xz 1 5 et ip -s link. Chercher await/%util élevés ou des drops.
Si vous voyez des erreurs/timeouts noyau dans dmesg, traitez-le comme du matériel jusqu’à preuve du contraire.

Checklist B: Décider « disque vs réseau vs CPU » avec des preuves

Cas disque : Haute latence commit/apply sur des OSDs spécifiques + await/%util élevé + erreurs/timeouts IO noyau. Remplacer ou migrer.
Cas réseau : Drops/retransmits + pics RTT sous charge + beaucoup d’OSDs affectés sur plusieurs hôtes. Corriger MTU, congestion, bonds, switching.
Cas CPU : Temps softirq/système élevé + concentration IRQ + disques rapides + réseau rapide mais slow ops toujours présents. Rééquilibrer IRQs et réduire la contention.
Cas pression de recovery : PGs backfilling/recovering + débit recovery élevé + pic de latence démarrant après un événement de panne. Throttler, puis guérir.

Checklist C: Actions sûres pour « arrêter l’hémorragie » (classées)

Limiter recovery/backfill (temporaire). C’est réversible et souvent immédiatement utile.
Pausеr les scrubs pendant les heures de pointe si le scrubbing contribue (puis les réactiver après).
Déplacer les VM les plus chaudes loin des hôtes OSD déjà en difficulté (réduire la contention noisy neighbor).
Marquer hors service un OSD clairement défaillant seulement quand vous avez des preuves solides. Puis contrôler le débit de recovery.
Ne pas redémarrer massivement les OSDs en espérant que « ça se remette ». Cela multiplie souvent le travail de recovery et transforme un avertissement en journée.

Checklist D: Améliorations structurelles (ce que vous faites hors incidents)

Séparer le trafic public et cluster Ceph si possible (NICs physiques ou au moins VLANs avec capacity planning).
Assurer un placement DB/WAL intentionnel : assez de NVMe, pas surchargés, et ne pas partager avec des workloads non liés.
Dimensionner correctement les hôtes OSD : CPU et RAM doivent avoir de la marge avec des médias rapides et 25/40/100GbE.
Baseliner et tracer : capturer hebdomadairement la latence OSD, la latence disque et les drops réseau. La dérive est votre système d’alerte précoce.
Standardiser la politique de recovery : throttles en heures ouvrées, accélération hors heures, étapes de rollback documentées.

FAQ

1) Les « slow ops » sont-ils toujours une urgence production ?

Non. Quelques slow ops pendant un événement de recovery contrôlé peuvent être acceptables. Si les slow ops persistent, s’amplifient, ou corrèlent avec des pics de latence IO des VM, traitez cela comme un incident.

2) Si un seul OSD montre une forte latence apply, est-il sûr de le redémarrer ?

Le redémarrage peut masquer temporairement un mauvais périphérique en vidant les files, mais cela ne corrigera pas la cause. Vérifiez d’abord dmesg et la latence du périphérique. Si le matériel semble suspect, planifiez un remplacement ou marquez-le hors service.

3) Quelle est la manière la plus rapide de différencier disque et réseau ?

Les problèmes disque apparaissent sur un petit ensemble d’OSDs avec une latence commit/apply extrême et un await périphérique élevé. Les problèmes réseau se manifestent par un impact plus large, des drops/retransmits et des pics RTT sous charge.

4) Séparer les réseaux public et cluster compte-t-il vraiment pour les petits clusters ?

Si le cluster est peu utilisé, on peut souvent s’en sortir avec un seul réseau. Dès que vous avez des sauvegardes lourdes, migrations ou événements de recovery, la séparation devient une fonction de fiabilité, pas un luxe.

5) Le CPU peut-il vraiment être le goulot si l’usage global n’est que de 30 % ?

Oui. Le traitement des IRQ et le softirq peuvent saturer quelques cœurs pendant que les autres sont inactifs. De plus, la localité NUMA et le comportement par-thread des démons peuvent créer une « saturation locale » masquée par la moyenne.

6) Dois-je augmenter les réglages de recovery pour guérir plus vite ?

Seulement après avoir mesuré l’impact sur les clients. Une recovery plus rapide est bonne, mais pas si elle transforme l’IO client en bouillie. Utilisez une politique : conservatrice en période de pointe, plus agressive hors heures, et vérifiez avec des métriques de latence.

7) Comment savoir si le DB/WAL BlueStore est mon goulot ?

Cherchez une latence commit BlueStore/RocksDB élevée dans ceph daemon osd.X perf dump, et vérifiez l’utilisation/latence du périphérique DB. Si le DB est partagé entre trop d’OSDs, c’est un point d’étranglement commun.

8) Est-il normal que la recovery cause des slow ops ?

Un impact modéré est normal. Un impact important indique généralement que la recovery concurrence trop agressivement l’IO client, ou que la capacité matériel/réseau est marginale pour vos réglages de réplication/EC.

9) Proxmox change-t-il le comportement de Ceph sous charge ?

Proxmox ne change pas les fondamentaux de Ceph, mais il influence les profils de charge (migrations, sauvegardes, snapshots) et la contention des ressources (VMs et OSDs partageant les mêmes hôtes). La physique reste la même.

10) Quel est le premier réglage sûr à toucher lors d’un incident ?

Limiter la recovery/backfill est souvent le changement réversible le plus sûr, surtout lorsque les slow ops surviennent après une panne et que des PGs se réparent activement. Ne « tunez » pas pour sortir d’un matériel défaillant.

Conclusion : prochaines étapes qui changent vraiment les résultats

Quand Ceph dit « slow ops », ce n’est pas une demande d’opinion. C’est une demande de mesures.
Commencez par la portée (quels démons), puis classez le goulot (disque, réseau, CPU, ou pression de recovery), puis agissez avec des contrôles réversibles avant de repenser quoi que ce soit.

Prochaines étapes pratiques :

Élaborez un petit runbook à partir du plan de diagnostic rapide et de la section Tâches. Placez-le où l’astreinte peut le trouver.
Baseliner ceph osd perf, iostat hôte et compteurs de drops réseau chaque semaine. Surveillez la dérive.
Décidez d’une politique de recovery et documentez-la (y compris comment revenir en arrière).
Si vous mélangez trafic public et cluster sur un réseau congestionné, planifiez la séparation. C’est l’équivalent d’acheter de la fiabilité avec une carte bancaire.
Si des OSDs spécifiques sont constamment plus lents, arrêtez de débattre. Remplacez le matériel ou corrigez la topologie des périphériques. Ceph a rarement tort sur l’OSD qui souffre.