JB ServicesJulien Berton

Proxmox VE 9.2 : l’équilibrage de charge dynamique face au DRS de vSphere

Par Julien Berton, architecte IT · Publié le · 8 min de lecture

Proxmox VE 9.2, publiée au printemps 2026, ajoute au gestionnaire de haute disponibilité un équilibreur de charge dynamique. Le cluster peut désormais déplacer à chaud des VM d’un nœud chargé vers un nœud moins sollicité, sans intervention de l’administrateur. Pour les équipes qui quittent vSphere, c’était l’un des derniers arguments en faveur de VMware : l’absence d’équivalent au DRS.

Dans les études de migration que je mène, la question revient presque à chaque fois : « Qu’est-ce qu’on perd en quittant le DRS ? ». Cet article fait le point sur ce que la version 9.2 apporte réellement, sur les différences qui subsistent avec vSphere et sur les précautions à prendre avant d’activer l’équilibrage automatique sur un cluster de production, en particulier quand il héberge des VM techniques ou industrielles.

Ce que fait le DRS dans vSphere

Le Distributed Resource Scheduler remplit deux rôles. Au démarrage d’une VM, il choisit l’hôte le plus adapté (placement initial). En fonctionnement, il surveille la consommation de processeur et de mémoire des hôtes et recommande ou exécute des migrations vMotion pour rééquilibrer le cluster. Trois niveaux d’automatisation existent (manuel, partiellement automatisé, entièrement automatisé) et un seuil de migration, réglable sur cinq niveaux, détermine à partir de quel déséquilibre une migration est jugée utile.

Le DRS porte aussi les règles d’affinité : garder deux VM ensemble, les séparer (anti-affinité), ou lier un groupe de VM à un groupe d’hôtes. Dans beaucoup de clusters que j’audite, ce sont ces règles qui comptent le plus, bien plus que le rééquilibrage lui-même : les deux contrôleurs de domaine ne doivent jamais tourner sur le même hôte, une VM sous licence liée au matériel doit rester sur certains serveurs.

Ce que Proxmox VE proposait avant la 9.2

Proxmox VE dispose depuis plusieurs versions d’un ordonnanceur de ressources pour le cluster (Cluster Resource Scheduler, CRS), intégré à la pile HA. En mode statique, il choisit le nœud de destination d’une VM gérée par la HA à partir des ressources configurées (vCPU et mémoire) des invités déjà présents sur chaque nœud. Il intervient au démarrage, lors d’une reprise après la panne d’un nœud ou lors d’une mise en maintenance, mais pas en continu.

La version 9.0 a remplacé les anciens groupes HA par des règles HA : des règles d’affinité de nœud (préférer ou imposer certains nœuds pour une ressource) et des règles d’affinité entre ressources (garder des VM ensemble ou les séparer). Ce sont les équivalents fonctionnels des règles VM-hôte et VM-VM du DRS. Il manquait donc surtout la partie dynamique : réagir à une charge qui évolue pendant la journée.

Ce qu’apporte l’équilibreur dynamique de la 9.2

Avec Proxmox VE 9.2, le CRS ne se limite plus au placement : il peut prendre en compte la charge réellement observée sur les nœuds et déclencher des migrations à chaud pour répartir les ressources gérées par la HA. Le fonctionnement reste cohérent avec le reste de la pile HA : les règles d’affinité définies depuis la 9.0 sont respectées lors des déplacements, et seules les ressources placées sous gestion HA sont concernées.

La même version apporte d’autres évolutions utiles dans un projet de migration : le noyau Linux 7.0 par défaut, la prise en charge de WireGuard dans le SDN pour relier des sites ou des segments de manière chiffrée, et des améliorations de gestion des clusters. Les critères, seuils et paramètres exacts de l’équilibreur sont décrits dans la documentation officielle et les notes de version : ils sont à lire attentivement avant toute activation, car ils diffèrent de ceux du DRS.

Les différences qui subsistent avec le DRS

  • Périmètre : le DRS s’applique à toutes les VM d’un cluster où il est activé. Sous Proxmox VE, une VM qui n’est pas déclarée dans la HA n’est ni redémarrée automatiquement ni rééquilibrée. Cela oblige à décider, VM par VM, ce qui doit être géré par le cluster, ce qui est plutôt une bonne discipline.
  • Maturité : le DRS a près de vingt ans de retours d’expérience. L’équilibreur de Proxmox VE est une fonctionnalité récente : il faut l’observer sur son propre cluster avant de lui faire confiance en mode entièrement automatique.
  • Vue multi-cluster : vCenter regroupe plusieurs clusters dans une même console. Côté Proxmox, ce rôle revient à Proxmox Datacenter Manager, disponible en version stable 1.0 depuis décembre 2025 puis en 1.1 en 2026 : vue centralisée de plusieurs clusters, migration de VM entre clusters, supervision de Ceph et installation automatisée de nœuds dans la dernière version.
  • Outillage tiers : certains outils de capacité ou de reporting s’appuyaient sur les métriques DRS et vROps. Il faut prévoir leur remplacement, par exemple par Zabbix pour l’historique de charge des nœuds.

