JP2005115751A - 計算機システム及び計算機システムの障害兆候の検知方法 - Google Patents

Abstract

【課題】動作中のＯＳ及びＡＰの状態を解析し、障害につながる兆候を検出して、起こりうる障害に対する処理を可能とする。
【解決手段】一般的なＯＳである第１ＯＳ１上で、通常の業務処理を行うサービスＡＰ３が実行される。第１ＯＳ１は、第１ＯＳ１が行った動作を、動作した時間と共に動作記録情報として記録する動作記録制御部６と、外部からの処理を受け付けて実行する補助ドライバ７とを有する。第１ＯＳ１より信頼性の高い第２ＯＳ２に備えられるマルチＯＳ制御部インタフェース１０は、第２ＯＳ２の上で動作するＡＰ４からマルチＯＳ制御部５を操作する。第２ＯＳ２上で動作する解析予測ＡＰ４は、第１ＯＳ１及びサービスＡＰ３の状態を解析して障害の兆候を検知する。障害の兆候を検出した場合、被解析ＯＳやサービスＡＰの縮退運転や、現用系から待機系の切り替え準備、切り替え等を障害が発生する前に行う。
【選択図】 図２

Description

本発明は、計算機システム及び計算機システムの障害兆候の検知方法に係り、特に、アプリケーション（ＡＰ）、オペレーティングシステム（ＯＳ）及びハードウェア（ＨＷ）の障害発生の兆候を自システム内で検知可能とした計算機システム及び計算機システムの障害兆候の検知方法に関する。

一般に、計算機システムのＡＰやＯＳは、ＡＰ、ＯＳ自身に含まれる欠陥や、ＯＳが使用している機器の障害等が主な原因となる等の様々な理由で障害を起こして停止することがある。

前述したような障害が起こったときにも、ＡＰが提供する機能を継続する必要がある場合にＡＰの障害を検知する技術に関する従来技術として、ウォッチドッグタイマを利用して、処理終了までの時間を監視したり、通信の授受が時間内に完了したか否かを判断したりするハートビートと呼ばれる技術が知られている。また、他の従来技術として、システムが定期的に吐き出すログを監視し、障害があったことを検知するという技術が知られている。なお、一般的なＨＡクラスタで利用されているハートビートに関する従来技術として、例えば、非特許文献１に開示された技術が知られている。
http://www.atmarkit.co.jp/flinux/rensai/ciuster02/ciuster02.html

前述したハートビートを利用する障害監視の方法に関する従来技術としては様々なものがあるが、何れにしても、これらの方法は、障害が実際に起こった後で、ある程度の時間が経過してから障害が検知されるため、常に障害の検知が遅くなるという問題点を有している。

また、ハートビートやウォッチドッグタイマを用いる従来技術は、ＡＰやＯＳの負荷が高くなった場合に、処理終了までの時間、通信データの授受の時間が監視制限時間を超えてしまう場合があり、障害を誤検出するという問題点を有している。

また、システムのログを監視する方法も、前述と同様に、障害が実際に起こった後で、ある程度の時間が経過してから障害が検知されるため、常に障害の検知が遅くなるという問題点を有している。

さらに、前述した従来技術による障害の監視は、障害監視用のＡＰにより行われるが、障害監視のためのＡＰが監視対象のＡＰと同一のＯＳ上で実行されているため、ＯＳ自身に障害が起きた場合に、監視を行うＡＰもＯＳの障害に巻き込まれてしまい、監視機能が失われてしまうという問題点を有している。

前述したような問題点を解決するために、監視用として別の計算機を用意するという方法もあるが、この場合も、やはり障害が起きた後でしか、障害が起きたことの検知を行うことができないという問題点が残ることになる。

本発明の目的は、前述した従来技術の問題点を解決し、動作中のＯＳ及びＡＰの状態を解析し、障害につながる兆候を検出して、起こりうる障害に対する処理を行うことを可能とした計算機システム及び計算機システムの障害兆候の検知方法を提供することにある。

本発明によれば前記目的は、第１のＯＳと、該第１のＯＳ上で動作し通常の業務処理を行うサービスアプリケーションと、前記第１のＯＳとは異なる第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記第１のＯＳが、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションが、前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知するように計算機システムを構成することにより達成される。

また、前記目的は、第１のＯＳと、該第１のＯＳ上で動作し通常の業務処理を行うサービスアプリケーションと、前記第１のＯＳとは異なる第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記第１のＯＳが、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションが、前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知する構成の計算機を複数台備え、１つの計算機の解析予測アプリケーションが、自己回復不能な障害の兆候を検知した場合、他の計算機に解析した障害の内容を通知し、処理を受け継がせるようにしたことにより達成される。

本発明によれば、同時に複数のＯＳを動作させ、一方のＯＳのＡＰから動作中の他方のＯＳやＡＰの状態を随時解析し、障害につながる兆候を検出して、起こりうる障害に対する処理を行うようにしているので、ＯＳやＡＰが不安定になり、動作不可能になったとしても、障害が発生する前にその兆候を検知し、障害に対処する処理を実行でき、障害による影響を最小限に抑えることが可能となる。

以下、本発明による計算機システムの実施形態を図面により詳細に説明する。

図１は本発明の第１の実施形態による計算機システムのハードウェア構成を示すブロック図、図２はメモリ２１の内部に格納されるプログラムの構成を示す図である。

本発明の第１の実施形態による計算機システムは、図１に示すように、計算機２０と、この計算機２０に接続される外部記憶装置２３、キーボード２４、マウス２５及び画面出力装置２９とにより構成され、計算機２０は、ＣＰＵ２２と、主記憶装置（メモリ）２１と、冷却装置２６と、温度センサ２７と、通信装置２８とを備えて構成される。

