Durante mucho tiempo tuve Proxmox con varios nodos pero sin HA configurado. Cada nodo vivía su vida: si se caía el nodo donde estaba corriendo mi agente de Gemology, ese servicio desaparecía hasta que yo me daba cuenta y lo encendía manualmente. Con dos o tres VMs es tolerable. Con más de diez servicios corriendo, te quedas sin noches tranquilas.
Proxmox High Availability es el mecanismo que permite que cuando un nodo falla, las VMs que tenía ese nodo se reinicien automáticamente en los nodos que siguen vivos. No es migración en caliente, que eso requiere hardware y configuración diferente. Es reinicio: la VM se apaga en el nodo que falla y se arranca en otro nodo del cluster. Para la mayoría de servicios del homelab, eso es suficiente.
Lo que no te dice la documentación de primeras es que para que HA funcione bien necesitas tres cosas: al menos 3 nodos, almacenamiento compartido o replicado, y entender cómo funciona el quorum de Corosync. Si no tienes las tres, te vas a frustrar.
El problema del quorum#
Corosync es el sistema de clustering que usa Proxmox para que los nodos se comuniquen y tomen decisiones. Para evitar el problema del “split-brain” (dos partes del cluster piensan que la otra mitad está muerta y ambas intentan tomar el control), Corosync requiere quorum: más de la mitad de los nodos del cluster tienen que estar de acuerdo para tomar decisiones.
Con 2 nodos, si se cae la comunicación entre ellos, ninguno tiene quorum y el cluster se paraliza. Con 3 nodos, puedes perder 1 y el cluster sigue funcionando con quorum de 2.
Aquí es donde entra una opción interesante si no tienes un tercer nodo completo: el QDevice. Puedes poner un proceso ligero en una máquina pequeña (una Raspberry Pi, un Mac mini, cualquier Linux) que actúa como desempate de quorum sin necesidad de ser un nodo Proxmox completo.
Yo tengo tres nodos físicos en mi cluster así que no necesito QDevice, pero si tu situación es dos nodos, esta es la opción para no tener que comprar un tercer servidor.
Almacenamiento: el otro requisito#
HA necesita que las VMs que quieres proteger estén en almacenamiento accesible desde cualquier nodo del cluster. Hay dos formas de conseguirlo:
Almacenamiento compartido (Ceph, NFS, iSCSI): todos los nodos leen y escriben en el mismo backend. Cuando una VM migra o se reinicia en otro nodo, accede a los mismos datos sin copiar nada.
Replicación (Proxmox Replication): Proxmox replica los discos de la VM desde el nodo principal a uno o más nodos de destino a intervalos regulares. Cuando el nodo principal falla, el nodo de destino tiene una copia reciente (con un posible lag de minutos según tu configuración) y puede arrancar la VM desde ahí.
Tengo Ceph configurado en el cluster, así que el almacenamiento compartido está resuelto. Si vas a montar HA y no tienes Ceph, la replicación es una opción viable, pero asume que puedes perder los cambios de los últimos minutos antes del fallo.
Para VMs con bases de datos o estados críticos, la pérdida de datos aunque sea de segundos duele. Para un agente que envía mensajes, un servidor web estático o un bot, que se reinicie con el estado de hace cinco minutos es perfectamente aceptable.
Configurar HA en Proxmox#
El proceso tiene dos partes: crear los grupos HA y añadir las VMs a esos grupos.
Grupos HA#
Un grupo HA define qué nodos pueden ejecutar las VMs del grupo y con qué prioridad. Vas a Datacenter > HA > Groups y creas uno nuevo.
Puedes especificar nodos con prioridades. Por ejemplo, si quieres que la VM corra preferentemente en el nodo1 y use nodo2 o nodo3 solo como fallback:
| |
El scheduler de HA intentará que la VM esté en el nodo con mayor prioridad disponible. Cuando el nodo1 vuelve a estar online después de un fallo, puede migrar la VM de vuelta automáticamente si tienes activada la opción “restricted”.
La opción “nofailback” hace que aunque el nodo original vuelva, la VM se quede en el nodo donde aterrizó. Útil para evitar migraciones innecesarias si tu cluster tiene nodos equilibrados.
Añadir VMs al grupo#
Vas a Datacenter > HA > Resources y añades la VM con el grupo que acabas de crear. El estado inicial es “started” que significa que HA quiere que esa VM esté corriendo en algún nodo del grupo.
Los estados posibles son:
- started: HA intenta que la VM esté corriendo. Si se cae el nodo, la reinicia en otro.
- stopped: HA no intenta arrancarla. Si el nodo falla, no hace nada.
- disabled: HA ignora esta VM.
Para testing, puedo recomendar usar “stopped” al principio y probar el mecanismo manualmente antes de dejarlo en “started” con VMs de producción.
El watchdog#
El sistema HA de Proxmox usa un watchdog de hardware o software para detectar que el nodo sigue vivo. Si el proceso del watchdog no recibe un “ping” periódico, el nodo se reinicia solo. Esto es fundamental para el HA: sin watchdog, un nodo que cuelga (no apagado, sino bloqueado) nunca sería detectado como muerto y los otros nodos no moverían las VMs.
Por defecto Proxmox usa el watchdog de software. Si tienes hardware con watchdog en la BIOS/UEFI, puedes configurarlo para mayor fiabilidad.
Probando el failover#
La única forma de saber si HA funciona es probarlo. Hay dos formas de forzar un fallo:
Opción 1: Apagado limpio del nodo
Apagar el nodo desde Proxmox o con poweroff. El cluster detecta que el nodo se fue y mueve las VMs. El problema es que esto es demasiado limpio y no simula un fallo real.
Opción 2: Forzar una caída abrupta
| |
Esto provoca un kernel panic inmediato. El watchdog no recibe el ping, el resto del cluster lo detecta como nodo muerto, y el sistema HA inicia el proceso de mover las VMs.
La primera vez que lo hice fue bastante tenso. El nodo se cayó, el cluster tardó unos 30-60 segundos en detectarlo (configurable, pero con trade-offs), y luego las VMs empezaron a aparecer en los otros nodos. Tardaron entre 2 y 4 minutos en estar completamente operativas, dependiendo del tamaño del disco y la velocidad de Ceph.
Para servicios que toleran un downtime de pocos minutos, esto es perfectamente aceptable. Para bases de datos críticas o servicios que necesitan estar up 24/7, necesitas algo más sofisticado (o simplemente más dinero).
El tiempo de recuperación#
El tiempo desde que falla el nodo hasta que la VM está operativa en otro nodo depende de varios factores:
Tiempo de detección: Por defecto Proxmox espera para confirmar que el nodo realmente está muerto antes de tomar acción. Demasiado agresivo y puedes migrar VMs de un nodo que solo tuvo un pico de carga. Demasiado conservador y tardas más en recuperarte. El valor por defecto suele ser suficiente.
Tamaño de la VM: Una VM pequeña con 1 CPU y 1 GB de RAM arranca en segundos. Una VM con 8 GB de RAM y discos grandes tarda más porque Ceph tiene que resolver la asignación del almacenamiento en el nuevo nodo.
Carga del cluster en ese momento: Si el cluster está bajo presión cuando ocurre el fallo, los tiempos suben.
En condiciones normales de mi homelab, el tiempo de recuperación está entre 2 y 5 minutos. Para un servicio que funciona 24/7 y puede tolerar eso, es una diferencia enorme frente a “esperar a que el admin se despierte y lo reinicie”.
Servicios que merece la pena proteger con HA#
No todo necesita HA. Añadir VMs a los grupos HA tiene un coste: el scheduler tiene más trabajo de gestión, y si hay muchos failovers, el cluster puede ponerse bajo presión.
Lo que merece la pena proteger:
Servicios de red críticos: tu router virtual, DNS interno, VPN. Si estos caen, el resto del homelab se vuelve inaccesible.
Bots y agentes con SLA: si tienes agentes que responden mensajes o monitorizan cosas y alguien depende de ellos, un downtime de varias horas es un problema real.
Bases de datos de aplicaciones: especialmente si otras VMs dependen de ellas.
Lo que no necesita HA:
Workloads de procesamiento en lote: si es una tarea que procesa datos cada noche, un reinicio simplemente reprocesa el trabajo.
VMs de desarrollo o testing: si está caída hasta el día siguiente, no pasa nada.
Servicios con alta tolerancia a interrupción: un servidor Plex puede estar 10 minutos caído sin que sea un drama.
Lo que aprendí a las malas#
Dos cosas me dieron problemas cuando lo configuré por primera vez.
La primera: no tener el almacenamiento bien dimensionado para Ceph. Cuando Ceph está bajo presión de espacio, el tiempo de recuperación sube muchísimo porque las operaciones de I/O se ralentizan. Mantén Ceph por debajo del 70-75% de capacidad.
La segunda: las VMs con direcciones IP fijas que dependían del nodo donde corrían. Tenía algunas VMs con IPs ligadas a la interfaz física del nodo (un fallo de diseño mío). Cuando hacían failover a otro nodo, esa IP ya no era accesible desde la red del homelab. La solución es asegurarse de que las VMs usen bridges de red virtuales correctamente configurados, no IPs de interfaces físicas del host.
Si tienes un cluster Proxmox con varios nodos y no has configurado HA todavía, el tiempo de configuración inicial son unas horas, pero el ahorro en noches sin dormir parchando servicios caídos lo vale con creces.
Referencias#
- Documentación oficial de Proxmox HA
- Corosync QDevice
- Post relacionado: Velero: backups automáticos para tu cluster K3s
- Post relacionado: Restic: backups incrementales para homelab