(57)【要約】【課題】計算機が故障した場合、オペレータの介在なしで、予備計算機を故障した計算機の代わりとして使用できるように設定して起動できるようにする。【解決手段】計算機Ｃ１上で動作する故障計算機探索プロセスＦＰは、当該計算機Ｃ１で障害が発生すると、他の計算機、例えば計算機Ｃ２で起動される。プロセスＦＰは、システム内の故障した計算機を探す。プロセスＦＰは故障した計算機を見つけると、計算機Ｃ２で起動されているならば、予備計算機探索部ＰＰ２を用いて予備計算機Ｃ５を探す。プロセスＦＰは、ブートイメージ設定部ＢＳ２を用いてディスク／ブート計算機管理データベースＤＢＤＢの内容を変更することで、故障した計算機で実行されていた、オペレーティングシステムを含むブートイメージを、予備計算機Ｃ５に間接的に設定する。プロセスＦＰは、このブートイメージ設定に従い、予備計算機Ｃ５をブートする。【選択図】    図７
2004334698.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１台の予備計算機を含む複数の計算機を備えた計算機システムにおいて、
故障した計算機を探索する故障計算機探索手段と、
前記故障計算機探索手段により故障した計算機が見つけられた場合、予備計算機を探索する予備計算機探索手段と、
前記予備計算機探索手段により見つけられた予備計算機に、前記故障した計算機で実行されていた、オペレーティングシステムを含むブートイメージを、直接または間接に設定するブートイメージ設定手段と、
前記ブートイメージ設定手段によるブートイメージ設定に従い、前記予備計算機探索手段により見つけられた予備計算機をブートするブート手段と
を具備することを特徴とする計算機システム。
【請求項２】
前記故障計算機探索手段は、前記計算機システム内の稼働状態にあるいずれか１つの計算機で動作する特定プロセスであり、当該プロセスが動作する計算機で障害が発生した場合には、前記予備計算機以外の他の計算機上で動作することを特徴とする請求項１記載の計算機システム。
【請求項３】
前記故障計算機探索手段は、前記計算機システム内の計算機毎に当該計算機が正常に稼働しているか否かを定期的に判定し、正常に稼働していないと判定された計算機が存在する場合には、予め定められた一定時間後に再度当該計算機が正常に稼働しているか否かを判定することにより、当該計算機が故障していないか、或いは故障しているかを判定することを特徴とする請求項２記載の計算機システム。
【請求項４】
前記故障計算機探索手段は、前記計算機システム内の稼働状態にある全ての計算機でそれぞれ別々に動作する特定プロセスであり、当該プロセスが動作する計算機で障害が発生した場合には、前記予備計算機以外の他の計算機上で動作することを特徴とする請求項１記載の計算機システム。
【請求項５】
前記故障計算機探索手段は、自身が前記計算機システム内のいずれの計算機で実行されるべきか認識可能であり、自身が動作すべき計算機で動作しているか否かを判定し、自身が動作すべき計算機で動作していない場合、当該自身が動作すべき計算機は故障していると判定することを特徴とする請求項４記載の計算機システム。
【請求項６】
前記計算機システム内の計算機の障害を検出し、当該障害が検出された計算機で実行されていたサービスを前記予備計算機以外の他の計算機に引き継がせるクラスタ制御手段を更に具備し、
前記クラスタ制御手段は、前記特定プロセスが動作する計算機の障害を検出した場合、当該特定プロセスを前記他の計算機への引き継ぎの対象とすることを特徴とする請求項２または請求項４記載の計算機システム。
【請求項７】
少なくとも１台の予備計算機を含む複数の計算機を備えた計算機システム内の前記計算機で実行される故障計算機代替制御プログラムであって、
前記故障計算機代替制御プログラムが実行される前記計算機を、
故障した計算機を探索する故障計算機探索手段と、
前記故障計算機探索手段により故障した計算機が見つけられた場合、予備計算機を探索する予備計算機探索手段と、
前記予備計算機探索手段により見つけられた予備計算機に、前記故障した計算機で実行されていた、オペレーティングシステムを含むブートイメージを、直接または間接に設定するブートイメージ設定手段と、
前記ブートイメージ設定手段によるブートイメージ設定に従い、前記予備計算機探索手段により見つけられた予備計算機をブートするブート手段
として機能させるための故障計算機代替制御プログラム。
【請求項８】
前記故障計算機探索手段は、前記計算機システム内の稼働状態にあるいずれか１つの計算機で動作する特定プロセスにより実現され、当該プロセスが動作する計算機で障害が発生した場合には、前記予備計算機以外の他の計算機上で動作することを特徴とする請求項７記載の故障計算機代替制御プログラム。
【請求項９】
前記故障計算機探索手段は、前記計算機システム内の稼働状態にある全ての計算機でそれぞれ別々に動作する特定プロセスにより実現され、当該プロセスが動作する計算機で障害が発生した場合には、前記予備計算機以外の他の計算機上で動作することを特徴とする請求項７記載の故障計算機代替制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の計算機で構成される計算機システムに係り、特に、“プロビジョニングノード”と呼ばれる予備の計算機を含み、稼働中の計算機が故障した場合に、その故障した計算機で実行されていたブートイメージを予備の計算機で実行可能とするのに好適な計算機システム及び故障計算機代替制御プログラムに関する。
【０００２】
【従来の技術】
近年、１つの筐体内に数十〜数百もの計算機ノードを含む高密度型の計算機システムが市販されている。このような計算機システムでは、プロビジョニングノード（ｐｒｏｖｉｓｉｏｎｉｎｇ  ｎｏｄｅ）と呼ばれる予備の計算機が含まれることが多い。一般に、予備計算機は通常は使用されず、通常使用している計算機が故障した場合の代替計算機（代替ノード）として使用される。具体的には、故障した計算機で実行されていたオペレーティングシステムを含むブートイメージを、オペレータ操作により予備計算機のブートイメージとして設定し、当該予備計算機を起動することにより、当該予備計算機を故障した計算機の代わりとして使用する。
【０００３】
一方、稼働状態にある計算機で障害が発生した場合に、その障害が発生した計算機で実行されていたサービス（業務）を、システム内の他の計算機、例えば待機状態（ホットスイタンバイ状態）にある他の計算機に引き継がせる（フェイルオーバする）、クラスタシステムと呼ばれる計算機システムが知られている（非特許文献１参照）。
【０００４】
【非特許文献１】
金子哲夫、森良哉、「クラスタソフトウェア」、東芝レビュー、Ｖｏｌ．５４
Ｎｏ．１２（１９９９）、ｐ．１８−２１
【０００５】
【発明が解決しようとする課題】
上記したように、予備計算機（プロビジョニングノード）を含む従来の計算機システムでは、システム内の計算機が故障した場合、予備計算機を故障した計算機の代わりとして使用することができる。しかし、従来の技術では、予備計算機を故障した計算機の代わりとして使用できるように設定して起動するには、オペレータの介在が必要であった。
【０００６】
一方、非特許文献１に記載されたクラスタシステムでは、故障した（障害が発生した）計算機で実行されていたサービスを、システム内の他の計算機に自動的に引き継がせる（フェイルオーバする）ことが可能である。
【０００７】
しかし、このクラスタシステムでは、サービスの引き継ぎ先の計算機は起動（ブート）されている必要がある。このため、クラスタシステムで適用されるサービスを引き継ぐ技術を、予備計算機を故障した計算機の代わりとして使用可能とする仕組みに応用することは困難である。
【０００８】
本発明は上記事情を考慮してなされたものでその目的は、計算機が故障した場合に、オペレータの介在なしで、予備計算機を故障した計算機の代わりとして使用できるように設定して起動することができる計算機システム及び故障計算機代替制御プログラムを提供することにある。
【０００９】
【課題を解決するための手段】
本発明の１つの観点によれば、少なくとも１台の予備計算機を含む複数の計算機を備えた計算機システムが提供される。この計算機システムは、故障した計算機を探索する故障計算機探索手段と、この故障計算機探索手段により故障した計算機が見つけられた場合、予備計算機を探索する予備計算機探索手段と、この予備計算機探索手段により見つけられた予備計算機に、上記故障した計算機で実行されていた、オペレーティングシステムを含むブートイメージを、直接または間接に設定するブートイメージ設定手段と、このブートイメージ設定手段によるブートイメージ設定に従い、上記予備計算機探索手段により見つけられた予備計算機をブートするブート手段とを備えている。
【００１０】
このような構成の計算機システムにおいては、計算機が故障した場合に、オペレータの介在なしで、予備計算機を故障した計算機の代わりとして使用できるようにブートイメージを直接または間接に設定して起動することができる。
【００１１】
ここで、上記故障計算機探索手段を、計算機システム内の稼働状態にあるいずれか１つの計算機で動作する特定プロセスにより実現し、当該プロセスが動作する計算機で障害が発生した場合には、予備計算機以外の他の計算機上で動作する構成とするとよい。このようにすると、上記特定プロセスが動作する計算機で障害が発生しても、当該プロセスの実行を継続でき、故障した計算機を確実に探すことができる。ここでは、故障計算機探索手段により、計算機システム内の計算機毎に当該計算機が正常に稼働しているか否かを定期的に判定し、正常に稼働していないと判定された計算機が存在する場合には、予め定められた一定時間後に再度当該計算機が正常に稼働しているか否かを判定することにより、当該計算機が故障していないか、或いは故障しているかを判定するとよい。
【００１２】
また、上記故障計算機探索手段を、計算機システム内の稼働状態にある全ての計算機でそれぞれ別々に動作する特定プロセスにより実現し、当該プロセスが動作する計算機で障害が発生した場合には、予備計算機以外の他の計算機上で動作する構成としてもよい。ここでは、故障計算機探索手段を、自身が計算機システム内のいずれの計算機で実行されるべきか認識可能とし、当該故障計算機探索手段に次の判定機能を持たせるとよい。この判定機能は、自身が動作すべき計算機で動作しているか否かを判定し、自身が動作すべき計算機で動作していない場合、当該自身が動作すべき計算機は故障していると判定する機能である。
【００１３】
また、特定プロセスが動作する計算機で障害が発生した場合に、当該特定プロセスを予備計算機以外の他の計算機上で動作させるには、計算機システム内の計算機の障害を検出し、当該障害が検出された計算機で実行されていたサービスを予備計算機以外の他の計算機に引き継がせるクラスタ制御手段を設け、特定プロセスが動作する計算機の障害が検出された場合、当該特定プロセスが上記他の計算機への引き継ぎの対象とされる構成とすればよい。
【００１４】
【発明の実施の形態】
以下、本発明の実施の形態につき図面を参照して説明する。
【００１５】
図１は本発明の第１の実施形態に係る計算機システムの構成を示すブロック図である。図１の計算機システムは、５台の計算機Ｃ１〜Ｃ５から構成される。計算機Ｃ１〜Ｃ５はネットワークＮで相互に接続されている。また計算機Ｃ１〜Ｃ５はストレージ・エリア・ネットワーク（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）ＳＡＮに接続されている。このストレージ・エリア・ネットワークＳＡＮには、ストレージ装置ＳＳも接続されている。ストレージ装置ＳＳには、ディスク（ディスク装置）Ｄ１〜Ｄ４が設けられている。つまり、計算機Ｃ１〜Ｃ５とストレージ装置ＳＳ内のディスクＤ１〜Ｄ４とはストレージ・エリア・ネットワークＳＡＮで接続されている。
【００１６】
ディスクＤ１，Ｄ２，Ｄ３，Ｄ４には、それぞれホスト名として“ｈｏｓｔ−１”，“ｈｏｓｔ−２”，“ｈｏｓｔ−３”，“ｈｏｓｔ−４”が割り当てられる計算機のためのブートイメージが予め保存されている。ディスクＤｉ（ｉ＝１〜４）に保存されているブートイメージは“ｈｏｓｔ−ｉ”のブートイメージと呼ばれ、例えばオペレーティングシステムＯＳｉ、及び当該オペレーティングシステムＯＳｉのもとで動作するアプリケーションプログラムを含む。つまりディスクＤｉは、ｈｏｓｔ−ｉ”のブートディスクとして用いられる。
【００１７】
図１には、計算機Ｃ１〜Ｃ５のうちの計算機Ｃ１〜Ｃ４が各々ディスクＤ１〜Ｄ４の内容をブートイメージとして稼動中で、当該計算機Ｃ１〜Ｃ４上でオペレーティングシステムＯＳ１〜ＯＳ４が動作している状態が示されている。これら稼働中の計算機Ｃ１〜Ｃ４は、自身のホスト名を、ディスクＤ１〜Ｄ４のブートイメージ中に記録された“ｈｏｓｔ−１”〜“ｈｏｓｔ−４”と認識しているものとする。一方、計算機Ｃ１〜Ｃ５のうちの計算機Ｃ５は、図１の状態では、プロビジョニングノード（ｐｒｏｖｉｓｉｏｎｉｎｇ  ｎｏｄｅ）と呼ばれる予備計算機として配置されている。つまり計算機Ｃ５には、オペレーティングシステムを含むブートイメージはロードされておらず、当該計算機Ｃ５はブートされていない。なお、予備計算機は１台である必要はなく、複数の予備計算機が配置される構成であっても構わない。
【００１８】
ストレージ装置ＳＳは、ディスク／ブート計算機管理データベースＤＢＤＢを有する。ディスク／ブート計算機管理データベースＤＢＤＢは、ストレージ装置ＳＳ内のディスクＤ１〜Ｄ４と当該ディスクＤ１〜Ｄ４をブートディスクとする計算機（ブート計算機）との対応関係を管理するための管理テーブルを保持する。
【００１９】
稼働中の計算機Ｃ１〜Ｃ４では、それぞれ、予備計算機探索部ＰＰ１〜ＰＰ４、ブートイメージ設定部ＢＳ１〜ＢＳ４、及びブート部ＢＢ１〜ＢＢ４が動作する。予備計算機探索部ＰＰｉ（ｉ＝１〜４）は、予備計算機を探索する機能を有する。予備計算機探索部ＰＰｉは、計算機／ディスク構成管理データベースＣＤＤＢｉを有する。計算機／ディスク構成管理データベースＣＤＤＢｉは、図１の計算機システム内の各計算機Ｃ１〜Ｃ５の状態とディスクＤ１〜Ｄ４との関係を管理するための管理テーブルを保持する。
【００２０】
ブートイメージ設定部ＢＳｉは、故障計算機探索プロセスＦＰからの指示により、ストレージ装置ＳＳ内のディスクＤｉに保存されているブートイメージを、ホスト名として“ｈｏｓｔ−ｉ”が割り当てられる計算機で実行されるように設定（ここでは間接的に設定）する機能を有する。ブート部ＢＢｉは、ブートイメージ設定部ＢＳｉにより設定されたブートイメージによりホスト名として“ｈｏｓｔ−ｉ”が割り当てられる計算機をブートする機能を有する。
【００２１】
稼働中の計算機Ｃ１〜Ｃ４のうちのいずれか１つ、例えば計算機Ｃ１では、故障計算機探索プロセスＦＰが動作する。故障計算機探索プロセスＦＰは、ホスト生存管理データベースＨＤＢを利用して故障計算機を探索する故障計算機探索部として機能する。ホスト生存管理データベースＨＤＢは、“ｈｏｓｔ−ｉ”が割り当てられている計算機が稼働（生存）しているかを管理するためのテーブルを保持する。
【００２２】
計算機Ｃｉ上で動作する、予備計算機探索部ＰＰｉ、ブートイメージ設定部ＢＳｉ及びブート部ＢＢｉは、所定の故障計算機代替制御プログラムを当該計算機Ｃｉ（内の図示せぬＣＰＵ）が読み取って実行することにより実現される。計算機Ｃ１上で動作する故障計算機探索プロセスＦＰも、上記故障計算機代替制御プログラムを当該計算機Ｃ１が読み取って実行することにより実現される。したがって、計算機Ｃ１以外の計算機で故障計算機探索プロセスＦＰが動作することもあり得る。
【００２３】
稼働中の計算機Ｃ１〜Ｃ４ではまた、クラスタ制御部ＣＣ１〜ＣＣ４が動作する。各クラスタ制御部ＣＣ１〜ＣＣ４は、ネットワークＮを介して相互に通信を行うことにより、障害が発生した計算機（障害計算機）を検出する機能を有する。ここでは、各クラスタ制御部ＣＣ１〜ＣＣ４がハードビート信号と呼ばれる信号を相互に且つ定期的に送信し、そのハートビート信号が予め定められた一定時間（タイムアウト時間）を超えて途絶えたことをもって、対応するクラスタ制御部が存在する計算機での障害発生が判断される。クラスタ制御部ＣＣ１〜ＣＣ４は、１つの仮想的なクラスタ制御機構ＣＣを構成する。クラスタ制御機構ＣＣは、検出された障害計算機で実行されていたサービスを他の計算機に引き継がせるための制御を行う機能を有する。本実施形態では、クラスタ制御機構ＣＣにより制御されるサービスの１つとして、故障計算機探索プロセスＦＰが予め定義されている。つまり、故障計算機探索プロセスＦＰは、当該プロセスＦＰが動作している計算機（図１では計算機Ｃ１）が障害等により停止した場合に、他の計算機で起動されるようにクラスタ制御機構ＣＣにより制御される。
【００２４】
クラスタ制御部ＣＣｉは、クラスタ制御用のソフトウェアプログラム（クラスタソフトウェア）を計算機Ｃｉ（内の図示せぬＣＰＵ）が読み取って実行することにより実現される。ここでは、クラスタソフトウェアと故障計算機代替制御プログラムとは、それぞれ独立のプログラムであるものとするが、例えば故障計算機代替制御プログラムに相当するコード情報がクラスタソフトウェアに予め組み込まれている構成とすることも可能である。
【００２５】
図２は、図１中の計算機／ディスク構成管理データベースＣＤＤＢｉ（ｉ＝１〜４）のデータ構造例を示す。図２に示すように、データベースＣＤＤＢｉの各レコードは、計算機、当該計算機のステータス、及びディスクの各情報を設定するための項目を含む。計算機の情報には、計算機の識別子が用いられる。ステータスは、対応する計算機の状態を示し、稼動（Ｓ）、プロビジョニング（Ｐ）、ダウン（Ｄ）またはリザーブ（Ｒ）を表す。ステータスが稼動（Ｓ）の場合、対応するレコード中のディスクの項目には、当該レコード中の計算機識別子で示される計算機の起動に用いられたブートイメージを保存しているディスクの識別子が設定される。
【００２６】
図２の計算機／ディスク構成管理データベースＣＤＤＢｉは、図１の計算機システムの状態を示している。つまり、計算機Ｃ１〜Ｃ４はディスクＤ１〜Ｄ４をブートディスクとして稼働（Ｓ）状態にあり、計算機Ｃ５はプロビジョニング（Ｐ）の状態、つまり予備計算機の状態にある。
【００２７】
図３は、計算機の状態の遷移を示す状態遷移図である。ここでは、上記４つの計算機状態の他に、システムに物理的に組み込まれていない状態（−）が示されている。図３に示すように、本実施形態では、プロビジョニング（Ｐ）の状態にある計算機（予備計算機）は、リザーブ（Ｒ）の状態を経て稼働（Ｓ）の状態に切り替え可能である。
【００２８】
図４は、図１中のディスク／ブート計算機管理データベースＤＢＤＢのデータ構造例を示す。図４に示すように、データベースＤＢＤＢの各レコードは、ブートイメージを保存しているディスク（ブートディスク）の情報（ディスク識別子）、及び当該ディスクをブートディスクとする計算機の情報（計算機識別子）を設定するための項目を含む。
【００２９】
図５は、図１中のホスト生存管理データベースＨＤＢのデータ構造例を示す。図５に示すように、データベースＨＤＢの各レコードは、ホストを示す情報、例えばホスト名、及びカウンタの情報（カウンタ値）を設定するための項目を含む。ここでは、クラスタ制御部ＣＣｉからハートビート信号がタイムアウト時間内に送信される毎に、当該クラスタ制御部ＣＣｉが動作しているホストに対応するカウンタが１インクリメントされる。
【００３０】
次に、図１の計算機システムにおける動作について、故障計算機を検出し、その故障計算機に適用されていたブートイメージを予備計算機に設定して当該予備計算機を起動する動作を例に、図６のフローチャートを参照して説明する。
【００３１】
今、図１の計算機システムでは、計算機Ｃ１〜Ｃ４が、ストレージ装置ＳＳ内のディスクＤ１〜Ｄ４に保存されている、ｈｏｓｔ−１”〜“ｈｏｓｔ−４”のブートイメージに従って稼働（Ｓ）している状態にあるものとする。また、計算機Ｃ５は予備計算機として配置されており、プロビジョニング（Ｒ）の状態にあるものとする。この場合、稼働状態にある計算機Ｃ１〜Ｃ４内の予備計算機探索部ＰＰ１〜ＰＰ４が有する計算機／ディスク構成管理データベースＣＤＤＢ１〜ＣＤＤＢ４の内容は、いずれも図２に示したようになっている。また、ストレージ装置ＳＳ内のディスク／ブート計算機管理データベースＤＢＤＢの内容は、図４に示したようになっている。
【００３２】
図１の計算機システムにおいて、クラスタ制御機構ＣＣ内の各クラスタ制御部ＣＣｉ（ｉ＝１〜４）、即ち各計算機Ｃｉ上で動作しているクラスタ制御部ＣＣｉは、相互にハートビート信号を送受信する。クラスタ制御部ＣＣｉは他のクラスタ制御部ＣＣｊ（ｊ＝１〜４、但しｊ≠ｉ）からタイムアウト時間内にハートビート信号を受信できた場合、ホスト生存管理データベースＨＤＢ内のレコードのうち、クラスタ制御部ＣＣｊが動作しているホストに対応するレコード中のカウンタ（の値）を１インクリメントする。クラスタ制御機構ＣＣは、クラスタ制御部ＣＣｊからのハートビート信号がタイムアウト時間を超えて途絶えた場合、当該クラスタ制御部ＣＣｊが動作している計算機Ｃｊの障害発生を判断する。
【００３３】
ここでは、クラスタ制御機構ＣＣにより障害発生と判断された計算機Ｃｊが、故障計算機探索プロセスＦＰが動作している計算機Ｃ１、即ちホスト名“ｈｏｓｔ−１”が割り当てられている計算機Ｃ１であるものとする。本実施例において、故障計算機探索プロセスＦＰは、当該プロセスＦＰが動作している計算機が障害発生計算機と判断された場合に、他の計算機に引き継ぐべき（フェイルオーバすべき）サービスとして定義されている。また、本実施形態のように故障計算機探索プロセスＦＰが計算機Ｃ１で動作している場合、計算機Ｃ２〜Ｃ４は待機系計算機として位置付けられる。これにより、計算機Ｃ１が障害発生計算機と判断された場合、故障計算機探索プロセスＦＰは計算機Ｃ２〜Ｃ４のいずれかに引き継がれる。ここでは、故障計算機探索プロセスＦＰは、図７に示すように、障害発生計算機Ｃ１から計算機Ｃ２に引き継がれるものとする。以降、故障計算機探索プロセスＦＰは、計算機Ｃ２上で動作する。
【００３４】
さて、ハートビート信号が途絶えた状態が長時間続く場合、つまり上記カウンタが長時間変化しない場合、対応する計算機は予備計算機への切り替えが必要であると判断できる。この判断は、故障計算機探索プロセスＦＰにより次のように行われる。
【００３５】
まず故障計算機探索プロセスＦＰは、起動されると、予め定められた一定時間スリープする（ステップＳ１）。次に故障計算機探索プロセスＦＰは、ホスト生存管理データベースＨＤＢを参照してカウンタが変化していないホストを探す（ステップＳ２）。
【００３６】
もし、カウンタが変化していないホストがないならば、つまり各ホストに対応するカウンタがいずれも変化しているならば、故障計算機探索プロセスＦＰは、故障したホストはないものと判断し、ステップＳ１に戻ってスリープする。以降、故障計算機探索プロセスＦＰは、カウンタが変化していないホストがない限り、ステップＳ１及びＳ２の処理を繰り返す。
【００３７】
これに対し、カウンタが変化していないホストがあるならば、当該ホストが故障したためにハートビート信号が途絶えているのか、当該ホストがリブートされるためにハートビート信号が途絶えているのかを判別するために、故障計算機探索プロセスＦＰはリブートに必要な一定時間スリープする（ステップＳ３）。その後、故障計算機探索プロセスＦＰは、改めてホスト生存管理データベースＨＤＢを参照し、先に、変化していないと判定されたホストのカウンタが依然として変化していないかを判定する（ステップＳ４）。もし、上記カウンタが依然として変化していない場合には、故障計算機探索プロセスＦＰは、対応するホストは生存しておらず、したがって故障したものと判定する。ここでは、ホスト名“ｈｏｓｔ−１”が割り当てられている計算機Ｃ１の故障が判定される。
【００３８】
このとき故障計算機探索プロセスＦＰは、クラスタ制御機構ＣＣによる制御で、計算機Ｃ１ではなくて計算機Ｃ２で動作している。故障計算機探索プロセスＦＰは、計算機Ｃ１の故障を判定した場合、予備計算機探索部ＰＰ２により予備計算機を探させる。もし、予備計算機が見つかった場合、故障計算機探索プロセスＦＰは、故障した計算機Ｃ１が使用していたディスク（Ｄ１）のブートイメージを、予備計算機が使用するように、ストレージ装置ＳＳ内のディスク／ブート計算機管理データベースＤＢＤＢをブートイメージ設定部ＢＳ２により操作させる（ステップＳ５）。
【００３９】
ここで、予備計算機探索部ＰＰ２による予備計算機（プロビジョニングノード）の探索は、計算機／ディスク構成管理データベースＣＤＤＢ２を参照して、ステータスがプロビジョニング（Ｐ）の計算機の識別子を取得することで実現される。計算機／ディスク構成管理データベースＣＤＤＢ２（ＣＤＤＢ１〜ＣＤＤＢ４）が図２のようになっている本実施形態では、計算機Ｃ５が予備計算機として検出される。この場合、予備計算機探索部ＰＰ２は、計算機／ディスク構成管理データベースＣＤＤＢ２を操作して、故障計算機Ｃ１及び予備計算機Ｃ５のステータスを、それぞれ、ダウン（Ｄ）及びリザーブ（Ｒ）に変更する。この予備計算機探索部ＰＰ２の操作内容は他の計算機Ｃ３，Ｃ４の予備計算機探索部ＰＰ３，ＰＰ４が有する計算機／ディスク構成管理データベースＣＤＤＢ３，ＣＤＤＢ４に反映され、当該データベースＣＤＤＢ３，ＣＤＤＢ４の内容が計算機／ディスク構成管理データベースＣＤＤＢ２の内容に一致するように変更される。この計算機／ディスク構成管理データベースＣＤＤＢ２〜ＣＤＤＢ４（ＣＤＤＢｉ）の内容を図９に示す。
【００４０】
一方、ブートイメージ設定部ＢＳ２は、ストレージ装置ＳＳ内のディスク／ブート計算機管理データベースＤＢＤＢを次のように操作する。即ちブートイメージ設定部ＢＳ２は、ディスク／ブート計算機管理データベースＤＢＤＢ中のレコードのうち、故障計算機Ｃ１がブート計算機として設定されているレコード、つまりディスクＤ１の情報と計算機Ｃ１の情報との対が設定されているレコードを対象に、当該ブート計算機の情報（識別子）を故障計算機Ｃ１から予備計算機Ｃ５の情報（識別子）に変更する。つまり、故障計算機Ｃ１で実行されていた“ｈｏｓｔ−１”のブートイメージが、予備計算機Ｃ５に間接的に設定される。このときのディスク／ブート計算機管理データベースＤＢＤＢの内容を図８に示す。
【００４１】
故障計算機探索プロセスＦＰは、ステップＳ５を実行すると、ブート部ＢＢ２により、ディスク／ブート計算機管理データベースＤＢＤＢに従って予備計算機Ｃ５をブートさせる（ステップＳ６）。ここでは、ブート部ＢＢ２は、ディスク／ブート計算機管理データベースＤＢＤＢを参照して、予備計算機Ｃ５の識別子が設定されているレコードを探す。次にブート部ＢＢ２は、探したレコードに設定されているディスクＤ１の識別子に従い、ストレージ装置ＳＳ内のディスクＤ１に保存されている“ｈｏｓｔ−１”のブートイメージで計算機Ｃ５をブートする。これにより故障した計算機Ｃ１が実行していたｈｏｓｔ−１”のブートイメージを、計算機Ｃ５が実行することが可能になる。即ち、計算機Ｃ５が“ｈｏｓｔ−１”として起動され、計算機Ｃ１が故障するまで当該計算機Ｃ１上で動作していた、オペレーティングシステムＯＳ１、予備計算機探索部ＰＰ１、ブートイメージ設定部ＢＳ１、ブート部ＢＢ１、及びクラスタ制御部ＣＣ１が、図１０に示すように当該計算機Ｃ５で動作するようになる。
【００４２】
このように本実施形態では、故障計算機探索プロセスＦＰが障害発生計算機Ｃ１上で動作していても、当該プロセスＦＰが他の計算機（ここでは計算機Ｃ２）に引き継がれるため、当該プロセスＦＰにより計算機Ｃ１の故障が確実に判定できる。また、故障計算機探索プロセスＦＰの制御により、引き継ぎ先の計算機上の予備計算機探索部、ブートイメージ設定部及びブート部（ここでは、予備計算機探索部ＰＰ２、ブートイメージ設定部ＢＳ２及びブート部ＢＢ２）を利用して、予備計算機の探索、故障計算機Ｃ１が使用していたディスク（Ｄ１）のブートイメージを予備計算機が使用可能とするための設定、及び予備計算機のブートの自動化を実現できる。
【００４３】
上記実施形態では、ホストの故障検出に、ハートビート信号をタイムアウト時間内に受信する都度インクリメントされるカウンタを用いている。しかし、タイムアウト時間を経過してもハートビート信号が依然として受信されない時間、つまりタイムアウト時間（第１のタイムアウト時間）からの経過時間を監視し、その経過時間が予め定められた時間（第２のタイムアウト時間）を超えた場合に、対応するホストの故障を判定するようにしてもよい。
【００４４】
［第２の実施形態］
図１１は本発明の第２の実施形態に係る計算機システムの構成を示すブロック図である。図１１において、図１の計算機システムと等価な構成要素には同一符号を付してある。
【００４５】
まず、図１１の計算機システムの構成について、図１の計算機と相異する点を中心に説明する。図１１の計算機システムにおいて、ネットワークＮには、リモート配布（Ｒｅｍｏｔｅ  Ｄｅｐｌｏｙｍｅｎｔ）サーバＲＤＳが接続されている。リモート配布サーバＲＤＳは、ディスクＲ１，Ｒ２，Ｒ３，Ｒ４を備えている。このディスクＲ１，Ｒ２，Ｒ３，Ｒ４には、それぞれ“ｈｏｓｔ−１”，“ｈｏｓｔ−２”，“ｈｏｓｔ−３”，“ｈｏｓｔ−４”のブートイメージが予め保存されている。したがって、ディスクＲ１，Ｒ２，Ｒ３，Ｒ４に保存されているブートイメージで例えば計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４をブートすると、当該計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４のホスト名はそれぞれ“ｈｏｓｔ−１”，“ｈｏｓｔ−２”，“ｈｏｓｔ−３”，“ｈｏｓｔ−４”となる。
【００４６】
計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４，Ｃ５は、それぞれディスク（ローカルディスク）Ｄ１，Ｄ２，Ｄ３，Ｄ４，Ｄ５を備えている。ここでは、ディスクＤ１，Ｄ２，Ｄ３，Ｄ４に、リモート配布サーバＲＤＳのディスクＲ１，Ｒ２，Ｒ３，Ｒ４の内容がコピーされている。そのため、計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４を起動すると、“ｈｏｓｔ−１”，“ｈｏｓｔ−２”，“ｈｏｓｔ−３”，“ｈｏｓｔ−４”が起動する。
【００４７】
次に、図１１の計算機システムにおける動作について、故障計算機を検出し、その故障計算機に適用されていたブートイメージを予備計算機に設定して当該予備計算機を起動する動作を例に、図１２のフローチャートを参照して説明する。
【００４８】
今、計算機Ｃ１〜Ｃ４が、ディスクＤ１〜Ｄ４にコピーされている、ｈｏｓｔ−１”〜“ｈｏｓｔ−４”のブートイメージに従って稼働（Ｓ）している状態にあるものとする。また、計算機Ｃ５は予備計算機として配置されており、プロビジョニング（Ｒ）の状態にあるものとする。更に、計算機Ｃ１上では、故障計算機探索プロセスＦＰが動作しているものとする。故障計算機探索プロセスＦＰは、計算機Ｃ１〜Ｃ４のいずれにも障害が発生しない通常状態では、図６中のステップＳ１，Ｓ２に相当するステップＳ１１，Ｓ１２の処理を繰り返す。
【００４９】
このような状態で、上記第１の実施形態と同様に計算機Ｃ１が故障したものとする。この場合、故障計算機探索プロセスＦＰは、図６中のステップＳ１，Ｓ２，Ｓ３，Ｓ４に相当するステップＳ１１，Ｓ１２，Ｓ１３，Ｓ１４に相当する処理で、計算機Ｃ１の故障を判断する。ここで、故障計算機探索プロセスＦＰは、計算機Ｃ１上のクラスタ制御部ＣＣ１からのハートビート信号がタイムアウト時間を越えて途絶えた結果、クラスタ制御機構ＣＣにより当該計算機Ｃ１の障害発生が検出された段階で、例えば計算機Ｃ２に引き継がれている。
【００５０】
故障計算機探索プロセスＦＰは、計算機Ｃ１の故障を判断すると、予備計算機探索部ＰＰ２により予備計算機を探させる。もし、予備計算機が見つかった場合、故障計算機探索プロセスＦＰは、故障した計算機Ｃ１が使用していた“ｈｏｓｔ−１”のブートイメージを予備計算機が使用するように、リモート配布サーバＲＤＳ内のディスクＲ１に保存されているブートイメージをブートイメージ設定部ＢＳ２により当該予備計算機のローカルディスクにコピーさせる（ステップＳ１５）。ここでは、ディスクＲ１に保存されている“ｈｏｓｔ−１”のブートイメージは、予備計算機Ｃ５のディスクＤ５にコピーされる。つまり、故障計算機Ｃ１で実行されていた“ｈｏｓｔ−１”のブートイメージが、予備計算機Ｃ５に直接設定される。
【００５１】
次に故障計算機探索プロセスＦＰは、ブート部ＢＢ２により、予備計算機Ｃ５のディスクＤ５にコピーされている“ｈｏｓｔ−１”のブートイメージに従って当該計算機Ｃ５をブートさせる（ステップＳ１６）。これにより計算機Ｃ５は“ｈｏｓｔ−１”として起動され、計算機Ｃ１が故障するまで当該計算機Ｃ１上で動作していた、オペレーティングシステムＯＳ１、予備計算機探索部ＰＰ１、ブートイメージ設定部ＢＳ１、ブート部ＢＢ１、及びクラスタ制御部ＣＣ１は、当該計算機Ｃ５で動作するようになる。
【００５２】
［第３の実施形態］
図１３は本発明の第３の実施形態に係る計算機システムの構成を示すブロック図である。図１３において、図１の計算機システムと等価な構成要素には同一符号を付してある。
【００５３】
まず、図１３の計算機システムの構成について、図１の計算機と相異する点を中心に説明する。図１３の計算機システムにおいて、計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４は、ストレージ装置ＳＳ内のディスクＤ１，Ｄ２，Ｄ３，Ｄ４に保存されている“ｈｏｓｔ−１”，“ｈｏｓｔ−２”，“ｈｏｓｔ−３”，“ｈｏｓｔ−４”のブートイメージで稼働（Ｓ）状態にある。この計算機Ｃ１，Ｃ２，Ｃ３，Ｃ４上では、図１中の故障計算機探索プロセスＦＰに相当する故障計算機探索プロセスＦＰ１，ＦＰ２，ＦＰ３，ＦＰ４が並行して動作する。
【００５４】
故障計算機探索プロセスＦＰｉ（ｉ＝１〜４）の特徴は、故障計算機探索プロセスＦＰとは異なって、ホスト名が“ｈｏｓｔ−ｉ”のブートイメージで起動している計算機（ここでは計算機Ｃｉ）で動作するプロセスであり、自身が動作すべき計算機が認識可能な点にある。つまり故障計算機探索プロセスＦＰｉは、自身が動作している計算機に割り当てられているホスト名（自身のホスト名）を、ストレージ装置ＳＳ内のディスクＤｉに保存されているブートイメージ中に記録された“ｈｏｓｔ−ｉ”であると認識している。
【００５５】
故障計算機探索プロセスＦＰｉは、ホスト名の認識機能を利用して、故障検索を探索する。このため故障計算機探索プロセスＦＰｉは、故障計算機探索プロセスＦＰとは異なり、ホスト生存管理データベースＨＤＢを必要としない。
【００５６】
本実施形態では、クラスタ制御機構ＣＣにより制御されるサービスとして、故障計算機探索プロセスＦＰｉが予め定義されている。つまり、故障計算機探索プロセスＦＰｉは、当該プロセスＦＰｉが動作している計算機（図１３では計算機Ｃｉ）が障害等により停止した場合に、他の計算機で起動されるようにクラスタ制御機構ＣＣにより制御される。
【００５７】
次に、図１３の計算機システムにおける動作について、故障計算機探索プロセスＦＰ１が計算機Ｃ１の故障を検出し、その故障計算機Ｃ１に適用されていたブートイメージを予備計算機に設定して当該予備計算機を起動する動作を例に、図１４のフローチャートを参照して説明する。
【００５８】
故障計算機探索プロセスＦＰ１は起動されると、自身が動作すべき計算機、つまりホスト名が“ｈｏｓｔ−１”の計算機Ｃ１で動作しているか否かを判定する（ステップＳ２１）。通常は、故障計算機探索プロセスＦＰ１は、図１３に示したように計算機Ｃ１で動作している。この場合、故障計算機探索プロセスＦＰ１は、次に起動されるまでスリープする（ステップＳ２８）。
【００５９】
今、故障計算機探索プロセスＦＰ１が動作している計算機Ｃ１で障害が発生したものとする。すると、故障計算機探索プロセスＦＰ１の起動場所が、クラスタ制御機構ＣＣの制御により、計算機システム内の他の計算機に移される（フェイルオーバされる）。これにより、故障計算機探索プロセスＦＰ１は、自身が動作すべきホスト名“ｈｏｓｔ−１”の計算機（Ｃ１）とは異なる計算機で動作することになる。ここでは、故障計算機探索プロセスＦＰ１は、ホスト名が“ｈｏｓｔ−２”の計算機Ｃ２で起動されたものとする。
【００６０】
故障計算機探索プロセスＦＰ１は計算機Ｃ２で起動された場合、上記ステップＳ２１において、自身が動作すべきホスト名が“ｈｏｓｔ−１”の計算機（Ｃ１）ではない計算機（ホスト名が“ｈｏｓｔ−２”の計算機Ｃ２）で動作しているものと判断する。すると故障計算機探索プロセスＦＰ１は、元々自身が動いていたホスト名が“ｈｏｓｔ−１”の計算機Ｃ１に障害が発生したことを認識する。この場合、故障計算機探索プロセスＦＰ１は、例えば自身が現在動作している計算機Ｃ２上の予備計算機探索部ＰＰ２を用いて、予備計算機を探す（ステップＳ２２，Ｓ２３）。この予備計算機探索部ＰＰ２による予備計算機の探索は、上記第１の実施形態と同様に、計算機／ディスク構成管理データベースＣＤＤＢ２を参照して、ステータスがプロビジョニング（Ｐ）の計算機の識別子を取得することで実現される。もし、プロビジョニング（Ｐ）の状態にある計算機が存在しない場合には、故障計算機探索プロセスＦＰ１は、一定時間スリープした後（ステップＳ２４）、再び予備計算機を探す（ステップＳ２２，Ｓ２３）。
【００６１】
今、計算機／ディスク構成管理データベースＣＤＤＢ２（ＣＤＤＢｉ）が図２のようになっているものとすると、計算機Ｃ５が予備計算機として検出される。故障計算機探索プロセスＦＰ１は予備計算機（Ｃ５）が見つかった場合、図６中のステップＳ５，Ｓ６に相当する処理（ステップＳ２５，Ｓ２６）を実行する。即ち故障計算機探索プロセスＦＰ１は、故障した計算機Ｃ１が使用していた“ｈｏｓｔ−１”のブートイメージを予備計算機Ｃ５が使用するように、ストレージ装置ＳＳ内のディスク／ブート計算機管理データベースＤＢＤＢを、例えば自身が現在動作している計算機Ｃ２上のブートイメージ設定部ＢＳ２により操作させる（ステップＳ２５）。また故障計算機探索プロセスＦＰ１は、自身が現在動作している計算機Ｃ２上のブート部ＢＢ２により、ディスク／ブート計算機管理データベースＤＢＤＢに従って予備計算機Ｃ５をブートさせる（ステップＳ２６）。これにより、故障した計算機Ｃ１が実行していた“ｈｏｓｔ−１”のブートイメージを、計算機Ｃ５が実行することが可能となり、オペレーティングシステムＯＳ１、予備計算機探索部ＰＰ１、ブートイメージ設定部ＢＳ１、ブート部ＢＢ１、及びクラスタ制御部ＣＣ１が、当該計算機Ｃ５で動作するようになる。
【００６２】
このように、故障した計算機Ｃ１が実行していた“ｈｏｓｔ−１”のブートイメージで予備計算機Ｃ５が起動されると、つまり計算機Ｃ５が“ｈｏｓｔ−１”として起動されると、本来“ｈｏｓｔ−１”の計算機で動作すべき故障計算機探索プロセスＦＰ１は、その起動場所をホスト名が“ｈｏｓｔ−１”の当該計算機Ｃ５に移される（ステップＳ２７）。この故障計算機探索プロセスＦＰ１をホスト名が“ｈｏｓｔ−１”の計算機に移す（戻す）処理（つまりフェイルバック処理）は、クラスタ制御機構ＣＣにより行われる。その後、故障計算機探索プロセスＦＰ１は、次に起動されるまでスリープする（ステップＳ２８）。
【００６３】
上記第３の実施形態では、予備計算機探索部ＰＰ１（ＰＰｉ）、ブートイメージ設定部ＢＳ１（ＢＳｉ）及びブート部ＢＢ１（ＢＢｉ）は故障計算機探索プロセスＦＰ１（ＦＰｉ）から独立している。しかし、予備計算機探索部ＰＰ１（ＰＰｉ）、ブートイメージ設定部ＢＳ１（ＢＳｉ）及びブート部ＢＢ１（ＢＢｉ）が故障計算機探索プロセスＦＰ１（ＦＰｉ）に付随する（含まれる）構成とすることも可能である。この構成では、クラスタ制御機構ＣＣの制御により故障計算機探索プロセスＦＰ１の起動場所が計算機Ｃ１から計算機Ｃ２に移される際に、予備計算機探索部ＰＰ１、ブートイメージ設定部ＢＳ１及びブート部ＢＢ１も計算機Ｃ２に移される。この場合、故障計算機探索プロセスＦＰ１は、図１４のフローチャートの処理を、予備計算機探索部ＰＰ１、ブートイメージ設定部ＢＳ１及びブート部ＢＢ１を用いて実行する。
【００６４】
また、上記第３の実施形態では、計算機Ｃ１の一時的な障害の場合にも、故障計算機探索プロセスＦＰ１が計算機Ｃ２に移されて、計算機Ｃ１で実行されていたブートイメージで予備計算機Ｃ５が起動される可能性がある。そこでクラスタ制御機構ＣＣは、故障計算機探索プロセスＦＰ１（ＦＰ１〜ＦＰ４）に関しては、他のサービスとは異なり、計算機障害の検出に用いられるタイムアウト時間より長いタイムアウト時間を用いて、障害発生計算機から他の計算機への移動制御（フェイルオーバ）を行うとよい。
【００６５】
［第４の実施形態］
図１５は本発明の第４の実施形態に係る計算機システムの構成を示すブロック図である。図１５において、図１１または図１３の計算機システムと等価な構成要素には同一符号を付してある。
【００６６】
図１５の計算機システムが第３の実施形態で適用された図１３の計算機システムに対して相異する点は、第２の実施形態で適用された図１１の計算機システムが、第１の実施形態で適用された図１の計算機システムに対して相異する点に一致する。この図１５の計算機システム内の故障計算機探索プロセスＦＰ１（ＦＰｉ）の処理手順を図１６のフローチャートに示す。図１６から明らかなように、故障計算機探索プロセスＦＰ１（ＦＰｉ）は、第３の実施形態で適用された図１４のフローチャートのステップＳ２１〜Ｓ２８に相当するステップＳ３１〜Ｓ３８を実行する。但し、ステップＳ３７は、図１４中のステップＳ２７と同様に、クラスタ制御機構ＣＣにより実行される。図１４のフローチャートと相異するのは、図１４中のステップＳ２５に相当するステップＳ３５である。つまりステップＳ３５では、図１２中のステップＳ１５と同様に、故障した計算機（Ｃ１）が使用していたブートイメージを予備計算機（Ｃ５）が使用するように、リモート配布サーバＲＤＳ内の対応するディスク（Ｒ１）に保存されているブートイメージを当該予備計算機（Ｃ５）のローカルディスク（Ｄ５）にコピーする処理が行われる。
【００６７】
上記第１乃至第４の実施形態では、あるブートイメージを実行していた計算機が故障した場合に、その計算機の故障検出をトリガとして、当該計算機が実行していたブートイメージで予備計算機を起動するようにしている。この技術を応用して、例えば計算機の負荷が基準値より大きくなったことをトリガとして、当該計算機が実行していたブートイメージで予備計算機を起動する構成とすることも可能である。この場合、故障計算機探索プロセスの引き継ぎは必ずしも必要ない。また、予め定められた時刻の到来をトリガとして、同一計算機を、例えば昼間は第１のオペレーティングシステムを含む第１のブートイメージで起動し、夜間は第２のオペレーティングシステムを含む第２のブートイメージで起動する構成とすることも可能である。この構成は、特に、ブートイメージのコピーを必要としない図１または図１３に示した計算機システムに適する。
【００６８】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【００６９】
【発明の効果】
以上詳述したように本発明によれば、計算機が故障した場合に、オペレータの介在なしで、予備計算機を故障した計算機の代わりとして使用できるようにブートイメージを直接または間接に設定して起動することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係る計算機システムの構成を示すブロック図。
【図２】図１中の計算機／ディスク構成管理データベースＣＤＤＢｉ（ｉ＝１〜４）のデータ構造例を示す図。
【図３】計算機の状態の遷移を示す状態遷移図。
【図４】図１中のディスク／ブート計算機管理データベースＤＢＤＢのデータ構造例を示す図。
【図５】図１中のホスト生存管理データベースＨＤＢのデータ構造例を示す図。
【図６】同第１の実施形態の主として故障計算機探索プロセスＦＰの動作を説明するためのフローチャート。
【図７】同第１の実施形態において故障計算機探索プロセスＦＰが計算機Ｃ１から計算機Ｃ２にフェイルオーバされた状態を示す図。
【図８】図６中のステップＳ５の実行後のディスク／ブート計算機管理データベースＤＢＤＢの内容を示す図。
【図９】図６中のステップＳ５の実行後の計算機／ディスク構成管理データベースＣＤＤＢｉの内容を示す図。
【図１０】故障した計算機Ｃ１が実行していたブートイメージを、計算機Ｃ５が実行することが可能となった状態を示す図。
【図１１】本発明の第２の実施形態に係る計算機システムの構成を示すブロック図。
【図１２】同第２の実施形態の主として故障計算機探索プロセスＦＰの動作を説明するためのフローチャート。
【図１３】本発明の第３の実施形態に係る計算機システムの構成を示すブロック図。
【図１４】同第３の実施形態の主として故障計算機探索プロセスＦＰ１の動作を説明するためのフローチャート。
【図１５】本発明の第４の実施形態に係る計算機システムの構成を示すブロック図。
【図１６】同第４の実施形態の主として故障計算機探索プロセスＦＰ１の動作を説明するためのフローチャート。
【符号の説明】
Ｃ１〜Ｃ５…計算機、Ｎ…ネットワーク、ＳＳ…ストレージ装置、ＳＡＮ…ストレージ・エリア・ネットワーク、Ｄ１〜Ｄ４，Ｒ１〜Ｒ４…ディスク、ＦＰ，ＦＰ１〜ＦＰ４…故障計算機探索プロセス、ＰＰ１〜ＰＰ４…予備計算機探索部、ＢＳ１〜ＢＳ４…ブートイメージ設定部、ＢＢ１〜ＢＢ４…ブート部、ＯＳ１〜ＯＳ４…オペレーティングシステム、ＣＣ…クラスタ制御機構、ＣＣ１〜ＣＣ４…クラスタ制御部、ＣＤＤＢ１〜ＣＤＤＢ４，ＣＤＤＢｉ…計算機／ディスク構成管理データベース、ＤＢＤＢ…ディスク／ブート計算機管理データベース、ＨＤＢ…ホスト生存管理データベース、ＲＤＳ…リモート配布サーバ。
【図１】
2004334698.tif 000003
【図２】
2004334698.tif 000004
【図３】
2004334698.tif 000005
【図４】
2004334698.tif 000006
【図５】
2004334698.tif 000007
【図６】
2004334698.tif 000008
【図７】
2004334698.tif 000009
【図８】
2004334698.tif 000010
【図９】
2004334698.tif 000011
【図１０】
2004334698.tif 000012
【図１１】
2004334698.tif 000013
【図１２】
2004334698.tif 000014
【図１３】
2004334698.tif 000015
【図１４】
2004334698.tif 000016
【図１５】
2004334698.tif 000017
【図１６】
2004334698.tif 000018