JP3062155B2 - 計算機システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数の計算機が接
続された計算機システムに関し、特に耐故障性、可用性
が向上した計算機システムに関する。

【０００２】

【従来の技術】計算機システムの可用性を向上させるた
めには、故障によるシステムのダウン時間を低減する必
要がある。この耐故障性向上を図る一つの方法として冗
長性の利用が挙げられる。冗長性はハードウェア、ソフ
トウェアの両方に適用することが可能であり、具体的に
は多重化、多数決方式、誤り訂正／検出符号の利用とい
った例がある。その中で、ハードウェアについて利用で
きる比較的簡単な形態であって適用範囲の広いものに、
一つの計算機システムを互いに接続された複数の計算機
で構成するという多重化の形態がある。

【０００３】この多重化では、システムを構成する個別
の計算機（これを以下、ノードと呼ぶことがある）が何
らかの原因で停止（ダウン）したとき、そのノードの処
理を予め定義された別のノードが引き継ぐフェールオー
バ構成とする事例が多くなってきている。

【０００４】

【発明が解決しようとする課題】この従来のフェールオ
ーバ構成では、障害発生時に、予め決められたノード先
にしか処理を引き継ぐ（フェールオーバする）ことがで
きない。つまり、この方法では、処理引き継ぎに必要な
計算機リソース（資源）量（例えばＣＰＵ負荷、メモリ
量）が多くても、それに応じてフェールオーバされるノ
ードを動的に変更できず、フェールオーバされたノード
の負荷が高くなってその処理速度が許容限度以上に低減
したり、極端な場合には処理を引き継ぐことが実質的に
不可能である場合が生じ得るという問題があった。

【０００５】また、例えば、重要度の低いデータベース
アプリケーションソフトウェア（以下、ＤＢアプリケー
ションと略記する）が稼働しているノードに、重要度の
高いＤＢアプリケーションをフェールオーバしたい場合
がある。この場合、フェールオーバ先のノードのメモリ
の一部は、重要度の低いＤＢアプリケーションが先に占
有しており、フェールオーバされる重要度の高いＤＢア
プリケーションは、残りのメモリ資源しか利用すること
ができず、処理が効率的に行われない、処理速度が遅い
といった上述の不都合を生じる。このように従来のフェ
ールオーバ方法では、単純には、リソースの割当が効果
的に行われないといった問題があった。これを改善した
従来のフェールオーバ方法には、一旦、先にリソースを
占有している重要度の低いＤＢアプリケーションを停止
させて、重要度の高いＤＢアプリケーションに対して優
先的にリソースが与えられるような再配分を行うものも
あった。この方法では、一旦、ノードをシャットダウン
する、すなわち既存のセッション情報（端末とＤＢ間の
接続及びトランザクションを処理するために必要な情
報）が失われてしまい、先に実行されていたアプリケー
ションのリソース再配分後の実行が面倒となるという問
題があった。

【０００６】本発明は上記問題点を解消するためになさ
れたもので、複数ノードがネットワーク接続され、ノー
ド間でフェールオーバを行うという多重化により耐故障
性、可用性を向上させる計算機システムであって、フェ
ールオーバ先での処理が効率的に行われるシステムを提
供することを目的とする。

【０００７】

【課題を解決するための手段】本発明に係る、それぞれ
処理プログラムを実行可能な複数のノードがネットワー
ク接続された計算機システムは、前記各ノードが、前記
各ノードそれぞれの稼働状況を監視する監視手段と、前
記監視手段が任意の前記ノードでの前記処理プログラム
の実行障害を検知したとき代替ノードを選択する代替ノ
ード選択手段と、前記実行障害を生じたノードから前記
代替ノードへ前記処理プログラムの実行を引き継がせる
フェールオーバ手段とを有し、前記監視手段は、前記各
ノードそれぞれのプロセッサ負荷を監視し、前記代替ノ
ード選択手段は、前記監視手段により得られた前記プロ
セッサ負荷に基づいて前記代替ノードを選択することを
特徴とする。

【０００８】本発明の好適な態様は、前記代替ノード選
択手段が前記プロセッサ負荷が最小であるノードを前記
代替ノードとして選択するものである。

【０００９】別の本発明に係る計算機システムにおいて
は、前記各ノードが、前記各ノードそれぞれの稼働状況
を監視する監視手段と、前記監視手段が任意の前記ノー
ドでの前記処理プログラムの実行障害を検知したとき代
替ノードを選択する代替ノード選択手段と、前記実行障
害を生じたノードから前記代替ノードへ前記処理プログ
ラムの実行を引き継がせるフェールオーバ手段とを有
し、前記監視手段は前記各ノードそれぞれのメモリ空き
容量を監視し、前記代替ノード選択手段は前記監視手段
により得られた前記メモリ空き容量に基づいて前記代替
ノードを選択することを特徴とする。本発明の好適な態
様は、前記代替ノード選択手段が前記メモリ空き容量が
最大であるノードを前記代替ノードとして選択するもの
である。

【００１０】また、本発明の他の好適な態様は、前記監
視手段が前記各ノードそれぞれのプロセッサ負荷とメモ
リ空き容量とを監視し、前記代替ノード選択手段が前記
監視手段により得られた前記プロセッサ負荷と前記メモ
リ空き容量とに基づいて前記代替ノードを選択するもの
である。

【００１１】また別の本発明に係る計算機システムにお
いては、前記各ノードが、前記各ノードそれぞれの稼働
状況を監視する監視手段と、前記監視手段が任意の前記
ノードでの前記処理プログラムの実行障害を検知したと
き代替ノードを選択する代替ノード選択手段と、前記実
行障害を生じたノードから前記代替ノードへ前記処理プ
ログラムの実行を引き継がせるフェールオーバ手段とを
有し、前記監視手段は前記各ノードそれぞれのメモリ空
き容量を監視し、前記フェールオーバ手段は前記代替ノ
ードの前記メモリ空き容量が前記処理プログラムの引き
継ぎに十分か否かを判断する容量比較手段と、前記メモ
リ空き容量が不足するときは前記代替ノードで先行して
起動されている先起動プログラムに割り当てられるメモ
リ容量を縮小するメモリ割当変更手段とを有することを
特徴とする。

【００１２】さらに他の本発明に係る計算機システム
は、前記代替ノードの前記先起動プログラムと当該先起
動プログラムを前記ネットワークを介して利用するユー
ザノードとの間のセッション情報を含んだセッション情
報テーブルを有し、前記フェールオーバ手段が、前記メ
モリ容量の割当変更を行う際に前記セッション情報に基
づいて既設セッション中のトランザクションが継続中か
否かを判別して継続中のトランザクションに対するメッ
セージのみ前記先起動プログラムに渡し、当該セッショ
ンに対する他のメッセージは前記割当変更が完了するま
で前記セッション情報に保留するメッセージ取扱手段を
有し、前記メモリ割当変更手段が前記トランザクション
が終了したときに、前記先起動プログラムの実行を停止
してメモリ割当変更を行うことを特徴とする。

【００１３】

【発明の実施の形態】［実施の形態１］以下、本発明の
実施の形態について図面を参照して説明する。

【００１４】本発明に係る計算機システムは、複数のノ
ード（ノード１、ノード２、…、ノードｎ）が互いにネ
ットワークを介して接続されて構成される。図１は、本
システムの構成を説明するための模式図である。各ノー
ドではそれぞれ、監視エージェントと呼ぶモジュールが
動作する。この監視エージェントは、例えば、各ノード
の中央処理装置（Central Processing Unit：ＣＰＵ）
で実行されるソフトウェアで構成され、各ノードで常時
実行状態にされている。そして監視エージェントは自律
的に動作して、それが動作するノード（自ノードと称す
る）と自ノード以外のネットワーク接続されたノード
（他ノードと称する）のＤＢアプリケーションの稼働状
況、ＣＰＵ資源、メモリ資源などを定期的に、又は随
時、サンプリングしながら監視する機能を有する。この
監視エージェント１０は、ノードのオペレーティングシ
ステム（ＯＳ）やＤＢが起動しているかどうかを判別す
る既存の機能を用いて各ノードの情報をチェックし、そ
れぞれの監視エージェント１０-1，１０-2，…，１０-n
の監視結果は、ネットワークを介して各ノードと接続さ
れた共有ディスク２０に書き込まれる。監視結果は具体
的には、この共有ディスク２０上に設けられる監視情報
リポジトリ２５に記録される。

【００１５】図２は、監視情報リポジトリ２５に格納さ
れる情報の一例の論理構成を示す模式図である。なお、
この図において、データとして実際に値が取得されるの
は、ツリー構造の最下位レベルの項目であり、それ以外
の項目はその下位レベルを総括する単なる名称である。
この図に示したように、監視情報リポジトリ２５には
「ノード情報」として各ノード毎の情報が格納される。
各「ノード情報」は、ノード名、最終サンプリング時
刻、監視エージェント情報、ロック済みエージェント情
報、サンプリング間隔、サンプリングデータ保存期間、
ノード状態、基準空きメモリ量といったデータを含んで
いる。

【００１６】また各「ノード情報」はさらに、「ＤＢ情
報」、「資源情報」という名称で総括されるデータを含
んでいる。ＤＢ情報は、各ノードにて使用されるＤＢシ
ステムの種類に応じた数だけの「ＤＢ」エントリで構成
され、各「ＤＢ」エントリはＤＢ名、実行優先度、サン
プリング時刻、ＤＢ状態、起動情報といったデータを含
んで構成される。

【００１７】「資源情報」は、「資源データ」エントリ
で構成され、各「資源データ」エントリはサンプリング
時刻、ＣＰＵ稼働率、空きメモリ量といったデータを含
んで構成される。「資源データ」エントリは「資源情
報」内に、サンプリング保存期間に応じて定まる、結果
を保存すべきサンプリング回数分だけ含まれる。すなわ
ち、「資源情報」には、サンプリングが行われる度に、
そのサンプリング時における「資源データ」を構成する
データセットが追加され、一方、予め定められたサンプ
リング保存期間を過ぎた「資源データ」エントリは削除
される。

【００１８】以下、監視情報リポジトリ２５内の各デー
タについて説明する。「ノード名」は、ノードを識別す
るための名前であり、「最終サンプリング時刻」は、当
該ノードについての情報が最後にサンプリングされた日
付、時刻を表す情報である。「監視エージェント情報」
は、ノードで動作する監視エージェントの識別子（名
前）、及び別の監視エージェントとのメッセージ交換が
できるようにするための設定情報である。「ロック済み
エージェント情報」は、当該ノードをチェックしている
監視エージェントの識別子を表し、どの監視エージェン
トも当該ノードをチェック中でないときは値“ＮＵＬ
Ｌ”が設定される。

【００１９】「サンプリング間隔」は、監視エージェン
トが自ノード内の全てのＤＢ情報及び資源情報を採取
し、監視情報リポジトリ２５内に登録されたＤＢアプリ
ケーションがダウンしているかどうかをチェックする間
隔である。「サンプリングデータ保存期間」には、資源
情報の過去の履歴の保存期間が指定される。

【００２０】「ノード状態」は、現在のノードの状態を
表すデータであり、その状態としては、例えば“停止
中”、“稼働中”、“ダウン”、“フェールオーバ作業
中”の４通りを定義することができる。

【００２１】ここで、“停止中”は、ノードが稼働して
いないことを示す状態である。“停止中”が記録される
タイミングはＯＳが正常に停止されるときに停止処理の
一環として行われるか、ノードの“ダウン”状態下での
全てのＤＢアプリケーションのフェールオーバ作業が完
了（当該作業の成功又は不成功は問わない）した直後で
ある。

【００２２】“稼働中”は、ノードが稼働していること
を示す状態である。“稼働中”が記録されるタイミング
は、自ノードの監視エージェントによって、自分自身の
起動初期処理として、又は“フェールオーバ作業中”状
態が終了した段階である。

【００２３】“ダウン”は、ノードが過去に“稼働中”
の状態であったが、現時点ではノードが停止している状
態を表す。“ダウン”が記録されるタイミングは、監視
情報リポジトリに当該ノードの状態として“稼働中”が
記録されているにも拘わらず他ノードの監視エージェン
トによって当該ノードの停止が検出された場合である。

【００２４】“フェールオーバ作業中”は、当該ノード
にてフェールオーバが実際に行われている状態である。
“フェールオーバ作業中”が記録されるタイミングは当
該ノードの監視エージェントが他ノードの監視エージェ
ントからＤＢフェールオーバの指示を受け取ったときで
あり、フェールオーバ作業が終了した時点で状態は“稼
働中”に戻る。

【００２５】次に「基準空きメモリ量」には、起動直後
の空きメモリ量が記録される。

【００２６】「ＤＢ情報」エントリに含まれる「ＤＢ
名」は、当該エントリに対応するＤＢシステムを一意に
特定する識別子である。「サンプリング時刻」は、当該
「ＤＢ情報」エントリの情報がサンプリングされた日
付、時刻を表す。「起動情報」は当該ＤＢシステムに対
応したＤＢアプリケーションを起動するための実行手順
が記述されたスクリプトファイル名や、運用時の標準メ
モリ量など、ＤＢアプリケーションを起動するために必
要な情報である。

【００２７】「ＤＢ状態」は、当該エントリに対応する
ＤＢシステムの状態を表すデータであり、その状態とし
ては、例えば“停止中”、“稼働中”、“ダウン”の３
通りを定義することができる。

【００２８】ここで、“停止中”は、ＤＢアプリケーシ
ョンが停止している状態を示す。“停止中”が記録され
るタイミングはＤＢアプリケーションが正常に停止され
るときに停止処理の一環として行われるか、自ノードの
監視エージェントによって、自分自身の起動初期処理と
してＤＢアプリケーションの停止が検出されたときであ
る。

【００２９】“稼働中”は、ＤＢアプリケーションが正
常に動作していることを示す状態である。“稼働中”が
記録されるタイミングは、当該ＤＢアプリケーションが
動作するノードの監視エージェントによって、当該ＤＢ
アプリケーションの状態が“稼働中”以外の状態におい
て、当該ＤＢアプリケーションが動作していることを検
出したときである。

【００３０】“ダウン”は、ＤＢアプリケーションが過
去に“稼働中”の状態であったが、現時点では停止して
いる状態を表すものである。“ダウン”が記録されるタ
イミングは、監視情報リポジトリに当該ＤＢアプリケー
ションの状態として“稼働中”が記録されているにも拘
わらず自ノードの監視エージェントによってＤＢアプリ
ケーションの停止が検出されたとき、又は当該ノードの
状態が他ノードの監視エージェントによって“ダウン”
と記録される場合である。

【００３１】「実行優先度」は、ＤＢシステムの優先度
であり、数値を以て表すことができる。例えば、数値が
大きいほど優先度が高いと定義することができる。

【００３２】「資源情報」エントリに含まれる「サンプ
リング時刻」は、当該「資源情報」エントリの情報がサ
ンプリングされた日付、時刻を表す。

【００３３】「ＣＰＵ稼働率」は、サンプリングが行わ
れた時点でのＣＰＵの稼働率を表す。

【００３４】「空きメモリ量」は、サンプリングされた
時刻での空きメモリ量を表す。

【００３５】図３〜７は、監視エージェントの動作を説
明するフロー図であり、特に図３は、監視エージェント
のＤＢアプリケーション状態監視に関する初期処理を説
明するフロー図である。まず、監視エージェント１０が
起動される前においては、監視情報リポジトリ２５内の
ノード状態は“停止中”に設定される。各ノードが起動
され、監視エージェント１０が起動されると、監視エー
ジェント１０は自ノードの状態を“稼働中”に設定する
（Ｓ５０）。次に、監視情報リポジトリ２５の自ノード
に関するノード情報にエントリされているＤＢ情報に基
づいて、エントリされている各ＤＢシステム毎に以下に
説明するステップＳ６０〜７５で構成されるループを繰
り返す。このループに含まれる処理においては、まずＤ
Ｂの状態が監視情報リポジトリ２５から取り出される
（Ｓ６０）。そして取り出したＤＢ状態の値が“稼働
中”であるか否かが判定され（Ｓ６５）、その判定結果
に応じた値でＤＢ状態が更新される（Ｓ７０，Ｓ７
５）。なお、この初期処理においては、“ダウン”状態
は生じないので、ステップＳ６５にて“稼働中”でない
と判定された場合には、ステップＳ７５において、初期
値“停止中”が維持される。ステップＳ８０において
は、全てのＤＢシステムについてステップＳ６０〜Ｓ７
５が実施されたかが判断され、実施されていないＤＢシ
ステムがあれば、処理はステップＳ６０に戻され、その
ＤＢシステムについて同様の処理が行われる。一方、ス
テップＳ８０において全てのＤＢシステムについて処理
が行われたと判断された場合には、図３に示す初期処理
は終了し、各ノード毎で行われる監視処理が開始され
る。

【００３６】図４は、各ノードでの監視処理の概略を説
明するフロー図であり、図５は当該監視処理に設けられ
る自ノードに対するＤＢ状況チェック処理Ｓ１２５内で
の処理をより詳細に示したフロー図である。図３と図４
とは、図に示される端子Ａにおいて互いに接続される。
図３に示す初期処理から図４に示す監視処理に処理が渡
されると、以降、ノードが稼働中である間、監視処理を
構成するＳ１００〜１４５が例えば一定間隔で起動され
繰り返される。

【００３７】タイマー処理Ｓ１００は、監視処理を一定
間隔で起動するために設けられ、当該処理が所定時間の
経過を検知したことに基づいて、続くＤＢ再起動処理Ｓ
１０５が必要に応じて行われる。このＤＢ再起動処理Ｓ
１０５は、ダウンしているＤＢアプリケーションの再起
動先（フェールオーバ先）として自ノードが選択された
という通知を受けた場合に実行され、そのダウンしてい
るＤＢアプリケーションを自ノードにおいて再起動す
る。

【００３８】次に時刻が取得され（Ｓ１１０）、その時
刻に基づいて、監視情報リポジトリ２５内に格納されて
いる自ノード情報内の資源情報のうちサンプリング保存
期間を超えたものがあるかどうかが探索され、当該保存
期間を超えたものは監視情報リポジトリ２５から削除さ
れる（Ｓ１１５）。

【００３９】このようにまず監視情報リポジトリ２５内
の不要なデータを整理した後、監視エージェントは自ノ
ードのチェックを開始する。そのチェック開始に際し
て、監視エージェントは自身の監視エージェント識別子
を自ノード情報のロック済みエージェント情報に登録す
る（Ｓ１２０）。これにより自ノードに対するチェック
処理実行中における他ノードの監視エージェントからの
チェックを排他制御する。

【００４０】自ノードに対するチェック処理はＤＢアプ
リケーションの状況のチェックと、自ノードのリソース
負荷状況のチェックとを含んでいる。このうち自ノード
のＤＢアプリケーションに対するチェック処理Ｓ１２５
を図５を用いてより詳しく説明する。このチェックは、
監視情報リポジトリ２５の自ノード情報にエントリされ
ている全てのＤＢシステムについて反復される（Ｓ２０
０）。まずＤＢ状態が監視情報リポジトリ２５から取り
出され、当該ＤＢ状態の値が“稼働中”であるか否かが
判定され（Ｓ２０５）、状態が“稼働中”でない場合に
は、当該ＤＢアプリケーションについてのチェックを終
了し、残る未チェックのＤＢアプリケーションに対する
チェックに移る（Ｓ２３０）。一方、ステップＳ２０５
において、監視情報リポジトリ２５上に格納されている
ＤＢ状態データが“稼働中”であるＤＢシステムに対し
ては、そのＤＢシステムの実際の状態が“正常稼働”で
あるか“停止”であるかが調べられる（Ｓ２１０）。こ
の実際の状態の判別には、従来技術を用いることができ
る。

【００４１】監視情報リポジトリ２５上で“稼働中”で
あった（Ｓ２０５）にも拘わらず、ステップＳ２１０で
取得された実際の状態が“停止”であった場合（Ｓ２１
５）は、ＤＢアプリケーションは実行障害を生じた、つ
まり“ダウン”していると判断され（Ｓ２２０）、ＤＢ
アプリケーションダウンに対応する所定の処理（Ｓ２２
５）が実行される。

【００４２】このＤＢアプリケーションダウン時の処理
では、実行障害を生じたＤＢアプリケーションを代替実
行させるのに適当なノード（代替ノード）が選択され、
当該ダウンしたＤＢアプリケーションをその代替ノード
において再起動し処理を引き継がせるための処理が、そ
の代替ノードで動作している監視エージェントに対して
実行される。すなわち、監視エージェントは、自ノード
でのＤＢアプリケーションの実行状況を監視する監視手
段、代替ノードを選択する代替ノード選択手段、及びダ
ウンしたＤＢアプリケーションの実行を代替ノードへ引
き継がせるフェールオーバ手段としての機能を有する。
なお、ここで選択された代替ノードへ発せられる処理引
き継ぎの指示は、当該代替ノードにおけるステップＳ１
０５で検知され、実行される。

【００４３】さて一方、条件判断ステップＳ２１５にお
いて、”停止”ではない、すなわち実際に“稼働中”で
あることが明らかになった場合は、監視情報リポジトリ
２５上の情報と一致しており異常はないので、当該ＤＢ
アプリケーションについてのチェックを終了し、残る未
チェックのＤＢアプリケーションに対するチェックに移
る（Ｓ２３０）。なお、ステップＳ２３０において、全
てのＤＢアプリケーションについてのチェックが完了し
たと判断された場合には、自ノードに対するチェック処
理Ｓ１２５を終了する。

【００４４】チェック処理Ｓ１２５が終了すると、次に
監視エージェントは、自ノードに関する資源情報のチェ
ックを行う（Ｓ１３０）。この処理では資源情報データ
がＯＳから取得され、監視情報リポジトリ２５に格納さ
れる（Ｓ１３０）とともに、そのサンプリング時刻で監
視情報リポジトリ２５内の自ノードに関する最終サンプ
リング時刻を更新する（Ｓ１３５）。

【００４５】ステップＳ１２５〜１３５の自ノードに対
するチェック処理が終了すると、監視エージェントは自
ノード情報のロック済みエージェント情報に“ＮＵＬ
Ｌ”を登録し、排他制御を解除する（Ｓ１４０）。

【００４６】以上の処理は監視エージェントが自ノード
に対して行う処理であるが、監視エージェントは自ノー
ドだけでなく、他のノードに対する監視及び障害時のフ
ェールオーバ処理をも行う（Ｓ１４５）。これを全ノー
ド処理と称する。図６，７は、全ノード処理を説明する
フロー図である。この全ノード処理は便宜上、図６，７
の２つに分割して表しており、両図の同一符号の端子
（具体的には端子Ｂ同士、及び端子Ｃ同士）において両
図は接続される。この処理は、あるノードの監視エージ
ェントが他のノードを順次選択して、選択したノードに
関し稼働状況の監視、及び障害発生時のフェールオーバ
処理を行うものであり、ステップＳ３００とステップＳ
４４５とで挟まれる処理が、それぞれのノードに対して
反復されるループ処理として構成されている。

【００４７】ステップＳ３０５〜３３０は、あるノード
の監視エージェント（以下、検査実行エージェントと称
する）がチェック対象として選択したノード（以下、検
査対象ノードと称する）を、他のノードの監視エージェ
ントがロック状態としたままダウンした場合に対応する
処置である。検査対象ノードのロック済みエージェント
情報が判別され（Ｓ３０５）、それが“ＮＵＬＬ”であ
る場合は問題がないので、検査実行エージェントは検査
対象ノードのロック済みエージェント情報に、自身のノ
ードの識別子を登録して検査対象ノードをロック状態と
し（Ｓ３３５）、検査対象ノードに対するチェックを開
始する。

【００４８】一方、ステップＳ３０５において、検査対
象ノードのロック済みエージェント情報に、他ノードの
識別子が登録されている場合は、当該他ノードの監視エ
ージェントと通信可能かどうかが調べられる（Ｓ３１
０）。もし通信可能であるならば、当該他ノードの監視
エージェントがその検査対象ノードをチェックであると
解して、当該他ノードに対するチェックは行わない。反
対に、ステップＳ３１０において、通信不可能であるこ
とが判明した場合には、当該他ノードの監視エージェン
トは検査対象ノードをロックしたままダウンしたと解さ
れる。そこで、検査実行エージェントは、現在検査を行
おうとしている検査対象ノードだけでなく全ノードを検
索対象として、当該他ノードの監視エージェントにより
ロックされているノードを監視情報リポジトリ２５のノ
ード情報に基づいて見いだし、そのロックを解除する。
具体的には、全てのノードを対象とするループ処理が行
われ（Ｓ３１５，Ｓ３３０）、そのノードのロック済み
エージェント情報が当該他ノードの識別子であるかどう
かが判定され（Ｓ３２０）、判定結果が“Ｙｅｓ”であ
る場合にはそのロック済みエージェント情報を“ＮＵＬ
Ｌ”にリセットし（Ｓ３２５）、“Ｎｏ”である場合に
はリセットを行わないという処理が行われる。しかる後
に、検査実行エージェントは現在検査を行おうとしてい
る検査対象ノードのロック済みエージェント情報に、自
身のノードの識別子を登録して検査対象ノードをロック
状態とし（Ｓ３３５）、検査対象ノードに対するチェッ
クを開始する。

【００４９】検査実行エージェントは、まず、監視情報
リポジトリ２５中の検査対象ノードのノード状態をチェ
ックする（Ｓ４００）。このノード状態に“稼働中”、
又は“フェールオーバ作業中”が設定されている場合
は、さらに、検査対象ノードが実際に動作しているかど
うかが調べられる（Ｓ４０５）。ちなみに、この判定は
従来技術を用いて行うことができる。この判定の結果、
検査対象ノードが、監視情報リポジトリ２５のノード状
態に設定された情報に反して、実際は停止していること
が判明した場合は、検査実行エージェントは検査対象ノ
ードがダウンしていると判定して、監視情報リポジトリ
２５の当該ノード状態を“ダウン”に変更する（Ｓ４１
０）。そして、検査実行エージェントは、ダウンしてい
ると判定した検査対象ノードについて監視情報リポジト
リ２５に登録されている全てのＤＢ情報を対象とするル
ープ処理を行う（Ｓ４１５，Ｓ４３０）。このループ処
理では、当該ＤＢ情報中のＤＢ状態に“稼働中”が設定
されているかどうかが調べられ（Ｓ４２０）、判定が
“Ｙｅｓ”である場合にはＤＢ状態を“ダウン”に変更
する（Ｓ４２５）。

【００５０】しかる後、検査実行エージェントは、ダウ
ンしたと判定した検査対象ノード上で実行されていたＤ
Ｂアプリケーションに対し、ノードダウンに対応する所
定の処理（Ｓ４３５）を実行する。このノードダウン時
の処理では、当該ダウンノード上で実行されていたＤＢ
アプリケーションを代替実行させるのに適当なノード
（代替ノード）が選択され、当該ＤＢアプリケーション
をその代替ノードにおいて再起動し処理を引き継がせる
ための処理が、その代替ノードで動作している監視エー
ジェントに対して実行される。すなわち、検査実行エー
ジェントは、他ノードである検査対象ノードの稼働状況
を監視する監視手段、代替ノードを選択する代替ノード
選択手段、及びノードダウンにより実行できなくなった
ＤＢアプリケーションの実行を代替ノードへ引き継がせ
るフェールオーバ手段としての機能を有する。なお、こ
こで選択された代替ノードへ発せられる処理引き継ぎの
指示は、当該代替ノードにおけるステップＳ１０５で検
知され、実行される。ノードダウン時の処理Ｓ４３５が
終了すると、検査実行エージェントは、検査対象ノード
のロック済みエージェント情報を“ＮＵＬＬ”に変更し
ロックを解除し（Ｓ４４０）、新たな検査対象ノードに
対する処理に移る（Ｓ４４５）。もし、全てのノードに
対して処理が終了したら全ノード処理Ｓ１４５を終了
し、図４に示すループに復帰する（Ｓ４５０）。

【００５１】なお、ステップＳ４００において、ノード
状態が“停止中”である場合は問題がない、つまりＤＢ
アプリケーションの実行障害は生じていないので、直ち
にロックを解除する（Ｓ４４０）。また、ノード状態が
既に“ダウン”に設定されている場合は、他のノードの
監視エージェントが既に当該検査対象ノードに対し検査
を実行して“ダウン”を検知し、ノードダウン時の処理
Ｓ４３５を実施したことを意味している。よって、この
場合も、現在検査を行っている検査実行エージェントは
改めてノードのダウンに対する処置を行わずに直ちにロ
ックを解除する（Ｓ４４０）。

【００５２】上述したように本システムによれば、ある
ノードでのＤＢアプリケーションの実行が困難となった
ときに、ネットワーク接続された複数のノードの中か
ら、その実行を引き継ぐノードとして適切なものが動的
に選択される。

【００５３】［実施の形態２］本発明の第２の実施形態
を、上記実施の形態１をベースに以下説明する。本実施
の形態の特徴は、実施の形態１におけるＤＢアプリケー
ションダウン時の処理Ｓ２２５及びノードダウン時の処
理Ｓ４３５に相当する処理にあり、以下、この実施の形
態１との相違点に重きを置いて説明し、実施の形態１と
基本的に同様である処理については説明を省略する。ま
た、実施の形態１と同様の構成要素には同一の符号を付
し、記載の簡潔を図る。

【００５４】本実施の形態においては、これらＤＢアプ
リケーションダウン時の処理及びノードダウン時の処理
における代替ノードの選択が、代替ノードとして選択さ
れるノードのＣＰＵ負荷に基づいて行われる点に大きな
特徴がある。

【００５５】本システムの各ノード上の監視エージェン
ト１０は、互いに非同期にサンプリング間隔毎に動作し
ている。監視エージェント１０は、自ノード内のあるＤ
Ｂアプリケーションがダウンしていること、又は他のあ
るノード全体がダウンしていることを検出すると、実施
の形態１のステップＳ２２５又はＳ４３５に相当するＤ
Ｂアプリケーションダウン時の処理及びノードダウン時
の処理を行う。

【００５６】図８は、本実施の形態におけるＤＢアプリ
ケーションダウン時の処理を示すフロー図である。この
処理は、ノード自体は稼働しているが、ＤＢアプリケー
ションはダウンしていることが検知された場合に実施さ
れる処理であり、図４のステップＳ１２０に続いて行わ
れる。

【００５７】監視エージェント１０は、自ノードのＤＢ
アプリケーションにダウン状態のものを検知すると、監
視情報リポジトリ２５に登録されている全てのノードを
対象とした以下の内容のループ処理を行う（Ｓ５００，
Ｓ５２５）。このループ処理の１回のループは１つのノ
ードに対応した処理であり、まず、そのノードの状態が
“稼働中”、“フェールオーバ作業中”のいずれかであ
るかどうかが監視情報リポジトリ２５のノード情報に基
づいて判定される（Ｓ５０５）。判定結果が“Ｙｅｓ”
である場合には、当該ノードに関する監視情報リポジト
リ２５中の資源情報に基づいて、平均ＣＰＵ稼働率が算
出される（Ｓ５１０）。ちなみに、例えばこの平均稼働
率は、監視情報リポジトリ２５に保存されている当該ノ
ードの複数サンプリングタイミングにおける資源情報の
全てを用いて計算される。

【００５８】次に、当該ノードが、現在の検査実行エー
ジェント以外の他ノードの監視エージェントにより“フ
ェールオーバ作業中”であるか否かが判定され（Ｓ５１
５）、その結果に基づいて換算ＣＰＵ稼働率が算定され
る。換算ＣＰＵ稼働率は、ステップＳ５１０で計算され
た平均ＣＰＵ稼働率に換算率αを乗じることにより求め
られる。ステップＳ５１０にてフェールオーバ作業中と
判定された場合には、αは１以上の定数（例えば１０）
とされ、これが乗じられて換算ＣＰＵ稼働率が求められ
る（Ｓ５２０）。一方、ステップＳ５１５にて、フェー
ルオーバ作業中ではないと判定された場合には、αは１
とされる、すなわち、ステップＳ５１０で求められた平
均ＣＰＵ稼働率がそのまま換算ＣＰＵ稼働率とされる。
監視エージェント１０は、この換算ＣＰＵ稼働率を決定
すると、当該ノードについてのループ処理を終了し、次
のノードのループ処理に移る。

【００５９】なお、ステップＳ５０５での判定結果が、
“停止中”、又は“ダウン”である場合には、当該ノー
ドにＤＢアプリケーションの処理を引き継ぐことはでき
ないので、代替ノードの候補から外して、次のノードに
対するループに移る。例えば、代替ノードの候補から外
したことは、それを表すためのフラグ等を設け、それに
より識別することができる。また、本システムでは後述
するように換算ＣＰＵ稼働率が小さいことを基準として
代替ノードを選択するので、ノードの換算ＣＰＵ稼働率
に非常に大きな値を設定することにより、当該ノードが
代替ノード候補外であることを識別するように構成する
こともできる。

【００６０】監視エージェント１０は上記ループ処理に
より、ネットワーク接続されたシステムの各ノードの代
替ノード候補としての可否、及び換算ＣＰＵ稼働率を定
めると、代替ノード候補のうち換算ＣＰＵ稼働率が最も
小さいノードを代替ノードとして選択し、当該代替ノー
ドに対し、ＤＢアプリケーションのダウンが確認された
ノード名（すなわち自ノード名）とダウン状態のＤＢ名
をメッセージとして送信することによりダウンしたＤＢ
アプリケーションの再起動を指示し（Ｓ５３０）、図４
のステップＳ１３０に復帰する。

【００６１】ちなみに、ノード状態がフェールオーバ作
業中である場合に１以上のαを乗じるのは、既にフェー
ルオーバ作業中のノードへは新たなフェールオーバ作業
の依頼が行われることを抑制し、なるべくフェールオー
バ作業を行っていないノードへ依頼が行われるようにし
て処理分散を図るためである。

【００６２】図９は、本実施の形態におけるノードダウ
ン時の処理を示すフロー図である。この処理は、あるノ
ードの監視エージェント１０が他ノードの全体がダウン
していることを検知した場合に実施する処理であり、図
７のステップＳ４３０に続いて行われる。

【００６３】監視エージェント１０は、監視情報リポジ
トリ２５に登録されている全てのノードを対象とした以
下の内容のループ処理を行う（Ｓ６００，Ｓ６５０）。
このループ処理の１回のループは１つのノードに対応し
た処理であり、そのノードの状態が“ダウン”であるか
どうかが監視情報リポジトリ２５のノード情報に基づい
て判定される（Ｓ６０５）。判定結果が“Ｎｏ”である
場合には、再起動等の実行障害処理は不要であるので、
次のノードについてのループ処理に移る。一方、判定結
果が“Ｙｅｓ”である場合には、ステップＳ６１０〜Ｓ
６３５の処理を行う。このステップＳ６１０〜Ｓ６３５
の処理は、代替ノード候補としての可否、及び換算ＣＰ
Ｕ稼働率を定めるための処理であり、上に説明したステ
ップＳ５００〜Ｓ５２５の処理と同様であるので、説明
を省略する。

【００６４】各ノードの換算ＣＰＵ稼働率が決定される
と、監視エージェント１０は代替ノード候補のうち換算
ＣＰＵ稼働率が最も小さいノードを代替ノードとして選
択し、当該代替ノードに対し、ＤＢアプリケーションの
ダウンが確認されたノード名（この場合は、ＤＢアプリ
ケーションダウン時の処理と異なり、他ノード名とな
る）とダウン状態のＤＢ名をメッセージとして送信する
（Ｓ６４０）。さらに、ダウンと判定されたノードの監
視情報リポジトリ２５での状態を“停止中”に変更し
（Ｓ６４５）、次のノードについてのループ処理に移
る。このようにして、ノードダウン時の処理のループＳ
６００〜Ｓ６５０は全てのノードを対象として実施され
る。

【００６５】図１０は、ステップＳ５３０，Ｓ６４０で
送信されたメッセージを受信したノードでのＤＢアプリ
ケーション再起動処理を説明するフロー図である。この
再起動処理は、図４のステップＳ１０５に相当する。

【００６６】各ノードは、一定間隔で監視エージェント
１０が動作し、いずれかの監視エージェント１０からの
メッセージが存在するか否かを調べる（Ｓ７００）。メ
ッセージが存在しなければ、図４に示すステップＳ１１
０以降の検査処理に移るが、メッセージが存在した場合
は、以下に述べるＤＢアプリケーション再起動処理を行
った後、検査処理に移る。

【００６７】再起動処理では、メッセージからＤＢアプ
リケーションの実行障害が検知されたノード名とＤＢ名
が取得される（Ｓ７０５）。そして、監視情報リポジト
リ２５の時ノードの情報に、“フェールオーバ作業中”
を設定し（Ｓ７１０）、監視情報リポジトリ２５からス
テップＳ７０５で取得されたＤＢ名に対応するＤＢ起動
情報を探しだし、その情報に基づいてＤＢアプリケーシ
ョンを起動する（Ｓ７１５）。また、ステップＳ７０５
で取得されたノード名、ＤＢ名に関するＤＢ情報エント
リを、自ノードのＤＢ情報に移動させるとともに（Ｓ７
２０）、当該ＤＢ情報の状態を“稼働中”に変更する
（Ｓ７２５）。そして、この再起動処理を行った後に既
に述べたように検査処理に移る。

【００６８】図１１は、上述した、ＤＢアプリケーショ
ンの実行障害検出時の監視エージェント１０の動作の一
例を説明する模式図である。この図に示す例では、ノー
ド１がダウンしていること、そしてその結果、ノード１
で実行されていたＤＢアプリケーション「ＤＢ＃１」が
ダウン状態であることが、ノード２の監視エージェント
１０（検査実行エージェント）による検査処理により検
知される。検査実行エージェントは、監視情報リポジト
リ２５の各ノードのノード情報中のＣＰＵ稼働率を参照
して、換算ＣＰＵ稼働率を算出し、その最小値を有する
ノード３を代替ノードに選択する。そして、ノード３の
監視エージェント１０に対し、ノード１で実行されてい
たＤＢ＃１の処理を引き継ぐように指示する。この指示
を受けたノード３の監視エージェント１０は、監視情報
リポジトリ２５中のＤＢ＃１に関する起動情報等に基づ
いてその再起動を実行する。

【００６９】本システムによれば、ＣＰＵの例えば過去
の稼働状況に基づいて、ＣＰＵ負荷が比較的厳しくない
ノードに、ダウンしたＤＢアプリケーションの処理引き
継ぎが行われる。

【００７０】なお、上述の例では、既にフェールオーバ
作業中であるノードの負荷を考慮した換算ＣＰＵ稼働率
が最小となるノードを代替ノードに選択したが、そのよ
うな考慮を行わずに、平均ＣＰＵ稼働率が最小値をとる
ノードを選択することとしてもよい。また、必ずしもそ
れらＣＰＵ稼働率が最も小さくなくてもよく、例えばＣ
ＰＵ負荷が所定の余裕を有することに基づいて選択を行
うことができ、この場合、例えば、ＣＰＵ稼働率が所定
の閾値以下となるノードのうち任意のものを選択するこ
とができる。

【００７１】また、上述の例では、サンプリングデータ
保存期間全体での平均に基づいて換算ＣＰＵ稼働率、又
は平均ＣＰＵ稼働率を求めたが、例えば、最新の何回か
のサンプリングで得られた資源情報の平均に基づいて代
替ノードを選択することもできる。

【００７２】さらに、資源情報に登録されるＣＰＵ稼働
率についての平均以外の統計情報を求め、それを考慮し
て代替ノードを決定することもできる。例えば、ＣＰＵ
稼働率の分散等から推定されるＣＰＵ稼働率の時間的な
変動を考慮して、単に平均値が小さいだけでなく、安定
してＣＰＵ稼働率が小さいものを代替ノードに選択して
もよい。

【００７３】［実施の形態３］本発明の第３の実施形態
を、図を参照して説明する。実施の形態２は、監視情報
リポジトリ２５に登録されるＣＰＵ稼働率を利用し、プ
ロセッサ負荷に基づいて代替ノードを選択した。これに
対し本実施の形態は、監視情報リポジトリ２５に登録さ
れる空きメモリ量を利用し、それに基づいて代替ノード
を選択する点が実施の形態２と異なる。以下、上記各実
施の形態と同様の内容については説明を省略し、それら
との相違点に重きを置いて説明する。なお、上記各実施
の形態と同様の構成要素には同一の符号を付し、記載の
簡潔を図る。

【００７４】図１２は、本実施の形態の特徴的処理を説
明するフロー図である。この処理は、図８の処理ステッ
プＳ５００〜Ｓ５３０及び図９のループ処理ステップＳ
６１０〜Ｓ６４０に置き換わるものである。

【００７５】すなわち、本システムの各ノード上の監視
エージェント１０は互いに非同期にサンプリング間隔毎
に動作し、自ノード内のあるＤＢアプリケーションがダ
ウンしていること、又は他のあるノード全体がダウンし
ていることを検出すると、実施の形態１のステップＳ２
２５又はＳ４３５に相当するＤＢアプリケーションダウ
ン時の処理及びノードダウン時の処理を行うわけである
が、本実施の形態におけるこれらの処理は、図１２のフ
ローで一部を置換された図８，９のフローで表される。

【００７６】各ノードの監視エージェント１０は、各ノ
ードの基準空きメモリ量を監視情報リポジトリ２５から
取得する。基準空きメモリ量は、各ノードの起動直後の
空き実メモリ量であり、基本的にはＯＳ等のノード稼働
に必須のソフトウェアのみメモリ上に存在し、他のアプ
リケーションがまだメモリ上に存在しない状態での空き
メモリ量を表す。各監視エージェント１０は、これら各
ノードの基準空きメモリ量を比較して、その最大値Ｍ
_maxを求める。この処理は、例えば、図３に示すステッ
プＳ５０の処理中に行うように構成される。

【００７７】次に、図１２の処理フローを説明する。監
視エージェント１０は、自ノードのＤＢアプリケーショ
ンにダウン状態のものを検知した場合、及び他のノード
全体がダウンしていることを検知した場合に、監視情報
リポジトリ２５に登録されている全てのノードを対象と
した以下の内容のループ処理を行う（Ｓ８００，Ｓ８２
０）。このループ処理の１回のループは１つのノードに
対応した処理であり、監視エージェント１０はそのノー
ドに関する資源情報に含まれる空きメモリ量を例えば監
視情報リポジトリ２５に保存されている全サンプリング
回数について平均し、その平均値をＭ_maxで除した値と
して定義されるメモリ余裕度ｍを求める（Ｓ８０５）。

【００７８】続いて、監視エージェント１０は、当該ノ
ードが、現在の検査実行エージェント以外の他ノードの
監視エージェントにより“フェールオーバ作業中”であ
るか否かを判定し（Ｓ８１０）、その結果に基づいて換
算メモリ余裕度が算定される。換算メモリ余裕度ｍ
^*は、ステップＳ８０５で計算されたメモリ余裕度ｍに
換算率βを乗じることにより求められる。ステップＳ８
１０にてフェールオーバ作業中と判定された場合には、
βは０以上１未満の定数（例えば０．１）とされ、これ
を乗じて換算メモリ余裕度ｍ^*が求められる（Ｓ８１
５）。一方、ステップＳ８１０にて、フェールオーバ作
業中ではないと判定された場合には、βは１とされる、
すなわち、ステップＳ８１０で求められたメモリ余裕度
ｍがそのまま換算メモリ余裕度ｍ^*とされる。監視エー
ジェント１０は、この換算メモリ余裕度ｍ^*を決定する
と、当該ノードについてのループ処理を終了し、次のノ
ードのループ処理に移る。

【００７９】監視エージェント１０は上記ループ処理に
より、ネットワーク接続されたシステムの各ノードの代
替ノード候補としての可否、及び換算メモリ余裕度を定
めると、代替ノード候補のうち換算メモリ余裕度が最も
大きいノードを代替ノードとして選択し、当該代替ノー
ドに対し、ＤＢアプリケーションのダウンが確認された
ノード名（すなわち自ノード名）とダウン状態のＤＢ名
をメッセージとして送信することによりダウンしたＤＢ
アプリケーションの再起動を指示する（Ｓ８２５）。

【００８０】ちなみに、ノード状態がフェールオーバ作
業中である場合に０以上１未満のβを乗じるのは、既に
フェールオーバ作業中のノードへは新たなフェールオー
バ作業の依頼が行われることを抑制し、なるべくフェー
ルオーバ作業を行っていないノードへ依頼が行われるよ
うにして処理分散を図るためである。

