Ampliar Ceph per un sol node no amplia res

L'entrada del blog de Ceph va datada l'11 de novembre del 2026 —el blog la data demà; nosaltres la vam llegir avui— i la signa Anthony D'Atri. Comença parlant de pastís d'Acció de Gràcies i acaba amb un exemple que val una reunió de pressupost: tres nodes amb pesos 100, 100 i 1.138. Hi ha 1.338 de disc cru. El pool escriu 95. I 1.043 —el 78 % del que vas pagar— no ho pot fer servir ningú, mai.

Operem Proxmox VE amb Ceph en producció, repartit en diversos centres de dades, i la conversa que més es repeteix quan a algú se li omple el clúster és sempre la mateixa: «tenim lloc al node tres, li fiquem discos allà i llestos». És la resposta natural, és la més barata, i en un clúster de tres nodes amb rèplica 3 no serveix absolutament de res. No és opinió nostra: és aritmètica de CRUSH, i l'autor acaba de publicar-la amb una calculadora al costat perquè ningú no se la cregui de paraula.

La regla que decideix la teva capacitat cap en una línia

Cada grup de col·locació (PG) d'un pool és un pastís. Un pool replicat el talla en tantes porcions idèntiques com digui el seu size; un de codi d'esborrat el talla en k porcions de dades i m de paritat. CRUSH reparteix aquelles porcions entre els dominis de fallada que anomeni la regla del pool, com a molt una porció a cadascun, de manera que perdre un node, un rack o una sala li costi a cada PG com a molt una sola porció. Aquesta és la part que protegeix les teves dades. La part que decideix la teva factura és el corol·lari, i l'autor l'escriu sense embuts: «A failure domain can never hold more than 1/n of what the pool stores, however big it is.»

On n és el size del pool replicat o el k+m del de codi d'esborrat. El domini de fallada per defecte és el host: l'usen tant la regla replicada per defecte com el perfil de codi d'esborrat per defecte. I el pes CRUSH d'un domini és la suma dels pesos dels seus OSD, que per defecte és la seva capacitat en TiB. El canvi mental, doncs, és aquest: la teva capacitat no és la suma dels teus discos. És el cru que CRUSH pot repartir sense que cap domini passi d'1/n, rebaixat pel full_ratio (0,95 per defecte, el punt on Ceph talla les escriptures) i dividit entre n —o multiplicat per k/(k+m) si vas amb codi d'esborrat—. I quan tens exactament n dominis, això és senzillament el que càpiga al més petit. L'emplenament, a més, s'atura abans, al backfillfull_ratio (0,90).

1.338 de disc, 95 escrivibles

Aquests són els tres repartiments que publica l'autor, posats l'un sota l'altre. Convé llegir la columna «escriu» amb compte: són unitats de dada, no de cru. Amb rèplica 3, escriure 95 ocupa 285 de disc.

Les dues últimes files són la mateixa xifra. Un quart node de 1.701 i un quart node de 150 escriuen exactament el mateix: 142,5. D'aquells 1.701, en treballen 150. Els altres 1.551 són allà perquè algú els vegi a l'inventari. I la comparació que a nosaltres ens sembla la que de debò fa mal és aquesta altra, que no és a l'article però surt dels seus mateixos números: passar de tres nodes de 100 a quatre de 100 puja la capacitat de 95 a 126,7, un 33 % més; ficar-li 1.038 de disc a un dels tres la deixa en 95, igual que estava.

La fórmula per endur-se a la reunió de compres

L'autor la deixa escrita de dues maneres equivalents: cap domini de fallada no pot aprofitar més d'1/n de la capacitat crua del pool; o, dit al revés, el domini més gran pot ser com a molt la suma dels altres dividida entre n−1. Això és una fórmula de full de càlcul, i aguanta una reunió amb el comercial que et vol vendre la caixa gran.

Apliquem-la a un cas que no és a l'article. Tens cinc nodes de 100 i vas a comprar el sisè. Amb rèplica 3, n = 3, la suma dels altres és 500, i el node nou pot arribar a 250 sense malgastar res. Amb codi d'esborrat 4+2, n = 6, la mateixa suma de 500 dividida entre cinc deixa el sostre en 100: ni un disc més. És a dir, el mateix ferro, el mateix pressupost i la mateixa sala donen dues respostes diferents segons una decisió que es va prendre en crear el pool, probablement fa anys, probablement sense apuntar-la enlloc.

CRUSH pel seu compte no arriba al sostre

