Recientemente leí algunas estadísticas alarmantes sobre tasas de corrupción en sistemas con RAM sin ECC y sistemas de archivos típicos. Por lo que puedo buscar en Google, tener un sistema con RAM ECC ejecutando ZFS es probablemente la mejor manera de prevenir la corrupción. La mayor parte de esa información ha estado en el contexto de las discusiones de NAS.
Puedo ver cómo sería útil tener un sistema de este tipo para archivar archivos, suponiendo que no estén dañados en la máquina de origen y se transfieran perfectamente a través de la red.
Lo que no he podido buscar en Google es esto: ¿cuál es el punto de tener archivos de alojamiento NAS de máxima confiabilidad (o como respaldo) cuando trabajo con los archivos en computadoras menos confiables? Tampoco puedo encontrar buena información sobre la corrección de errores en Samba (cualquiera que sea la última versión en un sistema operativo compatible con ZFS como FreeNAS u OpenIndiana); si es propenso a errores, entonces casi todo lo demás no tiene sentido (a menos que personalmente hash todo y verifica todas las transferencias).
¿Necesito (en sentido figurado) desechar mis sistemas actuales y reemplazarlos con hardware (mini) de nivel de servidor si no quiero preocuparme por la descomposición de bits, etc.? Y si sigo ese camino, ¿podría esperar razonablemente tener recursos para algo más que ejecutar ZFS? ¿Sin gastar miles de dólares?
Mi caso de uso:
Me preocupa algo más que la reproducción (por ejemplo, de películas y otros medios). Con frecuencia hago trabajos de programación en las computadoras de mi casa. Por ejemplo, tengo una cantidad cada vez mayor de archivos de bases de datos SQLite para varios proyectos. Que uno de ellos se corrompa podría ser un problema. También tengo muchos gigabytes de fotos familiares y de vacaciones que no sólo quiero archivar sino también organizar, etiquetar, etc. Así que, aunque no dirijo un banco, tengo cosas que serían difíciles de reemplazar y odio pensar en ello. siendo "silenciosamente corrompidos".
Respuesta1
ZFS es bastante exigente con el hardware en el que se ejecuta.
No en el sentido de que deba tener exactamente el chipset, la tarjeta gráfica, la versión de firmware del disco, etc. correctos, sino en el sentido de las capacidades proporcionadas por el hardware. Recuerde, ZFS fue diseñado como una solución de servidor de alta gama y ciertas suposiciones que hace lo reflejan.
Una parte importante de lo que hace que ZFS sea tan excelente para almacenar datos que le interesan es que puede configurarlo de manera que pueda detectary correctoerrores en el almacenamiento. Pueden ser errores triviales, como un cambio de un solo bit en alguna parte, o errores catastróficos, como la falla de varios discos a la vez. Siempre que se mantenga por encima del umbral de redundancia del diseño de su almacenamiento (por ejemplo, no más de dos discos que experimenten problemas simultáneamente en un vdev raidz2), ZFS puede corregir cualquier error utilizando datos redundantes. Otros errores, dependiendo de dónde y cómo ocurren, pueden provocar un pánico (semi) elegante del sistema o un simple error de E/S.
Si lo hace correctamente, también configurará su sistema para limpiar los grupos ZFS a intervalos regulares. Esto detectará la degradación antes de que se convierta en un problema y se lo notificará para que pueda considerar reemplazar los dispositivos de almacenamiento que tienen problemas para conservar sus datos antes de que esto se convierta en un problema.
Sin embargo, esa grandezaDepende del hecho de que se pueda confiar en la RAM.Toda esta validación, corrección, reescritura, etc., ocurre principalmente en la RAM. En servidores de alta gama, no encuentra nada más que RAM ECC.
ZFS protege (y maneja) los metadatos del grupo, los metadatos del sistema de archivos y los datos del usuario de la misma manera.No hay ninguna diferencia real aquí.
Si el sistema de su estación de trabajo experimenta un cambio de bits en la RAM, cuando escriba los datos con los bits invertidos en ZFS, los datos con los bits invertidos serán la base de lo que ZFS eventualmente escriba en el disco. Obviamente, esto es malo, porque significa que su archivo estará dañado. Sin embargo, los datos invertidos en bits seráncorrecto en lo que respecta a ZFS. esto es en realidadbien, porque significa que todos los métodos normales de recuperación de ZFS funcionarán. Sí, la copia más reciente del archivo en cuestión estará corrupta, perosería corrupto de todos modos,sin importar qué sistema de archivos estuviera usando.Puede aprovechar las instantáneas de ZFSpara al menos poder retroceder en el tiempo y encontrar una copia intacta. Configurar algo comozfs-auto-snappara tomar instantáneas de sus sistemas de archivos a intervalos regulares y cortos, mantener un historial más aproximado hacia atrás y olvidarse de él hasta que los necesite. (Por ejemplo, mantenga diez instantáneas con un intervalo de diez minutos; 50 instantáneas con una hora de diferencia; 30 instantáneas con seis horas de diferencia; etc.). Las instantáneas son prácticamente gratuitas en ZFS; si usas ZFS,usar instantáneastambién.
Si su servidor de almacenamiento que ejecuta ZFS tiene una RAM defectuosa, ya sea un bit volteado o atascado (uno o más), y tiene RAM ECC en el servidor de almacenamiento, esto se detectará y el evento se registrará o el sistema detenerse (si el error no se puede corregir). De cualquier manera, se preserva la integridad de los datos almacenados en el servidor. Si su servidor de almacenamiento ZFS tiene RAM sin ECC,entonces un error puede propagarse a través de todos sus datos y metadatosmientras ZFS intenta "corregir" los errores que en realidad son sólo producto de la imaginación de la computadora. En el peor de los casos,lo que realmente le sucede a la gente, todo su grupo se arruinará debido a esto y todos sus datos desaparecerán. La redundancia a nivel de almacenamiento/nivel vdev tampoco ayuda aquí. Con la mayoría de los demás sistemas de archivos (sin el comportamiento de autocorrección), solo se dañará el único lugar que se vio directamente afectado por el cambio de bit, y si esto sucede con los metadatos del sistema de archivos, es probable que los comprobadores y recuperadores de sistemas de archivos tradicionales puedan arreglarlos fácilmente. herramientas. ZFS no tiene esta trampilla de escape;no hay fsck.zfs.(Hayexfoliante zpool, pero eso no funciona si la piscina está rota sin posibilidad de reparación).
Lo que no he podido buscar en Google es esto: ¿cuál es el punto de tener archivos de alojamiento NAS de máxima confiabilidad (o como respaldo) cuando trabajo con los archivos en computadoras menos confiables?
Significa que tiene un depósito de datos confiable.Usted sabe que una vez que los datos llegan a su NAS, están a salvo de la corrupción. Cualquier daño se reparará automáticamente o se le informará sobre el problema (en el caso de ZFS, mediante un error de E/S). Es posible que los datos aún estén dañados mientras se trabaja en ellos utilizando sistemas menos confiables, pero tendrá un lugar al que acudir para obtener una copia conocida que no esté dañada. Esto es una ventaja incluso si solo el sistema NAS tiene ECC RAM, ZFS y monitoreo y alertas de almacenamiento de alta calidad configurados.
Luego, si lo desea, puede agregar (particularmente) RAM ECC a su(s) otro(s) sistema(s) según lo permita su presupuesto, para tapar el último agujero.
¿Necesito (en sentido figurado) desechar mis sistemas actuales y reemplazarlos con hardware (mini) de nivel de servidor si no quiero preocuparme por la descomposición de bits, etc.? Y si sigo ese camino, ¿podría esperar razonablemente tener recursos para algo más que ejecutar ZFS? ¿Sin gastar miles de dólares?
Primero, realmente no necesita hardware de nivel de servidor.Lo que necesita es principalmente RAM ECC (y una CPU y un controlador/chipset de memoria que admita RAM ECC),almacenamiento permanente razonablemente confiable e idealmente un estuche que facilite agregar y quitar discos mientras el sistema está en ejecución. Esto no tiene por qué ser muy caro y ciertamente no tiene por qué costar "miles de dólares".
En segundo lugar, a ZFS le gusta la RAM, pero principalmente para el almacenamiento en caché. Con la mayoría de las cargas de trabajo, 8-16 GB de RAM deberían ser suficientes, y 24-32 GB (fácilmente alcanzables incluso con placas base "de consumo") siguen teniendo un precio razonable incluso cuando se compra RAM ECC de marca de alta calidad. ZFS no consume mucha CPU; puedes hacer que necesite mucha CPU (como conZoL, configurando sha256, compresión gzip-9 y posiblemente deduplicación en combinación), pero no es necesario. Mi propio sistema ejecuta ZFS, no es muy potente (CPU FX-6100 con frecuencia reducida), uso sha256 en todas partes e incluso en E/S puramente secuencial los discos son el factor limitante: una vez que supera el pequeño tamaño inicial, parte de la limpieza de lecturas aleatorias, obtengo aproximadamente el mismo rendimiento en las limpiezas que en un raw dddel dispositivo de almacenamiento subyacente, con CPU de sobra.
Respuesta2
Lo que no he podido buscar en Google es esto: ¿cuál es el punto de tener archivos de alojamiento NAS de máxima confiabilidad (o como respaldo) cuando trabajo con los archivos en computadoras menos confiables?
La posibilidad de que algo salga mal es acumulativa.
En otras palabras (y con números falsos):
si hay un 10% de posibilidades de que algo salga mal en el NAS, y
si hay un 10% de posibilidades de que algo salga mal en el otro dispositivo,
entonces tiene un 20% de posibilidades de fallar cuando leer algo del NAS y reproducirlo en el otro dispositivo.
Tampoco puedo encontrar buena información sobre la corrección de errores en Samba.
Qué versión de samba. Los protocolos cambiaron bastante entre las tres versiones.
si es propenso a errores, entonces casi todo lo demás no tiene sentido (a menos que personalmente haga un hash de todo y verifique todas las transferencias).
Siempre existe el riesgo de cometer errores. Esto simplemente ocurre. Y son detectados y corregidos (por ejemplo, mediante sumas de verificación). Esto no siempre es cierto cuando se usa RAM, que es algo que se puede mejorar usando paridad y/o ECC. Sin embargo, estos problemas son relativamente improbables y es necesario encontrar un equilibrio entre un diseño chapado en oro (y caro) y "suficientemente bueno".
Este equilibrio será bastante diferente para algunos de nosotros (por ejemplo, los bancos necesitan las cosas perfectamente). Probablemente no garanticen el uso de ECC en sistemas personales destinados a reproducir películas.
Respuesta3
La conexión:
Intenté leer la documentación en el sitio web de Samba, pero no pude determinar si Samba tiene corrección de errores. Tuve que asumir el peor de los casos: que Samba depende de que la red subyacente esté libre de errores. Si esa red subyacente es TCP/IP, parece que la única protección es una suma de comprobación débil.
Terminé eligiendo iSCSI porque admite resúmenes de datos y encabezados opcionales que utilizan el algoritmo CRC32C. Eso va más allá de la comprobación de TCP/IP.
¿Hay algún beneficio?
Para mí la respuesta es "Sí, al menos en un escenario". Puedo hacer copias de seguridad de archivos en una máquina ZFS de nivel de servidor usando un programa en el que confío. Entonces puedo comprobar periódicamente sisegún cabe suponerLos archivos no modificados en la máquina original sonde hechosin modificar. Si hay una discrepancia, puedo restaurar la copia de seguridad desde el servidor.
El único punto débil es cuando los archivos se modifican intencionalmente en una máquina poco confiable de consumo. Como la corrupción durante esos cortos períodos de tiempo es tan improbable, lo encuentro aceptable. Si descubro que se ha producido corrupción durante la modificación, tendré copias de seguridad incrementales a las que recurrir.
¿Reemplazar mi computadora con un servidor lo suficientemente potente como para ejecutar ZFS y tener los recursos sobrantes para ser mi computadora principal?
Quizás, pero sería extremadamente caro. Estoy satisfecho con el escenario descrito anteriormente, así que no intentaré esto.