Problema

Los entusiastas de homelab que gestionan dos servidores físicos suelen buscar una capa de alta disponibilidad (HA) que permita replicar servicios críticos sin añadir una carga operativa excesiva. El patrón típico incluye:

  • Un nodo principal que ejecuta la mayor parte de los contenedores o máquinas virtuales.
  • Un nodo secundario que actúa como respaldo y, en caso de falla, asume la carga.
  • Necesidad de un sistema de almacenamiento compartido que ofrezca rendimiento cercano al NVMe y que sea fácil de provisionar.
  • Preferencia por herramientas que no requieran un aprendizaje profundo ni una infraestructura de orquestación compleja.

En este contexto, la decisión recae entre dos enfoques populares: Proxmox VE (con LXC y KVM) y Docker Swarm. Cada uno aborda la HA y el almacenamiento de forma distinta, y la elección depende de la complejidad aceptable, el tipo de carga de trabajo y la experiencia del administrador.

Causa

Los problemas que aparecen al intentar implementar HA en un homelab de dos nodos suelen originarse en tres áreas:

  1. Almacenamiento compartido inadecuado

    • Soluciones basadas en GlusterFS o Ceph pueden degradar el rendimiento cuando se usan discos NVMe y enlaces de 2.5 Gbps.
    • DRBD en modo master‑master ofrece mejor IOPS, pero requiere una capa NFS adicional para exponer los volúmenes a ambos nodos, lo que introduce latencia.

  2. Orquestación insuficiente

    • Docker Swarm brinda despliegue de contenedores con replicación de servicios, pero no gestiona máquinas virtuales ni LXC.
    • Proxmox maneja tanto contenedores como VMs, pero su modelo HA depende de un clúster de al menos tres nodos para quorum, lo que complica la configuración en un entorno de solo dos servidores.

  3. Sobrecarga operativa

    • Configurar DRBD, NFS y scripts de failover manualmente genera puntos de falla y aumenta la carga de mantenimiento.
    • Un stack “Docker‑only” es más sencillo, pero carece de herramientas integradas para snapshots de VM y migración en vivo.

Solución

Una solución reutilizable combina lo mejor de ambos mundos: usar Proxmox como capa de virtualización y Docker Swarm dentro de máquinas virtuales o LXC para los servicios que ya están containerizados. El esquema básico es:

  1. Crear un clúster Proxmox de dos nodos

    • Habilitar pmxcfs y configurar corosync con un quorum de dos nodos usando el modo two‑node (opción votequorum con expected_votes: 2).
    • Activar el HA Manager de Proxmox; aunque el quorum es limitado, el gestor sigue permitiendo migraciones automáticas cuando ambos nodos están en línea.

  2. Provisionar almacenamiento replicado con DRBD en modo dual primary

    • Configurar un recurso DRBD que exponga un bloque de datos como /dev/drbd0.
    • Formatear con XFS o ext4 y montar en ambos nodos bajo /mnt/shared.
    • Dentro de /mnt/shared crear un NFS export que sirva como backend para los contenedores que necesiten acceso a datos persistentes.

  3. Desplegar Docker Swarm dentro de una VM o LXC

    • En cada nodo lanzar una VM ligera (por ejemplo, Ubuntu Server) que actúe como Swarm manager y worker.
    • Usar la red overlay de Swarm para que los servicios se distribuyan automáticamente entre los dos hosts.
    • Montar el NFS exportado en la VM para que los volúmenes de Docker apunten a /mnt/shared.

  4. Configurar failover de la VM/LXC

    • En Proxmox, marcar la VM como recurso HA y asignarle una prioridad.
    • Si el nodo primario falla, el HA Manager reinicia la VM en el nodo secundario, manteniendo la dirección IP virtual mediante keepalived o VRRP.

Este enfoque mantiene la simplicidad operativa (Docker Swarm gestiona los contenedores) y flexibilidad (Proxmox permite añadir VMs o LXC para otras cargas, como Home Assistant). Además, DRBD ofrece rendimiento cercano al NVMe porque los datos se escriben directamente en los discos locales y se replican a alta velocidad por el enlace de 2.5 Gbps.

Alternativas prácticas

  • GlusterFS con replica‑2: útil si ya se tiene experiencia, pero prepárese para una caída de IOPS en bases de datos.
  • Ceph RBD en modo single‑node: demasiado pesado para dos servidores, a menos que se planee escalar a tres o más nodos.
  • Solo Docker Swarm con NFS externo: elimina Proxmox, pero pierde la capacidad de ejecutar VMs y LXC, y la gestión de snapshots queda en manos de scripts manuales.

Cuándo aplicar esta solución

  • Escenario típico: dos servidores con CPUs de bajo consumo (N5105, N4100) y discos NVMe, donde la carga principal son contenedores Docker y una o dos VMs de automatización.
  • Síntomas que indican la solución: latencia alta en bases de datos al usar GlusterFS, necesidad de migrar VMs sin tiempo de inactividad, y deseo de mantener una única capa de gestión (Proxmox) para backups y snapshots.
  • Exclusiones: entornos que requieren más de tres nodos para quorum robusto, o donde la única carga son contenedores sin necesidad de VMs; en esos casos Docker Swarm puro puede ser suficiente.

Código

# 1. Instalar DRBD en ambos nodos (Debian/Ubuntu)
apt-get install drbd-utils

# 2. Crear recurso DRBD (ejemplo /etc/drbd.d/shared.res)
cat > /etc/drbd.d/shared.res <<EOF
resource shared {
    protocol C;
    on node1 {
        device    /dev/drbd0;
        disk      /dev/nvme0n1p1;
        address   10.0.0.1:7789;
        meta-disk internal;
    }
    on node2 {
        device    /dev/drbd0;
        disk      /dev/nvme0n1p1;
        address   10.0.0.2:7789;
        meta-disk internal;
    }
}
EOF

# 3. Inicializar y montar
drbdadm create-md shared
drbdadm up shared
drbdadm -- --overwrite-data-of-peer primary shared   # en el nodo primario
mkfs.xfs /dev/drbd0
mkdir -p /mnt/shared
mount /dev/drbd0 /mnt/shared

# 4. Exportar NFS
apt-get install nfs-kernel-server
echo "/mnt/shared *(rw,sync,no_subtree_check)" >> /etc/exports
exportfs -ra

# 5. Configurar VM en Proxmox como Swarm manager
# (asume que la VM ya está creada y tiene Docker instalado)
docker swarm init --advertise-addr 10.0.0.10
docker swarm join-token worker   # copiar token al segundo nodo

Verificación

  1. DRBD estado: cat /proc/drbd debe mostrar Primary/Secondary y Connected.
  2. NFS acceso: desde ambos nodos ejecutar showmount -e 10.0.0.1 y montar manualmente mount -t nfs 10.0.0.1:/mnt/shared /tmp/test.
  3. Swarm salud: docker node ls debe listar ambos nodos con estado Ready.
  4. HA de VM: detener el nodo primario en Proxmox, observar que la VM se reinicia automáticamente en el nodo secundario y que los contenedores siguen corriendo (docker service ls).
  5. Rendimiento básico: usar fio contra /mnt/shared dentro de la VM para confirmar IOPS similares a los del disco local.

Notas adicionales

  • Quorum de dos nodos: Proxmox permite el modo two‑node pero depende de una red de gestión fiable; cualquier interrupción del enlace de 2.5 Gbps provocará un split‑brain. Considere un tercer nodo ligero (Raspberry Pi) solo para quorum si la disponibilidad es crítica.
  • Snapshots: Proxmox puede crear snapshots de la VM que contiene el Swarm manager; sin embargo, los volúmenes Docker que residen en NFS no se incluyen. Para bases de datos, habilite backups a nivel de aplicación (por ejemplo, mysqldump o pg_dump) dentro del contenedor.
  • Mantenimiento de DRBD: al actualizar el kernel o el paquete drbd-utils, siga la guía oficial para evitar pérdida de sincronización.
  • Monitoreo: integre prometheus y node_exporter dentro de la VM Swarm para observar latencia de red y uso de IOPS en tiempo real.
  • Escalado futuro: añadir un tercer nodo a Proxmox es trivial; basta con unirlo al clúster y replicar el recurso DRBD con on node3 en la configuración.

Con este patrón, se consigue una solución HA que combina la facilidad de Docker Swarm para contenedores con la robustez de Proxmox para máquinas virtuales y gestión de snapshots, todo sin requerir una infraestructura de tres nodos desde el inicio.