計算機２０のメモリ２１の内部には、図２に示すように、ＣＰＵ２２により実行される第１ＯＳ１、第２ＯＳ２、サービスＡＰ３、解析予測ＡＰ４、マルチＯＳ制御部５の各プログラムが格納されている。そして、第１ＯＳ１は、動作記録制御部６及び補助ドライバ７を備え、マルチＯＳ制御部５は、メモリ取得部８及びＯＳ間メッセージ通信部９を備えている。また、第２ＯＳ２は、マルチＯＳ制御部インタフェース１０を備えている。

図３はメモリ２１に格納される各プログラム内に設けられるデータテーブルの構成を示す図である。図３に示すように、サービスＡＰ３は、ＡＰ状態情報１７を含み、第１ＯＳ１は、ＯＳ状態情報１１と動作記録情報１２とページ変換テーブル１８とを含む。解析予測ＡＰ４は、障害兆候表１３と、対処プログラム表１４と、情報アドレス変換表１５と、前状態情報保持部１６とを含む。

前述において、第１ＯＳ１は、一般的なＯＳであり、サービスＡＰ３は、第１ＯＳ１の上で実行されるＡＰであり、通常の業務処理を行うプログラムである。解析予測ＡＰ４は、第２ＯＳ２の上で実行されるＡＰであり、第１ＯＳ１及びサービスＡＰ３の状態を解析して障害の兆候を検知するためのプログラムである。第２ＯＳ２は、第１ＯＳ１とは異なるＯＳであり、第１ＯＳ１より信頼性の高いＯＳであることが望ましい。

第１ＯＳ１内の動作記録制御部６は、第１ＯＳ１が行った動作を、動作した時間と共に動作記録情報１２に記録する。ここで記録される動作には、例えば、プロセスのコンテキストスイッチや、割り込み処理、システムコールやメモリ割り当て、その他第１ＯＳ１や計算機２０が出力する警告やエラー動作がある。第１ＯＳ１内の補助ドライバ７は、解析予測ＡＰ４の補助を行う補助プログラムであり、解析予測ＡＰ４上に解析すべき情報が格納されるメモリの位置と解析方法及び障害に対して行うべき処理の一覧を保持し、この処理の一覧の内容に従って、障害の兆候によって、第１ＯＳ１の障害に対する処理を行う。第１ＯＳ１の外部からの処理を受け付け、実行する処理、例えば、第２ＯＳ２から要求される処理を実行する。この補助ドライバ７への指示は、マルチＯＳ制御部５のＯＳ間メッセージ通信部９を用いて行われる。

マルチＯＳ制御部インタフェース１０は、第２ＯＳ２の機能として備えられるものであり、第２ＯＳ２の上で動作するＡＰからマルチＯＳ制御部５を操作するインタフェースである。

ＯＳ状態情報１１は、第１ＯＳ１の現在の動作状態を表す情報である。ここに格納される情報には、第１ＯＳ１で動作するＡＰを管理するためのプロセス管理情報や、ＯＳとプロセスのＣＰＵ時間の消費情報、同期を取るためのロックの使用状況、システムで開いているファイルやファイルハンドルの情報、第１ＯＳ１が管理しているメモリに関する情報、冷却装置２６のファンの回転数、温度センサ２７からの情報等がある。

ＡＰ状態情報１７は、サービスＡＰ３の動作状態を表す情報であり、この情報をチェックポイントとして保存しておくことにより、サービスＡＰ３のサービスが中断した場合に、中断した場所からサービスを再開できるだけの情報を有しているものとする。ページ変換テーブル１８は、第１ＯＳ１がＣＰＵの仮想メモリ機能を利用する場合に使用する論理アドレスから物理アドレスへの変換を行う際に参照するテーブルである。

図６は障害兆候表１３の構成を示す図である。障害兆候表１３は、解析予測ＡＰ４が第１ＯＳ１やサービスＡＰ３の情報を解析する際に使用する情報を格納しており、障害の兆候として予想される障害の兆候パターンと、その障害の兆候に対して利用する対処プログラム番号のリストとの組に兆候番号を付して保持している。例えば、兆候番号１の障害の兆候パターンが「動作記録が中断」であり、これに対処する対処プログラムリストに、プログラム番号１、４が１つの組として保持されており、また、兆候番号２の障害の兆候パターンが「デバイスからの異常発生」であり、これに対処する対処プログラムリストに、プログラム番号２、３が１つの組として保持されている。

図７は対処プログラム表１４の構成を示す図である。対処プログラム表１４は、図６の障害兆候表１３における対処プログラム番号のリストに保持される各対処プログラムの対処プログラム番号と、そのプログラムが実行する対処動作の内容とを保持している。

図８は情報アドレス変換表１５の構成を示す図である。情報アドレス変換表１５は、第１ＯＳ１上のサービスＡＰが持つＡＰ状態情報１７、第１ＯＳ１が持つＯＳ状態情報１１、動作記録情報１２へ第２ＯＳ２からアクセスするために必要な論理アドレスと、物理アドレスとの変換を行うための表であり、ＡＰ状態情報１７、ＯＳ状態情報１１、動作記録情報１２を示すカーネルページの情報と、論理アドレスと、物理アドレスとの組を保持している。

前状態情報保持部１６は、図示していないが、解析予測ＡＰ４が今まで解析を行った結果や、ＡＰ状態情報１７のチェックポイント情報、ＯＳ状態情報１１の内、障害の兆候を調べるために必要なデータを保持している。

