JP4575462B2 - ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ - Google Patents

Description

本発明は、ストレージシステムを有する計算機システムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、仮想ボリュームとしてサーバに提供されるストレージエリアネットワーク（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ、以下ＳＡＮ）において、ストレージシステムの障害を管理する方法及び装置に関するも
のである。

（１）ＳＡＮについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるＳＡＮが浸透しつつある。ＳＡＮの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。

（２）ＳＡＮ管理について
ＳＡＮによるストレージシステムの高い拡張性は、ＳＡＮにおける複数ベンダの装置（サーバ、スイッチ、ストレージ装置）の混在を可能とした。このようなＳＡＮを無停止で運用するために、ＳＡＮ管理が必要である。

ＳＡＮ管理の概要については、例えば非特許文献１で説明されている。ＳＡＮ管理の中でも、日々の運用の基本となる、ＳＡＮに接続される各装置の稼動状況監視が特に重要である。ＳＡＮの稼動状況を監視するためのソフトウェアを、以降ＳＡＮマネージャとよぶ。

ＳＡＮマネージャは、構成管理機能と障害監視機能の二大機能を持つ。

構成管理機能とは、ＳＡＮに接続される各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からＳＡＮの物理的な接続関係（トポロジ）を検出し、常に最新のトポロジを視覚化してＳＡＮマネージャのユーザ、言い換えるとＳＡＮ管理者に提供する機能である。

障害監視機能とは、ＳＡＮに接続される各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをＳＡＮ管理者に通知する機能である。

これら二つの機能により、ＳＡＮ管理者はＳＡＮマネージャを用いて装置の稼動状況を一元的に管理できるので、ＳＡＮ管理者の少人数化など運用コストの削減を図ることができる。

（３）バーチャリゼーション装置について
ＳＡＮにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献１に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。

１）ストレージサーバに接続された各ストレージ装置が有する記憶媒体内の記憶領域であるボリューム（以下実ボリューム）を管理し、ボリュームプールを生成する機能。

２）ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのＩ／Ｏアクセスを逐次実ボリュームへのＩ／Ｏ要求に変換してサーバからのＩ／Ｏに応答する機能。

これら二つの機能を有する装置を、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をＳＡＮに導入することにより、サーバへのボリューム割当は仮想ボリュームにより一元化され、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。つまり、ＳＡＮ管理者は一元的にボリュームの割当を行うことができる。

英国特許出願公開第２３５１３７５号明細書 リチャードベーカー（Ｒｉｃｈａｒｄ Ｂａｒｋｅｒ）、ポールマッシグリア（Ｐａｕｌ Ｍａｓｓｉｇｌｉａ）、"ストレージエリアネットワークエッセンシャルズ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｅｓｓｅｎｔｉａｌｓ）"、ジョンウィリーアンドサンズインク（Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， Ｉｎｃ）、２００２年、ｐ．３３１−３３４

ＳＡＮマネージャの持つ障害監視機能により、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、どの装置のどの部位が障害の原因かを切り分ける作業を行う。以降これを、「障害の切り分け」と呼ぶ。バーチャリゼーション装置が仮想ボリュームを提供することにより、サーバに提供されるボリュームの構成自由度は高まる。しかし、ＳＡＮに接続される複数ベンダの装置から発行された障害メッセージ（ＳＮＭＰ Ｔｒａｐなど）をもとに障害の切り分けをするには、個々の装置について高度な知識を持ったＳＡＮ管理者の手動作業に頼っているのが現状であり、管理コストが非常に高いという課題がある。

また、ＳＡＮマネージャは、障害の深刻さ（以降Ｓｅｖｅｒｉｔｙと呼ぶ）に応じて、業務システム全体を運用管理する管理ソフトウェア（以降上位システム管理ソフトと呼ぶ）へイベントを通知したり、ＳＡＮ管理者へのメールを送信したりといった、障害通報機能を持つ。しかし、障害のＳｅｖｅｒｉｔｙの定義はＳＡＮに接続される各装置に依存するため、どの装置のどのイベントが高いＳｅｖｅｒｉｔｙを持つか、その都度ＳＡＮ管理者が判断する必要があり、障害対策に時間を要するという課題がある。

本発明の第一の目的は、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することである。

本発明の第二の目的は、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトが、ＳＡＮに接続される装置から発行された障害メッセージのうち、必要な障害情報
を受信することができるようにすることである。

第一の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、複数の障害通知を関連づけて出力する。

又、第二の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する。

本発明によれば、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することができる。

また、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトは、ＳＡＮ内に存在する装置から発行された障害メッセージのうち、必要な障害情報を受信することができる。

以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発明が限定されるものではない。

＜ＳＡＮの構成＞
まず本実施形態におけるＳＡＮの構成例について説明する。図１から図６はＳＡＮ及びＳＡＮに接続される各装置の構成例を示し、図９から図１８は各装置内に具備された管理情報を示している。

図１にはＳＡＮの構成例を示す。本発明におけるＳＡＮは、管理エージェントを有する１台以上のサーバ、管理エージェントを有する１台以上のスイッチ、管理エージェントを有する１台以上のバーチャリゼーション装置、管理エージェントを有する１台以上のストレージ装置、そしてＳＡＮマネージャを有する１台のＳＡＮ管理サーバを有する。

以降の説明の都合上、本実施形態のＳＡＮにおいては、１台のサーバ（サーバＡ）２００００と、１台のスイッチ（スイッチＡ）３００００と、１台のバーチャリゼーション装置兼ストレージ装置（ストレージ装置Ａ）４００００と、１台のストレージ装置（ストレージ装置Ｂ ５００００）が、ファイバチャネル６００００を介して相互に接続されているものとする。本接続形態では、ストレージ装置Ａ４００００は、ストレージ装置Ｂ５００００の実ボリューム５７０００を、スイッチ３００００を介して認識し、仮想ボリューム機能を適用することにより、サーバに対してストレージ装置Ｂ５００００の実ボリューム５７０００を、ストレージ装置Ａ４００００の仮想化ボリュームとして提供する。なお、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００の接続形態については、図１に示す例の様にスイッチＡ３００００を介して接続するのではなく、例えば図２６に示す第二の構成例のように、ファイバチャネル６００００によって、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されていてもよい。また、図２７に示す第三の構成例のように、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されるパスと両ストレージ装置がスイッチ経由で接続されるパスとが混在していてもよい。

ＳＡＮ管理サーバ１００００は、管理用ネットワーク７００００を介してサーバ、スイッチ、及びストレージ装置それぞれに接続されており、各装置の管理エージェントとＳＡＮ管理サーバ１００００内のＳＡＮマネージャ１３１００は管理用ネットワークを介して通信できる。ＳＡＮマネージャ１３１００は、後述する処理により、ＳＡＮにおける仮想ボリュームと実ボリュームの構成管理と、ＳＡＮにおける障害切り分けと、ＳＡＮにおける障害通報を行う。

図２にはＳＡＮ管理サーバ１００００の構成例を示す。ＳＡＮ管理サーバ１００００は、プロセッサ１１０００と、メモリ１３０００と、管理用ネットワーク７００００に接続するための管理インタフェース制御部（以下、Ｉ／Ｆとする。）１４０００と、ＳＡＮマネージャ１３１００によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部１５０００と、ＳＡＮ管理者がＳＡＮマネージャに指示を入力するためのキーボード等の入力部１６０００を有し、これらは内部バス等の通信路１７０００を介して相互に接続される。

メモリ１３０００には、ＳＡＮ管理サーバによって実行されるプログラムであるＳＡＮマネージャ１３１００と、ＳＡＮにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル１３２００と、ＳＡＮにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル１３３００と、ＳＡＮ内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ１３４００と、ＳＡＮ内でＳＡＮマネージャ１３１００が管理対象としている装置の一覧を保持する装置検出リスト１３５００と、ＳＡＮ内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上の障害解析辞書１３６００と、イベント内容を記録するための障害ログ１３７００と、後述するＳｅｖｅｒｉｔｙ変換機能を行うにあたり、ＳＡＮ管理者により予め定義されるＳｅｖｅｒｉｔｙ変換定義を保持するための一つ以上の障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００とが格納されている。

図３にはサーバ２００００の構成例を示す。サーバ２００００は、プロセッサ２１０００と、メモリ２３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ２４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ２６０００を有し、これらは内部バス等の通信路２７０００を介して相互に接続される。

メモリ２３０００には、ＳＡＮマネージャ１３１００と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント２３１００と、当該サーバのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル２３２００と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル２３３００とが格納されている。

なお、本実施形態ではサーバはサーバＡの一台、サーバＡの具備するデータＩ／Ｆは一つとしたが、サーバ台数及びデータＩ／Ｆ数は一には限られず、サーバがＳＡＮに複数台接続されていても、又１台のサーバが複数のデータＩ／Ｆを備えていても良い。また、各サーバのデータＩ／Ｆには各サーバ内で固有の識別子（データＩ／Ｆ ＩＤ）が割当てられており、本実施例では、サーバＡのデータＩ／Ｆ ＩＤの値をａ１とする。

図４にはスイッチ３００００の構成例を示す。スイッチ３００００は、ファイバチャネル６００００を介して送受信されるデータのスイッチングを実現するコントローラ３１０００と、メモリ３３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ３４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ３６０００を有し、メモリ３３０００と管理Ｉ／Ｆ３４０００とデータＩ／Ｆ３６０００とはコントローラ３１０００を介して相互に接続される。

メモリ３３０００には、ＳＡＮマネージャ１３１００と通信して当該スイッチＡの管理情報を送受信するためのプログラムである管理エージェント３３１００と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル６００００を介した接続関係を示す情報であるＦＣ接続管理テーブル３３２００とが格納されている。

なお、本実施形態ではＳＡＮ内に存在するスイッチはスイッチＡの一台とし、スイッチＡは６個のデータＩ／Ｆを有する構成としているが、スイッチの台数及びデータＩ／Ｆの個数は幾つであっても良い。また、各データＩ／Ｆは装置内（スイッチ内）で固有の識別子（データＩ／Ｆ ＩＤ）を持ち、本実施形態においてはその値をｓ１、ｓ２、ｓ３、ｓ４、ｓ５、ｓ６とする。

図５にはバーチャリゼーション装置兼ストレージ装置であるストレージ装置Ａの詳細な構成例を示す。ストレージ装置Ａ ４００００は、ストレージ装置内の制御を行うコントローラ４１０００と、メモリ４３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ４４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ４６０００と、サーバが利用するデータが格納されるディスク装置内の記憶領域である一つ以上の実ボリューム４７０００とを有し、メモリ４３０００と管理Ｉ／Ｆ４４０００とデータＩ／Ｆ４６０００と実ボリューム４７０００とはコントローラ４１０００を介して相互に接続される。尚図５にはコントローラ４１０００に接続される記憶領域として実ボリューム４７０００の他に、一つ以上の仮想ボリューム４８０００が図示されている。この仮想ボリューム４８０００は、他のストレージ装置（例えばストレージ装置Ｂ５００００）が保持する実ボリュームをストレージ装置Ａの仮想ボリューム機能により仮想化したものであり、仮想ボリューム４８０００はストレージ装置Ａのボリュームとしてサーバに提供される記憶領域であるため図５にストレージ装置Ａの構成要素として表示しているが、実際の記憶領域はストレージ装置Ａに接続される他のストレージ装置内に存在する。

メモリ４３０００には、ＳＡＮマネージャ１３１００と通信してストレージ装置Ａの管理情報を送受信するためのプログラムである管理エージェント４３１００と、ストレージ装置ＡのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル４３２００と、当該ストレージ装置Ａの実ボリューム４７０００の管理情報を保持する実ボリューム管理テーブル４３３００と、仮想ボリューム機能を実現するための仮想ボリューム管理プログラム４３４００と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル４３５００が格納されている。

なお本実施形態では、ストレージ装置Ａは２個のデータＩ／Ｆと２個の実ボリュームと２個の仮想ボリュームを有するが、データＩ／Ｆ、実ボリューム、及び仮想ボリュームの個数は幾つであっても良い。各データＩ／Ｆ、各実ボリューム、及び各仮想ボリュームは装置内固有の識別子（データＩ／Ｆ ＩＤ、実ボリュームＩＤ、仮想ボリュームＩＤ）を持ち、本実施形態ではデータＩ／Ｆ ＩＤの値をｃ１、ｃ２、実ボリュームＩＤの値をｖａ１、ｖａ２、仮想ボリュームＩＤの値をｖｖ１、ｖｖ２とする。

図６にはストレージ装置Ｂの詳細な構成例を示す。ストレージ装置Ｂは、仮想ボリューム機能を持たない点を除いて、ストレージ装置Ａと同様の構成を有する。よって、メモリ５３０００には仮想ボリューム管理プログラムと仮想ボリューム管理テーブルは存在しない。なお、本実施形態では、ストレージ装置Ｂは２個のデータＩ／Ｆと３個の実ボリュームを有するが、データＩ／Ｆ及び実ボリュームの数は幾つであっても良い。また、ストレージ装置ＢのデータＩ／Ｆ ＩＤの値はｄ１、ｄ２、ボリュームＩＤの値はｖｂ１、ｖｂ２、ｖｂ３とする。

図９にはＳＡＮ管理サーバ１００００が保持する装置検出リスト１３５００の一例を示す。図９の検出対象ＩＤ欄にはＳＡＮ管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはＳＡＮ内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、ＩＰアドレス情報欄には各装置の管理用ネットワーク７００００上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録され、仮想化対象ＩＤ欄には、装置情報としてストレージが登録されたエントリであり、当該ストレージ装置が有する実ボリュームが他の装置によって仮想化される場合、仮想化処理を実行する当該他の装置の検出対象ＩＤが登録される。これらの情報はＳＡＮ管理者がＳＡＮ管理サーバ１００００の出力部１５０００及び入力部１６０００を用いて予め設定するものとする。本リストに基づき、ＳＡＮマネージャ１３１００は各装置の管理エージェントを特定して当該管理エージェントと通信する。

図１０にサーバＡ ２００００が保持するデータＩ／Ｆ管理テーブルの一例を示す。図１０のデータＩ／Ｆ ＩＤ欄には各サーバが有するデータＩ／ＦのＩＤの値が登録され、Ｐｏｒｔ ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）欄には当該データＩ／Ｆに対して割り当てられているファイバチャネル内で一意の識別子となるＰｏｒｔ ＷＷＮが登録され、ＳＣＳＩ ＩＤ欄にはデータＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスの識別子（ＳＣＳＩ ＩＤ番号）が登録される。

図１１にサーバＡ ２００００が保持するボリューム管理テーブルの一例を示す。サーバＡは３つのボリュームの提供を受けており、サーバＡはボリューム管理テーブルに自身が提供を受けているボリュームの情報を保持する。ボリューム管理テーブルのＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ） ＩＤ欄には、サーバＡ内で自身が提供を受けているボリュームに対して任意に割当てた識別子が登録される。データＩ／Ｆ ＩＤ欄にはボリュームにアクセスするために使用するサーバＡ上のデータＩ／Ｆの識別子が登録され、ＳＣＳＩ ＩＤ欄には該データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄にはＳＣＳＩターゲットデバイス内の当該ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録され、ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、サーバに対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。

尚、図１１の例では、サーバＡは、ストレージ装置Ａから実ボリュームｖａ１と、実ボリュームはストレージＢ内に存在するがストレージ装置Ａによって仮想化されている仮想ボリュームｖｖ１との提供を受けて使用しており、ストレージ装置Ｂから実ボリュームｖｂ３の提供を受けて使用している。尚、ストレージ装置Ｂの実ボリュームｖｂ３は、ストレージ装置Ａによって仮想化されることなくサーバＡに提供されている。

図１２にスイッチＡ ３００００が保持するＦＣ接続管理テーブル３３３００の一例を示す。ＦＣ接続管理テーブルは、スイッチＡ ３００００のデータＩ／Ｆであるｓ１からｓ６の接続先に関する情報を保持する。ＦＣ接続管理テーブルのデータＩ／Ｆ ＩＤ欄にはスイッチＡ ３００００のデータＩ／ＦのＩＤの値が登録され、スイッチ Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録され、接続先Ｐｏｒｔ ＷＷＮ欄には当該データＩ／Ｆが接続するサーバやストレージ装置上のデータＩ／ＦのＰｏｒｔ ＷＷＮが登録される。

図１３にストレージ装置が保持するデータＩ／Ｆ管理テーブルの一例を示す。データＩ／Ｆ管理テーブル４３２００はストレージ装置Ａが、データＩ／Ｆ管理テーブル５３２００はストレージ装置Ｂが有するテーブルである。データＩ／Ｆ管理テーブルのデータＩ／Ｆ ＩＤ欄には、ストレージ装置が有するデータＩ／Ｆの識別子の値が登録され、Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録される。

図１４にストレージ装置が保持する実ボリューム管理テーブルの一例を示す。実ボリューム管理テーブル２３３００はストレージ装置Ａが、実ボリューム管理テーブル５３３００はストレージ装置Ｂが有するテーブルである。実ボリューム管理テーブルの実ボリュームＩＤ欄にはストレージ装置が有する実ボリュームのＩＤの値が登録され、パス有無欄には当該実ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームをアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＳＣＳＩ ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。なお、実ボリューム管理テーブル中のパス有無欄でパスが“無”と登録されている実ボリュームは、まだ未使用の実ボリュームである。よって、データＩ／Ｆ ＩＤ欄、ＳＣＳＩ ＩＤ欄、ＳＣＳＩ ＬＵＮ欄のそれぞれの値は未定義であることを示す“Ｎ／Ａ”を登録する。

図１５にストレージ装置Ａ ４００００が保持する仮想ボリューム管理テーブル４３５００の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想ボリュームＩＤ欄にはサーバに提供している仮想ボリュームに対して任意に割り当てた識別子が登録され、パス有無欄には当該仮想ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。本実施形態においては、ストレージ装置Ａ ４００００は、データＩ／Ｆ ｃ１から仮想ボリュームｖｖ１を提供している。仮想ボリュームｖｖ２は未使用である。

次に仮想ボリューム管理テーブル４３５００の実ボリューム欄の内容を説明する。実データＩ／Ｆ ＩＤ欄には、仮想ボリュームＩＤ欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、ストレージ装置Ａ上のデータＩ／Ｆの識別子が登録される。ＳＣＳＩ ＩＤ欄には当該実データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実データＩ／Ｆを介してストレージ装置から提供されるボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録さる。実ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、当該実データＩ／Ｆを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。

なお、仮想ボリューム管理テーブルには、仮想化装置（例えばストレージ装置Ａ）によって仮想化されるボリュームのデータのみが登録される。従って、データＩ／Ｆ ｃ２からアクセス可能で、ストレージ装置Ｂ内に存在する実ボリュームｖｂ１、ｖｂ２は、ストレージ装置Ａに認識されストレージ装置Ａによって仮想化され仮想ボリュームとしてサーバに提供されるので、仮想ボリューム管理テーブルに登録されている。また、データＩ／Ｆ ｃ１からアクセス可能な実ボリュームｖａ１は、ストレージ装置Ａにおいて仮想化されることなくサーバに提供されるため、ｖａ１に関する情報は仮想ボリューム管理テーブル４３５００に登録されていない。また、ストレージ装置Ｂの実ボリュームｖｂ３は、データＩ／Ｆｄ２を介してサーバＡに直接認識されているため、ｖｂ３に関する情報も、仮想ボリューム管理テーブル４３５００に登録されない。このように、ボリューム仮想化機能を保持するバーチャリゼーション装置は、全てのストレージ装置の実ボリュームを仮想化していなくてもよい。

図１６にはＳＡＮ管理サーバ１００００が有する障害解析辞書１３６００の例を示す。（ａ）はストレージ装置Ａの、（ｂ）はストレージ装置Ｂの、（ｃ）はサーバＡの、（ｄ）はスイッチＡの障害解析辞書である。これらの辞書は、各装置から障害発生時等に発行されるＳＮＭＰ Ｔｒａｐメッセージの解析に用いられるものであり、その詳細は後述する。障害コード欄にはＳＮＭＰ ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールド中の障害コードが、障害部位欄には各障害コードに対応する障害発生部位が、識別子欄には障害発生部位を特定するための識別子が、原因欄にはメッセージ発行の原因が、Ｓｅｖｅｒｉｔｙ欄にはＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールド中のＴｒａｐのＳｅｖｅｒｉｔｙが登録されている。

