La alta disponibilidad es una de las capacidades más solicitadas cuando una empresa está evaluando su infraestructura de virtualización. También es una de las más frecuentemente mal implementadas, no porque la tecnología falle, sino porque se implementa sin los requisitos previos que la hacen funcionar de forma confiable.
Este artículo describe cómo funciona la alta disponibilidad en un clúster Proxmox, qué condiciones deben cumplirse para que tenga sentido implementarla, y cuáles son los errores de diseño más frecuentes que anulan su valor en producción.
Cómo funciona la HA en Proxmox
Proxmox VE implementa alta disponibilidad mediante un sistema de clúster basado en Corosync para la comunicación entre nodos y un gestor de HA propio que monitorea el estado de las máquinas virtuales marcadas como críticas.
Cuando el sistema detecta que un nodo del clúster deja de responder, el gestor de HA evalúa el estado del clúster usando el sistema de quorum: para que el clúster pueda tomar decisiones autónomas, más de la mitad de los nodos deben estar operativos y en comunicación. Si el quorum se mantiene, las VMs del nodo caído se reinician automáticamente en los nodos disponibles según las reglas de prioridad configuradas.
El tiempo de failover depende del tiempo de detección configurado y del tiempo de arranque de las VMs. En configuraciones estándar, ese tiempo está entre uno y cinco minutos. Las conexiones activas en el momento del fallo se interrumpen y deben restablecerse desde el cliente.
Requisitos mínimos para una implementación funcional
Tres nodos como mínimo. Con dos nodos, el sistema de quorum no puede resolver de forma autónoma la caída de un nodo: si el nodo A cae, el nodo B no puede determinar si A está caído o si es B quien perdió la conectividad. El resultado es que el clúster se suspende para evitar el split-brain. Proxmox permite configurar un QDevice externo basado en Corosync qdevice para resolver el quorum con dos nodos, pero esto requiere un tercer host que actúa como árbitro — lo que en la práctica equivale a tener tres dispositivos físicos de todas formas, con la complejidad adicional de gestionar un componente cuyo único rol es el arbitraje de quorum.
Red dedicada para tráfico de clúster. La comunicación Corosync entre nodos y la sincronización de almacenamiento deben usar una red separada del tráfico de producción y de acceso a las VMs. Sin esa separación, un pico de tráfico de datos puede generar latencia en la comunicación del clúster y provocar falsas alarmas de nodo caído, con el consecuente failover innecesario.
Almacenamiento compartido o replicado. Para que una VM pueda reiniciarse en otro nodo, su almacenamiento debe ser accesible desde ese nodo. Esto puede implementarse con un NAS compartido accesible por todos los nodos, con replicación de discos usando la herramienta de replicación integrada de Proxmox, o con almacenamiento distribuido como Ceph. Cada opción tiene implicaciones de rendimiento, costo y complejidad operacional diferentes.
Capacidad técnica para operar el clúster. Alguien en el equipo debe entender cómo funciona el quorum, cómo se reintegra un nodo después de una falla, y cómo se valida que el failover funciona correctamente. Sin esa capacidad, la alta disponibilidad no es una garantía operacional: es una configuración que nadie sabe cómo gestionar cuando se activa.
Errores de diseño frecuentes
HA en todas las VMs sin criterio de criticidad. No todas las máquinas virtuales de un entorno requieren alta disponibilidad. Marcar todas las VMs como HA aumenta el tiempo de recuperación en caso de falla real —porque el sistema debe reiniciar más VMs— y dificulta la gestión de recursos. El criterio correcto es identificar cuáles servicios tienen costo operacional real en caso de inactividad y marcar solo esas VMs.
Failover nunca probado en producción. El error más frecuente es configurar HA y asumir que funciona sin haberlo probado en condiciones controladas. La prueba correcta es simular la caída de un nodo apagándolo físicamente o deteniendo el servicio de Corosync, y verificar que las VMs marcadas como HA se reinician en el tiempo esperado y con los datos en el estado correcto.
Sin procedimiento documentado de recuperación de nodo. Cuando un nodo vuelve al clúster después de una falla, hay un proceso de reintegración que debe seguirse: verificar la integridad del almacenamiento, confirmar que el nodo está en estado correcto antes de devolver VMs, y validar que el quorum está estable. Si ese procedimiento no está documentado, cada incidente real se gestiona de forma improvisada.
Red de clúster compartida con tráfico de producción. Es el error de infraestructura más frecuente en implementaciones iniciales. La solución correcta es una interfaz de red dedicada para Corosync, separada de la red de gestión y de la red de datos de las VMs.
El proceso de implementación recomendado
Antes de configurar el clúster: documentar qué VMs son candidatas a HA y justificar la criticidad de cada una. Ese documento es el criterio de diseño del clúster.
Durante la implementación: construir el clúster en ambiente de pruebas, configurar HA en las VMs identificadas, y ejecutar la prueba de failover antes de mover cargas de producción. El failover debe probarse al menos una vez por cada tipo de almacenamiento usado.
Después de la implementación: documentar el procedimiento de recuperación de nodo y programar una prueba de failover semestral en producción, en horario de bajo impacto. Las implementaciones de HA que nunca se prueban en producción tienen una tasa de fallo real mayor que las que se prueban regularmente.
Cuándo Aleph Server recomienda no implementar HA todavía
Cuando el equipo no tiene experiencia operando un clúster Proxmox. Cuando el hardware disponible no cumple el mínimo de tres nodos con red dedicada. Cuando el análisis de criticidad no identifica servicios con costo operacional real en caso de inactividad. En esos casos, la recomendación es una infraestructura bien gestionada con backup verificado y procedimiento de recuperación documentado, que tiene un costo de recuperación mayor pero una complejidad operacional significativamente menor.