マルチＯＳ制御部５は、この上で動作する第１ＯＳ１と第２ＯＳ２とがお互いに独立して各種の処理を実行することが可能なように制御を行っている。独立して実行するとは、２つのＯＳが計算機の資源であるメモリ２１や入出力デバイスを分割して利用し、互いの実行が他に影響を与えないことを言う。１つの計算機で複数のＯＳを独立に実行する技術としては、例えば、特開平１１−１４９３８５号公報（以下、文献１という）に開示されている。この文献１によれば、第１ＯＳ１と第２ＯＳ２とを独立して実行でき、第１ＯＳ１が障害で停止した場合でも、第２ＯＳ２は継続して動作することができる。

マルチＯＳ制御部５は、さらに、あるＯＳから他のＯＳが使用している物理メモリをアクセスできるようにするメモリ取得部８を備えている。このメモリ取得部８は、例えば、あるＯＳの物理アドレスにあるページが、アクセス要求のあったＯＳからアクセス可能かどうかを調べ、要求のあったＯＳが利用できるように、ページテーブルに直接そのページの割り当てを行ったり、ＯＳ間でページ内容をコピーする機能である。

また、マルチＯＳ制御部５は、さらに、ＯＳ相互間での情報のやり取りを行うことができるように、相手のＯＳの手続きを呼び出す機能であるＯＳ間メッセージ通信部９を備えている。

図４は第２ＯＳ２が情報アドレス変換表１５を作成、更新する際の処理動作を説明するフローチャートであり、次に、これについて説明する。ここでの処理は、計算機システムが立ち上げられたときに、第２ＯＳ２が第１ＯＳ１の側にあるＡＰ状態情報１７、ＯＳ状態情報１１、動作記録情報１２の格納されているメモリアドレスの情報を持っていないために、それらの情報が格納されているメモリアドレスを取り込んで図８に示すような情報アドレス変換表１５を作成する処理である。

（１）まず、第１ＯＳ１の側にあるＡＰ状態情報１７、ＯＳ状態情報１１、動作記録情報１２の格納されているメモリの論理アドレスが既に取得されて判っているか否かを判定する（ステップ１０１）。

（２）ステップ１０１の判定で、第１ＯＳ１に格納されている動作記録情報１２及びＯＳ状態情報１１、ＡＰ状態情報１７の論理アドレスが取得できてなかった場合、補助ドライバ７を呼び出して動作記録情報１２及びＯＳ状態情報１１、ＡＰ状態情報１７の論理アドレスを取得する（ステップ１０２）。

（３）ステップ１０１の判定で、動作記録情報１２及びＯＳ状態情報１１、ＡＰ状態情報１７の論理アドレスが判っていた場合、または、ステップ１０２の処理でこれら論理アドレスを取得した後、第１ＯＳ１がページ変換テーブル１８を使用しているか否かを判定する（ステップ１０３）。

（４）ステップ１０３の判定で、第１ＯＳ１がページ変換テーブル１８を使用していた場合、このページ変換テーブル１８の位置が予め判っているか否かを判定し、判らない場合、補助ドライバ７を呼び出して前述のページ変換テーブル１８の位置を取得する（ステップ１０４、１０５）。

（５）ステップ１０４の判定で、ページ変換テーブル１８の位置が予め判っていた場合、また、ステップ１０５の処理でページ変換テーブル１８の位置を取得した後、メモリ取得部８によりページ変換テーブル１８そのものを取得する（ステップ１０６）。

（６）その後、取得したページ変換テーブル１８から動作記録情報１２及びＯＳ状態情報１１、ＡＰ状態情報１７の論理アドレスを物理アドレスに変換し、情報アドレス変換表１５を作成する（ステップ１０７、１０９）。

（７）ステップ１０３の判定で、第１ＯＳ１がページ変換テーブル１８を使用していなかった場合、論理アドレスを物理アドレスとして使用することとして情報アドレス変換表１５を作成する（ステップ１０８、１１０）。

前述したステップ１０４の判定で、ページ変換テーブル１８の位置が判っていなかった場合、ページ変換テーブル１８を、ＯＳを切り替えるためにマルチＯＳ制御部５が動作するときに、ＣＰＵ２２の制御レジスタから取得するようにすることもできる。このようにすることにより、ページ変換テーブル１８を探し出す必要がなくなる。

また、前述した動作記録情報１２及びＯＳ状態情報１１、ＡＰ状態情報１７の論理アドレス及び物理アドレスの取得方法として、第１ＯＳ１または第１ＯＳ１に内蔵された補助ドライバ７が、これらの情報にアクセスするための手段を用意し、また、これらの情報がどこにあるのかという情報を、マルチＯＳ制御部５に対して登録するためのインタフェースをマルチＯＳ制御部５に備えておくようにする方法もある。このようにすることにより、ＯＳ状態情報１１等が動的にメモリ上の位置が変化する場合であっても対応することが可能となる。

図５は第２ＯＳ２上の解析予測ＡＰ４の処理動作を説明するフローチャートであり、次に、これについて説明する。なお、図５に示すフローにおいて、何も記述していないステップ１３０は、ステップ１２２の繰り返しの処理を受けてステップ１２３の処理に戻すための処理ステップであり、また、同様に、何も記述していないステップ１２９は、ステップ１２５の繰り返しの処理を受けてステップ１２６の処理に戻すための処理ステップである。

（１）まず、解析予測ＡＰ４は、マルチＯＳ制御部５のメモリ取得部８と情報アドレス変換表１５とを用いて、第１ＯＳ１のＯＳ状態情報１１や動作記録情報１２、サービスＡＰ３のＡＰ状態情報１７の内容を取得する。また、前状態情報保持部１６から以前の第１ＯＳ１、サービスＡＰ３の状態情報を取得する（ステップ１２１）。

