JP2011238290A - 障害管理装置及びプログラム - Google Patents

Abstract

【課題】複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現する。
【解決手段】ディスク装置24に設けられた複数の論理ディスクLUの各々と複数のパスを介して通信可能とされたサーバ12において、(1)或るパスでI/O遅延が発生し、(2)ログにメッセージが記録され、(3)これがログトラップによって検知されると、(4)パス閉塞制御シェルが起動される。このシェルは、同一のＨＢＡを経由する複数のパスから成るパスのグループに対し、対応するロックディレクトリの有無を確認し、無ければ対応するロックディレクトリの作成を試行し、作成に成功した場合には、(5)管理テーブル上で前記グループの全パスを閉塞し、(6)ログトラップの動作を停止させる。
【選択図】図３

Description

本発明は障害管理装置及びプログラムに係り、特に、コンピュータが外部機器と通信するためのパスが複数の外部機器の各々毎に複数設けられた構成において、各パスの障害を管理する障害管理装置、及び、コンピュータを前記障害管理装置として機能させるための障害管理プログラムに関する。

コンピュータと記憶装置を含み、外部からの要求に従って記憶装置へのアクセス（記憶装置に記憶されているデータの読み出しや記憶装置へのデータの書き込み等）を行い、要求元へ応答を返す処理を行うシステムにおいて、障害発生等の際にも稼働状態の継続が求められている場合は、記憶装置自体を多重化すると共に、コンピュータが記憶装置と通信するための通信経路(パス)も多重化する等の冗長構成が採用されることが多い。

上記の冗長構成に適用可能な技術として、例えば特許文献１には、ホスト計算機と、物理ディスク及びディスクコントローラを備えたストレージシステムと、を備える計算機システムにおいて、ストレージシステムは、物理ディスクの記憶領域を、一つ以上の論理ユニットとしてホスト計算機に提供し、ホスト計算機は、当該ホスト計算機から論理ユニットへのアクセス経路である論理パスの障害を検知すると、障害が検知された論理パスと同じ論理ユニットにアクセスするための論理パスを特定し、特定された論理パスに対して障害検知処理を実行することで、特定された論理パスが正常であるか否かを判定し、特定されたパスの中から正常な論理パスを選択し、選択された正常な論理パスを用いて論理ユニットにアクセスする技術が開示されている。

また、上記に関連して特許文献２には、分散コンピュータ・システムにおいて、マスタ・プロセスは、共有リソース制御ファイルを新しいタイムスタンプ時間で周期的に更新し、共有リソースへアクセスを求めるプロセスは、共有リソース制御ファイルを読み取って他のプロセスがマスタとして指定されているか否か判定し、最後のタイムスタンプ時間からの経過時間が予め設定されている時間よりも長ければ、その共有リソース制御ファイルを無効にして新しい共有リソース制御ファイルを作成することで、共有リソースを制御するマスタ・プロセスを効率よく決定する技術が開示されている。

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

前述の冗長構成において、例えばコンピュータから記憶装置に至るパスの途中に存在する機器で障害が発生すると、当該機器を経由する複数のパスで障害の発生が各々検知される等のように、冗長構成では障害発生時に障害の発生が連続的に複数回通知されることが多い。このため、障害発生が通知されたことをトリガとして、障害の発生が通知されたパスを閉塞する等の障害対処処理を行う場合、この障害対処処理が頻繁に繰り返されることでコンピュータに多大な負荷が加わり、コンピュータ・システムの動作が不安定になったり、コンピュータがダウンする等の事態も生じ得る。

上記の問題に対しては、障害発生が通知されたことをトリガとして行われる障害対処処理に、特許文献２に記載の排他制御を適用することが考えられる。しかしながら、障害対処処理の実行に特許文献２に記載の技術を適用した場合、障害対処処理を行うプロセスが障害発生が通知される度に生成されると共に、生成されたプロセスは、マスタ権を獲得する迄マスタ権の獲得を繰り返し試行することになる。このため、パスの途中に存在する機器で障害が発生した等のように多数のパスに影響を及ぼす障害が発生し、多数のパスの障害発生が連続的に通知された場合、多数のプロセスが生成されることでコンピュータに多大な負荷が加わると共に、メモリ等のリソースが大量に消費されるので、コンピュータの動作の安定化に有効ではない。

本発明は上記事実を考慮して成されたもので、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現できる障害管理装置及び障害管理プログラムを得ることが目的である。

上記目的を達成するために請求項１記載の発明に係る障害管理装置は、外部機器と通信するための複数のパスから成るグループが設けられたコンピュータによって実現される障害管理装置であって、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段と、前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段と、前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段と、を備えている。

請求項１記載の発明に係る障害管理装置は、外部機器と通信するための複数のパスから成るグループが設けられたコンピュータによって実現される。なお、本発明に係る外部機器としては、例えば、情報を記憶可能でかつ記憶している情報を書替可能な記憶装置が好適であるが、他の機器であってもよい。また、本発明におけるグループは、例えば図２に「パスのグループ」と表記して示すように、物理的な通信経路を共有する複数のパスで構成することができる。請求項１記載の発明では、何れかのパスでの障害の発生が通知される毎に、判定手段により、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かが判定される。なお、同一属性での重複作成が制限されているファイル情報としては、例えば同一名称での重複作成が制限されているファイル情報、具体的にはＵＮＩＸ（登録商標）系のオペレーティング・システムにおけるディレクトリや、ＷＩＮＤＯＷＳ（登録商標）系のオペレーティング・システムにおけるフォルダを適用することができる。また、判定手段によって所定の属性のファイル情報が作成されていないと判定された場合は、作成手段により所定の属性のファイル情報の作成が試行され、作成手段による所定の属性のファイル情報の作成が成功した場合には、制御手段により、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われる。

このように、請求項１記載の発明では、同一グループに属するパスは障害発生時に同様の影響を受けることが多く、障害の発生が各々通知されることが多いことに基づき、閉塞処理として、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための処理を行うので、同一グループに属する各パスが各々影響を受ける障害が発生したとしても、各パスのうちの何れか１つのパスでの障害の発生が通知されたことに基づいて閉塞処理を一旦行った以降は、当該閉塞処理によって閉塞された各パスでの障害発生が通知されることが無くなり、複数のパスに影響を及ぼす障害が発生した場合にコンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。

また、或るパスで障害が発生した場合、その原因は障害が発生したパス上のハードウェア(例えばＨＢＡ(Host Bus Adapter)やケーブル等)の不調や故障等であることが多く、当該ハードウェアを被疑部位として稼働中の部位より切り離し、必要に応じて交換する保守作業(発生した障害を復旧させるための作業)が行われるが、この保守作業の実施に際し、被疑部位としてのハードウェアを経由する別のパスが存在している場合には、当該別のパスで障害が発生しているか否かに拘わらず、被疑部位としてのハードウェアの切り離しを行うために、前記別のパスが通信に使用されないように前記別のパスも閉塞する必要がある。請求項１記載の発明では、何れかのパスでの障害の発生が通知されると、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われるので、保守作業の実施に際し、障害が発生したパスと同一のグループに属する他の全てのパスを改めて閉塞する必要が無くなり、保守作業を行う作業者の負担を軽減することができる。

また、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合に、個々の通知に対応する処理が各々行われることになるが、本発明では、１回の閉塞処理により、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するので、閉塞処理の実行回数はパスのグループ毎に１回でよい。このため請求項１記載の発明では、障害の発生が通知されたパスが属するグループに対応する所定の属性のファイル情報が作成されておらず、所定の属性のファイル情報の作成が成功した場合に閉塞処理を行っている。

これにより、障害の発生が最も早く通知された特定のパスに対応する処理では、ファイル情報の作成が成功することで閉塞処理が行われる一方、前記特定のパスよりも後に障害の発生が通知された残りのパスに対応する処理では、所定の属性のファイル情報が既に作成されているか否かの判定のタイミングが、前記特定のパスに対応する処理における所定の属性のファイル情報の作成後であれば、所定の属性のファイル情報が既に作成されていると判定され、所定の属性のファイル情報が既に作成されているか否かの判定のタイミングが、特定のパスに対応する処理における所定の属性のファイル情報の作成前であったとしても、同一属性のファイル情報の重複作成が制限されているためにファイル情報の作成には失敗することで、閉塞処理は行われない。

このように、請求項１記載の発明では、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合にも、閉塞処理が重複して実行されることを確実に防止することができ、コンピュータに加わる負荷を低減することができる。従って、請求項１記載の発明によれば、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現することができる。

なお、請求項１記載の発明において、例えば請求項２に記載したように、判定手段、作成手段及び制御手段は、前記グループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、コンピュータによるプログラムの実行は、作成手段による所定の属性のファイル情報の作成が失敗した場合に終了されるように構成することが好ましい。これにより、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生がほぼ同時に通知された場合にも、個々の通知に対応する処理のうちファイル情報の作成に失敗した処理については、コンピュータによる実行が終了されることになり、当該処理の実行を終了させない場合と比較して、コンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。

また、請求項１又は請求項２記載の発明において、例えば請求項３に記載したように、判定手段は、所定の属性のファイル情報が既に作成されていると判定した場合に、当該ファイル情報が作成されてからの経過時間が閾値以上か否かを判定し、制御手段は、閉塞処理の終了後に、作成手段によって作成された所定の属性のファイル情報を削除すると共に、判定手段により、所定の属性のファイル情報が既に作成されており、当該ファイル情報が作成されてからの経過時間が閾値以上と判定された場合に、既に作成されているファイル情報を削除し、作成手段は、判定手段によって前記経過時間が閾値以上と判定された場合に、既に作成されているファイル情報が制御手段によって削除された後に、所定の属性のファイル情報の作成を試行するように構成することが好ましい。

請求項３記載の発明における閾値としては、判定手段、作成手段及び制御手段による一連の処理に要する時間よりも所定値以上長く、前回に発生が通知された障害とは異なる障害であると判断できる程度の時間(例えば１分間程度)に相当する値が好適である。請求項３記載の発明では、閉塞処理の終了後に、作成手段によって作成されたファイル情報が制御手段によって削除されるが、判定手段により、所定の属性のファイル情報が既に作成されており、当該ファイル情報が作成されてからの経過時間が閾値以上と判定された場合、当該ファイル情報は、何らかの理由で制御手段による削除が失敗し、残ってしまったファイル情報である可能性が高い。請求項３記載の発明では、このようなファイル情報も制御手段によって削除され、その後、作成手段によってファイル情報の作成が試行されるので、制御手段によるファイル情報の削除が失敗した場合にも、削除されずに残っているファイル情報が作成されてから閾値以上の時間の経過に伴い、作成手段が同一属性のファイル情報を再度作成することが可能で、制御手段が閉塞処理を行うことが可能な状態に復帰させることができる。

また、請求項３記載の発明において、例えば請求項４に記載したように、判定手段、作成手段及び制御手段は、前記グループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、コンピュータによる前記プログラムの実行は、判定手段によって所定の属性のファイル情報が作成されており、かつ前記経過時間が閾値未満と判定された場合に終了されるように構成することが好ましい。これにより、複数のパスに影響を及ぼす障害が発生し、同一のグループに属する互いに異なるパスでの障害の発生が閾値未満の時間間隔で各々通知された場合にも、各パスに対応する処理のうち障害の発生が２番目以降に通知されたパスに対応する処理については、コンピュータによる実行が終了されることになり、当該処理の実行を終了させない場合と比較して、コンピュータに加わる負荷を低減できると共に、メモリ等のリソースの消費量も抑制することができる。

請求項５記載の発明に係る障害管理プログラムは、外部機器と通信するための複数のパスから成るグループが設けられたコンピュータを、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段、前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段、及び、前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段として機能させる。

請求項５記載の発明に係る障害管理プログラムは、上記コンピュータを、上記の判定手段、作成手段及び制御手段として機能させるためのプログラムであるので、コンピュータが請求項５記載の発明に係る障害管理プログラムを実行することで、コンピュータが請求項１に記載の障害管理装置として機能することになり、請求項１記載の発明と同様に、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現することができる。

なお、上記の発明において、複数の外部機器のうちの互いに異なる前記外部機器と通信するための複数のパスから成るグループが複数設けられていてもよい(第１の態様)。請求項１記載の発明によれば、何れかのパスでの障害の発生が通知されると、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理が行われるので、上記の第１の態様において、コンピュータと接続する複数のパス(互いに異なるグループに属する複数のパス：一例として図２には、論理ディスクＬＵ#0をサーバ・コンピュータ１２と接続している全てのパスを明示している)のうちの一部のパスが閉塞され、かつ、閉塞されているパスが属するグループが相違する外部機器が複数存在している状態(本明細書ではこの状態を交差閉塞状態という)が生ずることを極力回避することができる。上記の交差閉塞状態が生じた場合、保守作業の実施に際し、障害が発生したパスと同一のグループに属する他の全てのパスを閉塞しようとすると、コンピュータと接続する複数のパスが全て閉塞されることで通信不能となってしまう外部機器が出現するので、保守作業の実施が困難になるが、請求項１記載の発明では、このような状況に陥ってしまうことを極力回避することができ、保守作業を実施できる確率を向上させることができる。

また、請求項１〜請求項４の何れかに記載の発明に第１の態様を適用した構成において、個々のグループの個々のパスの各々の状態を表す状態情報を状態テーブルに登録・管理し、コンピュータと個々の外部機器との通信に用いるパスを選択すると共に、状態情報として閉塞を意味する情報が状態テーブルに登録されているパスを、外部機器との通信における選択対象から除外する処理を含む管理処理を行う管理手段が設けられている場合、制御手段は、例えば、閉塞処理として、状態テーブルに登録されている状態情報のうち、障害の発生が通知されたパスと同一のグループに属する全てのパスの状態情報を、閉塞を意味する情報に各々書き替える処理を行うように構成することができる(第２の態様)。これにより、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞することを、簡易な処理によって実現することができる。

また、上記の第２の態様において、制御手段は、例えば、閉塞処理を行う前に状態テーブルを参照し、障害の発生が通知されたパスと同一のグループに属する全てのパスのうちの特定のパスが、当該特定のパスと同一の外部機器に対応する複数のパスのうちの未閉塞の最後のパスか否かを確認し、特定のパスが前記最後のパスであった場合は、状態テーブルに登録されている特定のパスに対応する状態情報の書き替えを中止することを、障害の発生が通知されたパスと同一のグループに属する全てのパスについて各々行うように構成することが好ましい(第３の態様)。これにより、閉塞処理の実行に伴ってコンピュータと通信するためのパスが全て閉塞された外部機器が出現することを防止することができ、閉塞処理の実行に拘わらず、コンピュータが１つ以上の未閉塞のパスを経由して個々の外部機器と通信可能な状態を維持することができる。

また、請求項１〜請求項４の何れかに記載の発明に第１〜第３の態様の何れかを適用した構成において、例えば、判定手段、作成手段及び制御手段は、何れかのグループの何れかのパスで障害の発生が通知される毎に起動されてコンピュータによって実行される単一のプログラムによって実現され、制御手段による閉塞処理により、状態テーブルに登録されている状態情報のうち、障害の発生が通知されたパスと同一のグループに属する全てのパスの状態情報が閉塞を意味する情報に各々書き替えられた場合に、障害の発生が通知された際の前記プログラムの起動を停止させる起動制御手段が設けられていることが好ましい(第４の態様)。これにより、障害の発生が通知されたパスと同一のグループに属する全てのパスが閉塞されている状態、すなわち前記全てのパスが閉塞処理が不要な状態であるにも拘わらず、前記プログラムが無駄に起動されることを防止することができ、コンピュータに加わる負荷の更なる低減及びメモリ等のリソースの消費量の更なる抑制を実現することができる。

また、上記の第４の態様において、起動制御手段は、例えば、制御手段によって閉塞処理が行われた結果、複数の外部機器の各々が、対応する複数のパスのうち未閉塞のパスの数が残り１つの状態となった場合にも、障害の発生が通知された際の前記プログラムの起動を停止させるように構成することが好ましい(第５の態様)。これにより、個々の外部機器に対応する未閉塞のパスの数が各々残り１つの状態、すなわち閉塞処理を行って閉塞状態のパスを増加させることが望ましくない状態であるにも拘わらず、前記プログラムが無駄に起動されることを防止することができ、コンピュータに加わる負荷の更なる低減及びメモリ等のリソースの消費量の更なる抑制を実現することができる。

以上説明したように本発明は、何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定し、所定の属性のファイル情報が作成されていない場合に、所定の属性のファイル情報の作成を試行し、所定の属性のファイル情報の作成が成功した場合に、障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行うようにしたので、複数のパスに影響を及ぼす障害が発生した場合のコンピュータの動作安定化を実現できる、という優れた効果を有する。

本実施形態に係るコンピュータ・システムの概略構成図である。 稼働時のディスク装置へのアクセスを説明するための概略図である。 Ｉ／Ｏ遅延発生時の処理の流れを示す概略図である。 パス閉塞制御処理の内容を示すフローチャートである。 パス閉塞制御処理の結果を各パターン毎に示す図表である。

以下、図面を参照して本発明の実施形態の一例を詳細に説明する。図１には本実施形態に係るコンピュータ・システム１０が示されている。コンピュータ・システム１０は、複数台のサーバ・コンピュータ１２(図１では２台のサーバ・コンピュータ１２Ａ，１２Ｂのみ図示している)と、論理ディスクＬＵが複数設けられ光ファイバケーブル２２を介して個々のサーバ・コンピュータ１２と各々接続されたディスク装置２４を備えており、ＤＢ(データベース)サーバとして機能する。なお、個々のサーバ・コンピュータ１２は本発明に係るコンピュータに、ディスク装置２４に設けられた個々の論理ディスクＬＵは本発明に係る外部機器に対応している。

個々のサーバ・コンピュータ１２は、ＣＰＵ１４、メモリ１６、ディスク駆動装置(ＤＫＵ)によって駆動されるディスクドライブ等から成る不揮発性の記憶部１８、サーバ・コンピュータ１２を光ファイバ経由でディスク装置２４と接続するための複数のＨＢＡ(Host Bus Adapter)２０(図１では２個のＨＢＡ(ＨＢＡ＃０,ＨＢＡ＃２)のみ示している)を含んで構成されている。個々のサーバ・コンピュータ１２の記憶部１８には、ディスク装置２４(詳しくはディスク装置２４の複数の論理ディスクのうちの何れかの論理ディスク)へのＩ／Ｏ(Input/Output：入出力)要求を出力するアプリケーション・プログラム、アプリケーションからのＩ／Ｏ要求に応答してハードウェアの制御等を行うオペレーティング・システム(ＯＳ)のプログラム、リンク管理部のプログラム、ドライバのプログラム、パス閉塞制御シェル(プログラム)及びログトラップのプログラムが各々記憶されている。なお、リンク管理部、ドライバ、パス閉塞制御シェル及びログトラップについては後述する。

記憶部１８に記憶されている各プログラムは、サーバ・コンピュータ１２の稼働開始時に記憶部１８から読み出されてメモリ１６に各々記憶され、必要時にＣＰＵ１４によって実行される。なお、記憶部１８に記憶されている各プログラムのうち、パス閉塞制御シェルは本発明に係る障害管理プログラムに対応しており(請求項２,４に記載の「単一のプログラム」にも対応している)、サーバ・コンピュータ１２は、ＣＰＵ１４がパス閉塞制御シェルを実行することで本発明に係る障害管理装置として機能する。

一方、ディスク装置２４は、ディスク駆動装置(ＤＫＵ)２６によって駆動される多数台のディスクドライブを備えている。多数台のディスクドライブは、各々冗長化された複数の論理ディスクＬＵを形成するように互いに接続されている(図１では、ディスク装置２４に設けられた論理ディスクの一部(ＬＵ#0〜ＬＵ#3,ＬＵ#m〜ＬＵ#m+3,ＬＵ#n〜ＬＵ#n+3)のみ示されている)。また、ディスク装置２４にはディスク制御装置(ＤＫＣ)２８が設けられている。ディスク制御装置(ＤＫＣ)２８には複数(図１では２個)のクラスタ３０が設けられており、個々のクラスタ３０には、複数(図１では２個)のチャネル・アダプタ(ＣＨＡ)３２、複数(図１では２個)のディスク・アダプタ(ＤＫＡ)３４、チャネル・アダプタ(ＣＨＡ)３２とディスク・アダプタ(ＤＫＡ)３４を接続するキャッシュ・スイッチ(ＣＳＷ)３６が設けられている。

個々の論理ディスクＬＵは個々のクラスタ３０の何れか１つののディスク・アダプタ(ＤＫＡ)３４に各々接続されている。また、同一のクラスタ３０に設けられた複数のチャネル・アダプタ(ＣＨＡ)３２は、互いに異なるサーバ・コンピュータ１２のＨＢＡ２０と光ファイバケーブル２２を介して各々接続されており、チャネル・アダプタ(ＣＨＡ)３２は、サーバ・コンピュータ１２から光ファイバケーブル２２経由でＩ／Ｏ要求を受信すると、キャッシュ・スイッチ(ＣＳＷ)３６を介し、受信したＩ／Ｏ要求におけるアクセス対象の論理ディスクＬＵが接続されたディスク・アダプタ(ＤＫＡ)３４へＩ／Ｏ要求を転送する。

次に本実施形態の作用として、まず、コンピュータ・システム１０がＤＢサーバとして稼働しており、ディスク装置２４等に障害が発生していない状態で、サーバ・コンピュータ１２のＣＰＵ１４によって各プログラムが実行されることで実現される処理について、図２を参照して説明する。

本実施形態では、個々のサーバ・コンピュータ１２にＨＢＡ２０が複数設けられており、個々のＨＢＡ２０は光ファイバケーブル２２を介してディスク装置２４(の互いに異なるクラスタ３０のチャネル・アダプタ(ＣＨＡ)３２)に各々接続されているので、図２に破線で示すように、個々のサーバ・コンピュータ１２は、ディスク装置２４の個々の論理ディスクＬＵと複数のパス(互いに異なるチャネル・アダプタ(ＣＨＡ)３２を経由する複数のパス)を介して通信可能とされており、個々の論理ディスクＬＵと通信を行うためのパスが冗長化(多重化)されている。なお、単一のサーバ・コンピュータ１２とディスク装置２４との間に設けられた複数のパスは、同一のチャネル・アダプタ(ＣＨＡ)３２を経由するパス(物理的な通信経路を共有するパス)を単位としてグループ化されている(図２に示す「パスのグループ」も参照)。

前述のアプリケーションから出力されるディスク装置２４へのＩ／Ｏ要求では、アクセス対象の論理ディスクＬＵが指定される。このＩ／Ｏ要求はＯＳを経由し、リンク管理部のプログラムがサーバ・コンピュータ１２のＣＰＵ１４によって実行されることで実現されるリンク管理部に転送・入力される。リンク管理部は、個々のパスへの負荷を把握し、入力されたＩ／Ｏ要求をアクセス対象の論理ディスクＬＵへ転送するためのパスを個々のパスへの負荷が分散するように選択し、ドライバのプログラムがサーバ・コンピュータ１２のＣＰＵ１４によって実行されることで実現されるドライバに対し、前記選択したパスを指定して前記Ｉ／Ｏ要求を転送・入力することで、前記Ｉ／Ｏ要求が前記選択したパスを通じて転送されるように制御する。また、リンク管理部は個々のパス毎にその状態が稼働中(Online)か非稼働中(閉塞中／Offline)かを表す状態情報を登録するためのパス状態管理テーブルを保持しており、Ｉ／Ｏ要求の転送に用いるパスの選択に際しては、パス状態管理テーブルに登録されている状態情報が「非稼働中(閉塞中):offline」のパスが選択対象から除外される。

またドライバは、図２に示すように、入力されたＩ／Ｏ要求を保持するためのキューを個々のパス毎に設けており、リンク管理部から入力されたＩ／Ｏ要求をリンク管理部から指定されたパスに対応するキューに一旦投入すると共に、個々のキューに保持されているＩ／Ｏ要求をキューへの投入順に個々のキューから取り出して対応するＨＢＡ２０へ転送・入力することで、Ｉ／Ｏ要求の実行順序を制御する。また、ドライバからＨＢＡ２０へ転送・入力されたＩ／Ｏ要求は、リンク管理部によって先に決定されて指定されたパスを通じてアクセス対象の論理ディスクＬＵへ転送され、前記Ｉ／Ｏ要求に応じたディスクアクセス処理(アクセス対象の論理ディスクＬＵを構成する何れかのディスクドライブに対するデータの読み出し又は書き込み)が行われた後に、同一のパスを通じてＩ／Ｏ要求に対する応答が転送される。

次に、ディスク装置２４のうちのアクセス対象の論理ディスクＬＵ、又は、特定のパスの途中に存在する何れかの機器で何らかの障害が発生することで、ドライバがＨＢＡ２０へ転送・入力した特定のＩ／Ｏ要求に対する応答が遅延した場合(Ｉ／Ｏ遅延が発生した場合)について説明する。

ドライバは、ＨＢＡ２０へのＩ／Ｏ要求の転送・入力に際し、Ｉ／Ｏ遅延の発生に備えて予め定められたタイマ値のタイマをスタートさせると共に、リトライカウンタのカウント値を０にリセットする。そして、特定のＩ／Ｏ要求に対する応答を受信する前に、特定のＩ／Ｏ要求に対応するタイマのタイムアウトが発生した場合には、リトライカウンタのカウント値を１だけインクリメントし、特定のＩ／Ｏ要求をＨＢＡ２０へ再度転送・入力すると共にタイマをスタートさせることを、リトライカウンタのカウント値が予め定められたリトライ回数の最大値に達する迄繰り返す。そして、リトライカウンタのカウント値がリトライ回数の最大値に達しても特定のＩ／Ｏ要求に対する応答を受信しなかった場合は、リンク管理部に対して障害の発生を通知する。

ところで、上記のタイマ値としては例えば３０〜４０秒、リトライ回数の最大値としては例えば３〜５回程度の値を用いられるが、仮にタイマ値が３６秒、リトライ回数の最大値が４回であったとすると、ドライバが最初のＩ／Ｏ要求を送信してからＩ／Ｏ遅延により障害の発生をリンク管理部へ通知する迄の経過時間は３６秒×(１＋４)＝１８０秒となるので、障害が発生してから、リンク管理部によって障害の発生が認識されて障害対処処理の実行が開始される迄に比較的長い時間が掛かる、という問題がある。

また、ドライバからリンク管理部へ障害の発生が通知される迄の間、発生している障害は障害対処処理が行われることなく放置されるが、障害が発生した箇所が、例えば複数のパスが経由する機器(例えばＨＢＡ２０やチャネル・アダプタ(ＣＨＡ)３２)等であった場合、障害発生箇所を経由する他のパスでもＩ／Ｏ遅延が各々発生し、Ｉ／Ｏ遅延によるＩ／Ｏ要求の再送信が各々行われることで、リンク管理部に対して障害の発生が連続的に複数回通知されることになり、障害発生が通知される都度、前述の障害対処処理が繰り返されることでサーバ・コンピュータ１２に多大な負荷が加わり、コンピュータ・システム１０の動作が不安定になったり、サーバ・コンピュータ１２がダウンする等の事態が生じる恐れがある。

一方、本実施形態に係るドライバは、任意のＩ／Ｏ要求に対する応答を受信する前に、前記Ｉ／Ｏ要求に対応するタイマのタイムアウトが発生することで、Ｉ／Ｏ遅延が発生した(図３の(1)も参照)ことを検知した場合、メモリ１６又は記憶部１８の記憶領域に予め設けられたログ情報記録領域に、Ｉ／Ｏ遅延(タイマのタイムアウト)が発生したことを表すＩ／Ｏ遅延メッセージを記録している(図３の(2)も参照)。このため、本実施形態では上述した課題を解決するために、ログ情報記録領域へのＩ／Ｏ遅延メッセージの記録を利用し、これをトリガとして、同一のチャネル・アダプタ(ＣＨＡ)３２を経由するパスのグループ単位でパスを閉塞する制御を行っている。

すなわち本実施形態では、上記制御を実現するために、サーバ・コンピュータ１２の記憶部１８にログトラップのプログラムとパス閉塞制御シェルが各々記憶されている。ログトラップ及びパス閉塞制御シェルは、単一のサーバ・コンピュータ１２に設けられたＨＢＡ２０と同数個存在しており、個々のログトラップは互いに異なるＨＢＡ２０(パスのグループ)に対応し、個々のパス閉塞制御シェルも互いに異なるＨＢＡ２０(パスのグループ)に対応している。

本実施形態において、Ｉ／Ｏ遅延の発生を検知した場合にドライバによってログ情報記録領域に記録されるＩ／Ｏ遅延メッセージは、Ｉ／Ｏ遅延が発生したパスを明示しない代わりに、Ｉ／Ｏ遅延が発生したパスのグループを明示するメッセージであり、個々のログトラップは、対応するパスのグループにＩ／Ｏ遅延が発生したことを表すＩ／Ｏ遅延メッセージがログ情報記録領域に記録されたか否かを監視している。そして、対応するパスのグループにＩ／Ｏ遅延が発生したことを表すＩ／Ｏ遅延メッセージがログ情報記録領域に記録されたことを検知(図３の(3)も参照)したログトラップは、対応するパスのグループが同一のパス閉塞制御シェルを起動する(図３の(4)も参照)。以下、ログトラップによって起動されたパス閉塞制御シェルによって行われるパス閉塞制御処理について、図４を参照して説明する。

パス閉塞制御処理では、まずステップ５０において、対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)に対して予め設定された名称のロックディレクトリが既に作成されているか否かを判定する。本実施形態ではＯＳとしてＵＮＩＸ（登録商標）系のＯＳを用いており、ＵＮＩＸ（登録商標）系のＯＳでは名称が同一のディレクトリの重複作成が制限(禁止)されている。本実施形態に係るロックディレクトリは、ＵＮＩＸ（登録商標）系のＯＳにおけるディレクトリの上記特性をパス閉塞制御シェルの排他制御に利用するためのものであり、本実施形態では、ロックディレクトリとして用いるディレクトリの名称がパスのグループ毎に予め設定されており、対応するパスのグループに対して予め設定された名称のロックディレクトリを作成できたパス閉塞制御シェルにのみパス状態管理テーブルの更新権を与えることで、対応するパスのグループが同一のパス閉塞制御シェルが多重に起動された場合(複数のパス閉塞制御処理が並列に実行されている場合)の排他制御を実現している。

なお、パス閉塞制御処理では大半のケースで自シェルを起動したログトラップ(対応するパスのグループが同一のログトラップ)を停止させる処理を行う(詳細は後述)ので、ログトラップを停止させる処理を行った以降は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されることは生じ得ない。但し、例えば同一のグループに属する各パスでＩ／Ｏ遅延がほぼ同時に発生した等のように、ログトラップを停止させる処理が行われる前に、対応するパスのグループが同一のパス閉塞制御シェルが再度起動された場合には上記の重複起動が発生することになる。上記のステップ５０は本発明に係る判定手段に対応している。

なお、上記のロックディレクトリは本発明に係るファイル情報に対応している。また、本発明において、ＯＳはＵＮＩＸ（登録商標）系に限られるものではなく、ＷＩＮＤＯＷＳ（登録商標）系のＯＳにおけるフォルダについても、名称が同一のフォルダの重複作成が制限(禁止)されているので、ＯＳがＷＩＮＤＯＷＳ（登録商標）系である場合は、ＷＩＮＤＯＷＳ（登録商標）系のＯＳにおけるフォルダを本発明に係るファイル情報として適用可能である。また、本発明に係るファイル情報は、同一名称での重複作成が制限されている情報に限られるものではなく、名称以外の他の属性が同一の情報の重複作成が制限されている情報を適用することも可能である。

上記のステップ５０の判定が否定された場合、対応するパスのグループが同一のパス閉塞制御シェルは重複起動されていない(対応するパスのグループが同一の他のパス閉塞制御処理は並列に実行されていない)と判断できるのでステップ６０へ移行し、対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)に対して予め設定された名称のロックディレクトリの作成を試行する。なお、ステップ６０は本発明に係る作成手段に対応している。次のステップ６２では、ステップ６０でロックディレクトリの作成に成功したか否か判定する。ロックディレクトリの作成に成功した場合はパス状態管理テーブルの更新権を獲得できたと判断できるので、ステップ６２の判定が肯定された場合はステップ６６へ移行し、ステップ６６以降でパス状態管理テーブルを更新する閉塞処理を行う。

すなわち、まずステップ６６では対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)の中から処理対象の単一のパスを選択する。次のステップ６８ではパス状態管理テーブルを参照し、ステップ６６で選択した処理対象のパスに対応する(処理対象のパスによってサーバ・コンピュータ１２と接続されている)判定対象の論理ディスクＬＵについて、当該判定対象の論理ディスクＬＵをサーバ・コンピュータ１２と接続している全てのパスの状態を確認する。そしてステップ７０では、該判定対象の論理ディスクＬＵをサーバ・コンピュータ１２と接続している全てのパス(一例として図２には、論理ディスクＬＵ#0をサーバ・コンピュータ１２と接続している全てのパスを明示している)のうち、未閉塞のパスの数が２以上か否か判定する。

ステップ７０の判定が肯定された場合はステップ７２へ移行し、パス状態管理テーブルに登録されている処理対象のパスの状態情報を「稼働中:online」から「非稼働中(閉塞中):offline」へ書き替えることで処理対象のパスを閉塞し、ステップ７４へ移行する。また、判定対象の論理ディスクＬＵをサーバ・コンピュータ１２と接続している未閉塞のパスの数が１の場合、すなわち処理対象のパスが判定対象の論理ディスクＬＵをサーバ・コンピュータ１２と接続している未閉塞の最後のパスである場合は、処理対象のパスを閉塞してしまうとサーバ・コンピュータ１２が判定対象の論理ディスクＬＵと通信不能の状態になってしまうので、ステップ７０の判定が否定された場合はステップ７２の処理を行うことなくステップ７４へ移行する。

ステップ７４では、対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)の中に未処理のパス(処理対象として未選択のパス)が存在しているか否か判定する。この判定が肯定された場合はステップ６６へ戻り、ステップ７４の判定が否定される迄ステップ６６〜ステップ７４を繰り返す。これにより、対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)に属する全てのパスに対してステップ６６〜ステップ７４の閉塞処理が各々行われる(図３の(5)も参照)。なお、ステップ６６〜ステップ７４は本発明に係る制御手段に対応している。

上記の閉塞処理の結果、例えば図５に示すパターン１のように、サーバ・コンピュータ１２とディスク装置２４の間に設けられた全てのパスが「稼働中:online」の状態で、ＨＢＡ０系のパスのグループのうちの一部のパスでＩ／Ｏ遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、ＨＢＡ０系のパスのグループにおける全てのパスの状態情報が「非稼働中(閉塞中):offline」へ書き替えされる。また、例えば図５に示すパターン２のように、ＨＢＡ０系のパスのグループのうちの一部のパスが「非稼働中(閉塞中):offline」の状態で、ＨＢＡ０系のパスのグループのうちの他のパスでＩ／Ｏ遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、ＨＢＡ０系のパスのグループのうち「稼働中:online」のパスの状態情報が「非稼働中(閉塞中):offline」へ書き替えされる。

なお、上記のように一部のパスが「非稼働中(閉塞中):offline」となっている状態は、例えば特定のパスにおける光通信の通信障害や一時的な減衰により、特定のパスが物理的に通信不能な状態となったことがＨＢＡによって検知され、これに基づきドライバによって対応するパスの状態情報が書替えられることによって生ずる。図５に示すパターン１,２では、何れもパス閉塞制御実行後にＨＢＡ０系の全てのパスが「非稼働中(閉塞中):offline」となっており、同一グループに属するパスの中に「稼働中:online」のパスと「非稼働中(閉塞中):offline」のパスが混在している交差閉塞状態が生ずることが回避されているので、発生した障害を復旧させる際の作業が簡単になる。

一方、例えば図５に示すパターン３のように、ＨＢＡ２系のパスのグループのうちの一部のパス(論理ディスクLU#0に対応するパス)が「非稼働中(閉塞中):offline」の状態で、ＨＢＡ０系のパスのグループのうちの一部のパスでＩ／Ｏ遅延が発生した場合には、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、ＨＢＡ０系のパスのグループのうち論理ディスクLU#0以外の論理ディスクに対応するパスについては状態情報が「非稼働中(閉塞中):offline」へ書き替えされるものの、論理ディスクLU#0に対応するパスについては、当該パスが論理ディスクLU#0をサーバ・コンピュータ１２と接続している未閉塞の最後のパスであり、前記パスを閉塞してしまうとサーバ・コンピュータ１２が論理ディスクLU#0と通信不能の状態になってしまうことから、前述のステップ７０の判定が否定されることで状態情報は「稼働中:online」のまま維持される。この場合は交差閉塞状態が生ずることになるものの、サーバ・コンピュータ１２が論理ディスクLU#0と通信不能の状態になってしまうことは回避できる。

なお、上記の閉塞処理で閉塞されたパスは、サーバ・コンピュータ１２からディスク装置２４へのＩ／Ｏ要求の転送に用いるパスの選択対象から除外されるので、ドライバによってＩ／Ｏ遅延の発生が検知されてＩ／Ｏ遅延メッセージがログ情報記録領域に記録されることはない。このため、同一グループに属する各パスが各々経由する機器等で障害が発生したとしても、図５に示すパターン１,２のように同一グループに属する全パスを閉塞できた場合には、以後は今回の障害が復旧する迄の間、今回Ｉ／Ｏ遅延が発生したパスのグループに対してパス閉塞制御処理が再度行われることはない。また、閉塞処理で閉塞されたパスについては、閉塞される前に当該パスを用いてＩ／Ｏ要求が送信され、送信したＩ／Ｏ要求に対する応答がタイムアウトしたことで前記パスの閉塞後にＩ／Ｏ遅延の発生が検知されたとしても、前記パスが閉塞されたことに基づきＩ／Ｏ要求の再送信は行われない。従って、同一グループに属する各パスに影響を及ぼす障害が発生した場合にサーバ・コンピュータ１２に加わる負荷を軽減できると共に、メモリ等のリソースの消費量も抑制できる。また、上記の閉塞処理はログ情報記録領域へのＩ／Ｏ遅延メッセージの記録、すなわち、ドライバによる１回目のＩ／Ｏ要求の送信がタイムアウトしたことをトリガとして行われるので、ドライバからリンク管理部へ障害の発生が通知されたことをトリガとして閉塞処理を行う場合と比較してより早期に閉塞処理を行うことができる。

対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)に属する全てのパスに対してステップ６６〜ステップ７４の処理を行うと、ステップ７４の判定が否定されてステップ７６へ移行し、パス状態管理テーブルを再度参照し、ステップ６６〜ステップ７４の処理の結果、対応するパスのグループの全てのパスが閉塞されたか否か判定する。上記判定の条件には、例えば図５に示すパターン１,２が該当し、上記判定が肯定された場合はステップ８２へ移行する。また、ステップ７６の判定が否定された場合はステップ７８へ移行し、パス状態管理テーブルを再度参照してディスク装置２４の各論理ディスク毎に未閉塞のパスの数を計数する。そして次のステップ８０では、ディスク装置２４の各論理ディスク毎の未閉塞のパスの数が全て１か否か判定する。ステップ７６の判定が否定されてステップ８０の判定が肯定される条件には、例えば図５に示すパターン３が該当し、ステップ８０の判定が肯定された場合はステップ８２へ移行する。

