RAIDアレイにおけるダブルフォールトおよび破損（英語）

目次

1. データエラーとダブルフォールト
2. パンクチャー：その説明と原因
3. 問題の予防策およびパンクチャ発生後の解決方法
   
    

第1章：データエラーとダブルフォールト

RAIDアレイもデータエラーの影響を受けます。  RAIDコントローラおよびハードドライブのファームウェアには、多くの種類のデータエラーを検知して、アレイ/ドライブに書き込む前に修正する機能が備わっています。  古いファームウェアを使用すると、最新のファームウェア バージョンで使用可能なエラー処理/エラー訂正機能がないため、アレイ/ドライブに誤ったデータが書き込まれる可能性があります。


データ エラーは、物理的な不良ブロックが原因で発生する可能性もあります。  たとえば、回転しているプラッタに読み取り/書き込みヘッドがぶつかった（ヘッドクラッシュした）ときに、不正ブロックが発生することがあります。  また、プラッタの特定箇所で、ビットを磁気的に保持する能力が徐々に劣化して、不正ブロックになることもあります。  プラッタの劣化により発生した不正ブロックは、正しく読み取りできることもあります。  このような不正ブロックは、間欠的に検知される場合があります。確実に検知するには、ドライブに対する拡張診断が必要です。  


不正ブロック、つまり不正な論理ブロックアドレス（LBA）は、論理データエラーによって発生することもあります。  これは、書き込みの成功が報告されているにもかかわらず、データがドライブに不正確に書き込まれたときに発生します。  また、ドライブに正常に保存されているデータが意図せず変更されることがあります。  一例として「ビットフリップ」があります。これは、読み取り/書き込みヘッドがデータ上を通過したときや、近くの場所に書き込みが行われたときに、0と1で構成されるデータが別の値に変化することで発生します。  このような状況が発生すると、データの「コンシステンシー」が失われます。  特定ブロックのデータの値が元の値と異なっているので、データのチェックサムが一致しなくなる可能性があります。  物理LBAは正常であり、正常に書き込むことができますが、現在は誤ったデータを保持しているので、不良ブロックとして解釈されることがあります。


不良LBAは、通常「Sense Code 3/11/0」として報告されます。Sense Key「3」はメディアエラーです。  追加のSense CodeとSense修飾子の「11/00」は回復不能な読み取りエラーとして定義されています。  ブロックの修正は試行されません。また、不正ブロックがドライブのプラッタに存在する物理的不具合なのか、それとも他の原因によるデータエラーなのかも判断されません。  「Sense Code 3/11/00」が存在しても、それがそのまま、物理ドライブに障害が発生した、または交換する必要があることを意味するわけではありません。


Dell製ハードウェアベースのRAIDコントローラーは、データ エラーの多くのシナリオを修正するための巡回読み取りや整合性チェックなどの機能を持っています。  Patrol Readは、デフォルトで自動バックグラウンドタスクとして動作します。この機能では、データが正しく読み取られるように、ハードドライブ上の個々のブロックがすべてチェックされます。  Patrol Readでは、不正ブロックの修正や、予備ブロックへの回復不能ブロックの再配置が試行されます。  コンシステンシーチェックは手動でアクティブにする機能です（スケジュールすることもできます）。この機能では、アレイ内のすべてのドライブが相互に比較され、データと冗長データが正確に一致していることが確認されます。  たとえば、RAID 5アレイの場合は、データとパリティで正しい値が使用されていることを確認するために、アレイ内の3台のドライブが比較されます。  単一エラーを検知した場合は、残りのデータとパリティを使用して、間違った値を書き換えて修正します。  同様に、RAID 1アレイでは、データが正しくミラーリングされるように、1台のドライブ上のデータがもう一方のドライブと比較されます。


RAIDアレイ内の単一のエラー（修正されていない場合）は、より深刻なエラーがアレイ内で発生する原因となることがあります（特に、2番目のエラーが発生したとき）。  1つまたは複数の単一エラーが発生しても、アレイが最適な状態にあればデータ損失は起こりません。  アレイが最適な状態の間は、まだ正常に動作するのに十分なデータと冗長性があります。


コントローラーには、正常動作中にエラーを修正する機能があるため、データに根本的な問題が存在する場合に常に簡単に検出できるわけではありません。  1つまたは複数の単一エラー状態が存在する場合でも、コントローラログ、ハードウェアログ、またはオペレーティングシステムのイベントログには、エラーやアラートがほとんど記録されません。  そのため、整合性エラーや単一エラーが存在していても、アレイは長期間正常に動作しているように見えることがあります。




図1：RAID 5アレイでの複数の単一エラー - 最適なアレイ


図1に示すように、このアレイには複数のエラーがあります。  しかし、いずれのストライプでも単一エラーしか発生していないので、RAID 5の冗長性により、コントローラは依然としてすべてのデータにアクセスできます。  パリティセグメントでエラーが発生している場合は、すべてのデータは正常なので、読み取り動作には何の影響もありません。  データセグメントでエラーが発生した場合は、正常なデータと正常なパリティピースに対してXOR比較を実行し、損失/不正データセグメントを再計算します。  いずれの場合も、どのストライプにも1つのエラーしかないため、すべてのデータに正常にアクセスするために十分な冗長性が確保されています。

RAIDアレイ内の1台または複数のドライブにデータ エラーがあり、そのアレイ内の別のドライブが、ドライブの障害、外部構成、ドライブの取り外しなどの理由によりアクティブなメンバーでなくなった場合は、「ダブル フォールト」と呼ばれる状態が発生します。  ダブル フォールト状態になると、影響を受けるストライプ内のすべての情報のデータ ロスがすぐに発生します。




図2：障害が発生したドライブのダブル フォールト（ストライプ1およびストライプ2のデータが失われる） - 縮退アレイ


最適な状態にあるアレイでも、ダブル フォールト状態が発生する可能性があります。  これは、複数のハードドライブ上で同一LBAが不正な場合に発生します。  ますます高容量化する現代のハードドライブに含まれる膨大なLBA数を考えると、このような状況は非常にまれです。  複数のハード ドライブ上の同じLBAが同時に「不良」になることはほとんどありません。

定期的な整合性チェック操作を実行すると、物理的な不良ブロックであるか、データの論理エラーであるかに関係なく、単一エラーは修正されます。コンシステンシーチェックを実行すれば、追加でエラーが発生した際のダブルフォールト状態のリスクも低減できます。  任意のストライプに含まれるのが1個の単一エラーであれば、整合性チェックでほぼすべてのエラーを解決できます。

トップに戻る
 

---

 

第2章：パンクチャー：その説明と原因

パンクチャとは、デルのPERCコントローラの機能の一つです。ダブルフォールト状態によってデータロスが発生しても、コントローラがアレイの冗長性を復元できるようにする機能です。  パンクチャは「エラー付き再構築」と呼ばれることもあります。  RAIDコントローラはダブルフォールトを検知します。影響を受けるストライプ内のデータ回復に十分な冗長性がないので、コントローラは当該ストライプ内にパンクチャを作成し、再構築の続行を許可します。

 

• 複数ドライブ上の同一ストライプでデータにアクセスできなくなるすべての状況を、ダブルフォールトと呼びます。
• ダブルフォールトが発生すると、影響を受けるストライプ内のデータが失われます。
• すべてのパンクチャはダブルフォールトですが、ダブルフォールトがすべてパンクチャにつながるとは限りません。

図3：パンクチャーされたストライプ（ストライプ1およびストライプ2のデータはダブル フォールト状態のために失われる） - 最適なアレイ


パンクチャー機能がないと、アレイの再構築が失敗し、アレイが縮退状態のままになります。  この障害によって別のドライブも故障して、アレイが機能しないオフライン状態になることもあります。  アレイのパンクチャは、ブート機能にも、アレイ内のデータにアクセスする機能にも影響しません。  ダブルフォールトによるすべての破損やデータロスは、それ以前にすでに発生しています。



パンクチャは次の2つの状況のいずれかで発生します。
 

• ダブルフォールトがすでに存在している（データはすでに失われている）
  • オンラインドライブ上のデータエラーが再構築中のドライブに伝播する（コピーされる）

 

