ディスクドライブのリビルドを高速におこなうには

 

RAIDは大容量ドライブにはベストの選択ではないかもしれない。リビルド戦略を見直す時です。

現在のストレージ環境で大容量ドライブのリビルド時間を短縮することについて、多くの議論がなされている。今日、高速リビルド技術は広く普及しているものの、まだハードウェアRAIDと個々のドライブのリビルド時間を考慮しないユーザーが多い。そしてこの議論に新たな観点が生まれてきた。それはリビルド時間を短縮するための最適な方法は、まずリビルドの必要がないようにすることだろう、ということだ。

故障でベンダに返却されたSATAドライブのおよそ50％は、検査の結果「問題は見つからなかった」として、新品とほぼ同様に機能する交換用ドライブとしてサービスに戻されている。これは、SATAドライブはもともと軽負荷のデスクトップやラップトップ用に開発されたもので、高性能なエンタープライズ・アレイ向けではないため、時々パフォーマンスが落ち、その結果ディスクが反応しないと判断されることがあるためだ。そのため、ベンダの中には、そういった障害を診断して、ディスクが本当に故障しているか、一時的に減速しているだけかを判定する技術を導入したところもある。この技術はリビルド中にセカンドディスクが故障してデータが失われるリスクを軽減できるので、重視すべき技術である。

貴社のRAIDリビルドの課題解決にむけての最適な方法やベンダを決定する前に、ここに至ったいきさつを振り返ってみよう。RAID（Redundant Array of Independent（またはinexpensive）Disks）という言葉は1980年代後半に、ディスクドライブをアレイにして保護する手法を説明するために導入された。旧RAID Advisory Boardによる標準化への取り組みにもかかわらず、ほとんどのベンダはRAIDの基本定義に適合した保護手法を開発したものの、実装の段階では様々に変化した。どんな戦略を組もうと、RAIDのリビルド時間はディスク容量が大きくなるにしたがって例外なく長くなる。これは単純に、パリティからコピーまたはリビルドすべきデータが増えるためである。ほとんどのRAIDモードではディスクドライブが1台故障すると、RAIDのリビルドが完了するまでデータは保護されない状態に置かれる。さらにはRAIDのリビルドは処理能力を大量に使い尽くす。

しかし、ディスク1台の故障の場合でもデータ保護ができる方法はある。デュアルパリティRAID 6 -- シングルRAIDグループの2台のドライブが故障した時にデータが利用できるようにする技術 -- を実装するか、またはリモートミラーリング技術を導入して、ドライブの故障を防ぐことばかりでなく、サイト全体が障害に陥った場合でもデータが利用できるようにしておくことまでもできる。しかし、保護を積み重ねていくことにはコストを伴い、保護されるデータの価値とのバランスを考えなければならない。データ保護のために余分に割り当てられる容量は、時に保存データの3〜4倍にもなることがある。

TB級の大容量Serial ATA（SATA）ディスクドライブの登場で、事態はさらに悪化した。SATAドライブの回転速度はファイバチャネル（FC）ドライブの半分以下だが、1TBまで（FCドライブの2倍）データを収納できる。しかし、ドライブの密度は低速な回転速度を埋め合わせるほどではない。7,200 rpmのディスクドライブの平均レイテンシは15,000 rpmのドライブの2倍を超える。TBクラスのSATAドライブでは、システムの負荷によってはリビルドは数日間に及ぶこともあり、ビジネスへの影響が許容できないほどの重荷になってきている。データ格納に大容量ドライブを使用するのは極めてコスト的に有利である。SATAドライブのMB単価は高性能なFCドライブよりもずっと低い。高性能なFCドライブはストレージの最上位であり続けているものの、SATAドライブは低価格のおかげでアーカイブシステムやスケールアウト型のストレージアーキテクチャに広く普及している。

新たなデータ保護スキーム
大切なことはディスクを保護するのではなくて情報を保護することだということを、ストレージベンダはようやく理解し始めた。そしてデータ保護スキームもそれを反映するように展開し始めている。市場には、大容量低速ドライブにまつわる問題を解決する斬新なアプローチがいくつか出てきている。そうした技術の中には、システムの実行するリビルドの総回数を減らすものもある。また、情報自体を基本にした保護スキームにシフトし始めたところもある。つまり、ディスクをミラーリングするのではなく、情報（ファイル、チャンク、オブジェクト）をミラーリングするということだ。少しずついろんな方法を組み入れる方法もある。こうするとリビルド時間にどんな影響が出るだろうか？ディスクではなく情報をリビルドするという観点で考えると、マルチディスクアーキテクチャで大量の並列処理ができることを利用するように、システムアーキテクチャに力を注ぐ必要がある。

