El clúster tria node comptant convidats: antiafinitat a Proxmox VE 9 i la regla que ningú declara

Cau un node de matinada. La resta del clúster manté el quòrum, el vigilant fa la seva feina i al cap d'una estona les màquines del node mort —les que estaven donades d'alta com a recursos d'HA, la resta continuen apagades— estan arrencant en un altre lloc. Tot ha funcionat. La pregunta que gairebé ningú es fa és qui va triar aquell altre lloc i amb quin criteri. En un Proxmox VE acabat d'instal·lar la resposta està escrita a la documentació oficial i és molt més simple del que la gent suposa: el planificador mira el nombre de convidats actius que té cada node i tria el que en té menys. Compta. No sap que la 101 és la segona pota de la 100.

Qui decideix on arrenca la teva màquina

La peça es diu Cluster Resource Scheduler, CRS. A cada ronda del gestor d'HA —uns deu segons— repassa els recursos i decideix si algun necessita una col·locació nova. Té tres modes i el que ve de fàbrica és basic: compta convidats actius per node. Els altres dos sí que miren CPU i memòria: static-load fa servir les quotes configurades dels convidats actius, i dynamic-load hi afegeix l'ús mitjà real de CPU i memòria. Cap dels tres no ve amb una llista de quines màquines fan parella.

La documentació anomena punts de planificació els moments en què el CRS entra en acció, i en marca dos com a sempre actius: la recuperació de recursos quan cau un node, i els canvis a la configuració de regles. Això vol dir que la col·locació no és opcional. Encara que no hagis tocat res, el dia de l'incident algú decideix en quin ferro arrenca cada cosa. L'única pregunta oberta és si aquella decisió té en compte el que tu saps de la teva pròpia arquitectura.

El que va canviar a la 9.0 i va arribar al teu clúster sol

Durant anys, l'única cosa que es podia expressar a Proxmox eren els grups d'HA: aquesta màquina, en aquests nodes, amb aquestes prioritats. Servia per dir on sí, i no servia per dir amb qui no. Proxmox VE 9.0 va substituir aquell mecanisme per les regles d'HA, que són dues famílies diferents: les d'afinitat de node, que lliguen recursos a nodes, i les d'afinitat de recurs, que lliguen recursos entre ells. I hi ha una cosa que despista: totes dues famílies admeten el modificador --affinity negative, però vol dir coses diferents a cadascuna. En una regla de node, negativa vol dir «en qualsevol node menys aquests», que és una manera còmoda d'excloure sense llistar el clúster sencer. En una regla de recurs, negativa vol dir «aquests dos, mai al mateix node». Quan aquí es parli d'antiafinitat sense cognom, és la segona.

El detall que convé no passar per alt és que això no espera que tu ho decideixis. Les notes de la versió són explícites: els grups queden obsolets i els existents es migren automàticament a regles d'afinitat de node tan bon punt tots els nodes del clúster corren Proxmox VE 9. L'opció nofailback dels grups desapareix i se substitueix per failback, que ara es configura per recurs. Si vas actualitzar el clúster i no ho vas tornar a mirar, tens regles noves escrites pel mateix sistema i una opció que ha canviat de lloc i de signe.

Una preferència i una ordre

Aquí hi ha l'asimetria que, segons la nostra experiència, més gent descobreix tard. Les dues famílies de regles tenen valors per defecte oposats.

La conseqüència pràctica és que molta gent té el contrari del que es pensa que té. La regla que restringeix una màquina a un node concret, si no la marques estricta, no restringeix res el dia que aquell node falta. I la regla que separa dues màquines mana fins i tot quan l'alternativa és que una d'elles no arrenqui. Es declaren així:

# separar dos recursos: mai al mateix node
ha-manager rules add resource-affinity keep-separate \
    --affinity negative --resources vm:200,ct:300

# fixar un recurs a un node... i fer-ho de debò
ha-manager rules add node-affinity ha-rule-vm100 --resources vm:100 --nodes node1
ha-manager rules set node-affinity ha-rule-vm100 --strict 1

