(57)【要約】【課題】記憶装置の監視を容易に又は低コストで実現する。【解決手段】データを記憶する記憶装置２と、前記記憶装置２へのアクセスを行なう処理装置１１と、前記処理装置１１及び前記記憶装置２とを含むシステム１の状態に関する状態情報の管理を行なうシステム管理装置６と、所定のプロトコルに従って前記記憶装置２へのアクセス制御を行なう入出力制御部３と、前記入出力制御部３による前記記憶装置２へのアクセスに用いられるデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置２の状態情報を前記システム管理装置６に通知する監視部７と、を有する。【選択図】図２
2015114873.tif 000002
【特許請求の範囲】
【請求項１】
データを記憶する記憶装置と、
前記記憶装置へのアクセスを行なう処理装置と、
前記処理装置及び前記記憶装置とを含むシステムの状態に関する状態情報の管理を行なうシステム管理装置と、
所定のプロトコルに従って前記記憶装置へのアクセス制御を行なう入出力制御部と、
前記入出力制御部による前記記憶装置へのアクセスに用いられるデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する監視部と、を有する
ことを特徴とする、情報処理装置。
【請求項２】
前記監視部は、前記入出力制御部と前記記憶装置との間で送受信されるデータを監視し、前記入出力制御部から前記記憶装置に送信されるデータに前記記憶装置の所定の記憶領域のデータに対するアクセス要求が含まれる場合、当該アクセス要求又は当該アクセス要求に対する前記記憶装置からの応答データに前記所定の情報が含まれるか否かを判定する
ことを特徴とする、請求項１記載の情報処理装置。
【請求項３】
前記所定の記憶領域は、前記記憶装置を含む複数の記憶装置において共通に定義された領域であって前記記憶装置の構成に関する構成情報が格納される領域であり、
前記所定の情報は、前記構成情報に含まれる前記記憶装置の故障の有無に関する情報である
ことを特徴とする、請求項２記載の情報処理装置。
【請求項４】
前記監視部は、前記入出力制御部と前記記憶装置との間で送受信されるデータの監視を通じて、前記所定の領域における前記所定の情報が格納される位置を特定する
ことを特徴とする、請求項２又は請求項３記載の情報処理装置。
【請求項５】
前記監視部は、前記入出力装置と前記記憶装置との間で転送中のデータを取得し、取得したデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する
ことを特徴とする、請求項１〜４のいずれか１項記載の情報処理装置。
【請求項６】
前記システム管理装置から通知された前記システムの状態情報に応じて前記システムの管理者に通知を行なう通知処理部をさらにそなえ、
前記システム管理装置は、前記監視部から通知された前記記憶装置の状態情報を前記システムの状態情報に集約して前記通知処理部へ通知する
ことを特徴とする、請求項１〜５のいずれか１項記載の情報処理装置。
【請求項７】
データを記憶する記憶装置と、前記記憶装置へのアクセスを行なう処理装置と、前記記憶装置の監視を行なう監視部と、をそなえる情報処理装置における監視方法であって、
前記監視部において、
所定のプロトコルに従って前記記憶装置へのアクセス制御を行なう入出力制御部による前記記憶装置へのアクセスに用いられるデータに含まれる所定の情報を検出し、
前記所定の情報に基づく前記記憶装置の状態に関する状態情報を、前記処理装置及び前記記憶装置とを含むシステムの状態情報の管理を行なうシステム管理装置に通知する
ことを特徴とする、監視方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、情報処理装置および監視方法に関する。
【背景技術】
【０００２】
サーバやパーソナルコンピュータ等の情報処理装置では、搭載する各種デバイスのハードウェアを統合して監視するために、個々のデバイスに対応したエージェントが用いられる場合がある。
図８は、情報処理装置１００の構成例を示す図である。情報処理装置１００は、図８に示すように、Redundant Arrays of Inexpensive Disks（ＲＡＩＤ）を構成するHard Disk Drive（ＨＤＤ）やSolid State Drive（ＳＳＤ）等の複数の記憶装置２００をそなえる。記憶装置２００は、Peripheral Component Interconnect Express（ＰＣＩｅ；登録商標）デバイスの一例である。図８の例では、ハードウェアＲＡＩＤが設定される記憶装置２００は、Serial Attached Small Computer System Interface（ＳＡＳ）／Serial Advanced Technology Attachment（ＳＡＴＡ）インタフェースを介してＲＡＩＤコントローラ３１０に接続される。また、ソフトウェアＲＡＩＤが設定される記憶装置２００は、ＰＣＩｅインタフェースを介してＰＣＩｅコントローラ３２０に接続される。
【０００３】
情報処理装置１００のOperating System（ＯＳ）９００では、ＲＡＩＤエージェント５１０やＳＳＤエージェント５２０が、対応するＰＣＩｅデバイス２００用のＲＡＩＤドライバ４１０やＳＳＤドライバ４２０を経由してデバイスからハードウェア情報を取得する。なお、ハードウェア情報には、少なくともＰＣＩｅデバイス２００が正常に動作しているか否か（故障の有無）を示す状態情報が含まれる。プラットフォームエージェント６００は、各ＰＣＩｅデバイス２００のエージェント４１０，４２０からハードウェア情報を収集・集約し、イベントインジケータ７００に渡す。例えば、プラットフォームエージェント６００は、発生イベントをソフトウェア的にSoftware（Ｓ／Ｗ）イベントインジケータ７２０に渡す。或いは、プラットフォームエージェント６００は、発生イベントをBaseboard Management Controller（ＢＭＣ）／Management Board（ＭＭＢ）８００経由でHardware（Ｈ／Ｗ）イベントインジケータ７１０に渡す。なお、ＢＭＣ又はＭＭＢ８００は、情報処理装置１００において発生したイベントを集約して管理する管理装置である。
【０００４】
Ｈ／Ｗイベントインジケータ７１０及びＳ／Ｗイベントインジケータ７２０は、それぞれ発生イベントに応じた処理を実行する。例えばＨ／Ｗイベントインジケータ７１０は、Simple Network Management Protocol（ＳＮＭＰ）トラップやＥ−ｍａｉｌの送信，ハードウェアログの生成，Light Emitting Diode（ＬＥＤ）の制御等を行なう。また、Ｓ／Ｗイベントインジケータ７２０は、ＯＳログの生成，情報処理装置１００のモニタ等の画面上へのポップアップメッセージの表示等を行なう。
【０００５】
なお、関連する技術として、ストレージ装置にサービスプロセッサ（Service Processor；ＳＶＰ）を複数搭載し、複数の処理を複数のＳＶＰに分散する技術が知られている（例えば、特許文献１参照）。これにより、各ＳＶＰの処理を単純化し信頼性の高い監視を行なうことができる。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−１０７０８０号公報
【特許文献２】特表２００７−５１５００２号公報
【特許文献３】特開２００６−３３１３９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
図８に示す情報処理装置１００では、ハードウェア統合監視のために、ＰＣＩｅデバイスごとに専用のエージェントが開発・検証されることになる。また、エージェントは、ＯＳの種類ごと，版数ごとに開発・検証が行なわれることになる。従って、全体の開発コストが増大するという課題がある。
また、ＰＣＩｅデバイス２００のハードウェア，ファームウェア，ドライバ，及びエージェントの各モジュールには、高い互換依存関係があることが多い。いずれか一つのモジュールが新版に更新された場合、全体の互換性を保つために、当該ＰＣＩｅデバイス２００の全モジュールが更新されることになる。また、各ＰＣＩｅデバイス２００のエージェント５１０，５２０とプラットフォームエージェント６００との間にも同様の依存関係があることが多い。結果として、一つのモジュールの改版により、情報処理装置１００における監視モジュール全体の改版が行なわれることになり、管理者によるシステムメンテナンスの大きな負担となるという課題もある。
【０００８】
例えば、ハードウェア故障によりＰＣＩｅデバイス２００が交換され、且つ、交換後のＰＣＩｅデバイス２００が交換前のハードウェア・ファームウェアよりも新版である場合、互換問題の対策のために、速やかにシステム全体の更新が求められることになる。また、例えばＯＳのカーネル版数が更新される場合も同様に、ハードウェア・ファームウェアも含めた全体のモジュール更新が求められることになる。
【０００９】
なお、上述した外部ストレージにＳＶＰを複数搭載する技術では、上記課題については考慮されていない。
このように、エージェントはＯＳ（基本ソフト）の種類や版数，ＰＣＩｅデバイス（記憶装置）のモジュールの版数等に依存するため、エージェントによる記憶装置の監視が困難になる、又は監視コストが増大するという課題がある。
【００１０】
１つの側面では、本発明は、記憶装置の監視を容易に又は低コストで実現することを目的とする。
なお、前記目的に限らず、後述する発明を実施するための形態に示す各構成により導かれる作用効果であって、従来の技術によっては得られない作用効果を奏することも本発明の他の目的の１つとして位置付けることができる。
【課題を解決するための手段】
【００１１】
本件の情報処理装置は、データを記憶する記憶装置と、前記記憶装置へのアクセスを行なう処理装置と、前記処理装置及び前記記憶装置とを含むシステムの状態に関する状態情報の管理を行なうシステム管理装置と、所定のプロトコルに従って前記記憶装置へのアクセス制御を行なう入出力制御部と、前記入出力制御部による前記記憶装置へのアクセスに用いられるデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する監視部と、を有する。
【発明の効果】
【００１２】
一実施形態によれば、記憶装置の監視を容易に又は低コストで実現することができる。
【図面の簡単な説明】
【００１３】
【図１】一実施形態に係る情報処理装置のハードウェア構成例を示す図である。
【図２】図１に示す情報処理装置の機能構成例を示す図である。
【図３】ＤＤＦのデータ構造例を示す図である。
【図４】図１に示すレジスタが格納する監視データの一例を示す図である。
【図５】図１に示すスヌープ処理部によるＰＣＩｅデバイスの監視処理の一例を説明するフローチャートである。
【図６】図１に示すスヌープ処理部によるＰＣＩｅデバイスの監視処理の一例を説明するフローチャートである。
【図７】図１に示すスヌープ処理部によるＰＣＩｅデバイスの監視処理の一例を説明するフローチャートである。
【図８】情報処理装置の構成例を示す図である。
【図９】図８に示す情報処理装置のハードウェア構成例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して実施の形態を説明する。
〔１〕一実施形態
〔１−１〕情報処理装置の構成
以下、図１及び図２を参照して、一実施形態の一例としての情報処理装置１の構成について説明する。図１は、一実施形態に係る情報処理装置１のハードウェア構成例を示す図であり、図２は、図１に示す情報処理装置１の機能構成例を示す図である。
【００１５】
図１に示すように、サーバやパーソナルコンピュータ等の情報処理装置１は、ハードウェア構成として、１以上（図１では複数）の記憶装置２，ＲＡＩＤコントローラ３１，及びＰＣＩｅコントローラ３２をそなえる。また、情報処理装置１は、ハードウェア構成として、Central Processing Unit（ＣＰＵ）１１，１以上（図１では複数）のメモリ１２，Ｈ／Ｗイベントインジケータ５１，ＢＭＣ／ＭＭＢ６，及びスヌープ処理部７をさらにそなえる。
【００１６】
記憶装置２は、例えばＨＤＤ等の磁気ディスク装置、ＳＳＤ等の半導体ドライブ装置、又はフラッシュメモリ等の不揮発性メモリ等、種々のデータやプログラムを格納するハードウェアである。一実施形態に係る記憶装置２は、ＰＣＩｅインタフェース（又は、ＰＣＩｅインタフェース及びＳＡＳ／ＳＡＴＡインタフェース）を介して情報処理装置１に接続されるため、記憶装置２をＰＣＩｅデバイス２とも表記する。
【００１７】
ＲＡＩＤコントローラ３１は、複数のＰＣＩｅデバイス２を用いたＲＡＩＤ構成の管理・制御をハードウェアＲＡＩＤにより行なうスイッチ／コントローラであり、当該複数の記憶装置２をＳＡＳ又はＳＡＴＡインタフェースを介して接続する。ＰＣＩｅコントローラ３２は、ＰＣＩｅ接続が可能なＳＳＤ等の記憶装置２をＰＣＩｅインタフェースを介して接続するスイッチ／コントローラである。なお、ＲＡＩＤコントローラ３１はＰＣＩｅインタフェースを介してＰＣＩｅコントローラ３２と接続される。以下、ＲＡＩＤコントローラ３１及びＰＣＩｅコントローラ３２を特に区別しない場合には、これらを総称してコントローラ３という。
【００１８】
コントローラ３は、ＲＡＩＤドライバ４１やＳＳＤドライバ４２（図２参照）からの要求に応じて、記憶装置２へのデータのライトや記憶装置２からのデータのリード等のアクセス制御を行なう。ここで、コントローラ３は、ＳＡＳ／ＳＡＴＡプロトコルやＰＣＩｅプロトコル等のＰＣＩｅデバイス２に対応するプロトコルを用いてアクセス制御を行なう。すなわち、コントローラ３は、所定のプロトコルに従って記憶装置２へのアクセス制御を行なう入出力制御部の一例であるといえる。
【００１９】
ＣＰＵ１１は、メモリ１２，ＰＣＩｅコントローラ３２，ＢＭＣ／ＭＭＢ６等と接続され、種々の制御や演算を行なう演算処理装置（処理装置）の一例である。ＣＰＵ１１は、メモリ１２又は図示しないRead Only Memory（ＲＯＭ）等に格納されたプログラムを実行することにより、情報処理装置１における種々の機能を実現する。なお、ＣＰＵ１１に限らず、処理装置としては、Micro Processing Unit（ＭＰＵ）等の電子回路が用いられてもよい。
【００２０】
メモリ１２は、種々のデータやプログラムを格納する記憶装置である。ＣＰＵ１１は、プログラムを実行する際に、メモリ１２にデータやプログラムを格納し展開する。なお、メモリ１２としては、例えばRandom Access Memory（ＲＡＭ）等の揮発性メモリが挙げられる。
例えばＣＰＵ１１は、図２に示すように、ＲＡＩＤドライバ４１，及びＳＳＤドライバ４２の機能を含むＯＳ８を実行する。
【００２１】
ＲＡＩＤドライバ４１はＲＡＩＤコントローラ３１又は／及びＰＣＩｅデバイス２のハードウェアを制御するソフトウェアであり、ＳＳＤドライバ４２はＳＳＤ等のＰＣＩｅデバイス２のハードウェアを制御するソフトウェアである。以下、ＲＡＩＤドライバ４１及びＳＳＤドライバ４２を特に区別しない場合には、これらを総称してドライバ４という。ドライバ４は、上位装置（ホスト）であるＣＰＵ１１に対して、アクセス対象であるＰＣＩｅデバイス２へのインタフェースを提供する。例えばドライバ４は、ＣＰＵ１１からの要求をＰＣＩｅデバイス２に対応するＳＡＳ，ＳＡＴＡ，又はＰＣＩｅ等の所定のプロトコルに従って変換し、ＰＣＩｅデバイス２への指示（アクセス）を行なう。
【００２２】
なお、ＯＳ８は、複数のＰＣＩｅデバイス２を用いたＲＡＩＤ構成の管理・制御をソフトウェアＲＡＩＤにより行なう機能をそなえることができる。例えば図２に示す例では、ＯＳ８が実行するソフトウェアＲＡＩＤは、ＰＣＩｅコントローラ３２と直接接続されるＳＳＤに対するＲＡＩＤ構成の管理・制御を行なう。すなわち、図２では、情報処理装置１がそなえる全てのＰＣＩｅデバイス２がＲＡＩＤを構成する例を示している。
【００２３】
Ｈ／Ｗイベントインジケータ５１は、発生イベントに応じた処理を実行する。例えばＨ／Ｗイベントインジケータ５１は、発生イベントに応じて、ＳＮＭＰトラップやＥ−ｍａｉｌの送信，ハードウェアログの生成，ＬＥＤの制御等を行なう。なお、ＯＳ８は、図２に示すようにＨ／Ｗイベントインジケータ５１の処理結果の管理等を行なうイベントインジケータ５の機能をそなえてもよい。
【００２４】
ＢＭＣ／ＭＭＢ６は、ＣＰＵ１１及びＰＣＩｅデバイス２とを含む情報処理装置１の制御、例えば情報処理装置１の状態に関する状態情報の管理を行なうシステム管理装置の一例である。例えば、ＢＭＣ／ＭＭＢ６は、Inter-Integrated Circuit（Ｉ２Ｃ；登録商標）等のバスを介してメモリ１２やＰＣＩｅデバイス２等のベースボード上のコンポーネントと接続される。そして、ＢＭＣ／ＭＭＢ６は、バスを介して任意のコンポーネントからログ等の情報を収集（集約）し、情報処理装置１において発生（検出）したイベントをＨ／Ｗイベントインジケータ５１へ通知することができる。従って、Ｈ／Ｗイベントインジケータ５１は、ＢＭＣ／ＭＭＢ６から通知された情報処理装置（システム）１の状態に関する状態情報に応じて情報処理装置（システム）１の管理者に通知を行なう通知処理部の一例である。なお、ＢＭＣ／ＭＭＢ６は、情報処理装置１の電源制御等の各種制御を行なうことができる。
【００２５】
また、ＢＭＣ／ＭＭＢ６は、データ通信用のポートとは別にLocal Area Network（ＬＡＮ）等の監視用のポートをそなえ、管理者等は、リモートでＢＭＣ／ＭＭＢ６にアクセスをして、情報処理装置１の監視を行なうことができる。なお、ＢＭＣ／ＭＭＢ６は、ＣＰＵ，ＭＰＵ，Application Specific Integrated Circuit（ＡＳＩＣ），又はField Programmable Gate Array（ＦＰＧＡ）等の処理装置をそなえてもよい。そして、ＢＭＣ／ＭＭＢ６としての機能は、当該処理装置がＢＭＣ／ＭＭＢ６の記憶装置に保持されたソフトウェア（ファームウェア）を実行することにより実現されてもよい。また、ＢＭＣ／ＭＭＢ６は、Ｈ／Ｗイベントインジケータ５１による上記制御の少なくとも一部又は全部をＢＭＣ／ＭＭＢ６上で動作するソフトウェアの機能により実現してもよい。例えばＢＭＣ／ＭＭＢ６は、Ｈ／Ｗイベントインジケータ５１におけるＳＮＭＰトラップやＥ−ｍａｉｌを、監視用のポートを介して送信することができる。
【００２６】
スヌープ処理部７は、コントローラ３とＰＣＩｅデバイス２との間でＰＣＩｅ，ＳＡＳ／ＳＡＴＡのプロトコルでやり取りされるデータ（データフレーム）やコマンド（コマンドフレーム）（以下、これらをまとめて転送データともいう）を監視する。そして、スヌープ処理部７は、転送データが所定の条件を満たす場合、ＢＭＣ／ＭＭＢ６に対してＰＣＩｅデバイス２の故障／正常を出力信号により通知する。このため、スヌープ処理部７は、図１及び図２に示すように、コントローラ３とＰＣＩｅデバイス２との間の任意の箇所と接続され、転送データを取得（スヌープ）できるようになっている。また、スヌープ処理部７は、ＢＭＣ／ＭＭＢ６と接続され、検出したＰＣＩｅデバイス２の状態情報を通知できるようになっている。なお、スヌープ処理部７としては、電子回路、例えばＣＰＵ，ＭＰＵ，ＡＳＩＣ，又はＦＰＧＡ等の集積回路が挙げられる。
【００２７】
すなわち、スヌープ処理部７は、コントローラ３によるＰＣＩｅデバイス２へのアクセスに用いられる転送データに含まれる所定の情報を検出すると、所定の情報に基づくＰＣＩｅデバイス２の状態情報をＢＭＣ／ＭＭＢ６に通知する監視部の一例であるといえる。
〔１−２〕スヌープ処理部の構成例
以下、スヌープ処理部７の構成例を説明する。
【００２８】
なお、以下、スヌープ処理部７がＲＡＩＤ配下のＰＣＩｅデバイス２の監視を行なう場合を例に挙げて説明する。
スヌープ処理部７は、図２に示すように、レジスタ７１（図１参照），フレーム監視部７２，データ抽出部７３，及び通知部７４をそなえる。
レジスタ７１は、スヌープ処理部７における監視データを格納する記憶素子（記憶回路）である。レジスタ７１が格納する監視データについては後述する。
【００２９】
フレーム監視部７２は、図１及び図２に示すように、コントローラ３と記憶装置２との間で送受信される転送データを監視するものである。フレーム監視部７２は、例えばコントローラ３とＰＣＩｅデバイス２との間のバス，コントローラ３，又はＰＣＩｅデバイス２と接続され、転送データを取得（スヌープ）することができる。転送データの取得は既知の種々の手法により行なうことが可能であり、その詳細な説明は省略する。
【００３０】
具体的には、フレーム監視部７２は、転送データの監視において、コントローラ３からＰＣＩｅデバイス２に送信される転送データにＰＣＩｅデバイス２の所定の記憶領域のデータに対するアクセス要求（書込又は読出コマンド）が含まれるか否かを監視する。そして、フレーム監視部７２は、転送データに上記アクセス要求が含まれると判定した場合、読出コマンドに対するＰＣＩｅデバイス２からの応答データ（読出データ）又は書込コマンドに所定の情報が含まれるか否かを判定する。書込コマンド又は応答データに所定の情報が含まれると判定すると、フレーム監視部７２は、処理をデータ抽出部７３に渡す。
【００３１】
ここで、所定の記憶領域は、例えばＰＣＩｅデバイス２の構成に関する構成情報が格納される領域であって、異なる複数のＰＣＩｅデバイス２において共通に定義される領域である。また、所定の情報は、構成情報に含まれる情報であり、例えばＰＣＩｅデバイス２の故障の有無に関する情報が含まれる。さらに、構成情報は、ＰＣＩｅデバイス２等の任意のモジュール（例えばハードウェア，ファームウェア，ドライバ等）又はＯＳ８の種類／版数等に依存せず、これらの種類／版数等が変更（更新）されても仕様が変更されないデータであることが好ましい。例えば構成情報としては、ＰＣＩｅデバイス２の冗長化処理（ＲＡＩＤ）のための基本データであって、標準規格であるDisk Data Format（ＤＤＦ）により定義されたデータが挙げられる。
【００３２】
以下、図３及び図４を参照して、フレーム監視部７２のより具体的な構成例を説明する。図３は、ＤＤＦのデータ構造例を示す図であり、図４は、図１に示すレジスタ７１が格納する監視データの一例を示す図である。
ここで、ＤＤＦは、近年、ＲＡＩＤコントローラ等のＲＡＩＤ製品のベンダ各社が標準的に採用しＲＡＩＤ製品に実装している規格である。ＤＤＦでは、図３に示すように、ＨＤＤ／ＳＳＤ等のＰＣＩｅデバイス２の最終Logical Block Address（ＬＢＡ）に、“DDF Header (Anchor)”（アンカーヘッダ）が記録される。このアンカーヘッダには、ＰＣＩｅデバイス２の簡単な情報を含むＲＡＩＤ構成情報と、ＲＡＩＤ構成詳細情報の格納ＬＢＡのオフセットとが記録される。
【００３３】
具体的には、アンカーヘッダには、実際のＰＣＩｅデバイス２の状態が記録される“DDF Header (Primary)”（プライマリヘッダ）のＬＢＡが記録される（図３の矢印（ｉ）参照）。ＲＡＩＤ構成詳細情報は、図３に示すようにプライマリヘッダを含む所定のサイズの領域であり、ＲＡＩＤ構成詳細情報にはＰＣＩｅデバイス２の故障の有無に関する情報（所定の情報）を含むＰＣＩｅデバイス２の詳細な情報が含まれる。なお、アンカーヘッダには、オプションで、プライマリヘッダの冗長データである“DDF Header (Secondary)”（セカンダリヘッダ）のＬＢＡも記録される（図３の矢印（ii）参照）。
【００３４】
ところで、オープンシステムでは、各ハードウェアは開発ベンダが異なり、ベンダユニークの実装となっていることが多い。従って、ハードウェアのみでの監視は標準化されない限り困難である。或いは、標準化自体の長期化及び全ＰＣＩｅデバイスベンダの標準規格の実装による長期化により標準化されるまでに長い時間を要する。このため、ハードウェア統合監視の機能を搭載した情報処理装置を短期間で開発することは困難である。
【００３５】
これに対し、一実施形態に係る情報処理装置１では、スヌープ処理部７が、異なる複数のＰＣＩｅデバイス２において共通に定義される所定の領域内に記憶されたＰＣＩｅデバイス２の故障の有無に関する情報を用いて、ＰＣＩｅデバイス２の監視を行なう。従って、情報処理装置１のシステムベンダは、ＰＣＩｅデバイス２等の各ハードウェアの開発ベンダに依らず単独でＰＣＩｅデバイス２の監視機構を実装することが可能となる。また、各開発ベンダはハードウェア監視のための追加実装を行なわなくて済む。結果として、システムベンダは、ハードウェア統合監視の機能を搭載した情報処理装置１を短期間で開発することができる。また、システムベンダ及び開発ベンダの双方においてＰＣＩｅデバイス２の監視に係るコストを低減させることができる。
【００３６】
以下、最終ＬＢＡからプライマリヘッダのＬＢＡまでの領域（ＲＡＩＤ構成情報とＲＡＩＤ構成詳細情報とを含む領域）が上記所定の領域であり、最終ＬＢＡからプライマリヘッダのＬＢＡまでの領域に格納されたデータが上記構成情報であるものとする。
フレーム監視部７２は、情報処理装置１の起動後、ＳＡＳ／ＳＡＴＡ／ＰＣＩｅのデータトランザクションの監視を開始し、コントローラ３からのＳＣＳＩ／ＡＴＡコマンドフレーム，ＰＣＩｅコマンドフレームを検出する。そして、フレーム監視部７２は、検出したコマンドのオペレーションコードがＰＣＩｅデバイス２の最終セクタの読出コマンドである場合、当該読出コマンドに対応するＰＣＩｅデバイス２からの応答データフレームを判別する。なお、ＰＣＩｅデバイス２の最終セクタの読出コマンドとしては、ＳＡＳの場合“Read Capacity Command (0x25)”が挙げられ、ＳＡＴＡの場合“READ NATIVE MAX ADDRESS (0xF8)”が挙げられる。
【００３７】
以下、コントローラ３のインタフェースがＳＡＳに対応するものであって、コントローラ３がＰＣＩｅデバイス２へＳＡＳコマンドを送信するものとして説明するが、インタフェース及びコマンドがＳＡＴＡ又はＰＣＩｅに対応するものであっても、同様である。
フレーム監視部７２は、応答データフレームから、読出コマンドで要求された最終セクタのアドレスを示すデータを抽出し、レジスタ７１に格納する。最終セクタのアドレスを示すデータとしては、例えば“RETURNED LOGICAL BLOCK ADDRESS”（４バイト）及び“LOGICAL BLOCK LENGTH IN BYTES”（４バイト）の計８バイトのデータが挙げられる（図４参照）。ここで、“RETURNED LOGICAL BLOCK ADDRESS”はアンカーヘッダのＬＢＡを示し、“LOGICAL BLOCK LENGTH IN BYTES”はアンカーヘッダのブロックサイズを示す。なお、アンカーヘッダのブロックサイズは一般的に５１２バイトである場合が多いため、フレーム監視部７２は“LOGICAL BLOCK LENGTH IN BYTES”の抽出を省略してもよい。
【００３８】
以下、“LOGICAL BLOCK LENGTH IN BYTES”は５１２バイトであるものとして説明する。
このようにして、フレーム監視部７２は、ＰＣＩｅデバイス２の最終アドレス、つまりアンカーヘッダのＬＢＡを検出することができる。なお、ＣＰＵ１１又はコントローラ３は、情報処理装置１の起動後、はじめに各ＰＣＩｅデバイス２の最終アドレスを認識するためにＰＣＩｅデバイス２へ最終セクタの読出コマンドを発行する。従って、フレーム監視部７２は、ＣＰＵ１１又はコントローラ３の上記性質を利用して、確実にアンカーヘッダのＬＢＡを検出することができる。
【００３９】
また、フレーム監視部７２は、上記処理によりアンカーヘッダのＬＢＡを検出すると、データトランザクションの監視においてコントローラ３からのＳＣＳＩ／ＡＴＡコマンドフレーム，ＰＣＩｅコマンドフレームを検出する。そして、フレーム監視部７２は、検出したコマンドのオペレーションコードが書込又は読出コマンドであり、且つ、最終セクタ（アンカーヘッダ）へのアクセス要求であるか否かを判定する。
【００４０】
オペレーションコードが最終セクタへの読出コマンドである場合、フレーム監視部７２は、当該読出コマンドに対するＰＣＩｅデバイス２からの応答データフレームを判別する。なお、フレーム監視部７２は、オペレーションコードが最終セクタへの書込コマンドである場合は次の処理で書込データフレームを参照する。以下、書込データフレームと応答データフレームとをまとめて単にデータフレームという。
【００４１】
フレーム監視部７２は、データフレームに含まれる最終セクタのデータオフセット“0x00”から４バイトの値が、ＤＤＦのフォーマットであることを示すシグニチャ（例えば“0xDE11DE11”）であることを検出する。これにより、フレーム監視部７２は、ＰＣＩｅデバイス２がＤＤＦの規格に準拠していることを検出することができる。
なお、書込コマンドとしては“Write(10)-0x2A”，“Write(12)-0xAA”，“Write(16)-0x8A”...等が挙げられ、読出コマンドとしては“Read(10)-0x28”，“Read(12)-0xA8”，“Read(16)-0x88”...等が挙げられる（括弧内の数字はアドレス幅の違いを示す）。また、フレーム監視部７２は、書込又は読出コマンドのCommand Descriptor Block（ＣＤＢ）つまり制御領域を参照することで、当該コマンドが最終セクタへのアクセス要求であるか否かを判定することができる。具体的には、フレーム監視部７２は、書込又は読出コマンドのＣＤＢ内のアクセスＬＢＡ及び転送ブロック数に基づき、データ転送先のＬＢＡがレジスタ７１に格納された“RETURNED LOGICAL BLOCK ADDRESS”と一致するか否か（又は含むか否か）を判定すればよい。
【００４２】
フレーム監視部７２は、最終セクタへの又は最終セクタからの上記データフレームから、以下のデータをレジスタ７１に格納する（図４参照）。なお、以下のオフセットは、アンカーヘッダの先頭アドレス（“DDF Header (primary)”）からのオフセットを示す。
・“DDF Header (Primary)”のＬＢＡ：例えばオフセット“0x60”から８バイト分の値。
【００４３】
・“Physical_Disk_Records_Section”：ＰＣＩｅデバイス２の状態が格納される領域（図３の太枠内“Physical Disk Record”参照）のオフセット。例えばオフセット“0xC8”から４バイト分の値。
・“Physical_Disk_Records_Section_Length”：“Physical_Disk_Records_Section”のセクタ数。例えばオフセット“0xCC”から４バイト分の値。
【００４４】
このようにして、フレーム監視部７２は、ＰＣＩｅデバイス２の状態が格納される領域のアドレス、つまり“Physical_Disk_Records_Section”のオフセットを検出することができる。
以上の処理により、スヌープ処理部７は、ＰＣＩｅデバイス２の状態を取得するために用いる監視データを取得することができる。
【００４５】
次に、フレーム監視部７２は、監視データを用いてＰＣＩｅデバイス２の状態が含まれる転送データを監視・検出する。具体的には、フレーム監視部７２は、データトランザクションの監視においてコントローラ３からのＳＣＳＩ／ＡＴＡコマンドフレーム，ＰＣＩｅコマンドフレームを検出する。そして、フレーム監視部７２は、検出したコマンドのオペレーションコードが書込又は読出コマンドであり、且つ、プライマリヘッダへのアクセス要求であるか否かを判定する。
【００４６】
なお、フレーム監視部７２は、書込又は読出コマンドのＣＤＢを参照することで、当該コマンドがプライマリヘッダへのアクセス要求であるか否かを判定することができる。具体的には、フレーム監視部７２は、書込又は読出コマンドのＣＤＢ内のアクセスＬＢＡ及び転送ブロック数に基づき、データ転送先のＬＢＡがレジスタ７１に格納された“DDF Header (Primary)”のＬＢＡと一致するか否か（又は含むか否か）を判定すればよい。
【００４７】
オペレーションコードがプライマリヘッダへの読出コマンドである場合、フレーム監視部７２は、当該読出コマンドに対するＰＣＩｅデバイス２からの応答データフレームを判別し、データ抽出部７３に渡す。なお、フレーム監視部７２は、オペレーションコードがプライマリヘッダへの書込コマンドである場合は当該書込データフレームをデータ抽出部７３に渡す。
【００４８】
データ抽出部７３は、フレーム監視部７２により書込コマンド又は応答データに所定の情報が含まれると判定されると、書込コマンド又は応答データから当該所定の情報を抽出する。
具体的には、データ抽出部７３は、書込又は応答データフレームに含まれるプライマリヘッダからのオフセット（レジスタ７１に格納されたオフセット）“Physical_Disk_Records_Section”から先の転送データを監視する。このとき、データ抽出部７３は、“Physical_Disk_Records_Section”からのオフセット“0x40”から先の転送データである“Physical_Disk_Entries”内の値を参照する。ここで、“Physical_Disk_Entries”には、例えば６４バイトごとに各ＰＣＩｅデバイス２の状態情報が格納される。具体的には、“Physical_Disk_Entries”のオフセット“0x1E”におけるビット１のデータが、ＰＣＩｅデバイス２の故障の有無に関する情報（所定の情報）に対応する。つまり、データ抽出部７３は、“Physical_Disk_Entries”において、６４バイトごとに、オフセット“0x1E”におけるビット１のデータの値を参照することで、各ＰＣＩｅデバイス２の故障の有無に関する情報を取得することができるのである。
【００４９】
なお、データ抽出部７３は、取得した各ＰＣＩｅデバイス２の故障の有無に関する情報をレジスタ７１又は他の記憶装置に保存してもよい。
フレーム監視部７２は、“Physical_Disk_Records_Section”からのデータ転送が“Physical_Disk_Records_Section_Length”のセクタ数分完了すると、再び転送データの監視に戻る。
【００５０】
すなわち、スヌープ処理部７は、上述した処理によってＢＭＣ／ＭＭＢ６にステータス信号を出力した後、引き続き他の（又は同じ）ＰＣＩｅデバイス２において所定の領域へのアクセスが発生するか否かを待ち受けることができる。そして、スヌープ処理部７は、所定の領域へのアクセスが発生する都度、上記“Physical_Disk_Entries”からの所定の情報の抽出及びステータス信号の出力を実行することができる。
【００５１】
なお、図４に示す例では、レジスタ７１に１セットの監視データが格納されることを示している。この監視データは複数のＰＣＩｅデバイス２で共通に用いられてもよいし、複数のＰＣＩｅデバイス２の記憶容量が互いに異なるような場合にはＬＢＡも異なるため、フレーム監視部７２は、ＰＣＩｅデバイス２ごとにレジスタ７１に監視データを格納してもよい。
【００５２】
このように、“Physical_Disk_Entries”がＰＣＩｅデバイス２ごとに６４バイトの情報を含むため、データ抽出部７３は、１つのＰＣＩｅデバイス２の“Physical_Disk_Entries”を参照することで全てのＰＣＩｅデバイス２の状態を取得することができる。これにより、スヌープ処理部７は、コマンドフレームが所定の領域に対するアクセスである場合にデータフレームから所定の情報を取得すればよいので、監視の負荷を低減させることができる。
【００５３】
通知部７４は、データ抽出部７３が取得した各ＰＣＩｅデバイス２の状態に基づいて、ＰＣＩｅデバイス２のステータス信号（状態情報）をＢＭＣ／ＭＭＢ６に通知する。例えば通知部７４は、“Physical_Disk_Entries”内の６４バイトごとのオフセット“0x1E”におけるビット１のデータが全て“0”（正常）であれば、ＢＭＣ／ＭＭＢ６への出力を“Low”（ＰＣＩｅデバイス２が正常）とする。一方、通知部７４は、当該ビット１のデータのうち、１つでも“1”（故障，異常）であれば、ＢＭＣ／ＭＭＢ６への出力を“High”（ＰＣＩｅデバイス２が故障，異常）とする。
【００５４】
このように、通知部７４は、“Physical_Disk_Entries”内の所定の情報の値に応じてＰＣＩｅデバイス２のステータス信号をＢＭＣ／ＭＭＢ６に通知する。なお、通知部７４は、故障したＰＣＩｅデバイス２を特定する情報をＢＭＣ／ＭＭＢ６に通知してもよい。
通知部７４からＰＣＩｅデバイス２のステータス信号の通知を受けたＢＭＣ／ＭＭＢ６は、当該ＰＣＩｅデバイス２を含む情報処理装置１の各モジュールの状態情報を集約してＨ／Ｗイベントインジケータ５１へ通知する。そして、Ｈ／Ｗイベントインジケータ５１は、ＢＭＣ／ＭＭＢ６から通知された状態情報に応じて、管理者等へ通知を行なう。
【００５５】
以上のように、スヌープ処理部７は、フレームの監視を行ない、少なくとも監視に用いる情報をレジスタ７１に格納し、監視するフレームが所定の条件に該当した場合にＰＣＩｅデバイス２のステータス信号をＢＭＣ／ＭＭＢ６に出力する。
具体的には、スヌープ処理部７は、ＰＣＩｅ，ＳＡＳ／ＳＡＴＡ経由でやり取りされるＤＤＦデータ（所定の領域）へのデータ参照又は更新の内容、つまりデバイス制御データトランザクションをスヌープする。そして、スヌープ処理部７は、スヌープにより取得したデータを本来のデータトランザクションの目的ではない冗長部品（ＰＣＩｅデバイス２）の故障検知やハードウェア情報の表示に利用することで、ＰＣＩｅデバイス２の故障等の監視（状態監視）を実現する。
【００５６】
ハードウェアの監視においては、監視制御を行なうＢＭＣ／ＭＭＢ自体，又はその上位層であるエージェント（プラットフォームエージェント）で統合監視を行なうのが一般的である。図９は図８に示す情報処理装置１００のハードウェア構成例を示す図である。例えば図９に示すように、従来の手法では、ＢＭＣ／ＭＭＢ９００又はＣＰＵ１１００（ＯＳ９００）が、ＲＡＩＤコントローラ３１０，ＰＣＩｅコントローラ３２０，メモリ１２００等で検出された故障の情報を収集して統合監視する。
【００５７】
これに対し、ＢＭＣ／ＭＭＢ６は、スヌープ処理部７により、図１に示すように、コントローラ３で検出されたＰＣＩｅデバイス２の故障の情報を、コントローラ３よりも下位層であるコントローラ３とＰＣＩｅデバイス２との間で収集することができる。
従って、情報処理装置１は、図８に示すようなＲＡＩＤエージェント５１０，ＳＳＤエージェント５２０，及びプラットフォームエージェント６００や、Ｓ／Ｗイベントインジケータ７２０の構成を省略することができる。このようなハードウェア・ファームウェアによるエージェントレスの監視により、一実施形態に係る情報処理装置１によれば、ハードウェア統合監視のために、ＰＣＩｅデバイス２ごとに専用のエージェントの開発・検証が不要となる。つまり、ＯＳ８の種類や版数，ＰＣＩｅデバイス２のモジュールの版数等を考慮しなくてよく、ＰＣＩｅコントローラ３２の監視コストを低減させることができる。また、ＰＣＩｅデバイス２の各モジュールの互換依存関係を考慮しなくてよいため、管理者によるシステムメンテナンスの負担を低減させることができる。さらに、ＯＳ８上で動作するエージェントを省略できるため、ＯＳ８の処理負荷を低減させることができるという効果も奏することができる。
【００５８】
また、スヌープ処理部７は、任意の記録媒体に記録されたデータではなく、コントローラ３とＰＣＩｅデバイス２との間でインターフェース転送中のデータを利用（取得）し、所定の情報を抽出する。従って、コントローラ３がＰＣＩｅデバイス２の故障を検出してから短時間で検出することができる。
さらに、スヌープ処理部７は、コントローラ３とＰＣＩｅデバイス２との間で送受信される転送データの監視を通じて、所定の領域における所定の情報が格納される位置（オフセット）を特定する。従って、複数のＰＣＩｅデバイス２の記憶容量が互いに異なっていても、適応的に所定の情報が格納される位置を特定することができる。
【００５９】
以上のように、一実施形態に係る情報処理装置１によれば、ＰＣＩｅデバイス２のの監視を容易に又は低コストで実現することができる。
〔１−３〕動作例
次に、図５〜図７を参照して、上述の如く構成された一実施形態の一例としての情報処理装置１（スヌープ処理部７）の動作例を説明する。
【００６０】
図５〜図７は、それぞれ図１に示すスヌープ処理部７によるＰＣＩｅデバイス２の監視処理の一例を説明するフローチャートである。
以下、コントローラ３のインタフェースがＳＡＳに対応するものであって、コントローラ３がＰＣＩｅデバイス２へＳＡＳコマンドを送信するものとして説明する。また、ＰＣＩｅデバイス２の最終セクタのサイズ“LOGICAL BLOCK LENGTH IN BYTES”が一般的な５１２バイトであるものとして説明する。さらに、書込／読出コマンドが一般的な“Write (10)”／“Read (10)”コマンドであるものとして説明する。
【００６１】
はじめに、図５に示すように、情報処理装置１の電源がオンになると、スヌープ処理部７のフレーム監視部７２により、ＳＡＳ／ＳＡＴＡ／ＰＣＩｅのデータトランザクションの監視が開始される（ステップＳ１）。データトランザクションの監視では、フレーム監視部７２は、例えばＳＣＳＩ／ＡＴＡコマンドフレームを待ち続ける。
次いで、フレーム監視部７２により、ＳＣＳＩ／ＡＴＡコマンドフレームが検出されると、当該コマンドのオペレーションコードが、最終セクタ読出コマンドであるか否かが判断される（ステップＳ２）。当該コマンドのオペレーションコードが最終セクタ読出コマンドではない場合（ステップＳ２のＮｏルート）、最終セクタ読出コマンドが受信されるまでステップＳ２の処理がループする。一方、当該コマンドのオペレーションコードが最終セクタ読出コマンドである場合（ステップＳ２のＹｅｓルート）、フレーム監視部７２により、最終セクタ読出コマンドに該当する応答データフレームが判別される。そして、フレーム監視部７２により、最終セクタのアドレスに該当する８バイトのデータ（“RETURNED LOGICAL BLOCK ADDRESS”，“LOGICAL BLOCK LENGTH IN BYTES”）がレジスタ７１に格納され（ステップＳ３）、処理が図６に遷移する。
【００６２】
次に、図６に示すように、フレーム監視部７２により、データトランザクションの監視が続けられる。このとき、フレーム監視部７２は、コマンドフレームを待ち続ける。
フレーム監視部７２により、コマンドフレームが検出されると、当該コマンドのオペレーションコードが、アンカーヘッダへの書込又は読出コマンドであるか否かが判定される（ステップＳ４）。このとき、フレーム監視部７２は、書込／読出コマンドのＣＤＢ内のアクセスＬＢＡ及び転送ブロック数により、データ転送ＬＢＡがレジスタ７１に格納された“RETURNED LOGICAL BLOCK ADDRESS”と一致するか否か（又は含まれるか否か）を判断する。アンカーヘッダへの書込又は読出コマンドではない場合（ステップＳ４のＮｏルート）、アンカーヘッダへの書込又は読出コマンドが受信されるまでステップＳ４の処理がループする。一方、アンカーヘッダへの書込又は読出コマンドである場合（ステップＳ４のＹｅｓルート）、フレーム監視部７２により、ステップＳ５の処理が実行される。
【００６３】
ステップＳ５では、フレーム監視部７２により、書込／読出コマンドに該当するデータフレームが検出され、最終セクタのデータオフセット“0x00”から４バイトの値がＤＤＦであることを示すシグニチャであるか否かが判定される。例えばフレーム監視部７２は、最終セクタのデータオフセット“0x00”から４バイトの値が“0xDE11DE11”であるか否かを判断する。上記４バイトの値がＤＤＦを示すものでない場合（ステップＳ５のＮｏルート）、処理がステップＳ４に移行する。一方、上記４バイトの値がＤＤＦを示すものである場合（ステップＳ５のＹｅｓルート）、フレーム監視部７２により、ステップＳ６の処理が実行される。
【００６４】
ステップＳ６では、フレーム監視部７２により、最終セクタへの又は最終セクタからのデータフレームから以下のデータが抽出されて、レジスタ７１に格納され、処理が図７に遷移する。なお、以下のオフセットは、アンカーヘッダの先頭アドレスである“DDF Header (primary)”からのオフセットを示す。
・“DDF Header (Primary)”のＬＢＡ
・“Physical_Disk_Records_Section”（オフセット）
・“Physical_Disk_Records_Section_Length”（オフセット）
次に、図７に示すように、フレーム監視部７２により、データトランザクションの監視が続けられる。このとき、フレーム監視部７２は、コマンドフレームを待ち続ける。
【００６５】
フレーム監視部７２により、コマンドフレームが検出されると、当該コマンドのオペレーションコードが、プライマリヘッダへの書込又は読出コマンドであるか否かが判定される（ステップＳ７）。このとき、フレーム監視部７２は、書込／読出コマンドのＣＤＢ内のアクセスＬＢＡ及び転送ブロック数により、データ転送ＬＢＡがレジスタ７１に格納された“DDF Header (Primary)”のＬＢＡと一致するか否か（又は含まれるか否か）を判断する。プライマリヘッダへの書込又は読出コマンドではない場合（ステップＳ７のＮｏルート）、プライマリヘッダへの書込又は読出コマンドが受信されるまでステップＳ７の処理がループする。一方、プライマリヘッダへの書込又は読出コマンドである場合（ステップＳ７のＹｅｓルート）、データ抽出部７３によりステップＳ８の処理が実行される。
【００６６】
ステップＳ８では、データ抽出部７３により、データフレームに含まれるプライマリヘッダからのオフセット（レジスタ７１に格納されたオフセット）“Physical_Disk_Records_Section”から先の転送データが監視される。このとき、データ抽出部７３により、“Physical_Disk_Records_Section”からのオフセット“0x40”から先の転送データである“Physical_Disk_Entries”内の値が参照される。そして、データ抽出部７３により、“Physical_Disk_Entries”において、６４バイトごとに、オフセット“0x1E”におけるビット１のデータの値が取得される。
【００６７】
そして、通知部７４により、“Physical_Disk_Entries”内の６４バイトごとのオフセット“0x1E”におけるビット１のデータが全て“0”（正常）であるか否かが判定される。全て“0”の場合（ステップＳ８のＹｅｓルート）、通知部７４により、スヌープ処理部７の出力が“Low”に設定され、ＢＭＣ／ＭＭＢ６にＰＣＩｅデバイス２の状態が正常である旨が通知され（ステップＳ９）、処理がステップＳ１１に移行する。一方、当該ビット１のデータのうち、１つでも“1”（故障，異常）の場合（ステップＳ８のＮｏルート）、通知部７４により、スヌープ処理部７の出力が“High”に設定される。また、通知部７４により、ＢＭＣ／ＭＭＢ６にＰＣＩｅデバイス２の状態が故障，異常である旨が通知され（ステップＳ１０）、処理がステップＳ１１に移行する。
【００６８】
ステップＳ１１では、フレーム監視部７２により、“Physical_Disk_Records_Section”から“Physical_Disk_Records_Section_Length”のセクタ数分のデータ転送完了が確認され、処理がステップＳ７に移行する。このように、スヌープ処理部７は、ステップＳ１〜Ｓ６において監視データを生成しているため、２回目以降の“Physical_Disk_Entries”の取得は、ステップＳ７〜Ｓ１１の処理を繰り返せばよい。
【００６９】
〔２〕その他
以上、本発明の好ましい実施形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲内において、種々の変形、変更して実施することができる。
例えば、上述した記憶装置２では、ＰＣＩｅ，ＳＡＳ／ＳＡＴＡ等のインタフェースをが用いられるものとして説明したが、これに限定されるものではなく、スヌープ処理部７によるスヌープが可能な他のインタフェースが用いられてもよい。
【００７０】
また、上述したフレーム監視部７２は、コントローラ３とＰＣＩｅデバイス２との間でやり取りされるデータを監視するものとして説明したが、これに限定されるものではない。例えばフレーム監視部７２を含むスヌープ処理部７の少なくとも一部の構成がコントローラ３にそなえられてもよい。この場合、フレーム監視部７２はコントローラ３がＰＣＩｅデバイス２へ送信及び受信するデータを監視すればよい。
【００７１】
さらに、上述した情報処理装置１のハードウェア構成例は例示である。例えば、各コントローラ３，ＢＭＣ／ＭＭＢ６，Ｈ／Ｗイベントインジケータ５１，及びスヌープ処理部７間での構成（ハードウェア又はソフトウェア（ファームウェア））の増減や分割、任意の組み合わせでの統合等は、適宜行なわれてもよい。
また、上述したスヌープ処理部７は、ＲＡＩＤ配下のＰＣＩｅデバイス２の監視を行なうものとして説明したが、これに限定されるものではない。例えばＲＡＩＤを構成しないＰＣＩｅデバイス２であっても、ＰＣＩｅデバイス２の故障の有無に関する情報が記録される領域が既知である（望ましくは標準化された仕様を採用する）ＰＣＩｅデバイス２であれば、上述した制御を適用することが可能である。
【００７２】
〔３〕付記
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
データを記憶する記憶装置と、
前記記憶装置へのアクセスを行なう処理装置と、
前記処理装置及び前記記憶装置とを含むシステムの状態に関する状態情報の管理を行なうシステム管理装置と、
所定のプロトコルに従って前記記憶装置へのアクセス制御を行なう入出力制御部と、
前記入出力制御部による前記記憶装置へのアクセスに用いられるデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する監視部と、を有する
ことを特徴とする、情報処理装置。
【００７３】
（付記２）
前記監視部は、前記入出力制御部と前記記憶装置との間で送受信されるデータを監視し、前記入出力制御部から前記記憶装置に送信されるデータに前記記憶装置の所定の記憶領域のデータに対するアクセス要求が含まれる場合、当該アクセス要求又は当該アクセス要求に対する前記記憶装置からの応答データに前記所定の情報が含まれるか否かを判定する
ことを特徴とする、付記１記載の情報処理装置。
【００７４】
（付記３）
前記所定の記憶領域は、前記記憶装置を含む複数の記憶装置において共通に定義された領域であって前記記憶装置の構成に関する構成情報が格納される領域であり、
前記所定の情報は、前記構成情報に含まれる前記記憶装置の故障の有無に関する情報である
ことを特徴とする、付記２記載の情報処理装置。
【００７５】
（付記４）
前記監視部は、前記入出力制御部と前記記憶装置との間で送受信されるデータの監視を通じて、前記所定の領域における前記所定の情報が格納される位置を特定する
ことを特徴とする、付記２又は付記３記載の情報処理装置。
（付記５）
前記監視部は、前記入出力装置と前記記憶装置との間で転送中のデータを取得し、取得したデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する
ことを特徴とする、付記１〜４のいずれか１項記載の情報処理装置。
【００７６】
（付記６）
前記システム管理装置から通知された前記システムの状態情報に応じて前記システムの管理者に通知を行なう通知処理部をさらにそなえ、
前記システム管理装置は、前記監視部から通知された前記記憶装置の状態情報を前記システムの状態情報に集約して前記通知処理部へ通知する
ことを特徴とする、付記１〜５のいずれか１項記載の情報処理装置。
【００７７】
（付記７）
データを記憶する記憶装置と、前記記憶装置へのアクセスを行なう処理装置と、前記記憶装置の監視を行なう監視部と、をそなえる情報処理装置における監視方法であって、
前記監視部において、
所定のプロトコルに従って前記記憶装置へのアクセス制御を行なう入出力制御部による前記記憶装置へのアクセスに用いられるデータに含まれる所定の情報を検出し、
前記所定の情報に基づく前記記憶装置の状態に関する状態情報を、前記処理装置及び前記記憶装置とを含むシステムの状態情報の管理を行なうシステム管理装置に通知する
ことを特徴とする、監視方法。
【００７８】
（付記８）
前記監視部において、
前記入出力制御部と前記記憶装置との間で送受信されるデータを監視し、
前記入出力制御部から前記記憶装置に送信されるデータに前記記憶装置の所定の記憶領域のデータに対するアクセス要求が含まれる場合、当該アクセス要求又は当該アクセス要求に対する前記記憶装置からの応答データに前記所定の情報が含まれるか否かを判定する
ことを特徴とする、付記７記載の監視方法。
【００７９】
（付記９）
前記所定の記憶領域は、前記記憶装置を含む複数の記憶装置において共通に定義された領域であって前記記憶装置の構成に関する構成情報が格納される領域であり、
前記所定の情報は、前記構成情報に含まれる前記記憶装置の故障の有無に関する情報である
ことを特徴とする、付記８記載の監視方法。
【００８０】
（付記１０）
前記監視部において、
前記入出力制御部と前記記憶装置との間で送受信されるデータの監視を通じて、前記所定の領域における前記所定の情報が格納される位置を特定する
ことを特徴とする、付記８又は付記９記載の監視方法。
【００８１】
（付記１１）
前記監視部において、
前記入出力装置と前記記憶装置との間で転送中のデータを取得し、
取得したデータに含まれる所定の情報を検出すると、前記所定の情報に基づく前記記憶装置の状態情報を前記システム管理装置に通知する
ことを特徴とする、付記７〜１０のいずれか１項記載の監視方法。
【００８２】
（付記１２）
前記システム管理装置において、
前記監視部から通知された前記記憶装置の状態情報を前記システムの状態情報に集約し、
前記システムの状態情報に応じて前記システムの管理者に通知を行なう通知処理部に、前記集約した前記システムの状態情報を通知する
ことを特徴とする、付記７〜１１のいずれか１項記載の監視方法。
【符号の説明】
【００８３】
１    情報処理装置（システム）
１１    ＣＰＵ（処理装置）
１２，１２００    メモリ
１００    情報処理装置
１１００    ＣＰＵ
２，２００    ＰＣＩｅデバイス（記憶装置）
３    コントローラ（入出力制御部）
３１，３１０    ＲＡＩＤコントローラ
３２，３２０    ＰＣＩｅコントローラ
４    ドライバ
４１，４１０    ＲＡＩＤドライバ
４２，４２０    ＳＳＤドライバ
５，７００    イベントインジケータ
５１    Ｈ／Ｗイベントインジケータ（通知処理部）
５１０    ＲＡＩＤエージェント
５２０    ＳＳＤエージェント
６    ＢＭＣ／ＭＭＢ（システム監視装置）
６００  プラットフォームエージェント
７    スヌープ処理部（監視部）
７１    レジスタ
７２    フレーム監視部
７３    データ抽出部
７４    通知部
７１０    Ｈ／Ｗイベントインジケータ
７２０    Ｓ／Ｗイベントインジケータ
８，９００    ＯＳ
８００    ＢＭＣ／ＭＭＢ
【図１】
2015114873.tif 000003
【図２】
2015114873.tif 000004
【図３】
2015114873.tif 000005
【図４】
2015114873.tif 000006
【図５】
2015114873.tif 000007
【図６】
2015114873.tif 000008
【図７】
2015114873.tif 000009
【図８】
2015114873.tif 000010
【図９】
2015114873.tif 000011