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

Description

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

（１）ＳＡＮについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるＳＡＮが浸透しつつある。ＳＡＮの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
（２）ＳＡＮマネージャについて
ＳＡＮで集約された異機種のストレージ装置を無停止で運用するためには、それぞれの機種の運用方法に精通した管理者が必要であり、管理コストが高い。ストレージ装置の運用管理においては、特に日々の運用の基本となる、ＳＡＮに接続される各装置（サーバ・スイッチ・ストレージ装置など）の稼動状況の監視が重要である。稼動状況を監視するためのソフトウェアを、以降ＳＡＮマネージャとよぶ。ＳＡＮマネージャは、構成管理機能と障害監視機能の二大機能を持つ。構成管理機能とは、ＳＡＮを構成する各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からＳＡＮの物理的な接続関係（トポロジ）を検出し、常に最新のトポロジを視覚化してＳＡＮマネージャユーザ、言い換えるとＳＡＮ管理者に提供する機能である。障害監視機能とは、各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをユーザに通知する機能である。これら二つの機能により、ユーザはＳＡＮマネージャを用いて装置の稼動状況を一元的に管理でき、ＳＡＮ管理者の少人数化など運用コストの削減を図ることができる。
（３）バーチャリゼーション装置について
ＳＡＮにおけるストレージ管理技術として、仮想ストレージ技術がある。仮想ストレージ技術は特許文献１に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。１）ストレージサーバに接続された各ストレージシステムが有する記憶媒体内の記憶領域であるボリューム（以下実ボリューム）を管理し、ストレージプールを生成する機能。２）ストレージプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのＩ／Ｏアクセスを逐次実ボリュームに展開してサーバからのＩ／Ｏに応答する機能。これら二つの機能を有するサーバないしはスイッチを、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をＳＡＮに導入することにより、サーバユーザはバーチャリゼーション装置に対して仮想ボリュームの割当を要求すればよく、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。その結果、ＳＡＮ管理者は一元的にボリュームの割当を行うことができる。

英国特許出願公開第２３５１３７５号明細書

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

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

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

ＳＡＮマネージャは、各サーバに具備される管理エージェントからデータＩ／Ｆおよびボリュームに関する情報を取得し、各スイッチに具備される管理エージェントからデータＩ／Ｆの接続状況に関する情報を取得し、各ストレージ装置に具備される管理エージェントからデータＩ／Ｆとボリュームに関する情報を取得し、各バーチャリゼーション装置に具備される管理エージェントから仮想ボリュームに関する情報を取得する。取得した情報をもとに、ＳＡＮマネージャは、ＳＡＮにおけるサーバと仮想ボリュームの対応関係（以下仮想ボリュームマッピングと呼ぶ）を検出し、仮想ボリュームマッピング情報としてこの対応関係を管理する。さらにＳＡＮマネージャは、仮想ボリュームマッピングと仮想ボリュームの構成情報をもとに、サーバと実ボリュームの対応関係（以下実ボリュームマッピングと呼ぶ）を検出し、実ボリュームマッピング情報としてこの対応関係を管理する。そしてＳＡＮマネージャは、仮想ボリュームマッピング情報と実ボリュームマッピング情報を出力し、ＳＡＮ管理者に両者の対応関係を提示する。

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

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

＜実施例１ 仮想ボリュームと実ボリュームの構成管理＞
本実形態においては、ＳＡＮマネージャが、仮想ボリュームマッピングと実ボリュームマッピングを把握することによって、仮想ボリュームと実ボリュームの構成を管理する技術を示す。

（１−１）ＳＡＮの構成例
まずＳＡＮの構成例について説明する。図１から図５はＳＡＮ及びＳＡＮに接続される各装置の構成例を示し、図８から図１５は各装置内に具備された管理情報を示している。

図１にはＳＡＮの構成例を示す。本発明におけるＳＡＮは、管理エージェントを有する１台以上のサーバ、管理エージェントを有する１台以上のスイッチ、管理エージェントを有する１台以上のバーチャリゼーション装置、管理エージェントを有する１台以上のストレージ装置、そしてＳＡＮマネージャを有する１台のＳＡＮ管理サーバを有する。以降の説明の都合上、実施例１のＳＡＮにおいては、２台のサーバ（サーバＡ，サーバＢ）２００００と、１台のスイッチ兼バーチャリゼーション装置３００００と、２台のストレージ装置（ストレージＡ４００００とストレージＢ５００００）が、ファイバチャネル６００００を介して相互に接続されているものとする。一方、ＳＡＮ管理サーバ１００００は、管理用ネットワーク７００００を介してサーバ、バーチャリゼーション装置、ストレージ装置それぞれに接続されており、各装置の管理エージェントとＳＡＮ管理サーバ１００００内のＳＡＮマネージャ１３１００は管理用ネットワークを介して通信できる。ＳＡＮマネージャ１３１００は、後述する処理により、ＳＡＮにおける仮想ボリュームと実ボリュームの構成を管理する。

