Por qué un clúster Proxmox de dos nodos necesita un tercer voto para el quórum
La fase de la emoción: "He montado un clúster, ¿y ahora qué?"
Hay un momento en que todo encaja. Tienes dos máquinas con buenas especificaciones, quizá un NUC junto a un equipo algo más potente, y de repente has montado un clúster. Parece que subes de nivel, porque ahora orquestas infraestructura en lugar de solo ejecutar VMs.
Esa emoción es real. Empiezas a pensar en buenas prácticas, en redundancia, quizá incluso en alta disponibilidad. Ya conoces la regla de que lo ideal son tres nodos, pero dos parece casi lo mismo, ¿verdad?
Ahí empieza la ilusión, porque lo que parece un clúster todavía no se comporta como tal.
El primer aviso: "Necesitas un tercer nodo. En serio."
La respuesta más inmediata va directa al grano: necesitas un tercer nodo para evitar el split brain.
Al principio suena exagerado. Tienes dos máquinas, así que ¿por qué no basta? Porque un clúster depende del consenso, y el número de máquinas por sí solo no te lo da.
En Proxmox, el quórum decide si el clúster puede funcionar, y el quórum exige una mayoría. Con dos nodos, si uno cae no hay mayoría, solo desacuerdo.
Un usuario lo remarca todavía más: un tercer voto, a menudo mediante un QDevice, es "prácticamente obligatorio". Cuando asimilas que el tercer voto hace falta de verdad, la emoción empieza a convertirse en cautela.
El escenario del bloqueo: cuando cae un nodo y todo se para
Esta parte casi nadie la espera. Si tienes un clúster de dos nodos y uno se desconecta, aunque sea por algo inofensivo como un reinicio, el otro nodo puede bloquearte por completo porque no consigue establecer el quórum.
Piénsalo un segundo. Tu "clúster" queda inutilizable porque una máquina se reinició.
El sistema hace exactamente aquello para lo que está diseñado: evitar el split brain, en el que dos nodos actúan por su cuenta y corrompen el estado compartido. En un homelab, sin embargo, resulta brutal. Tú no estás pensando en consenso distribuido; solo intentas que las cosas sigan funcionando, y de repente el sistema juega en tu contra.
El apaño: QDevice y el "falso tercer nodo"
Aquí entra el apaño ingenioso: un QDevice.
En lugar de añadir un tercer servidor completo, puedes añadir un voto ligero que participa en el quórum sin ejecutar cargas de trabajo. No es un nodo completo, pero inclina la balanza.
Por eso alguien comenta de pasada que se le olvidó "volver a configurar mi qdevice", como si fuera una pieza crítica del montaje, que lo es.
Con un QDevice, tu clúster de dos nodos pasa a ser estable en la práctica. Sin él, siempre estás a un reinicio de la confusión. Es el arreglo más pequeño con el mayor impacto, y por algún motivo es el que la mayoría descubre demasiado tarde.
El momento mágico: "Espera… ¿puedo mover VMs en marcha?"
Pese a todos los avisos, hay una razón por la que la gente sigue con los clústeres: cuando funcionan, son increíbles.
La migración en vivo es la función que lo cambia todo. Mover una VM en marcha de un nodo a otro sin tiempo de inactividad parece hacer trampa. Un usuario lo describió como "realmente mágico" cuando separas las cargas de trabajo del hardware. Otro lo dice sin más: "Te va a volar la cabeza". No exageran.
Aquí es donde tu homelab deja de parecer un montón de máquinas y empieza a parecer una plataforma.
El baño de realidad: "¿De verdad necesitas un clúster?"
Luego llega la pregunta incómoda de si realmente necesitas esto.
Una perspectiva devuelve las cosas a la tierra: para la mayoría de la gente, los clústeres en un homelab tienen más que ver con aprender que con necesitarlos. Las configuraciones de alta disponibilidad de verdad (Ceph, HA, actualizaciones sin tiempo de inactividad) son potentes, pero también suman complejidad muy rápido.
Otro usuario apunta a una alternativa: gestionar varios hosts independientes sin clúster, sobre todo si algunos nodos no están siempre encendidos.
Así que la división queda así:
- Clústeres para ganar experiencia y tener funciones avanzadas
- Hosts independientes por sencillez y fiabilidad
Según tus objetivos, una opción puede tener mucho más sentido que la otra.
La restricción oculta: tu nodo más débil lo define todo
Otro detalle sutil pilla a la gente desprevenida: tu clúster solo es tan flexible como su hardware más débil. Un comentario señala que la CPU más antigua del clúster determina qué puede migrar adónde.
Así que tu flamante nodo nuevo no desbloquea capacidades nuevas si tu nodo antiguo no las admite, y la compatibilidad de migración se convierte en un problema de mínimo común denominador.
No es motivo para descartarlo, pero es otro recordatorio de que montar un clúster significa alinear máquinas, además de sumarlas.
Los clústeres resuelven problemas que quizá aún no tienes
Lo que hace tan interesante toda esta situación es lo rápido que la gente se lanza a montar clústeres y lo despacio que se da cuenta de para qué sirven de verdad.
Los clústeres brillan cuando necesitas:
- Alta disponibilidad
- Failover sin cortes
- Mantenimiento sin tiempo de inactividad
Pero si solo ejecutas unos pocos servicios, puede que esas ventajas no compensen la complejidad añadida.
El hilo común de todo esto es que un clúster de dos nodos parece un avance, pero sin quórum es frágil. Añade un tercer voto y se vuelve estable. Añade almacenamiento compartido y HA y se vuelve potente.
Hasta entonces, es una experiencia de aprendizaje disfrazada de infraestructura, y quizá eso es justo lo que tiene que ser.