JP4234730B2 - Ｒａｉｄ閉塞判定方法、ｒａｉｄ装置、そのコントローラ・モジュール、プログラム - Google Patents

Description

本発明は、ＲＡＩＤ装置における閉塞判定等に関する。

従来のＲＡＩＤシステムの概略構成を図１１に示す。図１１において、ＲＡＩＤ装置１００は、ＣＭ（Centralized Module）１０１、ＢＲＴ（Backend Router）１０２，１０３、及び複数のディスクから成るＲＡＩＤグループ１０４を有する。尚、図では、ＲＡＩＤグループ１０４は１つのみ示すが、実際には複数ある場合が多い。ホスト１１０は、任意の通信線を介してＣＭ１０１に対して、任意のＲＡＩＤグループへのアクセスを要求する。

ＣＭ１０１は、ＲＡＩＤ装置１００内における各種ディスクアクセス処理、エラーリカバリ処理等を管理・制御する。ＢＲＴ１０２、１０３は、ＣＭ１０１とＲＡＩＤグループ１０４との間に位置し、ＣＭ１０１とＲＡＩＤグループ１０４とを繋ぐ為のスイッチの役割を果たす。ホスト１１０がＣＭ１０１を介してＲＡＩＤグループ１０４にアクセスする経路（パス）は２つあり（図では１つのアクセス経路のみ示しているが）、この２つのアクセス経路の各々にＢＲＴ１０２、１０３が設けられている。従って、どちらか一方のアクセス経路が何等かの理由（例えば、ＢＲＴの故障等）によって使用不可となっても、他方のアクセス経路を用いてアクセスすることができる。

しかしながら、例えば、両方の経路（両系とも）が使用不可となる場合がある。図示の例では、ＢＲＴ１０２、１０３が故障しており、この場合、当然、全てのＲＡＩＤグループ１０４にアクセスすることが出来なくなる（図では、ＲＡＩＤグループは１つのみであるが、実際には、複数のＲＡＩＤグループが存在する場合が多い）。

この様に、ＲＡＩＤ装置において、あるＲＡＩＤグループへアクセスできなくなった場合、そのままホスト１１０がアクセス要求し続けると、ＲＡＩＤ装置１００側でディスク故障と判断し、最終的にはＲＡＩＤグループ故障となりユーザデータが消失する可能性がある。また、ホスト１１０は、アクセス出来ないにも係らずアクセスしようとする為、ホスト処理遅延の原因となる。

その為、アクセスできない理由がディスク要因である場合を除いては、ＲＡＩＤを一旦閉塞状態にさせる。ＲＡＩＤ閉塞とは、上記アクセス出来なくなったＲＡＩＤグループの状態を、閉塞前と同じ状態で保持し、ホストアクセスを禁止している状態を意味する。これによって、ユーザデータを保護し、ホストからのアクセスを、即、異常終了とさせる。
ホストアクセスは、閉塞したＲＡＩＤグループにおいて、閉塞となった要因が解消された時点から受付可能となる。

ここで問題になるのが、ＲＡＩＤ閉塞を行うか否かの判定方法である。
図１２に、従来のＲＡＩＤ閉塞判定方法の一例を示す。尚、図１２には、判定対象となるＲＡＩＤグループがＲＡＩＤ１の場合に対応した閉塞判定方法を示す。

図１２に示す表の通り、従来では、各“ＲＡＩＤが閉塞し得る事象”（装置として発生した事象（３））と“ＤＬＵ単位での各ディスクの状態”（２）との組み合わせに応じて、ＲＡＩＤグループを閉塞させるか否かを登録しており、各“ＲＡＩＤが閉塞し得る事象”のうちの１つが発生したときに、この表を参照して、ＲＡＩＤグループを閉塞させるか否かを判定する。尚、この表は、例えば、ＣＭ１０１内のメモリ等に記憶されており、この判定はＣＭ１０１が行う。また、尚、この表において「○」は閉塞させること、「×」は閉塞させないことを意味している。

“ＲＡＩＤが閉塞し得る事象”は、図示の例では、「ペアとなるＢＲＴの故障」、「ペアとなるＢＲＴのポートの故障」、「ペアとなるＢＲＴの故障（ＢＲＴ跨ぎ）」、「ペアとなるＢＲＴのポートの故障（ＢＲＴ跨ぎ）」、「Ｐ１がＮｅ(Not Exist)へ遷移」等であるが、これら以外にも様々な事象が発生し得る。

「ペアとなるＢＲＴの故障」とは、例えば上記ＢＲＴ１０２、１０３の両方が故障したことを意味する。従って、この場合には、当然、図示の通り、各ディスクの状態は関係なく、全て「○（閉塞させる）」となる。

「ペアとなるＢＲＴのポートの故障」とは、例えば上記ＢＲＴ１０２、１０３において、同一の１つのＲＡＩＤグループに接続しているポートが、両方とも故障した場合である。 また、上記“ＢＲＴ跨ぎ”とは、同一のRAIDグループに属するディスクが、別々の系統に接続されている場合である。例えば、図１５に示すように、ＢＲＴ０とＢＲＴ１の系統に接続されたディスクＰ１と、ＢＲＴ２とＢＲＴ３の系統に接続されたディスクＰ２とが、同じＲＡＩＤグループである場合である。

また、図１２において示す各記号（状態を示す記号）の意味について以下に説明する。
まず、ＤＬＵについて説明する。図１３（ａ）、（ｂ）に示すように、ＲＬＵはＲＡＩＤグループそのものを意味し、ＤＬＵは、ＲＬＵという論理ボリュームと、ディスクという物理的ボリュームを結合する為の概念である。尚、DISKは、各ハードディスクそのものである。また、尚、図１３（ａ）に示すように、RAID１の場合には、ＤＬＵとＲＬＵとは同じ内容となる。よって、図１２に示すＤＬＵはＲＬＵに置き換えても良い。

図１２に示すＰ１，Ｐ２，ＨＳ１，ＨＳ２は、１つのＲＡＩＤグループを構成する各ディスクに仮に与えた名称である。尚、図１３（ａ）に示す通り、ＲＡＩＤ１においてはＲＡＩＤグループは２つのディスク（Ｐ１，Ｐ２）より構成され、ディスクＰ１，Ｐ２の両方に同一のデータが書き込まれるが、実際には更にスペア用のディスク(Hot Spareと呼ぶ)が用意されており、これが図１２に示すHS1、HS2である。

また、図１２に示すＤＬＵ又は各ディスクの状態を示すAｖ,Br等の記号の意味を、以下に記す。
すなわち、
Ａｖ（Available；通常状態）、Ｂｒ（Broken；故障状態）、Ｆｕ（Failed Usable；ＲＡＩＤ故障時にRead（読出し）のみ許可状態）、Ｅｘ（Exposed；縮退状態）、Ｎｅ（Not Exist；loop down等が原因でDiskが一時的に見えなくなる状態）、Ｒｂ（Rebuild；Rebuild状態）、Ｓｐｒ（Sparing；Redundant Copy状態）、SiU(Spare In Use；Hot Spare使用状態)、Ｃｐ（Copyback；Copyback状態）、SpW（Spr＋WF）である。

図１２に示す通り、ＤＬＵ／ＲＬＵを構成する各ディスクの上記何れかの状態によって、そのＤＬＵ／ＲＬＵの状態が決まる。例えば、ディスクＰ１，Ｐ２の両方が通常状態(Av)であれば、当然、ＤＬＵは通常状態(Av)となる。これについて、図１４を参照して説明する。

図１４（ａ）については、上記の通りであり、この通常状態から、どちらか一方のディスクが故障状態(Br)になったら、そのＤＬＵは縮退状態(Ex)となる（図１４（ｂ））。
尚、図１２に示す通り、故障状態(Br)ではなく、Ne状態になった場合でも、そのＤＬＵは縮退状態となる。あるいは、例えば、ディスクP1が不調になった為に、ディスクP1をSpr状態にしディスクＨＳ１をRb状態にして、ディスクP1のデータをディスクＨＳ１にコピーしている状態で、更にディスクＰ２がＢrとなった場合も、そのDLUは縮退状態となる。
そして、図１４（ｂ）の状態になったら、レイド１では２つ以上のディスクに同一データを格納する必要があるので、上記Hot Spare（ここではＨＳ１）を使用する為に、図１４（ｃ）に示す通り、ディスクＰ１の格納データをディスクHS1にコピーする。この状態では、ディスクHS1はRb状態であり、ＤＬＵもＲb状態である。そして、コピー完了したら、図１４（ｄ）に示す通り、ディスクHS1は通常状態となり、この様にHot Spareを用いて通常運用しているＤＬＵの状態は、SiU状態となる。

