JP2005011237A - クラスタシステム及びサービス制御プログラム - Google Patents
クラスタシステム及びサービス制御プログラム Download PDFInfo
- Publication number
- JP2005011237A JP2005011237A JP2003176959A JP2003176959A JP2005011237A JP 2005011237 A JP2005011237 A JP 2005011237A JP 2003176959 A JP2003176959 A JP 2003176959A JP 2003176959 A JP2003176959 A JP 2003176959A JP 2005011237 A JP2005011237 A JP 2005011237A
- Authority
- JP
- Japan
- Prior art keywords
- service
- relationship
- services
- computer
- cluster system
- 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.)
- Granted
Links
Images
Landscapes
- Hardware Redundancy (AREA)
Abstract
【解決手段】クラスタシステム内のシナリオ管理機構12に設けられたサービス制御部122は、クラスタシステムにより提供されるサービスに関し、サービス関係情報DB121aに記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御する。サービス制御部122は、サービスの開始制御では、サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機のサービス実行機構に対して当該サービスの開始を指示し、当該サービスの停止制御では、当該サービスを開始している計算機のサービス実行機構に対して当該サービスの停止を指示する。
【選択図】 図2
Description
【発明の属する技術分野】
本発明は、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムに係り、特に当該システムにおけるサービスの実行を制御するのに好適なクラスタシステム及びサービス制御プログラムに関する。
【0002】
【従来の技術】
計算機システムの目的として、その計算機システム上でアプリケーションプログラムを実行し、ユーザにサービスを提供することが従来から知られている。近年、サービスの重要性が増すにつれて、サービスが実行される計算機システムに高い可用性が求められるようになっている。
【0003】
現在、計算機システムの可用性を高めたシステムとして、クラスタシステムが注目を集めている(例えば、非特許文献1参照)。クラスタシステムは、ネットワーク接続された複数台の計算機で構成され、それらの計算機を統一的に管理するためのクラスタシステム管理機構を備えている。クラスタシステム管理機構は、予め定義されたクラスタシステムの設定に従って、サービスの開始処理及び停止処理、並びにサービスの状態監視を制御する。
【0004】
例えば、ホットスタンバイ型のクラスタシステムでは、クラスタシステム管理機構は、サービスを開始している計算機(稼働系計算機)で発生した障害を検出したときに、引継ぎ先の計算機(待機系計算機)でそのサービスを再開するという制御を行う。このサービスを引き継ぐための制御はフェイルオーバと呼ばれる。このフェイルオーバにより、サービスの提供不能時間が短縮され、クラスタシステムの可用性が高まる。
【0005】
従来のクラスタシステムでは、複数のサービスを提供する場合に、2台の計算機で構成されるホットスタンバイ型のクラスタシステムを、提供するサービスの数だけ用意する形態がとられている。しかし、この形態では、提供するサービスの数がnであるとすると、クラスタシステムを構築するのに2×n台の計算機が必要になり、計算機資源が無駄になる。そこで、計算機資源を節約するために、待機系を共通化した、n対1バックアップの形態をとるクラスタシステムも知られている。
【0006】
【非特許文献1】
金子哲夫、森良哉、「クラスタソフトウェア」、東芝レビュー、Vol.54 No.12(1999)、p.18−21
【0007】
【発明が解決しようとする課題】
上記したように、複数のサービスを提供する従来のクラスタシステムでは、ホットスタンバイ型のクラスタシステムが提供するサービスの数(n)だけ用意される形態、あるいはn対1バックアップの形態がとられている。これらの形態は、単にホットスタンバイ型のクラスタシステムを組み合わせた形態である。このため、ホットスタンバイ型のクラスタシステムと同等なサービスの制御しかできない。
【0008】
本発明は上記事情を考慮してなされたものでその目的は、複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、これによりホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できるクラスタシステム及びサービス制御プログラムを提供することにある。
【0009】
【課題を解決するための手段】
本発明の1つの観点によれば、複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムが提供される。このクラスタシステムは、サービス間関係情報記憶手段と、上記複数の計算機の各々に設けられるサービス実行手段と、サービス制御手段とを備えている。サービス間関係情報記憶手段には、複数種類のサービスのうちの相異なる2種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報が記憶される。サービス実行手段は、対応する計算機上でのサービスの開始及び停止を行う。サービス制御手段は、クラスタシステムにより提供されるサービスに関し、上記サービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御する。このサービス制御手段は、サービスの開始制御では、上記サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機のサービス実行手段に対して当該サービスの開始を指示する。また、サービス制御手段は、サービスの停止制御では、当該サービスを開始している計算機の前記サービス実行手段に対して当該サービスの停止を指示する
このように本発明においては、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。
【0010】
ここで、上記複数種類のサービスの各々について当該サービスの許可状態を管理するためのサービス許可状態情報を記憶するサービス許可状態情報記憶手段を追加すると共に、上記サービス制御手段には、上記サービス許可状態情報の示す許可状態に対応して上記サービス間関係情報の示すサービス間の関係が合致するように、開始すべきサービス及び当該開始すべきサービスを開始する計算機、あるいは停止すべきサービス及び当該停止すべきサービスを開始している計算機を選択する自動制御手段を持たせるとよい。このようにすると、上記サービス許可状態情報の示す許可状態に対応してサービス間の関係が合致するように、どのサービスをどの計算機で開始させるか、あるいは停止させるかを自動的に決定できる。
【0011】
更に、上記サービス実行手段によりサービスが開始された場合に、当該サービスに対応する上記サービス許可状態情報の示す許可状態を不許可にするバッチジョブ制御手段を上記サービス制御手段に持たせ、上記サービス許可状態情報の示す許可状態が不許可となった場合に、上記自動制御手段により当該サービス許可状態情報に対応するサービスの停止制御が行われる構成とするとよい。このようにすると、バッチジョブのサービスが簡単に実現できる。
【0012】
また、上記サービス間関係情報に、サービス間の関係の種類、サービス間の関係の属性及びサービス間の関係の適用範囲を示す情報を含め、上記サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であり、上記サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、上記自動制御手段による選択の候補となる上記強い関係を満たす計算機が複数存在するときに当該サービス間の関係が成立する計算機が優先的に選択される弱い関係とが設定可能であり、上記サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能である構成とするとよい。
【0013】
ここで、上記クラスタシステムを、固有の種類のサービスを提供するn台の稼働系計算機と、このn台の稼働系計算機のいずれかの計算機に障害が発生した場合に、当該障害発生計算機で開始されていたサービスを引き継ぐことが可能なm台の待機系計算機で構成し、上記サービス間関係情報記憶手段に記憶される、上記n台の稼働系計算機がそれぞれ提供するサービスのうちの相異なる2種類のサービスの組み合わせ毎の全てのサービス間関係情報に、上記サービス間の関係の種類、上記サービス間の関係の属性及び上記サービス間の関係の適用範囲として、それぞれ排他関係、強い関係及び局所的関係が設定される構成とするならば、n対mバックアップ構成を容易に実現できる。
【0014】
また、上記クラスタシステムにより提供されるサービスとして、データに相当する第1のサービス、データをバックアップする第2のサービス及びデータにアクセスする第3のサービスの3種類のサービスが定義されると共に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、上記第1のサービスに対して上記第2のサービスと上記第3のサービスとから強い依存関係が局所的関係として設定され、上記第2のサービスと上記第3のサービスとの間に強い排他関係が大局的関係として設定される構成とするならば、データのコールドバックアップを容易に実現できる。
【0015】
同様に、上記サービス間関係情報記憶手段に記憶されるサービス間関係情報に、上記第1のサービスに対して上記第2のサービスと上記第3のサービスとから強い依存関係が局所的関係として設定され、上記第3のサービスに対して上記第2のサービスから強い依存関係が大局的関係として設定され構成とするならば、データのオンラインバックアップを容易に実現できる。
【0016】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【0017】
[第1の実施形態]
図1は本発明の第1の実施形態に係るクラスタシステムの構成を示すブロック図である。同図において、クラスタシステム1は、図示せぬネットワークにより相互接続された複数の計算機、例えばN台の計算機10−1(#1),10−2(#2),…10−N(#N)を備えて構成される。クラスタシステム1は、クラスタシステム制御機構10を有する。クラスタシステム制御機構10は、計算機10−1(#1),10−2(#2),…10−N(#N)上にまたがって存在する。つまりクラスタシステム1は、計算機10−1〜10−Nを用いて実現されるクラスタシステム制御機構10を有する。
【0018】
クラスタシステム制御機構10は、各計算機10−i(i=1〜N)上に実現されるサービス実行機構11−iを有する。つまり計算機10−iはサービス実行機構11−iを有する。サービス実行機構11−iは、サービスの開始を行うサービス開始手段111−iとサービスの停止を行うサービス停止手段112−iとを有する。クラスタシステム制御機構10はまた、シナリオ管理機構12を有する。シナリオ管理機構12は、全てのサービス実行機構11−1〜11−Nとの間に通信経路13−1〜13−Nを持つ。図1の例では、シナリオ管理機構12は、クラスタシステム1を構成する全ての計算機11−1〜11−Nにまたがって存在する。シナリオ管理機構12は、各計算機11−1〜11−N上で動作し、相互に通信を行うシナリオ管理部12−1〜12−Nによって実現される。本実施形態において、サービス実行機構11−i及びシナリオ管理部12−iは、それぞれ対応するソフトウェアプログラムを計算機10−i(内の図示せぬCPU)が読み取って実行することにより実現されるものとする。
【0019】
ここで、図1のシステム内の各要素について詳述する前に、当該システムで適用される「サービス間の関係」について説明する。サービス間の関係とは、相異なる2つのサービスの間にどのような関係があるかを定めたものである。本実施形態において適用される「サービス間の関係」を規定する要素には、
・サービス間の関係の種類
・サービス間の関係の属性
・サービス間の関係の適用範囲
がある。
【0020】
「サービス間の関係の種類」には、
・依存関係
・排他関係
・無関係
がある。
【0021】
「依存関係」とは、予め決められたサービスが開始しているときのみ、サービスを開始可能な関係である。例えばサービス#1に、サービス#2に対する依存関係が定義されている場合には、サービス#2が既に開始しているときのみ、サービス#1を開始可能である。換言するならば、サービス#1とサービス#2とが開始している状態で、サービス#2が停止したときは、サービス#1も停止する。
【0022】
「排他関係」とは、サービスを開始しているときは、予め決められたサービスが開始していてはならない関係である。例えば、サービス#1に、サービス#2に対する排他関係が定義されている場合、サービス#2が開始していないときのみサービス#1は開始可能であり、サービス#2が開始しているときはサービス#1は開始不可能である。
【0023】
「無関係」とは、あるサービスと別のサービスとの間に、何の関係も存在しない関係である。
「依存関係」と「排他関係」と「無関係」とは、互いに独立である。
【0024】
次に、「サービス間の関係の属性」には、
・強い関係
・弱い関係
がある。
【0025】
「強い関係」とは、対象となるサービス間の関係が、必ず成立しなければならない関係であることを意味する。強い関係であるサービス間の関係に違反するような、サービスの開始あるいはサービスの停止はできない。
【0026】
「弱い関係」とは、ユーザがサービスを開始する計算機を指定せずにサービスの開始操作を行った場合に、シナリオ管理機構12が、自動的にサービスを開始する計算機を決定するために参照される関係であることを意味する。このようなサービスの制御を、サービスの自動制御と呼ぶ。つまり、「弱い関係」は、サービスの自動制御における選択の候補となる「強い関係」を満たす計算機(選択肢)が複数あるときに、その「弱い関係」が成立する計算機が優先的に選択される関係である。ここでは、サービスを開始可能な計算機(その計算機でサービスを開始していることが、強い関係であるサービス間の関係に違反しない計算機)が複数ある場合、それらの中から、弱い関係であるサービス間の関係に違反しない計算機が、サービスを開始する計算機に決定される。
【0027】
「サービス間の関係の適用範囲」には、
・局所的関係
・大局的関係
がある。
【0028】
「局所的関係」とは、対象となるサービス間の関係が、同一計算機でサービスを開始しているときにのみ適用される範囲であることを意味する。「大局的関係」とは、対象となるサービス間の関係が、どの計算機でサービスを開始しているかによらずに適用される範囲であることを意味する。
【0029】
例えば、サービス#1とサービス#2との間に強い排他関係が設定されていて、サービス#1が計算機#1で開始しているものとする。この場合、上記強い排他関係が大局的関係であればサービス#2はいずれの計算機でも開始できず、局所的関係であればサービス#2は計算機#1では開始できない。
【0030】
図2は、図1中のシナリオ管理機構12の構成を示すブロック図である。シナリオ管理機構12は、データベース部121とサービス制御部122とに大別される。
データベース部121は、サービス関係情報データベース(DB)121a、サービス状態情報データベース(DB)121b、計算機状態情報データベース(DB)121c、及びサービス許可状態情報データベース(DB)121dを記憶するための情報記憶部である。
【0031】
サービス関係情報DB121aは、サービス間の関係を管理するためのデータベースである。サービス関係情報DB121aの1つのデータ(レコード)は、サービス名SN1、当該サービス名SN1のサービスと関係するサービスのサービス名SN2、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の5項目で構成される。
【0032】
サービス状態情報DB121bは、サービスの状態を管理するためのデータベースである。サービス状態情報DB121bの1つのデータ(レコード)は、サービス名、計算機名、及び状態の3項目で構成される。サービス名とは、図1のクラスタシステムにより提供されるサービスの名前である。計算機名とは、サービス開始手段111−iを最後に実行させた計算機の名前である。状態とは、サービスが正常に開始しているかどうかを示す情報であり、「開始」、「停止」または「障害発生」の3状態を持つ。
【0033】
計算機状態情報DB121cは、計算機の状態を管理するためのデータベースである。計算機状態情報DB121cの1つのデータ(レコード)は、計算機名及び状態の2項目で構成される。計算機名とは、図1のクラスタシステムを構成する計算機の名前である。状態とは、計算機が正常に動作しているかどうかを示す情報であり、「正常」または「異常」の2状態を持つ。
【0034】
サービス許可状態情報DB121dは、サービスの許可状態を管理するためのデータベースである。サービス許可状態情報DB121dの1つのデータ(レコード)は、サービス名及び許可状態の2項目で構成される。サービス名とは、図1のクラスタシステムにより提供されるサービスの名前である。許可状態とは、サービスが開始していること(つまりサービスが開始状態にあること)が許可されているか許可されていないかを示し、「許可」または「不許可」の2状態を持つ。
【0035】
サービス制御部122は、操作処理部122a、手動制御部122b、自動制御部122c、サービス間関係判定部122d、実行制御部122e及び障害検出部122fの各処理部を有する。
操作処理部122aは、図示せぬクライアント端末(ユーザ端末)からネットワークを介して与えられるユーザからの操作内容を受け取って、その操作内容に対応するサービスの制御(ある計算機で、あるサービスを開始あるいは停止すること)を、手動制御部122bに依頼するユーザインタフェースである。
【0036】
手動制御部122bは、操作処理部122aからサービスの制御依頼(ある計算機で、あるサービスを開始あるいは停止すること)を受け取ると、そのサービスの制御が、サービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認し、実行制御部122eにその制御を依頼する。
【0037】
自動制御部122cは、定期的にサービス許可状態情報DB121dを参照し、当該情報DB121dの変化に応じてサービスの制御を自動的に実行する。即ち自動制御部122cは、あるサービスの許可状態が「許可」になると、そのサービスを開始すること(つまり停止状態から開始状態へ遷移させること)がサービスの状態及び計算機の状態及びサービス間の関係の面から可能であることを確認して、サービスを開始する計算機を決定する。自動制御部122cは、決定した計算機でサービスを開始するための制御を実行制御部122eに依頼する。また自動制御部122cは、許可状態が「不許可」になると、そのサービスを開始している計算機を特定する。自動制御部122cは、特定した計算機で開始されているサービスを停止するための制御を実行制御部122eに依頼する。
【0038】
サービス間関係判定部122dは、手動制御部122bまたは自動制御部122cから受け取ったサービスの制御を実行することが、データベース部121に設定されているサービス間の関係に違反しないかどうかを判定する。
実行制御部122eは、手動制御部122bまたは自動制御部122cから受け取ったサービスの制御を、該当する計算機10−iのサービス実行機構11−iへ伝える。
障害検出部122fは、計算機10−iで障害が発生したことを検出して、サービス状態情報DB121b及び計算機状態情報DB121cを更新する。
【0039】
次に、図1のクラスタシステムの動作について、ユーザによるサービスの開始操作に伴ってシナリオ管理機構12が実行する処理を例に説明する。この処理は、ユーザが、サービスを開始する計算機を指定するか否かで異なる。
【0040】
まず、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構12の主として自動制御部122cによる処理について、図3のフローチャートを参照して説明する。
シナリオ管理機構12内の操作処理部122aは、ユーザからのあるサービス(サービス#jとする)の開始操作内容をクライアント端末から受け取ると、サービス許可状態情報DB121dにアクセスし、サービス#jの許可状態を「許可」にする。
【0041】
自動制御部122cは、サービス許可状態情報DB121dを定期的に参照する(ステップS1)。もし、サービス#jの許可状態が「許可」になったなら(ステップS2)、自動制御部122cは計算機状態情報DB121cを参照し、未判断の計算機があるかを調べる(ステップS3)。ここで、ステップS3の1回目では、全ての計算機が未判断である。ステップS3が繰り返された結果、未判断の計算機がなくなったときは、自動制御部122cは、サービス#jの開始操作に伴う処理を終了する(ステップS4)。
【0042】
これに対し、未判断の計算機があるときは、自動制御部122cは、未判断の計算機のうちの任意の1台を、サービス#jの開始対象計算機の候補(以下、候補計算機と称する)として選択する(ステップS5)。ここでは、計算機10−i(計算機#i)が候補計算機として選択されたものとする。次に自動制御部122cは、選択された候補計算機10−iの状態が「正常」であるかを計算機状態情報DB121cをもとに調べる(ステップS6)。
【0043】
もし、候補計算機10−iの状態が正常でないならば(ステップS6)、自動制御部122cは当該計算機10−iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理(ステップS3)に戻る。これに対し、候補計算機10−iの状態が正常であるならば(ステップS6)、自動制御部122cはサービス間関係判定部122dに問い合わせて、当該計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しないかを調べる(ステップS7)。このサービス間関係判定部122dの処理については後述する。
【0044】
自動制御部122cは、候補計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しているならば(ステップS7)、当該計算機10−iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理(ステップS3)に戻る。これに対し、候補計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反していないならば(ステップS7)、自動制御部122cは当該計算機10−iに対するサービス制御要求を実行制御部122eへ送る。この場合、実行制御部122eは自動制御部122cからのサービス制御要求に従い、当該要求で指定された計算機10−i(計算機#i)のサービス実行機構11−iに対し、サービス#jの開始を行うサービス開始手段111−iを実行させるための命令を送る(ステップS8)。
【0045】
実行制御部122eは、計算機10−iのサービス実行機構11−iに対し、サービス#jの開始を行うサービス開始手段111−iを実行させるための命令を送ると、自動制御部122cに対してサービス制御要求の完了を通知する。自動制御部122cは、サービス制御要求の完了通知を受け取ると、サービス状態情報DB121bにアクセスし、サービス#jの状態を「開始」にする(ステップS9)。以上で、ユーザがサービスを開始する計算機を指定しない場合における、サービス#jの開始操作に伴う処理は終了する(ステップS10)。
【0046】
次に、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構12の主として手動制御部122bによる処理について、図4のフローチャートを参照して説明する。
シナリオ管理機構12内の操作処理部122aは、ユーザからのある計算機(以下、指定計算機と称する)10−i(計算機#i)でのあるサービス(サービス#jとする)の開始操作を受け取る、それに基づいたサービス制御要求を手動制御部122bへ送る。これにより手動制御部122bは、要求されたサービス制御の処理、つまりサービス#jの開始操作に伴う処理を開始する(ステップS11)。
【0047】
まず、手動制御部122bは計算機状態情報DB121cを参照し、指定計算機10−iの状態が正常であるかを調べる(ステップS12)。もし、指定計算機10−iの状態が正常でないならば、手動制御部122bは指定計算機10−iでサービス#jを開始できないものとして、サービス#jの開始操作に伴う処理を終了する(ステップS13)。これに対し、指定計算機10−iの状態が正常であるならば、手動制御部122bは、サービス間関係判定部122dに問い合わせて、当該計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しないかを調べる(ステップS14)。
【0048】
手動制御部122bは、指定計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しているならば(ステップS14)、サービス#jの開始操作に伴う処理を終了する(ステップS13)。これに対し、指定計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反していないならば(ステップS14)、手動制御部122bは当該計算機10−iに対するサービス制御要求を実行制御部122eへ送る。
【0049】
実行制御部122eは、手動制御部122bからのサービス制御要求に従い、当該要求で指定された計算機10−iのサービス実行機構11−iに対し、サービス#jの開始を行うサービス開始手段111−iを実行させるための命令を送る(ステップS15)。そして実行制御部122eは、手動制御部122bに対してサービス制御要求の完了を通知する。手動制御部122bは、サービス制御要求の完了通知を受け取ると、サービス状態情報DB121bにアクセスし、サービス#jの状態を「開始」にする(ステップS16)。以上で、ユーザがサービスを開始する計算機を指定した場合における、サービス#jの開始操作に伴う処理は終了する(ステップS17)。
【0050】
次に、クラスタシステム1内の計算機で発生した障害が検出された場合に、当該障害発生計算機で開始されていたサービスをクラスタシステム1内の他の計算機で引き継ぐ(フェイルオーバする)ために実行されるシナリオ管理機構12の主として自動制御部122cによる処理(フェイルオーバ処理)について、図5のフローチャートを参照して説明する。
【0051】
今、シナリオ管理機構12内の障害検出部122fが、クラスタシステム1内のある計算機、例えば計算機10−k(計算機#k)で発生した障害を検出したものとする。この場合、障害検出部122fは、計算機状態情報DB121cにアクセスし、障害発生計算機10−k(計算機#k)の状態を「異常」にする。また障害検出部122fはサービス状態情報DB121bにもアクセスし、計算機名が「計算機#k」であり、且つ現在の状態が「開始」の全てのサービスついて、当該状態を「障害発生」にする。
【0052】
シナリオ管理機構12内の自動制御部122cは、サービス状態情報DB121bを定期的に参照する(ステップS21)。もし、状態が「障害発生」であるサービスがあったならば(ステップS22)、自動制御部122cは当該サービスをフェイルオーバするための処理を開始する。ここでは、サービス#jの状態が「障害発生」となったことが検出されたものとする。
【0053】
まず、自動制御部122cは計算機状態情報DB121cを参照し、未判断の計算機があるかを調べる(ステップS23)。ここで、ステップS23の1回目では、全ての計算機が未判断である。ステップS23が繰り返された結果、未判断の計算機がなくなったときは、自動制御部122cは、サービス#jをフェイルオーバするための処理を終了する(ステップS24)。
【0054】
これに対し、未判断の計算機があるときは、自動制御部122cは、未判断の計算機のうちの任意の1台を、サービス#jの開始(引き継ぎ)対象計算機の候補(以下、候補計算機と称する)として選択する(ステップS25)。ここでは、計算機10−i(計算機#i)が候補計算機として選択されたものとする。次に自動制御部122cは、選択された候補計算機10−iの状態が「正常」であるかを計算機状態情報DB121cをもとに調べる(ステップS26)。
【0055】
もし、候補計算機10−iの状態が正常でないならば(ステップS26)、自動制御部122cは当該計算機10−iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理(ステップS23)に戻る。これに対し、候補計算機10−iの状態が正常であるならば(ステップS26)、自動制御部122cはサービス間関係判定部122dに問い合わせて、当該計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しないかを調べる(ステップS27)。
【0056】
自動制御部122cは、候補計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反しているならば(ステップS27)、当該計算機10−iを判断済みの計算機とし、上記した未判断の計算機があるかを調べる処理(ステップS23)に戻る。これに対し、候補計算機10−iにおけるサービス#jの開始が、サービス間の関係に違反していないならば(ステップS27)、自動制御部122cは当該計算機10−iに対するサービス制御要求を実行制御部122eへ送る。この場合、実行制御部122eは自動制御部122cからのサービス制御要求に従い、当該要求で指定された計算機10−i(計算機#i)のサービス実行機構11−iに対し、サービス#jの開始を行うサービス開始手段111−iを実行させるための命令を送る(ステップS28)。そして実行制御部122eは、自動制御部122cに対してサービス制御要求の完了を通知する。
【0057】
自動制御部122cは、サービス制御要求の完了通知を受け取ると、サービス状態情報DB121bにアクセスし、サービス#jの状態を「開始」にする(ステップS29)。以上で、障害発生計算機10−k(障害発生計算機#k)が開始していたサービス#jをクラスタシステム1内の他の正常な計算機(ここでは計算機10−i(計算機#i))がフェイルオーバするための処理は終了する(ステップS30)。自動制御部122cは、状態が「障害発生」であるサービスがある限り、上記の処理を繰り返す。
【0058】
次に、シナリオ管理機構12内のサービス間関係判定部122dにより実行されるサービス間関係判定処理(つまり、着目するサービスがサービス間の関係に違反していないかを調べる処理)について、図6のフローチャートを参照して説明する。
【0059】
今、手動制御部122bまたは自動制御部122cからサービス間関係判定部122dに対し、あるサービス#jをある計算機10−i(計算機#i)で開始してよいかという問い合わせが与えられたものとする。ここで、問い合わせられたサービス及び計算機を、それぞれ、対象サービス及び対象計算機と称する。ここでは、対象サービスはサービス#jであり、対象計算機は計算機10−i(計算機#i)であるものとする。
【0060】
サービス間関係判定部122dは、手動制御部122bまたは自動制御部122cからの問い合わせを受け取ると、当該問い合わせで指定された対象サービス#jを当該問い合わせで指定された計算機10−i(計算機#i)で開始することに対する、サービス間の関係に違反しているかを調べるサービス間関係判定処理を開始する(ステップS41)。まず、サービス間関係判定部122dはサービス関係情報DB121aを参照し、当該サービス関係情報DB121a中でサービス名SN1が対象サービス#jを表すデータ(レコード)を全て取得する(ステップS42)。
【0061】
次にサービス間関係判定部122dは、取得したデータの中に、サービス間の関係の種類が「排他関係」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い排他関係」であり、且つ未判断のものがあるかを調べる(ステップS43)。ここで、ステップS43の1回目では、全ての「強い排他関係」が未判断である。ステップS43が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部122dは、後述する依存関係を調べる処理(ステップS50)に進む。
【0062】
一方、未判断の「強い排他関係」のデータがあるときは、サービス間関係判定部122dは、未判断のデータのうちの任意の1つを、サービス間関係の判定対象の候補となるデータ(以下、候補データと称する)として選択する(ステップS44)。次にサービス間関係判定部122dは、サービス状態情報DB121bを参照し、サービス関係情報DB121a中の選択した候補データにおけるサービス名SN2で示されるサービスに関する情報(以下、排他対象データと称する)を取得する(ステップS45)。
【0063】
サービス間関係判定部122dは、取得した排他対象データの状態が「開始」であるかを調べる(ステップS46)。もし、取得した排他対象データの状態が開始でないならば(ステップS46)、サービス間関係判定部122dは当該データを判断済みとし、未判断のものがあるかを調べる処理(ステップS43)に戻る。これに対し、取得した排他対象データの状態が開始であるならば、サービス間関係判定部122dは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる(ステップS47)。
【0064】
もし、取得した排他対象データのサービス間の関係の属性が局所的関係でないならば(ステップS47)、サービス間関係判定部122dはサービス間の関係に違反していると決定する(ステップS49)。これに対し、排他対象データのサービス間の関係の属性が局所的関係であるならば(ステップS47)、サービス間関係判定部122dは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる(ステップS48)。
【0065】
もし、排他対象データに含まれている計算機名が対象計算機を表しているならば(ステップS48)、サービス間関係判定部122dは、対象サービス#jを計算機10−iで開始することがサービス間の関係に違反していると決定する(ステップS49)。これに対し、排他対象データに含まれている計算機名が対象計算機を表していないならば(ステップS48)、サービス間関係判定部122dは当該データを判断済みとし、未判断のものがあるかを調べる処理(ステップS43)に戻る。
【0066】
さて、ステップS43が繰り返された結果、未判断の「強い排他関係」のデータがなくなったときは、サービス間関係判定部122dは、ステップS42で取得したデータの中に、サービス間の関係の種類が「依存」であって且つサービス間の関係の属性が「強い関係」であり、つまり「強い依存関係」であり、且つ未判断のものがあるかを調べる(ステップS50)。ここで、ステップS50の1回目では、全ての「強い依存関係」が未判断である。ステップS50が繰り返された結果、未判断の「強い依存関係」のデータがなくなったときは(ステップS50)、サービス間関係判定部122dは対象サービス#jを計算機10−iで開始することががサービス間の関係に違反していないと決定する(ステップS51)。
【0067】
一方、未判断の「強い依存関係」のデータがあるときは、サービス間関係判定部122dは、未判断の「強い依存関係」のデータのうちの任意の1つを、サービス間関係の判定対象の候補データとして選択する(ステップS52)。次にサービス間関係判定部122dは、サービス状態情報DB121bを参照し、サービス関係情報DB121a中の選択した候補データにおけるサービス名で示されるサービスに関する情報を依存対象データとして取得する(ステップS53)。
【0068】
サービス間関係判定部122dは、取得した依存対象データの状態が「開始」であるかを調べる(ステップS54)。もし、取得した依存対象データの状態が開始であるならば(ステップS54)、サービス間関係判定部122dは当該データを判断済みとし、未判断のものがあるかを調べる処理(ステップS50)に戻る。これに対し、取得した依存対象データの状態が開始でないならば、サービス間関係判定部122dは、当該データのサービス間の関係の属性が、局所的関係であるかを調べる(ステップS55)。
【0069】
もし、取得した依存対象データのサービス間の関係の属性が局所的関係でないならば(ステップS55)、サービス間関係判定部122dは当該データを判断済みとし、未判断のものがあるかを調べる処理(ステップS50)に戻る。これに対し、依存対象データのサービス間の関係の属性が局所的関係であるならば(ステップS55)、サービス間関係判定部122dは、当該排他対象データに含まれている計算機名が、前記対象計算機を表しているかを調べる(ステップS56)。
【0070】
もし、依存対象データに含まれている計算機名が対象計算機を表していないならば(ステップS56)、サービス間関係判定部122dは、対象サービス#jを計算機10−iで開始することがサービス間の関係に違反していると決定する(ステップS57)。これに対し、依存対象データに含まれている計算機名が対象計算機を表しているならば(ステップS56)、サービス間関係判定部122dは当該データを判断済みとし、未判断のものがあるかを調べる処理(ステップS50)に戻る。
【0071】
このように、本発明の第1の実施形態においては、サービス関係情報DB121aによりサービス間の関係を設定することにより、高度で且つ詳細なサービスの制御が実現可能となる。具体的には、順番に開始しなければいけないサービス、同時に開始してはいけないサービスを設定することにより、高度で且つ詳細なサービスの制御がクラスタシステム制御機構10内のシナリオ管理機構12から制御可能となる。また、本発明の第1の実施形態においては、主として自動制御部122cにより実現されるサービスの自動制御を使用することにより、ユーザに求められる判断が減少し、クラスタシステムの制御を容易にすることができる。更に本発明の第1の実施形態においては、サービスをフェイルオーバする仕組みを簡単に実現できる。
【0072】
(第1の実施形態の第1の変形例)
図7は、本発明の第1の実施形態の第1の変形例に係るクラスタシステムの構成を示すブロック図である。なお、図7の構成において、図1と等価な部分には同一の参照符号を付してある。
【0073】
図7に示すクラスタシステム1’の特徴は、図1中のシナリオ管理機構12に相当するシナリオ管理機構12’が、計算機10−1(#1)〜10−N(#N)のうちのいずれか1つの計算機、例えば計算機10−1(#1)上に存在する点にある。
【0074】
本発明の第1の実施形態及びその第1の変形例から明らかなように、クラスタシステム内のシナリオ管理機構は、クラスタシステムを構成する複数の計算機のうちのいずれか1つの計算機上だけに存在しても、全ての計算機上にまたがって存在しても、2つ以上の一部の計算機上に存在しても構わない。
【0075】
(第1の実施形態の第2の変形例)
次に、上記第1の実施形態の第2の変形例について説明する。
サービス間の関係の種類(依存関係、排他関係、無関係)と、サービス間の関係の属性(強い関係、弱い関係)とは、組み合わせることが可能である。その組み合わせの数は、以下に示す5通り、即ち
・強い依存関係
・弱い依存関係
・強い排他関係
・弱い排他関係
・無関係
となる。
【0076】
また、上記5通りの組み合わせに、サービス間の関係の適用範囲(局所的関係、大局的関係)を組み合わせることも可能である。組み合わせの数は、以下に示す10(5×2)通り、即ち
(1)局所的な強い依存関係
(2)局所的な弱い依存関係
(3)局所的な強い排他関係
(4)局所的な弱い排他関係
(5)局所的な無関係
(6)大局的な強い依存関係
(7)大局的な弱い依存関係
(8)大局的な強い排他関係
(9)大局的な弱い排他関係
(10)大局的な無関係
となる。
【0077】
したがって、サービス間の関係を設定するとき、同一のサービス間について、上記10通りの組み合わせから幾つかを選択して同時に設定することが可能である。しかし、同時に設定される選択された組み合わせ(選択パターン)のうちの幾つかは、論理的に矛盾が生じるもの、あるいは無意味なものである。例えば、(6)の組み合わせと(8)の組み合わせとを同時に設定すると、論理的に矛盾が生じる。また、排他関係を考えてみると、(8)の組み合わせを設定しているときに(3)の組み合わせを設定することは無意味である。また、依存関係を考えてみると、(1)の組み合わせを設定しているときに(6)の組み合わせを設定することは無意味である。
【0078】
このような、論理的に矛盾が生じる選択パターン及び無意味な選択パターンを、上記10通りの組み合わせのうちの同時に設定可能な選択パターンの中から除いた場合、設定可能な選択パターンは以下に示す15通り、即ち
(1)局所的な強い依存関係と大局的な強い依存関係
(2)局所的な弱い依存関係と大局的な強い依存関係
(3)局所的な弱い依存関係と大局的な弱い依存関係
(4)大局的な強い依存関係のみ
(5)大局的な弱い依存関係のみ
(6)大局的な強い依存関係と局所的な強い排他関係
(7)大局的な弱い依存関係と局所的な強い排他関係
(8)大局的な強い依存関係と局所的な弱い排他関係
(9)大局的な弱い依存関係と局所的な弱い排他関係
(10)局所的な弱い排他関係のみ
(11)局所的な強い排他関係のみ
(12)局所的な弱い排他関係と大局的な弱い排他関係
(13)局所的な強い排他関係と大局的な弱い排他関係
(14)局所的な強い排他関係と大局的な強い排他関係
(15)無関係のみ
となる。
【0079】
このように、本発明の第1の実施形態の第2の変形例においては、サービス間の関係の種類、その属性、及びその適用範囲の組み合わせのうちから、幾つかを選択してサービス関係情報DB121aに設定するとき、論理的に矛盾が生じる選択パターンと論理的に無意味な選択パターンとを予め除いておくことで、論理的に正しいサービス間の関係を効率よく設定可能となる。
【0080】
[第2の実施形態]
次に本発明の第2の実施形態について説明する。
図8は図1のクラスタシステム内で、図2の構成のシナリオ管理機構12に代えて用いられるシナリオ管理機構120の構成を示すブロック図である。なお、図8の構成において、図2と等価な部分には同一の参照符号を付してある。
【0081】
図8の構成のシナリオ管理機構120の特徴は、バッチジョブが実現可能な構成を有している点にある。バッチジョブとは、予め定められた一連の処理を実行し、その処理の終了をもってジョブの終了とする方式のジョブである。従来のクラスタシステムでは、サービスを停止させるには、必ずユーザによる操作が必要であるため、バッチジョブのような自動的に終了する処理をサービスとして実現することが困難であった。
【0082】
図8のシナリオ管理機構120はバッチジョブ制御部122gを有する。このシナリオ管理機構120の構成は、図2のシナリオ管理機構12に、バッチジョブ制御部122gが追加された構成と等価である。バッチジョブ制御部122gはバッチジョブ型サービス情報DB121eを有する。このバッチジョブ型サービス情報DB121eは、バッチジョブとして扱うサービス(バッチジョブ型サービス)のデータベースである。バッチジョブ型サービス情報DB121eの1つのデータ(レコード)は、サービス名及び状態の2項目で構成される。サービス名とは、クラスタシステムにより提供されるバッチジョブ型サービスの名前である。状態とは、バッチジョブ型サービスが実行中かどうかを示す情報であり、「実行中」または「停止」の2状態を持つ。
【0083】
次に、図8に示した構成のシナリオ管理機構120の主としてバッチジョブ制御部122gによる処理について、あるバッチジョブ型サービス(サービス#jとする)を扱う処理を例に、図9のフローチャートを参照して説明する。
まず、バッチジョブ型サービス情報DB121eには、サービス名がサービス#jで状態が「停止」のデータ(レコード)が設定されているものとする。この状態で、操作処理部122aが、ユーザからのサービス#jの開始操作を受け取ったものとする。すると操作処理部122aは、サービス許可状態情報DB121dにアクセスして、サービス#jの許可状態を「許可」にする。
【0084】
バッチジョブ制御部122gは、サービス許可状態情報DB121dを定期的に参照し、その都度サービス#jに関するデータを取得する(ステップS61)。もし、サービス許可状態情報DB121dから取得したサービス#jの許可状態が「許可」になったならば(ステップS62)、バッチジョブ制御部122gはバッチジョブ型サービス情報DB121eにアクセスしてサービス#jの状態を「実行中」にする(ステップS63)。
【0085】
次にバッチジョブ制御部122gは定期的にサービス状態情報DB121bを参照して、サービス#jに関するデータ(レコード)を取得する。一方、自動制御部122cは、この例のように、サービス#jの許可状態が「許可」となった場合、当該サービス#jの開始処理を実行し、その最後でサービス状態情報DB121bにアクセスして、サービス#jの状態を「開始」にする。
【0086】
バッチジョブ制御部122gは、サービス状態情報DB121b中のサービス#jの状態が「開始」になると(ステップS64)、サービス許可状態情報DB121dにアクセスして、当該サービス#jの許可状態を「不許可」にする(ステップS65)。自動制御部122cは、サービス#jの許可状態が「不許可」になると、当該サービス#jを停止する処理を実行し、その最後でサービス状態情報DB121bにアクセスして、当該サービス#jの状態を「停止」にする。
【0087】
バッチジョブ制御部122gは、サービス状態情報DB121b中のサービス#jの状態が「停止」になると(ステップS66)、バッチジョブ型サービス情報DB121eにアクセスして、当該サービス#jの状態を停止にする(ステップS67)。以上でサービス#jのバッチジョブ処理は終了する(ステップS67)。
【0088】
このように本発明の第2の実施形態においては、バッチジョブ制御部122gを備えたシナリオ管理機構120を用いることにより、サービスをバッチジョブとして扱うことが可能となる。これにより、例えばデータのバックアップのようなバッチジョブとして扱うのに適した処理を、シナリオ管理機構120によって制御可能となる。
【0089】
[第3の実施形態]
次に本発明の第3の実施形態について説明する。
図10は本発明の第3の実施形態に係るクラスタシステム(n対mバックアップ構成クラスタシステム)の構成を示すブロック図である。この図10のn対mバックアップ構成クラスタシステムの特徴は、従来から知られているn対m(nは2以上の整数、mは1以上の整数)バックアップ構成を、前記第1の実施形態で適用されたクラスタシステムを応用して実現している点にある。
【0090】
図10のn対mバックアップ構成クラスタシステムは、n個の1対mバックアップ構成クラスタシステム1−1(#1),1−2(#2),…1−n(#n)から構成されている。クラスタシステム1−1(#1),1−2(#2),…1−n(#n)は、それぞれ、稼働系計算機として用いられる計算機100−1(#1),100−2(#2),…100−n(#n)を備えている。計算機100−1(#1),100−2(#2),…100−n(#n)は、それぞれサービス#1,#2,…#nを提供する。クラスタシステム1−1(#1),1−2(#2),…1−n(#n)は、当該クラスタシステム1−1(#1),1−2(#2),…1−n(#n)内の稼働系計算機100−1(#1),100−2(#2),…100−n(#n)に対応して共通に設けられ、待機系計算機として用いられるm台の計算機100−(n+1)(#n+1),100−(n+2)(#n+2),…100−(n+m)(#n+m)を備えている。クラスタシステム1−1(#1)〜1−n(#n)内の稼働系計算機100−1(#1)〜100−n(#n)、及びクラスタシステム1−1(#1)〜1−n(#n)に共通の待機系計算機100−(n+1)(#n+1)〜100−(n+m)(#n+m)は、図示せぬネットワークにより相互接続されている。
【0091】
このように、図10に示したn対mバックアップ構成クラスタシステムは、計算機資源を節約するためにm台の計算機100−(n+1)(#n+1)〜100−(n+m)(#n+m)をいずれも待機系計算機として共通に使用する、n個の1対mバックアップ構成クラスタシステム1−1(#1)〜1−n(#n)から構成される。このn対mバックアップ構成クラスタシステムでは、サービス#1〜#nを提供するn台の稼働系計算機100−1〜100−nのうちのいずれかで障害が発生した場合に、その計算機が提供していたサービスを、m台の計算機100−(n+1)〜100−(n+m)のいずれかで引き継ぐことが可能なように構成されている。図10のn対mバックアップ構成クラスタシステムの構成は、n個の1対mバックアップ構成クラスタシステム1−1(#1)〜1−n(#n)を備えている点を除けば、前記第1の実施形態におけるクラスタシステムと同様である。即ち図10のn対mバックアップ構成クラスタシステムは、計算機100−1(#1)〜100−(n+m)(#n+m)毎に設けられるサービス実行機構と図2の構成のシナリオ管理機構とを含むクラスタシステム制御機構(いずれも図示せず)を有している。したがって、第3の実施形態では、必要に応じて図2を援用する。
【0092】
従来技術では、n対mバックアップ構成の計算機システムを実現するためには、n個のサービス#1〜#n全てに対して、どの計算機で開始し、障害発生時にはどの計算機へ引き継ぐのかを、同じ計算機にサービスが集中しないように注意しながら設定する必要がある。これに対して、本発明の第3の実施形態では、前記第1の実施形態で適用されたクラスタシステムを用いることにより、この種の設定が以下に述べるように簡単に行える。
【0093】
図11は、図10のn対mバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報DB121aの一例を示す。この図11のサービス関係情報DB121aには、図10のn対mバックアップ構成クラスタシステムにより提供されるn個のサービスのうちのサービス#i(i=1〜n−1)と他のサービス#j(j=i+1〜n)との全ての組み合わせについて、その組み合わせのサービスを表すサービス名(SN1,SN2)、サービス(#i,#j)間の関係の種類、サービス(#i,#j)間の関係の属性、及びサービス(#i,#j)間の関係の適用範囲の情報が登録されている。ここでは、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲は、サービスの組み合わせに無関係に、
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
のように設定される。
【0094】
次に、図11に示すサービス関係情報DB121aを適用した図10のn対mバックアップ構成クラスタシステムの動作を、図2の構成及び図5のフローチャートを援用して説明する。
図2に示すシナリオ管理機構12中の操作処理部122aは、ユーザによるn個のサービス#1〜#nの開始操作を受け取ると、サービス許可状態情報DB121dにアクセスし、n個のサービス#1〜#nの許可状態をいずれも「許可」にする。自動制御部122cは、サービス許可状態情報DB121d中のサービス#1〜#nの許可状態が「許可」になったなら、そのサービス#1〜#nを、サービス関係情報DB121aにより示されるサービス間の関係に従い、n対mバックアップ構成クラスタシステムを構成するn+m台の計算機のうちのn台の稼働系計算機100−1(#1)〜100−n(#n)で1サービスずつ開始させる。ここでは、計算機100−i(#i)でサービス#iが開始されるものとする。
【0095】
この状態で、例えば計算機100−1(#1)で障害が発生したために、当該計算機100−1で開始していたサービス#1をフェイルオーバするものとする。このフェイルオーバ処理は、前記第1の実施形態と同様に、自動制御部122cにより図5のフローチャートに従って実行される。即ち自動制御部122cは、サービス状態情報DB121bを参照することで、サービス#1を開始していた計算機100−1で障害が発生したことを検出すると(図5ステップS21,S22)、当該サービス#1を引き継ぐ計算機を、図5のステップS23から始まる一連の処理(ステップS23,S25〜S27)により決定する。ここでは、計算機状態情報DB121cの示す計算機状態及びサービス関係情報DB121aの示すサービス間の関係をもとに、図10のn対mバックアップ構成クラスタシステム内のn+m台の計算機の中から、サービス#1の開始がサービス間の関係に違反しない正常な計算機が1つ選択される。図11に示すサービス関係情報DB121aの例では、サービス#1の開始がサービス間の関係に違反しない計算機は、サービスを開始していない待機系の計算機100−(n+1)〜100−(n+m)であり、そのうちの計算機100−(n+1)が選択されたものとする。この場合、計算機100−(n+1)によりサービス#1が開始される(引き継がれる)。
【0096】
更に、この状態で計算機100−2で障害が発生し、当該計算機100−2で開始していたサービス#2をフェイルオーバするものとする。この場合も上記と同様に、自動制御部122cにより引継ぎ先の計算機が決定される。ここでは、稼働系の計算機100−1〜100−nとサービス#1を引き継いだ計算機100−(n+1)とを除くm−1台の計算機100−(n+2)〜100−(n+m)のうちの1つ、例えば計算機100−(n+2)が引継ぎ先の計算機として選択され、当該計算機100−(n+2)でサービス#2が開始される(引き継がれる)ものとする。
【0097】
以下、同様の制御により、n≧mの場合には、計算機100−1〜100−nのうちのm台の計算機で障害が発生しても、そのm台の計算機で開始されていたサービスを、m台の待機系の計算機100−(n+1)〜100−(n+m)へ自動的にフェイルオーバできる。つまり、図10のn対mバックアップ構成クラスタシステムでは、n≧mの場合には、m個までのサービスを、m台の待機系の計算機100−(n+1)〜100−(n+m)へフェイルオーバできる。また、n<mの場合には、n個までのサービスを、m台の待機系の計算機100−(n+1)〜100−(n+m)のうちのn台へフェイルオーバできる。
【0098】
このように本発明の第3の実施形態においては、サービス関係情報DB121aを利用すると共に、全てのサービス間(サービスの組み合わせ)の関係について、当該サービス関係情報DB121aにて、いずれも、サービス間の関係の種類=排他関係、サービス間の属性=強い関係、サービス間の適用範囲=局所的関係と定義することにより、n対mバックアップ構成を実現できる。この第3の実施形態は、前記第1の実施形態で適用されたサービス間の関係と自動制御部122cによるサービスの自動制御とを組み合わせたものであり、従来のn対mバックアップ構成のクラスタシステムに比べ、設定が簡単で且つ統一的といえる。
【0099】
[第4の実施形態]
次に本発明の第4の実施形態について説明する。この第4の実施形態の特徴は、前記第2の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのコールドバックアップを実現している点にある。したがって、クラスタシステムの構成については、図1及び図8を援用する。
【0100】
データのコールドバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させてデータのバックアップをとる操作をいう。つまり、バックアップ処理中にデータへのアクセスが発生しないバックアップ形態をデータのコールドバックアップと呼ぶ。
【0101】
従来のクラスタシステムでコールドバックアップを実現するには、まずデータにアクセスするサービスを停止してから、データをバックアップする処理を実行し、その後再びデータにアクセスするサービスを開始するという操作を、ユーザが行う必要がある。また従来のクラスタシステムでは、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第4の実施形態では、第2の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【0102】
図12は、本発明の第4の実施形態で適用される、(図1のクラスタシステム1中のシナリオ管理機構12に代えて用いられる)図8の構成のシナリオ管理機構120が有するサービス関係情報DB121aの一例を示す。この第4の実施形態では、図12のサービス関係情報DB121aに登録されるサービスとして、以下に示す3つのサービス
・データに相当するサービス(データそれ自体)
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第2の実施形態で適用されたバッチジョブ型のサービスとする。
【0103】
図12に示すサービス関係情報DB121aでは、サービス間の関係として、サービス間の関係#1乃至#3の3種が定義される。このサービス間の関係#1乃至#3のそれぞれについての、サービス関係情報DB121aのデータ(レコード)の内容、即ちサービス名SN1,SN2、サービス間の関係の種類、サービス間の関係の属性、及びサービス間の関係の適用範囲の情報は次の通りである。
【0104】
(サービス間の関係#1)
まず、サービス間の関係#1についての情報は、
・サービス名SN1…データにアクセスするサービス
・サービス名SN2…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
である。
【0105】
(サービス間の関係#2)
次に、サービス間の関係#2についての情報は、
・サービス名SN1…データをバックアップするサービス
・サービス名SN2…データに相当するサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…局所的関係
(サービス間の関係#3)
最後に、サービス間の関係#3についての情報は、
・サービス名SN1…データにアクセスするサービス
・サービス名SN2…データをバックアップするサービス
・サービス間の関係の種類…排他関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。
【0106】
次に、本発明の第4の実施形態におけるデータのコールドバックアップについて、図1及び図8の構成並びに図3及び図9のフローチャートを援用して説明する。但し、図1中のシナリオ管理機構12に代えて、図8の構成のシナリオ管理機構120が用いられているものとする。
【0107】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係#1により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係#1により、同一の計算機で開始される。ここでは、上記両サービスは、図1のクラスタシステム中の計算機10−1で開始されるものとする。
【0108】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図8に示したシナリオ管理機構120内の操作処理部122aは、サービス許可状態情報DB121dにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【0109】
自動制御部122cは、サービス許可状態情報DB121dを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係#2に従い、当該「許可」となった「データをバックアップするサービス」を、「データに相当するサービス」が開始されている計算機10−1で開始させる(図3ステップS2〜S10)。この状態で、自動制御部122cはサービス間の関係#3に従い、計算機10−1で開始されている「データにアクセスするサービス」を停止させる。
【0110】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、上記の例のように、「データをバックアップするサービス」が計算機10−1で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部122gにより直ちに「不許可」にされる(図9ステップS62〜S65)。すると自動制御部122cは、計算機10−1での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【0111】
さて、計算機10−1での「データをバックアップするサービス」が停止されると、「データにアクセスするサービス」が開始していることがサービス間の関係#3に違反しなくなる。このため、自動制御部122cは、「データにアクセスするサービス」を再び開始させる(図3ステップS7〜S9)。
【0112】
このように本発明の第4の実施形態においては、サービス関係情報DB121aを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データをバックアップするサービス」と「データにアクセスするサービス」との間に強い排他関係を大局的関係として設定することにより、データのコールドバックアップを実現できる。この第4の実施形態は、前記第2の実施形態で適用されたサービス間の関係と自動制御部122cによるサービスの自動制御とを組み合わせて応用したものであり、従来のクラスタシステムを用いてデータのコールドバックアップを実現するのに比べて、ユーザがサービスを開始したり停止したりする必要がない。更に第4の実施形態では、「データをバックアップするサービス」を開始するときに、どの計算機で「データに相当するサービス」が開始されているかを明示的に指定したり、サービスを開始する順番を考慮したりする必要もない。よって第4の実施形態によるクラスタシステムは、従来のクラスタシステムより設定が簡単で且つ統一的といえる。
【0113】
[第5の実施形態]
次に本発明の第5の実施形態について説明する。この第5の実施形態の特徴は、前記第2の実施形態で適用されたクラスタシステムにより、サービス間の関係を利用してデータのオンラインバックアップを実現している点にある。したがって、クラスタシステムの構成については、図1及び図8を援用する。
【0114】
データのオンラインバックアップとは、データと、そのデータにアクセスするサービスがあるときに、データにアクセスするサービスを停止させずにデータのバックアップをとる操作をいう。
【0115】
従来のクラスタシステムでオンラインバックアップを実現するには、データにアクセスするサービスとデータをバックアップする処理が、データが存在する計算機で実行されるようにしたり、データにアクセス可能となってからデータにアクセスするサービスを開始したりといったサービス及び処理の制御を、ユーザの操作により行う必要がある。本発明の第5の実施形態では、第2の実施形態で適用されたクラスタシステムを用いることにより、この種のサービス及び処理の制御が以下に述べるように自動的に行える。
【0116】
図13は、本発明の第5の実施形態で適用される、(図1のクラスタシステム1中のシナリオ管理機構12に代えて用いられる)図8の構成のシナリオ管理機構120が有するサービス関係情報DB121aの一例を示す。この第5の実施形態では、図13のサービス関係情報DB121aに登録されるサービスとして、前記第4の実施形態と同様に、以下に示す3つのサービス
・データに相当するサービス
・データにアクセスするサービス
・データをバックアップするサービス
が用意される。「データをバックアップするサービス」は、前記第2の実施形態で適用されたバッチジョブ型のサービスとする。
【0117】
図13に示すサービス関係情報DB121aでは、サービス間の関係として、サービス間の関係#1乃至#3の3種が定義される。このサービス間の関係#1乃至#3のうち、サービス間の関係#1及び#2については、第4の実施形態におけるサービス間の関係#1及び#2に一致するため、説明を省略する。一方、サービス間の関係#3は、第4の実施形態におけるサービス間の関係#3と、サービス間の関係の種類が異なる。
【0118】
即ち、第5の実施形態で適用されるサービス間の関係#3は、
・サービス名SN1…データをバックアップするサービス
・サービス名SN2…データにアクセスするサービス
・サービス間の関係の種類…依存関係
・サービス間の関係の属性…強い関係
・サービス間の関係の適用範囲…大局的関係
である。このように、第5の実施形態で適用されるサービス間の関係#3は、サービス名SN1及びSN2が第4の実施形態と逆となり、「サービス間の関係の種類」が「依存関係」となり、「サービス間の関係の適用範囲」が大局的関係となっている点に特徴がある。
【0119】
次に、本発明の第5の実施形態におけるデータのコールドバックアップについて、図1及び図8の構成並びに図3及び図9のフローチャートを援用して説明する。但し、図1中のシナリオ管理機構12に代えて、図8の構成のシナリオ管理機構120が用いられているものとする。
【0120】
今、「データに相当するサービス」及び「データにアクセスするサービス」が既に開始されているものとする。ここでは、サービス間の関係#1により、「データに相当するサービス」が先に開始される。また、「データに相当するサービス」及び「データにアクセスするサービス」の両サービスは、サービス間の関係#1により、同一の計算機で開始される。ここでは、上記両サービスは、第4の実施形態と同様に、図1のクラスタシステム中の計算機10−1で開始されるものとする。
【0121】
このような状態で、ユーザがデータのバックアップのために、クライアント端末上で「データをバックアップするサービス」を開始する操作を行ったものとする。すると、図8に示したシナリオ管理機構120内の操作処理部122aは、サービス許可状態情報DB121dにアクセスし、「データをバックアップするサービス」の許可状態を「許可」にする。
【0122】
自動制御部122cは、サービス許可状態情報DB121dを定期的に参照しており、「データをバックアップするサービス」の許可状態が「許可」にされると、サービス間の関係#2及び#3に従い、当該「データをバックアップするサービス」を、「データに相当するサービス」及び「データにアクセスするサービス」が開始されている計算機10−1で開始させる(図3ステップS2〜S10)。
【0123】
「データをバックアップするサービス」は、バッチジョブ型のサービスである。このため、「データをバックアップするサービス」が計算機10−1で開始されると、当該「データをバックアップするサービス」の許可状態が、バッチジョブ制御部122gにより直ちに「不許可」にされる(図9ステップS62〜S65)。すると自動制御部122cは、計算機10−1での「データをバックアップするサービス」を停止する処理を実行する。この「データをバックアップするサービス」を停止する処理は、当該サービスの開始に伴う処理、即ちデータをバックアップするための処理が完了した後に行われる。
【0124】
このように本発明の第5の実施形態においては、サービス関係情報DB121aを利用して、「データに相当するサービス」、「データをバックアップするサービス」及び「データにアクセスするサービス」を定義し、「データに相当するサービス」に対して、それぞれ「データをバックアップするサービス」と「データにアクセスするサービス」とから強い依存関係を局所的関係として設定すると共に、「データにアクセスするサービス」に対して「データをバックアップするサービス」から強い依存関係を大局的関係として設定することにより、データのオンラインバックアップを実現できる。この第5の実施形態は、前記第2の実施形態で適用されたサービス間の関係と自動制御部122cによるサービスの自動制御とを組み合わせて応用したものであり、前記第4の実施形態と同様に、従来のクラスタシステムを用いてデータのオンラインバックアップを実現するのに比べて、設定が簡単で且つ統一的といえる。
【0125】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【0126】
【発明の効果】
以上詳述したように本発明によれば、クラスタシステムにより提供されるサービスに関し、サービス間関係情報記憶手段に記憶されているサービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御することにより、サービス間の関係に合致した高度で且つ詳細なサービスの制御が実現できる。よって、クラスタシステムにより複数のサービスを提供する場合に、システムの可用性、計算機資源の有効活用及びサービスの処理能力の向上の面から最適になるようにサービスを計算機に配置でき、ホットスタンバイ型のクラスタシステムより高度なサービスの制御が実現できる。
【図面の簡単な説明】
【図1】本発明の第1の実施形態に係るクラスタシステムの構成を示すブロック図。
【図2】図1中のシナリオ管理機構12の構成を示すブロック図。
【図3】同第1の実施形態において、ユーザがサービスを開始する計算機を指定しない場合におけるシナリオ管理機構12の主として自動制御部122cによる処理を説明するためのフローチャート。
【図4】同第1の実施形態において、ユーザがサービスを開始する計算機を指定する場合におけるシナリオ管理機構12の主として手動制御部122bによる処理を説明するためのフローチャート。
【図5】同第1の実施形態におけるシナリオ管理機構12の主として自動制御部122cによるフェイルオーバ処理を説明するためのフローチャート。
【図6】同第1の実施形態におけるサービス間関係判定処理を説明するためのフローチャート。
【図7】同第1の実施形態の第1の変形例に係るクラスタシステムの構成を示すブロック図。
【図8】同第1の実施形態の第2の変形例で適用されるシナリオ管理機構の構成を示すブロック図。
【図9】同第2の変形例におけるシナリオ管理機構120の主としてバッチジョブ制御部122gによる処理を説明するためのフローチャート。
【図10】本発明の第3の実施形態に係るn対mバックアップ構成クラスタシステムのブロック構成図。
【図11】図10のn対mバックアップ構成クラスタシステム中のシナリオ管理機構が有するサービス関係情報DB121aの一例を示す図。
【図12】本発明の第4の実施形態で適用される、データのコールドバックアップを実現するためのサービス関係情報DB121aの一例を示す図。
【図13】本発明の第5の実施形態で適用される、データのオンラインバックアップを実現するためのサービス関係情報DB121aの一例を示す図。
【符号の説明】
1…クラスタシステム、10…クラスタシステム制御機構、10−1〜10−N…計算機、11−1〜11−N…サービス実行機構、12,12’…シナリオ管理機構、100−1〜100−n…稼働系計算機、100−(n+1)〜100−(n+m)…待機系計算機、121…データベース部、121a…サービス関係情報DB、121b…サービス状態情報DB、121c…計算機状態情報DB、121d…サービス許可状態情報DB、121e…バッチジョブ型サービス情報DB、122…サービス制御部、122a…操作処理部、122b…手動制御部、122c…自動制御部、122d…サービス間関係判定部、122e…実行制御部、122g…バッチジョブ制御部。
Claims (15)
- 複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステムにおいて、
前記複数種類のサービスのうちの相異なる2種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報を記憶するサービス間関係情報記憶手段と、
前記複数の計算機の各々に設けられ、サービスの開始及び停止を司るサービス実行手段と、
前記クラスタシステムにより提供されるサービスに関し、前記サービス間関係情報の示すサービス間関係に合致するように、当該サービスの開始または停止を制御するサービス制御手段であって、当該サービスの開始制御では、前記サービス間関係情報の示すサービス間関係に合致する、当該サービスの提供が可能な計算機を選択して、その計算機の前記サービス実行手段に対して当該サービスの開始を指示し、当該サービスの停止制御では、当該サービスを開始している計算機の前記サービス実行手段に対して当該サービスの停止を指示するサービス制御手段と
を具備することを特徴とするクラスタシステム。 - 前記サービス間関係情報はサービス間の関係の種類を示す情報を含み、当該サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であることを特徴とする請求項1記載のクラスタシステム。
- 前記サービス間関係情報はサービス間の関係の属性を示す情報を含み、当該サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、前記サービス制御手段による選択の候補となる前記強い関係を満たす選択肢が複数あるときにそれが成立するものが選択される弱い関係とが設定可能であることを特徴とする請求項1記載のクラスタシステム。
- 前記サービス間関係情報はサービス間の関係の適用範囲を示す情報を含み、当該サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能であることを特徴とする請求項1記載のクラスタシステム。
- 前記複数種類のサービスの各々について当該サービスの許可状態を管理するためのサービス許可状態情報を記憶するサービス許可状態情報記憶手段を更に具備し、
前記サービス制御手段は、前記サービス許可状態情報の示す許可状態に対応して前記サービス間関係情報の示すサービス間の関係が合致するように、開始すべきサービス及び当該開始すべきサービスを開始する計算機、あるいは停止すべきサービス及び当該停止すべきサービスを開始している計算機を選択する自動制御手段を含む
ことを特徴とする請求項1記載のクラスタシステム。 - 前記サービス制御手段は、あるサービスの開始または停止が外部から指定された場合に、当該サービスに対応する前記サービス許可状態情報の示す許可状態を許可または不許可にする操作処理手段を含むことを特徴とする請求項5記載のクラスタシステム。
- 前記サービス制御手段は、前記サービス実行手段によりサービスが開始された場合に、当該サービスに対応する前記サービス許可状態情報の示す許可状態を不許可にするバッチジョブ制御手段を更に含み、
前記自動制御手段は、前記サービス許可状態情報の示す許可状態が不許可となった場合、当該サービス許可状態情報に対応するサービスの停止制御を行う
ことを特徴とする請求項5記載のクラスタシステム。 - 前記サービス間関係情報は、サービス間の関係の種類、サービス間の関係の属性及びサービス間の関係の適用範囲を示す情報を含み、前記サービス間の関係の種類として、予め定められたサービスが開始しているときのみサービスを開始可能な依存関係と、サービスを開始しているときは予め決められたサービスが開始していてはならない排他関係と、無関係とが設定可能であり、前記サービス間の関係の属性として、当該サービス間の関係が必ず成立しなければならない強い関係と、前記自動制御手段による選択の候補となる前記強い関係を満たす計算機が複数存在するときに当該サービス間の関係が成立する計算機が優先的に選択される弱い関係とが設定可能であり、前記サービス間の関係の適用範囲として、同一計算機でサービスが開始しているときにのみ当該サービス間の関係が適用される局所的関係と、いずれの計算機でサービスが開始しているかによらずに当該サービス間の関係が適用される大局的関係とが設定可能であることを特徴とする請求項5記載のクラスタシステム。
- 同一のサービス間について、前記サービス間の関係の種類、前記サービス間の関係の属性及び前記サービス間の関係の適用範囲の異なる組み合わせのうち、前記サービス間関係情報記憶手段に同時に設定された場合に論理的に矛盾が生じる、あるいは無意味となる組み合わせを、前記サービス間関係情報記憶手段への設定対象外とすることを特徴とする請求項8記載のクラスタシステム。
- 前記クラスタシステムを構成する計算機の台数はn+m台(nは2以上の整数、mは1以上の整数)であり、当該n+m台の計算機のうちのn台はそれぞれ固有の種類のサービスを提供する稼働系計算機であり、残りのm台は前記n台の稼働系計算機のいずれかの計算機に障害が発生した場合に、当該障害発生計算機で開始されていたサービスを引き継ぐことが可能な待機系計算機であり、
前記サービス間関係情報記憶手段に記憶される、前記n台の稼働系計算機がそれぞれ提供するサービスのうちの相異なる2種類のサービスの組み合わせ毎の全てのサービス間関係情報に、前記サービス間の関係の種類、前記サービス間の関係の属性及び前記サービス間の関係の適用範囲として、それぞれ排他関係、強い関係及び局所的関係が設定されている
ことを特徴とする請求項8記載のクラスタシステム。 - 前記クラスタシステムにより提供されるサービスとして、データに相当する第1のサービス、データをバックアップする第2のサービス及びデータにアクセスする第3のサービスの3種類のサービスが定義されると共に、
前記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、前記第1のサービスに対して前記第2のサービスと前記第3のサービスとから強い依存関係が局所的関係として設定され、前記第2のサービスと前記第3のサービスとの間に強い排他関係が大局的関係として設定されている
ことを特徴とする請求項8記載のクラスタシステム。 - 前記クラスタシステムにより提供されるサービスとして、データに相当する第1のサービス、データをバックアップする第2のサービス及びデータにアクセスする第3のサービスの3種類のサービスが定義されると共に、
前記サービス間関係情報記憶手段に記憶されるサービス間関係情報には、前記第1のサービスに対して前記第2のサービスと前記第3のサービスとから強い依存関係が局所的関係として設定され、前記第3のサービスに対して前記第2のサービスから強い依存関係が大局的関係として設定されている
ことを特徴とする請求項8記載のクラスタシステム。 - 複数の計算機から構成され、複数種類のサービスが提供可能なクラスタシステム内の前記計算機でサービスの実行を制御するために実行されるサービス制御プログラムであって、
前記計算機に、
前記クラスタシステムにより提供可能なサービスのうち開始すべきサービスを検出するステップと、
前記複数の計算機の中から、前記検出された開始すべきサービスを提供可能な正常な計算機を順次選択するステップと、
前記計算機が選択される都度、前記複数種類のサービスのうちの相異なる2種類のサービスの組み合わせ毎に、そのサービス間の関係を予め定義したサービス間関係情報が記憶されたサービス間関係情報記憶手段を参照することにより、前記選択された計算機で前記検出されたサービスを開始することが、対応する前記サービス間関係情報の示すサービス間関係に合致するかを判定するステップと、
前記サービス間関係に合致すると判定された場合に、前記選択された計算機で前記検出されたサービスを開始させるステップと
を実行させるためのサービス制御プログラム。 - 前記検出ステップでは、外部から開始が指定されたサービス、または障害が発生した計算機で開始されていたサービスが、開始すべきサービスとして検出されることを特徴とする請求項13記載のサービス制御プログラム。
- 前記計算機に、
前記クラスタシステムにて開始されているサービスのうち停止すべきサービスを検出するステップと、
前記検出された停止すべきサービスを開始している計算機を特定するステップと、
前記特定された計算機で開始されている前記検出された停止すべきサービスを停止させるステップと
を更に実行させるための請求項13記載のサービス制御プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003176959A JP4363914B2 (ja) | 2003-06-20 | 2003-06-20 | クラスタシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003176959A JP4363914B2 (ja) | 2003-06-20 | 2003-06-20 | クラスタシステム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2005011237A true JP2005011237A (ja) | 2005-01-13 |
JP4363914B2 JP4363914B2 (ja) | 2009-11-11 |
Family
ID=34099688
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003176959A Expired - Lifetime JP4363914B2 (ja) | 2003-06-20 | 2003-06-20 | クラスタシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4363914B2 (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007172334A (ja) * | 2005-12-22 | 2007-07-05 | Internatl Business Mach Corp <Ibm> | 並列型演算システムの冗長性を確保するための方法、システム、およびプログラム |
JP2010198060A (ja) * | 2009-02-23 | 2010-09-09 | Nec Corp | サーバシステム及びサーバシステムの制御方法 |
JP2011138454A (ja) * | 2010-01-04 | 2011-07-14 | Nomura Research Institute Ltd | 運用管理装置、運用システムおよび定義データ同期方法 |
US9703653B2 (en) | 2012-12-12 | 2017-07-11 | Kabushiki Kaisha Toshiba | Cloud system management apparatus, cloud system, reallocation method, and computer program product |
-
2003
- 2003-06-20 JP JP2003176959A patent/JP4363914B2/ja not_active Expired - Lifetime
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2007172334A (ja) * | 2005-12-22 | 2007-07-05 | Internatl Business Mach Corp <Ibm> | 並列型演算システムの冗長性を確保するための方法、システム、およびプログラム |
US8713352B2 (en) | 2005-12-22 | 2014-04-29 | International Business Machines Corporation | Method, system and program for securing redundancy in parallel computing system |
JP2010198060A (ja) * | 2009-02-23 | 2010-09-09 | Nec Corp | サーバシステム及びサーバシステムの制御方法 |
JP2011138454A (ja) * | 2010-01-04 | 2011-07-14 | Nomura Research Institute Ltd | 運用管理装置、運用システムおよび定義データ同期方法 |
US9703653B2 (en) | 2012-12-12 | 2017-07-11 | Kabushiki Kaisha Toshiba | Cloud system management apparatus, cloud system, reallocation method, and computer program product |
Also Published As
Publication number | Publication date |
---|---|
JP4363914B2 (ja) | 2009-11-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6477563B1 (en) | Agent system and information processing method for same | |
US8145741B2 (en) | Selecting a target design based on criteria | |
US6195678B1 (en) | Remote resource management system for automatically downloading required files from application server depending on contents of selected files on requesting computer | |
US9075661B2 (en) | Placing objects on hosts using hard and soft constraints | |
JP4597488B2 (ja) | プログラム配置方法及びその実施システム並びにその処理プログラム | |
US20070174849A1 (en) | Non-disruptive multipath device driver update system and method | |
US20100293409A1 (en) | Redundant configuration management system and method | |
US20130159344A1 (en) | Dynamically splitting multi-tenant databases | |
US20130073894A1 (en) | Techniques for achieving high availability with multi-tenant storage when a partial fault occurs or when more than two complete faults occur | |
US20080244552A1 (en) | Upgrading services associated with high availability systems | |
US20050050200A1 (en) | Computer system and cluster system program | |
US20090055444A1 (en) | Method and System for High-Availability Database | |
JP2003085005A (ja) | 計算機システム構成自動変更方式 | |
CN112910937B (zh) | 容器集群中的对象调度方法、装置、服务器和容器集群 | |
JP3737810B2 (ja) | 計算機システム及び故障計算機代替制御プログラム | |
US6957254B1 (en) | Method and apparatus for reaching agreement between nodes in a distributed system | |
JPH11282686A (ja) | ネットワークコンピュータシステム | |
JP4363914B2 (ja) | クラスタシステム | |
US20110035748A1 (en) | Data processing method, data processing program, and data processing system | |
JP4163481B2 (ja) | クラスタシステム及び同システムにおけるサービス制御方法 | |
JP2008059599A (ja) | 仮想化されたリソースの割当て方法及びその実施システム | |
JP5056346B2 (ja) | 情報処理装置、情報処理システム、仮想サーバの移動処理の制御方法、及び、プログラム | |
JP4034201B2 (ja) | 計算機資源利用方式及び計算機資源利用方法 | |
JP5647597B2 (ja) | 保守管理システムおよびクライアント端末 | |
US20230367632A1 (en) | Job management system and control method thereof |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050609 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050705 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050905 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060404 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060607 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20060711 |
|
A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20070330 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090416 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090625 |
|
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: 20090818 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120828 Year of fee payment: 3 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 4363914 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: 20120828 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130828 Year of fee payment: 4 |
|
EXPY | Cancellation because of completion of term |