• ダブルフォールトが存在していない（2つ目のエラーが発生したときにデータが失われる）
  • デグレードした状態でオンラインドライブで不正ブロックが発生すると、そのLBAがパンクチャされる

アレイをパンクチャするメリットは、システムが本番稼働し続けること、およびアレイの冗長性が復元されることにあります。  影響を受けているストライプにあるデータは、パンクチャが発生していようといまいと、すでに失われています。  LSI手法の主なデメリットは、アレイにパンクチャが存在しているときに、影響を受けているデータへのアクセスがあると、回復不能なエラーが発生し続けることです。


パンクチャは3つの場所で発生する可能性があります。  まず、データを含まないブランクスペースで発生する可能性があります。  このストライプにはアクセスできませんが、データが存在していないので、大きな影響はありません。  パンクチャされたストライプへのOSによるすべての書き込みは失敗し、データは別の場所に書き込まれます。


次に、README.TXTファイルのような重要ではないデータを含むストライプで、パンクチャが発生する可能性があります。  影響を受けているデータがアクセスされなければ、通常のI/O中にはエラーは発生しません。  ファイルシステムのバックアップを試行すると、パンクチャの影響を受けているすべてのファイルのバックアップが失敗します。  整合性チェックまたは巡回読み取り動作を実行すると、適切なLBAおよび/またはストライプに対する「Sense code:  3/11/00」が生成されます。


3番目に、アクセスされるデータ空間でパンクチャーが発生することがあります。  この場合は、失われたデータによって、さまざまなエラーが発生します。  これらのエラーは、本番稼働環境に悪影響を及ぼさない軽微なエラーのことも、  オペレーティングシステムを起動できなくなったり、アプリケーションが機能しなくなったりする、より深刻なエラーのこともあります。


最終的には、パンクチャされたアレイを削除して再作成し、パンクチャを除去する必要があります。  この手順を実行すると、すべてのデータが消去されます。パンクチャを取り除いた後で、データを再作成するか、バックアップから復元します。  パンクチャーの解消は、ビジネスのニーズにより都合のいい時間にスケジュール設定できます。


パンクチャーの発生したストライプ内のデータにアクセスした場合、修正が適用できない、影響を受ける不良LBAに対するエラーが引き続き報告されます。最後には、不正ブロック管理（BBM）テーブルがいっぱいになり、1台または複数台のドライブに「予測エラー」というフラグが立てられます（これは、数分、数日、数週間、さらに数か月かかることもあります）。図3では、通常、ドライブ0に予測エラーフラグが設定されます。これは、ドライブ1とドライブ2からドライブ0に伝播するエラーが原因です。ドライブ0は実際には正常に動作している可能性があり、ドライブ0を交換しても、最終的には交換したドライブにも予測エラーのフラグが付けられることになります。


パンクチャーが発生した後で整合性チェックを実行しても、この問題は解決されません。  これこそが、定期的なコンシステンシーチェックが非常に重要な理由です。可能であれば、ドライブ交換の前に実行することが特に重要です。整合性チェックを実行するには、アレイが最適な状態である必要があります。


単一データ エラーに絡んでハード ドライブの障害などの追加のエラー イベントが発生しているRAIDアレイでは、障害が発生したドライブまたは交換用ドライブがアレイに再構築される際にパンクチャーが発生します。たとえば、最適な状態にあるRAID 5アレイには、ドライブ0、ドライブ1、およびドライブ2が含まれています。ドライブ0が故障（図2）して交換されると、不足している情報がドライブ1とドライブ2に残っているデータとパリティを使用して再構築され、交換されたドライブ0に戻されます。しかし、ドライブ1にデータエラーがあり、再構築動作中にそのエラーに到達したときには、不足しているデータの再構築に十分な情報がストライプ内に存在していない状態になります。再構築中には、ドライブ0にはデータがなく、ドライブ1には不正なデータが含まれていて、ドライブ2には正常なデータが含まれています。つまり、このストライプには複数のエラーが含まれています。ドライブ0とドライブ1には有効なデータが含まれていないので、当該ストライプ内のすべてのデータは回復できずに失われます。  その結果として、図3に示すように、再構築中にストライプ1と2にパンクチャが作成されます。このエラーはドライブ0に伝播します。


アレイがパンクチャされると、冗長性が復元され、アレイは最適な状態に戻ります。  これにより、さらにエラーやドライブ故障が発生した場合でも、これ以上のデータロスを防ぐことができます。

トップに戻る
 

---

第3章：問題発生前の予防策およびパンクチャー発生後の解決方法

「壊れていなければ直さない」という前提での運用は魅力的です。これは多くの領域に当てはまりますが、ストレージサブシステムを最善の方法で保護し管理するためには、日常的かつ定期的なメンテナンスを行うことを強くお勧めします。事前メンテナンスでは、既存のエラーを修正し、特定のエラーの発生を防止できます。すべてのエラーの発生を防ぐことはできませんが、ほとんどの重大なエラーを大幅に軽減できます。ストレージおよびRAIDサブシステムの場合、その手順は次のとおりです。

 

• コントローラ、ハードドライブ、バックプレーン、およびその他のデバイスのドライバおよびファームウェアをアップデートする
• 定期的にコンシステンシーチェックを実行する
• ログをレビューして問題の兆候を探る

これは、高度な技術的レビューである必要はなく、単純にログにおおまかに目を通して潜在的な問題の明白な兆候を探すだけで十分です。
質問や懸念事項がある場合は、Dellテクニカル サポートにお問い合わせください。


最も重要なことの1つは、ファームウェアが最新の状態に保たれていることです。ファームウェアには、デバイス動作のロジックがすべて含まれています。ファームウェアは、各種のエラー処理とエラー修正の機能を含め、デバイスの機能や仕様を提供します。ファームウェアを最新に保てば、パフォーマンスが向上し、エラーは減少します。新しい機能と機能拡張は、ファームウェア アップデートを使用して追加することもできます。


ファームウェアは、さまざまな場所に存在するかのうせいがあります。RAIDコントローラだけでなく、システムやアレイに取り付けられた個々のハードドライブにもファームウェアが含まれています。バックプレーンおよび外部エンクロージャには、その中に格納されるドライブとアレイの動作に影響を与える可能性のあるファームウェアも含まれています。


もう1つのプロアクティブなメンテナンスの推奨事項は、「整合性チェック」を実行することです。  コンシステンシーチェックは手動で行います。これは、RAIDコントローラで利用される帯域の一部が使用されることが理由です。ただし、整合性チェックは、パフォーマンスへの影響が最も低い時間にスケジュール設定できます。


整合性チェックでは、ドライブ上の不良ブロックがチェックされますが、さらに重要なのは、すべての箇所が正しく一致していることを確認するためにアレイ内のデータを比較するということです。問題を検知すると、アレイ内の他のドライブにあるデータをチェックし、データのあるべき状態を判断して修正します。既存のデータエラーに加えて2番目のエラーや障害が発生したときのパンクチャのリスクを抑えるには、データエラーが比較的小規模なうちに修正することが最善です。ダブル フォールトとパンクチャーが存在すると、アレイとデータを機能する状態に復元するための時間が必要になり、生産性が低下することがあります。さらに、すべてのデータが完全に失われることさえあります。


ダブル フォールトまたはパンクチャー状態が存在する場合、データロスが発生することが多くあります。こうしたエラーが発生した場所がブランクスペースや重要でないデータスペースであれば、本番稼働環境のデータに直接与える影響は比較的小さくなります。ただし、こうしたエラーの存在は、より深刻な問題の存在を示していることがあります。ハードウェア エラーや古いファームウェアをすぐに対処することが必要な可能性があります。


ダブル フォールトやパンクチャーが発生しているか、または発生している疑いがある場合は、より深刻な問題のリスクを最小限にするために以下の手順に従います。

 

• コンシステンシーチェックを実行する（アレイは最適な状態になっている必要がある）
• ハードウェアの問題が存在するかどうかを判断する
• コントローラログをチェックする
• ハードウェア診断を実行する
• 必要に応じてデルのテクニカルサポートにお問い合わせください。

これらのステップが完了しても、また別の懸念があります。パンクチャが存在したまま時間が経過すると、ハードドライブは予測エラー状態になります。ドライブに伝播したデータエラーは、そのドライブに実際にはハードウェア上の問題がなかったとしても、ドライブ上のメディアエラーとして報告されます。LBAにアクセスするたびにエラーが報告されます。エラー ログがいっぱいになると、ドライブは自身を予測エラーとして報告します。


1台のドライブ上の1つのパンクチャーしたLBAは、何度も報告されることがあります。パンクチャの数によっては、アレイ内の複数台のドライブが予測エラー状態として報告されることがあります。予測エラー状態のドライブを交換すると、既存のパンクチャが交換ドライブに再び伝播するので、最終的には、交換したドライブにも予測エラーフラグが設定されます。このような状況への唯一の対応処置は、パンクチャー状態を解消することです。


図3を見ると、ストライプ1とストライプ2にパンクチャーがあることがわかります。ハードドライブを交換しても、元データの再構築に必要な冗長性がないので、この問題は解決されません。事前にバックアップしていない限り、パンクチャされたストライプに含まれているすべてのデータが失われます。もちろん、データロスを引き起こすのはパンクチャではなく、ダブルフォールト状態です。パンクチャは、ダブルフォールトを含むアレイに冗長性を復元するための手段です。
 

 

 

 

1. 保存キャッシュを破棄します（存在する場合）
2. 外部設定をクリアします（存在する場合）
3. アレイを削除します
4. ドライブの位置を1つ移動します（図1を参照して、ディスク0をスロット1に、ディスク1をスロット2に、ディスク2をスロット0にそれぞれ移動します）
5. 必要に応じてアレイを再作成します
6. アレイの（高速初期化ではなく）完全初期化を実行します
7. アレイで「整合性チェック」を実行します

整合性チェックがエラーなしで完了した場合、アレイが正常になり破損が取り除かれたと考えられます。これで、正常なアレイにデータをリストアできるようになりました。


より深刻なケースでは、問題が解決されず、これらの手順に従っているにもかかわらずエラーが解決しない場合があります。これらの手順を実行しても問題が解決しない場合は、Dellテクニカル サポートにお問い合わせください。


パンクチャーをより詳細に分析して、共通しているドライブを特定する必要がある場合があります。たとえば図3では、ディスク0と1の間のパンクチャ、およびディスク0と2の間のパンクチャがコントローラログに表示されます。ディスク0が共通ドライブです。上記と同じステップを実行しますが、最初に共通ドライブを完全に取り外します。図1の例では、ディスク0を取り外してから、このステップを実行します。残りのディスク（1および2）を使用してアレイを作成します。整合性チェックが完了し、アレイが正常であると判断したら、次にディスク0を再度追加し、すべてのドライブでこの手順を再度実行するか、またはRLM（RAIDレベルの移行）および/またはOCE（オンライン容量拡張）機能を使用して残りのドライブをアレイに戻して追加します。


予測エラーのフラグが付いているドライブはすべて取り外し、リカバリー プロセスには含めないでください。例として図3を再度使用しますが、ここでディスク0が予測エラー状態であれば、このドライブを取り外します。その後、前述のステップを実行します。ドライブは2台しか残っていないので、作成されるRAIDアレイはRAID 5ではなくRAID 1です。交換用ディスク0を入手してから、3台のドライブすべてを含めてこの手順を再度実行する方法と、RLMを使用してディスク0を既存のアレイに追加し、ドライブ2台のRAID 1からドライブ3台のRAID 5に変更する方法があります。


データ ロスの可能性があることを考えると、このプロセスの実行には躊躇するかもしれません。ここでは「予防は治療に勝る」ということわざがまさに真実です。経験から、ほとんどすべてのダブルフォールト状態は、RAIDハードウェアやアレイに対する事前メンテナンスを実行していれば回避できたはずのものでした。
 

 

 

関連記事
「PERC - RAIDの破損の修正方法」

 

トップに戻る

 

-

-