図２にはＳＡＮ管理サーバ１００００の構成例を示す。ＳＡＮ管理サーバ１００００は、プロセッサ１１０００、主記憶１２０００、記憶領域１３０００、管理用ネットワーク７００００に接続する管理Ｉ／Ｆ１４０００と、ＳＡＮマネージャ１３１００によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力装置１５０００を有し、これらは内部バス等の通信路１７０００を介して相互に接続する。記憶領域１３０００には、ＳＡＮ管理サーバによって実行されるプログラムであるＳＡＮマネージャ１３１００と、ＳＡＮにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル１３２００と、ＳＡＮにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル１３３００と、ＳＡＮ内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ１３４００と、ＳＡＮ内でＳＡＮマネージャ１３１００が管理対象としている装置の一覧を保持する装置検出リスト１３５００とが格納されている。

図３にはサーバ２００００の構成図を示す。サーバ２００００は、プロセッサ２１０００と、主記憶２２０００と、記憶領域２３０００と、管理用ネットワーク７００００に接続する管理Ｉ／Ｆ２４０００と、ファイバチャネル６００００に接続する一つ以上のデータＩ／Ｆ２６０００を有し、これらは内部バス等の通信路２７０００を介して相互に接続する。記憶領域２３０００には、ＳＡＮマネージャ１３１００と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント２３１００と、当該サーバのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル２３２００と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル２３３００とが格納されている。なお、本実施例ではサーバＡ・サーバＢともに一つのデータＩ／Ｆを具備するものとしたが、データＩ／Ｆを複数備えていても良い。また、各サーバのデータＩ／Ｆには各サーバ内で固有の識別子（データＩ／Ｆ ＩＤ）が割当てられており、本実施例では、サーバＡのデータＩ／Ｆ ＩＤの値をａ１、サーバＢのデータＩ／Ｆ ＩＤの値をｂ１とする。

図４にはバーチャリゼーション装置の構成例を示す。バーチャリゼーション装置３００００は、ファイバチャネル６００００を介して送受信されるデータのスイッチング及び仮想ストレージ機能を実現するコントローラ３１０００と、記憶領域３３０００と、管理用ネットワーク７００００に接続する管理Ｉ／Ｆ３４０００と、ファイバチャネル６００００に接続する一つ以上のデータＩ／Ｆ３６０００を有し、これらはコントローラ３１０００を介して相互に接続する。記憶領域３３０００には、ＳＡＮマネージャ１３１００と通信して当該バーチャリゼーション装置の管理情報を送受信するためのプログラムである管理エージェント３３１００と、仮想ストレージ機能を実現するためのボリューム仮想化プログラム３３２００と、当該バーチャリゼーション装置と各サーバや各ストレージ装置との間のファイバチャネル６００００を介した接続関係を示す情報であるＦＣ接続管理テーブル３３３００と、当該バーチャリゼーション装置のデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル３３４００と、当該バーチャリゼーション装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル３３５００とが格納されている。なお、本実施例ではバーチャリゼーション装置は６個のデータＩ／Ｆを有する構成としているが、データＩ／Ｆの個数は幾つであっても良い。各データＩ／Ｆは装置内固有の識別子（データＩ／Ｆ ＩＤ）を持ち、本実施例においてはその値をｓ１、ｓ２、ｓ３、ｓ４、ｓ５、ｓ６とする。

図５にはストレージ装置Ａの詳細な構成例を示す。ストレージ装置４００００は、ストレージ装置内の制御を行うコントローラ４１０００と、記憶領域４３０００と、管理用ネットワーク７００００に接続する管理Ｉ／Ｆ４４０００と、ファイバチャネル６００００に接続する一つ以上のデータＩ／Ｆ４６０００と、サーバおよびバーチャリゼーション装置に提供する記憶領域である一つ以上の実ボリューム４７０００を有し、これらはコントローラ４１０００を介して互に接続する。記憶領域４３０００には、ＳＡＮマネージャ１３１００と通信してストレージ装置Ａの管理情報を送受信するためのプログラムである管理エージェント４３１００と、ストレージ装置ＡのデータＩ／Ｆの管理情報を保持するデータＩ／Ｆ管理テーブル４３２００と、当該ストレージ装置Ａの実ボリューム４７０００の管理情報を保持する実ボリューム管理テーブル４３３００とが格納されている。尚、本実施例ではストレージ装置Ａは２個のデータＩ／Ｆと４個の実ボリュームを有するが、データＩ／Ｆ及び実ボリュームの個数は幾つであっても良い。各データＩ／Ｆ及び各実ボリュームは装置内固有の識別子（データＩ／Ｆ ＩＤ及びボリュームＩＤ）を持ち、本実施例ではデータＩ／Ｆ ＩＤの値をｃ１、ｃ２、ボリュームＩＤの値をｖａ１、ｖａ２、ｖａ３、ｖａ４とする。

ストレージ装置Ｂも図５に示すストレージ装置Ａと同様の構成を有する。なお本実施例では、ストレージ装置Ｂも２個のデータＩ／Ｆと４個の実ボリュームを有する。ストレージ装置ＢのデータＩ／Ｆ ＩＤの値はｄ１、ｄ２、ボリュームＩＤの値はｖｂ１、ｖｂ２、ｖｂ３、ｖｂ４とする。

図８にはＳＡＮ管理サーバ１００００が保持する装置検出リスト１３５００の一例を示す。図８の検出対象ＩＤ欄にはＳＡＮ管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはＳＡＮ内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、ＩＰアドレス情報欄には各装置の管理用ネットワーク７００００上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録される。本リストに基づき、ＳＡＮマネージャ１３１００は各装置の管理エージェントを特定して当該管理エージェントと通信する。

図９に各サーバ２００００が保持するデータＩ／Ｆ管理テーブルの一例を示す。（ａ）はサーバＡの、（ｂ）はサーバＢのテーブルであり、それぞれＩＤがａ１、ｂ１のデータＩ／Ｆに関する情報を保持している。図８のデータＩ／Ｆ ＩＤ欄には各サーバが有するデータＩ／ＦのＩＤの値が登録され、ＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）欄には当該データＩ／ＦのＷＷＮが登録され、ＳＣＳＩ ＩＤ欄にはデータＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスの識別子（ＳＣＳＩ ＩＤ番号）が登録される。ここでＷＷＮとはファイバチャネル６００００上でデータＩ／Ｆを一意に識別するための識別子である。

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

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

図１２にバーチャリゼーション装置３００００が保持するデータＩ／Ｆ管理テーブル３３４００の一例を示す。図１２では、バーチャリゼーション装置３００００がデータＩ／Ｆ ｓ１、ｓ２から仮想ボリュームを提供しており、各サーバからはｓ１、ｓ２が仮想データＩ／Ｆ ｖｓ１とｖｓ２として認識されている場合を示す。データＩ／Ｆ管理テーブルのデータＩ／Ｆ ＩＤ欄にはバーチャリゼーション装置３００００のデータＩ／ＦのＩＤの値が登録され、仮想データＩ／Ｆ ＩＤ欄には各サーバに当該データＩ／Ｆの識別子として認識させている識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該仮想データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録される。

図１３にバーチャリゼーション装置３００００が保持する仮想ボリューム管理テーブル３３５００の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想データＩ／Ｆ ＩＤ欄には、バーチャリゼーション装置が有する仮想データＩ／Ｆの識別子の値（図１２の仮想データＩ／Ｆ ＩＤ欄に登録される識別子の値）が登録され、ＳＣＳＩ ＩＤ欄には当該仮想データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該仮想データＩ／Ｆを介してサーバに提供される仮想ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録され、仮想ボリュームＩＤ欄には当該仮想データＩ／Ｆを介してサーバに提供している仮想ボリュームに対して任意に割り当てた識別子が登録される。本実施例においては、バーチャリゼーション装置３００００は、仮想データＩ／Ｆ ｖｓ１から仮想ボリュームｖｖ１を提供し、仮想データＩ／Ｆ ｖｓ２から仮想ボリュームｖｖ２を提供している。ここで仮想ボリューム欄に仮想データＩ／Ｆ ｖｓ１に関するエントリが２つあるのは、後述するように仮想データＩ／Ｆ ｖｓ１から提供される仮想ボリュームｖｖ１が２つの実ボリュームｖａ２とｖｂ１から構成されているためである。

次に仮想ボリューム管理テーブル３３５００の実ボリューム欄の内容を説明する。実データＩ／Ｆ ＩＤ欄には、仮想ボリュームＩＤ欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、バーチャリゼーション装置上のデータＩ／Ｆの識別子が登録される。ＳＣＳＩ ＩＤ欄には当該実データＩ／Ｆの接続先であるＳＣＳＩターゲットデバイスのＳＣＳＩ ＩＤ番号が登録され、ＬＵＮ欄には当該実データＩ／Ｆを介してストレージ装置から提供されるボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録さる。実ボリューム情報欄には、ＳＣＳＩ ＩＮＱＵＩＲＹコマンドなどにより取得可能な、当該実データＩ／Ｆを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。尚、データＩ／Ｆ ｓ４からアクセス可能な実ボリュームｖａ３、ｖａ４及びデータＩ／Ｆ ｓ６からアクセス可能な実ボリュームｖｂ３は、バーチャリゼーション装置に認識されており、将来仮想ボリュームを構成してサーバに提供され得るが、現在は仮想ボリュームとしてサーバへ提供されてはいない。従って実ボリュームｖａ３、ｖａ４、ｖｂ３に関する情報は実ボリューム欄にのみ登録されており、仮想ボリューム欄には登録されていない。また、データＩ／Ｆ ｓ３からアクセス可能な実ボリュームｖａ１は、バーチャリゼーション装置において仮想化されることなくサーバに提供されるため、ｖａ１に関する情報は仮想ボリューム管理テーブル３３５００に登録されていない。

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

図１５にストレージ装置が保持する実ボリューム管理テーブルの一例を示す。（ａ）はストレージ装置Ａが、（ｂ）はストレージ装置Ｂが有するテーブルである。実ボリューム管理テーブルの実ボリュームＩＤ欄にはストレージ装置が有する実ボリュームのＩＤの値が登録され、パス有無欄には当該実ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データＩ／Ｆ ＩＤ欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータＩ／Ｆの識別子の値が登録され、ＳＣＳＩ ＩＤ欄には当該データＩ／Ｆに割り当てられたＳＣＳＩ ＩＤ番号が登録され、ＳＣＳＩ ＬＵＮ欄には当該実ボリュームにアクセスするためのＳＣＳＩロジカルユニット番号が登録される。

（１−２）仮想ボリューム及び実ボリュームの構成管理処理
次に、ＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、仮想ボリューム及び実ボリュームの構成管理処理について説明する。以下、特に明記のない限りは、各ステップはＳＡＮマネージャ１３１００が実施するものとする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えばＳＡＮ管理者が、ＳＡＮ管理サーバの入力手段に対して、仮想トポロジ表示２０２０上の、仮想ボリュームｖｖ１からサーバＡまでの仮想マッピング２０２１を指定する指示を与えた場合を考える。仮想マッピング２０２１は図７に示す仮想ボリュームマッピング管理テーブル１３３００中で仮想マッピングＩＤ１３３０１がｖｍ２である行に登録されたデータに基づいて表示されている。そこで仮想マッピング２０２１がＳＡＮ管理者によって指定されると、ＳＡＮマネージャは仮想マッピング２０２１に対応する仮想マッピングＩＤ ｖｍ２をキーとして、図６に示す実ボリュームマッピング管理テーブル１３２００を検索する。そしてＳＡＮマネージャは、実ボリュームマッピング管理テーブル１３２００中で対応仮想マッピングＩＤ１３２１２がｖｍ２である行全てに登録されているデータに基づいて、実トポロジ表示２０１０内に実マッピングを表示する。この結果表示される実マッピングが図１９に示す実マッピング２０１１である。また、例えばＳＡＮ管理者が、ＳＡＮ管理サーバの入力手段に対して、実トポロジ表示２０１０上の、実ボリュームｖａ２からサーバＡまでの実マッピングを指定する指示を与えた場合を考える。実ボリュームｖａ２からサーバＡまでの実マッピングは、図６に示す実ボリュームマッピング管理テーブル１３２００中で実マッピングＩＤ１３２０１がｐｍ２である行に登録されたデータに基づいて表示されている。そこで当該実マッピングがＳＡＮ管理者によって指定されると、ＳＡＮマネージャは当該実マッピングのエントリに格納された仮想マッピングＩＤ１３２１２の値 ｖｍ２をキーとして、図７に示す仮想ボリュームマッピング管理テーブル１３３００を検索する。そしてＳＡＮマネージャは、仮想ボリュームマッピング管理テーブル１３３００中で仮想マッピングＩＤ１３２１２がｖｍ２である行に登録されているデータに基づいて、仮想トポロジ表示２０２０内に仮想マッピング２０２１を表示する。また、ＳＡＮマネージャは、仮想マッピングＩＤ１３２１２の値 ｖｍ２をキーとして、図６に示す実ボリュームマッピング管理テーブル１３２００も検索し、仮想マッピングＩＤ１３２１２の値が ｖｍ２である他の実マッピングの行を検索する。もし照合するものがあれば、実トポロジ表示２０１０内に照合された実マッピングを表示する。この結果表示される仮想マッピングが図１９に示す仮想マッピング２０２１である。

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

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

＜実施例２−バーチャリゼーション装置の障害監視−＞
以下に、バーチャリゼーション装置の障害監視機能の一例について示す。現在のＳＡＮ管理ソフトによる障害監視機能は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で作成されたＲＦＣ１１５７「Ａ Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ （ＳＮＭＰ）」によって定められたＳＮＭＰプロトコルのＴｒａｐメッセージを利用することが多い。しかし、仮想ストレージ技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。

そこで本実施例では、ＳＡＮ管理サーバが図２に示す構成に加え、ＳＡＮ内の各装置から受信する障害通知メッセージの内容を解釈するためのイベント変換リストを保持する。各装置が発行する障害通知を受けたＳＡＮマネージャは、イベント変換リストや、各管理エージェントから取得して実トポロジリボジトリに格納したＳＡＮの構成情報をもとに、その障害が実ボリュームへのＩ／Ｏアクセスに与える影響を検出する。さらに、ＳＡＮマネージャは仮想ボリュームマッピング情報を参照し、その障害が仮想ボリュームへのＩ／Ｏアクセスに与える影響を検出する。そして、これらの検出結果をＳＡＮマネージャは仮想ボリュームマッピング情報と実ボリュームマッピング情報に関連付けて出力することによって、ＳＡＮ管理者の障害特定と障害対策の負荷を軽減する。

（２−１）実施例２のＳＡＮの構成
実施例２におけるＳＡＮ及びＳＡＮ内の各装置の構成は実施例１で示した構成にほぼ等しいので、異なる点のみ説明する。

図２０に実施例２におけるＳＡＮ管理サーバ１００００の構成例を示す。実施例２においては、ＳＡＮ管理サーバ１００００が記憶領域１３０００内に、ＳＡＮ内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上のイベント辞書１３６００と、イベント内容を記録するための障害ログ１３７００を有する。

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

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

図２１に、ＳＡＮ管理サーバ１００００がイベント辞書１３６００中に有するストレージＡに関するＳＮＭＰ Ｔｒａｐメッセージの変換リストの例を示す。本リストは、ストレージＡが発行するＳＮＭＰ ＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールド中の障害コードが、どの部位の障害を示すかを一覧にしたものであり、各障害コードに対応する障害発生部位と当該障害発生部位の識別子が登録されている。

図２２にはＳＡＮ管理サーバ１００００が有する障害ログ１３７００を示す。障害ログにはＳＡＮマネージャが障害通知メッセージを受信した時に割り当てるイベントＩＤ、障害通知メッセージの送信元装置名、障害が発生している装置内の部位、当該部位を含む実マッピングのＩＤと、当該部位を含む仮想マッピングのＩＤが登録される
（２−２）実施例２のバーチャリゼーション装置の障害監視処理
図２３にＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、障害監視処理のフローチャート２４００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。

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

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

ステップ２４２０において、抽出したＩＰアドレスが装置検出リスト１３５００内に存在し、Ｔｒａｐメッセージ発行元の装置が特定できた場合、ＳＡＮマネージャはＳＡＮ管理サーバ１００００が当該装置のイベント変換リストを具備しているか確認する（ステップ２４２５）。イベント変換リストを具備している場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当てると共に、装置名を登録する（ステップ２４３０）。続いてＳＡＮマネージャはＴｒａｐメッセージのＶａｒｉａｂｌｅ Ｂｉｎｄｉｎｇｓフィールドをキーとしてイベント変換リストを検索し、障害部位を特定し、障害部位とその識別子を障害ログ１３７００に登録する（ステップ２４３０）。ステップ２４２５でイベント変換リストを具備していないと判断した場合は、ＳＡＮマネージャは障害ログ１３７００に新規エントリを作成し、イベントＩＤを割当てるとともに、装置名を登録する（ステップ２４３１）。また、ＳＡＮマネージャは障害部位は装置全体みなし、装置全体を障害ログ１３７００に障害部位として登録し、以降のステップを継続する（ステップ２４３６）。

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

図２２は、ストレージＡからデータＩ／Ｆ ｃ２の障害を示す障害コード３０ｃ２を含むＳＮＭＰ Ｔｒａｐメッセージが発行された場合に、このＳＮＭＰ Ｔｒａｐメッセージを受信したＳＡＮマネージャが図２３に示す処理を実行した結果作成される障害ログを示している。ストレージＡのデータＩ／Ｆ ｃ２は実ボリューム管理テーブル１３２００内で仮想マッピングＩＤ ｖｍ２と対応付けられており、仮想マッピングＩＤ ｖｍ２は実ボリューム管理テーブル１３２００内で実マッピングＩＤ ｐｍ２及び実マッピングＩＤ ｐｍ３と対応付けられているから、障害ログ１３７００は図２２に示すような内容となる。

図２４には、ＳＡＮマネージャが、図１９に示す実トポロジ表示および仮想トポロジ表示に図２２に示す障害ログの内容を反映させて出力手段１５０００に出力する障害通知メッセージの例を示す。

実ボリュームマッピング管理テーブル１３２００の内容をもとにした出力例が実トポロジ表示２０１０であり、実トポロジ表示内には障害ログ１３７００に登録された実マッピングＩＤが示す実マッピングが、障害の影響を受ける実マッピング２１１１として表示される。更に、障害ログ１３７００に登録された障害装置名、障害部位、及び障害ログに登録された実マッピングＩＤと対応付けられて実ボリュームマッピング管理テーブル１３２００に登録されているＬＵ ＩＤ１３２０３が表示される（実トポロジ表示内障害通知メッセージ２０１２）。

更にＳＡＮマネージャは、仮想ボリュームマッピング管理テーブル１３３００の内容をもとに出力する仮想トポロジ表示２０２０に、障害ログ１３７００に登録された仮想マッピングＩＤが示す仮想マッピングを、障害の影響を受ける仮想マッピング２１２１として表示する。また、障害ログ１３７００に登録された障害装置名、障害部位、及び障害ログに登録された仮想マッピングＩＤと対応付けて仮想マッピング管理テーブル１３３００に登録されているボリュームＩＤ１３３１１も表示される（仮想トポロジ表示内障害通知メッセージ２０２２）。

本実施例で示したバーチャリゼーション装置の障害監視方法を用いることで、ＳＡＮ管理者は、各装置のハードウェア障害が実ボリュームおよび仮想ボリュームにどのような影響を与えるかを容易に把握することができる。

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

そこで、本実施例では、ＳＡＮ管理者がＳＡＮマネージャを利用して仮想ボリュームを作成する時、ＳＡＮマネージャが関連する仮想ボリュームマッピング情報ないしは実ボリュームマッピング情報を提供し、ＳＡＮ管理者の仮想ボリューム作成作業を支援する技術について説明する。本実施例では、ＳＡＮ管理サーバが仮想ボリュームマッピング情報ないしは実ボリュームマッピング情報をもとにＳＡＮ管理者の仮想ボリューム作成要求をチェックし、作成要求中のボリュームが既に割当済みのボリュームと資源を共有する場合にはその旨を出力してＳＡＮ管理者に通知するよう、ＳＡＮ管理サーバを構成する。

本実施例におけるＳＡＮの構成、ＳＡＮ内の各装置の構成は実施例１に示す構成と同様である。但し、本実施例においてはＳＡＮ管理サーバが図２に示す構成に加え、更にキーボードやマウス等の入力装置を備えている。

図２５にＳＡＮ管理サーバ１００００上のＳＡＮマネージャ１３１００が実施する、ボリュームの構成変更チェック処理のフローチャート２６００を示す。以下、特に明記のない場合は、各ステップはＳＡＮマネージャ１３１００が実施するものとする。ＳＡＮマネージャ１３１００は、ＳＡＮ管理者からボリューム割当のための入力値を受け付ける（ステップ２６１０）。ここで入力値とは、ＳＡＮ管理者が作成しようとしている仮想ボリュームの属性（割当先サーバ、容量、要求する性能など）である。また、実トポロジリポジトリ１３４００内にコピーされた仮想ボリューム管理テーブル１４１３０には、バーチャリゼーション装置３００００が認識済みであるが、未だ仮想ボリュームとして使用されていない実ボリューム（以下未使用実ボリューム）の情報も登録されている。したがって、ＳＡＮ管理者が容量や性能を入力するのではなく、仮想ボリュームを作成するための一つ以上の未使用ボリュームを入力して未使用ボリュームを直接指定することも考えられる。

与えられた入力値をキーとして、ＳＡＮマネージャ１３１００は、実ボリュームマッピング管理テーブル１３２００及び仮想ボリュームマッピング管理テーブル１３３００を検索する（ステップ２６２０）。具体的にはＳＡＮマネージャ１３１００は、ＳＡＮ管理者から受け付けた割当先サーバをキーとして実ボリュームマッピング管理テーブル及び仮想ボリュームマッピング管理テーブルを検索し、当該割当先サーバに既に割り当てられている仮想ボリュームとその仮想ボリュームに対応する実ボリューム情報を抽出する。また入力値として仮想ボリュームを構成する未使用ボリュームが指定されていない場合は、ＳＡＮマネージャは容量など入力値が示す条件に合致する一つ以上の未使用ボリュームの情報を、仮想ボリューム管理テーブル３３５００を検索して抽出する。

ＳＡＮマネージャは検索結果に基づき、これから割り当てる仮想ボリュームを構成する未使用ボリュームの一覧と、割当先サーバに既に割当済みの仮想ボリューム及び該仮想ボリュームに対応する実ボリューム情報を出力する。（ステップ２６３０）。この際、これからサーバに割り当てられる未使用ボリュームと、このサーバに既に割当済みの仮想ボリューム及び該仮想ボリュームに対応する実ボリュームとの間で資源を共有する場合（例えば、同じストレージ装置が有する実ボリュームがある場合）にはその旨を出力する。これによって、ＳＡＮ管理者は正常系と待機系とが資源を共有しないよう（例えば、同じストレージ装置の記憶領域を使用しないよう）サーバに仮想ボリュームを割り当てることが可能となる。即ち、ＳＡＮ管理者は、これからサーバに割り当てられる未使用ボリュームと、このサーバに割当済みのボリュームとが資源を共有する旨のメッセージが出力された場合には、構成変更を実施しない旨をＳＡＮ管理サーバに入力すればよい。そしてＳＡＮ管理者は出力された情報をもとにＳＡＮ管理者が構成変更を実施するかどうか判断した結果を受け付け（ステップ２６４０）、変更を実施してもよければ変更を実施する（ステップ２６５０）。そうでなければ変更を中止する（ステップ２６６０）。以上でフローチャート２６００を終了する。尚、これからサーバに割り当てられる未使用ボリュームと、このサーバに既に割当済みのボリュームとが資源を共有する場合には、ＳＡＮ管理サーバが、構成変更を実施しないよう制御することとしてもよい。

本実施例で示したボリュームの構成変更チェック処理により、ＳＡＮ管理者は、仮想ボリューム管理機能が稼動している状況下においても、容易に実ボリュームを意識した仮想ボリューム作成が可能となる。

尚、以上で説明した実施例１、実施例２、実施例３においては、スイッチ３００００がバーチャリゼーション機能を備えているネットワーク構成を想定していたが、スイッチ３００００とは異なる装置をバーチャリゼーション装置として管理ネットワーク７００００及びＳＡＮ６００００に接続した構成であっても、上述の実施例１、２、３は同様の処理により実現可能である。

ストレージネットワークシステムの構成例を示す図である。 ＳＡＮ管理サーバの構成例を示す図である。 サーバの構成例を示す図である。 バーチャリゼーション装置の構成例を示す図である。 ストレージ装置の構成例を示す図である。 ＳＡＮ管理サーバが保持する実ボリュームマッピング管理テーブルの例を示す図である。 ＳＡＮ管理サーバが保持する仮想ボリュームマッピング管理テーブルの例を示す図である。 ＳＡＮ管理サーバが保持する装置検出リストの例を示す図である。 サーバが保持するデータＩ／Ｆ管理テーブルの例を示す図である。 サーバが保持するボリューム管理テーブルの例を示す図である。 バーチャリゼーション装置が保持するＦＣ接続管理テーブルの例を示す図である。 バーチャリゼーション装置が保持するデータＩ／Ｆ管理テーブルの例を示す図である。 バーチャリゼーション装置が保持する仮想ボリューム管理テーブルの例を示す図である。 ストレージが保持するデータＩ／Ｆ管理テーブルの例を示す図である。 ストレージが保持する実ボリューム管理テーブルの例を示す図である。 ＳＡＮ管理サーバが行うストレージネットワークの実トポロジ及び仮想トポロジ表示処理の一例を示すフローチャートである。 ＳＡＮ管理サーバが行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 ＳＡＮ管理サーバが行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。 ＳＡＮ管理サーバが出力する実トポロジ表示及び仮想トポロジ表示の一例を示す図である。 ＳＡＮ管理サーバの他の構成例を示す図である。 ＳＡＮ管理サーバが保持するストレージに関するイベント変換リストの例を示す図である。 ＳＡＮ管理サーバが保持する障害ログの例を示す図である。 ＳＡＮ管理サーバが行う障害監視処理の一例を示すフローチャートである。 ＳＡＮ管理サーバが出力する、障害通知表示の一例を示す図である。 ＳＡＮ管理サーバが行うボリュームの構成変更チェック処理の一例を示すフローチャートである。 ＳＮＭＰ Ｔｒａｐメッセージの構成例を示す図である。

符号の説明

１００００…ＳＡＮ管理サーバ
１３１００…ＳＡＮマネージャ
２００００…サーバ
３００００…バーチャリゼーション装置
４００００…ストレージＡ
５００００…ストレージＢ
２３１００…サーバの管理エージェント
３３１００…スイッチの管理エージェント
４３１００…ストレージＡの管理エージェント
５３１００…ストレージＢの管理エージェント
４７０００…ストレージＡの実ボリューム
５７０００…ストレージＢの実ボリューム

Claims (8)

1. 第１の実ボリュームを有する第１のストレージ装置と、
   第２の実ボリュームを有する第２のストレージ装置と、
   ネットワークを介して前記第１および第２のストレージ装置と接続され、前記第１のストレージ装置内の第１の実ボリュームおよび前記第２のストレージ装置内の第２の実ボリュームから構成される仮想ボリュームをサーバに提供するバーチャリゼーション装置と、
   前記第１および第２のストレージ装置、前記バーチャリゼーション装置、及び前記サーバを接続するネットワークの情報を表示するために、前記ネットワークに接続される管理サーバによって実行される障害情報表示方法であって、
   前記第１および第２のストレージ装置、前記バーチャリゼーション装置、及び前記サーバから、前記ネットワークの接続関係に関するネットワーク情報を受信するステップと、
   前記第１のストレージ装置から前記第１の実ボリュームに関する実ボリューム情報を受信し、前記第２のストレージ装置から前記第２の実ボリュームに関する実ボリューム情報を受信するステップと、
   前記バーチャリゼーション装置から、前記仮想ボリュームに関する仮想ボリューム情報を受信するステップと、
   前記ネットワーク情報および前記仮想ボリューム情報に基づいて、前記サーバから前記仮想ボリュームまでの仮想接続パスを示した仮想トポロジ情報を表示するステップと、
   前記ネットワーク情報と、前記第１および第２の実ボリュームに関する実ボリューム情報に基づいて、前記サーバから前記第１のストレージ装置内の前記第１の実ボリュームおよび前記第２のストレージ装置内の前記第２の実ボリュームまでの実接続パスを示す実トポロジ情報を表示するステップとを有し、
   更に、前記仮想接続パスに関連する障害の検出情報を受信した場合であって、前記仮想トポロジ情報を表示した状態で前記障害に関連する仮想接続パスを指定する指示を受信した場合、前記実トポロジ情報の表示上における前記指定された仮想接続パスに対応する前記実接続パスを特定し、該実接続パス上の前記障害の要因となる障害部位を特定し、前記実トポロジ情報の表示に際して該障害部位を該実接続パスに反映して表示することを特徴とする、障害情報表示方法。
2. 請求項１記載の障害情報表示方法において、
   前記仮想接続パスに関連する障害の検出情報は、前記仮想ボリュームに関連する障害の検出情報であることを特徴とする障害情報表示方法。
3. 請求項１記載の障害情報表示方法において、
   前記バーチャリゼーション装置は、複数のインタフェース部を有するスイッチであり、
   前記仮想トポロジ情報を表示するステップにおいて、前記仮想接続パスは、前記サーバから前記スイッチ内の前記複数のインタフェース部のうちの一以上のインタフェース部を介して前記仮想ボリュームまでの接続関係を示すことを特徴とする障害情報表示方法。
4. 請求項１記載の障害情報表示方法であって、
   前記第１のストレージ装置は、更に、インタフェースを有し、
   前記障害部位を反映して表示する場合、前記指定された仮想接続パスに対応する前記実接続パス上の前記障害の要因となる障害部位は、前記インタフェースであることを特徴とする障害情報表示方法。
5. 第１の実ボリュームを有する第１のストレージ装置と、
   第２の実ボリュームを有する第２のストレージ装置と、
   ネットワークを介して前記第１および第２のストレージ装置と接続され、前記第１のストレージ装置内の第１の実ボリュームおよび前記第２のストレージ装置内の第２の実ボリュームから構成される仮想ボリュームをサーバに提供するバーチャリゼーション装置と、
   前記第１および第２のストレージ装置、前記バーチャリゼーション装置、及び前記サーバとに、ネットワークを介して接続される管理サーバであって、
   前記ネットワークと接続されるインタフェースと、
   プロセッサと、
   出力部とを有し、
   前記インタフェースを介して、前記第１および第２のストレージ装置、前記バーチャリゼーション装置、及び前記サーバから、前記ネットワークの接続関係に関するネットワーク情報を受信し、
   前記インタフェースを介して、前記第１のストレージ装置から前記第１の実ボリュームに関する実ボリューム情報を受信し、前記第２のストレージ装置から前記第２の実ボリュームに関する実ボリューム情報を受信し、
   前記インタフェースを介して、前記バーチャリゼーション装置から、前記仮想ボリュームに関する仮想ボリューム情報を受信し、
   前記プロセッサは、前記ネットワーク情報および前記仮想ボリューム情報に基づいて、前記サーバから前記仮想ボリュームまでの仮想接続パスを示した仮想トポロジ情報を前記出力装置に表示させ、
   前記ネットワーク情報と、前記第１および第２の実ボリュームに関する実ボリューム情報に基づいて、前前記サーバから前記第１のストレージ装置内の前記第１の実ボリュームおよび前記第２のストレージ装置内の前記第２の実ボリュームまでの実接続パスを示す実トポロジ情報を前記出力装置に表示させ、
   更に、前記仮想接続パスに関連する障害の検出情報を受信した場合であって、前記仮想トポロジ情報を表示した状態で前記障害に関連する仮想接続パスを指定する指示を受信した場合、前記実トポロジ情報の表示上における前記指定された仮想接続パスに対応する前記実接続パスを特定し、該実接続パス上の前記障害の要因となる障害部位を特定し、前記実トポロジ情報の表示に際して該障害部位を該実接続パスに反映させて前記出力装置に表示させることを特徴とする、管理サーバ。
6. 請求項５記載の管理サーバにおいて、
   前記プロセッサは、仮想接続パスに関連する障害として、前記仮想ボリュームに関連する障害の検出情報を受信することを特徴とする管理サーバ。
7. 請求項５記載の管理サーバにおいて、
   前記バーチャリゼーション装置は、複数のインタフェース部を有するスイッチであり、
   前記プロセッサは、前記仮想接続パスとして、前記サーバから前記スイッチ内の前記複数のインタフェース部のうちの一以上のインタフェース部を介して前記仮想ボリュームまでの接続関係を示す情報を前記出力装置に表示させることを特徴とする管理サーバ。
8. 請求項５記載の管理サーバであって、
   前記第１のストレージ装置は、更に、インタフェース部を有し、
   前記プロセッサは、前記指定された仮想接続パスに対応する前記実接続パス上の前記障害の要因となる障害部位が前記インタフェース部であることを前記出力装置に表示させることを特徴とする管理サーバ。

Images