El desafío
Necesitábamos una infraestructura de virtualización que cumpliera varios requisitos exigentes: alto rendimiento para inferencia de modelos de inteligencia artificial con GPUs dedicadas, redundancia real ante fallos de hardware, failover automático sin intervención humana, y todo con un presupuesto razonable usando hardware accesible.
La solución que diseñamos combina Proxmox VE como hipervisor, ZFS como sistema de archivos con replicación incremental, GPU passthrough vía VFIO para máximo rendimiento en CUDA, y un sistema de votación con QDevice para alta disponibilidad con solo dos nodos.
Arquitectura general
El sistema está compuesto por tres máquinas con roles claramente definidos:
ZFS: la base de todo
Elegimos ZFS sobre NVMe como sistema de almacenamiento por una razón fundamental: la capacidad de hacer snapshots instantáneos y replicación incremental a nivel de bloque. Cada 15 minutos, ZFS toma una foto del estado de los discos virtuales, la compara con la anterior, y envía solo los bloques que cambiaron al segundo servidor a través del enlace dedicado de 2.5 Gbps.
Compresión LZ4: reduce escrituras sin coste de CPU apreciable. atime=off: elimina escrituras innecesarias de timestamps de acceso. ARC de 16GB: caché de lectura en RAM que sirve datos frecuentes sin tocar disco. Thin provisioning: las VMs pueden tener 1TB de disco asignado pero solo ocupan el espacio que realmente usan.
La primera sincronización entre servidores transfirió aproximadamente 43GB en 20 minutos. A partir de ahí, las sincronizaciones incrementales tardan alrededor de 5 segundos, ya que solo viajan los bloques modificados en los últimos 15 minutos.
GPU Passthrough con VFIO
Para conseguir rendimiento nativo de GPU en las máquinas virtuales, usamos VFIO (Virtual Function I/O) que permite asignar dispositivos PCI directamente a una VM. La GPU habla directamente con la máquina virtual sin intermediarios: no hay emulación, no hay overhead de virtualización. Los benchmarks de CUDA dan resultados prácticamente idénticos a una instalación en bare metal, con una diferencia inferior al 3%.
Configuramos dos GPUs en passthrough simultáneo para la VM principal: una NVIDIA RTX 2070 con 8GB de VRAM y una RTX 3060 con 12GB, proporcionando 20GB de VRAM total para inferencia de modelos de IA.
El GPU passthrough bloquea la RAM de la VM con mlock() para que el acceso directo a memoria (DMA) de las GPUs funcione correctamente. Esto significa que la RAM asignada a una VM con GPU no se puede compartir dinámicamente. Para servicios sin GPU, los containers LXC permiten compartir RAM dinámicamente, igual que la CPU, optimizando el uso de recursos del servidor.
Red: triple redundancia
Diseñamos la red con tres capas completamente independientes, cada una con su propio cableado físico y tarjeta de red dedicada:
Red de producción (ISP Principal)
La red principal conectada al router que gestiona las IPs públicas. Por aquí sale el tráfico de las VMs hacia internet y es la red primaria del cluster Proxmox.
Red de failover (ISP Secundario)
Segunda línea de internet con un proveedor diferente. Configurada con una prioridad inferior en la tabla de rutas. Si el ISP principal cae, tanto el host como las VMs redirigen el tráfico automáticamente por esta línea sin intervención manual.
Red de replicación (enlace directo 2.5 Gbps)
Cable directo entre los dos servidores Proxmox dedicado exclusivamente a la replicación ZFS. No comparte ancho de banda con ningún otro tráfico. A 2.5 Gbps, puede transferir aproximadamente 300 MB/s de datos de replicación.
El cluster Proxmox está configurado con dos enlaces de comunicación independientes: uno por cada ISP. Si el switch o la conexión del ISP principal falla, los nodos siguen comunicándose por el ISP secundario y no disparan un failover innecesario. Solo si un nodo no responde por ninguna de las dos redes se activa la migración automática.
El sistema de votación: cómo funciona el failover automático
Este es el corazón de la alta disponibilidad. Con solo dos servidores, hay un problema clásico llamado split-brain: si se pierde la comunicación entre ambos, cada uno cree que el otro ha muerto y los dos intentan arrancar las mismas VMs simultáneamente, lo que podría corromper datos.
La solución es un QDevice: un tercer participante que actúa como árbitro. No necesita ser un servidor potente — en nuestro caso es una máquina Linux existente que ya ejecutaba otros servicios. Solo instala un paquete y emite su voto cuando se le solicita.
Cómo funciona el quorum
El sistema tiene tres votantes con un voto cada uno. Para tomar cualquier decisión crítica (como arrancar una VM en otro nodo), se necesita quorum: al menos 2 de 3 votos a favor.
Detección del fallo
Corosync envía heartbeats continuos entre nodos. Si un nodo no responde durante el timeout configurado, se inicia el proceso de votación. No es un simple ping: es un protocolo con tokens criptográficos que detecta incluso máquinas colgadas (kernel panic, freeze) aunque la tarjeta de red siga activa a nivel eléctrico.
Votación
Los nodos supervivientes y el árbitro votan. Si el servidor principal ha caído, el servidor backup y el árbitro suman 2 votos de 3: hay quorum suficiente para actuar.
Failover: la misma VM arranca en el otro servidor
El gestor de HA de Proxmox arranca la VM en el servidor backup usando la réplica ZFS más reciente. La VM aparece con exactamente la misma IP pública, la misma configuración y los mismos datos. Ambos servidores están conectados al mismo switch y al mismo segmento de red, así que cuando la VM anuncia su IP por ARP, el tráfico se redirige automáticamente al nuevo servidor. Desde el exterior, es el mismo servidor — los usuarios no notan el cambio. Los servicios se restablecen en menos de un minuto.
Failback: vuelta al servidor principal
Cuando el servidor principal vuelve a estar online, el sistema sincroniza los datos nuevos generados durante el failover desde el backup al principal, migra la VM de vuelta y reanuda la replicación normal. Todo de forma automática, sin intervención.
Funcionamiento normal
⚠ Servidor 1 cae — failover automático
✓ Servidor 1 regresa — failback automático
Escenarios de fallo
| Escenario | Resultado | Estado |
|---|---|---|
| Servidor principal cae | Backup + árbitro votan, VM arranca en backup con la misma IP | Automático |
| Servidor backup cae | VM sigue en el principal sin cambios, replicación pausada | Sin impacto |
| Árbitro cae | Todo funciona, se pierde la capacidad de failover automático | Degradado |
| ISP principal cae | Tráfico redirige por ISP secundario automáticamente | Automático |
| Switch ISP principal cae | Cluster sigue comunicándose por ISP secundario (dual-link) | Automático |
| Corte eléctrico total | Al volver la luz, servidor principal arranca, VM inicia, replicación reanuda | Automático |
| Servidor principal colgado (kernel panic) | Heartbeats detectan falta de respuesta, failover automático | Automático |
| Árbitro + principal caen simultáneamente | Backup sin quorum, requiere intervención manual | Manual |
Rendimiento y compartición de recursos
Una de las ventajas clave de ZFS es el thin provisioning. Podemos asignar 1TB de disco virtual a una VM aunque solo use 23GB reales. El espacio restante queda disponible para otras VMs. Es el mismo principio que aplican los grandes proveedores cloud.
Con la CPU, Proxmox permite overcommit total: si asignamos todos los cores a tres VMs, las tres comparten los mismos cores físicos y el hipervisor reparte el tiempo de forma inteligente. Para la RAM, los containers LXC ofrecen compartición dinámica nativa — solo consumen la memoria que realmente necesitan en cada momento.
VPN: malla cifrada entre todos los nodos
Todos los servidores están conectados mediante una VPN WireGuard en una red privada dedicada. Esto permite comunicación cifrada entre nodos independientemente de su ubicación geográfica. Los servicios internos (sistemas de archivos compartidos, APIs de inferencia) viajan por la VPN sin exposición a internet público.
Conclusión
Con hardware accesible y software open source, hemos construido una infraestructura que ofrece las mismas garantías que un entorno empresarial: replicación continua cada 15 minutos, failover automático en menos de un minuto, múltiples capas de redundancia de red con dos proveedores independientes, y rendimiento GPU nativo para cargas de trabajo de inteligencia artificial.
Lo más relevante es que si el servidor principal cae, la misma VM con la misma IP pública y los mismos datos arranca automáticamente en el servidor backup. Desde la perspectiva de los usuarios y servicios externos, no hay interrupción perceptible más allá de unos segundos de reconexión.
Hipervisor: Proxmox VE 9.1 · Almacenamiento: ZFS sobre NVMe 2TB · GPU: NVIDIA RTX 2070 + RTX 3060 (VFIO passthrough) · Red: Dual WAN + enlace directo 2.5 Gbps · HA: Corosync + QDevice (quorum de 3 votos) · VPN: WireGuard mesh · OS Guest: Ubuntu 22.04 LTS + CUDA 13.
