Saltar a contenido

11 contencion

Principio

Todo contenedor LXC (contenedor ligero de Proxmox) en Proxmox VE tiene definidos límites duros de RAM y CPU en código OpenTofu.
Ningún servicio puede consumir recursos de forma descontrolada y derribar el servidor Ra (servidor principal de SmallCountry).

Ante una presión de recursos que se acerca a los límites físicos del host (RAM agotada, CPU saturada, temperatura alta), el sistema no colapsa de forma caótica, sino que ejecuta una cadena de degradación predefinida y versionada en el repositorio Forgejo.

El orquestador principal de esta cadena es n8n, que apaga servicios siguiendo el orden establecido en degradation_policy.yml. Para evitar que un fallo del propio n8n bloquee la degradación, un watchdog externo (script de bash + systemd timer) monitoriza la salud de n8n y aplica una degradación de emergencia si es necesario.

Los dispositivos físicos (Shelly (actuador eléctrico WiFi), ESP32 (microcontrolador WiFi para sensores)) y los servicios Tier A quedan siempre fuera de la cadena de degradación. La infraestructura crítica y la resiliencia física no se sacrifican nunca.

Cómo se implantan los límites de recursos

Cada LXC se crea con una asignación mínima y máxima de recursos en su definición de OpenTofu:

resource "proxmox_lxc" "nextcloud" {
  hostname = "nextcloud"
  cores    = 2
  memory   = 2048
  swap     = 512
  # ...
}
  • La RAM se define con un límite duro (memory) y un swap limitado (swap). El LXC (contenedor ligero de Proxmox) no puede sobrepasar ese tope aunque lo intente.
  • La CPU se limita con cores y opcionalmente con cpuunits para prioridades relativas.
  • Proxmox VE aplica estos límites mediante cgroups, impidiendo físicamente que un proceso dentro del LXC consuma más de lo asignado.

Los ajustes de recursos no se deciden a ojo, sino con datos reales de Victoria Metrics y Grafana:

  • Si el uso real supera el 80% del límite durante un período sostenido, el administrador evalúa ampliar los recursos.
  • Si el uso real nunca llega al 20% del límite, se revisa a la baja para liberar capacidad.
  • Cualquier modificación se aplica mediante un cambio en el código de OpenTofu, siguiendo el flujo del 1. Infraestructura y configuración como código.

La cadena de degradación (degradation_policy.yml)

El orden de apagado está declarado en un archivo YAML (formato de configuración legible) versionado en Forgejo y legible tanto por n8n como por el watchdog:

degradation_order:
  - tier: 5
    label: "Efímeros"
    services:
      - qbittorrent
      - sonarr
      - radarr
  - tier: 4
    label: "Degradables"
    services:
      - jellyfin
      - kavita
      - audiobookshelf
  - tier: 3
    label: "Productivos no esenciales"
    services:
      - searxng
      - pinry
      - freshrss
  - tier: 2
    label: "Importantes"
    services:
      - immich
      - nextcloud
      - n8n
  # Tier A y dispositivos físicos nunca se incluyen.
Regla Explicación
Orden de apagado Se apaga primero el Tier D completo, luego el Tier D, luego el Tier C y, solo en emergencia extrema, partes del Tier B.
Notificación por paso Cada paso de degradación genera una sola alerta en ntfy y Matrix, informando de qué servicios se han apagado y por qué.
Reversibilidad Cuando la presión de recursos desciende por debajo del umbral de seguridad, n8n puede volver a encender los servicios en orden inverso (opcional, configurable).
Nunca se degradan Los LXC de Tier A (NetBird, Authentik, Forgejo, Pi-hole), los servicios de tiempo real (Node-RED, Mosquitto) y los dispositivos físicos (Shelly, ESP32) quedan excluidos de la cadena.

Ejecución de la degradación

1. En condiciones normales: n8n

  • n8n recibe las métricas de presión del sistema desde Victoria Metrics (RAM usada, CPU load, temperatura).
  • Cuando una métrica supera un umbral de alerta definido en degradation_policy.yml, n8n ejecuta el flujo de apagado paso a paso.
  • Antes de apagar un grupo de servicios, verifica que el paso anterior ha liberado recursos suficientes. Si no, continúa con el siguiente grupo.
  • Cada apagado se registra en Victoria Metrics como un evento de degradación.

2. En degradación de emergencia: watchdog

  • Un script watchdog (bash puro + systemd timer) se ejecuta cada minuto.
  • Verifica si n8n responde en su healthcheck. Si n8n no responde o el host está tan saturado que n8n no puede funcionar, el watchdog lee directamente degradation_policy.yml y aplica la misma cadena de apagado mediante la API (interfaz de programación) de Proxmox VE o, en último caso, mediante comandos pct stop.
  • Esto garantiza que la degradación funciona incluso si el propio orquestador es la causa del problema.

Stack necesario

  • OpenTofu – Definición declarativa de límites de recursos por LXC.
  • Proxmox VE – Aplicación de límites mediante cgroups, API para apagar LXCs.
  • n8n – Orquestación de la degradación en condiciones normales.
  • Watchdog (bash + systemd timer) – Degradación de emergencia si n8n falla.
  • degradation_policy.yml – Archivo de configuración versionado en Forgejo.
  • Victoria Metrics + Grafana – Panel de presión de recursos y alertas de umbral.
  • ntfy + Matrix – Notificación de pasos de degradación.

Relaciones con otros principios

Diagrama de contención y degradación

graph TD
    subgraph Monitorizacion [Monitorización de presión]
        VicMet[Victoria Metrics]
        Grafana[Grafana]
    end

    subgraph Orquestador [Orquestador principal]
        n8n[n8n]
    end

    subgraph Watchdog [Watchdog de emergencia]
        WD[Script watchdog]
    end

    subgraph Degradacion [Cadena de degradación]
        T5[Tier D - Efímeros]
        T4[Tier D - Degradables]
        T3[Tier C - Productivos]
        T2[Tier B - Importantes]
        T5 --> T4 --> T3 --> T2
    end

    subgraph Protegidos [Nunca degradados]
        T1[Tier A - Críticos]
        Edge[Dispositivos físicos]
    end

    VicMet -->|Métricas de presión| n8n
    VicMet -->|Métricas de presión| WD
    n8n -->|Apagar servicios| Degradacion
    WD -->|Apagar servicios si n8n no responde| Degradacion
    n8n -->|Alerta| Alerta[ntfy / Matrix]
    WD -->|Alerta| Alerta

    Protegidos -.-|Excluidos de la cadena| Degradacion

    style Monitorizacion fill:#a5d6a7,stroke:#2e7d32,color:#000
    style Orquestador fill:#90caf9,stroke:#1565c0,color:#000
    style Watchdog fill:#ffcc80,stroke:#e65100,color:#000
    style Degradacion fill:#ffe082,stroke:#f57f17,color:#000
    style Protegidos fill:#c8e6c9,stroke:#2e7d32,color:#000

← Principio 10: Asistencia inteligente   |   Principio 12: Conocimiento compartido →

Secciones relacionadas