Alta disponibilidad en Proxmox VE 9: HA, fencing y balanceo dinámico sin sustos

La alta disponibilidad es una de esas cosas que todo el mundo quiere tener y muy poca gente configura bien. En Proxmox VE es tentador: se activa con cuatro clics, la interfaz te dice que la VM está «HA gestionada» y uno se queda tranquilo. Hasta que se cae un nodo de verdad, en producción, un martes por la tarde, y descubres que el clúster no reacciona como esperabas —o que reacciona demasiado y te apaga a martillazos un servidor que estaba perfectamente sano. He visto ambas cosas, y las dos tienen la misma raíz: montar HA sin entender qué hay debajo.

Este tutorial va de entender qué hay debajo. Vamos a recorrer el stack de HA de Proxmox VE 9 pieza a pieza: el ha-manager, los recursos, las reglas de afinidad que en la versión 9 sustituyen a los viejos grupos, el fencing por watchdog que es lo que de verdad hace que todo esto sea seguro, el Cluster Resource Scheduler con su flamante balanceo dinámico de la 9.2, y cómo desactivar HA para un mantenimiento sin que el clúster entre en pánico. Todo con comandos reales y con los caveats que se pagan caros. Doy por hecho que ya tienes un clúster montado; si andas peleándote con el almacenamiento, que es requisito para todo esto, échale antes un ojo a la guía de almacenamiento en Proxmox VE.

Qué es el stack de HA de Proxmox: ha-manager, CRM y LRM

Proxmox no tiene «un servicio de HA» monolítico. Tiene dos daemons cooperando sobre el sistema de ficheros replicado del clúster (pmxcfs, montado en /etc/pve), y esa arquitectura explica casi todo su comportamiento.

El primero es el CRM (Cluster Resource Manager, servicio pve-ha-crm). Solo hay un CRM activo en todo el clúster: el master. Se elige mediante un lock en pmxcfs y es quien toma las decisiones globales —a qué nodo va cada recurso, cuándo hay que hacer fencing, cuándo se recupera un servicio caído. Si el nodo master se cae, otro nodo adquiere el lock y se convierte en el nuevo CRM. El segundo es el LRM (Local Resource Manager, servicio pve-ha-lrm), que corre en cada nodo y ejecuta localmente lo que el CRM le ordena: arrancar, parar o migrar las VMs y contenedores de ese nodo concreto.

La comunicación entre ambos no es por red directa, sino a través de ficheros en /etc/pve/ha/. El CRM escribe el estado deseado, el LRM lo lee, actúa y escribe el estado real. Este diseño «desacoplado» es la razón por la que Proxmox puede seguir funcionando aunque la comunicación se degrade, y también la razón por la que necesita quórum para hacer nada: sin quórum, pmxcfs pasa a solo lectura y el CRM no puede escribir órdenes.

Un recurso HA es simplemente una VM o un contenedor puestos bajo la gestión de este par de daemons. Se identifican con el prefijo del tipo: vm:100 para una máquina virtual con VMID 100, ct:105 para un contenedor LXC. Cuando añades un recurso a HA, le estás diciendo al clúster «este servicio me importa; si el nodo donde vive se muere, quiero que lo levantes en otro sitio». El estado global de todo esto se consulta con un único comando que vas a teclear mil veces:

# Estado del CRM, de cada LRM y de todos los recursos gestionados
ha-manager status

# Versión detallada, con el estado deseado y el real de cada servicio
ha-manager status --verbose

Requisitos previos que no se negocian

HA en Proxmox no es un interruptor: es la punta de un iceberg que se apoya en tres pilares. Si alguno falla, HA no solo no ayuda, sino que puede hacer daño.

Clúster con quórum real. HA requiere un clúster Corosync funcionando y, sobre todo, con quórum. El quórum es la mayoría de votos que permite al clúster tomar decisiones con la certeza de que no hay otra «mitad» haciendo lo mismo por su cuenta. Con tres nodos, el quórum es 2; si se cae uno, los dos que quedan siguen teniendo mayoría y pueden recuperar los servicios. Comprobar el quórum es lo primero que se hace siempre:

# Estado del clúster: nodos, votos, quórum y anillos de Corosync
pvecm status

# Fíjate en la línea "Quorate: Yes" y en "Expected votes" vs "Total votes"
pvecm nodes

Almacenamiento accesible desde varios nodos. Aquí está el malentendido número uno. Para que una VM se levante en otro nodo, sus discos tienen que estar disponibles en ese otro nodo. Hay dos caminos válidos: storage compartido de verdad —Ceph RBD, NFS, o LVM sobre iSCSI/FC— donde el disco vive en un sitio al que todos los nodos llegan; o replicación ZFS, donde cada nodo tiene una copia local que se sincroniza periódicamente. Con storage compartido, la recuperación es prácticamente instantánea porque el disco ya está ahí. Con replicación ZFS, la recuperación funciona, pero pierdes todo lo que se escribió desde la última réplica: si replicas cada 15 minutos, en el peor caso pierdes 15 minutos de datos. Es un compromiso perfectamente razonable para muchos entornos, pero hay que tomarlo con los ojos abiertos.

# Replicación ZFS de la VM 100 al nodo pve2 cada 5 minutos
pvesr create-local-job 100-0 pve2 --schedule "*/5"

# Estado de los trabajos de replicación
pvesr status

Red de clúster fiable y dedicada. Corosync es sensible a la latencia, no al ancho de banda. Un anillo Corosync compartido con el tráfico de backups o de migraciones es una fábrica de falsos positivos: un pico de latencia hace que un nodo parezca caído, se dispara el fencing, y te reinicias un servidor que estaba vivo. La regla de oro es una red física separada solo para Corosync, y a ser posible un segundo anillo redundante por otra interfaz. Esto no es un lujo: es la diferencia entre un HA que te salva y uno que te sabotea.

Estados de un recurso HA: lo que pides y lo que ocurre

Conviene distinguir dos planos. Por un lado está el estado solicitado (request state): lo que tú, administrador, le pides al recurso. Por otro, el estado de servicio (service state): la fase real en la que el CRM tiene el recurso en cada instante, que va cambiando durante las transiciones. Confundirlos lleva a sustos innecesarios cuando ves un migrate o un fence en la salida de ha-manager status.

Los estados solicitados son cuatro:

• started: el CRM se encarga de mantener el recurso en marcha. Si el nodo cae, lo recupera en otro. Es el estado normal de una VM en producción.
• stopped: el recurso se mantiene parado, pero sigue gestionado. Si el nodo donde estaba cae, el CRM lo «recoloca» (lo asocia a otro nodo) pero sin arrancarlo.
• disabled: parado y sin intentos de recolocación. Es el estado para «quítame esto de en medio temporalmente sin sacarlo de HA».
• ignored: el recurso deja de estar gestionado por HA por completo, pero sin borrar su configuración. Útil para intervenir a mano sin que el CRM interfiera.

Los estados de servicio son más y describen el ciclo de vida interno. Los que más vas a ver son estos:

La distinción entre migrate y relocate es la que más gente confunde. Migrate es en caliente y conserva el estado; se usa cuando el nodo origen sigue vivo (por ejemplo, en un mantenimiento planificado). Relocate es apagar y volver a arrancar en otro sitio; es lo que ocurre tras la caída de un nodo, porque de una máquina muerta no se puede sacar el contenido de la RAM.

Fencing y watchdog: el corazón de un HA seguro

Aquí es donde se separa el HA de juguete del HA de producción. El problema que resuelve el fencing tiene nombre: split-brain. Imagina que un nodo deja de responder por la red de clúster, pero en realidad sigue vivo y sus VMs siguen escribiendo en el disco compartido. Si el clúster asume que está muerto y arranca esas mismas VMs en otro nodo, tienes dos instancias de la misma máquina escribiendo sobre los mismos datos a la vez. Eso no es una caída: es corrupción garantizada, y de la peor clase, porque parece que todo funciona hasta que el sistema de ficheros se desintegra.

Para evitarlo, antes de recuperar los recursos de un nodo sospechoso hay que tener la certeza absoluta de que ese nodo está apagado o aislado. A eso se le llama fencing. Proxmox lo resuelve con una estrategia elegante llamada self-fencing por watchdog: en vez de que otro nodo tenga que ir a apagarte por PDU o IPMI, cada nodo se vigila a sí mismo y se reinicia solo si detecta que ha perdido quórum o que sus daemons de HA no están funcionando.

