Performances de Ceph sur Proxmox lentes : 10 vérifications qui trouvent réellement le goulot d’étranglement

janvier 16, 2026 • février 3, 2026 • Lecture : 30 min • Views: 12

Cet article vous a aidé ?

Ceph sur Proxmox a un talent particulier : tout fonctionne bien jusqu’au jour où vous migrez quelques VM, lancez une sauvegarde, et soudain tout donne l’impression d’écrire sur une clé USB de 2009. Des pics de latence. L’iowait qui monte. Votre configuration « hyperconvergée » devient « hyper-inquiète ».

La solution est rarement mystique. Il s’agit le plus souvent d’un de dix goulots d’étranglement ennuyeux et mesurables — réseau, trafic de recovery, classes de disques mal assorties, métadonnées BlueStore mal dimensionnées, CPU sous-dimensionnés, ou une règle CRUSH qui vous déteste en silence. Allons le prendre sur le fait.

Feuille de route pour un diagnostic rapide

Vous voulez des réponses rapides, pas un week-end avec Grafana et des regrets. Voici l’ordre que j’utilise quand quelqu’un dit « Ceph est lent » et qu’une file de production se forme derrière lui.

Première étape : le cluster est-il unhealthy ou juste lent ?

Vérifiez l’état, les recovery et les opérations bloquées. Si recovery/backfill est en cours, vous ne diagnostiquez pas la performance — vous diagnostiquez une reconstruction.
Confirmez que les OSD sont up/in et que personne ne clignote (flapping).

Deuxième étape : est-ce le réseau ?

La plupart des plaintes « Ceph est lent » sont en réalité des problèmes de congestion réseau déguisés.
Recherchez des pertes, des retransmissions, des bizarreries de offload NIC, un MTU incohérent et des switches sur-engorgés.

Troisième étape : est-ce les disques/OSD ?

Vérifiez la latence de commit/apply des OSD, les opérations lentes de BlueStore, et si le DB/WAL se trouve sur le mauvais média.
Assurez-vous de ne pas avoir mis des OSD HDD dans la même règle CRUSH que des OSD SSD puis d’être surpris.

Quatrième étape : est-ce le chemin client (hôtes Proxmox/VMs) ?

Les nœuds Proxmox peuvent devenir un goulot sur le CPU, la pile réseau du noyau, ou trop de clients RBD.
Une mise en cache mal configurée, un ordonnanceur IO inadapté, ou des jobs de sauvegarde peuvent transformer « correct » en « plat ».

Si vous ne retenez qu’une chose : prouvez toujours si le goulot est réseau, media OSD ou recovery avant de toucher aux réglages. Tuner la mauvaise couche est la manière dont les incidents deviennent des « expériences d’apprentissage ».

Quelques faits (et historique) qui expliquent la douleur d’aujourd’hui

Le débogage des performances devient plus simple quand vous vous souvenez pourquoi Ceph se comporte ainsi.

L’objectif de conception de Ceph était la fiabilité à grande échelle — pas « IOPS maximum sur trois nœuds ». Il est né d’une recherche à UC Santa Cruz et a grandi en un système de stockage à l’échelle planétaire.
CRUSH (Controlled Replication Under Scalable Hashing) explique pourquoi Ceph peut placer les données sans un serveur méta central décidant de chaque emplacement. C’est excellent pour l’échelle, mais ça signifie que la topologie et les classes de périphériques comptent beaucoup.
RBD est Copy-on-Write au niveau bloc et aime la latence cohérente. Il reflétera absolument les micro-bursts et la gigue réseau dans la latence « disque » des VM.
BlueStore a remplacé FileStore pour supprimer le surcoût du système de fichiers et améliorer les performances, mais il a introduit la séparation DB/WAL — bien fait c’est rapide, mal fait c’est lent d’une manière très spécifique.
Le mode « replication 3 » par défaut de Ceph est un artefact culturel d’opérateurs qui préfèrent dormir la nuit. Vous payez cette sécurité avec une amplification d’écriture et du trafic réseau.
Les placement groups (PGs) sont un levier d’échelle, pas une superstition de tuning. Trop de PGs brûlent mémoire et CPU ; trop peu concentrent la charge et ralentissent la reconstruction.
Recovery et backfill sont des throttles intentionnels. Ceph essaie de continuer à servir les IO pendant la reconstruction, mais vous partagez toujours disques et réseau.
Le 10GbE a rendu Ceph courant dans les clusters « abordables ». Malheureusement, il a aussi généralisé la sur-souscription, et la sur-souscription est la source des latences mystérieuses.
Proxmox a rendu Ceph accessible via une UI conviviale — et a aussi facilité le déploiement de Ceph sans faire les devoirs ennuyeux sur le réseau et les disques.

Une idée paraphrasée à retenir, attribuée à Werner Vogels (mentalité fiabilité/ops) : tout finit par tomber en panne, alors concevez et exploitez en tenant compte des pannes comme normales. Le débogage de performance adopte la même mentalité : supposez que la contention est normale et prouvez d’où elle vient.

Les 10 vérifications (avec commandes, sorties et décisions)

Ce ne sont pas des « astuces ». Ce sont des vérifications avec un résultat clair : vous lancez une commande, lisez la sortie, puis choisissez une action concrète. C’est ainsi qu’on arrête de deviner.

Vérification 1 : Etat du cluster, recovery et ops lentes (la vérif « sommes-nous en reconstruction ? »)

Si le cluster est en recovery, votre « problème de performance » peut être un comportement attendu. Décidez d’attendre, de limiter la recovery, ou d’arrêter le job qui cause le churn.

cr0x@server:~$ ceph -s
  cluster:
    id:     9f1b2d9a-1b2c-4b9b-8d2d-2f7e5f0f2c1a
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 34 sec, daemons [osd.3,osd.7] have slow ops
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
    mgr: mgr1(active, since 2h)
    osd: 12 osds: 12 up (since 2h), 12 in (since 2h)
  data:
    pools:   4 pools, 256 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     220 active+clean
             36  active+clean+scrubbing
  io:
    client:   220 MiB/s rd, 55 MiB/s wr, 2.1k op/s rd, 900 op/s wr

Ce que cela signifie : « slow ops » indique généralement que les OSD ne suivent pas (disque) ou sont bloqués (réseau ou files internes). Le scrubbing apparaît aussi ; ce n’est pas mal, mais ce n’est pas gratuit.

Décision : Si les slow ops coïncident avec des fenêtres de scrub/recovery, planifiez le scrub hors heures et ajustez la QoS de recovery (vérifications plus loin). Si les slow ops apparaissent aléatoirement sous IO normal, poursuivez — c’est un vrai goulot.

cr0x@server:~$ ceph health detail
HEALTH_WARN 12 slow ops, oldest one blocked for 34 sec, daemons [osd.3,osd.7] have slow ops
[WRN] SLOW_OPS: 12 slow ops, oldest one blocked for 34 sec, daemons [osd.3,osd.7] have slow ops
    slow op 1, oldest at osd.3, committed, currently waiting for subops from [osd.7, osd.9]
    slow op 2, oldest at osd.7, waiting for BlueStore kv commit

Ce que cela signifie : « waiting for subops » sent le réseau/replication ; « waiting for BlueStore kv commit » sent le DB/WAL de BlueStore ou la latence du périphérique.

Décision : Séparez votre hypothèse : chemin réseau vs média OSD / métadonnées BlueStore.

Vérification 2 : Prouvez que le problème est dans Ceph, pas dans la VM ou le système de fichiers hôte

Les opérateurs aiment accuser Ceph. Parfois c’est justifié. Parfois la VM fait des writes 4k sync sur un FS avec barriers et vous regardez la physique en action.

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        98.00 GiB        22.16 GiB        70.80 GiB   22.61%
local-lvm     lvmthin     active       870.00 GiB       412.00 GiB       458.00 GiB   47.36%
ceph-rbd         rbd     active        21.00 TiB        13.10 TiB         7.90 TiB   62.38%

Ce que cela signifie : Confirme quelles VM sont réellement sur RBD. J’ai vu des tickets « Ceph est lent » où la VM était finalement sur local-lvm. Ce n’est pas un incident avancé ; c’est une chasse au trésor.

Décision : Si seuls certains workloads sont sur Ceph, comparez le comportement entre stockages avant de toucher au tuning Ceph.

cr0x@server:~$ rbd -p ceph-vm ls | head
vm-100-disk-0
vm-101-disk-0
vm-104-disk-0
vm-105-disk-0

Ce que cela signifie : Confirme que les images RBD existent et sont accessibles. Si cette commande est lente, cela peut indiquer une lenteur MON/MGR ou des problèmes réseau.

Décision : Les opérations métadonnées lentes vous orientent vers le réseau, le disque MON, ou une charge globale du cluster.

Vérification 3 : Notions réseau de base — latence, pertes, MTU incohérent (le tueur silencieux)

Ceph est un système de stockage distribué. Votre réseau est donc le bus de stockage. Traitez-le comme tel.

cr0x@server:~$ ip -s link show dev eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210 7123456      0   18422       0  112233
    TX:  bytes packets errors dropped carrier collsns
    8765432109 6234567      0       9       0       0

Ce que cela signifie : Des RX drops par dizaines de milliers ne sont pas « normaux ». Ce sont un symptôme. Sur des liens Ceph chargés, les pertes se traduisent souvent par des retransmissions, qui se traduisent en latence de queue, qui rendent vos propriétaires de VM mécontents.

Décision : Si les drops augmentent pendant les incidents, réparez le réseau avant de tuner Ceph. Vérifiez les buffers du switch, la sur-souscription, le flow control, et les pilotes NIC.

cr0x@server:~$ 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.
8980 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.321 ms
8980 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.309 ms
8980 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.315 ms
8980 bytes from 10.10.10.12: icmp_seq=4 ttl=64 time=0.311 ms
8980 bytes from 10.10.10.12: icmp_seq=5 ttl=64 time=0.318 ms

--- 10.10.10.12 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 0.309/0.315/0.321/0.004 ms

Ce que cela signifie : Les jumbo frames fonctionnent soit de manière cohérente de bout en bout, soit ce sont un piège. Ceci vérifie le MTU de chemin avec « do not fragment ».

Décision : Si vous voyez « Frag needed » ou des pertes, arrêtez. Corrigez la cohérence MTU sur NICs, bonds, bridges et switches. Un MTU mixte crée une forme particulière de misère de performance : ça marche un peu, lentement.

cr0x@server:~$ ss -ti dst 10.10.10.12 | head -n 12
ESTAB 0 0 10.10.10.11:6801 10.10.10.12:0
	 cubic wscale:7,7 rto:204 rtt:0.31/0.02 ato:40 mss:8960 pmtu:9000 rcvmss:8960 advmss:8960
	 bytes_sent:123456789 bytes_acked:123450000 bytes_received:9876543 segs_out:123456 segs_in:122999
	 retrans:12/3456 lost:0 sacked:123 fackets:12 reordering:0

Ce que cela signifie : Des retransmissions pendant un incident de latence sont une preuve flagrante. Pas toujours la cause racine, mais toujours pertinente.

Décision : Si les retransmissions augmentent sous charge, réduisez la sur-souscription, isolez le trafic Ceph, et vérifiez les buffers NIC et les réglages d’interruption. Ne « tunez pas BlueStore » pour corriger des pertes de paquets.

Blague #1 : Les jumbo frames sont comme les régimes : soit tout le monde les suit, soit vous obtenez des résultats bizarres et beaucoup de déni.

Vérification 4 : Les réseaux public et cluster sont-ils séparés (ou au moins ne se disputent-ils pas) ?

Proxmox facilite l’utilisation d’une même interface pour le trafic public Ceph et la réplication/backfill « juste pour l’instant ». « Juste pour l’instant » devient éternel.

cr0x@server:~$ ceph config get mon public_network
10.10.10.0/24

cr0x@server:~$ ceph config get mon cluster_network
10.20.20.0/24

Ce que cela signifie : Si cluster_network est vide, réplication et recovery partagent le même réseau que les clients. Ça peut aller dans de petits clusters, jusqu’à ce que ça ne le soit plus.

Décision : Si vous avez des NIC/VLAN séparés, configurez cluster_network. Sinon, envisagez de l’ajouter avant de chasser les micro-optimisations.

Vérification 5 : Surcharge de réplication/EC — payez-vous la durabilité deux fois ?

Les plaintes de performance viennent souvent d’attentes mal alignées. Quelqu’un voulait « des disques VM rapides », un autre voulait « trois copies sur des hôtes », et personne n’a chiffré la facture IO.

cr0x@server:~$ ceph osd pool ls detail
pool 1 'ceph-vm' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 128 pgp_num 128 autoscale_mode on
pool 2 'ceph-ct' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 64 pgp_num 64 autoscale_mode on
pool 3 'cephfs_data' erasure size 4+2 crush_rule 3 object_hash rjenkins pg_num 64 pgp_num 64 autoscale_mode on
pool 4 'cephfs_metadata' replicated size 3 min_size 2 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 autoscale_mode on

Ce que cela signifie : Un pool répliqué size 3 transforme chaque écriture en trois écritures sur le réseau et les disques. Les pools EC réduisent l’empreinte mais coûtent du CPU et peuvent augmenter la latence des petites écritures.

Décision : Pour des VM avec beaucoup de petites écritures aléatoires, les pools répliqués sont généralement la base raisonnable. Si vous utilisez EC pour des VM, faites-le parce que vous l’avez mesuré et acceptez les compromis.

cr0x@server:~$ ceph tell osd.* perf dump | head -n 20
{
  "osd": {
    "op_wip": 12,
    "op_latency": 0.018,
    "op_process_latency": 0.012,
    "op_r_latency": 0.006,
    "op_w_latency": 0.021,
    "subop_latency": 0.019
  }
}

Ce que cela signifie : Une augmentation de subop_latency par rapport à op_latency peut indiquer que les sous-opérations de réplication sont lentes — souvent le réseau, parfois des pairs lents (classes de disques mixtes, OSDs surchargés).

Décision : Si un sous-ensemble d’OSD a une latence bien pire, isolez-les : ils peuvent être sur des disques inférieurs, un firmware inadapté, ou des hôtes surchargés.

Vérification 6 : Classes de disques et règles CRUSH — arrêtez de mélanger SSD et HDD dans le même chemin de performance

C’est l’un des échecs « ça marchait en labo ». Quelques OSD HDD se glissent dans la règle d’un pool SSD, et maintenant chaque écriture atterrit parfois sur l’enfant lent du groupe.

cr0x@server:~$ ceph osd tree
ID  CLASS  WEIGHT   TYPE NAME         STATUS REWEIGHT PRI-AFF
-1         34.00000 root default
-3         11.33333     host pve1
 0   ssd    1.80000         osd.0         up  1.00000 1.00000
 1   ssd    1.80000         osd.1         up  1.00000 1.00000
 2   hdd    3.06667         osd.2         up  1.00000 1.00000
-5         11.33333     host pve2
 3   ssd    1.80000         osd.3         up  1.00000 1.00000
 4   ssd    1.80000         osd.4         up  1.00000 1.00000
 5   ssd    1.80000         osd.5         up  1.00000 1.00000

