Clúster HA con Proxmox y 2 nodos: configurar correctamente Quorum, QDevice y Fencing

Un HA-Cluster con Proxmox y 2 nodos es en la práctica un caso especial: se monta rápidamente, pero en materia de Quorum (decisión por mayoría en el clúster) y Fencing (aislar de forma estricta un nodo defectuoso para evitar la corrupción de datos) es claramente más exigente que un conjunto clásico de 3 nodos. La razón es sencilla: con exactamente dos votos no existe una mayoría sin un tercer «marcapasos». En cuanto la comunicación o el almacenamiento flaquean, aparecen riesgos de situaciones de «Split Brain»: dos partes que cada una cree ser la instancia válida.

Este artículo muestra de forma práctica cómo resolver correctamente el Quorum en dos nodos Proxmox (QDevice), cómo implementar y probar de forma realista el Fencing en Proxmox (incluido el Watchdog) y qué estrategias de comprobación y de retroceso ayudan en la operación. El foco está en las repercusiones sobre la disponibilidad, la integridad de los datos y la operación — no en detalles de frameworks.

HA-Cluster con Proxmox y 2 nodos en la práctica

En Proxmox la comunicación del clúster se basa en Corosync (Cluster-Messaging) y la configuración del clúster reside en pmxcfs (Proxmox Cluster File System, un sistema de archivos de configuración distribuido y dependiente del quórum). Para las decisiones del clúster, Corosync utiliza un Quorum: solo cuando se alcanza una mayoría la vista del clúster se considera „valid“ y se permiten las acciones de escritura en el clúster.

Con tres nodos esto es robusto: dos de tres constituyen mayoría. Con dos nodos, sin ayudas, es frágil: si cae un nodo o solo la conexión, queda un voto — y eso no es mayoría. El clúster queda bloqueado (en el mejor de los casos). En el peor de los casos, los administradores evitan los mecanismos de protección del Quorum y arriesgan un Split Brain: ambas partes continúan, escriben en el mismo almacenamiento o ejecutan acciones de HA contradictorias.

Importante para la planificación: „HA“ no es solo „la VM arranca en otro host“. HA significa, sobre todo, decisiones consistentes en caso de fallo. Para ello se necesitan bien al menos tres votos o bien una „tercera voz“ externa y controlada.

Principio básico: QDevice como tercer voto para el Quorum de Proxmox

La solución limpia para dos nodos Proxmox es un QDevice. No se trata de otro host Proxmox, sino de una ayuda de quórum: un servicio externo (qnetd, Corosync Quorum Net Daemon) proporciona, a través de la red, un voto adicional. Los nodos del clúster se conectan como clientes (qdevice) a ese servicio. Con ello, ante una caída o una partición puede restablecerse la mayoría: 1 nodo + QDevice = 2 votos (mayoría de 3).

Por qué funciona: QDevice no toma «decisiones de HA», sino que actúa como un testigo controlado que determina a qué partición se le otorga el voto adicional. Eso reduce considerablemente el riesgo de split‑brain, pero no sustituye al fencing. Porque incluso con quorum un nodo puede «seguir en marcha» pero ya no ser seguro (p. ej., el almacenamiento se bloquea, el kernel se cuelga, timeouts de I/O). En ese caso necesita un mecanismo que garantice: solo un host puede seguir escribiendo en recursos compartidos.

Requisitos y comprobación de diseño antes de la implementación

Antes de configurar QDevice o fencing, aclare las condiciones marco. Muchas implementaciones de 2 nodos fracasan no por Proxmox en sí, sino por supuestos no explicitados sobre red, almacenamiento o alimentación eléctrica.

1) Red: al menos dos rutas, latencia definida, MTU consistente

Para Corosync no cuenta la «ancho de banda», sino la latencia estable y la baja pérdida de paquetes. Planifique idealmente redes separadas (o VLANs) para gestión/cluster (Corosync) y tráfico de VM. Si utiliza una interfaz Corosync dedicada, vigile que la MTU sea idéntica y la configuración de los switches consistente. Los «Jumbo Frames aplicados de forma desigual» son un clásico causante de particiones esporádicas.

2) Almacenamiento: almacenamiento compartido vs. replicación

En HA con Proxmox aparecen con frecuencia dos patrones:

• Almacenamiento compartido (p. ej., iSCSI/NFS/SAN): Ambos hosts ven el mismo datastore. Ventaja: la VM puede arrancar rápidamente en el otro host. Riesgo: un split brain puede corromper el almacenamiento si ambos hosts escriben simultáneamente.
• Almacenamiento replicado (p. ej., replicación ZFS): Los datos se sincronizan o replican periódicamente entre hosts. Ventaja: menos «escritura simultánea» en el mismo dispositivo de bloques. Inconveniente: RPO/RTO dependen de los intervalos de replicación y del proceso de failover.

