Proxmox VE ha incorporado una de esas mejoras que no hacen mucho ruido fuera del mundo de la virtualización, pero que cambian bastante la operación diaria de un clúster. La actualización de pve-manager 9.1.8 junto a pve-ha-manager 5.2.0 introduce un nuevo modo de planificación llamado Dynamic Load y una opción de rebalanceo automático para recursos gestionados por HA. No es un clon de VMware DRS, pero sí cubre una carencia muy concreta: evitar que un clúster quede descompensado después de un fallo o tras añadir capacidad nueva.
Hasta ahora, el comportamiento de alta disponibilidad en Proxmox era eficaz pero bastante directo. Si un nodo caía, HA reiniciaba las máquinas virtuales o contenedores afectados en los nodos supervivientes. El problema llegaba después. Cuando el nodo volvía al clúster, las cargas no regresaban ni se redistribuían por sí solas. El administrador tenía que moverlas manualmente, tirar de scripts o aceptar que un nodo quedara descargado mientras otros seguían soportando más trabajo del necesario.
Qué aporta Dynamic Load al HA de Proxmox
La novedad está en el planificador de recursos del clúster, dentro de las opciones de Datacenter. Proxmox añade una capa más inteligente para decidir dónde colocar cargas HA y, si se activa el rebalanceo automático, cuándo moverlas para mejorar la distribución del clúster.
La mejora no convierte Proxmox en una plataforma con DRS completo al estilo VMware. Es más preciso hablar de HA con balanceo de carga. El sistema observa el uso de CPU y memoria, compara el estado de los nodos y decide si una migración mejora el equilibrio del conjunto. No intenta predecir la carga futura ni modelar escenarios complejos a largo plazo. Trabaja con la situación actual y con los límites configurados por el administrador.
La diferencia importa. VMware DRS lleva años actuando como un optimizador continuo, con políticas de reservas, límites, afinidad, automatización y recomendaciones en entornos que pueden escalar a miles de máquinas virtuales. Proxmox adopta un enfoque más sencillo y más fácil de entender. Para muchos clústeres de tres, cinco o siete nodos, esa sencillez no es una limitación grave. Es justo lo que se necesitaba: que el sistema deje de depender de una persona para volver a repartir cargas razonablemente.
| Modo de planificación | Qué hace |
|---|---|
| Default | Mantiene el comportamiento histórico, sin tener en cuenta la carga del nodo |
| Basic | Distribuye recursos según el número de cargas HA por nodo |
| Static-Load | Usa cuotas máximas configuradas de CPU y memoria para decidir ubicación |
| Dynamic-Load | Usa métricas reales de CPU y memoria observadas en los nodos |
| Automatic Rebalance | Permite mover cargas HA existentes si mejora el equilibrio del clúster |
En la práctica, el caso más claro es una caída de nodo. Antes, el clúster se recuperaba, pero quedaba desordenado. Ahora, si se usa el planificador adecuado y se activa el rebalanceo, Proxmox puede mover cargas de vuelta o repartirlas entre nodos cuando el cálculo indique que la migración mejora el estado general.
También resulta útil al ampliar un clúster. Si se añade un nuevo nodo, ya no es necesario esperar a que futuras cargas lo utilicen o mover máquinas a mano. El sistema puede empezar a aprovecharlo para recursos HA y migrar workloads existentes si la distribución mejora.
Cómo evita convertirse en una tormenta de migraciones
El gran miedo de cualquier sistema de rebalanceo automático es que empiece a mover máquinas sin descanso. Una pequeña variación de carga, una migración, otro nodo que se calienta, otra migración más. En virtualización, automatizar mal puede ser peor que no automatizar.
Proxmox intenta evitarlo con varios controles. El imbalance threshold define cuánto desequilibrio debe haber antes de que el planificador considere actuar. El minimum imbalance improvement marca cuánto debe mejorar el clúster para justificar una migración. El hold duration introduce un intervalo mínimo para que una misma carga no sea movida repetidamente en poco tiempo.
Este diseño es sensato porque permite ajustar la agresividad. En un clúster pequeño, con pocas cargas críticas, puede interesar un comportamiento algo más reactivo. En un entorno con muchas máquinas, almacenamiento compartido sensible o Ceph, quizá sea mejor un perfil conservador para no generar ruido operativo, tráfico de red innecesario o migraciones en momentos poco adecuados.
La función también respeta reglas de afinidad. Si dos recursos tienen afinidad positiva y deben ejecutarse juntos, el balanceador los trata como una unidad a efectos de cálculo y migración. Si existen reglas negativas para mantener cargas separadas, el planificador las respeta al decidir ubicación. Este punto es importante porque muchas arquitecturas HA dependen de separar componentes redundantes, controladores, bases de datos o servicios que no deben convivir en el mismo nodo.
Hay además una mejora en camino que apunta a un control más fino: la propiedad auto-rebalance por recurso HA. La idea, ya trabajada en los parches de Proxmox, es permitir que un administrador marque qué recursos pueden o no ser candidatos a migración automática durante el rebalanceo. Por defecto, el valor se plantea como activado, pero deshabilitarlo para una VM concreta impediría que esa VM fuera movida por el rebalanceador automático.
Por qué importa para migraciones desde VMware
La ausencia de DRS ha sido uno de los argumentos recurrentes contra Proxmox en conversaciones de migración desde VMware. No siempre era un argumento decisivo, pero sí aparecía a menudo. Para grandes entornos con miles de máquinas y políticas avanzadas de capacidad, DRS sigue teniendo más recorrido. Para clústeres medianos, departamentales, de servicios gestionados o de cloud privado, lo que se necesitaba era algo más básico: que Proxmox entendiera la carga real y pudiera reequilibrar sin intervención manual constante.
Ahí esta actualización cambia la conversación. Ya no es exacto decir que Proxmox no tiene ningún mecanismo de balanceo automático para HA. Lo tiene, aunque con un alcance más limitado que DRS. La pregunta correcta pasa a ser otra: ¿necesita la organización un optimizador predictivo complejo o le basta con colocación sensible a carga y rebalanceo automático de recursos HA?
Para muchos escenarios, la segunda opción será suficiente. Un clúster Proxmox con HA, Ceph o almacenamiento compartido, backups integrados, soporte de Veeam y ahora rebalanceo de cargas cubre cada vez más casos de uso que antes quedaban más cómodos en vSphere por madurez operativa. No elimina la necesidad de diseñar bien, dimensionar correctamente y probar escenarios de fallo, pero reduce trabajo manual en el día a día.
También encaja con la filosofía de Proxmox: añadir capacidades útiles sin construir una capa excesivamente opaca. Un administrador puede entender por qué se movió una carga: había un desequilibrio, la mejora superaba el mínimo configurado y el recurso no estaba bloqueado por reglas o condiciones. Esa trazabilidad operativa tiene valor, sobre todo en equipos pequeños que no quieren pelearse con un “cerebro” de planificación difícil de explicar.
Qué no debe esperarse de esta función
El nuevo rebalanceo no sustituye a una buena arquitectura. Si un clúster está mal dimensionado, si hay VMs sobredimensionadas, si el almacenamiento es el cuello de botella o si la red de migración no está preparada, el planificador no hará magia. Moverá cargas entre nodos, pero no corregirá una compra mal planteada ni un diseño sin margen de crecimiento.
Tampoco es una herramienta de capacity planning. No predice si dentro de seis meses faltará RAM, CPU o IOPS. Para eso siguen haciendo falta métricas históricas, observabilidad, planificación y revisión periódica. El rebalanceo trabaja sobre el presente, no sobre un modelo de demanda futura.
Otro límite es que se aplica dentro de cada clúster. Proxmox Datacenter Manager puede aportar visibilidad y gestión entre clústeres, pero esta función no convierte varios clústeres en un único pool global capaz de rebalancear cargas entre sitios. Para la mayoría de organizaciones medianas no será un problema, aunque sí lo será para entornos distribuidos más complejos.
También conviene revisar versiones antes de activar nada. En algunos repositorios, la interfaz de pve-manager mostró opciones antes de que todos los componentes necesarios estuvieran disponibles en la misma rama. La función depende de versiones compatibles de pve-ha-manager y otros paquetes del clúster, así que lo prudente es verificar con pveversion -v, leer notas de actualización y probar en un entorno controlado.
Para producción, la recomendación razonable es no activarlo un viernes por la tarde. Primero conviene hacer una prueba con cargas representativas, simular caída y recuperación de nodo, observar cómo se comportan las migraciones, ajustar umbrales y validar el impacto sobre red, almacenamiento y servicios. Las migraciones son reales y pueden afectar a aplicaciones sensibles, aunque el sistema esté diseñado para ser conservador.
La actualización confirma una tendencia: Proxmox avanza rápido en madurez empresarial. No copiando pieza por pieza el modelo de VMware, sino cerrando huecos prácticos que dificultaban su adopción en producción. El rebalanceo HA automático no es la última palabra en planificación de recursos, pero sí una mejora importante para quienes quieren operar clústeres Proxmox con menos intervención manual y más confianza tras fallos, ampliaciones o cambios de carga.
Preguntas frecuentes
¿Proxmox ya tiene DRS como VMware?
No exactamente. Proxmox incorpora rebalanceo HA automático y planificación basada en carga, pero no un DRS predictivo completo como el de VMware. Para muchos clústeres medianos, aun así, puede resolver el problema operativo más habitual.
¿Qué es Dynamic Load en Proxmox?
Dynamic Load es un modo de planificación que usa métricas reales de CPU y memoria para decidir ubicación y rebalanceo de recursos HA dentro del clúster.
¿El rebalanceo mueve todas las máquinas virtuales?
No. Se aplica a recursos gestionados por HA y respeta reglas de afinidad. Además, Proxmox está trabajando en una opción auto-rebalance para controlar qué recursos pueden ser movidos automáticamente.
¿Conviene activarlo directamente en producción?
Lo prudente es probarlo antes en un entorno representativo. Hay que validar umbrales, impacto de migraciones, comportamiento con almacenamiento y reglas de afinidad antes de dejar que actúe sobre cargas críticas.
