私は過去3日間のRAIDレベルを調べてきました。そして、RAIDコントローラーのハードウェア/ソフトウェアの長所/短所を検討してきました。 RAIDはバックアップソリューションではないことを理解しており、1つの質問が残っていますが、完全に問題ありません。
RAIDコントローラーは、RAID1からRAID6でさえ、ハードディスクドライブに障害が発生していることを実際にどのように検出しますか。私が行った調査によると、ほとんどの一般的なハードディスクドライブメーカーは、ハードディスクドライブの設計にECCを使用しており、1ビットの障害から3ビット程度保護することを想定しています。
これについて考えるとき、RAID(1)と同一の2台のハードディスクドライブがあるとしましょう。たとえば、データはドライブ0から読み取られ、同時にドライブ1からも読み取られます。ただしドライブ1はECC読み取りエラーをRAIDコントローラーに報告します。
これが大きな問題です。ハードウェアRAIDでは、RAIDコントローラーは何をしますか?ハードディスクから読み取りに失敗したという信号を受け取りました。ハードディスクドライブに障害があり、交換が必要であると報告する場合があります。
RAIDコントローラは、ドライブから正常に読み取られるまで、データを別のハードディスクドライブに要求しますか。 (はい、ドライブは読み取りが正しいことを報告できますが、データはまだ破損している可能性があり、RAIDは読み取り時に極性またはECCをチェックしません)
話をしてくれたネットアップのエンジニアに、まさにこの質問をしました。彼の答えは、多かれ少なかれ、次のとおりでした。
読み取り時にチェックサムを読み取る人は誰もいません。意味がありません。チェックサムを読み取るということは、スライス全体とチェックサムを読み取ってから、チェックサムを計算して正しいデータがあることを確認する必要があることを意味します。さらに、RAID-6などを実行している場合は、オルソガナルチェックサム。これは、異なるディスク上のまったく異なるセクターを同時にランダムにシークする機能を破壊するため、全体的なパフォーマンスのキラーです。同様に、RAID-1ではミラーの両側を読み取る人はほとんどいません。片側だけを読み取る場合は、ミラーのどちら側から読み取るかを交互に切り替えることができるため、スループットが向上します。突然不一致が発生した場合は、どちらのディスクを実行しますか。あなたは正しいと思いますか、そしてあなたはどちらを壊れていると思いますか?最新のRAIDシステムはすべて、ディスク上のコントローラーに依存して、RAIDコントローラーに問題があることを通知します(SMARTなど)。その時点で、ほとんどの場合、ディスクはディスクから追い出されます。アレイ。チェックサムは、読み取り検証ではなく、アレイの再構築に使用されます。
質問への答えは、RAIDコントローラの製造元と、それらがエラー/障害のあるドライブ検出をどのように実装したかに大きく依存します。
RAID実装がディスクの「正常性」を評価できるさまざまな方法(SMART、SCSI「CheckCondition」および「SenseKey」メッセージ)がありますが、RAID実装がどのように公開されている「標準」を認識していません。これらのメソッドに基づいて動作する必要があります。 RAIDコントローラーファームウェア(または、さらに言えば、OSでのソフトウェアRAID実装)の各メーカーとモデルが使用する特定の手順は、製造元の設計によって異なります。
現在、すべてのハードディスクドライブはエラー訂正コード(ECC)を使用しています。私たちがビットエラーで取り組んでいるデータ密度は、単なる現実です。回復不能な読み取りエラーは、RAIDコントローラーにとって重要です。関心のあるレベルでは、メディアエラーがデバイススタックからOS、そして最終的にはユーザーにどのように報告されるかを実際に理解するために、RAIDコントローラーとドライブファームウェアの両方の設計仕様を持っている必要があります。
実装は完全にメーカー次第です。ドライブに書き込まれるデータのパリティを計算し、それが間違っている場合は問題の可能性を示し、オンボードがある場合はハードディスクのステータスを監視する可能性がありますSMARTステータス、ドライブから直接エラーを読み取る、特定のドライブへの複数のエラーによる問題があるかどうかを確認するなど。
ドライブに問題があることを知らなかったコントローラーがありました。 1つのディスクに完全に障害が発生した3ドライブのRAID5がありました。新しいドライブをインストールし、正常なディスクの1つを再構築する過程で、回復不能な読み取りエラーが発生しました。これは、ドライブが大きくなり、製造元が製造プロセスでこれらの特定の数を許可するにつれて、ますます問題になります。最終結果?ベアメタルバックアップから再構築します。したがって、コントローラーがドライブの不良をどのように「認識」しているかを尋ねても、必ずしも認識しているとは限りません。
言い換えれば、RAIDコントローラーは可能な限り最善を尽くします。彼らはまだ失敗します。
最終的な結果として、RAIDコントローラーは通常、ソフトウェアから作業を抽象化することでセットアップを簡素化し、処理能力を専用ハードウェアにオフロードし、(通常)エンドユーザーにどのドライブが不良であるかを伝えるためのより良いサポートを追加します(ソフトウェアツールと/または点滅するライト)ので、どちらが悪いかを推測する必要はありません。
ソフトウェアRAIDはOSと統合されており、はるかに安価であり、現在(特にLinuxについて話している場合)ほぼ同じくらい信頼性が高く、ほぼ同じくらい高速(場合によっては高速)です。また、多くのコントローラーとは異なり、特別なドライバーは必要ありません。ハイエンドカードを使用すると、おそらくパフォーマンスが向上しますが、ほとんどのホームグレードRAIDの場合、速度は同等になる傾向があります。
マザーボードのRAIDについて話している場合、それは実際にはRAIDではありません。これはソフトウェアRAIDの安っぽいバージョンであり、マザーボードが南に移動した場合、ドライブ上のデータをどのように操作するかがベンダー固有であることが多いため、データを回復することはほぼ不可能です。システムに障害が発生し、ドライブをアレイから別のシステムに移動してデータを回復できない場合があります。
全体として、ビジネスのサーバー用のRAIDについて話している場合や、本当に特殊なニーズがある場合を除いて、ソフトウェアRAIDは、ホームユーザーが使用する90%のハードウェアRAIDと同等です。