JP4189101B2 - クラスタシステムのシステム構成およびシステム動作の定義装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
この発明は、複数のサーバ計算機（以下「ノード」と記す）をネットワークなどを介して連係動作させるクラスタ技術、特に障害のあったノードの上で動作していた業務ソフトウエア（以下「サービス」と記す）を他のノードが引き継いでシステムの可用性を高めるクラスタＨＡ(High Availability)システムの、応用技術に関する。
【０００２】
【従来の技術】
高可用性計算機システム（以下HA(High Availability)システムと呼ぶ場合もある）においては、他のクライアント計算機に対してサービスを提供する複数のサーバ計算機をネットワークによって連携させ、いずれかのサーバ計算機で障害が発生しても、他のサーバ計算機がサービスを引き継ぐことによりシステム全体としては、サービスの中断を可能な限り短くするように設計される。
【０００３】
このような高可用性システムを実現するときには、サーバ計算機や使用する装置類の数、ソフトウエア構成といった一般のシステムでの設計事項に加え、どのような障害が発生したときに、どのようにサービスを引き継ぐかを決定しなければならない。
【０００４】
従来のＨＡシステムの実現方法の簡単なものは、固定のハードウエア構成と、障害に対する固定的なサービス引継ぎ手順が用意されていて、それを利用するというものである。一般には、種々のシステム形態により柔軟に対応する必要があるために、障害時のサービス引継ぎ手順については、スクリプト言語で記述する方式を採る場合が多かった。
【０００５】
【発明が解決しようとする課題】
従来、クラスタを実現するクラスタソフトウエアとして、固定的なシステム動作を提供する製品と、スクリプトの記述等によりシステム動作をカスタマイズ可能な製品とがあった。前者はクラスタＨＡシステム本来の目的である高信頼性を実現するのが容易ではあるがシステム固有の細かな要求を実現できない問題がある。一方後者は、さまざまな要求に柔軟に対応できるメリットがあるが、その反面、意図したクラスタシステムの動作を正確に実現することが困難だった。ＨＡシステムは信頼性が最も重視されるシステムである。従って設計ミスのために、実際に障害が発生したときに意図していたサービス引継ぎが行われなかったり、新たな誤動作を引き起こしては、ＨＡシステム化の意味がない。
【０００６】
しかし、システムの動作をシステム設計者がその都度、スクリプト言語で記述する従来の技術では、その作成に多くの作業工数を必要とし、なおかつ記述誤りの混入する可能性が高かった。
【０００７】
また、スクリプトによるシステム動作定義は手続き的になされてきた。しかし、システム設計者が意図するのは、システムにある障害が発生したときにサービスをどのノードで実行するかという点である。これを直接的に表現できるシステム動作定義法が求められていた。
【０００８】
また、手続き的に記述するスクリプトでは、一般にシステム状態の変化に対応して各ノードが何をすべきかを定義する。しかし、この方法では、システム設計者はシステム状態の組合わせ、すなわちシステム状態数の２乗のオーダーの場合について考慮しなければならなくなる。
【０００９】
この発明は上記事情に鑑みてなされたもので、スクリプトを用いてシステム動作を実現するクラスタソフトウエアにおいて、システム動作を容易かつ正確に定義することを可能にするクラスタシステムのシステム構成およびシステム動作の定義装置を提供することである。
【００１０】
【課題を解決するための手段】
上記目的を達成するために、この発明のクラスタシステムのシステム構成およびシステム動作の定義装置は、複数のノードを連携動作させ、障害が発生したノードで動作していたサービスを他のノードが引き継ぐクラスタシステムにおいて、少なくともサービス、ノードを含む構成要素の種別と識別名を入力し、入力情報に基づいてシステム構成を定義する情報を保持するシステム構成定義手段と、各場面における各サービスの各ノードにおける実行優先度を入力し、入力情報に基づきシステム全体の動作を定義する情報を保持するシステム動作定義手段であって、前記場面はシステム状態とその状態下での全サービスに関するサービス配置により定義され、前記システム状態は前記システム構成定義手段により入力された構成要素群の状態の組で定義され、各要素の状態の指定は各要素の種別によって与えられる状態値のいずれかまたは無指定であり、前記サービス配置はそのシステム状態下でそのサービスを実行する可能性のあるノードには実行優先度が与えられ、実行する可能性の無いノードには実行なしが与えられる、システム動作定義手段と、前記システム構成定義手段およびシステム動作定義手段により定義された情報をテキストもしくは図表により表現する表現手段とを具備することを特徴とする。
【００１１】
この発明のクラスタシステムのシステム構成およびシステム動作の定義装置によれば、クラスタＨＡシステムのさまざまなシステム動作を、現実的な要求の自由度を保ったままで簡単かつ厳密に定義することができる。
【００１７】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
【００１８】
以下の説明において、各種定義の記述やそれをもとに生成される情報を、「Ｓ式」で表現する。Ｓ式は次の形式を持つ。
【００１９】
Ｓ式 ：：＝リスト｜｜アトム｜｜’Ｓ式
リスト ：：＝（［要素０要素１…］）
要素ｉ ：：＝Ｓ式
リストは０個以上の要素を括弧「（」と「）」とで括ったものである。リストの要素を左から右へ順番に、０番目、１番目、２番目、…、最後の要素、のようにリストの中での並び位置で特定することもある。リストの要素がさらにリストであっても良い。アトムは、空白、改行、括弧、単引用符（’）を含まない文字列である。Ｓ式のリストは可変長の任意型配列や２進木によって容易に計算機プログラムにおける内部データ表現に対応づけられる。アトムは、プログラミング言語の「文字列」型や「整数」型などに対応づけられる。単引用符（’）を伴うＳ式も、固有のデータ構造などにより表現できるだろう。従って、以下で用いるＳ式は、文字どおりのテキストであっても、それに等価な内部データ表現であってもよいものとする。
【００２０】
リストを、関数呼出し式と解釈する場合がある。この場合、０番目の要素が関数名を表し、それ以降の要素が関数への引数を表す。なお、セミコロン（；）を用いてその右側にテキストを付記する場合があるが、これは注釈であり、記述対象のＳ式に含まれるものではない。
【００２１】
図１は、本発明の高可用計算機システム設計支援機能のうちのシステム構成とシステム動作の定義機能を示す概念図である。図１に示す実施形態では、システム構成定義およびシステム動作定義を与えられると、各ノードの動作を展開出力する。この際のシステム構成定義およびシステム動作定義の入力は、例えば図２乃至４に示すようなＧＵＩ環境において入力可能である。
【００２２】
図２は、システムを構成するコンポーネントの定義を入力する画面例を示す。この画面を用いてコンポーネントの種類と数、すなわち例えばサービスの数、ノードの数、ＬＡＮの数、共有ディスク装置（図示例では、ＡＦ１２００として示される）の数などを入力する。
【００２３】
図３はシステム接続構成の定義を入力する画面例を示す。３１、３３、３５はそれぞれ「リソース」、「サービス」及び「ノード」の各名前を入力するフィールドである。又３７はノード＊が装置＊と接続されていることを定義するフィールド（具体的には(connected Node-* *)）を示す。さらに、フィールド３９にサービスとリソースとの相関関係を記載する。例えばフィールド３９の場合は、サービス２が共有ディスクＡＦ１２００を参照（具体的には(refer Service-2 AF1200-1)をすることを定義する。
【００２４】
図４はシステム動作の定義を入力する画面例を示す。４１は定義場面におけるサービス１、２の各ノードにおける実行優先度を入力するフィールドを示す（但し「―――」は実行しないことを表す）。また、４３は場面を選択するボタンを表す。場面は各コンポーネントの状態の組合わせで決定される。上述のようにＧＵＩを介して入力されたシステムの構成の定義、それら構成の接続の定義、および動作の定義をシステム内部でデータとして保持する形態は次の通りである。
【００２５】
システム構成定義１は、例えば次のように定義される。
【００２６】

