Bonjours les gens, un petit article concernant la fameuse option « Dynamic Load » de Proxmox et le dynamic resource scheduling qu’on attends depuis longtemps, car j’entends et je lit pas mal de choses un peu contradictoires en ce moment !
Le HA dans Proxmox : une histoire de résilience aux pannes, pas d’équilibrage de charge
Depuis ses premières versions stables en environnement de production, Proxmox VE intègre un mécanisme de HA reposant sur un cluster Corosync (le composant de proxmox chargé de ça). Le principe est simple et robuste : dès lors qu’un nœud du cluster tombe (quelle que soit la raison), les machines virtuelles ou conteneurs LXC marqués comme tel (oui il faut déclarer les VM ou conteneurs comme étant couvert par la fonction HA, faisez gaffe à ne pa oublier !) sont automatiquement redémarrés sur un des host restant up. Le gestionnaire HA s’appuie sur un système de quorum (d’où l’importance du nombre impair de noeuds), et sur des agents qui surveillent en permanence l’état des ressources et des hyperviseurs.
Ce qu’il faut bien comprendre ici, c’est que le HA de Proxmox n’a historiquement qu’une seule ambition : la tolérance aux pannes. Il ne se soucie pas de savoir si un nœud est chargé à 90 % de CPU pendant que son voisin tourne à 15 %. Son travail, c’est de faire en sorte que vos VMs redémarrent quelque part quand ça casse, point. Le placement initial reste manuel et à la discrétion des admins, et une fois les VMs en route, elles ne bougent plus sauf catastrophe, évidemment 🙂 .
« Dynamic Load » : quand le HA commence (enfin) à regarder la charge
Avec l’option « Dynamic Load » introduite dans la 9.1.8 d’avril dernier, Proxmox fait un premier pas vers quelque chose de plus intelligent. Concrètement, l’algorithme de sélection du noeud qui cible d’une VM lors d’une bascule HA s’appuie désormais sur des métriques de charge en temps réel des nœuds disponibles (CPU et mémoire) pour orienter son choix. Jusqu’ici, la sélection du nœud de destination était relativement simple, voire naïve : le gestionnaire HA choisissait parmi les hosts éligibles selon des priorités statiques configurées à la main, sans vraiment se soucier de leur charge à l’instant T.
Avec Dynamic Load activé, le scheduler HA va désormais favoriser le host le moins chargé au moment de la décision de placement, ce qui évite de surcharger bêtement un nœud déjà sous pression pendant qu’un autre tourne à vide. C’est d’autant plus utilise sur les « petits » clusters où les déséquilibres de charge sont fréquents et où on ne souhaitait pas intégrer des outils tiers comme ProxLB et plus récemment PegaProx ou Proxcenter pour faire le boulot de ré-équilibrage.
Alors, « Dynamic Load » ayé, c’est du DRS like ?
En réalité, pas vraiment : Le DRS de vSphere, c’est un moteur d’optimisation continu et proactif (notamment à partir de vSphere 8 avec le Proactive DRS) : il surveille en permanence la charge de l’ensemble du cluster, calcule des scores de déséquilibre, et migre à chaud des VMs avec vMotion pour rééquilibrer la charge globale sans attendre qu’une panne survienne. Il peut aussi piloter la mise en veille de nœuds sous-utilisés pour optimiser la consommation énergétique (avec DPM).
Dynamic Load n’intervient qu’au moment d’un événement de placement (une bascule HA ou un démarrage de VM) et ne déclenche aucune migration à chaud proactive pour rééquilibrer l’ensemble du cluster qui dérive progressivement vers un déséquilibre. Si vos VMs tournent depuis des heures et que la charge s’est déséquilibrée progressivement, Proxmox ne fera rien pour corriger ça. Pour ça, il faudra toujours s’appuyer sur des solutions complémentaires. Dynamic Load est donc une amélioration sérieuse du comportement HA de Proxmox, mais elle reste réactive et événementielle, là où un vrai DRS est proactif et continu.
Dont acte, c’est un pas dans la bonne direction !
Références :
– Un article qui dit quasi la même chose et dont je me suis inspiré pour construire mon propre post : https://www.virtualizationhowto.com/2026/04/proxmox-9-1-8-finally-rebalances-ha-workloads-automatically/