【００８１】本システムによれば、メモリの例えば過去
の空き状況に基づいて、メモリの余裕が比較的大きいノ
ードに、ダウンしたＤＢアプリケーションの処理引き継
ぎが行われる。メモリの余裕が大きい場合には、スワッ
ピングが抑制されることによりキャッシュのヒット率が
向上したり、スラッシングが防止されることにより高い
処理効率が得られる。

【００８２】なお、上述の例では、既にフェールオーバ
作業中であるノードの負荷を考慮した換算メモリ余裕度
が最大となるノードを代替ノードに選択したが、そのよ
うな考慮を行わずに、単純なメモリ余裕度が最大値をと
るノードを選択することとしてもよい。また、必ずしも
それらメモリ余裕度が最も大きくなくてもよく、例えば
メモり余裕度が所定の閾値以上となるノードのうち任意
のものを選択することができる。

【００８３】また、上述の例では、サンプリングデータ
保存期間全体での平均に基づいて換算メモリ余裕度、又
は単純なメモリ余裕度を求めたが、例えば、最新の何回
かのサンプリングで得られた資源情報の平均に基づいて
代替ノードを選択することもできる。

【００８４】さらに、資源情報に登録される空きメモリ
量（又はメモリ余裕度）についての平均以外の統計情報
を求め、それを考慮して代替ノードを決定することもで
きる。例えば、メモリ余裕度の分散等から推定される空
きメモリ量の時間的な変動を考慮して、単に平均値が大
きいだけでなく、安定してメモリ余裕度が大きいものを
代替ノードに選択してもよい。

【００８５】［実施の形態４］本発明の第４の実施形態
は、監視情報リポジトリ２５に登録されるＣＰＵ稼働率
と空きメモリ量との双方を利用して代替ノードを選択す
る点が、ＣＰＵ稼働率のみ利用する実施の形態２や空き
メモリ量のみ利用する実施の形態３と異なる。以下、上
記各実施の形態と同様の内容については説明を省略し、
それらとの相違点に重きを置いて説明する。なお、上記
各実施の形態と同様の構成要素には同一の符号を付し、
記載の簡潔を図る。

【００８６】本実施の形態では、ＣＰＵ稼働率と空きメ
モリ量との双方を用いて「空き資源率」なるパラメータ
をノードごとに算出し、その値に基づいて代替ノードを
選択する。つまり、一般に計算機における「資源」はＣ
ＰＵ負荷、メモリ使用のそれぞれに関する独立した指標
で把握されるが、本実施の形態では、それらの指標を、
あるノードの資源のうち他の処理に利用可能な資源の割
合を表す「空き資源率」という一つの指標に統合する。

【００８７】例えば、空き資源率は、次のように定義さ
れる。ＣＰＵ稼働率をＷ（０≦Ｗ≦１）で表すと、ＣＰ
Ｕ空き率ωは（１−Ｗ）で表される。メモリに関して
は、空きメモリ量をＥで表し、また、実施の形態３と同
様にしてＭ_maxを求め、これらの比（Ｅ／Ｍ_max）をメモ
リ空き率εと定義する。そして、これらＣＰＵ空き率ω
とメモリ空き率εとの相加平均｛（ω＋ε）／２｝を空
き資源率と定義する。

【００８８】監視エージェント１０（検査実行エージェ
ント）は、このように定義した空き資源率が最大となる
ノードを代替ノードに選択する。

【００８９】本発明の趣旨は、ＣＰＵ稼働率と空きメモ
リ量との双方を考慮して代替ノードを決定する点にあ
り、上に示した空き資源率の定義は一例に過ぎない。例
えば、（ｋ₁・ω＋ｋ₂・ε）／（ｋ₁＋ｋ₂）、（ω²＋
ε²）／２、（ω・ε）^1/2といったもので空き資源率を
定義することも可能である。

【００９０】このようにＣＰＵ稼働率と空きメモリ量と
の双方を考慮することにより、ノードの資源の余裕度の
評価の信頼性が高くなり、より適切に代替ノードを決定
することができる。

【００９１】［実施の形態５］上記各実施の形態では、
フェールオーバ先の空き資源の度合いを計算し、余裕が
あるノードへダウンしたＤＢアプリケーションの処理の
引き継ぎを行わせるものであった。これらの方式では、
代替ノードは動的に決定され、余裕度のあるものが選択
されるので、そのようにして決定された代替ノードでフ
ェールオーバが不可能である可能性は低い。しかし、そ
れでもなお、資源が最も空いたノードを選択したにも拘
わらずフェールオーバするには資源（特にメモリ資源）
が足りない可能性は残る。

【００９２】本発明の第５の実施形態は、これに対処す
るものであり、フェールオーバ先のノードで現在稼働中
のＤＢアプリケーションが獲得しているメモリを動的に
変更、すなわち空きメモリ量を必要に応じて増加させ、
フェールオーバを支障なく実行するものである。

【００９３】以下、上記各実施の形態と同様の内容につ
いては説明を省略し、それらと本実施の形態との相違点
に重きを置いて説明する。なお、上記各実施の形態と同
様の構成要素には同一の符号を付し、記載の簡潔を図
る。

【００９４】図１３は、本実施の形態の特徴的処理を説
明するフロー図である。この処理は、基本的には図４の
ＤＢ再起動処理Ｓ１０５内に追加されるものである。

【００９５】すなわち、タイマー処理が監視エージェン
ト１０の処理を開始させると、ＤＢ再起動処理Ｓ１０５
が開始され、その中でまず、監視エージェント１０は、
ＤＢ再起動を指示するメッセージを受信していることを
確認すると、それに指示されたＤＢ名に対応する起動情
報を監視情報リポジトリ２５から取得するとともに、現
在の自ノードの空きメモリ量を把握する。そして起動情
報中のデータである当該ＤＢシステムの運用に用いられ
る標準メモリ量（所要空きメモリ量）と、現在の空きメ
モリ量とを比較する（Ｓ９００）。もし、空きメモリ量
が標準メモリ量より大きい場合には（Ｓ９００）、ＤＢ
再起動に支障がないので、上記各実施の形態と同様のフ
ェールオーバ処理によるＤＢの起動が開始される（Ｓ９
２５）。

【００９６】一方、空きメモリ量が標準メモリ量より小
さい場合には、そのままＤＢ再起動を行うと、ＤＢアプ
リケーションを起動できないか、起動できても運用に支
障を生じる可能性がある。よって、この場合には監視エ
ージェント１０は、監視情報リポジトリ２５の自ノード
情報に登録されている先に起動されている全てのＤＢエ
ントリのうち、フェールオーバされるＤＢアプリケーシ
ョンより優先度の低いＤＢアプリケーションを対象とし
た以下の内容のループ処理を行う（Ｓ９０５，Ｓ９２
０）。このループ処理の１回のループは１つのＤＢエン
トリに対応した処理であり、監視エージェント１０はそ
のＤＢエントリに対して、現在よりも縮小された新たな
メモリ割り当て量を決定する（Ｓ９１０）。そして、当
該先に起動されているＤＢアプリケーションを一旦終了
した後、ステップＳ９１０で決定した割り当て量に基づ
いて再起動する（Ｓ９１５）。これによりメモリの再編
成が行われ、ループ処理が対象とする全てのＤＢエント
リについて処理が終わると、メモリ上にはフェールオー
バ対象のＤＢアプリケーションの運用に必要な量の空き
が生成されている。監視エージェント１０は、ステップ
Ｓ９００にて空きメモリ量が標準メモリ量より小さいと
判定された場合には、このようにして空きメモリ量を拡
大した後、上記各実施の形態で行ったと同様にしてフェ
ールオーバ対象のＤＢアプリケーションを起動する（Ｓ
９２５）。ちなみに、このステップＳ９２５におけるＤ
Ｂアプリケーションの起動は、監視情報リポジトリ２５
に登録された起動情報中の起動のためのスクリプトファ
イル等を参照して実行される。

【００９７】先起動のＤＢアプリケーションに対する新
たなメモリ割り当て量の具体的な決定方法の例を次に説
明する。例えば、新たなメモリ割り当て量の決定におい
ては、対象となるＤＢエントリの実行優先度を考慮する
ことができる。監視情報リポジトリ２５には、各ＤＢエ
ントリの実行優先度が登録されており、監視情報リポジ
トリ２５の説明で述べたように、ここでは、実行優先度
はそれが高い程、大きな数値で表される。ここで、ＤＢ
エントリ「ＤＢ＃ｉ」の優先度を表す数値をＰ_iとする
と、ＤＢエントリ「ＤＢ＃ａ」に対する割り当てメモリ
の縮小量Ｒ_aを次式で計算する。なお、この式の中でＬ
は、フェールオーバ対象ＤＢの起動に不足しているメモ
リ量であり、その標準メモリ量から現在の空きメモリ量
を差し引いた値である。また、総和“Σ”はステップＳ
９０５で対象とされる全てのＤＢエントリ（すなわち、
フェールオーバ対象のＤＢエントリより優先度の低いも
の）について計算される。

【００９８】Ｒ_a＝Ｌ・Ｐ_a／ΣＰ_i そして、ＤＢエントリ「ＤＢ＃ａ」に対する新たなメモ
リ割り当て量は、当該エントリに対して監視情報リポジ
トリ２５に格納されている運用時標準メモリ量からＲ_a
を差し引いた値に決定される。

【００９９】このように、フェールオーバ対象のＤＢア
プリケーションの実行に空きメモリ量が不足している場
合でも、先行して起動されている他のＤＢアプリケーシ
ョンに割り当てられるメモリ量を縮小・再編成すること
により、フェールオーバ処理が一層、確実に実行され
る。

【０１００】［実施の形態６］上記実施の形態５では、
先行して起動されているＤＢアプリケーションの使用メ
モリ量を変更することにより、フェールオーバ対象のＤ
Ｂアプリケーションの実行に必要な空きメモリ量が確保
された。このメモリ割り当ての変更に際し、先行して起
動されているＤＢアプリケーションは一旦終了される。
本実施の形態は、この先行起動ＤＢアプリケーションの
終了及び再起動の際のマンマシンインターフェースの改
善に関わるものである。すなわち、本実施の形態は、稼
働中のＤＢシステムのメモリ使用量を縮小してフェール
オーバ対象のＤＢシステム起動に必要な空きメモリ量を
確保する実施の形態５において、当該メモリ縮小時に、
稼働中のＤＢシステムの処理の継続性を担保し、エンド
ユーザにＤＢシステムが停止されることを意識させない
ように構成したことを特徴とするものである。

【０１０１】以下、上記各実施の形態と同様の内容につ
いては説明を省略し、それらと本実施の形態との相違点
に重きを置いて説明する。なお、上記各実施の形態と同
様の構成要素には同一の符号を付し、記載の簡潔を図
る。

【０１０２】エンドユーザとＤＢシステムとがネットワ
ークを介してメッセージを交換しながら処理を進めるシ
ステム形態においては、エンドユーザ側ノードとＤＢシ
ステム動作ノードそれぞれの処理は複数の機能レイヤを
含む階層構造に構成される。

【０１０３】図１４は、エンドユーザ側ノードとＤＢシ
ステム動作ノードとの機能レイヤ構成例を示す模式図で
ある。エンドユーザ側ノード１０００には、上位のレイ
ヤからエンドユーザアプリケーション１００２、ＤＢシ
ステム用の端末側メッセージ交換モジュール１００４及
びネットワーク制御層１００６の３つのレイヤが示さ
れ、一方、ＤＢシステム動作ノード１０１０には、上位
のレイヤからＤＢアプリケーション１０１２、ＤＢシス
テム用のサーバ側メッセージ交換モジュール１０１４及
びネットワーク制御層１０１６の３つのレイヤが示され
ている。そして、両ノードは最下位のレイヤであるネッ
トワーク制御層間を物理的なコネクション１０２０で接
続される。なお、このレイヤ構成は一例であって、例え
ば各レイヤをさらに細かく分けることも可能である。例
えば、ネットワーク制御層１００６，１０１６は、ＴＣ
Ｐ／ＩＰプロトコルではネットワーク層、データリンク
層及び物理層に対応することとなる。

【０１０４】エンドユーザアプリケーション１００２か
ら発行されるメッセージは、端末側メッセージ交換モジ
ュール１００４を介して、ネットワーク制御層１００６
に渡される。ネットワーク制御層１００６とネットワー
ク制御層１０１６との間では、ケーブルなどの物理的な
コネクション１０２０を介して、信号の授受が行われ
る。ＤＢシステム動作ノード１０１０のサーバ側メッセ
ージ交換モジュール１０１４は、ネットワーク制御層１
０１６からのメッセージを常時受け入れることができる
ように監視を行い、メッセージの到着を確認すると、そ
のメッセージをＤＢアプリケーション１０１２に渡す。
逆に、ＤＢアプリケーション１０１２からの結果出力
は、サーバ側メッセージ交換モジュール１０１４、ネッ
トワーク制御層１０１６、コネクション１０２０、ネッ
トワーク制御層１００６、端末側メッセージ交換モジュ
ール１００４を順にたどって、エンドユーザアプリケー
ション１００２に渡される。

【０１０５】さて、図１４に示すようなシステム構成に
おいて、フェールオーバ時には先行して稼働されている
１又は複数のＤＢアプリケーション１０１２の実行プロ
セス（以下、ＤＢプロセスと呼ぶ）に対するメモリ量の
変更処理が行われうる。このメモリ変更処理は、ＤＢこ
のとき、ＤＢプロセスを正常に終了させ、新たなメモリ
量で再実行させることで実現され、その際のエンドユー
ザアプリケーション１００２と各ＤＢアプリケーション
（ＤＢプロセス）１０１２との間のセッションの維持の
機能は主としてサーバ側メッセージ交換モジュール１０
１４が担う。すなわち、サーバ側メッセージ交換モジュ
ール１０１４は、エンドユーザから見て、セッション
（エンドユーザアプリケーションとＤＢアプリケーショ
ンのレベルで相互にメッセージの交換が可能な状態）が
あたかも切断されていない、つまり擬似的にセッション
がつながっているように見せる機能を有している。

【０１０６】図１５は、本実施の形態の特徴的処理を含
んだメモリ再編成処理を説明するフロー図である。この
処理は、基本的には図１３のメモリ再編成処理Ｓ９１５
の位置において実行される処理ステップを構成する。

【０１０７】監視エージェント１０は自ノードにおいて
先行して起動されているＤＢプロセスに対し決定される
新メモリ割り当て量を得ると（Ｓ１１００）、サーバ側
メッセージ交換モジュールに対し、ＤＢ再起動準備要求
信号を発する（Ｓ１１０５）。

【０１０８】この要求信号を受信したサーバ側メッセー
ジ交換モジュールは、セッション維持のためのセッショ
ン処理（詳細は後述する）を行い、監視エージェント１
０へ準備済み信号を送信する（Ｓ１１１０）。監視エー
ジェント１０は、この準備済み信号を受信した後、チェ
ックポイント処理を行う（Ｓ１１１５）。チェックポイ
ント処理は、ＤＢプロセスのメモリ空間にあるデータベ
ースのデータ断片と実際にディスクに記録されているデ
ータ断片の内容とが異なる場合に、メモリ上のデータ断
片をディスクに書き込む処理である。チェックポイント
処理Ｓ１１１５を行った後に、監視エージェント１０は
ＤＢシステムを停止させる（Ｓ１１２０）。なお、その
停止方法は、個々のＤＢシステムに依存する。

【０１０９】次に、監視エージェント１０は、各ＤＢプ
ロセス毎に、磁気ディスク装置等に格納されている全て
のＤＢパラメータファイルを読み出すループ処理を行う
（Ｓ１１２５，Ｓ１１４０）。このループ処理内では、
磁気ディスク装置１１３０から例えば一つずつパラメー
タファイルを読み込む。このパラメータファイルは、Ｄ
Ｂプロセスに割り当てるメモリ量等のＤＢプロセス起動
条件を外部から指定するためのファイルであり、ＤＢシ
ステムはこのパラメータファイルに応じた種々の条件で
起動される。なお、その起動の仕方は個々のＤＢシステ
ムに依存し様々である。さて、監視エージェント１０は
磁気ディスク装置１１３０から読み込んだパラメータフ
ァイルからＤＢプロセスに割り当てられるメモリ量情報
が取り出される（Ｓ１１３５）。

【０１１０】このようにループＳ１１２５〜Ｓ１１３５
を終了した段階では、あるＤＢシステムに対する種々の
起動条件におけるメモリ所要量が取り出される。監視エ
ージェント１０は、それらの中に、ステップＳ１１００
で得た新メモリ割り当て量に等しいものを見いだした場
合には、当該メモリ所要量に対応するパラメータファイ
ルを、再起動に用いるパラメータファイルとして選択す
る。また、それらの中に、新メモリ割り当て量に等しい
ものが存在しない場合には、その新メモリ割り当て量を
超えず、それに最も近いメモリ所要量を選択し、それに
対応するパラメータファイルを、再起動に用いるパラメ
ータファイルとして選択する（Ｓ１１４５）。

【０１１１】監視エージェント１０は選択した再起動用
パラメータファイルを用いてＤＢシステムの再起動を行
う（Ｓ１１５０）。そして、サーバ側メッセージ交換モ
ジュールに対してＤＢ起動済み信号を送信する（Ｓ１１
５５）。

【０１１２】サーバ側メッセージ交換モジュールはＤＢ
起動済み信号を受信に応じたセッション処理（後述す
る）を行う（Ｓ１１６０）。以上のようにして本実施の
形態のシステムはメモリ再編成処理を行う。

【０１１３】次に、サーバ側メッセージ交換モジュール
におけるセッション処理について説明する。サーバ側メ
ッセージ交換モジュールは、「セッションＩＤ」、「ト
ランザクションＩＤ」、「端末情報」、「メッセージチ
ェイン」といった情報の組をセッション毎に格納したセ
ッション情報テーブルを有している。

【０１１４】ここで、「セッションＩＤ」は、セッショ
ン毎に一意に割り当てられる識別子である。これはＤＢ
プロセスによって割り当てられ、サーバ側メッセージ交
換モジュールは、ＤＢプロセスからセッションＩＤを通
知される。

【０１１５】「トランザクションＩＤ」はトランザクシ
ョンを管理するための識別番号であり、これは、ＤＢプ
ロセスによって割り当てられ、サーバ側メッセージ交換
モジュールは、トランザクションが発生した時点でＤＢ
プロセスからトランザクションＩＤを通知される。な
お、「トランザクション」とは、あるセッションにおい
て、ＤＢに対して変更、追加、削除の操作が一回以上行
われる場合、この操作が最初に行われた時点から“確
定”メッセージがＤＢプロセスによって受け付けられる
までをいう。

【０１１６】「端末情報」は端末と通信するためにネッ
トワーク制御層において必要とされる情報である。ちな
みに、これはどのような種類のネットワーク（例えばＴ
ＣＰ／ＩＰ等）を使用するかに応じて異なり得る。

【０１１７】「メッセージチェイン」は、ＤＢシステム
動作ノード１０１０がエンドユーザ側ノード１０００か
ら受け取ったメッセージのうち、その時点ではＤＢプロ
セスに渡すことができないものを保留するための仕組み
である。図１６は、メッセージチェインの構造を説明す
る模式図である。セッション情報テーブル中には、メッ
セージチェインの先頭アドレスを表すメッセージチェイ
ンポインタ１２００が格納される。メッセージチェイン
ポインタ１２００が指し示すメモリ上、又は磁気ディス
ク上のアドレスから連続する領域に先頭のメッセージエ
ントリ１２０２が格納され、例えば、そのメッセージエ
ントリの前部にはメッセージの実体が、また後部には次
のメッセージエントリの先頭アドレスを示す次のポイン
タ１２０４が格納される。このように各メッセージエン
トリがそれに続くメッセージエントリの開始アドレス情
報を有することにより各メッセージエントリは順に接続
された鎖状の構造を形成する。ちなみに、サーバ側メッ
セージ交換モジュールは、先頭のメッセージについてＤ
Ｂプロセスに渡す等の処理を済ますと、その先頭メッセ
ージのエントリに格納された次メッセージエントリへの
ポインタ１２０４をメッセージチェインポインタ１２０
０に転記して、当該先頭メッセージエントリをチェイン
から外す。

【０１１８】サーバ側メッセージ交換モジュールには、
以下に説明する「通常状態」、「準備中状態」、「準備
済み状態」の３つの状態が定義される。

【０１１９】「通常状態」は、サーバ側メッセージ交換
モジュールが再起動要求信号を受け取っていない状態
で、エンドユーザアプリケーションとＤＢプロセスとが
制約なしにメッセージ交換できる状態である。

【０１２０】「準備中状態」は、再起動要求信号を受信
し、一つ以上のセッション情報にトランザクションＩＤ
が登録されている状態であり、エンドユーザアプリケー
ションとＤＢプロセスとのメッセージ交換には次の制約
が課される。

【０１２１】（１）新規のセッション要求は受け付けな
い、（２）セッション情報にトランザクションＩＤが設
定されているセッションは当該トランザクションが確
定、終了されるまでメッセージ交換を可能とする、
（３）セッション情報にトランザクションＩＤが設定さ
れていないセッションについてエンドユーザアプリケー
ションからメッセージが届いたとき（例えば、前トラン
ザクションが終了したセッションについて新たなトラン
ザクションの開始となるメッセージが届いたとき）は、
当該メッセージをメッセージチェインに登録しＤＢプロ
セスに伝達しない。

【０１２２】すなわち、準備中状態では、新たなセッシ
ョン、トランザクションの開設は認めず、その一方で現
存のトランザクションについてのみＤＢに対する実際の
処理を認め、その正常な終了を待つわけである。

【０１２３】「準備済み状態」は、再起動要求信号を受
信し、セッション情報が全く無い状態、または全てのセ
ッション情報にトランザクションＩＤが登録されていな
い状態であり、この場合には、エンドユーザアプリケー
ションとＤＢプロセスとのメッセージ交換には次の制約
が課される。

【０１２４】（１）新規のセッション要求は受け付けな
い、（２）セッション情報にエンドユーザアプリケーシ
ョンからメッセージが届いたときは、当該メッセージを
メッセージチェインに登録しＤＢプロセスに伝達しな
い。

【０１２５】すなわち、準備済み状態は、ＤＢシステム
を停止できる状態であり、メモリ再編成処理のための準
備ができたという意味である。この状態は、監視エージ
ェント１０からのＤＢ起動済み信号によって「通常状
態」へ遷移する。

【０１２６】図１７〜２０は、サーバ側メッセージ交換
モジュールでの処理を説明するためのフロー図である。
これらの図は、便宜上一つのフロー図を分割したもので
あり、それらに現れる同一記号で示されるノード同士は
互いに接続されることを意味する。例えば、図１７の円
内に“Ｆ”を記したノードＡから、図１８の同様に表さ
れるノードＦへ処理が渡されることになる。

【０１２７】サーバ側メッセージ交換モジュールは、Ｄ
Ｂプロセスからのメッセージ、ネットワークを介したエ
ンドユーザアプリケーションからのメッセージ、監視エ
ージェント１０からのメッセージを受け取ると（Ｓ１３
００）、それが監視エージェント１０からのメッセージ
であるか否かを判別する（Ｓ１３０５）。判定結果が
“Ｙｅｓ”である場合には、次に、当該メッセージが再
起動要求信号であるかどうかが判定される（Ｓ１３１
０）。判定結果が“Ｙｅｓ”であり、さらに続く判定に
よりセッション情報が存在し（Ｓ１３１５）、かつ既存
セッション情報を調査した結果、トランザクションＩＤ
が設定されている場合には（Ｓ１３２０）、サーバ側メ
ッセージ交換モジュールの状態を準備中状態とし（Ｓ１
３２５）、ステップＳ１３００に戻る。ステップＳ１３
１５、Ｓ１３２０において判定結果が“Ｎｏ”である場
合には、稼働中のトランザクションは既に存在していな
いので、サーバ側メッセージ交換モジュールの状態を準
備済み状態として（Ｓ１３３０）ステップＳ１３００に
戻る。

【０１２８】ステップＳ１３１０において監視エージェ
ント１０からのメッセージが再起動要求信号でない場合
は、ＤＢ起動済み信号であると判断される。この場合に
は、セッション情報のメッセージチェインに保留されて
いるメッセージが存在するならば（Ｓ１３３５）、全て
のセッション情報において保留されているメッセージを
ＤＢプロセスに送信してから（Ｓ１３４０）、一方、メ
ッセージが存在しないならばそのまま直ちに、サーバ側
メッセージ交換モジュールの状態を通常状態に変更する
（Ｓ１３４５）。

【０１２９】また、ステップＳ１３００で受け取ったメ
ッセージがＤＢプロセスからのものである場合には（Ｓ
１３０５，Ｓ１４００）、それがトランザクション確定
済みメッセージであるかどうかが判定される（Ｓ１４０
５）。判定結果が“Ｙｅｓ”である場合には、当該メッ
セージがどのセッションに対する返答メッセージかを調
べ、そのセッションに対するセッション情報のトランザ
クションＩＤをクリアする（Ｓ１４１０）。その結果、
全てのセッションのトランザクションＩＤがクリアされ
た場合（Ｓ１４１５）、サーバ側メッセージ交換モジュ
ールの状態が準備中であれば（Ｓ１４２０）、それを準
備済み状態に変更し、監視エージェント１０に準備済み
信号を送信して（Ｓ１４２５）、ステップＳ１３００に
戻る。一方、まだトランザクションＩＤが確定していな
いセッションがある場合は（Ｓ１４１５）、サーバ側メ
ッセージ交換モジュールはそれまでの状態（通常状態又
は準備中状態）を維持しステップＳ１３００に戻る。ま
た、ステップＳ１４２０においてサーバ側メッセージ交
換モジュールの状態が準備中でない場合、具体的には通
常状態である場合にも、サーバ側メッセージ交換モジュ
ールはそれまでの通常状態を維持して、ステップＳ１３
００に戻る。なお、ステップＳ１４２０では、先行する
ステップＳ１４１０までにおいてまだトランザクション
が存在したので準備済み状態ではあり得ない。

【０１３０】ステップＳ１４０５において、ＤＢプロセ
スからのメッセージがトランザクション確定済みメッセ
ージではなく（Ｓ１４０５）、かつ当該メッセージ中に
トランザクションＩＤが含まれている場合（Ｓ１４３
０）には、新たなトランザクションの発生を示す返答メ
ッセージである。この場合には、当該メッセージがどの
セッションに対する返答メッセージであるかを調べ、そ
のセッションに対応するセッション情報に当該トランザ
クションＩＤを設定し（Ｓ１４３５）、セッション情報
に基づいてエンドユーザ側ノード１０００を特定し当該
メッセージを返し（Ｓ１４４０）、ステップＳ１３００
に戻る。なお、サーバ側メッセージ交換モジュールの状
態が準備中である場合には、このような場合は生じな
い。なぜなら、新たなトランザクションはエンドユーザ
アプリケーションからの要求に応じて発生するものであ
るが、サーバ側メッセージ交換モジュールの状態が準備
中である場合には、後述するようにエンドユーザアプリ
ケーションからのメッセージはメッセージチェインに格
納されＤＢプロセスには伝達されないので、トランザク
ションが発生されることも、それを通知するメッセージ
が生じることもないからである。

【０１３１】一方、ステップＳ１４３０において、判定
結果が“Ｎｏ”である場合には、現存するトランザクシ
ョンに対する処理に応じたメッセージであるので、セッ
ション情報にトランザクションＩＤを設定せずに、ステ
ップＳ１４４０の処理を行って、ステップＳ１３００に
戻る。

【０１３２】また、ステップＳ１３００で受け取ったメ
ッセージがエンドユーザ側ノード１０００からのもので
ある場合には（Ｓ１３０５，Ｓ１４００）、処理はサー
バ側メッセージ交換モジュールの状態が通常状態である
か否かで分岐する（Ｓ１５００）。

【０１３３】通常状態である場合には（Ｓ１５００）、
図１９に示す処理が行われる。まず、当該メッセージが
新規セッション確立要求である場合には（Ｓ１５０
５）、ＤＢプロセスにメッセージを送信する（Ｓ１５１
０）。そして、それに応じてＤＢプロセスがセッション
を確立する処理を行い（Ｓ１５１５）、セッション確立
通知をサーバ側メッセージ交換モジュールに返すと、サ
ーバ側メッセージ交換モジュールはそのＤＢプロセスか
らの応答からセッションＩＤを取得し、初期化状態の新
規のセッション情報を登録し（Ｓ１５２０）、ステップ
Ｓ１３００に戻る。

【０１３４】一方、ステップＳ１５０５にて、新規セッ
ション確立要求ではないと判定された場合には、ＤＢプ
ロセスにメッセージを送信し（Ｓ１５２５）、ステップ
Ｓ１３００に戻る。

【０１３５】ステップＳ１５００において通常状態では
ないと判定された場合、具体的にはサーバ側メッセージ
交換モジュールが準備中又は準備済みの状態である場合
には、上述したようなエンドユーザ側ノード１０００と
ＤＢプロセスとのメッセージ交換には制約が課せられ
る。まずメッセージが新規セッション確立要求である場
合（Ｓ１６００）には、エンドユーザ側ノード１０００
にエラーが返され（Ｓ１６０５）、ステップＳ１３００
に戻る。

【０１３６】メッセージが新規セッション確立要求でな
い場合（Ｓ１６００）には、サーバ側メッセージ交換モ
ジュールの状態が準備済み状態か、準備中状態かに応じ
て分岐する（Ｓ１６１０）。準備済み状態の場合には、
セッション情報のメッセージチェインに当該メッセージ
を登録して（Ｓ１６１５）ステップＳ１３００に戻る。
準備中状態の場合には、メッセージからセッションを特
定する（Ｓ１６２０）。そして、対応するセッション情
報にトランザクションＩＤが登録されている場合には、
ＤＢプロセスにメッセージを伝達し（Ｓ１６３０）、ス
テップＳ１３００に戻る。トランザクションＩＤが登録
されていない場合には、メッセージチェインへの登録処
理Ｓ１６１５を行い、ステップＳ１３００に復帰する。
図２１は、セッション情報にトランザクションＩＤが登
録されているセッションに生じる状態遷移の例を示す状
態遷移図である。図に於いて、時間は上から下に経過
し、各状態間の実線の矢印は、エンドユーザ側ノード１
０００、サーバ側メッセージ交換モジュール及びＤＢプ
ロセス間のメッセージ等の送受信を表し、サーバ側メッ
セージ交換モジュールの通常状態、準備中状態、及び準
備済み状態間の点線の矢印はそれら状態間の状態遷移を
表す。

【０１３７】エンドユーザ側ノード１０００とＤＢプロ
セスとは、通常状態のサーバ側メッセージ交換モジュー
ルを介してメッセージ送信、それに対する結果通知を行
っている（Ｐ１７００）。この状態でサーバ側メッセー
ジ交換モジュールは、監視エージェント１０からフェー
ルオーバのためのＤＢ再起動要求信号を受信すると、準
備中状態に遷移する（Ｓ１７０５）。以降、エンドユー
ザ側ノード１０００とＤＢプロセスとは、既存のトラン
ザクションがあるうちは、準備中状態のサーバ側メッセ
ージ交換モジュールを介して、メッセージ送信、それに
対する結果通知を行って処理を進める（Ｐ１７１０）。
そして、エンドユーザ側ノード１０００からＤＢプロセ
スにトランザクションが確定したことが通知され、それ
に対する確定処理済みの通知がＤＢプロセスからサーバ
側メッセージ交換モジュールに送信されると（Ｓ１７２
０）、サーバ側メッセージ交換モジュールは状態を準備
済み状態に遷移させ（Ｓ１７２５）、監視エージェント
１０に対し、ＤＢ再起動処理の準備ができたことを通知
する準備済み信号を発信する。以降、監視エージェント
１０はＤＢ再起動処理を実施し（Ｓ１７３０）、それを
終了するとサーバ側メッセージ交換モジュールに対しＤ
Ｂ起動済み信号を送信する。サーバ側メッセージ交換モ
ジュールは、この準備済み信号送信からＤＢ起動済み信
号受信までの間、エンドユーザ側ノード１０００からメ
ッセージＳ１７３５を受信しても、それをＤＢプロセス
に渡さずメッセージチェインに保留する。そしてサーバ
側メッセージ交換モジュールは、ＤＢ起動済み信号を受
信すると、状態を準備済みから通常状態に復帰させる
（Ｓ１７４０）とともに、メッセージチェインに保留さ
れていたメッセージをＤＢプロセスに渡す（Ｓ１７４
５）。ＤＢプロセスの保留メッセージに対する処理は、
保留されずにそのまま渡されたメッセージに対するもの
と変わりなく、ＤＢプロセスはその処理結果をエンドユ
ーザ側ノード１０００に通知する（Ｓ１７５０）。

【０１３８】以上のような本実施の形態の仕組みによれ
ば、フェールオーバ対象のＤＢシステム起動に必要な空
きメモリ量を確保するためのメモリ再編成処理において
稼働中のＤＢシステムを停止する場合に、実行中のトラ
ンザクションは正常に終了され、またエンドユーザが発
したメッセージは拒否されることなく、例えばＤＢ再起
動中においてもメッセージチェインに保留され、再起動
終了後に引き続いて対応する処理が行われる。つまり、
ＤＢ再起動時におけるＤＢプロセスの処理内容自体の継
続性が担保されるとともに、エンドユーザに対するイン
ターフェースとしても、ＤＢシステムが途切れることな
く処理を行っているように見せることができる。

【０１３９】

【発明の効果】本発明に係る計算機システムによれば、
ネットワーク接続された各ノードがそれぞれの稼働状態
を監視し、その監視結果に基づいて実行障害を生じたノ
ードの処理を引き継がせる代替ノードを選択するので、
代替ノードとしてそのときのシステムの状態に応じた最
適なものが動的に選択されるという効果が得られる。

【０１４０】また本発明に係る計算機システムによれ
ば、各ノードのプロセッサ負荷の監視結果に基づいて代
替ノードが選択される。例えばプロセッサ負荷が最小に
なるノードが代替ノードに選択される。これにより、プ
ロセッサ負荷が厳しくないノードが代替ノードに選択さ
れ、プロセッサ負荷の面でシステム内での負荷分散が図
られ、処理の速度の確保が図られるという効果が得られ
る。

【０１４１】また本発明に係る計算機システムによれ
ば、各ノードのメモリ空き容量の監視結果に基づいて代
替ノードが選択される。例えばメモリ空き容量が最大に
なるノードが代替ノードに選択される。これにより、メ
モリの余裕の比較的大きいノードが代替ノードに選択さ
れ、メモリ容量の面でシステム内での負荷分散が図ら
れ、スワッピングが抑制されることによりキャッシュの
ヒット率が向上したり、スラッシングが防止されること
により高い処理効率が得られるといった効果が得られ
る。

【０１４２】また本発明に係る計算機システムによれ
ば、各ノードのプロセッサ負荷とメモリ空き容量との双
方の監視結果に基づいて代替ノードが選択される。これ
により、プロセッサ負荷及びメモリ容量の両方の面を考
慮してシステム内での負荷分散が図られ、処理効率が確
保されるという効果が得られる。

【０１４３】また本発明に係る計算機システムによれ
ば、代替ノードのメモリ空き容量が実行障害を生じた処
理プログラムの引き継ぎに不足している場合には、代替
ノードで先行して起動されているプログラムへの割り当
てメモリ容量が縮小されるので、フェールオーバ処理が
一層、確実に実行されるという効果がある。

【０１４４】また本発明に係る計算機システムによれ
ば、先起動プログラムを停止してメモリ容量の割当変更
を行う際に、セッション情報に基づいて既設セッション
中のトランザクションが継続中か否かを判別して継続中
のトランザクションに対するメッセージのみが先起動プ
ログラムに渡される。また当該セッションに対する他の
メッセージはメモリ容量の割当変更が完了するまでセッ
ション情報に保留され、割当変更後に通常通りに処理さ
れる。これらにより、先起動プログラムを停止し、その
メモリ使用量を縮小してフェールオーバ対象の処理プロ
グラム起動に必要な空きメモリ量を確保する場合に、先
起動プログラムの処理内容の継続性が担保され、またエ
ンドユーザには先起動プログラムが停止されることが意
識されないインターフェースが提供されるという効果が
得られる。

【図面の簡単な説明】

【図１】 本発明の実施の形態に係る計算機システムの
構成を説明するための模式図である。

【図２】 本発明の実施の形態に係る監視情報リポジト
リに格納される情報の一例の論理構成を示す模式図であ
る。

【図３】 本発明の実施の形態に係る監視エージェント
のＤＢアプリケーション状態監視に関する初期処理を説
明するフロー図である。

【図４】 本発明の実施の形態に係る監視エージェント
の監視処理の概略を説明するフロー図である。

【図５】 本発明の実施の形態に係る監視エージェント
による自ノードに対するＤＢ状況チェック処理Ｓ１２５
を説明するフロー図である。

【図６】 本発明の実施の形態に係る監視エージェント
による全ノード処理を説明するフロー図である。

【図７】 本発明の実施の形態に係る監視エージェント
による全ノード処理を説明するフロー図である。

【図８】 実施の形態２に係る監視エージェントによる
ＤＢアプリケーションダウン時の処理を示すフロー図で
ある。

【図９】 実施の形態２に係る監視エージェントによる
ノードダウン時の処理を示すフロー図である。

【図１０】 実施の形態２に係る監視エージェントにお
けるフェールオーバ指示に応じて行われるＤＢアプリケ
ーション再起動処理を説明するフロー図である。

【図１１】 実施の形態２に係る監視エージェントによ
るＤＢアプリケーションの実行障害検出時の動作の一例
を説明する模式図である。

【図１２】 実施の形態３に係る監視エージェントの代
替ノード選択方法を説明するフロー図である。

【図１３】 実施の形態５に係る監視エージェントによ
る、メモリ再編成を含んだフェールオーバ処理を説明す
るフロー図である。

【図１４】 実施の形態６に係る計算機システムにおけ
るエンドユーザ側ノードとＤＢシステム動作ノードとの
機能レイヤ構成例を示す模式図である。

【図１５】 実施の形態６に係る監視エージェントによ
るメモリ再編成処理を説明するフロー図である。

【図１６】 実施の形態６に係るメッセージチェインの
構造を説明する模式図である。

【図１７】 実施の形態６に係るサーバ側メッセージ交
換モジュールでの処理を説明するためのフロー図であ
る。

【図１８】 実施の形態６に係るサーバ側メッセージ交
換モジュールでの処理を説明するためのフロー図であ
る。

【図１９】 実施の形態６に係るサーバ側メッセージ交
換モジュールでの処理を説明するためのフロー図であ
る。

【図２０】 実施の形態６に係るサーバ側メッセージ交
換モジュールでの処理を説明するためのフロー図であ
る。

【図２１】 実施の形態６における、セッション情報に
トランザクションＩＤが登録されているセッションに生
じる状態遷移の例を示す状態遷移図である。

【符号の説明】

１，２，３ ノード、１０ 監視エージェント、２０
共有ディスク、２５監視情報リポジトリ、１０００ エ
ンドユーザ側ノード、１００２ エンドユーザアプリケ
ーション、１００４ 端末側メッセージ交換モジュー
ル、１００６ネットワーク制御層、１０１０ ＤＢシス
テム動作ノード、１０１２ ＤＢアプリケーション、１
０１４ サーバ側メッセージ交換モジュール、１０１６
ネットワーク制御層、１０２０ コネクション。

Claims (7)

(57)【特許請求の範囲】
1. 【請求項１】 それぞれ処理プログラムを実行可能な複
   数のノードがネットワーク接続された計算機システムに
   おいて、 前記各ノードは、 前記各ノードそれぞれの稼働状況を監視する監視手段
   と、 前記監視手段が任意の前記ノードでの前記処理プログラ
   ムの実行障害を検知したとき、代替ノードを選択する代
   替ノード選択手段と、 前記実行障害を生じたノードから前記代替ノードへ前記
   処理プログラムの実行を引き継がせるフェールオーバ手
   段と、 を有し、 前記監視手段は、前記各ノードそれぞれのプロセッサ負
   荷を監視し、 前記代替ノード選択手段は、前記監視手段により得られ
   た前記プロセッサ負荷に基づいて前記代替ノードを選択
   すること、 を特徴とする計算機システム。
2. 【請求項２】 請求項１記載の計算機システムにおい
   て、 前記代替ノード選択手段は、前記プロセッサ負荷が最小
   であるノードを前記代替ノードとして選択すること、 を特徴とする計算機システム。
3. 【請求項３】 それぞれ処理プログラムを実行可能な複
   数のノードがネットワーク接続された計算機システムに
   おいて、 前記各ノードは、 前記各ノードそれぞれの稼働状況を監視する監視手段
   と、 前記監視手段が任意の前記ノードでの前記処理プログラ
   ムの実行障害を検知したとき、代替ノードを選択する代
   替ノード選択手段と、 前記実行障害を生じたノードから前記代替ノードへ前記
   処理プログラムの実行を引き継がせるフェールオーバ手
   段と、 を有し、 前記監視手段は、前記各ノードそれぞれのメモリ空き容
   量を監視し、 前記代替ノード選択手段は、前記監視手段により得られ
   た前記メモリ空き容量に基づいて前記代替ノードを選択
   すること、 を特徴とする計算機システム。
4. 【請求項４】 請求項３記載の計算機システムにおい
   て、 前記代替ノード選択手段は、前記メモリ空き容量が最大
   であるノードを前記代替ノードとして選択すること、 を特徴とする計算機システム。
5. 【請求項５】 それぞれ処理プログラムを実行可能な複
   数のノードがネットワーク接続された計算機システムに
   おいて、 前記各ノードは、 前記各ノードそれぞれの稼働状況を監視する監視手段
   と、 前記監視手段が任意の前記ノードでの前記処理プログラ
   ムの実行障害を検知したとき、代替ノードを選択する代
   替ノード選択手段と、 前記実行障害を生じたノードから前記代替ノードへ前記
   処理プログラムの実行を引き継がせるフェールオーバ手
   段と、 を有し、 前記監視手段は、前記各ノードそれぞれのプロセッサ負
   荷とメモリ空き容量とを監視し、 前記代替ノード選択手段は、前記監視手段により得られ
   た前記プロセッサ負荷と前記メモリ空き容量とに基づい
   て前記代替ノードを選択すること、 を特徴とする計算機システム。
6. 【請求項６】 それぞれ処理プログラムを実行可能な複
   数のノードがネットワーク接続された計算機システムに
   おいて、 前記各ノードは、 前記各ノードそれぞれの稼働状況を監視する監視手段
   と、 前記監視手段が任意の前記ノードでの前記処理プログラ
   ムの実行障害を検知したとき、代替ノードを選択する代
   替ノード選択手段と、 前記実行障害を生じたノードから前記代替ノードへ前記
   処理プログラムの実行を引き継がせるフェールオーバ手
   段と、 を有し、 前記監視手段は、前記各ノードそれぞれのメモリ空き容
   量を監視し、 前記フェールオーバ手段は、 前記代替ノードの前記メモリ空き容量が前記処理プログ
   ラムの引き継ぎに十分か否かを判断する容量比較手段
   と、 前記メモリ空き容量が不足するときは、前記代替ノード
   で先行して起動されている先起動プログラムに割り当て
   られるメモリ容量を縮小するメモリ割当変更手段と、 を有することを特徴とする計算機システム。
7. 【請求項７】 請求項６記載の計算機システムにおい
   て、 前記代替ノードの前記先起動プログラムと当該先起動プ
   ログラムを前記ネットワークを介して利用するユーザノ
   ードとの間のセッション情報を含んだセッション情報テ
   ーブルを有し、 前記フェールオーバ手段は、前記メモリ容量の割当変更
   を行う際に、前記セッション情報に基づいて既設セッシ
   ョン中のトランザクションが継続中か否かを判別して継
   続中のトランザクションに対するメッセージのみ前記先
   起動プログラムに渡し、当該セッションに対する他のメ
   ッセージは前記割当変更が完了するまで前記セッション
   情報に保留するメッセージ取扱手段を有し、 前記メモリ割当変更手段は、前記トランザクションが終
   了したときに、前記先起動プログラムの実行を停止して
   メモリ割当変更を行うこと、 を特徴とする計算機システム。