Ceph a Tentacle: durant l'actualització el teu clúster corre en dues versions alhora

Ceph 19.2 Squid té el final de vida estimat el 31 d'octubre i Ceph 20.2 Tentacle fa des del 20 de maig que és al repositori empresarial de Proxmox. Amb aquestes dues dates damunt la taula, la finestra de manteniment d'aquesta tardor ja no és una hipòtesi: és un punt al calendari d'algú. I dins d'aquesta finestra hi passa una cosa que gairebé cap pla no contempla, perquè sona a detall i decideix el risc sencer: durant unes hores —de vegades dies— el clúster no corre Squid ni corre Tentacle. Corre les dues alhora.

Operem Proxmox VE amb emmagatzematge Ceph en producció, repartit en diversos centres de dades, així que això s'escriu des del costat de qui obre la finestra. Comencem pel que encara no hem fet: no hem posat Tentacle en producció de cap client. El motiu és al final i no té a veure amb el rendiment.

L'anunci que continua circulant ja no descriu la realitat

El fil de l'anunci original, del 9 de gener, continua sent el primer resultat que troba gairebé tothom en cercar «Proxmox Ceph Tentacle». Diu dues coses molt citables: que Tentacle és «now available on the Proxmox Ceph test repository for installation or upgrade», en estat de vista prèvia, i que Ceph 19.2 Squid «will stay supported until September 2026 for the time being». Totes dues eren certes quan es van escriure. Cap de les dues no descriu el que tens al davant al setembre de 2026.

El 2 de juny, un membre de l'equip de Proxmox ho deixava escrit al fòrum sense cap cerimònia: «Ceph Tentacle is in the enterprise repository since May 20th». El 30 de juny, un altre confirmava que la 20.2.2 era al repositori de proves, i el 30 de juliol un tercer anunciava que «Ceph 20.2.2 is now available in the ceph-tentacle enterprise repository». La guia oficial d'actualització, la que seguiràs pas a pas, ja no parla de vista prèvia enlloc: l'exemple que et posa és la línia enterprise, amb no-subscription i test com a alternatives si no tens subscripció. La porta es va obrir el 20 de maig, sense anunci propi, i el fil que tothom enllaça continua dient que és tancada.

A Proxmox l'estat d'un paquet es comprova al repositori, amb apt policy ceph-common, no al fil del fòrum on es va anunciar. Un anunci és una foto d'un dia. El repositori és el present.

Les dates d'aigües amunt completen el quadre. Squid va sortir el 26 de setembre de 2024 i el projecte Ceph li dona un final de vida estimat el 31 d'octubre de 2026. Tentacle va sortir el 18 de novembre de 2025 i arriba fins a l'1 de juny de 2027. Entre avui i la caducitat de Squid queden menys de dos mesos.

apt no actualitza el teu clúster

Un apt full-upgrade canvia fitxers al disc. Els processos que estan servint el teu emmagatzematge continuen sent, en memòria, exactament els d'abans. Per això el procediment oficial dedica tres passos separats a reiniciar tres coses diferents: systemctl restart ceph-mon.target per als monitors, systemctl restart ceph-mgr.target per als gestors i systemctl restart ceph-osd.target per als OSD. I aquí neix l'estat de què tracta aquest article, perquè aquests tres reinicis no passen alhora ni han de passar alhora. Els monitors, a més, també van d'un node cada vegada.

L'estat mixt està dissenyat, no tolerat

Ceph està pensat per funcionar així. La documentació de l'orquestrador ho diu sense embuts en descriure una actualització: «Each daemon is restarted only after Ceph indicates that the cluster will remain available». Cada dimoni es reinicia només després que Ceph indiqui que el clúster continuarà disponible. I tens una ordre per mirar per on vas, ceph versions, que retorna el recompte de dimonis per versió: quants monitors a cadascuna, quants OSD a cadascuna. Durant bona part de la finestra aquest recompte estarà repartit, i això és exactament el que s'espera.

Convé apuntar un detall abans que et mossegui, perquè el trobaràs tu sol si llegeixes les dues documentacions: no coincideixen en l'ordre dels dos primers passos. El wiki de Proxmox mana reiniciar primer els monitors i després els gestors. La documentació de Ceph, descrivint l'actualització amb el seu propi orquestrador, diu el contrari: «The upgrade order starts with managers, monitors, then other daemons». Són eines diferents i procediments diferents, així que cap dels dos no s'equivoca, però si t'has documentat a les dues pararàs a mitja finestra preguntant-te a quin dels dos has de fer cas. Segueix el de Proxmox: és el que correspon als paquets que tens instal·lats i el que el seu equip prova.

