(57)【特許請求の範囲】
【請求項１】
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置において、
前記複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築手段と、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築手段と、
前記第１及び第２の再構築手段を制御し、前記第２の再構築手段が前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築手段に該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御手段と、
を具備することを特徴とするストレージ制御装置。
【請求項２】
前記第２の再構築手段は、２台の予備記憶装置を連携させた再構築を行う場合、該再構築を早く開始した予備記憶装置を先行側、該再構築を遅く開始した予備記憶装置を追従側に設定し、該先行側で再構築が行われた部分のなかで該追従側が再構築を行っていない部分が無い状況になったとき、該追従側は該再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させる、
ことを特徴とする請求項１記載のストレージ制御装置。
【請求項３】
前記再構築制御手段は、前記未故障の１台で前記再構築が終了した領域が連続しているか否かにより、前記２台の再構築処理の内容を変化させる、
ことを特徴とする請求項１記載のストレージ制御装置。
【請求項４】
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御方法において、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行い、
前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて該再構築を行わせる、
ことを特徴とするストレージ制御方法。
【請求項５】
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、
前記複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築機能と、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築機能と、
前記第１及び第２の再構築機能を制御し、前記第２の再構築機能により前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築機能による該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、格納対象とする情報であるデータ及びパリティを複数の記憶装置（ストレージ）に分散して格納することにより冗長化を実現する技術に関する。
【背景技術】
【０００２】
近年、ストレージは大容量化し、そのストレージに蓄積されるデータ量は増大し続けている。それにより、サーバに搭載／接続されるストレージでは、重要なデータが失われる危険性を低減させるために、一般にＲＡＩＤ（Redundant Arrays of Inexpensive Disks）による冗長化が行われている。
【０００３】
ＲＡＩＤは、複数台のストレージ（ハードディスク装置等の記憶装置）を１台のストレージとして管理する技術である。高速性や安全性により、ＲＡＩＤ０からＲＡＩＤ６まで７つのレベルがある。最近では、２台のストレージの故障に対応可能なＲＡＩＤ６が注目されている。そのＲＡＩＤ６では、格納するデータから２種類のパリティを生成し、それらを分散（ストライピング）して複数台のストレージに格納する。
【０００４】
ストレージシステムの構築は通常、同じ時期に製造された同一モデルのストレージを用いて行われる。そのようにシステムを構築した場合、平均故障間隔(ＭＴＢＦ)等の特性はほぼ同じとなり、１台のストレージが故障すると、続けて別のストレージが故障する可能性が比較的に高い。ＲＡＩＤの再構築（リビルド）作業では、データの読み出しが連続的に発生して各ストレージへの負荷は高くなるために、ストレージが故障しやすい状態となる。このようなことから、ＲＡＩＤ５よりも信頼性の高いＲＡＩＤ６が注目されるようになってきている。ＲＡＩＤの再構築は、故障したストレージに予備用のストレージであるホットスペア（ＨＳ）を割り当て、故障したストレージに格納されていたデータ或いはパリティを未故障のストレージに格納されているデータ或いはパリティから復元し格納することで行われる。ここでは以降、ストレージに格納されるデータ及びパリティを「情報」と総称することとする。
【特許文献１】特開２００６−２５９８９４号公報
【特許文献２】特開平０３−２４０１２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ＲＡＩＤ６の再構築を行う従来のストレージ制御装置としては、特許文献１に記載されたものがある。その特許文献１に記載された従来のストレージ制御装置では、１台のストレージの再構築中に２台目のストレージが故障した場合、１台目のストレージに対して行っている再構築の進捗状況に応じて、２台のストレージを対象にした再構築を連携して行うことができるようになっている。既に再構築した部分（ストライプ）の再構築は行わないようにして、効率的に冗長性を回復できるようにしている。
【０００６】
しかし、２台のストレージを対象にした再構築を行っている間に、その２台のストレージに割り当てた２台のホットスペアのうちの１台が故障する可能性がある。このことから、ＲＡＩＤ６の再構築では、そのような場合にも適切に対応できるようにすることが重要と考えられる。
【０００７】
本発明は、故障した２台のストレージに再構築用に割り当てた２台のストレージ（ホットスペア）のうちの１台が再構築中に故障した場合の再構築を適切に行うための技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明のストレージ管理装置は、格納対象とする情報であるデータ及びパリティを複数の記憶装置（ストレージ）に分散して格納することにより冗長化を実現するものであり、複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築手段と、複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築手段と、第１及び第２の再構築手段を制御し、第２の再構築手段が再構築を行っている間に２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築手段に該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御手段と、を具備する。
【０００９】
なお、上記第２の再構築手段は、２台の予備記憶装置を連携させた再構築を行う場合、該再構築を早く開始した予備記憶装置を先行側、該再構築を遅く開始した予備記憶装置を追従側に設定し、該先行側で再構築が行われた部分のなかで該追従側が再構築を行っていない部分が無い状況になったとき、該追従側は該再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させる、ことが望ましい。再構築制御手段は、未故障の１台で再構築が終了した領域が連続しているか否かにより、２台の再構築処理の内容を変化させる、ことが望ましい。
【００１０】
本発明のストレージ制御方法は、格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するためのものであり、複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行い、再構築を行っている間に２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて該再構築を行わせる。
【００１１】
本発明のプログラムは、格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築機能と、複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築機能と、第１及び第２の再構築機能を制御し、第２の再構築機能により再構築を行っている間に２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築機能による該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御機能と、を実現させる。
【発明の効果】
【００１２】
本発明が適用されたＲＡＩＤ装置等のストレージシステムでは、複数の記憶装置（ストレージ）のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、その２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、その２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行い、その再構築を行っている間に２台の予備記憶装置のうちの１台が故障した場合に、故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて再構築を行わせる。このため、冗長化のためのグループに属するストレージが３台以上、故障したとしても、再構築が可能な状況であればその再構築を適切に行うことができる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態によるストレージ制御装置が適用されたＲＡＩＤ装置の構成を示す図である。そのＲＡＩＤ装置１は、例えばＵＮＩＸ（登録商標）サーバ或いはＩＡ（Intel Architecture）サーバがホスト・コンピュータ（以降「ホスト」）２として接続され、そのホスト２から受信したデータを冗長化して格納するものである。そのために、複数のＣＡ（Channel Adapter）１１、２つのＣＭ（Controller Module）１２、及び多数のハードディスク装置（ＨＤＤ）１３を備えている。
【００１４】
ＣＭ１２は、ホスト２からの指示に従って、ＨＤＤ１３にアクセスするものであり、ＣＰＵ１２１、フラッシュ（Ｆｌａｓｈ）メモリ１２２、キャッシュメモリ１２３、２つのディスクＩ／Ｆアダプタ（以降「ＤＩ」）１２４、及び他のＣＭ１２との通信用アダプタ１２５を備えている。フラッシュメモリ１２２にはＣＰＵ１２１が実行するプログラムが格納されており、ＣＰＵ１２１はそのプログラムをキャッシュメモリ１２３に読み出して実行することにより制御を行う。本実施形態によるストレージ制御装置は、そのＣＭ１２上で実現されている。
【００１５】
なお、このプログラムは、別のフラッシュメモリ、光ディスク、或いは可搬性のＨＤＤ等に記録して配布しても良い。通信ネットワークを介して取得するようにしても良い。再構築の対象とするストレージは、ＨＤＤ１３とは異なる種類であっても良く、複種類であっても良い。
【００１６】
図２は、ＣＭ１３の機能構成図である。
そのＣＭ１３は、通信部２０１、システム制御部２０２、冗長化部２０３、アクセス部２０４、リビルド制御部２０５、スケジュール管理部２０６、及びリビルド実行部２０７を備えている。
【００１７】
通信部２０１は、ホスト２或いは他のＣＭ１２との間で通信を行うものである。システム制御部２０２は、ＣＭ１２全体の制御を行うものである。情報（データ或いはパリティ）を分散して格納するＨＤＤ１３はグループとして管理され、そのグループ（ＲＡＩＤグループ）を構成するＨＤＤ１３の組み合わせは、そのグループを構成するＨＤＤ１３の故障によって変更される。その管理・変更は、システム制御部２０２に搭載されたグループ状態変更部２０２ａによって行われる。
【００１８】
冗長化部２０３は、システム制御部２０２からＨＤＤ１３に格納するデータを受け取ってパリティを生成し、生成したパリティをデータと共に分散してＨＤＤ１３（ＲＡＩＤグループ）に格納する。アクセス部２０４は、実際にＨＤＤ１３にアクセスするものである。このため、情報のＨＤＤ１３への格納、及び読み出しはアクセス部１０４を介して行われる。
【００１９】
リビルド実行部２０７は、故障したＨＤＤ１３に格納されていた情報を同じＲＡＩＤグループに属する未故障のＨＤＤ１３に格納されている情報から復元し、復元した情報を故障したＨＤＤ１３に代替用に割り当てられた予備のＨＤＤ１３であるホットスペア（ＨＳ）に格納するリビルドを実行する。その実行はストライプ単位で行う。情報の読み出し、及び格納はアクセス部２０４を介して行う。
【００２０】
リビルド制御部２０５は、故障したＨＤＤ１３のリビルド（再構築）の実施、つまりリビルド実行部２０７の動作を制御する。スケジュール管理部２０６は、ＨＤＤ１３のリビルドを実施するスケジュールを管理する。
【００２１】
上記各部２０１〜２０７は、ＣＰＵ１２１がフラッシュメモリ１２２に格納されたプログラムを実行することにより実現される。それにより、ホスト２からの要求に対応するための動作を可能とし、ＨＤＤ１３の故障時には再構築を自動的に行う。
【００２２】
図１に示すキャッシュメモリ１２３には、データの冗長化のためにデータ・バッファ１２３ａが確保されている。そのメモリ１２３に確保された制御テーブルエリア１２３ｂは、図３及び図４にそれぞれ示すテーブルを格納するためのものである。以降は、図３〜図６を参照して、本実施形態で行われるＲＡＩＤ６の再構築処理について具体的に説明する。
【００２３】
図５は、ＲＡＩＤ６のステータス遷移図である。同じＲＡＩＤグループに属するＨＤＤ１３のなかで故障したＨＤＤ１３の発生、その再構築の終了に伴う状態（ステータス）遷移を示したものである。
【００２４】
図５に示すように、正常状態ＳＴ１で１台目のＨＤＤ（図中「Ｄｉｓｋ」）１３の故障により、１台のＨＤＤ１３が故障しているＰａｒｔｉａｌｙ  Ｅｘｐｏｓｅｄ状態ＳＴ２に遷移する。その後は、１台のＨＤＤ１３を再構築するＰａｒｔｉａｌｙ  Ｅｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ３に遷移する。その再構築を終了すると、正常状態ＳＴ１に遷移し、その再構築中に別の１台、つまり２台目が故障すると、２台のＨＤＤ１３が故障しているＥｘｐｏｓｅｄ状態ＳＴ４に遷移する。そのＥｘｐｏｓｅｄ状態ＳＴ４に遷移した後は、２台のＨＤＤ１３を再構築するＥｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ５に遷移する。
【００２５】
２台のＨＤＤ１３を再構築中に、復元した情報を格納する２台のＨＳのうちの何れかが故障する場合がある。その故障が発生した場合、つまり３台目のＨＤＤ１３が故障した場合、Ｅｘｐｏｓｅｄ状態ＳＴ４に遷移する。それにより、故障したＨＳ（ＨＤＤ１３）を別のＨＳに代えて、２台のＨＤＤ１３を再構築するＥｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ５に遷移する。そのようにして本実施形態では、ＨＳの故障（３台目以上の故障）によりＥｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ５からＥｘｐｏｓｅｄ状態ＳＴ４に遷移させることにより、再構築に用いている２台のＨＳの故障に対応するようにしている。１台分の再構築が終了した場合には、つまり再構築すべきＨＤＤ１３が残り１台となった場合には、Ｐａｒｔｉａｌｙ  Ｅｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ３に遷移する。
【００２６】
図６は、２台のＨＤＤ１３の再構築中に１台のＨＳが故障した場合に行われる再構築処理を示す図である。図６（ａ）は、未故障のＨＳで再構築が終了した領域が連続していないケースで行われる再構築処理を示し、図６（ｂ）は、その領域が連続しているケースで行われる再構築処理を示している。
【００２７】
図６において、Ｄ０〜Ｄ３は情報として格納されるデータ、Ｐ−Ｐ及びＰ−Ｑは情報として格納される２種類のパリティをそれぞれ示している。それにより、ＲＡＩＤグループは未故障の６台（データ格納用に４台、パリティ格納用に２台の計６台）のＨＤＤ１３から構成されることを表している。ＨＳ０〜ＨＳ２は、故障したＨＤＤ１３（ここではＨＳを含む）の再構築用に割り当てられたＨＳを示している。以降、便宜的に、図６（ａ）或いは（ｂ）を参照、或いは想定して説明する場合、Ｄ０〜Ｄ３、Ｐ−Ｐ、Ｐ−Ｑ、及びＨＳ０〜ＨＳ２はそれぞれＨＤＤ１３を指す符号として用いることとする。そのことを明確にするために、ＨＤＤ１３は「ディスク」と表記する。
【００２８】
ＨＳが故障（３台目以上のＨＤＤ１３が故障）した場合の再構築処理を説明する前に、２台のＨＤＤ１３が故障した場合（普通は１台の再構築中に別の１台が故障した場合である）の再構築処理について簡単に説明する。
【００２９】
２台のＨＤＤ１３が故障した場合の再構築処理は、特許文献１に記載された方法により行われる。
２台目のＨＤＤ１３が故障するまでの間に、１台目に故障したＨＤＤ１３の再構築が進行、つまりそのＨＤＤ１３に割り当てたＨＳに復元した情報が格納される領域が拡大する。再構築が済んだ部分は、１台分の再構築のみを行えば良く、その再構築が済んでいない部分（２重故障部分）は、２台分の再構築を行う必要がある。このことから、２台分の再構築を行う必要の有無により、再構築を行う部分、つまり復元した情報を格納する領域を分けて再構築を行っている。それにより図６（ａ）では、１台目のＨＤＤ１３であるディスクＤ１の故障によりディスクＨＳ０を用いた再構築を「ｆｏｌｌｏｗ＿ｅｎｄ」で示す位置まで行ったときにディスクＤ３が故障したことを表している。その２台目の故障により、ｆｏｌｌｏｗ＿ｅｎｄ以降はディスクＨＳ０及びＨＳ１を用いた２台の再構築を連携させて行い、ディスクＨＳ１のｆｏｌｌｏｗ＿ｅｎｄまでの再構築は１台のみの再構築として行っていることを表している。
【００３０】
上記のように２台の再構築を行う場合、３台目以上のＨＤＤ１３（ＨＳ）が故障したときの未故障のＨＤＤ１３（ＨＳ）の再構築状況は、再構築を行った領域（済み領域）が連続している状況（図６（ｂ））、及びその済み領域が連続していない状況（図６（ａ））、つまり済み領域と再構築を行っていない領域である未済み領域とが交互に連続している状況に大別される。以降、前者は「済み領域連続状況」、後者は済み領域非連続状況」とそれぞれ呼ぶことにする。
【００３１】
本実施形態では、３台目以上のＨＤＤ１３（ＨＳ）の故障時に済み領域非連続状況であった場合、未故障のＨＤＤ１３（ＨＳ）を用いた再構築は未終了の領域のみを対象にして行い、新たに割り当てたＨＳ（図６（ａ）（及び図６（ｂ））ではディスクＨＳ２）はその先頭から再構築を行う。それにより、２台の再構築は連携させない。図６（ａ）ではそのことを示している。
【００３２】
一方、３台目以上のＨＤＤ１３（ＨＳ）の故障時に済み領域連続状況であった場合には、未故障のＨＤＤ１３（ＨＳ）を用いた再構築は未終了の領域のみを対象にして、新たに割り当てたＨＳと連携させて行い、その新たに割り当てたＨＳで連携の対象とならない部分は別に再構築を行う。それにより、新たに割り当てたＨＳでは２種類の再構築を並行して行う。図６（ｂ）ではそのことを示している。
【００３３】
このようにして本実施形態では、３台目以上のＨＤＤ１３（ＨＳ）が故障した場合、未故障のＨＳの再構築状況が済み領域連続状況か否かに係わらず、未故障のＨＳを用いた再構築はそれが済んでいない未済み領域のみを対象にして行うようにしている。それにより、短時間に冗長性を回復できるようにしている。
【００３４】
再構築状況が済み領域非連続状況であった場合、新たに割り当てたＨＳの再構築は連携させずに行うようにしている。これは、再構築処理の制御が複雑化するのを抑えるということの他に、再構築を実施する際に発生するシーク時間の増大を抑えるためである。そのシーク時間の増大を抑えることにより、再構築もより短い時間で完了させることができるようになる。
【００３５】
上述したような再構築処理を行うために、本実施形態では、ＨＤＤ１３毎に管理用のテーブル（以降「構成テーブル」）を用意し、再構築実施用に別のテーブル（以降「リビルド制御テーブル」）をＨＤＤ１３の故障により用意するようにしている。図１のキャッシュメモリ１２３に確保した制御テーブルエリア１２３ｂには、それらテーブルが格納される。それらのテーブルについて、図３及び図４を参照して具体的に説明する。
【００３６】
図３は、構成テーブルの構成を示す図である。その構成テーブルは、ＲＡＩＤ装置１に搭載されたＨＤＤ１３毎に用意され、各種パラメータが格納される。図中、再構築に特に関係しないパラメータは「ｒｅｓｅｒｖｅ」と表記している。それにより以降、ｒｅｓｅｒｖｅと表記していないパラメータについてのみ説明する。テーブルの横に表記した「０ｘ００」「０ｘ０４」等は、相対アドレスの値を示している。
【００３７】
「Ｓｔａｔｕｓ」は、対応するＨＤＤ１３の状態を示すパラメータである。そのパラメータにより、例えば正常状態、故障状態、及び再構築中状態を認識可能とさせている。「ＰＬＵＮ」は、対応するＨＤＤ１３に割り当てられた識別用の番号（ディスク番号）である。「ＲＬＵＮ」は、対応するＨＤＤ１３が属するＲＡＩＤグループに割り当てられた識別用の番号（グループ番号）である。
【００３８】
「Ｂｌｏｃｋ  Ｃｏｕｎｔ」は、対応するＨＤＤ１３の記憶容量を示すパラメータである。ＨＤＤ１３では普通、全てのセクタに通し番号を振り、その通し番号によってセクタを指定できるＬＢＡ（Logical Block Addressing）方式が採用される。そのパラメータは、例えばＬＢＡ方式により記憶容量を示すものである。その場合、その値は最後のセクタに割り当てられたセクタ番号に１を加算して得られるものである。以降、ＬＢＡ方式を採用していることを前提として説明を行う。
【００３９】
「ｒｅｂｕｉｌｄ＿ｐｌｂａ」は、再構築実施時にその再構築が終了した位置を示すパラメータである。その位置はセクタ番号により示される。「Ｒｅｂｕｉｌｄ  Ｂｌｏｃｋ
Ｃｏｕｎｔ」は、１回の処理単位、つまり１スプライト分の記憶容量を示すパラメータである。その記憶容量はセクタ数により表現された値である。以降、その処理単位は「ブロック」と呼ぶことにする。
【００４０】
「ｒｅｂｕｉｌｄ＿ｐａｉｒ＿ｐｌｕｎ」は、再構築を連携させるＨＤＤ１３のディスク番号を示すパラメータである。初期値は「０ｘｆｆｆｆ」である。再構築の連携は、２台のうちで再構築を早く開始した方を先行側、他方を追従側に設定して行われる。このパラメータは、先行側のみ設定される。「ｒｅｂｕｉｌｄ＿ｍｏｄｅ」は、連携した再構築を行っているか否かを示すパラメータである。その初期値は０であり、連携させた再構築を行う場合に「１」となる。このパラメータも先行側のみ設定される。
【００４１】
「ｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａ」は、再構築の連携を開始させる位置を示すパラメータである。このパラメータは、追従側のみ設定される。初期値は「０ｘｆｆｆｆｆｆｆｆ」である。「ｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａ」は、追従側のみ設定される、追従側で再構築が終了した位置を示すパラメータである。初期値は「０ｘｆｆｆｆｆｆｆｆ」である。
【００４２】
上記パラメータのなかで、「ｒｅｂｕｉｌｄ＿ｐａｉｒ＿ｐｌｕｎ」「ｒｅｂｕｉｌｄ＿ｍｏｄｅ」「ｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａ」及び「ｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａ」は、２台の再構築を連携させるために設定される。このことから、それらを「連携パラメータ」と総称する。
【００４３】
図６（ａ）及び（ｂ）に表記の「ｒｅｂｕｉｌｄ＿ｐｌｂａ」や「ｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａ」、及び「ｆｏｌｌｏｗ＿ｅｎｄ」等は、図３に示すパラメータ名、或いはその略記である。それにより、ディスクＨＳ０の故障時に設定されていた各パラメータの内容、及び新たに割り当てたディスクＨＳ２で設定される各パラメータの内容を表している。
【００４４】
図４は、リビルド制御テーブルの構成を示す図である。その制御テーブルは、再構築の対象となるＨＤＤ１３毎に用意され、実際の再構築はこの制御テーブルを参照して行われる。図３と同様に、ｒｅｓｅｒｖｅと表記していないパラメータについてのみ説明する。テーブルの横に表記した「０ｘ００」「０ｘ０４」等は、図３と同じく相対アドレスの値を示している。
【００４５】
「ＲＬＵＮ」は、故障したＨＤＤ１３に割り当てられたＨＳが属することになるＲＡＩＤグループのグループ番号である。「復元先ＰＬＵＮ」は割り当てられたＨＳのディスク番号である。「復元元ＰＬＵＮ」は故障したＨＤＤ１３（ＨＳ）のディスク番号である。「ｐｒｅｖｉｏｕｓ＿ａｃｂ＿ａｄｄｒｅｓｓ」は、一つ前の制御テーブルが格納された先頭アドレスを示すパラメータであり、「ｎｅｘｔ＿ａｃｂ＿ａｄｄｒｅｓｓ」は、一つ後の制御テーブルが格納された先頭アドレスを示すパラメータである。これら２つのパラメータにより、リビルド制御テーブルは順次、参照していくようにしている。一つ前、或いは一つ後の制御テーブルが存在しない場合はＮＵＬＬで表現される。
【００４６】
「ｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｌｂａ」は次に再構築の対象となるブロックの先頭のセクタ番号を示すパラメータである。「ｐｌｕｒａｌ＿ｒｅｂｕｉｌｄ＿ｅｘｅ」は、再構築を行うモードを示すパラメータである。そのパラメータにより示されるモードは、１台の再構築を行うモード（以降「独立モード」）、及び２台の再構築を連携して行うモード（以降「連携モード」）のうちの何れかである。独立モード時の値は０。連携モード時の値は１である。
【００４７】
本実施形態では、再構築を行うべき部分（ストライプ）の再構築は先行側→追従側の順序で行うようにしている。それにより、先行側で再構築が行われた部分（ストライプ）のなかで追従側が再構築を行っていない部分が無い状況となると、再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させるようにしている。「ｒｅｂｕｉｌｄ＿ｓｌｅｅｐ」は、スリープ状態か否かを示すパラメータである。その値は、スリープ状態でない時には０、その状態時には１である。「ａｗａｋｅｎ＿ｎｅｅｄ」は、連携を解除する際に追従側のスリープ状態を解除する必要性の有無を示すパラメータである。その値は、解除の必要性がないときには０、その必要があるときには１である。
【００４８】
図６（ａ）に示すように、ディスクＨＳ０及びＨＳ１を用いて２台分の再構築を行う場合、ディスクＨＳ１では２重故障部分以外は独立モードで再構築を行う。このため、ディスクＨＳ１では、独立モード及び連携モードの２つのモードで再構築が行われる。それにより、リビルド制御テーブルは２つ用意される。
【００４９】
次に、図７〜図１２に示す各処理のフローチャートを参照して、故障の発生時のＣＭ１２の動作について詳細に説明する。その各処理、及び図３及び図４にそれぞれ示すテーブルの管理は、ＣＰＵ１２１がフラッシュメモリ１２２に格納されているプログラムを実行することで実現される。
【００５０】
図７は、復旧処理のフローチャートである。その復旧処理は、ＨＤＤ１３の故障の発生を契機にして、その発生から復旧が完了するまでの間に実行される主な処理を抜粋してまとめたものである。始めに図７を参照して、その復旧処理について詳細に説明する。
【００５１】
先ず、ステップＳ１では、新たな故障の発生に対応するための開始処理を実行する。その開始処理の実行により、故障したＨＤＤ１３の構成テーブルは初期設定され、リビルド制御テーブルの生成、或いは消去が行われる。
【００５２】
ステップＳ１に続くステップＳ２では、リビルド制御テーブルを選択する。その後に移
行するステップＳ３では、選択したリビルド制御テーブルが追従側のＨＤＤ１３用のものか否か判定する。その制御テーブル中のｐｌｕｒａｌ＿ｒｅｂｕｉｌｄ＿ｅｘｅの値が連携モードを示す１であり、且つ復元先ＰＬＵＮから特定される構成テーブルに格納されているｒｅｂｕｉｌｄ＿ｍｏｄｅの値が初期値の０であった場合、選択した制御テーブルは追従側のＨＤＤ１３用であることから、判定はＹＥＳとなってステップＳ１０に移行する。そうでない場合には、つまり選択した制御テーブルが先行側のもの、或いは連携させない独立モードのものであった場合には、判定はＮＯとなってステップＳ４に移行する。
【００５３】
ステップＳ４では、再構築を行う範囲を設定する。このとき設定される範囲は、選択したリビルド制御テーブル中のｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｌｂａが示すセクタを先頭とし、その先頭から構成テーブル中のＲｅｂｕｉｌｄ  Ｂｌｏｃｋ  Ｃｏｕｎｔが示すセクタ数分の領域である。そのような範囲を設定した後はステップＳ５に移行して、その範囲の再構築（復元）を行うための再構築処理を実行する。その再構築は周知の方法を用いて行うため、詳細な説明は省略する。その再構築処理の実行後はステップＳ６に移行する。
【００５４】
ステップＳ６では、次の再構築処理のための第１の後処理を実行する。続くステップＳ７では、追従側のスリープ状態を必要に応じて解除するためのスリープ解除処理を実行する。その実行後は、ステップＳ８に移行して、新たな故障が発生したか否か判定する。その故障が発生した場合、判定はＹＥＳとなって上記ステップＳ１に戻る。そうでない場合には、判定はＮＯとなり、ステップＳ９に移行する。なお、故障が発生したか否かの判定は、ＤＩ１２４を介してＨＤＤ１３に行われるアクセスをＣＰＵ１２１が監視することで行われる。
【００５５】
ステップＳ９では、再構築が全て完了したか否か判定する。本実施形態では、再構築が完了したＨＤＤ１３ではリビルド制御テーブルを消去するようにしている。このため、例ビルド制御テーブルが存在しない場合、判定はＹＥＳとなり、ここで復旧処理を終了する。そうでない場合には、判定はＮＯとなり、上記ステップＳ２に戻って制御テーブルの選択を行う。
【００５６】
上記ステップＳ３の判定がＹＥＳとなって移行するステップＳ１０では、選択したリビルド制御テーブル中のｒｅｂｕｉｌｄ＿ｓｌｅｅｐの値がスリープ状態を示すものか否か判定する。その値がスリープ状態を示す１であった場合、判定はＹＥＳとなって上記ステップＳ８に移行する。そうでない場合には、つまりその値が０であった場合には、判定はＮＯとなってステップＳ１１に移行する。
【００５７】
ステップＳ１１では、上記ステップＳ４と同様に、再構築を行う範囲を設定する。続くステップＳ１２では、設定した範囲の再構築（復元）を行うための再構築処理を実行する。その後は、次の再構築処理のための第２の後処理をステップＳ１３で実行し、更にスリープ状態を必要に応じて設定するためのスリープ設定処理をステップＳ１４で実行してから上記ステップＳ８に移行する。
【００５８】
以降は、上記復旧処理内で実行される各種サブルーチン処理について詳細に説明する。
図８は、上記ステップＳ１として実行される開始処理のフローチャートである。始めに図８を参照して、その開始処理について詳細に説明する。
【００５９】
先ず、ステップＳ２１では、故障したＨＤＤ１３に設定されているＲＡＩＤレベルがＲＡＩＤ６か否か判定する。そのＲＡＩＤレベルは、ＲＡＩＤグループの管理用テーブルにより管理している。そのため、その管理用テーブルにＲＡＩＤレベルとしてＲＡＩＤ６が設定されていた場合、判定はＹＥＳとなってステップＳ２３に移行する。そうでない場合には、つまり例えばＲＡＩＤ１或いはＲＡＩＤ５等が設定されていた場合には、判定はＮ
ＯとなってステップＳ２２に移行し、設定されたＲＡＩＤレベルに応じて再構築を実行するための設定を行う。その後に開始処理を終了する。
【００６０】
ステップＳ２３では、新たに発生した故障によって遷移させるべき状態の判定を行う。続くステップＳ２４では、その状態が１台の再構築を行うＰａｒｔｉａｌｙ  Ｅｘｐｏｓｅｄ  Ｒｅｂｕｉｌｄ状態ＳＴ３に遷移させるべきものであった場合、つまり故障したＨＤＤ１３が属するＲＡＩＤグループで再構築が必要なＨＤＤ１３が１台であった場合、判定はＹＥＳとなってステップＳ２５に移行し、再構築処理を実施するための準備を行った後、開始処理を終了する。
【００６１】
この準備では、ｐｌｕｒａｌ＿ｒｅｂｕｉｌｄ＿ｅｘｅの値を０（初期値）としたリビルド制御テーブルが生成される。復元先ＰＬＵＮには再構築用に割り当てられたＨＤＤ１３（ＨＳ）のディスク番号、復元元ＰＬＵＮには故障したＨＤＤ１３のディスク番号がそれぞれ設定される。再構築に割り当てられたＨＤＤ１３の構成テーブルでは、Ｓｔａｔｕｓは再構築中を示す値に、ＲＬＵＮは故障したＨＤＤ１３が属するＲＡＩＤグループを示す番号にそれぞれ更新される。故障したＨＤＤ１３の構成テーブル中のＳｔａｔｕｓは故障中を示す値に更新される。
【００６２】
ＲＡＩＤ６では、情報の格納に用いているＨＤＤ１３が１度に３台以上、故障すると、言い換えれば３台以上の再構築を行うべき状況となると、再構築を行えなくなる。このため、特には図示していないが、上記ステップＳ２３では、新たな故障によってそのような状況となったか否か判定することにより、そのような状況となったＲＡＩＤグループでの再構築を終了させるための処理を行うようになっている。
【００６３】
一方、ステップＳ２６では、ＲＡＩＤグループでの故障により再構築すべきＨＤＤ１３は２台となったか否か判定する。図６（ａ）及び（ｂ）に示すように、ディスクＤ１の再構築中にディスクＤ３が故障したような場合、判定はＹＥＳとなってステップＳ２７に移行する。そうでない場合には、つまり図６（ａ）及び（ｂ）に示すように、２台のＨＳを用いた再構築中にその１台が故障することで故障代数が３台以上となった場合には、判定はＮＯとなってステップＳ２９に移行する。
【００６４】
ステップＳ２７では、上記ステップＳ２５と同様に、リビルド制御テーブルを生成する。その制御テーブルでは、ｐｌｕｒａｌ＿ｒｅｂｕｉｌｄ＿ｅｘｅの値を１とし、生成済みの制御テーブル中のｐｌｕｒａｌ＿ｒｅｂｕｉｌｄ＿ｅｘｅの値は１に更新する。構成テーブルでは、Ｓｔａｔｕｓ及びＲＬＵＮを更新する。そのような更新を行った後はステップＳ２８に移行して、先行側と共に、構成テーブル中の連携パラメータを更新する。その後、この開始処理を終了する。
【００６５】
連携パラメータの更新は、先行側では、ｒｅｂｕｉｌｄ＿ｐａｉｒ＿ｐｌｕｎに追従側のＨＤＤ１３のディスク番号、ｒｅｂｕｉｌｄ＿ｍｏｄｅに１をそれぞれ設定することで行われる。追従側では、ｒｅｂｕｉｌｄ＿ｐａｉｒ＿ｐｌｕｎに先行側のＨＤＤ１３のディスク番号、ｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａに先行側のｒｅｂｕｉｌｄ＿ｐｌｂａの値をそれぞれ設定することで行われる。
【００６６】
ステップＳ２９では、故障したＨＤＤ１３（ＨＳ）を用いた再構築用に作成済みのリビルド制御テーブルを消去し、そのＨＤＤ１３を再構築するためのリビルド制御テーブルを生成して、２つの構成テーブルの更新を行う。次のステップＳ３０では、その２つの構成テーブル中の連携パラメータの更新を必要に応じて行う。その後、この開始処理を終了する。
【００６７】
ここでは、２台のＨＳのなかで故障しなかった方の再構築状況の判定を行い、リビルド制御テーブルが生成される。図６（ａ）に示すように、再構築状況が済み領域非連続状況であった場合、独立モードで再構築を行うためのリビルド制御テーブルが生成され、故障しなかった方の連携モードが設定されたリビルド制御テーブルでは、その連携モードに代わって独立モードが設定される。それにより、その方（図６（ａ）ではディスクＨＳ１が相当）を用いた再構築は以降２つの独立モードで行う。その方の構成テーブルでは、連携パラメータはｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａを除き全て初期値に更新される。故障したＨＤＤ１３（ＨＳ）に割り当てたＨＤＤ１３（ＨＳ）側では連携パラメータは初期値のままとなる。ｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａを初期値に更新しないのは、既に再構築済みの領域を再度、再構築するのを回避するためである。
【００６８】
一方、図６（ｂ）に示すように、再構築状況が済み領域連続状況であった場合、独立モード、連携モードのそれぞれで再構築を行うために２つのリビルド制御テーブルが生成され、故障しなかった方のリビルド制御テーブルの更新は行われない。その方（先行側）の連携パラメータでは、ｒｅｂｕｉｌｄ＿ｍｏｄｅの値は１に更新され、他は初期値に更新される。故障したＨＤＤ１３（ＨＳ）に割り当てたＨＤＤ１３（追従側）では、ｒｅｂｕｉｌｄ＿ｐａｉｒ＿ｐｌｕｎは先行側のディスク番号に更新され、ｒｅｂｕｉｌｄ＿ｆｏｌｌｏｗ＿ｅｎｄ＿ｐｌｂａは先行側のｒｅｂｕｉｌｄ＿ｐｌｂａの値に更新される。
【００６９】
このようにして開始処理では、新たな故障が発生した時点の状況に応じてリビルド制御テーブルの生成、或いは消去、及び構成テーブルの更新が行われる。それにより、それらのテーブルを参照して再構築を実施するための準備が行われる。
【００７０】
図９は、図７に示す復旧処理内でステップＳ６として実行される第１の後処理のフローチャートである。次に図９を参照して、その後処理について詳細に説明する。
再構築は、上述したように、リビルド制御テーブル、及び構成テーブルを参照して行われる。この第１の後処理は、先行側、或いは独立モードで１回の再構築処理を行ったことに合わせて、それらのテーブルを更新するために行われる。
【００７１】
先ず、ステップＳ４１では、直前に実行した再構築処理は先行側用のものか否か判定する。その再構築処理が先行側用のものであった場合、判定はＹＥＳとなってステップＳ４５に移行し、進捗を更新する。それにより、構成テーブル中のｒｅｂｕｉｌｄ＿ｐｌｂａ、及び／或いは、リビルド制御テーブル中のｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａは、次の再構築を開始すべきセクタを示す値（セクタ番号）に更新する。その後、この第１の後処理を終了する。一方、そうでない場合には、判定はＮＯとなり、次にステップＳ４２で同様に進捗を更新した後、ステップＳ４３に移行する。
【００７２】
図６（ａ）に示すように、ディスクＨＳ０が故障すると、ディスクＨＳ１では２つの独立モードで再構築が行われる。ｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａ以降の再構築の進捗は、リビルド制御テーブル中のｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａで管理するようになっている。ｒｅｂｕｉｌｄ＿ｐｌｂａは他の独立モードによる再構築に用いているために更新は行わない。
【００７３】
ステップＳ４３では、更新後のｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａが示す位置が最終の位置か否か判定する。設定されたモードでの再構築が終了した場合、それらの位置が一致することから、判定はＹＥＳとなってステップＳ４４に移行し、リビルド制御テーブルを消去し、構成テーブルを初期状態に更新した後、この第１の後処理を終了する。そうでない場合には、判定はＮＯとなり、ここでこの第１の後処理を終了する。
【００７４】
最終の位置は、通常はＢｌｏｃｋ  Ｃｏｕｎｔが示す位置である（このため図中に表記
）。しかし、図６（ａ）に示すディスクＨＳ１では、ｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａとなる場合がある。Ｂｌｏｃｋ  Ｃｏｕｎｔ及びｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａを対象とした最終の位置の選択は、ｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａが示す位置により行っている。ｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａの示す位置がｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａの示す位置以前であれば、最終の位置としてｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａの示す位置が選択される。
【００７５】
図１０は、図７に示す復旧処理内でステップＳ７として実行されるスリープ解除処理のフローチャートである。次に図１０を参照して、その解除処理について詳細に説明する。その解除処理は、上述したように、追従側のスリープ状態を解除するために実行される。
【００７６】
先ず、ステップＳ５１では、リビルド制御テーブル中のａｗａｋｅｎ＿ｎｅｅｄの値が０か否か判定する。その値が０、つまり追従側のスリープ状態を解除する必要が無い場合、判定はＹＥＳとなり、ここでスリープ解除処理を終了する。そうでない場合には、判定はＮＯとなり、ステップＳ５２に移行する。
【００７７】
ステップＳ５２では、追従側のリビルド制御テーブルを検索して抽出する。続くステップＳ５３では、その制御テーブル中のｒｅｂｕｉｌｄ＿ｓｌｅｅｐの値が０、つまり追従側がスリープ状態となっていないか否か判定する。追従側がスリープ状態でなかった場合、判定はＹＥＳとなり、ここでスリープ解除処理を終了する。そうでない場合には、判定はＮＯとなり、ステップＳ５４でスリープ状態を解除、つまりｒｅｂｕｉｌｄ＿ｓｌｅｅｐの値を０に更新してから、このスリープ解除処理を終了する。
【００７８】
図１１は、図７に示す復旧処理内でステップＳ１３として実行される第２の後処理のフローチャートである。次に図１３を参照して、その後処理について詳細に説明する。
先ず、ステップＳ６１では、進捗を更新する。それにより、構成テーブル中のｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａ、及び、リビルド制御テーブル中のｒｅｂｕｉｌｄ＿ｓｔａｒｔ＿ｐｌｂａは、次の再構築を開始すべきセクタを示す値（セクタ番号）に更新する。その更新後はステップＳ６２に移行する。
【００７９】
ステップＳ６２では、更新後のｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａの示す位置が再構築の最終位置（図中「最終ＬＢＡ」と表記）か否か判定する。それらの位置が一致、即ちｒｅｂｕｉｌｄ＿ｐｌｕｒａｌ＿ｐｌｂａの示す位置がＢｌｏｃｋ  Ｃｏｕｎｔの示す位置と一致する場合、判定はＹＥＳとなってステップＳ６３に移行し、追従側、及び先行側のリビルド制御テーブルを共に消去し、各構成テーブルの連携パラメータを初期値に更新した後、この第２の後処理を終了する。そうでない場合には、判定はＮＯとなり、ここでこの第２の後処理を終了する。
【００８０】
図１２は、図７に示す復旧処理内でステップＳ１４として実行されるスリープ設定処理のフローチャートである。最後に図１２を参照して、その設定処理について詳細に説明する。本実施形態では、先行側の再構築が終了した位置まで追従側の再構築が進捗することを条件にスリープ状態に移行させるようにしている。
【００８１】
先ず、ステップＳ７１では、先行側のリビルド制御テーブルが存在するか否か判定する。その制御テーブルが存在する場合、判定はＹＥＳとなってステップＳ７２に移行する。そうでない場合には、判定はＮＯとなり、スリープ状態を設定する必要はないとして、ここでスリープ設定処理を終了する。
【００８２】
ステップＳ７２では、上記条件が満たされているか否か判定する。その条件が満たされている場合、判定はＹＥＳとなり、ステップＳ７３でリビルド制御テーブル中のｒｅｂｕ
ｉｌｄ＿ｓｌｅｅｐの値を１に更新してスリープ状態を設定した後、このスリープ設定処理を終了する。そうでない場合には、判定はＮＯとなり、ここでこのスリープ設定処理を終了する。
【００８３】
なお、本実施形態では、２台の再構築中にそのうちの１台が故障した場合、未故障のＨＤＤ１３（ＨＳ）の再構築状況に応じて、２台の再構築を行う方法を異ならせるようにしているが、同一の方法により再構築を行うようにしても良い。また、再構築を行う位置が異なることで発生するシーク時間を考慮して、その方法を異ならせるようにしても良い。また、１台の再構築を連携モード及び独立モードで行う場合、例えば連携モード（２重故障部分の再構築）を優先して行い、その終了後に独立モードの再構築を行うといったような優先関係を設定しても良い。再構築に用いる情報（パラメータ）は構成テーブル及びリビルド制御テーブル等により管理しているが、その情報の管理方法は特に限定されるものではない。
【００８４】
上述の実施形態に関し、更に以下の付記を開示する。
（付記１）
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置において、
前記複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築手段と、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築手段と、
前記第１及び第２の再構築手段を制御し、前記第２の再構築手段が前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築手段に該再構築を行わせる再構築制御手段と、
を具備することを特徴とするストレージ制御装置。
【００８５】
（付記２）
前記再構築制御手段は、前記２台の予備記憶装置のうちの１台が故障した場合、未故障の１台の再構築の進捗状況に応じて、前記第２の再構築手段による２台の再構築処理の内容を変化させる、
ことを特徴とする付記１記載のストレージ制御装置。
【００８６】
（付記３）
前記再構築制御手段は、前記未故障の１台で前記再構築が終了した領域が連続しているか否かにより、前記２台の再構築処理の内容を変化させる、
ことを特徴とする付記２記載のストレージ制御装置。
【００８７】
（付記４）
前記再構築制御手段は、前記未故障の１台で前記再構築が終了した領域が連続していない場合、前記第２の再構築手段により前記２台の再構築処理を独立させて行う、
ことを特徴とする付記３記載のストレージ制御装置。
【００８８】
（付記５）
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御方法において、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行い、
前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該再構築を行わせる、
ことを特徴とするストレージ制御方法。
【００８９】
（付記６）
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、
前記複数の記憶装置のなかで故障した１台の記憶装置に格納されていた情報を、該１台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該１台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第１の再構築機能と、
前記複数の記憶装置のなかで故障した２台の記憶装置にそれぞれ格納されていた情報を、該２台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該２台の記憶装置の代替とする２台の予備記憶装置に格納することにより再構築を行う第２の再構築機能と、
前記第１及び第２の再構築機能を制御し、前記第２の再構築機能により前記再構築を行っている間に前記２台の予備記憶装置のうちの１台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第２の再構築機能による該再構築を行わせる再構築制御機能と、
を実現させるためのプログラム。
【図面の簡単な説明】
【００９０】
【図１】本実施形態によるストレージ制御装置が適用されたＲＡＩＤ装置の構成を示す図である。
【図２】本実施形態によるストレージ制御装置が適用されたＲＡＩＤ装置に搭載されているＣＭ１３の機能構成図である。
【図３】構成テーブルの構成を示す図である。
【図４】リビルド制御テーブルの構成を示す図である。
【図５】ＲＡＩＤ６のステータス遷移図である。
【図６】２台のＨＤＤ１３の再構築中に１台のＨＳが故障した場合に行われる再構築処理を示す図である。
【図７】復旧処理のフローチャートである。
【図８】開始処理のフローチャートである。
【図９】第１の後処理のフローチャートである。
【図１０】スリープ解除処理のフローチャートである。
【図１１】第２の後処理のフローチャートである。
【図１２】スリープ設定処理のフローチャートである。
【符号の説明】
【００９１】
１      ＲＡＩＤ装置
２      ホスト・コンピュータ
１１      ＣＡ（Channel Adapter）
１２      ＣＭ（ControllerModule）
１３      ハードディスク装置（ＨＤＤ）
１２１      ＣＰＵ
１２２      フラッシュメモリ
１２３      キャッシュメモリ
１２４      ディスクＩ／Ｆアダプタ
【図１】
0004499776.tif 000002
【図２】
0004499776.tif 000003
【図３】
0004499776.tif 000004
【図４】
0004499776.tif 000005
【図５】
0004499776.tif 000006
【図７】
0004499776.tif 000007
【図８】
0004499776.tif 000008
【図９】
0004499776.tif 000009
【図１０】
0004499776.tif 000010
【図１１】
0004499776.tif 000011
【図１２】
0004499776.tif 000012
【図６】
0004499776.tif 000013