NAS ZFS de 71 TiB sin fallas de discos durante 10 años
(louwrentius.com)- Un NAS ZFS de 71 TiB armado con 24 discos HGST de 4 TB lleva más de 10 años en operación; se cambiaron la placa madre y la fuente de alimentación, pero hasta ahora no hubo fallas de discos
- En 10 años, el tiempo acumulado de funcionamiento de los discos fue de apenas unas 6000 horas; encenderlo de forma remota solo cuando se necesita redujo mucho el costo de electricidad
- En HN surgió la opinión de que la probabilidad de que 24 discos no fallen durante 10 años es más alta de lo que parece, por lo que es difícil afirmar que se deba a haberlos mantenido apagados con frecuencia
- ZFS volvió a importar el pool sin problemas incluso después de cambios de sistema operativo, y en los zpool scrub ejecutados algunas veces al año nunca se detectó un error de checksum
- El ruido, la red, el UPS, los respaldos y el plan de reemplazo se administraron como compromisos entre energía, costo y aceptación de riesgo; en el futuro, la misma capacidad podría lograrse también con 6 a 8 discos en RAIDZ2
Un NAS ZFS de 71 TiB que resistió más de 10 años
- Un NAS ZFS de 71 TiB en formato 4U, compuesto por 24 discos de 4 TB, sigue en uso después de más de 10 años
- El sistema actual usa su segunda placa madre y su segunda fuente de alimentación
- Hasta ahora no hubo ni una sola falla de disco
- El tiempo acumulado de funcionamiento de los discos HGST de 4 TB es de unas 6000 horas, equivalente a unos 250 días de operación en un período de 10 años
Operación de energía: encenderlo solo cuando hace falta
- El NAS normalmente está apagado y se enciende de forma remota solo cuando se necesita
- El flujo de encendido es el siguiente
- Un script enciende una regleta IoT
- Cuando termina de arrancar el BMC (Baseboard Management Controller), se enciende el NAS mediante IPMI
- Como alternativa, también se podría usar Wake-on-LAN
- Al terminar de usarlo, un pequeño script apaga el servidor, espera unos segundos y luego corta la alimentación desde la pared
- Se evitó dejar apagado solo el servidor manteniendo alimentados la placa madre y el BMC, porque eso consume unos 7 W de forma continua
- Como los otros servicios se ejecutan en una Raspberry Pi 4 o en un servidor con consumo en espera mucho menor, no había necesidad de mantener encendido el NAS grande todo el tiempo
- La motivación principal es reducir la factura eléctrica, y también se consideró que probablemente sería bueno para la vida útil de los discos duros
- Sin embargo, en HN surgió la opinión de que la probabilidad de que 24 discos pasen 10 años sin fallar es mayor de lo esperado, por lo que es difícil atribuir este resultado de forma concluyente a operar cortando la energía
- El NAS anterior también funcionó durante unos 5 años con 20 discos Samsung Spinpoint F1 de 1 TB sin fallas de discos
Componentes que dieron problemas antes que los discos
- Aunque los discos siguieron funcionando bien, hace algunos años hubo que reemplazar la placa madre
- Los síntomas de la falla eran que no se podía entrar al BIOS y que a veces fallaba el arranque
- Se intentaron medidas básicas, como retirar la batería CMOS, pero no resolvieron el problema
- La misma placa madre estaba a la venta en Ebay a un precio razonable, así que se pudo reemplazar sin mayores problemas
- Se necesitaba la misma placa porque el servidor usaba 4 ranuras PCIe
- La configuración era de 3 HBA y una NIC de 10 Gbit
- La fuente de alimentación enfrentaba la condición de que, al arrancar, todos los discos hacían spin-up al mismo tiempo y consumían unos 600 W durante algunos segundos
- La fuente tenía una potencia nominal de 750 W y, según se recuerda, el riel de 12 V también podía entregar suficiente potencia, pero a veces se cortaba durante el arranque
Operación con ZFS y resultados de scrub
- ZFS funcionó sin problemas durante años
- Aunque se cambió el sistema operativo varias veces, no hubo problemas para volver a importar el pool existente después de instalar un nuevo OS
- Si se armara un nuevo servidor de almacenamiento, se volvería a usar ZFS
- zpool scrub se ejecuta algunas veces al año
- Completar un scrub toma unas 20 horas
- Como durante el scrub el consumo eléctrico es alto, se ejecuta en días en los que la electricidad es barata bajo una tarifa eléctrica dinámica
- Hasta ahora, en los scrub nunca se detectó un error de checksum
- Se estima que, sumando todos los discos, se leyó más de un petabyte de datos, pero nunca hubo una situación en la que ZFS tuviera que intervenir para recuperar datos
Errores de disco y corrupción silenciosa de datos
- Las fallas de disco se dividen principalmente en dos formas
- Una falla total, en la que el disco directamente no se detecta
- Fallas de lectura/escritura o sectores defectuosos
- La tercera forma, la corrupción silenciosa de datos, se considera muy rara
- Casos en los que el disco no sabe que entregó datos dañados
- Casos en los que no se detecta un error de checksum en la conexión SATA
- Como hay muchas comprobaciones de checksum de bajo nivel, se considera que este riesgo es muy pequeño
- La corrupción silenciosa de datos es un riesgo real, pero se ve como un problema que preocupa más en entornos de gran escala, como centros de datos, que en un entorno residencial
- ZFS vale la pena aprenderlo para usuarios familiarizados con Linux o FreeBSD, y no es demasiado difícil de aprender
Control de ventiladores para un NAS silencioso
- Este NAS es muy silencioso para ser un NAS
- El chasis incluye 3 ventiladores de 12 V robustos para enfriar las 24 bahías de discos
- A velocidad predeterminada son muy ruidosos, pero a bajas RPM son bastante silenciosos y ofrecen suficiente flujo de aire en la mayoría de las situaciones
- Con solo la velocidad baja, la temperatura terminaba subiendo durante lecturas y escrituras de los discos
- La placa madre Supermicro usada permitía controlar todos los headers de ventilador desde Linux
- Se creó un script que ajusta la velocidad de los ventiladores según la temperatura del disco más caliente
- En un subreddit de matemáticas se preguntó por un algoritmo que permitiera mantener el silencio y a la vez enfriar los discos, y recomendaron un controlador PID
- Se escribió el código de control PID en Python, se tomó código de ejemplo y se ajustaron los parámetros
- Este script funcionó bien durante años y mantuvo la temperatura de los discos por debajo de 40 °C
- Debido al bajo flujo de aire base, también hizo falta un ventilador adicional para enfriar las 4 tarjetas PCIe, como las HBA y la tarjeta de red
Cambios en la configuración de red
- Al principio se usó un controlador de red gigabit de cuatro puertos con bonding de red
- Con esta configuración se lograron transferencias de unos 450 MB/s entre varios sistemas
- Como se necesitaban demasiados cables UTP, luego se cambió a tarjetas Infiniband económicas
- Con la configuración Infiniband se podía llegar a unos 700 MB/s entre sistemas
- Al decidir volver de Ubuntu a Debian, la tarjeta Infiniband dejó de funcionar, y no se pudo resolver la causa
- Después se compró una tarjeta 10Gbit Ethernet usada, que sigue funcionando sin problemas hasta hoy
UPS, respaldos y aceptación de riesgo
- Durante un tiempo se usó un UPS grande para permitir un apagado correcto durante cortes de energía
- Al comprobar que el UPS agregaba más de 10 W además del consumo eléctrico del servidor, se retiró
- Se decidió aceptar el riesgo de perder el sistema por un problema de energía
- Los datos más importantes se respaldan tres veces
- Gran parte de los datos almacenados en el servidor no se considera lo bastante importante como para respaldarse
- La pérdida de datos por fallas de discos depende del hardware de reemplazo y de ZFS
- Si esa protección no es suficiente, se ha operado durante 10 años bajo la condición de aceptar la pérdida
Una próxima generación también podría ser más pequeña
- Actualmente no hay un plan de almacenamiento futuro específico
- La razón original para construir este servidor fue no querer seguir moviendo datos por falta de espacio, y todavía queda suficiente espacio disponible
- Hay placa madre, CPU, memoria y tarjetas HBA de repuesto, por lo que es probable que el sistema pueda revivirse incluso si falla
- Como la capacidad de los discos duros aumentó mucho, algún día podría cambiarse el chasis de 24 bahías por un factor de forma más pequeño
- El mismo nivel de almacenamiento redundante podría construirse con 6 a 8 discos duros y RAIDZ2, es decir, redundancia de nivel RAID 6
- Se considera que el almacenamiento sigue siendo caro
- Otra posibilidad es que, en los próximos años, el sistema finalmente falle y que, al no reemplazarlo, termine el hobby del almacenamiento
1 comentarios
Comentarios de Hacker News
Me pregunto si hay un ciclo de reemplazo de discos
Es muy probable que los 24 discos sean del mismo modelo y del mismo lote, y que tengan un desgaste similar; entonces la mayoría podría fallar más o menos al mismo tiempo y el resto también podría caer por la carga adicional durante la reconstrucción
El almacenamiento confiable es complicado
Obviamente ambos fallaron al mismo tiempo, y hubo que pasar toda la noche recuperando todo
La verdad, fue muchísima suerte :D
Pero no parece muy probable que el desgaste de hardware sea tan consistente
Aguantó bien hasta que murió un disco y, durante la reconstrucción, murió el segundo
Claro, tampoco era ZFS, no hacía scrubs regulares, la tasa de fallas de los discos en los 2000 podía ser distinta, y además no lo apagaba cuando no lo usaba
El punto clave, más que la causa exacta, es la falla correlacionada. Con la advertencia habitual: muestra de 1 y un extraño cualquiera de internet
La parte de “este NAS es muy silencioso para ser un NAS” se debe a que los ventiladores de mayor diámetro pueden mover mucho aire incluso a bajas RPM y además son mucho más eficientes energéticamente
Oxide Computer comentó en una charla por qué usan ventiladores de 80 mm: porque son silenciosos y, más importante aún, consumen menos energía
Decían que en otros servidores habían observado que hasta 25% de la energía se va en mover ventiladores, mientras que en los suyos es alrededor de 1%
https://www.youtube.com/shorts/hTJYY_Y1H9Q
https://www.youtube.com/watch?v=4vVXClXVuzE
Salvo los ventiladores de 40 mm de las fuentes Flex ATX, que ya casi no se ven, y aun así los de 80 mm hoy también son bastante raros. Normalmente se ven más de 120 mm o 140 mm
De verdad odio el ruido agudo de alta frecuencia de los ventiladores pequeños típicos de DC a altas RPM
Ojalá también usen alguna forma “inteligente” de controlar la velocidad del ventilador ;-)
Estoy totalmente convencido de la idea de mover más flujo de aire a menor velocidad
Entiendo que en chasis 1U o 2U eso es difícil
Aun así, está bueno. Solo la reducción del ruido del ventilador ya impresiona, y hace preguntarse por qué nadie había pensado antes en algo que parece tan simple
He escuchado el consejo completamente opuesto: que conviene dejar los discos girando para reducir el desgaste por ciclos de encendido y apagado
No sé qué creer, pero sí me gusta que al dejar encendido un NAS con ZFS se puedan hacer scrubs regulares y verificar los datos
Como referencia, tuve un sistema de 4 discos funcionando 10 años y en ese tiempo hubo 2 fallas de disco, aunque no eran de gama enterprise sino WD Green
No es lo mismo encender y apagar un disco una o dos veces al día que hacerlo entrar en spin-down cada 15 minutos o menos
Los WD Green no se recomiendan para NAS. Antes solían aparcar los cabezales de lectura/escritura cada pocos segundos; eso puede estar bien si casi no se accede a los datos, pero en un servidor termina causando desgaste continuo y puede provocar una falla prematura
Los cabezales de lectura/escritura casi no se desgastan mientras flotan sobre los platos. Al apagar, los cabezales se apoyan físicamente en una rampa o en la zona de aterrizaje del plato, y ese aterrizaje y despegue es lo que más los desgasta
En el peor caso, por fricción estática, el cabezal incluso puede arrancarse durante el despegue
Los rodamientos también duran más, y si quedan detenidos demasiado tiempo pueden trabarse. Lo mismo pasa con el motor del disco
La corriente de irrupción al encender también es un estrés eléctrico, por pequeña que sea
Las únicas razones para apagar un disco duro son ahorrar energía, reducir ruido o transportarlo
Entonces podrían estar haciendo spin-up y spin-down varias veces al día, así que esta afirmación no me termina de convencer para nada
Pero no tengo evidencia para sostenerlo
En ese caso, mantener los discos girando para evitar que se enciendan y apaguen cada pocos minutos sí puede ayudar a mejorar la vida útil
Pero en un homelab, probablemente estés gastando mucho más en electricidad de lo que ahorras en desgaste de discos
Tengo varios discos grandes para medios familiares, y me gustaría protegerlos con una garantía mayor que solo “el disco no ha fallado”
Cuando se habla de sistemas de archivos con checksum, normalmente la discusión gira en torno a ZFS y BTRFS, pero me pregunto si alguien ha usado bcachefs
Entiendo que ya fue integrado upstream en el kernel de Linux y que soporta checksums de extremo a extremo. El autor también parece tomarse muy en serio la responsabilidad de un sistema de archivos
¿Alguien aquí lo usa?
https://bcachefs.org/
Tardó más o menos una semana hasta que todo el RAID dejó de montar por un problema con el journal. La configuración era de 8 HDD, 2 SSD como caché de escritura y 2 NVMe como caché de lectura
El autor respondió en Reddit en menos de un día, y probé su parche. Tuve que compilar el kernel de Linux y arrancar con eso, pero no resolvió el problema
Después de eso, lamentablemente ya no hubo respuesta, así que esperé unos días, lo borré todo y volví a un RAID mdadm normal
Lo importante, por supuesto, es que tenía respaldo de todo, pero sí perdí algunos datos no importantes, y me recordó una vez más que la vanguardia es inestable
Aun así, el proceso de configuración y las funciones fueron excelentes. Solo poder añadir discos y marcarlos como caché de lectura/escritura ya estaba muy bien
Sin duda pienso volver a intentarlo después de que madure unos años más
[1] https://linuxiac.com/torvalds-expresses-regret-over-merging-...
[2] https://news.ycombinator.com/item?id=41407768
No querría arriesgar datos de producción, pero para un homelab puede estar bien
Eso sí, hay que preguntarse cuánto tiempo estás dispuesto a dedicarle si algo sale mal
También he usado ZFS por más de 15 años y he visto de todo por culpa de hardware malo, pero en buen hardware empresarial ha funcionado sin fallas
Estoy probando una configuración con unos 2 TiB de SSD delante de unos 8 TiB de discos duros grandes, usando el SSD como caché
He tenido problemas menores con la combinación ya heredada de zsys + ZFS en raíz en Ubuntu, pero es una configuración común y muy usada desde hace años, así que es fácil encontrar soporte
No creo que use bcachefs hasta que tenga un nivel parecido de adopción y soporte comunitario
Creo que el entorno en el que giran los discos marca una diferencia enorme en su vida útil
Un entorno residencial tiene mucha más variabilidad que un centro de datos o una oficina. Las variaciones de temperatura y humedad son un gran desafío, pero lo que me sorprendió fue que incluso pequeñas cantidades de polvo parecían tener un impacto bastante claro
Hace mucho tiempo tenía un arreglo de 8x500G en un viejo servidor Dell en el sótano. Todos los discos eran Seagate nuevos, de 7200 RPM, quizá incluso la versión “empresarial”
Durante 5 años falló un disco cada 6 meses en promedio. Tenía 2 discos de paridad, guardaba discos de repuesto y mandaba RMA cada vez que uno fallaba
Después de mudarme, tuve una sala dedicada para el laboratorio, y con la misma configuración no tuve ni una sola falla en los siguientes 5 años. Ya esperaba que el nuevo entorno fuera mejor, pero me sorprendió cuánto ayudó que fuera más limpio y estable
He tenido un NAS/servidor de archivos funcionando de forma continua en entornos residenciales polvorientos, y todavía hoy alcanza a verse el esponjoso logo gris de Synology, pero nunca he visto algo así
Creo que esa generación tenía un problema de firmware
Aquí se puede ver la tasa anual de fallas: https://www.backblaze.com/blog/best-hard-drive-q4-2014/
En los discos modernos sellados y llenos de helio, aunque eso hubiera sido un problema antes, ya no debería serlo tanto ahora
En cuanto a la parte de “acepto el riesgo de perder el sistema por problemas eléctricos”, hay otra falla muy rara que un UPS sí puede evitar: el desequilibrio eléctrico
Si hay un problema eléctrico por obras cercanas, o si cae un rayo en un poste cerca de la casa, puede haber picos tanto hacia arriba como hacia abajo, y ambos pueden ser destructivos
En mi primer trabajo, hace unos 10 años, varios servidores murieron así. Pero esa fue la única vez que escuché de un problema así
Según entiendo, un UPS también bloquea esos picos, y el UPS moriría antes de que el servidor se dañara
Un rayo cayó directamente en la antena de TV de la casa de mis padres, y eso estaba conectado por cable coaxial hasta el amplificador/divisor en el gabinete de comunicaciones
Luego, por alguna razón, pasó al patch panel de red cercano y quemó todos los controladores Ethernet cableados conectados a la red. Incluyendo los puertos del switch y los integrados en los AP
En el switch de red, la corriente aparentemente trató de irse a tierra y terminó destruyendo hasta la fuente de poder
Cómo pasó de coaxial a Cat5 sigue siendo un poco un misterio. Tal vez el electricista dejó algún tramo tendido en paralelo muy cerca en algún punto
Hubo que recablear toda la red, pero por suerte no había computadoras cableadas en el sitio. El almacenamiento probablemente tampoco lo habría soportado
El APC de 850VA de 99 dólares que compras en Office Depot no hace eso. Solo cambia muy rápido de CA a batería, pero en realidad no limpia la energía
Si puedes comprar algo bueno, de verdad mejora la confiabilidad del hardware a largo plazo. La energía limpia es buena
Por cómo quedaron repartidos los equipos muertos, dañados y aparentemente intactos, el camino más directo fue claramente el par de cobre que llevaba VDSL. El módem estaba conectado por Ethernet a todo lo demás
La solución correcta probablemente sería convertir a óptico, pasar por un tramo de fibra y luego volver a convertir. La electricidad tiene muchas más probabilidades de irse por otro camino que por el vidrio
Pero elegir los productos resultó mucho más molesto de lo esperado, y como no soy de redes, tras como una hora intentando distinguir opciones me rendí
Así que puse un puente Wi‑Fi entre el módem VDSL y el resto del equipo. Espero que en la próxima tormenta ese modo de falla quede aislado
Había un arreglo ZFS conectado a ese mismo módem y sobrevivió, pero creo que fue pura suerte
En ese entonces no tenía servidores, pero era desesperante que varios focos LED se descompusieran cada pocas semanas. Era un edificio viejo, de los 60, y la instalación eléctrica de nuestro departamento también tenía reparaciones improvisadas bastante sospechosas
El “secreto” no es apagarlos, sino simplemente la suerte
Tengo discos HGST de 4TB funcionando 24/7 desde hace más de 10 años. No son exactamente 24, sino 8, pero las fallas han sido 0
Yo también solo he tenido suerte; conozco gente que ha tenido que tramitar RMA varias veces con esos mismos discos
Lo que más me intriga es qué datos requieren 71TB si la mayor parte del tiempo puede estar apagado. ¿Es un servidor de almacenamiento para respaldos?
Por ejemplo, los rodamientos pueden pegarse cuando están fríos
Alguien que sepa bien de estadística probablemente podría estimar una tasa de falla anual de alrededor del 1% y calcular la probabilidad de que los 24 hayan sobrevivido
Además, los 20 discos del NAS anterior tampoco fallaron. Entonces N=44; ¿qué tan afortunado hay que ser?
Es para uso residencial, y cuando necesito los datos normalmente los copio por 10Gbit a un sistema mucho más eficiente en consumo, y luego vuelvo a apagar este NAS
Ha habido discos para los que los ciclos de energía sí eran peligrosos
Así que coincido con el modelo, pero no hay que asumir que esto siempre sea una buena idea para todo el mundo. Algunos SSD necesitan recibir energía de forma periódica
Con el patrón de uso de un NAS, probablemente ese requisito sí se cumpla
Seguramente está bien, y la factura de luz sin duda es más barata. Los discos con grasa extra en el eje fueron en su momento un caso atípico
Me pregunto si Backblaze tendrá un modelo estadístico sobre encender/apagar discos y su vida útil. Ellos parecen estar siempre en el espacio del problema de tenerlos encendidos todo el tiempo
Pero en mi caso no hago ciclos de energía a estos discos con frecuencia. A lo mucho, unas pocas veces al mes
No puedo afirmar ni demostrar que no sea un gran riesgo, pero llevo más de 15 años aceptando ese riesgo creyendo que no lo es
También hay que recordar que los discos duros tienen opción de hacer spin-down en reposo. Es decir, están hechos para soportar muchos spin-ups al día
Usaba discos duros internos de 3.5 pulgadas y un dock USB para respaldar varios equipos Synology, y cuando volvía a insertar un disco en el dock para restaurar archivos o hacer más respaldos, como 1 de cada 10 veces parecía que ya no volvía a encender
Llevo años usando en producción una base de datos PostgreSQL de varios TB sobre ZFS, y hasta ahora no he tenido ningún problema, ni siquiera bit flips
Para quien le interese, documenté aquí la experiencia:
https://lackofimagination.org/2022/04/our-experience-with-po...
Sobre los cortes intermitentes de energía durante el arranque, hay que fijarse en que los discos toman potencia del riel de 5V al iniciar
Un disco similar normalmente consume hasta 1.2A. Si sumas eso al hecho de que la carga máxima del riel de 5V es 25A (Seasonic Platinum 860W), hay una probabilidad alta de que ocurra una falla de alimentación durante el arranque si no usas staggered spinup