Hi ha un número escrit als teus servidors que ningú no ha decidit i que creix cada vegada que amplies el clúster. No és a la factura, no surt al panell i no el comprova cap inventari: és el temps que triga Proxmox a adonar-se que un dels seus nodes ha mort. Amb els valors de fàbrica, aquest temps puja 650 mil·lisegons per cada node que hi afegeixes. Proxmox ho va corregir a la versió 9.2, però l'arranjament només entra als clústers que es creen de zero. Si has actualitzat el teu de la 8 a la 9 aquestes setmanes, continues amb el rellotge vell.
Aquest post és la continuació declarada d'un altre. Fa unes setmanes vam escriure que l'alta disponibilitat de Proxmox no evita la caiguda, l'escurça, amb el sostre que publica la mateixa documentació: uns dos minuts de detecció i commutació, i d'aquí el límit de 99,999 % que el fabricant es posa a si mateix per escrit. Allò anava del que compres en activar l'HA. Això va del que passa abans d'aquests dos minuts, en el tros que gairebé ningú no mira, i d'un ajust nou que el teu clúster probablement no ha rebut.
Abans de moure res, el clúster s'ha de posar d'acord
Quan un node s'apaga, el primer que passa no té res a veure amb les màquines virtuals. Els nodes que queden han de refer la llista de qui continua viu, i d'això se n'encarrega corosync amb dos temporitzadors. El token és el que un node espera el testimoni abans de donar-lo per perdut: 3.000 mil·lisegons per defecte. El consensus és el que esperen després per acordar la nova membresia; si no el toques, es calcula sol a 1,2 × token.
El detall que canvia el resultat és que aquests 3.000 mil·lisegons no són el valor que s'utilitza. Tan bon punt el fitxer de configuració té una llista de nodes amb tres o més membres —és a dir, en qualsevol clúster real—, corosync calcula el temps de debò així: token + (nombre de nodes − 2) × token_coefficient. I aquest coeficient val 650 mil·lisegons de fàbrica. La documentació explica el perquè sense embuts: serveix perquè «el clúster escali sense haver de canviar el token a mà cada vegada que s'afegeix un node». És una decisió raonable —un clúster gran necessita més marge— amb una conseqüència que gairebé ningú no ha calculat.
La suma dels dos temporitzadors és, en paraules de la documentació de Proxmox, «the minimum time needed to reestablish a new cluster membership after a node goes offline». És a dir: el terra de la teva commutació, el que passa abans que el gestor d'HA aixequi un dit. Amb la fórmula i els valors de fàbrica, el compte surt sol:
El compte és nostre; la fórmula i els valors per defecte són de la documentació oficial de corosync. La comprovació que la fórmula és la que creiem la dóna el mateix manual de Proxmox, que com a exemple publica token 4.950 i consensus 5.940 —«10,89 segons»—, exactament la fila de cinc nodes. Són temporitzadors configurats, no temps mesurats a la teva sala.
No cal creure's la taula. Aquests són els teus dos números reals, en mil·lisegons, ara mateix:
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'
La cursa: 45 segons contra 60
Aquest número creixent seria una curiositat si no competís amb un altre que no creix. Proxmox aïlla els nodes perduts per self-fencing: un node que es queda sense quòrum no pot rearmar el seu temporitzador de guarda i es reinicia sol «after the watchdog has timed out (this happens after 60 seconds)». Aquest 60 és fix. L'altre, el de posar-se d'acord, puja amb cada servidor que compres.
La documentació de Proxmox posa la cursa per escrit. Mantenir la suma de token i consensus per sota de 45 segons és «especially important» amb HA activa, «to ensure that a new cluster membership is formed before the watchdog timeout of 60 seconds expires, which would trigger a node fence». I demana marge per sota d'aquests 45 «so that transient timing variations do not push the cluster past the watchdog threshold». La seva escala és explícita: baixar el coeficient és suggerit per damunt de 30 segons, recomanat per damunt de 40 i fortament recomanat per damunt de 45.
Mira un altre cop l'última fila de la taula. Un clúster de 29 nodes amb els valors de fàbrica dóna 45,21 segons: ha creuat el llindar que la mateixa documentació marca com a «fortament recomanat» corregir, i ho ha fet sense que ningú toqués un fitxer, simplement creixent. A partir d'aquí, un tall de xarxa d'uns segons pot acabar reiniciant nodes que estaven sans, amb les seves màquines funcionant i el seu emmagatzematge accessible. No va fallar el ferro: el rellotge de posar-se d'acord va arribar tard al rellotge de donar-se per mort.
L'arranjament de la 9.2 només arriba als clústers nous
Proxmox ha vist el problema i l'ha corregit. La documentació ho diu en literal: «Since Proxmox VE 9.2, new clusters are created with a lower token coefficient of 125 milliseconds explicitly set in /etc/pve/corosync.conf». L'efecte és gran i es mesura: amb 125 en lloc de 650, el clúster de 29 nodes de l'última fila passa de 45,21 a 14,03 segons. Tres vegades més ràpid, i amb el watchdog de 60 a una distància còmoda.
Ara llegeix aquesta frase un altre cop, a poc a poc: new clusters are created. El coeficient s'escriu al fitxer en crear el clúster. Si el teu fa anys que funciona i l'has actualitzat de la branca 8 a la 9 —cosa que molta gent està fent just ara, perquè Proxmox VE 8 arriba a fi de suport aquest mes—, el teu corosync.conf és el que ja tenies: sense coeficient explícit i, per tant, amb els 650 de sempre. La mateixa documentació ho confirma per l'altre costat, quan explica com baixar-lo: cal afegir la línia a mà. Actualitzar no te l'ha donat, i la documentació no esmenta cap avís que t'ho expliqui.
Quan NO tocar res
Aquest post es pot llegir com «corre a canviar el coeficient». No ho facis. Si tens entre tres i vuit nodes, la teva suma va de 8 segons a una mica més de 15, molt lluny dels 45, i el valor de fàbrica no és el teu problema. Tocar corosync.conf per moda significa ficar la mà en l'únic fitxer capaç de partir-te el clúster en dues meitats que no es parlen, amb les màquines enceses. Es canvia quan el compte ho demana, seguint el procediment de la documentació i amb una finestra acordada.
El que sí que convé fer avui, tinguis la mida que tinguis, és la part barata: executar aquest corosync-cmapctl, apuntar els dos números a la documentació del clúster i saber en quin punt de la taula ets. Costa dos minuts i et diu si tens deures o no. A més, la documentació és clara que el marge no es compra només baixant el coeficient: exigeix una xarxa de clúster que aguanti, i abaixar els temps en una xarxa amb latència irregular empitjora les coses en comptes d'arreglar-les.
L'altre rellotge que continua corrent: l'emmagatzematge
Si l'emmagatzematge és Ceph, hi ha dos temporitzadors més i van a una altra escala. Un OSD es declara caigut quan deixa de donar senyals durant osd_heartbeat_grace, 20 segons per defecte —amb el matís que el monitor vol que el reportin diversos OSD de màquines diferents abans de marcar-lo—. Però caigut no equival a fora: per marcar-lo out i començar a refer les rèpliques que falten, Ceph espera mon_osd_down_out_interval, i aquí són 10 minuts.
Aquests deu minuts són deliberats i són bons: eviten que un reinici de manteniment dispari el moviment de terabytes per tota la xarxa. Convé saber que existeixen perquè marquen el moment exacte en què un simulacre deixa de ser gratis. Si el node torna en cinc minuts, no ha passat res; si trigues dotze a aixecar-lo, el clúster ja ha començat a rebalancejar i t'has emportat una tarda de trànsit de recuperació de regal. Hi ha un tercer valor que gairebé ningú no mira i que importa abans d'apagar un rack sencer: mon_osd_down_out_subtree_limit, per defecte rack, és la unitat més petita del mapa CRUSH que Ceph no traurà automàticament. Un node sencer sí; un rack sencer, no.
Amb una condició prèvia que ja vam explicar aquí i que torna a aparèixer: perquè aquest rebalanceig acabi, ha de cabre. Si el clúster va just d'espai, el que veuràs no és una recuperació sinó un embús, i ho desenvolupem en el post sobre per què a Ceph la capacitat la marca el disc més ple.
Tot això només se sap apagant alguna cosa a propòsit
Els números de dalt són el terra teòric. El número real de la teva empresa surt d'una sola manera, i té nom des de fa anys: «Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions in production». Experimentar, confiança, producció. Ni auditar, ni documentar, ni laboratori.
El mètode que proposen té quatre passos i el primer és el que tothom es salta: definir el «steady state», una mesura observable que digui que el sistema va bé. Després es formula la hipòtesi que aquest estat aguantarà, s'introdueix l'esdeveniment real —«servers that crash, hard drives that malfunction, network connections that are severed»— i s'intenta refutar la hipòtesi. Així ho aterrem nosaltres per a una empresa de trenta persones:
- 1.La hipòtesi s'escriu abans. «En apagar el node 3, la comanda que s'està tramitant es completa i l'ERP torna a respondre en menys de X minuts.» Amb un número a dins, i signada per qui ho sosté.
- 2.Els valors de fàbrica, apuntats abans de tocar res: token i consensus reals, si el watchdog és de maquinari o softdog, i els llindars de Ceph. Mitja hora que t'estalvia discutir després sobre el que va passar.
- 3.Radi d'explosió mínim. Un node, i el que menys serveis crítics tingui. La primera vegada s'aprèn el mateix i es trenca menys.
- 4.Dimarts al matí. Amb la gent que ho sap arreglar desperta i sense pressa per marxar. Un simulacre un divendres a les set de la tarda és un incident disfressat.
- 5.El rellotge l'atura un usuari, no un panell verd. I el número s'apunta encara que sigui lleig: el número lleig d'avui és l'objectiu del trimestre vinent.
El nostre últim simulacre de recuperació completa es va tancar en 14 minuts. Ho donem com a dada interna i com a prova que es pot mesurar, no com a promesa contractual: el número de cada empresa depèn de la seva arquitectura, de la seva aplicació i de quantes vegades ho hagi assajat. El nostre tampoc no va ser així el primer dia.
El que es compra de debò
La fallada és inevitable: una font es mor, un disc se'n va, algú ensopega amb un cable. Que això es converteixi en avaria —que l'empresa deixi de funcionar— és una decisió de disseny, i part d'aquesta decisió són uns quants números que ja són escrits als teus servidors, posats per defecte per gent que no coneixia el teu clúster. Saber quins són costa un matí; no saber-los costa el que costa un dia aturat.
A everyWAN operem Proxmox VE amb Ceph en producció repartit en diversos centres de dades, i fem simulacres de recuperació cronometrats. Per això mirem aquests temporitzadors abans de signar un número de continuïtat amb ningú: és el que hi ha darrere d'infraestructura i cloud i de compliment i continuïtat, i no una casella d'alta disponibilitat marcada en una proposta. Quan el rellotge comença a córrer de debò, el que ajuda és tenir un equip mirant.
Fonts (verificades una a una): valors per defecte de token (3.000 ms) i token_coefficient (650 ms), la condició que la fórmula només s'aplica amb una llista d'almenys tres nodes, la fórmula token + (nodes − 2) × token_coefficient i el càlcul automàtic de consensus a 1,2 × token — corosync.conf(5); coeficient de 125 ms en clústers creats des de Proxmox VE 9.2, el llindar de 45 segons davant del watchdog de 60, l'escala 30/40/45, l'exemple de 4.950 / 5.940 ms i la comanda de comprovació — Proxmox VE: Cluster Manager; el self-fencing per watchdog als 60 segons — Proxmox VE: High Availability; osd_heartbeat_grace (20 s), mon_osd_down_out_interval (10 min) i mon_osd_down_out_subtree_limit (rack) — Ceph: Monitor/OSD Interaction; definició de chaos engineering i els quatre passos del mètode experimental — Principles of Chaos Engineering. Documentació consultada el 28 d'agost de 2026. La taula de nodes davant de token+consensus és un càlcul nostre a partir de la fórmula oficial i dels valors per defecte, contrastat amb l'exemple de cinc nodes que publica la mateixa documentació de Proxmox; són temporitzadors configurats, no temps mesurats al teu clúster. El simulacre de 14 minuts és una dada interna d'everyWAN, no un compromís de servei.
Saps quin valor té el token del teu clúster?
Mirem els teus temporitzadors, fem el compte amb el teu nombre de nodes i, si toca, preparem el simulacre amb tu: hipòtesi escrita, un sol node i cronòmetre. Sense fum i amb la documentació al davant.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN