JPH11184825A

JPH11184825A - クラスタシステム

Info

Publication number: JPH11184825A
Application number: JP9350391A
Authority: JP
Inventors: Hiroyuki Yamanishi; 宏幸山西; Akio Saito; 彰男斎藤
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1997-12-19
Filing date: 1997-12-19
Publication date: 1999-07-09

Abstract

(57)【要約】【課題】クラスタシステムにおいて、計算機及びアプ
リケーションの状態変化に応じてアプリケーションの起
動、停止、起動計算機の決定及び引き継ぎ計算機の決定
を動的に行い、クラスタシステムの最適化を図る。【解決手段】状態監視部２０、負荷更新部３０が計算
機及びアプリケーションの状態を示す情報を取り込む。
取り込んだ情報は、共用データ記憶部１０で管理する。
構成制御部４０は、トリガを状態監視部２０、負荷更新
部３０から受け取ると、アプリケーションの引き継ぎや
引き継ぎ計算機の変更などの指示をクラスタ管理機構９
００に出す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、分散した複数の
計算機を一まとまりにして構成したクラスタシステムに
関するものである。特に、クラスタシステムでのアプリ
ケーションの引き継ぎに関するものである。

【０００２】

【従来の技術】クラスタシステムにおいては、複数の計
算機で１つ以上のアプリケーションを実行し、アプリケ
ーション、もしくはアプリケーションを実行中の計算機
が異常停止した場合、クラスタ内の他の計算機でアプリ
ケーションを引き継いで実行する。この、アプリケーシ
ョンを引き継いで実行する計算機を引継ぎ計算機と呼
ぶ。引継ぎ計算機は、クラスタシステム内で、予め設定
される。このような、アプリケーションの切り替えを示
した従来の技術として、特開平６−２８２０６号公報に
開示された「クラスタシステムのデータ処理ステーショ
ン障害時の復旧方式」がある。この技術は、運用側の故
障により無条件に予備側に切り替えるものである。だ
が、その後の新しい運用側の障害には対処できないとい
う欠点があった。

【０００３】

【発明が解決しようとする課題】このように、従来のク
ラスタの構成制御方式では、自動引継ぎ制御しか行われ
ておらず、異常停止した計算機が復帰した等の事象によ
ってクラスタ構成計算機メンバーが変更された場合、ア
プリケーションの引継ぎ計算機の再設定などは、システ
ム管理者がコマンド等を実行して行う必要があった。ま
た、アプリケーションが計算機に引き継がれる際、計算
機やアプリケーションの状況に対応した引継ぎ計算機の
自動変更処理が行われておらず、重複障害発生時に１つ
の計算機にアプリケーションが集中してしまうことなど
もある。

【０００４】この発明は、上記のような問題点を解決す
るためになされたものであり、計算機及びアプリケーシ
ョンの状態変化に応じて、アプリケーションの起動、停
止、起動計算機の決定を自動的に行うクラスタシステム
を得ることを目的としている。また、計算機及びアプリ
ケーションの状態変化に応じて、動的に引継ぎ計算機の
決定を行い、クラスタ構成を最適に制御するクラスタシ
ステムを得ることを目的としている。また、予め形式の
決まった運転形態を簡単に設定することができる機能を
備えたクラスタシステムを得ることを目的としている。

【０００５】

【課題を解決するための手段】この発明に係るクラスタ
システムは、１つ以上のアプリケーションを実行可能な
複数台のサーバをメンバーとして構成されるクラスタシ
ステムであって、上記複数台のサーバのいずれか１台に
上記アプリケーションを実行させるとともに、上記１台
のサーバが上記アプリケーションを実行不可能である時
に他のサーバに上記アプリケーションの実行を引き継が
せるクラスタシステムにおいて、以下の要素を有するこ
とを特徴とする。（ａ）上記複数台のサーバから共通して利用可能な共用
データとして、上記複数台のサーバの状態を示すサーバ
状態情報と上記複数台のサーバの負荷を示す負荷情報と
上記アプリケーションの動作に関するアプリケーション
動作情報とを記憶する共用データ記憶部、（ｂ）上記複
数台のサーバの状態を取得して上記サーバ状態情報を更
新する状態監視部、（ｃ）上記複数台のサーバの負荷を
取得して上記負荷情報を更新する負荷更新部、（ｄ）上
記共用データ記憶部を参照して、上記アプリケーション
と上記複数台のサーバとの対応を動的に制御する構成制
御部。

【０００６】上記共用データ記憶部は、上記クラスタシ
ステムの制御に関する規約を定義する規約情報を記憶す
るとともに、上記構成制御部は、上記クラスタシステム
の起動の際のクラスタ構成時に上記規約情報と上記サー
バ状態情報とを参照して上記アプリケーション動作情報
を作成することを特徴とする。

【０００７】上記構成制御部は、上記クラスタシステム
のクラスタ構成後に新たなサーバが起動してメンバーと
して上記クラスタシステムに参加した時、上記サーバ状
態情報と上記アプリケーション動作情報とを参照して上
記アプリケーションの引継ぎを行うことを特徴とする。

【０００８】上記構成制御部は、上記クラスタシステム
のクラスタ構成後にメンバーの移動が発生した時、上記
サーバ状態情報と上記アプリケーション動作情報とを参
照して上記アプリケーションを引き継ぐ引継ぎサーバを
決定して上記アプリケーション動作情報を更新すること
を特徴とする。

【０００９】上記構成制御部は、上記複数のサーバのい
ずれかの負荷状態に変化が起こった時、上記サーバ負荷
情報と上記アプリケーション動作情報とを参照して上記
アプリケーションの引継ぎを行うことを特徴とする。

【００１０】上記規約情報は、ユーザが設定する定義フ
ァイルをもとに作成されることを特徴とする。

【００１１】上記クラスタシステムは、パターン化され
たテンプレートを予め用意し、用意したテンプレートの
いずれかをもとに上記規約情報を作成することを特徴と
する。

【００１２】上記負荷更新部は、所定のタイミングで定
期的に上記複数台のサーバの負荷を取得して上記負荷情
報を更新し、上記構成制御部は、上記負荷情報を参照し
てアプリケーション引継ぎに際し、上記アプリケーショ
ンを引き継ぐ引継ぎサーバを決定して上記アプリケーシ
ョンの引継ぎを行うことを特徴とする。

【００１３】

【発明の実施の形態】実施の形態１．最初に、この発明
のクラスタシステムが実現する機能の概要を説明する。１．実現機能の概要（ａ）計算機の初期起動時、即ち、個々の計算機が電源
投入され、クラスタの初期構成が行われる時、クラスタ
内のアプリケーションの引継ぎ計算機を自動制御し、決
定する機能。（ｂ）計算機の起動時、アプリケーションを自動的に引
き継がせる機能。（ｃ）計算機異常停止時又は異常停止からの復帰時な
ど、クラスタを構成する計算機に変更があった際、クラ
スタ内のアプリケーションの引継ぎ計算機を自動制御し
て変更する機能。（ｄ）計算機が通常、起動している状態（ＣＰＵ、メモ
リ、ネットワーク）の負荷を監視し、その状態の変化に
応じて、アプリケーションを自動制御する機能。（ｅ）プログラミングを行うことなく、定義ファイルを
設定するだけで、構成の再構築制御を行う機能。（ｆ）ホットスタンバイ、ロードシェア、Ｎ：１バック
アップ型など、予め形式の決まった運転形態を簡単に設
定することができる機能。（ｇ）アプリケーションを自動で引き継がせる場合、各
計算機の負荷も考慮し、引継ぎ計算機を決定する機能。

【００１４】次に、図を用いてこの発明のクラスタシス
テムの構成を説明する。図１は、この発明のクラスタシ
ステムの構成の一例を示すブロック図である。図におい
て、９００は既存のクラスタ管理機構である。この発明
のクラスタシステムでは、サーバ１００ａ〜１００ｃ
（計算機ともいう）の状態及びアプリケーションの状態
に関する情報をサーバ１００ａの状態監視部２０でクラ
スタ管理機構９００から取り込み、それらの情報を共用
データ記憶部１０ａに記憶する（矢印２２０）。この共
用データ記憶部１０ａは、矢印２１０に示すように、他
のサーバの共用データ記憶部１０ｂ、共用データ記憶部
１０ｃにコピーして同じ状態に置くよう管理されるもの
とする。また、負荷更新部３０ａ〜３０ｃは、サーバ１
００ａ〜１００ｃの負荷に関する情報を得て共用データ
記憶部１０ａに記憶する（２３０ａ〜２３０ｃ）。構成
制御部４０は、システムの状態変化を状態監視部２０か
ら受けると、又はシステムの負荷の変化を各計算機に存
在する負荷更新部３０ａ〜３０ｃから受けると、アプリ
ケーションの引継ぎや、引継ぎ計算機の変更などの指示
をクラスタ管理機構９００へ出す。状態監視部２０と構
成制御部４０を構成制御処理部１６０と呼ぶ。ここで
は、構成制御処理部１６０がサーバ１００ａ上で動作す
る場合を示しているが、サーバ１００ｂやサーバ１００
ｃ上で動作しても構わない。

【００１５】以下に、前述したクラスタシステムの機能
を実現する実現手段について説明する。２．実現手段の概要（ａ）クラスタの初期起動の通知を受けた構成制御部４
０は、実行中のアプリケーションの引継ぎ計算機を、ア
プリケーションを実行していない計算機に設定する。（ｂ）ある計算機が動作中のクラスタに参加してきた
時、その通知を受けた構成制御部４０は、その計算機上
で動作すべきアプリケーションを検索し、動作すべきア
プリケーションが検索されれば、そのアプリケーション
を引き継がせる指示を出す。（ｃ）クラスタに参加中の計算機が停止したり、動作中
のクラスタにある計算機が参加した場合、その通知を受
けた構成制御部４０は、引継ぎ計算機を変更する指示を
出す。（ｄ）各計算機の負荷状態（ＣＰＵ、メモリ、ネットワ
ーク）を監視し、その状態を管理する機能を構成制御部
４０に持たせる。実行中のアプリケーションをその負荷
の状況に応じて、引継ぎ計算機に引き継がせる指示を出
す。（ｅ）計算機が異常停止した時、停止していた計算機が
起動した時のアプリケーションの動作について定義した
制御動作定義ファイル３５を管理コマンドを用いて、各
計算機へ配布／配置する。構成制御部４０は、各要素に
変化があった場合、その情報に従った自動制御を行う。（ｆ）予めパターン化されたクラスタの自動構成制御を
行うための定義情報のテンプレートを用意し、ユーザに
開放する。テンプレートをもとに、制御動作定義ファイ
ル３５が作成される。（ｇ）負荷更新部３０ａ〜３０ｃが定期的に負荷の情報
を取り込み、取り込んだ情報を共用データ記憶部１０ａ
〜１０ｃへと反映する。各計算機の負荷情報を管理する
管理機能を持った構成制御部４０が、その負荷情報が示
す負荷状況に応じて最適なアプリケーションの引継ぎを
指示する。図２に、アプリケーションの引継ぎの例を示
す。図２は、サーバ１００ｂが異常停止し、アプリケー
ションＡＰ３がサーバ１００ｃに引き継がれた状態を示
している。

【００１６】３．ハードウェア構成図３は、この発明のクラスタシステムのハードウェア構
成の一例を示す図である。ハードウェアは、各ローカル
ディスク２００ａ〜２００ｎを持つＮ台のサーバ１００
ａ〜１００ｎ、各サーバ間の通信路であるネットワーク
１０００から構成される。

【００１７】４．ソフトウェア構成図４，図５は、マルチサーバ上のソフトウェアの位置付
けを説明する図である。ソフトウェアは、大別して下記
部位から構成される。（ａ）既存のクラスタ管理機構９００アプリケーションパッケージを、定義された情報に従っ
てサーバに割り付け、実行させるクラスタ管理機構であ
る。クラスタ管理機構９００は、アプリケーション実行
中のサーバが異常停止した場合、アプリケーション毎に
定義されている別サーバで再起動するなどの制御を行
う。本実施の形態では、ヒューレットパッカード社（米
国のＨｅｗｌｅｔｔ−ＰａｃｋａｒｄＣｏｍｐａｎ
ｙ、ＨＰ社ともいう。Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ
Ｃｏｍｐａｎｙ、ＨＰはＨＰ社の商標又は登録商標）
のＭＣ／ＳｅｒｖｉｃｅＧｕａｒｄをクラスタ管理機構
として使用する場合を例にとって説明する。クラスタ管
理機構は、既存の製品であり、本発明以前の従来からあ
る技術である。

【００１８】（ｂ）構成制御処理部１６０クラスタを構成する全てのサーバ上で動作可能な構成制
御処理部１６０がある。構成制御処理部１６０は、状態
監視部２０と構成制御部４０からなる。構成制御処理部
１６０は、クラスタを構成する全てのサーバのうち、い
ずれかのサーバ上で動作する。構成制御処理部１６０
は、全てのサーバで動作可能なもので、クラスタ管理機
構９００に対して予め設定することにより、下記のよう
にクラスタ管理機構９００によって起動される。・初期起動クラスタ管理機構９００の設定（起動サーバの優先順位
指定）に従い、現状構成内の高優先順位のサーバで起動
される。・動作サーバ停止時の再起動動作中のサーバが異常停止した場合、クラスタ管理機構
の設定に記述された次優先順位のサーバで再起動され、
引き続き動作する。図５は、サーバ１００ａが停止し、
構成制御処理部１６０がサーバ１００ｂで引き続き動作
する場合を示している（矢印２１９）。この初期／再起
動のメカニズムは、既存のクラスタ管理機構が行う。構
成制御処理部１６０は、前述した機能を実現し、アプリ
ケーションの移動先サーバの決定などを行う。決定され
た移動先のサーバの指示は、クラスタ管理機構９００に
対して行われる。また、アプリケーションの起動、移動
等の制御は、クラスタ管理機構９００により行われる。
クラスタ管理機構９００は、構成制御処理部１６０から
の指示に従い動作する。即ち、この実施の形態の構成制
御処理部１６０は、クラスタ管理機構９００の存在を前
提としている。構成制御処理部１６０は、直接アプリケ
ーションを起動したり、アプリケーションの引き継ぎを
行ったりすることはない。