ここで、一番外側の括弧で囲まれたリスト全体がシステム構成の定義であり、リストの０番目の要素であるキーワードsystemConfigurationが、そのことを表している。systemConfigurationに続く要素がシステム構成要素を表している。各要素リストの０番目の要素(この例では、node, LAN, service等)がシステム構成要素の種別を表すキーワードであり、１番目の要素(この例では、MailServer, AccountServer, AltServer, CommonLan, DiagLan, DK1, MailService, AccountService)がその構成要素の名前である。この定義情報は、ノードが、MailServer, AccountServer, AltServerの３台から構成され、ＬＡＮが、CommonLan, DiagLanの２本から構成され、共有ディスク(sharedDisk)がDK1の１台から構成されるシステム上で、サービスとしてMailService, AccountServiceの２つを実行するシステムの構成定義を表している。このシステム構成の場合、システム動作定義の各場面において、２つのサービスに対する３台のノードの、サービス実行優先度、または「実行なし」を定義する。
【００２７】
システム動作定義２は、複数の場面定義から成り、例えば次のように定義される。
【００２８】

ここで、一番外側のリスト全体がシステム動作の定義であり、リストの０番目の要素のキーワードsystemBehaviorが、そのことを表している。それに続く要素リストの各々が、場面の定義である。各場面定義は、さらに２つの要素リスト（例えばFAULT CommonLanとFAULT DiagLanという要素と、優先順序を表す要素）を持つ。場面定義の０番目の要素はシステム状態を表し、次の形式を持つ。
【００２９】
(and 要素１状態 要素２状態…)
「要素ｋ状態」は、
（状態名ｋ 要素名ｋ）
の形式を持ち、その１番目の要素で表すシステム構成要素が、０番目の要素で表す状態にあることを明示的に表している。このシステム状態において、状態を明示されないシステム構成要素は、「状態指定なし」と見なす。場面定義の１番目の要素は、そのシステム状態における、各サービスの各ノードへの配置の仕方を表し、次の形式を持つ。
【００３０】
（サービス１配置 サービス２配置…）
「サービスｉ配置」は、
（優先度ｉ１ 優先度ｉ２…）
の形式を持つ。優先度ｉｊはそのサービス（サービスｉ）の、対応するノード（ノードｊ）への配置法を表し、その値は、「実行優先度」または「実行なし」のいずれかである。「実行優先度」は、優先度の高いものから順に、１、２、…の通し番号で表すものとする。また、「実行なし」は、「…」で表す。
【００３１】
システム動作展開手段３は、システム動作定義２から各ノードの動作定義を生成する手段であり、システム動作定義２の展開処理を行ない、結果を格納手段４に格納する。
【００３２】
システム動作展開手段３は次の形式を持つ。
【００３３】

