Escenarios de pérdida de datos ZFS


27

Estoy buscando construir un gran ZFS Pool (150 TB +), y me gustaría escuchar las experiencias de las personas sobre escenarios de pérdida de datos debido a fallas de hardware, en particular, distinguir entre instancias donde solo se pierden algunos datos frente a todo el sistema de archivos ( de si incluso hay tal distinción en ZFS).

Por ejemplo: supongamos que se pierde un vdev debido a una falla, como una caja de unidad externa que pierde energía, o una tarjeta controladora que falla. Por lo que he leído, el grupo debería entrar en un modo con errores, pero si se devuelve el vdev, ¿debería recuperarse? ¿o no? o si el vdev está parcialmente dañado, ¿se pierde todo el grupo, algunos archivos, etc.?

¿Qué sucede si falla un dispositivo ZIL? ¿O solo uno de varios ZIL?

¡Realmente se aprecian todas las anécdotas o escenarios hipotéticos respaldados por un profundo conocimiento técnico!

¡Gracias!

Actualizar:

Estamos haciendo esto de forma económica ya que somos una pequeña empresa (aproximadamente 9 personas) pero generamos una buena cantidad de datos de imágenes.

Los datos son en su mayoría archivos pequeños, según mi cuenta, aproximadamente 500k archivos por TB.

Los datos son importantes pero no súper críticos. Estamos planeando usar el conjunto de ZFS para reflejar una matriz de datos "en vivo" de 48 TB (en uso durante aproximadamente 3 años), y usar el resto del almacenamiento para datos 'archivados'.

El grupo se compartirá mediante NFS.

Supuestamente, el bastidor está en una línea de generador de respaldo del edificio, y tenemos dos UPS APC capaces de alimentar el bastidor a plena carga durante aproximadamente 5 minutos.


2
Si aún no sabe lo que está haciendo, obtenga un consultor y / u obtenga algunos cursos. Dudo que todos los detalles que necesita se puedan cubrir en una respuesta simple.
Lucas Kauffman

3
Entonces, ¿todavía estás planeando usar el SATA de 7.2 del consumidor de cheapo? suspiro
Chopper3

@ Chopper3 En realidad, no dije eso intencionalmente ... Estoy considerando seriamente comprar unidades SAS de 2 TB en lugar de unidades SATA de 3 TB. Aunque he visto a muchas personas decir que han estado usando unidades SATA bien ...
Cyclone

1
Los discos SATA para ZFS no son realmente una buena combinación. No encontrarás muchas personas recomendando esa configuración hoy en día. En la escala de la que estás hablando (150 TB), es un error costoso e innecesario. Echa un vistazo a esto, sin embargo .
ewwhite

Respuestas:


22

Diseñe de la manera correcta y minimizará las posibilidades de pérdida de datos de ZFS. Sin embargo, no ha explicado lo que está almacenando en la piscina. En mis aplicaciones, sirve principalmente VMWare VMDK y exporta zvols a través de iSCSI. 150 TB no es una cantidad trivial, por lo que me apoyaría en un profesional para obtener consejos de escalado.

Nunca he perdido datos con ZFS.

Yo he experimentado todo lo demás:

Pero a pesar de todo eso, nunca hubo una pérdida apreciable de datos. Solo tiempo de inactividad. Para los VMWare VMDK que se encuentran en la parte superior de este almacenamiento, a menudo era necesario un fsck o reinicio después de un evento, pero no peor que cualquier otro bloqueo del servidor.

En cuanto a la pérdida de un dispositivo ZIL, eso depende del diseño, de lo que esté almacenando y de sus patrones de E / S y escritura. Los dispositivos ZIL que uso son relativamente pequeños (4GB-8GB) y funcionan como un caché de escritura. Algunas personas reflejan sus dispositivos ZIL. El uso de dispositivos SSD STEC de alta gama hace que la duplicación sea prohibitiva. En su lugar, uso tarjetas PCIe DDRDrive individuales . Planifique la protección de la batería / UPS y use tarjetas SSD o PCIe con una copia de seguridad de supercondensador (similar a las implementaciones de controlador RAID BBWC y FBWC ).

La mayor parte de mi experiencia ha estado en el lado de Solaris / OpenSolaris y NexentaStor . Sé que la gente usa ZFS en FreeBSD, pero no estoy seguro de qué tan atrás están las versiones de zpool y otras características. Para implementaciones de almacenamiento puro, recomendaría ir a la ruta Nexentastor (y hablar con un socio experimentado ), ya que es un sistema operativo especialmente diseñado y hay implementaciones más críticas que se ejecutan en derivados de Solaris que FreeBSD.


Actualicé mi pregunta con más información, pero estoy particularmente interesado en conocer más detalles sobre: ​​'nunca una pérdida apreciable de datos' y lo que eso significa / involucrado. También estoy interesado en saber más acerca de cómo recuperar esos zpools defectuosos, manejar las NIC defectuosas e incluso los problemas con las unidades SATA y cambiar a SAS (aunque te alegrará saber que probablemente iré con 2TB SAS sobre 3TB SATA , por recomendación tuya).
Ciclón

Pérdida no apreciable == unos pocos segundos de datos transaccionales, o un estado de falla consistente . Y las NIC malas se aislaron en un solo host VMWare y provocaron problemas a nivel de VM. No es el almacenamiento ZFS subyacente.
ewwhite

El design the right wayenlace está roto ahora.
Saurabh Nanda

11

Accidentalmente sobrescribí ambos ZIL en la última versión de OpenSolaris, lo que provocó la pérdida irrevocable de todo el grupo. (¡Error realmente grave de mi parte! No entendí que perder el ZIL significaría perder el grupo. Afortunadamente se recuperó de la copia de seguridad con el tiempo de inactividad).

Sin embargo, desde la versión 151a (no sé de antemano cómo significa la versión de ZPool), este problema se ha solucionado. Y puedo testificar que funciona.

Aparte de eso, he perdido CERO datos en un servidor de 20tb, incluso debido a varios casos más de error del usuario, fallas múltiples de energía, mala administración del disco, configuraciones incorrectas, numerosos discos fallidos, etc. Aunque la administración y Las interfaces de configuración en Solaris cambian con frecuencia y enloquecedor de una versión a otra y presentan un objetivo significativo de habilidades siempre cambiantes, sigue siendo la mejor opción para ZFS.

No solo no he perdido datos en ZFS (después de mi terrible error), sino que me protege constantemente. Ya no experimento corrupción de datos, lo que me ha afectado durante los últimos 20 años en cualquier número de servidores y estaciones de trabajo, con lo que hago. La corrupción de datos silenciosa (o simplemente "bastante silenciosa") me ha matado varias veces, cuando los datos salen de la rotación de la copia de seguridad, pero de hecho se han dañado en el disco. O en otros escenarios donde las copias de seguridad respaldaron las versiones corruptas. Este ha sido un problema mucho más grande que simplemente perder datos a lo grande de una vez, lo que casi siempre se respalda de todos modos. Por esta razón, me encanta ZFS y no puedo entender por qué la suma de comprobación y la curación automática no han sido características estándar en los sistemas de archivos durante una década. (Por supuesto, los sistemas verdaderamente de vida o muerte generalmente tienen otras formas de asegurar la integridad,

Palabra inteligente: si no desea descender a ACL-hell, no use el servidor CIFS integrado en ZFS. Usa Samba. (Sin embargo, dijiste que usas NFS).

No estoy de acuerdo con el argumento SAS vs. SATA, al menos la sugerencia de que SAS siempre se prefiere sobre SATA, para ZFS. No sé si ese comentario [s] hacía referencia a la velocidad de rotación del plato, la supuesta fiabilidad, la velocidad de la interfaz o algún otro atributo [s]. (O tal vez simplemente "cuestan más y, en general, no son utilizados por los consumidores, por lo tanto, son superiores". Una encuesta de la industria publicada recientemente (todavía estoy en las noticias, estoy seguro), reveló que SATA realmente sobrevive a SAS en promedio, al menos con el tamaño de muestra significativo de la encuesta. (Me sorprendió, eso es seguro.) No puedo recordar si se trataba de versiones "empresariales" de SATA, o de los consumidores, o qué velocidades, pero en mi considerable experiencia, los modelos empresariales y de consumo fallan al mismo tiempo. Tasas estadísticamente significativas. (Sin embargo, existe el problema de que las unidades de consumo tardan demasiado tiempo en fallar, lo que definitivamente es importante en la empresa, pero eso no me ha mordido, y creo que es más relevante para los controladores de hardware que podrían tomar todo volumen fuera de línea en tales casos. Pero eso no es un problema SAS vs SATA, y ZFS nunca me ha fallado. Como resultado de esa experiencia, ahora uso una combinación de 1/3 unidades SATA empresariales y 2/3 de consumo .) Además, no he visto un impacto significativo en el rendimiento con esta mezcla de SATA, cuando se configura correctamente (por ejemplo, una franja de espejos de tres vías), pero nuevamente tengo una baja demanda de IOPS, así que dependiendo de qué tan grande sea su tienda y casos de uso típicos, YMMV. Definitivamente, he notado que el tamaño de caché incorporado por disco es más importante para los problemas de latencia que la velocidad de rotación del plato, en mis casos de uso.

En otras palabras, es un sobre con múltiples parámetros: costo, rendimiento, IOPS, tipo de datos, número de usuarios, ancho de banda administrativo y casos de uso comunes. Decir que SAS es siempre la solución correcta es ignorar un gran universo de permutaciones de esos factores.

Pero de cualquier manera, ZFS es absolutamente genial.


3
Gracias por tomarse el tiempo de responder. Su experiencia con ZFS es consistente con la mía. Mis comentarios sobre la selección de unidades fueron específicamente sobre discos Nearline SAS versus SATA. La principal diferencia es la interfaz. Son mecánicamente equivalentes. La mejor práctica en ZFS-land ahora es evitar SATA debido a la necesidad de interfaces de doble puerto, mejor corrección de errores y tiempos de espera manejables ofrecidos por SAS.
ewwhite

Terminé con discos SAS de 3 TB pero ... antes de hacerlo, improvisé 30 discos mixtos (5 SGB de 400 GB, SATS de 750 GB, 14 SAS de 1 TB) que coloqué en el mismo gabinete expandido SAS. Realmente el peor de los casos según. Estas unidades también tenían ~ 2-3 años de tiempo de ejecución ya. Luego escribí un programa que ejecutaba 8 subprocesos que leían al azar, escribían y borraban archivos del grupo. Lo corrí durante más de una semana. Leí y escribí> 100 TB en el grupo ... sin problemas. AVG R / W 100-400MB / seg. Sospecho que las advertencias SATA sobre SAS podrían ser viejas noticias ahora.
Ciclón el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.