Mi homelab empezó con un único nodo Proxmox ejecutando máquinas virtuales para servidores web, bases de datos y almacenamiento en la nube. Consolidar esas cargas simplificó la gestión, pero también concentró el riesgo: un solo host caído podía dejarlo todo fuera de servicio.
Añadir un segundo nodo me permitió explorar la replicación ZFS y la alta disponibilidad. La lección importante es que un clúster, una réplica y una copia de seguridad resuelven problemas distintos. Tener dos servidores no garantiza, por sí mismo, servicio ininterrumpido ni cero pérdida de datos.
Esto es un relato arquitectónico de aquel homelab, no un manual de instalación atado a versiones concretas. El montaje original no registró suficiente detalle de versiones y configuración como para presentar sus comandos como una guía de despliegue reproducible.
¿Qué cambia al añadir un segundo nodo?
Proxmox VE combina máquinas virtuales KVM, contenedores LXC y gestión de clúster. Un segundo host da un sitio donde ejecutar una carga, pero la recuperación sigue dependiendo de varios requisitos previos:
- El host superviviente necesita CPU, memoria y almacenamiento de sobra para las cargas que tenga que recuperar.
- Los discos de las máquinas deben ser accesibles desde ese host, mediante almacenamiento compartido o una configuración de replicación soportada.
- Los bridges de red y el resto de dependencias de las máquinas deben existir en el destino de recuperación.
- El clúster tiene que poder tomar decisiones seguras sobre la propiedad de los recursos.
- Los recursos deben gestionarse explícitamente con HA; unirse a un clúster no activa HA para todas las máquinas.
El diseño de red importa tanto como los hosts. El tráfico de replicación no debería ahogar la comunicación del clúster, que es sensible a la latencia. Dimensiona y prueba la red contra el ritmo real de cambio de datos, en lugar de dar por hecho que una velocidad de enlace concreta garantiza un clúster funcional.
Por qué elegí replicación ZFS local
Para el montaje de dos nodos elegí ZFS en lugar de añadir la complejidad operativa de Ceph. Es una decisión sobre el tamaño y las restricciones de este homelab, no una recomendación general en contra del almacenamiento distribuido.
Las opciones de almacenamiento de Proxmox sirven para cosas distintas:
| Almacenamiento | Consideración principal |
|---|---|
| LVM | Almacenamiento de bloques sobre volúmenes lógicos; no es un sistema de replicación. |
| LVM Thin | Aprovisionamiento fino y snapshots, vigilando de cerca el espacio libre. |
| Directorio | Almacenamiento en ficheros cuya durabilidad depende del sistema de ficheros y los discos subyacentes. |
| ZFS local | Checksums, snapshots y soporte para el framework de replicación de Proxmox. |
| Ceph | Almacenamiento distribuido con sus propios requisitos de recursos, red y operación. |
La replicación ZFS local no es almacenamiento compartido. Proxmox transfiere periódicamente snapshots de los volúmenes de las máquinas a otro nodo, enviando los cambios de forma incremental tras la sincronización inicial. El destino contiene el último estado replicado con éxito, no necesariamente la última escritura de la aplicación.
Por poner una línea temporal de ejemplo, supón que el último snapshot correcto corresponde a las 12:00 y el origen falla a las 12:04. Las escrituras posteriores a ese snapshot pueden faltar en el destino de recuperación. Un intervalo configurado más corto reduce la exposición, pero los trabajos de replicación fallidos o lentos pueden hacer que el hueco real sea mucho mayor.
Monitoriza la antigüedad de la última replicación correcta y sus errores, no solo si existe una programación. Los checksums de ZFS tampoco significan que toda corrupción se pueda reparar: la reparación depende de que exista una copia redundante válida. La compresión y la deduplicación son funciones distintas; la deduplicación no debería activarse a la ligera sin entender su coste en recursos.
El quórum y el compromiso de los dos nodos
Con solo dos hosts con voto, perder uno crea un problema de quórum. En mi homelab usé una Raspberry Pi Zero como árbitro externo. En un diseño de dos nodos, un dispositivo de quórum externo ayuda a arbitrar los votos, pero no es otro host de cómputo y no guarda las réplicas de las máquinas.
La guía oficial de HA recomienda al menos tres nodos de clúster para un quórum fiable. Trata un homelab de dos nodos con dispositivo de quórum como un diseño con casos de fallo adicionales que hay que entender, no como un sustituto equivalente de un clúster de producción totalmente redundante.
El árbitro también necesita una ubicación adecuada en cuanto a alimentación y red. Perder a la vez un host y el acceso al árbitro puede dejar al host restante sin capacidad de operar con seguridad. No sortees las particiones forzando el quórum a la ligera.
El failover no es migración en vivo
La migración en vivo mueve una máquina en ejecución mientras su host origen sigue disponible. Cuando un host ya ha fallado, la recuperación por HA consiste en reiniciar el recurso de forma segura en un host superviviente elegible.
Esa distinción importa para las aplicaciones: el estado en memoria y las conexiones activas pueden perderse, y una base de datos puede necesitar recuperación tras caída. El fencing evita que el propietario antiguo siga operando mientras otro host toma el control. El quórum y el fencing son partes complementarias de una recuperación segura, no funciones intercambiables.
El tiempo total de caída incluye la detección del fallo, el fencing, el arranque de la máquina y la recuperación de la aplicación. La afirmación de “uno o dos minutos” del artículo original no era una medición documentada y no debería tomarse como una garantía de tiempo de recuperación.
La replicación no es una copia de seguridad
Una réplica puede incluir un borrado accidental o un cambio no deseado de la aplicación. Mantén copias de seguridad con retención independiente, protege su acceso y prueba la restauración por separado del failover de hosts.
Antes de confiar en el diseño, valida estos escenarios en un laboratorio desechable con datos de prueba recuperables:
- Un trabajo de replicación falla porque el destino está lleno o inaccesible, y la monitorización avisa de la réplica obsoleta.
- Un host falla, la partición restante tiene quórum seguro y el propietario antiguo queda aislado antes de la recuperación.
- Una máquina recuperada arranca con la red esperada y la aplicación pasa sus comprobaciones de salud.
- El host origen vuelve sin crear un segundo propietario activo.
- Una copia de seguridad se restaura en un entorno aislado y sus datos de aplicación se pueden verificar.
Registra la versión de Proxmox, la topología, las dependencias de las máquinas, los últimos datos replicados y el tiempo de recuperación medido de la aplicación. Esas observaciones son mucho más útiles que afirmar sin matices que el clúster es de alta disponibilidad.
Para seguir leyendo
- Proxmox VE: High Availability
- Proxmox VE: Storage Replication
- Proxmox VE: Cluster Manager
- Diseño de sistemas: patrones de acceso y resiliencia para los compromisos del lado de la aplicación que la infraestructura por sí sola no resuelve.