JP4736783B2 - ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 - Google Patents

Description

本発明では、計算機システムに用いられるストレージシステムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、バーチャリゼーション装置のボリューム仮想化機能を介して仮想ボリュームとしてホスト計算機に提供されるストレージエリアネットワーク(Storage Area Network、以下SAN)において、ボリュームの構成および障害を管理する方法及び装置に関するものである。

(1)SANについて
近年、各ホスト計算機からストレージ装置を切り離して集約化した、ストレージ入出力専用のネットワークであるSANが浸透しつつある。SANの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
(2)SAN管理について
SANによるストレージシステムの高い拡張性は、SANにおける複数ベンダの装置（ホスト計算機、スイッチ、ストレージ装置）の混在を可能とした。このようなSANを無停止で運用するために、SAN管理が必要である。SAN管理の中でも、日々の運用の基本となる、SANに接続される各装置の稼動状況監視が特に重要である。SANの稼動状況を監視するためのソフトウェアを、以降SANマネージャとよぶ。

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

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

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

これら二つの機能により、SAN管理者はSANマネージャを用いて装置の稼動状況を一元的に管理できるので、SAN管理者の少人数化など運用コストの削減を図ることができる。
(3)バーチャリゼーション装置について
SANにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献１に開示されている。本特許文献には、ストレージホスト計算機と呼ばれる装置が以下の二つの機能を有することが開示されている。

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

2)ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、ホスト計算機からの仮想ボリュームへのI/Oアクセスを逐次実ボリュームへのI/O要求に変換してホスト計算機からのI/Oに応答する機能。

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

英国特許出願公開第2351375号明細書

バーチャリゼーション装置が仮想ボリュームを提供することにより、ホスト計算機へ提供するボリューム構成の自由度は高まる。しかし、SAN管理者は、ホスト計算機と仮想ボリュームの関係と、仮想ボリュームと実ボリュームの関係という、双方の関係を常に把握してSANを運用する必要がある。そして、SANの規模が大きくなるほど、つまりバーチャリゼーション装置とストレージ装置の台数が増えて接続関係が複雑になるほど、SANの構成を把握するのは困難になる。

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

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

本発明の第一の目的は、SANにおいて、実ボリュームと仮想ボリュームの対応関係を容易に把握するための技術を提供することである。

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

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

本発明においては、SANを構成する各装置に具備される管理エージェントと、SAN管理者が使用する管理計算機に具備されるSANマネージャを用いて、SANにおけるボリューム構成が管理される。

第一の目的に対して、SANマネージャは、各ホスト計算機に具備される管理エージェントからデータI/Fおよびボリュームに関する情報を取得し、各スイッチに具備される管理エージェントからデータI/Fの接続状況に関する情報を取得し、各ストレージ装置に具備される管理エージェントからデータI/Fとボリュームに関する情報を取得し、各バーチャリゼーション装置に具備される管理エージェントから仮想ボリュームに関する情報を取得する。取得した情報をもとに、SANマネージャは、SANにおけるホスト計算機と仮想ボリュームの対応関係(以下仮想ボリュームマッピングと呼ぶ)を検出し、仮想ボリュームマッピング情報としてこの対応関係を管理する。さらにSANマネージャは、仮想ボリュームマッピングと仮想ボリュームの構成情報をもとに、ホスト計算機と実ボリュームの対応関係(以下実ボリュームマッピングと呼ぶ)を検出し、実ボリュームマッピング情報としてこの対応関係を管理する。これら構成情報を元に、SANマネージャは、以下の三つの機能を提供する。第一に、仮想ボリュームマッピング情報と実ボリュームマッピング情報を出力し、SAN管理者に両者の対応関係を提示する(仮想ボリューム構成管理機能)。第二に、SAN内の各装置から受信する障害通知メッセージの内容を解釈するためのイベント辞書を保持し、各装置が発行する障害通知を受けて、イベント辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したSANの構成情報をもとに、その障害が実ボリュームへのI/Oアクセス、及び、仮想ボリュームへのI/Oアクセスに与える影響を検出する(障害波及範囲検出機能)。第三に、ストレージ管理者がSANマネージャを利用して仮想ボリュームを作成する時、関連する仮想ボリュームマッピング情報ないしは実ボリュームマッピング情報を提供し、SAN管理者の仮想ボリューム作成作業を支援する(ボリューム割当機能)。

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

第三の目的に対して、SANに接続された装置から複数の障害通知を受信するSANマネージャは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する(障害重要度変換機能)。

本発明により、ストレージネットワークの実ボリュームと仮想ボリュームの対応関係を、SAN管理者が容易に把握できるようになる。

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

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

以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発
明が限定されるものではない。
本実施形態は、スイッチ兼バーチャリゼーション装置を有するSANにおいて、SANマネージャが、SANに接続される各装置の構成情報から、仮想ボリュームマッピングと実ボリュームマッピングを作成することによって、SAN管理者が仮想ボリュームと実ボリュームの対応関係を容易に管理するための、仮想ボリュームの構成管理機能を示す。
(1-1) SANの構成
本実施形態におけるSANの構成について説明する。図1から図5はSAN及びSANに接続される各装置の構成例を示し、図8から図15は各装置内に具備された管理情報を示している。

図1にはSANの構成例を示す。本発明におけるSANは、管理エージェントを有する1台以上のホスト計算機、管理エージェントを有する1台以上のスイッチ、管理エージェントを有する1台以上のバーチャリゼーション装置、管理エージェントを有する1台以上のストレージ装置、そしてSANマネージャを有する1台の管理計算機を有する。以降の説明の都合上、本実施形態のSANにおいては、2台のホスト計算機(H1,H2)20000と、1台のスイッチ兼バーチャリゼーション装置の役割を果たすバーチャリゼーションスイッチ(SW1)30000と、2台のストレージ装置(S1,S2)が、ファイバチャネル60000を介して相互に接続されているものとする。一方、管理計算機10000は、管理用ネットワーク70000を介してホスト計算機、バーチャリゼーションスイッチ、ストレージ装置それぞれに接続されており、各装置の管理エージェントと管理計算機10000内のSANマネージャ13100は管理用ネットワークを介して通信できる。SANマネージャ13100は、後述する処理により、SANにおける仮想ボリュームと実ボリュームの構成を管理する。

図2には管理計算機10000の構成例を示す。管理計算機10000は、プロセッサ11000、主記憶12000、ハードディスク等の不揮発な記憶領域13000、管理用ネットワーク70000に接続する管理I/F14000と、SANマネージャ13100によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部15000と、キーボードやマウス等の入力部16000とを有し、これらは内部バス等の通信路17000を介して相互に接続する。記憶領域13000には、管理計算機によって実行されるプログラムであるSANマネージャ13100と、SANにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル13200と、SANにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル13300と、SAN内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ13400と、SAN内でSANマネージャ13100が管理対象としている装置の一覧を保持する装置検出リスト13500とが格納されている。なお、図示していないが、記憶領域13000には、OS(オペレーティングシステム)が格納される。プロセッサ11000は、記憶領域13000内のOS、SANマネージャ13100、テーブルを主記憶にロードし、管理計算機の処理を実行する。

図3にはホスト計算機20000の構成図を示す。ホスト計算機20000は、プロセッサ21000と、主記憶22000と、ハードディスク等の不揮発な記憶領域23000と、管理用ネットワーク70000に接続する管理I/F24000と、ファイバチャネル60000に接続する一つ以上のデータI/F26000を有し、これらは内部バス等の通信路27000を介して相互に接続する。記憶領域23000には、SANマネージャ13100と通信して当該ホスト計算機の管理情報を送受信するためのプログラムである管理エージェント23100と、当該ホスト計算機のデータI/Fの管理情報を保持するデータI/F管理テーブル23200と、当該ホスト計算機がアクセスするボリュームの管理情報を保持するボリューム管理テーブル23300とが格納されている。なお、本実施例ではホスト計算機H1,H2ともに一つのデータI/Fを具備するものとしたが、データI/Fを複数備えていても良い。また、各ホスト計算機のデータI/Fには各ホスト計算機内で固有の識別子(データI/F ID)が割当てられており、本実施例では、ホスト計算機H1のデータI/F IDの値をa1、ホスト計算機H2のデータI/F IDの値をb1とする。なお、図示していないが、記憶領域23000には、OS(オペレーティングシステム)やアプリケーションプログラムが格納される。プロセッサ21000は、記憶領域23000内のOS、アプリケーションプログラム、管理エージェント23100、テーブルを主記憶にロードし、ホスト計算機の処理を実行する。

図4にはバーチャリゼーションスイッチ30000の構成例を示す。バーチャリゼーションスイッチ30000は、ファイバチャネル60000を介して送受信されるデータのスイッチング及び仮想ストレージ機能を実現するコントローラ31000と、ハードディスク等の不揮発な記憶領域33000と、管理用ネットワーク70000に接続する管理I/F34000と、ファイバチャネル60000に接続する一つ以上のデータI/F36000を有し、これらはコントローラ31000を介して相互に接続する。記憶領域33000には、SANマネージャ13100と通信して当該バーチャリゼーションスイッチの管理情報を送受信するためのプログラムである管理エージェント33100と、ボリューム仮想化機能を実現するためのボリューム仮想化プログラム33200と、当該バーチャリゼーションスイッチと各ホスト計算機や各ストレージ装置との間のファイバチャネル60000を介した接続関係を示す情報であるFC接続管理テーブル33300と、当該バーチャリゼーションスイッチのデータI/Fの管理情報を保持するデータI/F管理テーブル33400と、当該バーチャリゼーションスイッチが各ホスト計算機に提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル33500とが格納されている。なお、本実施例では当該バーチャリゼーションスイッチは6個のデータI/Fを有する構成としているが、データI/Fの個数は幾つであっても良い。各データI/Fは装置内固有の識別子(データI/F ID)を持ち、本実施例においてはその値をs1、s2、s3、s4、s5、s6とする。なお、図示していないが、記憶領域33000には、スイッチ制御を行う制御プログラムが格納される。当該スイッチ起動時に、記憶領域33000内の制御プログラム、ボリューム仮想化プログラム33200、管理エージェント23100、テーブルがコントローラ31000にロードされ、ボリューム仮想化機能を持つスイッチとして処理が実行される。

図5にはストレージ装置S1の詳細な構成例を示す。ストレージ装置40000は、ストレージ装置内の制御を行うコントローラ41000と、ハードディスク等の不揮発な記憶領域43000と、管理用ネットワーク70000に接続する管理I/F44000と、ファイバチャネル60000に接続する一つ以上のデータI/F46000と、ホスト計算機およびバーチャリゼーションスイッチに提供する記憶領域である一つ以上の実ボリューム47000を有し、これらはコントローラ41000を介して互に接続する。記憶領域43000には、SANマネージャ13100と通信してストレージ装置S1の管理情報を送受信するためのプログラムである管理エージェント43100と、ストレージ装置S1のデータI/Fの管理情報を保持するデータI/F管理テーブル43200と、当該ストレージ装置S1の実ボリューム47000の管理情報を保持する実ボリューム管理テーブル43300とが格納されている。尚、本実施例ではストレージ装置S1は2個のデータI/Fと4個の実ボリュームを有するが、データI/F及び実ボリュームの個数は幾つであっても良い。各データＩ/F及び各実ボリュームは装置内固有の識別子(データI/F ID及びボリュームID)を持ち、本実施例ではデータI/F IDの値をc1、c2、ボリュームIDの値をva1、va2、va3、va4とする。なお、図示していないが、記憶領域43000には、ストレージ装置の制御を行う制御プログラムが格納される。ストレージ装置起動時に、記憶領域43000内の制御プログラム、管理エージェント43100、テーブルがコントローラ41000にロードされ、ストレージ装置の処理が実行される。

ストレージ装置S2も図5に示すストレージ装置S1と同様の構成を有する。なお本実施例では、ストレージ装置S2も2個のデータI/Fと4個の実ボリュームを有する。ストレージ装置S2のデータI/F IDの値はd1、d2、ボリュームIDの値はvb1、vb2、vb3、vb4とする。

図8には管理計算機10000が保持する装置検出リスト13500の一例を示す。図8の検出対象ID欄には管理計算機内で任意に割当てられる番号が登録され、装置種別欄にはSAN内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、IPアドレス情報欄には各装置の管理用ネットワーク70000上でのアドレスが登録され、仮想化機能欄には各装置がボリューム仮想化機能を備えているか否かが登録される。本リストに基づき、SANマネージャ13100は各装置の
管理エージェントを特定して当該管理エージェントと通信する。なお、これらの情報は、SAN管理者によって管理計算機10000から予め登録してもよい。また、SAN管理者の入力無しに、ファイバチャネルや管理用ネットワーク上のネームサービス等から各装置の情報を取得して作成してもよい。

図9A及びBに各ホスト計算機20000が保持するデータI/F管理テーブルの一例を示す。図９Aはホスト計算機H1の、図９Bはホスト計算機H2のテーブルであり、それぞれIDがa1、b1のデータI/Fに関する情報を保持している。図8のデータI/F ID欄には各ホスト計算機が有するデータI/FのIDの値が登録され、WWN(World Wide Name)欄には当該データI/FのWWNが登録され、SCSI ID欄にはデータI/Fの接続先であるSCSIターゲットデバイスの識別子(SCSI ID番号)が登録される。ここでWWNとはファイバチャネル60000上でデータI/Fを一意に識別するための識別子である。

図10A及びBに各ホスト計算機が保持するボリューム管理テーブルの一例を示す。図10Aはホスト計算機H1の、図10Bはホスト計算機H2のテーブルである。ホスト計算機H1は二つのボリューム、ホスト計算機H2は一つのボリュームの提供を受けており、各ホスト計算機はボリューム管理テーブルに自身が提供を受けているボリュームの情報を保持している。ボリューム管理テーブルのLU ID欄には、各ホスト計算機内で自身が提供を受けているボリュームに対して任意に割当てた識別子が登録される。データI/F ID欄にはボリュームにアクセスするために使用するホスト計算機上のデータI/Fの識別子が登録され、SCSI ID欄には該データI/Fの接続先であるSCSIターゲットデバイスのSCSI ID番号が登録され、LUN欄にはSCSIターゲットデバイス内の当該ボリュームにアクセスするためのSCSIロジカルユニット番号が登録され、ボリューム情報欄には、SCSI INQUIRYコマンドなどにより取得可能な、ホスト計算機に対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。

図11にバーチャリゼーションスイッチ30000が保持するFC接続管理テーブル33300の一例を示す。FC接続管理テーブルは、バーチャリゼーションスイッチ30000のデータI/Fであるs1からs6の接続先に関する情報を保持する。FC接続管理テーブルのデータI/F ID欄にはバーチャリゼーションスイッチ30000のデータI/FのIDの値が登録され、スイッチ側WWN欄には当該データI/FのWWNが登録され、接続先WWN欄には当該データI/Fが接続するホスト計算機やストレージ装置上のデータI/FのWWNが登録される。

図12にバーチャリゼーションスイッチ30000が保持するデータI/F管理テーブル33400の一例を示す。図12では、バーチャリゼーションスイッチ30000がデータI/F s1、s2から仮想ボリュームを提供しており、各ホスト計算機からはs1、s2が仮想データI/F vs1とvs2として認識されている場合を示す。データI/F管理テーブルのデータI/F ID欄にはバーチャリゼーションスイッチ30000のデータI/FのIDの値が登録され、仮想データI/F ID欄には各ホスト計算機に当該データI/Fの識別子として認識させている識別子の値が登録され、SCSI ID欄には当該仮想データI/Fに割り当てられたSCSI ID番号が登録される。

図13にバーチャリゼーションスイッチ30000が保持する仮想ボリューム管理テーブル33500の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想データI/F ID欄には、バーチャリゼーションスイッチ30000が有する仮想データI/Fの識別子の値（図12の仮想データI/F ID欄に登録される識別子の値）が登録され、SCSI ID欄には当該仮想データI/Fに割り当てられたSCSI ID番号が登録され、LUN欄には当該仮想データI/Fを介してホスト計算機に提供される仮想ボリュームにアクセスするためのSCSIロジカルユニット番号が登録され、仮想ボリュームID欄には当該仮想データI/Fを介してホスト計算機に提供している仮想ボリュームに対して任意に割り当てた識別子が登録される。本実施例においては、バーチャリゼーションスイッチ30000は、仮想データI/F vs1から仮想ボリュームvv1を提供し、仮想データI/F vs2から仮想ボリュームvv2を提供している。ここで仮想ボリューム欄に仮想データI/F vs1に関するエントリが２つあるのは、後述するように仮想データI/F vs1から提供される仮想ボリュームvv1が２つの実ボリュームva2とvb1から構成されているためである。なお、仮想ボリュームのホスト計算機への割当が決まっていない場合は、当該仮想ボリュームの仮想ボリューム欄には、値が存在しないことを示す「N/A(Not Applicable)」が格納されるものとする。

次に仮想ボリューム管理テーブル33500の実ボリューム欄の内容を説明する。実データI/F ID欄には、仮想ボリュームID欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、バーチャリゼーションスイッチ30000上のデータI/Fの識別子が登録される。SCSI ID欄には当該実データI/Fの接続先であるSCSIターゲットデバイスのSCSI ID番号が登録され、LUN欄には当該実データI/Fを介してストレージ装置から提供されるボリュームにアクセスするためのSCSIロジカルユニット番号が登録さる。実ボリューム情報欄には、SCSI INQUIRYコマンドなどにより取得可能な、当該実データI/Fを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。尚、データI/F s4からアクセス可能な実ボリュームva3、va4及びデータI/F s6からアクセス可能な実ボリュームvb3は、バーチャリゼーションスイッチ30000に認識されており、将来仮想ボリュームを構成してホスト計算機に提供され得るが、現在は仮想ボリュームとしてホスト計算機へ提供されてはいない。従って実ボリュームva3、va4、vb3に関する情報は実ボリューム欄にのみ登録されており、仮想ボリューム欄には登録されていない。また、データI/F s3からアクセス可能な実ボリュームva1は、バーチャリゼーションスイッチ30000において仮想化されることなくホスト計算機に提供されるため、va1に関する情報は仮想ボリューム管理テーブル33500に登録されていない。

図14A及びBにストレージ装置が保持するデータI/F管理テーブルの一例を示す。図１４Aはストレージ装置S1が、図１４BはストレージBが有するテーブルである。データI/F管理テーブルのデータI/F ID欄には、ストレージ装置が有するデータI/Fの識別子の値が登録され、WWN欄には当該データI/FのWWNが登録される。

図15A及び図１５Bにストレージ装置が保持する実ボリューム管理テーブルの一例を示す。図１５Aはストレージ装置S1が、図１５Bはストレージ装置S2が有するテーブルである。実ボリューム管理テーブルの実ボリュームID欄にはストレージ装置が有する実ボリュームのIDの値が登録され、パス有無欄には当該実ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データI/F ID欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータI/Fの識別子の値が登録され、SCSI ID欄には当該データI/Fに割り当てられたSCSI ID番号が登録され、SCSI LUN欄には当該実ボリュームにアクセスするためのSCSIロジカルユニット番号が登録される。なお、実ボリュームがホスト計算機またはバーチャリゼーションスイッチに割当されていない場合は、当該実ボリュームのパス有無欄の「無」とし、データI/F ID欄、SCSI ID欄、SCSI LUN欄には、値が存在しないことを示す「N/A(Not Applicable)」を格納する。
(1-2)仮想ボリューム及び実ボリュームの構成管理処理
次に、管理計算機10000上のSANマネージャ13100が実施する、仮想ボリューム及び実ボリュームの構成管理処理について説明する。以下、特に明記のない限りは、各ステップはSANマネージャ13100が実施するものとする。

図16にSANマネージャ13100によって実行される実トポロジ及び仮想トポロジ表示処理の概要を表すフローチャート1700を示す。SANマネージャ13100は、装置検出リスト13500を元にSAN内の装置を検出し、各装置の管理エージェントと通信をして、各装置が保持する図9から図15に示す情報をコピーする(ステップ1710)。

次にSANマネージャ13100はコピーした情報を実トポロジリポジトリ13400に格納する(ステップ1720)。

その後、ステップ1720で格納した情報をもとに、後述する仮想ボリュームマッピング管理テーブル13300を作成する(ステップ1730)。

さらに実トポロジリポジトリ13400内の情報と仮想ボリュームマッピング管理テーブル13300をもとに、後述する実ボリュームマッピング管理テーブル13200を作成する(ステップ1740)。

最後に仮想ボリュームマッピング管理テーブル13300及び実ボリュームマッピング管理テーブル13200の内容をもとに、実トポロジと仮想トポロジを出力し(ステップ1750)、終了する。

以上が実トポロジ及び仮想トポロジ表示処理である。

図17にSANマネージャ13100によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ1730の詳細な処理を表すフローチャートを示す。また図7に図17に示す処理によって作成される仮想ボリュームマッピング管理テーブル13300の一例を示す。

SANマネージャ13100は、各ホスト計算機から受信して実トポロジリポジトリ13400に格納した全てのボリューム管理テーブル23300について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する(ステップ1810)。

まず、SANマネージャは、仮想ボリュームマッピング管理テーブルに新規エントリを作成し、新しく割り当てた仮想マッピングID13301を登録する。更にSANマネージャは現在処理中のボリューム管理テーブル23300の送信元ホスト計算機名13302、ボリューム管理テーブルに記憶されているデータI/F ID13304及びLU ID13303を登録する(ステップ1820)。

次にSANマネージャは、登録されたデータI/F13304が接続されるスイッチのデータI/Fを調査し、スイッチの名前13305とデータI/F ID13306を登録する。具体的には、SANマネージャはまず仮想ボリュームマッピング管理テーブル13300に登録されたホスト計算機のデータI/F ID13304をキーとして、当該ホスト計算機から受信して実トポロジデポジトリ13400に格納されているデータI/F管理テーブル23200を検索し、当該データI/F IDのWWNを調べる。さらにSANマネージャは当該WWNをキーとして、バーチャリゼーションスイッチ30000から受信して実トポロジデポジトリ13400に格納されているFC接続スイッチテーブル33300を検索し、当該ホスト計算機がどのスイッチのどのデータI/Fに接続しているかを検索し、結果を接続先スイッチ名13305と接続先スイッチデータI/F ID13306として登録する(ステップ1830)。

以上の処理により、仮想ボリュームマッピング管理テーブル13300の左半分（ホスト計算機欄）にホスト計算機に関する情報が登録される。

次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の左半分（ストレージ欄）に情報を登録するための処理を行う。

