ADR-0003: Sesión 2026-05-16 — saneamiento mayor + crisis NVMe

Campo	Valor
Status	Implemented (2026-05-16/17)
Date	2026-05-16
Decision by	ramon
Reviewers	claude (Opus 4.7 1M)
Supersedes	—
Builds on	ADR-0001 (routing consolidation), ADR-0002 (cleanup+retention)

Contexto

Sesión maratón (~7h) que arrancó con un audit en 4 ejes (infra Proxmox / observabilidad / routing / almacenamiento) y derivó en:

1. Crisis NVMe NAS: ambos Ediloca EN600Pro 256GB del cache LVM murieron en cascada en <1h por firmware defectuoso (kernel reportaba clearing duplicate IDs for nsid 1). Cache LVM auto-detached tras reboot.
2. Drama reboot pmx-50: tras apt full-upgrade (kernel salto 6.17.13→7.0.2-4-pve), reboot atascado >10min, requirió power cycle físico.
3. 23 tareas ejecutadas del audit + improvisadas.

Documento decisiones arquitectónicas tomadas para evitar perder contexto en futuras sesiones.

Decisiones

D1. Reemplazo NVMe: 1× Crucial P310 500GB en writethrough (NO RAID1 writeback)

Decisión: cuando llegue el reemplazo (lunes 2026-05-18), montar single NVMe en modo writethrough, no recrear el RAID1+writeback que falló.

Justificación basada en datos del cache anterior (dmsetup status capturado pre-fallo): - 99.6% read hit rate sostenido durante 15 días - 11.2% write hit rate (workload es 99% reads) - 11 dirty blocks pendientes al momento del fallo (writeback aportaba poco) - 41.6 TB servidos desde NVMe vs 158 GB de misses → working set ≤ 80 GB, cabe sobrado en 500 GB

Trade-offs: - ✅ Mitad de coste (1× P310 ~110€ vs 2× 220€) - ✅ Sin md1 RAID1 layer = menos puntos de fallo - ✅ Writethrough: datos siempre en HDD, fallo SSD = solo pierdes performance, no datos - ❌ Performance escritura no acelerada (irrelevante: workload es read-heavy) - ❌ Sin redundancia cache: si SSD muere, NAS vuelve a HDD speed hasta reemplazo

Alternativas descartadas: - 2× P310 en RAID1 writeback: coste doble, beneficio marginal para workload medido - Sin cache: HDD-only sería 100-130× más lento en random reads (datos del benchmark interno)

D2. NO consolidar cloudflared con otros LXCs

Decisión: mantener cloudflared aislado en LXC 123 (pmx-51), no fusionar con tv-gw o wireguard.

Justificación: el audit identificó "edge LXC consolidation" como ahorro ~600MB RAM. Pero: - Cloudflared = único punto de entrada público. Cualquier fallo = sin acceso a todos los servicios - Mixing con tv-gw (L3 transparent gateway con routing tables complejas) o wireguard (kernel module) = single point of failure crítico - 600 MB de RAM en cluster con 32 GB+ libre es coste irrelevante

Alternativa descartada: LXC "edge" único — beneficio no justifica el riesgo.

D3. Kernel 7.0.2-4-pve en ambos nodos (alineado)

Decisión: aceptar el salto mayor 6.17.13 → 7.0.2-4 en ambos nodos, no pinear al 6.17 antiguo.

Justificación: - proxmox-default-kernel paquete 2.0.2 → 2.1.0 promociona 7.0 como default - Diferir = quedarse con kernel pronto deprecated, alineación rota - Riesgo regression: bajo (Proxmox 7.0 lleva semanas en testing; ningún reporte upstream relevante para nuestro hardware Ryzen 7735HS / Celeron N5095)

Gotcha aprendido: reboot pmx-50 con VM 208 (12 GB RAM, 54 containers) puede tardar >10 min o atascarse. Política: reboots futuros de pmx-50 con qm stop 208 graceful primero, monitor a mano, considerar IP-KVM.

D4. Tunnel CF 100% via Caddy (eliminar bypass-direct)

