Un clúster Proxmox HA instalado en producción. Failover probado en un entorno de prueba. Nunca probado en producción. Al caer el primer nodo, las VMs quedaron bloqueadas durante 45 minutos porque el quorum no estaba configurado correctamente. Este es un escenario real, una experiencia directa que subraya lo crítico que es no solo instalar un clúster Proxmox HA, sino también verificar cada uno de sus aspectos. La alta disponibilidad no es una opción, es una necesidad para cualquier entorno empresarial que gestione cargas de trabajo de misión crítica. Si un clúster no funciona como se espera durante una emergencia, su valor es nulo. Esta guía proporciona una checklist detallada para la instalación y verificación de un clúster Proxmox HA, basada en años de experiencia en campo con cientos de VMs.
Requisitos Previos / Entorno de Prueba
Antes de adentrarnos en la instalación, es fundamental preparar la infraestructura base. Dos aspectos son cruciales para la estabilidad y fiabilidad de un clúster Proxmox HA: la red dedicada para el tráfico del clúster y la perfecta sincronización temporal entre todos los nodos.
Red dedicada para el tráfico del clúster
El tráfico de heartbeat y Corosync, esencial para la comunicación entre los nodos y la gestión del quorum, debe estar aislado. Utilizar una red separada garantiza que posibles congestiones en la red de gestión o de las VMs no afecten la estabilidad del clúster. Idealmente, cada nodo debería tener al menos dos interfaces de red físicas dedicadas al tráfico Corosync, configuradas en un bonding (ej. LACP o balance-rr) para redundancia y rendimiento. En entornos con más de 300 VMs, la estabilidad de la red del clúster es prioritaria. Estudios recientes indican que el 30% de los split-brain en clústeres HA son causados por problemas de red (ClusterLabs Report 2025).
NTP sincronizado
La precisión temporal es un requisito no negociable para el correcto funcionamiento del quorum. Una desalineación, incluso mínima, entre los relojes de los nodos puede generar problemas de quorum, causando bloqueos o split-brain. Configura todos los nodos Proxmox para que se sincronicen con servidores NTP fiables, preferiblemente internos a tu red o pools públicos como pool.ntp.org. Verifica regularmente el estado de la sincronización NTP.
Instalación del Clúster y Quorum Device
Una vez preparados los requisitos previos, podemos proceder con la creación y expansión del clúster.
Creación del clúster
El primer paso es crear el clúster desde el primer nodo. Este comando inicializa el clúster y lo prepara para la adición de otros nodos.
pvecm create myclusterAdición de nodos al clúster
Después de crear el clúster, puedes añadir los nodos restantes. Asegúrate de que el firewall esté configurado correctamente para permitir la comunicación Corosync en los puertos 5404 y 5405 UDP.
pvecm add <ip-nodo1>Reemplaza
Verificación del estado del clúster
Después de añadir los nodos, verifica el estado del clúster para asegurarte de que todos los nodos estén en línea y que el quorum esté establecido.
pvecm statusQuorum Status y Quorum Device
El quorum es el mecanismo que previene el split-brain, asegurando que solo una partición del clúster pueda operar. En un clúster con un número par de nodos (especialmente dos), un Quorum Device (QDevice) es esencial. Un QDevice es un host externo ligero (ej. un Raspberry Pi) que actúa como un voto adicional, permitiendo al clúster mantener el quorum si uno de los dos nodos falla.
corosync-quorumtool -sEste comando te mostrará el estado del quorum. Asegúrate de que el número de votos activos sea suficiente para mantener el quorum (generalmente, (Número_Nodos / 2) + 1).
Almacenamiento Compartido: Ceph o NFS/iSCSI
Para la alta disponibilidad, las VMs deben poder acceder a sus discos desde cualquier nodo del clúster. Esto requiere un almacenamiento compartido.
Ceph: Solución Distribuida
Ceph es una solución de almacenamiento distribuido integrada nativamente en Proxmox. Ofrece alta disponibilidad, escalabilidad y rendimiento. La instalación de Ceph en Proxmox es relativamente sencilla.
pveceph init --network 10.10.10.0/24 # Inicializa Ceph en el nodo actual
pveceph createmon # Crea un monitor Ceph
pveceph createosd /dev/sdb # Añade un disco como OSD (Object Storage Device)
pveceph createpool vm-storage # Crea un pool para las VMsRecuerda configurar Ceph en todos los nodos y tener al menos 3 OSDs para la redundancia. La estabilidad de Ceph es directamente proporcional al número de OSDs y a la calidad de la red de interconexión.
NFS/iSCSI: Almacenamiento Externo
Como alternativa a Ceph, puedes utilizar almacenamiento externo basado en NFS o iSCSI. Asegúrate de que el almacenamiento también sea de alta disponibilidad y que los nodos Proxmox tengan conectividad redundante al array de almacenamiento. Un único punto de fallo en el almacenamiento compartido anularía la HA del clúster Proxmox.
HA Groups y Políticas de Failover
Proxmox HA Manager gestiona automáticamente el reinicio de las VMs en un nodo funcional en caso de fallo. Puedes definir grupos HA y políticas específicas.
Configuración de HA Manager
ha-manager status te dará una visión general del estado actual de los recursos HA. Puedes definir qué VMs o contenedores deben ser gestionados por el HA y con qué políticas (ej. max_relocate, max_restart).
ha-manager statusLos HA Groups permiten agrupar VMs que deben estar en el mismo nodo o en nodos diferentes, evitando que un failover mueva todas las VMs críticas a un único host, sobrecargándolo. Esto es particularmente útil en entornos con más de 2.000 estaciones de trabajo virtualizadas.
Prueba de Failover y Verificación de Funcionamiento
Este es el paso más crítico: la verificación práctica de que el clúster HA funciona como se espera. No basta con confiar en las configuraciones teóricas.
Prueba de failover manual
Simula el failover de una VM para verificar que se migra y reinicia correctamente en otro nodo.
ha-manager crm-command migrate <vmid> <node>Reemplaza
Simulación de un fallo real
Desconecta la red de un nodo, apaga un nodo forzadamente. Observa los tiempos de recuperación de las VMs. Esta es la única forma de estar seguro de que la configuración HA es robusta. Mide el tiempo de inactividad y asegúrate de que se ajuste a los SLA previstos. En un entorno empresarial, un failover debe ocurrir en pocos minutos, no en 45.
Monitoreo del Clúster con Prometheus + Grafana
Un clúster HA sin monitoreo proactivo es una bomba de tiempo. Integra Proxmox con Prometheus para la recolección de métricas y Grafana para la visualización y las alertas. Monitorea el estado del quorum, el uso de recursos de los nodos, la latencia del almacenamiento y el estado de las VMs HA. Alertas críticas para corosync_quorum_votes_total o proxmox_ha_resource_status pueden salvarte de un desastre.
Errores Comunes y Resolución de Problemas
- Falta de red dedicada para Corosync: Causa latencia e inestabilidad. Solución: configura una interfaz de red separada y un bonding.
- NTP no sincronizado: Lleva a split-brain. Solución: configura servidores NTP en todos los nodos y verifica regularmente.
- Quorum insuficiente en clústeres de 2 nodos: El clúster se bloquea si un nodo cae. Solución: implementa un QDevice.
- Almacenamiento compartido no HA: Si el almacenamiento falla, falla todo. Solución: usa Ceph o almacenamiento SAN/NAS con redundancia.
- Falta de pruebas de failover reales: La teoría no es suficiente. Solución: simula fallos reales y mide los tiempos de recuperación.
- Firewall no configurado correctamente: Bloquea el tráfico Corosync. Solución: abre los puertos UDP 5404 y 5405.
- Versiones de Proxmox no alineadas: Problemas de compatibilidad. Solución: mantén todos los nodos con la misma versión y nivel de parches.
Conclusiones con Puntos Clave Operativos
La implementación de un clúster Proxmox HA es un paso fundamental para garantizar la continuidad operativa. Sin embargo, la instalación es solo el comienzo. El verdadero desafío reside en la verificación y el mantenimiento constante. Recuerda: una red dedicada para Corosync, NTP sincronizado y un Quorum Device adecuado son pilares no negociables. Integra un monitoreo robusto y, sobre todo, prueba el failover en condiciones reales. Solo así podrás estar seguro de que tu clúster resistirá cuando la producción esté en riesgo. La tranquilidad de un entorno IT estable es el resultado de una planificación meticulosa y de pruebas rigurosas.
Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026
Lee también: Prometheus y Grafana: Checklist de Instalación y Alertas Críticas
Actualizado: Julio 2026