Totes les xifres de dalt suposen un repartiment perfecte, i CRUSH sol no l'aconsegueix. El seu algorisme straw2 sorteja cada domini en proporció al seu pes, però si li surt un que el PG ja fa servir, torna a sortejar. L'efecte és que un domini pesat s'elegeix menys vegades del que el seu pes diria, i els lleugers s'omplen abans d'hora. En el repartiment 100·100·100·150, el sostre amb repartiment equilibrat és 142,5 i sense encallar res; CRUSH pel seu compte es queda en uns 132, que és quan s'omple el primer node petit.

El mateix disc mort, dos finals diferents

Aquí és on el càlcul deixa de ser comptable i es torna operatiu. Mor un OSD de pes 10 en un de tres nodes de 100, amb rèplica 3. Cada PG ja té una còpia als altres dos nodes, així que el que hi havia en aquell OSD només es pot tornar a protegir dins del seu propi node. Aquell node passa a valer 90, i com que tots els PG hi tenen una còpia, marca el pas: el sostre del pool cau de 95 a 85,5. Perds 9,5 pel disc mort i altres 9,5 a cadascun dels dos nodes sans, que deixen de poder fer-se servir.

I ara la frase que hauria d'estar penjada a la paret de qualsevol que operi un Ceph de tres nodes: l'emplenament s'atura al backfillfull_ratio, així que si el pool guardava més de 81 —el 85 % del seu sostre— quan va morir el disc, la recuperació s'atura amb els PG encara degradats. No és que vagi lenta: és que no acaba. Amb un quart node de 100, el mateix disc mort baixa el sostre només de 126,7 a 123,5, i per reprotegir del tot n'hi ha prou amb estar per sota de 117, el 92 % del sostre. Si el que perds és un node sencer de tres, no hi ha on reprotegir: els PG es queden degradats fins que el node torni. De quatre, es reprotegeixen als altres tres mentre el pool estigui per sota de 90, el 71 % del seu sostre.

El mateix disc mort, al mateix armari, el mateix dimarts. Amb quatre nodes és paperassa —es reposa sol i ho expliques dilluns—; amb tres, és un clúster degradat esperant que arribi el recanvi. La diferència no la decideix el disc ni la sort: es va decidir mesos abans, quan algú va triar tres nodes en lloc de quatre perquè tres era el que calia per al quòrum. Ja ho vam explicar amb més detall a per què un Ceph de tres nodes no es cura sol, aguanta, i aquest article li posa per fi els números de capacitat al costat.

Codi d'esborrat: el mateix càlcul, amb k+m

Un pool 4+2 sobre sis nodes de 100 escriu 380. Mor un OSD de pes 10 i el sostre cau a 342; per reprotegir del tot cal estar per sota de 324. Sobre set nodes de 100, el mateix pool escriu 443,3, la mateixa fallada el deixa en 437 i la reprotecció demana estar per sota de 414. El que compra aquell setè node, dit amb els percentatges que n'hem tret nosaltres: un 17 % més de capacitat, convertir una caiguda de 38 en una de 6, i passar d'haver d'anar al 85 % del sostre a poder anar al 93 %. Tres coses diferents, i només una apareix en un full de càlcul de compres.

I un advertiment que l'autor despatxa en una frase i que nosaltres repetim cada vegada que algú proposa m = 1 per estalviar un disc de paritat: «if you choose m=1, expect data unavailability during maintenance and data loss when component failures overlap». No és un «no recomanat» de manual. És que durant un manteniment planificat —el teu, el de dimarts— el pool no està disponible, i si una fallada n'enxampa una altra pel mig, les dades es perden. El PG Calc reescrit marca en ambre precisament això: els pools amb menys de tres rèpliques i els que porten m = 1.

Les cinc ordres que mirem abans de signar una ampliació

Quan ens truquen per «ampliar el Ceph», la primera pregunta no és quins discos, és quants dominis de fallada hi ha i quant pesa cadascun. Aquest és el càlcul de fora del node; el de dins —els llindars per OSD i per què el disc més ple mana sobre tot el clúster— el vam explicar a la capacitat la marca el disc més ple. Això és el que executem abans de mirar un catàleg, i es pot copiar tal qual:

Amb aquelles cinc sortides i la fórmula de dalt, la recomanació surt sola, i bastants vegades és la que pitjor senta en una reunió de pressupost: no compris discos encara, compra un node. És una factura més incòmoda de defensar i bastanta més feina de posada en marxa, però és l'única resposta que arregla alhora la capacitat i la recuperació. I hi ha un «quan no» igual d'honest: si el teu clúster ja té cinc o sis dominis ben repartits i el que necessites és volum, aleshores sí, discos; en aquell repartiment la fórmula et dóna marge de sobra i no cal gastar-se un servidor sencer.