図１７にはＳＡＮ管理サーバ１００００が有する障害ログ１３７００を示す。障害ログにはＳＡＮマネージャが障害通知メッセージを受信した時に割り当てるイベントＩＤ、障害が発生した時刻、障害通知メッセージの送信元装置名、障害通知メッセージ中の障害コード、当該部位を含む実マッピングのＩＤ、当該部位を含む仮想マッピングのＩＤと、他の障害イベントとの関係が登録される
図１８には、ＳＡＮ管理サーバ１００００が有する障害Ｓｅｖｅｒｉｔｙ変換テーブルの一例を示す。本変換テーブルは、後述するＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理において、ＳＡＮマネージャが受信する複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作を定義するものである。本テーブルは、ＳＡＮ環境構築にあたりＳＡＮ管理者が定義するものとする。障害Ｓｅｖｅｒｉｔｙ変換テーブルには、複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに対応する各装置のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作が登録される。例えば図１８の場合、ストレージ装置ＡのＳｅｖｅｒｉｔｙが“３”のときと、ストレージ装置ＢのＳｅｖｅｒｉｔｙ“４”、“５”、“６”のとき、ＳＡＮ環境で共通のＳｅｖｅｒｉｔｙ“３”とみなされ、その結果、ＳＡＮマネージャは、ストレージ装置Ａの障害メッセージ情報のみをＳＮＭＰ Ｔｒａｐとして送信し、かつ、ＳＡＮ管理者にメールで送信する。尚、Ｓｅｖｅｒｉｔｙ変換テーブルは、ＳＡＮの構成情報に基づいて定義される。図１８に示すＳｅｖｅｒｉｔｙ変換テーブルにおいては例えば、ストレージＡのＳｅｖｅｒｉｔｙ３とストレージＢのＳｅｖｅｒｉｔｙ４〜５が共通Ｓｅｖｅｒｉｔｙ３として関連づけられており、共通Ｓｅｖｅｒｉｔｙ３の障害通知メッセージに関してはストレージＡに関する障害情報のみをＳＮＭＰ Ｔｒａｐとして送信し、ＳＡＮ管理者にメールで送信するよう定義されている。これは、ストレージＢが有する実ボリュームをストレージＡが仮想化してサーバに提供しており、ストレージＢが送受信する入出力要求はストレージＡを介してサーバが送受信することとなるからであり、従ってストレージＡのＳｅｖｅｒｉｔｙとストレージＢのＳｅｖｅｒｉｔｙとを関連付け、ストレージＡ及びストレージＢの実ボリュームを仮想化しているストレージＡに関する障害情報のみを出力するよう定義されているのである。

＜ＳＡＮマネージャの仮想ボリュームマッピング及び実ボリュームマッピング作成処理＞
次に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はＳＡＮ管理サーバ１００００のプロセッサ１１０００がメモリ１３０００内に格納されているプログラムを実行することによって定期的に実行されるもので、ＳＡＮ環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはＳＡＮマネージャ１３１００が実施するものとする。

図１９にＳＡＮマネージャ１３１００によって実行される実トポロジ及び仮想トポロジ表示処理の概要を表すフローチャート１７００を示す。ＳＡＮマネージャ１３１００は、装置検出リスト１３５００を元にＳＡＮ内の装置を検出し、各装置の管理エージェントと通信をして、各装置が保持する図１０から図１５に示す情報をコピーする（ステップ１７１０）。次にＳＡＮマネージャ１３１００はコピーした情報を実トポロジリポジトリ１３４００に格納する（ステップ１７２０）。その後、ステップ１７２０で格納した情報をもとに、後述する仮想ボリュームマッピング管理テーブル１３３００を作成する（ステップ１７３０）。さらに実トポロジリポジトリ１３４００内の情報と仮想ボリュームマッピング管理テーブル１３３００をもとに、後述する実ボリュームマッピング管理テーブル１３２００を作成する（ステップ１７４０）。最後に仮想ボリュームマッピング管理テーブル１３３００及び実ボリュームマッピング管理テーブル１３２００の内容をもとに、実トポロジなどの結果を出力し（ステップ１７５０）、終了する。

図２０にＳＡＮマネージャ１３１００によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ１７３０の詳細な処理を表すフローチャートを示す。また図８に図２０に示す処理によって作成される仮想ボリュームマッピング管理テーブル１３３００の一例を示す。

ＳＡＮマネージャ１３１００は、各サーバから受信して実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブル２３３００について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する（ステップ１８１０）。

まず、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルに新規エントリを作成し、新しく割り当てた仮想マッピングＩＤ１３３０１を登録する。更にＳＡＮマネージャは現在処理中のボリューム管理テーブル２３３００の送信元サーバ名１３３０２、ボリューム管理テーブルに記憶されているデータＩ／Ｆ ＩＤ１３３０４及びＬＵ ＩＤ１３３０３を登録する（ステップ１８２０）。次にＳＡＮマネージャは、登録されたデータＩ／Ｆ１３３０４が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前１３３０５とデータＩ／Ｆ ＩＤ１３３０６を登録する。具体的には、ＳＡＮマネージャはまず仮想ボリュームマッピング管理テーブル１３３００に登録されたサーバのデータＩ／Ｆ ＩＤ１３３０４をキーとして、当該サーバから受信して実トポロジデポジトリ１３４００に格納されているデータＩ／Ｆ管理テーブル２３２００を検索し、当該データＩ／Ｆ ＩＤのＰｏｒｔ ＷＷＮを調べる。さらにＳＡＮマネージャは当該Ｐｏｒｔ ＷＷＮをキーとして、スイッチＡから受信して実トポロジデポジトリ１３４００に格納されているＦＣ接続管理テーブル３３２００を検索し、当該サーバがどのスイッチのどのデータＩ／Ｆに接続しているかを検索し、結果を接続先スイッチ名１３３０５と接続先スイッチデータＩ／Ｆ ＩＤ１３３０６として登録する（ステップ１８３０）。以上の処理により、仮想ボリュームマッピング管理テーブル１３３００の左半分（サーバ欄）にサーバに関する情報が登録される。

次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の左半分（ストレージ欄）に情報を登録するための処理を行う。ＳＡＮマネージャはボリューム管理テーブル２３３００にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーション装置によって提供されているものか否かを調べる。具体的には、ＳＡＮマネージャは装置名をキーとして装置検出リスト１３５００を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーション装置から提供されているものと判断する。（ステップ１８４０）。ステップ１８４０の結果により、以下のように処理が分岐する（ステップ１８５０）。

ボリュームがバーチャリゼーション装置 以外のストレージ装置から提供されている場合、ＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを、仮想ボリュームマッピング管理テーブル１３３００のストレージ欄にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは、登録したボリュームＩＤ１３３１１をキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索し、当該実ボリュームにアクセスするために使用されるデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６０）。そしてＳＡＮマネージャは、登録したストレージデータＩ／Ｆ１３３１０が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはまずストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、当該ストレージ装置から受信したデータＩ／Ｆ管理テーブルを検索し、当該ストレージデータＩ／ＦのＰｏｒｔ ＷＷＮを調べ、さらにＷＷＮをキーとして、スイッチＡから受信したＦＣ接続管理テーブル３３２００を検索し、当該ストレージデータＩ／ＦがどのスイッチのどのデータＩ／Ｆに接続しているかを調査する。そしてＳＡＮマネージャは調査結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７０）。

ステップ１８５０においてボリュームがバーチャリゼーション装置から提供されていると判断した場合、ＳＡＮマネージャは以下の処理を行う。まずＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを仮想ボリュームマッピング管理テーブル１３３００にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは登録したボリュームＩＤ１３３１１をキーとして、バーチャリゼーション装置から受信した仮想ボリューム管理テーブル４３５００及び実ボリューム管理テーブル４３３００を検索し、当該ボリュームにアクセスするために使用されるストレージ装置ＡのデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６１）。次に、ストレージ装置Ａの当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、スイッチＡ から受信したデータＩ／Ｆ管理テーブル３３４００を検索し、当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆ ＩＤを調査して、結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７１）。

装置検出リスト１３５００に装置が未登録のためボリューム管理テーブル２３３００が実トポロジリポジトリ１３４００に格納されていない場合、及び、装置が管理Ｉ／Ｆを具備しない場合、ステップ１８５０では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル２３３００のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする（ステップ１８６２）。

以上のステップを、ＳＡＮ管理サーバが各サーバから受信し実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブルの全エントリに対して、ＳＡＮマネージャが実行したとき、ステップ１７３０の処理は終了する。

図２１に、ＳＡＮマネージャ１３１００が行う実ボリュームマッピング管理テーブル作成ステップ１７４０の詳細な処理フローを示す。又図７に図２１に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。

ＳＡＮマネージャ１３１００は、ステップ１７３０で作成した仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対して、以下の処理を実行する（ステップ１９１０）。

まず、ＳＡＮマネージャは新規エントリを作成し、新しく割り当てた実マッピングＩＤ１３２０１を登録する（ステップ１９２０）。次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の各エントリのストレージ名１３３０９をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名１３３０９をキーとして装置検出リスト１３５００を検索し、当該装置の仮想化機能の有無をチェックする（ステップ１９３０）。

仮想化機能を有する場合、ＳＡＮマネージャは以下のステップを実行する。ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルエントリ中のボリュームＩＤ１３３１１をキーとして、ストレージ名１３３０９が示す装置から受信した仮想ボリューム管理テーブル３３５００を検索し、ボリュームＩＤ１３３１１と一致する仮想ボリュームＩＤのエントリを抽出する（ステップ１９４０）。次にＳＡＮマネージャは、検索して得られたエントリの数と同数のエントリを実ボリューム管理マッピングテーブルに用意する（ステップ１９５０）。そして、ＳＡＮマネージャは、用意したエントリに対して、サーバ欄（１３２０２から１３２０６）には仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリのサーバ欄の内容（１３３０２から１３３０６）をコピーする。ストレージ欄のスイッチデータＩ／Ｆ ＩＤ欄１３２０８にはステップ１９４０で抽出した仮想ボリューム管理テーブル３３５００のエントリの、実ボリューム情報欄の実データＩ／Ｆ ＩＤの内容をコピーする。また、ストレージ欄のストレージ名エントリ１３２０９及びボリュームＩＤエントリ１３２１１には、仮想ボリューム管理テーブル４３５００の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームＩＤをコピーする。また対応仮想マッピングＩＤ欄１３２１２には仮想ボリュームマッピング管理テーブル１３３００中の仮想マッピングＩＤ１３３０１の内容を登録する。ストレージ欄のスイッチ名欄１３２０７には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名１３３０７の内容をコピーする（ステップ１９６０）。更に、ＳＡＮマネージャは、実ボリュームマッピング管理テーブル１３２１２のストレージ欄のボリュームＩＤ１３２１１に登録したボリュームＩＤをキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索して、当該ボリュームが接続されるデータＩ／ＦのＩＤを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータＩ／Ｆ ＩＤ１３２１０に登録する。

ステップ１９３０にて仮想化機能を有しないとの判断がされた場合、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリ（１３３０２から１３３１１）を実ボリュームマッピング管理テーブル１３２００のエントリ（１３２０２から１３２１１）へコピーし、仮想ボリュームマッピング管理テーブル１３３００の仮想マッピングＩＤ１３３０１の内容を実ボリュームマッピング管理テーブル１３２００の対応仮想マッピングＩＤ１３２１２に登録する。

以上の処理により実ボリュームマッピング管理テーブル１３２００のエントリ１３２０１から１３２１２までが登録される。

以上のステップを仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対してＳＡＮマネージャが実行したとき、ステップ１７４０に示す処理が終了する。

図７で示された実ボリュームマッピングテーブルをもとに、ＳＡＮマネージャ１３１００が出力部１５０００に出力する実トポロジ表示の例を図２３に示す。実ボリュームマッピング管理テーブル１３２００の内容をもとに、サーバ、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示２０１０である。

＜ＳＡＮマネージャの障害切り分け処理＞
以下に、ＳＡＮマネージャによる障害切り分け処理の一例について示す。

現在のＳＡＮ管理ソフトによる障害監視機能は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で作成されたＲＦＣ１１５７「Ａ Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＳＮＭＰ）」によって定められたＳＮＭＰプロトコルのＴｒａｐメッセージを利用することが多い。しかし、仮想ボリューム技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。また、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、障害の切り分けするには、現状個々の装置の高度な知識を持ったＳＡＮ管理者の手動作業に頼るため、管理コストが非常に高い。

そこで本処理では、複数の装置が発行する障害通知を受けたＳＡＮマネージャは、障害解析辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したＳＡＮの構成情報をもとに、それらの障害が実ボリューム及び仮想ボリュームへのＩ／Ｏアクセスに与える影響を解析する。また、当該障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる。そして、これらの結果をＳＡＮマネージャが出力することによって、ＳＡＮ管理者による複数障害メッセージの解析及び障害きりわけ作業を軽減する。

ここで、障害切り分け処理を説明する前に、図２５にＳＡＮ管理サーバ１００００上のＳＡＮマネージャがＳＡＮ内の各装置から受信するＳＮＭＰ Ｔｒａｐメッセージのフォーマットと、ＳＮＭＰ Ｔｒａｐメッセージの一例を示し、説明しておく。ここでＳＮＭＰ Ｔｒａｐメッセージとは、ＳＡＮ内の各装置の管理エージェントがＳＡＮ管理サーバ１００００に対して送信する障害通知メッセージのことである。図２５（ａ）は、ＳＮＭＰ Ｔｒａｐメッセージのフォーマットを図示したものである。ＳＮＭＰメッセージは、メッセージヘッダと、メッセージ送信先のコミュニティ名と、メッセージ種別を示すＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ） Ｔｙｐｅと、送信元装置のベンダ名を示すＥｎｔｅｒｐｒｉｓｅと、送信先ＩＰアドレスを示すＡｇｅｎｔ Ａｄｄｒｅｓｓと、Ｔｒａｐメッセージの種別を示すＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅと、ＴｒａｐメッセージのＳｅｖｅｒｉｔｙを示すＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅと、メッセージの送信時刻を示すＴｉｍｅｓｔａｍｐと、メッセージ内容を格納するＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓのフィールドから構成される。ＰＤＵ Ｔｙｐｅフィールドの値が“４”のとき、当該メッセージはＳＮＭＰ Ｔｒａｐメッセージであると識別される。またＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅフィールドの値が“６”のとき、当該ＳＮＭＰ Ｔｒａｐメッセージは送信元装置ベンダ固有の定義に基づくＴｒａｐメッセージと識別され、各ベンダによって定義されたＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドに記載されたＳｅｖｅｒｉｔｙと、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドに記載された障害コードの内容にもとづき、Ｔｒａｐメッセージを解釈する必要がある。

本実施形態において、ストレージＡ ４００００が自装置のハードウェア障害を通知するために送信するＳＮＭＰ Ｔｒａｐメッセージの一例を図２５（ｂ）に示す。図２５（ｂ）に示すメッセージは、ＰＤＵ Ｔｙｐｅが“４”であることからＳＮＭＰ Ｔｒａｐメッセージであると認識され、Ｇｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅが“６”であることから送信元ベンダ固有の定義に基づくＴｒａｐメッセージであると認識される。また、Ｓｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドには障害のＳｅｖｅｒｉｔｙを、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドには障害発生部位を示す障害コードを格納するようベンダが定義しているものとする。従って図２５（ｂ）に示すＳＮＭＰ Ｔｒａｐメッセージは、Ｓｅｖｅｒｉｔｙが“１”で障害コード“３０ｃ１”の障害が生じている旨を表している。

図２２に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理の一例を示すフローチャート２４００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。

ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２４１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出し（ステップ２４１５）、抽出したＩＰアドレスをキーとして実トポロジリポジトリ１３４００に格納されている装置検出リスト１３５００を検索する（ステップ２４２０）。

ＩＰアドレスが装置検出リスト１３５００内に存在しない場合は、未登録の装置からのＴｒａｐメッセージであるためＳＡＮマネージャはＴｒａｐメッセージの内容を解析できない。従ってＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、障害装置としてＩＰアドレスを、障害部位としてＴｒａｐメッセージそのものを出力し（ステップ２４６５）、後述するステップ２４５５の処理にジャンプする。

ステップ２４２０において、抽出したＩＰアドレスが装置検出リスト１３５００内に存在し、Ｔｒａｐメッセージ発行元の装置が特定できた場合、ＳＡＮマネージャはＳＡＮ管理サーバ１００００が当該装置の障害解析辞書を具備しているか確認する（ステップ２４２５）。

ステップ２４２５にて障害解析辞書を具備している場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドをキーとして障害解析辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する（ステップ２４３０）。

ステップ２４２５で障害解析辞書を具備していないと判断した場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、ＳＡＮマネージャは、障害部位は装置全体みなし、障害コード欄には“装置全体”として登録し、以降のステップを継続する（ステップ２４３１）。

ステップ２４３０あるいはステップ２４３１が終了した後、ＳＡＮマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する（ステップ２４３５）。具体的には、まず、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。

その後、ＳＡＮマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する（ステップ２４４０）。具体的には、ステップ２４３５で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル４３５００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから仮想ボリュームＩＤを抽出する。さらに、抽出した仮想ボリュームＩＤをキーとして実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索し、実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。

ステップ２４３５とステップ２４４０で障害ログの作成中エントリの、実ボリュームマッピングと、仮想ボリュームマッピングの関係を登録した後、ＳＡＮマネージャは、当該作成中エントリと、他の障害ログエントリの関係について調査する。まず、ＳＡＮマネージャは、作成中のエントリが、ハード故障によるものか、他の部位へのアクセスエラーによるものかを調査する（ステップ２４４５）。具体的には、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとしてその原因を検索する。

ステップ２４４５で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある“親イベント”であると判断し、イベント関係欄に“親イベント”と登録する（ステップ２４５０）。ステップ２４４５で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある“子イベント”であると判断し、イベント関係欄に“子イベント”と登録する（ステップ２４５１）。

最後にＳＡＮマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する（ステップ２４５５）。以上でフローチャート２４００を終了する。

ここで、フローチャート２４００で示されたＳＡＮマネージャ１００００の障害切り分け処理の具体例について説明する。図２３は、図１７に記載された障害ログのエントリが、フローチャート２４００で示された障害切り分け処理により、どのように出力されるかの例を示す図である。ここで、イベントＩＤ １０００、１００１、１００２、１００３は、ストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。

イベントＩＤ １０００の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１のハード故障と解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりハード故障は“親イベント”であることがわかる。

次に、イベントＩＤ １００１の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置Ａの仮想ボリュームｖｖ１のＩ／Ｏを実ボリュームｖｂ１に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりアクセスエラーは“子イベント”であることがわかる。同様に、イベントＩＤ １００２の障害メッセージ及びイベントＩＤ １００３の障害メッセージも“子イベント”であることがわかる。

ステップ２４５５で障害メッセージを出力するにあたり、ＳＡＮマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は“親イベント”と“子イベント”のどちらかを特定する。ここで、「一定時間」とは、あらかじめＳＡＮ管理者が指定した時間で、障害の関連付けの単位となる時間である。図１７のイベントＩＤ １０００、１００１、１００２、１００３は、いずれも実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関連付けられ、かつ、イベントＩＤ １０００が“親イベント”であることがわかるので、図２３の障害イベント一覧ウィンドウ２０２０では、例えばイベント関連性欄にシンボル２０２１のように関連付けを示すことができる。

