コンピュータ機器で障害が最も多いパーツは、やはりハードディスクである事は未だ変わりはありません。そしていかに新技術が投入されたとしてもますます大容量化するハードディスクは、常にデータの一部欠損というリスクが付きまとっています。例えば、過去1GBのハードディスク100台に対し1台の割合で欠損ブロックが発生していたと仮定し、同じエラーレートを採用した上で現在の100GBクラスのハードディスクに当てはめたとすると、全てのハードディスクが欠損ブロックを発生させる確率を持っていることになります

より高密度化するハードディスクのリスクとは

ハードディスクの高密度化への進化は未だ衰える事がありません。

約一年半で容量が二倍といったペースは、利用者に大きなコストメリットを与える反面、一台のハードディスク故障で損なうデータ量は増加します。つまりコストメリットとリスクが反比例するのです。こういった、ハードディスクがメカ毎故障するトラブルに対しては、従来のRAID装置でも十分リカバリー可能なのですが、近年新たなトラブルが増加傾向にあり、これまでのRAIDアルゴリズムではリカバリー不能なケースが出てきています。

増加するハードディスクの欠損ブロック

データトラックが1ミリの幅に2万本を超える密度となると、外部からのちょっとした振動を加えるだけでも、ヘッドの位置が数トラックもずれてしまうほどの世界です。もしこれがデータを書き込み中に起こったらどうなるでしょう？単純に数トラック分、データを斜めに上書きしてしまうことになります。

もちろん、現在のハードディスクは、こういったトラブルも回避できるよう、ショックセンサーで衝撃を検出し隣接トラックへの上書き防止しています。しかし、こういった既知のトラブルへは対処できていても、ここまでミクロの世界になると設計者が想像もし得ない問題も起こる可能性もあります。

例えばD-RAMのメモリーセル設計者から聞いた話ですが、地磁気が影響するのか装置を北に向けるか東に向けるかで、3ヶ月に一度の割合で1ビットだけフリップが起こるといったようなトラブルです。現在のハードディスクの記録密度は１インチ平方辺り30Gbitものデータが書き込まれているため、繊細で高度なサーボ技術の上に成り立っています。

したがって、メモリーセルに設計者が悩んだような障害が起こりえないとも限りません。
さて、現実面ではどうかというと、明らかにデータが読めなくなる欠損ブロックの発生頻度が高くなっています。

単純にこの障害を説明すると、例えば、毎年、新聞の文字が小さくなっていったらどうなるでしょう？

より小さな文字を印刷する技術が進歩した結果、逆により拡大率の高い虫眼鏡で文字を読み取るようなものです。

もしこのような印刷物となると、印刷物を指で少しでも擦ってしまったら、読めなくなるような事があっても不思議ではありません。

実はハードディスクにおける欠損ブロックの発生とは、こういったレベルのトラブルによく似ていて、記録密度が高くなればなるほどリスクが高くなります。

数年前のハードディスクは、実データでの読み込みにおけるエラー率は10のマイナス9乗程度であったのですが、現在は10のマイナス6乗程度でどちらもECCエラー訂正ビット数を増やしデータの信頼性を保っているのですが、それに伴ってECCエラー訂正の演算も複雑化し、その処理回数も増加します。また数学的な論理値で信頼性を確保しているとはいえエラーの発生しやすいブロックとは、特定の領域に集中する傾向が高いといえます。

そのため、ECCエラー訂正も効かないブロックが発生するのですが、こういったブロックでもハードディスクの生産時点で必ずしも不良扱いとならない、つまり、品質レベルで良否の狭間にあるブロックが存在しています。

このようなブロックの発生頻度は、単純計算してもハードディスクの記憶容量に比例する上に、実データの読込品質も相乗して高くなってしまう宿命的な問題なのです。

欠損ブロックを持つハードディスクは不良なのか？

ハードディスクはECC エラー訂正のできないブロックが存在したとしても、ありとあらゆるアナログ技術を駆使して、読み込みのリトライを試みます。ある程度のリトライ数を超えて読み込みに成功すると、次回の読み込み時にもデータが正常に読めるようにと、そのデータを上書きするリフレッシュを行うのですが、それに失敗すると今度はブロックを別の予備領域にリアサインしデータを書き込みます。

一般に、この機能をオートリアサインと呼んでいます。ハードディスクは生産時点で見つからなかった品質の低いブロックを、実運用によるオートリアサインで品質を高めて行きます。特に運用開始からオートリアサインの多く発生する数ヶ月間は、スクリーニング期間とも呼ばれ暫くすると落ち着いてきます。しかし、稀にリトライをどんなに繰り返しても読めないブロックが最終的に欠損ブロック(Bad Block )となります。

