Clustering en Proxmox VE 9 para producción: quórum, corosync y QDevice sin dramas

Montar un clúster de Proxmox VE es engañosamente fácil. Dos comandos, pvecm create en un nodo y pvecm add en el otro, y ya tienes una interfaz única que gestiona varias máquinas. El problema es que ese «funciona» de laboratorio no es lo mismo que un clúster production-grade que aguanta la caída de un nodo un martes a las tres de la tarde sin que se te caigan las VMs ni, peor aún, sin que se te corrompa la configuración. La diferencia entre una cosa y la otra está en entender qué pasa por debajo: cómo se comunican los nodos, qué es el quórum y por qué el clúster decide volverse de solo lectura justo cuando más lo necesitas.

Este es el tutorial que me habría ahorrado un par de sustos en producción. Vamos a ver la anatomía real de un clúster Proxmox VE 9, cómo funciona el quórum y por qué importa tanto, el eterno problema de los clústeres de dos nodos y su solución con QDevice, cómo tiene que ser la red de corosync para no darte disgustos, y el paso a paso con los comandos pvecm que de verdad se usan. Todo aplicado a la rama 9.x, que corre sobre Debian 13 «Trixie» y mantiene el mismo stack de clustering que ya conocías, con corosync 3 y knet como transporte. Si vienes de VMware quizá te interese antes repasar las alternativas a VMware en 2026 y el almacenamiento en Proxmox, porque el storage condiciona cómo montas la alta disponibilidad.

Anatomía de un clúster: corosync y pmxcfs

Un clúster de Proxmox se sostiene sobre dos piezas que trabajan juntas pero hacen cosas muy distintas. Confundirlas es el primer paso para diagnosticar mal un problema.

Corosync es la capa de comunicación y membresía. Es un motor de group communication que se encarga de que todos los nodos sepan en tiempo real quién está vivo, quién ha desaparecido y quién acaba de unirse. Envía latidos (heartbeats) constantes entre nodos, mantiene la lista de miembros del clúster y, sobre todo, calcula el quórum. Corosync no sabe nada de VMs ni de discos: su único trabajo es responder a la pregunta «¿qué nodos forman ahora mismo el clúster y tenemos mayoría?». En Proxmox VE 9 se usa corosync 3 con el transporte knet (Kronosnet), que es lo que permite tener varios enlaces redundantes de forma nativa.

pmxcfs (Proxmox Cluster File System) es lo que ves montado en /etc/pve. Es un sistema de ficheros especial, respaldado por una base de datos, que replica la configuración del clúster a todos los nodos en tiempo real. Cuando editas la definición de una VM, un usuario, un almacenamiento o una regla de firewall, escribes en /etc/pve de un nodo y pmxcfs se encarga de propagarlo instantáneamente al resto usando corosync como canal de transporte. Por eso desde cualquier nodo del clúster ves exactamente la misma configuración: no hay un «nodo maestro» con la verdad; la verdad está replicada.

Y aquí viene la conexión crítica entre ambos: pmxcfs solo permite escrituras si corosync dice que hay quórum. Si pierdes la mayoría, pmxcfs monta /etc/pve en modo solo lectura. Esa decisión, que a primera vista parece un fastidio, es justo lo que evita que dos mitades de un clúster partido escriban configuraciones contradictorias y te destrocen los datos.

Quórum: la regla que protege tus datos

El quórum es el concepto que separa a quien sabe operar un clúster de quien solo sabe crearlo. La idea es sencilla y viene directa de la teoría de sistemas distribuidos: para tomar decisiones (arrancar una VM, moverla, cambiar configuración) tiene que haber de acuerdo una mayoría de votos. Cada nodo aporta normalmente un voto. La mayoría se calcula como la mitad de los votos esperados más uno.

¿Por qué la mayoría y no, por ejemplo, «que estén al menos dos»? Porque la mayoría es la única cifra que garantiza que no puede haber dos grupos con quórum a la vez. Si la red se parte en dos y cada trozo cree que él es el clúster de verdad, tendrías el clásico split-brain: ambos lados arrancando las mismas VMs sobre el mismo disco compartido, cada uno pisando al otro, corrupción garantizada. Con la regla de la mayoría eso es imposible por aritmética: solo un lado puede tener más de la mitad de los votos.

La documentación oficial lo dice sin rodeos: «en caso de partición de red, los cambios de estado requieren que una mayoría de nodos estén en línea. El clúster pasa a modo de solo lectura si pierde el quórum». Ese modo de solo lectura significa que /etc/pve deja de aceptar escrituras. Las VMs que ya estaban corriendo siguen funcionando —no se apagan solas— pero no puedes cambiar configuración, ni arrancar máquinas nuevas, ni actuar la HA. El clúster se congela para protegerte de ti mismo.

Veamos la aritmética con una tabla, porque es lo que de verdad debes tener claro antes de decidir cuántos nodos montas:

Fíjate en el detalle que casi nadie mira: un clúster de cuatro nodos tolera exactamente las mismas caídas (una) que uno de tres, pero tiene más superficie para fallar. Por eso la recomendación clásica es número impar de nodos. Con impar, cada voto que añades sirve para algo; con par, el nodo extra no te da más tolerancia y sí te introduce el riesgo de empate 50/50 al partirse la red.

Puedes ver el estado del quórum en cualquier momento con pvecm status. Esta es la parte que hay que saber leer:

pvecm status

# Quorum information
# ------------------
# Date:             Sat Jul 19 09:12:44 2026
# Quorum provider:  corosync_votequorum
# Nodes:            3
# Node ID:          0x00000001
# Ring ID:          1.5c
# Quorate:          Yes
#
# Votequorum information
# ----------------------
# Expected votes:   3
# Highest expected: 3
# Total votes:      3
# Quorum:           2
# Flags:            Quorate
#
# Membership information
# ----------------------
#     Nodeid      Votes Name
# 0x00000001          1 pve01 (local)
# 0x00000002          1 pve02
# 0x00000003          1 pve03

Las líneas que importan: Quorate: Yes te dice que el clúster tiene mayoría y acepta escrituras. Expected votes es cuántos votos espera ver el clúster (3), Total votes cuántos ve ahora mismo (3) y Quorum el mínimo para operar (2). Si un nodo se cae, Total votes baja a 2, sigue siendo >= 2, y el clúster aguanta. Si se caen dos, bajas a 1, pierdes quórum y /etc/pve se vuelve de solo lectura.

El drama de los clústeres de dos nodos

Aquí está la trampa en la que cae medio mundo. Montas dos servidores porque es lo que tienes, haces el clúster, y todo va bien... hasta que uno se cae o se corta el enlace entre ellos. Con dos nodos hay dos votos y el quórum exige dos. Si pierdes un nodo, te quedas con un voto de dos: no hay mayoría, pierdes quórum, y el nodo superviviente se queda de solo lectura. Justo el nodo que sigue vivo, el que debería seguir dando servicio, es incapaz de arrancar nada nuevo ni de actuar la HA. Un clúster de dos nodos, sin más, no tolera ni una sola caída sin bloquearse.

La razón es la misma de siempre: con dos nodos y una partición de red, cada uno se ve a sí mismo con un voto y no puede distinguir «el otro se ha muerto» de «el otro sigue vivo pero no lo veo». Si dejáramos que un solo voto operase, ambos lados actuarían a la vez y tendríamos split-brain. La aritmética del quórum lo impide, pero al precio de bloquear todo.

La solución no es forzar two_node: 1 en la configuración y cruzar los dedos (eso relaja la protección y es jugar con fuego en producción). La solución correcta es el QDevice: un tercer voto que vive fuera de los dos nodos.