また、例えば故障ではないが多少の不具合が生じた為、そのままそのディスク（ここではＰ２とする）を使い続けるのは不安である場合等には、図１４（ｅ）に示すように、ディスクＰ２をSpr状態にすると共に、Hot Spare（ここではＨＳ１）をＲｂ状態にして、ディスクＰ２のデータをHot Spareにコピーする。このときのＤＬＵの状態はRedundant Copy(Spr)状態である。

上記Hot Spareを使用して通常運用を行っている状態で、例えばディスクＰ２が正常になったら、図１４（ｆ）に示すように、ディスクＰ２をＲｂ状態にして、Hot Spareの格納データをディスクＰ２にコピーする。このときのＤＬＵの状態は、Copyback(Cp)状態となる。

また、図１４（ｇ）に示すように、ディスクＰ１，Ｐ２の何れか一方がＦｕ状態、他方がＢｒ状態の場合、ＤＬＵはＢｒ状態である。尚、そのＲＡＩＤグループが使用不能状態となった場合（ここでは、ディスクＰ１，Ｐ２の両方が故障した場合）、そのときに故障したディスクはＢｒ状態とはしないようにしている。図示の例では最初にディスクＰ２が故障した為にディスクＰ２をＢｒ状態にしたが、その後にディスクＰ１が故障したときには、ＢｒではなくＦｕとすることで、格納されているデータを少しでも救出するように試みる。尚、RAID１の場合は１台のディスクが故障しただけでは使用不能状態とはならないが、RAID０の場合は一台故障しただけで使用不能状態となるので、Ｂｒ状態となるディスクは存在しないことになる。

また、ＤＬＵがSiU状態となるのは、図１４（ｄ）の状態以外にも、図１４（ｈ）の状態がある。図１４（ｈ）では、図１４（ｄ）の状態から更にディスクＰ１が不調になった為に、ディスクＰ１をSpr状態にしてそのデータをディスクHS2にコピー中の状態である（当然、ディスクHS2はRb状態である）。

また、図１２の図上右端に示すように、例えばディスクＰ２が、Sprではなく、SpW（Spr＋WF）の状態のときも、そのＤＬＵはSpr状態として扱う。この「Spr＋WF」について、図１４（ｉ），（ｊ）を用いて説明する。

まず、図１４（ｉ）に示すように、ディスクＰ１がAv状態、ディスクＰ２がSpr状態、ディスクHS1がRb状態で、ディスクＰ１からディスクHS1にコピーを行っているときに、Writeが発生したものとする。この場合、Writeは、図示の通り、全ディスクに対して行われる。そして、図示の通り、ディスクＰ２に対するWriteが失敗したものとする。この場合、ディスクＰ２にはＯＬＤデータが格納されている状態（Write前の状態）である為、ディスクＰ２からリードすることは出来ない。よって、図１４（ｊ）に示す通り、ディスクＰ２は「Spr＋WF」状態にする。但し、この状態でも、ディスクＰ２からディスクHS1へのコピーは続行する。この状態が、図１２の図上右端に示す状態である。

また、特許文献１、特許文献２、特許文献３に記載の公知技術が知られている。
特許文献１の発明は、ディスク装置を有する周辺装置に対する入出力動作要求で障害が発生した場合に、コンピュータによる判断処理の軽減を図ると共に、障害回復処理における無駄なリトライ処理を低減できるエラーリトライ方法である。

特許文献２の発明は、FC-AL接続されているシステムで障害が発生した場合に、各種モニターの連携により、ＨＵＢに接続されている装置をポート単位に自動バイパスさせ、Ｔ＆Ｄを実行させて障害情報を収集し、ログ情報とペアにして管理する方法である。

特許文献３の発明は、ディスク・サブシステムからの障害通知が、デバイスパスに依存する障害であれば、該当するデバイスパスのみを閉塞してチャネルパスへの影響を防ぐデバイスパス閉塞方式である。
特開２０００−１３２４１３号公報 特開２０００−２１５０８６号公報 特開平４−２９１６４９号公報

上記図１２で説明した従来の方式では、以下の（１）〜（４）等の問題点がある。
（１）“ＲＡＩＤが閉塞し得る事象”が増えた場合、その都度、この事象を表に追加すると共に、この追加事象と各種“ＲＡＩＤグループがとりうる状態”との組み合わせに応じたＲＡＩＤ閉塞の可否の設定を行わなければならず、非常に手間が掛かる。

（２）図１２に示す表だけでは対応できない事象が発生した場合、例外処理を追加しなければならなかった。
（３）（２）の例外処理を追加していった結果、論理が複雑化し、メンテナンスし難くなる。

（４）“ＲＡＩＤが閉塞し得る事象”を特定している関係上、論理の共通化ができず、ソースコードの増大に繋がる。
尚、上記特許文献１〜３は、上記問題点を解決することには何等関係がない。すなわち、特許文献１の発明は、ディスク装置に対するリトライ処理に係るものであり、ディスク装置内でのエラー発生時の対処方法とは関係ない。特許文献２の発明は、システムとして、あるサブシステムにおいて障害が発生した場合の、システムとしてのリカバリ方法と障害情報／ログ情報の採取に係るものであり、サブシステム（ここではディスク装置）内でのエラー発生時の対処方法とは関係ない。特許文献３は、デバイスパスに着目し、デバイスパス異常時にはデバイスパスを自律的に閉塞させ、システムへの影響を最小限にする発明であり、デバイスパス閉塞後に閉塞されたデバイスパスに存在するＲＡＩＤグループのデータ保護に関するものではない。

本発明の課題は、ＲＡＩＤ閉塞の可否の判定処理に係わり、その設定の手間を大幅に軽減し、メンテナンス性を向上させ、コーディング量の削減し、各ＲＡＩＤレベルに共通の判定論理を用いることができるＲＡＩＤ装置におけるＲＡＩＤ閉塞判定方法、ＲＡＩＤ装置、そのコントローラ・モジュール、プログラム等を提供することである。

本発明による第１のコントローラ・モジュールは、複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおいて、前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクの状態又は前記各ディスクへのアクセスパスの有無に基づいて、前記各ディスクを複数のカテゴリに分類して当該分類単位毎に該当するディスクの数を集計し、該各集計結果と予め設定される閾値条件とを比較することによって、該ＲＡＩＤグループを閉塞させるか否かを判定するＲＡＩＤ管理・制御手段を有する。

上記第１のコントローラ・モジュールでは、“ＲＡＩＤが閉塞し得る事象”が何であるかに関係なく、所定の分類方法によって分類・集計し、集計結果と閾値条件とを比較することで、ＲＡＩＤ閉塞可否を判定できる。この様に、判定論理が共通化できるので、“ＲＡＩＤが閉塞し得る事象”が増えた場合でも判定論理を追加する必要なく、例外処理の追加等も必要なく、メンテナンス性が向上する。また、各ＲＡＩＤレベル毎に閾値条件を設定すれば済む。

本発明による第２のコントローラ・モジュールは、複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおいて、該コントローラ・モジュールと外部の任意のホスト装置とのインタフェースであるＩ／Ｏ制御手段と、前記ＲＡＩＤ装置内の任意の前記ＲＡＩＤグループの閉塞可否の判定、閉塞の実行を管理・制御するＲＡＩＤ管理・制御手段とを有し、前記ＲＡＩＤ管理・制御手段は、任意の前記ＲＡＩＤグループの閉塞を実行する場合、該ＲＡＩＤグループが短時間でリカバリ可能か否かを判定し、短時間でリカバリ可能と判定した場合、その旨を前記Ｉ／Ｏ制御手段に通知し、前記Ｉ／Ｏ制御手段は、該通知を受けた場合であって前記ホスト装置が前記閉塞されたＲＡＩＤグループへのアクセスを要求した場合には、該ホスト装置に対してダミーの応答を返信する。

ＲＡＩＤグループの閉塞を実行した場合、通常であれば、ホスト装置からのアクセスは全て受け付けなくなる為、ホスト装置側ではそれまで実行していた処理は異常終了することになる。しかし、閉塞させたＲＡＩＤグループが短時間でリカバリ可能な状況であるならば、ホスト側にダミーの応答を返信することで、ホストをしばらく待たせる。これによって、それまで実行していた処理が異常終了されることを回避できる。

本発明のＲＡＩＤ閉塞判定方法、ＲＡＩＤ装置、そのコントローラ・モジュール、プログラム等によれば、ＲＡＩＤ閉塞の可否の判定処理に係わり、その設定の手間を大幅に軽減し、メンテナンス性を向上させ、コーディング量の削減し、各ＲＡＩＤレベルに共通の判定論理を用いることができる。

また、ＲＡＩＤ閉塞した場合でも、ホスト側でそれまで実行していた処理が異常終了されることを回避できる。

以下、図面を参照して、本発明の実施の形態について説明する。
図１に、本例のＲＡＩＤ装置１の構成図を示す。
図示のＲＡＩＤ装置１は、２つのＣＭ１０（１０ａ、１０ｂ）、ＦＲＴ３、ＢＲＴ４、ＢＲＴ５、ＤＥ６、ＤＥ７を有する。

ＣＭ１０とＢＲＴ４、５に関しては、上記従来技術で説明した通りであり、ＣＭはCentralized Module、ＢＲＴはBackend Routerである。但し、ここでは、ＣＭ１０ａは、ＢＲＴ４とＢＲＴ５の両系統に接続しており、ＣＭ１０ｂも、ＢＲＴ４とＢＲＴ５の両系統に接続している。尚、後述するＲＡＩＤ閉塞可否判定処理等は、ＣＭ１０ａ、１０ｂが各々個別に実行する。また、ＦＲＴ３は、ＣＭ１０ａ−１０ｂ間の通信を中継制御するものである。

ＤＥ（ドライブエンクロージャー）６は、ＰＢＣ６ａ，６ｂと、ディスク群６ｃを有する。同様に、ＤＥ（ドライブエンクロージャー）７は、ＰＢＣ７ａ，７ｂと、ディスク群７ｃとを有する。そして、例えば、ディスク群６ｃにおける図示のディスクＰ１とディスク群６ｃにおける図示のディスクＰ２とで、１つのＲＡＩＤグループ（例えばRAID１）を形成している。勿論、この例に限らない。例えば、従来技術で説明した「ＢＲＴ跨ぎ」のＲＡＩＤグループが構成されている場合もあり得るし、１つのディスク群内でＲＡＩＤグループが構成されている場合もあり得る。更に、複数のＲＡＩＤグループがあったときに、全て同じＲＡＩＤレベルであるとは限らず、ＲＡＩＤレベルが異なる場合もあり得る。各ＲＡＩＤグループのＲＡＩＤレベルは、ＣＭ１０が記憶・管理している。

ＰＢＣはポート・バイパス・サーキットである。
ＢＲＴ４の各ポートはＰＢＣ６ａ、ＰＢＣ７ａに接続しており、ＢＲＴ５の各ポートはＰＢＣ６ｂ、ＰＢＣ７ｂに接続しており、各ＣＭ１０は、ＢＲＴ４又はＢＲＴ５とＰＢＣを介して、ディスク群６ｃ、ディスク群７ｃにアクセスする。

各ＣＭ１０は、任意の通信線を介してホスト２（２ａ、２ｂ）に接続している。各ＣＭ１０は、Ｉ／Ｏ制御部２１を有しており、Ｉ／Ｏ制御部２１がホスト２とのやりとり（ホストアクセスの受付、応答等）を実行する。また、各ＣＭ１０は、ＲＡＩＤ管理・制御部２２を有している。

ＲＡＩＤ管理・制御部２２は、ＲＡＩＤ装置１内の各部品（ＢＲＴ、ＰＢＣ等）や各ディスクの状態を随時取得して構成情報２２ａとして記憶している。これ自体は、従来と同様であるので、特に説明しないし、構成情報２２ａの具体例も示さない。そして、ＲＡＩＤ管理・制御部２２は、構成情報２２ａ等を参照し、更に各ディスクに対するアクセスパスをチェックして、ＲＡＩＤ閉塞可否の判定を行う。従来でも、上述した通り、構成情報２２ａにおける各ディスクの状態等を参照して、ＲＡＩＤ閉塞可否の判定を行っているが、本発明では判定方法が異なる。本発明の特徴は、主にＲＡＩＤ管理・制御部２２にある。すなわち、ＲＡＩＤ管理・制御部２２によるＲＡＩＤ閉塞可否の判定方法、短時間リカバリ可否の判定方法等にある。詳しくは後述する。

但し、ＲＡＩＤ閉塞可否の判定結果自体は、従来と同様である。すなわち、ＲＡＩＤを閉塞させるべき状態であるか否かを判定する為の根拠（理由）自体は、従来と同じであり、従って判定結果自体は、従来と変わらない。しかし、本手法では、後述する“分類”と“閾値”を用いた判定を行うことで、上述した従来の問題点を解決できる。

尚、ＲＡＩＤ管理・制御部２２は、ＲＡＩＤ閉塞の実行、閉塞の解除等も行っている。
尚、各ＣＭ１０と各ＢＲＴ４，５とは、Back Panelによって接続されており、Ｉ／Ｆ（インタフェース）はＦＣ（ファイバーチャネル）である。各ＢＲＴ４，５と各ＤＥ６，７とは、ＦＣケーブルによって接続されており、Ｉ／Ｆ（インタフェース）はＦＣ（ファイバーチャネル）である。各ＤＥ６，７内の各ディスクは、Back Panelによって接続されており、Ｉ／Ｆ（インタフェース）はＦＣ（ファイバーチャネル）である。そして、各ディスクへのアクセスは、ＦＣループにより行う。この為、ＦＣループ上の複数のディスクのうち、上流のディスクの不具合等によってループが途切れると、下流のディスクにアクセスできなくなる場合がある。

図２に上記ＣＭ１０のハードウェア構成図を示す。
図２に示すＣＭ１０は、各ＤＩ３１、各ＤＭＡ３２、２つのＣＰＵ３３，３４、ＭＣＨ(Memory Controller Hub)３５、メモリ３６、及びＣＡ３７を有する。

ＤＩ３１は、各ＢＲＴと接続するＦＣコントローラである。ＤＭＡ３２はＦＲＴ３に接続する通信回路である。ＭＣＨ３５は、ＣＰＵ３３，３４の外部バス等の所謂ホスト側のバスを、ＰＣＩバスと接続し、相互に通信できるようにする為の回路である。ＣＡ３７は、ホストと接続する為のアダプタである。

以下、まず、本発明の第１の実施形態について説明する。
第１の実施形態における後述する各種フローチャートの処理は、メモリ３６に予め格納されているアプリケーションプログラムを、ＣＰＵ３３又はＣＰＵ３４が読出し・実行することにより実現される。尚、これは、後述する第２の実施形態についても同様である。また、後述する図３（ｂ）に示す閾値条件データ等も、予めメモリ３６に格納されており、この閾値条件データは後述するように上記閉塞可否判定処理の際に参照される。

図３は、第１の実施形態による閉塞可否判断方法を説明する為の図である。
本例の閉塞可否判断処理は、例えば、上記“ＲＡＩＤが閉塞し得る事象”の何れかが発生すると処理開始する。本手法では、従来のように各“ＲＡＩＤが閉塞し得る事象”毎に閉塞可否を登録しておくものではない。“ＲＡＩＤが閉塞し得る事象”の発生は、単なる処理開始のトリガとなるに過ぎず、閉塞可否の判断は、各ディスクの状態や各ディスクへのアクセスパスの有無等に基づいて、図３（ａ）に示す基準に従った集計を行い（各ディスクを複数のカテゴリ（ここでは、図示の３種類の集計単位）に分類して、各カテゴリ毎に該当したディスクの数をカウントする）、この集計結果を図３（ｂ）に示す閾値条件と比較することにより行う。

まず、図３（ａ）について説明する。
ここで、ＲＡＩＤ閉塞判定を行ううえでは、任意のＲＡＩＤグループ毎に、どのディスクが使用でき、どのディスクが使用できないかを区別し、ＲＡＩＤグループとしてアクセスが可能なのかを判定する必要がある。

その為、ＲＡＩＤグループ内の各ディスクを、その状態に応じて分類する。図３（ａ）に示す通り、“Use Disk”、“Unuse Disk”、“Loop Down Disk”の何れかに分類する。尚、従来で説明した通り、ＲＡＩＤグループとは上記ＲＬＵを意味する。従って、本例の分類・集計処理及び閾値条件との比較・判定処理（つまり、ＲＡＩＤ閉塞判定処理）は、ＲＬＵ単位で行うものである。

基本的には、“Use Disk” はアクセス可能なディスクであり、“Unuse Disk”はアクセスが不可能なディスクである。但し、“Unuse Disk”は、ディスクの故障によってアクセスできなくなった場合が該当する。アクセスパス消失によってアクセスできなくなったディスクは、“Loop Down Disk”に分類するものとし、ディスク故障とは区別する。

以上述べたことを、具体的なディスク状態を示して一覧表にしたものが図３（ａ）である。
図３（ａ）に示すように、“Use Disk”に分類されるディスクは、そのディスクの状態が、Available（通常状態）、Failed Usable（ＲＡＩＤ故障時にRead（読出し）のみ許可状態）、Sparing（Redundant Copy状態）の何れかの状態であるディスクである。但し、これらの状態であっても、後述する“Loop Down Disk”の条件に該当するものは、“Loop Down Disk”に分類する。

“Unuse Disk” に分類されるディスクは、そのディスクの状態が、“Use Disk”に該当しないディスクである。例えば、Broken（故障状態）、Rebuild、Not Existの何れかの状態であるディスクである（但し、後述する特例２を適用する場合には、この限りではない）。また、Not Existに関しては、後述する（５）のケースに該当する場合には、“Loop Down Disk”にカウントする。

但し、ディスクの状態は、図１２に示した種類に限らない。以下、図１２には示していないが“Unuse Disk” に分類されるべき状態の例を列挙しておく。但し、本説明においては、図１２に示していない状態は考慮せずに説明するものとする。
『・Not Available；ディスクが搭載されていない状態。
・Not Supported；定義よりも容量が小さいディスクが搭載された状態。
・Present；Rebuild／Copyback待ちディスク。
・Readying；ディスク組み込み処理中の状態。
・Spare；Hot Spareとして正常状態のディスク（ＲＡＩＤグループに含まれない為、Unuse Diskとして扱う） 』
“Loop Down Disk”に分類されるディスクは、以下の（４）、（５）の何れかの条件に該当するディスクである。

（４）Available、Failed Usable、Sparingの何れかの状態であり、且つ当該ディスクのアクセスパスが無い場合
（５）Available、Failed Usable、Sparingの何れかの状態であるが、Not Exist状態へ遷移（変更）途中の場合
但し、特例として、以下の条件が加わる形態もある。

特例１；Redundant中のRebuild Diskは、集計に含めない。
特例２；Sparing状態であっても“Write Failあり”のディスクは、“Use Disk”ではなく、“Unuse Disk” に分類する。

ここで、上記（５）について説明しておく。まず、前提として、図１には示していないが、従来より、ＣＭ１０は、ＲＡＩＤ装置１内の各部品（ＢＲＴ、ＰＢＣ等）の状態や各ディスクへのアクセスパスや各ディスクの状態を監視・検出する機能部（ＲＡＳと呼ぶ）が存在する。そして、ＲＡＳは、各検出結果を、上記ＲＡＩＤ管理・制御部２２に通知する。ＲＡＩＤ管理・制御部２２は、この通知を受けて、自己が保持・管理する構成情報２２ａを更新する。そして、上記分類の判断は、基本的には、ＲＡＩＤ管理・制御部２２が、この構成情報２２ａを参照して行う。

上記（５）における“遷移（変更）途中”とは、ＲＡＩＤ管理・制御部２２が上記ＲＡＳから新たなディスク状態の通知を受けたが、未だ構成情報２２ａの更新を行なっていない状態を意味する。従って、上記（５）の意味は、上記ＲＡＳが任意のディスクの状態がNot Exist状態に変化したことをＲＡＩＤ管理・制御部２２に通知しているが、ＲＡＩＤ管理・制御部２２が未だこの変化を構成情報２２ａに反映させていない状況を意味している。

ＣＭ（Centralized Module）のＲＡＩＤ管理・制御部２２は、上記の通り基本的には構成情報２２ａを参照して各ディスクの状態を認識し、更に必要に応じてディスクへのアクセスパスをチェックして、これら処理結果に基づいて上記分類を行い、“Use Disk”、“Unuse Disk”、“Loop Down Disk”それぞれに分類されたディスクの数を集計する。そして、図３（ｂ）に示すＲＡＩＤ閉塞閾値表（閾値条件）を参照して集計値と比較して、閉塞可否を判定する。図３（ｂ）に示すＲＡＩＤ閉塞閾値表には、図示の通り、各ＲＡＩＤレベル毎に対応した閾値条件が格納されており、ＣＭは、判定対象のＲＡＩＤグループのＲＡＩＤレベルに対応する閾値条件を参照して、上記集計値と比較して、閉塞可否を判定する。集計値が閾値条件に該当する場合には、閉塞させるものと判定する。

図示の通り、判定対象のＲＡＩＤグループのＲＡＩＤレベルがRAID０の場合には、“Use Disk”の数は関係なく、“Unuse Disk”の数が‘０’で且つ“Loop Down Disk”の数が‘１’以上である場合には、このＲＡＩＤグループは閉塞状態にさせるものと判定する。尚、既に従来で述べた通り、RAID０の場合には、“Unuse Disk”は存在し得ない。なぜなら、RAID０の場合、１つでもディスクが故障したら、使用不能状態となるので、上記図１４（ｇ）で説明した通り、ＢｒではなくＦｕとして扱うからである。よって、Rebuildとなるディスクもあり得ないし、Hot Spareにコピー中となることもない。従って「“Unuse Disk”の数が‘０’」という条件は、上記のことを確認の意味で明示しているだけであると考えても良いので、この条件は無くてもよい。

判定対象のＲＡＩＤグループのＲＡＩＤレベルがRAID１又はRAID0+1の場合には、“Unuse Disk”の数は関係なく、“Use Disk”の数が‘０’で且つ“Loop Down Disk”の数が‘１’以上である場合には、このＲＡＩＤグループは閉塞状態にさせるものと判定する。

判定対象のＲＡＩＤグループのＲＡＩＤレベルがRAID5又はRAID0+5の場合には、２種類の閾値条件のうち、どちらか一方に該当した場合には、ＲＡＩＤグループは閉塞状態にさせるものと判定する。すなわち、２種類の閾値条件は、どちらも、“Use Disk”の数は関係ない（幾つでもよい）。そして、一方の閾値条件は「“Unuse Disk”の数が‘０’で且つ“Loop Down Disk”の数が‘２’以上」、他方の閾値条件は「“Unuse Disk”の数が‘１’で且つ“Loop Down Disk”の数が‘１’以上」である。

図３（ｂ）に示す閾値は、各ＲＡＩＤレベル毎に、ユーザデータを保障できなくなる状態を一意に決定する為のものである。例えば、RAID０の場合、ストライピングである為、１台でもディスクが故障すれば、ユーザデータは消失する。RAID１の場合、ミラーリングである為、ディスクが１台故障しても、ミラーディスクが存在しており、ユーザデータは保障される。

以上説明した閉塞可否判定手法では、以下の（１）〜（４）の効果が得られる。
（１）論理共通化によるコーディング量の削減
（２）論理共通化によるメンテナンス性の向上
（３）発生事象が増えても論理を追加・変更する必要がない（処理開始のトリガが増えるだけ）
（４）ＲＡＩＤレベルが増えても、新たな閾値条件を追加することで対応可能
図４〜図７に、本例のＲＡＩＤ閉塞判定処理のフローチャート図を示す。これらフローチャート図は、基本的には、上記図３（ａ）、（ｂ）で説明して分類方法、閾値を用いた判定方法を、コンピュータによる実行処理手順として示したものである。尚、ここでいうコンピュータとは、上記ＣＭのことである。ＣＭ内のメモリには、図４〜図７に示すＲＡＩＤ閉塞判定処理をＣＰＵ３３又はＣＰＵ３４によって実行させる為のプログラムが格納されている。但し、機能的に言えば、図４〜図７に示すフローチャートの処理は、ＲＡＩＤ管理・制御部２２が行なう。他のフローチャートの処理も同様である。

まず、図４の処理について説明する。図４の処理は、上記特例１、特例２を考慮しない場合の処理である。
図示の処理において、本例のＲＡＩＤ閉塞判定処理（ステップＳ１４以降）は、何等かの部品故障が発生したときに（ステップＳ１１）、この故障によって両系ともFC Loop Down状態となった場合に（ステップＳ１２，ＹＥＳ）実行する。よって、両系ともFC Loop Down状態となる状況にならない場合には（ステップＳ１２，ＮＯ）、本処理は実行しない（ステップＳ１３）。

尚、上記ステップＳ１１、Ｓ１２の判定自体は、従来と同じである。従来では、ステップＳ１２の判定がＹＥＳの場合、上述した“ＲＡＩＤが閉塞し得る事象”を特定する処理を行い、この特定した事象を用いて、図１２の表を参照して、ＲＡＩＤ閉塞可否を判定していた。

一方、本手法では、上記ステップＳ１２の判定がＹＥＳの場合、上記故障部品が接続される全てのＲＡＩＤグループを対象として、各ＲＡＩＤグループ毎にステップＳ１４〜Ｓ２４の処理を実行する。すなわち、まず、そのＲＡＩＤグループ内の各ディスクの状態をチェックする（ステップＳ１４）。そして、各ディスク毎にステップＳ１６〜Ｓ２１の処理を実行する。

まず、処理対象のディスクの状態が、Av（Available）、Fu（Failed Usable）、Spr（Sparing）の何れかの状態である場合には（ステップＳ１６、ＹＥＳ）、このディスクへのアクセスパス（このディスクから見て上位側のパス）があるか否かをチェックし（ステップＳ１８）、Pathがある場合には（ステップＳ１８，ＹＥＳ）“Use Disk”としてカウントし（ステップＳ１９）、Pathが無い場合には（ステップＳ１８，ＮＯ）“Loop Down Disk”としてカウントする（ステップＳ２０）。また、ディスクの状態が、Av、Fu、Spr以外の状態である場合には（ステップＳ１６，ＮＯ）、“Unuse Disk”としてカウントする（ステップＳ１７）。

