Errores de HA en Proxmox: 10 problemas de failover a evitar

La HA de Proxmox falla de la forma más dolorosa cuando el clúster está técnicamente configurado para alta disponibilidad, pero el diseño que lo rodea no puede sostener el failover que esperas. Los problemas habituales son el quórum, el acceso al almacenamiento, el fencing, las reglas de ubicación, la capacidad y una recuperación de aplicaciones que nadie ha probado.

En agosto de 2026, Proxmox recomienda al menos tres nodos en el clúster para tener un quórum fiable, y su gestor de HA usa fencing basado en watchdog para impedir que un nodo caído o aislado siga ejecutando la misma carga de trabajo. Esos dos detalles explican por qué un clúster que parece redundante en un diagrama puede fallar estrepitosamente en la práctica.

¿Qué protege realmente la HA de Proxmox?

La alta disponibilidad de Proxmox gestiona automáticamente las máquinas virtuales y los contenedores seleccionados para que puedan reiniciarse en otro nodo sano después de que falle un host. No hace que el sistema operativo invitado ni la aplicación que corre dentro estén disponibles al instante, y esa distinción importa.

Si una VM de base de datos necesita cuatro minutos para arrancar y otros tres para que la base de datos supere las comprobaciones de salud, la caída de la aplicación dura más que el tiempo que tarda el clúster en detectar el fallo del host. La documentación de Proxmox sitúa la detección de errores y el failover típicos de HA en unos dos minutos, y eso es solo una parte del camino de recuperación.

Si todavía estás decidiendo lo pequeño que puede ser razonablemente un diseño de HA, lee Ceph, HA y el clúster mínimo viable para pymes.

1. ¿Por qué es arriesgado un clúster HA de Proxmox con dos nodos?

Un clúster de dos nodos pierde la mayoría simple cuando desaparece uno de ellos. Proxmox recomienda al menos tres nodos para un quórum fiable porque los nodos que quedan necesitan votos suficientes para decidir qué lado de una partición tiene permiso para actuar.

Un QDevice puede añadir un voto externo a un clúster de dos nodos. Puede ser un diseño útil en entornos pequeños, pero no convierte dos servidores en tres. Sigues teniendo solo dos nodos de cómputo, y un fallo puede dejar todas las cargas de trabajo concentradas en una sola máquina.

El error práctico es planificar solo el quórum y olvidarse de la capacidad. Si el nodo A y el nodo B funcionan cada uno al 70 por ciento de uso de memoria, perder cualquiera de los dos deja sin un lugar seguro donde reiniciarlo todo. El quórum puede estar sano mientras la capacidad no lo está.

La guía sobre el quórum de Proxmox con dos nodos profundiza en ese modo de fallo.

2. ¿Qué pasa cuando el nodo de destino no ve el almacenamiento de la VM?

La HA no puede reiniciar bien una VM en un nodo que no tiene acceso a sus discos. Parece obvio, pero el acceso asimétrico al almacenamiento es una de las formas más fáciles de crear un clúster que funciona en el día a día y falla en una emergencia.

Imagina cuatro nodos. Tres ven un LUN iSCSI, y el cuarto es solo de cómputo y usa otro sistema de almacenamiento. Si una carga de trabajo HA que vive en ese LUN puede acabar en el cuarto nodo, la decisión de ubicación puede resultar inválida para esa VM.

La solución es de arquitectura. Todo nodo elegible para el failover tiene que acceder al almacenamiento que necesita esa carga de trabajo, o tu política de ubicación de HA tiene que mantenerla lejos de los nodos que no pueden ejecutarla. No esperes a un corte de luz para descubrir que la visibilidad del almacenamiento cambia de un nodo a otro.

3. ¿Por qué el fencing importa más que un failover rápido?

El fencing protege los datos al asegurarse de que el nodo caído o aislado ya no puede ejecutar recursos HA antes de que otro nodo los reinicie. Proxmox usa fencing basado en watchdog como parte de su arquitectura de HA.

