7 vatios en reposo – construyendo un servidor/NAS de bajo consumo en Intel 12.ª/13.ª generación

Artículo original ↗ Discusión en Hacker News ↗

Buscar una construcción Intel de 12.ª/13.ª generación con 7 vatios en reposo como servidor doméstico o NAS pone de relieve cuánto depende el consumo total no solo de la CPU, sino del comportamiento del chipset, la red y, sobre todo, de los discos duros mecánicos. Los comentaristas sopesan el equilibrio entre un consumo en reposo ultrabajo y preocupaciones prácticas como la fiabilidad del RAID, el soporte de memoria ECC, las políticas de apagado de discos y el coste de las plataformas modernas de estación de trabajo o servidor. Se comparan alternativas como mini‑PCs Intel N100, equipos usados con Xeon/Supermicro, appliances Synology/QNAP y placas basadas en ARM en términos de eficiencia, expandibilidad, facilidad de gestión e integridad de datos a largo plazo.

Diseño de NAS de Bajo Consumo y Consumo en Reposo

  • A muchos les impresiona lograr un consumo en reposo de un solo dígito en vatios, especialmente frente a sistemas antiguos de 24 bahías o Xeon que permanecen en reposo a 100–150 W.
  • Otros señalan la ley de los rendimientos decrecientes: el coste y la complejidad del hardware pueden compensar poco frente a un sistema con un reposo algo más alto usado durante muchos años.
  • Varios participantes describen montajes alternativos de bajo consumo (p. ej., Atom, Xeon/E3 antiguos, Ryzen PRO, NUCs, escritorios Fujitsu) con reposos entre ~6–50 W según los discos y las tarjetas.

ZFS, RAID y Discos Mecánicos

  • Se informa de que ZFS tolera retrasos largos en el arranque de los discos, pero las unidades SMR pueden bloquearse durante minutos y causar problemas.
  • Se considera perjudicial para la vida útil de los HDD el encendido/apagado frecuente; muchos prefieren mantener los discos girando o usar temporizadores largos de inactividad.
  • El RAID con striping por bloques (ZFS/Btrfs) dificulta el apagado individual de discos; a menudo los arrays necesitan la mayoría de los discos para cualquier archivo.
  • Algunos usan con éxito ZFS con vdevs de datos en reposo, pero requiere un ajuste cuidadoso para evitar que las tareas en segundo plano despierten los discos.
  • Debate sobre el tamaño del array: algunos defienden un RAIDZ de 5–6 discos con doble paridad como un “punto óptimo”; otros prefieren SSD espejados más simples o un solo disco + rsync frecuente.

Memoria ECC y Compromisos de Plataforma

  • Hay una fuerte sensación de que un RAID/NAS de larga duración sin ECC es arriesgado; otros responden que mucha gente lo hace y “está bien”.
  • Los chipsets de estación de trabajo/servidor de Intel (C246, W680, placas Supermicro) y los Xeon antiguos son opciones ECC populares, aunque a menudo caras.
  • Los APUs AMD Ryzen PRO y algunas placas B550 pueden usar ECC con el AGESA/firmware adecuados, pero la verificación no es trivial.
  • La ECC integrada en el chip de DDR5 se distingue de la ECC “real” con informes de errores visibles para el SO.

Opciones de CPU: del N100 al Ryzen de Gama Alta

  • Muchos elogian los mini‑PCs Intel N100/N305 por su reposo de 2–8 W y rendimiento suficiente para NAS ligero, contenedores y Home Assistant.
  • Limitaciones: menos carriles PCIe, límites de RAM (a menudo 16–32 GB) y SATA limitado, lo que los hace menos adecuados para construcciones ZFS con muchos discos.
  • Otros muestran montajes Ryzen de gama alta (incluidos PRO/embedded) ajustados para un reposo sorprendentemente bajo dado el gran RAM, 10/40 GbE y muchos discos, señalando que la elección cuidadosa de componentes es crucial.

NAS DIY frente a NAS de Aparato

  • Los appliances Synology/QNAP son elogiados por su software pulido al estilo DSM, su funcionamiento de “configurar y olvidar” y su larga vida de soporte, incluidos algunos modelos compatibles con ECC.
  • Críticas: código cerrado, kernels relativamente antiguos, frescura limitada de Btrfs y ventanas de soporte finitas.
  • Varios sostienen que un NAS white-box con ZFS y ECC ofrece más control y potencialmente mejor fiabilidad a largo plazo, a costa del esfuerzo de administración y del “jank” de Linux/BSD.