«Reinicia els OSD d'un node cada vegada»

El wiki posa en negreta el tros que importa: «Restart all OSDs. Only restart OSDs on one node at a time to avoid loss of data redundancy». És la instrucció que decideix quant dura la teva finestra, així que mereix entendre's en comptes d'obeir-se a cegues.

L'aritmètica és curta. Un pool amb els valors per defecte de Proxmox guarda tres còpies i n'exigeix dues per servir: mida 3, min_size 2. Si el teu domini de fallada és el node, que és l'habitual en un clúster hiperconvergit, en reiniciar els OSD d'un node tots els grups de col·locació que hi tenien una còpia es queden momentàniament amb dues. Continues servint, no se n'assabenta ningú, i per això està pensat. Però durant aquests minuts ets a una sola fallada que un grup caigui a una còpia, quedi per sota de min_size i deixi de servir tota l'E/S —no només les escriptures: també les lectures d'aquest grup—. Reiniciar dos nodes alhora t'estalvia una tarda i et costa tot el marge que compra aquesta frase.

I una precisió que evita una falsa sensació de seguretat: noout no protegeix d'això. Impedeix el reequilibri, no la degradació. Amb la marca posada, els grups d'aquest node són a dues còpies exactament igual que sense ella. Dit com ho diem sempre: la fallada és inevitable, l'avaria és una decisió de disseny. Durant la finestra estàs renunciant expressament a un nivell de redundància, i això s'ha de decidir despert i amb algú mirant, no un divendres a les set. Convé a més haver fet abans el compte de quant aguanta el teu clúster amb un node menys, perquè si vas just d'espai la finestra deixa de ser una molèstia i passa a ser un risc diferent.

noout: «opcional, però recomanat»

El procediment diu, textualment: «Set the noout flag for the duration of the upgrade (optional, but recommended)». L'ordre és ceph osd set noout. Aquí ens mullarem: dir-ne opcional és tècnicament cert i operativament enganyós.

Sense aquesta marca, Ceph fa el que fa sempre amb un OSD que deixa de respondre: espera i el treu del clúster. El paràmetre que governa aquesta espera, mon_osd_down_out_interval, porta per defecte deu minuts. Treure del clúster un node sencer d'OSD equival a donar l'ordre de recrear a la resta dels discs totes les còpies que hi vivien. Un apt full-upgrade que s'allarga, un node que triga a arrencar, una espera que un servei pari bé, i ja has creuat el llindar. El desagradable és que l'operació, un cop arrencada, no es cancel·la sola: tornes a posar el node, Ceph se n'adona i desfà part de la feina, però mentrestant el teu clúster ha estat movent teres que no calia moure, en plena finestra i competint amb la producció.

I després hi ha el pas que de debò s'oblida: treure-la en acabar. Un clúster que es queda amb noout posat té l'autoreparació desactivada i ningú no se'n recordarà. Funciona perfectament fins al dia en què un disc mor de debò i no passa res, que és el pitjor que pot no passar.

Hi ha dues respostes a «quina versió corre el meu Ceph?»

La primera és la que dona dpkg: els binaris instal·lats. La segona és la que el clúster ha declarat, i es canvia amb una ordre a part, al final de tot: ceph osd require-osd-release tentacle. El procediment l'acompanya d'un advertiment que diu més del que sembla: «Before raising the minimum required OSD version, you should ensure all OSDs got upgraded successfully and report running a Ceph 20.2 version».

El que has declarat es llegeix amb ceph osd dump | grep require_osd_release. I aquí va l'avís que motiva mig article: no ho confonguis amb ceph mon dump | grep min_mon_release. Aquesta segona ordre és al wiki, sí, però al pas dels monitors i per verificar aquest pas; retorna min_mon_release 20 (tentacle) tan bon punt han reiniciat els monitors, i continuarà dient 20 encara que no hagis executat require-osd-release a la vida. És l'ordre amb la qual més gent dona l'actualització per acabada abans d'hora, perquè ensenya el número que un espera veure.

La conseqüència pràctica: un clúster pot passar mesos amb tots els binaris a 20.2, el panell en verd i la declaració encara a 19. No es trenca res. No apareix cap alerta escandalosa. Simplement continua funcionant en un mode de compatibilitat que ningú no ha demanat, i tot el que depengui que el clúster sencer sigui nou es queda sense encendre. És el mateix patró que ja vam explicar amb Fast EC, la millora de rendiment de Tentacle que arriba apagada i cal activar a mà per cada pool. Si obres la finestra, tingues escrit per endavant quines ordres s'executen després que tot sigui verd: és la part del procediment que es perd quan el panell es posa verd i tothom se'n va a dormir.

CephFS és on es paga en capacitat

Si tens CephFS, el procediment et demana dues coses abans de tocar els MDS: desactivar standby_replay i reduir el nombre de rangs a un. Les ordres són ceph fs set <fs> allow_standby_replay false i ceph fs set <fs> max_mds 1. És el punt on renuncies a capacitat de servei i no només a redundància: passes de repartir el sistema de fitxers entre diversos servidors de metadades a concentrar-lo en un, amb el que això significa un dilluns al matí.

És també l'únic lloc on la documentació et demana, entre parèntesis i dues vegades, que apuntis alguna cosa en un paper: si penses restaurar-ho després, pren nota de si allow_standby_replay estava activat, i pren nota del nombre original de dimonis MDS. És una petició molt poc habitual en un manual tècnic, i hi és per una raó evident per a qualsevol que hagi fet això alguna vegada: de matinada ningú no recorda quants rangs hi havia. Sense aquest paper, l'actualització acaba amb un CephFS d'un sol rang actiu que funciona, rendeix pitjor, i que ningú no relaciona amb una finestra de manteniment de fa sis setmanes.

Els requisits són un ordre de treball

Són tres i es llegeixen en trenta segons: Proxmox VE 9.1 o superior, concretament el paquet pve-manager en versió 9.1.4 o més nova; Ceph a Squid, concretament 19.2.3-pve3 o més nou; i el clúster sa. Aquesta darrera l'escriuen amb signe d'exclamació, cosa poc freqüent en documentació tècnica: «The cluster must be healthy and working!».

Llegits junts, aquests tres requisits ordenen la feina. Si ets a Proxmox VE 8, el teu següent pas és Proxmox i Ceph ve al darrere —i aquesta branca ja té el seu propi calendari tancat, així que probablement tinguis dues finestres per endavant i no una. El tercer és el que es salta la gent amb pressa: un clúster que ja arrossega un grup de col·locació degradat, o un OSD que va i ve des de fa setmanes, no és candidat. L'actualització no arregla res d'això; ho multiplica, just en el moment en què a més has baixat la redundància expressament.

Per què nosaltres encara no

La raó ja no és el repositori, perquè aquesta excusa es va acabar el 20 de maig. És la cadència, i el rodatge. Tentacle porta publicades cinc versions: la inicial 20.2.0 al novembre i quatre correctives —20.2.1 el 6 d'abril, 20.2.2 el 16 de juny, 20.2.3 el 5 d'agost i 20.2.4 el 19 d'agost—. Dues, el mateix mes, amb catorze dies de diferència. Això parla d'una versió que encara s'està movent, no d'una versió dolenta.

Hi ha a més una asimetria que convé mirar abans de discutir versions: el darrer anunci de repositori empresarial que hem pogut verificar és el del 30 de juliol i correspon a la 20.2.2, mentre que aigües amunt ja van per la 20.2.4 del 19 d'agost. Aquest desfasament és justament el que compres amb la subscripció: un retard deliberat mentre algú mira. Comprova el teu amb apt policy ceph-common abans de donar per fet quina versió t'instal·larà la finestra. Muntar Tentacle en laboratori ara sí que té tot el sentit, perquè un procediment s'assaja abans d'estrenar-lo, i qui tingui CephFS amb diversos rangs hauria d'assajar-ho dues vegades.

Sobre el rendiment, que és el que circularà: al fil de l'anunci, un usuari va publicar que després d'actualitzar passava de 60.207 a 68.516 IOPS aleatòries de 4K (un 13,8 % més) i de 7.488 a 10.120 seqüencials de 64K (un 35,1 %). Se li ha de reconèixer que va publicar més del que és habitual: tres nodes Intel NUC14 amb NVMe i l'script amb rbd bench. Els retrets són uns altres. Ho va mesurar sobre un pool replicat de mida 2 i min_size 2, que no és el valor per defecte de Proxmox ni el de gairebé cap producció seriosa; ho va mesurar el 17 de gener contra la 20.2.0, quatre correctives enrere; i no hi ha repetició ni segona font. Pot ser perfectament cert a la seva màquina. No és una xifra que nosaltres posaríem en una proposta, i certament no és un motiu per avançar una finestra.