以上の集計処理を、上記処理対象のＲＡＩＤグループ内の全てのディスクについて実行したら（ステップＳ２１，ＹＥＳ）、上記処理によって得られた、“Use Disk”、“Unuse Disk”、“Loop Down Disk”のカウント値を用いて、図３（ｂ）に示すＲＡＩＤ閉塞閾値表を参照して（上記処理対象のＲＡＩＤグループのＲＡＩＤレベルに対応する閾値条件を参照して）、ＲＡＩＤ閉塞の可否を判定する（ステップＳ２２）。そして、ステップＳ２２の判定がＹＥＳであれば当該ＲＡＩＤグループを閉塞させ（ステップＳ２３）、ＮＯであれば何も処理しない（ステップＳ２４）。

一方、本手法のＲＡＩＤ閉塞可否判定処理は、上記部品故障発生の場合だけでなく、任意のディスクの状態が変化した場合にも実行する。つまり、上記の通り、ＲＡＳは、各ディスクの状態を監視・検出してＲＡＩＤ管理・制御部２２に通知しており、ＲＡＩＤ管理・制御部２２は、構成情報２２ａを参照して、状態が変化したディスクがある場合には図５の処理を開始する。

すなわち、任意のディスクの状態が変化した場合には（ステップＳ８１）、少なくとも当該状態変化したディスクが属するＲＡＩＤグループを処理対象として、このＲＡＩＤグループに属する全てのディスクの状態をチェックし、各ディスク毎にステップＳ８３〜Ｓ９３の処理を実行することで、集計を行う。

すなわち、まず、処理対象のディスクの状態（但し、構成情報２２ａに記録されている状態）が、Av、Fu、Spr以外の状態である場合には（ステップＳ８３，ＮＯ）、“Unuse Disk”としてカウントする（ステップＳ８８）。処理対象のディスクの状態が、Av、Fu、Sprの何れかの状態である場合には（ステップＳ８３，ＹＥＳ）、この処理対象ディスクが変更対象ディスク（状態が変化したディスク）であるか否かを判定する（ステップＳ８４）。そして、変更対象ディスクではない場合には（ステップＳ８４，ＮＯ）、上記ステップＳ１８，Ｓ１９，Ｓ２０と同じ処理を行う（ステップＳ８５，Ｓ９１，Ｓ９２）。すなわち、処理対象ディスクへのアクセスパス（このディスクから見て上位側のパス）があるか否かをチェックし（ステップＳ８５）、Pathがある場合には（ステップＳ８５，ＹＥＳ）“Use Disk”としてカウントし（ステップＳ９１）、Pathが無い場合には（ステップＳ８５，ＮＯ）“Loop Down Disk”としてカウントする（ステップＳ９２）。

一方、処理対象ディスクが変更対象ディスク（状態が変化したディスク）である場合には（ステップＳ８４，ＹＥＳ）、もし上記Av、Fu、Sprの何れかの状態からＮｅ状態（Not Exist）へ変化したのであれば（ステップＳ８６，ＹＥＳ）、“Loop Down Disk”としてカウントする（ステップＳ９０）。一方、もし上記Av、Fu、Sprの何れかの状態からＮｅ状態（Not Exist）以外の状態に変化したならば（ステップＳ８６，ＮＯ）、変化後の状態がAv、Fu、Sprの何れかの状態であれば（ステップＳ８７，ＮＯ）、“Use Disk”としてカウントし（ステップＳ８９）、Av、Fu、Spr以外の状態へと変化したのであれば（ステップＳ８７，ＹＥＳ）、“Unuse Disk”としてカウントする（ステップＳ８８）。

そして、全ての処理対象ディスクについて上述した集計処理を実行したら（ステップＳ９３，ＹＥＳ）、ステップＳ９４，Ｓ９５，Ｓ９６の処理を実行する。ステップＳ９４，Ｓ９５，Ｓ９６の処理は、上記ステップＳ２２，Ｓ２３，Ｓ２４の処理と同じであるので、ここでは説明しない。

次に、図６の処理について説明する。図６の処理は、図４の処理において上記特例１を考慮した処理である。図６において図４の処理と同じ処理ステップには同じステップ番号を付してあり、その説明は省略するものとし、以下、図４の処理と違う部分についてのみ説明する。尚、ここでは、図４の処理に上記特例１を適用した処理を示すが、当然、図５の処理に上記特例１を適用してもよい。この処理は特に図示しないが、上記ステップＳ８３の判定がＮＯの場合に、後述するステップＳ３１の処理が加わることになる。

図６の処理が図４の処理と異なる点は、ステップＳ１６の判定がＮＯとなった場合に、図示のステップＳ３１の処理が加わっている点である。ステップＳ３１の処理は、処理対象ディスクがRedundant Copy中のCopy先Disk（ Redundant中のRebuild Disk）であるか否かを判定し、そうである場合には（ステップＳ３１，ＹＥＳ）、ステップＳ１７の処理は実行しないようにする処理である。ステップＳ３１の判定がＮＯであれば、“Unuse Disk”としてカウントする（ステップＳ１７）。

すなわち、図４の処理では、ステップＳ１６の判定がＮＯであれば必ず“Unuse Disk”としてカウントしたが、本処理では、処理対象ディスクがRedundant Copy先Diskである場合には集計対象から除外する。

次に、図７の処理について説明する。図７の処理は、上記特例１、特例２の両方を考慮した処理である。図７において図６の処理と同じ処理ステップには同じステップ番号を付してあり、その説明は省略するものとし、以下、図６の処理と違う部分についてのみ説明する。

図７の処理が図６の処理と異なる点は、ステップＳ１８の判定がＹＥＳとなった場合に、上記ステップＳ１９の処理の代わりに、図示のステップＳ４１〜Ｓ４３の処理を実行する点である。

ステップＳ１８の判定がＹＥＳとなる場合、すなわち、処理対象ディスクの状態がAv（Available）、Fu（Failed Usable）、Spr（Sparing）の何れかの状態であり且つPathが存在する場合には、上記図４、図６の処理では必ず“Use Disk”としてカウントしたが、本処理では、処理対象ディスクが“Sparing状態で且つWrite失敗あり”の状態である場合には（つまり、上記図１２に示すSpWの状態であれば）（ステップＳ４１，ＹＥＳ）、“Unuse Disk”としてカウントする（ステップＳ４２）。勿論、これ以外の場合には（ステップＳ４１，ＮＯ）、“Use Disk”としてカウントする（ステップＳ４３）。
尚、ここでは、図４の処理に上記特例１、特例２を適用した処理を示すが、当然、図５の処理に上記特例１、特例２を適用してもよい。この処理は特に図示しないが、上記ステップＳ８３の判定がＮＯの場合に対して上記ステップＳ３１の処理が加わり、ステップＳ９１の処理の代わりに上記ステップＳ４１，Ｓ４２，Ｓ４３の処理を行うことになる。

以上説明した処理を、具体例を挙げて説明する。
まず、図８（ａ）に具体例の１つを示す。ここでは、ＲＡＩＤレベルがRAID１のＲＡＩＤグループの２つのディスクＰ１，Ｐ２のうち、ディスクＰ１がBr状態（故障状態）、ディスクＰ２がＡｖ状態（通常状態）であったが、何等かの原因でディスクＰ２に対するアクセスパスが消失した例を示す。この例では、図４の処理を実行すると、ディスクＰ１に関してはステップＳ１６でＮＯとなるので“Unuse Disk”としてカウントし、ディスクＰ２に関してはステップＳ１８でＮＯとなるので“Loop Down Disk”としてカウントする。尚、Ｂｒ状態のディスクは、通常、ＲＡＩＤグループから外れるものとして管理されるが、図８（ａ）の例から明らかなように、本例の集計処理に関してはＢｒ状態のディスクもＲＡＩＤグループに属するものとして集計対象に含めている。

従って、集計結果は、“Use Disk”＝‘０’、“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１’となる。図３（ｂ）においてRAID１に対応する閾値は、“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１以上’であるので、閉塞条件に合致し、当該ＲＡＩＤグループは閉塞させるものと判定される。

図８（ａ）のような例であれば、図４の処理であっても問題なく閉塞可否を判定できる。しかし、本処理は、冗長性が無いＲＡＩＤグループを対象に考えている為、例えばRedundant Copy等のように冗長性を保ちながらRebuildするケースを想定していない為、誤判定が生じる場合がある。

その一例を図８（ｂ）に示す。尚、図８（ｂ）のＲＡＩＤグループのＲＡＩＤレベルはRAID5であるものとする。
図８（ｂ）に示す通り、この例では、ディスクＰ２が故障（Br）した為、上記Hot Spare（ここではＨＳ１）を使用し、ディスクＨＳ１がAv状態になった。その後、ディスクＰ１にも不具合が生じた為、ディスクＰ１をSpr状態にして、Hot Spare（ここではＨＳ２）に対してディスクＰ１のデータをコピーする処理（Redundant Copy）を実行している。しかし、コピー処理実行中に、ディスクＰ１に対するアクセスパスが、何等かの理由により消失してしまったケースを示している。

この様なケースでは、このＲＡＩＤグループは閉塞させなければならない。
しかしながら、図４の処理に従うと、ディスクＰ１はステップＳ１８でＹＥＳとなるので“Loop Down Disk”としてカウントされ、ディスクＨＳ１は“Use Disk” としてカウントされ、ディスクＰ２とＨＳ２は“Unuse Disk”としてカウントされるので、集計結果は以下の通りとなる。

“Use Disk”＝‘１’、“Unuse Disk”＝‘２’、“Loop Down Disk”＝‘１’
一方、図３（ｂ）において、RAID5に対応する閉塞条件は、以下の２種類ある。
・“Unuse Disk”＝‘０’、“Loop Down Disk”＝‘２以上’
・“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１以上’
従って、上記集計結果は、上記２種類の閉塞条件のどちらにも該当しないので、閉塞しないと判定されてしまう。

この為、上記特例１を採用しており、図６の処理を実行する。すなわち、Redundant Copy中のCopy先Disk（この例ではディスクＨＳ２）は、集計対象から除外する。よって、図６の処理を実行した場合の集計結果は以下の通りとなる。

“Use Disk”＝‘１’、“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１’
従って、上記２種類の閉塞条件のうち、
・“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１以上’
に該当することになるので、当該ＲＡＩＤグループは閉塞させるものと判定される（誤判定しない）ことになる。

次に、以下、特例２を用いる理由について、具体例を用いて説明する。
まず、既に説明してあるが、図１２の図上右側に示すように、Redundant Copy(Sparing)には、“Write失敗あり”（SpW）という状態が存在する。この状態は、Redundant Copyの完了率を向上させる為に設けられたものである。すなわち、上記従来技術で説明した通り、全てのディスクに対してWriteを行った結果、Redundant Copyのコピー元でWriteが失敗する場合がある。この場合に、直ぐに故障状態とはせずに、Copyを継続させる場合がある。この状態の一例を図８（ｃ）に示す。図８（ｃ）に示す一例では、ディスクＰ２とＨＳ１はＡｖ状態であり、ディスクＰ１をコピー元としてディスクＨＳ２をコピー先としてRedundant Copyを実行したが、ディスクＰ１でWriteが失敗している。この場合、図示の通り、ディスクＰ１の状態は、Ｂｒ状態とはせずに、“Spr＋WF”状態とし、コピーを継続させる。この状態で、図示の例では、ディスクＰ２に対するアクセスパスが、何等かの理由により消失してしまったケースを示している。

ここで、上記Writeが失敗しているディスクＰ１は、Old Dataが書かれている為、このディスクＰ１からReadすることはできない。また、RAID5の場合は、Read可能なディスク（Av状態のディスク）が最低２つ残っていなければならず、図８（ｃ）に示す状態では、閉塞させなければ、Old DataがReadされ、データ化けに繋がる可能性がある。

しかしながら、図８（ｃ）の状態に対して図６の処理を実行すると、集計結果は以下の通りとなる。
“Use Disk”＝‘２’、“Unuse Disk”＝‘０’、“Loop Down Disk”＝‘１’
従って、上記２種類の閉塞条件のどちらにも該当しないので、閉塞しないことになってしまう。そこで、図７の処理では、ディスクＰ１は、“Use Disk”ではなく、“Unuse Disk”としてカウントするようにしている。つまり、Writeが失敗したRedundant Copyのコピー元ディスクは、故障状態と同様に扱い、ＲＡＩＤグループの状態は冗長性がない状態と同じに扱う。

図８（ｃ）の状態に対して図６の処理を実行すると、集計結果は以下の通りとなる。
“Use Disk”＝‘１’、“Unuse Disk”＝‘１’、“Loop Down Disk”＝‘１’
従って、上記２種類の閉塞条件の一方に該当することになるので、当該ＲＡＩＤグループは閉塞させるものと判定される（適切な判定が行われる）。

ところで、ここで、以上説明した図４〜図７の何れかの処理、あるいは上記従来技術又は何等かの既存技術によって、任意のＲＡＩＤグループを閉塞させた場合、当然、ホスト装置からのアクセスは全て受け付けなくなる為、ホスト装置側ではそれまで実行していた処理は異常終了することになる。これは、ミッションクリティカルなシステムであれば問題無いが（下手にアクセスを滞らせるより、処理を、即、中止させたほうが、システム的に影響は少ない）、そうでないシステム（ホスト側で、レスポンス時間が長くなってもよいから、ＲＡＩＤ装置の復旧を優先させてほしいような事情があるシステム）を考慮して、以下の第２の実施形態を提案する。すなわち、閉塞したＲＡＩＤグループの復旧に時間が掛かるならば仕方ないが、短時間で復旧出来る場合には、実際はＲＡＩＤグループは閉塞していても、ホストに対しては閉塞を知らせない方がよいと考えられる。

この為、第２の実施形態では、実際はＲＡＩＤグループは閉塞していても、短時間で復旧出来る場合には、ホストアクセスに対してダミーの応答（ここでは、Busy）を返すようにする。Busyを返された場合、ホストは、しばらく時間をおいてリトライ処理を行うことになり、それまで実行していた処理を異常終了することにはならない。リトライ処理に対してもBusyを返す。この様にして、ホストがリトライ処理を繰返している間に、閉塞したＲＡＩＤグループを復旧させる（リカバリ処理を行う）。但し、リカバリが失敗した場合には、ホストが延々とリトライ処理を繰返すことになるので、結果的にシステムに悪影響を与える為、即時、ＲＡＩＤ閉塞の発生を通知する。

短時間でリカバリ可能な場合とは、以下の場合である。
（ａ）ＲＡＩＤ装置による自動リカバリ機能が動作する部品故障の場合（但し、自動リカバリ機能が動作する故障と動作しない故障が同時に発生した場合は、短時間でリカバリ可能な場合として扱う。２つのＢＲＴによる２系統によってアクセスする為、一方の系統だけでも自動リカバリ機能によって復旧すれば、使用可能となるからである。）。

（ｂ）あるディスクの故障により他のディスクがSpindownしてしまうような部品故障の場合
上記（ａ）に関して、具体的には、例えば、ＢＲＴのポートが故障した場合、ＣＥ（作業者：人）が強制的に故障させた場合等には、自動リカバリ機能は動作しない。一方、同じくＢＲＴのポートが故障した場合に、ＲＡＩＤ装置側で異常として切り離した場合（例えばＰＢＣが異常と判断したディスク切り離した場合）は、自動リカバリ機能が動作する。

上記ＰＢＣが異常と判断したディスク切り離すことについて説明する。例えば、ＢＲＴの任意のポートに複数のディスクＡ，Ｂ，Ｃが接続されてＦＣループを形成している場合であって、ディスクＡ→ディスクＢ→ディスクＣの順にループするとした場合に、仮にディスクＡが不調になってループが途切れてしまうと、実際にはディスクＡが原因であっても、ＢＲＴのポートが故障したと判定されてしまう場合がある。この場合、ＰＢＣが従来より有するチェック機能により各ディスクをチェックすると、ディスクＡが原因であることが分かるので、ＰＢＣがディスクＡを切り離せば、問題は解決する。

ＲＡＳは、ＲＡＩＤ管理・制御部２２に故障発生を通知する際に、どのルートで故障と判断したのか（上記例では、作業者によるものか、装置側で判断したのか）という情報（Factor）を付加して通知する。ＲＡＩＤ管理・制御部２２は、この情報（Factor）も、構成情報２２ａ内に記録する。上記自動リカバリ機能が動作するものであるか否かの判定は、構成情報２２ａを参照して行ってもよいし、Factorを構成情報２２ａに反映させるタイミングで行っても良い。これは上記（ｂ）に関して同様である。すなわち、部品故障だけでなく、ディスクについても故障と扱う場合には、上記Factorが付加され、構成情報２２ａに反映されるので、このFactorを参照して上記判断を行う。

図９に、上記図７の処理に基づく上記第２の実施形態の処理フローチャート図を示す。
図９において、図７における処理ステップと同じ処理ステップには、同一のステップ番号を付してあり、その説明は省略する。

図７の処理では、ステップＳ２２においてＲＡＩＤを閉塞する（ステップＳ２２，ＹＥＳ）と判定した場合には、ステップＳ２３の処理（ＲＡＩＤを閉塞させる処理）を実行したが、図９の処理では、ステップＳ２３の代わりに、ステップＳ５１〜Ｓ５３の処理を実行する。

すなわち、上記ステップＳ２２の判定がＹＥＳの場合、このＲＡＩＤ閉塞の原因となった故障が、上記（ａ）、（ｂ）の何れかの部品故障であるか否かを判定し（ステップＳ５１）、上記（ａ）、（ｂ）の何れかの部品故障である場合には（ステップＳ５１，ＹＥＳ）、ＲＡＩＤグループを閉塞させると共に、Ｉ／Ｏ制御部２１に対してリカバリ中である旨を通知する（ステップＳ５２）。この通知を受けたＩ／Ｏ制御部２１は、上記ホストアクセスに対してダミーの応答（ここでは、Busy）を返す。

一方、上記（ａ）、（ｂ）の部品故障に該当しない場合には（ステップＳ５１，ＮＯ）、図７の場合と同様、通常通りのＲＡＩＤ閉塞処理を実行する（ステップＳ５３）。
図１０に、ＲＡＩＤ閉塞からの復旧時の処理フローチャート図を示す。

図１０において、ステップＳ６１〜Ｓ６６の処理は、従来通りの処理である。すなわち、故障部品が、部品交換や自動リカバリ等を経て再びシステムに組み込み可能となり（ステップＳ６１）、組み込みに成功したならば（ステップＳ６２，ＹＥＳ）、ＲＡＩＤ復旧判断処理を実施する（ステップＳ６３）。そして、ＲＡＩＤを復旧できると判定したならば（ステップＳ６４，ＹＥＳ）、そのＲＡＩＤグループを復旧させる（ステップＳ６５）。ＲＡＩＤを復旧できないと判定したならば（ステップＳ６４，ＮＯ）、何もしない。

ここで、組み込みに失敗したならば（ステップＳ６２，ＮＯ）、通常であれば何も行わないが（ステップＳ６９）、上記ステップＳ５２の処理を行っていた場合（ステップＳ６７，ＹＥＳ）、ホストはリトライ処理を続けていることになるので、リカバリ失敗をＩ／Ｏ制御部２１に通知して、ホストアクセスをError終了させる必要がある（ステップＳ６８）。

以上説明したように、第２の実施形態では、ＲＡＩＤ閉塞が生じても短時間で復旧可能な場合には、ホストをしばらく待たせておき、ＲＡＩＤ復旧完了と同時にホストアクセスを許可するので、ホストアクセスを異常終了させずにアクセスを再開させることができる。一方、もしＲＡＩＤ復旧失敗した場合には、即、ホストアクセスを異常終了させ、ホストが無駄なリトライ処理を続けないようにする。

（付記１） 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおいて、
前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクの状態又は前記各ディスクへのアクセスパスの有無に基づいて、前記各ディスクを複数のカテゴリに分類して当該分類単位毎に該当するディスクの数を集計し、該各集計結果と予め設定される閾値条件とを比較することによって、該ＲＡＩＤグループを閉塞させるか否かを判定するＲＡＩＤ管理・制御手段、
を有することを特徴とするコントローラ・モジュール。

（付記２） 前記複数のカテゴリは、“Use Disk”、“Unuse Disk”、“Loop Down Disk”であり、
前記閾値条件は各ＲＡＩＤレベル毎に設定され、前記判定は処理対象の前記ＲＡＩＤグループのＲＡＩＤレベルに応じた閾値条件を用いて行うことを特徴とする付記１記載のコントローラ・モジュール。

（付記３） 基本的には、前記“Use Disk”はアクセス可能なディスクであり、前記“Unuse Disk”はディスクの故障によってアクセスできないディスクであり、前記“Loop Down Disk”はアクセスパス消失によってアクセスできないディスクであることを特徴とする付記１又は２記載のコントローラ・モジュール。

（付記４） 前記ＲＡＩＤレベルがRAID０の場合、前記閾値条件は、“Unuse Disk”が０且つ“Loop Down Disk”が１以上であり、
ＲＡＩＤレベルがRAID０の前記ＲＡＩＤグループであって前記集計結果が該閾値条件に該当したＲＡＩＤグループは、閉塞させると判定することを特徴とする付記２記載のコントローラ・モジュール。

（付記５） 前記ＲＡＩＤレベルがRAID１又はRAID０＋１の場合、前記閾値条件は、“Use Disk”が０且つ“Loop Down Disk”が１以上であり、
ＲＡＩＤレベルがRAID１又はRAID０＋１の前記ＲＡＩＤグループであって前記集計結果が該閾値条件に該当したＲＡＩＤグループは、閉塞させると判定することを特徴とする付記２記載のコントローラ・モジュール。

（付記６） 前記ＲＡＩＤレベルがRAID５又はRAID０＋５の場合、前記閾値条件は、“Unuse Disk”が０且つ“Loop Down Disk”が２以上、又“Unuse Disk”が１且つ“Loop Down Disk”が１以上であり、
ＲＡＩＤレベルがRAID５又はRAID０＋５の前記ＲＡＩＤグループであって前記集計結果が該２種類の閾値条件の何れか一方に該当したＲＡＩＤグループは、閉塞させると判定することを特徴とする付記２記載のコントローラ・モジュール。

（付記７） Redundant コピー中のコピー先ディスクは、前記集計の対象外とすることを特徴とする付記２記載のコントローラ・モジュール。
（付記８） Sparing状態であっても“Write失敗あり”のディスクは、前記“Use Disk”ではなく、前記“Unuse Disk” に分類することを特徴とする付記２記載のコントローラ・モジュール。

（付記９） 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおいて、
該コントローラ・モジュールと外部の任意のホスト装置とのインタフェースであるＩ／Ｏ制御手段と、
前記ＲＡＩＤ装置内の任意の前記ＲＡＩＤグループの閉塞可否の判定、閉塞の実行を管理・制御するＲＡＩＤ管理・制御手段とを有し、
前記ＲＡＩＤ管理・制御手段は、任意の前記ＲＡＩＤグループの閉塞を実行する場合、該ＲＡＩＤグループが短時間でリカバリ可能か否かを判定し、短時間でリカバリ可能と判定した場合、その旨を前記Ｉ／Ｏ制御手段に通知し、
前記Ｉ／Ｏ制御手段は、該通知を受けた場合であって前記ホスト装置が前記閉塞されたＲＡＩＤグループへのアクセスを要求した場合には、該ホスト装置に対してダミーの応答を返信することを特徴とするコントローラ・モジュール。

（付記１０） 前記ダミーの応答は、Ｂｕｓｙであり、
該Busyの応答により、前記ホスト装置は、リトライ処理を繰返すことを特徴とする付記９記載のコントローラ・モジュール。

（付記１１） 前記短時間でリカバリ可能な場合とは、前記ＲＡＩＤ装置による自動リカバリ機能が動作する部品故障の場合、又は任意のディスクの故障により他のディスクがSpindownした場合であることを特徴とする付記９記載のコントローラ・モジュール。

（付記１２） ＲＡＩＤ装置において、
複数のディスクより成るＲＡＩＤグループと、
前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクの状態又は前記各ディスクへのアクセスパスの有無に基づいて、該各ディスクを複数のカテゴリに分類して当該分類単位毎に該当するディスクの数を集計し、該各集計結果と予め設定される閾値条件とを比較することによって、該ＲＡＩＤグループを閉塞させるか否かを判定するコントローラ・モジュールと、
を有することを特徴とするＲＡＩＤ装置。

（付記１３） ＲＡＩＤ装置において、
該ＲＡＩＤ装置と外部の任意のホスト装置とのインタフェースであるＩ／Ｏ制御手段と、
該ＲＡＩＤ装置内の任意のＲＡＩＤグループの閉塞可否の判定、閉塞の実行を管理・制御するＲＡＩＤ管理・制御手段とを有し、
前記ＲＡＩＤ管理・制御手段は、前記任意のＲＡＩＤグループの閉塞を実行する場合、該ＲＡＩＤグループが短時間で復旧するか否かを判定し、短時間で復旧すると判定した場合、その旨を前記Ｉ／Ｏ制御手段に通知し、
前記Ｉ／Ｏ制御手段は、該通知を受けた場合、前記ホスト装置が前記閉塞されたＲＡＩＤグループへのアクセスを要求した場合、該ホスト装置に対してダミーの応答を返信することを有することを特徴とするＲＡＩＤ装置。

（付記１４） 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置におけるコンピュータに、
前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクの状態や前記各ディスクへのアクセスパスの有無に基づいて、該各ディスクを複数のカテゴリに分類して当該分類単位毎に該当するディスクの数を集計する機能と
該各集計結果と予め設定される閾値条件とを比較することによって、該ＲＡＩＤグループを閉塞させるか否かを判定する機能と、
を実現させる為のプログラム。

(付記１５) ＲＡＩＤ装置におけるコンピュータに、
該ＲＡＩＤ装置内の任意のＲＡＩＤグループの閉塞可否の判定、閉塞の実行を管理・制御する機能と、
前記任意のＲＡＩＤグループの閉塞を実行する場合、該ＲＡＩＤグループが短時間で復旧するか否かを判定し、短時間で復旧すると判定した場合であって該閉塞されるＲＡＩＤグループへのアクセスを外部のホスト装置が要求する場合、該ホスト装置に対してダミーの応答を返信する機能と、
を実現させる為のプログラム。

（付記１６） 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおけるＲＡＩＤ閉塞判定方法であって、
前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクの状態や前記各ディスクへのアクセスパスの有無に基づいて、該各ディスクを複数のカテゴリに分類して当該分類単位毎に該当するディスクの数を集計し、
該各集計結果と予め設定される閾値条件とを比較することによって、該ＲＡＩＤグループを閉塞させるか否かを判定することを特徴とするＲＡＩＤ閉塞判定方法。

本例のＲＡＩＤ装置の構成図である。 図１に示すＣＭのハードウェア構成図である。 （ａ）、（ｂ）は、本手法による閉塞可否判断方法を説明する為の図である。 本例のＲＡＩＤ閉塞判定処理のフローチャート図（その１）である。 本例のＲＡＩＤ閉塞判定処理のフローチャート図（その２）である。 本例のＲＡＩＤ閉塞判定処理のフローチャート図（その３）である。 本例のＲＡＩＤ閉塞判定処理のフローチャート図（その４）である。 （ａ）〜（ｃ）は、図４〜図７の処理を具体例を用いて説明する為の図である。 本例の第２の実施形態の処理フローチャート図（その１）である。 本例の第２の実施形態の処理フローチャート図（その２）である。 従来のＲＡＩＤシステムの概略構成図である。 従来のＲＡＩＤ閉塞判定方法を説明する為の図である。 （ａ）、（ｂ）は、ＲＬＵ／ＤＬＵを説明する為の図である。 （ａ）〜（ｊ）は、ＲＡＩＤグループがとりえる状態を説明する為の図である。 “ＢＲＴ跨ぎ”を説明する為の図である。

符号の説明

１ ＲＡＩＤ装置
２（２ａ、２ｂ） ホスト
１０（１０ａ、１０ｂ） ＣＭ
３ ＦＲＴ
４，５ ＢＲＴ
６，７ ＤＥ
６ａ，６ｂ、７ａ、７ｂ ＰＢＣ
６ｃ、７ｃ ディスク群
２１ Ｉ／Ｏ制御部
２２ ＲＡＩＤ管理・制御部
２２ａ 構成情報
３１ ＤＩ
３２ ＤＭＡ
３３，３４ ＣＰＵ
３５ ＭＣＨ(Memory Controller Hub)
３６ メモリ
３７ ＣＡ

Claims (8)

1. 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールにおいて、
   前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクを、前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスの有無および前記ＲＡＩＤグループに属する前記各ディスクの状態に基づいた複数の分類単位に分類した上で、前記複数の分類単位にそれぞれ属する前記ＲＡＩＤグループに属する前記特定の事象が発生したディスクの数を集計し、
   ここで前記複数の分類単位は前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた分類単位を含み、
   該各集計結果のうちの少なくとも前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果と対応する予め設定される閾値条件とを比較し、
   前記各集計結果のうちの前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果が対応する前記閾値条件を満たしたときに該ＲＡＩＤグループを閉塞させると判定する、
   ＲＡＩＤ管理・制御手段、
   を有することを特徴とするコントローラ・モジュール。
2. 前記閾値条件は各ＲＡＩＤレベル毎に設定され、前記判定は処理対象の前記ＲＡＩＤグ
   ループのＲＡＩＤレベルに応じた閾値条件を用いて行うことを特徴とする請求項１記載のコントローラ・モジュール。
3. 前記複数の分類単位が、第一の分類単位および第三の分類単位を含み、
   前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位が、前記第三の分類単位に相当し、
   前記ＲＡＩＤレベルがRAID１又はRAID０＋１の場合、前記閾値条件は、前記第一の分類単位に属する前記特定の事象が発生したディスクの数が０且つ前記第三の分類単位に属する前記特定の事象が発生したディスクの数が１以上、であり、
   ＲＡＩＤレベルがRAID１又はRAID０＋１の前記ＲＡＩＤグループであって前記集計結果が該閾値条件に該当したＲＡＩＤグループは、閉塞させると判定することを特徴とする請求項２記載のコントローラ・モジュール。
4. 前記複数の分類単位が、第二の分類単位および第三の分類単位を含み、
   前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位が、前記第三の分類単位に相当し、
   前記ＲＡＩＤレベルがＲＡＩＤ５又はＲＡＩＤ０＋５の場合、前記閾値条件は、前記第二の分類単位に属する前記特定の事象が発生したディスクの数が０且つ前記第三の分類単位に属する前記特定の事象が発生したディスクの数が２以上、であるか又は、前記第二の分類単位に属する前記特定の事象が発生したディスクの数が１且つ前記第三の分類単位に属する前記特定の事象が発生したディスクの数が１以上、であり、
   ＲＡＩＤレベルがRAID５又はRAID０＋５の前記ＲＡＩＤグループであって前記集計結果が該２種類の閾値条件の何れか一方に該当したＲＡＩＤグループは、閉塞させると判定することを特徴とする請求項２記載のコントローラ・モジュール。
5. 該コントローラ・モジュールと外部の任意のホスト装置とのインタフェースであるＩ／Ｏ制御手段
   をさらに含み、
   前記ＲＡＩＤ管理・制御手段は、任意の前記ＲＡＩＤグループの閉塞を実行する場合、該ＲＡＩＤグループが短時間でリカバリ可能か否かを判定し、短時間でリカバリ可能と判定した場合、その旨を前記Ｉ／Ｏ制御手段に通知し、
   前記Ｉ／Ｏ制御手段は、該通知を受けた場合であって前記ホスト装置が前記閉塞されたＲＡＩＤグループへのアクセスを要求した場合には、該ホスト装置に対してダミーの応答を返信することを特徴とする請求項１記載のコントローラ・モジュール。
6. ＲＡＩＤ装置において、
   複数のディスクより成るＲＡＩＤグループと、
   前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクを、前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスの有無および前記ＲＡＩＤグループに属する前記各ディスクの状態に基づいた複数の分類単位に分類した上で、前記複数の分類単位にそれぞれ属する前記ＲＡＩＤグループに属する前記特定の事象が発生したディスクの数を集計し、
   ここで前記複数の分類単位は前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた分類単位を含み、
   該各集計結果のうちの少なくとも前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果と対応する予め設定される閾値条件とを比較し、
   前記各集計結果のうちの前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果が対応する前記閾値条件を満たしたときに該ＲＡＩＤグループを閉塞させると判定する、
   コントローラ・モジュールと、
   を有することを特徴とするＲＡＩＤ装置。
7. 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置内のコントローラ・モジュールが実行するＲＡＩＤ閉塞判定方法であって、
   前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクを、前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスの有無および前記ＲＡＩＤグループに属する前記各ディスクの状態に基づいた複数の分類単位に分類した上で、前記複数の分類単位にそれぞれ属する前記ＲＡＩＤグループに属する前記特定の事象が発生したディスクの数を集計し、
   ここで前記複数の分類単位は前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた分類単位を含み、
   該各集計結果のうちの少なくとも前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果と対応する予め設定される閾値条件とを比較し、
   前記各集計結果のうちの前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果が対応する前記閾値条件を満たしたときに該ＲＡＩＤグループを閉塞させると判定する
   ことを特徴とするＲＡＩＤ閉塞判定方法。
8. 複数のディスクより成るＲＡＩＤグループを有するＲＡＩＤ装置におけるコンピュータに、
   前記ＲＡＩＤ装置内でＲＡＩＤ閉塞可否を判定すべき特定の事象が発生する毎に、閉塞判定対象となる前記各ＲＡＩＤグループ毎に、前記ＲＡＩＤグループに属する前記各ディスクを、前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスの有無および前記ＲＡＩＤグループに属する前記各ディスクの状態に基づいた複数の分類単位に分類した上で、前記複数の分類単位にそれぞれ属する前記ＲＡＩＤグループに属する前記特定の事象が発生したディスクの数を集計し、ここで前記複数の分類単位は前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた分類単位を含む、という機能と
   該各集計結果のうちの少なくとも前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果と対応する予め設定される閾値条件とを比較し、前記各集計結果のうちの前記ＲＡＩＤグループに属する前記各ディスクへのアクセスパスが無い場合に応じた前記分類単位に属する前記特定の事象が発生したディスクの数の集計結果が対応する前記閾値条件を満たしたときに該ＲＡＩＤグループを閉塞させると判定する機能と、
   を実現させる為のプログラム。