サーバーにはどのRAIDレベルを選ぶべきですか？

01

最初にリカバリ要件を書く

障害モデルを平易な言葉で定義してください：1台のデバイス、2台のデバイス、コントローラー、誤削除、またはサーバー全体。RAIDは一部のデバイス障害のみに対処します。サービス復旧の目標時間とデータ損失の目標時点を設定し、ローカルアレイがどの要件を満たせるか、どの要件に他の場所でのレプリケーションまたはバックアップが必要かを特定してください。

また、システムが劣化状態でも書き込みを受け付け続ける必要があるかどうかを記録してください。読み取り中心のアーカイブ、書き込みの多いデータベース、使い捨てのスクラッチスペースは、同じ数のドライブを使用しても異なるレイアウトが必要になる場合があります。したがって、容量効率は1つの制約であり、最終的な判断ではありません。

02

レイアウトをワークロードとデバイス数に合わせる

ミラーは2デバイスのブートまたはデータセットに簡単で、独立したミラーグループが有用なランダムI/Oに適しています。パリティレイアウトは、書き込み作業と再構築の複雑さを容量と交換します。ダブルパリティは広いHDDセットで追加の障害マージンを保持でき、RAID 10は生容量の半分をミラーペアと交換します。これらは設計傾向であり、パフォーマンス保証ではありません。コントローラ、ファイルシステム、キューの深さ、レコードサイズ、アプリケーションパターンがすべて重要です。

実際のカタログトポロジーを使用してください。12ドライブと24ドライブのストレージサーバーでは、2台のNVMeコンピュートサーバーでは利用できない選択肢があります。個別のNVMeブートペアをデータアレイの計算に含めないでください。また、障害ドメインとI/O動作をモデル化せずに、1つの非常に広いグループが複数のグループよりも好ましいと想定しないでください。

03

冗長性を所有するレイヤーを1つ選択する

ハードウェアコントローラ、Linux MD、または ZFS などのファイルシステムのどれがレイアウトを所有するかを決定してください。文書化された理由なしに独立した RAID レイヤーを重ねるのは避けてください。健全性と交換状態が曖昧になる可能性があります。ZFS 冗長性はミラーまたは RAIDZ vdev を通じて表現され、チェックサムに依存します。トップレベル vdev を失うとプールを失う可能性があるため、冗長性のあるプールに単一の非冗長デバイスを追加すると障害モデルが変わります。

アレイを作成する前に、ドライブの識別、交換手順、ブート動作、オペレーティングシステムが観察できるものを確認してください。後でトポロジを変更すると、特にパリティレイアウトでは制約が生じたり混乱を招いたりする可能性があります。

• OpenZFS vdev構造 ↗

04

劣化および再構築ウィンドウを計画する

監視では、正常、劣化、再構築、整合性チェックの状態を区別する必要があります。Linux MDは、resync、recover、check、repairなどのアクションを公開します。ボリュームがマウントされていることだけを報告するのではなく、進行状況と不一致を収集してください。ダーティで劣化したRAID 5または6は破損リスクをもたらす可能性があるため、強制アセンブリを日常的なリカバリのショートカットにしてはいけません。

アラートのルーティング、スペアの調達、交換品の特定、ワークロードのスロットリング、復元の方が継続よりも安全な時点を文書化してください。納品されたデバイス、アレイの負荷、コントローラを測定せずに再構築時間を約束しないでください。

05

選択とその制限を記録する

完成した設計では、レイアウト、同一ドライブの前提、使用可能容量の見積もり、許容される障害、監視ソース、復元場所を明記する必要があります。バージョン管理されたデータを別の障害ドメインに保持し、復元をテストします。期待される結果は、RAIDが損失を防ぐという主張ではなく、本番データが到着する前に障害動作とリカバリ責任が理解されているアレイです。