JP2015222454A - Ｒａｉｄ障害自己修復装置 - Google Patents

Abstract

【課題】予備のストレージ装置を用いることなく、障害の発生したストレージ装置の修復可能性を判断し、当該ストレージ装置の修復が完了した後にＲＡＩＤ装置をデグレード状態から自動復帰させる。【解決手段】デグレード通知に基づく障害発生履歴から、ストレージ装置４の修復可能性を判断する障害統計管理機能部５１と、障害統計管理機能部５１により修復可能であると判断された場合に、ストレージ装置４の修復状況を監視するストレージ状態監視機能部５２と、障害統計管理機能部５１またはストレージ状態監視機能部５２により修復不可能であると判断された場合に、ストレージ装置４の故障を通知する異常状態通知機能部５３と、ストレージ状態監視機能部５２により修復処理が完了したと判断された場合に、ストレージ装置４をＲＡＩＤ装置に復帰させるＲＡＩＤ復帰処理機能部５４とを備えた。【選択図】図１

Description

この発明は、複数のストレージ装置をまとめて一台の装置として管理するＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）技術に関し、いずれかのストレージ装置において修復処理が発生した場合に、修復処理を終えたストレージ装置を自動でＲＡＩＤ装置に復帰させるＲＡＩＤ障害自己修復装置に関するものである。

ＲＡＩＤとは、複数のストレージ装置（例えばＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）など）を仮想的に一台のストレージ装置として運用する技術であり、ストレージ装置に保存したデータの冗長性の向上を目的とする。ＲＡＩＤ装置としては、例えば、図１４に示すように、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）がＳ／Ｗ（ＳｏｆｔＷａｒｅ）的に機能を提供する構成（Ｓ／Ｗ−ＲＡＩＤ）や、図１５に示すように、専用Ｈ／Ｗ（ＨａｒｄＷａｒｅ）により実現する構成（Ｈ／Ｗ−ＲＡＩＤ）がある。

なお、ＲＡＩＤは、ストレージ装置の構成に応じてＲＡＩＤ０、ＲＡＩＤ１やＲＡＩＤ５などいくつかの種類が存在するが、以下では特に断りなき場合、「ＲＡＩＤ」とはＲＡＩＤ１を示すものとする。

そして、現在のストレージ装置は、ストレージ装置内部にて読込み処理や書込み処理の異常が発生すると、この異常を検知してセクタ再配置などの修復処理を実行する。しかしストレージ装置の修復処理では再配置先セクタの検索などを要するため、修復完了までに要する時間を事前に知ることはできない。また、修復処理はストレージ装置内部のマイコンが実施しており、修復処理中はマザーボードとの通信処理を停止するストレージ装置が一般的である。

一方、ストレージ装置の接続に用いられる通信規格（例えばＳｅｒｉａｌ ＡＴＡなど）では書込み完了割込みの応答時間が規定されている。一例として、ＳＡＴＡ通信規格によるストレージ装置への書込み処理通信では、ストレージ装置外部からストレージ装置へ書込み要求を発行した後、３０秒以内にストレージ装置から書込み完了割込みが戻る必要がある。

しかしながら、修復処理中のストレージ装置に書込み処理を行った場合、ストレージ装置の修復処理により書込み完了割込みが規定時間を超過する場合がある。この場合、ストレージ装置通信は通信規格上の途絶と扱われる。

ＲＡＩＤ運用時、ＲＡＩＤ装置のストレージアクセス処理は、ＲＡＩＤ装置を構成する全てのストレージ装置から書込み完了割込みが返ることで完了する。すなわち、１台でも書込み完了割込みを返さないストレージ装置が存在すると、図１６に示すように、ＲＡＩＤ装置のストレージアクセスは遅滞状態となる。ＲＡＩＤ装置では、速やかにストレージアクセスを復帰させる必要がある。

そこで、書込み完了割込みが規定時間内に戻らなかったストレージ装置を速やかにＲＡＩＤ装置から切り離し、図１７に示すようにデグレード状態でＲＡＩＤ運用を継続する。
ここで、デグレード状態とはデータの冗長性が低下している状態であるが、ＲＡＩＤ装置がストレージアクセスを遅滞し続けるよりも健全である。

一方、ＲＡＩＤ装置から切り離されたストレージ装置は、その通信途絶の理由が修復処理であった場合、修復処理が完了すると健全な状態になる。しかしながら、このストレージ装置は、既にＲＡＩＤ装置から切り離された状態である。その結果、最終的には全てのストレージ装置が健全な状態となっているものの、ＲＡＩＤ装置はデグレード状態で運用されてしまうという課題がある。

そこで、上記課題を解決するために従来から以下のような方法が用いられている。
まず、第１の方法は、ＲＡＩＤ装置を保守する作業員（保守員）によってストレージ装置をＲＡＩＤ装置に復帰させる方法である。すなわち、保守員が、ＲＡＩＤ装置のデグレード状態を確認し、代替ストレージ装置または修復処理を終えたストレージ装置を手動でＲＡＩＤ装置に復帰させる。

