JP4499776B2 - ストレージ制御装置、方法、及びプログラム - Google Patents

ストレージ制御装置、方法、及びプログラム Download PDF

Info

Publication number
JP4499776B2
JP4499776B2 JP2007284546A JP2007284546A JP4499776B2 JP 4499776 B2 JP4499776 B2 JP 4499776B2 JP 2007284546 A JP2007284546 A JP 2007284546A JP 2007284546 A JP2007284546 A JP 2007284546A JP 4499776 B2 JP4499776 B2 JP 4499776B2
Authority
JP
Japan
Prior art keywords
reconstruction
storage
storage device
storage devices
rebuilding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2007284546A
Other languages
English (en)
Other versions
JP2009110456A (ja
Inventor
実希夫 伊藤
秀治郎 大黒谷
和彦 池内
親志 前田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2007284546A priority Critical patent/JP4499776B2/ja
Priority to US12/261,853 priority patent/US8386837B2/en
Publication of JP2009110456A publication Critical patent/JP2009110456A/ja
Application granted granted Critical
Publication of JP4499776B2 publication Critical patent/JP4499776B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1076Parity data used in redundant arrays of independent storages, e.g. in RAID systems
    • G06F11/1092Rebuilding, e.g. when physically replacing a failing disk
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/10Indexing scheme relating to G06F11/10
    • G06F2211/1002Indexing scheme relating to G06F11/1076
    • G06F2211/1057Parity-multiple bits-RAID6, i.e. RAID 6 implementations

Description

本発明は、格納対象とする情報であるデータ及びパリティを複数の記憶装置(ストレージ)に分散して格納することにより冗長化を実現する技術に関する。
近年、ストレージは大容量化し、そのストレージに蓄積されるデータ量は増大し続けている。それにより、サーバに搭載/接続されるストレージでは、重要なデータが失われる危険性を低減させるために、一般にRAID(Redundant Arrays of Inexpensive Disks)による冗長化が行われている。
RAIDは、複数台のストレージ(ハードディスク装置等の記憶装置)を1台のストレージとして管理する技術である。高速性や安全性により、RAID0からRAID6まで7つのレベルがある。最近では、2台のストレージの故障に対応可能なRAID6が注目されている。そのRAID6では、格納するデータから2種類のパリティを生成し、それらを分散(ストライピング)して複数台のストレージに格納する。
ストレージシステムの構築は通常、同じ時期に製造された同一モデルのストレージを用いて行われる。そのようにシステムを構築した場合、平均故障間隔(MTBF)等の特性はほぼ同じとなり、1台のストレージが故障すると、続けて別のストレージが故障する可能性が比較的に高い。RAIDの再構築(リビルド)作業では、データの読み出しが連続的に発生して各ストレージへの負荷は高くなるために、ストレージが故障しやすい状態となる。このようなことから、RAID5よりも信頼性の高いRAID6が注目されるようになってきている。RAIDの再構築は、故障したストレージに予備用のストレージであるホットスペア(HS)を割り当て、故障したストレージに格納されていたデータ或いはパリティを未故障のストレージに格納されているデータ或いはパリティから復元し格納することで行われる。ここでは以降、ストレージに格納されるデータ及びパリティを「情報」と総称することとする。
特開2006−259894号公報 特開平03−240123号公報
RAID6の再構築を行う従来のストレージ制御装置としては、特許文献1に記載されたものがある。その特許文献1に記載された従来のストレージ制御装置では、1台のストレージの再構築中に2台目のストレージが故障した場合、1台目のストレージに対して行っている再構築の進捗状況に応じて、2台のストレージを対象にした再構築を連携して行うことができるようになっている。既に再構築した部分(ストライプ)の再構築は行わないようにして、効率的に冗長性を回復できるようにしている。
しかし、2台のストレージを対象にした再構築を行っている間に、その2台のストレージに割り当てた2台のホットスペアのうちの1台が故障する可能性がある。このことから、RAID6の再構築では、そのような場合にも適切に対応できるようにすることが重要と考えられる。
本発明は、故障した2台のストレージに再構築用に割り当てた2台のストレージ(ホットスペア)のうちの1台が再構築中に故障した場合の再構築を適切に行うための技術を提供することを目的とする。
本発明のストレージ管理装置は、格納対象とする情報であるデータ及びパリティを複数の記憶装置(ストレージ)に分散して格納することにより冗長化を実現するものであり、複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築手段と、複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築手段と、第1及び第2の再構築手段を制御し、第2の再構築手段が再構築を行っている間に2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築手段に該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御手段と、を具備する。
なお、上記第2の再構築手段は、2台の予備記憶装置を連携させた再構築を行う場合、該再構築を早く開始した予備記憶装置を先行側、該再構築を遅く開始した予備記憶装置を追従側に設定し、該先行側で再構築が行われた部分のなかで該追従側が再構築を行っていない部分が無い状況になったとき、該追従側は該再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させる、ことが望ましい。再構築制御手段は、未故障の1台で再構築が終了した領域が連続しているか否かにより、2台の再構築処理の内容を変化させる、ことが望ましい。
本発明のストレージ制御方法は、格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するためのものであり、複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行い、再構築を行っている間に2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて該再構築を行わせる。
本発明のプログラムは、格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築機能と、複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築機能と、第1及び第2の再構築機能を制御し、第2の再構築機能により再構築を行っている間に2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築機能による該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御機能と、を実現させる。
本発明が適用されたRAID装置等のストレージシステムでは、複数の記憶装置(ストレージ)のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、その2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、その2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行い、その再構築を行っている間に2台の予備記憶装置のうちの1台が故障した場合に、故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて再構築を行わせる。このため、冗長化のためのグループに属するストレージが3台以上、故障したとしても、再構築が可能な状況であればその再構築を適切に行うことができる。
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図1は、本実施形態によるストレージ制御装置が適用されたRAID装置の構成を示す図である。そのRAID装置1は、例えばUNIX(登録商標)サーバ或いはIA(Intel Architecture)サーバがホスト・コンピュータ(以降「ホスト」)2として接続され、そのホスト2から受信したデータを冗長化して格納するものである。そのために、複数のCA(Channel Adapter)11、2つのCM(Controller Module)12、及び多数のハードディスク装置(HDD)13を備えている。
CM12は、ホスト2からの指示に従って、HDD13にアクセスするものであり、CPU121、フラッシュ(Flash)メモリ122、キャッシュメモリ123、2つのディスクI/Fアダプタ(以降「DI」)124、及び他のCM12との通信用アダプタ125を備えている。フラッシュメモリ122にはCPU121が実行するプログラムが格納されており、CPU121はそのプログラムをキャッシュメモリ123に読み出して実行することにより制御を行う。本実施形態によるストレージ制御装置は、そのCM12上で実現されている。
なお、このプログラムは、別のフラッシュメモリ、光ディスク、或いは可搬性のHDD等に記録して配布しても良い。通信ネットワークを介して取得するようにしても良い。再構築の対象とするストレージは、HDD13とは異なる種類であっても良く、複種類であっても良い。
図2は、CM13の機能構成図である。
そのCM13は、通信部201、システム制御部202、冗長化部203、アクセス部204、リビルド制御部205、スケジュール管理部206、及びリビルド実行部207を備えている。
通信部201は、ホスト2或いは他のCM12との間で通信を行うものである。システム制御部202は、CM12全体の制御を行うものである。情報(データ或いはパリティ)を分散して格納するHDD13はグループとして管理され、そのグループ(RAIDグループ)を構成するHDD13の組み合わせは、そのグループを構成するHDD13の故障によって変更される。その管理・変更は、システム制御部202に搭載されたグループ状態変更部202aによって行われる。
冗長化部203は、システム制御部202からHDD13に格納するデータを受け取ってパリティを生成し、生成したパリティをデータと共に分散してHDD13(RAIDグループ)に格納する。アクセス部204は、実際にHDD13にアクセスするものである。このため、情報のHDD13への格納、及び読み出しはアクセス部104を介して行われる。
リビルド実行部207は、故障したHDD13に格納されていた情報を同じRAIDグループに属する未故障のHDD13に格納されている情報から復元し、復元した情報を故障したHDD13に代替用に割り当てられた予備のHDD13であるホットスペア(HS)に格納するリビルドを実行する。その実行はストライプ単位で行う。情報の読み出し、及び格納はアクセス部204を介して行う。
リビルド制御部205は、故障したHDD13のリビルド(再構築)の実施、つまりリビルド実行部207の動作を制御する。スケジュール管理部206は、HDD13のリビルドを実施するスケジュールを管理する。
上記各部201〜207は、CPU121がフラッシュメモリ122に格納されたプログラムを実行することにより実現される。それにより、ホスト2からの要求に対応するための動作を可能とし、HDD13の故障時には再構築を自動的に行う。
図1に示すキャッシュメモリ123には、データの冗長化のためにデータ・バッファ123aが確保されている。そのメモリ123に確保された制御テーブルエリア123bは、図3及び図4にそれぞれ示すテーブルを格納するためのものである。以降は、図3〜図6を参照して、本実施形態で行われるRAID6の再構築処理について具体的に説明する。
図5は、RAID6のステータス遷移図である。同じRAIDグループに属するHDD13のなかで故障したHDD13の発生、その再構築の終了に伴う状態(ステータス)遷移を示したものである。
図5に示すように、正常状態ST1で1台目のHDD(図中「Disk」)13の故障により、1台のHDD13が故障しているPartialy Exposed状態ST2に遷移する。その後は、1台のHDD13を再構築するPartialy Exposed Rebuild状態ST3に遷移する。その再構築を終了すると、正常状態ST1に遷移し、その再構築中に別の1台、つまり2台目が故障すると、2台のHDD13が故障しているExposed状態ST4に遷移する。そのExposed状態ST4に遷移した後は、2台のHDD13を再構築するExposed Rebuild状態ST5に遷移する。
2台のHDD13を再構築中に、復元した情報を格納する2台のHSのうちの何れかが故障する場合がある。その故障が発生した場合、つまり3台目のHDD13が故障した場合、Exposed状態ST4に遷移する。それにより、故障したHS(HDD13)を別のHSに代えて、2台のHDD13を再構築するExposed Rebuild状態ST5に遷移する。そのようにして本実施形態では、HSの故障(3台目以上の故障)によりExposed Rebuild状態ST5からExposed状態ST4に遷移させることにより、再構築に用いている2台のHSの故障に対応するようにしている。1台分の再構築が終了した場合には、つまり再構築すべきHDD13が残り1台となった場合には、Partialy Exposed Rebuild状態ST3に遷移する。
図6は、2台のHDD13の再構築中に1台のHSが故障した場合に行われる再構築処理を示す図である。図6(a)は、未故障のHSで再構築が終了した領域が連続していないケースで行われる再構築処理を示し、図6(b)は、その領域が連続しているケースで行われる再構築処理を示している。
図6において、D0〜D3は情報として格納されるデータ、P−P及びP−Qは情報として格納される2種類のパリティをそれぞれ示している。それにより、RAIDグループは未故障の6台(データ格納用に4台、パリティ格納用に2台の計6台)のHDD13から構成されることを表している。HS0〜HS2は、故障したHDD13(ここではHSを含む)の再構築用に割り当てられたHSを示している。以降、便宜的に、図6(a)或いは(b)を参照、或いは想定して説明する場合、D0〜D3、P−P、P−Q、及びHS0〜HS2はそれぞれHDD13を指す符号として用いることとする。そのことを明確にするために、HDD13は「ディスク」と表記する。
HSが故障(3台目以上のHDD13が故障)した場合の再構築処理を説明する前に、2台のHDD13が故障した場合(普通は1台の再構築中に別の1台が故障した場合である)の再構築処理について簡単に説明する。
2台のHDD13が故障した場合の再構築処理は、特許文献1に記載された方法により行われる。
2台目のHDD13が故障するまでの間に、1台目に故障したHDD13の再構築が進行、つまりそのHDD13に割り当てたHSに復元した情報が格納される領域が拡大する。再構築が済んだ部分は、1台分の再構築のみを行えば良く、その再構築が済んでいない部分(2重故障部分)は、2台分の再構築を行う必要がある。このことから、2台分の再構築を行う必要の有無により、再構築を行う部分、つまり復元した情報を格納する領域を分けて再構築を行っている。それにより図6(a)では、1台目のHDD13であるディスクD1の故障によりディスクHS0を用いた再構築を「follow_end」で示す位置まで行ったときにディスクD3が故障したことを表している。その2台目の故障により、follow_end以降はディスクHS0及びHS1を用いた2台の再構築を連携させて行い、ディスクHS1のfollow_endまでの再構築は1台のみの再構築として行っていることを表している。
上記のように2台の再構築を行う場合、3台目以上のHDD13(HS)が故障したときの未故障のHDD13(HS)の再構築状況は、再構築を行った領域(済み領域)が連続している状況(図6(b))、及びその済み領域が連続していない状況(図6(a))、つまり済み領域と再構築を行っていない領域である未済み領域とが交互に連続している状況に大別される。以降、前者は「済み領域連続状況」、後者は済み領域非連続状況」とそれぞれ呼ぶことにする。
本実施形態では、3台目以上のHDD13(HS)の故障時に済み領域非連続状況であった場合、未故障のHDD13(HS)を用いた再構築は未終了の領域のみを対象にして行い、新たに割り当てたHS(図6(a)(及び図6(b))ではディスクHS2)はその先頭から再構築を行う。それにより、2台の再構築は連携させない。図6(a)ではそのことを示している。
一方、3台目以上のHDD13(HS)の故障時に済み領域連続状況であった場合には、未故障のHDD13(HS)を用いた再構築は未終了の領域のみを対象にして、新たに割り当てたHSと連携させて行い、その新たに割り当てたHSで連携の対象とならない部分は別に再構築を行う。それにより、新たに割り当てたHSでは2種類の再構築を並行して行う。図6(b)ではそのことを示している。
このようにして本実施形態では、3台目以上のHDD13(HS)が故障した場合、未故障のHSの再構築状況が済み領域連続状況か否かに係わらず、未故障のHSを用いた再構築はそれが済んでいない未済み領域のみを対象にして行うようにしている。それにより、短時間に冗長性を回復できるようにしている。
再構築状況が済み領域非連続状況であった場合、新たに割り当てたHSの再構築は連携させずに行うようにしている。これは、再構築処理の制御が複雑化するのを抑えるということの他に、再構築を実施する際に発生するシーク時間の増大を抑えるためである。そのシーク時間の増大を抑えることにより、再構築もより短い時間で完了させることができるようになる。
上述したような再構築処理を行うために、本実施形態では、HDD13毎に管理用のテーブル(以降「構成テーブル」)を用意し、再構築実施用に別のテーブル(以降「リビルド制御テーブル」)をHDD13の故障により用意するようにしている。図1のキャッシュメモリ123に確保した制御テーブルエリア123bには、それらテーブルが格納される。それらのテーブルについて、図3及び図4を参照して具体的に説明する。
図3は、構成テーブルの構成を示す図である。その構成テーブルは、RAID装置1に搭載されたHDD13毎に用意され、各種パラメータが格納される。図中、再構築に特に関係しないパラメータは「reserve」と表記している。それにより以降、reserveと表記していないパラメータについてのみ説明する。テーブルの横に表記した「0x00」「0x04」等は、相対アドレスの値を示している。
「Status」は、対応するHDD13の状態を示すパラメータである。そのパラメータにより、例えば正常状態、故障状態、及び再構築中状態を認識可能とさせている。「PLUN」は、対応するHDD13に割り当てられた識別用の番号(ディスク番号)である。「RLUN」は、対応するHDD13が属するRAIDグループに割り当てられた識別用の番号(グループ番号)である。
「Block Count」は、対応するHDD13の記憶容量を示すパラメータである。HDD13では普通、全てのセクタに通し番号を振り、その通し番号によってセクタを指定できるLBA(Logical Block Addressing)方式が採用される。そのパラメータは、例えばLBA方式により記憶容量を示すものである。その場合、その値は最後のセクタに割り当てられたセクタ番号に1を加算して得られるものである。以降、LBA方式を採用していることを前提として説明を行う。
「rebuild_plba」は、再構築実施時にその再構築が終了した位置を示すパラメータである。その位置はセクタ番号により示される。「Rebuild Block
Count」は、1回の処理単位、つまり1スプライト分の記憶容量を示すパラメータである。その記憶容量はセクタ数により表現された値である。以降、その処理単位は「ブロック」と呼ぶことにする。
「rebuild_pair_plun」は、再構築を連携させるHDD13のディスク番号を示すパラメータである。初期値は「0xffff」である。再構築の連携は、2台のうちで再構築を早く開始した方を先行側、他方を追従側に設定して行われる。このパラメータは、先行側のみ設定される。「rebuild_mode」は、連携した再構築を行っているか否かを示すパラメータである。その初期値は0であり、連携させた再構築を行う場合に「1」となる。このパラメータも先行側のみ設定される。
「rebuild_follow_end_plba」は、再構築の連携を開始させる位置を示すパラメータである。このパラメータは、追従側のみ設定される。初期値は「0xffffffff」である。「rebuild_plural_plba」は、追従側のみ設定される、追従側で再構築が終了した位置を示すパラメータである。初期値は「0xffffffff」である。
上記パラメータのなかで、「rebuild_pair_plun」「rebuild_mode」「rebuild_follow_end_plba」及び「rebuild_plural_plba」は、2台の再構築を連携させるために設定される。このことから、それらを「連携パラメータ」と総称する。
図6(a)及び(b)に表記の「rebuild_plba」や「rebuild_plural_plba」、及び「follow_end」等は、図3に示すパラメータ名、或いはその略記である。それにより、ディスクHS0の故障時に設定されていた各パラメータの内容、及び新たに割り当てたディスクHS2で設定される各パラメータの内容を表している。
図4は、リビルド制御テーブルの構成を示す図である。その制御テーブルは、再構築の対象となるHDD13毎に用意され、実際の再構築はこの制御テーブルを参照して行われる。図3と同様に、reserveと表記していないパラメータについてのみ説明する。テーブルの横に表記した「0x00」「0x04」等は、図3と同じく相対アドレスの値を示している。
「RLUN」は、故障したHDD13に割り当てられたHSが属することになるRAIDグループのグループ番号である。「復元先PLUN」は割り当てられたHSのディスク番号である。「復元元PLUN」は故障したHDD13(HS)のディスク番号である。「previous_acb_address」は、一つ前の制御テーブルが格納された先頭アドレスを示すパラメータであり、「next_acb_address」は、一つ後の制御テーブルが格納された先頭アドレスを示すパラメータである。これら2つのパラメータにより、リビルド制御テーブルは順次、参照していくようにしている。一つ前、或いは一つ後の制御テーブルが存在しない場合はNULLで表現される。
「rebuild_start_lba」は次に再構築の対象となるブロックの先頭のセクタ番号を示すパラメータである。「plural_rebuild_exe」は、再構築を行うモードを示すパラメータである。そのパラメータにより示されるモードは、1台の再構築を行うモード(以降「独立モード」)、及び2台の再構築を連携して行うモード(以降「連携モード」)のうちの何れかである。独立モード時の値は0。連携モード時の値は1である。
本実施形態では、再構築を行うべき部分(ストライプ)の再構築は先行側→追従側の順序で行うようにしている。それにより、先行側で再構築が行われた部分(ストライプ)のなかで追従側が再構築を行っていない部分が無い状況となると、再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させるようにしている。「rebuild_sleep」は、スリープ状態か否かを示すパラメータである。その値は、スリープ状態でない時には0、その状態時には1である。「awaken_need」は、連携を解除する際に追従側のスリープ状態を解除する必要性の有無を示すパラメータである。その値は、解除の必要性がないときには0、その必要があるときには1である。
図6(a)に示すように、ディスクHS0及びHS1を用いて2台分の再構築を行う場合、ディスクHS1では2重故障部分以外は独立モードで再構築を行う。このため、ディスクHS1では、独立モード及び連携モードの2つのモードで再構築が行われる。それにより、リビルド制御テーブルは2つ用意される。
次に、図7〜図12に示す各処理のフローチャートを参照して、故障の発生時のCM12の動作について詳細に説明する。その各処理、及び図3及び図4にそれぞれ示すテーブルの管理は、CPU121がフラッシュメモリ122に格納されているプログラムを実行することで実現される。
図7は、復旧処理のフローチャートである。その復旧処理は、HDD13の故障の発生を契機にして、その発生から復旧が完了するまでの間に実行される主な処理を抜粋してまとめたものである。始めに図7を参照して、その復旧処理について詳細に説明する。
先ず、ステップS1では、新たな故障の発生に対応するための開始処理を実行する。その開始処理の実行により、故障したHDD13の構成テーブルは初期設定され、リビルド制御テーブルの生成、或いは消去が行われる。
ステップS1に続くステップS2では、リビルド制御テーブルを選択する。その後に移
行するステップS3では、選択したリビルド制御テーブルが追従側のHDD13用のものか否か判定する。その制御テーブル中のplural_rebuild_exeの値が連携モードを示す1であり、且つ復元先PLUNから特定される構成テーブルに格納されているrebuild_modeの値が初期値の0であった場合、選択した制御テーブルは追従側のHDD13用であることから、判定はYESとなってステップS10に移行する。そうでない場合には、つまり選択した制御テーブルが先行側のもの、或いは連携させない独立モードのものであった場合には、判定はNOとなってステップS4に移行する。
ステップS4では、再構築を行う範囲を設定する。このとき設定される範囲は、選択したリビルド制御テーブル中のrebuild_start_lbaが示すセクタを先頭とし、その先頭から構成テーブル中のRebuild Block Countが示すセクタ数分の領域である。そのような範囲を設定した後はステップS5に移行して、その範囲の再構築(復元)を行うための再構築処理を実行する。その再構築は周知の方法を用いて行うため、詳細な説明は省略する。その再構築処理の実行後はステップS6に移行する。
ステップS6では、次の再構築処理のための第1の後処理を実行する。続くステップS7では、追従側のスリープ状態を必要に応じて解除するためのスリープ解除処理を実行する。その実行後は、ステップS8に移行して、新たな故障が発生したか否か判定する。その故障が発生した場合、判定はYESとなって上記ステップS1に戻る。そうでない場合には、判定はNOとなり、ステップS9に移行する。なお、故障が発生したか否かの判定は、DI124を介してHDD13に行われるアクセスをCPU121が監視することで行われる。
ステップS9では、再構築が全て完了したか否か判定する。本実施形態では、再構築が完了したHDD13ではリビルド制御テーブルを消去するようにしている。このため、例ビルド制御テーブルが存在しない場合、判定はYESとなり、ここで復旧処理を終了する。そうでない場合には、判定はNOとなり、上記ステップS2に戻って制御テーブルの選択を行う。
上記ステップS3の判定がYESとなって移行するステップS10では、選択したリビルド制御テーブル中のrebuild_sleepの値がスリープ状態を示すものか否か判定する。その値がスリープ状態を示す1であった場合、判定はYESとなって上記ステップS8に移行する。そうでない場合には、つまりその値が0であった場合には、判定はNOとなってステップS11に移行する。
ステップS11では、上記ステップS4と同様に、再構築を行う範囲を設定する。続くステップS12では、設定した範囲の再構築(復元)を行うための再構築処理を実行する。その後は、次の再構築処理のための第2の後処理をステップS13で実行し、更にスリープ状態を必要に応じて設定するためのスリープ設定処理をステップS14で実行してから上記ステップS8に移行する。
以降は、上記復旧処理内で実行される各種サブルーチン処理について詳細に説明する。
図8は、上記ステップS1として実行される開始処理のフローチャートである。始めに図8を参照して、その開始処理について詳細に説明する。
先ず、ステップS21では、故障したHDD13に設定されているRAIDレベルがRAID6か否か判定する。そのRAIDレベルは、RAIDグループの管理用テーブルにより管理している。そのため、その管理用テーブルにRAIDレベルとしてRAID6が設定されていた場合、判定はYESとなってステップS23に移行する。そうでない場合には、つまり例えばRAID1或いはRAID5等が設定されていた場合には、判定はN
OとなってステップS22に移行し、設定されたRAIDレベルに応じて再構築を実行するための設定を行う。その後に開始処理を終了する。
ステップS23では、新たに発生した故障によって遷移させるべき状態の判定を行う。続くステップS24では、その状態が1台の再構築を行うPartialy Exposed Rebuild状態ST3に遷移させるべきものであった場合、つまり故障したHDD13が属するRAIDグループで再構築が必要なHDD13が1台であった場合、判定はYESとなってステップS25に移行し、再構築処理を実施するための準備を行った後、開始処理を終了する。
この準備では、plural_rebuild_exeの値を0(初期値)としたリビルド制御テーブルが生成される。復元先PLUNには再構築用に割り当てられたHDD13(HS)のディスク番号、復元元PLUNには故障したHDD13のディスク番号がそれぞれ設定される。再構築に割り当てられたHDD13の構成テーブルでは、Statusは再構築中を示す値に、RLUNは故障したHDD13が属するRAIDグループを示す番号にそれぞれ更新される。故障したHDD13の構成テーブル中のStatusは故障中を示す値に更新される。
RAID6では、情報の格納に用いているHDD13が1度に3台以上、故障すると、言い換えれば3台以上の再構築を行うべき状況となると、再構築を行えなくなる。このため、特には図示していないが、上記ステップS23では、新たな故障によってそのような状況となったか否か判定することにより、そのような状況となったRAIDグループでの再構築を終了させるための処理を行うようになっている。
一方、ステップS26では、RAIDグループでの故障により再構築すべきHDD13は2台となったか否か判定する。図6(a)及び(b)に示すように、ディスクD1の再構築中にディスクD3が故障したような場合、判定はYESとなってステップS27に移行する。そうでない場合には、つまり図6(a)及び(b)に示すように、2台のHSを用いた再構築中にその1台が故障することで故障代数が3台以上となった場合には、判定はNOとなってステップS29に移行する。
ステップS27では、上記ステップS25と同様に、リビルド制御テーブルを生成する。その制御テーブルでは、plural_rebuild_exeの値を1とし、生成済みの制御テーブル中のplural_rebuild_exeの値は1に更新する。構成テーブルでは、Status及びRLUNを更新する。そのような更新を行った後はステップS28に移行して、先行側と共に、構成テーブル中の連携パラメータを更新する。その後、この開始処理を終了する。
連携パラメータの更新は、先行側では、rebuild_pair_plunに追従側のHDD13のディスク番号、rebuild_modeに1をそれぞれ設定することで行われる。追従側では、rebuild_pair_plunに先行側のHDD13のディスク番号、rebuild_follow_end_plbaに先行側のrebuild_plbaの値をそれぞれ設定することで行われる。
ステップS29では、故障したHDD13(HS)を用いた再構築用に作成済みのリビルド制御テーブルを消去し、そのHDD13を再構築するためのリビルド制御テーブルを生成して、2つの構成テーブルの更新を行う。次のステップS30では、その2つの構成テーブル中の連携パラメータの更新を必要に応じて行う。その後、この開始処理を終了する。
ここでは、2台のHSのなかで故障しなかった方の再構築状況の判定を行い、リビルド制御テーブルが生成される。図6(a)に示すように、再構築状況が済み領域非連続状況であった場合、独立モードで再構築を行うためのリビルド制御テーブルが生成され、故障しなかった方の連携モードが設定されたリビルド制御テーブルでは、その連携モードに代わって独立モードが設定される。それにより、その方(図6(a)ではディスクHS1が相当)を用いた再構築は以降2つの独立モードで行う。その方の構成テーブルでは、連携パラメータはrebuild_follow_end_plbaを除き全て初期値に更新される。故障したHDD13(HS)に割り当てたHDD13(HS)側では連携パラメータは初期値のままとなる。rebuild_follow_end_plbaを初期値に更新しないのは、既に再構築済みの領域を再度、再構築するのを回避するためである。
一方、図6(b)に示すように、再構築状況が済み領域連続状況であった場合、独立モード、連携モードのそれぞれで再構築を行うために2つのリビルド制御テーブルが生成され、故障しなかった方のリビルド制御テーブルの更新は行われない。その方(先行側)の連携パラメータでは、rebuild_modeの値は1に更新され、他は初期値に更新される。故障したHDD13(HS)に割り当てたHDD13(追従側)では、rebuild_pair_plunは先行側のディスク番号に更新され、rebuild_follow_end_plbaは先行側のrebuild_plbaの値に更新される。
このようにして開始処理では、新たな故障が発生した時点の状況に応じてリビルド制御テーブルの生成、或いは消去、及び構成テーブルの更新が行われる。それにより、それらのテーブルを参照して再構築を実施するための準備が行われる。
図9は、図7に示す復旧処理内でステップS6として実行される第1の後処理のフローチャートである。次に図9を参照して、その後処理について詳細に説明する。
再構築は、上述したように、リビルド制御テーブル、及び構成テーブルを参照して行われる。この第1の後処理は、先行側、或いは独立モードで1回の再構築処理を行ったことに合わせて、それらのテーブルを更新するために行われる。
先ず、ステップS41では、直前に実行した再構築処理は先行側用のものか否か判定する。その再構築処理が先行側用のものであった場合、判定はYESとなってステップS45に移行し、進捗を更新する。それにより、構成テーブル中のrebuild_plba、及び/或いは、リビルド制御テーブル中のrebuild_start_plbaは、次の再構築を開始すべきセクタを示す値(セクタ番号)に更新する。その後、この第1の後処理を終了する。一方、そうでない場合には、判定はNOとなり、次にステップS42で同様に進捗を更新した後、ステップS43に移行する。
図6(a)に示すように、ディスクHS0が故障すると、ディスクHS1では2つの独立モードで再構築が行われる。rebuild_plural_plba以降の再構築の進捗は、リビルド制御テーブル中のrebuild_start_plbaで管理するようになっている。rebuild_plbaは他の独立モードによる再構築に用いているために更新は行わない。
ステップS43では、更新後のrebuild_start_plbaが示す位置が最終の位置か否か判定する。設定されたモードでの再構築が終了した場合、それらの位置が一致することから、判定はYESとなってステップS44に移行し、リビルド制御テーブルを消去し、構成テーブルを初期状態に更新した後、この第1の後処理を終了する。そうでない場合には、判定はNOとなり、ここでこの第1の後処理を終了する。
最終の位置は、通常はBlock Countが示す位置である(このため図中に表記
)。しかし、図6(a)に示すディスクHS1では、rebuild_plural_plbaとなる場合がある。Block Count及びrebuild_plural_plbaを対象とした最終の位置の選択は、rebuild_start_plbaが示す位置により行っている。rebuild_start_plbaの示す位置がrebuild_plural_plbaの示す位置以前であれば、最終の位置としてrebuild_plural_plbaの示す位置が選択される。
図10は、図7に示す復旧処理内でステップS7として実行されるスリープ解除処理のフローチャートである。次に図10を参照して、その解除処理について詳細に説明する。その解除処理は、上述したように、追従側のスリープ状態を解除するために実行される。
先ず、ステップS51では、リビルド制御テーブル中のawaken_needの値が0か否か判定する。その値が0、つまり追従側のスリープ状態を解除する必要が無い場合、判定はYESとなり、ここでスリープ解除処理を終了する。そうでない場合には、判定はNOとなり、ステップS52に移行する。
ステップS52では、追従側のリビルド制御テーブルを検索して抽出する。続くステップS53では、その制御テーブル中のrebuild_sleepの値が0、つまり追従側がスリープ状態となっていないか否か判定する。追従側がスリープ状態でなかった場合、判定はYESとなり、ここでスリープ解除処理を終了する。そうでない場合には、判定はNOとなり、ステップS54でスリープ状態を解除、つまりrebuild_sleepの値を0に更新してから、このスリープ解除処理を終了する。
図11は、図7に示す復旧処理内でステップS13として実行される第2の後処理のフローチャートである。次に図13を参照して、その後処理について詳細に説明する。
先ず、ステップS61では、進捗を更新する。それにより、構成テーブル中のrebuild_plural_plba、及び、リビルド制御テーブル中のrebuild_start_plbaは、次の再構築を開始すべきセクタを示す値(セクタ番号)に更新する。その更新後はステップS62に移行する。
ステップS62では、更新後のrebuild_plural_plbaの示す位置が再構築の最終位置(図中「最終LBA」と表記)か否か判定する。それらの位置が一致、即ちrebuild_plural_plbaの示す位置がBlock Countの示す位置と一致する場合、判定はYESとなってステップS63に移行し、追従側、及び先行側のリビルド制御テーブルを共に消去し、各構成テーブルの連携パラメータを初期値に更新した後、この第2の後処理を終了する。そうでない場合には、判定はNOとなり、ここでこの第2の後処理を終了する。
図12は、図7に示す復旧処理内でステップS14として実行されるスリープ設定処理のフローチャートである。最後に図12を参照して、その設定処理について詳細に説明する。本実施形態では、先行側の再構築が終了した位置まで追従側の再構築が進捗することを条件にスリープ状態に移行させるようにしている。
先ず、ステップS71では、先行側のリビルド制御テーブルが存在するか否か判定する。その制御テーブルが存在する場合、判定はYESとなってステップS72に移行する。そうでない場合には、判定はNOとなり、スリープ状態を設定する必要はないとして、ここでスリープ設定処理を終了する。
ステップS72では、上記条件が満たされているか否か判定する。その条件が満たされている場合、判定はYESとなり、ステップS73でリビルド制御テーブル中のrebu
ild_sleepの値を1に更新してスリープ状態を設定した後、このスリープ設定処理を終了する。そうでない場合には、判定はNOとなり、ここでこのスリープ設定処理を終了する。
なお、本実施形態では、2台の再構築中にそのうちの1台が故障した場合、未故障のHDD13(HS)の再構築状況に応じて、2台の再構築を行う方法を異ならせるようにしているが、同一の方法により再構築を行うようにしても良い。また、再構築を行う位置が異なることで発生するシーク時間を考慮して、その方法を異ならせるようにしても良い。また、1台の再構築を連携モード及び独立モードで行う場合、例えば連携モード(2重故障部分の再構築)を優先して行い、その終了後に独立モードの再構築を行うといったような優先関係を設定しても良い。再構築に用いる情報(パラメータ)は構成テーブル及びリビルド制御テーブル等により管理しているが、その情報の管理方法は特に限定されるものではない。
上述の実施形態に関し、更に以下の付記を開示する。
(付記1)
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置において、
前記複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築手段と、
前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築手段と、
前記第1及び第2の再構築手段を制御し、前記第2の再構築手段が前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築手段に該再構築を行わせる再構築制御手段と、
を具備することを特徴とするストレージ制御装置。
(付記2)
前記再構築制御手段は、前記2台の予備記憶装置のうちの1台が故障した場合、未故障の1台の再構築の進捗状況に応じて、前記第2の再構築手段による2台の再構築処理の内容を変化させる、
ことを特徴とする付記1記載のストレージ制御装置。
(付記3)
前記再構築制御手段は、前記未故障の1台で前記再構築が終了した領域が連続しているか否かにより、前記2台の再構築処理の内容を変化させる、
ことを特徴とする付記2記載のストレージ制御装置。
(付記4)
前記再構築制御手段は、前記未故障の1台で前記再構築が終了した領域が連続していない場合、前記第2の再構築手段により前記2台の再構築処理を独立させて行う、
ことを特徴とする付記3記載のストレージ制御装置。
(付記5)
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御方法において、
前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行い、
前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該再構築を行わせる、
ことを特徴とするストレージ制御方法。
(付記6)
格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、
前記複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築機能と、
前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築機能と、
前記第1及び第2の再構築機能を制御し、前記第2の再構築機能により前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築機能による該再構築を行わせる再構築制御機能と、
を実現させるためのプログラム。
本実施形態によるストレージ制御装置が適用されたRAID装置の構成を示す図である。 本実施形態によるストレージ制御装置が適用されたRAID装置に搭載されているCM13の機能構成図である。 構成テーブルの構成を示す図である。 リビルド制御テーブルの構成を示す図である。 RAID6のステータス遷移図である。 2台のHDD13の再構築中に1台のHSが故障した場合に行われる再構築処理を示す図である。 復旧処理のフローチャートである。 開始処理のフローチャートである。 第1の後処理のフローチャートである。 スリープ解除処理のフローチャートである。 第2の後処理のフローチャートである。 スリープ設定処理のフローチャートである。
符号の説明
1 RAID装置
2 ホスト・コンピュータ
11 CA(Channel Adapter)
12 CM(ControllerModule)
13 ハードディスク装置(HDD)
121 CPU
122 フラッシュメモリ
123 キャッシュメモリ
124 ディスクI/Fアダプタ

Claims (5)

  1. 格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置において、
    前記複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築手段と、
    前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築手段と、
    前記第1及び第2の再構築手段を制御し、前記第2の再構築手段が前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築手段に該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御手段と、
    を具備することを特徴とするストレージ制御装置。
  2. 前記第2の再構築手段は、2台の予備記憶装置を連携させた再構築を行う場合、該再構築を早く開始した予備記憶装置を先行側、該再構築を遅く開始した予備記憶装置を追従側に設定し、該先行側で再構築が行われた部分のなかで該追従側が再構築を行っていない部分が無い状況になったとき、該追従側は該再構築を行うタイミングとなっても再構築を行わないスリープ状態に移行させる、
    ことを特徴とする請求項1記載のストレージ制御装置。
  3. 前記再構築制御手段は、前記未故障の1台で前記再構築が終了した領域が連続しているか否かにより、前記2台の再構築処理の内容を変化させる、
    ことを特徴とする請求項記載のストレージ制御装置。
  4. 格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御方法において、
    前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行い、
    前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、未故障の予備記憶装置による再構築の進捗状況に応じて該再構築を行わせる、
    ことを特徴とするストレージ制御方法。
  5. 格納対象とする情報であるデータ及びパリティを複数の記憶装置に分散して格納することにより冗長化を実現するストレージ制御装置として用いることが可能なコンピュータに、
    前記複数の記憶装置のなかで故障した1台の記憶装置に格納されていた情報を、該1台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該1台の記憶装置の代替とする予備記憶装置に格納することにより再構築を行う第1の再構築機能と、
    前記複数の記憶装置のなかで故障した2台の記憶装置にそれぞれ格納されていた情報を、該2台の記憶装置以外の記憶装置に格納されている情報を用いて復元し、該2台の記憶装置の代替とする2台の予備記憶装置に格納することにより再構築を行う第2の再構築機能と、
    前記第1及び第2の再構築機能を制御し、前記第2の再構築機能により前記再構築を行っている間に前記2台の予備記憶装置のうちの1台が故障した場合に、該故障した予備記憶装置に他の予備記憶装置を割り当て、該第2の再構築機能による該再構築を未故障の予備記憶装置による再構築の進捗状況に応じて行わせる再構築制御機能と、
    を実現させるためのプログラム。
JP2007284546A 2007-10-31 2007-10-31 ストレージ制御装置、方法、及びプログラム Active JP4499776B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007284546A JP4499776B2 (ja) 2007-10-31 2007-10-31 ストレージ制御装置、方法、及びプログラム
US12/261,853 US8386837B2 (en) 2007-10-31 2008-10-30 Storage control device, storage control method and storage control program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007284546A JP4499776B2 (ja) 2007-10-31 2007-10-31 ストレージ制御装置、方法、及びプログラム

Publications (2)

Publication Number Publication Date
JP2009110456A JP2009110456A (ja) 2009-05-21
JP4499776B2 true JP4499776B2 (ja) 2010-07-07

Family

ID=40584449

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007284546A Active JP4499776B2 (ja) 2007-10-31 2007-10-31 ストレージ制御装置、方法、及びプログラム

Country Status (2)

Country Link
US (1) US8386837B2 (ja)
JP (1) JP4499776B2 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2484846A (en) * 2009-08-21 2012-04-25 Ibm Data storage system and method for operating a data storage system
JP2011128917A (ja) * 2009-12-18 2011-06-30 Fujitsu Ltd データ割当制御プログラム、データ割当制御方法、およびデータ割当制御装置
US9415401B2 (en) 2012-04-04 2016-08-16 Alternative Packaging Solutions Llc One turn actuated duration spray pump mechanism
CN103688373B (zh) * 2012-04-11 2016-03-02 株式会社理技独设计系统 照明装置以及液晶显示装置
JP6171616B2 (ja) * 2013-06-24 2017-08-02 富士通株式会社 ストレージ制御装置、及びストレージ制御プログラム
US9501360B2 (en) 2013-07-01 2016-11-22 International Business Machines Corporation Rebuilding data while reading data in a dispersed storage network
US9747177B2 (en) 2014-12-30 2017-08-29 International Business Machines Corporation Data storage system employing a hot spare to store and service accesses to data having lower associated wear
KR20180045220A (ko) * 2016-10-25 2018-05-04 삼성전자주식회사 읽기 요청 횟수를 줄이는 데이터 복원 동작을 수행하는 데이터 스토리지 시스템
US10241877B2 (en) 2016-12-12 2019-03-26 International Business Machines Corporation Data storage system employing a hot spare to proactively store array data in absence of a failure or pre-failure event
US10733053B1 (en) 2018-01-31 2020-08-04 Pure Storage, Inc. Disaster recovery for high-bandwidth distributed archives
US11354058B2 (en) 2018-09-06 2022-06-07 Pure Storage, Inc. Local relocation of data stored at a storage device of a storage system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000148409A (ja) * 1998-11-12 2000-05-30 Hitachi Ltd 冗長記憶装置
JP2001147785A (ja) * 1999-10-29 2001-05-29 Hewlett Packard Co <Hp> データを管理する方法
JP2006259894A (ja) * 2005-03-15 2006-09-28 Fujitsu Ltd ストレージ制御装置および方法

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0786810B2 (ja) 1990-02-16 1995-09-20 富士通株式会社 アレイディスク装置
JP2923702B2 (ja) 1991-04-01 1999-07-26 株式会社日立製作所 記憶装置及びそのデータ修復方法
JPH0668603A (ja) * 1992-08-20 1994-03-11 Hitachi Maxell Ltd 光ディスク装置
DE69408498D1 (de) 1993-06-30 1998-03-19 Ibm Kodierung und Rekonstruktion des Dateninhaltes von bis zu zwei nichtverfügbaren DASDs in einer DASD-Anordnung
JPH07261945A (ja) * 1994-03-17 1995-10-13 Hitachi Ltd ディスクアレイ装置およびディスクアレイの区分け方法
US6430701B1 (en) * 1998-01-27 2002-08-06 Aiwa Co., Ltd. Data recording and reproducing method and apparatus using plurality of data recording and reproducing units, and computer-readable recording medium
US7185222B2 (en) * 2003-11-14 2007-02-27 International Business Machines Corporation Apparatus, system, and method for maintaining data in a storage array
US7409582B2 (en) * 2004-05-06 2008-08-05 International Business Machines Corporation Low cost raid with seamless disk failure recovery
GB0612482D0 (en) * 2006-06-23 2006-08-02 Ibm Apparatus and method for controlling raid array rebuild
US8065558B2 (en) * 2009-03-24 2011-11-22 Lsi Corporation Data volume rebuilder and methods for arranging data volumes for improved RAID reconstruction performance

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000148409A (ja) * 1998-11-12 2000-05-30 Hitachi Ltd 冗長記憶装置
JP2001147785A (ja) * 1999-10-29 2001-05-29 Hewlett Packard Co <Hp> データを管理する方法
JP2006259894A (ja) * 2005-03-15 2006-09-28 Fujitsu Ltd ストレージ制御装置および方法

Also Published As

Publication number Publication date
JP2009110456A (ja) 2009-05-21
US8386837B2 (en) 2013-02-26
US20090113237A1 (en) 2009-04-30

Similar Documents

Publication Publication Date Title
JP4499776B2 (ja) ストレージ制御装置、方法、及びプログラム
JP4815825B2 (ja) ディスクアレイ装置及びその再構築方法
JP2501752B2 (ja) コンピユ―タ・システムのストレ―ジ装置及びデ―タのストア方法
JP5391993B2 (ja) ディスクアレイ装置
CN101523353B (zh) 在存在全局热备用磁盘的情况下用于故障驱动器的优化重建和向回复制的方法
JP4754852B2 (ja) ストレージ制御装置および方法
US6976187B2 (en) Rebuilding redundant disk arrays using distributed hot spare space
US5566316A (en) Method and apparatus for hierarchical management of data storage elements in an array storage device
JP4719802B2 (ja) ストレージ管理装置、ストレージ管理方法およびストレージシステム
US20140304469A1 (en) Data storage
US20190391889A1 (en) Allocating part of a raid stripe to repair a second raid stripe
EP0518603A2 (en) Distributed sparing in DASD arrays
CN104123100A (zh) 控制存储设备阵列中的数据存储
US9003140B2 (en) Storage system, storage control apparatus, and storage control method
JPH0731579B2 (ja) Dasdアレイの階層を管理する方法および装置
JP2011520182A (ja) 分散データストレージシステムの信頼性の動的定量化と改善
JP2018508073A (ja) データ除去、割り当て、及び再構築
US20050193273A1 (en) Method, apparatus and program storage device that provide virtual space to handle storage device failures in a storage system
US10877844B2 (en) Using deletable user data storage space to recover from drive array failure
JP4756704B2 (ja) データ・ストレージ・アレイ
JP2005099995A (ja) 磁気ディスク装置のディスク共有方法及びシステム
US8402231B2 (en) Storage device, method for restoring data in storage device and storage controller
JP5169993B2 (ja) データストレージシステム、データ領域管理方法
JP2014203285A (ja) ドライブアレイ装置、コントローラ、データ記憶ドライブ及び方法
JP2010267037A (ja) ディスクアレイ装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090319

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091008

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091020

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091221

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100413

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100415

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130423

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4499776

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140423

Year of fee payment: 4