En ambos casos: sin fencing el almacenamiento compartido en una configuración de 2 nodos es especialmente arriesgado. Incluso con QDevice, el fencing debería contemplarse como la «última instancia».

3) Gestión fuera de banda y watchdog

Para un fencing fiable normalmente necesita una interfaz Out-of-Band como IPMI (gestión remota BMC) o una PDU con control de encendido. Alternativamente existen mecanismos basados en almacenamiento (p. ej., SBD) que en entornos Proxmox suelen estar fuera de la ruta estándar. Adicionalmente debería haber un watchdog activo: es un temporizador de hardware o del kernel que reinicia el host si el sistema «se queda colgado» y deja de alimentarlo regularmente (keepalive). Eso aborda deadlocks en los que un host aún tiene alimentación eléctrica pero ya no toma decisiones seguras.

Implementación: configurar QDevice (qnetd) para dos nodos Proxmox

La recomendación desde el punto de vista operativo: ejecute el servicio QDevice en un tercer sistema que sea independiente de los dos hosts de Proxmox (otro circuito eléctrico/UPS, idealmente otro rack/segmento de ubicación). Puede ser una pequeña VM o un mini‑servidor. Lo importante no es tanto el rendimiento como la disponibilidad y rutas de red limpias.

Paso 1: QNetd en el host de QDevice instalar

Ejemplo para un sistema Debian/Ubuntu como host de QDevice:

sudo apt update
sudo apt install -y corosync-qnetd
sudo systemctl enable --now corosync-qnetd
sudo systemctl status corosync-qnetd

Asegúrese de que el firewall permita el puerto de qnetd (por defecto TCP 5403). En redes RESTrictivas, esto suele ser el primer escollo: Corosync suele comunicarse internamente mediante UDP/Multicast o UDP/Unicast, mientras que qnetd utiliza TCP.

Paso 2: Asegurar el tiempo y la resolución de nombres

Los componentes del clúster son sensibles a la deriva de tiempo. Active NTP/Chrony en todos los sistemas. Además, la resolución de nombres debe ser estable (DNS o /etc/hosts), ya que los certificados e identidades pueden jugar un papel en qdevice/qnetd.

Paso 3: Registrar QDevice en el clúster de Proxmox

En un nodo de Proxmox (típicamente el que inicializó el clúster) integre QDevice. Proxmox proporciona para ello pvecm (Proxmox VE Cluster Manager).

# Status prüfen
pvecm status

# QDevice hinzufügen (Hostname oder IP des QNetd-Hosts)
pvecm qdevice setup <QNETD_HOSTNAME_ODER_IP>

El proceso de configuración genera y distribuye las claves/certificados necesarios y modifica la configuración de Corosync en consecuencia. Después, verifique de nuevo el estado del clúster:

pvecm status
pvecm qdevice status

Expectativa en un clúster de 2 nodos: verá, junto a los dos votos de los nodos, información adicional de quórum proporcionada por QDevice. Si QDevice no es accesible, en caso de fallo el quórum vuelve al problemático modelo de 2 votos.

Problemas típicos con QDevice

• QDevice en el mismo segmento Layer‑2 que ambos nodos, pero en la misma arista del switch: si el switch falla, QDevice cae con él. Entonces el «tercer testigo» no es independiente.
• QDevice como VM en el propio clúster de Proxmox: eso es un círculo vicioso. Si el clúster flaquea, también fluctúa la VM que debería estabilizar el quórum.
• Reglas de firewall imprecisas: qnetd requiere conectividad TCP estable. Pérdida de paquetes o inspección TLS en el trayecto puede provocar desconexiones intermitentes.
• Intentos de ajuste de timeouts de Corosync demasiado agresivos: en redes pequeñas, timeouts más cortos pueden parecer «más rápidos», pero aumentan los triggers erróneos ante breves perturbaciones. Primero medir, luego cambiar.

Fencing in Proxmox: por qué el quórum por sí solo no basta

Aun con QDevice, el quórum solo indica quién puede decidir. No indica si otro nodo está realmente detenido. Aquí es donde entra en juego el Fencing (a menudo también llamado STONITH: «Shoot The Other Node In The Head»). Objetivo: cuando un host, desde la perspectiva del clúster, debe considerarse caído, se le apaga o reinicia de forma fiable antes de que los recursos (VMs, almacenamiento) continúen ejecutándose en el otro host.

En Proxmox se gestiona la HA mediante el HA Manager integrado. El HA Manager puede administrar servicios (VMs/contenedores) y moverlos en caso de fallo. Pero: si ambos Hosts creen simultáneamente que están „activos“, la HA puede ejecutar acciones incorrectas sin fencing. Con almacenamiento compartido esto es especialmente peligroso, porque bloques de datos pueden escribirse en paralelo.