ステップ７６又はステップ８０の判定が肯定される条件では、今回発生した障害が復旧する迄の間、少なくとも対応するパスのグループ(Ｉ／Ｏ遅延が発生したパスのグループ)に対しては閉塞処理(状態情報の書き替え)を行う必要は無く、また、例えば図５に示すパターン３におけるＨＢＡ０系の論理ディスクLU#0に対応するパスのように、対応するパスのグループの中に未閉塞のパスが存在していたとしても、当該パスを閉塞するとサーバ・コンピュータ１２が通信不能の状態になってしまう論理ディスクＬＵが出現するので、対応するパスのグループに対しては閉塞処理(状態情報の書き替え)を行うことは望ましくない。このため、ステップ８２では自処理を起動したログトラップ(対応するパスのグループが同一のログトラップ)の動作を停止させ(図３の(6)、図５に示すパターン１〜３の「ログトラップ」の欄も参照)た後にステップ８４へ移行する。

このログトラップの動作停止に伴い、以後は対応するパスのグループにＩ／Ｏ遅延が発生したことを表すＩ／Ｏ遅延メッセージがログ情報記録領域に記録されたとしても、ログトラップによってパス閉塞制御シェルが起動されることはなく、パス閉塞制御処理は行われない。これにより、同一グループに属する各パスが各々経由する機器等で障害が発生したとしても、ログトラップの動作を停止させた以降は、今回の障害が復旧する迄の間、今回Ｉ／Ｏ遅延が発生したパスのグループに対してパス閉塞制御処理が再度行われることはないので、同一グループに属する各パスに影響を及ぼす障害が発生した場合にサーバ・コンピュータ１２に加わる負荷を軽減できると共に、メモリ等のリソースの消費量も抑制できる。

一方、ステップ７６の判定及びステップ８０の判定が各々否定される条件としては、例えば何らかの理由により１つ以上のパスの閉塞に失敗した場合が挙げられる。典型例を図５にパターン４として示す。図５に示すパターン４は、サーバ・コンピュータ１２とディスク装置２４の間に設けられた全てのパスが「稼働中:online」の状態で、ＨＢＡ０系のパスのグループのうちの一部のパスでＩ／Ｏ遅延が発生することで、前述したパターン１と同様に、ＨＢＡ０系のパスのグループにおける全てのパスの状態情報の「非稼働中(閉塞中):offline」への書き替えを行ったものの、「パス閉塞制御実行後の管理テーブルの内容」に示されているように、エラー発生等の理由でＨＢＡ０系のパスのグループのうち論理ディスクLU#0に対応するパスの状態情報の書き替えに失敗したパターンである。