【００１９】（ｃ）共用データ記憶部１０ａ〜１０ｃネットワークを介した共用メモリ機能（あるサーバで書
き込んだ内容を別サーバに反映することで、別サーバが
その内容を参照できる機能）をサポートする記憶部であ
る。構成制御処理部１６０が別サーバで再起動された場
合の引き継ぎデータとして使用される。この共用メモリ
機能の実現方式は問わないものとする。この実施の形態
では、この共用メモリ機能にサポートされた共用データ
記憶部を用いる場合について説明する。データの共用方
式には、特殊な装置や共用ディスクを使用した様々な方
式が考えられるが、本実施の形態は、ネットワークを介
した方式で記述する。

【００２０】（ｄ）アプリケーションプロセス（アプリ
ケーションＡＰ１〜ＡＰ３）構成制御処理部１６０の動作結果として、障害時のバッ
クアップサーバ設定などが行われるユーザのアプリケー
ションプログラム。実際のサーバ起動は、クラスタ管理
機構が行う。本発明のクラスタシステムは、クラスタ管
理機構９００に対して指示を出す。図５の矢印２３４
は、アプリケーションＡＰ１、アプリケーションＡＰ２
がサーバ１００ａの停止に伴い、サーバ１００ｃで引き
継ぎ実行される状態を示している。その際、構成制御処
理部１６０は、共用データ記憶部１０ｂに定義されてい
る情報を参照してクラスタ管理機構９００に対してアプ
リケーションの起動指示を出し（２４６）、指示を受け
取ったクラスタ管理機構９００は、２３２に示すよう
に、アプリケーションＡＰ１，ＡＰ２をそれぞれ起動す
る。構成制御処理部１６０は、２２６に示すように、ク
ラスタ管理機構９００から各サーバ及びアプリケーショ
ンの状態を取得する。

【００２１】５．システム動作概要次に、クラスタシステムの動作について説明する。図６
は、クラスタシステムの動作概要図である。大きな流れ
は、以下のようになる。（１）常時実行の状況収集常時、下記情報を取り込み、共用データ記憶部に書き込
み、他サーバの共用データ記憶部に反映を行う。（ａ）サーバ状態状態監視部２０は、クラスタにサーバが組み込まれてい
るか否かの状態をクラスタ管理機構９００より取り込み
（矢印２２５）、全サーバの状態を管理する。サーバの
突然の異常停止や異常停止後の立ち上がりなどを検知す
る。共用データ記憶部は、２１０に示すように、他サー
バに反映を行う。（ｂ）各サーバの負荷状態各サーバの負荷更新部３０ａ〜３０ｃは、自サーバの負
荷をそれぞれ取り込み、共用データ記憶部へ書き込む。
書き込まれた各サーバの負荷は、それぞれ他サーバへ反
映される。他サーバへお互いに反映することにより、各
サーバの共用データ記憶部は、全てのサーバの負荷状態
を記憶する。

【００２２】（２）アプリケーションのサーバ割り付け
の管理、制御構成制御処理部の総合的な管理として、構成制御部が下
記に示す各アプリケーションプログラムの実行状態の管
理、制御を行う。１）管理各サーバの状態と合わせて、各アプリケーションの下記
状態を常に管理している。（ａ）各アプリケーションの動作サーバアプリケーションの動作サーバとは、そのアプリケーシ
ョンが動作しているサーバである。（ｂ）各アプリケーションのバックアップサーバ各アプリケーションが動作しているサーバが停止した場
合、どのサーバで再起動させるかを定義する情報であ
る。再起動させるサーバをバックアップサーバという。２）制御後述されるタイミング（構成サーバ変更、定周期）で、
各アプリケーションの動作サーバとバックアップサーバ
を再定義し、クラスタ管理機構に動作サーバとバックア
ップサーバの再定義の指示を行う。なお、動作サーバ、
バックアップサーバの再定義は、予め定義された制御動
作定義ファイルに沿って行われる。制御動作定義ファイ
ル３５には、下記の２つの記述方式がある。（ａ）規約記述型サーバ状態に応じた割り付け指示などの規約の詳細をシ
ステム管理者が予め記述する。状況に応じた複雑な指示
が可能という長所がある。だが、システム管理者の負荷
が重いという欠点もある。（ｂ）モデル指定型クラスタシステムが用意する代表的な形態のモデルをシ
ステム管理者が指定する簡易な設定方式である。設定が
簡単に短時間で行え、システム管理者の負荷を大幅に軽
減するという長所がある。例えば、予め用意されたモデ
ルから二重系ホットスタンバイ、多重系Ｎ対１バックア
ップ型などのモデルを指定できる。

【００２３】（３）初期立ち上げ時の動作初期立ち上げ時には、構成制御部４０が制御動作定義フ
ァイルをもとに作成された共用データ記憶部の制御動作
規約情報テーブル（後述）を参照して動作サーバとバッ
クアップサーバを定義し、各アプリケーションの起動要
求をクラスタ管理機構９００に伝える。

【００２４】（４）構成サーバ変更時の動作サーバの異常停止及び異常停止後の再立ち上げにより、
構成サーバが変更した時、状態監視部２０からのトリガ
２５２で、各アプリケーションのバックアップサーバの
再定義を構成制御部４０が行う。構成制御部４０は、再
定義したバックアップサーバをクラスタ管理機構９００
に伝える。なお、バックアップサーバの再設定先は、サ
ーバ構成及び各サーバの負荷状況をもとに決定される。

【００２５】（５）定周期による動作負荷更新部３０ａからのトリガ２５４で、構成制御部４
０は、定期的に各サーバの負荷をチェックし、チェック
の結果により、各アプリケーションのバックアップサー
バを低負荷のサーバに再設定し、アプリケーション移動
時に特定サーバに負荷が集中することを防ぐ。

【００２６】（６）サーバ異常時のアプリケーションの
移動動作実際に、サーバの異常停止が発生した場合、構成制御処
理部１６０により設定されたバックアップサーバでアプ
リケーションを再起動させるために、クラスタ管理機構
９００にアプリケーションの再起動の指示を出す。指示
を受け取ったクラスタ管理機構９００がアプリケーショ
ンを再起動する。以上のように、この発明のクラスタシ
ステムは動作する。

【００２７】６．サーバ状態の監視次に、状態監視部２０が行うサーバ状態の監視について
説明する。図７は、サーバ状態の監視を説明する図であ
る。状態監視部２０によるサーバ状態の取得は、このク
ラスタシステムが使用するクラスタ管理機構９００の提
供する状態取得機能を使用して行う。状態監視部２０
は、クラスタ管理機構９００からポーリング形式でサー
バ状態を取得する。本実施の形態では、今回取得したサ
ーバ状態の情報と前回取得したサーバ状態の情報とを比
較し、状態変化を検知する方式を採用している。主たる
動作は、以下の通りである。（ａ）クラスタ管理機構９００の提供するサーバ状態取
得コマンドを使用し、ポーリング形式で全サーバの状態
を取得する（矢印２６０）。（ｂ）初回の取得時、共用データ記憶部のサーバ状態情
報テーブル１２ａに記憶し、他サーバのサーバ状態情報
テーブル１２ｂ、１２ｃへ反映を行う（矢印２１０）。（ｃ）２回目以降の取得時（前回の取得結果を記録済み
の時）は、記録情報と比較する。状態変化を検知する
と、共用データ記憶部のサーバ状態情報テーブル１２ａ
に取得した状態及び変更マーク（切り離し／組み込みマ
ーク）を記憶し、他サーバのサーバ状態情報テーブル１
２ｂ、１２ｃへ反映を行う（矢印２１０）。（ｄ）初回及び変更時、構成制御部へ制御トリガを指示
する。トリガは、ＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔ
ｅｍ）が提供するメッセージ送信機能（プログラム間通
信機能）を使用する。

