(57)【要約】【課題】クラスタ構成の高可用性コンピュータシステムにおいて、障害が発生したコンピュータをハートビート相互監視によりリセットする場合に、相互リセットもしくは重複リセットで生じる対処の遅延を回避して障害系リセットを高速に実施できるようにする。【解決手段】クラスタ内の各コンピュータ0110〜0140でそれぞれ発行する他系に対するリセット命令はリセット制御装置0190に送信され、リセット制御装置の制御モジュール0191では、新たに入力されたリセット命令が、バッファ0193記録された既に実行中のリセット命令と競合するか否かを判定し、判定の結果が競合しないとの結果であった場合にリセット命令をその発行先のコンピュータに送信し、かつ送信したリセット命令の情報を実行中のリセット命令を示す情報としてバッファ0193に記録する。【選択図】図１
2006285810.tif 000002
【特許請求の範囲】
【請求項１】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が前記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピューを含み、該複数のコンピュータが互いの状態を監視するためのハードビートパスと、互いに他をリセットするリセットパスと、リセット動作を制御するリセット制御装置とを有するクラスタ構成コンピュータシステムの系リセット方法であり、
前記複数のコンピュータのそれぞれが前記ハートビートパスを介した他のコンピュータの状態の監視により他のコンピュータをリセット対象とするリセット命令を発行するステップと、
リセット制御装置に新たに入力したリセット命令が、既に実行中のリセット命令と競合するか否かを判定するステップと、
前記判定するステップが競合しないとの結果であった時に、前記入力リセット命令を前記制御装置からその発行先のコンピュータに送信し、かつ送信したリセット命令の情報を実行中のリセット命令を示す情報としてバッファに記録するステップと、
前記送信したリセット命令によるリセット動作が完了したとき前記バッファから前記実行中のリセット命令を示す情報を削除するステップ、
を含むクラスタ構成コンピュータシステムの系リセット方法。
【請求項２】
前記判定するステップにて新たに入力されたリセット命令が実行中のリセッ命令と競合すると判定された時は、前記新たに入力されたリセット命令を前記リセット制御装置中に待機させ、所定の待ち時間が経過してから該待機させたリセット命令を再度前記の判定に供することを特徴とする請求項１に記載のクラスタ構成コンピュータシステムの系リセット方法。
【請求項３】
前記実行中のリセット命令によるリセット動作が完了したことを契機に、前記リセット制御装置中に待機しているリセット命令のうち、前記完了したリセット命令と競合するリセット命令の待機を中止するステップを更に有する請求項２に記載のクラスタ構成コンピュータシステムの系リセット方法。
【請求項４】
請求項１に記載のクラスタ構成コンピュータシステムの系リセット方法において、前記複数のコンピュータのそれぞれが所属するコンピュータのグループを前記リセット制御装置中に予め記憶するステップと、新たに入力されたリセット命令の発行元のコンピュータの所属するグループと発行先のコンピュータの所属するグループと比較し、両者が一致しない場合には該リセット命令の実行が不可であることを前記発行元に通知するステップを更に有することを特長とするクラスタ構成コンピュータシステムの系リセット方法。
【請求項５】
請求項１に記載のクラスタ構成コンピュータシステムの系リセット方法において、前記複数のコンピュータが他のコンピュータをリセットする優先度をそれぞれ前記リセット制御装置中に予め記憶するステップと、新たに入力されたリセット命令の発行元のコンピュータの優先度と発行先のコンピュータの優先度とを比較し、前者が後者より低い場合には該リセット命令の実行が不可であることを前記発行元に通知するステップを更に有することを特長とするクラスタ構成コンピュータシステムの系リセット方法。
【請求項６】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が前記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピューを含み、該複数のコンピュータが互いの状態を監視するためのハードビートパスと、互いに他をリセットするリセットパスと、リセット動作を制御するリセット制御装置とを有するクラスタ構成コンピュータシステムの系リセット方法であり、
前記複数のコンピューのそれぞれに、他のコンピュータをリセットする優先度を設定するステップと、
前記複数のコンピュータのそれぞれが前記ハートビートパスを介した他のコンピュータの状態の監視により他のコンピュータをリセット対象とするリセット命令を発行するステップと、
リセット制御装置に新たに入力したリセット命令の発行元の優先度と発行先の優先度を比較するステップと、
前記比較ステップで発行元の優先度が発行先の優先度より高い場合に、前記リセット命令を発行先のコンピュータに送信するステップと、
前記比較ステップで発行元の優先度が発行先の優先度より高くない場合に、前記リセット命令を前記リセット制御装置内に待機させ、所定の待ち時間が経過してから該待機させたリセット命令を前記発行先のコンピュータに送信するステップと、
前記送信したリセット命令によるリセット動作が完了したとき、前記リセット制御装置に待機しているリセット命令のうち前記リセット動作と競合するリセット命令を前記リセット制御装置から削除するステップ、
を含むクラスタ構成コンピュータシステムの系リセット方法。
【請求項７】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピューを含み、該複数のコンピュータが互いの状態を監視するためのハードビートパスと、互いに他をリセットするリセットパスと、リセット動作を制御するリセット制御装置とを有するクラスタ構成コンピュータシステムの系リセット方法であり、
前記複数のコンピューのそれぞれに、他のコンピュータをリセットする優先度を設定するステップと、
前記複数のコンピュータのそれぞれが前記ハートビートパスを介した他のコンピュータの状態の監視により他のコンピュータをリセット対象とするリセット命令を発行するステップと、
リセット制御装置に新たに入力したリセット命令の発行元の優先度と発行先の優先度を比較するステップと、
前記比較ステップで発行元の優先度が発行先の優先度より高い場合に、前記リセット命令と既に実行中のリセット命令が競合しないか判定し、競合しない時に前記リセット命令を発行先のコンピュータに送信するステップと、
前記判定で競合すると判明した時に前記リセット命令を前記リセット制御装置内に待機させ、所定の時間が経過してから該待機させたリセット命令を再び前記判定に供するステップと、
前記比較ステップで発行元の優先度が発行先の優先度より高くない場合に、前記リセット命令を前記リセット制御装置内に待機させ、所定の時間が経過してから該待機させたリセット命令を前記発行先のコンピュータに送信するステップと、
前記送信したリセット命令によるリセット動作が完了したとき、前記リセット制御装置に待機しているリセット命令のうち前記リセット動作と競合するリセット命令を前記リセット制御装置から削除するステップ、
を含むクラスタ構成コンピュータシステムの系リセット方法。
【請求項８】
前記比較ステップで発行元の優先度が発行先の優先度より高くない場合に、前記判定ステップの結果により待機させるリセット命令と区別するフラグを付した上で前記リセット命令を前記リセット制御装置内に待機させることを特徴とする請求項８記載のクラスタ構成コンピュータシステムの系リセット方法。
【請求項９】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピューを含み、該複数のコンピュータが互いの状態を監視するためのハードビートパスと、互いに他をリセットするリセットパスと、リセット動作を制御するリセット制御装置とを有するクラスタ構成コンピュータシステムの系リセット方法であり、
前記複数のコンピュータのそれぞれが所属するコンピュータのグループを前記リセット制御装置中に予め記憶するステップと、
前記複数のコンピュータのそれぞれが前記ハートビートパスを介した他のコンピュータの状態の監視により他のコンピュータをリセット対象とするリセット命令を発行するステップと、
発行されたリセット命令の発行元のコンピュータの所属するグループと発行先のコンピュータの所属するグループと比較し、両者が一致した場合は発行先のコンピュータに前記リセット命令を送信し、両者が一致しない場合には該リセット命令の実行が不可であることを前記発行元に通知するステップとを有することを特徴とするクラスタ構成コンピュータシステムの系リセット方法。
【請求項１０】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピューを含み、該複数のコンピュータが互いの状態を監視するためのハードビートパスと、互いに他をリセットするリセットパスと、リセット動作を制御するリセット制御装置とを有するクラスタ構成コンピュータシステムの系リセット方法であり、
前記複数のコンピュータが他のコンピュータをリセットする優先度をそれぞれ前記リセット制御装置中に予め記憶するステップと、
前記複数のコンピュータのそれぞれが前記ハートビートパスを介した他のコンピュータの状態の監視により他のコンピュータをリセット対象とするリセット命令を発行するステップと
発行されたリセット命令の発行元のコンピュータの優先度と発行先のコンピュータの優先度とを比較し、前者が後者より高い場合には該リセット命令を前記発行先のコンピュータに送信し、前者が後者より低い場合には該リセット命令の実行が不可であることを前記発行元に通知するステップとを有することを特徴とするクラスタ構成コンピュータシステムの系リセット方法。
【請求項１１】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系のコンピュータの処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピュータと、
該複数のコンピュータが互いの状態を監視するためのハードビートパスと、
前記複数のコンピュータがそれぞれ他のコンピュータに対して発行するリセット命令を入力して判定を加え、その結果にしたがってリセット命令をリセット対象のコンピュータに送出するリセット制御装置とを有し、
前記リセット制御装置の内部には、前記リセット対象のコンピュータに送出したリセット命令の情報を記録するバッファと、
前記バッファを管理し、入力するリセット命令と前記バッファに記録された情報とを比較して前記判定を行う制御モジュールとを備えることを特徴とするクラスタ構成コンピュータシステム。
【請求項１２】
前記制御モジュールは、リセット命令をそのリセット対象のコンピュータに送信するとき、少なくとも該リセット命令の発行先を前記実行中のリセット命令の情報として格納し、新規に入力したリセット命令の発行元もしくは発行先が前記実行中のリセット命令のいずれかの発行先と一致するとき、前記新規リセット命令が実行中のリセット命令と競合すると判定して前記新規リセット命令の送信を見合わせることを特徴とする請求項１１に記載のクラスタ構成コンピュータシステム。
【請求項１３】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系の処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピュータと、
該複数のコンピュータが互いの状態を監視するためのハードビートパスと、
前記複数のコンピュータがそれぞれ他のコンピュータに対して発行するリセット命令を入力して判定を加え、その結果にしたがってリセット命令をリセット対象のコンピュータに送出するリセット制御装置とを有し、
前記リセット制御装置の内部には、前記リセット対象のコンピュータに送出したリセット命令の情報を記録する第１のバッファと、
前記リセット対象のコンピュータに送出することを見合わせたリセット命令を待機させる第２のバッファと、
入力するリセット命令と前記バッファに記録された情報とを比較して前記判定を行ない、前記入力するリセット命令が実行中のリセット命令と競合すると判定したときには該リセット命令をリセット対象のコンピュータに送出することを見合わせて前記第２のバッファに待機させる制御モジュールとを備えることを特徴とするクラスタ構成コンピュータシステム。
【請求項１４】
前記第２のバッファには、送出することを見合わせたリセット命令の発行元および発行先と、そのリセット命令を待機させる待ち時間とが記録され、
前記制御モジュールは、リセット命令を待機させてから該リセット命令に対応して記録された待ち時間が経過すると、該リセット命令について前記競合の判定を再度行うことを特徴とする請求項１３記載のクラスタ構成コンピュータシステム。
【請求項１５】
あるアプリケーションの実行に関して少なくと一台が現用系のコンピュータとなり、残りうちの少なくとも一台が上記現用系の処理を引き継ぐべき待機系のコンピュータとなり得る複数台のコンピュータと、
該複数のコンピュータが互いの状態を監視するためのハードビートパスと、
前記複数のコンピュータがそれぞれ他のコンピュータに対して発行するリセット命令を入力して判定を加え、その結果にしたがってリセット命令をリセット対象のコンピュータに送出するリセット制御装置とを有し、
前記リセット制御装置の内部には、前記リセット対象のコンピュータに送出して実行中のリセット命令の情報と、前記複数の計算機がそれぞれ他の計算機を状態監視の結果によってリセットする優先度とを記録する第１のバッファと、
前記リセット対象のコンピュータに送出することを見合わせたリセット命令を待機させる第２のバッファと、
入力するリセット命令の発効元の優先度と発行先の優先度とを比較し、後者が前者より高い場合にはより高い優先度のコンピュータからのリセットを待つために該リセット命令を前記第２のバッファに待機させ、後者が前者より低い場合には更に実行中のリセット命令との競合を判定し、競合する場合には実行中のリセット命令の完了を待つために該リセット命令を前記第２のバッファに待機させ、競合しない場合には前記リセット対象のコンピュータに送出する制御モジュールとを備えることを特徴とするクラスタ構成コンピュータシステム。
【請求項１６】
前記リセット制御装置は、より高い優先度のコンピュータからのリセットを待つためにリセット命令を待機させる第１の待ち時間と、実行中のリセット命令の完了を待つためにリセット命令を待機させる第２の待ち時間とをそれぞれ独立に設定するインターフェースを有することを特徴とする請求項１５に記載のクラスタ構成コンピュータシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はアプリケーションシステムを構築する障害許容性のあるコンピュータシステムに関し、特にアプリケーションを実行中であるコンピュータのプログラムもしくはオペレーティングシステムに障害があった時に、その実行中のアプリケーションを別のコンピュータに引き継がせる系切替機能を有するプログラムと、そのプログラムからの系切替指示の優先度を制御する装置を持つコンピュータシステムに関する。
【背景技術】
【０００２】
高信頼性を必要とするコンピュータシステムでは、処理（アプリケーション）を実行する現用系コンピュータと、現用系に障害が発生した際に処理を引き継ぐ予備系コンピュータとを含む構成をとる。現用系で発生した障害の検出から予備系に処理を引き継ぐ手続きはクラスタプログラムによって提供される。さらに、アプリケーションがディスク上のデータを利用する場合には、ディスクは現用系と予備系との間で共有される構成をとる。現用系障害時に予備系が処理を引き継ぐためには、クラスタを構成するコンピュータから予備系となるコンピュータを決定することと、アプリケーションやオペレーティングシステム（OS）が使用している資源のうち、同時に利用することのできない資源（共有リソース）、例えば、共有ディスクやIPアドレスを引き継ぐことが必要となる。さらに、予備系が現用系の障害を監視するパスが遮断される障害（ネットワークスプリット）が生じた場合であっても、現用系と予備系が同時に共有リソースを利用しないように保証することが、さらなる高信頼性を実現するためには必要である。
【０００３】
クラスタ構成において、共有ディスクを排他的に引き継ぐことで、処理を引き継ぐ予備系を決定する方法が多くのクラスタプログラムで行われており、その例として、特許文献１がある。
特許文献１には、予備系から現用系を停止させるための機構を利用し、予備系のクラスタプログラムが現用系をリセットすることによって、現用系が所有する共有リソースを解放させ、予備系が解放された共有リソースを所有することで、共有リソースを排他制御する技術が記載される。
【０００４】
【特許文献１】特開平10−207855号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１では、クラスタ構成のコンピュータシステムにおいて、予備系は、現用系の監視が出来なくなった場合には、現用系を停止させることで、共有リソースの排他制御を実現している。しかし、お互いが相手の予備系であるような２台からなるクラスタにおいて、ネットワークスプリット時が生じた場合には、互いに相手の系をリセットしようとするため、全ての系がリセットされてしまう可能性がある。従って、ネットワークスプリット時には処理が中断してしまい、高可用性が実現できないというリセットの競合（相互リセット）問題がある。
【０００６】
また、予備系は現用系をリセットするが、現用系が予備系をリセットすることはない。従って、現用系とそれを引き継ぐ予備系2台（予備系1、予備系２）から構成されるクラスタを考えた場合、ネットワークスプリットにより、現用系と予備系１からなる２台のクラスタと、予備系２とに分離するようなケースにおいては、予備系２は、現用系をリセットし、系切替を行なう。一方で、予備系１も、予備系２により現用系がリセットされたことで、現用系の障害を検知し、系切替を実行してしまう。そのため、予備系１と予備系２が同時に現用系になり、共有リソースの二重アクセスが生じてしまったり、あるいは、最初のリセットにより障害系が回復処理を再度リセットしてしまい、障害系の回復を遅延させてしまったりする、別のリセットの競合（重複リセット）問題もある。
【０００７】
これらの競合リセット・重複リセットの問題は、リセットの発行を行なうクラスタプログラム間で同時にリセットを発行することがないように、リセット発行の順序性を保証することで解決される。しかし、この解決方法では、リセット発行の順序が最上位の系が障害になった場合には、次のリセット発行の優先度を有する系がリセットを行うまでに一定時間の遅延が発生してしまうため、系切り替え時間に遅延が生じてしまう問題があった。
【課題を解決するための手段】
【０００８】
本発明は、現用／待機系コンピュータを含む高可用性コンピュータシステムであって、現用／待機系が少なくとも一つのリソースを共有し、各コンピュータ間が互いの障害を監視するためのハートビートパスと、互いの系を停止させるためのリセットパスと、リセットパスに接続されたリセット制御装置を兼ね備えているコンピュータシステムにおいて、リセットの競合を防止し、高速な系切替を実現する機能を提供する。たとえば、共有されるリソースは、ディスク装置である。
【０００９】
本発明では、各コンピュータが他系をリセットするためのリセット命令の発行を制御するためのリセット制御装置を有する。リセット制御装置は、リセットの競合関係を判断する。たとえば、投入されたリセット命令とすでに実行中の別のリセット命令の送受信する系の関係がある。あるリセット命令の発行元が別のリセット命令によりリセットが実行中である場合には、リセット制御装置は、後発のリセット命令を防止する。このようにして、マシンがお互いの監視できない状況で、お互いにリセットを実行しあい、処理を引き継ぐマシンが不在になることを防ぐ。また、あるリセット命令の発行先が別のリセット命令によりリセットが実行中である場合には、リセット制御装置は、後発のリセット命令を防止する。このようにして、同じマシンに対して、リセットが複数回行われることを防ぐ。
【００１０】
リセットが防止されない場合は、障害系のリセットが行われ、障害系の動作を停止させ、共有リソースの使用を終了させる。この動作の停止処理は、たとえば、電源オフであったり、あるいは、ＯＳのシャットダウンであったりしてもよい。
また、リセット命令の送受信が可能なマシンをグループとすることで、異なるグループからの不正なリセット命令により誤ってリセットが行われることを防ぐ。
【００１１】
さらに、リセット制御装置がリセット命令を発行したマシンの優先度からリセット命令の発行順序を制御することでリセットの競合を防ぐ方法を用いても良い。ここで、マシンの優先度は、システム内で一意に定まる値を用いればよく、たとえばクラスタプログラムがリセット制御装置に教える値でも良いし、リセットパスに用いられるＮＩＣのＩＰアドレスを用いる方法であってもよい。
【００１２】
また、リセット制御装置が、リセットの競合が発生した場合に、競合を発生させた後発のリセットを競合が解消してから、再実行することで、先に実行中のリセットが失敗した場合にも、障害系のリセットを実現し、系切り替えを実現することができる。
このようにして、クラスタ構成のコンピュータシステムにおいて、リセット命令の制御を実現することで、リセットの競合を防止することができ、障害系の検知と同時に各コンピュータがリセットを実行することができるため、系切り替えが高速に実現される高可用性システムが実現される。
【発明の効果】
【００１３】
リセットの競合を生じることなく、リセットの発行を実現することにより、現用系コンピュータの障害を検出したクラスタプログラムがリセットを遅延なく発行しても、リセットされる系がただ一つだけとなるような系切替を実現することのできる高可用性コンピュータシステムを提供することができる。
【実施例１】
【００１４】
本発明の実施例に関する図と説明は、本発明を鮮明に理解するのに適当な要素を示すために簡単化されており、発明を実施するのに支障ない範囲で既知の要素等は省略していることを理解されたい。また実施例にかかわる技術の中には、本発明を実装するために他の要素が望ましく、かつ／または、必要とされると思われるものが幾つかある。しかし、技術中のこれらの要素は既知であり、本発明の理解を容易にするものではないので、ここでは説明しない。
【００１５】
図１は、実施例１の高可用性コンピュータシステムのシステムブロック図である。コンピュータ0110、0120、0130、及び0140はそれぞれクラスタプログラム0111、0112、0113及び0114を搭載する。これにより、そのいずれもが現用系コンピュータにも、他の系に対する予備系コンピュータにもなり得る。
【００１６】
コンピュータ0110(系Ａ)は、外部との通信を送受信する手段であるネットワークアダプタ（ＮＩＣ）0112、及び0113を備える。ＮＩＣ0112は監視パス0160（別名ハートビートパス）に接続される。より詳しく言えば、このＮＩＣ0112は、自系のクラスタプログラム（0111）が監視パス0160を介して他のコンピュータの障害を監視するため、また他のクラスタプログラムに自系の障害を通知するための通信に用いられる。他のコンピュータ0120、0130、及び0140にそれぞれ設けられたＮＩＣ0122、0132、0142も、全く同様の接続と用途をもつ。もう一つのＮＩＣ0113は、各コンピュータに共通に設けられたリセット制御装置0190へ接続するリセットパス0115に接続される。より詳しくは、ＮＩＣ0113は、自系のクラスタプログラム（0111）が他のいずれかのコンピュータの障害を検知してその障害発生系のリセット命令を発したとき、リセット制御装置0190にそのリセット命令を伝達するための通信に用いられる。ここで、ＮＩＣ0112と0113は理解のために別々にしたが、複数のポートをもつ単一のＮＩＣであっても良い。他のコンピュータ0120、0130、及び0140に同様それぞれ設けられたＮＩＣ0123、0133、0143も全く同様の接続と用途をもつ。
【００１７】
各系のコンピュータ0110、0120、0130、及び0140にそれぞれ設けられたリセット装置0114、0124、0134、0144は、リセットパス0115、0125、0135、0145をそれぞれ介してリセット制御装置0191からリセット信号を受けた時に自系を停止させる機能を持つ。具体的にはリセット装置は、電源を一時的に落とす、ＯＳ（オペレーティングシステム）を強制停止させること等で自系の停止する。クラスタプログラム0111、0121、0131、0141は、自系の状態を監視し、前記ＮＩＣ0112と前記監視パス0160を介して他系に通知する機能と、他系の状態を監視し、他系の障害発生時に他系をリセットする命令を発行する機能と、リセット完了後に障害系の処理を引き継ぐ系切り替え処理を実行する機能とをそれぞれ有する。クラスタプログラム0111、0121、0131、0141のより詳細な処理については、図３と図４を用いて後述する。
【００１８】
リセット制御装置0190には、リセット制御モジュール0191、入力リセット情報バッファ（ＩＢＣＲ）0192及び実行中リセット情報バッファ（ＩＢＥＲ）0193が備えられる。クラスタプログラム0111、0121、0131、0141が発行するリセット命令は、いずれもリセット制御装置の制御モジュール0191に伝達される。制御モジュール0191は、リセット命令の発行順序や、発行元の系の優先度、あるいはその系の所属グループ等に基づいてリセット命令の調停を行う。具体的には、既にリセットすべき対象のコンピュータのリセット装置へリセット信号が発行されて、リセット完了待ちであるリセット命令（実行中のリセット命令）との相互関係により、新規に入力したリセット命令によるリセット信号の発行を、実行したり、待機させたり、抑止したりといった制御を行う。入力リセット情報バッファ（ＩＢＣＲ）0192は、各系のクラスタプログラムから制御モジュール0191に入力されたリセット命令に関する情報を保持するバッファである。実行中リセット情報バッファ（ＩＢＥＲ）0193は、前記制御モジュール0191が各系のリセット装置へ発行されたリセット命令に関する情報を保持するバッファである。
【００１９】
図２は、前記２つのバッファの有する情報を示した図である。ＩＢＣＲ0192は、前記制御モジュール0191が新規に受信したリセット命令について、以下の二つの情報が格納される。
(1) 前記リセット命令を発行したクラスタプログラムの系を一意に定める識別子であるリセット送信元ＳｙｓｔｅｍＩＤ0201
(2) 前記リセット命令によってリセットされる系を一意に定める識別子であるリセット送信先ＳｙｓｔｅｍＩＤ0202
一方、ＩＢＥＲ0193は、リセット制御装置0190の制御下にある全ての系に対応するエントリをもつ表を格納する。
【００２０】
この表は、各エントリを一意に定めるＳｙｓｔｅｍＩＤが予め格納されるカラム0211と、当該エントリのＳｙｓｔｅｍＩＤが示す系を発行元とするリセット命令が制御モジュールから送出されることに対応して、そのリセット命令を一意に識別するリセットＩＤが格納されるカラム0212と、当該エントリのＳｙｓｔｅｍＩＤが示す系をリセット対象とするリセット命令が制御モジュールから送出されることに対応して、そのリセット命令を一意に識別するリセットＩＤが格納されるカラム0213とを有する。図２の例では、ＳｙｓｔｅｍＩＤがＢの系からＩＤ１と名付けられたリセット命令が発行され、ＳｙｓｔｅｍＩＤがＡの系に送出されて実行中であることを示す。
【００２１】
なお、これらのＳｙｓｔｅｍＩＤは、例えば、前記リセット命令に含まれる情報と同一であっても良いし、リセット制御装置0190内に変換テーブルを有し、その変換テーブルによって前記リセット命令に含まれる情報を変換した値であってもよい。また、本実施例において、同一の系を同一のＳｙｓｔｅｍＩＤで表しているが、同様に別のＳｙｓｔｅｍＩＤを変換した値であってもよい。さらに、本実施例では、理解を容易にするために、入力されたリセット命令を一つとしたが、複数のリセット命令を同時に処理してもよく、その場合は、前記ＩＢＣＲ0192は複数のリセット命令の情報を同様に保持する。
【００２２】
図３から図５は、本実施例におけるクラスタプログラムによる動作と、リセット制御装置の動作を表したフロー図である。
まず、図３は、クラスタプログラムにより各コンピュータが自系の状態を監視し、他系のクラスタプログラムに自系の状態を通知する動作フローを表した図である。
【００２３】
自系の監視は処理0301より開始する。処理0302ではコンピュータは一定時間が経過しているかどうかが判定し、一定時間が経過していない場合には、一定時間が経過するまで前記処理0302を繰り返す。一定時間が経過している場合には、自系か正常かどうかをチェックする(処理0303)。自系が正常である場合には、他のクラスタプログラム対して正常状態の通知0391を送信し(処理0304)、再び自系の監視処理(前記処理0301)に戻る。一方、自系が正常でない場合は、他系のクラスタプログラムに対して障害状態の通知0392を送信し（処理0305）、障害が発生した自系の停止を行なう。ここで、前記処理0305における自系の停止は、系間で共有リソースの排他制御を実現する処理であればよく、例えば、系切り替え制御の対象となるアプリケーションの停止や、コンピュータそのものの停止がある。
【００２４】
次に、図４は、クラスタプログラムが外部からの通信を受信した場合に、各コンピュータが障害発生を判定し系切り替えを行う動作フローを表した図である。
外部からの通信に対する処理は処理0401より開始する。コンピュータは、まず処理0402では、外部からの通知0491の受信を試みる。処理0403で外部通信元からの通知0491を受信したかを判断する。前記通知0491が届いていない場合は、他系の正常状態が一定時間途絶えて障害となるかを判断する(処理0404)。前記処理0404で障害であると判断した場合には、障害と判定された系に対してリセット命令0492の発行を行い(処理0405)、再び通知の受信処理0402に戻る。前記処理0404で障害でないと判断した場合には、そのまま通知の受信処理0402に戻る。
【００２５】
一方、前記処理0403において、前記通知0491を受信した場合には、コンピュータは前記通知0491の送信元が他系のクラスタプログラムであるか、自系のリセット制御装置0190であるかを判断する(処理0411)。前記処理0411において、他系のクラスタプログラムであった場合には、前記通知0491が障害状態の通知（図３にて説明した通知0392）であったかを判断する。障害である場合には、系切り替え処理(処理0423)を実行し、そうでない場合は、前記通知0491は正常状態の通知（図３にて説明した通知0391）であるため、何も行わず、再び通知の受信処理0402に戻る。
【００２６】
前記処理0411において、リセット制御装置であった場合には、他系から発せられたリセット命令の受付完了の応答（通知0593、後述）かどうかを判断する（処理0421）。受付完了の応答であった場合には、続いて到着するリセット完了の通知の受信のため、通知の受信処理0402に戻る。一方、処理0421において、受付完了の応答で無かった場合には、受付不可の応答（通知0592後述）であるかを判定する(処理0422)。受付不可であった場合には、リセット命令より他系リセット命令が優先されたことを示しているため、何もせずに、通知の受信処理0402に戻る。また、前記処理0422において、受付不可でもなかった場合には、前記リセット命令0492が完了した通知（通知0594、後述）であるため、系切り替え処理0423を実行する。
【００２７】
図５は、制御モジュール0191がバッファＩＢＣＲ0191、ＩＢＥＲ0192を用いて動作するフローを示した図である。
まず、制御モジュール0191は外部からの通信を受信する（処理0501）。次にモジュール0191は、その受信した通信が、クラスタプログラムがリセットパスを介して送信したリセット要求通知（図４のリセット命令0492）であるかを判断する（処理0502）。リセット要求通知であった場合には、処理0511を実行し、そうでない場合には処理0531を実行する。処理0511では、モジュール0191は送信元の系のＳｙｓｔｅｍＩＤ0201とリセット対象である系のＳｙｓｔｅｍＩＤ0202をバッファＩＢＣＲ0192に登録する。続いて処理0512では、前記リセット命令0492の発行元がすでに実行中の別のリセット命令の送信先となっているかどうかを判断する。具体的には、前記バッファＩＢＥＲ0193上の、リセット送信元ＳｙｓｔｅｍＩＤ0201の値に対応するエントリのカラム0213にリセットＩＤが登録されているかを確認する。リセットＩＤが登録されていれば、その新規リセット命令の送信元を対象とするリセットが既に実行中であり、登録されていないヌル（null）状態であれば、リセットは実行されていない。
【００２８】
処理0512で新規リセット命令0492のリセット送信元が既にリセット中である場合には、モジュール0191は、相互にリセットを掛け合うのを防ぐため、新規リセット命令0492の送信元のクラスタプログラムに対して、リセット不可の通知（通知0592）を行ない（処理0521）、前記ＩＢＣＲ0192に登録した前記ＳｙｓｔｅｍＩＤ0201、0202を削除し（処理522）、その後再び通信の受信処理（処理0501）に戻る。
【００２９】
一方、新規リセット命令0492のリセット送信元が実行中のリセット命令の送信先でない場合（処理0512がNoである場合）には、次にモジュール0191は、この新規リセット命令の送信先がすでに実行中の別のリセット命令の送信先であるかどうかを判断する（処理0513）。具体的には、新規リセット命令のリセット送信先ＳｙｓｔｅｍＩＤ0202に対応するＩＢＥＲ0193のエントリのカラム0213にリセットＩＤが登録されているか否かを確認する。処理0513でYesの場合、つまり新規リセット命令の送信先が既にリセット中である場合には、重複してリセットを行うのを防ぐため、モジュール0191はリセット不可の通知（処理0521）およびＩＢＣＲ0192からの新規リセット命令の削除（処理0522）を行なう。なお、処理0512でYesの場合には、処理0521の通知先の系に既に別のリセット命令が実行されているので、処理0521のリセット不可の通知は省絡しても良い。
【００３０】
処理0513でもＮoの場合には、新規リセット命令を実行可能であるため、まず前記ＩＢＣＲ0192からリセット送信元ＳｙｓｔｅｍＩＤ0201、とリセット送信先ＳｙｓｔｅｍＩＤ0202を削除する（処理0514）。次にモジュール0191は、新たなリセットＩＤを新規リセットに割り当て（処理0515）、その新たなリセットＩＤを、削除したリセット送信元ＳｙｓｔｅｍＩＤ0201に対応するＩＢＥＲ0192のエントリのカラム0212と、削除したリセット送信先ＳｙｓｔｅｍＩＤ0202に対応するＩＢＥＲ0192エントリのカラム0213の双方に登録する（処理0516）。その後モジュール0191は、削除したリセット送信先ＳｙｓｔｅｍＩＤ0202で特定される系のリセット装置にリセットパスを介してリセット命令を送信し（通知0594）、つまりその系のリセット実行を指示する（処理0517）。さらに、実行に移されたリセット命令の発行元であるリセット送信元ＳｙｓｔｅｍＩＤ0201で特定される系のクラスタプログラムに、リセットを実行したことを通知し（通知0593）、再び通信受信処理0501に戻る。なお、この通知0593は、先に図４を参照して述べたクラスタプログラムの動作フロー上ではクラスタプログラムの外部からの通知0491に相当する。つまりクラスタプログラムでは前述の処理0402が行なわれる。また、リセット制御装置0190からのリセット命令の送信（前記通知0594）を受けた系のリセット装置は、自系のコンピュータのリセットを実施した後、リセット完了通知をリセットパス(0115、0125、0135、0145)を介して、リセット制御装置0190に送信する。
【００３１】
処理0502で、リセット要求通知でない場合には制御モジュール0191はリセット装置からのリセット完了通知であるかを判断する（処理0531）。完了通知でない場合は、制御モジュール0191が処理する通知以外であるため、再び通信受信処理0501に戻る。一方、リセット完了通知であった場合には、前記バッファＩＢＥＲ0193のカラム0212とカラム0213から、完了したリセット命令のリセットＩＤを削除する（処理0532）。その後、そのリセットＩＤがカラム0213に書かれていたエントリに対応する系がリセットされたことをそれ以外の全系のクラスタプログラムに通知し（通知0595、処理0533）、再び通知受信処理0501に戻る。
【００３２】
以上に述べた実施例では、発行元と発行先が同時にリセットされること（相互リセット）を防ぐことができる。さらに、同一の系に対して複数のリセットが発行された場合において、リセットが完了した系を再度リセットし、再起動完了までの回復時間が増大すること（重複リセット）を防ぐことができる。さらに、クラスタプログラムが相互リセットや重複リセットを意識せずに、障害検知後に遅延なくリセットを行なうことが可能であり、高速で高信頼なクラスタシステムを実現することができる。
【実施例２】
【００３３】
図６、図７は、実施例２を示した図である。
本実施例では、リセット制御装置0190の制御モジュール0191で管理、使用する実行中リセット情報バッファＩＢＥＲ0193に格納される表の構成が先の実施例１と異なる。実施例２でＩＢＥＲ0193に保持される表を図６に示す。実施例１の表(図２参照)と共通のカラム0211、0212、0213に加えて、当該エントリに対応する系が所属するグループを表すＧｒｏｕｐＩＤを格納するカラム0601を有する。例えば、各クラスタプログラムが、リセットパスを介して自系ＧｒｏｕｐＩＤを制御モジュール0191に通知することで前記ＧｒｏｕｐＩＤをＩＢＥＲ0193に予め登録する。
【００３４】
本実施例では、ＧｒｏｕｐＩＤが同一、つまりそれぞれの系が同一のグループに所属する場合には、リセットをお互いに許可する。異なるグループに属する系同士のリセットは禁止する。図７はその動作を示すもので、先の実施例１の制御モジュールの動作フロー（図５）に挿入される追加処理ステップ0701のみを示す。制御モジュール0191は、新規リセット命令（通知0492）を受信後、処理0511でその新規リセット命令をＩＢＣＲへの登録すると、次に処理0701を実行する。処理0701では、ＩＢＥＲ0193のカラム0601を参照して、リセット送信元ＳｙｓｔｅｍＩＤ0201とリセット送信先ＳｙｓｔｅｍＩＤ0202のそれぞれの系のＧｒｏｕｐＩＤを比較する。それぞれのＧｒｏｕｐＩＤが同一でない場合には、リセットが許可されていないため、図６の処理0521のリセット不可通知以降の処理を行う。ＧｒｏｕｐＩＤが同一の場合には、リセットが可能であるため、処理0512以降の処理を継続する。
【００３５】
以上の述べた実施例２では、リセット命令の発行元と発行先が同一グループのときのみリセットを可能とする。これにより、クラスタプログラムが誤った動作をした場合や、悪意をもってクラスタ外部からリセット命令が送信された場合においても、誤って系がリセットされることを防止することができ、高信頼なクラスタシステムを実現することができる。
なお、ＧｒｏｕｐＩＤの導入によるの効果は、実施例１の特徴である既に実行中のリセット命令と競合の判定を行うか否かによらず得ることができる。つまり、上記した実施例２の動作フローに変えて、図７の処理0701でYesだった場合は図５の処理0514に移る動作フローを採用しても、ＧｒｏｕｐＩＤの導入による効果が得られる。
【実施例３】
【００３６】
図８、図９は実施例３を示した図である。
本実施例にて、ＩＢＥＲ0193内に格納して使用する表は図８に示す構造である。実施例１の表(図２参照)と共通のカラム0211、0212、0213に加えてＳｙｓｔｅｍ優先度を格納するカラム0801を有する。前記Ｓｙｓｔｅｍ優先度は、対応する系が発行するリセット命令の優先度を表す識別子であり、優先度が高い系は優先度の低い系のからのリセットを禁止する特長を有する。前記Ｓｙｓｔｅｍ優先度は、例えば、クラスタプログラムがリセットパスを介して、リセット制御装置に通知することで登録可能である。
【００３７】
図９は、実施例３の制御モジュールの動作フローのうち、実施例１の制御モジュールの動作フロー（図５）に挿入される追加処理ステップ0901のみを示す。制御モジュール0191は、新規リセット命令（前記通知0492）を受信後、処理0511でその新規リセット命令をＩＢＣＲへの登録すると、次に処理0901を実行する。処理0901では、ＩＢＥＲ0193のカラム0801を参照して、リセット送信元ＳｙｓｔｅｍＩＤ0201とリセット送信先ＳｙｓｔｅｍＩＤ0202のそれぞれの系のＳｙｓｔｅｍ優先度を比較する。ＳｙｓｔｅｍＩＤ0201の系がＳｙｓｔｅｍＩＤ0202の系よりもＳｙｓｔｅｍ優先度が低い場合には、リセット不可通知（処理0521）以降の処理を行い、優先度が高い場合には、リセットが可能であるため、処理0512以降の処理を継続する。
【００３８】
本実施例では、重要な処理を行なう系の優先度を高くして優先度の低い他の系からリセットされることを防ぐことが可能となり、高信頼なクラスタシステムが得られる。
Ｓｙｓｔｅｍ優先度の導入により得られる上記の効果は、実施例１の特徴である既に実行中のリセット命令と競合の判定を行うか否かによらず得ることができる。つまり、上記した実施例３の動作フローに変えて、図９の処理0901でYesだった場合は図５の処理0514に移る動作フローを採用することも有効である。
【実施例４】
【００３９】
図１０、図１１、図１２はリセット不可であることをクラスタプログラムに通知する代わりに、リセット制御装置内でリセット命令の再実行を制御するようにした第４の実施例を示す。
まず、図１０は、本実施例のリセット制御装置0190'の構成を示す。このリセット制御装置0190'は、実施例１のリセット制御装置0190(図２)に対し待機中リセット情報バッファ（ＩＢＷＲ）1001を更に有する点が異なる。待機中リセット情報バッファＩＢＷＲ1001は、各系のリセット装置への発行を待機させた各リセット命令に関して、下記３つの情報を保持する。
(1)  待機中のリセット命令を発行したクラスタプログラムの系を一意に定める識別子であるリセット送信元ＳｙｓｔｅｍＩＤ1011
(2)  待機中のリセット命令がリセットする系を一意に定める識別子であるリセット送信先ＳｙｓｔｅｍＩＤ1012
(3)  待機中のリセット命令が発行を待つ時間を定める待ち時間1013
図１１、図１２は、本実施例のリセット制御装置0190'の制御モジュール0191の動作フローを示す。
【００４０】
まず、図１１は、ＩＢＷＲにリセット命令を待機させ、再発行する動作フローが付加されたことによる図５からの変更部分を表す。制御モジュール0191は、処理0511で新規リセット命令をＩＢＣＲ0192に登録すると、次に処理0701でそのリセット命令の発行元と発行先とが同一グループに属すかを判定する。このステップは第２実施例と同様であり、それぞれの系が同一グループでなければ図５の処理0521に進んでリセット不可を発行元のクラスタプログラム通知する。それぞれの系が同一グループであれば、処理0512、処理0513に進む。処理0512で、新規リセット命令0492の発行元が既に実行中のリセットの対象であると判定された場合、あるいは処理0513で新規リセット命令の発行先が実行中のリセットの対象であると判断された場合には、処理0521のリセット不可の通知ではなく、処理1101を実行する。処理1101では、ＩＢＷＲ1001内に、新たに格納する待機リセット命令の待ち時間1013を設定する。
【００４１】
具体的には、新規なリセット命令と相互リセットあるいは重複リセットの関係となる実行中のリセット（存在するとしたら）が完了するに充分な遅延時間を予めリセット制御装置に設定しておき、処理1101ではその遅延時間を待ち時間1013として、ＩＢＷＲ1001に設定する。続いて処理1102ではＩＢＣＲ0192から新規リセット命令0492を削除する。その後処理1103でＩＢＮＷＲ1001で削除したリセット命令を待機中リセット命令として登録する。具体的にはは前記ＩＢＣＲ0192に格納されていたＳｙｓｔｅｍＩＤ0201、0202をそれぞれ待機中リセット命令のリセット送信元ＳｙｓｔｅｍＩＤ1011、リセット送信先ＳｙｓｔｅｍＩＤ1012として格納する。処理1104では前記待ち時間1013が経過したかどうかを判定し、経過していなければ待ち続ける（処理1104）。一方、前記待ち時間1013が経過していれば、前記ＩＢＷＲ1001から、待ち時間が終了したリセット命令を削除し（処理1105）、前記処理1105で削除したリセット命令を再度実行するため処理0511（図５）にもどる。つまり待機させていたリセット命令を再び新規リセット命令として前記ＩＢＣＲ0192に登録し、以上に述べた処理を繰り返す。
【００４２】
本実施例では、完了したリセット命令が待機中のリセット命令の発行元や発行先をリセットする場合が生じる。この場合には、待機させたリセット命令を再び呼び出す必要はなくなる。図１２は、このような理由で必要となる追加処理ステップを示す。制御モジュール0191が、リセット完了通知を受信し、ステップ0532（図５）でそのリセット命令のリセットＩＤをＩＢＥＲから削除した後、追加処理ステップ1201が実行される。処理1201では、前記ＩＢＥＲにおいて削除されたリセットＩＤがカラム0213に格納されていたエントリのＳｙｓｔｅｍＩＤ（リセットされた系のＳｙｓｔｅｍＩＤ）と同じ値をＳｙｓｔｅｍＩＤ1012またはＳｙｓｔｅｍＩＤ1013に持つリセット命令をＩＢＷＲ1001から削除する。その後、通常のリセット命令の実行完了フロー（処理0533）へと戻る。
【００４３】
また、以上の実施例４を変形し、実施例３で採用したＳｙｓｔｅｍ優先度によるリセット可否の判定を同時に採用してもよい。その場合は、たとえば、図１１の処理0701を処理0511の後ではなく、処理0901（図９）の後に実行する。
【００４４】
実施例４では、新規リセット命令と競合するリセット命令が既に実行段階に入っている時には、リセット不可を発行元に返すのでなく、その新規リセット命令を待機させた後に再び判定する。つまり、上記の競合するリセット命令の実行が失敗に終わった時には、即座に待機させたリセット命令による障害系のリセットが行われる。したがって、より高信頼なクラスタシステムを実現することができる。
【実施例５】
【００４５】
図１３及び図１４は、Ｓｙｓｔｅｍ優先度が低い系から高い系へのリセットを不可とするのでなく、そのようなリセット命令を入力したら、Ｓｙｓｔｅｍ優先度が高い別の系からのリセットがなされるのに充分な待機時間が経過するまでそのリセット命令を待機させる実施例５を示す。
【００４６】
実施例５はＳｙｓｔｅｍ優先度を利用するため、実行中リセット情報バッファＩＢＥＲに格納する表は実施例３と同様であり、図８に示す構造となる。リセット命令の待機も行うので、図１０に示すリセット制御装置0190'を用いる。
実施例５で用いられる新規リセット情報バッファＩＢＣＲ0192、待機中リセット情報バッファＩＢＷＲ1001にそれぞれ格納する情報は図１３に示すとおりとなる。ＩＢＣＲ0192には入力したリセット命令の送信元ＳｙｓｔｅｍＩＤ0201、送信先ＳｙｓｔｅｍＩＤ0202に加えて、優先度が高いリセットを待つための待機が行われたリセット命令であるか否かを示す優先度待ちフラグ130１が記録される。またＩＢＷＲ1001の待機中のリセット命令の各々についても、図１０で説明した情報に加えて上記と同様の優先度待ちフラグ1302が記録される。
【００４７】
図１４は本実施例における制御モジュール0191の動作フローを表している。ただし図１４には図５に示す動作フローからの変更部分を表す。さらに本実施例の動作フローは図１１、図１２で説明した変更部分もそのまま含む。
【００４８】
制御モジュール0191は、新規リセット命令を受信した等により処理0511（図５）でリセット命令をＩＢＣＲ0192に格納する。次に図１４の処理0901に進み、制御モジュール0191は、そのリセット命令の発行元の優先度を発行先の優先度とを比較する。その具体的な方法は、図９を参照した実施例３の説明で述べた通りである。発行先の優先度の方が高かった場合に、処理1401を実行する。処理1401ではＩＢＣＲ0192の優先度フラグ1301がセットされているかどうかを判断する。ＩＢＣＲ0192の優先度待ちフラグ1301がセットされていない場合は、そのリセット命令は、より優先度が高い別の系からのリセットを待つため待機（優先度待ち）に初めて入ることになるため、ＩＢＣＲ1001に優先度フラグ1301を設定する（処理1402）。
【００４９】
次に処理1403では、ＩＢＷＲ1001に新たに格納するリセット命令の待ち時間1013（図１３）を設定する。具体的には、低い優先度の系からのリセット命令でリセット要とされた系が、より高い優先度の別の系からのリセットを受けるのに充分な遅延時間を予めリセット制御装置内に設定しておく。処理1403ではその遅延時間を今からＩＢＷＲ1001に格納するリセット命令の待ち時間1013（図１３）としてＩＢＷＲ1001に設定する。次に処理1404でＩＢＣＲ0192からリセット命令を削除し、処理1405でその削除したリセット命令をＩＢＷＲ1001に格納する。ＩＢＣＲ0192内の優先度待ちフラグ1301がセットされていたので、格納したリセット命令に対応する優先度待ちフラグ1302もセットされる。待ち時間の経過の確認（処理1406）の後に、待機させた上記リセット命令をＩＢＷＲ1001から削除し（処理1407）、そのリセット命令を再判定するため処理0511にもどる。このとき、ＩＢＷＲ1001に登録されていた優先度待ちフラグ1302の値もそのままＩＢＣＲ0192に反映するので、再判定のためＩＢＣＲ0192に戻されたリセット命令の優先度待ちフラグ1301はセットされた状態（済）となる。
【００５０】
処理1401でＩＢＣＲ0192の優先度待ちフラグ1301がセットされている場合は、処理0512（図１１）に進む。すなわち、リセット命令の発行元の系の優先度が発行先の系より高いという条件に合致しないためにリセット制御装置内に待機させられたリセット命令が、再び実行判定に供された時は、より優先度が高い系からリセットを待つための待機を再び繰り返すのではなく、リセット実行のための処理に回される。処理0901で、判定しようとする新規リセット命令の発効元の優先度の方が発行先の優先度より高い場合にも、そのまま処理0512に進み、実施例３と同様なリセット処理が行われる。
【００５１】
処理0512からは図１２のフローに従うので、実施例１で述べた相互リセット、重複リセットの判定（リセット競合判定）は本実施例５でも実行され、さらにそれらの判定が「競合あり」だったとき、図１１の処理1101以降に進む。つまり実施例３と同様に、リセット競合判定の結果でリセット命令がＩＢＷＲ内に待機させられる。したがって本実施例５では、ＩＢＷＲ1001内に待機しているリセット命令には、先に説明した優先度が高いリセットを待つために待機するリセット命令と、競合リセットを避けるために待機するリセット命令の２種類が有る。後者については優先度待ちフラグ1302がセットされない。すなわち本実施例で導入したこの優先度待ちフラグは上記２種類の待機リセット命令を識別する機能を持つ。
【００５２】
さらに、実施例５のリセット制御モジュール0191の動作フローは、図１２に示した追加処理ステップ1201を含む。すなわちリセット対象の系のリセット制御装置にリセット命令が送出され、これによりリセット完了が通知された場合には、図５の処理0532に引き続き、図１２の処理1201が実行される。つまリ、ＩＢＷＲ1001内に待機させられるリセット命令の内、リセットが完了した系が発行先か、もしくは発行元であるリセット命令（完了したリセット動作と競合するリセット命令）はＩＢＷＲ1001から削除される。
【００５３】
以上に述べた実施例５では、系の優先度に即したリセット可否判定がなされるとともに、優先度が低い系から高い系へのリセット命令は、充分な待機時間の待機に入れられ、その待機時間を経てもその間に逆方向のリセットが実行されずに残されていれば、実行に移される。したがってクラスタ構成のシステム間で高信頼かつ確実なリセットおよび系切替が行われる。
【００５４】
以上の実施例では、リセット制御装置が一つであるクラスタ構成のコンピュータシステムについて説明をしたが、複数のリセット制御装置を備えたクラスタ構成のシステムでも同様に実施できる。その場合は、各リセット制御装置のバッファをリセット制御装置間で同期することで本発明を実現することができる。
【００５５】
さらに、リセット制御モジュールは、リセット制御装置の上のモジュールであるとしたが、計算機で稼動するプログラムであってもよい。その場合は、リセット制御装置はクラスタ構成コンピュータシステムの一つの計算機となる。ブレード型計算機では、リセット制御装置は、ブレード型計算機の筐体内部にあってもよく、例えば、ブレード型計算機の筐体を管理する管理プロセッサである。
【産業上の利用可能性】
【００５６】
本発明では、クラスタシステムの系相互でリセット発行に要する時間を調整することによらずに、競合リセットおよび重複リセットを防止できる。したがって高速リセット、高速の系切替が可能となり、障害発生時にもサービスを継続し得る高可用性のクラスタコンピュータシステムに有効に利用されることが見込まれる。
【図面の簡単な説明】
【００５７】
【図１】本発明の第１の実施例において、系切替が行なわれる場合におけるクラスタ構成のコンピュータシステムモデルの高位のシステムブロック図である。
【図２】本発明の第１の実施例において、系切替制御装置内のリセット情報バッファの構成を示した図である。
【図３】本発明の第１の実施例において、クラスタプログラムが自系の状態を送信する処理を説明した処理フロー図である。
【図４】本発明の第１の実施例において、クラスタプログラムが受信した通信内容を元に実行する処理を説明した処理フロー図である。
【図５】本発明の第１の実施例において、リセット制御装置が実行する処理を説明した処理フロー図である。
【図６】本発明の第２の実施例において、リセット制御装置内のリセット情報バッファの構成を示した図である。
【図７】本発明の第２の実施例において、リセット制御装置が実行する処理を説明した処理フロー図である。
【図８】本発明の第３の実施例において、リセット制御装置内のリセット情報バッファの構成を示した図である。
【図９】本発明の第３の実施例において、リセット制御装置が実行する処理を説明した処理フロー図である。
【図１０】本発明の第４の実施例において、リセット制御装置内のリセット情報バッファの構成を示した図である。
【図１１】本発明の第４の実施例において、リセット制御装置が実行する処理を説明した処理フロー図である。
【図１２】本発明の第４の実施例において、リセットされた系が発行した待機中のリセット命令を削除する処理を説明した処理フロー図である。
【図１３】本発明の第５の実施例において、リセットされた系が発行した待機中のリセット命令を削除する処理を説明した処理フロー図である。
【図１４】本発明の第５の実施例において、リセット制御装置が実行する処理を説明した処理フロー図である。
【符号の説明】
【００５８】
0110、0120．0130、0140：コンピュータ
0111、0121、0131、0141：クラスタプログラム
0112、0113、0122、0123、0132、0133、0142、0143：ネットワークアダプタ（ＮＩＣ）
0190：リセット制御装置
0191：制御モジュール
0192：入力リセット情報バッファ
0193：実行中リセット情報バッファ。
【図１】
2006285810.tif 000003
【図２】
2006285810.tif 000004
【図３】
2006285810.tif 000005
【図４】
2006285810.tif 000006
【図５】
2006285810.tif 000007
【図６】
2006285810.tif 000008
【図７】
2006285810.tif 000009
【図８】
2006285810.tif 000010
【図９】
2006285810.tif 000011
【図１０】
2006285810.tif 000012
【図１１】
2006285810.tif 000013
【図１２】
2006285810.tif 000014
【図１３】
2006285810.tif 000015
【図１４】
2006285810.tif 000016