El cluster elige nodo contando invitados: anti-afinidad en Proxmox VE 9 y la regla que nadie declara

Se cae un nodo de madrugada. El resto del cluster mantiene el quórum, el vigilante hace su trabajo y al rato las máquinas del nodo muerto —las que estaban dadas de alta como recursos de HA, las demás siguen apagadas— están arrancando en otro sitio. Todo ha funcionado. La pregunta que casi nadie se hace es quién eligió ese otro sitio y con qué criterio. En un Proxmox VE recién instalado la respuesta está escrita en la documentación oficial y es mucho más simple de lo que la gente supone: el planificador mira el número de invitados activos que tiene cada nodo y elige el que menos tiene. Cuenta. No sabe que la 101 es la segunda pata de la 100.

Quién decide dónde arranca tu máquina

La pieza se llama Cluster Resource Scheduler, CRS. En cada ronda del gestor de HA —unos diez segundos— repasa los recursos y decide si alguno necesita una colocación nueva. Tiene tres modos y el que viene de fábrica es basic: cuenta invitados activos por nodo. Los otros dos sí miran CPU y memoria: static-load usa las cuotas configuradas de los invitados activos, y dynamic-load añade a esas cuotas el uso medio real de CPU y memoria. Ninguno de los tres viene con una lista de qué máquinas son parejas.

La documentación llama puntos de planificación a los momentos en que el CRS entra en acción, y marca dos de ellos como siempre activos: la recuperación de recursos cuando cae un nodo, y los cambios en la configuración de reglas. Eso quiere decir que la colocación no es opcional. Aunque no hayas tocado nada, el día del incidente alguien decide en qué hierro arranca cada cosa. La única pregunta abierta es si esa decisión tiene en cuenta lo que tú sabes de tu propia arquitectura.

Lo que cambió en 9.0 y llegó a tu cluster solo

Durante años, lo único que se podía expresar en Proxmox eran los grupos de HA: esta máquina, en estos nodos, con estas prioridades. Servía para decir dónde sí, y no servía para decir con quién no. Proxmox VE 9.0 sustituyó ese mecanismo por las reglas de HA, que son dos familias distintas: las de afinidad de nodo, que atan recursos a nodos, y las de afinidad de recurso, que atan recursos entre sí. Y hay algo que despista: las dos familias admiten el modificador --affinity negative, pero significa cosas distintas en cada una. En una regla de nodo, negativa quiere decir «en cualquier nodo menos estos», que es una forma cómoda de excluir sin listar el cluster entero. En una regla de recurso, negativa quiere decir «estos dos, nunca en el mismo nodo». Cuando aquí se hable de anti-afinidad sin apellido, es la segunda.

El detalle que conviene no pasar por alto es que esto no espera a que tú lo decidas. Las notas de la versión son explícitas: los grupos quedan obsoletos y los existentes se migran automáticamente a reglas de afinidad de nodo en cuanto todos los nodos del cluster corren Proxmox VE 9. La opción nofailback de los grupos desaparece y se sustituye por failback, que ahora se configura por recurso. Si actualizaste el cluster y no volviste a mirar, tienes reglas nuevas escritas por el propio sistema y una opción que cambió de sitio y de signo.

Una preferencia y una orden

Aquí está la asimetría que, en nuestra experiencia, más gente descubre tarde. Las dos familias de reglas tienen valores por defecto opuestos.

La consecuencia práctica es que mucha gente tiene lo contrario de lo que cree tener. La regla que restringe una máquina a un nodo concreto, si no la marcas estricta, no restringe nada el día que ese nodo falta. Y la regla que separa dos máquinas manda incluso cuando la alternativa es que una de ellas no arranque. Se declaran así:

# separar dos recursos: nunca en el mismo nodo
ha-manager rules add resource-affinity keep-separate \
    --affinity negative --resources vm:200,ct:300

# fijar un recurso a un nodo... y hacerlo de verdad
ha-manager rules add node-affinity ha-rule-vm100 --resources vm:100 --nodes node1
ha-manager rules set node-affinity ha-rule-vm100 --strict 1

# ver qué reglas hay, y cuáles afectan a un recurso
ha-manager rules list
ha-manager rules config --resource vm:100

La aritmética de una regla negativa

Una regla que separa n recursos necesita n nodos donde ponerlos, y eso está escrito como prueba de viabilidad, no como consejo: «una regla de afinidad de recurso negativa no puede especificar más recursos de HA que nodos hay en el cluster. Si no, los recursos no tienen nodos suficientes para ser separados». Una regla que no pasa esa prueba se queda deshabilitada, que es la primera forma de perder una garantía sin enterarse. Y para las que sí pasan, la documentación dice qué ocurre cuando la cuenta se estropea sobre la marcha: si la restricción no se puede satisfacer, el gestor de HA deja el recurso en estado recovery cuando se trata de un failover, y en estado error en cualquier otro caso.

Hagamos la cuenta con el cluster más común que nos encontramos: tres nodos. Si pones una regla negativa entre tres recursos —pongamos las tres instancias de una aplicación repartida—, en marcha normal encajan justo: uno por nodo, sin margen. El día que se cae un nodo quedan dos sitios para tres cosas que no pueden compartir sitio, y una de las tres no vuelve. El planificador no se ha equivocado; ha hecho exactamente lo que la regla dice. Con dos recursos en la regla, en cambio, sobra un nodo y la recuperación es limpia.

Lectura nuestra, no de la documentación: eso no lo llamaríamos un defecto. Es una decisión de diseño que estabas tomando sin saberlo. Hay servicios donde arrancar dos réplicas en el mismo hierro es peor que tener una parada, porque el segundo nodo da una falsa sensación de cobertura que se evapora en el siguiente reinicio. Y hay servicios donde encendido y degradado es infinitamente mejor que apagado y correcto. Esa elección es tuya y solo se toma bien con calma, un martes. Nunca a las tres de la madrugada.

Y hay una cuenta que va antes que esta, aunque a mucha gente le llegue después: el capítulo de alta disponibilidad describe reglas, prioridades y vallado, pero no describe ningún mecanismo que reserve capacidad para el failover. Nadie te impide llenar los tres nodos hasta arriba de memoria. El día que falte uno, o la RAM que queda da para arrancarlo todo o no da, y esa resta la haces tú antes o no la hace nadie. Es una de las cosas que ya poníamos sobre la mesa al escribir cuándo NO migrar de VMware a Proxmox, y sigue siendo la diferencia más honesta que hay entre las dos plataformas en este terreno.

Es la misma idea que contábamos al hablar de por qué la redundancia no sobrevive al procedimiento, solo que al revés: allí la pareja redundante la deshacía una persona siguiendo un manual, y aquí la deshace un planificador haciendo su trabajo. Y es prima hermana de la distinción entre redundancia y diversidad de ruta: dos cosas duplicadas solo son dos si no comparten el punto que puede fallar. En un cluster ese punto es el nodo, y decir cuál no se comparte es un fichero de texto.

Lo que la regla arrastra sin que se lo pidas

Las reglas se combinan entre ellas, y ahí es donde el alcance crece por su cuenta. Tres comportamientos que están en la documentación y que casi nunca se tienen en la cabeza al escribir la primera regla:

• Dos reglas positivas que compartan un recurso se funden en una sola. Si 100 y 101 van juntas, y 101 y 102 también, entonces las tres van juntas. Nadie escribió esa tercera relación.
• Un grupo unido por afinidad positiva hereda las restricciones de cualquiera de sus miembros. Si 102 está atada al nodo 3 por una regla de nodo, 100 y 101 quedan atadas al nodo 3 también. Y si uno del grupo tiene una afinidad negativa con otro recurso, la tienen todos.
• Las reglas se someten a pruebas de viabilidad antes de aplicarse, y las que no las pasan quedan deshabilitadas hasta que resuelvas el conflicto. Entre las pruebas: un recurso solo puede estar en una regla de afinidad de nodo; una regla negativa de nodo no puede llevar prioridades ni listar todos los nodos del cluster; una regla de afinidad de recurso necesita al menos dos recursos. Dos recursos que estén a la vez en una regla positiva y en una negativa son un conflicto puro, y las dos reglas se desactivan.

Ese último punto es el que nos parece más peligroso en la práctica, y no por su complejidad sino por su silencio. Una regla deshabilitada no protesta cada mañana. Está en la interfaz, con su nombre, y no hace nada. Quien la escribió cree que el cluster tiene una garantía que el cluster no tiene, y se enterará el día del failover. Por eso el primer comando de la lista de más abajo no es escribir una regla: es leer las que ya hay.

Desde 9.2 el cluster también mueve por su cuenta

Todo lo anterior importaba ya, pero importaba sobre todo el día del incidente. Proxmox VE 9.2, publicado el 21 de mayo de 2026, añadió el balanceador de carga automático del CRS: el cluster mide su propio desequilibrio y, si se pasa de la raya durante suficientes rondas seguidas, emite migraciones para corregirlo. Solo mueve recursos gestionados por HA, las migraciones van de una en una, y el umbral de desequilibrio viene de fábrica en el 30 %. No está encendido por defecto —requiere el modo static-load o dynamic-load— pero el día que alguien lo encienda, la colocación deja de ser una foto fija del día que montaste el cluster y pasa a ser una decisión continua.

La documentación deja claro que esas migraciones obedecen siempre a las reglas de afinidad vigentes. Es la frase tranquilizadora del capítulo, y es cierta. También es exactamente el problema: obedecer las reglas solo te protege si las reglas existen. Un balanceador que no sabe que la 100 y la 101 son la misma cosa dos veces hará lo único que le has pedido, que es repartir carga, y repartir carga puede significar juntarlas. Hay dos matices más que conviene apuntar: el rebalanceo automático se puede desactivar recurso a recurso, y si un recurso tiene afinidad positiva con otro que lo lleva desactivado, tampoco se mueve ninguno de los dos.

Cinco minutos delante del cluster

Esto es lo que miramos nosotros cuando nos sentamos delante de un Proxmox VE 9 que ya está en producción. No hace falta ventana de mantenimiento para ninguno de los cinco puntos.

1. Leer antes de escribir. ha-manager rules list y buscar dos cosas: reglas que no esperabas —las que migró sola la 9.0— y reglas deshabilitadas por conflicto. Lo segundo es una garantía que alguien cree tener.
2. Escribir la lista de parejas. En papel, antes de tocar nada: los dos controladores de dominio, la base de datos y su réplica, los dos nodos del balanceador, el par de servidores de la aplicación. Casi siempre son menos de las que uno cree, y casi nunca están escritas en ningún sitio.
3. Hacer la cuenta antes de crear la regla. Recursos en la regla negativa frente a nodos capaces de ejecutarlos, menos uno, que es el que puede caerse. Si la resta no da, no crees la regla todavía: primero decide qué prefieres que pase.
4. Revisar el failback por recurso. Es la opción que sustituyó al nofailback de los grupos viejos. Decide si una máquina vuelve sola a su nodo preferido cuando ese nodo reaparece, que es una segunda ventana de riesgo justo después de la primera.
5. Reglas primero, balanceador después. Si vas a activar el balanceo automático de 9.2, el orden importa: declara las parejas, comprueba que ninguna regla quedó deshabilitada y solo entonces enciende el modo dinámico. Al revés, le estás dando permiso para mover cosas cuyas relaciones aún no conoce.

Cuándo no poner la regla

Si tu cluster son dos nodos, la regla sigue comprando algo, pero conviene saber exactamente qué. Te separa las dos máquinas mientras los dos nodos estén vivos, y eso no es poco: el planificador reparte contando invitados en total, así que si uno de los dos tiene más invitados puede juntarlas sin problema. Lo que no te compra es nada para el día del incidente, porque en cuanto queda un solo nodo la respuesta de la regla es que no. Con dos nodos, la anti-afinidad protege el día a día y se aparta el día que hace ruido. Si lo que operas es un puñado de máquinas sin pareja real —cada servicio, una VM— entonces sí, no necesitas nada de esto, y añadir reglas solo te dará conflictos que resolver.

Y si tu caso es el de arriba —prefieres encendido y degradado a apagado y correcto— hay un apaño que usamos y que decimos que es apaño, porque no es una función pensada para esto: en lugar de una afinidad de recurso negativa, dos reglas de afinidad de nodo no estrictas, una por máquina, apuntando a nodos distintos. Separa mientras se pueda y no bloquea cuando no se pueda, que es justo la asimetría de valores por defecto con la que empezaba este post. No es tan limpio como la regla negativa y no da ninguna garantía dura; simplemente hace lo otro.

Todo esto va de lo mismo que el resto de nuestro trabajo: el fallo del nodo es inevitable y no se negocia. Lo que sí se decide, y se decide antes, es el tamaño de la avería. Un cluster con las reglas escritas y la cuenta hecha pierde un nodo y sigue. Uno sin ellas también sobrevive casi siempre, porque el planificador reparte razonablemente bien, y ese «casi siempre» es precisamente el problema: funciona hasta el día que le toca poner tus dos réplicas en el mismo sitio, y ese día ya no hay a quién preguntar. Si estás montando o revisando uno, el checklist de hardening que aplicamos a cada cluster Proxmox VE 9.2 cubre la otra mitad de la conversación.

Nota de fuentes

Todo lo técnico de este post sale de tres fuentes primarias de Proxmox, consultadas el 10 de septiembre de 2026: el capítulo High Availability de la documentación oficial de Proxmox VE y la página Roadmap del wiki oficial, con los registros de cambios de las versiones 9.0, 9.1 y 9.2. De la documentación proceden: que el modo de planificación por defecto del CRS es basic y que ese modo elige nodo por el número de invitados activos; la existencia de los modos static-load y dynamic-load y qué mide cada uno; que la ronda del gestor de HA dura alrededor de diez segundos; que la recuperación de recursos y los cambios de reglas son puntos de planificación siempre activos; que las reglas de afinidad de nodo tienen strict a 0 por defecto y qué implica; que las reglas de afinidad de recurso son estrictas por defecto y, en la práctica, solo estrictas —el comando no expone ningún --strict para esa familia— y que, si la restricción no se puede cumplir, el recurso queda en estado recovery en un failover o en error en otro caso; la fusión de reglas positivas que comparten recursos y la herencia de restricciones dentro de un grupo positivo; las pruebas de viabilidad y que las reglas que no las pasan quedan deshabilitadas; el funcionamiento del balanceador automático, su umbral de desequilibrio por defecto del 30 %, que solo mueve recursos gestionados por HA de forma secuencial, que requiere el modo static-load o dynamic-load, que sus migraciones obedecen siempre las reglas de afinidad vigentes y el comportamiento del rebalanceo desactivado por recurso. Los comandos citados son los de la propia documentación y de la página de manual de ha-manager. Del Roadmap proceden: que las reglas de HA se introdujeron en Proxmox VE 9.0, que los grupos de HA quedan obsoletos y se migran automáticamente a reglas de afinidad de nodo cuando todos los nodos corren Proxmox VE 9, que nofailback se sustituye por failback, que Proxmox VE 9.2 se publicó el 21 de mayo de 2026 y que el balanceo dinámico llegó en esa versión. Es lectura NUESTRA, y no de la documentación: que un cluster sin reglas declaradas tiene un problema latente y no un problema; que una regla negativa insatisfacible es una decisión de diseño sobre si prefieres degradado o parado; el orden de trabajo del checklist; y el apaño de las dos reglas de afinidad de nodo no estrictas como sustituto blando de la anti-afinidad, que presentamos como apaño precisamente porque la documentación no lo plantea así. No damos cifras de rendimiento, tiempos de recuperación ni porcentajes de clusters afectados, porque no los tenemos medidos y preferimos decirlo. Que operamos Proxmox VE con Ceph en producción y que no somos resellers de Proxmox ni de VMware es información propia de everyWAN. Comprueba cualquiera de estos comandos en tu entorno de pruebas antes de ejecutarlos en producción. La fotografía de portada es «Front of server racks at NERSC», del Lawrence Berkeley National Laboratory, publicada en Wikimedia Commons bajo dominio público.