【００２８】７．負荷状況の監視次に、負荷更新部３０ａ〜３０ｃが行う負荷状況の監視
について説明する。図８は、負荷状況の監視を説明する
図である。各サーバの負荷更新部が自サーバの負荷を取
り込み、共用データ記憶部１０ａ〜１０ｃに書き込み、
他サーバへ反映を行う。動作は、以下の通りである。（ａ）負荷更新部３０ａ〜３０ｃは、定周期で起動され
る。（ｂ）負荷更新部３０ａ〜３０ｃは、ＯＳが提供するＣ
ＰＵ負荷情報取り込みコマンドで、ＯＳツール群９１０
ａ〜９１０ｃより自サーバのＣＰＵ負荷を取り込み（２
６２ａ〜２６２ｃ）、共用データ記憶部のサーバ負荷情
報テーブル１３ａ〜１３ｃに書き込み（２６８ａ〜２６
８ｃ）、他サーバの共用データ記憶部１０ａ〜１０ｃへ
それぞれ反映する。（ｃ）構成制御部４０が動作するサーバ上で動作する負
荷更新部の場合、構成制御部４０へバックアップサーバ
チェックのトリガを送る（矢印２６４）。

【００２９】８．アプリケーション状況の管理、制御次に、構成制御部４０が行うアプリケーション状況の管
理、制御について説明する。構成制御部４０は、各アプ
リケーションの状態を管理し、状態監視部２０又は負荷
更新部３０からのトリガによって、各アプリケーション
のバックアップサーバの変更などを行う。

【００３０】（１）管理データ管理、制御するための必要な管理データは、以下のもの
である。なお、各データはすべて共用データ記憶部１０
ａ〜１０ｃに確保され、更新時は全てのサーバに反映さ
れる。従って、各サーバは同一イメージの管理データを
有することになる。

【００３１】（ａ）制御動作規約情報テーブル１１図９に、制御動作規約情報テーブル１１を示す。制御動
作規約情報テーブル１１は、サーバの構成に応じ、各ア
プリケーションの動作サーバとバックアップサーバの割
り付け定義が記述された動作規約定義である。定義自体
は、定義ファイル制御動作定義ファイル３５に記述さ
れ、定義ファイル制御動作定義ファイル３５の内容が共
用データ記憶部に制御動作規約情報テーブル１１ａ〜１
１ｃとしてクラスタの初期構成時に展開される。制御動
作規約情報テーブル１１は、クラスタシステム動作中に
書き替えられることはなく、固定値である。各規約の意
味は、以下の通りである。・動作サーバ１１０５クラスタの初期立ち上げ時にアプリケーションを動作さ
せるサーバ名である。・バックアップサーバ１１０７初期立ち上げ時、設定されるバックアップサーバ名であ
る。未定義時、バックアップサーバを割り付けない。・固定指示１１０９定期負荷によりバックアップサーバの切替を行うか否か
の指定である。切り替えを行う時“ＯＦＦ”、切り替え
を行わない時“ＯＮ”とする。・自動移動モード１１１１同一サーバで複数のアプリケーションが動作している状
態で、他のサーバが復旧した時、その復旧したサーバに
複数のアプリケーションのうちのいずれかのアプリケー
ションを移動させるか否かの指定である。否の時、復旧
したサーバへのアプリケーションの移動は行わずに、復
旧したサーバへバックアップサーバを割り付ける処理と
なる。固定指示１１０９、自動移動モード１１１１の２
つの規約は、アプリケーションを移動させるためには、
そのアプリケーションを終了させなければならないの
で、業務の内容により途中で停止させることが望ましく
ない場合への対応として用意されている。

【００３２】（ｂ）サーバ状態情報テーブル１２図１０に、サーバ状態情報テーブル１２を示す。各サー
バの正常／異常などの状態を管理するためのもので、状
態監視部２０が共用データ記憶部に作成、更新する。各
パラメータの意味は、下記の通りである。・サーバ状態１２０３サーバがクラスタに組み込まれているか否か（正常／切
り離し）の状態を示す。・検出状態１２０５状態変化のあったサーバについて、検出した状態の変化
が“クラスタからの切り離し”か“クラスタへの組み込
み”かを示す。・処理モード１２０７サーバ状態の変化に伴う変更処理が処理中か否かを示
す。構成制御処理部１６０の構成制御動作途中にサーバ
の移動が発生した場合、サーバ移動後のリカバリに使用
する。

【００３３】（ｃ）サーバ負荷情報テーブル１３図１１に、サーバ負荷情報テーブル１３を示す。各サー
バのＣＰＵ負荷情報を管理するためのもので、負荷更新
部が定期的に更新する。サーバ負荷情報テーブル１３
は、共用データ記憶部に確保される。各パラメータの意
味は、下記の通りである。・負荷情報１３０３各サーバのＣＰＵ負荷（％）を示す。

【００３４】（ｄ）アプリケーション動作情報テーブル
１４図１２に、アプリケーション（ＡＰ）動作情報テーブル
１４を示す。各アプリケーションの動作サーバとバック
アップサーバを管理するもので、構成制御部４０が作
成、更新する。また、構成制御部４０は、アプリケーシ
ョン動作情報テーブル１４の更新内容に従って、クラス
タ管理機構９００に実行指示を行う。各パラメータの意
味は、下記の通りである。・動作サーバ名１４０３アプリケーションが実際に動作しているサーバ名が保持
される。・バックアップサーバ名１４０５実際にバックアップサーバとして割り付けられているサ
ーバ名が保持される。・処理中フラグ１４０７アプリケーションに対する動作サーバやバックアップサ
ーバの変更処理が、処理中か否かを示す。構成制御処理
部１６０の構成制御動作途中に、サーバの移動が発生し
た場合、サーバ移動後のリカバリに使用する。

【００３５】（２）構成制御部４０の動作トリガ構成制御部４０の動作トリガには、下記のものがある。・初期立ち上げシステムが開始されたタイミングで、状態監視部２０か
ら通知される。・構成変更時サーバ異常停止、再立ち上げ、操作指示によるサーバ切
り離し／組み込みにより、サーバの状態が変更されたタ
イミングで、状態監視部２０から通知される。・定期負荷更新部が定期的に行う自サーバ負荷更新タイミング
で、構成制御部４０が動作しているサーバの負荷更新部
３０から通知を受けとる。構成制御部４０は、動作トリ
ガの通知をＯＳ提供のメッセージ通知機構（プログラム
間通信機能）で受けとる。構成制御部４０は、メッセー
ジの通知を常に待ち、受けとると要因に沿った処理を行
う。

【００３６】（３）初期立ち上げ時の構成制御部４０の
動作図１３は、構成制御部４０の初期立ち上げ時の動作を示
す流れ図である。構成制御部４０は、状態監視部２０か
ら何らかのメッセージの送付を受けると、Ｓ１０１にお
いて、メッセージを取り込み、メッセージの要因が“初
期立ち上げ”かどうか判定する。ＮＯの場合、Ｓ１０３
において、他の要求のメッセージかどうかチェックを行
う。ＹＥＳの場合、Ｓ１０５において、サーバ状態情報
テーブルから現状のサーバ構成を取得し、本構成に対応
する制御動作規約情報テーブル１１を参照し、各アプリ
ケーションの動作サーバとバックアップサーバを決定
し、アプリケーション動作情報テーブルを作成する。次
に、Ｓ１０７で、クラスタ管理機構９００に、各アプリ
ケーションをアプリケーション動作情報テーブルに定義
された動作サーバで起動するよう指示を行う。次に、Ｓ
１０９において、クラスタ管理機構９００にアプリケー
ションのバックアップサーバの設定を行うよう指示を出
す。Ｓ１１１において、全アプリケーションの処理が終
了したか否かを判定し、終了するまでＳ１０５〜Ｓ１０
９の処理を繰り返す。このように、全アプリケーション
に対し、上記起動／設定処理を行う。Ｓ１１１の判定で
全アプリケーション処理が終了すると、Ｓ１１３でメッ
セージ待ちに戻る。この状態で、アプリケーション動作
サーバが異常停止すると、クラスタ管理機構９００は、
構成制御部４０の指示により設定されているバックアッ
プサーバでアプリケーションを再起動する。

【００３７】（４）構成変更時の構成制御部４０の動作図１４から図１８は、サーバ構成が変更された時の構成
制御部４０の動作を示す流れ図である。１）動作サーバ切り離し時サーバの異常停止やユーザ指示によりサーバがクラスタ
から削除された場合、構成制御部４０は、図１４，図１
５に示した流れ図に従い、下記動作を行う。構成制御部
４０は、状態監視部２０からメッセージの送付を受ける
と、Ｓ１２１において、送付されたメッセージを取り込
み、取り込んだメッセージが“切り離し要求”かどうか
判定する。判定した結果、“切り離し要求”でなけれ
ば、Ｓ１２３において、他の要因のチェックを行う。
“切り離し要求”であった場合には、Ｓ１２５におい
て、サーバ状態情報テーブル１２から切り離し要求のあ
るサーバ（検出状態１２０５が切り離しのサーバ）をサ
ーチする。検出したら、サーバ状態情報テーブル１２の
処理モード１２０７を処理中にセットする（Ｓ１２
９）。検出しない場合は、元のメッセージ待ちに戻る
（Ｓ１２７）。

【００３８】次に、Ｓ１３１において、アプリケーショ
ン動作情報テーブルから該当サーバで動作していたアプ
リケーションをスキャンする。次に、Ｓ１３３におい
て、検出したアプリケーションのアプリケーション動作
情報テーブルの処理中フラグ１４０７をセットし、実際
に動作しているサーバ名をクラスタ管理機構９００から
取り込み、取り込んだサーバ名をアプリケーション動作
情報テーブル１４の動作サーバ名１４０３にセットす
る。この時点では、切り離し要求のあるサーバ上で動作
していたアプリケーションは、既にクラスタ管理機構９
００によりアプリケーション動作情報テーブル１４で定
義されているバックアップサーバで再起動しているはず
であるが、構成制御部４０は、クラスタ管理機構９００
から実際の動作サーバ名を取り込む。

【００３９】実際に動作しているサーバが存在しない
（アプリケーション停止＝バックアップ未定義又は重複
障害）場合は、図１５のＳ１３９に示すように、バック
アップサーバ無しを選択する。

【００４０】アプリケーションが動作中の場合、制御動
作規約情報テーブルの同一サーバ構成の項を参照し（図
１４、Ｓ１３５）、アプリケーションのバックアップサ
ーバが未定義の場合、図１５のＳ１３９に示すように、
バックアップサーバ無しを選択する。アプリケーション
のバックアップサーバの未定義は、故障により動作サー
バ数が特定台数に満たない場合、サーバの処理能力上の
問題から、重要でないアプリケーションを切り捨て、重
要なアプリケーションの動作を保証するため等に使用さ
れる。

【００４１】バックアップサーバが定義されている場
合、アプリケーション動作情報テーブル／サーバ状態情
報テーブルから、アプリケーションが動作していない正
常サーバをサーチする（図１５、Ｓ１３７）。検出した
場合、検出した正常サーバをバックアップサーバに決定
する（図１５、Ｓ１４３）。

【００４２】検出しない場合、サーバ負荷テーブルから
最も低負荷なサーバをバックアップサーバに選択する
（図１５、Ｓ１４１）。

【００４３】次に、Ｓ１４５で、アプリケーション動作
情報テーブルのバックアップサーバ名を選択したバック
アップサーバに変更し、他サーバに反映を行う。その
後、Ｓ１４７で、クラスタ管理機構９００にバックアッ
プサーバの変更指示を行う。完了後、アプリケーション
動作情報テーブル１４の処理中フラグ１４０７をリセッ
トし、他サーバへ反映を行う（Ｓ１４９）。Ｓ１３１〜
Ｓ１４９の処理を該当する全アプリケーションに対して
繰り返し行う。

【００４４】全アプリケーションに対する処理が完了し
たら、サーバ状態情報テーブル１２の該当サーバのサー
バ状態１２０３を切り離し状態にし、検出状態１２０５
をクリア、処理モード１２０７をリセットし、他サーバ
へ反映する（Ｓ１５１）。

【００４５】２）サーバ再組み込み時異常サーバの再立ち上げやコマンド指示によるサーバ組
み込みで、クラスタにサーバが再組み込みされた場合、
構成制御部４０は、図１６から図１８に示す流れ図に従
い、下記動作を行う。

【００４６】構成制御部４０は、状態監視部２０からメ
ッセージを送付されると、Ｓ１６１において、送付され
たメッセージを取り込み、メッセージが“組み込み要
求”かどうか判定する。“組み込み要求”でなかった時
には、Ｓ１６３において、他の要求のチェックを行う。
“組み込み要求”であった場合には、Ｓ１６５におい
て、サーバ状態情報テーブル１２から組み込み要求のあ
るサーバ（検出状態１２０５が組み込み）をサーチす
る。検出したら、サーバ状態情報テーブル１２の処理モ
ード１２０７を処理中にセットする（Ｓ１６９）。検出
しない場合は、元のメッセージ待ちに戻る（Ｓ１６
７）。

【００４７】次に、アプリケーション動作情報テーブル
１４をサーチし、動作していないアプリケーション（動
作サーバ名１４０３に登録のないアプリケーション）を
サーチする（Ｓ１７１）。検出した場合、下記を行う。
アプリケーション動作情報テーブル１４の処理中フラグ
１４０７を処理中にし、動作サーバ名１４０３を組み込
みサーバに設定し、他サーバへ反映する（Ｓ１７３）。
次に、Ｓ１７５で、アプリケーションの起動指示をクラ
スタ管理機構９００に対して行う。完了後、アプリケー
ション動作情報テーブル１４の処理中フラグ１４０７を
リセットし、他サーバへ反映する。該当するアプリケー
ションに対し処理を行ったら、元のメッセージ待ちへ戻
る（Ｓ１７９）。

【００４８】Ｓ１７１の判定で、動作サーバなしのアプ
リケーションが無い場合は、図１７のＳ１８１におい
て、同一サーバで重複動作しているアプリケーションを
アプリケーション動作情報テーブル１４からサーチす
る。存在する場合、下記のアプリケーション移動処理を
行う。制御動作規約情報テーブル１１を参照し、同一サ
ーバで重複動作しているアプリケーションの内、同一サ
ーバ構成時、自動移動モードがＯＮのものをサーチする
（Ｓ１８３）。存在しない場合は、アプリケーション移
動処理はスキップし、図１８のＳ１９３に進む。検出し
た場合、図１７のＳ１８５において、そのアプリケーシ
ョンのアプリケーション動作情報テーブル１４の処理中
フラグ１４０７をセットし、動作サーバ名１４０３を組
み込みサーバに変更し、他サーバに反映する。その後、
クラスタ管理機構９００に、該当アプリケーションの移
動（停止、起動サーバ設定、起動）指示を行う（Ｓ１８
７）。完了後、アプリケーション動作情報テーブル１４
の処理中フラグ１４０７をリセットし、他サーバに反映
する（Ｓ１８９）。処理終了後、元のメッセージ待ちへ
戻る（Ｓ１９１）。

【００４９】上記のアプリケーション移動処理が行われ
なかった場合、図１８のＳ１９３において、各アプリケ
ーションのバックアップサーバ名１４０５を組み込みサ
ーバに変更する。本処理は、前述同様、アプリケーショ
ン動作情報テーブル１４の処理中フラグ１４０７を処理
中にし、バックアップサーバ名１４０５を書き換え、他
サーバに反映する。次に、Ｓ１９５において、クラスタ
管理機構９００に、バックアップサーバ名変更指示を行
う。次に、Ｓ１９７において、アプリケーション動作情
報テーブル１４の処理中フラグ１４０７をリセットし、
他サーバに反映する。

【００５０】最後に、サーバ状態情報テーブル１２のサ
ーバ状態１２０３を正常に書き換え、検出状態１２０５
をクリア、処理モード１２０７をリセットし、他サーバ
へ反映する（Ｓ１９９）。

【００５１】（５）定期負荷更新時の動作負荷更新部からのトリガがあった場合、構成制御部４０
は、図１９に示す流れ図に従い、下記動作を行う。構成
制御部４０は、負荷更新部３０からメッセージを送付さ
れると、Ｓ２１１で送付されたメッセージを取り込み、
“定期負荷要求”かを判定する。“定期負荷要求”でな
い時、Ｓ２１３で他の要求のチェックを行う。“定期負
荷要求”であった時、Ｓ２１５でアプリケーション動作
情報テーブル１４をサーチし、バックアップサーバが定
義されている動作アプリケーションの内、制御動作規約
情報テーブルの同一サーバ構成時の固定バックアップ指
定なしのアプリケーション（固定指示１１０９がＯＦＦ
のアプリケーション）をサーチする。

【００５２】該当するアプリケーションがサーチされる
と、Ｓ２１７でサーチされたアプリケーションのバック
アップサーバの負荷と他サーバの負荷をサーバ負荷情報
テーブルで比較しながら、より低負荷のサーバをサーチ
する。また、サーチしたより低負荷のサーバをサーバ状
態情報テーブル１２でサーチし、サーバ状態１２０３が
正常であることを確認する。より低負荷で正常なサーバ
があれば、Ｓ２１９で、該当アプリケーションのアプリ
ケーション動作情報テーブル１４の処理中フラグ１４０
７を処理中にし、バックアップサーバ名１４０５をサー
チしたサーバに書き換え、他サーバに反映する。次に、
Ｓ２２１でクラスタ管理機構９００にバックアップサー
バ名の変更指示を行う。完了後、アプリケーション動作
情報テーブル１４の処理中フラグ１４０７をリセット
し、他サーバに反映する。（Ｓ２２３）。全アプリケー
ションに対し、上記Ｓ２１５〜Ｓ２２３の処理を行い
（Ｓ２２５）、処理が終了したらメッセージ待ちへ戻る
（Ｓ２２７）。

【００５３】９．制御動作例以下に、制御動作例として、サーバ状態の変更に対する
アプリケーションのバックアップサーバの割り付けの例
をいくつか記述する。（１）構成変更（異常停止／復旧）による動作例５台構成時の構成変更時の割り付け例を示す。図２０
は、サーバ構成の変更例を示す図である。図２１は、図
２０のサーバ構成の変更にそれぞれ対応するアプリケー
ションの割り付け例を示す図である。図２０の２００
１、図２１の２１０１に示すように、各アプリケーショ
ンＡＰ１，ＡＰ２，ＡＰ３がサーバ１００ａ，１００
ｂ，１００ｃで動作し、各アプリケーションのバックア
ップサーバは、サーバ１００ｄに割り当てられている。

【００５４】次に、図２０の２００２に示すように、サ
ーバ１００ａが異常停止すると、クラスタ管理機構９０
０がアプリケーションＡＰ１を、２１０１においてバッ
クアップサーバに指定されているサーバ１００ｄに移
す。構成制御部４０は、このトリガを元に、各アプリケ
ーションのバックアップサーバをアプリケーションが何
も動作していないサーバ１００ｅに割り付ける。割り付
けた状態を図２１の２１０２に示す。

【００５５】次に、図２０の２００３に示すように、サ
ーバ１００ｂが異常停止すると、クラスタ管理機構９０
０がアプリケーションＡＰ２をバックアップサーバに指
定されているサーバ１００ｅに移す。構成制御部４０
は、このトリガを元に、各アプリケーションのバックア
ップサーバをサーバ１００ｃ，１００ｄ，１００ｄと、
図２１の２１０３に示すように再設定する。負荷による
調整は、前述した説明のように行われるので、ここでは
説明は省略する。

【００５６】次に、図２０の２００４に示すように、サ
ーバ１００ａが復旧して立ち上がり、それを構成制御部
４０が検知すると、このトリガを元に、構成制御部４０
は、各アプリケーションのバックアップサーバを、図２
１の２１０４に示すように、サーバ１００ａに再設定す
る。

【００５７】（２）構成変更（復旧）による動作例図２２から図２４は、異常縮退後の復旧時の動作例を示
す図である。図２２の２２０１、図２３の２３０１に示
すように、サーバ１００ｄ、１００ｅが正常な状態で稼
働しており、アプリケーションＡＰ１、アプリケーショ
ンＡＰ３がサーバ１００ｄで重複動作しているものとす
る。その状態で、サーバ１００ｃが復旧すると、構成制
御部４０は、そのトリガを受け、サーバ１００ｃ，１０
０ｄ，１００ｅの３台によるクラスタ構成時の制御動作
規約情報テーブルのアプリケーションＡＰ３の自動移動
モードを判定する。自動移動モードＯＮの場合、構成制
御部４０は、クラスタ管理機構９００に指示を出し、ア
プリケーションＡＰ３はサーバ１００ｃに移動（停止、
再起動）される。その結果、図２２の２２０２、図２３
の２３０３に示すように、サーバ１００ｃ，１００ｄ，
１００ｅでの運転に移行する。

