(57)【要約】【課題】複数のプログラムを複数の実行ノードで並列実行する耐障害システムにおいて、異常な実行ノードを速やかに検出する。【解決手段】同一の実行環境１１２を持つ複数の実行ノード１１０−１〜１１０−ｎ上で、同等の機能を持つが異なるバージョンのプログラム１１１−１〜１１１−ｎを並列実行させることでプログラムレベルでの耐障害性を持たせた耐障害システムにおいて、異常な実行ノードが存在しない状態では、各実行ノードの環境情報の違いはプログラムのバージョンの相違に起因する差異に過ぎないが、何れかの実行ノードが異常になると、その異常になった実行ノードの環境情報だけが他の正常な実行ノードの環境情報と明確に差が生じる。情報取得手段１２１は、プログラムを並列実行中の複数の実行ノードの環境情報を取得し、比較検証手段１２２はこれら複数の環境情報を比較して異常ノードを検出する。【選択図】  図１
2004355233.tif 000002
【特許請求の範囲】
【請求項１】
同一の実行環境上でバージョンが異なるプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備えることを特徴とする耐障害システム。
【請求項２】
それぞれ異なる実行環境上で同一のプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備えることを特徴とする耐障害システム。
【請求項３】
それぞれ異なる実行環境上でバージョンが異なるプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備えることを特徴とする耐障害システム。
【請求項４】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備えることを特徴とする耐障害システム。
【請求項５】
前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含むことを特徴とする請求項１乃至４の何れか１項に記載の耐障害システム。
【請求項６】
前記検出された異常な実行ノードを停止させる停止手段を備えることを特徴とする請求項５記載の耐障害システム。
【請求項７】
前記複数の実行ノードの安定性を判定する安定性判定手段と、前記安定性判定手段で前記複数の実行ノードが安定していると判定されたときに既定数を超える数の実行ノードを停止対象として選択する選択手段とを備え、前記停止手段は前記選択手段で選択された実行ノードを停止させるものであることを特徴とする請求項６記載の耐障害システム。
【請求項８】
異常な実行ノードが検出されたときに、新たな実行ノードを起動する追加手段を備えることを特徴とする請求項５、６または７記載の耐障害システム。
【請求項９】
前記複数の実行ノード上の前記プログラムに同一の処理要求を分配する処理要求分配手段と、前記複数の実行ノードで実行された前記プログラムの処理結果からシステムとしての処理結果を導出する処理結果導出手段とを備えることを特徴とする請求項１乃至８の何れか１項に記載の耐障害システム。
【請求項１０】
前記処理要求分配手段は、処理サービスの要求メッセージを受信する手段と、その要求メッセージをシステム内で処理するかどうか判定する手段と、処理すると判定したら、転送先の実行ノードに転送するためのメッセージを生成する手段と、生成したメッセージを実行ノードに送信する手段と、システムの状態に応じて、判断基準となる情報を更新する手段とを含むことを特徴とする請求項９記載の耐障害システム。
【請求項１１】
前記処理結果導出手段は、処理サービスの応答もしくはデータベースアクセスなどの処理途中の別サービス要求メッセージを受信する手段と、その応答メッセージもしくは別サービス要求メッセージをどのように処理するか判定し、判定に基づきメッセージの選択もしくは生成を行う手段と、応答メッセージもしくは別サービス要求メッセージをサービス要求元もしくは別サービス要求先に転送するために転送メッセージを生成する手段と、生成したメッセージをサービス要求元もしくは別サービス要求先に送信する手段と、システムの状態に応じて、判断基準となる情報を更新する手段とを含むことを特徴とする請求項１０記載の耐障害システム。
【請求項１２】
前記複数の実行ノードに通信経路を通じて接続された少なくとも１つの管理ノードを備え、前記管理ノードに前記障害管理手段を備えることを特徴とする請求項１乃至４の何れか１項に記載の耐障害システム。
【請求項１３】
前記複数の実行ノードのそれぞれに前記障害管理手段を備えることを特徴とする請求項１乃至４の何れか１項に記載の耐障害システム。
【請求項１４】
前記実行ノードに実マシンを用いることを特徴とする請求項１乃至１３の何れか１項に記載の耐障害システム。
【請求項１５】
前記実行ノードに仮想マシンを用いることを特徴とする請求項１乃至１３の何れか１項に記載の耐障害システム。
【請求項１６】
複数の実行ノードの環境情報を比較検証することで、異常な実行ノードを検出することを特徴とする耐障害システム。
【請求項１７】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードに通信経路を通じて接続され、前記複数のプログラムを並列実行中の前記複数の実行ノードから環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備えることを特徴とする管理ノード。
【請求項１８】
前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含むことを特徴とする請求項１７記載の管理ノード。
【請求項１９】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し且つ管理ノードとしても機能する実行ノードであって、前記１つ以上の他実行ノードおよび自ノードから、前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備えることを特徴とする実行ノード。
【請求項２０】
前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含むことを特徴とする請求項１９記載の実行ノード。
【請求項２１】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードおよび前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備える管理ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し、且つ、前記管理ノードの前記障害管理手段に対して、自ノードの環境情報を前記通信経路を通じて提供する情報提供手段を備えることを特徴とする実行ノード。
【請求項２２】
前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含むことを特徴とする請求項２１記載の実行ノード。
【請求項２３】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の他実行ノードに通信経路を通じて接続され、前記複数の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し、且つ、前記複数の他実行ノードのうち前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する管理ノードとして機能する他実行ノードの障害管理手段に対して、自ノードの環境情報を前記通信経路を通じて提供する情報提供手段を備えることを特徴とする実行ノード。
【請求項２４】
前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含むことを特徴とする請求項２３記載の実行ノード。
【請求項２５】
複数の実行ノードを備える計算機システムにおけるプログラム並列実行方法において、
（ａ）プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードで、前記プログラムを並列実行するステップ
（ｂ）前記複数の実行ノードの前記プログラムに同一の処理要求を処理させるステップ
（ｃ）前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出するステップ
（ｄ）前記複数の計算ノードで並列実行される前記複数のプログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップ
を含むことを特徴とするプログラム並列実行方法。
【請求項２６】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードで前記複数のプログラムが並列実行されているときに前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを備えることを特徴とする耐障害システムの障害検出装置。
【請求項２７】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードを備える計算機システムを、前記複数のプログラムが並列実行されているときに前記複数の実行ノードの環境情報を取得する情報取得手段、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段、として機能させる耐障害システムプログラム。
【請求項２８】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードに通信経路を通じて接続された計算機を、前記複数のプログラムを並列実行中の前記複数の実行ノードから環境情報を取得して比較し異常な実行ノードを検出する障害管理手段、として機能させる管理ノード用プログラム。
【請求項２９】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し且つ管理ノードとしても機能する計算機を、前記１つ以上の他実行ノードおよび自ノードから、前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段、として機能させる実行ノード用プログラム。
【請求項３０】
プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードおよび前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備える管理ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供する計算機を、前記管理ノードの前記障害管理手段に対して、自ノードの環境情報を前記通信経路を通じて提供する情報提供手段、として機能させる実行ノード用プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は実行ノードを複数備えた計算機システムに関し、特にプログラムレベルでの耐障害性能を高めた耐障害システムに関する。
【０００２】
【従来の技術】
耐障害システムは、構成要素の故障は避けられないという観点から、実行ノードの冗長化によって信頼性を高めた計算機システムである。例えば、後述する非特許文献１には、プロセッサとメモリからなる多数の実行ノードをバスに接続し、全ての処理を適当な大きさのタスクに分割して、各タスクを複数の実行ノードで同時に実行し、各タスクの実行結果から多数決によりシステムの出力を導出すると共に異常な実行ノードを検出する耐障害システムが示されている。
【０００３】
類似する耐障害システムは、特許文献１にも記載されている。但し、特許文献１に記載されるシステムでは、クライアントがそれぞれ異なる複数のサーバに対して処理要求を出し、クライアント自身が複数のサーバから返される結果から多数決によって正しい結果を求めている。また、クライアントから複数のサーバに対して、処理要求を送ると同時に浮動小数点演算やファイルアクセス等の試験手続きの実行要求を送信し、各サーバから返されてくる処理要求に対する結果だけでなく試験手続きの実行結果をも比較して正しい処理結果の導出と障害サーバの検出を行う方法が記載されている。
【０００４】
非特許文献１に記載される耐障害システムは、主にハードウェアレベルでの耐障害性の向上を狙ったものであり、実行ノードは全て同じ構成を有し、タスクは同一のプログラムにより各実行ノードで並列実行することを前提としている。このため、プログラムにバグがあると、並列実行された全てのプログラムに異常が発生する確率が高く、ソフトウェアレベルでの耐障害性の向上は難しい。大規模かつ複雑化の一途をたどるプログラムに、バグの存在しない完全性を求めることは、事実上困難であるため、プログラムレベルで耐障害性を持たせる必要がある。
【０００５】
プログラムにバグが存在していても、障害が外部に影響を与えない、ソフトウェアレベルでの耐障害性を向上させる従来技術として、Ｎバージョン方式やその改良方式、およびリカバリブロック方式が知られている。
【０００６】
Ｎバージョン方式は、後述する非特許文献２に記載されているように、複数の異なる開発者によってそれぞれ異なる手法で作成された同一の機能を達成する複数のバージョン（版）のプログラムを計算機システムで並列に実行し、複数のプログラムの出力結果から多数決によりシステムの出力を導出する方式である。
【０００７】
Ｎバージョンを改良した方式は、後述する特許文献２に記載されるように、１つのプログラムを機能単位で幾つかのモジュールに分割し、各モジュール毎に複数のバージョンの異なるモジュールを開発し、各モジュールを組み合わせることで、低い開発コストで、より多くのバージョンの異なるプログラムを開発する手法である。例えば、あるプログラムを｛Ａ、Ｂ、Ｃ｝の３つのモジュールに分割し、各モジュール毎に２種類ずつのバージョンの異なるモジュールＡ１とＡ２、Ｂ１とＢ２、Ｃ１とＣ２を開発し、これらを組み合わせて｛Ａ１、Ｂ１、Ｃ１｝、｛Ａ１、Ｂ１、Ｃ２｝、｛Ａ１、Ｂ２、Ｃ１｝、｛Ａ１、Ｂ２、Ｃ２｝、｛Ａ２、Ｂ１、Ｃ１｝、｛Ａ２、Ｂ１、Ｃ２｝、｛Ａ２、Ｂ２、Ｃ１｝、｛Ａ２、Ｂ２、Ｃ２｝と８種類のバージョンの異なるプログラムを開発すると、２つの異なるバージョンのプログラムを開発するのに近いコストで、８種類のバージョンの異なるプログラムを開発することができる。
【０００８】
一方、リカバリブロック方式は、後述する非特許文献３に記載されているように、プログラムの実行結果の正当性を検証する方式である。具体的には、Ｎバージョン方式と同じく、複数の異なるバージョンのプログラムを作成し、それぞれに順位づけを行う。第１順位のバージョンのプログラムの実行結果を、アクセプタンステスト（Ａｃｃｅｐｔａｎｃｅ  Ｔｅｓｔ：受け入れテスト）と呼ばれる予め定められた検証論理により検証し、検証結果が合格ならば、その実行結果を選択する。検証結果が不合格ならば、第２順位のバージョンのプログラムの実行結果を選択する。
【０００９】
このように、従来の耐障害システムは、複数の異なるバージョンのプログラムによる多重実行によって、システムとしての正しい処理結果の導出と障害ノードの検出を行っている。
【００１０】
他方、耐障害システムに限らず通常の計算機システムにおいても、ハートビート信号を用いて実行ノードが正常に動作しているかどうかを定期的に調べるｐｉｎｇ−ｐｏｎｇ方式などによって、システムに存在する個々のノードの障害発生の有無を検出しており、障害の発生したノードを停止するなどの障害対応処理を実施している。
【００１１】
【非特許文献１】
社団法人情報処理学会編，「新版  情報処理ハンドブック」，第１版，株式会社オーム社，平成７年１１月２５日、ｐ４５９−４６１
【非特許文献２】
「Ｆａｕｌｔ  ｔｏｌｅｒａｎｃｅ  ｂｙ  ｄｅｓｉｇｎ  ｄｉｖｅｒｓｉｔｙ：  Ｃｏｎｃｅｐｔｓ  ａｎｄ  ｅｘｐｅｒｉｍｅｎｔｓ」（Ａｖｉｚｉｅｎｉｓ，  Ａ．，  Ｋｅｌｌｙ，  Ｊ．Ｐ．Ｊ．，  ＩＥＥＥ  Ｃｏｍｐｕｔｅｒ  ｖｏｌ．１７，  ｎｏ．８，  ｐｐ：６７−８０，  １９８４．）
【非特許文献３】
「Ｄｉｓｔｒｉｂｕｔｅｄ  Ｅｘｅｃｕｔｉｏｎ  ｏｆ  Ｒｅｃｏｖｅｒｙ  Ｂｌｏｃｋｓ：  Ａｎ  Ａｐｐｒｏａｃｈ  ｆｏｒ  Ｕｎｉｆｏｒｍ  Ｔｒｅａｔｍｅｎｔ  ｏｆ  Ｈａｒｄｗａｒｅ  ａｎｄ  Ｓｏｆｔｗａｒｅ  Ｆａｕｌｔｓ  ｉｎ  Ｒｅａｌ−Ｔｉｍｅ  Ａｐｐｌｉｃａｔｉｏｎｓ」（Ｋ．  Ｈ．  Ｋｉｍ，  Ｈｏｗａｒｄ  Ｏ．  Ｗｅｌｃｈ，  ＩＥＥＥ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｃｏｍｐｕｔｅｒｓ，  ｖｏｌ．３８，  ｎｏ．５，  ｐｐ：６２６−６３６，  １９８９）
【特許文献１】
特開平７−３０６７９４号公報
【特許文献２】
特開平６−３４２３６９号公報
【００１２】
【発明が解決しようとする課題】
上述したようにプログラムレベルでの耐障害性能を高めた従来の耐障害システムにおいては、同等の機能を持つ複数のプログラムを並列実行し、それら複数のプログラムの実行結果から多数決方法やアクセプタンステストによる検証などによってシステムとしての正しい実行結果を導出すると同時に障害ノードを検出している。従って、最終的に実行結果が出揃うまで障害ノードを検出できず、障害ノードの速やかな検出が行えないという課題がある。ｐｉｎｇ−ｐｏｎｇ方式を用いて障害ノードの検出を並行して実施しても、全くｐｏｎｇ応答が無くなるノードダウンといった障害は検出できるが、処理結果が他のノードと相違することになるような異常な実行ノードを早期に検出することは困難である。
【００１３】
異常な実行ノードの早期検出が困難であると、異常な実行ノードの停止が遅れ、リソースの無駄な消費によって実行コストが上昇すると共に、異常な実行ノードが停止されずに動作し続けることによって他の正常な実行ノードに障害が波及し、耐障害性を劣化させる恐れがある。
【００１４】
本発明の目的は、複数のプログラムを複数の実行ノードで並列実行する耐障害システムにおいて、異常な実行ノードの速やかな検出を可能にすることにある。
【００１５】
本発明の別の目的は、異常な実行ノードが動作し続けることによる悪影響を速やかに除去することにある。
【００１６】
本発明の他の目的は、耐障害システムの開発コスト、実行コストを低減することにある。
【００１７】
【課題を解決するための手段】
本発明の耐障害システムは、複数の実行ノードの環境情報を比較検証することで、異常な実行ノードを検出することを基本とする。ここで、環境情報とは、プロセッサの使用状態、稼動中のプロセスの実行状態、メモリの使用状態、キャッシュの使用状態、仮想記憶の使用状態、スワップファイルの使用状態、ディスクの使用状態、入出力インタフェースの状態、ネットワークの状態、電源供給の有無、各デバイスの温度などの１つ又は複数あるいは全部の情報のことである。本発明の耐障害システムは、具体的には以下のような構成を備える。
【００１８】
本発明の第１の耐障害システムは、同一の実行環境上でバージョンが異なるプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備える。
【００１９】
本発明の第２の耐障害システムは、それぞれ異なる実行環境上で同一のプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備える。
【００２０】
本発明の第３の耐障害システムは、それぞれ異なる実行環境上でバージョンが異なるプログラムを実行することにより同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備える。
【００２１】
本発明の第４の耐障害システムは、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードと、前記複数のプログラムを並列実行中の前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段とを備える。
【００２２】
本発明の第５の耐障害システムは、第１乃至第４の耐障害システムにおいて、前記障害管理手段は、前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを含んで構成される。
【００２３】
本発明の第６の耐障害システムは、第５の耐障害システムにおいて、前記検出された異常な実行ノードを停止させる停止手段を備える。
【００２４】
本発明の第７の耐障害システムは、第６の耐障害システムにおいて、前記複数の実行ノードの安定性を判定する安定性判定手段と、前記安定性判定手段で前記複数の実行ノードが安定していると判定されたときに既定数を超える数の実行ノードを停止対象として選択する選択手段とを備え、前記停止手段は前記選択手段で選択された実行ノードを停止させるようにしている。
【００２５】
本発明の第８の耐障害システムは、第５、第６または第７の耐障害システムにおいて、異常な実行ノードが検出されたときに、新たな実行ノードを起動する追加手段を備える。
【００２６】
本発明の第９の耐障害システムは、第１乃至第８の耐障害システムにおいて、前記複数の実行ノード上の前記プログラムに同一の処理要求を分配する処理要求分配手段と、前記複数の実行ノードで実行された前記プログラムの処理結果からシステムとしての処理結果を導出する処理結果導出手段とを備える。
【００２７】
本発明の第１０の耐障害システムは、第９の耐障害システムにおいて、前記処理要求分配手段は、処理サービスの要求メッセージを受信する手段と、その要求メッセージをシステム内で処理するかどうか判定する手段と、処理すると判定したら、転送先の実行ノードに転送するためのメッセージを生成する手段と、生成したメッセージを実行ノードに送信する手段と、システムの状態に応じて、判断基準となる情報を更新する手段とを含んで構成される。
【００２８】
本発明の第１１の耐障害システムは、第１０の耐障害システムにおいて、前記処理結果導出手段は、処理サービスの応答もしくはデータベースアクセスなどの処理途中の別サービス要求メッセージを受信する手段と、その応答メッセージもしくは別サービス要求メッセージをどのように処理するか判定し、判定に基づきメッセージの選択もしくは生成を行う手段と、応答メッセージもしくは別サービス要求メッセージをサービス要求元もしくは別サービス要求先に転送するために転送メッセージを生成する手段と、生成したメッセージをサービス要求元もしくは別サービス要求先に送信する手段と、システムの状態に応じて、判断基準となる情報を更新する手段とを含んで構成される。
【００２９】
本発明の第１２の耐障害システムは、第１乃至第４の耐障害システムにおいて、前記複数の実行ノードに通信経路を通じて接続された少なくとも１つの管理ノードを備え、前記管理ノードに前記障害管理手段を備える。
【００３０】
本発明の第１３の耐障害システムは、第１乃至第４の耐障害システムにおいて、前記複数の実行ノードのそれぞれに前記障害管理手段を備える。
【００３１】
本発明の第１４の耐障害システムは、第１乃至第１３の耐障害システムにおいて、前記実行ノードに実マシンを用いる。
【００３２】
本発明の第１５の耐障害システムは、第１乃至第１３の耐障害システムにおいて、前記実行ノードに仮想マシンを用いる。
【００３３】
本発明の第１の管理ノードは、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードに通信経路を通じて接続され、前記複数のプログラムを並列実行中の前記複数の実行ノードから環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備える。
【００３４】
本発明の第２の管理ノードは、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し且つ管理ノードとしても機能する実行ノードであって、前記１つ以上の他実行ノードおよび自ノードから、前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備える。
【００３５】
本発明の第１の実行ノードは、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する１つ以上の他実行ノードおよび前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する障害管理手段を備える管理ノードに通信経路を通じて接続され、前記１つ以上の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し、且つ、前記管理ノードの前記障害管理手段に対して、自ノードの環境情報を前記通信経路を通じて提供する情報提供手段を備える。
【００３６】
本発明の第２の実行ノードは、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の他実行ノードに通信経路を通じて接続され、前記複数の他実行ノードとプログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が相違するが同等の機能を提供し、且つ、前記複数の他実行ノードのうち前記複数のプログラムを並列実行中の実行ノードの環境情報を取得して比較し異常な実行ノードを検出する管理ノードとして機能する他実行ノードの障害管理手段に対して、自ノードの環境情報を前記通信経路を通じて提供する情報提供手段を備える。
【００３７】
また、本発明のプログラム並列実行方法は、複数の実行ノードを備える計算機システムにおけるプログラム並列実行方法において、（ａ）プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードで、前記プログラムを並列実行するステップ、（ｂ）前記複数の実行ノードの前記プログラムに同一の処理要求を処理させるステップ、（ｃ）前記複数の実行ノードの環境情報を取得して比較し異常な実行ノードを検出するステップ、（ｄ）前記複数の計算ノードで並列実行される前記複数のプログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップ、を含んで構成される。
【００３８】
また、本発明の耐障害システムの障害検出装置は、プログラムのバージョン及び前記プログラムを実行する実行環境の少なくとも一方が互いに相違するが同等の機能を提供する複数の実行ノードで前記複数のプログラムが並列実行されているときに前記複数の実行ノードの環境情報を取得する情報取得手段と、取得された前記複数の実行ノードの環境情報を比較して異常な実行ノードを検出する比較検証手段とを備える。
【００３９】
【作用】
全く同一の実行環境を持つ複数の実行ノード上で全く同一のプログラムを並列実行させた場合、各実行ノードのプロセッサの使用状態やメモリの使用状態などの環境情報はほぼ全く等しくなる。
【００４０】
これに対して、第１の耐障害システムのように、全く同一の実行環境を持つ複数の実行ノード上で、同等の機能を持つが異なるバージョンのプログラムを並列実行させた場合、異常となる実行ノードが発生していない状態では、各実行ノードの環境情報の違いはプログラムのバージョンの相違に起因する差異に過ぎないが、若し、何れかの実行ノードが異常になると、その異常になった実行ノードの環境情報だけが他の正常な実行ノードの環境情報と、プログラムのバージョンの違いに起因する差以上に明確に差が生じる。従って、プログラムを並列実行中の複数の実行ノードの環境情報を取得して比較することにより、実行結果が出揃う前に異常なノードの検出が行える。
【００４１】
また、第２の耐障害システムのように、それぞれ異なる実行環境を持つ複数の実行ノード上で、同一のプログラムを並列実行させた場合、異常となる実行ノードが発生していない状態では、各実行ノードの環境情報の違いは実行環境の相違に起因する差異に過ぎないが、若し、何れかの実行ノードが異常になると、その異常になった実行ノードの環境情報だけが他の正常な実行ノードの環境情報と、実行環境の違いに起因する差以上に明確に差が生じる。従って、プログラムを並列実行中の複数の実行ノードの環境情報を取得して比較することにより、実行結果が出揃う前に異常なノードの検出が行える。
【００４２】
また、第３の耐障害システムのように、それぞれ異なる実行環境を持つ複数の実行ノード上で、それぞれ異なるバージョンのプログラムを並列実行させた場合、異常となる実行ノードが発生していない状態では、各実行ノードの環境情報の違いはプログラムのバージョンおよび実行環境の相違に起因する差異に過ぎないが、若し、何れかの実行ノードが異常になると、その異常になった実行ノードの環境情報だけが他の正常な実行ノードの環境情報と、プログラムのバージョンおよび実行環境の違いに起因する差以上に明確に差が生じる。従って、プログラムを並列実行中の複数の実行ノードの環境情報を取得して比較することにより、実行結果が出揃う前に異常なノードの検出が行える。
【００４３】
また、第４の耐障害システムのように、プログラムのバージョン及び実行環境の少なくとも一方が互いに相違する複数の実行ノードで前記複数のプログラムを並列実行させた場合、異常となる実行ノードが発生していない状態では、各実行ノードの環境情報の違いはプログラムのバージョンや実行環境の相違に起因する差異に過ぎないが、若し、何れかの実行ノードが異常になると、その異常になった実行ノードの環境情報だけが他の正常な実行ノードの環境情報と、プログラムのバージョンおよび／または実行環境の違いに起因する差以上に明確に差が生じる。従って、プログラムを並列実行中の複数の実行ノードの環境情報を取得して比較することにより、実行結果が出揃う前に異常なノードの検出が行える。
【００４４】
【発明の第１の実施の形態】
図１参照すると、本発明の第１の実施の形態にかかる耐障害システムは、複数の実行ノード１１０−１〜１１０−ｎと、これら複数の実行ノード１１０−１〜１１０−ｎを管理する少なくとも１つの管理ノード１２０と、これら複数の実行ノード１１０−１〜１１０−ｎおよび管理ノード１２０を互いに通信可能に接続する通信経路１３０とを含んで構成される。
【００４５】
実行ノード１１０−１〜１１０−ｎは、プログラム１１１−１〜１１１−ｎと、そのプログラム１１１−１〜１１１−ｎを実行する実行環境１１２と、自ノードの環境情報を管理ノード１２０に提供する情報提供部１１６とを有する。
【００４６】
本実施の形態において、各実行ノード１１０−１〜１１０−ｎの実行環境１１２はすべて同一であり、少なくとも１つの演算部１１３と記憶部１１４と入出力部１１５とを備えている。情報提供部１１６は、自ノードにおける実行環境１１２が備える演算部１１３や記憶部１１４や入出力部１１５などの状態を示す環境情報を管理ノード１２０に提供する。
【００４７】
プログラム１１１−１〜１１１−ｎは、管理ノード１２０から与えられる処理要求を入力して要求される処理を実行し、その処理結果を管理ノード１２０に返却するアプリケーションプログラムである。本実施の形態においては、各実行ノード１１０−１〜１１０−ｎのプログラム１１１−１〜１１１−ｎは、同等の機能を提供するプログラムであるが、前述したＮバージョン方式で使用されるプログラムのように、互いにバージョン（版）が相違している。
【００４８】
管理ノード１２０は、異常な実行ノードの検出などシステムの障害を検出する障害検出部１２４と、各実行ノード１１０−１〜１１０−ｎのプログラム１１１−１〜１１１−ｎに同一の処理要求を分配して並列に処理させる処理要求分配処理、障害検出部１２４で検出された障害に対応する障害対応処理、プログラム１１１−１〜１１１−ｎの処理結果からシステムとしての処理結果を導出する処理結果導出処理など、システム全体の実行状態を管理する実行管理部１２５と、種々のデータを記憶する記憶部１２９とを備える。特に本実施の形態では、検出した異常な実行ノードを外部に通知する通知手段１２３が実行管理部１２５に設けられている。
【００４９】
障害検出部１２４は、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２が備える演算部１１３、記憶部１１４および入出力部１１５などの状態を示す環境情報を、各実行ノード１１０−１〜１１０−ｎの情報提供部１１６から取得して記憶部１２９に記憶する情報取得手段１２１と、この情報取得手段１２１によって取得された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２の環境情報を記憶部１２９から読み出して比較検証し、その検証結果を記憶部１２９に記憶する比較検証手段１２２とを含んで構成される。
【００５０】
通信経路１３０は、バス、シリアル、パラレル、ＬＡＮ、無線ＬＡＮ、インターネット、公衆回線などの任意の通信回線であり、また複数を組み合わせた多重化通信回線であっても良い。
【００５１】
ここで、個々の実行ノード１１０−１〜１１０−ｎおよび管理ノード１２０は、例えば１台のパーソナルコンピュータ（ＰＣ）や大型計算機の１つのセルなど、物理的に存在する実マシンであっても良いし、仮想マシンであっても良い。また、全ての実行ノード１１０−１〜１１０−ｎおよび管理ノード１２０を、全て実マシンで実現しても良いし、全て仮想マシンで実現しても良く、一部の実行ノードは仮想マシンで、残りの実行ノードは実マシンで実現する如く、仮想マシンと実マシンとが混在していても良い。
【００５２】
仮想マシンは、図２の仮想マシン２１１に示されるように、物理的な計算機２１２とその上で実行される仮想マシンモニタと呼ばれる制御ソフトウェア２１３とで実現される仮想マシン実行環境２１４を利用して、ソフトウェアで実現される計算機であり、計算機シミュレータあるいは計算機エミュレータとも呼ばれる。仮想マシンは、実マシンと論理的には全く同じ動作をする。同じ仮想マシン実行環境２１４上に１つまたは複数の仮想マシン２１１を実現することができ、各々の仮想マシン２１１の機器構成は、その仮想マシンを実現している計算機２１２上にあるファイルで指定される。仮想マシン２１１が備える演算部や記憶部や入出力部は仮想資源と呼ばれる。制御ソフトウェア２１３の最も基本的な機能は、仮想マシン２１１が備える仮想資源と計算機２１２が備える実資源とのマッピング機能である。このように仮想マシンはソフトウェアで実現されているので、必要な時にのみ存在する。つまり、必要な時に仮想マシンは生成され、不要となると消去される。そのため、実行ノード１１０−１〜１１０−ｎに仮想マシンを使用すると、多数の計算機および機器を常時用意する必要がなく、コストの削減が可能となる。なお、実行ノード１１０−１〜１１０−ｎのうちの全部または一部を仮想マシン２１１で実現する場合、それらは同じ仮想マシン実行環境２１４上に生成されたものであっても良いし、別の仮想マシン実行環境２１４上に生成されたものであっても良い。
【００５３】
次に、図３のフローチャートを参照して、本実施の形態の耐障害システムにおけるシステム起動時の動作を説明する。
【００５４】
システムが起動されると、複数の実行ノード１１０−１〜１１０−ｎが同じ実行環境１１２でバージョンの異なるプログラム１１１−１〜１１１−ｎが並列に実行されるように、各実行ノード１１０−１〜１１０−ｎに実行環境１１２およびプログラム１１１−１〜１１１−ｎの設定が行われる（Ｓ１０１〜Ｓ１０４）。具体的には、記憶部１２９には各実行ノード１１０−１〜１１０−ｎ毎の実行環境設定データ、並列実行対象となるプログラム１１１−１〜１１１−ｎ、システム起動時に起動すべき実行ノードの数と起動対象とする実行ノードの指定情報などが予め記憶されている。管理ノード１２０の実行管理部１２５は、内部の変数Ｎを１に初期設定し（Ｓ１０１）、１番目の実行ノード１１０−１に注目し、その実行ノード１１０−１の実行環境設定データ等を記憶部１２９から読み込んで、実行環境１１２を設定する（Ｓ１０２）。実行管理部１２５は、１つの実行ノードに対する実行環境１１２の設定を終えると、変数Ｎを１加算し（Ｓ１０４）、２番目の実行ノード１１０−２に対して同様の処理を繰り返す。これを、記憶部１２９に予め設定されたシステム起動時に起動すべき既定数の全ての実行ノードに対する処理が終るまで（Ｓ１０３でＹＥＳ）、繰り返す。システム起動時に起動すべき実行ノードの個数を定める規定数としては、３以上の値が使用される。ステップＳ１０２の処理例を以下に示す。
【００５５】
（ａ）実行ノード１１０−ｉ（ｉ＝１〜ｎ）が実マシンの場合
実行管理部１２５は、実行ノード１１０−ｉに対して遠隔操作などで電源オンの命令を送信する。この命令によって起動した実行ノード１１０−ｉは、起動途中で、自身の実行環境を実行管理部１２５に問い合せる。実行管理部１２５は、記憶部１２９から、その実行ノード１１０−ｉの実行環境設定データを読み出し、応答する。実行ノード１１０−ｉは、応答された実行環境設定データを用いて、自ノード１１０−ｉの実行環境１１２を設定する。具体的には、例えば実行ノード１１０−ｉが一般的なＰＣの場合、実行環境の設定をＢＩＯＳに保存して再起動し、再起動後、プログラム１１１−ｉの処理を開始させる。
【００５６】
（ｂ）実行ノード１１０−ｉ（ｉ＝１〜ｎ）が仮想マシンの場合
仮想マシンの実行環境は、その仮想マシンを実現している実マシン上にあるファイルで指定されるため、実行管理部１２５は、実行ノード（仮想マシン）１１０−ｉを実現している実マシン上の該当するファイルを、記憶部１２９から読み出した当該実行ノード用の実行環境設定データで更新し、その仮想マシンのプロセスを起動する。起動後、その実行ノード（仮想マシン）がプログラム１１１−ｉの処理を開始する。
【００５７】
他の方法として、同じ実行環境１１２を持つ実行ノードを予め多数用意しておき、実行管理部１２５がどの実行ノードを活性化させるかを制御することにより、同じ実行環境１１２の複数の実行ノード１１０−１〜１１０−ｎを起動するようにしても良い。この場合、実行ノードが実マシンのときは、遠隔操作による電源オンの命令の送信により起動され、仮想マシンのときはそのプロセスの起動命令の送信により行われる。
【００５８】
各実行ノード１１０−１〜１１０−ｎの実行環境の設定後、システムは、各実行ノード１１０−１〜１１０−ｎでプログラム１１１−１〜１１１−ｎを並列実行する通常運用状態となる。
【００５９】
通常運用状態では、実行管理部１２５および障害検出部１２４においてシステムの状態を取得し、取得したシステムの状態に応じた処理を行う。実行管理部１２５が取得するシステムの状態は、システム全体の終了命令が発行されたかどうか、プログラム１１１−１〜１１１−ｎで処理すべき新たな処理要求が発生したかどうか、プログラム１１１−１〜１１１−ｎで処理要求に対する処理が終了したかどうかなどの情報である。また、障害検出部１２４が取得するシステムの状態は、各実行ノード１１０−１〜１１０−ｎにおける情報提供部１１６が提供する、実行環境１１２の状態を示す環境情報である。取得された環境情報は記憶部１２９に一旦記憶され、その後読み出されて異常ノードの検出に用いられる。この障害関連処理の詳細については後述する。
【００６０】
システム全体の終了命令が発行された場合、終了処理が行われ、すべての実行ノードが停止する。システム全体の終了命令は、システム運用者からの入力、タイマーなどのイベントをトリガーとして発行される。システム全体の終了命令は、管理ノード１２０の実行管理部１２５で検出され、各実行ノード１１０−１〜１１０−ｎに通知される。具体的な制御命令は、記憶部１２９に記憶されている各実行ノード１１０−１〜１１０−ｎの実行環境設定データに応じて、実行管理部１２５から発行される。これにより、ＵＰＳ装置などの電源装置を介して電源断の処理を行う、主記憶や仮想記憶の状態を保持したまま停止するＳＴＲ（Ｓｕｓｐｅｎｄ  ｔｏ  ＲＡＭ）を行う、などの方法で各実行ノード１１０−１〜１１０−ｎが停止する。
【００６１】
新たな処理要求が発生した場合、管理ノード１２０の実行管理部１２５は、その処理要求を複数の実行ノード１１０−１〜１１０−ｎ上のプログラム１１１−１〜１１１−ｎに処理させるための処理分配処理を実行する。また、プログラム１１１−１〜１１１−ｎで処理要求に対する処理が終了した場合、実行管理部１２５は、システムとしての処理結果を導出する処理を行う。この処理は、例えば、異常ノードとして検出された実行ノード以外の実行ノードのプログラムの処理結果から多数決法によってシステムとしての処理結果を求める手法を使って行うことができる。また、数値計算の結果のような明確な実行結果が無い、あるいは得られない、あるいは得るのが困難なプログラム１１１−１〜１１１−ｎの場合、多数決法の適用は困難なので、異常ノードとして検出された実行ノード以外の複数の実行ノードのプログラムで得られた処理結果から、任意の１つをシステムとしての処理結果として選択する手法などを使って、システムとしての処理結果を導出する。勿論、これらの手法に限定されず、任意の手法を用いることが可能である。
【００６２】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図４のフローチャートを参照して説明する。
【００６３】
複数の実行ノード１１０−１〜１１０−ｎにおいてプログラム１１１−１〜１１１−ｎが並列実行されているとき、障害検出部１２４の情報取得手段１２１は、定期的に、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報を通信経路１３０を通じて各実行ノード１１０−１〜１１０−ｎの情報提供部１１６から取得し、それを記憶部１２９の環境情報記憶域に記憶する（ステップＳ２０１）。
【００６４】
以下、管理ノード１２０が各実行ノード１１０−１〜１１０−ｎから取得する環境情報について詳細に説明する。
【００６５】
取得する環境情報の例を、以下に示す。
（ａ）プロセッサの使用状態
（ｂ）稼動中のプロセスの実行状態
（ｃ）メモリの使用状態
（ｄ）キャッシュの使用状態
（ｅ）仮想記憶の使用状態
（ｆ）スワップファイルの使用状態
（ｇ）ディスクの使用状態
（ｈ）入出力インタフェースの状態
（ｉ）ネットワークの状態
（ｊ）各デバイスの温度
【００６６】
上記のｂはソフトウェアにかかる環境情報の例であり、それ以外のａ、ｃ〜ｊはハードウェアにかかる環境情報の例である。本発明においては、前記ａ〜ｊの何れか１種類だけを取得するようにしても良いし、前記ａ〜ｊの内の任意の複数種類あるいは全部を取得するようにしても良い。前記ｂだけを取得する構成では、ソフトウェアにかかる環境情報だけを取得する構成になり、前記ａ、ｃ〜ｊの少なくとも１つを取得する構成では、ハードウェアにかかる環境情報だけを取得する構成になる。勿論、各実行ノードの電源供給の有無や消費電力など、前記ａ〜ｊに例示した以外の環境情報を取得するようにしても良い。
【００６７】
前記ａ〜ｊの環境情報を取得する方法としては、次の２つの方法がある。
【００６８】
◇環境情報の取得方法１
管理ノード１２０の情報取得手段１２１から通信経路１３０経由で各実行ノード１１０−１〜１１０−ｎにログインし、コマンドラインより様々な調査コマンドを発行してその結果を解析したり、あるいは／ｐｒｏｃ以下の仮想ファイルシステムを調べる方法である。この場合、実行ノード１１０−１〜１１０−ｎの情報提供部１１６は、管理ノード１２０からの調査コマンドを受信して実行し結果を返すコマンド実行部として実現される。
【００６９】
◇環境情報の取得方法２
実行ノード１１０−１〜１１０−ｎの情報提供部１１６を、前記ａ〜ｊの環境情報を取得するハードウェアデバイスであるサービスプロセッサで実現し、管理ノード１２０の情報取得部１２１が各実行ノード１１０−１〜１１０−ｎのサービスプロセッサから環境情報を取得する。
【００７０】
以下、前記ａ〜ｊの環境情報の詳細とその取得方法の詳細について説明する。なお、取得方法としては前記取得方法１を使用し、ＬｉｎｕｘＯＳ（Ｒｅｄｈａｔ７．３）が各ノードに実装されている場合を想定する。
【００７１】
（ａ）プロセッサの使用状態
（ア）ロードアベレージ（プロセッサの使用率）
これは、ｕｐｔｉｍｅコマンド、あるいはｔｏｐコマンドを実行して結果を解析することで取得できる。
（イ）プロセッサ上で動いているプロセス数
これは、ｐｓコマンド、あるいはｔｏｐコマンドを実行して結果を解析することで取得できる。
【００７２】
（ｂ）稼動中のプロセスの実行状態
（ア）プロセスの実行状態（実行状態（ｒｕｎｎｉｎｇ）、割込み可能な休眠状態（ｓｌｅｅｐｉｎｇ  ｉｎ  ａｎ  ｉｎｔｅｒｒｕｐｔｉｂｌｅ  ｗａｉｔ）、割込み不可な待機状態（ｗａｉｔｉｎｇ  ｉｎ  ｕｎｉｎｔｅｒｒｕｐｔｉｂｌｅ  ｄｅｓｋ  ｓｌｅｅｐ）、親プロセスが死んでいるゾンビ状態（ｚｏｍｂｉｅ）、トレースされている状態（ｔｒａｃｅｄ）、シグナルにより停止している状態（ｓｔｏｐｐｅｄ）、ページング中（ｐａｇｉｎｇ））
（イ）プロセスが使用しているメモリ領域
（ウ）プロセスのロードアベレージ
（エ）プロセスの実行時間（ｕｓｅｒ  ｍｏｄｅ／ｋｅｒｎｅｌ  ｍｏｄｅ）
（オ）プロセスの実行優先度（ｐｒｉｏｒｉｔｙ）
（カ）プロセスのメモリ消費量
（キ）プロセスに割り当てられた仮想メモリのサイズ
（ク）プロセスのページフォールト数（ｍａｊｏｒ  ｆａｕｌｔ／ｍｉｎｏｒ  ｆａｕｌｔ）
（ケ）プロセスからのディスクの読み込み、書き込み回数／サイズ
（コ）シグナルのビットマップ
これらは、プロセスＩＤがＸＸＸＸとすると、／ｐｒｏｃ／ｘｘｘｘ／ｓｔａｔ、／ｐｒｏｃ／ｘｘｘｘ／ｓｔａｔｕｓ、／ｐｒｏｃ／ｘｘｘｘ／ｓｔａｔｍ以下の仮想ファイルを参照することで取得できる。
【００７３】
（ｃ）メモリの使用状態
（ア）メモリのサイズ
（イ）メモリの使用量
これらは、ｆｒｅｅコマンドあるいはｔｏｐコマンドを実行し、結果を解析することで取得できる。また、／ｐｒｏｃ／ｍｅｍｉｎｆｏを調べることで取得できる。
【００７４】
（ｄ）キャッシュの使用状態
（ア）キャッシュのサイズ
（イ）キャッシュヒット率
これらは、ｆｒｅｅコマンドを実行して結果を解析することで取得できる。また、／ｐｒｏｃ／ｍｅｍｉｎｆｏを参照することで取得できる。
【００７５】
（ｅ）仮想記憶の使用状態
（ア）仮想記憶のサイズ
（イ）仮想記憶の使用量
これらは、ｆｒｅｅコマンド、あるいはｔｏｐコマンドを実行して結果を解析することで取得できる。また、／ｐｒｏｃ／ｍｅｍｉｎｆｏを参照することで取得できる。
【００７６】
（ｆ）スワップファイルの使用状態
（ア）スワップのサイズ
これは、ｆｒｅｅコマンド、あるいはｔｏｐコマンドを実行して結果を解析することで取得できる。また、／ｐｒｏｃ／ｍｅｍｉｎｆｏを参照することで取得できる。
（イ）スワップされたページ数
これらは、プロセス毎のページフォールト数の合計値として求めることができる。
【００７７】
（ｇ）ディスクの使用状態
（ア）ディスクのサイズ
（イ）ディスクの使用量
これらは、ｄｆコマンドを実行して結果を解析することで取得できる。
【００７８】
（ｈ）入出力インタフェースの状態
（ア）各デバイス（ＩＤＥ、ＳＣＳＩ、ＰＣＩ、ＮＩＣ等）の有無
（イ）各デバイスの状態（正常に動作しているか）
これらは、ｌｓｐｃｉコマンドを実行して結果を解析することで取得できる。また、ＮＩＣの場合、ｉｆｃｏｎｆｉｇコマンドを実行すると、より詳細な情報が得られる。
【００７９】
（ｉ）ネットワークの状態
（ア）接続の有無
（イ）送受信パケット数
これらは、ｉｆｃｏｎｆｉｇコマンドの実行結果を解析することで取得できる。
【００８０】
（ｊ）各デバイスの温度
（ア）プロセッサの温度
これは、ＢＩＯＳが対応していれば／ｐｒｏｃ／ｃｐｕｉｎｆｏを参照して取得できる。なお、他にも電源装置やマシン内部の温度も取得するようにしてよい。
【００８１】
続いて、障害検出部１２４の比較検証手段１２２の動作を説明する。障害検出部１２４の比較検証手段１２２は、記憶部１２９に記憶された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報に基づいて、大多数の他の実行ノードの環境情報と明確に相違する環境情報となっている実行ノードを異常な実行ノードとして検出する（Ｓ２０２）。
【００８２】
例えば、プロセスの異常終了が多い異常な実行ノードは、他の正常な実行ノードに比べて、実行状態がゾンビのプロセスが増える。また、プログラムが無限ループなどに陥って暴走した異常な実行ノードは、他の正常な実行ノードに比べて、プロセッサのロードアベレージが高くなる。プロセスのフォークが無限ループ状態になった異常な実行ノードは、他の正常な実行ノードに比べて、プロセス数が増える。メモリリークのバグが発生した異常な実行ノードは、他の正常な実行ノードに比べて、メモリ使用量、仮想記憶使用量、スワップ数が増える。異常によってログが増えすぎた異常な実行ノードは、他の正常な実行ノードに比べて、ディスク使用量が多くなる。ワーム型ウィルスに感染した異常な実行ノードは、他の正常な実行ノードに比べて、ネットワークの送信パケットが増える。プロセッサが熱暴走した異常な実行ノードは、他の正常な実行ノードに比べて、プロセッサの温度が上がる。比較検証手段１２２は、このような経験則を利用して異常ノードを検出する。具体的には、比較検証手段１２２は、多数決法あるいは外れ値検出法を用いて比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する。なお、比較検証の手法については、これら２つの手法に限定するものではない。
【００８３】
ここで、多数決法とは、多数決論理に基づき、大多数を正常、少数を異常とする手法である。また、外れ値検出法とは、例えば”Ｄｅｔｅｃｔｉｎｇ  ｃｅｌｌｕｌａｒ  ｆｒａｕｄ  ｕｓｉｎｇ  ａｄａｐｔｉｖｅ  ｐｒｏｔｏｔｙｐｅｓ”（Ｐ．  Ｂｕｒｇｅ，  Ｊ．  Ｓｈａｗｅ−Ｔａｙｌｏｒ，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＡＩ  Ａｐｐｒｏａｃｈｅｓ  ｔｏ  Ｆｒａｕｄ  Ｄｅｔｅｃｔｉｏｎ  ａｎｄ  Ｒｉｓｋ  Ｍａｎａｇｅｍｅｎｔ，  ｐｐ：９−１３，  １９９７）や”Ｏｎ−ｌｉｎｅ  Ｕｎｓｕｐｅｒｖｉｓｅｄ  Ｏｕｌｔｌｉｅｒ  Ｄｅｔｅｃｔｉｏｎ  Ｕｓｉｎｇ  Ｆｉｎｉｔｅ  Ｍｉｘｔｕｒｅｓ  ｗｉｔｈ  Ｄｉｓｃｏｕｎｔｉｎｇ  Ｌｅａｒｎｉｎｇ  Ａｌｇｏｒｉｔｈｍｓ”（Ｋ．  Ｙａｍａｎｉｓｈｉ  ｅｔ．  ａｌ．，  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ６ｔｈ  ＡＣＭ  ＳＩＧＫＤＤ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｋｎｏｗｌｅｄｇｅ  Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｄａｔａ  Ｍｉｎｉｎｇ，  ＡＣＭ  Ｐｒｅｓｓ，  ｐｐ：３２０−３２４，  ２０００）に記載されている統計的外れ値検出のように、データセットにおいて、大多数のデータが従う確率分布から外れたデータ、すなわち発生しにくいデータを「統計的外れ値」として異常と同定する手法である。ここで、環境情報には上記ａ〜ｊのように種類の異なる情報が含まれているため、同じ種類どうしの比較に加えて、総合的な比較も行う。具体的には、例えば、各環境情報に重みを付けておき、外れ値の度合い×重みの総和で、総合的な判定を行う。重みの付け方は、経験に基づき予め手動で設定する、過去の障害履歴を参照して設定する等の任意の方法が可能である。
【００８４】
比較検証手段１２２による検証結果は記憶部１２９に記憶される。実行管理部１２５は、記憶部１２９に記憶された検証結果を参照して異常ノードが検出されたかどうかを判定し、異常ノードが検出されていれば、障害対応処理の一環として、検出された異常な実行ノードを電子メールなどの方法で予め定められたユーザに通知する（Ｓ２０３）。勿論、通知先はユーザだけでなく、例えばこの通知結果をもって何らかの制御を行うシステムでも構わない。また、異常ノードが検出された場合にのみ結果を通知するだけでなく、比較検証の結果を常に通知しても構わない。
【００８５】
情報取得手段１２１による各実行ノード１１０−１〜１１０−ｎからの環境情報の取得とその取得された環境情報に基づく比較検証手段１２２により比較検証は、少なくとも各実行ノード１１０−１〜１１０−ｎに処理要求が分配されてから結果が出るまでの期間中、定期的に繰り返される。繰り返しの周期は、短く設定するほど障害を早期に検出でき高い耐障害性を確保できるが、周期が短くなると処理量が増大するので、実際は、両者を考慮した周期が設定される。また、各実効ノード１１０−１〜１１０−ｎの実行結果が出揃った場合には、従来のＮバージョン方式のように実行結果だけを比較検証して異常ノードを検出するようにしても良いし、環境情報と実行結果の双方を比較検証して異常ノードを検出するようにしても良い。
【００８６】
このように本実施の形態では、プログラムを並列実行中の各実行ノードから取得した環境情報を比較検証することで異常な実行ノードを検出するため、最終的な実行結果が出揃う前、つまり障害が実行結果として発現する前に速やかに異常ノードを検出することが可能となる。また、実行結果を取得しなくても検出できるため、数値計算の結果のような明確な実行結果が無い、あるいは得られない、あるいは得るのが困難なプログラムに対しても容易に適用できる。更に、予め異常値を検出する閾値を固定して異常を検出する手法に比べ、柔軟性が高く、想定していない障害も検出できる。
【００８７】
【発明の第２の実施の形態】
図５を参照すると、本発明の第２の実施の形態にかかる耐障害システムは、管理ノード５２０の実行管理部５２５が図１の通知手段１２３の代わりに、異常な実行ノードを停止させる停止手段５２６を備えている点で第１の実施の形態と構成が異なり、その他の構成は第１の実施の形態と同じである。また、本実施の形態にかかる耐障害システムの動作は、障害関連処理を除いて第１の実施の形態と同じである。
【００８８】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図６のフローチャートを参照して説明する。
【００８９】
システム起動後、複数の実行ノード１１０−１〜１１０−ｎにおいてプログラム１１１−１〜１１１−ｎが並列実行される通常運用状態になると、障害検出部１２４は、プログラム１１１−１〜１１１−ｎを実行している実行ノード１１０−１〜１１０−ｎの個数が予め定められた既定数Ｘ以上であるかどうかを判定し（Ｓ６０１）、既定数Ｘ以上であれば、情報取得手段１２１により、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報を通信経路１３０を通じて取得し、それを記憶部１２９の環境情報記憶域に記憶する（ステップＳ６０２）。取得する環境情報は第１の実施の形態におけるものと同じである。なお、規定数Ｘとしては、多数決論理により異常ノードあるいは正常ノードが判明する最小の値「３」を用いるが、３より大きな値にしても良い。
【００９０】
次に、障害検出部１２４の比較検証手段１２２は、記憶部１２９に記憶された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２の環境情報を読み込み、第１の実施の形態と同様に多数決法あるいは外れ値検出法を用いて比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する（Ｓ６０３）。比較検証手段１２２による検証結果は記憶部１２９に記憶される。
【００９１】
次に、実行管理部５２５は、記憶部１２９から検証結果を読み出し、異常と判定された実行ノードがあるかどうかを判定し（Ｓ６０４）、異常と判定された実行ノードがある場合、停止手段５２６により、その異常な実行ノードを停止させる（Ｓ６０５）。実行ノードを停止させる制御命令は、記憶部１２９に保持されたその実行ノードの環境設定データに応じて、通信経路１３０経由で停止手段５２６から発行される。これにより、異常な実行ノードが実マシンの場合、例えば電源装置を介して電源断の処理が行われ、仮想マシンの場合、仮想マシンを実現しているプロセスが停止する。
【００９２】
以上のような環境情報の取得と比較検証、異常ノードの停止処理は、プログラム１１１−１〜１１１−ｎを実行している実行ノード１１０−１〜１１０−ｎの個数が予め定められた既定数Ｘ以上である間、定期的に実行される。そして、異常ノードの停止によって、プログラム１１１−１〜１１１−ｎを実行している実行ノード１１０−１〜１１０−ｎの個数が予め定められた既定数Ｘより少なくなると（Ｓ６０１でＮＯ）、図６に示される処理を停止する。
【００９３】
このように本実施の形態によれば、第１の実施の形態で得られる効果に加えて、異常と判定された実行ノードを停止するため、無駄なリソースの消費がなく、実行コストを低減できる。また、障害が実行結果として発現する前に異常ノードの検出とその停止が行えるため、最終的な実行結果が出揃った時点で異常ノードの検出とその停止を行う場合に比べて、実行コストの削減効果が高く、さらに異常ノードが動作し続けることによる正常ノードへの障害の波及を防止することができる。
【００９４】
【発明の第３の実施の形態】
図７を参照すると、本発明の第３の実施の形態にかかる耐障害システムは、管理ノード５２０の実行管理部５２５が図１の通知手段１２３の代わりに、新たな実行ノードを追加する追加手段９２９を備えている点で第１の実施の形態と構成が異なり、その他の構成は第１の実施の形態と同じである。また、本実施の形態にかかる耐障害システムの動作は、障害関連処理を除いて第１の実施の形態と同じである。
【００９５】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図８のフローチャートを参照して説明する。システム起動後、複数の実行ノード１１０−１〜１１０−ｎにおいてプログラム１１１−１〜１１１−ｎが並列実行される通常運用状態になると、障害検出部１２４の情報取得手段１２１は、定期的に、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報を通信経路１３０を通じて各実行ノード１１０−１〜１１０−ｎの情報提供部１１６から取得し、それを記憶部１２９の環境情報記憶域に記憶する（ステップＳ７０１）。取得する環境情報は第１の実施の形態におけるものと同じである。
【００９６】
次に、障害検出部１２４の比較検証手段１２２は、記憶部１２９に記憶された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２の環境情報を読み込み、第１の実施の形態と同様に多数決法あるいは外れ値検出法を用いて比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する（Ｓ７０２）。比較検証手段１２２による検証結果は記憶部１２９に記憶される。
【００９７】
次に、実行管理部５２５は、記憶部１２９から検証結果を読み出し、異常と判定された実行ノードがあるかどうかを判定し（Ｓ７０３）、異常と判定された実行ノードがある場合、追加手段９２９により、新たな実行ノードを起動する（Ｓ７０４）。起動する実行ノードの個数、実際に起動する実行ノードの情報、各実行ノードの実行環境設定データは記憶部１２９に事前に記憶されており、追加手段９２９は記憶部１２９からそれらの情報を参照して新しい実行ノードを起動し、他の実行ノードと異なるバージョンのプログラムの処理を開始させる。新しく起動する実行ノードの数は、例えば直前のステップＳ７０３で異常と判定された実行ノードの個数と同じに設定されるが、それ以上の数を設定しておくことも可能である。
【００９８】
このように本実施の形態によれば、第１の実施の形態で得られる効果に加えて、実行ノードが異常と判定される毎に新たな実行ノードが追加されるため、正常な実行ノードの数が多数決論理で必要な最低値３より少なくなる事態を回避でき、耐障害性が向上する。
【００９９】
【発明の第４の実施の形態】
図９を参照すると、本発明の第４の実施の形態にかかる耐障害システムは、管理ノード７２０の実行管理部７２５が停止手段５２６に加えて、実行ノードの安定性を判定する安定性判定手段７２７と、安定性が確認されたら既定数Ｘ（Ｘは３以上の予め定められた値）を超える余分な実行ノードを停止対象ノードとして選択する選択手段７２８を備えている点で第２の実施の形態と構成が異なり、その他の構成は第２の実施の形態と同じである。また、本実施の形態にかかる耐障害システムの動作は、障害関連処理を除いて第２の実施の形態と同じである。
【０１００】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図１０のフローチャートを参照して説明する。
【０１０１】
システム起動後、複数の実行ノード１１０−１〜１１０−ｎにおいてプログラム１１１−１〜１１１−ｎが並列実行される通常運用状態になると、障害検出部１２４は、プログラム１１１−１〜１１１−ｎを実行している実行ノード１１０−１〜１１０−ｎの個数が予め定められた既定数Ｘ以上であるかどうかを判定し（Ｓ８０１）、既定数Ｘ以上であれば、情報取得手段１２１により、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報を通信経路１３０を通じて情報提供部１１６から取得し、それを記憶部１２９の環境情報記憶域に記憶する（ステップＳ８０２）。取得する環境情報は第１の実施の形態におけるものと同じである。
【０１０２】
次に、障害検出部１２４の比較検証手段１２２は、記憶部１２９に記憶された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２の環境情報を読み込み、第１の実施の形態と同様に多数決法あるいは外れ値検出法を用いて比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する（Ｓ８０３）。比較検証手段１２２による検証結果は記憶部１２９に記憶される。
【０１０３】
次に、実行管理部７２５は、記憶部１２９から検証結果を読み出し、異常と判定された実行ノードがあるかどうかを判定し（Ｓ８０４）、異常と判定された実行ノードがある場合、停止手段５２６により、第２の実施の形態と同様に、その異常な実行ノードを停止させる（Ｓ８０５）。
【０１０４】
他方、異常と判定された実行ノードがない場合、実行管理部７２５は、安定性判定手段７２７により、異常と判定されずに残っている正常な実行ノード１１０−１〜１１０−ｎの安定性を判定する（Ｓ８０６）。安定性の判定方法としては、異常ノードが検出されなくなってから既定時間が経過したら安定と判断する方法、比較検証手段１２２による比較検証において既定回数連続で異常ノードが検出されなければ安定と判断する方法などを使用する。勿論、これらの方法に限定するものではない。安定性の判定結果は記憶部１２９に記憶される。
【０１０５】
次に、実行管理部７２５は記憶部１２９から安定性の判定結果を読み出し、安定しているとの判定結果が出ていない場合（Ｓ８０７でＮＯ）、制御を障害検出部１２４に移し、障害検出部１２４は再び環境情報の取得と比較検証の処理を繰り返す。他方、安定しているとの判定結果が出ている場合（Ｓ８０７でＹＥＳ）、選択手段７２８により、既定数Ｘを超える数だけの実行ノードを停止させる実行ノードとして選択する（Ｓ８０８）。停止させる実行ノードを選択する方法としては、偏りを無くすために完全にランダムで選択する方法、事前に定義された順位がより高いものから順に選択する方法、事前に定義されたローテーションスケジュールに従って選択する方法などを使用する。勿論、これらの方法に限定するものではない。選択手段７２８で選択された実行ノードの情報は記憶部１２９に記憶される。
【０１０６】
次に、停止手段５２６は、記憶部１２９から停止対象となる実行ノードの情報を読み出し、それらに対して通信経路１３０経由で制御命令を発行することにより、選択手段７２８で選択された全ての実行ノードを停止させる。以後、図１０に示した処理は停止する。
【０１０７】
このように本実施の形態によれば、第２の実施の形態で得られる効果に加えて、すべての実行ノードが安定した状態になった時点で、不要な分だけ実行ノードを停止させるため、実行コストをより低減することができる。
【０１０８】
【発明の第５の実施の形態】
図１１を参照すると、本発明の第５の実施の形態にかかる耐障害システムは、管理ノード９２０の実行管理部９２５が停止手段５２６、安定性判定手段７２７および選択手段７２８に加えて、新たな実行ノードを追加する追加手段９２９を備えている点で図９の第４の実施の形態と構成が異なり、その他の構成は第４の実施の形態と同じである。また、本実施の形態にかかる耐障害システムの動作は、障害関連処理を除いて第４の実施の形態と同じである。
【０１０９】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図１２のフローチャートを参照して説明する。
【０１１０】
システム起動後、規定数Ｘ（Ｘは３以上の値）の複数の実行ノード１１０−１〜１１０−ｎにおいてプログラム１１１−１〜１１１−ｎが並列実行されている通常運用状態になると、障害検出部１２４は、情報取得手段１２１により、各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２のほぼ同一時点の環境情報を通信経路１３０を通じて情報提供部１１６から取得し、それを記憶部１２９の環境情報記憶域に記憶する（ステップＳ１００１）。取得する環境情報は第１の実施の形態におけるものと同じである。次に、障害検出部１２４の比較検証手段１２２は、記憶部１２９に記憶された各実行ノード１１０−１〜１１０−ｎにおける実行環境１１２の環境情報を読み込み、第１の実施の形態と同様に多数決法あるいは外れ値検出法を用いて比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する（Ｓ１００２）。比較検証手段１２２による検証結果は記憶部１２９に記憶される。次に、実行管理部９２５は、記憶部１２９から検証結果を読み出し、異常と判定された実行ノードがあるかどうかを判定する（Ｓ１００３）。異常と判定された実行ノードが無い場合、制御はステップＳ１００１に戻り、一定期間毎に環境情報の取得と比較検証する処理を再び繰り返す。
【０１１１】
他方、異常と判定された実行ノードがある場合、実行管理部９２５は、追加手段９２９により、新たな実行ノードを起動する（Ｓ１００４）。起動する実行ノードの個数、実際に起動する実行ノードの情報、各実行ノードの実行環境設定データは記憶部１２９に事前に記憶されており、追加手段９２９は記憶部１２９からそれらの情報を参照して新しい実行ノードを起動し、他の実行ノードと異なるバージョンのプログラムの処理を開始させる。新しく起動する実行ノードの数は、例えば直前のステップＳ１００３で異常と判定された実行ノードの個数と同じに設定されるが、それ以上の数を設定しておくことも可能である。
【０１１２】
その後、制御はステップＳ１００５に移る。ステップＳ１００５〜Ｓ１０１３は、図１０のステップＳ８０１〜Ｓ８０９と同じである。これにより、プログラム１１１−１〜１１１−ｎを実行する実行ノード１１０−１〜１１０−ｎの数が既定数Ｘ以上あることを条件に、環境情報の取得と比較検証による異常ノードの同定の処理が一定期間毎に繰り返され、異常ノードが発生した場合にはその実行ノードが停止される。また、実行ノードが安定すると、既定数Ｘを超える余分な実行ノードが停止される。但し、図１０の処理と異なり、余分な実行ノードを停止した後、またはプログラム１１１−１〜１１１−ｎを実行する実行ノード１１０−１〜１１０−ｎの数が既定数Ｘより少なくなると、制御はステップＳ１０２１に移行する。従って、実行ノードの個数が規定数Ｘより少ない場合（Ｓ１０２１でＹＥＳ）、追加手段９２９は、実行ノードの数が規定数Ｘになるように新たな実行ノードを起動する（Ｓ１０２２）。そして、ステップＳ１００１以降の処理へと進む。これにより、更に別の実行ノードが異常になると、再度、新たな実行ノードが追加されることになる。
【０１１３】
このように本実施の形態によれば、第４の実施の形態で得られる効果に加えて、平常時は実行ノードの数を減らすことで実行コストを低減し、障害を検知したら実行ノードを追加して起動、実行することで耐障害性を向上させることができる。従って、必要に応じて適切な耐障害性を提供することができる。
【０１１４】
【発明の第６の実施の形態】
図１３を参照すると、本発明の第６の実施の形態にかかる耐障害システムは、管理ノード１１２０の実行管理部１１２５が停止手段５２６、安定性判定手段７２７、選択手段７２８および追加手段７２９に加えて、外部からの要求メッセージを受けて、実行ノード１１０−１〜１１０−ｎに分配し、その応答メッセージを収集し、外部に返信するメッセージ管理手段１１２７を備えている点で図１１の第５の実施の形態と構成が異なり、その他の構成は第５の実施の形態と同じである。また、本実施の形態にかかる耐障害システムの動作は、メッセージ管理手段１１２７に関連する処理を除いて第５の実施の形態と同じである。
【０１１５】
図１４を参照すると、メッセージ管理手段１１２７は、要求メッセージ受信手段１２１１、要求メッセージ処理判断手段１２１２、要求メッセージ生成手段１２１３、要求メッセージ送信手段１２１４、要求メッセージ処理判断情報記憶部１２１５および要求メッセージ転送先情報記憶部１２１６から構成される処理要求分配系と、応答メッセージ受信手段１２２１、応答メッセージ処理判断手段１２２２、応答メッセージ生成手段１２２３、応答メッセージ送信手段１２２４、応答メッセージ処理判断情報記憶部１２２５および応答メッセージ転送先情報記憶部１２２６から構成される処理結果導出系と、実行管理部１１２５の停止手段５２６による実行ノードの停止および追加手段７２９による実行ノードの追加に応じて、各記憶部１２１５、１２１６、１２２５、１２２６を更新する情報更新手段１２３１とを含んで構成され、サービスを要求するクライアントなどといった要求メッセージ送信元１２０２に接続されると共に、実行ノード１１０−１〜１１０−ｎに相当する実行ノード群１２０１に接続される。なお、図１４に示される応答メッセージ送信先１２０３は、要求メッセージ送信元１２０２あるいは実行ノード群１２０１に相当する。
【０１１６】
次に、メッセージ管理手段１１２７の動作を説明する。
【０１１７】
要求メッセージ送信元１２０２から本実施の形態の耐障害システムに要求メッセージが送信されてくると、要求メッセージ受信手段１２１１で受信する。要求メッセージ処理判断手段１２１２では、要求メッセージ処理判断情報記憶部１２１５に記憶された情報を参照して、受信した要求メッセージの転送の可否および転送する場合には転送先の実行ノード１１０−ｉ（ｉ＝１〜ｎ）を判断する。転送先が無いなどの理由で転送しないと判断した場合は、要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元１２０２に返す。転送すると判断した場合、要求メッセージ処理判断手段１２１２は、転送先の実行ノード１１０−ｉを指定して要求メッセージを要求メッセージ生成手段１２１３に伝達する。転送先の実行ノードが複数ある場合、それらの全てを指定する。
【０１１８】
要求メッセージ生成手段１２１３は、要求メッセージ転送先情報記憶部１２１６を参照して、要求メッセージの宛先を転送する実行ノード１１０−ｉに書き換えることで、実際に転送する要求メッセージを生成する。ここで、転送先の実行ノードが複数あるのであれば、要求メッセージ生成手段１２１３は、要求メッセージを複製し、それぞれの宛先を転送先の実行ノードに書き換えることで、複数の転送する要求メッセージを生成する。
【０１１９】
要求メッセージ送信手段１２１４は、要求メッセージ生成手段１２１３で生成された要求メッセージを、通信経路１３０を通じて、実行ノード群１２０１内の該当する実行ノード１１０−ｉに送信する。要求メッセージの転送を受けた実行ノード１１０−ｉは、その要求メッセージをプログラム１１１−ｉに処理させる。
【０１２０】
各実行ノード１１０−ｉのプログラム１１１−ｉは、要求された処理を行い、応答メッセージを送信する。要求メッセージ送信元１２０２からの要求メッセージをプログラム１１１−ｉで一度処理するだけで、そのプログラム１１１−ｉから最終的な処理結果の応答メッセージが出される場合だけでなく、最終的な処理結果を得る過程で別の実行ノードや外部のシステムにデータベースアクセスなどの処理要求を行う応答メッセージ（別サービス要求メッセージ）が返される場合がある。応答メッセージ受信手段１２２１は、このような実行ノード１１０−ｉからの応答メッセージを受信し、内部のバッファに一時的に蓄積する。
【０１２１】
応答メッセージ処理判断手段１２２２は、応答転送メッセージ生成に必要な処理結果が応答メッセージ受信手段１２２１のバッファに蓄積されたかどうかを判断し、未だ蓄積されていないときは今回の処理を終了する。応答転送メッセージ生成に必要な処理結果が蓄積されていれば、応答メッセージ処理判断手段１２２２は、応答メッセージ処理判断情報記憶部１２２５を参照して、応答転送メッセージの生成可否および転送先の判断を行い、応答転送メッセージを生成する。例えば、蓄積されている応答メッセージが別サービス要求メッセージであって、別サービス要求メッセージを分配する実行ノードが１つも無いなどの理由で転送しないと判断した場合、おおもとの要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元１２０２に送信する。また、蓄積されている応答メッセージが別サービス要求メッセージであって分配先が存在するために転送すると判断した場合および蓄積されている応答メッセージが別サービス要求メッセージでなく最終的な応答メッセージの場合、応答メッセージが一つであれば、そのメッセージをそのまま転送するメッセージとする。複数の実行ノード１１０−ｉのプログラム１１１−ｉから複数の応答メッセージがある場合、応答メッセージ処理判断手段１２２２は、応答メッセージ処理判断情報記憶部１２２５を参照して、以下のような応答メッセージの選択あるいは生成を行い、転送先を指定して応答メッセージ生成部１２２３に伝達する。転送先は、最終的な応答であれば、要求メッセージ元であり、別サービス要求メッセージであれば、実行ノード等である。
【０１２２】
（ａ）任意の一つの実行ノード１１０−ｉの計算機プログラム１１１−ｉからの応答メッセージを選択し、これを応答転送メッセージとする。このとき、最も早く到着した応答メッセージを選択するようにしても良い。
（ｂ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージから多数決論理により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｃ）予め定められた既定個数の応答メッセージが到着次第、多数決により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｄ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージの平均値を取るなどの統計処理を行い、統計処理で得られた値をもつ応答転送メッセージを生成する。
（ｅ）異常と検出された実行ノード以外の任意の実行ノードの結果を出力する。
【０１２３】
応答メッセージの選択あるいは生成の方法は、これらに限定されるものではなく、その他任意の方法を使用することができる。
【０１２４】
応答メッセージ生成手段１２２３は、応答メッセージ転送先情報記憶部１２２６を参照して、応答転送メッセージの宛先を応答メッセージ送信先１２０３に書き換えることで、実際に転送する応答メッセージを生成する。応答メッセージ送信手段１２２４は、生成された応答メッセージを応答メッセージ送信先１２０３に送信する。応答メッセージ送信先１２０３が、実行ノードである場合、その実行ノードのプログラムは要求された処理を行い、その処理結果を応答メッセージで送信する。また、応答メッセージ送信先１２０３が、要求メッセージ送信元１２０２である場合、システムとしての処理結果が要求メッセージ送信元１２０２に返却されたことになる。
【０１２５】
他方、情報更新手段１２３１は、実行ノードが起動されたり、停止されたりしてシステムの状態が変化すると、その情報を元に、要求メッセージ処理判断情報記憶部１２１５、要求メッセージ転送先情報記憶部１２１６、応答メッセージ処理判断情報記憶部１２２５および応答メッセージ転送先情報記憶部１２２６に格納された情報を適宜更新する。
【０１２６】
このように本実施の形態によれば、第５の実施の形態で得られる効果に加えて、実行ノードと外部とのやり取りにＮバージョン方式と同様な耐障害性を付与することができる。
【０１２７】
【発明の第７の実施の形態】
従来の耐障害システムおよびこれまでに説明した本発明の第１〜第６の実施の形態にかかる耐障害システムは、全ての実行ノードが同一の実行環境を持ち、その同一の実行環境上で、異なるバージョンのプログラムを実行することで、耐障害性を付与していたが、本実施の形態にかかる耐障害システムは、全ての実行ノードが互いに異なる実行環境を持ち、その異なる実行環境上で、同一のプログラムを実行することで、耐障害性を持たせる。一般にソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するため、複数の実行ノードの実行環境をそれぞれ異ならせることで、プログラムに存在する特定のバグが活性化する特定の状態が全ての実行ノードで同時に起き難くなり、同一のプログラムを使用してソフトウェアレベルでの耐障害性を持たせることができる。このような耐障害手法を、本明細書では環境多様型ソフトウェアフォールトトレランス（略して環境多様ＳＦＴ）と呼ぶ。
【０１２８】
図１５を参照すると、本発明の第７の実施の形態にかかる耐障害システムは、複数の実行ノード１３１０−１〜１３１０−ｎと、これら複数の実行ノード１３１０−１〜１３１０−ｎを管理する少なくとも１つの管理ノード１３２０と、これら複数の実行ノード１３１０−１〜１３１０−ｎおよび管理ノード１３２０を互いに通信可能に接続する通信経路１３０とを含んで構成される。実行ノード１３１０−１〜１３１０−ｎは、同一のプログラム１３１１と、そのプログラム１３１１を実行するそれぞれ異なる実行環境１３１２−１〜１３１２−ｎと、情報提供部１１６とを有する実マシンあるいは仮想マシンである。それぞれの実行環境１３１２−１〜１３１２−ｎは、少なくとも１つの演算部１３１３−１〜１３１３−ｎと記憶部１３１４−１〜１３１４−ｎと入出力部１３１５−１〜１３１５−ｎとを備えている。また、管理ノード１３２０は、図１３に示した第６の実施の形態における管理ノード１１２０と同様の構成を備えている。つまり、本実施の形態は、図１３に示した第６の実施の形態において、プログラムを全て同じバージョンにし、実行環境をそれぞれ異ならせたものに相当する。
【０１２９】
実行環境は、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類に大別され、この４種類のうちの少なくとも１種類が相違すると、異なる実行環境となる。
【０１３０】
ハードウェア環境とは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類などのことである。これらハードウェア環境を規定する計算機の主記憶容量などをハードウェア環境パラメータと呼ぶ。ハードウェア環境パラメータの１つでも互いに相違するハードウェア環境は異なるハードウェア環境となる。
【０１３１】
ソフトウェア環境とは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのバージョンのことである。基本ソフトウェアとは、インターネットブラウザ、ファイアーウォール、ウィルスチェッカーなどのように、常時実行されるために、計算機プログラムの動作に影響を与えるもののことである。各種デバイスドライバとは、ディスクドライバなどのことである。各種ライブラリとは、動的リンクライブラリなどのことである。また、これらのソフトウェアに対する修正パッチ、セキュリティパッチの適用・未適用の設定もソフトウェア環境の一つである。さらに、ＯＳ、基本ソフトウェア、ライブラリの動作を規定するレジストリ、セキュリティポリシー、アクセスポリシーなどのコンフィグレーションファイルの設定状態もソフトウェア環境に含まれる。これらソフトウェア環境を規定するＯＳのバージョンなどをソフトウェア環境パラメータと呼ぶ。ソフトウェア環境パラメータの１つでも互いに相違するソフトウェア環境は異なるソフトウェア環境となる。
【０１３２】
外部接続機器環境とは、計算機に接続されている外部記憶装置、表示装置、入力装置、通信装置などの仕様のことである。例えば、シリアルポート、ディスプレイ、ハードディスク、ネットワーク、キーボード、マウス、タブレット、プリンタ、スピーカーなどの仕様である。これら外部接続機器環境を規定する外部記憶装置の仕様を外部接続機器環境パラメータと呼ぶ。外部接続機器環境パラメータの１つでも互いに相違する外部接続機器環境は異なる外部接続機器環境となる。
【０１３３】
プログラム起動環境とは、計算機プログラムの起動方法の種類であり、具体的には、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムとＯＳの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動といったプログラム起動方法の種類である。これらプログラム起動環境を規定する起動方法の種類はプログラム起動環境のパラメータの１つである。また、実行ノードが活性化する条件もプログラム起動環境のパラメータに含まれる。例えば、ある実行ノードは、システムの運用開始と同時に活性化し、別の実行ノードは、別の実行ノードの停止または負荷増加のイベント通知を受けて活性化するなどの如きものである。さらに、起動時刻、停止タイミング、停止時刻、連続稼動時間といった運用環境も、ここではプログラム起動環境パラメータに含める。プログラム起動環境パラメータの１つでも互いに相違するプログラム起動環境は異なるプログラム起動環境となる。
【０１３４】
本実施の形態においては、管理ノード１３２０の記憶部１２９に記憶されている各実行ノード毎の実行環境設定データは互いに異なっており、第１の実施の形態と同様に図３に示した手順によってシステム起動時に各実行ノードの実行環境を設定する際、管理ノード１３２０の実行管理部１３２５は、記憶部１２９に記憶された各実行ノード毎にそれぞれ異なる実行環境設定データを使って、各実行ノード１３１０−１〜１３１０−ｎに実行環境１３１２−１〜１３１２−ｎおよび同一のプログラム１３１１の設定を行う。これにより、同一のプログラム１３１１がそれぞれ異なる実行環境１３１２−１〜１３１２−ｎ上で並列実行される通常運用状態となる。
【０１３５】
ここで、プログラム１３１１に存在する特定のバグが活性化する特定の状態を全ての実行ノード１３１０−１〜１３１０−ｎで同時に起き難くするためには、実行ノード１３１０−１〜１３１０−ｎどうしの実行環境１３１２−１〜１３１２−ｎの相違度を或る程度以上大きくするのが望ましい。何故なら、他の環境やパラメータは全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するだけでは殆ど効果がないからである。そこで、本実施の形態では、複数の実行ノードの任意の２つの実行ノード間の実行環境の相違度は、予め定められた相違度以上に相違するように定められている。以下、この点について説明する。
【０１３６】
今、２つの実行ノードＸ、Ｙの実行環境の相違度をＤＸＹとし、次式に示すように定義する。
2004355233.tif 000003
【０１３７】
ここで、ＤＨは実行ノードＸ、Ｙのハードウェア環境の相違度、ＤＳは実行ノードＸ、Ｙのソフトウェア環境の相違度、ＤＧは実行ノードＸ、Ｙの外部接続機器環境の相違度、ＤＫは実行ノードＸ、Ｙのプログラム起動環境の相違度をそれぞれ示す。ａ，ｂ，ｃ，ｄは重み付けの変数であり、全て同じ値を使えば各環境の相違度を公平に考慮することができ、他のものに比べて大きな値を用いればその環境の相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【０１３８】
ハードウェア環境の相違度ＤＨは、ハードウェア環境のパラメータ数をｒ個とすると、次式で定義される。
2004355233.tif 000004
【０１３９】
ここで、ＤＨＸｉ（ｉ＝１〜ｒ）は実行ノードＸのハードウェア環境のｉ番目のパラメータ、ＤＨＹｉ（ｉ＝１〜ｒ）は実行ノードＹのハードウェア環境のｉ番目のパラメータ、｜ＤＨＸｉ−ＤＨＹｉ｜は実行ノードＸ、Ｙのハードウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、記憶部１３１４−１〜１３１４−ｎの相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、演算部（プロセッサ）１３１３−１〜１３１３−ｎの相違度は、種類が同じで且つバージョンが同じであれば相違度０、種類が同じであるがバージョンが異なれば相違度１、種類が異なれば相違度２の如く定められる。また、キャッシュの有効、無効のパラメータなど、取り得る状態が２つしか無いパラメータの場合、両者が同じ状態であれば相違度０、異なっていれば相違度１とする。ｈｉ（ｉ＝１〜ｒ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【０１４０】
ソフトウェア環境の相違度ＤＳは、ソフトウェア環境のパラメータ数をｓ個とすると、次式で定義される。
2004355233.tif 000005
【０１４１】
ここで、ＤＳＸｉ（ｉ＝１〜ｓ）は実行ノードＸのソフトウェア環境のｉ番目のパラメータ、ＤＳＹｉ（ｉ＝１〜ｓ）は実行ノードＹのソフトウェア環境のｉ番目のパラメータ、｜ＤＳＸｉ−ＤＳＹｉ｜は実行ノードＸ、Ｙのソフトウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ＯＳの相違度は、同じ種類で且つバージョンが同じであれば相違度０、同じ種類のＯＳであるがバージョンが異なれば相違度１、異なる種類のＯＳであれば相違度２の如く定められる。ウィルスチェッカーなど、実装の有無も相違する場合、例えば、共に実装されていてバージョンが同じであれば相違度０、同じ種類のプログラムであるがバージョンが異なれば相違度１、異なる種類のプログラムであれば相違度２、実装の有無が相違すれば相違度３の如く定められる。ｓｉ（ｉ＝１〜ｓ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【０１４２】
外部接続機器環境の相違度ＤＧは、外部接続機器環境のパラメータ数をｔ個とすると、次式で定義される。
2004355233.tif 000006
【０１４３】
ここで、ＤＧＸｉ（ｉ＝１〜ｔ）は実行ノードＸの外部接続機器環境のｉ番目のパラメータ、ＤＧＹｉ（ｉ＝１〜ｔ）は実行ノードＹの外部接続機器環境のｉ番目のパラメータ、｜ＤＧＸｉ−ＤＧＹｉ｜は実行ノードＸ、Ｙの外部接続機器環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ハードディスクの相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、プリンタの相違度は、共に実装されていて同じ種類であれば相違度０、共に実装されているが種類や仕様が異なれば相違度１、実装の有無が相違すれば相違度３の如く定められる。ｇｉ（ｉ＝１〜ｔ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【０１４４】
プログラム起動環境の相違度ＤＫは、プログラム起動環境のパラメータ数をｕ個とすると、次式で定義される。
2004355233.tif 000007
【０１４５】
ここで、ＤｋＸｉ（ｉ＝１〜ｕ）は実行ノードＸのプログラム起動環境のｉ番目のパラメータ、ＤｋＹｉ（ｉ＝１〜ｕ）は実行ノードＹのプログラム起動環境のｉ番目のパラメータ、｜ＤｋＸｉ−ＤｋＹｉ｜は実行ノードＸ、Ｙのプログラム起動環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、再起動方法の相違度は、種類が同じであれば相違度０、種類が異なれば相違度１の如く定められる。ｋｉ（ｉ＝１〜ｕ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【０１４６】
各実行ノード１３１０−１〜１３１０−ｎの実行環境１３１２−１〜１３１２−ｎの選定に際しては、式（１）で計算される任意の２つの実行ノード間の実行環境の相違度が、予め定められた閾値の相違度よりも大きくなるように選定される。これにより、他の環境は全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するような２つの実行環境を設定するような事態を防止することができる。また、閾値を高く設定すれば、複数の実行ノードでプログラムに存在するバグが同時に発現する確率をより小さくすることができる。
【０１４７】
通常運用状態における動作は、図１３に示した第６の実施の形態の耐障害システムとほぼ同じである。但し、環境多様ＳＦＴでは、全ての実行ノードが正常な状態においても最初から環境情報に違いがあるため、比較検証ではこの当初の違いを考慮して、異常ノードを検出する必要がある。以下、この点について詳しく説明する。
【０１４８】
まず、実行ノードの個数を実行ノード１、２、３の３台とし、たとえば比較検証する値を、各実行ノード１、２、３における或るプロセスの消費メモリ［ＫＢ］：ｘ１、ｘ２、ｘ３、そのプロセスのＣＰＵ使用率［％］：ｙ１、ｙ２、ｙ３、その実行ノードにおけるＣＰＵの温度［度］：ｚ１、ｚ２、ｚ３の３つの種類の環境情報を示すパラメータを用いるものとする。
【０１４９】
また、パラメータｘ１の、集合｛ｘ１、ｘ２、ｘ３｝に対する外れ値を計算する関数を下記（６）、パラメータｙ１の、集合｛ｙ１、ｙ２、ｙ３｝に対する外れ値を計算する関数を下記（７）、パラメータｚ１の、集合｛ｚ１、ｚ２、ｚ３｝に対する外れ値を計算する関数を下記（８）に示すものとする。但し、これらの関数はパラメータが環境の影響を受けない場合のものである。
ｆ（ｘ１、｛ｘ１、ｘ２、ｘ３｝）  …（６）
ｇ（ｙ１、｛ｙ１、ｙ２、ｙ３｝）  …（７）
ｈ（ｚ１、｛ｚ１、ｚ２、ｚ３｝）  …（８）
【０１５０】
また、実行ノード１の総合的な外れ度Ｈ（Ｍ１）を、前記（６）〜（８）の計算式を使って次式で計算するものとする。
2004355233.tif 000008
ここで、α、β、γは定数である。
【０１５１】
さて、実際は、上記のパラメータｘ、ｙ、ｚのうち、プロセス毎の消費メモリ：ｘは、基本的に環境の差異の影響を受けないパラメータであり、プロセス毎のＣＰＵ使用率（ロードアベレージ）：ｙは、ＣＰＵの処理性能に影響を受けるため環境の差異の影響を受けるパラメータである。また、ＣＰＵ温度：ｚは、環境の差異（ＣＰＵの種類など）の影響を受けるパラメータであるが、該当ノードのＢＩＯＳがＣＰＵ温度の取得に対応していない場合には取得すらできないものであるため、値としては未定義値となる場合がある。このため、環境の差異の影響を受けないパラメータｘ、環境の差異の影響を受けるパラメータｙ、取得できないことのあるパラメータｚ毎に、実際には以下のように計算していく。
【０１５２】
◇環境の差異の影響を受けないパラメータ
基本的に環境の差異の影響を受けないパラメータｘは、そのまま式（６）を計算する外れ値計算関数に渡して計算し、その計算結果を式（９）に適用する。
【０１５３】
◇環境の差異の影響を受けるパラメータ
プロセス毎のＣＰＵ使用率（ロードアベレージ）ｙは、ＣＰＵの処理性能に影響を受けるため、以下のように処理する。
【０１５４】
例えば仕事量１０のプロセスは、処理性能１００のＣＰＵの場合、使用率は１０÷１００＝１０％となるが、処理性能５００のＣＰＵの場合、使用率は１０÷５００＝２％となる。このようなパラメータは、この環境の差異の影響を打ち消す関数を用いて、外れ値を計算する。具体的には、実行ノード１のｙに関する外れ値の計算式（７）を、環境差異を打ち消す関数をＩとすると、次式（７’）のように変形して使用する。
2004355233.tif 000009
ここで、ｅはｙに影響を与える環境をあらわすパラメータである。また、関数Ｉは、例えば前述のＣＰＵ使用率の場合、次式に示すものとなる。
Ｉ（ｙ、ｐ）  ＝ｙ×ｐ÷１００  …（１０）
ここで、ｙはＣＰＵ使用率、ｐはＣＰＵ処理性能である。
【０１５５】
◇パラメータが取得できない場合
ＣＰＵ温度などは、値として未定義値となり得るパラメータの場合、環境差異を打ち消す関数Ｉ’として、以下のようなものを使用する。
2004355233.tif 000010
ここで、Ａは定数、Ｆはｚが定義された場合の環境差異を打ち消す関数、ｅはｚに影響を与える環境をあらわすパラメータである。また、未定義の場合に与えられる値Ａでは、外れ値計算の信頼性が高くない場合、外れ値計算関数に掛かる定数の値を小さくすることで、その影響を少なくする。具体的には、前記式（９）における定数γを小さくする、あるいは０にして、ｚに関する外れ値計算の影響を小さくする、あるいは無視する。
【０１５６】
結局、実行ノード１の総合的な外れ度Ｈ（Ｍ１）の計算式は以下のようになる。
2004355233.tif 000011
【０１５７】
以上のように本実施の形態によれば、第６の実施の形態で得られる効果に加えて、使用するプログラム１３１１は１種類のため、プログラムの開発コストを軽減できる。また、実行ノード１３１０−１〜１３１０−ｎに仮想マシンを使用すれば、主記憶メモリのサイズなど各種のパラメータ設定の変更が容易であり、多様な実行環境を容易に実現でき、また、常時多様な実行環境を実現する計算機および機器を用意する必要がないので、実行コストの削減が可能である。
【０１５８】
本実施の形態は、図１３に示した第６の実施の形態において、プログラムを全て同じバージョンにし、実行環境をそれぞれ異ならせたものであるが、他の実施の形態として、図１に示した第１の実施の形態、図５に示した第２の実施の形態、図７に示した第３の実施の形態、図９に示した第４の実施の形態において、図１１に示した第５の実施の形態において、プログラムを全て同じバージョンにし、実行環境をそれぞれ異ならせることも考えられる。
【０１５９】
【発明の第８の実施の形態】
これまで説明した実施の形態では、各実行ノードの環境情報の取得と比較検証による異常ノードの同定、異常ノード発生時の障害対応処理といった障害関連処理を、管理ノードで集中的に行う構成を採用したが、障害関連処理を複数の実行ノードで分散的に行う構成にすることも可能である。また、障害関連処理だけでなく、処理要求の分配処理や並列実行されるプログラムの処理結果からシステムとしての処理結果を導出する処理など、他の処理も複数の実行ノードで分散的に行う構成にすることも可能である。一例として、図１１に示した第５の実施の形態にかかる耐障害システムを分散管理方式に変更した耐障害システムの構成例を図１６に示す。勿論、第５の実施の形態以外の他の実施の形態についても同様に分散管理方式にすることが可能である。
【０１６０】
図１６を参照すると、本発明の第８の実施の形態にかかる耐障害システムは、複数の実行ノード１４１０−１〜１４１０−ｎと、これら実行ノード１４１０−１〜１４１０−ｎを接続する通信経路１３０とを含んで構成される。
【０１６１】
実行ノード１４１０−１〜１４１０−ｎは、図１１に示される第５の実施の形態における実行ノード１１０−１〜１１０−ｎの構成において、実行環境１１２に代えて、実行環境１１２が有する演算部１１３、記憶部１１４および入出力部１１５を有し且つ管理部１４２０を有する実行環境１４１２を備える点で異なる。
【０１６２】
管理部１４２０は、実行ノード１４１０−１〜１４１０−ｎの環境情報を取得する情報取得手段１４３１および環境情報を比較検証する比較検手段１４３２を有する障害検出部１４３０と、他の実行ノードと協調して実行ノード１４１０−１〜１４１０−ｎの実行管理を行う協調実行管理部１４４０とを備えている。また、協調実行管理部１４４０は、異常として検出された実行ノードや安定状態における余分な実行ノードを停止させる停止手段１４４１と、実行ノード１４１０−１〜１４１０−ｎの安定性を判定する安定性判定手段１４４２と、安定状態になったときに既定数Ｘを超える余分な実行ノードを停止対象の実行ノードとして選択する選択手段１４４３と、新たな実行ノードをシステムに追加する追加手段１４４４とを含む。
【０１６３】
本実施の形態の動作は、本発明の第５の実施の形態とほぼ同じである。ただし第５の実施の形態における管理ノード９２０は備えず、各実行ノード１４１０−１〜１４１０−ｎの管理部１４２０が通信経路１３０を介して情報をやり取りし、協調して動作する点が異なる。特に協調実行管理手段１４４０が異常と同定した実行ノードを停止したり、新たに実行ノードを起動する場合には、それらの動作は排他的に実行される必要がある。なぜなら同時に全ての実行ノードが停止したり、同一の実行ノードに対して複数の起動命令が発行され、コンフリクトを発生する可能性があるからである。
【０１６４】
協調動作手法としては、以下の２つの手法が考えられる。
【０１６５】
◇手法１各操作毎に他の全ての実行ノードとネゴシエーションを行う手法である。
具体的には、制御命令を発行するノードをＡ、制御対象となるノードをＢ、その他の関連ノードをＣ（複数存在する）とすると、以下のような手順となる。
【０１６６】
（１）ノードＡは、ノードＣに、ノードＢを制御する制御許可の申請を通知する。
（２）通知を受け取ったノードＣは、特に問題が無ければ（自分がノードＢに何らかの制御をしようとしなければ）、制御命令許可を返信し、問題がある場合は不許可の旨を返信する。
（３）ノードＡは一定時間待機して不許可通知がなければ、ノードＢの制御を行う。他方、不許可通知があれば、失敗となる。この場合、一定時間（ランダム）待機後、（１）から再試行を行う。一定回数失敗したら、あるいは一定時間経過したら、制御を放棄する。
【０１６７】
◇手法２関連ノードから暫定的に管理ノードを選択する手法である。具体的には以下のような手順となる。
【０１６８】
（１）関連する全てのノードの中から、何らかの方針（例えば、もっとも負荷が少ないノード、等）、あるいはランダムで１つのノードを選び、以降そのノードを管理ノードとする。
（２）以降の管理制御は、選ばれた管理ノードが一手に行う。
（３）選ばれた管理ノードが、なんらかの理由で停止した場合、残ったノードから同様の方法でノードを選び、新たなる管理ノードとする。
【０１６９】
以上のように本実施の形態によれば、第５の実施の形態で得られる効果に加え、単一の管理ノードを持たないため、単一故障点が存在せず、より高い耐障害性を提供できる。
【０１７０】
【発明の他の実施の形態】
本発明の第１〜第６、第８の実施の形態にかかる耐障害システムは、全ての実行ノードが同一の実行環境を持ち、その同一の実行環境上で、異なるバージョンのプログラムを実行することで、耐障害性を持たせた。また、第７の実施の形態にかかる耐障害システムは、全ての実行ノードがそれぞれ異なる実行環境を持ち、その異なる実行環境上で同一バージョンのプログラムを実行することで、耐障害性を持たせた。本発明の他の実施の形態として、全ての実行ノードがそれぞれ異なる実行環境を持ち、その異なる実行環境上でそれぞれ異なるバージョンのプログラムを実行することで、耐障害性を持たせることもできる。また、一部の実行ノードどうしは実行環境が相違するがプログラムのバージョンは同じであり、他の一部の実行ノードどうしはプログラムのバージョンが相違するが実行環境は同一であるというようにすることで、耐障害性を持たせる実施の形態も考えられる。つまり、本発明の耐障害システムにおける複数の実行ノードは、プログラム及びこのプログラムを実行する実行環境から構成され、前記プログラムのバージョンおよび前記実行環境の少なくとも一方が互いに相違するが全て同等の機能を提供する複数の実行ノードであれば良い。
【０１７１】
【実施例】
次に本発明の実施例について図面を参照して詳細に説明する。以下の実施例は、本発明の第５の実施の形態の一実施例である。
【０１７２】
（構成の説明）
図１７を参照すると、本実施例は、実行ノード１７１０−１〜１７１０−ｎ、管理ノード１７２０およびそれらを相互に通信可能に接続する通信経路１３０を備える。
【０１７３】
実行ノード１７１０−１〜１７１０−ｎは、インテル−アーキテクチャによる演算部１７１３、記憶部１７１４、入出力部１７１５を備える実行環境１７１２において動作するＬｉｎｕｘマシンであり、アプリケーションプログラム１７１１−１〜１７１１−ｎが動作する。また、各実行ノード１７１０−１〜１７１０−ｎは、自ノードの環境情報を通信経路１７３０経由で管理ノード１７２０に提供する情報提供部１７１６を有する。
【０１７４】
管理ノード１７２０もまたＬｉｎｕｘマシンであり、異常な実行ノードの検出などシステムの障害を検出する障害検出部１７２１、システム全体の実行状態を管理する実行管理部１７２４、記憶部１７２９を備える。
【０１７５】
障害検出部１７２１は、各実行ノード１７１０−１〜１７１０−ｎにおける実行環境１７１２の状態を示す環境情報を情報提供部１７１６から取得して記憶部１７２９に記憶する情報取得手段１７２２と、この情報取得手段１７２２によって取得された各実行ノード１７１０−１〜１７１０−ｎにおける実行環境１７１２の環境情報を記憶部１７２９から読み出して比較検証し、その検証結果を記憶部１７２９に記憶する比較検証手段１７２３とを備える。
【０１７６】
実行管理部１７２４は、新たな実行ノードを起動する追加手段１７２５、指定された実行ノードを停止させる停止手段１７２６、各実行ノード１７１０−１〜１７１０−ｎの安定性を判定する安定性判定手段１７２７、停止する実行ノードを選択する選択手段１７２８を備える。
【０１７７】
記憶部１７２９は、情報取得手段１７２２が取得する環境情報のリストである取得環境情報リストＭ１７０１、この取得環境情報リストＭ１７０１に記載された各環境情報毎の取得方法を記述した環境情報取得方法Ｍ１７０２、情報取得手段１７２２で取得された環境情報Ｍ１７０３、比較検証手段１７２３による比較検証結果Ｍ１７０４、追加手段１７２５が新たな実行ノードを追加する際に参照する追加ノード起動情報Ｍ１７０５、安定性判定手段１７２７の判定結果である安定性判定結果Ｍ１７０６、安定状態に至ったときに選択手段１７２８が停止対象として選択した実行ノードの情報である選択結果Ｍ１７０７を保持する。なお、記憶部１７２９には、管理ノード１７２０がシステム起動時に参照する、起動すべき実行ノードの数と起動対象とする実行ノードの指定情報、各ノードの実行環境のデータおよび並列実行対象となるプログラムも記憶されているが、図１７では図示を省略してある。
【０１７８】
（動作の説明）
次に本実施例による耐障害システムの動作について詳細に説明する。
【０１７９】
第５の実施の形態における説明個所で説明したように、システムが起動されると、管理ノード１７２０は、複数の実行ノード１７１０−１〜１７１０−ｎが同じ実行環境１７１２でバージョンの異なるプログラム１７１１−１〜１７１１−ｎが並列に実行されるように、各実行ノード１７１０−１〜１７１０−ｎに実行環境１７１２およびプログラム１７１１−１〜１７１１−ｎの設定を行い、通常運用状態に移行する。本実施例では、３つの実行ノード１７１０−１〜１７１０−３において、プログラム１７１１−１〜１７１１−３が並列実行されている通常運用状態になったものとする。
【０１８０】
この通常運用状態においては、第５の実施の形態における説明個所で説明したように、実行管理部１７２４および障害検出部１７２１においてシステムの状態を取得し、取得したシステムの状態に応じた処理を行う。実行管理部１７２４が取得するシステムの状態は、システム全体の終了命令が発行されたかどうか、プログラム１７１１−１〜１７１１−３で処理すべき新たな処理要求が発生したかどうか、プログラム１７１１−１〜１７１１−３で処理要求に対する処理が終了したかどうかなどの情報である。また、障害検出部１７２１が取得するシステムの状態は、各実行ノード１７１０−１〜１７１０−３における情報提供部１７１６が提供する、実行環境１７１２の状態を示す環境情報である。取得された環境情報は記憶部１７２９に一旦記憶され、その後読み出されて異常ノードの検出に用いられる。この障害関連処理の実施例にについては後に詳述する。
【０１８１】
システム全体の終了命令が発行された場合、終了処理が行われ、すべての実行ノードが停止する。新たな処理要求が発生した場合、管理ノード１７２０の実行管理部１７２４は、その処理要求を複数の実行ノード１７１０−１〜１７１０−３上のプログラム１７１１−１〜１７１１−３に処理させるための処理分配処理を実行する。また、プログラム１７１１−１〜１７１１−３で処理要求に対する処理が終了した場合、実行管理部１７２４は、システムとしての処理結果を導出する処理を行う。この処理は、例えば、異常ノードとして検出された実行ノード以外の実行ノードのプログラムの処理結果から多数決法によってシステムとしての処理結果を求める手法や、異常ノードとして検出された実行ノード以外の複数の実行ノードのプログラムで得られた処理結果から、任意の１つをシステムとしての処理結果として選択する手法などを使って、システムとしての処理結果を導出する。勿論、これらの手法に限定されず、任意の手法を用いることが可能である。
【０１８２】
次に、本実施の形態にかかる耐障害システムにおける障害関連処理の一例について、その流れを示す図１８のフローチャートを参照して説明する。
【０１８３】
システム起動後、本実施例では前述したように、３つの実行ノード１７１０−１〜１７１０−３において、プログラム１７１１−１〜１７１１−３が並列実行されている通常運用状態になる。
【０１８４】
まず、ステップＳ１８０１では、実行管理部１７２４が、動作している実行ノード１７１０−１〜１７１０−３の数が規定数Ｘ未満かどうかを判定する。本実施例では、規定数Ｘを３とする。そのため、システム起動直後のステップＳ１８０１では、実行ノードは規定数Ｘ以上であるため、ステップＳ１８０２は実行されず、ステップＳ１８０３へと進む。
【０１８５】
ステップＳ１８０３では、障害検出部１７２１における情報取得手段１７２２により、各実行ノード１７１０−１〜１７１０−３の環境情報を取得する。取得すべき環境情報は、取得環境情報リストＭ１７０１として記憶部１７２９に格納されている。本実施例では、取得環境情報リストＭ１７０１に、ＨＴＴＰデーモン（プロセス名ｈｔｔｐｄ）のプロセスの数、ノード全体のメモリ消費量、ノード全体のＣＰＵ使用率の３つの環境情報を取得するよう設定されているものとする。また、各環境情報の取得方法は、環境情報取得方法Ｍ１７０２として記憶部１７２９に格納されている。本実施例では各環境情報は以下のように取得するよう環境情報取得方法Ｍ１７０２に記述されているものとする。
【０１８６】
○ＨＴＴＰＤのプロセスの数：
（１）対象となる実行ノードにｔｅｌｎｅｔでログインする。
（２）ｐｓ  −ｅ  ｜  ｇｒｅｐ  ｈｔｔｐｄ  ｜  ｗｃ  というコマンドを実行する。
（３）標準出力として得られた結果を、解析する。
○ノード全体のメモリ消費量：
（１）対象となる実行ノードにｔｅｌｎｅｔでログインする。
（２）ｆｒｅｅ  というコマンドを実行する。
（３）標準出力として得られた結果を、解析する。
○ノード全体のＣＰＵ使用率：
（１）対象となる実行ノードにｔｅｌｎｅｔでログインする。
（２）ｕｐｔｉｍｅ  というコマンドを実行する。
（３）標準出力として得られた結果を、解析する。
【０１８７】
この結果得られた環境情報を以下の通りとする。
□実行ノード１７１０−１：
ＨＴＴＰＤのプロセスの数…１４［個］
ノード全体のメモリ消費量…１２７９１２［ＫＢ］
ノード全体のＣＰＵ使用率…１．１２［％］
□実行ノード１７１０−２：
ＨＴＴＰＤのプロセスの数…１７［個］
ノード全体のメモリ消費量…１８３３８１［ＫＢ］
ノード全体のＣＰＵ使用率…６２．８０［％］
□実行ノード１７１０−３：
ＨＴＴＰＤのプロセスの数…１５［個］
ノード全体のメモリ消費量…１３１１０４［ＫＢ］
ノード全体のＣＰＵ使用率…１．４０［％］
これらの環境情報は記憶部１７２９に環境情報Ｍ１７０３として格納される。
【０１８８】
障害検出部１７２１における比較検証手段１７２３は、記憶部１７２９に記憶された各実行ノード１７１０−１〜１７１０−３における実行環境１７１２の環境情報Ｍ１７０３を読み込み、比較検証することで、他と明確に異なる環境情報を持つ実行ノードを、異常のある実行ノードとして同定する（ステップＳ１８０４）。
【０１８９】
比較検証手段１７２３における比較検証方法として、本実施例ではまず個々のデータの外れ値検出法に、スミルノフ・グラブス検定による外れ値検出を用いる。スミルノフ・グラブス検定による外れ値検出とは、あるデータの集合に対し、対立仮説Ｈ１として「データのうち、平均値からもっとも離れたデータは外れ値である」という前提をおき、また、これを否定する帰無仮説Ｈ０として「データは同じ母集団のものである」という前提をおき、これらの前提のもと、平均値からもっとも離れたデータＸｉについて、Ｔｉ＝｜Ｘｉ−Ｘ｜／√Ｕ  （Ｘはデータの集合の平均値、Ｕは不変分散）を求め、Ｔｉに対し有意点ｔとの差によって帰無仮説を採択あるいは棄却することで、Ｘｉを任意の有意水準で外れ値か否か検定する方法である。
【０１９０】
まずＨＴＴＰＤのプロセス数については、Ｘ１＝１４、Ｘ２＝１７、Ｘ３＝１５であるため、データの集合の平均値Ｘ、不変分散Ｕは、それぞれ下記のようになる。
Ｘ  ＝  Σｎｉ＝１（Ｘｉ）  ／  ｎ  ＝１５．３３３
Ｕ  ＝  Σｎｉ＝１（Ｘｉ−Ｘ）＾２  ／  （ｎ−１）  ＝  １．５２８
【０１９１】
また、各データＸｉの平均値Ｘとの差分Ｓｉは、
Ｓ１  ＝  ｜Ｘ１−Ｘ｜  ＝  １．３３３
Ｓ２  ＝  ｜Ｘ２−Ｘ｜  ＝  １．６６７
Ｓ３  ＝  ｜Ｘ３−Ｘ｜  ＝  ０．３３３
であり、もっとも離れたデータはＸ２である。
【０１９２】
したがってＸ２について検定を行うと、
Ｔ２＝｜Ｘ２−Ｘ｜／√Ｕ＝１．０９１
となる。
【０１９３】
ここで有意水準５％で検定を行うとすると、ｎ＝３なので、有意点ｔはｔ＝１．１５３（統計数値表から求める）となる。したがって、Ｔ２＜ｔであるため帰無仮説Ｈ０を採択する。すなわちＸ２は外れ値ではない。したがって外れ値は存在しない。
【０１９４】
同様にメモリ消費量については、
Ｘ１  ＝  １２７９１２
Ｘ２  ＝  １８３３８１
Ｘ３  ＝  １３１１０４
であり、
Ｘ  ＝  １４７４６５．７００
Ｕ  ＝  ３１１４４．５１０
であり、
Ｓ１  ＝  １９５５３．７００
Ｓ２  ＝  ３５９１５．３３０
Ｓ３  ＝  １６３６１．７００
であるため、Ｘ２について検定を行うと
Ｔ２  ＝  １．１５３
となる。したがって、Ｔ２  ≧  ｔのため、帰無仮説Ｈ０を棄却する。すなわちＸ２が外れ値である。
【０１９５】
同様にＣＰＵ使用率については、
Ｘ１  ＝  １．１２
Ｘ２  ＝  ６２．８０
Ｘ３  ＝  １．４０
であり、
Ｘ  ＝  ２１．７７３
Ｕ  ＝  ３５．５３０
であり、
Ｓ１  ＝  ２０．６５３
Ｓ２  ＝  ４１．０２７
Ｓ３  ＝  ２０．３７３
であるため、Ｘ２について検定を行うと
Ｔ２  ＝  １．１５５
となる。したがって、Ｔ２  ≧  ｔのため、帰無仮説Ｈ０を棄却する。すなわちＸ２が外れ値である。
【０１９６】
次にノード自体の比較検証手法として、以下の式を用いて、総合的な外れ度Ｈを計算する。
2004355233.tif 000012
αβγは定数であり、本実施例では１とする。
関数ｆ（Ｘｉ、｛Ｘ１．．．ｎ｝）は、Ｘｉが集合｛Ｘ１．．．ｎ｝において外れ値であれば１、外れ値でなければ０を返す。
Ｘｉは実行ノード１７１０−ｉのＨＴＴＰＤのプロセス数、
Ｙｉは実行ノード１７１０−ｉのメモリの消費量、
Ｚｉは実行ノード１７１０−ｉのＣＰＵ使用率である。
【０１９７】
したがって各実行ノードの総合的な外れ度Ｈは、
Ｈ１  ＝  ０＋０＋０  ＝  ０
Ｈ２  ＝  ０＋１＋１  ＝  ２
Ｈ３  ＝  ０＋０＋０  ＝  ０
となる。
【０１９８】
総合的な外れ度Ｈが２以上の実行ノードは異常であるとすると、Ｈ２＝２のため、実行ノード１７１０−２は異常と同定される。この比較検証結果は、比較検証結果Ｍ１７０４として記憶部１７２９に格納される。
【０１９９】
ステップＳ１８０５では、実行管理部１７２４が比較検証結果Ｍ１７０４を読み出し、異常と判定された実行ノードの有無を判定する。異常と判定された実行ノードが無い場合、制御はステップＳ１８０１に戻り、一定期間毎に環境情報の取得と比較検証する処理を再び繰り返す。
【０２００】
前述の例では実行ノード１７１０−２が異常と同定されたため、ステップＳ１８０６では、追加手段１７２５が新たな実行ノードを起動する。どのように、いくつ実行ノードを起動するかは記憶部１７２９に格納された追加ノード起動情報Ｍ１７５に記憶されている。本実施例では３つの実行ノード１７１０−４、１７１０−５、１７１０−６を起動するとする。そして、ステップＳ１８０７へ移行する。
【０２０１】
ステップＳ１８０７では、実行管理部１７２４が、実行ノード１７１０−１〜１７１０−６の数が規定数より多いかどうか判定する。実行ノード１７１０−１〜１７１０−６の数が規定数以下の場合、制御はステップＳ１７０１に戻る。前述した例では、この時点で実行ノード１７１０−１〜１７１０−６の６個が動作しているため、ステップＳ１８０８に制御が移る。
【０２０２】
ステップＳ１７０８およびステップＳ１７０９では、再度各実行ノードの環境情報を取得して比較検証することで、異常な実行ノードを検出する。このステップＳ１８０８およびステップＳ１８０９の動作は、ステップＳ１８０３およびステップＳ１８０４の動作と同一である。その結果、ステップＳ１８０３で異常ノードと同定された実行ノード、先の例では実行ノード１７１０−２が、再度異常ノードと同定される。
【０２０３】
ステップＳ１８１０では、実行管理部１７２４が比較検証結果Ｍ１７０４を読み出し、異常と判定された実行ノードの有無を判定する。異常な実行ノードがある場合、停止手段１７２６が、その実行ノードを停止する（ステップＳ１８１１）。今の場合、異常な実行ノードと同定された実行ノード１７１０−２が停止させられる。そしてステップＳ１８０７に戻り、環境情報の取得と比較検証が繰り返される。
【０２０４】
この環境情報の取得と比較検証が何度か繰り返された状況で、異常な実行ノードが無い場合、安定性判定手段１７２７が、残った実行ノード１７１０−１〜１７１０−６の安定性を判定し、その結果を安定性判定結果Ｍ１７０６として記憶部１７２９に格納する（ステップＳ１８１２）。本実施例では、ステップＳ１８１０において異常ノードが検出されなくなってから、ステップＳ１８０８〜Ｓ１８１０、Ｓ１８１２、Ｓ１８１３のループにおいて一定時間、ステップＳ１８１０において異常ノードが検出されない場合に、安定したと判定する。
【０２０５】
ステップＳ１８１３では、実行管理部１７２４が安定性判定結果Ｍ１７０６を読み出し、安定していないと判定されていた場合は、制御はステップＳ１８０８に戻る。
【０２０６】
一方、安定していると判定されていた場合、選択手段１７２８は規定数Ｘ（＝３）を超えている数だけ、停止させる実行ノードを選択し、その結果を選択結果Ｍ１７０７として記憶部１７２９に格納する（ステップＳ１８１４）。今の例では、この時点で動作してい実行ノードは、実行ノード１７１０−１、１７１０−３〜１７１０−６の５個であるので、２個の実行ノードを停止させる実行ノードとして選択する。また、本実施例では、恣意的な選択による偏りをなくすために、停止させる実行ノードをランダムで選択する。
【０２０７】
次にステップＳ１８１５において、停止手段１７２６は、記憶部１７２９より選択結果Ｍ１７０７を読み出し、選択された実行ノードを停止させる。そして、制御をステップＳ１８０１に戻す
【０２０８】
なお、ステップＳ１８０７〜Ｓ１８１１のループが何度か繰り返されて、実行ノード数が規定数Ｘ（＝３）未満になると、ステップＳ１８０１に移行し、このステップＳ１８０１の判定結果がＹＥＳとなる。このため、追加手段１７２５は、実行ノード１７１０−１〜１７１０−ｎの数が規定数Ｘになるように、新たな実行ノードを起動する（ステップＳ１７０２）。どのように実行ノードを起動するかは記憶部１７２９に格納された追加ノード起動情報Ｍ１７０５に記憶されている。
【０２０９】
以上本発明の実施の形態および実施例について説明したが、本発明は以上の実施の形態および実施例に限定されず、その他各種の付加変更が可能である。また、本発明の各実施の形態および実施例における実行ノードおよび管理ノードは、その有する機能をハードウェア的に実現することは勿論、コンピュータとプログラムとで実現することができる。プログラムは、磁気ディスクや半導体メモリ等のコンピュータ可読記録媒体に記録されて提供され、コンピュータの立ち上げ時などにコンピュータに読み取られ、そのコンピュータの動作を制御することにより、そのコンピュータを前述した各実施の形態および実施例における実行ノードおよび管理ノードとして機能させる。
【０２１０】
【発明の効果】
以上説明したように、本発明によれば、次のような効果が得られる。
【０２１１】
複数のプログラムを複数の実行ノードで並列実行する耐障害システムにおいて、異常な実行ノードを速やかに検出できる。その理由は、プログラムを並列実行中の複数の実行ノードの環境情報を取得して比較することにより、実行結果が出揃う前に異常なノードの検出が行えるからである。
【０２１２】
事前に想定していない障害も検出することができる。その理由は、予め異常値を検出する閾値を固定して異常を検出するのではなく、複数の実行ノードの環境情報を比較して異常なノードの検出を行うからである。
【０２１３】
耐障害システムの実行コストを低減することができる。その理由は、異常ノードを早期に検出してそのノードを停止させるため、無駄なリソースの消費が無くなるからである。また、複数の実行ノードが安定したら、余分な実行ノードを停止させるからである。
【０２１４】
要求に応じた無駄のない耐障害性を提供できる。その理由は、複数の実行ノードが安定したら余分な実行ノードを停止させて実行コストを下げ、再び異常なノードが検出されたら新たな実行ノードを追加して耐障害性を確保するからである。
【０２１５】
それぞれ異なる実行環境を持つ複数の実行ノードで同一のプログラムを並列実行させる構成にあっては、プログラムが１種類で済むため開発コストを低減することができる。
【０２１６】
それぞれ異なる実行環境を持つ複数の実行ノードを仮想マシンで実現する構成にあっては、多種多様な実行環境を実現する実マシンを常時用意しておく必要がなく、多様な実行環境をソフトウェアによって実現できるため、低コストと高い耐障害性の両立が可能である。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態にかかる耐障害システムのブロック図である。
【図２】実行ノードや管理ノードに使用する仮想マシンの説明図である。
【図３】本発明の第１の実施の形態にかかる耐障害システムにおけるシステム起動時の処理例を示すフローチャートである。
【図４】本発明の第１の実施の形態にかかる耐障害システムにおける障害関連処理のフローチャートである。
【図５】本発明の第２の実施の形態にかかる耐障害システムのブロック図である。
【図６】本発明の第２の実施の形態にかかる耐障害システムにおける障害関連処理のフローチャートである。
【図７】本発明の第３の実施の形態にかかる耐障害システムのブロック図である。
【図８】本発明の第３の実施の形態にかかる耐障害システムにおける障害関連処理のフローチャートである。
【図９】本発明の第４の実施の形態にかかる耐障害システムのブロック図である。
【図１０】本発明の第４の実施の形態にかかる耐障害システムにおける障害関連処理のフローチャートである。
【図１１】本発明の第５の実施の形態にかかる耐障害システムのブロック図である。
【図１２】本発明の第５の実施の形態にかかる耐障害システムにおける障害関連処理のフローチャートである。
【図１３】本発明の第６の実施の形態にかかる耐障害システムのブロック図である。
【図１４】本発明の第６の実施の形態にかかる耐障害システムにおけるメッセージ管理手段のブロック図である。
【図１５】本発明の第７の実施の形態にかかる耐障害システムのブロック図である。
【図１６】本発明の第８の実施の形態にかかる耐障害システムのブロック図である。
【図１７】本発明の第５の実施の形態の一実施例にかかる耐障害システムのブロック図である。
【図１８】本発明の第５の実施の形態の一実施例にかかる耐障害システムにおける障害関連処理のフローチャートである。
【符号の説明】
１１０−１〜１１０−ｎ…実行ノード
１１１−１〜１１１−ｎ…プログラム
１１２…実行環境
１１３…演算部
１１４…記憶部
１１５…入出力部
１１６…情報提供部
１２０…管理ノード
１２１…情報取得手段
１２２…比較検証手段
１２３…通知手段
１２４…障害検出部
１２５…実行管理部
１２９…記憶部
１３０…通信経路
【図１】
2004355233.tif 000013
【図２】
2004355233.tif 000014
【図３】
2004355233.tif 000015
【図４】
2004355233.tif 000016
【図５】
2004355233.tif 000017
【図６】
2004355233.tif 000018
【図７】
2004355233.tif 000019
【図８】
2004355233.tif 000020
【図９】
2004355233.tif 000021
【図１０】
2004355233.tif 000022
【図１１】
2004355233.tif 000023
【図１２】
2004355233.tif 000024
【図１３】
2004355233.tif 000025
【図１４】
2004355233.tif 000026
【図１５】
2004355233.tif 000027
【図１６】
2004355233.tif 000028
【図１７】
2004355233.tif 000029
【図１８】
2004355233.tif 000030