SANマネージャはボリューム管理テーブル23300にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーションスイッチ30000によって提供されているものか否かを調べる。具体的には、SANマネージャは装置名をキーとして装置検出リスト13500を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーションスイッチ30000から提供されているものと判断する。(ステップ1840)。

尚本実施例ではボリュームがスイッチAから提供されている場合に当該ボリュームはバーチャリゼーションスイッチ30000から提供されていると判断される。ステップ1840の結果により、以下のように処理が分岐する(ステップ1850)。

ボリュームがバーチャリゼーションスイッチ30000以外の装置から提供されている場合、SANマネージャはボリューム管理テーブル23300のボリューム情報欄に登録されている装置名とボリュームIDを、仮想ボリュームマッピング管理テーブル13300のストレージ欄にストレージ名13309及びボリュームID13311として登録する。更にSANマネージャは、登録したボリュームID13311をキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索し、当該実ボリュームにアクセスするために使用されるデータI/FのIDを調査し、結果をストレージデータI/F ID13310として登録する(ステップ1860)。

そしてSANマネージャは、登録したストレージデータI/F13310が接続されるスイッチのデータI/Fを調査し、スイッチの名前とデータI/F IDを登録する。具体的には、SANマネージャはまずストレージデータI/F ID13310をキーとして、当該ストレージ装置から受信したデータI/F管理テーブルを検索し、当該ストレージデータI/FのWWNを調べ、さらにWWNをキーとして、バーチャリゼーションスイッチ30000から受信したFC接続スイッチテーブル33300を検索し、当該ストレージデータI/FがどのスイッチのどのデータI/Fに接続しているかを調査する。そしてSANマネージャは調査結果を接続先スイッチ名13307と接続先スイッチデータI/F ID13308として登録する(ステップ1870)。

ステップ1850においてボリュームがバーチャリゼーション装置から提供されていると判断した場合、SANマネージャは以下の処理を行う。まずSANマネージャはボリューム管理テーブル23300のボリューム情報欄に登録されている装置名とボリュームIDを仮想ボリュームマッピング管理テーブル13300にストレージ名13309及びボリュームID13311として登録する。更にSANマネージャは登録したボリュームID13311をキーとして、バーチャリゼーションスイッチ30000から受信した仮想ボリューム管理テーブル33500を検索し、当該仮想ボリュームにアクセスするために使用されるバーチャリゼーションスイッチ30000の仮想データI/FのIDを調査し、結果をストレージデータI/F ID13310として登録する(ステップ1861)。

次に、バーチャリゼーションスイッチ30000の当該仮想データI/Fに対応するスイッチのデータI/Fを調査し、スイッチの名前とデータI/F IDを登録する。具体的には、SANマネージャはストレージデータI/F ID13310をキーとして、バーチャリゼーションスイッチ30000から受信したデータI/F管理テーブル33400を検索し、当該仮想データI/Fに対応するスイッチのデータI/F IDを調査して、結果を接続先スイッチ名13307と接続先スイッチデータI/F ID13308として登録する(ステップ1871)。

装置検出リスト13500に装置が未登録のためボリューム管理テーブル23300が実トポロジリポジトリ13400に格納されていない場合、及び、装置が管理I/Fを具備しない場合、ステップ1850では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル23300のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする(ステップ1862)。

以上のステップを、各ホスト計算機から受信され実トポロジリポジトリ13400に格納された全てのボリューム管理テーブルの全エントリに対して、SANマネージャが実行したとき、ステップ1730の処理は終了する。

以上が仮想ボリュームマッピング管理テーブル作成ステップ1730である。

図18に、SANマネージャ13100が行う実ボリュームマッピング管理テーブル作成ステップ1740の詳細な処理フローを示す。又図6に図18に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。

SANマネージャ13100は、ステップ1730で作成した仮想ボリュームマッピング管理テーブル13300の全てのエントリに対して、以下の処理を実行する(ステップ1910)。

まず、SANマネージャは新規エントリを作成し、新しく割り当てた実マッピングID13201を登録する(ステップ1920)。次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の各エントリのストレージ名13309をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名13309をキーとして装置検出リスト13500を検索し、当該装置の仮想化機能の有無をチェックする(ステップ1930)。

仮想化機能を有する場合、SANマネージャは以下のステップを実行する。SANマネージャは、仮想ボリュームマッピング管理テーブルエントリ中のボリュームID13311をキーとして、ストレージ名13309が示す装置から受信した仮想ボリューム管理テーブル33500を検索し、ボリュームID13311と一致する仮想ボリュームIDのエントリを抽出する(ステップ1940)。

次にSANマネージャは、検索して得られたエントリの数と同数のエントリを実ボリューム管理マッピングテーブルに用意する(ステップ1950)。

そして、SANマネージャは、用意したエントリに対して、ホスト計算機欄（13202から13206）には仮想ボリュームマッピング管理テーブル13300の現在処理中のエントリのホスト計算機欄の内容（13302から13306）をコピーする。ストレージ欄のスイッチデータI/F ID欄13208にはステップ1940で抽出した仮想ボリューム管理テーブル33500のエントリの、実ボリューム情報欄の実データI/F IDの内容をコピーする。また、ストレージ欄のストレージ名エントリ13209及びボリュームIDエントリ13211には、仮想ボリューム管理テーブル33500の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームIDをコピーする。また対応仮想マッピングID欄13212には仮想ボリュームマッピング管理テーブル13300中の仮想マッピングID13301の内容を登録する。ストレージ欄のスイッチ名欄13207には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名13307の内容をコピーする(ステップ1960)。

更に、SANマネージャは、実ボリュームマッピング管理テーブル13212のストレージ欄のボリュームID13211に登録したボリュームIDをキーとして、ストレージ装置から受信した実ボリューム管理テーブル43300を検索して、当該ボリュームが接続されるデータI/FのIDを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータI/F ID13210に登録する。

ステップ1930にて仮想化機能を有しないとの判断がされた場合、SANマネージャは、仮想ボリュームマッピング管理テーブル13300の現在処理中のエントリ(13302から13311)を実ボリュームマッピング管理テーブル13200のエントリ（13202から13211）へコピーし、仮想ボリュームマッピング管理テーブル13300の仮想マッピングID13301の内容を実ボリュームマッピング管理テーブル13200の対応仮想マッピングID13212に登録する。

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

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

以上が実ボリュームマッピング管理テーブル作成ステップ1740である。

図6および図7で示されたマッピングテーブルをもとに、SANマネージャ13100が出力部15000に出力する実トポロジ表示及び仮想トポロジ表示の例を図19に示す。実ボリュームマッピング管理テーブル13200の内容をもとに、ホスト計算機、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示2010であり、仮想ボリュームマッピング管理テーブル13300の内容をもとに、ホスト計算機、スイッチ、ストレージ（仮想ストレージを含む）の間の接続関係を表した出力例が仮想トポロジ表示2020である。

例えばSAN管理者が、管理計算機の入力部に対して、仮想トポロジ表示2020上の、仮想ボリュームvv1からホスト計算機H1までの仮想マッピング2021を指定する指示を与えた場合を考える。

仮想マッピング2021は図7に示す仮想ボリュームマッピング管理テーブル13300中で仮想マッピングID13301がvm2である行に登録されたデータに基づいて表示されている。そこで仮想マッピング2021がSAN管理者によって指定されると、SANマネージャは仮想マッピング2021に対応する仮想マッピングID vm2をキーとして、図6に示す実ボリュームマッピング管理テーブル13200を検索する。そしてSANマネージャは、実ボリュームマッピング管理テーブル13200中で対応仮想マッピングID13212がvm2である行全てに登録されているデータに基づいて、実トポロジ表示2010内に実マッピングを表示する。この結果表示される実マッピングが図19に示す実マッピング2011である。

また、例えばSAN管理者が、管理計算機の入力部に対して、実トポロジ表示2010上の、実ボリュームva2からホスト計算機H1までの実マッピングを指定する指示を与えた場合を考える。

実ボリュームva2からホスト計算機H1までの実マッピングは、図6に示す実ボリュームマッピング管理テーブル13200中で実マッピングID13201がpm2である行に登録されたデータに基づいて表示されている。そこで当該実マッピングがSAN管理者によって指定されると、SANマネージャは当該実マッピングのエントリに格納された仮想マッピングID13212の値 vm2をキーとして、図7に示す仮想ボリュームマッピング管理テーブル13300を検索する。そしてSANマネージャは、仮想ボリュームマッピング管理テーブル13300中で仮想マッピングID13212がvm2である行に登録されているデータに基づいて、仮想トポロジ表示2020内に仮想マッピング2021を表示する。また、SANマネージャは、仮想マッピングID13212の値 vm2をキーとして、図6に示す実ボリュームマッピング管理テーブル13200も検索し、仮想マッピングID13212の値が vm2である他の実マッピングの行を検索する。もし照合するものがあれば、実トポロジ表示2010内に照合された実マッピングを表示する。この結果表示される仮想マッピングが図19に示す仮想マッピング2021である。

なお、詳細は図示しないが、本実施形態における結果出力のその他の方法として、以下の三つの方法が考えられる。

第一の方法は、SAN管理者が管理計算機の入力部から指示することにより、管理計算機が保持する実ボリュームマッピングテーブル、仮想ボリュームマッピングテーブル、実ボリュームと仮想ボリュームとの対応関係といった構成情報を、テキスト形式のような、SAN管理者の可読フォーマットで出力する方法である。

第二の方法は、SAN管理者が管理計算機の入力部からコマンド入力することにより、前記構成情報を、前記入力されたコマンドの出力結果として出力する方法である。

第三の方法は、他のSAN管理ソフト等が、SANマネージャが前記構成情報を出力するために開示するアプリケーションプログラムインタフェース（Application Program Interface, 以下APIと略記する）を実行し、APIの戻り値として出力する方法である。

これらの結果、SAN管理者は実ボリュームと仮想ボリュームの対応関係を相互
のトポロジ表示を起点として容易に知ることができる。

本実施例で示した仮想ボリュームと実ボリュームの構成管理技術により、SAN管理者はSANの構成が複雑になっても、ホスト計算機と仮想ボリュームの関係および仮想ボリュームと実ボリュームの関係を容易に把握することができる。

以下、上記した実施形態の変形例について説明する。本変形例では、スイッチ兼バーチャリゼーション装置を有するSANにおいて、ストレージネットワークの実ボリュームと仮想ボリュームの対応関係を用いて、ストレージシステムの障害に対する実ボリュームと仮想ボリュームへの影響範囲を検出する、障害波及範囲検出機能について示す。

現在のSAN管理ソフトによる障害監視機能は、IETF(Internet Engineering Task Force)で作成されたRFC1157「A Simple Network Management Protocol (SNMP)」によって定められたSNMPプロトコルのTrapメッセージを利用することが多い。しかし、仮想ストレージ技術によってホスト計算機に割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。

そこで本変形例では、管理計算機が図2に示す構成に加え、SAN内の各装置から受信する障害通知メッセージの内容を解釈するためのイベント辞書を保持する。各装置が発行する障害通知を受けたSANマネージャは、イベント辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したSANの構成情報をもとに、その障害が実ボリュームへのI/Oアクセスに与える影響を検出する。さらに、SANマネージャは仮想ボリュームマッピング情報を参照し、その障害が仮想ボリュームへのI/Oアクセスに与える影響を検出する。そして、これらの検出結果をSANマネージャは仮想ボリュームマッピング情報と実ボリュームマッピング情報に関連付けて出力することによって、SAN管理者の障害特定と障害対策の負荷を軽減する。
(2-1) SANの構成
変形例におけるSAN及びSAN内の各装置の構成について、上述した実施形態と異なる点のみ説明する。

図20に変形例における管理計算機10000の構成例を示す。変形例においては、管理計算機10000が記憶領域13000内に、SAN内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上のイベント辞書13600と、イベント内容を記録するための障害ログ13700を有する。

図26A及びBに管理計算機10000上のSANマネージャがSAN内の各装置から受信するSNMP Trapメッセージのフォーマットと、SNMP Trapメッセージの一例を示す。ここでSNMP Trapメッセージとは、SAN内の各装置の管理エージェントが管理計算機10000に対して送信する障害通知メッセージのことである。図26Aは、SNMP Trapメッセージのフォーマットを図示したものである。SNMPメッセージは、メッセージヘッダと、メッセージ送信先のコミュニティ名と、メッセージ種別を示すPDU(Protocol Data Unit) Typeと、送信元装置のベンダ名を示すEnterpriseと、送信先IPアドレスを示すAgent Addressと、Trapメッセージの種別を示すGeneric Trap TypeおよびSpecific Trap Typeと、メッセージの送信時刻を示すTimestampと、メッセージ内容を格納するVariable Bindingsのフィールドから構成される。PDU Typeフィールドの値が"4"のとき、当該メッセージはSNMP Trapメッセージであると識別される。またGeneric Trap Typeフィールドの値が"6"のとき、当該SNMP Trapメッセージは送信元装置ベンダ固有の定義に基づくTrapメッセージと識別され、各ベンダによって定義されたSpecific Trap TypeフィールドとVariable Bindingsフィールド(図中下線部)の内容にもとづきTrapメッセージを解釈する必要がある。

本変形例において、ストレージ装置S1 40000が自装置のハードウェア障害を通知するために送信するSNMP Trapメッセージの一例を図26Bに示す。図26Bに示すメッセージは、PDU Typeが”4”であることからSNMP Trapメッセージであると認識され、Generic Trap Typeが”6”であることから送信元ベンダ固有の定義に基づくTrapメッセージであると認識される。更に本変形例においては、Specific Trap Typeには障害種別を、Variable Bindingsには障害発生部位を示す障害コードを格納するようベンダが定義しているものとする。従って図26Bに示すSNMP Trapメッセージは、障害コード30c1で識別される部位にハードウェア障害が生じている旨を表している。

図21に、管理計算機10000がイベント辞書13600中に有するストレージ装置S1に関するSNMP Trapメッセージの変換リストの例を示す。本リストは、ストレージ装置S1が発行するSNMP TrapメッセージのVariable Bindingsフィールド中の障害コードが、どの部位の障害を示すかを一覧にしたものであり、各障害コードに対応する障害発生部位と当該障害発生部位の識別子が登録されている。

図22には管理計算機10000が有する障害ログ13700を示す。障害ログにはSANマネージャが障害通知メッセージを受信した時に割り当てるイベントID、障害通知メッセージの送信元装置名、障害が発生している装置内の部位、当該部位を含む実マッピングのIDと、当該部位を含む仮想マッピングのIDが登録される
以上が変形例におけるSANの構成である。
(2-2) ストレージシステムの障害に対する実ボリュームと仮想ボリュームへの障害影響範囲検出処理
図23に管理計算機10000上のSANマネージャ13100が実施する、障害影響範囲検出処理のフローチャート2400を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。

SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2410)。

メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出し(ステップ2415)、抽出したIPアドレスをキーとして実トポロジリポジトリ13400に格納されている装置検出リスト13500を検索する(ステップ2420)。

IPアドレスが装置検出リスト13500内に存在しない場合は、未登録の装置からのTrapメッセージであるためSANマネージャはTrapメッセージの内容を解析できない。従ってSANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、障害装置としてIPアドレスを、障害部位としてTrapメッセージそのものを出力し(ステップ2465)、処理を終了する。

ステップ2420において、抽出したIPアドレスが装置検出リスト13500内に存在し、Trapメッセージ発行元の装置が特定できた場合、SANマネージャは管理計算機10000が当該装置のイベント辞書を具備しているか確認する(ステップ2425)。

イベント辞書を具備している場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当てると共に、装置名を登録する(ステップ2430)。

続いてSANマネージャはTrapメッセージのVariable Bindingsフィールドをキーとしてイベント辞書を検索し、障害部位を特定し、障害部位とその識別子を障害ログ13700に登録する(ステップ2430)。

ステップ2425でイベント辞書を具備していないと判断した場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当てるとともに、装置名を登録する(ステップ2431)。

また、SANマネージャは障害部位を装置全体とみなし、装置全体を障害ログ13700に障害部位として登録し、以降のステップを継続する(ステップ2436)。

障害ログ13700に障害部位を登録した後、SANマネージャは登録した障害部位が実ボリュームと関係があるかを調査する(ステップ2440)。

具体的には、SANマネージャは、障害装置名及び障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリに各々実ボリューム、仮想ボリュームとしてコピーする(ステップ2445)。

最後にSANマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する(ステップ2450)。

以上でフローチャート2400を終了する。

以上が障害影響範囲検出処理である。

図22は、ストレージAからデータI/F c2の障害を示す障害コード30c2を含むSNMP Trapメッセージが発行された場合に、このSNMP Trapメッセージを受信したSANマネージャが図23に示す処理を実行した結果作成される障害ログを示している。

ストレージAのデータI/F c2は実ボリューム管理テーブル13200内で仮想マッピングID vm2と対応付けられており、仮想マッピングID vm2は実ボリューム管理テーブル13200内で実マッピングID pm2及び実マッピングID pm3と対応付けられているから、障害ログ13700は図22に示すような内容となる。

図24には、SANマネージャが、図19に示す実トポロジ表示および仮想トポロジ表示に図22に示す障害ログの内容を反映させて出力部15000に出力する障害通知メッセージの例を示す。

実ボリュームマッピング管理テーブル13200の内容をもとにした出力例が実トポロジ表示2010であり、実トポロジ表示内には障害ログ13700に登録された実マッピングIDが示す実マッピングが、障害の影響を受ける実マッピング2111として表示される。更に、障害ログ13700に登録された障害装置名、障害部位、及び障害ログに登録された実マッピングIDと対応付けられて実ボリュームマッピング管理テーブル13200に登録されているLU ID13203が表示される(実トポロジ表示内障害通知メッセージ2012)。

更にSANマネージャは、仮想ボリュームマッピング管理テーブル13300の内容をもとに出力する仮想トポロジ表示2020に、障害ログ13700に登録された仮想マッピングIDが示す仮想マッピングを、障害の影響を受ける仮想マッピング2121として表示する。また、障害ログ13700に登録された障害装置名、障害部位、及び障害ログに登録された仮想マッピングIDと対応付けて仮想マッピング管理テーブル13300に登録されているボリュームID13311も表示される(仮想トポロジ表示内障害通知メッセージ2022)。

なお、詳細は図示しないが、本実施形態における結果出力のその他の方法として、以下の六つの方法が考えられる。

第一の方法は、SAN管理者が管理計算機の入力部から指示することにより、管理計算機が保持する障害ログを、テキスト形式のような、SAN管理者の可読フォーマットで出力する方法である。

第二の方法は、SAN管理者が管理計算機の入力部からコマンド入力することにより、前記障害ログを、前記入力されたコマンドの出力結果として出力する方法である。

第三の方法は、他のSAN管理ソフト等が、SANマネージャが前記構成情報を出力するために開示するAPIを実行し、APIの戻り値として出力する方法である。

第四の方法は、管理計算機が、例えばsyslog（シスログ)プロトコルのような、ログ出力プロトコルに則って、障害ログを出力する方法である。

第五の方法は、管理計算機が、SAN管理者が予め設定した他のSAN管理プログラムなどに対して、障害ログをSNMP Trapとして出力する方法である。

第六の方法は、管理計算機が、SAN管理者が予め設定した管理者のメール/携帯電話/ページャなどに対して、障害ログを通知する方法である。

本変形例で示した、ストレージシステムの障害に対する実ボリュームと仮想ボリュームへの影響範囲を検出する、障害管理機能を用いることで、SAN管理者は、各装置のハードウェア障害が実ボリュームおよび仮想ボリュームにどのような影響を与えるかを容易に把握することができる。

バーチャリゼーション装置による仮想ボリューム管理機能により、SAN管理者は多数の異種ストレージ装置の実ボリュームを意識することなく、ホスト計算機に対して仮想ボリュームを割り当てることができる。しかし、例えば性能や信頼性などを考慮してホスト計算機に仮想ボリュームを割り当てる場合は、SAN管理者は仮想ボリュームを構成する実ボリューム及びホスト計算機とその実ボリュームとの間の接続関係を意識して仮想ボリュームを割り当てたい場合がある。また、24時間365日無停止稼動というように高い可用性と信頼性が求められるSANでは、万一の障害に備え、正常系と待機系という、フェイルオーバー可能な構成をとる。このような環境では、正常系と待機系が資源を共有しないよう、物理構成を意識したシステム設計が必要になる。したがって、バーチャリゼーション環境下で仮想ボリュームないしは実ボリュームを作成する際にも、そのボリュームがどのような物理資源によって提供されるかをチェックする機能が必要になる。

そこで、次の変形例（変形例１）では、スイッチ兼バーチャリゼーション装置を有するSANにおいて、SANマネージャが提供するボリューム割当機能について示す。具体的には、SAN管理者がSANマネージャを利用して仮想ボリュームを作成する時、SANマネージャが関連する仮想ボリュームマッピング情報ないしは実ボリュームマッピング情報を提供し、SAN管理者の仮想ボリューム作成作業を支援する技術について説明する。変形例２では、管理計算機が仮想ボリュームマッピング情報ないしは実ボリュームマッピング情報をもとにSAN管理者の仮想ボリューム作成要求をチェックし、作成要求中のボリュームが既に割当済みのボリュームと資源を共有する場合にはその旨を出力してSAN管理者に通知するよう、管理計算機を構成する。
(3-1)変形例２のSANの構成
変形例１におけるSANの構成、SAN内の各装置の構成は実施形態に示す構成であってもよいし、上述した変形例に示す構成であってもよい。よって説明を省略する。
(3-2)変形例２のボリューム割当処理
図25に管理計算機10000上のSANマネージャ13100が実施する、ボリューム割当処理のフローチャート2600を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。SANマネージャ13100は、SAN管理者からボリューム割当のための入力値を受け付ける(ステップ2610)。 ここで入力値とは、SAN管理者が作成しようとしている仮想ボリュームの属性(割当先ホスト計算機、容量、要求する性能など)である。また、実トポロジリポジトリ13400内にコピーされた仮想ボリューム管理テーブル14130には、バーチャリゼーションスイッチ30000が認識済みであるが、未だ仮想ボリュームとして使用されていない実ボリューム(以下未使用実ボリューム)の情報も登録されている。したがって、SAN管理者が容量や性能を入力するのではなく、仮想ボリュームを作成するための一つ以上の未使用ボリュームを入力して未使用ボリュームを直接指定することも考えられる。

与えられた入力値をキーとして、SANマネージャ13100は、実ボリュームマッピング管理テーブル13200及び仮想ボリュームマッピング管理テーブル13300を検索する(ステップ2620)。具体的にはSANマネージャ13100は、SAN管理者から受け付けた割当先ホスト計算機をキーとして実ボリュームマッピング管理テーブル及び仮想ボリュームマッピング管理テーブルを検索し、当該割当先ホスト計算機に既に割り当てられている仮想ボリュームとその仮想ボリュームに対応する実ボリューム情報を抽出する。また入力値として仮想ボリュームを構成する未使用ボリュームが指定されていない場合は、SANマネージャは容量など入力値が示す条件に合致する一つ以上の未使用ボリュームの情報を、仮想ボリューム管理テーブル33500を検索して抽出する。

SANマネージャは検索結果に基づき、これから割り当てる仮想ボリュームを構成する未使用ボリュームの一覧と、割当先ホスト計算機に既に割当済みの仮想ボリューム及び該仮想ボリュームに対応する実ボリューム情報を出力する(ステップ2630)。

この際、これからホスト計算機に割り当てられる未使用ボリュームと、このホスト計算機に既に割当済みの仮想ボリューム及び該仮想ボリュームに対応する実ボリュームとの間で資源を共有する場合（例えば、同じストレージ装置が有する実ボリュームがある場合）にはその旨を出力する。これによって、SAN管理者は正常系と待機系とが資源を共有しないよう（例えば、同じストレージ装置の記憶領域を使用しないよう）ホスト計算機に仮想ボリュームを割り当てることが可能となる。即ち、SAN管理者は、これからホスト計算機に割り当てられる未使用ボリュームと、このホスト計算機に割当済みのボリュームとが資源を共有する旨のメッセージが出力された場合には、構成変更を実施しない旨を管理計算機に入力すればよい。

そしてSAN管理者は出力された情報をもとにSAN管理者が構成変更を実施するかどうか判断した結果を受け付け(ステップ2640)、変更を実施してもよければ変更を実施する(ステップ2650)。そうでなければ変更を中止する(ステップ2660)。以上でフローチャート2600を終了する。尚、これからホスト計算機に割り当てられる未使用ボリュームと、このホスト計算機に既に割当済みのボリュームとが資源を共有する場合には、SAN管理計算機が、構成変更を実施しないよう制御することとしてもよい。

本変形例で示したボリューム割当処理により、SAN管理者は、仮想ボリューム管理機能が稼動している状況下においても、容易に実ボリュームを意識した仮想ボリューム作成が可能となる。

実施例1、変形例、および変形例１は、バーチャリゼーションスイッチを有する構成を想定した。他の変形例（変形例２）では、ストレージ装置がボリューム仮想化プログラムを具備するバーチャリゼーションストレージ装置である構成を想定し、当該構成においても、構成管理機能、障害管理機能、ボリューム割当機能が実現できることを示す。
(4-1)変形例２のSANの構成
本変形例２におけるSANの構成について説明する。本変形例の構成は、上述した実施形態や他の変形例の構成と概ね同じであるが、スイッチSW2がボリューム仮想化機能を具備しないスイッチである点と、ストレージ装置S3がボリューム仮想化機能を具備するバーチャリゼーションストレージ装置である点が異なる。よって、図27から図31により、異なる点のみを示し、それ以外の説明は省略する。

図27には変形例２におけるSANの構成例を示す。本実施形態のSANにおいては、2台のホスト計算機(H1,H2)20000と、1台のスイッチ(SW2)80000と、1台のバーチャリゼーションストレージ装置(S3)90000と、1台のストレージ装置(S2)50000が、ファイバチャネル60000を介して相互に接続されているものとする。本接続形態では、バーチャリゼーションストレージ装置S3 90000は、ストレージ装置S2 50000の実ボリューム57000を、スイッチ30000を介して認識し、ボリューム仮想化機能を適用することにより、ホストに対して、バーチャリゼーションストレージ装置S3 90000の仮想化ボリュームとして提供する。なお、バーチャリゼーションストレージ装置S3 90000とストレージ装置S2 50000の接続形態については、例えば図28に示す第二の構成例のように、ファイバチャネル60000によって、バーチャリゼーションストレージ装置S3 90000とストレージ装置S2 50000が直接接続されていてもよい。また、図29に示す第三の構成例のように、直接接続とスイッチ経由接続が混在してもよい。

管理計算機10000、ホスト計算機20000、ストレージ装置S2 50000の構成は変形例と同じであるため、説明を省略する。

図30に、本変形例におけるスイッチ80000の構成例を示す。スイッチ80000と、変形例におけるバーチャリゼーション装置兼スイッチ30000の違いは、ハードディスク等の不揮発な記憶領域83000上に、SANマネージャ13100と通信して当該スイッチSW2の管理情報を送受信するためのプログラムである管理エージェント83100と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル60000を介した接続関係を示す情報であるFC接続管理テーブル83200のみが格納されていることである。言い換えれば、ボリューム仮想化プログラム33200と、仮想ボリューム管理テーブル33500とは格納されていない。

図31に、変形例２におけるバーチャリゼーション装置兼ストレージ装置であるバーチャリゼーションストレージ装置S3の詳細な構成例を示す。バーチャリゼーションストレージ装置S3 90000が、変形例のストレージ装置S1 40000と異なる点は、他のストレージ装置が保持する実ボリュームを仮想ボリューム機能により仮想化してサーバに提供する記憶領域である一つ以上の仮想ボリューム88000を有する点と、ハードディスク等の不揮発な記憶領域83000に、ボリューム仮想化機能を実現するためのボリューム仮想化プログラム83400と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル83500が格納されている点である。なお、本実施形態ではバーチャリゼーションストレージ装置S3は2個のデータI/Fと2個の実ボリュームと2個の仮想ボリュームを有するが、データI/F、実ボリューム、及び仮想ボリュームの個数は幾つであっても良い。各データＩ/F、各実ボリューム、及び各仮想ボリュームは装置内固有の識別子(データI/F ID、実ボリュームID、仮想ボリュームID)を持ち、本実施形態ではデータI/F IDの値をc1、c2、ボリュームIDの値をva1、va2、仮想ボリュームIDの値をvv1、vv2とする。

次に、本実施形態において各装置内に具備された管理情報について、変形例と異なる点のみ説明する。

図34に、管理計算機10000が保持する装置検出リスト13500の一例を示す。装置検出リスト13500のテーブル構成は図8と変わらない。本実施形態で異なる点は、スイッチSW2が仮想化機能を有しないこと、バーチャリゼーションストレージ装置S3が仮想化機能を有することである。

図35に各ホスト計算機20000が保持するデータI/F管理テーブルの一例を示すが、これは図9とテーブル構成も内容も変わらない。

図36に各ホスト計算機が保持するボリューム管理テーブルの一例を示す。ボリューム管理テーブルのテーブル構成は図10と変わらない。本実施形態で異なる点は、
ホスト計算機H1は三つのボリュームの提供を受けており、ホスト計算機H2は全くボリュームの提供を受けていないことである。

図37にスイッチが保持するFC接続管理テーブル83300の一例を示す。FC接続管理テーブルのテーブル構成も内容も図11と変わらない。

図38で、図３８Aは、バーチャリゼーションストレージ装置S3が保持するデータI/F管理テーブル93200、および、図３８Bは、ストレージ装置S2が保持するデータI/F管理テーブル53200の一例を示す。データI/F管理テーブルのテーブル構成も内容も図14と変わらない。

図39で、図39Aは、バーチャリゼーションストレージ装置S3が保持する実ボリューム管理テーブル93300、および、図３９Bは、ストレージ装置S2が保持する実ボリューム管理テーブル53300の一例を示す。実ボリューム管理テーブルのテーブル構成は図15と変わらない。内容で異なる点は、バーチャリゼーションストレージ装置S3やストレージ装置S2の具備するボリュームが異なること、および、バーチャリゼーションストレージ装置S3が具備する実ボリュームva2は、ボリューム仮想化機能により、仮想ボリュームとして提供されることを示すため、パス有無欄に「仮想」という値が格納されていることである。パス有無欄に「仮想」という値が格納されているときは、データI/F ID欄、SCSI ID欄、SCSI LUN欄には、値が存在しないことを示す「N/A(Not Applicable)」が格納される。

図40に、バーチャリゼーションストレージ装置S3が保持する、仮想ボリューム管理テーブル93500の一例を示す。仮想ボリューム管理テーブルのテーブル構成は図13と変わらない。内容で異なる点は、バーチャリゼーションストレージ装置S3によって提供される仮想ボリュームが異なることである。なお、本実施形態では、仮想ボリュームvv1が２つの実ボリュームva2とvb1から構成されている。また、仮想ボリュームvv2は一つの実ボリュームvb2から構成されているが、まだホストにボリューム割当されていないため、仮想データI/F ID欄、SCSI ID欄、LUN欄には、値が存在しないことを示す「N/A(Not Applicable)」が格納される。

以上が変形例２におけるSANの構成である。
(4-2)変形例２における構成管理機能
次に、変形例２において管理計算機10000上のSANマネージャ13100が実施する、仮想ボリューム及び実ボリュームの構成管理処理について説明する。

実施例1で述べた、実トポロジ及び仮想トポロジ表示処理のフローチャート1700には、ボリューム仮想化機能がストレージ装置にあることに影響を受けるステップは存在しない。よって、変形例３における実トポロジ及び仮想トポロジ表示処理のフローチャート1700は、実施例1と同じである。説明を省略する。

実施例1で述べた、仮想トポロジマッピング管理テーブル作成ステップ1730の詳細な処理フローには、後述のとおり、ボリューム仮想化機能がストレージ装置にあることに影響を受けるステップが存在する。よって、変形例３における仮想トポロジマッピング管理テーブル作成ステップ1730の詳細な処理フロー1730について、実施例1との違いを説明する。

図41にSANマネージャ13100によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ1730の詳細な処理を表すフローチャートを示す。

ステップ1810からステップ1850までは、実施例1で説明した図17のフローチャートと同じであるため、説明を省略する。

ステップ1850において、ボリュームがバーチャリゼーション装置以外のストレージ装置から提供されていると判断された場合のフローは、実施例1で説明した図17のフローチャートと同じであるため、説明を省略する。

また、装置検出リスト13500に装置が未登録のためボリューム管理テーブル23300が実トポロジリポジトリ13400に格納されていない場合、及び、装置が管理I/Fを具備しない場合のフローも、実施例1で説明した図17のフローチャートと同じであるため、説明を省略する。

ステップ1850において、ボリュームがバーチャリゼーション装置から提供されていると判断した場合、SANマネージャは以下の処理を行う。まずSANマネージャは、当該ボリュームが、バーチャリゼーション装置内の実ボリュームであるか、仮想ボリュームであるかを判断する(ステップ1880)。具体的には、当該ボリュームのボリュームIDが、バーチャリゼーションストレージ装置の実ボリューム管理テーブル内に存在するか、仮想ボリューム管理テーブル内に存在するかを調べればよい。

ステップ1880で当該ボリュームが実ボリュームであると判断されたときは、以降の処理で当該ボリュームを実ボリュームとして取り扱うため、ステップ1860にジャンプする。

ステップ1880で当該ボリュームが仮想ボリュームであると判断されたときは、以降の処理で当該ボリュームを仮想ボリュームとして取り扱うため、ステップ1861にジャンプする。

ステップ1861以降のフローは、実施例1で説明した図17のフローチャートと同じであるため、説明を省略する。

以上が変形例３においてSANマネージャ13100によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ1730である。なお、本フローは、実施例1での仮想ボリュームマッピング管理テーブル作成ステップ1730として動作させてもよい。

実施例1で述べた、実ボリュームマッピング管理テーブル作成ステップ1740の詳細な処理フロー1740には、ボリューム仮想化機能がストレージ装置にあることに影響を受けるステップは存在しない。よって、変形例３における実ボリュームマッピング管理テーブル作成ステップ1740の詳細な処理フロー1740は、図18に示すフローチャート1740と同じである。説明を省略する。

変形例３において、SANマネージャが実行した仮想ボリューム及び実ボリュームの構成管理処理の結果として生成される、実ボリュームマッピング管理テーブルを図32に、仮想ボリュームマッピング管理テーブルを図33に示す。ここで、仮想ボリュームマッピング管理テーブルの仮想マッピングIDがvm1のエントリは、本実施例で述べた図41に示す仮想ボリュームマッピング管理テーブル作成ステップ1880を追加したことによって、実ボリュームと判断され、作成されたものである。また、仮想ボリュームマッピング管理テーブルの仮想マッピングIDがvm2のエントリは、前記ステップ1880を追加したことによって、仮想ボリュームと判断され、作成されたものである。このように、ステップ1880を追加したことにより、バーチャリゼーション装置が実ボリュームを具備する構成であっても、SANマネージャは、仮想ボリュームマッピング管理テーブルを作成することができる。

図32および図33で示されたマッピングテーブルをもとに、SANマネージャ13100が出力部15000に出力する実トポロジ表示及び仮想トポロジ表示の例を図42に示す。仮想トポロジ表示2020、仮想マッピング2021、実トポロジ表示2010、実マッピング2011については、実施例1で述べた方法を用いて表示可能であるため、説明を省略する。

なお、詳細は図示しないが、実施例1で述べた、結果出力のその他三つの方法についても、変形例３でも出力可能である。
(4-3)変形例３における障害波及範囲検出機能
変形例で述べた、障害影響範囲検出処理のフローチャート2400には、ボリューム仮想化機能がストレージ装置にあることに影響を受けるステップは存在しない。よって、変形例３において管理計算機10000上のSANマネージャ13100が実施する、障害影響範囲検出処理のフローチャート2400は、変形例におけるフローチャート2400と同じである。説明を省略する。

例えば図43に示すような、バーチャリゼーションストレージ装置S3に関するイベント辞書をもち、バーチャリゼーションストレージ装置S3から、実ボリュームva2の障害を示す障害コード30va2を含むSNMP Trapメッセージが発行された場合を考える。

このSNMP Trapメッセージを受信したSANマネージャは、前記障害影響範囲検出処理のフローチャート2400を実行することにより、図44のイベントID 1001に示すような、障害ログを生成することができる。

また、この障害ログを用いると、SANマネージャは、変形例で述べた方法と同じ方法によって、図45に示すような、実トポロジ表示内障害通知メッセージ2012、仮想トポロジ表示内障害通知メッセージ2022を表示することができる。

なお、詳細は図示しないが、変形例で述べた、結果出力のその他六つの方法についても、変形例３でも出力可能である。
(4-4)変形例３におけるボリューム割当機能
変形例２で述べた、ボリューム割当処理のフローチャート2600には、ボリューム仮想化機能がストレージ装置にあることに影響を受けるステップは存在しない。よって、変形例３におけるボリューム割当処理のフローチャート2600は、変形例２と同じである。説明を省略する。

以上、ストレージ装置がボリューム仮想化プログラムを具備するバーチャリゼーションストレージ装置である構成においても、構成管理機能、障害管理機能、ボリューム割当機能が実現できる。

以下の変形例３では、ストレージ装置兼バーチャリゼーション装置を有するSANにおいて、SAN管理者の管理負担を軽減する、障害関連付け機能、及び、障害重要度変換機能について説明する。

障害関連付け機能とは、具体的には、複数の装置が発行する障害通知を受けたSANマネージャが、イベント辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したSANの構成情報をもとに、障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる機能である。

また、障害重要度変換機能とは、具体的には、SANマネージャが受信する複数の装置の障害メッセージに統一的なSeverityを定義し、その定義に応じた方法でSANマネージャが障害を通報する機能である。
(5-1)変形例３のSANの構成
変形例３におけるSANの構成は、図27に示したSANの構成と同じである。ただし、管理計算機10000が具備するテーブルが一部異なるため、異なる点のみ説明する。

図46に、本変形例における管理計算機10000の詳細な構成を示す。変形例３の管理計算機10000と異なる点は、イベント辞書13600のテーブル構造が異なる点、障害ログ13700のテーブル構造が異なる点、新たに障害Severity変換テーブル13800を具備する点である。それ以外は変形例３の管理計算機10000の詳細構成と同じであるため、説明を省略する。

図47にはSAN管理サーバ10000が有するイベント辞書13600の例を示す。図４７Aはバーチャリゼーションストレージ装置S3の、図４７Bはストレージ装置S2の、図４７Cはホスト計算機H1の、図４７DはスイッチSW2のイベント辞書である。これらの辞書は、各装置から障害発生時等に発行されるSNMP Trapメッセージの解析に用いられるものであり、その詳細は後述する。障害コード欄にはSNMP TrapメッセージのVariable Bindingsフィールド中の障害コードが、障害部位欄には各障害コードに対応する障害発生部位が、識別子欄には障害発生部位を特定するための識別子が、原因欄にはメッセージ発行の原因が、Severity欄にはSNMP TrapメッセージのSpecific Trap Typeフィールド中のTrapのSeverityが登録されている。

図48にはSAN管理サーバ10000が有する障害ログ13700を示す。障害ログにはSANマネージャが障害通知メッセージを受信した時に割り当てるイベントID、障害が発生した時刻、障害通知メッセージの送信元装置名、障害通知メッセージ中の障害コード、当該部位を含む実マッピングのID、当該部位を含む仮想マッピングのIDと、他の障害イベントとの関係が登録される
図49には、SAN管理サーバ10000が有する障害Severity変換テーブルの一例を示す。本変換テーブルは、後述するSANマネージャのSeverity変換機能を含む障害通報処理において、SANマネージャが受信する複数の装置の障害メッセージに対する共通のSeverityと、共通のSeverityに応じてSANマネージャが実行する動作を定義するものである。本テーブルは、SAN環境構築にあたりSAN管理者が定義するものとする。

障害Severity変換テーブルには、複数の装置の障害メッセージに対する共通のSeverityと、共通のSeverityに対応する各装置のSeverityと、共通のSeverityに応じてSANマネージャが実行する動作が登録される。

例えば図49の場合、バーチャリゼーションストレージ装置S3のSeverityが"3"のときと、ストレージ装置S2のSeverity"4"、"5"、"6"のとき、SAN環境で共通のSeverity"3"とみなされ、その結果、SANマネージャは、バーチャリゼーションストレージ装置S3の障害メッセージ情報のみをSNMP Trapとして送信し、かつ、SAN管理者にメールで送信する。

尚、Severity変換テーブルは、SANの構成情報に基づいて定義される。図49に示すSeverity変換テーブルにおいては例えば、バーチャリゼーションストレージ装置S3のSeverity３とストレージ装置S2のSeverity4〜５が共通Severity３として関連づけられており、共通Severity３の障害通知メッセージに関してはバーチャリゼーションストレージ装置S3に関する障害情報のみをSNMP Trapとして送信し、SAN管理者にメールで送信するよう定義されている。これは、ストレージ装置S2が有する実ボリュームをバーチャリゼーションストレージ装置S3が仮想化してホスト計算機に提供しており、ストレージ装置S2が送受信する入出力要求はバーチャリゼーションストレージ装置S3を介してホスト計算機が送受信することとなるからであり、従ってバーチャリゼーションストレージ装置S3のSeverityとストレージ装置S2のSeverityとを関連付け、バーチャリゼーションストレージ装置S3及びストレージ装置S2の実ボリュームを仮想化しているバーチャリゼーションストレージ装置S3に関する障害情報のみを出力するよう定義されているのである。
(5-2)本変形例における障害関連付け機能
図50に、SANマネージャ13100が実施する、障害関連付け処理の一例を示すフローチャート2400を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。

SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2410)。

メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出し(ステップ2415)、抽出したIPアドレスをキーとして実トポロジリポジトリ13400に格納されている装置検出リスト13500を検索する(ステップ2420)。

IPアドレスが装置検出リスト13500内に存在しない場合は、未登録の装置からのTrapメッセージであるためSANマネージャはTrapメッセージの内容を解析できない。従ってSANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、障害装置としてIPアドレスを、障害部位としてTrapメッセージそのものを出力し(ステップ2465)、後述するステップ2455の処理にジャンプする。

ステップ2420において、抽出したIPアドレスが装置検出リスト13500内に存在し、Trapメッセージ発行元の装置が特定できた場合、SANマネージャは当該装置のイベント辞書を具備しているか確認する(ステップ2425)。

ステップ2425にてイベント辞書を具備している場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、TrapメッセージのVariable Bindingsフィールドをキーとしてイベント辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する(ステップ2430)。

ステップ2425でイベント辞書を具備していないと判断した場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、SANマネージャは、障害部位は装置全体みなし、障害コード欄には"装置全体"として登録し、以降のステップを継続する(ステップ2431)。

ステップ2430あるいはステップ2431が終了した後、SANマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する(ステップ2435)。具体的には、まず、登録された障害装置名のイベント辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。

その後、SANマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する(ステップ2440)。具体的には、ステップ2435で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル43500に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから仮想ボリュームIDを抽出する。さらに、抽出した仮想ボリュームIDをキーとして実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索し、実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。

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

ステップ2445で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある"親イベント"であると判断し、イベント関係欄に"親イベント"と登録する(ステップ2450)。

ステップ2445で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある"子イベント"であると判断し、イベント関係欄に"子イベント"と登録する(ステップ2451)。

最後にSANマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する(ステップ2455)。以上でフローチャート2400を終了する。

以上が障害関連付け処理のフローチャートである。

ここで、フローチャート2400で示されたSANマネージャ10000の障害関連付け処理の具体例について説明する。

図51は、図48に記載された障害ログのエントリが、フローチャート2400で示された障害関連付け処理により、どのように出力されるかの例を示す図である。ここで、イベントID 1000、1001、1002、1003は、ストレージ装置S2のデータI/F ID d1がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。

イベントID 1000の障害メッセージを受信したとき、SANマネージャは、ステップ2430でストレージ装置S2のデータI/F ID d1のハード故障と解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりハード故障は"親イベント"であることがわかる。

次に、イベントID 1001の障害メッセージを受信したとき、SANマネージャは、ステップ2430でバーチャリゼーションストレージ装置S3の仮想ボリュームvv1のI/Oを実ボリュームvb1に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりアクセスエラーは"子イベント"であることがわかる。同様に、イベントID 1002の障害メッセージ及びイベントID 1003の障害メッセージも"子イベント"であることがわかる。

ステップ2455で障害メッセージを出力するにあたり、SANマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は"親イベント"と"子イベント"のどちらかを特定する。ここで、「一定時間」とは、あらかじめSAN管理者が指定した時間で、障害の関連付けの単位となる時間である。図17のイベントID 1000、1001、1002、1003は、いずれも実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関連付けられ、かつ、イベントID 1000が"親イベント"であることがわかるので、図23の障害イベント一覧ウィンドウ2030では、例えばイベント関連性欄にシンボル2031のように関連付けを示すことができる。

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

また、詳細は図示しないが、本実施形態における結果出力のその他の方法として、以下の六つの方法が考えられる。

