Configuración RAID para NAS grande

13

Estoy pensando en construir una caja NAS de disco de 24 1TB, pero no estoy seguro de cuál es la mejor configuración de disco. Estoy mirando el uso del controlador areca ARC-1280ML-2G y colgando las 24 unidades.

Me gustaría que todo se monte como un volumen, debido al tipo de datos que almacenamos en él. Una idea loca que teníamos era configurar 6 volúmenes RAID 5 de 4 discos, luego hacer RAID 5 de software sobre esos 6 volúmenes. Eso significaría que cualquier volumen podría morir en nosotros y aún así no perderíamos datos.

Debo señalar que este es un proyecto de I + D, tenemos una próxima aplicación en la que necesitaremos decenas de terabytes de almacenamiento para ser rápidos y altamente disponibles. Pero para la fase inicial de I + D podemos aceptar algunos riesgos.

¿Cuál es la mejor solución para este tipo de configuración? Con 24 discos de 1 TB, es probable que más de uno falle al mismo tiempo (o dentro del tiempo que lleva reconstruir el volumen después de un primer fallo), por lo que tengo problemas para encontrar una buena solución.

kevin42
fuente

Respuestas:

10

Ya existe un nivel RAID para lo que desea; se llama RAID 10.

El MTBF para unidades de nivel profesional y de consumo ha aumentado en un orden de magnitud en los últimos años, la tasa de error no corregible se ha mantenido relativamente constante. Esta tasa se estima en 10 ^ 14 bits, por lo que un bit por cada 12 terabytes leídos, para unidades SATA de consumo, fuente .

Entonces, por cada escaneo de sus pases de su unidad de 24Tb, estadísticamente encontrará al menos 2 errores de un solo bit. Cada uno de esos errores desencadenará una reconstrucción RAID5 y, lo que es peor, durante la reconstrucción, un segundo error causará una doble falla.

Dave Cheney
fuente
Excelentes puntos en la tasa de error no corregible, pero en el tercer párrafo, debe agregar que "estadísticamente, encontrará ...", ya que todos sabemos que los errores de lectura (o la falta de ellos) no son seguros
Matt Simmons
¿No intentará leer nuevamente antes de reconstruir?
Antoine Benkemoun
Antoine: Claro, pero si realmente no se puede leer, tendrá que reconstruir para obtener los datos de la paridad, IIRC.
Matt Simmons
@ Antonie, estos son errores de lectura que no se pueden corregir, es decir, errores que no son corregibles por la lógica ECC de las unidades (que está corrigiendo errores a una velocidad significativamente mayor que 1: 10 ^ 14)
Dave Cheney
¿Entonces estos son errores causados ​​por errores de escritura? ¿Qué impide que una segunda lectura suceda con éxito?
Antoine Benkemoun
11

Este es precisamente mi trabajo diario ... construir servidores de almacenamiento Linux.

  • La tarjeta Areca está bien. Puede usarlo en RAID-6, proporcionará una seguridad razonable. Compre también la unidad de batería de respaldo opcional .
  • Utilice discos de calidad empresarial , no unidades de escritorio. Gastará 400 dólares más en su servidor, pero vale la pena. Compre dos unidades de repuesto. No te metas con él, usa discos del mismo modelo.
  • Para el sistema de archivos, use XFS . No es broma, ext3 y sus amigos simplemente no estarán a la altura del trabajo para sistemas de archivos de 16 TB +. Incluso en caso de un accidente grave, xfs_repair será bastante rápido en un volumen de 20 TB (15 minutos, no más).
  • Preferiblemente, use LVM2 , facilitará la administración del almacenamiento, incluso si no planea modificarlo demasiado.
  • instale la herramienta de administración de areca y escriba un trabajo cron para enviarle un correo electrónico diario con un chequeo de salud.
  • No olvides el respaldo . RAID no es una copia de seguridad; Si alguien simplemente elimina un archivo importante, no podrá recuperarse sin una copia de seguridad adecuada. Personalmente uso rdiff-backup para guardar todos los datos importantes en un servidor dedicado con un historial de un mes; También puede crear dos volúmenes RAID en su servidor de archivos y respaldar uno en el otro.
