¿Por qué los niveles de RAID anidados 1 + 5 o 1 + 6 son casi desconocidos? El artículo de Wikipedia de niveles RAID anidados actualmente no tiene sus secciones. No entiendo por qué no son más comunes que RAID 1 + 0, especialmente en comparación con la duplicación triple RAID 1 + 0.

Es evidente que el tiempo de reconstrucción se está volviendo cada vez más problemático a medida que las capacidades de manejo aumentan más rápido que su rendimiento o confiabilidad. Me dijeron que RAID 1 se reconstruye más rápido y que una matriz RAID 0 de pares RAID 1 evita el problema, pero seguramente también lo haría una matriz RAID 5 o 6 de pares RAID 1. Al menos esperaría que fueran una alternativa común a RAID 1 + 0.

Para 16 de las unidades de 1TB, aquí están mis cálculos de la probabilidad ingenua de recurrir a la copia de seguridad, es decir, con el supuesto simplificador de que las unidades son independientes con una probabilidad uniforme:

RAID | storage | cumulative probabilities of resorting to backup /m
 1+0 |     8TB | 0, 67, 200, 385, 590, 776, 910, 980, 1000, 1000, 1000
 1+5 |     7TB | 0,  0,   0,  15,  77, 217, 441, 702,  910, 1000, 1000
 1+6 |     6TB | 0,  0,   0,   0,   0,   7,  49, 179,  441,  776, 1000
(m = 0.001, i.e. milli.)

Si esto es correcto, entonces está bastante claro que RAID 1 + 6 es excepcionalmente más confiable que RAID 1 + 0 para solo una reducción del 25% en la capacidad de almacenamiento. Como es el caso en general, el rendimiento de escritura teórico (sin contar los tiempos de búsqueda) es la capacidad de almacenamiento / tamaño de matriz × número de unidades × rendimiento de escritura de la unidad más lenta en la matriz (los niveles RAID con redundancia tienen una mayor amplificación de escritura para escrituras que no llene una franja, pero esto depende del tamaño del fragmento), y el rendimiento de lectura teórico es la suma de los rendimientos de lectura de las unidades en la matriz (excepto que RAID 0, RAID 5 y RAID 6 todavía pueden estar limitados teóricamente por los rendimientos de lectura de la unidad más lenta, la segunda más lenta y la tercera más lenta respectivamente). Es decir, suponiendo unidades idénticas, eso sería respectivamente 8 ×, 7 ×,

Además, considere un RAID 0 cuádruple de RAID 1 triplica, es decir, RAID 1 + 0 triple reflejo de 12 unidades, y un RAID 6 sextuple de pares RAID 1, es decir, RAID 1 + 6 de 12 unidades. De nuevo, estos son unidades idénticas de 1TB. Ambos diseños tienen el mismo número de unidades (12), la misma cantidad de capacidad de almacenamiento (4 TB), la misma proporción de redundancia (2/3), el mismo rendimiento máximo de escritura (4 ×) y el mismo rendimiento máximo de lectura ( 12 ×). Aquí están mis cálculos (hasta ahora):

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | 0, 0, 18,  ?,   ?,   ?,   ?,   ?, 1000
1+6 (6×2) | 0, 0,  0,  0,   0,  22, 152, 515, 1000

Sí, esto puede parecer excesivo, pero cuando se usa la duplicación triple para dividir un clon para la copia de seguridad, RAID 1 + 6 también puede usarse, simplemente congelando y eliminando 1 de cada unidad de todas menos 2 de la RAID 1 pares, y mientras lo hace, todavía tiene una confiabilidad mucho mejor cuando se degrada que la matriz RAID 1 + 0 degradada. Aquí están mis cálculos para 12 unidades degradadas por 4 de esta manera:

RAID      | cumulative probabilities of resorting to backup /m
1+0 (4×3) | (0, 0, 0, 0), 0, 143, 429, 771, 1000
1+6 (6×2) | (0, 0, 0, 0), 0,   0,  71, 414, 1000

Sin embargo, el rendimiento de lectura podría degradarse a 6 × durante este tiempo para RAID 1 + 6, mientras que RAID 1 + 0 solo se reduce a 8 ×. Sin embargo, si una unidad falla mientras la matriz está en este estado degradado, la matriz RAID 1 + 6 tendría una probabilidad de 50-50 de permanecer en aproximadamente 6 × o estar limitada a 5 ×, mientras que la matriz RAID 1 + 0 tendría estar limitado a un cuello de botella 4 × . El rendimiento de escritura no debería verse afectado (incluso podría aumentar si las unidades tomadas para respaldo fueran las unidades limitantes más lentas).

De hecho, ambos pueden verse como 'espejo triple' porque la matriz RAID 1 + 6 degradada es capaz de separar un grupo RAID 6 adicional de 4 unidades. En otras palabras, este diseño RAID 1 + 6 de 12 unidades se puede dividir en 3 conjuntos RAID 6 degradados (pero funcionales).

Entonces, ¿es solo que la mayoría de la gente no ha entrado en las matemáticas en detalle? ¿Veremos más RAID 1 + 6 en el futuro?

En general, diría que RAID 1 + 0 tenderá a ser más utilizado que 1 + 5 o 1 + 6 porque RAID 1 + 0 es lo suficientemente confiable y proporciona un rendimiento marginalmente mejor y un almacenamiento más utilizable.

Creo que la mayoría de la gente tomaría el fracaso de un par RAID 1 completo dentro del grupo RAID 1 + 0 como un evento increíblemente raro por el que vale la pena romper las copias de seguridad, y probablemente no esté demasiado entusiasmado con obtener menos del 50% de su físico disco como espacio utilizable.

Si necesita una mayor confiabilidad que RAID 1 + 0, ¡adelante! ... pero la mayoría de la gente probablemente no necesita eso.

La respuesta práctica se encuentra en algún lugar en la intersección de las especificaciones del controlador RAID de hardware, los tamaños de disco promedio, los factores de forma de la unidad y el diseño del servidor.

La mayoría de los controladores RAID de hardware están limitados en los niveles RAID que admiten. Estas son las opciones de RAID para un controlador HP ProLiant Smart Array:

[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]

nota: el "adm" es solo espejo triple

Los controladores RAID LSI admiten: 0, 1, 5, 6, 10, 50, and 60

Por lo tanto, estos controladores solo son capaces de RAID 50 y 60 como niveles anidados. LSI ( née Dell PERC ) y HP comprenden la mayor parte del mercado de adaptadores de almacenamiento de servidores empresariales. Esa es la razón principal por la que no ve algo como RAID 1 + 6 o RAID 61 en el campo.

