(57)【要約】【課題】各種デバイスとの接続バスが正常に動作しているかを監視するバスモニタリングと解析を、監視用ＣＰＵを要さず、ＯＳ自身が処理できない異常が発生した際でも解析用ボードから取得した情報を元に障害解析と障害処理を行う。【解決手段】情報処理装置のシステムバス（ＰＣＩバス）１１５に接続され、各種デバイスとの接続バス（ＩＤＥ１２１、ＳＣＳＩバス１１６）が正常に動作しているかを監視するためのバスのモニタリングおよび解析機能を有するバスモニタ１１３と、ハードウェアからの割り込みやＣＰＵの処理時間を振り分ける機能を持つ仮想ハードウェア１３２により、複数のＯＳに対しハードウェア資源を分離独立させる機能１３１と、複数ＯＳ間でデータ書込みまたは読み出しを可能とする機能１３１を備え、通常動作しているＯＳとは独立したＯＳ上でバスの監視および解析を行うモニタリングプログラム１３４を実行させる。【選択図】　　　　図１
2004030513.tif 000002
【特許請求の範囲】
【請求項１】
各種デバイスとの接続バスのモニタリングおよび解析を行う解析用バスモニタと、ハードウェアからの割り込みやＣＰＵの処理時間を振り分ける仮想ハードウェアにより、複数のＯＳに対しハードウェア資源を分離独立させる手段と、複数ＯＳ間でデータの書込みまたは読み出しを行う複数ＯＳ制御プログラムを備えたマルチＯＳ環境の情報処理装置からなるバスモニタリングシステムであって、
通常動作しているＯＳとは別のＯＳ上で動作し、上記解析用バスモニタの制御を行い、バスのモニタリングおよび異常検出を行うバスモニタ監視プログラムを具備することを特徴としたバスモニタリングシステム。
【請求項２】
請求項１記載のバスモニタリングシステムにおいて、
前記バスモニタリング監視用プログラムは、通常動作しているＯＳの種別に依存しないことを特徴とするバスモニタリングシステム。
【請求項３】
情報処理装置に対し、業務ＯＳ基本部の処理と、ハードウェア制御を行うハードウェアドライバ群の処理と、ＳＣＳＩバスモニタを制御するためのＳＣＳＩバスモニタ管理ＡＰの処理と、ハードウェア内にロギングされる障害情報を編集出力するためのＬＯＧ制御ＡＰの処理と、ＩＥＤバスモニタを制御するＩＤＥバスモニタ管理ＡＰの処理と、これらの各ＡＰによる編集結果をＬＡＮ経由でクライアントＰＣ側からの制御で行うためのリモート制御ＡＰの処理を、それぞれ実行させるためのモニタ監視用プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置の入出力バスモニタリングシステムおよびそのプログラムに関し、特にマルチＯＳ環境の情報処理装置で、通常のＯＳとは別のＯＳ上で動作する監視プログラムにより制御されるバスモニタを組込んだ情報処理装置およびプログラムに関する。
【０００２】
【従来の技術】
従来のバスモニタ装置としては、例えば特開平７−３１９８０４号公報に示すＳＣＳＩバスモニタ装置及びバスモニタシステムがある。これは、バス受信部で取込まれたＳＣＳＩ信号の遷移から記録すべき事象を検出するイベント検出手段と、この状態をトレースデータとして順次記録するトレースメモリとを設けて、記憶量が設定値を超えたとき、警報を出力するとともにバスに対してビジー信号を出力し、その間にトレースデータを外部へ転送するものである。すなわち、監視対象のバスライン（ＳＣＳＩバス）に接続したアダプタを介してＳＣＳＩバスモニタ装置に信号を取り込み、モニタ装置内で処理したトレース情報をホスト収集装置（トレースメモリ）に送り、オペレータがホスト収集装置に含まれるキーボードの操作等により情報を解析していた。
【０００３】
また、特開平１０−２２２４３２号公報に示すＳＣＳＩバスモニタリングシステムでは、ＳＣＳＩバス監視部がＳＣＳＩバスの監視を随時行い、バス情報解析部ではバスの信号情報をデータとして提供可能な形に変換する。バスモニタデーモンは、定期的にバスモニタに対してＳＣＳＩコマンドを発行することにより、ＳＣＳＩバスの情報を取得して、システムにフィードバックさせる。すなわち、ＳＣＳＩバスモニタにＳＣＳＩ装置としての機能を組込み、ホストコンピュータから操作可能とし、ＳＣＳＩバスモニタから取得したＳＣＳＩバス情報をもとに、ＳＣＳＩバスの性能向上を図っている。
【０００４】
【発明が解決しようとする課題】
しかしながら、これらの従来技術では、監視用の別のホスト収集装置が必要であったり、ＯＳ自身が検知できない異常でホストコンピュータのプログラムがハングアップした場合などは、ＳＣＳＩバスモニタに採取された情報が利用できないという問題がある。
また、特開平１０−２２２４３２号公報では、使用するＯＳ毎にＳＣＳＩバスモニタを制御するプログラムを開発しなければならないという問題もある。
【０００５】
本発明の目的は、このような従来の問題を解消し、監視用のＣＰＵを必要とせず、通常のＯＳがハングアップやシステム停止してしまった場合などでも、バスモニタに採取された情報を利用できる安価で確実な障害解析および回復手段を備えたバスモニタリングシステムおよびそのプログラムを提供することにある。
【０００６】
【課題を解決するための手段】
上記目的を達成するため、本発明のバスモニタリングシステムは、情報処理装置のシステムバス（ＰＣＩバス）に接続され、各種デバイスとの接続バス（ＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ　Ｄｅｖｉｃｅ　Ｅｌｅｃｔｒｏｎｉｃｓ）、ＳＣＳＩバス）が正常に動作しているか否かを監視するためのバスのモニタリングおよび解析機能を有するバスモニタと、ハードウェアからの割り込みやＣＰＵの処理時間を振り分ける機能を持つ仮想ハードウェアにより複数のＯＳに対しハードウェア資源を分離独立させる機能と、複数ＯＳ間でデータ書込みまたは読み出しを可能とする機能とを備えたマルチＯＳ環境の情報処理装置において、通常のＯＳとは独立したＯＳ上で動作する前記バスモニタを制御するためのモニタリングプログラムを実行させるようにしている。
これにより、通常のＯＳ自身が処理できないような異常が発生した場合でも、監視用の別ＣＰＵが無くてもモニタリングプログラムからの情報により的確な障害解析および対策が可能となる。また、仮想ハードウェアを用いることにより、ＯＳに依存しないでバスモニタを制御するための監視プログラムを開発することが可能となる。
【０００７】
本発明のモニタ監視プログラムは、情報処理装置に対し、業務ＯＳ基本部の処理と、ハードウェア制御を行うハードウェアドライバ群の処理と、ＳＣＳＩバスモニタを制御するためのＳＣＳＩバスモニタ管理ＡＰの処理と、ハードウェア内にロギングされる障害情報を編集出力するためのＬＯＧ制御ＡＰの処理と、ＩＥＤバスモニタを制御するＩＤＥバスモニタ管理ＡＰの処理と、これらの各ＡＰによる編集結果をＬＡＮ経由でクライアントＰＣ側からの制御で行うためのリモート制御ＡＰの処理とを、それぞれ実行させるためのプログラムである。
【０００８】
【発明の実施の形態】
以下、本発明の実施形態を、図面により詳細に説明する。
図１は、本発明の一実施形態を示す監視対象バスをＳＣＳＩバスとしたバスモニタリングシステムの構成図である。
図１において、ソフトウェア１３０は、業務側プログラム１３３と監視側プログラム１３４の２つからなり、ハードウェア１０１は、業務側プログラム１３３と監視側プログラム１３４から仮想ハードウェア１３２としてそれぞれにアクセスされる。
複数ＯＳ制御プログラム１３１は、ハードウェア１０１からの割り込みやＣＰＵ１０８の処理時間を業務側プログラム１３３と監視側プログラム１３４に振り分ける機能があり、仮想ハードウェア１３２を各ＯＳに対しハードウェアのように見せることで、業務側プログラム１３３から見えるハードウェア資源と監視側プログラム１３４から見えるハードウェア資源とを分離独立させている。
【０００９】
また、複数ＯＳ制御プログラム１３１は、複数ＯＳ間でデータの書き込みまたは読み出しを可能とする機能も有する。これらの機能により、１つのハードウェア上で複数のＯＳが互いに独立して実行することを実現している。ここで実施しているような１つのハードウェアで複数のＯＳを独立に実行する技術は、特開平１１−１４９３８５号公報に開示されている。これによれば、業務側プログラム１３３と監視側プログラム１３４を独立実行でき、業務側プログラム１３３が障害で停止した場合でも、監視側プログラム１３４は継続して動作できる。
【００１０】
ハードウェア１０１は、ＣＰＵ１０８、主メモリ１０９、ＳＣＳＩＡ１１２、ＳＣＳＩバスモニタ１１３、ＬＡＮＡ１１４、各種デバイスを制御するためのＳｕｐｅｒＩＯ１１１、各バスを制御するシステムバスコントローラ１２０が、それぞれＰＣＩバス１１５に接続されている。システムバスコントローラ１２０には、ＣＲＴＡ１１０が接続され、ＣＲＴ１０７への表示制御を行う。また、システムバスコントローラ１２０は、ＩＤＥバス１２１の制御も行う。ＳｕｐｅｒＩＯ１１１へは、キーボード１０５およびマウス１０６が接続される。
ＳＣＳＩＡ１１２には、ＳＣＳＩバス１１６を介してＨＤＤ（ハードディスク）１０２〜１０４が接続される。なおＨＤＤの台数は、本実施例では３台としたが、この台数に限定されるものではない。このＳＣＳＩバス１１６の状態遷移をモニタリングできるように、ＳＣＳＩバスモニタ１１３も接続されている。
また、ＬＡＮ１２２を介して、複数台のクライアントＰＣが接続される。本実施例においては、クライアントＰＣ１１７〜１１９の３台を接続した例を示している。
【００１１】
図２は、図１における業務側プログラムの構成を示す図である。
業務側プログラム１３３は、図２に示すように、業務ＯＳ基本部２０１、ハードウェア制御を行うハードウェアドライバ群２０２、業務用の各種アプリケーションプログラムからなる業務ＡＰ２０３、ＣＰＵ１０８やハードウェアドライバ群２０２から報告されたエラーのロギングや通知を行うシステム管理用アプリケーションであるシステム管理ＡＰ２０４、およびＬＡＮ１２２を介してクライアントＰＣ１１７〜１１９との通信を行うリモート制御ＡＰ２０５で構成されている。
【００１２】
図３は、図１における監視側プログラムの構成を示す図である。
監視側プログラム１３４は、図３に示すように、業務ＯＳ基本部３０１、ハードウェア制御を行うハードウェアドライバ群３０２、ＳＣＳＩバスモニタ１１３を制御するためのＳＣＳＩバスモニタ管理ＡＰ３０３、ハードウェア１０１内にロギングされる障害情報を編集出力するためのＬＯＧ制御ＡＰ３０４、ＩＤＥバスモニタ９０１（図９参照）を制御するＩＤＥバスモニタ管理ＡＰ３０６、および、これらの各ＡＰによる編集結果をＬＡＮ１２２経由でクライアントＰＣ１１７〜１１９側からの制御で行うためのリモート制御ＡＰ３０５からなる。
なお、監視側プログラム１３４の操作はハードウェア１０１に接続されたキーボード１０５、マウス１０６およびＣＲＴ１０７を使用するか、あるいはＬＡＮＡ１１４に接続されたクライアントＰＣの操作による。
本実施例では、クライアントＰＣ１１７を監視側プログラム１３４を操作する管理用ＰＣとして記述する。
【００１３】
図４は、図１におけるＳＣＳＩバスモニタ１１３の構成を示す図である。
ＳＣＳＩバスの信号を受信するためのバスレシーバ４０１、受信したバスの信号をＳＣＳＩバスモニタ１１３の内部タイミングに同期させるためのバス信号ラッチ４０２、バスの状態遷移を記憶するためのトレースメモリ４０９、ＰＣＩバスとの転送制御を行うＰＣＩバス制御部４１０、バスの状態遷移の発生時刻を示すためのタイムスタンプ発生部４０３、トレースメモリ４０９への書き込み停止条件を設定するためのトレース停止条件設定部４０４、トレース停止条件の検出およびバスの状態遷移を検出するイベント検出部４０５、トレースメモリ４０９のアクセスタイミングやアドレス更新タイミングを制御するモニタシーケンサ部４０６、トレースメモリ４０９のアドレスを管理するメモリアドレス制御部４０７、およびＳＣＳＩバスモニタ全体の制御を行うモニタ内部制御部４０８からなる。
【００１４】
図５は、本発明の一実施例のシステム起動手順を示すフローチャートである。
図５により起動処理を説明する。
ハードウェア１０１に電源が投入（またはリブート）されると、業務側プログラム１３３が起動する（ステップ５０１）。業務側プログラム１３３は初期化処理を開始するが、複数ＯＳ制御プログラム１３１により初期化処理を中断し監視側プログラム１３４を起動する（ステップ５０２）。監視側プログラム１３４は、トレースメモリ４０９のクリア（ステップ５０３）、タイムスタンプ発生部４０３の初期設定（ステップ５０４）、トレース停止条件設定部４０４の初期設定（ステップ５０５）を行う。
この時設定されるトレース停止条件は、フリーラン状態（停止条件なし）である。
【００１５】
次に、モニタシーケンサ部４０６を起動し、トレース動作を開始する（ステップ５０６）。その後、リモート制御ＡＰ３０５を入力待ちで起動し、クライアントＰＣ１１７（管理用ＰＣ）からの操作待ちとする（ステップ５０７、ステップ５０８）。この状態で、複数ＯＳ制御プログラム１３１により業務側プログラム１３３に処理が移され、業務側プログラム１３３の起動処理が再開される（ステップ５０９）。次に、業務ＡＰ２０３が起動され、関連する各種情報の初期化が行われる（ステップ５１０）。その後、業務ＡＰ２０３による通常業務が開始される（ステップ５１１）。
【００１６】
図６は、図１、図２におけるＳＣＳＩバス１１６に関する障害が、システム管理ＡＰ２０４よりクライアントＰＣ１１７に通知された場合の処理手順を示すフローチャートである。
システム管理ＡＰ２０４がＳＣＳＩバス１１６に関する障害を、ハードウェアドライバ群２０２と業務ＯＳ基本部２０１の応答をモニタすることにより検出する（ステップ６０１）。システム管理ＡＰ２０４は、障害情報のロギングを行うとともにリモート制御ＡＰ２０５を介してクライアントＰＣ１１７に障害通知する（ステップ６０２）。一般的には、システム管理者がクライアントＰＣ１１７の情報から障害解析を行う（ステップ６０３）。この段階で障害要因を特定できれば、それに基づき適切な対策を実施する。システム管理ＡＰ２０４より通知された情報では要因が特定できない場合、システム管理者が、クライアントＰＣ１１７よりＳＣＳＩバスモニタ管理ＡＰ３０３をアクセスし、ＳＣＳＩバスモニタの動作モードを指定する（ステップ６０４）。
【００１７】
ステップ６０４により動作パラメータを指定されたＳＣＳＩバスモニタ管理ＡＰ３０３は、まずモニタシーケンサ部４０６の停止指示を行う（ステップ６０５）。次に、トレース停止条件設定部４０４にチェックコンデション状態検出（エラー応答）などのステップ６０４で指定された停止条件を設定する（ステップ６０６）。そしてモニタシーケンサ部４０６を起動し、トレース動作を開始する（ステップ６０７）。監視側プログラム１３４は、イベント待ちの状態に入り休止状態となる（ステップ６０８）。これら監視側プログラム１３４の動作は、複数ＯＳ制御プログラム１３１により業務側プログラム１３３とは独立して実行される。
【００１８】
図７は、ＣＳＩバスモニタが設定された停止条件を検出された場合の処理フローチャートである。
イベント検出部４０４は、バス信号ラッチ４０２の出力とトレース停止条件設定部４０６の出力を比較し停止条件が成立したことを検出する（ステップ７０１）。この結果、モニタシーケンサ部４０６によるトレースメモリ４０９へのＳＣＳＩバス信号状態の書き込みを停止する（ステップ７０２）。ＳＣＳＩバスモニタ１１３からの割り込みにより、ＳＣＳＩバスモニタ管理ＡＰ３０３に停止条件成立が通知される（ステップ７０３）。ＳＣＳＩバスモニタ管理ＡＰ３０３は、ＰＣＩバス１１５を介してトレースメモリ４０９の内容を主メモリ１０９の所定のエリアに読み出す（ステップ７０４）。その後、ＳＣＳＩバスモニタ管理ＡＰ３０３は主メモリ１０９上でトレースデータを編集し、結果をリモート制御ＡＰ３０５を介してクライアントＰＣ１１７に転送する（ステップ７０５）。システム管理者は、クライアントＰＣ１１７に転送されたトレースの内容を解析し、障害対策を実施する（ステップ７０６）。
業務側プログラム１３３の業務ＯＳ基本部２０１自身が処理できないような異常が発生した場合、業務側プログラム１３３は、停止状態などの機能不能状態に遷移してしまう場合がある。
【００１９】
図８は、業務側プログラム停止障害時の処理フローチャートである。
システム管理者がクライアントＰＣ１１７の操作によりＳＣＳＩバスモニタ管理ＡＰ３０３モニタ停止、およびトレースデータ転送を指定する（ステップ８０１）。モニタ停止を指示されたＳＣＳＩバスモニタ管理ＡＰ３０３が、モニタシーケンサ部４０６に停止の設定を行う（ステップ８０２）。モニタシーケンサ部４０６によるトレースメモリ４０９へのＳＣＳＩバス信号状態の書き込みが停止される（ステップ８０３）。ＳＣＳＩバスモニタ管理ＡＰ３０３は、ＰＣＩバス１１５を介してトレースメモリ４０９の内容を主メモリ１０９の所定のエリアに読み出す（ステップ８０４）。その後、ＳＣＳＩバスモニタ管理ＡＰ３０３は主メモリ１０９上でトレースデータを編集し、結果をリモート制御ＡＰ３０５を介してクライアントＰＣ１１７に転送する（ステップ８０５）。システム管理者は、クライアントＰＣ１１７に転送されたトレースの内容を解析し障害対策を実施する（ステップ８０６）。
【００２０】
業務側プログラム１３３の業務ＯＳ基本部２０１自身が処理できないような異常がＳＣＳＩバス１１６のシーケンス以外の原因と考えられる場合、システム管理者はクライアントＰＣ１１７の操作によりＬＯＧ制御ＡＰ３０４をアクセスしハードウェア１０１内にロギングされている各種ハードウェアログログの編集出力を行う。このようにして得られた情報を解析することにより、障害要因を判断し、適切な対策を実施する。
【００２１】
また、本実施例では、ＳＣＳＩバスモニタ１１３の制御をＳＣＳＩバスモニタ管理ＡＰ３０３でのみ行っているが、複数ＯＳ制御プログラム１３１の仮想ハードウェア１３２の設定を変更することで、システム管理ＡＰ２０４側から行えるようにすることもできる。システム管理ＡＰ２０４に、ＳＣＳＩバス１１６に関する障害検出時、自動的にＳＣＳＩバスモニタ１１３の制御を行う機能を組み込むことにより、システム管理者の操作を介入させずにＳＣＳＩバス１１６の状態情報を採取することが可能になる。
【００２２】
図９は、本発明によるＩＤＥバスをトレースする場合の追加構成を示す図である。
本実施例では、ＳＣＳＩバス１１６のモニタリングを行うことを例にしたが、図９に示すようにＩＤＥバスモニタ９０１を接続し、監視側プログラム１３４にＩＤＥバスモニタ管理ＡＰを組み込むことでＩＤＥバスの監視を行うことも可能になる。図９において、ＩＤＥバスモニタ９０１は、ＰＣＩバス１１５から制御され、ＩＤＥバス１２１の監視を行う。ＨＤＤ９０２、ＨＤＤ９０３はＩＤＥ　Ｉ／ＦのＨＤＤである。
【００２３】
【発明の効果】
以上説明したように、本発明によれば、マルチＯＳ環境を利用して、通常動作している業務ＯＳとは別のＯＳ上で動作するバスモニタ監視プログラムでバスモニタを制御しているので、業務ＯＳ、業務プログラム自身が処理できないような異常が発生した場合、監視用の別ＣＰＵがなくてもモニタリングプログラムからの情報により的確な障害解析および対策が可能となる。また、仮想ハードウェア方式を用いることにより、業務側プログラムのＯＳ種別に依存することなく、同一の監視側プログラムを使用できる。
【図面の簡単な説明】
【図１】本発明の一実施形態を示すバスモニタリングシステムの構成図である。
【図２】図１における業務側プログラムの構成を示す図である。
【図３】図１における監視側プログラムの構成を示す図である。
【図４】図１におけるＳＣＳＩバスモニタの構成を示す図である。
【図５】本発明の一実施例を示すシステムの起動手順を示すフローチャートである。
【図６】本発明における障害検出時の処理フローチャートである。
【図７】本発明におけるトレース停止条件検出時の処理フローチャートである。
【図８】本発明における業務側プログラム停止障害時の処理フローチャートである。
【図９】本発明によりＩＤＥバスをトレースする場合の追加構成を示す図である。
【符号の説明】
１０１…ハードウェア、１０２〜１０４…ＨＤＤ（ハードディスク）、
１０５…キーボード、１０６…マウス、１０７…ＣＲＴ、１０８…ＣＰＵ、
１０９…主メモリ、１１０…ＣＲＴＡ、１１１…Ｓｕｐｅｒ　ＩＯ、
１１２…ＳＣＳＩＡ、１１３…ＳＣＳＩバスモニタ、１１４…ＬＡＮＡ、
１１５…ＰＣＩバス、１１６…ＳＣＳＩバス、
１１７〜１１９…クライアントＰＣ、１２０…システムバスコントローラ、
１２１…ＩＤＥバス、１２２…ＬＡＮ、１３０…ソフトウェア、
１３１…複数ＯＳ制御プログラム、１３２…仮想ハードウェア、
１３３…業務側プログラム、１３４…監視側プログラム、
２０１…業務ＯＳ基本部、２０２…ハードウェアドライバ群、
２０３…業務ＡＰ（ＡＰ：アプリケーションプログラム）、
２０４…システム監視ＡＰ、２０５…リモート制御ＡＰ、
３０１…監視ＯＳ基本部、３０２…ハードウェアドライバ群、
３０３…ＳＣＳＩバスモニタ管理ＡＰ、３０４…ＬＯＧ制御ＡＰ、
３０５…リモート制御ＡＰ、３０６…ＩＤＥバスモニタ管理ＡＰ、
４０１…バスレシーバ、４０２…バス信号ラッチ、
４０３…タイムスタンプ発生部、４０４…トレース停止条件設定部、
４０５…イベント検出部、４０６…モニタシーケンサ部、
４０７…メモリアドレス制御部、４０８…モニタ内部制御部、
４０９…トレースメモリ、４１０…ＰＣＩバス制御部、
９０１…ＩＤＥバスモニタ、９０１，９０２…ＨＤＤ。
【図１】
2004030513.tif 000003
【図２】
2004030513.tif 000004
【図３】
2004030513.tif 000005
【図４】
2004030513.tif 000006
【図５】
2004030513.tif 000007
【図６】
2004030513.tif 000008
【図７】
2004030513.tif 000009
【図８】
2004030513.tif 000010
【図９】
2004030513.tif 000011