Quatre preguntes abans d'obrir la finestra

1. Quant de temps serà el clúster en dues versions, i qui ho mira durant aquesta estona? No hi ha una resposta correcta —hi ha clústers que triguen una tarda i d'altres tres dies—, però hi ha d'haver una resposta escrita abans de començar, i un nom al costat.
2. Què passa si un disc mor mentre un node d'OSD s'està reiniciant? Si la resposta és «no ho sé», la finestra encara no està planificada. Si la resposta és «aquest grup cau per sota de min_size i deixa de servir E/S fins que torni el node», almenys és una resposta, i decideix a quina hora s'obre.
3. Qui decideix parar a mitges, i què vol dir parar? Deixar el clúster en dues versions una setmana és una decisió vàlida i suportada. Deixar-lo així sense que ningú ho sàpiga, no. La diferència entre les dues coses és un correu.
4. Està apuntat, en algun lloc que no sigui la memòria d'algú, el nombre de MDS i l'estat de standby_replay d'abans? I, ja posats, qui executa require-osd-release, qui comprova ceph osd dump i qui treu el noout quan tot sigui verd?

Totes quatre són de govern del canvi, que és per on cauen els sistemes de debò: el treball clàssic d'Oppenheimer, Ganapathi i Patterson sobre tres grans serveis d'internet ja assenyalava el 2003 l'error d'operació —i dins d'ell, la configuració— com la primera causa de caigudes visibles per a l'usuari en dos dels tres serveis, per davant del maquinari. Una actualització de Ceph és un canvi de configuració manual damunt del lloc on viuen totes les teves dades.

Nota de fonts

L'anunci original del 9 de gener de 2026 —amb les frases sobre el repositori test, l'estat de vista prèvia i el suport de Squid «fins al setembre de 2026»— i l'informe de rendiment de l'usuari, amb el seu maquinari i el seu script, són en aquest fil del fòrum de Proxmox; se citen datats expressament, perquè descriuen l'estat d'aquell dia i no el d'avui. L'entrada de Tentacle al repositori empresarial (20 de maig de 2026) la confirma un membre de l'equip de Proxmox el 2 de juny en aquest fil. El pas de Tentacle 20.2.2 al repositori de proves (30 de juny de 2026) i a l'empresarial (30 de juliol de 2026) són missatges de l'equip de Proxmox en aquest altre fil. Requisits (Proxmox VE 9.1 / pve-manager 9.1.4, Ceph 19.2.3-pve3, clúster sa), línies dels repositoris enterprise, no-subscription i test, ordre de reinici dels dimonis, la marca noout descrita com a opcional però recomanada, la instrucció de reiniciar els OSD d'un node cada vegada, les ordres de CephFS i ceph osd require-osd-release tentacle amb el seu advertiment previ: wiki de Proxmox VE, «Ceph Squid to Tentacle». En aquesta mateixa guia, ceph mon dump | grep min_mon_release apareix al pas dels monitors i serveix per verificar aquest pas; que no val com a comprovació de require-osd-release, i que per a això es fa servir ceph osd dump | grep require_osd_release, és una precisió nostra sobre com funcionen el MonMap i l'OSDMap. Dates de publicació i final de vida estimat de Squid (26-09-2024 i 31-10-2026) i de Tentacle (18-11-2025 i 01-06-2027), i les dates de les versions 20.2.1 a 20.2.4: índex oficial de releases de Ceph i notes de Tentacle. La frase sobre que cada dimoni es reinicia només quan el clúster continuarà disponible i l'ordre «gestors, monitors, després la resta» són de la documentació d'actualització amb cephadm, i se citen com el que són: el procediment d'una altra eina de desplegament. Valor per defecte de mon_osd_down_out_interval (deu minuts): «Monitor/OSD Interaction». Valors per defecte de pool a Proxmox (mida 3, min_size 2): manual de Proxmox VE, capítol «Deploy Hyper-Converged Ceph Cluster». L'error d'operació com a primera causa de caigudes visibles per a l'usuari en dos dels tres serveis estudiats: Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. Les cites es reprodueixen en el seu idioma original; el text explica en cada cas què diuen. Les opinions són nostres: que dir «opcional» a noout és enganyós, que la cadència de correccions diu més que el número de versió, que el desfasament del repositori empresarial és el que es compra amb la subscripció, que la xifra del fòrum no serveix per a una proposta i que encara no toca posar-ho en producció de client surten d'operar Proxmox VE amb Ceph, no de les fonts citades.