Saltar a contenido

Servidores del parque

Traducción automática del original francés.

Página de referencia. No explica nada: proporciona los valores exactos y señala aquellos que caducan.

Tabla de servidores

Servidor Naturaleza Rol
Mac Pro máquina física Servidor principal Obsidian, sincronización del cofre — ya no aloja ninguna VM desde el 05-09-2026
vm-compute-02 mini-PC, hipervisor Proxmox Aloja las cuatro VMs del parque
vm-claude VM (KVM) VM de desarrollo, cofre montado, sin Docker
vm-docker VM (KVM) ~100 contenedores: proxy inverso, SSO, Forge, bases de datos
vm-addons VM (KVM) ~30 contenedores: puerta de enlace MCP y pequeños servicios derivados del servidor GPU
vm-agents VM (KVM) Entorno de pruebas para los agentes de IA del equipo — ningún secreto del parque se almacena aquí
vm-compute-01 máquina física ~85 contenedores, GPU, inferencia local, domótica
NAS Synology NAS NFSv4, red WAN, fuente de verdad del cofre, ~35 contenedores
pi-bao Raspberry Pi, sin Docker Dedicado al cofre de secretos de máquinas (OpenBao), nada más
vps-fr-ovh VPS único servidor fuera de la red local, ~15 contenedores
paw-01 portátil con Linux Servidor de administración; inaccesible = en modo de espera hasta que se demuestre lo contrario

Contenedores registrados el 06-10-2026: se actualizan semanalmente, la fecha indica cuándo fueron creados.

Las direcciones no están aquí, y es intencional

Esta documentación es pública. El plan de direcciones, las cuentas y los puertos de acceso se almacenan en el cofre privado — no se publican ni son necesarios para comprender cómo está construido el parque. En todas las páginas, una máquina se identifica por su rol y el acceso se realiza a través de una marca del tipo <user>@<hôte> -p <port-ssh>.

Dos propiedades merecen ser mencionadas, ya que explican ciertos fallos:

  • Los puertos SSH no son los predeterminados. Un puerto ssh <hôte> sin -p no falla realmente: se desconecta, lo que parece que la máquina está apagada;
  • El plan de control de la red mesh ha cambiado (paso de un servicio alojado a una instancia auto-alojada). Todas las direcciones de la red mesh cambiaron ese día. Una dirección obtenida antes de esa fecha ya no es válida, y nadie lo dice — de ahí la regla: un inventario de direcciones debe tener su fecha de obtención, o no tiene valor.

Bases y particularidades docker

Host Base Invocation docker
vm-docker /opt/docker/<stack>/ docker directo
vm-compute-01 /opt/docker/<stack>/ docker directo
NAS Synology /volume3/docker/<stack>/ sudo -n /usr/local/bin/docker — ruta absoluta obligatoria
vm-addons /opt/docker/<stack>/ docker directo
vps-fr-ovh /opt/docker/<stack>/ docker directo, sin sudo

Consecuencia práctica: cualquier script que busque los archivos de base bajo /opt/docker/ en todos los hosts fallará al encontrar el NAS sin generar ningún error.

Ubicación física

A partir del 27-08-2026, el NAS y sus dos DX517 están en el sótano, en la habitación ventilada que ya alberga vm-compute-01. Dos efectos medidos el día del traslado:

  • Temperatura de los discos: HDD 40–44 → 34–40 °C, SSD 39 → 31–32 °C, NVMe 50/55 → 45 °C;
  • La velocidad de 1 Gbit/s entre las dos habitaciones ha desaparecido — rtx → nas medido en 2354/1583 Mbit/s, rtx → vm-docker en 2209/2348, frente a 940/940 cuatro días antes.

En estos caminos, ~940 Mbit/s ya no es normal, sino una anomalía.

Ambas máquinas virtuales abandonaron el Mac el 5 de septiembre de 2026: ahora están funcionando en el hipervisor Proxmox, también en una bodega, junto con vm-addons (creada el mismo día) y vm-agents (2 de octubre de 2026). El Mac solo tiene Obsidian y la sincronización. La dirección IP de las máquinas virtuales no ha cambiado; es estática en el invitado, por lo que viaja con el disco: una migración de host no invalida los webhooks de terceros ni los servidores upstream del proxy inverso. El nombre de la interfaz, en cambio, ha cambiado (deriva del camino PCI): todos los scripts que nombraban la interfaz se han vuelto falsos ese día, silenciosamente.

Un host que está inactivo no es un host que falla

El Mac entra en modo de suspensión cuando el sistema lo decide, en cualquier momento. Nada lo despierta para medirlo, y es el régimen deseado. Esto tiene tres consecuencias para cualquier sonda que lo intente:

  1. Un timeout es un estado indeterminado, no una falla. No se puede concluir sobre esta máquina hasta que esté activa;
  2. No hay protección por horario. Una ventana "de la noche" permite que una falsa alerta pase a cada siesta diurna y oculta una verdadera falla nocturna. La protección se basa en la causa (el host es inaccesible) o en una duración larga, nunca en la hora;
  3. No se debe despertar al objetivo para medirlo. Una sonda que despierta a su objetivo está midiendo su propia intrusión.

Antes de atribuir una falla nocturna a una suspensión, hay que verificarla:

# L'hôte a-t-il dormi ?
ssh -p <port-ssh> <user>@mac "pmset -g log | grep 'Entering Sleep' | tail -3"

# L'invité a-t-il sauté dans le temps ?
sudo journalctl -k --since '2026-08-24 00:00' | grep time-jumped

Dos sesiones atribuyeron erróneamente una falla del sistema de archivos a esta noche: el Mac no estaba en modo de suspensión, el invitado no tenía ningún time-jumped, y el diagnóstico duró nueve horas. Un timeout nocturno se diagnostica, no se explica de antemano.

Dernière vérification de cette page : 2026-10-06