Congela tu clúster: el paso que no puedes olvidar en Proxmox HA

Pocas cosas provocan tanto pánico como ver que tu clúster de Proxmox empieza a reiniciarse espontáneamente en mitad de lo que iba a ser una mejora de hardware rutinaria. En un segundo todo funciona con normalidad; al siguiente se desata el caos, y te quedas intentando recomponer lo sucedido mientras asumes el golpe en tu reputación.

Eso fue exactamente lo que le ocurrió a un usuario de Proxmox que decidió renovar la distribución eléctrica en su rack de servidores. Tenía un plan metódico: sustituir equipamiento, reiniciar un switch Dell de 48 puertos y reanudar la actividad con normalidad. Pero olvidó un paso crítico: poner la alta disponibilidad (HA) en modo mantenimiento.

La reacción en cadena que nadie quiere vivir

Esto fue lo que falló: en esa infraestructura, toda la comunicación de clúster de Corosync transitaba a través de ese único switch Dell de 1G. Al reiniciarse el conmutador, la comunicación de Corosync cayó en picado de golpe, y Proxmox ejecutó con precisión aquello para lo que fue diseñado: activó los mecanismos de HA, asumió que los nodos estaban caídos y empezó a migrar o reiniciar máquinas virtuales a toda prisa para intentar mantener los servicios con vida.

El desenlace fue una tormenta de reinicios en todo el clúster que nadie anticipó.

Hay que reconocerle al autor que no culpó al sistema. Conocía la existencia del modo mantenimiento en HA; simplemente lo olvidó. Un pequeño descuido en una planificación por lo demás impecable se convirtió en una dura lección sobre lo frágil que resulta una arquitectura incompleta o con puntos únicos de fallo.

Qué es el modo mantenimiento en HA y por qué importa

Si administras un clúster de Proxmox y utilizas HA, este paso no puedes saltártelo bajo ningún concepto. El modo mantenimiento en este contexto significa indicarle al clúster que permanezca en calma y no reaccione si cree que un nodo ha caído. Estás silenciando deliberadamente al watchdog para evitar que intente "protegerte" mientras ejecutas tareas programadas.

Sin esa orden previa, el gestor de HA de Proxmox interpreta que el nodo ha muerto en cuanto pierde contacto de red e intenta ayudar reiniciando las máquinas virtuales críticas en otros nodos, a menudo con consecuencias imprevistas y desastrosas.

El procedimiento correcto es directo: antes de cualquier intervención que pueda interrumpir la comunicación del clúster, especialmente al manipular switches o la alimentación de equipos de red, cambia el estado de esos recursos de HA a modo "ignored".

Consejos prácticos de administradores en primera línea

Este no fue un caso aislado. La publicación encendió un debate muy participativo entre administradores de Proxmox, y muchos compartieron exactamente la misma experiencia con comportamientos imprevistos del clúster al no desactivar la HA adecuadamente durante actualizaciones, cambios eléctricos o reconfiguraciones de red.

La frustración aumenta porque todavía no existe una opción en la interfaz gráfica para poner la HA en mantenimiento. Como comentaba un usuario: "Desde 2023, ¿cómo es posible que esto aún no esté en la interfaz web?". Una queja comprensible: Proxmox ha avanzado mucho incorporando funciones a la consola visual, pero la gestión fina de HA sigue dependiendo exclusivamente de la línea de comandos, al menos por ahora.

El comando que habría evitado el incidente es el siguiente:

sudo ha-manager crm-command set vm:<VMID> state=ignored

También puedes ejecutarlo para múltiples máquinas virtuales, impidiendo que Proxmox intente migrarlas o reiniciarlas por su cuenta.

En el debate surgió otra confusión frecuente: un usuario intentó poner el nodo en sí en mantenimiento pensando que bastaba, y no es así. Es necesario deshabilitar la HA tanto a nivel de recurso como a nivel de nodo. Poner un nodo en modo mantenimiento vacía las máquinas virtuales hacia otros hosts, pero no detiene los intentos de HA de reubicarlas, cuando lo que se necesitaba era evitar que el servicio tomara cualquier acción.

Diseñar para la resiliencia y evitar tropiezos evitables

Hay una lección más amplia aquí que va más allá de cambiar un parámetro de HA. Varios participantes aportaron recomendaciones de infraestructura que evitan este tipo de crisis en el clúster desde el inicio:

Utiliza múltiples interfaces para Corosync. Proxmox lo soporta nativamente, y disponer de rutas redundantes (por ejemplo, enlaces agregados entre switches distintos) marca la diferencia entre una disponibilidad impecable y una caída general.

Elimina puntos únicos de fallo. Hacer pasar todo el tráfico de Corosync por un único switch es arriesgarse a problemas graves. Se recomiendan despliegues con dos conmutadores independientes, con separación mediante VLANs para el tráfico de Corosync ring 0 y ring 1. La agregación de enlaces en modo active-backup es una elección habitual porque evita la complejidad de LACP y no exige apilamiento ni funciones avanzadas en el switch.

Evita enrutar Corosync a través de cortafuegos. Si el cortafuegos se reinicia o sufre un retardo, el clúster puede perder el quórum o algo peor; mantén siempre el tráfico de Corosync en VLANs aisladas y sin enrutamiento intermedio.

Un participante expuso un ejemplo ejemplar: dos switches de 10G, dos interfaces por nodo en active-backup y VLANs dedicadas y aisladas para cada anillo. Cuando desconectó por accidente ambos switches durante una migración de SAIs, el clúster resistió sin problemas. No hubo split-brain ni tormenta de reinicios: solo una única VM que requirió un reinicio manual puntual.

Qué comprobar antes de cualquier mantenimiento

Esta es la lista de verificación básica:

1. Pon las máquinas virtuales gestionadas por HA en estado "ignored". Esto le indica al clúster que no las toque, pase lo que pase.

2. Si vas a reiniciar switches o cualquier equipo que afecte a Corosync, reparte antes ese tráfico entre múltiples interfaces y conmutadores.

3. No asumas que "modo mantenimiento" significa lo mismo en todas partes: el mantenimiento del nodo es diferente al mantenimiento de HA.

4. Documenta tu plan detalladamente por escrito; no confíes solo en tu memoria. Los años de experiencia no cambian este hecho: un procedimiento escrito reduce drásticamente el margen de error.

Conclusión

El modo mantenimiento merece un botón dedicado en la interfaz gráfica, pero sobre todo actúa como un recordatorio indispensable: tu clúster solo será tan fiable como los supuestos técnicos que hayas contemplado en su diseño.

Antes de tu próxima ventana de mantenimiento, revisa a fondo tu lista de tareas y pon la HA en pausa cuando corresponda. Por muy sólido que parezca tu plan, si olvidas ese único ajuste, tu clúster de Proxmox puede desestabilizarse en el momento más inoportuno.