Proxmox VE 9.2 : Dynamic Load Balancer HA — Guide Complet CRS, Configuration GUI & CLI

Depuis ses premières versions, Proxmox VE dispose d'un système de haute disponibilité (HA) permettant de redémarrer automatiquement les machines virtuelles et containers sur un autre nœud en cas de panne. Mais jusqu'à la version 9.2, ce mécanisme restait réactif : il n'intervenait qu'en réponse à une défaillance, sans jamais chercher à optimiser la répartition des workloads entre nœuds en conditions normales. Résultat concret sur les clusters de production : un nœud à 85 % de RAM pendant qu'un autre tourne à 20 %, sans que Proxmox ne fasse rien. Le rééquilibrage était entièrement manuel — migrex à la main, script cron, ou outil tiers.

Proxmox VE 9.2 change la donne avec l'introduction du Dynamic Load Balancer, une évolution majeure du Cluster Resource Scheduler (CRS). En mode dynamique, le CRS surveille en temps réel les métriques de CPU et de mémoire de chaque nœud et de chaque guest HA, calcule un score d'équilibre global, et déclenche des live migrations automatiques pour corriger les déséquilibres détectés. Ce n'est pas un simple round-robin : le moteur de décision intègre les règles d'affinité HA, les contraintes de groupes de nœuds, et les préférences de ressources définies par l'administrateur. À cela s'ajoute une fonctionnalité très attendue en production : la commande disarm-ha / arm-ha, qui permet de geler proprement l'intégralité du stack HA avant une fenêtre de maintenance, éliminant le risque de fencing accidentel lors d'un redémarrage planifié. Cet article explore en détail le fonctionnement du Dynamic Load Balancer, sa configuration pas à pas, ses limites, et les bonnes pratiques pour l'intégrer dans un cluster de production.

Contexte : le Cluster Resource Scheduler avant Proxmox 9.2

Pour comprendre ce que change Proxmox 9.2, il faut revenir sur ce qu'est le CRS et comment il fonctionnait jusqu'ici.

Le Cluster Resource Scheduler (CRS) est le composant de Proxmox VE responsable de la planification du placement des guests (VMs et LXC) sur les nœuds du cluster. Il intervient dans deux situations :

• Au démarrage initial d'un guest : le CRS choisit le nœud le plus adapté selon des critères de capacité disponible (RAM libre, charge CPU).
• Lors d'un failover HA : si un nœud tombe en panne, le CRS sélectionne le nœud cible pour relancer les guests HA orphelins.

Avant la version 9.2, le CRS disposait de deux modes de fonctionnement :

• Mode statique (static) : le placement est calculé à partir des ressources configurées (RAM allouée, vCPU), sans tenir compte de l'utilisation réelle au moment du placement. C'est le mode par défaut depuis des années.
• Mode utilisation (utilization) : le CRS consulte l'utilisation actuelle des ressources pour affiner le choix au moment du placement initial. Mais ce mode n'était actif qu'à l'instant T du démarrage — il ne réévaluait pas continuellement le placement.

Le problème fondamental était l'absence de réévaluation continue. Une VM démarrée sur le nœud A au moment où il était le moins chargé pouvait y rester indéfiniment, même si le nœud A devenait saturé deux heures plus tard tandis que le nœud C était quasiment vide. Proxmox ne déplaçait rien. L'administrateur devait surveiller lui-même et migrer manuellement.

Cette situation est acceptable pour de petits clusters homelab, mais elle devient un problème sérieux en production où des dizaines de guests peuvent être répartis de façon sous-optimale, avec des impacts mesurables sur les performances applicatives et sur la capacité à absorber de nouveaux failovers.

Le Dynamic Load Balancer de Proxmox 9.2 : fonctionnement détaillé

Architecture générale

Le Dynamic Load Balancer de Proxmox 9.2 est implémenté comme un nouveau mode du CRS, appelé dynamic. Contrairement aux modes précédents qui n'agissaient qu'au moment du placement initial, le mode dynamique introduit une boucle d'évaluation continue : le CRS interroge régulièrement les métriques de charge de chaque nœud et de chaque guest HA, calcule l'état d'équilibre du cluster, et décide si des migrations sont nécessaires.

