JP4363914B2

JP4363914B2 - Cluster system

Info

Publication number: JP4363914B2
Application number: JP2003176959A
Authority: JP
Inventors: 基起中西; 浩太郎遠藤
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2003-06-20
Filing date: 2003-06-20
Publication date: 2009-11-11
Anticipated expiration: 2023-06-20
Also published as: JP2005011237A

Description

【０００１】
【発明の属する技術分野】
本発明は、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムに係り、特に当該システムにおけるサービスの実行を制御するのに好適なクラスタシステムに関する。
【０００２】
【従来の技術】
計算機システムの目的として、その計算機システム上でアプリケーションプログラムを実行し、ユーザにサービスを提供することが従来から知られている。近年、サービスの重要性が増すにつれて、サービスが実行される計算機システムに高い可用性が求められるようになっている。
【０００３】
現在、計算機システムの可用性を高めたシステムとして、クラスタシステムが注目を集めている（例えば、非特許文献１参照）。クラスタシステムは、ネットワーク接続された複数台の計算機で構成され、それらの計算機を統一的に管理するためのクラスタシステム管理機構を備えている。クラスタシステム管理機構は、予め定義されたクラスタシステムの設定に従って、サービスの開始処理及び停止処理、並びにサービスの状態監視を制御する。
【０００４】
例えば、ホットスタンバイ型のクラスタシステムでは、クラスタシステム管理機構は、サービスを開始している計算機（稼働系計算機）で発生した障害を検出したときに、引継ぎ先の計算機（待機系計算機）でそのサービスを再開するという制御を行う。このサービスを引き継ぐための制御はフェイルオーバと呼ばれる。このフェイルオーバにより、サービスの提供不能時間が短縮され、クラスタシステムの可用性が高まる。
【０００５】
従来のクラスタシステムでは、複数のサービスを提供する場合に、２台の計算機で構成されるホットスタンバイ型のクラスタシステムを、提供するサービスの数だけ用意する形態がとられている。しかし、この形態では、提供するサービスの数がｎであるとすると、クラスタシステムを構築するのに２×ｎ台の計算機が必要になり、計算機資源が無駄になる。そこで、計算機資源を節約するために、待機系を共通化した、ｎ対１バックアップの形態をとるクラスタシステムも知られている。
【０００６】
【非特許文献１】
金子哲夫、森良哉、「クラスタソフトウェア」、東芝レビュー、Vol.54 No.12(1999)、p.18-21
【０００７】
【発明が解決しようとする課題】
上記したように、複数のサービスを提供する従来のクラスタシステムでは、ホットスタンバイ型のクラスタシステムが提供するサービスの数（ｎ）だけ用意される形態、あるいはｎ対１バックアップの形態がとられている。これらの形態は、単にホットスタンバイ型のクラスタシステムを組み合わせた形態である。このため、ホットスタンバイ型のクラスタシステムと同等なサービスの制御しかできない。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、これによりホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できるクラスタシステムを提供することにある。
【０００９】
【課題を解決するための手段】
本発明の１つの観点によれば、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムが提供される。このクラスタシステムは、サービス間関係情報記憶手段と、上記複数の計算機の各々に設けられるサービス実行手段と、サービス制御手段とを備えている。サービス間関係情報記憶手段には、複数種類のサービスのうちの相異なる２種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報が記憶される。サービス実行手段は、対応する計算機上でのサービスの開始及び停止を行う。サービス制御手段は、クラスタシステムにより提供されるサービスに関し、上記サービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御する。このサービス制御手段は、サービスの開始制御では、上記サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機のサービス実行手段に対して当該サービスの開始を指示する。また、サービス制御手段は、サービスの停止制御では、当該サービスを開始している計算機の前記サービス実行手段に対して当該サービスの停止を指示する
このように本発明においては、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。
【００１０】
ここで、上記複数種類のサービスの各々について当該サービスの許可状態を管理するためのサービス許可状態情報を記憶するサービス許可状態情報記憶手段を追加すると共に、上記サービス制御手段には、上記サービス許可状態情報の示す許可状態に対応して上記サービス間関係情報の示すサービス間の関係が合致するように、開始すべきサービス及び当該開始すべきサービスを開始する計算機、あるいは停止すべきサービス及び当該停止すべきサービスを開始している計算機を選択する自動制御手段を持たせるとよい。このようにすると、上記サービス許可状態情報の示す許可状態に対応してサービス間の関係が合致するように、どのサービスをどの計算機で開始させるか、あるいは停止させるかを自動的に決定できる。
【００１１】
更に、上記サービス実行手段によりサービスが開始された場合に、当該サービスに対応する上記サービス許可状態情報の示す許可状態を不許可にするバッチジョブ制御手段を上記サービス制御手段に持たせ、上記サービス許可状態情報の示す許可状態が不許可となった場合に、上記自動制御手段により当該サービス許可状態情報に対応するサービスの停止制御が行われる構成とするとよい。このようにすると、バッチジョブのサービスが簡単に実現できる。
【００１２】
また、上記サービス間関係情報に、サービス間の関係の種類、サービス間の関係の属性及びサービス間の関係の適用範囲を示す情報を含め、上記サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であり、上記サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、上記自動制御手段による選択の候補となる上記強い関係を満たす計算機が複数存在するときに当該サービス間の関係が成立する計算機が優先的に選択される弱い関係とが設定可能であり、上記サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能である構成とするとよい。
【００１３】
ここで、上記クラスタシステムを、固有の種類のサービスを提供するｎ台の稼働系計算機と、このｎ台の稼働系計算機のいずれかの計算機に障害が発生した場合に、当該障害発生計算機で開始されていたサービスを引き継ぐことが可能なｍ台の待機系計算機で構成し、上記サービス間関係情報記憶手段に記憶される、上記ｎ台の稼働系計算機がそれぞれ提供するサービスのうちの相異なる２種類のサービスの組み合わせ毎の全てのサービス間関係情報に、上記サービス間の関係の種類、上記サービス間の関係の属性及び上記サービス間の関係の適用範囲として、それぞれ排他関係、強い関係及び局所的関係が設定される構成とするならば、ｎ対ｍバックアップ構成を容易に実現できる。
【００１４】
また、上記クラスタシステムにより提供されるサービスとして、データに相当する第１のサービス、データをバックアップする第２のサービス及びデータにアクセスする第３のサービスの３種類のサービスが定義されると共に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、上記第１のサービスに対して上記第２のサービスと上記第３のサービスとから強い依存関係が局所的関係として設定され、上記第２のサービスと上記第３のサービスとの間に強い排他関係が大局的関係として設定される構成とするならば、データのコールドバックアップを容易に実現できる。
【００１５】
同様に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報に、上記第１のサービスに対して上記第２のサービスと上記第３のサービスとから強い依存関係が局所的関係として設定され、上記第３のサービスに対して上記第２のサービスから強い依存関係が大局的関係として設定され構成とするならば、データのオンラインバックアップを容易に実現できる。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１７】
［第１の実施形態］
図１は本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図である。同図において、クラスタシステム１は、図示せぬネットワークにより相互接続された複数の計算機、例えばＮ台の計算機１０-1（＃１），１０-2（＃２），…１０-N（＃Ｎ）を備えて構成される。クラスタシステム１は、クラスタシステム制御機構１０を有する。クラスタシステム制御機構１０は、計算機１０-1（＃１），１０-2（＃２），…１０-N（＃Ｎ）上にまたがって存在する。つまりクラスタシステム１は、計算機１０-1〜１０-Nを用いて実現されるクラスタシステム制御機構１０を有する。
【００１８】
クラスタシステム制御機構１０は、各計算機１０-i（ｉ＝１〜Ｎ）上に実現されるサービス実行機構１１-iを有する。つまり計算機１０-iはサービス実行機構１１-iを有する。サービス実行機構１１-iは、サービスの開始を行うサービス開始手段１１１-iとサービスの停止を行うサービス停止手段１１２-iとを有する。クラスタシステム制御機構１０はまた、シナリオ管理機構１２を有する。シナリオ管理機構１２は、全てのサービス実行機構１１-1〜１１-Nとの間に通信経路１３-1〜１３-Nを持つ。図１の例では、シナリオ管理機構１２は、クラスタシステム１を構成する全ての計算機１１-1〜１１-Nにまたがって存在する。シナリオ管理機構１２は、各計算機１１-1〜１１-N上で動作し、相互に通信を行うシナリオ管理部１２-1〜１２-Nによって実現される。本実施形態において、サービス実行機構１１-i及びシナリオ管理部１２-iは、それぞれ対応するソフトウェアプログラムを計算機１０-i（内の図示せぬＣＰＵ）が読み取って実行することにより実現されるものとする。
【００１９】
ここで、図１のシステム内の各要素について詳述する前に、当該システムで適用される「サービス間の関係」について説明する。サービス間の関係とは、相異なる２つのサービスの間にどのような関係があるかを定めたものである。本実施形態において適用される「サービス間の関係」を規定する要素には、
・サービス間の関係の種類
・サービス間の関係の属性
・サービス間の関係の適用範囲
がある。
【００２０】
「サービス間の関係の種類」には、
・依存関係
・排他関係
・無関係
がある。
【００２１】
「依存関係」とは、予め決められたサービスが開始しているときのみ、サービスを開始可能な関係である。例えばサービス＃１に、サービス＃２に対する依存関係が定義されている場合には、サービス＃２が既に開始しているときのみ、サービス＃１を開始可能である。換言するならば、サービス＃１とサービス＃２とが開始している状態で、サービス＃２が停止したときは、サービス＃１も停止する。
【００２２】
「排他関係」とは、サービスを開始しているときは、予め決められたサービスが開始していてはならない関係である。例えば、サービス＃１に、サービス＃２に対する排他関係が定義されている場合、サービス＃２が開始していないときのみサービス＃１は開始可能であり、サービス＃２が開始しているときはサービス＃１は開始不可能である。
【００２３】
「無関係」とは、あるサービスと別のサービスとの間に、何の関係も存在しない関係である。
「依存関係」と「排他関係」と「無関係」とは、互いに独立である。
【００２４】
次に、「サービス間の関係の属性」には、
・強い関係
・弱い関係
がある。
【００２５】
「強い関係」とは、対象となるサービス間の関係が、必ず成立しなければならない関係であることを意味する。強い関係であるサービス間の関係に違反するような、サービスの開始あるいはサービスの停止はできない。
【００２６】
「弱い関係」とは、ユーザがサービスを開始する計算機を指定せずにサービスの開始操作を行った場合に、シナリオ管理機構１２が、自動的にサービスを開始する計算機を決定するために参照される関係であることを意味する。このようなサービスの制御を、サービスの自動制御と呼ぶ。つまり、「弱い関係」は、サービスの自動制御における選択の候補となる「強い関係」を満たす計算機（選択肢）が複数あるときに、その「弱い関係」が成立する計算機が優先的に選択される関係である。ここでは、サービスを開始可能な計算機（その計算機でサービスを開始していることが、強い関係であるサービス間の関係に違反しない計算機）が複数ある場合、それらの中から、弱い関係であるサービス間の関係に違反しない計算機が、サービスを開始する計算機に決定される。
【００２７】
「サービス間の関係の適用範囲」には、
・局所的関係
・大局的関係
がある。
【００２８】
「局所的関係」とは、対象となるサービス間の関係が、同一計算機でサービスを開始しているときにのみ適用される範囲であることを意味する。「大局的関係」とは、対象となるサービス間の関係が、どの計算機でサービスを開始しているかによらずに適用される範囲であることを意味する。
【００２９】
例えば、サービス＃１とサービス＃２との間に強い排他関係が設定されていて、サービス＃１が計算機＃１で開始しているものとする。この場合、上記強い排他関係が大局的関係であればサービス＃２はいずれの計算機でも開始できず、局所的関係であればサービス＃２は計算機＃１では開始できない。
【００３０】
図２は、図１中のシナリオ管理機構１２の構成を示すブロック図である。シナリオ管理機構１２は、データベース部１２１とサービス制御部１２２とに大別される。
データベース部１２１は、サービス関係情報データベース（ＤＢ）１２１ａ、サービス状態情報データベース（ＤＢ）１２１ｂ、計算機状態情報データベース（ＤＢ）１２１ｃ、及びサービス許可状態情報データベース（ＤＢ）１２１ｄを記憶するための情報記憶部である。
【００３１】
サービス関係情報ＤＢ１２１ａは、サービス間の関係を管理するためのデータベースである。サービス関係情報ＤＢ１２１ａの１つのデータ（レコード）は、サービス名ＳＮ１、当該サービス名ＳＮ１のサービスと関係するサービスのサービス名ＳＮ２、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の５項目で構成される。
【００３２】
サービス状態情報ＤＢ１２１ｂは、サービスの状態を管理するためのデータベースである。サービス状態情報ＤＢ１２１ｂの１つのデータ（レコード）は、サービス名、計算機名、及び状態の３項目で構成される。サービス名とは、図１のクラスタシステムにより提供されるサービスの名前である。計算機名とは、サービス開始手段１１１-iを最後に実行させた計算機の名前である。状態とは、サービスが正常に開始しているかどうかを示す情報であり、「開始」、「停止」または「障害発生」の３状態を持つ。
【００３３】
計算機状態情報ＤＢ１２１ｃは、計算機の状態を管理するためのデータベースである。計算機状態情報ＤＢ１２１ｃの１つのデータ（レコード）は、計算機名及び状態の２項目で構成される。計算機名とは、図１のクラスタシステムを構成する計算機の名前である。状態とは、計算機が正常に動作しているかどうかを示す情報であり、「正常」または「異常」の２状態を持つ。
【００３４】
サービス許可状態情報ＤＢ１２１ｄは、サービスの許可状態を管理するためのデータベースである。サービス許可状態情報ＤＢ１２１ｄの１つのデータ（レコード）は、サービス名及び許可状態の２項目で構成される。サービス名とは、図１のクラスタシステムにより提供されるサービスの名前である。許可状態とは、サービスが開始していること（つまりサービスが開始状態にあること）が許可されているか許可されていないかを示し、「許可」または「不許可」の２状態を持つ。
【００３５】
サービス制御部１２２は、操作処理部１２２ａ、手動制御部１２２ｂ、自動制御部１２２ｃ、サービス間関係判定部１２２ｄ、実行制御部１２２ｅ及び障害検出部１２２ｆの各処理部を有する。
操作処理部１２２ａは、図示せぬクライアント端末（ユーザ端末）からネットワークを介して与えられるユーザからの操作内容を受け取って、その操作内容に対応するサービスの制御（ある計算機で、あるサービスを開始あるいは停止すること）を、手動制御部１２２ｂに依頼するユーザインタフェースである。
【００３６】
手動制御部１２２ｂは、操作処理部１２２ａからサービスの制御依頼（ある計算機で、あるサービスを開始あるいは停止すること）を受け取ると、そのサービスの制御が、サービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認し、実行制御部１２２ｅにその制御を依頼する。
【００３７】
自動制御部１２２ｃは、定期的にサービス許可状態情報ＤＢ１２１ｄを参照し、当該情報ＤＢ１２１ｄの変化に応じてサービスの制御を自動的に実行する。即ち自動制御部１２２ｃは、あるサービスの許可状態が「許可」になると、そのサービスを開始すること（つまり停止状態から開始状態へ遷移させること）がサービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認して、サービスを開始する計算機を決定する。自動制御部１２２ｃは、決定した計算機でサービスを開始するための制御を実行制御部１２２ｅに依頼する。また自動制御部１２２ｃは、許可状態が「不許可」になると、そのサービスを開始している計算機を特定する。自動制御部１２２ｃは、特定した計算機で開始されているサービスを停止するための制御を実行制御部１２２ｅに依頼する。
【００３８】
サービス間関係判定部１２２ｄは、手動制御部１２２ｂまたは自動制御部１２２ｃから受け取ったサービスの制御を実行することが、データベース部１２１に設定されているサービス間の関係に違反しないかどうかを判定する。
実行制御部１２２ｅは、手動制御部１２２ｂまたは自動制御部１２２ｃから受け取ったサービスの制御を、該当する計算機１０-iのサービス実行機構１１-iへ伝える。
障害検出部１２２ｆは、計算機１０-iで障害が発生したことを検出して、サービス状態情報ＤＢ１２１ｂ及び計算機状態情報ＤＢ１２１ｃを更新する。
【００３９】
次に、図１のクラスタシステムの動作について、ユーザによるサービスの開始操作に伴ってシナリオ管理機構１２が実行する処理を例に説明する。この処理は、ユーザが、サービスを開始する計算機を指定するか否かで異なる。
【００４０】
まず、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理について、図３のフローチャートを参照して説明する。
シナリオ管理機構１２内の操作処理部１２２ａは、ユーザからのあるサービス（サービス＃ｊとする）の開始操作内容をクライアント端末から受け取ると、サービス許可状態情報ＤＢ１２１ｄにアクセスし、サービス＃ｊの許可状態を「許可」にする。
【００４１】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照する（ステップＳ１）。もし、サービス＃ｊの許可状態が「許可」になったなら（ステップＳ２）、自動制御部１２２ｃは計算機状態情報ＤＢ１２１ｃを参照し、未判断の計算機があるかを調べる（ステップＳ３）。ここで、ステップＳ３の１回目では、全ての計算機が未判断である。ステップＳ３が繰り返された結果、未判断の計算機がなくなったときは、自動制御部１２２ｃは、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ４）。
【００４２】
これに対し、未判断の計算機があるときは、自動制御部１２２ｃは、未判断の計算機のうちの任意の１台を、サービス＃ｊの開始対象計算機の候補（以下、候補計算機と称する）として選択する（ステップＳ５）。ここでは、計算機１０-i（計算機＃ｉ）が候補計算機として選択されたものとする。次に自動制御部１２２ｃは、選択された候補計算機１０-iの状態が「正常」であるかを計算機状態情報ＤＢ１２１ｃをもとに調べる（ステップＳ６）。
【００４３】
もし、候補計算機１０-iの状態が正常でないならば（ステップＳ６）、自動制御部１２２ｃは当該計算機１０-iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ３）に戻る。これに対し、候補計算機１０-iの状態が正常であるならば（ステップＳ６）、自動制御部１２２ｃはサービス間関係判定部１２２ｄに問い合わせて、当該計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ７）。このサービス間関係判定部１２２ｄの処理については後述する。
【００４４】
自動制御部１２２ｃは、候補計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ７）、当該計算機１０-iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ３）に戻る。これに対し、候補計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ７）、自動制御部１２２ｃは当該計算機１０-iに対するサービス制御要求を実行制御部１２２ｅへ送る。この場合、実行制御部１２２ｅは自動制御部１２２ｃからのサービス制御要求に従い、当該要求で指定された計算機１０-i（計算機＃ｉ）のサービス実行機構１１-iに対し、サービス＃ｊの開始を行うサービス開始手段１１１-iを実行させるための命令を送る（ステップＳ８）。
【００４５】
実行制御部１２２ｅは、計算機１０-iのサービス実行機構１１-iに対し、サービス＃ｊの開始を行うサービス開始手段１１１-iを実行させるための命令を送ると、自動制御部１２２ｃに対してサービス制御要求の完了を通知する。自動制御部１２２ｃは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ９）。以上で、ユーザがサービスを開始する計算機を指定しない場合における、サービス＃ｊの開始操作に伴う処理は終了する（ステップＳ１０）。
【００４６】
次に、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構１２の主として手動制御部１２２ｂによる処理について、図４のフローチャートを参照して説明する。
シナリオ管理機構１２内の操作処理部１２２ａは、ユーザからのある計算機（以下、指定計算機と称する）１０-i（計算機＃ｉ）でのあるサービス（サービス＃ｊとする）の開始操作を受け取る、それに基づいたサービス制御要求を手動制御部１２２ｂへ送る。これにより手動制御部１２２ｂは、要求されたサービス制御の処理、つまりサービス＃ｊの開始操作に伴う処理を開始する（ステップＳ１１）。
【００４７】
まず、手動制御部１２２ｂは計算機状態情報ＤＢ１２１ｃを参照し、指定計算機１０-iの状態が正常であるかを調べる（ステップＳ１２）。もし、指定計算機１０-iの状態が正常でないならば、手動制御部１２２ｂは指定計算機１０-iでサービス＃ｊを開始できないものとして、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ１３）。これに対し、指定計算機１０-iの状態が正常であるならば、手動制御部１２２ｂは、サービス間関係判定部１２２ｄに問い合わせて、当該計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ１４）。
【００４８】
手動制御部１２２ｂは、指定計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ１４）、サービス＃ｊの開始操作に伴う処理を終了する（ステップＳ１３）。これに対し、指定計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ１４）、手動制御部１２２ｂは当該計算機１０-iに対するサービス制御要求を実行制御部１２２ｅへ送る。
【００４９】
実行制御部１２２ｅは、手動制御部１２２ｂからのサービス制御要求に従い、当該要求で指定された計算機１０-iのサービス実行機構１１-iに対し、サービス＃ｊの開始を行うサービス開始手段１１１-iを実行させるための命令を送る（ステップＳ１５）。そして実行制御部１２２ｅは、手動制御部１２２ｂに対してサービス制御要求の完了を通知する。手動制御部１２２ｂは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ１６）。以上で、ユーザがサービスを開始する計算機を指定した場合における、サービス＃ｊの開始操作に伴う処理は終了する（ステップＳ１７）。
【００５０】
次に、クラスタシステム１内の計算機で発生した障害が検出された場合に、当該障害発生計算機で開始されていたサービスをクラスタシステム１内の他の計算機で引き継ぐ（フェイルオーバする）ために実行されるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理（フェイルオーバ処理）について、図５のフローチャートを参照して説明する。
【００５１】
今、シナリオ管理機構１２内の障害検出部１２２ｆが、クラスタシステム１内のある計算機、例えば計算機１０-k（計算機＃ｋ）で発生した障害を検出したものとする。この場合、障害検出部１２２ｆは、計算機状態情報ＤＢ１２１ｃにアクセスし、障害発生計算機１０-k（計算機＃ｋ）の状態を「異常」にする。また障害検出部１２２ｆはサービス状態情報ＤＢ１２１ｂにもアクセスし、計算機名が「計算機＃ｋ」であり、且つ現在の状態が「開始」の全てのサービスついて、当該状態を「障害発生」にする。
【００５２】
シナリオ管理機構１２内の自動制御部１２２ｃは、サービス状態情報ＤＢ１２１ｂを定期的に参照する（ステップＳ２１）。もし、状態が「障害発生」であるサービスがあったならば（ステップＳ２２）、自動制御部１２２ｃは当該サービスをフェイルオーバするための処理を開始する。ここでは、サービス＃ｊの状態が「障害発生」となったことが検出されたものとする。
【００５３】
まず、自動制御部１２２ｃは計算機状態情報ＤＢ１２１ｃを参照し、未判断の計算機があるかを調べる（ステップＳ２３）。ここで、ステップＳ２３の１回目では、全ての計算機が未判断である。ステップＳ２３が繰り返された結果、未判断の計算機がなくなったときは、自動制御部１２２ｃは、サービス＃ｊをフェイルオーバするための処理を終了する（ステップＳ２４）。
【００５４】
これに対し、未判断の計算機があるときは、自動制御部１２２ｃは、未判断の計算機のうちの任意の１台を、サービス＃ｊの開始（引き継ぎ）対象計算機の候補（以下、候補計算機と称する）として選択する（ステップＳ２５）。ここでは、計算機１０-i（計算機＃ｉ）が候補計算機として選択されたものとする。次に自動制御部１２２ｃは、選択された候補計算機１０-iの状態が「正常」であるかを計算機状態情報ＤＢ１２１ｃをもとに調べる（ステップＳ２６）。
【００５５】
もし、候補計算機１０-iの状態が正常でないならば（ステップＳ２６）、自動制御部１２２ｃは当該計算機１０-iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ２３）に戻る。これに対し、候補計算機１０-iの状態が正常であるならば（ステップＳ２６）、自動制御部１２２ｃはサービス間関係判定部１２２ｄに問い合わせて、当該計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しないかを調べる（ステップＳ２７）。
【００５６】
自動制御部１２２ｃは、候補計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反しているならば（ステップＳ２７）、当該計算機１０-iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理（ステップＳ２３）に戻る。これに対し、候補計算機１０-iにおけるサービス＃ｊの開始が、サービス間の関係に違反していないならば（ステップＳ２７）、自動制御部１２２ｃは当該計算機１０-iに対するサービス制御要求を実行制御部１２２ｅへ送る。この場合、実行制御部１２２ｅは自動制御部１２２ｃからのサービス制御要求に従い、当該要求で指定された計算機１０-i（計算機＃ｉ）のサービス実行機構１１-iに対し、サービス＃ｊの開始を行うサービス開始手段１１１-iを実行させるための命令を送る（ステップＳ２８）。そして実行制御部１２２ｅは、自動制御部１２２ｃに対してサービス制御要求の完了を通知する。
【００５７】
自動制御部１２２ｃは、サービス制御要求の完了通知を受け取ると、サービス状態情報ＤＢ１２１ｂにアクセスし、サービス＃ｊの状態を「開始」にする（ステップＳ２９）。以上で、障害発生計算機１０-k（障害発生計算機＃ｋ）が開始していたサービス＃ｊをクラスタシステム１内の他の正常な計算機（ここでは計算機１０-i（計算機＃ｉ））がフェイルオーバするための処理は終了する（ステップＳ３０）。自動制御部１２２ｃは、状態が「障害発生」であるサービスがある限り、上記の処理を繰り返す。
【００５８】
次に、シナリオ管理機構１２内のサービス間関係判定部１２２ｄにより実行されるサービス間関係判定処理（つまり、着目するサービスがサービス間の関係に違反していないかを調べる処理）について、図６のフローチャートを参照して説明する。
【００５９】
今、手動制御部１２２ｂまたは自動制御部１２２ｃからサービス間関係判定部１２２ｄに対し、あるサービス＃ｊをある計算機１０-i（計算機＃ｉ）で開始してよいかという問い合わせが与えられたものとする。ここで、問い合わせられたサービス及び計算機を、それぞれ、対象サービス及び対象計算機と称する。ここでは、対象サービスはサービス＃ｊであり、対象計算機は計算機１０-i（計算機＃ｉ）であるものとする。
【００６０】
サービス間関係判定部１２２ｄは、手動制御部１２２ｂまたは自動制御部１２２ｃからの問い合わせを受け取ると、当該問い合わせで指定された対象サービス＃ｊを当該問い合わせで指定された計算機１０-i（計算機＃ｉ）で開始することに対する、サービス間の関係に違反しているかを調べるサービス間関係判定処理を開始する（ステップＳ４１）。まず、サービス間関係判定部１２２ｄはサービス関係情報ＤＢ１２１ａを参照し、当該サービス関係情報ＤＢ１２１ａ中でサービス名ＳＮ１が対象サービス＃ｊを表すデータ（レコード）を全て取得する（ステップＳ４２）。
【００６１】
次にサービス間関係判定部１２２ｄは、取得したデータの中に、サービス間の関係の種類が「排他関係」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い排他関係」であり、且つ未判断のものがあるかを調べる（ステップＳ４３）。ここで、ステップＳ４３の１回目では、全ての「強い排他関係」が未判断である。ステップＳ４３が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部１２２ｄは、後述する依存関係を調べる処理（ステップＳ５０）に進む。
【００６２】
一方、未判断の「強い排他関係」のデータがあるときは、サービス間関係判定部１２２ｄは、未判断のデータのうちの任意の１つを、サービス間関係の判定対象の候補となるデータ（以下、候補データと称する）として選択する（ステップＳ４４）。次にサービス間関係判定部１２２ｄは、サービス状態情報ＤＢ１２１ｂを参照し、サービス関係情報ＤＢ１２１ａ中の選択した候補データにおけるサービス名ＳＮ２で示されるサービスに関する情報（以下、排他対象データと称する）を取得する（ステップＳ４５）。
【００６３】
サービス間関係判定部１２２ｄは、取得した排他対象データの状態が「開始」であるかを調べる（ステップＳ４６）。もし、取得した排他対象データの状態が開始でないならば（ステップＳ４６）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ４３）に戻る。これに対し、取得した排他対象データの状態が開始であるならば、サービス間関係判定部１２２ｄは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる（ステップＳ４７）。
【００６４】
もし、取得した排他対象データのサービス間の関係の属性が局所的関係でないならば（ステップＳ４７）、サービス間関係判定部１２２ｄはサービス間の関係に違反していると決定する（ステップＳ４９）。これに対し、排他対象データのサービス間の関係の属性が局所的関係であるならば（ステップＳ４７）、サービス間関係判定部１２２ｄは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる（ステップＳ４８）。
【００６５】
もし、排他対象データに含まれている計算機名が対象計算機を表しているならば（ステップＳ４８）、サービス間関係判定部１２２ｄは、対象サービス＃ｊを計算機１０-iで開始することがサービス間の関係に違反していると決定する（ステップＳ４９）。これに対し、排他対象データに含まれている計算機名が対象計算機を表していないならば（ステップＳ４８）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ４３）に戻る。
【００６６】
さて、ステップＳ４３が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部１２２ｄは、ステップＳ４２で取得したデータの中に、サービス間の関係の種類が「依存」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い依存関係」であり、且つ未判断のものがあるかを調べる（ステップＳ５０）。ここで、ステップＳ５０の１回目では、全ての「強い依存関係」が未判断である。ステップＳ５０が繰り返された結果、未判断の「強い依存関係」のデータがなくなったときは（ステップＳ５０）、サービス間関係判定部１２２ｄは対象サービス＃ｊを計算機１０-iで開始することががサービス間の関係に違反していないと決定する（ステップＳ５１）。
【００６７】
一方、未判断の「強い依存関係」のデータがあるときは、サービス間関係判定部１２２ｄは、未判断の「強い依存関係」のデータのうちの任意の１つを、サービス間関係の判定対象の候補データとして選択する（ステップＳ５２）。次にサービス間関係判定部１２２ｄは、サービス状態情報ＤＢ１２１ｂを参照し、サービス関係情報ＤＢ１２１ａ中の選択した候補データにおけるサービス名で示されるサービスに関する情報を依存対象データとして取得する（ステップＳ５３）。
【００６８】
サービス間関係判定部１２２ｄは、取得した依存対象データの状態が「開始」であるかを調べる（ステップＳ５４）。もし、取得した依存対象データの状態が開始であるならば（ステップＳ５４）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。これに対し、取得した依存対象データの状態が開始でないならば、サービス間関係判定部１２２ｄは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる（ステップＳ５５）。
【００６９】
もし、取得した依存対象データのサービス間の関係の属性が局所的関係でないならば（ステップＳ５５）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。これに対し、依存対象データのサービス間の関係の属性が局所的関係であるならば（ステップＳ５５）、サービス間関係判定部１２２ｄは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる（ステップＳ５６）。
【００７０】
もし、依存対象データに含まれている計算機名が対象計算機を表していないならば（ステップＳ５６）、サービス間関係判定部１２２ｄは、対象サービス＃ｊを計算機１０-iで開始することがサービス間の関係に違反していると決定する（ステップＳ５７）。これに対し、依存対象データに含まれている計算機名が対象計算機を表しているならば（ステップＳ５６）、サービス間関係判定部１２２ｄは当該データを判断済みとし、未判断のものがあるかを調べる処理（ステップＳ５０）に戻る。
【００７１】
このように、本発明の第１の実施形態においては、サービス関係情報ＤＢ１２１ａによりサービス間の関係を設定することにより、高度で且つ詳細なサービスの制御が実現可能となる。具体的には、順番に開始しなければいけないサービス、同時に開始してはいけないサービスを設定することにより、高度で且つ詳細なサービスの制御がクラスタシステム制御機構１０内のシナリオ管理機構１２から制御可能となる。また、本発明の第１の実施形態においては、主として自動制御部１２２ｃにより実現されるサービスの自動制御を使用することにより、ユーザに求められる判断が減少し、クラスタシステムの制御を容易にすることができる。更に本発明の第１の実施形態においては、サービスをフェイルオーバする仕組みを簡単に実現できる。
【００７２】
（第１の実施形態の第１の変形例）
図７は、本発明の第１の実施形態の第１の変形例に係るクラスタシステムの構成を示すブロック図である。なお、図７の構成において、図１と等価な部分には同一の参照符号を付してある。
【００７３】
図７に示すクラスタシステム１’の特徴は、図１中のシナリオ管理機構１２に相当するシナリオ管理機構１２’が、計算機１０-1（＃１）〜１０-N（＃Ｎ）のうちのいずれか１つの計算機、例えば計算機１０-1（＃１）上に存在する点にある。
【００７４】
本発明の第１の実施形態及びその第１の変形例から明らかなように、クラスタシステム内のシナリオ管理機構は、クラスタシステムを構成する複数の計算機のうちのいずれか１つの計算機上だけに存在しても、全ての計算機上にまたがって存在しても、２つ以上の一部の計算機上に存在しても構わない。
【００７５】
（第１の実施形態の第２の変形例）
次に、上記第１の実施形態の第２の変形例について説明する。
サービス間の関係の種類（依存関係、排他関係、無関係）と、サービス間の関係の属性（強い関係、弱い関係）とは、組み合わせることが可能である。その組み合わせの数は、以下に示す５通り、即ち
・強い依存関係
・弱い依存関係
・強い排他関係
・弱い排他関係
・無関係
となる。
【００７６】
また、上記５通りの組み合わせに、サービス間の関係の適用範囲（局所的関係、大局的関係）を組み合わせることも可能である。組み合わせの数は、以下に示す１０（５×２）通り、即ち
（１）局所的な強い依存関係
（２）局所的な弱い依存関係
（３）局所的な強い排他関係
（４）局所的な弱い排他関係
（５）局所的な無関係
（６）大局的な強い依存関係
（７）大局的な弱い依存関係
（８）大局的な強い排他関係
（９）大局的な弱い排他関係
（１０）大局的な無関係
となる。
【００７７】
したがって、サービス間の関係を設定するとき、同一のサービス間について、上記１０通りの組み合わせから幾つかを選択して同時に設定することが可能である。しかし、同時に設定される選択された組み合わせ（選択パターン）のうちの幾つかは、論理的に矛盾が生じるもの、あるいは無意味なものである。例えば、（６）の組み合わせと（８）の組み合わせとを同時に設定すると、論理的に矛盾が生じる。また、排他関係を考えてみると、（８）の組み合わせを設定しているときに（３）の組み合わせを設定することは無意味である。また、依存関係を考えてみると、（１）の組み合わせを設定しているときに（６）の組み合わせを設定することは無意味である。
【００７８】
このような、論理的に矛盾が生じる選択パターン及び無意味な選択パターンを、上記１０通りの組み合わせのうちの同時に設定可能な選択パターンの中から除いた場合、設定可能な選択パターンは以下に示す１５通り、即ち
（１）局所的な強い依存関係と大局的な強い依存関係
（２）局所的な弱い依存関係と大局的な強い依存関係
（３）局所的な弱い依存関係と大局的な弱い依存関係
（４）大局的な強い依存関係のみ
（５）大局的な弱い依存関係のみ
（６）大局的な強い依存関係と局所的な強い排他関係
（７）大局的な弱い依存関係と局所的な強い排他関係
（８）大局的な強い依存関係と局所的な弱い排他関係
（９）大局的な弱い依存関係と局所的な弱い排他関係
（１０）局所的な弱い排他関係のみ
（１１）局所的な強い排他関係のみ
（１２）局所的な弱い排他関係と大局的な弱い排他関係
（１３）局所的な強い排他関係と大局的な弱い排他関係
（１４）局所的な強い排他関係と大局的な強い排他関係
（１５）無関係のみ
となる。
【００７９】
このように、本発明の第１の実施形態の第２の変形例においては、サービス間の関係の種類、その属性、及びその適用範囲の組み合わせのうちから、幾つかを選択してサービス関係情報ＤＢ１２１ａに設定するとき、論理的に矛盾が生じる選択パターンと論理的に無意味な選択パターンとを予め除いておくことで、論理的に正しいサービス間の関係を効率よく設定可能となる。
【００８０】
［第２の実施形態］
次に本発明の第２の実施形態について説明する。
図８は図１のクラスタシステム内で、図２の構成のシナリオ管理機構１２に代えて用いられるシナリオ管理機構１２０の構成を示すブロック図である。なお、図８の構成において、図２と等価な部分には同一の参照符号を付してある。
【００８１】
図８の構成のシナリオ管理機構１２０の特徴は、バッチジョブが実現可能な構成を有している点にある。バッチジョブとは、予め定められた一連の処理を実行し、その処理の終了をもってジョブの終了とする方式のジョブである。従来のクラスタシステムでは、サービスを停止させるには、必ずユーザによる操作が必要であるため、バッチジョブのような自動的に終了する処理をサービスとして実現することが困難であった。
【００８２】
図８のシナリオ管理機構１２０はバッチジョブ制御部１２２ｇを有する。このシナリオ管理機構１２０の構成は、図２のシナリオ管理機構１２に、バッチジョブ制御部１２２ｇが追加された構成と等価である。バッチジョブ制御部１２２ｇはバッチジョブ型サービス情報ＤＢ１２１ｅを有する。このバッチジョブ型サービス情報ＤＢ１２１ｅは、バッチジョブとして扱うサービス（バッチジョブ型サービス）のデータベースである。バッチジョブ型サービス情報ＤＢ１２１ｅの１つのデータ（レコード）は、サービス名及び状態の２項目で構成される。サービス名とは、クラスタシステムにより提供されるバッチジョブ型サービスの名前である。状態とは、バッチジョブ型サービスが実行中かどうかを示す情報であり、「実行中」または「停止」の２状態を持つ。
【００８３】
次に、図８に示した構成のシナリオ管理機構１２０の主としてバッチジョブ制御部１２２ｇによる処理について、あるバッチジョブ型サービス（サービス＃ｊとする）を扱う処理を例に、図９のフローチャートを参照して説明する。
まず、バッチジョブ型サービス情報ＤＢ１２１ｅには、サービス名がサービス＃ｊで状態が「停止」のデータ（レコード）が設定されているものとする。この状態で、操作処理部１２２ａが、ユーザからのサービス＃ｊの開始操作を受け取ったものとする。すると操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスして、サービス＃ｊの許可状態を「許可」にする。
【００８４】
バッチジョブ制御部１２２ｇは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照し、その都度サービス＃ｊに関するデータを取得する（ステップＳ６１）。もし、サービス許可状態情報ＤＢ１２１ｄから取得したサービス＃ｊの許可状態が「許可」になったならば（ステップＳ６２）、バッチジョブ制御部１２２ｇはバッチジョブ型サービス情報ＤＢ１２１ｅにアクセスしてサービス＃ｊの状態を「実行中」にする（ステップＳ６３）。
【００８５】
次にバッチジョブ制御部１２２ｇは定期的にサービス状態情報ＤＢ１２１ｂを参照して、サービス＃ｊに関するデータ（レコード）を取得する。一方、自動制御部１２２ｃは、この例のように、サービス＃ｊの許可状態が「許可」となった場合、当該サービス＃ｊの開始処理を実行し、その最後でサービス状態情報ＤＢ１２１ｂにアクセスして、サービス＃ｊの状態を「開始」にする。
【００８６】
バッチジョブ制御部１２２ｇは、サービス状態情報ＤＢ１２１ｂ中のサービス＃ｊの状態が「開始」になると（ステップＳ６４）、サービス許可状態情報ＤＢ１２１ｄにアクセスして、当該サービス＃ｊの許可状態を「不許可」にする（ステップＳ６５）。自動制御部１２２ｃは、サービス＃ｊの許可状態が「不許可」になると、当該サービス＃ｊを停止する処理を実行し、その最後でサービス状態情報ＤＢ１２１ｂにアクセスして、当該サービス＃ｊの状態を「停止」にする。
【００８７】
バッチジョブ制御部１２２ｇは、サービス状態情報ＤＢ１２１ｂ中のサービス＃ｊの状態が「停止」になると（ステップＳ６６）、バッチジョブ型サービス情報ＤＢ１２１ｅにアクセスして、当該サービス＃ｊの状態を停止にする（ステップＳ６７）。以上でサービス＃ｊのバッチジョブ処理は終了する（ステップＳ６７）。
【００８８】
このように本発明の第２の実施形態においては、バッチジョブ制御部１２２ｇを備えたシナリオ管理機構１２０を用いることにより、サービスをバッチジョブとして扱うことが可能となる。これにより、例えばデータのバックアップのようなバッチジョブとして扱うのに適した処理を、シナリオ管理機構１２０によって制御可能となる。
【００８９】
［第３の実施形態］
次に本発明の第３の実施形態について説明する。
図１０は本発明の第３の実施形態に係るクラスタシステム（ｎ対ｍバックアップ構成クラスタシステム）の構成を示すブロック図である。この図１０のｎ対ｍバックアップ構成クラスタシステムの特徴は、従来から知られているｎ対ｍ（ｎは２以上の整数、ｍは１以上の整数）バックアップ構成を、前記第１の実施形態で適用されたクラスタシステムを応用して実現している点にある。
【００９０】
図１０のｎ対ｍバックアップ構成クラスタシステムは、ｎ個の１対ｍバックアップ構成クラスタシステム１-1（＃１），１-2（＃２），…１-n（＃ｎ）から構成されている。クラスタシステム１-1（＃１），１-2（＃２），…１-n（＃ｎ）は、それぞれ、稼働系計算機として用いられる計算機１００-1（＃１），１００-2（＃２），…１００-n（＃ｎ）を備えている。計算機１００-1（＃１），１００-2（＃２），…１００-n（＃ｎ）は、それぞれサービス＃１，＃２，…＃ｎを提供する。クラスタシステム１-1（＃１），１-2（＃２），…１-n（＃ｎ）は、当該クラスタシステム１-1（＃１），１-2（＃２），…１-n（＃ｎ）内の稼働系計算機１００-1（＃１），１００-2（＃２），…１００-n（＃ｎ）に対応して共通に設けられ、待機系計算機として用いられるｍ台の計算機１００-(n+1)（＃ｎ＋１），１００-（n+2)（＃ｎ＋２），…１００-(n+m)（＃ｎ＋ｍ）を備えている。クラスタシステム１-1（＃１）〜１-n（＃ｎ）内の稼働系計算機１００-1（＃１）〜１００-n（＃ｎ）、及びクラスタシステム１-1（＃１）〜１-n（＃ｎ）に共通の待機系計算機１００-(n+1)（＃ｎ＋１）〜１００-(n+m)（＃ｎ＋ｍ）は、図示せぬネットワークにより相互接続されている。
【００９１】
このように、図１０に示したｎ対ｍバックアップ構成クラスタシステムは、計算機資源を節約するためにｍ台の計算機１００-(n+1)（＃ｎ＋１）〜１００-(n+m)（＃ｎ＋ｍ）をいずれも待機系計算機として共通に使用する、ｎ個の１対ｍバックアップ構成クラスタシステム１-1（＃１）〜１-n（＃ｎ）から構成される。このｎ対ｍバックアップ構成クラスタシステムでは、サービス＃１〜＃ｎを提供するｎ台の稼働系計算機１００-1〜１００-nのうちのいずれかで障害が発生した場合に、その計算機が提供していたサービスを、ｍ台の計算機１００-(n+1)〜１００-(n+m)のいずれかで引き継ぐことが可能なように構成されている。図１０のｎ対ｍバックアップ構成クラスタシステムの構成は、ｎ個の１対ｍバックアップ構成クラスタシステム１-1（＃１）〜１-n（＃ｎ）を備えている点を除けば、前記第１の実施形態におけるクラスタシステムと同様である。即ち図１０のｎ対ｍバックアップ構成クラスタシステムは、計算機１００-1（＃１）〜１００-(n+m)（＃ｎ＋ｍ）毎に設けられるサービス実行機構と図２の構成のシナリオ管理機構とを含むクラスタシステム制御機構（いずれも図示せず）を有している。したがって、第３の実施形態では、必要に応じて図２を援用する。
【００９２】
従来技術では、ｎ対ｍバックアップ構成の計算機システムを実現するためには、ｎ個のサービス＃１〜＃ｎ全てに対して、どの計算機で開始し、障害発生時にはどの計算機へ引き継ぐのかを、同じ計算機にサービスが集中しないように注意しながら設定する必要がある。これに対して、本発明の第３の実施形態では、前記第１の実施形態で適用されたクラスタシステムを用いることにより、この種の設定が以下に述べるように簡単に行える。
【００９３】
図１１は、図１０のｎ対ｍバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報ＤＢ１２１ａの一例を示す。この図１１のサービス関係情報ＤＢ１２１ａには、図１０のｎ対ｍバックアップ構成クラスタシステムにより提供されるｎ個のサービスのうちのサービス＃ｉ（ｉ＝１〜ｎ−１）と他のサービス＃ｊ（ｊ＝ｉ＋１〜ｎ）との全ての組み合わせについて、その組み合わせのサービスを表すサービス名（ＳＮ１，ＳＮ２）、サービス（＃ｉ，＃ｊ）間の関係の種類、サービス（＃ｉ，＃ｊ）間の関係の属性、及びサービス（＃ｉ，＃ｊ）間の関係の適用範囲の情報が登録されている。ここでは、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲は、サービスの組み合わせに無関係に、
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
のように設定される。
【００９４】
次に、図１１に示すサービス関係情報ＤＢ１２１ａを適用した図１０のｎ対ｍバックアップ構成クラスタシステムの動作を、図２の構成及び図５のフローチャートを援用して説明する。
図２に示すシナリオ管理機構１２中の操作処理部１２２ａは、ユーザによるｎ個のサービス＃１〜＃ｎの開始操作を受け取ると、サービス許可状態情報ＤＢ１２１ｄにアクセスし、ｎ個のサービス＃１〜＃ｎの許可状態をいずれも「許可」にする。自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄ中のサービス＃１〜＃ｎの許可状態が「許可」になったなら、そのサービス＃１〜＃ｎを、サービス関係情報ＤＢ１２１ａにより示されるサービス間の関係に従い、ｎ対ｍバックアップ構成クラスタシステムを構成するｎ＋ｍ台の計算機のうちのｎ台の稼働系計算機１００-1（＃１）〜１００-n（＃ｎ）で１サービスずつ開始させる。ここでは、計算機１００-i（＃ｉ）でサービス＃ｉが開始されるものとする。
【００９５】
この状態で、例えば計算機１００-1（＃１）で障害が発生したために、当該計算機１００-1で開始していたサービス＃１をフェイルオーバするものとする。このフェイルオーバ処理は、前記第１の実施形態と同様に、自動制御部１２２ｃにより図５のフローチャートに従って実行される。即ち自動制御部１２２ｃは、サービス状態情報ＤＢ１２１ｂを参照することで、サービス＃１を開始していた計算機１００-1で障害が発生したことを検出すると（図５ステップＳ２１，Ｓ２２）、当該サービス＃１を引き継ぐ計算機を、図５のステップＳ２３から始まる一連の処理（ステップＳ２３，Ｓ２５〜Ｓ２７）により決定する。ここでは、計算機状態情報ＤＢ１２１ｃの示す計算機状態及びサービス関係情報ＤＢ１２１ａの示すサービス間の関係をもとに、図１０のｎ対ｍバックアップ構成クラスタシステム内のｎ＋ｍ台の計算機の中から、サービス＃１の開始がサービス間の関係に違反しない正常な計算機が１つ選択される。図１１に示すサービス関係情報ＤＢ１２１ａの例では、サービス＃１の開始がサービス間の関係に違反しない計算機は、サービスを開始していない待機系の計算機１００-(n+1)〜１００-(n+m)であり、そのうちの計算機１００-(n+1)が選択されたものとする。この場合、計算機１００-(n+1)によりサービス＃１が開始される（引き継がれる）。
【００９６】
更に、この状態で計算機１００-2で障害が発生し、当該計算機１００-2で開始していたサービス＃２をフェイルオーバするものとする。この場合も上記と同様に、自動制御部１２２ｃにより引継ぎ先の計算機が決定される。ここでは、稼働系の計算機１００-1〜１００-nとサービス＃１を引き継いだ計算機１００-(n+1)とを除くｍ−１台の計算機１００-(n+2)〜１００-(n+m)のうちの１つ、例えば計算機１００-(n+2)が引継ぎ先の計算機として選択され、当該計算機１００-(n+2)でサービス＃２が開始される（引き継がれる）ものとする。
【００９７】
以下、同様の制御により、ｎ≧ｍの場合には、計算機１００-1〜１００-nのうちのｍ台の計算機で障害が発生しても、そのｍ台の計算機で開始されていたサービスを、ｍ台の待機系の計算機１００-(n+1)〜１００-(n+m)へ自動的にフェイルオーバできる。つまり、図１０のｎ対ｍバックアップ構成クラスタシステムでは、ｎ≧ｍの場合には、ｍ個までのサービスを、ｍ台の待機系の計算機１００-(n+1)〜１００-(n+m)へフェイルオーバできる。また、ｎ＜ｍの場合には、ｎ個までのサービスを、ｍ台の待機系の計算機１００-(n+1)〜１００-(n+m)のうちのｎ台へフェイルオーバできる。
【００９８】
このように本発明の第３の実施形態においては、サービス関係情報ＤＢ１２１ａを利用すると共に、全てのサービス間（サービスの組み合わせ）の関係について、当該サービス関係情報ＤＢ１２１ａにて、いずれも、サービス間の関係の種類＝排他関係、サービス間の属性＝強い関係、サービス間の適用範囲＝局所的関係と定義することにより、ｎ対ｍバックアップ構成を実現できる。この第３の実施形態は、前記第１の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせたものであり、従来のｎ対ｍバックアップ構成のクラスタシステムに比べ、設定が簡単で且つ統一的といえる。
【００９９】
［第４の実施形態］
次に本発明の第４の実施形態について説明する。この第４の実施形態の特徴は、前記第２の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのコールドバックアップを実現している点にある。したがって、クラスタシステムの構成については、図１及び図８を援用する。
【０１００】
データのコールドバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させてデータのバックアップをとる操作をいう。つまり、バックアップ処理中にデータへのアクセスが発生しないバックアップ形態をデータのコールドバックアップと呼ぶ。
【０１０１】
従来のクラスタシステムでコールドバックアップを実現するには、まずデータにアクセスするサービスを停止してから、データをバックアップする処理を実行し、その後再びデータにアクセスするサービスを開始するという操作を、ユーザが行う必要がある。また従来のクラスタシステムでは、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第４の実施形態では、第２の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【０１０２】
図１２は、本発明の第４の実施形態で適用される、（図１のクラスタシステム１中のシナリオ管理機構１２に代えて用いられる）図８の構成のシナリオ管理機構１２０が有するサービス関係情報ＤＢ１２１ａの一例を示す。この第４の実施形態では、図１２のサービス関係情報ＤＢ１２１ａに登録されるサービスとして、以下に示す３つのサービス
・データに相当するサービス（データそれ自体）
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第２の実施形態で適用されたバッチジョブ型のサービスとする。
【０１０３】
図１２に示すサービス関係情報ＤＢ１２１ａでは、サービス間の関係として、サービス間の関係＃１乃至＃３の３種が定義される。このサービス間の関係＃１乃至＃３のそれぞれについての、サービス関係情報ＤＢ１２１ａのデータ（レコード）の内容、即ちサービス名ＳＮ１，ＳＮ２、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の情報は次の通りである。
【０１０４】
（サービス間の関係＃１）
まず、サービス間の関係＃１についての情報は、
・サービス名ＳＮ１…データにアクセスするサービス
・サービス名ＳＮ２…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
である。
【０１０５】
（サービス間の関係＃２）
次に、サービス間の関係＃２についての情報は、
・サービス名ＳＮ１…データをバックアップするサービス
・サービス名ＳＮ２…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
（サービス間の関係＃３）
最後に、サービス間の関係＃３についての情報は、
・サービス名ＳＮ１…データにアクセスするサービス
・サービス名ＳＮ２…データをバックアップするサービス
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。
【０１０６】
次に、本発明の第４の実施形態におけるデータのコールドバックアップについて、図１及び図８の構成並びに図３及び図９のフローチャートを援用して説明する。但し、図１中のシナリオ管理機構１２に代えて、図８の構成のシナリオ管理機構１２０が用いられているものとする。
【０１０７】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係＃１により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係＃１により、同一の計算機で開始される。ここでは、上記両サービスは、図１のクラスタシステム中の計算機１０-1で開始されるものとする。
【０１０８】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図８に示したシナリオ管理機構１２０内の操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【０１０９】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係＃２に従い、当該「許可」となった「データをバックアップするサービス」を、「データに相当するサービス」が開始されている計算機１０-1で開始させる（図３ステップＳ２〜Ｓ１０）。この状態で、自動制御部１２２ｃはサービス間の関係＃３に従い、計算機１０-1で開始されている「データにアクセスするサービス」を停止させる。
【０１１０】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、上記の例のように、「データをバックアップするサービス」が計算機１０-1で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部１２２ｇにより直ちに「不許可」にされる（図９ステップＳ６２〜Ｓ６５）。すると自動制御部１２２ｃは、計算機１０-1での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【０１１１】
さて、計算機１０-1での「データをバックアップするサービス」が停止されると、「データにアクセスするサービス」が開始していることがサービス間の関係＃３に違反しなくなる。このため、自動制御部１２２ｃは、「データにアクセスするサービス」を再び開始させる（図３ステップＳ７〜Ｓ９）。
【０１１２】
このように本発明の第４の実施形態においては、サービス関係情報ＤＢ１２１ａを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データをバックアップするサービス」と「データにアクセスするサービス」との間に強い排他関係を大局的関係として設定することにより、データのコールドバックアップを実現できる。この第４の実施形態は、前記第２の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせて応用したものであり、従来のクラスタシステムを用いてデータのコールドバックアップを実現するのに比べて、ユーザがサービスを開始したり停止したりする必要がない。更に第４の実施形態では、「データをバックアップするサービス」を開始するときに、どの計算機で「データに相当するサービス」が開始されているかを明示的に指定したり、サービスを開始する順番を考慮したりする必要もない。よって第４の実施形態によるクラスタシステムは、従来のクラスタシステムより設定が簡単で且つ統一的といえる。
【０１１３】
［第５の実施形態］
次に本発明の第５の実施形態について説明する。この第５の実施形態の特徴は、前記第２の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのオンラインバックアップを実現している点にある。したがって、クラスタシステムの構成については、図１及び図８を援用する。
【０１１４】
データのオンラインバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させずにデータのバックアップをとる操作をいう。
【０１１５】
従来のクラスタシステムでオンラインバックアップを実現するには、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第５の実施形態では、第２の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【０１１６】
図１３は、本発明の第５の実施形態で適用される、（図１のクラスタシステム１中のシナリオ管理機構１２に代えて用いられる）図８の構成のシナリオ管理機構１２０が有するサービス関係情報ＤＢ１２１ａの一例を示す。この第５の実施形態では、図１３のサービス関係情報ＤＢ１２１ａに登録されるサービスとして、前記第４の実施形態と同様に、以下に示す３つのサービス
・データに相当するサービス
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第２の実施形態で適用されたバッチジョブ型のサービスとする。
【０１１７】
図１３に示すサービス関係情報ＤＢ１２１ａでは、サービス間の関係として、サービス間の関係＃１乃至＃３の３種が定義される。このサービス間の関係＃１乃至＃３のうち、サービス間の関係＃１及び＃２については、第４の実施形態におけるサービス間の関係＃１及び＃２に一致するため、説明を省略する。一方、サービス間の関係＃３は、第４の実施形態におけるサービス間の関係＃３と、サービス間の関係の種類が異なる。
【０１１８】
即ち、第５の実施形態で適用されるサービス間の関係＃３は、
・サービス名ＳＮ１…データをバックアップするサービス
・サービス名ＳＮ２…データにアクセスするサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。このように、第５の実施形態で適用されるサービス間の関係＃３は、サービス名ＳＮ１及びＳＮ２が第４の実施形態と逆となり、「サービス間の関係の種類」が「依存関係」となり、「サービス間の関係の適用範囲」が大局的関係となっている点に特徴がある。
【０１１９】
次に、本発明の第５の実施形態におけるデータのコールドバックアップについて、図１及び図８の構成並びに図３及び図９のフローチャートを援用して説明する。但し、図１中のシナリオ管理機構１２に代えて、図８の構成のシナリオ管理機構１２０が用いられているものとする。
【０１２０】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係＃１により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係＃１により、同一の計算機で開始される。ここでは、上記両サービスは、第４の実施形態と同様に、図１のクラスタシステム中の計算機１０-1で開始されるものとする。
【０１２１】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図８に示したシナリオ管理機構１２０内の操作処理部１２２ａは、サービス許可状態情報ＤＢ１２１ｄにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【０１２２】
自動制御部１２２ｃは、サービス許可状態情報ＤＢ１２１ｄを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係＃２及び＃３に従い、当該「データをバックアップするサービス」を、「データに相当するサービス」及び「データにアクセスするサービス」が開始されている計算機１０-1で開始させる（図３ステップＳ２〜Ｓ１０）。
【０１２３】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、「データをバックアップするサービス」が計算機１０-1で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部１２２ｇにより直ちに「不許可」にされる（図９ステップＳ６２〜Ｓ６５）。すると自動制御部１２２ｃは、計算機１０-1での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【０１２４】
このように本発明の第５の実施形態においては、サービス関係情報ＤＢ１２１ａを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データにアクセスするサービス」に対して「データをバックアップするサービス」から強い依存関係を大局的関係として設定することにより、データのオンラインバックアップを実現できる。この第５の実施形態は、前記第２の実施形態で適用されたサービス間の関係と自動制御部１２２ｃによるサービスの自動制御とを組み合わせて応用したものであり、前記第４の実施形態と同様に、従来のクラスタシステムを用いてデータのオンラインバックアップを実現するのに比べて、設定が簡単で且つ統一的といえる。
【０１２５】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【０１２６】
【発明の効果】
以上詳述したように本発明によれば、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。よって、クラスタシステムにより複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、ホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図。
【図２】図１中のシナリオ管理機構１２の構成を示すブロック図。
【図３】同第１の実施形態において、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構１２の主として自動制御部１２２ｃによる処理を説明するためのフローチャート。
【図４】同第１の実施形態において、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構１２の主として手動制御部１２２ｂによる処理を説明するためのフローチャート。
【図５】同第１の実施形態におけるシナリオ管理機構１２の主として自動制御部１２２ｃによるフェイルオーバ処理を説明するためのフローチャート。
【図６】同第１の実施形態におけるサービス間関係判定処理を説明するためのフローチャート。
【図７】同第１の実施形態の第１の変形例に係るクラスタシステムの構成を示すブロック図。
【図８】同第１の実施形態の第２の変形例で適用されるシナリオ管理機構の構成を示すブロック図。
【図９】同第２の変形例におけるシナリオ管理機構１２０の主としてバッチジョブ制御部１２２ｇによる処理を説明するためのフローチャート。
【図１０】本発明の第３の実施形態に係るｎ対ｍバックアップ構成クラスタシステムのブロック構成図。
【図１１】図１０のｎ対ｍバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報ＤＢ１２１ａの一例を示す図。
【図１２】本発明の第４の実施形態で適用される、データのコールドバックアップを実現するためのサービス関係情報ＤＢ１２１ａの一例を示す図。
【図１３】本発明の第５の実施形態で適用される、データのオンラインバックアップを実現するためのサービス関係情報ＤＢ１２１ａの一例を示す図。
【符号の説明】
１…クラスタシステム、１０…クラスタシステム制御機構、１０-1〜１０-N…計算機、１１-1〜１１-N…サービス実行機構、１２，１２’…シナリオ管理機構、１００-1〜１００-n…稼働系計算機、１００-(n+1)〜１００-(n+m)…待機系計算機、１２１…データベース部、１２１ａ…サービス関係情報ＤＢ、１２１ｂ…サービス状態情報ＤＢ、１２１ｃ…計算機状態情報ＤＢ、１２１ｄ…サービス許可状態情報ＤＢ、１２１ｅ…バッチジョブ型サービス情報ＤＢ、１２２…サービス制御部、１２２ａ…操作処理部、１２２ｂ…手動制御部、１２２ｃ…自動制御部、１２２ｄ…サービス間関係判定部、１２２ｅ…実行制御部、１２２ｇ…バッチジョブ制御部。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a cluster system composed of a plurality of computers and capable of providing a plurality of types of services, and is particularly suitable for controlling execution of services in the systems. Cluster system About.
[0002]
[Prior art]
As an object of a computer system, it is conventionally known that an application program is executed on the computer system to provide a service to a user. In recent years, as the importance of services has increased, high availability has been demanded of computer systems on which services are executed.
[0003]
Currently, cluster systems are attracting attention as systems that increase the availability of computer systems (see, for example, Non-Patent Document 1). The cluster system is composed of a plurality of computers connected to the network, and includes a cluster system management mechanism for uniformly managing these computers. The cluster system management mechanism controls service start processing and stop processing, and service status monitoring in accordance with pre-defined cluster system settings.
[0004]
For example, in a hot standby type cluster system, when the cluster system management mechanism detects a failure that has occurred in the computer that has started the service (active computer), the service is executed on the takeover destination computer (standby computer). Control to resume. Control for taking over this service is called failover. This failover shortens the service unavailable time and increases the availability of the cluster system.
[0005]
In a conventional cluster system, when a plurality of services are provided, a hot standby type cluster system including two computers is prepared for the number of services to be provided. However, in this embodiment, if the number of services to be provided is n, 2 × n computers are required to construct a cluster system, and computer resources are wasted. Therefore, a cluster system in the form of an n-to-1 backup with a common standby system is also known in order to save computer resources.
[0006]
[Non-Patent Document 1]
Tetsuo Kaneko, Yoshiya Mori, "Cluster Software", Toshiba Review, Vol.54 No.12 (1999), p.18-21
[0007]
[Problems to be solved by the invention]
As described above, in the conventional cluster system that provides a plurality of services, the number of services (n) provided by the hot standby type cluster system is prepared, or the form of n-to-1 backup is used. . These forms are simply combinations of hot standby type cluster systems. For this reason, only control of services equivalent to that of a hot standby type cluster system can be performed.
[0008]
The present invention has been made in view of the above circumstances, and its purpose is to optimize the system availability, the effective use of computer resources, and the improvement of service processing capacity when providing a plurality of services. Services can be placed on computers, which enables more advanced service control than hot standby cluster systems Cluster system Is to provide.
[0009]
[Means for Solving the Problems]
According to one aspect of the present invention, a cluster system that includes a plurality of computers and can provide a plurality of types of services is provided. This cluster system includes inter-service relationship information storage means, service execution means provided in each of the plurality of computers, and service control means. The inter-service relationship information storage unit stores inter-service relationship information in which the relationship between services is defined in advance for each combination of two different types of services among a plurality of types of services. The service execution means starts and stops the service on the corresponding computer. The service control unit controls the start or stop of the service provided by the cluster system so as to match the inter-service relationship indicated by the inter-service relationship information. In the service start control, the service control means selects a computer capable of providing the service that matches the inter-service relation indicated by the inter-service relation information, and sends the service to the service execution means of the computer. Instruct the start of. In the service stop control, the service control means instructs the service execution means of the computer that has started the service to stop the service.
As described above, according to the present invention, the service provided by the cluster system is started or stopped so as to match the service relationship indicated by the service relationship information stored in the service relationship information storage unit. By controlling, it is possible to realize advanced and detailed service control that matches the relationship between services.
[0010]
Here, for each of the plurality of types of services, a service permission state information storage unit for storing service permission state information for managing a permission state of the service is added, and the service control unit includes the service permission state information The service to be started and the computer that starts the service to be started, or the service to be stopped and the stop to be matched so that the relationship between the services indicated by the relationship information between services corresponds to the permission state indicated by the information. It is preferable to have an automatic control means for selecting a computer that has started a service to be performed. In this way, it is possible to automatically determine which service is to be started or stopped by which computer so that the relationship between services matches in accordance with the permission state indicated by the service permission state information.
[0011]
Further, when the service is started by the service execution means, the service control means has a batch job control means for disabling the permission state indicated by the service permission state information corresponding to the service, and the service permission is provided. When the permission state indicated by the state information is not permitted, the automatic control means may be configured to perform stop control of the service corresponding to the service permission state information. In this way, a batch job service can be easily realized.
[0012]
In addition, the service relationship information includes the information indicating the type of relationship between services, the attribute of the relationship between services, and the applicable range of the relationship between services, and a predetermined service as the type of relationship between services. It is possible to set the dependency that can start the service only when the service starts, the exclusive relationship that the predetermined service should not start when the service is started, and irrelevant. As an attribute of the relationship between the services, there is a strong relationship that the relationship between the services must be established, and a relationship between the services when there are multiple computers that satisfy the strong relationship that are candidates for selection by the automatic control means. It is possible to set a weak relationship that preferentially selects computers that satisfy the requirements. There is a local relationship in which the relationship between the services is applied only when the service is started, and a global relationship in which the relationship between the services is applied regardless of the computer on which the service is started. A configuration that can be set is preferable.
[0013]
Here, when a failure occurs in the n active computers that provide a specific type of service and one of the n active computers, the cluster system starts with the failure occurrence computer. 2 of the services provided by the n active computers stored in the inter-service relationship information storage means, each of which is composed of m standby computers capable of taking over the service that has been provided. For all service relationship information for each type of service combination, the relationship type between the services, the attribute of the relationship between the services, and the applicable range of the relationship between the services, exclusive relationship, strong relationship and local If the relationship is set, an n-to-m backup configuration can be easily realized.
[0014]
Further, as the services provided by the cluster system, three types of services are defined: a first service corresponding to data, a second service for backing up data, and a third service for accessing data. In the inter-service relationship information stored in the inter-service relationship information storage means, a strong dependency is set as a local relationship from the second service and the third service with respect to the first service, If a strong exclusive relationship is set as a global relationship between the second service and the third service, cold backup of data can be easily realized.
[0015]
Similarly, in the inter-service relationship information stored in the inter-service relationship information storage means, a strong dependence relationship is set as a local relationship from the second service and the third service with respect to the first service. If a strong dependency relationship is set as a global relationship with respect to the third service from the second service, data online backup can be easily realized.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings.
[0017]
[First Embodiment]
FIG. 1 is a block diagram showing a configuration of a cluster system according to the first embodiment of the present invention. In the figure, the cluster system 1 includes a plurality of computers interconnected by a network (not shown), for example, N computers 10-1 (# 1), 10-2 (# 2),... 10-N (#N ). The cluster system 1 has a cluster system control mechanism 10. The cluster system control mechanism 10 exists over the computers 10-1 (# 1), 10-2 (# 2),... 10-N (#N). That is, the cluster system 1 has the cluster system control mechanism 10 realized using the computers 10-1 to 10-N.
[0018]
The cluster system control mechanism 10 has a service execution mechanism 11-i realized on each computer 10-i (i = 1 to N). That is, the computer 10-i has a service execution mechanism 11-i. The service execution mechanism 11-i includes a service start unit 111-i that starts a service and a service stop unit 112-i that stops a service. The cluster system control mechanism 10 also has a scenario management mechanism 12. The scenario management mechanism 12 has communication paths 13-1 to 13-N between all the service execution mechanisms 11-1 to 11-N. In the example of FIG. 1, the scenario management mechanism 12 exists across all the computers 11-1 to 11 -N constituting the cluster system 1. The scenario management mechanism 12 is realized by scenario management units 12-1 to 12-N that operate on the computers 11-1 to 11-N and communicate with each other. In the present embodiment, the service execution mechanism 11-i and the scenario management unit 12-i are realized by the computer 10-i (a CPU (not shown)) reading and executing the corresponding software program. To do.
[0019]
Here, before describing each element in the system of FIG. 1 in detail, the “relationship between services” applied in the system will be described. The relationship between services is what defines the relationship between two different services. In the element that defines the “relationship between services” applied in this embodiment,
-Types of relationships between services
Attributes of relationships between services
・ Scope of relationship between services
There is.
[0020]
"Type of relationship between services"
・ Dependency
・ Exclusive relationship
・ Unrelated
There is.
[0021]
A “dependency relationship” is a relationship in which a service can be started only when a predetermined service is started. For example, when the service # 1 has a dependency relationship with the service # 2, the service # 1 can be started only when the service # 2 has already started. In other words, when the service # 2 is stopped while the service # 1 and the service # 2 are started, the service # 1 is also stopped.
[0022]
The “exclusive relationship” is a relationship in which a predetermined service must not be started when the service is started. For example, if an exclusive relationship with service # 2 is defined in service # 1, service # 1 can be started only when service # 2 is not started, and service # 2 is started when service # 2 is started # 1 cannot start.
[0023]
“Unrelated” is a relationship in which no relationship exists between one service and another service.
“Dependency relationship”, “exclusive relationship” and “irrelevant” are independent of each other.
[0024]
Next, the “attribute of relationship between services”
・ Strong relationship
・ Weak relationships
There is.
[0025]
“Strong relationship” means that a relationship between target services must be established. A service cannot be started or stopped in a way that violates a strong relationship between services.
[0026]
The “weak relationship” is referred to when the scenario management mechanism 12 automatically determines a computer that starts a service when a user performs a service start operation without specifying a computer that starts the service. It means that it is a relationship. Such service control is called automatic service control. In other words, the “weak relationship” is preferentially selected when there are multiple computers (options) that satisfy the “strong relationship” that are candidates for selection in automatic service control. It is a relationship. Here, if there are multiple computers that can start a service (a computer that does not violate the relationship between services that have a strong relationship that the service is started on that computer), the service that has a weak relationship among them A computer that does not violate the relationship between them is determined as the computer that starts the service.
[0027]
“Scope of relationships between services”
・ Local relationship
・ Global relationship
There is.
[0028]
The “local relationship” means that the relationship between the target services is a range that is applied only when the service is started on the same computer. The “global relationship” means that the relationship between the target services is a range that is applied regardless of which computer has started the service.
[0029]
For example, it is assumed that a strong exclusive relationship is set between the service # 1 and the service # 2, and the service # 1 starts on the computer # 1. In this case, if the strong exclusive relationship is a global relationship, service # 2 cannot be started by any computer, and if it is a local relationship, service # 2 cannot be started by computer # 1.
[0030]
FIG. 2 is a block diagram showing the configuration of the scenario management mechanism 12 in FIG. The scenario management mechanism 12 is roughly divided into a database unit 121 and a service control unit 122.
The database unit 121 is an information storage unit for storing a service related information database (DB) 121a, a service status information database (DB) 121b, a computer status information database (DB) 121c, and a service permission status information database (DB) 121d. It is.
[0031]
The service relationship information DB 121a is a database for managing relationships between services. One data (record) in the service relationship information DB 121a includes a service name SN1, a service name SN2 of a service related to the service of the service name SN1, a type of relationship between services, an attribute of a relationship between services, and an inter-service Consists of 5 items in the scope of the relationship.
[0032]
The service status information DB 121b is a database for managing the service status. One data (record) in the service status information DB 121b is composed of three items: a service name, a computer name, and a status. The service name is a name of a service provided by the cluster system in FIG. The computer name is the name of the computer that executed the service start unit 111-i last. The status is information indicating whether the service has started normally, and has three statuses of “start”, “stop”, and “failure occurrence”.
[0033]
The computer state information DB 121c is a database for managing the state of the computer. One piece of data (record) in the computer state information DB 121c is composed of two items: a computer name and a state. The computer name is a name of a computer constituting the cluster system of FIG. The state is information indicating whether the computer is operating normally, and has two states, “normal” and “abnormal”.
[0034]
The service permission state information DB 121d is a database for managing the service permission state. One piece of data (record) in the service permission state information DB 121d is composed of two items: a service name and a permission state. The service name is a name of a service provided by the cluster system in FIG. The permitted state indicates whether the service is started (that is, the service is in the started state) or not, and has two states “permitted” or “not permitted”.
[0035]
The service control unit 122 includes processing units such as an operation processing unit 122a, a manual control unit 122b, an automatic control unit 122c, an inter-service relationship determination unit 122d, an execution control unit 122e, and a failure detection unit 122f.
The operation processing unit 122a receives an operation content from a user given via a network from a client terminal (user terminal) (not shown), and controls a service corresponding to the operation content (starts a service on a certain computer or This is a user interface that requests the manual control unit 122b to stop.
[0036]
When the manual control unit 122b receives a service control request (starting or stopping a certain service by a certain computer) from the operation processing unit 122a, the control of the service is performed according to the service state, the computer state, and the service. After confirming that it is possible from the aspect of the relationship, the execution control unit 122e is requested to control it.
[0037]
The automatic control unit 122c periodically refers to the service permission state information DB 121d, and automatically executes service control according to changes in the information DB 121d. That is, when the permission state of a certain service becomes “permitted”, the automatic control unit 122c starts the service (that is, makes a transition from the stop state to the start state) to determine the service state, the computer state, and the relationship between the services. Confirm that it is possible from the aspect of this, and decide the computer to start the service. The automatic control unit 122c requests the execution control unit 122e to start control on the determined computer. Further, when the permission state becomes “not permitted”, the automatic control unit 122c identifies the computer that has started the service. The automatic control unit 122c requests the execution control unit 122e to perform control for stopping the service started by the specified computer.
[0038]
The inter-service relationship determination unit 122d determines whether executing the control of the service received from the manual control unit 122b or the automatic control unit 122c does not violate the relationship between services set in the database unit 121.
The execution control unit 122e transmits the service control received from the manual control unit 122b or the automatic control unit 122c to the service execution mechanism 11-i of the corresponding computer 10-i.
The failure detection unit 122f detects that a failure has occurred in the computer 10-i, and updates the service state information DB 121b and the computer state information DB 121c.
[0039]
Next, the operation of the cluster system in FIG. 1 will be described by taking as an example processing executed by the scenario management mechanism 12 in accordance with a service start operation by the user. This process differs depending on whether or not the user designates a computer for starting a service.
[0040]
First, processing by the automatic control unit 122c of the scenario management mechanism 12 when the user does not designate a computer for starting a service will be described with reference to the flowchart of FIG.
When the operation processing unit 122a in the scenario management mechanism 12 receives from the client terminal the start operation content of a certain service (service #j) from the user, the operation processing unit 122a accesses the service permission state information DB 121d and determines the permission state of the service #j. Set to "Allow".
[0041]
The automatic control unit 122c periodically refers to the service permission state information DB 121d (step S1). If the permission state of the service #j becomes “permitted” (step S2), the automatic control unit 122c refers to the computer state information DB 121c and checks whether there is an undetermined computer (step S3). Here, in the first time of step S3, all the computers are undecided. As a result of repeating step S3, when there are no more undetermined computers, the automatic control unit 122c ends the process associated with the start operation of the service #j (step S4).
[0042]
On the other hand, when there is an undetermined computer, the automatic control unit 122c sets any one of the undetermined computers as a candidate for a computer to be started for service #j (hereinafter referred to as a candidate computer). Select (step S5). Here, it is assumed that the computer 10-i (computer #i) is selected as a candidate computer. Next, the automatic control unit 122c checks whether the state of the selected candidate computer 10-i is “normal” based on the computer state information DB 121c (step S6).
[0043]
If the candidate computer 10-i is not in a normal state (step S6), the automatic control unit 122c uses the computer 10-i as a determined computer, and checks whether there is an undetermined computer as described above (step S6). Return to S3). On the other hand, if the status of the candidate computer 10-i is normal (step S6), the automatic control unit 122c inquires the inter-service relationship determination unit 122d and the start of service #j in the computer 10-i is It is checked whether the relationship between services is violated (step S7). The process of the inter-service relationship determination unit 122d will be described later.
[0044]
If the start of the service #j in the candidate computer 10-i violates the relationship between services (step S7), the automatic control unit 122c determines that the computer 10-i is a determined computer, and The process returns to the process of checking whether there is a judgment computer (step S3). On the other hand, if the start of the service #j in the candidate computer 10-i does not violate the relationship between services (step S7), the automatic control unit 122c executes and controls the service control request for the computer 10-i. To section 122e. In this case, the execution control unit 122e starts the service #j to the service execution mechanism 11-i of the computer 10-i (computer #i) specified by the request in accordance with the service control request from the automatic control unit 122c. A command for executing the service start means 111-i to be executed is sent (step S8).
[0045]
When the execution control unit 122e sends an instruction for executing the service start unit 111-i for starting the service #j to the service execution mechanism 11-i of the computer 10-i, the execution control unit 122e sends the command to the automatic control unit 122c. Notify completion of service control request. Upon receiving the service control request completion notification, the automatic control unit 122c accesses the service status information DB 121b and sets the status of the service #j to “start” (step S9). Thus, the process associated with the start operation of service #j in the case where the user does not specify the computer for starting the service ends (step S10).
[0046]
Next, processing performed mainly by the manual control unit 122b of the scenario management mechanism 12 when the user designates a computer for starting a service will be described with reference to the flowchart of FIG.
The operation processing unit 122a in the scenario management mechanism 12 receives a start operation of a service (referred to as service #j) from a user (hereinafter referred to as a designated computer) 10-i (computer #i) from the user. A service control request based on the request is sent to the manual control unit 122b. As a result, the manual control unit 122b starts the requested service control process, that is, the process associated with the start operation of the service #j (step S11).
[0047]
First, the manual control unit 122b refers to the computer state information DB 121c and checks whether the state of the designated computer 10-i is normal (step S12). If the state of the designated computer 10-i is not normal, the manual control unit 122b assumes that the service #j cannot be started by the designated computer 10-i, and ends the process associated with the start operation of the service #j (step S13). ). On the other hand, if the state of the designated computer 10-i is normal, the manual control unit 122b inquires the inter-service relationship determination unit 122d, and the start of service #j in the computer 10-i It is checked whether the relationship is violated (step S14).
[0048]
If the start of service #j in designated computer 10-i violates the relationship between services (step S14), manual control unit 122b ends the process associated with the start operation of service #j (step S13). ). On the other hand, if the start of the service #j in the designated computer 10-i does not violate the relationship between services (step S14), the manual control unit 122b executes and controls the service control request for the computer 10-i. To section 122e.
[0049]
In accordance with the service control request from the manual control unit 122b, the execution control unit 122e performs service start unit 111-i for starting the service #j to the service execution mechanism 11-i of the computer 10-i specified by the request. A command for executing is sent (step S15). Then, the execution control unit 122e notifies the completion of the service control request to the manual control unit 122b. When the manual control unit 122b receives the service control request completion notification, the manual control unit 122b accesses the service status information DB 121b and sets the status of the service #j to “start” (step S16). Thus, the process associated with the start operation of service #j when the user designates the computer for starting the service ends (step S17).
[0050]
Next, when a failure that has occurred in a computer in the cluster system 1 is detected, it is executed to take over (fail over) the service that was started in the failure-occurring computer in another computer in the cluster system 1. Processing (failover processing) mainly performed by the automatic control unit 122c of the scenario management mechanism 12 will be described with reference to a flowchart of FIG.
[0051]
Assume that the failure detection unit 122f in the scenario management mechanism 12 has detected a failure that has occurred in a certain computer in the cluster system 1, for example, the computer 10-k (computer #k). In this case, the failure detection unit 122f accesses the computer state information DB 121c and sets the state of the failure occurrence computer 10-k (computer #k) to “abnormal”. The failure detection unit 122f also accesses the service state information DB 121b, and sets the state to “failure occurrence” for all services whose computer name is “computer #k” and whose current state is “start”.
[0052]
The automatic control unit 122c in the scenario management mechanism 12 refers to the service state information DB 121b periodically (step S21). If there is a service whose status is “failure occurrence” (step S22), the automatic control unit 122c starts a process for failing over the service. Here, it is assumed that the state of service #j is detected as “failure occurrence”.
[0053]
First, the automatic control unit 122c refers to the computer status information DB 121c and checks whether there is an undetermined computer (step S23). Here, in the first time of step S23, all the computers are undecided. As a result of repeating step S23, when there are no more undetermined computers, the automatic control unit 122c ends the process for failing over the service #j (step S24).
[0054]
On the other hand, when there is an undetermined computer, the automatic control unit 122c selects an arbitrary one of the undetermined computers as a candidate for a computer (hereinafter referred to as a candidate computer) for starting (taking over) service #j. (Step S25). Here, it is assumed that the computer 10-i (computer #i) is selected as a candidate computer. Next, the automatic control unit 122c checks whether or not the state of the selected candidate computer 10-i is “normal” based on the computer state information DB 121c (step S26).
[0055]
If the status of the candidate computer 10-i is not normal (step S26), the automatic control unit 122c uses the computer 10-i as a determined computer, and checks whether there is an undetermined computer (step S26). Return to S23). On the other hand, if the state of the candidate computer 10-i is normal (step S26), the automatic control unit 122c inquires the inter-service relationship determination unit 122d, and the start of service #j in the computer 10-i is It is examined whether or not the relationship between services is violated (step S27).
[0056]
If the start of the service #j in the candidate computer 10-i violates the relationship between the services (step S27), the automatic control unit 122c determines that the computer 10-i is a determined computer, and The process returns to the process of checking whether there is a judgment computer (step S23). On the other hand, if the start of the service #j in the candidate computer 10-i does not violate the relationship between services (step S27), the automatic control unit 122c executes and controls the service control request for the computer 10-i. To section 122e. In this case, the execution control unit 122e starts the service #j to the service execution mechanism 11-i of the computer 10-i (computer #i) designated by the request in accordance with the service control request from the automatic control unit 122c. A command for executing the service start means 111-i to be executed is sent (step S28). Then, the execution control unit 122e notifies the completion of the service control request to the automatic control unit 122c.
[0057]
Upon receiving the service control request completion notification, the automatic control unit 122c accesses the service status information DB 121b and sets the status of the service #j to “start” (step S29). As described above, the service #j started by the failure computer 10-k (failure computer #k) is failed over by another normal computer in the cluster system 1 (here, the computer 10-i (computer #i)). The process for doing so ends (step S30). The automatic control unit 122c repeats the above process as long as there is a service whose state is “failure occurrence”.
[0058]
Next, an inter-service relationship determination process (that is, a process for checking whether the service of interest violates the relationship between services) executed by the inter-service relationship determination unit 122d in the scenario management mechanism 12 is shown in FIG. This will be described with reference to a flowchart.
[0059]
Now, an inquiry is given from the manual control unit 122b or the automatic control unit 122c to the inter-service relationship determination unit 122d as to whether a certain service #j can be started on a certain computer 10-i (computer #i). To do. Here, the inquired service and computer are referred to as a target service and a target computer, respectively. Here, it is assumed that the target service is service #j and the target computer is computer 10-i (computer #i).
[0060]
When the inter-service relationship determination unit 122d receives an inquiry from the manual control unit 122b or the automatic control unit 122c, the target service #j specified by the inquiry is the computer 10-i (computer #i) specified by the inquiry. In step S41, an inter-service relationship determination process is performed to check whether the relationship between services is violated. First, the inter-service relationship determination unit 122d refers to the service relationship information DB 121a and acquires all data (records) in which the service name SN1 represents the target service #j in the service relationship information DB 121a (step S42).
[0061]
Next, the inter-service relationship determination unit 122d includes, in the acquired data, the type of the relationship between services is “exclusive relationship” and the attribute of the relationship between services is “strong relationship”, that is, “strong exclusion” It is checked whether or not there is an undetermined one (step S43). Here, in the first time of step S43, all “strong exclusive relationships” have not been determined. As a result of the repetition of step S43, when there is no undetermined “strong exclusive relationship” data, the inter-service relationship determination unit 122d proceeds to a process of examining dependency described later (step S50).
[0062]
On the other hand, when there is undetermined “strong exclusive relationship” data, the inter-service relationship determination unit 122d selects any one of the undetermined data as data that is a candidate for the determination target of the inter-service relationship ( Hereinafter, it is selected as candidate data) (step S44). Next, the inter-service relationship determination unit 122d refers to the service state information DB 121b, and acquires information related to the service indicated by the service name SN2 in the selected candidate data in the service relationship information DB 121a (hereinafter referred to as exclusion target data). (Step S45).
[0063]
The inter-service relationship determination unit 122d checks whether the status of the acquired exclusion target data is “start” (step S46). If the status of the acquired exclusion target data is not the start (step S46), the inter-service relationship determination unit 122d determines that the data has been determined, and returns to the process of checking whether there is an undetermined data (step S43). On the other hand, if the status of the acquired exclusion target data is “start”, the inter-service relationship determination unit 122d checks whether the attribute of the relationship between the services of the data is a local relationship (step S47).
[0064]
If the attribute of the relationship between services of the acquired exclusion target data is not a local relationship (step S47), the inter-service relationship determination unit 122d determines that the relationship between services is violated (step S49). On the other hand, if the attribute of the relationship between the services of the exclusion target data is a local relationship (step S47), the inter-service relationship determination unit 122d determines that the computer name included in the exclusion target data indicates that the target It is checked whether the computer is represented (step S48).
[0065]
If the computer name included in the exclusion target data represents the target computer (step S48), the inter-service relationship determination unit 122d may start the target service #j on the computer 10-i between services. Is determined to be violated (step S49). On the other hand, if the computer name included in the exclusion target data does not represent the target computer (step S48), the inter-service relationship determination unit 122d determines that the data has been determined, and whether there is an undecided one. The process returns to the examination process (step S43).
[0066]
As a result of repeating step S43, when there is no undecided “strong exclusive relationship” data, the inter-service relationship determination unit 122d includes the type of relationship between services in the data acquired in step S42. Is “dependency” and the attribute of the relationship between services is “strong relationship”, that is, “strong dependency” and whether there is an undetermined one (step S50). Here, in the first time of step S50, all the “strong dependency relationships” have not been determined. As a result of repeating step S50, when there is no undecided “strong dependency” data (step S50), the inter-service relationship determination unit 122d may start the target service #j on the computer 10-i. It is determined that the relationship between services is not violated (step S51).
[0067]
On the other hand, when there is undetermined “strong dependency” data, the inter-service relationship determination unit 122d determines any one of the undetermined “strong dependency” data as the determination target of the inter-service relationship. Is selected as candidate data (step S52). Next, the inter-service relationship determination unit 122d refers to the service state information DB 121b, and acquires information related to the service indicated by the service name in the selected candidate data in the service relationship information DB 121a as dependency target data (step S53).
[0068]
The inter-service relationship determination unit 122d checks whether the state of the acquired dependency target data is “start” (step S54). If the state of the acquired dependence target data is “start” (step S54), the inter-service relationship determination unit 122d determines that the data has been determined, and returns to the process of checking whether there is undetermined data (step S50). . On the other hand, if the state of the acquired dependence target data is not the start, the inter-service relationship determination unit 122d checks whether the attribute of the relationship between the services of the data is a local relationship (step S55).
[0069]
If the attribute of the relationship between the services of the acquired dependency target data is not a local relationship (step S55), the inter-service relationship determination unit 122d determines that the data has been determined and checks whether there is an undetermined one. Return to (Step S50). On the other hand, if the attribute of the relationship between the services of the dependency target data is a local relationship (step S55), the inter-service relationship determination unit 122d determines that the computer name included in the exclusion target data is the target name. It is checked whether the computer is represented (step S56).
[0070]
If the computer name included in the dependency target data does not represent the target computer (step S56), the inter-service relationship determination unit 122d may start the target service #j on the computer 10-i between services. Is determined to be violated (step S57). On the other hand, if the computer name included in the dependency target data represents the target computer (step S56), the inter-service relationship determination unit 122d determines that the data has been determined, and whether there is an undetermined one. The process returns to the examination process (step S50).
[0071]
As described above, in the first embodiment of the present invention, advanced and detailed service control can be realized by setting the relationship between services by the service relationship information DB 121a. Specifically, by setting services that must be started in sequence and services that must not be started at the same time, advanced and detailed service control can be controlled from the scenario management mechanism 12 in the cluster system control mechanism 10. It becomes. In the first embodiment of the present invention, the automatic control of the service realized mainly by the automatic control unit 122c is used to reduce the judgment required by the user and facilitate the control of the cluster system. Can do. Furthermore, in the first embodiment of the present invention, a service failover mechanism can be easily realized.
[0072]
(First modification of the first embodiment)
FIG. 7 is a block diagram showing the configuration of the cluster system according to the first modification of the first embodiment of the present invention. In the configuration of FIG. 7, the same reference numerals are assigned to the parts equivalent to those in FIG.
[0073]
The feature of the cluster system 1 ′ shown in FIG. 7 is that the scenario management mechanism 12 ′ corresponding to the scenario management mechanism 12 in FIG. 1 is one of the computers 10-1 (# 1) to 10-N (#N). Or on one computer, for example, computer 10-1 (# 1).
[0074]
As is apparent from the first embodiment of the present invention and the first modification example thereof, the scenario management mechanism in the cluster system exists only on any one of a plurality of computers constituting the cluster system. Even if it exists over all the computers, it may exist over two or more partial computers.
[0075]
(Second modification of the first embodiment)
Next, a second modification of the first embodiment will be described.
The type of relationship between services (dependency relationship, exclusive relationship, irrelevant) and the attribute of relationship between services (strong relationship, weak relationship) can be combined. There are five combinations as shown below, that is,
・ Strong dependency
・ Weak dependencies
・ Strong exclusive relationship
・ Weak exclusive relationship
・ Unrelated
It becomes.
[0076]
In addition, the application range (local relationship, global relationship) of the relationship between services can be combined with the above five combinations. The number of combinations is 10 (5 × 2) as shown below, that is,
(1) Strong local dependency
(2) Local weak dependence
(3) Local strong exclusion relationship
(4) Local weak exclusion relationship
(5) Local unrelated
(6) Strong global dependency
(7) Global weak dependency
(8) Global strong exclusive relationship
(9) Global weak exclusion relationship
(10) Global unrelated
It becomes.
[0077]
Therefore, when setting the relationship between services, it is possible to select several of the above ten combinations and set them simultaneously for the same service. However, some of the selected combinations (selection patterns) set at the same time are logically contradictory or meaningless. For example, if the combination (6) and the combination (8) are set at the same time, a logical contradiction occurs. Considering the exclusive relationship, setting the combination (3) is meaningless when the combination (8) is set. Considering the dependency, it is meaningless to set the combination (6) when the combination (1) is set.
[0078]
When such logically contradictory selection patterns and meaningless selection patterns are excluded from the selection patterns that can be set simultaneously among the above 10 combinations, the selection patterns that can be set are shown below. 15 ways,
(1) Strong local dependence and strong global dependence
(2) Local weak dependence and global strong dependence
(3) Local weak dependence and global weak dependence
(4) Only global strong dependencies
(5) Only global weak dependencies
(6) Strong global dependence and strong local exclusion
(7) Global weak dependence and local strong exclusion
(8) Global strong dependence and local weak exclusion
(9) Global weak dependence and local weak exclusion
(10) Local weak exclusive relationship only
(11) Only local strong exclusion relationship
(12) Local weak exclusion relationship and global weak exclusion relationship
(13) Local strong exclusion relationship and global weak exclusion relationship
(14) Local strong exclusive relationship and global strong exclusive relationship
(15) Only unrelated
It becomes.
[0079]
Thus, in the second modification of the first embodiment of the present invention, service relationship information is selected by selecting some of the types of relationships between services, their attributes, and their combinations. When setting in the DB 121a, a logically correct relationship between services can be set efficiently by removing in advance a selection pattern that causes logical contradiction and a logically meaningless selection pattern.
[0080]
[Second Embodiment]
Next, a second embodiment of the present invention will be described.
FIG. 8 is a block diagram showing a configuration of a scenario management mechanism 120 used in place of the scenario management mechanism 12 having the configuration of FIG. 2 in the cluster system of FIG. In the configuration of FIG. 8, the same reference numerals are given to the portions equivalent to those in FIG.
[0081]
A feature of the scenario management mechanism 120 configured as shown in FIG. 8 is that it has a configuration capable of realizing a batch job. A batch job is a type of job that executes a predetermined series of processes and ends the job when the process ends. In the conventional cluster system, in order to stop the service, an operation by the user is always required. Therefore, it is difficult to realize a process of automatically ending such as a batch job as a service.
[0082]
The scenario management mechanism 120 in FIG. 8 has a batch job control unit 122g. The configuration of the scenario management mechanism 120 is equivalent to a configuration in which a batch job control unit 122g is added to the scenario management mechanism 12 of FIG. The batch job control unit 122g has a batch job type service information DB 121e. This batch job type service information DB 121e is a database of services (batch job type services) handled as batch jobs. One piece of data (record) in the batch job type service information DB 121e is composed of two items: a service name and a status. The service name is the name of a batch job type service provided by the cluster system. The state is information indicating whether or not the batch job type service is being executed, and has two states of “being executed” or “stopped”.
[0083]
Next, referring to the flowchart of FIG. 9, taking as an example a process that handles a batch job type service (service #j) for the process mainly performed by the batch job control unit 122g of the scenario management mechanism 120 having the configuration shown in FIG. To explain.
First, it is assumed that data (record) in which the service name is service #j and the state is “stopped” is set in the batch job type service information DB 121e. In this state, it is assumed that the operation processing unit 122a receives a service #j start operation from the user. Then, the operation processing unit 122a accesses the service permission state information DB 121d and sets the permission state of the service #j to “permitted”.
[0084]
The batch job control unit 122g periodically refers to the service permission state information DB 121d and acquires data regarding the service #j each time (step S61). If the permission state of the service #j acquired from the service permission state information DB 121d is “permitted” (step S62), the batch job control unit 122g accesses the batch job type service information DB 121e to access the service #j. The state is set to “being executed” (step S63).
[0085]
Next, the batch job control unit 122g periodically refers to the service status information DB 121b and acquires data (records) related to the service #j. On the other hand, as shown in this example, when the permission state of the service #j becomes “permitted”, the automatic control unit 122c executes the start processing of the service #j and finally accesses the service state information DB 121b. Thus, the state of service #j is set to “start”.
[0086]
When the status of the service #j in the service status information DB 121b is “started” (step S64), the batch job control unit 122g accesses the service permission status information DB 121d and sets the permission status of the service #j to “not permitted”. (Step S65). When the permission state of the service #j becomes “not permitted”, the automatic control unit 122c executes a process of stopping the service #j, and finally accesses the service state information DB 121b to check the state of the service #j. Set to “Stop”.
[0087]
When the status of the service #j in the service status information DB 121b is “stopped” (step S66), the batch job control unit 122g accesses the batch job type service information DB 121e to stop the status of the service #j. (Step S67). This completes the batch job processing for service #j (step S67).
[0088]
As described above, in the second embodiment of the present invention, the service can be handled as a batch job by using the scenario management mechanism 120 including the batch job control unit 122g. As a result, for example, the scenario management mechanism 120 can control processing suitable for handling as a batch job such as data backup.
[0089]
[Third Embodiment]
Next, a third embodiment of the present invention will be described.
FIG. 10 is a block diagram showing the configuration of a cluster system (n-to-m backup configuration cluster system) according to the third embodiment of the present invention. The n-to-m backup configuration cluster system shown in FIG. 10 is characterized by a conventionally known n-to-m backup configuration (where n is an integer of 2 or more and m is an integer of 1 or more) in the first embodiment. It is realized by applying the applied cluster system.
[0090]
The n-to-m backup configuration cluster system in FIG. 10 includes n 1-to-m backup configuration cluster systems 1-1 (# 1), 1-2 (# 2),..., 1-n (#n). Yes. The cluster systems 1-1 (# 1), 1-2 (# 2),..., 1-n (#n) are computers 100-1 (# 1) and 100-2 (# 2) used as active computers, respectively. 2),... 100-n (#n). Computers 100-1 (# 1), 100-2 (# 2),... 100-n (#n) provide services # 1, # 2,. The cluster systems 1-1 (# 1), 1-2 (# 2),... 1-n (#n) are the cluster systems 1-1 (# 1), 1-2 (# 2),. m commonly provided corresponding to the active computers 100-1 (# 1), 100-2 (# 2),... 100-n (#n) in n (#n) and used as standby computers Computers 100- (n + 1) (# n + 1), 100- (n + 2) (# n + 2),... 100- (n + m) (# n + m) are provided. Active computers 100-1 (# 1) to 100-n (#n) and cluster systems 1-1 (# 1) to 1 in the cluster systems 1-1 (# 1) to 1-n (#n) The standby computers 100- (n + 1) (# n + 1) to 100- (n + m) (# n + m) common to -n (#n) are interconnected by a network (not shown).
[0091]
As described above, the n-to-m backup configuration cluster system shown in FIG. 10 has m computers 100- (n + 1) (# n + 1) to 100- (n + m) (#) in order to save computer resources. n + m) are commonly used as standby computers, and are composed of n 1-to-m backup cluster systems 1-1 (# 1) to 1-n (#n). In this n-to-m backup configuration cluster system, if a failure occurs in any of the n active computers 100-1 to 100-n that provide services # 1 to #n, the computer provides them. The existing service can be taken over by any of the m computers 100- (n + 1) to 100- (n + m). The configuration of the n-to-m backup configuration cluster system in FIG. 10 is the same as that described above except that it includes n 1-to-m backup configuration cluster systems 1-1 (# 1) to 1-n (#n). This is the same as the cluster system in the first embodiment. That is, the n-to-m backup configuration cluster system of FIG. 10 includes a service execution mechanism provided for each of the computers 100-1 (# 1) to 100- (n + m) (# n + m) and a scenario management mechanism of the configuration of FIG. A cluster system control mechanism (none of which is shown). Therefore, in 3rd Embodiment, FIG. 2 is used as needed.
[0092]
In the prior art, in order to realize a computer system with an n-to-m backup configuration, it is the same as which computer is started for all n services # 1 to #n and to which computer is taken over when a failure occurs. It is necessary to set it carefully so that the service is not concentrated on the computer. On the other hand, in the third embodiment of the present invention, this type of setting can be easily performed as described below by using the cluster system applied in the first embodiment.
[0093]
FIG. 11 shows an example of the service relation information DB 121a possessed by the scenario management mechanism in the n-to-m backup configuration cluster system of FIG. The service relation information DB 121a of FIG. 11 includes service #i (i = 1 to n−1) of n services provided by the n-to-m backup configuration cluster system of FIG. 10 and other services #j. For all combinations with (j = i + 1 to n), the service name (SN1, SN2) representing the service of the combination, the type of relationship between services (#i, #j), service (#i, #j) The attribute of the relationship between the services and the information on the application range of the relationship between the services (#i, #j) are registered. Here, the type of relationship between services, the attribute of the relationship between services, and the scope of the relationship between services are independent of the combination of services.
-Types of relationships between services: exclusive relationships
・ Attributes of relationships between services: Strong relationships
・ Scope of relationships between services: Local relationships
It is set like this.
[0094]
Next, the operation of the n-to-m backup configuration cluster system of FIG. 10 to which the service relation information DB 121a shown in FIG. 11 is applied will be described with the aid of the configuration of FIG. 2 and the flowchart of FIG.
When the operation processing unit 122a in the scenario management mechanism 12 illustrated in FIG. 2 receives a start operation of n services # 1 to #n by the user, the operation processing unit 122a accesses the service permission state information DB 121d and the n services # 1 to # 1. All the permission states of #n are set to “permitted”. If the permission state of the services # 1 to #n in the service permission state information DB 121d is “permitted”, the automatic control unit 122c changes the service # 1 to #n between the services indicated by the service relation information DB 121a. According to the relationship, one service is started for each of the n active computers 100-1 (# 1) to 100-n (#n) among the n + m computers constituting the n-to-m backup configuration cluster system. Here, it is assumed that the service #i is started on the computer 100-i (#i).
[0095]
In this state, for example, because a failure has occurred in the computer 100-1 (# 1), the service # 1 started in the computer 100-1 is failed over. This failover processing is executed according to the flowchart of FIG. 5 by the automatic control unit 122c, as in the first embodiment. That is, when the automatic control unit 122c detects that a failure has occurred in the computer 100-1 that has started the service # 1 by referring to the service state information DB 121b (steps S21 and S22 in FIG. 5), the service # The computer that takes over 1 is determined by a series of processes (steps S23, S25 to S27) starting from step S23 in FIG. Here, based on the relationship between the computer state indicated by the computer state information DB 121c and the service indicated by the service relationship information DB 121a, service # 1 is selected from the n + m computers in the n-to-m backup configuration cluster system of FIG. One normal computer whose start does not violate the relationship between services is selected. In the example of the service relationship information DB 121a shown in FIG. 11, computers whose start of service # 1 does not violate the relationship between services are standby computers 100- (n + 1) to 100- (n + m), of which the computer 100- (n + 1) is selected. In this case, service # 1 is started (taken over) by the computer 100- (n + 1).
[0096]
Furthermore, it is assumed that a failure occurs in the computer 100-2 in this state, and the service # 2 started in the computer 100-2 is failed over. Also in this case, the takeover destination computer is determined by the automatic control unit 122c as described above. Here, m-1 computers 100- (n + 2) to 100- (n) excluding the active computers 100-1 to 100-n and the computer 100- (n + 1) that has taken over service # 1. + m), for example, the computer 100- (n + 2) is selected as the takeover destination computer, and the service # 2 is started (taken over) by the computer 100- (n + 2). To do.
[0097]
Hereinafter, under the same control, when n ≧ m, even if a failure occurs in m computers among the computers 100-1 to 100-n, the service started by the m computers is changed. , Can automatically fail over to m standby computers 100- (n + 1) to 100- (n + m). That is, in the n-to-m backup configuration cluster system of FIG. 10, when n ≧ m, up to m services are transferred to m standby computers 100- (n + 1) to 100- (n + m ). If n <m, up to n services can be failed over to n of m standby computers 100- (n + 1) to 100- (n + m).
[0098]
As described above, in the third embodiment of the present invention, the service relationship information DB 121a is used, and the relationship between all services (combinations of services) is all between the services in the service relationship information DB 121a. By defining relationship type = exclusive relationship, attribute between services = strong relationship, application range between services = local relationship, an n-to-m backup configuration can be realized. The third embodiment is a combination of the relationship between services applied in the first embodiment and automatic service control by the automatic control unit 122c, and is a conventional cluster system having an n-to-m backup configuration. Compared to, the settings are simple and uniform.
[0099]
[Fourth Embodiment]
Next, a fourth embodiment of the present invention will be described. The feature of this fourth embodiment is that cold backup of data is realized by utilizing the relationship between services by the cluster system applied in the second embodiment. Therefore, FIG.1 and FIG.8 is used about the structure of a cluster system.
[0100]
The cold backup of data refers to an operation of backing up data by stopping the service that accesses data when there is data and a service that accesses the data. That is, a backup mode in which access to data does not occur during backup processing is called data cold backup.
[0101]
To implement cold backup in a conventional cluster system, the user must first stop the service that accesses the data, then execute the process of backing up the data, and then start the service that accesses the data again. There is a need to do. In a conventional cluster system, data access service and data backup processing can be executed on the computer where the data exists, or data access can be started after the data is accessible. It is necessary to control such services and processes by user operations. In the fourth embodiment of the present invention, by using the cluster system applied in the second embodiment, this type of service and processing control can be automatically performed as described below.
[0102]
FIG. 12 shows service-related information possessed by the scenario management mechanism 120 having the configuration of FIG. 8 (used in place of the scenario management mechanism 12 in the cluster system 1 of FIG. 1) applied in the fourth embodiment of the present invention. An example of DB121a is shown. In the fourth embodiment, the following three services are registered as services registered in the service relation information DB 121a of FIG.
・ Service corresponding to data (data itself)
・ Service to access data
・ Data backup service
Is prepared. The “data backup service” is a batch job type service applied in the second embodiment.
[0103]
In the service relationship information DB 121a shown in FIG. 12, three types of relationships # 1 to # 3 between services are defined as relationships between services. The contents of the data (record) in the service relation information DB 121a for each of the relations # 1 to # 3 between services, that is, service names SN1 and SN2, types of relations between services, attributes of relations between services, and services Information on the scope of the relationship between them is as follows.
[0104]
(Relationship between services # 1)
First, the information about the relationship # 1 between services is
Service name SN1: Service for accessing data
Service name SN2: Service corresponding to data
-Types of relationships between services: dependencies
・ Attributes of relationships between services: Strong relationships
・ Scope of relationships between services: Local relationships
It is.
[0105]
(Relationship between services # 2)
Next, information about the relationship # 2 between services is
-Service name SN1: Data backup service
Service name SN2: Service corresponding to data
-Types of relationships between services: dependencies
・ Attributes of relationships between services: Strong relationships
・ Scope of relationships between services: Local relationships
(Relationship between services # 3)
Finally, information about relationship # 3 between services is
Service name SN1: Service for accessing data
-Service name SN2: Service for backing up data
-Types of relationships between services: exclusive relationships
・ Attributes of relationships between services: Strong relationships
・ Application scope of relations between services ... Global relations
It is.
[0106]
Next, cold backup of data according to the fourth embodiment of the present invention will be described with reference to the configurations of FIGS. 1 and 8 and the flowcharts of FIGS. However, it is assumed that the scenario management mechanism 120 having the configuration of FIG. 8 is used instead of the scenario management mechanism 12 in FIG.
[0107]
It is assumed that “a service corresponding to data” and “a service for accessing data” have already started. Here, “service corresponding to data” is started first due to the relationship # 1 between services. Further, both the “service corresponding to data” and the “service accessing data” are started on the same computer by the relationship # 1 between the services. Here, it is assumed that both services are started by the computer 10-1 in the cluster system of FIG.
[0108]
In this state, it is assumed that the user performs an operation of starting a “data backup service” on the client terminal for data backup. Then, the operation processing unit 122a in the scenario management mechanism 120 illustrated in FIG. 8 accesses the service permission state information DB 121d and sets the permission state of “data backup service” to “permitted”.
[0109]
The automatic control unit 122c periodically refers to the service permission state information DB 121d, and when the permission state of the “service for backing up data” is set to “permitted”, the “permitted” The “service for backing up data” is started on the computer 10-1 where “service corresponding to data” has been started (steps S2 to S10 in FIG. 3). In this state, the automatic control unit 122c stops the “service for accessing data” started in the computer 10-1 according to the relationship # 3 between services.
[0110]
The “data backup service” is a batch job type service. Therefore, as shown in the above example, when the “data backup service” is started in the computer 10-1, the permission status of the “data backup service” is immediately set to “not valid” by the batch job control unit 122g. “Permitted” (steps S62 to S65 in FIG. 9). Then, the automatic control unit 122c executes a process of stopping the “data backup service” in the computer 10-1. The process of stopping the “data backup service” is performed after the process accompanying the start of the service, that is, the process for backing up the data is completed.
[0111]
Now, when the “data backup service” in the computer 10-1 is stopped, the fact that the “data access service” has started does not violate the relationship # 3 between services. Therefore, the automatic control unit 122c restarts the “service for accessing data” (steps S7 to S9 in FIG. 3).
[0112]
As described above, in the fourth embodiment of the present invention, the service-related information DB 121a is used to define "service corresponding to data", "service for backing up data", and "service for accessing data" For the “service corresponding to data”, a strong dependency is set as a local relationship from “service for backing up data” and “service for accessing data”, and “service for backing up data” and “ By setting a strong exclusive relationship with the “service for accessing data” as a global relationship, cold backup of the data can be realized. In the fourth embodiment, the relationship between services applied in the second embodiment is applied in combination with the automatic control of services by the automatic control unit 122c, and data is obtained using a conventional cluster system. Compared to realizing the cold backup, the user does not need to start or stop the service. Further, in the fourth embodiment, when the “service for backing up data” is started, it is explicitly specified on which computer the “service corresponding to data” is started, and the order of starting the services is set. There is no need to consider. Therefore, it can be said that the cluster system according to the fourth embodiment is simpler and more uniform than the conventional cluster system.
[0113]
[Fifth Embodiment]
Next, a fifth embodiment of the present invention will be described. The feature of the fifth embodiment is that online backup of data is realized by utilizing the relationship between services by the cluster system applied in the second embodiment. Therefore, FIG.1 and FIG.8 is used about the structure of a cluster system.
[0114]
Data online backup refers to an operation of backing up data without stopping the data access service when there is data and a service accessing the data.
[0115]
To implement online backup in a conventional cluster system, the data access service and the data backup process can be executed on the computer where the data exists, or the data can be accessed before the data is accessed. It is necessary to control services and processes such as starting a service to be performed by a user operation. In the fifth embodiment of the present invention, by using the cluster system applied in the second embodiment, this type of service and processing control can be automatically performed as described below.
[0116]
FIG. 13 shows service-related information that the scenario management mechanism 120 having the configuration of FIG. 8 (used in place of the scenario management mechanism 12 in the cluster system 1 of FIG. 1) applied in the fifth embodiment of the present invention. An example of DB121a is shown. In the fifth embodiment, the following three services are registered as services registered in the service relation information DB 121a of FIG. 13 as in the fourth embodiment.
・ Service equivalent to data
・ Service to access data
・ Data backup service
Is prepared. The “data backup service” is a batch job type service applied in the second embodiment.
[0117]
In the service relationship information DB 121a shown in FIG. 13, three types of relationships # 1 to # 3 between services are defined as relationships between services. Among the relationships # 1 to # 3 between the services, the relationships # 1 and # 2 between the services coincide with the relationships # 1 and # 2 between the services in the fourth embodiment, and thus the description thereof is omitted. On the other hand, the relationship # 3 between services is different from the relationship # 3 between services in the fourth embodiment in the type of relationship between services.
[0118]
That is, the relationship # 3 between services applied in the fifth embodiment is
-Service name SN1: Data backup service
Service name SN2: Service for accessing data
-Types of relationships between services: dependencies
・ Attributes of relationships between services: Strong relationships
・ Application scope of relations between services ... Global relations
It is. As described above, in the relationship # 3 between services applied in the fifth embodiment, the service names SN1 and SN2 are opposite to those in the fourth embodiment, and the “type of relationship between services” is “dependency”. This is characterized in that the “application range of the relationship between services” is a global relationship.
[0119]
Next, cold backup of data according to the fifth embodiment of the present invention will be described with reference to the configurations of FIGS. 1 and 8 and the flowcharts of FIGS. However, it is assumed that the scenario management mechanism 120 having the configuration of FIG. 8 is used instead of the scenario management mechanism 12 in FIG.
[0120]
It is assumed that “a service corresponding to data” and “a service for accessing data” have already started. Here, “service corresponding to data” is started first due to the relationship # 1 between services. Further, both the “service corresponding to data” and the “service accessing data” are started on the same computer by the relationship # 1 between the services. Here, it is assumed that both services are started by the computer 10-1 in the cluster system of FIG. 1, as in the fourth embodiment.
[0121]
In this state, it is assumed that the user performs an operation of starting a “data backup service” on the client terminal for data backup. Then, the operation processing unit 122a in the scenario management mechanism 120 illustrated in FIG. 8 accesses the service permission state information DB 121d and sets the permission state of “data backup service” to “permitted”.
[0122]
The automatic control unit 122c periodically refers to the service permission state information DB 121d, and when the permission state of “service for backing up data” is set to “permitted”, according to the relationships # 2 and # 3 between services, The “service for backing up data” is started on the computer 10-1 on which “service corresponding to data” and “service for accessing data” have been started (steps S2 to S10 in FIG. 3).
[0123]
The “data backup service” is a batch job type service. For this reason, when the “data backup service” is started on the computer 10-1, the permission status of the “data backup service” is immediately set to “not permitted” by the batch job control unit 122g (see FIG. 9 steps S62 to S65). Then, the automatic control unit 122c executes a process of stopping the “data backup service” in the computer 10-1. The process of stopping the “data backup service” is performed after the process accompanying the start of the service, that is, the process for backing up the data is completed.
[0124]
As described above, in the fifth embodiment of the present invention, the service-related information DB 121a is used to define “a service corresponding to data”, “a service for backing up data”, and “a service for accessing data”. For the “service corresponding to data”, a strong dependency is set as a local relationship from “service for backing up data” and “service for accessing data”, respectively, and for “service for accessing data” By setting a strong dependency relationship as a global relationship from the “data backup service”, online data backup can be realized. In the fifth embodiment, the relationship between services applied in the second embodiment is applied in combination with the automatic control of services by the automatic control unit 122c, and the fifth embodiment is similar to the fourth embodiment. In addition, it can be said that the setting is simple and uniform as compared with the case where the online backup of data is realized using a conventional cluster system.
[0125]
Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, you may combine suitably the component covering different embodiment.
[0126]
【The invention's effect】
As described above in detail, according to the present invention, with respect to the service provided by the cluster system, the service relationship is indicated so that it matches the service relationship indicated by the service relationship information stored in the service relationship information storage means. By controlling the start or stop, it is possible to realize sophisticated and detailed service control that matches the relationship between services. Therefore, when multiple services are provided by a cluster system, the services can be placed on the computer so as to be optimal in terms of system availability, effective use of computer resources, and improvement of service processing capacity. More advanced service control than system can be realized.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a cluster system according to a first embodiment of the present invention.
FIG. 2 is a block diagram showing a configuration of a scenario management mechanism 12 in FIG.
FIG. 3 is a flowchart for explaining processing mainly by an automatic control unit 122c of the scenario management mechanism 12 when a user does not designate a computer for starting a service in the first embodiment.
FIG. 4 is a flowchart for explaining processing mainly by a manual control unit 122b of the scenario management mechanism 12 when a user designates a computer to start a service in the first embodiment.
FIG. 5 is a flowchart for explaining failover processing mainly by the automatic control unit 122c of the scenario management mechanism 12 in the first embodiment;
FIG. 6 is a flowchart for explaining a service relationship determination process in the first embodiment;
FIG. 7 is a block diagram showing a configuration of a cluster system according to a first modification of the first embodiment.
FIG. 8 is a block diagram showing a configuration of a scenario management mechanism applied in a second modification of the first embodiment.
FIG. 9 is a flowchart for explaining processing mainly by a batch job control unit 122g of the scenario management mechanism 120 in the second modification.
FIG. 10 is a block configuration diagram of an n-to-m backup configuration cluster system according to a third embodiment of the present invention.
11 is a diagram showing an example of a service relation information DB 121a included in the scenario management mechanism in the n-to-m backup configuration cluster system of FIG.
FIG. 12 is a diagram showing an example of a service relation information DB 121a for realizing cold backup of data applied in the fourth embodiment of the present invention.
FIG. 13 is a diagram showing an example of a service relation information DB 121a for realizing online backup of data, which is applied in the fifth embodiment of the present invention.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Cluster system, 10 ... Cluster system control mechanism, 10 <-1> -10-N ... Computer, 11-1-11-N ... Service execution mechanism, 12, 12 '... Scenario management mechanism, 100-1-100-n ... Active computer, 100- (n + 1) to 100- (n + m) ... Standby computer, 121 ... Database section, 121a ... Service related information DB, 121b ... Service status information DB, 121c ... Computer status information DB 121d ... Service permission status information DB, 121e ... Batch job type service information DB, 122 ... Service control unit, 122a ... Operation processing unit, 122b ... Manual control unit, 122c ... Automatic control unit, 122d ... Inter-service relationship determination unit, 122e ... execution control unit, 122g ... batch job control unit.

Claims

In a cluster system that is configured from a plurality of computers and can provide three types of services: a first service that provides data, a second service that backs up data, and a third service that accesses data,
As a type of the first inter-service relationship that is a relationship between the first and third services, a dependency that can start the third service is defined only when the first service has already started. And defining a strong relationship that the first inter-service relationship must be established as an attribute of the first inter-service relationship, and defining the application range of the first inter-service relationship as a service on the same computer A first inter-service relation information defining a local relation to which the first inter-service relation is applied only when the first service relation is started, and a second relation between the first and second services As the type of inter-service relationship, a dependency that can start the second service is defined only when the first service has already started, and the second inter-service relationship attribute is defined as the second service inter-service relationship. of Defines a strong relationship exist relationships must necessarily satisfied, and as the scope of the relationship between the second service, the relationship between the second service is applied only when the service is the start on the same computer The third service starts as the second service relationship information that defines the local relationship in advance and the type of the third service relationship that is the relationship between the second and third services. Defining an exclusive relationship that can start the second service only when it is not, defining a strong relationship that the third service relationship must be established as an attribute of the third service relationship, In addition, as the application range of the third inter-service relationship, a third relationship that defines a global relationship to which the third inter-service relationship is applied regardless of which computer the service is started on. And service between the related information storage means for storing the inter-service related information,
Service permission state information storage means for storing service permission state information for managing permission states indicating permission / non-permission that each of the three types of services is in a start state;
A service execution unit that is provided in each of the plurality of computers and manages the start and stop of the service;
A service control means for controlling the start or stop of a service provided by the cluster system so as to match the service relationship indicated by the first to third service relationship information. The permission state information storage means should be periodically referred to start so as to match the service relationship indicated by the first to third service relationship information corresponding to the permission state indicated by the service permission state information. Select the service and the computer that starts the service to be started, or the service to be stopped and the computer that has started the service to be stopped, and start the service or the service to the service execution means of the computer Service control means including automatic control means for instructing to stop the service,
The automatic control means is indicated by the service permission status information in a state where the first and third services are started by the same computer in accordance with the first service relation indicated by the first service relation information. When the permission state of the second service is permitted, the first service is started as the second service according to the second service relationship indicated by the second service relationship information. And stop the third service already started on the computer on which the second service is started in accordance with the third service relation indicated by the third service relation information. A cluster system characterized by

In a cluster system that is configured from a plurality of computers and can provide three types of services: a first service that provides data, a second service that backs up data, and a third service that accesses data,
As a type of the first inter-service relationship that is a relationship between the first and third services, a dependency that can start the third service is defined only when the first service has already started. And defining a strong relationship that the first inter-service relationship must be established as an attribute of the first inter-service relationship, and defining the application range of the first inter-service relationship as a service on the same computer A first inter-service relation information defining a local relation to which the first inter-service relation is applied only when the first service relation is started, and a second relation between the first and second services As the type of inter-service relationship, a dependency that can start the second service is defined only when the first service has already started, and the second inter-service relationship attribute is defined as the second service inter-service relationship. of Defines a strong relationship exist relationships must necessarily satisfied, and as the scope of the relationship between the second service, the relationship between the second service is applied only when the service is the start on the same computer The third service has already started as the type of the relationship between the second service and the third service, which is the relationship between the second and third services. A dependency that can start the second service is defined only when the second service is started, and a strong relationship that the third service relationship must be established as an attribute of the third service relationship is defined. In addition, as an application range of the third inter-service relation, a global relation to which the third inter-service relation is applied regardless of which computer the service is started is defined. And service between the related information storage means for storing the inter-service relationship information,
Service permission state information storage means for storing service permission state information for managing the permission state of the service for each of the three types of services;
A service execution unit that is provided in each of the plurality of computers and manages the start and stop of the service;
A service control means for controlling the start or stop of a service provided by the cluster system so as to match the service relationship indicated by the first to third service relationship information. The service to be started and the service to be started so as to match the service relation indicated by the service relation information corresponding to the permission state indicated by the service permission status information by periodically referring to the permission status information storage means A computer that starts a service, or a service to be stopped and a computer that has started the service to be stopped are selected, and the service execution unit of the computer is instructed to start the service or stop the service. Service control means including automatic control means, and
The automatic control means is indicated by the service permission status information in a state where the first and third services are started by the same computer in accordance with the first service relation indicated by the first service relation information. The second service relation indicated by the second service relation information and the third service indicated by the third service relation information when the permission state of the second service is permitted. The cluster system according to claim 1, wherein the second service is started in a state where the first and third services are started on a computer on which the first and third services are started.