Dans un cluster de virtualisation, le placement initial d'une VM n'est jamais définitif. Les charges évoluent, certaines machines consomment davantage que prévu et les maintenances déplacent progressivement les workloads. Un cluster qui était équilibré le lundi peut concentrer l'essentiel de sa mémoire ou de son CPU sur un seul nœud quelques semaines plus tard.
VMware répond depuis longtemps à ce problème avec Distributed Resource Scheduler, plus connu sous le nom de DRS. Proxmox VE dispose de son propre mécanisme : le Cluster Resource Scheduler, ou CRS. Avec Proxmox VE 9.2 et son nouveau Dynamic Load Balancer, la comparaison devient enfin sérieuse.
Mais CRS n'est pas une copie de DRS. Son périmètre, ses déclencheurs et son niveau de maturité sont différents. Pour l'exploiter correctement, il faut comprendre ce qu'il mesure, quand il prend une décision et quelles ressources il peut réellement déplacer.
Qu'est-ce que le Cluster Resource Scheduler ?
CRS est le moteur de placement de ressources du gestionnaire de haute disponibilité de Proxmox VE. Il aide le HA Manager à choisir le meilleur nœud lorsqu'une VM ou un conteneur géré par la HA doit être démarré, récupéré ou déplacé.
Le scheduler intervient notamment lors :
- de la récupération d'un service après la perte d'un nœud ;
- d'un démarrage ou d'un déplacement piloté par la HA ;
- d'une modification des règles ou groupes HA ;
- d'un rééquilibrage au démarrage, s'il est activé ;
- d'un rééquilibrage automatique périodique avec Proxmox VE 9.2.
Le point essentiel est là : CRS appartient à la pile HA. Il ne parcourt pas indistinctement toutes les VM du datacenter. Le mécanisme automatique de Proxmox VE 9.2 migre les ressources administrées par le HA Manager et autorisées à participer au rééquilibrage.
De Proxmox VE 7.3 à 9.2 : une évolution en trois étapes
CRS n'est pas apparu soudainement avec la version 9.2.
Proxmox VE 7.3 : les fondations
En 2022, Proxmox VE 7.3 pose les fondations du Cluster Resource Scheduler sous forme de Technology Preview. Le mode static-load ne se contente plus de compter les services : il exploite les vCPU et la mémoire configurés pour évaluer plusieurs destinations.
Le moteur utilise TOPSIS, une méthode d'aide à la décision multicritère. Chaque nœud admissible constitue une alternative ; le scheduler compare l'effet du placement sur l'ensemble du cluster puis sélectionne l'option la plus favorable.
Ce premier CRS reste toutefois limité aux situations dans lesquelles le HA Manager doit déjà rechercher un nouveau nœud : récupération après incident, politique d'arrêt ou modification de la configuration d'un groupe HA. Il ne surveille pas encore la charge pour déclencher spontanément des migrations et ne constitue donc pas un équilibrage continu.
Proxmox VE 9.0 : des règles de placement plus précises
Proxmox VE 9.0 transforme les contraintes de placement en règles HA explicites. Les anciennes configurations de groupes HA sont dépréciées et migrées vers des règles d'affinité entre ressources et nœuds.
Une règle ressource-nœud peut attribuer des priorités à plusieurs hôtes. En mode non strict, CRS préfère ces nœuds mais peut utiliser un autre membre du cluster s'ils sont indisponibles. En mode strict, la ressource ne peut fonctionner que sur les nœuds autorisés ; si aucun n'est disponible, elle n'est pas démarrée ailleurs.
Les règles ressource-ressource décrivent les relations entre workloads. Une affinité positive demande à CRS de les réunir sur le même nœud, par exemple pour réduire la latence entre une application et sa base. Une affinité négative les répartit sur des nœuds différents afin qu'une panne unique ne touche pas simultanément plusieurs composants redondants.
Ces règles s'appliquent au placement, à la récupération HA et aux migrations décidées par CRS. Leur création ou leur modification peut provoquer un repositionnement pour rétablir la contrainte. Proxmox VE 9.0 ne déclenche toutefois pas encore de migrations en observant un déséquilibre de charge : il apporte le cadre de placement que le mode dynamique de la 9.2 utilisera ensuite.
Proxmox VE 9.2 : charge réelle et migrations automatiques
Depuis mai 2026, le mode dynamic-load ajoute l'utilisation réelle du CPU et de la mémoire aux décisions. Le CRS Load Balancer peut aussi déclencher automatiquement des migrations de ressources HA afin de réduire un déséquilibre persistant entre les nœuds.
C'est ce dernier point qui rapproche le plus CRS de VMware DRS : le scheduler ne choisit plus seulement une destination lorsqu'un événement impose déjà un placement ; il peut agir de lui-même pour améliorer la distribution des charges.
Les trois modes de calcul
Le mode choisi modifie profondément la qualité du placement.
basic : compter les ressources actives
Le mode historique cherche principalement à répartir le nombre de services HA. Trois petites VM et trois VM très consommatrices ont cependant le même poids comptable.
Ce mode est prévisible et peu coûteux, mais il peut produire un équilibre visuel trompeur : chaque nœud héberge le même nombre de VM alors que leur consommation réelle est très différente.
static-load : utiliser les ressources configurées
Le scheduler prend en compte les vCPU et la mémoire déclarés dans la configuration des invités. Avant de placer une ressource, il simule son impact sur chaque nœud éligible.
Cette approche est utile lorsque les quotas reflètent correctement les besoins. Elle devient moins précise en présence de VM largement surdimensionnées ou de workloads dont la consommation varie fortement.
dynamic-load : intégrer la consommation observée
Le mode dynamique combine les métriques d'utilisation des nœuds et des invités avec les quotas configurés. Il distingue donc une VM réellement active d'une VM qui possède huit vCPU mais reste presque toujours inactive.
La mémoire reçoit un poids particulièrement important dans le calcul, car elle représente une ressource physiquement limitée et moins compressible que le CPU. Le scheduler ne recherche pas une égalité parfaite ; il cherche une meilleure alternative en considérant simultanément les points hauts et la répartition globale.
| Mode | Données principales | Avantage | Limite |
|---|---|---|---|
basic |
Nombre de services HA | Simple et prévisible | Ignore la taille et la charge |
static-load |
vCPU et RAM configurés | Anticipe les besoins déclarés | Sensible au surdimensionnement |
dynamic-load |
Charge réelle et quotas | Reflète mieux l'activité | Dépend de métriques fiables et fluctuantes |
Comment fonctionne le rééquilibrage automatique ?
Le HA Manager travaille par cycles d'environ dix secondes. À chaque cycle, le load balancer peut évaluer le niveau de déséquilibre du cluster. Il ne lance pas une migration à la moindre variation : plusieurs garde-fous évitent de déplacer continuellement les VM.
Le principe peut être résumé ainsi :
- mesurer la charge des nœuds et des ressources HA ;
- vérifier que le déséquilibre dépasse un seuil configuré ;
- attendre qu'il persiste pendant la durée prévue ;
- simuler les migrations admissibles ;
- écarter celles qui violent une règle HA ou n'apportent pas assez d'amélioration ;
- choisir la migration qui réduit le mieux le déséquilibre ;
- effectuer les migrations séquentiellement, puis réévaluer le cluster.
Dynamic Load, le rééquilibrage au démarrage et les migrations automatiques se configurent depuis les paramètres CRS du datacenter.Comprendre les paramètres de rééquilibrage
Imbalance Threshold (%). Ce seuil détermine à partir de quel niveau le cluster est considéré comme suffisamment déséquilibré pour envisager une migration. Le déséquilibre est normalisé sur une échelle de 0 à 100 % à partir de la moyenne et de l'écart-type des charges des nœuds. La valeur par défaut est de 30 %. Tant que le cluster reste sous ce seuil, CRS n'agit pas.
Rebalancing Method. Cette option choisit la méthode de notation des migrations candidates. bruteforce, la valeur par défaut, compare les déplacements admissibles et retient celui qui produit le plus faible déséquilibre attendu. TOPSIS est l'autre méthode disponible dans Proxmox VE 9.2 ; elle classe les candidats par rapport à une solution idéale et à une solution défavorable. Les règles HA restent prioritaires dans les deux cas : une destination interdite ne devient jamais candidate.
Hold Duration. Cette valeur indique pendant combien de cycles HA consécutifs le seuil doit rester dépassé. Un cycle dure environ dix secondes. Avec la valeur par défaut de 3, le déséquilibre doit donc persister pendant approximativement trente secondes avant que CRS recherche une migration. Si la charge repasse sous le seuil, le compteur est remis à zéro.
Minimum Imbalance Improvement (%). Une migration n'est exécutée que si elle réduit le déséquilibre d'au moins ce pourcentage relatif. La valeur par défaut est de 10 %. Par exemple, avec un déséquilibre courant de 40 %, une migration simulée qui le ramène à 37 % n'améliore la situation que de 7,5 % : elle est rejetée. Une migration qui le ramène à 35 % apporte 12,5 % d'amélioration et peut être retenue.
Ces paramètres forment une chaîne de décision : dépasser le seuil, rester au-dessus pendant la durée de maintien, trouver le meilleur déplacement autorisé, puis vérifier que son gain dépasse l'amélioration minimale. Ce double filtrage évite qu'un pic temporaire ou un bénéfice marginal déclenche une migration coûteuse.
Pourquoi les migrations sont-elles séquentielles ?
CRS lance les migrations de rééquilibrage l'une après l'autre. Ce choix limite la pression simultanée sur le réseau, le stockage et les nœuds, mais rend le retour à l'équilibre progressif.
Après chaque migration, l'état réel peut différer de la simulation : la charge applicative a évolué, la mémoire a changé ou une autre action HA est survenue. Réévaluer entre deux mouvements est donc plus sûr que d'exécuter en parallèle un plan devenu obsolète.
Dans un cluster très déséquilibré, il faut accepter que le rééquilibrage prenne du temps. CRS privilégie la stabilité opérationnelle à la vitesse d'une redistribution massive.
Les règles HA restent prioritaires
Le load balancer ne peut choisir que les destinations autorisées par les règles HA.
Auto-Rebalance permet de contrôler leur participation aux migrations automatiques.Affinité avec les nœuds
Une règle d'affinité peut préférer certains nœuds ou interdire les autres. Une VM nécessitant un accélérateur, un réseau spécifique ou une génération CPU compatible doit rester sur les hôtes qui répondent à ces contraintes.
Affinité positive entre ressources
Des ressources peuvent être maintenues ensemble. C'est utile lorsque leur proximité réduit une latence critique, mais le groupe devient alors plus difficile à déplacer et peut concentrer la charge.
Affinité négative entre ressources
Des composants redondants peuvent être séparés afin d'éviter qu'une panne de nœud les affecte simultanément : contrôleurs, bases répliquées, frontaux ou nœuds d'un même service.
Exclusion du rééquilibrage
L'option auto-rebalance peut être désactivée pour une ressource HA. Elle reste administrée par la HA, mais le load balancer ne la choisit plus pour ses migrations automatiques. Une ressource en affinité positive avec une ressource exclue est également écartée du rééquilibrage.
Cette option est pertinente pour une VM sensible aux microcoupures, une appliance avec une licence liée au matériel ou une charge dont la migration consomme énormément de bande passante.
Rééquilibrer au démarrage ou en continu
Deux mécanismes proches ne doivent pas être confondus.
L'option ha-rebalance-on-start permet au scheduler d'examiner plus largement le placement lorsqu'une ressource HA démarre. Elle améliore la répartition lors d'un événement de démarrage, mais ne constitue pas à elle seule un équilibrage continu.
Le CRS Load Balancer de Proxmox VE 9.2 surveille quant à lui le déséquilibre au fil du temps et peut déclencher une migration même si aucune ressource n'était en cours de démarrage.
La documentation recommande encore la prudence avec ha-rebalance-on-start en modes static-load et dynamic-load, notamment dans les environnements comprenant des milliers de ressources HA, car le nombre de combinaisons à évaluer augmente rapidement.
CRS face à VMware DRS
La comparaison est utile à condition de ne pas effacer les différences d'architecture et de maturité.
| Fonction | Proxmox CRS avec PVE 9.2 | VMware DRS |
|---|---|---|
| Placement initial | Oui, pour les ressources HA | Oui |
| Charge CPU et mémoire réelle | Oui, mode dynamic-load |
Oui |
| Migrations automatiques | Oui, pour les ressources HA autorisées | Oui, selon le niveau d'automatisation |
| Règles d'affinité et anti-affinité | Oui, via les règles HA | Oui |
| Recommandations sans exécution | Visibilité plus limitée | Mode manuel et recommandations matures |
| Périmètre | HA Manager d'un cluster PVE | Cluster vSphere administré par vCenter |
| Automatisation progressive | Paramètres de seuil et exclusions | Plusieurs niveaux d'automatisation |
| Maturité et profondeur d'écosystème | Fonction récente | Fonction historique et très éprouvée |
| Licence | Inclus dans Proxmox VE open source | Dépend de l'édition et des licences VMware |
DRS possède des années d'optimisation, une présentation détaillée de ses recommandations et une intégration très profonde à l'écosystème vSphere. CRS est plus récent et assume un modèle plus resserré autour de la HA Proxmox.
Pour une stratégie de sortie de VMware, la bonne question n'est donc pas « CRS possède-t-il chaque bouton de DRS ? », mais « couvre-t-il les politiques de placement, d'équilibrage et d'exploitation réellement nécessaires à notre cluster ? ».
CRS ne remplace pas la capacité physique
Un scheduler répartit une charge ; il ne crée ni CPU, ni RAM, ni IOPS.
Si tous les nœuds sont proches de la saturation, déplacer une VM ne résout rien. Pire, la migration peut momentanément augmenter la consommation réseau et stockage. Il faut conserver une réserve suffisante pour absorber la perte d'un nœud et le redémarrage de ses ressources HA.
La capacité doit donc être validée selon le scénario dégradé, pas seulement selon l'état nominal :
- consommation après perte du plus gros nœud ;
- mémoire réellement disponible sans surallocation dangereuse ;
- débit du réseau de migration ;
- latence et capacité du stockage partagé ;
- durée nécessaire pour évacuer ou maintenir un hôte ;
- impact des sauvegardes, réplications et opérations Ceph.
Les prérequis avant activation
Une HA réellement opérationnelle
Le quorum, le watchdog, le fencing, les groupes et les politiques de redémarrage doivent avoir été testés. Activer un scheduler automatique au-dessus d'une HA mal comprise augmente le nombre d'actions possibles sans corriger le socle.
Une compatibilité CPU maîtrisée
La migration en ligne suppose un modèle CPU compatible entre les nœuds. Les générations hétérogènes, les flags exposés avec host et certaines appliances demandent une validation spécifique.
Un réseau de migration dimensionné
Une VM très active en mémoire peut transférer plusieurs fois les pages modifiées avant la bascule finale. Un réseau saturé allonge la migration et augmente le temps d'indisponibilité résiduel.
Un stockage accessible à la destination
Avec un stockage partagé, le disque reste accessible et la migration concerne surtout l'état mémoire. Avec des disques locaux, le transfert devient plus lourd et n'est pas équivalent à un simple mouvement de calcul.
Des métriques cohérentes
Le mode dynamique décide à partir des mesures disponibles. NTP, supervision et collecte doivent être fiables. Les résultats doivent être comparés avec les métriques applicatives et stockage, car CRS n'interprète pas la criticité métier d'une transaction.
Ce que CRS ne sait pas deviner
CRS ne connaît pas :
- la fenêtre métier pendant laquelle une microcoupure est inacceptable ;
- la dépendance d'une application à un équipement externe ;
- la fin imminente d'un traitement batch ;
- la vraie priorité d'un client ou d'un service ;
- la saturation future d'un datastore ;
- la conformité d'une licence après déplacement ;
- le coût organisationnel d'une migration automatique.
Ces informations doivent être traduites en règles HA, exclusions, fenêtres d'exploitation, alertes ou procédures. L'intelligence du scheduler dépend directement de la qualité du modèle fourni par l'administrateur.
Une méthode de déploiement en huit étapes
- Mettre à jour un cluster de test vers Proxmox VE 9.2 et vérifier la santé HA.
- Inventorier les ressources éligibles, leurs dépendances et leurs contraintes CPU, réseau et stockage.
- Formaliser les affinités, anti-affinités et nœuds autorisés.
- Commencer avec
static-loadpour observer les choix du scheduler. - Activer
dynamic-loadsur un périmètre non critique. - Exclure avec
auto-rebalanceles workloads qui ne doivent pas migrer automatiquement. - Configurer des seuils conservateurs et observer un cycle de charge complet.
- Tester la perte d'un nœud, la maintenance, le retour à l'équilibre et le rollback.
Les indicateurs utiles sont le nombre de migrations, leur durée, le gain d'équilibre, l'utilisation CPU et mémoire avant et après, la consommation réseau, la latence stockage et les interruptions applicatives observées.
CRS et Proxmox Datacenter Manager ne jouent pas le même rôle
CRS agit à l'intérieur d'un cluster Proxmox VE. Il choisit un nœud et rééquilibre les ressources HA de ce cluster.
Proxmox Datacenter Manager apporte une vue et des opérations au-dessus de plusieurs clusters indépendants. PDM peut faciliter une migration inter-clusters, mais il ne transforme pas plusieurs clusters en un domaine CRS unique.
On peut résumer l'architecture ainsi :
- CRS décide où exécuter une ressource dans son cluster ;
- HA Manager garantit son état et orchestre les actions locales ;
- PDM centralise la visibilité et certaines opérations entre plusieurs environnements.
Faut-il activer CRS en production maintenant ?
Oui, si l'organisation dispose déjà d'un cluster HA sain, d'une architecture homogène et d'une vraie méthode de test. Le mode dynamique et le load balancer répondent à un manque important de Proxmox VE dans les infrastructures à forte densité.
Non, si l'objectif est de masquer une saturation, une HA non testée ou un réseau de migration insuffisant. L'automatisation accélère les bonnes décisions comme les mauvaises configurations.
Le meilleur point de départ n'est pas l'activation globale. C'est un périmètre de VM non critiques, des seuils prudents et l'observation des décisions pendant plusieurs cycles de charge.
Point de vue
Le Dynamic Load Balancer de Proxmox VE 9.2 est une évolution majeure. Avec la charge réelle, les règles d'affinité, les exclusions et les migrations automatiques, CRS dépasse désormais le simple choix d'un nœud au redémarrage.
Ce n'est pas encore un clone fonctionnel de VMware DRS, et ce n'est pas nécessairement le bon objectif. CRS s'intègre à une architecture Proxmox où la HA reste le cadre de décision et où l'administrateur conserve un contrôle explicite sur les ressources automatisées.
Pour les entreprises qui évaluent une sortie de VMware, CRS ferme néanmoins une partie importante de l'écart opérationnel. La question du placement dynamique ne peut plus être écartée par un simple « Proxmox n'a pas de DRS ». Il existe désormais une réponse native, crédible et testable — à condition de la traiter comme un composant d'infrastructure critique, pas comme une case à cocher.