Cette boucle s'appuie sur le Proxmox Cluster Manager (PVE-CRM), le démon central de gestion HA qui tourne sur le nœud maître du cluster. C'est lui qui collecte les métriques, évalue l'algorithme de décision, et ordonne les migrations via les API internes de Proxmox.

Les métriques surveillées

Le CRS en mode dynamique collecte deux familles de métriques :

• Utilisation CPU réelle : exprimée en pourcentage d'utilisation effective des vCPUs de chaque guest, agrégée au niveau du nœud. Le CRS ne se base pas sur le nombre de vCPUs alloués (ce qui serait un indicateur statique) mais sur l'utilisation observée en temps réel via les mécanismes de monitoring internes de Proxmox.
• Pression mémoire réelle : la RAM effectivement utilisée par chaque guest, et non la mémoire allouée (balloon). Proxmox surveille la mémoire active des guests via les guest agents QEMU ou les statistiques du noyau pour les LXC.

Ces métriques sont collectées au niveau de chaque nœud par le démon pvedaemon, et remontées au PVE-CRM maître via le bus de communication interne du cluster (corosync). Le CRS calcule ensuite un score d'imbalance global basé sur l'écart-type de charge entre les nœuds : plus les charges sont hétérogènes, plus le score est élevé.

L'algorithme de décision

Lorsque le score d'imbalance dépasse le seuil configuré, le CRS passe en phase de résolution. Il cherche la migration optimale selon l'algorithme suivant :

1. Identification du nœud le plus chargé : le nœud avec le score de charge normalisé le plus élevé est le candidat source.
2. Sélection du guest candidat à la migration : parmi les guests HA actifs sur le nœud source, le CRS choisit celui dont la migration vers un autre nœud réduirait le score d'imbalance global de façon maximale, tout en respectant les contraintes (RAM disponible sur le nœud cible, affinité HA, groupes de nœuds).
3. Vérification des contraintes HA : avant de valider la migration, le CRS vérifie que le placement proposé est conforme aux règles d'affinité définies (affinité positive/négative entre guests, restrictions de groupe de nœuds). Si le placement optimal viole une règle, le CRS passe au candidat suivant.
4. Déclenchement de la live migration : si un couple source/cible valide est trouvé, le PVE-CRM ordonne une live migration du guest HA, sans interruption de service.
5. Réévaluation : après chaque migration, le score d'imbalance est recalculé. Si le cluster est suffisamment équilibré, la boucle entre en phase de veille. Sinon, le processus recommence.

Paramètres de sensibilité et de comportement

Le Dynamic Load Balancer est configurable dans deux endroits de l'interface Proxmox :

• Datacenter → Options → CRS : activation du mode dynamique et paramètres globaux.
• HA → Options : sensibilité du balancer, comportement des migrations automatiques.

Les paramètres clés exposés dans l'interface :

• Mode CRS : none (désactivé), static (placement initial uniquement), utilization (placement initial avec métriques réelles), dynamic (nouveau mode continu Proxmox 9.2).
• Seuil d'imbalance : valeur numérique au-delà de laquelle le balancer déclenche une migration. Un seuil bas (sensibilité élevée) peut provoquer des migrations trop fréquentes ; un seuil élevé laisse davantage de déséquilibre. Proxmox recommande de commencer avec les valeurs par défaut et d'ajuster à l'observation.
• Intervalle d'évaluation : fréquence à laquelle le CRS réévalue l'équilibre du cluster. Par défaut quelques minutes, configurable.

Configuration pas à pas du Dynamic Load Balancer

Prérequis

Avant d'activer le mode dynamique, vérifiez les prérequis suivants :

