Proxmox VE 9 sustituye los grupos de HA por reglas de ubicación flexibles

Proxmox VE 9 ha actualizado su arquitectura de alta disponibilidad al sustituir los grupos de HA heredados por reglas de HA más granulares. Este cambio afecta a cómo los administradores definen dónde se ejecutan las máquinas virtuales y los contenedores durante la operación normal y tras un fallo de nodo. La actualización requiere una configuración cuidadosa de la afinidad de nodos y la ubicación de recursos para garantizar una conmutación por error fiable sin intervención manual.

Qué ha ocurrido

La última versión de Proxmox VE cambia el mecanismo de control de la ubicación de los invitados desde simples grupos de HA a un sistema basado en reglas almacenado en /etc/pve/ha/rules.cfg. En versiones anteriores, los administradores utilizaban grupos para expresar preferencias sobre qué nodos debían alojar invitados específicos. Proxmox VE 9 deprecia estos grupos en favor de reglas explícitas de afinidad de nodos y afinidad de recursos. Las configuraciones existentes se migran automáticamente a reglas de afinidad de nodos una vez que todos los nodos del clúster ejecutan la versión 9, pero los administradores deben verificar la lógica resultante para evitar comportamientos inesperados.

Este cambio estructural forma parte de un énfasis más amplio en configuraciones robustas de alta disponibilidad que dependen de un quórum adecuado y del aislamiento (fencing). El sistema utiliza dos demonios principales: el gestor local de recursos (pve-ha-lrm) y el gestor de recursos del clúster (pve-ha-crm). Estos componentes coordinan con un temporizador watchdog para asegurar que, si un nodo falla o pierde conectividad de red, sea reiniciado forzadamente antes de que sus invitados sean reiniciados en otro lugar. Esto previene la corrupción de datos en almacenamiento compartido al garantizar que ningún par de nodos escriba simultáneamente en el mismo disco.

Detalles clave

• Las Reglas de HA sustituyen a los Grupos: Las reglas de afinidad de nodos definen dónde puede ejecutarse un invitado, mientras que las reglas de afinidad de recursos mantienen a los invitados juntos o separados. Las reglas no son estrictas por defecto a menos que se configuren explícitamente así.
• Aislamiento mediante Watchdog: Proxmox VE utiliza un temporizador watchdog para aislar los nodos fallidos. Si un nodo pierde el quórum, no puede reiniciar el temporizador, lo que provoca un reinicio de hardware o software para proteger la integridad del almacenamiento compartido.
• Requisitos de Quórum: Una alta disponibilidad fiable requiere al menos tres nodos en el clúster o dos nodos más un QDevice. Los clústeres de dos nodos sin un QDevice corren el riesgo de sufrir escenarios de cerebro dividido (split-brain) donde ningún nodo puede asumir el control de forma segura.
• Políticas de Apagado: Los administradores pueden elegir entre políticas conditional, migrate, failover o freeze para mantenimientos planificados. La política predeterminada conditional detiene los invitados durante el apagado, mientras que migrate intenta primero la migración en vivo.
• Modo de Mantenimiento: Un comando dedicado de modo de mantenimiento migra los invitados de HA fuera de un nodo objetivo y los mantiene alejados hasta que se desactiva el modo, simplificando reparaciones de hardware o actualizaciones.
• Requisito de Pruebas: El autor enfatiza la necesidad de desconectar el cable de alimentación de un nodo de prueba para verificar la conmutación por error, ya que los apagados limpios no activan los mismos mecanismos de aislamiento y recuperación que los fallos reales de hardware.

Contexto

La alta disponibilidad en entornos de virtualización depende del concepto de quórum, que asegura que una mayoría de nodos esté de acuerdo con el estado del clúster. Sin quórum, un clúster no puede distinguir entre un fallo de nodo y una partición de red, lo que conduce a una potencial corrupción de datos si múltiples nodos intentan actuar como primarios. Proxmox VE aborda esto requiriendo un número impar de miembros votantes o un QDevice desempate.

El aislamiento (fencing) es el proceso de aislar un nodo fallido para impedir que acceda a recursos compartidos. En Proxmox VE, esto se logra mediante temporizadores watchdog. Si un nodo deja de responder o pierde contacto con la mayoría del clúster, su temporizador watchdog expira, forzando un reinicio. Este reinicio duro asegura que cualquier bloqueo mantenido por el nodo fallido sea liberado, permitiendo al gestor de recursos del clúster reiniciar de forma segura los invitados afectados en nodos sanos.

Por qué importa

Para equipos que gestionan infraestructura autoalojada, el cambio hacia las reglas de HA ofrece mayor control sobre la distribución de recursos pero introduce complejidad en la configuración. Las reglas de afinidad mal configuradas pueden impedir que los invitados inicien durante un fallo si los nodos preferidos no están disponibles. Comprender la diferencia entre afinidad estricta y no estricta es crítico para asegurar que los servicios esenciales permanezcan online incluso cuando el hardware preferido está offline.

La dependencia de watchdogs y quórum significa que la selección de hardware y la fiabilidad de la red son más importantes que nunca. Usar el watchdog de software predeterminado (softdog) es conveniente pero menos fiable que un módulo de watchdog de hardware dedicado. Los equipos deben asegurarse de que su hardware de servidor soporte y habilite estos módulos para garantizar que el aislamiento ocurra rápidamente durante fallos del mundo real, como cortes de energía o pánicos del kernel.

Además, la distinción entre alta disponibilidad y copias de seguridad sigue siendo un error común. La HA asegura la continuidad del servicio reiniciando invitados en otros nodos, pero no protege contra la corrupción de datos o errores lógicos dentro del propio invitado. Los administradores deben mantener estrategias de copia de seguridad separadas y asegurarse de que las soluciones de almacenamiento compartido, como Ceph o la replicación ZFS, estén correctamente configuradas para minimizar las ventanas de pérdida de datos durante eventos de conmutación por error.

Qué puedes hacer

• Verificar la Configuración de Quórum: Asegúrate de que tu clúster tenga al menos tres nodos o dos nodos con un QDevice para mantener el quórum durante un fallo de un solo nodo.
• Revisar las Reglas de HA: Comprueba /etc/pve/ha/rules.cfg después de actualizar a Proxmox VE 9 para confirmar que las reglas de afinidad de nodos migradas coinciden con tu estrategia de ubicación deseada.
• Configurar Watchdogs de Hardware: Habilita los módulos de watchdog de hardware en /etc/default/pve-ha-manager en lugar de depender únicamente del softdog de software para un aislamiento más fiable.
• Probar la Conmutación por Error de Forma Segura: Realiza una prueba controlada añadiendo una VM desechable a HA y cortando físicamente la alimentación de su nodo anfitrión para observar el proceso de recuperación y los tiempos.
• Establecer la Política de Apagado: Establece explícitamente la política de apagado en datacenter.cfg a migrate si prefieres la migración en vivo durante reinicios planificados, en lugar del comportamiento predeterminado de parada y reinicio.
• Usar el Modo de Mantenimiento: Utiliza la función ha-manager crm-command node-maintenance cuando realices trabajos en un nodo específico para migrar automáticamente los invitados fuera y evitar que regresen hasta que el trabajo esté completo.