El escenario peligroso es el split brain. Un lado de una partición de red cree que el otro está muerto, pero el host aislado sigue ejecutando la VM y sigue escribiendo en el almacenamiento. Arrancar una segunda copia en otro sitio puede corromper los datos.

Por eso es mala idea acortar de forma agresiva los temporizadores de fallo sin entender el fencing. Un reinicio más rápido no sirve de nada si aumenta la probabilidad de tener dos escritores activos.

Prueba el comportamiento del watchdog en el hardware real. Un archivo de configuración que dice que hay fencing es una prueba más débil que un test de fallo controlado.

4. ¿Por qué conviene separar la comunicación del clúster del tráfico ruidoso?

El tráfico de Corosync es pequeño, pero sensible a la latencia. Una red de clúster que comparte rutas congestionadas con tareas de copia de seguridad, replicación de almacenamiento, migraciones grandes o switches inestables puede producir síntomas que parecen el fallo de un nodo.

Las recomendaciones de diseño de clústeres de Proxmox hacen hincapié en una red fiable, porque el quórum depende de que los nodos puedan comunicarse de forma constante.

El ancho de banda no es la única métrica que importa. Un enlace de 10 GbE con pérdida de paquetes y latencia impredecible puede ser peor para la comunicación del clúster que una ruta de 1 GbE más tranquila.

Monitorea la pérdida de paquetes, la latencia y el comportamiento de los switches. Si el clúster se vuelve inestable cada vez que empiezan las copias de seguridad, la política de HA no es el sitio donde buscar.

5. ¿Por qué el almacenamiento compartido no equivale automáticamente a HA?

El almacenamiento compartido resuelve la accesibilidad de los discos. No hace nada por la capacidad de cómputo, los fallos de arranque del invitado, las malas reglas de ubicación, las dependencias de red ni el estado de la aplicación.

NFS, iSCSI, Fibre Channel y Ceph pueden ofrecer almacenamiento accesible desde varios nodos, según tu arquitectura. El propio sistema de almacenamiento pasa entonces a formar parte del diseño de disponibilidad.

Un único NAS con una controladora y una sola ruta de red puede dar acceso compartido a todos los nodos Proxmox y seguir siendo un punto único de fallo.

La misma lógica vale para Ceph. Ceph elimina algunas dependencias de un almacenamiento central, pero solo si tienes suficientes dominios de fallo, OSDs sanos y una red adecuada.

Las ventajas y desventajas se tratan en Almacenamiento para HA en Proxmox: Ceph, replicación ZFS o NAS.

6. ¿Puede la replicación ZFS sustituir al almacenamiento compartido para HA?

La replicación ZFS puede reducir la dependencia del almacenamiento compartido, pero cambia el modelo de recuperación. La replicación de almacenamiento de Proxmox copia los volúmenes de los invitados entre nodos según una programación, con un intervalo mínimo documentado de un minuto, así que la copia secundaria puede ir por detrás de la VM activa.

Si un nodo falla de repente, puede que las escrituras más recientes posteriores a la última replicación completada no existan en el destino. Para algunas cargas de trabajo eso es aceptable. Para una base de datos transaccional, puede que no.

No describas la replicación ZFS como HA sin pérdida de datos salvo que la aplicación tenga otro mecanismo que proteja esas escrituras. Lo que tienes que decidir es tu objetivo de punto de recuperación: ¿cuántos datos recientes te puedes permitir perder?

7. ¿Qué problema tienen los antiguos grupos de HA en Proxmox VE 9?

Proxmox VE 9 abandonó los grupos de HA en favor de las reglas de afinidad de nodos de HA. Los grupos de HA existentes quedan obsoletos y se migran al nuevo modelo de afinidad de nodos.

Esto importa en las actualizaciones, porque los viejos supuestos sobre nodos preferidos y el comportamiento de failback pueden sobrevivir en una forma que no has revisado. Después de pasar a Proxmox VE 9, inspecciona cada regla de HA. Confirma qué nodos son elegibles, cuáles son preferidos y si de verdad quieres failback.

Un servicio que vuelve una y otra vez a un nodo preferido después del mantenimiento puede generar movimientos innecesarios. Un servicio con una ubicación demasiado estricta puede volverse imposible de arrancar cuando un nodo está caído.

La política de ubicación debería describir un requisito operativo real en lugar de fijar para siempre la distribución actual.

8. ¿Por qué fallan los clústeres HA durante el mantenimiento planificado?

El mantenimiento planificado es donde descubres si el clúster tiene suficiente capacidad libre. Si vaciar un nodo empuja a los hosts restantes más allá de los límites seguros de memoria o almacenamiento, el diseño no tenía una capacidad N más uno real.

Proxmox ofrece un comportamiento de mantenimiento de HA y políticas de apagado, entre ellas una política de migración que intenta mover los servicios HA en ejecución antes de que siga el apagado. Usa esas funciones de forma deliberada.

Antes de parchear un nodo, comprueba la memoria libre, el margen de CPU, las rutas de almacenamiento y cualquier dispositivo en passthrough que impida la migración. Una VM con una GPU o un HBA en passthrough puede que no se mueva como una VM normal.

El mantenimiento es una versión controlada de un fallo, así que trátalo como una prueba de HA recurrente.

9. ¿Por qué una VM sana puede significar un servicio caído?

El hipervisor sabe si la máquina virtual está en marcha. Puede que no sepa si la aplicación que corre dentro atiende bien a los usuarios.

Una VM Windows puede arrancar con la replicación de Active Directory rota. Una VM Linux puede estar en marcha mientras PostgreSQL sigue atascado en recuperación, y un servidor web puede responder localmente mientras el balanceador de carga no llega a él. La HA de infraestructura no cubre nada de eso.

Monitorea el servicio además del estado de la VM. Añade comprobaciones de salud de la aplicación, comprobaciones de dependencias y pruebas sintéticas externas cuando la carga de trabajo lo justifique.

Si tu objetivo de disponibilidad se define a nivel de servicio de negocio, tu prueba también tiene que definirse a ese nivel.

10. ¿Por qué un clúster HA sin probar no es realmente HA?

El error de HA más caro es dar por hecho que el diseño funciona porque todos los nodos aparecen en verde.

En una ventana de mantenimiento, desconecta un cable, apaga un nodo, rompe una ruta de almacenamiento, desactiva un puerto del switch o reinicia un participante del quórum, y anota qué pasa y cuánto tarda la recuperación. No lo pruebes todo a la vez.

Empieza con un fallo controlado y mide cuatro tiempos: detección, reinicio del invitado, disponibilidad del sistema operativo y disponibilidad de la aplicación. Esas cifras pasan a ser tu referencia real de recuperación.

Después prueba también la ruta de las copias de seguridad. La HA protege el tiempo de actividad frente a algunos fallos de infraestructura, pero no sustituye a las copias de seguridad frente a borrados, corrupción o ransomware.

¿Qué cambiaría primero en un clúster HA de Proxmox frágil?

Primero haría explícito el dominio de fallo. Haría una lista de cada VM en HA, los nodos que pueden ejecutarla, el almacenamiento que necesita, sus dependencias de red y la capacidad libre necesaria cuando falla un nodo. Luego probaría el fallo de un host.

Si el clúster tiene solo dos nodos, arreglaría el diseño del quórum antes de añadir más cargas de trabajo HA. Si el acceso al almacenamiento cambia según el nodo, arreglaría las reglas de ubicación o la arquitectura de almacenamiento antes de fiarme del reinicio automático. Si el clúster no puede perder un host sin agotar la RAM, reduciría la carga o añadiría capacidad.

Un clúster más pequeño con un comportamiento predecible ante fallos es más útil que un diseño de HA complicado al que nunca se ha obligado a fallar.