Problema

En un homelab típico se acumulan servicios de contenedores, máquinas virtuales, bases de datos y una gran cantidad de archivos multimedia. La pregunta recurrente es si mantener el compute (CPU, GPU, memoria) en un nodo independiente y el storage en un NAS dedicado, o consolidar ambos en una única caja que combine capacidad de disco y potencia de procesamiento (All‑In‑One). La decisión afecta:

  • Rendimiento de red: la transferencia de archivos entre contenedores y discos puede saturar un enlace de 1 GbE.
  • Escalabilidad: agregar más CPU o más discos implica diferentes rutas de expansión.
  • Fiabilidad: los discos externos conectados por USB pueden presentar cuellos de botella y fallos intermitentes.
  • Flexibilidad futura: la aparición de workloads de IA local o de transcodificación exige más GPU/CPU y ancho de banda.

El reto es crear una arquitectura que soporte la carga actual (Docker, Plex, Nextcloud, etc.) y que permita crecer sin re‑arquitecturas costosas.

Causa

  1. Limitaciones de la NIC integrada
    Mini PCs como el Beelink S12 suelen ofrecer solo 1 GbE. Cuando el almacenamiento está en un HDD USB, la única ruta de datos pasa por esa NIC, creando un cuello de botella evidente en transcodificaciones y backups.

  2. Dependencia de USB 2.5 GbE adapters
    Los adaptadores USB‑to‑2.5 GbE son útiles, pero comparten el controlador USB con los discos externos. En entornos con alta I/O el controlador puede colapsar, provocando desconexiones o latencias altas.

  3. Crecimiento de la capa de medios
    Un HDD externo de 8 TB es suficiente para iniciar, pero a medida que el archivo de medios supera los 20 TB, la gestión de snapshots, replicación y acceso concurrente se vuelve problemática.

  4. Workloads emergentes (IA local, transcodificación)
    Modelos de OCR o LLM requieren CPU con AVX‑512 o una GPU ligera. Un nodo de cómputo sin capacidad de expansión no podrá atender esas demandas sin reemplazo total.

  5. Topología de red 2.5 GbE vs 10 GbE
    Cuando los switches de acceso son 2.5 GbE y los uplinks 10 GbE, un NAS con 10 GbE no aporta beneficio si el nodo de cómputo sigue limitado a 1 GbE. La arquitectura de red debe alinearse con la velocidad del nodo que accede al almacenamiento.

Solución

1. Definir requisitos cuantitativos

Métrica Valor actual Proyección 12‑meses
Tráfico medio de medios (GB/día) 30 80
Concurrencia de contenedores 12 20
Necesidad de transcodificación 2‑4 streams 6‑8 streams
Workloads de IA local Ninguno 1‑2 modelos ligeros
Ancho de banda disponible 1 GbE (NIC) 2.5 GbE (switch)

Si la proyección supera la capacidad de la NIC del nodo de cómputo, la separación de storage es la opción segura.

2. Arquitectura separada (Compute + NAS)

  1. NAS dedicado (ej. UniFi UNAS 4 o similar) con:

    • 4‑6 bahías HDD, RAID‑Z2 o RAID‑10.
    • 2 × 10 GbE SFP+ y 2 × 2.5 GbE RJ45.
    • Servicios SMB/NFS/iSCSI sin capa de aplicación (no un “app‑store”).

  2. Nodo de cómputo (mini PC o servidor):

    • CPU con al menos 4 núcleos y soporte AVX.
    • NIC 2.5 GbE o 10 GbE (PCIe) para conectar directamente al NAS.
    • Proxmox como hipervisor; crear VM/CT para Docker y Plex.
    • Montar los volúmenes del NAS vía NFS (para archivos) e iSCSI (para bases de datos de alto I/O).

  3. Red:

    • VLAN de “storage” aislada, con QoS que priorice tráfico iSCSI/NFS.
    • Enlaces de uplink 10 GbE entre switches y NAS; enlaces de acceso 2.5 GbE a los nodos.

