JP4163481B2 - クラスタシステム及び同システムにおけるサービス制御方法 - Google Patents
クラスタシステム及び同システムにおけるサービス制御方法 Download PDFInfo
- Publication number
- JP4163481B2 JP4163481B2 JP2002298836A JP2002298836A JP4163481B2 JP 4163481 B2 JP4163481 B2 JP 4163481B2 JP 2002298836 A JP2002298836 A JP 2002298836A JP 2002298836 A JP2002298836 A JP 2002298836A JP 4163481 B2 JP4163481 B2 JP 4163481B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- server
- server computer
- executed
- relationship
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Hardware Redundancy (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、複数台のサーバ計算機から構成されるクラスタシステムに係り、特に開始または引継の必要な目的とするサービスを実行するサーバ計算機を決定するのに好適なクラスタシステム及び同システムにおけるサービス制御方法に関する。
【０００２】
【従来の技術】
システムの可用性を高める計算機システムとして、従来からクラスタシステムが知られている。このクラスタシステムは、同一のサービス（アプリケーションプログラム）を提供可能な複数台の計算機（サーバ計算機）から構成される（例えば、非特許文献１参照）。
【０００３】
クラスタシステムは、サービスを起動・停止する計算機を決定する機構（サービス制御決定機構）を有している。このサービス制御決定機構は、現在サービスを提供している計算機に障害が発生したときに、クラスタシステム内の他の正常な計算機の中からそのサービスを引き継ぐ計算機を決定して、そのサービスを継続させることにより、サービスが使用不能になる時間を最小限にしている。
【０００４】
【非特許文献１】
金子哲夫、外１名、「クラスタソフトウェア」、東芝レビュー、１９９９年、Vol.54、No.12、p.18-21
【０００５】
【発明が解決しようとする課題】
上記したように、従来のクラスタシステムでは、現在サービスを提供している計算機（サーバ計算機）に障害が発生したために、そのサービスを引き継ぐ計算機を決定する際に、他の正常な計算機にサービスを引き継ぐという簡単なルールだけに従っている。このため従来のクラスタシステムでは、多数のサーバ計算機を用いた環境において、柔軟にサービスを起動することが難しいという問題がある。
【０００６】
本発明は上記事情を考慮してなされたものでその目的は、相異なるサービス相互の実行に関する関係を定義した情報を利用することで柔軟なサービスの運用が実現できるクラスタシステム及び同システムにおけるサービス制御方法を提供することにある。
【０００７】
【課題を解決するための手段】
本発明の１つの観点によれば、複数台のサーバ計算機から構成されるクラスタシステムが提供される。このシステムは、クラスタシステム上で実行し得るサービスに関し、相異なるサービス相互の実行に関する関係を定義したサービス間関係情報が登録されるサービス間関係情報登録手段と、サービス制御決定機構とを備えている。このサービス制御決定機構は、目的とするサービスの実行が可能なサーバ計算機の中から、上記サービス間関係情報登録手段に登録されているサービス間関係情報に基づいて、目的とするサービスを実行するサーバ計算機を決定する。
【０００８】
このような構成においては、目的とするサービス（例えば開始または引継を必要とするサービス）との間でサービス相互の実行に関する関係を持つ他のサービスの存在を考慮して、当該目的とするサービスを実行するサーバ計算機が決定される、このため、目的とするサービスを実行するサーバ計算機として単に正常な計算機を当てる従来技術と異なり、クラスタシステムにおける柔軟なサービスの運用が可能となる。
【０００９】
ここで、上記サービス間関係情報により、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係を排他関係として定義すると共に、上記サービス制御決定機構に、目的とするサービスとの間で排他関係（サーバ内の強い排他関係）のあることが示されているサービスを実行中のサーバ計算機以外の正常なサーバ計算機の中から、目的とするサービスを実行するサーバ計算機を決定する手段を持たせるとよい。このようにすると、目的とするサービスとの間でサーバ内の強い排他関係のあることが示されているサービス、つまり目的とするサービスと同一サーバ計算機内で並行して実行できないサービスを実行中のサーバ計算機を、当該目的とするサービスを実行するサーバ計算機の候補から外すことができる。よって、例えばデータベース（ＤＢ）をアクセスするサービス（ＤＢアプリケーション）と、ＤＢをバックアップするサービス（ＤＢバックアップアプリケーション）など、本質的に同じサーバで動作することができないサービス（アプリケーション）を、クラスタシステムとして一元的に制御することができる。
【００１０】
上記排他関係は、目的とするサービスとの間にサーバ内の強い排他関係のあるサービスを実行中のサーバ計算機において、当該実行中のサービスが優先される「現状サービス優先」の排他関係である。しかし、目的とするサービスを優先させる「後サービス」優先の排他関係を適用することも可能である。ここでも、目的とするサービスとの間にサーバ内の強い排他関係のあるサービスを実行中でないサーバ計算機は、当該目的とするサービスを実行するサーバ計算機の候補とすればよい。一方、目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機内で、当該目的とするサービスとの間にサーバ内の強い排他関係のあるサービスが実行中の場合には、当該実行中のサービスを全て停止し、しかる後に、当該選択されたサーバ計算機を上記候補として扱えばよい。この候補（選択されたサーバ計算機）は、正常に動作可能であるならば、当該目的とするサービスを実行するサーバ計算機として決定される。これにより、サービスの開始または継続が不可欠であるサービスに対応でき、より柔軟性の高いクラスタシステムが実現できる。
【００１１】
また、上記の排他関係は、本質的に同一サーバ計算機内で並行して実行できないサービス相互の関係（サーバ内の強い排他関係）であるが、本質的に同一クラスタシステム内で並行して実行できないサービス相互の関係（クラスタシステム内の強い排他関係）を適用することも可能である。ここでは、目的とするサービスとの間でクラスタシステム内の強い排他関係のあるサービスがクラスタシステム内で実行中でない場合に、目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、目的とするサービスを実行するサーバ計算機を決定すればよい。このようにすると、本質的に同じクラスタシステム内で動作することができないサービスをクラスタシステムとして一元的に制御することが可能となる。また、「後サービス優先」のクラスタシステム内の排他関係を適用することも可能である。ここでは、目的とするサービスとの間でクラスタシステム内の排他関係のあるサービスが実行中の場合には、当該実行中のサービスを全て停止し、しかる後に目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、当該目的とするサービスを実行するサーバ計算機を決定すればよい。この構成においても、より柔軟性の高いクラスタシステムが実現可能となる。
【００１２】
また、サービス間関係情報によって定義可能な排他関係として、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係であって、実行中のサービスを優先させる関係である第１の排他関係と、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係であって、実行中のサービスより目的とするサービスを優先させる関係である第２の排他関係とを適用することも可能である。ここでは、目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機が正常に動作可能なサーバ計算機であり、且つ当該目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に第１の排他関係及び第２の排他関係が共にない場合には直ちに、当該目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に第１の排他関係はないものの、第２の排他関係がある場合には、当該選択されたサーバ計算機内で実行中の、当該目的とするサービスとの間で第２の排他関係のある全てのサービスを停止させた後に、当該選択されたサーバ計算機を当該目的とするサービスを実行するサーバ計算機として決定するとよい。このようにすると、クライアント端末からのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバ計算機で動かすという運用ができる。
【００１３】
また、サービス間関係情報によって定義可能な排他関係として、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係、つまりサーバ内の強い排他関係に代えて、同一サーバ計算機内で並行して実行することが好ましくないサービス相互間の関係、つまりサーバ内の弱い排他関係を適用することも可能である。ここでは、目的とするサービスの実行が可能なサーバ計算機の中から、当該目的とするサービスとの間でサーバ内の弱い排他関係にあるサービスを実行中のサーバ計算機と正常な動作が不可能なサーバ計算機とを除いて、当該目的とするサービスを実行するサーバ計算機を決定するようにし、当該目的とするサービスを実行するサーバ計算機を決定できなかった場合に限り、上記排他関係を考慮することなく、当該目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、当該目的とするサービスを実行するサーバ計算機を決定するとよい。このようにすると、クライアント端末からのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバ計算機で動かすという運用ができる。これにより、負荷分散を考慮した設定が容易になる。
【００１４】
また、クラスタシステム上で実行し得る各サービスの優先度を定義したサービス優先度情報が登録されるサービス優先度情報登録手段を追加することも可能である。ここでは、目的とするサービスと当該目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機内で実行中のサービスとの間に排他関係があっても、当該目的とするサービスの方が当該選択されたサーバ計算機内で実行中のサービスより優先度が高いことが上記サービス優先度情報により示されている場合には、当該選択されたサーバ計算機内で実行中のサービスであって、目的とするサービスとの間で排他関係のあるサービスを全て停止させ、しかる後に当該選択されたサーバ計算機を当該目的とするサービスを実行するサーバ計算機として決定するとよい。これにより、サービス間の排他関係を考慮しつつ優先度の高いサービスを優先的に開始または継続させることができる。
【００１５】
また、上記サービス優先度情報登録手段に加えて、クラスタシステム上で実行し得るサービス毎に、当該サービスの実行可否がクラスタシステムを利用するクライアント端末から設定可能なサービス実行可能情報が登録されるサービス実行可能情報登録手段を追加することも可能である。ここでは、クラスタシステムで実行し得るサービスを上記サービス優先度情報に従って優先度順に選択し、この選択されたサービスが実行可能であると上記サービス実行可能情報により示されている場合に、当該サービスとの間でサービス相互の実行に関する関係を持つサービスを上記サービス間関係情報に基づいて特定するとよい。また、この特定されたサービスの実行が未だ計画されていない場合に、上記選択されたサービスを実行計画の対象として決定すると共に、当該サービスを実行するサーバ計算機を、目的とするサービスの実行が可能なサーバ計算機の中から決定するとよい。このようにすると、特に、サービスの実行の開始を指示する開始命令であって、当該サービスを仮に開始したならば、当該サービスよりも優先度の高いサービスに悪影響を与えるような開始命令があった際にも、優先度に従い実行しないという処理が容易に実現できる。
【００１６】
なお、以上のクラスタシステムに係る本発明は、当該クラスタシステムにおいて目的とするサービスを実行するサーバ計算機を決定するためのサービス制御方法に係る発明としても成立する。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１８】
［第１の実施形態］
図１は本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図である。
図１に示すクラスタシステムは、各種のサービス（アプリケーションプログラム）を提供可能なｎ（ｎは２以上の自然数）台のサーバ計算機（以下、単にサーバと称する）１０-1〜１０-nから構成されている。サーバ１０-1〜１０-nは、２つのネットワーク１１及び１２により相互接続されている。ネットワーク１２には、クラスタシステム内のサーバ１０-1〜１０-nからのサービスの提供を受ける、つまりクラスタシステムを利用する、図示せぬクライアント端末（以下、単にクライアントと称する）が接続されている。本実施形態において、ネットワーク１１は、サーバ１０-1〜１０-nが相互に通信を行うのに用いられ、ネットワーク１２は、サーバ１０-1〜１０-nがクライアントとの間で通信を行うのに用いられる。なお、通信効率は低下するものの、サーバ１０-1〜１０-n相互の通信と、サーバ１０-1〜１０-nとクライアントとの間の通信とに、１つのネットワークを用いてもよい。
【００１９】
サーバ１０-1〜１０-nは、クラスタとしての制御を司るためのクラスタ制御機構１０１-1〜１０１-nを備えている。クラスタ制御機構１０１-1〜１０１-nは、それぞれネットワーク１１を介して互いに通信を行いながら同一の処理を実行する。これにより、クラスタ制御機構１０１-1〜１０１-nは、クラスシステム全体で１つの仮想的なクラスタ制御機構１０１を構成する。
【００２０】
クラスタ制御機構１０１-1〜１０１-nは、サービス制御決定機構１０２-1〜１０２-nと、サービス実行機構１０３-1〜１０３-nとを含む。サービス制御決定機構１０２-1〜１０２-nは、サービスを起動・停止するサーバを決定する。即ちサービス制御決定機構１０２-1〜１０２-nは、いずれのサーバでいずれのサービスを実行させるかを決定すると共に、いずれのサーバで実行されているいずれのサービスを停止させるかを決定する。サービス実行機構１０３-1〜１０３-nは、サービス制御決定機構１０２-1〜１０２-nの決定に従い、サービスを実行する。
【００２１】
サービス制御決定機構１０２-1〜１０２-nは、サービス間関係情報テーブルＴＢＬ１と実行サーバ情報テーブルＴＢＬ２とを有している。
サービス間関係情報テーブルＴＢＬ１は、図１のクラスタシステム上で実行し得る相異なるサービスの間の排他関係の情報（以下、サービス間関係情報と称する）を登録したテーブルである。本実施形態における相異なるサービスの間の排他関係とは、あるサービスが実行されている場合には、同じサーバ内で別のあるサービスを実行することができないという関係、つまり同じサーバ内で並行して実行することが本質的にできないサービス相互間の関係である。このような排他関係を、サーバ内の強い排他関係と呼ぶ。
【００２２】
サービス間関係情報テーブルＴＢＬ１のデータ構造の一例を図２に示す。図２のテーブルＴＢＬ１には、例えばサービスＡ及びＢの間に排他関係があることが示されている。この場合、サービスＡの実行中は、同じサーバ内でサービスＢを実行できず、逆にサービスＢの実行中は、同じサーバ内でサービスＡを実行できない。つまり、排他関係のあるサービスＡ及びＢは、同一サーバ内で並行して実行できない。
【００２３】
実行サーバ情報テーブルＴＢＬ２は、図１のクラスタシステム上で実行し得るサービス（を示すサービス名）毎に、当該サービスを当該システム内のいずれのサーバで実行（起動）できるかを示す情報（以下、実行サーバ情報と称する）を登録したテーブルである。この実行サーバ情報は、当該情報により対応するサービスを実行できることが示されているサーバ毎の優先度を含んでいる。このサーバ毎の優先度は、対応するサービスをいずれのサーバで実行するのがより好ましいかを示す。ここでは、優先度の値が小さいほど高優先度であることを示す。
【００２４】
実行サーバ情報テーブルＴＢＬ２のデータ構造例を図３に示す。図３のテーブルＴＢＬ２には、例えばサービスＡは、サーバＡ〜ＤのうちのサーバＡ〜Ｃで実行可能なことが示されている。また、このサービスＡを実行可能なサーバＡ，Ｂ，Ｃの優先度として、それぞれ優先度１，優先度３，優先度２が設定されている。これにより、サービスＡを実行するサーバとしては、サーバＡが最も好ましく、以下サーバＣ、サーバＢの順であることが示される。
【００２５】
サービス制御決定機構１０２-1〜１０２-nは、それぞれネットワーク１１を介して互いに通信を行いながら同一の処理を実行する。これによりサービス制御決定機構１０２-1〜１０２-nは、クラスシステム全体で１つの仮想的なサービス制御決定機構１０２を構成する。サービス制御決定機構１０２-1〜１０２-nが有するサービス間関係情報テーブルＴＢＬ１及び実行サーバ情報テーブルＴＢＬ２は常に同一内容となるように制御される。
【００２６】
サービス制御決定機構１０２-1〜１０２-nは、サービスの開始命令を受けた場合、或いはクラスタシステム内のサービス（サーバ）に障害が発生した場合に、サービス間関係情報テーブルＴＢＬ１に登録されているサービス間関係情報及び実行サーバ情報テーブルＴＢＬ２に登録されている実行サーバ情報をもとに、クラスタシステム内のいずれのサーバでサービスを実行すべきかを決定する。ここでは、サービス制御決定機構１０２-1〜１０２-nのうち、サービスを実行すべきサーバ１０-i（ｉは１〜ｎのいずれか）内のサービス制御決定機構１０２-iにより、サービス実行機構１０３-iが制御される。但し、以下の説明では、煩雑さを避けるために、仮想的なサービス制御決定機構１０２が上述の決定を行って、対応するサーバ１０-i内のサービス実行機構１０３-iを制御するものとして扱う。
【００２７】
次に、本発明の第１の実施形態において適用される、目的とするサービスを実行する計算機を決定するためのサービス制御処理について、図４のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害（サーバの障害発生）に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００２８】
まずサービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、開始または引き継ぐべき目的とするサービス（以下、対象サービスと称する）の実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ１〜Ｓ３）。今、サーバ１０-i（ｉは１〜ｎのいずれか）が選択されたものとする。
【００２９】
サービス制御決定機構１０２は、サーバ１０-iを対象サーバとして選択すると、当該サーバ１０-iについて、障害が発生したサーバ自身であるか、或いは電源が遮断されているサーバであるか、つまり正常な動作が不可能なサーバであるかをチェックする（ステップＳ４）。
【００３０】
もし、対象サーバ１０-iが、電源が遮断されているサーバ、或いは障害が発生したサーバ自身であるならば、つまり正常に動作できないサーバであるならば、サービス制御決定機構１０２は、当該サーバでは対象サービスを開始または引き継ぐことが不可能であると判断する。この場合、サービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を再び参照し、対象サービスの実行が可能であるとして登録されているサーバの中に未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまりサーバ１０-iの次の優先度のサーバを対象サーバとして選択する（ステップＳ１〜Ｓ３）。そしてサービス制御決定機構１０２は、この新たな対象サーバについて、再度ステップＳ４を実行する。
【００３１】
これに対し、ステップＳ３で選択されたサーバ１０-i、即ち対象サーバ１０-iが、電源が遮断されているサーバでも、障害が発生したサーバ自身でもないならば、つまり正常に動作可能なサーバであるならば、サービス制御決定機構１０２は、当該サーバ１０-iで対象サービスを実行できる可能性があると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-iと当該サーバ１０-iで現在実行されているサービスとをもとに、サービス間関係情報テーブルＴＢＬ１を参照して、その参照結果から、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係（サーバ内の強い排他関係）がないか否か、つまり対象サーバ１０-iで現在実行されているサービスと対象サービスとを、当該対象サーバ１０-iで並行して実行可能か否かをチェックする（ステップＳ５，Ｓ６）。
【００３２】
もし、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係があるならば、サービス制御決定機構１０２は、実行中のサービス（現状サービス）を優先させるために、対象サービスを対象サーバ１０-iで実行することはできないと判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまり対象サービスを実行することはできないと判断されたサーバ１０-iの次の優先度のサーバを対象サーバとして選択し（ステップＳ１〜Ｓ３）、この新たな対象サーバについて、再度ステップＳ４を実行する。
【００３３】
これに対し、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係がないならば、サービス制御決定機構１０２は対象サービスを対象サーバ１０-iで実行できると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-i内のサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ７）。
【００３４】
なお、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバについて、対象サービスの実行が可能かをチェックした結果、当該対象サービスが起動できなかった場合には、つまり未チェックのサーバが残っていない場合には（ステップＳ２）、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００３５】
このように、本発明の第１の実施形態においては、クラスタシステム上で実行し得るサービス間に、サーバ内の強い排他関係を持たせることで、例えばデータベース（ＤＢ）をアクセスするサービス（ＤＢアプリケーション）と、ＤＢをバックアップするサービス（ＤＢバックアップアプリケーション）など、本質的に同じサーバで動作することができないサービス（アプリケーション）を、クラスタシステムとして一元的に制御することができる。
【００３６】
［第１の実施形態の第１の変形例］
次に、本発明の第１の実施形態の第１の変形例について説明する。この第１の変形例の特徴は、サービス間の排他関係が、サーバ内はなくて、クラスタシステム内（クラスタシステム全体）で定義されている点にある。つまり第１の変形例では、サービス間関係情報テーブルＴＢＬ１に登録されたサービス間関係情報は、クラスタシステム上で実行し得る各サービスについて、そのサービスが実行されている場合に、当該クラスタシステム内で並行して実行することができないサービスとの関係、つまり同じクラスタシステム内で並行して実行することが本質的にできないサービス相互間の関係を示す。このような関係（排他関係）を、クラスシステム内の強い排他関係と呼ぶ。第１の変形例におけるシステム構成は、第１の実施形態で適用された図１のシステム構成と同様である。
【００３７】
以下、本発明の第１の実施形態の第１の変形例におけるサービス制御処理について、便宜的に図１のシステムを援用しながら、図５のフローチャートを参照して説明する。
【００３８】
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００３９】
まずサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１を参照し、クラスタシステム内に対象サービスとの間で排他関係を持つサービスが存在し、しかも当該排他関係を持つサービスが実行中かのチェックを行う（ステップＳ１１，Ｓ１２）。もし、排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、実行中のサービス（現状サービス）を優先させるために、開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００４０】
これに対し、対象サービスとの間で排他関係を持つ実行中のサービスが存在しないならば、サービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、対象サービスの実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ１３〜Ｓ１５）。今、サーバ１０-i（ｉは１〜ｎのいずれか）が選択されたものとする。
【００４１】
サービス制御決定機構１０２は、サーバ１０-iを対象サーバとして選択すると、当該サーバ１０-iについて、障害が発生したサーバ自身であるか、或いは電源が遮断されているサーバであるか、つまり正常な動作が不可能なサーバであるかをチェックする（ステップＳ１６）。
【００４２】
もし、対象サーバ１０-iが、電源が遮断されているサーバ、或いは障害が発生したサーバ自身であるならば、サービス制御決定機構１０２は、当該サーバ１０-iでは対象サービスを開始することが不可能であると判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまりサーバ１０-iの次の優先度のサーバを対象サーバとして選択し（ステップＳ１３〜Ｓ１５）、この新たな対象サーバについて、再度ステップＳ１６を実行する。
【００４３】
これに対し、対象サーバ１０-iが、電源が遮断されているサーバでも、障害が発生したサーバ自身でもないならば、サービス制御決定機構１０２は、当該サーバ１０-iで対象サービスを実行できると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-iのサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ１７）。
【００４４】
なお、クラスタシステム内に対象サービスとの間で排他関係を持つ実行中のサービスが存在しなくても、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバが、いずれも障害発生サーバ自身であるか、或いは電源が遮断されているサーバである場合には、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００４５】
このように、上記第１の実施形態の第１の変形例においては、クラスタシステム上で実行し得るサービス間に、当該クラスタシステム内の強い排他関係を持たせることで、本質的に同じクラスタシステム内で動作することができないサービスをクラスタシステムとして一元的に制御することが可能となる。
【００４６】
［第１の実施形態の第２の変形例］
次に、本発明の第１の実施形態の第２の変形例について説明する。この第２の変形例の第１の特徴は、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報で示されるサービス間の排他関係が、上記第１の変形例と同様に、クラスタシステム内（クラスタシステム全体）で定義されており、クラスタシステム内の強い排他関係によるクラスタ制御が行われる点にある。第２の変形例の第２の特徴は、上記第１の変形例とは異なって、実行中のサービスを優先させるのではなく、開始または引き継ぐべきサービスを優先させる点、つまり現状サービス優先ではなくて後サービス優先とする点にある。第２の変形例におけるシステム構成は、第１の実施形態で適用された図１のシステム構成と同様である。
【００４７】
以下、本発明の第１の実施形態の第２の変形例におけるサービス制御処理について、便宜的に図１のシステムを援用しながら、図６のフローチャートを参照して説明する。
【００４８】
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００４９】
まずサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１を参照し、クラスタシステム内で実行中のサービスの中に、対象サービスとの間で排他関係を持つサービスが存在するかのチェックを行う（ステップＳ２１，Ｓ２２）。
【００５０】
もし、対象サービスとの間で排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、当該実行中のサービスを全て特定し、対象サービス（後サービス）の実行を優先させるために、その特定された全サービスの停止を、サービス実行機構１０３-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に対して、対象サービスの開始または引継を指示する（ステップＳ４５）。これにより、排他関係に拘わらずに、サービスが実行可能な最もサーバ優先度の高いサーバにて対象サービスを開始または引き継がせることができる。
【００７８】
これに対し、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバについてステップＳ４４のチェックを行っても、目的のサーバ（対象サーバ）が見つからず、未チェックのサーバが存在しないならば（ステップＳ４２のＮＯ）、サービス制御決定機構１０２は、排他関係を考慮しないでも、対象サービスの開始または引継ができないものと判断する。この対象サービスの開始または引継ができない要因は、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全てのサーバの電源が遮断されているか、或いは障害が発生しているためである。この場合、サービス制御決定機構１０２は、対象サービスの開始または引継ができない旨を当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００７９】
このように、上記第１の実施形態の第４の変形例においては、クラスタシステム上で実行し得るサービス間のサーバ内の弱い排他関係を持たせ、できれば同一サーバ上で並行して実行させたくないサービスを設定することで、クライアントからのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバで動かすという運用ができる。これにより、負荷分散を考慮した設定が容易になる。
【００８０】
［第２の実施形態］
図９は本発明の第２の実施形態に係るクラスタシステムの構成を示すブロック図である。なお、図１と同様の部分には、便宜的に同一符号を付して、詳細な説明を省略する。
【００８１】
図９のクラスタシステムが、図１のクラスタシステムと主として異なる点は、サーバ１０-1〜１０-nが有するクラスタ制御機構１０１-1〜１０１-nのサービス制御決定機構１０２-1〜１０２-nに、サービス間関係情報テーブルＴＢＬ１及び実行サーバ情報テーブルＴＢＬ２に加えて、サービス優先度情報テーブルＴＢＬ３を持たせたことにある。
【００８２】
サービス優先度情報テーブルＴＢＬ３は、図９のクラスタシステム上で実行し得るサービスの優先度情報を登録したテーブルである。このテーブルＴＢＬ３のデータ構造の一例を図１２に示す。図１２のテーブルＴＢＬ３には、４つのサービスＡ，Ｂ，Ｃ，Ｄの優先度として、それぞれ優先度１，優先度３，優先度２，優先度４が設定されている。この場合、サービスＡ，Ｂ，Ｃ，Ｄの優先度（重要度）は、サービスＡが最も高く、以下サービスＣ、サービスＢ、サービスＤの順であることが示される。
【００８３】
なお、第２の実施形態において、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報は、第１の実施形態と同様に、相異なるサービスのサーバ内の強い排他関係、つまり同一サーバ上で、本質的には並行して動作できないサービスを示す。
【００８４】
次に、本発明の第２の実施形態におけるサービス制御処理について、図１０のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００８５】
まずサービス制御決定機構１０２は、上記第１の実施形態における図４中のステップＳ１〜Ｓ４と同様の処理（ステップＳ５１〜Ｓ５４）を実行する。即ちサービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されているサーバの中から、障害が発生しておらず、且つ電源が遮断されていないサーバ、つまり対象サービスを実行できる可能性のあるサーバを、優先度の高い順に１つだけ探す。
【００８６】
もし、目的のサーバ、例えばサーバ１０-iが見つけられたなら、サービス制御決定機構１０２は、当該サーバ１０-iと当該サーバ１０-iで現在実行されているサービスとをもとに、サービス間関係情報テーブルＴＢＬ１を参照する（ステップＳ５５）。そしてサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１の参照結果から、サーバ（対象サーバ）１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在するか否かをチェックする（ステップＳ５６）。
【００８７】
もし、対象サーバ１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在しないならば、サービス制御決定機構１０２は、対象サーバ１０-iのサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ６０）。
【００８８】
これに対し、対象サーバ１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３を参照する（ステップＳ５７）。そしてサービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３に登録されている各サーバの優先度のうち、サーバ１０-i上で現在実行中のサービスの優先度と上記対象サービスの優先度とを比較して、現在実行中のサービスの方が優先度が低いか否かをチェックする（ステップＳ５８）。
【００８９】
もし、現在実行中のサービスの方が優先度が低いならば、つまり対象サービスの方が優先度が高いならば、サービス制御決定機構１０２は現在実行中のサービス、つまり対象サービスとの間で排他関係のあるサービスの停止を、対象サーバ１０-iのサービス実行機構１０３-iに対して指示する（ステップＳ５９）。しかる後にサービス制御決定機構１０２は、上記サービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ６０）。
【００９０】
一方、現在実行中のサービスの方が優先度が高いならば、サービス制御決定機構１０２は、サーバ１０-iでは対象サービスを開始できないと判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバを対象サーバとして選択し（ステップＳ５１〜Ｓ５３）、この新たな対象サーバについて、再度ステップＳ５４を実行する。そして、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されているサーバのいずれにおいても対象サービスを開始させることができなかった結果、未チェックのサーバがなくなったならば（ステップＳ５２）、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００９１】
このように、本発明の第２の実施形態においては、サービス間にサーバ内の強い排他関係を持たせるだけでなく優先度をも持たせることで、サービス間の排他関係を考慮しつつ優先度の高いサービスを優先的に開始または継続させることができる。
【００９２】
［第３の実施形態］
図１１は本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図である。なお、図９と同様の部分には、便宜的に同一符号を付して、詳細な説明を省略する。
【００９３】
図１１のクラスタシステムが、図９のクラスタシステムと主として異なる点は、サーバ１０-1〜１０-nが有するクラスタ制御機構１０１-1〜１０１-nのサービス制御決定機構１０２-1〜１０２-nに、サービス間関係情報テーブルＴＢＬ１、実行サーバ情報テーブルＴＢＬ２及びサービス優先度情報テーブルＴＢＬ３に加えて、サービス実行可能情報テーブルＴＢＬ４を持たせたことにある。
【００９４】
サービス実行可能情報テーブルＴＢＬ４は、図１１のクラスタシステム上で実行し得るサービス毎に、実行の可否を示すサービス実行可能情報を登録したテーブルである。このサービス毎の実行可否は、クライアント（ユーザ）からの要求に応じて設定可能である。つまり、クライアントからサービス制御決定機構１０２にネットワーク１２を介してあるサービスを実行して欲しいという情報が与えられた場合には、上記テーブルＴＢＬ４内の当該サービスに対応する実行可否状態は「可能」に設定される。また、クライアントからサービス制御決定機構１０２にサービスを実行して欲しくないというい情報が与えられた場合には、上記テーブルＴＢＬ４内の当該サービスに対応する実行可否状態は「可能でない」に設定される。また、バッチサービス（バッチ処理）のように、ある処理の実行後やある時間経過後に完了してしまうサービスが完了した場合にも、当該サービスに対応する実行可否状態は「可能でない」に設定される。このテーブルＴＢＬ４のデータ構造の一例を図１３に示す。
【００９５】
なお、第３の実施形態において、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報は、第１の実施形態で適用されたようなサーバ内の排他関係（サービス間の排他関係）と、第１の実施形態の第１の変形例で適用されたようなクラスタシステム内の排他関係（サービス間の排他関係）とを選択的に定義（設定）可能である。ここでは、上記サーバ内の排他関係、つまり同じサーバ上で本質的に並行して動作できないサービス間の排他関係を、「排他関係（サーバ）」と表現する。また、上記クラスタシステム内の排他関係、つまり同じクラスタシステム上で本質的に並行して動作できないサービス間の排他関係を、「排他関係（システム）」と表現する。
【００９６】
次に、本発明の第３の実施形態におけるサービス制御処理について、図１４及び図１５のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからの要求によりサービス実行可能情報テーブルＴＢＬ４に登録されているサービス実行可能情報に変更があった場合、バッチ処理などの完了によりテーブルＴＢＬ４中の該当するサービスの実行可否状態が「可能」から「可能でない」に変更された場合、サービスが動作しているサーバに障害が発生した場合、サービスに障害が発生した場合、或いはクラスタシステム内のサーバが復旧した場合に、図１４及び図１５のフローチャートに従う処理を開始する。
【００９７】
まずサービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３を参照し、図１１のクラスタシステム上で実行し得るサービスを、サービス優先度に従い、サービス優先度の高い順に１台ずつ対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。
【００９８】
サービス制御決定機構１０２は、対象サービスを選択すると、サービス実行可能情報テーブルＴＢＬ４を参照して、当該対象サービスがクラスタシステム上で実行可能であるか否かをチェックする（ステップＳ６４，Ｓ６５）。
【００９９】
もし、対象サービスが実行可能でないならば、サービス制御決定機構１０２はサービス優先度情報テーブルＴＢＬ３を再び参照し、未チェックのサービスが残っているならば、その未チェックのサービスのうち最も優先度の高いサービスを対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。
【０１００】
これに対し、対象サービスが実行可能ならば、サービス制御決定機構１０２はサービス実行可能情報テーブルＴＢＬ４を参照し、図１１のクラスタシステム内で当該対象サービスとの間で排他関係を持つサービス、つまり「排他関係（システム）」を持つサービスを特定する（ステップＳ６６）。そしてサービス制御決定機構１０２は、上記特定されたサービス、つまり対象サービスとの間で「排他関係（システム）」を持つサービスの実行（クラスタシステム内のいずれかのサーバでの実行）が（後述するステップＳ７３で）既に計画されているかをチェックする（ステップＳ６７）。
【０１０１】
もし、上記特定されたサービスの実行が計画されているならば、サービス制御決定機構１０２はステップＳ６３で選択された対象サービスを実行計画に盛り込むことは諦める。この場合、サービス制御決定機構１０２は、未チェックのサービスが残っているならば、その未チェックのサービスのうち最も優先度の高いサービス、つまり実行計画に盛り込まれないこととなったサービスの次の優先度のサービスを選択して（ステップＳ６１〜Ｓ６３）、実行計画に盛り込めないかチェックする（ステップＳ６４〜Ｓ６７）。
【０１０２】
これに対し、上記特定されたサービスの実行が計画されていないならば、サービス制御決定機構１０２は実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、ステップＳ６３で選択された対象サービスの実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ６８〜Ｓ７０）。
【０１０３】
サービス制御決定機構１０２は、対象サーバを選択すると、サービス間関係情報テーブルＴＢＬ１を参照し、上記ステップＳ６３で選択された対象サービスとの間で当該対象サーバ内で排他関係を持つサービス、つまり「排他関係（サーバ）」を持つサービスを特定する（ステップＳ７１）。そしてサービス制御決定機構１０２は、上記特定されたサービス、つまり対象サービスとの間で「排他関係（サーバ）」を持つサービスの対象サーバ内での実行が既に計画されているかをチェックする（ステップＳ７２）。
【０１０４】
もし、上記特定されたサービスの対象サーバ内での実行が計画されているならば、サービス制御決定機構１０２はステップＳ６３で選択された対象サービスをステップ７０で選択された対象サーバでの実行計画に盛り込むことは諦める。この場合、サービス制御決定機構１０２は、次の優先度のサーバが存在するならば、当該サーバ内で対象サービスが実行可能であるかのチェックを再試行する。即ちサービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサービス、つまり現在の対象サーバの次の優先度のサーバを新たな対象サーバとして選択する（ステップＳ６８〜Ｓ７０）。そしてサービス制御決定機構１０２は、対象サービスとの間で「排他関係（サーバ）」を持つサービスの対象サーバ内での実行が既に計画されているか、つまり対象サービスを対象サーバ内での実行計画に盛り込めるかをチェックする（ステップＳ７１，Ｓ７２）。
【０１０５】
これに対し、上記特定されたサービスの対象サーバ内での実行が計画されていないならば、サービス制御決定機構１０２は、ステップＳ６３で選択された対象サービスを当該対象サーバで実行すること、つまり当該対象サービスを当該対象サーバでの実行計画に盛り込むことを決定する（ステップＳ７３）。
【０１０６】
サービス制御決定機構１０２は、対象サービスを当該対象サーバで実行することを決定した場合、或いは対象サービスが実行可能なサーバが見つからなかった場合、次の優先度のサービスが存在するならば、そのサービスを新たな対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。そしてサービス制御決定機構１０２は、新たな対象サービスが実行可能なサーバが存在するならば（ステップＳ６４，Ｓ６５）、当該サーバを対象サーバとして特定し、当該対象サーバ内で対象サービスが実行可能であるかのチェックを再試行する。（ステップＳ６６〜Ｓ７２）。
【０１０７】
このようにして、サービス実行可能情報テーブルＴＢＬ４に登録されている全サービスについて処理した結果、未チェックのサービスが残っていないならば（ステップＳ６２）、サービス制御決定機構１０２は、当該全サービスのうちの計画済みのサービスを実行させるための処理を次のように行う。まずサービス制御決定機構１０２は、各サーバ１０-i（ｉ＝１〜ｎ）で現在実行中のサービスのうち、当該サーバ１０-iでの実行が計画されていないサービスについて、当該サーバ１０-i内のサービス実行機構１０３-iに対して当該計画されていないサービスの停止を指示する（ステップＳ７４）。しかる後にサービス制御決定機構１０２は、各サーバ１０-i（ｉ＝１〜ｎ）で実行が計画されているサービスのうち、未だ実行されていないサービスの実行開始を当該サーバ１０-i内のサービス実行機構１０３-iに対して指示する（ステップＳ７５）。
【０１０８】
このように、本発明の第３の実施形態においては、図１１のクラスタシステム上で実行し得るサービスについて、サービス優先度の高い順に、当該サービスが実行可能状態に設定されているかを調べるようにしている。また、第３の実施形態においては、実行可能状態に設定されているサービスについて、サービス間の排他関係を考慮しながら、当該サービスを実行可能なサーバの優先順位順に、当該サービスを実行するサーバを決定するようにしている。
【０１０９】
これにより、第３の実施形態によれば、次に列挙する効果を得ることができる。
（１）サービスを実行するのに最も適したサーバが障害から復旧した際に、そのサーバにサービスを移すことが簡単な設定だけで行える。
（２）クライアント（ユーザ）に、サービスの開始ではなくて当該サービスの実行可能状態を設定させることで、当該サービスの実行の開始を指示する開始命令であって、当該サービスを仮に開始したならば、当該サービスよりも優先度の高いサービスに悪影響を与えるような開始命令があった際にも、優先度に従い実行しないという処理が容易に実現できる。
【０１１０】
（３）できる限り優先度の高いサービスを、できるだけ優先度の高いサーバで実行することを容易にする。
【０１１１】
上記各実施形態または各変形例では、サービス制御決定機構１０２-1〜１０２-nに、テーブルＴＢＬ１，ＴＢＬ２、またはテーブルＴＢＬ１〜ＴＢＬ３、またはテーブルＴＢＬ１〜ＴＢＬ４を持たせている。しかし、これらのテーブルはサービス制御決定機構１０２からアクセス可能な記憶手段に格納されていればよく、これらのテーブルを、当該サービス制御決定機構が有している必要はない。
【０１１２】
なお、本発明は、上記各実施形態及び各変形例に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０１１３】
【発明の効果】
以上詳述したように本発明によれば、クラスタシステム上で実行し得るサービスに関し、相異なるサービス相互の実行に関する関係を定義したサービス間関係情報を適用し、目的とするサービス（例えば開始または引継を必要とするサービス）との間でサービス相互の実行に関する関係を持つ他のサービスの存在を考慮して、当該目的とするサービスを実行するサーバ計算機を決定するようにしたので、クラスタシステムにおける柔軟なサービスの運用が実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図。
【図２】図１中のサービス間関係情報テーブルＴＢＬ１のデータ構造例を示す図。
【図３】図１中の実行サーバ情報テーブルＴＢＬ２のデータ構造例を示す図。
【図４】本発明の第１の実施形態におけるサービス制御処理を説明するためのフローチャート。
【図５】同第１の実施形態の第１の変形例におけるサービス制御処理を説明するためのフローチャート。
【図６】本発明の第１の実施形態の第２の変形例におけるサービス制御処理を説明するためのフローチャート。
【図７】本発明の第１の実施形態の第３の変形例におけるサービス制御処理を説明するためのフローチャート。
【図８】本発明の第１の実施形態の第４の変形例におけるサービス制御処理を説明するためのフローチャート。
【図９】本発明の第２の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１０】本発明の第２の実施形態におけるサービス制御処理を説明するためのフローチャート。
【図１１】本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１２】図９及び図１１中のサービス優先度情報テーブルＴＢＬ３のデータ構造例を示す図。
【図１３】図１１中のサービス実行可能情報テーブルＴＢＬ４のデータ構造例を示す図。
【図１４】本発明の第３の実施形態におけるサービス制御処理を説明するためのフローチャートの一部を示す図。
【図１５】本発明の第３の実施形態におけるサービス制御処理を説明するためのフローチャートの残りを示す図。
【符号の説明】
１０-1〜１０-n…サーバ（サーバ計算機）
１１，１２…ネットワーク
１０１…（仮想の）クラスタ制御機構
１０１-1〜１０１-n…クラスタ制御機構
１０２…（仮想の）サービス制御決定機構
１０２-1〜１０２-n…サービス制御決定機構
１０３-1〜１０３-n…サービス実行機構
ＴＢＬ１…サービス間関係情報テーブル（サービス間関係情報登録手段）
ＴＢＬ２…実行サーバ情報テーブル（実行サーバ情報登録手段）
ＴＢＬ３…サービス優先度情報テーブル（サービス優先度情報登録手段）
ＴＢＬ４…サービス実行可能情報テーブル（サービス実行可能情報登録手段）
【発明の属する技術分野】
本発明は、複数台のサーバ計算機から構成されるクラスタシステムに係り、特に開始または引継の必要な目的とするサービスを実行するサーバ計算機を決定するのに好適なクラスタシステム及び同システムにおけるサービス制御方法に関する。
【０００２】
【従来の技術】
システムの可用性を高める計算機システムとして、従来からクラスタシステムが知られている。このクラスタシステムは、同一のサービス（アプリケーションプログラム）を提供可能な複数台の計算機（サーバ計算機）から構成される（例えば、非特許文献１参照）。
【０００３】
クラスタシステムは、サービスを起動・停止する計算機を決定する機構（サービス制御決定機構）を有している。このサービス制御決定機構は、現在サービスを提供している計算機に障害が発生したときに、クラスタシステム内の他の正常な計算機の中からそのサービスを引き継ぐ計算機を決定して、そのサービスを継続させることにより、サービスが使用不能になる時間を最小限にしている。
【０００４】
【非特許文献１】
金子哲夫、外１名、「クラスタソフトウェア」、東芝レビュー、１９９９年、Vol.54、No.12、p.18-21
【０００５】
【発明が解決しようとする課題】
上記したように、従来のクラスタシステムでは、現在サービスを提供している計算機（サーバ計算機）に障害が発生したために、そのサービスを引き継ぐ計算機を決定する際に、他の正常な計算機にサービスを引き継ぐという簡単なルールだけに従っている。このため従来のクラスタシステムでは、多数のサーバ計算機を用いた環境において、柔軟にサービスを起動することが難しいという問題がある。
【０００６】
本発明は上記事情を考慮してなされたものでその目的は、相異なるサービス相互の実行に関する関係を定義した情報を利用することで柔軟なサービスの運用が実現できるクラスタシステム及び同システムにおけるサービス制御方法を提供することにある。
【０００７】
【課題を解決するための手段】
本発明の１つの観点によれば、複数台のサーバ計算機から構成されるクラスタシステムが提供される。このシステムは、クラスタシステム上で実行し得るサービスに関し、相異なるサービス相互の実行に関する関係を定義したサービス間関係情報が登録されるサービス間関係情報登録手段と、サービス制御決定機構とを備えている。このサービス制御決定機構は、目的とするサービスの実行が可能なサーバ計算機の中から、上記サービス間関係情報登録手段に登録されているサービス間関係情報に基づいて、目的とするサービスを実行するサーバ計算機を決定する。
【０００８】
このような構成においては、目的とするサービス（例えば開始または引継を必要とするサービス）との間でサービス相互の実行に関する関係を持つ他のサービスの存在を考慮して、当該目的とするサービスを実行するサーバ計算機が決定される、このため、目的とするサービスを実行するサーバ計算機として単に正常な計算機を当てる従来技術と異なり、クラスタシステムにおける柔軟なサービスの運用が可能となる。
【０００９】
ここで、上記サービス間関係情報により、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係を排他関係として定義すると共に、上記サービス制御決定機構に、目的とするサービスとの間で排他関係（サーバ内の強い排他関係）のあることが示されているサービスを実行中のサーバ計算機以外の正常なサーバ計算機の中から、目的とするサービスを実行するサーバ計算機を決定する手段を持たせるとよい。このようにすると、目的とするサービスとの間でサーバ内の強い排他関係のあることが示されているサービス、つまり目的とするサービスと同一サーバ計算機内で並行して実行できないサービスを実行中のサーバ計算機を、当該目的とするサービスを実行するサーバ計算機の候補から外すことができる。よって、例えばデータベース（ＤＢ）をアクセスするサービス（ＤＢアプリケーション）と、ＤＢをバックアップするサービス（ＤＢバックアップアプリケーション）など、本質的に同じサーバで動作することができないサービス（アプリケーション）を、クラスタシステムとして一元的に制御することができる。
【００１０】
上記排他関係は、目的とするサービスとの間にサーバ内の強い排他関係のあるサービスを実行中のサーバ計算機において、当該実行中のサービスが優先される「現状サービス優先」の排他関係である。しかし、目的とするサービスを優先させる「後サービス」優先の排他関係を適用することも可能である。ここでも、目的とするサービスとの間にサーバ内の強い排他関係のあるサービスを実行中でないサーバ計算機は、当該目的とするサービスを実行するサーバ計算機の候補とすればよい。一方、目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機内で、当該目的とするサービスとの間にサーバ内の強い排他関係のあるサービスが実行中の場合には、当該実行中のサービスを全て停止し、しかる後に、当該選択されたサーバ計算機を上記候補として扱えばよい。この候補（選択されたサーバ計算機）は、正常に動作可能であるならば、当該目的とするサービスを実行するサーバ計算機として決定される。これにより、サービスの開始または継続が不可欠であるサービスに対応でき、より柔軟性の高いクラスタシステムが実現できる。
【００１１】
また、上記の排他関係は、本質的に同一サーバ計算機内で並行して実行できないサービス相互の関係（サーバ内の強い排他関係）であるが、本質的に同一クラスタシステム内で並行して実行できないサービス相互の関係（クラスタシステム内の強い排他関係）を適用することも可能である。ここでは、目的とするサービスとの間でクラスタシステム内の強い排他関係のあるサービスがクラスタシステム内で実行中でない場合に、目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、目的とするサービスを実行するサーバ計算機を決定すればよい。このようにすると、本質的に同じクラスタシステム内で動作することができないサービスをクラスタシステムとして一元的に制御することが可能となる。また、「後サービス優先」のクラスタシステム内の排他関係を適用することも可能である。ここでは、目的とするサービスとの間でクラスタシステム内の排他関係のあるサービスが実行中の場合には、当該実行中のサービスを全て停止し、しかる後に目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、当該目的とするサービスを実行するサーバ計算機を決定すればよい。この構成においても、より柔軟性の高いクラスタシステムが実現可能となる。
【００１２】
また、サービス間関係情報によって定義可能な排他関係として、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係であって、実行中のサービスを優先させる関係である第１の排他関係と、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係であって、実行中のサービスより目的とするサービスを優先させる関係である第２の排他関係とを適用することも可能である。ここでは、目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機が正常に動作可能なサーバ計算機であり、且つ当該目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に第１の排他関係及び第２の排他関係が共にない場合には直ちに、当該目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に第１の排他関係はないものの、第２の排他関係がある場合には、当該選択されたサーバ計算機内で実行中の、当該目的とするサービスとの間で第２の排他関係のある全てのサービスを停止させた後に、当該選択されたサーバ計算機を当該目的とするサービスを実行するサーバ計算機として決定するとよい。このようにすると、クライアント端末からのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバ計算機で動かすという運用ができる。
【００１３】
また、サービス間関係情報によって定義可能な排他関係として、同一サーバ計算機内で並行して実行することが本質的にできないサービス相互間の関係、つまりサーバ内の強い排他関係に代えて、同一サーバ計算機内で並行して実行することが好ましくないサービス相互間の関係、つまりサーバ内の弱い排他関係を適用することも可能である。ここでは、目的とするサービスの実行が可能なサーバ計算機の中から、当該目的とするサービスとの間でサーバ内の弱い排他関係にあるサービスを実行中のサーバ計算機と正常な動作が不可能なサーバ計算機とを除いて、当該目的とするサービスを実行するサーバ計算機を決定するようにし、当該目的とするサービスを実行するサーバ計算機を決定できなかった場合に限り、上記排他関係を考慮することなく、当該目的とするサービスの実行が可能なサーバ計算機の中から、正常な動作が不可能なサーバ計算機を除いて、当該目的とするサービスを実行するサーバ計算機を決定するとよい。このようにすると、クライアント端末からのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバ計算機で動かすという運用ができる。これにより、負荷分散を考慮した設定が容易になる。
【００１４】
また、クラスタシステム上で実行し得る各サービスの優先度を定義したサービス優先度情報が登録されるサービス優先度情報登録手段を追加することも可能である。ここでは、目的とするサービスと当該目的とするサービスを実行するサーバ計算機の候補になり得るものとして選択されたサーバ計算機内で実行中のサービスとの間に排他関係があっても、当該目的とするサービスの方が当該選択されたサーバ計算機内で実行中のサービスより優先度が高いことが上記サービス優先度情報により示されている場合には、当該選択されたサーバ計算機内で実行中のサービスであって、目的とするサービスとの間で排他関係のあるサービスを全て停止させ、しかる後に当該選択されたサーバ計算機を当該目的とするサービスを実行するサーバ計算機として決定するとよい。これにより、サービス間の排他関係を考慮しつつ優先度の高いサービスを優先的に開始または継続させることができる。
【００１５】
また、上記サービス優先度情報登録手段に加えて、クラスタシステム上で実行し得るサービス毎に、当該サービスの実行可否がクラスタシステムを利用するクライアント端末から設定可能なサービス実行可能情報が登録されるサービス実行可能情報登録手段を追加することも可能である。ここでは、クラスタシステムで実行し得るサービスを上記サービス優先度情報に従って優先度順に選択し、この選択されたサービスが実行可能であると上記サービス実行可能情報により示されている場合に、当該サービスとの間でサービス相互の実行に関する関係を持つサービスを上記サービス間関係情報に基づいて特定するとよい。また、この特定されたサービスの実行が未だ計画されていない場合に、上記選択されたサービスを実行計画の対象として決定すると共に、当該サービスを実行するサーバ計算機を、目的とするサービスの実行が可能なサーバ計算機の中から決定するとよい。このようにすると、特に、サービスの実行の開始を指示する開始命令であって、当該サービスを仮に開始したならば、当該サービスよりも優先度の高いサービスに悪影響を与えるような開始命令があった際にも、優先度に従い実行しないという処理が容易に実現できる。
【００１６】
なお、以上のクラスタシステムに係る本発明は、当該クラスタシステムにおいて目的とするサービスを実行するサーバ計算機を決定するためのサービス制御方法に係る発明としても成立する。
【００１７】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１８】
［第１の実施形態］
図１は本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図である。
図１に示すクラスタシステムは、各種のサービス（アプリケーションプログラム）を提供可能なｎ（ｎは２以上の自然数）台のサーバ計算機（以下、単にサーバと称する）１０-1〜１０-nから構成されている。サーバ１０-1〜１０-nは、２つのネットワーク１１及び１２により相互接続されている。ネットワーク１２には、クラスタシステム内のサーバ１０-1〜１０-nからのサービスの提供を受ける、つまりクラスタシステムを利用する、図示せぬクライアント端末（以下、単にクライアントと称する）が接続されている。本実施形態において、ネットワーク１１は、サーバ１０-1〜１０-nが相互に通信を行うのに用いられ、ネットワーク１２は、サーバ１０-1〜１０-nがクライアントとの間で通信を行うのに用いられる。なお、通信効率は低下するものの、サーバ１０-1〜１０-n相互の通信と、サーバ１０-1〜１０-nとクライアントとの間の通信とに、１つのネットワークを用いてもよい。
【００１９】
サーバ１０-1〜１０-nは、クラスタとしての制御を司るためのクラスタ制御機構１０１-1〜１０１-nを備えている。クラスタ制御機構１０１-1〜１０１-nは、それぞれネットワーク１１を介して互いに通信を行いながら同一の処理を実行する。これにより、クラスタ制御機構１０１-1〜１０１-nは、クラスシステム全体で１つの仮想的なクラスタ制御機構１０１を構成する。
【００２０】
クラスタ制御機構１０１-1〜１０１-nは、サービス制御決定機構１０２-1〜１０２-nと、サービス実行機構１０３-1〜１０３-nとを含む。サービス制御決定機構１０２-1〜１０２-nは、サービスを起動・停止するサーバを決定する。即ちサービス制御決定機構１０２-1〜１０２-nは、いずれのサーバでいずれのサービスを実行させるかを決定すると共に、いずれのサーバで実行されているいずれのサービスを停止させるかを決定する。サービス実行機構１０３-1〜１０３-nは、サービス制御決定機構１０２-1〜１０２-nの決定に従い、サービスを実行する。
【００２１】
サービス制御決定機構１０２-1〜１０２-nは、サービス間関係情報テーブルＴＢＬ１と実行サーバ情報テーブルＴＢＬ２とを有している。
サービス間関係情報テーブルＴＢＬ１は、図１のクラスタシステム上で実行し得る相異なるサービスの間の排他関係の情報（以下、サービス間関係情報と称する）を登録したテーブルである。本実施形態における相異なるサービスの間の排他関係とは、あるサービスが実行されている場合には、同じサーバ内で別のあるサービスを実行することができないという関係、つまり同じサーバ内で並行して実行することが本質的にできないサービス相互間の関係である。このような排他関係を、サーバ内の強い排他関係と呼ぶ。
【００２２】
サービス間関係情報テーブルＴＢＬ１のデータ構造の一例を図２に示す。図２のテーブルＴＢＬ１には、例えばサービスＡ及びＢの間に排他関係があることが示されている。この場合、サービスＡの実行中は、同じサーバ内でサービスＢを実行できず、逆にサービスＢの実行中は、同じサーバ内でサービスＡを実行できない。つまり、排他関係のあるサービスＡ及びＢは、同一サーバ内で並行して実行できない。
【００２３】
実行サーバ情報テーブルＴＢＬ２は、図１のクラスタシステム上で実行し得るサービス（を示すサービス名）毎に、当該サービスを当該システム内のいずれのサーバで実行（起動）できるかを示す情報（以下、実行サーバ情報と称する）を登録したテーブルである。この実行サーバ情報は、当該情報により対応するサービスを実行できることが示されているサーバ毎の優先度を含んでいる。このサーバ毎の優先度は、対応するサービスをいずれのサーバで実行するのがより好ましいかを示す。ここでは、優先度の値が小さいほど高優先度であることを示す。
【００２４】
実行サーバ情報テーブルＴＢＬ２のデータ構造例を図３に示す。図３のテーブルＴＢＬ２には、例えばサービスＡは、サーバＡ〜ＤのうちのサーバＡ〜Ｃで実行可能なことが示されている。また、このサービスＡを実行可能なサーバＡ，Ｂ，Ｃの優先度として、それぞれ優先度１，優先度３，優先度２が設定されている。これにより、サービスＡを実行するサーバとしては、サーバＡが最も好ましく、以下サーバＣ、サーバＢの順であることが示される。
【００２５】
サービス制御決定機構１０２-1〜１０２-nは、それぞれネットワーク１１を介して互いに通信を行いながら同一の処理を実行する。これによりサービス制御決定機構１０２-1〜１０２-nは、クラスシステム全体で１つの仮想的なサービス制御決定機構１０２を構成する。サービス制御決定機構１０２-1〜１０２-nが有するサービス間関係情報テーブルＴＢＬ１及び実行サーバ情報テーブルＴＢＬ２は常に同一内容となるように制御される。
【００２６】
サービス制御決定機構１０２-1〜１０２-nは、サービスの開始命令を受けた場合、或いはクラスタシステム内のサービス（サーバ）に障害が発生した場合に、サービス間関係情報テーブルＴＢＬ１に登録されているサービス間関係情報及び実行サーバ情報テーブルＴＢＬ２に登録されている実行サーバ情報をもとに、クラスタシステム内のいずれのサーバでサービスを実行すべきかを決定する。ここでは、サービス制御決定機構１０２-1〜１０２-nのうち、サービスを実行すべきサーバ１０-i（ｉは１〜ｎのいずれか）内のサービス制御決定機構１０２-iにより、サービス実行機構１０３-iが制御される。但し、以下の説明では、煩雑さを避けるために、仮想的なサービス制御決定機構１０２が上述の決定を行って、対応するサーバ１０-i内のサービス実行機構１０３-iを制御するものとして扱う。
【００２７】
次に、本発明の第１の実施形態において適用される、目的とするサービスを実行する計算機を決定するためのサービス制御処理について、図４のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害（サーバの障害発生）に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００２８】
まずサービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、開始または引き継ぐべき目的とするサービス（以下、対象サービスと称する）の実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ１〜Ｓ３）。今、サーバ１０-i（ｉは１〜ｎのいずれか）が選択されたものとする。
【００２９】
サービス制御決定機構１０２は、サーバ１０-iを対象サーバとして選択すると、当該サーバ１０-iについて、障害が発生したサーバ自身であるか、或いは電源が遮断されているサーバであるか、つまり正常な動作が不可能なサーバであるかをチェックする（ステップＳ４）。
【００３０】
もし、対象サーバ１０-iが、電源が遮断されているサーバ、或いは障害が発生したサーバ自身であるならば、つまり正常に動作できないサーバであるならば、サービス制御決定機構１０２は、当該サーバでは対象サービスを開始または引き継ぐことが不可能であると判断する。この場合、サービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を再び参照し、対象サービスの実行が可能であるとして登録されているサーバの中に未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまりサーバ１０-iの次の優先度のサーバを対象サーバとして選択する（ステップＳ１〜Ｓ３）。そしてサービス制御決定機構１０２は、この新たな対象サーバについて、再度ステップＳ４を実行する。
【００３１】
これに対し、ステップＳ３で選択されたサーバ１０-i、即ち対象サーバ１０-iが、電源が遮断されているサーバでも、障害が発生したサーバ自身でもないならば、つまり正常に動作可能なサーバであるならば、サービス制御決定機構１０２は、当該サーバ１０-iで対象サービスを実行できる可能性があると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-iと当該サーバ１０-iで現在実行されているサービスとをもとに、サービス間関係情報テーブルＴＢＬ１を参照して、その参照結果から、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係（サーバ内の強い排他関係）がないか否か、つまり対象サーバ１０-iで現在実行されているサービスと対象サービスとを、当該対象サーバ１０-iで並行して実行可能か否かをチェックする（ステップＳ５，Ｓ６）。
【００３２】
もし、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係があるならば、サービス制御決定機構１０２は、実行中のサービス（現状サービス）を優先させるために、対象サービスを対象サーバ１０-iで実行することはできないと判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまり対象サービスを実行することはできないと判断されたサーバ１０-iの次の優先度のサーバを対象サーバとして選択し（ステップＳ１〜Ｓ３）、この新たな対象サーバについて、再度ステップＳ４を実行する。
【００３３】
これに対し、対象サーバ１０-iで現在実行されているサービスと対象サービスとの間に排他関係がないならば、サービス制御決定機構１０２は対象サービスを対象サーバ１０-iで実行できると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-i内のサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ７）。
【００３４】
なお、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバについて、対象サービスの実行が可能かをチェックした結果、当該対象サービスが起動できなかった場合には、つまり未チェックのサーバが残っていない場合には（ステップＳ２）、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００３５】
このように、本発明の第１の実施形態においては、クラスタシステム上で実行し得るサービス間に、サーバ内の強い排他関係を持たせることで、例えばデータベース（ＤＢ）をアクセスするサービス（ＤＢアプリケーション）と、ＤＢをバックアップするサービス（ＤＢバックアップアプリケーション）など、本質的に同じサーバで動作することができないサービス（アプリケーション）を、クラスタシステムとして一元的に制御することができる。
【００３６】
［第１の実施形態の第１の変形例］
次に、本発明の第１の実施形態の第１の変形例について説明する。この第１の変形例の特徴は、サービス間の排他関係が、サーバ内はなくて、クラスタシステム内（クラスタシステム全体）で定義されている点にある。つまり第１の変形例では、サービス間関係情報テーブルＴＢＬ１に登録されたサービス間関係情報は、クラスタシステム上で実行し得る各サービスについて、そのサービスが実行されている場合に、当該クラスタシステム内で並行して実行することができないサービスとの関係、つまり同じクラスタシステム内で並行して実行することが本質的にできないサービス相互間の関係を示す。このような関係（排他関係）を、クラスシステム内の強い排他関係と呼ぶ。第１の変形例におけるシステム構成は、第１の実施形態で適用された図１のシステム構成と同様である。
【００３７】
以下、本発明の第１の実施形態の第１の変形例におけるサービス制御処理について、便宜的に図１のシステムを援用しながら、図５のフローチャートを参照して説明する。
【００３８】
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００３９】
まずサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１を参照し、クラスタシステム内に対象サービスとの間で排他関係を持つサービスが存在し、しかも当該排他関係を持つサービスが実行中かのチェックを行う（ステップＳ１１，Ｓ１２）。もし、排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、実行中のサービス（現状サービス）を優先させるために、開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００４０】
これに対し、対象サービスとの間で排他関係を持つ実行中のサービスが存在しないならば、サービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、対象サービスの実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ１３〜Ｓ１５）。今、サーバ１０-i（ｉは１〜ｎのいずれか）が選択されたものとする。
【００４１】
サービス制御決定機構１０２は、サーバ１０-iを対象サーバとして選択すると、当該サーバ１０-iについて、障害が発生したサーバ自身であるか、或いは電源が遮断されているサーバであるか、つまり正常な動作が不可能なサーバであるかをチェックする（ステップＳ１６）。
【００４２】
もし、対象サーバ１０-iが、電源が遮断されているサーバ、或いは障害が発生したサーバ自身であるならば、サービス制御決定機構１０２は、当該サーバ１０-iでは対象サービスを開始することが不可能であると判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバ、つまりサーバ１０-iの次の優先度のサーバを対象サーバとして選択し（ステップＳ１３〜Ｓ１５）、この新たな対象サーバについて、再度ステップＳ１６を実行する。
【００４３】
これに対し、対象サーバ１０-iが、電源が遮断されているサーバでも、障害が発生したサーバ自身でもないならば、サービス制御決定機構１０２は、当該サーバ１０-iで対象サービスを実行できると判断する。この場合、サービス制御決定機構１０２は、対象サーバ１０-iのサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ１７）。
【００４４】
なお、クラスタシステム内に対象サービスとの間で排他関係を持つ実行中のサービスが存在しなくても、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバが、いずれも障害発生サーバ自身であるか、或いは電源が遮断されているサーバである場合には、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００４５】
このように、上記第１の実施形態の第１の変形例においては、クラスタシステム上で実行し得るサービス間に、当該クラスタシステム内の強い排他関係を持たせることで、本質的に同じクラスタシステム内で動作することができないサービスをクラスタシステムとして一元的に制御することが可能となる。
【００４６】
［第１の実施形態の第２の変形例］
次に、本発明の第１の実施形態の第２の変形例について説明する。この第２の変形例の第１の特徴は、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報で示されるサービス間の排他関係が、上記第１の変形例と同様に、クラスタシステム内（クラスタシステム全体）で定義されており、クラスタシステム内の強い排他関係によるクラスタ制御が行われる点にある。第２の変形例の第２の特徴は、上記第１の変形例とは異なって、実行中のサービスを優先させるのではなく、開始または引き継ぐべきサービスを優先させる点、つまり現状サービス優先ではなくて後サービス優先とする点にある。第２の変形例におけるシステム構成は、第１の実施形態で適用された図１のシステム構成と同様である。
【００４７】
以下、本発明の第１の実施形態の第２の変形例におけるサービス制御処理について、便宜的に図１のシステムを援用しながら、図６のフローチャートを参照して説明する。
【００４８】
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００４９】
まずサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１を参照し、クラスタシステム内で実行中のサービスの中に、対象サービスとの間で排他関係を持つサービスが存在するかのチェックを行う（ステップＳ２１，Ｓ２２）。
【００５０】
もし、対象サービスとの間で排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、当該実行中のサービスを全て特定し、対象サービス（後サービス）の実行を優先させるために、その特定された全サービスの停止を、サービス実行機構１０３-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に対して、対象サービスの開始または引継を指示する（ステップＳ４５）。これにより、排他関係に拘わらずに、サービスが実行可能な最もサーバ優先度の高いサーバにて対象サービスを開始または引き継がせることができる。
【００７８】
これに対し、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全サーバについてステップＳ４４のチェックを行っても、目的のサーバ（対象サーバ）が見つからず、未チェックのサーバが存在しないならば（ステップＳ４２のＮＯ）、サービス制御決定機構１０２は、排他関係を考慮しないでも、対象サービスの開始または引継ができないものと判断する。この対象サービスの開始または引継ができない要因は、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されている全てのサーバの電源が遮断されているか、或いは障害が発生しているためである。この場合、サービス制御決定機構１０２は、対象サービスの開始または引継ができない旨を当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００７９】
このように、上記第１の実施形態の第４の変形例においては、クラスタシステム上で実行し得るサービス間のサーバ内の弱い排他関係を持たせ、できれば同一サーバ上で並行して実行させたくないサービスを設定することで、クライアントからのサービスの開始要求時、或いはサービスの障害発生時に、該当するサービスを、サービス間の排他関係を考慮して可能な限り排他関係のあるサービスが実行されていない別のサーバで動かすという運用ができる。これにより、負荷分散を考慮した設定が容易になる。
【００８０】
［第２の実施形態］
図９は本発明の第２の実施形態に係るクラスタシステムの構成を示すブロック図である。なお、図１と同様の部分には、便宜的に同一符号を付して、詳細な説明を省略する。
【００８１】
図９のクラスタシステムが、図１のクラスタシステムと主として異なる点は、サーバ１０-1〜１０-nが有するクラスタ制御機構１０１-1〜１０１-nのサービス制御決定機構１０２-1〜１０２-nに、サービス間関係情報テーブルＴＢＬ１及び実行サーバ情報テーブルＴＢＬ２に加えて、サービス優先度情報テーブルＴＢＬ３を持たせたことにある。
【００８２】
サービス優先度情報テーブルＴＢＬ３は、図９のクラスタシステム上で実行し得るサービスの優先度情報を登録したテーブルである。このテーブルＴＢＬ３のデータ構造の一例を図１２に示す。図１２のテーブルＴＢＬ３には、４つのサービスＡ，Ｂ，Ｃ，Ｄの優先度として、それぞれ優先度１，優先度３，優先度２，優先度４が設定されている。この場合、サービスＡ，Ｂ，Ｃ，Ｄの優先度（重要度）は、サービスＡが最も高く、以下サービスＣ、サービスＢ、サービスＤの順であることが示される。
【００８３】
なお、第２の実施形態において、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報は、第１の実施形態と同様に、相異なるサービスのサーバ内の強い排他関係、つまり同一サーバ上で、本質的には並行して動作できないサービスを示す。
【００８４】
次に、本発明の第２の実施形態におけるサービス制御処理について、図１０のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからのサービスの開始命令、或いはクラスタ制御機構１０１からのサービスの障害に起因するサービスの引継命令を受けた場合、以下に述べるように、当該サービスを、クラスタシステム内のいずれのサーバで開始または引き継ぐかを決定する。
【００８５】
まずサービス制御決定機構１０２は、上記第１の実施形態における図４中のステップＳ１〜Ｓ４と同様の処理（ステップＳ５１〜Ｓ５４）を実行する。即ちサービス制御決定機構１０２は、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されているサーバの中から、障害が発生しておらず、且つ電源が遮断されていないサーバ、つまり対象サービスを実行できる可能性のあるサーバを、優先度の高い順に１つだけ探す。
【００８６】
もし、目的のサーバ、例えばサーバ１０-iが見つけられたなら、サービス制御決定機構１０２は、当該サーバ１０-iと当該サーバ１０-iで現在実行されているサービスとをもとに、サービス間関係情報テーブルＴＢＬ１を参照する（ステップＳ５５）。そしてサービス制御決定機構１０２は、サービス間関係情報テーブルＴＢＬ１の参照結果から、サーバ（対象サーバ）１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在するか否かをチェックする（ステップＳ５６）。
【００８７】
もし、対象サーバ１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在しないならば、サービス制御決定機構１０２は、対象サーバ１０-iのサービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ６０）。
【００８８】
これに対し、対象サーバ１０-i上に、対象サービスとの間で排他関係を持つ実行中のサービスが存在するならば、サービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３を参照する（ステップＳ５７）。そしてサービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３に登録されている各サーバの優先度のうち、サーバ１０-i上で現在実行中のサービスの優先度と上記対象サービスの優先度とを比較して、現在実行中のサービスの方が優先度が低いか否かをチェックする（ステップＳ５８）。
【００８９】
もし、現在実行中のサービスの方が優先度が低いならば、つまり対象サービスの方が優先度が高いならば、サービス制御決定機構１０２は現在実行中のサービス、つまり対象サービスとの間で排他関係のあるサービスの停止を、対象サーバ１０-iのサービス実行機構１０３-iに対して指示する（ステップＳ５９）。しかる後にサービス制御決定機構１０２は、上記サービス実行機構１０３-iに対して、対象サービスの開始または引継を指示する（ステップＳ６０）。
【００９０】
一方、現在実行中のサービスの方が優先度が高いならば、サービス制御決定機構１０２は、サーバ１０-iでは対象サービスを開始できないと判断する。この場合、サービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサーバを対象サーバとして選択し（ステップＳ５１〜Ｓ５３）、この新たな対象サーバについて、再度ステップＳ５４を実行する。そして、実行サーバ情報テーブルＴＢＬ２に対象サービスの実行が可能であるとして登録されているサーバのいずれにおいても対象サービスを開始させることができなかった結果、未チェックのサーバがなくなったならば（ステップＳ５２）、サービス制御決定機構１０２はサービスの開始または引継ができない旨を、当該サービスの開始命令または引継命令の発行元に通知して、処理を完了する。
【００９１】
このように、本発明の第２の実施形態においては、サービス間にサーバ内の強い排他関係を持たせるだけでなく優先度をも持たせることで、サービス間の排他関係を考慮しつつ優先度の高いサービスを優先的に開始または継続させることができる。
【００９２】
［第３の実施形態］
図１１は本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図である。なお、図９と同様の部分には、便宜的に同一符号を付して、詳細な説明を省略する。
【００９３】
図１１のクラスタシステムが、図９のクラスタシステムと主として異なる点は、サーバ１０-1〜１０-nが有するクラスタ制御機構１０１-1〜１０１-nのサービス制御決定機構１０２-1〜１０２-nに、サービス間関係情報テーブルＴＢＬ１、実行サーバ情報テーブルＴＢＬ２及びサービス優先度情報テーブルＴＢＬ３に加えて、サービス実行可能情報テーブルＴＢＬ４を持たせたことにある。
【００９４】
サービス実行可能情報テーブルＴＢＬ４は、図１１のクラスタシステム上で実行し得るサービス毎に、実行の可否を示すサービス実行可能情報を登録したテーブルである。このサービス毎の実行可否は、クライアント（ユーザ）からの要求に応じて設定可能である。つまり、クライアントからサービス制御決定機構１０２にネットワーク１２を介してあるサービスを実行して欲しいという情報が与えられた場合には、上記テーブルＴＢＬ４内の当該サービスに対応する実行可否状態は「可能」に設定される。また、クライアントからサービス制御決定機構１０２にサービスを実行して欲しくないというい情報が与えられた場合には、上記テーブルＴＢＬ４内の当該サービスに対応する実行可否状態は「可能でない」に設定される。また、バッチサービス（バッチ処理）のように、ある処理の実行後やある時間経過後に完了してしまうサービスが完了した場合にも、当該サービスに対応する実行可否状態は「可能でない」に設定される。このテーブルＴＢＬ４のデータ構造の一例を図１３に示す。
【００９５】
なお、第３の実施形態において、サービス間関係情報テーブルＴＢＬ１に登録されるサービス間関係情報は、第１の実施形態で適用されたようなサーバ内の排他関係（サービス間の排他関係）と、第１の実施形態の第１の変形例で適用されたようなクラスタシステム内の排他関係（サービス間の排他関係）とを選択的に定義（設定）可能である。ここでは、上記サーバ内の排他関係、つまり同じサーバ上で本質的に並行して動作できないサービス間の排他関係を、「排他関係（サーバ）」と表現する。また、上記クラスタシステム内の排他関係、つまり同じクラスタシステム上で本質的に並行して動作できないサービス間の排他関係を、「排他関係（システム）」と表現する。
【００９６】
次に、本発明の第３の実施形態におけるサービス制御処理について、図１４及び図１５のフローチャートを参照して説明する。
サービス制御決定機構１０２は、クライアントからの要求によりサービス実行可能情報テーブルＴＢＬ４に登録されているサービス実行可能情報に変更があった場合、バッチ処理などの完了によりテーブルＴＢＬ４中の該当するサービスの実行可否状態が「可能」から「可能でない」に変更された場合、サービスが動作しているサーバに障害が発生した場合、サービスに障害が発生した場合、或いはクラスタシステム内のサーバが復旧した場合に、図１４及び図１５のフローチャートに従う処理を開始する。
【００９７】
まずサービス制御決定機構１０２は、サービス優先度情報テーブルＴＢＬ３を参照し、図１１のクラスタシステム上で実行し得るサービスを、サービス優先度に従い、サービス優先度の高い順に１台ずつ対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。
【００９８】
サービス制御決定機構１０２は、対象サービスを選択すると、サービス実行可能情報テーブルＴＢＬ４を参照して、当該対象サービスがクラスタシステム上で実行可能であるか否かをチェックする（ステップＳ６４，Ｓ６５）。
【００９９】
もし、対象サービスが実行可能でないならば、サービス制御決定機構１０２はサービス優先度情報テーブルＴＢＬ３を再び参照し、未チェックのサービスが残っているならば、その未チェックのサービスのうち最も優先度の高いサービスを対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。
【０１００】
これに対し、対象サービスが実行可能ならば、サービス制御決定機構１０２はサービス実行可能情報テーブルＴＢＬ４を参照し、図１１のクラスタシステム内で当該対象サービスとの間で排他関係を持つサービス、つまり「排他関係（システム）」を持つサービスを特定する（ステップＳ６６）。そしてサービス制御決定機構１０２は、上記特定されたサービス、つまり対象サービスとの間で「排他関係（システム）」を持つサービスの実行（クラスタシステム内のいずれかのサーバでの実行）が（後述するステップＳ７３で）既に計画されているかをチェックする（ステップＳ６７）。
【０１０１】
もし、上記特定されたサービスの実行が計画されているならば、サービス制御決定機構１０２はステップＳ６３で選択された対象サービスを実行計画に盛り込むことは諦める。この場合、サービス制御決定機構１０２は、未チェックのサービスが残っているならば、その未チェックのサービスのうち最も優先度の高いサービス、つまり実行計画に盛り込まれないこととなったサービスの次の優先度のサービスを選択して（ステップＳ６１〜Ｓ６３）、実行計画に盛り込めないかチェックする（ステップＳ６４〜Ｓ６７）。
【０１０２】
これに対し、上記特定されたサービスの実行が計画されていないならば、サービス制御決定機構１０２は実行サーバ情報テーブルＴＢＬ２を参照し、クラスタシステムに含まれるサーバ１０-1〜１０-nのうち、ステップＳ６３で選択された対象サービスの実行が可能であるとして登録されているサーバを、優先度の高い順に１台ずつ対象サーバとして選択する（ステップＳ６８〜Ｓ７０）。
【０１０３】
サービス制御決定機構１０２は、対象サーバを選択すると、サービス間関係情報テーブルＴＢＬ１を参照し、上記ステップＳ６３で選択された対象サービスとの間で当該対象サーバ内で排他関係を持つサービス、つまり「排他関係（サーバ）」を持つサービスを特定する（ステップＳ７１）。そしてサービス制御決定機構１０２は、上記特定されたサービス、つまり対象サービスとの間で「排他関係（サーバ）」を持つサービスの対象サーバ内での実行が既に計画されているかをチェックする（ステップＳ７２）。
【０１０４】
もし、上記特定されたサービスの対象サーバ内での実行が計画されているならば、サービス制御決定機構１０２はステップＳ６３で選択された対象サービスをステップ７０で選択された対象サーバでの実行計画に盛り込むことは諦める。この場合、サービス制御決定機構１０２は、次の優先度のサーバが存在するならば、当該サーバ内で対象サービスが実行可能であるかのチェックを再試行する。即ちサービス制御決定機構１０２は、未チェックのサーバが残っているならば、その未チェックのサーバのうち最も優先度の高いサービス、つまり現在の対象サーバの次の優先度のサーバを新たな対象サーバとして選択する（ステップＳ６８〜Ｓ７０）。そしてサービス制御決定機構１０２は、対象サービスとの間で「排他関係（サーバ）」を持つサービスの対象サーバ内での実行が既に計画されているか、つまり対象サービスを対象サーバ内での実行計画に盛り込めるかをチェックする（ステップＳ７１，Ｓ７２）。
【０１０５】
これに対し、上記特定されたサービスの対象サーバ内での実行が計画されていないならば、サービス制御決定機構１０２は、ステップＳ６３で選択された対象サービスを当該対象サーバで実行すること、つまり当該対象サービスを当該対象サーバでの実行計画に盛り込むことを決定する（ステップＳ７３）。
【０１０６】
サービス制御決定機構１０２は、対象サービスを当該対象サーバで実行することを決定した場合、或いは対象サービスが実行可能なサーバが見つからなかった場合、次の優先度のサービスが存在するならば、そのサービスを新たな対象サービスとして選択する（ステップＳ６１〜Ｓ６３）。そしてサービス制御決定機構１０２は、新たな対象サービスが実行可能なサーバが存在するならば（ステップＳ６４，Ｓ６５）、当該サーバを対象サーバとして特定し、当該対象サーバ内で対象サービスが実行可能であるかのチェックを再試行する。（ステップＳ６６〜Ｓ７２）。
【０１０７】
このようにして、サービス実行可能情報テーブルＴＢＬ４に登録されている全サービスについて処理した結果、未チェックのサービスが残っていないならば（ステップＳ６２）、サービス制御決定機構１０２は、当該全サービスのうちの計画済みのサービスを実行させるための処理を次のように行う。まずサービス制御決定機構１０２は、各サーバ１０-i（ｉ＝１〜ｎ）で現在実行中のサービスのうち、当該サーバ１０-iでの実行が計画されていないサービスについて、当該サーバ１０-i内のサービス実行機構１０３-iに対して当該計画されていないサービスの停止を指示する（ステップＳ７４）。しかる後にサービス制御決定機構１０２は、各サーバ１０-i（ｉ＝１〜ｎ）で実行が計画されているサービスのうち、未だ実行されていないサービスの実行開始を当該サーバ１０-i内のサービス実行機構１０３-iに対して指示する（ステップＳ７５）。
【０１０８】
このように、本発明の第３の実施形態においては、図１１のクラスタシステム上で実行し得るサービスについて、サービス優先度の高い順に、当該サービスが実行可能状態に設定されているかを調べるようにしている。また、第３の実施形態においては、実行可能状態に設定されているサービスについて、サービス間の排他関係を考慮しながら、当該サービスを実行可能なサーバの優先順位順に、当該サービスを実行するサーバを決定するようにしている。
【０１０９】
これにより、第３の実施形態によれば、次に列挙する効果を得ることができる。
（１）サービスを実行するのに最も適したサーバが障害から復旧した際に、そのサーバにサービスを移すことが簡単な設定だけで行える。
（２）クライアント（ユーザ）に、サービスの開始ではなくて当該サービスの実行可能状態を設定させることで、当該サービスの実行の開始を指示する開始命令であって、当該サービスを仮に開始したならば、当該サービスよりも優先度の高いサービスに悪影響を与えるような開始命令があった際にも、優先度に従い実行しないという処理が容易に実現できる。
【０１１０】
（３）できる限り優先度の高いサービスを、できるだけ優先度の高いサーバで実行することを容易にする。
【０１１１】
上記各実施形態または各変形例では、サービス制御決定機構１０２-1〜１０２-nに、テーブルＴＢＬ１，ＴＢＬ２、またはテーブルＴＢＬ１〜ＴＢＬ３、またはテーブルＴＢＬ１〜ＴＢＬ４を持たせている。しかし、これらのテーブルはサービス制御決定機構１０２からアクセス可能な記憶手段に格納されていればよく、これらのテーブルを、当該サービス制御決定機構が有している必要はない。
【０１１２】
なお、本発明は、上記各実施形態及び各変形例に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果の欄で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。
【０１１３】
【発明の効果】
以上詳述したように本発明によれば、クラスタシステム上で実行し得るサービスに関し、相異なるサービス相互の実行に関する関係を定義したサービス間関係情報を適用し、目的とするサービス（例えば開始または引継を必要とするサービス）との間でサービス相互の実行に関する関係を持つ他のサービスの存在を考慮して、当該目的とするサービスを実行するサーバ計算機を決定するようにしたので、クラスタシステムにおける柔軟なサービスの運用が実現できる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係るクラスタシステムの構成を示すブロック図。
【図２】図１中のサービス間関係情報テーブルＴＢＬ１のデータ構造例を示す図。
【図３】図１中の実行サーバ情報テーブルＴＢＬ２のデータ構造例を示す図。
【図４】本発明の第１の実施形態におけるサービス制御処理を説明するためのフローチャート。
【図５】同第１の実施形態の第１の変形例におけるサービス制御処理を説明するためのフローチャート。
【図６】本発明の第１の実施形態の第２の変形例におけるサービス制御処理を説明するためのフローチャート。
【図７】本発明の第１の実施形態の第３の変形例におけるサービス制御処理を説明するためのフローチャート。
【図８】本発明の第１の実施形態の第４の変形例におけるサービス制御処理を説明するためのフローチャート。
【図９】本発明の第２の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１０】本発明の第２の実施形態におけるサービス制御処理を説明するためのフローチャート。
【図１１】本発明の第３の実施形態に係るクラスタシステムの構成を示すブロック図。
【図１２】図９及び図１１中のサービス優先度情報テーブルＴＢＬ３のデータ構造例を示す図。
【図１３】図１１中のサービス実行可能情報テーブルＴＢＬ４のデータ構造例を示す図。
【図１４】本発明の第３の実施形態におけるサービス制御処理を説明するためのフローチャートの一部を示す図。
【図１５】本発明の第３の実施形態におけるサービス制御処理を説明するためのフローチャートの残りを示す図。
【符号の説明】
１０-1〜１０-n…サーバ（サーバ計算機）
１１，１２…ネットワーク
１０１…（仮想の）クラスタ制御機構
１０１-1〜１０１-n…クラスタ制御機構
１０２…（仮想の）サービス制御決定機構
１０２-1〜１０２-n…サービス制御決定機構
１０３-1〜１０３-n…サービス実行機構
ＴＢＬ１…サービス間関係情報テーブル（サービス間関係情報登録手段）
ＴＢＬ２…実行サーバ情報テーブル（実行サーバ情報登録手段）
ＴＢＬ３…サービス優先度情報テーブル（サービス優先度情報登録手段）
ＴＢＬ４…サービス実行可能情報テーブル（サービス実行可能情報登録手段）
Claims (6)
- 複数台のサーバ計算機から構成されるクラスタシステムにおいて、
前記クラスタシステム上で実行し得るサービスに関し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係であって、実行中のサービスを優先させる関係を第１の排他関係として定義し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係であって、実行中のサービスより目的とするサービスを優先させる関係を第２の排他関係として定義したサービス間関係情報を登録したサービス間関係情報登録手段と、
目的とするサービスの実行が可能なサーバ計算機を選択するサーバ計算機選択手段と、
前記サーバ計算機選択手段により選択されたサーバ計算機が正常に動作可能なサーバ計算機である場合に、前記目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に前記第１の排他関係または前記第２の排他関係があるかを前記サービス間関係情報に基づいて判定する排他関係判定手段と、
前記排他関係判定手段により、前記目的とするサービスと前記選択されたサーバ計算機内で実行中のサービスとの間に前記第２の排他関係があると判定された場合、当該選択されたサーバ計算機内で実行中の前記目的とするサービスとの間で前記第２の排他関係のある全てのサービスを停止させる手段と、
前記排他関係判定手段により、前記目的とするサービスと前記選択されたサーバ計算機内で実行中のサービスとの間に、前記第１の排他関係及び前記第２の排他関係が共にないと判定された場合には直ちに、前記第２の排他関係があると判定された場合には、前記目的とするサービスとの間で前記第２の排他関係のある全ての実行中のサービスが停止された後に、当該選択されたサーバ計算機を前記目的とするサービスを実行するサーバ計算機として決定する決定手段と
を具備することを特徴とするクラスタシステム。 - 前記クラスタシステム上で実行し得るサービス毎に当該サービスの実行が可能な前記クラスタシステム上のサーバ計算機を定義した実行サーバ情報を登録した実行サーバ情報登録手段を更に具備し、
前記目的とするサービスの実行が可能なサーバ計算機は前記実行サーバ情報登録手段に登録されている実行サーバ情報により示される
ことを特徴とする請求項１記載のクラスタシステム。 - 前記クラスタシステム上で実行し得るサービス毎に当該サービスの実行が可能な前記クラスタシステム上のサーバ計算機を定義すると共に、当該サービスの実行が可能なサーバ計算機毎の当該サービスの実行に関する優先度を定義した実行サーバ情報を登録した実行サーバ情報登録手段を更に具備し、
前記サーバ計算機選択手段は、前記実行サーバ情報登録手段に登録されている実行サーバ情報により示される前記目的とするサービスの実行が可能なサーバ計算機を当該実行サーバ情報により示される優先度順に選択する
ことを特徴とする請求項１記載のクラスタシステム。 - 複数台のサーバ計算機から構成されるクラスタシステムにおいて、
前記クラスタシステム上で実行し得るサービスに関し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係を排他関係として定義したサービス間関係情報を登録したサービス間関係情報登録手段と、
前記クラスタシステム上で実行し得るサービス毎に当該サービスの実行が可能な前記クラスタシステム上のサーバ計算機を定義すると共に、当該サービスの実行が可能なサーバ計算機毎の当該サービスの実行に関する優先度を定義した実行サーバ情報を登録した実行サーバ情報登録手段と、
目的とするサービスの実行が可能なサーバ計算機を選択するサーバ計算機選択手段であって、前記実行サーバ情報登録手段に登録されている実行サーバ情報により示される前記目的とするサービスの実行が可能なサーバ計算機を、当該実行サーバ情報により示される優先度順に選択するサーバ計算機選択手段と、
前記サーバ計算機選択手段により選択されたサーバ計算機が正常に動作可能なサーバ計算機である場合に、前記目的とするサービスと当該選択されたサーバ計算機内で実行中のサービスとの間に排他関係があるか否かを前記サービス間関係情報に基づいて判定する排他関係判定手段と、
前記排他関係判定手段が前記目的とするサービスと前記選択されたサーバ計算機内で実行中のサービスとの間に排他関係がないと判定した場合に、当該選択されたサーバ計算機を前記目的とするサービスを実行するサーバ計算機として決定する決定手段と
を具備することを特徴とするクラスタシステム。 - 複数台のサーバ計算機から構成されるクラスタシステムにおいて、目的とするサービスを実行するサーバ計算機を決定するためのサービス制御方法であって、
目的とするサービスの開始または引継が必要な場合、当該目的とするサービスの実行が可能な前記クラスタシステム上のサーバ計算機を順次選択するステップと、
前記目的とするサービスの実行が可能なサーバ計算機が選択される毎に、当該選択されたサーバ計算機が正常な動作が可能なサーバ計算機であるかを判定するステップと、
前記選択されたサーバ計算機が正常な動作が可能なサーバ計算機であると判定された場合に、前記クラスタシステム上で実行し得るサービスに関し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係であって、実行中のサービスを優先させる関係を第１の排他関係として定義し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係であって、実行中のサービスより目的とするサービスを優先させる関係を第２の排他関係として定義した、サービス間関係情報登録手段に登録されているサービス間関係情報を参照して、前記正常な動作が可能であると判定されたサーバ計算機で実行中のサービスと前記目的とするサービスとの間に前記第１の排他関係または前記第２の排他関係があるかを判定するステップと、
前記正常な動作が可能であると判定されたサーバ計算機で実行中のサービスと前記目的とするサービスとの間に前記第２の排他関係があると判定された場合、前記正常な動作が可能であると判定されたサーバ計算機で実行中の前記目的とするサービスとの間で前記第２の排他関係のある全てのサービスを停止させるステップと、
前記正常な動作が可能であると判定されたサーバ計算機で実行中のサービスと前記目的とするサービスとの間に前記第１の排他関係及び前記第２の排他関係が共にないと判定された場合には直ちに、前記第２の排他関係があると判定された場合には、前記目的とするサービスとの間で前記第２の排他関係のある全ての実行中のサービスが停止された後に、前記正常な動作が可能であると判定されたサーバ計算機を前記目的とするサービスを実行するサーバ計算機として決定するステップと
を具備することを特徴とするサービス制御方法。 - 複数台のサーバ計算機から構成されるクラスタシステムにおいて、目的とするサービスを実行するサーバ計算機を決定するためのサービス制御方法であって、
前記クラスタシステム上で実行し得るサービス毎に当該サービスの実行が可能な前記クラスタシステム上のサーバ計算機を定義すると共に、当該サービスの実行が可能なサーバ計算機毎の当該サービスの実行に関する優先度を定義した、実行サーバ情報登録手段に登録されている実行サーバ情報を参照して、当該実行サーバ情報により示される目的とするサービスの実行が可能なサーバ計算機を、当該実行サーバ情報により示される優先度順に選択するステップと、
前記目的とするサービスの実行が可能なサーバ計算機が選択される毎に、当該選択されたサーバ計算機が正常な動作が可能なサーバ計算機であるかを判定するステップと、
前記選択されたサーバ計算機が正常に動作可能なサーバ計算機であると判定された場合に、前記クラスタシステム上で実行し得るサービスに関し、同一サーバ計算機内で並行して実行することができないサービス相互間の関係を排他関係として定義した、サービス間関係情報登録手段に登録されているサービス間関係情報を参照して、前記目的とするサービスと前記正常な動作が可能であると判定されたサーバ計算機内で実行中のサービスとの間に排他関係があるかを判定するステップと、
前記目的とするサービスと前記正常な動作が可能であると判定されたサーバ計算機内で実行中のサービスとの間に排他関係がないと判定された場合に、当該正常な動作が可能であると判定されたサーバ計算機を前記目的とするサービスを実行するサーバ計算機として決定するステップと
を具備することを特徴とするサービス制御方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002298836A JP4163481B2 (ja) | 2002-10-11 | 2002-10-11 | クラスタシステム及び同システムにおけるサービス制御方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002298836A JP4163481B2 (ja) | 2002-10-11 | 2002-10-11 | クラスタシステム及び同システムにおけるサービス制御方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004133764A JP2004133764A (ja) | 2004-04-30 |
| JP4163481B2 true JP4163481B2 (ja) | 2008-10-08 |
Family
ID=32288141
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002298836A Expired - Fee Related JP4163481B2 (ja) | 2002-10-11 | 2002-10-11 | クラスタシステム及び同システムにおけるサービス制御方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4163481B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006323526A (ja) * | 2005-05-17 | 2006-11-30 | Fujitsu Ltd | クラスタ管理プログラム、該プログラムを記録した記録媒体、クラスタ管理方法、ノード、およびクラスタ |
| JP4515354B2 (ja) * | 2005-08-16 | 2010-07-28 | 株式会社野村総合研究所 | 負荷分散処理システム及び装置 |
| US8112527B2 (en) | 2006-05-24 | 2012-02-07 | Nec Corporation | Virtual machine management apparatus, and virtual machine management method and program |
| JP4703681B2 (ja) * | 2008-04-21 | 2011-06-15 | 株式会社東芝 | クラスタシステム及び引き継ぎ先ノード決定方法 |
| JP5262492B2 (ja) * | 2008-09-17 | 2013-08-14 | 沖電気工業株式会社 | クラスタシステム及びコマンド競合制御方法 |
| JP5625243B2 (ja) * | 2009-02-26 | 2014-11-19 | 日本電気株式会社 | 情報処理システム、ディザスタリカバリ方法及びディザスタリカバリプログラム |
| JP5374450B2 (ja) * | 2010-07-05 | 2013-12-25 | 日本電信電話株式会社 | 付加サービス競合制御システム、付加サービス競合制御方法及び付加サービス競合制御プログラム |
| JP5436607B2 (ja) * | 2012-04-16 | 2014-03-05 | 株式会社ソニー・コンピュータエンタテインメント | サーバ、クライアント装置、調停方法、サービス要求方法、およびデータ配信システム |
-
2002
- 2002-10-11 JP JP2002298836A patent/JP4163481B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004133764A (ja) | 2004-04-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8145741B2 (en) | Selecting a target design based on criteria | |
| CN109814998A (zh) | 一种多进程任务调度的方法及装置 | |
| US8042101B2 (en) | Method and program for monitoring execution state of program | |
| US6477563B1 (en) | Agent system and information processing method for same | |
| US8713352B2 (en) | Method, system and program for securing redundancy in parallel computing system | |
| US20030070114A1 (en) | Computer recovery method and system for recovering automatically from fault, and fault monitoring apparatus and program used in computer system | |
| JP2005528691A (ja) | サーバ連結環境のための業務継続ポリシー | |
| JP4163481B2 (ja) | クラスタシステム及び同システムにおけるサービス制御方法 | |
| WO2012127476A1 (en) | Data backup prioritization | |
| WO2009083827A1 (en) | Methods and systems for generating availability management framework (amf) configurations | |
| JPH10503306A (ja) | 顧客−サーバアーキテクチャを有するコンピュータシステム | |
| CN107357688A (zh) | 分布式系统及其故障恢复方法和装置 | |
| WO2006129277A2 (en) | Method and hardware node for customized upgrade control | |
| WO2004099990A1 (ja) | 計算機システム及び同システムに適用される故障計算機代替制御方法 | |
| US20060271672A1 (en) | System and method for loading various operating systems from a remote console | |
| US8200492B2 (en) | Update technique for speech recognition applications with uninterrupted (24X7) operation | |
| US7555544B1 (en) | Implementation of affinities in high availability computer system clusters | |
| CN109002263A (zh) | 存储容量的调整方法及装置 | |
| JPH07336447A (ja) | 電子交換機の回線選択方法 | |
| JP4363914B2 (ja) | クラスタシステム | |
| CN112567687A (zh) | 朝向网络切片的可用性 | |
| JP3930455B2 (ja) | 計算機システム、サービス継続制御プログラム | |
| JP2001014290A (ja) | マルチプロセッサシステム | |
| JP4595892B2 (ja) | データベース管理システム構築方法、装置、プログラム及び記録媒体 | |
| Dhall | Designing Graceful Degradation in Software Systems. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041124 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041221 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050221 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050705 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080616 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080724 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110801 Year of fee payment: 3 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4163481 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110801 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120801 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120801 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130801 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |