JP2009265689A - クラスタシステム及び引き継ぎ先ノード決定方法 - Google Patents

Abstract

【課題】稼動系ノードでの障害時に最適な引き継ぎ先ノードを決定できるようにする。
【解決手段】クラスタシステムを構成する各ノード１０-iのＡＰＩフック部１３４は、ノード１０-iが稼動系ノードとして動作している場合、アプリケーション１２-iが使用するＡＰＩをフックして、そのフックされたＡＰＩの実行結果を含むＡＰＩ情報をＡＰＩ情報記憶部１４-iに格納する。評価部１３５は、ノード１０-iが待機系ノードとして動作している状態で稼動系ノードで障害が発生した場合、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報で示されるＡＰＩを実行し、その実行結果が正しいかを当該ＡＰＩ情報に含まれている実行結果に基づいて判定することにより、アプリケーション１２-iを稼動することが可能であるかを評価する。評価部１３５は、この評価結果に基づいてノード１０-iが引き継ぎノードとして最適であるかを決定する。
【選択図】 図２

Description

本発明は、複数のサーバ計算機（ノード）から構成されるクラスタシステムに係り、特に、稼動系（稼動系ノード）として動作しているサーバ計算機で異常が発生した場合に、当該稼動系ノードでの処理を引き継ぐノード（引き継ぎ先ノード）を決定するのに好適なクラスタシステム及び引き継ぎ先ノード決定方法に関する。

従来から、複数台のサーバ計算機（ノード）が互いに通信して連携を取ることにより、クライアントに対して１台のマシンであるかのように振る舞う、いわゆるクラスタシステムが知られている。このようなクラスタシステムによれば、処理の分散や可用性の向上が実現される。

処理分散を特徴とするクラスタシステムでは、システム内でクライアントに対して処理（サービスの提供）を行っているサーバ計算機（稼動系ノード）の負荷が増大した場合、他のサーバ計算機（待機系ノード）に当該処理を行わせる（または分担させる）ことによって、システム全体の処理能力を下げることなく稼動系ノードの負荷を減少させることができる。

また高可用性を特徴とするクラスタシステムでは、システム内の稼動系ノードに障害が発生した場合、当該処理が待機系ノードによって引き継がれる。このように、稼動系ノードに障害が発生しても、待機系ノードによって処理が引き継がれることにより、システム全体で可用性を保つことができる。ここで、障害が発生したノードはシステムから切り離される。このためクラスタシステムでは、システムを停止させることなく障害が発生したノードの交換や修理を行うことが可能となる。

クラスタシステムの稼動系ノードでは、当該システムにおけるクラスタ構成を管理するためのクラスタ管理部が、当該稼動系ノードの状態及び当該稼動系ノードで動作するアプリケーション（クライアントにサービスを提供するためのアプリケーション）の状態を監視する。稼動系ノードのクラスタ管理部は、この監視によって、稼動系ノードの負荷の増大や当該稼動系ノードの障害を検知する。

稼動系ノードのクラスタ管理部は、稼動系ノードの負荷の増大や当該稼動系ノードの障害（例えば稼動系ノードで動作しているアプリケーションの異常）を検知すると、クラスタシステム内の他のノード（待機系ノード）のクラスタ管理部と連携して、当該他のノードへの処理の引き継ぎを行う。稼動系ノードから処理を引き継ぐ待機系ノード、つまり引き継ぎ先ノードは、クライアントへのサービスの提供のために用いられていた、アプリケーションの情報やＩＰアドレス、共有ディスク領域などを引き継ぐことにより、稼動系ノードで行われていた処理（サービス）を開始する。このため、クライアントは、このような引き継ぎを意識することなく、同じＩＰアドレスで引き継ぎ先ノードと接続することが可能である。

システムの実行能力や稼働率をできるだけ下げないためには、異常検知の仕組みと待機系ノードへの早急の引き継ぎの他、引き継ぎ先ノードで確実にサービスが動作することが重要であり、更にシステムが快適に稼動することが求められる。

そこで従来の技術では、以下のようにして引き継ぎ先ノードが決定される。

（１）待機系ノードが１台の場合はこれに引き継ぐ
（２）待機系ノードが複数台の場合、次の要素を検討して決定する
２ａ）予め設定されたノード優先度
２ｂ）アプリケーション（サービス）の依存関係
アプリケーションの依存関係とは、例えば特許文献１に記載されているように、同一ノード内で複数のアプリケーションが並行して実行される場合に、それらのアプリケーションが作用し合うかを示す関係をいう。引き継ぐべきアプリケーションが、待機系ノードで実行されている他のアプリケーションと作用し合う場合、当該待機系ノードは引き継ぎ先として決定されない。
特開２００４−１３３７６４号公報

上述のように従来の技術では、引き継ぎ先ノードの決定に、予め設定されたノード優先度や、アプリケーションの依存関係のように、各ノード（サーバ計算機）に関する予め設定される静的な条件のみが用いられる。またアプリケーションに関する条件は依存関係のみである。

ところが、このような条件に基づいて決定されるノードが、引き継ぎ先ノードとして必ずしも最適であるとは限らない。即ち、引き継ぎ先ノードとして決定されたノードであっても、例えば、引き継いだアプリケーションの実行によって大量のリソースを消費するような場合には、一時的なリソース不足が起こって実行能力が低くなったり、正常に動作しなかったりすることもあり得る。このようなリソースの消費状況は、引き継がれるべきアプリケーションが引き継ぎ先ノードで実際に起動されて初めて把握される。

本発明は上記事情を考慮してなされたものでその目的は、稼動系ノードで障害が発生した場合に、稼動系ノードでの処理が引き継ぎ先ノードに実際に引き継がれる前に、その引き継ぎ先ノードの候補となる待機系ノードでアプリケーションが稼動可能であるかを評価することによって最適な引き継ぎ先ノードを決定することができるクラスタシステム及び引き継ぎ先ノード決定方法を提供することにある。

本発明の１つの観点によれば、稼動系ノードとして動作する場合に所定のアプリケーションを稼動させることによりクライアントに対してサービスを提供する、通信路によって相互接続された複数のサーバ計算機と、前記複数のサーバ計算機によって共有される記憶手段とを備えたクラスタシステムが提供される。このクラスタシステムにおいて、前記複数のサーバ計算機はそれぞれ、前記通信路を介して連携することにより当該複数のサーバ計算機のクラスタ構成を管理するクラスタ管理手段を有している。また、前記クラスタ管理手段は、前記アプリケーションとオペレーティングシステムとの間に位置するフック手段であって、当該クラスタ管理手段を有するサーバ計算機が稼動系ノードとして動作している場合、当該稼動系ノードで稼動している前記アプリケーションが使用するアプリケーションプログラムインタフェースをフックして、そのフックされたアプリケーションプログラムインタフェースの実行結果を含む当該アプリケーションプログラムインタフェースに関するアプリケーションプログラムインタフェース情報を前記記憶手段に格納するフック手段と、当該クラスタ管理手段を有するサーバ計算機が待機系ノードとして動作している状態で前記稼動系ノードで障害が発生した場合、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースを実行し、その実行結果が正しいかを、当該アプリケーションプログラムインタフェース情報に含まれている実行結果に基づいて判定することにより、当該クラスタ管理手段を有するサーバ計算機で前記アプリケーションを稼動することが可能であるかを評価して、その評価結果に基づき、当該クラスタ管理手段を有するサーバ計算機が前記障害を発生した稼動系ノードの引き継ぎノードとして最適であるかを決定する評価手段とを含む。

本発明によれば、アプリケーションが稼動している稼動系ノードに異常が発生した場合に、稼動系ノードでの処理が引き継ぎ先ノードに実際に引き継がれる前に、その引き継ぎ先ノードの候補となる待機系ノードでアプリケーションが稼動可能であるかが評価され、稼動可能と評価された待機系ノードが引き継ぎ先ノードとして決定される。このため、本発明によれば、アプリケーションの実行失敗による障害発生を減少させることができる。

以下、本発明の実施の形態につき図面を参照して説明する。
［第１の実施形態］
図１は本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図である。

図１に示すクラスタシステムは、３台以上のサーバ計算機、例えば３台のサーバ計算機（以下、ノードと称する）１０-1，１０-2及び１０-3から構成される。図１の例では、ノード１０-1は稼動系ノードとして動作し、ノード１０-2及び１０-3は待機系ノードとして動作しているものとする。ノード１０-1〜１０-3は、ネットワークのような通信路２０によって相互接続されている。

ノード１０-1〜１０-3では、それぞれオペレーティングシステム（ＯＳ）１１-1〜１１-3が動作する。ノード１０-1〜１０-3ではまた、当該ノード１０-1〜１０-3が稼動系ノードである場合に、アプリケーション（アプリケーションプログラム）１２-1〜１２-3が動作する。アプリケーション１２-1〜１２-3は、ノード１０-1〜１０-3がクライアントに対して特定のサービスを提供するために、当該ノード１０-1〜１０-3において実行される。このため図１の例では、ノード１０-1〜１０-3上のアプリケーション１２-1〜１２-3のうち、稼動系ノード１０-1上のアプリケーション１２-1のみが動作しており、待機系ノード１０-2及び１０-3上のアプリケーション１２-2及び１２-3は停止している。アプリケーション１２-1〜１２-3が実行されることによって提供されるサービス（サービスの種類）は同一である。

ノード１０-1〜１０-3は、それぞれ、クラスタ管理部１３-1〜１３-3及びアプリケーションプログラムインタフェース情報記憶部（以下、ＡＰＩ情報記憶部と称する）１４-1〜１４-3を有する。第１の実施形態においクラスタ管理部１３-1〜１３-3は、通信路２０を介して連携することにより、ノード１０-1〜１０-3のクラスタ構成を管理する。ノード１０-i（ｉ＝１，２，３）のクラスタ管理部１３-iは、ノード１０-i内の図示せぬＣＰＵが、ディスクのような記憶媒体に格納されているクラスタソフトウェアと呼ばれるソフトウェアプログラムを例えば当該ノード１０-i内の主メモリに読み込んで実行することにより実現されるものとする。

図２は、ノード１０-i（ｉ＝１，２，３）の構成（特にノード１０-i内のクラスタ管理部１３-iの構成）を示すブロック図である。クラスタ管理部１３-iは、クラスタ制御部１３１、アプリケーション制御部（以下、アプリ制御部と称する）１３２、監視部１３３、アプリケーションプログラムインタフェースフック部（以下、ＡＰＩフック部と称する）１３４及び評価部１３５を含む。

クラスタ制御部１３１は、アプリ制御部１３２、監視部１３３、ＡＰＩフック部１３４及び評価部１３５を制御することによって、クラスタシステム内のノード１０-1〜１０-3のクラスタ構成を制御する。クラスタ制御部１３１は、他のノードのクラスタ制御部１３１と通信路２０を介して相互に通信を行うことで、他のノードの障害を検知する。このクラスタ制御部１３１相互間のノード障害検知のための通信はハートビート通信と呼ばれる。

アプリ制御部１３２は、クラスタ管理部１３-1の制御の下でアプリケーション１２-iの起動／停止を制御する。
監視部１３３は、アプリケーション１２-iの状態を監視することによって当該アプリケーション１２-iの異常を検知する。監視部１３３をクラスタ制御部１３１に含めることも可能である。

ＡＰＩフック部１３４は、例えば論理的に、アプリケーション１２-iとＯＳ１１-iとの間に位置する。ＡＰＩフック部１３４は、ノード１０-iが稼動系ノードの場合、アプリケーション１２-iが使用するＡＰＩをフックするように構成されている。第１の実施形態においてＡＰＩは関数（システム関数）であり、予めＯＳ１１-iに用意されている。ＡＰＩフック部１３４は、自身がフックしたＡＰＩに関する情報（以下、ＡＰＩ情報と称する）をＡＰＩ情報記憶部１４-1に時系列順に格納する。ＡＰＩ情報は、ＡＰＩフック部１３４によってフックされた関数（ＡＰＩ）の関数名と、当該関数に渡されるべき（つまり当該関数の実行に用いられるべき）入力値である引数（ＯＳ１１-iに渡される引数）と、当該関数の実行の結果としての出力値（ＯＳ１１-iからの出力値）である返り値とを含む。

ＡＰＩ情報記憶部１４-iに格納されたＡＰＩ情報、つまりノード１０-iが稼動系ノードである場合に、当該ノード１０-i内のＡＰＩフック部１３４によって取得されたＡＰＩ情報（アプリケーション１２-iが使用した関数の関数名を含むＡＰＩ情報）は、ノード１０-i内のクラスタ制御部１３１によって、クラスタシステムを構成する他の全てのノード（つまり待機系ノード）のクラスタ制御部に転送される。転送されたＡＰＩ情報は、上記待機系ノードのＡＰＩ情報記憶部に格納される。

ノード１０-i内の評価部１３５は、稼動系ノードの異常が検知され、且つ当該ノード１０-iが待機系ノードの場合に、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報の示す関数（ＡＰＩ）を実行することによって、当該ノード１０-iが引き継ぎ先ノードとなり得るかを評価するように構成されている。第１の実施形態において、引き継ぎ先ノードとなり得るノードとは、アプリケーションを稼動することが可能がノードをいう。

評価部１３５による上述の評価の仕組みは次の通りである。評価部１３５は、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報の示す関数（つまり稼動系ノードのＡＰＩフック部１３４によってフックされた関数）をＯＳ１１-iを介して実行する。第１の実施形態において評価部１３５によって実行される関数は、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報の示す全ての関数ではなく、例えば、使用頻度の高い関数、或いはリソースを大量に消費する関数のような、アプリケーション１２-iの動作に大きな影響のある関数（ＡＰＩ）に限られるものとする。したがってＡＰＩフック部１３４が、このような関数だけを選択的にフックする構成とすることもできる。リソースを大量に消費する関数として、メモリ確保関数（例えばｍａｌｌｏｃ関数、ｒｅａｌｌｏｃ関数）や、スレッド作成関数（ＣｒｅａｔｅＴｈｒｅａｄ関数）が挙げられる。

評価部１３５は、関数の実行によってＯＳ１１-iから返される値（返り値）が正しいかによって、ノード１０-iでアプリケーション１２-iを稼動することが可能かを評価する。評価部１３５の評価結果は、クラスタ制御部１３１に通知される。待機系ノードのクラスタ制御部１３１は、相互に評価部１３５の判定結果を通知する。これにより各待機系ノード内の評価部１３５は、当該各待機系ノード内の評価部１３５の評価結果に基づいて、いずれの待機系ノードが引き継ぎ先ノードとして最適かを決定する。なお、第１の実施形態と異なって待機系ノードが１台の場合には、その唯一の待機系ノードでアプリケーションが稼動可能であれば、当該ノードが引き継ぎ先ノードとして決定される。

次に、第１の実施形態の動作について、図１の例のように、ノード１０-1が稼動系ノードとして動作し、ノード１０-2及び１０-3が待機系ノードとして動作している場合を例に説明する。

＜稼動系ノード内のＡＰＩフック部の動作＞
まず、稼動系ノード１０-1内のＡＰＩフック部１３４の動作について、図３のフローチャートを参照して説明する。

稼動系ノード１０-1内のＡＰＩフック部１３４は、当該ノード１０-1で動作するアプリケーション１２-1によって呼び出される（コールされる）ＡＰＩ（ここではＡＰＩフック部１３４によって管理されているＡＰＩ）をフックする（つかまえる）（ステップＳ１，Ｓ２）。これによりアプリケーション１２-1からのＡＰＩの呼び出しが直接アプリケーション１２-1に伝えられるのが抑止される。ＡＰＩフック部１３４は、フックしたＡＰＩ（関数）に関する情報として、当該関数の関数名と、引数と、返り値（つまりＡＰＩ）情報を含むＡＰＩ情報を取得する（ステップＳ３）。

ＡＰＩフック部１３４は取得されたＡＰＩ情報を、ＡＰＩ情報記憶部１４-1に格納する（ステップＳ４）。またＡＰＩフック部１３４は、取得されたＡＰＩ情報を、稼動系ノード１０-1内のクラスタ制御部１３１によって待機系ノード１０-2及び１０-3に転送させる（ステップＳ５）。

稼動系ノード１０-1内のクラスタ制御部１３１によって待機系ノード１０-2及び１０-3に転送されたＡＰＩ情報は、当該待機系ノード１０-2及び１０-3内のクラスタ制御部１３１によって、それぞれＡＰＩ情報記憶部１４-2及び１４-3に格納される。これにより、稼動系ノード１０-1内のＡＰＩフック部１３４によって取得されたＡＰＩ情報は、当該稼動系ノード１０-1及び待機系ノード１０-2及び１０-3によって共有される。つまり、ＡＰＩ情報記憶部１４-1乃至１４-3は、論理的に共有ＡＰＩ情報記憶部を構成する。

第１の実施形態では、作図の都合で、ノード１０-1〜１０-3が、それぞれＡＰＩ情報記憶部１４-1〜１４-3を有している。しかし、ノード１０-1〜１０-3が、それぞれＡＰＩ情報記憶部１４-1〜１４-3を持つ代わりに、当該ノード１０-1〜１０-3によって共有される共有ストレージ装置（の記憶領域）内に、ＡＰＩ情報記憶部（つまり共有ＡＰＩ情報記憶部）が確保される構成としてもよい。この場合、ノード１０-1（稼動系ノード１０-1）のＡＰＩフック部１３４がＡＰＩ情報を共有ストレージ装置のＡＰＩ情報記憶部に格納するだけで、ノード１０-1〜１０-3は当該ＡＰＩ情報を共有することができる。

稼動系ノード１０-1内のＡＰＩフック部１３４の詳細について、図４の動作説明図を参照して説明する。
アプリケーション１２-iは自身が呼び出すべき関数（ＡＰＩ）の関数名のリストである関数テーブル１２０を含んでいる。この関数テーブル１２０は、アプリケーション１２-iが本来呼び出すべき第１の関数（第１のＡＰＩ）の関数名、及び当該第１の関数に予め対応付けられた第２の関数（第２のＡＰＩ）の関数名の対のリストを保持する。

図４の例では、関数テーブル１２０に保持されるリストは、第１の関数ｆｕｎ１（）の関数名及び第２の関数ｆｕｎ１′（）の関数名の対と、第１の関数ｆｕｎ２（）の関数名及び第２の関数ｆｕｎ２′（）の関数名の対とを含む。ＯＳ１１-1には、このリストで示される関数ｆｕｎ１（）及びｆｕｎ２（）を含む第１の関数の集合（第１の集合）が予めＡＰＩの集合として用意されている。一方、ＡＰＩフック部１３４には、関数ｆｕｎ１′（）及びｆｕｎ２′（）を含む第２の関数の集合が予めＡＰＩの集合として用意されている。ＡＰＩフック部１３４において、関数ｆｕｎ１′（）及びｆｕｎ２′（）の関数名は関数ｆｕｎ１（）及びｆｕｎ２（）の関数名と対応付けて管理されている。

今、アプリケーション１２-1が第１の関数ｆｕｎ１（）を呼び出したいものとする。第１の実施形態において、アプリケーション１２-1が呼び出そうとする第１の関数（の関数名）に第２の関数（の関数名）が関数テーブル１２０によって対応付けられている場合、当該アプリケーション１２-iは第２の関数を呼び出す。これにより、例えば関数ｆｕｎ１（）の呼び出しが必要な場合であれば、関数ｆｕｎ１′（）の呼び出しが行われる。関数ｆｕｎ１（）の呼び出しに用いられる引数は、そのまま関数ｆｕｎ１′（）の呼び出しに用いられる（継承される）。この引数は、例えば整数（Ｉｎｔｅｇｅｒ）型（ＩＮＴ型）のＸＸであるものとする。

上記したように、関数ｆｕｎ１′（）はＡＰＩフック部１３４に予め用意されている。そこでＡＰＩフック部１３４は、関数ｆｕｎ１（）に対応付けられた関数ｆｕｎ１′（）の呼び出しがアプリケーション１２-1によって行われると、図４において矢印４１で示されるように、当該ｆｕｎ１′（）の呼び出しをフックする。これによりＡＰＩフック部１３４では、関数ｆｕｎ１′（）が呼び出されて実行される。

ＡＰＩフック部１３４は、関数ｆｕｎ１′（）の実行により、当該関数ｆｕｎ１′（）に対応付けられた関数ｆｕｎ１（）の関数名と、当該関数ｆｕｎ１′（）に継承された引数（つまり関数ｆｕｎ１（）を呼び出すために用いられる入力値である引数（ＸＸ））とを取得する。そしてＡＰＩフック部１３４は、関数ｆｕｎ１′（）に対応付けられた関数ｆｕｎ１（）の呼び出し、つまりアプリケーション１２-1が本来行うべき関数ｆｕｎ１（）の呼び出しを、図４において矢印４２で示すように、当該アプリケーション１２-1に代わって行う。この呼び出しにより、ＯＳ１１-1に用意されている関数ｆｕｎ１（）が呼び出され、当該関数ｆｕｎ１（）に上記取得された引数（ＸＸ）が渡される。

するとＯＳ１１-1では、呼び出された関数ｆｕｎ１（）（つまり、ＡＰＩフック部１３４からの呼び出しに応じて呼び出された関数ｆｕｎ１（））が、ＡＰＩフック部１３４を介して渡されたアプリケーション１２-1からの引数（ＸＸ）に基づいて実行される。ＯＳ１１-1による関数ｆｕｎ１（）の実行結果を示す、当該ＯＳ１１-1（関数ｆｕｎ１（））からの出力値（つまり返り値）は、図４において矢印４３で示すように、当該関数ｆｕｎ１（）の直接の呼び出し元であるＡＰＩフック部１３４に返される。この返り値は、例えば整数型（ＩＮＴ型）のＹＹであるものとする。

ＡＰＩフック部１３４は、ＯＳ１１-1から返される、当該ＯＳ１１-1による関数ｆｕｎ１（）の実行結果である返り値（ＹＹ）を取得する。ＡＰＩフック部１３４は、取得された返り値（ＹＹ）を、図４において矢印４４で示されるように、アプリケーション１２-1に返す。

以上の動作は、アプリケーション１２-1にとっては、図４において矢印４５で示されるように、アプリケーション１２-1からＯＳ１１-1に対して関数ｆｕｎ１（）の呼び出しを行い、図４において矢印４６で示されるように、関数ｆｕｎ１（）の実行結果である返り値（ＹＹ）をアプリケーション１２-1がＯＳ１１-1（関数ｆｕｎ１（））から受け取ったことと等価である。

さてＡＰＩフック部１３４は、アプリケーション１２-1からの関数ｆｕｎ１′（）の呼び出しをフックした際に取得された、当該ｆｕｎ１′（）が対応付けられた関数ｆｕｎ１（）の関数名及び当該関数ｆｕｎ１（）に渡されるべき引数（ＸＸ）と、当該関数ｆｕｎ１（）をＯＳ１１-1から呼び出すことによって当該ＯＳ１１-1から取得された返り値（ＹＹ）とを含むＡＰＩ情報を、図４において矢印４７で示されるように、ＡＰＩ情報記憶部１４-1に格納する。

ＡＰＩフック部１３４が関数ｆｕｎ１（）の関数名、引数（ＸＸ）及び返り値（ＹＹ）を取得する動作は、当該ＡＰＩフック部１３４がアプリケーション１２-1の使用する関数ｆｕｎ１（）をフックして、当該関数ｆｕｎ１（）の関数名及び当該関数ｆｕｎ１（）の引数（関数ｆｕｎ１（）の実行に関する入力値）と、当該関数ｆｕｎ１（）の実行結果である返り値（ＹＹ）とを取得することと等価である。

以上に述べた稼動系ノード１０-1内のＡＰＩフック部１３４の動作は、アプリケーション１２-1から第１の関数に対応付けられた第２の関数の呼び出しが行われる都度実行される。これにより、ノード１０-1〜１０-3内のそれぞれＡＰＩ情報記憶部１４-1〜１４-3には、アプリケーション１２-1が使用する第１の関数の各々について、関数名と入出力値である引数及び返り値とを含むＡＰＩ情報が蓄積される。

このような状態で、稼動系ノード１０-1に障害が発生したものとする。ここでは稼動系ノード１０-1の障害として、ノード１０-1内のアプリケーション１２-1に異常が発生した場合を想定している。稼動系ノード１０-1内の監視部１３３は、アプリケーション１２-1の異常を検知すると、その旨を当該ノード１０-1内のクラスタ制御部１３１に通知する。

稼動系ノード１０-1内のクラスタ制御部１３１は、監視部１３３からアプリケーション１２-1の異常が通知されると、待機系ノード１０-2及び１０-3内のクラスタ制御部１３１に、その旨を通知する。この通知に応じて待機系ノード１０-2及び１０-3内のクラスタ制御部１３１は、当該ノード１０-2及び１０-3内の評価部１３５に、それぞれ当該ノード１０-2及び１０-3が引き継ぎ先ノードとなり得るか、つまりアプリケーション１２-2及び１２-3を稼動することが可能かを評価するように要求する。

なお、稼動系ノード１０-1においてアプリケーション１２-1の異常以外の障害が発生した場合、例えば稼動系ノード１０-1のハードウェア障害が発生した場合には、稼動系ノード１０-1のクラスタ制御部１３１は、待機系ノード１０-2及び１０-3内のクラスタ制御部１３１との間でハートビート通信を行うことができなくなる。そこで、待機系ノード１０-2及び１０-3内のクラスタ制御部１３１は、稼動系ノード１０-1内のクラスタ制御部１３１との間のハートビート通信が途絶えたことをもって、当該稼動系ノード１０-1の障害を検知することができる。

＜待機系ノード内の評価部の動作＞
待機系ノード１０-2及び１０-3内の評価部１３５は、待機系ノード１０-2及び１０-3内のクラスタ制御部１３１から評価要求を受け取ると、それぞれＡＰＩ情報記憶部１４-2及び１４-3（つまり論理的な共有ＡＰＩ情報記憶部）に格納されているＡＰＩ情報（つまり、稼動系ノード１０-1内のＡＰＩフック部１３４によって取得されたＡＰＩ情報）に基づき、当該ＡＰＩ情報の示す関数（ＡＰＩ）を実行することによって、当該ノード１０-2及び１０-3自身についての要求された評価を行う。

第１の実施形態において評価部１３５によって実行される関数は、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報の示す全ての関数ではなく、例えば、リソースを大量に消費する関数のような、アプリケーション１２-iの動作に大きな影響のある関数（ＡＰＩ）に限られる。したがってＡＰＩフック部１３４が、このような関数だけを選択的にフックする構成とすることもできる。リソースを大量に消費する関数としては、前述したように、メモリ確保関数やスレッド作成関数などが知られている。

以下、評価部１３５による評価処理の手順について、待機系ノード１０-2内の評価部１３５の動作を例に、図５のフローチャートを参照して説明する。
まず評価部１３５は、ＡＰＩ情報記憶部１４-2から、実行されるべきＡＰＩ情報（詳細には、実行されるべき関数の関数名及び引数を含むＡＰＩ情報）を選択する（ステップＳ１１）。評価部１３５は、選択されたＡＰＩ情報中の関数名と引数とを用いて、当該関数名で示される関数（ＡＰＩ）の呼び出しを行う（ステップＳ１２）。

ＯＳ１１-2は、評価部１３５による呼び出しに応じ、呼び出された関数に、当該関数の呼び出しに用いられた引数を適用することで、当該関数を実行する。そしてＯＳ１１-2（呼び出された関数）は、呼び出された関数の実行の結果である返り値を評価部１３５に返す。これにより評価部１３５は、自身が呼び出した関数の実行の結果である返り値を取得する（ステップＳ１３）。つまり評価部１３５は、選択されたＡＰＩ情報中の関数名で示される関数を実行することにより、関数の実行の結果である返り値を取得する。

評価部１３５は、取得された返り値が正しいかを判定する（ステップＳ１４）。このステップＳ１４での判定は、次のように行われる。まず、取得された返り値が選択されたＡＰＩ情報中の返り値と比較される。そして、両返り値が同じであるならば、取得された返り値は正しいと判定される。これに対し、両返り値が異なっているならば、取得された返り値は誤っていると判定される。

ところで、返り値の「型」は様々である。例えば返り値の型が整数型のように、選択されたＡＰＩ情報中の返り値と比較可能な場合には、上述の判定手法を適用することができる。しかし、比較ができない「型」の返り値もある。そこで、比較ができないような「型」の返り値が返される関数に関するＡＰＩ情報は、例えばステップＳ１１での選択の対象から外せばよい。また、値の比較ができないような「型」の返り値の場合に、取得された返り値自体が、対応する関数の実行に成功したと見なせるか否かによって、当該返り値が正しいかを判定するようにしても構わない。例えば「ＲｅｇＯｐｅｎＫｅｙＥｘ」というレジストリ操作関数は、レジストリのハンドルを返す。したがって、レジストリ操作関数の実行の場合、返り値として「ハンドル」が返されたなら、当該返り値が正しいと判定するようにしても構わない。

さて、取得された返り値が正しくないと、上記ステップＳ１４において判定された場合、評価部１３５は待機系ノード１０-2でのアプリケーション１２-2の稼動が不可であることを示す評価結果を、当該ノード１０-2内のクラスタ制御部１３１に通知する（ステップＳ１５）。するとクラスタ制御部１３１は、この評価部１３５による評価結果を、他の待機系ノードであるノード１０-3のクラスタ制御部１３１に通知する。待機系ノード１０-3内のクラスタ制御部１３１は、待機系ノード１０-2内のクラスタ制御部１３１から通知された評価結果を当該ノード１０-3内の評価部１３５に送る。

評価部１３５はステップＳ１５を実行した場合、待機系ノード１０-2でアプリケーション１２-2を稼動することはできず、当該ノード１０-2は引き継ぎ先ノードとして不適であると決定する（ステップＳ１６）。この評価部１３５の決定結果は待機系ノード１０-2内のクラスタ制御部１３１に通知される（ステップＳ２０）。

これに対し、取得された返り値が正しいと、上記ステップＳ１４において判定された場合、評価部１３５は、実行されるべきＡＰＩ情報を全て実行したかを判定する（ステップＳ１７）。もし、実行されるべきＡＰＩ情報（未選択のＡＰＩ情報）があるならば（ステップＳ１７）、評価部１３５は当該未選択のＡＰＩ情報を選択して（ステップＳ１１）、ステップＳ１２以降の処理を行う。

一方、実行されるべき未選択のＡＰＩ情報がないならば（ステップＳ１７）、評価部１３５は、実行されるべきＡＰＩ情報は全て選択されて、当該ＡＰＩ情報の示す全ての関数の実行により取得された返り値はいずれも正しかったと判断する。この場合、評価部１３５は、待機系ノード１０-2でのアプリケーション（ここではアプリケーション１２-2）の稼動が可能であることを示す評価結果を、当該ノード１０-2内のクラスタ制御部１３１に通知する（ステップＳ１８）。すると待機系ノード１０-2内のクラスタ制御部１３１は、評価部１３５の評価結果を、他の待機系ノードであるノード１０-3のクラスタ制御部１３１に通知する。待機系ノード１０-3内のクラスタ制御部１３１は、待機系ノード１０-2内のクラスタ制御部１３１から通知された評価結果を当該ノード１０-3内の評価部１３５に送る。

待機系ノード１０-3においても、待機系ノード１０-2と同様の処理が行われ、当該ノード１０-3内の評価部１３５による評価結果、つまりノード１０-3でアプリケーション１２-3を稼動することが可能であるかの評価結果が、待機系ノード１０-2内のクラスタ制御部１３１に通知される。待機系ノード１０-2内のクラスタ制御部１３１は、待機系ノード１０-3についての評価結果を、当該待機系ノード１０-2内の評価部１３５に通知する。

待機系ノード１０-2内の評価部１３５はステップＳ１８を実行すると、当該ノード１０-2を含む各待機系ノード（ここでは待機系ノード１０-2及び１０-3）の評価結果に基づき、当該ノード１０-2が引き継ぎ先ノードとして最適かを決定（判定）する（ステップＳ１９）。もし、待機系ノード１０-2及び１０-3の評価結果が、いずれもアプリケーションの稼動が可能であることを示す場合、待機系ノード１０-2内の評価部１３５は、当該ノード１０-2の方が予め定められた優先度が高いかによって、当該ノード１０-2が引き継ぎ先ノードとして最適かを決定する。これに対し、待機系ノード１０-2及び１０-3の評価結果のうち、待機系ノード１０-2の評価結果のみアプリケーションの稼動が可能であることを示す場合、当該待機系ノード１０-2内の評価部１３５は、当該ノード１０-2が引き継ぎ先ノードとして最適であると決定する。

評価部１３５は、ステップＳ１９における決定結果を待機系ノード１０-2内のクラスタ制御部１３１に通知する。待機系ノード１０-2内のクラスタ制御部１３１は、当該ノード１０-2が引き継ぎ先ノードとして最適であると決定された場合だけ、稼動系ノード１０-1での処理を引き継ぐための制御を行う。

待機系ノード１０-3においても、待機系ノード１０-2と同様の処理が行われ、当該ノード１０-3を含む各待機系ノード（ここでは待機系ノード１０-2及び１０-3）の評価結果に基づき、当該ノード１０-3が引き継ぎ先ノードとして最適かが決定される。

このように第１の実施形態においては、アプリケーション１２-1が稼動している稼動系ノード１０-1に異常が発生した場合に、待機系ノード１０-2及び１０-3のいずれかが引き継ぎ先ノードとなって稼動系ノード１０-1での処理を実際に引き継ぐ前に、当該待機系ノード１０-2及び１０-3でアプリケーション１２-2及び１２-3が稼動可能であるかを評価し、稼動可能と評価されたノードが引き継ぎ先ノードとして決定される。このため第１の実施形態によれば、アプリケーションの実行失敗による障害発生を減少させることができる。

第１の実施形態では、リソースを大量に消費する関数を、評価部１３５によって実行される関数、つまりアプリケーション１２-iの動作に大きな影響のある関数として挙げている。しかし、使用頻度の高い関数も、アプリケーション１２-iの動作に大きな影響のある関数として挙げることができる。このような使用頻度の高い関数は、例えばＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報の示す関数の中から、予め定められた閾値を超える使用頻度の関数として選択することができる。

また第１の実施形態では、待機系ノードの評価結果が他の待機系ノードに通知され、これにより全待機系ノードは、それぞれの評価結果を共有する。しかし、ノード１０-1〜１０-3によって共有される共有ストレージ装置内に各待機系ノードの評価結果を格納するための特別の記憶領域が確保される構成とするならば、待機系ノード１０-2及び１０-3内の評価部１３５が当該記憶領域に自身の評価結果を格納するだけで、待機系ノード１０-2及び１０-3は、それぞれの評価結果を共有することができる。

また第１の実施形態では、稼動系ノードがノード１０-1の１台、待機系ノードがノード１０-2及び１０-3の２台であるクラスタシステムを想定している。しかし、Ｎ及びＭを０より大きい整数であるとすると、Ｎ台の稼動系ノードとＭ台の待機系ノードで構成されるクラスタシステムであっても構わない。ここでＭが１の場合、つまり待機系ノードが１台の場合、当該待機系ノードは前述したように、自身の評価結果（アプリケーションを稼動することが可能であるかの評価結果）のみで、引き継ぎ先ノードとして最適かを決定すればよい。

［第２の実施形態］
次に本発明の第２の実施形態について、図１のブロック図を援用して説明する。

図６は、第２の実施形態で適用されるノード１０-i（ｉ＝１，２，３）の構成を示すブロック図である。図６において、図２と等価な部分には同一参照符号が付されている。

図６に示すノード１０-iの構成は、当該ノード１０-i内のクラスタ管理部１３-iに情報収集部１３６が追加されている点と、当該ノード１０-i内に収集情報記憶部１５-iが追加されている点で、第１の実施形態におけるノード１０-i（図２に示すノード１０-iの構成）と相違する。したがって以下の説明では、図１において、ノード１０-1〜１０-3が、それぞれ収集情報記憶部１５-1〜１５-3を有しているものとする。また、図６に示すノード１０-i内の評価部１３５の機能は、上記第１の実施形態と一部相違する。

ノード１０-i内の情報収集部１３６は、引き継ぎ先ノードを決定する際に利用される情報を予め収集するように構成されている。この情報は、ノード１０-iが稼動系ノードであって、且つ当該稼動系ノード１０-iにおいてアプリケーション１２-iが正常に動作している場合における、リソース消費量の時系列データである。情報収集部１３６は、収集したリソース消費量の時系列データに基づいて、当該リソース消費量の統計値を算出する。ここでは説明を簡単にするために、リソース消費量がメモリ消費量であるものとする。

ノード１０-i内の収集情報記憶部１５-iは、稼動系ノードの情報収集部１３６で収集された情報（リソース消費量の時系列データ及びリソース消費量の統計値）を格納するのに用いられる。

第２の実施形態において、ノード１０-i内の評価部１３５は、稼動系ノードの異常が検知され、且つ当該ノード１０-iが待機系ノードの場合に、ＡＰＩ情報記憶部１４-iに格納されているＡＰＩ情報（つまり稼動系ノードのＡＰＩフック部１３４によって取得されたＡＰＩ情報）の示す関数を実行することによって、収集情報記憶部１５-i内に収集されているリソース消費量の統計値の示すリソース量が確保できるかを判定する。ノード１０-i内の評価部１３５は、この判定結果に基づいて、当該ノード１０-iを引き継ぎ先ノードとするかを決定する。

次に第２の実施形態の動作について、上記第１の実施形態と同様に、ノード１０-1が稼動系ノードとして動作し、ノード１０-2及び１０-3が待機系ノードとして動作している場合を例に説明する。

＜稼動系ノード内の情報収集部の動作＞
まず、稼動系ノード１０-1内の情報収集部１３６の動作について説明する。
稼動系ノード１０-1内のＡＰＩフック部１３４は、第１の実施形態と同様に、アプリケーション１２-1が使用するＡＰＩ（関数）をフックする。稼動系ノード１０-1内の情報収集部１３６は、アプリケーション１２-1の起動時から、当該アプリケーション１２-1が正常に稼動している限り、ＡＰＩフック部１３４によってフックされた関数の実行によって消費されるリソース量を収集する。ここで、関数の実行によって消費されるリソース量は、アプリケーション１２-1が関数を呼び出す際に明示的に示される。例えば、メモリ確保関数としてのｍａｌｌｏｃ関数は、確保されるべきサイズ（ｓｉｚｅ）を指定する引数を用いて、「ｍａｌｌｏｃ（ｓｉｚｅ）」の形式で表される。この引数ｓｉｚｅから、「ｍａｌｌｏｃ（ｓｉｚｅ）」が実行された場合に、ｓｉｚｅバイトのメモリ量（リソース）が確保（確保）されることを認識できる。

情報収集部１３６は、例えばｍａｌｌｏｃ関数がＡＰＩフック部１３４によってフックされた場合、当該ＡＰＩフック部１３４から、このｍａｌｌｏｃ関数の引数ｓｉｚｅ、つまりｓｉｚｅバイトという確保されるべきメモリ量を示すデータを、消費されるメモリ量（リソース量）を示すデータとして取得する。情報収集部１３６は、ＡＰＩフック部１３４によってフックされた関数の実行によって消費されるメモリ量（メモリ消費量）を示すデータを収集する都度、そのデータを時系列順に収集情報記憶部１５-1に格納する。

情報収集部１３６は、収集情報記憶部１５-1に収集されたメモリ消費量の時系列データに基づき、メモリ消費量の統計値を、例えば定期的に算出する。ここで、メモリ消費量の統計値は、例えば、メモリ消費量の最大値または平均値である。また、平均値の計算に、予め定められた閾値を超えるようなスパイク値を除くことも可能である。更に、平均値として、アプリケーション１２-1の起動時からの全期間に亙る平均値、日平均値または週平均値を適用することも可能である。

情報収集部１３６は、メモリ消費量（リソース消費量）の統計値を算出すると、当該統計値を最新のメモリ消費量の統計値として収集情報記憶部１５-1内の統計値領域に格納する。これにより統計値領域の内容が、最新のメモリ消費量の統計値に更新される。同時に情報収集部１３６は、この最新のメモリ消費量の統計値を、クラスタ制御部１３１によって、待機系ノード１０-2及び１０-3のクラスタ制御部１３１を介して当該待機系ノード１０-2及び１０-3の情報収集部１３６に転送させる。

転送された最新のメモリ消費量の統計値は、待機系ノード１０-2及び１０-3の情報収集部１３６によって当該待機系ノード１０-2及び１０-3の収集情報記憶部１５-2（ｉ＝２）及び１６-3（ｉ＝３）に格納される。これにより、稼動系ノード１０-1内の情報収集部１３６によって取得されたメモリ消費量の統計値は、当該稼動系ノード１０-1及び待機系ノード１０-2及び１０-3によって共有される。つまり、各ノード１０-i（ｉ＝１，２，３）の収集情報記憶部１５-iは、論理的に共有収集情報記憶部を構成する。なお、各ノード１０-iが収集情報記憶部１５-iを持つ代わりに、共有ストレージ装置（の記憶領域）内に、収集情報記憶部が確保される構成としてもよい。

＜待機系ノード内の評価部の動作＞
次に、第１の実施形態と同様に稼動系ノード１０-1に障害が発生したものとする。この場合、待機系ノード１０-2内の評価部１３５は、当該ノード１０-2がアプリケーション１２-2を稼動することが可能かを評価する。同様の評価は、待機系ノード１０-3内の評価部１３５でも行われる。

以下、評価部１３５による評価処理の手順について、待機系ノード１０-2内の評価部１３５の動作を例に、図７のフローチャートを参照して説明する。
まず評価部１３５は、収集情報記憶部１５-i（ｉ＝２）、つまり収集情報記憶部１５-2から、メモリ消費量の統計値を読み込む（ステップＳ２１）。次に評価部１３５は、ＡＰＩ情報記憶部１４-2から、実行されるべきＡＰＩ情報を選択する（ステップＳ２２）。ここでは、実行されるべきＡＰＩ情報が、メモリ領域を確保するためのメモリ確保関数の関数名を含むＡＰＩ情報であるものとする。

評価部１３５は、選択されたＡＰＩ情報中の関数名を用いると共に、当該関数名で指定される関数の引数として、収集情報記憶部１５-2から読み出されたメモリ消費量の統計値を用いて、当該関数（メモリ確保関数）を実行する（ステップＳ２３）。次に評価部１３５は、関数の実行の結果に基づき、メモリ消費量の統計値（引数）で示されるサイズのメモリ量が確保できたかを判定する（ステップＳ２４）。

もし、統計値で示されるサイズのメモリ量が確保できなかったならば（ステップＳ２４）、評価部１３５は第１の実施形態において返り値が正しくないと判定された場合と同様の処理（つまりステップＳ１５，Ｓ１６，Ｓ２０と同様の処理）を実行する（ステップＳ２５，Ｓ２６，Ｓ３０）。

これに対し、統計値で示されるサイズのメモリ量が確保できたならば（ステップＳ２４）、評価部１３５は第１の実施形態において返り値が正しいと判定された場合と同様の処理を実行する。即ち評価部１３５は、実行されるべきＡＰＩ情報を全て実行したかを判定し（ステップＳ２７）、実行されるべきＡＰＩ情報（未選択のＡＰＩ情報）があるならば、当該未選択のＡＰＩ情報を選択して（ステップＳ２２）、ステップＳ２３以降の処理を行う。ここで、統計値で示されるサイズのメモリ量が確保できたということは、当該サイズを引数とした関数（ＡＰＩ）の呼び出し及び実行に必要なメモリ量も確保できたことを意味する点に注意する、
一方、実行されるべき未選択のＡＰＩ情報がないならば（ステップＳ２７）、評価部１３５は第１の実施形態において実行されるべき未選択のＡＰＩ情報がないと判定された場合と同様の処理（つまりステップＳ１８〜Ｓ２０と同様の処理）を実行する（ステップＳ２８〜Ｓ３０）。

待機系ノード１０-3内の評価部１３５においても、上述の待機系ノード１０-2内の評価部１３５と同様の動作が行われる。

これにより、待機系ノード１０-2及び１０-3のいずれか一方においてのみ、上記統計値で示されるサイズのメモリ量が確保できたと判定された場合、つまり待機系ノード１０-2及び１０-3のいずれか一方においてのみアプリケーションを稼動可能であると判定された場合には、その一方のノードが引き継ぎ先ノードとして決定される。また、待機系ノード１０-2及び１０-3の双方で、上記統計値で示されるサイズのメモリ量が確保できたと判定された場合には、待機系ノード１０-2及び１０-3のうち、予め定められた優先度が高い方のノードが引き継ぎ先ノードとして決定される。

［第３の実施形態］
次に本発明の第３の実施形態について、図１のブロック図を援用して説明する。
図８は、第３の実施形態で適用されるノード１０-i（ｉ＝１，２，３）の構成を示すブロック図である。図８において、図６と等価な部分には同一参照符号が付されている。

図８に示すノード１０-iの構成は、当該ノード１０-i内のクラスタ管理部１３-iにＡＰＩフック部１３４及び情報収集部１３６が設けられていない点と、当該ノード１０-i内に情報収集部１３６に相当する情報収集部１６-iが設けられている点と、当該ノード１０-i内にＡＰＩ情報記憶部１４-iが設けられていない点で、第２の実施形態におけるノード１０-i（図６に示すノード１０-iの構成）と相違する。したがって以下の説明では、図１において、ノード１０-1〜１０-3が、それぞれ収集情報記憶部１５-1〜１５-3と情報収集部１６-1〜１６-3を有する一方、ＡＰＩ情報記憶部１４-1〜１４-3を有していないものとする。また、図８に示すノード１０-i内の評価部１３５の機能は、上記第２の実施形態と一部相違する。

第３の実施形態において、ノード１０-i内の情報収集部１６-iは、当該ノード１０-iが稼動系ノードである場合に、アプリケーション１２-iが消費するリソース量の時系列データを、引き継ぎ先を決定する際に利用される情報として収集するように構成されている。情報収集部１６-iは、収集した、アプリケーション１２-iが消費するリソース量（リソース消費量）の時系列データに基づいて、当該リソース消費量の統計値を算出する。

ノード１０-i内の収集情報記憶部１５-iは、稼動系ノードの情報収集部で収集された情報（アプリケーション１２-iが消費するリソース量の時系列データ及び当該リソース消費量の統計値）を格納するのに用いられる。

ノード１０-i内の評価部１３５は、稼動系ノードの異常が検知され、且つ当該ノード１０-iが待機系ノードの場合に、収集情報記憶部１５-i内に収集されているリソース消費量の統計値の示すリソース量と、当該ノード１０-iの現在の空きリソース量とに基づき、当該統計値の示すリソース量が確保できるかを評価する。ノード１０-i内の評価部１３５は、この評価結果に基づいて、当該ノード１０-iを引き継ぎ先ノードとするかを決定する。

次に第３の実施形態の動作について、上記第２の実施形態と同様に、ノード１０-1が稼動系ノードとして動作し、ノード１０-2及び１０-3が待機系ノードとして動作している場合を例に説明する。

＜稼動系ノード内の情報収集部の動作＞
まず、稼動系ノード１０-1内の情報収集部１６-i（ｉ＝１）の動作、つまり情報収集部１６-1の動作について説明する。
情報収集部１６-1は、アプリケーション１２-1が消費するリソース量の時系列データを、当該アプリケーション１２-iの外部から観測（監視）することによって収集する。このような、アプリケーション１２-iが消費するリソース量を観測する仕組みは従来から知られており、専用のコマンド或いはツールを用いることにより実現される。

アプリケーション１２-1が消費するリソース量（第１のリソース量）は、当該アプリケーション１２-1によるＡＰＩ（例えばメモリ確保関数）の呼び出し及び実行に必要なリソース量（第２のリソース量）と、当該ＡＰＩ（関数）の実行によって確保されるリソース量（第３のリソース量）との和である。

このように、第２の実施形態では、第３のリソース量を示すデータだけが収集されるのに対し、第３の実施形態では、第３のリソース量を示すデータに加えて第２のリソース量を示すデータも収集される。第２のリソース量は、関数の引数を保持するためのスタックやＡＰＩの内部処理で消費するリソース量などである。

情報収集部１６-1は、第１のリソース量を示すデータを収集する都度、そのデータを時系列順に収集情報記憶部１５-1に格納する。情報収集部１６-1は、第２の実施形態における情報収集部１３６と同様に、収集情報記憶部１５-1に収集された第１のリソース量の時系列データに基づき、当該第１のリソース量（アプリケーション１２-1で消費されるリソース量）の統計値を、例えば定期的に算出する。

情報収集部１６-1は、第１のリソース量の統計値を算出すると、当該統計値を最新の第１のリソース量（リソース消費量）の統計値として収集情報記憶部１５-1内の統計値領域に格納する。これにより統計値領域の内容が、最新の第１のリソース量の統計値に更新される。同時に情報収集部１６-1は、この最新の第１のリソース量の統計値を、クラスタ制御部１３１によって、待機系ノード１０-2及び１０-3のクラスタ制御部１３１を介して当該待機系ノード１０-2及び１０-3の情報収集部１６-2（ｉ＝２）及び１６-3（ｉ＝３）に転送させる。転送された最新の第１のリソース量の統計値は、待機系ノード１０-2及び１０-3の情報収集部１６-2及び１６-3によって、当該待機系ノード１０-2及び１０-3の収集情報記憶部１５-2（ｉ＝２）及び１６-3（ｉ＝３）に格納される。以下では、リソース量がメモリ量であるものとして説明する。

＜待機系ノード内の評価部の動作＞
次に、第２の実施形態と同様に稼動系ノード１０-1に障害が発生したものとする。この場合、待機系ノード１０-2内の評価部１３５は、当該ノード１０-2がアプリケーション１２-2を稼動することが可能かを評価する。同様の評価は、待機系ノード１０-3内の評価部１３５でも行われる。

以下、評価部１３５による評価処理の手順について、待機系ノード１０-2内の評価部１３５の動作を例に、図９のフローチャートを参照して説明する。
まず、評価部１３５は、収集情報記憶部１５-2（ｉ＝２）から、第１のメモリ量（第１のリソース量）の統計値（つまりアプリケーションが消費するメモリ量の統計値）を読み込む（ステップＳ３１）。次に評価部１３５は、読み込まれた統計値で示されるメモリ量（リソース量）を、待機系ノード１０-2の現在の空きメモリ量（リソース量）と比較する（ステップＳ３２）。ここで、待機系ノード１０-2の現在の空きメモリ量を示すデータは、周知のように、ＯＳ１１-2（ｉ＝２）に問い合わせることによって当該ＯＳ１１-2から取得することができる。

評価部１３５は、上記の比較の結果に基づき、上記読み込まれた統計値で示されるメモリ量が待機系ノード１０-2において確保で可能であるかを判定する（ステップＳ３３）。

さて、収集情報記憶部１５-2（ｉ＝２）に収集されている第１のメモリ量の統計値は最新の統計値である。したがって、この統計値の示すメモリ量は、現時点（つまり稼動系ノード１０-1で障害が発生した時点）において待機系ノード１０-2が引き継ぎ先ノードとして動作してアプリケーション１２-2を実行するのに必要となるメモリ量であると見なすことができる。このため、待機系ノード１０-2内の評価部１３５が、上述の比較の結果に基づいて、当該ノード１０-2において上記統計値の示すメモリ量を確保可能であると判定できるならば、当該ノード１０-2でアプリケーション１２-2を稼動することができると判定できる。

そこで、上記統計値で示されるメモリ量が待機系ノード１０-2において確保できないと判定されたならば（ステップＳ３３）、評価部１３５は第２の実施形態において引数で示されるメモリ量が確保できなかった場合と同様の処理（つまりステップＳ２５，Ｓ２６，Ｓ３０と同様の処理）を実行する（ステップＳ３４，Ｓ３５，Ｓ３８）。

これに対し、上記統計値で示されるメモリ量が待機系ノード１０-2において確保できると判定されたならば（ステップＳ３３）、評価部１３５は第２の実施形態おいて引数で示されるメモリ量が確保でき、且つ実行されるべき未選択のＡＰＩ情報がないと判定された場合と同様の処理（つまりステップＳ２８〜Ｓ３０と同様の処理）を実行する（ステップＳ３６〜Ｓ３８）。

待機系ノード１０-3内の評価部１３５においても、上述の待機系ノード１０-2内の評価部１３５と同様の動作が行われる。

これにより、待機系ノード１０-2及び１０-3のいずれか一方においてのみ、上記統計値で示されるサイズのメモリ量が確保可能であると判定された場合、つまり待機系ノード１０-2及び１０-3のいずれか一方においてのみアプリケーションを稼動可能であると判定された場合には、その一方のノードが引き継ぎ先ノードとして決定される。また、待機系ノード１０-2及び１０-3の双方で、上記統計値で示されるサイズのメモリ量が確保可能であると判定された場合には、待機系ノード１０-2及び１０-3のうち、予め定められた優先度が高い方のノードが引き継ぎ先ノードとして決定される。第３の実施形態では、アプリケーションからのＡＰＩの呼び出しをフックすることなく、待機系ノードの中から最適な引き継ぎ先ノードを決定することができる。

［第４の実施形態］
次に本発明の第４の実施形態について、図１のブロック図を援用して説明する。
図１０は、第４の実施形態で適用されるノード１０-i（ｉ＝１，２，３）の構成を示すブロック図である。図１０において、図２と等価な部分には同一参照符号が付されている。

図１０に示すノード１０-iの構成は、当該ノード１０-i内のクラスタ管理部１３-iにＡＰＩフック部１３４に代えてＡＰＩフック・Ｉ／Ｏ隔離部１３７が設けられている点で、第１の実施形態におけるノード１０-i（図２に示すノード１０-iの構成）と相違する。また、図１０に示すノード１０-i内の評価部１３５の機能は、上記第１の実施形態と一部相違する。

第４の実施形態において、ノード１０-i内のクラスタ管理部１３-iに設けられたＡＰＩフック・Ｉ／Ｏ隔離部１３７は、図２に示されるＡＰＩフック部１３４と同様の機能（ＡＰＩフック機能）に加えて、評価部１３５による評価のためにアプリケーション１２-iから呼び出される関数（ＡＰＩ）を当該評価部１３５に代わって仮想的に実行することにより、通常であれば当該アプリケーション１２-iとＯＳ１１-iとの間で授受される入出力（Ｉ／Ｏ）を当該ＯＳ１１-iから隔離する機能（Ｉ／Ｏ隔離機能）を有する。ＡＰＩフック・Ｉ／Ｏ隔離部１３７は、アプリケーション１２-iから呼び出された関数と返り値とを評価部１３５に渡す。

第４の実施形態において、評価部１３５はＡＰＩ情報記憶部１４-iに格納されている関数の呼び出し（実行）を自身が行う代わりに、アプリケーション１２-iを動作させることにより、当該関数の呼び出し（実行）を当該アプリケーション１２-i自身に行わせる。つまり評価部１３５は、ＡＰＩ情報記憶部１４-iに格納されている関数の呼び出し（実行）を、アプリケーション１２-iを動作させることによって実現する。

評価部１３５は、アプリケーション１２-1による関数の呼び出し（実行）に応じてＡＰＩフック・Ｉ／Ｏ隔離部１３７によって取得された返り値が正しいかを、当該関数の関数名に対応付けてＡＰＩ情報記憶部１４-iに格納されている返り値に基づいて判定することにより、ノード１０-iでのアプリケーション１２-iの稼動が可能であるかを評価する。

次に、第４の実施形態の動作について、図１の例のように、ノード１０-1が稼動系ノードとして動作し、ノード１０-2及び１０-3が待機系ノードとして動作している場合を例に説明する。

＜稼動系ノード内のＡＰＩフック・Ｉ／Ｏ隔離部の動作＞
稼動系ノード１０-1内のＡＰＩフック・Ｉ／Ｏ隔離部１３７は、上記第１の実施形態におけるＡＰＩフック部１３４と同様に、図３のフローチャートの示す手順で動作する。即ちＡＰＩフック・Ｉ／Ｏ隔離部１３７は、アプリケーション１２-1によってコールされたＡＰＩ（関数）をフックする。但し、第４の実施形態では、待機系ノード１０-2及び１０-3内の評価部１３５は、ＡＰＩフック・Ｉ／Ｏ隔離部１３７によってフックされたＡＰＩを直接実行しない。このため、ＡＰＩフック・Ｉ／Ｏ隔離部１３７が引数を取得する必要はない。つまり、第４の実施形態においてＡＰＩフック・Ｉ／Ｏ隔離部１３７は、アプリケーション１２-1によってコールされた関数の関数名と返り値とを取得する。取得された、関数名及び返り値を含むＡＰＩ情報は、ノード１０-1〜１０-3のＡＰＩ情報記憶部１４-1〜１４-3（つまり共有ＡＰＩ情報記憶部）に時系列順に格納される。

＜待機系ノード内の評価部及びＡＰＩフック・Ｉ／Ｏ隔離部の動作＞
次に、稼動系ノード１０-1に障害が発生した結果、待機系ノード１０-2及び１０-3内の評価部１３５が起動されたものとする。これにより待機系ノード１０-2及び１０-3内の評価部１３５は、それぞれ当該ノード１０-2及び１０-3においてアプリケーション１２-2及び１２-3を稼動することが可能であるかを評価する。

以下、評価部１３５及びＡＰＩフック・Ｉ／Ｏ隔離部１３７の動作について、待機系ノード１０-2内の評価部１３５及びＡＰＩフック・Ｉ／Ｏ隔離部１３７の動作を例に、図１１の動作説明図を参照して説明する。

待機系ノード１０-2内の評価部１３５は、図１１において矢印１１１で示されるように、ＡＰＩフック・Ｉ／Ｏ隔離部１３７に対して評価モードを通知すると共に、矢印１１２で示されるように、アプリケーション１２-2を実際に起動する。するとアプリケーション１２-2は、稼動系ノードにおけるのと同様に動作して、必要に応じてＡＰＩ（関数）を呼び出す。

ＡＰＩフック・Ｉ／Ｏ隔離部１３７は、第１の実施形態において稼動系ノードで動作するけるＡＰＩフック部１３４と同様に、アプリケーション１２-2によって呼び出される（コールされる）ＡＰＩを、図１１において矢印１１３で示されるようにフックする。評価モードにおいて、ＡＰＩフック・Ｉ／Ｏ隔離部１３７は、フックしたＡＰＩ（関数）を、アプリケーション１２-2とＯＳ１１-2との間で授受されるＩ／Ｏが隔離されるように、以下に述べるように仮想的に実行する。そしてＡＰＩフック・Ｉ／Ｏ隔離部１３７は、関数の実行結果としての返り値を、図１１において矢印１１４で示されるようにアプリケーション１２-2に返す。

ＡＰＩフック・Ｉ／Ｏ隔離部１３７（待機系ノード１０-2内のＡＰＩフック・Ｉ／Ｏ隔離部１３７）によってフックされたＡＰＩに関するＡＰＩ情報は、当該ＡＰＩが稼動系ノード１０-1内のＡＰＩフック・Ｉ／Ｏ隔離部１３７によってフックされた際に、ＡＰＩ情報記憶部１４-1〜１４-3に格納されている。したがって、評価部１３５から評価モードの通知を受けた待機系ノード１０-2内のＡＰＩフック・Ｉ／Ｏ隔離部１３７が、フックしたＡＰＩを実行することは、ＡＰＩ情報記憶部１４-2に格納されているＡＰＩ情報の示すＡＰＩを、評価部１３５がＡＰＩフック・Ｉ／Ｏ隔離部１３７を用いて実行することと等価である。

さて、待機系ノード１０-2内のＡＰＩフック・Ｉ／Ｏ隔離部１３７によってフックされた関数が、当該ディスクライトやネットワークへのデータ送出を伴う特別の関数である場合があり得る。そこでＡＰＩフック・Ｉ／Ｏ隔離部１３７は、少なくとも、自身がフックした関数が上記のような特別な関数の場合には、当該関数をＯＳ１１-2を用いて実際に実行しないように構成されている。これにより、通常であればアプリケーション１２-2とＯＳ１１-2との間で授受されるＩ／Ｏが隔離され、上記のような特別な関数の実行に起因してディスクライトやネットワークへのデータ送出が発生するのを防止できる。

そこでＡＰＩフック・Ｉ／Ｏ隔離部１３７は、自身がフックした関数を仮想的に実行することにより当該関数の実行結果としての返り値を生成する。ＡＰＩフック・Ｉ／Ｏ隔離部１３７は、生成された返り値を上述のようにアプリケーション１２-2に返す。これによりＡＰＩフック・Ｉ／Ｏ隔離部１３７は、アプリケーション１２-2から呼び出された関数（ＡＰＩ）が実行されたかのように見せかけて、当該アプリケーション１２-2に次の処理を行わせることができる。なお、ＡＰＩフック・Ｉ／Ｏ隔離部１３７がフックした関数が上記特別な関数でない場合、ＯＳ１１-2を用いて当該関数を実行しても構わない。

ＡＰＩフック・Ｉ／Ｏ隔離部１３７は、アプリケーション１２-2に返り値を返す際に、その返り値と実行された関数の関数名とを、図１１において矢印１１５で示されるように、評価部１３５に渡す。ここでアプリケーション１２-2の動作が正常であるならば、当該アプリケーション１２-2が起動されてから少なくとも当該アプリケーション１２-2の起動が完了するまでの間は、ＡＰＩフック・Ｉ／Ｏ隔離部１３７によってフックされる関数の順番は、ＡＰＩ情報記憶部１４-2に時系列順に格納されているＡＰＩ情報の示す関数の順番に一致する。したがって評価部１３５は、アプリケーション１２-2の動作が正常であるならば、ＡＰＩフック・Ｉ／Ｏ隔離部１３７から渡された関数名の関数が、ＡＰＩフック・Ｉ／Ｏ隔離部１３７によって何番目にフックされたかに基づいて、図１１において矢印１１６で示されるようにＡＰＩ情報記憶部１４-1を参照することで、当該関数名を含むＡＰＩ情報に含まれている返り値を取得することができる。

なお、ノード１０-i（ｉ＝１，２，３）が、ＡＰＩフック・Ｉ／Ｏ隔離部１３７に代えて、稼動系ノードの場合にだけ動作する、第１の実施形態におけるＡＰＩフック部１３４に相当するＡＰＩフック部と、待機系ノードの場合にだけ動作するＡＰＩフック・Ｉ／Ｏ隔離部とを有していても構わない。

評価部１３５は、ＡＰＩフック・Ｉ／Ｏ隔離部１３７から渡された返り値が正しいかを、ＡＰＩ情報記憶部１４-1から取得された返り値と比較することによって判定する。

評価部１３５は、アプリケーション１２-2の起動から予め定められたタイミングが到来するまで評価モードを継続する。このタイミングは、例えばアプリケーション１２-2の起動が完了するタイミングである。評価部１３５は、このタイミングが到来すると、評価モードを解除する。これによりＡＰＩフック・Ｉ／Ｏ隔離部１３７は、フック動作とフックされた関数の実行とを停止する。

評価部１３５は、評価モードの期間に、ＡＰＩフック・Ｉ／Ｏ隔離部１３７によってフックされた関数の実行の結果である返り値が全て正しかったならば、第１の実施形態におけるステップＳ１８と同様に、待機系ノード１０-2でのアプリケーション１２-2の稼動が可能であることを示す評価結果を、当該ノード１０-2内のクラスタ制御部１３１に通知する。この評価結果は、ノード１０-2内のクラスタ制御部１３１によって他の待機系ノード１０-3に通知される。また、この待機系ノード１０-3内の評価部１３５の評価結果は待機系ノード１０-2にも通知される。

待機系ノード１０-2内の評価部１３５は、上記第１の実施形態と同様に、当該ノード１０-2を含む各待機系ノード（ここでは待機系ノード１０-2及び１０-3）の評価結果に基づき、当該ノード１０-2が引き継ぎ先ノードとして最適かを決定する。
待機系ノード１０-3においても、待機系ノード１０-2と同様の処理が行われ、当該ノード１０-3を含む各待機系ノード（ここでは待機系ノード１０-2及び１０-3）の評価結果に基づき、当該ノード１０-3が引き継ぎ先ノードとして最適かが決定される。

このように第４の実施形態では、待機系ノード１０-2及び１０-3において、それぞれアプリケーション１２-2及び１２-3を実際に動作させることにより、当該アプリケーション１２-2及び１２-3を正常に稼動可能かを判定することができるため、第１の実施形態に比べてより正確に引き継ぎ先ノードを決定することが可能となる。

なお、本発明は、上記第１乃至第４の実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、第１乃至第４の実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、第１乃至第４の実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。

本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図。 図１に示されるノードの構成を示す示すブロック図。 同第１の実施形態における稼動系ノード内のＡＰＩフック部の動作手順を示すフローチャート。 同第１の実施形態における稼動系ノード内のＡＰＩフック部の動作を説明するための図。 同第１の実施形態における待機系ノード内の評価部の動作手順を示すフローチャート。 本発明の第２の実施形態で適用されるノードの構成を示すブロック図。 同第２の実施形態における待機系ノード内の評価部の動作手順を示すフローチャート。 本発明の第３の実施形態で適用されるノードの構成を示すブロック図。 同第３の実施形態における待機系ノード内の評価部の動作手順を示すフローチャート。 本発明の第４の実施形態で適用されるノードの構成を示すブロック図。 同第４の実施形態における待機系ノード内の評価部及びＡＰＩフック部の動作を説明するための図。

符号の説明

１０-1〜１０-3，１０-i…ノード（サーバ計算機）、１１-1〜１１-3，１１-i…ＯＳ（オペレーティングシステム）、１２-1〜１２-3，１２-i…アプリケーション、１３-1〜１３-3，１３-i…クラスタ管理部、１４-1〜１４-3，１４-i…ＡＰＩ（アプリケーションプログラムインタフェース）情報記憶部（記憶手段）、１５-i…収集情報記憶部（記憶手段）、１６-i，１３６…情報収集部、１３１…クラスタ制御部、１３４…ＡＰＩフック部、１３５…評価部、１３７…ＡＰＩフック・Ｉ／Ｏ隔離部。

Claims (5)

1. 稼動系ノードとして動作する場合に所定のアプリケーションを稼動させることによりクライアントに対してサービスを提供する、通信路によって相互接続された複数のサーバ計算機と、前記複数のサーバ計算機によって共有される記憶手段とを備えたクラスタシステムにおいて、
   前記複数のサーバ計算機はそれぞれ、前記通信路を介して連携することにより当該複数のサーバ計算機のクラスタ構成を管理するクラスタ管理手段を有し、
   前記クラスタ管理手段は、
   前記アプリケーションとオペレーティングシステムとの間に位置するフック手段であって、当該クラスタ管理手段を有するサーバ計算機が稼動系ノードとして動作している場合、当該稼動系ノードで稼動している前記アプリケーションが使用するアプリケーションプログラムインタフェースをフックして、そのフックされたアプリケーションプログラムインタフェースの実行結果を含む当該アプリケーションプログラムインタフェースに関するアプリケーションプログラムインタフェース情報を前記記憶手段に格納するフック手段と、
   当該クラスタ管理手段を有するサーバ計算機が待機系ノードとして動作している状態で前記稼動系ノードで障害が発生した場合、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースを実行し、その実行結果が正しいかを、当該アプリケーションプログラムインタフェース情報に含まれている実行結果に基づいて判定することにより、当該クラスタ管理手段を有するサーバ計算機で前記アプリケーションを稼動することが可能であるかを評価して、その評価結果に基づき、当該クラスタ管理手段を有するサーバ計算機が前記障害を発生した稼動系ノードの引き継ぎノードとして最適であるかを決定する評価手段とを含む
   ことを特徴とするクラスタシステム。
2. 前記評価手段は、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースの実行のために前記アプリケーションを稼動し、
   前記フック手段は、前記評価手段によって稼動された前記アプリケーションが使用するアプリケーションプログラムインタフェースをフックして当該アプリケーションプログラムインタフェースを実行することによって、前記アプリケーションと前記オペレーティングシステムとの間で授受される入出力を隔離し、当該アプリケーションプログラムインタフェースの実行結果を前記アプリケーションに返すと共に、前記フックされたアプリケーションプログラムインタフェースの実行結果を含む当該アプリケーションプログラムインタフェースに関する第１のアプリケーションプログラムインタフェース情報を前記評価手段に渡し、
   前記評価手段は前記フック手段から渡された前記第１のアプリケーションプログラムインタフェース情報に含まれている実行結果を当該評価手段の実行結果として、その実行結果が正しいかを、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報のうち前記第１のアプリケーションプログラムインタフェース情報に対応する第２のアプリケーションプログラムインタフェース情報に含まれている実行結果に基づいて判定する
   ことを特徴とする請求項１記載のクラスタシステム。
3. 前記クラスタ管理手段は、当該クラスタ管理手段を有するサーバ計算機が稼動系ノードとして動作している場合、前記フック手段によってフックされたアプリケーションプログラムインタフェースの実行によって消費されるリソース量を示すデータを収集して、当該収集されたリソース量を示すデータを前記記憶手段に格納する収集手段を更に有し、
   前記評価手段は、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースの実行結果が正しいかを、当該アプリケーションプログラムインタフェース情報に含まれている実行結果に対応する、前記記憶手段に格納されている前記収集されたデータの示すリソース量が確保可能であるかによって判定する
   ことを特徴とする請求項１記載のクラスタシステム。
4. 前記待機系ノードの数は１を超えており、
   前記評価手段は、当該評価手段自身の評価結果及び、当該評価手段を有するサーバ計算機である第１のサーバ計算機とは別のサーバ計算機のうち前記待機系ノードとして動作している別の計算機である第２のサーバ計算機が有する評価手段の評価結果に基づいて、前記第１のサーバ計算機が前記障害を発生した稼動系ノードの引き継ぎノードとして最適であるかを決定する
   ことを特徴とする請求項１乃至３のいずれかに記載のクラスタシステム。
5. 稼動系ノードとして動作する場合に所定のアプリケーションを稼動させることによりクライアントに対してサービスを提供する、通信路によって相互接続された複数のサーバ計算機と、前記複数のサーバ計算機によって共有される記憶手段とを備えたクラスタシステムにおいて、前記稼動系ノードで障害が発生した場合に引き継ぎ先ノードを決定するための引き継ぎ先ノード決定方法であって、
   前記複数のサーバ計算機のうちの稼動系ノードが、当該稼動系ノードで稼動している前記アプリケーションが使用するアプリケーションプログラムインタフェースをフックするステップと、
   前記フックされたアプリケーションプログラムインタフェースの実行結果を含む当該アプリケーションプログラムインタフェースに関するアプリケーションプログラムインタフェース情報を、前記稼動系ノードが前記記憶手段に格納するステップと、
   前記稼動系ノードで障害が発生した場合に、前記複数のサーバ計算機のうちの待機系ノードが、前記記憶手段に格納されているアプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースを実行するステップと、
   前記待機系ノードが、前記アプリケーションプログラムインタフェース情報で示されるアプリケーションプログラムインタフェースの実行結果が正しいかを、当該アプリケーションプログラムインタフェース情報に含まれている実行結果に基づいて判定することにより、当該待機系ノードで前記アプリケーションを稼動することが可能であるかを評価して、その評価結果に基づき、当該待機系ノード自身が前記障害を発生した稼動系ノードの引き継ぎノードとして最適であるかを決定するステップと
   を具備することを特徴とする引き継ぎノード決定方法。

Images