Vas posar noout per actualitzar Ceph i vas apagar la reposició de còpies

El procediment d'actualització de Ceph a Proxmox et recomana, al seu pas quatre, que executis ceph osd set noout: «optional, but recommended», diu el wiki. La documentació de Ceph, a la seva pàgina de resolució de problemes d'OSD, diu que això és «més un exercici mental» que un suggeriment que ningú «al món post-Luminous» ho executi. Les dues frases estan publicades avui i totes dues són defensables. La que decideix si el teu clúster reposa una còpia perduda aquesta nit és la segona.

Operem Proxmox VE amb Ceph en producció, repartit en diversos datacenters, de manera que aquesta bandera l'hem posat nosaltres moltes vegades i la continuarem posant. Aquest post no va de si noout està malament. Va de què apaga exactament, dels dos avisos que no llegiràs mentre estigui posada, i de les quatre ordres que fan la mateixa feina sense desactivar l'automatisme de tot el clúster.

L'octubre és el mes en què molta gent tocarà el seu Ceph

La taula de versions actives de la documentació de Ceph, avui, diu això: Squid, publicada el 26 de setembre del 2024, última 19.2.6, fi de vida estimada el 31 d'octubre del 2026. Tentacle, publicada el 18 de novembre del 2025, última 20.2.4, fi de vida estimada l'1 de juny del 2027. Perdre el suport d'una branca de Ceph no vol dir que el clúster s'apagui: vol dir que deixen d'arribar els backports, inclosos els de seguretat. Així doncs, a qui estigui a Squid li queden setmanes de pedaços, i això converteix l'octubre en un mes de finestres de manteniment.

Aquesta paraula, «estimada», no és decorativa, i ja en vam escriure: la data de Squid es va moure del 19 de setembre al 31 d'octubre en un commit sense anunci, i en el mateix moviment Tentacle va perdre 170 dies de vida útil estimada. Aquí ens interessa la conseqüència pràctica: molta gent executarà el guió d'actualització de Squid a Tentacle aquest mes.

Aquest guió, al wiki de Proxmox, té una forma molt reconeixible: canviar el repositori, posar la bandera (i t'ofereix fer-ho des de la interfície, a la pestanya OSD, amb un botó que es diu Manage Global Flags), apt update i apt full-upgrade, reiniciar els monitors d'un en un, els managers, els OSD node a node, els MDS si hi ha CephFS, fixar ceph osd require-osd-release tentacle i, al final de tot, treure la bandera. L'últim pas de la llista és el que es queda sense fer. No per deixadesa: perquè la finestra no s'acaba quan s'acaba el procediment, sinó quan algú decideix que s'ha acabat, i aquest algú fa quatre hores que mira ceph -s a les dues de la matinada.

El que noout apaga no és el rebalanceig

La majoria la posa amb una idea al cap: «evito que el clúster es posi a moure terabytes mentre reinicio un node». La documentació és més concreta que aquesta idea. A la llista de comprovacions de salut, l'avís OSDMAP_FLAGS descriu noout així: els OSD en estat down no passen automàticament a out un cop transcorregut l'interval configurat.

Aquest interval configurat té nom i valor: mon_osd_down_out_interval, 10 minuts per defecte, descrit com «marca com a out qualsevol OSD que porti down aquest temps». I la diferència entre els dos estats és tota la conversa: down vol dir «no contesta»; out vol dir «surt del repartiment». És el pas a out el que fa que CRUSH recalculi on va cada còpia i el que posa en marxa la creació de la còpia que falta en un altre disc. Si mai no arriba a out, el clúster no reposa res pel seu compte. Marcar-lo out a mà sí que funciona, fins i tot amb la bandera posada; el que cal és que algú se n'hagi adonat.

I aquí hi ha el detall que canvia la conversa: la bandera no distingeix. No sap que l'osd.7 és avall perquè acabes de reiniciar-lo tu i que l'osd.12 és avall perquè se li ha mort l'electrònica. Per a ella són el mateix estat i reben el mateix tracte. Amb rèplica 3, això vol dir dues còpies on el teu disseny en diu tres, i un avís PG_DEGRADED que defineix exactament això: «la redundància de dades està reduïda per a algunes dades». Vam escriure fa una setmana sobre què es cura sol i què no en un Ceph de tres nodes; això és un esglaó per sobre, perquè aquí la curació l'impedeix una decisió teva, presa fa sis hores i escrita enlloc.

El manual de Ceph diu, amb aquestes paraules, que no la facis servir

A la pàgina de resolució de problemes d'OSD, just després d'explicar com es posa la bandera global, hi ha un requadre d'advertiment. Traduït, diu: «això és més un exercici mental ofert amb el propòsit de donar al lector una idea dels dominis de fallada i del comportament de CRUSH que un suggeriment que ningú al món post-Luminous executi ceph osd set noout». I el requadre continua, i convé citar-lo sencer: «quan els OSD tornin a l'estat up, el rebalanceig es reprendrà i el canvi introduït per l'ordre quedarà revertit». És a dir: el projecte la desaconsella perquè la considera poc útil. El motiu pel qual la desaconsellem nosaltres és un altre i ve a continuació.

Luminous és del 2017. Aquesta frase no és el comentari d'un fòrum: és a la documentació oficial del projecte, a la pàgina de resolució de problemes d'OSD, i el paràgraf següent ofereix l'alternativa sense embuts: a Luminous i posteriors, és més segur marcar únicament els OSD afectats.

Convé dir l'altra cosa també, perquè si no això es converteix en un pim-pam fàcil: el procediment de Proxmox no és imprudent. Demana la bandera global perquè és un procediment genèric que ha de funcionar igual en un clúster de tres nodes i en un de trenta, i perquè l'alternativa exigeix saber el nom del bucket CRUSH de cada host. Per a un manual, és una decisió raonable. El que no és raonable és que aquest manual, escrit per a tothom, sigui l'únic que decideix la postura de redundància del teu clúster concret durant sis hores.

El fre que ja tenies posat i no sabies

Hi ha un paràmetre que gairebé ningú mira i que ja fa, per defecte, bona part del que la gent creu que compra amb noout: mon_osd_down_out_subtree_limit. La seva descripció és «la unitat CRUSH més petita que Ceph no marcarà automàticament com a out», amb un exemple explícit: si val host i cauen tots els OSD d'un host, Ceph no els traurà sol. El seu valor per defecte és rack.

Llegeix-ho a poc a poc, perquè diu dues coses alhora. La primera: l'escenari que de debò fa por ja està frenat. Si desapareix un rack sencer —o qualsevol unitat igual o més gran—, Ceph no es posa a recol·locar desenes de terabytes pel seu compte. Amb un matís important: si el teu mapa CRUSH és el pla de sèrie —arrel i hosts, sense buckets de tipus rack—, l'únic nivell que arriba a aquesta mida és l'arrel sencera, de manera que la protecció real és força menor del que sona. La segona, la que importa per a la finestra d'aquesta nit: un host no està frenat. Si reinicies un node i triga més de deu minuts a tornar, els seus OSD sortiran del repartiment. Aquest cas, i no un altre, és el que justifica tocar una bandera. I abans de teclejar convé fer-se una altra pregunta: quin domini de fallada tocaré? Si la resposta és un host, la bandera és d'aquell host.

I el que gairebé ningú explica: un PG degradat no es scrubeja

Aquesta part no surt a cap procediment d'actualització i és la que ens va fer escriure el post. La comprovació de salut PG_NOT_SCRUBBED inclou una frase que, llegida fora de context, sembla un detall d'implementació: «els PG es revisen només si estan marcats com a clean… els PG mal col·locats o degradats no es marcaran com a clean». La de PG_NOT_DEEP_SCRUBBED diu el mateix de manera més prudent, amb un «potser no».

El deep scrub és el mecanisme que compara els checksums de les còpies i troba la corrupció silenciosa: l'avís OSD_SCRUB_ERRORS, que aixequen les revisions en general, existeix precisament perquè «revisions recents han descobert inconsistències». Ara encadena les peces en l'ordre en què passen:

• Poses noout per a la finestra.
• Un disc es mor de debò (no és el que vas reiniciar tu).
• El seu OSD es queda en down i mai no arriba a out: no es reposa la còpia.
• Els PG que hi vivien queden degraded, per tant deixen d'estar clean.
• En no estar clean, deixen de revisar-se.

És a dir: l'únic mecanisme que verifica que les dues còpies que et queden continuen sent correctes deixa d'executar-se just sobre les dades a les quals els falta una còpia. Això no és la suma de dos problemes. És un problema que apaga el detector de l'altre.

Un clúster groc permanent és un clúster sense alarma

Algú dirà, amb raó, que Ceph avisa que no s'està revisant. És cert, i es pot calcular quan. L'interval màxim de revisió superficial, osd_scrub_max_interval, són 7 dies; l'avís salta quan passa un percentatge extra d'aquest interval marcat per mon_warn_pg_not_scrubbed_ratio, que per defecte és 0,5: tres dies i mig més, és a dir, 10 dies i mig. Per al deep scrub, osd_deep_scrub_interval són uns altres 7 dies i el ratio mon_warn_pg_not_deep_scrubbed_ratio és 0,75: 12 dies i quart.

Aquests dos avisos existeixen i funcionen. Aquests avisos arriben. La qüestió és on arriben. Des del segon en què vas executar ceph osd set noout, el clúster està en HEALTH_WARN per OSDMAP_FLAGS. Si la bandera continua posada dotze dies després, l'avís del deep scrub aterra en un tauler que fa dotze dies que és groc, sota una línia que tothom ha après a ignorar perquè «és la de l'actualització». Un groc nou dins d'un groc vell no és una alerta: és la mateixa línia d'ahir. La bandera no només desactiva una funció; desactiva el canal pel qual Ceph t'ho explicaria.

La mateixa entrada OSDMAP_FLAGS descriu les altres banderes de la família, i val la pena posar-les una al costat de l'altra amb el que la gent creu que fan:

Les tres primeres files es posen juntes amb una freqüència que fa respecte, normalment copiant una línia d'un fil de fòrum. Però la pitjor de totes per deixar-se posada és l'última. Amb nodown, un OSD realment mort continua apareixent amunt al mapa, perquè els monitors han deixat de fer cas a qui els informa del contrari. I això ja no és un groc que ignores: és un verd que no és veritat.

Les quatre ordres que fan el mateix sense apagar el clúster

L'alternativa que proposa la mateixa documentació cap en quatre línies. La bandera deixa de ser del clúster i passa a ser del disc o del host que tocaràs:

# un sol disc que trauras o substituirasceph osd add-noout osd.12
ceph osd rm-noout  osd.12

# el host sencer que reiniciaras (nom del bucket CRUSH)ceph osd set-group   noout nodo-03
ceph osd unset-group noout nodo-03

Això no et deixa sense avís: hi ha una comprovació de salut pròpia, OSD_FLAGS, que salta quan «un o més OSD, nodes CRUSH o classes de dispositiu tenen una bandera d'interès posada». Continues tenint el teu groc. La diferència és que ara és un groc que anomena tres OSD concrets en comptes d'un que tapa el clúster sencer, i que mentre el tens posat, la resta del clúster conserva el seu automatisme: si durant la teva finestra es mor un disc en un altre node, aquell sí que surt als deu minuts i la seva còpia es reposa sola, que és exactament el que volies que passés.

La comprovació de trenta segons, i la que falta a la teva monitorització

Abans de continuar llegint, mira si en tens alguna posada ara mateix. Són tres ordres i cap no canvia res:

ceph -s                     # avisa de les banderes posades, sota healthceph osd dump | grep ^flags # les banderes globals, en cruceph health detail          # OSDMAP_FLAGS i OSD_FLAGS, amb el detall

Si surt noout, nodown, noin o noup —la resta del que llista osd dump hi és de sèrie—, la pregunta següent no és tècnica: qui la va posar, per a què, i quan s'havia de treure? Si ningú no sap respondre les tres, la bandera fa més temps posada del que ningú recorda i la teva redundància real no és la que figura al disseny.

I la part que sí que és feina nostra: vigilem els clústers amb Zabbix, i la regla que importa aquí no és «avisa'm si el clúster no és en HEALTH_OK». Aquesta alerta se silencia el primer mes, per bones raons, i a partir d'aquí no serveix de res. La regla útil és una altra: avisa'm si hi ha una bandera posada i han passat més de N hores des que es va posar. Una bandera de manteniment és un canvi manual amb data de caducitat implícita; l'alerta ha de ser sobre la caducitat, no sobre l'estat.

Això no és una mania nostra. El treball clàssic d'Oppenheimer, Ganapathi i Patterson sobre per què fallen els serveis d'internet (USENIX, 2003) va posar l'error d'operador al capdavant de les causes de caiguda en dos dels tres serveis que va estudiar, per davant del maquinari, i dins seu la mala configuració era el subtipus dominant. El paper a més precisa quan passa: mentre els operadors «feien canvis al sistema, per exemple desplegant o actualitzant programari». ceph osd set noout és, literalment, un canvi de configuració manual fet per un operador. És a la categoria guanyadora.

El que no estem dient

No hem perdut dades per això, i no ens inventarem un cas de client per arrodonir el post. El que hi ha aquí és la documentació llegida sencera i l'aritmètica feta. La bandera global no és un error en si mateixa: és un procediment genèric aplicat a un clúster concret, i tot el risc és en quant dura, no en l'acte de posar-la. Mitja hora de noout amb algú al davant és una cosa; tres setmanes perquè ningú no va tancar la finestra és una altra de ben diferent.

Els valors que hem citat són els valors per defecte. Si algú va tocar mon_osd_down_out_interval, el subtree_limit o els dos ratios d'avís, els teus números no són aquests; comprova'ls amb ceph config get mon mon_osd_down_out_interval i ceph config get mgr mon_warn_pg_not_deep_scrubbed_ratio abans de fiar-te del càlcul. I les dates de fi de suport de la taula de versions vénen marcades com a estimades pel mateix projecte, que ja les ha mogut més d'una vegada.

El conflicte d'interès, per davant: no som revenedors de Proxmox ni venem subscripcions de Ceph, no cobrem comissió per cap de les dues. Operar clústers aliens i fer aquestes finestres de matinada sí que ho facturem.

Fonts (verificades el 2 d'octubre del 2026): la taula de versions actives amb Squid 19.2.6 (inicial 26-09-2024, fi de vida estimada 31-10-2026) i Tentacle 20.2.4 (inicial 18-11-2025, fi de vida estimada 01-06-2027) — índex de versions de Ceph; la descripció literal de noout, nodown, noscrub/nodeep_scrub i nobackfill/norecover/norebalance, la comprovació OSD_FLAGS per a OSD i buckets, la definició de PG_DEGRADED, OSD_SCRUB_ERRORS i les frases sobre que els PG degradats no es marquen com a clean a PG_NOT_SCRUBBED i PG_NOT_DEEP_SCRUBBED — comprovacions de salut de Ceph; l'advertiment de l'«exercici mental» i les ordres add-noout, rm-noout, set-group i unset-group — resolució de problemes d'OSD; mon_osd_down_out_interval (10 minuts) i mon_osd_down_out_subtree_limit (rack) — interacció monitor-OSD; osd_scrub_max_interval i osd_deep_scrub_interval (7 dies cadascun) — configuració d'OSD; els valors per defecte 0,5 i 0,75 dels dos ratios d'avís — src/common/options/global.yaml.in del codi de Ceph; el procediment amb ceph osd set noout, el botó Manage Global Flags i l'unset final — wiki de Proxmox, actualització de Ceph Squid a Tentacle; els canvis de configuració manuals com a causa principal de caigudes greus — Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. La lectura que la bandera apaga el detector de l'altre problema, l'aritmètica dels 10,5 i 12,25 dies i la regla d'alerta per antiguitat de la bandera són nostres, no d'aquelles fonts.