Más allá de esa consideración, los niveles de RAID anidados más allá de RAID 10 requieren una cantidad relativamente grande de discos. Dadas las crecientes capacidades de disco disponibles en la actualidad (con discos SAS y SATA nearline de 3.5 "), junto con el hecho de que muchos chasis de servidores están diseñados alrededor de 8 jaulas de discos de 2.5", no hay muchas oportunidades para configurar físicamente RAID 1+ 6 o RAID 61.

Las áreas donde puede ver algo como RAID 1 + 6 serían las soluciones RAID de software de chasis grande. Linux MD RAID o ZFS son definitivamente capaces de hacerlo. Pero en ese momento, la falla de la unidad puede mitigarse con discos de repuesto en caliente o en frío. La confiabilidad de RAID no es un gran problema en estos días, siempre que evite el nivel de RAID tóxico y las combinaciones de hardware (por ejemplo, discos RAID 5 y 6TB). Además, el rendimiento de lectura y escritura se abstraería mediante capas y capas de almacenamiento en caché. Las cargas de trabajo de almacenamiento promedio generalmente se benefician de una u otra.

Entonces, al final, parece que la necesidad / demanda simplemente no existe.

• Tiene rendimientos decrecientes en confiabilidad. Es poco probable que RAID 6 genere fallas incluso en unidades SATA desagradables con una tasa de 1 en 10 ^ 14 UBER. En las unidades FC / SAS, su UBER es 1 en 10 ^ 16 y también obtiene un rendimiento considerablemente mayor.

• La confiabilidad del grupo RAID no lo protege contra la eliminación accidental. (por lo que necesita las copias de seguridad de todos modos)

• más allá de ciertos niveles de RAID, sus probabilidades de una falla compuesta en los discos se vuelven más bajas que la falla compuesta de la infraestructura de soporte (energía, red, fuga de aire acondicionado, etc.)

• Escribir penalidad. Cada escritura entrante en su RAID 61 activará 12 operaciones de E / S (ingenuamente hechas). RAID 6 ya es doloroso en escenarios de 'nivel bajo' en términos de PIO por escritura aleatoria de TB. (y en el nivel superior, su tasa de fallas es 100 veces mejor de todos modos)

• no es '25% de reducción ', es una reducción adicional de 25%. Su 16TB se está convirtiendo en 6TB. Entonces obtienes un 37.5% de almacenamiento utilizable. Necesita 3 veces más discos por capacidad y 3 veces más espacio en el centro de datos. Probablemente obtendrá más confiabilidad simplemente haciendo conjuntos RAID6 más pequeños. No he hecho el cálculo de números, pero intente, por ejemplo, las sumas de RAID 6 en conjuntos 3x 3 + 2 (15 unidades, menos sobrecarga de almacenamiento que su RAID10). O haciendo espejos de 3 vías en su lugar.

Habiendo dicho eso, es más común de lo que piensas hacerlo para DR de sitios múltiples. Ejecuté matrices de almacenamiento replicadas donde tengo grupos RAID RAID5 / 6 / DP de forma asíncrona o sincrónica en un sitio de recuperación ante desastres. (No sincronice si puede evitarlo; se ve bien, en realidad es horrible).

Con mis NetApps, ese es un metrocluster con algunos agregados reflejados. Con mis VMAX, tenemos Symmetrix Remote Data Facility (SRDF). Y mis 3PAR hacen copia remota.

Es costoso, pero proporciona niveles de DR de 'centro de datos en llamas'.

Con respecto a los espejos triples: los he usado, pero no como medidas directas de resistencia RAID, sino como clones completos como parte de una estrategia de respaldo. Sincronice un tercer espejo, divídalo, móntelo en un servidor separado y realice una copia de seguridad utilizando una infraestructura completamente diferente. Y a veces gira el tercer espejo como una opción de recuperación.

El punto que estoy tratando de hacer es que, en mi experiencia directa como administrador de almacenamiento, en un estado de husillo de ~ 40,000 (sí, estamos reemplazando decenas de unidades diariamente), hemos tenido que ir a copias de seguridad para una variedad de razones en los últimos 5 años, pero ninguna de ellas ha sido la falla del grupo RAID. Debatimos los méritos relativos y el tiempo de recuperación aceptable, el punto de recuperación y las ventanas de interrupción. Y apuntalar todo esto SIEMPRE es el costo de la resistencia adicional.

Nuestra matriz de todos los medios de fregado y falla predicen, y sobra agresivamente y prueba las unidades.

Incluso si hubiera una implementación RAID adecuada, la relación costo-beneficio simplemente no existe. El dinero gastado en el espacio de almacenamiento se invertiría mejor en una retención más larga o un ciclo de respaldo más frecuente. O comunicaciones más rápidas. O simplemente husillos más rápidos, porque incluso con números de resistencia idénticos, una reconstrucción más rápida de repuestos mejora su probabilidad de falla compuesta.

Por lo tanto, creo que ofrecería la respuesta a su pregunta:

No ve RAID 1 + 6 y 1 + 5 muy a menudo, porque el beneficio de costo simplemente no se acumula. Dada una cantidad limitada de dinero, y dada la necesidad de implementar una solución de respaldo en primer lugar, todo lo que está haciendo es gastar dinero para reducir su frecuencia de interrupciones. Hay mejores formas de gastar ese dinero.

Los sistemas modernos y avanzados no implementan formas como esa porque son excesivamente complicadas, completamente innecesarias y contrarias a cualquier aspecto de eficiencia.

Como otros han señalado, la relación entre el espacio bruto y el espacio utilizable es esencialmente 3: 1. Eso es esencialmente tres copias (dos copias redundantes). Debido al costo de cálculo de "raid6" (dos veces, si se refleja), y la pérdida resultante de IOPS, esto es muy ineficiente. En ZFS, que está muy bien diseñado y ajustado, la solución equivalente, en cuanto a capacidad, sería crear una franja de espejos de 3 vías.

A modo de ejemplo, en lugar de un espejo de formas raid6 / raidz2 de 6 vías (12 unidades en total), que sería muy ineficiente (tampoco algo que ZFS tenga ningún mecanismo para implementar), tendría espejos 4x de 3 vías (también 12 unidades). Y en lugar de 1 unidad de IOPS, tendría 4 unidades de IOPS. Especialmente con las máquinas virtuales, esa es una gran diferencia. El ancho de banda total para las dos formas puede ser muy similar en lecturas / escrituras secuenciales, pero la franja de los espejos de 3 vías definitivamente respondería mejor con lectura / escritura aleatoria.

En resumen: raid1 + 6 es generalmente poco práctico, ineficiente y, como era de esperar, nada que alguien serio sobre el almacenamiento considere desarrollar.

Para aclarar la disparidad de IOPS: con un espejo de formas raid6 / raidz2, con cada escritura, las 12 unidades deben actuar como una sola. La forma total no puede dividir la actividad en múltiples acciones que múltiples formas pueden realizar de forma independiente. Con una franja de espejos de 3 vías, cada escritura puede ser algo con lo que solo uno de los 4 espejos debe lidiar, por lo que otra escritura que ingrese no tiene que esperar a que se ocupe toda la forma ómnibus antes de considerar otras acciones .

Como nadie lo dijo directamente: el rendimiento de escritura de Raid6 no es marginalmente peor. Es horrible más allá de toda descripción si se pone bajo carga.

La escritura secuencial está bien y siempre que el almacenamiento en caché, la fusión de escritura, etc., pueda ocultarlo, se verá bien. Bajo una carga alta, las cosas se ven mal y esta es la razón principal por la que casi nunca se usa una configuración 1 + 5/6.

Buscar tiempos

El problema es que la amplificación de búsqueda de escritura se comporta de manera muy diferente a la amplificación de rendimiento de escritura . La amplificación mínima del rendimiento de escritura con paridad ocurre cuando se escribe una franja completa a la vez (llamemos a este adjetivo 'franja completa') pero la amplificación de búsqueda de escritura mínima ocurre, por el contrario, cuando la escritura completa después de una búsqueda en el dispositivo virtual encaja Un solo pedazo. Antes de entrar en detalles, las relaciones son mucho más fáciles de transmitir en forma tabulada:

RAID | write throughput amplification factor | write seek amplification factor
     | full-stripe (e.g.) | single-chunk     | full-stripe  | single-chunk
   0 | 1           ;  1   | 1           ;  1 | n       ; 12 | 1           ;  1
   1 | n           ; 12   | n           ; 12 | n       ; 12 | n           ; 12
   5 | n/(n - 1)   ; ~1.1 | min [3, n]  ;  3 | n       ; 12 | min [3, n]  ;  3
   6 | n/(n - 2)   ;  1.2 | min [5, n]  ;  5 | n       ; 12 | min [5, n]  ;  5
*1+0 | n₁          ;  3   | n₁          ;  3 | n       ; 12 | n₁          ;  3*
 1+5 | n/(n₅ - 1)  ;  2.4 | expr₁       ;  5 | n       ; 12 | expr₁       ;  5
*1+6 | n/(n₆ - 2)  ;  3   | expr₂       ;  8 | n       ; 12 | expr₂       ;  8*
expr₁ = 2n₁ + min [1, n₅ - 2]
expr₂ = 3n₁ + min [2, n₆ - 3]

donde n es el número total de unidades, n₁ es el número de unidades en los grupos RAID 1, y n₅ y n₆ son el número de grupos en las matrices RAID 5 o RAID 6 respectivamente. Los ejemplos se relacionan con el ejemplo de 12 unidades en la pregunta (las filas relevantes son ' *bolded*'); Ejemplos de niveles RAID 1 + 0, 1 + 5, 1 + 6 son 4 × 3, 6 × 2, 6 × 2 respectivamente.

Tenga en cuenta que solo el factor de amplificación de rendimiento de escritura de banda completa está directamente relacionado con la proporción de redundancia. Los casos de un solo fragmento son más complicados para aquellos con paridad. Surgen porque escribir un solo fragmento requiere leer el fragmento de paridad más fácil u otros fragmentos de datos, antes de escribir los fragmentos de paridad junto con el nuevo fragmento de datos. (No son directamente multiplicativos porque las lecturas inducidas deben multiplicarse por el respectivo rendimiento de lectura / factor de amplificación de búsqueda para RAID 1, siendo ambos 1; ver más abajo).

Desafortunadamente, elegir un tamaño de fragmento que minimice esta amplificación de rendimiento de escritura adicional tiene el efecto secundario de maximizarLa escritura busca amplificación. Para escrituras pequeñas con un tiempo de escritura insignificante en comparación con el tiempo de búsqueda, el rendimiento de escritura de la creación de bandas con un tamaño de fragmento muy pequeño (para ser una franja completa) es solo 1 ×, como la duplicación, ya que requiere que todas las unidades busquen los fragmentos para cada escritura y el rendimiento obtenido de la movilización de todas estas unidades es irrelevante. Ha dividido la proporción de tiempo de escritura para buscar el tiempo por el número de unidades en la matriz, pero para pequeñas escrituras esto ya era insignificante. No tendría sentido usar un tamaño de fragmento tan pequeño como para que incluso las escrituras pequeñas sean de banda completa. Para las escrituras lo suficientemente pequeñas como para sentir los efectos de la búsqueda, es mejor que encajen en un solo fragmento.

RAID | large contiguous write throughput    | concurrent tiny writes throughput
     | full-stripe    | single-chunk        | full-stripe | single-chunk
   0 | n×       ; 12× | n×          ; 12×   | 1×     ; 1× | n×          ; 12×
   1 | 1×       ;  1× | 1×          ;  1×   | 1×     ; 1× | 1×          ;  1×
   5 | (n - 1)× ; 11× | max[n/3, 1]×;  4×   | 1×     ; 1× | max[n/3, 1]×;  4×
   6 | (n - 2)× ; 10× | max[n/5, 1]×;  2.4× | 1×     ; 1× | max[n/5, 1]×;  2.4×
*1+0 | n₀×      ;  4× | n₀×         ;  4×   | 1×     ; 1× | n₀×         ;  4×  *
 1+5 | (n₅ - 1)×;  5× | expr₃×      ;  2.4× | 1×     ; 1× | expr₃×      ;  2.4×
*1+6 | (n₆ - 2)×;  4× | expr₄×      ;  1.5× | 1×     ; 1× | expr₄×      ;  1.5×*
expr₃ = n/(2n₁ + min [1, n₅ - 2]) = max [n/(2n₁ + 1), n/(2n₁ + n₅ - 2)]
expr₄ = n/(3n₁ + min [2, n₆ - 3]) = max [n/(3n₁ + 2), n/(3n₁ + n₆ - 3)]

Nota: Las columnas de rendimiento medio 2 pueden ignorarse dado un tamaño de fragmento sensible que es mayor que las escrituras para las cuales el tiempo de búsqueda es significativo, pero lo suficientemente pequeño como para que las escrituras grandes sean de banda completa. El gran tamaño de la segunda columna de rendimiento es más parecido a las unidades distribuidas. Una escritura 'pequeña' es donde el efecto del rendimiento es insignificante.

Tener un tamaño de fragmento incorrectamente pequeño también aumenta el efecto de la amplificación de búsqueda para las lecturas, aunque no tanto y solo en el caso de la franja completa.

RAID | read throughput amplification factor | read seek amplification factor
     | full-stripe      | single-chunk      | full-stripe (e.g.) | single-chunk
   0 | 1                | 1                 | n      to n;    12 | 1
   1 | 1                | 1                 | 1      to n;  1–12 | 1
   5 | 1                | 1                 | n - 1  to n; 11–12 | 1
   6 | 1                | 1                 | n - 2  to n; 10–12 | 1
*1+0 | 1                | 1                 | n₀     to n;  4–12 | 1           *
 1+5 | 1                | 1                 | n₅ - 1 to n;  5–12 | 1
*1+6 | 1                | 1                 | n₆ - 2 to n;  4–12 | 1           *

Nota: El 'a n' se debe a que cuando solo hay una lectura simultánea, es teóricamente posible movilizar todas las unidades para buscar lugares apropiados y leer colectivamente los datos para obtener el máximo rendimiento de lectura contigua.

RAID | large contiguous read throughput | concurrent tiny reads throughput
     | full-stripe (e.g.)| single-chunk | full-stripe         | single-chunk
   0 | n×          ; 12× | n×     ; 12× | 1×          ;  1×   | n×     ; 12×
   1 | n×          ; 12× | n×     ; 12× | n×          ; 12×   | n×     ; 12×
   5 | n×          ; 12× | n×     ; 12× | n/(n - 1)×  ; ~1.1× | n×     ; 12×
   6 | n×          ; 12× | n×     ; 12× | n/(n - 2)×  ;  1.2× | n×     ; 12×
*1+0 | n×          ; 12× | n×     ; 12× | n₁×         ;  3×   | n×     ; 12×*
 1+5 | n×          ; 12× | n×     ; 12× | n/(n₅ - 1)× ;  2.4× | n×     ; 12×
*1+6 | n×          ; 12× | n×     ; 12× | n/(n₆ - 2)× ;  3×   | n×     ; 12×*

Nota: Nuevamente, las 2 columnas de rendimiento medio pueden ignorarse dado un tamaño de fragmento sensible. La tercera columna de rendimiento vuelve a estar estrechamente relacionada con la proporción de redundancia.

Sin embargo, un tamaño de fragmento lo suficientemente grande significa que las lecturas pequeñas nunca tienen una franja completa. Entonces, dada una implementación eficiente y un tamaño de fragmento adecuado, el rendimiento de lectura debe ser proporcional al número de unidades idénticas cuando no se degrada.

Entonces, realmente, el 'factor de amplificación' es mucho más complicado que la fórmula en la pregunta, donde solo se había considerado la amplificación de rendimiento de banda completa. En particular, el rendimiento de escritura de 6 × 2 RAID 1 + 6 para escrituras concurrentes que son lo suficientemente pequeñas como para ser vinculadas a búsqueda será peor que el de 4 × 3 RAID 1 + 0. Y para pequeñas escrituras, que son todas buscadas, el rendimiento solo puede ser aproximadamente un tercio del de 4 × 3 RAID 1 + 0 en el mejor de los casos (es decir, dada una implementación perfecta).

Una vez aclarado ese problema, la comparación de 12 unidades no tiene un ganador absoluto:

                                  | 4×3 RAID 1+0 | 6×2 RAID 1+6
   number of identical 1TB drives | 12           | 12
                 storage capacity | 4TB          | 4TB
            redundancy proportion | 2/3          | 2/3
large contiguous write throughput | 4×           | 4×
 large contiguous read throughput | 12×          | 12×
concurrent tiny writes throughput |*4×           | 1.5×
 concurrent tiny reads throughput | 12×          | 12×
safe number of random drive loses | 2            |*5
    12 - 1 large write throughput | 4×           | 4×
     12 - 1 large read throughput | 8×           |*11×
    12 - 1 tiny writes throughput |*4×           | ~1.42×
     12 - 1 tiny reads throughput | 8×           |*~9.33×
  can split-off a copy for backup | yes[1]       | yes[1]
                  2-site failover | yes          | yes
    2-copy large write throughput | 4×           | 4×
     2-copy large read throughput |*8×           | 6×
    2-copy tiny writes throughput |*4×           | ~1.28×
     2-copy tiny reads throughput |*8×           | 6×
   2-copy safe random drive loses | 1            |*2
2-copy - 1 large write throughput | 4×           | 4×
 2-copy - 1 large read throughput | 4×           |*5× or 6×[2]
2-copy - 1 tiny writes throughput |*4×           | ~1.46× or 1.2×[2]
 2-copy - 1 tiny reads throughput | 4×           |*3.6x or 6×[2]
can be divided into 3 full copies | yes          | yes
                  3-site failover | yes          | yes
    1-copy large write throughput | 4×           | 4×
     1-copy large read throughput | 4×           | 4×
    1-copy tiny writes throughput |*4×           | ~0.85×
     1-copy tiny reads throughput |*4×           | 2×
   1-copy safe random drive loses | 0            | 0
                       complexity |*simple       | more complex

Nota 1: Una copia completa de los datos almacenados es, respectivamente, un RAID 0 cuádruple o una matriz RAID 6 degradada 4/6. Nota 2: Existe la posibilidad de que la falla de la unidad desconecte uno de los 4 pares RAID 1 degradados o degrade uno de los 2 pares normales.

Sin embargo, tendría el doble de rendimiento de lectura de una matriz RAID 6 de 6 unidades y el rendimiento de escritura minúsculo debería ser un 25% mejor (1.5 / 1.2) debido a que las lecturas requeridas se dividen entre los pares RAID 1, y RAID 6 obviamente lo hace tiene aplicaciones adecuadas, por lo que en aplicaciones de alta disponibilidad que tienen las escrituras más grandes o que están más preocupados por el rendimiento de lectura de rendimiento de escritura, tal vez no es un nicho para RAID 1 + 6 después de todo. Pero eso no es todo…

Complejidad

Hasta ahora, esto es solo en teoría (principalmente combinatoria ), en la práctica la complejidad significará que las implementaciones de RAID 1 + 6 pueden tener deficiencias que pierden oportunidades y no logran los resultados teóricos. RAID 6 ya es más complejo, y anidar agrega un poco más de complejidad además de esto.

Por ejemplo, no es obvio de inmediato que 6 × 2 RAID 1 + 6 se pueda abstraer con 3 cabezales de lectura virtuales independientes capaces de leer simultáneamente 3 lecturas grandes contiguas con un rendimiento de 4 × cada una, al igual que 4 × 3 RAID 1 + 0. Simplemente anidar 6 pares RAID 1 en una matriz RAID 6 usando un software RAID puede no ser tan elegante; la implementación puede ser estúpida y trepidante (todavía no he probado esta hipótesis).

La complejidad también presenta un mayor costo de desarrollo de implementaciones y herramientas. Aunque puede haber aplicaciones que podrían beneficiarse de tal anidamiento, las mejoras pueden no valer los costos de desarrollo.