サービスｉ実行動作は、サービスｉに関するノード群の実行動作を表し、次の形式を持つ。
【００３４】

サービスｉｊ実行動作は、サービスｉに関するノードｊの実行動作を表し、次の形式を持つ。
【００３５】

システム動作展開手段による展開処理は、次のように行う。
【００３６】
（１）場面定義群を、優先度の高いものが後になるように並べ替える。この際、優先度は次のように決定する。
【００３７】
（イ）明示条件数の多い場面ほど、優先度が高い。
【００３８】
（ロ）明示条件数が同じ場合、もとの並び順で後にあるものほど、優先度が高い。
【００３９】
（２）システム動作展開結果格納手段４の、各サービスの各ノードにおける展開された動作を、暗黙では(ユーザにより定義されていなければ)、「サービス実行なし」に設定する。これを次のＳ式で表す。
【００４０】
(cond
(t 'stop)
前述のシステム動作定義によれば、システム全体では、次のようになる。
【００４１】

（３）ソートした場面群の先頭（最も優先度の低いもの）から、各場面について以下を繰り返す。この例では、場面１については、MailServerとAccountServerとAltServerの実行優先度が定義され、場面２以降にさらに詳細な定義がされる。例えば、どのサーバが故障したときに、どのサーバを動かすかという動作定義が成される。場面数が後になればなる程詳細な条件設定が成される。
【００４２】
（３．１）場面内の各サービスについて、以下を繰り返す。
【００４３】
（３．１．１）サービスの配置法の中で、実行優先度を割り当てられたものについて以下を繰り返す。
【００４４】
（３．１．１．１）場面の明示条件に自ノードでの実行可能性を追加したものを条件とし、そのノードにおいて何もしないことを動作とするリスト
((and<明示条件＞(executableサービス名自ノード名))
,NOP)
をサービス実行動作の先頭に加える。
【００４５】
上述のリストは、サービス名 自ノード名が実行可能であり、明示条件が満足するなら、何もしないということを意味する。リストを上から順番に見ていき、先に該当したものがあればそれが実行される。また、上記NOPの意味は、例えば、ノード１が実行優先順位１でノード３が実行優先順位２のときに、ノード１が故障したとする。この場合、ノード３がノード１に代わり実行するが、ノード３が実行中にノード１が回復した場合にどうするかという問題が生じる。この場合には、NOPの定義がされていると、例えノード１が回復しても、ノード１に切り替えずに引き続きノード３が続行することを意味する。
【００４６】
ここで言う実行可能性とは、例えば、図１に示す場面１のサービス１の定義において、MailServerで実行できる限りはMailServerで実行することを意味する。そしてもし実行できなかったらAltServerで実行することを意味する。サービス１においてMailServerで実行できたならば、次にサービス１でMailServerが実行可能であるとはどういうことかをシステムで定義する。すなわち、あるサービスをあるノードで実行可能であるとはどういうことかを定義する。明示的に、例えば"fault"等の条件がユーザにより与えられていなかった場合には、システムは明示されていないものの取り得る状態を全部調べそれぞれについて実行可能か否かの判断を行ない、実行できる場合には、そのノードで実行する。例えばサービス１において、共有ディスクをノード２が使っていたとする。そして、実行可能性の条件として、使用している共有装置がすべて正常であることを条件としていた場合には、ノード１が故障していた場合は、ノード１はサービス１を実行できないとシステムは判断する。
【００４７】
（３．１．１．２）場面の明示条件に高優先ノードでの実行不能性と自ノードでの実行可能性を追加したものを条件とし、そのノードにおけるサービスを開始することを動作とするリスト
((and<明示条件＞

をサービス実行動作の先頭に加える。
【００４８】
すなわち、このリストでは、例えば、ノード３で実行可能であるがノード１で実行可能でないときに、ノード３で実行することを記載している。なお、上記"null"は"NOT"の意味である。
【００４９】
（３．１．２）サービス配置法の中で、「実行なし」を割り当てられたものについて以下を繰り返す。
【００５０】
（３．１．２．１）場面の明示条件を条件とし、そのノードにおけるサービス停止を動作とするリスト
((and<明示条件＞)
, stop)
をサービス実行動作の先頭に加える。
【００５１】
前述のシステム動作定義から展開される動作定義の全体は、次のようになる。
【００５２】

上述した展開において、上から順番に見ていきどれかの条件に該当すれば、その条件が実行される。例えば最初の条件は、MailServerが故障でかつAltServerが故障のときは停止するという条件であるが、この条件が満足された場合、システムはその段階で停止する。
【００５３】
なお、システム動作が定義通りに実現できたならば、ある時点においてあるサービスを実行しているノードが高々１台であることが次のようにして確認できる。
【００５４】
システムの初期状態では、いずれのサービスも実行されていない。
【００５５】
あるシステム状態において、サービスｉの開始（start）を算出する場面があるとき、それらの場面の中で最も優先度の高いものを場面ｍと仮定する
サービスを実行する可能性のあるノードはその場面の中で重複でなく優先度を割り当てられているので、その場面定義からサービス開始を算出されるノードは１つに特定される。これをノードjとする。
【００５６】
サービス開始を算出されるための条件は、他の動作（NOP,stop）を算出される条件より厳しいので、ノードj以外のノード動作は、場面ｍか、それよりも優先度の高い場面から算出される。
【００５７】
上記仮定より、場面ｍよりも優先度の高い場面によって動作を算出されたノードの動作がstartであることはない。（startを算出されるノードは高々１台である。）
startの定義から、ノードjはサービスiを実行しているノードが存在しないときだけ、実際にサービスiを実行開始する。
【００５８】
以上より、サービスiを実行しているノードは常に高々１台である。
【００５９】
図５はこの発明の他の実施形態を示す。
【００６０】
この実施形態においては、ユーザが設定した定義が、ユーザが意図したものと一致するか否かを確認するためのシステム動作のシミュレーションが記載される。
【００６１】
システム状態設定部１１は、検証員の指示により、または乱数などの自動的な方法により、システム状態格納部１２にシステム状態を設定する。システム状態格納部１２は、各システム構成要素の現在の状態設定値を保持する。構成要素の状態値として設定可能な値（すなわち、図６におシステム構成要素情報２３ａで挙げられている装置の取り得る状態）は、システム構成要素状態情報１３ｂにより規定される。
【００６２】
ノード動作算出部１４は、システム状態格納部１２の設定が完了すると、その状態に基づき各ノードが各サービスに対してとる動作を算出し、これを算出結果格納部１６に格納する。動作の算出は、システム固有の関数定義１３ｄを用いてシステム動作展開結果１５に従って行う。システム固有関数定義１３ｄは、システム構成要素の各々について現在の状態を判定する関数と、サービスの実行可能性を判定する関数を含む。この例では、いずれの構成要素も、状態値としてNORMALまたはFAULTのいずれかをとり次の関数呼出しによって状態の判定が可能であるとする。
【００６３】
（NORMAL構成要素名） ：指定の要素がNORMAL状態であるか否か（論理値）
(FAULT構成要素名) ：指定の要素がFAULT状態であるか否か（論理値）
また、サービスのあるノードにおける実行可能性は、いずれも次の関数呼出しで判定できるものとする。
【００６４】
(executableサービス名 ノード名)
：サービスをそのノードで実行するのに必要な条件が満たされている。
【００６５】
上記executableの関数を実行すると、実行可能か否かの結果が出力される。
【００６６】
一般にこれらのシステム固有の関数は、システム構成定義１３ａを参照する。システム構成定義１３ａは、図１のシステム構成定義１で与えられたものと同じ情報を含む。但し、システム構成要素間の関係に依存したシステム動作をシミュレーションするために、システム構成定義において、要素間の関係も定義する必要がある。ここでは、構成要素間の「接続」関係と、サービスから資源要素への「参照」関係を、構成要素の定義の中でそれぞれconnectionとreferのキーワードで定義するものとする。
【００６７】
(connected 構成要素１ 構成要素２…)
：定義中の構成要素が、リストの要素の構成要素と「接続」の関係にある。これは対称な関係であり、一方から接続関係が定義されれば、逆向きにも接続関係が成立する。
【００６８】
(refer構成要素１ 構成要素２…)
：定義中のサービスが、リストの要素の構成要素を「参照」する関係にある。
【００６９】
例えば、システム構成定義は次のように与えられる。
【００７０】

システム動作展開結果１５は図１のシステム動作展開結果４に相当する。
【００７１】
ノード動作算出部１４は、以下の関数を固定的に定義されているものとする。
【００７２】
(and関数呼出し１関数呼出し２…)
：引数の関数呼出しはいずれも論理値をとる。
【００７３】
それらのすべてが真なら、この関数呼出し自体も真。そうでなければ偽。引数の関数呼出しは０個でもよく、その場合は真。
【００７４】
(null 関数呼出し)
：引数の関数呼出しが真なら関数呼出し自体は偽。そうでなければ真。
【００７５】
(cond 節１節２…) ：節は、（関数呼出し’値）または（t’値）の形をとる。先頭の節から順番に０番目の要素を調べ、それがｔであるか、または（それ以外は論理値を取る関数呼出し）関数呼出しの結果が真であるならば、その節の１番目の要素の’を除いた値が、この関数呼出し辞退の値となる。いずれの節の０番目の要素もｔでもなく値が真となる関数呼出しでなければ、この呼出しの値は偽となる。
【００７６】
以上の関数は、展開されたシステム動作から、システム状態に応じたノードの動作を算出する場合に使用する。この他、サービスの実行可能性をシステム固有にできるようにするために、以下の関数を備える。
【００７７】
(or関数呼出し１関数呼出し２…)
：引数の関数呼出しはいずれも論理値をとる。
【００７８】
それらのいずれかが真なら、この関数呼出し自体も真。そうでなけらば偽。引数の関数呼出しは０個でもよく、その場合は偽。
【００７９】
(eq 値１値２) ：値１と値２が等しければ、真、そうでなければ偽。
【００８０】
(connected 要素１要素２)：要素１と要素２との間に接続関係が定義されていれば真、そうでなければ偽。
【００８１】
(referサービス要素) ：サービスと要素との間に参照関係が定義されていれば真、そうでなければ偽。
(list要素１要素２…) ：引数要素の値を要素とするリスト。
【００８２】
(forEveryパターン有効化条件式)
(forSomeパターン有効化条件式)
(makeListパターン有効化条件式)
：これらの関数はシステム構成定義との間でパターンマッチングを行ない、マッチしたパターンのうち有効化条件が真となるものについてのみ、最後の要素の式を用いて何らかの処理を行う共通の構造を持つ。
【００８３】
パターンは（（要素種１変数１）（要素種２変数２）…の形式を持ち、要素種に該当するシステム構成要素を対応づけて得られる全ての組合わせについて、対応づけられた要素を変数の値として設定し、その設定下で有効化条件の判定と式の処理を試みる。
【００８４】
forEveryは有効化条件が真のときには、式が常に真になるならば読み出し結果が真、そうでなければ偽となる。forSomeは、有効化条件が真となるパターンのうち少なくとも１つにおいて式が真になれば呼出し結果が真、そうでなければ偽となる。
【００８５】
makeListは、有効化条件が真となるときの式の値を要素とするリストを値とする。
【００８６】
サービスｉの実行可能性は、例えば「すべての参照要素がNORMALであること」とするなら次のように定義される。
【００８７】
(forEvery ((component$r)) (referサービスi$r)(NORMAL$r))
上述の定義では、サービスｉが参照しているすべてのコンポーネントがノーマルであれば、サービスｉが実行可能であると定義している。
【００８８】
ただしここで、componentは任意のシステム構成要素を表す要素種である。これらの関数を用いて、システム動作展開結果１５の各サービス、各ノードに対応した要素を関数呼出しとして評価すると、各ノードの各サービスに対する動作が算出されるので、これをノード動作算出結果格納部１６に格納する。サービス実行状態算出部１７は、算出されたノード動作の算出結果に基づき新しいサービスの実行状態をサービス実行状態格納部１８に設定する。サービス実行状態格納部１８は、各サービスについて、実行中であればそれを実行しているノード名を、また、実行中でなければnilを保持する。動作start, stop, NOPの意味から、実際にサービス実行状態格納部１８に設定される値は、以前のサービス実行状態格納部１８の値にも依存し、次のようになる。
【００８９】
ノードjのサービスiに対する動作がstartの場合：
サービスiが以前にいずれのノードにおいても実行状態でなければ、サービスiはノードjで実行状態とする。（実行状態に、ノードjを設定する）
ノードjのサービスiに対する動作がstopの場合：
サービスiはノードｊで停止状態とする。（実行状態をnilにする）
ノードjのサービスiに対する動作が、NOPの場合。
【００９０】
サービスiのノードjでの実行状態を変更しない。
【００９１】
サービス状態表示部１９は、システム状態の変更毎に、その結果のサービス実行状態を、検証員に対して表示する。
【００９２】
次に、この発明のさらに他の実施形態について説明する。
【００９３】
図６は、システム動作の実現可能性の実現例を示している。
【００９４】
図６において、システム状態設定部２１は、システムがとり得る全ての状態を、順次システム状態格納部２２に設定する。システム状態格納部２２は、各システム構成要素の現在の設定値を保持する。システム状態格納部２２、システム構成定義２３、ノード動作算出部２４、システム動作展開結果２５、およびノード動作算出結果格納部２６は、それぞれ図５に示すシステム状態格納部１２、システム構成定義１３、ノード動作算出部１４、システム動作展開結果１５、およびノード動作算出結果格納部１６に対応する。但し、システム構成関数定義２３ｄはシステム状態値算出部２７のために、システム固有の関数定義として、各ノートにおいて、クラスタソフトウエアが検出する状態値を算出する関数と、各ノード上で動作するクラスタソフトウエアが情報を共有できる可能性を判定する関数を新たに必要とする。検出状態値算出部２７は、これらの関数と、システム寿応対格納部２２のシステム状態、およびシステムに依存しない関数定義２８ａを用いて、各ノード上で動作するクラスタソフトウエアが直接的または間接的に検出することのできる状態値を算出し検出状態値格納部２８に格納する。検出状態値格納部２８の固有算出部２８ａは、ノード動作算出部２４の固有関数定義２４ａと共通の内容を持ち、その実体は１つであってもかまわないノードｊが検出する状態値を算出する関数の定義式は、例えば次のように与えることができる。
【００９５】

この関数は、検出状態としてLANを介して接続された各ノードとの診断交信（一般に、「ハートビート」と呼ばれる）の状態のみを得ることを定義しており、LANとノードの組合わせそれぞれについて、次の形式の状態名−状態値リストを要素に持つリストを生成する。
【００９６】
((HeartBeatノードj $lan $n2)状態値)
ここで、$lan, $n2には、実際のLANおよびノードの名前が入る。また、状態値はそのLANと相手ノードのいずれもが正常ならOK、そうでなければNGとなる。ノードjがノードkの情報を共有できる可能性の判定関数の定義式は、例えば次のように与えることができる。
【００９７】

検出状態値算出部２７は、各ノードが直接的に検出する状態値を検出状態値算出関数によって算出した後、情報共有可能性判定関数（ハートビート）によって情報の共有（参照）が可能であるとされたノード群すべての検出状態値を併合することにより、各ノードが直接的又は間接的に知ることのできるすべての検出状態値を求め、検出状態値格納部２８に格納する。
【００９８】
本発明における「検証」とは、与えられたシステム動作を、クラスタソフトウエアが実現できるか否かを調べることである。これは次のように行われる。
【００９９】
まず、システム設計者により与えられたシステム動作定義は、システム状態に対して各ノードが行うべき動作を算出する一種の関数と考えられる（図７のＦｅｃ）。これを実現するためには、クラスタソフトウエアは、検出可能な状態値にもとづき目的の動作を実現するスクリプトを与えられなければならない。このスクリプトも一種の関数を実現していると考えられる（図７のＦｅｄ）。図７に示すＦｅｃが図６のノード動作算出部２４に対応し、図７に示すＤが図６の検出状態値算出部２７に対応する。システム状態に対して検出状態値を得る過程も関数と見なせる（図７のＦｄｃ）ので、システム動作の実現可能性は、形式的には
Ｆｅｃ≡Ｆｅｄ・Ｆｄｃ
となるＦｅｄが定義可能なことと表現できる。
【０１００】
スクリプトの記述力が十分であると仮定すると、求められるのはＦｄｃを経てもシステム状態Ｃの情報が十分に保持されていることであり、システム動作の実現可能性は次のように換言できる。
【０１０１】
「全てのシステム状態について、あるノードに求められる動作がＦｅｃによって異なって算出されるなら、Ｆｄｃによって算出されるそのノードの検出状態値も異ならなければならない」
いま、Ｆｄｃの出力相当の値がノード動作算出結果格納部２６に格納され、Ｆｄｃの出力相当の値が算出検出状態値格納部２８に格納されているとする。この情報を用いて、検出部２９は次のように検証処理を行う。
【０１０２】
(1)サービス、ノード、および動作の、３次元の分類テーブルを検出状態値分類格納部３０に用意しそのすべての要素を空きリストに初期化する。
【０１０３】
(2)すべてのシステムの状態について算出されるノード動作算出結果格納部２６、算出検出状態値格納部２８毎に以下の処理を行う。
【０１０４】
(2.1)すべてのサービスについて以下を繰り返す。
(2.1.1)すべてのノードについて以下を繰り返す。
【０１０５】
(2.1.1.1)ノード動作算出結果格納部２６から、該サービス、該ノードの動作を取り出す（ａとする）。
【０１０６】
(2.1.1.2)検出状態値分類格納部３０の該ノードの検出状態値を取り出す（ｄとする）
(2.1.1.2)すべての動作について以下を繰り返す。
【０１０７】
(2.1.1.2.1)ａと異なる動作については、
(2.1.1.2.1.1)検出状態値分類格納部３０の該サービス、該ノード、該動作の要素リストにｄと一致するものがすでに登録されているなら、「動作実現不能」のエラーを検証員に通知する。
【０１０８】
(2.1.1.2.2)ａと同じ動作については、
(2.1.1.2.2.1)検出状態値分類格納部３０の該サービス、該ノード、該動作の要素リストにｄと一致するものがすでに登録されているなら、何もしない。
【０１０９】
(2.1.1.2.2.2)検出状態値分類格納部３０の該サービス、該ノード、該動作の要素リストにｄと一致するものがすでに登録されていないなら、ｄを該サービス、該ノード、該動作の要素リストに追加する。
【０１１０】
図８は、「検証」の画面例を示す図である。図８において、「VRIFY」ボタンを押すと、５３に示すように問題の個所を示テキストが表示される。さらに、所望のテキストを参照して「SHOW」ボタン５５を押すと、詳細情報（すなわち、その問題の状況）が表示される。System Configurationのウインドウの「File」メニューで「quit」を選択すると「検証」の動作が終了する。
【０１１１】
なお、図１で説明したシステム構成定義および動作定義およびライブラリを合わせて図５で示したシステム動作のシミュレーションや図６で示したシステム動作実現可能性の検証が可能であることを説明したが、それ以外に実際にスクリプトに変換するためのコンパイラを作成することも可能である。
【０１１２】
【発明の効果】
この発明によれば、クラスタＨＡシステムのさまざまなシステム動作を、現実的な要求の自由度を保ったままで簡単かつ厳密に定義できる。すなわち、システムにある障害が発生したときにサービスをどのノードで実行するかを直接的に表現できる。
【０１１３】
また、本発明によれば、実現したいシステム動作をシステム状態ベースで定義でき、問題の複雑さをみかけ上、システム状態数のオーダーに縮退できる。
【０１１４】
また、システム構成要素の状態を明示的に与えられないシステム状態については、サービスの「実行可能性」によりノードの動作が判断される。これによって、システム設計者がすべてのシステム状態を逐一考慮するわずらわしさを回避できるとともに、非明示状態は可能な限りサービスを実行する方向に解釈されるためシステムの可用性を最大限に高くできる。
【図面の簡単な説明】
【図１】本発明の高可用計算機システム設計支援装置の一実施形態を示すブロック図。
【図２】システムを構成するコンポーネントの定義を入力する画面例を示す図。
【図３】システム接続構成の定義を入力する画面例を示す図。
【図４】システム動作を定義する入力画面例を示す図。
【図５】本発明の他の実施形態を示すブロック図。
【図６】本発明のさらに、他の実施形態を示すブロック図。
【図７】図６に示す実施形態において、「検証」を説明するための説明図。
【図８】図６に示す実施形態において、設計を検証をした結果を示す画面例を示す図。
【符号の説明】
１…システム構成定義
２…システム動作定義
３…システム動作展開手段
４…システム動作展開結果格納部
１１…システム状態設定部
１２…システム状態格納部
１３…システム構成定義
１４…ノード動作算出部
１５…システム動作展開結果
１６…ノード動作算出結果格納部
１７…サービス状態算出部
１８…サービス実行状態格納部
１９…サービス状態表示部
２１…システム状態設定部
２２…システム状態格納部
２３…システム構成定義
２４…ノード動作算出部
２５…システム動作展開結果
２６…ノード動作算出結果格納部
２７…検出状態値算出部
２８…算出検出状態値格納部
２９…検出部
３０…検出状態値分類格納部

Claims (5)

1. 複数のノードを連携動作させ、障害が発生したノードで動作していたサービスを他のノードが引き継ぐクラスタシステムにおいて、
   少なくともサービス、ノードを含む構成要素の種別と識別名を入力し、入力情報に基づいてシステム構成を定義する情報を保持するシステム構成定義手段と、
   各場面における各サービスの各ノードにおける実行優先度を入力し、入力情報に基づきシステム全体の動作を定義する情報を保持するシステム動作定義手段であって、前記場面はシステム状態とその状態下での全サービスに関するサービス配置により定義され、前記システム状態は前記システム構成定義手段により入力された構成要素群の状態の組で定義され、各要素の状態の指定は各要素の種別によって与えられる状態値のいずれかまたは無指定であり、前記サービス配置はそのシステム状態下でそのサービスを実行する可能性のあるノードには実行優先度が与えられ、実行する可能性の無いノードには実行なしが与えられる、システム動作定義手段と、
   前記システム構成定義手段およびシステム動作定義手段により定義された情報をテキストもしくは図表により表現する表現手段とを具備することを特徴とするクラスタシステムのシステム構成およびシステム動作の定義装置。
2. 前記システム動作定義手段は、各ノードが各サービスに関してとるべき動作とその判定条件を設定する際に、優先度を割り当てられたノードについて、動作の決定条件と動作を、場面のシステム状態が成立し、かつ自ノードよりも高い優先度を持つノードにおいて該サービスを実行可能でなく、かつ自ノードにおいて該サービスを実行可能なら該サービスに対する動作を”ｓｔａｒｔ”とし、場面のシステム状態が成立しかつ自ノードよりも高い優先度を持つノードにおいて該サービスを実行可能であるなら該サービスに対する動作を”ＮＯＰ”とし、その場面において「実行なし」とされたノードは、動作の決定条件と動作を、場面のシステム状態が成立するとき、該サービスに対する動作を”ｓｔｏｐ”とし、前記”ｓｔａｒｔ”は該サービスをいずれかのノードにおいても実行していないなら、その実行の開始を意味し、前記”ｓｔｏｐ”は該サービスを自ノードで実行中ならそのサービスを停止させ、実行中でなければ何もしないことを意味し、前記”ＮＯＰ”は該サービスについて何もしないことを意味する、第１システム動作定義手段と、
   場面における入力情報から各ノードの各サービスに関する動作とその動作条件への展開を各場面について行うと共に、場面毎の定義情報に優先順位を設け、あるノードの動作決定条件が複数個成立するときには、優先度の高い場面の定義情報にもとづいて動作を決定する第２システム動作定義手段とから構成されることを特徴とする請求項１記載のクラスタシステムのシステム構成およびシステム動作の定義装置。
3. システムの構成要素間の関係を入力し、入力情報に基づいてシステム接続構成を定義する情報を保持するシステム構成要素間定義手段と、
   想定したシステム状態の、個々のシステム要素の状態を保持する第１の保持手段と、
   想定したシステム状態において、個々のシステム要素がいずれの状態にあるか判定する第１の判定手段と、
   各サービスが実行中であるかないかを示す情報と、実行中である場合にいずれのノードで実行しているかを示す情報と、サービスの実行状態とを保持する第２の保持手段と、
   任意の与えられたシステム状態に対して、前記システム構成要素間の関係を用いて、各サービスがあるノードにおいて実行可能であるか否かを判定する第２の判定手段とを具備し、具体的なシステム状態を想定し、それに対して、各ノードの動作を算出することを特徴とする請求項１記載のクラスタシステムのシステム構成およびシステム動作の定義装置。
4. 想定したシステム状態における、各システムの構成要素の状態を設定するためのシステム状態設定手段と、
   想定したシステム状態における、各ノードの動作を、前記システム動作定義手段と、前記第１の判定手段、および第２の判定手段に基づいて算出する算出手段と、
   前記算出手段により算出された各サービスに対する各ノードの動作から、前記定義した動作の意味に基づき各サービスの実行状態を保持する第３の保持手段と、
   前記第３の保持手段に保持されたサービスの実行状態を出力する出力手段とをさらに有したことを特徴とする請求項３記載のクラスタシステムのシステム構成およびシステム動作の定義装置。
5. 各ノード上で動作するクラスタソフトウエアが与えられたシステム状態において検出する状態値を定義するための状態値定義手段と、
   各ノード上で動作するクラスタソフトウエアが、他のノード上で動作するクラスタソフウエアと検出した状態値の情報を共有することが、与えられたシステム状態において可能か否かの判定法を定義するための判定法定義手段と、
   システムがとりうるあらゆるシステム状態において、前記システムの動作定義によりあるノードがあるサービスに関して異なる動作をとることが求められているならば、そのノードが前記状態値定義手段および判定法定義手段により直接的または間接的に検出する状態値が異なるか否かを検証する検証手段をさらに有したことを特徴とする請求項１記載のクラスタシステムのシステム構成およびシステム動作の定義装置。

Images