# veure quines regles hi ha, i quines afecten un recurs
ha-manager rules list
ha-manager rules config --resource vm:100

L'aritmètica d'una regla negativa

Una regla que separa n recursos necessita n nodes on posar-los, i això està escrit com a prova de viabilitat, no com a consell: «una regla d'afinitat de recurs negativa no pot especificar més recursos d'HA que nodes hi ha al clúster. Si no, els recursos no tenen prou nodes per ser separats». Una regla que no passa aquella prova es queda deshabilitada, que és la primera manera de perdre una garantia sense adonar-se'n. I per a les que sí que passen, la documentació diu què passa quan el compte s'espatlla sobre la marxa: si la restricció no es pot satisfer, el gestor d'HA deixa el recurs en estat recovery quan es tracta d'un failover, i en estat error en qualsevol altre cas.

Fem el compte amb el clúster més comú que ens trobem: tres nodes. Si poses una regla negativa entre tres recursos —posem les tres instàncies d'una aplicació repartida—, en marxa normal encaixen just: un per node, sense marge. El dia que cau un node queden dos llocs per a tres coses que no poden compartir lloc, i una de les tres no torna. El planificador no s'ha equivocat; ha fet exactament el que la regla diu. Amb dos recursos a la regla, en canvi, sobra un node i la recuperació és neta.

Lectura nostra, no de la documentació: això no ho anomenaríem un defecte. És una decisió de disseny que estaves prenent sense saber-ho. Hi ha serveis on arrencar dues rèpliques al mateix ferro és pitjor que tenir-ne una de parada, perquè el segon node dona una falsa sensació de cobertura que s'evapora en el següent reinici. I hi ha serveis on encès i degradat és infinitament millor que apagat i correcte. Aquesta tria és teva i només es pren bé amb calma, un dimarts. Mai a les tres de la matinada.

I hi ha un compte que va abans que aquest, encara que a molta gent li arribi després: el capítol d'alta disponibilitat descriu regles, prioritats i tanca, però no descriu cap mecanisme que reservi capacitat per al failover. Ningú no t'impedeix omplir els tres nodes fins dalt de memòria. El dia que en falti un, o la RAM que queda dona per arrencar-ho tot o no dona, i aquella resta la fas tu abans o no la fa ningú. És una de les coses que ja posàvem damunt la taula en escriure quan NO migrar de VMware a Proxmox, i continua sent la diferència més honesta que hi ha entre les dues plataformes en aquest terreny.

És la mateixa idea que explicàvem parlant de per què la redundància no sobreviu al procediment, només que a l'inrevés: allà la parella redundant la desfeia una persona seguint un manual, i aquí la desfà un planificador fent la seva feina. I és cosina germana de la distinció entre redundància i diversitat de ruta: dues coses duplicades només són dues si no comparteixen el punt que pot fallar. En un clúster aquell punt és el node, i dir quin no es comparteix és un fitxer de text.

El que la regla arrossega sense que li ho demanis

Les regles es combinen entre elles, i és aquí on l'abast creix pel seu compte. Tres comportaments que són a la documentació i que gairebé mai no es tenen al cap en escriure la primera regla:

• Dues regles positives que comparteixin un recurs es fonen en una de sola. Si 100 i 101 van juntes, i 101 i 102 també, aleshores les tres van juntes. Ningú no va escriure aquella tercera relació.
• Un grup unit per afinitat positiva hereta les restriccions de qualsevol dels seus membres. Si la 102 és lligada al node 3 per una regla de node, la 100 i la 101 queden lligades al node 3 també. I si un del grup té una afinitat negativa amb un altre recurs, la tenen tots.
• Les regles se sotmeten a proves de viabilitat abans d'aplicar-se, i les que no les passen queden deshabilitades fins que resolguis el conflicte. Entre les proves: un recurs només pot estar en una regla d'afinitat de node; una regla negativa de node no pot portar prioritats ni llistar tots els nodes del clúster; una regla d'afinitat de recurs necessita com a mínim dos recursos. Dos recursos que estiguin alhora en una regla positiva i en una de negativa són un conflicte pur, i totes dues regles es desactiven.

Aquest últim punt és el que ens sembla més perillós a la pràctica, i no per la seva complexitat sinó pel seu silenci. Una regla deshabilitada no protesta cada matí. És a la interfície, amb el seu nom, i no fa res. Qui la va escriure es pensa que el clúster té una garantia que el clúster no té, i se n'assabentarà el dia del failover. Per això la primera ordre de la llista de més avall no és escriure una regla: és llegir les que ja hi ha.

Des de la 9.2 el clúster també mou pel seu compte

Tot això anterior ja importava, però importava sobretot el dia de l'incident. Proxmox VE 9.2, publicat el 21 de maig de 2026, va afegir el balancejador de càrrega automàtic del CRS: el clúster mesura el seu propi desequilibri i, si es passa de la ratlla durant prou rondes seguides, emet migracions per corregir-lo. Només mou recursos gestionats per HA, les migracions van d'una en una, i el llindar de desequilibri és del 30 % de fàbrica. No està encès per defecte —requereix el mode static-load o dynamic-load— però el dia que algú l'encengui, la col·locació deixa de ser una foto fixa del dia que vas muntar el clúster i passa a ser una decisió contínua.

La documentació deixa clar que aquelles migracions obeeixen sempre les regles d'afinitat vigents. És la frase tranquil·litzadora del capítol, i és certa. També és exactament el problema: obeir les regles només et protegeix si les regles existeixen. Un balancejador que no sap que la 100 i la 101 són la mateixa cosa dues vegades farà l'única cosa que li has demanat, que és repartir càrrega, i repartir càrrega pot voler dir ajuntar-les. Hi ha dos matisos més que convé apuntar: el rebalanceig automàtic es pot desactivar recurs a recurs, i si un recurs té afinitat positiva amb un altre que el porta desactivat, tampoc no es mou cap dels dos.

Cinc minuts davant del clúster

Això és el que mirem nosaltres quan ens asseiem davant d'un Proxmox VE 9 que ja està en producció. No cal finestra de manteniment per a cap dels cinc punts.

1. Llegir abans d'escriure. ha-manager rules list i buscar dues coses: regles que no esperaves —les que va migrar sola la 9.0— i regles deshabilitades per conflicte. La segona cosa és una garantia que algú es pensa que té.
2. Escriure la llista de parelles. En paper, abans de tocar res: els dos controladors de domini, la base de dades i la seva rèplica, els dos nodes del balancejador, el parell de servidors de l'aplicació. Gairebé sempre són menys de les que un es pensa, i gairebé mai no estan escrites enlloc.
3. Fer el compte abans de crear la regla. Recursos a la regla negativa contra nodes capaços d'executar-los, menys un, que és el que pot caure. Si la resta no dona, no creïs la regla encara: primer decideix què prefereixes que passi.
4. Revisar el failback per recurs. És l'opció que va substituir el nofailback dels grups vells. Decideix si una màquina torna sola al seu node preferit quan aquell node reapareix, que és una segona finestra de risc just després de la primera.
5. Regles primer, balancejador després. Si activaràs el balanceig automàtic de la 9.2, l'ordre importa: declara les parelles, comprova que cap regla no ha quedat deshabilitada i només llavors encén el mode dinàmic. A l'inrevés, li estàs donant permís per moure coses les relacions de les quals encara no coneix.

Quan no posar la regla

Si el teu clúster són dos nodes, la regla continua comprant alguna cosa, però convé saber exactament què. Et separa les dues màquines mentre tots dos nodes estiguin vius, i això no és poc: el planificador reparteix comptant convidats en total, així que si un dels dos té més convidats pot ajuntar-les sense problema. El que no et compra és res per al dia de l'incident, perquè així que queda un sol node la resposta de la regla és que no. Amb dos nodes, l'antiafinitat protegeix el dia a dia i s'aparta el dia que fa soroll. Si el que operes és un grapat de màquines sense parella real —cada servei, una VM— llavors sí, no necessites res d'això, i afegir regles només et donarà conflictes per resoldre.

