JP2004295738A - 耐障害計算機システム、プログラム並列実行方法およびプログラム - Google Patents
耐障害計算機システム、プログラム並列実行方法およびプログラム Download PDFInfo
- Publication number
- JP2004295738A JP2004295738A JP2003089880A JP2003089880A JP2004295738A JP 2004295738 A JP2004295738 A JP 2004295738A JP 2003089880 A JP2003089880 A JP 2003089880A JP 2003089880 A JP2003089880 A JP 2003089880A JP 2004295738 A JP2004295738 A JP 2004295738A
- Authority
- JP
- Japan
- Prior art keywords
- computer program
- fault
- unit
- node
- management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1492—Generic software techniques for error detection or fault masking by run-time replication performed by the application software
- G06F11/1494—N-modular type
Abstract
【課題】同一の計算機プログラムを使用してソフトウェアレベルで耐障害性を高めることのできる耐障害計算機システムを提供する。
【解決手段】複数の計算ノード１の計算機プログラム実行環境（ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境）は、それぞれ異なるように設定され、管理ノード２の制御の下に同一の計算機プログラム４を並列に実行する。ソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するため、複数の計算ノード１の計算機プログラム実行環境をそれぞれ異ならせて計算機プログラム４を並列実行させることにより、計算機プログラム４に存在する特定のバグが活性化する特定の状態が全ての計算ノード１に同時に起きるのを防止する。
【選択図】 図１
【解決手段】複数の計算ノード１の計算機プログラム実行環境（ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境）は、それぞれ異なるように設定され、管理ノード２の制御の下に同一の計算機プログラム４を並列に実行する。ソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するため、複数の計算ノード１の計算機プログラム実行環境をそれぞれ異ならせて計算機プログラム４を並列実行させることにより、計算機プログラム４に存在する特定のバグが活性化する特定の状態が全ての計算ノード１に同時に起きるのを防止する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は計算ノードを複数備えた計算機システムに関し、特にプログラムレベルでの耐障害性能を高めた計算機システムに関する。
【０００２】
【従来の技術】
耐障害計算機システムは、構成要素の故障は避けられないという観点から、計算ノードの冗長化によって信頼性を高めた計算機システムである。例えば、後述する非特許文献１には、プロセッサとメモリからなる多数の計算ノードをバスに接続し、全ての処理を適当な大きさのタスクに分割して、各タスクを複数の計算ノードで同時に実行し、各タスクの実行結果から多数決によりシステムの出力を導出することにより、単一の計算ノードに障害が発生してもシステム外部からは正常時と全く同じ振る舞いをする耐障害計算機システムが示されている。この耐障害計算機システムは、主にハードウェアレベルでの耐障害性の向上を狙ったものであり、計算ノードは全て同じ構成を有し、タスクは同一の計算機プログラムにより各計算ノードで並列実行することを前提としている。このため、計算機プログラムにバグがあると、ソフトウェアフォールトによって全てのタスクが異常終了する確率が高く、ソフトウェアレベルでの耐障害性の向上は難しい。
【０００３】
そこで、ソフトウェアレベルでの耐障害性の向上を目的とした従来技術として、後述する非特許文献２には、複数の異なる開発者によってそれぞれ異なる手法で作成された同一の機能を達成する複数の計算機プログラムを計算機システムで並列に実行し、複数の計算機プログラムの出力結果から多数決によりシステムの出力を導出する技術が示されている。
【０００４】
他方、耐障害計算機システムに限らず通常の計算機システムにおいても、障害が発生した場合には速やかに障害の回復が試行される。従来の計算機システムにおける障害に対する回復方法の一例が、後述する特許文献１に記載されている。この従来システムでは、いわゆるチェックポインティングと呼ばれる手法で、ある時点での計算機プログラムの実行状態を保存しておき、さらに計算機プログラムの実行過程を詳細に記録しておくことで、障害が発生した場合に、障害発生前に保存したチェックポインティングのデータから、計算機プログラムの実行状態を復元し、さらにプログラムの実行過程を再現することで、計算機システムを障害から回復させることを試みる手法が述べられている。
【０００５】
チェックポインティングと類似した手法として、バックアップが一般的に知られている。バックアップは、計算機のハードディスク上のデータをテープなどの別の媒体に保存することであるが、チェックポインティングは、計算機プログラムにおける内部変数や実行位置を含めた状態の動的なデータも保存する点で異なる。そのため、確実なチェックポインティングを行うためには、内部変数が変更中での保存を避けたり、実行位置が明確に分かる保存をする必要がある。通常のチェックポインティング機能は、計算機プログラム本体に組み込まれるが、特許文献１記載の発明のように、チェックポインティングをデータの入出力のタイミングと同期させることで、チェックポインティング機能をプログラムに組み込むことを不要にする手法もある。
【０００６】
一方、障害の原因が発生してから、障害が顕在化し、検知されるまで、ある程度の時間が経過するために、どの時点で保存したチェックポインティングのデータを復元すればよいかが分からないという問題がある。従来は、計算機プログラムが出力するログや、障害が検知された時点でのプログラムの実行状態のダンプデータなどから、システム運用者が手間と時間をかけて、原因を解明し、その後適切なチェックポインティングデータを選択し、システムの回復作業を行っていた。後述する特許文献２のように、チェックポインティングのデータを管理しておき、障害時にそのチェックポインティングのデータを自動的に１つずつ試していくことで、適切なチェックポインティングデータを探索し、システムの回復作業の手間を省く手法も知られている。
【０００７】
チェックポインティングしたデータを復元し、プログラムを再スタートする際の「再スタート」にもさまざまな手法が知られている。現在のパーソナルコンピュータ製品においては、ＡＣＰＩ（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ）と呼ばれる計算機の実行状態を制御する規格が、広く採用されている。ＡＣＰＩにおいては、計算機の一時停止状態がいくつか定義されており、一時停止状態からの再スタート方式について述べられている。その中でも、次のような計算機の一時停止と再スタートが広く利用されている。一つは、計算機の主記憶の状態をそのままにして、ＣＰＵを停止する方法で、いわゆるＳＴＲ（Ｓｕｓｐｅｎｄ Ｔｏ ＲＡＭ）と呼ばれる方法である。もう一つは、計算機の主記憶・仮想記憶の状態をハードディスクに保存し、ＯＳを停止し、ＯＳの再起動時に保存した主記憶・仮想記憶の状態を復元する方法で、いわゆるＳＴＤ（Ｓｕｓｐｅｎｄ Ｔｏ Ｄｉｓｋ）と呼ばれる手法である。また一般的に、次のような計算機プログラムの再スタートを行うことも多い。一つは、ＯＳ上で、計算機プログラムのプロセスを停止後、プロセスを再起動する方法である。再実行とも言う。もう一つは、ＯＳを停止させて、ＯＳを再起動後、当該プロセスを起動する方法である。さらに、ＯＳの停止に関して、強制的な電源断によるような方法（リセット）と、ＯＳに対してシャットダウン処理を行って、停止する方法がある。これらの多様な計算機プログラムの再スタート、つまり実行環境の変更は、計算機プログラムや障害の種類、回復までの時間や手間の容易性、データ復元の安全性などを考慮して、システム運用者が判断して行っている。
【０００８】
【非特許文献１】
社団法人情報処理学会編，「新版 情報処理ハンドブック」，第１版，株式会社オーム社，平成７年１１月２５日、ｐ４５９−４６１
【非特許文献２】
「Ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ ｂｙ ｄｅｓｉｇｎ ｄｉｖｅｒｓｉｔｙ： Ｃｏｎｃｅｐｔｓ ａｎｄ ｅｘｐｅｒｉｍｅｎｔｓ」（Ａｖｉｚｉｅｎｉｓ， Ａ．， Ｋｅｌｌｙ， Ｊ．Ｐ．Ｊ．， ＩＥＥＥ Ｃｏｍｐｕｔｅｒ ｖｏｌ．１７， ｎｏ．８， ｐｐ：６７−８０， １９８４．）
【特許文献１】
特表２００２−５０５７６８号公報
【特許文献２】
特許第３２９００５２号公報
【０００９】
【発明が解決しようとする課題】
ソフトウェアレベルでの耐障害性を高めるために、非特許文献２に記載されるように同一の機能を達成する複数の計算機プログラムを用いる方法は、プログラムの開発に多大な労力と費用を必要とする。従って、開発コストを低減するために、同一の計算機プログラムを使用してソフトウェアレベルで耐障害性を高めることのできる技術が望まれている。
【００１０】
また、何れかの計算ノードが障害になった場合、その障害を復旧するための回復処理を行うことは当然であるが、その際、再び同じような障害を招かないような有益な方法が望まれる。
【００１１】
更に、耐障害計算機システムに特許文献１または２に記載のチェックポインティングによる障害からの回復手法を単に適用しただけでは、どのチェックポインティングデータから計算機プログラムを再スタートすれば良いのかを解明するまでに時間がかかるため、より短時間に解明できる有益な方法が望まれる。
【００１２】
本発明の目的は、同一の計算機プログラムを使用してソフトウェアレベルで耐障害性を高めることのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１３】
本発明の別の目的は、計算ノードが障害状態に陥った場合に、再び同じような障害ができるだけ発生しないようにすることのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１４】
本発明の更に別の目的は、チェックポインティング手法による障害からの回復時間を短縮することのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１５】
【課題を解決するための手段】
本発明の耐障害計算機システムは、それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行することを基本とする。具体的には、本発明の第１の耐障害計算機システムは、それぞれ異なる計算機プログラム実行環境の下で同一の計算機プログラムを並列に実行する複数の計算ノードと、前記複数の計算ノード毎のプログラム実行状態および計算機プログラム実行環境設定データを記憶する記憶手段と、前記記憶手段に記憶された計算機プログラム実行環境設定データに基づいて各計算ノード毎にその計算ノードの計算機プログラム実行環境の設定を行う実行環境設定手段と、前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を分配する処理要求分配手段と、前記各計算ノードの障害の有無を監視し障害発生時には障害対応処理を実施する障害管理手段と、前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出する処理結果導出手段とを備えている。
【００１６】
ここで、それぞれ異なる計算機プログラム実行環境とは、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類の環境の少なくとも１つの環境が異なることによって、計算機プログラム実行環境間の相違度が所定の相違度以上異なることである。
【００１７】
また、ハードウェア環境が異なるとは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類のうちの少なくとも１つが異なることである。
【００１８】
また、ソフトウェア環境が異なるとは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのうち少なくとも１つの種類やバージョンが異なることである。
【００１９】
また、外部接続機器環境が異なるとは、外部記憶装置、表示装置、入力装置、通信装置のうち少なくとも１つの種類や仕様が異なることである。
【００２０】
また、プログラム起動環境が異なるとは、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムとＯＳの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動のうちの異なる再起動方法を用いることである。
【００２１】
本発明の第２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害にかかる前記計算ノードの計算機プログラム実行環境を変更して前記計算機プログラムを再実行させる。
【００２２】
本発明の第３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害にかかる前記計算ノードにおける計算機プログラムの実行状態を変更して前記計算機プログラムを再実行させる。
【００２３】
本発明の第４の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせる。
【００２４】
本発明の第５の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記処理要求分配手段は、前記障害管理手段によってシステムの状態に応じて更新される分配先情報を記憶する分配先情報記憶部と、処理要求である処理サービスの要求メッセージを受信する要求メッセージ受信部と、前記要求メッセージをシステム内のどの計算ノードで処理するかを前記分配先情報に基づいて判断する処理判断部と、分配先の計算ノードに前記要求メッセージを転送するための転送メッセージを生成する要求転送メッセージ生成部と、生成された要求転送メッセージを転送先の計算ノードに転送する要求転送メッセージ送信部とを備える。
【００２５】
本発明の第６の耐障害計算機システムは、第５の耐障害計算機システムにおいて、前記処理結果導出手段は、応答生成条件および前記障害管理手段によってシステムの状態に応じて更新される分配先情報を含む判断基準情報を記憶する判断基準情報記憶部と、前記処理サービスの応答メッセージおよびデータベースアクセスなどの処理途中の別サービス要求メッセージを前記計算ノードから受信する応答メッセージ受信部と、前記受信した応答メッセージおよび別サービス要求メッセージを一時的に記憶する応答メッセージ保持部と、前記応答メッセージ保持部に保持された応答メッセージおよび別サービス要求メッセージをどのように処理するかを前記判断基準情報に基づいて判断する応答処理判断部と、応答メッセージおよび別サービス要求メッセージをサービス要求元および別サービス要求先に転送するための応答転送メッセージを生成する応答転送メッセージ生成部と、生成された応答転送メッセージをサービス要求元または別サービス要求先に転送する応答転送メッセージ送信部とを備える。
【００２６】
本発明の第７の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２７】
本発明の第８の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２８】
本発明の第９の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２９】
本発明の第１０の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００３０】
本発明の第１１の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３１】
本発明の第１２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３２】
本発明の第１３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３３】
本発明の第１４の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記処理要求分配手段を備え、前記複数の計算ノードに備わる複数の処理要求分配手段によって処理要求の分配処理を分散して行うものである。
【００３４】
本発明の第１５の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記障害管理手段および前記記憶手段を備える。
【００３５】
本発明の第１６の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害を検知し障害情報を送信する第１の手段と前記障害検知手段から障害情報を受信しシステム全体として障害を管理する第２の手段とで構成され、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記第２の手段と前記記憶手段を備え、前記複数の計算ノードのそれぞれに前記第１の手段を備える。
【００３６】
本発明の第１７の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記管理ノードに前記障害管理手段を備える。
【００３７】
本発明の第１８の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記管理ノードに前記障害管理手段を備える。
【００３８】
本発明の第１９の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノード毎に前記障害管理手段を備え、前記複数の計算ノードに備わる複数の前記障害管理手段によってシステム全体の障害の管理を分散的に行うものである。
【００３９】
本発明の第２０の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４０】
本発明の第２１の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４１】
本発明の第２２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４２】
本発明の第２３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部とジョブ管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出する処理を、前記複数の計算ノードに備わる複数の前記処理結果導出手段によって分散的に行うものである。
【００４３】
本発明の第２４の耐障害計算機システムは、第１乃至第２３の耐障害計算機システムにおいて、前記計算ノードに実マシンを用いる。
【００４４】
本発明の第２５の耐障害計算機システムは、第１乃至第２３の耐障害計算機システムにおいて、前記計算ノードに仮想マシンを用いる。
【００４５】
他方、本発明のプログラム並列実行方法は、それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行することを基本とする。具体的には、本発明の第１のプログラム並列実行方法は、複数の計算ノードを備える計算機システムにおけるプログラム並列実行方法において、（ａ）複数の計算ノードのそれぞれに、異なる計算機プログラム実行環境を設定するステップ、（ｂ）前記複数の計算ノードで、同一の計算機プログラムを並列実行するステップ、（ｃ）前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を処理させるステップ、（ｄ）前記複数の計算ノードの動作状態を監視し障害を検知したときに障害対応処理を行うステップ、（ｅ）前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップを有する。
【００４６】
また、本発明の第２のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラム実行環境を変更し、前記計算機プログラムを再実行する。
【００４７】
また、本発明の第３のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラムの実行状態を変更し、前記計算機プログラムを再実行する。
【００４８】
また、本発明の第４のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせる。
【００４９】
【作用】
一般にソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するため、複数の計算ノードの計算機プログラム実行環境をそれぞれ異ならせて計算機プログラムを並列実行させる本発明にあっては、計算機プログラムに存在する特定のバグが活性化する特定の状態が全ての計算ノードで同時に起き難くなり、同一の計算機プログラムを使用して、ソフトウェアレベルでの耐障害性を高めることができる。
【００５０】
また、障害にかかる計算ノードの計算機プログラム実行環境を変更して計算機プログラムを再実行することにより、計算機プログラムに存在する特定のバグが活性化する特定の状態の再発生を防止し、再び同じような障害が発生するのを防止することができる。
【００５１】
また、複数の計算ノードで障害が発生し、チェックポインティング手法で障害からの回復を試みる際、複数の計算ノードにおいて異なるチェックポインティングデータから計算機プログラムを並列に再実行させることにより、どのチェックポインティングデータから計算機プログラムを再起動すれば障害が回復するかが短時間で解明でき、チェックポインティング手法による障害からの回復時間を短縮することができる。
【００５２】
【発明の第１の実施の形態】
図１を参照すると、本発明の第１の実施の形態にかかる耐障害計算機システムは、複数の計算ノード１と、これら複数の計算ノード１を管理する少なくとも１つの管理ノード２と、これら複数の計算ノード１および管理ノード２を互いに通信可能に接続する通信経路３とを含んで構成される。
【００５３】
計算ノード１は、少なくとも１つのプロセッサ５と、メモリ６と、並列実行対象となる計算機プログラム４と、自計算ノードにおける計算機プログラム実行環境の設定機能、計算機プログラム４をメモリ６に読み込んで実行させるなどのプロセス管理機能および通信経路３を介してのデータの送受信機能を持つプログラム実行管理部７とを含んで構成される。計算機プログラム４は、管理ノード２から与えられる処理要求を処理し、その処理結果を管理ノード２に返却するアプリケーションプログラムであり、全ての計算ノード１で同一のアプリケーションプログラムが使用される。
【００５４】
管理ノード２は、各計算ノード１毎のプログラム実行状態（チェックポインティングデータなど）および計算機プログラム実行環境の設定データなどを記憶する記憶部１３と、複数の計算ノード１において並列実行される複数の計算機プログラム４の実行状態を管理し、システムの状態を考慮してジョブ（処理要求）の管理を行うジョブ管理部８と、システム全体における障害の状態を監視し、障害発生時には障害対応処理を実行する障害管理部９とを含んで構成される。
【００５５】
通信経路３は、バス、シリアル、パラレル、ＬＡＮ、無線ＬＡＮ、インターネット、公衆回線などの任意の通信回線であり、また複数を組み合わせた多重化通信回線であっても良い。
【００５６】
ここで、個々の計算ノード１および管理ノード２は、例えば１台のパーソナルコンピュータ（ＰＣ）や大型計算機の１つのセルなど、物理的に存在する実マシンであっても良いし、仮想マシンであっても良い。また、全ての計算ノード１および管理ノード２を、全て実マシンで実現しても良いし、全て仮想マシンで実現しても良く、一部の計算ノード１は仮想マシンで、残りの計算ノード１は実マシンで実現する如く、仮想マシンと実マシンとが混在していても良い。
【００５７】
仮想マシンは、図２の仮想マシン１１に示されるように、物理的な計算機１２とその上で実行される仮想マシンモニタと呼ばれる制御ソフトウェア１３とで実現される仮想マシン実行環境１４を利用して、ソフトウェアで実現される計算機であり、計算機シュミレータあるいは計算機エミュレータとも呼ばれる。仮想マシンは、実マシンと論理的には全く同じ動作をする。同じ仮想マシン実行環境１４上に１つまたは複数の仮想マシン１１を実現することができ、各々の仮想マシン１１は独自の機器構成をとることができる。仮想マシン１１が備えるプロセッサやメモリ等の資源は仮想資源と呼ばれる。制御ソフトウェア１３の最も基本的な機能は、仮想マシン１１が備える仮想資源と計算機１２が備える実資源とのマッピング機能である。
【００５８】
このように仮想マシンはソフトウェアで実現されているので、必要な時にのみ存在する。つまり、必要な時に仮想マシンは生成され、不要となると消去される。そのため、計算ノード１に仮想マシンを使用すると、常時多様な環境を実現する計算機および機器を用意する必要なく、コストの削減が可能となる。また、仮想マシンは、ソフトウェアで実現されているので、主記憶メモリのサイズなど各種のパラメータ設定の変更が容易であり、多様な実行環境を指定することが容易である。
【００５９】
本実施の形態の耐障害計算機システムは、複数の計算ノード１にそれぞれ異なる計算機プログラム実行環境を設定し、その異なる計算機プログラム実行環境で同一の計算機プログラム４を並列実行することを基本とする。
【００６０】
計算機プログラム実行環境は、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類に大別され、この４種類のうちの少なくとも１種類が相違すると、異なる計算機プログラム実行環境となる。
【００６１】
ハードウェア環境とは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類などのことである。これらハードウェア環境を規定する計算機の主記憶容量などをハードウェア環境パラメータと呼ぶ。ハードウェア環境パラメータの１つでも互いに相違するハードウェア環境は異なるハードウェア環境となる。
【００６２】
ソフトウェア環境とは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのバージョンのことである。基本ソフトウェアとは、インターネットブラウザ、ファイアーウォール、ウィルスチェッカーなどのように、常時実行されるために、計算機プログラムの動作に影響を与えるもののことである。各種デバイスドライバとは、ディスクドライバなどのことである。各種ライブラリとは、動的リンクライブラリなどのことである。また、これらのソフトウェアに対する修正パッチ、セキュリティパッチの適用・未適用の設定もソフトウェア環境の一つである。さらに、ＯＳ、基本ソフトウェア、ライブラリの動作を規定するレジストリ、セキュリティポリシー、アクセスポリシーなどのコンフィグレーションファイルの設定状態もソフトウェア環境に含まれる。これらソフトウェア環境を規定するＯＳのバージョンなどをソフトウェア環境パラメータと呼ぶ。ソフトウェア環境パラメータの１つでも互いに相違するソフトウェア環境は異なるソフトウェア環境となる。
【００６３】
外部接続機器環境とは、計算機に接続されている外部記憶装置、表示装置、入力装置、通信装置などの仕様のことである。例えば、シリアルポート、ディスプレイ、ハードディスク、ネットワーク、キーボード、マウス、タブレット、プリンタ、スピーカーなどの仕様である。これら外部接続機器環境を規定する外部記憶装置の仕様を外部接続機器環境パラメータと呼ぶ。外部接続機器環境パラメータの１つでも互いに相違する外部接続機器環境は異なる外部接続機器環境となる。
【００６４】
プログラム起動環境とは、計算機プログラムの起動方法の種類であり、具体的には、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムとＯＳの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動といったプログラム起動方法の種類である。これらプログラム起動環境を規定する起動方法の種類はプログラム起動環境のパラメータの１つである。また、計算機プログラムをチェックポインティングしたデータから再スタートさせる際に、どの時点でチェックポインティングしたデータから再スタートするかもプログラム起動環境のパラメータの１つである。さらに、計算ノードが活性化する条件もプログラム起動環境のパスワードに含まれる。例えば、ある計算ノードは、システムが運用開始と同時に活性化し、別の計算ノードは、別の計算ノードの停止または負荷増加のイベント通知を受けて活性化するなどの如きものである。プログラム起動環境パラメータの１つでも互いに相違するプログラム起動環境は異なるプログラム起動環境となる。
【００６５】
本実施の形態においては、管理ノード２の記憶部１０における計算機プログラム実行環境定義領域に、各計算ノード１毎の計算機プログラム実行環境設定データが定義されており、且つそれぞれの計算ノード１の計算機プログラム実行環境設定データは互いに異なるように定義されている。各計算ノード１のプログラム実行管理部７は、管理ノード２のジョブ管理部８から自身の計算機プログラム実行環境の情報を取得し、その情報を用いて自計算ノード１の実行環境を設定し、計算プログラム４を読み込み、他の計算ノード１と並列に実行する。
【００６６】
ここで、計算機プログラム４に存在する特定のバグが活性化する特定の状態を全ての計算ノード１で同時に起き難くするためには、計算ノード１どうしの計算機プログラム実行環境の相違度を或る程度以上大きくするのが望ましい。何故なら、他の環境やパラメータは全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するだけでは殆ど効果がないからである。そこで、本実施の形態では、複数の計算ノードの任意の２つの計算ノード間の計算機プログラム実行環境の相違度は、予め定められた相違度以上に相違するように定められている。以下、この点について説明する。
【００６７】
今、２つの計算ノードＸ、Ｙの計算機プログラム実行環境の相違度をＤＸＹとし、次式に示すように定義する。
ＤＸＹ＝ａＤＨ＋ｂＤＳ＋ｃＤＧ＋ｄＤＫ …（１）
【００６８】
ここで、ＤＨは計算ノードＸ、Ｙのハードウェア環境の相違度、ＤＳは計算ノードＸ、Ｙのソフトウェア環境の相違度、ＤＧは計算ノードＸ、Ｙの外部接続機器環境の相違度、ＤＫは計算ノードＸ、Ｙのプログラム起動環境の相違度をそれぞれ示す。ａ，ｂ，ｃ，ｄは重み付けの変数であり、全て同じ値を使えば各環境の相違度を公平に考慮することができ、他のものに比べて大きな値を用いればその環境の相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００６９】
ハードウェア環境の相違度ＤＨは、ハードウェア環境のパラメータ数をｒ個とすると、次式で定義される。
ＤＨ＝ｈ１｜ＤＨＸ１−ＤＨＹ１｜＋ｈ２｜ＤＨＸ２−ＤＨＹ２｜＋ … ＋ｈｒ｜ＤＨＸｒ−ＤＨＹｒ｜ …（２）
【００７０】
ここで、ＤＨＸｉ（ｉ＝１〜ｒ）は計算ノードＸのハードウェア環境のｉ番目のパラメータ、ＤＨＹｉ（ｉ＝１〜ｒ）は計算ノードＹのハードウェア環境のｉ番目のパラメータ、｜ＤＨＸｉ−ＤＨＹｉ｜は計算ノードＸ、Ｙのハードウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、メモリ６の相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、プロセッサ５の相違度は、種類が同じで且つバージョンが同じであれば相違度０、種類が同じであるがバージョンが異なれば相違度１、種類が異なれば相違度２の如く定められる。また、キャッシュの有効、無効のパラメータなど、取り得る状態が２つしか無いパラメータの場合、両者が同じ状態であれば相違度０、異なっていれば相違度１とする。ｈｉ（ｉ＝１〜ｒ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７１】
ソフトウェア環境の相違度ＤＳは、ソフトウェア環境のパラメータ数をｓ個とすると、次式で定義される。
ＤＳ＝ｓ１｜ＤＳＸ１−ＤＳＹ１｜＋ｓ２｜ＤＳＸ２−ＤＳＹ２｜＋ … ＋ｓｓ｜ＤＳＸｓ−ＤＳＹｓ｜ …（３）
【００７２】
ここで、ＤＳＸｉ（ｉ＝１〜ｓ）は計算ノードＸのソフトウェア環境のｉ番目のパラメータ、ＤＳＹｉ（ｉ＝１〜ｓ）は計算ノードＹのソフトウェア環境のｉ番目のパラメータ、｜ＤＳＸｉ−ＤＳＹｉ｜は計算ノードＸ、Ｙのソフトウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ＯＳの相違度は、同じ種類で且つバージョンが同じであれば相違度０、同じ種類のＯＳであるがバージョンが異なれば相違度１、異なる種類のＯＳであれば相違度２の如く定められる。ウィルスチェッカーなど、実装の有無も相違する場合、例えば、共に実装されていてバージョンが同じであれば相違度０、同じ種類のプログラムであるがバージョンが異なれば相違度１、異なる種類のプログラムであれば相違度２、実装の有無が相違すれば相違度３の如く定められる。ｓｉ（ｉ＝１〜ｓ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７３】
外部接続機器環境の相違度ＤＧは、外部接続機器環境のパラメータ数をｔ個とすると、次式で定義される。
ＤＧ＝ｇ１｜ＤＧＸ１−ＤＧＹ１｜＋ｇ２｜ＤＧＸ２−ＤＧＹ２｜＋ … ＋ｇｔ｜ＤＧＸｔ−ＤＧＹｔ｜ …（４）
【００７４】
ここで、ＤＧＸｉ（ｉ＝１〜ｔ）は計算ノードＸの外部接続機器環境のｉ番目のパラメータ、ＤＧＹｉ（ｉ＝１〜ｔ）は計算ノードＹの外部接続機器環境のｉ番目のパラメータ、｜ＤＧＸｉ−ＤＧＹｉ｜は計算ノードＸ、Ｙの外部接続機器環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ハードディスクの相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、プリンタの相違度は、共に実装されていて同じ種類であれば相違度０、共に実装されているが種類や仕様が異なれば相違度１、実装の有無が相違すれば相違度３の如く定められる。ｇｉ（ｉ＝１〜ｔ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７５】
プログラム起動環境の相違度ＤＫは、プログラム起動環境のパラメータ数をｕ個とすると、次式で定義される。
ＤＫ＝ｋ１｜ＤＫＸ１−ＤＫＹ１｜＋ｋ２｜ＤＫＸ２−ＤＫＹ２｜＋ … ＋ｋｕ｜ＤＫＸｕ−ＤＫＹｕ｜ …（５）
【００７６】
ここで、ＤｋＸｉ（ｉ＝１〜ｕ）は計算ノードＸのプログラム起動環境のｉ番目のパラメータ、ＤｋＹｉ（ｉ＝１〜ｕ）は計算ノードＹのプログラム起動環境のｉ番目のパラメータ、｜ＤｋＸｉ−ＤｋＹｉ｜は計算ノードＸ、Ｙのプログラム起動環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、再起動方法の相違度は、種類が同じであれば相違度０、種類が異なれば相違度１の如く定められる。ｋｉ（ｉ＝１〜ｕ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７７】
各計算ノード１の計算機プログラム実行環境の選定に際しては、式（１）で計算される任意の２つの計算ノード間の計算機プログラム実行環境の相違度が、予め定められた閾値の相違度よりも大きくなるように選定される。これにより、他の環境は全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するような２つの計算機プログラム実行環境を設定するような事態を防止することができる。また、閾値を高く設定すれば、複数の計算ノード１で計算機プログラム４に存在するバグが同時に発現する確率をより小さくすることができる。
【００７８】
図３は本実施の形態の耐障害計算機システムにおける処理の流れを示すフローチャートであり、システム上で稼動するプログラムによって実行される。以下、図３を参照して、本実施の形態の耐障害計算機システムの動作の概略を説明する。
【００７９】
システムが起動されると、複数の計算ノード１が互いに異なる計算機プログラム実行環境で同一の計算機プログラム４が並列実行されるように、各計算ノード１に計算機プログラム実行環境の設定が行われる（Ｓ１０１〜Ｓ１０４）。各計算ノード１の実行環境の設定後、システムは、各計算ノード１で計算機プログラム４を並列実行する通常運用状態となる。
【００８０】
通常運用状態では、ジョブ管理部８および障害管理部９においてシステムの状態を取得し（Ｓ１０５）、取得したシステムの状態に応じた処理を行う。ステップＳ１０５で取得するシステムの状態は、システム全体の終了命令が発行されたかどうか、障害が検出されたかどうか、計算機プログラム４で処理すべき新たな処理要求が発生したかどうか、計算機プログラム４で処理要求に対する処理が終了したかどうかなどである。また、チェックポインティング手法による障害回復を行うために、チェックポインティングデータを各計算ノード１で採取し、プログラム実行管理部７を通じて通信経路３経由で管理ノード２へ送信し、ジョブ管理部８が記憶部１０における各計算ノード毎のプログラム実行状態記憶領域に保存する処理も、このシステム状態取得で実施される。各計算ノード１におけるチェックポインティングデータの採取方法は当業者に良く知られた方法なので説明は省略する。
【００８１】
システム全体の終了命令が発行された場合（Ｓ１０６でＹｅｓ）、終了処理が行われ（Ｓ１０７）、すべてのノードが停止する。障害が検出された場合（Ｓ１０８でＹｅｓ）、障害対応処理が実行され（Ｓ１０９）、その後にシステム状態の取得ステップＳ１０５に戻り、システムの運用を継続する。新たな処理要求が発生した場合（Ｓ１１０でＹｅｓ）、その処理要求を複数の計算ノード１上の計算機プログラム４に処理させるための処理要求処理が実行され（Ｓ１１１）、その後、システム状態の取得ステップＳ１０５に戻る。計算機プログラム４で処理要求に対する処理が終了した場合（Ｓ１１２でＹｅｓ）、システムとしての処理結果を導出するための処理結果処理が実行され（Ｓ１１３）、再びシステム状態の取得ステップＳ１０５に戻る。
【００８２】
次に、各段階における動作の詳細を説明する。
【００８３】
（１）計算機プログラム実行環境の設定（図３のＳ１０１〜Ｓ１０４）
管理ノード２のジョブ管理部８は、内部の変数Ｎを１に初期設定し（Ｓ１０１）、複数存在する計算ノード１のうち１番目の計算ノードに注目し、その計算ノード１のプログラム実行管理部７と協調して、その計算ノード１の計算機プログラム実行環境を設定する（Ｓ１０２）。ジョブ管理部８は、１つの計算ノードに対する計算機プログラム実行環境の設定を終えると、変数Ｎを１加算し（Ｓ１０４）、２番目の計算ノードに対して同様の処理を繰り返す。これを、必要な全ての計算ノード１に対する処理が終るまで（Ｓ１０３でＹｅｓ）、繰り返す。ステップＳ１２の処理例を以下に示す。
【００８４】
（ａ）計算ノード１が実マシンの場合
ジョブ管理部８は、計算ノード１に対して遠隔操作などで電源オンの命令を送信する。この命令によって起動した計算ノード１は、起動途中で、プログラム実行管理部７により自身の計算機プログラム実行環境をジョブ管理部８に問い合せる。ジョブ管理部８は、記憶部１０から、その計算ノード用のプログラム実行環境設定データを読み出し、応答する。プログラム実行管理部７は、応答されたプログラム実行環境設定データを用いて、自計算ノードの実行環境を設定する。具体的には、例えば計算ノードが一般的なＰＣの場合、プログラム実行管理部７は、実行環境の設定をＢＩＯＳに保存して再起動し、再起動後、プログラム実行管理部７は計算機プログラム４の処理を開始させる。
【００８５】
（ｂ）計算ノード１が仮想マシンの場合
仮想マシンの実行環境は、その仮想マシンを実現している実マシン上にあるファイルで指定される。従って、ジョブ管理部８は、計算ノード（仮想マシン）を実現している実マシン上の該当するファイルを、記憶部１０から読み出した当該計算ノード用の設定データで更新し、その仮想マシンのプロセスを起動する。起動後、その計算ノード（仮想マシン）のプログラム実行管理部７が計算機プログラム４の処理を開始する。
【００８６】
他の方法として、異なる実行環境をもつ計算ノードを予め多数用意しておき、ジョブ管理部８がどの計算ノードを活性化させるかを制御することで、それぞれ計算機プログラム実行環境の異なる複数の計算ノードを起動するようにしても良い。この場合、計算ノードが実マシンのときは、遠隔操作による電源オンの命令の送信により起動され、仮想マシンのときはそのプロセスの起動命令の送信により行われる。
【００８７】
（２）システム全体の終了命令関連（図３のＳ１０５、Ｓ１０７）
システム全体の終了命令は、システム運用者からの入力、タイマーなどのイベントをトリガーとして発行される。システム全体の終了命令は、管理ノード２で検出され、各計算ノード１に通知される。具体的な制御命令は、記憶部１０に保持された各計算ノード１毎のプログラム実行環境設定データに応じて、ジョブ管理部８から発行される。これにより、例えば、或る計算ノード１は、チェックポインティング処理を行い、そのチェックポインティングデータを磁気テープなどにコピーする処理を行って、シャットダウン処理を行う。他の計算ノード１では、例えば、自計算ノード１にＵＰＳ装置など電源装置が接続されていれば、その電源装置を介して電源断の処理を行う。また、他の計算ノード１では、主記憶・仮想記憶の状態を保持したまま停止するＳＴＲ（Ｓｕｓｏｐｅｎｄ ｔｏ ＲＡＭ）を行う。
【００８８】
（３）障害関連処理（図３のＳ１０５、Ｓ１０９）
障害の発生の有無をチェックする手法については、ｐｉｎｇ−ｐｏｎｇ方式など従来より様々な手法が存在し、本発明はこれらの任意の手法の一つ或いは複数を組み合わせて用いることができる。例えば、ｐｉｎｇ−ｐｏｎｇ方式を用いる場合、障害管理部９が通信経路３を介し、ｐｉｎｇ−ｐｏｎｇ方式のハートビート信号を用いて各計算ノード１の動作状況を調べ、障害の発生の有無をチェックする。ハートビート信号とは、例えばＩＰネットワークのｐｉｎｇがよく知られている。管理ノード２からＩＰネットワーク上にあるデバイス（この場合には計算ノード１）に対して、インターネット制御プロトコル（ＩＣＭＰ）でｐｉｎｇ信号を発行する。一方、計算ノード１は、ｐｉｎｇ信号を受けると、ｐｏｎｇ信号を発行して応答する。管理ノード２は各計算ノード１からｐｏｎｇ信号を受けることで、管理ノード２とその計算ノード１が、ＩＰネットワークレベルで正常に動作していることを確認する。このようなｐｉｎｇ−ｐｏｎｇ方式の通信を、一定時間間隔で行うことで、ハートビート信号による障害の有無のチェックを行う。
【００８９】
次に、発生した障害に対する障害対応処理（Ｓ１０９）について説明する。
【００９０】
図４はステップＳ１０９で実施される障害対応処理の一例を示すフローチャートである。障害管理部９は、障害を検知すると、予め内部に設定されている障害対応テーブル（図示せず）を検索して、発生した障害に対して実行すべき障害対応方法を取得し（Ｓ１２１）。この取得した障害対応方法を実行する命令を発行する（Ｓ１２２）。具体的には、障害対応テーブルには、障害の種類毎の障害コードと、その種類の障害に対して実行すべき障害対応方法のコマンドとがペアで設定されており、検知した障害の障害コードでテーブルを検索してコマンドを取得し、そのコマンドを発行する。次に、障害管理部９は、どの計算ノードに対してどのような障害対応方法を実行済み或いは実行中であるかなどを示す障害対応ログを、記憶部１０の障害対応ログ記憶領域に保存する（Ｓ１２３）。この保存された障害対応ログは、再び障害が発生した場合に、過去にどのような障害対応方法が実施され、あるいは実行中であるかを考慮して次の障害対応方法を決定するために利用される。他方、発行されたコマンドを受信した計算ノード１では、そのコマンドを実行することより、障害対応方法を実施する（Ｓ１２４）。
【００９１】
以上のような障害対応処理を行うことにより、例えば、或る計算ノード１のｐｉｎｇ応答がないという障害が検知され、その障害コードが０１０１であり、障害コード０１０１に対応して「再起動コマンド」が障害対応テーブルに設定されている場合、その計算ノード１に対して再起動コマンドが発行され、その計算ノード１の再起動により障害の回復が試行される。ここで、同じ計算機プログラム実行環境の下で計算ノード１を再起動して計算機プログラム４を再スタートすると、再び同じ障害が発生する確率が高いため、障害の発生した計算ノード１の計算機プログラム実行環境を記憶部１０に記憶されている別のプログラム実行環境設定データを用いて変更し、その後に計算ノード１を再起動するようにしても良い。計算ノード１のプログラム実行環境の変更はステップＳ１０２で説明した処理と同様の処理で可能である。また、計算機プログラム４のプログラムの実行状態（プロセスや入出力の優先度など）を変更して、再起動するようにしても良い。
【００９２】
また、障害対応方法がチェックポインティング手法による回復の場合、記憶部１０からチェックポインティングデータが読み出されて通信経路３経由で計算ノード１に送られ、障害によって計算機プログラム４の実行を一時停止している計算ノード１では、プログラム実行管理部５によって、受信したチェックポインティングデータを用いてデータを復元し、計算機プログラム４を再起動することによって障害の回復が試行される。ここで、計算機プログラム４の一時停止と再起動は、その計算ノード１に設定されたプログラム実行環境設定データのプログラム起動環境に従う。つまり、計算機プログラム４のサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラム４のサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラム４のＯＳによる停止と再起動、計算機プログラム４とＯＳのシャットダウン処理と再起動、計算機プログラム４とＯＳの強制終了と再起動、計算機プログラム４とＯＳの再インストール後の再起動、計算機プログラム４とＯＳのクリアインストール後の再起動のうち、その計算ノード１のプログラム起動環境で指定された方法で行われる。
【００９３】
また、複数の計算ノード１で障害が発生した場合のチェックポインティング手法による回復処理では、障害管理部９は、これら複数の計算ノード１において、異なるチェックポインティングデータから計算機プログラム４を並列に再実行させることにより、どのチェックポインティングデータから計算機プログラム４を再起動すれば障害が回復するかを短時間で解明し、チェックポインティング手法による障害からの回復時間を短縮する。どの計算ノード１にどのチェックポインティングデータを用いたかは障害対応ログで管理される。
【００９４】
以上、障害対応方法について具体例を幾つか説明したが、勿論、ここに述べたような方法以外にも、障害の発生した計算ノードを停止させる、計算機プログラムの移動やコピーを行って、障害の発生した計算ノードで行われていた処理を他の計算ノードに代替させる、システム運用者へ障害の発生を知らせる電子メールを送信する等、任意の障害対応処理が可能である。また、障害の発生した計算ノードを停止させると以後その計算ノードに関する障害検出は不要になる等、実行した障害対応方法によって障害検知動作の変更が必要な場合、障害管理部９は障害管理動作を変更する。
【００９５】
（４）処理要求に関連する処理（図３のＳ１０５、Ｓ１１１、Ｓ１１３）
管理ノード２のジョブ管理部８は、耐障害計算機システムで処理すべき処理要求が発生すると、その処理要求を複数の計算ノード１上の計算機プログラム４に処理させるための処理要求処理Ｓ１１１を実行し、また複数の計算ノード１の計算機プログラム４で処理要求に対する処理が終了すると、システムとしての処理結果を導出するための処理結果処理Ｓ１１３を実行する。処理要求処理Ｓ１１１の一例を図５に、処理結果処理Ｓ１１３の一例を図６に、この処理要求処理および処理要求処理を行うジョブ管理部８の構成例を図７に、それぞれ示す。
【００９６】
図７を参照すると、ジョブ管理部８は、要求メッセージ分配条件記憶部３２、要求処理判断部３３、要求メッセージ受信部３４、要求メッセージ転送先記憶部３５、要求転送メッセージ生成部３６、要求転送メッセージ送信部３７、応答メッセージ生成条件記憶部３８、応答処理判断部３９、応答メッセージ受信部４０、応答メッセージ転送先記憶部４１、応答転送メッセージ生成部４２、応答転送メッセージ送信部４３および応答メッセージ保持部４４を含んで構成され、サービスを要求するクライアントなどといった要求メッセージ送信元２０に接続されると共に、システム内部では障害管理部９および複数の計算ノード１に接続される。なお、図７に示される応答メッセージ送信先２１は、要求メッセージ送信元あるいは計算ノードに相当する。
【００９７】
要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５には、障害管理部９によってシステムの状態に応じて更新される分配先情報が記憶される。つまり、要求メッセージ分配条件記憶部３２には、要求メッセージ送信元２０から受信した要求メッセージを分配する計算ノードを指定する情報が設定され、要求メッセージ転送先記憶部３５にはそれらの各計算ノードの宛先情報が設定されており、それぞれ障害管理部９の情報更新部３１によって障害対応処理の一環として更新される。例えば、或る計算ノード１の障害によりその障害ノード１を停止等してシステムから論理的に切り離した場合、障害管理部９の情報更新部３１によって、当該計算ノード１に関する情報が要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５から削除され、また代替可能な計算ノード１が他に存在すれば、障害管理部９によって、当該代替可能な計算ノード１に関する情報が要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５に追加される。
【００９８】
また、応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１には、応答生成条件および障害管理部９によってシステムの状態に応じて更新される分配先情報を含む判断基準情報が記憶される。つまり、応答メッセージ生成条件記憶部３８には、計算ノード１から受信した応答メッセージから応答メッセージ送信先２１に転送する応答転送メッセージを生成する条件および転送先情報が設定され、応答メッセージ転送先記憶部４１には各応答転送メッセージ送信先の宛先情報が設定されており、障害管理部９の情報更新部３１によって障害対応処理の一環として更新される。例えば、或る計算ノード１の障害によりその障害ノード１を停止等してシステムから論理的に切り離した場合、障害管理部９の情報更新部３１によって、当該計算ノード１に関する情報が応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１から削除され、また代替可能な計算ノード１が他に存在すれば、障害管理部９によって、当該代替可能な計算ノード１に関する情報が応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１に追加される。なお、要求メッセージ送信元２０の宛先情報は、処理判断部３３によって応答メッセージ転送先記憶部４１に登録され、要求メッセージ送信元２０に通知されるシステムとしての処理結果の返却時に、応答転送メッセージ生成部４２により参照される。
【００９９】
要求メッセージ送信元２０から本実施の形態の耐障害計算機システムに要求メッセージが送信されてくると、要求メッセージ受信部３４で受信する（Ｓ１３１）。要求処理判断部３３では、要求メッセージ分配条件記憶部３２を参照して、受信した要求メッセージの転送の可否および転送する場合には転送先の計算ノード１を判断する（Ｓ１３２）。転送先が無いなどの理由で転送しないと判断した場合は、要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元２０に返す。転送すると判断した場合、要求処理判断部３３は、転送先の計算ノードを指定して要求メッセージを要求転送メッセージ生成部３６に伝達する。
【０１００】
要求転送メッセージ生成部３６は、要求メッセージ転送先記憶部３５を参照して、要求メッセージの宛先を転送する計算ノード１に書き換えることで、実際に転送する要求メッセージを生成する（Ｓ１３３）。ここで、転送先の計算ノード１が複数あるのであれば、要求転送メッセージ生成部３６は、要求メッセージを複製し、それぞれの宛先を転送先の計算ノード１に書き換えることで、複数の転送する要求メッセージを生成する。
【０１０１】
要求転送メッセージ送信部３７は、要求転送メッセージ生成部３６で生成された要求メッセージを、通信経路３を通じて、該当する計算ノード１に送信する（Ｓ１３４）。要求メッセージの転送を受けた計算ノード１のプログラム実行管理部７は、その要求メッセージを計算機プログラム４に処理させる。
【０１０２】
各計算ノード１の計算機プログラム４は、要求された処理を行い、応答メッセージを送信する。要求メッセージ送信元２０からの要求メッセージを計算機プログラム４で一度処理するだけで、その計算機プログラム４から最終的な処理結果の応答メッセージが出される場合だけでなく、最終的な処理結果を得る過程で別の計算ノードや外部のシステムにデータベースアクセスなどの処理要求を行う応答メッセージ（別サービス要求メッセージ）が返される場合がある。応答メッセージ受信部４０は、このような計算機プログラム４からの応答メッセージを受信し、応答メッセージ保持部４４に蓄積する（Ｓ１４１）。
【０１０３】
応答処理判断部３９は、応答転送メッセージ生成に必要な処理結果が応答メッセージ保持部４４に蓄積されたかどうかを判断し（Ｓ１４２）、未だ蓄積されていないときは今回の処理結果処理Ｓ１１３を終了する。必要な処理結果が蓄積されていれば、応答処理判断部３９は、応答メッセージ生成条件記憶部３８を参照して、応答転送メッセージの生成可否および転送先の判断を行い、応答転送メッセージを生成する（Ｓ１４３）。例えば、蓄積されている応答メッセージが別サービス要求メッセージであって、別サービス要求メッセージを分配する計算ノードが１つも無いなどの理由で転送しないと判断した場合、おおもとの要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元２０に送信する。また、蓄積されている応答メッセージが別サービス要求メッセージであって分配先が存在するために転送すると判断した場合および蓄積されている応答メッセージが別サービス要求メッセージでなく最終的な応答メッセージの場合、応答メッセージが一つであれば、そのメッセージをそのまま転送するメッセージとする。複数の計算ノード１の計算機プログラム４から複数の応答メッセージがある場合、応答処理判断部３９は、応答メッセージ生成条件記憶部３８を参照して、以下のような応答メッセージの選択あるいは生成を行い、転送先を指定して応答転送メッセージ生成部４２に伝達する。転送先は、最終的な応答であれば要求であれば、要求メッセージ元であり、別サービス要求メッセージであれば、計算ノード１等である。
【０１０４】
（ａ）任意の一つの実行ノード１の計算機プログラム４からの応答メッセージを選択し、これを応答転送メッセージとする。このとき、最も早く到着した応答メッセージを選択するようにしても良い。
（ｂ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージから多数決論理により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｃ）予め定められたＮ個の応答メッセージが到着次第、多数決により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｄ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージの平均値を取るなどの統計処理を行い、統計処理で得られた値をもつ応答転送メッセージを生成する。
【０１０５】
応答メッセージの選択あるいは生成の方法は、これらに限定されるものではなく、その他任意の方法を使用することができる。
【０１０６】
応答転送メッセージ生成部４２は、応答メッセージ転送先記憶部４１を参照して、応答転送メッセージの宛先を応答メッセージ送信先２１に書き換えることで、実際に転送する応答転送メッセージを生成する（Ｓ１４４）。応答転送メッセージ送信部４３は、生成された応答転送メッセージを応答メッセージ送信先２１に送信する（Ｓ１４５）。応答メッセージ送信先２１が、計算ノード１である場合、計算ノード１の計算機プログラム４は要求された処理を行い、その処理結果を応答メッセージで送信する。また、応答メッセージ送信先２１が、要求メッセージ送信元２０である場合、システムとしての処理結果が要求メッセージ送信元２０に返却されたことになる。
【０１０７】
【発明の第２の実施の形態】
図８を参照すると、本発明の第２の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１および管理ノード２で共有する構成とした点で第１の実施の形態と相違する。
【０１０８】
本実施の形態では、各計算ノード１毎の計算機プログラム実行環境設定データを定義した記憶部１０を全てのノードで共有しているため、各計算ノード１の計算機プログラム実行環境を設定したり、既に設定されている環境を別の環境に再設定する際、管理ノード２から通信経路３経由でプログラム実行環境設定データを各計算ノード１に送信する必要がなく、記憶部１０に記憶されているどの計算機プログラム実行環境を使用するかを管理ノード１０から計算ノード１に対して通信経路３経由あるいは記憶部１０上に設けた通信領域経由で通知し、計算ノード１が記憶部１０からプログラム実行環境設定データを読み出して、自ノードの実行環境の設定が行える。また、障害を検出した計算ノード１のプログラム実行状態（プロセスや入出力の優先度など）を変更する際にも、管理ノード２が記憶部１０上に記憶されている当該計算ノード１のプログラム実行状態を更新し、計算ノード１がその更新されたプログラム実行状態を記憶部１０から読み出して自計算ノード１のプログラム実行状態を更新するといった動作が行える。
【０１０９】
また、各計算ノード１のチェックポインティングデータを記憶する記憶部１０を各計算ノード１で共有することで、各計算ノード１がチェックポインティングデータを記憶部１０に保存したり、記憶部１０からチェックポインティングデータを読み出して再スタートする際に管理ノード２とチェックポインティングデータを授受する必要がなくなり、チェックポインティングのデータ転送が容易となる。そのため、計算機プログラムの移動やコピーも容易となる。また、他の計算ノード１の実行状態に応じて、自動的に自ノードの計算機プログラム４の動作状態を変更することも可能である。
【０１１０】
【発明の第３の実施の形態】
図９を参照すると、本発明の第３の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１および管理ノード２に個別に備え、各ノードが通信して、各記憶部１０の同一性を保つミラーリングを行うようにした点で第１の実施の形態と相違する。ミラーリングにおいては、データの更新の都度、通信を行って、分散したデータの同一性を保つ手法を用いても良いし、データ参照がある時点で、新たにデータ更新がされていないかどうかをチェックし、更新されている部分だけ通信を行って、分散したデータの同一性を保つ手法を用いても良い。
【０１１１】
本実施の形態では、各計算ノード１毎の計算機プログラム実行環境設定データを定義した記憶部１０を各ノード毎に備えているため、各計算ノード１の計算機プログラム実行環境を設定したり、既に設定されている環境を別の環境に再設定する際、管理ノード２から通信経路３経由でプログラム実行環境設定データを各計算ノード１に送信する必要がなく、記憶部１０に記憶されているどの計算機プログラム実行環境を使用するかを管理ノード１０から計算ノード１に対して通信経路３経由あるいは記憶部１０上に設けた通信領域経由で通知し、計算ノード１が記憶部１０からプログラム実行環境設定データを読み出して、自ノードの実行環境の設定が行える。また、障害を検出した計算ノード１のプログラム実行状態（プロセスや入出力の優先度など）を変更する際にも、管理ノード２が記憶部１０上に記憶されている当該計算ノード１のプログラム実行状態を更新し、計算ノード１がその更新されたプログラム実行状態を記憶部１０から読み出して自計算ノード１のプログラム実行状態を更新するといった動作が行える。
【０１１２】
また、各計算ノード１のチェックポインティングデータを記憶する記憶部１０を各計算ノード１で共有することで、各計算ノード１がチェックポインティングデータを記憶部１０に保存したり、記憶部１０からチェックポインティングデータを読み出して再スタートする際に管理ノード２とチェックポインティングデータを授受する必要がなくなり、チェックポインティングのデータ転送が容易となる。そのため、計算機プログラムの移動やコピーも容易となる。また、他の計算ノード１の実行状態に応じて、自動的に自ノードの計算機プログラム４の動作状態を変更することも可能である。
【０１１３】
さらに、同じデータが複数の記憶部１０に分散して記憶されているため、耐障害性を高めることができる。但し、ミラーリングのための通信負荷が高く、システムのパフォーマンスが悪くなる可能性はある。
【０１１４】
【発明の第４の実施の形態】
図１０を参照すると、本発明の第４の実施の形態にかかる耐障害計算機システムは、複数の計算ノード１のそれぞれに障害検知部５１を備え、管理ノード２の障害管理部９は、各計算ノード１の障害検知部５１から通知される障害情報を受信してシステム全体の障害管理を行う点で図１に示した第１の実施の形態にかかる耐障害計算機システムと相違する。
【０１１５】
各計算ノード１の障害検知部５１は、障害を検知すると、通信経路３経由で障害情報を管理ノード２の障害管理部９に通知する。このような構成を用いることによって、前述したｐｉｎｇ−ｐｏｎｇ方式による障害の有無のチェックに比べ、より効率的な、またより詳細な障害情報を取得することが可能となる。なぜならば、ｐｉｎｇ−ｐｏｎｇという双方向の通信に対して、障害検知部５１が継続的に一方向の信号を発行するだけで、ハートビート信号として機能するからである。障害管理部９は、ハートビート信号が途絶えたことによって、障害を検知する。また、障害検知部５１は通信経路３を用いずに各計算ノード１に含まれる各モジュールの動作情報を取得するので、たとえ通信障害が発生したとしても、その影響を受けることが少ない。障害検知部５１の一例として、サービスプロセッサがよく知られている。サービスプロセッサは、計算ノード１において演算処理を行うプロセッサ５とは別のプロセッサであり、プロセッサ５、メモリ６、それらの間のバスなどの動作状態をチェックし、動作情報を収集する機能をもつ。さらに動作情報を解析し、障害通報装置に通信する機能を持つサービスプロセッサもある。
【０１１６】
【発明の第５の実施の形態】
図１１を参照すると、本発明の第５の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１に個別に備え、各ノードが通信して、各記憶部１０の同一性を保つミラーリングを行うようにした点と、管理ノード２を省略し、管理ノード２のジョブ管理部８で集中管理していたジョブ管理を分散管理するためのジョブ管理部８’と、管理ノード２の障害管理部９で集中管理していた障害管理を分散管理するための障害管理部９’を各計算ノード１に備えるようにした点で、第１の実施の形態と相違する。ミラーリングにおいては、データの更新の都度、通信を行って、分散したデータの同一性を保つ手法を用いても良いし、データ参照がある時点で、新たにデータ更新がされていないかどうかをチェックし、更新されている部分だけ通信を行って、分散したデータの同一性を保つ手法を用いても良い。
【０１１７】
第１の実施の形態では、各計算ノード１において、プログラム実行管理は、管理ノード２と通信を行い、ジョブの割り振り、およびそのジョブを処理するプログラムの実行環境の情報を取得していたが、本実施の形態では、各計算ノード１にプログラム実行環境設定データを保持する記憶部１０があり、予め別途プログラム実行環境の設定データを保持しておくことによって、分散的なジョブ管理が可能となっている。また、各計算ノード１のプログラム実行管理部７は相互に通信して、他の計算ノード１の状態の情報を交換し、必要であれば記憶部１０のデータを更新し、自ノードの実行環境を変更したり、ジョブを他の計算ノード１に転送するなどの動作を行う。
【０１１８】
さらに、システム全体の障害状態の監視と管理は、各計算ノード１に設けられた障害管理部９’が互い通信し合って分散的に行う。このとき、検知された障害情報は、プログラム実行管理部７を経由してその他の障害管理部９’に送られ、障害情報および障害対応情報を各計算ノード１で共有する。これは、同一の障害要因に対して、複数の障害管理部９’から同時に障害対応命令が発行されて、その命令がコンフリクトし、別の不具合や障害の原因となるのを防止するためである。
【０１１９】
このように本実施の形態では、単一の管理ノードを持たないため、一つの管理ノードにおいて障害が発生しても、その他の管理ノードは継続して動作し、システム全体として障害状態の監視と管理を継続するので、より高い耐障害性を確保できる。
【０１２０】
図１１では、全ての計算ノード１に障害管理部９’を設けたが、全てではなく任意の複数の計算ノード１に障害管理部９’を設ける構成も考えられる。また、特定の１つの計算ノード１に第１の実施の形態における管理ノード２の障害管理部９と同様に障害を集中管理する障害管理部を設けるようにしても良い。
【０１２１】
【発明の効果】
以上説明したように、本発明においては、以下のような効果を奏する。
【０１２２】
同一の計算機プログラムを使用して、ソフトウェアレベルでの耐障害性を高めることができる。その理由は、ソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するが、本発明では、複数の計算ノードの計算機プログラム実行環境がそれぞれ異なっており、計算機プログラムに存在する特定のバグが活性化する特定の状態が全ての計算ノードで同時に起きる確率が低下するからである。
【０１２３】
計算ノードが障害状態に陥った場合に、再び同じような障害が発生するのを防止することができる。その理由は、障害にかかる計算ノードの計算機プログラム実行環境を変更して計算機プログラムを再実行するため、計算機プログラムに存在する特定のバグが活性化する特定の状態が再実行後に再び発生する確率が、計算機プログラム実行環境を変えない場合に比べて低下するからである。
【０１２４】
チェックポインティング手法による障害からの回復時間を短縮することができる。その理由は、複数の計算ノードで障害が発生し、チェックポインティング手法で障害からの回復を試みる際、複数の計算ノードにおいて異なるチェックポインティングデータから計算機プログラムを並列に再実行させるため、どのチェックポインティングデータから計算機プログラムを再起動すれば障害が回復するかが短時間で解明するからである。
【０１２５】
前述のように自動的に障害状態からの回復処理を試行するため、計算機システムの運用管理者の障害回避、回復作業の手間が省け、また人為的ミスをさけることができるという意味で障害回避、回復作業の確実性を向上させることができる。
【０１２６】
複数の計算ノード毎に障害管理手段を備え、複数の障害管理手段によってシステム全体の障害の管理を分散的に行う構成にあっては、一部の計算ノードに障害があっても、その他の計算ノードで障害管理機能を提供することができるため、耐障害計算機システムの障害管理機能の耐障害性を向上させることができる。
【０１２７】
処理要求分配手段として、障害管理手段によってシステムの状態に応じて更新される分配先情報を記憶する記憶部、要求メッセージ受信部、処理判断部、要求転送メッセージ生成部および要求転送メッセージ送信部を備える構成にあっては、サービスを要求するクライアント等の処理要求元から入力される処理要求をシステムの状態に応じた複数の計算ノードの計算機プログラムで並列に処理することができる。
【０１２８】
処理結果導出手段として、応答生成条件および障害管理手段によってシステムの状態に応じて更新される分配先情報を含む判断基準情報を記憶する記憶部、応答メッセージ受信部、応答メッセージ保持部、応答処理判断部、応答転送メッセージ生成部および応答転送メッセージ送信部を備える構成にあっては、処理過程で発生する別サービス要求メッセージの処理についてもプログラムレベルでの耐障害性を高めるためにシステムの状態に応じた複数の計算ノードの計算機プログラムで並列に処理することができ、また、複数の計算機プログラムの処理結果から多数決などで導出したシステムとしての処理結果を応答メッセージとして処理サービス要求元に返却することにより、計算機プログラムの不具合による計算ミス障害に対する耐障害性を高めることができる。他方、サービス要求に対する処理結果もしくは処理過程で出力される別サービス要求に対する処理結果のうち、応答が早いものを用いて処理を進めることにより、処理遅延障害に対する耐障害性を高めることができる。
【０１２９】
計算ノードに仮想マシンを使用する構成にあっては、耐障害機能を持つ計算機システムを低コストで提供することができる。その理由は、仮想マシンはソフトウェア的にその計算機プログラム実行環境を設定できために実マシンを使う場合のように種々のハードウェアを用意しておく必要がなく、また、仮想マシンは必要時に生成し、不要となれば消去できるためハードウェア資源の効率的な使用が可能になるからである。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態にかかる耐障害計算機システムのブロック図である。
【図２】計算ノードや管理ノードに使用する仮想マシンの説明図である。
【図３】本発明の第１の実施の形態にかかる耐障害計算機システムの処理の流れを示すフローチャートである。
【図４】障害対応処理の一例を示すフローチャートである。
【図５】処理要求処理の一例を示すフローチャートである。
【図６】処理結果処理の一例を示すフローチャートである。
【図７】ジョブ管理部の構成例を示すブロック図である。
【図８】本発明の第２の実施の形態にかかる耐障害計算機システムのブロック図である。
【図９】本発明の第３の実施の形態にかかる耐障害計算機システムのブロック図である。
【図１０】本発明の第４の実施の形態にかかる耐障害計算機システムのブロック図である。
【図１１】本発明の第５の実施の形態にかかる耐障害計算機システムのブロック図である。
【符号の説明】
１…計算ノード
２…管理ノード
３…通信経路
４…計算機プログラム
５…プロセッサ
６…メモリ
７…プログラム実行管理部
８、８’…ジョブ管理部
９、９’…障害管理部
１０…記憶部
１１…仮想マシン
１２…計算機
１３…制御ソフトウェア
１４…仮想マシン実行環境
２０…要求メッセージ送信元
２１…応答メッセージ送信先
３１…情報更新部
３２…要求メッセージ分配条件記憶部
３３…処理判断部
３４…要求メッセージ受信部
３５…要求メッセージ転送先記憶部
３６…要求転送メッセージ生成部
３７…要求転送メッセージ送信部
３８…応答メッセージ生成条件生成部
３９…応答処理判断部
４０…応答メッセージ受信部
４１…応答メッセージ転送先記憶部
４２…応答転送メッセージ生成部
４３…応答転送メッセージ送信部
４４…応答メッセージ保持部
５１…障害検知部
【発明の属する技術分野】
本発明は計算ノードを複数備えた計算機システムに関し、特にプログラムレベルでの耐障害性能を高めた計算機システムに関する。
【０００２】
【従来の技術】
耐障害計算機システムは、構成要素の故障は避けられないという観点から、計算ノードの冗長化によって信頼性を高めた計算機システムである。例えば、後述する非特許文献１には、プロセッサとメモリからなる多数の計算ノードをバスに接続し、全ての処理を適当な大きさのタスクに分割して、各タスクを複数の計算ノードで同時に実行し、各タスクの実行結果から多数決によりシステムの出力を導出することにより、単一の計算ノードに障害が発生してもシステム外部からは正常時と全く同じ振る舞いをする耐障害計算機システムが示されている。この耐障害計算機システムは、主にハードウェアレベルでの耐障害性の向上を狙ったものであり、計算ノードは全て同じ構成を有し、タスクは同一の計算機プログラムにより各計算ノードで並列実行することを前提としている。このため、計算機プログラムにバグがあると、ソフトウェアフォールトによって全てのタスクが異常終了する確率が高く、ソフトウェアレベルでの耐障害性の向上は難しい。
【０００３】
そこで、ソフトウェアレベルでの耐障害性の向上を目的とした従来技術として、後述する非特許文献２には、複数の異なる開発者によってそれぞれ異なる手法で作成された同一の機能を達成する複数の計算機プログラムを計算機システムで並列に実行し、複数の計算機プログラムの出力結果から多数決によりシステムの出力を導出する技術が示されている。
【０００４】
他方、耐障害計算機システムに限らず通常の計算機システムにおいても、障害が発生した場合には速やかに障害の回復が試行される。従来の計算機システムにおける障害に対する回復方法の一例が、後述する特許文献１に記載されている。この従来システムでは、いわゆるチェックポインティングと呼ばれる手法で、ある時点での計算機プログラムの実行状態を保存しておき、さらに計算機プログラムの実行過程を詳細に記録しておくことで、障害が発生した場合に、障害発生前に保存したチェックポインティングのデータから、計算機プログラムの実行状態を復元し、さらにプログラムの実行過程を再現することで、計算機システムを障害から回復させることを試みる手法が述べられている。
【０００５】
チェックポインティングと類似した手法として、バックアップが一般的に知られている。バックアップは、計算機のハードディスク上のデータをテープなどの別の媒体に保存することであるが、チェックポインティングは、計算機プログラムにおける内部変数や実行位置を含めた状態の動的なデータも保存する点で異なる。そのため、確実なチェックポインティングを行うためには、内部変数が変更中での保存を避けたり、実行位置が明確に分かる保存をする必要がある。通常のチェックポインティング機能は、計算機プログラム本体に組み込まれるが、特許文献１記載の発明のように、チェックポインティングをデータの入出力のタイミングと同期させることで、チェックポインティング機能をプログラムに組み込むことを不要にする手法もある。
【０００６】
一方、障害の原因が発生してから、障害が顕在化し、検知されるまで、ある程度の時間が経過するために、どの時点で保存したチェックポインティングのデータを復元すればよいかが分からないという問題がある。従来は、計算機プログラムが出力するログや、障害が検知された時点でのプログラムの実行状態のダンプデータなどから、システム運用者が手間と時間をかけて、原因を解明し、その後適切なチェックポインティングデータを選択し、システムの回復作業を行っていた。後述する特許文献２のように、チェックポインティングのデータを管理しておき、障害時にそのチェックポインティングのデータを自動的に１つずつ試していくことで、適切なチェックポインティングデータを探索し、システムの回復作業の手間を省く手法も知られている。
【０００７】
チェックポインティングしたデータを復元し、プログラムを再スタートする際の「再スタート」にもさまざまな手法が知られている。現在のパーソナルコンピュータ製品においては、ＡＣＰＩ（Ａｄｖａｎｃｅｄ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ａｎｄ Ｐｏｗｅｒ Ｉｎｔｅｒｆａｃｅ）と呼ばれる計算機の実行状態を制御する規格が、広く採用されている。ＡＣＰＩにおいては、計算機の一時停止状態がいくつか定義されており、一時停止状態からの再スタート方式について述べられている。その中でも、次のような計算機の一時停止と再スタートが広く利用されている。一つは、計算機の主記憶の状態をそのままにして、ＣＰＵを停止する方法で、いわゆるＳＴＲ（Ｓｕｓｐｅｎｄ Ｔｏ ＲＡＭ）と呼ばれる方法である。もう一つは、計算機の主記憶・仮想記憶の状態をハードディスクに保存し、ＯＳを停止し、ＯＳの再起動時に保存した主記憶・仮想記憶の状態を復元する方法で、いわゆるＳＴＤ（Ｓｕｓｐｅｎｄ Ｔｏ Ｄｉｓｋ）と呼ばれる手法である。また一般的に、次のような計算機プログラムの再スタートを行うことも多い。一つは、ＯＳ上で、計算機プログラムのプロセスを停止後、プロセスを再起動する方法である。再実行とも言う。もう一つは、ＯＳを停止させて、ＯＳを再起動後、当該プロセスを起動する方法である。さらに、ＯＳの停止に関して、強制的な電源断によるような方法（リセット）と、ＯＳに対してシャットダウン処理を行って、停止する方法がある。これらの多様な計算機プログラムの再スタート、つまり実行環境の変更は、計算機プログラムや障害の種類、回復までの時間や手間の容易性、データ復元の安全性などを考慮して、システム運用者が判断して行っている。
【０００８】
【非特許文献１】
社団法人情報処理学会編，「新版 情報処理ハンドブック」，第１版，株式会社オーム社，平成７年１１月２５日、ｐ４５９−４６１
【非特許文献２】
「Ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ ｂｙ ｄｅｓｉｇｎ ｄｉｖｅｒｓｉｔｙ： Ｃｏｎｃｅｐｔｓ ａｎｄ ｅｘｐｅｒｉｍｅｎｔｓ」（Ａｖｉｚｉｅｎｉｓ， Ａ．， Ｋｅｌｌｙ， Ｊ．Ｐ．Ｊ．， ＩＥＥＥ Ｃｏｍｐｕｔｅｒ ｖｏｌ．１７， ｎｏ．８， ｐｐ：６７−８０， １９８４．）
【特許文献１】
特表２００２−５０５７６８号公報
【特許文献２】
特許第３２９００５２号公報
【０００９】
【発明が解決しようとする課題】
ソフトウェアレベルでの耐障害性を高めるために、非特許文献２に記載されるように同一の機能を達成する複数の計算機プログラムを用いる方法は、プログラムの開発に多大な労力と費用を必要とする。従って、開発コストを低減するために、同一の計算機プログラムを使用してソフトウェアレベルで耐障害性を高めることのできる技術が望まれている。
【００１０】
また、何れかの計算ノードが障害になった場合、その障害を復旧するための回復処理を行うことは当然であるが、その際、再び同じような障害を招かないような有益な方法が望まれる。
【００１１】
更に、耐障害計算機システムに特許文献１または２に記載のチェックポインティングによる障害からの回復手法を単に適用しただけでは、どのチェックポインティングデータから計算機プログラムを再スタートすれば良いのかを解明するまでに時間がかかるため、より短時間に解明できる有益な方法が望まれる。
【００１２】
本発明の目的は、同一の計算機プログラムを使用してソフトウェアレベルで耐障害性を高めることのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１３】
本発明の別の目的は、計算ノードが障害状態に陥った場合に、再び同じような障害ができるだけ発生しないようにすることのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１４】
本発明の更に別の目的は、チェックポインティング手法による障害からの回復時間を短縮することのできる耐障害計算機システムおよびプログラム並列実行方法を提供することにある。
【００１５】
【課題を解決するための手段】
本発明の耐障害計算機システムは、それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行することを基本とする。具体的には、本発明の第１の耐障害計算機システムは、それぞれ異なる計算機プログラム実行環境の下で同一の計算機プログラムを並列に実行する複数の計算ノードと、前記複数の計算ノード毎のプログラム実行状態および計算機プログラム実行環境設定データを記憶する記憶手段と、前記記憶手段に記憶された計算機プログラム実行環境設定データに基づいて各計算ノード毎にその計算ノードの計算機プログラム実行環境の設定を行う実行環境設定手段と、前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を分配する処理要求分配手段と、前記各計算ノードの障害の有無を監視し障害発生時には障害対応処理を実施する障害管理手段と、前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出する処理結果導出手段とを備えている。
【００１６】
ここで、それぞれ異なる計算機プログラム実行環境とは、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類の環境の少なくとも１つの環境が異なることによって、計算機プログラム実行環境間の相違度が所定の相違度以上異なることである。
【００１７】
また、ハードウェア環境が異なるとは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類のうちの少なくとも１つが異なることである。
【００１８】
また、ソフトウェア環境が異なるとは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのうち少なくとも１つの種類やバージョンが異なることである。
【００１９】
また、外部接続機器環境が異なるとは、外部記憶装置、表示装置、入力装置、通信装置のうち少なくとも１つの種類や仕様が異なることである。
【００２０】
また、プログラム起動環境が異なるとは、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムとＯＳの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動のうちの異なる再起動方法を用いることである。
【００２１】
本発明の第２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害にかかる前記計算ノードの計算機プログラム実行環境を変更して前記計算機プログラムを再実行させる。
【００２２】
本発明の第３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害にかかる前記計算ノードにおける計算機プログラムの実行状態を変更して前記計算機プログラムを再実行させる。
【００２３】
本発明の第４の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせる。
【００２４】
本発明の第５の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記処理要求分配手段は、前記障害管理手段によってシステムの状態に応じて更新される分配先情報を記憶する分配先情報記憶部と、処理要求である処理サービスの要求メッセージを受信する要求メッセージ受信部と、前記要求メッセージをシステム内のどの計算ノードで処理するかを前記分配先情報に基づいて判断する処理判断部と、分配先の計算ノードに前記要求メッセージを転送するための転送メッセージを生成する要求転送メッセージ生成部と、生成された要求転送メッセージを転送先の計算ノードに転送する要求転送メッセージ送信部とを備える。
【００２５】
本発明の第６の耐障害計算機システムは、第５の耐障害計算機システムにおいて、前記処理結果導出手段は、応答生成条件および前記障害管理手段によってシステムの状態に応じて更新される分配先情報を含む判断基準情報を記憶する判断基準情報記憶部と、前記処理サービスの応答メッセージおよびデータベースアクセスなどの処理途中の別サービス要求メッセージを前記計算ノードから受信する応答メッセージ受信部と、前記受信した応答メッセージおよび別サービス要求メッセージを一時的に記憶する応答メッセージ保持部と、前記応答メッセージ保持部に保持された応答メッセージおよび別サービス要求メッセージをどのように処理するかを前記判断基準情報に基づいて判断する応答処理判断部と、応答メッセージおよび別サービス要求メッセージをサービス要求元および別サービス要求先に転送するための応答転送メッセージを生成する応答転送メッセージ生成部と、生成された応答転送メッセージをサービス要求元または別サービス要求先に転送する応答転送メッセージ送信部とを備える。
【００２６】
本発明の第７の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２７】
本発明の第８の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２８】
本発明の第９の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００２９】
本発明の第１０の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものである。
【００３０】
本発明の第１１の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３１】
本発明の第１２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３２】
本発明の第１３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものである。
【００３３】
本発明の第１４の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記処理要求分配手段を備え、前記複数の計算ノードに備わる複数の処理要求分配手段によって処理要求の分配処理を分散して行うものである。
【００３４】
本発明の第１５の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記障害管理手段および前記記憶手段を備える。
【００３５】
本発明の第１６の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記障害管理手段は、障害を検知し障害情報を送信する第１の手段と前記障害検知手段から障害情報を受信しシステム全体として障害を管理する第２の手段とで構成され、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記第２の手段と前記記憶手段を備え、前記複数の計算ノードのそれぞれに前記第１の手段を備える。
【００３６】
本発明の第１７の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記管理ノードに前記障害管理手段を備える。
【００３７】
本発明の第１８の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記管理ノードに前記障害管理手段を備える。
【００３８】
本発明の第１９の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノード毎に前記障害管理手段を備え、前記複数の計算ノードに備わる複数の前記障害管理手段によってシステム全体の障害の管理を分散的に行うものである。
【００３９】
本発明の第２０の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４０】
本発明の第２１の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４１】
本発明の第２２の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものである。
【００４２】
本発明の第２３の耐障害計算機システムは、第１の耐障害計算機システムにおいて、前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部とジョブ管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出する処理を、前記複数の計算ノードに備わる複数の前記処理結果導出手段によって分散的に行うものである。
【００４３】
本発明の第２４の耐障害計算機システムは、第１乃至第２３の耐障害計算機システムにおいて、前記計算ノードに実マシンを用いる。
【００４４】
本発明の第２５の耐障害計算機システムは、第１乃至第２３の耐障害計算機システムにおいて、前記計算ノードに仮想マシンを用いる。
【００４５】
他方、本発明のプログラム並列実行方法は、それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行することを基本とする。具体的には、本発明の第１のプログラム並列実行方法は、複数の計算ノードを備える計算機システムにおけるプログラム並列実行方法において、（ａ）複数の計算ノードのそれぞれに、異なる計算機プログラム実行環境を設定するステップ、（ｂ）前記複数の計算ノードで、同一の計算機プログラムを並列実行するステップ、（ｃ）前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を処理させるステップ、（ｄ）前記複数の計算ノードの動作状態を監視し障害を検知したときに障害対応処理を行うステップ、（ｅ）前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップを有する。
【００４６】
また、本発明の第２のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラム実行環境を変更し、前記計算機プログラムを再実行する。
【００４７】
また、本発明の第３のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラムの実行状態を変更し、前記計算機プログラムを再実行する。
【００４８】
また、本発明の第４のプログラム並列実行方法は、第１のプログラム並列実行方法において、前記ステップｄにおける障害対応処理として、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせる。
【００４９】
【作用】
一般にソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するため、複数の計算ノードの計算機プログラム実行環境をそれぞれ異ならせて計算機プログラムを並列実行させる本発明にあっては、計算機プログラムに存在する特定のバグが活性化する特定の状態が全ての計算ノードで同時に起き難くなり、同一の計算機プログラムを使用して、ソフトウェアレベルでの耐障害性を高めることができる。
【００５０】
また、障害にかかる計算ノードの計算機プログラム実行環境を変更して計算機プログラムを再実行することにより、計算機プログラムに存在する特定のバグが活性化する特定の状態の再発生を防止し、再び同じような障害が発生するのを防止することができる。
【００５１】
また、複数の計算ノードで障害が発生し、チェックポインティング手法で障害からの回復を試みる際、複数の計算ノードにおいて異なるチェックポインティングデータから計算機プログラムを並列に再実行させることにより、どのチェックポインティングデータから計算機プログラムを再起動すれば障害が回復するかが短時間で解明でき、チェックポインティング手法による障害からの回復時間を短縮することができる。
【００５２】
【発明の第１の実施の形態】
図１を参照すると、本発明の第１の実施の形態にかかる耐障害計算機システムは、複数の計算ノード１と、これら複数の計算ノード１を管理する少なくとも１つの管理ノード２と、これら複数の計算ノード１および管理ノード２を互いに通信可能に接続する通信経路３とを含んで構成される。
【００５３】
計算ノード１は、少なくとも１つのプロセッサ５と、メモリ６と、並列実行対象となる計算機プログラム４と、自計算ノードにおける計算機プログラム実行環境の設定機能、計算機プログラム４をメモリ６に読み込んで実行させるなどのプロセス管理機能および通信経路３を介してのデータの送受信機能を持つプログラム実行管理部７とを含んで構成される。計算機プログラム４は、管理ノード２から与えられる処理要求を処理し、その処理結果を管理ノード２に返却するアプリケーションプログラムであり、全ての計算ノード１で同一のアプリケーションプログラムが使用される。
【００５４】
管理ノード２は、各計算ノード１毎のプログラム実行状態（チェックポインティングデータなど）および計算機プログラム実行環境の設定データなどを記憶する記憶部１３と、複数の計算ノード１において並列実行される複数の計算機プログラム４の実行状態を管理し、システムの状態を考慮してジョブ（処理要求）の管理を行うジョブ管理部８と、システム全体における障害の状態を監視し、障害発生時には障害対応処理を実行する障害管理部９とを含んで構成される。
【００５５】
通信経路３は、バス、シリアル、パラレル、ＬＡＮ、無線ＬＡＮ、インターネット、公衆回線などの任意の通信回線であり、また複数を組み合わせた多重化通信回線であっても良い。
【００５６】
ここで、個々の計算ノード１および管理ノード２は、例えば１台のパーソナルコンピュータ（ＰＣ）や大型計算機の１つのセルなど、物理的に存在する実マシンであっても良いし、仮想マシンであっても良い。また、全ての計算ノード１および管理ノード２を、全て実マシンで実現しても良いし、全て仮想マシンで実現しても良く、一部の計算ノード１は仮想マシンで、残りの計算ノード１は実マシンで実現する如く、仮想マシンと実マシンとが混在していても良い。
【００５７】
仮想マシンは、図２の仮想マシン１１に示されるように、物理的な計算機１２とその上で実行される仮想マシンモニタと呼ばれる制御ソフトウェア１３とで実現される仮想マシン実行環境１４を利用して、ソフトウェアで実現される計算機であり、計算機シュミレータあるいは計算機エミュレータとも呼ばれる。仮想マシンは、実マシンと論理的には全く同じ動作をする。同じ仮想マシン実行環境１４上に１つまたは複数の仮想マシン１１を実現することができ、各々の仮想マシン１１は独自の機器構成をとることができる。仮想マシン１１が備えるプロセッサやメモリ等の資源は仮想資源と呼ばれる。制御ソフトウェア１３の最も基本的な機能は、仮想マシン１１が備える仮想資源と計算機１２が備える実資源とのマッピング機能である。
【００５８】
このように仮想マシンはソフトウェアで実現されているので、必要な時にのみ存在する。つまり、必要な時に仮想マシンは生成され、不要となると消去される。そのため、計算ノード１に仮想マシンを使用すると、常時多様な環境を実現する計算機および機器を用意する必要なく、コストの削減が可能となる。また、仮想マシンは、ソフトウェアで実現されているので、主記憶メモリのサイズなど各種のパラメータ設定の変更が容易であり、多様な実行環境を指定することが容易である。
【００５９】
本実施の形態の耐障害計算機システムは、複数の計算ノード１にそれぞれ異なる計算機プログラム実行環境を設定し、その異なる計算機プログラム実行環境で同一の計算機プログラム４を並列実行することを基本とする。
【００６０】
計算機プログラム実行環境は、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類に大別され、この４種類のうちの少なくとも１種類が相違すると、異なる計算機プログラム実行環境となる。
【００６１】
ハードウェア環境とは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類などのことである。これらハードウェア環境を規定する計算機の主記憶容量などをハードウェア環境パラメータと呼ぶ。ハードウェア環境パラメータの１つでも互いに相違するハードウェア環境は異なるハードウェア環境となる。
【００６２】
ソフトウェア環境とは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのバージョンのことである。基本ソフトウェアとは、インターネットブラウザ、ファイアーウォール、ウィルスチェッカーなどのように、常時実行されるために、計算機プログラムの動作に影響を与えるもののことである。各種デバイスドライバとは、ディスクドライバなどのことである。各種ライブラリとは、動的リンクライブラリなどのことである。また、これらのソフトウェアに対する修正パッチ、セキュリティパッチの適用・未適用の設定もソフトウェア環境の一つである。さらに、ＯＳ、基本ソフトウェア、ライブラリの動作を規定するレジストリ、セキュリティポリシー、アクセスポリシーなどのコンフィグレーションファイルの設定状態もソフトウェア環境に含まれる。これらソフトウェア環境を規定するＯＳのバージョンなどをソフトウェア環境パラメータと呼ぶ。ソフトウェア環境パラメータの１つでも互いに相違するソフトウェア環境は異なるソフトウェア環境となる。
【００６３】
外部接続機器環境とは、計算機に接続されている外部記憶装置、表示装置、入力装置、通信装置などの仕様のことである。例えば、シリアルポート、ディスプレイ、ハードディスク、ネットワーク、キーボード、マウス、タブレット、プリンタ、スピーカーなどの仕様である。これら外部接続機器環境を規定する外部記憶装置の仕様を外部接続機器環境パラメータと呼ぶ。外部接続機器環境パラメータの１つでも互いに相違する外部接続機器環境は異なる外部接続機器環境となる。
【００６４】
プログラム起動環境とは、計算機プログラムの起動方法の種類であり、具体的には、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムとＯＳの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動といったプログラム起動方法の種類である。これらプログラム起動環境を規定する起動方法の種類はプログラム起動環境のパラメータの１つである。また、計算機プログラムをチェックポインティングしたデータから再スタートさせる際に、どの時点でチェックポインティングしたデータから再スタートするかもプログラム起動環境のパラメータの１つである。さらに、計算ノードが活性化する条件もプログラム起動環境のパスワードに含まれる。例えば、ある計算ノードは、システムが運用開始と同時に活性化し、別の計算ノードは、別の計算ノードの停止または負荷増加のイベント通知を受けて活性化するなどの如きものである。プログラム起動環境パラメータの１つでも互いに相違するプログラム起動環境は異なるプログラム起動環境となる。
【００６５】
本実施の形態においては、管理ノード２の記憶部１０における計算機プログラム実行環境定義領域に、各計算ノード１毎の計算機プログラム実行環境設定データが定義されており、且つそれぞれの計算ノード１の計算機プログラム実行環境設定データは互いに異なるように定義されている。各計算ノード１のプログラム実行管理部７は、管理ノード２のジョブ管理部８から自身の計算機プログラム実行環境の情報を取得し、その情報を用いて自計算ノード１の実行環境を設定し、計算プログラム４を読み込み、他の計算ノード１と並列に実行する。
【００６６】
ここで、計算機プログラム４に存在する特定のバグが活性化する特定の状態を全ての計算ノード１で同時に起き難くするためには、計算ノード１どうしの計算機プログラム実行環境の相違度を或る程度以上大きくするのが望ましい。何故なら、他の環境やパラメータは全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するだけでは殆ど効果がないからである。そこで、本実施の形態では、複数の計算ノードの任意の２つの計算ノード間の計算機プログラム実行環境の相違度は、予め定められた相違度以上に相違するように定められている。以下、この点について説明する。
【００６７】
今、２つの計算ノードＸ、Ｙの計算機プログラム実行環境の相違度をＤＸＹとし、次式に示すように定義する。
ＤＸＹ＝ａＤＨ＋ｂＤＳ＋ｃＤＧ＋ｄＤＫ …（１）
【００６８】
ここで、ＤＨは計算ノードＸ、Ｙのハードウェア環境の相違度、ＤＳは計算ノードＸ、Ｙのソフトウェア環境の相違度、ＤＧは計算ノードＸ、Ｙの外部接続機器環境の相違度、ＤＫは計算ノードＸ、Ｙのプログラム起動環境の相違度をそれぞれ示す。ａ，ｂ，ｃ，ｄは重み付けの変数であり、全て同じ値を使えば各環境の相違度を公平に考慮することができ、他のものに比べて大きな値を用いればその環境の相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００６９】
ハードウェア環境の相違度ＤＨは、ハードウェア環境のパラメータ数をｒ個とすると、次式で定義される。
ＤＨ＝ｈ１｜ＤＨＸ１−ＤＨＹ１｜＋ｈ２｜ＤＨＸ２−ＤＨＹ２｜＋ … ＋ｈｒ｜ＤＨＸｒ−ＤＨＹｒ｜ …（２）
【００７０】
ここで、ＤＨＸｉ（ｉ＝１〜ｒ）は計算ノードＸのハードウェア環境のｉ番目のパラメータ、ＤＨＹｉ（ｉ＝１〜ｒ）は計算ノードＹのハードウェア環境のｉ番目のパラメータ、｜ＤＨＸｉ−ＤＨＹｉ｜は計算ノードＸ、Ｙのハードウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、メモリ６の相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、プロセッサ５の相違度は、種類が同じで且つバージョンが同じであれば相違度０、種類が同じであるがバージョンが異なれば相違度１、種類が異なれば相違度２の如く定められる。また、キャッシュの有効、無効のパラメータなど、取り得る状態が２つしか無いパラメータの場合、両者が同じ状態であれば相違度０、異なっていれば相違度１とする。ｈｉ（ｉ＝１〜ｒ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７１】
ソフトウェア環境の相違度ＤＳは、ソフトウェア環境のパラメータ数をｓ個とすると、次式で定義される。
ＤＳ＝ｓ１｜ＤＳＸ１−ＤＳＹ１｜＋ｓ２｜ＤＳＸ２−ＤＳＹ２｜＋ … ＋ｓｓ｜ＤＳＸｓ−ＤＳＹｓ｜ …（３）
【００７２】
ここで、ＤＳＸｉ（ｉ＝１〜ｓ）は計算ノードＸのソフトウェア環境のｉ番目のパラメータ、ＤＳＹｉ（ｉ＝１〜ｓ）は計算ノードＹのソフトウェア環境のｉ番目のパラメータ、｜ＤＳＸｉ−ＤＳＹｉ｜は計算ノードＸ、Ｙのソフトウェア環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ＯＳの相違度は、同じ種類で且つバージョンが同じであれば相違度０、同じ種類のＯＳであるがバージョンが異なれば相違度１、異なる種類のＯＳであれば相違度２の如く定められる。ウィルスチェッカーなど、実装の有無も相違する場合、例えば、共に実装されていてバージョンが同じであれば相違度０、同じ種類のプログラムであるがバージョンが異なれば相違度１、異なる種類のプログラムであれば相違度２、実装の有無が相違すれば相違度３の如く定められる。ｓｉ（ｉ＝１〜ｓ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７３】
外部接続機器環境の相違度ＤＧは、外部接続機器環境のパラメータ数をｔ個とすると、次式で定義される。
ＤＧ＝ｇ１｜ＤＧＸ１−ＤＧＹ１｜＋ｇ２｜ＤＧＸ２−ＤＧＹ２｜＋ … ＋ｇｔ｜ＤＧＸｔ−ＤＧＹｔ｜ …（４）
【００７４】
ここで、ＤＧＸｉ（ｉ＝１〜ｔ）は計算ノードＸの外部接続機器環境のｉ番目のパラメータ、ＤＧＹｉ（ｉ＝１〜ｔ）は計算ノードＹの外部接続機器環境のｉ番目のパラメータ、｜ＤＧＸｉ−ＤＧＹｉ｜は計算ノードＸ、Ｙの外部接続機器環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、ハードディスクの相違度は、２倍未満の容量差であれば相違度０（実質的な相違なし）、２倍以上４倍未満の容量差があれば相違度１、４倍以上８倍未満の容量があれば相違度２の如く定められる。また、プリンタの相違度は、共に実装されていて同じ種類であれば相違度０、共に実装されているが種類や仕様が異なれば相違度１、実装の有無が相違すれば相違度３の如く定められる。ｇｉ（ｉ＝１〜ｔ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７５】
プログラム起動環境の相違度ＤＫは、プログラム起動環境のパラメータ数をｕ個とすると、次式で定義される。
ＤＫ＝ｋ１｜ＤＫＸ１−ＤＫＹ１｜＋ｋ２｜ＤＫＸ２−ＤＫＹ２｜＋ … ＋ｋｕ｜ＤＫＸｕ−ＤＫＹｕ｜ …（５）
【００７６】
ここで、ＤｋＸｉ（ｉ＝１〜ｕ）は計算ノードＸのプログラム起動環境のｉ番目のパラメータ、ＤｋＹｉ（ｉ＝１〜ｕ）は計算ノードＹのプログラム起動環境のｉ番目のパラメータ、｜ＤｋＸｉ−ＤｋＹｉ｜は計算ノードＸ、Ｙのプログラム起動環境のｉ番目どうしのパラメータの相違度で、パラメータの種類に応じて定められる。例えば、再起動方法の相違度は、種類が同じであれば相違度０、種類が異なれば相違度１の如く定められる。ｋｉ（ｉ＝１〜ｕ）は重み付けの変数であり、全て同じ値を使えば各パラメータの相違度を公平に考慮することができ、他のものに比べて大きな値を用いればそのパラメータの相違度を重要視できる。これらの重み付け変数は、実験や経験、過去の計算機資源の使用履歴の解析結果などに基づいて設定される。
【００７７】
各計算ノード１の計算機プログラム実行環境の選定に際しては、式（１）で計算される任意の２つの計算ノード間の計算機プログラム実行環境の相違度が、予め定められた閾値の相違度よりも大きくなるように選定される。これにより、他の環境は全て同じで、主記憶容量だけが高々数バイト乃至数十バイト程度相違するような２つの計算機プログラム実行環境を設定するような事態を防止することができる。また、閾値を高く設定すれば、複数の計算ノード１で計算機プログラム４に存在するバグが同時に発現する確率をより小さくすることができる。
【００７８】
図３は本実施の形態の耐障害計算機システムにおける処理の流れを示すフローチャートであり、システム上で稼動するプログラムによって実行される。以下、図３を参照して、本実施の形態の耐障害計算機システムの動作の概略を説明する。
【００７９】
システムが起動されると、複数の計算ノード１が互いに異なる計算機プログラム実行環境で同一の計算機プログラム４が並列実行されるように、各計算ノード１に計算機プログラム実行環境の設定が行われる（Ｓ１０１〜Ｓ１０４）。各計算ノード１の実行環境の設定後、システムは、各計算ノード１で計算機プログラム４を並列実行する通常運用状態となる。
【００８０】
通常運用状態では、ジョブ管理部８および障害管理部９においてシステムの状態を取得し（Ｓ１０５）、取得したシステムの状態に応じた処理を行う。ステップＳ１０５で取得するシステムの状態は、システム全体の終了命令が発行されたかどうか、障害が検出されたかどうか、計算機プログラム４で処理すべき新たな処理要求が発生したかどうか、計算機プログラム４で処理要求に対する処理が終了したかどうかなどである。また、チェックポインティング手法による障害回復を行うために、チェックポインティングデータを各計算ノード１で採取し、プログラム実行管理部７を通じて通信経路３経由で管理ノード２へ送信し、ジョブ管理部８が記憶部１０における各計算ノード毎のプログラム実行状態記憶領域に保存する処理も、このシステム状態取得で実施される。各計算ノード１におけるチェックポインティングデータの採取方法は当業者に良く知られた方法なので説明は省略する。
【００８１】
システム全体の終了命令が発行された場合（Ｓ１０６でＹｅｓ）、終了処理が行われ（Ｓ１０７）、すべてのノードが停止する。障害が検出された場合（Ｓ１０８でＹｅｓ）、障害対応処理が実行され（Ｓ１０９）、その後にシステム状態の取得ステップＳ１０５に戻り、システムの運用を継続する。新たな処理要求が発生した場合（Ｓ１１０でＹｅｓ）、その処理要求を複数の計算ノード１上の計算機プログラム４に処理させるための処理要求処理が実行され（Ｓ１１１）、その後、システム状態の取得ステップＳ１０５に戻る。計算機プログラム４で処理要求に対する処理が終了した場合（Ｓ１１２でＹｅｓ）、システムとしての処理結果を導出するための処理結果処理が実行され（Ｓ１１３）、再びシステム状態の取得ステップＳ１０５に戻る。
【００８２】
次に、各段階における動作の詳細を説明する。
【００８３】
（１）計算機プログラム実行環境の設定（図３のＳ１０１〜Ｓ１０４）
管理ノード２のジョブ管理部８は、内部の変数Ｎを１に初期設定し（Ｓ１０１）、複数存在する計算ノード１のうち１番目の計算ノードに注目し、その計算ノード１のプログラム実行管理部７と協調して、その計算ノード１の計算機プログラム実行環境を設定する（Ｓ１０２）。ジョブ管理部８は、１つの計算ノードに対する計算機プログラム実行環境の設定を終えると、変数Ｎを１加算し（Ｓ１０４）、２番目の計算ノードに対して同様の処理を繰り返す。これを、必要な全ての計算ノード１に対する処理が終るまで（Ｓ１０３でＹｅｓ）、繰り返す。ステップＳ１２の処理例を以下に示す。
【００８４】
（ａ）計算ノード１が実マシンの場合
ジョブ管理部８は、計算ノード１に対して遠隔操作などで電源オンの命令を送信する。この命令によって起動した計算ノード１は、起動途中で、プログラム実行管理部７により自身の計算機プログラム実行環境をジョブ管理部８に問い合せる。ジョブ管理部８は、記憶部１０から、その計算ノード用のプログラム実行環境設定データを読み出し、応答する。プログラム実行管理部７は、応答されたプログラム実行環境設定データを用いて、自計算ノードの実行環境を設定する。具体的には、例えば計算ノードが一般的なＰＣの場合、プログラム実行管理部７は、実行環境の設定をＢＩＯＳに保存して再起動し、再起動後、プログラム実行管理部７は計算機プログラム４の処理を開始させる。
【００８５】
（ｂ）計算ノード１が仮想マシンの場合
仮想マシンの実行環境は、その仮想マシンを実現している実マシン上にあるファイルで指定される。従って、ジョブ管理部８は、計算ノード（仮想マシン）を実現している実マシン上の該当するファイルを、記憶部１０から読み出した当該計算ノード用の設定データで更新し、その仮想マシンのプロセスを起動する。起動後、その計算ノード（仮想マシン）のプログラム実行管理部７が計算機プログラム４の処理を開始する。
【００８６】
他の方法として、異なる実行環境をもつ計算ノードを予め多数用意しておき、ジョブ管理部８がどの計算ノードを活性化させるかを制御することで、それぞれ計算機プログラム実行環境の異なる複数の計算ノードを起動するようにしても良い。この場合、計算ノードが実マシンのときは、遠隔操作による電源オンの命令の送信により起動され、仮想マシンのときはそのプロセスの起動命令の送信により行われる。
【００８７】
（２）システム全体の終了命令関連（図３のＳ１０５、Ｓ１０７）
システム全体の終了命令は、システム運用者からの入力、タイマーなどのイベントをトリガーとして発行される。システム全体の終了命令は、管理ノード２で検出され、各計算ノード１に通知される。具体的な制御命令は、記憶部１０に保持された各計算ノード１毎のプログラム実行環境設定データに応じて、ジョブ管理部８から発行される。これにより、例えば、或る計算ノード１は、チェックポインティング処理を行い、そのチェックポインティングデータを磁気テープなどにコピーする処理を行って、シャットダウン処理を行う。他の計算ノード１では、例えば、自計算ノード１にＵＰＳ装置など電源装置が接続されていれば、その電源装置を介して電源断の処理を行う。また、他の計算ノード１では、主記憶・仮想記憶の状態を保持したまま停止するＳＴＲ（Ｓｕｓｏｐｅｎｄ ｔｏ ＲＡＭ）を行う。
【００８８】
（３）障害関連処理（図３のＳ１０５、Ｓ１０９）
障害の発生の有無をチェックする手法については、ｐｉｎｇ−ｐｏｎｇ方式など従来より様々な手法が存在し、本発明はこれらの任意の手法の一つ或いは複数を組み合わせて用いることができる。例えば、ｐｉｎｇ−ｐｏｎｇ方式を用いる場合、障害管理部９が通信経路３を介し、ｐｉｎｇ−ｐｏｎｇ方式のハートビート信号を用いて各計算ノード１の動作状況を調べ、障害の発生の有無をチェックする。ハートビート信号とは、例えばＩＰネットワークのｐｉｎｇがよく知られている。管理ノード２からＩＰネットワーク上にあるデバイス（この場合には計算ノード１）に対して、インターネット制御プロトコル（ＩＣＭＰ）でｐｉｎｇ信号を発行する。一方、計算ノード１は、ｐｉｎｇ信号を受けると、ｐｏｎｇ信号を発行して応答する。管理ノード２は各計算ノード１からｐｏｎｇ信号を受けることで、管理ノード２とその計算ノード１が、ＩＰネットワークレベルで正常に動作していることを確認する。このようなｐｉｎｇ−ｐｏｎｇ方式の通信を、一定時間間隔で行うことで、ハートビート信号による障害の有無のチェックを行う。
【００８９】
次に、発生した障害に対する障害対応処理（Ｓ１０９）について説明する。
【００９０】
図４はステップＳ１０９で実施される障害対応処理の一例を示すフローチャートである。障害管理部９は、障害を検知すると、予め内部に設定されている障害対応テーブル（図示せず）を検索して、発生した障害に対して実行すべき障害対応方法を取得し（Ｓ１２１）。この取得した障害対応方法を実行する命令を発行する（Ｓ１２２）。具体的には、障害対応テーブルには、障害の種類毎の障害コードと、その種類の障害に対して実行すべき障害対応方法のコマンドとがペアで設定されており、検知した障害の障害コードでテーブルを検索してコマンドを取得し、そのコマンドを発行する。次に、障害管理部９は、どの計算ノードに対してどのような障害対応方法を実行済み或いは実行中であるかなどを示す障害対応ログを、記憶部１０の障害対応ログ記憶領域に保存する（Ｓ１２３）。この保存された障害対応ログは、再び障害が発生した場合に、過去にどのような障害対応方法が実施され、あるいは実行中であるかを考慮して次の障害対応方法を決定するために利用される。他方、発行されたコマンドを受信した計算ノード１では、そのコマンドを実行することより、障害対応方法を実施する（Ｓ１２４）。
【００９１】
以上のような障害対応処理を行うことにより、例えば、或る計算ノード１のｐｉｎｇ応答がないという障害が検知され、その障害コードが０１０１であり、障害コード０１０１に対応して「再起動コマンド」が障害対応テーブルに設定されている場合、その計算ノード１に対して再起動コマンドが発行され、その計算ノード１の再起動により障害の回復が試行される。ここで、同じ計算機プログラム実行環境の下で計算ノード１を再起動して計算機プログラム４を再スタートすると、再び同じ障害が発生する確率が高いため、障害の発生した計算ノード１の計算機プログラム実行環境を記憶部１０に記憶されている別のプログラム実行環境設定データを用いて変更し、その後に計算ノード１を再起動するようにしても良い。計算ノード１のプログラム実行環境の変更はステップＳ１０２で説明した処理と同様の処理で可能である。また、計算機プログラム４のプログラムの実行状態（プロセスや入出力の優先度など）を変更して、再起動するようにしても良い。
【００９２】
また、障害対応方法がチェックポインティング手法による回復の場合、記憶部１０からチェックポインティングデータが読み出されて通信経路３経由で計算ノード１に送られ、障害によって計算機プログラム４の実行を一時停止している計算ノード１では、プログラム実行管理部５によって、受信したチェックポインティングデータを用いてデータを復元し、計算機プログラム４を再起動することによって障害の回復が試行される。ここで、計算機プログラム４の一時停止と再起動は、その計算ノード１に設定されたプログラム実行環境設定データのプログラム起動環境に従う。つまり、計算機プログラム４のサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラム４のサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラム４のＯＳによる停止と再起動、計算機プログラム４とＯＳのシャットダウン処理と再起動、計算機プログラム４とＯＳの強制終了と再起動、計算機プログラム４とＯＳの再インストール後の再起動、計算機プログラム４とＯＳのクリアインストール後の再起動のうち、その計算ノード１のプログラム起動環境で指定された方法で行われる。
【００９３】
また、複数の計算ノード１で障害が発生した場合のチェックポインティング手法による回復処理では、障害管理部９は、これら複数の計算ノード１において、異なるチェックポインティングデータから計算機プログラム４を並列に再実行させることにより、どのチェックポインティングデータから計算機プログラム４を再起動すれば障害が回復するかを短時間で解明し、チェックポインティング手法による障害からの回復時間を短縮する。どの計算ノード１にどのチェックポインティングデータを用いたかは障害対応ログで管理される。
【００９４】
以上、障害対応方法について具体例を幾つか説明したが、勿論、ここに述べたような方法以外にも、障害の発生した計算ノードを停止させる、計算機プログラムの移動やコピーを行って、障害の発生した計算ノードで行われていた処理を他の計算ノードに代替させる、システム運用者へ障害の発生を知らせる電子メールを送信する等、任意の障害対応処理が可能である。また、障害の発生した計算ノードを停止させると以後その計算ノードに関する障害検出は不要になる等、実行した障害対応方法によって障害検知動作の変更が必要な場合、障害管理部９は障害管理動作を変更する。
【００９５】
（４）処理要求に関連する処理（図３のＳ１０５、Ｓ１１１、Ｓ１１３）
管理ノード２のジョブ管理部８は、耐障害計算機システムで処理すべき処理要求が発生すると、その処理要求を複数の計算ノード１上の計算機プログラム４に処理させるための処理要求処理Ｓ１１１を実行し、また複数の計算ノード１の計算機プログラム４で処理要求に対する処理が終了すると、システムとしての処理結果を導出するための処理結果処理Ｓ１１３を実行する。処理要求処理Ｓ１１１の一例を図５に、処理結果処理Ｓ１１３の一例を図６に、この処理要求処理および処理要求処理を行うジョブ管理部８の構成例を図７に、それぞれ示す。
【００９６】
図７を参照すると、ジョブ管理部８は、要求メッセージ分配条件記憶部３２、要求処理判断部３３、要求メッセージ受信部３４、要求メッセージ転送先記憶部３５、要求転送メッセージ生成部３６、要求転送メッセージ送信部３７、応答メッセージ生成条件記憶部３８、応答処理判断部３９、応答メッセージ受信部４０、応答メッセージ転送先記憶部４１、応答転送メッセージ生成部４２、応答転送メッセージ送信部４３および応答メッセージ保持部４４を含んで構成され、サービスを要求するクライアントなどといった要求メッセージ送信元２０に接続されると共に、システム内部では障害管理部９および複数の計算ノード１に接続される。なお、図７に示される応答メッセージ送信先２１は、要求メッセージ送信元あるいは計算ノードに相当する。
【００９７】
要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５には、障害管理部９によってシステムの状態に応じて更新される分配先情報が記憶される。つまり、要求メッセージ分配条件記憶部３２には、要求メッセージ送信元２０から受信した要求メッセージを分配する計算ノードを指定する情報が設定され、要求メッセージ転送先記憶部３５にはそれらの各計算ノードの宛先情報が設定されており、それぞれ障害管理部９の情報更新部３１によって障害対応処理の一環として更新される。例えば、或る計算ノード１の障害によりその障害ノード１を停止等してシステムから論理的に切り離した場合、障害管理部９の情報更新部３１によって、当該計算ノード１に関する情報が要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５から削除され、また代替可能な計算ノード１が他に存在すれば、障害管理部９によって、当該代替可能な計算ノード１に関する情報が要求メッセージ分配条件記憶部３２および要求メッセージ転送先記憶部３５に追加される。
【００９８】
また、応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１には、応答生成条件および障害管理部９によってシステムの状態に応じて更新される分配先情報を含む判断基準情報が記憶される。つまり、応答メッセージ生成条件記憶部３８には、計算ノード１から受信した応答メッセージから応答メッセージ送信先２１に転送する応答転送メッセージを生成する条件および転送先情報が設定され、応答メッセージ転送先記憶部４１には各応答転送メッセージ送信先の宛先情報が設定されており、障害管理部９の情報更新部３１によって障害対応処理の一環として更新される。例えば、或る計算ノード１の障害によりその障害ノード１を停止等してシステムから論理的に切り離した場合、障害管理部９の情報更新部３１によって、当該計算ノード１に関する情報が応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１から削除され、また代替可能な計算ノード１が他に存在すれば、障害管理部９によって、当該代替可能な計算ノード１に関する情報が応答メッセージ生成条件記憶部３８および応答メッセージ転送先記憶部４１に追加される。なお、要求メッセージ送信元２０の宛先情報は、処理判断部３３によって応答メッセージ転送先記憶部４１に登録され、要求メッセージ送信元２０に通知されるシステムとしての処理結果の返却時に、応答転送メッセージ生成部４２により参照される。
【００９９】
要求メッセージ送信元２０から本実施の形態の耐障害計算機システムに要求メッセージが送信されてくると、要求メッセージ受信部３４で受信する（Ｓ１３１）。要求処理判断部３３では、要求メッセージ分配条件記憶部３２を参照して、受信した要求メッセージの転送の可否および転送する場合には転送先の計算ノード１を判断する（Ｓ１３２）。転送先が無いなどの理由で転送しないと判断した場合は、要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元２０に返す。転送すると判断した場合、要求処理判断部３３は、転送先の計算ノードを指定して要求メッセージを要求転送メッセージ生成部３６に伝達する。
【０１００】
要求転送メッセージ生成部３６は、要求メッセージ転送先記憶部３５を参照して、要求メッセージの宛先を転送する計算ノード１に書き換えることで、実際に転送する要求メッセージを生成する（Ｓ１３３）。ここで、転送先の計算ノード１が複数あるのであれば、要求転送メッセージ生成部３６は、要求メッセージを複製し、それぞれの宛先を転送先の計算ノード１に書き換えることで、複数の転送する要求メッセージを生成する。
【０１０１】
要求転送メッセージ送信部３７は、要求転送メッセージ生成部３６で生成された要求メッセージを、通信経路３を通じて、該当する計算ノード１に送信する（Ｓ１３４）。要求メッセージの転送を受けた計算ノード１のプログラム実行管理部７は、その要求メッセージを計算機プログラム４に処理させる。
【０１０２】
各計算ノード１の計算機プログラム４は、要求された処理を行い、応答メッセージを送信する。要求メッセージ送信元２０からの要求メッセージを計算機プログラム４で一度処理するだけで、その計算機プログラム４から最終的な処理結果の応答メッセージが出される場合だけでなく、最終的な処理結果を得る過程で別の計算ノードや外部のシステムにデータベースアクセスなどの処理要求を行う応答メッセージ（別サービス要求メッセージ）が返される場合がある。応答メッセージ受信部４０は、このような計算機プログラム４からの応答メッセージを受信し、応答メッセージ保持部４４に蓄積する（Ｓ１４１）。
【０１０３】
応答処理判断部３９は、応答転送メッセージ生成に必要な処理結果が応答メッセージ保持部４４に蓄積されたかどうかを判断し（Ｓ１４２）、未だ蓄積されていないときは今回の処理結果処理Ｓ１１３を終了する。必要な処理結果が蓄積されていれば、応答処理判断部３９は、応答メッセージ生成条件記憶部３８を参照して、応答転送メッセージの生成可否および転送先の判断を行い、応答転送メッセージを生成する（Ｓ１４３）。例えば、蓄積されている応答メッセージが別サービス要求メッセージであって、別サービス要求メッセージを分配する計算ノードが１つも無いなどの理由で転送しないと判断した場合、おおもとの要求メッセージを破棄するか、受信できない旨のメッセージを要求メッセージ送信元２０に送信する。また、蓄積されている応答メッセージが別サービス要求メッセージであって分配先が存在するために転送すると判断した場合および蓄積されている応答メッセージが別サービス要求メッセージでなく最終的な応答メッセージの場合、応答メッセージが一つであれば、そのメッセージをそのまま転送するメッセージとする。複数の計算ノード１の計算機プログラム４から複数の応答メッセージがある場合、応答処理判断部３９は、応答メッセージ生成条件記憶部３８を参照して、以下のような応答メッセージの選択あるいは生成を行い、転送先を指定して応答転送メッセージ生成部４２に伝達する。転送先は、最終的な応答であれば要求であれば、要求メッセージ元であり、別サービス要求メッセージであれば、計算ノード１等である。
【０１０４】
（ａ）任意の一つの実行ノード１の計算機プログラム４からの応答メッセージを選択し、これを応答転送メッセージとする。このとき、最も早く到着した応答メッセージを選択するようにしても良い。
（ｂ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージから多数決論理により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｃ）予め定められたＮ個の応答メッセージが到着次第、多数決により１つの応答メッセージを選択し、これを応答転送メッセージとする。
（ｄ）予め設定されたタイムアウト時間（例えば１分）内に受信した複数の応答メッセージの平均値を取るなどの統計処理を行い、統計処理で得られた値をもつ応答転送メッセージを生成する。
【０１０５】
応答メッセージの選択あるいは生成の方法は、これらに限定されるものではなく、その他任意の方法を使用することができる。
【０１０６】
応答転送メッセージ生成部４２は、応答メッセージ転送先記憶部４１を参照して、応答転送メッセージの宛先を応答メッセージ送信先２１に書き換えることで、実際に転送する応答転送メッセージを生成する（Ｓ１４４）。応答転送メッセージ送信部４３は、生成された応答転送メッセージを応答メッセージ送信先２１に送信する（Ｓ１４５）。応答メッセージ送信先２１が、計算ノード１である場合、計算ノード１の計算機プログラム４は要求された処理を行い、その処理結果を応答メッセージで送信する。また、応答メッセージ送信先２１が、要求メッセージ送信元２０である場合、システムとしての処理結果が要求メッセージ送信元２０に返却されたことになる。
【０１０７】
【発明の第２の実施の形態】
図８を参照すると、本発明の第２の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１および管理ノード２で共有する構成とした点で第１の実施の形態と相違する。
【０１０８】
本実施の形態では、各計算ノード１毎の計算機プログラム実行環境設定データを定義した記憶部１０を全てのノードで共有しているため、各計算ノード１の計算機プログラム実行環境を設定したり、既に設定されている環境を別の環境に再設定する際、管理ノード２から通信経路３経由でプログラム実行環境設定データを各計算ノード１に送信する必要がなく、記憶部１０に記憶されているどの計算機プログラム実行環境を使用するかを管理ノード１０から計算ノード１に対して通信経路３経由あるいは記憶部１０上に設けた通信領域経由で通知し、計算ノード１が記憶部１０からプログラム実行環境設定データを読み出して、自ノードの実行環境の設定が行える。また、障害を検出した計算ノード１のプログラム実行状態（プロセスや入出力の優先度など）を変更する際にも、管理ノード２が記憶部１０上に記憶されている当該計算ノード１のプログラム実行状態を更新し、計算ノード１がその更新されたプログラム実行状態を記憶部１０から読み出して自計算ノード１のプログラム実行状態を更新するといった動作が行える。
【０１０９】
また、各計算ノード１のチェックポインティングデータを記憶する記憶部１０を各計算ノード１で共有することで、各計算ノード１がチェックポインティングデータを記憶部１０に保存したり、記憶部１０からチェックポインティングデータを読み出して再スタートする際に管理ノード２とチェックポインティングデータを授受する必要がなくなり、チェックポインティングのデータ転送が容易となる。そのため、計算機プログラムの移動やコピーも容易となる。また、他の計算ノード１の実行状態に応じて、自動的に自ノードの計算機プログラム４の動作状態を変更することも可能である。
【０１１０】
【発明の第３の実施の形態】
図９を参照すると、本発明の第３の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１および管理ノード２に個別に備え、各ノードが通信して、各記憶部１０の同一性を保つミラーリングを行うようにした点で第１の実施の形態と相違する。ミラーリングにおいては、データの更新の都度、通信を行って、分散したデータの同一性を保つ手法を用いても良いし、データ参照がある時点で、新たにデータ更新がされていないかどうかをチェックし、更新されている部分だけ通信を行って、分散したデータの同一性を保つ手法を用いても良い。
【０１１１】
本実施の形態では、各計算ノード１毎の計算機プログラム実行環境設定データを定義した記憶部１０を各ノード毎に備えているため、各計算ノード１の計算機プログラム実行環境を設定したり、既に設定されている環境を別の環境に再設定する際、管理ノード２から通信経路３経由でプログラム実行環境設定データを各計算ノード１に送信する必要がなく、記憶部１０に記憶されているどの計算機プログラム実行環境を使用するかを管理ノード１０から計算ノード１に対して通信経路３経由あるいは記憶部１０上に設けた通信領域経由で通知し、計算ノード１が記憶部１０からプログラム実行環境設定データを読み出して、自ノードの実行環境の設定が行える。また、障害を検出した計算ノード１のプログラム実行状態（プロセスや入出力の優先度など）を変更する際にも、管理ノード２が記憶部１０上に記憶されている当該計算ノード１のプログラム実行状態を更新し、計算ノード１がその更新されたプログラム実行状態を記憶部１０から読み出して自計算ノード１のプログラム実行状態を更新するといった動作が行える。
【０１１２】
また、各計算ノード１のチェックポインティングデータを記憶する記憶部１０を各計算ノード１で共有することで、各計算ノード１がチェックポインティングデータを記憶部１０に保存したり、記憶部１０からチェックポインティングデータを読み出して再スタートする際に管理ノード２とチェックポインティングデータを授受する必要がなくなり、チェックポインティングのデータ転送が容易となる。そのため、計算機プログラムの移動やコピーも容易となる。また、他の計算ノード１の実行状態に応じて、自動的に自ノードの計算機プログラム４の動作状態を変更することも可能である。
【０１１３】
さらに、同じデータが複数の記憶部１０に分散して記憶されているため、耐障害性を高めることができる。但し、ミラーリングのための通信負荷が高く、システムのパフォーマンスが悪くなる可能性はある。
【０１１４】
【発明の第４の実施の形態】
図１０を参照すると、本発明の第４の実施の形態にかかる耐障害計算機システムは、複数の計算ノード１のそれぞれに障害検知部５１を備え、管理ノード２の障害管理部９は、各計算ノード１の障害検知部５１から通知される障害情報を受信してシステム全体の障害管理を行う点で図１に示した第１の実施の形態にかかる耐障害計算機システムと相違する。
【０１１５】
各計算ノード１の障害検知部５１は、障害を検知すると、通信経路３経由で障害情報を管理ノード２の障害管理部９に通知する。このような構成を用いることによって、前述したｐｉｎｇ−ｐｏｎｇ方式による障害の有無のチェックに比べ、より効率的な、またより詳細な障害情報を取得することが可能となる。なぜならば、ｐｉｎｇ−ｐｏｎｇという双方向の通信に対して、障害検知部５１が継続的に一方向の信号を発行するだけで、ハートビート信号として機能するからである。障害管理部９は、ハートビート信号が途絶えたことによって、障害を検知する。また、障害検知部５１は通信経路３を用いずに各計算ノード１に含まれる各モジュールの動作情報を取得するので、たとえ通信障害が発生したとしても、その影響を受けることが少ない。障害検知部５１の一例として、サービスプロセッサがよく知られている。サービスプロセッサは、計算ノード１において演算処理を行うプロセッサ５とは別のプロセッサであり、プロセッサ５、メモリ６、それらの間のバスなどの動作状態をチェックし、動作情報を収集する機能をもつ。さらに動作情報を解析し、障害通報装置に通信する機能を持つサービスプロセッサもある。
【０１１６】
【発明の第５の実施の形態】
図１１を参照すると、本発明の第５の実施の形態にかかる耐障害計算機システムは、図１に示した第１の実施の形態にかかる耐障害計算機システムの管理ノード２が備えている記憶部１０を、全ての計算ノード１に個別に備え、各ノードが通信して、各記憶部１０の同一性を保つミラーリングを行うようにした点と、管理ノード２を省略し、管理ノード２のジョブ管理部８で集中管理していたジョブ管理を分散管理するためのジョブ管理部８’と、管理ノード２の障害管理部９で集中管理していた障害管理を分散管理するための障害管理部９’を各計算ノード１に備えるようにした点で、第１の実施の形態と相違する。ミラーリングにおいては、データの更新の都度、通信を行って、分散したデータの同一性を保つ手法を用いても良いし、データ参照がある時点で、新たにデータ更新がされていないかどうかをチェックし、更新されている部分だけ通信を行って、分散したデータの同一性を保つ手法を用いても良い。
【０１１７】
第１の実施の形態では、各計算ノード１において、プログラム実行管理は、管理ノード２と通信を行い、ジョブの割り振り、およびそのジョブを処理するプログラムの実行環境の情報を取得していたが、本実施の形態では、各計算ノード１にプログラム実行環境設定データを保持する記憶部１０があり、予め別途プログラム実行環境の設定データを保持しておくことによって、分散的なジョブ管理が可能となっている。また、各計算ノード１のプログラム実行管理部７は相互に通信して、他の計算ノード１の状態の情報を交換し、必要であれば記憶部１０のデータを更新し、自ノードの実行環境を変更したり、ジョブを他の計算ノード１に転送するなどの動作を行う。
【０１１８】
さらに、システム全体の障害状態の監視と管理は、各計算ノード１に設けられた障害管理部９’が互い通信し合って分散的に行う。このとき、検知された障害情報は、プログラム実行管理部７を経由してその他の障害管理部９’に送られ、障害情報および障害対応情報を各計算ノード１で共有する。これは、同一の障害要因に対して、複数の障害管理部９’から同時に障害対応命令が発行されて、その命令がコンフリクトし、別の不具合や障害の原因となるのを防止するためである。
【０１１９】
このように本実施の形態では、単一の管理ノードを持たないため、一つの管理ノードにおいて障害が発生しても、その他の管理ノードは継続して動作し、システム全体として障害状態の監視と管理を継続するので、より高い耐障害性を確保できる。
【０１２０】
図１１では、全ての計算ノード１に障害管理部９’を設けたが、全てではなく任意の複数の計算ノード１に障害管理部９’を設ける構成も考えられる。また、特定の１つの計算ノード１に第１の実施の形態における管理ノード２の障害管理部９と同様に障害を集中管理する障害管理部を設けるようにしても良い。
【０１２１】
【発明の効果】
以上説明したように、本発明においては、以下のような効果を奏する。
【０１２２】
同一の計算機プログラムを使用して、ソフトウェアレベルでの耐障害性を高めることができる。その理由は、ソフトウェアフォールトは、ソフトウェアであるプログラムに存在する特定のバグが特定の状態に陥った際に活性化して、障害として発現するが、本発明では、複数の計算ノードの計算機プログラム実行環境がそれぞれ異なっており、計算機プログラムに存在する特定のバグが活性化する特定の状態が全ての計算ノードで同時に起きる確率が低下するからである。
【０１２３】
計算ノードが障害状態に陥った場合に、再び同じような障害が発生するのを防止することができる。その理由は、障害にかかる計算ノードの計算機プログラム実行環境を変更して計算機プログラムを再実行するため、計算機プログラムに存在する特定のバグが活性化する特定の状態が再実行後に再び発生する確率が、計算機プログラム実行環境を変えない場合に比べて低下するからである。
【０１２４】
チェックポインティング手法による障害からの回復時間を短縮することができる。その理由は、複数の計算ノードで障害が発生し、チェックポインティング手法で障害からの回復を試みる際、複数の計算ノードにおいて異なるチェックポインティングデータから計算機プログラムを並列に再実行させるため、どのチェックポインティングデータから計算機プログラムを再起動すれば障害が回復するかが短時間で解明するからである。
【０１２５】
前述のように自動的に障害状態からの回復処理を試行するため、計算機システムの運用管理者の障害回避、回復作業の手間が省け、また人為的ミスをさけることができるという意味で障害回避、回復作業の確実性を向上させることができる。
【０１２６】
複数の計算ノード毎に障害管理手段を備え、複数の障害管理手段によってシステム全体の障害の管理を分散的に行う構成にあっては、一部の計算ノードに障害があっても、その他の計算ノードで障害管理機能を提供することができるため、耐障害計算機システムの障害管理機能の耐障害性を向上させることができる。
【０１２７】
処理要求分配手段として、障害管理手段によってシステムの状態に応じて更新される分配先情報を記憶する記憶部、要求メッセージ受信部、処理判断部、要求転送メッセージ生成部および要求転送メッセージ送信部を備える構成にあっては、サービスを要求するクライアント等の処理要求元から入力される処理要求をシステムの状態に応じた複数の計算ノードの計算機プログラムで並列に処理することができる。
【０１２８】
処理結果導出手段として、応答生成条件および障害管理手段によってシステムの状態に応じて更新される分配先情報を含む判断基準情報を記憶する記憶部、応答メッセージ受信部、応答メッセージ保持部、応答処理判断部、応答転送メッセージ生成部および応答転送メッセージ送信部を備える構成にあっては、処理過程で発生する別サービス要求メッセージの処理についてもプログラムレベルでの耐障害性を高めるためにシステムの状態に応じた複数の計算ノードの計算機プログラムで並列に処理することができ、また、複数の計算機プログラムの処理結果から多数決などで導出したシステムとしての処理結果を応答メッセージとして処理サービス要求元に返却することにより、計算機プログラムの不具合による計算ミス障害に対する耐障害性を高めることができる。他方、サービス要求に対する処理結果もしくは処理過程で出力される別サービス要求に対する処理結果のうち、応答が早いものを用いて処理を進めることにより、処理遅延障害に対する耐障害性を高めることができる。
【０１２９】
計算ノードに仮想マシンを使用する構成にあっては、耐障害機能を持つ計算機システムを低コストで提供することができる。その理由は、仮想マシンはソフトウェア的にその計算機プログラム実行環境を設定できために実マシンを使う場合のように種々のハードウェアを用意しておく必要がなく、また、仮想マシンは必要時に生成し、不要となれば消去できるためハードウェア資源の効率的な使用が可能になるからである。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態にかかる耐障害計算機システムのブロック図である。
【図２】計算ノードや管理ノードに使用する仮想マシンの説明図である。
【図３】本発明の第１の実施の形態にかかる耐障害計算機システムの処理の流れを示すフローチャートである。
【図４】障害対応処理の一例を示すフローチャートである。
【図５】処理要求処理の一例を示すフローチャートである。
【図６】処理結果処理の一例を示すフローチャートである。
【図７】ジョブ管理部の構成例を示すブロック図である。
【図８】本発明の第２の実施の形態にかかる耐障害計算機システムのブロック図である。
【図９】本発明の第３の実施の形態にかかる耐障害計算機システムのブロック図である。
【図１０】本発明の第４の実施の形態にかかる耐障害計算機システムのブロック図である。
【図１１】本発明の第５の実施の形態にかかる耐障害計算機システムのブロック図である。
【符号の説明】
１…計算ノード
２…管理ノード
３…通信経路
４…計算機プログラム
５…プロセッサ
６…メモリ
７…プログラム実行管理部
８、８’…ジョブ管理部
９、９’…障害管理部
１０…記憶部
１１…仮想マシン
１２…計算機
１３…制御ソフトウェア
１４…仮想マシン実行環境
２０…要求メッセージ送信元
２１…応答メッセージ送信先
３１…情報更新部
３２…要求メッセージ分配条件記憶部
３３…処理判断部
３４…要求メッセージ受信部
３５…要求メッセージ転送先記憶部
３６…要求転送メッセージ生成部
３７…要求転送メッセージ送信部
３８…応答メッセージ生成条件生成部
３９…応答処理判断部
４０…応答メッセージ受信部
４１…応答メッセージ転送先記憶部
４２…応答転送メッセージ生成部
４３…応答転送メッセージ送信部
４４…応答メッセージ保持部
５１…障害検知部
Claims (38)
- それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行する耐障害計算機システム。
- それぞれ異なる計算機プログラム実行環境の下で同一の計算機プログラムを並列に実行する複数の計算ノードと、前記複数の計算ノード毎のプログラム実行状態および計算機プログラム実行環境設定データを記憶する記憶手段と、前記記憶手段に記憶された計算機プログラム実行環境設定データに基づいて各計算ノード毎にその計算ノードの計算機プログラム実行環境の設定を行う実行環境設定手段と、前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を分配する処理要求分配手段と、前記各計算ノードの障害の有無を監視し障害発生時には障害対応処理を実施する障害管理手段と、前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出する処理結果導出手段とを備えることを特徴とする耐障害計算機システム。
- それぞれ異なる計算機プログラム実行環境とは、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類の環境の少なくとも１つの環境が異なることによって、計算機プログラム実行環境間の相違度が所定の相違度以上異なることである請求項２記載の耐障害計算機システム。
- ハードウェア環境が異なるとは、計算機の主記憶容量、仮想記憶容量、メモリアクセスタイミング、プロセッサ速度、バス速度、バス幅、プロセッサ数、リードキャッシュメモリサイズ、ライトキャッシュメモリサイズ、キャッシュの有効・無効状態、プロセッサやメモリの種類のうちの少なくとも１つが異なることである請求項３記載の耐障害計算機システム。
- ソフトウェア環境が異なるとは、ＯＳ、基本ソフトウェア、各種デバイスドライバ、各種ライブラリのうち少なくとも１つの種類やバージョンが異なることである請求項３記載の耐障害計算機システム。
- 外部接続機器環境が異なるとは、外部記憶装置、表示装置、入力装置、通信装置のうち少なくとも１つの種類や仕様が異なることである請求項３記載の耐障害計算機システム。
- プログラム起動環境が異なるとは、計算機プログラムのサスペンド・ツー・ラムによる一時停止と再起動、計算機プログラムのサスペンド・ツー・ディスクによる一時停止と再起動、計算機プログラムのＯＳによる停止と再起動、計算機プログラムとＯＳのシャットダウン処理と再起動、計算機プログラムとＯＳの強制終了と再起動、計算機プログラムの再インストール後の再起動、計算機プログラムとＯＳのクリアインストール後の再起動のうちの異なる再起動方法を用いることである請求項３記載の耐障害計算機システム。
- 前記障害管理手段は、障害にかかる前記計算ノードの計算機プログラム実行環境を変更して前記計算機プログラムを再実行させるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記障害管理手段は、障害にかかる前記計算ノードにおける計算機プログラムの実行状態を変更して前記計算機プログラムを再実行させるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記障害管理手段は、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記処理要求分配手段は、前記障害管理手段によってシステムの状態に応じて更新される分配先情報を記憶する分配先情報記憶部と、処理要求である処理サービスの要求メッセージを受信する要求メッセージ受信部と、前記要求メッセージをシステム内のどの計算ノードで処理するかを前記分配先情報に基づいて判断する処理判断部と、分配先の計算ノードに前記要求メッセージを転送するための要求転送メッセージを生成する要求転送メッセージ生成部と、生成された要求転送メッセージを転送先の計算ノードに転送する要求転送メッセージ送信部とを備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記処理結果導出手段は、応答生成条件および前記障害管理手段によってシステムの状態に応じて更新される分配先情報を含む判断基準情報を記憶する判断基準情報記憶部と、前記処理サービスの応答メッセージおよびデータベースアクセスなどの処理途中の別サービス要求メッセージを前記計算ノードから受信する応答メッセージ受信部と、前記受信した応答メッセージおよび別サービス要求メッセージを一時的に記憶する応答メッセージ保持部と、前記応答メッセージ保持部に保持された応答メッセージおよび別サービス要求メッセージをどのように処理するかを前記判断基準情報に基づいて判断する応答処理判断部と、応答メッセージおよび別サービス要求メッセージをサービス要求元および別サービス要求先に転送するための応答転送メッセージを生成する応答転送メッセージ生成部と、生成された応答転送メッセージをサービス要求元または別サービス要求先である応答メッセージ送信先に転送する応答転送メッセージ送信部とを備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、前記管理ノードの前記ジョブ管理部から指定された自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記実行環境設定手段を備え、前記実行環境設定手段は、自計算ノードの前記記憶手段に記憶された計算機プログラム実行環境設定データを取得して自計算ノードの計算機プログラム実行環境を設定するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記ジョブ管理部に前記処理要求分配手段を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部は、前記管理ノードの前記ジョブ管理部から処理要求の分配を受けるものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記プログラム実行管理部に前記処理要求分配手段を備え、前記複数の計算ノードに備わる複数の処理要求分配手段によって処理要求の分配処理を分散して行うものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記障害管理手段および前記記憶手段を備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記障害管理手段は、障害を検知し障害情報を送信する第１の手段と前記障害検知手段から障害情報を受信しシステム全体として障害を管理する第２の手段とで構成され、前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードに前記第２の手段と前記記憶手段を備え、前記複数の計算ノードのそれぞれに前記第１の手段を備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記管理ノードに前記障害管理手段を備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記管理ノードに前記障害管理手段を備えることを特徴とする請求項３記載の耐障害計算機システム。
- 前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノード毎に前記障害管理手段を備え、前記複数の計算ノードに備わる複数の前記障害管理手段によってシステム全体の障害の管理を分散的に行うものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部および前記記憶手段を備え、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノードからアクセス可能な共有記憶手段として構成され、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記複数の計算ノードと通信経路を通じて接続された管理ノードを備え、前記管理ノードはジョブ管理部を備え、前記記憶手段は、前記管理ノードおよび前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記処理結果導出手段は、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出するものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記記憶手段は、前記複数の計算ノード毎に個別に備えられ、前記複数の計算ノードは前記計算機プログラムの実行を管理するプログラム実行管理部とジョブ管理部を備え、前記ジョブ管理部に前記処理結果導出手段を備え、前記複数の計算ノードの前記プログラム実行管理部から前記処理要求にかかる前記計算機プログラムの処理結果を受け取ってシステムとしての処理結果を導出する処理を、前記複数の計算ノードに備わる複数の前記処理結果導出手段によって分散的に行うものであることを特徴とする請求項３記載の耐障害計算機システム。
- 前記計算ノードに実マシンを用いることを特徴とする請求項１乃至２５の何れか１項に記載の耐障害計算機システム。
- 前記計算ノードに仮想マシンを用いることを特徴とする請求項１乃至２５の何れか１項に記載の耐障害計算機システム。
- それぞれ異なる計算機プログラム実行環境を有する複数の計算ノードで同一の計算機プログラムを並列実行するプログラム並列実行方法。
- 複数の計算ノードを備える計算機システムにおけるプログラム並列実行方法において、
（ａ）複数の計算ノードのそれぞれに、異なる計算機プログラム実行環境を設定するステップ
（ｂ）前記複数の計算ノードで、同一の計算機プログラムを並列実行するステップ
（ｃ）前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を処理させるステップ
（ｄ）前記複数の計算ノードの動作状態を監視し障害を検知したときに障害対応処理を行うステップ
（ｅ）前記複数の計算ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップ
を含むことを特徴とするプログラム並列実行方法。 - それぞれ異なる計算機プログラム実行環境とは、ハードウェア環境、ソフトウェア環境、外部接続機器環境およびプログラム起動環境の４種類の環境の少なくとも１つの環境が異なることによって、計算機プログラム実行環境間の相違度が所定の相違度以上異なることである請求項３３記載のプログラム並列実行方法。
- 前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラム実行環境を変更し、前記計算機プログラムを再実行することを特徴とする請求項３４記載のプログラム並列実行方法。
- 前記ステップｄにおける障害対応処理として、障害にかかる前記計算ノードの計算機プログラムの実行状態を変更し、前記計算機プログラムを再実行することを特徴とする請求項３４記載のプログラム並列実行方法。
- 前記ステップｄにおける障害対応処理として、障害回復をチェックポインティング手法によって行う場合に、用いるチェックポインティングデータを複数の計算ノードでそれぞれ異ならせることを特徴とする請求項３４記載のプログラム並列実行方法。
- 複数の計算ノードを備える計算機システムに、
（ａ）複数の計算ノードのそれぞれに、異なる計算機プログラム実行環境を設定するステップ
（ｂ）前記複数の計算ノードで、同一の計算機プログラムを並列実行するステップ
（ｃ）前記複数の計算ノード上の前記計算機プログラムに同一の処理要求を処理させるステップ
（ｄ）前記複数の計算ノードの動作状態を監視し障害を検知したときに障害対応処理を行うステップ
（ｅ）前記複数の掲載ノード上で並列実行される前記複数の計算機プログラムの前記処理要求に対する処理結果からシステムとしての処理結果を導出するステップ
を実行させるプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003089880A JP4345334B2 (ja) | 2003-03-28 | 2003-03-28 | 耐障害計算機システム、プログラム並列実行方法およびプログラム |
| US10/792,840 US7237140B2 (en) | 2003-03-28 | 2004-03-05 | Fault tolerant multi-node computing system for parallel-running a program under different environments |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003089880A JP4345334B2 (ja) | 2003-03-28 | 2003-03-28 | 耐障害計算機システム、プログラム並列実行方法およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004295738A true JP2004295738A (ja) | 2004-10-21 |
| JP4345334B2 JP4345334B2 (ja) | 2009-10-14 |
Family
ID=33127252
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003089880A Expired - Fee Related JP4345334B2 (ja) | 2003-03-28 | 2003-03-28 | 耐障害計算機システム、プログラム並列実行方法およびプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7237140B2 (ja) |
| JP (1) | JP4345334B2 (ja) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008210164A (ja) * | 2007-02-27 | 2008-09-11 | Fujitsu Ltd | ジョブ管理装置、クラスタシステム、およびジョブ管理プログラム |
| JP2009040199A (ja) * | 2007-08-08 | 2009-02-26 | Mitsubishi Electric Corp | 運行管理用フォルトトレラントシステム |
| JP2009508241A (ja) * | 2005-11-10 | 2009-02-26 | 華為技術有限公司 | 装置管理において、スケジューリング・タスクを処理するための方法およびシステム |
| JP2014102683A (ja) * | 2012-11-20 | 2014-06-05 | Fujitsu Ltd | 情報処理装置の制御プログラム、情報処理装置の制御方法および情報処理装置 |
| JP2018136794A (ja) * | 2017-02-22 | 2018-08-30 | 日本電信電話株式会社 | ルータおよび通信制御方法 |
| JP2020161123A (ja) * | 2019-03-19 | 2020-10-01 | 株式会社クリューシステムズ | 認証方法、そのシステム及び管理サーバ |
| WO2024009499A1 (ja) * | 2022-07-08 | 2024-01-11 | 日立Astemo株式会社 | 車載タスク分割システム及び車載タスク分割方法 |
Families Citing this family (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB0112781D0 (en) * | 2001-05-25 | 2001-07-18 | Global Continuity Plc | Method for rapid recovery from a network file server failure |
| JP4457581B2 (ja) * | 2003-05-28 | 2010-04-28 | 日本電気株式会社 | 耐障害システム、プログラム並列実行方法、耐障害システムの障害検出装置およびプログラム |
| JP4410030B2 (ja) * | 2004-05-26 | 2010-02-03 | テックファーム株式会社 | メールの送信を完了するまでの平均待ち時間を短くすることができるメール配信装置、プログラムおよびメール送信方法 |
| US7580915B2 (en) | 2004-12-14 | 2009-08-25 | Sap Ag | Socket-like communication API for C |
| US7600217B2 (en) * | 2004-12-14 | 2009-10-06 | Sap Ag | Socket-like communication API for Java |
| US7593930B2 (en) * | 2004-12-14 | 2009-09-22 | Sap Ag | Fast channel architecture |
| US7886294B2 (en) * | 2004-12-28 | 2011-02-08 | Sap Ag | Virtual machine monitoring |
| US7562138B2 (en) * | 2004-12-28 | 2009-07-14 | Sap | Shared memory based monitoring for application servers |
| US7552153B2 (en) * | 2004-12-28 | 2009-06-23 | Sap Ag | Virtual machine monitoring using shared memory |
| US7689989B2 (en) | 2004-12-28 | 2010-03-30 | Sap Ag | Thread monitoring using shared memory |
| FR2882448B1 (fr) * | 2005-01-21 | 2007-05-04 | Meiosys Soc Par Actions Simpli | Procede de gestion, de journalisation ou de rejeu du deroulement d'un processus applicatif |
| US20060198386A1 (en) * | 2005-03-01 | 2006-09-07 | Tong Liu | System and method for distributed information handling system cluster active-active master node |
| US7478278B2 (en) * | 2005-04-14 | 2009-01-13 | International Business Machines Corporation | Template based parallel checkpointing in a massively parallel computer system |
| US20060271575A1 (en) * | 2005-05-25 | 2006-11-30 | Harris Steven T | Clustered object state using field set operations |
| JP4839841B2 (ja) * | 2006-01-04 | 2011-12-21 | 株式会社日立製作所 | スナップショット再起動方法 |
| US7941404B2 (en) * | 2006-03-08 | 2011-05-10 | International Business Machines Corporation | Coordinated federated backup of a distributed application environment |
| US8291419B2 (en) * | 2006-09-26 | 2012-10-16 | International Business Machines Corporation | Fault tolerant system for execution of parallel jobs |
| US7647484B2 (en) * | 2007-02-23 | 2010-01-12 | International Business Machines Corporation | Low-impact performance sampling within a massively parallel computer |
| US8359495B2 (en) * | 2007-03-27 | 2013-01-22 | Teradata Us, Inc. | System and method for using failure casting to manage failures in computer systems |
| JP5011191B2 (ja) * | 2007-04-02 | 2012-08-29 | 株式会社日立製作所 | 計算機システム及び通信制御方法 |
| US8484637B2 (en) * | 2007-04-03 | 2013-07-09 | Microsoft Corporation | Parallel installation |
| JP2009223582A (ja) * | 2008-03-14 | 2009-10-01 | Fujitsu Ltd | 情報処理装置、情報処理装置の制御方法および制御プログラム |
| US9146722B2 (en) * | 2008-04-16 | 2015-09-29 | International Business Machines Corporation | Reinstalling a computer based on frequency of application utilization |
| US20100333094A1 (en) * | 2009-06-24 | 2010-12-30 | Mark Restall | Job-processing nodes synchronizing job databases |
| US8132043B2 (en) * | 2009-12-17 | 2012-03-06 | Symantec Corporation | Multistage system recovery framework |
| US8782434B1 (en) | 2010-07-15 | 2014-07-15 | The Research Foundation For The State University Of New York | System and method for validating program execution at run-time |
| US8799378B2 (en) * | 2010-12-17 | 2014-08-05 | Microsoft Corporation | Non-greedy consumption by execution blocks in dataflow networks |
| EP2690557B1 (en) * | 2011-03-23 | 2015-05-13 | Hitachi, Ltd. | Computer system, data processing method, and data processing program |
| US8683170B1 (en) | 2011-09-23 | 2014-03-25 | Netapp, Inc. | Consistent distributed storage communication protocol semantics in a clustered storage system |
| US9203900B2 (en) | 2011-09-23 | 2015-12-01 | Netapp, Inc. | Storage area network attached clustered storage system |
| US9239749B2 (en) * | 2012-05-04 | 2016-01-19 | Paraccel Llc | Network fault detection and reconfiguration |
| DE102012212304A1 (de) * | 2012-07-13 | 2014-01-16 | Siemens Aktiengesellschaft | Anordnung mit einem Mikroprozessorsystem |
| US9122873B2 (en) | 2012-09-14 | 2015-09-01 | The Research Foundation For The State University Of New York | Continuous run-time validation of program execution: a practical approach |
| US9069782B2 (en) | 2012-10-01 | 2015-06-30 | The Research Foundation For The State University Of New York | System and method for security and privacy aware virtual machine checkpointing |
| US10262000B1 (en) * | 2013-06-19 | 2019-04-16 | Emc Corporation | Global distributed file append using log-structured file system |
| IN2013CH05539A (ja) | 2013-12-02 | 2015-06-12 | Infosys Ltd | |
| RU2600538C2 (ru) * | 2014-04-08 | 2016-10-20 | Интел Корпорейшн | Запуск приложения на основе интерфейса передачи сообщения (mpi) в гетерогенной среде |
| US10613886B2 (en) * | 2015-06-30 | 2020-04-07 | Vmware, Inc. | Protecting virtual computing instances |
| WO2018007594A1 (en) * | 2016-07-07 | 2018-01-11 | Universität Zürich | Method and computer program for monitoring touchscreen events of a handheld device |
| CN106844083B (zh) * | 2017-02-20 | 2020-05-12 | 重庆邮电大学 | 一种面向流计算系统异常感知的容错方法及系统 |
| US10671482B2 (en) * | 2017-09-12 | 2020-06-02 | Cohesity, Inc. | Providing consistency in a distributed data store |
| US11403024B2 (en) * | 2019-08-28 | 2022-08-02 | Cohesity, Inc. | Efficient restoration of content |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07141303A (ja) * | 1993-11-16 | 1995-06-02 | Fujitsu Ltd | 並列計算機 |
| JPH08235133A (ja) * | 1995-02-28 | 1996-09-13 | Toshiba Corp | 多重処理システム |
| JPH09212467A (ja) * | 1996-01-30 | 1997-08-15 | Fujitsu Ltd | 負荷分散制御システム |
| JPH09305552A (ja) * | 1996-05-15 | 1997-11-28 | Nec Corp | 負荷均等化装置 |
| JP3072048B2 (ja) * | 1996-03-19 | 2000-07-31 | 株式会社東芝 | 計算機システムおよび計算機システムのソフトウェア故障回復方法 |
| JP3085917B2 (ja) * | 1997-04-10 | 2000-09-11 | 三菱電機株式会社 | 耐ソフトウェア障害構成を有したデータ処理装置 |
| JP2000276454A (ja) * | 1999-03-26 | 2000-10-06 | Hitachi Ltd | ソフトウェアの構成方法 |
| JP2001101149A (ja) * | 1999-09-30 | 2001-04-13 | Nec Corp | 分散並列型データ処理装置及び分散並列型データ処理プログラムを記録した記録媒体並びに分散並列型データ処理システム |
| JP2001202346A (ja) * | 2000-01-19 | 2001-07-27 | Yamaguchi Technology Licensing Organization Ltd | 計算機の分散処理システム |
| JP2002049509A (ja) * | 2000-08-01 | 2002-02-15 | Hitachi Ltd | データ処理システム |
| JP2002259147A (ja) * | 2001-02-27 | 2002-09-13 | Hitachi Ltd | 情報処理装置及びリアルタイム分散処理システム |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5987622A (en) * | 1993-12-10 | 1999-11-16 | Tm Patents, Lp | Parallel computer system including parallel storage subsystem including facility for correction of data in the event of failure of a storage device in parallel storage subsystem |
| US5440726A (en) * | 1994-06-22 | 1995-08-08 | At&T Corp. | Progressive retry method and apparatus having reusable software modules for software failure recovery in multi-process message-passing applications |
| US5712971A (en) * | 1995-12-11 | 1998-01-27 | Ab Initio Software Corporation | Methods and systems for reconstructing the state of a computation |
| US6014669A (en) * | 1997-10-01 | 2000-01-11 | Sun Microsystems, Inc. | Highly-available distributed cluster configuration database |
| US6173420B1 (en) * | 1997-10-31 | 2001-01-09 | Oracle Corporation | Method and apparatus for fail safe configuration |
| GB9800803D0 (en) * | 1998-01-14 | 1998-03-11 | British Telecomm | Communications sytem |
| US6693874B1 (en) * | 1999-05-26 | 2004-02-17 | Siemens Information & Communication Networks, Inc. | System and method for enabling fault tolerant H.323 systems |
| US6651183B1 (en) * | 1999-10-28 | 2003-11-18 | International Business Machines Corporation | Technique for referencing failure information representative of multiple related failures in a distributed computing environment |
| US6745240B1 (en) * | 1999-11-15 | 2004-06-01 | Ncr Corporation | Method and apparatus for configuring massively parallel systems |
| US6823356B1 (en) * | 2000-05-31 | 2004-11-23 | International Business Machines Corporation | Method, system and program products for serializing replicated transactions of a distributed computing environment |
| US6816905B1 (en) * | 2000-11-10 | 2004-11-09 | Galactic Computing Corporation Bvi/Bc | Method and system for providing dynamic hosted service management across disparate accounts/sites |
| US6966010B1 (en) * | 2001-08-31 | 2005-11-15 | Hewlett-Packard Development Company, L.P. | Application container that allows concurrent execution on multiple Nodes in a Cluster |
-
2003
- 2003-03-28 JP JP2003089880A patent/JP4345334B2/ja not_active Expired - Fee Related
-
2004
- 2004-03-05 US US10/792,840 patent/US7237140B2/en not_active Expired - Fee Related
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07141303A (ja) * | 1993-11-16 | 1995-06-02 | Fujitsu Ltd | 並列計算機 |
| JPH08235133A (ja) * | 1995-02-28 | 1996-09-13 | Toshiba Corp | 多重処理システム |
| JPH09212467A (ja) * | 1996-01-30 | 1997-08-15 | Fujitsu Ltd | 負荷分散制御システム |
| JP3072048B2 (ja) * | 1996-03-19 | 2000-07-31 | 株式会社東芝 | 計算機システムおよび計算機システムのソフトウェア故障回復方法 |
| JPH09305552A (ja) * | 1996-05-15 | 1997-11-28 | Nec Corp | 負荷均等化装置 |
| JP3085917B2 (ja) * | 1997-04-10 | 2000-09-11 | 三菱電機株式会社 | 耐ソフトウェア障害構成を有したデータ処理装置 |
| JP2000276454A (ja) * | 1999-03-26 | 2000-10-06 | Hitachi Ltd | ソフトウェアの構成方法 |
| JP2001101149A (ja) * | 1999-09-30 | 2001-04-13 | Nec Corp | 分散並列型データ処理装置及び分散並列型データ処理プログラムを記録した記録媒体並びに分散並列型データ処理システム |
| JP2001202346A (ja) * | 2000-01-19 | 2001-07-27 | Yamaguchi Technology Licensing Organization Ltd | 計算機の分散処理システム |
| JP2002049509A (ja) * | 2000-08-01 | 2002-02-15 | Hitachi Ltd | データ処理システム |
| JP2002259147A (ja) * | 2001-02-27 | 2002-09-13 | Hitachi Ltd | 情報処理装置及びリアルタイム分散処理システム |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009508241A (ja) * | 2005-11-10 | 2009-02-26 | 華為技術有限公司 | 装置管理において、スケジューリング・タスクを処理するための方法およびシステム |
| JP2008210164A (ja) * | 2007-02-27 | 2008-09-11 | Fujitsu Ltd | ジョブ管理装置、クラスタシステム、およびジョブ管理プログラム |
| JP2009040199A (ja) * | 2007-08-08 | 2009-02-26 | Mitsubishi Electric Corp | 運行管理用フォルトトレラントシステム |
| JP2014102683A (ja) * | 2012-11-20 | 2014-06-05 | Fujitsu Ltd | 情報処理装置の制御プログラム、情報処理装置の制御方法および情報処理装置 |
| JP2018136794A (ja) * | 2017-02-22 | 2018-08-30 | 日本電信電話株式会社 | ルータおよび通信制御方法 |
| JP2020161123A (ja) * | 2019-03-19 | 2020-10-01 | 株式会社クリューシステムズ | 認証方法、そのシステム及び管理サーバ |
| WO2024009499A1 (ja) * | 2022-07-08 | 2024-01-11 | 日立Astemo株式会社 | 車載タスク分割システム及び車載タスク分割方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040205377A1 (en) | 2004-10-14 |
| US7237140B2 (en) | 2007-06-26 |
| JP4345334B2 (ja) | 2009-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4345334B2 (ja) | 耐障害計算機システム、プログラム並列実行方法およびプログラム | |
| JP4457581B2 (ja) | 耐障害システム、プログラム並列実行方法、耐障害システムの障害検出装置およびプログラム | |
| US6195760B1 (en) | Method and apparatus for providing failure detection and recovery with predetermined degree of replication for distributed applications in a network | |
| US6266781B1 (en) | Method and apparatus for providing failure detection and recovery with predetermined replication style for distributed applications in a network | |
| US9244771B2 (en) | Fault tolerance and failover using active copy-cat | |
| US7543174B1 (en) | Providing high availability for an application by rapidly provisioning a node and failing over to the node | |
| US9176834B2 (en) | Tolerating failures using concurrency in a cluster | |
| US20080172679A1 (en) | Managing Client-Server Requests/Responses for Failover Memory Managment in High-Availability Systems | |
| CN109656742B (zh) | 一种节点异常处理方法、装置及存储介质 | |
| EP2524302B1 (en) | Persistent application activation and timer notifications | |
| US20070195704A1 (en) | Method of evaluating data processing system health using an I/O device | |
| US10860411B2 (en) | Automatically detecting time-of-fault bugs in cloud systems | |
| CN111736996B (zh) | 一种面向分布式非易失内存系统的进程持久化方法及装置 | |
| JP6124644B2 (ja) | 情報処理装置および情報処理システム | |
| JP3690666B2 (ja) | マルチコンピュータシステム | |
| Wang | Transparent fault tolerance for job healing in HPC environments | |
| Stearley et al. | Investigating an API for resilient exascale computing. | |
| Liu et al. | REM-Rocks: A Runtime Environment Migration Scheme for Rocks based Linux HPC Clusters | |
| Lee et al. | Reliable Software Distributed Shared Memory Using Page Migration | |
| SaurabhJha et al. | Resiliency of HPC Interconnects: A Case Study of Interconnect Failures and Recovery in Blue Waters |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060213 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080729 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090414 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20090514 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20090514 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090601 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090623 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090706 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120724 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120724 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130724 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |