Por qué casi todos los clústeres de Proxmox tienen tres nodos (y qué no te da el tercero)

Un vistazo en 30 segundos

• Tres nodos no dan más rendimiento que dos. Dan mayoría: cada nodo aporta un voto y, al perder uno, quedan dos de tres. La documentación de Proxmox lo dice sin rodeos: para HA hacen falta al menos tres nodos para un quorum fiable.
• Lo que casi nadie sabe: cuatro nodos no mejoran a tres. Toleran exactamente la misma caída —una— y añaden un modo de fallo nuevo, el empate a dos, que deja el clúster entero en solo lectura.
• Perder el quorum no apaga las máquinas, pero congela el clúster: pasa a solo lectura. Y si hay HA activo, el nodo aislado no puede resetear su watchdog y se reinicia solo en unos 60 segundos.
• Dos nodos son perfectamente válidos con un QDevice que aporte el tercer voto. Resuelve el quorum; no aporta ni un gigabyte de RAM para arrancar las máquinas del otro.
• Y ojo con ponerlo donde no toca: Proxmox desaconseja el QDevice en clústeres con número impar de nodos.
• La pila de HA tarda del orden de dos minutos entre detectar el fallo y tener los servicios arriba. Es rapidísimo comparado con una intervención manual, y no es cero.
• Con tres nodos y Ceph por defecto —size 3, min_size 2— hay una réplica por nodo. Al caer uno el dato sigue accesible, pero no hay dónde recrear la tercera copia hasta que vuelva.
• Tres nodos resuelven el quorum. La capacidad, la red, el almacenamiento y las copias son cuatro problemas aparte, y ninguno se arregla añadiendo el tercer servidor.

---

Si miras diez presupuestos de virtualización con Proxmox, nueve traen tres nodos. Pasa tanto que ya casi nadie pregunta por qué, y cuando se pregunta la respuesta suele ser un «es lo recomendado» que no explica nada.

La razón no tiene que ver con el rendimiento. Tres servidores no rinden más que dos por arte de magia. Tiene que ver con algo mucho más básico: cómo decide un sistema distribuido quién manda cuando se rompe la comunicación.

Y una vez entendido eso, aparece la parte que de verdad importa, que es todo lo que tres nodos no resuelven.

La aritmética del quorum

Proxmox VE usa Corosync para la comunicación entre los miembros del clúster y pmxcfs, un sistema de ficheros distribuido, para la configuración. Cada nodo aporta, por defecto, un voto. Para que el clúster pueda cambiar algo necesita mayoría.

El quorum no existe para ir más rápido. Existe para impedir que dos mitades de un clúster partido sigan actuando cada una como si tuviera autoridad sobre los mismos recursos y los mismos discos. Ese escenario —dos nodos escribiendo a la vez sobre la misma máquina virtual convencidos de que el otro está muerto— es el split brain, y termina en corrupción de datos.

Por eso el número impar. Tres da una mayoría natural: si desaparece uno, los otros dos todavía pueden ponerse de acuerdo.

Por qué cuatro nodos no son mejores que tres

Esta es la parte contraintuitiva, y la razón por la que verás clústeres de tres, cinco o siete, pero rara vez de cuatro por decisión de diseño.

Con cuatro nodos, la mayoría son tres votos. Si cae uno, quedan tres y el clúster sigue: exactamente igual que con tres nodos. Pero si la red se parte por la mitad —dos nodos a cada lado, algo perfectamente posible con dos switches o dos armarios—, ninguno de los dos lados tiene mayoría y los dos se quedan en solo lectura. Con tres nodos ese empate no puede darse.

Léela por la columna de la derecha: pasar de tres a cuatro nodos añade capacidad de cómputo, que puede ser justo lo que necesitas, pero no añade ni una caída más de tolerancia y sí un escenario nuevo de bloqueo. Si vas a crecer, el salto que compra tolerancia es a cinco.

Qué pasa exactamente el minuto en que se pierde el quorum

Aquí hay dos comportamientos que conviene conocer antes de que ocurran, porque el primero sorprende y el segundo asusta si no se espera.

El clúster pasa a solo lectura. No se apagan las máquinas: las que están corriendo siguen corriendo. Lo que se congela es la capacidad de cambiar cosas. No se pueden arrancar máquinas nuevas, ni editar configuraciones, ni migrar. Si alguna vez te has encontrado una interfaz de Proxmox que responde pero no deja hacer nada, casi siempre es esto.

Y si hay HA activo, el nodo aislado se reinicia solo. La pila de alta disponibilidad se apoya en un watchdog que hay que ir reseteando periódicamente. Un nodo sin quorum no puede resetearlo, así que el temporizador expira y reinicia el servidor entero en torno a los 60 segundos. No es un fallo: es el auto-fencing, la garantía de que ese nodo ha dejado de tocar el almacenamiento compartido antes de que sus máquinas se arranquen en otro sitio.

Ese es también el motivo de que la recuperación no sea instantánea. La propia documentación habla de tiempos típicos de detección de error y conmutación del orden de dos minutos. Es una barbaridad de rápido comparado con que alguien reciba una alerta y se conecte, y no es cero interrupción: lo desarrollamos en su momento al explicar qué significa de verdad que un clúster aguante.

Dos nodos y un QDevice: cuándo tiene sentido

Un clúster de dos nodos no está mal por definición. Está incompleto: con dos votos, la caída de uno deja al superviviente en minoría y sin poder hacer nada.

La solución que documenta Proxmox es el QDevice: un tercer voto que aporta una máquina externa, sin tener que comprar un tercer servidor de virtualización. Puede ser un equipo pequeño, una máquina virtual en otra ubicación o cualquier sistema Linux modesto con conectividad a los dos nodos.

Dos advertencias, y las dos importan:

Primera: el QDevice resuelve el quorum, no la capacidad. Si cae uno de los dos servidores, el que queda tiene que asumir lo que decidas recuperar. Si no le sobra CPU y memoria, el tercer voto no arranca nada. Es el error de diseño más repetido con esta arquitectura.

Segunda: no lo pongas en clústeres impares. La documentación lo desaconseja explícitamente en clústeres con número impar de nodos, porque cambia el comportamiento del sistema de votos y no aporta nada donde la mayoría ya está garantizada por aritmética.

Lo que tres nodos no te dan

Aquí es donde la conversación se pone interesante, porque es la parte que no se resuelve comprando servidores.

No te dan capacidad

Es el fallo de diseño que más nos encontramos: tres nodos con 512 GB cada uno, 1,5 TB en total, y alguien reparte 500 GB de máquinas en cada uno. En papel, perfecto: sobra memoria. En la práctica, el día que cae un nodo hay medio terabyte de máquinas buscando sitio en 24 GB libres.

Tener quorum no es tener sitio. Proxmox detectará el fallo correctamente, decidirá correctamente que hay que arrancar esas máquinas y no podrá. La regla es aritmética: con N nodos, el uso sostenible por nodo es (N-1)/N, o sea un 66 % con tres. Y a diferencia de vSphere, aquí nadie te frena si te la saltas — es una de las cosas que hay que tener claras antes de decidir una migración.

Dos matices prácticos, para que la regla no se convierta en dogma:

• No hace falta un servidor entero vacío. El margen se reparte entre los tres; lo que tiene que existir es la capacidad agregada.
• No todo tiene que volver. Se puede decidir por escrito que el ERP, la base de datos y los controladores de dominio arrancan primero y que los entornos de desarrollo se quedan apagados durante la incidencia. Eso es un plan; descubrirlo el día del fallo, no.

Y una advertencia sobre cómo se hace la cuenta: se hace con consumo y picos reales, no sumando vCPU configuradas. La CPU se puede sobrecomprometer con cabeza; la memoria es mucho menos indulgente.

No te dan red

¿De qué sirven tres servidores redundantes si los tres cuelgan del mismo switch?

Corosync necesita una red fiable, y lo que le importa no es el ancho de banda sino la latencia baja y estable: la documentación pide menos de 5 milisegundos, recomienda una tarjeta de red física dedicada para el tráfico del clúster y aclara que 1 Gbit suele ser suficiente. Los nodos deben poder hablar entre ellos por los puertos UDP 5405 a 5412, y Corosync admite hasta ocho enlaces para redundancia.

La palabra clave en esa redundancia es física: dos enlaces que pasan por el mismo switch, por la misma bandeja o por el mismo SAI son un enlace con dos nombres.

No te dan almacenamiento

La pila de HA de Proxmox exige almacenamiento compartido para las máquinas y contenedores que gestione. Ahí caben muchas arquitecturas —NFS, iSCSI, Fibre Channel, Ceph, replicación ZFS— y cada una cambia lo que ocurre cuando desaparece un nodo.

Si ese almacenamiento es una única cabina sin redundancia, has trasladado el punto único de fallo del servidor al armario de al lado.

Con Ceph hay un matiz que conviene entender antes de montarlo en tres nodos, y que es consecuencia directa de los valores por defecto: size 3 y min_size 2 significan tres copias del dato y un mínimo de dos para permitir escritura. Con tres nodos, eso es una copia por nodo. Cuando cae uno, el dato sigue disponible con dos copias y el clúster sigue escribiendo, pero no hay un cuarto sitio donde recrear la tercera copia: Ceph se queda degradado hasta que el nodo vuelva. Funciona, pero durante ese tiempo estás a una avería de quedarte por debajo del mínimo.

De ahí dos recomendaciones de la propia documentación que en tres nodos no son opcionales: SSD en instalaciones pequeñas, para que la recuperación sea corta y no coincida con otro fallo, y red exclusiva de 10 Gbps o más para Ceph, entre otras cosas porque su tráfico interfiere con servicios sensibles a la latencia como el propio Corosync. Lo contamos con más detalle al hablar de Ceph en un cloud privado.

