(57)【要約】【課題】クラスタシステムにおいて高度で且つ詳細なサービスの制御を実現可能とする。【解決手段】クラスタシステム内のシナリオ管理機構１２に設けられたサービス制御部１２２は、クラスタシステムにより提供されるサービスに関し、サービス関係情報ＤＢ１２１ａに記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御する。サービス制御部１２２は、サービスの開始制御では、サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機のサービス実行機構に対して当該サービスの開始を指示し、当該サービスの停止制御では、当該サービスを開始している計算機のサービス実行機構に対して当該サービスの停止を指示する。【選択図】    図２
2005011237.tif 000002
【特許請求の範囲】
【請求項１】
複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムにおいて、
前記複数種類のサービスのうちの相異なる２種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報を記憶するサービス間関係情報記憶手段と、
前記複数の計算機の各々に設けられ、サービスの開始及び停止を司るサービス実行手段と、
前記クラスタシステムにより提供されるサービスに関し、前記サービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御するサービス制御手段であって、当該サービスの開始制御では、前記サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機の前記サービス実行手段に対して当該サービスの開始を指示し、当該サービスの停止制御では、当該サービスを開始している計算機の前記サービス実行手段に対して当該サービスの停止を指示するサービス制御手段と
を具備することを特徴とするクラスタシステム。
【請求項２】
前記サービス間関係情報はサービス間の関係の種類を示す情報を含み、当該サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であることを特徴とする請求項１記載のクラスタシステム。
【請求項３】
前記サービス間関係情報はサービス間の関係の属性を示す情報を含み、当該サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、前記サービス制御手段による選択の候補となる前記強い関係を満たす選択肢が複数あるときにそれが成立するものが選択される弱い関係とが設定可能であることを特徴とする請求項１記載のクラスタシステム。
【請求項４】
前記サービス間関係情報はサービス間の関係の適用範囲を示す情報を含み、当該サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能であることを特徴とする請求項１記載のクラスタシステム。
【請求項５】
前記複数種類のサービスの各々について当該サービスの許可状態を管理するためのサービス許可状態情報を記憶するサービス許可状態情報記憶手段を更に具備し、
前記サービス制御手段は、前記サービス許可状態情報の示す許可状態に対応して前記サービス間関係情報の示すサービス間の関係が合致するように、開始すべきサービス及び当該開始すべきサービスを開始する計算機、あるいは停止すべきサービス及び当該停止すべきサービスを開始している計算機を選択する自動制御手段を含む
ことを特徴とする請求項１記載のクラスタシステム。
【請求項６】
前記サービス制御手段は、あるサービスの開始または停止が外部から指定された場合に、当該サービスに対応する前記サービス許可状態情報の示す許可状態を許可または不許可にする操作処理手段を含むことを特徴とする請求項５記載のクラスタシステム。
【請求項７】
前記サービス制御手段は、前記サービス実行手段によりサービスが開始された場合に、当該サービスに対応する前記サービス許可状態情報の示す許可状態を不許可にするバッチジョブ制御手段を更に含み、
前記自動制御手段は、前記サービス許可状態情報の示す許可状態が不許可となった場合、当該サービス許可状態情報に対応するサービスの停止制御を行う
ことを特徴とする請求項５記載のクラスタシステム。
【請求項８】
前記サービス間関係情報は、サービス間の関係の種類、サービス間の関係の属性及びサービス間の関係の適用範囲を示す情報を含み、前記サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であり、前記サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、前記自動制御手段による選択の候補となる前記強い関係を満たす計算機が複数存在するときに当該サービス間の関係が成立する計算機が優先的に選択される弱い関係とが設定可能であり、前記サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能であることを特徴とする請求項５記載のクラスタシステム。
【請求項９】
同一のサービス間について、前記サービス間の関係の種類、前記サービス間の関係の属性及び前記サービス間の関係の適用範囲の異なる組み合わせのうち、前記サービス間関係情報記憶手段に同時に設定された場合に論理的に矛盾が生じる、あるいは無意味となる組み合わせを、前記サービス間関係情報記憶手段への設定対象外とすることを特徴とする請求項８記載のクラスタシステム。
【請求項１０】
前記クラスタシステムを構成する計算機の台数はｎ＋ｍ台（ｎは２以上の整数、ｍは１以上の整数）であり、当該ｎ＋ｍ台の計算機のうちのｎ台はそれぞれ固有の種類のサービスを提供する稼働系計算機であり、残りのｍ台は前記ｎ台の稼働系計算機のいずれかの計算機に障害が発生した場合に、当該障害発生計算機で開始されていたサービスを引き継ぐことが可能な待機系計算機であり、
前記サービス間関係情報記憶手段に記憶される、前記ｎ台の稼働系計算機がそれぞれ提供するサービスのうちの相異なる２種類のサービスの組み合わせ毎の全てのサービス間関係情報に、前記サービス間の関係の種類、前記サービス間の関係の属性及び前記サービス間の関係の適用範囲として、それぞれ排他関係、強い関係及び局所的関係が設定されている
ことを特徴とする請求項８記載のクラスタシステム。
【請求項１１】
前記クラスタシステムにより提供されるサービスとして、データに相当する第１のサービス、データをバックアップする第２のサービス及びデータにアクセスする第３のサービスの３種類のサービスが定義されると共に、
前記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、前記第１のサービスに対して前記第２のサービスと前記第３のサービスとから強い依存関係が局所的関係として設定され、前記第２のサービスと前記第３のサービスとの間に強い排他関係が大局的関係として設定されている
ことを特徴とする請求項８記載のクラスタシステム。
【請求項１２】
前記クラスタシステムにより提供されるサービスとして、データに相当する第１のサービス、データをバックアップする第２のサービス及びデータにアクセスする第３のサービスの３種類のサービスが定義されると共に、
前記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、前記第１のサービスに対して前記第２のサービスと前記第３のサービスとから強い依存関係が局所的関係として設定され、前記第３のサービスに対して前記第２のサービスから強い依存関係が大局的関係として設定されている
ことを特徴とする請求項８記載のクラスタシステム。
【請求項１３】
複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステム内の前記計算機でサービスの実行を制御するために実行されるサービス制御プログラムであって、
前記計算機に、
前記クラスタシステムにより提供可能なサービスのうち開始すべきサービスを検出するステップと、
前記複数の計算機の中から、前記検出された開始すべきサービスを提供可能な正常な計算機を順次選択するステップと、
前記計算機が選択される都度、前記複数種類のサービスのうちの相異なる２種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報が記憶されたサービス間関係情報記憶手段を参照することにより、前記選択された計算機で前記検出されたサービスを開始することが、対応する前記サービス間関係情報の示すサービス間関係に合致するかを判定するステップと、
前記サービス間関係に合致すると判定された場合に、前記選択された計算機で前記検出されたサービスを開始させるステップと
を実行させるためのサービス制御プログラム。
【請求項１４】
前記検出ステップでは、外部から開始が指定されたサービス、または障害が発生した計算機で開始されていたサービスが、開始すべきサービスとして検出されることを特徴とする請求項１３記載のサービス制御プログラム。
【請求項１５】
前記計算機に、
前記クラスタシステムにて開始されているサービスのうち停止すべきサービスを検出するステップと、
前記検出された停止すべきサービスを開始している計算機を特定するステップと、
前記特定された計算機で開始されている前記検出された停止すべきサービスを停止させるステップと
を更に実行させるための請求項１３記載のサービス制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムに係り、特に当該システムにおけるサービスの実行を制御するのに好適なクラスタシステム及びサービス制御プログラムに関する。
【０００２】
【従来の技術】
計算機システムの目的として、その計算機システム上でアプリケーションプログラムを実行し、ユーザにサービスを提供することが従来から知られている。近年、サービスの重要性が増すにつれて、サービスが実行される計算機システムに高い可用性が求められるようになっている。
【０００３】
現在、計算機システムの可用性を高めたシステムとして、クラスタシステムが注目を集めている（例えば、非特許文献１参照）。クラスタシステムは、ネットワーク接続された複数台の計算機で構成され、それらの計算機を統一的に管理するためのクラスタシステム管理機構を備えている。クラスタシステム管理機構は、予め定義されたクラスタシステムの設定に従って、サービスの開始処理及び停止処理、並びにサービスの状態監視を制御する。
【０００４】
例えば、ホットスタンバイ型のクラスタシステムでは、クラスタシステム管理機構は、サービスを開始している計算機（稼働系計算機）で発生した障害を検出したときに、引継ぎ先の計算機（待機系計算機）でそのサービスを再開するという制御を行う。このサービスを引き継ぐための制御はフェイルオーバと呼ばれる。このフェイルオーバにより、サービスの提供不能時間が短縮され、クラスタシステムの可用性が高まる。
【０００５】
従来のクラスタシステムでは、複数のサービスを提供する場合に、２台の計算機で構成されるホットスタンバイ型のクラスタシステムを、提供するサービスの数だけ用意する形態がとられている。しかし、この形態では、提供するサービスの数がｎであるとすると、クラスタシステムを構築するのに２×ｎ台の計算機が必要になり、計算機資源が無駄になる。そこで、計算機資源を節約するために、待機系を共通化した、ｎ対１バックアップの形態をとるクラスタシステムも知られている。
【０００６】
【非特許文献１】
金子哲夫、森良哉、「クラスタソフトウェア」、東芝レビュー、Ｖｏｌ．５４  Ｎｏ．１２（１９９９）、ｐ．１８−２１
【０００７】
【発明が解決しようとする課題】
上記したように、複数のサービスを提供する従来のクラスタシステムでは、ホットスタンバイ型のクラスタシステムが提供するサービスの数（ｎ）だけ用意される形態、あるいはｎ対１バックアップの形態がとられている。これらの形態は、単にホットスタンバイ型のクラスタシステムを組み合わせた形態である。このため、ホットスタンバイ型のクラスタシステムと同等なサービスの制御しかできない。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、これによりホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できるクラスタシステム及びサービス制御プログラムを提供することにある。
【０００９】
【課題を解決するための手段】
本発明の１つの観点によれば、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムが提供される。このクラスタシステムは、サービス間関係情報記憶手段と、上記複数の計算機の各々に設けられるサービス実行手段と、サービス制御手段とを備えている。サービス間関係情報記憶手段には、複数種類のサービスのうちの相異なる２種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報が記憶される。サービス実行手段は、対応する計算機上でのサービスの開始及び停止を行う。サービス制御手段は、クラスタシステムにより提供されるサービスに関し、上記サービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御する。このサービス制御手段は、サービスの開始制御では、上記サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機のサービス実行手段に対して当該サービスの開始を指示する。また、サービス制御手段は、サービスの停止制御では、当該サービスを開始している計算機の前記サービス実行手段に対して当該サービスの停止を指示する
このように本発明においては、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。
【００１０】
ここで、上記複数種類のサービスの各々について当該サービスの許可状態を管理するためのサービス許可状態情報を記憶するサービス許可状態情報記憶手段を追加すると共に、上記サービス制御手段には、上記サービス許可状態情報の示す許可状態に対応して上記サービス間関係情報の示すサービス間の関係が合致するように、開始すべきサービス及び当該開始すべきサービスを開始する計算機、あるいは停止すべきサービス及び当該停止すべきサービスを開始している計算機を選択する自動制御手段を持たせるとよい。このようにすると、上記サービス許可状態情報の示す許可状態に対応してサービス間の関係が合致するように、どのサービスをどの計算機で開始させるか、あるいは停止させるかを自動的に決定できる。
【００１１】
更に、上記サービス実行手段によりサービスが開始された場合に、当該サービスに対応する上記サービス許可状態情報の示す許可状態を不許可にするバッチジョブ制御手段を上記サービス制御手段に持たせ、上記サービス許可状態情報の示す許可状態が不許可となった場合に、上記自動制御手段により当該サービス許可状態情報に対応するサービスの停止制御が行われる構成とするとよい。このようにすると、バッチジョブのサービスが簡単に実現できる。
【００１２】
また、上記サービス間関係情報に、サービス間の関係の種類、サービス間の関係の属性及びサービス間の関係の適用範囲を示す情報を含め、上記サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であり、上記サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、上記自動制御手段による選択の候補となる上記強い関係を満たす計算機が複数存在するときに当該サービス間の関係が成立する計算機が優先的に選択される弱い関係とが設定可能であり、上記サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能である構成とするとよい。
【００１３】
ここで、上記クラスタシステムを、固有の種類のサービスを提供するｎ台の稼働系計算機と、このｎ台の稼働系計算機のいずれかの計算機に障害が発生した場合に、当該障害発生計算機で開始されていたサービスを引き継ぐことが可能なｍ台の待機系計算機で構成し、上記サービス間関係情報記憶手段に記憶される、上記ｎ台の稼働系計算機がそれぞれ提供するサービスのうちの相異なる２種類のサービスの組み合わせ毎の全てのサービス間関係情報に、上記サービス間の関係の種類、上記サービス間の関係の属性及び上記サービス間の関係の適用範囲として、それぞれ排他関係、強い関係及び局所的関係が設定される構成とするならば、ｎ対ｍバックアップ構成を容易に実現できる。
【００１４】
また、上記クラスタシステムにより提供されるサービスとして、データに相当する第１のサービス、データをバックアップする第２のサービス及びデータにアクセスする第３のサービスの３種類のサービスが定義されると共に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、上記第１のサービスに対して上記第２のサービスと上記第３のサービスとから強い依存関係が局所的関係として設定され、上記第２のサービスと上記第３のサービスとの間に強い排他関係が大局的関係として設定される構成とするならば、データのコールドバックアップを容易に実現できる。
【００１５】
同様に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報に、上記第１のサービスに対して上記第２のサービスと上記第３のサービスとから強い依存関係が局所的関係として設定され、上記第３のサービスに対して上記第２のサービスから強い依存関係が大局的関係として設定され構成とするならば、データのオンラインバックアップを容易に実現できる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１７】
［第１の実施形態］
図１は本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図である。同図において、クラスタシステム１は、図示せぬネットワークにより相互接続された複数の計算機、例えばＮ台の計算機１０−１（＃１），１０−２（＃２），…１０−Ｎ（＃Ｎ）を備えて構成される。クラスタシステム１は、クラスタシステム制御機構１０を有する。クラスタシステム制御機構１０は、計算機１０−１（＃１），１０−２（＃２），…１０−Ｎ（＃Ｎ）上にまたがって存在する。つまりクラスタシステム１は、計算機１０−１〜１０−Ｎを用いて実現されるクラスタシステム制御機構１０を有する。
【００１８】
クラスタシステム制御機構１０は、各計算機１０−ｉ（ｉ＝１〜Ｎ）上に実現されるサービス実行機構１１−ｉを有する。つまり計算機１０−ｉはサービス実行機構１１−ｉを有する。サービス実行機構１１−ｉは、サービスの開始を行うサービス開始手段１１１−ｉとサービスの停止を行うサービス停止手段１１２−ｉとを有する。クラスタシステム制御機構１０はまた、シナリオ管理機構１２を有する。シナリオ管理機構１２は、全てのサービス実行機構１１−１〜１１−Ｎとの間に通信経路１３−１〜１３−Ｎを持つ。図１の例では、シナリオ管理機構１２は、クラスタシステム１を構成する全ての計算機１１−１〜１１−Ｎにまたがって存在する。シナリオ管理機構１２は、各計算機１１−１〜１１−Ｎ上で動作し、相互に通信を行うシナリオ管理部１２−１〜１２−Ｎによって実現される。本実施形態において、サービス実行機構１１−ｉ及びシナリオ管理部１２−ｉは、それぞれ対応するソフトウェアプログラムを計算機１０−ｉ（内の図示せぬＣＰＵ）が読み取って実行することにより実現されるものとする。
【００１９】
ここで、図１のシステム内の各要素について詳述する前に、当該システムで適用される「サービス間の関係」について説明する。サービス間の関係とは、相異なる２つのサービスの間にどのような関係があるかを定めたものである。本実施形態において適用される「サービス間の関係」を規定する要素には、
・サービス間の関係の種類
・サービス間の関係の属性
・サービス間の関係の適用範囲
がある。
【００２０】
「サービス間の関係の種類」には、
・依存関係
・排他関係
・無関係
がある。
【００２１】
「依存関係」とは、予め決められたサービスが開始しているときのみ、サービスを開始可能な関係である。例えばサービス＃１に、サービス＃２に対する依存関係が定義されている場合には、サービス＃２が既に開始しているときのみ、サービス＃１を開始可能である。換言するならば、サービス＃１とサービス＃２とが開始している状態で、サービス＃２が停止したときは、サービス＃１も停止する。
【００２２】
「排他関係」とは、サービスを開始しているときは、予め決められたサービスが開始していてはならない関係である。例えば、サービス＃１に、サービス＃２に対する排他関係が定義されている場合、サービス＃２が開始していないときのみサービス＃１は開始可能であり、サービス＃２が開始しているときはサービス＃１は開始不可能である。
【００２３】
「無関係」とは、あるサービスと別のサービスとの間に、何の関係も存在しない関係である。
「依存関係」と「排他関係」と「無関係」とは、互いに独立である。
【００２４】
次に、「サービス間の関係の属性」には、
・強い関係
・弱い関係
がある。
【００２５】
「強い関係」とは、対象となるサービス間の関係が、必ず成立しなければならない関係であることを意味する。強い関係であるサービス間の関係に違反するような、サービスの開始あるいはサービスの停止はできない。
【００２６】
「弱い関係」とは、ユーザがサービスを開始する計算機を指定せずにサービスの開始操作を行った場合に、シナリオ管理機構１２が、自動的にサービスを開始する計算機を決定するために参照される関係であることを意味する。このようなサービスの制御を、サービスの自動制御と呼ぶ。つまり、「弱い関係」は、サービスの自動制御における選択の候補となる「強い関係」を満たす計算機（選択肢）が複数あるときに、その「弱い関係」が成立する計算機が優先的に選択される関係である。ここでは、サービスを開始可能な計算機（その計算機でサービスを開始していることが、強い関係であるサービス間の関係に違反しない計算機）が複数ある場合、それらの中から、弱い関係であるサービス間の関係に違反しない計算機が、サービスを開始する計算機に決定される。
【００２７】
「サービス間の関係の適用範囲」には、
・局所的関係
・大局的関係
がある。
【００２８】
「局所的関係」とは、対象となるサービス間の関係が、同一計算機でサービスを開始しているときにのみ適用される範囲であることを意味する。「大局的関係」とは、対象となるサービス間の関係が、どの計算機でサービスを開始しているかによらずに適用される範囲であることを意味する。
【００２９】
例えば、サービス＃１とサービス＃２との間に強い排他関係が設定されていて、サービス＃１が計算機＃１で開始しているものとする。この場合、上記強い排他関係が大局的関係であればサービス＃２はいずれの計算機でも開始できず、局所的関係であればサービス＃２は計算機＃１では開始できない。
【００３０】
図２は、図１中のシナリオ管理機構１２の構成を示すブロック図である。シナリオ管理機構１２は、データベース部１２１とサービス制御部１２２とに大別される。
データベース部１２１は、サービス関係情報データベース（ＤＢ）１２１ａ、サービス状態情報データベース（ＤＢ）１２１ｂ、計算機状態情報データベース（ＤＢ）１２１ｃ、及びサービス許可状態情報データベース（ＤＢ）１２１ｄを記憶するための情報記憶部である。
【００３１】
サービス関係情報ＤＢ１２１ａは、サービス間の関係を管理するためのデータベースである。サービス関係情報ＤＢ１２１ａの１つのデータ（レコード）は、サービス名ＳＮ１、当該サービス名ＳＮ１のサービスと関係するサービスのサービス名ＳＮ２、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の５項目で構成される。
【００３２】
サービス状態情報ＤＢ１２１ｂは、サービスの状態を管理するためのデータベースである。サービス状態情報ＤＢ１２１ｂの１つのデータ（レコード）は、サービス名、計算機名、及び状態の３項目で構成される。サービス名とは、図１のクラスタシステムにより提供されるサービスの名前である。計算機名とは、サービス開始手段１１１−ｉを最後に実行させた計算機の名前である。状態とは、サービスが正常に開始しているかどうかを示す情報であり、「開始」、「停止」または「障害発生」の３状態を持つ。
【００３３】
計算機状態情報ＤＢ１２１ｃは、計算機の状態を管理するためのデータベースである。計算機状態情報ＤＢ１２１ｃの１つのデータ（レコード）は、計算機名及び状態の２項目で構成される。計算機名とは、図１のクラスタシステムを構成する計算機の名前である。状態とは、計算機が正常に動作しているかどうかを示す情報であり、「正常」または「異常」の２状態を持つ。
【００３４】
サービス許可状態情報ＤＢ１２１ｄは、サービスの許可状態を管理するためのデータベースである。サービス許可状態情報ＤＢ１２１ｄの１つのデータ（レコード）は、サービス名及び許可状態の２項目で構成される。サービス名とは、図１のクラスタシステムにより提供されるサービスの名前である。許可状態とは、サービスが開始していること（つまりサービスが開始状態にあること）が許可されているか許可されていないかを示し、「許可」または「不許可」の２状態を持つ。
【００３５】
サービス制御部１２２は、操作処理部１２２ａ、手動制御部１２２ｂ、自動制御部１２２ｃ、サービス間関係判定部１２２ｄ、実行制御部１２２ｅ及び障害検出部１２２ｆの各処理部を有する。
操作処理部１２２ａは、図示せぬクライアント端末（ユーザ端末）からネットワークを介して与えられるユーザからの操作内容を受け取って、その操作内容に対応するサービスの制御（ある計算機で、あるサービスを開始あるいは停止すること）を、手動制御部１２２ｂに依頼するユーザインタフェースである。
【００３６】
手動制御部１２２ｂは、操作処理部１２２ａからサービスの制御依頼（ある計算機で、あるサービスを開始あるいは停止すること）を受け取ると、そのサービスの制御が、サービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認し、実行制御部１２２ｅにその制御を依頼する。
【００３７】
自動制御部１２２ｃは、定期的にサービス許可状態情報ＤＢ１２１ｄを参照し、当該情報ＤＢ１２１ｄの変化に応じてサービスの制御を自動的に実行する。即ち自動制御部１２２ｃは、あるサービスの許可状態が「許可」になると、そのサービスを開始すること（つまり停止状態から開始状態へ遷移させること）がサービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認して、サービスを開始する計算機を決定する。自動制御部１２２ｃは、決定した計算機でサービスを開始するための制御を実行制御部１２２ｅに依頼する。また自動制御部１２２ｃは、許可状態が「不許可」になると、そのサービスを開始している計算機を特定する。自動制御部１２２ｃは、特定した計算機で開始されているサービスを停止するための制御を実行制御部１２２ｅに依頼する。
【００３８】
サービス間関係判定部１２２ｄは、手動制御部１２２ｂまたは自動制御部１２２ｃから受け取ったサービスの制御を実行することが、データベース部１２１に設定されているサービス間の関係に違反しないかどうかを判定する。
実行制御部１２２ｅは、手動制御部１２２ｂまたは自動制御部１２２ｃから受け取ったサービスの制御を、該当する計算機１０−ｉのサービス実行機構１１−ｉへ伝える。
障害検出部１２２ｆは、計算機１０−ｉで障害が発生したことを検出して、サービス状態情報ＤＢ１２１ｂ及び計算機状態情報ＤＢ１２１ｃを更新する。
【００３９】
次に、図１のクラスタシステムの動作について、ユーザによるサービスの開始操作に伴ってシナリオ管理機構１２が実行する処理を例に説明する。この処理は、ユーザが、サービスを開始する計算機を指定するか否かで異なる。
【００４０】
まず、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理について、図３のフローチャートを参照して説明する。
シナリオ管理機構１２内の操作処理部１２２ａは、ユーザからのあるサービス（サービス＃ｊとする）の開始操作内容をクライアント端末から受け取ると、サービス許可状態情報ＤＢ１２１ｄにアクセスし、サービス＃ｊの許可状態を「許可」にする。
【００４１】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照する（ステップＳ１）。もし、サービス＃ｊの許可状態が「許可」になったなら（ステップＳ２）、自動制御部１２２ｃは計算機状態情報ＤＢ１２１ｃを参照し、未判断の計算機があるかを調べる（ステップＳ３）。ここで、ステップＳ３の１回目では、全ての計算機が未判断である。ステップＳ３が繰り返された結果、未判断の計算機がなくなったときは、自動制御部１２２ｃは、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ４）。
【００４２】
これに対し、未判断の計算機があるときは、自動制御部１２２ｃは、未判断の計算機のうちの任意の１台を、サービス＃ｊの開始対象計算機の候補（以下、候補計算機と称する）として選択する（ステップＳ５）。ここでは、計算機１０−ｉ（計算機＃ｉ）が候補計算機として選択されたものとする。次に自動制御部１２２ｃは、選択された候補計算機１０−ｉの状態が「正常」であるかを計算機状態情報ＤＢ１２１ｃをもとに調べる（ステップＳ６）。
【００４３】
もし、候補計算機１０−ｉの状態が正常でないならば（ステップＳ６）、自動制御部１２２ｃは当該計算機１０−ｉを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ３）に戻る。これに対し、候補計算機１０−ｉの状態が正常であるならば（ステップＳ６）、自動制御部１２２ｃはサービス間関係判定部１２２ｄに問い合わせて、当該計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ７）。このサービス間関係判定部１２２ｄの処理については後述する。
【００４４】
自動制御部１２２ｃは、候補計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ７）、当該計算機１０−ｉを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ３）に戻る。これに対し、候補計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ７）、自動制御部１２２ｃは当該計算機１０−ｉに対するサービス制御要求を実行制御部１２２ｅへ送る。この場合、実行制御部１２２ｅは自動制御部１２２ｃからのサービス制御要求に従い、当該要求で指定された計算機１０−ｉ（計算機＃ｉ）のサービス実行機構１１−ｉに対し、サービス＃ｊの開始を行うサービス開始手段１１１−ｉを実行させるための命令を送る（ステップＳ８）。
【００４５】
実行制御部１２２ｅは、計算機１０−ｉのサービス実行機構１１−ｉに対し、サービス＃ｊの開始を行うサービス開始手段１１１−ｉを実行させるための命令を送ると、自動制御部１２２ｃに対してサービス制御要求の完了を通知する。自動制御部１２２ｃは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ９）。以上で、ユーザがサービスを開始する計算機を指定しない場合における、サービス＃ｊの開始操作に伴う処理は終了する（ステップＳ１０）。
【００４６】
次に、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構１２の主として手動制御部１２２ｂによる処理について、図４のフローチャートを参照して説明する。
シナリオ管理機構１２内の操作処理部１２２ａは、ユーザからのある計算機（以下、指定計算機と称する）１０−ｉ（計算機＃ｉ）でのあるサービス（サービス＃ｊとする）の開始操作を受け取る、それに基づいたサービス制御要求を手動制御部１２２ｂへ送る。これにより手動制御部１２２ｂは、要求されたサービス制御の処理、つまりサービス＃ｊの開始操作に伴う処理を開始する（ステップＳ１１）。
【００４７】
まず、手動制御部１２２ｂは計算機状態情報ＤＢ１２１ｃを参照し、指定計算機１０−ｉの状態が正常であるかを調べる（ステップＳ１２）。もし、指定計算機１０−ｉの状態が正常でないならば、手動制御部１２２ｂは指定計算機１０−ｉでサービス＃ｊを開始できないものとして、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ１３）。これに対し、指定計算機１０−ｉの状態が正常であるならば、手動制御部１２２ｂは、サービス間関係判定部１２２ｄに問い合わせて、当該計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ１４）。
【００４８】
手動制御部１２２ｂは、指定計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ１４）、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ１３）。これに対し、指定計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ１４）、手動制御部１２２ｂは当該計算機１０−ｉに対するサービス制御要求を実行制御部１２２ｅへ送る。
【００４９】
実行制御部１２２ｅは、手動制御部１２２ｂからのサービス制御要求に従い、当該要求で指定された計算機１０−ｉのサービス実行機構１１−ｉに対し、サービス＃ｊの開始を行うサービス開始手段１１１−ｉを実行させるための命令を送る（ステップＳ１５）。そして実行制御部１２２ｅは、手動制御部１２２ｂに対してサービス制御要求の完了を通知する。手動制御部１２２ｂは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ１６）。以上で、ユーザがサービスを開始する計算機を指定した場合における、サービス＃ｊの開始操作に伴う処理は終了する（ステップＳ１７）。
【００５０】
次に、クラスタシステム１内の計算機で発生した障害が検出された場合に、当該障害発生計算機で開始されていたサービスをクラスタシステム１内の他の計算機で引き継ぐ（フェイルオーバする）ために実行されるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理（フェイルオーバ処理）について、図５のフローチャートを参照して説明する。
【００５１】
今、シナリオ管理機構１２内の障害検出部１２２ｆが、クラスタシステム１内のある計算機、例えば計算機１０−ｋ（計算機＃ｋ）で発生した障害を検出したものとする。この場合、障害検出部１２２ｆは、計算機状態情報ＤＢ１２１ｃにアクセスし、障害発生計算機１０−ｋ（計算機＃ｋ）の状態を「異常」にする。また障害検出部１２２ｆはサービス状態情報ＤＢ１２１ｂにもアクセスし、計算機名が「計算機＃ｋ」であり、且つ現在の状態が「開始」の全てのサービスついて、当該状態を「障害発生」にする。
【００５２】
シナリオ管理機構１２内の自動制御部１２２ｃは、サービス状態情報ＤＢ１２１ｂを定期的に参照する（ステップＳ２１）。もし、状態が「障害発生」であるサービスがあったならば（ステップＳ２２）、自動制御部１２２ｃは当該サービスをフェイルオーバするための処理を開始する。ここでは、サービス＃ｊの状態が「障害発生」となったことが検出されたものとする。
【００５３】
まず、自動制御部１２２ｃは計算機状態情報ＤＢ１２１ｃを参照し、未判断の計算機があるかを調べる（ステップＳ２３）。ここで、ステップＳ２３の１回目では、全ての計算機が未判断である。ステップＳ２３が繰り返された結果、未判断の計算機がなくなったときは、自動制御部１２２ｃは、サービス＃ｊをフェイルオーバするための処理を終了する（ステップＳ２４）。
【００５４】
これに対し、未判断の計算機があるときは、自動制御部１２２ｃは、未判断の計算機のうちの任意の１台を、サービス＃ｊの開始（引き継ぎ）対象計算機の候補（以下、候補計算機と称する）として選択する（ステップＳ２５）。ここでは、計算機１０−ｉ（計算機＃ｉ）が候補計算機として選択されたものとする。次に自動制御部１２２ｃは、選択された候補計算機１０−ｉの状態が「正常」であるかを計算機状態情報ＤＢ１２１ｃをもとに調べる（ステップＳ２６）。
【００５５】
もし、候補計算機１０−ｉの状態が正常でないならば（ステップＳ２６）、自動制御部１２２ｃは当該計算機１０−ｉを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ２３）に戻る。これに対し、候補計算機１０−ｉの状態が正常であるならば（ステップＳ２６）、自動制御部１２２ｃはサービス間関係判定部１２２ｄに問い合わせて、当該計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ２７）。
【００５６】
自動制御部１２２ｃは、候補計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ２７）、当該計算機１０−ｉを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ２３）に戻る。これに対し、候補計算機１０−ｉにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ２７）、自動制御部１２２ｃは当該計算機１０−ｉに対するサービス制御要求を実行制御部１２２ｅへ送る。この場合、実行制御部１２２ｅは自動制御部１２２ｃからのサービス制御要求に従い、当該要求で指定された計算機１０−ｉ（計算機＃ｉ）のサービス実行機構１１−ｉに対し、サービス＃ｊの開始を行うサービス開始手段１１１−ｉを実行させるための命令を送る（ステップＳ２８）。そして実行制御部１２２ｅは、自動制御部１２２ｃに対してサービス制御要求の完了を通知する。
【００５７】
自動制御部１２２ｃは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ２９）。以上で、障害発生計算機１０−ｋ（障害発生計算機＃ｋ）が開始していたサービス＃ｊをクラスタシステム１内の他の正常な計算機（ここでは計算機１０−ｉ（計算機＃ｉ））がフェイルオーバするための処理は終了する（ステップＳ３０）。自動制御部１２２ｃは、状態が「障害発生」であるサービスがある限り、上記の処理を繰り返す。
【００５８】
次に、シナリオ管理機構１２内のサービス間関係判定部１２２ｄにより実行されるサービス間関係判定処理（つまり、着目するサービスがサービス間の関係に違反していないかを調べる処理）について、図６のフローチャートを参照して説明する。
【００５９】
今、手動制御部１２２ｂまたは自動制御部１２２ｃからサービス間関係判定部１２２ｄに対し、あるサービス＃ｊをある計算機１０−ｉ（計算機＃ｉ）で開始してよいかという問い合わせが与えられたものとする。ここで、問い合わせられたサービス及び計算機を、それぞれ、対象サービス及び対象計算機と称する。ここでは、対象サービスはサービス＃ｊであり、対象計算機は計算機１０−ｉ（計算機＃ｉ）であるものとする。
【００６０】
サービス間関係判定部１２２ｄは、手動制御部１２２ｂまたは自動制御部１２２ｃからの問い合わせを受け取ると、当該問い合わせで指定された対象サービス＃ｊを当該問い合わせで指定された計算機１０−ｉ（計算機＃ｉ）で開始することに対する、サービス間の関係に違反しているかを調べるサービス間関係判定処理を開始する（ステップＳ４１）。まず、サービス間関係判定部１２２ｄはサービス関係情報ＤＢ１２１ａを参照し、当該サービス関係情報ＤＢ１２１ａ中でサービス名ＳＮ１が対象サービス＃ｊを表すデータ（レコード）を全て取得する（ステップＳ４２）。
【００６１】
次にサービス間関係判定部１２２ｄは、取得したデータの中に、サービス間の関係の種類が「排他関係」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い排他関係」であり、且つ未判断のものがあるかを調べる（ステップＳ４３）。ここで、ステップＳ４３の１回目では、全ての「強い排他関係」が未判断である。ステップＳ４３が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部１２２ｄは、後述する依存関係を調べる処理（ステップＳ５０）に進む。
【００６２】
一方、未判断の「強い排他関係」のデータがあるときは、サービス間関係判定部１２２ｄは、未判断のデータのうちの任意の１つを、サービス間関係の判定対象の候補となるデータ（以下、候補データと称する）として選択する（ステップＳ４４）。次にサービス間関係判定部１２２ｄは、サービス状態情報ＤＢ１２１ｂを参照し、サービス関係情報ＤＢ１２１ａ中の選択した候補データにおけるサービス名ＳＮ２で示されるサービスに関する情報（以下、排他対象データと称する）を取得する（ステップＳ４５）。
【００６３】
サービス間関係判定部１２２ｄは、取得した排他対象データの状態が「開始」であるかを調べる（ステップＳ４６）。もし、取得した排他対象データの状態が開始でないならば（ステップＳ４６）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ４３）に戻る。これに対し、取得した排他対象データの状態が開始であるならば、サービス間関係判定部１２２ｄは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる（ステップＳ４７）。
【００６４】
もし、取得した排他対象データのサービス間の関係の属性が局所的関係でないならば（ステップＳ４７）、サービス間関係判定部１２２ｄはサービス間の関係に違反していると決定する（ステップＳ４９）。これに対し、排他対象データのサービス間の関係の属性が局所的関係であるならば（ステップＳ４７）、サービス間関係判定部１２２ｄは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる（ステップＳ４８）。
【００６５】
もし、排他対象データに含まれている計算機名が対象計算機を表しているならば（ステップＳ４８）、サービス間関係判定部１２２ｄは、対象サービス＃ｊを計算機１０−ｉで開始することがサービス間の関係に違反していると決定する（ステップＳ４９）。これに対し、排他対象データに含まれている計算機名が対象計算機を表していないならば（ステップＳ４８）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ４３）に戻る。
【００６６】
さて、ステップＳ４３が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部１２２ｄは、ステップＳ４２で取得したデータの中に、サービス間の関係の種類が「依存」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い依存関係」であり、且つ未判断のものがあるかを調べる（ステップＳ５０）。ここで、ステップＳ５０の１回目では、全ての「強い依存関係」が未判断である。ステップＳ５０が繰り返された結果、未判断の「強い依存関係」のデータがなくなったときは（ステップＳ５０）、サービス間関係判定部１２２ｄは対象サービス＃ｊを計算機１０−ｉで開始することががサービス間の関係に違反していないと決定する（ステップＳ５１）。
【００６７】
一方、未判断の「強い依存関係」のデータがあるときは、サービス間関係判定部１２２ｄは、未判断の「強い依存関係」のデータのうちの任意の１つを、サービス間関係の判定対象の候補データとして選択する（ステップＳ５２）。次にサービス間関係判定部１２２ｄは、サービス状態情報ＤＢ１２１ｂを参照し、サービス関係情報ＤＢ１２１ａ中の選択した候補データにおけるサービス名で示されるサービスに関する情報を依存対象データとして取得する（ステップＳ５３）。
【００６８】
サービス間関係判定部１２２ｄは、取得した依存対象データの状態が「開始」であるかを調べる（ステップＳ５４）。もし、取得した依存対象データの状態が開始であるならば（ステップＳ５４）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。これに対し、取得した依存対象データの状態が開始でないならば、サービス間関係判定部１２２ｄは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる（ステップＳ５５）。
【００６９】
もし、取得した依存対象データのサービス間の関係の属性が局所的関係でないならば（ステップＳ５５）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。これに対し、依存対象データのサービス間の関係の属性が局所的関係であるならば（ステップＳ５５）、サービス間関係判定部１２２ｄは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる（ステップＳ５６）。
【００７０】
もし、依存対象データに含まれている計算機名が対象計算機を表していないならば（ステップＳ５６）、サービス間関係判定部１２２ｄは、対象サービス＃ｊを計算機１０−ｉで開始することがサービス間の関係に違反していると決定する（ステップＳ５７）。これに対し、依存対象データに含まれている計算機名が対象計算機を表しているならば（ステップＳ５６）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。
【００７１】
このように、本発明の第１の実施形態においては、サービス関係情報ＤＢ１２１ａによりサービス間の関係を設定することにより、高度で且つ詳細なサービスの制御が実現可能となる。具体的には、順番に開始しなければいけないサービス、同時に開始してはいけないサービスを設定することにより、高度で且つ詳細なサービスの制御がクラスタシステム制御機構１０内のシナリオ管理機構１２から制御可能となる。また、本発明の第１の実施形態においては、主として自動制御部１２２ｃにより実現されるサービスの自動制御を使用することにより、ユーザに求められる判断が減少し、クラスタシステムの制御を容易にすることができる。更に本発明の第１の実施形態においては、サービスをフェイルオーバする仕組みを簡単に実現できる。
【００７２】
（第１の実施形態の第１の変形例）
図７は、本発明の第１の実施形態の第１の変形例に係るクラスタシステムの構成を示すブロック図である。なお、図７の構成において、図１と等価な部分には同一の参照符号を付してある。
【００７３】
図７に示すクラスタシステム１’の特徴は、図１中のシナリオ管理機構１２に相当するシナリオ管理機構１２’が、計算機１０−１（＃１）〜１０−Ｎ（＃Ｎ）のうちのいずれか１つの計算機、例えば計算機１０−１（＃１）上に存在する点にある。
【００７４】
本発明の第１の実施形態及びその第１の変形例から明らかなように、クラスタシステム内のシナリオ管理機構は、クラスタシステムを構成する複数の計算機のうちのいずれか１つの計算機上だけに存在しても、全ての計算機上にまたがって存在しても、２つ以上の一部の計算機上に存在しても構わない。
【００７５】
（第１の実施形態の第２の変形例）
次に、上記第１の実施形態の第２の変形例について説明する。
サービス間の関係の種類（依存関係、排他関係、無関係）と、サービス間の関係の属性（強い関係、弱い関係）とは、組み合わせることが可能である。その組み合わせの数は、以下に示す５通り、即ち
・強い依存関係
・弱い依存関係
・強い排他関係
・弱い排他関係
・無関係
となる。
【００７６】
また、上記５通りの組み合わせに、サービス間の関係の適用範囲（局所的関係、大局的関係）を組み合わせることも可能である。組み合わせの数は、以下に示す１０（５×２）通り、即ち
（１）局所的な強い依存関係
（２）局所的な弱い依存関係
（３）局所的な強い排他関係
（４）局所的な弱い排他関係
（５）局所的な無関係
（６）大局的な強い依存関係
（７）大局的な弱い依存関係
（８）大局的な強い排他関係
（９）大局的な弱い排他関係
（１０）大局的な無関係
となる。
【００７７】
したがって、サービス間の関係を設定するとき、同一のサービス間について、上記１０通りの組み合わせから幾つかを選択して同時に設定することが可能である。しかし、同時に設定される選択された組み合わせ（選択パターン）のうちの幾つかは、論理的に矛盾が生じるもの、あるいは無意味なものである。例えば、（６）の組み合わせと（８）の組み合わせとを同時に設定すると、論理的に矛盾が生じる。また、排他関係を考えてみると、（８）の組み合わせを設定しているときに（３）の組み合わせを設定することは無意味である。また、依存関係を考えてみると、（１）の組み合わせを設定しているときに（６）の組み合わせを設定することは無意味である。
【００７８】
このような、論理的に矛盾が生じる選択パターン及び無意味な選択パターンを、上記１０通りの組み合わせのうちの同時に設定可能な選択パターンの中から除いた場合、設定可能な選択パターンは以下に示す１５通り、即ち
（１）局所的な強い依存関係と大局的な強い依存関係
（２）局所的な弱い依存関係と大局的な強い依存関係
（３）局所的な弱い依存関係と大局的な弱い依存関係
（４）大局的な強い依存関係のみ
（５）大局的な弱い依存関係のみ
（６）大局的な強い依存関係と局所的な強い排他関係
（７）大局的な弱い依存関係と局所的な強い排他関係
（８）大局的な強い依存関係と局所的な弱い排他関係
（９）大局的な弱い依存関係と局所的な弱い排他関係
（１０）局所的な弱い排他関係のみ
（１１）局所的な強い排他関係のみ
（１２）局所的な弱い排他関係と大局的な弱い排他関係
（１３）局所的な強い排他関係と大局的な弱い排他関係
（１４）局所的な強い排他関係と大局的な強い排他関係
（１５）無関係のみ
となる。
【００７９】
このように、本発明の第１の実施形態の第２の変形例においては、サービス間の関係の種類、その属性、及びその適用範囲の組み合わせのうちから、幾つかを選択してサービス関係情報ＤＢ１２１ａに設定するとき、論理的に矛盾が生じる選択パターンと論理的に無意味な選択パターンとを予め除いておくことで、論理的に正しいサービス間の関係を効率よく設定可能となる。
【００８０】
［第２の実施形態］
次に本発明の第２の実施形態について説明する。
図８は図１のクラスタシステム内で、図２の構成のシナリオ管理機構１２に代えて用いられるシナリオ管理機構１２０の構成を示すブロック図である。なお、図８の構成において、図２と等価な部分には同一の参照符号を付してある。
【００８１】
図８の構成のシナリオ管理機構１２０の特徴は、バッチジョブが実現可能な構成を有している点にある。バッチジョブとは、予め定められた一連の処理を実行し、その処理の終了をもってジョブの終了とする方式のジョブである。従来のクラスタシステムでは、サービスを停止させるには、必ずユーザによる操作が必要であるため、バッチジョブのような自動的に終了する処理をサービスとして実現することが困難であった。
【００８２】
図８のシナリオ管理機構１２０はバッチジョブ制御部１２２ｇを有する。このシナリオ管理機構１２０の構成は、図２のシナリオ管理機構１２に、バッチジョブ制御部１２２ｇが追加された構成と等価である。バッチジョブ制御部１２２ｇはバッチジョブ型サービス情報ＤＢ１２１ｅを有する。このバッチジョブ型サービス情報ＤＢ１２１ｅは、バッチジョブとして扱うサービス（バッチジョブ型サービス）のデータベースである。バッチジョブ型サービス情報ＤＢ１２１ｅの１つのデータ（レコード）は、サービス名及び状態の２項目で構成される。サービス名とは、クラスタシステムにより提供されるバッチジョブ型サービスの名前である。状態とは、バッチジョブ型サービスが実行中かどうかを示す情報であり、「実行中」または「停止」の２状態を持つ。
【００８３】
次に、図８に示した構成のシナリオ管理機構１２０の主としてバッチジョブ制御部１２２ｇによる処理について、あるバッチジョブ型サービス（サービス＃ｊとする）を扱う処理を例に、図９のフローチャートを参照して説明する。
まず、バッチジョブ型サービス情報ＤＢ１２１ｅには、サービス名がサービス＃ｊで状態が「停止」のデータ（レコード）が設定されているものとする。この状態で、操作処理部１２２ａが、ユーザからのサービス＃ｊの開始操作を受け取ったものとする。すると操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスして、サービス＃ｊの許可状態を「許可」にする。
【００８４】
バッチジョブ制御部１２２ｇは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照し、その都度サービス＃ｊに関するデータを取得する（ステップＳ６１）。もし、サービス許可状態情報ＤＢ１２１ｄから取得したサービス＃ｊの許可状態が「許可」になったならば（ステップＳ６２）、バッチジョブ制御部１２２ｇはバッチジョブ型サービス情報ＤＢ１２１ｅにアクセスしてサービス＃ｊの状態を「実行中」にする（ステップＳ６３）。
【００８５】
次にバッチジョブ制御部１２２ｇは定期的にサービス状態情報ＤＢ１２１ｂを参照して、サービス＃ｊに関するデータ（レコード）を取得する。一方、自動制御部１２２ｃは、この例のように、サービス＃ｊの許可状態が「許可」となった場合、当該サービス＃ｊの開始処理を実行し、その最後でサービス状態情報ＤＢ１２１ｂにアクセスして、サービス＃ｊの状態を「開始」にする。
【００８６】
バッチジョブ制御部１２２ｇは、サービス状態情報ＤＢ１２１ｂ中のサービス＃ｊの状態が「開始」になると（ステップＳ６４）、サービス許可状態情報ＤＢ１２１ｄにアクセスして、当該サービス＃ｊの許可状態を「不許可」にする（ステップＳ６５）。自動制御部１２２ｃは、サービス＃ｊの許可状態が「不許可」になると、当該サービス＃ｊを停止する処理を実行し、その最後でサービス状態情報ＤＢ１２１ｂにアクセスして、当該サービス＃ｊの状態を「停止」にする。
【００８７】
バッチジョブ制御部１２２ｇは、サービス状態情報ＤＢ１２１ｂ中のサービス＃ｊの状態が「停止」になると（ステップＳ６６）、バッチジョブ型サービス情報ＤＢ１２１ｅにアクセスして、当該サービス＃ｊの状態を停止にする（ステップＳ６７）。以上でサービス＃ｊのバッチジョブ処理は終了する（ステップＳ６７）。
【００８８】
このように本発明の第２の実施形態においては、バッチジョブ制御部１２２ｇを備えたシナリオ管理機構１２０を用いることにより、サービスをバッチジョブとして扱うことが可能となる。これにより、例えばデータのバックアップのようなバッチジョブとして扱うのに適した処理を、シナリオ管理機構１２０によって制御可能となる。
【００８９】
［第３の実施形態］
次に本発明の第３の実施形態について説明する。
図１０は本発明の第３の実施形態に係るクラスタシステム（ｎ対ｍバックアップ構成クラスタシステム）の構成を示すブロック図である。この図１０のｎ対ｍバックアップ構成クラスタシステムの特徴は、従来から知られているｎ対ｍ（ｎは２以上の整数、ｍは１以上の整数）バックアップ構成を、前記第１の実施形態で適用されたクラスタシステムを応用して実現している点にある。
【００９０】
図１０のｎ対ｍバックアップ構成クラスタシステムは、ｎ個の１対ｍバックアップ構成クラスタシステム１−１（＃１），１−２（＃２），…１−ｎ（＃ｎ）から構成されている。クラスタシステム１−１（＃１），１−２（＃２），…１−ｎ（＃ｎ）は、それぞれ、稼働系計算機として用いられる計算機１００−１（＃１），１００−２（＃２），…１００−ｎ（＃ｎ）を備えている。計算機１００−１（＃１），１００−２（＃２），…１００−ｎ（＃ｎ）は、それぞれサービス＃１，＃２，…＃ｎを提供する。クラスタシステム１−１（＃１），１−２（＃２），…１−ｎ（＃ｎ）は、当該クラスタシステム１−１（＃１），１−２（＃２），…１−ｎ（＃ｎ）内の稼働系計算機１００−１（＃１），１００−２（＃２），…１００−ｎ（＃ｎ）に対応して共通に設けられ、待機系計算機として用いられるｍ台の計算機１００−（ｎ＋１）（＃ｎ＋１），１００−（ｎ＋２）（＃ｎ＋２），…１００−（ｎ＋ｍ）（＃ｎ＋ｍ）を備えている。クラスタシステム１−１（＃１）〜１−ｎ（＃ｎ）内の稼働系計算機１００−１（＃１）〜１００−ｎ（＃ｎ）、及びクラスタシステム１−１（＃１）〜１−ｎ（＃ｎ）に共通の待機系計算機１００−（ｎ＋１）（＃ｎ＋１）〜１００−（ｎ＋ｍ）（＃ｎ＋ｍ）は、図示せぬネットワークにより相互接続されている。
【００９１】
このように、図１０に示したｎ対ｍバックアップ構成クラスタシステムは、計算機資源を節約するためにｍ台の計算機１００−（ｎ＋１）（＃ｎ＋１）〜１００−（ｎ＋ｍ）（＃ｎ＋ｍ）をいずれも待機系計算機として共通に使用する、ｎ個の１対ｍバックアップ構成クラスタシステム１−１（＃１）〜１−ｎ（＃ｎ）から構成される。このｎ対ｍバックアップ構成クラスタシステムでは、サービス＃１〜＃ｎを提供するｎ台の稼働系計算機１００−１〜１００−ｎのうちのいずれかで障害が発生した場合に、その計算機が提供していたサービスを、ｍ台の計算機１００−（ｎ＋１）〜１００−（ｎ＋ｍ）のいずれかで引き継ぐことが可能なように構成されている。図１０のｎ対ｍバックアップ構成クラスタシステムの構成は、ｎ個の１対ｍバックアップ構成クラスタシステム１−１（＃１）〜１−ｎ（＃ｎ）を備えている点を除けば、前記第１の実施形態におけるクラスタシステムと同様である。即ち図１０のｎ対ｍバックアップ構成クラスタシステムは、計算機１００−１（＃１）〜１００−（ｎ＋ｍ）（＃ｎ＋ｍ）毎に設けられるサービス実行機構と図２の構成のシナリオ管理機構とを含むクラスタシステム制御機構（いずれも図示せず）を有している。したがって、第３の実施形態では、必要に応じて図２を援用する。
【００９２】
従来技術では、ｎ対ｍバックアップ構成の計算機システムを実現するためには、ｎ個のサービス＃１〜＃ｎ全てに対して、どの計算機で開始し、障害発生時にはどの計算機へ引き継ぐのかを、同じ計算機にサービスが集中しないように注意しながら設定する必要がある。これに対して、本発明の第３の実施形態では、前記第１の実施形態で適用されたクラスタシステムを用いることにより、この種の設定が以下に述べるように簡単に行える。
【００９３】
図１１は、図１０のｎ対ｍバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報ＤＢ１２１ａの一例を示す。この図１１のサービス関係情報ＤＢ１２１ａには、図１０のｎ対ｍバックアップ構成クラスタシステムにより提供されるｎ個のサービスのうちのサービス＃ｉ（ｉ＝１〜ｎ−１）と他のサービス＃ｊ（ｊ＝ｉ＋１〜ｎ）との全ての組み合わせについて、その組み合わせのサービスを表すサービス名（ＳＮ１，ＳＮ２）、サービス（＃ｉ，＃ｊ）間の関係の種類、サービス（＃ｉ，＃ｊ）間の関係の属性、及びサービス（＃ｉ，＃ｊ）間の関係の適用範囲の情報が登録されている。ここでは、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲は、サービスの組み合わせに無関係に、
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
のように設定される。
【００９４】
次に、図１１に示すサービス関係情報ＤＢ１２１ａを適用した図１０のｎ対ｍバックアップ構成クラスタシステムの動作を、図２の構成及び図５のフローチャートを援用して説明する。
図２に示すシナリオ管理機構１２中の操作処理部１２２ａは、ユーザによるｎ個のサービス＃１〜＃ｎの開始操作を受け取ると、サービス許可状態情報ＤＢ１２１ｄにアクセスし、ｎ個のサービス＃１〜＃ｎの許可状態をいずれも「許可」にする。自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄ中のサービス＃１〜＃ｎの許可状態が「許可」になったなら、そのサービス＃１〜＃ｎを、サービス関係情報ＤＢ１２１ａにより示されるサービス間の関係に従い、ｎ対ｍバックアップ構成クラスタシステムを構成するｎ＋ｍ台の計算機のうちのｎ台の稼働系計算機１００−１（＃１）〜１００−ｎ（＃ｎ）で１サービスずつ開始させる。ここでは、計算機１００−ｉ（＃ｉ）でサービス＃ｉが開始されるものとする。
【００９５】
この状態で、例えば計算機１００−１（＃１）で障害が発生したために、当該計算機１００−１で開始していたサービス＃１をフェイルオーバするものとする。このフェイルオーバ処理は、前記第１の実施形態と同様に、自動制御部１２２ｃにより図５のフローチャートに従って実行される。即ち自動制御部１２２ｃは、サービス状態情報ＤＢ１２１ｂを参照することで、サービス＃１を開始していた計算機１００−１で障害が発生したことを検出すると（図５ステップＳ２１，Ｓ２２）、当該サービス＃１を引き継ぐ計算機を、図５のステップＳ２３から始まる一連の処理（ステップＳ２３，Ｓ２５〜Ｓ２７）により決定する。ここでは、計算機状態情報ＤＢ１２１ｃの示す計算機状態及びサービス関係情報ＤＢ１２１ａの示すサービス間の関係をもとに、図１０のｎ対ｍバックアップ構成クラスタシステム内のｎ＋ｍ台の計算機の中から、サービス＃１の開始がサービス間の関係に違反しない正常な計算機が１つ選択される。図１１に示すサービス関係情報ＤＢ１２１ａの例では、サービス＃１の開始がサービス間の関係に違反しない計算機は、サービスを開始していない待機系の計算機１００−（ｎ＋１）〜１００−（ｎ＋ｍ）であり、そのうちの計算機１００−（ｎ＋１）が選択されたものとする。この場合、計算機１００−（ｎ＋１）によりサービス＃１が開始される（引き継がれる）。
【００９６】
更に、この状態で計算機１００−２で障害が発生し、当該計算機１００−２で開始していたサービス＃２をフェイルオーバするものとする。この場合も上記と同様に、自動制御部１２２ｃにより引継ぎ先の計算機が決定される。ここでは、稼働系の計算機１００−１〜１００−ｎとサービス＃１を引き継いだ計算機１００−（ｎ＋１）とを除くｍ−１台の計算機１００−（ｎ＋２）〜１００−（ｎ＋ｍ）のうちの１つ、例えば計算機１００−（ｎ＋２）が引継ぎ先の計算機として選択され、当該計算機１００−（ｎ＋２）でサービス＃２が開始される（引き継がれる）ものとする。
【００９７】
以下、同様の制御により、ｎ≧ｍの場合には、計算機１００−１〜１００−ｎのうちのｍ台の計算機で障害が発生しても、そのｍ台の計算機で開始されていたサービスを、ｍ台の待機系の計算機１００−（ｎ＋１）〜１００−（ｎ＋ｍ）へ自動的にフェイルオーバできる。つまり、図１０のｎ対ｍバックアップ構成クラスタシステムでは、ｎ≧ｍの場合には、ｍ個までのサービスを、ｍ台の待機系の計算機１００−（ｎ＋１）〜１００−（ｎ＋ｍ）へフェイルオーバできる。また、ｎ＜ｍの場合には、ｎ個までのサービスを、ｍ台の待機系の計算機１００−（ｎ＋１）〜１００−（ｎ＋ｍ）のうちのｎ台へフェイルオーバできる。
【００９８】
このように本発明の第３の実施形態においては、サービス関係情報ＤＢ１２１ａを利用すると共に、全てのサービス間（サービスの組み合わせ）の関係について、当該サービス関係情報ＤＢ１２１ａにて、いずれも、サービス間の関係の種類＝排他関係、サービス間の属性＝強い関係、サービス間の適用範囲＝局所的関係と定義することにより、ｎ対ｍバックアップ構成を実現できる。この第３の実施形態は、前記第１の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせたものであり、従来のｎ対ｍバックアップ構成のクラスタシステムに比べ、設定が簡単で且つ統一的といえる。
【００９９】
［第４の実施形態］
次に本発明の第４の実施形態について説明する。この第４の実施形態の特徴は、前記第２の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのコールドバックアップを実現している点にある。したがって、クラスタシステムの構成については、図１及び図８を援用する。
【０１００】
データのコールドバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させてデータのバックアップをとる操作をいう。つまり、バックアップ処理中にデータへのアクセスが発生しないバックアップ形態をデータのコールドバックアップと呼ぶ。
【０１０１】
従来のクラスタシステムでコールドバックアップを実現するには、まずデータにアクセスするサービスを停止してから、データをバックアップする処理を実行し、その後再びデータにアクセスするサービスを開始するという操作を、ユーザが行う必要がある。また従来のクラスタシステムでは、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第４の実施形態では、第２の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【０１０２】
図１２は、本発明の第４の実施形態で適用される、（図１のクラスタシステム１中のシナリオ管理機構１２に代えて用いられる）図８の構成のシナリオ管理機構１２０が有するサービス関係情報ＤＢ１２１ａの一例を示す。この第４の実施形態では、図１２のサービス関係情報ＤＢ１２１ａに登録されるサービスとして、以下に示す３つのサービス
・データに相当するサービス（データそれ自体）
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第２の実施形態で適用されたバッチジョブ型のサービスとする。
【０１０３】
図１２に示すサービス関係情報ＤＢ１２１ａでは、サービス間の関係として、サービス間の関係＃１乃至＃３の３種が定義される。このサービス間の関係＃１乃至＃３のそれぞれについての、サービス関係情報ＤＢ１２１ａのデータ（レコード）の内容、即ちサービス名ＳＮ１，ＳＮ２、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の情報は次の通りである。
【０１０４】
（サービス間の関係＃１）
まず、サービス間の関係＃１についての情報は、
・サービス名ＳＮ１…データにアクセスするサービス
・サービス名ＳＮ２…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
である。
【０１０５】
（サービス間の関係＃２）
次に、サービス間の関係＃２についての情報は、
・サービス名ＳＮ１…データをバックアップするサービス
・サービス名ＳＮ２…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
（サービス間の関係＃３）
最後に、サービス間の関係＃３についての情報は、
・サービス名ＳＮ１…データにアクセスするサービス
・サービス名ＳＮ２…データをバックアップするサービス
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。
【０１０６】
次に、本発明の第４の実施形態におけるデータのコールドバックアップについて、図１及び図８の構成並びに図３及び図９のフローチャートを援用して説明する。但し、図１中のシナリオ管理機構１２に代えて、図８の構成のシナリオ管理機構１２０が用いられているものとする。
【０１０７】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係＃１により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係＃１により、同一の計算機で開始される。ここでは、上記両サービスは、図１のクラスタシステム中の計算機１０−１で開始されるものとする。
【０１０８】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図８に示したシナリオ管理機構１２０内の操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【０１０９】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係＃２に従い、当該「許可」となった「データをバックアップするサービス」を、「データに相当するサービス」が開始されている計算機１０−１で開始させる（図３ステップＳ２〜Ｓ１０）。この状態で、自動制御部１２２ｃはサービス間の関係＃３に従い、計算機１０−１で開始されている「データにアクセスするサービス」を停止させる。
【０１１０】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、上記の例のように、「データをバックアップするサービス」が計算機１０−１で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部１２２ｇにより直ちに「不許可」にされる（図９ステップＳ６２〜Ｓ６５）。すると自動制御部１２２ｃは、計算機１０−１での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【０１１１】
さて、計算機１０−１での「データをバックアップするサービス」が停止されると、「データにアクセスするサービス」が開始していることがサービス間の関係＃３に違反しなくなる。このため、自動制御部１２２ｃは、「データにアクセスするサービス」を再び開始させる（図３ステップＳ７〜Ｓ９）。
【０１１２】
このように本発明の第４の実施形態においては、サービス関係情報ＤＢ１２１ａを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データをバックアップするサービス」と「データにアクセスするサービス」との間に強い排他関係を大局的関係として設定することにより、データのコールドバックアップを実現できる。この第４の実施形態は、前記第２の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせて応用したものであり、従来のクラスタシステムを用いてデータのコールドバックアップを実現するのに比べて、ユーザがサービスを開始したり停止したりする必要がない。更に第４の実施形態では、「データをバックアップするサービス」を開始するときに、どの計算機で「データに相当するサービス」が開始されているかを明示的に指定したり、サービスを開始する順番を考慮したりする必要もない。よって第４の実施形態によるクラスタシステムは、従来のクラスタシステムより設定が簡単で且つ統一的といえる。
【０１１３】
［第５の実施形態］
次に本発明の第５の実施形態について説明する。この第５の実施形態の特徴は、前記第２の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのオンラインバックアップを実現している点にある。したがって、クラスタシステムの構成については、図１及び図８を援用する。
【０１１４】
データのオンラインバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させずにデータのバックアップをとる操作をいう。
【０１１５】
従来のクラスタシステムでオンラインバックアップを実現するには、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第５の実施形態では、第２の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【０１１６】
図１３は、本発明の第５の実施形態で適用される、（図１のクラスタシステム１中のシナリオ管理機構１２に代えて用いられる）図８の構成のシナリオ管理機構１２０が有するサービス関係情報ＤＢ１２１ａの一例を示す。この第５の実施形態では、図１３のサービス関係情報ＤＢ１２１ａに登録されるサービスとして、前記第４の実施形態と同様に、以下に示す３つのサービス
・データに相当するサービス
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第２の実施形態で適用されたバッチジョブ型のサービスとする。
【０１１７】
図１３に示すサービス関係情報ＤＢ１２１ａでは、サービス間の関係として、サービス間の関係＃１乃至＃３の３種が定義される。このサービス間の関係＃１乃至＃３のうち、サービス間の関係＃１及び＃２については、第４の実施形態におけるサービス間の関係＃１及び＃２に一致するため、説明を省略する。一方、サービス間の関係＃３は、第４の実施形態におけるサービス間の関係＃３と、サービス間の関係の種類が異なる。
【０１１８】
即ち、第５の実施形態で適用されるサービス間の関係＃３は、
・サービス名ＳＮ１…データをバックアップするサービス
・サービス名ＳＮ２…データにアクセスするサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。このように、第５の実施形態で適用されるサービス間の関係＃３は、サービス名ＳＮ１及びＳＮ２が第４の実施形態と逆となり、「サービス間の関係の種類」が「依存関係」となり、「サービス間の関係の適用範囲」が大局的関係となっている点に特徴がある。
【０１１９】
次に、本発明の第５の実施形態におけるデータのコールドバックアップについて、図１及び図８の構成並びに図３及び図９のフローチャートを援用して説明する。但し、図１中のシナリオ管理機構１２に代えて、図８の構成のシナリオ管理機構１２０が用いられているものとする。
【０１２０】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係＃１により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係＃１により、同一の計算機で開始される。ここでは、上記両サービスは、第４の実施形態と同様に、図１のクラスタシステム中の計算機１０−１で開始されるものとする。
【０１２１】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図８に示したシナリオ管理機構１２０内の操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【０１２２】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係＃２及び＃３に従い、当該「データをバックアップするサービス」を、「データに相当するサービス」及び「データにアクセスするサービス」が開始されている計算機１０−１で開始させる（図３ステップＳ２〜Ｓ１０）。
【０１２３】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、「データをバックアップするサービス」が計算機１０−１で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部１２２ｇにより直ちに「不許可」にされる（図９ステップＳ６２〜Ｓ６５）。すると自動制御部１２２ｃは、計算機１０−１での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【０１２４】
このように本発明の第５の実施形態においては、サービス関係情報ＤＢ１２１ａを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データにアクセスするサービス」に対して「データをバックアップするサービス」から強い依存関係を大局的関係として設定することにより、データのオンラインバックアップを実現できる。この第５の実施形態は、前記第２の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせて応用したものであり、前記第４の実施形態と同様に、従来のクラスタシステムを用いてデータのオンラインバックアップを実現するのに比べて、設定が簡単で且つ統一的といえる。
【０１２５】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【０１２６】
【発明の効果】
以上詳述したように本発明によれば、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。よって、クラスタシステムにより複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、ホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図。
【図２】図１中のシナリオ管理機構１２の構成を示すブロック図。
【図３】同第１の実施形態において、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理を説明するためのフローチャート。
【図４】同第１の実施形態において、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構１２の主として手動制御部１２２ｂによる処理を説明するためのフローチャート。
【図５】同第１の実施形態におけるシナリオ管理機構１２の主として自動制御部１２２ｃによるフェイルオーバ処理を説明するためのフローチャート。
【図６】同第１の実施形態におけるサービス間関係判定処理を説明するためのフローチャート。
【図７】同第１の実施形態の第１の変形例に係るクラスタシステムの構成を示すブロック図。
【図８】同第１の実施形態の第２の変形例で適用されるシナリオ管理機構の構成を示すブロック図。
【図９】同第２の変形例におけるシナリオ管理機構１２０の主としてバッチジョブ制御部１２２ｇによる処理を説明するためのフローチャート。
【図１０】本発明の第３の実施形態に係るｎ対ｍバックアップ構成クラスタシステムのブロック構成図。
【図１１】図１０のｎ対ｍバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報ＤＢ１２１ａの一例を示す図。
【図１２】本発明の第４の実施形態で適用される、データのコールドバックアップを実現するためのサービス関係情報ＤＢ１２１ａの一例を示す図。
【図１３】本発明の第５の実施形態で適用される、データのオンラインバックアップを実現するためのサービス関係情報ＤＢ１２１ａの一例を示す図。
【符号の説明】
１…クラスタシステム、１０…クラスタシステム制御機構、１０−１〜１０−Ｎ…計算機、１１−１〜１１−Ｎ…サービス実行機構、１２，１２’…シナリオ管理機構、１００−１〜１００−ｎ…稼働系計算機、１００−（ｎ＋１）〜１００−（ｎ＋ｍ）…待機系計算機、１２１…データベース部、１２１ａ…サービス関係情報ＤＢ、１２１ｂ…サービス状態情報ＤＢ、１２１ｃ…計算機状態情報ＤＢ、１２１ｄ…サービス許可状態情報ＤＢ、１２１ｅ…バッチジョブ型サービス情報ＤＢ、１２２…サービス制御部、１２２ａ…操作処理部、１２２ｂ…手動制御部、１２２ｃ…自動制御部、１２２ｄ…サービス間関係判定部、１２２ｅ…実行制御部、１２２ｇ…バッチジョブ制御部。
【図１】
2005011237.tif 000003
【図２】
2005011237.tif 000004
【図３】
2005011237.tif 000005
【図４】
2005011237.tif 000006
【図５】
2005011237.tif 000007
【図６】
2005011237.tif 000008
【図７】
2005011237.tif 000009
【図８】
2005011237.tif 000010
【図９】
2005011237.tif 000011
【図１０】
2005011237.tif 000012
【図１１】
2005011237.tif 000013
【図１２】
2005011237.tif 000014
【図１３】
2005011237.tif 000015