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.
fuente
Respuestas:
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.
fuente
design the right wayenlace está roto ahora.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.
fuente