（２）次に、ステップ１２１の処理で取得した情報について、障害兆候表１３のパターンに従った解析を行い、ステップ１２１の処理で取得した情報から障害につながる動作や状態の変化のパターンを調べる。この調べは、障害兆候表１３のパターンの数だけ繰り返される（ステップ１２２、１２３、１３０）。

（３）解析の結果、障害の兆候を検出したか否かを判定し、障害の兆候を検出した場合、障害兆候表１３のパターンに併記された障害対処を行うプログラムリストを得て、次に説明する処理動作を繰り返す（ステップ１２４、１２５）。

（４）まず、対処プログラム表１４から対処動作プログラムを得て、この対処プログラムの行う対処動作が実行可能か否かを判定し、可能であれば、対処動作を実行する（ステップ１２６〜１２８）。

（５）ステップ１２７の判定で、対処動作を実行できないと判定された場合、ステップ１２６の処理に戻って、新たな対処動作を試みる（ステップ１２９）。

（６）障害兆候表にあるパターンの全てを調べ、対処動作を終了したとき、また、ステップ１２３、１２４の処理の繰り返しで、障害の兆候を検出できなかった場合、解析予測ＡＰ４は、サービスＡＰ３を再開できるように、ステップ１２１の処理で取得した情報を使用して前状態情報保持部１６の情報を更新し（ステップ１３１）、一定時間動作を停止した後、ステップ１２１からの処理に戻って、障害解析の処理を続ける（ステップ１３１、１３２）。

前述した本発明の実施形態による各処理は、処理プログラムとして構成することができ、この処理プログラムは、ＨＤ、ＤＡＴ、ＦＤ、ＭＯ、ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等の記録媒体に格納して提供することができ、また、ネットワークにより提供することができる。

障害兆候表１３に登録される障害兆候パターンとしては、例えば、以下に説明するようなものがある。

サービスＡＰ３の情報がＯＳ状態情報１１のプロセス管理情報を解析しても見つからず、動作記録情報１２の警告情報に、サービスＡＰ３の異常終了が記録されているパターン。この場合、サービスＡＰ３の障害と判断する。

サービスＡＰ３に対して、一定時間ＣＰＵ時間の割り当てがなく、サービスＡＰ３の実行が行われていないことが、動作記録情報１２に記されたコンテキストスイッチの実行履歴から判るパターン、及び、この場合に、ＯＳ状態情報１１のプロセス管理情報やロックの使用状況からサービスＡＰ３が何らかの動作の待ち合わせを行っていることが調べられたパターン。これらの場合、サービスＡＰ３に対するＣＰＵ時間の割り当てで障害が起きたと判断する。

動作記録情報１２の割り込みに関する動作の履歴情報から、キーボード２４やマウス２５、通信装置２８からの反応速度が、前状態情報保持部１６に記録した定常状態に比べて遅いパターン。この場合、サービス品質の低下や、装置自体の故障の兆候と判断する。

動作記録情報１２のエラー履歴情報にメモリ２１のパリティエラーが報告されているパターン。この場合、メモリ２１の故障の兆候と判断する。

動作記録情報１２にあるプロセス間通信の記録や、第１ＯＳ１のメモリ割り当て記録、ＯＳ状態情報１１のメモリ使用状況から、メモリ不足から何らかのＡＰが異常終了しているパターン。この場合、メモリリークによる障害の兆候や、過負荷による障害の兆候と判断する。

また、ＯＳ状態情報１１からファイルハンドルなどのシステムリソースに余裕がなくなっているのを検知したパターン。この場合、リソース不足になる可能性があり、障害の兆候と判断する。

ＯＳ状態情報１１のＯＳのＣＰＵ時間の消費を調べることにより、第１ＯＳ１自体が消費するＣＰＵ時間とサービスＡＰ３が消費するＣＰＵ時間の割合を調べて、その割合が、前状態情報保持部１６に記録されているものに比べて、極端に第１ＯＳ１の割合が多いことを検知したパターン。この場合、サービス品質が低下しはじめている可能性があり、障害の兆候と判断する。

動作記録情報１２の割り込み履歴から、割り込みが多発しているのが検知され、ＯＳ状態情報１１から第１ＯＳ１が消費するＣＰＵ時間が多いことが検知されたパターン、この場合、割り込み処理の負荷が高くなることによって、サービス品質が低下しはじめている可能性があり、障害の兆候と判断する。

動作記録情報１２のエラー発生履歴情報から、ディスクアクセスエラーが発生していることが検知されたパターン。この場合、そのディスクの物理的な寿命に達した、あるいは、欠陥が生じた可能性があり、障害の兆候と判断する。

ＯＳ状態情報１１の温度センサ情報から、前状態情報保持部１６に記録している定常状態に比べてＣＰＵ２３や計算機２０の温度が上昇したり、冷却装置２６のファンの回転数が減少していることが検知されたパターン。この場合、ハードウェア障害を引き起こす可能性があり、障害の兆候と判断する。

ＯＳ状態情報１１や動作記録情報１２、ＡＰ状態情報１７等のデータは、第１ＯＳ１においても重要度が高く、アクセス頻度が高いデータである。これらがディスク上へスワップアウトされているパターン。この場合、メモリが深刻な不足状態にあると判断する。

次に、図７に示す対処プログラム表１４に登録されている対処プログラムの対処動作の例を、図７を参照して説明する。

サービスＡＰ３が異常終了している場合、プログラム番号０のプログラムが、サービスＡＰ３を再度起動させる（１４００）。

サービスＡＰ３の実行が止まっている、あるいは、サービスＡＰ３が他のＡＰの実行を待っている場合、プログラム番号１のプログラムが、これらのＡＰの優先度を上昇させるように、補助ドライバ７に指示する（１４０１）。

