(57)【要約】【課題】信頼性の高いクラスタシステムを提供する。【解決手段】複数のノードで構成されるクラスタを複数設け、一定時間毎に行なわれるチェックポイントの時、またはジョブの終了時に各クラスタからの実行結果の多数決をとる。【選択図】　　　図３
2004046356.tif 000002
【特許請求の範囲】
【請求項１】
複数のクラスタであって、各クラスタは複数のノードからなり、各クラスタの複数のノードはアプリケーションプログラムの処理を分担して並列に実行するものと、
該複数のクラスタからの複数の実行結果の中から、最も多くのクラスタからの実行結果を前記アプリケーションプログラムの実行結果として採用する多数決手段とを具備する高信頼性クラスタシステム。
【請求項２】
前記多数決手段は、すべてのクラスタにおいてアプリケーションプログラムの処理が終了した後において前記多数決の判断を行なう請求項１記載のシステム。
【請求項３】
前記多数決手段は、すべてのクラスタにおいてチェックポイントの処理を行った後において前記多数決の判断を行なう請求項１記載のシステム。
【請求項４】
各クラスタの各ノードについて、同期待ち状態にあるノードの実行結果を記憶する記憶領域をさらに具備し、
前記多数決手段は、それぞれのクラスタにおいて同じ処理を担当するノードについて同期待ちとなって実行結果が書き込まれた後において多数決の判断を行なう請求項１記載のシステム。
【請求項５】
複数のコンピュータに請求項１〜４のいずれか１項記載のシステムを実現させるプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、クラスタシステムの高信頼性化に関する。
【０００２】
【従来の技術】
クラスタシステムは複数の計算機（ノード）に同一作業目的の処理を分担させ並列に実行させることで単体では限界であった処理能力や信頼性を向上させるシステムである。複数のノードを一つのクラスタとして動作させるためのソフトウェアがクラスタシステムソフトウェアである。
【０００３】
【発明が解決しようとする課題】
一般にクラスタシステムは安価なＰＣを組合わせることによって構成される事が多い。通常ＰＣはコモディティ製品の集合体であり、汎用機などに比べるとその信頼性が乏しいという問題点があった。
【０００４】
そこで本発明はユーザが投入したジョブを多重化し、多数決によって最も多くのクラスタが出した答えを正解とするような高信頼性クラスタ装置を提供することを目的とする。また本発明によって多くのノードを有効に利用して信頼性を高めることができる。また他のクラスタが計算した結果と比較することによって障害が発生しているノードを特定することが可能となる。
【０００５】
【課題を解決するための手段】
本発明の高信頼性クラスタ装置は、複数のクラスタであって、各クラスタは複数のノードからなり、各クラスタの複数のノードはアプリケーションプログラムの処理を分担して並列に実行するものと、該複数のクラスタからの複数の実行結果の中から、最も多くのクラスタからの実行結果を前記アプリケーションプログラムの実行結果として採用する多数決手段とを具備することを特徴とするものである。
【０００６】
【発明の実施の形態】
以下、本発明をクラスタシステムソフトウェアの１つであるＳＣｏｒｅによって実現されるクラスタシステムに適用した例について説明する。
【０００７】
ＳＣｏｒｅはＲＷＣＰ（新情報開発機構）が開発したＨＰＣ型のクラスタシステムソフトウェアである。図１にＳＣｏｒｅのソフトウェアアーキテクチャを示す。
【０００８】
図中のＳＣｏｒｅ−Ｄはユーザの並列ジョブに対してＣＰＵを割り当ててスケジューリングを行うジョブスケジューラである。ユーザがジョブを投入すると、そのジョブが必要とする資源によってクラスタを割り当てる。ユーザの資源要求を満たすようなクラスタが複数見つかった場合には、より負荷の軽いクラスタが割り当てられる。負荷が等しい複数のクラスタがあった場合には、よりＣＰＵの速いクラスタを割り当てるような機能を持っている。
【０００９】
ＳＣｏｒｅ−Ｄでは複数のユーザが同時にジョブを投入できるマルチユーザ環境をサポートしている。マルチユーザ環境では時分割によってスケジューリングするギャングスケジューリングモードと、１つのジョブがスケジュールされるとそれが終了するまで他のジョブはスケジューリングされない排他スケジューリングモードを選択することができる。
【００１０】
ユーザジョブの実行が終了すると、ＳＣｏｒｅ−Ｄは割り当てたノードの解放などの後処理を行ってユーザに結果を返す。
【００１１】
図２にＳＣｏｒｅ上で動作する並列ジョブの処理の流れを示す。図はマルチユーザ環境を示している。
【００１２】
ｓｃｏｕｔは並列リモートシェル実行環境で、オプション“−ｇ”でリモートシェル環境を構成するノードを指定する。ｓｃｏｕｔの標準入力がターミナルである場合にはｓｃｏｕｔはシェルプロセスを起動する。このシェルの中でＳＣｏｒｅ−Ｄを起動すると、ＳＣｏｒｅ−Ｄはｓｃｒｕｎによるユーザからのジョブの到着を待つ。ユーザジョブを投入すると、そのユーザが正規のユーザであるかどうかの認証処理を行う。認証に成功するとノード数などの必要なリソースを確保してジョブを実行する。認証後はｓｃｒｕｎはユーザジョブをコントロールするためのフロントエンドプロセスとして動作する。ＳＣｏｒｅ−Ｄはユーザジョブが終了すると割り当てられたノードの解放等の後処理を行って次のユーザジョブの到着を待つ。
【００１３】
同じ処理を複数のクラスタで同時に行い、その結果から多数決によって勝者を決定する。過半数をとった方をシステムの最終結果とする。これはトリプル・モジュラー・リダンダンシー（ＴＭＲ）またはＮ−モジュラー・リダンダンシー（ＮＭＲ）と呼ばれるアーキテクチャで、フォルトトレランスを実現する方法の一つである。本発明ではＮＭＲをクラスタシステム上で実現する。
【００１４】
多数決を行うために各クラスタが出した計算結果を比較する必要がある。このタイミングとして図３に示すように以下の２通りの方式が考えられる。
【００１５】
・ジョブの終了時に最終結果を比較する。
【００１６】
・一定時間周期で行なわれるチェックポイントの時に中間結果を比較する。
【００１７】
ジョブの終了時に比較を行う場合は、全てのクラスタでジョブが終了した時点で計算結果の比較を行う。
【００１８】
チェックポイントはＳＣｏｒｅ−Ｄが持っている機能で、一定時間毎にジョブの途中経過をハードディスクに書き出すことである。ジョブの実行が何らかの理由で途中で失敗した場合には、前回のチェックポイントから実行を継続することができる。これをチェックポイント／リスタート機能と呼ぶ。チェックポイントを行った後で処理の途中経過を比較することによって、多数決に敗れたものは勝者のチェックポイントをコピーすることによって多数決処理を継続することができる。また多数決に敗れた場合にはハード／ソフト的に何らかの障害が発生していると考えれば、多数決処理から除外することもできる。
【００１９】
ＳＣｏｒｅ−Ｄのチェックポイント機能では一定時間毎にチェックポイントをとるために、それぞれのクラスタで同じ処理を担当するノード間で処理の進み具合いに偏りが生じる可能性があり、正確な比較処理ができなくなってしまうことがある。そこで図４に示したように各クラスタで同期をとった後にチェックポイントを行なうことによって処理の偏りを無くして比較を行うことができる。
【００２０】
例えば繰り返し演算を行っている場合には繰り返し回数を等しくする必要がある。また繰り返し演算の中でも比較できるポイントはアプリケーション毎に異なる。そこで、一定時間毎に比較するのでなく、途中経過を比較できる場所をアプリケーション側で指定することにより、この問題を解決することができる。同期ポイントの指定には以下の関数を呼び出すことによって行う。
【００２１】
ｖｏｉｄ　ＭＪ　ＳｙｎｃＰｏｉｎｔ　（ｖｏｉｄ　＊ｄａｔａ，　ｉｎｔ　ｃｏｕｎｔｍａｘ）｛
全てのクラスタの同期待ち；
チェックポイント；
比較→勝者／敗者を決定する
｝
この関数の引数の中で“ｄａｔａ”は比較対象データを示す。このように同期ポイントとチェックポイントの指定をアプリケーション側で行わせることによって、途中経過を正確に比較することができる。
【００２２】
ループ処理の中で上記の同期関数が呼ばれる度にチェックポイントおよび比較を行うと、性能が極端に低下してしまうことが考えられる。そこで、同期関数の中では引数“ｃｏｕｎｔｍａｘ”で指定された回数だけ呼ばれる毎にクラスタ間の同期を行って、チェックポイントをとることとする。
【００２３】
各クラスタ間で同期を行うかわりに、同じ処理を担当するノード同士で同期を行う事によって不要な同期待ちを省いて性能が低下するのを抑えることができる。このためには図５に示したような全ノードで共通にアクセスできる比較テーブルを用意する。各ノードでは同期関数が呼び出されると、自分のクラスタＩＤとノードＩＤに対応するエントリに途中経過を書き込む。全てのクラスタのエントリ（図５に示した例ではクラスタ０〜２のノード１のエントリ）が書き込まれると、ノード毎に比較を行う。比較にはジョブを実行しているスレッドとは別スレッドで行う。こうすることで途中経過を書き込んだノードは同期待ちすること無く、処理を継続することができる。多数決に敗れたクラスタには処理の停止を通知する。比較データが配列の場合には比較テーブルのエントリも配列として確保しなければならない。
【００２４】
計算結果／途中経過を比較するためには以下のアルゴリズムが考えられる。
【００２５】
・リーグ戦方式
図６に示すように、全てのクラスタからのデータを総当たりで比較する。その結果、図６に示した例では、クラスタ２からのデータは他のクラスタのいずれとも一致しないので、クラスタ２からのデータが異常であることが判明する。
【００２６】
・トーナメント方式
図７に示すように、隣接する２つのクラスタ間で比較を行って、等しかった場合には等しかったもの同士を比較する。さらに隣のクラスタで等しかったもの同士と比較を行う。異なっていた場合は、両者を隣のクラスタで等しかったものと比較する。異なった答えを出すクラスタが少ないと仮定すれば、トーナメント方式によって比較回数を減らすことができる。
【００２７】
多重化したジョブの実行において多数決に敗れたクラスタは、勝者のチェックポイントから処理を続行することができる。しかしながら、このようなクラスタは再び多数決に敗れる可能性が高いと考えられる。これは、このようなクラスタを構成するノードがソフト／ハード的に何らかの異常があるものと考えることができるためである。異常ノードが含まれるクラスタは直ちにユーザに報告されなければならない。またログに書き出しておくことによって後のメンテナンス作業を容易にすることができる。
【００２８】
異なるノード構成のクラスタで複数回の多数決法を行うことによって、どのノードが異常であるかを検出することができる。すなわち多数決に敗れたクラスタ間で共通するノードが異常ノードであると考えられる。
【００２９】
【実施例】
ＳＣｏｒｅ−Ｄはユーザジョブが到着してユーザ認証に成功すると、ｃｒｅａｔｅＪｏｂ（　）関数を呼び出してジョブを生成する。生成されたジョブはａｄｄ　ｊｏｂ（　）関数によってスケジューラに登録されて実行される。ここで、ユーザが指定した多重化数だけｃｒｅａｔｅＪｏｂ（　）を呼び出すことによってユーザが投入した一つのジョブを多重化することができる。
【００３０】
ユーザはｓｃｒｕｎによってＳＣｏｒｅ−Ｄにジョブを投入する時に、ジョブの多重化度を指定することができる。このためにはｓｃｒｕｎに新たに“−ｍｕｌｔｉ”オプションを定義した。以下にオプションを示す。
【００３１】
ｓｃｒｕｎ−ｍｕｌｔｉ＝多重化数　ユーザジョブ
ユーザが投入したジョブはＳＣｏｒｅ−Ｄ内で終了を待ってｓｃｒｕｎに返している。この時多重化によって生成したジョブは正しく終了処理を行うことができない。そこで多重化したジョブの終了を監視するスレッドを起動する。これをジョブ監視スレッドと呼ぶ。ジョブ監視スレッドは全てのジョブが終了するのを待って、全てのクラスタの結果から多数決処理を行う。
【００３２】
多数決で使われる比較対象データはユーザがアプリケーション内で指定する。比較データは以下の書式のＡＰＩ関数を呼び出すことで宣言する。
【００３３】
ｖｏｉｄ　ＭＪ　ＤｅｓｃＩｎｔ　（ｉｎｔ　＊ｐｔｒ，　ｉｎｔ　ｄｉｍ，　ｉｎｔ　ｓｉｚｅ　［　］）
ｖｏｉｄ　ＭＪ　ＤｅｓｃＤｏｕｂｌｅ　（ｄｏｕｂｌｅ　＊ｐｔｒ，　ｉｎｔ　ｄｉｍ，　ｉｎｔ　ｓｉｚｅ　［　］，　ｄｏｕｂｌｅ　ｄｅｌｔａ）
ここで、ＭＪ　ＤｅｓｃＩｎｔは整数型のデータを比較対象とすることを宣言するためのＡＰＩで、ＭＪ　ＤｅｓｃＤｏｕｂｌｅは浮動小数点数型のデータを宣言することを意味する。“ｄｉｍ”はデータが配列だった場合にその次元数を、“ｓｉｚｅ［　］　”は各次元のサイズを与えるための引数である。またＭＪ　ＤｅｓｃＤｏｕｂｌｅ（　）の“ｄｅｌｔａ”は誤差を指定するための引数である。誤差は有効数字の桁数を小数点以下何桁かで指定する。
【００３４】
例えば、
３．１４１５９２
３．１４１６００
は“ｄｅｌｔａ”が０．００１の時には等しいと判定され、０．０００１の場合には異なっていると判定される。
【００３５】
“ｄｅｌｔａ”は有効数字の桁数の整数として宣言することもできる。この場合、４以下の時は等しいと判定され、５以上の時は異なると判定される。
【００３６】
今回の実装では比較するタイミングはジョブが終了した段階で行っている。ジョブが終了すると、多重化したジョブ監視スレッドに実行結果が送出される。ジョブ監視スレッドは全てのサブクラスタから実行結果を受けとった時に、それぞれ比較する。
【００３７】
（付記１）複数のクラスタであって、各クラスタは複数のノードからなり、各クラスタの複数のノードはアプリケーションプログラムの処理を分担して並列に実行するものと、
該複数のクラスタからの複数の実行結果の中から、最も多くのクラスタからの実行結果を前記アプリケーションプログラムの実行結果として採用する多数決手段とを具備する高信頼性クラスタシステム。（１）
（付記２）前記多数決手段は、すべてのクラスタにおいてアプリケーションプログラムの処理が終了した後において前記多数決の判断を行なう付記１記載のシステム。（２）
（付記３）前記多数決手段は、すべてのクラスタにおいてチェックポイントの処理を行った後において前記多数決の判断を行なう付記１記載のシステム。（３）
（付記４）前記チェックポイントの処理を行なう前にすべてのクラスタ間で同期がとられる付記３記載の装置。
【００３８】
（付記５）各クラスタの各ノードについて、同期待ち状態にあるノードの実行結果を記憶する記憶領域をさらに具備し、
前記多数決手段は、それぞれのクラスタにおいて同じ処理を担当するノードについて同期待ちとなって実行結果が書き込まれた後において多数決の判断を行なう付記１記載のシステム。（４）
（付記６）前記多数決手段は、隣り合うクラスタ間で比較を繰り返すことによって多数決の判断を行なう付記１〜５のいずれかに記載のシステム。
【００３９】
（付記７）多数決に敗れたクラスタを通知する手段をさらに具備する付記１〜６のいずれかに記載のシステム。
【００４０】
（付記８）複数のコンピュータに付記１〜７のいずれかに記載のシステムを実現させるプログラム。（５）
【００４１】
【発明の効果】
以上説明したように、本発明によれば信頼性が乏しいＰＣの集合体であるＰＣクラスタにおいて、性能の低下を防ぎながら信頼性を向上させることができる。
【図面の簡単な説明】
【図１】ＳＣｏｒｅのソフトウェアアーキテクチャを示す図である。
【図２】Ｓｃｏｒｅ上で動作する並列ジョブの処理の流れを示す図である。
【図３】多数決を行なう２つの手法を説明する図である。
【図４】チェックポイントを行う前のクラスタ間の同期を説明する図である。
【図５】同一の処理を行なうノード間での同期を説明する図である。
【図６】リーグ戦方式による多数決を説明する図である。
【図７】トーナメント方式による多数決を説明する図である。
【図１】
2004046356.tif 000003
【図２】
2004046356.tif 000004
【図３】
2004046356.tif 000005
【図４】
2004046356.tif 000006
【図５】
2004046356.tif 000007
【図６】
2004046356.tif 000008
【図７】
2004046356.tif 000009