El mecanismo es un watchdog, un temporizador hardware o software que hay que «alimentar» (rearmar) periódicamente. Mientras el LRM está sano y tiene quórum, va reseteando la cuenta atrás una y otra vez. Si el LRM deja de alimentar el watchdog —porque el proceso se ha bloqueado, porque el nodo ha perdido quórum, o porque el CRM o el LRM han muerto— el temporizador llega a cero y reinicia el nodo por hardware, sin preguntar. La documentación es explícita: si hay servicios activos y el LRM o el CRM dejan de estar planificados, el watchdog dispara el reinicio tras 60 segundos.

Proxmox prefiere un watchdog hardware si el equipo lo tiene (IPMI, iTCO en muchas placas Intel, o el módulo específico del fabricante), porque es independiente del estado del sistema operativo: aunque el kernel se cuelgue por completo, el watchdog físico sigue contando y acaba reseteando. Si no hay hardware disponible o configurado, Proxmox carga el módulo del kernel softdog, que emula /dev/watchdog. El softdog es fiable, pero al vivir dentro del propio kernel que vigila, tiene una fiabilidad algo menor que un watchdog físico. La selección del módulo hardware se hace así:

# Indicar el módulo de watchdog hardware a usar (ejemplo con iTCO de Intel)
# Editar /etc/default/pve-ha-manager y ajustar:
#   WATCHDOG_MODULE=iTCO_wdt

# Comprobar qué watchdog está activo tras reiniciar el servicio
cat /sys/class/watchdog/watchdog0/state
lsmod | grep -E 'wdt|softdog'

En la salida de ha-manager status verás una línea de estado del watchdog para el CRM y otra por cada LRM que tenga su lock activo. Ese lock es la clave: el LRM solo hace algo si consigue su agent lock en pmxcfs, y mientras lo tiene, sostiene el watchdog. En cuanto pierde quórum, no puede renovar el lock, deja de alimentar el watchdog, y a los 60 segundos el nodo se reinicia solo. Ese reinicio es la garantía que el CRM master necesita para, con total seguridad, recuperar los servicios en otro sitio sin riesgo de split-brain.

Configuración paso a paso: recursos, reglas y políticas

Con los conceptos claros, la configuración es directa. Empezamos poniendo una VM bajo gestión de HA. Basta con añadirla como recurso; el estado por defecto es started, así que quedará en marcha y vigilada:

# Poner la VM 100 bajo HA (arrancada y vigilada por defecto)
ha-manager add vm:100

# Añadir un contenedor con estado y límites de reintentos explícitos
ha-manager add ct:105 --state started --max_restart 3 --max_relocate 2

# Cambiar el estado de un recurso ya gestionado
ha-manager set vm:100 --state stopped

# Sacar un recurso de HA por completo (sin borrar la VM)
ha-manager remove vm:100

Las dos políticas que controlan cómo reacciona el clúster ante un fallo son max_restart y max_relocate. max_restart es cuántas veces intenta el LRM rearrancar el recurso en el mismo nodo si el arranque falla (por defecto 1). max_relocate es cuántas veces intenta el CRM moverlo a otro nodo distinto si sigue sin arrancar (por defecto 1). Cuando se agotan ambos contadores, el recurso pasa a estado error y ahí se queda, esperando que un humano investigue. Esto es deliberado: si una VM no arranca en ningún sitio, el problema no es de ubicación, y ponerse a rebotarla infinitamente entre nodos solo agrava las cosas.

HA rules: el reemplazo de los grupos en Proxmox VE 9

Aquí llega uno de los cambios más importantes de la versión 9, y por eso conviene tenerlo claro. En Proxmox VE 8 se usaban los grupos HA para decir en qué nodos podía correr un recurso y con qué preferencia. En Proxmox VE 9 los grupos están deprecados y se sustituyen por las HA rules, que son funcionalmente equivalentes pero mucho más flexibles. Los grupos siguen funcionando por compatibilidad —si actualizas desde la 8, se migran automáticamente a reglas de afinidad de nodo—, pero desaparecerán en Proxmox VE 10, así que lo sensato en instalaciones nuevas es usar reglas directamente.

