La conversa es repeteix: algú canvia els discos del seu clúster per uns altres de més ràpids i el rendiment gairebé no es mou. Llavors comença la caça del coll d'ampolla —la xarxa, la CPU, el firmware, el kernel— i gairebé mai no es mira el lloc on de debò es decideix: el planificador d'operacions que cada OSD porta a dins, i el número que aquest planificador es creu que el teu disc és capaç de donar.
Operem Proxmox VE amb Ceph en producció en diversos centres de dades, així que això ho diem amb l'afecte de qui s'ho ha menjat: a Ceph, el rendiment que veus no el signa el fabricant del disc. El signa un repartiment intern que es va configurar sol, amb una mesura que va fer el teu OSD el dia que va arrencar i que probablement ningú no ha tornat a mirar. Els números que segueixen no són nostres: són els que porta la documentació de Ceph i els que trobaràs al teu clúster si el mires. De collita pròpia hi va l'ordre en què els mirem i què en fem.
El planificador que va arribar amb Quincy i gairebé ningú no va configurar
Dins d'un OSD competeixen quatre classes de feina: les operacions del client (les teves VM), la recuperació i el backfill, el scrub i les tasques de manteniment. Fins a Ceph Pacific aquest repartiment el feia una cua de prioritats ponderada (wpq). Amb Quincy, el planificador per defecte dels OSD BlueStore va passar a ser mclock_scheduler, i amb ell va canviar la manera de repartir: en comptes de prioritats relatives, mClock assigna a cada classe una reserva (mínim garantit), un pes i un límit sobre la capacitat total de l'OSD.
El perfil actiu per defecte es diu balanced —ho és des de la 17.2.7 i la 18.2.0; a les Quincy anteriors hi venia high_client_ops— i fa exactament el que promet: reserva un 50 % per al client i un 50 % per a la recuperació (més un 5 % per a la resta). Els altres dos perfils integrats mouen aquest equilibri: high_client_ops deixa 60/40 a favor del client i high_recovery_ops l'inverteix a 30/70 perquè un clúster degradat es curi abans.
Fins aquí, raonable. El problema no és el repartiment: és sobre què es reparteix.
315 IOPS: el número que governa el teu clúster i no vas posar tu
Per repartir percentatges, mClock necessita saber quin és el 100 %. Aquest sostre viu a osd_mclock_max_capacity_iops_hdd i osd_mclock_max_capacity_iops_ssd, i el determina el mateix OSD executant un benchmark el primer cop que arrenca; el resultat es desa a la configuració centralitzada dels monitors i es reutilitza en arrencades posteriors. Si aquesta mesura no es va arribar a fer o es va descartar, es mantenen els valors per defecte de la documentació:
- •315 IOPS per a un disc mecànic (
osd_mclock_max_capacity_iops_hdd). - •21.500 IOPS per a un d'estat sòlid (
osd_mclock_max_capacity_iops_ssd). - •I, al marge del benchmark, una amplada de banda seqüencial que no es mesura mai i sempre és fixa:
osd_mclock_max_sequential_bandwidth_hdd= 150Mi iosd_mclock_max_sequential_bandwidth_ssd= 1200Mi. mClock la fa servir per calcular el cost de cada operació, no el sostre.
I aquí hi ha la part que sorprèn més d'un. La mesura de l'arrencada no s'accepta a cegues: si el resultat se surt de la forquilla que Ceph considera creïble, el descarta i torna al valor per defecte, deixant un avís al log de l'OSD. Per dalt, osd_mclock_iops_capacity_threshold_hdd = 500 i osd_mclock_iops_capacity_threshold_ssd = 80.000. Per baix funciona igual, i és la meitat que ningú no explica: osd_mclock_iops_capacity_low_threshold_hdd = 50 i osd_mclock_iops_capacity_low_threshold_ssd = 1.000. Una mesura massa bona i una massa dolenta acaben al mateix lloc: la capacitat vàlida anterior o, si no n'hi ha, el valor de fàbrica.
Traduït a la vida real: pots tenir un NVMe empresarial que a la seva fitxa promet centenars de milers d'IOPS, i que el planificador del teu OSD estigui repartint, tan tranquil, sobre 21.500. El disc no menteix i la fitxa tampoc; simplement ningú no ha dit a Ceph que se'l cregui.
Com saber què es creu el teu clúster (cinc minuts)
Això no requereix finestra de manteniment ni aturar res. Es mira i prou:
# Quin planificador està actiu? ceph config show-with-defaults osd.0 | grep op_queue # Quin sostre d'IOPS es creu cada OSD? ceph config show-with-defaults osd.0 | grep mclock_max_capacity # Mesurar de debò aquest OSD (4 KiB aleatori, com mana la doc) i fixar el valor ceph tell osd.0 cache drop ceph tell osd.0 bench 12288000 4096 4194304 100 ceph config set osd.0 osd_mclock_max_capacity_iops_ssd <valor>
Si prefereixes que l'OSD ho torni a mesurar sol, existeix osd_mclock_force_run_benchmark_on_init (per defecte false), pensat precisament per a quan el maquinari de sota ha canviat: s'activa de manera temporal, es reinicia l'OSD perquè refresqui la seva capacitat i després es treu. Compte amb dues coses: el benchmark escriu, així que no és cosa de llançar-lo en hora punta alhora a tots els OSD; i la mesura és una foto d'aquell moment, feta per una màquina que en aquell instant no està servint les teves VMs.
Els paràmetres que feia anys que tocaves ja no fan res
Aquesta és la segona sorpresa, i la que fa perdre més temps. Amb un perfil integrat de mClock actiu, la documentació de Ceph és explícita: aquestes opcions se sobreescriuen amb els valors de mClock.
- ✗
osd_max_backfills,osd_recovery_max_active,osd_recovery_max_active_hddiosd_recovery_max_active_ssd: sobreescrits. - ✗Amb qualsevol perfil actiu, inclòs
custom, les esperes es desactiven (es posen a zero):osd_recovery_sleepi les seves variants,osd_scrub_sleep,osd_delete_sleepiosd_snap_trim_sleep.
Amb dos matisos que dona la mateixa documentació, i que convé dir per no vendre fum. El primer: aquests límits sí que es poden tocar, però només activant abans osd_mclock_override_recovery_settings (per defecte false); si no l'actives i els canvies igual, Ceph reverteix el teu valor al seu i deixa un avís al log del clúster. No és que s'ignori el teu ajust: és que se't desfà, i queda per escrit. El segon: els valors als quals reverteix coincideixen amb els històrics —osd_max_backfills 1, osd_recovery_max_active_hdd 3, _ssd 10—, així que a la majoria de clústers l'efecte net és el mateix que no haver tocat res. El que es perd és la il·lusió d'estar controlant-ho.
El wiki de Proxmox ho diu sense embuts: els mètodes antics per controlar quant rendiment es dedica al backfill i a la recuperació són ignorats per mClock. Així que si algú va copiar d'un manual del 2019 un osd_recovery_sleep_hdd generós perquè el clúster no s'ofegui durant una reconstrucció, aquest ajust avui no està fent absolutament res. I aquest mateix wiki avisa d'un detall que trenca receptes velles: fins a la 17.2.6 els valors res i lim del perfil custom s'expressaven en IOPS; des de la 17.2.7 i la 18.2.0 són una fracció de la capacitat d'IOPS de l'OSD, de 0,0 a 1,0. La mateixa línia copiada d'un fòrum significa dues coses diferents segons la teva versió.
El scrub no té finestra horària per defecte
Ceph verifica les seves dades pel seu compte, i això està molt bé: és una de les raons per les quals hi confiem. Però convé saber quan ho fa. Per defecte, el scrub lleuger es planteja a partir d'un dia (osd_scrub_min_interval) i el deep scrub —que llegeix les dades, no només les metadades— cada set dies (osd_deep_scrub_interval). Cada OSD admet fins a tres scrubs simultanis (osd_max_scrubs). I la finestra horària, osd_scrub_begin_hour i osd_scrub_end_hour, ve amb 0 i 0: sense restricció, a qualsevol hora.
En un clúster d'NVMe això passa inadvertit. En un de discos mecànics amb la nòmina tancant-se un dimarts al matí, no. L'opció sensata no és apagar el scrub —qui ho fa acaba descobrint la corrupció el dia del restore— sinó posar-li horari i acceptar que la verificació és part del cost de tenir les dades sanes. I aquí hi ha una palanca que sí que funciona: mClock t'ha posat osd_scrub_sleep a zero, però les hores d'inici i fi, els seus equivalents per dia de la setmana i osd_max_scrubs continuen sent teus.
La xarxa també és part del disc
Una escriptura de client en un pool replicat no acaba quan el disc primari l'ha desada: acaba quan l'han desada totes les rèpliques. La latència que veu la VM la marca, per tant, l'OSD més lent del grup, no la mitjana del clúster. Un sol disc malalt —o amb la seva mesura mal posada— arrossega la resta.
Per això la recomanació de xarxa de la mateixa documentació de Ceph no és un caprici de fabricant de commutadors. Els seus números: replicar 1 TiB per una xarxa d'1 Gb/s costa tres hores; 10 TiB, trenta hores; aquest mateix TiB a 10 Gb/s baixa a vint minuts. La recomanació és proveir com a mínim 10 Gb/s, i avisa que els nodes densos o d'NVMe poden saturar 10 GE i fins i tot 25 GE; per a càrregues de treball serioses suggereix 25 Gb/s, i enllaços de 100 Gb/s quan els nodes són densos. Aquestes trenta hores no són una dada de catàleg: són el temps que el teu clúster passa degradat després de perdre un node, i durant el qual el perfil balanced està reservant a la recuperació la meitat de cada OSD.
Quant triga aquesta reconstrucció depèn també de l'esquema del pool: recuperar una rèplica és copiar, i recuperar un fragment d'erasure coding és llegir uns quants trossos i reconstruir. Vam fer aquests comptes complets a rèplica 3 contra erasure coding, i les optimitzacions que canvien aquesta aritmètica a l'última branca les repassem a Fast EC arriba apagat.
Quan el disc SÍ que és el problema
Seria deshonest quedar-se en "és el planificador". Hi ha dos casos en què el maquinari és exactament el culpable, i la documentació de Ceph els assenyala sense diplomàcia:
- 1SSD de consum en un OSD. La documentació recomana unitats de classe empresarial perquè porten protecció davant pèrdua d'alimentació (PLP), i anomena les de gamma baixa o sense marca una falsa economia que pot patir cliffing: després d'una ràfega inicial, quan s'omple una memòria cau limitada, el rendiment sostingut es desploma. Sobre desgast, avisa que un disc de 0,3 DWPD pot servir per a OSD dedicats a dades escrites en seqüencial i llegides molt més del que s'escriuen, però no és bona elecció per a un pool RBD que serveix centenars de VM, i que la majoria de desplegaments d'OSD no necessiten més d'1 DWPD: els mixed-use de 3 DWPD solen ser excessius i costen força més. Fins aquí la documentació. El que hi posem nosaltres: Ceph escriu demanant confirmació a disc constantment, i sense PLP cadascuna d'aquestes confirmacions es paga en latència.
- 2Discos mecànics sense WAL/DB en flash, o amb massa per unitat. La proporció que dona la documentació és de quatre o cinc OSD de disc mecànic per cada SSD SATA de WAL/DB, i fins a uns quinze per NVMe. Passar-se d'aquí converteix el dispositiu de metadades en el nou coll d'ampolla —i en un domini de fallada que s'emporta tots els OSD que en depenen.
El que mirem nosaltres, en aquest ordre
- ✓El planificador actiu i el perfil de mClock. Abans de tocar res més.
- ✓El sostre d'IOPS de cada OSD, un per un. Un OSD amb el valor per defecte entre vint que sí que es van mesurar és una anomalia que no apareix en cap gràfic d'ús.
- ✓Els avisos del log de l'OSD sobre el resultat del benchmark descartat. Allà està escrit el problema, amb data.
- ✓Quins ajustos heretats segueixen escrits a la configuració sense efecte real, per esborrar-los i deixar de raonar sobre fum.
- ✓La latència per OSD, no la mitjana del clúster. La mitjana amaga justament el que mana.
Al gra
Ceph reparteix feina sobre una capacitat que es va estimar sola, en una arrencada, i que pot haver-se quedat en un valor de manual. Abans de signar la compra d'uns discos més ràpids, val la pena dedicar cinc minuts a preguntar al clúster què es creu que té. De vegades la resposta és que el maquinari va just i cal comprar. I de vegades la resposta és que el maquinari nou anava a entrar per la mateixa porta estreta que el vell.
Fonts (verificades el 13 d'agost de 2026 contra les branques latest i reef de la documentació): perfils, reserves, capacitat d'IOPS, llindars i opcions sobreescrites — mClock Config Reference; intervals de scrub i recuperació — OSD Config Reference; PLP, DWPD, proporcions de WAL/DB i temps de replicació per xarxa — Hardware Recommendations; confirmació de l'escriptura replicada per l'OSD primari — Ceph Architecture; canvi de wpq a mclock a Quincy, ajustos ignorats i unitats de res/lim segons versió — Proxmox VE Wiki: Ceph mClock Tuning.
El teu Ceph va lent i ningú no sap explicar per què?
A everyWAN dissenyem i operem emmagatzematge distribuït amb Ceph en producció. Mirem el clúster que ja tens abans de recomanar-te comprar res: no venem llicències ni discos de ningú.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN