JP2010020505A - クラスタリングを構成する計算機システムの系切替方法、及びシステム - Google Patents

Abstract

【課題】 障害サーバをリセットすることによって系切替を実現するクラスタシステムにおいて、性能劣化を生じる不要なリセットを防止する系切替方法を提供する。
【解決手段】 クラスタリングを構成する複数の計算機のうち、いずれかの計算機は、ある計算機を含む系障害を検知した場合、系の障害検知を他の系を構成する計算機に送信し、そのいずれかの計算機は、ある計算機を含む系の障害を検出し、他の系を構成する計算機から、ある計算機を含む系の障害通知を受信した場合、そのある計算機にリセットを発行する。
【選択図】 図７

Description

本発明は、アプリケーションを実行する実行系計算機および待機系計算機を有する計算機システムに関し、特にアプリケーションを実行中である計算機のプログラムもしくはオペレーティングシステムに障害があった時に、その実行中のアプリケーションを別の計算機に引き継がせる系切替制御を行う計算機システムに関する。

障害許容性を求められるアプリケーションシステムでは、複数のサーバによってデータ処理を行う実行系サーバと、実行系サーバに障害が発生した場合にデータ処理を引き継ぐ待機系サーバによるクラスタ構成によって信頼性を確保することができる。データベース（ＤＢ）のように、ディスクにデータを蓄積するアプリケーションでは、実行系サーバ及び待機系サーバからアクセス可能な共有ディスクによってデータを引継ぎ、待機系サーバによって処理を継続する。従って、ディスクへデータを同期的に書き込むＩ／Ｏ処理が必要となり、Ｉ／Ｏ処理性能によってシステム性能が決定される。

近年、広範的に利用されるアプリケーションシステムでは、上記のＩ／Ｏ性能によって決定されるシステム性能以上のシステム性能が必要となる場合が増えている。こうした要求に対して、メモリ上にのみデータを保持し、ディスク装置への同期的なＩ／Ｏ処理を無くすことで、システム性能を向上させるインメモリアプリケーションシステムが登場している。このようなインメモリアプリケーションシステムでは、そのままではメモリ上に保持したデータを待機系サーバと共有することはできないため、例えば、インメモリＤＢのように、メモリ上に保持されるデータを障害によって喪失することが許されない障害許容性が必要なアプリケーションでは、実行系サーバから待機系サーバに対して通信することで、実行系サーバのデータの複製を待機系サーバのメモリ上に保持させることでデータを冗長化する必要がある。このような障害許容性を考慮したインメモリアプリケーションシステムの一例として、特許文献１に示されるメモリＤＢシステムがある。特許文献１では実行系サーバが実行系サーバ上のデータベースで更新されたデータを待機系サーバ上の共有メモリに書き込むことで、待機系サーバにデータ複製を行い、障害時にデータを保証するような技術が開示される。

このように、障害許容性を求められるアプリケーションシステムにおいて、障害の発生したサーバ（障害サーバ）を、この障害を検出した正常なサーバがリセットする方法があり、例えば、特許文献２及び特許文献３に示される技術がある。特許文献２では、実行系サーバの障害を待機系サーバが検出した場合、障害を検出した待機系サーバが実行系サーバをリセットすることで、実行系サーバを停止させて、系切替を実現する技術に関して、各待機系サーバがリセットするタイミングが異なることで、リセットの競合を防ぐ技術が開示される。また、特許文献３では、同様のリセットによって系切替を実現する技術に関して、各待機系サーバが各々の障害検出時に発行するリセットを受信するリセット装置が、各リセットの競合を判断することで、リセットの競合を防ぐ技術が開示される。

日本特開２００５−２９３３１５号公報 日本特開２００６−１１９９２号公報 日本特開２００６−２８５８１０号公報

特許文献２、３に記載される技術は、ある１台の待機系サーバが実行系サーバを含む他のサーバの障害を検出した場合には、それらのサーバをリセットして系切替を行うため、系切替後には１台の実行系サーバで稼動することになる。ここで他のサーバの障害を検出する例として、その一台の待機系サーバが、監視用のネットワークの障害で、他のサーバを通信できなくなった場合や、あるサーバ自身の障害が生じた場合である。他のサーバいずれかの障害である場合は、そのサーバに対し、リセットを生じて、その後、その他のサーバで系切替を実行すればよい。しかし、監視用ネットワークの障害である場合は、正常稼動しているにも拘らず、実行系サーバと少なくとも１台以上の待機系サーバが存在するような高速に動作しているシステムをリセットし、リセットを発行した実行系サーバ１台で系切替をすることになる。その場合、正常に稼働しているサーバは、データ喪失を避けるためには、処理を中止する必要があり、システム停止という性能劣化が生じる。

あるいは、実行系サーバのデータを何らかの手段で保存しながら処理を継続したりする必要がある。例えば、ディスクへの同期的に保存する方法を用いたとしてもＩ／Ｏ処理性能から、性能劣化が生じる課題が同様に起きる。このように、上記特許文献２、３で開示されるリセットによるクラスタシステムでの系切替方法では、性能劣化を引き起こす不要なリセットを伴う系切替が生じる。

以上の課題に鑑みて、クラスタシステムにおいて、サーバ間でリセットを行い、系切替を実現する場合、不要なリセットを防止することを本発明の目的の一つとする。

本発明の一形態は、以上に示す課題の少なくとも一つを解決することを鑑みたものであり、クラスタリングを構成する複数の計算機のうち、いずれかの計算機は、ある計算機を含む系障害を検知した場合、系の障害検知を他の系を構成する計算機に送信し、そのいずれかの計算機は、ある計算機を含む系の障害を検出し、他の系を構成する計算機から、ある計算機を含む系の障害通知を受信した場合、そのある計算機にリセットを発行する、構成を有する。ここで、ある系が他系の障害を検出するケースとして、実際に他系を構成する計算機が障害である場合のほか、正常稼動しているような場合あっても、障害監視に利用する監視パスの障害や、サーバの監視プログラムのバグがあげられる。

本発明の一形態により、不要なリセットを防止する系切替方法を提供することができる。

以下、本発明の実施の形態を添付図面に基づいて説明する
ここで、本発明に関する図と説明は、本発明を鮮明に理解するのに適当な要素を示すために簡略化されており、発明を実施するのに支障ない範囲で既知の要素等は省略していることを理解されたい。本技術中で従来技術の中には、本発明を実装するために他の要素が望ましく、かつ／または、必要とされると思われるものが幾つかある。しかし、技術中のこれらの要素は既知であり、本発明の理解を容易にするものではないので、ここでは説明しない。

また、以下の説明では、各プログラムは実行系サーバのモジュール番号で説明している場合もあるが、それらの説明は、待機系サーバの対応したプログラムの説明も兼ねる場合もある。さらに、以降の図に示す符号において、他の図中の数字と同様の番号を用いているものがあるが、それらについては特に説明がない場合は、他の図の説明と同様である場合もある。
＜第１の実施の形態＞
図１から図１３は本発明における第１の実施形態について表している。第１の実施形態は、理解を容易にするために、３台の物理計算機によって構成されるクラスタシステムの例を用いて説明するが、３台以上のクラスタシステムに対しても適用可能である。

図１は、第１の実施形態におけるクラスタステムの構成を表すブロック図である。

第１の実施形態の物理計算機１００は、ＮＩＣ１０３、１０４、１０５と、プロセッサ１０１と、メモリ１０２と、リセット装置１０６を備える。

プロセッサ１０１は、メモリ１０２に格納されたプログラムを実行することによって、各種処理を実行する。メモリ１０２は、プロセッサ１０１によって実行されるプログラムおよび処理に必要なデータを格納することができる。ＮＩＣ１０３、１０４、１０５は、ネットワークである業務パス１１１、監視パス１１２を介して、他の計算機（例えば、クライアントや、待機系サーバ）と通信する。また、ＮＩＣは、リセットパス１１３を介して、物理計算機１００をリセットするリセット装置１０６と通信する。なお、プロセッサ１０１は複数のコアを備え、複数の処理を並列的に実行可能であってもよい。

物理計算機２００、３００も上記と同様に構成される。以下では、系Ａ５１００が実行系サーバ、系Ｂ５２００、系Ｃ５３００が待機系サーバとして、説明を行う。

メモリ１０２には、系切替を行う対象であるアプリケーションプログラムの例であるメモリＤＢプログラム１２１と、クラスタ管理コンソール１４１を有する。

メモリＤＢプログラム１２１は、系Ａ５１００１００で実行系サーバ、系Ｂ５２００、系Ｃ５３００では待機系サーバとして稼動しており（メモリＤＢプログラム（待機）121aと図示）、実行系サーバから待機系サーバに対して業務パス１１１を介してデータ複製が行われ、データの整合性を保つ機能を有する。

メモリ１０２には、サーバの状態を示すクラスタ状態管理表１３４、リセットを発行するタイミングに関する定義情報を有するリセット定義１３５および、リセットを発行するために必要なリソース量として物理計算機台数を指定する系切替許容台数定義１３６が格納される。

また、メモリ１０２は、自系の状態（ハートビート：以下、ＨＢ）を通知するＨＢ送信プログラム１３１と、他系からのＨＢにより他系の障害を監視し、その監視結果をクラスタ状態管理表１３４に反映する監視プログラム１３２と、表１３４を参照して、他系のリセット装置１０６にリセットを発行する系切替制御プログラム１３３と、を有する。以下、ＨＢ送信プログラム１３１，監視プログラム１３２および系切替制御プログラム１３３を実行するプロセッサ１０１をそれぞれ、ＨＢ送信部、監視部および系切替制御部という。

また、監視部は、他系の監視部と互いに検出した他系の障害を通知する。さらに、系切替制御部は、障害の系のリセットが完了した場合に、系切替を行う。

図２は、クラスタ状態管理表１３４を示す図である。クラスタ状態管理表１３４は、各系の系識別子２０１、識別子２０１で特定される系（サーバ）の状態が「正常」、「障害」、あるいはリセット中を含む「未稼動」を表す系状態２０２を示す欄を有する。さらに、状態管理表１３４は、系状態２０２が「障害」を示している場合に識別子２０１の系の障害を検出した計算機台数を示す障害検出台数２０３、識別子２０１で特定される系の系障害検出を認識する猶予時間を表す待合せタイマ２０４、及び、識別子２０１の系をリセットするまでの猶予時間を表すリセットタイマ２０５の欄を有する。待ち合わせタイマ２０４、リセットタイマ２０５は、タイマがセットされている場合にはその数値を保持する。一方、タイマがクリアされた場合を含む、セットされていない状態の場合には、数値以外、例えば「−」を保持することで、タイマのセットの有無が分かるような情報を保持する。
図３は、系切替許容台数定義１３６の一例を示す。系切替許容台数定義１３６は、リセットを発行するために必要なリソース量を表す系切替許容台数３０１を含み、「２台」が設定された例である。

図４は、リセット定義１３５の一例を示す。リセット定義１３５は、リセット優先度４０１、リセット間隔４０２の欄を有する。リセット優先度４０１は、各系がリセットを発行する優先度を表す。リセット間隔４０２は、リセット優先度４０１に基づいて各系が競合を生じないようにリセットを発行する時間間隔を表す。本実施例では、リセット優先度４０１を示す値が数値で表され、最も低い値が最優先である例を示す。図４では、系Ａ５１００、系Ｂ５２００、系Ｃ５３００からなる３台構成のクラスタシステムにおいて、順にリセット優先度が高くなるように設定されている。また、リセット間隔４０２の欄には「５秒」と示され、リセットを発行する時間間隔が「５秒」設定された例である。

各系の系切替制御部は、図４に示したリセット定義を用いると、各系でリセット発行が可能となった場合にリセット優先度順に５秒間隔でリセットタイマを設定する。リセット優先度が最優先の系のリセットタイマは任意で動作可能であるが、動作を単純化するため、以下ではリセットタイマが０秒である場合で説明する。また、ここで、リセット定義１３５は、障害サーバをリセットすることによって系切替を実現する場合において、リセットの競合を回避する方法を決定する一例を示すものであり、実施形態で示した定義と異なる定義を用いてもよく、その場合でも本実施形態を適用可能である。

例えば、異なる定義の一例として、リセット優先度４０１は、全システムの系のリセット優先度を含まず、各系に自系のリセット優先度のみを定義してもよく、この場合、各サーバが相互通信することで、クラスタシステムのリセット優先度を決定することができる。あるいは、稼動しているアプリケーションの状態に応じて、リセット優先度を動的に決定する方法であっても良く、この場合はリセット優先度定義を決定する指標となるアプリケーションの状態が定義されることもある。

図８から図１０は、フローチャートの一例を表す図である。

図８は、ＨＢ送信部が一定時間で自系の正常を通知するハートビートを行う処理を表すフローチャートである。まず、ＨＢ送信部は、ＨＢを送信する一定時間が経過したかを判断する（処理Ｓ８０１）、一定時間が経過していない場合には、再度処理Ｓ８０１に戻る。一方、一定時間が経過している場合には、自系が正常であることを他系の監視部８８１に監視パスを介して通知し（処理Ｓ８０１、Ｔ８５１）、次のハートビートを送信するために処理Ｓ８０１に戻る。
以上により、ある系が正常に動作し、監視パスが正常であれば、他系に正常であることを通知することが可能である。

図９は、監視部が障害を監視し、監視結果に基づいて行う処理の一例を示すフローチャートである。

図９では、まず、監視部が他系のＨＢ送信部又は監視部からの通信を受信する処理Ｓ９０１を実施し、通知を受信したかどうかを判断する（処理Ｓ９０２）。通知を受信していない場合には、監視部は、ハートビートが送信されるべき一定時間の間、他系からの正常状態の通知が受信していないかを判断し（処理Ｓ９０３）、受信している場合は、再び他系からの通信の受信処理Ｓ９０１へと戻る。

一方、処理Ｓ９０３で一定時間正常であることを受信していない場合には、監視部は、他系が障害であると検出し（処理Ｓ９０４）検出処理では、クラスタ状態管理表１３４の系Ａ５１００の系状態を「障害」と記憶する。次に、監視部は、自系が他系の障害を検出したことを、監視パスを介して他系の監視部９８２に通知する（処理Ｓ９０５）。続いて、監視部は、クラスタ状態管理表１３４の、障害であると検出された他系の識別子に対応する障害検出台数２０３のカウントを１増加する（処理Ｓ９０６）。監視部は、すでに検出済の障害かどうかを判断するために、待合せタイマがセットされているかどうかを判断し（処理Ｓ９０７）、セット済の場合には、処理Ｓ９０１に戻る。一方、監視部は、未セットの場合には、他系が系Ａ５１００の障害を検出するのを待ち合わせる猶予時間をクラスタ状態管理表１３４の待合せタイマに設定し（処理Ｓ９０８）、Ｓ９０１に戻り、監視を継続する。

一方、処理Ｓ９０２で、通知を受信した場合には、監視部は、他系の障害通知Ｔ９５２かどうかを判断する（処理Ｓ９０９）。他系の監視部からの他系障害通知である場合には、監視部は、処理Ｓ９０６以降を実施する。一方、そうでない場合（Ｓ９０９のＮｏ）は、監視部は、他の監視部からのリセット完了通知Ｔ１０５３であるかどうかを判断する（処理Ｓ９１０）。リセット完了通知だった場合には、障害が起きた系がリセットされたため、監視部は、クラスタ状態管理表１３４で、リセットされた障害系の系状態２０２で示す値をクリアし（処理Ｓ９１１）、処理Ｓ９０１へと戻り、監視を継続する。処理Ｓ９１１では、例えば、系状態２０２の欄で示す値を「未稼動」に変更し、リセットタイマ、待合せタイマ、及び、障害検出台数をクリアする処理を含んでもよい。一方、処理Ｓ９１０でリセット完了通知でない場合は、他系の監視部からの正常通知Ｔ８５１が受信されたことを意味するため、監視部は、他系が正常状態であることを検出し（処理Ｓ９１２）、処理Ｓ９０１へと戻り、監視を継続する。なお、処理Ｓ９１２では、判断処理Ｓ９０３での一定時間の通知の有無を検出するため、正常状態を受信した時刻に関する情報を記憶する処理が含まれてもよい。例えば、クラスタ状態管理表１３４の系状態２０２に系の状態「正常」とあわせて、時刻を記録する方法を用いてもよい。

また、Ｓ９０８では、待合せタイマに設定する時間は、リセットの競合を避けるために、クラスタシステムの全サーバがリセットを発行するのに十分な時間を設定する。例えば、リセット定義１３５を用いた場合、リセット優先度が最も低い系Ａ５１００を考慮し、全サーバ数×リセット間隔である「１５秒」が設定される。

図１０は、系切替制御部が障害サーバの障害時に、一定量のリソースである系切替許容台数を満たしているかを判断して、リセットを実施する処理の一例を示すフローチャートである。

図１０では、まず、一定量のリソースが障害を検出した系で満たすかどうかを判断するために、系切替制御部は、系切替許容台数定義１３６を参照し、障害サーバの障害検出台数２０３で示される台数が系切替許容台数以上であるかどうかを判断する（処理Ｓ１００１）。許容台数を満たさない場合には、S１００１に進み、系切替制御部は、待合せタイマに設定された時間が経過しないかを判断し、経過していない場合には、Ｓ１００１に戻る。一方、処理Ｓ１００２で、待合せタイマの時間が経過している場合には、S１００３に進み、系切替制御部は、一定量のリソースである系切替許容台数を満たせず、リセットが発行できなかったことを示すリセット未発行を、ユーザに通知する（処理Ｓ１００３）。

系切替制御部は、強制リセットが指示されたかどうかを判断する（処理Ｓ１００４）。指示があった場合には、系切替制御部は、リセットを発行するために処理Ｓ１００８以降を実行する。一方、指示が無い場合には、Ｓ１００４を繰り返し、ユーザからの指示の入力を待つ。また、S１００４を省略してS１００１に戻ってもよい。
ここで、ユーザからの応答Ｉ／Ｆ１１０３、１１０４を含まない場合には、指示を待ち合わせる必要はないため、処理Ｓ１００１に戻っても良い。

次に、処理Ｓ１００１で、障害検出台数が系切替許容台数以上である場合を説明する。S1001でYに進み、S1005で、系切替制御部は、クラスタ状態管理表１３４に含まれるリセットタイマ２０５をセットする（処理Ｓ１００５）。その後、Ｓ９１１と同様に、系切替制御部は、クラスタ状態管理表１３４を参照し、障害系の系状態２０２がクリアされていないかを判断する（処理Ｓ１００６）。

系状態がクリアされた場合には他系によって障害サーバのリセットが完了されているため、系切替制御部は、処理Ｓ１００１に戻り、再び判断処理Ｓ１００１を繰り返す。一方、クリアされていない場合は、クラスタ状態管理表１３４を参照し、系切替制御部は、クラスタ状態管理表１３４を参照し、リセットタイマで設定された時間が経過したかを判断する（処理Ｓ１００７）。経過していない場合には、系切替制御部は、再び処理Ｓ１００６を繰り返す。一方、処理Ｓ１００７で、リセットタイマにセットされた時間が経過した場合には、系切替制御部は、障害系のリセット装置に対してリセット要求Ｔ１０５１を発行する（処理Ｓ１００８）。障害系のリセット装置がリセット成功応答Ｔ１０５２を返してきた後、処理Ｓ９１１と同様に、障害系の系状態をクリアし（処理Ｓ１０１０）、系切替処理Ｓ１０１１を実行する。

ここで、本実施形態におけるシーケンス及びフローチャートは、ある一つの系の障害を監視し、リセットする動作を中心に説明したが、他の系に対しても同様の処理を行うために、各部が同様の処理を並列実行していてもよく、その場合も適用可能である。

図１１は、処理Ｓ１００３でユーザに通知するＩ／Ｆの例である。図１１において、クラスタコンソールでの表示画面１１０１は、リセットが発行できなかったことを示すメッセージ部１１０２を含む。また、表示画面１１０１は、ユーザが強制的にリセットを行うように指示を促す質問メッセージ部１１０３や、質問に対する応答Ｉ／Ｆを含んでも良く、応答Ｉ／Ｆは例えば、図１１に示すように、ユーザが簡単に選択可能なＩ／Ｆ１１０３、１１０４によって実現されてもよい。また、さらに、ユーザによる応答を助けるためのＩ／Ｆとして、定義情報を参照させるＩ／Ｆ１１０５を含んでもよい。ここで、Ｉ／Ｆ１１０５で参照可能な情報の一部ないしは全部を予めメッセージ部１１０２が含んでもよい。図１１に示すI/Fのような画面を、クラスタ管理コンソールを介して表示させることで通知する方法を用いても良い。

さらに、ユーザが強制的にリセットを実施するかどうかを指定するＩ／Ｆの別の形態として、例えば、図１２に示す物理計算機の構成のように、強制リセット定義１３７をメモリ１０２に格納していてもよい。図１３は、強制リセットの有無を表す情報１３０１を指定する強制リセット定義１３７の内容を示す図である。保持してもよい。このような構成の場合、処理Ｓ１００３でのユーザへの通知処理は、実施しない方法を用いても良い。あるいは通知する場合には、図１１の質問メッセージ部１１０３の代わりに、強制リセットを実行した旨のメッセージを出力してもよい。あるいは、メッセージ部１１０２以外は管理コンソールで入出力しない方法を用いてもよい。なお、図１２の構成は、一つの物理計算機のみのハードウェア構成およびプログラムやデータの格納例を示したが、他の物理計算機２００，３００も同様の構成であってもよい。

図５から図７は、図８ないし図１０で説明した処理を実行した際の複数の系との関係を説明した動作シーケンスを示す図である。なお、以降の実施形態でも同様のシーケンス図を用いて説明をする場合があるが、これらのシーケンス図は、本発明の処理の理解を容易にすることを目的とし、当該処理以外の処理は簡略化されていることを理解されたい。
図５は、第１の実施形態における系切替許容条件を満たした場合に実行される動作を表すシーケンス図である。本図では、図１に示したクラスタ構成において、図３・図４に示した定義がされた場合において、各実行系サーバである系Ａ５１００に障害５１１が発生した場合を一例として説明する。
まず、系Ａ５１００で障害５１１が発生すると、待機系サーバである系Ｃ５３００との間の正常通知（ハートビート）が途絶する（５１２）。系Ｃ５３００の監視部は、図９に示す処理を実行し、正常通知途絶を契機に、系Ａ５１００の障害を検出し、処理５１３を開始する。ここで、検出処理では、クラスタ状態管理表１３４の系Ａ５１００の系状態を「障害」と記憶する処理を含む。処理５１３は、他系の監視部に対して、系Ｃ５３００が系Ａ５１００の障害を検出したことを通知し（５１４、Ｓ９０５）、クラスタ状態管理表の障害検出台数を１台増加させ、他系が系Ａ５１００の障害を検出するのを待ち合わせる猶予時間をクラスタ状態管理表の待合せタイマを設定する（５１６、Ｓ９０６，Ｓ９０８）。ここで、待合せタイマは、リセットの競合を避けるために、クラスタシステムの全サーバがリセットを発行するのに十分な時間を設定する。例えば、リセット定義１３５を用いた場合、リセット優先度が最も低い系Ａ５１００を考慮し、全サーバ数×リセット間隔である「１５秒」が設定される。

次に、系Ｃ５３００の系切替制御部は、クラスタ状態管理表１３４を参照し、障害サーバの障害検出台数が、系切替許容台数以上であるか、あるいは待合せタイマに設定された時間が経過していないかの２条件を判断する処理を繰り返し実施する。監視部の処理５１３が終了した後には、処理５１７で判断処理（５１６）が行われ、２条件とも満たさないため、処理が終了する。処理５１７及び５１８は、図１０の処理に対応している。

一方、系Ｂ５２００では、まず系Ａ５１００障害通知５１４を受信した監視部は、系Ｃ５３００の処理５１３〜５１６と同様の処理５１９〜５２２を、さらに、系切替制御部が処理５１７、５１８と同様の処理５２２、５２３を行う。

一方、系Ａ５１００の障害５１１を同様の正常通知途絶５３１によって系Ｂ５２００が検出した場合にも処理５３２〜５３４、５３３〜５３４、５３８〜５３９、及び５４０〜５４１として、それぞれ処理５１３〜５１５、５１７〜５１８、５１９〜５２０、５２２〜５７３に対応する同様の処理が行われる。ここで、各系では待合せタイマがセットされているため、待ち合わせタイマをセットする処理は行われない。

以上の一連の処理により、系Ｂ５２００、系Ｃ５３００は系Ａ５１００の障害検出台数は「２台」となるため、判断処理５３６、５４１で系切替許容台数以上であると判断され、リセットタイマをセットする処理５３７、５４２（図１０のＳ１００５）が処理５３５、５４０に含まれて実施される。本実施形態では、それぞれ、系Ｂ５２００に「５秒」系Ｃ５３００に「０秒」が設定される。

従って、系Ｃ５３００が系Ｂ５２００より先にリセットタイマ時間が経過するため（５５１）、系Ｃ５３００の系切替制御部が、リセットによる系切替を実施する一連の処理５５２を実施する（図１０のＳ１００７，Ｓ１００８）。

処理５５２では、系Ｃ５３００の系切替制御部がクラスタ状態管理表を参照することで、リセットタイマ時間の経過を検出し（５５３）、障害となった系Ａ５１００のリセット装置にリセットを要求し（５５４）、リセット装置が系Ａ５１００のリセット（５５５）後にリセット成功を通知するのを受信する（５５６）処理が行われる。受信後、クラスタシステムの他系の監視部に系Ｃ５３００が系Ａ５１００のリセットを完了したことを通知し（５５７）、クラスタ状態管理表からリセットが完了した系Ａ５１００の情報をクリアし（５５８）、系切替処理５５９を行う。

一方、系Ｂ５２００は、通知５５７を受信したことを契機に、処理５５８同様に、系Ａ５１００の情報をクリアする処理５６１を含む処理５６０が実施される（図９のＳ９０１，Ｓ９１０，Ｓ９１１）。これにより、系Ｂ５２００でセットされたリセットタイマがクリアされ、系Ｂ５２００からのリセットが生じなくなる。ここで、系切替処理５６１は、他系である系Ｂ５２００と協調して動作するような系切替処理を含んでもよい。例えば、協調動作する系切替処理として、系切替先を系Ｃ５３００ではなく、系Ｂ５２００とするような系切替処理がある。

以上、図５に示す一連の処理により、ある系が障害の場合には、他系からリセットすることが可能であり、系切替処理を実現することができる。

図６は、本発明の第１の実施形態における系切替許容条件を満たした場合に実行される動作を表すシーケンス図である。本動作は、系Ｃ５３００が他系とハートビートができなくなるような障害が発生した場合に生じる動作であり、他系からの障害通知を受信せず、かつ、他系からリセットされる場合の動作を示すものである。このような障害として、例えば、系Ｃ５３００の監視パス用ＮＩＣの障害６１１や、系Ｃ５３００のＨＢ送信部の障害などがあり、本例では前者の場合を一例として説明する。

まず、系Ｃ５３００では、図５と同様に、図９のＳ９０１ないしＳ９０８及び図１０のＳ１００１ないしＳ１００７に対応する処理で、系Ａ５１００の障害検出を含む処理５１２〜５１８が行われる。なお、系Ａ５１００の障害通知５１４は、障害６１１によって他系に通知されない点は異なる。

一方、系Ａ５１００及び系Ｂ５２００は、正常稼動中であるため、図９のＳ９０１ないしＳ９０８及び図１０のＳ１００１ないしＳ１００７、さらにＳ１００８ないしＳ１０１０に対応する処理で、処理５１２〜５２３及び５３１〜５４２と同様に、処理６３１〜６４２及び６５１〜６６２が行われる。但し、系Ａ５１００、系Ｂ５２００でリセットタイマを設定する処理６５７、６６０では、各系のリセット優先度に応じて「１０秒」「５秒」が設定される。系Ａ５１００、系Ｂ５２００でセットされるリセットタイマの値は、系Ｃ５３００の待合せタイマよりも小さいため、正常に稼動している系のリセットタイマ時間が先に経過することが保証される。従って、リセット優先度がより小さい系Ｂ５２００が、リセットタイマ時間が経過し（６７１）、系Ｃ５３００、系Ｂ５２００が系Ａ５１００に対して行う処理５５２〜５６１と同様に、系Ｂ５２００、系Ａ５１００が系Ｃ５３００に対して処理６７２〜６８１を実施する。なお、系切替処理６７９は、系Ａ５１００に実行系サーバが存在することを検出することで、実行サーバを系Ｂ５２００に切り替える動作を行わない処理を含んでも良い。この場合には系切替は行われず、Ｓ１０１１は実行されない。

以上、図６に示す一連の処理により、系Ａ５１００と系Ｂ５２００が正常稼動している場合には、系Ｃ５３００が系Ａ５１００、系Ｂ５２００をリセットすることなく、系Ａ５１００、系Ｂ５２００から系Ｃ５３００をリセットすることが可能であり、性能低下を引き起こす系切替を防ぐことができる。

図７は、本発明の第１の実施形態における系切替許容条件を満たさなかった場合に実行する処理の異なる一例を示すシーケンス図である。本図も、図６と同様に、系Ｃ５３００が他系とハートビートができなくなるような障害が発生した場合に生じる動作である。しかし、他系からリセットされず、待ち合わせタイマに設定された時間が経過した場合の動作を示すものである。このような障害として、例えば、系Ａ５１００、系Ｂ５２００の両方に障害７１１、７１２が発生した場合や、系Ｃ５３００の監視パス用のＮＩＣ障害と系Ａ５１００、系Ｂ５２００の一方に障害が発生した複合的な障害が発生した場合などがあり、本例では前者の場合を一例として説明する。

まず、系Ｃ５３００では、図６と同様に、図９のＳ９０１ないしＳ９０８及び図１０のＳ１００１ないしＳ１００７に対応する処理で、系Ａ５１００の障害検出を含む処理５１２〜５１８が行われる。その後、系Ａ５１００、系Ｂ５２００が障害であるため、系Ｃ５３００はリセットされないことから、処理５１６で設定された待合せタイマ時間が経過し（７２１）、系切替制御部は処理７２２を実行する。処理７２２では、クラスタ状態管理表を参照することで、待合せタイマ時間の経過を検出し（７２３及び図１０のＳ１００２）、系切替条件である系許容台数を障害検出台数が満たさなかったため、リセットが発行されなかったことをクラスタ管理コンソールに通知する（７２４及び図１０のＳ１００３）処理を含む。通知を受けた管理コンソールは、ユーザに対する処理７２５を実施する。処理７２５では、７２４の通知内容をユーザに表示する（７２６）。加えて、処理７２６は、ユーザから系Ａ５１００のリセットを強制的に実施するかどうかの指示を受ける処理７２７を含んでも良い。指示を受け付けた場合には、処理７２８以降の処理がクラスタ管理コンソール及び系切替制御部で実施される。まず、管理コンソールが系切替制御部に系Ａ５１００の強制リセットを指示し（７２８及び図１０のＳ１００４）、系切替制御部は、指示を契機に５５４〜５５９と同様に、系Ａ５１００をリセットし系切替を行う処理７２９〜７３４を実施する（図１０のＳ１００８）。尚、系Ａ５１００のリセット完了通知７３２は障害７１２によって、他系には通知されない点は異なる。

なお、図７では、図５、図６と同様に、系Ｂ５２００の障害７１１に対応した系Ａ５１００に対するリセットを伴う系切替の動作のみを表すシーケンスしか記載されていないが、系Ｂ５２００の障害７１２に対応した系Ｂ５２００に対するリセットを伴う系切替の動作が、同様にして行われることもある。

以上、図７に示す一連の処理により、リセットによる系切替が行われない場合をユーザが知ることの出来るＩ／Ｆが提供されるとともに、ユーザの指示によって、実行系サーバの系Ａ５１００が障害である場合には、障害による業務停止状態を継続させないように性能低下を引き起こしてでもリセットすることで系切替を行うことができる。

以上、図１から図１３に示した第１の実施形態によれば、障害系を検出している正常稼動中の系の台数を管理し、系切替許容台数を満たすかどうか判断し、リセットによる系切替を制御することで、実行系サーバが系切替許容台数のクラスタ構成で性能を維持して、正常稼動中である場合には、クラスタ構成に属さない障害系をリセットすることが可能となるため、リセット後に系切替をしても性能を維持できないような系切替を防ぐことができる。
さらに、系切替許容台数を満たさなかった場合に、リセットが未実施となる場合をユーザに通知することができる。さらに、その場合にユーザが強制リセットを指示して、リセットによる系切替を実施させることも出来るため、性能を維持できない系切替をユーザの判断に基づいて実施することも可能である。

＜第２の実施の形態＞
図１４から図２３は、本発明における第２の実施形態について表しており、第１の実施形態の一部を変更して実施することで実現される。
図１４は、第２の実施形態におけるクラスタシステムの構成を表すブロック図である。図１に示した第１の実施形態におけるブロック図の一部を変更したものである。

図１４において、図１と異なる点は、リセット制御装置４００がリセットパス１１３に接続される点である。

第１の実施形態と同様に、物理計算機のメモリ１２１には、ＨＢ送信プログラム１３１と、監視プログラム１４３２と、系切替制御プログラム１４３３が格納される。ここで、後二者は、詳細はシーケンス図及びフローチャートを用いて後述するが、第１の実施形態と異なる動作を行う。

監視プログラム１４３２は、プロセッサにより実行され、図１５に示されるクラスタ状態管理表１４３４である系の障害状態を管理することで障害を検出する監視部を構成する。系切替制御プログラム１４３３は、プロセッサにより実行され、障害を検出した場合には、リセットパスを介して、リセット制御装置に障害系のリセットを行うように指示を出す系切替制御部を構成する。図１５は、クラスタ状態管理表を示す。第１の実施形態におけるクラスタ管理表１３４が有していた情報と同様の系識別子２０１、系状態２０２を含む。

リセット制御装置４００は、ＮＩＣ４３と、プロセッサ４１と、メモリ４２を備える。物理計算機１００と同様に、プロセッサ４１は、メモリ４２に格納されたプログラムを実行することによって、各種処理を実行する。ＮＩＣ４３は、ネットワークであるリセットパス１１３を介して、各物理計算機のリセット装置１０６と通信する。なお、プロセッサ４１は複数のコアを備え、複数の処理を並列的に実行可能であってもよい。メモリ４２には、リセット状態管理プログラム、リセット制御プログラム、また、本例では、リセット制御装置が物理計算機と同様の構成である例を示したが、プロセッサ４１がメモリ４２に格納された各プログラムを実行した場合の処理と同様の処理を行なう一つ以上の演算装置によって構成されてもよい。

メモリ４２は、プロセッサ４１によって実行されるリセット状態管理プログラム１０１及びリセット制御プログラム４０１を有する。さらに、メモリ４２は、リセット状態表４０３、系切替許容台数定義４０４および虚勢系切替定義４０５を有する。

リセット制御装置４００のプロセッサ４１は、リセット状態管理プログラム１０１を実行し、各系からのリセット要求の状態をリセット状態表４０３で管理するリセット状態管理部１０１を構成する。また、リセット制御装置４００のプロセッサ４１は、リセット制御プログラムを実行することにより、系切替許容台数定義１３７と同様の系切替許容台数定義４０４を用いて、各系から要求されたリセットを発行する処理を行うリセット制御部４０１を構成する。さらに、強制リセット定義１３７と同様の強制リセット定義４０５を備えてもよい。

リセット状態表は、図１６に示すように、リセット要求先の系を表す障害系識別子１６０１と、何台が障害系にリセット要求を発行したか表す障害検出台数１６０２と、リセット要求元の系を表す障害検出元識別子１６０３を有する。ここで、識別子１６０３は、リセット制御装置が受信した順序を一緒に記録する機能を有しており、例えば、図１６では、表の先頭からリセット要求順に情報が保持される。

図２０から図２３は、障害検出処理およびリセット発行制御処理に関するフローチャートの一例を表す図である。なお、ＨＢ送信部の動作は、第１の実施形態の動作図８と同様である。
図２０は、監視部が障害を監視し、監視結果に基づいて行う処理の一例を示すフローチャートである。図２０では、まず、監視部が図９の処理Ｓ９０１〜Ｓ９０４及び処理Ｓ９１０〜Ｓ９１２と同様に、処理Ｓ２００１〜Ｓ２００４及び処理Ｓ２００５〜２００７を実施する。第１の実施形態との違いとしては、まず、処理Ｓ２００４では、他系障害検出によってクラスタ状態管理表１４３４の系状態２０２を「障害」と変更し、処理２００１へと戻る。次に、処理Ｓ２００２で通信を受信していないと判断された場合には、監視部は、リセット完了通知を受信したかを判断する（Ｓ２００５）。また、処理Ｓ２００７で、障害系の系状態をクリアする場合、監視部は、管理表１４３４の系状態を「未稼動」に変更し、処理Ｓ２００１へと戻る。

図２１は、系切替制御部が障害サーバの障害時にリセット要求をリセット制御装置に発行する処理の一例を示すフローチャートである。
図２１では、まず、系切替制御部は、処理Ｓ２００４によって検出された障害系があるかを判断する（処理Ｓ２１０１）。障害系がない場合は処理Ｓ２１０１を繰り返し実行する。一方で、障害系がある場合には、系切替制御部は、リセット制御装置２１８１に対してリセット要求Ｔ２１５１を発行する（処理Ｓ２１０２）。リセット要求発行後、系切替制御部は、リセット応答Ｔ２１５２を受信したかを判断する。受信していない場合は、監視部が処理Ｓ２００７で障害状態クリアを実施したかを判断し（処理Ｓ２１０４）する。判断結果、障害状態がクリアされていない場合には、障害系のリセットは行われていないため、系切替制御部は、処理Ｓ２１０３に戻り、リセット応答の受信確認処理を繰り返す。一方、処理Ｓ２１０４で障害状態クリアがされた場合には、他系からのリセットによって障害系がリセットされているため、系切替制御部は、処理Ｓ２１０１に戻り、他の障害系を判断する処理を継続する。

一方、処理Ｓ２１０３で、系切替制御部は、リセット応答を受信した場合には、リセット応答の種別の判断を行う（処理Ｓ２１０５）．リセット成功である場合は、図１０の処理Ｓ１００９〜Ｓ１０１１と同様に、処理Ｓ２１０９〜Ｓ２１１１を実施し、他系の監視部２１８３へのリセット完了通知Ｔ２１５５と系切替処理Ｓ２１１１を行う。

また、処理Ｓ２１０５で、リセット応答の内容がリセットタイムアウト通知である場合には、一定量のリソースである系切替許容台数を満たせず、リセット制御装置がリセットを発行できなかった場合である。従って、図１０の処理Ｓ１００３、Ｓ１００４、及びＳ１００８と同様に、系切替制御部は、図１１のようなＧＵＩを出力し（Ｓ２１０６）、ユーザからの今日世知リセットの発行指示を待ち、発行指示があれば、リセット強制発行を行う（Ｓ２１０７、Ｓ２１０８）処理Ｓ２１０７、Ｓ２１０８は、強制リセット定義４０５を含めて、第１の実施形態と同様にあらかじめ強制リセットＯＫか否かを定義しておいてもよい。

図２２は、リセット制御装置のリセット状態管理部が各系から受信したリセット要求から障害検出台数を管理する処理の一例を示す。

まず、リセット状態管理部は、系切替制御部からのリセット要求２２５１を受信し（処理Ｓ２２０１）、リセット状態表４０３の障害検出台数１６０２のカウントを＋１、値を増加する（処理Ｓ２２０２）。さらに、障害検出台数のカウント増加とともに、系Ａ５１００へのリセット要求を発行した系を特定する識別子と発行時刻や順序、複数の系の間での発行順序も記憶する。次に、すでに検出済の障害かどうかを判断するために、リセット状態管理部は、待合せタイマがセットされているかどうかを判断（処理Ｓ２２０３）する。判断結果、待ち合わせタイマがセット済の場合、リセット状態管理部は、そのままＳ２２０１に戻る。一方、未セットの場合には、リセット状態管理部は、待合せタイマのセット（処理Ｓ２２０４）を実施した後、処理２２０１に戻り、監視を継続する。

図２３は、リセット制御装置のリセット制御部が、各系から受信したリセット要求から障害検出台数が一定量のリソースである系切替許容台数を満たしているかを判断して、
リセットを実施する処理の一例を示す。

まず、リセット制御部は、図１０の処理Ｓ１００１、Ｓ１００２と同様の処理Ｓ２３０１、Ｓ２３０２を、クラスタ状態管理表１３４、系切替許容台数定義１３６の代わりにリセット状態表４０３、系切替許容台数定義４０４を用いることで実施する。リセット制御部は、処理Ｓ２３０２において待合せタイマで設定された時間が経過した場合には、処理２１０６以降の処理の実行契機となるリセットタイムアウト通知Ｔ２３５１をリセット発行元に通知する（処理Ｓ２３０３）。リセット発行元が複数ある場合は、リセット制御部は、リセット状態表を参照し、からリセット発行順序が一番早いリセット発行元の系切替制御部２３８２に通知する。そして、リセット制御部は、処理Ｓ２１０８で、リセット強制発行指示Ｔ２３５２を受けたかを判断する（処理Ｓ２３０４）。リセット強制発行指示Ｔを受けた場合には、リセット制御部は、リセット発行処理Ｓ２３０５以降を実施する。一方、発行されていない場合には、リセット制御部は、処理Ｓ１００４における強制リセット指示待ちと同様に指示を待つために、処理Ｓ２３０４を繰り返す。

一方、処理Ｓ２３０１で障害検出台数が系切替許容台数以上である場合には、リセット制御部は、障害系のリセット装置２３８１にリセットＴ２３５３を発行して、リセット成功応答Ｔ２３５６を受信する処理Ｓ２３０５を実施する。続いて、リセット制御部は、リセット状態表を参照して、リセット状態表からリセット発行順序が一番早いリセット発行元の系状態制御部２３８２に、通知Ｔ２１５２又は通知Ｔ２１５４であるリセット成功通知Ｔ２３５５を通知する処理Ｓ２３０７を、リセット状態をクリア（処理Ｓ２３０６）した後に実施する。

図１７から図１９は、図２０ないし図２３のフローチャートを実行した際の第２の実施形態の処理概要を示す簡単な動作シーケンスを示す図であり、各図が対象とする障害は、第１の実施形態におけるシーケンス図７から図９にそれぞれ対応しており、各シーケンスの一部を変更して実施することで実現される。

図１７は、第２の実施形態における系切替許容条件を満たした場合に実行される動作を表すシーケンス図である。 処理１７１７ないし１７１９、１７３６及び１７３７は、図２２のフローチャートに対応する。処理１７２０、１７３８ないし１７４４は、図２３のフローチャートに対応する。処理１７１３、１７１４、１７４５、１７４６，１７４７および１７４８は、図２０のおよび図２１のフローチャートの一部に対応する。処理１７４９および１７５０は、図２０のフローチャートの一部に対応する。

まず、系Ａ５１００では、障害１７１１が発生すると、系Ｃ５３００は系Ａ５１００からの正常通知途絶１７１２を監視部１４３２が検出したことを契機に、系Ａ５１００の障害を検出し、処理１７１３を開始する。処理１７１３は、系切替制御部１４３３に系Ａ５１００の障害を通知する処理１７１４を含む。系切替制御部は、通知により、リセット装置に対して系Ａ５１００のリセットを要求する処理１７１６を含む処理１７１５を実施する。

リセット制御装置５４００では、リセット状態管理部４０１がリセット要求を受信すると、処理１７１７を実施する（図２２の処理）。処理１７１７では、リセット状態管理部は、リセット状態表を用いて、処理５１５、５１６と同様に、処理１７１８、１７１９を実施する。ここで、処理１７１８では、処理５１５と同様の障害検出台数以外に、系Ａ５１００へのリセット要求を発行した系と発行順序も記憶する処理を含む。次に、リセット制御装置５４００では、図５において系Ｃ５３００の系切替制御部１３３がクラスタ状態管理表１３４を用いて実施した処理５１７、５１８と同様に、処理１７２０、１７２１で、リセット制御部４０２がリセット状態表４０３を用いて、障害検出台数と待ち合わせタイマの２条件を判断する処理を行い、条件を満たさないため、処理が終了する（図２３のＳ２３０１及びＳ２３０２）。また、これらの処理も同様に、リセット制御部によって繰り返し実施される。

一方、系Ａ５１００の障害１７１１は、図５と同様に系Ｂ５２００でも同様に検出され、処理１７１２〜１７１８、及び１７２０と処理１７２１と同様に、それぞれ処理１７３１〜１７３７、及び処理１７３８、１７３９が行われる（図２３の各ステップに対応）。この一連の処理において、リセット制御装置５４００には処理１７１９によって、待合せタイマがセットされているため、待ち合わせタイマをセットする処理は行われない（図２２の各ステップに対応）。

処理１７３７で、リセット制御部は、系Ａ５１００の障害検出台数は「２台」となるため、判断処理１７３９で系切替許容台数以上であると判断され、障害となった系Ａ５１００のリセット装置にリセットを要求し（１７４０）、リセット装置が系Ａ５１００のリセット（１７４１）後にリセット成功を通知するのを受信する（１７４２、図２３のＳ２３０５）。処理１７４２の後、リセット制御部は、リセットが完了した系Ａ５１００の情報をクリアする処理１７４３を実施し、リセット状態表から、系Ａ５１００のリセット要求を最初に行った系である系Ｃ５３００へのリセット成功を通知する処理１７４４を行う。

系Ｃ５３００では、リセット要求処理１７１４に対する応答として、監視部は、リセット成功通知を受信すると、処理１７４５を実施する。処理１７４５では、他系の監視部に対して、系Ｃ５３００が系Ａ５１００のリセットを完了したことを通知し（１７４６）、系Ａ５１００の情報をクリアする処理１７４７を実行し、系切替処理１７４８を行う（図２１の各ステップ）。処理１７４５ないし１７４８は、図２１のＳ２１０３、Ｓ２１０５，Ｓ２１０９、Ｓ２１１０およびＳ２１１１の処理に対応している。

一方、系Ｂ５２００は、通知１７４６を受信したことを契機に、処理１７４５と同様に、系Ａ５１００の情報をクリアする処理１７５０を含む処理１７４９が実施される（図２１の各ステップ）。ここで、系切替処理１７４８は、処理５６１と同様に、他系である系Ｂ５２００と協調して動作するような系切替処理を含んでもよい。

以上、図１７に示す一連の処理により、ある系が障害の場合には、他系からリセットすることが可能であり、系切替処理を実現することができる。

図１８は、本発明の第２の実施形態における系切替許容条件を満たした場合に実行される動作を表すシーケンス図である。

まず、系Ｃ５３００及びリセット制御装置５４００では、図１８と同様に系Ａ５１００の障害検出を含む処理１７１１〜１７２０が行われる。一方、系Ａ５１００及び系Ｂ５２００は、図６同様に、正常稼動中であるため、処理１７１２〜１７２１、及び１７３１〜１７３９と同様に、処理１８３１〜１８４０、及び処理１８５１〜１８５９が行われる。これにより、処理１７１９によって系Ａ５１００に対する待合せタイマ時間が経過する前に、処理１８５９によって、系Ｃ５３００の障害検出台数が「２台」となり、リセット装置による系Ｃ５３００のリセット処理と、系Ｂ５２００、系Ａ５１００の処理を含む一連の処理１８６０〜１８７０が、処理１７４０〜１７５０と同様にして、実施される。ここで、系切替処理１８６８は、図６の系切替処理６７９と同様に、実行サーバを系Ｂ５２００に切り替える動作を行わない処理を含んでも良い。

以上、図１８に示す一連の処理により、系Ａ５１００と系Ｂ５２００が正常稼動している場合には、系Ｃ５３００が系Ａ５１００、系Ｂ５２００をリセットすることなく、系Ａ５１００、系Ｂ５２００から系Ｃ５３００をリセットすることが可能であり、性能低下を引き起こす系切替を防ぐことができる。

図１９は、本発明の第２の実施形態における系切替許容条件を満たさなかった場合に実行する処理の異なる一例を示すシーケンス図である。

まず、系Ｃ５３００では、図１７と同様に、系Ａ５１００の障害検出を含む処理１７１２〜１７２１が行われる。その後、図７と同様に、系Ａ５１００、系Ｂ５２００が障害であるため、系Ｃ５３００のリセット要求がリセット制御装置５４００によって受信されないことから、処理１７１９で設定された待合せタイマ時間が経過し（１９１１）、リセット制御装置５４００のリセット制御部は処理１９１２を実行する。

処理１９１２では、リセット状態表を参照することで、待合せタイマ時間の経過を検出し（１９１３）、系切替条件である系許容台数を障害検出台数が満たさなかったため、リセットが発行されずタイムアウトしたことをリセット要求の発行元である系Ｃ５３００の系切替制御部に対して通知する（１９１４）。通知を受けた系切替制御部は、処理７２４〜７２８と同様に、処理１９１５〜１９１９を実行する。また、一連の処理では、第１の実施形態で強制リセット定義１３７を利用する処理と同様に、リセット制御装置５４００の強制リセット定義４０５を利用する処理を含む。これにより、第１の実施形態と同様に、ユーザへの通知Ｉ／Ｆと指示Ｉ／Ｆを提供することができる。

系切替制御部は、強制リセット指示１９１９を受信すると、リセット装置に強制リセットを発行する（１９２０）。リセット制御装置５４００は、強制リセットを受信すると、１７４０〜１７４８と同様に、系Ａ５１００をリセットし系切替を行う処理１９２１〜１９２９を実施する。

以上、図１９に示す一連の処理により、リセットによる系切替が行われない場合をユーザが知ることの出来るＩ／Ｆが提供されるとともに、ユーザの指示によって、実行系サーバの系Ａ５１００が障害である場合には、障害による業務停止状態を継続させないように性能低下を引き起こしてでもリセットすることで系切替を行うことができる。

ここで、第２の実施形態におけるシーケンス及びフローチャートも、第１の実施形態と同様に、ある一つの系の障害を監視し、リセットする動作を中心に説明したが、他の系に対しても同様の処理を行うために、各部が同様の処理を並列実行していてもよく、その場合も適用可能である。
以上、図１４から図２３に示した第２の実施形態によれば、各計算機からのリセット発行を受信して、各計算機をリセットするリセット装置障害によって、系を検出している正常稼動中の系の台数を管理し、系切替許容台数を満たすかどうか判断し、リセットを実施するかを制御することを通じて各計算機の系切替を制御し、第１の実施形態と同様の効果を得ることが出来る。
＜第３の実施の形態＞
図２４から図２９は、本発明における第３の実施形態について表しており、第１の実施形態の一部を変更して実施することで実現される。

図２４は、第３の実施形態におけるクラスタシステムの構成を表すブロック図である。図１に示した第１の実施形態におけるブロック図の一部を変更したものである。

図２４の計算機は、以下に示す機能を有する。

まず、メモリ１０２上に仮想化機構１６１が格納され、プロセッサ１０１によって実行される。また、仮想計算機１５１、１５２は、仮想化機構によって、物理計算機１００のメモリ１０２やプロセッサ１０１や、ＮＩＣ１０３、１０４、１０５等のリソースが配分されることで、物理計算機と同等の機能を有することができる。これにより、仮想計算機それぞれで、上のメモリＤＢプログラム１２１、各プログラム、クラスタ管理コンソールは物理計算機上にある場合と同様に動作する。仮想化機構のリソース制御プログラム１６２は、設定値に基づいて、仮想計算機が使用するリソース使用量を決定するプログラムで、プロセッサ１０１が実行することによりリソース制御部が構成される。ここで、リソース制御部は、仮想計算機の生成・削除を行う。なお、設定値は、外部から指定することが可能であり、例えば、他の物理計算機からや、設定対象を含む仮想計算機から設定されてもよい。加えて、リソース制御部は、物理計算機のリソースが各仮想計算機にどのように使用されているかという情報を外部から参照することが可能である。また、同一物理計算機上の仮想計算機間の通信は、物理計算機のＮＩＣを介する必要がなく、例えば、仮想化機構を介したメモリ間のコピーにより実施されても良い。そのため、仮想計算機では、このような方法を実現する各装置の異常、例えば、仮想化機構やメモリの異常により、ＨＢ障害を検出する場合もある。
次にメモリ１０２は、図１の一部を変更したクラスタ状態管理表２４３４と、新たに系切替許容リソース定義２４３６、リソース量取得部２４３８、リソース状態表２４３９を有する。
クラスタ状態管理表２４３４は、図２５に示すように、クラスタ状態管理表１３４と同様の系識別子２０１、系状態２０２、障害検出台数２０３、待合せタイマ２０４に加えて、障害検出元識別子２５０１を有する。障害検出元識別子は、自計算機が認識している中において、系識別子で示される系を障害だと検出した系と、その順序情報が記憶され、例えば、図２５では検出順序順に表の先頭から格納される。
系切替許容リソース定義２４３６は、図２６に示すように、アプリケーションプログラムであるメモリＤＢプログラムが性能を維持して動作するために必要となるリソース量を示すリソース種別２６０１毎の許容リソース量２６０２が格納される。
リソース量取得プログラム２４３８は、クラスタ状態管理表に格納されたクラスタ構成の各系が存在する物理計算機上のリソース状態を、仮想化管理機構のリソース制御部を介して取得し、リソース状態表として格納するプログラムで、プロセッサ１０１が実行することにより、リソース量取得部を構成する。ここで、リソース状態の取得は、定期的に行われても良いし、あるいはリソース状態表を使用する際に行われても良い。

図２７は、リソース状態表を示す。図２７では、リソース状態表は、物理計算機識別子２７０１、系識別子２７０２、リソース量２７０３の欄で構成される。リソース量２７０３は、系切替許容リソース定義のリソース種別２６０１に指定される各リソース量を含む。例えば、図２５で指定されたプロセッサ１０１、メモリ１０２、ＮＩＣ１０３が使用する業務パス１１１に対応するリソースが格納される。ここで、図２７で示されるリソース量は、一例として、プロセッサの負荷量２７０４、メモリ量、ＮＩＣによるスループットを示しているが、違う指標を用いても良い。また、系識別子では、仮想計算機である各系の識別子の他に、仮想計算機で利用されていない未割り当てなリソース量を示すために「未割当」とする識別子を含んでも良く、この場合、リソース量２７０３には未割り当てなリソース量が格納される。

図２８、図２９は、監視部及び系切替制御部が行う処理を表すフローチャートであり、それぞれ、図９、図１０に示した第１の実施形態におけるフローチャートの一部を変更したものである。
図２８は、監視部が障害を監視し、監視結果に基づいて行う処理の一例を示すフローチャートである。

図２８では、監視部は、図９の処理Ｓ９０１〜Ｓ９１２と同様の処理Ｓ２８０１〜Ｓ２８１１を実行する。第１の実施形態との違いとしては、クラスタ状態管理表に追加された障害検出元識別子２５０１に関する処理があり、まず、処理Ｓ２８０６では、の障害検出台数をカウントする処理に加えて、通知Ｔ２８５１によって、障害検出を通知してきた系を障害検出元識別子２５０１に格納する。また、処理２８１１では、障害系の系状態のクリアとして、処理Ｓ９１１と同様の処理に加えて、障害検出元識別子のクリアも実施される。

次に、図２９は、系切替制御部が障害サーバの障害時に、一定量のリソースである系切替許容リソースを満たしているかを判断して、リセットを実施する処理の一例を示すフローチャートである。

図２９では、系切替制御部により、図１０の処理Ｓ１００１〜Ｓ１０１１と同様の処理Ｓ２９０１〜Ｓ２９１１が実施される。第１の実施形態との違いとしては、まず、処理Ｓ２９０２において、系切替制御部は、障害検出元識別子２５０１に格納された系で割当可能なリソース量を、リソース状態表２４２９を参照することで計算し、系切替許容リソース定義２４３６に指定された系切替許容リソース量以上であるかを判断する。ここで、割当可能なリソース量としては、障害検出元の系が使用するリソース量の値を利用してもよい。あるいは、障害検出元のリソース量に、障害系が障害検出元と同一の物理計算機上にある場合は、障害系のリソース量を加えても良いし、割当可能なリソース量として、障害検出元の系が稼動する物理計算機における未割り当てなリソース量を加えても良い。障害系のリセットによって解放されたリソースや未割り当てなリソースを、リソース制御部を介して障害検出元の系に追加する処理を、系切替処理Ｓ２９１２に含むことで、許容リソース量が保証される。
次に処理Ｓ１００６において、系切替制御部は、障害状態をクリアする処理は、処理Ｓ１００６に加えて、障害検出元識別子２５０１をクリアする処理を含む。
以上に、図２８、図２９に示すフローチャートによって、性能維持可能なリソース量を系切替先となる系で利用可能かどうかを判断し、リセットによる系切替制する機能が提供される。すなわち、障害系をリセットすることによって系切替を実現するクラスタシステムにおいて、障害系を検出している正常稼動中の計算機を管理し、各サーバのリソース量から、正常稼動中のサーバで実行系サーバが稼動した場合に、実行サーバが稼動するために必要となる一定量のリソースを満たすかどうかを判断してリセットを実施する。
なお、本実施形態では、系切替許容リソース量定義として、実行系サーバのリソース量を指定する例を示したが、複数の系のリソース量を指定してもよく、その場合には判断処理Ｓ２９０１では、複数の系のリソース量が系切替許容リソース量を満たすかどうかを判断することで、同様の機能を提供できる。

以上、図２４から図２９に示した第３の実施形態によれば、第１の実施形態における系切替許容台数によって行われていたリセット制御を、仮想計算機のリソース量によってリセットを制御することで、仮想計算機を含むクラスタシステムであっても、第１の実施形態と同様の効果を提供することができる。

なお、仮想計算機とリソース量を用いた第３の実施形態における、物理計算機と計算機台数を用いた第１の実施形態における処理の相違は、同様に第２の実施形態にも適用可能であり、これにより、第２の実施形態も仮想計算機とリソース量を用いて、第１の実施形態と同様の効果を提供することができる。

以上のように、クラスタ構成をとり、共有ディスクを構成しない、待機系サーバにデータを複製し、Ｉ／Ｏ処理性能が高いメモリ上で稼動するようなインメモリアプリケーションシステムに適用してもよい。特に、一定量のサーバ数やリソース量を保証することができるため、データを複数サーバのメモリ上に冗長化する高可用なインメモリアプリケーションシステムに適用し、性能劣化を引き起こす不要なリセットを伴う系切替を防止してもよい。 また、障害サーバをリセットすることによって系切替を実現するクラスタシステムにおいて、系切替後に必要となる一定量のリソースが満たされるかどうかを判断して、リセットを発行する構成により、性能劣化を引き起こす要なリセットを防止してもよい。

本発明の第１の実施形態におけるシステム構成図である。 本発明の第１の実施形態におけるクラスタ状態管理表の一例である。 本発明の第１の実施形態における系切替許容条件の一例である。 本発明の第１の実施形態におけるリセット発行タイミングに関するリセット定義の一例である。 本発明の第１の実施形態における系切替許容条件を満たした場合に実行する処理の一例を示すシーケンス図である。 本発明の第１の実施形態における系切替許容条件を満たさなかった場合に実行する処理の一例を示すシーケンス図である。 本発明の第１の実施形態における系切替許容条件を満たさなかった場合に実行する処理の異なる一例を示すシーケンス図である。 本発明の第１の実施形態におけるハートビート監視を行う処理の一例を示すフローチャートである。 本発明の第１の実施形態における障害の監視を行う処理の一例を示すフローチャートである。 本発明の第１の実施形態における障害検出時にリセットを行う処理の一例を示すフローチャートである。 本発明の第１の実施形態における系切替許容条件を満たさなかった場合のユーザインターフェースの一例である。 本発明の第１の実施形態における異なるシステム構成例を表すシステム構成図である。 本発明の第１の実施形態における系切替許容条件を満たさなかった場合のユーザインターフェースの異なる一例である。 本発明の第２の実施形態におけるシステム構成図である。 本発明の第２の実施形態におけるクラスタ状態管理表の一例である。 本発明の第２の実施形態におけるリセット状態表の一例である。 本発明の第２の実施形態における系切替許容条件を満たした場合に実行する処理の一例を示すシーケンス図である。 本発明の第２の実施形態における系切替許容条件を満たさなかった場合に実行する処理の一例を示すシーケンス図である。 本発明の第２の実施形態における系切替許容条件を満たさなかった場合に実行する処理の異なる一例を示すシーケンス図である。 本発明の第２の実施形態における障害の監視を行う処理の一例を示すフローチャートである。 本発明の第２の実施形態における障害検出時にリセット要求を行う処理の一例を示すフローチャートである。 本発明の第２の実施形態におけるリセット要求を受けたリセット装置がリセット状態を管理する処理の一例を示すフローチャートである。 本発明の第２の実施形態におけるリセット要求を受けたリセット装置がリセットを行う処理の一例を示すフローチャートである。 本発明の第３の実施形態におけるシステム構成図である。 本発明の第３の実施形態におけるクラスタ状態管理表の一例である。 本発明の第３の実施形態における系切替許容条件の一例である。 本発明の第３の実施形態におけるリソース状態表の一例である。 本発明の第３の実施形態における障害の監視を行う処理の一例を示すフローチャートである。 本発明の第３の実施形態における障害検出時にリセットを行う処理の一例を示すフローチャートである。

符号の説明

１００、２００、３００ 物理計算機
１０１ プロセッサ
１０２ メモリ
１０３ １０４、１０５ ＮＩＣ
１０６ リセット装置
１１１ 業務パス
１１２ 監視パス
１１３ リセットパス
１２１ メモリＤＢプログラム
１２３ クラスタ管理コンソール
１３１ ＨＢ送信プログラム
１３２ 監視プログラム
１３３ 系切替制御プログラム
１３４ クラスタ状態管理表
１３５ リセット定義
１３６ 系切替許容台数定義
１３９ リソース状態表
１４１ 入出力画面

Claims (15)

1. クラスタリングを構成する複数の計算機を含む計算機システムにおける系切り替え制御方法であって、
   前記複数の計算機のうち第一の計算機によって、第一の回線を介して第二の計算機を監視し、
   前記第一の計算機によって、前記第二の計算機の障害を検出し、
   前記第一の計算機によって、前記クラスタを構成する複数の計算機のうち他の計算機における前記第二の計算機に対する監視結果を含む通知を前記他の計算機から受け、
   前記検出した第二の計算機の障害に関する情報と、前記監視結果とを対応付け、
   前記対応付けが所定の条件を満たしているか否かを判断し、
   所定の条件を満たしている場合は、第二の計算機にリセット指示を第二の回線を介して行う、ことを特徴とする系切替制御方法。
2. 請求項1記載の系切替制御方法であって、
   前記所定の条件は、前記第一の計算機が受ける通知の数が、所定の数に達していることを特徴とする系切替制御方法。
3. 請求項２記載の系切替制御方法であって、
   前記所定の数は、前記クラスタ構成される計算機であって、かつ前記第一の計算機および前記第二の計算機以外の計算機の台数であることを特徴とする系切替制御方法。
4. 請求項２記載の系切替制御方法であって、
   前記第一の計算機が前記第二の計算機の障害を検出した場合は、前記対応付けは、前記監視結果の送り元の第二の計算機の数に１と足した数値であって、
   前記所定の条件は、前記数値が、前記クラスタ構成される計算機のうち、前記第二の計算機以外の計算機の数に達していることであることを特徴とする系切替制御方法。
5. 請求項１記載の系切替制御方法であって、
   前記監視結果は、一以上の前記他の計算機から受け、
   前記一以上の前記監視結果と前記検出した第二の計算機の障害に関する情報とが対応づいている場合、
   前記所定の条件は、前記監視結果の数が前記他の計算機の台数であることを特徴とする系切替制御方法。
6. 請求項1記載の系切替制御方法であって、
   前記第二の計算機は現用系の計算機であって、前記第1の計算機は前記現用系に対する待機系の計算機であって、前記リセットを送信後、前記第一の計算機によって系を切り替えることを特徴とする系切替制御方法。
7. 請求項１記載の系切替制御方法であって、
   あらかじめ定められた時間内で、前記所定の条件を満たした場合にリセット指示を行うことを特徴とする系切替制御方法。
8. 請求項７記載の系切替制御方法であって、
   前記あらかじめ定められた時間を経過した場合、前記リセット指示を行わなかったことを出力することを特徴とする系切替制御方法。
9. 請求項１記載の系切替制御方法であって、
   前記監視するステップは、
   前記第一の計算機によって、前記第二の計算機から第一の回線に送信されるハートビートを受信するか否かで判断し、
   前記障害を検出するステップは、前記第一の計算機の障害又は前記第一の回線の障害により、前記ハートビートを所定の時間内に受領するか否かで障害を検出する、ことを特徴とする系切替制御方法。
10. 計算機システムであって、
    クラスタリングにより構成される３以上の計算機を備え、いずれか一の計算機が、所定のアプリケーションを実行する現用系計算機で、他の計算機は、待機系計算機であって、
    前記計算機はそれぞれ、プロセッサと、前記プロセッサに接続されるメモリと、
    前記プロセッサに接続される第一のネットワークインタフェースと、
    第二のネットワークインタフェースと、を有し、
    前記計算機のうち、第一の計算機が備える前記プロセッサが、前記第一のネットワークインタフェースを介して、前記計算機のうち第二の計算機との通信の障害を検出した場合、前記プロセッサは、前記第二の計算機以外の計算機から、前記第二の計算機との通信の障害情報を前記第一のネットワークインタフェースを介して受信するか否かを判断し、前記障害情報を受信した場合、前記メモリに前記障害情報を格納し、
    前記メモリを参照し、前記障害情報をいくつの計算機から受信したか否かを算出し、
    算出結果、前記障害情報を所定の数の計算機から受信した場合は、前記第二の計算機に対してリセット要求を前記第二のネットワークインタフェースを介して発行する、ことを特徴とする計算機システム。
11. 請求項１０記載の計算機システムであって、
    前記プロセッサは、前記第二の計算機との通信の障害を検出した場合、他の計算機に前記第二の計算機との通信の障害を検出した旨の通知を前記第一のネットワークインタフェースを介して発行する、ことを特徴とする計算機システム。
12. 請求項１０記載の計算機システムであって、
    前記プロセッサは、前記第二の計算機との通信の障害を検出してから所定の時間が経過した場合、強制リセットを前記第二のネットワークインタフェースを介して前記第二の計算機に発行する、ことを特徴とする計算機システム。
13. 請求項１０記載の計算機システムであって、
    前記計算機は、前記プロセッサに接続される出力部を有し、
    前記出力部は、前記第二の計算機との通信の障害を検出してから所定の時間が経過した場合、リセット未発行である旨を示すメッセージを出力する、ことを特徴とする計算機システム。
14. クラスタリングを構成する複数の計算機にネットワークを介して接続されるリセット制御装置であって、
    前記ネットワークに接続されるネットワークインタフェースと、
    前記ネットワークに接続されるプロセッサと、
    前記プロセッサに接続されるメモリと、を備え、
    前記プロセッサは、前記ネットワークインタフェースを介して、いずれか一の計算機の通信障害に関する障害情報を受け、前記障害情報を前記メモリに格納し、前記メモリに格納された障害情報に基づいて、所定の数の計算機から受信したか否かを判断し、
    判断結果、所定の数の計算機から受信した場合は、障害が発生した計算機にリセットを、前記ネットワークインタフェースを介して発行することを、特徴とするリセット制御装置。
15. 請求項１４記載の計算機であって、
    所定の数は、クラスタ構成される計算機の台数から障害情報に関連する計算機の台数を減じた台数である、ことを特徴とするリセット制御装置。

Images