また、例えば、ＳＡＮ管理者がイベント指定２０２２のように、ある特定の障害イベントを指定したとき、ＳＡＮマネージャ１００００は、実トポロジ表示ウィンドウ２０１０中に、実トポロジマッピング表示２０１１のように指定されたイベントに対応する実トポロジマッピングを図示してもよい。さらに、障害通知ウィンドウ２０１２のように、指定されたイベントの内容を分かりやすく表示してもよい。

以上、ＳＡＮマネージャは、障害切り分け処理により、ＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる
＜ＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理＞
以下に、ＳＡＮマネージャによるＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例について示す。本処理では、ＳＡＮマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のＳｅｖｅｒｉｔｙ変換機能を保持し、ＳＡＮ管理者により予め定義された障害Ｓｅｖｅｒｉｔｙ変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のＳｅｖｅｒｉｔｙに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。

図２４に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理のフローチャート２５００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。

ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２５１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出する（ステップ２５１５）。

抽出したＩＰアドレスを元に、ＳＡＮマネージャは、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あるかどうかを調査する（ステップ２５２０）。具体的には、はじめに、抽出したＩＰアドレスが装置検出リスト１３５００内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するＳｅｖｅｒｉｔｙ欄が、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００に存在するか調査する。

ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係ないと判断した場合は、ＳＡＮマネージャはＳｅｖｅｒｉｔｙ変換機能を行わず、Ｔｒａｐメッセージをそのまま上位管理ソフトに転送する（ステップ２５２６）。

ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あると判断した場合は、ＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドからメッセージ発行元装置のＳｅｖｅｒｉｔｙを抽出する（ステップ２５２５）。メッセージ発行元の装置名と、抽出したＳｅｖｅｒｉｔｙをもとに、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００を調査し、共通Ｓｅｖｅｒｉｔｙとアクションを特定する（ステップ２５３０）。最後に、ステップ２５３０で特定したアクションを実行する（ステップ２５３５）。以上でフローチャート２５００を終了する。

ここで、フローチャート２５００で示されたＳＡＮマネージャ１００００の障害通報処理の具体例について説明する。図１７に記載された障害ログのエントリのうち、イベントＩＤ ２０００のイベントが受信されたときを考える。イベントＩＤ ２０００の障害メッセージは、ステップ２５１５でストレージ装置Ｂが発行元装置であると判断されるので、ステップ２５２０で共通Ｓｅｖｅｒｉｔｙ定義に関係ある場合と判断される。ステップ２５２５においてＴｒａｐメッセージ中のＳｅｖｅｒｉｔｙは“４”であることから、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００記載のアクション「ストレージＡの情報をＴｒａｐ送信及びメール送信」を適用し、イベントＩＤ ２０００の障害メッセージは、上位管理ソフト及びＳＡＮ管理者には通報されない。

以上、ＳＡＮマネージャは、Ｓｅｖｅｒｉｔｙ変換機能を含む通報処理により、ＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じたＳＡＮマネージャの障害通報機能を提供することができる。

なお、ＳＡＮマネージャが実施するストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理、障害切り分け処理、Ｓｅｖｅｒｉｔｙ変換機能を含む障害通報処理は、ストレージ装置Ａ ４００００がバーチャリゼーション装置であることを想定していたが、ストレージ装置Ａ４００００とは異なる装置をバーチャリゼーション装置として管理ネットワーク７００００及びＳＡＮ６００００に接続した構成であっても、上述の処理は同様に実現可能である。

以上に説明した実施形態によれば、バーチャリゼーション装置を有するＳＡＮにおいて、ＳＡＮマネージャが実行される装置がＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、ＳＡＮマネージャが、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる。

また、ＳＡＮにおいてＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じた方法でＳＡＮマネージャが障害を通報することで、ＳＡＮ管理者や上位システム管理ソフトが、必要十分な障害情報のみを受信することになり、通報後の障害対策の迅速化が可能となる。

ＳＡＮの構成例を示す図である。 ＳＡＮ管理サーバの構成例を示す図である。 サーバの構成例を示す図である。 スイッチの構成例を示す図である。 仮想化機能を有するストレージ装置の構成例を示す図である。 ストレージ装置の構成例を示す図である。 ＳＡＮ管理サーバが保持する実ボリュームマッピング管理テーブルの例を示す図である。 ＳＡＮ管理サーバが保持する仮想ボリュームマッピング管理テーブルの例を示す図である。 ＳＡＮ管理サーバが保持する装置検出リストの例を示す図である。 サーバが保持するデータＩ／Ｆ管理テーブルの例を示す図である。 サーバが保持するボリューム管理テーブルの例を示す図である。 スイッチが保持するＦＣ接続管理テーブルの例を示す図である。 ストレージ装置が保持するデータＩ／Ｆ管理テーブルの例を示す図である。 ストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。 ストレージ装置が保持する仮想ボリューム管理テーブルの例を示す図である。 ＳＡＮ管理サーバが保持するストレージ装置に関する障害解析辞書テーブルの例を示す図である。 ＳＡＮ管理サーバが保持する障害ログの例を示す図である。 ＳＡＮ管理サーバが保持する障害Ｓｅｖｅｒｉｔｙ変換テーブルの例を示す図である。 ＳＡＮ管理サーバが行うストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理の一例を示すフローチャートである。 ＳＡＮ管理サーバが行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 ＳＡＮ管理サーバが行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 ＳＡＮ管理サーバが行う障害切り分け処理の一例を示すフローチャートである。 ＳＡＮ管理サーバが出力する、障害切り分け結果表示の一例を示す図である。 ＳＡＮ管理サーバが行うＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例を示すフローチャートである。 ＳＮＭＰ Ｔｒａｐメッセージの構成例を示す図である。 ＳＡＮの構成例を示す図である。 ＳＡＮの構成例を示す図である。

符号の説明

１００００：ＳＡＮ管理サーバ
１３１００：ＳＡＮマネージャ
２００００：サーバ
３００００：スイッチ
４００００：ストレージ装置Ａ
５００００：ストレージ装置Ｂ
２３１００：サーバの管理エージェント
３３１００：スイッチの管理エージェント
４３１００：ストレージ装置Ａの管理エージェント
５３１００：ストレージ装置Ｂの管理エージェント
４７０００：ストレージ装置Ａの提供する実ボリューム
４８０００：ストレージ装置Ａの提供する仮想ボリューム
５７０００：ストレージ装置Ｂの提供する実ボリューム

Claims (12)