ある装置の故障が予測される場合、プログラム番号２のプログラムが、その装置の使用を禁止する。また、メモリ２１の障害の場合、プログラム番号２のプログラムが、対応する部分を割り当てないようにマルチＯＳ制御部５のＯＳ間メッセージ通信部９を用いて指示する。例えば、外部記憶装置２３が複数ある場合、１つに不良が発見されたとしても、他の記憶装置が利用可能ならば、計算機２０全体を止める必要はない。このため、不良の発生した記憶装置のみを利用不可能にして、計算機の動作を続行させる（１４０２）。

メモリ不足やリソース不足につながる障害の兆候を検知した場合、プログラム番号３のプログラムが、メモリやリソースを大量に消費しているＡＰを再起動するように、補助ドライバ７に指示する（１４０３）。

また、割り込みが多発している場合、プログラム番号４のプログラムが、割り込み処理の原因となる装置への動作を止め、割り込み時の動作を変更することを補助ドライバ７に指示する（１４０４）。

冷却装置２６に障害の兆候が現れた場合、プログラム番号５のプログラムが、補助ドライバ７を用いて、ＣＰＵ２２の動作周波数を下げ（１４０５）、また、プログラム番号６のプログラムが、第１ＯＳ１が動作するときにＣＰＵ２２の一時停止命令を実行する等により、発熱を抑制するように指示する（１４０６）。

前述した障害対処動作が実行できない場合、最終的に、プログラム番号７のプログラムが、第１ＯＳ１を再起動させる（１４０７）。

前述において、第１ＯＳ１あるいはサービスＡＰ３を再起動させた場合、直前に前状態情報保持部１６に退避していたＡＰ状態情報１７を用いて、サービスＡＰ３の動作を再開させる。

以上説明したような方法を用いることにより、本発明の第１の実施形態は、第１ＯＳ１に実際の障害が発生する前に、その兆候を検知し、障害を未然に防ぐように第１ＯＳ１を動作させることができる。

図９は本発明の第２の実施形態による計算機システムのハードウェア構成を示すブロック図である。なお、第２の実施形態におけるハードウェア構成以外の部分の構成及び動作は、第１の実施形態の場合と同一である。

図９に示す本発明の第２の実施形態は、図１に示した第１の実施形態に対して、外部から監視を行うための外部端末４０を用意し、解析予測ＡＰ４が検出した障害の兆候の情報を外部端末４０へ送り、外部端末４０からこの障害に対する対応操作を行うことを可能とすると共に、自己回復不能な障害が予測された場合に外部に対応を求めることができるようにしたものである。

前記の外部端末４０と計算機２０とはネットワーク４１用いて通信を行うことが可能であり、相互間での情報の授受を行うことができる。ネットワーク４１は、第２ＯＳ２のみから利用することができる第２通信装置４３に接続されている。このようにすることにより、第１ＯＳ１が用いている第１通信装置４２に障害の兆候が現れていても、第２ＯＳ２から安全にネットワーク４１を用いることが可能である。また、この第２の実施形態は、第１ＯＳ１と第２ＯＳ２とが同一の第１通信装置４２を共有してコストを削減するように構成することもできるが、この場合、第１通信装置４２の障害以外の障害の兆候が現れた場合にのみ対応することになる。

前述したような本発明の第２の実施形態によれば、第１ＯＳ１に実際の障害が発生する前に、その兆候を検知して、実際に起きうる障害を外部に通知することができ、管理者が外部にいるような場合にも、外部の管理者が適切な対処を行うことができる。

図１０は本発明の第３の実施形態による計算機システムのハードウェア構成を示すブロック図である。図１０に示す第３の実施形態は、前述の第２の実施形態による計算機システムを複数連結して、サービスをフェイルオーバする構成としたものである。なお、第３の実施形態におけるハードウェア構成以外の部分の構成及び動作は、第１の実施形態の場合と同一である。

図１０に示す第３の実施形態による計算機システムは、通常時におけるサービスを行う現用系の第１計算機５０と第１計算機５０の代用が可能な待機系の第２計算機５１とにより構成される。そして、第１計算機５０と第２計算機５１との間は、第１、第２の計算機のそれぞれが持つ第２ＯＳ２からしか使用することができない通信装置４３によってネットワーク４１を介して接続されている。前述の通信装置４３から接続されたネットワーク４１には、管理用の外部端末４０が接続されている。また、第１計算機５０と第２計算機５１との間では、外部記憶装置２３を共有している。

前述したように構成される第３の実施形態による計算機システムにおいて、第１計算機５０の第１ＯＳ１に障害の兆候が検出されたとき、第１計算機５０内の解析予測ＡＰ４は、障害が起きる前に、第１計算機５０内の第２通信装置４３を通じて、第２計算機５１に第１計算機５０に生起した障害の兆候と、その履歴や状態とを知らせる。第２計算機５１は、これらの情報から第１計算機５０の障害に備え、サービス引き継ぎのための処理を行う。また、第２計算機５１は、これらの情報から自計算機での同様の障害の発生に対応することができる。例えば、第２計算機５１は、障害が起きる可能性がある場合、第１計算機５０側のＯＳ状態情報１１や動作記録情報１２、前状態情報保持部１６、ＡＰ状態情報１７を、予め第２計算機５１の解析予測ＡＰ４に送信しておき、障害につながる動作を解析しておくことにより、第２計算機５１の第１ＯＳ１で第１計算機５０と同じ障害が発生することを未然に防ぐことができる。

図１１は前述した本発明の第３の実施形態でのサービス引継ぎのための処理動作を説明するフローチャートであり、次に、これについて説明する。

