Perché i livelli RAID nidificati 1 + 5 o 1 + 6 sono quasi inauditi? I livelli RAID nidificati nell'articolo Wikipedia mancano attualmente le loro sezioni. Non capisco perché non siano più comuni di RAID 1 + 0, soprattutto se confrontati con il triplo mirroring di RAID 1 + 0.

È evidente che il tempo di ricostruzione sta diventando sempre più problematico poiché le capacità del convertitore stanno aumentando più rapidamente delle loro prestazioni o affidabilità. Mi è stato detto che RAID 1 si ricostruisce più velocemente e che un array RAID 0 di coppie RAID 1 evita il problema, ma sicuramente lo sarebbe anche un array RAID 5 o 6 di coppie RAID 1. Almeno mi aspetto che siano un'alternativa comune a RAID 1 + 0.

Per 16 unità da 1 TB, ecco i miei calcoli della probabilità ingenua di ricorrere al backup, ovvero con l'ipotesi semplificativa che le unità siano indipendenti con probabilità pari:

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.)

Se questo è corretto, allora è abbastanza chiaro che RAID 1 + 6 è eccezionalmente più affidabile di RAID 1 + 0 per solo una riduzione del 25% della capacità di archiviazione. Come in generale, il throughput di scrittura teorico (senza contare i tempi di ricerca) è la capacità di archiviazione / dimensione dell'array × numero di unità × throughput di scrittura dell'unità più lenta dell'array (i livelli RAID con ridondanza hanno un'amplificazione di scrittura più elevata per le scritture che non riempire una striscia ma questo dipende dalle dimensioni del blocco) e la velocità di lettura teorica è la somma delle velocità di lettura delle unità nell'array (tranne che RAID 0, RAID 5 e RAID 6 possono ancora essere teoricamente limitati da il drive più lento, il 2o più lento e il 3o più lento leggono rispettivamente i throughput). Cioè, assumendo unità identiche, che sarebbe rispettivamente 8 ×, 7 ×,

Inoltre, considera un quadruplo RAID 0 di triple RAID 1, ovvero il triplo mirroring RAID 1 + 0 di 12 unità e un sestuple RAID 6 di coppie RAID 1, ovvero RAID 1 + 6 di 12 unità. Ancora una volta, si tratta di unità da 1 TB identiche. Entrambi i layout hanno lo stesso numero di unità (12), la stessa quantità di capacità di archiviazione (4 TB), la stessa proporzione di ridondanza (2/3), lo stesso throughput di scrittura massimo (4 ×) e lo stesso throughput di lettura massimo ( 12 ×). Ecco i miei calcoli (finora):

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ì, può sembrare eccessivo, ma laddove il triplo mirroring viene utilizzato per dividere un clone per il backup, RAID 1 + 6 può essere usato altrettanto bene, semplicemente congelando e rimuovendo 1 di ciascuna unità di tutte tranne 2 del RAID 1 coppia e, nel farlo, ha comunque un'affidabilità di gran lunga migliore se degradata rispetto all'array RAID 1 + 0 degradato. Ecco i miei calcoli per 12 unità degradate da 4 in questo modo:

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

La velocità di lettura, tuttavia, potrebbe essere ridotta a 6 × durante questo periodo per RAID 1 + 6, mentre RAID 1 + 0 è ridotto solo a 8 ×. Tuttavia, se un'unità si guasta mentre l'array si trova in questo stato degradato, l'array RAID 1 + 6 avrebbe una probabilità 50-50 di rimanere a circa 6 × o essere limitato ulteriormente a 5 ×, mentre l'array RAID 1 + 0 sarebbe essere limitato a un collo di bottiglia 4 × . La velocità di scrittura non dovrebbe essere influenzata (potrebbe anche aumentare se le unità prese per il backup fossero le unità più lente e limitanti).

In effetti, entrambi possono essere visti come un "triplo mirroring" perché l'array RAID 1 + 6 degradato è in grado di dividere un ulteriore gruppo RAID 6 di 4 unità. In altre parole, questo layout RAID 1 + 6 a 12 unità può essere diviso in 3 array RAID 6 degradati (ma funzionali)!

Quindi è solo che la maggior parte delle persone non ha approfondito la matematica in dettaglio? Vedremo più RAID 1 + 6 in futuro?

Generalmente direi che RAID 1 + 0 tenderà ad essere più ampiamente utilizzato di 1 + 5 o 1 + 6 perché RAID 1 + 0 è abbastanza affidabile e offre prestazioni leggermente migliori e spazio di archiviazione più utilizzabile.

Penso che la maggior parte delle persone considererebbe il fallimento di una coppia RAID 1 completa all'interno del gruppo RAID 1 + 0 come un evento incredibilmente raro per cui vale la pena eseguire il backup - e probabilmente non è troppo entusiasta di diventare sotto il 50% del proprio fisico disco come spazio utilizzabile.

Se hai bisogno di una migliore affidabilità rispetto a RAID 1 + 0, allora provaci! ..ma la maggior parte delle persone probabilmente non ne ha bisogno.

La risposta pratica sta da qualche parte all'intersezione tra le specifiche del controller RAID hardware, le dimensioni medie del disco, i fattori di forma dell'unità e la progettazione del server.

La maggior parte dei controller RAID hardware sono limitati nei livelli RAID che supportano. Ecco le opzioni RAID per un controller HP ProLiant Smart Array:

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

nota: "adm" è solo un triplo mirroring

Supporto controller RAID LSI: 0, 1, 5, 6, 10, 50, and 60

Quindi questi controller sono in grado di RAID 50 e 60 solo come livelli nidificati. LSI ( née Dell PERC ) e HP rappresentano la maggior parte del mercato degli adattatori di storage per server aziendali. Questo è il motivo principale per cui non vedi qualcosa come RAID 1 + 6 o RAID 61 sul campo.

Oltre a ciò, livelli RAID nidificati oltre a RAID 10 richiedono un numero relativamente elevato di dischi. Date le crescenti capacità di unità disponibili oggi (con unità SAS e SATA nearline da 3,5 "), insieme al fatto che molti chassis per server sono progettati attorno a gabbie da 8 x 2,5", non c'è molta possibilità di configurare fisicamente RAID 1+ 6 o RAID 61.

Le aree in cui potresti vedere qualcosa come RAID 1 + 6 sarebbero le soluzioni RAID software per chassis di grandi dimensioni. Linux MD RAID o ZFS ne sono sicuramente capaci. Ma a quel punto, il guasto dell'unità può essere mitigato da dischi hot o cold-spare. L'affidabilità RAID al giorno d'oggi non è un grosso problema, a condizione che si evitino combinazioni di livello RAID tossico e hardware (ad es. Dischi RAID 5 e 6 TB). Inoltre, le prestazioni di lettura e scrittura verrebbero astratte dai livelli di tiering e cache. I carichi di lavoro di archiviazione medi in genere beneficiano dell'uno o dell'altro.

Quindi, alla fine, sembra che il bisogno / domanda non sia proprio lì.

• Hai rendimenti decrescenti sull'affidabilità. È improbabile che RAID 6 comporti un errore anche in unità SATA brutte con una velocità UBER 1 su 10 ^ 14. Su unità FC / SAS il tuo UBER è 1 su 10 ^ 16 e ottieni anche prestazioni notevolmente maggiori.

• L'affidabilità del gruppo RAID non ti protegge dalla cancellazione accidentale. (quindi hai comunque bisogno dei backup)

• oltre determinati livelli di RAID, le probabilità di un errore composto sui dischi diventano inferiori al guasto composto dell'infrastruttura di supporto (alimentazione, rete, perdita di aria condizionata, ecc.)

• Scrivi penalità. Ogni scrittura in arrivo sul tuo RAID 61 attiverà 12 operazioni IO (eseguite in modo ingenuo). RAID 6 è già doloroso in scenari di "livello basso" in termini di IOP per TB di scrittura casuale. (e al livello superiore, il tuo tasso di fallimento è comunque 100 volte migliore)

• non è una "riduzione del 25%", è un'ulteriore riduzione del 25%. Il tuo 16 TB si sta trasformando in 6 TB. In questo modo otterrai il 37,5% di spazio di archiviazione utilizzabile. Sono necessari 3 volte il numero di dischi per capacità e 3 volte lo spazio del datacenter. Probabilmente otterresti maggiore affidabilità semplicemente realizzando set RAID6 più piccoli. Non ho fatto il crunching dei numeri, ma provo - ad esempio le somme di RAID 6 in set 3x 3 + 2 (15 unità, un overhead di archiviazione inferiore rispetto al RAID10). O invece fare specchi a 3 vie.

Detto questo, è più comune di quanto si pensi per farlo con DR multi-sito. Eseguo array di archiviazione replicati in cui ho gruppi RAID5 / 6 / DP RAID in modo asincrono o sincrono su un sito DR. (Non sincronizzare se è possibile evitarlo - sembra buono, in realtà è orribile).

Con i miei NetApps, questo è un metrocluster con alcuni aggregati speculari. Con i miei VMAX abbiamo Symmetrix Remote Data Facility (SRDF). E i miei 3PAR eseguono la copia remota.

È costoso, ma fornisce livelli di DR "data center che prendono fuoco".

Per quanto riguarda i mirror tripli: li ho usati, ma non come misure dirette di resilienza RAID, ma piuttosto come cloni completi come parte di una strategia di backup. Sincronizza un terzo mirror, suddividilo, montalo su un server separato ed esegui il backup utilizzando un'infrastruttura completamente diversa. E a volte ruotare il terzo mirror come opzione di ripristino.

Il punto che sto cercando di sottolineare è che nella mia esperienza diretta come amministratore di archiviazione - in una proprietà di circa 40.000 mandrini (sì, stiamo sostituendo decine di unità ogni giorno) - abbiamo dovuto andare ai backup per una varietà di motivi negli ultimi 5 anni, ma nessuno di questi è stato un fallimento del gruppo RAID. Discutiamo i relativi meriti e tempi di recupero accettabili, punto di ripristino e finestre di interruzione. E alla base di tutto ciò c'è SEMPRE il costo della resilienza extra.

Il nostro array predice tutti gli errori di pulizia e guasti dei supporti, risparmiando e testando in modo aggressivo.

Anche se ci fosse un'implementazione RAID adatta, il rapporto costi-benefici non esiste. I soldi spesi per lo spazio di archiviazione sarebbero meglio investiti in una conservazione più lunga o in un ciclo di backup più frequente. O comunicazioni più veloci. O semplicemente mandrini generalmente più veloci, perché anche con numeri di resilienza identici, la ricostruzione più rapida dei ricambi migliora la probabilità di fallimento del composto.

Quindi penso che offrirei quindi la risposta alla tua domanda:

Non vedi RAID 1 + 6 e 1 + 5 molto spesso, perché il vantaggio in termini di costi semplicemente non si accumula. Data una quantità limitata di denaro e in primo luogo la necessità di implementare una soluzione di backup, tutto ciò che stai facendo è spendere soldi per ridurre la frequenza delle interruzioni. Ci sono modi migliori per spendere quei soldi.

I sistemi moderni e avanzati non implementano forme del genere perché sono eccessivamente complicati, completamente inutili e contrari a qualsiasi parvenza di efficienza.

Come altri hanno sottolineato, il rapporto tra spazio grezzo e spazio utilizzabile è essenzialmente 3: 1. Si tratta essenzialmente di tre copie (due copie ridondanti). A causa del costo di calcolo di "raid6" (due volte, se rispecchiato) e della conseguente perdita di IOPS, questo è molto inefficiente. In ZFS, che è molto ben progettato e messo a punto, la soluzione equivalente, per quanto riguarda la capacità, sarebbe quella di creare una striscia di specchi a 3 vie.

Ad esempio, invece di un mirror di forme raid6 / raidz2 a 6 vie (12 unità in totale), che sarebbe molto inefficiente (anche se ZFS non ha alcun meccanismo da implementare), avresti mirror 4x a 3 vie (anche 12 unità). E invece di 1 unità IOPS, avresti 4 unità IOPS. Soprattutto con le macchine virtuali, questa è una grande differenza. La larghezza di banda totale per le due forme può essere molto simile nelle letture / scritture sequenziali, ma la striscia di specchi a 3 vie sarebbe sicuramente più reattiva con la lettura / scrittura casuale.

Per riassumere: raid1 + 6 è in genere poco pratico, inefficiente e non sorprende che nulla di seriamente considerato dallo storage venga preso in considerazione.

Per chiarire la disparità IOPS: con uno specchio di forme raid6 / raidz2, con ogni scrittura, tutte e 12 le unità devono agire come una. Non è possibile per la forma totale suddividere l'attività in più azioni che più forme possono eseguire in modo indipendente. Con una striscia di specchi a 3 vie, ogni scrittura può essere qualcosa che solo uno dei 4 specchi deve affrontare, quindi un'altra scrittura che arriva non deve aspettare che l'intera forma dell'omnibus debba affrontare prima di guardare ulteriori azioni .

Dal momento che nessuno l'ha detto abbastanza direttamente: le prestazioni di scrittura di Raid6 non sono leggermente peggiori. È orribile oltre ogni descrizione se messo sotto carico.

La scrittura sequenziale è OK e fintanto che la memorizzazione nella cache, la scrittura unita ecc. È in grado di coprirla, sembra ok. Sotto carico elevato, le cose sembrano andare male e questo è il motivo principale per cui una configurazione 1 + 5/6 non viene quasi mai utilizzata.

Cerca tempi

Il problema è che l' amplificazione della ricerca in scrittura si comporta in modo molto diverso dall'amplificazione della velocità di scrittura . L'amplificazione minima del throughput di scrittura con parità si verifica quando un'intera riga viene scritta contemporaneamente (chiamiamo questo aggettivo "full-stripe"), tuttavia l'amplificazione minima della ricerca in scrittura si verifica, al contrario, quando l'intera scrittura che segue una ricerca nel dispositivo virtuale si adatta un singolo pezzo. Prima di entrare nei dettagli, le relazioni sono molto più facili da comunicare in forma tabellare:

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]