Ce que cela signifie : Vous avez des OSD HDD dans le même root que des SSD. Ce n’est pas automatiquement faux, mais c’est un risque si votre règle de pool ne contraint pas par classe.

Décision : Assurez-vous que la règle CRUSH du pool sélectionne uniquement SSD (ou uniquement HDD) selon l’intention. Si vous voulez des tiers mixtes, faites-le explicitement avec des pools et politiques séparés, pas par roulette accidentelle.

cr0x@server:~$ ceph osd crush rule dump replicated_rule
{
  "rule_id": 0,
  "rule_name": "replicated_rule",
  "type": 1,
  "steps": [
    { "op": "take", "item": -1, "item_name": "default" },
    { "op": "chooseleaf_firstn", "num": 0, "type": "host" },
    { "op": "emit" }
  ]
}

Ce que cela signifie : Cette règle ne filtre pas la classe de périphérique. Les HDD peuvent donc être choisis comme replicas même pour des pools majoritairement SSD.

Décision : Créez une règle basée sur la classe et déplacez les pools sensibles aux performances vers elle. Oui, c’est du travail. C’est moins de travail que d’expliquer des fsyncs à 200ms à une équipe base de données.

Vérification 7 : Placement et dimensionnement du DB/WAL BlueStore — vos « OSD SSD » peuvent quand même manquer de métadonnées

BlueStore utilise RocksDB pour les métadonnées (DB) et un WAL. Sur des médias rapides, le placement DB/WAL peut faire ou défaire la latence sur les petites écritures.

cr0x@server:~$ ceph-bluestore-tool show-label --dev /dev/sdb | head -n 30
{
  "osd_uuid": "f3b6b7b3-2a3a-4b7c-9b4c-1f2e3d4c5b6a",
  "size": 1920383410176,
  "btime": "2025-10-01T11:12:13.000000+0000",
  "description": "main",
  "whoami": "3"
}

cr0x@server:~$ ceph-volume lvm list | sed -n '1,80p'
====== osd.3 =======
  [block]       /dev/ceph-2c1a3b4d-.../osd-block-9a8b7c6d-...
      devices              /dev/sdb
  [db]          /dev/ceph-2c1a3b4d-.../osd-db-1a2b3c4d-...
      devices              /dev/nvme0n1
  [wal]         /dev/ceph-2c1a3b4d-.../osd-wal-5e6f7a8b-...
      devices              /dev/nvme0n1

Ce que cela signifie : Cet OSD a le block sur /dev/sdb (probablement SSD/SATA) avec DB/WAL sur NVMe, ce qui est généralement bon pour la latence. Si DB/WAL sont sur le même périphérique lent que le block pour des OSD HDD, vous le ressentirez.

Décision : Si vous avez des OSD HDD, envisagez fortement de placer DB/WAL sur SSD/NVMe. Si vous avez des OSD SSD mais voyez encore une latence de commit élevée, confirmez que le DB n’est pas sous-dimensionné ou contesté (plusieurs OSD partageant une petite partition NVMe).

cr0x@server:~$ ceph daemon osd.3 bluestore perf dump | head -n 40
{
  "kv_commits": 124567,
  "kv_commit_latency_ms": {
    "avgcount": 1024,
    "sum": 8345.21,
    "avg": 8.15
  },
  "deferred_write_ops": 0,
  "stall": 0
}

Ce que cela signifie : Une latence moyenne de commit KV d’environ 8ms peut être acceptable sur HDD, suspecte sur « tout NVMe », et catastrophique si elle monte à des dizaines/centaines de ms. Cela corrèle aussi avec les slow ops « waiting for BlueStore kv commit ».

Décision : Si la latence de KV commit est élevée, investiguez la saturation du périphérique DB, les réglages du cache d’écriture, et si vous poussez trop d’OSD sur un seul périphérique DB. Envisagez un reprovisionnement avec un dimensionnement DB correct et une isolation.

Vérification 8 : CPU, mémoire et ordonnanceur des OSD — quand le stockage est rapide, l’hôte devient le goulot

Ceph n’est pas que des disques. Les OSD calculent des checksums, compressent (si activé), gèrent le réseau et la comptabilité. Sur les petits clusters, un peu de starvation CPU devient beaucoup de latence de queue.

cr0x@server:~$ ceph tell osd.* dump_historic_ops | head -n 25
{
  "ops": [
    {
      "description": "osd_op(client.1234:5678 1.2e3f4b5c ::ffff:10.10.10.50:0/12345 1) [write 0~4096]",
      "duration": 1.238,
      "initiated_at": "2025-12-28T10:11:12.123456+0000",
      "age": 1.238
    }
  ]
}

Ce que cela signifie : Les ops prenant >1s ne sont pas normales pour des clusters SSD sains sous charge modérée. La description montre des writes 4k ; les petites écritures sync exposent la latence immédiatement.

Décision : Corrélez avec le CPU steal, la charge moyenne, et la contention des threads OSD sur le même nœud.

cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:22:01 up 12 days,  3:10,  1 user,  load average: 18.22, 16.90, 12.40
Tasks: 512 total,   2 running, 510 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28.1 us,  6.4 sy,  0.0 ni, 48.2 id, 15.9 wa,  0.0 hi,  1.4 si,  0.0 st
MiB Mem : 128000.0 total,   2200.0 free,  41200.0 used,  84600.0 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  82200.0 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8123 ceph      20   0 8421376 4.1g  120m S  220.0   3.3  92:12.34 ceph-osd