Decisión: migrar los 7 bypass-tunnel HTTP a Caddy. Solo excepción permitida: SSH (backup.monxas.casa → ssh://).

Justificación: - Logs centralizados en Caddy access log - Certs unificados (wildcard *.monxas.casa) - Política Sablier lazy aplicable a cualquier host - Posibilidad de CF Access transparente sobre todo

Trade-off aceptado: hop extra Caddy añade ~10ms latencia, irrelevante para tráfico web. WebSocket (HA) maneja Caddy transparente, validado.

D5. Monitoring preventivo BTRFS/mdadm/PCIe

Decisión: extender smart-collect.sh del NAS con métricas que habrían detectado el defecto Ediloca desde el día 1.

Métricas añadidas: - btrfs_corruption_errs, btrfs_read_io_errs, btrfs_write_io_errs - mdadm_array_active, mdadm_array_degraded, mdadm_array_devices_active/total - pcie_link_width_current vs pcie_link_width_max — el chivato real (Ediloca negociaba x1 cuando debía x4)

Reglas Grafana asociadas (folder homelab): - BTRFS corruption en NAS (critical, for 1m) - RAID NAS DEGRADED (critical, for 1m) - PCIe NVMe link downgraded NAS (warning, for 5m)

Lección general: SMART self-report es necesario pero insuficiente para detectar fallos de controller/PCIe. Monitorear el bus y el RAID layer es donde está la señal real.

D6. CF Access en 6 servicios (n8n con bypass /webhook)

Decisión: proteger sonarr/radarr/prowlarr/bazarr/jellyseerr/n8n con CF Access policy default (allow [email protected] + monxas.com domain).

Patrón n8n: 2 apps Access en mismo host: - n8n.monxas.casa/webhook con decision: bypass (everyone) — webhooks externos pasan sin auth - n8n.monxas.casa con decision: allow (default policy) — UI requiere login

Path-specific matching de CF Access permite proteger root sin romper webhooks. /webhook-test/* pasa con cookie session una vez logueado (no requiere bypass explícito).

D7. Consolidación kiwix → LXC 251 (rag)

Decisión: mover kiwix-serve docker + zim-http systemd de LXC 250 a LXC 251 (rag), retain LXC 250 stopped 7-14d como blue-green safety.

Justificación: kiwix usa poca RAM (~200MB), rag tiene 4c/6GB. Comparten mismo NFS mount /mnt/nas/offline-kit. Consolidación libera 1 LXC overhead, simplifica inventory.

Implementación

23 tareas ejecutadas. Ver MEMORY.md del workspace claude para tracking. Commit dfbf677 con cambios en ~/stacks/ (cors-anywhere stack nuevo, esp-relay, Loki bind, Caddyfile, managed.caddy, etc.).

Consecuencias

• Performance: NAS sin cache hasta lunes (volverá a HDD speed para 0.4% de reads). PBS pasó de 90%→54% espacio libre (quota subida 300G→500G).
• Seguridad: 6 servicios nuevos detrás de CF Access, attack surface reducida.
• Visibilidad: cluster pmx-51 vuelve a Loki tras días ciego, smart-collect extendido detectará próximo fallo HW antes.
• Mantenibilidad: 1 LXC menos (250), 1 cloudflared más simple (no consolidado).
• Riesgo residual: NVMe sin redundancia mientras llega P310. Snapshots BTRFS daily compensan.

Pendientes inmediatos

• Instalar Crucial P310 500GB cuando llegue (lunes 18-may)
• Decidir destino LXC 250 (destroy en 7-14d si todo OK)
• ETMF stack (working tree pendiente, no en commit)
• Considerar smart plugs Shelly + IP-KVM para drama futuro

Lecciones grabadas en memoria

• nas_nvme_failure_20260516.md (nuevo)
• cf_access_homelab.md (nuevo)
• proxmox_issues.md #26 (reboot stuck) y #27 (NVMe cascade)
• observability_stack.md (Loki bind, 5 reglas preventivas)
• terramaster_f4423_packet_loss.md (NVMe MUERTA, monitoring extendido)