現在、ドライブの故障回数を全体的に減らすことで必要なリビルド回数を減らす技術がいくつか提供されている。ある場合には、ベンダは応答しないドライブをオフラインに切り替えて問題を診断し、障害が見つからなければサービスに戻している。この方法は全部リビルドする必要がなくなるため、優れた方法である。ドライブがオフラインになると、システムはそのドライブに行われるはずの書き込みをすべてジャーナリングして、その間にドライブを復旧させようとする。復旧が成功したら、ディスク全体ではなくジャーナリングされたデータだけをリビルドする。 いくつかのベンダは、必要なリビルド回数を減らすとともに、グリッド型ストレージアーキテクチャを活用してリビルドを高速化するという二面的な手法を取っている。ディスクがアクセス要求にすぐに応答しないと、その二面機能の1つが作動する。システムは要求データのミニパリティリビルドをしてからリビルドデータを返すことで応答し、その間に応答しないドライブを一時的にサービスから外す。ドライブは簡単な診断を受けてからサービスに戻される。これならリビルドの必要はない。ドライブがオフラインの間に書き込まれたデータはシステム内の他のスペースに書き込まれる。

また、グリッド・アーキテクチャを使ってリビルドを高速化することもできる。グリッド・アーキテクチャでは容量ノードまたはストレージノードとは別にプロセッサノードがある。通常、プロセッサノードはすべての容量ノードにアクセスできる。データの書き込みはいくつもの分割データに分解される。分割データはシステム内のできるだけ多くのストレージノードに分散して転送される。デフォルトで分割データが9個、分割パリティが3個（分割パリティの正確な数はユーザーが設定可能）だとすれば、12のそれぞれのストレージノードに分割データまたは分割パリティが1つずつ送られる。ストレージノードが4つなら（最小構成）、各ノードはそれぞれ3つずつ取得する。ドライブが故障すると、従来のハードウェアRAIDと同じようにそのドライブからデータがリビルドされる。従来のRAIDと違うのは、データが1つのドライブにリビルドされるのではないことだ。データは利用できるストレージ容量を活かして、各ストレージノードに再転送される。あるストレージノードが完全に故障した場合は、そのドライブのデータは残りのストレージノードでリビルドされる。このタイプの技術はパリティ保護されたデータとミラーリングされたデータの両方で実行される。ディスクドライブではなくデータを保護することや、さらにグリッドアーキテクチャの効果によって、リビルドは従来のドライブリビルドの何分の1かの時間で完了する。リビルドされるのは情報であり、ドライブの正確なレイアウトではない。

また別のベンダは、アーキテクチャを活かしてリビルドを高速化してドライブが複数故障したときのデータ損失リスクを軽減している。ファイルが書き込まれると、データとパリティがクラスタ内の利用できるディスクドライブ全部に転送される。ドライブが故障すると、リビルドに必要なデータがクラスタ内の複数のノードに分散されているので、クラスタ全体のドライブが活かされることになる。

データ保護手法をハードウェア型のアプローチからソフトウェア型のアプローチにシフトすることで、新しい可能性が開ける。ハードウェア型の保護手法では、データ全部を保護するか、または何も保護しないかという選択しかないことがあった。情報ベースの保護はより粒度の細かい、ポリシーベースの情報保護の可能性に道を開いた。

肝心なのは、データの種類によって求められるストレージ特性が変わってくることだ。ハードウェアRAIDは依然として小容量・高速ドライブに適したソリューションであり、すぐに市場から消えることはない。ただし、情報ベースのデータ保護スキームが最高水準のストレージ製品でいずれ主流になっても何も驚くには当たらない。ベンダは管理方法の簡略化と情報を中心にしたシステムの構築を進めていくからだ。

多くのベンダは情報ベースのデータ保護や高速リビルド技術を提供している。厳しい経済情勢でも、リビルドを高速にしたり、リビルドの必要性を軽減する技術を提供するベンダの数は増え続けると思われる。大容量の安価なディスクドライブを活用する技術を評価する際は、リビルド中にデータを損失するリスクをどうやって減らすのか、ベンダに質問しよう。

All Rights Reserved, Copyright 2000 - 2009, TechTarget
*この翻訳記事の翻訳著作権はJDSFが所有しています。 このページに掲載されている記事・写真・図表などの無断転載を禁じます。