Hay una prueba bastante cruel para saber si entiendes tu homelab: apaga un servidor y mira qué se rompe.
No hace falta hacerlo a lo bruto. De hecho, mejor no hacerlo a lo bruto si en casa hay DNS, domótica, fotos, contraseñas o cualquier cosa que use alguien que no comparte tu entusiasmo por los racks. Pero la pregunta sigue siendo buenísima. Si apago este nodo, ¿qué deja de funcionar? ¿Qué se degrada? ¿Qué da igual? ¿Qué servicio parece vivir en otro sitio pero en realidad depende de este por una base de datos, un montaje de red o una regla de proxy?
Durante mucho tiempo fui llevando eso en la cabeza. Mala idea. La cabeza sirve para montar cosas, no para recordar seis meses después por qué un contenedor de documentos dependía de una base de datos que estaba en otro servidor porque aquel día “era temporal”. Temporal, en homelab, muchas veces significa fósil con uptime.
Por eso me gusta tener un mapa de dependencias. No un diagrama precioso para enseñar. Un mapa operativo. Una lista que me diga qué pasa si apago cada máquina, qué servicios viven ahí, qué datos guarda, qué depende de ella y cómo volver a levantar lo importante si algo sale mal.
Ya hablé de inventario de homelab, pero el inventario responde a “qué tengo”. El mapa de dependencias responde a una pregunta más incómoda: “qué se cae si esto desaparece”.
La diferencia entre inventario y dependencia#
Un inventario típico dice algo como esto:
- Servidor A: Proxmox, varias VMs, contenedores internos.
- NAS: almacenamiento, backups, media.
- Mini PC: DNS, proxy, domótica.
- Raspberry Pi o similar: monitorización ligera.
Eso ayuda, pero no basta. Si el DNS corre en el mini PC y el proxy también, entonces muchos servicios que viven en otros servidores dependen de él. Si las fotos están en el NAS pero la aplicación está en una VM, apagar cualquiera de los dos rompe la experiencia. Si el servidor de backups está sano pero el almacenamiento donde escribe no monta bien, el backup es teatro.
El mapa de dependencias baja un nivel. Para cada servicio quiero saber:
- Dónde corre.
- Dónde guarda datos.
- Qué necesita para arrancar.
- Qué otros servicios dependen de él.
- Qué pasa si se apaga durante una hora.
- Qué pasa si se pierde durante un día.
No todos los servicios merecen el mismo cariño. Si cae un dashboard bonito, puedo vivir. Si cae DNS, la casa empieza a hacer cosas raras. Si cae el gestor de contraseñas, puedo tirar de caché local durante un rato, pero no quiero descubrirlo justo antes de necesitar una clave. Si cae la domótica, igual solo pierdo comodidad. O igual una automatización importante deja de funcionar y alguien me mira con esa cara de “tu laboratorio otra vez”.
Ese matiz importa.
Mi clasificación: crítico, importante, cómodo y juguete#
Para no volverme loco, clasifico cada servicio en cuatro niveles.
Crítico es lo que afecta a la casa o al acceso básico. DNS, DHCP si lo gestionas tú, firewall, acceso remoto, almacenamiento donde viven datos familiares, backups de cosas importantes, domótica si ya controla rutinas reales. Si cae, alguien lo nota rápido o tú pierdes capacidad de arreglar otras cosas.
Importante es lo que duele, pero tiene margen. Fotos, documentos, contraseñas, Git privado, automatizaciones útiles, monitorización, paneles de administración. Si cae un rato no se acaba el mundo, pero no quiero dejarlo pudriéndose.
Cómodo es lo que mejora la vida pero no debería bloquear nada. Dashboards, lectores RSS, herramientas auxiliares, gestores visuales, alguna app de recetas, algún servicio de laboratorio que uso a ratos.
Juguete es lo que puedo romper sin drama. Pruebas, stacks temporales, VMs para aprender, servicios que estoy evaluando. Aquí soy bastante más agresivo. Si algo lleva meses en juguete y nadie lo usa, quizá no es un servicio. Es una decoración con consumo eléctrico.
La gracia de esta clasificación es que te obliga a ser honesto. Muchos homelabs tienen demasiadas cosas tratadas como críticas. Eso agota. Si todo es crítico, nada está realmente protegido. Prefiero tener pocos servicios mimados y muchos servicios que acepto romper.
El mapa por servidor#
El formato que mejor me funciona es aburrido. Una nota por servidor o nodo, con bloques muy simples:
- Rol principal.
- Servicios que corren ahí.
- Datos que guarda localmente.
- Dependencias externas.
- Servicios que dependen de él.
- Cómo apagarlo con seguridad.
- Cómo levantarlo después.
- Qué comprobar tras encender.
No necesito más. De hecho, si necesito más, probablemente estoy mezclando documentación de arquitectura con runbook operativo. Para eso prefiero separar. El mapa me tiene que servir a las once de la noche, no quedar bonito en una reunión imaginaria conmigo mismo.
Un ejemplo genérico:
| |
No hay magia. Hay claridad. Y cuando algo falla, la claridad gana a cualquier dashboard.
Las dependencias invisibles son las peligrosas#
Las dependencias obvias no suelen pillarte. Si apagas el NAS, sabes que las carpetas compartidas desaparecen. Si apagas el firewall, sabes que la red va a sufrir. Lo que molesta de verdad son las dependencias invisibles.
Algunas típicas:
- Un servicio web que vive en un servidor pero guarda la base de datos en otro.
- Un contenedor que depende de un montaje NFS o SMB.
- Un proxy central que hace que todos los servicios parezcan locales.
- DNS interno sin alternativa razonable.
- Certificados renovados desde una sola máquina.
- Backups que dependen de que otro servidor tenga montado el destino.
- Automatizaciones que llaman a servicios por nombres internos.
- Apps móviles configuradas contra una URL que solo funciona si el túnel está vivo.
Estas son las que apunto con más cuidado. No porque sean malas. Un homelab normal tiene dependencias. El problema es fingir que no existen.
Una forma sencilla de encontrarlas es mirar cada servicio y preguntarse: “si esto arranca desde cero, qué necesita antes”. Muchas veces la respuesta no está en la app, está alrededor. Necesita DNS, base de datos, almacenamiento, proxy, certificado, red de contenedores, token, cola de trabajos o una carpeta con permisos muy concretos.
La aplicación es solo la parte que ves.
El orden de arranque importa más de lo que parece#
Cuando todo está encendido, las dependencias parecen estables. Cuando hay un corte eléctrico, una mudanza de servidor o una ventana de mantenimiento, el orden de arranque empieza a importar.
Yo intento tener claro un orden mínimo:
- Red base: router, switch, WiFi si aplica.
- DNS y acceso administrativo.
- Almacenamiento principal.
- Virtualización o hosts de contenedores.
- Bases de datos compartidas.
- Proxy, certificados y acceso remoto.
- Servicios familiares o críticos.
- Servicios cómodos y laboratorio.
No siempre se puede seguir al pie de la letra. En algunos montajes el DNS corre dentro del propio cluster, lo cual es cómodo hasta que el cluster necesita DNS para estar cómodo. Este tipo de circularidad es donde el mapa ayuda a no mentirse.
Mi preferencia actual es que lo básico tenga el menor número posible de dependencias. DNS interno, acceso remoto y notas operativas no deberían depender de cinco piezas elegantes. Si necesito levantar media plataforma para leer cómo se arregla la plataforma, he diseñado una broma.
Qué pasa si apago cada servidor#
Este es el ejercicio que más recomiendo. Coges cada máquina y escribes tres respuestas:
- Qué se cae inmediatamente.
- Qué sigue funcionando pero peor.
- Qué no debería verse afectado.
Por ejemplo, si apago el servidor de almacenamiento:
- Se caen carpetas compartidas, media, backups que escriben ahí y apps con datos en ese volumen.
- Siguen vivos algunos contenedores, pero pueden fallar al escribir.
- DNS, firewall y acceso remoto deberían seguir funcionando si están bien separados.
Si apago el nodo de red:
- Se cae DNS interno, proxy o VPN si viven ahí.
- Algunos servicios siguen por IP, pero la experiencia se rompe.
- Los datos del NAS deberían seguir intactos.
Si apago el nodo de laboratorio:
- Se caen pruebas, VMs temporales y stacks secundarios.
- No debería afectar a casa.
- Si afecta a casa, el laboratorio dejó de ser laboratorio y hay que corregirlo.
Esa última frase me ha salvado de varias tonterías. El laboratorio tiene que poder arder sin que la casa huela a humo.
Cómo lo pruebo sin buscarme una bronca#
No hace falta apagar servidores al azar. Se puede probar con cuidado.
Primero hago una revisión pasiva. Miro inventario, proxy, DNS, backups y almacenamiento. Apunto dependencias evidentes. Luego elijo un servicio no crítico y valido si el mapa coincide con la realidad. Después, cuando toca mantenimiento real, aprovecho para comprobar un servidor completo.
Antes de apagar nada crítico, reviso:
- Backup reciente.
- Acceso alternativo.
- Servicios familiares en uso.
- Ventana horaria decente.
- Plan de vuelta atrás.
Esto suena exagerado para casa, hasta que recuerdas que en casa también vive gente. No todo el mundo considera apasionante que internet, la tele, la música o las luces fallen porque tú querías “validar arquitectura”. Hay que elegir batallas.
También me gusta hacer pruebas pequeñas: cambiar temporalmente un cliente a DNS secundario, entrar por una ruta de acceso alternativa, restaurar una copia pequeña, levantar un servicio sin el proxy delante. Son gestos modestos, pero descubren mentiras.
Señales de que el mapa está mal#
Un mapa de dependencias envejece. No hay forma elegante de evitarlo. La forma práctica es detectar síntomas:
- Apagas algo “secundario” y cae algo importante.
- Un servicio crítico depende de una VM de laboratorio.
- Nadie sabe dónde vive una base de datos.
- Los backups de un servicio no incluyen su configuración real.
- El proxy tiene rutas que ya no recuerdas.
- DNS contiene nombres de máquinas que no existen.
- Hay servicios que solo funcionan porque nunca se han reiniciado.
Esta última da miedo porque es bastante común. Un contenedor lleva meses vivo, una dependencia cambió, una variable ya no existe, una imagen desapareció, pero como nadie ha reiniciado, todo parece estable. Hasta que reinicias.
Por eso el mapa no solo es para apagar. También es para entender si podrías reconstruir.
Mi regla para simplificar#
Cada vez que actualizo el mapa, busco una dependencia que pueda quitar. No siempre la encuentro, pero la pregunta merece la pena.
¿Este servicio necesita una base de datos externa o SQLite basta? ¿Este proxy interno aporta algo o puedo acceder por VPN? ¿Este contenedor debería vivir junto a sus datos? ¿Este servicio crítico está demasiado cerca del laboratorio? ¿Estoy usando alta disponibilidad para algo que nadie usa?
La arquitectura buena en casa suele ser menos sofisticada de lo que apetece. Menos piezas, menos magia, menos acoplamiento raro. Ya sé que Kubernetes, Ceph, VLANs y automatización fina molan. También sé que el sábado por la noche prefiero arreglar una cosa simple que descifrar mi propia obra de ingeniería.
Un mapa de dependencias te enseña dónde has sido listo y dónde te has venido arriba.
Dónde guardarlo#
No lo guardaría solo dentro del propio homelab. Si la documentación vive en un servicio que depende del homelab, el día malo empieza con una ironía bastante pobre.
Mi solución preferida es tener una copia en texto plano, versionada si puede ser, y otra copia accesible desde un portátil o una nube externa. Nada especialmente sofisticado. Markdown, notas, Git, un PDF exportado, lo que sea. Lo importante es que puedas leerlo cuando el servidor principal no arranca.
También conviene que no contenga secretos. El mapa debe decir “gestor de contraseñas” o “token en vault”, no pegar claves. Si alguien encuentra esa nota, no debería llevarse las llaves de casa.
La versión mínima que sí haría#
Si no tienes ganas de documentar todo, haría solo esto:
- Lista de servidores.
- Servicios críticos por servidor.
- Datos importantes por servidor.
- Qué depende de DNS.
- Qué depende del NAS o almacenamiento principal.
- Orden de arranque tras caída total.
- Qué se puede apagar sin avisar a nadie.
Con eso ya tienes más que muchos homelabs bastante serios. Y sobre todo tienes una base para tomar decisiones. Porque el mapa no va de documentar por documentar. Va de ver el sistema entero y quitar puntos tontos de fallo.
El homelab ideal no es el que nunca se rompe. Ese no existe. El bueno es el que entiendes cuando algo falla, el que puedes levantar por partes y el que no convierte cada apagado en una sesión de espiritismo técnico.
Si no sabes qué se cae al apagar un servidor, no tienes arquitectura. Tienes fe. Y la fe, para los discos duros y las redes domésticas, siempre me ha parecido un plan bastante flojo.