第一の方法は、SAN管理者が管理計算機の入力部から指示することにより、管理計算機が保持する障害ログを、テキスト形式のような、SAN管理者の可読フォーマットで出力する方法である。

第二の方法は、SAN管理者が管理計算機の入力部からコマンド入力することにより、前記障害ログを、前記入力されたコマンドの出力結果として出力する方法である。

第三の方法は、他のSAN管理ソフト等が、SANマネージャが前記構成情報を出力するために開示するAPIを実行し、APIの戻り値として出力する方法である。

第四の方法は、管理計算機が、例えばsyslog（シスログ)プロトコルのような、ログ出力プロトコルに則って、障害ログを出力する方法である。

第五の方法は、管理計算機が、SAN管理者が予め設定した他のSAN管理プログラムなどに対して、障害ログをSNMP Trapとして出力する方法である。

第六の方法は、管理計算機が、SAN管理者が予め設定した管理者のメール/携帯電話/ページャなどに対して、障害ログを通知する方法である。

以上、SANマネージャは、障害関連付け処理により、SANを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、SAN管理者による障害の切り分け負担を軽減することができる。
(5-3)本変形例における障害重要度変換機能
つづいて、以下に、SANマネージャによる障害重要度変換機能について示す。本機能では、SANマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のSeverityを、SAN管理者により予め定義された障害Severity変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。

図52に、SANマネージャ13100が実施する、障害重要度変換処理のフローチャート2500を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。

SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2510)。

メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出する(ステップ2515)。

抽出したIPアドレスを元に、SANマネージャは、メッセージ発行元の装置が共通Severity定義に関係あるかどうかを調査する(ステップ2520)。具体的には、はじめに、抽出したIPアドレスが装置検出リスト13500内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するSeverity欄が、障害Severity変換テーブル13800に存在するか調査する。

ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係ないと判断した場合は、SANマネージャはSeverity変換機能を行わず、Trapメッセージをそのまま上位管理ソフトに転送する(ステップ2526)。ここで、転送方法としては、上位管理ソフトに対してSNMP Trapを発行する方法や、上位管理ソフト独自のプロトコルでメッセージを送信する方法などが考えられる。

ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係あると判断した場合は、SNMP TrapメッセージのSpecific Trap Typeフィールドからメッセージ発行元装置のSeverityを抽出する(ステップ2525)。

メッセージ発行元の装置名と、抽出したSeverityをもとに、障害Severity変換テーブル13800を調査し、共通Severityとアクションを特定する(ステップ2530)。

最後に、ステップ2530で特定したアクションを実行する(ステップ2535)。

以上でフローチャート2500を終了する。

以上が障害重要度変換処理のフローチャートである。

ここで、フローチャート2500で示されたSANマネージャ10000の障害通報の具体例について説明する。図17に記載された障害ログのエントリのうち、イベントID 2000のイベントが受信されたときを考える。

イベントID 2000の障害メッセージは、ステップ2515でストレージ装置Bが発行元装置であると判断されるので、ステップ2520で共通Severity定義に関係ある場合と判断される。

ステップ2525においてTrapメッセージ中のSeverityは"4"であることから、障害Severity変換テーブル13800記載のアクション「バーチャリゼーションストレージ装置S3の情報をTrap送信及びメール送信」を適用し、イベントID 2000の障害メッセージは、上位管理ソフト及びSAN管理者には通報されない。

以上、SANマネージャは、Severity変換機能を含む通報を行うことで、SANマネージャが受信する複数のストレージ装置の障害メッセージに統一的なSeverityを定義し、その定義に応じたSANマネージャの障害通報機能を提供することができる。

なお、SANマネージャが実施する前記障害関連付け機能、及び前記障害重要度変換機能は、ストレージ装置S3がバーチャリゼーション装置である構成を想定していた。しかし、前記障害関連付け機能、及び前記障害重要度変換機能の処理フローにおいて、ボリューム仮想化機能を具備する装置に依存した処理は存在しない。よって、変形例で記載したような、スイッチがバーチャリゼーション装置である構成においても、同じフローチャートを適用することにより、障害関連付け機能と障害重要度変換機能を実現することができる。

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

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

変形例３では、バーチャリゼーション装置(ボリューム仮想化機能の搭載先はスイッチまたはストレージ装置を問わない)を有し、管理計算機により障害メッセージを収集する構成における、障害関連付け機能、及び、障害重要度変換機能について説明した。

さらに、変形例４では、バーチャリゼーション装置がSANマネージャを具備する構成における、障害関連付け機能について説明する。
(6-1)変形例４のSANの構成
変形例４におけるSANの構成として、ストレージ装置がバーチャリゼーション装置を兼ねる構成と、スイッチがバーチャリゼーション装置を兼ねる構成の二つの構成が考えられる。

ストレージ装置がバーチャリゼーション装置を兼ねる構成は、図27に示した変形例３のSANの構成と同じである。ただし、図53に示すとおり、バーチャリゼーションストレージ装置S3 80000が、SANマネージャ13100と、実トポロジリポジトリ13400と、装置検出リスト13500と、実ボリュームマッピング管理テーブル13200と、仮想ボリュームマッピング管理テーブル13300、を具備する。さらに、バーチャリゼーションストレージ装置S3 80000が、図46及び47に示すようなイベント辞書13600をも具備していてもよい（図示せず）。

スイッチがバーチャリゼーション装置を兼ねる構成は、図1に示した変形例のSANの構成と同じである。ただし、図54に示すとおり、バーチャリゼーションスイッチSW1 30000が、SANマネージャ13100と、実トポロジリポジトリ13400と、装置検出リスト13500と、実ボリュームマッピング管理テーブル13200と、仮想ボリュームマッピング管理テーブル13300を具備する。さらに、バーチャリゼーションスイッチSW130000が、図46及び47に示すようなイベント辞書13600をも具備していてもよい（図示せず）。

また、両者ともに、バーチャリゼーション装置が複数あり、いずれかのバーチャリゼーション装置がＳＡＮマネージャー及びその他上述したテーブル等を有し、他のバーチャリゼーション装置がＳＡＮエージェントを有していてもよい。その場合、バーチャリゼーション装置間では、管理ネットワークで接続されている。また、いずれかのＳＡＮマネージャーを有するバーチャリゼーション装置が、他のバーチャリゼーション装置が仮想化する実ボリュームを有するストレージ装置と管理ネットワークを介して接続され、そのストレージ装置からＳＮＭＰTrapイベントを、ＳＡＮマネージャーを有するバーチャリゼーション装置が受領してもよい。
(6-2)変形例４における障害関連付け機能
図55に、変形例４においてSANマネージャ13100が実施する、障害関連付け処理の一例を示すフローチャート2400を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。

本実施形態において、SANマネージャ13100は、バーチャリゼーション装置内に具備される。よって、バーチャリゼーション装置が実ボリュームへのリードライトアクセスに失敗したことを、SNMP Trapではなく、実際のリードライトアクセス結果で検知することができる。

よって、図55に示すとおり、ステップ2411において、SANマネージャは、他の装置からのSNMP Trapイベントだけでなく、バーチャリゼーション装置自身の障害やバーチャリゼーション装置からファイバチャネルを経由した実ボリュームへのアクセスエラーのような、バーチャリゼーション装置自身のイベントも、イベント受領対象に加える。

ステップ2411において、SANマネージャがSNMP Trapを受領したときは、ステップ2415にジャンプし、ステップ2415以降のステップは、SAN管理サーバーの代わりにバーチャリゼーション装置が実施する以外は、本変形例で示した図50のフローと同じである。よって説明を省略する。

ステップ2411において、SANマネージャが、バーチャリゼーション装置自身のイベントを受領したときは、障害ログ13700に新規エントリを作成し、イベントIDを割当て、後述するバーチャリゼーション装置のイベント情報をもとに、障害ログ情報を登録し、ステップ2445にジャンプする(ステップ2412)。ここで、バーチャリゼーション装置自身のイベントとは、バーチャリゼーション装置内の仮想ボリューム管理プログラムが実ボリュームへのリードライトアクセスに失敗したこと、または、バーチャリゼーション装置内の管理エージェントがバーチャリゼーション装置内の障害を検出したことを指す。このとき、バーチャリゼーション装置内の仮想ボリューム管理プログラムまたは管理エージェントは、バーチャリゼーション装置のイベント情報をSANマネージャに送信する。メッセージ授受のプロトコルは問わないものとする。データ構造は、イベント辞書13600と同様に、障害コード欄と、障害部位欄と、識別子欄と、原因欄と、Severity欄とを持ち、さらに、イベント発生時刻である時刻欄を持つ。SANマネージャは、受信したイベント情報の各欄の値を、障害ログ情報13700の各欄にコピーすることにより、障害ログ情報を新規作成すればよい。ステップ2445以降のステップは、本変形例で示した図50のフローと同じである。よって説明を省略する。

図56は、本実施例の障害関連付け処理を、バーチャリゼーションストレージ装置を有するSANに適用することにより、障害ログがどのように出力されるかの例を示す図である。具体的な表示方法は本変形例に同じであるので、説明を省略する。図56のイベントID 1001のエラーは、バーチャリゼーション装置がファイバチャネルを経由したリードライトアクセスによって検知したボリュームアクセスエラーであり、当該イベントID 1001のイベントが、他のSNMP Trapにより受領したイベントと関連づけて表示することができる。

なお、詳細は図示しないが、変形例で述べた、結果出力のその他六つの方法についても、変形例３でも出力可能である。

また、図55で示した障害関連付け処理は、ボリューム仮想化プログラムがどの装置に具備されてもステップに影響を受けない。よって、バーチャリゼーションスイッチを有するSANにおいても、当該処理を適用可能である。

以上、本実施例によれば、バーチャリゼーション装置がSANマネージャを具備することにより、管理用ネットワーク経由の障害メッセージだけでなく、ファイバチャネル経由の障害も関連付けが可能になる。すなわち、バーチャリゼーション装置がSANマネージャを具備することにより、管理用ネットワーク経由の障害メッセージだけでなく、ファイバチャネル経由の障害も監視対象とすることができる。
また、管理用ネットワーク経由の障害メッセージとファイバチャネル経由の障害の関連付けにより、SAN管理者の障害切り分け負担を軽減することができる。

上述したいずれかの実施例によると、大規模なデータセンタにおける多数のボリュームの構成管理を容易に運用することができる。