• Cluster Proxmox VE 9.2 opérationnel : au moins 3 nœuds (2 nœuds + 1 quorum ou qdevice). Le load balancer n'a de sens que sur un cluster multi-nœuds.
• Stack HA active : les services HA doivent être démarrés et opérationnels. Vérifiez avec ha-manager status.
• Guests inscrits dans le HA Manager : le CRS dynamique ne gère que les guests HA-enrolled. Les VMs non-HA ne seront pas déplacées. Inscrivez les guests critiques via HA → Ressources → Ajouter.
• Guest agents installés (recommandé) : pour les VMs, le qemu-guest-agent améliore la précision des métriques mémoire collectées.
• Réseau de migration dédié (recommandé) : configurez une interface réseau dédiée aux live migrations dans Datacenter → Options → Migration pour ne pas saturer le réseau de production pendant les rééquilibrages.

Activer le mode dynamique via l'interface web

1. Connectez-vous à l'interface Proxmox VE Web UI (port 8006).
2. Naviguez vers Datacenter → Options.
3. Repérez la section Cluster Resource Scheduler (CRS).
4. Passez le champ Mode de static à dynamic.
5. Cliquez sur OK pour appliquer.

La modification est immédiate et ne nécessite pas de redémarrage du cluster. Le CRS passe en mode dynamique sur tous les nœuds simultanément.

Activer le mode dynamique en ligne de commande

Via SSH sur n'importe quel nœud du cluster :

# Activer le mode CRS dynamique
pvesh set /cluster/options --crs-ha dynamic

# Vérifier la configuration actuelle
pvesh get /cluster/options | grep crs

Configurer la sensibilité dans les options HA

Une fois le mode dynamique activé, ajustez la sensibilité du balancer dans HA → Options :

# Via l'API REST Proxmox (exemple)
# Lister les options HA actuelles
pvesh get /cluster/ha/config/options

# Les paramètres de sensibilité seront exposés ici
# Modifier via l'interface Web : HA → Options → CRS sensitivity

En pratique, pour un premier déploiement en production, nous recommandons une approche progressive :

1. Semaine 1 : activez le mode dynamique avec les seuils par défaut (conservateurs). Observez les logs de migration dans /var/log/pve/ha-manager.log.
2. Semaine 2 : analysez la fréquence et la pertinence des migrations automatiques. Ajustez le seuil à la baisse si trop peu de migrations, à la hausse si trop fréquentes.
3. Semaine 3+ : affinez selon les patterns de charge observés (pics journaliers, hebdomadaires, saisonniers).

Surveiller l'activité du load balancer

Plusieurs commandes permettent de surveiller le comportement du CRS dynamique :

# Statut général du HA Manager
ha-manager status

# Logs du CRS (migrations automatiques)
journalctl -u pve-ha-crm --since "1 hour ago" | grep -i "crs\|balance\|migrat"

# Logs HA détaillés
tail -f /var/log/pve/ha-manager.log

# Métriques temps réel des nœuds (via API)
pvesh get /nodes --output-format json | jq '.[] | {node: .node, cpu: .cpu, mem: .mem, maxmem: .maxmem}'

La fonctionnalité Arm/Disarm du HA Manager

Parallèlement au Dynamic Load Balancer, Proxmox VE 9.2 apporte une autre amélioration très demandée par les équipes d'exploitation : la possibilité de désarmer et réarmer le HA Manager au niveau cluster pour les fenêtres de maintenance planifiée.

Le problème avant Proxmox 9.2

Avant cette version, effectuer une maintenance planifiée sur un cluster Proxmox HA était une opération délicate. Si vous redémarriez un nœud pour appliquer des mises à jour kernel ou changer un composant matériel, le HA Manager pouvait interpréter l'absence temporaire du nœud comme une panne et déclencher deux actions indésirables :

• Fencing du nœud : le cluster forçait l'arrêt matériel du nœud via IPMI/BMC pour s'assurer qu'il ne corromprait pas les données partagées.
• Failover des guests HA : les VMs du nœud en maintenance étaient relancées en urgence sur d'autres nœuds, souvent de façon chaotique.

L'ancienne procédure recommandée était fastidieuse : migrer manuellement tous les guests HA vers d'autres nœuds, passer le nœud en mode maintenance dans l'interface, effectuer les opérations, puis relancer les guests un par un. Sur un cluster de 20+ guests, cela représentait 30 à 60 minutes d'opérations manuelles à chaque maintenance.

