JPH10187638A - クラスタ制御システム - Google Patents

Abstract

(57)【要約】 【課題】 クラスタシステムを監視制御し、障害が発生
した場合に当計算機上で動作していたプログラムをクラ
スタ内の他の計算機に移行して実行させることを目的と
する。 【解決手段】 クラスタを構成する各計算機上でクラス
タデーモンが実行されており、各パッケージを起動する
と同時に、実行計算機上のリソースを監視制御し、その
データを各計算機上にローカルデータとして保持する。
マネージャは、各計算機上のクラスタデーモンと通信を
行ない、クラスタシステム全体の監視制御のためのグロ
ーバルデータを保持している。また、マネージャは、ク
ラスタシステムのパッケージの１つであり、マネージャ
やマネージャを実行している計算機に障害が発生した場
合、クラスタデーモンにより他の計算機上で再起動され
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、クラスタシステム
を監視制御し、ある計算機上で障害が発生した場合に該
計算機上で動作していたパッケージプログラムをクラス
タを構成する他の計算機に移行して実行するクラスタ制
御システムに関するものである。

【０００２】

【従来の技術】従来クラスタと呼ばれる技術には大きく
分けて、ＣＰＵが主記憶を共有する密結合型クラスタ
と、計算機がＬＡＮや共有ディスクなどを用いてデータ
を共有する疎結合型クラスタの２つが存在するが、ここ
での記述は後者の疎結合型クラスタについてである。図
５０は、従来のクラスタシステムの構成例を示す説明図
である。図において、計算機Ａ〜Ｎ（１０１ａ〜１０１
ｎ）はクラスタを構成する複数の計算機である。各計算
機上では、ｃｌｕｓｔｅｒ ｄａｅｍｏｎＡ〜Ｎ（１０
２ａ〜１０２ｎ）が実行されており、各ｃｌｕｓｔｅｒ
ｄａｅｍｏｎにより各パッケージプログラムＡ１〜Ｎ
２（１０３ａ１〜１０３ｎ２）が起動される。ここで、
パッケージプログラムとは、アプリケーションプログラ
ムやサービスプログラム等の総称である。各ｃｌｕｓｔ
ｅｒ ｄａｅｍｏｎは、実行している計算機上のリソー
ス（ＣＰＵ，ＬＡＮ，Ｄｉｓｋ，パッケージプログラム
が提供する各種サービス，ネットワークアドレスなど）
を監視／制御し、そのデータを各計算機上にローカルデ
ータＡ〜Ｎ（１０４ａ〜１０４ｎ）として保持してい
る。

【０００３】次に、クラスタシステムの動作について、
図５１に基づいて説明する。計算機Ａ（１０１ａ）上で
必要なリソースＡ（２４０１ａ）がなくなった場合、ｃ
ｌｕｓｔｅｒ ｄａｅｍｏｎＡ（１０２ａ）は計算機Ａ
（１０１ａ）を停止させる。計算機Ａ（１０１ａ）が停
止した場合、他の計算機Ｎ（１０１ｎ）上のｃｌｕｓｔ
ｅｒ ｄａｅｍｏｎ Ｎ（１０２ｎ）がこれを検知し、
計算機Ａ（１０１ａ）上で実行していたパッケージプロ
グラムＡ（１０３ａ）を他の計算機Ｎ（１０１ｎ）で実
行する。このようにして、パッケージプログラムは、ク
ラスタ内のどこかの計算機上で実行されることになる。
また、各パッケージプログラム毎にネットワークアドレ
スを割り当てることにより、パッケージプログラムが提
供するサービスを利用する場合において、ユーザはパッ
ケージプログラムがクラスタ内のどの計算機上で実行さ
れているかを意識する必要がなかった。また、分散して
いるリソースの状態を集中して監視制御する方式とし
て、特開平５−７５６２８号「ネットワーク資源監視シ
ステム」、特開平５−１３４９０２号「分散コンピュー
ティングシステムでの稼働情報管理方式」、特開平６−
２２３０２０号「ネットワーク管理システムおよびオブ
ジェクトの管理方法」などがあった。しかしながら、こ
れらの方式は管理用の計算機や管理用のプロセス（マネ
ージャ）を用いることにより実現しており、管理用の計
算機や管理用のプロセス（マネージャ）に障害が発生し
た場合については考慮されていなかった。

【０００４】

【発明が解決しようとする課題】従来のクラスタシステ
ムは以上のようにして構成されているので、システム全
体の監視および制御を行うプログラムを作成する場合に
おいては、データが各計算機に分散されていて、クラス
タ内の全ての計算機と通信しなければならず、プログラ
ムの作成が困難であるという問題点があった。また、分
散しているリソース状態を集中監視制御する方式におい
ては、システム全体を監視制御する計算機やプロセスに
障害が発生した場合に監視機能が全く停止するという問
題点があった。また、各種パッケージプログラム間の相
関関係や優先順位などの定義が行なえなかったため、多
重系などの他のシステムからの移行が困難であるという
問題点があった。また、パッケージの再起動に時間がか
かり、回復に時間がかかるという問題があった。また、
システムが回復後のパッケージの切り替え処理に時間が
かかり、並列処理を行うパッケージが並列処理を行えな
いため、回復後にシステムのパフォーマンスが落ちると
いう問題があった。

【０００５】この発明は上記のような問題点を解消する
ためになされたもので、クラスタシステム全体の監視お
よび制御を行うプログラムの作成を容易にするととも
に、他システムからの移行を可能とし、高速に動作する
クラスタ制御システムを提供することを目的とする。

【０００６】

【課題を解決するための手段】第１の発明に係わるクラ
スタ制御システムは、クラスタシステムを構成する計算
機群上のある計算機に障害が発生した場合に該計算機上
で動作中のパッケージプログラムを他の計算機で実行さ
せるクラスタシステムにおいて、クラスタを構成する各
計算機が、アプリケーションや各種のサービスを提供す
るパッケージプログラムと、計算機間で通信を行いリソ
ースを監視制御するクラスタデーモンと、監視結果をロ
ーカルデータとして記憶するローカルデータ記憶手段を
備え、クラスタシステム内のうち１台の計算機は、上記
パッケージプログラム、クラスタデーモン、ローカルデ
ータ記憶手段に加えて、各計算機上のローカルデータか
ら収集されて、いずれの計算機からも参照可能なグロー
バルデータ記憶手段と、グローバルデータ記憶手段およ
び各計算機上のクラスタデーモンと通信を行い、クラス
タシステム全体の監視制御を行うマネージャを搭載し、
マネージャが搭載されている計算機で障害が発生した場
合にはクラスタ内の他の計算機上で再起動させるように
したものである。

【０００７】第２の発明に係わるクラスタ制御システム
は、クラスタシステムを構成する計算機群上のある計算
機に障害が発生した場合に計算機上で動作中のパッケー
ジプログラムを他の計算機で実行させるクラスタシステ
ムにおいて、クラスタを構成する各計算機が、アプリケ
ーションや各種のサービスを提供するパッケージプログ
ラムと、計算機間で通信を行いリソースを監視制御する
クラスタデーモンと、自計算機上のクラスタデーモンお
よびマネージャと通信を行うエージェントと、監視結果
をローカルデータとして記憶するローカルデータ記憶手
段を備え、クラスタシステム内のうち１台の計算機は、
クラスタデーモン、エージェント、ローカルデータ記憶
手段に加えて、各計算機上のローカルデータから収集さ
れて、いずれの計算機からも参照可能なグローバルデー
タ記憶手段と、グローバルデータ記憶手段および各計算
機上のエージェントと通信を行い、クラスタシステム全
体の監視制御を行うマネージャを搭載し、マネージャが
搭載されている計算機に障害が発生した場合にクラスタ
内の他の計算機上で再起動させるようにしたものであ
る。

【０００８】第３の発明に係わるクラスタ制御システム
は、クラスタシステムを構成する計算機群上のある計算
機に障害が発生した場合に計算機上で動作していたパッ
ケージプログラムを他の計算機で実行させるクラスタシ
ステムにおいて、クラスタを構成する各計算機が、アプ
リケーションや各種のサービスを提供するパッケージプ
ログラムと、自計算機上のパッケージプログラムおよび
計算機間で通信を行いリソースを監視制御するクラスタ
デーモンと、自計算機上のクラスタデーモン、各計算機
上のエージェント間、およびグローバルデータ記憶手段
と通信を行うエージェントと、監視結果をローカルデー
タとして記憶するローカルデータ記憶手段を備え、クラ
スタシステム内のうち１台の計算機は、上記クラスタデ
ーモン、エージェント、ローカルデータ記憶手段に加え
て、各計算機上のローカルデータから収集されて、いず
れの計算機からも参照可能なグローバルデータ記憶手段
を備え、各計算機上のエージェントが直接にグローバル
データ記憶手段、およびエージェント間で通信を行うよ
うにしたものである。

【０００９】第４の発明に係わるクラスタ制御システム
は、クラスタシステムを構成する計算機群上のある計算
機に障害が発生した場合に計算機上で動作していたパッ
ケージプログラムを他の計算機で実行させるクラスタシ
ステムにおいて、クラスタを構成する各計算機が、アプ
リケーションや各種のサービスを提供するパッケージプ
ログラムと、自計算機上のパッケージプログラムおよび
各計算機間で通信を行いリソースを監視制御するクラス
タデーモンと、自計算機上のクラスタデーモン、各計算
機上のエージェント間、およびグローバルデータと通信
を行うエージェントと、監視結果をローカルデータとし
て記憶するローカルデータ記憶手段を備え、クラスタシ
ステム内のうち１台の計算機は、上記クラスタデーモ
ン、エージェント、ローカルデータ記憶手段に加えて、
各計算機上のローカルデータから収集されて、いずれの
計算機からも参照可能なグローバルデータ記憶手段と、
自計算機上のエージェントおよびクラスタデーモンと通
信を行うマネージャを備え、各計算機上のエージェント
が直接にグローバルデータ記憶手段、およびエージェン
ト間で通信を行うようにしたものである。

【００１０】第５の発明は、第１または第２または第４
の発明に係わるクラスタ制御システムにおいて、マネー
ジャはクラスタシステムを構成する計算機群のリソース
状態変化時の処理を記述したリソース設定ファイルと、
リソース設定ファイルの定義に従い、リソースの状態に
変化があった場合にリソース制御処理を行なう自動制御
機構を備えるようにしたものである。

【００１１】第６の発明は、第５の発明に係わるクラス
タ制御システムにおいて、リソース設定ファイルにはパ
ッケージプログラム間の相関関係や実行に関する優先順
位情報を定義し、自動制御機構は、該定義情報に基づい
て各計算機上のパッケージプログラムを動作させるよう
にしたものである。

【００１２】第７の発明は、第１または第２または第４
または第５のいずれかの発明に係わるクラスタ制御シス
テムにおいて、マネージャはパッケージプログラムに対
して、運転、待機、試験を含む運転動作モードを付加
し、該モードに従ってパッケージプログラムの動作制御
の管理を行なうモード管理機構を備えるようにしたもの
である。

【００１３】第８の発明は、第１、第２、第４乃至第７
のいずれかの発明に係わるクラスタ制御システムにおい
て、マネージャは、クラスタシステム内で起きたリソー
スの状態変化に関するログを収集するログ管理機構を備
えるようにしたものである。

【００１４】また、第９の発明は、クラスタ制御システ
ムを構成する複数の計算機のうちの１つの計算機に障害
が発生した場合に、上記障害が発生した計算機で運転中
のアプリケーションや各種のサービスを提供するパッケ
ージプログラムを他の計算機で運転させるクラスタ制御
システムにおいて、上記複数の計算機はそれぞれ、自己
の計算機の障害及び回復を監視するとともに、上記パッ
ケージプログラムの起動及び運転を制御するクラスタデ
ーモンを備え、上記複数の計算機のうちの第１の計算機
は、上記パッケージプログラムである第１のパッケージ
プログラムを運転し、上記複数の計算機のうちの第２の
計算機は、上記第１のパッケージプログラムと同じアプ
リケーションやサービスを提供する第２のパッケージプ
ログラムを起動状態で待機させ、上記複数の計算機のう
ち１つの計算機は、上記クラスタデーモンに加えて、上
記複数の計算機のそれぞれのクラスタデーモンから監視
の結果を受け取るとともに、上記クラスタデーモンを制
御して、上記第１の計算機に障害が発生した場合に、上
記第２の計算機に上記第２のパッケージプログラムを運
転させるとともに、上記第１の計算機が障害から回復し
た場合には、上記第１の計算機に上記第１のパッケージ
プログラムを起動状態で待機させるマネージャを備えた
ものである。

【００１５】また、第１０の発明は、上記第１のパッケ
ージプログラムの出力若しくは上記第２のパッケージプ
ログラムの出力のいずれかを選択して出力する出力制御
手段を有し、上記第２の計算機は、上記第２のパッケー
ジプログラムを起動状態で待機させる代わりに、上記第
２のパッケージプログラムを運転し、上記マネージャに
代えて、上記複数の計算機のそれぞれのクラスタデーモ
ンから監視の結果を受け取るとともに、上記クラスタデ
ーモンを制御して、上記第１のパッケージプログラムの
出力が上記出力制御手段から出力されているときに上記
第１の計算機で障害が発生した場合、上記第１のパッケ
ージプログラムの出力に代えて上記第２のパッケージプ
ログラムの出力を上記出力制御手段から出力させ、上記
第２の計算機で障害が発生するまで上記出力制御手段に
上記第２のパッケージプログラムの出力を継続して出力
させ、上記第１のパッケージプログラムが運転を再開し
上記第２の計算機で障害が発生した場合に、上記第２の
パッケージプログラムの出力に代えて、上記第１のパッ
ケージプログラムの出力を上記出力制御手段から出力さ
せるマネージャを備えたものである。

【００１６】また、第１１の発明は、上記マネージャに
代えて、上記複数の計算機のそれぞれのクラスタデーモ
ンから監視の結果を受け取るとともに、上記クラスタデ
ーモンを制御して、上記第１の計算機に障害が発生した
場合に、上記第２の計算機に上記第２のパッケージプロ
グラムを運転させるとともに、上記複数の計算機のうち
の第３の計算機に上記第１のパッケージプログラムを起
動状態で待機させるマネージャを備えたものである。

【００１７】また、第１２の発明は、上記複数の計算機
のそれぞれで起動されるパッケージプログラムのそれぞ
れの優先順位を記憶する管理テーブルを備え、上記マネ
ージャに代えて、上記複数の計算機のそれぞれのクラス
タデーモンから監視の結果を受け取るとともに、上記ク
ラスタデーモンを制御して、上記第１の計算機に障害が
発生した場合に、上記管理テーブルから上記第１の計算
機で運転されていた上記パッケージプログラムよりも優
先順位の低いパッケージプログラムを検索し、この優先
順位の低いパッケージプログラムの運転を停止させると
ともに、上記優先順位の低いパッケージプログラムを運
転していた計算機で上記第１の計算機で運転されていた
パッケージプログラムを起動させるマネージャを備えた
ものである。

【００１８】また、第１３の発明は、クラスタシステム
を構成する複数の計算機のうちの１つの計算機に障害が
発生した場合に、上記障害が発生した計算機で運転中の
アプリケーションや各種のサービスを提供するパッケー
ジプログラムを他の計算機で運転させるクラスタシステ
ムにおいて、上記複数の計算機はそれぞれ、自己の計算
機の障害及び回復を監視するとともに、上記パッケージ
プログラムの起動及び運転を制御するクラスタデーモン
を備え、上記複数の計算機のうち１つの計算機は、上記
クラスタデーモンに加えて、上記複数の計算機のそれぞ
れで起動されるパッケージプログラムのそれぞれの優先
順位及び上記複数の計算機のそれぞれの負荷を記憶する
管理テーブルと、上記複数の計算機のそれぞれのクラス
タデーモンから監視の結果を受け取るとともに、上記ク
ラスタデーモンを制御して、上記複数の計算機のうちの
第１の計算機の負荷があらかじめ定められた負荷よりも
大きくなった場合に、上記管理テーブルを参照し、上記
第１の計算機で運転しているパッケージプログラムのう
ちの優先順位の低いパッケージプログラムの運転を停止
させ、停止させたパッケージプログラムを上記複数の計
算機のうちの負荷があらかじめ定められた負荷よりも小
さい計算機で起動させるマネージャと、を備えたたもの
である。

【００１９】また、第１４の発明は、上記管理テーブル
に代えて、上記複数の計算機上で起動されるパッケージ
プログラムのそれぞれの優先順位を記憶する管理テーブ
ルを備え、上記クラスタデーモンは、自己の計算機のリ
ソースを監視し、上記マネージャに代えて、上記複数の
計算機のそれぞれのクラスタデーモンから監視の結果を
受け取るとともに、上記クラスタデーモンを制御して、
上記クラスタデーモンにより監視されたリソースに変化
が生じた場合に、上記優先順位に基づいて、上記複数の
計算機のそれぞれで運転されているパッケージプログラ
ムのそれぞれにリソースを割り当て直すマネージャを備
えたものである。

【００２０】また、第１５の発明は、複数の計算機のそ
れぞれによって並列に運転される複数の上記パッケージ
プログラムを１つのグループとするグループ名を記憶す
る管理テーブルを備え、上記マネージャに代えて、上記
複数の計算機のそれぞれのクラスタデーモンから監視の
結果を受け取るとともに、上記クラスタデーモンを制御
して、上記複数の計算機のうちの第１の計算機に障害が
発生した場合に、上記管理テーブルから、上記複数の計
算機のうちの計算機であって上記第１の計算機上で運転
されていたパッケージプログラムと同じグループのパッ
ケージプログラムを運転していない計算機を検索し、検
索された計算機で上記第１の計算機が運転していたパッ
ケージプログラムを起動させ、運転させるマネージャを
備えたものである。

【００２１】

【発明の実施の形態】

実施の形態１．以下、この発明の第１の実施形態につい
て、図１乃至図５に基づいて説明する。図１において、
計算機Ａ〜Ｎ（１０１ａ〜１０１ｎ）はクラスタを構成
する複数の計算機である。各計算機上では、ｃｌｕｓｔ
ｅｒ ｄａｅｍｏｎＡ〜Ｎ（１０２ａ〜１０２ｎ）が実
行されており、各ｃｌｕｓｔｅｒ ｄａｅｍｏｎにより
各パッケージプログラムＡ１〜Ｎ２（１０３ａ１〜１０
３ｎ２）が起動される。パッケージプログラムとは、ア
プリケーションやサービスの総称である。また、各ｃｌ
ｕｓｔｅｒ ｄａｅｍｏｎは、実行している計算機上の
リソース（ＣＰＵ，ＬＡＮ，Ｄｉｓｋ，パッケージプロ
グラム，ネットワークアドレスなど）を監視制御し、そ
のデータを各計算機上にローカルデータＡ〜Ｎ（１０４
ａ〜１０４ｎ）として保持している。マネージャ１０５
は、各計算機上のｃｌｕｓｔｅｒ ｄａｅｍｏｎと通信
を行なうことにより、クラスタシステム全体の監視制御
を行なうものであり、グローバルデータ１０６を保持し
ている。グローバルデータ１０６は、クラスタ内の計算
機のどこからでも参照することができるデータであり、
共有ディスクや共有メモリ、メモリのレプリケーション
などにより実現されている。また、マネージャ１０５
は、クラスタシステム内のパッケージの１つであり、マ
ネージャやマネージャを実行している計算機に障害が発
生した場合、ｃｌｕｓｔｅｒ ｄａｅｍｏｎにより他の
計算機上で再起動される。

【００２２】次に、マネージャの構成を図２に基づいて
説明する。図において、要求処理機構２０１は、ユーザ
からの要求（Ｄ２０１：リソース状態取得要求、リソー
ス制御要求、通知設定要求）を受信し、要求に応じた処
理を行ない（Ｄ２０２，Ｄ２０３，Ｄ２０４）、ユーザ
に処理結果（Ｄ２０５）を送信する機構である。リソー
ス制御機構２０２は、要求処理機構２０１からの要求
（Ｄ２０４）を受け、要求の対象となるリソースを保持
している計算機をリソース状態ＤＢ（２０３）を参照
（Ｄ２０６）することにより決定し、その計算機に対し
てリソースの制御要求（Ｄ２０７）を送信するものであ
る。リソース状態監視機構２０４は定期的にクラスタ内
の各リソースに対し、リソースを保持している計算機に
リソース状態取得要求（Ｄ２０８）を送信し、その回答
であるリソース状態（Ｄ２０９）を受信し、リソース状
態ＤＢ（２０３）を参照（Ｄ２１０）し、リソースの状
態が変化した時にリソース状態変化処理機構２０５に通
知（Ｄ２１１）するものである。リソース状態変化処理
機構２０５は、リソース状態監視機構２０４からの通知
（Ｄ２１１）を受け、リソース状態ＤＢ（２０３）を更
新（Ｄ２１２）するとともに、通知設定ＤＢ（２０７）
を参照（Ｄ２１３）し、通知設定がされていればリソー
ス状態変化通知機構２０８に通知（Ｄ２１４）するもの
である。通知設定機構２０６は、要求処理機構２０１か
らの要求（Ｄ２０２）に従い、通知設定ＤＢ（２０７）
を更新（Ｄ２１５）し、リソース状態ＤＢ（２０３）を
参照（Ｄ２１６）し、現在の状態をリソース状態変化通
知機構２０８に通知（Ｄ２１７）するものである。リソ
ース状態変化通知機構２０８は、リソース状態変化処理
機構２０５、または通知設定機構２０６からの通知（Ｄ
２１４、Ｄ２１７）を受け、設定を行なったユーザに対
してリソース状態変化通知（Ｄ２１８）を送信するもの
である。通信制御機構２０９は、ユーザ、ｃｌｕｓｔｅ
ｒ ｄａｅｍｏｎとの送受信を制御するものである。リ
ソース状態ＤＢ（２０３）は、リソースの名前、状態、
保持している計算機などの情報を格納しているデータベ
ースである。通知設定ＤＢ（２０７）は、マネージャと
接続しているどのユーザに対して、どのリソースの状態
が変化した時に通知を行なうかについての情報を格納し
ているデータベースである。

【００２３】次に、ユーザから要求があった場合のマネ
ージャの処理動作について、図３に基づいて説明する。
まず、ステップ３０１において、ユーザからの要求（Ｄ
２０１）を待ち、ステップ３０２において、ユーザから
の要求（Ｄ２０１）の種類を判別する。ユーザからの要
求がリソースの状態取得であった場合、ステップ３０３
において要求処理機構２０１はリソース状態ＤＢを参照
（Ｄ２０３）し、要求のあったリソースの状態を取得す
る。ステップ３０４において、要求処理機構２０１がユ
ーザへリソースの状態を送信（Ｄ２０５）し、ステップ
３０１に戻る。一方、ユーザからの要求がリソースの制
御であった場合、ステップ３０５において、リソース制
御機構２０２は要求処理機構２０１から要求（Ｄ２０
４）を受け、リソース状態ＤＢを参照（Ｄ２０６）し、
要求のあったリソースの状態を保持している計算機を取
得する。ステップ３０６において、リソース制御機構２
０２はステップ３０５で取得した計算機へ制御要求（Ｄ
２０７）を送信する。ステップ３０７において、要求処
理機構２０１はステップ３０６のリソース制御機構２０
２の処理結果をユーザへ送信（Ｄ２０５）し、ステップ
３０１に戻る。ユーザからの要求がリソースの状態変化
通知の設定であった場合、ステップ３０８において、通
知設定機構２０６は通知設定ＤＢを更新（Ｄ２１５）す
る。ステップ３０９において、要求処理機構２０１はリ
ソース制御機構２０２を起動する（Ｄ２０４）とともに
ユーザへ処理結果を送信（Ｄ２０５）する。ステップ３
１０において、通知設定機構２０６はリソース状態ＤＢ
（２０３）より現在のリソースの状態を取得（Ｄ２１
６）する。ステップ３１１において、リソース状態変化
通知機構２０８は通知設定機構２０６からの通知（Ｄ２
１７）を受け、ステップ３１０で取得したリソースの状
態をユーザへ通知（Ｄ２１８）し、ステップ３０１に戻
る。ステップ３１０においてユーザへの通知を行なうの
は、現在のリソースの状態（ユーザにとっての初期値）
を返すためである。

【００２４】次に、マネージャのリソースの監視処理に
ついて、図４に基づいて説明する。ステップ４０１にお
いて、ステップ４０２以降の処理を全リソースについて
行なう。ステップ４０２において、リソース状態監視機
構２０４はリソースの状態をそのリソースを保持してい
る計算機より取得（Ｄ２０８，Ｄ２０９）する。ステッ
プ４０３において、リソース状態監視機構２０４はリソ
ース状態ＤＢ（２０３）を参照（Ｄ２１０）し、その状
態と取得したリソースの状態が同じであれば、ステップ
４０１に戻り、それ以外ならばステップ４０４以降の処
理を行なう。ステップ４０４において、リソース状態変
化処理機構２０５はリソース状態監視機構２０４から通
知（Ｄ２１１）を受け、リソース状態ＤＢ（２０３）の
状態を取得したリソースの状態に更新（Ｄ２１２）す
る。ステップ４０５において、リソース状態変化処理機
構２０５は通知設定ＤＢを参照（Ｄ２１３）し、そのリ
ソースの状態変化に対するユーザへの通知が登録されて
いればステップ４０６において、リソース状態変化通知
機構２０８はリソース状態変化処理機構２０５から通知
（Ｄ２１４）を受け、ユーザにリソースの状態変化を通
知（Ｄ２１８）し、それ以外ならば、ステップ４０１に
戻る。ステップ４０７において、一定時間停止する。

【００２５】図５はクラスタシステム内における監視制
御用プロセスの構成例を示したものである。図におい
て、マネージャ１０５と同一の計算機Ａ（１０１ａ）上
のプロセスＡ（５０１ａ）、クラスタ内の他の計算機Ｂ
（１０１ｂ）上のプロセスＢ（５０１ｂ）、ＷＳなどの
ようなクラスタ外の計算機Ｃ（５０２）上のプロセスＣ
（５０１ｃ）からクラスタ上の全リソースの監視制御を
行うことが可能となる。また、各パッケージプロセスは
マネージャ１０５に対してのみアクセスすればよく、マ
ネージャがどの計算機上で動作しているかを意識するこ
となく、クラスタの監視制御を行うことができる。

【００２６】実施の形態２．本発明の第２の実施形態に
ついて、図６乃至図１１に基づいて説明する。本実施形
態は図１のプロセス構成を変更したものであり、ｃｌｕ
ｓｔｅｒ ｄａｅｍｏｎが他の計算機からアクセスでき
ない場合や、マネージャおよびネットワークの負荷を軽
くしたい場合の構成である。図６は、本実施形態におけ
るプロセス構成を示す図である。エージェントＡ〜Ｎ
（６０１ａ〜６０１ｎ）は、各計算機上で実行されて、
各計算機上のｃｌｕｓｔｅｒ ｄａｅｍｏｎおよびマネ
ージャと通信を行なうものである。尚、その他の要素
は、図１において同一番号を付したのものと同じ構成要
素である。

【００２７】図７は、本実施形態におけるマネージャの
構成である。図２との相違点は、リソース状態監視機構
２０４を削除し、リソース状態変化処理機構２０５はエ
ージェントからの通知を受信（Ｄ７０１）するようにし
たこと、及びリソース制御機構２０２はｃｌｕｓｔｅｒ
ｄａｅｍｏｎに対してではなくエージェントにリソー
ス制御要求を送信（Ｄ７０２）するようにしたことであ
る。

【００２８】図８は、本実施形態におけるエージェント
の構成を示す図である。各機構の動作は図２と同様であ
るが以下の点が異なっている。即ち、通知設定ＤＢ（２
０７）、および通知設定機構２０６が削除され、要求処
理機構２０１に対する要求は、マネージャからのリソー
ス制御要求（Ｄ７０２）だけである。リソース制御機構
２０２は、リソース状態ＤＢ（２０３）を参照せずに、
動作している計算機上のｃｌｕｓｔｅｒ ｄａｅｍｏｎ
にリソース制御要求（Ｄ７０２）を送信する。リソース
状態変化処理機構２０５は、通知設定ＤＢ（２０７）を
参照せずに全てのリソース状態監視機構２０４からの通
知（Ｄ２１１）をリソース状態変化通知機構２０８に通
知（Ｄ２１４）する。リソース状態変化通知機構２０８
は、ユーザに対してではなく、マネージャに対してリソ
ース状態変化通知（Ｄ７０１）を行う。リソース状態Ｄ
Ｂ（８０１）は、エージェントが実行されている計算機
が保持するローカルなリソース状態のみを管理してい
る。通信制御機構２０９の送信時にマネージャ１０５が
存在しなかった場合、そのデータはキューに保持され
る。ユーザからの要求があった場合におけるマネージャ
の処理は、図３と同様である。

【００２９】次に、図１０に基づいて、マネージャのリ
ソースの監視処理について説明する。ステップ１００１
において、リソース状態監視機構２０４はエージェント
からのリソース状態変化通知（Ｄ７０１）を待つ。ステ
ップ１００２〜１００４は、図４におけるステップ４０
４〜４０６と同様である。

【００３０】次に、エージェントのリソースの監視処理
について、図１１に基づいて説明する。ステップ１１０
１において、ステップ１１０２以降の処理を計算機上の
全リソースについて行なう。ステップ１１０２におい
て、リソース状態監視機構２０４はリソースの状態をｃ
ｌｕｓｔｅｒ ｄａｅｍｏｎより取得（Ｄ２０８，Ｄ２
０９）する。ステップ１１０３において、リソース状態
監視機構２０４はリソース状態ＤＢを参照（Ｄ２１０）
し、その状態と取得したリソースの状態が同じであれ
ば、ステップ１１０１に戻り、それ以外ならばステップ
１１０４以降の処理を行なう。ステップ１１０４におい
て、リソース状態変化処理機構２０５はリソース状態監
視機構２０４から通知（Ｄ２１１）を受け、リソース状
態ＤＢの状態を取得したリソースの状態に更新（Ｄ２１
２）する。ステップ１１０５において、リソース状態変
化通知機構２０８はリソース状態変化処理機構２０５か
ら通知（Ｄ２１４）を受け、マネージャにリソースの状
態変化を通知（Ｄ７０１）し、ステップ１１０１に戻
る。また、ステップ１１０６において一定時間停止す
る。

【００３１】更に、図９は図８の変形例を示した図であ
り、ｃｌｕｓｔｅｒ ｄａｅｍｏｎにリソースの状態変
化の通知を行なう機能がある場合のエージェントの構成
である。各機構の基本動作は図８と同様であるが、リソ
ース状態監視機構２０４、リソース状態ＤＢ（８０１）
を削除し、通知設定機構２０６を追加した点で異なって
いる。ここで、通知設定機構２０６はエージェントの起
動またはｃｌｕｓｔｅｒ ｄａｅｍｏｎの起動時に全て
のリソースの状態変化を通知するようにｃｌｕｓｔｅｒ
ｄａｅｍｏｎに通知設定要求（Ｄ９０１）を送信する
機構である。また、リソース状態変化処理機構２０５
は、ｃｌｕｓｔｅｒ ｄａｅｍｏｎからの通知（Ｄ９０
２）を受け、リソース状態変化通知機構２０８に通知
（Ｄ９０３）する。

【００３２】以上の構成により、ｃｌｕｓｔｅｒ ｄａ
ｅｍｏｎが同一計算機上のプロセスとしか通信できない
場合においても、同一計算機上のエージェントがｃｌｕ
ｓｔｅｒ ｄａｅｍｏｎと通信し、マネージャはエージ
ェントと通信するため、マネージャによるクラスタの集
中監視制御が可能となる。また、各エージェントがリソ
ースの状態を定期的に取得するようにしたので、負荷が
分散され、ネットワークを流れるデータが少なくなり、
マネージャ、ネットワークの負荷を軽くすることが可能
である。

【００３３】実施の形態３．本発明の第３の実施形態に
ついて、図１２、図１３に基づいて説明する。本実施形
態は、図６のプロセス構成を変更したものであり、マネ
ージャを削除してエージェント同志が互いに通信し、グ
ローバルデータを参照するようにしたものである。次
に、図１２に基づいてプロセス構成を説明する。エージ
ェントＡ〜Ｎ（６０１ａ〜６０１ｎ）は、各エージェン
トＡ〜Ｎが搭載された計算機上で実行されるｃｌｕｓｔ
ｅｒ ｄａｅｍｏｎ、他の計算機上のエージェント、お
よびユーザと通信を行なうものである。グローバルデー
タ１０６は、各計算機からアクセス可能であり、各計算
機からのアクセスは排他的に行なわれる。エージェント
の構成は、図２のマネージャの構成と同様であるが、各
機構は以下の点で異なっている。リソース状態ＤＢ（２
０３）、通知設定ＤＢ（２０７）に対するアクセスは、
各エージェントで排他をとりアトミックに行なわれる。
また、各エージェントのリソース状態監視機構２０４
は、各エージェントの実行されている計算機上のリソー
スのみの監視を行なう。また、リソース制御機構２０２
は、制御するリソースが計算機上に存在すれば、計算機
上のｃｌｕｓｔｅｒ ｄａｅｍｏｎに送信し、存在しな
ければリソース状態ＤＢ（２０３）を参照して、そのリ
ソースを保持している計算機上のエージェントまたは、
ｃｌｕｓｔｅｒ ｄａｅｍｏｎに送信する。更に、通信
制御機構２０９における各ユーザからの受信、ユーザへ
の送信は各ユーザまたは各エージェントからの受信、ユ
ーザまたはエージェントへの送信となる。

【００３４】図１３は、本構成を用いたユーザプロセス
の構成例を示す図である。ユーザプロセスＡ（１３０
１）は、エージェント６０１ａ〜６０１ｎの内のどれか
１つのエージェントを選び通信を行なう。ここで、図１
３（ｂ）のようにエージェントに障害が発生した場合
は、他のエージェントを選び再接続する。ユーザプロセ
スＢ（１３０２）は、エージェント６０１ａ〜６０１ｎ
の内のどれか２つのエージェントを選び通信を行なうも
のである。この場合には、図１３（ｂ）のように片方の
エージェントに障害が発生した場合でも、もう一方のエ
ージェントと通信を行なうことにより、処理を継続する
ことが可能である。以上の構成により、ユーザは、クラ
スタ内のどれか一つのエージェントと通信することによ
りクラスタの集中監視制御が可能となる。また、２つの
エージェントと通信することにより、エージェントに障
害が発生した場合の通信不能時間を短縮することが可能
となる。

【００３５】実施の形態４．本発明の第４の実施形態に
ついて、図１４、図１５に基づいて説明する。本実施形
態は、図１２においてマネージャ１０５を追加したもの
である。以下に、図１４を用いてプロセス構成を説明す
る。ここで、エージェントＡ〜Ｎ（６０１ａ〜６０１
ｎ）は、図１２に記載のものと同様である。マネージャ
１０５は、ネットワークアドレスのみを持つパッケージ
プログラムとして構成され、ユーザはマネージャ１０５
にアクセスすることにより、クラスタ内のどれか１つの
エージェントに対しアクセスを行うことができる。

【００３６】図１５は、本構成を用いたユーザプロセス
の構成例である。ユーザプロセスＡ（１５０１）は、マ
ネージャ１０５と通信を行なうものである。図１５
（ｂ）のようにマネージャ１０５に障害が発生した場合
は、他の計算機上でマネージャ１０５が再起動され、ユ
ーザプロセスＡ（１５０１）は、マネージャ１０５と再
接続される。ユーザプロセスＢ（１５０２）は、エージ
ェント６０１ａ〜６０１ｎの内のどれか２つのエージェ
ントを選び通信を行なうものである。図１５（ｂ）のよ
うに片方のエージェントに障害が発生した場合でも、も
う一方のエージェントと通信を行なうことにより、処理
を継続することが可能である。以上の構成により、ユー
ザは実施形態１、実施形態２のようにマネージャに対し
てのみアクセスを行なうか、または実施形態３のように
クラスタ内のどれか一つのエージェントにアクセスする
かの運用形態を適宜選択することが可能となる。また、
マネージャに対してのみアクセスを行なう場合、マネー
ジャはネットワークアドレスのみを有するパッケージプ
ログラムとして構成されるので、実施形態１、および２
と比べ短い時間でマネージャの移動が行なえるので、マ
ネージャに障害が発生した場合でも通信不能時間を短縮
することができる。

【００３７】実施の形態５．本発明の第５の実施形態に
ついて、図１６、図１７に基づいて説明する。本実施形
態は図７のマネージャにおいて、マネージャに設定ファ
イルと自動制御機構を備えたものである。図１６は、本
実施形態におけるマネージャの構成図である。図におい
て、設定ファイル１６０１はリソース状態の変化に基づ
いてシステムの自動制御を行なうためのものであり、リ
ソース名、イベント名、処理の組を記述したものであ
る。また、イベント名、処理中の変数名（ａｔｔｒｉｂ
ｕｔｅ）、およびコマンド名（ｍｅｔｈｏｄ）はリソー
スの種類により決まるものであり、変数名は“リソース
名．変数名”と表記し、コマンド名は“リソース名−＞
コマンド名”と表記する。自動制御機構１６０２は、設
定ファイル１６０１を読み込み（Ｄ１６０１）、リソー
ス状態変化処理機構２０５からの通知（Ｄ１６０２）を
受けた時に、リソース状態ＤＢ（２０３）を参照（Ｄ１
６０３）し、設定ファイル１６０１の定義に従い、リソ
ース制御機構２０２にリソース制御要求（Ｄ１６０４）
を送信する機構である。

【００３８】次に、図１７は、設定ファイルの例を示し
た図である。図において、ｐｋｇ１，ｐｋｇ２はリソー
ス名であり、リソースの種類はパッケージである。１〜
３行目はコメントである。５〜９行目はｐｋｇ１が停止
した時にｐｋｇ２が起動されていなければｐｋｇ２を起
動するための定義である。１１〜１５行目はｐｋｇ１が
起動した時にｐｋｇ２がｐｋｇ１と同じ計算機上で起動
されていればｐｋｇ２を停止するための定義である。１
７〜２１行目はｐｋｇ２が起動した時にｐｋｇ１がｐｋ
ｇ２と同じ計算機上で起動されていればｐｋｇ２を停止
する（ｐｋｇ２の起動を中止する）ための定義である。
以上の定義では、ｐｋｇ１とｐｋｇ２が同じ計算機上で
は動作しないようにし、同じ計算機上で動作しようとし
た場合にはｐｋｇ１を優先するようなシステムとなる。
本設定ファイルではパッケージに対する制御を例とした
が、もちろん他のリソースに対する制御を行なっても良
い。また、本実施形態では実施形態２のマネージャにつ
いて説明したが、実施形態１、実施形態４に記載のマネ
ージャに対して実施しても良い。

【００３９】実施の形態６．本発明の第６の実施形態に
ついて、図１８に基づいて説明する。本実施形態は図１
７の設定ファイルの変形例に関するもので、パッケージ
間の相関関係や優先順位の設定を可能としたものであ
る。設定ファイルにパッケージ名とパッケージの実行可
能条件の組の記述を加えたものであり、自動制御機構は
設定ファイルの設定に従いリソース制御機構により、リ
ソースの制御を可能としたものである。パッケージの実
行可能条件はパッケージ名、｜、＆、！の列であり、パ
ッケージ名は同じ計算機上でそのパッケージが起動して
いることを条件とし、｜、＆、！は条件の論理和、論理
積、論理否定を表す。また、記述した順番によりパッケ
ージの優先順位は定義されるものとする。

【００４０】図１８は、設定ファイルの例である。１行
目はコメントである。２行目は、ｐｋｇ１は同じ計算機
上でｐｋｇ２が動作していてはいけないことを定義して
いる。３行目は、ｐｋｇ２とｐｋｇ１が同じ計算機上で
動作することを禁止するための定義である。４行目は、
ｐｋｇ３はｐｋｇ１またはｐｋｇ２が、同じ計算機上で
動作しなければならないことを定義している。以上の定
義によれば、ｐｋｇ３は同じ計算機上でｐｋｇ１または
ｐｋｇ２のどちらか片方のみが動作している計算機上で
実行されるようなシステムとなる。

【００４１】実施の形態７．本発明の第７の実施形態に
ついて、図１９乃至図２１に基づいて説明する。本実施
形態は、図７のマネージャ構成にモード管理機構を備え
たものである。同じパッケージプログラムが複数の計算
機上で実行可能な場合に、各パッケージプログラムに”
運転”、”待機”、”試験”などのモードの情報を付加
し、モードの情報に基づいてパッケージプログラムの動
作を変更するようなマネージャを実現する。

【００４２】図１９は、本実施形態におけるマネージャ
の構成を示す図である。モード管理機構１９０１はリソ
ース状態変化処理機構２０５からの通知（Ｄ１９０１）
を受け、リソース状態ＤＢ２０３を参照（Ｄ１９０２）
し、図２０に示すような動作を行うようにリソース制御
機構２０２に対しリソース制御要求（Ｄ１９０３）を送
信する機構である。

【００４３】図２０は、パッケージプログラムのモード
状態遷移を示す図である。モードが停止のパッケージプ
ログラムは”運転”、”待機”、”試験”のモードを指
定して起動することによって各状態に遷移し、各状態か
らは、停止または、障害発生時にモードが”停止”の状
態に遷移する。また、モードが”待機”中のパッケージ
プログラムは、”運転”中の他のパッケージプログラム
が停止した場合に、”運転”のモードに状態遷移する。
また、モード状態が”運転”のパッケージは、常にクラ
スタ内で１つであるように制御される。

【００４４】図２１は、２台の計算機が動作する場合の
運用例を示す図である。図において、パッケージＡ（２
１０１，２１０２）は同一のパッケージであり、各計算
機上で実行されている。図２１（ａ）のように計算機１
上のパッケージＡ（２１０１）のモードを”運転”と
し、計算機２上のパッケージＡ（２１０２）のモード
を”待機”としていた場合、計算機１に障害が発生した
時（図２１（ｂ））、計算機２上のパッケージＡ（２１
０２）のモードを”運転”とし処理を継続する（図２１
（ｃ））。計算機１が再起動された時には、クラスタ内
に運転のパッケージＡ（２１０２）があるため、計算機
１上では、パッケージＡ（２１０１）のモードを待機と
して再起動する（図２１（ｄ））。以上のような構成を
とることにより、パッケージの再起動を行なうよりも短
時間で切替を行なうことが可能となる。本実施形態では
モードの状態として、”運転”、”待機”、”試験”を
定義したが、他の状態を定義してもよい。また、本実施
形態では実施形態２のマネージャを用いているが、勿
論、実施形態１、実施形態４、実施形態５のマネージャ
を使用しても良い。

【００４５】実施の形態８．本発明の第８の実施形態に
ついて、図２２に基づいて説明する。本実施形態は、図
７のマネージャ構成にログ管理機構を備えたものであ
る。本実施形態におけるマネージャの構成を図２２に示
す。図において、ログ管理機構２２０１は、リソース状
態変化処理機構２０５からリソースの状態変化の通知
（Ｄ２２０１）を受けログＤＢ（２２０２）を更新（Ｄ
２２０２）する。この時、ログのデータは時系列に並ぶ
ように制御する。また、要求処理機構２０１からの要求
（Ｄ２２０３）を受け、ログＤＢ（２２０２）を参照
（Ｄ２２０４）し、ログデータを返す。ログＤＢ（２２
０２）には、クラスタ内の全リソースの全イベントと発
生した時間が保存される。以上の構成により、ユーザは
マネージャに対してアクセスするだけでクラスタ内で発
生した全イベントの情報を取得することが可能となる。
また、本実施形態では、実施形態２のマネージャについ
て説明したが、勿論、実施形態１、実施形態４、実施形
態５、実施形態７のマネージャを使用しても良い。

【００４６】実施の形態９．本発明の第９の実施の形態
について、図２３〜図２６に基づいて説明する。本実施
形態は、図１に示したクラスタシステムのマネージャ１
０５の代わりに用いられ、各パッケージをモードで管理
する機能を有するマネージャを備えたものである。な
お、以降、計算機Ａ１０１ａ〜計算機Ｎ１０１ｎのうち
どれかを特定しないときは計算機１０１といい、クラス
タデーモンＡ１０２ａ〜Ｎ１０２ｎを特定しないときは
クラスタデーモン１０２．、パッケージ１０３ａ１〜１
０３ｎ２のうちどれかを特定しないときはパッケージ１
０３という。

【００４７】本実施形態におけるマネージャの構成を図
２３に示す。図２３において、通知処理機構２３０１
は、クラスタデーモン１０２からのリソース状態変化通
知を受信し（Ｄ２３０１）、モード管理機構２３０２に
受け取ったリソース状態変化通知を送る（Ｄ２３０２）
機構である。リソース状態変化通知（Ｄ２３０１）は、
計算機１０１が停止したときなど、システム全体のリソ
ースに変化があったときに、当該リソースを管理するク
ラスタデーモン１０２から送信される通知である。モー
ド管理機構２３０２は、通知処理機構２３０１からのリ
ソース状態変化通知（Ｄ２３０２）を受け、管理テーブ
ル２３０３を参照／更新し、モード制御機構２３０４に
モード制御要求（Ｄ２３０４）を送信する機構である。
モード制御機構２３０４は、モード管理機構２３０２か
らのモード制御要求（Ｄ２３０４）を受信し、クラスタ
デーモン１０２またはパッケージ１０３に対してモード
制御要求を送信する（Ｄ２３０５）機構である。

【００４８】図２４は管理テーブル２３０３の記憶内容
の例を示す。管理テーブル２３０３には、パッケージ名
とモードの状態、例えば「運転」、「待機」、「停止」
等が保持されている。図２５は、図２３のマネージャ１
０５の処理を説明するフローチャートである。

【００４９】次に、図２５に基づいて、マネージャ１０
５の動作について説明する。ステップ２５０１におい
て、モード管理機構２３０２は管理テーブル２３０３の
初期化を行う。次に、ステップ２５０２において、通知
処理機構２３０１はクラスタデーモン１０２からのリソ
ース状態変化通知（Ｄ２３０１）を待ち、受信したらモ
ード管理機構２３０２へリソース状態変化通知（Ｄ２３
０２）を送信する。続いて、ステップ２５０３におい
て、モード管理機構２３０２はリソース状態変化通知
（Ｄ２３０２）の種類を判別する。リソース状態変化通
知（Ｄ２３０２）が計算機１０１の起動である場合には
ステップ２５０７へ進み、計算機１０１の停止である場
合にはステップ２５０４へ進む。計算機の停止であった
場合、ステップ２５０４において、モード管理機構２３
０２は、管理テーブル２３０３を更新し、停止した計算
機１０１上で運転または待機していたすべてのパッケー
ジ１０３のモードを「停止」に書き換える。

【００５０】次に、ステップ２５０５において、モード
が「待機」のパッケージ１０３があるかを調べる。この
とき、複数種類のパッケージ１０３が計算機上で実行さ
れている場合には、停止したパッケージ１０３と同種類
のパッケージ１０３であってモードが「待機」であるパ
ッケージ１０３があるかを調べる。そのために、図２４
に示した管理テーブル２３０３に、パッケージ１０３が
実行されている計算機の情報及びパッケージ１０３の種
類の情報を追加してもよい。ステップ２５０５で、モー
ドが「待機」のパッケージ１０３がなかった場合にはス
テップ２５０２に戻る。ここで、モードが「待機」のパ
ッケージ１０３がなかった場合には、運転している他の
計算機１０１上で停止したパッケージ１０３と同種類の
パッケージを起動してもよい。

【００５１】モードが「待機」のパッケージ１０３があ
った場合には、ステップ２５０６において、モード管理
機構２３０２は、モード制御機構２３０４へ「運転」を
指示するモード制御要求（Ｄ２３０４）を送る。そし
て、モード制御機構２３０４がクラスタデーモン１０２
を介し、ステップ２５０５で見つけたパッケージ１０３
へモード制御要求（Ｄ２３０４）を送信することによ
り、待機していたパッケージ１０３を運転させる。

【００５２】次に、ステップ２５１０において、モード
管理機構２３０２は管理テーブル２３０３を更新する。
すなわち、ステップ２５０６で運転を指示したパッケー
ジ１０３についての管理テーブル２３０３のモードを
「運転」に書き換える。ステップ２５１０が終了する
と、ステップ２５０２に戻る。

【００５３】一方、ステップ２５０３で通知の種類が計
算機１０１の起動であると判断された場合には、ステッ
プ２５０７において、モード管理機構２３０２はモード
制御機構２３０４にモード制御要求（Ｄ２３０４）を送
り、起動した計算機１０１上において停止していたパッ
ケージ１０３を待機の状態で起動する。次に、ステップ
２５０８において、管理テーブル２３０３を参照し、モ
ードが「運転」のパッケージ１０３があるかどうかを調
べる。ここで、複数種類のパッケージ１０３が存在する
場合では、ステップ２５０７で起動したパッケージ１０
３と同種類のパッケージ１０３であってモードが「運
転」であるパッケージ１０３があるかどうかを調べる。

【００５４】モードが「運転」であるパッケージ１０３
がある場合には、ステップ２５１０において、モード管
理機構２３０２は管理テーブル２３０３を更新する。す
なわち、ステップ２５０７で起動したパッケージ１０３
についての管理テーブル２３０３のモードを「待機」に
書き換える。ステップ２５１０が終了すると、ステップ
２５０２に戻る。

【００５５】一方、モードが「運転」であるパッケージ
１０３がない場合には、ステップ２５０９において、モ
ード管理機構２３０２は、モード制御機構２３０４へ
「運転」を指示するモード制御要求（Ｄ２３０４）を送
る。そして、モード制御機構２３０４がクラスタデーモ
ン１０２を介し、ステップ２５０８で見つけたパッケー
ジ１０３にモード制御要求（Ｄ２３０５）を送信するこ
とにより、待機していたパッケージ１０３を運転させ
る。次に、ステップ２５１０において、モード管理機構
２３０２は管理テーブル２３０３を更新する。すなわ
ち、ステップ２５０９で運転を指示したパッケージ１０
３についての管理テーブル２３０３のモードを「運転」
に書き換える。ステップ２５１０が終了すると、ステッ
プ２５０２に戻る。

【００５６】図２６はこの実施の形態の動作の一例を説
明する図である。図２６において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図２
６（a）に示すように、第１の計算機である計算機Ａ１
０１ａ上で第１のパッケージであるパッケージＡ１０３
ａが実行されており、第２の計算機である計算機Ｂ１０
１ｂ上で第２のパッケージであるパッケージＢ１０３ｂ
が待機している状態で、図２６（b）に示すように計算
機Ａ１０１ａが停止したとすると、上述のようにマネー
ジャ１０５が動作し、図２６（c）に示すように、ただ
ちに計算機Ｂ１０１ｂ上で待機していたパッケージＢ１
０３ｂが実行、すなわち運転状態となる。このときパッ
ケージＡ１０３ａからパッケージＢ１０３ｂへの切り替
わりは、パッケージＢ１０３ｂが待機状態で待っていた
め、起動にかかる時間が省かれ、高速に行うことができ
る。そして、計算機Ａ１０１ａが停止状態から復帰し正
常に動作し始めると、計算機Ａ１０１ａ上では先ほど停
止したパッケージＡ１０３ａが起動し、待機状態とな
る。ここで、計算機Ａ１０１ａが障害から復帰した後
も、ただちにパッケージＢ１０３ｂからパッケージＡ１
０３ａに処理を切り替えるのではなく、パッケージＡ１
０３ａを待機状態とするため、新たに切り替え処理が発
生せず、システム全体として処理が高速に実行される。

【００５７】以上のように、この実施の形態の構成によ
れば、クラスタシステム上で運転／待機といったモード
により管理される２重系のシステムを構築することがで
き、パッケージの再起動を行うよりも短い時間で切り替
えを行うことができる。

【００５８】実施の形態１０．本発明の第１０の実施の
形態について、図２７〜図３０に基づいて説明する。本
実施形態は、図１に示したクラスタシステムのマネージ
ャ１０５の代わりに用いられ、各パッケージ１０３の出
力を管理する機能を有するマネージャを備えたものであ
る。本実施形態におけるマネージャの構成を図２７に示
す。図２７において、図２３と同一の符号は同一又は相
当の部分を表す。出力管理機構２７０１は、通知処理機
構２３０１からのリソース状態変化通知（Ｄ２３０２）
を受け、管理テーブル２７０２を参照／更新し、出力抑
止機構（２７０３）に出力抑止／解除要求を送る（Ｄ２
７０２）機構である。出力抑止機構２７０３は、出力管
理機構２７０１からの出力抑止／解除要求（Ｄ２７０
２）を受信し、クラスタデーモン１０２またはパッケー
ジ１０３に対して出力抑止／解除要求を送信する（Ｄ２
７０３）機構である。

【００５９】図２８は管理テーブル２７０２の記憶内容
の例を示す。管理テーブル２７０２には、パッケージ名
と出力抑止の状態、例えば抑止、解除が保持されてい
る。図２９は、図２７のマネージャ１０５の処理を説明
するフローチャートである。

【００６０】次に、図２９に基づいて、この実施の形態
のマネージャ１０５の動作について説明する。ステップ
２９０１において、出力管理機構２７０１は管理テーブ
ル２７０２の初期化を行う。次に、ステップ２９０２に
おいて、通知処理機構２３０１はクラスタデーモン１０
２からのリソース状態変化通知（Ｄ２３０１）を待ち、
受信したら出力抑止機構２７０３へリソース状態変化通
知（Ｄ２３０１）を送信する。続いて、ステップ２９０
３において、出力管理機構２７０１はリソース状態変化
通知（Ｄ２３０１）の種類を判別する。リソース状態変
化通知（Ｄ２３０１）が計算機１０１の起動である場合
にはステップ２９０７へ進み、計算機１０１の停止であ
る場合にはステップ２９０４へ進む。計算機の停止であ
った場合、ステップ２９０４において、出力管理機構２
７０１は、管理テーブル２７０２を更新し、停止した計
算機１０５上のすべてのパッケージ１０３にかかる出力
抑止状態を「抑止」に書き換える。

【００６１】次に、ステップ２９０５において、出力管
理機構２７０１は、出力抑止状態が「抑止」のパッケー
ジ１０３があるかを調べる。このとき、複数種類のパッ
ケージ１０３が計算機上で実行されている場合には、抑
止したパッケージ１０３と同種類のパッケージ１０３で
あって出力抑止状態が「抑止」であるパッケージ１０３
があるかを調べる。そのために、図２８に示した管理テ
ーブル２７０２に、パッケージ１０３が実行されている
計算機の情報及びパッケージ１０３の種類の情報を追加
してもよい。ステップ２９０５で、出力抑止状態が「抑
止」のパッケージ１０３がなかった場合にはステップ２
９０２に戻る。ここで、出力抑止状態が「抑止」のパッ
ケージ１０３がなかった場合には、運転している他の計
算機１０１上で、ステップ２９０４において抑止された
パッケージ１０３と同種類のパッケージを起動してもよ
い。

【００６２】出力抑止状態が「抑止」のパッケージ１０
３があった場合には、ステップ２９０６において、出力
管理機構２７０１は、出力抑止機構２７０３へ「解除」
を指示する出力抑止解除要求（Ｄ２７０２）を送る。そ
して、出力抑止機構２７０３がクラスタデーモン１０２
を介し、ステップ２９０５で見つけたパッケージ１０３
へ出力抑止解除要求（Ｄ２７０３）を送信することによ
り、出力が抑止されていたパッケージ１０３が出力を開
始する。

【００６３】次に、ステップ２９１０において、出力管
理機構２７０１は管理テーブル２７０２を更新する。す
なわち、ステップ２９０６で出力抑止解除を指示したパ
ッケージ１０３についての管理テーブル２７０２の出力
抑止状態を「解除」に書き換える。ステップ２９１０が
終了すると、ステップ２９０２に戻る。

【００６４】一方、ステップ２９０３で通知の種類が計
算機１０１の起動であると判断された場合には、ステッ
プ２９０７において、出力管理機構２７０１は出力抑止
機構２７０３に出力抑止解除要求（Ｄ２７０２）を送
り、起動した計算機１０１上において、パッケージ１０
３を出力が抑止された状態で起動する。次に、ステップ
２９０８において、管理テーブル２７０２を参照し、出
力抑止状態が「解除」のパッケージ１０３があるかどう
かを調べる。ここで、複数種類のパッケージ１０３が存
在する場合では、ステップ２９０７で起動したパッケー
ジ１０３と同種類のパッケージ１０３であって出力抑止
状態が「解除」であるパッケージ１０３があるかどうか
を調べる。

【００６５】出力抑止状態が「解除」であるパッケージ
１０３がある場合には、ステップ２９１０において、出
力管理機構２７０１は管理テーブル２７０２を更新す
る。すなわち、ステップ２９０７で起動したパッケージ
１０３についての管理テーブル２７０２の出力抑止状態
を「抑止」に書き換える。ステップ２９１０が終了する
と、ステップ２９０２に戻る。

【００６６】一方、出力抑止状態が「解除」であるパッ
ケージ１０３がない場合には、ステップ２９０９におい
て、出力管理機構２７０１は、出力抑止機構２７０３へ
「解除」を指示する出力抑止解除要求（Ｄ２７０２）を
送る。そして、出力抑止機構２７０３がクラスタデーモ
ン１０２を介し、ステップ２９０８で見つけたパッケー
ジ１０３に出力抑止解除要求（Ｄ２７０２）を送信する
ことにより、出力が抑止されていたパッケージ１０３が
出力を開始する。次に、ステップ２９１０において、出
力管理機構２７０１は管理テーブル２７０２を更新す
る。すなわち、ステップ２９０９で出力抑止解除を指示
したパッケージ１０３についての管理テーブル２７０２
の出力抑止状態を「解除」に書き換える。ステップ２９
１０が終了すると、ステップ２９０２に戻る。

【００６７】図３０はこの実施の形態の動作の一例を説
明する図である。図３０において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図３
０（a）に示すように、第１の計算機である計算機Ａ１
０１ａ上で第１のパッケージであるパッケージＡ１０３
ａが実行されており、第２の計算機である計算機Ｂ１０
１ｂ上で第２のパッケージであるパッケージＢ１０３ｂ
が実行されており、パッケージＡ１０３ａは出力を行っ
ている、すなわち出力抑止解除状態であり、パッケージ
Ｂ１０３ｂは出力が抑止され、すなわち出力抑止状態で
ある。但し、パッケージＡ１０３ａとパッケージＢ１０
３ｂは、同じ入力データを受け取り、同様に動作してい
る。図３０（a）に示す状態で、図３０（b）に示すよう
に計算機Ａ１０１ａが停止したとすると、上述のように
マネージャ１０５が動作し、図３０（c）に示すよう
に、ただちに計算機Ｂ１０１ｂ上で出力を抑止していた
パッケージＢ１０３ｂが出力を開始する。このとき、パ
ッケージＢ１０３ｂはパッケージＡ１０３ａと同様に動
作しているため、切り替えは一瞬で完了し、実施の形態
９に示したシステムよりもシステムの回復時間が速いと
いう特徴がある。そして、計算機Ａ１０１ａが停止状態
から復帰し正常に動作し始めると、計算機Ａ１０１ａ上
では先ほどダウンしたパッケージＡ１０３ａが起動し、
再び動作し始める。このとき、出力は抑止された状態で
動作する。ここで、計算機Ａ１０１ａが障害から復帰し
た後も、ただちにパッケージＢ１０３ｂからパッケージ
Ａ１０３ａに処理を切り替えるのではなく、パッケージ
Ａ１０３ａを出力抑止状態とするため、新たに切り替え
処理が発生せず、システム全体として処理が高速に実行
される。

【００６８】ここで、出力制御手段は、出力抑止、出力
抑止解除を行う手段であり、パッケージプログラムに設
けてもよいし、パッケージプログラムとは別のプロセ
ス、又はスレッドで実行されるプログラムであってもよ
い。パッケージ１０３が別のパッケージ１０３等の他の
プロセス、スレッド、若しくは周辺機器等のハードウェ
アコントローラと交信する場合には、出力制御手段を介
して交信を行うようにする。

【００６９】以上のように、この実施の形態の構成によ
れば、クラスタシステム上でFree Run Dualシステムを
構築することができ、パッケージの再起動を行うよりも
短い時間で切り替えを行うことができる。

【００７０】実施の形態１１．本発明の第１１の実施の
形態について、図３１〜図３４に基づいて説明する。本
実施形態は、図１に示したクラスタシステムのマネージ
ャ１０５の代わりに用いられ、各パッケージをモードで
管理する機能を有するマネージャを備えたものである。
本実施形態におけるマネージャの構成を図３１に示す。
図３１において、パッケージ管理機構３１０１は、通知
処理機構２３０１からのリソース状態変化通知（Ｄ２３
０２）を受け、管理テーブル３１０２を参照／更新し、
パッケージ制御機構３１０３にパッケージ制御要求（Ｄ
３１０２）を送信する機構である。パッケージ制御機構
３１０３は、パッケージ管理機構３１０１からのパッケ
ージ制御要求（Ｄ３１０２）を受信し、クラスタデーモ
ン１０２またはパッケージ１０３に対してパッケージ制
御要求（Ｄ３１０３）を送信する機構である。

【００７１】図３２は管理テーブル３１０２の記憶内容
の例を示す。管理テーブル３１０２には、図３２(a)に
示すように、パッケージ名、モードの状態、実行計算
機、グループ名が記憶されている第１のテーブルと、図
３２(b)に示すように各計算機の動作状態、例えば「運
転」、「停止」の情報が記憶されている第２のテーブル
が保持されている。ここで、モードの状態の情報は例え
ば「運転」，「停止」，「待機」等の情報であり、実行
計算機の情報はパッケージ名で特定されるパッケージ１
０３が、どの計算機１０１で実行されているかを示す情
報、グループ名は、パッケージの種類を示す情報であ
り、同一のグループ名が指定されたパッケージ同士は、
他のパッケージの処理を引き継ぐことができる。図３３
は、図３１のマネージャ１０５の処理を説明するフロー
チャートである。

【００７２】次に、図３３に基づいて、マネージャ１０
５の動作について説明する。ステップ３２０１におい
て、パッケージ管理機構３１０１は管理テーブル３１０
２の初期化を行う。次に、ステップ３２０２において、
通知処理機構２３０１はクラスタデーモン１０２からの
リソース状態変化通知（Ｄ２３０１）を待ち、受信した
らパッケージ管理機構３１０１へリソース状態変化通知
（Ｄ２３０２）を送信する。続いて、ステップ３２０３
において、パッケージ管理機構３１０１はリソース状態
変化通知（Ｄ２３０２）の種類を判別する。リソース状
態変化通知（Ｄ２３０２）が計算機１０１の起動である
場合にはステップ３２０８へ進み、計算機１０１の停止
である場合にはステップ３２０４へ進む。計算機の停止
であった場合、ステップ３２０４において、パッケージ
管理機構３１０１は、管理テーブル３１０２を更新し、
停止した計算機１０５上で運転または待機していたすべ
てのパッケージ１０３のモードを「停止」に書き換え
る。

【００７３】次に、ステップ３２０５において、停止し
たパッケージのグループと同一のグループ内でモードが
「待機」のパッケージ１０３があるかを調べる。ステッ
プ３２０５で、モードが「待機」のパッケージ１０３が
なかった場合にはステップ３２０８に跳ぶ。

【００７４】モードが「待機」のパッケージ１０３があ
った場合には、ステップ３２０６において、パッケージ
管理機構３１０１は、パッケージ制御機構３１０３へ
「運転」を指示するパッケージ制御要求（Ｄ３１０２）
を送る。そして、パッケージ制御機構３１０３がクラス
タデーモン１０２を介し、ステップ３２０５で見つけた
パッケージ１０３へパッケージ制御要求（Ｄ３１０２）
を送信することにより、待機していたパッケージ１０３
を運転させる。

【００７５】次に、ステップ３２０７において、パッケ
ージ管理機構３１０１は管理テーブル３１０２を更新す
る。すなわち、ステップ３２０６で運転を指示したパッ
ケージ１０３についての管理テーブル３１０２のモード
を「運転」に書き換える。ステップ３２１０が終了する
と、ステップ３２０２に戻る。

【００７６】続いて、ステップ３２０８において、パッ
ケージ管理機構３１０１は管理テーブル３１０２を参照
し、モードが「停止」であるパッケージを実行すること
ができる計算機１０１があるか否かを判断する。計算機
１０１がある場合には次のステップ３２０９に移り、な
い場合にはステップ３２１２へ跳ぶ。

【００７７】ステップ３２０９において、パッケージ管
理機構３１０１はパッケージ制御機構３１０３へ「待
機」を指示するパッケージ制御要求（Ｄ３１０２）を送
る。そして、パッケージ制御機構３１０３がステップ３
２０８で見つけた計算機１０１のクラスタデーモン１０
２へパッケージ制御要求（Ｄ３１０３）を送信する。ク
ラスタデーモン１０２は、「待機」を指示するパッケー
ジ制御要求（Ｄ３１０３）を受け取ると、目的のパッケ
ージ１０３を待機状態で起動させる。次に、ステップ３
２１０において、パッケージ管理機構３１０１は管理テ
ーブル３１０２を参照し、ステップ３２０９で起動した
パッケージのグループと同一のグループでにモードが
「運転」であるパッケージがあるか否かを調べ、ある場
合にはステップ３２１２へ跳び、ない場合には、次のス
テップ３２１１へ移る。

【００７８】次にステップ３２１１において、パッケー
ジ管理機構３１０１はパッケージ制御機構３１０３へ
「運転」を指示するパッケージ制御要求（Ｄ３１０２）
を送る。そして、パッケージ制御機構３１０３が、ステ
ップ３２０９で起動したパッケージ１０３を管理するク
ラスタデーモン１０２へパッケージ制御要求（Ｄ３１０
３）を送信する。クラスタデーモン１０２は、「運転」
を指示するパッケージ制御要求（Ｄ３１０３）を受け取
ると、目的のパッケージ１０３の待機状態を解除し、運
転を開始させる。

【００７９】次に、ステップ３２１２において、パッケ
ージ管理機構３１０１は管理テーブル３１０２を更新す
る。すなわち、ステップ３２０９、ステップ３２１１で
変更されたパッケージ１０３の状態を管理テーブル３１
０２に反映させる。ステップ３２１２が終了すると、ス
テップ３２０２に戻る。

【００８０】図３４はこの実施の形態の動作の一例を説
明する図である。図３４において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図３
４（a）に示すように、第１の計算機である計算機Ａ１
０１ａ上で第１のパッケージであるパッケージＡ１０３
ａが運転されており、第２の計算機である計算機Ｂ１０
１ｂ上で第２のパッケージであるパッケージＢ１０３ｂ
が待機しており、パッケージＡ１０３ａとパッケージＢ
１０３ｂは同一のグループであるとする。図３４（a）
に示す状態で、図３４（b）に示すように計算機Ａ１０
１ａが停止したとすると、上述のようにマネージャ１０
５が動作し、図３４（c）に示すように、ただちに計算
機Ｂ１０１ｂ上で待機していたパッケージＢ１０３ｂが
実行、すなわち運転状態となり、パッケージＡ１０３ａ
の処理を引き継ぐ。このときパッケージＡ１０３ａから
パッケージＢ１０３ｂへの切り替わりは、パッケージＢ
１０３ｂが待機状態で待っていため、起動にかかる時間
が省かれ、高速に行うことができる。そして、第３の計
算機である別の計算機Ｃ１０１ｃ上では先ほど停止した
パッケージＡ１０３ａと同一のパッケージ１０３が起動
し、待機状態となる。

【００８１】以上のように、この実施の形態の構成によ
れば、クラスタシステム上で運転／待機といったモード
により管理される２重系のシステムを構築することがで
き、パッケージの再起動を行うよりも短い時間で切り替
えを行うことができる。さらに、この実施の形態の構成
によれば、縮退運転時間を短くすることができるという
効果がある。すなわち、従来の２重系のシステムでは、
片方の計算機が停止した場合、その計算機の復旧作業を
行っている間は、１重系となり、その間にもう一方の計
算機が停止するとシステムダウンとなったが、この実施
の形態によれば、一方のパッケージが停止した場合、停
止したパッケージは他の計算機で起動されるため、１重
系となる時間はパッケージの再起動時間のみとなり、多
重障害によるシステムダウンを避けることができ、シス
テムの信頼性を高めることができる。

【００８２】実施の形態１２．本発明の第１２の実施の
形態について、図３５〜図３７に基づいて説明する。本
実施形態のマネージャ１０５の構成は、図３１に示した
ものと基本的に同様であるが、以下に説明するように各
構成で実行される処理が異なる。

【００８３】まず、管理テーブル３１０２について説明
する。図３５は管理テーブル３１０２の記憶内容の例を
示す。この実施の形態の管理テーブル３１０２には、図
３５(a)に示すように、パッケージ名、そのパッケージ
が実行されている実行計算機名が記憶された第３のテー
ブルと、図３５(b)に示すように各計算機の動作状態、
例えば「運転」、「停止」の情報が記憶されている第２
のテーブルが保持されている。

【００８４】次に、図３３に基づいて、マネージャ１０
５の動作について説明する。図３３は、図３１のマネー
ジャ１０５の処理を説明するフローチャートである。ス
テップ３５０１において、パッケージ管理機構３１０１
は管理テーブル３１０２の初期化を行う。次に、ステッ
プ３５０２において、通知処理機構２３０１はクラスタ
デーモン１０２からのリソース状態変化通知（Ｄ２３０
１）を待ち、受信したらパッケージ管理機構３１０１へ
リソース状態変化通知（Ｄ２３０２）を送信する。続い
て、ステップ３５０３において、パッケージ管理機構３
１０１はリソース状態変化通知（Ｄ２３０２）の種類を
判断する。リソース状態変化通知（Ｄ２３０２）が計算
機１０１の起動である場合にはステップ３５０７へ進
み、計算機１０１の停止である場合にはステップ３５０
４へ進む。計算機の停止であった場合、ステップ３５０
４において、パッケージ管理機構３１０１は、管理テー
ブル３１０２を参照し、空き計算機１０１を検索する。
空き計算機１０１が見つかった場合には、次のステップ
３５０６へ進み、空き計算機１０１がなかった場合に
は、ステップ３５１０へ跳ぶ。

【００８５】次に、ステップ３５０６において、パッケ
ージ管理機構３１０１は、パッケージ制御機構３１０３
へ「運転」を指示するパッケージ制御要求（Ｄ３１０
２）を送る。そして、パッケージ制御機構３１０３がス
テップ３５０５で見つけた計算機１０１のクラスタデー
モン１０２へ、「運転」を指示するパッケージ制御要求
（Ｄ３１０３）を送る。このパッケージ制御要求（Ｄ３
１０３）を受け取ったクラスタデーモン１０２は、停止
した計算機１０１上で実行されていたパッケージ１０３
と同一のパッケージ１０３を起動させ、パッケージ１０
３の実行を開始させる。次に、ステップ３５１０におい
て、パッケージ管理機構３１０１は管理テーブル３１０
２の内容を現在の計算機の状態に更新し、ステップ３５
０２へ戻る。

【００８６】一方、ステップ３５０３で通知が計算機１
０１の起動であると判断された場合には、ステップ３５
０７において、パッケージ管理機構３１０１は管理テー
ブル３１０２の内容を現在の計算機１０１の状態に更
新、すなわち、起動した計算機１０１にかかる状態の項
目を「運転」に書き換える。次に、ステップ３５０８に
おいて、停止しているパッケージ１０３があるかを、例
えば、実施の形態１１で説明した図３２(a)に示すよう
な第１のテーブルを参照することによって調べ、停止し
ているパッケージがある場合には、停止しているパッケ
ージ１０３を実行できる計算機１０１があるかを調べ
る。停止しているパッケージ１０３がない場合、若しく
は停止しているパッケージ１０３を実行できる計算機１
０３がない場合には、上述のステップ３５１０へ跳び、
停止しているパッケージ１０３があり、かつ停止してい
るパッケージ１０３を実行できる計算機１０１がある場
合には、次のステップ３５０９へ進む。

【００８７】ステップ３５０９において、パッケージ管
理機構３１０１は、パッケージ制御機構３１０３へ「運
転」を指示するパッケージ制御要求（Ｄ３１０２）を送
る。そして、パッケージ制御機構３１０３がステップ３
５０８で見つけた計算機１０１のクラスタデーモン１０
２へ、「運転」を指示するパッケージ制御要求（Ｄ３１
０３）を送信することにより、ステップ３５０８で見つ
けた計算機１０１上で、同じくステップ３５０８で見つ
けたパッケージ１０３を起動させるとともに、実行させ
る。ステップ３５０９が終了すると、上述のステップ３
５１０へ進む。

【００８８】図３７はこの実施の形態の動作の一例を説
明する図である。図３７において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図３
７（a）に示すように、計算機Ａ１０１ａ上でパッケー
ジＡ１０３ａが運転されており、計算機Ｂ１０１ｂ上で
パッケージＢ１０３ｂが運転されており、パッケージＡ
１０３ａとパッケージＢ１０３ｂは異なる種類のパッケ
ージ１０３であるとする。図３４（a）に示す状態で、
図３４（b）に示すように計算機Ａ１０１ａが停止した
とすると、上述のようにマネージャ１０５が動作し、パ
ッケージＡ１０３ａが空き計算機Ｎ１０１ｎ上で起動さ
れ、実行される。その後、図３４（c）に示すように、
計算機Ａ１０１ａが起動すると、今度は計算機Ａ１０１
ａが空き計算機、すなわちバックアップ用の計算機とな
る。そして、図３７(d)に示すように、今度は計算機Ｂ
１０１ｂが故障等により停止すると、上述のようにマネ
ージャ１０５が動作し、計算機Ｂ１０１ｂ上で実行され
ていたパッケージＢ１０３ｂが、今度は空き計算機とな
っていた計算機Ａ１０１ａ上で起動され、実行される。

【００８９】以上のように、この実施の形態の構成によ
れば、クラスタシステム上でシステムの状態によりパッ
ケージの移動先を変更するような多重系システムを構築
することができる。また、この実施の形態では、図３７
(c)のように停止した計算機Ａ１０１ａが回復しても、
計算機Ａ１０１ａをバックアップして、パッケージＡ１
０３ａの実行を行った計算機Ｎ１０１ｎがそのまま実行
を続け、回復した計算機Ａ１０１ａは今度は他の計算機
のバックアップに回る。そのため、回復した計算機Ａ１
０１ａが再びパッケージＡ１０３ａを実行し、計算機Ｎ
１０１ｎが再びバックアップに回るようなシステムに比
べ、計算機の切り替え回数が減り、システム全体の処理
パフォーマンスが向上する。すなわち、処理を高速に実
行するとことができる。

【００９０】実施の形態１３．本発明の第１３の実施の
形態について、図３８及び図３９に基づいて説明する。
本実施形態のマネージャ１０５の構成は、図３１に示し
たものと基本的に同様であり、その処理は基本的に図３
６を用いて説明した実施の形態１２と同様である。ただ
し、以下に説明するようにパッケージ１０３を起動する
計算機１０１を求める処理、すなわち、ステップ３５０
４及びステップ３５０８が異なる。

【００９１】まず、この実施の形態の管理テーブル３１
０２について説明する。図３８に管理テーブル３１０２
の記憶内容の例を示す。この実施の形態の管理テーブル
３１０２には、図３８(a)に示すように、パッケージ
名、そのパッケージが実行されている実行計算機名、及
びそのパッケージのグループ名が記憶された第４のテー
ブルと、図３８(b)に示すように各計算機の動作状態、
例えば「運転」、「停止」の情報が記憶されている第２
のテーブルが保持されている。

【００９２】次に、この実施の形態のマネージャ１０５
の動作について説明する。上述のように、この実施の形
態のマネージャ１０５の動作は、基本的に実施の形態１
２と同様であるため、異なる処理、すなわち、ステップ
３５０４及びステップ３５０８について以下に説明す
る。この実施の形態のステップ３５０４においては、パ
ッケージ管理機構３１０１は、管理テーブル３１０２を
参照し、空き計算機ではなく、停止した計算機１０１上
で実行されていたパッケージ１０３と同一のグループの
パッケージ１０３が実行されていない計算機１０１を検
索する。同一のグループのパッケージ１０３が実行され
ていない計算機１０１が見つかった場合には、次のステ
ップ３５０６へ進み、見つからなかった場合には、ステ
ップ３５１０へ跳ぶ。

【００９３】また、この実施の形態のステップ３５０８
においては、停止しているパッケージ１０３があるか
を、例えば、実施の形態１１で説明した図３２(a)に示
すような第１のテーブルを参照することによって調べ、
停止しているパッケージがある場合には、停止している
パッケージ１０３を実行できる計算機１０１があるかを
調べる。停止しているパッケージ１０３がない場合、若
しくは停止しているパッケージ１０３を実行できる計算
機１０３がない場合には、上述のステップ３５１０へ跳
び、停止しているパッケージ１０３があり、かつ停止し
ているパッケージ１０３を実行できる計算機１０１があ
る場合には、次のステップ３５０９へ進む。ここで、実
行できる計算機１０１として、空き計算機１０１ではな
く、停止しているパッケージ１０３と同一のグループの
パッケージ１０３が実行されていない計算機１０１を見
つける。

【００９４】図３９はこの実施の形態の動作の一例を説
明する図である。図３９において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図３
９（a）に示すように、計算機Ａ１０１ａ上でパッケー
ジＡ１０３ａが運転されており、計算機Ｂ１０１ｂ上で
パッケージＢ１０３ｂが運転されており、パッケージＡ
１０３ａとパッケージＢ１０３ｂは、同一グループに指
定されたパッケージであり、一つのまとまった処理をそ
れぞれのパッケージで分散して行う、すなわち並列処理
するパッケージであり、計算機Ａ１０１ａで実行されて
いるパッケージＣ１０３ｃは、パッケージＡ１０３ａと
パッケージＢ１０３ｂの出力をまとめるためのパッケー
ジであるとする。図３４（a）に示す状態で、図３４
（b）に示すように計算機Ａ１０１ａが停止したとする
と、上述のようにマネージャ１０５が動作し、パッケー
ジＡ１０３ａが同一グループのパッケージＢ１０３ｂが
実行されている計算機Ｂ１０１ｂではなく、同一グルー
プのパッケージが実行されていない計算機Ｎ１０１ｎで
起動され、実行される。

【００９５】以上のように、この実施の形態の構成によ
れば、クラスタシステム上でロードシェアシステムを構
築することができ、負荷の分散を行うことができる。す
なわち、並行処理を行っている複数のパッケージ同士を
同一の計算機１０１上で起動しないことにより、切り替
え処理が実行された後も並列処理による高速処理を継続
することができる。

【００９６】実施の形態１４．本発明の第１４の実施の
形態について、図４０〜図４２に基づいて説明する。本
実施形態のマネージャ１０５の構成は、図３１に示した
ものと基本的に同様であるが、以下に説明するように各
構成で実行される処理が異なる。

【００９７】まず、管理テーブル３１０２について説明
する。図４０は管理テーブル３１０２の記憶内容の例を
示す。この実施の形態の管理テーブル３１０２には、図
４０(a)に示すように、パッケージ名、そのパッケージ
が実行されている実行計算機名、及びそのパッケージの
優先順位が記憶された第５のテーブルと、図４０(b)に
示すように各計算機の動作状態、例えば「運転」、「停
止」の情報が記憶されている第２のテーブルが保持され
ている。

【００９８】次に、図４１に基づいて、マネージャ１０
５の動作について説明する。図４１は、図３１のマネー
ジャ１０５の処理を説明するフローチャートである。ス
テップ４００１において、パッケージ管理機構３１０１
は管理テーブル３１０２の初期化を行う。次に、ステッ
プ４００２において、通知処理機構２３０１はクラスタ
デーモン１０２からのリソース状態変化通知（Ｄ２３０
１）を待ち、受信したらパッケージ管理機構３１０１へ
リソース状態変化通知（Ｄ２３０２）を送信する。続い
て、ステップ４００３において、パッケージ管理機構３
１０１はリソース状態変化通知（Ｄ２３０２）の種類を
判断する。リソース状態変化通知（Ｄ２３０２）が計算
機１０１の起動である場合にはステップ４００４へ進
み、計算機１０１の停止である場合にはステップ４００
７へ進む。

【００９９】一方、ステップ４００３で通知が計算機１
０１の起動であると判断された場合には、ステップ４０
０４において、パッケージ管理機構３１０１は管理テー
ブル３１０２を参照し、停止しているパッケージ１０３
を検索する。ここで、停止しているパッケージ１０３を
検索する方法の一例としては、図４０(a)の第５のテー
ブルの実行計算機で指定された計算機が、図４０(b)の
第２のテーブルにおいて「停止」となっているパッケー
ジ１０３、若しくは、図４０(a)の第５のテーブルにパ
ッケージ名及び優先順位は指定されているものの、実行
計算機の項目にはどの計算機も指定されていないパッケ
ージ１０３を検索する方法がある。

【０１００】次に、ステップ４００５において、パッケ
ージ管理機構３１０１はステップ４００４で停止してい
るパッケージが見つかったか否かを判断する。ここで、
停止しているパッケージがあった場合には、次のステッ
プ４００６へ進み、ない場合にはステップ４０１２へ跳
ぶ。

【０１０１】次に、ステップ４００６において、パッケ
ージ管理機構３１０１は、まず、停止しているパッケー
ジ１０３のうち一番優先順位の高いパッケージを探し、
パッケージ制御機構３１０３へ一番優先順位の高いパッ
ケージ１０３の「運転」を指示するパッケージ制御要求
（Ｄ３１０２）を送る。そして、パッケージ制御機構３
１０３が、新たに起動した計算機１０１のクラスタデー
モン１０２へ、「運転」を指示するパッケージ制御要求
（Ｄ３１０３）を送信することにより、新たに起動した
計算機１０１上で、停止しているパッケージ１０３のう
ち一番優先順位の高いパッケージ１０３が実行される。
ステップ４００６が終了すると、次のステップ４０１２
へ移る。

【０１０２】次に、ステップ４０１２において、パッケ
ージ管理機構３１０１は管理テーブル３１０２の内容
を、現在の計算機及びパッケージの状態に合わせて更新
し、ステップ４００２へ戻る。

【０１０３】一方、ステップ４００３で計算機の停止で
あると判断された場合、ステップ４００７において、パ
ッケージ管理機構３１０１は、管理テーブル３１０２を
参照し、停止した計算機１０１上で動作していたパッケ
ージを実行可能な計算機１０１を検索する。実行可能な
計算機１０１が見つかった場合には、次のステップ４０
１１へ進み、実行可能な計算機１０１がなかった場合に
は、ステップ４００９へ跳ぶ。ここで、パッケージ１０
３を実行できるか否かは、そのパッケージの実行に必要
なリソースと、対象計算機１０１の残りリソースを比較
することにより行い、計算機１０１にパッケージの実行
に必要なリソースが十分に残っている場合には実行可能
であるとし、残っていない場合には実行不能と判断す
る。

【０１０４】実行可能なパッケージ１０３がない場合に
は、ステップ４００９において、パッケージ管理機構３
１０１は管理テーブル３１０２を参照し、停止したパッ
ケージ１０３よりも優先順位の低いパッケージ１０３で
停止可能なパッケージ１０３があるか否かを調べる。停
止可能なパッケージがあった場合には、ステップ４０１
０へ進み、ない場合には上述のステップ４０１２へ進
む。停止可能なパッケージがある場合には、ステップ４
０１０において、パッケージ管理機構３１０１は、パッ
ケージ制御機構３１０３へ「停止」を指示するパッケー
ジ制御要求（Ｄ３１０２）を送る。そして、パッケージ
制御機構３１０３がステップ４００９で見つけたパッケ
ージ１０３を管理するクラスタデーモン１０２へ、「停
止」を指示するパッケージ制御要求（Ｄ３１０３）を送
る。このパッケージ制御要求（Ｄ３１０３）を受け取っ
たクラスタデーモン１０２は、ステップ４００９で見つ
かったパッケージ１０３を停止させ、そのパッケージが
使用していたリソースを開放させる。このステップ４０
１０が終了すると、ステップ４０１１へ移る。

【０１０５】ステップ４０１１においては、パッケージ
管理機構３１０１は、パッケージ制御機構３１０３へ、
停止したパッケージ１０３の「運転」を指示するパッケ
ージ制御要求（Ｄ３１０２）を送る。そして、パッケー
ジ制御機構３１０３が、ステップ４００８で見つけた計
算機１０１、若しくはステップ４０１０でパッケージ１
０３を停止させた計算機１０１のクラスタデーモン１０
２へ、「運転」を指示するパッケージ制御要求（Ｄ３１
０３）を送る。このパッケージ制御要求（Ｄ３１０３）
を受け取ったクラスタデーモン１０２は、停止したパッ
ケージ１０３を起動し、運転を開始させる。ステップ４
０１１が終了すると、上述のステップ４０１２へ移る。

【０１０６】図４２はこの実施の形態の動作の一例を説
明する図である。図４２において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図４
２（a）に示すように、計算機Ａ１０１ａ〜計算機Ｎ１
０１ｎのそれぞれでパッケージＡ１０３ａ〜パッケージ
Ｎ１０１ｎが運転されており、パッケージＡ１０３ａ〜
パッケージＮ１０１ｎはそれぞれ異なる種類のパッケー
ジ１０３であるとする。各パッケージの優先順位は、パ
ッケージＡ１０３ａが最も高く、その次にパッケージＢ
１０３ｂ、パッケージＮ１０１ｎが最も低いとする。図
４２（a）に示す状態で、図３４（b）に示すように第１
の計算機である計算機Ａ１０１ａが停止したとすると、
上述のようにマネージャ１０５が動作し、計算機Ｎ１０
１ｎ上で、パッケージＡ１０３ａよりも優先順位の低い
パッケージＮ１０１ｎが停止され、代わりに停止したパ
ッケージＡ１０３ａが起動され、実行される。

【０１０７】その後、図３４（c）に示すように、計算
機Ａ１０１ａが回復し、起動すると、今度は計算機Ａ１
０１ａ上で、停止していたパッケージＮ１０１ｎが実行
される。そして、今度は図３７(d)に示すように、計算
機Ｂ１０１ｂが故障等により停止すると、上述のように
マネージャ１０５が動作し、計算機Ａ１０１ａで実行さ
れていた優先順位の低いパッケージＮ１０１ｎが停止
し、その代わりに優先順位の高い停止したパッケージＢ
１０３ｂが起動され、実行される。

【０１０８】ここで、さらに図４２(e)に示すように、
計算機Ｎ１０１ｎまでもが停止すると、パッケージＡ１
０３ａはパッケージＢ１０３ｂよりも優先順位が高いた
め、計算機Ａ１０１ａ上で実行されていたパッケージＢ
１０３ｂが停止し、代わりにパッケージＡ１０３ａが計
算機Ａ１０１ａ上で起動され、実行される。その後、図
４２(f)に示すように、計算機Ｂ１０１ｂが回復する
と、停止しているパッケージの中で一番優先順位の高い
パッケージＢ１０３ｂが、計算機Ｂ１０１ｂ上で起動さ
れ、実行される。

【０１０９】以上のように、この実施の形態の構成によ
れば、クラスタシステム上で多重縮退システムを構築す
ることができ、障害発生時にも重要な処理を優先的に行
うことができる。

【０１１０】実施の形態１５．本発明の第１５の実施の
形態について、図４３〜図４６に基づいて説明する。本
実施形態のマネージャ１０５の構成は、図３１に示した
ものと基本的に同様であるが、以下に説明するように各
構成で実行される処理が異なる。

【０１１１】まず、管理テーブル３１０２について説明
する。図４３は管理テーブル３１０２の記憶内容の例を
示す。この実施の形態の管理テーブル３１０２には、図
４３(a)に示すように、パッケージ名、そのパッケージ
が実行されている実行計算機名、のパッケージの優先順
位、及びそのパッケージの実行に必要な負荷が記憶され
た第６のテーブルと、図４３(b)に示すように各計算機
の動作状態、例えば「運転」、「停止」の情報、及び各
計算機の最大許容負荷が記憶されている第７のテーブル
が保持されている。負荷の例としてはリソース、例え
ば、メモリ、ＣＰＵ時間等がある。

【０１１２】次に、図４４に基づいて、マネージャ１０
５の動作について説明する。図４１は、図３１のマネー
ジャ１０５の処理を説明するフローチャートである。ス
テップ４３０１において、パッケージ管理機構３１０１
は管理テーブル３１０２の初期化を行う。次に、ステッ
プ４３０２において、通知処理機構２３０１はクラスタ
デーモン１０２からのリソース状態変化通知（Ｄ２３０
１）を待ち、受信したらパッケージ管理機構３１０１へ
リソース状態変化通知（Ｄ２３０２）を送信する。続い
て、ステップ４３０３において、パッケージ管理機構３
１０１はリソース状態変化通知（Ｄ２３０２）の種類を
判断する。リソース状態変化通知（Ｄ２３０２）が計算
機１０１の起動若しくは停止である場合にはステップ４
３０９へ進み、計算機１０１の負荷１００％以上を伝え
る通知である場合には次のステップ４３０４へ進む。

【０１１３】ステップ４３０４において、負荷が１００
％以上となった計算機１０１（以下、この実施の形態に
おいて、過負荷計算機という）上で動作していたパッケ
ージ１０３であって、処理を行っていないパッケージ１
０３のうち優先度の低いものを選択し、そのパッケージ
１０３（以下、この実施の形態において選択パッケージ
という）について、以下のステップ４３０５〜４３０８
の処理を行う。

【０１１４】まず、ステップ４３０５において、選択パ
ッケージを停止する。すなわち、パッケージ管理機構３
１０１は、パッケージ制御機構３１０３へ選択パッケー
ジの停止を指示するパッケージ制御要求（Ｄ３１０２）
を送る。そして、パッケージ制御機構３１０３が、当該
選択パッケージを管理するクラスタデーモン１０２へ
「停止」を指示するパッケージ制御要求（Ｄ３１０３）
を送信することにより、この要求を受け取ったクラスタ
デーモン１０２が選択パッケージ停止させる。ここで、
選択パッケージを停止させることにより、過負荷計算機
のリソースが開放され、過負荷計算機の負荷が減少す
る。

【０１１５】次に、ステップ４３０６において、パッケ
ージ管理機構３１０１は、選択パッケージにかかる管理
テーブル２３０３の項目を更新、すなわち「停止」に書
き換える。ステップ４３０７において、過負荷計算機上
で動作する全パッケージについて、上述のステップ４３
０４〜４３０６の処理を行ったかを判断し、処理した場
合には、ステップ４３１０へ進み、処理していない場合
には、次のステップ４３０８へ移る。

【０１１６】次のステップ４３０８において、過負荷計
算機の負荷が１００以上であるかが調べられる。１００
％以上である場合には、上述ステップ４３０４へ戻り、
１００％未満である場合には、ステップ４３１０へ移
る。１００％以上であるか否かは、パッケージ管理機構
３１０１が、管理テーブル２３０３を参照し、過負荷計
算機で運転或いは待機しているパッケージの負荷の合計
と、過負荷計算機の最大許容負荷とを比較することによ
り判断する。

【０１１７】一方、ステップ４３０３で通知の種類が計
算機の起動若しくは停止であると判断された場合には、
ステップ４３０９において、パッケージ管理機構３１０
１は、管理テーブル２３０３を更新し、当該計算機の項
目を通知の内容に応じて、「運転」若しくは「停止」に
書き換える。次に、ステップ４３１０において、パッケ
ージ管理機構３１０１は管理テーブル３１０２を参照
し、停止しているパッケージ１０３のうち最も優先順位
の高いもの（以下、この実施の形態において、優先パッ
ケージという）を検索する。

【０１１８】次に、ステップ４３１１において、パッケ
ージ管理機構３１０１は、管理テーブル２３０３を参照
し、優先パッケージを実行できる計算機１０１を選択す
る。ここで、計算機１０１の選択は、優先パッケージの
実行に必要な負荷、各計算機１０１の最大許容負荷、並
びに、各計算機１０１において運転又は待機しているパ
ッケージにかかる負荷を基準にして行われる。実行でき
る計算機１０１がない場合には選択は行われず、実行で
きる計算機がないという結果が得られる。

【０１１９】続いて、ステップ４３１２において、ステ
ップ４３１１で実行可能な計算機１０１があったか否か
が判断され、あった場合には次のステップ４３１３に移
り、ない場合にはステップ４３１６へ移る。次のステッ
プ４３１３においては、ステップ４３１１で選択された
計算機１０１上で、優先パッケージが起動される。すな
わち、パッケージ管理機構３１０１は、パッケージ制御
機構３１０３へ優先パッケージの「運転」を指示するパ
ッケージ制御要求（Ｄ３１０２）を送る。そして、パッ
ケージ制御機構３１０３が、ステップ４３１１で選択さ
れた計算機１０１のクラスタデーモン１０２へ、「運
転」を指示するパッケージ制御要求（Ｄ３１０３）を送
信することにより、当該計算機１０１上で、停止してい
るパッケージ１０３のうち一番優先順位の高いパッケー
ジ１０３が実行される。

【０１２０】次に、ステップ４３１４において、パッケ
ージ管理機構３１０１は管理テーブル２３０３を更新
し、管理テーブル２３０３の優先パッケージにかかる項
目、すなわち実行計算機を更新する。次に、ステップ４
３１５において、パッケージ管理機構３１０１は停止し
ているパッケージ１０３すべてについて、上述４３１０
からの処理、すなわちステップ４３１０〜４３１８の処
理を行ったかを判断し、すべてのパッケージ１０３につ
いて処理した場合には、ステップ４３０２へ移り、新た
なリソース状態変化通知（Ｄ２３０１）が来るのを待
つ、すべてのパッケージ１０３について処理が終わって
いない場合には、ステップ４３１０に戻る。

【０１２１】一方、ステップ４３１２で実行可能な計算
機１０１がないと判断された場合には、ステップ４３１
６において、パッケージ管理機構３１０１は管理テーブ
ル３１０２を参照し、停止しているパッケージ１０３よ
りも優先順位の低いパッケージ１０３で停止可能なパッ
ケージ１０３があるか否かを調べる。停止可能なパッケ
ージがあった場合には、ステップ４３１７へ進み、ない
場合には上述のステップ４３１５へ進む。停止可能なパ
ッケージがある場合には、ステップ４３１７において、
パッケージ管理機構３１０１は、パッケージ制御機構３
１０３へ「停止」を指示するパッケージ制御要求（Ｄ３
１０２）を送る。そして、パッケージ制御機構３１０３
がステップ４３１６で見つけたパッケージ１０３を管理
するクラスタデーモン１０２へ、「停止」を指示するパ
ッケージ制御要求（Ｄ３１０３）を送る。このパッケー
ジ制御要求（Ｄ３１０３）を受け取ったクラスタデーモ
ン１０２は、ステップ４３１６で見つかったパッケージ
１０３を停止させ、そのパッケージが使用していたリソ
ースを開放させる。次に、ステップ４３１８において、
パッケージ管理機構３１０１は、管理テーブル２３０３
を更新し、ステップ４３１７で停止させたパッケージに
かかる項目を現在の状態に書き換える。ステップ４３１
１が終了すると、上述のステップ４３１１へ移り、上述
のような新たなリソースの開放、或いは優先パッケージ
の起動の処理を行う。

【０１２２】図４５はこの実施の形態の動作の一例を説
明する図である。図４５において、図１と同一の符号は
同一または相当の部分を表している。まず、最初に図４
５（a）に示すように、計算機Ａ１０１ａ〜計算機Ｎ１
０１ｎのそれぞれでパッケージＡ１０３ａ〜パッケージ
Ｆ１０１ｆが運転されており、パッケージＡ１０３ａ〜
パッケージＦ１０１ｆはそれぞれ異なる種類のパッケー
ジ１０３であるとする。各パッケージの優先順位は、パ
ッケージＡ１０３ａが最も高く、その次にパッケージＢ
１０３ｂ、以降順に、パッケージＣ１０１ｃ、パッケー
ジＤ１０１ｄ、パッケージＥ１０１ｅ、パッケージＦ１
０１ｆであるとする。また、パッケージＡ１０３ａは計
算機Ａ１０１ａの負荷の４０％を占めており、パッケー
ジＢ１０３ｂ〜パッケージＦ１０１ｆはそれぞれ順番
に、実行される計算機１０１の負荷の４０％、４０％、
２０％、２０％、２０％を占めている。図４５（a）に
示す状態で、図４５（b）に示すように第１の計算機で
ある計算機Ａ１０１ａがの負荷が１００％以上となった
とすると、上述のようにマネージャ１０５が動作し、図
４５(c)に示すように、計算機Ａ１０１ａで一番優先順
位の低い優先順位の低いパッケージＤ１０３ｄが停止
し、代わりに、負荷に余裕のある計算機Ｂ１０１ｂ上で
パッケージＤ１０３ｄが起動し、実行を開始する。

【０１２３】また、図４６は、この実施の形態の動作の
他の例を説明する図である。図４６において、図４５と
同一の符号は同一または相当の部分を表している。図４
６(a)に示す状態で、図４６(b)に示すように計算機Ａ１
０１ａが停止して、パッケージＡ１０３ａ及びパッケー
ジＤ１０３ｄが停止したとする。すると、上述のように
マネージャ１０５が動作し、図４６(c)に示すように、
停止したパッケージで優先順位の最も高いパッケージＡ
１０３ａが計算機Ｎ１０１ｎ上で起動し実行を開始す
る。このとき、優先順位の低いパッケージＦ１０３ｆは
停止する。一方、停止したパッケージの中で次に優先順
位の高いＤ１０１ｄは、負荷に余裕のある計算機Ｂ１０
１ｂで起動され、実行される。また、パッケージＦ１０
１ｆは負荷に余裕のある計算機１０１がなく、優先順位
も起動中の他のパッケージ１０３よりも低いため、起動
されない。

【０１２４】以上のように、この実施の形態の構成によ
れば、自動負荷分散システムを構築することができ、負
荷を自動的に分散し、重要な処理のレスポンスの劣化を
防ぐことができる。

【０１２５】実施の形態１６．本発明の第１６の実施の
形態について、図４７〜図４９に基づいて説明する。本
実施形態は、図１に示したクラスタシステムのマネージ
ャ１０５の代わりに用いられ、各パッケージに割り当て
るリソースの量を、各パッケージの優先順位に基づいて
管理する機能を有するマネージャを備えたものである。
本実施形態におけるマネージャの構成を図４７に示す。
図４７において、図２３と同一の符号は同一又は相当の
部分を表す。リソース割り当て管理機構４６０１は、通
知処理機構２３０１からのリソース状態変化通知（Ｄ２
３０１）を受け、管理テーブル４６０２を参照／更新
し、リソース割り当て制御機構４６０３にパッケージ制
御要求（Ｄ４６０３）を送信する機構である。リソース
割り当て制御機構４６０３は、リソース割り当て管理機
構４６０１からのパッケージ制御要求（Ｄ４６０２）を
受信し、クラスタデーモン１０２またはパッケージ１０
３に対してパッケージ制御要求（Ｄ４６０３）を送信す
ることにより、残りのリソースをパッケージの優先順位
に応じた量だけ、そのパッケージ１０３に割り当てる機
構である。

【０１２６】図４８は管理テーブル４６０２の記憶内容
の例を示す。管理テーブル４６０２には、図４８に示す
ように、パッケージ名、実行計算機、優先順位が記憶さ
れている第８のテーブルが保持されている。ここで、実
行計算機の情報はパッケージ名で特定されるパッケージ
１０３が、どの計算機１０１で実行されているかを示す
情報である。図４９は、図４７のマネージャ１０５の処
理を説明するフローチャートである。

【０１２７】次に、図４９に基づいて、マネージャ１０
５の動作について説明する。ステップ４８０１におい
て、リソース割り当て管理機構４６０１は管理テーブル
４６０２の初期化を行う。次に、ステップ４８０２にお
いて、通知処理機構２３０１はクラスタデーモン１０２
からのリソース状態変化通知（Ｄ２３０１）を待ち、受
信したらリソース割り当て管理機構４６０１へリソース
状態変化通知（Ｄ２３０２）を送信する。

【０１２８】続いて、ステップ４８０３において、リソ
ース割り当て管理機構４６０１は、リソース状態変化通
知（Ｄ２３０２）に応じて、管理テーブル４６０２を更
新する。ステップ４８０４において、クラスタシステム
内の複数の計算機１０１のうちで、まだステップ４８０
５〜ステップ４８０８の処理を行っていない計算機を１
つ選択する（以下、この実施の形態において、この選択
された計算機を選択計算機という）。そして、選択計算
機について、以下のステップ４８０４〜ステップ４８０
７の処理を行う。

【０１２９】まず、ステップ４８０５において、選択計
算機上で実行されているパッケージで、まだステップ４
８０６及びステップ４８０７の処理を行っていないパッ
ケージのうち優先順位の最も高いものを選択する（以
下、この実施の形態において、この選択されたパッケー
ジを選択パッケージという）。そして、選択パッケージ
について、以下のステップ４８０６及びステップ４８０
７の処理を行う。

【０１３０】ステップ４８０６において、選択パッケー
ジに割り当てるリソースの量を選択計算機のリソースの
残量から計算する。例えば、 ［割り当てるリソースの量］＝［リソースの残量×０．
５］ のような式により求める。そして、あらたなリソースの
残量を以下のように求める。 (新たな)［リソースの残量］＝［リソースの残量］−
[割り当てるリソースの量]

【０１３１】次に、ステップ２８０７において、リソー
ス割り当て管理機構４６０１は、リソース割り当て制御
機構４６０３へリソース割り当て制御要求（Ｄ４６０
２）を送り、リソース割り当て制御機構４６０３が、選
択計算機のクラスタデーモン１０２へリソース割り当て
制御要求（Ｄ４６０３）を送る。リソース割り当て制御
要求（Ｄ４６０３）を受け取ったクラスタデーモン１０
２は、選択パッケージにステップ４８０６で計算された
［割り当てるリソースの量］のリソースを割り当てて、
選択パッケージを起動し、実行させる。

【０１３２】続いて、ステップ４８０８において、選択
計算機上のすべてのパッケージ１０３について、上述ス
テップ４８０６〜ステップ４８０７の処理を実行したか
を判断し、実行していなかった場合には、ステップ４８
０５に戻り、上述の処理を繰り返す。一方、実行してい
た場合には、ステップ４８０９において、全計算機につ
いて、上述ステップ４８０４〜ステップ４８０８の処理
を実行したかを判断し、実行していない場合には、ステ
ップ４８０４に戻り上述の処理を繰り返す。実行した場
合には、ステップ４８０２に戻り、次のリソース状態変
化通知（Ｄ２３０１）を待つ。

【０１３３】なお、このステップ４８０９の処理が終了
すると、ステップ４８０４において、ステップ４８０５
〜ステップ４８０８の処理を行ったという情報はクリア
され、処理を行っていないものとして取り扱われる。そ
して、ステップ４８０２で新たにリソース状態変化通知
（Ｄ２３０１）を受け取った場合には、受け取る以前に
ステップ４８０５〜ステップ４８０７の処理を行った計
算機１０１についても、ステップ４８０５〜ステップ４
８０７の処理が実行される。ステップ４８０５のパッケ
ージ１０３の選択についても同様である。このようにし
て、クラスタシステムの最新のリソース状態に応じて、
パッケージ１０３にリソースを動的に割り当てる。

【０１３４】なお、ステップ４８０６の割り当てるリソ
ース量の計算式は、パッケージ１０３の優先順位に応じ
て、優先順位が高いほど多くのリソースが割り当てられ
るような式であれば、他の式を用いてもよい。例えば、 [割り当てるリソースの量]＝[リソースの残量]×（１／
［優先順位］）×０．８ のような式を用いてもよい。

【０１３５】以上の構成により、クラスタシステム内
で、重要な処理のレスポンスの劣化を防ぐことができ、
あまり重要でない処理の継続もすることができる。

【０１３６】

【発明の効果】本発明は、以上説明したように構成され
ているので、以下に示すような効果を奏する。

【０１３７】マネージャがクラスタ上の全リソースの監
視制御を一括して行ない、パッケージプログラムはマネ
ージャに対してのみアクセスすれば良いようにしたの
で、障害発生時においても計算機上の動作環境を意識す
る必要がない。

【０１３８】また、マネージャを１個のパッケージプロ
グラムとして作成するようにしたので、マネージャある
いはマネージャが動作している計算機上に障害が発生し
ても、容易に他の計算機上で代替動作させることができ
る。

【０１３９】また、各計算機上にその計算機上のリソー
スを監視制御するエージェントをおくようにしたので、
マネージャやネットワークの負荷を軽減することができ
る。

【０１４０】また、各計算機上のエージェントが互いに
通信し、グローバルデータを直接アクセスするようにし
たので、マネージャの搭載が不要となる。

【０１４１】また、マネージャは同一計算機上のエージ
ェントと通信し、各計算機上のエージェントが互いに通
信するようにしたので、パッケージプログラムはマネー
ジャ、およびエージェントのいずれに対してアクセスす
るかを選択することができる。

【０１４２】また、自動制御機構を設け、パッケージプ
ログラム間の相互関係を定義した設定ファイルによる実
行環境を反映したシステム運転を行うようにしたので、
柔軟なシステム設計が可能となる。

【０１４３】また、パッケージプログラムに動作モード
を付加して管理するようにしたので、多重系システムか
らの移行、およびシステム運用が容易となる。

【０１４４】また、クラスタシステム内の全リソースの
状態の変化を一括してログとして収集保存するようにし
たので、障害発生時の解析作業が容易となる。

【０１４５】また、クラスタ制御システムを構成する複
数の計算機のうちの１つの計算機に障害が発生した場合
に、上記障害が発生した計算機で運転中のアプリケーシ
ョンや各種のサービスを提供するパッケージプログラム
を他の計算機で運転させるクラスタ制御システムにおい
て、上記複数の計算機はそれぞれ、自己の計算機の障害
及び回復を監視するとともに、上記パッケージプログラ
ムの起動及び運転を制御するクラスタデーモンを備え、
上記複数の計算機のうちの第１の計算機は、上記パッケ
ージプログラムである第１のパッケージプログラムを運
転し、上記複数の計算機のうちの第２の計算機は、上記
第１のパッケージプログラムと同じアプリケーションや
サービスを提供する第２のパッケージプログラムを起動
状態で待機させ、上記複数の計算機のうち１つの計算機
は、上記クラスタデーモンに加えて、上記複数の計算機
のそれぞれのクラスタデーモンから監視の結果を受け取
るとともに、上記クラスタデーモンを制御して、上記第
１の計算機に障害が発生した場合に、上記第２の計算機
に上記第２のパッケージプログラムを運転させるととも
に、上記第１の計算機が障害から回復した場合には、上
記第１の計算機に上記第１のパッケージプログラムを起
動状態で待機させるマネージャを備えたため、高速にシ
ステムを回復させることができ、回復後も高速に処理を
実行する事ができる。

【０１４６】また、上記第１のパッケージプログラムの
出力若しくは上記第２のパッケージプログラムの出力の
いずれかを選択して出力する出力制御手段を有し、上記
第２の計算機は、上記第２のパッケージプログラムを起
動状態で待機させる代わりに、上記第２のパッケージプ
ログラムを運転し、上記マネージャに代えて、上記複数
の計算機のそれぞれのクラスタデーモンから監視の結果
を受け取るとともに、上記クラスタデーモンを制御し
て、上記第１のパッケージプログラムの出力が上記出力
制御手段から出力されているときに上記第１の計算機で
障害が発生した場合、上記第１のパッケージプログラム
の出力に代えて上記第２のパッケージプログラムの出力
を上記出力制御手段から出力させ、上記第２の計算機で
障害が発生するまで上記出力制御手段に上記第２のパッ
ケージプログラムの出力を継続して出力させ、上記第１
のパッケージプログラムが運転を再開し上記第２の計算
機で障害が発生した場合に、上記第２のパッケージプロ
グラムの出力に代えて、上記第１のパッケージプログラ
ムの出力を上記出力制御手段から出力させるマネージャ
を備えたため、高速にシステムを回復させることがで
き、回復後も高速に処理を実行する事ができる。

【０１４７】また、上記マネージャに代えて、上記複数
の計算機のそれぞれのクラスタデーモンから監視の結果
を受け取るとともに、上記クラスタデーモンを制御し
て、上記第１の計算機に障害が発生した場合に、上記第
２の計算機に上記第２のパッケージプログラムを運転さ
せるとともに、上記複数の計算機のうちの第３の計算機
に上記第１のパッケージプログラムを起動状態で待機さ
せるマネージャを備えたため、高速にシステムを回復さ
せることができ、回復後も高速に処理を実行することが
できる。

【０１４８】また、上記複数の計算機のそれぞれで起動
されるパッケージプログラムのそれぞれの優先順位を記
憶する管理テーブルを備え、上記マネージャに代えて、
上記複数の計算機のそれぞれのクラスタデーモンから監
視の結果を受け取るとともに、上記クラスタデーモンを
制御して、上記第１の計算機に障害が発生した場合に、
上記管理テーブルから上記第１の計算機で運転されてい
た上記パッケージプログラムよりも優先順位の低いパッ
ケージプログラムを検索し、この優先順位の低いパッケ
ージプログラムの運転を停止させるとともに、上記優先
順位の低いパッケージプログラムを運転していた計算機
で上記第１の計算機で運転されていたパッケージプログ
ラムを起動させるマネージャを備えたため、計算機がダ
ウンした後も、重要な処理を優先的に運転することがで
きる。

【０１４９】また、クラスタシステムを構成する複数の
計算機のうちの１つの計算機に障害が発生した場合に、
上記障害が発生した計算機で運転中のアプリケーション
や各種のサービスを提供するパッケージプログラムを他
の計算機で運転させるクラスタシステムにおいて、上記
複数の計算機はそれぞれ、自己の計算機の障害及び回復
を監視するとともに、上記パッケージプログラムの起動
及び運転を制御するクラスタデーモンを備え、上記複数
の計算機のうち１つの計算機は、上記クラスタデーモン
に加えて、上記複数の計算機のそれぞれで起動されるパ
ッケージプログラムのそれぞれの優先順位及び上記複数
の計算機のそれぞれの負荷を記憶する管理テーブルと、
上記複数の計算機のそれぞれのクラスタデーモンから監
視の結果を受け取るとともに、上記クラスタデーモンを
制御して、上記複数の計算機のうちの第１の計算機の負
荷があらかじめ定められた負荷よりも大きくなった場合
に、上記管理テーブルを参照し、上記第１の計算機で運
転しているパッケージプログラムのうちの優先順位の低
いパッケージプログラムの運転を停止させ、停止させた
パッケージプログラムを上記複数の計算機のうちの負荷
があらかじめ定められた負荷よりも小さい計算機で起動
させるマネージャと、を備えたため、負荷を自動的に分
散し、重要な処理のレスポンスの劣化を防ぐことができ
る。

【０１５０】また、上記管理テーブルに代えて、上記複
数の計算機上で起動されるパッケージプログラムのそれ
ぞれの優先順位を記憶する管理テーブルを備え、上記ク
ラスタデーモンは、自己の計算機のリソースを監視し、
上記マネージャに代えて、上記複数の計算機のそれぞれ
のクラスタデーモンから監視の結果を受け取るととも
に、上記クラスタデーモンを制御して、上記クラスタデ
ーモンにより監視されたリソースに変化が生じた場合
に、上記優先順位に基づいて、上記複数の計算機のそれ
ぞれで運転されているパッケージプログラムのそれぞれ
にリソースを割り当て直すマネージャを備えたため、重
要な処理のレスポンスの劣化を防ぐことができ、あまり
重要でない処理の継続もすることができる。

【０１５１】また、複数の計算機のそれぞれによって並
列に運転される複数の上記パッケージプログラムを１つ
のグループとするグループ名を記憶する管理テーブルを
備え、上記マネージャに代えて、上記複数の計算機のそ
れぞれのクラスタデーモンから監視の結果を受け取ると
ともに、上記クラスタデーモンを制御して、上記複数の
計算機のうちの第１の計算機に障害が発生した場合に、
上記管理テーブルから、上記複数の計算機のうちの計算
機であって上記第１の計算機上で運転されていたパッケ
ージプログラムと同じグループのパッケージプログラム
を運転していない計算機を検索し、検索された計算機で
上記第１の計算機が運転していたパッケージプログラム
を起動させ、運転させるマネージャを備えたため、シス
テムを回復させた後に、高速に並列処理を実行すること
ができる。

【図面の簡単な説明】

【図１】 本発明の第１の実施形態におけるプロセス構
成図である。

【図２】 本発明の第１の実施形態におけるマネージャ
の構成図である。

【図３】 本発明の第１の実施形態におけるユーザから
の要求に対するマネージャの処理を示すフローチャート
図である。

【図４】 本発明の第１の実施形態におけるマネージャ
のリソース状態監視の処理を示すフローチャート図であ
る。

【図５】 本発明の第１の実施形態の運用例を示す図で
ある。

【図６】 本発明の第２の実施形態におけるプロセス構
成図である。

【図７】 本発明の第２の実施形態におけるマネージャ
の構成図である。

【図８】 本発明の第２の実施形態におけるエージェン
トの構成図である。

【図９】 本発明の第２の実施形態におけるエージェン
トの変形例を示す構成図である。

【図１０】 本発明の第２の実施形態におけるマネージ
ャのリソース状態監視の処理を示すフローチャート図で
ある。

【図１１】 本発明の第２の実施形態におけるエージェ
ントのリソース状態監視の処理を示すフローチャート図
である。

【図１２】 本発明の第３の実施形態におけるプロセス
構成図である。

【図１３】 本発明の第３の実施形態の運用例を示す図
である。

【図１４】 本発明の第４の実施形態におけるプロセス
構成図である。

【図１５】 本発明の第４の実施形態の運用例を示す図
である。

【図１６】 本発明の第５の実施形態におけるマネージ
ャの構成図である。

【図１７】 本発明の第５の実施形態における設定ファ
イル例を示す図である。

【図１８】 本発明の第６の実施形態における設定ファ
イル例を示す図である。

【図１９】 本発明の第７の実施形態におけるマネージ
ャの構成図である。

【図２０】 本発明の第７の実施形態におけるモードの
状態遷移図である。

【図２１】 本発明の第７の実施形態の運用例を示す図
である。

【図２２】 本発明の第８の実施形態におけるマネージ
ャの構成図である。

【図２３】 本発明の第９の実施形態におけるマネージ
ャの構成図である。

【図２４】 本発明の第９の実施形態における管理テー
ブルの記憶内容構成例である。

【図２５】 本発明の第９の実施形態におけるマネージ
ャの処理を説明するフローチャートである。

【図２６】 本発明の第９の実施形態におけるシステム
の動作例を示す機能ブロック図である。

【図２７】 本発明の第１０の実施形態におけるマネー
ジャの構成図である。

【図２８】 本発明の第１０の実施形態における管理テ
ーブルの記憶内容構成例である。

【図２９】 本発明の第１０の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図３０】 本発明の第１０の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図３１】 本発明の第１１の実施形態におけるマネー
ジャの構成図である。

【図３２】 本発明の第１１の実施形態における管理テ
ーブルの記憶内容構成例である。

【図３３】 本発明の第１１の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図３４】 本発明の第１１の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図３５】 本発明の第１２の実施形態における管理テ
ーブルの記憶内容構成例である。

【図３６】 本発明の第１２の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図３７】 本発明の第１２の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図３８】 本発明の第１３の実施形態における管理テ
ーブルの記憶内容構成例である。

【図３９】 本発明の第１３の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図４０】 本発明の第１４の実施形態における管理テ
ーブルの記憶内容構成例である。

【図４１】 本発明の第１４の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図４２】 本発明の第１４の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図４３】 本発明の第１５の実施形態における管理テ
ーブルの記憶内容構成例である。

【図４４】 本発明の第１５の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図４５】 本発明の第１５の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図４６】 本発明の第１５の実施形態におけるシステ
ムの動作例を示す機能ブロック図である。

【図４７】 本発明の第１６の実施形態におけるマネー
ジャの構成図である。

【図４８】 本発明の第１６の実施形態における管理テ
ーブルの記憶内容構成例である。

【図４９】 本発明の第１６の実施形態におけるマネー
ジャの処理を説明するフローチャートである。

【図５０】 従来技術を示すプロセス構成図である。

【図５１】 従来技術の動作を示す図である。

【符号の説明】

１０１ａ 計算機Ａ、１０１ｂ 計算機Ｂ、１０１ｎ
計算機Ｎ、１０２ａｃｌｕｓｔｅｒ ｄａｅｍｏｎ
Ａ、１０２ｂ ｃｌｕｓｔｅｒ ｄａｅｍｏｎＢ、１０
２ｎ ｃｌｕｓｔｅｒ ｄａｅｍｏｎ Ｎ、１０３ａ１
パッケージＡ１、１０３ｂ１ パッケージＢ１、１０
３ｎ１ パッケージＮ１、１０３ａ２パッケージＡ２、
１０３ｂ２ パッケージＢ２、１０３ｎ２ パッケージ
Ｎ２、１０４ａ ローカルデータＡ、１０４ｂ ローカ
ルデータＢ、１０４ｎ ローカルデータＮ、１０５ マ
ネージャ、１０６ グローバルデータ、２０１ 要求処
理機構、２０２ リソース制御機構、２０３ リソース
状態ＤＢ、２０４ リソース状態監視機構、２０５ リ
ソース状態変化処理機構、２０６ 通知設定機構、２０
７ 通知設定ＤＢ、２０８ リソース状態変化通知機
構、２０９ 通信制御機構、５０１ａ プロセスＡ、５
０１ｂ プロセスＢ、５０１ｃ プロセスＣ、６０１ａ
エージェントＡ、６０１ｂ エージェントＢ、６０１
ｎ エージェントＮ、８０１ リソース状態ＤＢ、１３
０１ ユーザプロセスＡ、１３０２ユーザプロセスＢ、
１５０１ ユーザプロセスＡ、１５０２ ユーザプロセ
スＢ、１６０１ 設定ファイル、１６０２ 自動制御機
構、１９０１ モード管理機構、２２０１ ログ管理機
構、２２０２ ログＤＢ、２３０１ 通知処理機構、２
３０３ 管理テーブル、２３０２ モード管理機構、
２３０４ モード制御機構、２７０１ 出力管理機構、
２７０２ 管理テーブル、２７０３ 出力抑止機構、３
１０１ パッケージ管理機構、３１０２ 管理テーブ
ル、３１０３パッケージ制御機構。

Claims (15)

【特許請求の範囲】
1. 【請求項１】 クラスタシステムを構成する計算機群上
   のある計算機に障害が発生した場合に該計算機上で動作
   中のパッケージプログラムを他の計算機で実行させるク
   ラスタシステムにおいて、 クラスタを構成する各計算機は、 アプリケーションや各種のサービスを提供するパッケー
   ジプログラムと、 計算機間で通信を行いリソースを監視制御するクラスタ
   デーモンと、 上記監視結果をローカルデータとして記憶するローカル
   データ記憶手段を備え、 クラスタシステム内のうち１台の計算機は、上記パッケ
   ージプログラム、クラスタデーモン、ローカルデータ記
   憶手段に加えて、 各計算機上のローカルデータから収集されて、いずれの
   計算機からも参照可能なグローバルデータ記憶手段と、 上記グローバルデータ記憶手段および各計算機上のクラ
   スタデーモンと通信を行い、クラスタシステム全体の監
   視制御を行うマネージャを搭載し、 該マネージャが搭載されている計算機で障害が発生した
   場合にはクラスタ内の他の計算機上で再起動させるよう
   にしたことを特徴とするクラスタ制御システム。
2. 【請求項２】 クラスタシステムを構成する計算機群上
   のある計算機に障害が発生した場合に該計算機上で動作
   中のパッケージプログラムを他の計算機で実行させるク
   ラスタシステムにおいて、 クラスタを構成する各計算機は、 アプリケーションや各種のサービスを提供するパッケー
   ジプログラムと、 計算機間で通信を行いリソースを監視制御するクラスタ
   デーモンと、 自計算機上のクラスタデーモンおよびマネージャと通信
   を行うエージェントと、 上記監視結果をローカルデータとして記憶するローカル
   データ記憶手段を備え、 クラスタシステム内のうち１台の計算機は、上記クラス
   タデーモン、エージェント、ローカルデータ記憶手段に
   加えて、 各計算機上のローカルデータから収集されて、いずれの
   計算機からも参照可能なグローバルデータ記憶手段と、 上記グローバルデータ記憶手段および各計算機上のエー
   ジェントと通信を行い、クラスタシステム全体の監視制
   御を行うマネージャを搭載し、 該マネージャが搭載されている計算機に障害が発生した
   場合にクラスタ内の他の計算機上で再起動させるように
   したことを特徴とするクラスタ制御システム。
3. 【請求項３】 クラスタシステムを構成する計算機群上
   のある計算機に障害が発生した場合に該計算機上で動作
   していたパッケージプログラムを他の計算機で実行させ
   るクラスタシステムにおいて、 クラスタを構成する各計算機は、 アプリケーションや各種のサービスを提供するパッケー
   ジプログラムと、 自計算機上のパッケージプログラムおよび計算機間で通
   信を行いリソースを監視制御するクラスタデーモンと、 自計算機上のクラスタデーモン、各計算機上のエージェ
   ント間、およびグローバルデータ記憶手段と通信を行う
   エージェントと、 上記監視結果をローカルデータとして記憶するローカル
   データ記憶手段を備え、 クラスタシステム内のうち１台の計算機は、上記クラス
   タデーモン、エージェント、ローカルデータ記憶手段に
   加えて、 各計算機上のローカルデータから収集されて、いずれの
   計算機からも参照可能なグローバルデータ記憶手段を備
   え、 上記各計算機上のエージェントが直接にグローバルデー
   タ記憶手段、およびエージェント間で通信を行うように
   したことを特徴とするクラスタ制御システム。
4. 【請求項４】 クラスタシステムを構成する計算機群上
   のある計算機に障害が発生した場合に該計算機上で動作
   していたパッケージプログラムを他の計算機で実行させ
   るクラスタシステムにおいて、 クラスタを構成する各計算機は、 アプリケーションや各種のサービスを提供するパッケー
   ジプログラムと、 自計算機上のパッケージプログラムおよび各計算機間で
   通信を行いリソースを監視制御するクラスタデーモン
   と、 自計算機上のクラスタデーモン、各計算機上のエージェ
   ント間、およびグローバルデータと通信を行うエージェ
   ントと、 上記監視結果をローカルデータとして記憶するローカル
   データ記憶手段を備え、 クラスタシステム内のうち１台の計算機は、上記クラス
   タデーモン、エージェント、ローカルデータ記憶手段に
   加えて、 各計算機上のローカルデータから収集されて、いずれの
   計算機からも参照可能なグローバルデータ記憶手段と、 自計算機上のエージェントおよびクラスタデーモンと通
   信を行うマネージャを備え、 上記各計算機上のエージェントが直接にグローバルデー
   タ記憶手段、およびエージェント間で通信を行うように
   したことを特徴とするクラスタ制御システム。
5. 【請求項５】 上記マネージャはクラスタシステムを構
   成する計算機群のリソース状態変化時の処理を記述した
   リソース設定ファイルと、 リソース設定ファイルの定義に従い、リソースの状態に
   変化があった場合にリソース制御処理を行なう自動制御
   機構を備えたことを特徴とする請求項１又は請求項２又
   はまたは請求項４記載のクラスタ制御システム。
6. 【請求項６】 前記リソース設定ファイルにはパッケー
   ジプログラム間の相関関係や実行に関する優先順位情報
   を定義し、 自動制御機構は、該定義情報に基づいて各計算機上のパ
   ッケージプログラムを動作させるようにしたことを特徴
   とする請求項５記載のクラスタ制御システム。
7. 【請求項７】 上記マネージャはパッケージプログラム
   に対して、運転、待機、試験を含む運転動作モードを付
   加し、 該モードに従ってパッケージプログラムの動作制御の管
   理を行なうモード管理機構を備えたことを特徴とする請
   求項１、請求項２、請求項４、請求項５のいずれかに記
   載のクラスタ制御システム。
8. 【請求項８】 上記マネージャは、クラスタシステム内
   で起きたリソースの状態変化に関するログを収集するロ
   グ管理機構を備えたことを特徴とする請求項１、請求項
   ２、請求項４乃至請求項７のいずれかに記載のクラスタ
   制御システム。
9. 【請求項９】 クラスタ制御システムを構成する複数の
   計算機のうちの１つの計算機に障害が発生した場合に、
   上記障害が発生した計算機で運転中のアプリケーション
   や各種のサービスを提供するパッケージプログラムを他
   の計算機で運転させるクラスタ制御システムにおいて、 上記複数の計算機はそれぞれ、自己の計算機の障害及び
   回復を監視するとともに、上記パッケージプログラムの
   起動及び運転を制御するクラスタデーモンを備え、 上記複数の計算機のうちの第１の計算機は、上記パッケ
   ージプログラムである第１のパッケージプログラムを運
   転し、 上記複数の計算機のうちの第２の計算機は、上記第１の
   パッケージプログラムと同じアプリケーションやサービ
   スを提供する第２のパッケージプログラムを起動状態で
   待機させ、 上記複数の計算機のうち１つの計算機は、上記クラスタ
   デーモンに加えて、 上記複数の計算機のそれぞれのクラスタデーモンから監
   視の結果を受け取るとともに、上記クラスタデーモンを
   制御して、上記第１の計算機に障害が発生した場合に、
   上記第２の計算機に上記第２のパッケージプログラムを
   運転させるとともに、上記第１の計算機が障害から回復
   した場合には、上記第１の計算機に上記第１のパッケー
   ジプログラムを起動状態で待機させるマネージャを備え
   たことを特徴とするクラスタ制御システム。
10. 【請求項１０】 上記第１のパッケージプログラムの出
    力若しくは上記第２のパッケージプログラムの出力のい
    ずれかを選択して出力する出力制御手段を有し、 上記第２の計算機は、上記第２のパッケージプログラム
    を起動状態で待機させる代わりに、上記第２のパッケー
    ジプログラムを運転し、 上記マネージャに代えて、上記複数の計算機のそれぞれ
    のクラスタデーモンから監視の結果を受け取るととも
    に、上記クラスタデーモンを制御して、上記第１のパッ
    ケージプログラムの出力が上記出力制御手段から出力さ
    れているときに上記第１の計算機で障害が発生した場
    合、上記第１のパッケージプログラムの出力に代えて上
    記第２のパッケージプログラムの出力を上記出力制御手
    段から出力させ、上記第２の計算機で障害が発生するま
    で上記出力制御手段に上記第２のパッケージプログラム
    の出力を継続して出力させ、上記第１のパッケージプロ
    グラムが運転を再開し上記第２の計算機で障害が発生し
    た場合に、上記第２のパッケージプログラムの出力に代
    えて、上記第１のパッケージプログラムの出力を上記出
    力制御手段から出力させるマネージャを備えたことを特
    徴とする請求項９に記載のクラスタ制御システム。
11. 【請求項１１】 上記マネージャに代えて、上記複数の
    計算機のそれぞれのクラスタデーモンから監視の結果を
    受け取るとともに、上記クラスタデーモンを制御して、
    上記第１の計算機に障害が発生した場合に、上記第２の
    計算機に上記第２のパッケージプログラムを運転させる
    とともに、上記複数の計算機のうちの第３の計算機に上
    記第１のパッケージプログラムを起動状態で待機させる
    マネージャを備えたことを特徴とする請求項９に記載の
    クラスタ制御システム。
12. 【請求項１２】 上記複数の計算機のそれぞれで起動さ
    れるパッケージプログラムのそれぞれの優先順位を記憶
    する管理テーブルを備え、 上記マネージャに代えて、上記複数の計算機のそれぞれ
    のクラスタデーモンから監視の結果を受け取るととも
    に、上記クラスタデーモンを制御して、上記第１の計算
    機に障害が発生した場合に、上記管理テーブルから上記
    第１の計算機で運転されていた上記パッケージプログラ
    ムよりも優先順位の低いパッケージプログラムを検索
    し、この優先順位の低いパッケージプログラムの運転を
    停止させるとともに、上記優先順位の低いパッケージプ
    ログラムを運転していた計算機で上記第１の計算機で運
    転されていたパッケージプログラムを起動させるマネー
    ジャを備えたことを特徴とする請求項９に記載のクラス
    タ制御システム。
13. 【請求項１３】 クラスタシステムを構成する複数の計
    算機のうちの１つの計算機に障害が発生した場合に、上
    記障害が発生した計算機で運転中のアプリケーションや
    各種のサービスを提供するパッケージプログラムを他の
    計算機で運転させるクラスタシステムにおいて、 上記複数の計算機はそれぞれ、自己の計算機の障害及び
    回復を監視するとともに、上記パッケージプログラムの
    起動及び運転を制御するクラスタデーモンを備え、 上記複数の計算機のうち１つの計算機は、上記クラスタ
    デーモンに加えて、 上記複数の計算機のそれぞれで起動されるパッケージプ
    ログラムのそれぞれの優先順位及び上記複数の計算機の
    それぞれの負荷を記憶する管理テーブルと、 上記複数の計算機のそれぞれのクラスタデーモンから監
    視の結果を受け取るとともに、上記クラスタデーモンを
    制御して、上記複数の計算機のうちの第１の計算機の負
    荷があらかじめ定められた負荷よりも大きくなった場合
    に、上記管理テーブルを参照し、上記第１の計算機で運
    転しているパッケージプログラムのうちの優先順位の低
    いパッケージプログラムの運転を停止させ、停止させた
    パッケージプログラムを上記複数の計算機のうちの負荷
    があらかじめ定められた負荷よりも小さい計算機で起動
    させるマネージャと、を備えたことを特徴とするクラス
    タ制御システム。
14. 【請求項１４】 上記管理テーブルに代えて、上記複数
    の計算機上で起動されるパッケージプログラムのそれぞ
    れの優先順位を記憶する管理テーブルを備え、 上記クラスタデーモンは、自己の計算機のリソースを監
    視し、 上記マネージャに代えて、上記複数の計算機のそれぞれ
    のクラスタデーモンから監視の結果を受け取るととも
    に、上記クラスタデーモンを制御して、上記クラスタデ
    ーモンにより監視されたリソースに変化が生じた場合
    に、上記優先順位に基づいて、上記複数の計算機のそれ
    ぞれで運転されているパッケージプログラムのそれぞれ
    にリソースを割り当て直すマネージャ備えたことを特徴
    とする請求項１３に記載のクラスタ制御システム。
15. 【請求項１５】 複数の計算機のそれぞれによって並列
    に運転される複数の上記パッケージプログラムを１つの
    グループとするグループ名を記憶する管理テーブルを備
    え、 上記マネージャに代えて、上記複数の計算機のそれぞれ
    のクラスタデーモンから監視の結果を受け取るととも
    に、上記クラスタデーモンを制御して、上記複数の計算
    機のうちの第１の計算機に障害が発生した場合に、上記
    管理テーブルから、上記複数の計算機のうちの計算機で
    あって上記第１の計算機上で運転されていたパッケージ
    プログラムと同じグループのパッケージプログラムを運
    転していない計算機を検索し、検索された計算機で上記
    第１の計算機が運転していたパッケージプログラムを起
    動させ、運転させるマネージャを備えたことを特徴とす
    る請求項１３に記載のクラスタ制御システム。