Proxmox VE 9.2 va incorporar balanceig dinàmic de càrrega amb el Cluster Resource Scheduler, i per aquí fora s'ha resumit com que el clúster per fi s'equilibra sol. Proxmox mai no va prometre això: les seves pròpies notes de versió diuen dues vegades "HA-managed guests", i el manual ho tanca del tot — "Currently, these migrations are issued only for HA resources and executed sequentially". El que no està escrit a cap dels dos llocs és què costa ficar una VM en aquest club, i aquí és on apareix un watchdog i un node disposat a reiniciar-se en seixanta segons.
Operem clústers de Proxmox VE amb emmagatzematge Ceph en producció, repartits en diversos datacenters. Sobre el balancejador dinàmic no et donarem una estadística de quantes migracions ens ha estalviat, perquè seria inventada. El que segueix és una altra cosa: què diu exactament la documentació de la 9.2, quins valors porta de fàbrica, i el criteri amb què decidim encendre'l o deixar-lo apagat a cada clúster.
Tres modes, i el que portes posat no serveix per a això
El CRS és qui tria en quin node va cada recurs HA. Té tres modes, configurables a Datacenter → Options → Cluster Resource Scheduling:
- 1
basic— compta quants convidats actius hi ha a cada node. Res més. És el valor per defecte. - 2
static— fa servir les quotes de CPU i memòria configurades als convidats actius. El que posa al fitxer de la VM, no el que consumeix. - 3
dynamic— hi suma l'ús mitjà real de CPU i memòria. És el mode que la 9.2 va estrenar i el que dona sentit al balancejador.
Aquí hi ha el primer malentès: el balancejador automàtic no s'activa sol en actualitzar. Exigeix estar en static o en dynamic, i a més encendre un interruptor propi, ha-auto-rebalance, que ve a 0. Si vas actualitzar a la 9.2 i no vas tocar res, segueixes en basic i amb el balanceig apagat. La notícia de "Proxmox ja equilibra el clúster" descriu una capacitat, no res que et trobis activat.
L'aritmètica per defecte: 30 %, tres rondes, 10 %
El balancejador no mou res tan bon punt un node va més carregat que un altre. Ha de superar tres filtres encadenats, i tots tres tenen número. El desequilibri del clúster es deriva de la desviació típica i la mitjana de les càrregues dels nodes, normalitzat a un rang de 0 a 100 %:
| Paràmetre | Per defecte | Què decideix |
|---|---|---|
ha-auto-rebalance | 0 | Apagat de fàbrica. |
ha-auto-rebalance-threshold | 30 | Desequilibri en % que cal superar per començar a comptar. |
ha-auto-rebalance-hold-duration | 3 | Rondes consecutives per sobre del llindar. Cada ronda dura uns 10 s. |
ha-auto-rebalance-margin | 10 | Millora mínima RELATIVA, en %, perquè la migració triada valgui la pena. |
ha-auto-rebalance-method | bruteforce | Com es puntuen les migracions candidates. L'alternativa és topsis. |
auto-rebalance (per recurs) | 1 | Cada recurs HA entra al repartiment llevat que el treguis tu. |
Traduït: amb els valors de fàbrica, el clúster ha d'estar desequilibrat per sobre del 30 % durant uns 30 segons seguits, i a sobre la migració que el CRS triï ha de prometre una millora d'almenys el 10 %. Això és deliberat: un balancejador que reaccionés al primer pic estaria movent màquines tota la nit mentre corren els backups. L'efecte pràctic val la pena dir-lo en veu alta, perquè és contraintuïtiu: el balancejador està fet per no arreglar els teus pics curts. Si el teu problema és que de 2 a 4 de la matinada un node es posa al límit, això no és l'eina.
L'abast: només allò que hagis declarat
La frase de la documentació no admet interpretació: les migracions de reequilibri "are issued only for HA resources and executed sequentially". Dues coses en una línia. La primera, que una VM que no sigui recurs HA és invisible per al balancejador per molt que estigui devorant el node. La segona, que les migracions van d'una en una: un clúster molt desnivellat no s'arregla en un sospir, es va arreglant. I el mateix manual deixa oberta la porta de sortida: "It is planned that load balancing will also include non-HA resources in the future". Planejat. Avui no.
Hi ha un detall fi que convé conèixer abans que et sorprengui: les migracions de reequilibri respecten les regles d'afinitat, i si desactives auto-rebalance en un recurs, qualsevol altre recurs amb afinitat positiva cap a ell també queda fora del repartiment. És coherent —si dues màquines han de viure juntes, no en pots moure una de sola— però significa que excloure una VM pot excloure, sense que ho demanis, tot el seu grup. Si fa temps que et baralles amb les regles d'afinitat de la branca 9, ja vam escriure sobre com el clúster compta els convidats quan aplica antiafinitat.
El preu d'entrar al repartiment: 60 segons
Aquí és on això deixa de ser una conversa sobre rendiment. Perquè el balancejador pugui moure una VM, aquesta VM ha de ser recurs HA. I la pila d'HA de Proxmox se sosté sobre un watchdog: mentre un node tingui serveis HA actius, el seu LRM manté el watchdog obert i el va resetejant. Quan aquest node deixa d'estar al quòrum del clúster, el LRM espera que se'n formi un de nou i, mentre no n'hi hagi, no pot resetejar el watchdog. La documentació tanca la frase sense embuts: això "will trigger a reboot after the watchdog has timed out (this happens after 60 seconds)".
El revers d'aquesta regla és al mateix manual i gairebé ningú el cita: "If no service is configured for more than 15 minutes, the CRM automatically returns to the idle state and closes the watchdog completely". És a dir: un clúster sense cap recurs HA declarat acaba tancant el watchdog i no s'auto-reinicia. Aquest node, davant d'un tall de xarxa, es degrada i espera. El teu, tan bon punt aquest node tingui serveis HA actius, es reinicia. Val la pena quedar-se amb l'acotació exacta, perquè no val per a tots els nodes igual: el manual avisa que un node amb CRM actiu però amb el LRM ociós no dispara l'auto-fencing, ja que el LRM només sosté el seu watchdog mentre té el seu agent lock. El rellotge corre al node on de debò s'estan executant els serveis HA, no al clúster sencer.
I ara la conclusió que no està escrita a cap manual, perquè és nostra i es dedueix de juntar les dues peces: l'abast del balancejador és més petit que el radi del seu dany. Mou únicament les VM que hagis declarat HA, però el reinici que porta amb ell s'emporta tot el que hi hagi en aquest node, declarat o no. Les VM HA es recuperen en un altre node; les que no vas declarar tornen quan torni el node. Dit d'una altra manera: en encendre el balanceig estàs signant que prefereixes que un node aïllat es reiniciï abans que segueixi servint en solitari. Hi ha clústers on aquesta signatura és òbviament correcta i clústers on no, però la signatura es dona a la columna de la resiliència i es cobra allà, encara que se signi des del panell de rendiment.
Què no mourà encara que ho declaris
Un reequilibri és una migració, i una migració necessita que la destinació pugui executar aquella VM. El manual llista els requisits de la pila HA sense adorns: almenys tres nodes, emmagatzematge compartit i redundància de maquinari. I, perquè l'HA Manager consideri elegible qualsevol node, demana que el convidat:
- ✓faci servir opcions compatibles amb tots els nodes del clúster;
- ✓faci servir només emmagatzematge compartit accessible des de tots els nodes;
- ✓faci servir només interfícies de xarxa que existeixin a tots els nodes;
- ✓faci servir només passthroughs de dispositiu presents a tots els nodes.
Llegeix aquesta llista pensant en el teu parc real i veuràs el problema: la màquina que de debò et desnivella el clúster sol ser precisament la que incompleix algun dels quatre punts. La que té el disc en emmagatzematge local perquè "és que necessita IOPS". La que porta una targeta en passthrough. La que penja d'un bridge que només existeix en dos dels cinc nodes. El manual dona sortida a aquests casos, i convé no exagerar-ne la condemna: si una dependència només és en un subconjunt de nodes, es restringeix el recurs a aquest subconjunt amb una regla estricta d'afinitat de node, i l'HA Manager limita a aquests nodes la col·locació, la recuperació i la migració. És a dir, aquesta VM sí que es reequilibra, però només entre els dos nodes on pot viure. El balancejador reparteix bé el conjunt de màquines que ja eren fàcils de moure, i la feina avorrida de posar l'emmagatzematge compartit en condicions continua sent on es guanya. Si el teu cas és Ceph, convé tenir clar abans què aguanta de debò un clúster de tres nodes, i si véns de més enrere, per què l'HA de Proxmox no evita la caiguda, l'escurça.
La novetat de la 9.2 que més ens importa no és el balancejador
A la mateixa versió van arribar dues ordres del CRM, disarm-ha i arm-ha, que desarmen la pila d'HA a tot el clúster. Serveixen per fer manteniment planificat, com tocar la xarxa del clúster, "without triggering any node fencing events", i l'estat dels recursos HA es preserva durant la finestra perquè tornin al seu lloc en acabar. S'invoca triant mode de recurs: ha-manager crm-command disarm-ha freeze o ignore, i arm-ha en acabar. A nosaltres ens resulta més útil que el balanceig, perquè qualsevol que hagi hagut de moure un switch amb un clúster HA a sobre coneix el compte enrere de "com això trigui més d'un minut, se'm reinicien els nodes".
Amb la seva lletra petita, que el manual marca com a important: mentre la pila està desarmada "no automatic recovery, failover, or fencing takes place" i una fallada de node en aquesta finestra no la detecta ni la gestiona l'HA. Així que la finestra s'obre curta, amb el clúster sa, i es tanca tan bon punt acabes.
Quan no l'encendríem
No per desconfiança de l'eina, sinó perquè en aquests casos no resoldria el problema que el client té al davant:
- —Clúster de tres nodes al límit de capacitat. Si els tres van justos, el forat que necessites lliure no és el que iguala la mitjana: és el que et permet absorbir la caiguda d'un node sencer. Reequilibrar per quedar-te sense aquest forat és optimitzar el dia bo a costa del dolent.
- —Corosync compartint cable amb una altra cosa. Si la xarxa del clúster conviu amb la replicació o amb el trànsit de les VM, els talls de quòrum deixen de ser teòrics; i ara cada tall de quòrum té un rellotge de 60 segons al costat. Primer la xarxa, després el balanceig.
- —Quan la càrrega desigual té nom i cognoms. Si el que desnivella el clúster és una única VM concreta i coneguda, moure-la un cop amb el cap és millor que muntar un sistema que la mogui sola cada vegada que passi del llindar. Automatitzar una decisió que només es pren dues vegades l'any no és automatitzar, és amagar.
Les sis preguntes abans de prémer l'interruptor
Totes es responen amb un sí, un no o un número. Si alguna no la saps, aquesta és la tasca d'aquesta setmana, no el balancejador:
- 1.Quantes VM d'aquest node no són recursos HA? Aquest és el dany col·lateral el dia que es reiniciï.
- 2.Corosync té la seva pròpia xarxa, separada de l'emmagatzematge i de les VM? Sí o no.
- 3.De les VM que declararàs HA, quantes tenen disc local, passthrough o un bridge que no existeix a tots els nodes? Aquestes no es mouran.
- 4.Si cau un node sencer, hi caben les seves VM als que queden? Si la resposta és "just", el reequilibri et menjarà aquest marge.
- 5.El teu desequilibri real supera el 30 % durant més de mig minut seguit, o són pics de deu segons? Mira-ho abans, no després.
- 6.Està
disarm-haescrit al vostre procediment de manteniment de xarxa, o es confia que ningú trigui més d'un minut?
El balanceig dinàmic de la 9.2 és una bona peça i fa el que diu. El nostre criteri per encendre'l cap en una línia: quan la xarxa del clúster és on ha de ser i sobra marge per perdre un node sencer. I el deixem apagat, sense cap vergonya, quan no.
A everyWAN dissenyem i operem infraestructura i cloud sobre Proxmox VE amb emmagatzematge distribuït Ceph en producció. No venem llicències de ningú, així que quan diem que una funció no et fa falta, no estem deixant de facturar res.
Fonts (verificades el 06-11-2026): seccions Cluster Resource Scheduling, CRS Load Balancer, Requirements, Resources i Cluster Resource Manager (d.on surten les cites del watchdog, els 60 segons i els 15 minuts) del manual d'administració de Proxmox VE, versió 9.2.13 (última actualització del document: 24-set-2026) — pve-docs: HA Manager; valors per defecte de crs (el valor per recurs auto-rebalance és a la secció Resources del manual, no aquí) — datacenter.cfg(5); novetats i data de Proxmox VE 9.2 (21-maig-2026), inclosos el balanceig dinàmic i disarm-ha/arm-ha — Roadmap de Proxmox VE. Les cites en anglès estan preses literalment d'aquestes pàgines. La lectura sobre el radi de dany del reinici és nostra, no de la documentació, i es dedueix del fet que el watchdog actua sobre el node i no sobre el recurs.
Declararàs HA mitja dotzena de VM i no tens clar què canvia al node?
Revisem el disseny del clúster, la xarxa de Corosync i el marge real que et queda per perdre un node. Amb números teus, no amb els d'un fullet.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN