Ceph sur Proxmox : quand ça vaut le coup, quand c’est un piège et comment bien le dimensionner

Quand Ceph sur Proxmox en vaut la peine

Ceph sur Proxmox vaut la peine lorsque vous avez besoin de stockage bloc partagé pour la virtualisation qui peut croître,
survivre aux pannes et être exploité sans verrouillage fournisseur. L’expression clé est « besoin », pas « ce serait cool ».

Ça colle quand ces affirmations sont vraies

• Vous avez besoin de HA + migration à chaud à grande échelle sans un SAN/NAS central massif.
• Vous pouvez dédier du vrai matériel (NVMe, CPU, RAM, réseau) au comportement stockage, pas seulement à la capacité.
• Vous attendez des pannes (un disque par mois, un hôte par trimestre) et vous voulez que le cluster encaisse.
• Vous pouvez faire fonctionner au moins trois nœuds (et de préférence plus) avec du matériel et du réseau cohérents.
• Votre charge est surtout des disques VM (RBD) avec des schémas d’E/S raisonnables, pas un défilé chaotique d’écritures synchrones.
• Vous avez de la discipline opérationnelle : monitoring, fenêtres de maintenance, contrôle du firmware et une personne responsable de la santé du stockage.

Ce que Ceph vous apporte et qu’il est difficile de simuler

La vraie valeur n’est pas « stockage distribué ». C’est la tolérance aux pannes prévisible et l’élasticité opérationnelle.
Quand vous ajoutez des nœuds, vous ajoutez capacité et performance. Quand un hôte meurt, les données restent. Quand un disque meurt, vous le remplacez
et Ceph rétablit l’état. Si vous le mettez en place raisonnablement, c’est ennuyeux — et c’est une bonne chose.

Si vous voulez une règle de décision en une phrase : Ceph en vaut la peine lorsque vous souhaitez que le stockage échoue comme un service, pas comme un appareil.

Quand c’est un piège (et quoi faire à la place)

Le piège est de penser que Ceph, c’est « trois serveurs et quelques disques ». C’est comme croire qu’un datacenter, c’est « une pièce et un peu d’électricité ».
Ceph est un système distribué. Il est sensible à la latence, gourmand en réseau pendant les récupérations, et extrêmement honnête sur la physique.

Signaux d’alerte qui signifient souvent « n’y allez pas »

• Deux nœuds ou « on ajoutera le troisième plus tard ». Ceph a besoin de quorum et de domaines de panne ; « plus tard » n’est pas une conception.
• 1GbE ou « le trafic stockage et VM partagent le même switch bon marché ». La récupération vous mangera tout cru.
• Matériel mixte où la moitié des nœuds sont vieux et l’autre moitié neufs. Les OSD les plus lents dictent le tempo lors des récupérations.
• Budget axé sur la capacité : beaucoup de HDD, des SSD minuscules, peu de RAM, peu de CPU.
• Bases de données à forte écriture avec des rafales fsync, ou des applis qui effectuent des écritures synchrones par transaction sans regroupement.
• Pas de temps opérateur. Si personne ne possède le stockage, le cluster finira par vous posséder.

Que faire à la place (alternatives réalistes)

• Laboratoire mono-nœud ou petit cluster : ZFS sur chaque nœud, répliquer avec ZFS send, accepter que la migration à chaud ne soit pas gratuite.
• Deux nœuds en production : utilisez un SAN/NAS partagé ou un troisième hôte témoin léger pour le quorum (mais ne simulez pas Ceph).
• Bases critiques en latence : NVMe local avec réplication au niveau applicatif ; ou un appliance de stockage dédié.
• Budget serré : moins de nœuds mais plus puissants vaut mieux que beaucoup de nœuds faibles. Ceph ne récompense pas « plus de matériel médiocre ».

Blague #1 : Ceph sur 1GbE est un excellent moyen d’apprendre la patience, la pleine conscience et comment expliquer « cohérence éventuelle » à des humains en colère.

Comment Ceph se comporte réellement sous des charges VM

Proxmox utilise typiquement Ceph RBD pour les disques VM. Cela signifie que vos lectures et écritures VM deviennent des opérations objet
sur des placement groups (PGs), répartis sur des OSDs, et répliqués (ou encodés en effacement) à travers des domaines de panne.
C’est élégant. C’est aussi implacable : chaque écriture devient plusieurs écritures.

Pools répliqués : la valeur par défaut pour une raison

Un pool répliqué avec size=3 écrit les données sur trois OSDs. Votre « écriture 1 Go » devient trois écritures plus du travail méta.
L’avantage est une faible amplification de lecture et une logique de reconstruction simple. Pour les disques VM, les pools répliqués restent le choix sensé.

Erasure coding : séduisant sur le papier, compliqué en pratique