QDevice: el tercer voto que arregla el problema del par

Un QDevice es un árbitro externo. Coges una máquina cualquiera que no sea nodo del clúster —una VM ligera, una Raspberry Pi decente, un servidor de gestión que ya tengas— y le instalas el demonio corosync-qnetd. Ese demonio ofrece un voto adicional al clúster a través de la red. Los nodos, por su parte, ejecutan corosync-qdevice, que es el cliente que habla con el árbitro. La comunicación va por TCP en el puerto 5403.

Con esto, un clúster de dos nodos pasa a tener tres votos: uno por nodo más uno del QDevice. Ahora el quórum es 2 y sí puedes perder un nodo entero (o el enlace a él) manteniendo la mayoría, porque el nodo superviviente más el árbitro suman dos. El QDevice usa por defecto el algoritmo ffsplit (fifty-fifty split), pensado justo para desempatar cuando el clúster se parte en dos mitades iguales: concede su voto al lado que decida el árbitro, y ese lado gana.

El despliegue es directo. Primero, en el host testigo externo:

# En el host testigo (NO es nodo del clúster)
apt update
apt install corosync-qnetd

Después, en todos y cada uno de los nodos del clúster:

# En cada nodo del clúster
apt update
apt install corosync-qdevice

Y finalmente, desde un nodo del clúster (una sola vez), lanzas la configuración apuntando a la IP del testigo. Proxmox se encarga de establecer la confianza SSH, repartir certificados y arrancar el servicio en todos los nodos:

# Desde un nodo cualquiera del clúster, apuntando al testigo
pvecm qdevice setup 10.10.30.9

Tras esto, pvecm status muestra la línea del QDevice en la membresía y el flag Qdevice en el quórum:

pvecm status

# Votequorum information
# ----------------------
# Expected votes:   3
# Highest expected: 3
# Total votes:      3
# Quorum:           2
# Flags:            Quorate Qdevice
#
# Membership information
# ----------------------
#     Nodeid      Votes    Qdevice Name
# 0x00000001          1    A,V,NMW pve01 (local)
# 0x00000002          1    A,V,NMW pve02
# 0x00000000          1            Qdevice

Un matiz que la gente olvida: el QDevice está pensado para clústeres de número par de nodos (típicamente dos). Para clústeres con número impar de nodos no se recomienda, porque ya tienen mayoría natural y meter un árbitro solo añade complejidad y un punto más de fallo. Y ojo con el mantenimiento: si tienes QDevice y quieres añadir o quitar un nodo, primero hay que retirar el QDevice, hacer el cambio, y volver a configurarlo cuando tengas de nuevo número par. No lo dejes puesto mientras reconfiguras la membresía.

La red de corosync: baja latencia y redundancia

Si hay una sola cosa que te llevas de este artículo, que sea esta: corosync necesita una red dedicada, de baja latencia y redundante. La mayoría de los desastres de clúster que he visto no vienen de un fallo de hardware, sino de meter el tráfico de corosync por la misma red que las VMs y el almacenamiento, y ahogarlo.

Corosync es extremadamente sensible a la latencia porque depende de latidos que deben llegar dentro de una ventana temporal muy ajustada. La recomendación oficial es mantener latencias por debajo de 5 milisegundos, valores de LAN. Si un backup nocturno o una migración de VMs satura el enlace y los latidos de corosync empiezan a llegar tarde, corosync interpreta que un nodo ha desaparecido, lo expulsa, recalcula el quórum... y puedes acabar con una pérdida de quórum espuria: el hardware está perfecto, pero la red congestionada ha hecho que el clúster crea que se ha roto. En producción eso puede disparar reinicios de HA innecesarios.

Las reglas de oro para la red de corosync:

