(57)【要約】【課題】  クラスタシステムで、業務処理がトランザクションである場合であっても、待機系コンピュータのコストを最小限に抑える。【解決手段】  待機サーバの実行サーバ監視スレッドは、定期的に実行サーバの稼働状態を監視する（Ｓ４００）。その監視の結果としてタイムアウトを検出したとき（Ｓ４０１のＹ）、実行サーバをリセットし（Ｓ４２０）、実行サーバのＩＰアドレスに対する負荷分散を停止する（Ｓ４２１）。そして、実行サーバのトランザクションを回復し（Ｓ４４２）、稼働状態の監視に戻る（Ｓ４００）。また、監視の結果として実行サーバの正常を検出し（Ｓ４０１のＮ）、かつ、実行サーバ管理テーブルの稼働状態が停止であるとき（Ｓ４１０のＹ）、実行サーバに対する負荷分散を開始し（Ｓ４１２）、稼働状態の監視に戻る（Ｓ４００）。なお、リソース接続情報を用いてトランザクションを回復してもよい。【選択図】      図４
2005339525.tif 000002
【特許請求の範囲】
【請求項１】
クライアントと通信可能であり、そのクライアントから受信した処理要求を振り分ける負荷分散装置と、
前記負荷分散装置が振り分けた処理要求を受信し、その処理を実行する実行サーバと、
前記実行サーバの障害を検出したとき、その実行サーバのトランザクションを回復する
待機サーバと、
がネットワーク接続されて構成されるクラスタシステムにおいて、
前記待機サーバが、前記実行サーバごとに、その稼働状態を監視し、障害が発生した実
行サーバのトランザクションを回復すると共に、その実行サーバの縮退制御を行うクラス
タ制御方法であって、
前記待機サーバは、所定の実行サーバに対して処理を行う場合、
所定の時間ごとに前記実行サーバの稼働状態を監視するステップと、
前記監視の結果として前記実行サーバの障害を検出したとき、前記実行サーバをリセッ
トし、縮退させるステップと、
その次に、前記実行サーバのトランザクションを回復し、前記稼働状態の監視に戻るス
テップと、
前記監視の結果として前記実行サーバの正常を検出し、かつ、前記実行サーバが縮退し
ているとき、前記実行サーバの縮退を解除し、前記稼働状態の監視に戻るステップと、
を実行することを特徴とするクラスタ制御方法。
【請求項２】
前記負荷分散装置は、
前記処理要求を振り分ける実行サーバの構成リストを備え、
前記待機サーバは、所定の実行サーバに対して処理を行う場合、
前記実行サーバを縮退させるとき、前記負荷分散装置に対して前記構成リストから前記
実行サーバをはずすことを指示するメッセージを送信し、
前記実行サーバの縮退を解除するとき、前記負荷分散装置に対して前記構成リストに前
記実行サーバを追加することを指示するメッセージを送信する
ことを特徴とする請求項１に記載のクラスタ制御方法。
【請求項３】
前記待機サーバは、
前記実行サーバごとに、障害発生時のトランザクションの回復順序を制御するために、
ＮＵＬＬまたは次にトランザクションを回復する実行サーバへのポインタを設定する回復
順序ポインタを備え、
所定の実行サーバに対して処理を行う場合、
初期化処理として、前記実行サーバの回復順序ポインタをＮＵＬＬにするステップと、
前記トランザクションを回復する前に、既にトランザクション回復中の実行サーバがあ
る場合、その回復中の実行サーバから前記回復順序ポインタを辿っていったとき、最初に
ＮＵＬＬになった回復順序ポインタに当該実行サーバへのポインタを設定するステップと
、
その次に、他の実行サーバに対する処理からトランザクションの回復処理完了が通知さ
れるのを待って、トランザクションの回復を開始するステップと、
前記トランザクションを回復した後、当該実行サーバの回復順序ポインタがＮＵＬＬで
ないとき、その回復順序ポインタが示す実行サーバに対する処理に回復処理完了を通知し
、その回復順序ポインタにＮＵＬＬを設定するステップと、
を更に実行することを特徴とする請求項１または請求項２に記載のクラスタ制御方法。
【請求項４】
前記待機サーバは、
前記実行サーバごとに、トランザクションを回復するためにリソースにアクセスするのに必要なリソース接続情報を備え、
所定の実行サーバに対して処理を行う場合、
前記実行サーバが接続していたリソースのリソース接続情報を取得するステップと、
その取得したリソース接続情報を用いてトランザクションを回復するステップと、
を更に実行することを特徴とする請求項１ないし請求項３のいずれか一項に記載のクラスタ制御方法。
【請求項５】
請求項１ないし請求項４のいずれか一項に記載のクラスタ制御方法をサーバ用コンピュ
ータに実行させることを特徴とするクラスタ制御プログラム。
【請求項６】
クライアントと通信可能であり、そのクライアントから受信した処理要求を振り分ける負荷分散装置と、
前記負荷分散装置が振り分けた処理要求を受信し、その処理を実行する実行サーバと、
前記実行サーバの障害を検出したとき、その実行サーバのトランザクションを回復する
待機サーバと、
がネットワーク接続されて構成されるクラスタシステムであって、
前記待機サーバは、所定の実行サーバに対して処理を行う場合、
所定の時間ごとに前記実行サーバの稼働状態を監視し、
前記監視の結果として前記実行サーバの障害を検出したとき、前記実行サーバをリセッ
トし、縮退させ、
その次に、前記実行サーバのトランザクションを回復し、前記稼働状態の監視に戻り、
前記監視の結果として前記実行サーバの正常を検出し、かつ、前記実行サーバが縮退し
ているとき、前記実行サーバの縮退を解除し、前記稼働状態の監視に戻る
ことを特徴とするクラスタシステム。
【請求項７】
負荷分散装置がクライアントから受信して振り分けた処理要求を受信し、その処理を実行する実行サーバに接続され、前記実行サーバの障害を検出したとき、その実行サーバのトランザクションを回復する待機サーバであって、
所定の実行サーバに対して処理を行う場合、
所定の時間ごとに前記実行サーバの稼働状態を監視し、
前記監視の結果として前記実行サーバの障害を検出したとき、前記実行サーバをリセッ
トし、縮退させ、
その次に、前記実行サーバのトランザクションを回復し、前記稼働状態の監視に戻り、
前記監視の結果として前記実行サーバの正常を検出し、かつ、前記実行サーバが縮退し
ているとき、前記実行サーバの縮退を解除し、前記稼働状態の監視に戻る
ことを特徴とする待機サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータシステムの高可用性を実現するクラスタ制御技術に関する。
【背景技術】
【０００２】
コンピュータシステムの高可用性を実現する技術として、独立して動作する複数のコン
ピュータをまとめて１台のコンピュータとして取り扱うようにしたクラスタシステムがあ
る。そのクラスタシステムには、大きく分けて、通常は全てのコンピュータを使って動作
し、障害発生時には縮退して動作を継続するスケーラブル型クラスタシステムと、障害発
生時に動作する待機系コンピュータを持つスタンバイ型クラスタシステムとがある。更に
、そのスタンバイ型クラスタシステムは、１：１待機型、１：１相互待機型、Ｎ：１待機
型、Ｎ：Ｍ待機型などに分類される。Ｎ：１待機型は、Ｎ台の現用系コンピュータと１台
の待機系コンピュータとからなるクラスタシステムである。このＮ：１待機型は、待機系
コンピュータのコストを抑えつつ、コンピュータシステムの高可用性および業務処理の拡
張性（スケーラビリティ）を実現することができる。また、Ｎ：Ｍ待機型は、Ｎ台の現用
系コンピュータとＭ台の待機系コンピュータとからなるクラスタシステムである（通常は
、Ｎ＞Ｍ）。このＮ：Ｍ待機型は、Ｎ：１待機型の長所を受け継ぐと共に、Ｍ回の障害に
対応することができる。なお、Ｎ：１待機型クラスタシステムの一例が、特許文献１に開
示されている。
【特許文献１】米国特許５８５２７２４号明細書（“FIG. 2”およびその説明）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、従来のＮ：１待機型は、業務処理がトランザクションである場合、短時
間にコンピュータシステムの二重障害に対応することは困難であった。これは、１台の現
用系コンピュータに障害が発生したとき、１台の待機系コンピュータがその中断したトラ
ンザクション（業務処理）を回復し、引き継ぐことになるので、障害が発生した現用系コ
ンピュータが正常に稼働できる状態にならない限り、次に発生する他の現用系コンピュー
タの障害に対応することができないことによる。ここで、トランザクションとは、業務処
理が複数のプロセスから構成されるものの、分割することができない処理の単位をいう。
これに対して、従来のＮ：Ｍ待機型は、Ｍ回の障害に対応することができるが、Ｎ：１待
機型と比較して運用の複雑さや待機系コンピュータのコストなどが問題となっていた。
【０００４】
また、従来のＮ：１待機型クラスタシステムでは、現用系および待機系のサーバ構成（アプリケーションプログラムの種類や取り扱うデータベースの構造など）が一様である必要があった。これは、複数の現用系コンピュータに対して、１台の待機系コンピュータがトランザクションを回復し、その後の処理を含めて引き継ぐ必要があるからである。このため、Ｎ台の現用系においてサーバ構成が異なる場合は、同じサーバ構成の現用系をグループ化し、各グループについて１台の待機系を用意しなければならず、待機系のコストが増えるという問題があった。
【０００５】
以上を換言すれば、従来のスタンバイ型クラスタシステムは、業務処理がトランザクシ
ョンである場合、待機系コンピュータのコストを最小限に抑えつつ、短時間にコンピュー
タシステムの二重障害に対応することが困難であるという問題があった。
【０００６】
そこで、本発明は、前記問題に鑑み、クラスタシステムにおいて、業務処理がトランザクションである場合であっても、待機系コンピュータのコストを最小限に抑える手段を提供することを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決する本発明は、クライアントに接続され、そのクライアントから受信し
た処理要求を振り分ける負荷分散装置と、負荷分散装置が振り分けた処理要求を受信し、
その処理を実行する実行サーバと、実行サーバの障害を検出したとき、その実行サーバの
トランザクションを回復する待機サーバとがネットワーク接続されて構成されるスタンバ
イ型クラスタシステムにおいて、待機サーバが、実行サーバごとに、その稼働状態を監視
し、障害が発生した実行サーバのトランザクションを回復すると共に、その実行サーバの
縮退制御を行うクラスタ制御方法およびそのプログラムである。
【０００８】
この方法において、待機サーバは、実行サーバごとに行う処理として、所定の時間ごと
に実行サーバの稼働状態を監視し、障害が発生した実行サーバのトランザクションの回復
を行った後、その実行サーバの処理を引き継ぐことは行わず、再び実行サーバの稼働状態
の監視を継続する。これによって、待機サーバが障害の発生した実行サーバのトランザク
ションを随時回復するため、その回復が停滞することがなくなるので、その実行サーバの
未完了のトランザクションによる他の実行サーバの業務処理の中断を回避することができ
る。
【０００９】
また、この方法において、待機サーバは、障害が発生した実行サーバを縮退させるとき
、負荷分散装置に対して実行サーバの構成リストから当該実行サーバをはずすことを指示
するメッセージを送信する。これによって、障害が発生した実行サーバおよびそのＩＰア
ドレスを引き継いでトランザクションを回復する（フェールオーバ中の）待機サーバに、
負荷分散装置から不当に処理要求が来ることがなくなる。また、障害から回復して稼働で
きる状態になった実行サーバの縮退を解除するとき、負荷分散装置に対して実行サーバの
構成リストに当該実行サーバを追加することを指示するメッセージを送信する。これによ
って、稼働できる状態になった実行サーバに、負荷分散装置から処理要求が来るようにな
り、負荷分散が図られる。
【００１０】
更に、この方法において、待機サーバは、実行サーバごとに、障害発生時のトランザク
ションの回復順序を制御するために、ＮＵＬＬまたは次にトランザクションを回復する実
行サーバへのポインタを設定する回復順序ポインタを備え、この回復順序ポインタに従っ
て、障害が発生した実行サーバへのポインタを追加すると共に、順番にトランザクション
の回復を行う。これによって、実行サーバの障害が発生した順序に従って、その実行サー
バのトランザクションを回復することができる。
【００１１】
続いて、この方法において、待機サーバは、障害が発生した実行サーバのリソース接続情報を取得する。そして、このリソース接続情報を用いてリソースにアクセスし、仕掛かり中のトランザクションを回復する。これによって、実行サーバの構成が一様でなくても、処理対象の実行サーバを切り替えた場合にリソース接続情報を取得するため、障害のあった実行サーバが接続していたリソースに接続でき、トランザクションを回復することができる。
【００１２】
なお、本発明は、クラスタシステムおよび待機サーバを含む。また、請求項における「所定の実行サーバに対して処理を行う場合」の「処理」および「実行サーバに対する処理」は、後記する発明を実施するための最良の形態における「待機サーバの実行サーバ監視スレッド」に相当する。また、請求項における「実行サーバの縮退」の状態および「回復順序ポインタ」は、後記する発明を実施するための最良の形態においては、「実行サーバ管理テーブル」によって管理される。
【発明の効果】
【００１３】
本発明によれば、待機サーバがトランザクションを回復した後、業務処理を引き継がずに再び待機するので、待機系のコストを抑えることができる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明を実施するための最良の形態（以下、「本発明の実施の形態」という）に
ついて図面を参照して詳細に説明する。
【００１５】
≪第１の実施の形態≫
（クラスタシステムの構成と概要）
図１を参照して、第１の実施の形態に係るスタンバイ型クラスタシステムの構成について説明する。このスタンバイ型クラスタシステム（図１および以下において、単に「クラスタシステム１０」とする）においては、負荷分散装置１００がクライアント２０から受けた業務処理要求を複数の各実行サーバに分散処理させるために、各実行サーバに同一の業務処理プログラムが配備されている。クラスタシステム１０は、ネットワークセグメント１１０に接続された１台の負荷分散装置１００、Ｎ台の実行サーバ１６０〜１６２および１台の待機サーバ１７０と、ネットワークセグメント１２０に接続された２台のＤＢサーバ１８０、１８１とから構成されている。ネットワークセグメント１１０と、ネットワークセグメント１２０とは、ネットワーク１１５によって接続されている。各実行サーバ１６０〜１６２と、待機サーバ１７０とは、それぞれ、ＫＡ（Keep Alive）パス１３０〜１３２、リセットパス１４０〜１４２および共有ディスク装置１５０〜１５２を介して接続されている。各ＤＢサーバ１８０、１８１は、それぞれ、実行サーバ１６０〜１６２から業務処理中に参照、更新される業務ＤＢ１９０、１９１を配下に持つ。
【００１６】
負荷分散装置１００は、ネットワーク３０を介して接続されたクライアント２０から業
務処理要求を受ける。そして、自らが保持している実行サーバの構成リスト（図示せず）
において現在有効な実行サーバに対して、その業務処理要求を振り分ける。その振り分け
には、例えば、ラウンドロビン方式を使用する。その構成リストは、待機サーバ１７０の
負荷分散装置制御手段１７１からの指示によって更新するものとする。実行サーバ１６０
〜１６２は、負荷分散装置１００から振り分けられた業務処理要求に対応する業務処理を
実行するサーバであり、いわゆる現用系である。業務処理を実行するときには、ＤＢサー
バ１８０を介して業務ＤＢ１９０を参照、更新し、ＤＢサーバ１８１を介して業務ＤＢ１
９１を参照、更新する。業務処理がトランザクションである場合、業務ＤＢ１９０および
１９１の両方を更新するものとする。なお、「実行サーバ１」、「実行サーバ２」および
「実行サーバＮ」のように数字を付与しているのは、図５に示す実行サーバ識別子５０１
に対応させるためである。待機サーバ１７０は、実行サーバが停止したときにトランザク
ションの回復処理を行うサーバであり、いわゆる予備系（待機系）である。待機サーバ１
７０は、負荷分散装置制御手段１７１、フェールオーバ順序制御手段１７２およびトラン
ザクション回復処理手段１７３を備えている。負荷分散装置制御手段１７１は、負荷分散
装置１００を制御する機能を持ち、特に、実行サーバの稼働状態に応じて、前記構成リス
トに対する実行サーバの追加、削除などを負荷分散装置１００に指示する。フェールオー
バ順序制御手段１７２は、二重障害が発生したときのトランザクション回復順序を制御す
る機能を持つ。トランザクション回復処理手段１７３は、実行サーバが停止したとき、そ
の実行サーバの仕掛かり（未完了の）トランザクションを回復する機能を持つ。
【００１７】
ＫＡパス１３０〜１３２は、待機サーバ１７０が各実行サーバの稼働状態を監視するた
めに使用する信号線である。リセットパス１４０〜１４２は、待機サーバ１７０が各実行
サーバのネットワークアダプタ停止やＣＰＵ（Central Processing Unit）リセットなど
のリセット処理を行うために使用する信号線である。共有ディスク装置１５０〜１５２は
、各実行サーバにおけるトランザクションの状態を遂次格納する。その格納されているト
ランザクションの状態は、各実行サーバおよび待機サーバ１７０から参照、更新可能であ
る。
【００１８】
第１の実施の形態では、実行サーバ１６０〜１６２に配備された各業務処理プログラムが、それぞれＤＢサーバ１８０、１８１に対してグローバルトランザクションを実行し、そのトランザクションの状態をそれぞれ共有ディスク装置１５０〜１５２に格納することを想定しているが、単一ＤＢに対するローカルトランザクションを実行してもよいし、共有ディスク装置１５０〜１５２を同一の共有ディスク装置で実現してもよい。また、第１の実施の形態では、説明の便宜上、負荷分散装置、ネットワーク、ネットワークアダプタ、ＤＢサーバなどの冗長構成を採用していないが、これらの冗長構成を採ってもよい。
【００１９】
ここで、各構成要素の実現形態について説明する。クライアント２０は、ＰＣ（Person
al Computer）などのクライアント用コンピュータによって実現される。負荷分散装置１
００は、負荷分散ソフトウエアを搭載したＰＣや専用のハードウエアなどによって実現さ
れる。実行サーバ１６０〜１６２、待機サーバ１７０およびＤＢサーバ１８０、１８１は
、いわゆるサーバ用コンピュータによって実現される。共有ディスク装置１５０〜１５２
および業務ＤＢ１９０、１９１は、ハードディスク装置などの記憶装置によって実現され
る。また、負荷分散装置制御手段１７１、フェールオーバ順序制御手段１７２およびトラ
ンザクション回復処理手段１７３は、待機サーバ１７０に内蔵されるＣＰＵが所定のメモ
リに記憶されたプログラムを実行することによって実現される。
【００２０】
（クラスタシステムの処理）
図２を参照して、第１の実施の形態に係る待機サーバの処理の流れについて説明する（適宜図１参照）。待機サーバ１７０は、まず、図５に示す実行サーバ管理テーブル５００を初期化する（ステップＳ２００）。ここで、実行サーバ管理テーブル５００は、待機サーバ１７０に保存され、実行サーバの状態を管理するテーブルである。その詳細は後記する（図５参照）。次に、待機サーバ１７０による監視の対象となる各実行サーバにそれぞれ対応したＮ個の実行サーバ監視スレッドを実行する（ステップＳ２０１）。第１の実施の形態では、待機サーバ１７０において実行サーバを監視するために、各実行サーバに対応した複数のスレッド（プロセスの分割単位）を使用しているが、各実行サーバに対応した複数のプロセス（タスク）を利用してもよい。
【００２１】
図３を参照して、第１の実施の形態に係る実行サーバ管理テーブルの初期化処理の流れについて説明する。これは、図２のステップＳ２００の処理に相当する。待機サーバ１７０は、まず、実行サーバ管理テーブル５００の稼働状態５０４（図５参照）を全て「停止」に初期化する（ステップＳ３００）。次に、実行サーバ管理テーブル５００の回復順序ポインタ５０５（図５参照）を全てＮＵＬＬに初期化する（ステップＳ３０１）。なお、これらの初期化処理は、後記する実行サーバ監視スレッドが行うようにしてもよい。
【００２２】
図４を参照して、第１の実施の形態に係る実行サーバ監視スレッドの処理の流れについて説明する（適宜図１参照）。これは、図２のステップＳ２０１の処理に相当する。実行サーバＭ（Ｍ＝１〜Ｎ）に対応する実行サーバ監視スレッドＭは、まず、実行サーバＭに接続されたＫＡパスを使用して実行サーバＭの稼働状態を定期的に（所定の時間ごとに）監視する（ステップＳ４００）。実行サーバ監視スレッドＭは、稼働状態の監視がタイムアウトになったか否かによって監視対象の実行サーバＭの稼働状態を判断する（ステップＳ４０１）。ここで、「稼働状態の監視がタイムアウトになった」とは、実行サーバ監視スレッドＭがＫＡパスを介して実行サーバＭに応答要求を送信したのに対して、所定のタイムアウト時間が経過しても実行サーバＭから応答がなかったことを意味し、換言すれば、実行サーバＭが障害によって停止していることを意味する。
【００２３】
所定のタイムアウト時間以内に稼働状態を取得できた（応答要求に対する応答があった）場合は（ステップＳ４０１のＮ）、図５に示す実行サーバ管理テーブル５００における実行サーバＭの稼働状態５０４をチェックする（ステップＳ４１０）。実行サーバＭの稼働状態５０４が「停止」の場合は（ステップＳ４１０のＹ）、その稼働状態５０４を「停止」から「稼働中」に変更する（ステップＳ４１１）。そして、実行サーバ監視スレッドＭの指示によって、負荷分散装置制御手段１７１が実行サーバＭに対する負荷分散を開始する（ステップＳ４１２）。具体的には、まず、負荷分散装置制御手段１７１が、負荷分散装置１００に対して、前記構成リストに実行サーバＭを追加するように指示するメッセージを送信する。次に、負荷分散装置１００は、その指示のメッセージを受信して、前記構成リストに実行サーバＭを追加する。これによって、負荷分散装置１００は、実行サーバＭにも業務処理を振り分けるようになるので、実行サーバＭに対する負荷分散が開始されたことになる。その後、実行サーバ監視スレッドＭは、再び実行サーバＭの稼働状態を監視する（ステップＳ４００）。実行サーバＭの稼働状態５０４が「停止」でない場合、すなわち、「稼働中」の場合は（ステップＳ４１０のＮ）、再び実行サーバＭの稼働状態を監視する（ステップＳ４００）。
【００２４】
実行サーバ監視スレッドＭは、タイムアウト時間以内に稼働状態を取得できなかった場
合（ステップＳ４０１のＹ）、実行サーバ管理テーブル５００における実行サーバＭの稼
働状態５０４が「稼働中」であるか否かをチェックする（ステップＳ４０２）。稼働状態
５０４が「稼働中」でない場合、すなわち、「停止」の場合は（ステップＳ４０２のＮ）
、再び実行サーバＭの稼働状態を監視する（ステップＳ４００）。稼働状態５０４が「稼
働中」の場合は（ステップＳ４０２のＹ）、実行サーバＭに接続されたリセットパスを使
用して、実行サーバＭのネットワークアダプタ停止やＣＰＵリセットなどのリセット処理
を行う（ステップＳ４２０）。次に、実行サーバ監視スレッドＭの指示によって、負荷分
散装置制御手段１７１が、実行サーバＭのＩＰアドレスに対する負荷分散を停止する（ス
テップＳ４２１）。
【００２５】
具体的には、まず、負荷分散装置制御手段１７１が、負荷分散装置１００に対して、前記構成リストから実行サーバＭのＩＰアドレスを削除するように指示するメッセージを送信する。次に、負荷分散装置１００は、その指示のメッセージを受信して、前記構成リストから実行サーバＭのＩＰアドレスを削除する。これによって、負荷分散装置１００は、実行サーバＭのＩＰアドレスに業務処理を振り分けることがなくなるので、実行サーバＭのＩＰアドレスに対する負荷分散が停止されたことになる。これは、別途トランザクションを回復するときに、待機サーバ１７０が実行サーバＭのＩＰアドレスをテークオーバする（引き継ぐ）ことに起因して、クライアント２０からの新たな業務処理要求に対応する業務処理が、負荷分散装置１００から待機サーバ１７０に振り分けられるのを回避するためである。
【００２６】
続いて、実行サーバ監視スレッドＭは、実行サーバ管理テーブル５００の稼働状態５０
４を検索して、トランザクション「回復中」状態の実行サーバがあるか否かを判断する（
ステップＳ４２２）。「回復中」の実行サーバが存在する場合（ステップＳ４２２のＹ）
、実行サーバＭの稼働状態５０４を「稼働中」から「待機中」に変更する（ステップＳ４
３０）。次に、「回復中」状態の実行サーバの回復順序ポインタ５０５を順に辿り、最初
にＮＵＬＬを検出した個所に実行サーバＭへのポインタを書き込む（ステップＳ４３１）
。そして、実行サーバ監視スレッドＭは、他の実行サーバ監視スレッドからトランザクシ
ョン回復処理の完了通知が届くまで待機する（ステップＳ４３２）。
【００２７】
実行サーバ監視スレッドＭは、「回復中」の実行サーバが存在しない場合（ステップＳ
４２２のＮ）、または、前記トランザクション回復処理の完了通知を受けた場合（ステッ
プＳ４３２の待ちが解除された場合）、実行サーバ管理テーブル５００における実行サー
バＭの稼働状態５０４を「稼働中」または「待機中」から「回復中」に変更する（ステッ
プＳ４４０）。そして、実行サーバＭのＩＰアドレスをテークオーバ（引き継ぎ）する（
ステップＳ４４１）。具体的には、待機サーバ１７０のＬＡＮアダプタ（図示せず）には
固有のＩＰアドレスが予め設定されているが、そのＩＰアドレスの別名（alias）として
実行サーバＭのＩＰアドレスを設定する。これによって、待機サーバ１７０は、仕掛かり
トランザクションを回復するために他の実行サーバから要求される業務処理を、実行サー
バＭに代わって実行することができる。
【００２８】
次に、実行サーバ監視スレッドＭは、実行サーバ管理テーブル５００における実行サー
バＭの共有ディスク装置情報５０３から当該共有ディスク装置に格納されているトランザ
クションの状態を取得し、トランザクション回復処理手段１７３に指示することによって
、実行サーバＭの仕掛かりトランザクションを回復する（ステップＳ４４２）。具体的に
は、トランザクション回復処理手段１７３が、実行サーバＭのトランザクションの状態に
応じて、負荷分散装置１００からのトランザクションおよび他の実行サーバからのトラン
ザクションを回復する。
【００２９】
負荷分散装置１００からのトランザクションを回復するときには、コミットを行うこと
によってトランザクションを完了させたり、ロールバックを行うことによってトランザク
ション前の状態に戻したりする。例えば、そのトランザクションが、業務ＤＢ１９０の更
新が発生するプロセスＡを行い、次に、業務ＤＢ１９１の更新が発生するプロセスＢを行
うものであるとする。その場合、トランザクションの状態としてプロセスＡおよびプロセ
スＢが正常終了であったときには、トランザクションを完了させるために業務ＤＢ１９０
および１９１の更新を行うコミットを行う。また、プロセスＡまたはプロセスＢが異常終
了であったときには、トランザクション前の状態に戻すために業務ＤＢ１９０および１９
１の更新を止めて元に戻すロールバックを行う。
【００３０】
一方、実行サーバＭは、負荷分散装置１００からではなく、他の実行サーバからトラン
ザクションを受けることがある。例えば、他の実行サーバが、負荷分散装置１００から受
けたグローバルトランザクションを実行サーバＭにブランチすることがある。実行サーバ
Ｍがそのブランチされたトランザクションを実行中に異常停止すると、その業務処理が中
断する。このような他の実行サーバからブランチされたトランザクションを回復するとき
、待機サーバ１７０のトランザクション回復処理手段１７３は、まず、ブランチされた仕
掛かりトランザクションに係る他の実行サーバに対して、トランザクションの回復を行う
ように指示する。これに応じて、他の実行サーバは、ブランチしたトランザクションをど
う決着するかを判断し、前記ブランチしたトランザクションの決着の指示を待機サーバ１
７０に対して行う。そして、待機サーバ１７０のトランザクション回復処理手段１７３は
、他の実行サーバから受けた指示に従ってトランザクションを決着する。なお、このとき
、他の実行サーバは、ステップＳ４４１でテークオーバされた実行サーバＭのＩＰアドレ
スを使用して、待機サーバ１７０とのやりとりを行うことになる。
【００３１】
以上によって、実行サーバＭの仕掛かりトランザクションに起因する、他の実行サーバ
における業務処理の中断を回避することができる。特に、グローバルトランザクションの
場合、比較的長いトランザクションタイムアウト値を設定するため、仕掛かりトランザク
ションの回復処理による可用性の向上効果は大きい。
【００３２】
実行サーバ監視スレッドＭは、当該共有ディスク装置に格納されたトランザクションの
状態を更新した後、テークオーバした実行サーバＭのＩＰアドレスを破棄する（ステップ
Ｓ４４３）。具体的には、ステップＳ４４１において別名として設定した実行サーバＭの
ＩＰアドレスを、待機サーバ１７０のＬＡＮアダプタの設定からはずす。次に、実行サー
バ管理テーブル５００における実行サーバＭの稼働状態５０４を「回復中」から「停止」
に変更する（ステップＳ４４４）。そして、実行サーバ監視スレッドＭは、実行サーバ管
理テーブル５００における実行サーバＭの回復順序ポインタ５０５がＮＵＬＬか否かをチ
ェックする（ステップＳ４４５）。ＮＵＬＬの場合は（ステップＳ４４５のＹ）、再び実
行サーバＭの稼働状態を監視する（ステップＳ４６０、Ｓ４００）。ＮＵＬＬでない場合
は（ステップＳ４４５のＮ）、回復順序ポインタ５０５の指す実行サーバに対応する実行
サーバ監視スレッドにトランザクション回復処理の完了を通知し、その回復順序ポインタ
５０５をＮＵＬＬにリセットする（ステップＳ４５０）。このトランザクション回復処理
の完了の通知によって、通知先の実行サーバ監視スレッドにおけるステップＳ４３２の通
知待ちが解除される。そして、再び実行サーバＭの稼働状態を監視する（ステップＳ４６
０、Ｓ４００）。
【００３３】
第１の実施の形態では、複数の実行サーバに同一の業務処理プログラムを配備しているため、ステップＳ４４２〜Ｓ４４４によって、実行サーバ１６０〜１６２の多重障害が発生したときにおいても、クラスタシステム１０を縮退して業務処理を継続することができる。
【００３４】
図５を参照して、第１の実施の形態に係る実行サーバ監視スレッドが使用する実行サーバ管理テーブルの構成について説明する。実行サーバ管理テーブル５００は、実行サーバを一意に識別する実行サーバ識別子５０１、実行サーバのＬＡＮアダプタに付与するＩＰアドレス５０２、トランザクションの状態を格納する共有ディスク装置に関する情報である共有ディスク装置情報５０３、実行サーバの稼働状態５０４およびトランザクションの回復順序ポインタ５０５で構成されるレコードからなるテーブルである。
【００３５】
稼働状態５０４には、「停止」、「稼働中」、「回復中」および「待機中」がある。「
停止」は、当該実行サーバが、電源投入後、または、障害発生に対するトランザクション
回復後、まだ業務処理を行う状態になっていないことを示す。「稼働中」は、当該実行サ
ーバが、業務処理を行う状態になっていることを示す。「回復中」は、待機サーバ１７０
が、当該実行サーバの障害を検出して、トランザクションを回復している状態を示す。「
待機中」は、待機サーバ１７０が、実行サーバの多重障害が発生したとき、他の実行サー
バのトランザクションを回復中のため、当該実行サーバのトランザクションの回復を待機
させている状態を示す。
【００３６】
回復順序ポインタ５０５には、実行サーバの多重障害発生時、トランザクションを回復
する順序を示すリストを形成するために、次にトランザクションを回復する実行サーバへ
のポインタを格納する。前記リストの先頭は、稼働状態５０４が回復中の実行サーバであ
り、前記リストの最後は、前記リストを辿っていったときに初めて回復順序ポインタ５０
５がＮＵＬＬとなる実行サーバである。これによれば、障害が発生した順序に従ってトランザクションを回復するので、二重障害が発生したときのトランザクション回復の整合性を保障することができる。
【００３７】
≪第２の実施の形態≫
次に、第１の実施の形態と比較しながら、第２の実施の形態について説明する。図６は、第２の実施の形態に係るスタンバイ型クラスタシステムの構成を示す図である。この構成を第１の実施の形態のシステム構成（図１参照）と比較すると、図１のトランザクション回復処理手段１７３がトランザクション回復処理手段２（１７４）に置き換わっている。トランザクション回復処理手段２（１７４）は、実行サーバが停止した場合、その実行サーバの仕掛かりトランザクションを回復する機能を持つが、さらに、そのトランザクションを回復するためにリソースにアクセスするのに必要な情報を利用する機能を併せ持つ。
【００３８】
図７は、第２の実施の形態に係る実行サーバ管理テーブルの構成を示す図である。この構成を第１の実施の形態のテーブル構成（図５参照）と比較すると、リソース接続情報５０６が追加されている。リソース接続情報５０６は、実行サーバが接続していたリソースに関する情報であり、待機サーバがそのリソースにアクセスするのに必要な情報である。リソースとは、例えば、ＤＢサーバ１８０やＤＢサーバ１８１である。その場合、リソース接続情報５０６は、例えば、ＤＢサーバのＩＰアドレス、ユーザ名、パスワード、データベース名などである。図７では、１つのまとまったリソース接続情報５０６をＲＡと表現し、ＲＡ１、ＲＡ２、ＲＡ３のように例示している。仕掛かりトランザクションが２台以上のＤＢサーバまたは２個以上のＤＢにわたっているような場合には、実行サーバ１や実行サーバＮのレコードに示すように、リソース接続情報５０６が２つ以上のＲＡからなる。なお、リソースには、ＤＢサーバの他に、トランザクション処理を実現するＴＰモニタ（Transaction Processing Monitor）などが考えられる。
【００３９】
図８は、第２の実施の形態に係る実行サーバ監視スレッドの処理の一部を示すフローチャートである。この処理を第１の実施の形態の処理（図４参照）と比較すると、図４のステップＳ４４２がステップＳ８０１およびステップＳ８０２に置き換わっている。実行サーバ監視スレッドＭは、実行サーバＭのＩＰアドレスをテークオーバした（ステップＳ４４１）後、実行サーバ管理テーブル５１０から実行サーバＭのリソース構成情報５０６を取得する（ステップＳ８０１）。そして、その取得したリソース構成情報５０６のトランザクションを回復する（ステップＳ８０２）。
【００４０】
具体的には、リソース構成情報５０６と、実行サーバ管理テーブル５１０の共有ディスク装置情報５０３により当該共有ディスク装置から取得したトランザクションの状態とをトランザクション回復処理手段２（１７４）に指示することによって、実行サーバＭの仕掛かりトランザクションを回復する。このとき、トランザクション回復処理手段２（１７４）は、実行サーバ監視スレッドＭから指示されたリソース構成情報５０６に従ってＤＢサーバ１８０やＤＢサーバ１８１にアクセスし、同じく指示されたトランザクションの状態からトランザクションを回復する。その後、回復したトランザクションの状態を更新後、テークオーバしたＩＰアドレスを破棄する（ステップＳ４４３）。なお、以上説明した処理以外については、第１の実施の形態と同様である。
【００４１】
以上によれば、複数の実行サーバについて、それらのアプリケーションプログラムの種類や取り扱うデータベースの構造などのサーバ構成が一様でなくても、１台の待機サーバが各実行サーバのリソース接続情報を参照することによって、トランザクションの回復を行うことができる。なお、待機サーバが実行サーバの処理を引き継ぐことは行わないので、サーバ構成が一様である必要はない。これによれば、リソース接続情報を用いてリソースにアクセスするので、実行サーバの構成ごとに待機サーバを設ける必要はなく、待機系のコストを抑えることができる。
【００４２】
以上本発明の実施の形態について説明したが、図１に示す負荷分散装置および各サーバ
のそれぞれで実行されるプログラムをコンピュータによる読み取り可能な記録媒体に記録
し、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行す
ることにより、本発明の実施の形態に係るクラスタシステムが実現されるものとする。こ
こでいうコンピュータシステムとは、ＯＳ（Operating System）などのソフトウエアや周
辺機器などのハードウエアを含むものである。
【００４３】
≪その他の実施の形態≫
以上本発明について好適な実施の形態について一例を示したが、本発明は前記実施の形
態に限定されず、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。例えば、以下
のような実施の形態が考えられる。
（１）前記実施の形態においては、待機サーバ１７０が各実行サーバを監視したり、リセ
ットしたりするためにＫＡパスやリセットパスなどの信号線を使用するように記載したが
、それらの機能をネットワークによって実現してもよい。これによれば、待機サーバ１７
０と各実行サーバとの間に信号線を接続する必要がなくなるので、クラスタシステムの構
築コストを節減することができる。
（２）前記実施の形態においては、待機サーバ１７０が１台で構成されているように記載
したが、待機サーバに１：１スタンバイ構成を適用してもよい。また、現用系の実行サー
バやＤＢサーバなどのコストと比較して待機系として問題のないコストの範囲内で、複数
の待機サーバを配置してもよい。これによれば、待機サーバの可用性を向上させることが
できる。
【図面の簡単な説明】
【００４４】
【図１】第１の実施の形態に係るスタンバイ型クラスタシステムの構成を示す図である。
【図２】第１の実施の形態に係る待機サーバの処理の流れを示すフローチャートである。
【図３】第１の実施の形態に係る実行サーバ管理テーブルの初期化処理の流れを示すフローチャートである。
【図４】第１の実施の形態に係る実行サーバ監視スレッドの処理の流れを示すフローチャートである。
【図５】第１の実施の形態に係る実行サーバ管理テーブルの構成を示す図である。
【図６】第２の実施の形態に係るスタンバイ型クラスタシステムの構成を示す図である。
【図７】第２の実施の形態に係る実行サーバ管理テーブルの構成を示す図である。
【図８】第２の実施の形態に係る実行サーバ監視スレッドの処理の一部を示すフローチャートである。
【符号の説明】
【００４５】
１０    クラスタシステム
２０    クライアント
３０、１１５  ネットワーク
１００  負荷分散装置
１１０、１２０  ネットワークセグメント
１３０、１３１、１３２  ＫＡパス
１４０、１４１、１４２  リセットパス
１５０、１５１、１５２  共有ディスク装置
１６０、１６１、１６２  実行サーバ
１７０  待機サーバ
１７１  負荷分散装置制御手段
１７２  フェールオーバ順序制御手段
１７３  トランザクション回復処理手段
１８０、１８１  ＤＢサーバ
１９０、１９１  業務ＤＢ
５０６  リソース接続情報
【図１】
2005339525.tif 000003
【図２】
2005339525.tif 000004
【図３】
2005339525.tif 000005
【図４】
2005339525.tif 000006
【図５】
2005339525.tif 000007
【図６】
2005339525.tif 000008
【図７】
2005339525.tif 000009
【図８】
2005339525.tif 000010