L’EC économise de la capacité utilisable, mais augmente le coût CPU, le trafic réseau et l’amplification des petites écritures.
Cela peut fonctionner pour des charges séquentielles et volumineuses. Pour les disques de démarrage VM et les écritures aléatoires, cela devient souvent une machine à latence.
Utilisez EC avec prudence, en général pour les données froides, les sauvegardes ou des patterns d’objets — pas comme datastore principal VM.

BlueStore, WAL/DB et la « taxe des petites écritures »

Ceph moderne utilise BlueStore (pas FileStore). BlueStore a sa propre métadonnée (RocksDB) et utilise un WAL.
Sur des OSDs HDD, vous voulez ces composants DB/WAL sur SSD/NVMe, sinon vous payez la latence pour chaque opération riche en métadonnées.
Sur des OSDs tout-flash, garder DB/WAL sur le même périphérique est acceptable ; séparer peut aider mais n’est pas obligatoire.

La latence prime sur le débit pour la virtualisation

Les disques VM sont dominés par des E/S aléatoires petites, des mises à jour métadonnées et le comportement fsync selon le SE invité.
Si vous ne regardez que « GB/s » vous construirez un cluster qui affiche de bons benchmarks mais donne une mauvaise expérience.
Ce qui compte : la latence p95 pendant les opérations normales et pendant la récupération.

Une citation, parce que l’exploitation conserve des reçus

idée paraphrasée — Gene Kranz : « les systèmes robustes et compétents viennent de la discipline et de la préparation, pas de l’optimisme. »

Faits et contexte historique (parce que Ceph n’est pas apparu par hasard)

• Ceph a commencé comme projet de recherche à UCSC au milieu des années 2000, visant à éliminer les goulets métadonnées centralisés.
• Son algorithme CRUSH a été conçu pour éviter les tables de lookup et permettre de décider le placement à l’échelle sans coordinateur central.
• La couche RADOS de Ceph est le produit réel ; le bloc (RBD), le fichier (CephFS) et l’objet (RGW) sont des « clients » au-dessus.
• BlueStore a remplacé FileStore pour éviter la double journalisation via un système de fichiers POSIX et améliorer la constance des performances.
• CephFS a exigé un comportement stable des serveurs de métadonnées ; il a fallu des années avant qu’il soit considéré comme prêt pour la production dans les environnements conservateurs.
• Proxmox a intégré Ceph en profondeur pour rendre le stockage hyperconvergé accessible sans pile fournisseur séparée.
• Les placement groups existent pour regrouper le placement d’objets ; trop peu de PGs créent des goulets, trop en augmentent la surcharge.
• Les états de santé de Ceph (HEALTH_OK/WARN/ERR) sont volontairement francs pour que les opérateurs n’ignorent pas des problèmes « mineurs » jusqu’aux incidents.

Dimensionnement qui ne vous ment pas

Dimensionner Ceph consiste à faire correspondre la tolérance aux pannes, les objectifs de latence et le temps de récupération.
La capacité est la partie la plus simple — et la plus trompeuse. La bonne méthode est de raisonner à rebours depuis la charge.

Commencez par la seule question qui compte : que se passe-t-il si un nœud meurt ?

Quand un nœud meurt, Ceph va backfiller/rebalancer. Ça implique beaucoup de lectures depuis les OSDs survivants et des écritures vers d’autres.
Votre cluster doit survivre à cela tout en gardant les E/S VM tolérables. Si vous dimensionnez pour le « chemin heureux » seulement, la récupération devient la panne.

Nombre de nœuds : trois au minimum ; cinq pour commencer à être adulte

• 3 nœuds : utilisable, mais les domaines de panne sont serrés. La pression de récupération est intense ; la maintenance stressante.
• 4 nœuds : mieux, mais encore maladroit pour certains layouts CRUSH et plannings de maintenance.
• 5+ nœuds : récupération plus fluide, plus facile de mettre des nœuds hors service, meilleure distribution des PGs et des IO.

Réseau : traitez-le comme un backplane de stockage, pas comme « juste Ethernet »

Pour Ceph sur Proxmox, le réseau est le châssis. En IO normal, vous poussez du trafic de réplication. En récupération,
vous poussez une tempête. Si votre réseau est sous-dimensionné, tout devient « latence aléatoire » et la partie de blâme commence.

• Minimum viable : 10GbE, idéalement dédié ou séparé par VLAN pour le trafic public/cluster.
• Confortable : 25GbE pour des workloads mixtes, ou 10GbE pour de petits clusters tout-flash avec réglages soignés.
• Switches : non-bloquants, faible douleur de buffering, MTU cohérent et pas de politiques QoS « mystère ».

Médias OSD : tout-flash est plus simple ; les HDD nécessitent un soutien SSD/NVMe

Si vous exécutez du stockage VM sur des OSDs HDD, vous choisissez un monde où la latence d’écriture aléatoire est votre compagne constante.
Vous pouvez le rendre utilisable avec des SSD/NVMe pour DB/WAL, assez de spindles et des attentes réalistes. Mais ne prétendez pas que cela ressemblera à du flash SAN.

Profils matériels règle-de-pouce (pratiques, pas théoriques)

• Petit cluster VM tout-flash (3–5 nœuds) : 8–16 NVMe par nœud ou moins mais de grande capacité entreprise ; 128–256GB RAM ; 16–32 cœurs ; 25GbE si possible.
• Hybride (HDD capacité + SSD métadonnées) : 8–16 HDD par nœud plus 1–2 NVMe pour DB/WAL ; 128GB+ RAM ; 25GbE fortement recommandé.
• « On a trouvé des disques dans un placard » : ne le faites pas.

CPU et RAM : Ceph utilisera volontiers ce que vous lui refusez

Les OSDs consomment du CPU pour les checksums, la compression (si activée), les calculs EC (si utilisés) et les pipelines IO généraux.
Les MONs et MGRs ont besoin de mémoire pour garder les maps de cluster et servir les clients sans blocage.

• RAM : prévoyez mémoire pour les OSDs + overhead hôte + Proxmox. Affamer l’hôte provoque du jitter qui ressemble à un « bug Ceph » ou réseau.
• CPU : ne pas surconsommer au point que les threads OSD soient préemptés sous charge VM. Les spikes de latence sont le symptôme.

Maths de capacité qui reflètent la réalité

Pour les pools répliqués, la capacité utilisable est approximativement : raw / replica_size, moins les overheads.
Replica size 3 signifie environ un tiers utilisable. Puis réservez une marge : Ceph a besoin d’espace libre pour déplacer des données pendant panne et récupération.

• Objectif : garder les pools sous ~70–75% en steady state si vous tenez à vos week-ends.
• Pourquoi : la récupération et le backfill nécessitent de l’espace libre sur les OSDs ; les clusters presque pleins amplifient la douleur du rebalance et le risque.

Dimensionnement IOPS et latence : la partie inconfortable

Vous dimensionnez Ceph en comprenant les schémas d’E/S :

• Petites écritures aléatoires : punissent les clusters HDD et les réseaux sous-dimensionnés.
• Écritures synchrones (fsync) : révèlent le journal/WAL et la latence du périphérique ; les invités qui font des DB peuvent dominer le comportement du cluster.
• Lectures : généralement plus faciles, mais les lectures hors-cache et la récupération peuvent aussi faire mal.

Si vous ne pouvez pas mesurer la charge, supposez qu’elle est pire que prévu. Les charges de production le sont toujours.

Pools, CRUSH et décisions de placement des données

Taille des pools répliqués : choisissez la panne que vous voulez survivre

La plupart des déploiements Proxmox utilisent size=3, min_size=2. Cela survit généralement à une panne de nœud sans basculer en lecture seule.
Tomber à size=2 est tentant pour la capacité. C’est aussi une régression de fiabilité qui devient souvent une panne surprise lors d’une deuxième défaillance.

Domaines de panne : hôte, châssis, rack

Les règles CRUSH décident où atterrissent les répliques. Si votre domaine de panne est « hôte » mais que vos trois nœuds partagent une même multiprise,
votre domaine de panne réel est « multiprise ». Concevez votre agencement physique comme si vous le pensiez vraiment.

Nombre de PG : ne pas tuner à la main comme en 2016

L’autoscaling des PG existe pour une raison. Pourtant, il faut comprendre la pression des PG :
trop peu de PGs peut créer des hotspots ; trop de PGs peut surcharger la mémoire et le CPU des OSDs.
Utilisez l’autoscaler, puis vérifiez la distribution et la performance.

Séparez les pools par classe de performance, pas par intuition

• Pool rapide : OSDs NVMe tout-flash pour les VMs sensibles à la latence.
• Pool capacité : HDD+SSD DB/WAL pour le stockage massif, workloads moins sensibles.
• Ne pas mélanger : intégrer une classe d’OSD lente dans le même pool freine les IO clients pendant la récupération et le peering des PGs.

Tâches pratiques : commandes, sorties, ce que ça signifie, ce que vous décidez

Voici les vérifications que je lance quand quelqu’un dit « Ceph est lent » ou « Ceph est bizarre ».
Chacune inclut : commande, sortie exemple, ce que la sortie signifie, et la décision à prendre.

Task 1 — Confirmer la santé du cluster et le vrai titre

cr0x@server:~$ ceph -s
  cluster:
    id:     2c8c8b9a-1c61-4a9f-9a19-4c0d7cfe2a91
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops

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

  data:
    pools:   2 pools, 256 pgs
    objects: 1.12M objects, 4.3 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     254 active+clean
             2  active+remapped+backfilling

Signification : Pas « tout est cassé ». C’est un OSD avec des slow ops et un backfill en cours.

Décision : Considérez les plaintes de performance comme normales pendant le backfill ; investiguez pourquoi osd.7 est lent (disque, CPU, réseau).

Task 2 — Vérifier si vous êtes en récupération/backfill

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops; 2 pgs backfilling
SLOW_OPS 1 slow ops, oldest one blocked for 23 sec, osd.7 has slow ops
PG_BACKFILLING 2 pgs backfilling

Signification : Activité de récupération présente ; la latence client peut chuter.

Décision : Décidez si vous bridez temporairement la récupération ou si vous laissez faire ; vérifiez si le backfill est attendu (redémarrage OSD récent, remplacement de disque).

Task 3 — Identifier quel OSD est le vilain (ou la victime)

cr0x@server:~$ ceph osd perf
osd  commit_latency(ms)  apply_latency(ms)
  0                  6                 7
  1                  5                 6
  7                120               145
  8                  7                 8

Signification : osd.7 est bien plus lent que ses pairs ; ce n’est pas « Ceph est lent », c’est « un composant est lent ».

Décision : Investiguer la santé du disque, la saturation ou les erreurs réseau de l’hôte d’osd.7 ; envisager de le marquer out s’il nuit au cluster.

Task 4 — Vérifier l’arbre OSD et s’assurer que la topologie reflète la réalité

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.33333         osd.0      up   1.00000  1.00000
 1    ssd   1.33333         osd.1      up   1.00000  1.00000
 2    ssd   1.33333         osd.2      up   1.00000  1.00000
-5         11.33333     host pve2
 7    ssd   1.33333         osd.7      up   1.00000  1.00000
 8    ssd   1.33333         osd.8      up   1.00000  1.00000
 9    ssd   1.33333         osd.9      up   1.00000  1.00000

Signification : Classe et poids des OSDs cohérents. Si vous voyez des poids très différents, vous aurez des données et IO inégales.

Décision : Si un hôte a moins d’OSDs/poids, attendez des hotspots ; planifiez une expansion ou un reweight.

Task 5 — Vérifier l’état de l’autoscaler de PG

cr0x@server:~$ ceph osd pool autoscale-status
POOL     SIZE  TARGET SIZE  RATE  RAW CAPACITY  RATIO  TARGET RATIO  PG_NUM  NEW PG_NUM  AUTOSCALE
rbd         3            -   3.0       34 TiB   0.65             -     128         192  on
cephfs      3            -   3.0       34 TiB   0.10             -     128          64  on

Signification : L’autoscaler suggère que rbd a besoin de plus de PGs (plus de parallélisme), alors que cephfs pourrait en avoir moins.

Décision : Acceptez les changements de l’autoscaler pendant les périodes calmes ; évitez des vagues massives de PG pendant des incidents.

Task 6 — Vérifier les réglages de pool qui affectent la latence VM

cr0x@server:~$ ceph osd pool get rbd size
size: 3
cr0x@server:~$ ceph osd pool get rbd min_size
min_size: 2
cr0x@server:~$ rbd pool stats rbd
Total Images: 124
Total Snapshots: 37
Provisioned Size: 19.7 TiB
Total Used Size: 6.2 TiB

Signification : La réplication est réglée pour une HA typique. Provisioned vs used aide à repérer le risque de thin-provisioning.

Décision : Si le provisioned approche la capacité utilisable, appliquez des quotas ou étendez avant que le backfill devienne impossible.

Task 7 — Valider la santé réseau sur les interfaces Ceph

cr0x@server:~$ ip -s link show eno2
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed  mcast
    9123489123  8123492       0        3       0      0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    8451239912  7923341       0        0        0      0

Signification : Les erreurs sont à zéro ; quelques drops peuvent être tolérables, mais une montée des drops sous charge peut indiquer congestion ou problèmes de buffers.

Décision : Si erreurs/drops augmentent, cessez d’accuser Ceph et commencez à déboguer les ports switch, le mismatch MTU ou la saturation.

Task 8 — Confirmer la cohérence MTU (tueur silencieux)

cr0x@server:~$ ip link show eno2 | grep mtu
2: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000

Signification : L’interface a une MTU jumbo. C’est acceptable seulement si tout le chemin la supporte.

Décision : Si certains nœuds sont en 1500 et d’autres en 9000, choisissez une valeur et standardisez ; des MTU incohérentes provoquent des latences étranges et de la fragmentation.

Task 9 — Vérifier la saturation d’E/S hôte (le disque est-il saturé ?)

cr0x@server:~$ iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   980.0  2400.0  8820.0   2.1   0.3   34.0
sdb              10.0   320.0   160.0  5120.0  48.0   2.5   98.0

Signification : sdb est quasiment à 100% d’util avec un await élevé. Si c’est un périphérique OSD, il provoquera des slow ops.

Décision : Si des OSDs HDD sont saturés, réduisez le débit de récupération, déplacez les workloads chauds vers un pool flash, ou ajoutez des spindles/nœuds.

Task 10 — Inspecter un daemon OSD spécifique pour stalls ou erreurs device

cr0x@server:~$ systemctl status ceph-osd@7 --no-pager
● ceph-osd@7.service - Ceph object storage daemon osd.7
     Loaded: loaded (/lib/systemd/system/ceph-osd@.service; enabled)
     Active: active (running) since Sun 2025-12-28 08:12:11 UTC; 2h 3min ago
   Main PID: 23871 (ceph-osd)
      Tasks: 92
     Memory: 5.1G
        CPU: 1h 12min
     CGroup: /system.slice/system-ceph\x2dosd.slice/ceph-osd@7.service
             └─23871 /usr/bin/ceph-osd -f --cluster ceph --id 7 --setuser ceph --setgroup ceph

Signification : L’OSD tourne ; l’utilisation mémoire est visible. Cela n’atteste pas de sa santé, mais écarte « il est down ».

Décision : Si le CPU est faible mais la latence élevée, suspectez des waits disque ou IO ; vérifiez les logs et les stats device.

Task 11 — Chercher des problèmes disques au niveau noyau

cr0x@server:~$ dmesg -T | tail -n 8
[Sun Dec 28 09:55:14 2025] blk_update_request: I/O error, dev sdb, sector 219902314
[Sun Dec 28 09:55:14 2025] Buffer I/O error on dev sdb, logical block 27487789, async page read
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] tag#19 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Sense Key : Medium Error [current]
[Sun Dec 28 09:55:15 2025] sd 2:0:5:0: [sdb] Add. Sense: Unrecovered read error

Signification : Le disque est en échec. Ceph tentera de compenser, mais votre latence sera horrible et la récupération peut thrash.

Décision : Marquez l’OSD out, remplacez le disque et planifiez la fenêtre de récupération ; ne « pas attendre et voir ».

Task 12 — Marquer en sécurité un OSD out quand il nuit au cluster

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

Signification : Ceph va commencer à déplacer les données hors d’osd.7 pour restaurer l’état de réplication désiré.

Décision : Surveillez l’impact du backfill. Si le cluster ne peut pas gérer la récupération sans fondre, votre dimensionnement est marginal.

Task 13 — Observer et régler les throttles de recovery/backfill avec précaution

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

Signification : Des réglages de récupération conservateurs réduisent l’impact sur les clients mais allongent le temps de rebuild.

Décision : En heures ouvrées, restez conservateur. En fenêtres de maintenance, augmentez légèrement tout en surveillant la latence.

Task 14 — Vérifier « nearfull » avant que ça devienne « full »

cr0x@server:~$ ceph df
--- RAW STORAGE ---
CLASS  SIZE     AVAIL    USED     RAW USED  %RAW USED
ssd    34 TiB   21 TiB   13 TiB     13 TiB     38.25
TOTAL  34 TiB   21 TiB   13 TiB     13 TiB     38.25

--- POOLS ---
POOL  ID  PGS  STORED  OBJECTS  USED     %USED  MAX AVAIL
rbd    1  128  4.1TiB  950k     12.3TiB  57.0     6.2TiB
cephfs 2  128  0.2TiB  170k     0.6TiB    2.8     6.2TiB

Signification : L’usage raw semble correct, mais c’est le %USED par pool qui compte pour la capacité effective de ce pool.

Décision : Si rbd approche 70–75%, planifiez l’extension ; ne comptez pas courir près du plein et espérer une récupération indolore.

Task 15 — Vérifier que Proxmox voit et utilise correctement le datastore Ceph

cr0x@server:~$ pvesm status
Name     Type     Status    Total     Used     Avail    %
local    dir      active   1.8T     220G     1.6T   12.0%
ceph-rbd rbd      active   6.2T     3.5T     2.7T   56.0%

Signification : Le plugin de stockage Proxmox rapporte capacité et usage ; un décalage peut indiquer des problèmes d’auth/configuration.

Décision : Si Proxmox affiche « unknown » ou « inactive », corrigez la configuration client Ceph avant de pourchasser des fantômes de performance.

Méthode de diagnostic rapide (trouver le goulot sans réunion d’une semaine)

C’est l’ordre qui fait gagner du temps. Pas toujours. Mais assez souvent pour que ça devienne un réflexe.

Première étape : le cluster est-il healthy ou en récupération ?

• Lancez ceph -s et ceph health detail.
• Si vous voyez backfill/recovery/peering, acceptez que la performance soit dégradée et décidez de brider ou d’attendre.
• Si vous voyez des slow ops, identifiez les OSDs avec ceph osd perf.

Deuxième étape : un hôte ou disque traîne-t-il tout le monde ?

• Sur l’hôte suspect : iostat -x pour %util/await.
• Vérifiez les logs noyau : dmesg -T pour erreurs IO/reset storms.
• Vérifiez SMART si possible (souvent via outils vendor).
• Si un périphérique échoue, marquez l’OSD out et remplacez ; ne négociez pas avec la physique.

Troisième étape : le réseau ment-il ?

• Vérifiez les compteurs : ip -s link (errors/drops).
• Confirmez la MTU : ip link show.
• Cherchez la congestion : des pics pendant le backfill sont normaux ; des drops constants ne le sont pas.

Quatrième étape : problème de pool/client ?

