JP2009271858A - Computing system and program - Google Patents
Computing system and program Download PDFInfo
- Publication number
- JP2009271858A JP2009271858A JP2008123877A JP2008123877A JP2009271858A JP 2009271858 A JP2009271858 A JP 2009271858A JP 2008123877 A JP2008123877 A JP 2008123877A JP 2008123877 A JP2008123877 A JP 2008123877A JP 2009271858 A JP2009271858 A JP 2009271858A
- Authority
- JP
- Japan
- Prior art keywords
- lock
- deadlock
- thread
- unit
- acquisition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Hardware Redundancy (AREA)
- Debugging And Monitoring (AREA)
Abstract
Description
本発明は、計算機において発生するデッドロックを検出する計算機システム及びプログラムに関する。 The present invention relates to a computer system and a program for detecting a deadlock that occurs in a computer.
近年、例えば複数のノード(計算機)及び少なくとも1つ以上のストレージ装置(共有ディスク)から構成される高可用性(High Availability)クラスタシステム(以下、HAクラスタシステムと表記)と呼ばれる計算機システムが知られている。このHAクラスタシステムを構成する複数のノードには、例えば運用系ノード及び待機系ノードが含まれる。 In recent years, for example, a computer system called a high availability cluster system (hereinafter referred to as an HA cluster system) composed of a plurality of nodes (computers) and at least one storage device (shared disk) has been known. Yes. The plurality of nodes constituting the HA cluster system include, for example, an active node and a standby node.
HAクラスタシステムにおいては、例えば運用系ノードで障害が発生した場合、当該運用系ノード上で動作していたアプリケーション、共有ディスクまたはIP(Internet Protocol)アドレス等を待機系ノードで引き継ぐ(フェイルオーバ)ことにより障害を復旧し、クラスタシステムにおける運用を継続することができる。以下、HAクラスタシステムが提供する機能を継続するために必要な運用系ノードから待機系ノードに引き継がれる引継ぎ単位のセット(例えばアプリケーション、共有ディスク、IPアドレス等)を統合してサービスと称する。 In the HA cluster system, for example, when a failure occurs in the active node, the standby node takes over the application, shared disk, IP (Internet Protocol) address, etc. that were operating on the active node. The failure can be recovered and the operation in the cluster system can be continued. Hereinafter, a set of takeover units (for example, an application, a shared disk, an IP address, etc.) to be taken over from the active node to the standby node necessary for continuing the functions provided by the HA cluster system are referred to as a service.
例えば運用系ノードで発生する障害は、大きく2つ(第1の障害、第2の障害)に分類できる。第1の障害は、例えばシャットダウン等のノード自体が停止することにより生じるサーバ障害である。第2の障害は、例えばノード上で稼動しているアプリケーションが誤動作することにより生じるアプリケーション障害である。 For example, failures that occur in the active node can be roughly classified into two (first failure and second failure). The first failure is a server failure that occurs when the node itself stops, for example, shutdown. The second failure is an application failure that occurs when, for example, an application running on a node malfunctions.
上記したHAクラスタシステムを構成する各ノードには、当該HAクラスタシステムを管理するためのミドルウェア(HAクラスタデーモン)が備えられている。このHAクラスタデーモンでは、障害発生時に自動で待機系ノードにサービスを引き継ぐため、例えば運用系ノードで発生する障害を検出する仕組みが必要となる。以下、上記した第1の障害及び第2の障害のうち、第2の障害について述べる。 Each node constituting the above-described HA cluster system is provided with middleware (HA cluster daemon) for managing the HA cluster system. In this HA cluster daemon, since a service is automatically taken over to the standby node when a failure occurs, a mechanism for detecting a failure that occurs in the active node, for example, is required. Hereinafter, the second failure among the first failure and the second failure will be described.
上記した第2の障害(アプリケーション障害)を検出する技術として、例えば監視の対象となるアプリケーション(以下、監視対象アプリケーションと表記)の状態を監視する外部コマンド(状態監視コマンド)を用意し、HAクラスタデーモンにおいて当該状態監視コマンドが定期的に実行されることによって監視対象アプリケーションで発生した障害を検出する技術(以下、先行技術1と表記)がある。この先行技術1によれば、状態監視コマンドの返り値が異常を示すものであれば監視対象アプリケーションで障害が発生したことが検出される。なお、監視対象アプリケーションは、例えば少なくとも1つのプロセスから構成され、当該プロセスは1つ以上のスレッドから構成される。 As a technique for detecting the second failure (application failure) described above, for example, an external command (state monitoring command) for monitoring the state of an application to be monitored (hereinafter referred to as a monitoring target application) is prepared, and an HA cluster is prepared. There is a technique (hereinafter referred to as Prior Art 1) for detecting a failure that has occurred in a monitoring target application by periodically executing the state monitoring command in a daemon. According to this prior art 1, if the return value of the state monitoring command indicates an abnormality, it is detected that a failure has occurred in the monitoring target application. Note that the monitoring target application includes, for example, at least one process, and the process includes one or more threads.
ところで、上記したアプリケーション障害の代表的な例としてデッドロックが挙げられる。例えば上記した複数のスレッド(監視対象アプリケーション)の共有資源を用いて当該複数のスレッドのうちの1つのスレッドが実行される際、当該スレッドは、当該スレッドとは異なる他のスレッドからの当該共有資源の利用(アクセス)を排他制御するためにロックを取得する。この場合、ロックが取得されている間、他のスレッドは共有資源を利用することができない。また、スレッドの実行が終了されると、当該スレッドによって取得されていたロックは解放される。これにより、他のスレッドは共有資源を利用することができるようになる。 Incidentally, a deadlock is a typical example of the application failure described above. For example, when one thread of the plurality of threads is executed using the shared resource of the plurality of threads (monitored applications) described above, the thread is the shared resource from another thread different from the thread. Acquire a lock to exclusively control the use (access) of In this case, other threads cannot use the shared resource while the lock is acquired. Further, when the execution of the thread is terminated, the lock acquired by the thread is released. As a result, other threads can use the shared resource.
デッドロックとは、このような場合に、複数のスレッドがそれぞれロックを取得し、当該ロックが取得された状態を維持したまま当該複数のスレッドが互いに相手にロックされている共有資源の解放を待ってしまい、処理が停止することをいう。 In such a case, deadlock means that multiple threads acquire their respective locks and wait for the shared resources that are locked to each other to be held while the locks are acquired. It means that the process stops.
このアプリケーション障害であるデッドロック(アプリケーションのデッドロック)を直接検出して、上記したサービスをフェイルオーバする技術は知られていない。 There is no known technique for directly detecting this application failure deadlock (application deadlock) and failing over the above service.
上記したアプリケーションのデッドロックの検出に関連する技術として、アプリケーションプログラムに影響することなく、デッドロック状態を容易に且つ正確に検知できる技術(以下、先行技術2と表記)が開示されている(例えば、特許文献1を参照)。この先行技術2によれば、OS(Operating System)の中でロックの取得状態が管理されることによってデッドロックが検出される。 As a technique related to the detection of the above-described application deadlock, a technique (hereinafter referred to as Prior Art 2) that can easily and accurately detect a deadlock state without affecting an application program is disclosed (for example, described below). , See Patent Document 1). According to this prior art 2, a deadlock is detected by managing a lock acquisition state in an OS (Operating System).
また、デッドロックを発生させる可能性のある処理の組み合わせを構成する各処理を別々に行ったテスト時に取得した共通の資源に対するアクセス情報を元にデッドロックの可能性を検出する技術(以下、先行技術3と表記)が開示されている(例えば、特許文献2を参照)。この先行技術3によれば、アプリケーションの全処理の共有資源へのアクセス順序を予め記録し、その記録をつき合わせることでデッドロックが発生する可能性が検出される。 In addition, a technology for detecting the possibility of deadlock based on access information to a common resource acquired during a test in which each process constituting a combination of processes that may cause a deadlock is performed separately (hereinafter, the preceding (Referred to as Patent 3). According to the prior art 3, the access order to the shared resources of all processes of the application is recorded in advance, and the possibility of deadlock is detected by matching the records.
クラスタシステムにおけるデッドロックに関連する技術として、クラスタシステムにおける情報転送のためのオーバヘッド時間を短くし、デッドロック検出までの時間を短くする技術(以下、先行技術4と表記)が開示されている(例えば、特許文献3を参照)。この先行技術4は、クラスタシステム内のノード間の共有リソースにおけるデッドロックを検出する方法である。先行技術4によれば、ロック管理用ノードを1台用意し、当該共有リソースへのアクセスが不許可の場合、管理用ノードにチェックを要求することでデッドロックの発生が検出される。
上記した先行技術1においては、例えば外部の状態監視コマンドの定期実行によってアプリケーションの特定の障害が検出される。 In the above-described prior art 1, a specific failure of an application is detected by, for example, periodic execution of an external state monitoring command.
このため、先行技術1では、アプリケーションの代表的な障害であるデッドロックを外部から直接検出する手段がない。また、監視対象アプリケーションの内部実装はわからない場合が多いため、外部コマンドの実行では、必要な全ての機能の障害を網羅する監視は困難である。したがって、先行技術1では、例えばある特定の機能がデッドロックで処理できないというアプリケーション障害が発生しても当該デッドロックを検出することができない場合がある。 For this reason, in the prior art 1, there is no means for directly detecting a deadlock that is a typical failure of an application from the outside. In addition, since the internal implementation of the monitoring target application is often unknown, it is difficult to monitor all the necessary functional failures by executing an external command. Therefore, in the prior art 1, for example, even if an application failure occurs in which a specific function cannot be processed by a deadlock, the deadlock may not be detected.
また、先行技術1では、デッドロックが発生した場合であっても状態監視コマンドで検出可能な状態になるまで時間を要する場合がある。更に、状態監視コマンドで検出可能な状態になっても、次の定期監視実行までにタイムラグがあり、その分の時間を要する。このため、先行技術1では、デッドロックという障害が発生しても即座に当該デッドロックを検出することはできない。 In the prior art 1, it may take time until the state can be detected by the state monitoring command even when a deadlock occurs. Further, even if the state can be detected by the state monitoring command, there is a time lag until the next periodic monitoring execution, and it takes a corresponding amount of time. For this reason, in the prior art 1, even if a failure called deadlock occurs, the deadlock cannot be detected immediately.
したがって、先行技術1では、平均修理時間の増大による可用性の低下や検出可能な障害範囲の限定といった影響がある。 Therefore, in the prior art 1, there are effects such as a decrease in availability due to an increase in the average repair time and a limitation of a detectable failure range.
上記した先行技術2においては、特殊なOSが必要であり、クラスタシステムが管理する任意のアプリケーションの動作には適さない。また、デッドロックが検出された場合であっても、フェイルオーバ等の対処を行うことはできない。 The above-described prior art 2 requires a special OS and is not suitable for the operation of any application managed by the cluster system. Even if a deadlock is detected, it is not possible to take measures such as failover.
上記した先行技術3においては、上記したようにアプリケーションの全処理の共有資源へのアクセス順序を予め記録しておくため、動的にデッドロックを検出するものではない。したがって、先行技術3では、クラスタシステムでの障害検出には適さない。 In the above prior art 3, since the access order to the shared resources of all processes of the application is recorded in advance as described above, the deadlock is not dynamically detected. Therefore, Prior Art 3 is not suitable for detecting a failure in a cluster system.
上記した先行技術4においては、上記したようにロック管理用ノードを1台用意し、管理用ノードにチェックを要求することでデッドロックの発生を検出するため、ノード上で稼動するアプリケーションのデッドロックを検出する手段には適用することができない。
In the above-described
そこで、本発明の目的は、ノードにおけるデッドロックの発生をイベントドリブンで検出し、障害発生から障害検出までの時間を短縮及び検出可能な障害範囲を拡大することが可能な計算機システム及びプログラムを提供することにある。 Therefore, an object of the present invention is to provide a computer system and a program capable of detecting the occurrence of a deadlock in a node in an event-driven manner, reducing the time from the occurrence of a failure to the failure detection, and expanding the detectable failure range. There is to do.
本発明の1つの態様によれば、資源を共有する複数のスレッドを実行する計算機を具備し、前記計算機は、前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得する取得手段と、前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態が登録されるロック状態テーブルと、前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出する検出手段とを含むことを特徴とする計算機システムが提供される。 According to one aspect of the present invention, a computer is provided that executes a plurality of threads that share a resource, and the computer requests acquisition of a lock for occupying the resource from each of the plurality of threads. An acquisition unit for acquiring a lock acquisition request, a lock state table in which acquisition states of locks by the plurality of threads are registered based on the acquired lock acquisition request, the acquired lock acquisition request, and the lock There is provided a computer system including detection means for detecting the occurrence of a deadlock based on a lock acquisition state registered in a state table.
本発明によれば、ノードにおけるデッドロックの発生を検出することで、障害発生から障害検出までの時間を短縮及び検出可能な障害範囲を拡大することが可能となる。 According to the present invention, by detecting the occurrence of a deadlock in a node, it is possible to reduce the time from failure occurrence to failure detection and to expand the detectable failure range.
以下、図面を参照して、本発明の各実施形態について説明する。 Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[第1の実施形態]
図1は、本発明の第1の実施形態に係るクラスタシステム(計算機システム)の機能構成を示すブロック図である。
[First Embodiment]
FIG. 1 is a block diagram showing a functional configuration of a cluster system (computer system) according to the first embodiment of the present invention.
図1に示すように、本実施形態に係るクラスタシステムは、複数のノード(計算機)10及び共有ディスク30を備える。複数のノード10には、運用系ノード及び複数の待機系ノードが含まれる。
As shown in FIG. 1, the cluster system according to the present embodiment includes a plurality of nodes (computers) 10 and a shared
複数のノード10は、例えば通信路を介して互いに通信可能に接続されている。
The plurality of
また、複数のノード10及び共有ディスク30は、例えばFC(Fibre Channel)ケーブルで接続されている。
The plurality of
上記したクラスタシステムは、当該クラスタシステムを構成する複数のノード10のうち、例えば運用系ノードとして動作するノード(以下、運用系ノードと表記)10で障害が発生した場合、当該運用系ノード10の処理が待機系ノードとして動作するノード(以下、単に待機系ノードと表記)10に引き継がれる高可用性(High Availability)クラスタシステム(HAクラスタシステム)である。つまり、運用系ノード10で障害が発生した場合には、例えば運用系ノード10上で動作していたアプリケーション、共有ディスク30または当該運用系ノード10のIP(Internet Protocol)アドレス等(以下、サービスと表記)が待機系ノード10に引き継がれる処理(フェイルオーバ)が実行される。これにより、クラスタシステムでは、運用系ノード10において障害が発生した場合であっても待機系ノード10において運用を継続することが可能となる。
In the cluster system described above, when a failure occurs in, for example, a node (hereinafter referred to as an active node) 10 that operates as an active node among a plurality of
図2は、図1に示す複数のノード10の各々(以下、単にノード10と表記)の主として機能構成を示すブロック図である。
FIG. 2 is a block diagram mainly showing a functional configuration of each of the plurality of
ノード10上では、アプリケーション11、OS(Operating System:オペレーティングシステム)12、ジャケットライブラリ13及びHA(High Availability)クラスタデーモン14が動作する。
On the
アプリケーション11は、ジャケットライブラリ13による監視の対象となるアプリケーション(以下、監視対象アプリケーション11と表記)である。監視対象アプリケーション11は、例えば少なくとも1つのプロセスから構成される。ここでは、監視対象アプリケーション11は、1つのプロセスから構成されるものとして説明する。また、監視対象アプリケーション11を構成するプロセスは、1つ以上のスレッドから構成される。ここでは、監視対象アプリケーション11を構成するプロセスは、複数のスレッドから構成されるものとして説明する。
The
つまり、例えば運用系ノードとして動作するノード(運用系ノード)10では、監視対象アプリケーション11(を構成するプロセス)を構成する複数のスレッドが実行される。 That is, for example, in the node (active node) 10 that operates as the active node, a plurality of threads constituting the monitoring target application 11 (processes constituting the monitored application 11) are executed.
監視対象アプリケーション11を構成する複数のスレッドは、例えばノード10が有する資源(リソース)を共有する。
The plurality of threads constituting the
ノード10において複数のスレッドが実行される際には、当該複数のスレッドの各々は、当該ノード10が有する資源を占有するためのロックの取得を要求するロック取得要求をOS12に対して出力する。これにより、ロックが取得された場合には、当該ロックが取得された資源に対する排他制御が可能となる。
When a plurality of threads are executed in the
また、複数のスレッドの各々は、当該スレッドによりロックが取得されている資源の占有を解放するためのロック解放要求をOS12に対して出力する。これにより、ロックが解放された場合には、ロックを取得していたスレッド以外のスレッドは、当該ロックが取得されていた資源を使用(利用)することが可能となる。
Each of the plurality of threads outputs a lock release request for releasing the occupation of the resource for which the lock is acquired by the thread to the
OS12は、監視対象アプリケーション11を構成する複数のスレッドの各々を管理する。この場合、OS12は、複数のスレッドの各々を識別するためのスレッドIDを用いて実行中のスレッドを管理する。
The
OS12は、ロック取得部121及びロック解放部122を含む。ロック取得部121は、複数のスレッドの各々からのロック取得要求に応じてロックを取得する処理を実行する。ロック取得部121は、複数のスレッドの各々からのロック取得要求に応じて取得されるべきロックが他のスレッドによって既に取得されている場合には、当該ロックが他のスレッドによって解放されるのを待ってからロックの取得処理を実行する。
The
ロック解放部122は、複数のスレッドの各々からのロック解放要求に応じてロックを解放する処理を実行する。
The
ジャケットライブラリ13は、監視対象アプリケーション11を構成する複数のスレッドの各々からのOS12に対するロック取得要求及びロック解放要求をフック(取得)することで、当該複数のスレッドの各々によるロックの取得状態を管理する機能を有する。また、ジャケットライブラリ13は、フックされたロック取得要求及び複数のスレッドの各々によるロックの取得状態に基づいてデッドロックの発生を検出する機能を有する。
The
図2に示すように、ジャケットライブラリ13は、API(Application Program Interface)フック部131、ロック状態管理部132、ロック状態テーブル133、デッドロック検出部134及びデッドロック通知部135を含む。
As shown in FIG. 2, the
本実施形態において、APIフック部131、ロック状態管理部132、デッドロック検出部134及びデッドロック通知部135は、ノード10のコンピュータ(図示せず)が例えばノード10に備えられるメモリ(図示せず)に格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
In the present embodiment, the
また、本実施形態において、ロック状態テーブル133は、例えばノード10に備えられるメモリ内であって、上記した監視対象アプリケーション11(を構成するプロセス)に与えられたメモリ空間にその領域が確保されている。
Further, in the present embodiment, the lock state table 133 is in a memory provided in the
換言すれば、図2に示すジャケットライブラリ13は、APIフック部131、ロック状態管理部132、デッドロック検出部134及びデッドロック通知部135というモジュールと、ロック状態テーブル133というデータで構成される。
In other words, the
APIフック部131は、監視対象アプリケーション11を構成する複数のスレッドのOS12に対するロック取得要求及びロック解放要求をフックする。このロック取得要求及びロック解放要求には、当該要求に応じて取得または解放されるロックのアドレスが含まれる。ロックのアドレスは、OS12によって管理されているメモリ上のアドレスである。
The
APIフック部131は、ロック取得要求がフックされた場合には、当該ロック取得要求に含まれるロックのアドレス及び当該ロック取得要求に応じてロックの取得が実行される旨(以下、「ロック取得の実行」と表記)をロック状態管理部132に通知する。
When the lock acquisition request is hooked, the
また、APIフック部131は、ロック取得要求がフックされた場合には、当該ロック取得要求に応じてOS12に含まれるロック取得部(ロック取得API)121を実行する。これにより、ロック取得部121は、ロック取得要求に応じてロック取得処理を実行する。
Further, when a lock acquisition request is hooked, the
APIフック部131は、ロック解放要求がフックされた場合には、当該ロック解放要求に含まれるロックのアドレス及び当該ロック解放要求に応じてロックの解放が実行される旨(以下、「ロック解放の実行」と表記)をロック状態管理部132に通知する。
When the lock release request is hooked, the
また、APIフック部131は、ロック解放要求がフックされた場合には、当該ロック解放要求に応じてOS12に含まれるロック解放部(ロック解放API)122を実行する。これにより、ロック解放部122は、ロック解放要求に応じてロック解放処理を実行する。
Further, when a lock release request is hooked, the
APIフック部131は、OS12(に含まれるロック取得部121及びロック解放部122)からのロック取得要求に対する応答(以下、ロック取得応答と表記)及びロック解放要求に対する応答(以下、ロック解放応答と表記)をフックする。このロック取得応答及びロック解放応答には、当該取得または解放されたロックのアドレスが含まれる。また、APIフック部131は、ロック取得応答及びロック解放応答を監視対象アプリケーション11(を構成するスレッド)に返す。
The
APIフック部131は、ロック取得応答がフックされた場合、当該ロック取得応答に含まれるロックのアドレス及び当該ロック取得応答が返された旨(以下、「ロック取得の応答」と表記)をロック状態管理部132に通知する。同様に、APIフック部131は、ロック解放応答がフックされた場合、当該ロック解放応答に含まれるロックのアドレス及び当該ロック解放応答が返された旨(以下、「ロック解放の応答」と表記)をロック状態管理部132に通知する。
When the lock acquisition response is hooked, the
APIフック部131は、上記したようにロック状態管理部132に通知することによって、当該ロック状態管理部132にロック状態テーブル133の更新を要求する。
The
また、APIフック部131は、監視対象アプリケーション11を構成するスレッドからのロック取得要求に応じたロック取得部121(ロック取得API)の実行時に、デッドロック検出部134に対してデッドロックの発生の検出処理を要求する。このとき、APIフック部131は、ロックのアドレスをデッドロック検出部134に出力する。
Also, the
ロック状態管理部132は、APIフック部131からの通知を受けると、当該APIフック部131によってフックされたロック取得要求またはロック解放要求の要求元であるスレッドを識別するためのスレッドIDを、監視対象アプリケーション11を構成するスレッドを管理するOS12に問い合わせる。これにより、ロック状態管理部132は、スレッドIDを取得する。
Upon receiving the notification from the
ロック状態管理部132は、APIフック部131からの通知及び取得されたスレッドIDに基づいてロック状態テーブル133を更新する。ロック状態テーブル133には、監視対象アプリケーション11を構成する複数のスレッドによるロックの取得状態が登録される。ロック状態テーブル133の更新は、APIフック部131から通知されたロックのアドレス及びロック状態管理部132によって取得されたスレッドIDからなる組み合わせの状態(ロックの取得状態)を、APIフック部131からの通知の内容(例えば、「ロック取得の実行」等)に応じた状態に変更することによって行われる。
The lock
ロック状態管理部132は、更新するスレッドIDまたはロックのアドレスがロック状態テーブル133にない(登録されていない)ときは当該ロック状態テーブル133を拡張する。
The lock
デッドロック検出部134は、APIフック部131からの要求に基づいて、APIフック部131によってフックされたロック取得要求に応じてロックが取得された場合にデッドロックが発生するか否かを確認する。これにより、デッドロック検出部134は、デッドロックの発生を検出する。
Based on the request from the
このとき、デッドロック検出部134は、ロック取得要求の要求元であるスレッドを識別するためのスレッドIDをOS12に問い合わせることにより、当該スレッドIDを取得する。デッドロック検出部134は、取得されたスレッドID、APIフック部131によって出力されたロックのアドレス及びロック状態テーブル133に登録されているロック取得状態に基づいてデッドロックの発生を検出する。デッドロックの発生が検出された場合、デッドロック検出部134は、デッドロック通知部135に当該デッドロックの発生の通知要求を出力する。
At this time, the
なお、デッドロック検出部134によるデッドロックの発生の検出処理の詳細については後述する。
Details of the deadlock occurrence detection process by the
デッドロック通知部135は、デッドロック検出部134によって出力された通知要求に基づいて、デッドロックの発生をHAクラスタデーモン14に通知する。
The
HAクラスタデーモン14は、クラスタシステムの管理及び運用を実行する機能を有する。HAクラスタデーモン14は、運用系ノードとして動作するノード10において例えば監視対象アプリケーション11に障害が発生した場合には、当該ノード10のサービスを当該ノード10とは別の待機系ノードとして動作するノード10に引き継ぐ(フェイルオーバ)処理を実行する。
The
HAクラスタデーモン14は、ジャケットライブラリ13に含まれるデッドロック通知部135によってデッドロックの発生が通知された場合、監視対象アプリケーション11において障害(デッドロック)が発生したものとしてサービスのフェイルオーバ等の対処を行う。
When the
なお、HAクラスタデーモン14は、監視対象アプリケーション11において障害が発生した場合の対処として、監視対象アプリケーション11の再起動を行う構成であっても構わない。
Note that the
図3は、図2に示すロック状態テーブル133のデータ構造の一例を示す。図3に示すように、ロック状態テーブル133には、ロックのアドレス及びスレッドIDに対応付けてロックの取得状態が登録される。ここでは、ロックのアドレスはL(L1、L2、L3、…)、スレッドIDはT(T1、T2、T3、…)と表記されている。 FIG. 3 shows an example of the data structure of the lock state table 133 shown in FIG. As shown in FIG. 3, in the lock state table 133, the lock acquisition state is registered in association with the lock address and the thread ID. Here, the lock address is represented as L (L1, L2, L3,...), And the thread ID is represented as T (T1, T2, T3,...).
ここで、ロックの取得状態には、「ロック中」、「ロック要求中」及び「ロックなし」が含まれる。図3に示す例では、「ロック中」は「○」、「ロック要求中」は「△」、「ロックなし」は「ブランク(なし)」で表されている。 Here, the lock acquisition status includes “locking”, “lock requesting”, and “no lock”. In the example shown in FIG. 3, “locked” is represented by “◯”, “lock requested” is represented by “Δ”, and “no lock” is represented by “blank (none)”.
図3に示す例では、ロック状態テーブル133には、ロックのアドレス「L1」及びスレッドID「T1」に対応付けてロックの取得状態「○」が登録されている。これによれば、スレッドID「T1」によって識別されるスレッドが、ロックのアドレスが「L1」であるロックを「ロック中」であることが示されている。 In the example illustrated in FIG. 3, the lock acquisition state “◯” is registered in the lock state table 133 in association with the lock address “L1” and the thread ID “T1”. This indicates that the thread identified by the thread ID “T1” is “locking” the lock whose lock address is “L1”.
ロック状態テーブル133には、ロックのアドレス「L2」及びスレッドID「T3」に対応付けてロックの取得状態「○」が登録されている。これによれば、スレッドID「T3」によって識別されるスレッドが、ロックのアドレスが「L2」であるロックを「ロック中」であることが示されている。 In the lock state table 133, the lock acquisition state “◯” is registered in association with the lock address “L2” and the thread ID “T3”. This indicates that the thread identified by the thread ID “T3” is “locking” the lock whose lock address is “L2”.
また、ロック状態テーブル133には、ロックのアドレス「L3」及びスレッドID「T1」に対応付けてロックの取得状態「△」が登録されている。これによれば、スレッドID「T1」によって識別されるスレッドが、ロックのアドレスが「L1」であるロックを「ロック要求中」であることが示されている。 In the lock state table 133, the lock acquisition state “Δ” is registered in association with the lock address “L3” and the thread ID “T1”. This indicates that the thread identified by the thread ID “T1” is “locking requested” for the lock whose lock address is “L1”.
なお、ロック状態テーブル133において、上記した以外については「ロック中」及び「ロック要求中」でない、つまり、「ロックなし」であることが示されている。 The lock state table 133 indicates that the items other than those described above are not “locking” and “lock requesting”, that is, “no lock”.
次に、図4を参照して、上記したロック状態管理部132によるロック状態テーブル133の更新について説明する。
Next, update of the lock state table 133 by the lock
ロック状態管理部132は、APIフック部131からの通知及び取得されたスレッドID(要求元であるスレッドを識別するためのスレッドID)に基づいてロック状態テーブル133を更新する。APIフック部131からの通知(の内容)には、上記したように「ロック取得の実行」、「ロック取得の応答」、「ロック解放の実行」及び「ロック解放の応答」が含まれる。
The lock
ここで、図4に示すように、APIフック部131からの通知の内容が「ロック取得の実行」である場合には、ロック状態管理部132は、ロック状態テーブル133におけるロックの取得状態を「ロック要求中」に更新する。例えばAPIフック部131から通知されたロックのアドレスが「L1」、ロック状態管理部132によって取得されたスレッドIDが「T3」であり、APIフック部131からの通知の内容が「ロック取得の実行」である場合を想定する。この場合には、ロック状態管理部132は、ロックのアドレス「L1」及びスレッドID「T3」に対応付けられているロック状態テーブル133におけるロックの取得状態を「ロック要求中」に更新する。
Here, as shown in FIG. 4, when the content of the notification from the
図4に示すように、APIフック部131からの通知の内容が「ロック取得の応答」である場合には、ロック状態管理部132は、ロック状態テーブル133におけるロックの取得状態を「ロック中」に更新する。
As illustrated in FIG. 4, when the content of the notification from the
図4に示すように、APIフック部131からの通知の内容が「ロック解放の実行」である場合には、ロック状態テーブル133におけるロックの取得状態は変更していないため、ロック状態管理部132は、ロック状態テーブル133の更新は行わない。
As shown in FIG. 4, when the content of the notification from the
また、図4に示すように、APIフック部131からの通知の内容が「ロック解放の応答」である場合には、ロック状態管理部132は、ロック状態テーブル133におけるロックの取得状態を「ロックなし」に更新する。
As shown in FIG. 4, when the content of the notification from the
次に、図5のフローチャートを参照して、前述したデッドロック検出部134によるデッドロックの発生の検出処理の処理手順について説明する。
Next, with reference to the flowchart of FIG. 5, the processing procedure of the deadlock occurrence detection process by the
デッドロックの発生の検出処理は、デッドロック検出部134がAPIフック部131からの要求(デッドロックの発生の確認の要求)を受けると実行される。このとき、デッドロック検出部134は、APIフック部131からロックのアドレスを受け取る。また、デッドロック検出部134は、OS12に問い合わせることにより、スレッドIDを取得する。ここで取得されたスレッドIDは、APIフック部131から受け取られたロックのアドレスを含むロック取得要求(APIフック部131によってフックされたロック取得要求)の要求元であるスレッドを識別するためのIDである。以下、デッドロック検出部134がAPIフック部131から受け取ったロックのアドレスをL、当該デッドロック検出部134によって取得されたスレッドIDをTとして説明する。
The deadlock occurrence detection process is executed when the
まず、デッドロック検出部134は、初期化処理として、スタックをクリアする(ステップS1)。このスタックは、例えばデータを後入れ先出しの構造で保持するものであり、ハードウェアとソフトウェアの機能の組み合わせによって実装される。スタックは、例えばノード10に備えられているメモリにその領域が確保される。
First, the
次に、デッドロック検出部134は、Tをスタックに追加する(ステップS2)。ここでは、Tは、デッドロック検出部134によって取得されたスレッドIDである。
Next, the
デッドロック検出部134は、APIフック部131から受け取ったLのロックがTによって識別されるスレッド以外のスレッド(以下、単に他のスレッドと表記)に取得されているか否かを判定する(ステップS3)。このとき、デッドロック検出部134は、ロック状態テーブル133を参照して判定処理を実行する。デッドロック検出部134は、ロック状態テーブル133においてLのロックを「ロック中」であるスレッドが存在するか否かを判定する。
The
Lのロックが取得されていると判定された場合(ステップS3のYES)、デッドロック検出部134は、Tを、当該Lのロックを「ロック中」である他のスレッドを識別するためのスレッドID(つまり、T=Lのロックを取得しているスレッドを識別するためのスレッドID)とする(ステップS4)。これにより、ステップS4以降の処理においては、上記した他のスレッドを識別するためのスレッドIDをTとして処理が実行される。
When it is determined that the lock of L has been acquired (YES in step S3), the
次に、デッドロック検出部134は、T(上記した他のスレッドを識別するためのスレッドID)がスタックに存在するか否かを判定する(ステップS5)。
Next, the
スタックに存在しないと判定された場合(ステップS5のNO)、デッドロック検出部134は、ロック状態テーブル133を参照して、Tによって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する(ステップS6)。
If it is determined that the thread does not exist in the stack (NO in step S5), the
「ロック要求中」であるロックがあると判定された場合(ステップS6のYES)、デッドロック検出部134は、Lを、当該ロックのアドレス(つまり、L=Tによって識別されるスレッドが「ロック要求中」であるロックのアドレス)とする(ステップS7)。これにより、ステップS7以降の処理においては、上記したTによって識別されるスレッドが「ロック要求中」であるロックのアドレスをLとして処理が実行される。
If it is determined that there is a lock that is “lock requested” (YES in step S6), the
上記したステップS7の処理が実行された場合、ステップS2に戻って処理が繰り返される。 When the process of step S7 described above is executed, the process returns to step S2 and is repeated.
一方、ステップS3においてLのロックが取得されていないと判定された場合、デッドロック検出部134によって取得されたスレッドIDによって識別されるスレッドがロックを取得した場合であってもデッドロックは発生しないとして、デッドロック検出部134は、デッドロックの発生を検出することなく処理を終了する。
On the other hand, if it is determined in step S3 that the lock of L has not been acquired, even if the thread identified by the thread ID acquired by the
また、ステップS6において「ロック要求中」であるロックがないと判定された場合、デッドロック検出部134は、デッドロックの発生を検出することなく処理を終了する。
If it is determined in step S6 that there is no lock that is “lock requested”, the
一方、ステップS5においてTがスタックに存在すると判定された場合、デッドロック検出部134は、デッドロックの発生を検出する(ステップS8)。このように、ロック状態テーブル133に登録されているロックの取得状態において、ロック中及びロック要求中の(ロックの)ループが発生する場合に、デッドロック検出部134は、デッドロックの発生を検出する。
On the other hand, when it is determined in step S5 that T exists in the stack, the
ここで、図6を参照して、上記した検出部134のデッドロックの発生の検出処理について具体的に説明する。図6は、デッドロックが発生する場合のロックの取得状態を表すロック状態テーブル133の一例を示す。
Here, with reference to FIG. 6, the detection process of the occurrence of deadlock in the
ここでは、デッドロック検出部134がAPIフック部131から受け取ったロックのアドレスはL3であり、当該デッドロック検出部134がOS12に問い合わせることによって取得されたスレッドIDはT1であるものとして説明する。つまり、T1によって識別されるスレッドが、L3のロックを取得しようとしている場合を想定している。
Here, it is assumed that the address of the lock received by the
なお、図6に示す例では、上記したT1及びL3に対応付けて「ロック要求中(△)」が、ロック状態テーブル133に登録されている。 In the example shown in FIG. 6, “lock requested (Δ)” is registered in the lock state table 133 in association with T1 and L3 described above.
この場合、デッドロック検出部134は、取得されたスレッドIDであるT1をスタックに追加する。
In this case, the
次に、デッドロック検出部134は、APIフック部131から受け取ったL3のロックがT1によって識別されるスレッド以外のスレッド(他のスレッド)によって取得されているか否か(つまり、「ロック中」であるか否か)を、ロック状態テーブル133を参照して判定する。図6に示すロック状態テーブル133の例では、APIフック部131から受け取ったL3のロックはT2によって識別されるスレッドによって取得されている。したがって、デッドロック検出部134は、L3のロックが他のスレッド(T2によって識別されるスレッド)によって取得されていると判定する。
Next, the
デッドロック検出部134は、T2がスタックに存在するか否かを判定する。この段階ではスタックにはT1のみが存在するため、デッドロック検出部134は、T2がスタックに存在しないと判定する。
The
デッドロック検出部134は、ロック状態テーブル133を参照して、T2によって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する。図6に示すロック状態テーブル133の例では、T2によって識別されるスレッドは、L4のロックを「ロック要求中」である。したがって、デッドロック検出部134は、T2によって識別されるスレッドが「ロック要求中」であるロック(L4のロック)があると判定する。
The
この場合、デッドロック検出部134は、T2をスタックに追加する。T2がスタックに追加されると、デッドロック検出部134は、L4のロックがT2によって識別されるスレッド以外のスレッド(他のスレッド)によって取得されているか否かを、ロック状態テーブル133を参照して判定する。図6に示すロック状態テーブル133の例では、L4のロックはT4によって識別されるスレッドによって取得されている。したがって、デッドロック検出部134は、L4のロックが他のスレッド(T4によって識別されるスレッド)によって取得されていると判定する。
In this case, the
デッドロック検出部134は、T4がスタックに存在するか否かを判定する。この段階ではスタックにはT1及びT2が存在するため、デッドロック検出部134は、T4がスタックに存在しないと判定する。
The
デッドロック検出部134は、ロック状態テーブル133を参照して、T4によって識別されるスレッドが「ロック要求中」であるロックがあるか否かを判定する。図6に示すロック状態テーブル133の例では、T4によって識別されるスレッドは、L1のロックを「ロック要求中」である。したがって、デッドロック検出部134は、T4によって識別されるスレッドが「ロック要求中」であるロック(L1のロック)があると判定する。
The
この場合、デッドロック検出部134は、T4をスタックに追加する。T4がスタックに追加されると、デッドロック検出部134は、L1のロックがT4によって識別されるスレッド以外のスレッド(他のスレッド)によって取得されているか否かを、ロック状態テーブル133を参照して判定する。図6に示すロック状態テーブル133の例では、L1のロックはT1によって識別されるスレッドによって取得されている。したがって、デッドロック検出部134は、L1のロックが他のスレッド(T1によって識別されるスレッド)によって取得されていると判定する。
In this case, the
デッドロック検出部134は、T1がスタックに存在するか否かを判定する。この場合、スタックにはT1、T2及びT4が存在するため、デッドロック検出部134は、T1がスタックに存在すると判定する。
The
このようにT1がスタックに存在すると判定された場合、図6に示すように複数のスレッド間(ここでは、T1、T2及びT4)においてロック中及びロック要求中のループが発生することになる。複数のスレッドの各々は、いずれかのロックに対して「ロック要求中」である場合には当該スレッドが取得しているロックの解放を実行できない。つまり、例えばT1(によって識別されるスレッド)はT2のロックの解放を、T2はT4のロックの解放を、T4はT1のロックの解放を待っている状態となるため、複数のスレッドが互いに占有している資源の解放を待ち合うことによりデッドロックが発生する。 When it is determined that T1 exists in the stack as described above, a loop during locking and lock request occurs between a plurality of threads (here, T1, T2, and T4) as shown in FIG. Each of the plurality of threads cannot execute the release of the lock acquired by the thread when “lock is being requested” for any lock. That is, for example, T1 (thread identified by) waits for T2 lock release, T2 waits for T4 lock release, and T4 waits for T1 lock release, so multiple threads occupy each other. A deadlock occurs due to waiting for the release of the resource being released.
したがって、デッドロック検出部134は、上記したようにロック中及びロック要求中のループが発生する場合にはデッドロックの発生を検出する。
Therefore, the
なお、デッドロック検出部134は、デッドロックの発生を検出した場合、当該デッドロックの発生をHAクラスタデーモン14に通知することを要求する通知要求をデッドロック通知部135に出力する。デッドロック通知部135は、デッドロック検出部134からの通知要求に基づいてデッドロックの発生をHAクラスタデーモン14に通知する。HAクラスタデーモン14では、当該デッドロック通知部135からの通知に応じて例えばフェイルオーバ等の処理が実行される。
When the
次に、図7を参照して、監視対象アプリケーション11を構成するスレッドによってロックが取得される際の処理の流れについて説明する。
Next, the flow of processing when a lock is acquired by a thread constituting the
まず、監視対象アプリケーション11を構成するスレッドは、資源を占有するためのロック取得要求をOS12に対して出力する。このスレッドは、例えば運用系ノードとして動作しているノード10において実行されているスレッドである。スレッドから出力されるロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
First, the thread constituting the
ジャケットライブラリ13のAPIフック部131は、監視対象アプリケーション11を構成するスレッドからのロック取得要求をフックする。APIフック部131は、ロック取得要求がフックされると、ロック状態管理部132を実行する(ステップS11)。このとき、APIフック部131は、フックされたロック取得要求に含まれるロックのアドレス及び当該ロック取得要求に応じてロックの取得が実行される旨(ロック取得の実行)をロック状態管理部132に通知する。
The
APIフック部131によってロック状態管理部132が実行されると、ロック状態管理部132は、APIフック部131によってフックされたロック取得要求の要求元であるスレッド(つまり、実行中のスレッド)を識別するためのスレッドIDをOS12に問い合わせる。これにより、ロック状態管理部132は、ロック取得要求の要求元であるスレッドのスレッドIDを取得する(ステップS12)。
When the lock
ロック状態管理部132は、APIフック部131から通知されたロックのアドレス及びOS12に問い合わせることにより取得されたスレッドIDにロック状態テーブル133において対応付けられているロックの取得状態に更新する。このとき、ロック状態管理部132は、APIフック部131からの通知の内容が「ロック取得の実行」であるため、ロックの取得状態を「ロック要求中」に更新する(ステップS13)。
The lock
次に、APIフック部131は、デッドロック検出部134を実行する(ステップS14)。このとき、APIフック部131は、フックされたロック取得要求に含まれるロックのアドレスをデッドロック検出部134に出力する。
Next, the
APIフック部131によってデッドロック検出部134が実行されると、デッドロック検出部134は、APIフック部131によってフックされたロック取得要求の要求元となるスレッドのスレッドIDを取得し、上記した図5に示すデッドロックの発生の検出処理を実行する(ステップS15)。
When the
デッドロック検出部134によってデッドロックの発生が検出されない場合(ステップS15のNO)、APIフック部131は、OS12のロック取得API(ロック取得部121)を実行する(ステップS16)。このとき、APIフック部131は、OS12にロックのアドレスを出力する。
If the occurrence of a deadlock is not detected by the deadlock detection unit 134 (NO in step S15), the
OS12のロック取得部121は、APIフック部131によって出力されたロックのアドレスに応じて、ロック取得処理を実行する(ステップS17)。このとき、ロック取得部121は、例えばロックが既に他のスレッドによって取得されている場合には、当該ロックが解放されるのを待ってからロック取得処理を実行する。ロック取得部121は、ロック取得処理が実行されると、ロック取得応答(返り値)を監視対象アプリケーション11に対して出力する。このロック取得応答には、取得処理が完了されたロックのアドレスが含まれる。
The
ジャケットライブラリ13のAPIフック部131は、OS12のロック取得部121によって出力されたロック取得応答をフックする。APIフック部131は、ロック取得応答をフックすると、ロック状態管理部132を実行する(ステップS18)。このとき、APIフック部131は、フックされたロック取得応答に含まれるロックのアドレス及び当該ロック取得応答が返された旨(ロック取得の応答)をロック状態管理部132に通知する。
The
APIフック部131によってロック状態管理部132が実行されると、ロック状態管理部132は、APIフック部131によってフックされたロック取得応答の元となるロック取得要求の要求元であるスレッドを識別するためのスレッドIDをOS12に問い合わせる。これにより、ロック状態管理部132は、スレッドIDを取得する(ステップS19)。
When the lock
ロック状態管理部132は、APIフック部131から通知されたロックのアドレス及びOS12に問い合わせることにより取得されたスレッドIDにロック状態テーブル133において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部132は、APIフック部131からの通知の内容が「ロック取得の応答」であるため、ロックの取得状態を「ロック中」に更新する(ステップS20)。
The lock
上記したような処理が実行された後、APIフック部131によりロック取得応答が監視対象アプリケーション11に返されると処理が終了される。
After the processing as described above is executed, when the lock acquisition response is returned to the
一方、ステップS15においてデッドロック検出部134によってデッドロックの発生が検出された場合、デッドロック検出部134は、デッドロック通知部135を実行する(ステップS21)。
On the other hand, when the occurrence of deadlock is detected by the
デッドロック検出部134によってデッドロック通知部135が実行されると、デッドロック通知部135は、デッドロックの発生をHAクラスタデーモン14に通知する(ステップS22)。
When the
デッドロック通知部135によってデッドロックの発生が通知されると、HAクラスタデーモン14は、監視対象アプリケーション11で障害が発生したものとしてサービスのフェイルオーバ等の対処を行う(ステップS23)。
When the
なお、上記したステップS23の処理が実行されると、HAクラスタデーモン14により監視対象アプリケーション11等の動作が停止される。
Note that when the processing in step S23 described above is executed, the operation of the
次に、図8を参照して、監視対象アプリケーション11を構成するスレッドによってロックが解放される際の処理の流れについて説明する。
Next, the flow of processing when a lock is released by a thread constituting the
まず、監視対象アプリケーション11を構成するスレッドは、当該スレッドがロックを取得している資源の占有を解放するためのロック解放要求をOS12に対して出力する。このロック解放要求には、当該ロック解放要求に応じて解放されるロックのアドレスが含まれる。
First, the thread constituting the
ジャケットライブラリ13のAPIフック部131は、監視対象アプリケーション11を構成するスレッドからのロック解放要求をフックする。APIフック部131は、ロック解放要求をフックすると、ロック状態管理部132を実行する(ステップS31)。このとき、APIフック部131は、フックされたロック解放要求に含まれるロックのアドレス及び当該ロック解放要求に応じてロックの解放が実行される旨(ロック解放の実行)をロック状態管理部132に通知する。
The
ここで、前述したように、APIフック部131からの通知の内容が「ロック解放の実行」である場合には、ロックの取得状態は変更しないためロック状態テーブル133の更新は実行されない。
Here, as described above, when the content of the notification from the
したがって、APIフック部131は、OS12のロック解放API(ロック解放部122)を実行する(ステップS32)。このとき、APIフック部131は、OS12にロックのアドレスを出力する。
Accordingly, the
OS12のロック解放部121は、APIフック部131によって出力されたロックのアドレスに応じて、ロック解放処理を実行する(ステップS33)。ロック解放部122は、ロック解放処理が実行されると、ロック解放応答(返り値)を監視対象アプリケーション11に対して出力する。このロック解放応答には、解放処理が完了されたロックのアドレスが含まれる。
The
ジャケットライブラリ13のAPIフック部131は、OS12のロック解放部122によって出力されたロック解放応答をフックする。APIフック部131は、ロック解放応答をフックすると、ロック状態管理部132を実行する(ステップS34)。このとき、APIフック部131は、フックされたロック解放応答に含まれるロックのアドレス及び当該ロック解放応答が返された旨(ロック解放の応答)をロック状態管理部132に通知する。
The
APIフック部131によってロック状態管理部132が実行されると、ロック状態管理部132は、APIフック部131によってフックされたロック解放応答の元となるロック解放要求の要求元であるスレッドを識別するためのスレッドIDをOS12に問い合わせる。これにより、ロック状態管理部132は、ロック解放応答の元となるロック解放要求の要求元であるスレッドを識別するためのスレッドIDを取得する(ステップS35)。
When the lock
ロック状態管理部132は、APIフック部131から通知されたロックのアドレス及びOS12に問い合わせることにより取得されたスレッドIDにロック状態テーブル133において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部132は、APIフック部131からの通知の内容が「ロック解放の応答」であるため、ロックの取得状態を「ロックなし」に更新する(ステップS36)。
The lock
上記したような処理が実行された後、APIフック部131によりロック解放応答が監視対象アプリケーション11に返されると処理が終了される。
After the processing as described above is executed, when the lock release response is returned to the
上記したように本実施形態においては、監視対象アプリケーション11を構成する複数のスレッドからのロック取得要求及びロック解放要求と、OS12からのロック取得応答及びロック解放応答をフックし、当該複数のスレッドのロックの取得状態をロック状態テーブル133において管理することによって、例えばスレッドからロック取得要求があった場合にデッドロックの発生を検出することが可能となる。
As described above, in the present embodiment, the lock acquisition request and the lock release request from the plurality of threads constituting the
これにより、本実施形態においては、例えば監視対象アプリケーション11の状態を監視する外部コマンドを定期的に実行することによって当該監視対象アプリケーション11で発生した障害を検出するような定期監視と併用することで、検出可能な障害範囲を拡大することが可能となる。したがって、監視対象アプリケーション11で障害が発生した状態でサービスが継続される可能性を低下させることが可能となり、サービスの信頼性を向上させることが可能となる。
As a result, in the present embodiment, for example, by periodically executing an external command for monitoring the state of the
また、本実施形態においては、デッドロックが発生するタイミング(イベントドリブン)で障害を検出することができるため、上記した定期監視のみで検出できる障害の場合であっても、監視対象アプリケーションで発生した障害を検出するまでの時間を短縮することが可能となる。これにより、サービス停止時間を短縮することが可能となるため、当該サービスの可用性を向上させることができる。 In the present embodiment, since a failure can be detected at the timing (event driven) when a deadlock occurs, even if the failure can be detected only by the regular monitoring described above, the failure occurred in the monitored application. It is possible to shorten the time until the failure is detected. As a result, the service stop time can be shortened, so that the availability of the service can be improved.
[第2の実施形態]
次に、図9を参照して、本発明の第2の実施形態について説明する。図9は、本実施形態に係るクラスタシステムに備えられるノード100の主として機能構成を示すブロック図である。なお、前述した図2と同様の部分には同一参照符号を付してその詳しい説明は省略する。ここでは、図2と異なる部分について主に述べる。以下の実施形態についても同様にして重複した説明を省略する。
[Second Embodiment]
Next, a second embodiment of the present invention will be described with reference to FIG. FIG. 9 is a block diagram mainly showing a functional configuration of the
図9に示すように、本実施形態に係るクラスタシステムに備えられるノード100上では、監視対象アプリケーション、OS120、ジャケットライブラリ130a及びジャケットライブラリ130bが動作する。
As shown in FIG. 9, the monitoring target application, the
前述した第1の実施形態においては、監視対象アプリケーションが1つのプロセスから構成されるものとして説明したが、本実施形態においては、監視対象アプリケーションが複数のプロセスから構成される場合を想定している。つまり、本実施形態においては、ノード100で監視対象のアプリケーションのプロセス110a及び110bを含む複数のプロセスが実行される。以下、監視対象のアプリケーションのプロセス110aを、単にプロセス110aと表記する。同様に、監視対象のアプリケーションのプロセス110bを、単にプロセス110bと表記する。
In the first embodiment described above, the monitoring target application has been described as being configured by one process. However, in the present embodiment, it is assumed that the monitoring target application is configured by a plurality of processes. . That is, in this embodiment, a plurality of processes including the
以下、監視対象アプリケーションを構成する複数のプロセスのうち、プロセス110a及び110bについて説明する。プロセス110a及び110b以外のプロセスについては、当該プロセス110a及び110bと同様である。
Hereinafter, the
なお、監視対象アプリケーションを構成するプロセス110a及び110bは、複数のスレッドから構成される。
Note that the
OS120は、プロセス110aとプロセス110bと当該プロセス110a及び110bを構成する複数のスレッドの各々とを管理する。この場合、OS120は、プロセス110a及び110bを識別するためのプロセスIDと当該プロセス110a及び110bを構成する複数のスレッドの各々を識別するためのスレッドIDを用いて実行中のスレッドを管理する。
The
OS120は、ロック状態テーブル123を含む。このロック状態テーブル123は、例えばノード100に備えられるメモリ(図示せず)内であって、OS120に割り当てられた複数のプロセス間で共有のメモリ空間にその領域が確保されている。
The
ロック状態テーブル123には、プロセス110a及び110bを構成する複数のスレッドによるロックの取得状態が登録される。
In the lock state table 123, lock acquisition states by a plurality of threads constituting the
ジャケットライブラリ130aは、プロセス110aを構成する複数のスレッドの各々からのOS120に対するロック取得要求及びロック解放要求をフック(取得)することで、当該複数のスレッドの各々によるロックの取得状態を管理する。ジャケットライブラリ130aは、フックされたロック取得要求及び複数のスレッドの各々によるロックの取得状態に基づいてデッドロックの発生を検出する。ジャケットライブラリ130aは、デッドロックの発生が検出された場合、その旨をHAクラスタデーモン14に通知する。
The
なお、ジャケットライブラリは、プロセス毎に対応している。つまり、例えばプロセス110aにはジャケットライブラリ130aが対応しており、プロセス110bにはジャケットライブラリ130bが対応している。この場合、ジャケットライブラリ130aはプロセス110aからのロック取得要求等に応じた処理を実行し、ジャケットライブラリ130bはプロセス110bからのロック取得要求等に応じた処理を実行する。
Note that the jacket library corresponds to each process. That is, for example, the
以下、主にジャケットライブラリ130aの構成等について説明するが、ジャケットライブラリ130bについても当該ジャケットライブラリ130aと同様である。
Hereinafter, the configuration and the like of the
ジャケットライブラリ130aは、ロック状態管理部136及びデッドロック検出部137を含む。
The
本実施形態において、ロック状態管理部136及びデッドロック検出部137は、ノード100のコンピュータ(図示せず)が例えばノード100に備えられるメモリに格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
In the present embodiment, the lock
ロック状態管理部136は、APIフック部131によってフックされたロック取得要求またはロック解放要求の要求元であるスレッド(を含む複数のスレッド)から構成される)プロセス110aを識別するためのプロセスIDを、OS120に問い合わせる。これにより、ロック状態管理部136は、プロセスIDを取得する。
The lock
また、ロック状態管理部136は、APIフック部131からの通知を受けると、ロック取得要求またはロック解放要求の要求元であるスレッドを識別するためのスレッドIDを、OS120に問い合わせる。これにより、ロック状態管理部136は、スレッドIDを取得する。
In addition, when the notification from the
ロック状態管理部136は、APIフック部131からの通知、取得されたプロセスID及びスレッドIDに基づいてロック状態テーブル123を更新する。つまり、本実施形態においては、前述した第1の実施形態とは異なり、プロセスID、スレッドID及びロックのアドレスの3次元の組み合わせに対してロックの取得状態が管理(登録)される。
The lock
なお、ロック状態テーブル123には、上記したようにプロセス110a及び110bを構成する複数のスレッドによるロックの取得状態が登録されるが、ジャケットライブラリ130aのロック状態管理部136は、プロセス110aを構成する複数のスレッドによるロックの取得状態をロック状態テーブル123に登録(更新)する。つまり、プロセス110bを構成する複数のスレッドによるロックの取得状態は、ジャケットライブラリ130bのロック状態管理部(図示せず)によって登録される。
In the lock state table 123, as described above, the lock acquisition state by a plurality of threads constituting the
ロック状態管理部136は、更新するプロセスID、スレッドIDまたはロックのアドレスがロック状態テーブル123に登録されていないときは当該ロック状態テーブル123を拡張する。
When the process ID, thread ID, or lock address to be updated is not registered in the lock state table 123, the lock
デッドロック検出部137は、APIフック部131からの要求に基づいて、ロックの取得によってデッドロックが発生するか否かを確認する。これにより、デッドロック検出部137は、デッドロックの発生を検出する。
The
このとき、デッドロック検出部137は、APIフック部131によってフックされたロック取得要求の要求元であるスレッドから構成されるプロセス110aを識別するためのプロセスIDをOS120に問い合わせる。これにより、デッドロック検出部137は、プロセス110aのプロセスIDを取得する。また、デッドロック検出部137は、APIフック部131によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドIDをOS120に問い合わせることにより、当該スレッドIDを取得する。
At this time, the
デッドロック検出部137は、取得されたプロセスID、スレッドID及びAPIフック部131によって出力されたロックのアドレスと、ロック状態テーブル123に登録されているロック取得状態とに基づいて、デッドロックの発生を検出する。デッドロックの発生が検出された場合、デッドロック検出部137は、デッドロック通知部135に当該デッドロックの発生の通知要求を出力する。
The
なお、ジャケットライブラリ130bの構成については、上記したようにジャケットライブラリ130aと同様の構成であるため、図9において省略されている。また、ジャケットライブラリ130bの構成の詳しい説明は省略する。
The configuration of the
次に、図10を参照して、プロセス110aを構成するスレッドによってロックが取得される際の処理の流れについて説明する。
Next, the flow of processing when a lock is acquired by a thread constituting the
まず、プロセス110aを構成するスレッドは、資源を占有するためのロック取得要求をOS120に対して出力する。このロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
First, the thread constituting the
次に、前述した図7に示すステップS11の処理に相当するステップS41の処理が実行される。 Next, the process of step S41 corresponding to the process of step S11 shown in FIG. 7 is executed.
ロック状態管理部136は、APIフック部131によってフックされたロック取得要求の要求元であるスレッドから構成されるプロセス110aを識別するためのプロセスIDをOS120に問い合わせる。これにより、ロック状態管理部136は、プロセス110aのプロセスIDを取得する(ステップS42)。
The lock
ステップS42の処理が実行されると、前述した図7に示すステップS12の処理に相当するステップS43の処理が実行される。 When the process of step S42 is executed, the process of step S43 corresponding to the process of step S12 shown in FIG. 7 described above is executed.
ロック状態管理部136は、APIフック部131から通知されたロックのアドレス、ステップS42において取得されたプロセスID及びステップS43において取得されたスレッドIDに対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部132は、APIフック部131からの通知の内容が「ロック取得の実行」であるため、ロック状態テーブル123におけるロックの取得状態を「ロック要求中」に更新する(ステップS44)。
The lock
次に、デッドロック検出部137は、デッドロックの発生の検出処理を実行する(ステップS46)。このとき、デッドロック検出部137は、APIフック部131によってフックされたロック取得要求の要求元であるスレッドを含むプロセス110aを識別するためのプロセスIDをOS120に問い合わせることにより、当該プロセスIDを取得する。また、デッドロック検出部137は、APIフック部131によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドIDをOS120に問い合わせることにより、当該スレッドIDを取得する。デッドロック検出部137は、取得されたプロセスID、スレッドID、APIフック部131によって出力されたロックのアドレス及びロック状態テーブル123に登録されているロックの取得状態に基づいてデッドロックの発生を検出する。このロック状態テーブル123には、プロセス110a及び110bを含む複数のプロセスを構成するスレッドによるロックの取得状態が登録されている。
Next, the
なお、デッドロック検出部137によるデッドロックの発生の検出処理は、前述した図5に示す処理において例えばプロセスID及びスレッドIDの組をT、ロックのアドレスをLとした場合と同様であるため、その詳しい説明は省略する。
The deadlock generation detection process by the
デッドロック検出部137によってデッドロックの発生が検出されない場合(ステップS46のNO)、前述した図7に示すステップS16〜ステップS18の処理に相当するステップS47〜ステップS49の処理が実行される。
When the
次に、ロック状態管理部136は、APIフック部131によってフックされたロック取得応答の元となるロック取得要求の要求元であるスレッドから構成されるプロセス110aを識別するためのプロセスIDをOS120に問い合わせる。これにより、ロック状態管理部136は、プロセス110aのプロセスIDを取得する(ステップS50)。
Next, the lock
ステップS50の処理が実行されると、前述した図7のステップS19の処理に相当するステップS51の処理が実行される。 When the process of step S50 is executed, the process of step S51 corresponding to the process of step S19 of FIG. 7 described above is executed.
ロック状態管理部136は、APIフック部131から通知されたロックのアドレス、取得されたプロセスID及びスレッドIDにロック状態テーブル123において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部136は、APIフック部131からの通知の内容が「ロック取得の応答」であるため、ロック状態テーブル123におけるロックの取得状態を「ロック中」に更新する(ステップS20)。
The lock
一方、ステップS46においてデッドロック検出部137によってデッドロックの発生が検出された場合、前述した図7に示すステップS21〜ステップS23の処理に相当するステップS53〜ステップS55の処理が実行される。
On the other hand, when occurrence of a deadlock is detected by the
なお、プロセス110bを構成するスレッドによってロックが取得される場合には、上記した図10に示す処理と同様の処理がジャケットライブラリ130bにおいて実行されるため、その詳しい説明は省略する。
Note that when the lock is acquired by the thread constituting the process 110b, the same processing as the processing shown in FIG. 10 described above is executed in the
次に、図11を参照して、プロセス110aを構成するスレッドによってロックが解放される際の処理の流れについて説明する。
Next, with reference to FIG. 11, the flow of processing when a lock is released by a thread constituting the
まず、プロセス110aを構成するスレッドは、当該スレッドがロックを取得している資源の占有を解放するためのロック解放要求をOS120に対して出力する。このロック解放要求には、当該ロック解放要求に応じて解放されるロックのアドレスが含まれる。
First, the thread constituting the
次に、前述した図8に示すステップS31〜ステップS34の処理に相当するステップS61〜ステップS64の処理が実行される。 Next, the process of step S61-step S64 equivalent to the process of step S31-step S34 shown in FIG. 8 mentioned above is performed.
ロック状態管理部136は、APIフック部131によってフックされたロック解放応答の元となるロック解放要求の要求元であるスレッドから構成されるプロセス110aを識別するためのプロセスIDをOS120に問い合わせる。これにより、ロック状態管理部136は、プロセス110aのプロセスIDを取得する(ステップS65)。
The lock
ステップS65の処理が実行されると、前述した図8に示すステップS35の処理に相当するステップS66の処理が実行される。 When the process of step S65 is executed, the process of step S66 corresponding to the process of step S35 shown in FIG. 8 described above is executed.
次に、ロック状態管理部136は、APIフック部131から通知されたロックのアドレス、ステップS65において取得されたプロセスID及びステップS66において取得されたスレッドIDにロック状態テーブル123において対応付けられているロックの取得状態を更新する。このとき、ロック状態管理部136は、APIフック部131からの通知の内容が「ロック解放の応答」であるため、ロック状態テーブル123におけるロックの取得状態を「ロックなし」に更新する(ステップS67)。
Next, the lock
なお、プロセス110bを構成するスレッドによってロックが解放される場合には、上記した図11に示す処理と同様の処理がジャケットライブラリ130bにおいて実行されるため、その詳しい説明は省略する。
Note that when the lock is released by the thread constituting the process 110b, the same processing as the processing shown in FIG. 11 described above is executed in the
上記したように本実施形態においては、監視対象アプリケーションを構成する複数のプロセス(プロセス110a及びプロセス110b)を構成する複数のスレッドからのロック取得要求及びロック解放要求と、OS120からのロック取得応答及びロック解放応答とをフックし、当該複数のスレッドのロックの取得状態をロック状態テーブル123において管理することによって例えばスレッドからロック取得要求があった場合にデッドロックの発生を検出することが可能となる。つまり、本実施形態においては、前述した第1の実施形態とは異なり、例えば監視対象アプリケーションを構成する複数のプロセス間のデッドロックもイベントドリブンで検出すること可能となる。これにより、本実施形態は、例えばマルチプロセスのアプリケーションに対しても適用することができる。
As described above, in the present embodiment, lock acquisition requests and lock release requests from a plurality of threads that configure a plurality of processes (
[第3の実施形態]
次に、図12を参照して、本発明の第3の実施形態について説明する。図12は、本実施形態に係るクラスタシステムに備えられるノード200の機能構成を示すブロック図である。
[Third Embodiment]
Next, a third embodiment of the present invention will be described with reference to FIG. FIG. 12 is a block diagram showing a functional configuration of the
ノード200上では、OS210及びジャケットライブラリ220が動作する。OS210は、ロック作成部211及びスレッド作成部212を含む。
On the
スレッド作成部211は、例えば監視対象アプリケーション11からのスレッド作成要求に応じて、当該監視対象アプリケーション11を構成するスレッドを作成する。このスレッド作成要求は、スレッドを開始する関数のアドレス(以下、関数アドレスと表記)を指定することにより行われる。また、スレッド作成要求は、例えば監視対象アプリケーション11が起動された際に適宜出力される。スレッド作成部211は、スレッド作成要求に応じてスレッドが作成された場合、当該スレッド作成要求に対する応答として当該スレッドを識別するためのスレッドIDを監視対象アプリケーション11に対して返す。
For example, in response to a thread creation request from the
ロック作成部212は、例えば監視対象アプリケーション11を構成する複数のスレッドからのロック作成要求に応じて、資源を占有するためのロックを新たに作成する。このロック作成要求は、例えば上記したスレッド作成部211によってスレッドが作成された後に、当該スレッドから必要に応じて出力される。ロック作成部212は、ロック作成要求に応じてロックが作成された場合、当該ロック作成要求に対する応答として当該ロックのアドレスを監視対象アプリケーション11に対して返す。
The
図12に示すように、ジャケットライブラリ220は、APIフック部221、ロック/スレッド対応付け部222、スレッド対応テーブル223、ロック対応テーブル224、デッドロック検出部225、デッドロック情報作成部226、デッドロック情報読込部227、サスペンド判定部228を含む。
As illustrated in FIG. 12, the
本実施形態において、APIフック部221、ロック/スレッド対応付け部222、デッドロック検出部225、デッドロック情報作成部226、デッドロック情報読込部227及びサスペンド判定部228は、ノード200のコンピュータ(図示せず)が例えばノード200に備えられるメモリ(図示せず)に格納されているプログラムを実行することにより実現されるものとする。このプログラムは、コンピュータ読取可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してコンピュータにダウンロードされても構わない。
In the present embodiment, the
また、本実施形態において、スレッド対応テーブル223及びロック対応テーブル224は、例えばノード200に備えられるメモリ内であって、監視対象アプリケーション11(を構成するプロセス)に与えられたメモリ空間にその領域が確保されている。
Further, in the present embodiment, the thread correspondence table 223 and the lock correspondence table 224 are, for example, in a memory provided in the
APIフック部221は、監視対象アプリケーション11からのOS210に対するスレッド作成要求及びロック作成要求をフックする。APIフック部221は、フックされたスレッド作成要求及びロック作成要求をOS210に出力する。
The
APIフック部221は、スレッド作成要求に応じてスレッドが作成された後に、当該スレッド作成要求に対する応答をフックする。このフックされた応答には、スレッド作成要求に応じて作成されたスレッドを識別するためのスレッドIDが含まれる。APIフック部221は、フックされた応答に含まれるスレッドIDをロック/スレッド対応付け部222に対して出力することで、当該ロック/スレッド対応付け部222にスレッド対応テーブル223の更新を要求する。
The
また、APIフック部221は、ロック作成要求に応じてロックが作成された後に、当該ロック作成要求に対する応答をフックする。このフックされた応答には、ロック作成要求に応じて作成されたロックのアドレスが含まれる。APIフック部221は、フックされた応答に含まれるロックのアドレスをロック/スレッド対応付け部222に対して出力することで、当該ロック/スレッド対応付け部222にロック対応テーブル224の更新を要求する。
The
APIフック部221は、ロック取得要求がフックされた場合、当該ロック取得要求に含まれるロックのアドレスをサスペンド判定部228に出力することにより、当該ロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かの判定を要求する。
When the lock acquisition request is hooked, the
ロック/スレッド対応付け部222は、APIフック部221からの要求に応じてスレッド対応テーブル223を更新する。また、ロック/スレッド対応付け部222は、APIフック部221からの要求に応じてロック対応テーブル224を更新する。
The lock /
スレッド対応テーブル223には、OS210のスレッド作成部211によって作成されたスレッドを識別するためのスレッドIDと当該スレッドを開始するときの関数アドレスとの組み合わせの情報が保持される。この関数アドレスは、上記したスレッド作成要求において指定される。
The thread correspondence table 223 holds information on a combination of a thread ID for identifying a thread created by the thread creation unit 211 of the
ロック対応テーブル224は、OS210のロック作成部212によって作成されたロックのアドレスと当該ロックを作成したスレッド(ロック作成要求の要求元となるスレッド)を識別するためのスレッドIDとの組み合わせの情報が保持される。
The lock correspondence table 224 includes information on the combination of the address of the lock created by the
デッドロック検出部225は、デッドロックの発生が検出された場合、デッドロック情報作成部226に対して当該デッドロックを示すデッドロック状況情報の作成を要求する。
When the occurrence of a deadlock is detected, the
デッドロック情報作成部226は、デッドロック検出部225からの要求に応じて、デッドロック検出部225によって検出されたデッドロックを示すデッドロック状況情報を作成する。このとき、デッドロック情報作成部226は、スレッド対応テーブル223、ロック対応テーブル224及びロック状態テーブル133を参照して作成処理を実行する。デッドロック情報作成部226は、作成されたデッドロック状況情報を共有ディスク30に格納する。
The deadlock
デッドロック情報読込部227は、サスペンド判定部228の要求に応じて、共有ディスク30に格納されているデッドロック状況情報を読み込む。デッドロック情報読込部227は、共有ディスク30から読み込まれたデッドロック状況情報をサスペンド判定部228に出力する。
The deadlock
サスペンド判定部228は、APIフック部221からの要求を受けると、APIフック部221によってフックされたロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かを判定する。このとき、サスペンド判定部228は、スレッド対応テーブル223、ロック対応テーブル224及びロック状態テーブル133を参照して判定処理を実行する。また、サスペンド判定部228は、デッドロック情報読込部227によって出力されたデッドロック状況情報に基づいて判定処理を実行する。サスペンド判定部228の処理の詳細については後述する。
When receiving the request from the
図13は、図12に示すスレッド対応テーブル223のデータ構造の一例を示す。図13に示すように、スレッド対応テーブル223には、スレッドを開始するときの関数アドレス(スレッド開始時の関数アドレス)及び当該スレッドを識別するためのスレッドIDが対応付けて保持される。 FIG. 13 shows an example of the data structure of the thread correspondence table 223 shown in FIG. As shown in FIG. 13, in the thread correspondence table 223, a function address when starting a thread (function address at the time of starting the thread) and a thread ID for identifying the thread are held in association with each other.
つまり、スレッド対応テーブル223には、スレッド作成要求において指定された関数アドレス及び当該スレッド作成要求に応じて作成されたスレッドのスレッドIDが対応付けて保持される。 That is, the thread correspondence table 223 holds the function address specified in the thread creation request and the thread ID of the thread created in response to the thread creation request in association with each other.
また、例えば同一の関数アドレスから開始されるスレッドが複数存在する場合には、当該スレッドのスレッドIDは当該スレッドの作成順にスレッド対応テーブル223において保持される。 For example, when there are a plurality of threads started from the same function address, the thread ID of the thread is stored in the thread correspondence table 223 in the order of creation of the thread.
なお、上記したようにスレッド対応テーブル223は、監視対象アプリケーション11からスレッド作成要求が出力され、当該スレッド作成要求に応じてスレッドが作成された際にロック/スレッド対応付け部222によって更新される。
As described above, the thread correspondence table 223 is updated by the lock /
図13に示す例では、スレッド対応テーブル223には、スレッド開始時の関数アドレス「F1」に対応付けてスレッドID「T1→T2」が保持されている。これによれば、スレッド開始時の関数アドレスが「F1」であるスレッドを識別するスレッドIDが「T1」及び「T2」であることが示される。また、T1によって識別されるスレッド、T2によって識別されるスレッドの順に当該スレッドが作成されたことが示される。 In the example shown in FIG. 13, the thread correspondence table 223 holds the thread ID “T1 → T2” in association with the function address “F1” at the start of the thread. According to this, it is indicated that the thread IDs for identifying the thread whose function address is “F1” at the start of the thread are “T1” and “T2”. Further, it is shown that the threads are created in the order of the thread identified by T1 and the thread identified by T2.
また、スレッド対応テーブル223には、スレッド開始時の関数アドレス「F2」に対応付けてスレッドID「T3→T4→T5」が保持されている。これによれば、スレッド開始時の関数アドレスが「F2」であるスレッドを識別するスレッドIDが「T3」、「T4」及び「T5」であることが示される。また、T3によって識別されるスレッド、T4によって識別されるスレッド、T5によって識別されるスレッドの順に当該スレッドが作成されたことが示される。 The thread correspondence table 223 holds a thread ID “T3 → T4 → T5” in association with the function address “F2” at the start of the thread. This indicates that the thread IDs for identifying the thread whose function address at the start of the thread is “F2” are “T3”, “T4”, and “T5”. Further, it is shown that the threads are created in the order of the thread identified by T3, the thread identified by T4, and the thread identified by T5.
なお、スレッド対応テーブル223は、例えば監視対象アプリケーション11が再起動された場合またはフェイルオーバが実行され、運用系ノードの処理を引き継ぐために監視対象アプリケーション11が起動された場合等に、スレッドを前回の起動時と対応付けるために用いられる。したがって、同一の関数アドレスで開始されるスレッドの作成順序が異なる場合にはスレッドの対応付けに失敗するが、一般的なアプリケーションでは同一の関数のスレッド作成順序は同一となる実装であることが多い。特にHAクラスタシステムでは、サービスを継続するため、引継ぎ後も引継ぎ前と同じ動作をするように設定している場合がほとんどであるので、スレッド作成順序は同一となる。よって、本実施形態においては、同一の関数アドレスで開始されるスレッドの作成順序は同一であることを前提としている。
The thread correspondence table 223 indicates that, for example, when the
図14は、図12に示すロック対応テーブル224のデータ構造の一例を示す。図14に示すように、ロック対応テーブル224には、監視対象アプリケーション11を構成するスレッドを識別するためのスレッドID及び当該スレッドからのロック作成要求に応じてロック作成部212によって作成されたロックのアドレスが対応付けて保持されている。
FIG. 14 shows an example of the data structure of the lock correspondence table 224 shown in FIG. As shown in FIG. 14, the lock correspondence table 224 includes a thread ID for identifying a thread constituting the
また、例えば同一のスレッドからのロック作成要求に応じてロック作成部212によって作成されたロックのアドレスが複数存在する場合には、ロックのアドレスは作成順にロック対応テーブル224において保持される。
For example, if there are a plurality of lock addresses created by the
なお、上記したようにロック対応テーブル224は、監視対象アプリケーション11を構成するスレッドからロック作成要求が出力され、当該ロック作成要求に応じてロックが作成された際にロック/スレッド対応付け部222によって更新される。
As described above, the lock correspondence table 224 is output by the lock /
図14に示す例では、ロック対応テーブル224には、スレッドID「T1」に対応付けてロックのアドレス「L1→L2」が保持されている。これによれば、ロックのアドレスが「L1」及び「L2」であるロックが、スレッドID「T1」によって識別されるスレッドからのロック作成要求に応じて作成されたことが示される。また、ロックのアドレスが「L1」であるロック、ロックのアドレスが「L2」であるロックの順に当該ロックが作成されたことが示される。 In the example illustrated in FIG. 14, the lock correspondence table 224 holds the lock address “L1 → L2” in association with the thread ID “T1”. According to this, it is indicated that the locks whose lock addresses are “L1” and “L2” were created in response to a lock creation request from the thread identified by the thread ID “T1”. Further, it is indicated that the locks are created in the order of the lock having the lock address “L1” and the lock having the lock address “L2”.
また、ロック対応テーブル224には、スレッドID「T2」に対応付けてロックのアドレス「L3→L4→L5」が保持されている。これによれば、ロックのアドレスが「L3」、「L4」及び「L5」であるロックが、スレッドID「T2」によって識別されるスレッドからのロック作成要求に応じて作成されたことが示される。また、ロックのアドレスが「L3」であるロック、ロックのアドレスが「L4」であるロック、ロックのアドレスが「L5」であるロックの順に当該ロックが作成されたことが示されている。 Further, the lock correspondence table 224 holds a lock address “L3 → L4 → L5” in association with the thread ID “T2”. According to this, it is indicated that the locks whose lock addresses are “L3”, “L4”, and “L5” were created in response to a lock creation request from the thread identified by the thread ID “T2”. . Further, it is shown that the locks are created in the order of a lock whose lock address is “L3”, a lock whose lock address is “L4”, and a lock whose lock address is “L5”.
なお、上記したスレッド対応テーブル223と同様に、ロック対応テーブル224においても、同一のスレッドにおけるロックの作成順序は同一であることを前提としている。 Similar to the thread correspondence table 223 described above, the lock correspondence table 224 also assumes that the lock creation order in the same thread is the same.
図15は、共有ディスク30に格納されるデッドロック状況情報のデータ構造の一例を示す。デッドロック状況情報には、スレッド、他のスレッドを止めているロック(ロック中であるロック)及び取得要求中のロックが対応付けて含まれる。また、デッドロック状況情報においては、当該デッドロック状況情報に含まれるスレッド、他のスレッドを止めているロック及び取得要求中のロックは、スレッドID及びロックのアドレスを用いることなく、上記した図13及び図14に示すような関数アドレス及びスレッド及びロックの作成順を用いて示される。ここでは、適宜図13及び図14を用いて説明する。
FIG. 15 shows an example of the data structure of deadlock status information stored in the shared
ここで、図15に示すデッドロック状況情報は、前述した図6に示すロックの取得状態のようなデッドロック(図6のデッドロック)を示すものとする。 Here, it is assumed that the deadlock status information shown in FIG. 15 indicates a deadlock (deadlock in FIG. 6) like the lock acquisition state shown in FIG.
図15に示すように、図6のデッドロックを示すデッドロック状況情報には、スレッドとして「F1の1番目」、他のスレッドを止めているロックとして「F1の1番目のスレッドの1番目」、取得要求中のロックとして「F1の2番目のスレッドの1番目」が対応付けて含まれる。 As shown in FIG. 15, the deadlock status information indicating the deadlock of FIG. 6 includes “first of F1” as a thread and “first of the first thread of F1” as a lock that stops other threads. As a lock in the acquisition request, “first of the second thread of F1” is associated and included.
この「F1の1番目」は、スレッド対応テーブル223において関数アドレス「F1」に対応付けられているスレッドIDによって識別されるスレッドであって、1番目に作成されたスレッドを表している。つまり、図14に示すスレッド対応テーブル223の例では、T1によって識別されるスレッドを表している。 The “first of F1” is a thread identified by the thread ID associated with the function address “F1” in the thread correspondence table 223, and represents the first created thread. That is, the example of the thread correspondence table 223 shown in FIG. 14 represents a thread identified by T1.
「F1の1番目のスレッドの1番目」は、図15に示すロック対応テーブル224において上記した「F1の1番目のスレッド(ここでは、T1によって識別されるスレッド)」に対応付けられているロック(のアドレス)であって、1番目に作成されたロック(ここでは、ロックのアドレスが「L1」であるロック)を表している。 “First of the first thread of F1” is a lock associated with “the first thread of F1 (here, the thread identified by T1)” in the lock correspondence table 224 shown in FIG. Represents the first created lock (here, the lock whose lock address is “L1”).
「F1の2番目のスレッドの1番目」は、同様に、図15に示すロック対応テーブル224において「F1の2番目のスレッド(ここでは、T2によって識別されるスレッド)」に対応付けられているロックであって、1番目に作成されたロック(ここでは、ロックのアドレスが「L3」であるロック)を表している。 Similarly, “the first of the second threads of F1” is associated with “the second thread of F1 (here, the thread identified by T2)” in the lock correspondence table 224 illustrated in FIG. This is a lock and represents the first created lock (here, a lock whose lock address is “L3”).
図15における上記した以外のスレッド、他のスレッドを止めているロック及び取得要求中のロックについても同様である。 The same applies to threads other than those described above in FIG. 15, locks that stop other threads, and locks that are in acquisition requests.
デッドロック状況情報においては、デッドロックを上記したような表し方を用いることで、例えば複数のノード200間において同一のスレッドであるにもかかわらず異なるスレッドIDが付与された場合等であっても、スレッドが作成された順を用いることで異なるノード間においてもスレッドの対応付けが可能となる。また、ロック(のアドレス)についても同様である。
In the deadlock status information, by using the way of expressing deadlock as described above, for example, even when different thread IDs are given among a plurality of
次に、図16を参照して、上記した新たにスレッドが作成される処理(スレッド作成処理)の流れについて説明する。このスレッド作成処理は、例えばノード200において監視対象アプリケーション11が再起動された場合やフェイルオーバが実行され、待機系ノードとして動作していたノード200が運用系ノードとして動作する際に監視対象アプリケーション11が起動された場合等に実行される。
Next, with reference to FIG. 16, the flow of the above-described process for creating a new thread (thread creation process) will be described. For example, when the monitored
まず、例えば監視対象アプリケーション11が起動されると、当該監視対象アプリケーション11は、スレッドの作成を要求するためにスレッド作成要求をOS210に対して出力する。このスレッド作成要求は、監視対象アプリケーション11がスレッドを開始するときの関数アドレスを指定することにより行う。
First, for example, when the
ジャケットライブラリ220のAPIフック部221は、監視対象アプリケーション11からのスレッド作成要求をフックする。APIフック部221は、スレッド作成要求がフックされると、OS210のスレッド作成API(スレッド作成部211)を実行する(ステップS71)。このとき、APIフック部221は、スレッド作成要求をスレッド作成部211に出力する。
The
OS210のスレッド作成部211は、APIフック部221によって出力されたスレッド作成要求に応じて、スレッドの作成処理を実行する(ステップS72)。このとき、スレッド作成部211は、スレッド作成要求において指定された関数アドレスに基づいてスレッドを作成する。
The thread creation unit 211 of the
スレッド作成部211は、スレッドの作成処理が実行されると、当該作成されたスレッドを識別するためのスレッドIDを、スレッド作成要求に対する応答として監視対象アプリケーション11に対して出力する。
When the thread creation process is executed, the thread creation unit 211 outputs a thread ID for identifying the created thread to the
ジャケットライブラリ220のAPIフック部221は、OS210(のスレッド作成部211)からのスレッドID(スレッド作成要求に対する応答)をフックする。APIフック部221は、スレッドIDがフックされると、ロック/スレッド対応付け部222を実行する(ステップS73)。このとき、APIフック部221は、フックされたスレッドIDを、ロック/スレッド対応付け部222に対して出力する。
The
APIフック部211によってロック/スレッド対応付け部222が実行されると、ロック/スレッド対応付け部222は、スレッド対応テーブル223を更新する(ステップS74)。ロック/スレッド対応付け部222は、スレッド作成要求において指定された関数アドレス及びAPIフック部221によって出力されたスレッドIDを対応付けてスレッド対応テーブル223に登録する。
When the lock /
上記した処理が実行された後、APIフック部221によりスレッド作成要求に対する応答としてのスレッドIDが監視対象アプリケーション11に返されると処理が終了される。
After the above process is executed, the process is terminated when the
次に、図17を参照して、上記した新たにロックが作成される処理(ロック作成処理)の流れについて説明する。このロック作成処理は、例えば上記したスレッド作成処理においてスレッドが作成された後に実行される。 Next, with reference to FIG. 17, the flow of the above-described process for creating a new lock (lock creation process) will be described. This lock creation process is executed, for example, after a thread is created in the thread creation process described above.
まず、例えば上記した図16に示すようにスレッドが作成されると、当該スレッドは、必要に応じて新たなロックの作成を要求するためにロック作成要求を出力する。 First, for example, when a thread is created as shown in FIG. 16 described above, the thread outputs a lock creation request to request creation of a new lock as necessary.
ジャケットライブラリ220のAPIフック部221は、監視対象アプリケーション11からのロック作成要求をフックする。APIフック部221は、ロック作成要求がフックされると、OS210のロック作成API(ロック作成部212)を実行する(ステップS81)。このとき、APIフック部221は、ロック作成要求をロック作成部212に出力する。
The
OS210のロック作成部212は、APIフック部221によって出力されたロック作成要求に応じて、ロックの作成処理を実行する(ステップS82)。
The
ロック作成部212は、ロックの作成処理が実行されると、当該作成されたロックのアドレスを、ロック作成要求に対する応答として監視対象アプリケーション11に対して出力する。
When the lock creation process is executed, the
APIフック部221は、OS210(ロック作成部212)からのロックのアドレス(ロック作成要求に対する応答)をフックする。APIフック部221は、ロックのアドレスがフックされると、ロック/スレッド対応付け部222を実行する(ステップS83)。このとき、APIフック部221は、フックされたロックのアドレスを、ロック/スレッド対応付け部222に対して出力する。
The
APIフック部211によってロック/スレッド対応付け部222が実行されると、ロック/スレッド対応付け部222は、ロック作成要求の要求元となるスレッドを識別するためのスレッドIDをOS210に対して問い合わせる。これにより、ロック/スレッド対応付け部222は、ロック作成要求の要求元となるスレッドのスレッドIDを取得する(ステップS84)。
When the lock /
次に、ロック/スレッド対応付け部222は、ロック対応テーブル224を更新する(ステップS85)。ロック/スレッド対応付け部222は、APIフック部221によって出力されたロックのアドレス及び取得されたスレッドIDを対応付けてロック対応テーブル224に登録する。
Next, the lock /
上記した処理が実行された後、APIフック部221によりロック作成要求に対する応答としてロックのアドレスが監視対象アプリケーション11に返されると処理が終了される。
After the processing described above is executed, the processing is ended when the lock address is returned to the
次に、図18を参照して、監視対象アプリケーション11を構成するスレッドによってロックが取得される際の処理の流れについて説明する。
Next, with reference to FIG. 18, the flow of processing when a lock is acquired by a thread constituting the
まず、監視対象アプリケーション11を構成するスレッドは、資源を占有するためのロック取得要求をOS210に対して出力する。このロック取得要求には、当該ロック取得要求に応じて取得されるロックのアドレスが含まれる。
First, the thread configuring the
ジャケットライブラリ220のAPIフック部221は、監視対象アプリケーション11を構成するスレッドからのロック取得要求をフックする。APIフック部221は、ロック取得要求がフックされると、サスペンド判定部228を実行する(ステップS91)。このとき、APIフック部221は、フックされたロック取得要求に含まれるロックのアドレスをサスペンド判定部228に出力する。
The
APIフック部221によってサスペンド判定部228が実行されると、サスペンド判定部228は、APIフック部221によってフックされたロック取得要求の要求元であるスレッドを識別するためのスレッドIDをOS210に問い合わせる。これにより、サスペンド判定部228は、ロック取得要求の要求元であるスレッドのスレッドIDを取得する(ステップS92)。
When the suspend
サスペンド判定部228は、APIフック部221によって出力されたロックのアドレス、取得されたスレッドID及び共有ディスク30に格納されているデッドロック状況情報に基づいて、ロック取得要求に応じて実行されるロック取得処理をサスペンドすべきか否かを判定する処理(以下、サスペンド判定処理と表記)を実行する(ステップS93)。このとき、サスペンド判定部228は、スレッド対応テーブル223、ロック対応テーブル224及びロック状態テーブル133を参照してサスペンド判定処理を実行する。このサスペンド判定処理の詳細については後述する。
The suspend
次に、前述した図7に示すステップS11〜ステップS20に相当するステップS94〜ステップS103の処理が実行され、処理が終了される。 Next, steps S94 to S103 corresponding to steps S11 to S20 shown in FIG. 7 described above are executed, and the process is terminated.
一方、ステップS98においてデッドロック検出部225によってデッドロックの発生が検出されたと判定された場合、デッドロック検出部225は、デッドロック情報作成部226を実行する(ステップS104)。デッドロック検出部225は、デッドロック情報作成部226に対して、デッドロック状況情報の作成を要求する。
On the other hand, if it is determined in step S98 that the deadlock has been detected by the
このとき、デッドロック検出部225によってデッドロックの発生が検出されているため、ロック状態テーブル133に登録されているロックの取得状態はデッドロックを表している。よって、デッドロック情報作成部226は、ロック状態テーブル133に登録されているロックの取得状態に基づいて、デッドロックを示すデッドロック状況情報を作成する。このとき、デッドロック情報作成部226は、スレッド対応テーブル223及びロック対応テーブル224を参照して、上記した図15に示すように関数アドレス及びスレッド及びロックの作成順を用いてデッドロック状況情報を作成する。
At this time, since the occurrence of a deadlock is detected by the
デッドロック情報作成部226は、作成されたデッドロック状況情報を共有ディスク30に格納する。
The deadlock
次に、前述した図7に示すステップS21〜ステップS23の処理に相当するステップS106〜ステップS108の処理が実行され、処理が終了される。 Next, the process of step S106-step S108 equivalent to the process of step S21-step S23 shown in FIG. 7 mentioned above is performed, and a process is complete | finished.
次に、図19のフローチャートを参照して、上記したサスペンド判定部228によるサスペンド判定処理の処理手順について説明する。
Next, the processing procedure of the suspend determination process by the suspend
このサスペンド判定部228によるサスペンド判定処理は、上記したようにサスペンド判定部228がAPIフック部221からの要求を受けると実行される。APIフック部221は、監視対象アプリケーション11からのロック取得要求がフックされた場合にサスペンド判定部228に対して要求を出力する。このとき、サスペンド判定部228は、APIフック部221からロック取得要求に含まれるロックのアドレスを取得する。
The suspend determination process by the suspend
サスペンド判定部228は、デッドロック情報読込部227によって共有ディスク30からデッドロック状況情報が読み込まれている(読み込み済)か否かを判定する(ステップS111)。
The suspend
デッドロック状況情報が読み込まれていないと判定された場合(ステップS111のNO)、サスペンド判定部228は、デッドロック情報読込部227を実行する(ステップS112)。サスペンド判定部228は、デッドロック情報読込部227に対して、デッドロック状況情報の読み込みを要求する。デッドロック情報読込部227は、サスペンド判定部228からの要求に応じて共有ディスク30に格納されているデッドロック状況情報を読み込む。
When it is determined that the deadlock status information has not been read (NO in step S111), the suspend
サスペンド判定部228は、デッドロック情報読込部227によって読み込まれたデッドロック状況情報を取得する(ステップS113)。
The suspend
次に、サスペンド判定部228は、APIフック部221によってフックされたロック取得要求に応じたロック取得処理をサスペンドすべきか否かを判定する(ステップS114)。
Next, the suspend
サスペンド判定部228は、例えば予め定められた第1及び第2の条件を満たす場合に例えば今後デッドロックが発生する可能性があるとして、ロック取得処理をサスペンドすべきと判定する。このとき、サスペンド判定部228は、取得されたロックのアドレス、スレッドID及びデッドロック状況情報に基づいて判定処理を実行する。また、サスペンド判定部228は、スレッド対応テーブル223、ロック対応テーブル224及びロック状態テーブル133を参照して判定処理を実行する。なお、ここでは条件が2つ(第1及び第2の条件)であるものとして説明するが、当該条件は2つに限られない。つまり、条件は、2つ以上であっても構わない。以下、第1及び第2の条件の一例について説明する。
The suspend
なお、サスペンド判定部228による判定処理においては、取得されたスレッドIDによって識別されるスレッドがデッドロック状況情報に含まれるスレッドである、つまり、当該スレッドがデッドロック状況情報によって示されるデッドロック時に実行中であることを前提としている。また、APIフック部221によってフックされたロック取得要求に応じて取得されるロック(取得されたスレッドID及びロックのアドレスの組み合わせによるロックの取得状態)がデッドロック状況情報に含まれる他のスレッドを止めている(止めることになる)ロックであることを前提としている。
In the determination process by the suspend
上記した第1の条件は、取得されたデッドロック状況情報において、取得されたスレッドIDによって識別されるスレッドに対応付けられている「取得要求中のロック」を止めることになるロック(デッドロック状況情報に含まれる「他のスレッドを止めているロック」)が、当該ロックに対応付けられている「スレッド」によって取得されていることである。 The first condition described above is that the acquired deadlock status information is a lock (deadlock status) that stops the “lock during acquisition request” associated with the thread identified by the acquired thread ID. The “lock that stops other threads”) included in the information is acquired by the “thread” associated with the lock.
また、上記した第2の条件は、APIフック部221によってフックされたロック取得要求に応じて取得されるロックによって止められることになるデッドロック状況情報に含まれる「取得要求中のロック」に対応付けられているスレッドが、当該スレッドに対応付けて当該デッドロック状況情報に含まれる「他のスレッドを止めているロック」を取得していることである。
The second condition described above corresponds to “lock during acquisition request” included in the deadlock status information that is stopped by the lock acquired in response to the lock acquisition request hooked by the
サスペンド判定部228は、上記した第1及び第2の条件を満たす場合には、取得されたデッドロック状況情報によって示されるデッドロックと同じ状況に陥る可能性があると判定する。よって、この場合には、APIフック部221によってフックされたロック取得要求に応じたロック取得処理をサスペンドすべきであると判定される。
When the first and second conditions are satisfied, the suspend
ここで、図20を参照して、上記した図19に示すステップS114の処理について具体的に説明する。図20は、ロック状態テーブル133におけるAPIフック部221によってフックされたロック取得要求に応じて取得されるロック及び既に取得されているロックの関係の一例を表す図である。
Here, with reference to FIG. 20, the process of step S114 shown in FIG. 19 will be specifically described. FIG. 20 is a diagram illustrating an example of a relationship between a lock acquired in response to a lock acquisition request hooked by the
なお、サスペンド判定部228によって取得されたデッドロック状況情報は、前述した図6のデッドロックを示すものとして説明する。なお、図20及び前述した図6において、スレッドID「T1」〜「T4」及びロックのアドレス「L1」〜「L4」はそれぞれ対応しているものとして説明する。
The deadlock status information acquired by the suspend
また、APIフック部221によってフックされたロック取得要求に応じて取得されるロックのアドレス(サスペンド判定処理部228によって取得されたロックのアドレス)は「L3」であり、当該ロック取得要求の要求元であるスレッドを識別するためのスレッドID(サスペンド判定処理部228によって取得されたスレッドID)は「T2」であるものとする。つまり、図20における斜線部のロック取得状態が「ロック中」になる場合を想定している。以下、APIフック部221によってフックされたロック取得要求に応じて取得されるロック(図20における斜線部)を対象ロックと称する。
The address of the lock acquired in response to the lock acquisition request hooked by the API hook unit 221 (the address of the lock acquired by the suspend determination processing unit 228) is “L3”, and the request source of the lock acquisition request It is assumed that the thread ID (thread ID acquired by the suspend determination processing unit 228) for identifying the thread is “T2”. That is, it is assumed that the lock acquisition state in the shaded area in FIG. 20 is “locking”. Hereinafter, the lock (hatched portion in FIG. 20) acquired in response to the lock acquisition request hooked by the
まず、図20に示す例では、サスペンド判定部228によって取得されたスレッドID「T2」によって識別されるスレッド(以下、単に「T2」と表記)がデッドロック状況情報によって示されるデッドロック時(以下、単にデッドロック時と表記)において実行中である。また、対象ロックがデッドロック時に他のスレッド(ここでは、「T1」)を止めることになるロックである。したがって、対象ロックは、上記した前提を満たすものとする。 First, in the example illustrated in FIG. 20, the thread identified by the thread ID “T2” acquired by the suspend determination unit 228 (hereinafter simply referred to as “T2”) is indicated by deadlock status information (hereinafter referred to as “T2”). , Simply described as deadlock). In addition, the target lock is a lock that stops other threads (here, “T1”) when deadlock occurs. Therefore, the target lock satisfies the above-described assumption.
ここで、図20及び前述した図6に示すように、デッドロック時に「T2」で取得要求中になるロック(ここでは、ロックのアドレスが「L4」であるロック)を止めることになるロックが、「T4」によって取得されている。したがって、対象ロックは、上記した第1の条件を満たす。 Here, as shown in FIG. 20 and FIG. 6 described above, there is a lock that stops a lock that is being requested for acquisition at “T2” at the time of deadlock (here, a lock whose lock address is “L4”). , “T4”. Therefore, the target lock satisfies the first condition described above.
また、図20及び前述した図6に示すように、対象ロックによって止められることになるロック(ここでは、ロックのアドレスが「L3」であるロック)を取得要求中となるスレッド(ここでは、「T1」)が、デッドロック時に他のスレッド(ここでは、「T4」)を止めることになるロック(ここでは、ロックのアドレスが「L1」であるロック)を取得している。したがって、対象ロックは、上記した第2の条件を満たす。 Further, as shown in FIG. 20 and FIG. 6 described above, a thread (here, “a lock whose lock address is“ L3 ”) that is to be stopped by the target lock” (here “ T1 ") has acquired a lock (here, a lock whose lock address is" L1 ") that stops another thread (here," T4 ") at the time of deadlock. Therefore, the target lock satisfies the second condition described above.
よって、対象ロックが取得された場合において、「T1」がロックのアドレスが「L1」であるロック(以下、「L1」のロックと表記)を解放する前に「L3」のロックを、「T2」が「L3」のロックを解放する前に「L4」のロックを、「T4」が「L4」のロックを解放する前に「L1」のロックを取得しようとした(ロック取得要求を出力した)場合、前述した図6に示すデッドロックと同じ状況に陥る可能性があるため当該対象ロックのロック取得処理がサスペンドされる。 Therefore, when the target lock is acquired, the lock of “L3” is released before the lock whose lock address is “L1” (hereinafter referred to as “L1” lock) is “T2”. Tried to acquire the lock of “L4” before releasing the lock of “L3”, and acquired the lock of “L1” before releasing the lock of “L4” to “T4” (the lock acquisition request was output ), There is a possibility of falling into the same situation as the deadlock shown in FIG.
なお、上記した第1及び第2の条件は一例であるため、ロック取得処理をサスペンドするための条件として当該第1及び第2の条件以外の条件によってサスペンド判定処理が実行される構成であっても構わない。 Since the first and second conditions described above are examples, the suspend determination process is executed under conditions other than the first and second conditions as conditions for suspending the lock acquisition process. It doesn't matter.
再び図19に戻ると、サスペンドすべきであると判定された場合(ステップS114のYES)、APIフック部221によってフックされたロック取得要求に応じたロック取得処理は予め定められた時間(一定時間)サスペンドされる(ステップS115)。
Referring back to FIG. 19 again, if it is determined that the suspension should be suspended (YES in step S114), the lock acquisition process in response to the lock acquisition request hooked by the
次に、上記したステップS115において一定時間サスペンドされた後、当該ステップS115の処理がn回実行されたか否かが判定される(ステップS116)。このnは、予め定められた値である。 Next, after suspending for a predetermined time in step S115, it is determined whether or not the process of step S115 has been executed n times (step S116). This n is a predetermined value.
ステップS115の処理がn回実行されたと判定された場合(ステップS116のYES)、処理は終了される。つまり、APIフック部221によってフックされたロック取得要求に応じたロック取得処理が実行される。一方、ステップS115の処理がn回実行されていないと判定された場合(ステップS116のNO)、ステップS114に戻って処理が繰り返される。
If it is determined that the process of step S115 has been executed n times (YES in step S116), the process ends. That is, the lock acquisition process corresponding to the lock acquisition request hooked by the
ステップS111においてデッドロック状況情報が読み込まれていると判定された場合には、ステップS114の処理が実行される。 If it is determined in step S111 that deadlock status information has been read, the process of step S114 is executed.
ステップS114においてサスペンドすべきでないと判定された場合には、サスペンドされることなく処理が終了される。つまり、APIフック部221によってフックされたロック取得要求に応じたロック取得処理が実行される。
If it is determined in step S114 that it should not be suspended, the process ends without being suspended. That is, the lock acquisition process corresponding to the lock acquisition request hooked by the
ここでは、ステップS115の処理(サスペンド処理)がn回実行された場合に当該サスペンド処理が終了されるものとして説明したが、ステップS114においてサスペンドすべきでないと判定されるまでロック取得処理が実行されない、つまり、サスペンド処理が継続される構成であっても構わない。 Here, although it has been described that the suspend process is terminated when the process (suspend process) in step S115 is executed n times, the lock acquisition process is not executed until it is determined in step S114 that the suspend process should not be performed. In other words, the configuration may be such that the suspend process is continued.
なお、共有ディスク30に複数のデッドロック状況情報が格納されている場合には、当該複数のデッドロック状況情報の全てについて上記した図19に示す処理が実行される。
When a plurality of deadlock status information is stored in the shared
上記したように本実施形態においては、例えばノード200においてデッドロックの発生が検出された場合には、当該デッドロックを示すデッドロック状況情報が共有ディスク400に格納される。本実施形態においては、ノード200のAPIフック部221によってロック取得要求がフックされると、当該ロック取得要求に応じたロック取得処理が実行されるとデッドロックに陥る可能性があるか否かをデッドロック状況情報に基づいて判定することによって、当該ロック取得処理をサスペンドすることができる。これにより、本実施形態においては、複数のノード200のいずれかにおいて発生したデッドロックと同じ条件のデッドロックが発生する確率を低減することが可能となる。このように、本実施形態においては、アプリケーション障害が発生する確率を低減することでクラスタシステムの可用性を向上させることが可能となる。
As described above, in this embodiment, for example, when occurrence of a deadlock is detected in the
また、本実施形態においては、デッドロックが発生する可能性があると判定された場合に、一定時間のみロック取得処理をサスペンドすることで、監視対象アプリケーション11の動作に与える影響を最小限に抑えることが可能である。
In the present embodiment, when it is determined that there is a possibility of deadlock, the lock acquisition process is suspended only for a predetermined time, thereby minimizing the influence on the operation of the monitored
なお、本願発明は、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。 Note that the present invention is not limited to the above-described embodiments as they are, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. Further, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine the component covering different embodiment suitably.
10,100,200…ノード(計算機)、11…監視対象アプリケーション、12,210…OS、13,130a,130b,220…ジャケットライブラリ、14…HAクラスタデーモン(フェイルオーバ手段)、30…共有ディスク(格納手段)、121…ロック取得部、122…ロック解放部、131,221…APIフック部(取得手段)、132,136…ロック状態管理部(ロック管理手段)、123,133…ロック状態テーブル、134,137,225…デッドロック検出部、135…デッドロック通知部、211…スレッド作成部、212…ロック作成部、222…ロック/スレッド対応付け部、223…スレッド対応テーブル、224…ロック対応テーブル、226…デッドロック情報作成部、227…デッドロック情報読込部、228…サスペンド判定部。 DESCRIPTION OF SYMBOLS 10,100,200 ... Node (computer), 11 ... Monitored application, 12, 210 ... OS, 13, 130a, 130b, 220 ... Jacket library, 14 ... HA cluster daemon (failover means), 30 ... Shared disk (storage) Means), 121 ... Lock acquisition part, 122 ... Lock release part, 131, 221 ... API hook part (acquisition means), 132, 136 ... Lock state management part (lock management means), 123, 133 ... Lock state table, 134 , 137, 225 ... deadlock detection unit, 135 ... deadlock notification unit, 211 ... thread creation unit, 212 ... lock creation unit, 222 ... lock / thread association unit, 223 ... thread correspondence table, 224 ... lock correspondence table, 226 ... Deadlock information creation unit, 227 ... Deadlock Click information reading unit, 228 ... suspend determination unit.
Claims (7)
前記計算機は、
前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得する取得手段と、
前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態が登録されるロック状態テーブルと、
前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出する検出手段と
を含む
ことを特徴とする計算機システム。 A computer that executes a plurality of threads that share resources;
The calculator is
An acquisition means for acquiring a lock acquisition request for requesting acquisition of a lock for occupying the resource from each of the plurality of threads;
Based on the acquired lock acquisition request, a lock state table in which acquisition states of locks by the plurality of threads are registered;
A computer system comprising: a detecting unit that detects occurrence of a deadlock based on the acquired lock acquisition request and a lock acquisition state registered in the lock state table.
前記計算機は、
前記デッドロックの発生が検出された場合、前記ロック状態テーブルに登録されているロックの取得状態によって表される当該デッドロックを示すデッドロック状況情報を作成し、当該作成されたデッドロック状況情報を前記格納手段に格納する作成手段と、
前記取得手段によって前記複数のスレッドの各々からのロック取得要求が取得された場合に、前記格納手段に格納されているデッドロック状況情報を読み込む読み込み手段と、
前記取得されたロック取得要求に応じてロックが取得された場合に、前記読み込まれたデッドロック状況情報によって示されるデッドロックに陥る可能性があるかを、前記ロック状態テーブルに登録されているロックの取得状態に基づいて判定する判定手段と、
前記デッドロックに陥る可能性があると判定された場合、前記取得されたロック取得要求に応じたロック取得処理をサスペンドするサスペンド手段と
を含む
ことを特徴とする請求項2記載の計算機システム。 Further comprising storage means accessed by the computer;
The calculator is
When the occurrence of the deadlock is detected, the deadlock status information indicating the deadlock represented by the lock acquisition status registered in the lock status table is created, and the created deadlock status information is Creating means for storing in the storage means;
A read unit that reads deadlock status information stored in the storage unit when a lock acquisition request is acquired from each of the plurality of threads by the acquisition unit;
The lock registered in the lock state table indicates whether there is a possibility of falling into a deadlock indicated by the read deadlock status information when a lock is acquired in response to the acquired lock acquisition request. Determining means for determining based on the acquisition state of
The computer system according to claim 2, further comprising: a suspend unit that suspends lock acquisition processing according to the acquired lock acquisition request when it is determined that there is a possibility of falling into the deadlock.
前記検出手段は、前記ロック状態テーブルを参照して、前記複数のスレッド間において前記ロック状態テーブルに登録されているロック中及びロック要求中のループが発生する際に前記デッドロックの発生を検出する
ことを特徴とする請求項1記載の計算機システム。 When a lock is acquired in response to the acquired lock acquisition request, the lock acquisition state is registered in the lock state table as the acquisition state of the lock, and a lock acquired in response to the lock acquisition request is registered. Lock management means for registering in the lock state table that the lock is being acquired as the lock acquisition state when acquired by a thread other than the thread that is the request source of the lock acquisition request;
The detecting means refers to the lock state table to detect the occurrence of the deadlock when a loop that is registered in the lock state table and a lock request is generated between the plurality of threads. The computer system according to claim 1.
前記計算機に、
前記複数のスレッドの各々からの、前記資源を占有するためのロックの取得を要求するロック取得要求を取得するステップと、
前記取得されたロック取得要求に基づいて、前記複数のスレッドによるロックの取得状態を前記ロック状態テーブルに登録するステップと、
前記取得されたロック取得要求及び前記ロック状態テーブルに登録されているロックの取得状態に基づいて、デッドロックの発生を検出するステップと
を実行させるためのプログラム。 A program that executes a plurality of threads that share resources and is executed by a computer having a lock state table,
In the calculator,
Obtaining a lock acquisition request for requesting acquisition of a lock for occupying the resource from each of the plurality of threads;
Registering the lock acquisition state by the plurality of threads in the lock state table based on the acquired lock acquisition request;
Detecting the occurrence of a deadlock based on the acquired lock acquisition request and the lock acquisition status registered in the lock status table.
前記デッドロックの発生が検出された場合に当該計算機の処理を当該系計算機とは別の計算機に引き継ぐステップと、
前記デッドロックの発生が検出された場合、前記ロック状態テーブルに登録されているロックの取得状態によって表される当該デッドロックを示すデッドロック状況情報を作成し、当該作成されたデッドロック状況情報を、前記計算機によってアクセスされる格納手段に格納するステップと、
前記複数のスレッドの各々からのロック取得要求が取得された場合に、前記格納手段に格納されているデッドロック状況情報を読み込むステップと、
前記取得されたロック取得要求に応じてロックが取得された場合に、前記読み込まれたデッドロック状況情報によって示されるデッドロックに陥る可能性があるかを、前記ロック状態テーブルに登録されているロックの取得状態に基づいて判定するステップと、
前記デッドロックに陥る可能性があると判定された場合、前記取得されたロック取得要求に応じたロック取得処理をサスペンドするステップと
を更に実行させるための請求項6記載のプログラム。 In the calculator,
When the occurrence of the deadlock is detected, taking over the processing of the computer to a computer different from the system computer;
When the occurrence of the deadlock is detected, the deadlock status information indicating the deadlock represented by the lock acquisition status registered in the lock status table is created, and the created deadlock status information is Storing in storage means accessed by the computer;
When a lock acquisition request from each of the plurality of threads is acquired, reading deadlock status information stored in the storage unit;
The lock registered in the lock state table indicates whether there is a possibility of falling into a deadlock indicated by the read deadlock status information when a lock is acquired in response to the acquired lock acquisition request. Determining based on the acquisition state of
The program according to claim 6, further executing a step of suspending lock acquisition processing according to the acquired lock acquisition request when it is determined that there is a possibility of falling into the deadlock.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008123877A JP2009271858A (en) | 2008-05-09 | 2008-05-09 | Computing system and program |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008123877A JP2009271858A (en) | 2008-05-09 | 2008-05-09 | Computing system and program |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009271858A true JP2009271858A (en) | 2009-11-19 |
Family
ID=41438324
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008123877A Pending JP2009271858A (en) | 2008-05-09 | 2008-05-09 | Computing system and program |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2009271858A (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012153722A1 (en) * | 2011-05-12 | 2012-11-15 | 日本電気株式会社 | Deadlock prevention system, deadlock prevention method, and programs |
JP2013114359A (en) * | 2011-11-25 | 2013-06-10 | Hitachi Ltd | Computer system and monitoring method |
JP2014119964A (en) * | 2012-12-17 | 2014-06-30 | Hitachi Ltd | Computer system and program |
CN111159051A (en) * | 2019-12-31 | 2020-05-15 | 北京天融信网络安全技术有限公司 | Deadlock detection method and device, electronic equipment and readable storage medium |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06337798A (en) * | 1993-03-30 | 1994-12-06 | Fujitsu Ltd | Deadlock detecting device |
JPH0736721A (en) * | 1993-07-16 | 1995-02-07 | Pfu Ltd | Control system for multiplex computer system |
JP2004341878A (en) * | 2003-05-16 | 2004-12-02 | Toshiba Corp | Real-time os and method for detecting deadlock |
JP2007048247A (en) * | 2005-08-09 | 2007-02-22 | Movell Software:Kk | System freeze diagnostics and restoration technique applied to wireless device |
-
2008
- 2008-05-09 JP JP2008123877A patent/JP2009271858A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06337798A (en) * | 1993-03-30 | 1994-12-06 | Fujitsu Ltd | Deadlock detecting device |
JPH0736721A (en) * | 1993-07-16 | 1995-02-07 | Pfu Ltd | Control system for multiplex computer system |
JP2004341878A (en) * | 2003-05-16 | 2004-12-02 | Toshiba Corp | Real-time os and method for detecting deadlock |
JP2007048247A (en) * | 2005-08-09 | 2007-02-22 | Movell Software:Kk | System freeze diagnostics and restoration technique applied to wireless device |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012153722A1 (en) * | 2011-05-12 | 2012-11-15 | 日本電気株式会社 | Deadlock prevention system, deadlock prevention method, and programs |
US9323585B2 (en) | 2011-05-12 | 2016-04-26 | Nec Corporation | Deadlock preventing apparatus, deadlock preventing method, and program |
JP5950124B2 (en) * | 2011-05-12 | 2016-07-13 | 日本電気株式会社 | Deadlock prevention device, deadlock prevention method, and program |
JP2013114359A (en) * | 2011-11-25 | 2013-06-10 | Hitachi Ltd | Computer system and monitoring method |
JP2014119964A (en) * | 2012-12-17 | 2014-06-30 | Hitachi Ltd | Computer system and program |
CN111159051A (en) * | 2019-12-31 | 2020-05-15 | 北京天融信网络安全技术有限公司 | Deadlock detection method and device, electronic equipment and readable storage medium |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200177451A1 (en) | Distributed lifecycle management for cloud platforms | |
CN106790694B (en) | Distributed system and scheduling method of target object in distributed system | |
RU2751551C1 (en) | Method and apparatus for restoring disrupted operating ability of a unit, electronic apparatus and data storage medium | |
JP4726416B2 (en) | Method for operating a computer cluster | |
CN107590072B (en) | Application development and test method and device | |
WO2017140131A1 (en) | Data writing and reading method and apparatus, and cloud storage system | |
WO2017071460A1 (en) | Container monitoring method and apparatus | |
US20080263390A1 (en) | Cluster system and failover method for cluster system | |
JP5543333B2 (en) | Dynamic CLI mapping for clustered software entities | |
CN109614167B (en) | Method and system for managing plug-ins | |
CN111143044B (en) | Task scheduling management system, method, device and storage medium thereof | |
CN105357042B (en) | A kind of highly available cluster system and its host node and from node | |
CN112199240B (en) | Method for switching nodes during node failure and related equipment | |
CN114064414A (en) | High-availability cluster state monitoring method and system | |
CN113382077B (en) | Micro-service scheduling method, micro-service scheduling device, computer equipment and storage medium | |
US20220138036A1 (en) | Safely recovering workloads within a finite timeframe from unhealthy cluster nodes | |
JP2009271858A (en) | Computing system and program | |
US8065569B2 (en) | Information processing apparatus, information processing apparatus control method and control program | |
US20070058525A1 (en) | Monitoring a problem condition in a communications system | |
CN109032674B (en) | Multi-process management method, system and network equipment | |
US8595349B1 (en) | Method and apparatus for passive process monitoring | |
CN115309421A (en) | Static variable synchronization method, device, equipment and storage medium of single-point system | |
CN111208949B (en) | Method for determining data rollback time period in distributed storage system | |
CN109032774B (en) | Application program recovery method and device | |
JPH09319720A (en) | Distributed process managing system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100426 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100511 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20100928 |