Proxmox VE 9.2: configurare il Dynamic Load Balancer HA senza sorprese

Proxmox VE 9.2 introduce un Dynamic Load Balancer integrato nello stack High Availability. Non distribuisce semplicemente le VM in parti uguali: il Cluster Resource Scheduler (CRS) usa carico reale, configurazione dei guest e vincoli HA per decidere se una migrazione può ridurre lo sbilanciamento. È una funzione interessante per cluster piccoli e medi, ma va attivata con metodo: ogni riequilibrio genera traffico, consumo CPU e una migrazione live.

Questa guida chiarisce cosa bilancia davvero Proxmox, quali prerequisiti verificare e come adottarlo senza trasformare un’automazione utile in una fonte di instabilità.

Cosa cambia rispetto al bilanciamento statico

Il CRS dispone di più modalità. basic ragiona soprattutto sul numero di guest attivi. static-load considera le risorse configurate, come CPU e memoria assegnate. dynamic-load incorpora anche l’utilizzo medio osservato dei nodi e dei guest attivi. La memoria pesa più della CPU nel calcolo, perché è una risorsa rigida: un picco CPU può essere assorbito nel tempo, mentre una pressione eccessiva sulla RAM può portare a swapping o OOM.

Il bilanciatore valuta periodicamente il cluster e seleziona la migrazione che riduce maggiormente lo squilibrio. Le migrazioni vengono eseguite in sequenza e rispettano le regole di affinità HA. Nella versione 9.2 il perimetro è importante: il riequilibrio automatico riguarda i guest gestiti da HA, non tutte le VM e tutti i container.

Prerequisiti prima di abilitarlo

Il load balancer non sostituisce una progettazione HA corretta. Prima dell’attivazione verifica:

almeno tre nodi e quorum stabile;
storage condiviso accessibile da tutti i nodi candidati;
bridge, VLAN e reti disponibili con nomi coerenti;
CPU compatibili per la live migration oppure un modello CPU comune;
assenza di passthrough locali non replicabili, salvo vincoli espliciti;
banda e latenza adeguate sulla rete di migrazione;
backup recenti e test di ripristino già eseguiti;
regole di node affinity per i guest limitati ad alcuni host.

Una VM con GPU PCIe in passthrough, storage locale o interfaccia presente su un solo nodo non deve essere lasciata eleggibile ovunque. Il posto giusto per esprimere il vincolo è una regola di affinità stretta, non una nota nella documentazione interna.

Raccogli anche una baseline di alcuni giorni: uso CPU e RAM per nodo, picchi, durata delle migrazioni, throughput della rete dedicata e spazio sullo storage. Senza baseline non puoi distinguere un bilanciamento utile da semplice movimento.

Configurazione dalla GUI

Il percorso è Datacenter → Options → Cluster Resource Scheduling. Seleziona dynamic-load come modalità CRS e configura il load balancer automatico. I parametri centrali sono tre:

Imbalance threshold: la soglia oltre la quale il cluster è considerato sbilanciato. Il valore predefinito documentato è 30%. Una soglia troppo bassa rende il sistema nervoso e può causare migrazioni per variazioni normali.
Hold duration: quante iterazioni consecutive devono confermare lo sbilanciamento. Serve a ignorare picchi brevi. Un ciclo HA dura circa dieci secondi, quindi il valore va scelto pensando alla persistenza del carico, non alla velocità di reazione.
Imbalance improvement: miglioramento minimo atteso per autorizzare una migrazione. Il valore predefinito è 10%. Evita di spostare una VM quando il beneficio calcolato è marginale.

Non partire da soglie aggressive. Mantieni inizialmente i valori predefiniti, osserva il comportamento e modifica un solo parametro alla volta. In un homelab con rete a 1 Gb/s o storage non particolarmente rapido conviene privilegiare stabilità e poche migrazioni significative.

L’opzione HA rebalance on start consente al CRS di scegliere il nodo più adatto quando si avvia una risorsa HA. Per static-load e dynamic-load la documentazione la indica ancora come technology preview e ne sconsiglia l’uso su ambienti con migliaia di risorse. In produzione va trattata come funzione da validare, non come casella da selezionare automaticamente.

Escludere i workload sensibili

Ogni risorsa HA dispone dell’opzione auto-rebalance, attiva per impostazione predefinita. Disabilitala per database sensibili alla latenza, appliance con licenze legate all’host, guest con finestre operative rigide o workload che hanno già un proprio meccanismo applicativo di distribuzione.

Attenzione alle affinità positive: se una risorsa esclusa dal riequilibrio deve restare insieme a un’altra risorsa, anche quest’ultima non parteciperà alle migrazioni automatiche. Le regole rappresentano vincoli reali e prevalgono sul desiderio di ottenere nodi graficamente uniformi.

Rollout controllato

Una procedura prudente può essere articolata così:

aggiorna tutti i nodi alla stessa release supportata e controlla il quorum;
verifica configurazione e stato con ha-manager config e ha-manager status;
applica affinità ed esclusioni prima di attivare il bilanciatore;
abilita dynamic-load durante una finestra presidiata;
osserva almeno un ciclo di carico rappresentativo;
controlla i log del CRM master e degli LRM coinvolti;
misura durata, banda e impatto delle migrazioni;
documenta soglie, motivazioni ed esclusioni.

Per il troubleshooting sono utili:

ha-manager status
ha-manager config
journalctl -u pve-ha-crm --since "1 hour ago"
journalctl -u pve-ha-lrm --since "1 hour ago"

Il CRM prende le decisioni cluster-wide; l’LRM esegue le azioni sul nodo. Per ricostruire una migrazione bisogna leggere entrambi i lati, identificando prima quale nodo detiene il ruolo di CRM master.

Quando fermarsi

Più equilibrio non significa automaticamente più affidabilità. Se le migrazioni saturano la rete, aumentano la latenza dello storage o si ripetono senza un vantaggio osservabile, alza soglia e durata oppure escludi i workload problematici. L’obiettivo non è mantenere grafici identici, ma ridurre la contesa preservando margine per un failover reale.

Prima di affidarti all’automazione, prova una migrazione manuale per ogni classe di guest e verifica che rete, storage e modello CPU siano realmente compatibili. Testa poi il comportamento con un nodo in manutenzione: un cluster bilanciato ma privo di capacità residua non è resiliente.

Checklist finale

Quorum e HA risultano sani.
Tutti i nodi candidati espongono dipendenze compatibili.
Le affinità descrivono i vincoli hardware e applicativi.
I guest sensibili hanno auto-rebalance disabilitato.
Le soglie partono da valori conservativi.
Rete e storage sono monitorati durante le migrazioni.
Rimane capacità sufficiente a sostenere la perdita di un nodo.
Esistono backup verificati e una procedura di disattivazione.

Il Dynamic Load Balancer è utile quando riduce decisioni manuali ripetitive senza nascondere i vincoli dell’infrastruttura. Attivato dopo una baseline, con affinità corrette e osservabilità adeguata, può migliorare l’uso delle risorse. Attivato alla cieca, rischia soltanto di automatizzare migrazioni che non servono.