El teu Ceph de tres nodes no es cura sol: aguanta

Si en un clúster de tres nodes es mor un disc, Ceph ho arregla sol mentre dines. Si es mor el node sencer, no arregla res: es queda esperant que torni. Aguantar i curar-se són dues coses diferents amb dues factures diferents, i la diferència és a quants llocs diferents té Ceph on deixar-hi una còpia.

Comencem pel que ve posat. El manual de Proxmox VE diu, a la seva pàgina de Ceph, que en crear un pool «we set a default of 128 PGs, a size of 3 replicas and a min_size of 2 replicas». Tres còpies, i el clúster accepta escriptures mentre en quedin dues. Aquestes tres còpies van a hosts diferents, i això tampoc no és un costum: ho decideix osd_crush_chooseleaf_type, que val 1 per defecte. La documentació de Ceph ho lletreja quan explica com muntar un clúster d'un sol node, perquè allà cal abaixar-lo «from the default of 1 (meaning host or node) to 0 (meaning osd)». Amb tres servidors i tres còpies el compte surt exacte: cada host guarda una còpia absolutament de tot.

Aquesta exactitud és el problema. Un disseny on el compte surt exacte es queda sense marge tan bon punt hi falta un sumand.

Un disc mort sí que s'arregla sol

Convé començar pel cas bo. Si es mor un disc i el host continua viu, la regla de CRUSH tria primer un host i després baixa a un disc de dins, així que hi ha on recol·locar la còpia: un altre OSD del mateix servidor. El clúster reconstrueix i torna a HEALTH_OK sense que ningú toqui res. I això no és una configuració rara: el mateix manual de Proxmox recomana «at least three nodes and at least 12 OSDs, evenly distributed among the nodes», o sigui quatre discos per servidor en el mínim recomanat.

Tot el que ve a partir d'aquí tracta de l'altre cas: el host sencer que se'n va, que és el cas que decideix si el teu pla de continuïtat val alguna cosa.

Els rellotges que ningú no mira

Posem que un node perd el corrent. El primer que passa és una absència de batecs. Els OSD es fan ping cada sis segons (osd_heartbeat_interval) i donen per caigut el veí que en porta vint sense contestar (osd_heartbeat_grace), tot i que aquest termini tampoc no és rígid: mon_osd_adjust_heartbeat_grace ve activat i Ceph l'estira per als OSD amb historial d'anar i venir. Els veïns el denuncien al monitor, i calen dos denunciants (mon_osd_min_down_reporters), comptats al nivell de cub que fixa mon_osd_reporter_subtree_level, per defecte host. Amb tres hosts i un de caigut queden just dos cubs des d'on denunciar, que és exactament el que demana el paràmetre: la detecció funciona, però deixa de funcionar amb dos hosts, i aquest és el terra real d'aquest disseny.

Entre «caigut» i «fora» hi ha un segon rellotge, i és el que importa, perquè marcar un OSD com a out és el que dispara el moviment de dades: mon_osd_down_out_interval, deu minuts per defecte. Deu minuts en què, expressament, no es mou ni un byte. Està ben pensat: el reinici d'un switch no hauria de provocar la migració d'un clúster sencer. Però és un termini publicat, així que va dins del teu RTO en comptes d'aparèixer com una sorpresa el dia dolent. Tampoc no és fix: mon_osd_adjust_down_out_interval ve en true, o sigui que Ceph l'escala segons la seva estimació de si aquell OSD és dels inestables.

Hi ha un tercer rellotge, més lent, per al node que no es mor del tot. Si un OSD deixa simplement de donar part al monitor, el termini per declarar-lo caigut és mon_osd_report_timeout, quinze minuts. Aquest és el camí del servidor que no s'apaga però tampoc no contesta, la fallada que de debò costa diagnosticar.

Passats els deu minuts tampoc no passa res