バーチャリゼーションスイッチを有するストレージネットワークシステムの構成例を示す図である。 実施例1における管理計算機の構成例を示す図である。 実施例1におけるホスト計算機の構成例を示す図である。 実施例1におけるバーチャリゼーションスイッチの構成例を示す図である。 実施例1におけるストレージ装置の構成例を示す図である。 実施例1における管理計算機が保持する実ボリュームマッピング管理テーブルの例を示す図である。 実施例1における管理計算機が保持する仮想ボリュームマッピング管理テーブルの例を示す図である。 実施例1における管理計算機が保持する装置検出リストの例を示す図である。 実施例1におけるホスト計算機が保持するデータI/F管理テーブルの例を示す図である。 実施例1におけるホスト計算機が保持するボリューム管理テーブルの例を示す図である。 実施例1におけるスイッチが保持するFC接続管理テーブルの例を示す図である。 実施例1におけるスイッチが保持するデータI/F管理テーブルの例を示す図である。 実施例1におけるバーチャリゼーション装置が保持する仮想ボリューム管理テーブルの例を示す図である。 実施例1におけるストレージ装置が保持するデータI/F管理テーブルの例を示す図である。 実施例1におけるストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。 実施例1における管理計算機が行うストレージネットワークの実トポロジ及び仮想トポロジ表示処理の一例を示すフローチャートである。 実施例1における管理計算機が行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 実施例1における管理計算機が行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 実施例1における管理計算機が行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 実施例1における管理計算機が出力する実トポロジ表示及び仮想トポロジ表示の一例を示す図である。 変形例における管理計算機の構成例を示す図である。 変形例における管理計算機が保持するストレージに関するイベント辞書の例を示す図である。 変形例における管理計算機が保持する障害ログの例を示す図である。 変形例における管理計算機が行う障害監視処理の一例を示すフローチャートである。 変形例における管理計算機が出力する、障害通知表示の一例を示す図である。 変形例１における管理計算機が行うボリュームの構成変更チェック処理の一例を示すフローチャートである。 SNMP Trapメッセージの構成例を示す図である。 バーチャリゼーションストレージ装置を有するストレージネットワークシステムの構成例を示す図である。 バーチャリゼーションストレージ装置を有するストレージネットワークシステムの第二の構成例を示す図である。 バーチャリゼーションストレージ装置を有するストレージネットワークシステムの第三の構成例を示す図である。 変形例２におけるスイッチの構成例を示す図である。 変形例２におけるバーチャリゼーションストレージ装置の構成例を示す図である。 変形例２における管理計算機が保持する実ボリュームマッピング管理テーブルの例を示す図である。 変形例２における管理計算機が保持する仮想ボリュームマッピング管理テーブルの例を示す図である。 変形例２における管理計算機が保持する装置検出リストの例を示す図である。 変形例２におけるホスト計算機が保持するデータI/F管理テーブルの例を示す図である。 変形例２におけるホスト計算機が保持するボリューム管理テーブルの例を示す図である。 変形例２におけるスイッチが保持するFC接続管理テーブルの例を示す図である。 変形例２におけるストレージ装置が保持するデータI/F管理テーブルの例を示す図である。 変形例２におけるストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。 変形例２におけるバーチャリゼーション装置が保持する仮想ボリューム管理テーブルの例を示す図である。 変形例２における管理計算機が行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 変形例２における管理計算機が行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 変形例２における管理計算機が出力する実トポロジ表示及び仮想トポロジ表示の一例を示す図である。 変形例２における管理計算機が保持するストレージに関するイベント辞書の例を示す図である。 変形例２における管理計算機が保持する障害ログの例を示す図である。 変形例２における管理計算機が出力する、障害通知表示の一例を示す図である。 変形例３における管理計算機の構成例を示す図である。 変形例３における管理計算機が保持するストレージに関するイベント辞書の例を示す図である。 変形例３における管理計算機が保持する障害ログの例を示す図である。 変形例３における管理計算機が保持する障害Severity変換テーブルの例を示す図である。 変形例３における管理計算機が行う障害関連付け処理の詳細な処理内容の一例を示すフローチャートである。 変形例３における管理計算機が行う障害関連付け処理の詳細な処理内容の一例を示すフローチャートである。 変形例３における管理計算機が出力する障害関連付け結果表示の一例を示す図である。 変形例３における管理計算機が行う障害重要度変換処理の詳細な処理内容の一例を示すフローチャートである。 変形例４におけるバーチャリゼーションストレージ装置の構成例を示す図である。 変形例４におけるバーチャリゼーションスイッチの構成例を示す図である。 変形例４におけるバーチャリゼーション装置が行う障害関連付け処理の詳細な処理内容の一例を示すフローチャートである。 変形例４におけるバーチャリゼーション装置が行う障害関連付け処理の詳細な処理内容の一例を示すフローチャートである。 変形例４におけるバーチャリゼーション装置が行う障害関連付け結果表示の一例を示す図である。

符号の説明

10000…管理計算機
13100…SANマネージャ
20000…ホスト計算機
30000…バーチャリゼーションスイッチ
40000…ストレージ装置
50000…ストレージ装置
60000…ファイバチャネル
70000…管理用ネットワーク
80000…スイッチ
90000…バーチャリゼーションストレージ装置
23100…ホスト計算機の管理エージェント
33100…バーチャリゼーションスイッチの管理エージェント
43100…ストレージ装置の管理エージェント
47000…ストレージ装置の実ボリューム
53100…ストレージ装置の管理エージェント
57000…ストレージ装置の実ボリューム
83100…スイッチの管理エージェント
93100…バーチャリゼーションストレージ装置の管理エージェント
97000…バーチャリゼーションストレージ装置の実ボリューム
98000…バーチャリゼーションストレージ装置の仮想ボリューム
33200,93400…ボリューム仮想化プログラム

Claims (9)

1. 複数のホスト計算機に接続される計算機システムであって、
   管理計算機と、
   前記ホスト計算機が利用するデータを格納可能な第一の実記憶領域と、前記第一の実記憶領域に対するアクセスを制御する第一のアクセス制御部と、を有する第一のストレージ装置と、
   前記ホスト計算機が利用するデータを格納可能な第二の実記憶領域と、前記第二の実記憶領域に対するアクセスを制御する第二のアクセス制御部と、を有する第二のストレージ装置と、を備え、
   前記第二のストレージ装置は、仮想化装置であって、
   前記第二のストレージ装置が、前記第一の実記憶領域及び前記第二の実記憶領域を用いて仮想記憶領域を構成し、前記第二のアクセス制御部が、前記仮想記憶領域をアクセス対象として前記ホスト計算機へ提供し、
   前記管理計算機は、前記仮想記憶領域、前記第一の実記憶領域、及び前記第二の実記憶領域の対応関係を作成し、前記第二のストレージ装置は、前記第二のストレージ装置自身で生じる前記仮想記憶領域に関連する障害を示すエラー情報を検出する障害検出部を備え、
   前記管理計算機は、前記対応関係に基づいて、アクセスが失敗であったことを示すアクセスエラー情報と、前記エラー情報と、を関連付け、
   前記ホスト計算機から前記第一の実記憶領域への実アクセスパスと、前記ホスト計算機から前記仮想記憶領域への仮想アクセスパスとを表示することにより、前記対応関係を出力し、
   前記仮想アクセスパスの表示において、
   前記第一のストレージ装置を、前記第一の実記憶領域を含む一つのストレージ装置として表示するのに対し、
   前記第二のストレージ装置を、前記第二の実記憶領域を含む第一の種別のストレージ装置と、前記仮想記憶領域を含む仮想ストレージ装置である第二の種別のストレージ装置とに分割して表示する
   ことを特徴とする計算機システム。
2. 請求項１記載の計算機システムであって、
   前記複数のホスト計算機のそれぞれは、障害を検出し、検出した障害に関する障害通知をネットワークを介して前記管理計算機に通知する障害情報通知部を備え、
   前記管理計算機は、前記複数のホスト計算機のそれぞれから障害通知を前記ネットワークを介して受領する障害受領部を備え、
   前記管理計算機は、さらに前記障害通知を前記アクセスエラー情報と前記エラー情報とを対応付けることを特徴とする計算機システム。
3. 請求項２記載の計算機システムであって、
   前記管理計算機は、
   前記エラー情報に基づいて仮想記憶領域に関する障害であるかどうかを特定することを特徴とする計算機システム。
4. 請求項１記載の計算機システムであって、
   前記第二のストレージ装置は、
   前記第二のストレージ装置自身に関連する障害を検出するストレージ障害検出部を有し、前記ストレージ障害検出部は、障害を検出した場合、前記管理計算機にストレージ障害通知を送信し、
   前記管理計算機は、前記ストレージ障害通知と前記アクセスエラー情報と前記エラー情報とを関連付けることを特徴とする計算機システム。
5. 請求項４記載の計算機システムであって、
   前記管理計算機は、前記ストレージ障害情報に基づいて仮想記憶領域に関する障害であるか特定することを特徴とする計算機システム。
6. 請求項１記載の計算機システムであって、前記ストレージ障害通知、前記エラー情報及びアクセスエラー情報は、SNMPトラップであることを特徴とする計算機システム。
7. 請求項１記載の計算機システムであって、
   前記第二のストレージ装置は、前記仮想記憶領域に対するデータの入出力要求を受信する入出力要求受領部を備え、
   前記障害検出部は、前記前記第二のストレージ装置自身が有する前記第二の実記憶領域に関連する障害を示すエラー情報を検出することを特徴とする計算機システム。
8. 請求項１記載の計算機システムであって、
   前記複数のホスト計算機と前記第一または第二のストレージ装置との間でデータの転送を行うスイッチ装置を備え、
   前記スイッチ装置は、
   前記複数のホスト計算機のうち少なくとも１つから、前記仮想記憶領域に対するアクセス要求を受け、前記第一の実記憶領域または前記仮想記憶領域に対するアクセス要求を送信し、前記第一または第二のストレージ装置から前記アクセス要求に対する回答を受け、前記回答を前記複数のホスト計算機のうち少なくとも１つに送信する転送制御部と、
   前記スイッチ装置が、前記アクセス要求に対し、前記第一または第二のストレージ装置からエラー通知を受けた場合、前記エラー通知を前記管理計算機に送信し、前記スイッチ装置自身の障害を検出し、前記スイッチ装置自身の障害に関するスイッチ障害情報を前記管理計算機に送信する障害検出部と、を備え、
   前記管理計算機は、前記スイッチ装置から前記スイッチ障害情報及び前記エラー通知の少なくとも一方を受領することを特徴とする計算機システム。
9. 複数のホスト計算機に接続される計算機システムで行う障害管理方法であって、
   前記計算機システムは、
   管理計算機と、
   前記ホスト計算機が利用するデータを格納可能な第一の実記憶領域と、前記第一の実記憶領域に対するアクセスを制御する第一のアクセス制御部と、を有する第一のストレージ装置と、
   前記ホスト計算機が利用するデータを格納可能な第二の実記憶領域と、前記第二の実記憶領域に対するアクセスを制御する第二のアクセス制御部と、を有する第二のストレージ装置と、を備え、
   前記第二のストレージ装置は、仮想化装置であって、
   前記第二のストレージ装置が、前記第一の実記憶領域及び前記第二の実記憶領域を用いて仮想記憶領域を構成し、前記第二のアクセス制御部が、前記仮想記憶領域をアクセス対象として前記ホスト計算機へ提供し、
   前記管理計算機は、前記仮想記憶領域、前記第一の実記憶領域、及び前記第二の実記憶領域の対応関係を作成し、
   前記第二のストレージ装置は、前記第二のストレージ装置自身で生じる前記仮想記憶領域に関連する障害を示すエラー情報を検出し、
   前記管理計算機は、前記対応関係に基づいて、アクセスが失敗であったことを示すアクセスエラー情報と、前記エラー情報と、を関連付け、
   前記ホスト計算機から前記第一の実記憶領域への実アクセスパスと、前記ホスト計算機から前記仮想記憶領域への仮想アクセスパスとを表示することにより、前記対応関係を出力し、
   前記仮想アクセスパスの表示において、
   前記第一のストレージ装置を、前記第一の実記憶領域を含む一つのストレージ装置として表示するのに対し、
   前記第二のストレージ装置を、前記第二の実記憶領域を含む第一の種別のストレージ装置と、前記仮想記憶領域を含む仮想ストレージ装置である第二の種別のストレージ装置とに分割して表示する
   ことを特徴とする障害管理方法。

Images