(57)【要約】【課題】アプリケーションのクラスタ化を阻害する可能性があるサーバ固有情報へのアクセスの状況を示す情報をユーザに提供できるようにする。【解決手段】フックライブラリ機構２２のフック機構２２２は、アプリケーション１３０からのサーバ固有情報アクセスのためのアプリケーションプログラムインタフェース（ＡＰＩ）の呼び出しを、フックライブラリ記憶部２２１に格納されているフックライブラリに基づいてフックする。フック機構２２２は、フックされた呼び出しを行う。アクセス管理機構２２４は、フックされたＡＰＩの呼び出しに基づくサーバ固有情報へのアクセスをアクセス管理テーブル２２３に記録する。状態通知機構２２６は、アクセス管理テーブル２２３によって示される、アプリケーション１３０からのサーバ固有情報へのアクセスの状況を示す情報をユーザに通知する。【選択図】      図２
2009289054.tif 000002
【特許請求の範囲】
【請求項１】
ユーザに対してサービスを提供するための特定アプリケーションの実行が可能なクラスタシステム向けサーバ計算機において、
前記サーバ計算機に固有のサーバ固有情報を取得するための第１のアプリケーションプログラムインタフェースの集合を含むシステムライブラリを予め格納したシステムライブラリ記憶手段と、
前記第１のアプリケーションプログラムインタフェースの呼び出しを受けて、当該第１のアプリケーションプログラムインタフェースを呼び出し元に提供するアプリケーションプログラムインタフェース提供手段と、
前記第１のアプリケーションプログラムインタフェースに対応付けられ、当該第１のアプリケーションプログラムインタフェースがフックされた際の動作を定義した第２のアプリケーションプログラムインタフェースの集合を含むフックライブラリを予め格納したフックライブラリ記憶手段と、
前記フックライブラリ記憶手段に格納されている前記フックライブラリに基づき、前記特定アプリケーションからの前記第１のアプリケーションプログラムインタフェースの呼び出しをフックするフック手段であって、前記フックライブラリにおいて当該フックされた第１のアプリケーションプログラムインタフェースに対応付けられている前記第２のアプリケーションプログラムインタフェースに従い、当該フックされた第１のアプリケーションプログラムインタフェースを呼び出すフック手段と、
前記特定アプリケーションからの前記第１のアプリケーションプログラムインタフェースの呼び出しに基づく前記サーバ固有情報へのアクセスを記録するのに用いられるアクセス管理テーブルと、
前記フック手段によって前記第１のアプリケーションプログラムインタフェースの呼び出しがフックされた場合に、当該第１のアプリケーションプログラムインタフェースの呼び出しに基づく前記サーバ固有情報へのアクセスを前記アクセス管理テーブルに記録するアクセス管理手段と、
前記アクセス管理テーブルによって示される、前記特定アプリケーションからの前記サーバ固有情報へのアクセスの状況を示す情報をユーザに通知するための状態通知手段と
を具備することを特徴とするクラスタシステム向けサーバ計算機。
【請求項２】
前記アクセス管理テーブルは、前記サーバ固有情報毎に用意される、当該サーバ固有情報へのアクセスの回数を記録するためのエントリを有し、
前記アクセス管理手段は、前記フック手段によって前記第１のアプリケーションプログラムインタフェースの呼び出しがフックされた場合に、当該フックされた第１のアプリケーションプログラムインタフェースの呼び出しに基づいてアクセスされるサーバ固有情報に対応する前記アクセス管理テーブルのエントリに記録されているアクセス回数をインクリメントする
ことを特徴とする請求項１記載のクラスタシステム向けサーバ計算機。
【請求項３】
前記アクセス管理手段によってインクリメントされた後の前記アクセス回数が予め定められた閾値を超えたかを判定する状態判定手段を更に具備し、
前記状態通知手段は、前記状態判定手段の判定結果を、前記特定アプリケーションからの前記サーバ固有情報へのアクセスの状況を示す情報としてユーザに通知する
ことを特徴とする請求項２記載のクラスタシステム向けサーバ計算機。
【請求項４】
前記フック手段によって前記第１のアプリケーションプログラムインタフェースの呼び出しがフックされた場合に、当該第１のアプリケーションプログラムインタフェースの呼び出しに基づいてアクセスされるべき前記サーバ固有情報に代えて、当該サーバ固有情報とは異なるダミーの固有情報を、前記第１のアプリケーションプログラムインタフェースの呼び出し対するに返り値として、前記フック手段によって前記特定アプリケーションに返させる固有情報置換手段を更に具備し、
前記状態判定手段は、前記ダミーの固有情報が返された前記特定アプリケーションの動作状態を監視し、異常発生の有無に基づいて前記特定アプリケーションのクラスタ構成時の悪影響の有無を判定する
ことを特徴とする請求項１乃至３のいずれかに記載のクラスタシステム向けサーバ計算機。
【請求項５】
ユーザに対してサービスを提供するための特定アプリケーションの実行が可能なクラスタシステム向けサーバ計算機であって、前記サーバ計算機に固有のサーバ固有情報を取得するための第１のアプリケーションプログラムインタフェースの集合を含むシステムライブラリを予め格納したシステムライブラリ記憶手段と、前記第１のアプリケーションプログラムインタフェースの呼び出しを受けて、当該第１のアプリケーションプログラムインタフェースを呼び出し元に提供するアプリケーションプログラムインタフェース提供手段と、前記第１のアプリケーションプログラムインタフェースに対応付けられ、当該第１のアプリケーションプログラムインタフェースがフックされた際の動作を定義した第２のアプリケーションプログラムインタフェースの集合を含むフックライブラリを予め格納したフックライブラリ記憶手段と、アクセス管理テーブルとを備えたクラスタシステム向けサーバ計算機に、
前記フックライブラリ記憶手段に格納されている前記フックライブラリに基づき、前記特定アプリケーションからの前記第１のアプリケーションプログラムインタフェースの呼び出しをフックするステップと、
前記フックされた第１のアプリケーションプログラムインタフェースを呼び出すステップと、
前記フックされた第１のアプリケーションプログラムインタフェースの呼び出しに基づく前記サーバ固有情報へのアクセスを前記アクセス管理テーブルに記録するステップと、
前記アクセス管理テーブルによって示される、前記特定アプリケーションからの前記サーバ固有情報へのアクセスの状況を示す情報をユーザに通知するステップと
を実行させるためのアプリケーションクラスタ化可能性判定支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラスタシステムに用いられるサーバ計算機に係り、特にアプリケーションのクラスタ化の可能性の判定を支援するのに好適なクラスタシステム向けサーバ計算機及びアプリケーションクラスタ化可能性判定支援プログラムに関する。
【背景技術】
【０００２】
従来から、複数のサーバ計算機（サーバ）から構成されるクラスタシステムが知られている。このクラスタシステムの特徴は、アプリケーション（特定アプリケーション）の実行によってユーザに提供されるサービスを、当該アプリケーションの障害、或いは当該アプリケーションを実行するサーバの障害が発生しても、当該ユーザに提供し続けることができる点にある。
【０００３】
クラスタシステムでは、当該システムを構成する複数のサーバのうちのあるサーバが稼動系サーバとなってアプリケーションを実行する。クラスタシステムにおいて、アプリケーション自体、或いは当該アプリケーションを実行するサーバに障害が発生した場合、当該システムを構成する他のサーバで同一のアプリケーションを実行し直すことにより、ユーザへ提供するサービスの継続が実現される。以下の説明では、障害が発生したサーバだけでなく、障害が発生したアプリケーションを実行するサーバも、障害発生サーバと呼ぶ。一方、アプリケーションを実行し直すサーバ、つまりアプリケーションの実行（サービス）を引き継ぐサーバを引き継ぎ先サーバと呼ぶ。
【０００４】
クラスタシステムには、サービスの提供を受けるユーザに対して、障害によってアプリケーションを実行するサーバが変わったことを意識させないための仕組みが用意される。この仕組みによれば、上述のようなサービスの継続のために、つまりサービスの連続性を保つために、当該システムを構成するサーバの間で、アプリケーションの利用するデータが共有される。また、障害発生サーバと引き継ぎ先サーバができる限り同じ条件で動作するように、環境（を示す環境情報）の引き継ぎも行われる。
【０００５】
このようなクラスタシステムでアプリケーションが利用可能なためには、つまりアプリケーションのクラスタ化（クラスタ構成化）が可能であるためには、幾つかの条件を必要とする。例えば、サービスの継続のためにアプリケーションを実行するサーバが変わると、当該アプリケーションがハードウェア（ＨＷ）やサーバに固有の情報、例えばホストＩＤ（ＨｏｓｔＩＤ）、ＭＡＣ（Media Access Control）アドレス（物理アドレス）、サーバシリアル番号のようなサーバ固有情報に依存した動作をするものである場合、当該アプリケーションはクラスタ化できない可能性がある。つまり、アプリケーション内部で発生するサーバ固有情報へのアクセスは、当該アプリケーションのクラスタ化を阻害する可能性がある。このため従来は、アプリケーションのクラスタ化の可能性を判断するのに必要な確認ポイントをまとめたチェックシートなどを用いて、当該アプリケーションを利用するユーザがクラスタ化の可能性を判定するのが一般的であった。
【０００６】
ところでアプリケーションは、目的の処理を実行するために関数（アプリケーションプログラムインタフェース：ＡＰＩ）を呼び出す（コールする）のが一般的である。もし、アプリケーションが呼び出す関数（ＡＰＩ）の関数名（ＡＰＩ名）を、他の名前に置き換えて、この置き換えられた関数名と同じ名を持つ関数を実行するならば、関数の変更なしに機能を拡張することができる（例えば特許文献１参照）。
【特許文献１】特開平１１−１１０１９４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
アプリケーションのクラスタ化が可能であるための判定に用いられる情報として、上述のホストＩＤ、ＭＡＣアドレス、サーバシリアル番号のようなサーバ固有情報が挙げられる。このようなサーバ固有情報は、クラスタシステムを構成する複数のサーバで共有されるデータ（共有データ）に含まれているのが一般的である。
【０００８】
しかし、サーバ固有情報には、アプリケーションの外部仕様や機能からユーザが独自に判断できるものと、仕様が公開されておらず、アプリケーションの開発者でないと分からない内部情報的なものとがある。内部情報的なサーバ固有情報、つまり外部から隠蔽されるサーバ固有情報へのアクセスについては、ユーザ（エンドユーザ）側で完全にチェックすることは困難である。また、外部から隠蔽されるサーバ固有情報についての事前の検証で、アプリケーションのクラスタ化が可能であると判定されても、運用時に、当該アプリケーションの特定の使用方法で問題になる場合がある。同様に、ＯＳやアプリケーションのアップデート後の仕様変更で問題になる場合もある。このため、サーバ固有情報についての事前の検証のみでは、アプリケーションのクラスタ化が可能であるかを、全ての可能性を考慮して確認することは難しい。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、アプリケーションのクラスタ化を阻害する可能性がある、当該アプリケーションの内部で隠れて利用されるサーバ固有情報へのアクセスの状況を示す情報をユーザに提供できる、クラスタシステム向けサーバ計算機及びアプリケーションのクラスタ化可能性判定支援プログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの観点によれば、ユーザに対してサービスを提供するための特定アプリケーションの実行が可能なクラスタシステム向けサーバ計算機が提供される。このクラスタシステム向けサーバ計算機は、前記サーバ計算機に固有のサーバ固有情報を取得するための第１のアプリケーションプログラムインタフェースの集合を含むシステムライブラリを予め格納したシステムライブラリ記憶手段と、前記第１のアプリケーションプログラムインタフェースの呼び出しを受けて、当該第１のアプリケーションプログラムインタフェースを呼び出し元に提供するアプリケーションプログラムインタフェース提供手段と、前記第１のアプリケーションプログラムインタフェースに対応付けられ、当該第１のアプリケーションプログラムインタフェースがフックされた際の動作を定義した第２のアプリケーションプログラムインタフェースの集合を含むフックライブラリを予め格納したフックライブラリ記憶手段と、前記フックライブラリ記憶手段に格納されている前記フックライブラリに基づき、前記特定アプリケーションからの前記第１のアプリケーションプログラムインタフェースの呼び出しをフックするフック手段であって、前記フックライブラリにおいて当該フックされた第１のアプリケーションプログラムインタフェースに対応付けられている前記第２のアプリケーションプログラムインタフェースに従い、当該フックされた第１のアプリケーションプログラムインタフェースを呼び出すフック手段と、前記特定アプリケーションからの前記第１のアプリケーションプログラムインタフェースの呼び出しに基づく前記サーバ固有情報へのアクセスを記録するのに用いられるアクセス管理テーブルと、前記フック手段によって前記第１のアプリケーションプログラムインタフェースの呼び出しがフックされた場合に、当該第１のアプリケーションプログラムインタフェースの呼び出しに基づく前記サーバ固有情報へのアクセスを前記アクセス管理テーブルに記録するアクセス管理手段と、前記アクセス管理テーブルによって示される、前記特定アプリケーションからの前記サーバ固有情報へのアクセスの状況を示す情報をユーザに通知するための状態通知手段とを具備する。
【発明の効果】
【００１１】
本発明によれば、特定アプリケーションの運用状態で、当該特定アプリケーションの内部で隠れて利用されるサーバ固有情報へのアクセス（つまり、当該特定アプリケーションのクラスタ化を阻害する可能性があるサーバ固有情報へのアクセス）のための、当該特定アプリケーションからの呼び出し（第１のアプリケーションプログラムインタフェースの呼び出し）をフックすることにより、ユーザが当該特定アプリケーションのクラスタ化の可能性を判定するのに利用可能な、サーバ固有情報へのアクセスの状況を示す情報を提供することができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態につき図面を参照して説明する。  
図１は本発明の一実施形態に係るクラスタシステム向けサーバ計算機のハードウェア構成を示すブロック図である。
【００１３】
図１において、サーバ計算機（以下、サーバと称する）１０は、それぞれ、ＣＰＵ１１と、主メモリ１２とを含む。サーバ１０は、例えば磁気ディスク装置のような外部記憶装置１３と接続されている。外部記憶装置１３は、サーバ１０の筐体（図示せず）内に配置されている。つまりサーバ１０は、ＣＰＵ１１及び主メモリ１２に加えて、外部記憶装置１３を有している。
【００１４】
外部記憶装置１３には、アプリケーション１３０が格納されている。アプリケーション１３０は、クラスタシステムを利用するクライアント端末（のユーザ）に、サービスを提供するのに用いられる特定のアプリケーションプログラム（特定アプリケーション）である。アプリケーション１３０は、サーバ１０の主メモリ１２にロードされて（読み込まれて）実行される。
【００１５】
外部記憶装置１３にはまた、アプリケーション１３０のクラスタ化の可能性の判定を支援するのに用いられるアプリケーションクラスタ化可能性判定支援プログラム１３１も格納されている。プログラム１３１は、サーバ１０の主メモリ１２にロードされて実行される。
【００１６】
図２は、図１に示されるサーバ１０の主として機能構成を示すブロック図である。  
サーバ１０は、図２に示されるように、システムライブラリ機構２１及びフックライブラリ機構２２を含む。
【００１７】
システムライブラリ機構２１は、システムライブラリ記憶部２１１及びアプリケーションプログラムインタフェース提供機構（ＡＰＩ提供機構）２１２から構成される。システムライブラリ機構２１は、サーバ１０の例えば図示せぬオペレーティングシステム（ＯＳ）に設けられる。
【００１８】
システムライブラリ記憶部２１１は、システムコールのような標準的な呼び出し（関数呼び出し）に応じて呼び出し元に関数（アプリケーションプログラムインタフェース：ＡＰＩ）を提供するのに用いられるシステムライブラリを格納する。システムライブラリは、上記呼び出しによって外部から参照可能な各種の関数（システム関数またはシステムライフライブラリ関数）の集合である。システムライブラリ記憶部２１１は、例えば図１に示される外部記憶装置１３の記憶領域の一部を用いて実現される。
【００１９】
ＡＰＩ提供機構２１２は、アプリケーション１３０または後述するフック機構２３からの関数（ＡＰＩ）呼び出しに応じて、システムライブラリ記憶部２１１に格納されているシステムライブラリの中から指定された関数（ＡＰＩ）を呼び出す。ＡＰＩ提供機構２１２は、呼び出された関数（ＡＰＩ）を呼び出し元に提供する。
【００２０】
フックライブラリ機構２２は、フックライブラリ記憶部２２１、フック機構２２２、アクセス管理テーブル２２３、アクセス管理機構２２４、状態判定機構２２５及び状態通知機構２２６から構成される。
【００２１】
フックライブラリ記憶部２２１は、フックライブラリを格納する。フックライブラリは、システムライブラリを構成するシステム関数の集合のうち、例えばサーバ１０に固有の情報（サーバ固有情報）毎に用意される、当該サーバ固有情報へのアクセスに用いられるシステム関数（ＡＰＩ）の集合に対応させて予め用意されるフック関数の集合である。フックライブラリに含まれる各フック関数（第２の関数）は、当該フック関数に対応するシステム関数（第１の関数）の関数名と対応付けて、フックライブラリ記憶部２２１に格納されている。フックライブラリ記憶部２２１は、例えば図１に示される外部記憶装置１３の記憶領域の一部を用いて実現される。なお、ライブラリ参照の高速化のために、外部記憶装置１３（システムライブラリ記憶部２１１及びフックライブラリ記憶部２２１）に格納されているシステムライブラリ及びフックライブラリが、サーバ１０の起動時に当該外部記憶装置１３から主メモリ１２の所定領域にロードされる構成であっても構わない。
【００２２】
フック機構２２２は、アプリケーション１３０からの関数（第１の関数）の呼び出し（コール）をフック（横取り）する。フック機構２２２は、自身がフックした関数呼び出しで指定される関数名のシステム関数と対応付けられているフック関数を呼び出して、アクセス管理機構２２４、状態判定機構２２５及び状態通知機構２２６と共に、当該フック関数に固有の処理を行う。
【００２３】
フック関数に固有の処理は、第１乃至第５の処理に大別される。第１の処理は、フック機構２２２がフックした関数呼び出しで指定されるシステム関数をシステムライブラリ機構２１から呼び出すための処理である。第２の処理は、呼び出されたシステム関数の処理結果（返り値）をアプリケーション１３０に返すための処理である。フック機構２２２は、この第１及び第２の処理を実行する。
【００２４】
アクセス管理テーブル２２３は、予め定められたサーバ固有情報毎に、当該固有情報へのアプリケーション１３０からのアクセス（参照）を管理するのに用いられる。ここでは、ホストＩＤ（ＨｏｓｔＩＤ）、ＭＡＣアドレス、サーバシリアル番号のような、サーバ１０が持つ（サーバ１０に割り当てられる）、当該サーバ１０に固有のサーバ固有情報が、アクセス管理テーブル２２３によって管理される。アクセス管理テーブル２２３は、例えば、図１に示される主メモリ１２の記憶領域の一部を用いて実現される。各サーバ固有情報にアクセスするためのシステム関数（ＡＰＩ）は予め定められている。
【００２５】
図３は、図２に示されるアクセス管理テーブル２２３のデータ構造例を示す。  
アクセス管理テーブル２２３は、予め定められたサーバ固有情報毎に当該固有情報へのアクセス回数を保持するためのエントリの群から構成される。アクセス管理テーブル２２３の各エントリは、サーバ固有情報及びアクセス回数（当該固有情報へのアクセス回数）を保持するための欄（サーバ固有情報欄及びアクセス回数欄）を含む。つまり、アクセス管理テーブル２２３は、予め定められたサーバ固有情報の各々に対応付けて、当該固有情報へのアクセス回数を保持する。
【００２６】
再び図２を参照すると、アクセス管理機構２２４は、フック機構２２２によってフックされた関数呼び出しに応じて関数（ＡＰＩ）が呼び出されて、呼び出された関数（ＡＰＩ）の実行によってサーバ１０の固有情報（サーバ固有情報）２３がアクセス（参照）される際に第３の処理を実行する。第３の処理は、アクセス管理テーブル２２３内で当該固有情報２３に対応付けられているアクセス回数（参照回数）を１インクリメントするための処理である。ここで、サーバ固有情報２３は外部記憶装置１３に格納されているものとする。
【００２７】
状態判定機構２２５は、アクセス管理テーブル２２３に保持されているサーバ固有情報毎のアクセス回数を監視することによって、当該アクセス回数が閾値を超えたかを判定するための処理（第４の処理）を実行する。状態通知機構２２６は、アプリケーション１３０からのサーバ固有情報へのアクセスの状況を示す情報（アクセス状況情報）を生成して、当該生成された情報をユーザに通知するための処理（第５の処理）を実行する。本実施形態では状態通知機構２２６は、アクセス状況情報として、状態判定機構２２５によって閾値を超えたと判定されたアクセス回数と対応付けられているサーバ固有情報が、ユーザ（例えばシステム管理者）に通知される。
【００２８】
次に、本実施形態の動作について、サーバ１０上で動作しているアプリケーション１３０からシステム関数ｆｕｎ１（）の呼び出し（コール）が行われた場合を例に、図４のフローチャートを参照して説明する。
【００２９】
サーバ１０上で動作するアプリケーション１３０は、従来であれば、システムライブラリ機構２１（のシステムライブラリ記憶部２１１に格納されているシステムライブラリ）を当該アプリケーション１３０自身にリンクすることにより、システムコールを実行する。これに対して本実施形態では、アプリケーション１３０とシステムライブラリ機構２１との間に、フックライブラリ機構２２が論理的に配置される。
【００３０】
今、アプリケーション１３０からシステム関数（ＡＰＩ）ｆｕｎ１（）の呼び出しが行われたものとする（ステップＳ１）。するとフックライブラリ機構２２のフック機構２２２は、以下に述べるように、フックライブラリ記憶部２２１に格納されているフックライブラリに基づき、当該ｆｕｎ１（）の呼び出しをフックする（ステップＳ２）。
【００３１】
システム関数ｆｕｎ１（）は、サーバ１０に固有の情報（サーバ固有情報）２３にアクセスするためのＡＰＩ（アプリケーションプログラムインタフェース）であるものとする。このサーバ固有情報２３が例えばホストＩＤの場合、システム関数ｆｕｎ１（）は、ｇｅｔｈｏｓｔｉｄ（）というＡＰＩである。
【００３２】
システム関数ｆｕｎ１（）の呼び出しは、当該ｆｕｎ１（）の関数名と引数とを含む。フックライブラリ記憶部２２１に格納されているフックライブラリには、このｆｕｎ１（）の関数名に対応付けて、フック関数ＦＵＮ１（）が設定されているものとする。この場合、フック機構２２２は、アプリケーション１３０からのｆｕｎ１（）の呼び出しをフックする。これによりフックライブラリ機構２２は、アプリケーション１３０がシステムライブラリ機構２１を当該アプリケーション１３０自身にリンクするのを抑止する。このような関数呼び出しをフックする動作は、前記特許文献１に記載されているようなライブラリフック技術を用いて実現される。
【００３３】
なお、フックライブラリに、ｆｕｎ１（）の関数名に対応付けてフック関数が格納されていないならば、フック機構２２２は、当該ｆｕｎ１（）の呼び出しをフックしない。この場合、ｆｕｎ１（）の呼び出しは、システムライブラリ機構２１のＡＰＩ提供機構２１２に入力される。
【００３４】
フック機構２２２は、システム関数ｆｕｎ１（）の呼び出しをフックすると（ステップＳ２）、フックされたｆｕｎ１（）の関数名に対応付けてフックライブラリに設定されているフック関数ＦＵＮ１（）を呼び出す（ステップＳ３）。つまり、アプリケーション１３０からのｆｕｎ１（）の呼び出しに対して、システムライブラリ記憶部２１１に格納されているシステムライブラリからシステム関数ｆｕｎ１（）が呼び出される代わりに、フックライブラリ記憶部２２１に格納されているフックライブラリからフック関数ＦＵＮ１（）が呼び出される。
【００３５】
ｆｕｎ１（）が、ｇｅｔｈｏｓｔｉｄ（）というＡＰＩ（システム関数）の場合、フックライブラリに用意されるフック関数（フックライブラリ関数）ＦＵＮ１（）には、例えばＧＥＴＨＯＳＴＩＤ（）が用いられる。
【００３６】
フック機構２２２によってフック関数ＦＵＮ１（）（例えばＧＥＴＨＯＳＴＩＤ（））が呼び出されると、フックライブラリ機構２２では、当該フック関数ＦＵＮ１（）に従い、当該フック関数ＦＵＮ１（）に固有の処理が、フック機構２２２、アクセス管理機構２２４、状態判定機構２２５及び状態通知機構２２６によって次のように実行される。
【００３７】
まずフック機構２２２は、自身がフックした関数呼び出しで指定される関数名のシステム関数ｆｕｎ１（）の実行によってアクセスされるべきサーバ固有情報２３をアクセス管理機構２２４に通知する。ここで、システム関数ｆｕｎ１（）の実行によってアクセスされるべきサーバ固有情報２３は予め定められていることに注意する。そこで、フックライブラリに、ｆｕｎ１（）の関数名に対応付けて、フック関数ＦＵＮ１（）だけでなくサーバ固有情報２３も設定される構成としてもよい。
【００３８】
アクセス管理機構２２４は、通知されたサーバ固有情報２３に基づき、当該固有情報２３に対応付けてアクセス管理テーブル２２３に保持されているアクセス回数を１だけカウントアップ（インクリメント）する（ステップＳ４）。したがって、ｆｕｎ１（）が上記ｇｅｔｏｈｏｔｉｄ（）であるならば、アクセス管理テーブル２２３において、ホストＩＤに対応付けて保持されているアクセス回数が１カウントアップされる。
【００３９】
このように本実施形態においては、サーバ固有情報へのアクセスはユーザの関与しないアプリケーション１３０で行われるにも拘わらずに、つまり隠れたサーバ固有情報へのアクセスであるにも拘わらずに、当該隠れたサーバ固有情報へのアクセスをアクセス管理テーブル２２３に記録することができる。
【００４０】
状態判定機構２２５は、アクセス管理機構２２４によってカウントアップされたアクセス回数（カウント値）が、予め定められた閾値を超えているかを判定する（ステップＳ５）。
【００４１】
もし、カウントアップ後のアクセス回数が閾値を超えていないならば（ステップＳ５がＮＯ）、直ちにフック機構２２２に制御が戻される。するとフック機構２２２は、自身がフックしたｆｕｎ１（）の呼び出しを、アプリケーション１３０に代わって行う（ステップＳ６）。このフック機構２２２からのｆｕｎ１（）の呼び出しに応じて、システムライブラリ機構２１のＡＰＩ提供機構２１２は、システムライブラリ記憶部２１１に格納されているシステムライブラリから、当該ｆｕｎ１（）を呼び出して実行する（ステップＳ７）。このように、フック機構２２２がフックしたｆｕｎ１（）の呼び出しが当該フック機構２２２によって行われることで、従来におけるアプリケーション１３０からのｆｕｎ１（）の呼び出し時と同様に、当該ｆｕｎ１（）がシステムライブラリ機構２１のＡＰＩ提供機構２１２によって実行される。これにより、サーバ固有情報２３へのアクセス（サーバ固有情報２３の参照）が行われる（ステップＳ８）。
【００４２】
ＡＰＩ提供機構２１２は、フック機構２２２によって呼び出されたｆｕｎ１（）の実行結果、つまりサーバ固有情報２３へのアクセスの結果を、返り値として呼び出し元のフック機構２２２に返す。フック機構２２２は、ＡＰＩ提供機構２１２から返された返り値（サーバ固有情報２３）を、アプリケーション１３０に返す。このように本実施形態では、アプリケーション１３０からのｆｕｎ１（）の呼び出しに応じて当該ｆｕｎ１（）が実行された結果が、ｆｕｎ１（）の呼び出しに対する返り値（サーバ固有情報２３）として、フックライブラリ機構２２（のフックライブラリ機構２２）を介してアプリケーション１３０に返される（ステップＳ９）。
【００４３】
アプリケーション１３０は、システムライブラリ機構２１（内のＡＰＩ提供機構２１２）からフックライブラリ機構２２（内のフック機構２２２）を介して返される返り値（サーバ固有情報２３）を、当該アプリケーション１３０自身が行ったｆｕｎ１（）の呼び出しに対する返り値（サーバ固有情報２３）として受け取る。これによりアプリケーション１３０は、フックライブラリ機構２２（内のフック機構２２２）の動作に影響されずに、受け取った返り値（サーバ固有情報２３）を利用した処理を行うことができる。つまり本実施形態においては、フックライブラリ機構２２の動作がアプリケーション１３０の動作に何ら影響を及ぼすことはない。
【００４４】
以上の動作は、アプリケーション１３０によりシステム関数の呼び出しが行われる都度実行される。やがて、アプリケーション１３０からのｆｕｎ１（）の呼び出しが何回か行われた結果、サーバ固有情報２３に対応付けてアクセス管理テーブル２２３に保持されているアクセス回数が閾値を超えたものとする。この場合、状態判定機構２２５はステップＳ５においてＹＥＳを判定して、状態通知機構２２６に制御を渡す。
【００４５】
すると状態通知機構２２６は、サーバ固有情報２３へのアクセス回数が閾値を超えたことを示す情報を生成し、当該生成された情報をアプリケーション１３０からのサーバ固有情報へのアクセスの状況を示す情報として、例えば電子メールによりユーザ（システム管理者）に通知する（ステップＳ１０）。ユーザは、この通知から、現在実行中のアプリケーション１３０はクラスタ化への影響の可能性が大きい、つまりアプリケーション１３０の障害または当該アプリケーション１３０を実行しているサーバ１０の障害が発生した場合に、当該アプリケーション１３０の実行によってユーザに提供されるサービスを継続することは難しいと判断できる。
【００４６】
状態通知機構２２６は上記の通知を行うと、フック機構２２２に制御を戻す。これにより、カウントアップ後のアクセス回数が閾値を超えていない場合と同様に、上記ステップＳ６乃至Ｓ９が行われる。
【００４７】
なお、サーバ固有情報２３へのアクセス回数が閾値を超えたことを、状態通知機構２２６からユーザに通知するのに、電子メール以外の通知手段を用いることも可能である。例えば、ユーザがクライアント端末を通して参照可能な特定のファイルに、サーバ固有情報２３へのアクセス回数が閾値を超えたことを示す情報を状態通知機構２２６が書き込むようにしても構わない。
【００４８】
また、状態判定機構２２５は必ずしも必要でない。ここで、フックライブラリ機構２２のアクセス管理機構２２４は、例えば、アプリケーション１３０の実行期間に亘って、或いは当該アプリケーション１３０の例えば起動時から一定期間、当該アプリケーション１３０によるサーバ固有情報アクセスの回数をアクセス管理テーブル２２３に記録するものとする。この場合、状態通知機構２２６は上記の期間後に、アクセス管理テーブル２２３の内容を、アプリケーション１３０からのサーバ固有情報へのアクセスの状況を示す情報として、ユーザ（システム管理者）に通知すればよい。また上記の期間後に、状態通知機構２２６が状態判定機構２２５と連携することにより、アクセス回数が１以上のエントリ情報をアクセス管理テーブル２２３から選択してユーザに通知してもよい。ユーザは、状態通知機構２２６からの通知に基づき、現在実行中のアプリケーション１３０が、クラスタ化に影響する可能性のあるサーバ固有情報への隠れたアクセスを行うかを判断する。当然、アクセス回数が多いほど、アプリケーション１３０のクラスタ化への影響の可能性が大きくなる。
【００４９】
また、アクセス管理テーブル２２３の各エントリに、サーバ固有情報へアクセスするためのシステム関数の関数名を保持するのに用いられる関数名欄を追加してもよい。つまりアクセス管理テーブル２２３が、予め定められたサーバ固有情報及び当該固有情報へアクセスするためのシステム関数の関数名の対にそれぞれ対応付けて、当該固有情報へのアクセス回数を保持するものであっても構わない。この場合、フック機構２２２は、自身がフックした関数呼び出しで指定される関数名をアクセス管理機構２２４に通知すればよい。アクセス管理機構２２４は、通知された関数名に基づき、当該関数名に対応付けてアクセス管理テーブル２２３に保持されているアクセス回数をカウントアップすることができる。
【００５０】
［第１の変形例］
次に、上記実施形態の第１の変形例について、図１を援用して説明する。
【００５１】
まず、上記実施形態の特徴は、サーバ固有情報へのアクセス回数が多いほど、アプリケーション１３０のクラスタ化への影響の可能性が大きくなることに着目して、そのような状態を状態通知機構２２６によってユーザに通知することにある。これに対し、第１の変形例の特徴は、アプリケーション１３０を実行するサーバの切り替え時（つまりフェイルオーバ時）に、サーバ固有情報も変更されることに着目して、当該固有情報の変更がアプリケーション１３０に影響を与えるかを、サーバの切り替えを行うことなく、サーバ１０単体で検証するようにしたことにある。つまり第１の変形例の特徴は、フェイルオーバ時のシミュレーションを稼動系のサーバ１０単体で行うようにしたことにある。
【００５２】
図５は、第１の変形例で適用されるサーバ１０の主として機能構成を示すブロック図である。図５において、図２と等価な要素には同一参照符号を付してある。
【００５３】
図５に示すサーバ１０では、上記実施形態と異なり、フックライブラリ機構２２に代えてフックライブラリ機構２２ａが用いられる。フックライブラリ機構２２ａは、フックライブラリ記憶部２２１、フック機構２２２、アクセス管理テーブル２２３ａ、アクセス管理機構２２４、状態判定機構２２５、状態通知機構２２６及び固有情報置換機構２２７から構成される。つまりフックライブラリ機構２２ａは、図２に示されるフックライブラリ機構２２に固有情報置換機構２２７を追加すると共に、図２に示されるアクセス管理テーブル２２３に代えてアクセス管理テーブル２２３ａを用いたものである。なお、状態判定機構２２５及び状態通知機構２２６の機能は、後述するように上記実施形態と異なる。
【００５４】
固有情報置換機構２２７は、アプリケーション１３０からのサーバ固有情報アクセスのためのシステム関数ｆｕｎ１（）の呼び出しに応じて当該アプリケーション１３０に返されるべき返り値（サーバ固有情報２３）を、予め定められたダミーの固有情報（ダミー情報）に置き換える。
【００５５】
図６は、アクセス管理テーブル２２３ａのデータ構造例を示す。アクセス管理テーブル２２３ａの各エントリは、サーバ固有情報欄及びアクセス回数欄に加えて、アプリケーション１３０の状態を保持するための第１及び第２の状態欄を含む。第１の状態欄は、サーバ固有情報２３がダミー情報に置き換えられずにアプリケーション１３０に返された場合の当該アプリケーション１３０の状態を保持するのに用いられる。第２の状態欄は、サーバ固有情報２３に代えてダミー情報がアプリケーション１３０に返された場合の当該アプリケーション１３０の状態を保持するのに用いられる。
【００５６】
クラスタシステムにおいてフェイルオーバが発生した場合、上述のようにサーバ固有情報も変更される。このサーバ固有情報の変更がアプリケーション１３０に影響を与えるかは、実際にフェイルオーバを発生することにより確認できる。しかし、そのためには、実際に複数のサーバを用いてクラスタシステムを構築する必要がある。
【００５７】
そこで、フェイルオーバの発生を想定して、アプリケーション１３０を単一のサーバ１０で再起動すると共に、当該アプリケーション１３０がアクセスするサーバ固有情報（サーバ１０に固有の情報）を変更することによって、当該アプリケーション１３０の動作を確認する手法を適用することが考えられる。しかし、アプリケーション１３０がアクセスするサーバ固有情報自体を変更した場合、当該アプリケーション１３０（つまり動作確認の対象となるアプリケーション１３０）以外にも影響を与える可能性がある。このため、上記の手法を安易に実施できない。
【００５８】
一方、上記実施形態では、アプリケーション１３０の動作時に、当該アプリケーション１３０からのシステム関数ｆｕｎ１（）の呼び出しが、フックライブラリ機構２２のフック機構２２２によってフックされる。このフックされた呼び出しに基づいて、システムライブラリからシステム関数ｆｕｎ１（）が実際に呼び出されて当該システム関数ｆｕｎ１（）が実行されることにより、サーバ１０に固有の情報（サーバ固有情報２３）がアクセスされる。このアクセスされるサーバ固有情報２３は予め定められている。したがって上記実施形態においては、アプリケーション１３０からのシステム関数ｆｕｎ１（）の呼び出しが、フックライブラリ機構２２のフック機構２２２によってフックされることにより、その時点で、アプリケーション１３０がアクセスしようとするサーバ固有情報２３を認識（特定）することが可能である。またサーバ固有情報２３の値自体はＯＳの機能によりアプリケーション１３０とは独立に確認できる。
【００５９】
そこで第１の変形例では、この特徴を利用することにより、サーバ固有情報の変更がアプリケーション１３０に影響を与えるかを、サーバ１０単体で検証する仕組みを実現している。具体的には、フックライブラリとリンクするアプリケーション１３０が、サーバ固有情報へアクセスするためのシステム関数の呼び出しによって当該固有情報を参照するときだけ、当該固有情報をダミー情報（ダミーの固有情報）で置き換えることにより、上記の仕組みを実現している。この仕組みによれば、例えばサーバ固有情報をダミー情報で置き換えた場合のサーバ１０の状態から、当該サーバ１０を含む複数のサーバを用いてクラスタシステムを構築することなく、また当該サーバ１０上の他のアプリケーションに影響を与えることなく、アプリケーション（特定のアプリケーション）１３０がサーバ固有情報に大きく依存するか、つまりアプリケーション１３０のクラスタ化への影響の可能性が大きいかを確認することができる。
【００６０】
サーバ固有情報の変更がアプリケーションに影響を与える場合の当該アプリケーションの挙動は、アプリケーション毎に異なる。例えば、サーバ固有情報の変更により、アプリケーション１３０の起動自体が行えない状態、或いはアプリケーション１３０におけるサーバ固有情報アクセスのエラー、或いはアプリケーション１３０自身の動作エラーが発生する可能性がある。このようなアプリケーション１３０では、サーバ固有情報の変更前の当該アプリケーション１３０の状態をサーバ固有情報の変更後の当該アプリケーション１３０の状態と比較することにより、サーバ固有情報の変更が当該アプリケーション１３０に与える影響度を判断することが可能である。
【００６１】
以下、第１の変形例の動作について、図７のフローチャートを参照して説明する。なお、図７において、図３のフローチャートと等価な処理ステップには同一参照符号を付してある。
【００６２】
まず、アプリケーション１３０からシステム関数ｆｕｎ１（）の呼び出しが行われたものとする（ステップＳ１）。この場合、フックライブラリ機構２２のフック機構２２２は、上記実施形態と同様に、フックライブラリに基づき、当該ｆｕｎ１（）の呼び出しをフックする（ステップＳ２）。次にフックライブラリ機構２２は、フックされたｆｕｎ１（）の関数名に対応付けてフックライブラリに設定されているフック関数ＦＵＮ１（）を呼び出す（ステップＳ３）。するとアクセス管理機構２２４は、システム関数ｆｕｎ１（）の実行によってアクセスされるべきサーバ固有情報２３に対応付けてアクセス管理テーブル２２３に保持されているアクセス回数を１だけカウントアップする（ステップＳ４）。
【００６３】
次に状態判定機構２２５が起動される。状態判定機構２２５は、フック機構２２２によってフックされたｆｕｎ１（）の呼び出しに基づいて、当該ｆｕｎ１（）が実行されることによってアクセスされるべきサーバ固有情報２３を、ダミーの固有情報（ダミー情報）で置き換えるかを判定する（ステップＳ１１）。この判定は、例えば、アクセス管理機構２２４によってカウントアップされたアクセス回数（カウント値）が１を超えているかに基づいて行われる。
【００６４】
もし、アクセス回数が１であるならば、つまり１を超えていないならば、状態判定機構２２５は、ダミー情報への置き換え（ダミー情報での応答）は不要であると判定する（ステップＳ１１がＮＯ）。この場合、フック機構２２２は、自身がフックしたｆｕｎ１（）の呼び出しを行う（ステップＳ６）。以降の動作は上記実施形態と同様であり、システムライブラリからｆｕｎ１（）が呼び出されて、当該ｆｕｎ１（）の実行によりサーバ固有情報２３がアクセスされる（ステップＳ６乃至Ｓ８）。そして、アクセスされたサーバ固有情報２３が、ｆｕｎ１（）の呼び出しに対する返り値として、フックライブラリ機構２２（のフックライブラリ機構２２）を介してアプリケーション１３０に返される（ステップＳ９）。すると状態判定機構２２５は、サーバ固有情報２３が返されたアプリケーション１３０の状態を採取して、採取された状態を示す情報（第１の状態情報）を、当該固有情報２３が保持されているアクセス管理テーブル２２３ａのエントリの第１の状態欄に設定する（ステップＳ１２，Ｓ１３）。なお、アプリケーション１３０の状態を採取する手法自体は従来から知られているため説明を省略する。
【００６５】
これに対してアクセス回数が１を超えているならば、状態判定機構２２５は、ダミー情報への置き換えが必要であると判定する（ステップＳ１１がＹＥＳ）。この場合、状態判定機構２２５は固有情報置換機構２２７を起動する。
【００６６】
すると固有情報置換機構２２７は、予め定められたダミー情報（ダミーの固有情報）をｆｕｎ１（）の呼び出しに対する返り値としてフック機構２２２に渡す（ステップＳ１４）。このことは、アプリケーション１３０からのｆｕｎ１（）の呼び出しに応じて、当該ｆｕｎ１（）が実際に実行されることによってアクセスされてアプリケーション１３０に返されるサーバ固有情報２３を、ダミー情報に置き換える（変更する）のと等価である。
【００６７】
フック機構２２２は、固有情報置換機構２２７から渡されたダミー情報を、アプリケーション１３０からのｆｕｎ１（）の呼び出しに対応する返り値として、当該アプリケーション１３０に渡す。すると状態判定機構２２５は、ダミー情報が返されたアプリケーション１３０の状態を採取して、採取された状態を示す情報（第２の状態情報）を、当該サーバ固有情報２３が保持されているアクセス管理テーブル２２３ａのエントリの第２の状態欄に設定する（ステップＳ１５，Ｓ１６）。
【００６８】
次に状態判定機構２２５は、第２の状態欄に設定された第２の状態情報を、当該第２の状態欄を含むアクセス管理テーブル２２３ａのエントリの第１の状態欄に設定されている第１の状態情報と比較することにより、ダミー情報（つまりサーバ固有情報の変更）がアプリケーション１３０の挙動に影響を及ぼしたかを判断する（ステップＳ１７，Ｓ１８）。状態通知機構２２６は、この状態判定機構２２５の判断結果を、上記実施形態と同様の手法によりユーザに通知する（ステップＳ１９）。
【００６９】
なお、フェイルオーバを想定したダミー情報への変更によりアプリケーション１３０の起動自体が行えない場合を確認可能とするために、当該アプリケーション１３０を一旦起動した後に、当該アプリケーション１３０を再起動してもよい。ここでは、アプリケーション１３０の最初の起動時には、ダミー情報への変更を行わず、当該アプリケーション１３０が停止された後に当該アプリケーション１３０が再度起動された際に、つまり当該アプリケーション１３０の再起動時に、１回目のアクセスでダミー情報への変更を行えばよい。これにより、ダミー情報への変更がアプリケーション１３０の起動に与える影響、つまりフェイルオーバの発生により当該アプリケーション１３０を実行するサーバが切り替えられる場合に当該アプリケーション１３０の起動に与える影響を調べることが可能である。
【００７０】
上記第１の変形例では、隠れたサーバ固有情報使用に対するアプリケーション１３０のクラスタ化への影響を確認するために、当該アプリケーション１３０からのサーバ固有情報アクセスためのシステム関数呼び出しをフックライブラリ機構２２ａでフックし、当該アプリケーション１３０が参照すべきサーバ固有情報をダミー情報（ダミーの固有情報）で置き換えるようにしている。もし、予め影響のあるサーバ固有情報の利用が確認できている場合、上述の固有情報置き換えの仕組みを利用して常にダミー情報を使うことにすれば、サーバ変更によるサーバ固有情報の変化を隠蔽してアプリケーション１３０の運用が可能となる。この理由は次の通りである。
【００７１】
まず、複数のサーバ、例えば２台のサーバ＃１及び＃２から構成されるクラスタシステムを想定する。サーバ＃１及び＃２の各々の構成は、上記第１の変形例におけるサーバ１０のそれと同様である。サーバ＃１及び＃２の固有のサーバ固有情報がそれぞれＡびＢであるとし、ダミー情報がＣであるものとする。
【００７２】
この場合、上述のアプリケーション１３０がサーバ＃１または＃２で動作してサーバ固有情報を参照する際に、フックライブラリ機構２２によって当該アプリケーション１３０にダミー情報Ｃが返される。これによりアプリケーション１３０は、サーバ＃１または＃２のいずれで動作する場合にも、ダミー情報Ｃを用いて動作することになる。よって、サーバ変更によるサーバ固有情報の変化が隠蔽される。
【００７３】
［第２の変形例］
次に、上記実施形態の第２の変形例について、図１及び図５を援用して説明する。  
第２の変形例の特徴は、アプリケーション１３０からのサーバ固有情報アクセスを含む特定のアクセスパターンをフックライブラリ機構２２ａにおいて検出する点にある。
【００７４】
まず、アプリケーション１３０の起動時の一般的なチェック動作として、当該アプリケーション１３０が動作するサーバ１０に固有のホストＩＤを参照することによって、当該サーバ１０を識別することが挙げられる。このアプリケーション１３０の起動時の動作は、通常、次のような手順で行われる。
【００７５】
(1) アプリケーション１３０を起動する。  
(2) システム関数ｇｅｔｈｏｓｔｉｄ（）を呼び出すことにより、アプリケーション１３０に固有の情報であるホストＩＤを読み出す。
【００７６】
(3) ｒｅａｄ関数ｒｅａｄ（ｆｄ，ｄａｔａ）を呼び出すことにより、アプリケーション１３０の設定データ（設定ファイルのデータ）の中から記録済みのホストＩＤを読み出す。ここで上記ｒｅａｄ関数におけるｆｄ及びｄａｔａは引数であり、それぞれ、読み出されるべきデータ（ホストＩＤ）の位置（つまり読み出し先）、読み出されたデータが格納されるべき位置（つまり読み出しデータの格納先）を示す。この場合、“ｆｄ”に記録されているデータ（ホストＩＤ）が読み出されて“ｄａｔａ”に格納される。
【００７７】
(4) ｇｅｔｈｏｓｔｉｄ（）の呼び出しによって読み出されたホストＩＤをｒｅａｄ（ｆｄ，ｄａｔａ）の呼び出しによって読み出されたデータと比較する。  
(5) 上記の比較の結果、両データが一致しているならば、アプリケーション１３０は正常なサーバで起動されたと（つまりアプリケーション１３０の正常起動が）判定される。これに対し、両データが一致していないならば、アプリケーション１３０は不正なサーバで起動されたと判定されて、アプリケーション１３０の起動失敗となる。
【００７８】
さて、第２の変形例では、ｒｅａｄ関数ｒｅａｄ（ｆｄ，ｄａｔａ）、システム関数ｇｅｔｈｏｓｔｉｄ（）、及びｗｒｉｔｅ関数ｗｒｉｔｅ（ｆｄ，ｄａｔａ）の各々の呼び出しを、フックライブラリ機構２２ａのフック機構２２２によるフック対象とするためのフックライブラリが、フックライブラリ機構２２ａのフックライブラリ記憶部２２１に予め格納されている。ｗｒｉｔｅ関数におけるｆｄは引数であり、データが書き込まれる（記録される）べき、例えば上記設定ファイル内の位置（つまり、データの書き出し先）を示し、ｄａｔａは当該データが格納されている位置（つまりデータの格納元）を示す。
【００７９】
フックライブラリ記憶部２２１の状態判定機構２２５は、フック機構２２２によってｒｅａｄ（ｆｄ，ｄａｔａ）がフックされた場合、ｄａｔａで指定される格納先に、ｇｅｔｈｏｓｔｉｄ（）の呼び出しによってシステムライブラリ機構２１のＡＰＩ提供機構２１２から返される返り値（ホストＩＤ）に一致するホストＩＤがあるかを判定する。状態判定機構２２５はまた、フック機構２２２によってｗｒｉｔｅ（ｆｄ，ｄａｔａ）がフックされた場合には、ｆｄで指定される書き出し先に、ｇｅｔｈｏｓｔｉｄ（）の呼び出しによってＡＰＩ提供機構２１２から返される返り値（ホストＩＤ）に一致するホストＩＤがあるかを判定する。
【００８０】
状態判定機構２２５は、これらの判定結果から、特定条件が成立するかを判定する。特定条件とは、ｇｅｔｈｏｓｔｉｄ（）及びｒｅａｄがそれぞれ呼び出されて当該両関数の実行により同一のホストＩＤが読み出され、加えてｇｅｔｈｏｓｔｉｄ（）とｒｅａｄとの間でｗｒｉｔｅが呼び出され、且つ当該ｗｒｉｔｅの示す、ｒｅａｄの場合と同一の書き出し先（ｆｄ）にホストＩＤが含まれていない特定のアクセスパターンのことである。
【００８１】
固有情報置換機構２２７は、状態判定機構２２５によって上記特定条件の成立が判定され、且つ、アプリケーション１３０が再起動されて当該アプリケーション１３０からのｇｅｔｈｏｓｔｉｄ（）の呼び出しがフック機構２２２によってフックされた場合、ダミー情報をフック機構２２２に渡す。即ち前記固有情報置換機構２２７は、ｇｅｔｈｏｓｔｉｄ（）の呼び出しに対する返り値として、ダミー情報（例えば、予めアプリケーション１３０が認識しているホストＩＤとは異なるホストＩＤ）をフック機構２２２に渡す。フック機構２２２は、固有情報置換機構２２７から渡されたダミー情報を、ｇｅｔｈｏｓｔｉｄ（）の呼び出しに対する返り値としてアプリケーション１３０に返す。状態判定機構２２５は、上記第１の変形例と同様にして、ダミー情報がアプリケーション１３０の挙動に影響を及ぼしたかを、当該アプリケーション１３０の起動に失敗したかによって判断する。
【００８２】
明らかなように、アプリケーション１３０からのアクセスのパターンが上記アプリケーション１３０の起動時のチェック動作のそれに一致する場合、上記特定条件は不成立となる。この場合、固有情報置換機構２２７によるダミー情報への置き換えは行われない。その理由は、もし、ダミー情報への置き換えを行っても、ｗｒｉｔｅ関数によってｆｄにダミー情報が書き込まれ、そのｆｄに書き込まれたダミー情報がｒｅａｄ関数によって読み出される可能性があるためである。つまり、ダミー情報への置き換えが、フェイルオーバの発生を想定した単一サーバ１０でのシミュレーションとならないためである。
【００８３】
なお、アプリケーション１３０によっては、上記 (2) 及び (3) の順番、つまりｇｅｔｈｏｓｔｉｄ及びｒｅａｄの順番が逆である可能性もある。もし、上述の例のようにｇｅｔｈｏｓｔｉｄが先の場合、ｇｅｔｈｏｓｔｉｄの実行時に読み出しデータを監視対象として、フックライブラリ機構２２の例えば状態判定機構２２５内に記録するとよい。一方、ｒｅａｄが先の場合、ホストＩＤを予め監視（確認）対象として例えば状態判定機構２２５内に登録しておくとよい。
【００８４】
［第３の変形例］
次に、上記実施形態の第３の変形例について、図１及び図５を援用して説明する。  
第３の変形例は、前述のようなアプリケーション１３０の起動時の一般的なチェック動作 (1) 〜 (5) の後にホストＩＤが参照される場合を想定する。更に詳細に述べるならば、第３の変形例は、アプリケーション１３０の扱うデータを暗号化して外部記憶装置１３に記録する場合において、暗号化のキーにサーバ１０に固有な情報、例えばサーバ１０のホストＩＤを利用するものとする。
【００８５】
この場合アプリケーション１３０では、前述のチェック動作 (1) 〜 (5) に続いて、以下の処理が実行されるのが一般的である。  
(6) ホストＩＤの読み出し
(7) 読み出されたホストＩＤをキーとして、任意のデータを暗号化
(8) 暗号化されたデータの外部記憶装置１３への書き込み（記録）
データの書き込みが続く場合、上記 (6) 〜 (7) の処理が繰り返される。
【００８６】
一方、外部記憶装置１３に記録されたデータを読み出す場合、アプリケーション１３０では以下の処理が実行される。  
(9) 外部記憶装置１３からのデータ（暗号化されたデータ）の読み出し
(10) ホストＩＤの読み出し
(11) 読み出されたホストＩＤをキーとして、読み出されたデータの復号化
データの読み出しが続く場合、上記 (9) 〜 (11) の処理が繰り返される。
【００８７】
このように、上記 (6) 〜 (8) 及び(9) 〜 (11) の処理は、それぞれアプリケーション１３０の挙動によって繰り返される。ここでは、これらの処理が繰り返されて、その都度ホストＩＤが読み出されることを想定する。そこでアクセス管理機構２２４は、ｇｅｔｈｏｓｔｉｄによるホストＩＤの読み出しのアクセス回数、ｒｅａｄによるデータの読み出し回数及びｗｒｉｔｅによるデータの書き込み回数をアクセス管理テーブル２２３ａに記録するのに加えて、アクセス順序を図示せぬログテーブルに記録する。なお、アクセス管理テーブル２２３ａのデータ構造は図６と異なっており、アクセス管理テーブル２２３ａの各エントリはサーバ固有情報欄に代えて関数名欄を含むものとする。具体的には、アクセス管理テーブル２２３ａは、関数名欄にｇｅｔｈｏｓｔｉｄ、ｒｅａｄ及びｗｒｉｔｅの関数名がそれぞれ設定されたエントリを含むものとする。
【００８８】
状態判定機構２２５は、アクセス管理テーブル２２３ａ及びログテーブルから、ｇｅｔｈｏｓｔｉｄ及びｒｅａｄ、或いはｇｅｔｈｏｓｔｉｄ及びｗｒｉｔｅの呼び出しによるアクセスが、時間的に近接した状態で繰り返されるかを判定する。この判定には、時間的に近接しているかを判定するための、近接度合いを示す閾値（第１の閾値）と、繰り返されたと判定するための繰り返し数の閾値（第２の閾値）とが用いられる。
【００８９】
ここで、１０００文字のデータをホストＩＤで暗号化して、その暗号化されたデータを外部記憶装置１３へ書き込む動作、または外部記憶装置１３に書き込まれた暗号化されたデータを読み出してホストＩＤで復号化する動作が行われるものとする。更に、データの書き込みまたは読み出し（書き込み／読み出し）の動作が、１０００文字のデータを対象に１回で実行されず、例えば１００文字単位で１０回に分けて実行されるものとする。この場合、最初は、ホストＩＤの読み出し及び１００文字のデータの書き込み、またはホストＩＤの読み出し及び１００文字のデータ読み出しが続けて行われる。このことを前提として、状態判定機構２２５による上述の判定が行われる。
【００９０】
まず、ホストＩＤの読み出しと最初のデータ書き込み／読み出しとが近接している（続いている）かが判定される。その後データ書き込み／読み出しが実行されると、当該データ書き込み／読み出しが同一の“ｆｄ”を対象として繰り返されること、つまり連続（近接）するデータ書き込み／読み出しが観測される。この場合、状態判定機構２２５は、これらのデータ書き込み／読み出しが最初に読み出されたホストＩＤの影響を受けていると判定する。
【００９１】
状態判定機構２２５は、ｇｅｔｈｏｓｔｉｄ及びｒｅａｄの呼び出しによるアクセス、或いはｇｅｔｈｏｓｔｉｄ及びｗｒｉｔｅの呼び出しによるアクセスが時間的に近接した状態で繰り返されると判定できた場合、これらのアクセスに依存性があると推測する。そこでフック機構２２２は、ｇｅｔｈｏｓｔｉｄ及びｗｒｉｔｅの呼び出しによるアクセスが時間的に近接して繰り返される間、予め測定されるアクセスのタイミング、順序に従い、アプリケーション１３０に返されるべきｇｅｔｈｏｓｔｉｄに対する返り値として、真のホストＩＤを用いる。一方、ｇｅｔｈｏｓｔｉｄ及びｒｅａｄの呼び出しによるアクセスが時間的に近接して繰り返される間は、フック機構２２２は予め測定されるアクセスのタイミング、順序に従い、アプリケーション１３０に返されるべきｇｅｔｈｏｓｔｉｄに対する返り値として、ダミー情報を用いる。
【００９２】
すると、ｇｅｔｈｏｓｔｉｄ及びｒｅａｄの呼び出しによるアクセスの繰り返しにおいて、アプリケーション１３０では読み出しデータの復号化に失敗する。この場合、アプリケーション１３０は読み出しエラーを当該アプリケーション１３０の実行履歴を表すログファイルに出力する。状態判定機構２２５は、このログファイルを参照することにより、アプリケーション１３０のクラスタ化が不可であると判断できる。なお、このログファイルを状態通知機構２２６がユーザに通知して、当該ユーザにアプリケーション１３０のクラスタ化が不可であることを判断させても構わない。
【００９３】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【００９４】
【図１】本発明の一実施形態に係るクラスタシステム向けサーバ計算機のハードウェア構成を示すブロック図。
【図２】図１に示されるサーバ計算機の主として機能構成を示すブロック図。
【図３】図２に示されるアクセス管理テーブル２２３のデータ構造例を示す図。
【図４】同実施形態の動作を説明するためのフローチャート。
【図５】同実施形態の第１の変形例で適用されるサーバ計算機の主として機能構成を示すブロック図。
【図６】図５に示されるアクセス管理テーブル２２３ａのデータ構造例を示す図。
【図７】同第１の変形例の動作を説明するためのフローチャート。
【符号の説明】
【００９５】
１０…サーバ（クラスタシステム向けサーバ計算機）、１１…ＣＰＵ、１２…主メモリ、１３…外部記憶装置、２１…システムライブラリ機構、２２…フックライブラリ機構、２３…サーバ固有情報、１３０…アプリケーション（特定アプリケーション）、１３１…アプリケーションクラスタ化可能性判定支援プログラム、２１１…システムライブラリ記憶部、２１２…ＡＰＩ（アプリケーションプログラムインタフェース）提供機構、２２１…フックライブラリ記憶部、２２２…フック機構、２２３，２２３ａ…アクセス管理テーブル、２２４…アクセス管理機構、２２５…状態判定機構、２２６…状態通知機構、２２７…固有情報置換機構。
【図１】
2009289054.tif 000003
【図２】
2009289054.tif 000004
【図３】
2009289054.tif 000005
【図４】
2009289054.tif 000006
【図５】
2009289054.tif 000007
【図６】
2009289054.tif 000008
【図７】
2009289054.tif 000009