第２の方法は、一定時間で修復処理を中断する機能を備えたストレージ装置を用いる方法である。この機能の呼称はストレージ装置の製造各社で異なる（例えば、Ｗｅｓｔｅｒｎ Ｄｉｇｉｔａｌ社ではＴＬＥＲ（Ｔｉｍｅ Ｌｉｍｉｔｅｄ Ｅｒｒｏｒ Ｒｅｃｏｖｅｒｙ）、Ｓａｍｓｕｎｇ社やＨｉｔａｃｈｉ社ではＣＣＴＬ（Ｃｏｍｍａｎｄ Ｃｏｍｐｌｅｔｉｏｎ Ｔｉｍｅ Ｌｉｍｉｔ）と呼ばれる）が、非特許文献１に開示されるように機能自体は同様であり、非特許文献２に機能の詳細が述べられている。この機能ではストレージ装置の修復処理を原因とする通信途絶が回避でき、これに伴うＲＡＩＤデグレードを回避することが可能となる。

第３の方法は、予め余分にストレージ装置を接続しておく方法である。例えばＲＡＩＤ１運用の場合、通常は２台のストレージ装置を要するが、装置には３台のストレージ装置を接続しておき、１台を予備として扱う。これにより、ＲＡＩＤ装置のデグレード状態を回避することが可能となる。

なお、特許文献１のように、ストレージ装置の通信状況及び障害発生頻度を監視してＲＡＩＤ装置からのストレージ装置の切り離しを判断する方式も考案されている。この方式はストレージ装置が故障する予兆を捉えて故障前にＲＡＩＤ装置からストレージ装置を切り離すことに貢献する。しかしながら、特許文献１に記載の障害値がしきい値を超えるまでストレージ装置の切り離しを行わないため、ＲＡＩＤ装置がストレージアクセスを遅滞し続ける可能性を有する。また本方式はストレージを切り離す判断に関するものであり、デグレード状態からの復帰には寄与しない。

特開平１０−２７５０６０号公報

Ｗｉｋｉｐｅｄｉａ、「Ｅｒｒｏｒ ｒｅｃｏｖｅｒｙ ｃｏｎｔｒｏｌ」、ｈｔｔｐ：／／ｅｎ．ｗｉｋｉｐｅｄｉａ．ｏｒｇ／ｗｉｋｉ／Ｅｒｒｏｒ＿ｒｅｃｏｖｅｒｙ＿ｃｏｎｔｒｏｌ Ｗｅｓｔｅｒｎ Ｄｉｇｉｔａ社著、「Ｔｉｍｅ−Ｌｉｍｉｔｅｄ Ｅｒｒｏｒ Ｒｅｃｏｖｅｒｙ（ＴＬＥＲ）」、ｈｔｔｐ：／／ｗｗｗ．ｗｄｃ．ｃｏｍ／ｅｎ／ｌｉｂｒａｒｙ／ｓａｔａ／２５７９−００１０９８．ｐｄｆ（２０１２年７月１２日現在リンク先消失）

しかしながら、上記第１の方法では、保守員が装置の設置された現地まで出向いてＲＡＩＤ装置を修復する必要があるため、保守員の人件費を要するという課題がある。また、この方法では、保守員が現地へ到着するまでデータの冗長性が損なわれた状態であるという課題もある。

また、上記第２の方法では、ストレージ装置内部の修復処理が打ち切られるため、ストレージ装置が異常を抱えたままＲＡＩＤ運用が継続されるという課題がある。この場合、エラーが生じた際のデータの再配置はＳ／Ｗ側が行うためデータの冗長状態は継続されるが、ストレージ装置の内部故障自体は修復されないままである。

また、上記第３の方法では、予備のストレージ装置を要するため、装置の費用が高価となるという課題がある。

この発明は、上記のような課題を解決するためになされたもので、予備のストレージ装置を用いることなく、障害が発生したストレージ装置の修復可能性を判断し、当該ストレージ装置の修復が完了した場合にＲＡＩＤ装置をデグレード状態から自動復帰させることができるＲＡＩＤ障害自己修復装置を提供することを目的としている。

この発明に係るＲＡＩＤ障害自己修復装置は、複数のストレージ装置からなるＲＡＩＤ装置において障害が発生したストレージ装置が切り離された旨を示すデグレード通知を受けることで、当該デグレード通知に基づく障害発生履歴から、当該障害が発生したストレージ装置の修復可能性を判断する障害統計管理機能部と、障害統計管理機能部によりストレージ装置が修復可能であると判断された場合に、当該ストレージ装置の修復状況を監視するストレージ状態監視機能部と、障害統計管理機能部またはストレージ状態監視機能部によりストレージ装置が修復不可能であると判断された場合に、当該ストレージ装置の故障を外部に通知する異常状態通知機能部と、ストレージ状態監視機能部によりストレージ装置の修復処理が完了したと判断された場合に、当該ストレージ装置をＲＡＩＤ装置に復帰させるＲＡＩＤ復帰処理機能部とを備えたものである。

この発明によれば、上記のように構成したので、予備のストレージ装置を用いることなく、障害が発生したストレージ装置の修復可能性を判断し、当該ストレージ装置の修復が完了した場合にＲＡＩＤ装置をデグレード状態から自動復帰させることができる。

この発明の実施の形態１に係るＲＡＩＤ障害自己修復装置が適用されたＲＡＩＤ装置の構成を示す図である。 この発明の実施の形態１における障害統計管理機能部の動作を示すフローチャートである。 この発明の実施の形態１における障害統計管理テーブルの構造を示す図である。 この発明の実施の形態１におけるストレージ状態監視機能部の動作を示すフローチャートである。 この発明の実施の形態１におけるストレージ状態監視テーブルの構造を示す図である。 この発明の実施の形態３における障害統計管理機能部の動作を示すフローチャートである。 この発明の実施の形態３における障害統計管理テーブルの構造を示す図である。 この発明の実施の形態６における障害統計管理機能部の動作を示すフローチャートである。 この発明の実施の形態６における障害統計管理テーブルの構造を示す図である。 この発明の実施の形態７における障害統計管理機能部の動作を示すフローチャートである。 この発明の実施の形態７における障害統計管理テーブルの構造を示す図である。 この発明の実施の形態８におけるＲＡＩＤ０の構成例を示す図である。 この発明の実施の形態８におけるＲＡＩＤ５の構成例を示す図である。 従来のＲＡＩＤ装置の構成例（Ｓ／Ｗ−ＲＡＩＤ）を示す図である。 従来のＲＡＩＤ装置の構成例（Ｈ／Ｗ−ＲＡＩＤ）を示す図である。 従来のＲＡＩＤ装置において、修復処理中のストレージ装置が存在する場合の状態を示す図である。 従来のＲＡＩＤ装置におけるデグレード動作を示す図である。

以下、この発明の実施の形態について図面を参照しながら詳細に説明する。
実施の形態１．
図１はこの発明の実施の形態１に係るＲＡＩＤ障害自己修復装置５が適用されたＲＡＩＤ装置の構成を示す図である。なお図１では、Ｓ／Ｗ実装のＲＡＩＤ装置（Ｓ／Ｗ−ＲＡＩＤ）を示し、また、ストレージ装置４ｂに障害が発生してＲＡＩＤ装置から切り離された状態を示している。
ＲＡＩＤ装置は、図１に示すように、アプリケーション１、ＲＡＩＤ管理Ｓ／Ｗ（ＲＡＩＤ管理機構）２、ストレージドライバ３ａ，３ｂ、ストレージ装置４ａ，４ｂおよびＲＡＩＤ障害自己修復装置５から構成されている。なお以下において、特に区別する必要がない場合には、ストレージドライバ３ａ，３ｂおよびストレージ装置４ａ，４ｂを単にストレージドライバ３およびストレージ装置４と称す。

アプリケーション１は、ＲＡＩＤ管理Ｓ／Ｗ２に対してストレージ装置４へのデータ書込み要求を行い、それに対する応答（データ書込み応答）を受けるものである。また、アプリケーション１は、ストレージ故障通知機能部１１を有している。ストレージ故障通知機能部１１は、ＲＡＩＤ障害自己修復装置５からのストレージ故障通知を受けて、該当するストレージ装置４の故障を外部（例えば保守員）に通知するものである。

ＲＡＩＤ管理Ｓ／Ｗ２は、アプリケーション１からの要求に応じて、ストレージドライバ３にデータ書込みを指示するものである。そして、ストレージドライバ３から完了通知を受けた場合には、データ書込み応答をアプリケーション１に出力する。また、ＲＡＩＤ管理Ｓ／Ｗ２は、ストレージ装置４に障害が発生し、ＲＡＩＤデグレードを行ってストレージドライバ３をＲＡＩＤ管理Ｓ／Ｗ２から切り離した場合、その旨をＲＡＩＤ障害自己修復装置５へ通知する機能を有している（デグレード通知）。さらに、ＲＡＩＤ障害自己修復装置５のストレージ復帰処理によりストレージ装置４がＲＡＩＤ装置に復帰した後、ＲＡＩＤ管理Ｓ／Ｗ２は当該ストレージ装置４に対するＲＡＩＤ同期を開始する。

ストレージドライバ３は、ＲＡＩＤ管理Ｓ／Ｗ２からの指示に応じて、ストレージ装置４に対してデータ書込みを指示するものである。そして、ストレージ装置４から書込み完了割込みを受けた場合には、完了通知をＲＡＩＤ管理Ｓ／Ｗ２に出力する。

ストレージ装置４は、ストレージドライバ３からの要求に応じて、データ書込みを行うものである。そして、上記処理が完了した後、完了割込みをストレージドライバ３に通知する。

ＲＡＩＤ障害自己修復装置５は、ＲＡＩＤ管理Ｓ／Ｗ２からのデグレード通知に基づいて、障害が発生したストレージ装置４の修復可能性を判断し、当該ストレージ装置４の修復処理が完了した場合にＲＡＩＤ装置に自動的に復帰させる機能も有している。このＲＡＩＤ障害自己修復装置５は、障害統計管理機能部５１、ストレージ状態監視機能部５２、異常状態通知機能部５３およびＲＡＩＤ復帰処理機能部５４から構成されている。

障害統計管理機能部５１は、ＲＡＩＤ管理Ｓ／Ｗ２からデグレード通知を受けることで、当該デグレード通知に基づくストレージ装置４の障害発生履歴から、障害が発生したストレージ装置４の修復可能性を判断するものである。

ストレージ状態監視機能部５２は、障害統計管理機能部５１によりストレージ装置４が修復可能であると判断された場合に、当該ストレージ装置４の修復状況を監視するものである。

異常状態通知機能部５３は、障害統計管理機能部５１またはストレージ状態監視機能部５２によりストレージ装置４が修復不可能であると判断された場合に、予め定められた手段によって、当該ストレージ装置４の故障を示すストレージ故障通知をストレージ故障通知機能部１１に出力するものである。