I si el teu cas és el de dalt —prefereixes encès i degradat a apagat i correcte— hi ha un pedaç que fem servir i que diem que és un pedaç, perquè no és una funció pensada per a això: en lloc d'una afinitat de recurs negativa, dues regles d'afinitat de node no estrictes, una per màquina, apuntant a nodes diferents. Separa mentre es pugui i no bloqueja quan no es pugui, que és justament l'asimetria de valors per defecte amb què començava aquest post. No és tan net com la regla negativa i no dona cap garantia dura; simplement fa l'altra cosa.

Tot això va del mateix que la resta de la nostra feina: la fallada del node és inevitable i no es negocia. El que sí que es decideix, i es decideix abans, és la mida de l'avaria. Un clúster amb les regles escrites i el compte fet perd un node i continua. Un sense elles també sobreviu gairebé sempre, perquè el planificador reparteix raonablement bé, i aquest «gairebé sempre» és precisament el problema: funciona fins al dia que li toca posar les teves dues rèpliques al mateix lloc, i aquell dia ja no hi ha a qui preguntar. Si n'estàs muntant o revisant un, el checklist de hardening que apliquem a cada clúster Proxmox VE 9.2 cobreix l'altra meitat de la conversa.

Nota de fonts

Tot el que és tècnic en aquest post surt de tres fonts primàries de Proxmox, consultades el 10 de setembre de 2026: el capítol High Availability de la documentació oficial de Proxmox VE i la pàgina Roadmap del wiki oficial, amb els registres de canvis de les versions 9.0, 9.1 i 9.2. De la documentació provenen: que el mode de planificació per defecte del CRS és basic i que aquell mode tria node pel nombre de convidats actius; l'existència dels modes static-load i dynamic-load i què mesura cadascun; que la ronda del gestor d'HA dura al voltant de deu segons; que la recuperació de recursos i els canvis de regles són punts de planificació sempre actius; que les regles d'afinitat de node tenen strict a 0 per defecte i què implica; que les regles d'afinitat de recurs són estrictes per defecte i, a la pràctica, només estrictes —l'ordre no exposa cap --strict per a aquella família— i que, si la restricció no es pot complir, el recurs queda en estat recovery en un failover o en error en un altre cas; la fusió de regles positives que comparteixen recursos i l'herència de restriccions dins d'un grup positiu; les proves de viabilitat i que les regles que no les passen queden deshabilitades; el funcionament del balancejador automàtic, el seu llindar de desequilibri per defecte del 30 %, que només mou recursos gestionats per HA de manera seqüencial, que requereix el mode static-load o dynamic-load, que les seves migracions obeeixen sempre les regles d'afinitat vigents i el comportament del rebalanceig desactivat per recurs. Les ordres citades són les de la mateixa documentació i de la pàgina de manual de ha-manager. Del Roadmap provenen: que les regles d'HA es van introduir a Proxmox VE 9.0, que els grups d'HA queden obsolets i es migren automàticament a regles d'afinitat de node quan tots els nodes corren Proxmox VE 9, que nofailback se substitueix per failback, que Proxmox VE 9.2 es va publicar el 21 de maig de 2026 i que el balanceig dinàmic va arribar en aquella versió. És lectura NOSTRA, i no de la documentació: que un clúster sense regles declarades té un problema latent i no un problema; que una regla negativa insatisfactible és una decisió de disseny sobre si prefereixes degradat o parat; l'ordre de treball del checklist; i el pedaç de les dues regles d'afinitat de node no estrictes com a substitut tou de l'antiafinitat, que presentem com a pedaç precisament perquè la documentació no ho planteja així. No donem xifres de rendiment, temps de recuperació ni percentatges de clústers afectats, perquè no els tenim mesurats i preferim dir-ho. Que operem Proxmox VE amb Ceph en producció i que no som resellers de Proxmox ni de VMware és informació pròpia d'everyWAN. Comprova qualsevol d'aquestes ordres al teu entorn de proves abans d'executar-les en producció. La fotografia de portada és «Front of server racks at NERSC», del Lawrence Berkeley National Laboratory, publicada a Wikimedia Commons sota domini públic.