wazoox
fuente
6

wow, RAID5 sobre RAID5? ¿Quieres discutir problemas de rendimiento? Tendrás toneladas . El host del que cuelgue a esos tendrá gatitos calculando la paridad, escribiendo esa paridad en 3 unidades y luego calculando la paridad de ESA paridad y escribiéndola en la cuarta unidad de ese conjunto. ¡GUAUU!

Hablemos de RAID10. Es esencialmente RAID 1, pero divide sus unidades por la mitad y refleja eso. Es tolerante a fallas ya que puede perder 2 unidades y aún así estar bien, además el rendimiento es sobresaliente.

Si no necesita una cantidad increíble de espacio, pero tiene una matriz de 24 TB sentada sin nada mejor que hacer, pero tiene que estar absolutamente positiva, entonces puede considerar RAID60. Es esencialmente RAID6 usando conjuntos de unidades en espejo. Perderá alrededor de la mitad de sus unidades, y el rendimiento será malo, pero estará casi garantizado de que los datos estarán allí.

Realmente, iría con RAID10. Funciona bien y funciona bien. Respaldo la opinión de Evan de que probablemente no debería hacer conjuntos RAID gigantes de tantos discos, porque como él dice, cosas como fsck y chkdsk tomarán una eternidad, y lo más importante en mi mente, porque la probabilidad estadística de un error de lectura sube como lo hace el tamaño del disco individual. Recomiendo 7-10 discos por juego. Podría crear 3 volúmenes RAID de un tamaño muy decente con esa cantidad de cabezales.

Independientemente de lo que elija, recuerde dejar un par de discos en repuestos dinámicos, para que pueda comenzar a reconstruir de inmediato, en lugar de que la matriz espere a que los reemplace. Tan pronto como muere un disco, el reloj comienza a marcar para que salga otro.

Matt Simmons
fuente
@ Matt: no estoy hablando del tamaño de los conjuntos RAID, estoy hablando del tamaño del sistema de archivos. El uso de un único sistema de archivos tan grande, sin importar el tipo de sistema de archivos, está pidiendo enorme tiempo de inactividad cuando se tiene que realizar una verificación de sistema de archivos debido a que el sistema operativo anfitrión "dañado" el sistema de archivos, etc.
Evan Anderson
@Evan - Lo siento, mi mal. Pero ese es otro argumento en contra también.
Matt Simmons
@ Matt: ¿Una discusión en contra de qué? El diseño de los contenedores RAID y la cantidad de sistemas de archivos en esos contenedores RAID son preocupaciones ortogonales. No tiene que tener un solo sistema de archivos en un solo contenedor RAID, y un sistema de archivos puede abarcar múltiples contenedores RAID en la mayoría de los sistemas operativos.
Evan Anderson
Tienes razón en ambos. Estamos de acuerdo No debe crear sistemas de archivos extremadamente grandes porque el tiempo de verificación es malo. Tampoco debe hacer volúmenes de incursión extremadamente grandes porque aumenta la probabilidad estadística de un error de lectura.
Matt Simmons
2

¿Por qué no RAID 1 + 0? Todo se maneja en el nivel del controlador ...

Matt Rogish
fuente
1

Sé que dijiste "I + D", pero también dijiste "altamente disponible". Yo cuestionaría los "ahorros" de una solución de bricolaje en lugar de comprar equipo SAN estándar para hacer esto. Cuando las cosas salgan mal con su solución de bricolaje, estará en una posición envidiable de no tener a quién contactar para pedir ayuda. ¿Cuánto le cuesta el tiempo de inactividad por hora? Puede consumir el costo de algunos equipos SAN de nivel medio bastante rápido en gastos de tiempo de inactividad, ignorando el gasto asociado con la pérdida de datos por error.

Independientemente de lo que haga sobre el disco subyacente, no crearía un solo sistema de archivos tan grande.

La corrupción del sistema de archivos es una posibilidad real (problema con el controlador RAID, errores del sistema operativo, etc.). En un volumen tan grande, una comprobación del sistema de archivos llevará una eternidad. Recomiendo encarecidamente el uso de múltiples volúmenes que pueden combinarse lógicamente para aparecer como un solo sistema de archivos (a través de diversos medios: no mencionó el sistema operativo, por lo que no puedo darle ideas específicas). Si tiene algún daño en el sistema de archivos, perderá parte del volumen lógico, pero aún estará "activo".

Como ejemplo: en un mundo de Windows, ejecutar CHKDSK en un volumen NTFS de 20TB lleno de archivos será LENTO . En ese tipo de entorno, crearía múltiples volúmenes NTFS más pequeños y los combinaría lógicamente en un solo espacio de nombres con DFS.

Evan Anderson
fuente
1

wazoox, las respuestas son buenas. No tengo el representante para darle más puntos positivos, pero agregaría lo siguiente.

RAID 6 o al menos 2 discos de paridad en vivo por 10 discos, 16 a lo sumo, es decir, si puede tomar alrededor de un día cuando el rendimiento se verá afectado por la reconstrucción de su banda. Si no puede vivir con la degradación, entonces tendrá que ser rayas reflejadas.

Si va por la ruta de Linux, usaría una tarjeta de banda de hardware (con respaldo de batería) o tendría un controlador de banda en la caja del disco. Estoy de acuerdo en que xfs es el sistema de archivos de elección en Linux, sin embargo, tenga en cuenta que los sistemas de archivos de alrededor de 50 TB en xfs requieren más de 16 GB de RAM si necesita ejecutar xfs_check.

Consideraría seriamente una buena caja NAS, como una NetApp, ya que son mucho menos trabajo a largo plazo, depende de cuánto le valga a la empresa el tiempo de su administrador de almacenamiento.

Lograr que nfs / samba funcione bien es un poco un arte oscuro. ¿Va a utilizar 10 GB de éter o solo agregaciones de 1 GB / seg? (No obtenga tarjetas Broadcomm, especialmente las de 10 GB).

LVM2 es obvio, pero no use el disparo instantáneo, ya que no es rápido.

Recuerde que las copias de seguridad de esto llevarán algún tiempo.

Pruebe la forma en que el sistema puede fallar antes de que entre en producción y escríbalo donde usted y sus colegas puedan encontrar los documentos cuando todo salga mal.

James
fuente
1

Depende de su relación lectura / escritura. Usamos muchos receptáculos de unidades de disco SAS externas de 25 discos HP MSA70 y siempre los creamos como una sola matriz RAID6, ya que nuestra relación de lectura / escritura es del 99%: 1%, por lo que no nos importa que R6 sea el más lento en la escritura ( sigue siendo bastante rápido, pero no tan bueno en comparación con otros). De esta manera, tenemos 23 discos con datos disponibles, tenemos muy buenos beneficios, como en MUY bueno, lectura aleatoria y lectura general de ancho de banda y podemos sobrevivir a dos fallas de disco.

Como guía general, una matriz RAID5 no debería tener más de aproximadamente 14 discos en una matriz, mientras que una RAID6 debería estar bien con hasta 54 discos más o menos, obviamente, cuanto mayor sea la matriz, mayor será el abismo entre el rendimiento de lectura y escritura y el Se necesitarán reconstrucciones más lentas, pero PUEDE ser una buena compensación.

Chopper3
fuente
0

Para empezar, agregaría dos discos en espera.

RAID 5 o 6 está bien para lecturas aleatorias o grandes lecturas y escrituras secuenciales. Si va a obtener muchas escrituras pequeñas, vaya con RAID 10 ya que RAID 5+ recibe un golpe 4 veces mayor en escrituras pequeñas.

Si va a activar la memoria caché de escritura, recuerde respaldarla con una batería.

Hans Malherbe
fuente