上記のパターン４では、ＨＢＡ０系のパスのグループの中に状態が「稼働中:online」のパス(論理ディスクLU#0に対応するパス)が混在しているのでステップ７６の判定が否定され、論理ディスクLU#0は対応するＨＢＡ０系及びＨＢＡ２系のパスが各々「稼働中:online」で未閉塞のパスの数＝２のためステップ８０の判定も否定される。このパターン４のように、対応するパスのうち未閉塞のパスの数が２以上の論理ディスクが存在している場合、当該論理ディスクについては、障害の発生に伴って対応するパスを閉塞する余地がある(障害の発生に伴って対応する何れか１つのパスを閉塞してもサーバ・コンピュータ１２と通信不能の状態にはならない)ので、ステップ７６,８０の判定が否定された場合はログトラップの動作を停止させることなく(ステップ８２をスキップして)ステップ８４へ移行する(図５に示すパターン４の「ログトラップ」の欄も参照)。

そしてステップ８４では、先のステップ６０で作成したロックディレクトリを削除し、パス閉塞処理を終了する。このロックディレクトリの削除に伴い、自シェルが再度起動されて対応するパスのグループが同一のパス閉塞制御処理が再度行われた場合に、パス状態管理テーブルを更新する閉塞処理を行うことが可能となる。

ところで、パス閉塞制御処理では、上述のようにステップ６６〜ステップ７４の閉塞処理により、対応するパスのグループの全てのパスの閉塞が試行されると共に、通常は(パスの状態情報の書き替えに失敗した等の稀なケース以外は)ログトラップの動作も停止されるので、同一グループに属する各パスが経由する機器等で障害が発生したとしても、各パスでＩ／Ｏ遅延が発生したことがドライバによって検知されるタイミングに一定時間以上の時間差があれば、Ｉ／Ｏ遅延が発生したことがドライバによって最初に検知されたパスについてのみ、ログ情報記録領域にＩ／Ｏ遅延メッセージが記録され、ログトラップによってパス閉塞制御シェルの起動されてパス閉塞制御処理が実行されることになる。

しかしながら、同一グループに属する各パスでＩ／Ｏ遅延が発生したことがドライバによってほぼ同時に検知された場合、より詳しくは、Ｉ／Ｏ遅延の発生が最初に検知されたパスについて、ログ情報記録領域にＩ／Ｏ遅延メッセージが記録されたことをトリガとしてパス閉塞制御処理が行われ、パス状態管理テーブルが更新されてログトラップの実行が停止される前に、同一グループに属する他のパスについてもＩ／Ｏ遅延の発生が検知され、ログ情報記録領域にＩ／Ｏ遅延メッセージが記録された場合には、同一のグループに属する複数のパスについて、ログ情報記録領域へのＩ／Ｏ遅延メッセージの記録をトリガとして、対応するパスのグループが同一の複数のパス閉塞制御処理が重複起動され、対応するパスのグループが同一の複数のパス閉塞制御処理がほぼ同じタイミングで並列に実行されることになる。以下、この場合のパス閉塞制御処理について説明する。

前述のように、パス閉塞制御処理のステップ５０ではロックディレクトリが既に作成されているか否かを判定している。先に説明したように、パス閉塞制御処理では処理終了時に、作成したロックディレクトリを削除する(ステップ８４)ので、ステップ５０の判定が肯定された場合は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が高いものの、稀に、以前に行われたパス閉塞制御処理でロックディレクトリの削除に失敗し、パス閉塞制御処理自体は終了しているもののロックディレクトリが残ってしまっていることもあり、これが原因である可能性も否定できない。

このため、ステップ５０の判定が肯定された場合はステップ５２へ移行し、既に存在しているロックディレクトリのタイムスタンプ(ロックディレクトリの作成日時)を確認した後に、次のステップ５４において、既に存在しているロックディレクトリの作成日時からの経過時間が予め定めた閾値以上か否か判定する。なお、ステップ５４の判定における閾値としては、例えばパス閉塞制御処理に要する時間よりも十分に長い時間(例えば１分間)に相当する値を適用することができる。また、ステップ５２,５４は請求項３に記載の判定手段に対応している。既に存在しているロックディレクトリの作成日時からの経過時間が予め定めた閾値未満の場合は、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が非常に高いと判断できるので、上記判定が否定された場合はステップ５６へ移行し、「多重起動のため停止」のメッセージを出力してパス閉塞制御処理を終了する。なお、ステップ５４の判定が否定された場合に、上記のようにステップ５６を経てパス閉塞制御処理を終了することは、請求項４に記載の「プログラムの終了」に対応している。

またステップ５４の判定が肯定された場合、既に存在しているロックディレクトリは、以前に行われたパス閉塞制御処理で削除に失敗して残ってしまっているものであり、以前に行われたパス閉塞制御処理自体は終了していると判断できるので、ステップ５８へ移行し、既に存在しているロックディレクトリを削除した後にステップ６０へ移行し、新たなロックディレクトリの作成を試行する。そしてロックディレクトリの作成に成功した場合には、ステップ６２の判定が肯定されてステップ６６へ移行し、先に説明した閉塞処理・ログトラップの動作停止が順に行われる。なお、ステップ５８は先に説明したステップ８４と共に請求項３に記載の制御手段に対応しており、ステップ５８で既に存在しているロックディレクトリを削除した後に、ステップ６０で新たなロックディレクトリの作成を試行することは、請求項３に記載の作成手段に対応している。

また、同一グループに属する複数のパスの各々におけるＩ／Ｏ遅延の発生が検知されたタイミングの時間差が極めて小さい場合、Ｉ／Ｏ遅延の発生が最初に検知されたパスに対応するパス閉塞制御処理でロックディレクトリが作成される前に、Ｉ／Ｏ遅延の発生が２番目以降に検知されたパスに対応するパス閉塞制御処理が行われ、Ｉ／Ｏ遅延の発生が２番目以降に検知されたパスに対応するパス閉塞制御処理でステップ５０の判定が否定されることも確率として０ではない。

しかしながら、ディレクトリの作成はＯＳを通じて行われるので、複数の処理(プロセス)がＯＳを通じてディレクトリを同時に作成しようとしたとしても、作成タイミングには必ず時間差が生じると共に、対応するパスのグループが同一のパス閉塞制御シェルによるパス閉塞制御処理ではロックディレクトリとして作成するディレクトリの名称が同一である一方、ＵＮＩＸ（登録商標）系のＯＳでは名称が同一のディレクトリの重複作成が制限(禁止)されているので、一方のパス閉塞制御処理ではロックディレクトリの作成に必ず失敗する。従って、パス閉塞制御処理においてステップ６２の判定が否定された場合、すなわちステップ６０で試行したロックディレクトリの作成に失敗した場合には、重複起動されているパス閉塞制御シェルによる別のパス閉塞制御処理でロックディレトリが先に作成されたと判断できるので、ステップ６４へ移行し「ディレクトリ作成失敗」のメッセージを出力してパス閉塞制御処理を終了する。なお、ステップ６２の判定が否定された場合に、上記のようにステップ６４を経てパス閉塞制御処理を終了することは、請求項２に記載の「プログラムの終了」に対応している。

このように、本実施形態に係るパス閉塞制御処理では、ロックディレクトリが既に存在しており、かつ当該ロックディレクトリの作成日時からの経過時間が閾値未満の場合、及び、ロックディレクトリは存在していないと判定したもののロックディレクトリの作成に失敗した場合には、対応するパスのグループが同一のパス閉塞制御シェルが重複起動されている可能性が非常に高いと判断してパス閉塞制御処理を直ちに終了するので、同一グループに属する各パスでＩ／Ｏ遅延が発生したことがドライバによってほぼ同時に検知され、対応するパスのグループが同一の複数のパス閉塞制御処理がほぼ同じタイミングで並列に実行された場合にも、閉塞処理が重複して実行されることを確実に防止することができ、サーバ・コンピュータ１２に加わる負荷を低減できると共に、メモリ等のリソースの消費量を早期に回復させることができる。

従って、本実施形態に係るパス閉塞制御処理によれば、複数のパスに影響を及ぼす障害がコンピュータ・システム１０に発生した場合に、各パスでのＩ／Ｏ遅延の発生が検知されたタイミングに拘わらず、サーバ・コンピュータ１２に加わる負荷を低減し、メモリ等のリソースの消費量を抑制することができるので、複数のパスに影響を及ぼす障害がコンピュータ・システム１０に発生した場合のサーバ・コンピュータ１２の動作安定化を実現することができる。

なお、上記で説明したパス閉塞制御処理では、対応するパスのグループに対して閉塞処理を行った後、ディスク装置２４の各論理ディスク毎の未閉塞のパスの数が全て１の場合(ステップ８０の判定が肯定された場合)に、対応するパスのグループが同一のログトラップの動作を停止させていたが、これに限定されるものではない。上記処理では、対応するパスのグループが異なるログトラップは動作が継続され、対応するパスのグループと異なるグループに属するパスでＩ／Ｏ遅延が発生した場合はパス閉塞制御シェルが起動されることになるが、各論理ディスク毎の未閉塞のパスの数が全て１であれば、パスの全てのグループに対して閉塞処理は不要であり、また閉塞処理を行うことは望ましくもないので、各論理ディスク毎の未閉塞のパスの数が全て１の場合には、パスの全てのグループに対してログトラップの動作を停止させるようにしてもよい。

また、上記ではログトラップ及びパス閉塞制御シェルをパスのグループ毎に設けた態様を説明したが、本発明はこれに限定されるものではなく、ログトラップ及びパス閉塞制御シェルを１つづつ設け、ログトラップは、ログ情報記録領域へのＩ／Ｏ遅延メッセージの記録をトリガとして、記録されたＩ／Ｏ遅延メッセージに対応するパスのグループを判定し、判定したグループを引数としてパス閉塞制御シェルを起動し、起動されたパス閉塞制御シェルは、通知されたグループが閉塞処理停止中か否かを判定し、閉塞処理停止中でなければ通知されたグループに対応する名称のロックディレクトリの存在確認、同名称のロックディレクトリの作成試行、通知されたグループの各パスに対する閉塞処理、通知されたグループが閉塞処理停止中であることを表す情報の設定・記憶、の各処理を行うように構成してもよい。

また、上記では本発明に係る外部機器の一例として、ディスク駆動装置(ＤＫＵ)２６によって駆動される多数台のディスクドライブを備えたディスク装置２４を説明したが、本発明に係る外部機器は上記構成に限定されるものではなく、例えばフラッシュメモリ等の半導体メモリから成る記憶装置であってもよいし、本発明に係るコンピュータ以外の相手装置と通信を行う通信装置であってもよく、任意の機器を適用可能である。

更に、外部機器(論理ディスクＬＵ)の数やパスのグループの数(ＨＢＡ２０、チャネル・アダプタ(ＣＨＡ)３２の数)、コンピュータ(サーバ・コンピュータ１２)の数等は、図面に示した数に限られるものではなく、本発明を逸脱しない範囲で適宜変更可能である。

また、上記では本発明に係る障害管理プログラムに対応するパス閉塞制御シェルがサーバ・コンピュータ１２の記憶部１８に予め記憶（インストール）されている態様を説明したが、本発明に係る障害管理プログラムは、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体に記録されている形態で提供することも可能である。

１０ コンピュータ・システム
１２ サーバ・コンピュータ
１４ ＣＰＵ
１６ メモリ
１８ 記憶部
２０ ＨＢＡ
２２ 光ファイバケーブル
２４ ディスク装置

Claims (5)

1. 外部機器と通信するための複数のパスから成るグループが設けられたコンピュータによって実現される障害管理装置であって、
   何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段と、
   前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段と、
   前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段と、
   を備えた障害管理装置。
2. 前記判定手段、前記作成手段及び前記制御手段は、前記グループの何れかのパスで障害の発生が通知される毎に起動されて前記コンピュータによって実行される単一のプログラムによって実現され、前記コンピュータによる前記プログラムの実行は、前記作成手段による前記所定の属性のファイル情報の作成が失敗した場合に終了される請求項１記載の障害管理装置。
3. 前記判定手段は、前記所定の属性のファイル情報が既に作成されていると判定した場合に、当該ファイル情報が作成されてからの経過時間が閾値以上か否かを判定し、
   前記制御手段は、前記閉塞処理の終了後に、前記作成手段によって作成された前記所定の属性のファイル情報を削除すると共に、前記判定手段により、前記所定の属性のファイル情報が既に作成されており、当該ファイル情報が作成されてからの経過時間が前記閾値以上と判定された場合に、既に作成されている前記ファイル情報を削除し、
   前記作成手段は、前記判定手段によって前記経過時間が前記閾値以上と判定された場合に、既に作成されている前記ファイル情報が前記制御手段によって削除された後に、前記所定の属性のファイル情報の作成を試行する請求項１又は請求項２記載の障害管理装置。
4. 前記判定手段、前記作成手段及び前記制御手段は、前記グループの何れかのパスで障害の発生が通知される毎に起動されて前記コンピュータによって実行される単一のプログラムによって実現され、前記コンピュータによる前記プログラムの実行は、前記判定手段によって前記所定の属性のファイル情報が作成されており、かつ前記経過時間が前記閾値未満と判定された場合に終了される請求項３記載の障害管理装置。
5. 外部機器と通信するための複数のパスから成るグループが設けられたコンピュータを、
   何れかのパスでの障害の発生が通知される毎に、同一属性での重複作成が制限されているファイル情報が、前記障害の発生が通知されたパスが属するグループに対応する所定の属性で既に作成されているか否かを判定する判定手段、
   前記判定手段によって前記所定の属性のファイル情報が作成されていないと判定された場合に、前記所定の属性のファイル情報の作成を試行する作成手段、
   及び、前記作成手段による前記所定の属性のファイル情報の作成が成功した場合に、前記障害の発生が通知されたパスと同一のグループに属する全てのパスを閉塞するための閉塞処理を行う制御手段
   として機能させる障害管理プログラム。