−−−第1の実施形態−−−
以下に本発明における第1の実施形態について図面を用いて詳細に説明する。第1の実施形態のフォールトトレラントシステムにおいては、多数決冗長構成におけるリーダーたる計算機およびフォロワーたる各計算機で、同一のタスクを実行する。リーダーはタスクの処理状体が含まれた通知メッセージをフォロワーに対して逐次送信し、フォロワーはそれに対して、リーダー同様に処理可能であるかどうかを承認/否認のメッセージ(追従可否のメッセージ)としてリーダーに応答する。この場合、リーダーはフォロワーからの応答すなわち上述のメッセージの内容、受信タイミングおよびメッセージの種類によって、該当タスクに関して多数決冗長構成に対応した動作(例:メッセージ待ち受け)の継続に関して判断する。
図1は、第1の実施形態に係るフォールトトレラントシステムの構成例を示す図である。図1に示すフォールトトレラントシステム1は、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性を向上させるコンピュータシステムである。
当該フォールトトレラントシステム1は、複数の計算機ノード110で構成される。図1のフォールトトレラントシステム1においては、計算機ノード110として3台の計算機ノード110A、110B、110Cでシステム構成した例を示している。勿論、フォールトトレラントシステム1を構成する計算機ノード数は「3」台である場合に限定されず、例えば「2」台や「4」台以上であってもよい。
多数決冗長構成に対応したフォールトトレラントシステム1においては、計算機ノード110のうち1台をリーダーノードとし、残りの計算機ノード110をフォロワーノードとする。リーダーノードとフォロワーノードの役割は、計算機ノード110の中で固定的である必要はない。例えば、あるタスク毎、すなわち当該タスクに関する上述の通知メッセージごとに、一番最初にその通知メッセージを送信した計算機ノード110をリーダーノードとするなどといったアルゴリズムを用いて、それぞれの役割を交代してもよい。ただし、フォールトトレラントシステム1の動作中の任意の時点において、リーダーノードは、高々一つが存在する。リーダーノードが存在しない場合、もしくは、リーダーノードに何らかの障害が発生して処理を停止しリーダーノードが存在しなくなった場合、フォールトトレラントシステム1は処理を中断し、フォロワーノードの中から、一つの計算機ノード110をリーダーノードとして選ぶこととなる。こうした多数決冗長構成を成す計算機ノード中からリーダーノードを選択する処理技術については既存のものを採用してよい。なお、第1の実施形態においては、3台の計算機ノード110のうち、計算機ノード110Aをリーダーとし、計算機ノード110B及び計算機ノード110Cをフォロワーとしている。
また、各計算機ノード110のハードウェア構成は以下の如くとなる。計算機ノード110は、主記憶装置121と1つ以上の中央演算装置120、外部通信インタフェース122、およびノード間通信インタフェース123を備える。このうち外部通信インタフェース122は、1台以上の端末102と外部ネットワーク111を介し接続されている。また、ノード間通信インタフェース123は、他の計算機ノード110とノード間ネットワーク112を介し接続されている。これらのネットワーク111、112は、例えばイーサネット(登録商標)規格やInfiniband規格に準拠して構成されたネットワークである。
また、計算機ノード110における主記憶装置121は、データの読み込み及び書き込みが可能な揮発性記憶装置であり、中央演算装置120からアクセスされる。この主記憶装置121は、例えばDRAM(Dynamic Random Access Memory)等で構成されるものである。
また、計算機ノード110における中央演算装置120は、汎用プロセッサであり、補助記憶装置124等から、基本ソフトウェア130、フォールトトレラントミドルウェア(以下、FTミドルウェア)131、及びアプリケーション132等のプログラムを読み出して主記憶装置121に展開し、該当プログラムを実行する。中央演算装置120の採用するアーキテクチャや、その処理速度は、複数ある計算機ノード110で同一のものでなくてもよい。また、各計算機ノード110は2つ以上の中央演算装置120を備えていてもよい。
また、計算機ノード110における補助記憶装置124は、永続的な不揮発性記憶装置であり、基本ソフトウェア130、FTミドルウェア131、アプリケーション132等のプログラムに加えて、これらプログラムから読み書きされるデータ等が格納される。補助記憶装置124は、例えばハードディスク、フラッシュメモリなどにより構成される。
また、計算機ノード110における外部通信インタフェース122は、計算機ノード110が端末102と通信を行うためのインタフェースである。一方、ノード間通信インタフェース123は、計算機ノード110同士で通信を行うためのインタフェースである。なお、外部通信インタフェース122及びノード間通信インタフェース123は、個別の装置である必要はなく、一つの通信インタフェースが外部通信インタフェース122及びノード間通信インタフェース123を兼ねていてもよい。外部通信インタフェース122及びノード間通信インタフェース123は、それぞれ外部ネットワーク111及びノード間ネットワーク112の種類に応じた通信インタフェース等で構成される。
また、主記憶装置121に保持されるアプリケーション132は、FTシステム1が提供する機能を実現するためのプログラムである。アプリケーション132は、一つ以上のタスク133から構成される。FTシステム1においては、複数の計算機ノード110で同じアプリケーション132が実行される。なおこの時、アプリケーション132は、実行される計算機ノード110のアーキテクチャや基盤ソフトウェア等の差異に応じた差異をもっていてもよい。すなわち、アプリケーション132およびそのタスク133を構成する、中央演算装置120のための命令群は、計算機ノード110間において同一である必要はない。
また、主記憶装置121に保持される基本ソフトウェア130は、マルチタスク処理が可能なオペレーティングシステムであり、複数のタスク133およびFTミドルウェア131を並列に実行することができる。この基本ソフトウェア130は、FTミドルウェア131に対して、補助記憶装置124に対するアクセス、外部通信インタフェース122及びノード間通信インタフェース123に対するデータ送受信の機能、主記憶装置121の一部分の占有領域の確保および解放等の機能を提供する。
また、主記憶装置121に保持されるFTミドルウェア131は、FTシステム1においてフォールトトレラント機能を実現するためのプログラムである。FTミドルウェア131は、上述のアプリケーション132に対して、補助記憶装置124に対するアクセス、外部通信インタフェース122に対するデータ送受信、主記憶装置121の一部分に対する排他処理の機能等を提供する。これらの機能について、FTミドルウェア131は、基本ソフトウェア130等の提供する機能を用いて実現する。なお、FTミドルウェア131は、独立したプログラムであっても、アプリケーション132に組み込まれて一体となる形であっても、あるいは、基本ソフトウェア130に組み込まれて一体となる形であってもよい。また、アプリケーション132、FTミドルウェア131、基本ソフトウェア130の3つは、単一のプログラムが兼ねていてもよい。
こうしたFTミドルウェア131は、タスク通信部140、ノード間通信部141、およびメッセージ処理部142を備えている。これらタスク通信部140、ノード間通信部141、メッセージ処理部142は、各計算機ノード110の中央演算装置120がFTミドルウェア131を実行することで実装される機能と言える。
このうちタスク通信部140は、タスク133からの処理の要求を受け取り、その要求をメッセージ処理部142に対して伝達する。一方、メッセージ処理部142は、他の計算機ノード110との同期をとった上で要求された処理を実行し、その結果をタスク通信部140に対して伝達する。メッセージ処理部142から上述の結果を得たタスク通信部140は、該当結果をタスク133に対して伝える。
メッセージ処理部142が他の計算機ノード110との通信を行う際には、ノード間通信部141に対し、ノード間通信インタフェース123を経由したデータ送信を要求する。一方、ノード間通信部141はノード間通信インタフェース123から受信したデータをメッセージ処理部142に伝達する。こうした、タスク133とタスク通信部140、タスク通信部140とメッセージ処理部142、メッセージ処理部142とノード間通信部141の各間の伝達の手段としては、任意のものを採用できる。例えば、上述の伝達手段として、関数呼び出しとその返り値や、ソケットやパイプといった基本ソフトウェア130の提供する通信手段等を用いることができる。
また、ノード間通信部141は、ノード間通信インタフェース123からデータを受信すると、その内容をメッセージ処理部142に伝達する。また、メッセージ処理部142から、他の計算機ノード110に対してのデータ送信の要求を受けると、その内容を指定された計算機ノード110に対して、ノード間通信インタフェース123を用いた送信を行う。
FTミドルウェア131では、前述した処理部140、141、142の他に、承認メッセージリスト150、通知メッセージリスト151、およびメッセージ種類テーブル152を備える。これらの保持するデータ及びその役割については後述する。なお、メッセージ種類テーブル152は、処理において必ずしも必要なものではない。これについても後述する。
続いて、FTシステム1を構成する各計算機ノード110の間の関係について説明する。図2は、第1の実施形態に係るFTシステム1を構成する複数の計算機ノード間の関係例を示す図であり、FTシステム1がフォールトトレラント機能を実現するために必要な各部分の関係例について示した図である。FTシステム1の実現するフォールトトレラント機能は、半数未満の計算機ノード110のハードウェアあるいはソフトウェアの障害が発生しても、タスク133の機能を継続して提供できる機能である。
そのために、先に説明したように、複数の計算機ノード110において同じタスク133を動作させる。タスク133が外部からの入力あるいは外部への出力を行う時、あるいは、複数のスレッドの動作順序を決定する時など、動作を計算機ノード110間で一致化させなければならない処理(以下、「動作一致化点」と呼ぶ)において、計算機ノード110間でメッセージをやりとりして、全ての計算機ノード110でタスク133が同一の挙動を示すようにする。
このために、各タスク133は、各動作一致化点において、FTミドルウェア131を呼び出し、その処理の実行を要求する。一方、FTミドルウェア131は、その内容を他の計算機ノード110のタスク133の要求と比較し、過半数の計算機ノード110に関して同一であれば、それを実際に実行する。これにより、計算機ノード110の半数未満が、ハードウェア障害やソフトウェア障害によって無応答、応答遅延、あるいは、異常応答を行った場合でも、他の計算機ノード110の結果により、タスク133の動作を継続することができる。
本実施形態では、上述したように、動作一致化点において計算機ノード110間で合意形成の効率化のために、計算機ノード110を、役割別にリーダーノード110Aとフォロワーノード110B、110Cの二種に分けるものとする。動作一致化点において、リーダーノード110Aが、その動作を決定し、フォロワーノード110B、110Cに対して、その処理要求に対する動作内容を通知メッセージ201により通知する。フォロワーノード110B、110Cは、自身のタスク133からの処理要求と照合し、この動作内容に追従可能、すなわちリーダーノード110Aと同じ挙動を実現することが可能であれば承認メッセージ202、不可能であれば否認メッセージ203をリーダーノード110Aに返答する。リーダーノード110Aは、承認メッセージ202を多数決における賛成票、否認メッセージ203を反対票として扱い、過半数が承認メッセージ202を受け取った時には、これを実際に実行する。このような多数決冗長構成に伴うリーダーノード110A、フォロワーノード110B、110Cの基本的な挙動に関しては従来と同様である。
続いて、FTミドルウェア131内の構造であるタスク通信部140、メッセージ処理部142、ノード間通信部141の動作と、その際に使用されるデータ構造である承認メッセージリスト150、通知メッセージリスト151、およびメッセージ種類テーブル152について述べる。
図3、図4、図5は、承認メッセージリスト150、通知メッセージリスト151、およびメッセージ種類テーブル152の内部構造の一例をそれぞれ示した図である。このうち、承認メッセージリスト150及び通知メッセージリスト151は、メッセージ処理部142によって下記のように使用される。メッセージ処理部142は、タスク通信部140から処理要求を受け取ったとき、当該計算機ノード110がリーダーノードであれば、これを他の計算機ノードすなわちフォロワーノードに対して伝達する。メッセージ処理部142は、フォロワーノードからの承認メッセージや否認メッセージの受信の有無を管理するために、承認メッセージリスト150に承認メッセージ、否認メッセージの受信履歴を記録する。他方、フォロワーノードでは、リーダーノードからの通知メッセージの受信の有無を管理するために、通知メッセージ201のリストである通知メッセージリスト151を使用する。
承認メッセージリスト150は、通知参照300、承認ノード集合301、及び、否認ノード集合302などの各値を各行として持つテーブルである。通知参照300は、その行の管理するところの通知メッセージ201への参照(参照は、識別子によるもの、メモリ番地によるもの、あるいは、参照先のコピーによるものなど任意の方法でよい。以下同様)用の情報で通知メッセージ201の識別情報となる。また、承認ノード集合301は、通知メッセージ201に対して承認メッセージ202を返答したフォロワーノードたる計算機ノード110の集合を表す。同様に、否認ノード集合302は、通知メッセージ201に対して否認メッセージ203を返答したフォロワーノードたる計算機ノード110の集合を表す。
また、通知メッセージリスト151は、リーダーノードから送付されていて、かつ、承認メッセージ202もしくは否認メッセージ203を返答していない0個以上の通知メッセージ201をリストとして持つ。
次に、タスク通信部140とメッセージ処理部142への処理の要求及びその結果の伝達に用いられるデータ構造について述べる。以下では、「処理要求」とはこのタスク通信部140からメッセージ処理部142に対して、タスクからの処理要求を伝達するデータ構造を指し、「処理結果」とはメッセージ処理部142からタスク通信部140に対して、処理要求に対する処理の結果(処理内容)を伝達するデータ構造を指す。処理要求の内部構造の一例としては、要求種別と、それに応じた要求パラメータがある。他方、処理結果の内部構造の一例としては、対応している処理要求への処理要求参照と、処理の結果を表す値である処理結果値がある。なお、タスク通信部140とメッセージ処理部142の間の伝達方式により、参照する処理が一意に特定できるのであれば、処理要求参照を省略することができる。
処理要求において、要求種別は、タスク133のFTミドルウェア131に対する要求の種別を示し、例えば、補助記憶装置124からの読み込みや補助記憶装置124への書き込み、外部通信インタフェース122からのデータ受信、あるいはデータ送信、主記憶装置121の一部領域に対する排他処理といったものである。一方、要求パラメータは、それぞれ要求種別により意味を異とする値であり、またその数も要求種別に応じて異なる。要求種別が「補助記憶装置124からの読み込み」であった場合を一例とすれば、補助記憶装置124上のファイル名、ファイル上の位置、読み込んだ値を格納する主記憶装置121の位置、読み込むバイト数等が、要求パラメータに含まれる。
また処理結果は、タスク通信部140からメッセージ処理部142に対してそれまでに通知された処理要求の処理結果を、メッセージ処理部142からタスク通信部140に通知するために使用される。処理結果値は、処理要求参照により参照される処理要求の要求種別により意味を異とする値であり、またその数も要求種別に応じて異なる。なお、この処理結果値は、要求に対する結果を全て表現する必要はない。たとえば外部通信インタフェース122からデータを受信し指定した主記憶装置121へのコピーといった副作用を持つ処理要求であれば、メッセージ処理部142は、指定したデータ内容の主記憶装置121へのコピー処理を行った上で、処理結果をタスク通信部140に通知する。このような場合において、受信したデータのサイズのみを処理結果値として返し、受信データそのものの情報は、処理結果値には陽に含めないということができる。
図6にて、リーダーノードとフォロワーノードの間で、処理要求の伝達を行う際に用いられる通知メッセージ201及び、それに対する応答である承認メッセージ202と否認メッセージ203 のデータ構造の一例を示す。ここで通知メッセージ201は、伝達するリクエストへの参照値であり、処理要求の種別を規定した処理要求400をもつ。処理要求への参照値に加えて、あるいはそれに代えて、後述するフォロワーノードにおける内容比較のために十分な内容、すなわちその処理要求について挙動が同一であると判定するのに十分な情報を含む任意の付随データ406を含んでいてもよい。
また、承認メッセージ202及び否認メッセージ203は、対応するリーダーノードから送付された通知メッセージ201を参照するための値である通知参照300を持つ。なお、通知メッセージ201を一意に識別できるのであれば、処理要求の参照で代用することもできる。
続いて図5に示すメッセージ種類テーブル152について述べる。メッセージ処理部142は、後述するように各処理要求に対して、メッセージ同期種類を判定する。メッセージ同期種類は、例えば「同期」、「準同期」のいずれかであり、その処理要求に対するメッセージの応答あるいは到着に対して、メッセージ処理部142がいつ次の処理に進むかの処理を規定するものである。例えば、リーダーノードにおけるメッセージ処理部142は、そのメッセージ同期種類が「同期」である処理要求に対しては、現在FTシステム1で正常に動作している全ての計算機ノード110からの応答を待ってから次の処理に進み、「準同期」であるメッセージに対しては、現在FTシステム1で正常に動作している計算機ノード110の半数の承認メッセージ202を待ってから次の処理に進む、といった動作を行う。この判断の方法の一例として、メッセージ種類テーブル152を用いた方法がある。 このメッセージ種類テーブル152は、上述した処理要求について、その要求種別303からメッセージ同期種類304を判断するものである。メッセージ種類テーブル152は、要求種別303とメッセージ同期種類304などの各値を各行として持つテーブルである。各行は、要求種別303をもつ処理要求、および、それを処理要求参照としてもつ通知メッセージ201のメッセージ待ちの挙動の種類が、メッセージ同期種類304であることを意味する。なお、メッセージ同期種類の判定は、この方法に限定されない。例えば、メッセージ種類テーブル152が存在しない場合であっても、計算機ノード110がメッセージにそのメッセージを一意に識別する連番を振り、ある倍数の番号のメッセージを「同期」とし、それ以外を「準同期」とするといった方法をとることもできる。
続いて、FTシステム1を構成する各計算機ノード110A、110B、110Cの動作と連携について説明する。図7は第1の実施形態に係るFTシステム1における計算機ノード110の各処理部の動作フロー例を示す図である。この図においては、リーダーノードとして計算機ノード110A、フォロワーノードとして計算機ノード110Bの動作を示している。この他のフォロワーノード110Cについては、計算機ノード110Bと同様の動作を行うので説明を省略している。
まず、リーダーノードたる計算機ノード110Aの動作について述べる。計算機ノード110Aのタスク通信部140は、アプリケーション132から要求を受け(510)、これを処理要求400の形でメッセージ処理部142に伝達する(511)。メッセージ処理部142は、この処理要求400に応じて必要であれば適宜処理を行い、その処理要求400等を含む通知メッセージ201を、ノード間通信部141に依頼してフォロワーノードに対して送信する(512)。
次に計算機ノード110Aのメッセージ処理部142は、タスク通信部140から受けた上述の処理要求400について、メッセージ同期種類を判断する(513)。メッセージ処理部142は、ステップ513で判断したメッセージ同期種類に応じた、フォロワーノードたる計算機ノード110B、110Cからの承認メッセージ202あるいは否認メッセージ203の応答待ちを行う(514)。この時、計算機ノード110Aのメッセージ処理部142は、すべてのフォロワーノードからの応答について受信待ち(メッセージ同期種類=「同期」)、半数のフォロワーノードからの承認メッセージ202について受信待ち(メッセージ同期種類=「準同期」)といった、メッセージ同期種類に応じた待機を行う。こうした応答待ちの後、メッセージ処理部142は、各フォロワーノードより得た該当タスクの処理結果に関して多数決処理を行い、タスク通信部140に対して、最終的に一致した結果を処理結果として伝達する(515)。タスク通信部140は、この結果をアプリケーション132に通知する(516)。
他方、フォロワーノードたる計算機ノード110Bの動作について説明する。なお、フォロワーノードである計算機ノード110Bのタスク通信部140の動作は、リーダーノードたる計算機ノード110Aの場合と同様であるので説明を省略する。フォロワーノードたる計算機ノード110Bのメッセージ処理部142は、リーダーノードたる計算機ノード110Aからの通知メッセージ201を待つ(517)。リーダーノードから通知メッセージ201が送信されてきた場合、計算機ノード110Bのメッセージ処理部142は、リーダーノードから受信した通知メッセージ201と、自身のタスク通信部140でタスク133から受けている処理要求の内容とを比較し、リーダーノードの挙動に追従可能(すなわち同じタスクについて処理を同期的に実行可能)かどうかを判断し、追従可能であれば承認メッセージ202を、追従不可であれば否認メッセージ203をノード間通信部141経由でリーダーノードに送信する(519)。
以下では、図7の点線で囲んだフローについて、その詳細を述べる。リーダーノードのメッセージ処理部142のフロー(501)について図8及び図9で、フォロワーノードのメッセージ処理部142のフロー(502)について図10でそれぞれ述べる。
図8、図9は第1の実施形態に係るフォールトトレラントシステムにおけるリーダーノードのメッセージ処理部での動作フロー例1、2を示す図であり、具体的には、リーダーノードのメッセージ処理部142が、タスク通信部140から処理要求を受け、この処理要求に対応する処理を行い、その結果をタスク通信部140に返す処理の一例を示したフローチャートである。
この場合、リーダーノードのメッセージ処理部142は、まずタスク通信部140から処理要求を受け取る(600)と、外部に影響がある場合、すなわち、外部通信インタフェース122からの送信などの場合を除いて、この処理要求に対応する処理を行う(601)。このときメッセージ処理部142は、必要であれば要求付随データ(図6の付随データ406に対応)を生成する。メッセージ処理部142は、これをもとに、受信した処理要求を参照する通知メッセージ201を生成し、要求付随データがあればそれを加え、全フォロワーノード(計算機ノード110B及び計算機ノード110C)に対してノード間通信部141を介して送信する(602)。
次にメッセージ処理部142は、FTミドルウェア131における承認メッセージリスト150に、該当通知メッセージ201に対応する、すなわち通知参照300として当該通知メッセージ201を含む行を追加する(603)。次にメッセージ処理部142は、ステップ600で受けた処理要求について、メッセージ同期種類を判定する(604)。
ステップ604において、メッセージ処理部142は、例えばFTミドルウェア131におけるメッセージ種類テーブル152に対し、上述の処理要求の情報を照合することにより、メッセージ種類テーブル152の各レコードのうち、要求種別400の値が、ステップ600で受けた処理要求(例:sync,Network_Send,Network_Recv,Lock_Acquire)の値にマッチした行を特定し、該当処理要求のメッセージ同期種類304を判断する。但し、既に上述したように、メッセージ同期種類を判断する手法は、メッセージ種類テーブル152を用いたこの方法に限定されず、メッセージ同期種類を一つに決定できる方法であればいずれのものも採用できる。
上述のステップ604の結果、ステップ600で受けた処理要求のメッセージ同期種類が「同期」であったとする(604:同期)。このとき、リーダーノードのメッセージ処理部142は、その時点で動作している全てのフォロワーノードからの応答を、該当処理要求に関する動作の継続に必要とする。すなわちリーダーノードのメッセージ処理部142は、全フォロワーノード(計算機ノード110B及び計算機ノード110C)からの承認メッセージ202あるいは否認メッセージ203を待つ(605)。
その後、メッセージ処理部142は、承認メッセージ202の受信をノード間通信部141から通知された(以下、簡単に「受信した」とする)場合(606:Ack)、承認メッセージリスト150の当該行(該当処理要求に関する通知メッセージ201に関してステップ603で追加した行)において、承認ノード集合301に、送信元の計算機ノード110(すなわち該当通知メッセージ201に対して承認メッセージ202を返答したフォロワーノード)の識別情報を追加する(607)。
他方、メッセージ処理部142は、否認メッセージ203をフォロワーノードから受信した場合(606:Nack)、同様に、承認メッセージリスト150の当該行において、否認ノード集合302に、送信元の計算機ノード110(すなわち該当通知メッセージ201に対して否認メッセージ202を返答したフォロワーノード)の識別情報を追加する(608)。
リーダーノードのメッセージ処理部142は、全てのフォロワーノードが承認メッセージリスト150における承認ノード集合301あるいは否認ノード集合302のいずれかに入るまで、これを繰り返す(609)。これにより、リーダーノードのメッセージ処理部142は、該当メッセージ201に対応する処理要求を実行する時点まで、すべてのフォロワーノードのタスク133が到達したことを確認できる。
ステップ609において、全てのフォロワーノードが承認メッセージリスト150における承認ノード集合301あるいは否認ノード集合302のいずれかに入ったと判定したならば(609:Yes)、リーダーノードのメッセージ処理部142は、同タスクに関する各計算機ノードでの実行結果について、多数決の原理に従って、処理を継続するかどうか判定する(610)。承認メッセージ202を送信した計算機ノードが否認メッセージより多数、ないしは否認メッセージと同数である場合(610:Yes)、リーダーノードのメッセージ処理部142は、否認メッセージ203を送信したノードを停止させる。これは、リーダーノード自身は当然この通知メッセージ201の内容に同意しているためで、承認メッセージ202を送信したフォロワーノードと否認メッセージ203を送信したフォロワーノードが同数であれば、過半数のノードが同意していることになる。承認メッセージ202を送信したノードが多数である場合に、まだ処理要求に対応する処理を実行していない場合には、この時点においては過半数の計算機ノードの同意が得られているため、リーダーノードはこれを実行する(611)。最後に、リーダーノードのメッセージ処理部142は、ステップ611の処理結果を生成して(612)、それをタスク通信部140に伝達し(613)、タスク通信部140からの次の処理要求を待つ処理(600)に戻る。
他方、否認メッセージ203を送信したノードのほうが多数である場合には(610:No)、リーダーノード自身に障害が発生したとみなせるので、リーダーノードのメッセージ処理部142は当該リーダーノード自身の動作を停止するなどの障害時の処理を実行する(614)。
一方、上述のステップ604の結果、メッセージ同期種類が「準同期」であったとする(604:準同期)。このとき、リーダーノードは、その時点で動作しているフォロワーノードのうち過半数からの応答を、該当タスクに関する動作の継続に必要とする。動作は、承認メッセージ202や否認メッセージ203の受信に関しては、前段の場合と同様であるが(616,617,618,620)、条件が異なり、フォロワーノードの半数以上が承認ノード集合301に加わるか、全てのフォロワーノードが承認ノード集合301あるいは否認ノード集合302のいずれかに入るまでこれを繰り返す(619)。リーダノード自身は、この決断に当然同意しているので、フォロワーノードの半数以上が承認メッセージ202を送信したということは、過半数のノードが応答したということになる。その後の多数決結果の判定処理(610)以降の処理は、前段の場合と同様である。なお、リーダーノードが処理を進めた後も、残りのフォロワーノードは、承認メッセージ202あるいは否認メッセージ203を送信する可能性がある。このために、リーダーノードのメッセージ処理部142は、これらを受け取った場合に、該当する承認ノード集合301あるいは否認ノード集合302に加わる操作を随時行う。否認メッセージ203を受信した場合には、これが少数派であることがわかるので、ただちにそのノードを停止させる。
上述した内容は、全てのフォロワーノードが正しく応答をした場合であるが、背景で述べたように、計算機ノード110や、ノード間ネットワーク112、ノード間通信インタフェース123での障害発生等により、フォロワーノードが無応答となる場合、あるいは、応答が著しく遅延する場合がある。この状況下では、上述のフローのうち、メッセージ同期種類が「同期」(604:同期)であった際の、リーダーノードのメッセージ処理部142が行う受信待ち(605)の処理に影響が及ぶ。
ステップ602での通知メッセージ201の送信時刻から所定時間(以下、タイムアウト時間とする)が経過した場合(606:タイムアウト)、リーダーノードのメッセージ処理部142は、その時刻までに承認メッセージ202もしくは否認メッセージ203を送らなかったフォロワーノードで障害が発生したとみなす。そして、リーダーノードのメッセージ処理部142は、多数決結果の判定判定(610)の処理にうつる。このとき、障害が発生したとみなされたフォロワーノードは、否認ノード集合302にあるとみなしてもよいし(621)、計算機ノードの全数から取り除いて判断してもよい。
上述のタイムアウト時間としては、最も単純な例では定数値が想定できる。或いは、例えば計算機ノード110が、任意のアルゴリズムによってタイムアウト時間を決定するとしてもよい。例えば、上述の通知メッセージ201に応じて所定処理を実行する時間を所定アルゴリズムで予測して、フォロワーノードからの承認/否認のいずれかのメッセージの到達期待時間を特定し、これをタイムアウト時間と算出するなどしてもよい。定数を用いた場合であっても、全メッセージのうちメッセージ同期種類が「同期」のものについてのみ、タイムアウト時間を用いた障害判定が行われるため、過半数の計算機ノードが大きな遅延なく動作している場合には、半数未満の、すなわち少数派の計算機ノードで一時的な遅れがあっても、それを吸収することができる。
また、メッセージ同期種類304が「同期」となる処理要求の要求パラメータに、実行制約時間を加え、これを基準にタイムアウト時間を定めることもできる。これは、タイムアウト時間を明示的にアプリケーションから制御することで、例えば周期的に実行されるタスクの周期時間というようなアプリケーションの特性に応じた障害判定を行うことが可能になるメリットがある。
メッセージ同期種類304が「同期」となる処理要求は、例えば、既知の時間制約のもと一定の時間間隔をおいて同じプログラムを繰り返し実行するタスク(「周期タスク」)での、繰り返し実行する領域の開始点を示す要求であるとか、未知のタイミングで到達する外部からのメッセージ受信、つまり、外部通信インタフェース122からのデータ受信の要求などである。メッセージ同期種類304が「同期」である二つの連続したメッセージについて、それらに対応する処理要求を発行するタスク133の実行箇所への早い方の到達時刻から、遅い方の到達時刻の時間についての時間制約(以下「時間制約」という)が明確である場合に、その時間制約を、いずれかの処理要求の要求パラメータに加える。
この時間制約を用いたステップ605におけるタイムアウト処理は、下記の通りになる。リーダーノードのメッセージ処理部142は、直前のメッセージ同期種類304が「同期」である処理要求の受信時刻から、その要求パラメータに含まれる時間制約、もしくは、現に処理している処理要求の要求パラメータに含まれる時間制約(どちらを用いるかは実装に依存する)だけ経った場合に、タイムアウトとみなす。これ以外のメッセージ同期種類304についても、あるいは、フォロワーノードについても、例えば、直前のメッセージ同期種類304が「同期」である処理要求の受信時刻から、その要求パラメータに含まれる時間制約を、あるいは、その時間制約を適当な割合で按分した時間をタイムアウト時間として用いることができる。
なお、後述するが、メッセージ種類が「非同期」の時の受信待ちにおいては、別の方法で決められたタイムアウト時間を用いて、障害判定を行ってもよいし、タイムアウトを用いないということもできる。後者では、過半数のノードが応答をしない場合にはリーダーノードはフォロワーノードからの承認/否認メッセージを無限に待つことになるが、そもそも過半数のノードが無応答である場合には、FTシステム1として動作を継続できない状態であって、停止させられるべき状態であり、可用性の点ではこれを大きく損なうものではない。
続いて、フォロワーノードのメッセージ処理部142における処理について説明する。図10は第1の実施形態に係るFTシステム1におけるフォロワーノードのメッセージ処理部142での動作フロー例を示す図であり、具体的には、フォロワーノードのメッセージ処理部142が、タスク通信部140から処理要求を受けて対応する処理を行い、その結果をタスク通信部140に返す処理の一例を示したフローチャートである。
この場合、フォロワーノードのメッセージ処理部142は、まず当該フォロワーノードにおけるタスク通信部140からの処理要求、またはノード間通信部141からのメッセージを待つ(700)。ここで、フォロワーノードのメッセージ処理部142は、タスク通信部140から処理要求を受け取った場合(701:Yes)、通知メッセージリスト151を確認し、タスク通信部140から受けた処理要求に対応する通知メッセージ201がリーダーから到着しているかどうか確認する(702)。
リーダーノードから対応する通知メッセージ201が到着している場合(702:Yes)、フォロワーノードのメッセージ処理部142は、通知メッセージ201の参照する処理要求を、タスク通信部140から受け取った処理要求と比較する(703)。ここでの比較処理は、タスク通信部140から得た処理要求と通知メッセージ201が含んでいた処理要求の互いの識別情報や付随データ等の一致判定など、二つの処理要求に応じた処理の結果が同一であると判定するのに十分な処理であればよい。
このステップ703の結果、通知メッセージ201の参照する処理要求と、タスク通信部140から受け取った処理要求が同一であると判定したならば(703:YES)、フォロワーノードのメッセージ処理部142は、リーダーノードに対する承認メッセージ202の送信をノード間通信部141を通じて行う(704)。
また、フォロワーノードのメッセージ処理部142は、該当通知メッセージ201をもとに、必要であれば対応する所定処理を実行して(705)、処理結果を生成し(706)、これをタスク通信部140に対して伝達する(707)。
他方、上述のステップ703の結果、通知メッセージ201の参照する処理要求と、タスク通信部140から受け取った処理要求が同一でないと判定したならば(703:No)、フォロワーノードのメッセージ処理部142は、リーダーノードに対する否認メッセージ203の送信をノード間通信部141を通じて行う(708)。なお、このときフォロワーの立場からはリーダーノードの挙動が異常とみなせるので、フォロワーノードのメッセージ処理部142は、リーダーノードの再選出等の提案を他の計算機ノード各々に行うなど、障害発生時の処理を行う(711)。
上述のステップ701にてタスク通信部140からの処理要求を受け取った時点で、リーダーノードからの処理要求が到着していない場合(702:No)、フォロワーノードのメッセージ処理部142は、リーダーノードからの処理要求の到着を待つこととなる(709)。リーダーノードからの処理要求を受信した場合(710:No)、フォロワーノードのメッセージ処理部142は、リーダーノードからの処理要求が既に通知メッセージリスト151に存在していた場合(702:Yes)と同じ処理に進む。
他方、リーダーノードの場合と同様に、フォロワーノードにおいて、リーダーノードもしくはノード間通信インタフェース123の障害等により、リーダーノードからの通知メッセージ201が著しく遅延するか、あるいは、これを受信できないことがある。このため、フォロワーノードのメッセージ処理部142は、ステップ709の待ちにおいて、処理要求の受信時刻からある時間(以下、タイムアウト時間という)が経過しても、リーダーノードから相当する通知メッセージ201を受信しなかった時は、リーダーノードあるいはそのノード間通信インタフェース123において障害が発生したとみなす(710:Yes)。そして、ステップ703で、通知メッセージ201の参照する処理要求と、タスク通信部140から受け取った処理要求とが同一でないと判定された場合と同様に、リーダーノードの再選出提案などの障害発生時の処理を行う(711)。
なお、ステップ701において、フォロワーノードのメッセージ処理部142が、ノード間通信部141から通知メッセージ201を受け取った場合(701:No)、当該通知メッセージ201に対応する処理要求は、タスク通信部140から未だ受信していないため、後の処理のために、該当通知メッセージ201の情報を通知メッセージリスト151に格納する(712)。その後、フォロワーノードのメッセージ処理部142は、処理要求もしくは通知メッセージ201の受信待ち(700)の処理に戻る。
以上の第1の実施形態を採用することで、多数決冗長構成を成すリーダーノードとフォロワーノードの動作を同一に保ちつつ、リーダーノードでのタイムアウト判定(フォロワーノードからの承認/否認メッセージの受信待ち期限の判定)を同期メッセージに関するもののみに減らすことにより、少数のフォロワーノードの一時的な処理や伝送の遅延を許容することができる。
また、メッセージ種類テーブル152を使用したメッセージ同期種類の判定を行うことによって、例えば、同期を行うための同期要求を発行するAPIをタスク通信部140が提供することにより、アプリケーション132が同期するタイミングを制御できるようになり、アプリケーション132の特性に一致したタイムアウト判定の制御を実現することができる。
なお、以上の説明では、タスク133が単一の場合を述べたが、複数ある場合も同様である。ただし、タスク通信部140およびメッセージ処理部142の処理は、タスクごとにスレッド化を行うなどの並列化を行うか、あるいは、入出力待ちの多重化処理を加えることによって、一つのタスク133に対する処理要求の処理によって、他のタスク133が滞らないようにする必要がある。
また、タスク通信部140からの処理要求の受け取りとノード間通信部141からの通知メッセージ201の受け取りを単一の流れとして記述したが、効率化のために複数のスレッド等を用いることによって、それぞれを並列的に実行しても構わない。
−−−第2の実施形態−−−
計算機ノードのメッセージ処理部142が要求リストを用いて処理を行う形態も想定できる。この要求リストとは、メッセージ処理部142が、他の計算機ノードから通知メッセージ201を受け取った際に、それに対して承認メッセージ202を返すか否認メッセージ203を返すかを選択するためのテーブルである。そのため要求リストは、返信するメッセージを承認/否認メッセージのいずれにするか判断するための十分なデータ、例えば、処理要求や要求付随データの各値を持つ。
こうした形態を第2の実施例として説明する。なお、第2の実施形態におけるFTシステム1は図1と同様の構成である。第2の実施形態におけるフォロワーノードの挙動は、図11に示すフローに沿ったものとなる。これ以外の動作と構成は、第1の実施形態と同様であるため、重複箇所の説明については省略する。
図11、図12は第2の実施形態におけるフォールトトレラントシステムのフォロワーノードのメッセージ処理部での動作フロー例1、例2を示す図である。ここでの第1の実施形態との大きな違いは、タスク通信部140で得た処理要求に対する処理を、リーダーノードからの通知メッセージ201の到着を待たずに進行させる点となる。
第2の実施形態におけるフォロワーノードのメッセージ処理部142は、タスク通信部140からの処理要求、またはノード間通信部141からの通知メッセージの伝達を待つ(800)。例えば、タスク通信部140から処理要求を受け取った場合(801:Yes)、フォロワーノードのメッセージ処理部142は、通知メッセージリスト151を確認し、対応する通知メッセージ201がリーダーノードから到着しているかどうか確認する(802)。
ステップ802の結果、タスク通信部140から得た処理要求に対応する通知メッセージ201が既に到着していると判定した場合(802:Yes)、フォロワーノードのメッセージ処理部142は、第1の実施形態と同様の処理を実行する(803〜810)。該当処理は第1の実施形態と同様であるので説明は省略する。
他方、ステップ802の結果、タスク通信部140から得た処理要求に対応する通知メッセージ201が到着していないと判定した場合(802:No)、フォロワーノードのメッセージ処理部142は、該当処理要求に対応する処理を行う(806)。ただし、外部通信インタフェース122からの送信などの、外部に対して影響を与える処理の場合には、実際にはその処理を行わずに、その想定される結果のみ計算する。また、フォロワーノードのメッセージ処理部142は、上述した要求リストに対して、処理要求に関する情報と、その処理の結果などを含む要求付随データを付け加える(807)。こうしてレコードが生成された要求リストは、図6に示した通知メッセージ201の処理要求400および付随データ406と同様形式のデータを含むレコードの集合体となる。
フォロワーノードのメッセージ処理部142は、上述のステップ806の結果から処理結果を生成し(809)、当該処理結果をタスク通信部140に伝達する(810)。その後、フォロワーノードのメッセージ処理部142は、タスク通信部140とノード間通信部141からの伝達待ちに戻る(800)。
一方、ステップ800において、ノード間通信部141から通知メッセージ201を受け取った場合(801:No)、フォロワーノードのメッセージ処理部142は、要求リストを確認し、通知メッセージ201のもつ処理要求参照に対応する処理要求があるかどうか確認する(811)。この確認処理の結果、ノード間通信部141から受け取った通知メッセージ201に対応する処理要求が、要求リスト中に存在すると判定した場合(811:Yes)、フォロワーノードのメッセージ処理部142は、タスク通信部140から得た通知メッセージ201と、要求リストに含まれていた該当処理要求とを比較する (812)。この比較の処理は、図10のステップ703に関して上述したものと同様である。
こうした比較処理の結果、通知メッセージ201の参照する処理要求と、タスク通信部140から受け取った処理要求とが同一であるとみなされた場合(812:Yes)、フォロワーノードのメッセージ処理部142は、承認メッセージ202をリーダーノードに送信する(813)。他方、通知メッセージ201の参照する処理要求と、タスク通信部140から受け取った処理要求とが同一でなかったとみなされた場合(812:NO)、フォロワーノードのメッセージ処理部142は、否認メッセージ203をリーダーノードに送信し(814)、リーダーノードに関する障害時処理を行う(815)。なお、上述のステップ811において、対応する処理要求が要求リスト中に無かった場合、フォロワーノードのメッセージ処理部142は、該当通知メッセージ201の情報を通知メッセージリスト151に追加する(816)。
以上の処理により、フォロワーノードは、リーダーノードからの通知メッセージを待つことなく、タスクに関する処理を各々進めることができるため、処理時間の遅延を短縮することができる。ただし、この場合のフォロワーノードは、リーダーノードでの結果を使わずに処理を進めるため、処理内容の相違が発生する確率が高くなる。そのためフォロワーノードは、一部の処理については、リーダーノードからの通知メッセージを待ち、その他の処理については、待たずに進めるといった、本実施例の部分的な適用も可能である。こうした部分的な適用をする際のフォロワーノードにおける判断には、メッセージ同期種類を用いることもできる。例えば、メッセージ同期種類が「同期」あるいは「準同期」のものについてはリーダーノードからの通知メッセージを待ち、次の実施例で述べるメッセージ同期種類が「非同期」の場合については、リーダーノードからの通知メッセージを待たないとするアルゴリズムである。
−−−第3の実施形態−−−
上述の第1および第2の実施形態では、メッセージ同期種類が「同期」、「準同期」のいずれかの場合について選択的に処理を行う例を示した。ここでは、これら同機種類に加えて、メッセージ同期種類が「非同期」の場合についても想定した例を示すものとする。図13は第3の実施形態におけるFTシステム1のリーダーノードのメッセージ処理部142での動作フロー例を示す図であり、図8のフローに対する差分のみを示したフローチャートである。従って、第1の実施例と同様の構成と処理については説明を省略する。
ここで、リーダーノードのメッセージ処理部142は、タスク通信部140からの処理要求の伝達、もしくはノード間通信部141からの通知メッセージ201の受信を待つ(1000)。待機中、タスク通信部140から処理要求を受け取った場合(1001:Yes)、リーダーノードのメッセージ処理部142は、図8のフローにおけるステップ601〜603を同様に実行した後、メッセージ同期種類を判定する(1002)。メッセージ同期種類が「同期」であった場合及び「準同期」であった場合の処理は、第1の実施形態で示した場合と同様である。
他方、メッセージ同期種類が「非同期」であった場合(1002:非同期)、リーダーノードのメッセージ処理部142は、フォロワーノードからの承認/否認メッセージを待つことなく、図8のフローにおけるステップ611に進む。なお、十分な数の承認/否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部142は、この時点で「準同期」の場合と同様に多数決処理(図8のステップ610)を行なってもよい。他方、多数決処理をしない場合は、タスク通信部140に対して結果を返した後に多数決処理を行う必要があるが、その場合、ノード間通信部141から通知メッセージ201を受信した場合(1001:No)に実行する。
リーダーノードのメッセージ処理部142は、ノード間通信部141から通知メッセージ201を受信したとき(1001:No)、それが承認メッセージ202であれば(1003:Ack)、それに対応する承認メッセージリスト150の行の承認ノード集合301に、その送信元のフォロワーノードの情報を加える(1004)。他方、否認メッセージ203であれば(1003:Nack)、リーダーノードのメッセージ処理部142は、否認ノード集合302に送信元のフォロワーノードの情報を加える(1005)。この行に関して、承認ノード集合301あるいは否認ノード集合302にまだ入っていないフォロワーノードが存在する場合(1006:No)、リーダーノードのメッセージ処理部142は受信待ちに戻る(1000)。すべてのフォロワーノードから承認/否認メッセージを受信した場合(1006:Yes)、リーダーノードのメッセージ処理部142は、多数決処理にうつる。この時、否認メッセージ203が多数の場合(1007:No)、リーダーノードのメッセージ処理部142は、当該リーダーノードに関する障害時処理を行う。
他方、承認メッセージ202が多数の場合(1007:Yes)、リーダーノードのメッセージ処理部142は、承認メッセージリスト150の当該行の削除などを行い(1009)、受信待ち(1000)に戻る。この時、リーダーノードのメッセージ処理部142は、必要に応じて否認メッセージ203を送ったフォロワーノードを停止させる処理等を行なってもよい。
また、十分な数の承認/否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部142は、ステップ1006から多数決処理(1007)へ処理を移すとしてもよい。
以上の実施形態により、第1の実施形態の場合と比べて、リーダーノードがフォロワーノードからの承認/否認メッセージを待つ回数を低減することができるため、個々の計算機ノードの遅れをより効率的かつ適切に許容することが可能になる。
−−−第4の実施形態−−−
ここでは、メッセージ同期種類が「同期」、「非同期」の2種である場合について想定した例を示すものとする。図14は第4の実施形態におけるFTシステム1のリーダーノードのメッセージ処理部142での動作フロー例を示す図であり、図8のフローに対する差分のみを示したフローチャートである。従って、第1の実施例と同様の構成と処理については説明を省略する。また、第3の実施形態と同様の構成と処理についても説明を省略する。
ここで、リーダーノードのメッセージ処理部142は、タスク通信部140からの処理要求の伝達、もしくはノード間通信部141からの通知メッセージ201の受信を待つ(1100)。待機中、タスク通信部140から処理要求を受け取った場合(1101:Yes)、リーダーノードのメッセージ処理部142は、図8のフローにおけるステップ601〜603を同様に実行した後、メッセージ同期種類を判定する(1102)。メッセージ同期種類が「同期」であった場合の処理は、第1の実施形態で示した場合と同様である(図8のフローにおけるステップ605へ)。
他方、メッセージ同期種類が「非同期」であった場合(1102:非同期)、リーダーノードのメッセージ処理部142は、フォロワーノードからの承認/否認メッセージを待つことなく、図8のフローにおけるステップ611に進む。なお、十分な数の承認/否認メッセージをフォロワーノードから既に受信していた場合、リーダーノードのメッセージ処理部142は、この時点で「準同期」の場合と同様に多数決処理(図8のステップ610)を行なってもよい。他方、多数決処理をしない場合は、タスク通信部140に対して結果を返した後に多数決処理を行う必要があるが、その場合、ノード間通信部141から通知メッセージ201を受信した場合(1101:No)に実行する。また、ステップ1101において、ノード間通信部141から通知メッセージ201を受信したとき(1001:No)、以降の処理(1103〜1109)については、第3の実施形態と同様である。
以上の実施形態により、第1の実施形態の場合と比べて、リーダーノードがフォロワーノードからの承認/否認メッセージを待つ回数を低減することができるため、個々の計算機ノードの遅れをより効率的かつ適切に許容することが可能になる。
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
こうした本実施形態によれば、フォールトトレラントシステムにおいて、計算機ノード間の同期のためのメッセージを分類し、その種類に応じて、一部のメッセージでのみ多数決投票の結果を待ち、そうでない場合には非同期的に実行するといった多数決投票の挙動変更を実行して、計算機ノード間での処理の待ち合わせ回数を低減し、以って計算機ノード間での性能ばらつきの影響を相対的に抑制可能となる。そうした効果は、システム全体における処理の遅延や効率低下を軽減できることにもつながる。また、障害判定を行うにあたり、アプリケーションの制約から明確である時間を障害判定の基準として用い、かつ、その基準点とメッセージ種類を一致させることにより、性能差を許容しつつ、過度な障害判定による可用性の低減を防止することも出来る。
したがって、アーキテクチャや基盤ソフトウェア等が互いに異なる複数の計算機ノードで構成されたフォールトトレラントシステムにおいて、計算機ノード間の性能差やばらつきによる全体性能の影響を低減し、またこうした影響に起因する過度な障害判定を防止することにより、システムにおける可用性が向上可能となる。
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行するものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。
また、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラントシステムにおいて、前記他計算機となった計算機のメッセージ処理部は、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しないものである、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または準同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行する、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期、準同期、および非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が準同期に対応するものであった場合、当該他計算機以外の計算機のうち少なくとも半数以上の計算機を対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、準同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。
また、フォールトトレラント制御方法において、前記他計算機となった計算機のメッセージ処理部が、当該他計算機のタスク通信部が得ている処理内容を所定基準に照合し、該当処理内容が同期または非同期のいずれかに対応したものであるか判定し、前記処理内容が同期に対応するものであった場合、当該他計算機以外の計算機の全てを対象として、前記追従可否のメッセージの受信待ちを実行し、前記処理内容が非同期に対応するものであった場合、当該他計算機以外の計算機からの前記追従可否のメッセージの受信待ちを実行しない、としてもよい。
こうして、各計算機が並行して実行すべき同一タスクの種類、すなわち同期、非同期の必要性有無に応じて、フォールトトレラントシステムにおけるリーダーたる計算機での、該当タスクに関する追従可否のメッセージ受信を待ち受けるべきフォロワー計算機の数をコントロールする。これにより、上述のメッセージを待ち受けるべき時間を必要性に応じて選択的に増減して、計算機間の性能差やばらつきによる上述のメッセージの到着時間差を適宜吸収し、ひいては過度な障害判定の防止や、システムにおける可用性向上が可能となる。特に、該当タスクが各計算機間で非同期で処理されるものである場合、リーダーたる計算機において、フォロワー計算機からの上述のメッセージの受信待ちが不要となり、障害判定に要する各計算機の使用リソースを効率化し、ひいてはシステムにおける更なる可用性向上が可能となる。