«Tenemos alta disponibilidad» es una de esas frases que todo el mundo dice y pocos han probado apagando un servidor de un tirón. En Proxmox, activar HA es marcar una opción en la interfaz. Que esa opción haga lo que esperas cuando a las tres de la mañana muere una fuente de alimentación es otra cosa. Depende de piezas que no se ven en el botón: quorum, fencing y almacenamiento compartido.
Este artículo va de esas piezas. No de la teoría de manual, sino de por qué un clúster mal diseñado se queda a medias —o peor, arranca la misma VM dos veces y corrompe sus datos— y cómo se diseña uno que convierta un fallo de hardware en un incidente aburrido: la VM se reinicia sola en otro nodo, alguien recibe una alerta y el servicio apenas parpadea.
Damos por supuesto que ya tienes un clúster Proxmox en producción o estás a punto. Si vienes de VMware, la lógica es distinta de vSphere HA en detalles importantes, y conviene entenderlos antes de confiarle producción.
La alta disponibilidad en Proxmox VE es un servicio del clúster que vigila un conjunto de recursos —VMs y contenedores marcados como gestionados por HA— y garantiza que sigan funcionando aunque el nodo que los aloja falle. Cuando detecta que un nodo ha muerto, reinicia sus recursos en otro nodo sano.
La palabra clave es reinicia, no migra. Una VM no se traslada en caliente desde un nodo que acaba de morir: eso es imposible, el nodo ya no está. Lo que ocurre es que el clúster arranca de nuevo esa VM en otro sitio, a partir de su disco, que debe estar accesible desde el nodo nuevo. De ahí que el almacenamiento compartido no sea un detalle: es el requisito.
Esto marca la diferencia con la migración en vivo, que sí traslada una VM en marcha entre nodos sanos sin cortarla —para mantenimiento planificado, por ejemplo—. HA es para lo no planificado: el fallo. Dos mecanismos distintos para dos problemas distintos.
Un clúster necesita saber, en todo momento, quién sigue vivo y con autoridad para actuar. Proxmox usa Corosync para eso, y la regla es la mayoría: un clúster con N nodos mantiene quorum mientras más de la mitad sigan comunicándose. Con 3 nodos, necesitas 2. Con 5, necesitas 3.
¿Por qué importa tanto? Por el escenario de partición (el temido split-brain). Imagina un clúster de 4 nodos donde un fallo de red lo parte en dos grupos de 2. Sin regla de mayoría, cada mitad podría creerse la superviviente y arrancar las mismas VMs. Dos copias de la misma máquina escribiendo en el mismo disco es corrupción garantizada. La regla de mayoría lo evita: en una partición 2-2 ninguna mitad tiene quorum, así que ninguna actúa. Es preferible parar a duplicar.
Esto tiene una consecuencia de diseño que mucha gente aprende tarde: un clúster de 2 nodos no tiene HA real por sí solo. Si uno cae, el otro se queda con 1 de 2 —no es mayoría— y pierde quorum. Se necesita un tercer voto. Para eso existe el QDevice: un árbitro externo ligero (un pequeño servidor o VM fuera del clúster) que aporta el voto de desempate. Con dos nodos + QDevice, cuando uno cae el otro tiene 2 de 3 y sigue operando.
Este es el mecanismo que más se malinterpreta y el que más incidentes causa cuando falta. Antes de reiniciar la VM de un nodo caído en otro nodo, el clúster necesita certeza absoluta de que el nodo original ya no está escribiendo en el disco de esa VM. Si no lo garantiza, vuelve el fantasma del split-brain: dos nodos tocando el mismo dato.
Esa garantía se llama fencing. Proxmox lo resuelve por defecto con un mecanismo elegante basado en un watchdog por hardware o software: cada nodo tiene un temporizador que debe reiniciarse constantemente mientras esté sano y con quorum. Si un nodo pierde quorum o se cuelga, deja de resetear su watchdog, y el watchdog lo reinicia por la fuerza (self-fencing) pasados unos 60 segundos. El clúster, por su parte, espera ese margen antes de reubicar los recursos: sabe que a los 60 segundos el nodo problemático o ha vuelto sano o se ha reiniciado a sí mismo. En ningún caso sigue escribiendo.
La consecuencia práctica: el tiempo de recuperación de HA no es instantáneo. Hay una ventana —del orden de uno a dos minutos— entre el fallo y el arranque de la VM en el nodo nuevo. Es el precio de la seguridad de datos. Quien espere failover en milisegundos está pensando en balanceo de carga, no en HA de virtualización.
Para que un nodo sano pueda arrancar la VM de un nodo muerto, su disco debe ser accesible desde ambos. Eso significa almacenamiento compartido o replicado. Las opciones habituales en Proxmox:
| Almacenamiento | Cómo comparte | Encaja bien en |
|---|---|---|
| Ceph | Distribuido, cada bloque replicado en varios nodos | Clústeres de 3+ nodos que quieren storage e HA en el mismo hardware |
| NFS / iSCSI | Cabina externa accesible por todos los nodos | Quien ya tiene una SAN/NAS y quiere separar cómputo de almacenamiento |
| ZFS con replicación | Cada nodo tiene su copia, sincronizada periódicamente | 2-3 nodos sin cabina; asume perder los últimos minutos de datos |
Merece un matiz la última fila. La replicación ZFS no es almacenamiento compartido de verdad: copia los discos de un nodo a otro cada pocos minutos. Si el nodo cae, la VM arranca en el otro con la última réplica —puede faltar lo escrito desde la última sincronización—. Es HA «casi síncrona», barata y válida para muchas cargas, siempre que asumas ese RPO de unos minutos. Para RPO cero, hace falta Ceph o una cabina compartida.
Si te planteas Ceph para unificar cómputo y almacenamiento, lo desarrollamos en Ceph para cloud privado sobre Proxmox.
Sobre un clúster ya formado con almacenamiento compartido, activar HA para una VM es directo:
# Añadir una VM al gestor de HA (VMID 100), con arranque preferente
# en un grupo de nodos y reinicio automático ante fallo
ha-manager add vm:100 --state started --max_restart 3 --max_relocate 3
# Ver el estado del gestor de HA en todo el clúster
ha-manager statusEn la interfaz web es Datacenter → HA: añades el recurso, defines su estado deseado (started) y, opcionalmente, un HA Group que fija en qué nodos prefiere correr y con qué prioridad. Los grupos sirven para políticas del tipo «esta VM prefiere los nodos 1 y 2; solo cae al 3 si no queda otra».
Para el QDevice en clústeres de dos nodos:
# En el árbitro externo
apt install corosync-qnetd
# En cada nodo del clúster
apt install corosync-qdevice
pvecm qdevice setup <IP-del-arbitro>A partir de ahí, pvecm status muestra tres votos donde antes había dos, y el clúster sobrevive a la caída de un nodo.
La lista de fallos reales es corta y se repite. Vale la pena conocerla de antemano.
Corosync compartiendo red con el tráfico pesado. El quorum viaja por Corosync, que es sensible a la latencia. Si comparte interfaz con el tráfico de storage o de backup, un pico de I/O puede provocar que los nodos se pierdan de vista, crean que hay fallo y disparen fencing sin que nada esté roto. Corosync quiere su red dedicada, o al menos una interfaz separada con prioridad. Es el error de diseño más común y el más caro.
Clúster de dos nodos sin QDevice. Se monta, se prueba apagando ordenadamente, funciona, y a producción. El día que un nodo muere de golpe, el otro pierde quorum y se queda tan parado como el muerto. HA sin tercer voto es HA que no llega cuando hace falta.
Sin almacenamiento compartido. Se marca HA en la VM, pero su disco vive en local. El nodo cae, el clúster quiere reubicar la VM y descubre que su disco no existe en ningún otro sitio. HA marcada no es HA posible: sin disco accesible, no hay reinicio.
Esperar failover instantáneo. Se mide el tiempo de recuperación, se ven 90 segundos y se reporta como bug. No lo es: es el fencing haciendo su trabajo. Ese minuto largo es lo que separa un failover seguro de una corrupción de datos.
No probar nunca el fallo real. El clásico. HA configurada, jamás validada tirando del cable. La primera vez que un clúster hace failover no debería ser en un incidente real. Se prueba en frío, con carga controlada, apagando un nodo a lo bruto y midiendo qué pasa.
Reuniendo todo, el patrón que aguanta:
Con eso, la muerte de un nodo deja de ser una crisis y pasa a ser una alerta y un par de VMs reiniciándose solas en otro sitio. Que es exactamente lo que se le pide a la alta disponibilidad.
¿Cuántos nodos necesito para HA en Proxmox? Tres es el mínimo cómodo: mantiene quorum (2 de 3) si cae uno, sin árbitro externo. Con dos nodos es posible, pero necesitas un QDevice que aporte un tercer voto; si no, al caer un nodo el otro pierde quorum y HA no actúa.
¿HA migra mis VMs en caliente cuando un nodo falla? No. La migración en vivo es para nodos sanos (mantenimiento planificado). Cuando un nodo falla, HA no migra: reinicia la VM en otro nodo a partir de su disco compartido. Por eso el almacenamiento debe ser accesible desde varios nodos.
¿Cuánto tarda la recuperación? Del orden de uno a dos minutos. El clúster espera a que el fencing garantice que el nodo caído ya no escribe (unos 60 segundos de watchdog) antes de arrancar la VM en otro sitio. No es failover instantáneo: esa ventana es el precio de no corromper datos.
¿Qué es el fencing y por qué es imprescindible? Es el mecanismo que asegura que un nodo caído no siga escribiendo en el disco de sus VMs antes de reiniciarlas en otro lado. Proxmox lo hace con un watchdog que reinicia por la fuerza a un nodo que pierde quorum. Sin fencing, dos nodos podrían tocar el mismo disco: corrupción segura.
¿Puedo hacer HA sin Ceph ni cabina externa? Sí, con replicación ZFS entre nodos. No es almacenamiento compartido real —copia los discos cada pocos minutos—, así que asumes un RPO de minutos: la VM arranca con la última réplica y puede faltar lo más reciente. Para RPO cero necesitas Ceph o una cabina compartida.
¿Quieres montar un clúster Proxmox que aguante de verdad la caída de un nodo, o dudas de si el tuyo hará failover cuando toque? Diseñamos el quorum, el fencing y el almacenamiento contigo, y lo probamos tirando del cable antes de que lo haga un incidente. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.