Consolidar decenas de máquinas virtuales en unos pocos servidores físicos tiene una contrapartida evidente: cuando un nodo falla, no cae un servicio, caen todos los que se ejecutaban en él. La respuesta a ese riesgo es el clúster con alta disponibilidad (HA), y es una de las razones por las que Proxmox VE se ha convertido en la alternativa preferida a los hipervisores comerciales: el clustering y la HA vienen incluidos de serie, sin licencias adicionales.
Pero activar HA no es marcar una casilla. Un clúster mal diseñado —dos nodos sin testigo, Corosync compartiendo red con el tráfico de backup, almacenamiento sin replicar— puede ofrecer menos disponibilidad que un buen servidor en solitario. Los conceptos que separan un clúster robusto de uno frágil son tres: quorum, fencing y almacenamiento compartido.
En este artículo explicamos cómo funciona la alta disponibilidad en Proxmox VE: qué papel juega Corosync, por qué el quorum exige un mínimo de tres votos, cómo el fencing evita el temido split-brain, qué opciones de almacenamiento existen y qué tiempos de failover puedes esperar en la práctica.
Qué Aporta un Clúster Proxmox
Un clúster Proxmox agrupa varios nodos físicos bajo una gestión común. Antes incluso de hablar de alta disponibilidad, el clúster aporta tres capacidades que cambian la operativa diaria:
-
check_circle
Gestión unificada: una sola interfaz web para administrar todos los nodos. La configuración vive en pmxcfs, un sistema de ficheros distribuido que replica
/etc/pveen tiempo real a todo el clúster. - check_circle Migración en vivo: mover una VM de un nodo a otro sin cortar el servicio. Es la base de los mantenimientos planificados: se parchea y reinicia un nodo mientras sus VMs se ejecutan en otro.
- check_circle Alta disponibilidad: si un nodo falla, las VMs y contenedores declarados como recursos HA se reinician automáticamente en los nodos supervivientes, sin intervención humana.
A esto se suma la posibilidad de desplegar Ceph directamente desde la interfaz para construir una plataforma hiperconvergente completa. Si estás valorando alternativas de hipervisor, en nuestra comparativa Proxmox vs VMware analizamos cómo estas funciones incluidas de serie compiten con las suites comerciales.
Corosync: La Capa de Comunicación del Clúster
Toda la coordinación del clúster descansa sobre Corosync, el motor de comunicación que mantiene la pertenencia al clúster (membership), transporta la configuración replicada de pmxcfs y determina, junto con el resto de nodos, quién tiene quorum en cada momento.
Corosync es extraordinariamente sensible a la latencia: necesita tiempos de ida y vuelta estables, idealmente por debajo de 5 ms. Apenas consume ancho de banda, pero si la red se satura —por ejemplo, porque comparte interfaz con el tráfico de backup o de almacenamiento— los mensajes de latido llegan tarde, los nodos se declaran caídos entre sí y el clúster entra en inestabilidad sin que exista un fallo real.
Por eso la recomendación es dedicar una red física exclusiva a Corosync y, además, configurar un segundo enlace por otra interfaz como redundancia. Kronosnet, el transporte de Corosync 3, conmuta automáticamente entre enlaces si el principal se degrada, evitando que un fallo de switch aísle a los nodos.
Quorum: Por Qué el Mínimo Son 3 Nodos
En un sistema distribuido, cada nodo solo conoce su propia perspectiva: si deja de ver a otro nodo, no puede saber si ese nodo ha muerto o si es él quien se ha quedado aislado de la red. El mecanismo que resuelve esta ambigüedad es el quorum: solo la partición que reúne la mayoría de votos (la mitad más uno) puede seguir operando.
De ahí la regla del mínimo de tres nodos. Con dos nodos, cualquier fallo deja a cada uno con un voto de dos: nadie tiene mayoría y el clúster completo se bloquea. Con tres, la pérdida de uno deja a los dos restantes con mayoría (2 de 3) y el servicio continúa. Si solo dispones de dos servidores, la alternativa soportada es añadir un QDevice: un pequeño demonio de voto que se ejecuta en una tercera máquina (una VM externa o incluso una Raspberry Pi) y aporta el voto de desempate.
¿Qué ocurre al perder el quorum? El nodo pasa a modo de solo lectura: pmxcfs bloquea cualquier cambio de configuración, no se pueden arrancar VMs y, si el nodo ejecuta recursos HA, se reiniciará automáticamente. Es un comportamiento deliberado para evitar el split-brain: dos particiones del clúster ejecutando la misma VM y escribiendo a la vez en el mismo disco, el escenario que corrompe datos de forma casi irreversible.
Regla de oro:
Mantén siempre un número impar de votos en el clúster: 3, 5 o 7 nodos, o 2 nodos + QDevice. Con votos pares, un corte de red que divida el clúster en dos mitades iguales deja a ambas sin mayoría y detiene todo el servicio.
Fencing y Watchdog: Garantizar que un Nodo Caído No Escribe
El quorum decide quién puede operar; el fencing garantiza que quien no puede operar deje de hacerlo de verdad. Antes de rearrancar en otro nodo una VM protegida por HA, Proxmox necesita la certeza absoluta de que el nodo original ya no la está ejecutando; de lo contrario habría dos instancias escribiendo en el mismo disco.
Proxmox implementa el fencing mediante watchdog: un temporizador de hardware (o el módulo softdog del kernel, usado por defecto) que reinicia la máquina si no se rearma periódicamente. Mientras el nodo tiene quorum, el servicio de HA rearma el watchdog; en cuanto lo pierde, deja de hacerlo y el nodo se resetea por sí solo en unos 60 segundos.
El resto del clúster no actúa a ciegas: el HA Manager espera a que expire ese margen de seguridad antes de declarar el nodo cercado y recuperar sus recursos. El resultado es una garantía firme: cuando la VM arranca en su nuevo nodo, el antiguo ya se ha reiniciado y no puede seguir escribiendo. El funcionamiento detallado está documentado en la wiki oficial de High Availability de Proxmox.
HA Manager: Recursos, Grupos y Reglas de Afinidad
El componente que orquesta todo es el HA Manager, con una arquitectura de dos piezas: un CRM (Cluster Resource Manager) que actúa como cerebro del clúster y un LRM (Local Resource Manager) en cada nodo que ejecuta las órdenes localmente.
Para poner una VM o un contenedor bajo HA basta con declararlo como recurso HA. Cada recurso tiene un estado solicitado (started, stopped, disabled) y el HA Manager trabaja para reconciliarlo con la realidad, pasando por estados internos como migrate, relocate, recovery, fence o error cuando algo falla.
Los grupos de HA permiten definir en qué nodos puede ejecutarse cada recurso y con qué prioridad: por ejemplo, que la base de datos prefiera los dos nodos con NVMe y solo caiga al tercero como último recurso. Las opciones restricted y nofailback afinan ese comportamiento para evitar migraciones de vuelta innecesarias.
Proxmox VE 9 dio un paso más con las reglas de afinidad y anti-afinidad: ahora puedes indicar que dos VMs deben ejecutarse juntas (afinidad, como una aplicación y su caché) o que nunca deben compartir nodo (anti-afinidad, como dos controladores de dominio o los miembros de un clúster de base de datos). Repasamos esta y otras mejoras en nuestro artículo sobre las novedades de Proxmox VE 9.
Almacenamiento Compartido o Replicado: Ceph, NFS y ZFS
La alta disponibilidad tiene un requisito previo innegociable: el disco de la VM debe ser accesible desde el nodo de destino. Si el disco vive únicamente en el almacenamiento local del nodo caído, no hay nada que recuperar. Existen tres enfoques principales:
Ceph hiperconvergente: cada nodo aporta sus discos locales a un almacenamiento distribuido con replicación síncrona (habitualmente tres copias). No hay pérdida de datos en un failover (RPO cero) y se gestiona desde la propia interfaz de Proxmox. Es la opción que analizamos en profundidad en nuestro artículo sobre Ceph y el almacenamiento distribuido. NFS o iSCSI: una cabina o NAS externo compartido por todos los nodos; sencillo de montar y útil para aprovechar una SAN existente, pero la cabina se convierte en punto único de fallo si no es redundante. ZFS replication: replicación asíncrona programada entre nodos (mínimo cada minuto); en un failover se pierden los últimos cambios no replicados, con un RPO de minutos, pero permite HA en clústeres pequeños sin almacenamiento compartido.
| Criterio | Ceph (hiperconvergente) | NFS / iSCSI (cabina externa) | ZFS Replication |
|---|---|---|---|
| Tipo de replicación | Síncrona (3 réplicas) | Según cabina | Asíncrona programada |
| RPO en failover | 0 (sin pérdida) | 0 (almacenamiento único) | Minutos (último snapshot) |
| Hardware necesario | 3+ nodos con discos locales | Cabina o NAS dedicado | Discos locales con ZFS |
| Punto único de fallo | No | Sí, si la cabina no es redundante | No |
| Escalabilidad | Horizontal, hasta PB | Vertical (límite de la cabina) | Limitada (clústeres pequeños) |
| Complejidad | Media-alta | Baja | Baja |
| Ideal para | Clústeres 3+ nodos, HA exigente | Aprovechar SAN existente | 2-3 nodos, presupuesto ajustado |
Tiempos de Failover y Escenarios de Fallo
¿Cuánto tarda realmente una VM en volver a estar en servicio? Conviene distinguir entre el mantenimiento planificado y el fallo real:
- check_circle Migración en vivo (planificada): cero corte. La memoria de la VM se copia en caliente al nodo de destino y el cambio final es imperceptible para el servicio. Es lo que se usa para parchear nodos sin ventana de mantenimiento.
- check_circle Failover por HA (fallo real): en torno a 2 minutos. Unos 60 segundos de margen de fencing para garantizar que el nodo caído se ha reseteado, más la reubicación de la VM y el arranque del sistema operativo invitado y sus servicios.
Los tres escenarios de fallo típicos se comportan de forma distinta:
- arrow_right Fallo de nodo (hardware, kernel panic, corte eléctrico): el caso de libro. Fencing del nodo y rearranque de sus recursos HA en los supervivientes, según las prioridades de grupo.
- arrow_right Fallo de la red de Corosync: el nodo aislado pierde quorum y se auto-cerca aunque su hardware esté sano; sus VMs se recuperan en el resto. Por eso el enlace redundante de Corosync es tan importante: evita failovers innecesarios.
- arrow_right Fallo del almacenamiento: la HA no puede ayudar si el almacenamiento compartido desaparece, porque las VMs no pueden arrancar en ningún nodo. Ceph tolera la pérdida de discos y de nodos completos; con una cabina única, la redundancia interna de la cabina marca tu límite real de disponibilidad.
Diseño Recomendado para un Clúster de Producción
Con todo lo anterior, el diseño de referencia para un clúster Proxmox de producción se resume en cuatro decisiones:
- check_circle Mínimo 3 nodos con número impar de votos (o 2 nodos + QDevice en entornos pequeños), para que el quorum sobreviva a la caída de cualquier nodo.
- check_circle Redes separadas: una red dedicada para Corosync (con segundo enlace de respaldo), otra para el almacenamiento (Ceph o tráfico NFS/iSCSI) y otra para el tráfico de las VMs y la gestión.
- check_circle Capacidad N+1: cada nodo debe reservar recursos suficientes para absorber las VMs de un nodo caído. Un clúster de tres nodos con la RAM al 90% no puede hacer failover de nada.
- check_circle Almacenamiento acorde al RPO: Ceph o cabina redundante para RPO cero; replicación ZFS si puedes asumir minutos de pérdida a cambio de simplicidad y coste.
HA no sustituye al backup:
La alta disponibilidad protege frente a fallos de hardware, no frente a errores. Un ransomware, un borrado accidental o una corrupción de datos se replican al instante a todas las copias del almacenamiento compartido. Mantén siempre una estrategia de backup independiente (regla 3-2-1) con copias fuera del clúster.
EasyDataHost: Clústeres Proxmox con Ceph en España
En EasyDataHost la alta disponibilidad no es teoría: nuestro cloud se ejecuta sobre clústeres Proxmox VE con almacenamiento Ceph hiperconvergente, redes redundantes y capacidad N+1, en datacenter propio en España con certificación ISO 27001 y conformidad ENS.
- arrow_right Cloud con failover automático incluido: tus VMs se benefician de la HA del clúster y de la replicación síncrona de Ceph sin configurar nada.
- arrow_right Clústeres Proxmox dedicados a medida: diseñamos, desplegamos y operamos clústeres para clientes, con dimensionamiento de quorum, redes separadas, Ceph o ZFS replication y pruebas de failover documentadas.
- arrow_right Soporte 24/7 de ingenieros que administran Proxmox y Ceph en producción a diario, no un call center.
Si estás planificando un clúster nuevo o quieres migrar desde otro hipervisor, contacta con nuestro equipo para un análisis técnico sin compromiso.
Preguntas Frecuentes
¿Cuántos nodos necesita un clúster Proxmox con alta disponibilidad?
Un mínimo de tres, para que ante el fallo de uno los dos restantes conserven la mayoría de votos. Con solo dos servidores, la alternativa soportada es un QDevice en una tercera máquina que aporte el voto de desempate. Para producción se recomiendan tres o más nodos con capacidad N+1.
¿Cuánto tarda el failover de una VM con HA en Proxmox?
En torno a dos minutos: unos 60 segundos de margen de fencing para garantizar que el nodo caído se ha reiniciado, más la reubicación y el arranque del sistema operativo invitado y sus servicios. Para mantenimientos planificados, la migración en vivo mueve la VM sin ningún corte.
¿La alta disponibilidad de Proxmox sustituye al backup?
No. La HA protege frente a fallos de hardware, pero un ransomware, un borrado accidental o una corrupción se replican al instante a todas las copias del almacenamiento compartido. Necesitas una estrategia de backup independiente (regla 3-2-1) con copias fuera del clúster.
Conclusión
La alta disponibilidad de Proxmox VE es madura, gratuita y perfectamente capaz de sostener cargas de producción exigentes, pero solo funciona tan bien como el diseño del clúster que la soporta:
- arrow_right Un clúster Proxmox aporta gestión unificada, migración en vivo y HA automática sin licencias adicionales.
- arrow_right Corosync necesita una red dedicada de baja latencia con enlace redundante; el quorum exige 3 nodos o 2 + QDevice para evitar el split-brain.
- arrow_right El fencing por watchdog garantiza que un nodo caído no siga escribiendo; el failover real ronda los 2 minutos, frente a la migración en vivo sin corte para mantenimientos.
- arrow_right El almacenamiento define el RPO: Ceph síncrono (cero pérdida), NFS/iSCSI según la cabina, ZFS replication asíncrona (minutos).
- arrow_right Diseña con redes separadas y capacidad N+1, y mantén backups independientes: la HA no protege frente a borrados ni ransomware.