Problema

En muchos homelabs la intención es que la infraestructura siga operando aunque falle un nodo, un switch o el firewall de borde. El patrón típico es un clúster de hipervisores (Proxmox, VMware, etc.) con almacenamiento distribuido (Ceph, GlusterFS) y servicios críticos (AD, LDAP, VMs) que deben migrarse automáticamente. Cuando la topología no está bien alineada –por ejemplo, enlaces de red inconsistentes, configuraciones de bonding incompletas o una integración LDAP parcial– el clúster pierde la capacidad de failover y los servicios quedan inaccesibles. El reto es diseñar una arquitectura que garantice que, al perder cualquier componente individual, el resto mantenga conectividad y disponibilidad de las VMs.

Causa

  1. Red sin balanceo de carga L3/L4
    Los switches de nivel 2 sin hashing basado en IP/port hacen que el tráfico de Ceph o del cluster Proxmox se concentre en un único enlace, creando cuellos de botella y fallos al desconectar un puerto.

  2. Bonding o LACP mal configurado
    Cuando los nodos usan NICs en modo “active‑standby” sin sincronizar la configuración de bonding, el enlace secundario nunca se activa y la redundancia queda inoperante.

  3. LDAP/AD sin replicación de red
    Si los controladores de dominio están en una sola VLAN o dependen de un único switch, la pérdida de ese segmento corta la autenticación de los hosts Proxmox, impidiendo que los recursos se re‑programen.

  4. Ceph sin quorum suficiente
    Un clúster Ceph necesita al menos la mitad más uno de los monitores (MON) activos. Con solo tres nodos, la caída de un monitor sin un nodo de reemplazo rompe el quorum y el almacenamiento se vuelve ilegible.

  5. Firewalls de borde sin sincronización de estado
    Configurar dos firewalls en modo activo‑pasivo sin compartir la tabla de estados hace que, al fallar el primario, las conexiones establecidas se pierdan y las VMs parezcan “apagadas”.

Solución

1. Redundancia de red con LACP y hashing

  • Usa switches que soporten LACP y habilita “src‑dst‑ip‑port” como algoritmo de distribución.
  • Configura bonding en cada nodo Proxmox con modo 802.3ad y asegura que todas las NICs del nodo estén en el mismo LAG.
  • Crea dos VLANs: una para tráfico de gestión (Proxmox UI, SSH) y otra para Ceph/public‑network. Mantén ambas en LACP.

2. LDAP/AD accesible desde ambas rutas

  • Coloca los controladores de dominio en una subred separada y replica la zona DNS en al menos dos servidores.
  • En Proxmox, define varios servidores LDAP en la sección datacenter -> authentication, marcando la opción “Use TLS” y habilitando “fallback”.
  • Verifica que cada nodo pueda resolver y contactar a ambos controladores antes de iniciar los servicios.

3. Ceph con monitor extra y OSDs balanceados

  • Añade un cuarto nodo ligero (por ejemplo, un mini‑PC) solo para ejecutar un monitor.
  • Distribuye los OSDs de manera que cada nodo tenga al menos una copia de cada PG (placement group).
  • Configura crush con reglas que eviten que dos réplicas caigan en la misma rack o switch.

4. Firewalls en HA con sincronización de estados

  • Implementa dos WatchGuard o pfSense en modo “Active‑Passive”.
  • Habilita la replicación de tabla de estados (pfsync) y configura una IP flotante (CARP/VRRP) que los hosts Proxmox usen como gateway.
  • En Proxmox, define la IP flotante como gateway en la configuración de red de cada VM.

5. Corosync y quorum en Proxmox

  • Asegúrate de que el fichero /etc/pve/corosync.conf incluya todos los nodos y que el ring0_addr apunte a la IP de gestión.
  • Activa qdevice (external quorum device) si no deseas añadir otro nodo físico; un pequeño contenedor Docker puede cumplir esa función.

6. Pruebas de failover automatizadas

  • Usa pveproxy y pvestatd para validar que los recursos de clúster siguen activos después de desconectar cada enlace.
  • Programa scripts de monitoreo (por ejemplo, con bash + ssh) que apaguen un nodo y verifiquen que las VMs migran automáticamente.

Cuándo aplicar esta solución

  • Síntomas típicos: pérdida de conectividad a VMs tras reiniciar un switch, errores de “no quorum” en Ceph, o fallos de autenticación LDAP después de un corte de red.
  • Escenarios válidos: clústers de 3‑4 nodos con almacenamiento distribuido, entornos de pruebas que simulan un ISP o BGP, y cualquier homelab donde la continuidad del servicio sea requisito.
  • No aplica: entornos monolíticos sin redundancia de red, o cuando el presupuesto impide al menos dos switches gestionables. En esos casos, la solución se reduce a backups externos y snapshots, no a HA real.
# Configuración básica de bonding en Proxmox (Debian based)
cat > /etc/network/interfaces <<EOF
auto bond0
iface bond0 inet static
    address 192.168.10.10/24
    gateway 192.168.10.1
    bond-slaves eth0 eth1
    bond-mode 802.3ad
    bond-miimon 100
    bond-xmit_hash_policy layer3+4
EOF

# Reiniciar red
systemctl restart networking

Verificación

  1. Chequeo de quorum Ceph

    ceph status | grep quorum

    Debe mostrar quorum: <node1>,<node2>,<node3>.

  2. Estado de corosync

    pvecm status

    Verifica que el Quorum sea Yes y que todos los nodos estén Online.

  3. Prueba de failover de VM

    • Apaga un nodo con qm shutdown <VMID> o desconecta su cable de red.
    • En la UI de Proxmox, confirma que la VM pasa a Running en otro host.
    • Revisa que la IP de la VM sigue respondiendo (ping).

  4. LDAP fallback

    ldapsearch -H ldaps://ldap1.example.com -b "dc=example,dc=com" "(objectClass=person)"
ldapsearch -H ldaps://ldap2.example.com -b "dc=example,dc=com" "(objectClass=person)"

    Ambos comandos deben devolver resultados sin error.

  5. Firewall flotante

    ip route get 8.8.8.8

    La salida debe mostrar la IP flotante como via incluso si el firewall primario está offline.

Notas adicionales

  • Cableado: etiqueta los pares de cables que forman cada LAG; un error de cruce es la causa más frecuente de enlaces “fantasma”.
  • Monitores Ceph ligeros: un Raspberry Pi 4 con 4 GB RAM es suficiente para un monitor de prueba; evita sobrecargar los nodos de cómputo.
  • Sincronización de tiempo: NTP debe estar activo en todos los nodos, switches y firewalls; la desincronización rompe el quorum de Corosync.
  • Snapshots vs. HA: aunque los snapshots son útiles, no sustituyen a un clúster HA; mantén ambos mecanismos para cubrir fallos de software y de hardware.
  • Documentación interna: guarda una copia del corosync.conf y del script de bonding en un repositorio Git; cualquier cambio accidental se revierte rápidamente.