JP2005025483A - ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ - Google Patents
ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ Download PDFInfo
- Publication number
- JP2005025483A JP2005025483A JP2003189954A JP2003189954A JP2005025483A JP 2005025483 A JP2005025483 A JP 2005025483A JP 2003189954 A JP2003189954 A JP 2003189954A JP 2003189954 A JP2003189954 A JP 2003189954A JP 2005025483 A JP2005025483 A JP 2005025483A
- Authority
- JP
- Japan
- Prior art keywords
- failure
- san
- information
- volume
- management server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0766—Error or fault reporting or storing
- G06F11/0781—Error filtering or prioritizing based on a policy defined by the user or on a policy defined by a hardware/software module, e.g. according to a severity level
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0727—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a storage system, e.g. in a DASD or network based storage system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
- H04L41/065—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis involving logical or physical relationship, e.g. grouping and hierarchies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】仮想ボリュームを提供するＳＡＮで障害の切り分けるには、ＳＡＮ管理者の高度な知識が必要とされ、また、各装置から発行される障害イベントの相対的な重要性はＳＡＮ管理者が評価しなければならない。
【解決手段】ＳＡＮマネージャは、ＳＡＮ内の各装置の管理エージェントから情報を取得し、取得した情報をもとにＳＡＮにおけるサーバと仮想ボリュームと実ボリュームの対応関係を管理する。複数の装置から障害メッセージを受信したＳＡＮマネージャは、対応関係及び障害解析辞書テーブルを用いて、障害メッセージの内容と複数の障害メッセージ間の関連を調べ、原因となる障害を特定して表示する。
またＳＡＮマネージャは、複数のストレージ装置から発行される障害メッセージのＳｅｖｅｒｉｔｙを共通のＳｅｖｅｒｉｔｙに変換するため変換テーブルを有し、障害メッセージが受信されたとき、その変換テーブルに定義された共通のＳｅｖｅｒｉｔｙに応じて上位管理プログラムや管理者へ障害を通報する。
【選択図】 図１
【解決手段】ＳＡＮマネージャは、ＳＡＮ内の各装置の管理エージェントから情報を取得し、取得した情報をもとにＳＡＮにおけるサーバと仮想ボリュームと実ボリュームの対応関係を管理する。複数の装置から障害メッセージを受信したＳＡＮマネージャは、対応関係及び障害解析辞書テーブルを用いて、障害メッセージの内容と複数の障害メッセージ間の関連を調べ、原因となる障害を特定して表示する。
またＳＡＮマネージャは、複数のストレージ装置から発行される障害メッセージのＳｅｖｅｒｉｔｙを共通のＳｅｖｅｒｉｔｙに変換するため変換テーブルを有し、障害メッセージが受信されたとき、その変換テーブルに定義された共通のＳｅｖｅｒｉｔｙに応じて上位管理プログラムや管理者へ障害を通報する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、ストレージシステムを有する計算機システムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、仮想ボリュームとしてサーバに提供されるストレージエリアネットワーク（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ、以下ＳＡＮ）において、ストレージシステムの障害を管理する方法及び装置に関するものである。
【０００２】
【従来の技術】
（１）ＳＡＮについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるＳＡＮが浸透しつつある。ＳＡＮの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
【０００３】
（２）ＳＡＮ管理について
ＳＡＮによるストレージシステムの高い拡張性は、ＳＡＮにおける複数ベンダの装置（サーバ、スイッチ、ストレージ装置）の混在を可能とした。このようなＳＡＮを無停止で運用するために、ＳＡＮ管理が必要である。
【０００４】
ＳＡＮ管理の概要については、例えば非特許文献１で説明されている。ＳＡＮ管理の中でも、日々の運用の基本となる、ＳＡＮに接続される各装置の稼動状況監視が特に重要である。ＳＡＮの稼動状況を監視するためのソフトウェアを、以降ＳＡＮマネージャとよぶ。
【０００５】
ＳＡＮマネージャは、構成管理機能と障害監視機能の二大機能を持つ。
【０００６】
構成管理機能とは、ＳＡＮに接続される各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からＳＡＮの物理的な接続関係（トポロジ）を検出し、常に最新のトポロジを視覚化してＳＡＮマネージャのユーザ、言い換えるとＳＡＮ管理者に提供する機能である。
【０００７】
障害監視機能とは、ＳＡＮに接続される各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをＳＡＮ管理者に通知する機能である。
【０００８】
これら二つの機能により、ＳＡＮ管理者はＳＡＮマネージャを用いて装置の稼動状況を一元的に管理できるので、ＳＡＮ管理者の少人数化など運用コストの削減を図ることができる。
【０００９】
（３）バーチャリゼーション装置について
ＳＡＮにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献１に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。
【００１０】
１）ストレージサーバに接続された各ストレージ装置が有する記憶媒体内の記憶領域であるボリューム（以下実ボリューム）を管理し、ボリュームプールを生成する機能。
【００１１】
２）ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのＩ／Ｏアクセスを逐次実ボリュームへのＩ／Ｏ要求に変換してサーバからのＩ／Ｏに応答する機能。
【００１２】
これら二つの機能を有する装置を、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をＳＡＮに導入することにより、サーバへのボリューム割当は仮想ボリュームにより一元化され、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。つまり、ＳＡＮ管理者は一元的にボリュームの割当を行うことができる。
【００１３】
【特許文献１】
英国特許出願公開第２３５１３７５号明細書
【非特許文献１】
リチャードベーカー（Ｒｉｃｈａｒｄ Ｂａｒｋｅｒ）、ポールマッシグリア（Ｐａｕｌ Ｍａｓｓｉｇｌｉａ）、“ストレージエリアネットワークエッセンシャルズ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｅｓｓｅｎｔｉａｌｓ）”、ジョンウィリーアンドサンズインク（Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， Ｉｎｃ）、２００２年、ｐ．３３１−３３４
【００１４】
【発明が解決しようとする課題】
ＳＡＮマネージャの持つ障害監視機能により、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、どの装置のどの部位が障害の原因かを切り分ける作業を行う。以降これを、「障害の切り分け」と呼ぶ。バーチャリゼーション装置が仮想ボリュームを提供することにより、サーバに提供されるボリュームの構成自由度は高まる。しかし、ＳＡＮに接続される複数ベンダの装置から発行された障害メッセージ（ＳＮＭＰ Ｔｒａｐなど）をもとに障害の切り分けをするには、個々の装置について高度な知識を持ったＳＡＮ管理者の手動作業に頼っているのが現状であり、管理コストが非常に高いという課題がある。
【００１５】
また、ＳＡＮマネージャは、障害の深刻さ（以降Ｓｅｖｅｒｉｔｙと呼ぶ）に応じて、業務システム全体を運用管理する管理ソフトウェア（以降上位システム管理ソフトと呼ぶ）へイベントを通知したり、ＳＡＮ管理者へのメールを送信したりといった、障害通報機能を持つ。しかし、障害のＳｅｖｅｒｉｔｙの定義はＳＡＮに接続される各装置に依存するため、どの装置のどのイベントが高いＳｅｖｅｒｉｔｙを持つか、その都度ＳＡＮ管理者が判断する必要があり、障害対策に時間を要するという課題がある。
【００１６】
本発明の第一の目的は、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することである。
【００１７】
本発明の第二の目的は、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトが、ＳＡＮに接続される装置から発行された障害メッセージのうち、必要な障害情報を受信することができるようにすることである。
【００１８】
【課題を解決するための手段】
第一の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、複数の障害通知を関連づけて出力する。
【００１９】
又、第二の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する。
【００２０】
【発明の実施の形態】
以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発明が限定されるものではない。
【００２１】
＜ＳＡＮの構成＞
まず本実施形態におけるＳＡＮの構成例について説明する。図１から図６はＳＡＮ及びＳＡＮに接続される各装置の構成例を示し、図９から図１８は各装置内に具備された管理情報を示している。
【００２２】
図１にはＳＡＮの構成例を示す。本発明におけるＳＡＮは、管理エージェントを有する１台以上のサーバ、管理エージェントを有する１台以上のスイッチ、管理エージェントを有する１台以上のバーチャリゼーション装置、管理エージェントを有する１台以上のストレージ装置、そしてＳＡＮマネージャを有する１台のＳＡＮ管理サーバを有する。
【００２３】
以降の説明の都合上、本実施形態のＳＡＮにおいては、１台のサーバ（サーバＡ）２００００と、１台のスイッチ（スイッチＡ）３００００と、１台のバーチャリゼーション装置兼ストレージ装置（ストレージ装置Ａ）４００００と、１台のストレージ装置（ストレージ装置Ｂ ５００００）が、ファイバチャネル６００００を介して相互に接続されているものとする。本接続形態では、ストレージ装置Ａ４００００は、ストレージ装置Ｂ５００００の実ボリューム５７０００を、スイッチ３００００を介して認識し、仮想ボリューム機能を適用することにより、サーバに対してストレージ装置Ｂ５００００の実ボリューム５７０００を、ストレージ装置Ａ４００００の仮想化ボリュームとして提供する。なお、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００の接続形態については、図１に示す例の様にスイッチＡ３００００を介して接続するのではなく、例えば図２６に示す第二の構成例のように、ファイバチャネル６００００によって、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されていてもよい。また、図２７に示す第三の構成例のように、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されるパスと両ストレージ装置がスイッチ経由で接続されるパスとが混在していてもよい。
【００２４】
ＳＡＮ管理サーバ１００００は、管理用ネットワーク７００００を介してサーバ、スイッチ、及びストレージ装置それぞれに接続されており、各装置の管理エージェントとＳＡＮ管理サーバ１００００内のＳＡＮマネージャ１３１００は管理用ネットワークを介して通信できる。ＳＡＮマネージャ１３１００は、後述する処理により、ＳＡＮにおける仮想ボリュームと実ボリュームの構成管理と、ＳＡＮにおける障害切り分けと、ＳＡＮにおける障害通報を行う。
【００２５】
図２にはＳＡＮ管理サーバ１００００の構成例を示す。ＳＡＮ管理サーバ１００００は、プロセッサ１１０００と、メモリ１３０００と、管理用ネットワーク７００００に接続するための管理インタフェース制御部（以下、Ｉ／Ｆとする。）１４０００と、ＳＡＮマネージャ１３１００によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部１５０００と、ＳＡＮ管理者がＳＡＮマネージャに指示を入力するためのキーボード等の入力部１６０００を有し、これらは内部バス等の通信路１７０００を介して相互に接続される。
【００２６】
メモリ１３０００には、ＳＡＮ管理サーバによって実行されるプログラムであるＳＡＮマネージャ１３１００と、ＳＡＮにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル１３２００と、ＳＡＮにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル１３３００と、ＳＡＮ内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ１３４００と、ＳＡＮ内でＳＡＮマネージャ１３１００が管理対象としている装置の一覧を保持する装置検出リスト１３５００と、ＳＡＮ内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上の障害解析辞書１３６００と、イベント内容を記録するための障害ログ１３７００と、後述するＳｅｖｅｒｉｔｙ変換機能を行うにあたり、ＳＡＮ管理者により予め定義されるＳｅｖｅｒｉｔｙ変換定義を保持するための一つ以上の障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００とが格納されている。
【００２７】
図３にはサーバ２００００の構成例を示す。サーバ２００００は、プロセッサ２１０００と、メモリ２３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ２４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ２６０００を有し、これらは内部バス等の通信路２７０００を介して相互に接続される。
【００２８】
メモリ２３０００には、ＳＡＮマネージャ１３１００と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント２３１００と、当該サーバのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル２３２００と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル２３３００とが格納されている。
【００２９】
なお、本実施形態ではサーバはサーバＡの一台、サーバＡの具備するデータＩ／Ｆは一つとしたが、サーバ台数及びデータＩ／Ｆ数は一には限られず、サーバがＳＡＮに複数台接続されていても、又１台のサーバが複数のデータＩ／Ｆを備えていても良い。また、各サーバのデータＩ／Ｆには各サーバ内で固有の識別子（データＩ／Ｆ ＩＤ）が割当てられており、本実施例では、サーバＡのデータＩ／Ｆ ＩＤの値をａ１とする。
【００３０】
図４にはスイッチ３００００の構成例を示す。スイッチ３００００は、ファイバチャネル６００００を介して送受信されるデータのスイッチングを実現するコントローラ３１０００と、メモリ３３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ３４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ３６０００を有し、メモリ３３０００と管理Ｉ／Ｆ３４０００とデータＩ／Ｆ３６０００とはコントローラ３１０００を介して相互に接続される。
【００３１】
メモリ３３０００には、ＳＡＮマネージャ１３１００と通信して当該スイッチＡ の管理情報を送受信するためのプログラムである管理エージェント３３１００と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル６００００を介した接続関係を示す情報であるＦＣ接続管理テーブル３３２００とが格納されている。
【００３２】
なお、本実施形態ではＳＡＮ内に存在するスイッチはスイッチＡの一台とし、スイッチＡは６個のデータＩ／Ｆを有する構成としているが、スイッチの台数及びデータＩ／Ｆの個数は幾つであっても良い。また、各データＩ／Ｆは装置内（スイッチ内）で固有の識別子（データＩ／Ｆ ＩＤ）を持ち、本実施形態においてはその値をｓ１、ｓ２、ｓ３、ｓ４、ｓ５、ｓ６とする。
【００３３】
図５にはバーチャリゼーション装置兼ストレージ装置であるストレージ装置Ａの詳細な構成例を示す。ストレージ装置Ａ ４００００は、ストレージ装置内の制御を行うコントローラ４１０００と、メモリ４３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ４４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ４６０００と、サーバが利用するデータが格納されるディスク装置内の記憶領域である一つ以上の実ボリューム４７０００とを有し、メモリ４３０００と管理Ｉ／Ｆ４４０００とデータＩ／Ｆ４６０００と実ボリューム４７０００とはコントローラ４１０００を介して相互に接続される。尚図５にはコントローラ４１０００に接続される記憶領域として実ボリューム４７０００の他に、一つ以上の仮想ボリューム４８０００が図示されている。この仮想ボリューム４８０００は、他のストレージ装置（例えばストレージ装置Ｂ５００００）が保持する実ボリュームをストレージ装置Ａの仮想ボリューム機能により仮想化したものであり、仮想ボリューム４８０００はストレージ装置Ａのボリュームとしてサーバに提供される記憶領域であるため図５にストレージ装置Ａの構成要素として表示しているが、実際の記憶領域はストレージ装置Ａに接続される他のストレージ装置内に存在する。
【００３４】
メモリ４３０００には、ＳＡＮマネージャ１３１００と通信してストレージ装置Ａの管理情報を送受信するためのプログラムである管理エージェント４３１００と、ストレージ装置ＡのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル４３２００と、当該ストレージ装置Ａの実ボリューム４７０００の管理情報を保持する実ボリューム管理テーブル４３３００と、仮想ボリューム機能を実現するための仮想ボリューム管理プログラム４３４００と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル４３５００が格納されている。
【００３５】
なお本実施形態では、ストレージ装置Ａは２個のデータＩ／Ｆと２個の実ボリュームと２個の仮想ボリュームを有するが、データＩ／Ｆ、実ボリューム、及び仮想ボリュームの個数は幾つであっても良い。各データＩ／Ｆ、各実ボリューム、及び各仮想ボリュームは装置内固有の識別子（データＩ／Ｆ ＩＤ、実ボリュームＩＤ、仮想ボリュームＩＤ）を持ち、本実施形態ではデータＩ／Ｆ ＩＤの値をｃ１、ｃ２、実ボリュームＩＤの値をｖａ１、ｖａ２、仮想ボリュームＩＤの値をｖｖ１、ｖｖ２とする。
【００３６】
図６にはストレージ装置Ｂの詳細な構成例を示す。ストレージ装置Ｂは、仮想ボリューム機能を持たない点を除いて、ストレージ装置Ａと同様の構成を有する。よって、メモリ５３０００には仮想ボリューム管理プログラムと仮想ボリューム管理テーブルは存在しない。なお、本実施形態では、ストレージ装置Ｂは２個のデータＩ／Ｆと３個の実ボリュームを有するが、データＩ／Ｆ及び実ボリュームの数は幾つであっても良い。また、ストレージ装置ＢのデータＩ／Ｆ ＩＤの値はｄ１、ｄ２、ボリュームＩＤの値はｖｂ１、ｖｂ２、ｖｂ３とする。
【００３７】
図９にはＳＡＮ管理サーバ１００００が保持する装置検出リスト１３５００の一例を示す。図９の検出対象ＩＤ欄にはＳＡＮ管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはＳＡＮ内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、ＩＰアドレス情報欄には各装置の管理用ネットワーク７００００上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録され、仮想化対象ＩＤ欄には、装置情報としてストレージが登録されたエントリであり、当該ストレージ装置が有する実ボリュームが他の装置によって仮想化される場合、仮想化処理を実行する当該他の装置の検出対象ＩＤが登録される。これらの情報はＳＡＮ管理者がＳＡＮ管理サーバ１００００の出力部１５０００及び入力部１６０００を用いて予め設定するものとする。本リストに基づき、ＳＡＮマネージャ１３１００は各装置の管理エージェントを特定して当該管理エージェントと通信する。
【００３８】
図１０にサーバＡ ２００００が保持するデータＩ／Ｆ管理テーブルの一例を示す。図１０のデータＩ／Ｆ ＩＤ欄には各サーバが有するデータＩ／ＦのＩＤの値が登録され、Ｐｏｒｔ ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）欄には当該データＩ／Ｆに対して割り当てられているファイバチャネル内で一意の識別子となるＰｏｒｔ ＷＷＮが登録され、ＳＣＳＩ ＩＤ欄にはデータＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスの識別子（ＳＣＳＩ ＩＤ番号）が登録される。
【００３９】
図１１にサーバＡ ２００００が保持するボリューム管理テーブルの一例を示す。サーバＡは３つのボリュームの提供を受けており、サーバＡはボリューム管理テーブルに自身が提供を受けているボリュームの情報を保持する。ボリューム管理テーブルのＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ） ＩＤ欄には、サーバＡ内で自身が提供を受けているボリュームに対して任意に割当てた識別子が登録される。データＩ／Ｆ ＩＤ欄にはボリュームにアクセスするために使用するサーバＡ上のデータＩ／Ｆの識別子が登録され、ＳＣＳＩ ＩＤ欄には該データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄にはＳＣＳＩターゲットデバイス内の当該ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録され、ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、サーバに対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。
【００４０】
尚、図１１の例では、サーバＡは、ストレージ装置Ａから実ボリュームｖａ１と、実ボリュームはストレージＢ内に存在するがストレージ装置Ａによって仮想化されている仮想ボリュームｖｖ１との提供を受けて使用しており、ストレージ装置Ｂから実ボリュームｖｂ３の提供を受けて使用している。尚、ストレージ装置Ｂの実ボリュームｖｂ３は、ストレージ装置Ａによって仮想化されることなくサーバＡに提供されている。
【００４１】
図１２にスイッチＡ ３００００が保持するＦＣ接続管理テーブル３３３００の一例を示す。ＦＣ接続管理テーブルは、スイッチＡ ３００００のデータＩ／Ｆであるｓ１からｓ６の接続先に関する情報を保持する。ＦＣ接続管理テーブルのデータＩ／Ｆ ＩＤ欄にはスイッチＡ ３００００のデータＩ／ＦのＩＤの値が登録され、スイッチ Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録され、接続先Ｐｏｒｔ ＷＷＮ欄には当該データＩ／Ｆが接続するサーバやストレージ装置上のデータＩ／ＦのＰｏｒｔ ＷＷＮが登録される。
【００４２】
図１３にストレージ装置が保持するデータＩ／Ｆ管理テーブルの一例を示す。データＩ／Ｆ管理テーブル４３２００はストレージ装置Ａが、データＩ／Ｆ管理テーブル５３２００はストレージ装置Ｂが有するテーブルである。データＩ／Ｆ管理テーブルのデータＩ／Ｆ ＩＤ欄には、ストレージ装置が有するデータＩ／Ｆの識別子の値が登録され、Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録される。
【００４３】
図１４にストレージ装置が保持する実ボリューム管理テーブルの一例を示す。実ボリューム管理テーブル２３３００はストレージ装置Ａが、実ボリューム管理テーブル５３３００はストレージ装置Ｂが有するテーブルである。実ボリューム管理テーブルの実ボリュームＩＤ欄にはストレージ装置が有する実ボリュームのＩＤの値が登録され、パス有無欄には当該実ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームをアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＳＣＳＩ ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。なお、実ボリューム管理テーブル中のパス有無欄でパスが”無”と登録されている実ボリュームは、まだ未使用の実ボリュームである。よって、データＩ／Ｆ ＩＤ欄、ＳＣＳＩ ＩＤ欄、ＳＣＳＩ ＬＵＮ欄のそれぞれの値は未定義であることを示す”Ｎ／Ａ”を登録する。
【００４４】
図１５にストレージ装置Ａ ４００００が保持する仮想ボリューム管理テーブル４３５００の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想ボリュームＩＤ欄にはサーバに提供している仮想ボリュームに対して任意に割り当てた識別子が登録され、パス有無欄には当該仮想ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。本実施形態においては、ストレージ装置Ａ ４００００は、データＩ／Ｆ ｃ１から仮想ボリュームｖｖ１を提供している。仮想ボリュームｖｖ２は未使用である。
【００４５】
次に仮想ボリューム管理テーブル４３５００の実ボリューム欄の内容を説明する。実データＩ／Ｆ ＩＤ欄には、仮想ボリュームＩＤ欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、ストレージ装置Ａ上のデータＩ／Ｆの識別子が登録される。ＳＣＳＩ ＩＤ欄には当該実データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実データＩ／Ｆを介してストレージ装置から提供されるボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録さる。実ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、当該実データＩ／Ｆを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。
【００４６】
なお、仮想ボリューム管理テーブルには、仮想化装置（例えばストレージ装置Ａ）によって仮想化されるボリュームのデータのみが登録される。従って、データＩ／Ｆ ｃ２からアクセス可能で、ストレージ装置Ｂ内に存在する実ボリュームｖｂ１、ｖｂ２は、ストレージ装置Ａに認識されストレージ装置Ａによって仮想化され仮想ボリュームとしてサーバに提供されるので、仮想ボリューム管理テーブルに登録されている。また、データＩ／Ｆ ｃ１からアクセス可能な実ボリュームｖａ１は、ストレージ装置Ａ において仮想化されることなくサーバに提供されるため、ｖａ１に関する情報は仮想ボリューム管理テーブル４３５００に登録されていない。また、ストレージ装置Ｂの実ボリュームｖｂ３は、データＩ／Ｆｄ２を介してサーバＡに直接認識されているため、ｖｂ３に関する情報も、仮想ボリューム管理テーブル４３５００に登録されない。このように、ボリューム仮想化機能を保持するバーチャリゼーション装置は、全てのストレージ装置の実ボリュームを仮想化していなくてもよい。
【００４７】
図１６にはＳＡＮ管理サーバ１００００が有する障害解析辞書１３６００の例を示す。（ａ）はストレージ装置Ａの、（ｂ）はストレージ装置Ｂの、（ｃ）はサーバＡの、（ｄ）はスイッチＡの障害解析辞書である。これらの辞書は、各装置から障害発生時等に発行されるＳＮＭＰ Ｔｒａｐメッセージの解析に用いられるものであり、その詳細は後述する。障害コード欄にはＳＮＭＰ ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールド中の障害コードが、障害部位欄には各障害コードに対応する障害発生部位が、識別子欄には障害発生部位を特定するための識別子が、原因欄にはメッセージ発行の原因が、Ｓｅｖｅｒｉｔｙ欄にはＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールド中のＴｒａｐのＳｅｖｅｒｉｔｙが登録されている。
【００４８】
図１７にはＳＡＮ管理サーバ１００００が有する障害ログ１３７００を示す。障害ログにはＳＡＮマネージャが障害通知メッセージを受信した時に割り当てるイベントＩＤ、障害が発生した時刻、障害通知メッセージの送信元装置名、障害通知メッセージ中の障害コード、当該部位を含む実マッピングのＩＤ、当該部位を含む仮想マッピングのＩＤと、他の障害イベントとの関係が登録される
図１８には、ＳＡＮ管理サーバ１００００が有する障害Ｓｅｖｅｒｉｔｙ変換テーブルの一例を示す。本変換テーブルは、後述するＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理において、ＳＡＮマネージャが受信する複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作を定義するものである。本テーブルは、ＳＡＮ環境構築にあたりＳＡＮ管理者が定義するものとする。障害Ｓｅｖｅｒｉｔｙ変換テーブルには、複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに対応する各装置のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作が登録される。例えば図１８の場合、ストレージ装置ＡのＳｅｖｅｒｉｔｙが”３”のときと、ストレージ装置ＢのＳｅｖｅｒｉｔｙ”４”、”５”、”６”のとき、ＳＡＮ環境で共通のＳｅｖｅｒｉｔｙ”３”とみなされ、その結果、ＳＡＮマネージャは、ストレージ装置Ａの障害メッセージ情報のみをＳＮＭＰ Ｔｒａｐとして送信し、かつ、ＳＡＮ管理者にメールで送信する。尚、Ｓｅｖｅｒｉｔｙ変換テーブルは、ＳＡＮの構成情報に基づいて定義される。図１８に示すＳｅｖｅｒｉｔｙ変換テーブルにおいては例えば、ストレージＡのＳｅｖｅｒｉｔｙ３とストレージＢのＳｅｖｅｒｉｔｙ４〜５が共通Ｓｅｖｅｒｉｔｙ３として関連づけられており、共通Ｓｅｖｅｒｉｔｙ３の障害通知メッセージに関してはストレージＡに関する障害情報のみをＳＮＭＰ Ｔｒａｐとして送信し、ＳＡＮ管理者にメールで送信するよう定義されている。これは、ストレージＢが有する実ボリュームをストレージＡが仮想化してサーバに提供しており、ストレージＢが送受信する入出力要求はストレージＡを介してサーバが送受信することとなるからであり、従ってストレージＡのＳｅｖｅｒｉｔｙとストレージＢのＳｅｖｅｒｉｔｙとを関連付け、ストレージＡ及びストレージＢの実ボリュームを仮想化しているストレージＡに関する障害情報のみを出力するよう定義されているのである。
【００４９】
＜ＳＡＮマネージャの仮想ボリュームマッピング及び実ボリュームマッピング作成処理＞
次に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はＳＡＮ管理サーバ１００００のプロセッサ１１０００がメモリ１３０００内に格納されているプログラムを実行することによって定期的に実行されるもので、ＳＡＮ環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００５０】
図１９にＳＡＮマネージャ１３１００によって実行される実トポロジ及び仮想トポロジ表示処理の概要を表すフローチャート１７００を示す。ＳＡＮマネージャ１３１００は、装置検出リスト１３５００を元にＳＡＮ内の装置を検出し、各装置の管理エージェントと通信をして、各装置が保持する図１０から図１５に示す情報をコピーする（ステップ１７１０）。次にＳＡＮマネージャ１３１００はコピーした情報を実トポロジリポジトリ１３４００に格納する（ステップ１７２０）。その後、ステップ１７２０で格納した情報をもとに、後述する仮想ボリュームマッピング管理テーブル１３３００を作成する（ステップ１７３０）。さらに実トポロジリポジトリ１３４００内の情報と仮想ボリュームマッピング管理テーブル１３３００をもとに、後述する実ボリュームマッピング管理テーブル１３２００を作成する（ステップ１７４０）。最後に仮想ボリュームマッピング管理テーブル１３３００及び実ボリュームマッピング管理テーブル１３２００の内容をもとに、実トポロジなどの結果を出力し（ステップ１７５０）、終了する。
【００５１】
図２０にＳＡＮマネージャ１３１００によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ１７３０の詳細な処理を表すフローチャートを示す。また図８に図２０に示す処理によって作成される仮想ボリュームマッピング管理テーブル１３３００の一例を示す。
【００５２】
ＳＡＮマネージャ１３１００は、各サーバから受信して実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブル２３３００について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する（ステップ１８１０）。
【００５３】
まず、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルに新規エントリを作成し、新しく割り当てた仮想マッピングＩＤ１３３０１を登録する。更にＳＡＮマネージャは現在処理中のボリューム管理テーブル２３３００の送信元サーバ名１３３０２、ボリューム管理テーブルに記憶されているデータＩ／Ｆ ＩＤ１３３０４及びＬＵ ＩＤ１３３０３を登録する（ステップ１８２０）。次にＳＡＮマネージャは、登録されたデータＩ／Ｆ１３３０４が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前１３３０５とデータＩ／Ｆ ＩＤ１３３０６を登録する。具体的には、ＳＡＮマネージャはまず仮想ボリュームマッピング管理テーブル１３３００に登録されたサーバのデータＩ／Ｆ ＩＤ１３３０４をキーとして、当該サーバから受信して実トポロジデポジトリ１３４００に格納されているデータＩ／Ｆ管理テーブル２３２００を検索し、当該データＩ／Ｆ ＩＤのＰｏｒｔ ＷＷＮを調べる。さらにＳＡＮマネージャは当該Ｐｏｒｔ ＷＷＮをキーとして、スイッチＡ から受信して実トポロジデポジトリ１３４００に格納されているＦＣ接続管理テーブル３３２００を検索し、当該サーバがどのスイッチのどのデータＩ／Ｆに接続しているかを検索し、結果を接続先スイッチ名１３３０５と接続先スイッチデータＩ／Ｆ ＩＤ１３３０６として登録する（ステップ１８３０）。以上の処理により、仮想ボリュームマッピング管理テーブル１３３００の左半分（サーバ欄）にサーバに関する情報が登録される。
【００５４】
次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の左半分（ストレージ欄）に情報を登録するための処理を行う。ＳＡＮマネージャはボリューム管理テーブル２３３００にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーション装置によって提供されているものか否かを調べる。具体的には、ＳＡＮマネージャは装置名をキーとして装置検出リスト１３５００を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーション装置から提供されているものと判断する。（ステップ１８４０）。ステップ１８４０の結果により、以下のように処理が分岐する（ステップ１８５０）。
【００５５】
ボリュームがバーチャリゼーション装置 以外のストレージ装置から提供されている場合、ＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを、仮想ボリュームマッピング管理テーブル１３３００のストレージ欄にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは、登録したボリュームＩＤ１３３１１をキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索し、当該実ボリュームにアクセスするために使用されるデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６０）。そしてＳＡＮマネージャは、登録したストレージデータＩ／Ｆ１３３１０が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはまずストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、当該ストレージ装置から受信したデータＩ／Ｆ管理テーブルを検索し、当該ストレージデータＩ／ＦのＰｏｒｔ ＷＷＮを調べ、さらにＷＷＮをキーとして、スイッチＡ から受信したＦＣ接続管理テーブル３３２００を検索し、当該ストレージデータＩ／ＦがどのスイッチのどのデータＩ／Ｆに接続しているかを調査する。そしてＳＡＮマネージャは調査結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７０）。
【００５６】
ステップ１８５０においてボリュームがバーチャリゼーション装置から提供されていると判断した場合、ＳＡＮマネージャは以下の処理を行う。まずＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを仮想ボリュームマッピング管理テーブル１３３００にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは登録したボリュームＩＤ１３３１１をキーとして、バーチャリゼーション装置から受信した仮想ボリューム管理テーブル４３５００及び実ボリューム管理テーブル４３３００を検索し、当該ボリュームにアクセスするために使用されるストレージ装置ＡのデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６１）。次に、ストレージ装置Ａの当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、スイッチＡ から受信したデータＩ／Ｆ管理テーブル３３４００を検索し、当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆ ＩＤを調査して、結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７１）。
【００５７】
装置検出リスト１３５００に装置が未登録のためボリューム管理テーブル２３３００が実トポロジリポジトリ１３４００に格納されていない場合、及び、装置が管理Ｉ／Ｆを具備しない場合、ステップ１８５０では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル２３３００のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする（ステップ１８６２）。
【００５８】
以上のステップを、ＳＡＮ管理サーバが各サーバから受信し実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブルの全エントリに対して、ＳＡＮマネージャが実行したとき、ステップ１７３０の処理は終了する。
【００５９】
図２１に、ＳＡＮマネージャ１３１００が行う実ボリュームマッピング管理テーブル作成ステップ１７４０の詳細な処理フローを示す。又図７に図２１に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。
【００６０】
ＳＡＮマネージャ１３１００は、ステップ１７３０で作成した仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対して、以下の処理を実行する（ステップ１９１０）。
【００６１】
まず、ＳＡＮマネージャは新規エントリを作成し、新しく割り当てた実マッピングＩＤ１３２０１を登録する（ステップ１９２０）。次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の各エントリのストレージ名１３３０９をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名１３３０９をキーとして装置検出リスト１３５００を検索し、当該装置の仮想化機能の有無をチェックする（ステップ１９３０）。
【００６２】
仮想化機能を有する場合、ＳＡＮマネージャは以下のステップを実行する。ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルエントリ中のボリュームＩＤ１３３１１をキーとして、ストレージ名１３３０９が示す装置から受信した仮想ボリューム管理テーブル３３５００を検索し、ボリュームＩＤ１３３１１と一致する仮想ボリュームＩＤのエントリを抽出する（ステップ１９４０）。次にＳＡＮマネージャは、検索して得られたエントリの数と同数のエントリを実ボリューム管理マッピングテーブルに用意する（ステップ１９５０）。そして、ＳＡＮマネージャは、用意したエントリに対して、サーバ欄（１３２０２から１３２０６）には仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリのサーバ欄の内容（１３３０２から１３３０６）をコピーする。ストレージ欄のスイッチデータＩ／Ｆ ＩＤ欄１３２０８にはステップ１９４０で抽出した仮想ボリューム管理テーブル３３５００のエントリの、実ボリューム情報欄の実データＩ／Ｆ ＩＤの内容をコピーする。また、ストレージ欄のストレージ名エントリ１３２０９及びボリュームＩＤエントリ１３２１１には、仮想ボリューム管理テーブル４３５００の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームＩＤをコピーする。また対応仮想マッピングＩＤ欄１３２１２には仮想ボリュームマッピング管理テーブル１３３００中の仮想マッピングＩＤ１３３０１の内容を登録する。ストレージ欄のスイッチ名欄１３２０７には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名１３３０７の内容をコピーする（ステップ１９６０）。更に、ＳＡＮマネージャは、実ボリュームマッピング管理テーブル１３２１２のストレージ欄のボリュームＩＤ１３２１１に登録したボリュームＩＤをキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索して、当該ボリュームが接続されるデータＩ／ＦのＩＤを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータＩ／Ｆ ＩＤ１３２１０に登録する。
【００６３】
ステップ１９３０にて仮想化機能を有しないとの判断がされた場合、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリ（１３３０２から１３３１１）を実ボリュームマッピング管理テーブル１３２００のエントリ（１３２０２から１３２１１）へコピーし、仮想ボリュームマッピング管理テーブル１３３００の仮想マッピングＩＤ１３３０１の内容を実ボリュームマッピング管理テーブル１３２００の対応仮想マッピングＩＤ１３２１２に登録する。
【００６４】
以上の処理により実ボリュームマッピング管理テーブル１３２００のエントリ１３２０１から１３２１２までが登録される。
【００６５】
以上のステップを仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対してＳＡＮマネージャが実行したとき、ステップ１７４０に示す処理が終了する。
【００６６】
図７で示された実ボリュームマッピングテーブルをもとに、ＳＡＮマネージャ１３１００が出力部１５０００に出力する実トポロジ表示の例を図２３に示す。実ボリュームマッピング管理テーブル１３２００の内容をもとに、サーバ、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示２０１０である。
【００６７】
＜ＳＡＮマネージャの障害切り分け処理＞
以下に、ＳＡＮマネージャによる障害切り分け処理の一例について示す。
【００６８】
現在のＳＡＮ管理ソフトによる障害監視機能は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で作成されたＲＦＣ１１５７「Ａ Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＳＮＭＰ）」によって定められたＳＮＭＰプロトコルのＴｒａｐメッセージを利用することが多い。しかし、仮想ボリューム技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。また、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、障害の切り分けするには、現状個々の装置の高度な知識を持ったＳＡＮ管理者の手動作業に頼るため、管理コストが非常に高い。
【００６９】
そこで本処理では、複数の装置が発行する障害通知を受けたＳＡＮマネージャは、障害解析辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したＳＡＮの構成情報をもとに、それらの障害が実ボリューム及び仮想ボリュームへのＩ／Ｏアクセスに与える影響を解析する。また、当該障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる。そして、これらの結果をＳＡＮマネージャが出力することによって、ＳＡＮ管理者による複数障害メッセージの解析及び障害きりわけ作業を軽減する。
【００７０】
ここで、障害切り分け処理を説明する前に、図２５にＳＡＮ管理サーバ１００００上のＳＡＮマネージャがＳＡＮ内の各装置から受信するＳＮＭＰ Ｔｒａｐメッセージのフォーマットと、ＳＮＭＰ Ｔｒａｐメッセージの一例を示し、説明しておく。ここでＳＮＭＰ Ｔｒａｐメッセージとは、ＳＡＮ内の各装置の管理エージェントがＳＡＮ管理サーバ１００００に対して送信する障害通知メッセージのことである。図２５（ａ）は、ＳＮＭＰ Ｔｒａｐメッセージのフォーマットを図示したものである。ＳＮＭＰメッセージは、メッセージヘッダと、メッセージ送信先のコミュニティ名と、メッセージ種別を示すＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ） Ｔｙｐｅと、送信元装置のベンダ名を示すＥｎｔｅｒｐｒｉｓｅと、送信先ＩＰアドレスを示すＡｇｅｎｔ Ａｄｄｒｅｓｓと、Ｔｒａｐメッセージの種別を示すＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅと、ＴｒａｐメッセージのＳｅｖｅｒｉｔｙを示すＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅと、メッセージの送信時刻を示すＴｉｍｅｓｔａｍｐと、メッセージ内容を格納するＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓのフィールドから構成される。ＰＤＵ Ｔｙｐｅフィールドの値が”４”のとき、当該メッセージはＳＮＭＰ Ｔｒａｐメッセージであると識別される。またＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅフィールドの値が”６”のとき、当該ＳＮＭＰ Ｔｒａｐメッセージは送信元装置ベンダ固有の定義に基づくＴｒａｐメッセージと識別され、各ベンダによって定義されたＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドに記載されたＳｅｖｅｒｉｔｙと、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドに記載された障害コードの内容にもとづき、Ｔｒａｐメッセージを解釈する必要がある。
【００７１】
本実施形態において、ストレージＡ ４００００が自装置のハードウェア障害を通知するために送信するＳＮＭＰ Ｔｒａｐメッセージの一例を図２５（ｂ）に示す。図２５（ｂ）に示すメッセージは、ＰＤＵ Ｔｙｐｅが”４”であることからＳＮＭＰ Ｔｒａｐメッセージであると認識され、Ｇｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅが”６”であることから送信元ベンダ固有の定義に基づくＴｒａｐメッセージであると認識される。また、Ｓｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドには障害のＳｅｖｅｒｉｔｙを、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドには障害発生部位を示す障害コードを格納するようベンダが定義しているものとする。従って図２５（ｂ）に示すＳＮＭＰ Ｔｒａｐメッセージは、Ｓｅｖｅｒｉｔｙが”１”で障害コード”３０ｃ１”の障害が生じている旨を表している。
【００７２】
図２２に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理の一例を示すフローチャート２４００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００７３】
ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２４１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出し（ステップ２４１５）、抽出したＩＰアドレスをキーとして実トポロジリポジトリ１３４００に格納されている装置検出リスト１３５００を検索する（ステップ２４２０）。
【００７４】
ＩＰアドレスが装置検出リスト１３５００内に存在しない場合は、未登録の装置からのＴｒａｐメッセージであるためＳＡＮマネージャはＴｒａｐメッセージの内容を解析できない。従ってＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、障害装置としてＩＰアドレスを、障害部位としてＴｒａｐメッセージそのものを出力し（ステップ２４６５）、後述するステップ２４５５の処理にジャンプする。
【００７５】
ステップ２４２０において、抽出したＩＰアドレスが装置検出リスト１３５００内に存在し、Ｔｒａｐメッセージ発行元の装置が特定できた場合、ＳＡＮマネージャはＳＡＮ管理サーバ１００００が当該装置の障害解析辞書を具備しているか確認する（ステップ２４２５）。
【００７６】
ステップ２４２５にて障害解析辞書を具備している場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドをキーとして障害解析辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する（ステップ２４３０）。
【００７７】
ステップ２４２５で障害解析辞書を具備していないと判断した場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、ＳＡＮマネージャは、障害部位は装置全体みなし、障害コード欄には”装置全体”として登録し、以降のステップを継続する（ステップ２４３１）。
【００７８】
ステップ２４３０あるいはステップ２４３１が終了した後、ＳＡＮマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する（ステップ２４３５）。具体的には、まず、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【００７９】
その後、ＳＡＮマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する（ステップ２４４０）。具体的には、ステップ２４３５で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル４３５００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから仮想ボリュームＩＤを抽出する。さらに、抽出した仮想ボリュームＩＤをキーとして実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索し、実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【００８０】
ステップ２４３５とステップ２４４０で障害ログの作成中エントリの、実ボリュームマッピングと、仮想ボリュームマッピングの関係を登録した後、ＳＡＮマネージャは、当該作成中エントリと、他の障害ログエントリの関係について調査する。まず、ＳＡＮマネージャは、作成中のエントリが、ハード故障によるものか、他の部位へのアクセスエラーによるものかを調査する（ステップ２４４５）。具体的には、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとしてその原因を検索する。
【００８１】
ステップ２４４５で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある”親イベント”であると判断し、イベント関係欄に”親イベント”と登録する（ステップ２４５０）。ステップ２４４５で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある”子イベント”であると判断し、イベント関係欄に”子イベント”と登録する（ステップ２４５１）。
【００８２】
最後にＳＡＮマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する（ステップ２４５５）。以上でフローチャート２４００を終了する。
【００８３】
ここで、フローチャート２４００で示されたＳＡＮマネージャ１００００の障害切り分け処理の具体例について説明する。図２３は、図１７に記載された障害ログのエントリが、フローチャート２４００で示された障害切り分け処理により、どのように出力されるかの例を示す図である。ここで、イベントＩＤ １０００、１００１、１００２、１００３は、ストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。
【００８４】
イベントＩＤ １０００の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１のハード故障と解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりハード故障は”親イベント”であることがわかる。
【００８５】
次に、イベントＩＤ １００１の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置Ａの仮想ボリュームｖｖ１のＩ／Ｏを実ボリュームｖｂ１に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりアクセスエラーは”子イベント”であることがわかる。同様に、イベントＩＤ １００２の障害メッセージ及びイベントＩＤ １００３の障害メッセージも”子イベント”であることがわかる。
【００８６】
ステップ２４５５で障害メッセージを出力するにあたり、ＳＡＮマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は”親イベント”と”子イベント”のどちらかを特定する。ここで、「一定時間」とは、あらかじめＳＡＮ管理者が指定した時間で、障害の関連付けの単位となる時間である。図１７のイベントＩＤ １０００、１００１、１００２、１００３は、いずれも実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関連付けられ、かつ、イベントＩＤ １０００が”親イベント”であることがわかるので、図２３の障害イベント一覧ウィンドウ２０２０では、例えばイベント関連性欄にシンボル２０２１のように関連付けを示すことができる。
【００８７】
また、例えば、ＳＡＮ管理者がイベント指定２０２２のように、ある特定の障害イベントを指定したとき、ＳＡＮマネージャ１００００は、実トポロジ表示ウィンドウ２０１０中に、実トポロジマッピング表示２０１１のように指定されたイベントに対応する実トポロジマッピングを図示してもよい。さらに、障害通知ウィンドウ２０１２のように、指定されたイベントの内容を分かりやすく表示してもよい。
【００８８】
以上、ＳＡＮマネージャは、障害切り分け処理により、ＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる
＜ＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理＞
以下に、ＳＡＮマネージャによるＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例について示す。本処理では、ＳＡＮマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のＳｅｖｅｒｉｔｙ変換機能を保持し、ＳＡＮ管理者により予め定義された障害Ｓｅｖｅｒｉｔｙ変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のＳｅｖｅｒｉｔｙに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。
【００８９】
図２４に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理のフローチャート２５００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００９０】
ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２５１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出する（ステップ２５１５）。
【００９１】
抽出したＩＰアドレスを元に、ＳＡＮマネージャは、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あるかどうかを調査する（ステップ２５２０）。具体的には、はじめに、抽出したＩＰアドレスが装置検出リスト１３５００内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するＳｅｖｅｒｉｔｙ欄が、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００に存在するか調査する。
【００９２】
ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係ないと判断した場合は、ＳＡＮマネージャはＳｅｖｅｒｉｔｙ変換機能を行わず、Ｔｒａｐメッセージをそのまま上位管理ソフトに転送する（ステップ２５２６）。
【００９３】
ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あると判断した場合は、ＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドからメッセージ発行元装置のＳｅｖｅｒｉｔｙを抽出する（ステップ２５２５）。メッセージ発行元の装置名と、抽出したＳｅｖｅｒｉｔｙをもとに、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００を調査し、共通Ｓｅｖｅｒｉｔｙとアクションを特定する（ステップ２５３０）。最後に、ステップ２５３０で特定したアクションを実行する（ステップ２５３５）。以上でフローチャート２５００を終了する。
【００９４】
ここで、フローチャート２５００で示されたＳＡＮマネージャ１００００の障害通報処理の具体例について説明する。図１７に記載された障害ログのエントリのうち、イベントＩＤ ２０００のイベントが受信されたときを考える。イベントＩＤ ２０００の障害メッセージは、ステップ２５１５でストレージ装置Ｂが発行元装置であると判断されるので、ステップ２５２０で共通Ｓｅｖｅｒｉｔｙ定義に関係ある場合と判断される。ステップ２５２５においてＴｒａｐメッセージ中のＳｅｖｅｒｉｔｙは”４”であることから、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００記載のアクション「ストレージＡの情報をＴｒａｐ送信及びメール送信」を適用し、イベントＩＤ ２０００の障害メッセージは、上位管理ソフト及びＳＡＮ管理者には通報されない。
【００９５】
以上、ＳＡＮマネージャは、Ｓｅｖｅｒｉｔｙ変換機能を含む通報処理により、ＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じたＳＡＮマネージャの障害通報機能を提供することができる。
【００９６】
なお、ＳＡＮマネージャが実施するストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理、障害切り分け処理、Ｓｅｖｅｒｉｔｙ変換機能を含む障害通報処理は、ストレージ装置Ａ ４００００がバーチャリゼーション装置であることを想定していたが、ストレージ装置Ａ４００００とは異なる装置をバーチャリゼーション装置として管理ネットワーク７００００及びＳＡＮ６００００に接続した構成であっても、上述の処理は同様に実現可能である。
【００９７】
以上に説明した実施形態によれば、バーチャリゼーション装置を有するＳＡＮにおいて、ＳＡＮマネージャが実行される装置がＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、ＳＡＮマネージャが、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる。
【００９８】
また、ＳＡＮにおいてＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じた方法でＳＡＮマネージャが障害を通報することで、ＳＡＮ管理者や上位システム管理ソフトが、必要十分な障害情報のみを受信することになり、通報後の障害対策の迅速化が可能となる。
【００９９】
【発明の効果】
本発明によれば、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することができる。
【０１００】
また、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトは、ＳＡＮ内に存在する装置から発行された障害メッセージのうち、必要な障害情報を受信することができる。
【図面の簡単な説明】
【図１】ＳＡＮの構成例を示す図である。
【図２】ＳＡＮ管理サーバの構成例を示す図である。
【図３】サーバの構成例を示す図である。
【図４】スイッチの構成例を示す図である。
【図５】仮想化機能を有するストレージ装置の構成例を示す図である。
【図６】ストレージ装置の構成例を示す図である。
【図７】ＳＡＮ管理サーバが保持する実ボリュームマッピング管理テーブルの例を示す図である。
【図８】ＳＡＮ管理サーバが保持する仮想ボリュームマッピング管理テーブルの例を示す図である。
【図９】ＳＡＮ管理サーバが保持する装置検出リストの例を示す図である。
【図１０】サーバが保持するデータＩ／Ｆ管理テーブルの例を示す図である。
【図１１】サーバが保持するボリューム管理テーブルの例を示す図である。
【図１２】スイッチが保持するＦＣ接続管理テーブルの例を示す図である。
【図１３】ストレージ装置が保持するデータＩ／Ｆ管理テーブルの例を示す図である。
【図１４】ストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。
【図１５】ストレージ装置が保持する仮想ボリューム管理テーブルの例を示す図である。
【図１６】ＳＡＮ管理サーバが保持するストレージ装置に関する障害解析辞書テーブルの例を示す図である。
【図１７】ＳＡＮ管理サーバが保持する障害ログの例を示す図である。
【図１８】ＳＡＮ管理サーバが保持する障害Ｓｅｖｅｒｉｔｙ変換テーブルの例を示す図である。
【図１９】ＳＡＮ管理サーバが行うストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理の一例を示すフローチャートである。
【図２０】ＳＡＮ管理サーバが行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図２１】ＳＡＮ管理サーバが行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図２２】ＳＡＮ管理サーバが行う障害切り分け処理の一例を示すフローチャートである。
【図２３】ＳＡＮ管理サーバが出力する、障害切り分け結果表示の一例を示す図である。
【図２４】ＳＡＮ管理サーバが行うＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例を示すフローチャートである。
【図２５】ＳＮＭＰ Ｔｒａｐメッセージの構成例を示す図である。
【図２６】ＳＡＮの構成例を示す図である。
【図２７】ＳＡＮの構成例を示す図である。
【符号の説明】
１００００：ＳＡＮ管理サーバ
１３１００：ＳＡＮマネージャ
２００００：サーバ
３００００：スイッチ
４００００：ストレージ装置Ａ
５００００：ストレージ装置Ｂ
２３１００：サーバの管理エージェント
３３１００：スイッチの管理エージェント
４３１００：ストレージ装置Ａの管理エージェント
５３１００：ストレージ装置Ｂの管理エージェント
４７０００：ストレージ装置Ａの提供する実ボリューム
４８０００：ストレージ装置Ａの提供する仮想ボリューム
５７０００：ストレージ装置Ｂの提供する実ボリューム
【発明の属する技術分野】
本発明は、ストレージシステムを有する計算機システムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、仮想ボリュームとしてサーバに提供されるストレージエリアネットワーク（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ、以下ＳＡＮ）において、ストレージシステムの障害を管理する方法及び装置に関するものである。
【０００２】
【従来の技術】
（１）ＳＡＮについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるＳＡＮが浸透しつつある。ＳＡＮの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
【０００３】
（２）ＳＡＮ管理について
ＳＡＮによるストレージシステムの高い拡張性は、ＳＡＮにおける複数ベンダの装置（サーバ、スイッチ、ストレージ装置）の混在を可能とした。このようなＳＡＮを無停止で運用するために、ＳＡＮ管理が必要である。
【０００４】
ＳＡＮ管理の概要については、例えば非特許文献１で説明されている。ＳＡＮ管理の中でも、日々の運用の基本となる、ＳＡＮに接続される各装置の稼動状況監視が特に重要である。ＳＡＮの稼動状況を監視するためのソフトウェアを、以降ＳＡＮマネージャとよぶ。
【０００５】
ＳＡＮマネージャは、構成管理機能と障害監視機能の二大機能を持つ。
【０００６】
構成管理機能とは、ＳＡＮに接続される各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からＳＡＮの物理的な接続関係（トポロジ）を検出し、常に最新のトポロジを視覚化してＳＡＮマネージャのユーザ、言い換えるとＳＡＮ管理者に提供する機能である。
【０００７】
障害監視機能とは、ＳＡＮに接続される各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをＳＡＮ管理者に通知する機能である。
【０００８】
これら二つの機能により、ＳＡＮ管理者はＳＡＮマネージャを用いて装置の稼動状況を一元的に管理できるので、ＳＡＮ管理者の少人数化など運用コストの削減を図ることができる。
【０００９】
（３）バーチャリゼーション装置について
ＳＡＮにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献１に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。
【００１０】
１）ストレージサーバに接続された各ストレージ装置が有する記憶媒体内の記憶領域であるボリューム（以下実ボリューム）を管理し、ボリュームプールを生成する機能。
【００１１】
２）ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのＩ／Ｏアクセスを逐次実ボリュームへのＩ／Ｏ要求に変換してサーバからのＩ／Ｏに応答する機能。
【００１２】
これら二つの機能を有する装置を、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をＳＡＮに導入することにより、サーバへのボリューム割当は仮想ボリュームにより一元化され、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。つまり、ＳＡＮ管理者は一元的にボリュームの割当を行うことができる。
【００１３】
【特許文献１】
英国特許出願公開第２３５１３７５号明細書
【非特許文献１】
リチャードベーカー（Ｒｉｃｈａｒｄ Ｂａｒｋｅｒ）、ポールマッシグリア（Ｐａｕｌ Ｍａｓｓｉｇｌｉａ）、“ストレージエリアネットワークエッセンシャルズ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ Ｅｓｓｅｎｔｉａｌｓ）”、ジョンウィリーアンドサンズインク（Ｊｏｈｎ Ｗｉｌｅｙ ＆ Ｓｏｎｓ， Ｉｎｃ）、２００２年、ｐ．３３１−３３４
【００１４】
【発明が解決しようとする課題】
ＳＡＮマネージャの持つ障害監視機能により、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、どの装置のどの部位が障害の原因かを切り分ける作業を行う。以降これを、「障害の切り分け」と呼ぶ。バーチャリゼーション装置が仮想ボリュームを提供することにより、サーバに提供されるボリュームの構成自由度は高まる。しかし、ＳＡＮに接続される複数ベンダの装置から発行された障害メッセージ（ＳＮＭＰ Ｔｒａｐなど）をもとに障害の切り分けをするには、個々の装置について高度な知識を持ったＳＡＮ管理者の手動作業に頼っているのが現状であり、管理コストが非常に高いという課題がある。
【００１５】
また、ＳＡＮマネージャは、障害の深刻さ（以降Ｓｅｖｅｒｉｔｙと呼ぶ）に応じて、業務システム全体を運用管理する管理ソフトウェア（以降上位システム管理ソフトと呼ぶ）へイベントを通知したり、ＳＡＮ管理者へのメールを送信したりといった、障害通報機能を持つ。しかし、障害のＳｅｖｅｒｉｔｙの定義はＳＡＮに接続される各装置に依存するため、どの装置のどのイベントが高いＳｅｖｅｒｉｔｙを持つか、その都度ＳＡＮ管理者が判断する必要があり、障害対策に時間を要するという課題がある。
【００１６】
本発明の第一の目的は、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することである。
【００１７】
本発明の第二の目的は、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトが、ＳＡＮに接続される装置から発行された障害メッセージのうち、必要な障害情報を受信することができるようにすることである。
【００１８】
【課題を解決するための手段】
第一の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、複数の障害通知を関連づけて出力する。
【００１９】
又、第二の目的に対して、ＳＡＮに接続された装置から複数の障害通知を受信する管理サーバは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する。
【００２０】
【発明の実施の形態】
以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発明が限定されるものではない。
【００２１】
＜ＳＡＮの構成＞
まず本実施形態におけるＳＡＮの構成例について説明する。図１から図６はＳＡＮ及びＳＡＮに接続される各装置の構成例を示し、図９から図１８は各装置内に具備された管理情報を示している。
【００２２】
図１にはＳＡＮの構成例を示す。本発明におけるＳＡＮは、管理エージェントを有する１台以上のサーバ、管理エージェントを有する１台以上のスイッチ、管理エージェントを有する１台以上のバーチャリゼーション装置、管理エージェントを有する１台以上のストレージ装置、そしてＳＡＮマネージャを有する１台のＳＡＮ管理サーバを有する。
【００２３】
以降の説明の都合上、本実施形態のＳＡＮにおいては、１台のサーバ（サーバＡ）２００００と、１台のスイッチ（スイッチＡ）３００００と、１台のバーチャリゼーション装置兼ストレージ装置（ストレージ装置Ａ）４００００と、１台のストレージ装置（ストレージ装置Ｂ ５００００）が、ファイバチャネル６００００を介して相互に接続されているものとする。本接続形態では、ストレージ装置Ａ４００００は、ストレージ装置Ｂ５００００の実ボリューム５７０００を、スイッチ３００００を介して認識し、仮想ボリューム機能を適用することにより、サーバに対してストレージ装置Ｂ５００００の実ボリューム５７０００を、ストレージ装置Ａ４００００の仮想化ボリュームとして提供する。なお、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００の接続形態については、図１に示す例の様にスイッチＡ３００００を介して接続するのではなく、例えば図２６に示す第二の構成例のように、ファイバチャネル６００００によって、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されていてもよい。また、図２７に示す第三の構成例のように、ストレージ装置Ａ４００００とストレージ装置Ｂ５００００が直接接続されるパスと両ストレージ装置がスイッチ経由で接続されるパスとが混在していてもよい。
【００２４】
ＳＡＮ管理サーバ１００００は、管理用ネットワーク７００００を介してサーバ、スイッチ、及びストレージ装置それぞれに接続されており、各装置の管理エージェントとＳＡＮ管理サーバ１００００内のＳＡＮマネージャ１３１００は管理用ネットワークを介して通信できる。ＳＡＮマネージャ１３１００は、後述する処理により、ＳＡＮにおける仮想ボリュームと実ボリュームの構成管理と、ＳＡＮにおける障害切り分けと、ＳＡＮにおける障害通報を行う。
【００２５】
図２にはＳＡＮ管理サーバ１００００の構成例を示す。ＳＡＮ管理サーバ１００００は、プロセッサ１１０００と、メモリ１３０００と、管理用ネットワーク７００００に接続するための管理インタフェース制御部（以下、Ｉ／Ｆとする。）１４０００と、ＳＡＮマネージャ１３１００によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部１５０００と、ＳＡＮ管理者がＳＡＮマネージャに指示を入力するためのキーボード等の入力部１６０００を有し、これらは内部バス等の通信路１７０００を介して相互に接続される。
【００２６】
メモリ１３０００には、ＳＡＮ管理サーバによって実行されるプログラムであるＳＡＮマネージャ１３１００と、ＳＡＮにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル１３２００と、ＳＡＮにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル１３３００と、ＳＡＮ内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ１３４００と、ＳＡＮ内でＳＡＮマネージャ１３１００が管理対象としている装置の一覧を保持する装置検出リスト１３５００と、ＳＡＮ内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上の障害解析辞書１３６００と、イベント内容を記録するための障害ログ１３７００と、後述するＳｅｖｅｒｉｔｙ変換機能を行うにあたり、ＳＡＮ管理者により予め定義されるＳｅｖｅｒｉｔｙ変換定義を保持するための一つ以上の障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００とが格納されている。
【００２７】
図３にはサーバ２００００の構成例を示す。サーバ２００００は、プロセッサ２１０００と、メモリ２３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ２４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ２６０００を有し、これらは内部バス等の通信路２７０００を介して相互に接続される。
【００２８】
メモリ２３０００には、ＳＡＮマネージャ１３１００と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント２３１００と、当該サーバのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル２３２００と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル２３３００とが格納されている。
【００２９】
なお、本実施形態ではサーバはサーバＡの一台、サーバＡの具備するデータＩ／Ｆは一つとしたが、サーバ台数及びデータＩ／Ｆ数は一には限られず、サーバがＳＡＮに複数台接続されていても、又１台のサーバが複数のデータＩ／Ｆを備えていても良い。また、各サーバのデータＩ／Ｆには各サーバ内で固有の識別子（データＩ／Ｆ ＩＤ）が割当てられており、本実施例では、サーバＡのデータＩ／Ｆ ＩＤの値をａ１とする。
【００３０】
図４にはスイッチ３００００の構成例を示す。スイッチ３００００は、ファイバチャネル６００００を介して送受信されるデータのスイッチングを実現するコントローラ３１０００と、メモリ３３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ３４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ３６０００を有し、メモリ３３０００と管理Ｉ／Ｆ３４０００とデータＩ／Ｆ３６０００とはコントローラ３１０００を介して相互に接続される。
【００３１】
メモリ３３０００には、ＳＡＮマネージャ１３１００と通信して当該スイッチＡ の管理情報を送受信するためのプログラムである管理エージェント３３１００と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル６００００を介した接続関係を示す情報であるＦＣ接続管理テーブル３３２００とが格納されている。
【００３２】
なお、本実施形態ではＳＡＮ内に存在するスイッチはスイッチＡの一台とし、スイッチＡは６個のデータＩ／Ｆを有する構成としているが、スイッチの台数及びデータＩ／Ｆの個数は幾つであっても良い。また、各データＩ／Ｆは装置内（スイッチ内）で固有の識別子（データＩ／Ｆ ＩＤ）を持ち、本実施形態においてはその値をｓ１、ｓ２、ｓ３、ｓ４、ｓ５、ｓ６とする。
【００３３】
図５にはバーチャリゼーション装置兼ストレージ装置であるストレージ装置Ａの詳細な構成例を示す。ストレージ装置Ａ ４００００は、ストレージ装置内の制御を行うコントローラ４１０００と、メモリ４３０００と、管理用ネットワーク７００００に接続するための管理Ｉ／Ｆ４４０００と、ファイバチャネル６００００に接続するための一つ以上のデータＩ／Ｆ４６０００と、サーバが利用するデータが格納されるディスク装置内の記憶領域である一つ以上の実ボリューム４７０００とを有し、メモリ４３０００と管理Ｉ／Ｆ４４０００とデータＩ／Ｆ４６０００と実ボリューム４７０００とはコントローラ４１０００を介して相互に接続される。尚図５にはコントローラ４１０００に接続される記憶領域として実ボリューム４７０００の他に、一つ以上の仮想ボリューム４８０００が図示されている。この仮想ボリューム４８０００は、他のストレージ装置（例えばストレージ装置Ｂ５００００）が保持する実ボリュームをストレージ装置Ａの仮想ボリューム機能により仮想化したものであり、仮想ボリューム４８０００はストレージ装置Ａのボリュームとしてサーバに提供される記憶領域であるため図５にストレージ装置Ａの構成要素として表示しているが、実際の記憶領域はストレージ装置Ａに接続される他のストレージ装置内に存在する。
【００３４】
メモリ４３０００には、ＳＡＮマネージャ１３１００と通信してストレージ装置Ａの管理情報を送受信するためのプログラムである管理エージェント４３１００と、ストレージ装置ＡのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル４３２００と、当該ストレージ装置Ａの実ボリューム４７０００の管理情報を保持する実ボリューム管理テーブル４３３００と、仮想ボリューム機能を実現するための仮想ボリューム管理プログラム４３４００と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル４３５００が格納されている。
【００３５】
なお本実施形態では、ストレージ装置Ａは２個のデータＩ／Ｆと２個の実ボリュームと２個の仮想ボリュームを有するが、データＩ／Ｆ、実ボリューム、及び仮想ボリュームの個数は幾つであっても良い。各データＩ／Ｆ、各実ボリューム、及び各仮想ボリュームは装置内固有の識別子（データＩ／Ｆ ＩＤ、実ボリュームＩＤ、仮想ボリュームＩＤ）を持ち、本実施形態ではデータＩ／Ｆ ＩＤの値をｃ１、ｃ２、実ボリュームＩＤの値をｖａ１、ｖａ２、仮想ボリュームＩＤの値をｖｖ１、ｖｖ２とする。
【００３６】
図６にはストレージ装置Ｂの詳細な構成例を示す。ストレージ装置Ｂは、仮想ボリューム機能を持たない点を除いて、ストレージ装置Ａと同様の構成を有する。よって、メモリ５３０００には仮想ボリューム管理プログラムと仮想ボリューム管理テーブルは存在しない。なお、本実施形態では、ストレージ装置Ｂは２個のデータＩ／Ｆと３個の実ボリュームを有するが、データＩ／Ｆ及び実ボリュームの数は幾つであっても良い。また、ストレージ装置ＢのデータＩ／Ｆ ＩＤの値はｄ１、ｄ２、ボリュームＩＤの値はｖｂ１、ｖｂ２、ｖｂ３とする。
【００３７】
図９にはＳＡＮ管理サーバ１００００が保持する装置検出リスト１３５００の一例を示す。図９の検出対象ＩＤ欄にはＳＡＮ管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはＳＡＮ内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、ＩＰアドレス情報欄には各装置の管理用ネットワーク７００００上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録され、仮想化対象ＩＤ欄には、装置情報としてストレージが登録されたエントリであり、当該ストレージ装置が有する実ボリュームが他の装置によって仮想化される場合、仮想化処理を実行する当該他の装置の検出対象ＩＤが登録される。これらの情報はＳＡＮ管理者がＳＡＮ管理サーバ１００００の出力部１５０００及び入力部１６０００を用いて予め設定するものとする。本リストに基づき、ＳＡＮマネージャ１３１００は各装置の管理エージェントを特定して当該管理エージェントと通信する。
【００３８】
図１０にサーバＡ ２００００が保持するデータＩ／Ｆ管理テーブルの一例を示す。図１０のデータＩ／Ｆ ＩＤ欄には各サーバが有するデータＩ／ＦのＩＤの値が登録され、Ｐｏｒｔ ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）欄には当該データＩ／Ｆに対して割り当てられているファイバチャネル内で一意の識別子となるＰｏｒｔ ＷＷＮが登録され、ＳＣＳＩ ＩＤ欄にはデータＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスの識別子（ＳＣＳＩ ＩＤ番号）が登録される。
【００３９】
図１１にサーバＡ ２００００が保持するボリューム管理テーブルの一例を示す。サーバＡは３つのボリュームの提供を受けており、サーバＡはボリューム管理テーブルに自身が提供を受けているボリュームの情報を保持する。ボリューム管理テーブルのＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ） ＩＤ欄には、サーバＡ内で自身が提供を受けているボリュームに対して任意に割当てた識別子が登録される。データＩ／Ｆ ＩＤ欄にはボリュームにアクセスするために使用するサーバＡ上のデータＩ／Ｆの識別子が登録され、ＳＣＳＩ ＩＤ欄には該データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄にはＳＣＳＩターゲットデバイス内の当該ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録され、ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、サーバに対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。
【００４０】
尚、図１１の例では、サーバＡは、ストレージ装置Ａから実ボリュームｖａ１と、実ボリュームはストレージＢ内に存在するがストレージ装置Ａによって仮想化されている仮想ボリュームｖｖ１との提供を受けて使用しており、ストレージ装置Ｂから実ボリュームｖｂ３の提供を受けて使用している。尚、ストレージ装置Ｂの実ボリュームｖｂ３は、ストレージ装置Ａによって仮想化されることなくサーバＡに提供されている。
【００４１】
図１２にスイッチＡ ３００００が保持するＦＣ接続管理テーブル３３３００の一例を示す。ＦＣ接続管理テーブルは、スイッチＡ ３００００のデータＩ／Ｆであるｓ１からｓ６の接続先に関する情報を保持する。ＦＣ接続管理テーブルのデータＩ／Ｆ ＩＤ欄にはスイッチＡ ３００００のデータＩ／ＦのＩＤの値が登録され、スイッチ Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録され、接続先Ｐｏｒｔ ＷＷＮ欄には当該データＩ／Ｆが接続するサーバやストレージ装置上のデータＩ／ＦのＰｏｒｔ ＷＷＮが登録される。
【００４２】
図１３にストレージ装置が保持するデータＩ／Ｆ管理テーブルの一例を示す。データＩ／Ｆ管理テーブル４３２００はストレージ装置Ａが、データＩ／Ｆ管理テーブル５３２００はストレージ装置Ｂが有するテーブルである。データＩ／Ｆ管理テーブルのデータＩ／Ｆ ＩＤ欄には、ストレージ装置が有するデータＩ／Ｆの識別子の値が登録され、Ｐｏｒｔ ＷＷＮ欄には当該データＩ／ＦのＰｏｒｔ ＷＷＮが登録される。
【００４３】
図１４にストレージ装置が保持する実ボリューム管理テーブルの一例を示す。実ボリューム管理テーブル２３３００はストレージ装置Ａが、実ボリューム管理テーブル５３３００はストレージ装置Ｂが有するテーブルである。実ボリューム管理テーブルの実ボリュームＩＤ欄にはストレージ装置が有する実ボリュームのＩＤの値が登録され、パス有無欄には当該実ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームをアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＳＣＳＩ ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。なお、実ボリューム管理テーブル中のパス有無欄でパスが”無”と登録されている実ボリュームは、まだ未使用の実ボリュームである。よって、データＩ／Ｆ ＩＤ欄、ＳＣＳＩ ＩＤ欄、ＳＣＳＩ ＬＵＮ欄のそれぞれの値は未定義であることを示す”Ｎ／Ａ”を登録する。
【００４４】
図１５にストレージ装置Ａ ４００００が保持する仮想ボリューム管理テーブル４３５００の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想ボリュームＩＤ欄にはサーバに提供している仮想ボリュームに対して任意に割り当てた識別子が登録され、パス有無欄には当該仮想ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。本実施形態においては、ストレージ装置Ａ ４００００は、データＩ／Ｆ ｃ１から仮想ボリュームｖｖ１を提供している。仮想ボリュームｖｖ２は未使用である。
【００４５】
次に仮想ボリューム管理テーブル４３５００の実ボリューム欄の内容を説明する。実データＩ／Ｆ ＩＤ欄には、仮想ボリュームＩＤ欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、ストレージ装置Ａ上のデータＩ／Ｆの識別子が登録される。ＳＣＳＩ ＩＤ欄には当該実データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実データＩ／Ｆを介してストレージ装置から提供されるボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録さる。実ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、当該実データＩ／Ｆを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。
【００４６】
なお、仮想ボリューム管理テーブルには、仮想化装置（例えばストレージ装置Ａ）によって仮想化されるボリュームのデータのみが登録される。従って、データＩ／Ｆ ｃ２からアクセス可能で、ストレージ装置Ｂ内に存在する実ボリュームｖｂ１、ｖｂ２は、ストレージ装置Ａに認識されストレージ装置Ａによって仮想化され仮想ボリュームとしてサーバに提供されるので、仮想ボリューム管理テーブルに登録されている。また、データＩ／Ｆ ｃ１からアクセス可能な実ボリュームｖａ１は、ストレージ装置Ａ において仮想化されることなくサーバに提供されるため、ｖａ１に関する情報は仮想ボリューム管理テーブル４３５００に登録されていない。また、ストレージ装置Ｂの実ボリュームｖｂ３は、データＩ／Ｆｄ２を介してサーバＡに直接認識されているため、ｖｂ３に関する情報も、仮想ボリューム管理テーブル４３５００に登録されない。このように、ボリューム仮想化機能を保持するバーチャリゼーション装置は、全てのストレージ装置の実ボリュームを仮想化していなくてもよい。
【００４７】
図１６にはＳＡＮ管理サーバ１００００が有する障害解析辞書１３６００の例を示す。（ａ）はストレージ装置Ａの、（ｂ）はストレージ装置Ｂの、（ｃ）はサーバＡの、（ｄ）はスイッチＡの障害解析辞書である。これらの辞書は、各装置から障害発生時等に発行されるＳＮＭＰ Ｔｒａｐメッセージの解析に用いられるものであり、その詳細は後述する。障害コード欄にはＳＮＭＰ ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールド中の障害コードが、障害部位欄には各障害コードに対応する障害発生部位が、識別子欄には障害発生部位を特定するための識別子が、原因欄にはメッセージ発行の原因が、Ｓｅｖｅｒｉｔｙ欄にはＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールド中のＴｒａｐのＳｅｖｅｒｉｔｙが登録されている。
【００４８】
図１７にはＳＡＮ管理サーバ１００００が有する障害ログ１３７００を示す。障害ログにはＳＡＮマネージャが障害通知メッセージを受信した時に割り当てるイベントＩＤ、障害が発生した時刻、障害通知メッセージの送信元装置名、障害通知メッセージ中の障害コード、当該部位を含む実マッピングのＩＤ、当該部位を含む仮想マッピングのＩＤと、他の障害イベントとの関係が登録される
図１８には、ＳＡＮ管理サーバ１００００が有する障害Ｓｅｖｅｒｉｔｙ変換テーブルの一例を示す。本変換テーブルは、後述するＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理において、ＳＡＮマネージャが受信する複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作を定義するものである。本テーブルは、ＳＡＮ環境構築にあたりＳＡＮ管理者が定義するものとする。障害Ｓｅｖｅｒｉｔｙ変換テーブルには、複数の装置の障害メッセージに対する共通のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに対応する各装置のＳｅｖｅｒｉｔｙと、共通のＳｅｖｅｒｉｔｙに応じてＳＡＮマネージャが実行する動作が登録される。例えば図１８の場合、ストレージ装置ＡのＳｅｖｅｒｉｔｙが”３”のときと、ストレージ装置ＢのＳｅｖｅｒｉｔｙ”４”、”５”、”６”のとき、ＳＡＮ環境で共通のＳｅｖｅｒｉｔｙ”３”とみなされ、その結果、ＳＡＮマネージャは、ストレージ装置Ａの障害メッセージ情報のみをＳＮＭＰ Ｔｒａｐとして送信し、かつ、ＳＡＮ管理者にメールで送信する。尚、Ｓｅｖｅｒｉｔｙ変換テーブルは、ＳＡＮの構成情報に基づいて定義される。図１８に示すＳｅｖｅｒｉｔｙ変換テーブルにおいては例えば、ストレージＡのＳｅｖｅｒｉｔｙ３とストレージＢのＳｅｖｅｒｉｔｙ４〜５が共通Ｓｅｖｅｒｉｔｙ３として関連づけられており、共通Ｓｅｖｅｒｉｔｙ３の障害通知メッセージに関してはストレージＡに関する障害情報のみをＳＮＭＰ Ｔｒａｐとして送信し、ＳＡＮ管理者にメールで送信するよう定義されている。これは、ストレージＢが有する実ボリュームをストレージＡが仮想化してサーバに提供しており、ストレージＢが送受信する入出力要求はストレージＡを介してサーバが送受信することとなるからであり、従ってストレージＡのＳｅｖｅｒｉｔｙとストレージＢのＳｅｖｅｒｉｔｙとを関連付け、ストレージＡ及びストレージＢの実ボリュームを仮想化しているストレージＡに関する障害情報のみを出力するよう定義されているのである。
【００４９】
＜ＳＡＮマネージャの仮想ボリュームマッピング及び実ボリュームマッピング作成処理＞
次に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はＳＡＮ管理サーバ１００００のプロセッサ１１０００がメモリ１３０００内に格納されているプログラムを実行することによって定期的に実行されるもので、ＳＡＮ環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００５０】
図１９にＳＡＮマネージャ１３１００によって実行される実トポロジ及び仮想トポロジ表示処理の概要を表すフローチャート１７００を示す。ＳＡＮマネージャ１３１００は、装置検出リスト１３５００を元にＳＡＮ内の装置を検出し、各装置の管理エージェントと通信をして、各装置が保持する図１０から図１５に示す情報をコピーする（ステップ１７１０）。次にＳＡＮマネージャ１３１００はコピーした情報を実トポロジリポジトリ１３４００に格納する（ステップ１７２０）。その後、ステップ１７２０で格納した情報をもとに、後述する仮想ボリュームマッピング管理テーブル１３３００を作成する（ステップ１７３０）。さらに実トポロジリポジトリ１３４００内の情報と仮想ボリュームマッピング管理テーブル１３３００をもとに、後述する実ボリュームマッピング管理テーブル１３２００を作成する（ステップ１７４０）。最後に仮想ボリュームマッピング管理テーブル１３３００及び実ボリュームマッピング管理テーブル１３２００の内容をもとに、実トポロジなどの結果を出力し（ステップ１７５０）、終了する。
【００５１】
図２０にＳＡＮマネージャ１３１００によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ１７３０の詳細な処理を表すフローチャートを示す。また図８に図２０に示す処理によって作成される仮想ボリュームマッピング管理テーブル１３３００の一例を示す。
【００５２】
ＳＡＮマネージャ１３１００は、各サーバから受信して実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブル２３３００について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する（ステップ１８１０）。
【００５３】
まず、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルに新規エントリを作成し、新しく割り当てた仮想マッピングＩＤ１３３０１を登録する。更にＳＡＮマネージャは現在処理中のボリューム管理テーブル２３３００の送信元サーバ名１３３０２、ボリューム管理テーブルに記憶されているデータＩ／Ｆ ＩＤ１３３０４及びＬＵ ＩＤ１３３０３を登録する（ステップ１８２０）。次にＳＡＮマネージャは、登録されたデータＩ／Ｆ１３３０４が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前１３３０５とデータＩ／Ｆ ＩＤ１３３０６を登録する。具体的には、ＳＡＮマネージャはまず仮想ボリュームマッピング管理テーブル１３３００に登録されたサーバのデータＩ／Ｆ ＩＤ１３３０４をキーとして、当該サーバから受信して実トポロジデポジトリ１３４００に格納されているデータＩ／Ｆ管理テーブル２３２００を検索し、当該データＩ／Ｆ ＩＤのＰｏｒｔ ＷＷＮを調べる。さらにＳＡＮマネージャは当該Ｐｏｒｔ ＷＷＮをキーとして、スイッチＡ から受信して実トポロジデポジトリ１３４００に格納されているＦＣ接続管理テーブル３３２００を検索し、当該サーバがどのスイッチのどのデータＩ／Ｆに接続しているかを検索し、結果を接続先スイッチ名１３３０５と接続先スイッチデータＩ／Ｆ ＩＤ１３３０６として登録する（ステップ１８３０）。以上の処理により、仮想ボリュームマッピング管理テーブル１３３００の左半分（サーバ欄）にサーバに関する情報が登録される。
【００５４】
次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の左半分（ストレージ欄）に情報を登録するための処理を行う。ＳＡＮマネージャはボリューム管理テーブル２３３００にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーション装置によって提供されているものか否かを調べる。具体的には、ＳＡＮマネージャは装置名をキーとして装置検出リスト１３５００を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーション装置から提供されているものと判断する。（ステップ１８４０）。ステップ１８４０の結果により、以下のように処理が分岐する（ステップ１８５０）。
【００５５】
ボリュームがバーチャリゼーション装置 以外のストレージ装置から提供されている場合、ＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを、仮想ボリュームマッピング管理テーブル１３３００のストレージ欄にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは、登録したボリュームＩＤ１３３１１をキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索し、当該実ボリュームにアクセスするために使用されるデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６０）。そしてＳＡＮマネージャは、登録したストレージデータＩ／Ｆ１３３１０が接続されるスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはまずストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、当該ストレージ装置から受信したデータＩ／Ｆ管理テーブルを検索し、当該ストレージデータＩ／ＦのＰｏｒｔ ＷＷＮを調べ、さらにＷＷＮをキーとして、スイッチＡ から受信したＦＣ接続管理テーブル３３２００を検索し、当該ストレージデータＩ／ＦがどのスイッチのどのデータＩ／Ｆに接続しているかを調査する。そしてＳＡＮマネージャは調査結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７０）。
【００５６】
ステップ１８５０においてボリュームがバーチャリゼーション装置から提供されていると判断した場合、ＳＡＮマネージャは以下の処理を行う。まずＳＡＮマネージャはボリューム管理テーブル２３３００のボリューム情報欄に登録されている装置名とボリュームＩＤを仮想ボリュームマッピング管理テーブル１３３００にストレージ名１３３０９及びボリュームＩＤ１３３１１として登録する。更にＳＡＮマネージャは登録したボリュームＩＤ１３３１１をキーとして、バーチャリゼーション装置から受信した仮想ボリューム管理テーブル４３５００及び実ボリューム管理テーブル４３３００を検索し、当該ボリュームにアクセスするために使用されるストレージ装置ＡのデータＩ／ＦのＩＤを調査し、結果をストレージデータＩ／Ｆ ＩＤ１３３１０として登録する（ステップ１８６１）。次に、ストレージ装置Ａの当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆを調査し、スイッチの名前とデータＩ／Ｆ ＩＤを登録する。具体的には、ＳＡＮマネージャはストレージデータＩ／Ｆ ＩＤ１３３１０をキーとして、スイッチＡ から受信したデータＩ／Ｆ管理テーブル３３４００を検索し、当該データＩ／Ｆに対応するスイッチのデータＩ／Ｆ ＩＤを調査して、結果を接続先スイッチ名１３３０７と接続先スイッチデータＩ／Ｆ ＩＤ１３３０８として登録する（ステップ１８７１）。
【００５７】
装置検出リスト１３５００に装置が未登録のためボリューム管理テーブル２３３００が実トポロジリポジトリ１３４００に格納されていない場合、及び、装置が管理Ｉ／Ｆを具備しない場合、ステップ１８５０では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル２３３００のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする（ステップ１８６２）。
【００５８】
以上のステップを、ＳＡＮ管理サーバが各サーバから受信し実トポロジリポジトリ１３４００に格納した全てのボリューム管理テーブルの全エントリに対して、ＳＡＮマネージャが実行したとき、ステップ１７３０の処理は終了する。
【００５９】
図２１に、ＳＡＮマネージャ１３１００が行う実ボリュームマッピング管理テーブル作成ステップ１７４０の詳細な処理フローを示す。又図７に図２１に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。
【００６０】
ＳＡＮマネージャ１３１００は、ステップ１７３０で作成した仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対して、以下の処理を実行する（ステップ１９１０）。
【００６１】
まず、ＳＡＮマネージャは新規エントリを作成し、新しく割り当てた実マッピングＩＤ１３２０１を登録する（ステップ１９２０）。次に、ＳＡＮマネージャは仮想ボリュームマッピング管理テーブル１３３００の各エントリのストレージ名１３３０９をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名１３３０９をキーとして装置検出リスト１３５００を検索し、当該装置の仮想化機能の有無をチェックする（ステップ１９３０）。
【００６２】
仮想化機能を有する場合、ＳＡＮマネージャは以下のステップを実行する。ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブルエントリ中のボリュームＩＤ１３３１１をキーとして、ストレージ名１３３０９が示す装置から受信した仮想ボリューム管理テーブル３３５００を検索し、ボリュームＩＤ１３３１１と一致する仮想ボリュームＩＤのエントリを抽出する（ステップ１９４０）。次にＳＡＮマネージャは、検索して得られたエントリの数と同数のエントリを実ボリューム管理マッピングテーブルに用意する（ステップ１９５０）。そして、ＳＡＮマネージャは、用意したエントリに対して、サーバ欄（１３２０２から１３２０６）には仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリのサーバ欄の内容（１３３０２から１３３０６）をコピーする。ストレージ欄のスイッチデータＩ／Ｆ ＩＤ欄１３２０８にはステップ１９４０で抽出した仮想ボリューム管理テーブル３３５００のエントリの、実ボリューム情報欄の実データＩ／Ｆ ＩＤの内容をコピーする。また、ストレージ欄のストレージ名エントリ１３２０９及びボリュームＩＤエントリ１３２１１には、仮想ボリューム管理テーブル４３５００の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームＩＤをコピーする。また対応仮想マッピングＩＤ欄１３２１２には仮想ボリュームマッピング管理テーブル１３３００中の仮想マッピングＩＤ１３３０１の内容を登録する。ストレージ欄のスイッチ名欄１３２０７には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名１３３０７の内容をコピーする（ステップ１９６０）。更に、ＳＡＮマネージャは、実ボリュームマッピング管理テーブル１３２１２のストレージ欄のボリュームＩＤ１３２１１に登録したボリュームＩＤをキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索して、当該ボリュームが接続されるデータＩ／ＦのＩＤを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータＩ／Ｆ ＩＤ１３２１０に登録する。
【００６３】
ステップ１９３０にて仮想化機能を有しないとの判断がされた場合、ＳＡＮマネージャは、仮想ボリュームマッピング管理テーブル１３３００の現在処理中のエントリ（１３３０２から１３３１１）を実ボリュームマッピング管理テーブル１３２００のエントリ（１３２０２から１３２１１）へコピーし、仮想ボリュームマッピング管理テーブル１３３００の仮想マッピングＩＤ１３３０１の内容を実ボリュームマッピング管理テーブル１３２００の対応仮想マッピングＩＤ１３２１２に登録する。
【００６４】
以上の処理により実ボリュームマッピング管理テーブル１３２００のエントリ１３２０１から１３２１２までが登録される。
【００６５】
以上のステップを仮想ボリュームマッピング管理テーブル１３３００の全てのエントリに対してＳＡＮマネージャが実行したとき、ステップ１７４０に示す処理が終了する。
【００６６】
図７で示された実ボリュームマッピングテーブルをもとに、ＳＡＮマネージャ１３１００が出力部１５０００に出力する実トポロジ表示の例を図２３に示す。実ボリュームマッピング管理テーブル１３２００の内容をもとに、サーバ、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示２０１０である。
【００６７】
＜ＳＡＮマネージャの障害切り分け処理＞
以下に、ＳＡＮマネージャによる障害切り分け処理の一例について示す。
【００６８】
現在のＳＡＮ管理ソフトによる障害監視機能は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で作成されたＲＦＣ１１５７「Ａ Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＳＮＭＰ）」によって定められたＳＮＭＰプロトコルのＴｒａｐメッセージを利用することが多い。しかし、仮想ボリューム技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。また、ＳＡＮ管理者は、複数の装置から発行されたイベントを元に、障害の切り分けするには、現状個々の装置の高度な知識を持ったＳＡＮ管理者の手動作業に頼るため、管理コストが非常に高い。
【００６９】
そこで本処理では、複数の装置が発行する障害通知を受けたＳＡＮマネージャは、障害解析辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したＳＡＮの構成情報をもとに、それらの障害が実ボリューム及び仮想ボリュームへのＩ／Ｏアクセスに与える影響を解析する。また、当該障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる。そして、これらの結果をＳＡＮマネージャが出力することによって、ＳＡＮ管理者による複数障害メッセージの解析及び障害きりわけ作業を軽減する。
【００７０】
ここで、障害切り分け処理を説明する前に、図２５にＳＡＮ管理サーバ１００００上のＳＡＮマネージャがＳＡＮ内の各装置から受信するＳＮＭＰ Ｔｒａｐメッセージのフォーマットと、ＳＮＭＰ Ｔｒａｐメッセージの一例を示し、説明しておく。ここでＳＮＭＰ Ｔｒａｐメッセージとは、ＳＡＮ内の各装置の管理エージェントがＳＡＮ管理サーバ１００００に対して送信する障害通知メッセージのことである。図２５（ａ）は、ＳＮＭＰ Ｔｒａｐメッセージのフォーマットを図示したものである。ＳＮＭＰメッセージは、メッセージヘッダと、メッセージ送信先のコミュニティ名と、メッセージ種別を示すＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ） Ｔｙｐｅと、送信元装置のベンダ名を示すＥｎｔｅｒｐｒｉｓｅと、送信先ＩＰアドレスを示すＡｇｅｎｔ Ａｄｄｒｅｓｓと、Ｔｒａｐメッセージの種別を示すＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅと、ＴｒａｐメッセージのＳｅｖｅｒｉｔｙを示すＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅと、メッセージの送信時刻を示すＴｉｍｅｓｔａｍｐと、メッセージ内容を格納するＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓのフィールドから構成される。ＰＤＵ Ｔｙｐｅフィールドの値が”４”のとき、当該メッセージはＳＮＭＰ Ｔｒａｐメッセージであると識別される。またＧｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅフィールドの値が”６”のとき、当該ＳＮＭＰ Ｔｒａｐメッセージは送信元装置ベンダ固有の定義に基づくＴｒａｐメッセージと識別され、各ベンダによって定義されたＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドに記載されたＳｅｖｅｒｉｔｙと、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドに記載された障害コードの内容にもとづき、Ｔｒａｐメッセージを解釈する必要がある。
【００７１】
本実施形態において、ストレージＡ ４００００が自装置のハードウェア障害を通知するために送信するＳＮＭＰ Ｔｒａｐメッセージの一例を図２５（ｂ）に示す。図２５（ｂ）に示すメッセージは、ＰＤＵ Ｔｙｐｅが”４”であることからＳＮＭＰ Ｔｒａｐメッセージであると認識され、Ｇｅｎｅｒｉｃ Ｔｒａｐ Ｔｙｐｅが”６”であることから送信元ベンダ固有の定義に基づくＴｒａｐメッセージであると認識される。また、Ｓｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドには障害のＳｅｖｅｒｉｔｙを、Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドには障害発生部位を示す障害コードを格納するようベンダが定義しているものとする。従って図２５（ｂ）に示すＳＮＭＰ Ｔｒａｐメッセージは、Ｓｅｖｅｒｉｔｙが”１”で障害コード”３０ｃ１”の障害が生じている旨を表している。
【００７２】
図２２に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理の一例を示すフローチャート２４００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００７３】
ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２４１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出し（ステップ２４１５）、抽出したＩＰアドレスをキーとして実トポロジリポジトリ１３４００に格納されている装置検出リスト１３５００を検索する（ステップ２４２０）。
【００７４】
ＩＰアドレスが装置検出リスト１３５００内に存在しない場合は、未登録の装置からのＴｒａｐメッセージであるためＳＡＮマネージャはＴｒａｐメッセージの内容を解析できない。従ってＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、障害装置としてＩＰアドレスを、障害部位としてＴｒａｐメッセージそのものを出力し（ステップ２４６５）、後述するステップ２４５５の処理にジャンプする。
【００７５】
ステップ２４２０において、抽出したＩＰアドレスが装置検出リスト１３５００内に存在し、Ｔｒａｐメッセージ発行元の装置が特定できた場合、ＳＡＮマネージャはＳＡＮ管理サーバ１００００が当該装置の障害解析辞書を具備しているか確認する（ステップ２４２５）。
【００７６】
ステップ２４２５にて障害解析辞書を具備している場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドをキーとして障害解析辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する（ステップ２４３０）。
【００７７】
ステップ２４２５で障害解析辞書を具備していないと判断した場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当て、メッセージのＴｉｍｅｓｔａｍｐフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、ＳＡＮマネージャは、障害部位は装置全体みなし、障害コード欄には”装置全体”として登録し、以降のステップを継続する（ステップ２４３１）。
【００７８】
ステップ２４３０あるいはステップ２４３１が終了した後、ＳＡＮマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する（ステップ２４３５）。具体的には、まず、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【００７９】
その後、ＳＡＮマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する（ステップ２４４０）。具体的には、ステップ２４３５で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル４３５００に一致するエントリがあるか検索する。一致するエントリがあれば、ＳＡＮマネージャはそのエントリから仮想ボリュームＩＤを抽出する。さらに、抽出した仮想ボリュームＩＤをキーとして実ボリュームマッピング管理テーブル１３２００に一致するエントリがあるか検索し、実マッピングＩＤ１３２０１と仮想マッピングＩＤ１３２１２を抽出し、障害ログ１３７００の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【００８０】
ステップ２４３５とステップ２４４０で障害ログの作成中エントリの、実ボリュームマッピングと、仮想ボリュームマッピングの関係を登録した後、ＳＡＮマネージャは、当該作成中エントリと、他の障害ログエントリの関係について調査する。まず、ＳＡＮマネージャは、作成中のエントリが、ハード故障によるものか、他の部位へのアクセスエラーによるものかを調査する（ステップ２４４５）。具体的には、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとしてその原因を検索する。
【００８１】
ステップ２４４５で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある”親イベント”であると判断し、イベント関係欄に”親イベント”と登録する（ステップ２４５０）。ステップ２４４５で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある”子イベント”であると判断し、イベント関係欄に”子イベント”と登録する（ステップ２４５１）。
【００８２】
最後にＳＡＮマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する（ステップ２４５５）。以上でフローチャート２４００を終了する。
【００８３】
ここで、フローチャート２４００で示されたＳＡＮマネージャ１００００の障害切り分け処理の具体例について説明する。図２３は、図１７に記載された障害ログのエントリが、フローチャート２４００で示された障害切り分け処理により、どのように出力されるかの例を示す図である。ここで、イベントＩＤ １０００、１００１、１００２、１００３は、ストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。
【００８４】
イベントＩＤ １０００の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置ＢのデータＩ／Ｆ ＩＤ ｄ１のハード故障と解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりハード故障は”親イベント”であることがわかる。
【００８５】
次に、イベントＩＤ １００１の障害メッセージを受信したとき、ＳＡＮマネージャは、ステップ２４３０でストレージ装置Ａの仮想ボリュームｖｖ１のＩ／Ｏを実ボリュームｖｂ１に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ２４３５において、実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関係することがわかる。さらに、ステップ２４４５によりアクセスエラーは”子イベント”であることがわかる。同様に、イベントＩＤ １００２の障害メッセージ及びイベントＩＤ １００３の障害メッセージも”子イベント”であることがわかる。
【００８６】
ステップ２４５５で障害メッセージを出力するにあたり、ＳＡＮマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は”親イベント”と”子イベント”のどちらかを特定する。ここで、「一定時間」とは、あらかじめＳＡＮ管理者が指定した時間で、障害の関連付けの単位となる時間である。図１７のイベントＩＤ １０００、１００１、１００２、１００３は、いずれも実ボリュームマッピングｐｍ２及び仮想ボリュームマッピングｖｍ２と関連付けられ、かつ、イベントＩＤ １０００が”親イベント”であることがわかるので、図２３の障害イベント一覧ウィンドウ２０２０では、例えばイベント関連性欄にシンボル２０２１のように関連付けを示すことができる。
【００８７】
また、例えば、ＳＡＮ管理者がイベント指定２０２２のように、ある特定の障害イベントを指定したとき、ＳＡＮマネージャ１００００は、実トポロジ表示ウィンドウ２０１０中に、実トポロジマッピング表示２０１１のように指定されたイベントに対応する実トポロジマッピングを図示してもよい。さらに、障害通知ウィンドウ２０１２のように、指定されたイベントの内容を分かりやすく表示してもよい。
【００８８】
以上、ＳＡＮマネージャは、障害切り分け処理により、ＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる
＜ＳＡＮマネージャのＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理＞
以下に、ＳＡＮマネージャによるＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例について示す。本処理では、ＳＡＮマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のＳｅｖｅｒｉｔｙ変換機能を保持し、ＳＡＮ管理者により予め定義された障害Ｓｅｖｅｒｉｔｙ変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のＳｅｖｅｒｉｔｙに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。
【００８９】
図２４に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害切り分け処理のフローチャート２５００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。
【００９０】
ＳＡＮマネージャ１３１００は、ある装置からのＳＮＭＰ Ｔｒａｐメッセージが受領されるまで待つ（ステップ２５１０）。メッセージを受領したら、ＳＡＮマネージャはメッセージのＡｇｅｎｔ Ａｄｄｒｅｓｓフィールドから、メッセージ発行元の装置のＩＰアドレスを抽出する（ステップ２５１５）。
【００９１】
抽出したＩＰアドレスを元に、ＳＡＮマネージャは、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あるかどうかを調査する（ステップ２５２０）。具体的には、はじめに、抽出したＩＰアドレスが装置検出リスト１３５００内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するＳｅｖｅｒｉｔｙ欄が、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００に存在するか調査する。
【００９２】
ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係ないと判断した場合は、ＳＡＮマネージャはＳｅｖｅｒｉｔｙ変換機能を行わず、Ｔｒａｐメッセージをそのまま上位管理ソフトに転送する（ステップ２５２６）。
【００９３】
ステップ２５２０において、メッセージ発行元の装置が共通Ｓｅｖｅｒｉｔｙ定義に関係あると判断した場合は、ＳＮＭＰ ＴｒａｐメッセージのＳｐｅｃｉｆｉｃ Ｔｒａｐ Ｔｙｐｅフィールドからメッセージ発行元装置のＳｅｖｅｒｉｔｙを抽出する（ステップ２５２５）。メッセージ発行元の装置名と、抽出したＳｅｖｅｒｉｔｙをもとに、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００を調査し、共通Ｓｅｖｅｒｉｔｙとアクションを特定する（ステップ２５３０）。最後に、ステップ２５３０で特定したアクションを実行する（ステップ２５３５）。以上でフローチャート２５００を終了する。
【００９４】
ここで、フローチャート２５００で示されたＳＡＮマネージャ１００００の障害通報処理の具体例について説明する。図１７に記載された障害ログのエントリのうち、イベントＩＤ ２０００のイベントが受信されたときを考える。イベントＩＤ ２０００の障害メッセージは、ステップ２５１５でストレージ装置Ｂが発行元装置であると判断されるので、ステップ２５２０で共通Ｓｅｖｅｒｉｔｙ定義に関係ある場合と判断される。ステップ２５２５においてＴｒａｐメッセージ中のＳｅｖｅｒｉｔｙは”４”であることから、障害Ｓｅｖｅｒｉｔｙ変換テーブル１３８００記載のアクション「ストレージＡの情報をＴｒａｐ送信及びメール送信」を適用し、イベントＩＤ ２０００の障害メッセージは、上位管理ソフト及びＳＡＮ管理者には通報されない。
【００９５】
以上、ＳＡＮマネージャは、Ｓｅｖｅｒｉｔｙ変換機能を含む通報処理により、ＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じたＳＡＮマネージャの障害通報機能を提供することができる。
【００９６】
なお、ＳＡＮマネージャが実施するストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理、障害切り分け処理、Ｓｅｖｅｒｉｔｙ変換機能を含む障害通報処理は、ストレージ装置Ａ ４００００がバーチャリゼーション装置であることを想定していたが、ストレージ装置Ａ４００００とは異なる装置をバーチャリゼーション装置として管理ネットワーク７００００及びＳＡＮ６００００に接続した構成であっても、上述の処理は同様に実現可能である。
【００９７】
以上に説明した実施形態によれば、バーチャリゼーション装置を有するＳＡＮにおいて、ＳＡＮマネージャが実行される装置がＳＡＮを構成する複数の装置からの障害メッセージを受信したとき、ＳＡＮマネージャが、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、ＳＡＮ管理者による障害の切り分け負担を軽減することができる。
【００９８】
また、ＳＡＮにおいてＳＡＮマネージャが受信する複数のストレージ装置の障害メッセージに統一的なＳｅｖｅｒｉｔｙを定義し、その定義に応じた方法でＳＡＮマネージャが障害を通報することで、ＳＡＮ管理者や上位システム管理ソフトが、必要十分な障害情報のみを受信することになり、通報後の障害対策の迅速化が可能となる。
【００９９】
【発明の効果】
本発明によれば、ＳＡＮに接続される装置から障害メッセージが発行された場合に、ＳＡＮ管理者による障害の切り分けを支援することができる。
【０１００】
また、ＳＡＮにおいて、ＳＡＮ管理者や上位システム管理ソフトは、ＳＡＮ内に存在する装置から発行された障害メッセージのうち、必要な障害情報を受信することができる。
【図面の簡単な説明】
【図１】ＳＡＮの構成例を示す図である。
【図２】ＳＡＮ管理サーバの構成例を示す図である。
【図３】サーバの構成例を示す図である。
【図４】スイッチの構成例を示す図である。
【図５】仮想化機能を有するストレージ装置の構成例を示す図である。
【図６】ストレージ装置の構成例を示す図である。
【図７】ＳＡＮ管理サーバが保持する実ボリュームマッピング管理テーブルの例を示す図である。
【図８】ＳＡＮ管理サーバが保持する仮想ボリュームマッピング管理テーブルの例を示す図である。
【図９】ＳＡＮ管理サーバが保持する装置検出リストの例を示す図である。
【図１０】サーバが保持するデータＩ／Ｆ管理テーブルの例を示す図である。
【図１１】サーバが保持するボリューム管理テーブルの例を示す図である。
【図１２】スイッチが保持するＦＣ接続管理テーブルの例を示す図である。
【図１３】ストレージ装置が保持するデータＩ／Ｆ管理テーブルの例を示す図である。
【図１４】ストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。
【図１５】ストレージ装置が保持する仮想ボリューム管理テーブルの例を示す図である。
【図１６】ＳＡＮ管理サーバが保持するストレージ装置に関する障害解析辞書テーブルの例を示す図である。
【図１７】ＳＡＮ管理サーバが保持する障害ログの例を示す図である。
【図１８】ＳＡＮ管理サーバが保持する障害Ｓｅｖｅｒｉｔｙ変換テーブルの例を示す図である。
【図１９】ＳＡＮ管理サーバが行うストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理の一例を示すフローチャートである。
【図２０】ＳＡＮ管理サーバが行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図２１】ＳＡＮ管理サーバが行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図２２】ＳＡＮ管理サーバが行う障害切り分け処理の一例を示すフローチャートである。
【図２３】ＳＡＮ管理サーバが出力する、障害切り分け結果表示の一例を示す図である。
【図２４】ＳＡＮ管理サーバが行うＳｅｖｅｒｉｔｙ変換機能を含む障害通報処理の一例を示すフローチャートである。
【図２５】ＳＮＭＰ Ｔｒａｐメッセージの構成例を示す図である。
【図２６】ＳＡＮの構成例を示す図である。
【図２７】ＳＡＮの構成例を示す図である。
【符号の説明】
１００００：ＳＡＮ管理サーバ
１３１００：ＳＡＮマネージャ
２００００：サーバ
３００００：スイッチ
４００００：ストレージ装置Ａ
５００００：ストレージ装置Ｂ
２３１００：サーバの管理エージェント
３３１００：スイッチの管理エージェント
４３１００：ストレージ装置Ａの管理エージェント
５３１００：ストレージ装置Ｂの管理エージェント
４７０００：ストレージ装置Ａの提供する実ボリューム
４８０００：ストレージ装置Ａの提供する仮想ボリューム
５７０００：ストレージ装置Ｂの提供する実ボリューム
Claims (20)
- 各々実ボリュームを有する一又は複数の記憶装置と、
ネットワークを介して前記一又は複数の記憶装置と接続され、前記一又は複数の記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置と、
前記一又は複数の記憶装置及び前記バーチャリゼーション装置と管理ネットワークを介して接続される管理サーバとを有するシステムにおける、障害情報管理方法であって、
障害を検出した一又は複数の記憶装置及び前記バーチャリゼーション装置から、前記管理サーバが複数の障害通知を受信する障害通知受信ステップと、
前記複数の障害通知を、前記バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、前記管理サーバが関連付ける関連付けステップと、
前記複数の障害通知を関連付けた結果を出力する障害メッセージ出力ステップとを有することを特徴とする障害情報管理方法。 - 請求項１記載の障害情報管理方法において、
前記関連付けステップは、障害通知によって通知される障害と関係のある実ボリューム若しくは仮想ボリュームが共通する複数の障害通知を関連付けるステップを有することを特徴とする障害情報管理方法。 - 請求項２記載の障害情報管理方法において、
前記関連付けステップは、一定期間内に前記管理サーバが受信した複数の障害通知を関連付けるステップを有することを特徴とする障害情報管理方法。 - 請求項２記載の障害情報管理方法において、
更に、前記管理サーバが、前記ネットワークに接続される装置から該ネットワークの構成情報を受信するステップと、
前記管理サーバが、前記構成情報に基づいて、前記実ボリュームと仮想ボリュームの対応関係を特定するステップとを有することを特徴とする障害情報管理方法。 - 請求項１記載の障害情報管理方法において、
前記関連付けステップは、前記実ボリュームと仮想ボリュームの対応関係に基づいて、前記複数の障害通知間の因果関係を特定するステップを有し、
前記出力ステップは、特定された因果関係を出力するステップを有することを特徴とする障害情報管理方法。 - 請求項５記載の障害情報管理方法において、
前記因果関係を特定するステップは、障害通知によって通知される障害と関連のある実ボリューム若しくは仮想ボリュームが共通する複数の障害通知を関連付けるステップと、
関連付けられた障害通知のうち、ハードウェアの故障を通知する障害通知を障害の原因を通知する障害通知と、アクセスエラーを通知する障害通知を前記障害の原因の影響を受けて発行された障害通知と特定するステップとを有することを特徴とする障害情報管理方法。 - 請求項１記載の障害情報管理方法において、
更に、前記障害を検出した一又は複数の記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害情報の重要度を表す複数の重要度情報を、共通の基準に基づく重要度情報に前記管理サーバが変換するステップと、
変換後の重要度情報に基づいて、予め定められた方法で、前記管理サーバが障害情報を出力するステップを有することを特徴とする障害情報管理方法。 - 各々サーバ装置とネットワークを介して接続される複数の記憶装置と、
前記複数の記憶装置と管理ネットワークを介して接続される管理サーバとを有するシステムにおける、障害情報管理方法であって、
障害を検出した複数の記憶装置から、前記管理サーバが複数の障害通知を受信する障害通知受信ステップと、
前記複数の障害通知に含まれる、各々異なる基準に基づく障害情報の重要度を表す複数の重要度情報を、共通の基準に基づく重要度情報に変換するステップと、
変換後の重要度情報に基づいて、前記複数の障害通知各々を処理するステップとを有することを特徴とする障害情報管理方法。 - 請求項８記載の障害情報管理方法において、
前記変換するステップは、前記ネットワークの構成情報に基づいて実行されることを特徴とする障害情報管理方法。 - 請求項９記載の障害情報管理方法において、
前記複数の記憶装置のいずれかは、他の記憶装置が有する実ボリュームを仮想ボリュームとして管理しており、
前記変換するステップは、前記いずれかの記憶装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて実行されることを特徴とする障害情報管理方法。 - 各々実ボリュームを有する一又は複数の記憶装置と、ネットワークを介して前記一又は複数の記憶装置と接続され、前記一又は複数の記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置とに、管理ネットワークを介して接続される管理サーバであって、
前記管理ネットワークに接続するためのインタフェース制御部と
プロセッサと、
前記プロセッサが実行するプログラム及び前記プロセッサが使用する情報が格納されているメモリと、
前記プロセッサによって実行される処理の処理結果を出力する出力部とを有し、
前記インタフェース制御部は、障害を検出した一又は複数の記憶装置及び前記バーチャリゼーション装置から、複数の障害通知を受信し、
前記プロセッサは、前記複数の障害通知を、前記バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて関連付け、
前記出力部は、前記プロセッサが前記複数の障害通知を関連付けた結果を出力することを特徴とする管理サーバ。 - 請求項１１記載の管理サーバにおいて、
前記プロセッサは、障害通知によって通知される障害と関係のある実ボリューム若しくは仮想ボリュームが共通する複数の障害通知を関連付けることを特徴とする管理サーバ。 - 請求項１２記載の管理サーバにおいて、
前記プロセッサは、一定期間内に前記インタフェース制御部が受信した複数の障害通知を関連付けることを特徴とする管理サーバ。 - 請求項１２記載の管理サーバにおいて、
前記インタフェース制御部は、前記ネットワークに接続される装置から該ネットワークの構成情報を受信し、
前記プロセッサは、前記構成情報に基づいて、前記実ボリュームと仮想ボリュームの対応関係を特定することを特徴とする管理サーバ。 - 請求項１１記載の管理サーバにおいて、
前記プロセッサは、前記実ボリュームと仮想ボリュームの対応関係に基づいて、前記複数の障害通知間の因果関係を特定し、
前記出力部は、特定された因果関係を出力することを特徴とする管理サーバ。 - 請求項１５記載の管理サーバにおいて、
前記プロセッサは、障害通知によって通知される障害と関連のある実ボリューム若しくは仮想ボリュームが共通する複数の障害通知を関連付け、
関連付けられた障害通知のうち、ハードウェアの故障を通知する障害通知を障害の原因を通知する障害通知と、アクセスエラーを通知する障害通知を前記障害の原因の影響を受けて発行された障害通知と特定することを特徴とする管理サーバ。 - 請求項１１記載の管理サーバにおいて、
前記プロセッサは更に、前記障害を検出した一又は複数の記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害情報の重要度を表す複数の重要度情報を、共通の基準に基づく重要度情報に変換し、
前記出力部は、変換後の重要度情報に基づいて、予め定められた方法で障害情報を出力することを特徴とする管理サーバ。 - 各々サーバ装置とネットワークを介して接続される複数の記憶装置に、管理ネットワークを介して接続される管理サーバであって、
前記管理ネットワークに接続されるインタフェース制御部と、
プロセッサと、
前記プロセッサによって実行される処理の処理結果を出力する出力部とを有し、
前記インタフェース制御部は、障害を検出した複数の記憶装置から、複数の障害通知を受信し、
前記プロセッサは、前記複数の障害通知に含まれる、各々異なる基準に基づく障害情報の重要度を表す複数の重要度情報を、共通の基準に基づく重要度情報に変換し、変換後の重要度情報に基づいて、前記複数の障害通知各々を処理することを特徴とする管理サーバ。 - 請求項１８記載の管理サーバにおいて、
前記プロセッサは、前記ネットワークの構成情報に基づいて、各々異なる基準に基づく前記複数の重要度情報を、共通の基準に基づく重要度情報に変換し、
前記出力部は、変換後の重要度情報に基づいて前記プロセッサが障害通知を処理した結果を出力することを特徴とする管理サーバ。 - 請求項１９記載の管理サーバにおいて、
前記複数の記憶装置のいずれかは、他の記憶装置が有する実ボリュームを仮想ボリュームとして管理しており、
前記プロセッサは、前記複数の記憶装置のいずれかが管理する実ボリュームと仮想ボリュームの対応関係に基づいて、各々異なる基準に基づく前記複数の重要度情報を共通の基準に基づく重要度情報に変換することを特徴とする管理サーバ。
Priority Applications (8)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189954A JP4130615B2 (ja) | 2003-07-02 | 2003-07-02 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
| US10/659,362 US7076688B2 (en) | 2003-07-02 | 2003-09-11 | Failure information management method and management server in a network equipped with a storage device |
| EP04013828A EP1494118A3 (en) | 2003-07-02 | 2004-06-11 | A failure information management method and management server in a network equipped with a storage device |
| US11/288,205 US7409583B2 (en) | 2002-10-07 | 2005-11-29 | Volume and failure management method on a network having a storage device |
| US11/437,700 US7406622B2 (en) | 2002-10-07 | 2006-05-22 | volume and failure management method on a network having a storage device |
| US12/216,472 US7669077B2 (en) | 2002-10-07 | 2008-07-07 | Volume and failure management method on a network having a storage device |
| US12/687,367 US7937614B2 (en) | 2002-10-07 | 2010-01-14 | Volume and failure management method on a network having a storage device |
| US13/072,947 US8397102B2 (en) | 2002-10-07 | 2011-03-28 | Volume and failure management method on a network having a storage device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003189954A JP4130615B2 (ja) | 2003-07-02 | 2003-07-02 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008027598A Division JP4575462B2 (ja) | 2008-02-07 | 2008-02-07 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2005025483A true JP2005025483A (ja) | 2005-01-27 |
| JP4130615B2 JP4130615B2 (ja) | 2008-08-06 |
Family
ID=33432316
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003189954A Expired - Fee Related JP4130615B2 (ja) | 2002-10-07 | 2003-07-02 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7076688B2 (ja) |
| EP (1) | EP1494118A3 (ja) |
| JP (1) | JP4130615B2 (ja) |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006228078A (ja) * | 2005-02-21 | 2006-08-31 | Hitachi Ltd | 階層関係で構成される複数のデバイス間のアクセス管理方法、管理計算機、または計算機システム |
| JP2006259976A (ja) * | 2005-03-16 | 2006-09-28 | Hitachi Ltd | ストレージ・エリア・ネットワークにおけるストレージセッション管理システム |
| JP2007026089A (ja) * | 2005-07-15 | 2007-02-01 | Hitachi Ltd | アクセスパス管理方法及びプログラム |
| JP2007172003A (ja) * | 2005-12-19 | 2007-07-05 | Hitachi Ltd | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 |
| JP2007293422A (ja) * | 2006-04-21 | 2007-11-08 | Hitachi Ltd | ネットワークブート計算機システムの高信頼化方法 |
| JP2010086516A (ja) * | 2008-09-04 | 2010-04-15 | Hitachi Ltd | 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム |
| WO2010122604A1 (ja) * | 2009-04-23 | 2010-10-28 | 株式会社日立製作所 | 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機 |
| JP2013509626A (ja) * | 2009-10-30 | 2013-03-14 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 仮想コンピューティング環境における障害管理のための方法、システム、およびコンピュータ・プログラム |
| JP2013073389A (ja) * | 2011-09-27 | 2013-04-22 | Nec Corp | 障害分析装置、障害分析方法、およびプログラム |
| US9063853B2 (en) | 2011-05-31 | 2015-06-23 | Fujitsu Limited | Storage device, storage system, and method for controlling storage device |
| US11762727B2 (en) | 2021-06-25 | 2023-09-19 | Fujitsu Limited | Information processing apparatus and method of monitoring operation |
Families Citing this family (78)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE10163282B4 (de) * | 2001-12-21 | 2005-06-09 | Visteon Global Technologies, Inc., Dearborn | Zahnstangengetriebe, insbesondere Zahnstangenlenkgetriebe sowie Verfahren zu dessen Erstellung |
| US7200779B1 (en) * | 2002-04-26 | 2007-04-03 | Advanced Micro Devices, Inc. | Fault notification based on a severity level |
| US20050081119A1 (en) * | 2003-08-08 | 2005-04-14 | Dizoglio Marc | Real time data storage monitoring and administration |
| US7234073B1 (en) * | 2003-09-30 | 2007-06-19 | Emc Corporation | System and methods for failover management of manageable entity agents |
| US7496690B2 (en) * | 2003-10-09 | 2009-02-24 | Intel Corporation | Method, system, and program for managing memory for data transmission through a network |
| JP4554949B2 (ja) * | 2004-01-23 | 2010-09-29 | 株式会社日立製作所 | 管理計算機および記憶装置の管理方法 |
| US7770059B1 (en) * | 2004-03-26 | 2010-08-03 | Emc Corporation | Failure protection in an environment including virtualization of networked storage resources |
| US20060047855A1 (en) | 2004-05-13 | 2006-03-02 | Microsoft Corporation | Efficient chunking algorithm |
| US8490064B2 (en) * | 2004-05-21 | 2013-07-16 | Oracle International Corporation | Hierarchical debug |
| US7359831B2 (en) * | 2004-05-21 | 2008-04-15 | Bea Systems, Inc. | Diagnostic context |
| US7376534B2 (en) * | 2004-05-21 | 2008-05-20 | Bea Systems, Inc. | Watches and notifications |
| US7395458B2 (en) * | 2004-05-21 | 2008-07-01 | Bea Systems, Inc. | Diagnostic instrumentation |
| US7379849B2 (en) * | 2004-05-21 | 2008-05-27 | Bea Systems, Inc. | Diagnostic image |
| US8126943B2 (en) * | 2004-08-09 | 2012-02-28 | International Business Machines Corporation | Autonomic virtual log configuration |
| US7502961B2 (en) * | 2004-09-09 | 2009-03-10 | Microsoft Corporation | Method, system, and apparatus for providing alert synthesis in a data protection system |
| US7865470B2 (en) * | 2004-09-09 | 2011-01-04 | Microsoft Corporation | Method, system, and apparatus for translating logical information representative of physical data in a data protection system |
| US7567974B2 (en) * | 2004-09-09 | 2009-07-28 | Microsoft Corporation | Method, system, and apparatus for configuring a data protection system |
| US8145601B2 (en) | 2004-09-09 | 2012-03-27 | Microsoft Corporation | Method, system, and apparatus for providing resilient data transfer in a data protection system |
| US7613787B2 (en) * | 2004-09-24 | 2009-11-03 | Microsoft Corporation | Efficient algorithm for finding candidate objects for remote differential compression |
| US7457871B2 (en) * | 2004-10-07 | 2008-11-25 | International Business Machines Corporation | System, method and program to identify failed components in storage area network |
| US7434091B1 (en) * | 2004-12-07 | 2008-10-07 | Symantec Operating Corporation | Flexibly combining mirroring, concatenation and striping in virtual storage devices |
| US20060174167A1 (en) * | 2005-01-28 | 2006-08-03 | Hitachi, Ltd. | Self-creating maintenance database |
| JP4652090B2 (ja) * | 2005-03-15 | 2011-03-16 | 富士通株式会社 | 事象通知管理プログラム、事象通知管理装置及び事象通知管理方法 |
| US20060218435A1 (en) * | 2005-03-24 | 2006-09-28 | Microsoft Corporation | Method and system for a consumer oriented backup |
| US7325103B1 (en) * | 2005-04-19 | 2008-01-29 | Network Appliance, Inc. | Serialization of administrative operations for accessing virtual volumes |
| JP2007018286A (ja) * | 2005-07-07 | 2007-01-25 | Hitachi Ltd | ストレージシステム、アダプタ装置並びに情報処理装置及びその制御方法 |
| JP4383484B2 (ja) * | 2005-07-14 | 2009-12-16 | 富士通株式会社 | メッセージ解析装置、制御方法および制御プログラム |
| US7926071B2 (en) * | 2005-10-20 | 2011-04-12 | Microsoft Corporation | Load balancing interfaces |
| US8234378B2 (en) | 2005-10-20 | 2012-07-31 | Microsoft Corporation | Load balancing in a managed execution environment |
| JP2007128437A (ja) * | 2005-11-07 | 2007-05-24 | Hitachi Ltd | ディスクアレイ装置及びその経路障害検出方法 |
| US7793138B2 (en) * | 2005-12-21 | 2010-09-07 | Cisco Technology, Inc. | Anomaly detection for storage traffic in a data center |
| US7805565B1 (en) | 2005-12-23 | 2010-09-28 | Oracle America, Inc. | Virtualization metadata promotion |
| US8185639B2 (en) * | 2006-01-03 | 2012-05-22 | Emc Corporation | Server identification in storage networks |
| US8032621B1 (en) * | 2006-01-03 | 2011-10-04 | Emc Corporation | Methods and apparatus providing root cause analysis on alerts |
| JP4920391B2 (ja) * | 2006-01-06 | 2012-04-18 | 株式会社日立製作所 | 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム |
| JP4818768B2 (ja) * | 2006-03-24 | 2011-11-16 | 富士通株式会社 | 情報処理システム、障害通知方法および障害通知プログラム |
| JP5068023B2 (ja) * | 2006-03-29 | 2012-11-07 | 株式会社日立製作所 | 計算機システム及び論理パス切替方法 |
| US7676694B2 (en) * | 2006-03-31 | 2010-03-09 | Emc Corporation | Managing system components |
| US8762418B1 (en) | 2006-05-31 | 2014-06-24 | Oracle America, Inc. | Metadata that allows refiltering and data reclassification without accessing the data |
| US7620855B2 (en) * | 2006-06-30 | 2009-11-17 | Seagate Technology Llc | Self-defining counters |
| US7613949B1 (en) * | 2006-06-30 | 2009-11-03 | Boone Lewis A | Fault isolation system and method |
| US7676702B2 (en) * | 2006-08-14 | 2010-03-09 | International Business Machines Corporation | Preemptive data protection for copy services in storage systems and applications |
| US7571349B2 (en) * | 2006-08-18 | 2009-08-04 | Microsoft Corporation | Configuration replication for system recovery and migration |
| US8751866B2 (en) * | 2006-09-28 | 2014-06-10 | International Business Machines Corporation | Autonomic fault isolation in a highly interconnected system |
| KR101490327B1 (ko) | 2006-12-06 | 2015-02-05 | 퓨전-아이오, 인크. | 뱅크 인터리브를 이용한 솔리드-스테이트 스토리지의 명령 관리 장치, 시스템 및 방법 |
| US8718030B2 (en) * | 2007-03-26 | 2014-05-06 | Qualcomm Incorporated | Methods and apparatus for performing channel tree operations |
| US7882393B2 (en) * | 2007-03-28 | 2011-02-01 | International Business Machines Corporation | In-band problem log data collection between a host system and a storage system |
| FR2915593B1 (fr) * | 2007-04-26 | 2009-07-10 | Aleksander Baczko | Un dispositif ameliorant la disponibilite des systemes techniques |
| US7779308B2 (en) * | 2007-06-21 | 2010-08-17 | International Business Machines Corporation | Error processing across multiple initiator network |
| US8204980B1 (en) * | 2007-06-28 | 2012-06-19 | Emc Corporation | Storage array network path impact analysis server for path selection in a host-based I/O multi-path system |
| JP4480756B2 (ja) | 2007-12-05 | 2010-06-16 | 富士通株式会社 | ストレージ管理装置、ストレージシステム制御装置、ストレージ管理プログラム、データ記憶システムおよびデータ記憶方法 |
| US7836226B2 (en) | 2007-12-06 | 2010-11-16 | Fusion-Io, Inc. | Apparatus, system, and method for coordinating storage requests in a multi-processor/multi-thread environment |
| US20090198549A1 (en) * | 2008-01-31 | 2009-08-06 | Kearns James A | Automated Repair System and Method for Network-Addressable Components |
| JP2009237826A (ja) * | 2008-03-26 | 2009-10-15 | Hitachi Ltd | ストレージシステム及びそのボリューム管理方法 |
| US9501305B2 (en) * | 2008-04-23 | 2016-11-22 | Inernational Business Machines Corporation | System for virtualisation monitoring |
| US8255525B2 (en) * | 2009-08-19 | 2012-08-28 | International Business Machines Corporation | System and method for circuit and path based event correlation |
| US8086896B2 (en) * | 2009-12-28 | 2011-12-27 | International Business Machines Corporation | Dynamically tracking virtual logical storage units |
| JP5696470B2 (ja) * | 2010-03-18 | 2015-04-08 | 株式会社リコー | 機器管理装置、機器管理方法、機器管理プログラム、及びそのプログラムを記録した記録媒体 |
| US8848518B2 (en) * | 2010-05-06 | 2014-09-30 | Verizon Patent And Licensing Inc. | System and method for providing notification of a change in path condition |
| US8612700B1 (en) | 2010-10-29 | 2013-12-17 | Symantec Corporation | Method and system of performing block level duplications of cataloged backup data |
| US20120185618A1 (en) * | 2011-01-13 | 2012-07-19 | Avaya Inc. | Method for providing scalable storage virtualization |
| JP5639913B2 (ja) * | 2011-02-02 | 2014-12-10 | 株式会社日立製作所 | 計算機システム、及びその制御方法 |
| WO2012164616A1 (en) | 2011-05-31 | 2012-12-06 | Hitachi, Ltd. | Computer system and its event notification method |
| US8782525B2 (en) * | 2011-07-28 | 2014-07-15 | National Insturments Corporation | Displaying physical signal routing in a diagram of a system |
| US9037927B2 (en) * | 2012-10-04 | 2015-05-19 | Hitachi, Ltd. | Event notification system, event information aggregation server, and event notification method |
| US10089167B2 (en) * | 2013-03-04 | 2018-10-02 | International Business Machines Corporation | Log file reduction according to problem-space network topology |
| CN104461842B (zh) * | 2013-09-23 | 2018-02-16 | 伊姆西公司 | 基于日志相似性来处理故障的方法和装置 |
| US9258242B1 (en) | 2013-12-19 | 2016-02-09 | Emc Corporation | Path selection using a service level objective |
| RU2013156784A (ru) | 2013-12-20 | 2015-06-27 | ИЭмСи КОРПОРЕЙШН | Способ и устройство выбора маршрута чтения и записи данных |
| US9870289B2 (en) * | 2014-12-12 | 2018-01-16 | Ca, Inc. | Notifying a backup application of a backup key change |
| US9880904B2 (en) * | 2014-12-12 | 2018-01-30 | Ca, Inc. | Supporting multiple backup applications using a single change tracker |
| US9733846B1 (en) * | 2014-12-18 | 2017-08-15 | EMC IP Holding Company LLC | Integrated backup performance enhancements by creating affinity groups |
| US9998537B1 (en) | 2015-03-31 | 2018-06-12 | EMC IP Holding Company LLC | Host-side tracking of data block changes for incremental backup |
| US10353780B1 (en) * | 2015-03-31 | 2019-07-16 | EMC IP Holding Company LLC | Incremental backup in a distributed block storage environment |
| TWI587661B (zh) * | 2015-11-26 | 2017-06-11 | 財團法人工業技術研究院 | 混合式軟體定義網路的虛擬區域網路復原方法、系統及其裝置 |
| US9813286B2 (en) | 2015-11-26 | 2017-11-07 | Industrial Technology Research Institute | Method for virtual local area network fail-over management, system therefor and apparatus therewith |
| US10331507B2 (en) | 2016-12-21 | 2019-06-25 | Mastercard International Incorporated | Systems and methods for real time computer fault evaluation |
| CN112653577A (zh) * | 2020-12-14 | 2021-04-13 | 武汉绿色网络信息服务有限责任公司 | 网元管理方法、装置及存储介质 |
Family Cites Families (50)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US204597A (en) * | 1878-06-04 | Improvement in beading attachments to cutter-heads | ||
| US208589A (en) * | 1878-10-01 | John gardner | ||
| US191904A (en) * | 1877-06-12 | Improvement in hames | ||
| US49572A (en) * | 1865-08-22 | Improved mode for cutting soles for boots and shoes | ||
| US47482A (en) * | 1865-04-25 | Improved landing-platform for steamboats and other vessels | ||
| US6253240B1 (en) * | 1997-10-31 | 2001-06-26 | International Business Machines Corporation | Method for producing a coherent view of storage network by a storage network manager using data storage device configuration obtained from data storage devices |
| US6457139B1 (en) | 1998-12-30 | 2002-09-24 | Emc Corporation | Method and apparatus for providing a host computer with information relating to the mapping of logical volumes within an intelligent storage system |
| IE20000203A1 (en) | 1999-03-25 | 2001-02-21 | Converge Net Technologies Inc | Storage domain management system |
| JP4515561B2 (ja) | 1999-08-27 | 2010-08-04 | 株式会社キーエンス | 荷電制御型インクジェットプリンタ |
| US6671776B1 (en) | 1999-10-28 | 2003-12-30 | Lsi Logic Corporation | Method and system for determining and displaying the topology of a storage array network having multiple hosts and computer readable medium for generating the topology |
| JP2001143367A (ja) | 1999-11-10 | 2001-05-25 | Nec Corp | ディスク装置監視システム |
| US6636981B1 (en) | 2000-01-06 | 2003-10-21 | International Business Machines Corporation | Method and system for end-to-end problem determination and fault isolation for storage area networks |
| US6826580B2 (en) | 2000-01-20 | 2004-11-30 | Emc Corporation | Distributed storage resource management in a storage area network |
| US20020103889A1 (en) | 2000-02-11 | 2002-08-01 | Thomas Markson | Virtual storage layer approach for dynamically associating computer storage with processing hosts |
| US7103653B2 (en) | 2000-06-05 | 2006-09-05 | Fujitsu Limited | Storage area network management system, method, and computer-readable medium |
| JP4794068B2 (ja) | 2000-06-05 | 2011-10-12 | 富士通株式会社 | ストレージエリア・ネットワーク管理システム |
| ATE480822T1 (de) * | 2001-02-13 | 2010-09-15 | Candera Inc | Failover-verarbeitung in einem speicherungssystem |
| US6792564B2 (en) * | 2001-03-01 | 2004-09-14 | International Business Machines Corporation | Standardized format for reporting error events occurring within logically partitioned multiprocessing systems |
| US7185062B2 (en) | 2001-09-28 | 2007-02-27 | Emc Corporation | Switch-based storage services |
| US7499986B2 (en) | 2001-10-04 | 2009-03-03 | International Business Machines Corporation | Storage area network methods with event notification conflict resolution |
| US7430593B2 (en) | 2001-10-05 | 2008-09-30 | International Business Machines Corporation | Storage area network for topology rendering |
| US7069395B2 (en) | 2001-10-05 | 2006-06-27 | International Business Machines Corporation | Storage area network methods and apparatus for dynamically enabled storage device masking |
| US8060587B2 (en) | 2001-10-05 | 2011-11-15 | International Business Machines Corporation | Methods and apparatus for launching device specific applications on storage area network components |
| US7287063B2 (en) | 2001-10-05 | 2007-10-23 | International Business Machines Corporation | Storage area network methods and apparatus using event notifications with data |
| US7171624B2 (en) | 2001-10-05 | 2007-01-30 | International Business Machines Corporation | User interface architecture for storage area network |
| US7457846B2 (en) | 2001-10-05 | 2008-11-25 | International Business Machines Corporation | Storage area network methods and apparatus for communication and interfacing with multiple platforms |
| US6952698B2 (en) | 2001-10-05 | 2005-10-04 | International Business Machines Corporation | Storage area network methods and apparatus for automated file system extension |
| US7137124B2 (en) | 2001-10-05 | 2006-11-14 | International Business Machines Corporation | Storage area network methods and apparatus for storage device masking |
| US20030093509A1 (en) | 2001-10-05 | 2003-05-15 | Li Raymond M. | Storage area network methods and apparatus with coordinated updating of topology representation |
| US20030154271A1 (en) | 2001-10-05 | 2003-08-14 | Baldwin Duane Mark | Storage area network methods and apparatus with centralized management |
| US6892264B2 (en) | 2001-10-05 | 2005-05-10 | International Business Machines Corporation | Storage area network methods and apparatus for associating a logical identification with a physical identification |
| US7080140B2 (en) | 2001-10-05 | 2006-07-18 | International Business Machines Corporation | Storage area network methods and apparatus for validating data from multiple sources |
| US7177935B2 (en) | 2001-10-05 | 2007-02-13 | International Business Machines Corporation | Storage area network methods and apparatus with hierarchical file system extension policy |
| US6996670B2 (en) | 2001-10-05 | 2006-02-07 | International Business Machines Corporation | Storage area network methods and apparatus with file system extension |
| US6920494B2 (en) | 2001-10-05 | 2005-07-19 | International Business Machines Corporation | Storage area network methods and apparatus with virtual SAN recognition |
| US6697924B2 (en) | 2001-10-05 | 2004-02-24 | International Business Machines Corporation | Storage area network methods and apparatus for identifying fiber channel devices in kernel mode |
| US20030149762A1 (en) | 2001-10-05 | 2003-08-07 | Knight Gregory John | Storage area network methods and apparatus with history maintenance and removal |
| US6854035B2 (en) | 2001-10-05 | 2005-02-08 | International Business Machines Corporation | Storage area network methods and apparatus for display and management of a hierarchical file system extension policy |
| US6889345B2 (en) * | 2001-10-19 | 2005-05-03 | Hewlett-Packard Development Company, Lp. | System and method for locating a failed storage device in a data storage system |
| US7349961B2 (en) | 2001-12-07 | 2008-03-25 | Hitachi, Ltd. | Detecting configuration inconsistency in storage networks |
| US6990604B2 (en) * | 2001-12-28 | 2006-01-24 | Storage Technology Corporation | Virtual storage status coalescing with a plurality of physical storage devices |
| US20030189929A1 (en) | 2002-04-04 | 2003-10-09 | Fujitsu Limited | Electronic apparatus for assisting realization of storage area network system |
| JP2003296037A (ja) | 2002-04-05 | 2003-10-17 | Hitachi Ltd | 計算機システム |
| JP2003316522A (ja) | 2002-04-26 | 2003-11-07 | Hitachi Ltd | 計算機システムおよび計算機システムの制御方法 |
| JP4100968B2 (ja) | 2002-06-06 | 2008-06-11 | 株式会社日立製作所 | データマッピング管理装置 |
| US7260628B2 (en) | 2002-09-06 | 2007-08-21 | Hitachi, Ltd. | Event notification in storage networks |
| JP4124331B2 (ja) | 2002-09-17 | 2008-07-23 | 株式会社日立製作所 | Ｄｂｍｓ向け仮想ボリューム作成・管理方法 |
| US7219300B2 (en) | 2002-09-30 | 2007-05-15 | Sanavigator, Inc. | Method and system for generating a network monitoring display with animated utilization information |
| JP4202709B2 (ja) | 2002-10-07 | 2008-12-24 | 株式会社日立製作所 | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 |
| US6957303B2 (en) | 2002-11-26 | 2005-10-18 | Hitachi, Ltd. | System and managing method for cluster-type storage |
-
2003
- 2003-07-02 JP JP2003189954A patent/JP4130615B2/ja not_active Expired - Fee Related
- 2003-09-11 US US10/659,362 patent/US7076688B2/en not_active Expired - Fee Related
-
2004
- 2004-06-11 EP EP04013828A patent/EP1494118A3/en not_active Withdrawn
Cited By (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006228078A (ja) * | 2005-02-21 | 2006-08-31 | Hitachi Ltd | 階層関係で構成される複数のデバイス間のアクセス管理方法、管理計算機、または計算機システム |
| US7949882B2 (en) | 2005-03-16 | 2011-05-24 | Hitachi, Ltd. | Storage session management system in storage area network |
| JP2006259976A (ja) * | 2005-03-16 | 2006-09-28 | Hitachi Ltd | ストレージ・エリア・ネットワークにおけるストレージセッション管理システム |
| JP4588500B2 (ja) * | 2005-03-16 | 2010-12-01 | 株式会社日立製作所 | ストレージ・エリア・ネットワークにおけるストレージセッション管理システム |
| JP2007026089A (ja) * | 2005-07-15 | 2007-02-01 | Hitachi Ltd | アクセスパス管理方法及びプログラム |
| JP4698316B2 (ja) * | 2005-07-15 | 2011-06-08 | 株式会社日立製作所 | アクセスパス管理方法及びプログラム |
| JP2007172003A (ja) * | 2005-12-19 | 2007-07-05 | Hitachi Ltd | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 |
| JP4736783B2 (ja) * | 2005-12-19 | 2011-07-27 | 株式会社日立製作所 | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 |
| JP2007293422A (ja) * | 2006-04-21 | 2007-11-08 | Hitachi Ltd | ネットワークブート計算機システムの高信頼化方法 |
| JP2010086516A (ja) * | 2008-09-04 | 2010-04-15 | Hitachi Ltd | 仮想化環境において生じる障害の解析方法、管理サーバ、及びプログラム |
| WO2010122604A1 (ja) * | 2009-04-23 | 2010-10-28 | 株式会社日立製作所 | 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機 |
| US8271492B2 (en) | 2009-04-23 | 2012-09-18 | Hitachi, Ltd. | Computer for identifying cause of occurrence of event in computer system having a plurality of node apparatuses |
| JP5468067B2 (ja) * | 2009-04-23 | 2014-04-09 | 株式会社日立製作所 | 複数のノード装置を含んだ計算機システムでのイベントの発生原因を特定する計算機 |
| JP2013509626A (ja) * | 2009-10-30 | 2013-03-14 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 仮想コンピューティング環境における障害管理のための方法、システム、およびコンピュータ・プログラム |
| US9063853B2 (en) | 2011-05-31 | 2015-06-23 | Fujitsu Limited | Storage device, storage system, and method for controlling storage device |
| JP2013073389A (ja) * | 2011-09-27 | 2013-04-22 | Nec Corp | 障害分析装置、障害分析方法、およびプログラム |
| US11762727B2 (en) | 2021-06-25 | 2023-09-19 | Fujitsu Limited | Information processing apparatus and method of monitoring operation |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4130615B2 (ja) | 2008-08-06 |
| US7076688B2 (en) | 2006-07-11 |
| EP1494118A3 (en) | 2007-05-23 |
| US20050015685A1 (en) | 2005-01-20 |
| EP1494118A2 (en) | 2005-01-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4130615B2 (ja) | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ | |
| JP4736783B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
| JP4202709B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
| US7669077B2 (en) | Volume and failure management method on a network having a storage device | |
| JP4294353B2 (ja) | ジョブ管理機能を有するストレージ系障害管理方法及び装置 | |
| US7949882B2 (en) | Storage session management system in storage area network | |
| US7619965B2 (en) | Storage network management server, storage network managing method, storage network managing program, and storage network management system | |
| EP1806657B1 (en) | Operation management program, operation management method, and operation management device | |
| US20140207929A1 (en) | Management apparatus and management method | |
| WO2010137063A1 (ja) | 管理サーバ及び管理システム | |
| JP2007257180A (ja) | ネットワークノード、スイッチ及びネットワーク障害回復方法 | |
| WO2012120634A1 (ja) | 管理計算機、ストレージシステム管理方法、及び、ストレージシステム | |
| US20110099273A1 (en) | Monitoring apparatus, monitoring method, and a computer-readable recording medium storing a monitoring program | |
| US9021078B2 (en) | Management method and management system | |
| JP4575462B2 (ja) | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ | |
| CN114172789B (zh) | 虚拟设备链路探测方法、装置、设备及存储介质 | |
| JP4256912B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
| JP2014123172A (ja) | 計算機システム、及びシステム管理方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050603 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050603 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060116 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060420 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20061114 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20070111 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20071211 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080207 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080311 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080424 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080520 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080522 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110530 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110530 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120530 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120530 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130530 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130530 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |