JP6424134B2

JP6424134B2 - 計算機システム及び計算機システムの制御方法

Info

Publication number: JP6424134B2
Application number: JP2015088221A
Authority: JP
Inventors: 英宏河合; 晃尾田; 博史峯
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2015-04-23
Filing date: 2015-04-23
Publication date: 2018-11-14
Anticipated expiration: 2035-04-23
Also published as: JP2016206965A

Description

本発明は、計算機システムの多重系制御方法に関する。

多重系の計算機システムは、業務を実行する現用系計算機と、現用系計算機を監視して異常を検知したときにその業務を引き継ぐ待機系計算機から構成される。この現用系計算機で異常が発生したときに、待機系計算機が業務を引き継ぐ一連の処理をフェイルオーバ(もしくは系切り替え)と呼ぶ。

フェイルオーバについては、次の３点が求められる。第一に、異常が発生した原因の解析を支援する目的で、異常を起こした現用系計算機のメモリダンプを採取する。第２に、異常を起こした現用系計算機が不適切なデータ出力を行わないように、待機系計算機が業務を引き継ぐ前に現用系計算機の業務を完全に停止させる、あるいは現用系計算機が停止したことを確認する。第三に、フェイルオーバ中の業務停止時間を短くするために、前記現用系計算機の業務停止を極力早いタイミングで実施する。

近年のオペレーティングシステム（以下ＯＳ）は、自身で異常を検知した場合、あるいはマスク不可割込み（ＮＭＩ＝Non Maskable Interrupt）を受信した場合、その時点での第一のＯＳのメモリ内容を保持したまま第２のＯＳを起動し、第２のＯＳがメモリダンプとして第一のＯＳのメモリ内容を永続的に保存する。

特に多重系システムにおいては、現用系計算機の異常を検知した待機系計算機が、公知または周知の手法で現用系計算機にＮＭＩを入力することで、現用系計算機の業務停止と、メモリダンプ処理の開始を同時に実現する。

しかし、現用系計算機のＯＳが既にメモリダンプ処理を開始している場合、前記手順に従って待機系計算機が現用系計算機にＮＭＩを入力すると、メモリダンプ処理が停止してしまい、メモリダンプに失敗することがある。

メモリダンプ処理を開始した後のＮＭＩ入力を抑止する方法として、特許文献１には、「障害の発生した計算機に搭載された機能拡張ボードが割込み指示メッセージに対して発生する割込みに対する割込み処理において、障害情報の保存を実行し、かつ前記機能拡張ボードに対して、前記割込み発生機能と計算機動作停止機能の抑止を指示し、後から送信される計算機の停止を指示するメッセージを無視して障害情報の保存を継続する」技術が開示されている。

国際公開第９９／２６１３８号

しかしながら、上記特許文献１では、上述した機能を有する機能拡張ボードを必要とするが、このような特別なハードウェアは広く一般に普及しておらず、様々な地域で、かつ安価に入手することは難しい。さらに、標準的なＯＳは、当該特別なハードウェアを利用するためのデバイスドライバをサポートしているとは限らない。

そこで本発明は、上記問題点に鑑みてなされたもので、特別なハードウェアを必要とせずに現用系計算機に異常が発生した時に、メモリダンプが強制的に停止されるのを抑止することを目的とする。

本発明は、プロセッサとメモリとを有する計算機を複数有し、前記複数の計算機のうち少なくとも一つを現用系計算機とし、他の計算機のうち少なくとも一つを待機系計算機とし、前記現用系計算機と前記待機系計算機を接続する第１のネットワークとを有する計算機システムであって、前記現用系計算機は、当該現用系計算機に接続されて、当該現用系計算機を管理する計算機管理装置と、業務を提供する第１のＯＳと、前記第１のＯＳが稼働中であることを示すハートビートを所定の周期で前記待機系計算機へ送信する通信部と、前記第１のＯＳに障害が発生した後に前記メモリの内容を出力する第２のＯＳと、を有し、前記計算機管理装置は、第２の所定時間までカウントすると所定のアクションを実行するウォッチドッグタイマと、前記ウォッチドッグタイマの稼働状態を設定するタイマ設定状態情報と、第２のネットワークを介して前記待機系計算機に接続されたアダプタと、を有し、前記現用系計算機は、前記業務の開始時に前記計算機管理装置の前記タイマ設定状態情報に前記業務の開始を示す有効状態を設定し、前記アクションとして当該現用系計算機のハードリセットを設定し、前記現用系計算機のプロセッサは、前記第１のＯＳが障害により停止したときには、前記ウォッチドッグタイマのカウントを開始させる開始コマンドを前記計算機管理装置に送信してから前記第２のＯＳを起動し、前記計算機管理装置は、前記開始コマンドを受信して前記タイマ設定状態情報を開始状態に更新し、前記待機系計算機は、前記ハートビートを受信してから第１の所定時間が経過した後に、前記タイマ設定状態情報を取得し、前記タイマ設定状態情報が前記開始状態であれば、前記第１のＯＳが停止したと判定して前記現用系計算機の業務を引き継ぎ、前記現用系計算機の前記第２のＯＳは、第３の所定時間毎に前記ウォッチドッグタイマをリセットし、前記計算機管理装置は、前記第２の所定時間までカウントした場合には前記所定のアクションとして設定された前記ハードリセットを前記現用系計算機へ入力する。