Hay dos familias de reglas. Las reglas de afinidad de nodo (node affinity) definen en qué nodos prefiere correr un recurso, con prioridades, y son las herederas directas de los grupos:

# La VM 100 prefiere ejecutarse en node1
ha-manager rules add node-affinity ha-rule-vm100 --resources vm:100 --nodes node1

# Afinidad estricta: SOLO puede correr en los nodos indicados
ha-manager rules add node-affinity solo-node1 --resources vm:101 --nodes node1 --strict 1

# Prioridades en cascada: prefiere node1, luego node2/node3, y node4 como último recurso
ha-manager rules add node-affinity prioridades \
  --resources vm:200,ct:300 --nodes "node1:2,node2:1,node3:1,node4"

El número tras los dos puntos es la prioridad: a mayor número, mayor preferencia. En el ejemplo, node1 con prioridad 2 gana a los demás; node2 y node3 comparten prioridad 1 y se reparten la carga entre ellos; node4, sin prioridad, es el comodín de último recurso. La opción --strict 1 es la que antes en los grupos se llamaba «restricted»: sin ella (comportamiento por defecto, no estricto), si ninguno de los nodos preferidos está disponible el recurso se mueve a cualquier otro nodo con tal de seguir vivo; con ella, el recurso solo puede correr en los nodos listados, y si ninguno está disponible se queda parado. Estricto es para VMs con licencias atadas a hardware o requisitos de afinidad reales; para el resto, no estricto es casi siempre lo que quieres.

La segunda familia, novedad muy útil, son las reglas de afinidad entre recursos (resource affinity). Sirven para decir «estas dos VMs deben ir juntas» o «estas dos nunca en el mismo nodo»:

# Mantener juntas dos VMs que se comunican mucho entre sí (afinidad positiva)
ha-manager rules add resource-affinity juntas \
  --affinity positive --resources vm:100,vm:200

# Mantener separados dos nodos de un mismo clúster de aplicación (afinidad negativa)
ha-manager rules add resource-affinity separadas \
  --affinity negative --resources vm:200,ct:300

# Listar todas las reglas definidas
ha-manager rules list

La afinidad positiva mantiene los recursos en el mismo nodo (ideal para una aplicación y su base de datos que se hablan por red interna). La negativa los reparte por nodos distintos, y es oro para clústeres a nivel de aplicación: si tienes dos réplicas de un balanceador o dos nodos de un etcd, lo último que quieres es que HA los junte en la misma máquina y que una sola caída te tumbe los dos. Cuando defines una afinidad negativa, el propio CRS se encarga de separarlos.

CRS y el balanceo dinámico de carga de la 9.2

El Cluster Resource Scheduler (CRS) es el cerebro que decide en qué nodo colocar cada recurso. Hasta ahora, cuando el CRM tenía que recuperar una VM, elegía destino con criterios sencillos. El CRS refina esa decisión, y en Proxmox VE 9 se configura con tres modos, en el fichero /etc/pve/datacenter.cfg (o desde Datacenter → Options → HA):

• basic: solo cuenta el número de servicios por nodo. Rápido y tonto.
• static: tiene en cuenta la configuración estática de CPU y memoria de cada recurso para repartir mejor. Es el salto de calidad razonable para la mayoría.
• dynamic: la gran novedad de la 9.2. Usa métricas de utilización reales y en tiempo real de nodos y recursos para decidir, no la configuración teórica.

El modo estático ya trae dos comportamientos muy útiles. Uno es rebalancear al arrancar un recurso, para que cuando una VM pase de parada a arrancada el CRS le busque el nodo más descargado en ese momento en lugar de dejarla donde estaba:

# Modo estático + elegir el mejor nodo al arrancar un recurso
# En /etc/pve/datacenter.cfg:
crs: ha=static,ha-rebalance-on-start=1

Pero lo que cambia las reglas del juego es el modo dynamic de la 9.2 con su balanceador de carga dinámico. En este modo, el CRS no se limita a colocar bien un recurso cuando hay un fallo: monitoriza continuamente el desequilibrio real del clúster y, si un nodo se sobrecarga mientras otros están ociosos, migra automáticamente en vivo las VMs y contenedores gestionados por HA para reequilibrar, respetando siempre las reglas de afinidad que hayas definido. Es el equivalente conceptual al DRS de VMware, pero integrado y sin licencia aparte. Se ajusta con varios parámetros para que no se vuelva loco migrando cosas a la mínima:

# Modo dinámico con balanceo automático y parámetros de sensibilidad
# En /etc/pve/datacenter.cfg:
crs: ha=dynamic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=15,ha-auto-rebalance-margin=10,ha-auto-rebalance-hold-duration=5,ha-auto-rebalance-method=topsis

Los parámetros merecen una explicación, porque son los que evitan el famoso «ping-pong» de migraciones:

La combinación de threshold, margin y hold-duration es lo que hace este balanceador utilizable en producción y no un generador de migraciones nerviosas: no basta con que haya desequilibrio, tiene que ser lo bastante grande (threshold), tiene que mantenerse en el tiempo (hold-duration) y la migración tiene que mejorar de verdad la situación (margin). Mi consejo si estrenas la 9.2: empieza en static, obsérvalo unas semanas, y solo entonces pasa a dynamic con umbrales conservadores.

Comportamiento ante el fallo de un nodo, minuto a minuto

Vale la pena seguir la secuencia completa de lo que ocurre cuando un nodo se cae en seco, porque entender los tiempos evita llamadas de pánico. Supongamos un clúster de tres nodos con storage compartido y la VM 100 corriendo en node3, que sufre un fallo eléctrico total.

1. Segundo 0: node3 desaparece. Corosync deja de recibir sus paquetes.
2. Primeros segundos: los otros dos nodos detectan la pérdida de node3. Como quedan 2 votos de 3, mantienen quórum y pueden actuar. El CRM master marca los recursos de node3 en estado fence: sabe que hay que recuperarlos, pero no toca nada todavía.
3. Hasta el segundo 60: aquí está la espera obligada. El CRM no arranca la VM 100 en otro nodo aún, porque no puede estar seguro de que node3 esté realmente muerto y no simplemente incomunicado. Espera a que el watchdog de node3 haga su trabajo. Si node3 estuviera vivo pero aislado, su propio LRM habría perdido quórum, habría dejado de alimentar el watchdog, y a los 60 segundos se autorreiniciaría. Como en nuestro caso está muerto de verdad, esa condición se da igualmente.
4. Tras confirmar el fencing: el CRM da por aislado a node3 y pasa la VM 100 a estado recovery. El CRS elige el nodo destino (el más descargado, según el modo configurado) y ordena al LRM de ese nodo arrancar la VM.
5. Arranque: con storage compartido, el disco ya está accesible, así que la VM arranca «en frío» como si hubiera sufrido un corte de luz. El sistema operativo invitado hace su boot normal. Con replicación ZFS, arranca desde la última copia replicada, con la consiguiente pérdida de los datos posteriores a esa réplica.

El tiempo total, por tanto, ronda los 60 segundos de fencing más el tiempo de arranque del invitado. No es HA de «cero pérdida de servicio» como un clúster activo-activo a nivel de aplicación; es recuperación automática rápida. Para la inmensa mayoría de cargas —un servidor web, una base de datos con su propio mecanismo de recuperación, un servicio interno— minuto y medio de indisponibilidad no planificada frente a una intervención manual a las tres de la madrugada es un trato excelente.

Mantenimiento planificado: desactivar HA sin sustos

Uno de los escenarios donde HA muerde a los novatos es el mantenimiento. Quieres reiniciar un nodo para aplicar actualizaciones, apagas el nodo, y HA —haciendo su trabajo— interpreta que se ha caído y empieza a mover cosas, o peor, dispara fencing. La forma correcta de intervenir un nodo gestionado por HA es ponerlo en modo mantenimiento, que en Proxmox VE 9 se controla limpiamente:

# Poner un nodo en mantenimiento: migra sus recursos HA a otros nodos
ha-manager crm-command node-maintenance enable node3

# Terminado el mantenimiento, devolver el nodo al servicio
ha-manager crm-command node-maintenance disable node3