• Sepárala del tráfico de VMs y de storage. Corosync usa muy poco ancho de banda, pero exige latencia baja y constante. Comparte NIC con un backup de 400 MB/s y lo estás pidiendo a gritos.
• Dale su propia NIC física y su propia VLAN. Idealmente una interfaz dedicada solo a corosync, no una subinterfaz de la que usa Ceph.
• Hazla redundante. knet soporta hasta 8 enlaces (link0, link1, ...). Con dos redes físicas independientes, corosync conmuta solo entre ellas si una falla, sin perder el clúster.
• Nada de WAN. Corosync no está pensado para cruzar internet ni enlaces de alta latencia. Un clúster estirado entre datacenters por WAN es una fuente inagotable de problemas.

Para la redundancia, defines los enlaces al crear el clúster. Cada nodo tendrá una IP en la red principal de corosync (link0) y otra en la red secundaria (link1), en rangos y switches físicamente distintos:

# link0 = red corosync primaria (p.ej. 10.10.10.0/24)
# link1 = red corosync secundaria e independiente (10.10.20.0/24)
pvecm create PROD-CLUSTER --link0 10.10.10.1 --link1 10.10.20.1

Puedes comprobar el estado de los enlaces en cualquier momento con corosync-cfgtool -s, que te dice qué links están activos y a qué nodos ve cada uno:

corosync-cfgtool -s

# Local node ID 1, transport knet
# LINK ID 0 udp
#     addr    = 10.10.10.1
#     status:
#         nodeid:   1:    localhost
#         nodeid:   2:    connected
#         nodeid:   3:    connected
# LINK ID 1 udp
#     addr    = 10.10.20.1
#     status:
#         nodeid:   1:    localhost
#         nodeid:   2:    connected
#         nodeid:   3:    connected

A nivel de firewall, corosync se comunica por UDP en los puertos 5405 a 5412 entre todos los nodos. Esta es la tabla de puertos que tienes que dejar abiertos entre nodos del clúster:

Crear el clúster paso a paso

Con la red clara, la creación es la parte fácil. Antes de empezar, verifica lo evidente: todos los nodos con la misma versión de PVE 9, relojes sincronizados por NTP, resolución de nombres funcionando (cada nodo debe resolver a los demás por su hostname) y conectividad por los enlaces de corosync.

Paso 1: crear el clúster en el primer nodo. Este nodo no puede tener ya un clúster montado. El nombre es solo identificativo:

# En pve01
pvecm create PROD-CLUSTER --link0 10.10.10.1 --link1 10.10.20.1

Paso 2: comprobar que el nodo se ve a sí mismo con quórum. Un clúster de un solo nodo es quorate por definición (1 voto de 1):

pvecm status

Paso 3: unir el resto de nodos. Esto se ejecuta en el nodo que quieres añadir, no en el primero. Le indicas la IP de corosync de un nodo que ya esté en el clúster y sus propios enlaces. Importante: el nodo que se une no puede tener VMs ni contenedores, porque su /etc/pve se va a sobrescribir con el del clúster, y cualquier conflicto de VMID es un problema. Instala limpio y únelo antes de crear nada:

# En pve02 (el nodo que se une)
pvecm add 10.10.10.1 --link0 10.10.10.2 --link1 10.10.20.2

# En pve03
pvecm add 10.10.10.1 --link0 10.10.10.3 --link1 10.10.20.3

Durante el pvecm add se te pedirá aceptar la huella SSH del nodo destino y la contraseña de root del clúster. El proceso copia la configuración, arranca corosync con la nueva membresía y reinicia el servicio de pmxcfs.

Paso 4: verificar la membresía completa. Cuando estén todos, pvecm nodes te lista los miembros y pvecm status te confirma el quórum:

pvecm nodes

# Membership information
# ----------------------
#     Nodeid      Votes Name
#          1          1 pve01 (local)
#          2          1 pve02
#          3          1 pve03

Con tres nodos viéndose y Quorate: Yes en el status, ya tienes un clúster funcional. Ahora, para que sea production-grade, quedan los detalles.

Buenas prácticas production-grade

Lo que separa un clúster de laboratorio de uno que aguanta producción real no es la configuración inicial, sino la disciplina alrededor. Estas son las prácticas que aplico sin excepción:

• Número impar de nodos. Tres, cinco, siete. Con impar cada voto suma tolerancia real y evitas empates al partirse la red. Si te obligan a tener par, mete un QDevice como voto de desempate.
• Red de corosync dedicada y redundante. Ya insistido arriba, pero es el punto número uno. NIC propia, VLAN propia, al menos link0 y link1 por switches distintos.
• Latencia por debajo de 5 ms entre todos los nodos por la red de corosync, medida en condiciones de carga real, no en un momento de calma.
• Relojes sincronizados con NTP. Todos los nodos apuntando a las mismas fuentes NTP. Un desfase de reloj entre nodos genera problemas sutiles en certificados, logs y coordinación de servicios.
• No mezcles versiones. Todos los nodos en la misma versión de PVE 9. Las actualizaciones se hacen nodo a nodo, drenando primero las VMs, pero el estado «mezclado» es transitorio, no permanente.
• Certificados y confianza sanas. pmxcfs y la API dependen de los certificados del clúster; no los toques a mano salvo que sepas exactamente qué haces.
• Suscripción alineada. En un clúster de producción todos los nodos deberían tener el mismo nivel de suscripción y el repositorio enterprise, para recibir las actualizaciones probadas de la rama estable.

Sobre la sincronización horaria, en Debian 13 basta con verificar que el servicio de tiempo está activo y sincronizado en cada nodo:

timedatectl status
# comprueba:  System clock synchronized: yes
#             NTP service: active

# Con chrony instalado, ver las fuentes y el desfase:
chronyc tracking

Añadir y quitar nodos con seguridad

Añadir nodos ya lo hemos visto: pvecm add desde el nodo entrante, siempre limpio y sin VMs. Quitar nodos es donde se cometen los errores más caros, porque hacerlo mal deja residuos que envenenan el clúster.

La secuencia correcta para eliminar un nodo es:

1. Migra o elimina todas las VMs y contenedores del nodo que vas a retirar. No debe quedar nada suyo en el clúster.
2. Apaga el nodo de forma definitiva. No debe volver a arrancar con esa identidad. Este paso es obligatorio antes del delnode.
3. Desde otro nodo del clúster, ejecuta el borrado por nombre:

# Desde un nodo que SÍ sigue en el clúster, con el nodo a borrar YA apagado
pvecm delnode pve03

La regla de oro, subrayada en la documentación oficial: un nodo eliminado no puede reunirse al clúster con el mismo nombre o IP sin reinstalar Proxmox desde cero. El nodo retirado conserva en su disco la información del viejo clúster; si lo enchufas otra vez tal cual, corrompes el estado. Si necesitas reincorporarlo, formatea, reinstala PVE limpio, y únelo como nodo nuevo.

El error clásico —y demoledor— es apagar un nodo y no hacer pvecm delnode. El clúster sigue esperando su voto: Expected votes no baja, así que ahora necesitas más nodos vivos de los que crees para mantener quórum. Un clúster de tres al que le arrancas un nodo del rack sin borrarlo se comporta como uno de tres al que se le ha caído un nodo, cuando debería comportarse como uno de dos. La membresía tiene que reflejar la realidad.

Escalado: hasta cuántos nodos

No hay un límite duro codificado para el número de nodos. Proxmox documenta que en la práctica el techo lo pone el rendimiento del hardware y, sobre todo, de la red de corosync, y que hay reportes de clústeres con más de 50 nodos en producción sobre hardware empresarial de gama alta. Dicho esto, cuanto más grande es el clúster, más exigente se vuelve corosync con la latencia y la calidad de la red, porque el volumen de mensajería de membresía crece.