ＲＡＩＤ復帰処理機能部５４は、ストレージ状態監視機能部５２によりストレージ装置４の修復処理が完了したと判断された場合に、予め定められた手段によって、当該ストレージ装置４をＲＡＩＤ装置に復帰させるものである。

次に、上記のように構成されたＲＡＩＤ障害自己修復装置５の動作について説明する。なお以下では、Ｓ／Ｗ−ＲＡＩＤにてＲＡＩＤ１運用中に、１台のストレージ装置４にて修復処理が発生した場合を示す。

あるストレージ装置４に障害が発生すると、ＲＡＩＤ管理Ｓ／Ｗ２はＲＡＩＤデグレードを行って、対応するストレージドライバ３を切り離すとともにその旨を示すデグレード通知をＲＡＩＤ障害自己修復装置５に出力する。なお、このデグレード通知には、障害が発生してＲＡＩＤ装置から切り離されたストレージ装置４の名称およびデグレードの発生時刻（障害の発生時刻）を示す情報が含まれている。そして、ＲＡＩＤ障害自己修復装置５は、上記デグレード通知を受け取ると、まず、障害統計管理機能部５１による処理を実行する。

この障害統計管理機能部５１の動作について、図２，３を参照しながら説明する。なお、図３は、障害統計管理機能部５１が保持する障害統計管理テーブル５１１の構造を示す図である。この障害統計管理テーブル５１１には、図３に示すように、ストレージ装置４ごとに、障害が発生した時刻（障害情報）が記録される。

障害統計管理機能部５１の動作では、図２に示すように、まず、ＲＡＩＤ管理Ｓ／Ｗ２からデグレード通知を受信したかを判断する（ステップＳＴ２０１）。このステップＳＴ２０１において、デグレード通知を受信していない場合には、シーケンスはステップＳＴ２０１に戻り、待機状態となる。

一方、ステップＳＴ２０１において、デグレード通知を受信した場合には、障害統計管理テーブル５１１全体から所定期間（例えば２４時間）以上経過したエントリ（障害情報）を削除する（ステップＳＴ２０２）。

次いで、デグレード通知の内容に基づいて、障害統計管理テーブル５１１に障害情報を登録する（ステップＳＴ２０３）。すなわち、デグレード通知に示されたストレージ装置４の障害発生時刻を、障害統計管理テーブル５１１に記録する。

次いで、障害統計管理テーブル５１１のうち、障害が発生したストレージ装置４に対応するエントリが所定数（例えば１０エントリ）に達したかを判断する（ステップＳＴ２０４）。

このステップＳＴ２０４において、障害が発生したストレージ装置４に対応するエントリが１０エントリに達したと判断した場合には、当該ストレージ装置４は故障停止する直前であり修復不可能であると判断し、ストレージ異常通知を異常状態通知機能部５３に出力する（ステップＳＴ２０５）。その後、シーケンスはステップＳＴ２０１に戻る。
なお、異常状態通知機能部５３では、上記ストレージ異常通知をアプリケーション１のストレージ故障通知機能部１１に出力し、ストレージ故障通知機能部１１は、この通知を受けて、該当するストレージ装置４の故障を外部（例えば保守員）に通知する。

一方、ステップＳＴ２０４において、障害が発生したストレージ装置４に対応するエントリが１０エントリに達していないと判断した場合には、当該ストレージ装置４は修復可能であると判断し、デグレード通知をストレージ状態監視機能部５２に出力する（ステップＳＴ２０６）。その後、シーケンスはステップＳＴ２０１に戻る。

次に、ストレージ状態監視機能部５２の動作について、図４，５を参照しながら説明する。なお、図５は、ストレージ状態監視機能部５２が保持するストレージ状態監視テーブル５３１の構造を示す図である。このストレージ状態監視テーブル５３１には、図５に示すように、ストレージ装置４ごとに、ストレージ状態監視機能部５２が監視を開始した時刻（状態監視開始時刻）が記録される。

ストレージ状態監視機能部５２の動作では、図４に示すように、まず、障害統計管理機能部５１からデグレード通知を受信したかを判断する（ステップＳＴ４０１）。このステップＳＴ４０１において、デグレード通知を受信していない場合には、シーケンスはステップＳＴ４０１に戻り、待機状態となる。

一方、ステップＳＴ４０１において、デグレード通知を受信した場合には、障害が発生したストレージ装置４に対応するストレージドライバ情報を取得する（ステップＳＴ４０２）。
次いで、ストレージ状態監視テーブル５３１に状態監視開始時刻を格納する（ステップＳＴ４０３）。

次いで、ポーリングを実施して、該当するストレージドライバ３に対してストレージ装置４への書込み処理（ｗｒｉｔｅ処理）を発行する（ステップＳＴ４０４）。その後、当該ストレージドライバ３から書込み処理に対する応答（完了通知）が帰ってくることを期待する。
次いで、所定期間（例えば３０秒）以内にストレージドライバ３から応答を受けられたかを判断する（ステップＳＴ４０５）。

このステップＳＴ４０５において、３０秒以内に応答を受けられなかった場合、ストレージ状態監視テーブル５３１を参照して、状態監視開始から所定期間（例えば２００秒）を超えたかを判断する（ステップＳＴ４０６）。
このステップＳＴ４０６において、状態監視開始から２００秒を超えていないと判断した場合には、シーケンスはステップＳＴ４０４に戻り、再度ポーリングを実施する。

一方、ステップＳＴ４０６において、状態監視開始から２００秒を超えたと判断した場合には、当該ストレージ装置４は修復不可能である可能性が高いため、ストレージ異常通知を異常状態通知機能部５３に出力する（ステップＳＴ４０７）。その後、シーケンスはステップＳＴ４０１に戻る。
なお、異常状態通知機能部５３では、上記ストレージ異常通知をアプリケーション１のストレージ故障通知機能部１１に出力し、ストレージ故障通知機能部１１は、この通知を受けて、該当するストレージ装置４の故障を外部（例えば保守員）に通知する。

一方、ステップＳＴ４０５において、３０秒以内に応答を受け取れた場合、当該ストレージ装置４の修復処理が完了したと判断し、復帰処理開始通知をＲＡＩＤ復帰処理機能部５４に出力する（ステップＳＴ４０８）。その後、シーケンスはステップＳＴ４０１に戻る。

そして、ＲＡＩＤ復帰処理機能部５４では、ストレージ状態監視機能部５２からの復帰処理開始通知に応じ、予め定められたＲＡＩＤ復帰手続きをＲＡＩＤ管理Ｓ／Ｗ２に実行することで、修復処理が完了したストレージ装置４をＲＡＩＤ装置に復帰させることを実現する。なお、ストレージ装置４がＲＡＩＤ装置に復帰すると、ＲＡＩＤ管理Ｓ／Ｗ２は当該ストレージ装置４に対するＲＡＩＤ同期を開始する。

なお、ストレージ状態監視機能部５２にて、ポーリングであるｗｒｉｔｅ処理を実行する際、ｗｒｉｔｅを発行する領域はＲＡＩＤ管理領域であれば何処でもよく、またｗｒｉｔｅするデータも任意でよい。ここで、ｗｒｉｔｅ処理が完了するとストレージ装置４内のデータを変えてしまうことになるが、ｗｒｉｔｅ処理が完了するならば当該ストレージ装置４はＲＡＩＤ装置に復帰することになるため、復帰後にＲＡＩＤ管理Ｓ／Ｗ２が行うＲＡＩＤ同期処理によりストレージ装置４内のデータは正しいデータに置き換わる。

以上のように、この実施の形態１によれば、デグレード通知に基づくストレージ装置４の障害発生履歴から当該ストレージ装置４の修復可能性を判断し、また、ストレージ装置４の修復状況を監視し、修復不可能であると判断した場合には外部にストレージ装置４の故障を通知し、修復が完了した場合には、ＲＡＩＤ装置に復帰させるように構成したので、予備のストレージ装置４を用いることなく、障害が発生したストレージ装置４の修復可能性を判断し、当該ストレージ装置４の修復が完了した場合にＲＡＩＤ装置をデグレード状態から自動復帰させることができる。
その結果、保守員の現地派遣回数低減による人件費の削減を図ることができる。また、自動でＲＡＩＤ装置をデグレード状態から復帰させることができるため、デグレード状態での運用時間を短縮することによるデータ冗長性の向上を図ることができる。また、ストレージ装置４の修復処理が完了した後に、ＲＡＩＤ装置への復帰を行うため、ストレージ装置４の健全性の向上と、これに伴うストレージ装置４の長寿命化を図ることができる。さらに、予備のストレージ装置４を不要とすることによる装置コストの低減を図ることができる。

なお、ＲＡＩＤ障害自己修復装置５に替えて、各ストレージドライバ３にリトライ機能を実装することも考えられる。しかしこの方式の場合、ＲＡＩＤ管理Ｓ／Ｗ２では、ストレージドライバ３がリトライ処理を実施している期間中はＲＡＩＤデグレード状態に移行できず、ＲＡＩＤ装置のストレージアクセスが復帰できない（図１６，１７参照）。その結果、正常なストレージ装置４へのデータ書込みもできなくなるため、ｗｒｉｔｅ待ちデータの滞留を引き起こす。したがって、ストレージドライバ３へのリトライ機能の実装は好ましくない。

実施の形態２．
実施の形態１では、ストレージ状態監視機能部５２において、ストレージ装置４が修復不可能と判断するまでの期間を固定値（例えば２００秒など）とする場合について示した。それに対して、実施の形態２では、ストレージ装置４の容量に応じて上記期間を調整する場合について示す。

一般的に、ストレージ装置４内部の修復処理ではストレージ装置４内部で代替箇所を探索するシーク処理が行われる。このシーク処理に要する時間は、ストレージ装置４の容量に比例して増加する。このことから、ストレージ装置４が修復処理に要する時間の最悪値は、その容量に比例して増加する。よって、ストレージ装置４の容量に比例して、修復不可能と判断するまでの秒数を長めに調整できる。

以上のように、この実施の形態２によれば、ストレージ状態監視機能部５２において、ストレージ装置４の容量に応じて、ストレージ装置４の修復不可能と判断するまでの期間を調整するように構成しても、実施の形態１と同様の効果を得ることができる。
なお、実施の形態２では、実施の形態１の構成を元に説明を行ったが、以下の実施の形態３〜８の構成に対しても同様に適用可能である。

実施の形態３．
実施の形態１では、障害統計管理機能部５１において、過去２４時間内に発生した障害発生回数を管理する場合について示した。それに対して、実施の形態３では、各ストレージ装置４の仕様に記載された代替セクタ数に基づく統計情報を管理する場合について示す。

一例として、１セクタ５１２Ｂｙｔｅのストレージ装置４にて代替セクタ数が１６０セクタ存在する場合、装置からストレージ装置４へのデータブロックの転送量が４０９８Ｂｙｔｅであれば、１回の転送では８セクタ分のデータが転送される。データの転送ごとにストレージ装置４内部にて修復処理の要否が判定されることから、障害統計管理機能部５１では、代替セクタ数に基づく障害対応残数として（１６０×５１２）／（４０９８）＝２０という数値を初期値（障害発生可能回数）とする。以降、デグレード通知を受信する度に、通信途絶したストレージ装置４ごとに１ずつ減算処理を行う。そして、この値が０となったストレージ装置４は代替セクタが枯渇した可能性が高いため、ストレージ状態監視機能部５２へ処理を移行せず、異常状態通知機能部５３に異常を通知する。
したがって、本実施の形態では、障害統計管理テーブル５１２において、時間に基づく何らかの管理は不要であり、ストレージ装置４に対して累積的に統計情報が管理される。

次に、上記のように構成された障害統計管理機能部５１の動作について、図６，７を参照しながら説明する。なお、図７は、障害統計管理機能部５１が保持する障害統計管理テーブル５１２の構造を示す図である。この障害統計管理テーブル５１２には、図５に示すように、ストレージ装置４ごとに、障害対応残数（障害発生可能回数から障害発生回数を差し引いた値）が記録される。

障害統計管理機能部５１の動作では、図６に示すように、まず、ＲＡＩＤ管理Ｓ／Ｗ２からデグレード通知を受信したかを判断する（ステップＳＴ６０１）。このステップＳＴ６０１において、デグレード通知を受信していない場合には、シーケンスはステップＳＴ６０１に戻り、待機状態となる。

一方、ステップＳＴ６０１において、デグレード通知を受信した場合には、障害統計管理テーブル５１２のうち、障害が発生したストレージ装置４に対応する障害対応残数が０であるかを判断する（ステップＳＴ６０２）。

このステップＳＴ６０２において、障害が発生したストレージ装置４の障害対応残数が０ではないと判断した場合には、当該障害対応残数から１を減算する（ステップＳＴ６０３）。
次いで、デグレード通知をストレージ状態監視機能部５２に出力する（ステップＳＴ６０４）。その後、シーケンスはステップＳＴ６０１に戻る。

一方、ステップＳＴ６０２において、障害が発生したストレージ装置４の障害対応残数が０であると判断した場合には、ストレージ異常通知を異常状態通知機能部５３に出力する（ステップＳＴ６０５）。その後、シーケンスはステップＳＴ６０１に戻る。

以上のように、この実施の形態３によれば、障害統計管理機能部５１において、ストレージ装置４が有する代替セクタ数に基づいて障害発生可能回数を算出し、デグレード通知に基づいて、ストレージ装置４の障害発生回数が障害発生可能回数を超過した場合には、当該ストレージ装置４は修復不可能であると判断し、障害発生可能回数内である場合には、当該ストレージ装置４は修復可能であると判断するように構成しても、実施の形態１と同様の効果を得ることができる。

なお、本実施の形態における減算処理を行う形態は一例であり、故障回数の加算処理でもよい。その場合、代替セクタ数に基づく故障対応残数は加算の上限値として用いられる。

実施の形態４．
実施の形態１では、ＲＡＩＤ障害自己修復装置５をＳ／Ｗ−ＲＡＩＤにて実装する場合を示したが、Ｈ／Ｗ−ＲＡＩＤにて実装することも考えられる。なお、本発明に係るＲＡＩＤ障害自己修復装置５は、ＲＡＩＤ装置から切り離されたストレージ装置４に対してポーリングできる必要があるため、Ｈ／Ｗ−ＲＡＩＤにて実装する場合には図１５に示すＲＡＩＤ管理Ｈ／Ｗ６００の内部に実装される。

実施の形態５．
実施の形態４では、ＲＡＩＤ障害自己修復装置５をＨ／Ｗ−ＲＡＩＤにて実装する場合について示した。それに対して、ＲＡＩＤ装置から切り離されたストレージ装置４の通信機能が復帰したことをＳ／Ｗ側から知る手段が提供されるならば、本発明に係るＲＡＩＤ障害自己修復装置５を、ＲＡＩＤ管理Ｈ／Ｗ６００の内部ではなくＳ／Ｗ実装によって実現することも可能である。例えば、ＲＡＩＤ管理Ｈ／Ｗ６００が、ＲＡＩＤ装置から切り離したストレージ装置４へのＳ／Ｗ側からのアクセスを許可する場合に可能である。

実施の形態６．
ＲＡＩＤ装置がパーティション構成であっても本方式は有効である。以下では、実施の形態１に係るＲＡＩＤ装置において、ストレージ装置４がパーティション構造である場合について示す。
この場合、ＲＡＩＤ管理Ｓ／Ｗ２からのデグレード通知には、障害が発生してＲＡＩＤ装置から切り離されたストレージ装置４の名称、デグレードの発生時刻（障害の発生時刻）および当該ストレージ装置４内の当該障害が発生したパーティションの番号を示す情報が含まれているものとする。

