Construir un clúster de Proxmox con alta disponibilidad en servidores dedicados

Primero la respuesta: qué hace falta, qué se obtiene

Los requisitos, según la propia documentación de Proxmox y sin dejarse llevar por ilusiones:

• Mínimo tres nodos para un quorum fiable. (Un clúster de dos nodos funciona con una QDevice externa como desempate, detalles más abajo, pero tres es donde el diseño quiere estar de verdad.)
• Una red fiable y de baja latencia entre nodos, por debajo de 5 ms, con el tráfico del clúster idealmente en su propia tarjeta de red. Es un requisito de mismo emplazamiento, de LAN privada, no algo que se estire entre regiones.
• Almacenamiento al que los nodos supervivientes puedan acceder: Ceph hiperconvergente, replicación ZFS por invitado, o almacenamiento compartido externo.

Lo que se obtiene a cambio, dicho con la misma llaneza: cuando un nodo muere, la HA reinicia sus invitados en los nodos supervivientes, automáticamente, en pocos minutos. Eso es recuperación ante caídas sin intervención humana, enormemente valiosa, pero no es tolerancia a fallos sin tiempo de inactividad: los invitados se reinician. La migración en caliente (para movimientos planificados) es la variante invisible; el failover es un reinicio.

Si tu necesidad real es «recuperarte de fallos en el plazo de un día laborable», una buena práctica de copia de seguridad y restauración en un único host sólido es menos maquinaria. La clusterización justifica su complejidad cuando los minutos importan, o cuando manejas suficientes invitados como para que la gestión centralizada y la migración en caliente se amorticen a diario.

Clusterización antes de la HA: ya merece la pena por sí sola

Una confusión habitual: clúster ≠ HA. Unir nodos en un clúster (pvecm) te da, sin ninguna HA configurada: una sola interfaz web que gestiona cada nodo, migración en caliente de VM entre nodos (mantenimiento de hardware sin tiempo de inactividad), configuración de red SDN y de firewall a nivel de todo el clúster, y gestión compartida de tareas y permisos. Muchos clústeres de producción funcionan exactamente así (las personas deciden cuándo se mueven los invitados) y añaden HA más tarde, de forma selectiva, por invitado, para los servicios que justifican un failover automatizado.

Quorum: por qué tres nodos

El problema que resuelve el quorum es el split-brain. Si los enlaces del clúster fallan y los nodos dejan de verse entre sí, cada lado debe decidir: «¿soy yo el clúster ahora?» Si ambos lados dicen que sí, los dos arrancan las mismas VM en el mismo almacenamiento compartido, y ahí descubres cómo son las imágenes de disco corruptas. La regla que lo impide: solo un grupo que tenga la mayoría de los votos puede actuar. Con tres nodos, cualquier partición tiene un lado mayoritario (2) y un lado minoritario (1) que se congela; con dos nodos, un enlace roto convierte a ambos lados en minoría: ninguno puede actuar, y la disponibilidad es ahora peor que con un solo nodo.

De ahí las dos formas permitidas: tres nodos o más, o dos nodos más una QDevice, un daemon testigo de corosync diminuto en una tercera máquina cualquiera (sirve un VPS o un servidor pequeño; no ejecuta invitados, solo vota). Lo que nunca está permitido es el workaround que sugieren los foros a medianoche: fijar manualmente los votos esperados en 1 para forzar la actividad de un nodo particionado. Ese interruptor es exactamente cómo el split-brain se convierte en una experiencia personal.

La red de corosync: la latencia es la ley

Corosync, la capa de membership y mensajería del clúster, es el componente cuyos requisitos son los menos negociables y los que más se violan:

• Latencia por debajo de 5 ms entre todos los nodos. Esto es física de LAN: mismo emplazamiento, red privada. Los nodos en ciudades diferentes no son un clúster; son dos clústeres y una estrategia de replicación.
• El ancho de banda es irrelevante; la contención es fatal. Corosync solo necesita kilobits, pero en cuanto comparte enlace con trabajos de copia de seguridad, tráfico de almacenamiento o migración de VM y ese enlace se satura, los paquetes de membership llegan tarde, se declara muertos a los nodos, y la HA empieza a «recuperar» invitados que estaban perfectamente bien. La recomendación oficial, que merece seguirse al pie de la letra: una tarjeta de red dedicada (1 Gbit sobra) para el tráfico del clúster, y hasta ocho enlaces de corosync redundantes si te sobran rutas. Como mínimo, un segundo enlace en cualquier otra red como respaldo.
• El tráfico de almacenamiento (especialmente el de Ceph) también quiere su propio carril; ver más abajo.

En nuestros servidores dedicados esto se traduce de forma directa: la red privada entre tus máquinas transporta corosync (y el almacenamiento) por interfaces que nunca compiten con el tráfico público.

Almacenamiento: la verdadera decisión de arquitectura

La premisa de la HA es que los discos de un invitado sobreviven al nodo en el que se ejecutaba. Tres formas de lograrlo:

Ceph: hiperconvergente, la respuesta completa

Proxmox integra Ceph de forma nativa: cada nodo aporta discos (OSD), Ceph replica los datos entre nodos (3 copias por defecto), cada nodo ve todo el almacenamiento, y perder un nodo no hace perder nada. Autorreparable, sin SAN externa, escala añadiendo nodos. Este es el clúster hiperconvergente canónico, y los requisitos oficiales son honestos sobre su apetito: tres o más servidores, preferiblemente idénticos, una red dedicada de 10 Gbit/s+ exclusiva para Ceph (25 Gbit/s+ cuando entra en juego el NVMe: una sola NVMe moderna puede saturar 10 Gbit/s ella sola), discos en HBA, no en controladoras RAID (Ceph se ocupa de la redundancia; una capa RAID debajo perjudica activamente), aproximadamente un hilo de CPU por servicio de Ceph y ~8 GiB de RAM por OSD para ir cómodo. Presupuesta esos recursos como sobrecarga de infraestructura en cada nodo, además del dimensionamiento de los invitados.

Replicación ZFS: el término medio pragmático

Cuando los requisitos de Ceph superan el presupuesto, pvesr replica los volúmenes de los invitados entre nodos según una programación (tan ajustada como cada minuto) por la red de migración, de ZFS a ZFS. El failover reinicia entonces el invitado desde su réplica con una salvedad que Ceph no tiene: una ventana explícita de pérdida de datos. Todo lo que haya cambiado desde la última sincronización (hasta un minuto, o tu programación) se pierde. Para muchas cargas de trabajo, ese intercambio es excelente: sin la complejidad del almacenamiento compartido, velocidad de NVMe local para cada invitado, redundancia por invitado en lugar de a nivel de clúster. Requiere almacenamiento de invitado basado en ZFS en ambos extremos.

Almacenamiento compartido externo

NFS o iSCSI accesible desde todos los nodos también satisface la HA, lo más simple conceptualmente, y traslada el problema: esa caja de almacenamiento es ahora el punto único de fallo que tu clúster no cubre. Sensato cuando es un sistema de almacenamiento genuinamente resiliente; una falsa economía cuando es un solo servidor NFS en el mismo rack.

Cómo es en realidad un failover

El mecanismo merece ser desmitificado, porque «el clúster se encarga» esconde un comportamiento bastante picante. Cada nodo que ejecuta invitados de HA arma un watchdog, un interruptor de hombre muerto (watchdog por hardware donde está configurado, softdog del kernel en caso contrario). Cuando un nodo pierde el quorum, deja de alimentar al watchdog, y tras el tiempo de espera (~60 segundos) el nodo se aplica fencing a sí mismo: se reinicia, lo que garantiza que sus invitados están realmente muertos y sus discos liberados. La mayoría con quorum espera a que pase esa ventana, y luego reinicia los invitados de HA del nodo aislado por fencing desde el almacenamiento compartido o replicado.

Tiempo de inactividad total experimentado por un invitado: ventana de watchdog + programación + arranque del invitado, típicamente unos pocos minutos. La configuración es por invitado (Datacenter → HA): marca los invitados que lo merecen, las reglas de grupo y afinidad dirigen dónde aterrizan (PVE 9 añadió reglas de afinidad de recursos como es debido, y el planificador de carga dinámico de la 9.2 puede equilibrar según el uso en tiempo real). Dos notas operativas que evitan incidentes autoinfligidos: usa el modo mantenimiento (y el desarme de HA a nivel de clúster de la 9.2) antes de reinicios deliberados, para que la maquinaria del watchdog no «recupere» un nodo que estás parcheando; y ten en cuenta que el fencing también es la razón por la que nunca debes simular un quorum en un nodo particionado: el watchdog es la última línea que impide que dos copias de tu base de datos escriban en un mismo disco.