Mi consejo práctico: para la mayoría de instalaciones, clústeres de entre 3 y 12 nodos son el punto dulce, fáciles de razonar y de mantener. Si necesitas más, cuida la red de corosync como si fuera oro, monitoriza la latencia de forma continua y valora particionar en varios clústeres más pequeños en lugar de uno gigante. Un clúster de 30 nodos con una red de corosync mediocre es mucho más frágil que dos de 15 con red impecable.

Caveats y trampas que muerden en producción

Recopilo aquí los errores que te van a costar una noche en pie si no los evitas:

• Corosync sobre red congestionada. El fallo número uno. Latidos que llegan tarde por saturación provocan pérdida de quórum espuria y reinicios de HA con el hardware perfectamente sano. Red dedicada, siempre.
• Relojes desincronizados. Sin NTP común, aparecen problemas raros de certificados, autenticación y logs que no cuadran. Es de los fallos más difíciles de diagnosticar porque nada apunta directamente al reloj.
• Quitar nodos sin pvecm delnode. Deja el voto fantasma en Expected votes y te come el margen de tolerancia a fallos sin que te enteres.
• Reutilizar nombres o IDs de nodo. Reincorporar un nodo viejo con el mismo hostname sin reinstalar corrompe el estado del clúster. Nombre y nodeid nuevos, y reinstalación limpia.
• Unir un nodo con VMs ya creadas. El pvecm add sobrescribe /etc/pve; los VMID en conflicto son un problema. Únelo vacío.
• Clúster sobre WAN. Corosync no perdona la latencia ni los cortes de un enlace de internet. Para varios sitios, monta clústeres independientes por sitio y replica entre ellos por otras vías, no estires un único clúster.
• Editar corosync.conf a mano sin incrementar config_version. Si tocas la configuración de corosync (por ejemplo para añadir un link), tienes que subir el número de versión o los nodos no aceptarán el cambio de forma consistente.

Diagnóstico rápido: los comandos que salvan la noche

Cuando algo va mal, estos son los comandos por los que empiezo, en este orden. Primero, el estado global del quórum y la membresía:

pvecm status      # quórum, votos, flags, miembros
pvecm nodes       # lista rápida de nodos y votos

Después, el estado de los enlaces de corosync, para ver si el problema es de red:

corosync-cfgtool -s   # links activos y conectividad por nodo

Y si sospecho que corosync está teniendo problemas de comunicación (latidos perdidos, reformaciones de membresía), voy directo a sus logs:

journalctl -u corosync -b        # log de corosync desde el último arranque
journalctl -u pve-cluster -b     # log de pmxcfs (/etc/pve)

Un caso especial: si has perdido quórum a propósito (por ejemplo, mantenimiento planificado con varios nodos apagados) y necesitas que un nodo superviviente vuelva a ser operable temporalmente, puedes bajar los votos esperados a mano. Es una medida de emergencia, con el clúster degradado y sabiendo lo que haces, nunca una práctica habitual:

# EMERGENCIA: forzar votos esperados a 1 en un nodo aislado.
# Solo con el resto de nodos apagados de forma controlada.
pvecm expected 1

Con estos cinco o seis comandos localizas el 90 % de los problemas de clúster: si es falta de quórum, si es un enlace de corosync caído, o si es pmxcfs quejándose. El resto casi siempre se reduce a red y a relojes.

Un clúster Proxmox VE 9 bien montado es de las cosas más sólidas que puedes tener en un datacenter propio: tolera caídas, migra VMs en vivo y se gestiona desde una sola interfaz. Pero toda esa robustez descansa sobre dos pilares que hay que respetar: darle a corosync la red que se merece y no pelearse nunca con el quórum. Respeta esas dos cosas y el clúster te durará años sin sustos. Si además vas a montar almacenamiento distribuido encima, repasa cómo encaja todo con el almacenamiento en Proxmox antes de decidir la arquitectura de HA.