dove n è il numero totale di unità, n₁ è il numero di unità nei gruppi RAID 1 e n₅ e n₆ sono il numero di gruppi rispettivamente negli array RAID 5 o RAID 6. Gli esempi si riferiscono all'esempio di 12 unità nella domanda (le righe pertinenti sono ' *bolded*'); esempi per i livelli RAID 1 + 0, 1 + 5, 1 + 6 sono rispettivamente 4 × 3, 6 × 2, 6 × 2.

Si noti che solo il fattore di amplificazione del throughput di scrittura a banda intera è direttamente correlato alla percentuale di ridondanza. I casi a pezzo singolo sono più complicati per quelli con parità. Si presentano perché la scrittura di un singolo blocco richiede la lettura di qualsiasi blocco di parità più semplice o degli altri blocchi di dati, prima di scrivere i blocchi di parità insieme al nuovo blocco di dati. (Non sono direttamente moltiplicativi perché le letture indotte devono invece essere moltiplicate per il rispettivo throughput di lettura / fattore di amplificazione di ricerca per RAID 1, essendo entrambi 1; vedere di seguito.)

Sfortunatamente, la scelta di una dimensione del blocco che minimizza questa ulteriore amplificazione del throughput di scrittura ha l'effetto collaterale di massimizzare effettivamentela scrittura cerca l'amplificazione. Per le scritture minuscole con un tempo di scrittura trascurabile rispetto al tempo di ricerca, le prestazioni di scrittura dello striping con una dimensione del blocco molto piccola (per essere full-stripe) sono solo 1 ×, come il mirroring, in quanto richiedono tutte le unità i blocchi per ogni scrittura e il rendimento ottenuto dalla mobilitazione di tutte queste unità sono irrilevanti. Ha diviso il rapporto tra tempo di scrittura e tempo di ricerca per il numero di unità nell'array, ma per le scritture minuscole questo era già trascurabile. Non avrebbe senso usare una pezzatura così piccola da rendere a strisce piene anche le piccole scritture. Per le scritture abbastanza piccole da sentire gli effetti della ricerca, è meglio che si inseriscano in un singolo blocco.

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: le 2 colonne di throughput intermedie possono essere ignorate, data una dimensione sensibile del blocco che è maggiore delle scritture per le quali il tempo di ricerca è significativo, ma abbastanza piccolo da consentire che le scritture di grandi dimensioni siano a strisce complete. Le grandi dimensioni del blocco della seconda colonna di throughput sono più simili alle unità con spanning. Una scrittura "minuscola" è dove l'effetto del throughput è trascurabile.

Avere una dimensione del blocco in modo inappropriato aumenta anche l'effetto dell'amplificazione della ricerca per le letture, anche se non tanto e solo nel caso della banda intera.

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: "to n" è perché quando si verifica contemporaneamente una sola lettura, è teoricamente possibile mobilitare tutte le unità per cercare luoghi appropriati e leggere collettivamente i dati per ottenere una velocità di lettura contigua massima.

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: anche in questo caso, è possibile ignorare le 2 colonne di throughput intermedie, data una dimensione sensibile del blocco. La terza colonna di throughput è di nuovo strettamente collegata alla percentuale di ridondanza.

Tuttavia, una dimensione del blocco abbastanza grande significa che le letture minuscole non sono mai a banda intera. Pertanto, data un'implementazione efficiente e le dimensioni appropriate del blocco, le prestazioni di lettura dovrebbero essere proporzionali al numero di unità identiche quando non vengono degradate.

Quindi, in realtà, il "fattore di amplificazione" è molto più complicato della formula nella domanda, in cui era stata presa in considerazione solo l'amplificazione del throughput a banda intera. In particolare, le prestazioni di scrittura di 6 × 2 RAID 1 + 6 per le scritture simultanee che sono abbastanza piccole da essere associate alla ricerca saranno peggiori di quelle di RAID 1 + 0 4 × 3. E per le scritture minuscole, che sono tutte ricercate, le prestazioni possono essere solo circa un terzo di quelle di 4 × 3 RAID 1 + 0 nella migliore delle ipotesi (cioè date un'implementazione perfetta).

Dopo aver risolto il problema, il confronto di 12 unità non ha un vincitore assoluto:

                                  | 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 dei dati memorizzati è rispettivamente un quadruplo RAID 0 o un array RAID 6 degradato 4/6. Nota 2: esiste anche la possibilità che il guasto dell'unità disattivi una delle 4 coppie RAID 1 degradate o degrada una delle 2 coppie normali.

Tuttavia, avrebbe il doppio delle prestazioni di lettura di un array RAID 6 di 6 unità e il throughput di piccole scritture dovrebbe essere migliore del 25% (1,5 / 1,2) a causa della suddivisione delle letture richieste tra le coppie RAID 1, e RAID 6 ovviamente lo fa hanno applicazioni adatte, quindi in applicazioni ad alta disponibilità che hanno le scritture più grandi o che sono più preoccupato per le prestazioni in lettura di prestazioni in scrittura, forse c'è è una nicchia per RAID 1 + 6 dopotutto. Ma non è tutto ...

Complessità

Questo è ancora solo in teoria fino ad ora (principalmente combinatoria ), in pratica la complessità significherà che le implementazioni di RAID 1 + 6 possono avere carenze che mancano opportunità e non raggiungono i risultati teorici. RAID 6 è già più complesso e la nidificazione aggiunge un po 'più di complessità a questo.

Ad esempio, non è immediatamente ovvio che 6 × 2 RAID 1 + 6 può essere estratto in modo da avere 3 testine di lettura virtuali indipendenti in grado di leggere simultaneamente 3 letture contigue di grandi dimensioni a 4 × throughput ciascuna, proprio come 4 × 3 RAID 1 + 0. La semplice nidificazione di 6 coppie RAID 1 in un array RAID 6 utilizzando un software RAID potrebbe non essere così elegante; l'implementazione può essere stupida e thrash (non ho ancora verificato questa ipotesi).

La complessità presenta anche un aumento dei costi di sviluppo di implementazioni e strumenti. Anche se potrebbero esserci applicazioni che potrebbero beneficiare di tale annidamento, i miglioramenti potrebbero non valere i costi di sviluppo.