(57)【要約】【課題】ノードにおけるデッドロックの発生をイベントドリブンで検出し、障害発生から障害検出までの時間を短縮及び検出可能な障害範囲を拡大することを可能とする。【解決手段】クラスタシステムは、資源を共有する複数のスレッドを実行するノード１０を備える。ノード１０は、ＡＰＩフック部１３１、ロック状態テーブル１３３及びデッドロック検出部１３４を含む。ＡＰＩフック部１３１は、複数のスレッドの各々からの、資源を占有するためのロックの取得を要求するロック取得要求をフックする。ロック状態テーブル１３３には、ＡＰＩフック部１３１によってフックされたロック取得要求に基づいて、複数のスレッドによるロックの取得状態が登録される。デッドロック検出部１３４は、ＡＰＩフック部１３１によってフックされたロック取得要求及びロック状態テーブル１３３に登録されているロックの取得状態に基づいて、デッドロックの発生を検出する。【選択図】      図２
2009271858.tif 000002
【特許請求の範囲】
【請求項１】
資源を共有する複数のスレッドを実行する計算機を具備し、
前記計算機は、
前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得する取得手段と、
前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態が登録されるロック状態テーブルと、
前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出する検出手段と
を含む
ことを特徴とする計算機システム。
【請求項２】
前記計算機は、前記検出手段によってデッドロックの発生が検出された場合に当該計算機の処理を当該計算機とは別の計算機に引き継ぐフェイルオーバ手段を更に含むことを特徴とする請求項１記載の計算機システム。
【請求項３】
前記計算機によってアクセスされる格納手段を更に具備し、
前記計算機は、
前記デッドロックの発生が検出された場合、前記ロック状態テーブルに登録されているロックの取得状態によって表される当該デッドロックを示すデッドロック状況情報を作成し、当該作成されたデッドロック状況情報を前記格納手段に格納する作成手段と、
前記取得手段によって前記複数のスレッドの各々からのロック取得要求が取得された場合に、前記格納手段に格納されているデッドロック状況情報を読み込む読み込み手段と、
前記取得されたロック取得要求に応じてロックが取得された場合に、前記読み込まれたデッドロック状況情報によって示されるデッドロックに陥る可能性があるかを、前記ロック状態テーブルに登録されているロックの取得状態に基づいて判定する判定手段と、
前記デッドロックに陥る可能性があると判定された場合、前記取得されたロック取得要求に応じたロック取得処理をサスペンドするサスペンド手段と
を含む
ことを特徴とする請求項２記載の計算機システム。
【請求項４】
前記サスペンド手段は、予め定められた時間、サスペンドすることを特徴とする請求項３記載の計算機システム。
【請求項５】
前記取得されたロック取得要求に応じてロックが取得された場合には前記ロックの取得状態としてロック中であることを前記ロック状態テーブルに登録し、当該ロック取得要求に応じて取得されるロックが当該ロック取得要求の要求元であるスレッド以外のスレッドによって取得されている場合には前記ロックの取得状態としてロック要求中であることを前記ロック状態テーブルに登録するロック管理手段を更に含み、
前記検出手段は、前記ロック状態テーブルを参照して、前記複数のスレッド間において前記ロック状態テーブルに登録されているロック中及びロック要求中のループが発生する際に前記デッドロックの発生を検出する
ことを特徴とする請求項１記載の計算機システム。
【請求項６】
資源を共有する複数のスレッドを実行し、ロック状態テーブルを備える計算機によって実行されるプログラムであって、
前記計算機に、
前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得するステップと、
前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態を前記ロック状態テーブルに登録するステップと、
前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出するステップと
を実行させるためのプログラム。
【請求項７】
前記計算機に、
前記デッドロックの発生が検出された場合に当該計算機の処理を当該系計算機とは別の計算機に引き継ぐステップと、
前記デッドロックの発生が検出された場合、前記ロック状態テーブルに登録されているロックの取得状態によって表される当該デッドロックを示すデッドロック状況情報を作成し、当該作成されたデッドロック状況情報を、前記計算機によってアクセスされる格納手段に格納するステップと、
前記複数のスレッドの各々からのロック取得要求が取得された場合に、前記格納手段に格納されているデッドロック状況情報を読み込むステップと、
前記取得されたロック取得要求に応じてロックが取得された場合に、前記読み込まれたデッドロック状況情報によって示されるデッドロックに陥る可能性があるかを、前記ロック状態テーブルに登録されているロックの取得状態に基づいて判定するステップと、
前記デッドロックに陥る可能性があると判定された場合、前記取得されたロック取得要求に応じたロック取得処理をサスペンドするステップと
を更に実行させるための請求項６記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機において発生するデッドロックを検出する計算機システム及びプログラムに関する。
【背景技術】
【０００２】
近年、例えば複数のノード（計算機）及び少なくとも１つ以上のストレージ装置（共有ディスク）から構成される高可用性（High Availability）クラスタシステム（以下、ＨＡクラスタシステムと表記）と呼ばれる計算機システムが知られている。このＨＡクラスタシステムを構成する複数のノードには、例えば運用系ノード及び待機系ノードが含まれる。
【０００３】
ＨＡクラスタシステムにおいては、例えば運用系ノードで障害が発生した場合、当該運用系ノード上で動作していたアプリケーション、共有ディスクまたはＩＰ（Internet Protocol）アドレス等を待機系ノードで引き継ぐ（フェイルオーバ）ことにより障害を復旧し、クラスタシステムにおける運用を継続することができる。以下、ＨＡクラスタシステムが提供する機能を継続するために必要な運用系ノードから待機系ノードに引き継がれる引継ぎ単位のセット（例えばアプリケーション、共有ディスク、ＩＰアドレス等）を統合してサービスと称する。
【０００４】
例えば運用系ノードで発生する障害は、大きく２つ（第１の障害、第２の障害）に分類できる。第１の障害は、例えばシャットダウン等のノード自体が停止することにより生じるサーバ障害である。第２の障害は、例えばノード上で稼動しているアプリケーションが誤動作することにより生じるアプリケーション障害である。
【０００５】
上記したＨＡクラスタシステムを構成する各ノードには、当該ＨＡクラスタシステムを管理するためのミドルウェア（ＨＡクラスタデーモン）が備えられている。このＨＡクラスタデーモンでは、障害発生時に自動で待機系ノードにサービスを引き継ぐため、例えば運用系ノードで発生する障害を検出する仕組みが必要となる。以下、上記した第１の障害及び第２の障害のうち、第２の障害について述べる。
【０００６】
上記した第２の障害（アプリケーション障害）を検出する技術として、例えば監視の対象となるアプリケーション（以下、監視対象アプリケーションと表記）の状態を監視する外部コマンド（状態監視コマンド）を用意し、ＨＡクラスタデーモンにおいて当該状態監視コマンドが定期的に実行されることによって監視対象アプリケーションで発生した障害を検出する技術（以下、先行技術１と表記）がある。この先行技術１によれば、状態監視コマンドの返り値が異常を示すものであれば監視対象アプリケーションで障害が発生したことが検出される。なお、監視対象アプリケーションは、例えば少なくとも１つのプロセスから構成され、当該プロセスは１つ以上のスレッドから構成される。
【０００７】
ところで、上記したアプリケーション障害の代表的な例としてデッドロックが挙げられる。例えば上記した複数のスレッド（監視対象アプリケーション）の共有資源を用いて当該複数のスレッドのうちの１つのスレッドが実行される際、当該スレッドは、当該スレッドとは異なる他のスレッドからの当該共有資源の利用（アクセス）を排他制御するためにロックを取得する。この場合、ロックが取得されている間、他のスレッドは共有資源を利用することができない。また、スレッドの実行が終了されると、当該スレッドによって取得されていたロックは解放される。これにより、他のスレッドは共有資源を利用することができるようになる。
【０００８】
デッドロックとは、このような場合に、複数のスレッドがそれぞれロックを取得し、当該ロックが取得された状態を維持したまま当該複数のスレッドが互いに相手にロックされている共有資源の解放を待ってしまい、処理が停止することをいう。
【０００９】
このアプリケーション障害であるデッドロック（アプリケーションのデッドロック）を直接検出して、上記したサービスをフェイルオーバする技術は知られていない。
【００１０】
上記したアプリケーションのデッドロックの検出に関連する技術として、アプリケーションプログラムに影響することなく、デッドロック状態を容易に且つ正確に検知できる技術（以下、先行技術２と表記）が開示されている（例えば、特許文献１を参照）。この先行技術２によれば、ＯＳ（Operating System）の中でロックの取得状態が管理されることによってデッドロックが検出される。
【００１１】
また、デッドロックを発生させる可能性のある処理の組み合わせを構成する各処理を別々に行ったテスト時に取得した共通の資源に対するアクセス情報を元にデッドロックの可能性を検出する技術（以下、先行技術３と表記）が開示されている（例えば、特許文献２を参照）。この先行技術３によれば、アプリケーションの全処理の共有資源へのアクセス順序を予め記録し、その記録をつき合わせることでデッドロックが発生する可能性が検出される。
【００１２】
クラスタシステムにおけるデッドロックに関連する技術として、クラスタシステムにおける情報転送のためのオーバヘッド時間を短くし、デッドロック検出までの時間を短くする技術（以下、先行技術４と表記）が開示されている（例えば、特許文献３を参照）。この先行技術４は、クラスタシステム内のノード間の共有リソースにおけるデッドロックを検出する方法である。先行技術４によれば、ロック管理用ノードを１台用意し、当該共有リソースへのアクセスが不許可の場合、管理用ノードにチェックを要求することでデッドロックの発生が検出される。
【特許文献１】特開２００４−３４１８７８号公報
【特許文献２】特開２００１−２２９０４３号公報
【特許文献３】特開２０００−１７２６５９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記した先行技術１においては、例えば外部の状態監視コマンドの定期実行によってアプリケーションの特定の障害が検出される。
【００１４】
このため、先行技術１では、アプリケーションの代表的な障害であるデッドロックを外部から直接検出する手段がない。また、監視対象アプリケーションの内部実装はわからない場合が多いため、外部コマンドの実行では、必要な全ての機能の障害を網羅する監視は困難である。したがって、先行技術１では、例えばある特定の機能がデッドロックで処理できないというアプリケーション障害が発生しても当該デッドロックを検出することができない場合がある。
【００１５】
また、先行技術１では、デッドロックが発生した場合であっても状態監視コマンドで検出可能な状態になるまで時間を要する場合がある。更に、状態監視コマンドで検出可能な状態になっても、次の定期監視実行までにタイムラグがあり、その分の時間を要する。このため、先行技術１では、デッドロックという障害が発生しても即座に当該デッドロックを検出することはできない。
【００１６】
したがって、先行技術１では、平均修理時間の増大による可用性の低下や検出可能な障害範囲の限定といった影響がある。
【００１７】
上記した先行技術２においては、特殊なＯＳが必要であり、クラスタシステムが管理する任意のアプリケーションの動作には適さない。また、デッドロックが検出された場合であっても、フェイルオーバ等の対処を行うことはできない。
【００１８】
上記した先行技術３においては、上記したようにアプリケーションの全処理の共有資源へのアクセス順序を予め記録しておくため、動的にデッドロックを検出するものではない。したがって、先行技術３では、クラスタシステムでの障害検出には適さない。
【００１９】
上記した先行技術４においては、上記したようにロック管理用ノードを１台用意し、管理用ノードにチェックを要求することでデッドロックの発生を検出するため、ノード上で稼動するアプリケーションのデッドロックを検出する手段には適用することができない。
【００２０】
そこで、本発明の目的は、ノードにおけるデッドロックの発生をイベントドリブンで検出し、障害発生から障害検出までの時間を短縮及び検出可能な障害範囲を拡大することが可能な計算機システム及びプログラムを提供することにある。
【課題を解決するための手段】
【００２１】
本発明の１つの態様によれば、資源を共有する複数のスレッドを実行する計算機を具備し、前記計算機は、前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得する取得手段と、前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態が登録されるロック状態テーブルと、前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出する検出手段とを含むことを特徴とする計算機システムが提供される。
【発明の効果】
【００２２】
本発明によれば、ノードにおけるデッドロックの発生を検出することで、障害発生から障害検出までの時間を短縮及び検出可能な障害範囲を拡大することが可能となる。
【発明を実施するための最良の形態】
【００２３】
以下、図面を参照して、本発明の各実施形態について説明する。
【００２４】
［第１の実施形態］
図１は、本発明の第１の実施形態に係るクラスタシステム（計算機システム）の機能構成を示すブロック図である。
【００２５】
図１に示すように、本実施形態に係るクラスタシステムは、複数のノード（計算機）１０及び共有ディスク３０を備える。複数のノード１０には、運用系ノード及び複数の待機系ノードが含まれる。
【００２６】
複数のノード１０は、例えば通信路を介して互いに通信可能に接続されている。
【００２７】
また、複数のノード１０及び共有ディスク３０は、例えばＦＣ（Fibre Channel）ケーブルで接続されている。
【００２８】
上記したクラスタシステムは、当該クラスタシステムを構成する複数のノード１０のうち、例えば運用系ノードとして動作するノード（以下、運用系ノードと表記）１０で障害が発生した場合、当該運用系ノード１０の処理が待機系ノードとして動作するノード（以下、単に待機系ノードと表記）１０に引き継がれる高可用性（High Availability）クラスタシステム（ＨＡクラスタシステム）である。つまり、運用系ノード１０で障害が発生した場合には、例えば運用系ノード１０上で動作していたアプリケーション、共有ディスク３０または当該運用系ノード１０のＩＰ（Internet Protocol）アドレス等（以下、サービスと表記）が待機系ノード１０に引き継がれる処理（フェイルオーバ）が実行される。これにより、クラスタシステムでは、運用系ノード１０において障害が発生した場合であっても待機系ノード１０において運用を継続することが可能となる。
【００２９】
図２は、図１に示す複数のノード１０の各々（以下、単にノード１０と表記）の主として機能構成を示すブロック図である。
【００３０】
ノード１０上では、アプリケーション１１、ＯＳ（Operating System：オペレーティングシステム）１２、ジャケットライブラリ１３及びＨＡ（High Availability）クラスタデーモン１４が動作する。
【００３１】
アプリケーション１１は、ジャケットライブラリ１３による監視の対象となるアプリケーション（以下、監視対象アプリケーション１１と表記）である。監視対象アプリケーション１１は、例えば少なくとも１つのプロセスから構成される。ここでは、監視対象アプリケーション１１は、１つのプロセスから構成されるものとして説明する。また、監視対象アプリケーション１１を構成するプロセスは、１つ以上のスレッドから構成される。ここでは、監視対象アプリケーション１１を構成するプロセスは、複数のスレッドから構成されるものとして説明する。
【００３２】
つまり、例えば運用系ノードとして動作するノード（運用系ノード）１０では、監視対象アプリケーション１１（を構成するプロセス）を構成する複数のスレッドが実行される。
【００３３】
監視対象アプリケーション１１を構成する複数のスレッドは、例えばノード１０が有する資源（リソース）を共有する。
【００３４】
ノード１０において複数のスレッドが実行される際には、当該複数のスレッドの各々は、当該ノード１０が有する資源を占有するためのロックの取得を要求するロック取得要求をＯＳ１２に対して出力する。これにより、ロックが取得された場合には、当該ロックが取得された資源に対する排他制御が可能となる。
【００３５】
また、複数のスレッドの各々は、当該スレッドによりロックが取得されている資源の占有を解放するためのロック解放要求をＯＳ１２に対して出力する。これにより、ロックが解放された場合には、ロックを取得していたスレッド以外のスレッドは、当該ロックが取得されていた資源を使用（利用）することが可能となる。
【００３６】
ＯＳ１２は、監視対象アプリケーション１１を構成する複数のスレッドの各々を管理する。この場合、ＯＳ１２は、複数のスレッドの各々を識別するためのスレッドＩＤを用いて実行中のスレッドを管理する。
【００３７】
ＯＳ１２は、ロック取得部１２１及びロック解放部１２２を含む。ロック取得部１２１は、複数のスレッドの各々からのロック取得要求に応じてロックを取得する処理を実行する。ロック取得部１２１は、複数のスレッドの各々からのロック取得要求に応じて取得されるべきロックが他のスレッドによって既に取得されている場合には、当該ロックが他のスレッドによって解放されるのを待ってからロックの取得処理を実行する。
【００３８】
ロック解放部１２２は、複数のスレッドの各々からのロック解放要求に応じてロックを解放する処理を実行する。
【００３９】
ジャケットライブラリ１３は、監視対象アプリケーション１１を構成する複数のスレッドの各々からのＯＳ１２に対するロック取得要求及びロック解放要求をフック（取得）することで、当該複数のスレッドの各々によるロックの取得状態を管理する機能を有する。また、ジャケットライブラリ１３は、フックされたロック取得要求及び複数のスレッドの各々によるロックの取得状態に基づいてデッドロックの発生を検出する機能を有する。
【００４０】
図２に示すように、ジャケットライブラリ１３は、ＡＰＩ（Application Program Interface）フック部１３１、ロック状態管理部１３２、ロック状態テーブル１３３、デッドロック検出部１３４及びデッドロック通知部１３５を含む。
【００４１】
本実施形態において、ＡＰＩフック部１３１、ロック状態管理部１３２、デッドロック検出部１３４及びデッドロック通知部１３５は、ノード１０のコンピュータ（図示せず）が例えばノード１０に備えられるメモリ（図示せず）に格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
【００４２】
また、本実施形態において、ロック状態テーブル１３３は、例えばノード１０に備えられるメモリ内であって、上記した監視対象アプリケーション１１（を構成するプロセス）に与えられたメモリ空間にその領域が確保されている。
【００４３】
換言すれば、図２に示すジャケットライブラリ１３は、ＡＰＩフック部１３１、ロック状態管理部１３２、デッドロック検出部１３４及びデッドロック通知部１３５というモジュールと、ロック状態テーブル１３３というデータで構成される。
【００４４】
ＡＰＩフック部１３１は、監視対象アプリケーション１１を構成する複数のスレッドのＯＳ１２に対するロック取得要求及びロック解放要求をフックする。このロック取得要求及びロック解放要求には、当該要求に応じて取得または解放されるロックのアドレスが含まれる。ロックのアドレスは、ＯＳ１２によって管理されているメモリ上のアドレスである。
【００４５】
ＡＰＩフック部１３１は、ロック取得要求がフックされた場合には、当該ロック取得要求に含まれるロックのアドレス及び当該ロック取得要求に応じてロックの取得が実行される旨（以下、「ロック取得の実行」と表記）をロック状態管理部１３２に通知する。
【００４６】
また、ＡＰＩフック部１３１は、ロック取得要求がフックされた場合には、当該ロック取得要求に応じてＯＳ１２に含まれるロック取得部（ロック取得ＡＰＩ）１２１を実行する。これにより、ロック取得部１２１は、ロック取得要求に応じてロック取得処理を実行する。
【００４７】
ＡＰＩフック部１３１は、ロック解放要求がフックされた場合には、当該ロック解放要求に含まれるロックのアドレス及び当該ロック解放要求に応じてロックの解放が実行される旨（以下、「ロック解放の実行」と表記）をロック状態管理部１３２に通知する。
【００４８】
また、ＡＰＩフック部１３１は、ロック解放要求がフックされた場合には、当該ロック解放要求に応じてＯＳ１２に含まれるロック解放部（ロック解放ＡＰＩ）１２２を実行する。これにより、ロック解放部１２２は、ロック解放要求に応じてロック解放処理を実行する。
【００４９】
ＡＰＩフック部１３１は、ＯＳ１２（に含まれるロック取得部１２１及びロック解放部１２２）からのロック取得要求に対する応答（以下、ロック取得応答と表記）及びロック解放要求に対する応答（以下、ロック解放応答と表記）をフックする。このロック取得応答及びロック解放応答には、当該取得または解放されたロックのアドレスが含まれる。また、ＡＰＩフック部１３１は、ロック取得応答及びロック解放応答を監視対象アプリケーション１１（を構成するスレッド）に返す。
【００５０】
ＡＰＩフック部１３１は、ロック取得応答がフックされた場合、当該ロック取得応答に含まれるロックのアドレス及び当該ロック取得応答が返された旨（以下、「ロック取得の応答」と表記）をロック状態管理部１３２に通知する。同様に、ＡＰＩフック部１３１は、ロック解放応答がフックされた場合、当該ロック解放応答に含まれるロックのアドレス及び当該ロック解放応答が返された旨（以下、「ロック解放の応答」と表記）をロック状態管理部１３２に通知する。
【００５１】
ＡＰＩフック部１３１は、上記したようにロック状態管理部１３２に通知することによって、当該ロック状態管理部１３２にロック状態テーブル１３３の更新を要求する。
【００５２】
また、ＡＰＩフック部１３１は、監視対象アプリケーション１１を構成するスレッドからのロック取得要求に応じたロック取得部１２１（ロック取得ＡＰＩ）の実行時に、デッドロック検出部１３４に対してデッドロックの発生の検出処理を要求する。このとき、ＡＰＩフック部１３１は、ロックのアドレスをデッドロック検出部１３４に出力する。
【００５３】
ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知を受けると、当該ＡＰＩフック部１３１によってフックされたロック取得要求またはロック解放要求の要求元であるスレッドを識別するためのスレッドＩＤを、監視対象アプリケーション１１を構成するスレッドを管理するＯＳ１２に問い合わせる。これにより、ロック状態管理部１３２は、スレッドＩＤを取得する。
【００５４】
ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知及び取得されたスレッドＩＤに基づいてロック状態テーブル１３３を更新する。ロック状態テーブル１３３には、監視対象アプリケーション１１を構成する複数のスレッドによるロックの取得状態が登録される。ロック状態テーブル１３３の更新は、ＡＰＩフック部１３１から通知されたロックのアドレス及びロック状態管理部１３２によって取得されたスレッドＩＤからなる組み合わせの状態（ロックの取得状態）を、ＡＰＩフック部１３１からの通知の内容（例えば、「ロック取得の実行」等）に応じた状態に変更することによって行われる。
【００５５】
ロック状態管理部１３２は、更新するスレッドＩＤまたはロックのアドレスがロック状態テーブル１３３にない（登録されていない）ときは当該ロック状態テーブル１３３を拡張する。
【００５６】
デッドロック検出部１３４は、ＡＰＩフック部１３１からの要求に基づいて、ＡＰＩフック部１３１によってフックされたロック取得要求に応じてロックが取得された場合にデッドロックが発生するか否かを確認する。これにより、デッドロック検出部１３４は、デッドロックの発生を検出する。
【００５７】
このとき、デッドロック検出部１３４は、ロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ１２に問い合わせることにより、当該スレッドＩＤを取得する。デッドロック検出部１３４は、取得されたスレッドＩＤ、ＡＰＩフック部１３１によって出力されたロックのアドレス及びロック状態テーブル１３３に登録されているロック取得状態に基づいてデッドロックの発生を検出する。デッドロックの発生が検出された場合、デッドロック検出部１３４は、デッドロック通知部１３５に当該デッドロックの発生の通知要求を出力する。
【００５８】
なお、デッドロック検出部１３４によるデッドロックの発生の検出処理の詳細については後述する。
【００５９】
デッドロック通知部１３５は、デッドロック検出部１３４によって出力された通知要求に基づいて、デッドロックの発生をＨＡクラスタデーモン１４に通知する。
【００６０】
ＨＡクラスタデーモン１４は、クラスタシステムの管理及び運用を実行する機能を有する。ＨＡクラスタデーモン１４は、運用系ノードとして動作するノード１０において例えば監視対象アプリケーション１１に障害が発生した場合には、当該ノード１０のサービスを当該ノード１０とは別の待機系ノードとして動作するノード１０に引き継ぐ（フェイルオーバ）処理を実行する。
【００６１】
ＨＡクラスタデーモン１４は、ジャケットライブラリ１３に含まれるデッドロック通知部１３５によってデッドロックの発生が通知された場合、監視対象アプリケーション１１において障害（デッドロック）が発生したものとしてサービスのフェイルオーバ等の対処を行う。
【００６２】
なお、ＨＡクラスタデーモン１４は、監視対象アプリケーション１１において障害が発生した場合の対処として、監視対象アプリケーション１１の再起動を行う構成であっても構わない。
【００６３】
図３は、図２に示すロック状態テーブル１３３のデータ構造の一例を示す。図３に示すように、ロック状態テーブル１３３には、ロックのアドレス及びスレッドＩＤに対応付けてロックの取得状態が登録される。ここでは、ロックのアドレスはＬ（Ｌ１、Ｌ２、Ｌ３、…）、スレッドＩＤはＴ（Ｔ１、Ｔ２、Ｔ３、…）と表記されている。
【００６４】
ここで、ロックの取得状態には、「ロック中」、「ロック要求中」及び「ロックなし」が含まれる。図３に示す例では、「ロック中」は「○」、「ロック要求中」は「△」、「ロックなし」は「ブランク（なし）」で表されている。
【００６５】
図３に示す例では、ロック状態テーブル１３３には、ロックのアドレス「Ｌ１」及びスレッドＩＤ「Ｔ１」に対応付けてロックの取得状態「○」が登録されている。これによれば、スレッドＩＤ「Ｔ１」によって識別されるスレッドが、ロックのアドレスが「Ｌ１」であるロックを「ロック中」であることが示されている。
【００６６】
ロック状態テーブル１３３には、ロックのアドレス「Ｌ２」及びスレッドＩＤ「Ｔ３」に対応付けてロックの取得状態「○」が登録されている。これによれば、スレッドＩＤ「Ｔ３」によって識別されるスレッドが、ロックのアドレスが「Ｌ２」であるロックを「ロック中」であることが示されている。
【００６７】
また、ロック状態テーブル１３３には、ロックのアドレス「Ｌ３」及びスレッドＩＤ「Ｔ１」に対応付けてロックの取得状態「△」が登録されている。これによれば、スレッドＩＤ「Ｔ１」によって識別されるスレッドが、ロックのアドレスが「Ｌ１」であるロックを「ロック要求中」であることが示されている。
【００６８】
なお、ロック状態テーブル１３３において、上記した以外については「ロック中」及び「ロック要求中」でない、つまり、「ロックなし」であることが示されている。
【００６９】
次に、図４を参照して、上記したロック状態管理部１３２によるロック状態テーブル１３３の更新について説明する。
【００７０】
ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知及び取得されたスレッドＩＤ（要求元であるスレッドを識別するためのスレッドＩＤ）に基づいてロック状態テーブル１３３を更新する。ＡＰＩフック部１３１からの通知（の内容）には、上記したように「ロック取得の実行」、「ロック取得の応答」、「ロック解放の実行」及び「ロック解放の応答」が含まれる。
【００７１】
ここで、図４に示すように、ＡＰＩフック部１３１からの通知の内容が「ロック取得の実行」である場合には、ロック状態管理部１３２は、ロック状態テーブル１３３におけるロックの取得状態を「ロック要求中」に更新する。例えばＡＰＩフック部１３１から通知されたロックのアドレスが「Ｌ１」、ロック状態管理部１３２によって取得されたスレッドＩＤが「Ｔ３」であり、ＡＰＩフック部１３１からの通知の内容が「ロック取得の実行」である場合を想定する。この場合には、ロック状態管理部１３２は、ロックのアドレス「Ｌ１」及びスレッドＩＤ「Ｔ３」に対応付けられているロック状態テーブル１３３におけるロックの取得状態を「ロック要求中」に更新する。
【００７２】
図４に示すように、ＡＰＩフック部１３１からの通知の内容が「ロック取得の応答」である場合には、ロック状態管理部１３２は、ロック状態テーブル１３３におけるロックの取得状態を「ロック中」に更新する。
【００７３】
図４に示すように、ＡＰＩフック部１３１からの通知の内容が「ロック解放の実行」である場合には、ロック状態テーブル１３３におけるロックの取得状態は変更していないため、ロック状態管理部１３２は、ロック状態テーブル１３３の更新は行わない。
【００７４】
また、図４に示すように、ＡＰＩフック部１３１からの通知の内容が「ロック解放の応答」である場合には、ロック状態管理部１３２は、ロック状態テーブル１３３におけるロックの取得状態を「ロックなし」に更新する。
【００７５】
次に、図５のフローチャートを参照して、前述したデッドロック検出部１３４によるデッドロックの発生の検出処理の処理手順について説明する。
【００７６】
デッドロックの発生の検出処理は、デッドロック検出部１３４がＡＰＩフック部１３１からの要求（デッドロックの発生の確認の要求）を受けると実行される。このとき、デッドロック検出部１３４は、ＡＰＩフック部１３１からロックのアドレスを受け取る。また、デッドロック検出部１３４は、ＯＳ１２に問い合わせることにより、スレッドＩＤを取得する。ここで取得されたスレッドＩＤは、ＡＰＩフック部１３１から受け取られたロックのアドレスを含むロック取得要求（ＡＰＩフック部１３１によってフックされたロック取得要求）の要求元であるスレッドを識別するためのＩＤである。以下、デッドロック検出部１３４がＡＰＩフック部１３１から受け取ったロックのアドレスをＬ、当該デッドロック検出部１３４によって取得されたスレッドＩＤをＴとして説明する。
【００７７】
まず、デッドロック検出部１３４は、初期化処理として、スタックをクリアする（ステップＳ１）。このスタックは、例えばデータを後入れ先出しの構造で保持するものであり、ハードウェアとソフトウェアの機能の組み合わせによって実装される。スタックは、例えばノード１０に備えられているメモリにその領域が確保される。
【００７８】
次に、デッドロック検出部１３４は、Ｔをスタックに追加する（ステップＳ２）。ここでは、Ｔは、デッドロック検出部１３４によって取得されたスレッドＩＤである。
【００７９】
デッドロック検出部１３４は、ＡＰＩフック部１３１から受け取ったＬのロックがＴによって識別されるスレッド以外のスレッド（以下、単に他のスレッドと表記）に取得されているか否かを判定する（ステップＳ３）。このとき、デッドロック検出部１３４は、ロック状態テーブル１３３を参照して判定処理を実行する。デッドロック検出部１３４は、ロック状態テーブル１３３においてＬのロックを「ロック中」であるスレッドが存在するか否かを判定する。
【００８０】
Ｌのロックが取得されていると判定された場合（ステップＳ３のＹＥＳ）、デッドロック検出部１３４は、Ｔを、当該Ｌのロックを「ロック中」である他のスレッドを識別するためのスレッドＩＤ（つまり、Ｔ＝Ｌのロックを取得しているスレッドを識別するためのスレッドＩＤ）とする（ステップＳ４）。これにより、ステップＳ４以降の処理においては、上記した他のスレッドを識別するためのスレッドＩＤをＴとして処理が実行される。
【００８１】
次に、デッドロック検出部１３４は、Ｔ（上記した他のスレッドを識別するためのスレッドＩＤ）がスタックに存在するか否かを判定する（ステップＳ５）。
【００８２】
スタックに存在しないと判定された場合（ステップＳ５のＮＯ）、デッドロック検出部１３４は、ロック状態テーブル１３３を参照して、Ｔによって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する（ステップＳ６）。
【００８３】
「ロック要求中」であるロックがあると判定された場合（ステップＳ６のＹＥＳ）、デッドロック検出部１３４は、Ｌを、当該ロックのアドレス（つまり、Ｌ＝Ｔによって識別されるスレッドが「ロック要求中」であるロックのアドレス）とする（ステップＳ７）。これにより、ステップＳ７以降の処理においては、上記したＴによって識別されるスレッドが「ロック要求中」であるロックのアドレスをＬとして処理が実行される。
【００８４】
上記したステップＳ７の処理が実行された場合、ステップＳ２に戻って処理が繰り返される。
【００８５】
一方、ステップＳ３においてＬのロックが取得されていないと判定された場合、デッドロック検出部１３４によって取得されたスレッドＩＤによって識別されるスレッドがロックを取得した場合であってもデッドロックは発生しないとして、デッドロック検出部１３４は、デッドロックの発生を検出することなく処理を終了する。
【００８６】
また、ステップＳ６において「ロック要求中」であるロックがないと判定された場合、デッドロック検出部１３４は、デッドロックの発生を検出することなく処理を終了する。
【００８７】
一方、ステップＳ５においてＴがスタックに存在すると判定された場合、デッドロック検出部１３４は、デッドロックの発生を検出する（ステップＳ８）。このように、ロック状態テーブル１３３に登録されているロックの取得状態において、ロック中及びロック要求中の（ロックの）ループが発生する場合に、デッドロック検出部１３４は、デッドロックの発生を検出する。
【００８８】
ここで、図６を参照して、上記した検出部１３４のデッドロックの発生の検出処理について具体的に説明する。図６は、デッドロックが発生する場合のロックの取得状態を表すロック状態テーブル１３３の一例を示す。
【００８９】
ここでは、デッドロック検出部１３４がＡＰＩフック部１３１から受け取ったロックのアドレスはＬ３であり、当該デッドロック検出部１３４がＯＳ１２に問い合わせることによって取得されたスレッドＩＤはＴ１であるものとして説明する。つまり、Ｔ１によって識別されるスレッドが、Ｌ３のロックを取得しようとしている場合を想定している。
【００９０】
なお、図６に示す例では、上記したＴ１及びＬ３に対応付けて「ロック要求中（△）」が、ロック状態テーブル１３３に登録されている。
【００９１】
この場合、デッドロック検出部１３４は、取得されたスレッドＩＤであるＴ１をスタックに追加する。
【００９２】
次に、デッドロック検出部１３４は、ＡＰＩフック部１３１から受け取ったＬ３のロックがＴ１によって識別されるスレッド以外のスレッド（他のスレッド）によって取得されているか否か（つまり、「ロック中」であるか否か）を、ロック状態テーブル１３３を参照して判定する。図６に示すロック状態テーブル１３３の例では、ＡＰＩフック部１３１から受け取ったＬ３のロックはＴ２によって識別されるスレッドによって取得されている。したがって、デッドロック検出部１３４は、Ｌ３のロックが他のスレッド（Ｔ２によって識別されるスレッド）によって取得されていると判定する。
【００９３】
デッドロック検出部１３４は、Ｔ２がスタックに存在するか否かを判定する。この段階ではスタックにはＴ１のみが存在するため、デッドロック検出部１３４は、Ｔ２がスタックに存在しないと判定する。
【００９４】
デッドロック検出部１３４は、ロック状態テーブル１３３を参照して、Ｔ２によって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する。図６に示すロック状態テーブル１３３の例では、Ｔ２によって識別されるスレッドは、Ｌ４のロックを「ロック要求中」である。したがって、デッドロック検出部１３４は、Ｔ２によって識別されるスレッドが「ロック要求中」であるロック（Ｌ４のロック）があると判定する。
【００９５】
この場合、デッドロック検出部１３４は、Ｔ２をスタックに追加する。Ｔ２がスタックに追加されると、デッドロック検出部１３４は、Ｌ４のロックがＴ２によって識別されるスレッド以外のスレッド（他のスレッド）によって取得されているか否かを、ロック状態テーブル１３３を参照して判定する。図６に示すロック状態テーブル１３３の例では、Ｌ４のロックはＴ４によって識別されるスレッドによって取得されている。したがって、デッドロック検出部１３４は、Ｌ４のロックが他のスレッド（Ｔ４によって識別されるスレッド）によって取得されていると判定する。
【００９６】
デッドロック検出部１３４は、Ｔ４がスタックに存在するか否かを判定する。この段階ではスタックにはＴ１及びＴ２が存在するため、デッドロック検出部１３４は、Ｔ４がスタックに存在しないと判定する。
【００９７】
デッドロック検出部１３４は、ロック状態テーブル１３３を参照して、Ｔ４によって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する。図６に示すロック状態テーブル１３３の例では、Ｔ４によって識別されるスレッドは、Ｌ１のロックを「ロック要求中」である。したがって、デッドロック検出部１３４は、Ｔ４によって識別されるスレッドが「ロック要求中」であるロック（Ｌ１のロック）があると判定する。
【００９８】
この場合、デッドロック検出部１３４は、Ｔ４をスタックに追加する。Ｔ４がスタックに追加されると、デッドロック検出部１３４は、Ｌ１のロックがＴ４によって識別されるスレッド以外のスレッド（他のスレッド）によって取得されているか否かを、ロック状態テーブル１３３を参照して判定する。図６に示すロック状態テーブル１３３の例では、Ｌ１のロックはＴ１によって識別されるスレッドによって取得されている。したがって、デッドロック検出部１３４は、Ｌ１のロックが他のスレッド（Ｔ１によって識別されるスレッド）によって取得されていると判定する。
【００９９】
デッドロック検出部１３４は、Ｔ１がスタックに存在するか否かを判定する。この場合、スタックにはＴ１、Ｔ２及びＴ４が存在するため、デッドロック検出部１３４は、Ｔ１がスタックに存在すると判定する。
【０１００】
このようにＴ１がスタックに存在すると判定された場合、図６に示すように複数のスレッド間（ここでは、Ｔ１、Ｔ２及びＴ４）においてロック中及びロック要求中のループが発生することになる。複数のスレッドの各々は、いずれかのロックに対して「ロック要求中」である場合には当該スレッドが取得しているロックの解放を実行できない。つまり、例えばＴ１（によって識別されるスレッド）はＴ２のロックの解放を、Ｔ２はＴ４のロックの解放を、Ｔ４はＴ１のロックの解放を待っている状態となるため、複数のスレッドが互いに占有している資源の解放を待ち合うことによりデッドロックが発生する。
【０１０１】
したがって、デッドロック検出部１３４は、上記したようにロック中及びロック要求中のループが発生する場合にはデッドロックの発生を検出する。
【０１０２】
なお、デッドロック検出部１３４は、デッドロックの発生を検出した場合、当該デッドロックの発生をＨＡクラスタデーモン１４に通知することを要求する通知要求をデッドロック通知部１３５に出力する。デッドロック通知部１３５は、デッドロック検出部１３４からの通知要求に基づいてデッドロックの発生をＨＡクラスタデーモン１４に通知する。ＨＡクラスタデーモン１４では、当該デッドロック通知部１３５からの通知に応じて例えばフェイルオーバ等の処理が実行される。
【０１０３】
次に、図７を参照して、監視対象アプリケーション１１を構成するスレッドによってロックが取得される際の処理の流れについて説明する。
【０１０４】
まず、監視対象アプリケーション１１を構成するスレッドは、資源を占有するためのロック取得要求をＯＳ１２に対して出力する。このスレッドは、例えば運用系ノードとして動作しているノード１０において実行されているスレッドである。スレッドから出力されるロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
【０１０５】
ジャケットライブラリ１３のＡＰＩフック部１３１は、監視対象アプリケーション１１を構成するスレッドからのロック取得要求をフックする。ＡＰＩフック部１３１は、ロック取得要求がフックされると、ロック状態管理部１３２を実行する（ステップＳ１１）。このとき、ＡＰＩフック部１３１は、フックされたロック取得要求に含まれるロックのアドレス及び当該ロック取得要求に応じてロックの取得が実行される旨（ロック取得の実行）をロック状態管理部１３２に通知する。
【０１０６】
ＡＰＩフック部１３１によってロック状態管理部１３２が実行されると、ロック状態管理部１３２は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッド（つまり、実行中のスレッド）を識別するためのスレッドＩＤをＯＳ１２に問い合わせる。これにより、ロック状態管理部１３２は、ロック取得要求の要求元であるスレッドのスレッドＩＤを取得する（ステップＳ１２）。
【０１０７】
ロック状態管理部１３２は、ＡＰＩフック部１３１から通知されたロックのアドレス及びＯＳ１２に問い合わせることにより取得されたスレッドＩＤにロック状態テーブル１３３において対応付けられているロックの取得状態に更新する。このとき、ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知の内容が「ロック取得の実行」であるため、ロックの取得状態を「ロック要求中」に更新する（ステップＳ１３）。
【０１０８】
次に、ＡＰＩフック部１３１は、デッドロック検出部１３４を実行する（ステップＳ１４）。このとき、ＡＰＩフック部１３１は、フックされたロック取得要求に含まれるロックのアドレスをデッドロック検出部１３４に出力する。
【０１０９】
ＡＰＩフック部１３１によってデッドロック検出部１３４が実行されると、デッドロック検出部１３４は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元となるスレッドのスレッドＩＤを取得し、上記した図５に示すデッドロックの発生の検出処理を実行する（ステップＳ１５）。
【０１１０】
デッドロック検出部１３４によってデッドロックの発生が検出されない場合（ステップＳ１５のＮＯ）、ＡＰＩフック部１３１は、ＯＳ１２のロック取得ＡＰＩ（ロック取得部１２１）を実行する（ステップＳ１６）。このとき、ＡＰＩフック部１３１は、ＯＳ１２にロックのアドレスを出力する。
【０１１１】
ＯＳ１２のロック取得部１２１は、ＡＰＩフック部１３１によって出力されたロックのアドレスに応じて、ロック取得処理を実行する（ステップＳ１７）。このとき、ロック取得部１２１は、例えばロックが既に他のスレッドによって取得されている場合には、当該ロックが解放されるのを待ってからロック取得処理を実行する。ロック取得部１２１は、ロック取得処理が実行されると、ロック取得応答（返り値）を監視対象アプリケーション１１に対して出力する。このロック取得応答には、取得処理が完了されたロックのアドレスが含まれる。
【０１１２】
ジャケットライブラリ１３のＡＰＩフック部１３１は、ＯＳ１２のロック取得部１２１によって出力されたロック取得応答をフックする。ＡＰＩフック部１３１は、ロック取得応答をフックすると、ロック状態管理部１３２を実行する（ステップＳ１８）。このとき、ＡＰＩフック部１３１は、フックされたロック取得応答に含まれるロックのアドレス及び当該ロック取得応答が返された旨（ロック取得の応答）をロック状態管理部１３２に通知する。
【０１１３】
ＡＰＩフック部１３１によってロック状態管理部１３２が実行されると、ロック状態管理部１３２は、ＡＰＩフック部１３１によってフックされたロック取得応答の元となるロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ１２に問い合わせる。これにより、ロック状態管理部１３２は、スレッドＩＤを取得する（ステップＳ１９）。
【０１１４】
ロック状態管理部１３２は、ＡＰＩフック部１３１から通知されたロックのアドレス及びＯＳ１２に問い合わせることにより取得されたスレッドＩＤにロック状態テーブル１３３において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知の内容が「ロック取得の応答」であるため、ロックの取得状態を「ロック中」に更新する（ステップＳ２０）。
【０１１５】
上記したような処理が実行された後、ＡＰＩフック部１３１によりロック取得応答が監視対象アプリケーション１１に返されると処理が終了される。
【０１１６】
一方、ステップＳ１５においてデッドロック検出部１３４によってデッドロックの発生が検出された場合、デッドロック検出部１３４は、デッドロック通知部１３５を実行する（ステップＳ２１）。
【０１１７】
デッドロック検出部１３４によってデッドロック通知部１３５が実行されると、デッドロック通知部１３５は、デッドロックの発生をＨＡクラスタデーモン１４に通知する（ステップＳ２２）。
【０１１８】
デッドロック通知部１３５によってデッドロックの発生が通知されると、ＨＡクラスタデーモン１４は、監視対象アプリケーション１１で障害が発生したものとしてサービスのフェイルオーバ等の対処を行う（ステップＳ２３）。
【０１１９】
なお、上記したステップＳ２３の処理が実行されると、ＨＡクラスタデーモン１４により監視対象アプリケーション１１等の動作が停止される。
【０１２０】
次に、図８を参照して、監視対象アプリケーション１１を構成するスレッドによってロックが解放される際の処理の流れについて説明する。
【０１２１】
まず、監視対象アプリケーション１１を構成するスレッドは、当該スレッドがロックを取得している資源の占有を解放するためのロック解放要求をＯＳ１２に対して出力する。このロック解放要求には、当該ロック解放要求に応じて解放されるロックのアドレスが含まれる。
【０１２２】
ジャケットライブラリ１３のＡＰＩフック部１３１は、監視対象アプリケーション１１を構成するスレッドからのロック解放要求をフックする。ＡＰＩフック部１３１は、ロック解放要求をフックすると、ロック状態管理部１３２を実行する（ステップＳ３１）。このとき、ＡＰＩフック部１３１は、フックされたロック解放要求に含まれるロックのアドレス及び当該ロック解放要求に応じてロックの解放が実行される旨（ロック解放の実行）をロック状態管理部１３２に通知する。
【０１２３】
ここで、前述したように、ＡＰＩフック部１３１からの通知の内容が「ロック解放の実行」である場合には、ロックの取得状態は変更しないためロック状態テーブル１３３の更新は実行されない。
【０１２４】
したがって、ＡＰＩフック部１３１は、ＯＳ１２のロック解放ＡＰＩ（ロック解放部１２２）を実行する（ステップＳ３２）。このとき、ＡＰＩフック部１３１は、ＯＳ１２にロックのアドレスを出力する。
【０１２５】
ＯＳ１２のロック解放部１２１は、ＡＰＩフック部１３１によって出力されたロックのアドレスに応じて、ロック解放処理を実行する（ステップＳ３３）。ロック解放部１２２は、ロック解放処理が実行されると、ロック解放応答（返り値）を監視対象アプリケーション１１に対して出力する。このロック解放応答には、解放処理が完了されたロックのアドレスが含まれる。
【０１２６】
ジャケットライブラリ１３のＡＰＩフック部１３１は、ＯＳ１２のロック解放部１２２によって出力されたロック解放応答をフックする。ＡＰＩフック部１３１は、ロック解放応答をフックすると、ロック状態管理部１３２を実行する（ステップＳ３４）。このとき、ＡＰＩフック部１３１は、フックされたロック解放応答に含まれるロックのアドレス及び当該ロック解放応答が返された旨（ロック解放の応答）をロック状態管理部１３２に通知する。
【０１２７】
ＡＰＩフック部１３１によってロック状態管理部１３２が実行されると、ロック状態管理部１３２は、ＡＰＩフック部１３１によってフックされたロック解放応答の元となるロック解放要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ１２に問い合わせる。これにより、ロック状態管理部１３２は、ロック解放応答の元となるロック解放要求の要求元であるスレッドを識別するためのスレッドＩＤを取得する（ステップＳ３５）。
【０１２８】
ロック状態管理部１３２は、ＡＰＩフック部１３１から通知されたロックのアドレス及びＯＳ１２に問い合わせることにより取得されたスレッドＩＤにロック状態テーブル１３３において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知の内容が「ロック解放の応答」であるため、ロックの取得状態を「ロックなし」に更新する（ステップＳ３６）。
【０１２９】
上記したような処理が実行された後、ＡＰＩフック部１３１によりロック解放応答が監視対象アプリケーション１１に返されると処理が終了される。
【０１３０】
上記したように本実施形態においては、監視対象アプリケーション１１を構成する複数のスレッドからのロック取得要求及びロック解放要求と、ＯＳ１２からのロック取得応答及びロック解放応答をフックし、当該複数のスレッドのロックの取得状態をロック状態テーブル１３３において管理することによって、例えばスレッドからロック取得要求があった場合にデッドロックの発生を検出することが可能となる。
【０１３１】
これにより、本実施形態においては、例えば監視対象アプリケーション１１の状態を監視する外部コマンドを定期的に実行することによって当該監視対象アプリケーション１１で発生した障害を検出するような定期監視と併用することで、検出可能な障害範囲を拡大することが可能となる。したがって、監視対象アプリケーション１１で障害が発生した状態でサービスが継続される可能性を低下させることが可能となり、サービスの信頼性を向上させることが可能となる。
【０１３２】
また、本実施形態においては、デッドロックが発生するタイミング（イベントドリブン）で障害を検出することができるため、上記した定期監視のみで検出できる障害の場合であっても、監視対象アプリケーションで発生した障害を検出するまでの時間を短縮することが可能となる。これにより、サービス停止時間を短縮することが可能となるため、当該サービスの可用性を向上させることができる。
【０１３３】
［第２の実施形態］
次に、図９を参照して、本発明の第２の実施形態について説明する。図９は、本実施形態に係るクラスタシステムに備えられるノード１００の主として機能構成を示すブロック図である。なお、前述した図２と同様の部分には同一参照符号を付してその詳しい説明は省略する。ここでは、図２と異なる部分について主に述べる。以下の実施形態についても同様にして重複した説明を省略する。
【０１３４】
図９に示すように、本実施形態に係るクラスタシステムに備えられるノード１００上では、監視対象アプリケーション、ＯＳ１２０、ジャケットライブラリ１３０ａ及びジャケットライブラリ１３０ｂが動作する。
【０１３５】
前述した第１の実施形態においては、監視対象アプリケーションが１つのプロセスから構成されるものとして説明したが、本実施形態においては、監視対象アプリケーションが複数のプロセスから構成される場合を想定している。つまり、本実施形態においては、ノード１００で監視対象のアプリケーションのプロセス１１０ａ及び１１０ｂを含む複数のプロセスが実行される。以下、監視対象のアプリケーションのプロセス１１０ａを、単にプロセス１１０ａと表記する。同様に、監視対象のアプリケーションのプロセス１１０ｂを、単にプロセス１１０ｂと表記する。
【０１３６】
以下、監視対象アプリケーションを構成する複数のプロセスのうち、プロセス１１０ａ及び１１０ｂについて説明する。プロセス１１０ａ及び１１０ｂ以外のプロセスについては、当該プロセス１１０ａ及び１１０ｂと同様である。
【０１３７】
なお、監視対象アプリケーションを構成するプロセス１１０ａ及び１１０ｂは、複数のスレッドから構成される。
【０１３８】
ＯＳ１２０は、プロセス１１０ａとプロセス１１０ｂと当該プロセス１１０ａ及び１１０ｂを構成する複数のスレッドの各々とを管理する。この場合、ＯＳ１２０は、プロセス１１０ａ及び１１０ｂを識別するためのプロセスＩＤと当該プロセス１１０ａ及び１１０ｂを構成する複数のスレッドの各々を識別するためのスレッドＩＤを用いて実行中のスレッドを管理する。
【０１３９】
ＯＳ１２０は、ロック状態テーブル１２３を含む。このロック状態テーブル１２３は、例えばノード１００に備えられるメモリ（図示せず）内であって、ＯＳ１２０に割り当てられた複数のプロセス間で共有のメモリ空間にその領域が確保されている。
【０１４０】
ロック状態テーブル１２３には、プロセス１１０ａ及び１１０ｂを構成する複数のスレッドによるロックの取得状態が登録される。
【０１４１】
ジャケットライブラリ１３０ａは、プロセス１１０ａを構成する複数のスレッドの各々からのＯＳ１２０に対するロック取得要求及びロック解放要求をフック（取得）することで、当該複数のスレッドの各々によるロックの取得状態を管理する。ジャケットライブラリ１３０ａは、フックされたロック取得要求及び複数のスレッドの各々によるロックの取得状態に基づいてデッドロックの発生を検出する。ジャケットライブラリ１３０ａは、デッドロックの発生が検出された場合、その旨をＨＡクラスタデーモン１４に通知する。
【０１４２】
なお、ジャケットライブラリは、プロセス毎に対応している。つまり、例えばプロセス１１０ａにはジャケットライブラリ１３０ａが対応しており、プロセス１１０ｂにはジャケットライブラリ１３０ｂが対応している。この場合、ジャケットライブラリ１３０ａはプロセス１１０ａからのロック取得要求等に応じた処理を実行し、ジャケットライブラリ１３０ｂはプロセス１１０ｂからのロック取得要求等に応じた処理を実行する。
【０１４３】
以下、主にジャケットライブラリ１３０ａの構成等について説明するが、ジャケットライブラリ１３０ｂについても当該ジャケットライブラリ１３０ａと同様である。
【０１４４】
ジャケットライブラリ１３０ａは、ロック状態管理部１３６及びデッドロック検出部１３７を含む。
【０１４５】
本実施形態において、ロック状態管理部１３６及びデッドロック検出部１３７は、ノード１００のコンピュータ（図示せず）が例えばノード１００に備えられるメモリに格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
【０１４６】
ロック状態管理部１３６は、ＡＰＩフック部１３１によってフックされたロック取得要求またはロック解放要求の要求元であるスレッド（を含む複数のスレッド）から構成される）プロセス１１０ａを識別するためのプロセスＩＤを、ＯＳ１２０に問い合わせる。これにより、ロック状態管理部１３６は、プロセスＩＤを取得する。
【０１４７】
また、ロック状態管理部１３６は、ＡＰＩフック部１３１からの通知を受けると、ロック取得要求またはロック解放要求の要求元であるスレッドを識別するためのスレッドＩＤを、ＯＳ１２０に問い合わせる。これにより、ロック状態管理部１３６は、スレッドＩＤを取得する。
【０１４８】
ロック状態管理部１３６は、ＡＰＩフック部１３１からの通知、取得されたプロセスＩＤ及びスレッドＩＤに基づいてロック状態テーブル１２３を更新する。つまり、本実施形態においては、前述した第１の実施形態とは異なり、プロセスＩＤ、スレッドＩＤ及びロックのアドレスの３次元の組み合わせに対してロックの取得状態が管理（登録）される。
【０１４９】
なお、ロック状態テーブル１２３には、上記したようにプロセス１１０ａ及び１１０ｂを構成する複数のスレッドによるロックの取得状態が登録されるが、ジャケットライブラリ１３０ａのロック状態管理部１３６は、プロセス１１０ａを構成する複数のスレッドによるロックの取得状態をロック状態テーブル１２３に登録（更新）する。つまり、プロセス１１０ｂを構成する複数のスレッドによるロックの取得状態は、ジャケットライブラリ１３０ｂのロック状態管理部（図示せず）によって登録される。
【０１５０】
ロック状態管理部１３６は、更新するプロセスＩＤ、スレッドＩＤまたはロックのアドレスがロック状態テーブル１２３に登録されていないときは当該ロック状態テーブル１２３を拡張する。
【０１５１】
デッドロック検出部１３７は、ＡＰＩフック部１３１からの要求に基づいて、ロックの取得によってデッドロックが発生するか否かを確認する。これにより、デッドロック検出部１３７は、デッドロックの発生を検出する。
【０１５２】
このとき、デッドロック検出部１３７は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッドから構成されるプロセス１１０ａを識別するためのプロセスＩＤをＯＳ１２０に問い合わせる。これにより、デッドロック検出部１３７は、プロセス１１０ａのプロセスＩＤを取得する。また、デッドロック検出部１３７は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ１２０に問い合わせることにより、当該スレッドＩＤを取得する。
【０１５３】
デッドロック検出部１３７は、取得されたプロセスＩＤ、スレッドＩＤ及びＡＰＩフック部１３１によって出力されたロックのアドレスと、ロック状態テーブル１２３に登録されているロック取得状態とに基づいて、デッドロックの発生を検出する。デッドロックの発生が検出された場合、デッドロック検出部１３７は、デッドロック通知部１３５に当該デッドロックの発生の通知要求を出力する。
【０１５４】
なお、ジャケットライブラリ１３０ｂの構成については、上記したようにジャケットライブラリ１３０ａと同様の構成であるため、図９において省略されている。また、ジャケットライブラリ１３０ｂの構成の詳しい説明は省略する。
【０１５５】
次に、図１０を参照して、プロセス１１０ａを構成するスレッドによってロックが取得される際の処理の流れについて説明する。
【０１５６】
まず、プロセス１１０ａを構成するスレッドは、資源を占有するためのロック取得要求をＯＳ１２０に対して出力する。このロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
【０１５７】
次に、前述した図７に示すステップＳ１１の処理に相当するステップＳ４１の処理が実行される。
【０１５８】
ロック状態管理部１３６は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッドから構成されるプロセス１１０ａを識別するためのプロセスＩＤをＯＳ１２０に問い合わせる。これにより、ロック状態管理部１３６は、プロセス１１０ａのプロセスＩＤを取得する（ステップＳ４２）。
【０１５９】
ステップＳ４２の処理が実行されると、前述した図７に示すステップＳ１２の処理に相当するステップＳ４３の処理が実行される。
【０１６０】
ロック状態管理部１３６は、ＡＰＩフック部１３１から通知されたロックのアドレス、ステップＳ４２において取得されたプロセスＩＤ及びステップＳ４３において取得されたスレッドＩＤに対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部１３２は、ＡＰＩフック部１３１からの通知の内容が「ロック取得の実行」であるため、ロック状態テーブル１２３におけるロックの取得状態を「ロック要求中」に更新する（ステップＳ４４）。
【０１６１】
次に、デッドロック検出部１３７は、デッドロックの発生の検出処理を実行する（ステップＳ４６）。このとき、デッドロック検出部１３７は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッドを含むプロセス１１０ａを識別するためのプロセスＩＤをＯＳ１２０に問い合わせることにより、当該プロセスＩＤを取得する。また、デッドロック検出部１３７は、ＡＰＩフック部１３１によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ１２０に問い合わせることにより、当該スレッドＩＤを取得する。デッドロック検出部１３７は、取得されたプロセスＩＤ、スレッドＩＤ、ＡＰＩフック部１３１によって出力されたロックのアドレス及びロック状態テーブル１２３に登録されているロックの取得状態に基づいてデッドロックの発生を検出する。このロック状態テーブル１２３には、プロセス１１０ａ及び１１０ｂを含む複数のプロセスを構成するスレッドによるロックの取得状態が登録されている。
【０１６２】
なお、デッドロック検出部１３７によるデッドロックの発生の検出処理は、前述した図５に示す処理において例えばプロセスＩＤ及びスレッドＩＤの組をＴ、ロックのアドレスをＬとした場合と同様であるため、その詳しい説明は省略する。
【０１６３】
デッドロック検出部１３７によってデッドロックの発生が検出されない場合（ステップＳ４６のＮＯ）、前述した図７に示すステップＳ１６〜ステップＳ１８の処理に相当するステップＳ４７〜ステップＳ４９の処理が実行される。
【０１６４】
次に、ロック状態管理部１３６は、ＡＰＩフック部１３１によってフックされたロック取得応答の元となるロック取得要求の要求元であるスレッドから構成されるプロセス１１０ａを識別するためのプロセスＩＤをＯＳ１２０に問い合わせる。これにより、ロック状態管理部１３６は、プロセス１１０ａのプロセスＩＤを取得する（ステップＳ５０）。
【０１６５】
ステップＳ５０の処理が実行されると、前述した図７のステップＳ１９の処理に相当するステップＳ５１の処理が実行される。
【０１６６】
ロック状態管理部１３６は、ＡＰＩフック部１３１から通知されたロックのアドレス、取得されたプロセスＩＤ及びスレッドＩＤにロック状態テーブル１２３において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部１３６は、ＡＰＩフック部１３１からの通知の内容が「ロック取得の応答」であるため、ロック状態テーブル１２３におけるロックの取得状態を「ロック中」に更新する（ステップＳ２０）。
【０１６７】
一方、ステップＳ４６においてデッドロック検出部１３７によってデッドロックの発生が検出された場合、前述した図７に示すステップＳ２１〜ステップＳ２３の処理に相当するステップＳ５３〜ステップＳ５５の処理が実行される。
【０１６８】
なお、プロセス１１０ｂを構成するスレッドによってロックが取得される場合には、上記した図１０に示す処理と同様の処理がジャケットライブラリ１３０ｂにおいて実行されるため、その詳しい説明は省略する。
【０１６９】
次に、図１１を参照して、プロセス１１０ａを構成するスレッドによってロックが解放される際の処理の流れについて説明する。
【０１７０】
まず、プロセス１１０ａを構成するスレッドは、当該スレッドがロックを取得している資源の占有を解放するためのロック解放要求をＯＳ１２０に対して出力する。このロック解放要求には、当該ロック解放要求に応じて解放されるロックのアドレスが含まれる。
【０１７１】
次に、前述した図８に示すステップＳ３１〜ステップＳ３４の処理に相当するステップＳ６１〜ステップＳ６４の処理が実行される。
【０１７２】
ロック状態管理部１３６は、ＡＰＩフック部１３１によってフックされたロック解放応答の元となるロック解放要求の要求元であるスレッドから構成されるプロセス１１０ａを識別するためのプロセスＩＤをＯＳ１２０に問い合わせる。これにより、ロック状態管理部１３６は、プロセス１１０ａのプロセスＩＤを取得する（ステップＳ６５）。
【０１７３】
ステップＳ６５の処理が実行されると、前述した図８に示すステップＳ３５の処理に相当するステップＳ６６の処理が実行される。
【０１７４】
次に、ロック状態管理部１３６は、ＡＰＩフック部１３１から通知されたロックのアドレス、ステップＳ６５において取得されたプロセスＩＤ及びステップＳ６６において取得されたスレッドＩＤにロック状態テーブル１２３において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部１３６は、ＡＰＩフック部１３１からの通知の内容が「ロック解放の応答」であるため、ロック状態テーブル１２３におけるロックの取得状態を「ロックなし」に更新する（ステップＳ６７）。
【０１７５】
なお、プロセス１１０ｂを構成するスレッドによってロックが解放される場合には、上記した図１１に示す処理と同様の処理がジャケットライブラリ１３０ｂにおいて実行されるため、その詳しい説明は省略する。
【０１７６】
上記したように本実施形態においては、監視対象アプリケーションを構成する複数のプロセス（プロセス１１０ａ及びプロセス１１０ｂ）を構成する複数のスレッドからのロック取得要求及びロック解放要求と、ＯＳ１２０からのロック取得応答及びロック解放応答とをフックし、当該複数のスレッドのロックの取得状態をロック状態テーブル１２３において管理することによって例えばスレッドからロック取得要求があった場合にデッドロックの発生を検出することが可能となる。つまり、本実施形態においては、前述した第１の実施形態とは異なり、例えば監視対象アプリケーションを構成する複数のプロセス間のデッドロックもイベントドリブンで検出すること可能となる。これにより、本実施形態は、例えばマルチプロセスのアプリケーションに対しても適用することができる。
【０１７７】
［第３の実施形態］
次に、図１２を参照して、本発明の第３の実施形態について説明する。図１２は、本実施形態に係るクラスタシステムに備えられるノード２００の機能構成を示すブロック図である。
【０１７８】
ノード２００上では、ＯＳ２１０及びジャケットライブラリ２２０が動作する。ＯＳ２１０は、ロック作成部２１１及びスレッド作成部２１２を含む。
【０１７９】
スレッド作成部２１１は、例えば監視対象アプリケーション１１からのスレッド作成要求に応じて、当該監視対象アプリケーション１１を構成するスレッドを作成する。このスレッド作成要求は、スレッドを開始する関数のアドレス（以下、関数アドレスと表記）を指定することにより行われる。また、スレッド作成要求は、例えば監視対象アプリケーション１１が起動された際に適宜出力される。スレッド作成部２１１は、スレッド作成要求に応じてスレッドが作成された場合、当該スレッド作成要求に対する応答として当該スレッドを識別するためのスレッドＩＤを監視対象アプリケーション１１に対して返す。
【０１８０】
ロック作成部２１２は、例えば監視対象アプリケーション１１を構成する複数のスレッドからのロック作成要求に応じて、資源を占有するためのロックを新たに作成する。このロック作成要求は、例えば上記したスレッド作成部２１１によってスレッドが作成された後に、当該スレッドから必要に応じて出力される。ロック作成部２１２は、ロック作成要求に応じてロックが作成された場合、当該ロック作成要求に対する応答として当該ロックのアドレスを監視対象アプリケーション１１に対して返す。
【０１８１】
図１２に示すように、ジャケットライブラリ２２０は、ＡＰＩフック部２２１、ロック／スレッド対応付け部２２２、スレッド対応テーブル２２３、ロック対応テーブル２２４、デッドロック検出部２２５、デッドロック情報作成部２２６、デッドロック情報読込部２２７、サスペンド判定部２２８を含む。
【０１８２】
本実施形態において、ＡＰＩフック部２２１、ロック／スレッド対応付け部２２２、デッドロック検出部２２５、デッドロック情報作成部２２６、デッドロック情報読込部２２７及びサスペンド判定部２２８は、ノード２００のコンピュータ（図示せず）が例えばノード２００に備えられるメモリ（図示せず）に格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
【０１８３】
また、本実施形態において、スレッド対応テーブル２２３及びロック対応テーブル２２４は、例えばノード２００に備えられるメモリ内であって、監視対象アプリケーション１１（を構成するプロセス）に与えられたメモリ空間にその領域が確保されている。
【０１８４】
ＡＰＩフック部２２１は、監視対象アプリケーション１１からのＯＳ２１０に対するスレッド作成要求及びロック作成要求をフックする。ＡＰＩフック部２２１は、フックされたスレッド作成要求及びロック作成要求をＯＳ２１０に出力する。
【０１８５】
ＡＰＩフック部２２１は、スレッド作成要求に応じてスレッドが作成された後に、当該スレッド作成要求に対する応答をフックする。このフックされた応答には、スレッド作成要求に応じて作成されたスレッドを識別するためのスレッドＩＤが含まれる。ＡＰＩフック部２２１は、フックされた応答に含まれるスレッドＩＤをロック／スレッド対応付け部２２２に対して出力することで、当該ロック／スレッド対応付け部２２２にスレッド対応テーブル２２３の更新を要求する。
【０１８６】
また、ＡＰＩフック部２２１は、ロック作成要求に応じてロックが作成された後に、当該ロック作成要求に対する応答をフックする。このフックされた応答には、ロック作成要求に応じて作成されたロックのアドレスが含まれる。ＡＰＩフック部２２１は、フックされた応答に含まれるロックのアドレスをロック／スレッド対応付け部２２２に対して出力することで、当該ロック／スレッド対応付け部２２２にロック対応テーブル２２４の更新を要求する。
【０１８７】
ＡＰＩフック部２２１は、ロック取得要求がフックされた場合、当該ロック取得要求に含まれるロックのアドレスをサスペンド判定部２２８に出力することにより、当該ロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かの判定を要求する。
【０１８８】
ロック／スレッド対応付け部２２２は、ＡＰＩフック部２２１からの要求に応じてスレッド対応テーブル２２３を更新する。また、ロック／スレッド対応付け部２２２は、ＡＰＩフック部２２１からの要求に応じてロック対応テーブル２２４を更新する。
【０１８９】
スレッド対応テーブル２２３には、ＯＳ２１０のスレッド作成部２１１によって作成されたスレッドを識別するためのスレッドＩＤと当該スレッドを開始するときの関数アドレスとの組み合わせの情報が保持される。この関数アドレスは、上記したスレッド作成要求において指定される。
【０１９０】
ロック対応テーブル２２４は、ＯＳ２１０のロック作成部２１２によって作成されたロックのアドレスと当該ロックを作成したスレッド（ロック作成要求の要求元となるスレッド）を識別するためのスレッドＩＤとの組み合わせの情報が保持される。
【０１９１】
デッドロック検出部２２５は、デッドロックの発生が検出された場合、デッドロック情報作成部２２６に対して当該デッドロックを示すデッドロック状況情報の作成を要求する。
【０１９２】
デッドロック情報作成部２２６は、デッドロック検出部２２５からの要求に応じて、デッドロック検出部２２５によって検出されたデッドロックを示すデッドロック状況情報を作成する。このとき、デッドロック情報作成部２２６は、スレッド対応テーブル２２３、ロック対応テーブル２２４及びロック状態テーブル１３３を参照して作成処理を実行する。デッドロック情報作成部２２６は、作成されたデッドロック状況情報を共有ディスク３０に格納する。
【０１９３】
デッドロック情報読込部２２７は、サスペンド判定部２２８の要求に応じて、共有ディスク３０に格納されているデッドロック状況情報を読み込む。デッドロック情報読込部２２７は、共有ディスク３０から読み込まれたデッドロック状況情報をサスペンド判定部２２８に出力する。
【０１９４】
サスペンド判定部２２８は、ＡＰＩフック部２２１からの要求を受けると、ＡＰＩフック部２２１によってフックされたロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かを判定する。このとき、サスペンド判定部２２８は、スレッド対応テーブル２２３、ロック対応テーブル２２４及びロック状態テーブル１３３を参照して判定処理を実行する。また、サスペンド判定部２２８は、デッドロック情報読込部２２７によって出力されたデッドロック状況情報に基づいて判定処理を実行する。サスペンド判定部２２８の処理の詳細については後述する。
【０１９５】
図１３は、図１２に示すスレッド対応テーブル２２３のデータ構造の一例を示す。図１３に示すように、スレッド対応テーブル２２３には、スレッドを開始するときの関数アドレス（スレッド開始時の関数アドレス）及び当該スレッドを識別するためのスレッドＩＤが対応付けて保持される。
【０１９６】
つまり、スレッド対応テーブル２２３には、スレッド作成要求において指定された関数アドレス及び当該スレッド作成要求に応じて作成されたスレッドのスレッドＩＤが対応付けて保持される。
【０１９７】
また、例えば同一の関数アドレスから開始されるスレッドが複数存在する場合には、当該スレッドのスレッドＩＤは当該スレッドの作成順にスレッド対応テーブル２２３において保持される。
【０１９８】
なお、上記したようにスレッド対応テーブル２２３は、監視対象アプリケーション１１からスレッド作成要求が出力され、当該スレッド作成要求に応じてスレッドが作成された際にロック／スレッド対応付け部２２２によって更新される。
【０１９９】
図１３に示す例では、スレッド対応テーブル２２３には、スレッド開始時の関数アドレス「Ｆ１」に対応付けてスレッドＩＤ「Ｔ１→Ｔ２」が保持されている。これによれば、スレッド開始時の関数アドレスが「Ｆ１」であるスレッドを識別するスレッドＩＤが「Ｔ１」及び「Ｔ２」であることが示される。また、Ｔ１によって識別されるスレッド、Ｔ２によって識別されるスレッドの順に当該スレッドが作成されたことが示される。
【０２００】
また、スレッド対応テーブル２２３には、スレッド開始時の関数アドレス「Ｆ２」に対応付けてスレッドＩＤ「Ｔ３→Ｔ４→Ｔ５」が保持されている。これによれば、スレッド開始時の関数アドレスが「Ｆ２」であるスレッドを識別するスレッドＩＤが「Ｔ３」、「Ｔ４」及び「Ｔ５」であることが示される。また、Ｔ３によって識別されるスレッド、Ｔ４によって識別されるスレッド、Ｔ５によって識別されるスレッドの順に当該スレッドが作成されたことが示される。
【０２０１】
なお、スレッド対応テーブル２２３は、例えば監視対象アプリケーション１１が再起動された場合またはフェイルオーバが実行され、運用系ノードの処理を引き継ぐために監視対象アプリケーション１１が起動された場合等に、スレッドを前回の起動時と対応付けるために用いられる。したがって、同一の関数アドレスで開始されるスレッドの作成順序が異なる場合にはスレッドの対応付けに失敗するが、一般的なアプリケーションでは同一の関数のスレッド作成順序は同一となる実装であることが多い。特にＨＡクラスタシステムでは、サービスを継続するため、引継ぎ後も引継ぎ前と同じ動作をするように設定している場合がほとんどであるので、スレッド作成順序は同一となる。よって、本実施形態においては、同一の関数アドレスで開始されるスレッドの作成順序は同一であることを前提としている。
【０２０２】
図１４は、図１２に示すロック対応テーブル２２４のデータ構造の一例を示す。図１４に示すように、ロック対応テーブル２２４には、監視対象アプリケーション１１を構成するスレッドを識別するためのスレッドＩＤ及び当該スレッドからのロック作成要求に応じてロック作成部２１２によって作成されたロックのアドレスが対応付けて保持されている。
【０２０３】
また、例えば同一のスレッドからのロック作成要求に応じてロック作成部２１２によって作成されたロックのアドレスが複数存在する場合には、ロックのアドレスは作成順にロック対応テーブル２２４において保持される。
【０２０４】
なお、上記したようにロック対応テーブル２２４は、監視対象アプリケーション１１を構成するスレッドからロック作成要求が出力され、当該ロック作成要求に応じてロックが作成された際にロック／スレッド対応付け部２２２によって更新される。
【０２０５】
図１４に示す例では、ロック対応テーブル２２４には、スレッドＩＤ「Ｔ１」に対応付けてロックのアドレス「Ｌ１→Ｌ２」が保持されている。これによれば、ロックのアドレスが「Ｌ１」及び「Ｌ２」であるロックが、スレッドＩＤ「Ｔ１」によって識別されるスレッドからのロック作成要求に応じて作成されたことが示される。また、ロックのアドレスが「Ｌ１」であるロック、ロックのアドレスが「Ｌ２」であるロックの順に当該ロックが作成されたことが示される。
【０２０６】
また、ロック対応テーブル２２４には、スレッドＩＤ「Ｔ２」に対応付けてロックのアドレス「Ｌ３→Ｌ４→Ｌ５」が保持されている。これによれば、ロックのアドレスが「Ｌ３」、「Ｌ４」及び「Ｌ５」であるロックが、スレッドＩＤ「Ｔ２」によって識別されるスレッドからのロック作成要求に応じて作成されたことが示される。また、ロックのアドレスが「Ｌ３」であるロック、ロックのアドレスが「Ｌ４」であるロック、ロックのアドレスが「Ｌ５」であるロックの順に当該ロックが作成されたことが示されている。
【０２０７】
なお、上記したスレッド対応テーブル２２３と同様に、ロック対応テーブル２２４においても、同一のスレッドにおけるロックの作成順序は同一であることを前提としている。
【０２０８】
図１５は、共有ディスク３０に格納されるデッドロック状況情報のデータ構造の一例を示す。デッドロック状況情報には、スレッド、他のスレッドを止めているロック（ロック中であるロック）及び取得要求中のロックが対応付けて含まれる。また、デッドロック状況情報においては、当該デッドロック状況情報に含まれるスレッド、他のスレッドを止めているロック及び取得要求中のロックは、スレッドＩＤ及びロックのアドレスを用いることなく、上記した図１３及び図１４に示すような関数アドレス及びスレッド及びロックの作成順を用いて示される。ここでは、適宜図１３及び図１４を用いて説明する。
【０２０９】
ここで、図１５に示すデッドロック状況情報は、前述した図６に示すロックの取得状態のようなデッドロック（図６のデッドロック）を示すものとする。
【０２１０】
図１５に示すように、図６のデッドロックを示すデッドロック状況情報には、スレッドとして「Ｆ１の１番目」、他のスレッドを止めているロックとして「Ｆ１の１番目のスレッドの１番目」、取得要求中のロックとして「Ｆ１の２番目のスレッドの１番目」が対応付けて含まれる。
【０２１１】
この「Ｆ１の１番目」は、スレッド対応テーブル２２３において関数アドレス「Ｆ１」に対応付けられているスレッドＩＤによって識別されるスレッドであって、１番目に作成されたスレッドを表している。つまり、図１４に示すスレッド対応テーブル２２３の例では、Ｔ１によって識別されるスレッドを表している。
【０２１２】
「Ｆ１の１番目のスレッドの１番目」は、図１５に示すロック対応テーブル２２４において上記した「Ｆ１の１番目のスレッド（ここでは、Ｔ１によって識別されるスレッド）」に対応付けられているロック（のアドレス）であって、１番目に作成されたロック（ここでは、ロックのアドレスが「Ｌ１」であるロック）を表している。
【０２１３】
「Ｆ１の２番目のスレッドの１番目」は、同様に、図１５に示すロック対応テーブル２２４において「Ｆ１の２番目のスレッド（ここでは、Ｔ２によって識別されるスレッド）」に対応付けられているロックであって、１番目に作成されたロック（ここでは、ロックのアドレスが「Ｌ３」であるロック）を表している。
【０２１４】
図１５における上記した以外のスレッド、他のスレッドを止めているロック及び取得要求中のロックについても同様である。
【０２１５】
デッドロック状況情報においては、デッドロックを上記したような表し方を用いることで、例えば複数のノード２００間において同一のスレッドであるにもかかわらず異なるスレッドＩＤが付与された場合等であっても、スレッドが作成された順を用いることで異なるノード間においてもスレッドの対応付けが可能となる。また、ロック（のアドレス）についても同様である。
【０２１６】
次に、図１６を参照して、上記した新たにスレッドが作成される処理（スレッド作成処理）の流れについて説明する。このスレッド作成処理は、例えばノード２００において監視対象アプリケーション１１が再起動された場合やフェイルオーバが実行され、待機系ノードとして動作していたノード２００が運用系ノードとして動作する際に監視対象アプリケーション１１が起動された場合等に実行される。
【０２１７】
まず、例えば監視対象アプリケーション１１が起動されると、当該監視対象アプリケーション１１は、スレッドの作成を要求するためにスレッド作成要求をＯＳ２１０に対して出力する。このスレッド作成要求は、監視対象アプリケーション１１がスレッドを開始するときの関数アドレスを指定することにより行う。
【０２１８】
ジャケットライブラリ２２０のＡＰＩフック部２２１は、監視対象アプリケーション１１からのスレッド作成要求をフックする。ＡＰＩフック部２２１は、スレッド作成要求がフックされると、ＯＳ２１０のスレッド作成ＡＰＩ（スレッド作成部２１１）を実行する（ステップＳ７１）。このとき、ＡＰＩフック部２２１は、スレッド作成要求をスレッド作成部２１１に出力する。
【０２１９】
ＯＳ２１０のスレッド作成部２１１は、ＡＰＩフック部２２１によって出力されたスレッド作成要求に応じて、スレッドの作成処理を実行する（ステップＳ７２）。このとき、スレッド作成部２１１は、スレッド作成要求において指定された関数アドレスに基づいてスレッドを作成する。
【０２２０】
スレッド作成部２１１は、スレッドの作成処理が実行されると、当該作成されたスレッドを識別するためのスレッドＩＤを、スレッド作成要求に対する応答として監視対象アプリケーション１１に対して出力する。
【０２２１】
ジャケットライブラリ２２０のＡＰＩフック部２２１は、ＯＳ２１０（のスレッド作成部２１１）からのスレッドＩＤ（スレッド作成要求に対する応答）をフックする。ＡＰＩフック部２２１は、スレッドＩＤがフックされると、ロック／スレッド対応付け部２２２を実行する（ステップＳ７３）。このとき、ＡＰＩフック部２２１は、フックされたスレッドＩＤを、ロック／スレッド対応付け部２２２に対して出力する。
【０２２２】
ＡＰＩフック部２１１によってロック／スレッド対応付け部２２２が実行されると、ロック／スレッド対応付け部２２２は、スレッド対応テーブル２２３を更新する（ステップＳ７４）。ロック／スレッド対応付け部２２２は、スレッド作成要求において指定された関数アドレス及びＡＰＩフック部２２１によって出力されたスレッドＩＤを対応付けてスレッド対応テーブル２２３に登録する。
【０２２３】
上記した処理が実行された後、ＡＰＩフック部２２１によりスレッド作成要求に対する応答としてのスレッドＩＤが監視対象アプリケーション１１に返されると処理が終了される。
【０２２４】
次に、図１７を参照して、上記した新たにロックが作成される処理（ロック作成処理）の流れについて説明する。このロック作成処理は、例えば上記したスレッド作成処理においてスレッドが作成された後に実行される。
【０２２５】
まず、例えば上記した図１６に示すようにスレッドが作成されると、当該スレッドは、必要に応じて新たなロックの作成を要求するためにロック作成要求を出力する。
【０２２６】
ジャケットライブラリ２２０のＡＰＩフック部２２１は、監視対象アプリケーション１１からのロック作成要求をフックする。ＡＰＩフック部２２１は、ロック作成要求がフックされると、ＯＳ２１０のロック作成ＡＰＩ（ロック作成部２１２）を実行する（ステップＳ８１）。このとき、ＡＰＩフック部２２１は、ロック作成要求をロック作成部２１２に出力する。
【０２２７】
ＯＳ２１０のロック作成部２１２は、ＡＰＩフック部２２１によって出力されたロック作成要求に応じて、ロックの作成処理を実行する（ステップＳ８２）。
【０２２８】
ロック作成部２１２は、ロックの作成処理が実行されると、当該作成されたロックのアドレスを、ロック作成要求に対する応答として監視対象アプリケーション１１に対して出力する。
【０２２９】
ＡＰＩフック部２２１は、ＯＳ２１０（ロック作成部２１２）からのロックのアドレス（ロック作成要求に対する応答）をフックする。ＡＰＩフック部２２１は、ロックのアドレスがフックされると、ロック／スレッド対応付け部２２２を実行する（ステップＳ８３）。このとき、ＡＰＩフック部２２１は、フックされたロックのアドレスを、ロック／スレッド対応付け部２２２に対して出力する。
【０２３０】
ＡＰＩフック部２１１によってロック／スレッド対応付け部２２２が実行されると、ロック／スレッド対応付け部２２２は、ロック作成要求の要求元となるスレッドを識別するためのスレッドＩＤをＯＳ２１０に対して問い合わせる。これにより、ロック／スレッド対応付け部２２２は、ロック作成要求の要求元となるスレッドのスレッドＩＤを取得する（ステップＳ８４）。
【０２３１】
次に、ロック／スレッド対応付け部２２２は、ロック対応テーブル２２４を更新する（ステップＳ８５）。ロック／スレッド対応付け部２２２は、ＡＰＩフック部２２１によって出力されたロックのアドレス及び取得されたスレッドＩＤを対応付けてロック対応テーブル２２４に登録する。
【０２３２】
上記した処理が実行された後、ＡＰＩフック部２２１によりロック作成要求に対する応答としてロックのアドレスが監視対象アプリケーション１１に返されると処理が終了される。
【０２３３】
次に、図１８を参照して、監視対象アプリケーション１１を構成するスレッドによってロックが取得される際の処理の流れについて説明する。
【０２３４】
まず、監視対象アプリケーション１１を構成するスレッドは、資源を占有するためのロック取得要求をＯＳ２１０に対して出力する。このロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
【０２３５】
ジャケットライブラリ２２０のＡＰＩフック部２２１は、監視対象アプリケーション１１を構成するスレッドからのロック取得要求をフックする。ＡＰＩフック部２２１は、ロック取得要求がフックされると、サスペンド判定部２２８を実行する（ステップＳ９１）。このとき、ＡＰＩフック部２２１は、フックされたロック取得要求に含まれるロックのアドレスをサスペンド判定部２２８に出力する。
【０２３６】
ＡＰＩフック部２２１によってサスペンド判定部２２８が実行されると、サスペンド判定部２２８は、ＡＰＩフック部２２１によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤをＯＳ２１０に問い合わせる。これにより、サスペンド判定部２２８は、ロック取得要求の要求元であるスレッドのスレッドＩＤを取得する（ステップＳ９２）。
【０２３７】
サスペンド判定部２２８は、ＡＰＩフック部２２１によって出力されたロックのアドレス、取得されたスレッドＩＤ及び共有ディスク３０に格納されているデッドロック状況情報に基づいて、ロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かを判定する処理（以下、サスペンド判定処理と表記）を実行する（ステップＳ９３）。このとき、サスペンド判定部２２８は、スレッド対応テーブル２２３、ロック対応テーブル２２４及びロック状態テーブル１３３を参照してサスペンド判定処理を実行する。このサスペンド判定処理の詳細については後述する。
【０２３８】
次に、前述した図７に示すステップＳ１１〜ステップＳ２０に相当するステップＳ９４〜ステップＳ１０３の処理が実行され、処理が終了される。
【０２３９】
一方、ステップＳ９８においてデッドロック検出部２２５によってデッドロックの発生が検出されたと判定された場合、デッドロック検出部２２５は、デッドロック情報作成部２２６を実行する（ステップＳ１０４）。デッドロック検出部２２５は、デッドロック情報作成部２２６に対して、デッドロック状況情報の作成を要求する。
【０２４０】
このとき、デッドロック検出部２２５によってデッドロックの発生が検出されているため、ロック状態テーブル１３３に登録されているロックの取得状態はデッドロックを表している。よって、デッドロック情報作成部２２６は、ロック状態テーブル１３３に登録されているロックの取得状態に基づいて、デッドロックを示すデッドロック状況情報を作成する。このとき、デッドロック情報作成部２２６は、スレッド対応テーブル２２３及びロック対応テーブル２２４を参照して、上記した図１５に示すように関数アドレス及びスレッド及びロックの作成順を用いてデッドロック状況情報を作成する。
【０２４１】
デッドロック情報作成部２２６は、作成されたデッドロック状況情報を共有ディスク３０に格納する。
【０２４２】
次に、前述した図７に示すステップＳ２１〜ステップＳ２３の処理に相当するステップＳ１０６〜ステップＳ１０８の処理が実行され、処理が終了される。
【０２４３】
次に、図１９のフローチャートを参照して、上記したサスペンド判定部２２８によるサスペンド判定処理の処理手順について説明する。
【０２４４】
このサスペンド判定部２２８によるサスペンド判定処理は、上記したようにサスペンド判定部２２８がＡＰＩフック部２２１からの要求を受けると実行される。ＡＰＩフック部２２１は、監視対象アプリケーション１１からのロック取得要求がフックされた場合にサスペンド判定部２２８に対して要求を出力する。このとき、サスペンド判定部２２８は、ＡＰＩフック部２２１からロック取得要求に含まれるロックのアドレスを取得する。
【０２４５】
サスペンド判定部２２８は、デッドロック情報読込部２２７によって共有ディスク３０からデッドロック状況情報が読み込まれている（読み込み済）か否かを判定する（ステップＳ１１１）。
【０２４６】
デッドロック状況情報が読み込まれていないと判定された場合（ステップＳ１１１のＮＯ）、サスペンド判定部２２８は、デッドロック情報読込部２２７を実行する（ステップＳ１１２）。サスペンド判定部２２８は、デッドロック情報読込部２２７に対して、デッドロック状況情報の読み込みを要求する。デッドロック情報読込部２２７は、サスペンド判定部２２８からの要求に応じて共有ディスク３０に格納されているデッドロック状況情報を読み込む。
【０２４７】
サスペンド判定部２２８は、デッドロック情報読込部２２７によって読み込まれたデッドロック状況情報を取得する（ステップＳ１１３）。
【０２４８】
次に、サスペンド判定部２２８は、ＡＰＩフック部２２１によってフックされたロック取得要求に応じたロック取得処理をサスペンドすべきか否かを判定する（ステップＳ１１４）。
【０２４９】
サスペンド判定部２２８は、例えば予め定められた第１及び第２の条件を満たす場合に例えば今後デッドロックが発生する可能性があるとして、ロック取得処理をサスペンドすべきと判定する。このとき、サスペンド判定部２２８は、取得されたロックのアドレス、スレッドＩＤ及びデッドロック状況情報に基づいて判定処理を実行する。また、サスペンド判定部２２８は、スレッド対応テーブル２２３、ロック対応テーブル２２４及びロック状態テーブル１３３を参照して判定処理を実行する。なお、ここでは条件が２つ（第１及び第２の条件）であるものとして説明するが、当該条件は２つに限られない。つまり、条件は、２つ以上であっても構わない。以下、第１及び第２の条件の一例について説明する。
【０２５０】
なお、サスペンド判定部２２８による判定処理においては、取得されたスレッドＩＤによって識別されるスレッドがデッドロック状況情報に含まれるスレッドである、つまり、当該スレッドがデッドロック状況情報によって示されるデッドロック時に実行中であることを前提としている。また、ＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロック（取得されたスレッドＩＤ及びロックのアドレスの組み合わせによるロックの取得状態）がデッドロック状況情報に含まれる他のスレッドを止めている（止めることになる）ロックであることを前提としている。
【０２５１】
上記した第１の条件は、取得されたデッドロック状況情報において、取得されたスレッドＩＤによって識別されるスレッドに対応付けられている「取得要求中のロック」を止めることになるロック（デッドロック状況情報に含まれる「他のスレッドを止めているロック」）が、当該ロックに対応付けられている「スレッド」によって取得されていることである。
【０２５２】
また、上記した第２の条件は、ＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロックによって止められることになるデッドロック状況情報に含まれる「取得要求中のロック」に対応付けられているスレッドが、当該スレッドに対応付けて当該デッドロック状況情報に含まれる「他のスレッドを止めているロック」を取得していることである。
【０２５３】
サスペンド判定部２２８は、上記した第１及び第２の条件を満たす場合には、取得されたデッドロック状況情報によって示されるデッドロックと同じ状況に陥る可能性があると判定する。よって、この場合には、ＡＰＩフック部２２１によってフックされたロック取得要求に応じたロック取得処理をサスペンドすべきであると判定される。
【０２５４】
ここで、図２０を参照して、上記した図１９に示すステップＳ１１４の処理について具体的に説明する。図２０は、ロック状態テーブル１３３におけるＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロック及び既に取得されているロックの関係の一例を表す図である。
【０２５５】
なお、サスペンド判定部２２８によって取得されたデッドロック状況情報は、前述した図６のデッドロックを示すものとして説明する。なお、図２０及び前述した図６において、スレッドＩＤ「Ｔ１」〜「Ｔ４」及びロックのアドレス「Ｌ１」〜「Ｌ４」はそれぞれ対応しているものとして説明する。
【０２５６】
また、ＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロックのアドレス（サスペンド判定処理部２２８によって取得されたロックのアドレス）は「Ｌ３」であり、当該ロック取得要求の要求元であるスレッドを識別するためのスレッドＩＤ（サスペンド判定処理部２２８によって取得されたスレッドＩＤ）は「Ｔ２」であるものとする。つまり、図２０における斜線部のロック取得状態が「ロック中」になる場合を想定している。以下、ＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロック（図２０における斜線部）を対象ロックと称する。
【０２５７】
まず、図２０に示す例では、サスペンド判定部２２８によって取得されたスレッドＩＤ「Ｔ２」によって識別されるスレッド（以下、単に「Ｔ２」と表記）がデッドロック状況情報によって示されるデッドロック時（以下、単にデッドロック時と表記）において実行中である。また、対象ロックがデッドロック時に他のスレッド（ここでは、「Ｔ１」）を止めることになるロックである。したがって、対象ロックは、上記した前提を満たすものとする。
【０２５８】
ここで、図２０及び前述した図６に示すように、デッドロック時に「Ｔ２」で取得要求中になるロック（ここでは、ロックのアドレスが「Ｌ４」であるロック）を止めることになるロックが、「Ｔ４」によって取得されている。したがって、対象ロックは、上記した第１の条件を満たす。
【０２５９】
また、図２０及び前述した図６に示すように、対象ロックによって止められることになるロック（ここでは、ロックのアドレスが「Ｌ３」であるロック）を取得要求中となるスレッド（ここでは、「Ｔ１」）が、デッドロック時に他のスレッド（ここでは、「Ｔ４」）を止めることになるロック（ここでは、ロックのアドレスが「Ｌ１」であるロック）を取得している。したがって、対象ロックは、上記した第２の条件を満たす。
【０２６０】
よって、対象ロックが取得された場合において、「Ｔ１」がロックのアドレスが「Ｌ１」であるロック（以下、「Ｌ１」のロックと表記）を解放する前に「Ｌ３」のロックを、「Ｔ２」が「Ｌ３」のロックを解放する前に「Ｌ４」のロックを、「Ｔ４」が「Ｌ４」のロックを解放する前に「Ｌ１」のロックを取得しようとした（ロック取得要求を出力した）場合、前述した図６に示すデッドロックと同じ状況に陥る可能性があるため当該対象ロックのロック取得処理がサスペンドされる。
【０２６１】
なお、上記した第１及び第２の条件は一例であるため、ロック取得処理をサスペンドするための条件として当該第１及び第２の条件以外の条件によってサスペンド判定処理が実行される構成であっても構わない。
【０２６２】
再び図１９に戻ると、サスペンドすべきであると判定された場合（ステップＳ１１４のＹＥＳ）、ＡＰＩフック部２２１によってフックされたロック取得要求に応じたロック取得処理は予め定められた時間（一定時間）サスペンドされる（ステップＳ１１５）。
【０２６３】
次に、上記したステップＳ１１５において一定時間サスペンドされた後、当該ステップＳ１１５の処理がｎ回実行されたか否かが判定される（ステップＳ１１６）。このｎは、予め定められた値である。
【０２６４】
ステップＳ１１５の処理がｎ回実行されたと判定された場合（ステップＳ１１６のＹＥＳ）、処理は終了される。つまり、ＡＰＩフック部２２１によってフックされたロック取得要求に応じたロック取得処理が実行される。一方、ステップＳ１１５の処理がｎ回実行されていないと判定された場合（ステップＳ１１６のＮＯ）、ステップＳ１１４に戻って処理が繰り返される。
【０２６５】
ステップＳ１１１においてデッドロック状況情報が読み込まれていると判定された場合には、ステップＳ１１４の処理が実行される。
【０２６６】
ステップＳ１１４においてサスペンドすべきでないと判定された場合には、サスペンドされることなく処理が終了される。つまり、ＡＰＩフック部２２１によってフックされたロック取得要求に応じたロック取得処理が実行される。
【０２６７】
ここでは、ステップＳ１１５の処理（サスペンド処理）がｎ回実行された場合に当該サスペンド処理が終了されるものとして説明したが、ステップＳ１１４においてサスペンドすべきでないと判定されるまでロック取得処理が実行されない、つまり、サスペンド処理が継続される構成であっても構わない。
【０２６８】
なお、共有ディスク３０に複数のデッドロック状況情報が格納されている場合には、当該複数のデッドロック状況情報の全てについて上記した図１９に示す処理が実行される。
【０２６９】
上記したように本実施形態においては、例えばノード２００においてデッドロックの発生が検出された場合には、当該デッドロックを示すデッドロック状況情報が共有ディスク４００に格納される。本実施形態においては、ノード２００のＡＰＩフック部２２１によってロック取得要求がフックされると、当該ロック取得要求に応じたロック取得処理が実行されるとデッドロックに陥る可能性があるか否かをデッドロック状況情報に基づいて判定することによって、当該ロック取得処理をサスペンドすることができる。これにより、本実施形態においては、複数のノード２００のいずれかにおいて発生したデッドロックと同じ条件のデッドロックが発生する確率を低減することが可能となる。このように、本実施形態においては、アプリケーション障害が発生する確率を低減することでクラスタシステムの可用性を向上させることが可能となる。
【０２７０】
また、本実施形態においては、デッドロックが発生する可能性があると判定された場合に、一定時間のみロック取得処理をサスペンドすることで、監視対象アプリケーション１１の動作に与える影響を最小限に抑えることが可能である。
【０２７１】
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
【図面の簡単な説明】
【０２７２】
【図１】本発明の第１の実施形態に係るクラスタシステムの機能構成を示すブロック図。
【図２】図１に示すノード１０の主として機能構成を示すブロック図。
【図３】図２に示すロック状態テーブル１３３のデータ構造の一例を示す図。
【図４】ロック状態管理部１３２によるロック状態テーブル１３３の更新について説明するための図。
【図５】デッドロック検出部１３４のデッドロックの発生の検出処理の処理手順を示すフローチャート。
【図６】デッドロックが発生する場合のロックの取得状態を表すロック状態テーブル１３３の一例を示す図。
【図７】監視対象アプリケーション１１を構成するスレッドによってロックが取得される際の処理の流れについて説明するための図。
【図８】監視対象アプリケーション１１を構成するスレッドによってロックが解放される際の処理の流れについて説明するための図。
【図９】本発明の第２の実施形態に係るクラスタシステムに備えられるノード１００の主として機能構成を示すブロック図。
【図１０】プロセス１１０ａを構成するスレッドによってロックが取得される際の処理の流れについて説明するための図。
【図１１】プロセス１１０ａを構成するスレッドによってロックが解放される際に処理の流れについて説明するための図。
【図１２】本発明の第３の実施形態に係るクラスタシステムのノード２００の主として機能構成を示すブロック図。
【図１３】図１２に示すスレッド対応テーブル２２３のデータ構造の一例を示す図。
【図１４】図１２に示すロック対応テーブル２２４のデータ構造の一例を示す図。
【図１５】共有ディスク３０に格納されるデッドロック状況情報のデータ構造の一例を示す図。
【図１６】スレッド作成処理の流れについて説明するための図。
【図１７】ロック作成処理の流れについて説明するための図。
【図１８】監視対象アプリケーション１１を構成するスレッドによってロックが取得される際の処理の流れについて説明するための図。
【図１９】サスペンド判定部２２８によるサスペンド判定処理の処理手順を示すフローチャート。
【図２０】ロック状態テーブル１３３におけるＡＰＩフック部２２１によってフックされたロック取得要求に応じて取得されるロック及び既に取得されているロックの関係の一例を表す図。
【符号の説明】
【０２７３】
１０，１００，２００…ノード（計算機）、１１…監視対象アプリケーション、１２，２１０…ＯＳ、１３，１３０ａ，１３０ｂ，２２０…ジャケットライブラリ、１４…ＨＡクラスタデーモン（フェイルオーバ手段）、３０…共有ディスク（格納手段）、１２１…ロック取得部、１２２…ロック解放部、１３１，２２１…ＡＰＩフック部（取得手段）、１３２，１３６…ロック状態管理部（ロック管理手段）、１２３，１３３…ロック状態テーブル、１３４，１３７，２２５…デッドロック検出部、１３５…デッドロック通知部、２１１…スレッド作成部、２１２…ロック作成部、２２２…ロック／スレッド対応付け部、２２３…スレッド対応テーブル、２２４…ロック対応テーブル、２２６…デッドロック情報作成部、２２７…デッドロック情報読込部、２２８…サスペンド判定部。
【図１】
2009271858.tif 000003
【図２】
2009271858.tif 000004
【図３】
2009271858.tif 000005
【図４】
2009271858.tif 000006
【図５】
2009271858.tif 000007
【図６】
2009271858.tif 000008
【図７】
2009271858.tif 000009
【図８】
2009271858.tif 000010
【図９】
2009271858.tif 000011
【図１０】
2009271858.tif 000012
【図１１】
2009271858.tif 000013
【図１２】
2009271858.tif 000014
【図１３】
2009271858.tif 000015
【図１４】
2009271858.tif 000016
【図１５】
2009271858.tif 000017
【図１６】
2009271858.tif 000018
【図１７】
2009271858.tif 000019
【図１８】
2009271858.tif 000020
【図１９】
2009271858.tif 000021
【図２０】
2009271858.tif 000022