Un apunt de versions, perquè l'article ho menciona de passada i té conseqüències: l'autoescalador de PG respon bé a la pregunta de quants PG ha de tenir un pool en molts clústers amb releases recents —el matís és seu, no ho ven com a universal— un cop el mon_target_pg_per_osd és almenys a 200, i aquest és el seu valor per defecte a partir de la release Umbrella. Si el teu clúster ve d'enrere, aquell paràmetre probablement continuï on era. Sobre qui té avui Umbrella i qui no, ja vam escriure què porta i què no porta l'assistent de Proxmox. I si el que et preocupa és l'altra cara —què passa quan la reposició de còpies està apagada expressament—, és a què fa de debò el flag noout.

Les sobres, que és on hi ha el menjar

L'article tanca amb cinc línies sota el títol «Leftovers». Les traduïm perquè valen més que la resta d'aquest text:

• Tingues almenys un domini de fallada més que el size del pool o el seu k+m.
• Mantén els dominis de fallada amb pesos semblants: cap no pot aprofitar més d'1/n de la capacitat crua.
• Afegeix capacitat repartida entre dominis, no a un de sol.
• Deixa el balancejador encès.
• Deixa lloc per sota del backfillfull perquè la recuperació hi càpiga.

Nosaltres n'hi afegim una setena, que no és tècnica: mesura el pes, no el catàleg. El ceph osd df tree s'executa abans de l'ordre de compra, no després que el comercial hagi posat l'oferta damunt la taula. Costa trenta segons i és l'única cosa que separa «hem ampliat l'emmagatzematge» d'«hem ampliat l'inventari».

Fonts (consultades el 10-11-2026): totes les xifres de repartiment, fallada i reprotecció —100·100·1.138 escrivint 95 amb 1.043 d'encallats (78 % del cru); 100·100·100·1.701 escrivint 142,5 amb el mateix 78 % encallat; el topall de 150 per al quart node; 100·100·100·150 arribant a 142,5 equilibrat i a uns 132 amb CRUSH sol; la caiguda de 95 a 85,5 i el llindar de 81 en morir un OSD de pes 10 en tres nodes de 100; la de 126,7 a 123,5 i el llindar de 117 amb quatre; els 90 (71 % del sostre) en perdre un node sencer de quatre; i el pool 4+2 amb 380 → 342 → 324 sobre sis nodes i 443,3 → 437 → 414 sobre set—, les dues frases citades («A failure domain can never hold more than 1/n of what the pool stores, however big it is» i «if you choose m=1, expect data unavailability during maintenance and data loss when component failures overlap»), la regla del domini major ≤ suma dels altres ÷ (n−1), el comportament de straw2 en tornar a sortejar, el balancejador actiu per defecte en mode upmap, els valors per defecte 0,95 i 0,90 de full_ratio i backfillfull_ratio, el mon_target_pg_per_osd a 200 per defecte des d'Umbrella, l'ambre del PG Calc per a m=1 i menys de tres rèpliques, i la llista de «Leftovers» — «Slicing the Pie: CRUSH Failure Domains and Your Capacity», d'Anthony D'Atri, blog oficial de Ceph, datat l'11-11-2026, que inclou a més una calculadora interactiva —la mateixa que la documentació publica com a FD Calc— i el PG Calc reescrit. Són elaboració nostra, a partir d'aquelles mateixes xifres: la comparació entre passar de tres a quatre nodes de 100 (95 → 126,7, un 33 % més) davant d'engreixar-ne un dels tres (95 → 95); l'exemple del sisè node amb cinc de 100, amb sostre de 250 en rèplica 3 i de 100 en 4+2; el càlcul que els 10,5 que es deixa CRUSH sense balancejador són un 7 % de la capacitat usable; els percentatges de marge del 85 % i el 93 % del sostre en el cas 4+2 de sis i set nodes, i el 17 % de capacitat extra del setè node; els 1.551 del quart node de 1.701, que surten de restar-li el topall útil de 150 que publica l'article i no de la seva convenció de capacitat encallada (que per a aquell cas dóna 78 % del cru); la formulació de la capacitat com a cru repartible ÷ n després del full_ratio; les cinc ordres de comprovació; i el «quan no» del final. Fotografia: «20-Bay Hard Drive Case 20251006 – fünf 3,5"-HDDs», de PantheraLeo1359531, CC BY 4.0 via Wikimedia Commons, original de 9.531 × 6.357, retallada i aclarida per nosaltres.