Corrección de normalidad y presupuesto N-1 — 2026-10-19

Autorización: aplicar las mejoras de la revisión con agentes simultáneos. Ámbito de este cambio: comprobador de RAM/HA, sin modificar RAM asignada, políticas HA, cargas, ARC ni reiniciar huéspedes o hosts.

Cambio aplicado

Fuente: ansible/roles/proxmox_node/files/normalidad; desplegada como /usr/local/bin/normalidad en pmx-50 y pmx-51.

• El OK usa exclusivamente MemAvailable destino − RAM+swap actual de HA migrables − 2048 MiB de reserva. No suma balloon al disponible.
• Publica aparte un margen condicionado. Lee balloon efectivo y mínimo de Proxmox, no memory configurado − mínimo; cualquier memoria ya cedida no se vuelve a sumar. Solo considera información balloon de hasta 120 segundos.
• Lee MemAvailable, swap y PSI full del invitado mediante QEMU Guest Agent. El techo adicional es min(balloon efectivo−mínimo, MemAvailable−512 MiB); con PSI full avg10 o avg300 >=1 %, datos ausentes/obsoletos o bajo disponible devuelve cero. Los 512 MiB son una guarda del indicador, no garantía de que el invitado tolere esa reducción. No se ejecuta ninguna reducción.
• Muestra ambos sentidos incluso con cero HA migrables; enumera recursos estrictos y huéspedes activos fuera de HA. Las parejas C0 se comprueban aparte. Ni las exclusiones ni un margen positivo acreditan HA completa.
• Publica límites RAM de los migrables y advierte que consumo actual no garantiza picos ni arranque simultáneo. La falta de medidas impide un OK.
• Respeta failback=0 (HAOS171): residir en el otro nodo estando started no se trata como retorno automático pendiente.
• Elimina touch /mnt/nfs_media/.normalidad. Comprueba acceso a metadatos y tipo/opciones de montaje mediante stat/findmnt, describiendo exactamente esa cobertura y sin afirmar una escritura probada.
• El código es importable sin ejecutar consultas; permite probar el presupuesto de manera aislada.

Evidencia tras despliegue

Primera ejecución desde pmx-50, durante el trabajo paralelo del 19-oct:

Concepto	MiB
Disponible pmx-50	13.498
Consumo RAM+swap de 10 HA migrables	11.912
Reserva	2.048
Margen sin balloon	−462
Techo adicional condicionado de VM208	2.026
Margen condicionado	+1.564
Límites RAM migrables	19.328

VM208: balloon efectivo 8192 MiB, mínimo 6144 MiB; disponible del invitado 2538 MiB; swap usada 2702 MiB; PSI full avg10/avg300 0,01/0,06 %. El comando sale 1 con AVISO, sin el falso OK previo. No se transforma el techo condicionado en capacidad ya disponible.

En ese momento los 14 HA estaban started, las 14 réplicas al día, 28 invitados cubiertos por job y todos con copia PBS de menos de 26 h. Quórum tres votos; watchdogs de hardware y kdump50 ready. Estos datos describen una muestra, no acreditan recuperación de todos los datos externos ni estabilidad prolongada.

Exclusiones por pérdida de pmx-51: estrictos 110/172/217/218; sin HA 200/204/271/301/302/303. Por pérdida de pmx-50, fuera de HA: 186/208/219/251/270/280/281/305. Los pares Caddy/DNS tienen su comprobación separada y pueden prestar cobertura de aplicación aunque no migre su huésped.

Validación y rollback

• Cinco pruebas pasan en ansible/roles/proxmox_node/tests/test_normalidad.py: caso histórico de falso OK, balloon parcialmente cedido, reserva del invitado, datos ausentes/obsoletos/PSI elevado y separación de ambos márgenes.
• Compilación Python correcta; despliegue temporal y renombrado atómico.
• Copia previa en ambos nodos: /usr/local/bin/normalidad.pre-nminus1-20261019.
• SHA256 anterior: <REDACTED>.
• SHA256 desplegado: <REDACTED>.
• Para volver: restaurar la copia previa sobre /usr/local/bin/normalidad; no requiere reinicio ni servicio. Eso recuperaría también las limitaciones del cálculo previo y su prueba de escritura NFS.

No se ha reducido VM208: quitar incluso 512 MiB dejaría un margen estimado muy pequeño en esta muestra. Se necesita un margen sostenido mediante capacidad física sana o una decisión explícita sobre qué cargas retirar durante una emergencia. Bajar límites sin liberar RAM real no arregla el presupuesto. La estabilidad de pmx-50 debe diagnosticarse antes de basar en él una ampliación o una nueva carga; este cambio mejora la veracidad del indicador.