さて、こういった経緯で最終的に欠損ブロックを発生してしまったハードディスクですが、これは故障なのかというと現実には、その大半が良品と判定されます。単純に言えば、消えてしまったデータはあきらめるしかないのですが、その欠損ブロックへ新しいデータを上書きし、そのデータが正常に読み取れるのであれば、ディスクメーカーから障害未再現の良品として返されます。もちろん、欠損ブロックの発生頻度が高く予備の領域が多く消費されている場合には故障扱いとなります。つまり、欠損ブロックに対しては、その発生頻度が良品の判定基準ともいえます。

とはいえ、ブロックひとつだからといって、データが消えてしまっては安全なシステム運用ができません。そこで必要となるのは、ソフトウェアで欠損ブロックを補う技術、つまり、RAID です。(もちろん、ハードウェアRAID もソフトウェア上でなりたっています。)

しかし世間では欠損ブロックを捕らえるRAIDが少ない

以前RAID は、欠損ブロックが発見されると、そのハードディスクは単純に不良品と判断し RAID グループから切り離していました。そして残ったディスクから欠損ブロックを復元し、ホストコンピュータにデータを返せば済んでいたのです。もちろん、そのRAIDグループに新しいハードディスクを加えてリビルドすれば、以前のハードディスクなら何のトラブルも無く復帰できましかし、現在のハードディスクを利用するRAIDはそうも行きません。

それは欠損ブロックの発生が、そのRAID グループ内のハードディスクで一台だけとは限らない時代となったためです。

もし、最初に欠損ブロックが見つかったディスクを安易にRAID グループから切り離してしまえば、リビルド時に他のドライブに欠損ブロックがあれば正常なリビルドができなくなります。

例えば図1 のように、HDD1 とHDD2 に欠損ブロック”×7 ””×11 ”が存在していた場合、先にHDD1の欠損ブロックを見つけて切り離したらどうなるでしょう？

リビルドの際は図2 のように列単位にパリティ計算され、スペアディスク(HDD5)に復元されたデータが書き込まれて行くのですが、欠損ブロック”×11 ”によってHDD5 の4 列目のデータは当然のことながら復元できないため、その時点でリビルドは不正終了となります。

したがって、従来のRAID アルゴリズムでは、このように複数のハードディスクで発生した欠損ブロックには対応することができません。実は、ニューテックのConfidence ATA シリーズでも、複数のハードディスクにおける欠損ブロック発生が問題になり始めたのが2001 年春頃で、その年の夏頃までのファームウェアでは対応できませんでした。

特に図2 のケースでは、4 列目の欠損ブロック位置でリビルドを中断した後、リビルドを最初からやり直すため、それを無限に繰り返すといった問題がありました。(これらのトラブルについては、その経緯がニューテックのホームページにも書かれているので参照ください。)

その他にも、世間に出回っているRAID を調べてみたのですが、そのほとんどのハードウェアRAID やOS 標準のソフトウェアRAID も、このような古いアルゴリズムで動作していました。中には図2 のケースで4 列目がリビルドできないにも関わらず、まるで欠損ブロックが無かったようにリビルドを正常終了し、不正であるはずのデータブロック(？)を、そのままOSに返してきているRAID までありました。

(現在も、大半のRAID は改善されていないようです。)

でも単純なアルゴリズムで欠損ブロックは修復できる

ところで、図2 をよく見れば分かるようにHDD1 はメカ的に完全な故障をしていなければ、復元すべき4 列目の正常なデータ(ブロック10 )が残っているのです。また、HDD1の欠損ブロックは、単純に新しいデータを上書きすれば機能を回復でき、その行為が品質の低い領域に対してスクリーニングとなるのであれば、むしろ切り離すべきではないのでしょうか。もちろん、スクリーニングの進んでいない新しいディスクへのリビルドを考えても、どの道、欠損ブロックのリスクは伴うのです。

さて、この欠損ブロックは障害とせず、上書きして回避するとすれば単純に図3 のように他のディスクからデータを復元し書き込めば良いのです。

また、欠損ブロック”×11 ”も見つかった際、同じ理屈でHDD1、3 、4 の4 列目のデータから復元できます。もちろん、ミラーリングのRAID- 1ならもっと簡単で、正常なもう一方のハードディスクからデータを読み取り、それを欠損ブロックに上書きしてやれば良いわけです。

以上のように、単純なアルゴリズムを追加するだけで、欠損ブロックのリカバリーが可能です。

Confidence ATA シリーズには、こういったアルゴリズムが昨年の夏頃からのファームウェアに追加されています。