1. 実ボリュームを有する記憶装置と、
   ネットワークを介して前記記憶装置と接続され、前記記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置と、
   前記記憶装置及び前記バーチャリゼーション装置と管理ネットワークを介して接続される管理サーバとを有するシステムにおける、障害情報管理方法であって、
   一定期間における前記記憶装置内の第１及び第２の実ボリュームと関係のある障害を前記記憶装置が検知し、一定期間における前記バーチャリゼーション装置内の第３及び第４の仮想ボリュームと関係のある障害を前記バーチャリゼーション装置が検知する障害検知ステップと、
   前記管理サーバが、前記記憶装置から前記第１及び第２の実ボリュームについての障害通知を、前記バーチャリゼーション装置から前記第３及び第４の仮想ボリュームについての障害通知を受信する障害通知受信ステップと、
   前記バーチャリゼーション装置が管理する実ボリュームの識別情報と仮想ボリュームの識別情報との対応テーブルに基づいて、前記管理サーバが、前記第１の実ボリュームに対応する仮想ボリュームが前記第３の仮想ボリュームであることを特定し、前記第３の仮想ボリュームについての障害通知と前記第１の実ボリュームについての障害通知とを第１の障害関連情報として関連付け、前記第２の実ボリュームに対応する仮想ボリュームが前記第４の仮想ボリュームであることを特定し、前記第４の仮想ボリュームについての障害通知と前記第２の実ボリュームについての障害通知とを第２の障害関連情報として関連付ける関連付けステップと、
   前記第１の障害関連情報と前記第２の障害関連情報とを異なる障害関連情報として出力する障害メッセージ出力ステップとを有することを特徴とする障害情報管理方法。
2. 請求項１記載の障害情報管理方法において、
   更に、前記管理サーバが、前記ネットワークに接続される装置から前記ネットワークの構成情報を受信するステップと、
   前記管理サーバが、前記構成情報に基づいて、前記実ボリュームと前記仮想ボリュームとの対応関係を特定するステップとを有することを特徴とする障害情報管理方法。
3. 請求項１記載の障害情報管理方法において、
   更に、前記関連付けられた第１の障害関連情報について、前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知の障害を原因として、前記第３の仮想ボリュームまたは前記第１の実ボリュームについての障害通知が発行されることを特定する障害要因特定ステップを有することを特徴とする障害情報管理方法。
4. 請求項３記載の障害情報管理方法において、
   前記障害要因特定ステップは、前記第１の障害関連情報について、ハードウェアの故障によって通知される前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知とを特定するステップであることを特徴とする障害情報管理方法。
5. 請求項１記載の障害情報管理方法において、
   更に、前記記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害の重要度を表す複数の重要度情報を、前記記憶装置及びバーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に前記管理サーバが変換するステップと、
   変換後の重要度情報に基づいて、予め定められた方法で、前記管理サーバが障害関連情報を出力するステップを有することを特徴とする障害情報管理方法。
6. 請求項１記載の障害情報管理方法において、
   前記システムは、更に、前記記憶装置、前記バーチャリゼーション装置、及び前記管理サーバを相互に接続するスイッチを有し、
   前記障害検知ステップは、前記スイッチの障害を検知するステップを有し、
   前記障害通知受信ステップは、前記管理サーバが前記スイッチから障害通知を受信するステップを有し、
   前記関連付けステップは、前記バーチャリゼーション装置内の第３及び第４の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記記憶装置内の第１及び第２の実ボリュームについての障害通知と、前記スイッチからの障害通知とが関連するかを判断するステップを有し、
   前記スイッチからの障害通知が前記第１の実ボリューム及び前記第３の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第１の障害関連情報として出力し、前記スイッチからの障害通知が前記第２の実ボリューム及び前記第４の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第２の障害関連情報として出力する障害メッセージ出力ステップとを有することを特徴とする障害情報管理方法。
7. 実ボリュームを有する記憶装置と、ネットワークを介して前記記憶装置と接続され、前記記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置とに、管理ネットワークを介して接続される管理サーバであって、
   前記管理ネットワークに接続するためのインタフェース制御部と、
   プロセッサと、
   前記プロセッサが実行するプログラム及び前記プロセッサが使用する情報が格納されているメモリと、
   前記プロセッサによって実行される処理の処理結果を出力する出力部とを有し、
   前記インタフェース制御部は、前記記憶装置から一定期間における第１及び第２の実ボリュームについての障害通知を、前記バーチャリゼーション装置から一定期間における第３及び第４の仮想ボリュームについての障害通知を受信し、
   前記プロセッサは、前記バーチャリゼーション装置が管理する実ボリュームの識別情報と仮想ボリュームの識別情報との対応テーブルに基づいて、前記第１の実ボリュームに対応する仮想ボリュームが前記第３の仮想ボリュームであることを特定し、前記第３の仮想ボリュームについての障害通知と前記第１の実ボリュームについての障害通知とを第１の障害関連情報として関連付け、前記第２の実ボリュームに対応する仮想ボリュームが前記第４の仮想ボリュームであることを特定し、前記第４の仮想ボリュームについての障害通知と前記第２の実ボリュームについての障害通知とを第２の障害関連情報として関連付け、
   前記出力部は、前記第１の障害関連情報と前記第２の障害関連情報とを異なる障害関連情報として出力することを特徴とする管理サーバ。
8. 請求項７記載の管理サーバにおいて、
   前記インタフェース制御部は、前記ネットワークに接続される装置から前記ネットワークの構成情報を受信し、
   前記プロセッサは、前記構成情報に基づいて、前記実ボリュームと前記仮想ボリュームとの対応関係を特定することを有することを特徴とする管理サーバ。
9. 請求項７記載の管理サーバにおいて、
   前記プロセッサは、更に、前記関連付けられた第１の障害関連情報について、前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知の障害を原因として、前記第３の仮想ボリュームまたは前記第１の実ボリュームについての障害通知が発行されることを特定することを特徴とする管理サーバ。
10. 請求項９記載の管理サーバにおいて、
    前記プロセッサは、前記第１の障害関連情報について、ハードウェアの故障によって通知される前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される前記第１の実ボリュームまたは前記第３の仮想ボリュームについての障害通知とを特定することを特徴とする管理サーバ。
11. 請求項７記載の管理サーバにおいて、
    前記プロセッサは更に、前記記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害の重要度を表す複数の重要度情報を、前記記憶装置及びバーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に前記管理サーバが変換し、
    前記出力部は、変換後の重要度情報に基づいて、予め定められた方法で障害関連情報を出力することを特徴とする管理サーバ。
12. 請求項７記載の管理サーバにおいて、
    前記管理サーバは、前記記憶装置および前記バーチャリゼーション装置とスイッチを介して相互に接続され、
    前記インタフェース制御部は、前記スイッチから障害通知を受信し、
    前記プロセッサは、前記バーチャリゼーション装置内の第３及び第４の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記記憶装置内の第１及び第２の実ボリュームについての障害通知と、前記スイッチからの障害通知とが関連するかを判断し、
    前記出力部は、前記スイッチからの障害通知が前記第１の実ボリューム及び前記第３の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第１の障害関連情報として出力し、前記スイッチからの障害通知が前記第２の実ボリューム及び前記第４の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第２の障害関連情報として出力することを特徴とする管理サーバ。

Images