前述の冗長構成において、例えばコンピュータから記憶装置に至るパスの途中に存在する機器で障害が発生すると、当該機器を経由する複数のパスで障害の発生が各々検知される等のように、冗長構成では障害発生時に障害の発生が連続的に複数回通知されることが多い。このため、障害発生が通知されたことをトリガとして、障害の発生が通知されたパスを閉塞する等の障害対処処理を行う場合、この障害対処処理が頻繁に繰り返されることでコンピュータに多大な負荷が加わり、コンピュータ・システムの動作が不安定になったり、コンピュータがダウンする等の事態も生じ得る。
上記の問題に対しては、障害発生が通知されたことをトリガとして行われる障害対処処理に、特許文献2に記載の排他制御を適用することが考えられる。しかしながら、障害対処処理の実行に特許文献2に記載の技術を適用した場合、障害対処処理を行うプロセスが障害発生が通知される度に生成されると共に、生成されたプロセスは、マスタ権を獲得する迄マスタ権の獲得を繰り返し試行することになる。このため、パスの途中に存在する機器で障害が発生した等のように多数のパスに影響を及ぼす障害が発生し、多数のパスの障害発生が連続的に通知された場合、多数のプロセスが生成されることでコンピュータに多大な負荷が加わると共に、メモリ等のリソースが大量に消費されるので、コンピュータの動作の安定化に有効ではない。
本発明は上記事実を考慮して成されたもので、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現できる障害管理装置及び障害管理プログラムを得ることが目的である。
上記目的を達成するために請求項1記載の発明に係る障害管理装置は、複数の外部機器のうちの互いに異なる前記外部機器と通信するための複数のパスから成るグループが複数設けられたコンピュータによって実現される障害管理装置であって、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段と、前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段と、前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段と、を備えている。
請求項1記載の発明に係る障害管理装置は、複数の外部機器のうちの互いに異なる外部機器と通信するための複数のパスから成るグループが複数系統設けられたコンピュータによって実現される。なお、本発明に係る外部機器としては、例えば請求項9に記載したように、情報を記憶可能でかつ記憶している情報を書替可能な記憶装置が好適であるが、他の機器であってもよい。また、本発明におけるグループは、例えば図2に「パスのグループ」と表記して示すように、物理的な通信経路を共有する複数のパスで構成することができる。請求項1記載の発明では、何れかのパスでの障害の発生が通知される毎に、判定手段により、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かが判定される。なお、同一属性での重複作成が制限されているファイル情報としては、例えば同一名称での重複作成が制限されているファイル情報、具体的にはUNIX(登録商標)系のオペレーティング・システムにおけるディレクトリや、WINDOWS(登録商標)系のオペレーティング・システムにおけるフォルダを適用することができる。また、判定手段によって所定の属性のファイル情報が作成されていないと判定された場合は、作成手段により所定の属性のファイル情報の作成が試行され、作成手段による所定の属性のファイル情報の作成が成功した場合には、制御手段により、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われる。
このように、請求項1記載の発明では、同一グループに属するパスは障害発生時に同様の影響を受けることが多く、障害の発生が各々通知されることが多いことに基づき、閉塞処理として、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための処理を行うので、同一グループに属する各パスが各々影響を受ける障害が発生したとしても、各パスのうちの何れか1つのパスでの障害の発生が通知されたことに基づいて閉塞処理を一旦行った以降は、当該閉塞処理によって閉塞された各パスでの障害発生が通知されることが無くなり、複数のパスに影響を及ぼす障害が発生した場合にコンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。
また、或るパスで障害が発生した場合、その原因は障害が発生したパス上のハードウェア(例えばHBA(Host Bus Adapter)やケーブル等)の不調や故障等であることが多く、当該ハードウェアを被疑部位として稼働中の部位より切り離し、必要に応じて交換する保守作業(発生した障害を復旧させるための作業)が行われるが、この保守作業の実施に際し、被疑部位としてのハードウェアを経由する別のパスが存在している場合には、当該別のパスで障害が発生しているか否かに拘わらず、被疑部位としてのハードウェアの切り離しを行うために、前記別のパスが通信に使用されないように前記別のパスも閉塞する必要がある。請求項1記載の発明では、何れかのパスでの障害の発生が通知されると、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われるので、保守作業の実施に際し、障害が発生したパスと同一のグループに属する他の全てのパスを改めて閉塞する必要が無くなり、保守作業を行う作業者の負担を軽減することができる。
また、請求項1記載の発明によれば、何れかのパスでの障害の発生が通知されると、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われるので、コンピュータと接続する複数のパス(互いに異なるグループに属する複数のパス:一例として図2には、論理ディスクLU#0をサーバ・コンピュータ12と接続している全てのパスを明示している)のうちの一部のパスが閉塞され、かつ、閉塞されているパスが属するグループが相違する外部機器が複数存在している状態(本明細書ではこの状態を交差閉塞状態という)が生ずることを極力回避することができる。上記の交差閉塞状態が生じた場合、保守作業の実施に際し、障害が発生したパスと同一のグループに属する他の全てのパスを閉塞しようとすると、コンピュータと接続する複数のパスが全て閉塞されることで通信不能となってしまう外部機器が出現するので、保守作業の実施が困難になるが、請求項1記載の発明では、このような状況に陥ってしまうことを極力回避することができ、保守作業を実施できる確率を向上させることができる。
また、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合に、個々の通知に対応する処理が各々行われることになるが、本発明では、1回の閉塞処理により、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するので、閉塞処理の実行回数はパスのグループ毎に1回でよい。このため請求項1記載の発明では、障害の発生が通知されたパスが属するグループに対応する所定の属性のファイル情報が作成されておらず、所定の属性のファイル情報の作成が成功した場合に閉塞処理を行っている。
これにより、障害の発生が最も早く通知された特定のパスに対応する処理では、ファイル情報の作成が成功することで閉塞処理が行われる一方、前記特定のパスよりも後に障害の発生が通知された残りのパスに対応する処理では、所定の属性のファイル情報が既に作成されているか否かの判定のタイミングが、前記特定のパスに対応する処理における所定の属性のファイル情報の作成後であれば、所定の属性のファイル情報が既に作成されていると判定され、所定の属性のファイル情報が既に作成されているか否かの判定のタイミングが、特定のパスに対応する処理における所定の属性のファイル情報の作成前であったとしても、同一属性のファイル情報の重複作成が制限されているためにファイル情報の作成には失敗することで、閉塞処理は行われない。
このように、請求項1記載の発明では、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合にも、閉塞処理が重複して実行されることを確実に防止することができ、コンピュータに加わる負荷を低減することができる。従って、請求項1記載の発明によれば、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現することができる。
なお、請求項1記載の発明において、例えば請求項2に記載したように、判定手段、作成手段及び制御手段は、何れかのグループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、コンピュータによるプログラムの実行は、作成手段による所定の属性のファイル情報の作成が失敗した場合に終了されるように構成することが好ましい。これにより、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合にも、個々の通知に対応する処理のうちファイル情報の作成に失敗した処理については、コンピュータによる実行が終了されることになり、当該処理の実行を終了させない場合と比較して、コンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。
また、請求項1又は請求項2記載の発明において、例えば請求項3に記載したように、判定手段は、所定の属性のファイル情報が既に作成されていると判定した場合に、当該ファイル情報が作成されてからの経過時間が閾値以上か否かを判定し、制御手段は、閉塞処理の終了後に、作成手段によって作成された所定の属性のファイル情報を削除すると共に、判定手段により、所定の属性のファイル情報が既に作成されており、当該ファイル情報が作成されてからの経過時間が閾値以上と判定された場合に、既に作成されているファイル情報を削除し、作成手段は、判定手段によって前記経過時間が閾値以上と判定された場合に、既に作成されているファイル情報が制御手段によって削除された後に、所定の属性のファイル情報の作成を試行するように構成することが好ましい。
請求項3記載の発明における閾値としては、判定手段、作成手段及び制御手段による一連の処理に要する時間よりも所定値以上長く、前回に発生が通知された障害とは異なる障害であると判断できる程度の時間(例えば1分間程度)に相当する値が好適である。請求項3記載の発明では、閉塞処理の終了後に、作成手段によって作成されたファイル情報が制御手段によって削除されるが、判定手段により、所定の属性のファイル情報が既に作成されており、当該ファイル情報が作成されてからの経過時間が閾値以上と判定された場合、当該ファイル情報は、何らかの理由で制御手段による削除が失敗し、残ってしまったファイル情報である可能性が高い。請求項3記載の発明では、このようなファイル情報も制御手段によって削除され、その後、作成手段によってファイル情報の作成が試行されるので、制御手段によるファイル情報の削除が失敗した場合にも、削除されずに残っているファイル情報が作成されてから閾値以上の時間の経過に伴い、作成手段が同一属性のファイル情報を再度作成することが可能で、制御手段が閉塞処理を行うことが可能な状態に復帰させることができる。
また、請求項3記載の発明において、例えば請求項4に記載したように、判定手段、作成手段及び制御手段は、何れかのグループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、コンピュータによる前記プログラムの実行は、判定手段によって所定の属性のファイル情報が作成されており、かつ前記経過時間が閾値未満と判定された場合に終了されるように構成することが好ましい。これにより、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生が閾値未満の時間間隔で各々通知された場合にも、各パスに対応する処理のうち障害の発生が2番目以降に通知されたパスに対応する処理については、コンピュータによる実行が終了されることになり、当該処理の実行を終了させない場合と比較して、コンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。
また、請求項1〜請求項4の何れかに記載の発明において、個々のグループの個々のパスの各々の状態を表す状態情報を状態テーブルに登録・管理し、コンピュータと個々の外部機器との通信に用いるパスを選択すると共に、状態情報として閉塞を意味する情報が状態テーブルに登録されているパスを、外部機器との通信における選択対象から除外する処理を含む管理処理を行う管理手段が設けられている場合、制御手段は、例えば請求項5に記載したように、閉塞処理として、状態テーブルに登録されている状態情報のうち、障害の発生が通知されたパスと同一のグループに属する全てのパスの状態情報を、閉塞を意味する情報に各々書き替える処理を行うように構成することができる。これにより、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞することを、簡易な処理によって実現することができる。
また、請求項5記載の発明において、制御手段は、例えば請求項6に記載したように、閉塞処理を行う前に状態テーブルを参照し、障害の発生が通知されたパスと同一のグループに属する全てのパスのうちの特定のパスが、当該特定のパスと同一の外部機器に対応する複数のパスのうちの未閉塞の最後のパスか否かを確認し、特定のパスが前記最後のパスであった場合は、状態テーブルに登録されている特定のパスに対応する状態情報の書き替えを中止することを、障害の発生が通知されたパスと同一のグループに属する全てのパスについて各々行うように構成することが好ましい。これにより、閉塞処理の実行に伴ってコンピュータと通信するためのパスが全て閉塞された外部機器が出現することを防止することができ、閉塞処理の実行に拘わらず、コンピュータが1つ以上の未閉塞のパスを経由して個々の外部機器と通信可能な状態を維持することができる。
また、請求項1〜請求項6の何れかに記載の発明において、例えば請求項7に記載したように、判定手段、作成手段及び制御手段は、何れかのグループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、制御手段による閉塞処理により、状態テーブルに登録されている状態情報のうち、障害の発生が通知されたパスと同一のグループに属する全てのパスの状態情報が閉塞を意味する情報に各々書き替えられた場合に、障害の発生が通知された際の前記プログラムの起動を停止させる起動制御手段が設けられていることが好ましい。これにより、障害の発生が通知されたパスと同一のグループに属する全てのパスが閉塞されている状態、すなわち前記全てのパスが閉塞処理が不要な状態であるにも拘わらず、前記プログラムが無駄に起動されることを防止することができ、コンピュータに加わる負荷の更なる低減及びメモリ等のリソースの消費量の更なる抑制を実現することができる。
また、請求項7記載の発明において、起動制御手段は、例えば請求項8に記載したように、制御手段によって閉塞処理が行われた結果、複数の外部機器の各々が、対応する複数のパスのうち未閉塞のパスの数が残り1つの状態となった場合にも、障害の発生が通知された際の前記プログラムの起動を停止させるように構成することが好ましい。これにより、個々の外部機器に対応する未閉塞のパスの数が各々残り1つの状態、すなわち閉塞処理を行って閉塞状態のパスを増加させることが望ましくない状態であるにも拘わらず、前記プログラムが無駄に起動されることを防止することができ、コンピュータに加わる負荷の更なる低減及びメモリ等のリソースの消費量の更なる抑制を実現することができる。
請求項10記載の発明に係る障害管理プログラムは、複数の外部機器のうちの互いに異なる前記外部機器と通信するための複数のパスから成るグループが複数設けられたコンピュータを、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段、前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段、及び、前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段として機能させる。
請求項10記載の発明に係る障害管理プログラムは、上記コンピュータを、上記の判定手段、作成手段及び制御手段として機能させるためのプログラムであるので、コンピュータが請求項10記載の発明に係る障害管理プログラムを実行することで、コンピュータが請求項1に記載の障害管理装置として機能することになり、請求項1記載の発明と同様に、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現することができる。
請求項11記載の発明に係る障害管理プログラムは、複数の外部機器のうちの互いに異なる前記外部機器と通信するための複数のパスから成るグループが複数系統設けられたコンピュータを、請求項1〜請求項9の何れか1項記載の障害管理装置の各手段として機能させる。
請求項11記載の発明に係る障害管理プログラムは、上記コンピュータを、請求項1〜請求項9の何れか1項記載の障害管理装置の各手段として機能させるためのプログラムであるので、コンピュータが請求項11記載の発明に係る障害管理プログラムを実行することで、コンピュータが請求項1〜請求項9の何れかに記載の障害管理装置として機能することになり、請求項1〜請求項9の何れかに記載の発明と同様に、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現することができる。
以上説明したように本発明は、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定し、所定の属性のファイル情報が作成されていない場合に、所定の属性のファイル情報の作成を試行し、所定の属性のファイル情報の作成が成功した場合に、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行うようにしたので、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現できる、という優れた効果を有する。
以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図1には本実施形態に係るコンピュータ・システム10が示されている。コンピュータ・システム10は、複数台のサーバ・コンピュータ12(図1では2台のサーバ・コンピュータ12A,12Bのみ図示している)と、論理ディスクLUが複数設けられ光ファイバケーブル22を介して個々のサーバ・コンピュータ12と各々接続されたディスク装置24を備えており、DB(データベース)サーバとして機能する。なお、個々のサーバ・コンピュータ12は本発明に係るコンピュータに、ディスク装置24に設けられた個々の論理ディスクLUは本発明に係る外部機器、詳しくは請求項9に記載の記憶装置に対応している。
個々のサーバ・コンピュータ12は、CPU14、メモリ16、ディスク駆動装置(DKU)によって駆動されるディスクドライブ等から成る不揮発性の記憶部18、サーバ・コンピュータ12を光ファイバ経由でディスク装置24と接続するための複数のHBA(Host Bus Adapter)20(図1では2個のHBA(HBA#0,HBA#2)のみ示している)を含んで構成されている。個々のサーバ・コンピュータ12の記憶部18には、ディスク装置24(詳しくはディスク装置24の複数の論理ディスクのうちの何れかの論理ディスク)へのI/O(Input/Output:入出力)要求を出力するアプリケーション・プログラム、アプリケーションからのI/O要求に応答してハードウェアの制御等を行うオペレーティング・システム(OS)のプログラム、リンク管理部のプログラム、ドライバのプログラム、パス閉塞制御シェル(プログラム)及びログトラップのプログラムが各々記憶されている。なお、リンク管理部、ドライバ、パス閉塞制御シェル及びログトラップについては後述する。
記憶部18に記憶されている各プログラムは、サーバ・コンピュータ12の稼働開始時に記憶部18から読み出されてメモリ16に各々記憶され、必要時にCPU14によって実行される。なお、記憶部18に記憶されている各プログラムのうち、パス閉塞制御シェルは本発明に係る障害管理プログラムに対応しており(請求項2,4,7に記載の「単一のプログラム」にも対応している)、サーバ・コンピュータ12は、CPU14がパス閉塞制御シェルを実行することで本発明に係る障害管理装置として機能する。
一方、ディスク装置24は、ディスク駆動装置(DKU)26によって駆動される多数台のディスクドライブを備えている。多数台のディスクドライブは、各々冗長化された複数の論理ディスクLUを形成するように互いに接続されている(図1では、ディスク装置24に設けられた論理ディスクの一部(LU#0〜LU#3,LU#m〜LU#m+3,LU#n〜LU#n+3)のみ示されている)。また、ディスク装置24にはディスク制御装置(DKC)28が設けられている。ディスク制御装置(DKC)28には複数(図1では2個)のクラスタ30が設けられており、個々のクラスタ30には、複数(図1では2個)のチャネル・アダプタ(CHA)32、複数(図1では2個)のディスク・アダプタ(DKA)34、チャネル・アダプタ(CHA)32とディスク・アダプタ(DKA)34を接続するキャッシュ・スイッチ(CSW)36が設けられている。
個々の論理ディスクLUは個々のクラスタ30の何れか1つののディスク・アダプタ(DKA)34に各々接続されている。また、同一のクラスタ30に設けられた複数のチャネル・アダプタ(CHA)32は、互いに異なるサーバ・コンピュータ12のHBA20と光ファイバケーブル22を介して各々接続されており、チャネル・アダプタ(CHA)32は、サーバ・コンピュータ12から光ファイバケーブル22経由でI/O要求を受信すると、キャッシュ・スイッチ(CSW)36を介し、受信したI/O要求におけるアクセス対象の論理ディスクLUが接続されたディスク・アダプタ(DKA)34へI/O要求を転送する。
次に本実施形態の作用として、まず、コンピュータ・システム10がDBサーバとして稼働しており、ディスク装置24等に障害が発生していない状態で、サーバ・コンピュータ12のCPU14によって各プログラムが実行されることで実現される処理について、図2を参照して説明する。
本実施形態では、個々のサーバ・コンピュータ12にHBA20が複数設けられており、個々のHBA20は光ファイバケーブル22を介してディスク装置24(の互いに異なるクラスタ30のチャネル・アダプタ(CHA)32)に各々接続されているので、図2に破線で示すように、個々のサーバ・コンピュータ12は、ディスク装置24の個々の論理ディスクLUと複数のパス(互いに異なるチャネル・アダプタ(CHA)32を経由する複数のパス)を介して通信可能とされており、個々の論理ディスクLUと通信を行うためのパスが冗長化(多重化)されている。なお、単一のサーバ・コンピュータ12とディスク装置24との間に設けられた複数のパスは、同一のチャネル・アダプタ(CHA)32を経由するパス(物理的な通信経路を共有するパス)を単位としてグループ化されている(図2に示す「パスのグループ」も参照)。
前述のアプリケーションから出力されるディスク装置24へのI/O要求では、アクセス対象の論理ディスクLUが指定される。このI/O要求はOSを経由し、リンク管理部のプログラムがサーバ・コンピュータ12のCPU14によって実行されることで実現されるリンク管理部に転送・入力される。リンク管理部は、個々のパスへの負荷を把握し、入力されたI/O要求をアクセス対象の論理ディスクLUへ転送するためのパスを個々のパスへの負荷が分散するように選択し、ドライバのプログラムがサーバ・コンピュータ12のCPU14によって実行されることで実現されるドライバに対し、前記選択したパスを指定して前記I/O要求を転送・入力することで、前記I/O要求が前記選択したパスを通じて転送されるように制御する。また、リンク管理部は個々のパス毎にその状態が稼働中(Online)か非稼働中(閉塞中/Offline)かを表す状態情報を登録するためのパス状態管理テーブルを保持しており、I/O要求の転送に用いるパスの選択に際しては、パス状態管理テーブルに登録されている状態情報が「非稼働中(閉塞中):offline」のパスが選択対象から除外される。
このように、リンク管理部は請求項5に記載の管理部に、パス状態管理テーブルは請求項5に記載の状態テーブルに各々対応している。
またドライバは、図2に示すように、入力されたI/O要求を保持するためのキューを個々のパス毎に設けており、リンク管理部から入力されたI/O要求をリンク管理部から指定されたパスに対応するキューに一旦投入すると共に、個々のキューに保持されているI/O要求をキューへの投入順に個々のキューから取り出して対応するHBA20へ転送・入力することで、I/O要求の実行順序を制御する。また、ドライバからHBA20へ転送・入力されたI/O要求は、リンク管理部によって先に決定されて指定されたパスを通じてアクセス対象の論理ディスクLUへ転送され、前記I/O要求に応じたディスクアクセス処理(アクセス対象の論理ディスクLUを構成する何れかのディスクドライブに対するデータの読み出し又は書き込み)が行われた後に、同一のパスを通じてI/O要求に対する応答が転送される。
次に、ディスク装置24のうちのアクセス対象の論理ディスクLU、又は、特定のパスの途中に存在する何れかの機器で何らかの障害が発生することで、ドライバがHBA20へ転送・入力した特定のI/O要求に対する応答が遅延した場合(I/O遅延が発生した場合)について説明する。
ドライバは、HBA20へのI/O要求の転送・入力に際し、I/O遅延の発生に備えて予め定められたタイマ値のタイマをスタートさせると共に、リトライカウンタのカウント値を0にリセットする。そして、特定のI/O要求に対する応答を受信する前に、特定のI/O要求に対応するタイマのタイムアウトが発生した場合には、リトライカウンタのカウント値を1だけインクリメントし、特定のI/O要求をHBA20へ再度転送・入力すると共にタイマをスタートさせることを、リトライカウンタのカウント値が予め定められたリトライ回数の最大値に達する迄繰り返す。そして、リトライカウンタのカウント値がリトライ回数の最大値に達しても特定のI/O要求に対する応答を受信しなかった場合は、リンク管理部に対して障害の発生を通知する。
ところで、上記のタイマ値としては例えば30〜40秒、リトライ回数の最大値としては例えば3〜5回程度の値を用いられるが、仮にタイマ値が36秒、リトライ回数の最大値が4回であったとすると、ドライバが最初のI/O要求を送信してからI/O遅延により障害の発生をリンク管理部へ通知する迄の経過時間は36秒×(1+4)=180秒となるので、障害が発生してから、リンク管理部によって障害の発生が認識されて障害対処処理の実行が開始される迄に比較的長い時間が掛かる、という問題がある。
また、ドライバからリンク管理部へ障害の発生が通知される迄の間、発生している障害は障害対処処理が行われることなく放置されるが、障害が発生した箇所が、例えば複数のパスが経由する機器(例えばHBA20やチャネル・アダプタ(CHA)32)等であった場合、障害発生箇所を経由する他のパスでもI/O遅延が各々発生し、I/O遅延によるI/O要求の再送信が各々行われることで、リンク管理部に対して障害の発生が連続的に複数回通知されることになり、障害発生が通知される都度、前述の障害対処処理が繰り返されることでサーバ・コンピュータ12に多大な負荷が加わり、コンピュータ・システム10の動作が不安定になったり、サーバ・コンピュータ12がダウンする等の事態が生じる恐れがある。
一方、本実施形態に係るドライバは、任意のI/O要求に対する応答を受信する前に、前記I/O要求に対応するタイマのタイムアウトが発生することで、I/O遅延が発生した(図3の(1)も参照)ことを検知した場合、メモリ16又は記憶部18の記憶領域に予め設けられたログ情報記録領域に、I/O遅延(タイマのタイムアウト)が発生したことを表すI/O遅延メッセージを記録している(図3の(2)も参照)。このため、本実施形態では上述した課題を解決するために、ログ情報記録領域へのI/O遅延メッセージの記録を利用し、これをトリガとして、同一のチャネル・アダプタ(CHA)32を経由するパスのグループ単位でパスを閉塞する制御を行っている。
すなわち本実施形態では、上記制御を実現するために、サーバ・コンピュータ12の記憶部18にログトラップのプログラムとパス閉塞制御シェルが各々記憶されている。ログトラップ及びパス閉塞制御シェルは、単一のサーバ・コンピュータ12に設けられたHBA20と同数個存在しており、個々のログトラップは互いに異なるHBA20(パスのグループ)に対応し、個々のパス閉塞制御シェルも互いに異なるHBA20(パスのグループ)に対応している。
本実施形態において、I/O遅延の発生を検知した場合にドライバによってログ情報記録領域に記録されるI/O遅延メッセージは、I/O遅延が発生したパスを明示しない代わりに、I/O遅延が発生したパスのグループを明示するメッセージであり、個々のログトラップは、対応するパスのグループにI/O遅延が発生したことを表すI/O遅延メッセージがログ情報記録領域に記録されたか否かを監視している。そして、対応するパスのグループにI/O遅延が発生したことを表すI/O遅延メッセージがログ情報記録領域に記録されたことを検知(図3の(3)も参照)したログトラップは、対応するパスのグループが同一のパス閉塞制御シェルを起動する(図3の(4)も参照)。以下、ログトラップによって起動されたパス閉塞制御シェルによって行われるパス閉塞制御処理について、図4を参照して説明する。
パス閉塞制御処理では、まずステップ50において、対応するパスのグループ(I/O遅延が発生したパスのグループ)に対して予め設定された名称のロックディレクトリが既に作成されているか否かを判定する。本実施形態ではOSとしてUNIX(登録商標)系のOSを用いており、UNIX(登録商標)系のOSでは名称が同一のディレクトリの重複作成が制限(禁止)されている。本実施形態に係るロックディレクトリは、UNIX(登録商標)系のOSにおけるディレクトリの上記特性をパス閉塞制御シェルの排他制御に利用するためのものであり、本実施形態では、ロックディレクトリとして用いるディレクトリの名称がパスのグループ毎に予め設定されており、対応するパスのグループに対して予め設定された名称のロックディレクトリを作成できたパス閉塞制御シェルにのみパス状態管理テーブルの更新権を与えることで、対応するパスのグループが同一のパス閉塞制御シェルが多重に起動された場合(複数のパス閉塞制御処理が並列に実行されている場合)の排他制御を実現している。
なお、パス閉塞制御処理では大半のケースで自シェルを起動したログトラップ(対応するパスのグループが同一のログトラップ)を停止させる処理を行う(詳細は後述)ので、ログトラップを停止させる処理を行った以降は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されることは生じ得ない。但し、例えば同一のグループに属する各パスでI/O遅延がほぼ同時に発生した等のように、ログトラップを停止させる処理が行われる前に、対応するパスのグループが同一のパス閉塞制御シェルが再度起動された場合には上記の重複起動が発生することになる。上記のステップ50は本発明に係る判定手段に対応している。
なお、上記のロックディレクトリは本発明に係るファイル情報に対応している。また、本発明において、OSはUNIX(登録商標)系に限られるものではなく、WINDOWS(登録商標)系のOSにおけるフォルダについても、名称が同一のフォルダの重複作成が制限(禁止)されているので、OSがWINDOWS(登録商標)系である場合は、WINDOWS(登録商標)系のOSにおけるフォルダを本発明に係るファイル情報として適用可能である。また、本発明に係るファイル情報は、同一名称での重複作成が制限されている情報に限られるものではなく、名称以外の他の属性が同一の情報の重複作成が制限されている情報を適用することも可能である。
上記のステップ50の判定が否定された場合、対応するパスのグループが同一のパス閉塞制御シェルは重複起動されていない(対応するパスのグループが同一の他のパス閉塞制御処理は並列に実行されていない)と判断できるのでステップ60へ移行し、対応するパスのグループ(I/O遅延が発生したパスのグループ)に対して予め設定された名称のロックディレクトリの作成を試行する。なお、ステップ60は本発明に係る作成手段に対応している。次のステップ62では、ステップ60でロックディレクトリの作成に成功したか否か判定する。ロックディレクトリの作成に成功した場合はパス状態管理テーブルの更新権を獲得できたと判断できるので、ステップ62の判定が肯定された場合はステップ66へ移行し、ステップ66以降でパス状態管理テーブルを更新する閉塞処理を行う。
すなわち、まずステップ66では対応するパスのグループ(I/O遅延が発生したパスのグループ)の中から処理対象の単一のパスを選択する。次のステップ68ではパス状態管理テーブルを参照し、ステップ66で選択した処理対象のパスに対応する(処理対象のパスによってサーバ・コンピュータ12と接続されている)判定対象の論理ディスクLUについて、当該判定対象の論理ディスクLUをサーバ・コンピュータ12と接続している全てのパスの状態を確認する。そしてステップ70では、該判定対象の論理ディスクLUをサーバ・コンピュータ12と接続している全てのパス(一例として図2には、論理ディスクLU#0をサーバ・コンピュータ12と接続している全てのパスを明示している)のうち、未閉塞のパスの数が2以上か否か判定する。
ステップ70の判定が肯定された場合はステップ72へ移行し、パス状態管理テーブルに登録されている処理対象のパスの状態情報を「稼働中:online」から「非稼働中(閉塞中):offline」へ書き替えることで処理対象のパスを閉塞し、ステップ74へ移行する。また、判定対象の論理ディスクLUをサーバ・コンピュータ12と接続している未閉塞のパスの数が1の場合、すなわち処理対象のパスが判定対象の論理ディスクLUをサーバ・コンピュータ12と接続している未閉塞の最後のパスである場合は、処理対象のパスを閉塞してしまうとサーバ・コンピュータ12が判定対象の論理ディスクLUと通信不能の状態になってしまうので、ステップ70の判定が否定された場合はステップ72の処理を行うことなくステップ74へ移行する。
ステップ74では、対応するパスのグループ(I/O遅延が発生したパスのグループ)の中に未処理のパス(処理対象として未選択のパス)が存在しているか否か判定する。この判定が肯定された場合はステップ66へ戻り、ステップ74の判定が否定される迄ステップ66〜ステップ74を繰り返す。これにより、対応するパスのグループ(I/O遅延が発生したパスのグループ)に属する全てのパスに対してステップ66〜ステップ74の閉塞処理が各々行われる(図3の(5)も参照)。なお、ステップ66〜ステップ74は本発明に係る制御手段(より詳しくは請求項5,6に記載の制御手段)に対応している。
上記の閉塞処理の結果、例えば図5に示すパターン1のように、サーバ・コンピュータ12とディスク装置24の間に設けられた全てのパスが「稼働中:online」の状態で、HBA0系のパスのグループのうちの一部のパスでI/O遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、HBA0系のパスのグループにおける全てのパスの状態情報が「非稼働中(閉塞中):offline」へ書き替えされる。また、例えば図5に示すパターン2のように、HBA0系のパスのグループのうちの一部のパスが「非稼働中(閉塞中):offline」の状態で、HBA0系のパスのグループのうちの他のパスでI/O遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、HBA0系のパスのグループのうち「稼働中:online」のパスの状態情報が「非稼働中(閉塞中):offline」へ書き替えされる。
なお、上記のように一部のパスが「非稼働中(閉塞中):offline」となっている状態は、例えば特定のパスにおける光通信の通信障害や一時的な減衰により、特定のパスが物理的に通信不能な状態となったことがHBAによって検知され、これに基づきドライバによって対応するパスの状態情報が書替えられることによって生ずる。図5に示すパターン1,2では、何れもパス閉塞制御実行後にHBA0系の全てのパスが「非稼働中(閉塞中):offline」となっており、同一グループに属するパスの中に「稼働中:online」のパスと「非稼働中(閉塞中):offline」のパスが混在している交差閉塞状態が生ずることが回避されているので、発生した障害を復旧させる際の作業が簡単になる。
一方、例えば図5に示すパターン3のように、HBA2系のパスのグループのうちの一部のパス(論理ディスクLU#0に対応するパス)が「非稼働中(閉塞中):offline」の状態で、HBA0系のパスのグループのうちの一部のパスでI/O遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、HBA0系のパスのグループのうち論理ディスクLU#0以外の論理ディスクに対応するパスについては状態情報が「非稼働中(閉塞中):offline」へ書き替えされるものの、論理ディスクLU#0に対応するパスについては、当該パスが論理ディスクLU#0をサーバ・コンピュータ12と接続している未閉塞の最後のパスであり、前記パスを閉塞してしまうとサーバ・コンピュータ12が論理ディスクLU#0と通信不能の状態になってしまうことから、前述のステップ70の判定が否定されることで状態情報は「稼働中:online」のまま維持される。この場合は交差閉塞状態が生ずることになるものの、サーバ・コンピュータ12が論理ディスクLU#0と通信不能の状態になってしまうことは回避できる。
なお、上記の閉塞処理で閉塞されたパスは、サーバ・コンピュータ12からディスク装置24へのI/O要求の転送に用いるパスの選択対象から除外されるので、ドライバによってI/O遅延の発生が検知されてI/O遅延メッセージがログ情報記録領域に記録されることはない。このため、同一グループに属する各パスが各々経由する機器等で障害が発生したとしても、図5に示すパターン1,2のように同一グループに属する全パスを閉塞できた場合には、以後は今回の障害が復旧する迄の間、今回I/O遅延が発生したパスのグループに対してパス閉塞制御処理が再度行われることはない。また、閉塞処理で閉塞されたパスについては、閉塞される前に当該パスを用いてI/O要求が送信され、送信したI/O要求に対する応答がタイムアウトしたことで前記パスの閉塞後にI/O遅延の発生が検知されたとしても、前記パスが閉塞されたことに基づきI/O要求の再送信は行われない。従って、同一グループに属する各パスに影響を及ぼす障害が発生した場合にサーバ・コンピュータ12に加わる負荷を軽減できると共に、メモリ等のリソースの消費量も抑制できる。また、上記の閉塞処理はログ情報記録領域へのI/O遅延メッセージの記録、すなわち、ドライバによる1回目のI/O要求の送信がタイムアウトしたことをトリガとして行われるので、ドライバからリンク管理部へ障害の発生が通知されたことをトリガとして閉塞処理を行う場合と比較してより早期に閉塞処理を行うことができる。
対応するパスのグループ(I/O遅延が発生したパスのグループ)に属する全てのパスに対してステップ66〜ステップ74の処理を行うと、ステップ74の判定が否定されてステップ76へ移行し、パス状態管理テーブルを再度参照し、ステップ66〜ステップ74の処理の結果、対応するパスのグループの全てのパスが閉塞されたか否か判定する。上記判定の条件には、例えば図5に示すパターン1,2が該当し、上記判定が肯定された場合はステップ82へ移行する。また、ステップ76の判定が否定された場合はステップ78へ移行し、パス状態管理テーブルを再度参照してディスク装置24の各論理ディスク毎に未閉塞のパスの数を計数する。そして次のステップ80では、ディスク装置24の各論理ディスク毎の未閉塞のパスの数が全て1か否か判定する。ステップ76の判定が否定されてステップ80の判定が肯定される条件には、例えば図5に示すパターン3が該当し、ステップ80の判定が肯定された場合はステップ82へ移行する。
ステップ76又はステップ80の判定が肯定される条件では、今回発生した障害が復旧する迄の間、少なくとも対応するパスのグループ(I/O遅延が発生したパスのグループ)に対しては閉塞処理(状態情報の書き替え)を行う必要は無く、また、例えば図5に示すパターン3におけるHBA0系の論理ディスクLU#0に対応するパスのように、対応するパスのグループの中に未閉塞のパスが存在していたとしても、当該パスを閉塞するとサーバ・コンピュータ12が通信不能の状態になってしまう論理ディスクLUが出現するので、対応するパスのグループに対しては閉塞処理(状態情報の書き替え)を行うことは望ましくない。このため、ステップ82では自処理を起動したログトラップ(対応するパスのグループが同一のログトラップ)の動作を停止させ(図3の(6)、図5に示すパターン1〜3の「ログトラップ」の欄も参照)た後にステップ84へ移行する。
このログトラップの動作停止に伴い、以後は対応するパスのグループにI/O遅延が発生したことを表すI/O遅延メッセージがログ情報記録領域に記録されたとしても、ログトラップによってパス閉塞制御シェルが起動されることはなく、パス閉塞制御処理は行われない。これにより、同一グループに属する各パスが各々経由する機器等で障害が発生したとしても、ログトラップの動作を停止させた以降は、今回の障害が復旧する迄の間、今回I/O遅延が発生したパスのグループに対してパス閉塞制御処理が再度行われることはないので、同一グループに属する各パスに影響を及ぼす障害が発生した場合にサーバ・コンピュータ12に加わる負荷を軽減できると共に、メモリ等のリソースの消費量も抑制できる。なお、ステップ76〜ステップ82は請求項7に記載の起動制御手段に対応しており、特にステップ80は請求項8に記載の起動制御手段に対応している。
一方、ステップ76の判定及びステップ80の判定が各々否定される条件としては、例えば何らかの理由により1つ以上のパスの閉塞に失敗した場合が挙げられる。典型例を図5にパターン4として示す。図5に示すパターン4は、サーバ・コンピュータ12とディスク装置24の間に設けられた全てのパスが「稼働中:online」の状態で、HBA0系のパスのグループのうちの一部のパスでI/O遅延が発生することで、前述したパターン1と同様に、HBA0系のパスのグループにおける全てのパスの状態情報の「非稼働中(閉塞中):offline」への書き替えを行ったものの、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、エラー発生等の理由でHBA0系のパスのグループのうち論理ディスクLU#0に対応するパスの状態情報の書き替えに失敗したパターンである。
上記のパターン4では、HBA0系のパスのグループの中に状態が「稼働中:online」のパス(論理ディスクLU#0に対応するパス)が混在しているのでステップ76の判定が否定され、論理ディスクLU#0は対応するHBA0系及びHBA2系のパスが各々「稼働中:online」で未閉塞のパスの数=2のためステップ80の判定も否定される。このパターン4のように、対応するパスのうち未閉塞のパスの数が2以上の論理ディスクが存在している場合、当該論理ディスクについては、障害の発生に伴って対応するパスを閉塞する余地がある(障害の発生に伴って対応する何れか1つのパスを閉塞してもサーバ・コンピュータ12と通信不能の状態にはならない)ので、ステップ76,80の判定が否定された場合はログトラップの動作を停止させることなく(ステップ82をスキップして)ステップ84へ移行する(図5に示すパターン4の「ログトラップ」の欄も参照)。
そしてステップ84では、先のステップ60で作成したロックディレクトリを削除し、パス閉塞処理を終了する。このロックディレクトリの削除に伴い、自シェルが再度起動されて対応するパスのグループが同一のパス閉塞制御処理が再度行われた場合に、パス状態管理テーブルを更新する閉塞処理を行うことが可能となる。
ところで、パス閉塞制御処理では、上述のようにステップ66〜ステップ74の閉塞処理により、対応するパスのグループの全てのパスの閉塞が試行されると共に、通常は(パスの状態情報の書き替えに失敗した等の稀なケース以外は)ログトラップの動作も停止されるので、同一グループに属する各パスが経由する機器等で障害が発生したとしても、各パスでI/O遅延が発生したことがドライバによって検知されるタイミングに一定時間以上の時間差があれば、I/O遅延が発生したことがドライバによって最初に検知されたパスについてのみ、ログ情報記録領域にI/O遅延メッセージが記録され、ログトラップによってパス閉塞制御シェルの起動されてパス閉塞制御処理が実行されることになる。
しかしながら、同一グループに属する各パスでI/O遅延が発生したことがドライバによってほぼ同時に検知された場合、より詳しくは、I/O遅延の発生が最初に検知されたパスについて、ログ情報記録領域にI/O遅延メッセージが記録されたことをトリガとしてパス閉塞制御処理が行われ、パス状態管理テーブルが更新されてログトラップの実行が停止される前に、同一グループに属する他のパスについてもI/O遅延の発生が検知され、ログ情報記録領域にI/O遅延メッセージが記録された場合には、同一のグループに属する複数のパスについて、ログ情報記録領域へのI/O遅延メッセージの記録をトリガとして、対応するパスのグループが同一の複数のパス閉塞制御処理が重複起動され、対応するパスのグループが同一の複数のパス閉塞制御処理がほぼ同じタイミングで並列に実行されることになる。以下、この場合のパス閉塞制御処理について説明する。
前述のように、パス閉塞制御処理のステップ50ではロックディレクトリが既に作成されているか否かを判定している。先に説明したように、パス閉塞制御処理では処理終了時に、作成したロックディレクトリを削除する(ステップ84)ので、ステップ50の判定が肯定された場合は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が高いものの、稀に、以前に行われたパス閉塞制御処理でロックディレクトリの削除に失敗し、パス閉塞制御処理自体は終了しているもののロックディレクトリが残ってしまっていることもあり、これが原因である可能性も否定できない。
このため、ステップ50の判定が肯定された場合はステップ52へ移行し、既に存在しているロックディレクトリのタイムスタンプ(ロックディレクトリの作成日時)を確認した後に、次のステップ54において、既に存在しているロックディレクトリの作成日時からの経過時間が予め定めた閾値以上か否か判定する。なお、ステップ54の判定における閾値としては、例えばパス閉塞制御処理に要する時間よりも十分に長い時間(例えば1分間)に相当する値を適用することができる。また、ステップ52,54は請求項3に記載の判定手段に対応している。既に存在しているロックディレクトリの作成日時からの経過時間が予め定めた閾値未満の場合は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が非常に高いと判断できるので、上記判定が否定された場合はステップ56へ移行し、「多重起動のため停止」のメッセージを出力してパス閉塞制御処理を終了する。なお、ステップ54の判定が否定された場合に、上記のようにステップ56を経てパス閉塞制御処理を終了することは、請求項4に記載の「プログラムの終了」に対応している。
またステップ54の判定が肯定された場合、既に存在しているロックディレクトリは、以前に行われたパス閉塞制御処理で削除に失敗して残ってしまっているものであり、以前に行われたパス閉塞制御処理自体は終了していると判断できるので、ステップ58へ移行し、既に存在しているロックディレクトリを削除した後にステップ60へ移行し、新たなロックディレクトリの作成を試行する。そしてロックディレクトリの作成に成功した場合には、ステップ62の判定が肯定されてステップ66へ移行し、先に説明した閉塞処理・ログトラップの動作停止が順に行われる。なお、ステップ58は先に説明したステップ84と共に請求項3に記載の制御手段に対応しており、ステップ58で既に存在しているロックディレクトリを削除した後に、ステップ60で新たなロックディレクトリの作成を試行することは、請求項3に記載の作成手段に対応している。
また、同一グループに属する複数のパスの各々におけるI/O遅延の発生が検知されたタイミングの時間差が極めて小さい場合、I/O遅延の発生が最初に検知されたパスに対応するパス閉塞制御処理でロックディレクトリが作成される前に、I/O遅延の発生が2番目以降に検知されたパスに対応するパス閉塞制御処理が行われ、I/O遅延の発生が2番目以降に検知されたパスに対応するパス閉塞制御処理でステップ50の判定が否定されることも確率として0ではない。
しかしながら、ディレクトリの作成はOSを通じて行われるので、複数の処理(プロセス)がOSを通じてディレクトリを同時に作成しようとしたとしても、作成タイミングには必ず時間差が生じると共に、対応するパスのグループが同一のパス閉塞制御シェルによるパス閉塞制御処理ではロックディレクトリとして作成するディレクトリの名称が同一である一方、UNIX(登録商標)系のOSでは名称が同一のディレクトリの重複作成が制限(禁止)されているので、一方のパス閉塞制御処理ではロックディレクトリの作成に必ず失敗する。従って、パス閉塞制御処理においてステップ62の判定が否定された場合、すなわちステップ60で試行したロックディレクトリの作成に失敗した場合には、重複起動されているパス閉塞制御シェルによる別のパス閉塞制御処理でロックディレトリが先に作成されたと判断できるので、ステップ64へ移行し「ディレクトリ作成失敗」のメッセージを出力してパス閉塞制御処理を終了する。なお、ステップ62の判定が否定された場合に、上記のようにステップ64を経てパス閉塞制御処理を終了することは、請求項2に記載の「プログラムの終了」に対応している。
このように、本実施形態に係るパス閉塞制御処理では、ロックディレクトリが既に存在しており、かつ当該ロックディレクトリの作成日時からの経過時間が閾値未満の場合、及び、ロックディレクトリは存在していないと判定したもののロックディレクトリの作成に失敗した場合には、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が非常に高いと判断してパス閉塞制御処理を直ちに終了するので、同一グループに属する各パスでI/O遅延が発生したことがドライバによってほぼ同時に検知され、対応するパスのグループが同一の複数のパス閉塞制御処理がほぼ同じタイミングで並列に実行された場合にも、閉塞処理が重複して実行されることを確実に防止することができ、サーバ・コンピュータ12に加わる負荷を低減できると共に、メモリ等のリソースの消費量を早期に回復させることができる。
従って、本実施形態に係るパス閉塞制御処理によれば、複数のパスに影響を及ぼす障害がコンピュータ・システム10に発生した場合に、各パスでのI/O遅延の発生が検知されたタイミングに拘わらず、サーバ・コンピュータ12に加わる負荷を低減し、メモリ等のリソースの消費量を抑制することができるので、複数のパスに影響を及ぼす障害がコンピュータ・システム10に発生した場合のサーバ・コンピュータ12の動作安定化を実現することができる。
なお、上記で説明したパス閉塞制御処理では、対応するパスのグループに対して閉塞処理を行った後、ディスク装置24の各論理ディスク毎の未閉塞のパスの数が全て1の場合(ステップ80の判定が肯定された場合)に、対応するパスのグループが同一のログトラップの動作を停止させていたが、これに限定されるものではない。上記処理では、対応するパスのグループが異なるログトラップは動作が継続され、対応するパスのグループと異なるグループに属するパスでI/O遅延が発生した場合はパス閉塞制御シェルが起動されることになるが、各論理ディスク毎の未閉塞のパスの数が全て1であれば、パスの全てのグループに対して閉塞処理は不要であり、また閉塞処理を行うことは望ましくもないので、各論理ディスク毎の未閉塞のパスの数が全て1の場合には、パスの全てのグループに対してログトラップの動作を停止させるようにしてもよい。本願の請求項8記載の発明は上記態様も権利範囲に含んでいる。
また、上記ではログトラップ及びパス閉塞制御シェルをパスのグループ毎に設けた態様を説明したが、本発明はこれに限定されるものではなく、ログトラップ及びパス閉塞制御シェルを1つづつ設け、ログトラップは、ログ情報記録領域へのI/O遅延メッセージの記録をトリガとして、記録されたI/O遅延メッセージに対応するパスのグループを判定し、判定したグループを引数としてパス閉塞制御シェルを起動し、起動されたパス閉塞制御シェルは、通知されたグループが閉塞処理停止中か否かを判定し、閉塞処理停止中でなければ通知されたグループに対応する名称のロックディレクトリの存在確認、同名称のロックディレクトリの作成試行、通知されたグループの各パスに対する閉塞処理、通知されたグループが閉塞処理停止中であることを表す情報の設定・記憶、の各処理を行うように構成してもよい。
また、上記では本発明に係る外部機器の一例として、ディスク駆動装置(DKU)26によって駆動される多数台のディスクドライブを備えたディスク装置24を説明したが、本発明に係る外部機器は上記構成に限定されるものではなく、例えばフラッシュメモリ等の半導体メモリから成る記憶装置であってもよいし、本発明に係るコンピュータ以外の相手装置と通信を行う通信装置であってもよく、任意の機器を適用可能である。
更に、外部機器(論理ディスクLU)の数やパスのグループの数(HBA20、チャネル・アダプタ(CHA)32の数)、コンピュータ(サーバ・コンピュータ12)の数等は、図面に示した数に限られるものではなく、本発明を逸脱しない範囲で適宜変更可能である。
また、上記では本発明に係る障害管理プログラムに対応するパス閉塞制御シェルがサーバ・コンピュータ12の記憶部18に予め記憶(インストール)されている態様を説明したが、本発明に係る障害管理プログラムは、CD−ROMやDVD−ROM等の記録媒体に記録されている形態で提供することも可能である。