また、高容量のハードディスクをサポートするConfidence 100/2000 以降の製品やDuoK2 シリーズには、同アルゴリズムを組み込んだファームウェアも既に用意されています。SCSIやFC のハードディスクは、IDE に比べ欠損ブロックの発生確率がかなり低いため、ファームウェア対応が後追いとなってしまい、お客様には大変ご迷惑をおかけしました。

なお、Duo K2 については弊社でのアップデートとなりますので、ニューテックのカスタマケア課までご相談ください。

何でRAID-3や5が他のディスクからデータを復元できるの

ところで、何で他のディスクからデータが復元できるの？

と、RAID- 3 や5 を理解していない人のために、簡単なデータ復元の理屈を解説しておきます。

簡単に言えば、小学校低学年の頃の算数を思い出してください。

テストで、こういった問題は出ませんでしたか？

１ ＋２ ＋３ ＝６ という式を基にテスト：以下の□の部分に数字を入れなさい。

１ ＋２ ＋□＝６

１ ＋□＋３ ＝６

□＋２ ＋３ ＝６

どの問題も、□の中の数字は簡単に計算できますね。

つまり、RAID にとって□の部分が欠損ブロックまたは壊れたディスクなのです。したがって数字1 ・2 ・3 の実データが入るブロック部分と、パリティに値する数字6 の部分があれば、どのブロックが無くなっても回復できます。もちろん、パリティが欠損ブロックだった場合、以下のような式になりますから同じように回復できますね。

１ ＋２ ＋３ ＝□

しかし、RAID- 3 や5 で問題となるのは、この□が2 つ以上になった場合、もちろん計算ができなくなることです。

当然

□＋２ ＋□＝６

では、2 つある□に色々な数字を入れることができます。

つまり、こうなった時は、新しいRAID アルゴリズムを導入したとしてもリカバリーできないトラブルとなるので、例えRAIDとはいえ欠損ブロックをOS に通知します。もちろん、この障害がハードディスクの故障であれば、ボリューム全体が使えなくなる大問題ですす。

したがって、RAID 装置を使っていても、バックアップは必要なのです。

さて、もう一歩、ステップアップして解説を進めます。

ところで単純に足し算すると、当然、桁あふれが起こるじゃないかと思われた人もいると思います。

７ ＋８ ＋９ ＝２４

データディスクもパリティディスクも同じ大きさの入れ物なのに、こうして桁あふれした場合、桁あふれしたデータはどこに保存するの？

実はRAID では足し算を使っていません。コンピュータの内部では数字を2 進数で扱っているので数字は0と1しか存在しないため、もっと便利な演算子があるのです。

それは、論理演算にある排他論理和(XOR )です。

ここで、解説をもっと単純化するために、RAID-3 や5 で最小構成であるデータディスク2台とパリティディスク1台の構成に変更します。

さて、排他論理和には次の規則があります。

※もちろん論理式なので桁あふれしません。

見て分かるように2 進数で両方の数字が違う時に答えが1 (真)です。

ここで、排他論理和の便利な所は”XOR”と”＝”を入れ替えても式が成立する点です。

となれば、”XOR ”と”＝”の入れ替えだけではなく、3 つの数字をどのように入れ替えても式

は成立します。

(1) ０ ＝０XOR０

同じ数字を入れ替えても意味無いので省略。

さて、この式で表した数字を左から、ディスク1 、ディスク2 、パリティと考えてください。どのディスクに欠損ブロックが生じても全て同じXOR で 桁あふれもなく計算できますね。

１XOR □＝１

この場合、単純に下の式として計算できます。

１XOR１ ＝□

□がどこにあっても、こんな風に式を成立させられます。

もちろん、ディスクをどの順に入れ替えても、ディスク台数が何台になろうとも、壊れた部分の復元には残ったディスクの全てをXOR すれば再生されるのです。次の式はディスクが4 台の時の例ですが、同じように数字を入れ替えて見てください。いずれも式が成立しますね。

(０XOR０ )XOR１ ＝１

しかし、あれ！それでは1 と0 以外の大きな数字はどうなるの？例えばコンピュータで表すByteデータでは？となるのですが、その心配はありません。実際にはビット単位で、同じ桁どうしでXOR しています。

例えば

となります。これが、一般にハードディスクのデータブロックサイズ512Byte でも、同じように512Byte ×8bit で4096bit 列のXOR です。

このbit 列が何bit になろうとも同じ方法で計算されるため、桁あふれのしないパリティデータが生成でき、そして、パリティ生成時もデータ復元時も全て同じXOR式だけでの簡素化したプログラムを実現しています。

また、ソフトウェアRAID では、このXOR 式を全てCPU で行うため、処理の重いシステムでは実用的ではないのですが、ハードウェアRAID の場合は専用IC でXOR 演算するので、高速で、かつ、CPU に負担をかけないため、どういったシステム環境でも実用的である点がメリットです。