Opciones de fencing realistas en operación de 2 nodos

• IPMI/Redfish Power Off/Reboot: El clásico en entornos de servidores. Requisito: el BMC debe ser accesible, aislado de forma independiente y no estar en la misma red que el segmento con problemas.
• PDU conmutables / Smart Power: Funciona también si el BMC es inestable. Sin embargo, debe operarse con seguridad organizativa (permisos de acceso, registro de eventos).
• Watchdog + auto-fencing: Cuando el Host detecta internamente que está en estado inseguro (p. ej., pierde quórum/cluster), puede reiniciarse a sí mismo. Esto no sustituye al fencing externo, pero aumenta la robustez frente a estados „colgados“.

Importante: un „apagado limpio“ no es fencing. El fencing debe ser en caso de duda duro, porque precisamente en el fallo lo „limpio“ suele dejar de funcionar de forma fiable.

Activar y comprobar Watchdog en Proxmox (Best Practice)

Un watchdog es un mecanismo que reinicia el sistema cuando deja de responder. Bajo Linux suele estar disponible /dev/watchdog mediante un módulo del kernel (p. ej. iTCO_wdt en plataformas Intel). Proxmox puede usar el watchdog para HA, para no seguir „medio muerto“ en situaciones de interbloqueo.

Paso 1: Comprobar si hay un dispositivo watchdog disponible

ls -l /dev/watchdog* || true

# Kernelmeldungen zum Watchdog
dmesg | grep -i watchdog || true

# Geladene Module
lsmod | grep -i wdt || true

Si no aparece ningún dispositivo, compruebe las opciones del BIOS/UEFI (Watchdog/Server Management) y los módulos del kernel adecuados. En entornos virtualizados el watchdog puede ser proporcionado por la plataforma de VM; en Bare Metal suele ser hardware/chipset.

Paso 2: Comprobar la configuración del watchdog en Proxmox

Según la versión de Proxmox y la configuración, el watchdog se activa mediante servicios del sistema/componentes HA. Como comprobación rápida en producción:

systemctl status pve-ha-lrm pve-ha-crm || true
journalctl -u pve-ha-lrm -u pve-ha-crm --since "-2h" | tail -n 200

Interpretación: No busque servicios „en verde“, sino indicios de que los componentes HA se ejecutan y no hay timeouts recurrentes/bucles de reinicio. Si no se usa HA, el watchdog sigue siendo útil como red de seguridad — pero entonces sus procesos operativos (monitorización/alertas) deben detectar de forma fiable los Hosts colgados.

Lista de verificación práctica: probar antes del primer failover de HA

Antes de que VMs productivas funcionen como recursos HA, realice pruebas controladas. El objetivo no es “funciona una vez”, sino “entendemos cuándo no funciona y cómo reaccionamos entonces”.

1) Línea base del estado del clúster y del quórum

pvecm nodes
pvecm status

# Corosync-Health grob prüfen
systemctl status corosync
journalctl -u corosync --since "-1h" | tail -n 200

Preste atención a pérdida de paquetes, timeouts de token y cambios recurrentes de membresía. Un clúster de 2 nodos debe funcionar de forma „aburrida“: sin reingresos continuos, sin flaps.

2) Comprobar el estado de QDevice y la dependencia

pvecm qdevice status

# QNetd vom Node aus erreichen
nc -vz <QNETD_HOSTNAME_ODER_IP> 5403

Si la conexión TCP falla de forma esporádica, resuélvalo antes de activar HA. De lo contrario, en caso de fallo se quedará sin mayoría.

3) Fallo de enlace simulado: desconectar la red de Corosync

Desconecte de forma controlada la interfaz de Corosync (no la de gestión, para que pueda seguir administrando) y observe qué ocurre: ¿Una parte obtiene quórum? ¿Permanece la otra parte bloqueada de forma limpia? Aquí es donde se muestra si QDevice y el diseño de red funcionan.

Observación durante la prueba:

watch -n 2 'pvecm status; echo; pvecm qdevice status'

Si ambos lados siguen pareciendo „activos“ o las acciones de HA no quedan claras, es una señal de advertencia: entonces debe planificar cuidadosamente el Fencing/aislamiento y las rutas de red.

Patrones de fallo típicos y resolución de problemas en producción

Patrón de fallo A: „El clúster no tiene quórum“ tras una breve perturbación de red

Causas: pérdida de paquetes en la ruta de Corosync, problemas de búfer/cola del switch, desajuste de MTU, QoS/Policing, switches virtuales con drops. En configuraciones de 2 nodos se nota de inmediato, porque no existe un tercer voto que estabilice la vista.

Procedimiento:

• Comprobar los logs de Corosync en busca de timeouts de token.
• Medir la ruta de red: drops en NIC/puertos del switch, errores, CRC, duplex.
• Si es posible: configurar una segunda red de Corosync (redundancia) en lugar de afinar los timeouts.

Patrón de fallo B: QDevice es accesible, pero el quórum se comporta „inesperadamente“

Causas: QDevice no independiente (comparte la causa del fallo), problemas de resolución de nombres/certificados, sesión TCP inestable, enrutamiento asimétrico. Compruebe si ambos nodos realmente hablan de forma estable con qnetd y si qnetd en sí mismo funciona sin interrupciones.

Comprobaciones rápidas:

# Auf dem QDevice-Host
systemctl status corosync-qnetd
journalctl -u corosync-qnetd --since "-2h" | tail -n 200

Patrón de fallo C: La VM arranca tras un failover, pero el almacenamiento está inconsistente o „bloqueado“

Este es el caso peligroso: quórum/HA han reaccionado „de algún modo“, pero sin un fencing seguro el host anterior aún puede generar I/O o bloquear recursos. Dependiendo del almacenamiento (NFS, iSCSI, Cluster‑FS, Ceph) se manifiesta como bloqueos, errores del sistema de archivos o discos de VM dañados.

Medidas:

• En caso de duda: apagar bruscamente el host afectado (fuera de banda, Out-of-Band) antes de continuar con el debug.
• Comprobar los logs de almacenamiento (lado Target/Controller). Muchas causas no están en el hipervisor.
• No liberar recursos HA hasta que quede claro que no hay „escrituras dobles“ activas.

Recomendación de implementación: diseño HA mínimo y robusto de 2 nodos

Si por motivos de presupuesto o espacio debe mantenerse en dos nodos, el objetivo es un diseño que reaccione de forma previsible ante fallos. Un paquete mínimo práctico se presenta así:

• 2 Proxmox‑Hosts con rutas de red separadas para Corosync/Management/VM‑Traffic (mínimo lógicamente vía VLAN, preferible físicamente).
• 1 QDevice‑Host independiente (qnetd), no ejecutado en ninguno de los dos Proxmox‑Hosts.
• Fencing fuera de banda (IPMI/Redfish o PDU) como proceso de emergencia definido, incluyendo responsabilidades y vías de acceso.
• Watchdog activo y probado para mitigar estados de bloqueo.
• Runbooks para bloqueos de partición/almacenamiento: ¿quién apaga qué Host y cuándo, cómo se vuelve a sincronizar, cómo se valida la consistencia de los datos?

Esto es menos «glamoroso» que las listas de características, pero reduce las fallas reales y, sobre todo, los riesgos sobre los datos.

Estrategia de retroceso y recuperación: ¿Qué hacer si Quorum/Fencing reacciona mal?

En la práctica debe asumirse que en algún momento surgirá un estado ambiguo: partición parcial, congelamiento del Storage, BMC inaccesible, HA‑Failover bloqueado. Lo decisivo es disponer de una secuencia de recuperación conservadora que proteja los datos.

Secuencia de recuperación conservadora (probada en operación)

1. Detener los accesos de escritura: Si hay Shared Storage y sospecha de doble escritura, priorice la parada forzada de un nodo (OOB Power Off) antes de reconfigurar «amablemente».
2. Estabilizar el estado del clúster: Solo cuando esté claro qué Host debe ser el «Master», restaure Corosync/Quorum (ruta de red, alcanzabilidad de qnetd).
3. Validar el Storage: Según el backend: comprobaciones del sistema de ficheros, logs del controlador de Storage, sesiones iSCSI, locks de NFS. Objetivo: evitar inconsistencias silenciosas.
4. Activar los servicios HA de forma controlada: No ponga «todo en piloto automático» de inmediato, sino de forma gradual, monitorizando latencia I/O, locks y errores de kernel.

Como regla operativa: es preferible tomarse 10 minutos adicionales para decidir correctamente que invertir 10 horas en recuperar datos. Dos nodos no perdonan la ambigüedad.

Conclusión final: 2 nodos son viables — pero solo con disciplina

Un clúster HA con Proxmox y 2 nodos puede operar de forma fiable si compensa conscientemente la debilidad sistémica (falta de mayoría natural). QDevice no es un «nice-to-have», sino la base para lograr el Quorum de forma sensata en caso de fallo. Fencing y Watchdog son las redes de seguridad que evitan corrupción de datos y estados indefinidos cuando la realidad (bloqueos de Storage, flaps de red, Hosts parcialmente defectuosos) golpea.

Si planifica hoy: incluya QDevice y Fencing desde el principio, pruebe los fallos críticos de forma controlada y documente un procedimiento de recuperación conservador. Así, de un «pequeño» clúster de 2 nodos obtiene un entorno que en operación se basa no en la esperanza sino en estados claros.

En este tema también son importantes Proxmox Qdevice y Proxmox Fencing. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.