• Confirmez les réglages de réplication du pool et l’autoscaler de PG.
• Vérifiez si vous avez utilisé des pools EC pour des disques VM (blessure auto-infligée courante).
• Validez la configuration Proxmox et que les clients utilisent le bon réseau.

Cinquième étape : c’est simplement sous-dimensionné ?

Si tous les composants sont « healthy » mais la latence est toujours mauvaise sous charge normale, votre cluster manque peut-être simplement
d’IOPS, de CPU ou de réseau. C’est le moment d’être honnête : le tuning ne transformera pas du HDD en NVMe.

Blague #2 : Tuner un cluster Ceph sous-dimensionné, c’est comme réarranger des chaises sur le pont — sauf que les chaises sont en feu et le navire est votre SLA.

Erreurs courantes : symptômes → cause racine → correction

1) « Tout devient lent quand un nœud tombe »

Symptômes : pics de latence, timeouts VM, Proxmox lent pendant remplacement de disque ou reboot d’hôte.

Cause racine : recovery/backfill qui sature le réseau ou les OSDs ; cluster dimensionné uniquement pour le chemin heureux.

Correction : augmentez le nombre de nœuds et la bande passante réseau ; bridez la récupération en heures ouvrées ; réservez une marge (restez sous ~75%).

2) « Ralentissements aléatoires, sans erreurs évidentes »

Symptômes : stalls occasionnels de 5–30s, HEALTH_WARN avec slow ops, puis ça s’efface.

Cause racine : un périphérique OSD intermittemment défaillant, bugs firmware, ou contention IO au niveau hôte.

Correction : utilisez ceph osd perf pour identifier les coupables ; vérifiez dmesg ; remplacez les disques instables ; arrêtez de mélanger des SSD grand public.

3) « Ceph est plein, mais df dit qu’il y a de la place »

Symptômes : un pool atteint nearfull/full, les écritures bloquent, malgré une capacité « raw » disponible.

Cause racine : la capacité effective au niveau pool est contrainte par la réplication et la distribution ; remplissage inégal des OSDs ; oversubscription thin-provisioning.

Correction : étendez avant que les pools dépassent les seuils sûrs ; rééquilibrez les weights ; appliquez des quotas et discipline de provisioning.

4) « Super throughput en benchmark, expérience VM terrible »

Symptômes : tests séquentiels ok ; workloads réels lents ; latence p95 catastrophique.

Cause racine : les benchmarks ne reflètent pas les petites E/S aléatoires + fsync ; HDD/hybride sans DB/WAL SSD adéquat ; famine CPU.

Correction : mesurez la latence ; déplacez les disques VM vers un pool tout-flash ; assurez un ordonnancement CPU adéquat pour les OSDs ; ne surcommitez pas les nœuds de stockage.

5) « On a mis de l’erasure coding pour économiser de l’espace sur les disques VM »

Symptômes : latence d’écriture plus élevée, surtout en charge ; récupération brutale ; pics CPU.

Cause racine : amplification des petites écritures en EC et coût calculatoire ; pas aligné avec les patterns d’E/S des disques VM.

Correction : utilisez des pools répliqués pour les disques VM ; gardez EC pour les gros objets et workloads peu sensibles à la latence.

6) « Ceph oscille quorum / MONs se plaignent »

Symptômes : MONs hors quorum, pauses du cluster, erreurs étranges pendant les pics de trafic.

Cause racine : nœuds MON surchargés ou sous-dimensionnés, instabilité réseau, ou MONs exécutés sur des nœuds affamés par les VM.

Correction : assurez trois MONs sur des nœuds stables ; réservez CPU/RAM ; isolez le réseau ; évitez de placer les MONs sur l’hyperviseur le plus sollicité.

7) « Le backfill ne finit jamais »

Symptômes : semaines de PG remapped/backfilling, états dégradés constants après des petits changements.

Cause racine : trop peu de capacité libre, trop peu de bande passante, ou changements trop agressifs (ajout/suppression de multiples OSDs d’un coup).

Correction : planifiez les changements ; ajoutez de la capacité par petits paquets ; bridez la récupération ; évitez d’opérer près du plein ; augmentez le réseau.

Trois mini-histoires du monde de l’entreprise (anonymisées, plausibles et douloureusement familières)

Mini-histoire 1 : l’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne est passée d’un seul hôte de virtualisation avec NVMe locaux à un cluster Proxmox trois nœuds avec Ceph.
L’hypothèse était simple : « on a trois nœuds, donc on a la HA maintenant. Ce sera au moins aussi rapide. »
Personne n’a dit « la réplication ajoute des écritures » à voix haute. Personne n’a testé les pannes avec des charges réelles.

Le premier reboot de maintenance eut lieu un mardi matin. Un nœud est tombé pour des mises à jour firmware. Ceph a fait son boulot :
a commencé à backfiller pour maintenir la réplication. La latence VM a grimpé, puis encore, puis l’assistance a commencé à transférer des tickets
avec des sujets écrits EN MAJUSCULES.

Ils ont blâmé Proxmox, puis Ceph, puis le réseau. La vérité était ennuyeuse : le 10GbE était partagé avec le trafic client,
et les OSDs étaient des SATA SSD qui paraissaient corrects en mono-nœud mais se sont effondrés sous des écritures aléatoires répliquées plus la récupération.
La mauvaise hypothèse n’était pas « Ceph est rapide ». C’était « Ceph se comporte comme du stockage local, juste partagé. »

La correction n’a pas été une configuration magique. Ils ont séparé le trafic stockage, bridé la récupération en heures de bureau,
et ajouté deux nœuds pour réduire la pression de récupération. La correction à long terme fut plus inconfortable :
ils ont arrêté de vendre l’idée interne que « la HA est gratuite ».

Mini-histoire 2 : l’optimisation qui a mal tourné

Une autre organisation disposait d’un cluster Ceph tout-flash qui était « correct » mais peu excitant. Ils voulaient plus d’efficacité de capacité.
Quelqu’un a proposé de l’erasure coding pour le datastore VM principal. Le tableur était magnifique.
Le plan de migration était propre. Le ticket de changement avait un ton confiant. Danger, en forme corporate.

Au début, ça a fonctionné. La capacité utilisable a augmenté. Puis les plaintes de performance ont commencé — subtiles d’abord, puis persistantes.
Le pire n’était pas la latence moyenne ; c’était la latence queue longue. Les applis se figeaient brièvement, puis repartaient. Les utilisateurs décrivaient ça comme « collant ».

Sous le capot, les petites écritures aléatoires subissaient l’amplification EC et le coût CPU additionnel.
Lors d’événements de récupération, le réseau et le CPU montaient en flèche d’une façon que l’équipe n’avait pas modélisée. Chaque incident mineur se transformait en
période prolongée de performance dégradée.

Ils ont rollbacké le datastore principal vers des pools répliqués, gardé l’EC pour les workloads moins interactifs,
et arrêté « d’optimiser » sans budget de performance aligné sur la charge. L’efficacité de capacité est géniale — jusqu’à ce qu’elle vous coûte la crédibilité.

Mini-histoire 3 : la pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe finance exploitait un cluster Proxmox+Ceph cinq nœuds. Rien d’exotique : pools répliqués, 25GbE, NVMe cohérents,
réglages de récupération conservateurs. Leur arme secrète n’était pas le matériel. C’était le processus.

Ils avaient une petite habitude hebdomadaire : revoir la santé Ceph, vérifier les outliers de latence OSD, et regarder les tendances d’utilisation des pools.
Ils imposaient aussi une règle : les mises à jour firmware stockage et les changements de noyau se faisaient en fenêtres de maintenance contrôlées, un nœud à la fois,
avec un checkpoint « stop si la récupération est en colère ».

Un semaine, ils ont remarqué un OSD dont la latence commit/apply montait légèrement. Pas d’erreur. Juste « différent ».
Ils l’ont marqué out pendant une fenêtre calme, remplacé le disque, laissé le cluster guérir, et sont passés à autre chose. Deux jours plus tard,
un modèle de disque similaire dans un autre environnement a commencé à générer des erreurs de lecture et a provoqué un incident visible client.

Leur panne a été un non-événement parce qu’ils traitaient le « légèrement étrange » comme une tâche à faire, pas une curiosité. La pratique était ennuyeuse.
Le résultat était excellent.

Checklists / plan étape par étape

Checklist de décision : devez-vous exécuter Ceph sur Proxmox ?

• Avez-vous au moins 3 nœuds maintenant (pas « bientôt ») ? De préférence 5+ ?
• Avez-vous du 10GbE minimum, idéalement 25GbE, avec des switches raisonnables ?
• Pouvez-vous maintenir l’utilisation steady-state sous ~70–75% ?
• Avez-vous du matériel cohérent entre les nœuds ?
• Avez-vous une personne responsable de la santé du stockage (alertes, maintenance, upgrades) ?
• Acceptez-vous que la récupération d’une panne soit un événement de performance que vous devez budgéter ?

Checklist de construction : une base sensée pour un nouveau cluster

1. Choisissez le nombre de nœuds et les domaines de panne. Décidez si « hôte » suffit ou si vous avez besoin d’une séparation au niveau rack.
2. Choisissez la vitesse réseau et la topologie. Séparez logiquement le trafic Ceph (VLAN) et, si possible, physiquement.
3. Choisissez la classe de média par pool. Ne mélangez pas HDD et NVMe dans le même pool de performance.
4. Configurez des pools répliqués pour les disques VM (size=3, min_size=2 est courant). Soyez explicite sur la raison.
5. Activez l’autoscaler PG et révisez périodiquement les changements suggérés.
6. Définissez l’alerte pour : HEALTH_WARN/ERR, slow ops, nearfull/full, changements de quorum MON, flaps OSD, erreurs disque.
7. Documentez le comportement de récupération : à quoi ressemble un état « dégradé normal » et quand brider.

Checklist opérations : habitudes hebdomadaires qui évitent le drame