Avant d’activer l’équilibrage : les points de contrôle

1. Le stockage et le réseau de migration

Une migration à chaud sans déplacement de disque suppose un stockage partagé : Ceph, NFS ou iSCSI. Une VM sur stockage local peut être migrée, mais le transfert du disque change complètement la durée et la charge réseau. Le trafic de migration doit circuler sur un réseau dédié et dimensionné, séparé du réseau Ceph et du trafic Corosync, qui supporte mal la latence. Un rééquilibrage qui sature le lien de réplication Ceph crée plus de problèmes qu’il n’en résout.

2. Les VM qui ne doivent pas bouger

C’est le point le plus souvent sous-estimé, et il concerne surtout les environnements techniques et industriels :

  • VM avec un périphérique USB passé en direct : interface KNX USB, clé de licence matérielle, adaptateur série vers un automate ;
  • VM avec carte PCI en passthrough, comme un GPU utilisé pour le rendu d’un jumeau numérique sous Unreal Engine 5 ;
  • logiciels dont la licence est liée à l’identifiant matériel de l’hôte ;
  • passerelles de supervision GTB qui maintiennent des sessions BACnet ou Modbus TCP sensibles à une coupure, même brève.

Pour ces VM, deux options : les laisser hors HA, ou les déclarer avec une règle d’affinité de nœud stricte. Dans les deux cas, la décision doit être écrite dans le dossier d’exploitation.

3. Les règles de séparation

Avant d’automatiser, je recense les paires et groupes qui doivent rester séparés : contrôleurs de domaine, serveurs DNS, nœuds d’un pare-feu virtuel en haute disponibilité, proxies Zabbix, serveurs applicatifs derrière un répartiteur. Chaque paire devient une règle d’affinité négative entre ressources. Sans ces règles, un équilibreur peut très bien réunir les deux membres d’une paire sur le même nœud parce que c’est la répartition la plus équilibrée à cet instant.

4. Le quorum et la capacité de reprise

La HA de Proxmox VE repose sur le quorum Corosync et sur le fencing par watchdog : un nœud qui perd le quorum s’isole lui-même pour que ses VM puissent redémarrer ailleurs. Il faut au moins trois votes, donc trois nœuds ou deux nœuds et un QDevice. Côté capacité, le cluster doit pouvoir absorber la perte d’un nœud (N+1) : un équilibreur répartit la charge, il ne crée pas de marge.

5. La supervision des migrations

Chaque migration automatique doit être visible : journal des tâches du cluster, alertes Zabbix sur le nombre de migrations par heure, corrélation avec la charge des nœuds. Un cluster qui fait des allers-retours entre deux nœuds signale un seuil mal réglé ou une VM dont la charge varie trop vite.

Une mise en service progressive

  1. Mettre à jour le cluster en 9.2, nœud par nœud, après lecture des notes de version et sauvegarde vérifiée.
  2. Passer en revue les ressources HA : ajouter celles qui doivent l’être, sortir ou épingler celles qui ne doivent pas bouger.
  3. Créer les règles d’affinité de nœud et d’anti-affinité avant toute activation.
  4. Observer quelques semaines la charge des nœuds dans la supervision pour savoir si le déséquilibre est réel et à quelles heures.
  5. Activer l’équilibrage avec un réglage prudent, puis ajuster à partir du journal des migrations.

Dans un projet de migration de VMware vers Proxmox VE, je traite ce sujet dès l’étude de faisabilité : l’inventaire des règles DRS existantes indique ce qui doit être recréé en règles HA, et les VM non migrables à chaud sont identifiées avant la première vague. La méthode complète est détaillée dans l’article Migrer de VMware vers Proxmox VE : la méthode en 7 étapes, et le calendrier de fin de support dans Fin de support de vSphere 8.

Votre cluster vSphere utilise le DRS et des règles d’affinité ? L’étude de faisabilité recense les règles, les VM non migrables à chaud et le dimensionnement nécessaire côté Proxmox VE. Voir l’offre migration VMware vers Proxmox.

Sources