ProxLB, projet open source développé pour distribuer et rééquilibrer les machines virtuelles et les conteneurs entre les nœuds d’un cluster Proxmox VE, a publié sa version 2.3.0. Cette mise à jour intègre de nouvelles options pour exclure certains charges, modifie le comportement de son solveur CP-SAT et corrige des problèmes liés à l’utilisation de balises pour attribuer des machines virtuelles à des nœuds spécifiques.

Les principales nouveautés de ProxLB 2.3 en 30 secondes

• ProxLB 2.3.0 a été publié le 31 août 2026 comme une mise à jour axée sur de petits ajustements et corrections.
• Permet d’exclure des machines virtuelles et des conteneurs par nom via ignore_guests.
• Ajoute un contrôle sur le comportement du solveur CP-SAT lorsqu’aucune solution viable n’est trouvée.
• Corrige des problèmes de node pinning causés par la conversion en minuscules des balises dans Proxmox.
• ProxLB continue d’offrir un planificateur externe et configurable pour les clusters Proxmox VE.

Cette mise à jour ne modifie pas la philosophie du projet, mais arrive à un moment intéressant pour les administrateurs de Proxmox. Le propre hyperviseur a progressé dans ses capacités natives de distribution dynamique de charges, tandis que des outils externes comme ProxLB cherchent à couvrir des scénarios nécessitant des politiques de placement plus spécifiques.

Développé sous l’égide de credativ, ProxLB se définit comme un planificateur de ressources et un répartiteur avancé pour les clusters Proxmox. Il peut analyser le CPU, la mémoire et le stockage local pour décider comment répartir les charges et supporte les machines virtuelles ainsi que les conteneurs. Il prend également en compte l’affinité, l’antiaffinité, le placement sur des nœuds spécifiques et les opérations de maintenance.

Son fonctionnement s’appuie sur l’API de Proxmox, évitant l’utilisation de SSH pour son opération. Il peut s’exécuter en task ponctuel, en service en arrière-plan ou s’intégrer partiellement à l’interface web de Proxmox.

Ce qui change avec ProxLB 2.3.0

L’une des nouveautés les plus pratiques est l’ajout de l’option ignore_guests. Jusqu’ici, ProxLB permettait déjà d’exclure des charges via des balises, mais cette nouvelle version permet de désigner directement par nom précise quelles machines virtuelles ou conteneurs doivent être ignorés.

Cela peut paraître anodin, mais dans des clusters avec beaucoup de charges, certains systèmes peuvent nécessiter que certaines machines soient exclues de toute politique automatique de migration. Cela peut être requis par des raisons liées aux applications, des dépendances hardware, des licences ou simplement parce qu’une machine spécifique requiert un traitement manuel.

Une autre nouveauté concerne le solveur CP-SAT, optionnellement basé sur Google OR-Tools.

ProxLB utilise ce mécanisme pour calculer l’affectation des machines entre nœuds via un modèle d’optimisation. Le solveur peut fonctionner en mode shadow, où il propose une planification sans modifier les migrations effectuées par ProxLB, ou en mode actif, où il orchestre directement ces migrations.

La version 2.3.0 introduit solver.fallback_to_greedy, une option liée au comportement du système lorsque le solveur CP-SAT ne parvient pas à trouver un plan viable en mode actif.

Elle permet de définir si ProxLB doit recourir à l’algorithme de répartition glouton (greedy) dans cette situation.

De plus, le traitement interne des ensembles de données RRD (Round Robin Database) a été modifié : la paire de valeurs représentant des moyennes et maxima a été remplacée par un conteneur générique nommé RrdDatasets.

Une petite correction impactant le node pinning

Parmi les corrections de ProxLB 2.3.0, une en particulier est intéressante car elle trouve son origine dans le traitement des balises dans Proxmox VE.

ProxLB permet de fixer une machine virtuelle ou un conteneur à certains nœuds du cluster via des balises. Par exemple, une charge peut être associée à un nœud particulier via une balise spécifique.

Cela est utile notamment lorsque des licences ou du hardware spécifique imposent cette restriction, ou lorsqu’un nœud dispose d’un matériel unique dans le cluster.

Le problème réside dans le fait que l’API de Proxmox convertit ces balises en minuscules, ce qui peut fausser la comparaison avec les noms de nœuds qui gardent leur casse. ProxLB pouvait alors ne pas faire correspondre correctement ces associations.

La version 2.3.0 corrige ce comportement en normalisant les noms lors de la comparaison et en renvoyant le nom original du nœud lors de l’établissement de la relation entre charges et serveurs.

C’est un bon exemple de ces erreurs diluées dans le temps, où le problème ne vient pas de la politique de placement elle-même, mais de la manière dont deux composants interprètent une même chaîne de texte.

ProxLB face au balancement natif de Proxmox

L’utilité de ProxLB a évolué avec Proxmox VE.

Le projet reconnaît aujourd’hui l’existence du Dynamic Load Balancing (DLB) introduit en Proxmox VE 9.2, qui offre une solution intégrée pour rééquilibrer automatiquement les charges gérées par High Availability (HA) entre les nœuds du cluster.

Cela signifie que ProxLB ne couvre plus exactement le même spectre qu’auparavant, quand Proxmox ne disposait pas d’un mécanisme natif équivalent.

La différence principale réside dans la portée.

Le DLB de Proxmox s’intègre directement dans son infrastructure HA et son planificateur de ressources. En revanche, ProxLB fonctionne comme une couche externe, offrant davantage d’options de personnalisation et pouvant agir également sur des charges hors du système HA.

De plus, ProxLB prend en compte le CPU, la mémoire, le stockage local, les ressources allouées, le surprovisionnement, et les métriques PSI (Pressure Stall Information), avec des politiques d’affinité, d’antiaffinité et de fixation spécifique à certains nœuds.

Le projet est également capable de déterminer le meilleur nœud pour héberger une nouvelle machine, une fonction utile pour l’automatisation ultérieure.

Cela ne signifie pas que ProxLB soit automatiquement préféré au répartiteur intégré de Proxmox. Une solution native simplifie la maintenance en réduisant le nombre de composants externes. ProxLB reste pertinent lorsque les politiques requises dépassent les capacités du mécanisme intégré ou lorsqu’on utilise des versions plus anciennes de Proxmox VE.

Il faut en revanche faire attention : la documentation actuelle du projet alerte sur de possibles conflits lorsqu’on combine certains groupes HA de Proxmox avec la logique de placement spécifique de ProxLB. Il est conseillé de vérifier cette interaction avant de déployer les deux mécanismes conjointement.

Automatiser aussi la maintenance du cluster

Le rééquilibrage n’est pas la seule fonction proposée.

ProxLB possède un mode de maintenance qui permet de marquer des nœuds pour qu’ils arrêtent de recevoir de nouvelles charges, en déplaçant les charges existantes vers d’autres nœuds. Le système tient compte des ressources disponibles, ainsi que des règles d’affinité ou d’antiaffinité, avant d’effectuer les migrations.

Il peut aussi être programmé pour intervenir à des créneaux horaires définis.

Pour des gestionnaires avec plusieurs nœuds, cela permet d’automatiser une partie du processus en vue de redémarrages, de mises à jour ou d’interventions hardware.

ProxLB 2.3.0 peut être installé via le dépôt Debian du projet, en utilisant des paquets .deb ou des images de conteneur. Le logiciel reste open source, avec tout son code, sa documentation, ses rapports d’incidents et son développement accessibles au public.

L’arrivée du balancement dynamique natif dans Proxmox VE 9.2 ne supprime pas forcément l’intérêt d’outils comme ProxLB. Elle crée plutôt deux niveaux distincts : une option intégrée pour les scénarios standards, et des outils externes offrant un contrôle accru pour qui souhaite gérer précisément où, quand et comment chaque charge est déplacée dans le cluster.

Questions fréquentes

Qu’est-ce que ProxLB pour Proxmox ?

ProxLB est un planificateur et répartiteur de charges open source pour les clusters Proxmox VE. Il analyse les ressources disponibles et peut redistribuer machines virtuelles et conteneurs entre différents nœuds.

Quelles nouveautés comporte ProxLB 2.3.0 ?

La version introduit l’exclusion des charges par nom via ignore_guests, un contrôle pour le fallback du solveur CP-SAT, et diverses corrections, notamment concernant la gestion de la casse dans les balises de fixation à des nœuds.

ProxLB reste-t-il utile avec le balancement dynamique de Proxmox VE 9.2 ?

Cela dépend du contexte. Le DLB offre une intégration native avec la gestion HA, tandis que ProxLB permet des options de personnalisation supplémentaires et peut gérer des charges hors du système HA.

Faut-il installer ProxLB sur tous les nœuds de Proxmox ?

Pas nécessairement. ProxLB fonctionne via l’API de Proxmox et peut s’exécuter à partir d’un seul système ayant accès à cette API. Il est possible de l’installer via des paquets Debian, des conteneurs, ou directement depuis le code source.