• Revoir ceph -s et ceph health detail.
• Vérifier ceph osd perf pour des outliers et investiguer au moins un par semaine.
• Revoir les tendances de capacité avec ceph df et l’utilisation Proxmox.
• Confirmer l’absence de pics d’erreurs/drops sur les NICs de stockage.
• Effectuer une activité de maintenance contrôlée à la fois (un reboot d’hôte, un remplacement d’OSD), puis observer.

Checklist d’expansion : ajouter nœuds/OSDs sans chaos

1. Confirmer que vous avez de la marge pour le backfill (espace et bande passante).
2. Ajouter par petits lots suffisants pour que la récupération ne broie pas les IO clients.
3. Surveiller les états PG et la perf OSD pendant le rebalancing.
4. Après récupération, valider l’utilisation des pools et la distribution des PGs.
5. Puis seulement passer au lot suivant.

FAQ

1) Quel est le nombre minimum de nœuds pour Ceph sur Proxmox ?

Trois nœuds est le minimum pour un vrai cluster avec quorum et stockage répliqué. Cinq nœuds, c’est là où la maintenance et la récupération cessent d’être acrobatiques.

2) Puis-je faire tourner Ceph sur 1GbE si ma charge est petite ?

Vous pouvez, mais vous ne devriez probablement pas. Même les petits clusters ont des événements de récupération, et le 1GbE transforme la récupération en « tout est lent ».
Si vous devez le faire, baissez vos attentes et évitez de promettre de la HA.

3) Ai-je besoin de réseaux séparés pour le trafic public et cluster ?

Pas strictement, mais la séparation (au moins VLAN) réduit le rayon d’impact et rend le troubleshooting plus simple. Si vous avez les ports, dédiez des liens.

4) Dois-je utiliser CephFS pour les disques VM ?

Pour les disques VM sur Proxmox, RBD est typiquement le bon choix. CephFS est excellent pour des workloads fichiers partagés, pas comme remplacement des sémantiques bloc.

5) Réplication size 2 vs 3 : size 2 est-elle acceptable ?

Size 2 n’est acceptable que si vous acceptez explicitement une tolérance de panne réduite et comprenez les scénarios de défaillance.
Dans la plupart des environnements business, size 3 est le défaut plus sûr car il tolère la réalité plus chaotique.

6) Dois-je utiliser l’erasure coding pour économiser de l’espace ?

Utilisez EC quand la charge s’y prête : gros objets, sensibilité à la latence faible, et si vous pouvez absorber le surcoût CPU/réseau.
Pour les datastores VM primaires, les pools répliqués sont généralement le bon compromis.

7) Jusqu’à quel remplissage Ceph est-il « trop plein » ?

Traitez ~70–75% comme la fourchette où il faut commencer à planifier une extension pour les pools répliqués VM.
Au-delà, la récupération devient plus lente et risquée, et vous finirez par rencontrer des contraintes de backfill.

8) Pourquoi la performance est-elle pire pendant les rebuilds même si le cluster est healthy ?

Parce que les rebuilds consomment les mêmes ressources dont vos clients ont besoin : IO disque, CPU et réseau.
Un cluster healthy peut tout de même être occupé. Vous dimensionnez et ajustez pour une dégradation acceptable pendant la récupération, pas pour la perfection.

9) Puis-je mélanger différents modèles de SSD ou générations de nœuds ?

Vous pouvez, mais c’est une source courante de latence queue longue et de comportements inégaux. Dans Ceph, l’hétérogénéité se manifeste lors des récupérations et workloads hotspot.
Si vous devez mélanger, isolez par classe de périphérique et pool, et attendez-vous à une complexité opérationnelle accrue.

10) Quel est le premier indicateur à surveiller quand « Ceph paraît lent » ?

ceph osd perf pour les outliers de commit/apply latency, et vérifier si le cluster est en backfilling. Un OSD lent peut empoisonner l’expérience globale.

Étapes suivantes que vous pouvez exécuter

1. Exécutez la méthode de diagnostic rapide la prochaine fois qu’on se plaint. Capturez ceph -s, ceph osd perf et l’iostat hôte.
2. Décidez votre budget de panne : jusqu’à quel point la dégradation pendant la récupération est « acceptable » ?
3. Corrigez les gros leviers d’abord : bande passante réseau, médias cohérents, et marge libre. Le tuning vient après.
4. Séparez les pools par classe de performance et arrêtez de mélanger les périphériques lents et rapides dans le même datastore VM.
5. Institutionnalisez les contrôles ennuyeux : revue hebdomadaire de santé, chasse aux outliers, suivi des tendances de capacité, et maintenance un changement à la fois.

Si Ceph sur Proxmox correspond à vos besoins et que vous le dimensionnez honnêtement, c’est une bonne manière d’exécuter de la virtualisation résiliente sans acheter une « religion » stockage.
Si vous essayez de tricher avec la physique, elle répondra par des graphiques de latence qui ressemblent à de l’art moderne.