Apagado con UPS en Proxmox: el orden del clúster importa

Un apagado con UPS para un único host de Proxmox es simple: detectas batería baja, detienes los sistemas invitados y apagas la máquina. En un clúster resulta más complicado, porque HA puede intentar reiniciar VMs en nodos que ya se están preparando para apagarse, Ceph puede perder suficientes OSDs como para bloquear la E/S y un servidor de backup puede utilizar un modelo de permisos de API por completo diferente.

PVE-UPS intenta resolver estos problemas en sus actualizaciones recientes. El proyecto ya era un pequeño contenedor LXC o Docker que supervisa un UPS mediante SNMP o a través de un servidor Network UPS Tools existente, y apaga los hosts de Proxmox mediante la API. No necesita agentes en cada nodo y permanece en modo de simulación hasta que el administrador lo activa de forma explícita.

Las versiones más recientes incorporan compatibilidad con Proxmox Backup Server, múltiples webhooks, autocomprobaciones más rigurosas y una lógica beta de apagado coordinado en clúster. La lógica de clúster es el gran cambio, porque cuando hay un clúster de por medio, el orden en el que se apagan los componentes forma parte del diseño de tu almacenamiento y tu alta disponibilidad.

¿Por qué la alta disponibilidad puede empeorar un corte eléctrico?

Proxmox HA existe para recuperar servicios cuando un nodo desaparece. Durante un apagado deliberado del clúster, esa recuperación es justo lo que no quieres que ocurra.

Imagina un clúster de tres nodos funcionando con batería. El nodo A alcanza su umbral de apagado y se desconecta. Si HA sigue activo, el clúster puede interpretar esto como una avería e iniciar la migración o el reinicio de servicios en los nodos B y C, que operan con la misma batería limitada y podrían estar a escasos minutos de su propio apagado. El clúster termina realizando más trabajo cuando debería estar liberando carga, por lo que el nuevo modo de clúster de PVE-UPS puede utilizar el mecanismo disarm-ha de Proxmox antes de que caiga el primer nodo.

La documentación actual de Proxmox HA describe un estado desarmado en el que se liberan los watchdogs en todo el clúster y se detienen el fencing automático, el failover y la recuperación. Proxmox advierte con claridad de que los servicios no están protegidos mientras HA está desarmado, por lo que este periodo debe ser breve. Para un apagado controlado es exactamente lo que buscas, ya que los nodos se van a apagar a propósito y el clúster no debe intentar compensar esa ausencia.

PVE-UPS cataloga esta preparación de clúster como beta y requiere Proxmox VE 9.2 o posterior para disarm-ha. En entornos 8.x más antiguos aplica una preparación de clúster reducida y no pretende ofrecer el mismo comportamiento de HA. Me parece un acierto, ya que una herramienta de automatización para UPS no debería dar por sentado sin comprobar que existe una función de clúster cuando el corte eléctrico ya está en marcha.

Para un contexto más amplio sobre almacenamiento y HA, consulta el hub de Proxmox de Mr.PlanB. El comportamiento de un clúster ante un corte de suministro depende en gran medida de cómo se diseñó desde el principio.

¿Por qué Ceph altera la secuencia de apagado?

En un clúster hiperconvergente con Ceph, el almacenamiento puede quedar inaccesible antes de que el último nodo de Proxmox se apague.

La propia documentación de Proxmox sobre el apagado de Ceph comienza con una regla que parece evidente pero que resulta fácil pasar por alto en la automatización: detener primero a todos los clientes de Ceph. En un entorno hiperconvergente de Proxmox, los clientes son principalmente las VMs y contenedores que utilizan RBD o CephFS. Solo cuando hayan dejado de acceder a Ceph se debe preparar el clúster de almacenamiento para su apagado. Proxmox recomienda entonces comprobar la salud de Ceph, activar la bandera noout para que los OSDs no se consideren perdidos de forma definitiva durante la parada programada y apagar los nodos en un orden ordenado.

Un apagado genérico host por host puede equivocarse aquí, por lo que PVE-UPS incluye una opción independiente para Ceph hiperconvergente. Su secuencia respeta la cadena de dependencias:

1. Desarmar HA.
2. Detener cada sistema invitado en el clúster.
3. Aplicar los ajustes de mantenimiento en Ceph.
4. Apagar los nodos en el orden configurado.

El paso 2 es donde un planteamiento más simple falla. Si el nodo A simplemente apaga sus propias VMs y se desconecta mientras siguen corriendo máquinas en los nodos B y C, el pool de Ceph restante puede caer por debajo del recuento de réplicas necesario para operar con E/S, y esas VMs supervivientes pueden quedar bloqueadas a nivel de disco. El nodo B intentará entonces apagar sistemas invitados cuyos discos virtuales han dejado de responder, y el proceso de apagado puede encallarse mientras la batería del UPS continúa agotándose. Es un escenario de avería mucho más grave que un simple host ignorando una orden de apagado.

¿Por qué no mantener un nodo de HA encendido el mayor tiempo posible?

A veces esa es la estrategia adecuada. Un administrador describió un plan de contingencia diferente: cuando la autonomía del UPS cae cerca de la mitad, apagar dos de los tres nodos de HA y migrar cada máquina al nodo restante. Mantener esa máquina encendida hasta que solo queden unos pocos minutos de batería y apagarla entonces.

Es un diseño perfectamente lógico cuando la carga de trabajo cabe en un solo nodo y el almacenamiento sigue funcionando tras la desconexión de los demás. No es una práctica segura de forma automática para un clúster hiperconvergente con Ceph, ya que la alta disponibilidad de computación y el almacenamiento distribuido tienen dependencias distintas. Si el último nodo depende de OSDs de Ceph que se apagaron con los dos primeros hosts, conservarlo encendido no aporta nada: las VMs seguirán corriendo para la CPU, pero habrán perdido su almacenamiento.

Con almacenamiento externo NFS, iSCSI, replicación local con ZFS o cualquier otro esquema sin Ceph, la consolidación tiene mucho más sentido. Apagar el clúster entero como una unidad debe ser una política elegida en función de tu instalación, y que PVE-UPS permita configurarlo es una decisión acertada.

¿Qué ha cambiado para Proxmox Backup Server?

PVE-UPS puede ahora tratar a Proxmox Backup Server como un objetivo de apagado independiente con entidad propia, en vez de asumir que PBS es otro nodo de PVE.

Las APIs son parecidas, pero los modelos de permisos difieren. PVE utiliza Sys.PowerMgmt para los permisos de apagado del host. PBS emplea Sys.PowerManagement, y sus rutas de API y métodos de autorización mediante token son distintos. Por esa razón, introducir un sistema PBS como si fuera un host PVE podía fallar mostrando un error que parecía un token de API no válido. Ahora cada entrada de host cuenta con un tipo propio, lo que permite definir con precisión entornos mixtos con PVE y PBS.

Aquí existe también un compromiso de seguridad. La documentación actual de PVE-UPS señala que PBS no ofrece un permiso restringido exclusivo para apagar, a diferencia de PVE. La configuración documentada para PBS concede un rol Admin delimitado a /system/status, y el proyecto advierte a los usuarios en producción que evalúen con cuidado si desean otorgar a un mismo servicio acceso tanto a los hosts de virtualización como al servidor de backup.

Es un buen consejo, ya que un servidor de backup se instala precisamente para disponer de una vía de recuperación independiente. Si el mismo servicio y la misma red de gestión pueden controlar tanto los hosts de producción como las copias de seguridad, cualquier brecha o error tendrá un alcance mayor. En un diseño corporativo, una ruta de apagado independiente o un segmento de red separado para PBS puede ser la opción más prudente.

¿Por qué la separación de privilegios del token confundió a los usuarios?

Una conexión API operativa no demuestra que el token cuente con autorización para apagar el host.

Un usuario temprano configuró el rol dedicado para la gestión de energía de forma correcta y aun así recibió una advertencia indicando que no se podía confirmar Sys.PowerMgmt. El motivo fue la separación de privilegios de los tokens de API en Proxmox. Con la separación de privilegios activa, un token requiere sus propias entradas en las ACL y no hereda directamente todo lo concedido al usuario principal. La configuración de PVE-UPS asigna el rol de energía al usuario dedicado y crea el token de apagado con la separación de privilegios desactivada, de modo que el token hereda los permisos del usuario.

El comando correspondiente utiliza --privsep 0, y el desarrollador confirmó más tarde que esto es intencionado en la configuración documentada. Conviene encontrarse con este tipo de fricciones durante la puesta en marcha de la herramienta, mucho antes de que el UPS dependa de la batería, y las autocomprobaciones reforzadas de la nueva versión están pensadas precisamente para detectarlas a tiempo.

¿Qué detecta realmente la nueva autocomprobación?

Revisa los detalles que de otro modo solo saldrían a la luz durante un apagón real, y el nombre del nodo de Proxmox es un buen ejemplo. Una configuración podría tener mayúsculas incorrectas o un sufijo de dominio adicional; una prueba básica de conexión podría superarse con éxito hasta que la llamada de apagado apuntara a un nombre de nodo que la API no reconociera. La nueva autocomprobación valida el nombre configurado frente a la API.

También verifica el estado del clúster una vez por clúster, se ejecuta automáticamente cuando el servicio vuelve a armarse y cuenta con una opción manual de "Ejecutar autocomprobación ahora".

Frente a la secuenciación del apagado del clúster pueden parecer funciones menores, pero en la práctica cobran gran valor. Los administradores confían en que la automatización del UPS casi nunca tenga que actuar en situaciones reales, de modo que los errores de configuración pueden permanecer inadvertidos durante meses o años. Cuanto mayor sea el tiempo entre cortes reales, más dependerás de las autocomprobaciones.

Un usuario relató posteriormente que la herramienta apagó sus servidores con éxito durante el primer apagón que sufrían en años. Es un único testimonio, pero refleja muy bien la situación: un flujo de emergencia puede permanecer sin uso durante muchísimo tiempo y convertirse de pronto en lo único que importa.