Al activar el mantenimiento, el LRM de ese nodo se marca como no disponible y migra en vivo sus recursos HA a otros nodos, sin cortar servicio y sin fencing, porque el nodo sigue vivo y con quórum. Cuando desactivas el mantenimiento, el nodo vuelve a estar disponible y —según tu política de failback en las reglas— los recursos pueden volver a él. Es la diferencia entre un reinicio ordenado y provocar una recuperación de emergencia por gusto.

Relacionado con esto está la política de apagado del clúster, que determina qué hace HA cuando apagas un nodo por las vías normales. La opción recomendada para nodos con recursos HA es migrate, que fuerza la migración de los servicios antes de completar el apagado:

# Política de apagado que migra los recursos HA antes de apagar el nodo
# En /etc/pve/datacenter.cfg:
ha: shutdown_policy=migrate

Si necesitas sacar un recurso concreto de la ecuación durante una intervención puntual sin tocar todo el nodo, recuerda los estados: ha-manager set vm:100 --state ignored lo deja fuera del control de HA para que puedas manipularlo a mano, y luego --state started lo devuelve al redil.

Caveats: donde HA se convierte en el problema

He dejado para el final la lista de trampas, porque es la parte que separa un despliegue que funciona de uno que te da un disgusto. Todas las he visto en producción.

• HA sin storage compartido real. Activar HA sobre almacenamiento local sin replicación es un billete a la frustración: cuando el nodo cae, sus discos caen con él y la VM no puede arrancar en ningún sitio porque no hay datos que arrancar. Si no tienes Ceph, NFS o iSCSI, tu única HA legítima es ZFS con replicación, asumiendo la ventana de pérdida de datos. No hay atajos.
• El clúster de dos nodos sin QDevice. Este es el caveat más importante y el más ignorado. Con dos nodos, el quórum es 2. Si uno se cae, el que queda tiene 1 voto de 2: pierde el quórum, pmxcfs pasa a solo lectura, y HA no puede recuperar nada. Encima, el propio nodo superviviente, al perder quórum, deja de alimentar su watchdog y se autorreinicia a los 60 segundos. Es decir: se te cae un nodo y el otro se reinicia solo. Desastre completo. La solución es un QDevice, un tercer votante ligero (un Raspberry Pi, una VM externa, cualquier Linux fuera del clúster) que rompe el empate:

# Instalar el paquete en el clúster (en cada nodo) y en el equipo externo
apt install corosync-qdevice   # en los nodos del clúster
apt install corosync-qnetd     # en el equipo árbitro externo

# Dar de alta el QDevice desde un nodo del clúster
pvecm qdevice setup 192.168.10.9

# Verificar: ahora deben aparecer 3 votos esperados
pvecm status

• Quórum perdido por red frágil. Un Corosync compartido con tráfico pesado genera falsos positivos: latencias que el clúster interpreta como caídas. Resultado: fencing de nodos sanos. Red dedicada para Corosync y, a ser posible, segundo anillo. Repito esto a propósito porque es la causa número uno de fencings inexplicables.
• Fencing mal configurado o watchdog inexistente. Si el watchdog no funciona —módulo mal cargado, hardware no soportado que nunca cayó al softdog—, el CRM se quedará esperando eternamente en estado fence un aislamiento que nunca llega, y los recursos no se recuperarán jamás. Verifica siempre que el watchdog esté activo antes de dar HA por bueno.
• Dependencia absoluta del watchdog. Todo el modelo de seguridad de Proxmox descansa en que un nodo problemático se reinicia solo. Eso implica que reinicios legítimos son parte del funcionamiento normal. Si tienes cargas que no toleran un reinicio abrupto, ese problema se resuelve dentro del invitado (con HA a nivel de aplicación), no discutiéndole al watchdog su razón de ser.
• Confiar en HA como si fuera backup. HA te protege de la caída de hardware. No te protege de un rm -rf, de un ransomware ni de un borrado de VM. HA y backups son capas distintas y complementarias; una no sustituye a la otra jamás.

Bien montado —tres nodos o más, storage compartido o replicación ZFS consciente, red de Corosync dedicada, watchdog verificado y reglas de afinidad pensadas— el HA de Proxmox VE 9 es sólido, predecible y, con el balanceo dinámico de la 9.2, además reparte carga solo. Mal montado, es una máquina de generar incidentes. La diferencia, como casi siempre en este oficio, está en entender qué hace cada pieza antes de pulsar el botón.