Fonctionnement de Disarm/Arm HA

Proxmox VE 9.2 introduit les commandes disarm-ha et arm-ha au niveau du CRM (Cluster Resource Manager), permettant de geler l'intégralité du stack HA de façon sécurisée :

• disarm-ha : suspend l'ensemble du HA Manager cluster-wide. En état désarmé, aucun failover automatique n'est déclenché, aucun fencing n'est exécuté, et le Dynamic Load Balancer est mis en pause. L'état de tous les guests HA est préservé en mémoire — Proxmox sait dans quel état chaque ressource se trouve et où elle devrait être.
• arm-ha : réactive le HA Manager. L'état préservé est utilisé pour restaurer la supervision des guests HA sans reconfiguration. Si des guests ont migré ou changé d'état pendant la période désarmée, le HA Manager réévalue la situation et agit en conséquence.

Commandes CRM

Les nouvelles commandes s'utilisent en SSH depuis le nœud maître du cluster (ou tout nœud ayant accès au CRM) :

# Désarmer le HA Manager avant maintenance
ha-manager disarm-ha

# Vérifier l'état du HA Manager
ha-manager status

# Effectuer les opérations de maintenance
# (reboot nœud, MAJ kernel, remplacement disque, etc.)
# ...

# Réarmer le HA Manager après maintenance
ha-manager arm-ha

# Vérifier que tous les guests HA sont de nouveau supervisés
ha-manager status

La commande disarm-ha est également accessible via l'interface Web dans le menu HA → Actions → Désarmer le HA, ce qui la rend accessible aux administrateurs qui n'ont pas accès SSH direct aux nœuds.

Cas d'usage typiques

Mise à jour kernel planifiée sur tous les nœuds :

# 1. Désarmer le HA Manager
ha-manager disarm-ha

# 2. Mettre à jour et redémarrer chaque nœud l'un après l'autre
# Sur node1 :
apt update && apt full-upgrade -y && reboot

# Attendre le redémarrage, vérifier que node1 a rejoint le cluster
pvecm status

# Répéter pour node2, node3...

# 3. Réarmer le HA Manager
ha-manager arm-ha

# 4. Vérifier l'état
ha-manager status

Important : même en mode désarmé, le cluster reste opérationnel. Les VMs et LXC continuent de tourner. Seul le mécanisme de supervision automatique (failover, fencing) est suspendu. Si un nœud tombe réellement en panne pendant la période désarmée, il faudra intervenir manuellement.

Interaction entre le Dynamic Load Balancer et les règles HA

Règles d'affinité HA

Le Dynamic Load Balancer respecte scrupuleusement les règles d'affinité HA existantes. Ces règles définissent des contraintes de co-localisation ou d'anti-co-localisation entre guests, et des restrictions de groupes de nœuds :

• Groupes de nœuds HA (HA groups) : si un guest HA est assigné à un groupe de nœuds restrictif (par exemple, uniquement les nœuds équipés de GPU), le load balancer ne migrera jamais ce guest vers un nœud hors du groupe.
• Affinité positive : si deux guests doivent rester sur le même nœud (pour des raisons de latence ou de performance), le load balancer les traitera comme une unité.
• Affinité négative : si deux guests ne doivent pas cohabiter (résilience, licences), le balancer s'assurera qu'une migration ne les réunit pas.

Cette intégration est importante car elle signifie que le Dynamic Load Balancer n'est pas une baguette magique universelle. Si toutes vos VMs critiques sont contraintes au nœud A par des règles d'affinité, le balancer ne pourra pas les déplacer, même si le nœud A est surchargé. Concevez vos règles HA avec la flexibilité de placement comme critère.

Affinité manuelle vs balancer automatique

Un changement de comportement notable en 9.2 : les migrations HA manuelles respectent désormais les règles d'affinité. Avant cette version, une migration manuelle pouvait placer un guest dans une position qui violerait immédiatement une règle d'affinité, forçant le HA Manager à corriger le placement dès la migration terminée (double migration inutile). Cette correction est maintenant appliquée en amont, au moment où l'administrateur ordonne la migration manuelle.

