JP3573599B2 - ディスクアレイにおけるデータ回復方法 - Google Patents
ディスクアレイにおけるデータ回復方法 Download PDFInfo
- Publication number
- JP3573599B2 JP3573599B2 JP18244697A JP18244697A JP3573599B2 JP 3573599 B2 JP3573599 B2 JP 3573599B2 JP 18244697 A JP18244697 A JP 18244697A JP 18244697 A JP18244697 A JP 18244697A JP 3573599 B2 JP3573599 B2 JP 3573599B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- volume
- disk storage
- drive
- input
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
- Debugging And Monitoring (AREA)
Description
【発明の属する技術分野】
本発明はディスクアレイの障害が発生したディスク記憶装置に保持されたデータを回復する方法に関する。
【0002】
【従来の技術】
計算機のデータを記憶する装置として、コストパフォーマンスが高い磁気ディスク記憶装置が一般的に使用される。磁気ディスクは2.5インチや3.5インチ程度の複数の磁気円盤と、各磁気円盤の両面に設けられた磁気ヘッドとを有し、後者によりデータが読み書きされる。磁気ディスク記憶装置の容量を増加するためには、磁気円盤の枚数を増やす方法と、各磁気円盤の記録密度を増加させる方法とがある。この2つの大容量化方法の相乗効果により、単体磁気ディスク記憶装置の容量は飛躍的に増加している。
【0003】
しかし、磁気ヘッドの移動や磁気円盤の回転はメカ的な動作であり、磁気ディスク記憶装置の性能の伸びは容量の伸びほど大きくない。この性能を高めるために、複数の磁気ディスク記憶装置を並列に動作させるディスクアレイと呼ばれる技術がある。ディスクアレイは、複数の磁気ディスク記憶装置に対し並列にデータを読み書きすることで性能を向上させることができる。例えば、単体磁気ディスク記憶装置のデータ転送性能が4Mバイト/秒の場合、4台の磁気ディスク記憶装置から並列にデータを読み書きすることで16Mバイト/秒の転送性能を得ることができる。
【0004】
また、ディスクアレイのもう一つの特徴は、単体磁気ディスク記憶装置よりも高い信頼性である。複数の磁気ディスク記憶装置を並列に動作させることで性能を向上させるが、それだけでは信頼性が低下してしまう欠点がある。つまり、単一のデータを複数の磁気ディスク記憶装置に格納しているため、磁気ディスク記憶装置のいずれかが障害を起こしただけで、データに欠損が生じてしまう。そこでディスクアレイではデータの格納時に誤り訂正符号と呼ばれる冗長データを磁気ディスク記憶装置のいずれかに格納する。誤り訂正符号として多くの場合にパリティが使用される。パリティを保持することで、磁気ディスク記憶装置のいずれかに障害が発生しても、欠損したデータ部分を回復することができる。例えば、4台の磁気ディスク記憶装置1,2,3,4のそれぞれに、次のような2進数のデータが格納されているとする。
【0005】
【数1】
磁気ディスク記憶装置1=(1001 1100 1010 0001)
磁気ディスク記憶装置2=(1111 0100 1011 1000)
磁気ディスク記憶装置3=(0101 1000 1110 1111)(1)
磁気ディスク記憶装置4=(1110 1001 0110 0011)
パリティは、異なるディスク上の対応する4つのビットの排他的論理和を算出することで得られる。例えば、上の例では以下のパリティが得られる。
【0006】
【数2】
磁気ディスク記憶装置5=(1101 1001 10010101) (2)
このように異なる磁気ディスク記憶装置に記憶され誤り訂正符号を作るのに使用されるデータおよび生成された誤り訂正符号とのグループを誤り訂正データグループという。誤り訂正符号がパリティであるときには、そのグループはパリティグループと呼ばれる。例えば、上記の例では、ディスク記憶装置1から5上の同じアドレスのデータが同一のパリティグループに属することになる。例えば磁気ディスク記憶装置3が障害を起こした場合は、以下のように磁気ディスク記憶装置1,2,4という3台のディスク記憶装置上のそれぞれデータと磁気ディスク記憶装置5に保持されたパリティとの排他的論理和を演算することにより、その障害を起こした磁気ディスク記憶装置3に記憶されていたデータを回復できる。
【0007】
ディスクアレイの障害回復方法としては、特開平7−152495には、ディスク記憶装置(以下、ドライブと呼ぶ)に障害状況の統計値を保持しておき、完全な障害が起こる前にドライブ交換を行うことでスペアドライブを不要にする方法も述べられている。しかし、通常はいずれかのドライブに障害が発生してから障害ドライブが正常なドライブに交換されている。
【0008】
一般に障害の管理単位は、ドライブである。障害が発生したドライブを正常なドライブにより交換した後、その障害が発生したドライブに記録されていたデータが他の複数のドライブに保持されているデータから回復される。回復されたデータは、障害が発生したドライブを置換した正常なドライブあるいはディスクアレイに予め設けられたスペアドライブに格納される。障害ドライブのデータの回復は、通常ある領域を単位にして行われる。典型的には、トラック単位に行われる。障害回復プログラムは障害ドライブの複数のトラックのそれぞれに対応して、対応するトラックのデータを回復するためのタスクを発行する。各タスクが実行されると、そのタスクは、他の複数のドライブの対応するトラックからデータおよびパリティを読み出し、それらを用いて回復対象のトラックのデータを回復し、正常なドライブあるいはスペアドライブの対応するトラックに書き込む。異なるトラックに対応するタスクが順次実行されるごとに、それぞれのトラックに対する回復動作が実行される。
【0009】
通常、一つのドライブは一つの領域として管理され、その領域内のデータが回復される順番は、データのドライブ内アドレスが小さい順である。一つのドライブを複数の領域(ボリウム)に分け、ボリウム別にデータを管理することも行われている。一つのドライブの容量が大きい場合にはこの管理が採用されている。そのドライブ内のデータを回復する場合でも、それぞれのボリウムごとにデータの回復が管理される。このように一つのドライブが複数のボリウムに分かれている場合でも、ドライブ内アドレスが小さいボリウム順にそれらのボリウムのデータが回復されている。
【0010】
全トラックのデータが回復されていないときにホストからいずれかのドライブに保持されたデータに対する入出力要求が発行されると、データ読み込みプログラムが新たにタスクとして障害回復のための複数のタスクの実行の合間に実行される。そのデータ読み込みプログラムでは、要求されたデータが正常なドライブに保持されている場合には、そのドライブからそのデータが読み出され、ホストに転送される。そのデータが障害が発生したドライブに保持されているときには、ディスクアレイは要求されたデータが回復済みか否か、すなわち、そのデータが属するトラックが既に回復済みか否かを判断する。要求されたデータが回復済みであれば、スペアドライブまたは交換ドライブからそのデータが読み出され、ホストに転送される。しかし、要求されたデータが回復されていない場合は、前述の障害回復処理と同じようにして要求されたデータが回復される。すなわち、障害が発生したドライブを除く複数のドライブから、要求されたデータと同じ誤り訂正グループに属するデータが読み出され、それらのデータに対して排他的論理和演算が行われ、要求されたデータが回復される。そのデータはホストに転送される。
【0011】
【発明が解決しようとする課題】
このような従来の障害回復方法では、障害の回復が完了していない段階でも、ホストからの入出力要求は実行されるようになっている。しかし、障害が発生したドライブに保持されたデータの内、まだ回復されていないデータを要求する入出力要求の処理時間は、回復済みのデータを要求する入出力要求の処理時間より遅くなる。各ドライブの容量が増加した場合に、そのドライブの回復時間が増大する。このため、上記問題はより顕著に現れる。このことは、ディスクアレイが複数のボリウムに分割されているときでも同じである。
【0012】
本発明の目的は、障害ドライブのデータを回復中に発生する、障害ドライブに保持されていたデータを要求する入出力要求の処理時間を実効的に短縮するディスクアレイのデータ回復方法を提供することである。
【0013】
【課題を解決するための手段】
上記問題を解決するために、本発明では、各ディスク記憶装置の複数の部分領域の各々に対応して、その部分領域に保持されたデータに対する外部装置からの入出力要求の発生数を計測し、上記複数のディスク記憶装置のいずれか一つに障害が発生したとき、そのディスク記憶装置の上記複数の部分領域に対してそれまでに計測された上記入出力要求の発生数に基づいて、それらの部分領域を順次選択する。
【0014】
上記障害が発生したディスク記憶装置に保持されたデータを回復するときには、上記複数の部分領域の各々に属する部分データに区分して、かつ、それらの部分領域が選択される順に従って順次回復する。
【0015】
これにより、入出力要求の発生頻度が大きい部分領域に属する障害ドライブのデータが優先的に回復される。この結果、これらの入出力要求の処理時間が増大するケースが減少する。
【0016】
より具体的には、上記計測では、前記複数のディスク記憶装置により構成される記憶領域をそれぞれ上記複数のディスク記憶装置の各々に属する部分を有するように分割して得られる、複数の横断的な部分領域の各々に対して、その横断的な部分領域に保持されたデータに対する外部装置からの入出力要求の発生数を計測し、上記障害が発生したディスク記憶装置の記憶領域の内、各横断的な部分領域に属する部分領域に対する入出力要求の発生数として、その横断的な部分領域に対して計測された入出力要求の発生数に比例する値を使用する。この横断的な部分領域としては、複数のボリウム領域の一つあるいは少なくとも一つのボリウム領域を分割して得られる複数の横断的な部分領域の一つが使用される。
【0017】
【発明の実施の形態】
以下、本発明に係るディスクアレイ障害回復方法を図面に示したいくつかの実施の形態を参照してさらに詳細に説明する。なお、以下においては、同じ参照番号は同じものもしくは類似のものを表すものとする。また、発明の第2の実施の形態以降においては、発明の第1の実施の形態との相違点を主に説明するに止める。
【0018】
<発明の実施の形態1>図1は、本発明によるディスクアレイ障害回復方法を適用する計算機システムの概略構成図を示したものである。101はホストプロセッサ(以下、ホストと呼ぶことがある)であり、122はディスクアレイ制御装置である。117〜121はドライブであり、ディスクアレイ制御装置122に接続される。ホスト101から入出力要求がディスクアレイ制御装置122に発行されると、ディスクアレイ制御装置122はその入出力要求を解釈し、ドライブ117〜121のいずれかに対し入出力動作を行う。ここでは5つのドライブ117〜121をドライブの例として示すのみであり、これらのドライブの数は適宜変更可能である。ドライブ121はスペアドライブである。スペアドライブ121には、ドライブ117〜120のいずれかのドライブが障害を起こし使用できなくなった場合に、障害を起こしたドライブのデータとして回復されたデータが書き込まれ、そのスペアドライブ121がその障害が発生したドライブの代わりに使用される。
【0019】
ディスクアレイ制御装置122は、ホスト制御部103、制御プロセッサ104、メモリ105、ドライブ制御部112〜116、およびこれらを接続するバス111から構成される。ホスト制御部103はホスト101から発行された入出力要求の受け付けや、処理終了をホストへ知らせる制御を行う。ドライブ制御部112〜116は、ドライブ117〜121に対応して設けられ、それぞれに対するデータの入出力制御を行う。ホスト制御部103とドライブ制御部112〜116は、制御プロセッサ104から起動/終了指示あるいはデータ転送指示が発行されときに動作する。制御プロセッサ104の動作は、メモリ108内に格納されたプログラムやテーブルにより制御される。
【0020】
障害管理プログラム131は、ドライブでの障害の発生を検出するプログラムで、公知の方法によりドライブでの障害の発生を検出する。例えば、上記読み込みプログラム106あるいは書き込みプログラムが発行するディスクアクセスコマンドとそれに対する応答を監視し、そのディスクアクセスコマンドに対する応答がアクセス先のドライブより所定の時間内に転送されて来たか否かを検出する。その応答がその時間内に転送されなかったときいには、ドライブに障害が発生したと判別し、メモリ内に設けられたドライブ管理テーブル(図示せず)にそのドライブでの障害発生を記憶する。障害回復プログラム109により障害ドライブのデータが全て回復され、スペアドライブ121に書き込まれたときに、スペアドライブを障害ドライブの代わりに使用する正常なドライブとしてそのドライブ管理テーブル(図示せず)に登録する。
【0021】
障害回復プログラム109は、常時起動され、ドライブ117〜120のいずれかに障害が発生したか否かを上記ドライブ管理テーブル(図示せず)を監視する。もしあるドライブに障害が発生したときには、そのドライブのデータを回復し、スペアドライブ121に書き込む。
【0022】
キャッシュ管理プログラム132はキャッシュ領域108へのアクセスを制御するプログラムである。キャッシュ領域108は、ドライブ117〜121から読み込まれたデータあるいはホスト101から書き込まれたデータを一時的に格納しておく領域である。ホスト101から要求され、いずれかのドライブから読み出されたブロックがキャッシュ領域108に保持されている状態で、同じデータの読み込みが再度ホスト101から要求された場合に、キャッシュ領域108からホスト101へそのデータを返送する。このことにより、入出力レスポンスを高速化することが可能となる。また、ホスト101から転送された書き込みデータは、一時的にこのキャッシュ領域に書き込まれ、その書き込みが完了した時点で、ホスト101に書き込み完了が通知され、その通知と並行してその要求されたデータがいずれかのドライブに書き込まれる。
【0023】
ディスクアレイ読み込みプログラム106は、ホスト101から発行された入力要求を制御し、ディスクアレイ書き込みプログラム107はホスト101から発行された出力要求を制御する制御プログラムである。
【0024】
複数のドライブにより構成される記憶領域は、それらを横断して存在する複数の領域、ここではボリウムに区分されている。頻度テーブル110は、各ボリウムごとにそのボリウムに対する入出力要求の発生数およびキャッシュリードヒット回数等の情報を記録する。本実施の形態では、いずれかのドライブに障害が発生した場合に、障害回復プログラム109が、その頻度テーブル110を参照して、その障害ドライブ内の複数のボリウムのデータを回復する順序を決定するところに特徴がある。
【0025】
図2に示すように、これらのドライブの互いに対応する位置には、同一誤り訂正データグループ、ここでは具体的にはパリティグループに属するデータあるいはパリティを保持する。各ドライブには、ブロックという一定の大きさのデータを単位として記憶される。図において、各ボリウム内に示された番号0,1,2およびP1等は、一つのブロックを示す。図では、ドライブ117〜120内のブロック0、1,2がデータブロックであり、ブロックP1はそれらから生成されたパリティを保持するブロックである。ブロック3,4,5とP2も同様である。本実施例ではこれらのドライブはレベルRAID5のディスクアレイを構成するように、ディスクアレイ制御装置122が動作する。パリティを保持する複数のブロックP1、P2、P3、P4、、、は、これらのドライブに分散して記憶されている。
【0026】
ホスト101は、ドライブ117〜120の領域を、ボリウム1(213)、ボリウム2(214)、ボリウム3(215)という3つの領域に分割して管理している。ボリウム213〜215は複数のドライブ117〜120に横断して定義される領域で、各ボリウムは、それぞれドライブ117〜120に属する領域を有する。これらの複数のドライブは、同一の誤り訂正データグループに属するデータを保持するドライブであり、論理グループとも呼ばれる。各ボリウムは、ホスト101の領域管理単位であり、本実施の形態では、見かけ上3つのドライブがホスト101に接続されていることになる。ここのボリウムの数3は一例であり、適宜変更可能である。ホスト101はボリウム213〜215を、異なるアプリケーションプログラム(図示せず)毎に割り当てたり、異なるユーザ毎に割り当てて使用する。それによりホスト101による領域管理が簡単になる。また複数のボリウムを使用することにより、アプリケーションプログラムやユーザ間の干渉をなくすことができるため、誤ってデータを上書きするような問題を回避することができる。本実施の形態では各ボリウムの容量は同一と仮定する。
【0027】
ホスト制御部103が入出力コマンドを受け取ると、制御プロセッサ104はそのコマンドが入力コマンドであるときには、ディスクアレイ読み込みプログラム106を起動し、そのコマンドが出力コマンドであるときには、ディスクアレイ書き込みプログラム107を起動する。また、制御プロセッサ104は、装置の起動時に障害回復プログラム109を起動する。
【0028】
ホスト101からディスクアレイ制御装置122に対して発行される入出力要求は、入出力コマンド200の形でホスト制御部103に与えられる。このコマンド内には、入出力対象となるボリウム(202)、入出力命令(203)、入出力位置(204)、入出力長(205)が格納されている。図2では、入出力コマンド200として、ボリウム3(213)のブロック2から1ブロック入力(READ)するための入力コマンドが示されている。ホスト101が発行する他のコマンドは、いずれかのドライブにデータを書き込む出力コマンドである。この出力コマンドの場合には、書き込むべきデータがホスト101からホスト制御部103に供給される。ホスト101は、複数のブロックの入出力を要求することができる。
【0029】
頻度テーブル110は、メモリ105上にあらかじめ作成され、適宜更新される。図3において、501はボリウム名であり、506は、各ボリュームごとに計測を開始した時刻である。計測開始時間506は入出力要求の発生頻度を求めるときの時間情報として使用される。502は、ホスト101より発行された各ボリュームに対するリード要求(入力要求)の数であり、503は、ホスト101より発行された各ボリュームに対するライト要求(出力要求)の数であり、504は、リード要求502の内で、キャッシュ領域108がヒットしたリード要求の数(ディスクキャッシュリードヒット回数)である。505は実効的な要求数である。これらのデータ502,503,504、505はキャッシュ管理プログラム132により更新される。このように、本実施の形態では、障害ドライブのデータを回復するときの回復順番として、複数のドライブにまたがるボリウムに対する入出力要求の発行数を計測している。これは、障害ドライブに対する入出力要求でなくても、同じボリウムの他のデータに対する入出力要求も、同じ障害ドライブに含まれた同じボリウムのデータの回復と衝突するので、同じボリウムに対する入出力要求の処理がそのボリウムのデータの回復処理の影響を受けるからである。
【0030】
実効的要求数505は、以下の算出式によってキャッシュ管理プログラム132により決定される。
【0031】
【数3】
実効的な要求数505=リード要求数502+ライト要求数503−ディスクキャッシュリードヒット回数504 (3)
リード要求数502とライト要求数503の和がホスト101からディスクアレイ制御装置122に発行されたリード要求、ライト要求の総数である。それらの要求の内で、リード要求に対してキャッシュ領域108がヒットしたときには、そのリード要求が要求するブロックはそのキャッシュ領域108からホスト101に供給されるために、いずれのドライブもアクセスされることはない。したがって、このようなアクセスは、ドライブに対する負荷にはならない。一方、ライト要求に対してキャッシュ領域108がヒットしたときには、そのライト要求が要求するブロックはそのキャッシュ領域108に一度書き込まれた後に、そのライト要求が指定するドライブに書き込まれる。したがって、キャッシュ領域108がヒットしたライト要求はドライブにとって負荷となる。したがって、上記実効的な要求数は、ホスト101からの総要求数の内で、ドライブに負荷となる要求の総数を表すことになる。ドライブ障害時に性能の問題が発生するのは、ホストが発行した入出力要求に対してドライブまでアクセスが至った場合であり、ホストのアクセスが局所的でキャッシュ領域108にヒットするケースが多い場合は大きな性能劣化にはならない。従って、回復の優先順位による効果をより的確にするために、ディスクキャッシュリードヒットの回数は、優先順位の決定に入れないほうがよい。
【0032】
計測開始時間506は、入出力要求の発生頻度を求めるときの時間情報として使用される。ボリウム毎に計測開始時間を設ける理由は、より正確にアクセス頻度を求めるためである。全ボリウムは必ずしもディスクアレイ制御装置122の電源が入ると同時に使用され始めるわけではない。電源が入ってからしばらくして使用され始めるボリウムの場合、電源が入ってから計測を開始すると頻度が小さく見えてしまう。そのため、計測開始の契機としてボリウム毎に、ディスクアレイ制御装置122の電源が入ってから初めて入出力要求を受け付けたとき等が適切である。したがって、計測開始時間506は、ディスクアレイ読み込みプログラム106あるいはディスクアレイ書き込みプログラム107により、各ボリウムに対する入出力要求を最初に処理するときにセットされる。なお、ディスクアレイ制御装置122の電源が入ると同時に全てのボリウムが使用される場合には、ディスクアレイ制御装置122の電源が入れられたと同時に計測を開始する方法も考えられる。この場合には、初期化プログラムが電源オン時にこの計測開始時間506をセットすればよい。
【0033】
ボリウム回復済みフラグ507は、障害ドライブ内の、各ボリウムのデータが回復済みであるか否かを示すフラグである。さらに、トラック回復済みフラグ508は、回復が未済みのボリウムの中で各トラックが回復済みであるか否かを示すフラグである。以下に説明するように、障害ドライブ内のあるボリウムのデータを回復するときに、各回復処理実行単位領域、具体的には各トラックのデータを回復する処理が順次異なるトラックに対して実行される。フラグ507,508は障害回復プログラム109により更新される。
【0034】
以下に説明するように、本実施の形態では障害が発生したドライブ内のデータの回復順序を、それらのデータに対するそれまでの入出力要求の発生数、より具体的には入出力要求の発生頻度に基づいて決める。すなわち、入出力要求の発生頻度が高かったデータを先に回復する。このためには、頻度テーブルとしては、本来的には、各ボリウムに対する入出力要求の発生数等の情報を、各ボリウム別、各ドライブ別に計測することが望ましいし、そのようにすることが可能である。
【0035】
しかし、一般には、同じボリウム内のデータに対する入出力要求の発生数等の情報はドライブによっては大きくは変わらないことが期待される。すなわち、あるボリウムのあるデータに対する入出力要求が多いときには、一般にはそのデータの近傍のデータに対する入出力要求も多いことになる。その結果、同じボリウムに属するデータに対する入出力要求の発生数は、ドライブによっては大きくは異ならないことが予想される。したがって、本実施の形態では、頻度テーブル110にて管理するデータを少なくするための一つの方法として、各ボリウムに対する入出力要求等の情報を計測し、そのボリウムのデータを保持する複数のドライブに対する入出力要求の発生数は、こうして計測された入出力要求の発生数に比例していると仮定し、後に説明する、データの回復順を決定するときには、あるボリウムに対してこうして計測された発生数を、そのボリウムに属する、障害が発生したドライブに保持されていたデータに対するそれまでの入出力要求の発生数として使用する。同様に、他の情報、例えば、計測開始時間もドライブに依らないで同じであるとして、同一のボリウムに対して計測されたデータを使用する。
【0036】
図4は、障害回復プログラム109のフローを示している。本処理は、ホストから要求される入出力要求の処理とは独立に実行される。実行の契機は、前述の通り、障害管理プログラム131によりドライブの障害が検知された時である。ステップ601では、ドライブに障害が発生したかどうかを判断する。この判断は、障害管理プログラム131が障害を検出したときに、メモリ105に設けられたドライブ管理テーブル(図示せず)に書き込む障害発生情報を監視して行う。その結果、ドライブ障害が発生していない場合は回復処理を行わず処理を終了する。障害が発生している場合はステップ602に移る。ステップ602では、頻度テーブル110(図3)を参照し、回復が完了していないボリウムの中から、入出力要求の発生頻度が最も高いボリウムを選択する。回復が完了していないボリウムは頻度テーブル110のボリウム回復済みフラグ507を参照することで選択可能である。また要求発生頻度は、頻度テーブル110の内容から、ボリウム毎に以下の算出式によって求める。
【0037】
【数4】
入出力要求頻度=実効的な要求数505/(現時刻−計測開始時刻506)(4)
ステップ603ではステップ602で選択されたボリウムの障害回復を行う。回復の方法は、障害が発生していない他の複数のドライブのデータ(パリティを含む)を読み込み、同一ドライブアドレス毎に排他的論理和を演算することにより、障害ドライブのデータを回復する。回復されたデータをスペアドライブの同一ドライブアドレスに書き込む処理を、当該ボリウムの領域に対して実行する。この際、障害回復プログラム109は、それ自体公知のように、回復対象のボリウムを複数の回復実行単位領域に分け、それらの単位領域のデータの回復を順次実行する。単位領域のデータを回復する処理は、タスクとして制御プロセッサ104により実行される。ただし、この時トラック回復済みフラグ508を参照し、当該トラックが回復済みである場合は、当該トラックの回復処理は行われない。これは、障害回復プログラム109がデータを回復していない領域に対してホストプロセッサ101から書き込みまたは読み込み要求が発生した場合は、後で述べるディスクアレイ読込みプログラム106またはディスクアレイ書き込みプログラム107により当該ボリウムが部分的に回復されるためである。ホストプロセッサは、その単位領域のデータの回復が終了したときには、次の単位領域のデータに対する回復処理を実行する新たなタスクとして起動される。本実施の形態では、通常そうであるように、トラックが障害回復処理の実行の単位領域とする。また、一つの単位領域のデータを回復したときには、頻度テーブル110内の、その単位領域に対する回復済みフラグ508をセットする。こうして、そのボリウムの全てのトラックのデータを回復したときには、ステップ604において、頻度テーブル110内の、そのボリウムに対するボリウム回復済みフラグ507をセットする。
【0038】
ステップ605では、障害ドライブ内の全てのボリウムに属するデータを回復したかどうかを判定する。未回復のボリウムがある場合はステップ602に戻り、未回復のボリウムに対して以上の処理を繰り返す。全てのボリウムが回復されたときには、障害回復プログラム109を終了する。
【0039】
以上の処理により、ホストからの入出力要求の発生頻度が高い順番にボリウムを回復することができる。前述のように、ディスクアレイは、回復が完了した領域へのアクセスは速いが、回復が完了していない領域へのアクセス時には単一入出力要求のために全てのドライブが占有されてしまう問題があり、ディスクアレイの処理性能が劣化する。本処理では、よくアクセスする領域のデータを優先して回復することで、この問題を最小限に抑えることができるようになる。この効果は、ドライブの容量が大きくなるほど大きくなる。これは、ドライブ容量が大きくなると回復時間も増加するため性能劣化の問題となる時間が増すためである。
【0040】
図5は、ディスクアレイ読み込みプログラム106の処理フローを示している。ステップ701では、ホストから転送された入力コマンド要求が要求するデータを保持するドライブを選択する。具体的には、入力コマンドが指定するボリウム番号202とブロック番号204、ブロック数205とから、これらで指定されるブロックが保持されているドライブを選択する。この選択はそれ自体公知の方法により実行される。例えば、各ボリウムごとにそれに属する各ブロックがどのドライブに保持されているかを示すメモリ105に保持されるアドレス管理テーブル(図示せず)その他の情報が使用される。入力要求により複数のブロックが要求されたときには、それぞれのブロックごとに、それが属するドライブが判断され、それらのブロックが異なるドライブに属すると判断されたときには、以下の処理はそれらのドライブの各々に対して実行される。なお、この入力コマンドがそれが指定するボリウムに対する最初の入出力要求であるときには、ディスクアレイ読み込みプログラム106は、頻度テーブル110中のそのボリウムに対する計測開始時間506をセットする。
【0041】
入力ステップ702では、当該ドライブが障害を起こしているかどうかを判断する。すでに述べたように、障害が発生しているか否かは、障害管理プログラム131により検出され、このプログラムが管理している、メモリ105内に設けられたドライブ管理テーブル(図示せず)に反映されている。ステップ702では、このテーブルを見て、上記ドライブに障害が発生ししているか否かを判別できる。上記ドライブに発生していない場合にはステップ706に移り、選択されたドライブからデータを読み込む。具体的には、ホスト101から要求されたブロックを当該ドライブから読み出すディスクアクセスコマンドをキャッシュ管理プログラム132に対して発行する。キャッシュ管理プログラム132は、このコマンドに応答してキャッシュ領域108にそのブロックが保持されているかをチェックする。
【0042】
このキャッシュ領域108がヒットしたときには、ヒットしたブロックをキャッシュ領域108から読み出し、ディスクアレイ読み込みプログラム106に渡す。このとき、キャッシュ管理プログラム132は、頻度テーブル110内のリード要求数502,キャッシュリードヒット数504を更新する。この場合には実効的要求数505は変更を要しない。また、キャッシュ管理プログラム132上記ディスクアクセスコマンドをドライブ制御部、例えば112には発行しない。しかし、キャッシュ領域108がミスヒットしたときには、上記ディスクアクセスコマンドをドライブ制御部、例えば、112に対して発行し、要求されたブロックを読み出し、ディスクアレイ読み込みプログラム106に渡す。このデータはキャッシュ領域108にも記憶する。このときに、キャッシュ管理プログラム132は、頻度テーブル110内のリード要求数502、実効的要求数505を更新する。こうして、ステップ706が終了し、次のステップ705にて、読み込みプログラム106は、当該ブロックをホスト制御部103を介してホスト101へ転送する。ホスト101はこのデータを入力バッファ206に書き込む。
【0043】
ステップ702において、要求されたデータを保持するドライブに障害が発生していると判断された場合は、ステップ703に移り、要求されたブロックがスペアドライブに回復されているかどうか判断する。この判断は、頻度テーブル110内のトラック回復済みフラグ508に基づいて行われる。すなわち、そのブロックが属するトラックのデータが回復済みであるかを、そのトラックに対するフラグ508により判断する。すでに説明したように、障害が発生したドライブのデータの回復は、そのドライブの各ボリウムのデータを、トラックを単位として行われる。
【0044】
ステップ703において、要求されたブロックがスペアドライブに回復されていないと判定された場合は、ステップ707に移る。ステップ707では、選択されたドライブの当該ブロックを回復する。この回復のためには、スペアドライブと障害が発生しているドライブを除く他の複数のドライブから、当該ブロックと同じパリティグループに属する複数のデータブロックと一つのパリティブロックを読み出し、それらの排他的論理和を取る。これらのブロックの読み出しのために、障害が発生したドライブとスペアドライブ以外のドライブの各々に対して、ディスクアクセスコマンドが発行される。具体的には、図6に示すように、ドライブ119に障害が発生している状態で、ブロック2に対して入力コマンド200がホスト101から発行され、かつ、そのブロックがスペアドライブ121にまだ回復されていない場合、ドライブ117,118、120から、ブロック2と同じパリティグループに属するブロック0,1,およびパリティブロックP5を読み出し、それらのブロックの対応するビットの排他的論理和により、ブロック2の対応するビットが回復される。先に延べた通り、回復の単位はトラックであり、実際には当該ブロックが含まれるトラックが回復される。回復されたトラックは障害回復プログラム109で述べた通りスペアドライブに書き込まれると共に、当該トラックのトラック回復済みフラグがセットされる。回復されたトラックの中から当該ブロックのみ抽出し、ステップ705により先に述べたのと同じ方法でホスト101に転送される。これらのディスクアクセスコマンドの各々の実行時には、先にステップ706に関して述べたように、キャッシュ管理プログラム132が介在する。
【0045】
もし、ステップ703において、そのトラックのデータが回復済みであると判断された場合には、ステップ704に移り、スペアドライブ121から該当ブロック、今の例では2を、図7に示すように読み出す。この読み出しのためにはディスクアクセスコマンドが発行されることには変わりはない。こうして読み出されたブロックは、ステップ705によりホスト101に転送される。以上によりディスクアレイ読み込みプログラム106による入力コマンド200の処理が終了する。
【0046】
図8は、ディスクアレイ書き込みプログラム107の処理フローを示している。ステップ801では、ホストから転送された出力要求が指定する、更新されるべきブロック(旧データ)を保持しているドライブとそのブロックに対する更新前のパリティ(旧パリティ)を保持しているドライブを選択する。なお、この出力コマンドがそれが指定するボリウムに対する最初の入出力要求であるときには、ディスクアレイ書き込みプログラム107は、頻度テーブル110中のそのボリウムに対する計測開始時間506をセットする。
【0047】
ステップ802では、これらのドライブのいずれかに障害を起こしているかどうかをディスクアレイ読み込みプログラム106が実行したのと同様な方法で判断する。ここでは簡単化のためにパリティ用のドライブには障害が発生していないと仮定する。上記旧データ用のブロックに障害が発生していない場合にはステップ808に移り、出力要求が指定する更新前のブロック(旧データ)を読み出す。この読み出しは先にディスクアレイ読み込みプログラム106に関して述べたと同じごとくにキャッシュ管理プログラム132を介在して行われる。但し、この書き込みプログラム107の実行時には、キャッシュ管理プログラム132は、頻度テーブル110内のライト要求数503、実効的要求数506を更新する。その後ステップ805に移る。ステップ805では、要求されたブロックに対する旧パリティを読み出す。ステップ806では、旧データと旧パリティとホストから転送された書き込みすべきデータ(新データ)との排他的論理和を演算することにより、新パリティを生成する。ステップ807では新パリティと、ホストから転送されたデータとをそれぞれ所定のドライブに書き込む。
【0048】
ステップ802において、旧データ用のドライブに障害が発生していると判断された場合には、ステップ803に移り、要求されたブロックがスペアドライブに回復されているかどうか判断する。この判別は、入力要求における処理703(図5)と同様に行われる。そのブロックが回復済みであればステップ804に移り、スペアドライブから該当ブロックの旧データを読み出した後、ステップ805に移る。その後の処理は、すでに述べたのと同じである。
【0049】
ステップ803において、要求されたブロックのデータがスペアドライブに回復されていないと判断された場合は、ステップ809に移る。ステップ809では、旧データ用のドライブの当該ブロックを回復する。この回復も入力要求に対する回復処理707(図5)と同じである。その後、ステップ805から807がすでに述べたように実行される。
【0050】
なお、図8では、旧パリティ用のドライブには障害がないと仮定したが実際にはこのドライブに障害があるか否かを判別し、そのドライブに障害があるときには、旧パリティを回復する処理を実行するように、図8を変形する必要がある。
【0051】
<発明の実施の形態2>
実施の形態1では、ディスクアレイが複数のボリウムに分割されている場合に障害回復を実行するボリウムの順をホストからの入出力要求の発生頻度に応じて実行することを示した。本実施の形態では、ディスクアレイが大容量のボリウムから構成されている場合に、ボリウムを複数の部分領域に分け、それらのデータの回復順序をそれらの領域へのホストからの入出力要求の発生頻度に依存して変更する。
【0052】
図9は本実施の形態におけるディスクアレイのボリウムの割り当てを示している。本実施の形態では、ボリウム901が実施の形態1のボリウム213等よりも容量が大きいと仮定する。図10に示すように、頻度テーブル110は、ボリウム901内を複数の部分領域に分割し、それぞれの部分領域に対して実施の形態1と同じ情報を有する。ここでは、ボリウム901は、ブロック0〜5とそれらに対するパリティを保持するのに使用されている領域と、ブロック6〜11とそれらに対するパリティを保持するのに使用されている領域と、ブロック12〜17とそれらに対するパリティを保持するのに使用されている領域に区分されている。これらの部分領域の大きさは同じと仮定する。
【0053】
障害が発生したドライブのデータの回復を行う場合に、一つのボリウムをその先頭から実行するのではなく、これらの部分領域に対する、入出力要求の発生頻度に基づいて、これらの部分領域のデータ回復順序を決めることができる。
【0054】
<変形例>
本発明は以上の実施の形態に限定されるのではなく、以下に例示する変形例を含めいろいろの変形例により実現可能である。
【0055】
(1)実施の形態2において、ディスクアレイ内に上記の大きなボリウムが複数ある場合にも、各ボリウムを部分領域に分割し、それらの複数のボリウムに対して得られた複数の部分領域について、実施の形態2と同様にしてデータ回復順序を決定することができる。
【0056】
(2)上記実施の形態1では各ボリウムは互いに同じ大きさであると仮定した。実施の形態2でも各部分領域は同じ大きさであると仮定した。しかい、いずれの実施の形態においても、このような大きさと異なる複数のボリウムあるいは部分領域が存在する場合にもそれぞれの実施の形態は適用できる。
【0057】
(3)上記実施の形態1,2においてはいずれもディスクアレイ内にスペアドライブを有していた。しかし、本発明は、スペアドライブを有しないで、障害が生じたドライブを他の正常なドライブにより交換する形式のディスクアレイにも適用できる。
【0058】
(4)本発明は、RAID5以外のディスクアレイにも適用できる。
【0059】
【発明の効果】
本発明によれば、障害を起こしたドライブのデータの回復中に発行される入出力要求の処理時間が従来より実効的に短縮される。
【図面の簡単な説明】
【図1】本発明によるデータ回復方法を適用するディスクアレイの全体構成図。
【図2】図1の装置におけるディスクアレイのボリウム構造とホストプロセッサからのコマンドの例を示す図。
【図3】図1の装置に使用する頻度テーブルの構成を示す図。
【図4】図1の装置における障害回復プログラムのフローチャート。
【図5】図1の装置におけるディスクアレイ読み込みプログラムのフローチャート。
【図6】図1の装置における入力コマンドの第1の処理態様を説明する図。
【図7】図1の装置における入力コマンドの第2の処理態様を説明する図。
【図8】図1の装置におけるディスクアレイ書き込みプログラムのフローチャート。
【図9】本発明によるデータ回復方法を適用する他のディスクアレイでのボリウム構成を示す図。
【図10】図9の装置に使用する頻度テーブルの構成を示す図。
【符号の説明】
117〜121:ドライブ
Claims (8)
- ホストプロセッサからの入出力要求を処理する複数のディスク記憶装置を有し、複数のデータとそれらに対する誤り訂正データとからそれぞれなる複数の誤り訂正データグループを上記複数のディスク記憶装置に記憶し、いずれかのディスク記憶装置に障害が発生したときには、当該障害が発生したディスク記憶装置以外の他の複数のディスク記憶装置に保持された複数のデータおよび誤り訂正符号とに基づいて上記障害が発生したディスク記憶装置に格納されたデータを回復し、回復されたデータを上記障害が発生したディスク記憶装置に代えて使用する正常なディスク記憶装置に記憶するディスクアレイにおいて、
複数のディスク記憶装置に横断的に存在する、該ホストプロセッサの領域管理単位として定義された論理的な領域である複数のボリウムに対応して、該ボリウムに保持されたデータに対する外部装置からの入出力要求の発生数を計測し、上記複数のディスク記憶装置のいずれか一つに障害が発生したとき、そのディスク記憶装置の上記複数のボリウムに対してそれまでに計測された上記入出力要求の発生数に基づいて、それらのボリウムを順次選択し、上記障害が発生したディスク記憶装置に保持されたデータを、上記複数のボリウムの各々に属するデータに区分して、かつ、それらのボリウムが選択される順に従って順次回復するディスクアレイにおけるデータ回復方法。 - 上記ボリウムの選択は、各ボリウムに対する入出力要求の発生頻度に依存して行う請求項1記載のディスクアレイにおけるデータ回復方法。
- 上記各ボリウムに対する入出力要求の発生頻度は、各ボリウムに対して発生した入出力要求の総数とそのボリウムの経過時間との比である請求項2記載のディスクアレイにおけるデータ回復方法。
- 各ボリウムの前記経過時間は、前記ディスクアレイの電源投入後そのボリウムに対する最初の入出力要求が外部装置から発行されてから上記一つのドライブに障害が発生するまでの経過時間である請求項3記載のディスクアレイにおけるデータ回復方法。
- 上記ディスクアレイは外部装置から要求され、上記複数のディスク記憶装置のいずれかから読み出されたデータおよび上記外部装置から要求され、当該外部装置から供給された上記複数のディスク記憶装置に書き込むべきデータとを一時的に保持するディスクキャッシュを有し、上記各ボリウムに対する入出力要求の発生数の計測に当たっては、そのボリウムに対して発生した入力要求の内、上記ディスクキャッシュにヒットした入力要求は計測しない請求項1から4のいずれか一つに記載のディスクアレイにおけるデータ回復方法。
- 上記障害が発生したドライブのいずれかの部分データを回復中に外部装置から上記障害が発生したドライブに保持されたいずれかのデータに対する入出力要求が発行されたときに、その入出力要求が指定するデータが上記交代用のディスク記憶装置に回復済みであるか否かを判別し、その指定されたデータが回復済みであるときには、上記交代用のディスク記憶装置に対して上記入出力要求を実行し、その指定されたデータが回復済みでないときには、その指定されたデータが属する部分のデータの全体が回復されるのを待たないで、その指定されたデータを上記障害が発生したディスク記憶装置以外の他の複数のディスク記憶装置に保持された複数のデータおよび誤り訂正符号とに基づいて回復するステップをさらに有する請求項1から5のいずれか一つに記載のディスクアレイにおけるデータ回復方法。
- 上記計測では、前記複数のディスク記憶装置により構成される記憶領域をそれぞれ上記複数のディスク記憶装置の各々に属する部分を有するように分割して得られる、複数の横断的なボリウムの各々に対して、その横断的なボリウムに保持されたデータに対する外部装置からの入出力要求の発生数を計測し、上記障害が発生したディスク記憶装置の記憶領域の内、各横断的なボリウムに属するボリウムに対する入出力要求の発生数として、その横断的なボリウムに対して計測された入出力要求の発生数に比例する値を使用する請求項1から6のいずれか一つに記載のディスクアレイにおけるデータ回復方法。
- 上記少なくとも一つのボリウムは更に複数のディスク記憶装置に横断的に分割された複数の部分領域を有し、上記入出力要求の発生数は該部分領域に対応して計測され、該部分領域に対する入出力要求の頻度に基いてデータ回復の順序を決める請求項1記載のディスクアレイにおけるデータ回復方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP18244697A JP3573599B2 (ja) | 1997-07-08 | 1997-07-08 | ディスクアレイにおけるデータ回復方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP18244697A JP3573599B2 (ja) | 1997-07-08 | 1997-07-08 | ディスクアレイにおけるデータ回復方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH1124850A JPH1124850A (ja) | 1999-01-29 |
JP3573599B2 true JP3573599B2 (ja) | 2004-10-06 |
Family
ID=16118413
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP18244697A Expired - Fee Related JP3573599B2 (ja) | 1997-07-08 | 1997-07-08 | ディスクアレイにおけるデータ回復方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3573599B2 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2002023968A (ja) * | 2000-07-04 | 2002-01-25 | Mitsubishi Electric Corp | 半導体記憶装置の制御装置およびフラッシュメモリストレージシステム |
WO2009157086A1 (ja) * | 2008-06-27 | 2009-12-30 | 富士通株式会社 | Raid装置並びにその制御装置および制御方法 |
US8285952B2 (en) | 2009-09-17 | 2012-10-09 | Hitachi, Ltd. | Method and apparatus to utilize large capacity disk drives |
-
1997
- 1997-07-08 JP JP18244697A patent/JP3573599B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH1124850A (ja) | 1999-01-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5778426A (en) | Methods and structure to maintain a two level cache in a RAID controller and thereby selecting a preferred posting method | |
US6760814B2 (en) | Methods and apparatus for loading CRC values into a CRC cache in a storage controller | |
JP4372134B2 (ja) | データ比較機能を有するストレージシステム | |
US5463765A (en) | Disk array system, data writing method thereof, and fault recovering method | |
JP2501752B2 (ja) | コンピユ―タ・システムのストレ―ジ装置及びデ―タのストア方法 | |
JP3129732B2 (ja) | コピーバックキャッシュを有する記憶装置アレイ | |
US20030236944A1 (en) | System and method for reorganizing data in a raid storage system | |
JPH023215B2 (ja) | ||
JP2004213647A (ja) | データ記憶装置およびシステム用のログ構造の書込みキャッシュ | |
JPH07210329A (ja) | シーク・アフィニテイ及び書き込み感度を保つための方法、複数トラックのデータをデステージするための方法及びdasdサブシステム | |
AU1578092A (en) | Cache memory system and method of operating the cache memory system | |
JPH05241957A (ja) | 予測性トラックテーブルを用いたレコード更新方法 | |
JP3260999B2 (ja) | ディスク制御装置の制御方法 | |
US7398448B2 (en) | Storage system has the function of preventing drive write error | |
KR0162121B1 (ko) | 개선된 데이터 기억장치 및 이 기억장치에 데이터를 기억시키는 방법 | |
JP3270959B2 (ja) | ディスクアレイ装置におけるパリティ格納方法およびディスクアレイ装置 | |
US20040133741A1 (en) | Disk array apparatus and data writing method used in the disk array apparatus | |
JP3573599B2 (ja) | ディスクアレイにおけるデータ回復方法 | |
JPH0877074A (ja) | フラッシュメモリを用いた記憶装置システム | |
JPH1185589A (ja) | 情報記憶装置および同装置に適用される管理データ再構築方法 | |
JP3615274B2 (ja) | ファイル制御装置 | |
KR19980047273A (ko) | 레이드 레벨 5 시스템에서 캐쉬 관리 방법 | |
JP3845239B2 (ja) | ディスクアレイ装置及びディスクアレイ装置における障害復旧方法 | |
JP4131953B2 (ja) | ファイル制御装置 | |
JP3202550B2 (ja) | ディスクアレイサブシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040330 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040528 |
|
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: 20040622 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040629 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070709 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080709 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080709 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090709 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090709 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100709 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100709 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120709 Year of fee payment: 8 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130709 Year of fee payment: 9 |
|
LAPS | Cancellation because of no payment of annual fees |