(57)【要約】【課題】必要なシステム性能を確保しながら、最短の時間でかつ高い信頼性を保ちながらプログラム修正作業を可能とする。【解決手段】ネットワークに接続された、複数のノード、及びこれらのノードを管理する管理ホストを有して構成されるクラスタシステムにおいて、各ノード上で動作するプログラムを修正する際に、ノードのサービスを停止する必要がある場合、管理ホストは、システムの負荷を監視する監視手段によりシステムの負荷及び各ノードの処理能力を考慮しながら、各ノードにおけるプログラム修正の進行を制御する。【選択図】  図１
2005043941.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続された、複数のノードと、該ノードを管理する管理ホストを有して構成されるクラスタシステムにおいて、各ノード上で動作するプログラムを修正する際に、ノードのサービスを停止する必要がある場合、該管理ホストは、システムの負荷を監視する監視手段によりシステムの負荷及び各ノードの処理能力を考慮しながら、各ノードにおけるプログラム修正の進行を制御することを特徴とするクラスタシステム。
【請求項２】
プログラム修正作業中に、ノードが既定の時間を過ぎてもサービスを再開しなかった場合、残りのノードに対するプログラム修正作業を中止することを特徴とする請求項１記載のクラスタシステム。
【請求項３】
プログラム修正作業時に、修正前のバージョンのプログラムを記憶装置に保存しておき、
ノード上のプログラム修正作業中の障害により、プログラム修正作業を中止した場合、プログラム修正作業の対象となったノードに対し、バージョン指定手段を用いて修正前のバージョンのプログラムを実行することを指定した上で、リセット手段により該ノードをリセットすることを特徴とする請求項１又は２記載のクラスタシステム。
【請求項４】
プログラム修正作業時に、管理ホストがプログラム修正を開始するノード数を決定する際に、修正作業の始めの方ではリセット指示を行うノード数を少なくしておき、その後、プログラム修正後サービスを正常に再開できたノード数が増加するに従い、プログラム修正を開始するノードの数を増加させることを特徴とする請求項２又は３記載のクラスタシステム。
【請求項５】
ノード上で実行されるプログラムを該ノードと異なる計算機上に置き、該ノードはネットワーク経由でプログラムを取得し、実行することを特徴とする請求項１乃至４のいずれかの項記載のクラスタシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はクラスタシステムに係り、特に複数の計算機をネットワークで結合することにより単独の計算機よりも高い性能や可用性を得ることを目的としたクラスタシステムにおけるソフトウェア管理機能に関するものである。
【０００２】
【従来の技術】
クラスタシステムは、その価格性能比の高さや拡張の容易さから、Ｗｅｂサーバや科学技術計算など多くの用途に使われ、またその規模も年々大きくなっている。それに伴い、システムの信頼性向上や管理コストの削減もますます重視されるようになっている。
【０００３】
最近では、数百台から数千台といった非常に多数の計算機からなるクラスタシステムも運用されている。このような大規模なクラスタシステムでは、ソフトウェア管理に要する工数が非常に大きくなる。
特に、オペレーティングシステムにおけるセキュリティパッチ適用のようなプログラム修正の際に、計算機をリセットすることがあり、サービスの停止を伴う場合もある。このような場合、システムの可用性の低下が問題となる。
【０００４】
上記問題へ対処する方法として、例えば特開２００３−１５８９４号公報には、クラスタシステム中の各計算機のオペレーティングシステムにパッチを適用する際、システムの過去の負荷状況を考慮し、平均的に負荷が低い時間帯に作業をスケジューリングし、かつ同一クラスタ内の計算機に対するパッチ適用作業が重複しないようにすることで、クラスタ全体としてサービスを停止させることなく、パッチを適用する方法が述べられている。
【特許文献１】
特開２００３−１５８９４号公報
【０００５】
【発明が解決しようとする課題】
上記従来技術では、プログラム修正作業全体にかかる時間について配慮がされておらず、クラスタシステムが非常に多数の計算機から構成される場合、プログラム修正作業にかかる時間が膨大になってしまうという問題があった。例えば１０００台の計算機から構成されるクラスタにおいて、１台ずつ逐次的にパッチを適用していった場合、１台あたり１０分かかると仮定すると、全計算機にパッチを適用するなには１週間程度の時間がかかってしまう。
また、従来技術では修正後のプログラムの不具合に起因する障害によるシステムダウンについては考慮されていなかった。
【０００６】
本発明の目的は、システムの性能低下を防止し、短時間で安全にクラスタシステム上のプログラムの修正作業を行うことを可能にすることにある。
【０００７】
【課題を解決するための手段】
上記目的を達成するために、本発明は、クラスタシステムの現在の負荷と、システムを構成する各計算機（ノードと言う）の処理能力を考慮して、プログラム修正作業を行うように構成する。
また、プログラム修正の安全性を向上させるために、プログラム修正後のノードの状態を監視し、プログラム修正後のノードが正常にサービスを再開できない場合には、残りのノードを対象としたプログラム修正を中止し、既にプログラム修正を行ったノードについては、修正前のバージョンをロードし直し、修正前の状態を復旧するように構成するものである。
本発明はまた、プログラム修正作業時に、管理ホストが一度にプログラム修正を開始するノード数を決定する際に、修正作業の始めの方ではリセット指示を行うノード数を少なくしておき、その後、プログラム修正後サービスを正常に再開できたノード数が増加するに従い、プログラム修正を開始するノードの数を増加させるように構成する。これにより、もし修正後のプログラムの不具合に起因する障害が発生した場合にも、その影響を低減することができる。
また、ノード上で実行されるプログラムをノードと異なる計算機上に置き、ノードはネットワーク経由でプログラムを取得し、実行するようにする。
【０００８】
【発明の実施の形態】
図１は本発明の一実施例が適用されるＷｅｂサービスシステムの構成を示す図である。
【０００９】
このシステムは、インターネット１にルータ２を介して接続されたロードバランサ３、およびこのロードバランサ３にネットワーク６を介して接続されたＷｅｂサーバ群１０、同じくネットワーク６に接続された管理ホスト８を有して形成される。
管理ホスト８は、ＯＳパッチ処理制御プログラム９及びノード状態テーブル１０１を備えると共に、ＯＳ修正プログラム５を格納する外部記憶装置４を具備する。
また、Ｗｅｂサーバ群１０は、異なる処理能力を有する複数の計算機（ノードと言う）１１〜１４、及び各ノードに対応して外部記憶装置１８、２１〜２３を有する。代表例として、ノード１４及び記憶装置１８の構成を図示している。
【００１０】
ロードバランサ３は、インターネット１およびルータ２を介して受け取ったリクエストを、適当な負荷分散アルゴリズム、例えばラウンドロビンに従い、いずれかのノード１１〜１４に転送する。リクエストを転送されたノードはリクエストに対応するページをリクエスト元に送信する。
ロードバランサは負荷監視ユニット７を備える。負荷監視ユニット７は、単位時間あたりのリクエスト件数で表されるシステム負荷をリアルタイムで計測する。計測されたシステム負荷は、ネットワーク６を介して管理ホスト９から参照できる。
【００１１】
各ノード１１〜１４は、サービスプロセッサ１６を備える。サービスプロセッサ１６は、ネットワーク６を介して受領した指示によりノードをリセットできる。また、サービスプロセッサ１６は、ＣＰＵと共有される不揮発性メモリ領域に格納された復旧フラグ１７にアクセス可能である。各ノードに対応して備えられた記憶装置１８には、現用ＯＳ１９及び旧ＯＳ２０が格納される。
【００１２】
図２は、図１のシステムのノード状態テーブル１０１を示す。
このノード状態テーブル１０１には、各ノードの処理能力、監視待機時間、状態が記録される。
ノードの処理能力は、ノードが単位時間あたりに処理可能なリクエスト数で表わされる。各ノードの処理能力は、システム構築時あるいはそのノードをシステムに追加した時に計測され、ノード状態テーブルに記録される。
監視待機時間は、管理ホスト９に対しパッチ適用作業を開始してからサービスを再開するまでに要する時間である。監視待機時間の値は、システム構築時あるいは当該ノードをシステムに追加した時に計測、記録される。
状態はノードに対するパッチ適用作業の進行状況を示し、「未適用」、「適用中」、「完了」、「失敗」、「復旧」および「非対象」のいずれかの値をとる。
【００１３】
本実施例によれば、このシステムにおいて、ノード上で実行されるＯＳへセキュリティパッチなどの修正プログラム（パッチ）を適用できる。
【００１４】
以下、修正プログラムの適用処理の詳細について説明する。
パッチ適用処理は、オペレータが、パッチ適用対象となる一つ又は複数のノードを指定して、管理ホスト９上でＯＳパッチ処理制御プログラム８を起動することにより開始される。
オペレータにより起動されたＯＳパッチ処理制御プログラム８は、制御タスクを生成する。
【００１５】
図３に制御タスクの処理フローを示す。
生成された制御タスクはノード状態テーブル１０１の初期化を行う（２０１）。制御タスクは、オペレータから指示されたパッチ適用対象のノードに対して、状態を「未適用」に設定する。また、パッチ適用対象以外のノードについては、状態を「非対象」に設定する。
【００１６】
次に、制御タスクはノード状態テーブル１０１を参照し、状態が「未適用」であるノードが存在するかチェックする（２０２）。「未適用」ノードが存在しなければ、後述するパッチ処理監視タスクのウェイト処理（２０９）に進む。
一方、状態が「未適用」であるノードが存在した場合、制御タスクは、システムの余剰処理能力を求める（２０３）。制御タスクは負荷監視ユニットからシステム負荷Ｌを取得する。
【００１７】
次に、制御タスクは、ノード状態テーブル１０１の処理能力の値を全ノードについて合計して得られるシステムの総処理能力Ｃを求める。総処理能力Ｃとシステム負荷Ｌの差Ｄがシステムの余剰処理能力である。
システム負荷Ｌを求める際には、現在の負荷実測値をそのまま使用してもよいが、過去のシステム負荷から将来のシステム負荷を予測する手段を用いてもよい。例えば、負荷計測ユニットが計測した、１０分前、現在のそれぞれの時刻のシステム負荷Ｗ０、Ｗ１より、最近１０分間の平均負荷変化率  Ｗｄ＝（Ｗ１−Ｗ０）／１０を求め、次の１０分間の平均負荷の予測値として、Ｌ＝Ｗ１＋Ｗｄ×  ５  を採用するという方法が考えられる。
【００１８】
次に、制御タスクは上記で述べた余剰処理能力Ｄに基づき、パッチ適用対象ノードｉを選択する（２０４）。制御タスクはノード状態テーブル１０１を参照し、処理能力がＤ以下で、かつ状態が「未適用」のノードのうち処理能力が最小のものを１つ選択する。このノードをノードｉとする。条件に該当するノードが無ければ、２０３に戻り、再びシステムの余剰処理能力の取得を行う。余剰処理能力は、システム負荷によって変化するので、後でシステム負荷が小さくなり、余剰処理能力が十分大きくなれば、パッチ適用対象ノードが選択される。
【００１９】
ノードの選択が成功した場合、制御タスクは、ノードｉの状態を「適用中」に変更する（２０５）。そして、ネットワーク６を介してノードｉへＯＳ修正プログラム５を転送し、転送が完了すると、ノードｉに対してパッチ適用を指示する（２０６）。尚、パッチ適用の指示を受けたノード側の処理については後述する。
パッチ適用支持が終わると、次に制御タスクは、ノードｉのパッチ処理が正常に行われるかどうかを監視するパッチ処理監視タスクを生成する（２０８）。尚、パッチ処理監視タスクの動作については後述する。
【００２０】
パッチ処理監視タスクを生成した後、制御タスクはパッチ適用のリスクを低下させるためのウェイトを行う（２１１）。制御タスクはノード状態テーブルを参照し、以下の条件が成り立つ間待機する。
「適用中」のノード数  ＞  「完了」のノード数
これにより、パッチの適用が完了して、正常動作が確認されたノードが増えるほど、即ちパッチの安全性が確認されるほど、一度にパッチ適用作業が行うノード数が増加することになる。
【００２１】
制御タスクは、以上で示した処理（２０１〜２１１）を、状態が「未適用」のノードが存在する限り繰り返す。状態が未適用のノードがなくなると、ステップ２０８で生成されたパッチ処理監視タスクがすべて終了するまで待機し（２０９）、それが終わると終了する。
【００２２】
尚、制御タスクはパッチ処理監視タスクからパッチ失敗シグナル（４０７）を受け取る場合がある。その場合、制御タスクはパッチ復旧タスクを生成し（２１０）、制御タスク自身は終了する。
【００２３】
次に図６を参照して、制御プログラムからパッチ適用の指示を受けたノード側の動作について述べる。
図６に示すように、パッチ適用の指示を受けた、例えばノード１４はサービスを停止する（５０１）。そして停止した当該ノード１４は、外部記憶装置１８に格納されてる現用ＯＳ１９を旧ＯＳ領域２０にコピーし、保存する（５０２）。当該ノード１４は、管理ホスト９から転送されたＯＳ修正パッチ８を実行し、現用ＯＳにパッチを適用する（５０３）。そしてノード１４は、復旧フラグ１７をリセットした後、必要ならばノード１４をリセットする（５０５）。ＯＳ修正プログラム５の適用に伴い、ノード１４のリセットが必要でなければ、ノード１４をリセットせずにサービスを再開する（５０６）。
【００２４】
リセットしたノードは、図７に示した手順でブート処理を行う。当該ノード１４は復旧フラグの状態を取得し（６０１）、復旧フラグがリセットされていた場合は、現用ＯＳ領域からＯＳをロードし（６０４）、ロードされたＯＳを実行開始する（６０５）。復旧フラグがセットされていた場合、旧ＯＳ領域２０から現用ＯＳ領域１９にＯＳをコピーし（６０２）、復旧フラグをリセットし（６０３）、現用ＯＳ領域からメモリ上にＯＳをロードし（６０４）、ＯＳの実行を開始する（６０５）。
【００２５】
次に、パッチ処理監視タスクの処理について述べる。
前述したように、この監視タスクは制御プログラム９によって生成される（２０８）。図５に、監視タスクの処理フローを示す。
最初に監視タスクは、ノード状態テーブル１０１に記録された監視対象ノードの監視待機時間だけ待つ（４０５）。これは、当該ノードに、パッチ適用処理、その後のリブート、サービスの再開に要する時間を与えるためである。
【００２６】
監視待機時間が経過すると、監視タスクは当該ノードに対し、テストページの送信を要求する（４０１）。当該ノードがそのリクエストに応え、監視タスクが正常にテストページを取得できた場合、監視タスクは当該ノードの状態を「完了」に変更し（４０４）、終了する。テストページの取得に失敗した場合は、当該ノードの状態を「失敗」に変更し（４０３）、パッチ失敗シグナル（４０７）を制御タスクに送信してから（４０６）、終了する。
【００２７】
次に、復旧タスクの処理について述べる。
前述したように、復旧タスクは、監視タスクからパッチ失敗シグナルを受信した制御タスクによって生成される（図２のステップ２１０）。
【００２８】
図４に、復旧タスクの処理フローを示す。
復旧タスクは、ノード状態テーブルを参照し、復旧の対象となるノードを探す（３０１）。状態が「失敗」または「適用中」のノードが復旧対象のノードである。該当するノードが無かった場合、復旧タスクは終了する。
【００２９】
一方、復旧対象のノードが存在した場合、復旧タスクは、例えば当該ノード１４の復旧フラグをセットし（３０２）、ノード１４の状態を「復旧」に変更し（３０３）、ノード１４をリセットする（３０４）。復旧フラグのセットおよびノード１４のリセットは、サービスプロセッサ１６を介して行う。サービスプロセッサ１６はノードのＣＰＵと独立して動作可能なため、パッチ適用後のＯＳによる不具合により、ノード上でＯＳが動作していない場合でもノードの再起動が可能である。
復旧タスクは、上記処理（３０２〜３０４）を復旧対象ノードが存在する間繰り返し、復旧対象ノードがなくなったら終了する。
【００３０】
前述したように、復旧タスクによってリセットされたノードは、当該ノードの復旧フラグがセットされていることを検出し、パッチ適用前のＯＳをロードしてブートする。これにより、当該ノードは、パッチ適用後のＯＳに不具合があった場合の障害から回復することができる。
【００３１】
上記実施例では、修正の対象となるプログラムはＯＳであるが、修正対象のプログラムはＯＳには限らない。修正時にサービスの停止をともなうサーバアプリケーションへの適用も可能であり、また効果的である。
【００３２】
図８は、第２の実施例によるＷｅｂサービスシステムの構成を示す図である。この実施例は、上記第１の実施例において説明したＯＳの修正ではなくて、各ノードの不揮発性記憶８１８に置かれたファームウェア（以下Ｆ／Ｗと言う）を修正の対象とする例である。
【００３３】
Ｆ／Ｗの更新作業は、オペレータが、パッチ処理対象ノードを指定してＦ／Ｗパッチ処理制御プログラム８１２を起動することにより開始される。オペレータによって起動されたＦ／Ｗパッチ処理制御プログラム８１２は、上記第１の実施例と同様に制御タスクを生成する。
制御タスクによるＦ／Ｗ修正プログラム８１１のノードへの配布、監視タスクの生成、復旧タスクの生成に関しては、第１の実施例のＯＳがＦ／Ｗに代わるだけで、基本的には第１実施例と同様に行われる。監視タスク、復旧タスク、ノード側のパッチ適用処理、ノードのブート処理も、ＯＳがＦ／Ｗに代わるだけで処理手順は第１の実施例と同様である。尚、図８には図１と異なる符号が付してあるが、上記Ｆ／Ｗの修正以外は、図１の符号のものと同様であると理解されよう。
【００３４】
図９は、第３の実施例によるシステムの構成を示す図である。
この実施例に示すシステムは、クラスタ管理ホスト９０４、計算ノード群（９１１〜９１４、以下ノード）、ファイルサーバ９２０から構成される科学技術計算用クラスタシステムの例である。
この実施例では、ノードと独立したファイルサーバ９２０に置かれたＯＳをパッチ適用の対象としている。
【００３５】
管理ホスト９０４およびノード上では、分散オペレーティングシステム（以下ＯＳ）が動作している。管理ホスト上のジョブ制御手段９０５により、各ノード上で実行されるジョブのスケジューリングが行われる。負荷計測手段９０６は、各ノードの負荷を監視し、全ノードの負荷の総和がシステム全体の負荷として求められる。ノード上で実行されるＯＳは、ノードと別個の計算機であるファイルサーバ９２０の外部記憶装置９２２に保持される。そのＯＳはファイルサーバ９２０からネットワーク９１０を介してノード９１１〜９１４へ転送され、そこで実行される。ファイルサーバ９２０の外部記憶装置９２２には、複数のバージョンのＯＳ９２３，９２４が格納されている。ファイルサーバ９２０はＯＳ選択手段９２１を備え、各ノードにどのバージョンのＯＳを転送するかを選択する。
【００３６】
各ノードは、遠隔リセット手段９１６を備える。遠隔リセット手段９１６により、管理ホスト９０４は、各ノードのＣＰＵ９１８の状態に関係なく、ネットワーク９１０を介して対象とするノードをリセットすることができる。
【００３７】
ＯＳの修正作業に必要な情報は、ノード状態テーブル（Ａ０１）によって管理される。
図１０にノード状態テーブルＡ０１の詳細を示す。
ノード状態テーブルＡ０１には、各ノードの、処理能力、監視待機時間、状態、現ＯＳバージョンおよび前ＯＳバージョンが登録される。
【００３８】
各ノードの処理能力は、当該ノードが単位時間あたりに実行可能な処理量である。処理能力は、システム構築時、あるいはノードをシステムに追加した時に計測して、登録される。監視待機時間は、ノードのＯＳ修正に要する時間である。状態は当該ノードに対するＯＳ修正作業の進捗状況に応じて、「未適用」、「適用中」、「完了」、「失敗」、「非対象」のいずれかの値をとる。現ＯＳバージョンおよび前ＯＳバージョンは、それぞれ、ノードが現在実行しているＯＳのバージョン番号と現在のＯＳを使う直前に実行していたＯＳのバージョン番号を値としてとる。ＯＳのバージョン番号については後で詳しく述べる。
【００３９】
ＯＳの修正作業は、オペレータが修正対象ノードを引数として、ＯＳ修正制御プログラム９０３を起動することによって開始される。修正対象ノードの現ＯＳバージョンはすべて同じ値でなければならない。
起動されたＯＳ修正制御プログラム９０３は、パッチ制御タスク（以下制御タスクと言う）を生成する。制御タスクの処理フローを図１１に示す。
【００４０】
制御タスクは、最初にノード状態テーブルの初期化を行う（Ｂ０１）。制御タスクは、オペレータから与えられたＯＳ修正対象ノードについて、状態を「未適用」に設定し、それ以外のノードについては状態を「非対象」にする。また、ＯＳ修正対象ノードについては、ノード制御テーブルの現ＯＳバージョンの値を前ＯＳバージョンにコピーする。
【００４１】
次に制御タスクは、ファイルサーバ９２０に備えられたＯＳのうち、ＯＳ修正対象のノードの現ＯＳバージョンに一致するＯＳをコピーし、そのコピーにＯＳパッチ９０９を適用し、新しいバージョンのＯＳを作成する。新しいバージョンのＯＳには既存のＯＳと異なるバージョン番号を与える。
【００４２】
次に制御タスクは、ノード状態テーブルＡ０１を参照し、状態が「未適用」のノードが存在するかチェックする（Ｂ１２）。該当するノードが存在しなかった場合の処理については後述する。
一方、「未適用」ノードが存在する場合、制御タスクはシステムの余剰処理能力を求める（Ｂ０３）。余剰処理能力は、ノード状態テーブルの各ノードの処理能力の総和とシステムの現在の負荷の差として求められる。尚、第１の実施例で述べたように、過去のシステム負荷から直近のシステム負荷を予測する方法も考えられる。
【００４３】
次に管理タスクは、ノード状態テーブルＡ０１を参照し、余剰処理能力よりも処理能力の小さい、状態が「未適用」のノードのうち、処理能力が最小のものを選択する（Ｂ０４）。該当するノードが無かった場合は、Ｂ０３に戻り、余剰処理能力を再び求める。余剰処理能力は、システムの負荷に応じて時々刻々変化するので、ある時間の後には条件を満たすノードを選択することができる。
管理タスクは、上で選択されたノードの状態を「適用中」に変更し（Ｂ０５）、更に、ノード状態テーブルの当該ノードの現ＯＳバージョンの値を前述した新しいバージョン番号に変更する（Ｂ０６）。そして、当該ノードにネットワーク経由でリセットを指示した後（Ｂ１１）、当該ノードの監視タスクを生成する（Ｂ０７）。
【００４４】
次に管理タスクは、第１実施例と同様、ＯＳ更新のリスクを低減するためのウェイトを行う（Ｂ０８）。制御タスクはノード状態テーブルを参照し、以下の条件が成り立つ間待機する。
「適用中」のノード数  ＞  「完了」のノード数
管理タスクは、上記の処理（Ｂ１２〜Ｂ０８）を、状態が「未適用」のノードが存在しなくなるまで繰り返す。
【００４５】
状態が「未適用」のノードが存在しなくなると、管理タスクは、すべてのノード監視タスクが終了するまで待機する（Ｂ０９）。すべての監視タスクが終了したら、制御タスクも終了する。最初のチェック（２０２）で「未適用」のノードが存在しない場合は、監視タスクは生成されないので、制御タスクは直ちに終了する。
制御タスクは、パッチ失敗シグナル（４０７）を受信することがある。パッチ失敗シグナルを受信した場合、制御タスクは復旧タスクを生成し（Ｂ１０）、制御タスク自身は終了する。
【００４６】
監視タスクの処理フローは、第１の実施例と同様である（図５参照）。監視タスクは、当該ノードの監視待機時間だけウェイトした後、監視対象ノードにテストページを要求する。テストページ取得に成功したら、当該ノードの状態を「完了」に変更し、失敗したら、当該ノードの状態を「失敗」に変更し、パッチ失敗シグナル（４０７）を制御タスクに送信してから終了する。
【００４７】
次に、復旧タスクの処理フローについて述べる。
復旧タスクの処理フローを図１３に示す。
生成された復旧タスクは、ノード状態テーブルを参照し、状態が「失敗」あるいは「適用中」のノードを１つ選択する（Ｄ０１）。選択したノードについて、現ＯＳバージョンを前ＯＳバージョンの値に変更する（Ｄ０２）。そして当該ノードの状態を「復旧」に変更し（Ｄ０３）、当該ノードをリセットする（Ｄ０４）。
リセットは、遠隔リセット手段９１６に対してネットワーク９１０経由でリセット要求を送ることによって行う。遠隔リセット手段９１６は当該ノードのＯＳがハングしていた場合でも当該ノードをリセットすることができる。
【００４８】
次に、ノードのブート処理について述べる。
図１２はノードのブート処理フローである。
リセットされたノードは、ＯＳのロードおよび実行に必要なハードウェアの初期化などを行った後（Ｃ０１）、ファイルサーバに対し当該ノード用のＯＳの転送を要求する。要求を受けたファイルサーバは、ノード状態テーブルを参照し、当該ノードの現ＯＳバージョンに一致するＯＳを当該ノードに転送する。当該ノードは転送されたＯＳをメモリ上にロードし、実行開始し（Ｃ０３）、サービスを再開する。
【００４９】
このように、上記実施例よれば、必要なシステム性能を維持しながら、最小限の時間でプログラム修正作業を完了できる。また、クラスタシステムにおけるプログラム修正作業時に、修正後のプログラムが持つ不具合に起因する障害が発生した場合でも、自動的な復旧を行うことができる。
【００５０】
特許請求の範囲に記載された以外の、主な態様について以下に記載する。
（６）、（１）に関し、管理ホストは、各ノードの状態を管理するノード状態テーブルを有し、該テーブルには、ノードが単位時間当りに処理可能なリクエスト数を表す処理能力、パッチ適用作業を開始してからサービスを再開するまでに要する時間を表す監視待機時間、及びノードに対するパッチ適用作業の進行状態を表す情報、を格納すること。
（７）、（１）に関し、監視手段は、上記（６）の該テーブルに登録されている処理能力に基いてシステムの余剰処理能力を算出すること。
（８）、（７）に関し、ノード状態テーブルを参照してパッチ適用作業の進行状態が「未適用」を示すノードのうち、算出された余剰処理能力が最小のノードを選択し、そのノードに対してパッチの適用を指示すること。
（９）、（１）又は（２）に関し、ノードにおけるパッチ適用処理において、パッチの適用を受けたノードはサービスを停止し、現用ＯＳを旧ＯＳの領域に格納して、該ノードは管理ホストから転送されたＯＳ修正パッチを実行し、現用ＯＳにパッチを適用する。
（１０）、修正の対象となるプログラムは、各ノードで実行されるＯＳ（図１の例）、又は各ノードの不揮発性記憶に格納されたファームウェア（図８の例）、又はノードとはネットワークを介して独立して接続されたファイルサーバのＯＳ（図９の例）であること。
（１１）、ファイルサーバのＯＳの修正に関し、ファイルサーバの外部記憶装置には、バージョンごとのＯＳを格納しておくと共に、ファイルサーバには、該外部記憶装置からノードに転送すべきＯＳを選択する選択手段を有し、
管理ホストは、各ノードの状態を管理するための、ノードが単位時間当りに処理可能なリクエスト数を表す処理能力、パッチ適用作業を開始してからサービスを再開するまでに要する時間を表す監視待機時間、ノードに対するパッチ適用作業の進行状態を表す情報、及び現ＯＳのバージョン及び前のＯＳのバージョンの情報を格納するノード状態テーブルを有し
復旧タスクの処理中に、該ノード状態テーブルを参照して、状態が「失敗」を示している場合、該ノードの現ＯＳのバージョンを前のＯＳのバージョンに変更すること。
【００５１】
【発明の効果】
本発明によれば、クラスタシステムにおける複数の計算機上のプログラムを修正するのに要する時間を、システムの性能を低下させずに、短縮できる。
【図面の簡単な説明】
【図１】本発明の一実施例が適用されるＷｅｂサービスシステムの構成を示す図。
【図２】一実施例におけるノード状態テーブル１０１の説明に供する図。
【図３】一実施例における制御タスクの処理フローチャートを示す図。
【図４】一実施例における復旧タスクの処理フローチャートを示す図。
【図５】第１実施例および第３実施例における監視タスクの処理フローチャートを示す図。
【図６】第１実施例におけるノード側のパッチ適用処理フローチャートを示す図。
【図７】第１実施例におけるノードのブート処理フローチャートを示す図。
【図８】第２の実施例によるＷｅｂサービスシステムの構成を示す図。
【図９】第３の実施例によるシステムの構成を示す図。
【図１０】第３の実施例におけるノード状態テーブルＡ０１の説明に供する図。
【図１１】第３の実施例における制御タスクの処理フローチャートを示す図。
【図１２】第３の実施例におけるノードのブート処理フローチャートを示す図。
【図１３】第３の実施例における復旧タスクのフローチャートを示す図。
【符号の説明】
００６  ネットワーク
００７  負荷監視ユニット
００８  ＯＳパッチ処理制御プログラム
００９  管理ホスト
００５  ＯＳ修正プログラム
０１１〜０１４  ノード
０１６  サービスプロセッサ
０１７  復旧フラグ
０１９  現用ＯＳ
０２０  旧ＯＳ
１０１  ノード状態テーブル。
【図１】
2005043941.tif 000003
【図２】
2005043941.tif 000004
【図３】
2005043941.tif 000005
【図４】
2005043941.tif 000006
【図５】
2005043941.tif 000007
【図６】
2005043941.tif 000008
【図７】
2005043941.tif 000009
【図８】
2005043941.tif 000010
【図９】
2005043941.tif 000011
【図１０】
2005043941.tif 000012
【図１１】
2005043941.tif 000013
【図１２】
2005043941.tif 000014
【図１３】
2005043941.tif 000015