Limites du Dynamic Load Balancer

Pour une utilisation éclairée, voici les limites importantes à connaître :

Scope : uniquement les guests HA-enrolled

C'est la limite la plus importante. Le Dynamic Load Balancer ne touche pas aux VMs et LXC non inscrits dans le HA Manager. Si vous avez des serveurs de développement, des VMs de test, ou des workloads batch qui ne sont pas gérés par HA, ils ne seront jamais déplacés par le load balancer, même s'ils consomment beaucoup de ressources sur un nœud surchargé.

Cette décision de conception est délibérée : Proxmox veut éviter de déplacer des workloads sans le consentement explicite de l'administrateur. L'inscription au HA Manager est le signal d'accord pour la gestion automatique.

Pas un outil de QoS

Le CRS dynamique optimise la distribution des workloads entre nœuds, pas la qualité de service au sein d'un nœud. Si un guest consomme 100 % d'un nœud à lui seul, le load balancer peut le migrer, mais il ne limitera pas la consommation du guest sur son nœud actuel. Pour le QoS intra-nœud, utilisez les mécanismes de CPU pinning et de limites de ressources des VMs.

Dépendance au réseau de migration

Chaque live migration générée par le balancer consume de la bande passante. Sur un cluster avec un réseau 10 GbE partagé entre production et migration, des rééquilibrages fréquents peuvent créer de la contention réseau. Configurez impérativement un réseau dédié aux migrations (Datacenter → Options → Migration) avec une interface réseau séparée.

Proxmox 9.2 : les autres nouveautés notables

Le Dynamic Load Balancer est la star de la version 9.2, mais Proxmox apporte plusieurs autres améliorations importantes que les administrateurs doivent connaître.

Kernel Linux 7.0 comme nouvelle base stable

Proxmox VE 9.2 passe sur le kernel Linux 7.0 comme base stable par défaut, en remplacement du kernel 6.x. Cette mise à jour apporte des améliorations substantielles pour les workloads de virtualisation : meilleure gestion des NUMA sur les architectures AMD EPYC et Intel Xeon récentes, amélioration des performances io_uring pour le stockage NVMe, et support de nouveaux matériels réseau et GPU.

La stack de virtualisation bénéficie également d'une mise à jour majeure : QEMU 11.0 apporte des améliorations aux périphériques virtio, un meilleur support des architectures ARM64, et des optimisations de performance pour les guests Windows. LXC 7.0 améliore l'isolation des namespaces et le support des systèmes de fichiers dans les containers.

Base OS : Debian 13.5 Trixie

Proxmox VE 9.2 est basé sur Debian 13.5 "Trixie", apportant l'ensemble des mises à jour de sécurité et des paquets à jour de l'écosystème Debian. Pour les administrateurs effectuant des mises à niveau depuis Proxmox 8.x (base Debian 12 Bookworm), une procédure de migration est documentée sur le wiki Proxmox.

SDN : WireGuard natif et améliorations BGP/EVPN

La stack SDN (Software-Defined Networking) de Proxmox intègre maintenant WireGuard comme protocole de fabric natif, sans nécessiter de configuration externe. WireGuard peut être utilisé pour créer des overlays chiffrés entre nœuds Proxmox géographiquement séparés, ouvrant des cas d'usage pour :

• Clusters multi-sites : deux datacenters reliés par un tunnel WireGuard automatiquement géré par Proxmox SDN, avec live migration de VMs entre sites.
• Labs DR : un site de reprise d'activité connecté au site primaire via WireGuard, avec réplication Ceph ou ZFS cross-site.
• Environnements cloud-edge : nœuds edge reliés à un cluster central via WireGuard.

Côté BGP/EVPN, Proxmox 9.2 ajoute le support des route maps et prefix lists pour le filtrage BGP, la redistribution des routes de fabric OSPF, et des options de configuration EVPN étendues incluant le support IPv6 en underlay.

Gestion des modèles CPU personnalisés via GUI

Jusqu'à Proxmox 9.1, la création de modèles CPU personnalisés (pour exposer des flags CPU spécifiques aux guests, ou pour assurer la compatibilité de migration entre nœuds avec des générations de processeurs différentes) se faisait uniquement via des fichiers de configuration QEMU édités à la main.

Proxmox 9.2 introduit une interface graphique dédiée dans Datacenter → CPU Models, permettant de créer, éditer et supprimer des profils CPU directement depuis l'interface web. Un sélecteur de flags CPU intégré affiche les flags supportés sur chaque nœud du cluster, facilitant la construction de profils compatibles avec l'ensemble du cluster.

Ceph Tentacle 20.2 comme option stable

Pour les clusters utilisant Ceph comme stockage distribué, Proxmox 9.2 propose Ceph Tentacle 20.2 comme version stable recommandée, en plus du support de Squid 19.2. Tentacle apporte des améliorations aux performances des volumes RBD (utilisés pour les disques de VMs) et une meilleure gestion des pools EC (Erasure Coding).

Sélection des guests pour les jobs de sauvegarde

L'interface de configuration des jobs de sauvegarde (Datacenter → Backup) bénéficie d'une refonte de la sélection des guests à inclure, avec un mode de filtrage plus intuitif permettant de combiner des critères par tags, par nœuds, et par noms.

Modes opératoires complets : GUI et CLI

Cette section détaille les procédures pas à pas pour activer, configurer et superviser le Dynamic Load Balancer et la fonctionnalité Arm/Disarm, avec les deux méthodes disponibles : interface web (GUI) et ligne de commande (CLI SSH).

Mode opératoire 1 — Activer le CRS dynamique

Via l'interface web (GUI)

1. Connectez-vous à l'interface Proxmox VE Web UI : https://<IP-nœud>:8006
2. Dans le panneau de gauche, cliquez sur Datacenter (l'entrée racine du cluster)
3. Cliquez sur l'onglet Options dans le panneau central
4. Repérez la ligne CRS et double-cliquez dessus (ou cliquez sur Edit)
5. Dans la boîte de dialogue, changez le champ Scheduler Policy de static à dynamic
6. Cliquez sur OK
7. Vérification : rafraîchissez la page Datacenter → Options — la valeur CRS doit afficher dynamic

Via la CLI (SSH)

# Connexion sur n'importe quel nœud du cluster
ssh root@<IP-nœud>

# Vérifier la valeur actuelle du CRS
pvesh get /cluster/options --output-format json | python3 -c "import sys,json; d=json.load(sys.stdin); print('CRS actuel:', d.get('crs-ha','non défini'))"

# Activer le mode dynamique
pvesh set /cluster/options --crs-ha dynamic

# Confirmer le changement
pvesh get /cluster/options | grep crs

Mode opératoire 2 — Inscrire des guests dans le HA Manager

Rappel : le CRS dynamique ne gère que les guests inscrits en HA. Cette étape est indispensable.

Via l'interface web (GUI)

1. Dans le panneau gauche, cliquez sur Datacenter → HA
2. Cliquez sur l'onglet Resources
3. Cliquez sur le bouton Add
4. Dans le champ VM / CT, sélectionnez la VM ou le container à inscrire
5. Choisissez le State souhaité : started (le HA Manager doit la maintenir démarrée)
6. Optionnel : sélectionnez un Group HA pour restreindre les nœuds éligibles
7. Définissez les paramètres de Max Restart et Max Relocate selon votre politique
8. Cliquez sur Add

Via la CLI (SSH)

# Inscrire la VM 100 dans le HA Manager, état souhaité : started
ha-manager add vm:100 --state started --max_restart 3 --max_relocate 2

# Inscrire le container LXC 200
ha-manager add ct:200 --state started

# Inscrire avec un groupe HA spécifique (ici groupe "production")
ha-manager add vm:101 --state started --group production

# Lister toutes les ressources HA
ha-manager status

Mode opératoire 3 — Configurer la sensibilité du load balancer

Via l'interface web (GUI)

1. Allez dans Datacenter → HA
2. Cliquez sur l'onglet Options
3. Repérez la section relative au CRS / Load Balancer sensitivity
4. Ajustez le curseur ou la valeur numérique selon votre besoin (valeur plus basse = plus sensible = migrations plus fréquentes)
5. Cliquez sur OK pour appliquer

Via la CLI (SSH)

# Vérifier les options HA actuelles (inclut les paramètres CRS)
pvesh get /cluster/ha/config/options

# Les paramètres de sensibilité apparaissent dans cet endpoint
# Modifier via pvesh si le paramètre est exposé :
# pvesh set /cluster/ha/config/options --crs-sensitivity <valeur>

# Surveiller les décisions de migration du CRS en temps réel
journalctl -u pve-ha-crm -f | grep -E "crs|balance|migrat|imbal"

Mode opératoire 4 — Créer un groupe HA pour contraindre le placement

Via l'interface web (GUI)

1. Allez dans Datacenter → HA → Groups
2. Cliquez sur Create
3. Donnez un nom au groupe (ex : production, gpu-nodes, site-paris)
4. Dans Nodes, sélectionnez les nœuds autorisés pour ce groupe et leur priorité (ex : node1:2,node2:1 — node1 en prioritaire)
5. Cochez Restricted si le guest ne peut être exécuté que sur les nœuds du groupe (le CRS ne pourra pas le migrer ailleurs)
6. Cochez No Failback si vous ne voulez pas que le guest revienne automatiquement sur son nœud d'origine après une panne
7. Cliquez sur Create

Via la CLI (SSH)

# Créer un groupe HA "production" avec node1 prioritaire, node2 secondaire
pvesh create /cluster/ha/groups --group production \
  --nodes "node1:2,node2:1,node3:1" \
  --restricted 1 \
  --nofailback 0 \
  --comment "VMs de production critiques"

# Assigner la VM 100 à ce groupe
pvesh set /cluster/ha/resources/vm:100 --group production

# Lister les groupes HA existants
pvesh get /cluster/ha/groups

Mode opératoire 5 — Désarmer et réarmer le HA Manager pour maintenance

Via l'interface web (GUI)

1. Allez dans Datacenter → HA
2. Dans le panneau, repérez le bouton Disarm HA (ou le menu Actions)
3. Cliquez sur Disarm HA — une confirmation est demandée
4. Confirmez : l'état du HA Manager passe en Disabled/Disarmed
5. Effectuez vos opérations de maintenance (reboot nœuds, MAJ, etc.)
6. Une fois la maintenance terminée, cliquez sur Arm HA
7. Vérifiez que tous les guests HA reprennent leur supervision normale dans l'onglet Resources

Via la CLI (SSH)

# === AVANT MAINTENANCE ===
# Vérifier l'état initial du HA Manager
ha-manager status

# Désarmer le HA Manager cluster-wide
ha-manager disarm-ha

# Confirmer l'état désarmé
ha-manager status
# → Doit afficher : HA Manager disarmed

# === PENDANT MAINTENANCE ===
# Exemple : reboot d'un nœud pour MAJ kernel
# Sur node1 :
ssh root@node1 "apt update && apt full-upgrade -y && reboot"

# Attendre le redémarrage et vérifier la réintégration au cluster
watch -n 5 "pvecm status"
# → Attendre que node1 réapparaisse avec le bon quorum

# === APRÈS MAINTENANCE ===
# Réarmer le HA Manager
ha-manager arm-ha

# Vérifier le retour à la normale
ha-manager status

# Vérifier que le CRS dynamique reprend son activité
journalctl -u pve-ha-crm --since "5 minutes ago" | grep -E "crs|arm|start"

Mode opératoire 6 — Surveiller et diagnostiquer le load balancer

Via l'interface web (GUI)

1. Les migrations déclenchées par le CRS dynamique apparaissent dans Datacenter → Tasks avec le type qmigrate ou vzmigrate et l'initiateur ha-manager
2. Pour voir les logs HA : cliquez sur un nœud → System → Syslog, filtrez sur pve-ha-crm
3. La charge en temps réel des nœuds est visible dans Datacenter → Summary (vue cluster) ou dans chaque nœud → Summary

Via la CLI (SSH)

# Historique des migrations HA (dernière heure)
journalctl -u pve-ha-crm --since "1 hour ago" | grep -i migrat

# Charge CPU et RAM de chaque nœud en temps réel
watch -n 10 "pvesh get /nodes --output-format json | \
  python3 -c \"import sys,json; \
  [print(f'{n[\\\"node\\\"]:<15} CPU:{n[\\\"cpu\\\"]*100:>5.1f}%  RAM:{n[\\\"mem\\\"]/n[\\\"maxmem\\\"]*100:>5.1f}%  ({n[\\\"mem\\\"]/1024**3:.0f}/{n[\\\"maxmem\\\"]/1024**3:.0f} GB)') \
  for n in json.load(sys.stdin)]\""

# Score d'imbalance : calculer manuellement l'écart de charge
pvesh get /nodes --output-format json | python3 -c "
import sys, json, statistics
nodes = json.load(sys.stdin)
loads = [n['cpu']*100 for n in nodes]
print(f'Charges CPU: {[f\"{l:.1f}%\" for l in loads]}')
print(f'Écart-type: {statistics.stdev(loads):.2f}%  (plus élevé = plus déséquilibré)')
"

# Statut détaillé de chaque ressource HA
ha-manager status -v

Migration depuis Proxmox 9.0 / 9.1

Pour les clusters déjà sur Proxmox VE 9.x, la mise à niveau vers 9.2 suit le processus standard :

# Sur chaque nœud, un par un (commencer par les nœuds sans VMs critiques)
# 1. Vérifier les sources APT
cat /etc/apt/sources.list.d/pve-enterprise.list
# ou pour no-subscription :
cat /etc/apt/sources.list.d/pve-no-subscription.list

# 2. Mettre à jour
apt update
apt full-upgrade

# 3. Vérifier la version après mise à jour
pveversion

# 4. Redémarrer pour charger le nouveau kernel 7.0
reboot

# 5. Vérifier que le nœud a rejoint le cluster
pvecm status

Scénarios d'usage en production : ce que change réellement le Dynamic Load Balancer

Cluster hétérogène avec pics de charge diurnes

Imaginons un cluster de 4 nœuds hébergeant 40 VMs HA : serveurs web, bases de données, services applicatifs. Le matin, les serveurs web démarrent des sessions en masse sur les nœuds 1 et 2, tandis que les nœuds 3 et 4 restent sous-utilisés. Sans le Dynamic Load Balancer, cette situation persiste toute la journée.

Avec le mode dynamique activé, le CRS détecte le déséquilibre dès les premières minutes du pic. Il migre 2 ou 3 VMs web vers les nœuds 3 et 4, réduisant la charge des nœuds 1 et 2. En soirée, quand la charge web diminue et que les traitements batch nocturnes démarrent sur les nœuds 3 et 4, le CRS rééquilibre dans l'autre sens. L'équipe d'exploitation n'intervient pas : le cluster s'optimise seul.

Préparation à un failover

Un cluster équilibré absorbe mieux les failovers imprévus. Si un nœud tombe en panne sans prévenir, les 10 VMs qu'il hébergeait doivent redémarrer sur les 3 nœuds restants. Si ces 3 nœuds étaient déjà à 80 % de charge, certains failovers peuvent échouer par manque de ressources.

Le Dynamic Load Balancer maintient une répartition homogène au quotidien, ce qui signifie que chaque nœud dispose en permanence d'une marge de capacité plus importante pour absorber un failover. C'est indirectement une amélioration de la résilience HA, pas seulement de l'optimisation de performance.

Consolidation et green IT

Le Dynamic Load Balancer peut aussi être utilisé dans une logique de consolidation : en maintenant les workloads concentrés sur les nœuds les plus chargés (seuil d'imbalance inversé ou logique applicative), il devient possible d'identifier les nœuds constamment sous-utilisés et de les mettre en veille pour réduire la consommation électrique. Cette intégration n'est pas native dans Proxmox 9.2 mais peut être construite avec des scripts utilisant l'API Proxmox en complément du CRS dynamique.

Questions fréquentes