El monitor marca els OSD del node mort com a out i Ceph intenta col·locar la tercera còpia en un altre lloc. Amb el domini de fallada en host i tres hosts dels quals un és fora, aquest altre lloc no existeix: els dos supervivents ja tenen la seva còpia i la regla prohibeix posar dues còpies de la mateixa dada al mateix host. Els grups de col·locació es queden en active+undersized+degraded, que la documentació de Ceph descriu amb aquestes paraules: «have the degraded or undersized flag set, which means that there are not enough instances of that PG in the cluster».

Potser ni tan sols veus tots aquests OSD en estat out. Ceph porta un fre, mon_osd_min_in_ratio amb valor 0,75, que és «the minimum ratio of in Ceph OSD Daemons before Ceph will mark Ceph OSD Daemons out»: en un clúster amb molts discos per servidor, buidar un host sencer topa amb aquest límit i part dels seus OSD es queden en down sense arribar a out. La conclusió no canvia —tampoc no hi ha recuperació— però explica per què el ceph osd tree que miris després pot no coincidir amb el que esperaves.

Mentrestant el clúster continua servint: queden dues còpies i min_size és dos, així que les teves màquines escriuen com si res. Per això gairebé ningú no se'l mira. Un clúster degradat que funciona genera un avís groc en un tauler; un clúster aturat genera vint trucades. I l'avaria que no genera trucades és la que es queda setmanes.

El preu d'aguantar és a la mateixa pàgina del manual

El manual de Proxmox VE té una frase que gairebé tothom llegeix en un altre context —és a l'apartat de canviar la xarxa de Ceph— i que és en realitat la regla d'operació d'un clúster degradat: «Do not restart OSDs on multiple hosts at the same time. Chances are that for some PGs (placement groups), 2 out of the (default) 3 replicas will be down. This will result in I/O being halted until the minimum required number (min_size) of replicas is available again».

Llegeix-la un altre cop amb un node ja fora. Un host caigut converteix qualsevol operació sobre un segon host exactament en l'escenari que aquella frase prohibeix. Actualitzar el kernel del node 2 i reiniciar-lo, canviar-li un disc, moure'l de cable: qualsevol d'aquestes coses deixa alguns grups de col·locació per sota de min_size i l'entrada/sortida s'atura en sec fins que torni el segon. Mentre un node és fora et quedes sense finestra de manteniment als altres dos. Aquest és el preu d'aguantar, i no apareix a cap factura.

El node que torna porta el trànsit

El dia que tornes el node al clúster comença el que no havia passat fins llavors: reconstruir tot el que es va escriure mentre era fora. I aquí hi ha una altra frase del manual de Proxmox que mereix llegir-se dues vegades: «The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum».

La curació et pot costar el quòrum. Si el trànsit de Ceph i el de corosync comparteixen cable, la recuperació que arregla l'emmagatzematge és capaç de tombar el clúster que el sosté, i ja hem explicat el poc que tolera corosync en latència. D'aquí que el manual demani com a mínim 10 Gbps exclusius per a Ceph i, en instal·lacions d'alt rendiment, tres xarxes físiques separades. És la condició perquè la recuperació no sigui el segon incident del dia.

Sobre quant dura aquesta reconstrucció el manual és honest i curt: «Especially with small clusters, recovery might take long», i recomana SSD en instal·lacions petites «to reduce recovery time, minimizing the likelihood of a subsequent failure event during recovery». O sigui que el motiu de comprar SSD en un clúster de tres és escurçar la finestra en què una segona fallada et troba sense xarxa, més que el rendiment diari. Hi ha una altra decisió de compra amagada a la mateixa pàgina: «a single OSD failure forces Ceph to recover more data at once» com més gran sigui el disc. Criteri nostre, no del manual: aquesta dada lluita contra el preu per terabyte, que empeny sempre cap a discos més grans, i convé decidir-ho a consciència —igual que la capacitat útil la marca el disc més ple i no la suma del full de càlcul—.

La memòria que no tens el dia que la necessites