Cuándo no clusterizar

• Dos nodos, sin un tercer voto en ningún sitio. Añade una QDevice (cualquier VM pequeña en otro lugar) o quédate sin clúster: un clúster de dos nodos sin QDevice falla peor que unos nodos independientes.
• Nodos separados por una latencia real. >5 ms significa que no. La resiliencia multisede se resuelve con sedes independientes más replicación y copias de seguridad, no con un clúster estirado.
• Cuando el requisito honesto es «restaurado para mañana». Un único host bien respaldado con reprovisión en menos de un minuto detrás es mucho menos que operar, y la restauración en caliente de PBS reduce aún más la diferencia.
• Hardware dispar para Ceph. Nodos muy diferentes entre sí incomodan a Ceph (el disco más lento marca el ritmo); la replicación ZFS tolera la asimetría mucho mejor.

Preguntas frecuentes

¿Puedo construir un clúster de dos nodos?

Sí, con la QDevice como tercer voto obligatorio: corosync-qnetd en cualquier máquina siempre encendida fuera del par (una pequeña instancia en la nube es la opción clásica; no ejecuta invitados y apenas necesita recursos). Con ella, cualquiera de los dos nodos puede fallar y el superviviente conserva el quorum y ejecuta la recuperación de HA. Sin ella, no lo hagas: cualquier fallo de enlace o de nodo congela todo el clúster, lo cual es estrictamente peor que dos hosts independientes.

¿Me da la HA un failover sin tiempo de inactividad?

No. Y saber por qué te da las expectativas correctas. El failover no planificado es fencing y luego reinicio: los invitados del nodo fallido arrancan de nuevo en los supervivientes tras la ventana del watchdog, así que cuenta con minutos de inactividad y diseña las aplicaciones para que se recuperen limpiamente de una parada brusca (deberían poder hacerlo de todos modos). Lo que sí es sin tiempo de inactividad es el movimiento planificado: la migración en caliente vacía un nodo antes de un mantenimiento con los invitados funcionando todo el tiempo. La HA se encarga de las sorpresas; la migración en caliente se encarga del calendario.

¿Pueden mis nodos estar en datacenters diferentes?

Racks o salas diferentes dentro de una misma instalación con conectividad privada por debajo de 5 ms: sí, y es buena higiene de dominio de fallos. Ciudades diferentes: no. Tanto la membership de corosync como (peor aún) la replicación síncrona de Ceph degeneran en inestabilidad con las latencias WAN. El patrón multirregión son clústeres independientes por sede, con replicación asíncrona y sincronización de copias de seguridad entre ellos, y el failover como un acto deliberado en lugar de automático.

¿Necesitan todos los nodos hardware idéntico?

Para el clúster en sí, no. Los nodos mixtos se agrupan sin problema, y la migración en caliente entre distintas generaciones de CPU funciona con un tipo de CPU base común configurado en los invitados (el coste: los invitados no pueden usar instrucciones más recientes). Para Ceph, lo casi idéntico es la recomendación firme: la capacidad y el rendimiento se equilibran entre los OSD, y un nodo lento frena todo el pool. Patrón pragmático para flotas mixtas: agrúpalos todos para la gestión, ejecuta Ceph (o parejas de replicación) sobre el subconjunto equiparado, y fija ahí los invitados de HA.

Desplegar en Serverside

El clúster que describe este artículo se traduce en un pedido concreto: tres servidores dedicados a juego (Proxmox preinstalado, NVMe en HBA para Ceph o ZFS para replicación) conectados mediante nuestra red privada para el tráfico de corosync y almacenamiento (tu ancho de banda público nunca ve la cháchara del clúster), cada uno con KVM-over-IP para el día en que un nodo necesite atención fuera de banda. La provisión tarda menos de un minuto en el ASN 55285, lo que hace trivial incluso el patrón de QDevice: cualquier tercera máquina pequeña sirve.

Ve construyendo hacia ahí con la serie: configuración inicial, redes, LXC frente a VM, y copias de seguridad, que igualmente necesitas; un clúster replica tus errores con excelente disponibilidad.