Ce que cela signifie : 15.9% iowait suggère des blocages de stockage, mais la moyenne de charge plus le processus OSD chaud suggèrent que le nœud est occupé. Si c’est un nœud hyperconvergé hébergeant beaucoup de VM, la contention CPU et IO est réelle.

Décision : Si OSD et VMs se disputent le CPU, réservez des ressources, réduisez la densité de VM, ou séparez les rôles. « Juste ajouter des réglages » n’est pas un plan de capacité.

cr0x@server:~$ cat /sys/block/sdb/queue/scheduler
mq-deadline none

Ce que cela signifie : Pour les SSD, mq-deadline est souvent un bon choix par défaut ; pour les HDD, le choix d’ordonnanceur compte plus. Pour NVMe, l’ordonnanceur compte souvent moins, mais « none » est acceptable.

Décision : Si vous observez une latence pathologique sur des OSD HDD, vérifiez que vous n’utilisez pas un ordonnanceur qui aggrave les tempêtes de seeks. N’attendez pas des miracles : Ceph sur HDD reste Ceph sur HDD.

Vérification 9 : Pression recovery/backfill/scrub — votre cluster mange ses légumes pendant le rush du midi

Le travail en arrière-plan de Ceph est bon. Il évite la perte de données. Il concurrence aussi les mêmes disques et réseau que vos clients.

cr0x@server:~$ ceph status | sed -n '1,30p'
  cluster:
    id:     9f1b2d9a-1b2c-4b9b-8d2d-2f7e5f0f2c1a
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
    mgr: mgr1(active, since 2h)
    osd: 12 osds: 12 up (since 2h), 12 in (since 2h)
  data:
    pools:   4 pools, 256 pgs
    pgs:     256 active+clean
  progress:
    Recovery event (35s)
      [============================..] (remaining: 9s)

Ce que cela signifie : Même avec HEALTH_OK, une recovery peut être active. Sur de petits clusters, un événement de recovery peut dominer les performances pendant des minutes à heures.

Décision : Si l’IO utilisateur est plus important que la rapidité de recovery en heures de bureau, limitez la recovery pendant les pics et planifiez les maintenances pour les gros rebalances.

cr0x@server:~$ ceph config get osd osd_recovery_max_active
3

cr0x@server:~$ ceph config get osd osd_max_backfills
2

Ce que cela signifie : Ces valeurs déterminent l’agressivité de recovery/backfill. Plus élevé = recovery plus rapide et pire latence client (généralement). Plus bas = plus doux pour les clients et reconstructions plus lentes.

Décision : Si votre cluster est petit et que l’IO utilisateur compte, restez conservateur. Si vous êtes dans un scénario de panne et avez besoin de redondance rapidement, augmentez temporairement — puis remettez après.

cr0x@server:~$ ceph config set osd osd_recovery_sleep 0.1

Ce que cela signifie : Ajouter un petit sleep de recovery peut lisser la latence client en donnant un peu d’air aux disques.

Décision : Utilisez ceci quand vous voyez des pics de latence induits par la recovery et que vous pouvez tolérer une reconstruction plus lente. Testez prudemment ; ne « set and forget » pas sans comprendre le temps de rebuild requis.

Vérification 10 : Benchmarkez la bonne chose — RADOS vs RBD, lectures vs écritures, sync vs async

Les benchmarks sont utiles quand ils répondent à une question précise. « Quelle est la vitesse de Ceph ? » n’est pas une question. « La latence d’écriture brute OSD est-elle acceptable ? » l’est.

cr0x@server:~$ rados bench -p ceph-vm 30 write --no-cleanup
hints = 1
Maintaining 16 concurrent writes of 4194304 bytes for at least 30 seconds.
Total time run:         30.422
Total writes made:      259
Write size:             4194304
Object size:            4194304
Bandwidth (MB/sec):     34.06
Stddev Bandwidth:       6.12
Max bandwidth (MB/sec): 45.01
Min bandwidth (MB/sec): 18.77
Average IOPS:           8
Stddev IOPS:            1
Average Latency(s):     1.932
Max latency(s):         5.221
Min latency(s):         0.412

Ce que cela signifie : Des écritures 4MB avec ~2s de latence moyenne sont un signal d’alerte sauf si le cluster est lourdement en recovery ou sur HDD avec contention extrême. Ce n’est pas du « tuning » ; c’est « quelque chose ne va pas ».

Décision : Si RADOS bench est mauvais, le problème est côté cluster (réseau/OSDs/recovery). Si RADOS bench est bon mais les disques VM sont lents, le problème est côté client (réglages RBD, pattern IO VM, contention hôte).