En un clúster hiperconvergit els dos supervivents han de fer dues coses alhora, i totes dues costen memòria. Una: arrencar les màquines del node mort, perquè per això hi ha l'alta disponibilitat —que no evita la caiguda, l'escurça—. Dues: pagar el sobrecost de memòria de Ceph mentre reconstrueix. El manual de Proxmox ho diu sense embuts: els OSD consumeixen més «during critical operations, such as recovery, rebalancing, or backfilling», recomana 8 GiB per OSD i adverteix que no s'apuri la memòria en operació normal, sinó «leave some headroom to cope with outages».

Si vas dimensionar la RAM per al dia bo, el dia dolent tens un problema de memòria a sobre del problema d'emmagatzematge. I arriba just quan l'alta disponibilitat acaba de repartir les màquines del node mort entre dos supervivents, que és un cinquanta per cent més de càrrega a cadascun. La capçalera de memòria d'un clúster de tres no és un luxe d'arquitecte: és la meitat del teu pla de recuperació.

Compta llocs, no nodes

El que separa «aguantar» de «curar-se» és un número petit: un domini de fallada més que còpies. Amb rèplica 3 i quatre hosts, quan se'n mor un queden tres llocs diferents, Ceph té on deixar la tercera còpia, reconstrueix, i en acabar tornes a estar protegit contra la següent fallada sense que ningú hagi anat al centre de dades. Amb tres hosts això no passa mai quan el que es mor és el host, per molts discos que hi tinguis dins. El quart node no compra capacitat: compra el permís de Ceph per curar-se sol. La mateixa aritmètica, amb altres números, és la que decideix si et compensa rèplica 3 o erasure coding.

La pega que més vegades hem vist oblidar mereix el seu propi paràgraf: un domini de fallada és el que es creu CRUSH, no el que diu la factura. Si el quart servidor penja de la mateixa regleta, del mateix switch i de la mateixa sala que els altres tres, has comprat un host més i no un lloc més; contra la fallada que de debò et tomba, la de la sala, continues tenint-ne un de sol. El que CRUSH sap de la teva instal·lació és el que li hagis explicat, i per defecte l'única cosa que sap és com es diu cada màquina. Les altres dues pegues són més suportables: el quart node costa diners i afegeix trànsit i un vot més, i no ha de ser monitor —el manual diu «You won't need more than 3 monitors, as long as your cluster is small to medium-sized»—.

El que comprovem abans de signar un clúster de tres

• Quant triga aquest clúster a tornar de degradat a HEALTH_OK des que el node torna, mesurat un cop amb les dades que té avui i no amb les que tenia buit el dia de la instal·lació. Aquest número entra al pla; el del full del fabricant no.
• La finestra de «no es toca», per escrit: mentre un host sigui fora, el segon no es reinicia, no se li canvia un disc i no se li toca un cable. I amb ella l'ús deliberat de ceph osd set noout per al manteniment planificat, que és l'altra meitat de la conversa. Escrit i signat, no sabut. Un estudi clàssic sobre per què fallen els grans serveis d'internet (Oppenheimer, Ganapathi i Patterson, USENIX 2003) va situar els canvis manuals de configuració per davant del maquinari com a causa, i la finestra degradada és exactament el moment en què un canvi raonable surt car.
• Regleta, switch, sala: els llocs comptats un a un. Amb aquesta llista al davant es decideix si el domini de fallada de la regla CRUSH continua sent host o ha de pujar un nivell. I de passada es mira mon_osd_down_out_subtree_limit, que existeix per no buidar de cop un subarbre sencer i ve posat en rack: si el teu mapa no té racks, aquest fre no arriba a entrar mai.
• Separar de debò la xarxa de Ceph de la de corosync. No una VLAN diferent sobre el mateix parell de cables: separada. És la diferència entre una recuperació lenta i una recuperació que s'emporta per davant el quòrum.
• I la còpia, fora del clúster. Rèplica 3 no és còpia de seguretat: un clúster que aguanta un node mort no et torna un fitxer esborrat per error ni sobreviu a un xifratge. Això és recuperació davant desastres, un altre problema i una altra factura.

El que no estem dient

Tot l'anterior descriu la configuració per defecte: tres hosts, rèplica 3, domini de fallada host. Si el teu mapa CRUSH té un altre nivell o si algú va tocar la regla, la conclusió canvia. La comprovació són dues ordres, ceph osd crush rule dump i ceph osd tree, costen deu segons i valen més que qualsevol cosa que diguem nosaltres.

Tampoc no estem dient que un Ceph de tres nodes estigui mal dissenyat. Tres és el mínim documentat —«you must use at least three (preferably) identical servers»— i funciona; nosaltres operem Proxmox VE amb emmagatzematge Ceph en producció, repartit en diversos centres de dades, i treballem amb Proxmox des de les branques 3.x. Per a moltes empreses, tres nodes ben muntats protegeixen més que una cabina cara a la qual mai no han fet una commutació de debò.

I no estem dient «compra't un quart node». Si el pressupost arriba a tres, la resposta no és més ferro: és un procediment escrit per a la finestra degradada i una còpia que visqui fora. L'única cosa que sostenim és que «es cura sol» no forma part del que compres amb tres quan el que es perd és un servidor sencer, i que un pla de continuïtat que doni per feta aquesta curació està comptant amb una cosa que la configuració per defecte no ofereix.

A everyWAN dissenyem i operem emmagatzematge distribuït amb Ceph i la infraestructura que el sosté, sobre Proxmox VE i en producció. No venem llicències de ningú, així que quan diem que amb tres nodes no hi ha recuperació automàtica d'un host no ens ho paga ningú, ni per dir-ho ni per callar-ho.

Fonts (consultades el 25-set-2026): els valors per defecte de osd_heartbeat_interval (6 s), osd_heartbeat_grace (20 s), mon_osd_adjust_heartbeat_grace (true), mon_osd_min_down_reporters (2), mon_osd_reporter_subtree_level (host), mon_osd_down_out_interval (10 minuts), mon_osd_report_timeout (15 minuts), mon_osd_adjust_down_out_interval (true), mon_osd_min_in_ratio (0,75) i mon_osd_down_out_subtree_limit (rack) són a Configuring Monitor/OSD Interaction de la documentació de Ceph (branca Tentacle). La descripció de PG_DEGRADED i de les banderes degraded i undersized és a Health checks. Que osd_crush_chooseleaf_type val 1 per defecte és a Pool, PG and CRUSH config reference, i la frase que tradueix aquest 1 a «host or node» és a Troubleshooting PGs. En aquesta mateixa referència, osd_pool_default_size val 3; compte amb osd_pool_default_min_size, el valor per defecte del qual és 0 i significa «no particular minimum», que Ceph avalua com size − (size/2) i amb rèplica 3 dona 2 —el 2 explícit el fixa Proxmox en crear el pool, segons el seu propi manual—. Les cites de Proxmox (tres servidors com a mínim, el pool per defecte, els 12 OSD repartits, no reiniciar OSD de diversos hosts alhora, el trànsit de recuperació i el quòrum de corosync, 10 Gbps exclusius, 8 GiB per OSD i la capçalera de memòria, la recomanació d'SSD en clústers petits, que un OSD més gran obliga a recuperar més de cop i el nombre de monitors) són al capítol de Ceph del manual de Proxmox VE. La referència sobre el pes de l'error humà davant del maquinari a les caigudes greus és Oppenheimer, Ganapathi i Patterson, Why Do Internet Services Fail, and What Can Be Done About It?, USENIX 2003. El que aquest post NO afirma: no hem reproduït la caiguda d'un node al laboratori per a aquest post; el comportament descrit es dedueix de la documentació citada i de la regla de rèplica per defecte, i per això insistim que el que es pot comprovar al teu clúster són ceph osd crush rule dump i ceph osd tree. Els temporitzadors són valors per defecte i poden estar canviats a la teva instal·lació (ceph config get). No donem cap xifra de durada d'una recuperació real perquè depèn del volum, del disc i de la xarxa, i qualsevol número que donéssim seria inventat. I la regla de comptar llocs en comptes de nodes, igual que la lectura del preu per terabyte davant del temps de reconstrucció, són criteri nostre i no recomanació de cap fabricant.