Segunda ejecución desde pmx-51: salida 1, margen sin balloon −404 MiB, condicionado +1644 MiB. Ambos nodos ejecutan el mismo hash. Las diferencias entre muestras son normales y refuerzan que no debe dimensionarse al límite.

Procedimiento concreto para emergencia de capacidad en pmx-50

Se conserva el modo degradado C2 descrito en ADR-0026, sin crear un daemon, cron ni ampliar exclusiones HA. No se ha ejecutado este procedimiento ni parado ninguna carga. Los candidatos operativos se limitan a RAG251 y Homelable305 tras revisar trabajo activo. CT281 queda excluido: no está aclarado si contiene sitios de clientes o de Carmelo, que está fuera del alcance autorizado.

Muestra en vivo de candidatos fuera de HA:

CT	Función perdida al apagarlo	RAM cgroup	Swap	Anon residente
251	RAG de Vera, Kiwix y servidor ZIM	~1455 MiB	~187 MiB	~757 MiB
305	Homelable y su servidor MCP	~286 MiB	0	~173 MiB

memory.current incluye caché de archivos, que puede estar contabilizada ya en MemAvailable. Tampoco la swap libera RAM equivalente al apagar. Por eso no se suman RAM+swap como ganancia: anon residente aproxima la parte privada que se dejaría de usar, sin garantizar el delta de MemAvailable. Medirlo después es obligatorio. RAG y Homelable sumaban ~930 MiB de anon en la muestra; esa cifra no acredita un margen amplio sobre los picos actuales. A modo de inventario, CT281 usaba ~1674 MiB RAM (~1245 MiB anon), pero no forma parte del procedimiento: preservar sus cuatro sitios y bases de datos hasta aclarar propiedad y autorización.

Todos tienen onboot=1; un reinicio de pmx-50 los arrancaría de nuevo. Se observaron timers de indexación RAG, backup/riesgo/spam WP y tareas del sistema. No se encontró un controlador existente que desactive estas cargas por falta de RAM; node-autowake arranca nodos, no resuelve esta reserva. No se amplió su función ni se alteraron timers. Una sesión en maint o SSH puede ejecutar el procedimiento usando los comandos Proxmox existentes.

1. En el nodo superviviente, comprobar pvecm status, ha-manager status, pct status <id> y tareas activas del nodo/CT en Proxmox. Confirmar que no está corriendo backup/restauración o una operación de mantenimiento. Si se opta por CT251, inspeccionar antes pct exec 251 -- systemctl is-active homelab-rag-indexer.service homelab-rag-fast.service; no cortar una tarea a ciegas. No detener PBS186, VM208, Caddy270 ni cloudflared219 como atajo.
2. Elegir CT251 o CT305 si su pérdida es aceptable; comprobar también las sesiones MCP/trabajo activo antes de suspender Homelable. Usar apagado ordenado, por ejemplo pct shutdown 251 --timeout 60 en pmx-50. Si falla, investigar; no añadir --forceStop ni usar pct stop automáticamente. No apagar CT281: su posible relación con clientes/Carmelo impide incluirlo en este procedimiento sin aclaración adicional.
3. Comprobar pct status <id>, free -m y normalidad. El resultado nuevo decide si se ha liberado suficiente RAM real. Con HA ya recuperado en50, revisar también la reserva libre del propio50: origen51 vacío no es una prueba de que50 tenga margen. No esperar que MemAvailable suba la suma íntegra de RAM+swap de la tabla.
4. Cuando51 esté sano y sus recursos hayan vuelto conforme a las políticas, revisar de nuevo memoria/PSI antes de pct start <id>. Arrancar de uno en uno y comprobar función de la aplicación y timers. HAOS171 tiene failback=0: puede permanecer deliberadamente en50; no forzar su migración como parte de restaurar estas cargas. Si50 reinicia durante el modo degradado, revisar inmediatamente el onboot y la reserva porque los CT volverán a arrancar.

Este procedimiento ofrece una respuesta manual reversible para una emergencia; no reserva memoria por anticipado ni convierte el clúster en tolerante a picos.

Observación posterior al reinicio de pmx-51

La comprobación central a las 22:02 devuelve NORMAL, con margen sin balloon +5035 MiB y solo 6140 MiB de HA migrables tras el arranque en frío. Las muestras anteriores con carga caliente sumaban ~11.900–12.900 MiB de RAM+swap. La liberación de swap/cachés al reiniciar cambia la foto: este OK acredita el consumo actual, no capacidad garantizada cuando las aplicaciones vuelvan a crecer ni picos de arranque. No se ha alterado el algoritmo para convertir esa mejora transitoria en una garantía; conservar el seguimiento y el procedimiento manual anterior.