En un clúster Ceph amb 384 TB bruts, rèplica 3 et deixa 128 TB útils. L'erasure coding 4+2 te'n deixa 256, aguantant les mateixes dues fallades simultànies. El doble d'espai amb el mateix maquinari: la mateixa documentació de Ceph ho diu així de clar. I tot i això, nosaltres —que operem Ceph en producció, repartit en diversos datacenters— seguim posant els discos de les VMs en rèplica 3. No és nostàlgia. És que el de l'espai és només un dels quatre comptes, i els altres tres gairebé mai no surten a la presentació.
El compte que surt a les presentacions: l'espai
Primer, què fa cadascun. Amb rèplica 3 (el tipus de pool per defecte a Ceph), cada objecte s'escriu sencer tres vegades, en tres OSDs de tres hosts diferents. Sobrevius a la pèrdua de dues còpies perquè sempre en queda una tercera. El preu: per cada TB de dades consumeixes 3 TB de disc. Factor 3,0; un 33% d'espai útil.
Amb erasure coding, l'objecte es trosseja en k fragments de dades i es calculen m fragments de paritat. Amb el perfil 4+2, cada objecte són 6 fragments en 6 hosts, i amb 4 de qualssevol es reconstrueix la dada: aguantes la pèrdua de 2. La sobrecàrrega és (k+m)/k = 1,5; un 67% d'espai útil. És el RAID 6 elevat a sistema distribuït.
| Amb 384 TB bruts (6 nodes × 8 discos de 8 TB) | Rèplica 3 | EC 4+2 |
|---|---|---|
| Espai útil | 128 TB (33%) | 256 TB (67%) |
| Fallades simultànies que aguanta | 2 | 2 |
| Hosts mínims (domini de fallada = host) | 3 (còmode amb 4) | 6 (còmode amb 7) |
| Escriptures petites aleatòries (VMs, BBDD) | El seu terreny | El seu punt feble |
Fins aquí el compte de l'espai, i el guanya l'erasure coding per golejada: mateix ferro, mateixa tolerància, 128 TB més. Si l'anàlisi s'acaba en aquesta taula, migres tots els pools aquesta mateixa tarda. Seguim amb els comptes que no surten.
El compte de les escriptures
Una escriptura en rèplica 3 és avorrida, i això és un elogi: l'OSD primari rep l'objecte i envia dues còpies íntegres als seus companys. Tres escriptures, zero matemàtiques, latència predictible.
Una escriptura en EC 4+2 trosseja l'objecte, calcula dos fragments de paritat (CPU) i reparteix sis escriptures entre sis hosts. Per a escriptures grans i seqüencials, aquest cost s'amortitza bé. El problema és l'escriptura petita i aleatòria —exactament el que generen una VM o una base de dades—: modificar 4 KB dins d'una franja implica llegir fragments, recalcular la paritat i tornar a escriure. On rèplica feia tres escriptures i dormia tranquil·la, l'EC munta una operació de lectura-modificació-escriptura repartida pel clúster.
No ho diem només nosaltres. La documentació oficial de Ceph ho escriu amb aquestes paraules: «no confonguis l'erasure coding amb un dinar gratis: hi ha un sacrifici de rendiment significatiu, especialment amb discos HDD i durant la recuperació o el backfill del clúster». Quan la documentació d'un producte t'avisa així de la seva pròpia funcionalitat, convé escoltar-la.
Es pot posar un disc de VM sobre un pool EC? Poder-se, es pot: des de Luminous existeix allow_ec_overwrites (només sobre BlueStore) per permetre escriptures parcials, i RBD funciona. La pregunta mai no va ser si es pot. És si vols pagar aquest peatge a cada escriptura petita de cada VM, per sempre.
El compte de la recuperació
El dia que un disc mor és quan es paga l'arquitectura. En rèplica, recuperar és copiar: els OSDs que tenen les còpies supervivents les reenvien, i llestos. En erasure coding, cada fragment perdut es reconstrueix: cal llegir k fragments d'altres OSDs, refer les matemàtiques i escriure el resultat. Més lectures, més trànsit entre nodes i més CPU, just en el moment en què el clúster està degradat i les teves VMs segueixen demanant IOPS com si no passés res. És la diferència entre fotocopiar una pàgina i tornar-la a redactar a partir dels apunts de quatre companys.
El compte dels nodes (el que decideix en una pime)
Aquest és el compte que més vegades tanca la conversa. Amb el domini de fallada al host —el mínim seriós—, un pool EC necessita almenys k+m hosts: 6 nodes per a un 4+2. I la mateixa documentació recomana tenir k+m+1 perquè el clúster pugui auto-reparar-se amb un node caigut: 7 nodes. Rèplica 3 funciona amb 3 i està còmoda amb 4.
Si el teu clúster té 3, 4 o 5 nodes —la majoria dels clústers de virtualització que veiem en pimes—, la decisió està presa abans de començar: no hi ha dominis de fallada suficients per a un EC seriós. Perfils petits tipus 2+1? Existeixen, i són el RAID 5 dels pobres: una sola fallada tolerada i una reconstrucció amb el clúster aguantant la respiració. Nosaltres no posem m=1 en producció amb dades que importin, i la documentació de Ceph tampoc no recomana alegries: per a bloc i fitxer suggereix no passar de m=3, i en general no triar k>4 o m>2 sense entendre molt bé les conseqüències.
On sí que brilla l'erasure coding
Res d'això no converteix l'erasure coding en mala tecnologia. És una eina excel·lent per a la feina correcta: dades que s'escriuen una vegada, en blocs grans, i sobretot es llegeixen.
- ✓Backups i arxiu: repositoris de còpies, dades fredes, retencions llargues. Escriptura seqüencial gran, lectura ocasional. El cas perfecte.
- ✓Emmagatzematge d'objectes (S3/RGW): mèdia, documents, datasets. Aquí un 67% d'espai útil davant d'un 33% són diners de debò a mesura que creixen els TB.
- ✓A Proxmox VE, si el clúster dona la talla, la canonada ja ve posada:
pveceph pool create <nom> --erasure-coding k=4,m=2crea el pool EC de dades i el seu pool replicat de metadades (l'EC no suporta les operacions OMAP que RBD necessita, així que les metadades van a part). L'obstacle mai no és l'eina; és la física.
El que fem nosaltres
- ✓Discos de VM i bases de dades: rèplica 3. Sempre. La latència predictible i la recuperació simple valen més que els TB extres.
- ✓Erasure coding per al que és fred —còpies secundàries, arxiu, objectes— i només quan el clúster té dominis de fallada de sobres per a un perfil seriós.
- ✗Ni rèplica 2 ni m=1 per a dades que importen. Estalviar entre una sisena part i un terç del disc per jugar-te el pool a una sola fallada és una mala compra.
- ✗No muntem un clúster de 7 nodes per perseguir l'estalvi de l'EC en discos de VM. Si el pressupost de discos t'empeny a posar les VMs en erasure coding, el problema no és el tipus de pool: és el dimensionament.
En curt
Rèplica 3 i erasure coding no competeixen: fan feines diferents. Rèplica compra latència baixa i recuperacions simples pagant en disc; l'erasure coding compra espai pagant en CPU, xarxa, complexitat i nodes. La trampa és mirar només la columna de l'espai, que és l'única que surt a la calculadora del pressupost. Un pool per a les VMs, un altre per al que és fred, i els quatre comptes fets abans de crear-ne cap: això és dissenyar emmagatzematge, i no hi ha drecera.
Portem anys operant emmagatzematge distribuït Ceph sota clústers Proxmox en producció, i aquesta decisió —quin pool, quin perfil, quants nodes— l'hem presa moltes vegades amb dades reals al davant. És de les que surten barates de pensar i caríssimes de desfer.
Fonts (verificades): sobrecàrrega (k+m)/k, cita del «free lunch», perfil 4+2 amb «el doble d'espai útil que rèplica size=3», recomanació de m≤3 i de no superar k=4/m=2 sense conèixer les implicacions, allow_ec_overwrites sobre BlueStore i requisit de k+m dominis de fallada (k+m+1 recomanat) — documentació oficial de Ceph; creació de pools EC i pool de metadades replicat a Proxmox VE (pveceph pool create --erasure-coding, EC sense suport complet d'OMAP per a RBD) — documentació de Proxmox VE (pveceph). L'exemple de 384 TB és aritmètica sobre aquestes fórmules.
Dissenyant (o patint) un clúster Ceph?
A everyWAN dissenyem i operem emmagatzematge distribuït Ceph en producció, repartit en diversos datacenters —amb maquinari propi i en infraestructura dels nostres clients—. T'ajudem a fer aquests comptes amb els teus números —càrregues, nodes, creixement— abans que el pool equivocat els faci per tu.
Microsoft 365
ES 
CAT 
EN