cr0x@server:~$ rbd perf image iostat --pool ceph-vm --image vm-100-disk-0 --interval 2 --count 5
rbd/image                         read_ops  read_bytes  write_ops  write_bytes  read_latency  write_latency
ceph-vm/vm-100-disk-0                  120     1.2MiB        340      24.0MiB        7.2ms        41.8ms
ceph-vm/vm-100-disk-0                  110     1.1MiB        360      25.5MiB        8.1ms        55.3ms
ceph-vm/vm-100-disk-0                   95   980.0KiB        390      28.3MiB        6.9ms        72.1ms
ceph-vm/vm-100-disk-0                  130     1.3MiB        310      22.1MiB        7.5ms        38.9ms
ceph-vm/vm-100-disk-0                  125     1.2MiB        320      23.0MiB        7.0ms        44.0ms

Ce que cela signifie : La latence écriture augmente tandis que la lecture reste stable. Cela pointe souvent vers la pression de réplication/commit, la contention DB/WAL, ou l’interférence de recovery.

Décision : Si c’est une seule image/VM : vérifiez le workload (DB sync-heavy, journaling). Si c’est beaucoup d’images : vérifiez la latence de commit des OSD et les retransmissions réseau.

Blague #2 : Faire un benchmark sans question, c’est comme tester la résistance d’une cafetière : vous apprendrez quelque chose, mais pas ce dont vous aviez besoin.

Trois mini-histoires d’entreprise issues des tranchées de la performance

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse (« 10GbE suffit »)

Ils avaient un cluster Proxmox propre, trois nœuds, Ceph replicat size 3, et une pile de switches 10GbE qui paraissait respectable sur les feuilles d’achat. L’hypothèse était simple : « 10GbE suffit pour notre workload ». Souvent c’est vrai — jusqu’à ce que ça ne le soit plus.

Le premier symptôme n’était pas une alerte Ceph. C’était le helpdesk : « Les VM gèlent une seconde pendant les sauvegardes. » Puis c’est devenu « les bases de données saccadent ». Les courbes de latence ressemblaient à un skyline. Le dashboard Ceph est resté majoritairement calme, car la santé n’était pas en cause. C’était la performance.

Nous avons relevé les compteurs d’interface et trouvé des RX drops qui montaient uniquement lors de deux événements : sauvegardes nocturnes et une fenêtre de scrub hebdomadaire. Le trafic de sauvegarde n’était même pas sur Ceph — du moins pas intentionnellement. Il partageait les mêmes uplinks bondés et les mêmes buffers de switch. Le trafic de réplication Ceph et le « backup vers NAS » se disputaient un couloir étroit.

L’hypothèse erronée était que la bande passante était la seule métrique. Le vrai coupable était la contention et les micro-bursts. Le trafic de réplication Ceph est en rafales ; le trafic de backup est soutenu ; mettez-les ensemble et vous obtenez une latence de queue qui rend les clients RBD tristes.

La solution était ennuyeuse : séparer correctement les réseaux (VLANs plus QoS sur le switch, finalement NICs dédiées), arrêter le scrubbing pendant les fenêtres de backup, et appliquer une politique empêchant que le trafic cluster partage le même point d’étranglement que les transferts en masse. L’incident de performance a disparu. Personne n’était impressionné, ce qui est le signe que c’était la bonne correction.

Mini-histoire 2 : L’optimisation qui a mal tourné (« Vite, augmentons la recovery »)

Chez une autre entreprise, humeur différente : ils détestaient voir « backfill » dans l’output Ceph. Après un reboot en boucle d’un nœud suite à une coupure, le cluster rééquilibrait. Quelqu’un a décidé d’« accélérer » en augmentant la concurrence de recovery et backfill.

Quelques minutes, tout avait l’air bien. Les barres de progression avançaient. Slack vibrait d’optimisme. Puis la latence VM a grimpé en flèche. Les applications ont commencé à timeout. Le cluster n’était pas unhealthy ; il était juste trop occupé à faire la bonne chose de façon trop agressive.

Ce qui s’est passé : ils ont transformé la recovery en workload prioritaire, involontairement. Le backfill a frappé les mêmes disques qui servaient l’IO client. Le réseau est devenu bruyant. Les files OSD se sont remplies. Les requêtes client n’ont pas échoué ; elles ont attendu. Et « attendre » c’est ce que les bases de données traduisent par « peut-être que le disque meurt ».

Nous avons reverté les réglages, ajouté un petit recovery sleep, et choisi une stratégie nuancée : recovery agressive uniquement pendant une fenêtre d’incident définie, conservative pendant les heures ouvrables. Ils ont tout de même récupéré rapidement la redondance — juste pas au prix de transformer la production en diaporama.

La leçon n’est pas « ne jamais tuner la recovery ». C’est « la recovery est un workload de performance ». Si vous ne la planifiez pas, elle vous planifie.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (« Règles CRUSH par classe et discipline de capacité »)

Une équipe a fait quelque chose peu à la mode : elle a gardé un design de stockage simple. Pools SSD et HDD séparés. Règles CRUSH par classe de périphérique. Pas d’héroïsme mix média. Ils ont aussi gardé de la marge : 70% d’utilisation était traité comme « se remplir », pas « plein de place ».

Quand un lot de SSD a commencé à montrer une latence élevée (pas en panne, juste bizarre), le cluster n’a pas implosé. Pourquoi ? Parce que les règles CRUSH empêchaient les HDD de devenir par erreur des replicas pour les pools VM sur SSD. Les workloads sensibles aux performances sont restés sur SSD. Les périphériques lents n’ont pas entraîné toute la queue de latence du pool.

Ils ont quand même dû agir : marquer les OSD suspects hors-service, remplacer les disques, laisser la recovery s’exécuter. Mais l’incident est resté contenu. Pas de tickets en cascade depuis des services non concernés. Pas de plan d’urgence « déplacer tout hors de Ceph ».

Ce qui les a sauvés n’était pas un sysctl magique. C’était l’hygiène de conception. Celle qui semble excessive jusqu’au jour où elle transforme une crise en une tâche de maintenance routinière.

Erreurs courantes : symptôme → cause racine → correction

C’est la partie où vous reconnaissez votre propre cluster et vous vous sentez un peu jugé. Bien. Les systèmes de production réagissent bien au jugement modéré.

1) Symptom : pics de latence d’écriture « aléatoires » sur beaucoup de VMs

Cause racine : pertes/retransmissions réseau, MTU incohérent, ou oversubscription de switch provoquant la latence de queue.
Correction : Vérifiez ip -s link, ss -ti, MTU bout en bout. Séparez trafic cluster/public. Réduisez l’oversubscription. Évitez de mélanger le trafic de backup sur les mêmes liens.

2) Symptom : les lectures semblent correctes, les écritures sont catastrophiques

Cause racine : goulot sur le chemin de réplication/commit : peers OSD lents, KV commits BlueStore, DB/WAL sous-dimensionnés, ou recovery qui interfère.
Correction : Inspectez les slow ops, la perf BlueStore, et les réglages de recovery. Déplacez DB/WAL sur des périphériques rapides ; limitez la recovery pendant les pics ; assurez-vous que la règle de pool évite les disques lents.

3) Symptom : « Ceph est lent » seulement pendant scrub/backfill

Cause racine : travail en arrière-plan qui concurrence pour le même IO et réseau.
Correction : Planifiez les fenêtres de scrub. Ajustez la concurrence recovery/backfill et ajoutez osd_recovery_sleep si nécessaire. Acceptez un temps de recovery plus long comme choix métier.

4) Symptom : une VM est terrible ; les autres vont bien

Cause racine : inadéquation du pattern de workload (DB sync-heavy, petites écritures aléatoires, fsync storms), ou l’image se trouve sur un PG/ensemble OSD très chargé.
Correction : Utilisez rbd perf image iostat. Vérifiez dans la VM les réglages du FS et de l’application. Envisagez de déplacer ce workload vers un pool à réglages différents ou vers un média plus rapide.

5) Symptom : performance dégradée après « ajout de capacité »

Cause racine : vous avez ajouté des disques plus lents dans la même règle CRUSH/pool, ou déclenché un fort rebalancing pendant un pic.
Correction : Règles CRUSH basées sur la classe. Ajoutez de la capacité dans une fenêtre contrôlée. Envisagez des reweights progressifs pour réduire le blast radius du rebalancing.

6) Symptom : la latence s’aggrave quand l’utilisation dépasse ~70–80%

Cause racine : fragmentation, réduction d’espace libre pour BlueStore/allocators, et comportements de placement/recovery plus coûteux au fur et à mesure que le cluster se remplit.
Correction : Gardez de la marge. Planifiez la capacité tôt. Ne faites pas tourner Ceph près de plein sauf si vous aimez les migrations d’urgence.

7) Symptom : les commandes Ceph sont lentes (status, ls, etc.)

Cause racine : latence disque MON, moniteurs surchargés, problèmes réseau, ou surcharge globale du cluster.
Correction : Vérifiez l’IO et le réseau des hôtes MON. Assurez-vous que les MONs tournent sur des médias fiables et ne sont pas affamés par des VMs sur le même nœud.

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

Plan de triage étape par étape (faites ceci dans l’ordre)

Capturez le moment : lancez ceph -s et ceph health detail. Sauvegardez la sortie avec un timestamp.
Confirmez l’étendue : quelles VMs, quel stockage, quels nœuds. Utilisez pvesm status et vérifiez où vivent les disques.
Vérifiez recovery/scrub : si actif, décidez de limiter ou d’attendre.
Compteurs réseau : ip -s link sur toutes les NIC Ceph, vérifiez drops et erreurs.
Sanity MTU : test MTU chemin avec ping -M do entre tous les nœuds sur les réseaux Ceph.
Retransmissions : ss -ti entre nœuds ; cherchez des retransmissions qui augmentent sous charge.
OSD outliers : identifiez les OSD avec pire latence via slow ops et perf dumps.
Classe disque et CRUSH : vérifiez que les pools utilisent les règles et classes correctes ; corrigez les mélanges accidentels.
DB/WAL BlueStore : confirmez le placement et vérifiez la latence de commit KV.
Benchmarquez de manière responsable : RADOS bench pour valider le cluster, puis RBD iostat pour valider le chemin client.

Checklist opérationnelle pour rester rapide (la routine ingrate)

Gardez l’utilisation du cluster confortablement en dessous de « plein ». Planifiez la capacité comme un adulte.
Séparez les réseaux public et cluster Ceph quand c’est possible, ou au moins isolez-les du trafic en masse.
Faites respecter les classes de périphériques et les règles CRUSH ; considérez le média mixte dans un pool comme un point de revue de conception.
Planifiez scrub et tâches lourdes de maintenance loin des sauvegardes et des workloads batch.
Documentez les réglages recovery/backfill et remettez-les après incidents.
Suivez les distributions de latence (p95/p99), pas seulement les moyennes. Les moyennes sont là pour vous surprendre.

FAQ

1) Pourquoi Ceph sur Proxmox est-il plus lent que du NVMe local ?

Parce que ce n’est pas la même chose. Le NVMe local est un appareil unique avec des accès à l’échelle de la microseconde. Les écritures Ceph sont distribuées, répliquées, et reconnues à travers le réseau et plusieurs OSD. Vous échangez de la latence contre de la disponibilité et de la flexibilité opérationnelle.

2) Ai-je vraiment besoin d’un réseau cluster séparé ?

Pas toujours, mais si vous avez de la latence imprévisible et un mélange d’IO client plus recovery/sauvegardes sur les mêmes liens, la séparation est l’un des correctifs à plus haut ROI. Si vous ne pouvez pas ajouter de NICs, la séparation VLAN plus QoS sur le switch reste meilleure que « tout partout ».

3) La taille de réplication 3 est-elle obligatoire ?

Non. C’est un défaut qui correspond à une posture de risque commune. Size 2 réduit l’amplification d’écriture mais augmente le risque et réduit la tolérance aux pannes. La bonne taille dépend des exigences métier, du nombre de nœuds, et de combien vous détestez les temps d’arrêt.

4) Dois-je utiliser l’erasure coding pour les disques VM ?

Généralement non pour des VM sensibles à la latence et aux petites écritures. L’EC est efficace pour l’espace et les objets larges, mais ajoute une surcharge CPU et peut pénaliser les petites écritures aléatoires. Si vous voulez EC pour des VM, mesurez avec votre workload réel et assumez la complexité.

5) Que signifie exactement « slow ops » ?

Cela signifie qu’une opération IO client prend plus de temps que prévu dans la pipeline OSD — en attente de sous-opérations, en attente de commits, en attente disque, ou bloquée derrière des files. Le détail fournit souvent un indice si c’est réseau/subop ou commit BlueStore.

6) Quelques disques lents peuvent-ils vraiment nuire à tout le pool ?

Oui. La réplication signifie que la latence d’écriture est souvent limitée par le replica le plus lent impliqué. Si votre règle CRUSH permet aux HDD de participer dans un pool pensé pour SSD, vous avez construit un générateur aléatoire de latence p99.

7) Pourquoi la performance chute pendant la recovery même si le cluster est « HEALTH_OK » ?

Parce que HEALTH_OK concerne la sécurité des données et les invariants du cluster, pas le SLO de latence de votre application. La recovery est un travail IO et réseau lourd ; Ceph peut rester correct tout en étant lent.

8) Combien d’OSD par nœud est « trop » ?

Ça dépend du CPU, de la RAM, du média et du réseau. Si les processus OSD sont à court de CPU ou si les périphériques DB BlueStore sont partagés trop agressivement, vous verrez la latence de commit et des slow ops. La bonne réponse vient de la mesure de latence par OSD et de la contention hôte, pas d’un chiffre magique.

9) Dois-je « juste ajouter plus de PGs » pour corriger des hotspots ?

Non, pas réflexivement. Le nombre de PGs affecte la mémoire, l’overhead de peering et le comportement de recovery. Utilisez l’autoscaling quand c’est approprié et n’ajustez manuellement que quand vous comprenez pourquoi la distribution est mauvaise.

10) Quel est l’indicateur le plus rapide pour distinguer « réseau » vs « disque » ?

Regardez les retransmissions/pertes pour le réseau et la latence de commit KV BlueStore plus les délais apply/commit des OSD pour le disque/métadonnées. Si les deux sont mauvais, félicitations : vous avez un vrai problème de système distribué.

Conclusion : prochaines étapes qui font bouger les choses

Si les performances Ceph-on-Proxmox sont lentes, ne commencez pas par changer des tunables. Commencez par prouver où le temps est passé. Exécutez la feuille de route de diagnostic rapide, puis réalisez les dix vérifications avec discipline : compteurs réseau, MTU, retransmissions, pression de recovery, classes de disques/règles CRUSH, placement DB/WAL BlueStore, et enfin des benchmarks ciblés.

Vos prochaines étapes pratiques :

Dans l’heure : capturez ceph -s, ceph health detail, les drops NIC, tests MTU, et retransmissions pendant la période lente.
Dans la journée : vérifiez que les règles de pool ne mélangent pas les classes de disques ; confirmez la séparation cluster/public ; auditez les horaires de recovery/scrub.
Dans la semaine : corrigez les problèmes structurels — DB/WAL sur les bons dispositifs, retirez les disques lents, et traitez la sur-souscription. Ne tunez qu’après que l’architecture ait cessé de se combattre elle-même.

Ceph peut être rapide. Il peut aussi être fiable. Mais il ne sera ni l’un ni l’autre si vous traitez le réseau comme une après-pensée et l’agencement des disques comme une suggestion.