RAID 1 + 6がより一般的なレイアウトではないのはなぜですか？
ネストされたRAIDレベル1 + 5または1 + 6がほとんど前例がないのはなぜですか？ ネストされたRAIDレベルのWikipediaの記事 には現在セクションがありません。特にRAID 1 + 0トリプルミラーリングと比較すると、なぜそれらがRAID 1 + 0より一般的ではないのか理解できません。
ドライブの容量がパフォーマンスや信頼性よりも速く増加しているため、再構築時間はますます問題になっていることは明らかです。 RAID 1はより速く再構築され、RAID 1ペアのRAID 0アレイは問題を回避すると言われていますが、RAID 5または6アレイのRAID 1ペアは確実にそうです。私は少なくともそれらがRAID 1 + 0の一般的な代替品になると期待しています。
1 TBのドライブのうち16台について、バックアップに頼るナイーブな確率の計算を以下に示します。つまり、ドライブが偶数の確率で独立しているという単純化した仮定を使用しています。
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.)
これが正しければ、RAID 1 + 6の方がRAID 1 + 0よりも非常に信頼性が高く、ストレージ容量が25％しか減少しないことは明らかです。一般的にそうであるように、理論的な書き込みスループット（シーク時間は含まない）は、ストレージ容量/アレイサイズ×ドライブ数×アレイ内の最も遅いドライブの書き込みスループットです（冗長性のあるRAIDレベルでは、書き込みの書き込み増幅が高くなります）ストライプを埋めないでくださいが、これはチャンクサイズによって異なります）。理論上の読み取りスループットは、アレイ内のドライブの読み取りスループットの合計です（ただし、RAID 0、RAID 5、およびRAID 6は、理論的には最も遅いドライブ、2番目に遅いドライブ、3番目に遅いドライブの読み取りスループット。つまり、同一のドライブを想定すると、最大書き込みスループットはそれぞれ8倍、7倍、または6倍、最大読み取りスループットは16倍になります。
さらに、RAID 1トリプルのRAID 0 quadruple 、つまり12台のドライブのRAID 1 + 0トリプルミラーリング、およびRAID 1ペアのRAID 6の6つ組、つまり12台のドライブのRAID 1 + 6について考えます。繰り返しますが、これらは同一の1TBドライブです。両方のレイアウトは、同じドライブ数（12）、同じ量のストレージ容量（4TB）、同じ割合の冗長性（2/3）、同じ最大書き込みスループット（4x）、および同じ最大読み取りスループット（ 12×）。これが私の計算です（これまでのところ）：
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
はい、これはやり過ぎのように見えるかもしれませんが、トリプルミラーリングを使用してバックアップのクローンを分割する場合、RAID 1 + 6は、RAIDの2つを除くすべてのドライブの1つをフリーズして削除するだけで、同様に使用できます。 1ペアであり、その際、劣化したRAID 1 + 0アレイよりも劣化した場合の信頼性ははるかに優れています。これは、この方法で4台まで低下した12台のドライブの計算です。
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
ただし、RAID 1 + 6の場合、この間に読み取りスループットは6倍に低下する可能性がありますが、RAID 1 + 0は8倍にしか低下しません。それでも、アレイがこの機能低下状態のときにドライブに障害が発生した場合、RAID 1 + 6アレイは50〜50の確率で約6倍にとどまるか、5倍に制限されますが、RAID 1 + 0アレイは4×ボトルネックに制限されます。書き込みスループットはかなり影響を受けないはずです（バックアップのために取得されたドライブが最も遅いドライブを制限していた場合でも、増加する可能性があります）。
実際、劣化したRAID 1 + 6アレイは4つのドライブの追加のRAID 6グループを分割できるため、どちらも「トリプルミラーリング」と見なすことができます。つまり、この12ドライブのRAID 1 + 6レイアウトは、3つの機能が低下した（ただし機能している）RAID 6アレイに分割できます。
それで、ほとんどの人が数学に詳しく入っていないだけなのでしょうか？将来、より多くのRAID 1 + 6が見られるでしょうか？
一般に、RAID 1 + 0は十分に信頼できるであり、パフォーマンスがわずかに向上し、ストレージがより使いやすくなるため、RAID 1 + 0は1 + 5または1 + 6よりも広く使用される傾向があると思います。
ほとんどの人は、RAID 1 + 0グループ内の完全なRAID 1ペアの障害を、非常にまれなイベントであると考えています。これは、バックアップを作成する価値はあります。おそらく、物理の50％未満にはあまり熱心ではありません。使用可能なスペースとしてのディスク。
RAID 1 + 0よりも優れた信頼性が必要な場合は、ぜひお試しください。 ..しかし、ほとんどの人はおそらくそれを必要としないでしょう。
実際の答えは、ハードウェアRAIDコントローラーの仕様、平均ディスクサイズ、ドライブフォームファクター、サーバー設計の交差点にあります。
ほとんどのハードウェアRAIDコントローラーは、サポートするRAIDレベルに制限があります。 HP ProLiant SmartアレイコントローラーのRAIDオプションは次のとおりです。
[raid=0|1|1adm|1+0|1+0adm|5|50|6|60]
注：「adm」はトリプルミラーリングです
LSI RAIDコントローラのサポート：0, 1, 5, 6, 10, 50, and 60
したがって、これらのコントローラーはネストされたレベルとしてRAID 50および60のみに対応します。 LSI（néeDell PERC）とHPは、エンタープライズサーバーストレージアダプター市場のほとんどを占めています。それがRAID 1 + 6やRAID 61のようなものがフィールドに表示されない主な理由です。
その考慮事項を超えて、RAID 10を超えるネストされたRAIDレベルには、比較的多数のディスクが必要です。現在利用可能なドライブ容量の増加（3.5 "ニアラインSASおよびSATAドライブ）と、多くのサーバーシャーシが8 x 2.5"ドライブケージを中心に設計されているという事実を考慮すると、それほど多くありません。 RAID 1 + 6、またはRAID 61を物理的に構成する機会の。
RAID 1 + 6のようなものが表示される領域は、大規模なシャーシソフトウェアRAIDソリューションです。 Linux MD RAIDまたはZFSは確実にそれを実行できます。しかし、その時までに、ドライブ障害はホットまたはコールドスペアディスクによって軽減できます。有毒なRAIDレベルとハードウェアの組み合わせ（RAID 5と6TBディスクなど）を避ければ、最近のRAIDの信頼性はそれほど問題ではありません。さらに、読み取りと書き込みのパフォーマンスは、階層化とキャッシングレイヤーによって抽象化されます。通常、平均的なストレージワークロードは、どちらか一方の恩恵を受けます。
結局のところ、必要性/要求がまったくないように見えます。
信頼性に対する収益が減少します。 RAID 6は、1/10 ^ 14 UBERレートの厄介なSATAドライブでも、障害が複合化する可能性はほとんどありません。 FC/SASドライブでは、UBERは10 ^ 16分の1であり、パフォーマンスも大幅に向上します。
RAIDグループの信頼性は、偶発的な削除から保護するものではありません。 （とにかくバックアップが必要です）
rAIDingの特定のレベルを超えると、ディスクの複合障害の確率は、サポートするインフラストラクチャ（電源、ネットワーク、エアコンリークなど）の複合障害よりも低くなります。
ペナルティを書きます。 RAID 61への受信書き込みごとに、12のIO操作がトリガーされます（単純に行われます）。 RAID 6は、TBランダム書き込みあたりのIOPに関して、「低階層」シナリオではすでに苦痛です。 （そしてより高い層では、失敗率はとにかく100倍優れています）
「25％削減」ではありませんさらに 25％削減です。 16 TBは6 TBに変わります。つまり、37.5％の使用可能なストレージが得られます。容量ごとに3倍のディスクと、3倍のデータセンタースペースが必要です。おそらく、より小さなRAID6セットを作成するだけで、より高い信頼性が得られます。私は数値を計算していませんが、試してみてください-たとえば、3x 3 + 2セットのRAID 6の合計（15ドライブ、RAID10よりも少ないストレージオーバーヘッド）。または、代わりに3方向ミラーを実行します。
そうは言っても、マルチサイトDRの場合よりも一般的です。 RAID 5/6/DP RAIDグループがDRサイトに非同期または同期である複製ストレージアレイを実行しています。 （回避できる可能性がある場合は同期しないでください。見た目はよく、実際には恐ろしいです）。
私のNetAppsでは、これはいくつかのミラーリングされたアグリゲートを持つメトロクラスターです。私のVMAXには、Symmetrix Remote Data Facility（SRDF）があります。そして、私の3PARはリモートコピーを行います。
それは高価ですが、DRの「データセンターキャッチファイア」レベルを提供します。
トリプルミラーについて-私はそれらを使用しましたが、直接のRAID回復力の対策としてではなく、バックアップ戦略の一部としてフルクローンとして使用しました。 3番目のミラーを同期して分割し、別のサーバーにマウントして、まったく異なるインフラストラクチャを使用してバックアップします。また、リカバリオプションとして3番目のミラーを回転させることもあります。
私がしようとしている点は、ストレージ管理者としての直接的な経験-約40,000のスピンドル領域で（はい、毎日数十台のドライブを交換しています）-さまざまなバックアップのために過去5年間に理由がありますが、RAIDグループの障害ではありません。私たちは、相対的なメリットと許容可能な回復時間、回復ポイント、および停止ウィンドウについて議論します。そして、これらすべてを支えるのは、常に、追加の回復力のコストです。
私たちのアレイはすべてのメディアスクラブと障害を予測し、積極的にドライブのスペアとテストを行います。
適切なRAID実装があったとしても、費用対効果はそこにはありません。ストレージスペースに費やされたお金は、より長い保存期間またはより頻繁なバックアップサイクルに投資するほうがよいでしょう。またはより速いコミュニケーション。または、通常はより高速なスピンドルです。復元力の数値が同じであっても、スペアのより迅速な再構築により、複合故障の確率が向上します。
だから私はあなたの質問に対する答えを提供すると思います：
RAID 1 + 6と1 + 5はあまり見られません。コスト面でのメリットが積み重なっていないためです。有限の金額があり、そもそもバックアップソリューションを実装する必要がある場合、停止している頻度を減らすためにお金を費やすだけです。そのお金を使うより良い方法があります。
最近のシステムと高度なシステムは、そのような形状を実装していません。なぜなら、それらは非常に複雑で、完全に不要であり、効率の類似性に反するからです。
他の人が指摘したように、未使用スペースと使用可能なスペースの比率は基本的に3：1です。これは基本的に3つのコピー（2つの冗長コピー）です。 「raid6」の計算コスト（ミラー化されている場合は2倍）、およびIOPSの損失により、これは非常に非効率的です。非常に適切に設計および調整されているZFSでは、同等のソリューションとして、容量面で3面ミラーのストライプを作成します。
例として、6ウェイraid6/raidz2シェイプ（合計12ドライブ）のミラーではなく、これは非常に非効率的です（これもZFSが実装するメカニズムを持っていないものです）、4x 3ウェイミラー（また12ドライブ）があります。ドライブ）。また、1ドライブに相当するIOPSの代わりに、4ドライブに相当するIOPSがあります。特に仮想マシンでは、それは大きな違いです。 2つの形状の合計帯域幅は、シーケンシャルな読み取り/書き込みで非常に似ている可能性がありますが、3方向ミラーのストライプは、ランダムな読み取り/書き込みで確実に応答性が高くなります。
要約すると、raid1 + 6は一般に非実用的で非効率的であり、当然のことながら、ストレージについて真剣に考える人が開発を検討することはありません。
IOPSの違いを明確にするには：raid6/raidz2シェイプのミラーを使用して、書き込みごとに、12台のドライブすべてが1つのドライブとして機能する必要があります。シェイプ全体がアクティビティを複数のアクションに分割して、複数のシェイプが独立して実行できる機能はありません。 3ウェイミラーのストライプでは、各書き込みは4つのミラーの1つだけが処理する必要がある場合があるため、別の書き込みは、オムニバス全体が処理されるのを待たずに次のアクションを確認する必要があります。 。
誰もそれを直接十分に言っていないので、Raid6書き込みパフォーマンスはわずかに悪くはありません。負荷をかけると説明以上に恐ろしい。
シーケンシャルな書き込みは問題なく、キャッシング、書き込みマージなどがそれをカバーできる限り、問題はありません。高負荷では状況が悪く見え、これが1 + 5/6設定がほとんど使用されない主な理由です。
時間を求める
問題は、書き込みseek増幅の動作が書き込みthroughput増幅と大きく異なることです。パリティ付きの最小書き込みスループットの増加は、ストライプ全体が一度に書き込まれるときに発生します（この形容詞を「フルストライプ」と呼びましょう）が、逆に、仮想デバイスでのシークに続く書き込み全体が収まるときに、最小書き込みシークの増加が発生します単一のチャンク。詳細に入る前に、関係は表形式で伝達する方がはるかに簡単です。
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]
nはドライブの総数、n₁はRAID 1グループのドライブ数、n numberとn₅はそれぞれRAID 5またはRAID 6アレイのグループ数です。例は、質問の12ドライブの例に関連しています（関連する行は ‘*bolded* '）; RAIDレベル1 + 0、1 + 5、1 + 6の例は、それぞれ4×3、6×2、6×2です。
フルストライプの書き込みスループット増幅率のみが、冗長性の比率に直接関係していることに注意してください。シングルチャンクのケースは、パリティのあるケースではより複雑です。それらは、新しいデータチャンクと共にパリティチャンクを書き込む前に、パリティチャンクまたは他のデータチャンクの最も簡単な方を読み取る必要があるために発生します。 （誘発された読み取りは、代わりにRAID 1のそれぞれの読み取りスループット/シーク増幅係数で乗算する必要があるため、これらは直接乗算ではありません。どちらも1です。以下を参照してください。）
残念ながら、この余分な書き込みスループットの増幅を最小限に抑えるチャンクサイズを選択すると、実際に書き込みシークの増幅が最大化するという副作用があります。シーク時間と比較して無視できる書き込み時間の小さな書き込みの場合、非常に小さなチャンクサイズ（フルストライプになる）のストライピングの書き込みパフォーマンスは、ミラーリングと同様に1倍です。各書き込みのチャンクと、これらすべてのドライブのモバイル化によって得られたスループットは関係ありません。シーク時間に対する書き込み時間の比率をアレイ内のドライブ数で割ったものですが、小さな書き込みの場合、これはすでに無視できます。小さな書き込みでさえ完全なストライプになるほど小さいチャンクサイズを使用しても意味がありません。シークの影響を感じるのに十分小さい書き込みの場合は、単一のチャンク内に収まるようにするのが最善です。
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)]
注：中間の2つのスループット列は、シーク時間が重要な書き込みよりも大きいが、大きな書き込みが完全なストライプになるほど十分に小さい書き込みチャンクサイズを指定すると無視できます。 2番目のスループット列のチャンクサイズが大きいことは、スパンドライブに似ています。 「小さな」書き込みでは、スループットの影響は無視できます。
チャンクサイズが不適切に小さいと、読み取りのシーク増幅の影響も大きくなりますが、フルストライプの場合ほどではありません。
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 *
注： 'to n'は、同時に発生する読み取りが1つしかない場合、理論的にはすべてのドライブを動員して適切な場所にシークし、データをまとめて読み取って、最大の連続読み取りスループットを最大化できるためです。
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×*
注：賢明なチャンクサイズを指定すると、中央の2つのスループット列は無視できます。 3番目のスループットの列も、冗長性の比率に密接に関連しています。
ただし、チャンクサイズが十分に大きい場合、小さな読み取りが完全なストライプになることはありません。したがって、効率的な実装と適切なチャンクサイズを考えると、読み取りパフォーマンスは、低下していない場合、同一のドライブの数に比例するはずです。
したがって、実際には、「増幅率」は、フルストライプスループットの増幅のみが考慮されていた問題の公式よりもはるかに複雑です。 特に、シークバウンドになるほど小さい同時書き込みの6×2 RAID 1 + 6の書き込みパフォーマンスは、4×3 RAID 1 + 0のパフォーマンスよりも低くなります。そして、すべてがシークである小さな書き込みの場合、パフォーマンスは4×3 RAID 1 + 0の約3分の1にすぎません（つまり、完全な実装が与えられている場合）。
この問題を解決したため、12ドライブの比較では完全な勝者はありません。
| 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
注1：保存されたデータの完全なコピーは、それぞれRAID 0クワッド、または4/6縮退RAID 6アレイです。注2：ドライブの障害により、4つの低下したRAID 1ペアの1つがオフラインになるか、2つの通常のペアの1つが低下するかについては、偶然の可能性があります。
それでも、6ドライブのRAID 6アレイの読み取りパフォーマンスは2倍になり、必要な読み取りがRAID 1ペア間で分割されるため、小さな書き込みスループットは25％向上するはずです（1.5/1.2）。RAID6は明らかに適切なアプリケーションがあるため、書き込みが大きい、または書き込みパフォーマンスよりも読み取りパフォーマンスを重視する高可用性アプリケーションでは、おそらくRAID 1 + 6のニッチがニッチです。 しかし、それだけではありません…
複雑
これは、これまでのところ理論的にはほとんど（ほとんど combinatorics ）ですが、実際には複雑であるため、RAID 1 + 6の実装には、機会を逃し、理論的な結果を達成できない欠陥がある可能性があります。 RAID 6はすでにより複雑であり、入れ子にするとさらに複雑になります。
たとえば、6×2 RAID 1 + 6が、4×3 RAID 1 + 0のように、それぞれ4×スループットで3つの連続した大きな読み取りを同時に読み取ることができる3つの独立した仮想読み取りヘッドを持つように抽象化できることはすぐにはわかりません。ソフトウェアRAIDを使用してRAID 6アレイに6つのRAID 1ペアを単にネストするだけでは、それほど洗練されていない場合があります。実装は愚かでスラッシュかもしれません（私はまだこの仮説をテストしていません）。
複雑さのために、実装とツールの開発コストも増加します。そのような入れ子の恩恵を受けることができるアプリケーションがあるかもしれませんが、改善は開発コストの価値がないかもしれません。