Y nunca, bajo ninguna presión, min_size 1: la documentación avisa de que permitir E/S con una sola réplica lleva a pérdida de datos y objetos irrecuperables.

No te dan copias de seguridad

Un clúster de tres nodos no es una copia de seguridad. Son dos problemas distintos.

La alta disponibilidad responde a «se ha roto un servidor». Las copias responden a «alguien borró la base de datos», «un cifrado nos ha comido los ficheros» o «necesito los datos del martes pasado». Un clúster impecable replica el borrado accidental a la misma velocidad a la que replica todo lo demás.

Con Proxmox Backup Server la parte técnica está resuelta, pero sigue habiendo que decidir retención, RPO y RTO, dónde vive la copia fuera del clúster y —lo que casi nunca se hace— probar la restauración con cronómetro. Una plataforma puede tener un HA excelente y una estrategia de copias lamentable, o justo lo contrario.

La pregunta correcta no es cuántos nodos

Cuando alguien nos pregunta si necesita tres nodos, la conversación útil empieza al darle la vuelta: qué tiene que seguir funcionando cuando desaparezca uno de los componentes, y cuánto tiempo puede estar sin funcionar.

De esa respuesta salen todas las demás. Cuántas máquinas hay que poder arrancar y cuánta memoria consumen de verdad; cuánto margen hay que dejar libre; si el almacenamiento aguanta la pérdida de un nodo o solo la de un disco; si la red tiene dos caminos físicos o dos cables por el mismo sitio; y cuánto se tarda en volver desde una copia si todo lo anterior falla a la vez.

Tres nodos son tan habituales porque resuelven de forma barata y elegante el primer problema de la lista: mantener la mayoría después de perder uno. Es un buen punto de partida y un mal punto final.

Si estás dimensionando una plataforma —tres nodos, dos con QDevice o cinco porque quieres aguantar dos caídas— cuéntanos qué tiene que seguir en pie y hacemos la cuenta contigo antes de que la haga la realidad. Cómo lo montamos y operamos nosotros está en Proxmox en producción.

Preguntas frecuentes

¿Proxmox necesita obligatoriamente tres nodos?

No. Proxmox VE funciona en un solo servidor y admite clústeres de cualquier tamaño. Lo que necesita tres nodos es la alta disponibilidad con un quorum fiable, que es lo que recomienda la documentación oficial. Para dos nodos existe la alternativa del QDevice como tercer voto.

¿Es mejor un clúster de cuatro nodos que uno de tres?

Para capacidad, sí. Para tolerancia a fallos, no: los dos aguantan la caída de un nodo. Y cuatro añade el riesgo de una partición dos a dos en la que ningún lado tiene mayoría y todo el clúster queda en solo lectura. Si el objetivo es tolerar dos caídas, el salto correcto es a cinco.

¿Qué pasa si un clúster de Proxmox pierde el quorum?

Pasa a modo de solo lectura: las máquinas encendidas siguen funcionando, pero no se puede cambiar la configuración, arrancar máquinas ni migrar. Además, si hay HA configurado, el nodo que se ha quedado sin quorum no puede resetear su watchdog y se reinicia solo al cabo de aproximadamente un minuto.

¿Un QDevice sustituye a un tercer servidor?

Solo a efectos de votos. Aporta el tercer voto que da mayoría, pero no aporta CPU ni memoria, así que cuando cae uno de los dos nodos el superviviente tiene que poder con lo que haya que arrancar. Y no conviene añadirlo a clústeres con número impar de nodos, porque la documentación lo desaconseja.

¿Hay que dejar un nodo vacío para tener N+1?

No. El margen se reparte entre todos los nodos; lo que debe existir es capacidad agregada suficiente para las cargas que quieras recuperar. Con tres nodos, eso significa no pasar de dos tercios de uso por nodo si quieres que todo vuelva a arrancar.

¿Necesito Ceph en un clúster de tres nodos?

No es obligatorio: Proxmox admite NFS, iSCSI, Fibre Channel, replicación ZFS y almacenamiento local. Ceph es una buena opción para tres nodos, con dos condiciones que la documentación deja claras: discos SSD para que la recuperación sea rápida y una red dedicada de 10 Gbps o más, separada del tráfico de Corosync.

Fuentes

• Proxmox VE, Cluster Manager (pvecm) — los tres nodos para un quorum fiable, el sistema de votos, el modo de solo lectura al perder quorum, el QDevice y los requisitos de red de Corosync.
• Proxmox VE, High Availability — requisitos de HA, funcionamiento del watchdog y del auto-fencing, y los tiempos típicos de detección y conmutación.
• Proxmox VE, Deploy Hyper-Converged Ceph Cluster — mínimo de tres servidores, valores por defecto de size y min_size, la advertencia sobre min_size 1, el consejo de usar SSD en instalaciones pequeñas y la recomendación de red exclusiva de 10 Gbps.