本発明によれば、特別なハードウェアを必要とせずに、現用系計算機に異常が発生したときには第２のＯＳによるメモリダンプが強制的に停止されてしまうことを抑止できる。また、待機系計算機は、異常の発生によって停止した現用系計算機が第２のＯＳに移行するタイミングで現用系計算機の第１のＯＳの停止を検知できる。これにより、現用系計算機の異常による停止から短時間で待機系計算機に業務を引き継がせることができる。さらに、現用系計算機及び待機系計算機では、ＯＳの改造や特殊なドライバは不要なため、汎用ＯＳを利用することができる。

本発明の第１の実施例を示し、多重系の計算機システムの一例を示すブロック図である。本発明の第１の実施例を示し、現用系計算機が自発的に停止するケースのタイムチャートである。本発明の第１の実施例を示し、現用系計算機が待機系計算機からの指示により停止するケースのタイムチャートである。本発明の第２の実施例を示し本発明の第２の実施例を示し、メモリダンプ処理用の第２のＯＳがハングアップした場合に、自動的に第１のＯＳを再起動させる処理の一例を示すタイムチャートである。本発明の第１及び第２の実施例を示し、ウォッチドッグタイマの状態遷移図である。

以下、本発明の実施形態を添付図面に基づいて説明する。

図１は、本発明の第１の実施例を示し、多重系の計算機システムの一例を示すブロック図である。多重系の計算機システムは、複数の計算機のうち少なくとも１台の現用系計算機１０と、現用系計算機１０を管理する現用系ＢＭＣ（Baseboard Management Controller）６と、少なくとも１台の待機系計算機２０と、待機系計算機２０を管理する待機系ＢＭＣ７と、現用系計算機１０と待機系計算機２０を接続するネットワーク３２と、現用系計算機１０と待機系ＢＭＣ７を接続し、待機系計算機２０と現用系ＢＭＣ６を接続するネットワーク３１から構成される。

現用系計算機１０と待機系計算機２０は同様に構成され、少なくとも、後述するようにＯＳを含むソフトウェアプログラムを実行する演算装置１１と、前記プログラムおよびその実行に必要なデータを格納するメモリ１２と、ハートビート（以下、ＨＢ）通信を行う通信装置１３と、他系ＢＭＣにコマンドを送信するためのＬＡＮアダプタ１４と、データやメモリダンプの内容を格納するストレージ装置１５と、を備える。ここでストレージ装置１５は、例えばハードディスクや不揮発性記憶媒体を含む。また、通信装置１３は、例えばＬＡＮアダプタなどである。

現用系計算機１０のメモリ１２には、業務（図示省略）を提供するための第１のＯＳ（図中１ｓｔＯＳ）１と、ＨＢの生成などを行うミドルウェア（図中Ｍｉｄｄｌｅ）２と、第１のＯＳ１が停止した後にメモリダンプを実行する第２のＯＳ（図中２ｎｄＯＳ）３とが格納される。現用系計算機１０の演算装置１１は、障害が発生するまでは第１のＯＳ１とミドルウェア２を実行する。なお、第１のＯＳ１上で稼働するアプリケーションやサービスが業務として現用系計算機１０から提供される。

待機系計算機２０のメモリ１２には、ＯＳ４と、現用系計算機１０のＨＢを監視するミドルウェア（図中Ｍｉｄｄｌｅ）５が格納され、演算装置１１によって実行される。

現用系ＢＭＣ６は待機系ＢＭＣ７も同様に構成され、現用系ＢＭＣ６は現用系計算機１０に搭載され、待機系ＢＭＣ７は待機系計算機２０に搭載される。

現用系ＢＭＣ６はネットワーク３１を介して待機系計算機２０からのコマンドを受信するためのＬＡＮアダプタ１６と、演算装置１９とメモリ８を有する。待機系ＢＭＣ７も同様に構成され、ＬＡＮアダプタ１６が現用系計算機１０からのコマンドを受信する。

メモリ８にはウォッチドッグタイマ（WatchDog Timer、以下ＷＤＴとする）１８と、ＷＤＴ１８の状態を保持するＷＤＴ設定状態１７が格納される。ＷＤＴ設定状態１７は、少なくとも「有効状態」と「無効状態」のいずれかが設定される。これらの状態は互いに区別できれば任意の状態や他の値を用いても良い。

なお、本実施例において、「有効状態」は現用系計算機１０の稼働状態が業務を「開始」していることを示す。また、「無効状態」は現用系計算機１０の稼働状態が業務を「停止」していることを示す。

現用系計算機１０と現用系ＢＭＣ６の間はシステムインタフェース３０で接続され、例えばシンプルなＩ／Ｏポート操作により通信を行うＫＣＳ（ＫｅｙｂｏａｒｄＣｏｎｔｒｏｌｌｅｒＳｔｙｌｅ）インタフェースが使用される。待機系計算機２０と待機系ＢＭＣ７の間のシステムインタフェース３０も同様である。

現用系計算機１０と待機系計算機２０は、現用系ＢＭＣ６と待機系ＢＭＣ７を含めて対称的な構成をとり、互いに役割を入れ替えて相互に監視制御しても良い。

なお、本実施例１では、メモリ８のメモリ８内にＷＤＴ１８を設定する例を示したが、図示しないハードウェアでＷＤＴを構成してもよい。

図２は、現用系計算機１０が障害によって自発的に停止するケースのタイムチャートである。図２の例では、現用系計算機１０自身が異常を検知してＯＳ停止処理（カーネルパニック）と、およびメモリダンプ採取のための第２のＯＳ３の起動処理を行うケースにおいて、現用系計算機１０と現用系ＢＭＣ６、および待機系計算機２０の処理の流れを示している。

前述のとおり、現用系計算機１０と待機系計算機２０はネットワーク３２で接続され、現用系計算機１０と現用系ＢＭＣ６はシステムインタフェース３０で接続され、さらに現用系ＢＭＣ６と待機系計算機２０はネットワーク３１で接続されている。各ステップの詳細は以下の通りである。

ステップ１００では、現用系計算機１０にて業務を開始する前に、ミドルウェア２が初期設定としてウォッチドッグタイマ（ＷＤＴ）１８を有効化するコマンドを現用系ＢＭＣ６に送信する。本実施例１ではＷＤＴ１８を有効状態にするだけであり、ＷＤＴ１８のタイマは開始させない。なお、現用系計算機１０は、起動時や業務開始時などで上記初期設定（初期化処理）を行えば良い。

ステップ１０１で、現用系ＢＭＣ６は、ＷＤＴ設定状態１７を「有効状態」に設定する。

ステップ１０２、１０２ｎで、現用系計算機１０のミドルウェア５は、所定の時間間隔Ｔｉでネットワーク３２を介してハートビート（ＨＢ）を待機系計算機２０に送信し、現用系計算機１０が正常に稼働中であることを繰り返し通知する。

ステップ１０３、１０３ｎで、待機系計算機２０のミドルウェア２は、現用系計算機１０からＨＢメッセージを受信し、受信時刻を記憶する。

ステップ１０４で、現用系計算機１０上で稼働する第１のＯＳ１が自身の不整合を検知し、カーネルパニックとなる。現用系計算機１０は、メモリダンプ採取用の第２のＯＳへの移行処理を開始する。

ステップ１０５では、現用系計算機１０が、前記第１のＯＳ１から前記第２のＯＳ３へ移行する中間で実行されるＯＳ非依存処理で、ＷＤＴ１８を無効化するコマンドを、システムインタフェース３０を介して現用系ＢＭＣ６に送信する。

ここでＯＳ非依存処理とは、ＶＧＡなどの標準的に搭載されるデバイスをシンプルなＩ／Ｏポート操作などにより初期化し、第２のＯＳ３の起動に備える処理である。上述のＫＣＳインタフェースによる通信もまたシンプルなＩ／Ｏポート操作により実現できるため、ＯＳ無しの状態で動作するように実装することは容易である。例えば、メモリ１２に格納される第２のＯＳ３の直前に、Ｉ／Ｏポートを操作するコマンドなどをロードしておけば良い。

ステップ１０６で、現用系ＢＭＣ６は、現用系計算機１０から無効化コマンドを受信してＷＤＴ設定状態１７を「無効状態」に更新する。

ステップ１０７で、待機系計算機２０は最後にＨＢを受信してから所定時間Ｔｃ２０２経過したと判定すると、ネットワーク３１を介して現用系ＢＭＣ６に対してＷＤＴ状態取得コマンドを送信する。現用系ＢＭＣ６は、現在のＷＤＴ設定状態１７である「無効状態」を応答する。待機系計算機２０は現用系ＢＭＣ６のＷＤＴ設定状態１７が「無効状態」であることを検知する。

ステップ１０８では、現用系計算機１０の異常停止から業務引継ぎまでの時間の要求仕様がＴｆ２０３とした場合、待機系計算機２０は最後にＨＢを受信してからＴｆ２０３時間経過したときに、ステップ１０７で取得したＷＤＴ設定状態１７を判定する。待機系計算機２０は、判定結果が「無効状態」であった場合、現用系計算機１０の業務は完全に停止していると認識し、現用系計算機１０上で実行していた業務の引継ぎを行う。業務の引継ぎについては、周知または公知の技術を適用すれば良いので、ここでは詳述しない。

ステップ１０９で、現用系計算機１０は、第２のＯＳ３の起動処理を行う。

ステップ１１０で、現用系計算機１０は、第２のＯＳ３の起動処理が完了すると、メモリダンプ処理を開始する。なお、第２のＯＳ３の起動処理も含め、メモリダンプ処理にはkdump等を採用することができる。

ステップ１１１で、現用系計算機１０は、前記第１のＯＳ１のメモリ１２の内容を、例えばストレージ装置１５などに保存し、メモリダンプを完了する。

ステップ１１２で、現用系計算機１０はメモリダンプ完了後、第１のＯＳ１を再起動する。現用系計算機１０は、第１のＯＳを再起動した後は新たな待機系として機能しても良いし、あるいは、再起動させずに停止させても良い。

ここで、待機系計算機２０が、最後にＨＢを受信してからＷＤＴ状態取得（１０７）を行うまでの時間Ｔｃ２０２は次のように求める。ＨＢの送信間隔をＴｉ２００、カーネルパニック（１０４）からＷＤＴ無効化（１０５）までの最大所要時間をＴｄ２０１とする（例えば、Ｔｄ２０１は数百ミリ秒である）。このとき、Ｔｃ＞Ｔｉ＋ＴｄかつＴｃ＜Ｔｆを満たす時間Ｔｃ２０２を待機系計算機２０のミドルウェア２に設定しておけばよい。また、最後にＨＢを受信してから業務引継ぎ（１０８）までの時間Ｔｆ２０３は、上記時間Ｔｃ２０２に所定値を加算してミドルウェア２に設定しておけばよい。

以上の処理によって、現用系計算機１０及び待機系計算機２０は、前記従来例のように特別なハードウェアを必要とせずに、ＢＭＣを搭載した標準的な計算機を採用しながら、現用系計算機１０に異常が発生したときにはメモリダンプが強制的に停止されてしまうことを抑止できる。

そして、また、待機系計算機２０は、異常の発生によって停止した現用系計算機１０が第２のＯＳ３に移行するタイミングで現用系計算機の第１のＯＳ１の停止を検知できる。これにより、現用系計算機１０の異常による業務の停止から短時間で待機系計算機２０に業務を引き継がせることができる。さらに、現用系計算機１０及び待機系計算機２０では、ＯＳの改造や特殊なドライバは不要であるため、汎用ＯＳを利用することができる。

図３は、上記図２において、現用系計算機１０の第１のＯＳ１がカーネルパニックする代わりに、ハングアップ、例えばＯＳ内部処理の無限ループなどの無応答の障害が発生したケースにおけるタイムチャートである。各ステップにおける詳細は以下の通りである。

ステップ１００〜１０３ｎは、上記図２のケースと同様である。

ステップ１２０では、現用系計算機１０の第１のＯＳ１がハングアップし、定期的なＨＢの送信（１０２）が停止する。

ステップ１０７で、待機系計算機２０は最後にＨＢを受信してから所定時間Ｔｃ２０２経過すると、ネットワーク３１を介して現用系ＢＭＣ６に対してＷＤＴ状態取得コマンドを送信する。現用系ＢＭＣ６は、ＷＤＴ設定状態１７を応答する。待機系計算機２０は現用系ＢＭＣ６のＷＤＴ設定状態１７が「有効状態」のままであることを検知する。

ステップ１２１で、現用系計算機１０の第１のＯＳ１の異常停止から業務引継ぎまでの時間の要求仕様がＴｆ２０３とした場合、待機系計算機２０は最後にＨＢを受信してからＴｆ２０３時間経過したときに、前記ステップ１０７で取得したＷＤＴ設定状態１７を判定する。そして、ＷＤＴ設定状態１７が「有効状態」であった場合、現用系計算機１０の業務は稼働を続けている可能性があるため、待機系計算機２０はネットワーク３１を介して現用系ＢＭＣ６にＮＭＩの入力指示を送信し、現用系計算機１０における業務の停止とメモリダンプ処理の開始を指令する。

ステップ１０８で、現用系計算機１０へのＮＭＩの入力により現用系計算機１０の第１のＯＳ１が停止するので、待機系計算機２０は現用系計算機１０上で実行していた業務の引継ぎを行う。

ステップ１２２で、ＮＭＩの入力指示を受信した現用系ＢＭＣ６は、システムインタフェース３０を介して現用系計算機１０にＮＭＩを入力する。

ステップ１０４では、ＮＭＩを受信した現用系計算機１０が、ＮＭＩハンドリングとしてカーネルパニック処理を実施する。

ステップ１０５〜１０６では、上記図２と同様にして、現用系計算機１０がＷＤＴ１８の無効化コマンドを送信し、現用系ＢＭＣ６がＷＤＴ設定状態１７を「無効状態」に更新する。

ステップ１２３ではＮＭＩの入力によって現用系計算機１０上で稼働する第１のＯＳ１が確実に停止しない場合も想定されるので、待機系計算機２０は、ＮＭＩ入力指示（１２１）から所定の（Ｔｃ−Ｔｉ）２１０時間が経過した後に再度、ＷＤＴ状態取得を行う。そして、待機系計算機２０は、再度取得したＷＤＴ設定状態１７が「無効状態」であることを判定しても良い。その場合、業務引き継ぎはステップ１０８では行わず、ステップ１２３においてＷＤＴ設定状態１７が「無効状態」であることを判定した後に行う。

ステップ１０９〜１１２は、上記図２の処理と同様であり、現用系計算機１０が第２のＯＳ３を起動してメモリダンプを実行し、メモリダンプの完了後に第１のＯＳ１の再起動を実行する。

以上の処理により、本実施例１では、ＢＭＣを搭載した計算機および汎用ＯＳにより構成される多重系の計算機システムにおいて、現用系計算機１０で実施されるメモリダンプ処理を止めることなく、現用系計算機１０の第１のＯＳがハングアップなどによって異常停止したことを、待機系計算機２０で短時間で検知することができる。

さらに、障害が発生した現用系計算機１０は、メモリダンプ採取用の第２のＯＳ３を起動する前にＷＤＴ１８を無効化して、待機系計算機２０に現用系の業務が停止したことを通知することができる。これによって、現用系計算機１０の障害発生から、待機系計算機２０が業務を引きつぐまでの時間を短縮することができる。

前記従来例のような機能拡張ボードやＢＭＣを使用しない場合では、メモリダンプ採取用の第２のＯＳ３を起動してからＬＡＮアダプタ１４等の初期化が完了するまでは、待機系計算機２０に現用系の業務が停止したことを通知できない。このため、現用系計算機１０で障害が発生してから、待機系計算機２０が現用系計算機１０の業務を引き継ぐまでの待ち時間が長くなる。

これに対して、本実施例１のように、第２のＯＳ３を起動する前にＷＤＴ１８を無効化しておくことで、待機系計算機２０は最後のＨＢを受信してから時間Ｔｃの経過後にＷＤＴ設定状態１７を取得して現用系の業務が停止したことを判定することができる。これにより、迅速なフェイルオーバを実現することができる。

なお、上記実施例１では現用系計算機１０のミドルウェア２がＨＢを送信し、待機系計算機２０のミドルウェア５で現用系計算機１０の障害発生を監視する例を示したが、これらの処理をＯＳで行ってもよい。

また、本実施例１では、現用系ＢＭＣ６に搭載されたＷＤＴ１８の状態を格納するＷＤＴ設定状態１７を設ける例を示したが、これに限定されるものではない。例えば、現用系計算機１０の実行に影響（意図しない作用）を与えることなく、現用系ＢＭＣ６等で「有効状態」と「無効状態」を設定可能であればよい。すなわち、現用系ＢＭＣ６のメモリ８に確保した領域や、演算装置１１のレジスタ等のリソースうち、現用系計算機１０に影響を与えずに利用可能なリソースで「有効状態」と「無効状態」を表せばよい。

本発明の第２の実施例は、前記実施例１の図２、３に示したメモリダンプ採取用の第２のＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）３の起動を開始した後に、第２のＯＳ３がハングアップした場合に、現用系計算機１０にハードリセットを入力し、第１のＯＳ１を再起動させるように変更したものである。これにより、異常発生によって停止した現用系計算機１０で、第２のＯＳ３に障害が発生しても新たな待機系として早期に復帰させることを保証できる。

なお、本実施例２の計算機システムの構成は前記実施例１と同様であり、前記実施例１では利用していなかったＷＤＴ１８の機能を使用する点が相違する。

図５は、本実施例２で現用系ＢＭＣ６のＷＤＴ１８を活用するにあたり、ＷＤＴ設定状態１７の状態遷移を簡単に示したものであり、より正確にはＩＰＭＩ（Intelligent Platform Management Interface）の仕様に準拠する。

まずＷＤＴ設定状態１７が任意の状態のときに演算装置１９が初期設定５００を行い、有効状態５０１に遷移する。このとき、演算装置１９がＷＤＴ設定状態１７の設定項目の一部である初期カウンタをＴｔ、アクションをハードリセットに設定する。

次にＷＤＴ開始５０２（実際にはＷＤＴリセットと同じ）コマンドが現用系ＢＭＣ６に送信されると、ＷＤＴ設定状態１７は開始状態５０３となり、演算装置１９がＷＤＴ設定状態１７の一部である現在カウンタを前記初期カウンタの値Ｔｔにセットする。

ＷＤＴ設定状態１７が開始状態５０３にあるとき、予め設定された単位時間経過５０４すると、演算装置１９が前記現在カウンタを１ずつ減算する。

同じくＷＤＴ設定状態１７が開始状態５０３にあるとき、ＷＤＴリセット５０５コマンドが現用系ＢＭＣ６に送信されると、演算装置１９は前記現在カウンタの値を前記初期カウンタの値Ｔｔにセットし直す。

さらにＷＤＴ設定状態１７が開始状態５０３にあるとき、前記現在カウンタが０になると、前記アクションの設定に従い当該現用系ＢＭＣ６を搭載する計算機にハードリセットを入力し、タイマ発火状態５０７に遷移する。これにより、現用系計算機１０はＷＤＴ１８のカウントアップによって所定のアクションであるハードリセットが入力されて、強制的に再起動する。

以上を踏まえて、図４、図５を用いて本実施例２を実現する処理を説明する。図４は、メモリダンプ処理用の第２のＯＳ３がハングアップした場合に、自動的に第１のＯＳ１を再起動させる処理の一例を示すタイムチャートである。図４の処理は、前記実施例１の図２のケースに対し、本実施例２を適用するものであるが、前記実施例１の図３のケースについても同様に適用することができる。各ステップの詳細は以下の通りである。

ステップ１３０では、現用系計算機１０は業務を開始する前に、初期設定としてＷＤＴ１８を有効状態５０１にするコマンドを現用系ＢＭＣ６に送信する。ここではＷＤＴ１８を有効状態５０１にするだけであり、タイマ（現在カウンタ）は開始させない。

ステップ１３１では、現用系ＢＭＣ６がＷＤＴ１８の有効化コマンドを受信し、ＷＤＴ設定状態１７を有効状態５０１に設定する。

ステップ１０２〜１０４は、前記実施例１の図２と同様であり、ＨＢの送信後に現用系計算機１０の第１のＯＳ１が異常の発生によってカーネルパニックとなる。

ステップ１３２では、メモリダンプ採取用の第２のＯＳ３を起動する前のＯＳ非依存処理において、ＷＤＴ開始５０２コマンドを、システムインタフェース３０を介して現用系ＢＭＣ６に送信する。本実施例２も前記実施例１と同様に、第２のＯＳ３を起動する前に、現用系ＢＭＣ６に対して設定の変更を指令する。

ステップ１３３では、現用系ＢＭＣ６は、ＷＤＴ設定状態１７を開始状態５０３に更新する。

ステップ１０７〜１０９は、前記実施例１の図２と同様であり、更新されたＷＤＴ設定状態１７を取得した待機系計算機２０は、現用系計算機１０の業務を引き継ぎ、現用系計算機１０では第２のＯＳ３を起動する。

ステップ１３４〜１３４ｎでは、第２のＯＳ３が起動した後、およびメモリダンプ最中において、現用系計算機１０は予め設定された一定の周期でＷＤＴリセット５０５コマンドを、システムインタフェース３０を介して現用系ＢＭＣ６に送信する。

ステップ１３５〜１３４ｎでは、現用系ＢＭＣ６は、ＷＤＴリセット５０５コマンドを受け取り、前記現在カウンタを前記初期カウンタ値Ｔｔにリセットする。そして、現用系ＢＭＣ６では現在カウンタのカウントを上述のように繰り返す。

ステップ１１０では、現用系計算機１０は、第２のＯＳ３の起動処理が完了すると、メモリダンプ処理を開始する。

ステップ１３６では、何らかの原因で、第２のＯＳ３のメモリダンプ処理がハングアップする。ステップ１３７では、最後のＷＤＴリセット１３５ｎから所定の時間Ｔｔが経過した後に、前記現在カウンタが０になり、タイマが発火する。現用系ＢＭＣ６は、ＷＤＴ設定状態１７を発火状態５０７に設定し、前記アクションに設定された通り、現用系計算機１０にハードリセットを入力する。

ステップ１３８では、ステップ１３７のハードリセット入力により、現用系計算機１０は強制的に再起動される。これにより、現用系計算機１０は新たな待機系計算機として復帰することができる。

なお、第２のＯＳ３のハングアップ（１３６）は、ステップ１０９およびそれ以降のタイミングで起こる場合も同様である。

以上の処理により、本実施例２ではさらに、第１のＯＳ１が停止した後の現用系計算機１０で実施される第２のＯＳ３によるメモリダンプ処理において、第２のＯＳ３の起動からメモリダンプ完了までの間にハングアップした場合であっても、待機系計算機２０に業務を引き継がせて、予測可能な時間内に現用系計算機１０を再起動して新たな待機系として復帰させることが可能となる。

また、上記実施例１、２ではＮＭＩやハードリセットを現用系計算機１０へ入力する装置として現用系ＢＭＣ６を用いる例を示したが、これに限定されるものではない。例えば、現用系計算機１０にＮＭＩやハードリセットを入力可能な計算機管理装置であれば良い。

また、上記実施例１、２では待機系計算機２０が現用系ＢＭＣ６のＷＤＴ設定状態１７を参照して、現用系計算機１０で業務が確実に停止したことを判定したが、ＷＤＴ設定状態１７に限定されるものではない。例えば、現用系計算機１０が業務を開始するとき（または開始前）にミドルウェア２または第１のＯＳが、現用系ＢＭＣ６または計算機管理装置の業務の開始を示す業務稼働状態に「開始」（＝ＷＤＴ有効）を設定する。

そして、第１のＯＳがカーネルパニックとなって、第２のＯＳ３を起動する前に、所定のＩ／Ｏ操作によって業務の停止を示す状態を現用系ＢＭＣ６または現用系の計算機管理装置の業務稼働状態に「停止」（＝ＷＤＴ無効）を設定する。待機系計算機２０は、最後のＨＢから所定時間Ｔｃの経過後に、現用系ＢＭＣ６または計算機管理装置の業務稼働状態を取得して、「停止」であれば現用系計算機１０の業務が確実に停止したと判定して業務を引き継ぐことができる。

このように、本発明では、現用系計算機１０に接続された計算機管理装置に、業務稼働状態の「開始」または「停止」が設定され、待機系計算機２０は、障害の発生を検知したときに業務稼働状態が「停止」であれば、現用系計算機１０の業務を引き継いで、迅速なフェイルオーバを実現できる。

また、本実施例１、２では、通信装置１３が待機系計算機２０に所定の周期で送信するＨＢと、現用系計算機１０がＷＤＴ設定状態１７に設定する状態を用いる例を示したが、これに限定されるものではない。例えば、現用系計算機１０が稼働していることを示す第１の稼働情報と、現用系計算機１０の第１のＯＳ１が停止したことを示す第２の稼働情報を計算機管理装置に設けてもよい。この場合、待機系計算機２０は、最後の第１の稼働情報を受信したときから所定時間後に、計算機管理装置から第２の稼働情報を取得することで、第１のＯＳ１に障害が発生した後に、第１のＯＳ１が確実に停止ししたことを判定することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

６現用系ＢＭＣ
７待機系ＢＭＣ
１０現用系計算機
１１演算装置
１２メモリ
１３通信装置
１４ＬＡＮアダプタ
１５ストレージ装置
１７ＷＤＴ設定状態
１８ウォッチドッグタイマ
２０待機系計算機
３０システムインタフェース
３１、３２ネットワーク

Claims

プロセッサとメモリとを有する計算機を複数有し、前記複数の計算機のうち少なくとも一つを現用系計算機とし、他の計算機のうち少なくとも一つを待機系計算機とし、前記現用系計算機と前記待機系計算機を接続する第１のネットワークとを有する計算機システムであって、
前記現用系計算機は、
当該現用系計算機に接続されて、当該現用系計算機を管理する計算機管理装置と、
業務を提供する第１のＯＳと、
前記第１のＯＳが稼働中であることを示すハートビートを所定の周期で前記待機系計算機へ送信する通信部と、
前記第１のＯＳに障害が発生した後に前記メモリの内容を出力する第２のＯＳと、を有し、
前記計算機管理装置は、
第２の所定時間までカウントすると所定のアクションを実行するウォッチドッグタイマと、
前記ウォッチドッグタイマの稼働状態を設定するタイマ設定状態情報と、
第２のネットワークを介して前記待機系計算機に接続されたアダプタと、を有し、
前記現用系計算機は、
前記業務の開始時に前記計算機管理装置の前記タイマ設定状態情報に前記業務の開始を示す有効状態を設定し、前記アクションとして当該現用系計算機のハードリセットを設定し、
前記現用系計算機のプロセッサは、
前記第１のＯＳが障害により停止したときには、前記ウォッチドッグタイマのカウントを開始させる開始コマンドを前記計算機管理装置に送信してから前記第２のＯＳを起動し、
前記計算機管理装置は、
前記開始コマンドを受信して前記タイマ設定状態情報を開始状態に更新し、
前記待機系計算機は、
前記ハートビートを受信してから第１の所定時間が経過した後に、前記タイマ設定状態情報を取得し、前記タイマ設定状態情報が前記開始状態であれば、前記第１のＯＳが停止したと判定して前記現用系計算機の業務を引き継ぎ、
前記現用系計算機の前記第２のＯＳは、
第３の所定時間毎に前記ウォッチドッグタイマをリセットし、
前記計算機管理装置は、
前記第２の所定時間までカウントした場合には前記所定のアクションとして設定された前記ハードリセットを前記現用系計算機へ入力することを特徴とする計算機システム。
請求項１に記載の計算機システムであって、
前記第２のＯＳは、
前記障害が発生した前記現用系計算機の前記メモリのダンプを実行することを特徴とする計算機システム。
プロセッサとメモリとを有する計算機を複数有し、前記複数の計算機のうち少なくとも一つを現用系計算機とし、他の計算機のうち少なくとも一つを待機系計算機とし、前記現用系計算機と前記待機系計算機を接続する第１のネットワークとを有して、前記現用系計算機が提供する業務を前記待機系計算機に切り替える計算機システムの制御方法であって、
前記現用系計算機は、
当該現用系計算機に接続されて、第２の所定時間までカウントすると所定のアクションを実行するウォッチドッグタイマと、前記ウォッチドッグタイマの稼働状態を設定するタイマ設定状態情報と、第２のネットワークを介して前記待機系計算機に接続されたアダプタと、を有して当該現用系計算機を管理する計算機管理装置と、
前記業務を提供する第１のＯＳと、
前記第１のＯＳが稼働中であることを示すハートビートを所定の周期で前記待機系計算機へ送信する通信部と、
前記第１のＯＳに障害が発生した後に前記メモリの内容を出力する第２のＯＳと、を有し、
前記制御方法は、
前記現用系計算機が、前記業務を提供する前記第１のＯＳを稼働させる第１のステップと、
前記現用系計算機が、当該現用系計算機を管理する前記計算機管理装置の前記タイマ設定状態情報に前記業務の開始を示す有効状態を設定し、前記アクションとして当該現用系計算機のハードリセットを設定する第２のステップと、
前記現用系計算機が、前記第１のＯＳが稼働中であることを示す前記ハートビートを所定の周期でネットワークを介して前記待機系計算機へ送信する第３のステップと、
前記現用系計算機のプロセッサが、前記第１のＯＳが障害により停止したときには、前記ウォッチドッグタイマのカウントを開始させる開始コマンドを前記計算機管理装置に送信する第４のステップと、
前記計算機管理装置が、前記開始コマンドを受信して前記タイマ設定状態情報を開始状態に更新する第５のステップと、
前記現用系計算機が、前記第２のＯＳを起動する第６のステップと、
前記待機系計算機が、前記ハートビートを受信してから第１の所定時間が経過した後に、前記タイマ設定状態情報を取得し、前記タイマ設定状態情報が前記開始状態であるか否かを判定する第７のステップと、
前記待機系計算機は、前記判定の結果が前記開始状態であれば、前記第１のＯＳが停止したと判定して前記現用系計算機の前記業務を引き継ぐ第８のステップと、
前記現用系計算機の前記第２のＯＳが、第３の所定時間毎に前記ウォッチドッグタイマをリセットする第９のステップと、
前記計算機管理装置の前記ウォッチドッグタイマが、前記第２の所定時間までカウントした場合には前記所定のアクションとして設定された前記ハードリセットを前記現用系計算機へ入力する第１０のステップと、
を含むことを特徴とする計算機システムの制御方法。
請求項３に記載の計算機システムの制御方法であって、
前記第６のステップは、
前記障害が発生した前記現用系計算機の前記メモリのダンプを実行することを特徴とする計算機システムの制御方法。