（１）第１計算機５０の第１ＯＳ１に障害が検出されたとき、第１計算機５０内の解析予測ＡＰ４は、まず、外部端末４０に切り替えの開始を送信し、第１計算機５０内のサービスＡＰ３のサービスを再開させるために、ＡＰ状態情報１７を第２計算機５１に送信する（ステップ１４０、１４１）。

（２）その後、第１計算機５０と第２計算機５１とは、ネットワークの設定の引き継ぎと、外部記憶装置の引き継ぎとを行い、最後に、第２計算機５１に動作を切り替えて、第１計算機５０の第１第１ＯＳ１を停止する（ステップ１４２〜１４５）。

前述したサービス引継ぎの処理では、最初に、外部端末４０に切り替えの開始を送信するとして説明したが、前述した切り替えの処理が終了した後、第２計算機５１の第２ＯＳ２から第１計算機５０の第１ＯＳ１の障害報告を外部端末４０に送信するようにしてもよい。

引き継ぎのための情報の第２計算機５１への送信は、障害の兆候の情報を第２計算機５１に送信したときと同様に、第２通信装置４３を介して行われる。

また、前述した本発明の第３の実施形態において、第１、第２の計算機５０、５１内の第２通信装置４３を第１ＯＳが使用する第１通信装置４２と共用して、前述した障害の兆候の情報、引き継ぎのための情報を送信するようにすることもできる。これにより、それぞれの計算機内に通信装置４３を別に用意する必要がなくなる。

また、前述した本発明の第３の実施形態において、ディスクの状態を引き継ぐ必要がない場合、外部記憶装置２３を共有せず、それぞれ個別の外部記憶装置２３を持つようにすることも可能である。この場合、図１１に示すフローのステップ１４３の処理の実行を省略することができる。

また、前述した本発明の第３の実施形態において、待機系となるの第２計算機５１における電力消費を抑えるため、障害による引継ぎが行われるまで第２計算機５１の電源を切っておくことが可能である。この場合、本発明により第１計算機５０で障害が予想されたときに、第２計算機５１を起動し、障害が発生する前に引き継ぎ動作を行うことによりサービスの停止時間を最小に抑えることができる。

前述したような構成を持つ本発明の第３の実施形態によれば、現用系の計算機における第１ＯＳ１に回避不可能な障害が予測された場合にも、業務を行うサービスＡＰ３の業務処理を、待機系の計算機により継続し続けることができる。

前述した本発明の第３の実施形態は、計算機として独立した２台の計算を現用系、待機系として使用するとして説明したが、本発明は、計算機として、論理分割制御部を有する仮想計算機を用い、マルチＯＳ制御部５として、仮想計算機を構築する論理分割制御部を用いるように構成することもできる。

前述の論理分割制御部については、ＯＳシリーズ第１１巻ＶＭ（岡崎世雄・全先実著：共立出版）（以下、文献２という）に仮想計算機の制御部（ＣＰ）として紹介されている。この文献２によれば、ＣＰは、仮想計算機への仮想的な物理メモリ割り当て状態を表すシャドウ・テーブルや、仮想ＣＰＵのレジスタの状態を表すＶＭＢＬＯＫを有する。

図１２は本発明の第４の実施形態による計算機システムのプログラム構成を示すブロック図である。図１２に示す第４の実施形態は、マルチＯＳ制御部５に代わって前述した論理分割制御部を利用して構成したものである。図１２に示す本発明の第４の実施形態で利用する論理分割制御部６０は、論理分割を行って仮想計算機システムを構成する際に通常設けられているもので、前述したシャドウ・テーブルやＶＭＢＬＯＫを取得することのできるＯＳ状態取得部５９及び他のＯＳの実行を制御するＯＳ実行制御部５８を備えると共に、本発明のためにメモリ取得部８とＯＳ間メッセージ通信部９とを備えている。また、第４の実施形態による計算機システムを構成する各プログラムは、メモリ２１の中に格納されている。

本発明の第４の実施形態による計算機システムは、論理分割制御部６０を用いるため、この計算機上で同時に動作するＯＳは２つ以上存在する。このうち、通常業務を行うサービスＡＰ３が動作するＯＳ群に属するＯＳを第１ＯＳ１とし、解析予測ＡＰ４が動作するＯＳ群に属するＯＳを第２ＯＳ２とする。そして、前述の第１ＯＳ１と第２ＯＳ２とを１つずつセットにしたものを、仮想マルチＯＳセットとし、任意のｎ個の仮想マルチＯＳセットである第１仮想マルチＯＳセット６１〜第ｎ仮想マルチＯＳセット６ｎを実現する。

論理分割制御部６０は、各仮想マルチＯＳセット６１〜６ｎに属する第１ＯＳ１と第２ＯＳ２とを、交互に切り替えながら実行する。このため、解析予測ＡＰ４が動作している間、監視の対象となる第１ＯＳ１の動作を確実に止めることができる。これにより、解析予測ＡＰ４が第１ＯＳ１の状態を解析する間、第１ＯＳ１が動作して勝手にメモリ上のデータを書き換えることを防止することができる。

前述したような構成を有する本発明の第４の実施形態によれば、論理分割制御部６０を持った計算機上でもマルチＯＳ環境を実現することができる。

図１３は本発明の第５の実施形態による計算機システムのプログラム構成を示すブロック図である。図１３に示す第５の実施形態は、前述した第４の実施形態における仮想マルチＯＳセットを複数個まとめて障害対応グループを作ることにより構成した例である。

図１３に示す第５の実施形態は、複数の障害対応グループ７１〜７ｎと図１２に示す場合と同様に構成される論理分割制御部６０とにより構成され、第１〜第ｎの複数の障害対応グループ７１〜７ｎのそれぞれは、２つ以上（図には２つだけ示している）の仮想マルチＯＳセット６１、６２〜６ｎ１、６ｎ２により構成されている。各仮想マルチＯＳセットのうち、通常時にサービスを行う第１ＯＳ１を持っているものを現用系システム、現用系の障害発生時にサービスを引き継ぐの他方のものを待機系システムとする。いま、第１障害対応グループ７１の現用系システムである仮想マルチＯＳセット６１で障害が予測された場合、同一グループの待機系システムである仮想マルチＯＳセット６２へサービスの引継ぎが行われる。サービス引継ぎのための通信には、論理分割制御部６０内のＯＳ間メッセージ通信部９が用いられる。

前述したような構成を有する本発明の第５の実施形態によれば、物理的な計算機の台数を増加させることなく、サービスを安定して提供し続けることのできる計算機システムを構築することが可能となる。

図１４は本発明の第６の実施形態による計算機システムのプログラム構成を示すブロック図である。図１４に示す第６の実施形態は、前述した第５の実施形態における１つの仮想マルチＯＳセット６１を、現用系の第１ＯＳ６１１と待機系の第１ＯＳ６２１と、１つの第２ＯＳ２及び解析予測ＡＰ４とにより構成したものである。

すなわち、図１４に示す第６の実施形態は、１つの仮想マルチＯＳセット６１を、現用系の第１ＯＳ６１１と待機系の第１ＯＳ６２１とで、１つの第２ＯＳ２及び解析予測ＡＰ４を共有するように構成される。そして、解析予測ＡＰ４が現用系の第１ＯＳ６１１やサービスＡＰ６１３に障害を予測した場合、通信装置の代わりに、図１４には示していない図１２の場合と同様に構成される論理分割制御部６０内のＯＳ間メッセージ通信部９により待機系の第１ＯＳ６２１及びサービスＡＰ６２３にサービスの引継ぎを行った後、ＯＳ実行制御部５８を使用して現用系の第１ＯＳ６１１を止めて、代わりに待機系の第１ＯＳ６２１を実行する。

図１４に示した本発明の第６の実施形態は、論理分割された仮想計算機システムにより構成されるとして説明したが、論理分割しなくても、メモリ内に２つの第１ＯＳと、１つの第２ＯＳを格納して、図２に示す場合と同様に構成することもできる。

図１５は本発明の第６の実施形態で解析予測ＡＰ４が使用するデータテーブルを示す図である。

図１４に示した本発明の第６の実施形態は、１つの解析予測ＡＰ４に対して、解析対象となる第１ＯＳ１が１またはそれ以上存在する場合、解析に用いる障害兆候表１３や障害対処表１０、対処プログラム表１４、情報アドレス変換表１５として、対象となるＯＳ毎に別々のものを用いることにより、解析対象の数の多さに対処する。例えば、対象となる第１ＯＳが２つである場合、解析予測ＡＰ４は、図１５に示すように、それぞれの第１ＯＳに応じた第１データセット８０及び第２データセット８１を持つことにより、異なる２つの第１ＯＳに対応する。各データセット８０、８１の内容は、図６〜図８により説明したものと同様である。

前述したような構成を有する本発明の第６の実施形態によれば、第２ＯＳ２の数を抑えることができるため、第２ＯＳや解析予測ＡＰが利用するメモリやディスク等のリソースを少なくすることができる。

また、第６の実施形態の変形例として、複数の第１ＯＳ１と単体の第２ＯＳ２とによりシステムを構成し、単体の第２ＯＳ２上で複数の解析予測ＡＰ４を動かす方法がある。この例によれば、解析対象ＯＳがあまり多くない場合、第２ＯＳ２の数を抑えることができる。

なお、前述で説明した本発明の第４〜第６の実施形態による計算機システムは、そのハードウェア構成としては、第１の実施形態で説明したものと実質的に同一でよく、また、各実施形態で説明した以外の詳細な動作等も、第１の実施形態で説明したものと実質的に同一である。

図１６は本発明の第１の実施形態による計算機システムの変形例によるメモリの内部に格納されるプログラムの構成を示す図である。

本発明の第１の実施形態では、１つのメモリ内にＡＰ、ＯＳ等の全てのプログラムを格納するとして説明したが、本発明は、マルチＯＳを構成する際に、図１６に示すように第２ＯＳ２と解析予測ＡＰ４とを、第１ＯＳ１を格納するメモリ２１から物理的に隔離した第２メモリ２２１を設けて格納し、第２ＯＳへの切り替えを、ハードウェア動作制御部２０５によって行う行うように構成することもできる。

本発明の第１の実施形態による計算機システムのハードウェア構成を示すブロック図である。 メモリ２１の内部に格納されるプログラムの構成を示す図である。 メモリ２１に格納される各プログラム内に設けられるデータテーブルの構成を示す図である。 第２ＯＳ２が情報アドレス変換表１５を作成、更新する際の処理動作を説明するフローチャートである。 第２ＯＳ２上の解析予測ＡＰ４の処理動作を制御するフローチャートである。 障害兆候表１３の構成を示す図である。 対処プログラム表１４の構成を示す図である。 情報アドレス変換表１５の構成を示す図である。 本発明の第２の実施形態による計算機システムのハードウェア構成を示すブロック図である。 本発明の第３の実施形態による計算機システムのハードウェア構成を示すブロック図である。 本発明の第３の実施形態でのサービス引継ぎのための処理動作を説明するフローチャートである。 本発明の第４の実施形態による計算機システムのプログラム構成を示すブロック図である。 本発明の第５の実施形態による計算機システムのプログラム構成を示すブロック図である。 本発明の第６の実施形態による計算機システムのプログラム構成を示すブロック図である。 本発明の第６の実施形態で解析予測ＡＰ４が使用するデータテーブルを示す図である。 本発明の第１の実施形態による計算機システムの変形例によるメモリの内部に格納されるプログラムの構成を示す図である。

符号の説明

１ 第１ＯＳ
２ 第２ＯＳ
３ サービスＡＰ
４ 解析予測ＡＰ
５ マルチＯＳ制御部
６ 動作記録制御部
７ 補助ドライバ
８ メモリ取得部
９ ＯＳ間メッセージ通信部
１０ マルチＯＳ制御部インタフェース
１１ ＯＳ状態情報
１２ 動作記録情報
１３ 障害兆候表
１４ 対処プログラム表
１５ 情報アドレス変換表
１６ 前状態情報保持部
１７ ＡＰ状態情報
１８ ページ変換テーブル
２０ 計算機
２１ メモリ
２２ ＣＰＵ
２３ 外部記憶装置
２４ キーボード
２５ マウス
２６ 冷却装置
２７ 温度センサ
２８ 通信装置
２９ 画面出力装置
４０ 外部端末
４１ ネットワーク
４２ 第１通信装置
４３ 第２通信装置
５０ 第１計算機
５１ 第２計算機
６０ 論理分割制御部
６１ 第１仮想マルチＯＳセット
６２ 第２仮想マルチＯＳセット
６ｎ 第ｎ仮想マルチＯＳセット
７１ 第１障害対応グループ
７ｎ 第ｎ障害対応グループ
８０ 第１データセット
８１ 第２データセット
２０５ ハードウェア動作制御部
２２１ 第２メモリ

Claims (10)

1. 第１のＯＳと、該第１のＯＳ上で動作し通常の業務処理を行うサービスアプリケーションと、前記第１のＯＳとは異なる第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記第１のＯＳは、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションは、前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知することを特徴とする計算機システム。
2. 前記第１のＯＳは、解析予測アプリケーションの補助を行う補助プログラムを有し、前記解析予測アプリケーションは、解析すべきメモリの位置と解析方法、及び、障害に対して行うべき処理の一覧を保持し、前記補助プログラムは、前記処理の一覧の内容に従い、障害の兆候によって、第１のＯＳの障害に対する処理を行うことを特徴とする請求項１記載の計算機システム。
3. 前記解析予測アプリケーションは、外部端末に対して解析した障害の兆候の内容を通知することを特徴とする請求項１記載の計算機システム。
4. 第１のＯＳと、該第１のＯＳ上で動作し通常の業務処理を行うサービスアプリケーションと、前記第１のＯＳとは異なる第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記第１のＯＳが、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションが、前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知する構成の計算機を複数台備え、１つの計算機の解析予測アプリケーションが、自己回復不能な障害の兆候を検知した場合、他の計算機に解析した障害の内容を通知し、処理を受け継がせることを特徴とする計算機システム。
5. 複数の第１のＯＳと、該複数の第１のＯＳのそれぞれの上で動作し通常の業務処理を行う複数のサービスアプリケーションと、前記第１のＯＳとは異なる１つの第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記複数の第１のＯＳのそれぞれは、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションは、前記複数第１のＯＳのそれぞれが保持する情報の内容を解析して障害の兆候を検知することを特徴とする計算機システム。
6. 第１のＯＳと、該第１のＯＳ上で動作し通常の業務処理を行うサービスアプリケーションと、前記第１のＯＳとは異なる第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記第１のＯＳが、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションが、前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知する構成の計算機を、論理分割により仮想マルチＯＳセットとして複数台構成し、前記複数の仮想マルチＯＳセットのそれぞれの第１のＯＳと第２のＯＳとが交互に切り替えられて動作を実行し、前記複数の仮想マルチＯＳセットそれぞれの解析予測アプリケーションが、自セットの前記第１のＯＳが保持する情報の内容を解析して障害の兆候を検知することを特徴とする計算機システム。
7. 前記複数の仮想マルチＯＳセットの１つの解析予測アプリケーションが、自セットの前記第１のＯＳでの障害の兆候を検知した場合、他の仮想マルチＯＳセットに解析した障害の内容を通知し、処理を受け継がせることを特徴とする請求項６記載の計算機システム。
8. 複数の第１のＯＳと、該複数の第１のＯＳのそれぞれの上で動作し通常の業務処理を行う複数のサービスアプリケーションと、前記第１のＯＳとは異なる１つの第２のＯＳと、該第２のＯＳ上で動作する解析予測アプリケーションとを備え、前記複数の第１のＯＳのそれぞれが、自ＯＳの状態情報と動作記録情報とを保持し、前記解析予測アプリケーションが、前記複数第１のＯＳのそれぞれが保持する情報の内容を解析して障害の兆候を検知する構成の計算機を、論理分割により仮想マルチＯＳセットとして構成し、前記マルチＯＳセットの解析予測アプリケーションが、前記第１のＯＳでの障害の兆候を検知した場合、他方の第１のＯＳに処理を受け継ぐことを特徴とする計算機システム。
9. 第１のＯＳとは異なる第２のＯＳ上で動作する解析予測アプリケーションが、第１のＯＳが保持している状態情報と動作記録情報との内容を解析して障害の兆候を検知することを特徴とする計算機システムの障害兆候の検知方法。
10. 前記解析予測アプリケーションは、解析すべきメモリの位置と解析方法、及び、障害に対して行うべき処理の一覧を保持し、前記第１のＯＳが有する解析予測アプリケーションの補助を行う補助プログラムを使用して、前記処理の一覧の内容に従い、障害の兆候によって、第１のＯＳの障害に対する処理を行うことを特徴とする請求項９記載の計算機システムの障害兆候の検知方法。
    

Images