Los clusters de tres nodos Proxmox VE aparecen constantemente cuando se habla de virtualización empresarial y alta disponibilidad. La explicación no está en que tres servidores proporcionen mágicamente más rendimiento que dos, sino en algo bastante más básico: el quorum que necesita un sistema distribuido para tomar decisiones de forma segura cuando se produce un fallo. La propia documentación de Proxmox recomienda al menos tres nodos cuando se busca alta disponibilidad con un quorum fiable.
Las claves de los clusters Proxmox de tres nodos en 30 segundos
- Cada nodo aporta normalmente un voto y el cluster necesita mayoría para mantener quorum.
- Con tres nodos, la pérdida de uno deja dos votos disponibles y el cluster conserva la mayoría.
- Dos nodos también son posibles y Proxmox contempla un QDevice externo como tercer voto.
- Tener quorum no significa tener capacidad suficiente para recuperar todas las máquinas virtuales.
- Un diseño HA debe contemplar CPU y RAM N+1, almacenamiento, Corosync, redes, switching, energía y backup.
La distinción es importante porque resulta relativamente sencillo comprar tres servidores, instalar Proxmox VE, crear el cluster y activar recursos de alta disponibilidad (HA). Eso no significa que la infraestructura pueda soportar correctamente la pérdida de uno de esos servidores.
El problema aparece cuando se diseña utilizando prácticamente el 100 % de la CPU y memoria disponibles. Si uno de los hosts deja de funcionar y los otros dos ya están saturados, Proxmox puede disponer de quorum y detectar correctamente el fallo, pero las máquinas virtuales afectadas no tendrán suficientes recursos donde volver a arrancar.
Ese es uno de los motivos por los que el número de nodos es solo una parte del diseño.
El quorum explica por qué tres nodos encajan tan bien
Proxmox VE utiliza Corosync para las comunicaciones del cluster y pmxcfs, su sistema de archivos distribuido para la configuración. Los nodos trabajan mediante un sistema de quorum basado en votos. En una configuración convencional cada nodo aporta un voto.
En un cluster formado por tres servidores la situación básica es sencilla:
| Estado | Nodos disponibles | Votos | ¿Hay mayoría? |
|---|---|---|---|
| Funcionamiento normal | 3 | 3 de 3 | Sí |
| Falla un nodo | 2 | 2 de 3 | Sí |
| Solo queda un nodo | 1 | 1 de 3 | No |
El objetivo del quorum no es aumentar el rendimiento, sino impedir que diferentes partes de un cluster dividido continúen actuando como si cada una tuviera autoridad sobre los mismos recursos.
Este tipo de situaciones puede terminar provocando el conocido split brain, especialmente peligroso cuando diferentes servidores pueden modificar simultáneamente recursos compartidos.
Por eso tres nodos proporcionan una mayoría natural: si desaparece uno, los otros dos todavía pueden ponerse de acuerdo.
¿Entonces un cluster de dos nodos es incorrecto?
No.
Proxmox permite configuraciones de dos nodos y documenta específicamente el uso de QDevice para pequeños clusters que necesitan mayor disponibilidad.
El QDevice proporciona un voto externo sin tener que incorporar necesariamente un tercer servidor completo de virtualización. Proxmox lo recomienda para clusters de dos nodos y, al contrario, desaconseja generalmente añadirlo a clusters que ya tienen un número impar de nodos debido al diferente comportamiento del sistema de votos.
Una arquitectura de dos hosts más QDevice puede tener bastante sentido cuando el coste de un tercer nodo de cómputo no está justificado.
Pero hay que separar nuevamente conceptos: el QDevice ayuda a resolver el quorum, no aporta CPU ni RAM para ejecutar máquinas virtuales.
Si uno de los dos servidores falla, el otro tendrá que asumir las cargas que se decida recuperar. Si no tiene capacidad, disponer del tercer voto no solucionará esa limitación.
El error de utilizar al 100 % los tres servidores
Aquí aparece uno de los aspectos más importantes al dimensionar alta disponibilidad.
Supóngase un cluster con tres servidores y 512 GB de RAM por nodo:
| Nodo | RAM física |
|---|---|
| PVE01 | 512 GB |
| PVE02 | 512 GB |
| PVE03 | 512 GB |
| Total | 1.536 GB |
La plataforma tiene físicamente 1,5 TB de memoria aproximadamente, pero eso no significa que toda pueda asignarse alegremente a las máquinas virtuales si el objetivo es mantener capacidad ante la pérdida completa de un host.
Si cada servidor mantiene 500 GB ocupados y PVE01 falla, quedan únicamente unos 24 GB libres entre los otros dos nodos. Las máquinas que utilizaban los recursos del servidor perdido difícilmente podrán recuperarse allí.
Por eso una arquitectura de alta disponibilidad suele diseñarse considerando capacidad N+1.
En términos sencillos, los recursos restantes deberían ser suficientes para soportar las cargas que deban continuar funcionando cuando desaparezca uno de los nodos.
Eso tampoco significa necesariamente mantener un servidor entero vacío.
Puede distribuirse la capacidad entre todos los nodos mientras se conserva margen agregado suficiente para el escenario de fallo previsto. Además, no todas las máquinas tienen por qué recibir la misma prioridad.
Una organización puede decidir que ERP, bases de datos, controladores de dominio o determinados servicios productivos deben recuperarse primero, mientras que máquinas de desarrollo, laboratorios o servicios secundarios pueden permanecer apagados durante una incidencia.
El dimensionamiento debería realizarse sobre consumo y picos reales, no simplemente sumando las vCPU configuradas en todas las máquinas virtuales.
La memoria suele ser menos flexible. Una plataforma con CPU disponible pero sin RAM suficiente seguirá teniendo problemas para recuperar las cargas.
HA tampoco significa migración en vivo
Hay otra confusión frecuente entre High Availability y Live Migration.
Durante una migración en vivo, el nodo de origen continúa funcionando. Proxmox puede trasladar una máquina virtual hacia otro servidor de manera planificada, por ejemplo para realizar mantenimiento.
Un fallo físico es diferente.
Si un host deja de funcionar inesperadamente, no existe una VM funcionando que pueda trasladarse ordenadamente desde el servidor original. El sistema HA tiene que determinar que el nodo ha fallado, garantizar que no continúa utilizando los recursos y recuperar las cargas protegidas en otro nodo.
La documentación de Proxmox explica que su pila HA utiliza mecanismos de locking y watchdog para permitir la recuperación automática de huéspedes gestionados por HA después de la pérdida o fencing de un nodo.
Por tanto, HA puede reducir y automatizar la recuperación, pero no equivale a cero interrupción.
Las aplicaciones que necesiten continuidad superior deben plantear también la disponibilidad en su propia arquitectura mediante replicación, clustering de bases de datos, balanceadores o múltiples instancias.
Corosync, almacenamiento y red también forman parte de la HA
Tener tres hosts con recursos suficientes todavía no completa el diseño.
Corosync necesita comunicaciones fiables entre los miembros del cluster. Proxmox recomienda una red física dedicada para este tráfico y señala que Corosync necesita principalmente latencia baja y estable, no un ancho de banda especialmente elevado. Una interfaz dedicada de 1 Gbit/s puede ser suficiente en muchos escenarios.
También admite múltiples enlaces de comunicación. La documentación actual contempla hasta ocho redes para Corosync y recomienda que la redundancia real utilice caminos físicos diferentes.
Esto introduce otra pregunta importante: ¿de qué sirve tener tres servidores redundantes si todos dependen de un único switch?
Lo mismo ocurre con el almacenamiento.
Proxmox puede trabajar con diferentes arquitecturas: almacenamiento compartido, NFS, iSCSI, Fibre Channel, Ceph, ZFS y almacenamiento local, entre otras posibilidades. La elección condiciona cómo se realizan las migraciones y cómo puede recuperarse una VM cuando desaparece un nodo.
Para HA, la documentación de Proxmox establece entre sus requisitos el almacenamiento compartido para las máquinas virtuales y contenedores gestionados de esta manera. Existen además diseños basados en almacenamiento distribuido o replicado que deben estudiarse según el escenario.
Ceph merece una mención especial porque tres nodos también aparecen con frecuencia como configuración mínima práctica en despliegues pequeños. Pero que sea posible construir Ceph con tres nodos no significa que tres nodos sean apropiados para cualquier carga. Capacidad útil, número de discos, réplica, red, IOPS, latencia, recuperación y comportamiento degradado deben dimensionarse por separado.
Y después está el backup
Un cluster de tres nodos tampoco sustituye las copias de seguridad.
HA intenta mantener o recuperar servicios cuando falla infraestructura. Un backup responde a problemas diferentes: borrado accidental, corrupción, ransomware, errores administrativos o necesidad de recuperar información de un momento anterior.
Proxmox dispone de Proxmox Backup Server (PBS) para proteger máquinas virtuales y contenedores, pero la estrategia debe seguir definiendo retención, Recovery Point Objective (RPO), Recovery Time Objective (RTO), ubicación de las copias y pruebas periódicas de restauración.
Una plataforma puede tener un excelente HA y una estrategia de backup deficiente, o justo lo contrario.
Por eso al evaluar un cluster de tres nodos resulta más útil abandonar la pregunta de cuántos servidores necesita Proxmox y plantear otra: qué tiene que seguir funcionando cuando uno de los componentes desaparece.
A partir de ahí pueden dimensionarse CPU, RAM, almacenamiento, red y capacidad de recuperación.
Tres nodos son habituales porque proporcionan una arquitectura sencilla para mantener quorum después de perder uno. Pero la alta disponibilidad empieza realmente cuando se calcula qué ocurre después de ese fallo.
Si las cargas críticas no caben en los dos servidores restantes, si todos dependen del mismo switch o si el almacenamiento introduce otro punto único de fallo, tener tres nodos no convierte por sí solo la plataforma en altamente disponible.
Preguntas frecuentes
¿Proxmox necesita obligatoriamente tres nodos?
No. Proxmox VE puede utilizarse con un único servidor y permite clusters de diferente tamaño. Para HA con quorum fiable, Proxmox recomienda al menos tres nodos; en pequeños clusters de dos nodos puede utilizarse un QDevice como voto adicional.
¿Qué ocurre si falla un nodo de un cluster Proxmox de tres servidores?
Los dos nodos restantes conservan la mayoría de votos. Si las máquinas están gestionadas por HA y existen almacenamiento y recursos suficientes, Proxmox puede recuperar las cargas afectadas en los hosts disponibles.
¿Hay que dejar un nodo Proxmox vacío para tener N+1?
No necesariamente. Los recursos pueden distribuirse entre los tres hosts, pero debe existir suficiente capacidad libre agregada para asumir las cargas que se quieran recuperar después de perder un nodo.
¿Un cluster Proxmox de tres nodos necesita Ceph?
No. Ceph es una posibilidad, no un requisito general para crear un cluster Proxmox. La plataforma admite diferentes alternativas de almacenamiento y la elección debe responder a los requisitos de disponibilidad, rendimiento y recuperación.