¿Por qué importan los webhooks múltiples durante un apagón?

"El apagado ha comenzado" es solo uno de los eventos sobre los que podrías querer recibir avisos. PVE-UPS admite ahora múltiples destinos para webhooks en vez de un único endpoint. Cada uno dispone de su propio formato, filtro de gravedad, función de prueba y encabezado de autorización opcional. Los formatos integrados abarcan Slack, Discord, ntfy, Microsoft Teams, JSON plano y texto plano, con una plantilla personalizada para cualquier otro servicio.

Un webhook fallido se refleja además en el registro de eventos, en la tarjeta del destino y en el panel general. Así es como debe operar la automatización de infraestructuras, ya que un sistema de avisos que deja de enviar notificaciones sin alertar resulta casi peor que no tener ninguno, porque sigues confiando en él.

Durante un corte de luz es habitual querer enviar alertas de distinta gravedad a destinos diferentes. "UPS con batería" puede remitirse a un canal de chat, mientras que "el apagado del clúster ha comenzado" o "el apagado del host ha fallado" pueden requerir una vía más urgente. Las opciones de notificación del proyecto ofrecen ahora la granularidad necesaria para ello.

¿Debe ejecutarse PVE-UPS dentro del clúster que apaga?

Puede hacerlo, pero el lugar donde lo ubiques importa. El proyecto se ejecuta habitualmente como un contenedor LXC sin privilegios en uno de los nodos protegidos de Proxmox, y su orden de apagado reserva el propio host de la aplicación para el final.

En un clúster Ceph existe una restricción añadida: el sistema invitado de PVE-UPS no debe depender del almacenamiento Ceph que va a apagar. La documentación actual del proyecto indica que el instalador rechaza un sistema de archivos raíz alojado en Ceph a menos que el administrador omita esa comprobación de forma manual. Tiene sentido: si el disco de la aplicación reside en Ceph y Ceph cae por debajo de min_size a mitad del apagado, la aplicación encargada de coordinar la parada puede congelarse antes de terminar. En un entorno hiperconvergente con Ceph, ubica el contenedor de PVE-UPS en almacenamiento local.

¿Qué debes comprobar antes de confiar en una automatización de UPS?

No esperes a que ocurra un corte de luz real. Empieza en modo de simulación y valida cada ruta de integración:

• Confirma que las lecturas del UPS sean correctas.
• Confirma que el porcentaje de batería y los umbrales de tiempo restante sean realistas bajo carga de trabajo real.
• Prueba cada token de API en PVE.
• Prueba la ruta de PBS de forma independiente si lo utilizas.
• Prueba cada webhook configurado.
• Ejecuta la autocomprobación.
• Confirma que los nombres de nodo configurados coincidan con la API.
• Si utilizas HA, comprueba que el clúster alcance el estado desarmado previsto.
• Si utilizas Ceph, prueba la parada de sistemas invitados y los preparativos de mantenimiento en un laboratorio o ventana de servicio.

Lleva a cabo después un simulacro controlado de corte de corriente. Desenchufa el UPS de la toma de corriente manteniendo los servidores conectados y observa la secuencia completa. Ver salir la primera orden de apagado dice muy poco; comprueba que los sistemas invitados se detengan, que Ceph mantenga la capacidad de respuesta hasta que los clientes se desconecten, que HA no reinicie cargas, que los hosts se apaguen en el orden esperado y que el UPS conserve suficiente autonomía para el escenario más lento.

Un Health Check de Proxmox puede revelar muchas debilidades en el clúster antes de ese simulacro, pero aun así debes probar la ruta de apagado en sí misma.

Leer el estado de la batería es la parte sencilla de automatizar un UPS

En comparación con la coordinación del apagado de un clúster, supervisar un UPS es la tarea sencilla. SNMP puede informar sobre la autonomía y NUT expone el estado de la batería. La dificultad radica en decidir qué hacer a continuación cuando la infraestructura cuenta con HA, almacenamiento distribuido, servidores de backup y múltiples hosts con dependencias diferentes entre sí.

PVE-UPS gana interés porque sus versiones recientes empiezan a gestionar esa orquestación. La compatibilidad con PBS soluciona un desfase de API real, los múltiples webhooks facilitan la detección de fallos y las autocomprobaciones reforzadas identifican errores de configuración con antelación. La función beta orientada a clústeres es la pieza más ambiciosa.

Un clúster de Proxmox es mucho más que tres servidores independientes que comparten una interfaz gráfica. Ante un fallo de suministro eléctrico, el estado de HA, el estado de los sistemas invitados, la salud de Ceph, la disponibilidad del almacenamiento y el orden de parada se influyen mutuamente. Si la secuencia falla, el clúster puede terminar luchando contra su propio apagado. Si es acertada, el UPS cumple exactamente la función para la que lo compraste: otorgar a toda la infraestructura el tiempo necesario para detenerse limpiamente.