また、障害統計管理機能部５１では、図３に示すようにストレージ装置４ごとに統計情報を管理したことに替えて、ストレージ装置４のパーティションごとに統計情報を管理する。

次に、上記のように構成された障害統計管理機能部５１の動作について、図８，９を参照しながら説明する。なお、図９は、障害統計管理機能部５１が保持する障害統計管理テーブル５１３の構造を示す図である。この障害統計管理テーブル５１３には、図９に示すように、ストレージ装置４のパーティションごとに、障害が発生した時刻（障害情報）が記録される。

障害統計管理機能部５１の動作では、図８に示すように、まず、ＲＡＩＤ管理Ｓ／Ｗ２からデグレード通知を受信したかを判断する（ステップＳＴ８０１）。このステップＳＴ８０１において、デグレード通知を受信していない場合には、シーケンスはステップＳＴ８０１に戻り、待機状態となる。

一方、ステップＳＴ８０１において、デグレード通知を受信した場合には、障害統計管理テーブル５１３全体から２４時間以上経過したエントリ（障害情報）を削除する（ステップＳＴ８０２）。

次いで、デグレード通知の内容に基づいて、障害統計管理テーブル５１３に障害情報を登録する（ステップＳＴ８０３）。すなわち、デグレード通知に示されたストレージ装置４のパーティション単位での障害発生時刻を、障害統計管理テーブル５１３に記録する。

次いで、障害統計管理テーブル５１３のうち、ストレージ装置４の当該障害が発生したパーティションに対応するエントリが１０エントリに達したかを判断する（ステップＳＴ８０４）。

このステップＳＴ８０４において、ストレージ装置４の障害が発生したパーティションに対応するエントリが１０エントリに達したと判断した場合には、当該ストレージ装置４は故障停止する直前であり修復不可能であると判断し、ストレージ異常通知を異常状態通知機能部５３に出力する（ステップＳＴ８０５）。その後、シーケンスはステップＳＴ８０１に戻る。

一方、ステップＳＴ８０４において、ストレージ装置４の障害が発生したパーティションに対応するエントリが１０エントリに達していないと判断した場合には、当該ストレージ装置４は修復可能であると判断し、デグレード通知をストレージ状態監視機能部５２に出力する（ステップＳＴ８０６）。その後、シーケンスはステップＳＴ８０１に戻る。

以上のように、この実施の形態６によれば、ストレージ装置４のパーティション単位で障害発生回数を管理するように構成しても、実施の形態１と同様の効果が得られる。

実施の形態７．
ＲＡＩＤ装置がパーティション構成である場合において、実施の形態６に替えて、実施の形態３に係る障害統計管理機能部５１を適用した構成としてもよい。

ここで、障害統計管理機能部５１の動作について、図１０，１１を参照しながら説明する。なお、図１１は、障害統計管理機能部５１が保持する障害統計管理テーブル５１４の構造を示す図である。この障害統計管理テーブル５１４には、図１１に示すように、ストレージ装置４のパーティションごとに、障害対応残数（障害発生可能回数から障害発生回数を差し引いた値）が記録される。

障害統計管理機能部５１の動作では、図１０に示すように、まず、ＲＡＩＤ管理Ｓ／Ｗ２からデグレード通知を受信したかを判断する（ステップＳＴ１００１）。このステップＳＴ１００１において、デグレード通知を受信していない場合には、シーケンスはステップＳＴ１００１に戻り、待機状態となる。

一方、ステップＳＴ１００１において、デグレード通知を受信した場合には、障害統計管理テーブル５１４のうち、ストレージ装置４の障害が発生したパーティションに対応する障害対応残数が０であるかを判断する（ステップＳＴ１００２）。

このステップＳＴ１００２において、ストレージ装置４の障害が発生したパーティションに対応する障害対応残数が０ではないと判断した場合には、当該障害対応残数から１を減算する（ステップＳＴ１００３）。
次いで、デグレード通知をストレージ状態監視機能部５２に出力する（ステップＳＴ１００４）。その後、シーケンスはステップＳＴ１００１に戻る。

一方、ステップＳＴ１００２において、ストレージ装置４の障害が発生したパーティションに対応する障害対応残数が０であると判断した場合には、ストレージ異常通知を異常状態通知機能部５３に出力する（ステップＳＴ１００５）。その後、シーケンスはステップＳＴ１００１に戻る。

以上のように、この実施の形態７によれば、代替セクタ数を用いて、ストレージ装置４のパーティション単位で障害発生の統計情報を管理するように構成しても、実施の形態１と同様の効果が得られる。

実施の形態８．
実施の形態１では、ＲＡＩＤとして、ＲＡＩＤ１を用いて説明を行ったが、これに限るものではなく、ＲＡＩＤ０以外のＲＡＩＤに対しても有効である。以下に例として、ＲＡＩＤ０，ＲＡＩＤ５の構成に付いて示す。

まず、ＲＡＩＤ０の構成について図１２を参照しながら説明する。
図１２に示すように、ＲＡＩＤ０では、書込みを行うデータは２つのデータ（データ１，データ２）に分割され、別々のストレージ装置４に格納される。よって、ＲＡＩＤ０ではデータの冗長性が無く、故障確立も増加するが、ストレージアクセス速度が高速となり、またストレージサイズも各ストレージ装置４の合計値となる。
そして、ＲＡＩＤ０では、その機能上デグレード状態は発生しない（いずれか１つのストレージ装置４の故障であってもデータの整合性が保てない）ため、本発明に係るＲＡＩＤ障害自己修復装置５を適用することに意味が無い。

次に、ＲＡＩＤ５の構成について図１３を参照しながら説明する。
図１３に示すように、ＲＡＩＤ５では、書込みを行うデータ（例えばデータＡ）が２つのデータ（例えばデータＡ１，データＡ２）と１つのパリティ（例えばパリティＡ）に分割され、別々のストレージ装置４に格納される。よって、いずれか１つのストレージ装置４が故障してもパリティからデータを復元することが可能である。
そして、ＲＡＩＤ５では、デグレード状態が発生しえるため、本発明に係るＲＡＩＤ障害自己修復装置５を適用することが有効である。

以上のように、この実施の形態８によれば、ＲＡＩＤ障害自己修復装置５をＲＡＩＤ０以外のＲＡＩＤに適用する構成としても、実施の形態１と同様の効果を得ることができる。

実施の形態９．
本発明に係るＲＡＩＤ障害自己修復装置５が適用可能なストレージ装置４としては、磁気ディスクを用いた記録媒体（例えば、ハードディスク）のみに限らない。一例として、不揮発メモリを用いた記録媒体（例えばＳｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅなど）などであってもよい。

なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。

１ アプリケーション、２ ＲＡＩＤ管理Ｓ／Ｗ、３，３ａ，３ｂ ストレージドライバ、４，４ａ，４ｂ ストレージ装置、５ ＲＡＩＤ障害自己修復装置、１１ ストレージ故障通知機能部、５１ 障害統計管理機能部、５２ ストレージ状態監視機能部、５３ 異常状態通知機能部、５４ ＲＡＩＤ復帰処理機能部、５１１〜５１４ 障害統計管理テーブル、５３１ ストレージ状態監視テーブル。

Claims (7)

1. 複数のストレージ装置からなるＲＡＩＤ装置において障害が発生した前記ストレージ装置が切り離された旨を示すデグレード通知を受けることで、当該デグレード通知に基づく障害発生履歴から、当該障害が発生したストレージ装置の修復可能性を判断する障害統計管理機能部と、
   前記障害統計管理機能部により前記ストレージ装置が修復可能であると判断された場合に、当該ストレージ装置の修復状況を監視するストレージ状態監視機能部と、
   前記障害統計管理機能部または前記ストレージ状態監視機能部により前記ストレージ装置が修復不可能であると判断された場合に、当該ストレージ装置の故障を外部に通知する異常状態通知機能部と、
   前記ストレージ状態監視機能部により前記ストレージ装置の修復処理が完了したと判断された場合に、当該ストレージ装置を前記ＲＡＩＤ装置に復帰させるＲＡＩＤ復帰処理機能部と
   を備えたＲＡＩＤ障害自己修復装置。
2. 前記デグレード通知には、前記障害が発生したストレージ装置および当該障害が発生した時刻を示す情報が含まれ、
   前記障害統計管理機能部は、前記デグレード通知に基づいて、前記ストレージ装置の障害発生回数が所定期間内に所定回数以上である場合には、当該ストレージ装置は修復不可能であると判断し、前記所定期間内に所定回数未満である場合には、当該ストレージ装置は修復可能であると判断する
   ことを特徴とする請求項１記載のＲＡＩＤ障害自己修復装置。
3. 前記障害統計管理機能部は、前記ストレージ装置が有する代替セクタ数に基づいて障害発生可能回数を算出し、前記デグレード通知に基づいて、前記ストレージ装置の障害発生回数が前記障害発生可能回数を超過した場合には、当該ストレージ装置は修復不可能であると判断し、前記障害発生可能回数内である場合には、当該ストレージ装置は修復可能であると判断する
   ことを特徴とする請求項１記載のＲＡＩＤ障害自己修復装置。
4. 前記デグレード通知には、前記障害が発生したストレージ装置内の当該障害が発生したパーティションを示す情報が含まれ、
   前記障害統計管理機能部は、前記パーティション単位で前記ストレージ装置が修復可能であるかを判断する
   ことを特徴とする請求項２または請求項３記載のＲＡＩＤ障害自己修復装置。
5. 前記ストレージ状態監視機能部は、監視対象のストレージ装置に対して書込み処理を実行し、所定期間経過しても当該ストレージ装置から前記書込み処理に対する応答がない場合には、当該ストレージ装置は修復不可能であると判断し、前記所定期間内に前記応答があった場合には、当該ストレージ装置は修復処理が完了したと判断する
   ことを特徴とする請求項１から請求項４のうちのいずれか１項記載のＲＡＩＤ障害自己修復装置。
6. 前記ストレージ状態監視機能部は、前記ストレージ装置のデータ記憶容量に応じて、前記所定期間を調整する
   ことを特徴とする請求項５記載のＲＡＩＤ障害自己修復装置。
7. 前記各機能部は、ソフトウェア、ハードウェハまたはその両方を組み合わせて実装される
   ことを特徴とする請求項１から請求項６のうちのいずれか１項記載のＲＡＩＤ障害自己修復装置。

Images