3. Arquitectura All‑In‑One (UGREEN DXP4800 Pro o similar)

  1. Hardware integrado:

    • CPU i3‑1315U (4 núcleos + iGPU) suficiente para 2‑4 streams de transcodificación.
    • 2 × NVMe (OS + cache) y 4 bahías HDD.
    • 10 GbE + 2.5 GbE nativos.

  2. Software:

    • Instalar Proxmox directamente en el chasis.
    • Crear una VM “Docker host” (Ubuntu) y montar los discos NVMe como zfs o btrfs para appdata.
    • Exportar los HDD como NFS/iSCSI para contenedores que necesiten acceso a medios.

  3. Ventajas:

    • Menor consumo de espacio y energía.
    • Reducción de cables y puntos de falla.
    • Suficiente para workloads ligeros y transcodificación básica.

  4. Limitaciones:

    • Escalabilidad de CPU/GPU está atada al chasis; reemplazarlo implica migrar todo el storage.
    • Si la red de acceso sigue en 1 GbE, el beneficio de 10 GbE se pierde a menos que se actualicen los switches o se añada un uplink dedicado.

4. Implementación práctica (ejemplo NFS + Proxmox)

  1. Configurar export NFS en el NAS (asumiendo Debian‑based NAS):
bash
apt-get update && apt-get install nfs-kernel-server
mkdir -p /export/media
chown nobody:nogroup /export/media
echo "/export/media 10.0.0.0/24(rw,sync,no_subtree_check)" >> /etc/exports
exportfs -ra
systemctl restart nfs-kernel-server
  1. Montar en el nodo Proxmox (añadir como storage):
bash
pvesm add nfs media-nfs --server 10.0.0.10 --export /export/media --path /mnt/pve/media-nfs --options vers=4
  1. Crear VM para Docker y asignar el storage media-nfs como disco adicional o montar dentro del contenedor.

5. Estrategia de backup

  • Backup local: snapshots ZFS en el NAS, replicados a un segundo NAS o a un Storage Box externo.
  • Backup remoto: rsync o restic hacia Hetzner Storage Box, programado fuera de horas pico.

Cuándo aplicar esta solución

Situación Arquitectura recomendada
Necesidad de escalar CPU/GPU en el futuro Compute separado + NAS
Red de acceso limitada a 1 GbE Compute separado (NIC 10 GbE)
Presupuesto muy ajustado y espacio limitado All‑In‑One (UGREEN)
Requerimientos críticos de alta disponibilidad de storage NAS dedicado con RAID‑Z2
Workloads de IA local con GPU dedicada Compute separado (añadir GPU)
Solo 2‑3 servicios de media y backup All‑In‑One suficiente

Si la proyección de tráfico supera la capacidad de la NIC del nodo actual y se prevé añadir GPU o CPU potente, la separación es la ruta menos costosa a largo plazo. Cuando la carga es estable y el presupuesto es el factor limitante, un All‑In‑One bien dimensionado cubre la mayoría de casos.

Verificación

  1. Comprobar latencia NFS

    bash
time dd if=/dev/zero of=/mnt/pve/media-nfs/testfile bs=1M count=1024 oflag=direct

    Tiempo < 5 s indica buen ancho de banda (≈2 GB/s en 10 GbE).

  2. Validar transcodificación
    Iniciar Plex con un stream 1080p y observar uso de intel_gpu_top. Si el uso del iGPU está por encima del 30 % y no aparecen errores de “hardware acceleration”, la configuración es adecuada.

  3. Test de backup
    Ejecutar restic snapshots y comparar hashes entre NAS y Storage Box. Verificar que la ventana de backup no supera el 10 % del ancho de banda disponible.

Notas adicionales

  • Evita depender de adaptadores USB‑to‑2.5 GbE en producción; prefierelos solo para pruebas rápidas.
  • Cuando uses iSCSI para bases de datos, habilita discard=unmap y noatime para reducir desgaste de SSD.
  • En entornos con VLANs, marca el tráfico de storage con DSCP 46 (EF) para priorizarlo