【００５８】なお、自動移動モードＯＦＦの場合は、ア
プリケーションの移動は行われず、各アプリケーション
のバックアップサーバにサーバ１００ｃが割り当てられ
る処理となる。この時の割り当てを、図２４に示す。

【００５９】（３）ＣＰＵ負荷による動作例図２５から図２８は、ＣＰＵ負荷変動による定期更新の
動作例を示す図である。図２５に示すように、サーバ１
００ｃ，１００ｄ，１００ｅでアプリケーションＡＰ
３，ＡＰ１，ＡＰ２がそれぞれ動作している。各ＣＰＵ
負荷により図２６に示すように、バックアップサーバが
サーバ１００ｃ，１００ｄ，１００ｄと割り付けられて
いる。サーバ１００ｄで動作しているアプリケーション
ＡＰ１のバックアップは、サーバ１００ｅより軽負荷で
あるサーバ１００ｃに割り付けられている。負荷更新部
３０による負荷の更新後、図２７に示すように、サーバ
負荷の軽負荷順位で、サーバ１００ｃとサーバ１００ｅ
が逆転したので、構成制御部４０は、サーバ１００ｃを
バックアップサーバとしていたアプリケーションＡＰ１
のバックアップサーバを図２８に示すように、サーバ１
００ｅに切り替える。

【００６０】１０．制御動作規約の定義次に、制御動作規約の定義について、図２９を用いて説
明する。共用データ記憶部１０の制御動作規約情報テー
ブル１１作成のために、ユーザが記述する定義ファイル
２９０１について説明する。制御動作規約情報テーブル
１１の作成方式は、規約記述型とモデル指定型の２方式
がある。

【００６１】ａ）規約記述型サーバ構成の各変動に対し、どのような動作制御を行う
かの規約定義２９０２を詳細に記述したユーザ定義ファ
イル２９０１を図２９の２９０３に示すように、ユーザ
が記述して作成する方式である。このユーザ定義ファイ
ル２９０１は、プログラミングを必要としない簡易なビ
ルドインコマンドで記述可能とする。クラスタシステム
立ち上げ時に構成制御部４０により規約定義２９０２が
参照され、制御動作規約情報テーブル１１が作成され
る。

【００６２】ｂ）モデル指定型特定の動作モデルを予め定義し、その中からユーザに指
定をさせる方式である。当然、内部で、指定されたモデ
ルをもとにして、規約定義２９１６に変換が行われる。
記述できるモデルは、以下の通りである。・二重系ホットスタンバイ（ロードシェア含む）型モデ
ル図３０に、二重系ホットスタンバイモデルの定義例を示
す。このモデルでは、アプリケーションを双方のサーバ
で動くよう２個用意した場合、ロードシェア型となる。
アプリケーション動作中のサーバが異常停止した場合、
動作中であったアプリケーションは、もう一方のサーバ
で再起動される。異常サーバが復旧した場合、復旧した
サーバは、各アプリケーションのバックアップサーバと
なる。・多重系Ｎ対１バックアップ（バックアップ浮動）型図３１に、多重系Ｎ対１バックアップモデルの定義例を
示す。（Ｎ＋１）台のサーバで構成され、１台を共通の
バックアップとする形態である。アプリケーションはＮ
個存在し、Ｎ台のサーバでそれぞれ動作する。動作サー
バが停止すると、アプリケーションはバックアップサー
バで動作する。異常サーバが復旧し、再度、組み込まれ
ると、全アプリケーションのバックアップサーバとな
る。なお、２個以上のサーバが異常停止した場合、その
アプリケーションは切り捨てられ、サーバが復旧した
時、再起動される。どちらの作成方式の場合も、記述フ
ァイル内容はクラスタシステム立ち上げ時、図２９の２
９０５，２９１８に示すように、制御動作規約情報テー
ブル１１に展開される。

【００６３】以上のように、この実施の形態では、クラ
スタ（分散した複数の計算機を一まとまりにしたシステ
ム）構成に於いて、計算機及びアプリケーションの状態
変化に応じて、アプリケーションの起動、停止、起動計
算機の決定、及び引継ぎ計算機（アプリケーション、も
しくはアプリケーション実行中の計算機が異常停止した
場合、次にアプリケーションを実行する計算機のこと）
の決定を自動的、かつ、最適に制御できるようにしたク
ラスタの自動構成制御方式について説明した。この実施
の形態のクラスタシステムによれば、計算機及びアプリ
ケーションの状態を常に監視し、その状態の変化に応じ
て、自動的かつ最適にアプリケーションの動作計算機を
動的に制御するので、システム管理者の負担が軽減され
る。

【００６４】前述した実施の形態では、ネットワークを
介して更新される共用データ記憶部をサーバ毎に備える
場合について説明したが、クラスタシステム内で共用の
メモリ装置を備えて共用データ記憶部としてもよい。

【００６５】

【発明の効果】この発明によれば、クラスタシステムを
構成するサーバの状態に応じて、アプリケーションとサ
ーバとの対応を動的に制御できる。これにより、システ
ム管理者がシステム監視、制御に要する負担を大幅に軽
減し、効率のよい高信頼システムの構築が可能になる。

【００６６】また、この発明によれば、クラスタに構成
されている計算機のメンバーに応じたアプリケーション
の引継ぎ計算機を自動的に決定できる。

【００６７】また、この発明によれば、新たにサーバが
起動した時、操作者を介入させずアプリケーションを自
動引継ぎできる。

【００６８】また、クラスタのメンバーに変動が生じた
際、実行中のアプリケーションの引継ぎ計算機を変更
し、決定するので、常に最適な引継ぎ計算機を選択可能
である。

【００６９】また、サーバの負荷に応じて、アプリケー
ションの引き継ぎを行うので、負荷の分散が図れる。

【００７０】また、定義ファイルを基にクラスタの構成
を制御する規約情報を作成するので、プログラミングレ
スによる定義が可能である。

【００７１】また、システムで定義テンプレートを用意
するので、パターン化された処理の場合、ユーザは、ク
ラスタシステムの詳細な定義を行う必要がない。

【００７２】また、構成制御部が、定期的に取得された
各計算機の負荷（ＣＰＵ、メモリ）状況によって最適な
引継ぎ計算機を自動決定し、引継ぎを行うので、操作者
が介入せず最適な引継ぎができる。

【図面の簡単な説明】

【図１】この発明のクラスタシステムの構成を示すブ
ロック図である。

【図２】この発明のクラスタシステムの構成を示すブ
ロック図である。

【図３】この発明のクラスタシステムのハードウェア
構成図である。

【図４】この発明のクラスタシステムの機能を示すブ
ロック図である。

【図５】この発明のクラスタシステムの機能を示すブ
ロック図である。

【図６】この発明のクラスタシステムの動作概要を示
す図である。

【図７】この発明のクラスタシステムの状態監視部２
０が行うサーバ状態の監視を説明する図である。

【図８】この発明のクラスタシステムの負荷更新部３
０が行う負荷状況の監視を説明する図である。

【図９】この発明のクラスタシステムの共用データ記
憶部１０の制御動作規約情報テーブル１１を示す図であ
る。

【図１０】この発明のクラスタシステムの共用データ
記憶部１０のサーバ状態情報テーブル１２を示す図であ
る。

【図１１】この発明のクラスタシステムの共用データ
記憶部１０のサーバ負荷情報テーブル１３を示す図であ
る。

【図１２】この発明のクラスタシステムの共用データ
記憶部１０のアプリケーション動作情報テーブル１４を
示す図である。

【図１３】この発明のクラスタシステムの構成制御部
４０の初期立ち上げ時の動作の流れ図である。

【図１４】この発明のクラスタシステムの構成制御部
４０のサーバ構成変更時の動作を示す流れ図である。

【図１５】この発明のクラスタシステムの構成制御部
４０のサーバ構成変更時の動作を示す流れ図である。

【図１６】この発明のクラスタシステムの構成制御部
４０のサーバ構成変更時の動作を示す流れ図である。

【図１７】この発明のクラスタシステムの構成制御部
４０のサーバ構成変更時の動作を示す流れ図である。

【図１８】この発明のクラスタシステムの構成制御部
４０のサーバ構成変更時の動作を示す流れ図である。

【図１９】この発明のクラスタシステムの構成制御部
４０の負荷更新時の動作の流れ図である。

【図２０】この発明のクラスタシステムのサーバ構成
の変更例を示す図である。

【図２１】この発明のクラスタシステムの図２０のサ
ーバ構成の変更に対応するアプリケーションの割り当て
例を示す図である。

【図２２】この発明のクラスタシステムの異常縮退後
の復旧時の構成の変更例を示す図である。

【図２３】この発明のクラスタシステムの図２２に対
応するサーバの異常縮退後の復旧時のアプリケーション
の割り当て例を示す図である。

【図２４】この発明のクラスタシステムの図２２に対
応するサーバの異常縮退後の復旧時のアプリケーション
の割り当て例を示す図である。

【図２５】この発明のクラスタシステムのＣＰＵ負荷
変動による定期更新時の動作例を示す図である。

【図２６】この発明のクラスタシステムのＣＰＵ負荷
変動による定期更新時の動作例を示す図である。

【図２７】この発明のクラスタシステムのＣＰＵ負荷
変動による定期更新時の動作例を示す図である。

【図２８】この発明のクラスタシステムのＣＰＵ負荷
変動による定期更新時の動作例を示す図である。

【図２９】この発明のクラスタシステムの共用データ
記憶部１０の制御動作規約情報テーブル１１の作成を説
明する図である。

【図３０】この発明のクラスタシステムの二重系ホッ
トスタンバイモデルの定義例を示す図である。

【図３１】この発明のクラスタシステムの多重系Ｎ対
１バックアップモデルの定義例を示す図である。

【符号の説明】

１０，１０ａ，１０ｂ，１０ｃ共用データ記憶部、１
１，１１ａ，１１ｂ，１１ｃ制御動作規約情報テーブ
ル、１２，１２ａ，１２ｂ，１２ｃサーバ状態情報テ
ーブル、１３，１３ａ，１３ｂ，１３ｃサーバ負荷情
報テーブル、１４，１４ａ，１４ｂ，１４ｃアプリケ
ーション動作情報テーブル、２０状態監視部、３０，
３０ａ，３０ｂ，３０ｃ負荷更新部、３５制御動作
定義ファイル、４０構成制御部、１００ａ，１００
ｂ，１００ｃ，１００ｎサーバ、１６０構成制御処
理部、２００ａ，２００ｂ，２００ｎディスク、９０
０クラスタ管理機構、９１０ａ，９１０ｂ，９１０ｃ
ＯＳツール群、１０００ネットワーク、１１０１サー
バ構成、１１０３アプリケーション名、１１０５動
作サーバ、１１０７バックアップサーバ、１１０９
固定指示、１１１１自動移動モード、１２０１サー
バ名、１２０３サーバ状態、１２０５検出状態、１２
０７処理モード、１３０１サーバ名、１３０３負
荷情報、１４０１アプリケーション名、１４０３動
作サーバ名、１４０５バックアップサーバ名、１４０
７処理中フラグ、ＡＰ１，ＡＰ２，ＡＰ３アプリケ
ーション。

Claims

【特許請求の範囲】

【請求項１】１つ以上のアプリケーションを実行可能
な複数台のサーバをメンバーとして構成されるクラスタ
システムであって、上記複数台のサーバのいずれか１台
に上記アプリケーションを実行させるとともに、上記１
台のサーバが上記アプリケーションを実行不可能である
時に他のサーバに上記アプリケーションの実行を引き継
がせるクラスタシステムにおいて、以下の要素を有するクラスタシステム（ａ）上記複数台のサーバから共通して利用可能な共用
データとして、上記複数台のサーバの状態を示すサーバ
状態情報と上記複数台のサーバの負荷を示す負荷情報と
上記アプリケーションの動作に関するアプリケーション
動作情報とを記憶する共用データ記憶部、（ｂ）上記複
数台のサーバの状態を取得して上記サーバ状態情報を更
新する状態監視部、（ｃ）上記複数台のサーバの負荷を
取得して上記負荷情報を更新する負荷更新部、（ｄ）上
記共用データ記憶部を参照して、上記アプリケーション
と上記複数台のサーバとの対応を動的に制御する構成制
御部。
【請求項２】上記共用データ記憶部は、上記クラスタ
システムの制御に関する規約を定義する規約情報を記憶
するとともに、上記構成制御部は、上記クラスタシステ
ムの起動の際のクラスタ構成時に上記規約情報と上記サ
ーバ状態情報とを参照して上記アプリケーション動作情
報を作成することを特徴とする請求項１に記載のクラス
タシステム。
【請求項３】上記構成制御部は、上記クラスタシステ
ムのクラスタ構成後に新たなサーバが起動してメンバー
として上記クラスタシステムに参加した時、上記サーバ
状態情報と上記アプリケーション動作情報とを参照して
上記アプリケーションの引継ぎを行うことを特徴とする
請求項１に記載のクラスタシステム。
【請求項４】上記構成制御部は、上記クラスタシステ
ムのクラスタ構成後にメンバーの移動が発生した時、上
記サーバ状態情報と上記アプリケーション動作情報とを
参照して上記アプリケーションを引き継ぐ引継ぎサーバ
を決定して上記アプリケーション動作情報を更新するこ
とを特徴とする請求項１に記載のクラスタシステム。
【請求項５】上記構成制御部は、上記複数のサーバの
いずれかの負荷状態に変化が起こった時、上記サーバ負
荷情報と上記アプリケーション動作情報とを参照して上
記アプリケーションの引継ぎを行うことを特徴とする請
求項１に記載のクラスタシステム。
【請求項６】上記規約情報は、ユーザが設定する定義
ファイルをもとに作成されることを特徴とする請求項２
に記載のクラスタシステム。
【請求項７】上記クラスタシステムは、パターン化さ
れたテンプレートを予め用意し、用意したテンプレート
のいずれかをもとに上記規約情報を作成することを特徴
とする請求項２に記載のクラスタシステム。
【請求項８】上記負荷更新部は、所定のタイミングで
定期的に上記複数台のサーバの負荷を取得して上記負荷
情報を更新し、上記構成制御部は、上記負荷情報を参照
してアプリケーション引継ぎに際し、上記アプリケーシ
ョンを引き継ぐ引継ぎサーバを決定して上記アプリケー
ションの引継ぎを行うことを特徴とする請求項１に記載
のクラスタシステム。