JP4130615B2 - Fault information management method and management server in a network having a storage device - Google Patents

Fault information management method and management server in a network having a storage device Download PDF

Info

Publication number
JP4130615B2
JP4130615B2 JP2003189954A JP2003189954A JP4130615B2 JP 4130615 B2 JP4130615 B2 JP 4130615B2 JP 2003189954 A JP2003189954 A JP 2003189954A JP 2003189954 A JP2003189954 A JP 2003189954A JP 4130615 B2 JP4130615 B2 JP 4130615B2
Authority
JP
Japan
Prior art keywords
failure
failure notification
volume
real
notification
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.)
Expired - Fee Related
Application number
JP2003189954A
Other languages
Japanese (ja)
Other versions
JP2005025483A (en
Inventor
山本  政行
高 大枝
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2003189954A priority Critical patent/JP4130615B2/en
Priority to US10/659,362 priority patent/US7076688B2/en
Priority to EP04013828A priority patent/EP1494118A3/en
Publication of JP2005025483A publication Critical patent/JP2005025483A/en
Priority to US11/288,205 priority patent/US7409583B2/en
Priority to US11/437,700 priority patent/US7406622B2/en
Priority to US12/216,472 priority patent/US7669077B2/en
Application granted granted Critical
Publication of JP4130615B2 publication Critical patent/JP4130615B2/en
Priority to US12/687,367 priority patent/US7937614B2/en
Priority to US13/072,947 priority patent/US8397102B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0766Error or fault reporting or storing
    • G06F11/0781Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/0706Error 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/0727Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error 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/079Root cause analysis, i.e. error or fault diagnosis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management 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/065Management 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02Standardisation; Integration
    • H04L41/0213Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/046Network management architectures or arrangements comprising network management agents or mobile agents therefor
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements 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)

Description

【0001】
【発明の属する技術分野】
本発明は、ストレージシステムを有する計算機システムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、仮想ボリュームとしてサーバに提供されるストレージエリアネットワーク(Storage Area Network、以下SAN)において、ストレージシステムの障害を管理する方法及び装置に関するものである。
【0002】
【従来の技術】
(1)SANについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるSANが浸透しつつある。SANの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
【0003】
(2)SAN管理について
SANによるストレージシステムの高い拡張性は、SANにおける複数ベンダの装置(サーバ、スイッチ、ストレージ装置)の混在を可能とした。このようなSANを無停止で運用するために、SAN管理が必要である。
【0004】
SAN管理の概要については、例えば非特許文献1で説明されている。SAN管理の中でも、日々の運用の基本となる、SANに接続される各装置の稼動状況監視が特に重要である。SANの稼動状況を監視するためのソフトウェアを、以降SANマネージャとよぶ。
【0005】
SANマネージャは、構成管理機能と障害監視機能の二大機能を持つ。
【0006】
構成管理機能とは、SANに接続される各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からSANの物理的な接続関係(トポロジ)を検出し、常に最新のトポロジを視覚化してSANマネージャのユーザ、言い換えるとSAN管理者に提供する機能である。
【0007】
障害監視機能とは、SANに接続される各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをSAN管理者に通知する機能である。
【0008】
これら二つの機能により、SAN管理者はSANマネージャを用いて装置の稼動状況を一元的に管理できるので、SAN管理者の少人数化など運用コストの削減を図ることができる。
【0009】
(3)バーチャリゼーション装置について
SANにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献1に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。
【0010】
1)ストレージサーバに接続された各ストレージ装置が有する記憶媒体内の記憶領域であるボリューム(以下実ボリューム)を管理し、ボリュームプールを生成する機能。
【0011】
2)ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのI/Oアクセスを逐次実ボリュームへのI/O要求に変換してサーバからのI/Oに応答する機能。
【0012】
これら二つの機能を有する装置を、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をSANに導入することにより、サーバへのボリューム割当は仮想ボリュームにより一元化され、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。つまり、SAN管理者は一元的にボリュームの割当を行うことができる。
【0013】
【特許文献1】
英国特許出願公開第2351375号明細書
【非特許文献1】
リチャードベーカー(Richard Barker)、ポールマッシグリア(Paul Massiglia)、“ストレージエリアネットワークエッセンシャルズ(Storage Area Network Essentials)”、ジョンウィリーアンドサンズインク(John Wiley & Sons, Inc)、2002年、p.331-334
【0014】
【発明が解決しようとする課題】
SANマネージャの持つ障害監視機能により、SAN管理者は、複数の装置から発行されたイベントを元に、どの装置のどの部位が障害の原因かを切り分ける作業を行う。以降これを、「障害の切り分け」と呼ぶ。バーチャリゼーション装置が仮想ボリュームを提供することにより、サーバに提供されるボリュームの構成自由度は高まる。しかし、SANに接続される複数ベンダの装置から発行された障害メッセージ(SNMP Trapなど)をもとに障害の切り分けをするには、個々の装置について高度な知識を持ったSAN管理者の手動作業に頼っているのが現状であり、管理コストが非常に高いという課題がある。
【0015】
また、SANマネージャは、障害の深刻さ(以降Severityと呼ぶ)に応じて、業務システム全体を運用管理する管理ソフトウェア(以降上位システム管理ソフトと呼ぶ)へイベントを通知したり、SAN管理者へのメールを送信したりといった、障害通報機能を持つ。しかし、障害のSeverityの定義はSANに接続される各装置に依存するため、どの装置のどのイベントが高いSeverityを持つか、その都度SAN管理者が判断する必要があり、障害対策に時間を要するという課題がある。
【0016】
本発明の第一の目的は、SANに接続される装置から障害メッセージが発行された場合に、SAN管理者による障害の切り分けを支援することである。
【0017】
本発明の第二の目的は、SANにおいて、SAN管理者や上位システム管理ソフトが、SANに接続される装置から発行された障害メッセージのうち、必要な障害情報を受信することができるようにすることである。
【0018】
【課題を解決するための手段】
第一の目的に対して、SANに接続された装置から複数の障害通知を受信する管理サーバは、バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、複数の障害通知を関連づけて出力する。
【0019】
又、第二の目的に対して、SANに接続された装置から複数の障害通知を受信する管理サーバは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する。
【0020】
【発明の実施の形態】
以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発明が限定されるものではない。
【0021】
<SANの構成>
まず本実施形態におけるSANの構成例について説明する。図1から図6はSAN及びSANに接続される各装置の構成例を示し、図9から図18は各装置内に具備された管理情報を示している。
【0022】
図1にはSANの構成例を示す。本発明におけるSANは、管理エージェントを有する1台以上のサーバ、管理エージェントを有する1台以上のスイッチ、管理エージェントを有する1台以上のバーチャリゼーション装置、管理エージェントを有する1台以上のストレージ装置、そしてSANマネージャを有する1台のSAN管理サーバを有する。
【0023】
以降の説明の都合上、本実施形態のSANにおいては、1台のサーバ(サーバA)20000と、1台のスイッチ(スイッチA)30000と、1台のバーチャリゼーション装置兼ストレージ装置(ストレージ装置A)40000と、1台のストレージ装置(ストレージ装置B 50000)が、ファイバチャネル60000を介して相互に接続されているものとする。本接続形態では、ストレージ装置A40000は、ストレージ装置B50000の実ボリューム57000を、スイッチ30000を介して認識し、仮想ボリューム機能を適用することにより、サーバに対してストレージ装置B50000の実ボリューム57000を、ストレージ装置A40000の仮想化ボリュームとして提供する。なお、ストレージ装置A40000とストレージ装置B50000の接続形態については、図1に示す例の様にスイッチA30000を介して接続するのではなく、例えば図26に示す第二の構成例のように、ファイバチャネル60000によって、ストレージ装置A40000とストレージ装置B50000が直接接続されていてもよい。また、図27に示す第三の構成例のように、ストレージ装置A40000とストレージ装置B50000が直接接続されるパスと両ストレージ装置がスイッチ経由で接続されるパスとが混在していてもよい。
【0024】
SAN管理サーバ10000は、管理用ネットワーク70000を介してサーバ、スイッチ、及びストレージ装置それぞれに接続されており、各装置の管理エージェントとSAN管理サーバ10000内のSANマネージャ13100は管理用ネットワークを介して通信できる。SANマネージャ13100は、後述する処理により、SANにおける仮想ボリュームと実ボリュームの構成管理と、SANにおける障害切り分けと、SANにおける障害通報を行う。
【0025】
図2にはSAN管理サーバ10000の構成例を示す。SAN管理サーバ10000は、プロセッサ11000と、メモリ13000と、管理用ネットワーク70000に接続するための管理インタフェース制御部(以下、I/Fとする。)14000と、SANマネージャ13100によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部15000と、SAN管理者がSANマネージャに指示を入力するためのキーボード等の入力部16000を有し、これらは内部バス等の通信路17000を介して相互に接続される。
【0026】
メモリ13000には、SAN管理サーバによって実行されるプログラムであるSANマネージャ13100と、SANにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル13200と、SANにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル13300と、SAN内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ13400と、SAN内でSANマネージャ13100が管理対象としている装置の一覧を保持する装置検出リスト13500と、SAN内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上の障害解析辞書13600と、イベント内容を記録するための障害ログ13700と、後述するSeverity変換機能を行うにあたり、SAN管理者により予め定義されるSeverity変換定義を保持するための一つ以上の障害Severity変換テーブル13800とが格納されている。
【0027】
図3にはサーバ20000の構成例を示す。サーバ20000は、プロセッサ21000と、メモリ23000と、管理用ネットワーク70000に接続するための管理I/F24000と、ファイバチャネル60000に接続するための一つ以上のデータI/F26000を有し、これらは内部バス等の通信路27000を介して相互に接続される。
【0028】
メモリ23000には、SANマネージャ13100と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント23100と、当該サーバのデータI/Fの管理情報を保持するデータI/F管理テーブル23200と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル23300とが格納されている。
【0029】
なお、本実施形態ではサーバはサーバAの一台、サーバAの具備するデータI/Fは一つとしたが、サーバ台数及びデータI/F数は一には限られず、サーバがSANに複数台接続されていても、又1台のサーバが複数のデータI/Fを備えていても良い。また、各サーバのデータI/Fには各サーバ内で固有の識別子(データI/F ID)が割当てられており、本実施例では、サーバAのデータI/F IDの値をa1とする。
【0030】
図4にはスイッチ30000の構成例を示す。スイッチ30000は、ファイバチャネル60000を介して送受信されるデータのスイッチングを実現するコントローラ31000と、メモリ33000と、管理用ネットワーク70000に接続するための管理I/F34000と、ファイバチャネル60000に接続するための一つ以上のデータI/F36000を有し、メモリ33000と管理I/F34000とデータI/F36000とはコントローラ31000を介して相互に接続される。
【0031】
メモリ33000には、SANマネージャ13100と通信して当該スイッチA の管理情報を送受信するためのプログラムである管理エージェント33100と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル60000を介した接続関係を示す情報であるFC接続管理テーブル33200とが格納されている。
【0032】
なお、本実施形態ではSAN内に存在するスイッチはスイッチAの一台とし、スイッチAは6個のデータI/Fを有する構成としているが、スイッチの台数及びデータI/Fの個数は幾つであっても良い。また、各データI/Fは装置内(スイッチ内)で固有の識別子(データI/F ID)を持ち、本実施形態においてはその値をs1、s2、s3、s4、s5、s6とする。
【0033】
図5にはバーチャリゼーション装置兼ストレージ装置であるストレージ装置Aの詳細な構成例を示す。ストレージ装置A 40000は、ストレージ装置内の制御を行うコントローラ41000と、メモリ43000と、管理用ネットワーク70000に接続するための管理I/F44000と、ファイバチャネル60000に接続するための一つ以上のデータI/F46000と、サーバが利用するデータが格納されるディスク装置内の記憶領域である一つ以上の実ボリューム47000とを有し、メモリ43000と管理I/F44000とデータI/F46000と実ボリューム47000とはコントローラ41000を介して相互に接続される。尚図5にはコントローラ41000に接続される記憶領域として実ボリューム47000の他に、一つ以上の仮想ボリューム48000が図示されている。この仮想ボリューム48000は、他のストレージ装置(例えばストレージ装置B50000)が保持する実ボリュームをストレージ装置Aの仮想ボリューム機能により仮想化したものであり、仮想ボリューム48000はストレージ装置Aのボリュームとしてサーバに提供される記憶領域であるため図5にストレージ装置Aの構成要素として表示しているが、実際の記憶領域はストレージ装置Aに接続される他のストレージ装置内に存在する。
【0034】
メモリ43000には、SANマネージャ13100と通信してストレージ装置Aの管理情報を送受信するためのプログラムである管理エージェント43100と、ストレージ装置AのデータI/Fの管理情報を保持するデータI/F管理テーブル43200と、当該ストレージ装置Aの実ボリューム47000の管理情報を保持する実ボリューム管理テーブル43300と、仮想ボリューム機能を実現するための仮想ボリューム管理プログラム43400と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル43500が格納されている。
【0035】
なお本実施形態では、ストレージ装置Aは2個のデータI/Fと2個の実ボリュームと2個の仮想ボリュームを有するが、データI/F、実ボリューム、及び仮想ボリュームの個数は幾つであっても良い。各データI/F、各実ボリューム、及び各仮想ボリュームは装置内固有の識別子(データI/F ID、実ボリュームID、仮想ボリュームID)を持ち、本実施形態ではデータI/F IDの値をc1、c2、実ボリュームIDの値をva1、va2、仮想ボリュームIDの値をvv1、vv2とする。
【0036】
図6にはストレージ装置Bの詳細な構成例を示す。ストレージ装置Bは、仮想ボリューム機能を持たない点を除いて、ストレージ装置Aと同様の構成を有する。よって、メモリ53000には仮想ボリューム管理プログラムと仮想ボリューム管理テーブルは存在しない。なお、本実施形態では、ストレージ装置Bは2個のデータI/Fと3個の実ボリュームを有するが、データI/F及び実ボリュームの数は幾つであっても良い。また、ストレージ装置BのデータI/F IDの値はd1、d2、ボリュームIDの値はvb1、vb2、vb3とする。
【0037】
図9にはSAN管理サーバ10000が保持する装置検出リスト13500の一例を示す。図9の検出対象ID欄にはSAN管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはSAN内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、IPアドレス情報欄には各装置の管理用ネットワーク70000上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録され、仮想化対象ID欄には、装置情報としてストレージが登録されたエントリであり、当該ストレージ装置が有する実ボリュームが他の装置によって仮想化される場合、仮想化処理を実行する当該他の装置の検出対象IDが登録される。これらの情報はSAN管理者がSAN管理サーバ10000の出力部15000及び入力部16000を用いて予め設定するものとする。本リストに基づき、SANマネージャ13100は各装置の管理エージェントを特定して当該管理エージェントと通信する。
【0038】
図10にサーバA 20000が保持するデータI/F管理テーブルの一例を示す。図10のデータI/F ID欄には各サーバが有するデータI/FのIDの値が登録され、Port WWN(World Wide Name)欄には当該データI/Fに対して割り当てられているファイバチャネル内で一意の識別子となるPort WWNが登録され、SCSI ID欄にはデータI/Fの接続先であるSCSIターゲットデバイスの識別子(SCSI ID番号)が登録される。
【0039】
図11にサーバA 20000が保持するボリューム管理テーブルの一例を示す。サーバAは3つのボリュームの提供を受けており、サーバAはボリューム管理テーブルに自身が提供を受けているボリュームの情報を保持する。ボリューム管理テーブルのLU(Logical Unit) ID欄には、サーバA内で自身が提供を受けているボリュームに対して任意に割当てた識別子が登録される。データI/F ID欄にはボリュームにアクセスするために使用するサーバA上のデータI/Fの識別子が登録され、SCSI ID欄には該データI/Fの接続先であるSCSIターゲットデバイスのSCSI ID番号が登録され、LUN欄にはSCSIターゲットデバイス内の当該ボリュームにアクセスするためのSCSIロジカルユニット番号が登録され、ボリューム情報欄には、SCSI INQUIRYコマンドなどにより取得可能な、サーバに対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。
【0040】
尚、図11の例では、サーバAは、ストレージ装置Aから実ボリュームva1と、実ボリュームはストレージB内に存在するがストレージ装置Aによって仮想化されている仮想ボリュームvv1との提供を受けて使用しており、ストレージ装置Bから実ボリュームvb3の提供を受けて使用している。尚、ストレージ装置Bの実ボリュームvb3は、ストレージ装置Aによって仮想化されることなくサーバAに提供されている。
【0041】
図12にスイッチA 30000が保持するFC接続管理テーブル33300の一例を示す。FC接続管理テーブルは、スイッチA 30000のデータI/Fであるs1からs6の接続先に関する情報を保持する。FC接続管理テーブルのデータI/F ID欄にはスイッチA 30000のデータI/FのIDの値が登録され、スイッチ Port WWN欄には当該データI/FのPort WWNが登録され、接続先Port WWN欄には当該データI/Fが接続するサーバやストレージ装置上のデータI/FのPort WWNが登録される。
【0042】
図13にストレージ装置が保持するデータI/F管理テーブルの一例を示す。データI/F管理テーブル43200はストレージ装置Aが、データI/F管理テーブル53200はストレージ装置Bが有するテーブルである。データI/F管理テーブルのデータI/F ID欄には、ストレージ装置が有するデータI/Fの識別子の値が登録され、Port WWN欄には当該データI/FのPort WWNが登録される。
【0043】
図14にストレージ装置が保持する実ボリューム管理テーブルの一例を示す。実ボリューム管理テーブル23300はストレージ装置Aが、実ボリューム管理テーブル53300はストレージ装置Bが有するテーブルである。実ボリューム管理テーブルの実ボリューム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"を登録する。
【0044】
図15にストレージ装置A 40000が保持する仮想ボリューム管理テーブル43500の一例を示す。まず仮想ボリューム欄の内容を説明する。仮想ボリュームID欄にはサーバに提供している仮想ボリュームに対して任意に割り当てた識別子が登録され、パス有無欄には当該仮想ボリュームに他の装置がアクセスする際に使用されるパスの有無が登録され、データI/F ID欄には当該ボリュームとアクセスするために使用されるストレージ装置上のデータI/Fの識別子の値が登録され、SCSI ID欄には当該データI/Fに割り当てられたSCSI ID番号が登録され、LUN欄には当該実ボリュームにアクセスするためのSCSIロジカルユニット番号が登録される。本実施形態においては、ストレージ装置A 40000は、データI/F c1から仮想ボリュームvv1を提供している。仮想ボリュームvv2は未使用である。
【0045】
次に仮想ボリューム管理テーブル43500の実ボリューム欄の内容を説明する。実データI/F ID欄には、仮想ボリュームID欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、ストレージ装置A上のデータI/Fの識別子が登録される。SCSI ID欄には当該実データI/Fの接続先であるSCSIターゲットデバイスのSCSI ID番号が登録され、LUN欄には当該実データI/Fを介してストレージ装置から提供されるボリュームにアクセスするためのSCSIロジカルユニット番号が登録さる。実ボリューム情報欄には、SCSI INQUIRYコマンドなどにより取得可能な、当該実データI/Fを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。
【0046】
なお、仮想ボリューム管理テーブルには、仮想化装置(例えばストレージ装置A)によって仮想化されるボリュームのデータのみが登録される。従って、データI/F c2からアクセス可能で、ストレージ装置B内に存在する実ボリュームvb1、vb2は、ストレージ装置Aに認識されストレージ装置Aによって仮想化され仮想ボリュームとしてサーバに提供されるので、仮想ボリューム管理テーブルに登録されている。また、データI/F c1からアクセス可能な実ボリュームva1は、ストレージ装置A において仮想化されることなくサーバに提供されるため、va1に関する情報は仮想ボリューム管理テーブル43500に登録されていない。また、ストレージ装置Bの実ボリュームvb3は、データI/Fd2を介してサーバAに直接認識されているため、vb3に関する情報も、仮想ボリューム管理テーブル43500に登録されない。このように、ボリューム仮想化機能を保持するバーチャリゼーション装置は、全てのストレージ装置の実ボリュームを仮想化していなくてもよい。
【0047】
図16にはSAN管理サーバ10000が有する障害解析辞書13600の例を示す。(a)はストレージ装置Aの、(b)はストレージ装置Bの、(c)はサーバAの、(d)はスイッチAの障害解析辞書である。これらの辞書は、各装置から障害発生時等に発行されるSNMP Trapメッセージの解析に用いられるものであり、その詳細は後述する。障害コード欄にはSNMP TrapメッセージのVariable Bindingsフィールド中の障害コードが、障害部位欄には各障害コードに対応する障害発生部位が、識別子欄には障害発生部位を特定するための識別子が、原因欄にはメッセージ発行の原因が、Severity欄にはSNMP TrapメッセージのSpecific Trap Typeフィールド中のTrapのSeverityが登録されている。
【0048】
図17にはSAN管理サーバ10000が有する障害ログ13700を示す。障害ログにはSANマネージャが障害通知メッセージを受信した時に割り当てるイベントID、障害が発生した時刻、障害通知メッセージの送信元装置名、障害通知メッセージ中の障害コード、当該部位を含む実マッピングのID、当該部位を含む仮想マッピングのIDと、他の障害イベントとの関係が登録される
図18には、SAN管理サーバ10000が有する障害Severity変換テーブルの一例を示す。本変換テーブルは、後述するSANマネージャのSeverity変換機能を含む障害通報処理において、SANマネージャが受信する複数の装置の障害メッセージに対する共通のSeverityと、共通のSeverityに応じてSANマネージャが実行する動作を定義するものである。本テーブルは、SAN環境構築にあたりSAN管理者が定義するものとする。障害Severity変換テーブルには、複数の装置の障害メッセージに対する共通のSeverityと、共通のSeverityに対応する各装置のSeverityと、共通のSeverityに応じてSANマネージャが実行する動作が登録される。例えば図18の場合、ストレージ装置AのSeverityが"3"のときと、ストレージ装置BのSeverity"4"、"5"、"6"のとき、SAN環境で共通のSeverity"3"とみなされ、その結果、SANマネージャは、ストレージ装置Aの障害メッセージ情報のみをSNMP Trapとして送信し、かつ、SAN管理者にメールで送信する。尚、Severity変換テーブルは、SANの構成情報に基づいて定義される。図18に示すSeverity変換テーブルにおいては例えば、ストレージAのSeverity3とストレージBのSeverity4〜5が共通Severity3として関連づけられており、共通Severity3の障害通知メッセージに関してはストレージAに関する障害情報のみをSNMP Trapとして送信し、SAN管理者にメールで送信するよう定義されている。これは、ストレージBが有する実ボリュームをストレージAが仮想化してサーバに提供しており、ストレージBが送受信する入出力要求はストレージAを介してサーバが送受信することとなるからであり、従ってストレージAのSeverityとストレージBのSeverityとを関連付け、ストレージA及びストレージBの実ボリュームを仮想化しているストレージAに関する障害情報のみを出力するよう定義されているのである。
【0049】
<SANマネージャの仮想ボリュームマッピング及び実ボリュームマッピング作成処理>
次に、SAN管理サーバ10000上のSANマネージャ13100が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はSAN管理サーバ10000のプロセッサ11000がメモリ13000内に格納されているプログラムを実行することによって定期的に実行されるもので、SAN環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはSANマネージャ13100が実施するものとする。
【0050】
図19にSANマネージャ13100によって実行される実トポロジ及び仮想トポロジ表示処理の概要を表すフローチャート1700を示す。SANマネージャ13100は、装置検出リスト13500を元にSAN内の装置を検出し、各装置の管理エージェントと通信をして、各装置が保持する図10から図15に示す情報をコピーする(ステップ1710)。次にSANマネージャ13100はコピーした情報を実トポロジリポジトリ13400に格納する(ステップ1720)。その後、ステップ1720で格納した情報をもとに、後述する仮想ボリュームマッピング管理テーブル13300を作成する(ステップ1730)。さらに実トポロジリポジトリ13400内の情報と仮想ボリュームマッピング管理テーブル13300をもとに、後述する実ボリュームマッピング管理テーブル13200を作成する(ステップ1740)。最後に仮想ボリュームマッピング管理テーブル13300及び実ボリュームマッピング管理テーブル13200の内容をもとに、実トポロジなどの結果を出力し(ステップ1750)、終了する。
【0051】
図20にSANマネージャ13100によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ1730の詳細な処理を表すフローチャートを示す。また図8に図20に示す処理によって作成される仮想ボリュームマッピング管理テーブル13300の一例を示す。
【0052】
SANマネージャ13100は、各サーバから受信して実トポロジリポジトリ13400に格納した全てのボリューム管理テーブル23300について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する(ステップ1810)。
【0053】
まず、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のPort WWNを調べる。さらにSANマネージャは当該Port WWNをキーとして、スイッチA から受信して実トポロジデポジトリ13400に格納されているFC接続管理テーブル33200を検索し、当該サーバがどのスイッチのどのデータI/Fに接続しているかを検索し、結果を接続先スイッチ名13305と接続先スイッチデータI/F ID13306として登録する(ステップ1830)。以上の処理により、仮想ボリュームマッピング管理テーブル13300の左半分(サーバ欄)にサーバに関する情報が登録される。
【0054】
次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の左半分(ストレージ欄)に情報を登録するための処理を行う。SANマネージャはボリューム管理テーブル23300にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーション装置によって提供されているものか否かを調べる。具体的には、SANマネージャは装置名をキーとして装置検出リスト13500を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーション装置から提供されているものと判断する。(ステップ1840)。ステップ1840の結果により、以下のように処理が分岐する(ステップ1850)。
【0055】
ボリュームがバーチャリゼーション装置 以外のストレージ装置から提供されている場合、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のPort WWNを調べ、さらにWWNをキーとして、スイッチA から受信したFC接続管理テーブル33200を検索し、当該ストレージデータI/FがどのスイッチのどのデータI/Fに接続しているかを調査する。そしてSANマネージャは調査結果を接続先スイッチ名13307と接続先スイッチデータI/F ID13308として登録する(ステップ1870)。
【0056】
ステップ1850においてボリュームがバーチャリゼーション装置から提供されていると判断した場合、SANマネージャは以下の処理を行う。まずSANマネージャはボリューム管理テーブル23300のボリューム情報欄に登録されている装置名とボリュームIDを仮想ボリュームマッピング管理テーブル13300にストレージ名13309及びボリュームID13311として登録する。更にSANマネージャは登録したボリュームID13311をキーとして、バーチャリゼーション装置から受信した仮想ボリューム管理テーブル43500及び実ボリューム管理テーブル43300を検索し、当該ボリュームにアクセスするために使用されるストレージ装置AのデータI/FのIDを調査し、結果をストレージデータI/F ID13310として登録する(ステップ1861)。次に、ストレージ装置Aの当該データI/Fに対応するスイッチのデータI/Fを調査し、スイッチの名前とデータI/F IDを登録する。具体的には、SANマネージャはストレージデータI/F ID13310をキーとして、スイッチA から受信したデータI/F管理テーブル33400を検索し、当該データI/Fに対応するスイッチのデータI/F IDを調査して、結果を接続先スイッチ名13307と接続先スイッチデータI/F ID13308として登録する(ステップ1871)。
【0057】
装置検出リスト13500に装置が未登録のためボリューム管理テーブル23300が実トポロジリポジトリ13400に格納されていない場合、及び、装置が管理I/Fを具備しない場合、ステップ1850では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル23300のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする(ステップ1862)。
【0058】
以上のステップを、SAN管理サーバが各サーバから受信し実トポロジリポジトリ13400に格納した全てのボリューム管理テーブルの全エントリに対して、SANマネージャが実行したとき、ステップ1730の処理は終了する。
【0059】
図21に、SANマネージャ13100が行う実ボリュームマッピング管理テーブル作成ステップ1740の詳細な処理フローを示す。又図7に図21に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。
【0060】
SANマネージャ13100は、ステップ1730で作成した仮想ボリュームマッピング管理テーブル13300の全てのエントリに対して、以下の処理を実行する(ステップ1910)。
【0061】
まず、SANマネージャは新規エントリを作成し、新しく割り当てた実マッピングID13201を登録する(ステップ1920)。次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の各エントリのストレージ名13309をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名13309をキーとして装置検出リスト13500を検索し、当該装置の仮想化機能の有無をチェックする(ステップ1930)。
【0062】
仮想化機能を有する場合、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には、仮想ボリューム管理テーブル43500の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームIDをコピーする。また対応仮想マッピングID欄13212には仮想ボリュームマッピング管理テーブル13300中の仮想マッピングID13301の内容を登録する。ストレージ欄のスイッチ名欄13207には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名13307の内容をコピーする(ステップ1960)。更に、SANマネージャは、実ボリュームマッピング管理テーブル13212のストレージ欄のボリュームID13211に登録したボリュームIDをキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索して、当該ボリュームが接続されるデータI/FのIDを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータI/F ID13210に登録する。
【0063】
ステップ1930にて仮想化機能を有しないとの判断がされた場合、SANマネージャは、仮想ボリュームマッピング管理テーブル13300の現在処理中のエントリ(13302から13311)を実ボリュームマッピング管理テーブル13200のエントリ(13202から13211)へコピーし、仮想ボリュームマッピング管理テーブル13300の仮想マッピングID13301の内容を実ボリュームマッピング管理テーブル13200の対応仮想マッピングID13212に登録する。
【0064】
以上の処理により実ボリュームマッピング管理テーブル13200のエントリ13201から13212までが登録される。
【0065】
以上のステップを仮想ボリュームマッピング管理テーブル13300の全てのエントリに対してSANマネージャが実行したとき、ステップ1740に示す処理が終了する。
【0066】
図7で示された実ボリュームマッピングテーブルをもとに、SANマネージャ13100が出力部15000に出力する実トポロジ表示の例を図23に示す。実ボリュームマッピング管理テーブル13200の内容をもとに、サーバ、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示2010である。
【0067】
<SANマネージャの障害切り分け処理>
以下に、SANマネージャによる障害切り分け処理の一例について示す。
【0068】
現在のSAN管理ソフトによる障害監視機能は、IETF(Internet Engineering Task Force)で作成されたRFC1157「A Simple Network Management Protocol (SNMP)」によって定められたSNMPプロトコルのTrapメッセージを利用することが多い。しかし、仮想ボリューム技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。また、SAN管理者は、複数の装置から発行されたイベントを元に、障害の切り分けするには、現状個々の装置の高度な知識を持ったSAN管理者の手動作業に頼るため、管理コストが非常に高い。
【0069】
そこで本処理では、複数の装置が発行する障害通知を受けたSANマネージャは、障害解析辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したSANの構成情報をもとに、それらの障害が実ボリューム及び仮想ボリュームへのI/Oアクセスに与える影響を解析する。また、当該障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる。そして、これらの結果をSANマネージャが出力することによって、SAN管理者による複数障害メッセージの解析及び障害きりわけ作業を軽減する。
【0070】
ここで、障害切り分け処理を説明する前に、図25にSAN管理サーバ10000上のSANマネージャがSAN内の各装置から受信するSNMP Trapメッセージのフォーマットと、SNMP Trapメッセージの一例を示し、説明しておく。ここでSNMP Trapメッセージとは、SAN内の各装置の管理エージェントがSAN管理サーバ10000に対して送信する障害通知メッセージのことである。図25(a)は、SNMP Trapメッセージのフォーマットを図示したものである。SNMPメッセージは、メッセージヘッダと、メッセージ送信先のコミュニティ名と、メッセージ種別を示すPDU(Protocol Data Unit) Typeと、送信元装置のベンダ名を示すEnterpriseと、送信先IPアドレスを示すAgent Addressと、Trapメッセージの種別を示すGeneric Trap Typeと、TrapメッセージのSeverityを示すSpecific Trap Typeと、メッセージの送信時刻を示すTimestampと、メッセージ内容を格納するVariable Bindingsのフィールドから構成される。PDU Typeフィールドの値が"4"のとき、当該メッセージはSNMP Trapメッセージであると識別される。またGeneric Trap Typeフィールドの値が"6"のとき、当該SNMP Trapメッセージは送信元装置ベンダ固有の定義に基づくTrapメッセージと識別され、各ベンダによって定義されたSpecific Trap Typeフィールドに記載されたSeverityと、Variable Bindingsフィールドに記載された障害コードの内容にもとづき、Trapメッセージを解釈する必要がある。
【0071】
本実施形態において、ストレージA 40000が自装置のハードウェア障害を通知するために送信するSNMP Trapメッセージの一例を図25(b)に示す。図25(b)に示すメッセージは、PDU Typeが”4”であることからSNMP Trapメッセージであると認識され、Generic Trap Typeが”6”であることから送信元ベンダ固有の定義に基づくTrapメッセージであると認識される。また、Specific Trap Typeフィールドには障害のSeverityを、Variable Bindingsフィールドには障害発生部位を示す障害コードを格納するようベンダが定義しているものとする。従って図25(b)に示すSNMP Trapメッセージは、Severityが"1"で障害コード"30c1"の障害が生じている旨を表している。
【0072】
図22に、SAN管理サーバ10000上のSANマネージャ13100が実施する、障害切り分け処理の一例を示すフローチャート2400を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。
【0073】
SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2410)。メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出し(ステップ2415)、抽出したIPアドレスをキーとして実トポロジリポジトリ13400に格納されている装置検出リスト13500を検索する(ステップ2420)。
【0074】
IPアドレスが装置検出リスト13500内に存在しない場合は、未登録の装置からのTrapメッセージであるためSANマネージャはTrapメッセージの内容を解析できない。従ってSANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、障害装置としてIPアドレスを、障害部位としてTrapメッセージそのものを出力し(ステップ2465)、後述するステップ2455の処理にジャンプする。
【0075】
ステップ2420において、抽出したIPアドレスが装置検出リスト13500内に存在し、Trapメッセージ発行元の装置が特定できた場合、SANマネージャはSAN管理サーバ10000が当該装置の障害解析辞書を具備しているか確認する(ステップ2425)。
【0076】
ステップ2425にて障害解析辞書を具備している場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、TrapメッセージのVariable Bindingsフィールドをキーとして障害解析辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する(ステップ2430)。
【0077】
ステップ2425で障害解析辞書を具備していないと判断した場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、SANマネージャは、障害部位は装置全体みなし、障害コード欄には"装置全体"として登録し、以降のステップを継続する(ステップ2431)。
【0078】
ステップ2430あるいはステップ2431が終了した後、SANマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する(ステップ2435)。具体的には、まず、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【0079】
その後、SANマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する(ステップ2440)。具体的には、ステップ2435で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル43500に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから仮想ボリュームIDを抽出する。さらに、抽出した仮想ボリュームIDをキーとして実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索し、実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
【0080】
ステップ2435とステップ2440で障害ログの作成中エントリの、実ボリュームマッピングと、仮想ボリュームマッピングの関係を登録した後、SANマネージャは、当該作成中エントリと、他の障害ログエントリの関係について調査する。まず、SANマネージャは、作成中のエントリが、ハード故障によるものか、他の部位へのアクセスエラーによるものかを調査する(ステップ2445)。具体的には、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとしてその原因を検索する。
【0081】
ステップ2445で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある"親イベント"であると判断し、イベント関係欄に"親イベント"と登録する(ステップ2450)。ステップ2445で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある"子イベント"であると判断し、イベント関係欄に"子イベント"と登録する(ステップ2451)。
【0082】
最後にSANマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する(ステップ2455)。以上でフローチャート2400を終了する。
【0083】
ここで、フローチャート2400で示されたSANマネージャ10000の障害切り分け処理の具体例について説明する。図23は、図17に記載された障害ログのエントリが、フローチャート2400で示された障害切り分け処理により、どのように出力されるかの例を示す図である。ここで、イベントID 1000、1001、1002、1003は、ストレージ装置BのデータI/F ID d1がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。
【0084】
イベントID 1000の障害メッセージを受信したとき、SANマネージャは、ステップ2430でストレージ装置BのデータI/F ID d1のハード故障と解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりハード故障は"親イベント"であることがわかる。
【0085】
次に、イベントID 1001の障害メッセージを受信したとき、SANマネージャは、ステップ2430でストレージ装置Aの仮想ボリュームvv1のI/Oを実ボリュームvb1に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりアクセスエラーは"子イベント"であることがわかる。同様に、イベントID 1002の障害メッセージ及びイベントID 1003の障害メッセージも"子イベント"であることがわかる。
【0086】
ステップ2455で障害メッセージを出力するにあたり、SANマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は"親イベント"と"子イベント"のどちらかを特定する。ここで、「一定時間」とは、あらかじめSAN管理者が指定した時間で、障害の関連付けの単位となる時間である。図17のイベントID 1000、1001、1002、1003は、いずれも実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関連付けられ、かつ、イベントID 1000が"親イベント"であることがわかるので、図23の障害イベント一覧ウィンドウ2020では、例えばイベント関連性欄にシンボル2021のように関連付けを示すことができる。
【0087】
また、例えば、SAN管理者がイベント指定2022のように、ある特定の障害イベントを指定したとき、SANマネージャ10000は、実トポロジ表示ウィンドウ2010中に、実トポロジマッピング表示2011のように指定されたイベントに対応する実トポロジマッピングを図示してもよい。さらに、障害通知ウィンドウ2012のように、指定されたイベントの内容を分かりやすく表示してもよい。
【0088】
以上、SANマネージャは、障害切り分け処理により、SANを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、SAN管理者による障害の切り分け負担を軽減することができる
<SANマネージャのSeverity変換機能を含む障害通報処理>
以下に、SANマネージャによるSeverity変換機能を含む障害通報処理の一例について示す。本処理では、SANマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のSeverity変換機能を保持し、SAN管理者により予め定義された障害Severity変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。
【0089】
図24に、SAN管理サーバ10000上のSANマネージャ13100が実施する、障害切り分け処理のフローチャート2500を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。
【0090】
SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2510)。メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出する(ステップ2515)。
【0091】
抽出したIPアドレスを元に、SANマネージャは、メッセージ発行元の装置が共通Severity定義に関係あるかどうかを調査する(ステップ2520)。具体的には、
はじめに、抽出したIPアドレスが装置検出リスト13500内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するSeverity欄が、障害Severity変換テーブル13800に存在するか調査する。
【0092】
ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係ないと判断した場合は、SANマネージャはSeverity変換機能を行わず、Trapメッセージをそのまま上位管理ソフトに転送する(ステップ2526)。
【0093】
ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係あると判断した場合は、SNMP TrapメッセージのSpecific Trap Typeフィールドからメッセージ発行元装置のSeverityを抽出する(ステップ2525)。メッセージ発行元の装置名と、抽出したSeverityをもとに、障害Severity変換テーブル13800を調査し、共通Severityとアクションを特定する(ステップ2530)。最後に、ステップ2530で特定したアクションを実行する(ステップ2535)。以上でフローチャート2500を終了する。
【0094】
ここで、フローチャート2500で示されたSANマネージャ10000の障害通報処理の具体例について説明する。図17に記載された障害ログのエントリのうち、イベントID 2000のイベントが受信されたときを考える。イベントID 2000の障害メッセージは、ステップ2515でストレージ装置Bが発行元装置であると判断されるので、ステップ2520で共通Severity定義に関係ある場合と判断される。ステップ2525においてTrapメッセージ中のSeverityは"4"であることから、障害Severity変換テーブル13800記載のアクション「ストレージAの情報をTrap送信及びメール送信」を適用し、イベントID 2000の障害メッセージは、上位管理ソフト及びSAN管理者には通報されない。
【0095】
以上、SANマネージャは、Severity変換機能を含む通報処理により、SANマネージャが受信する複数のストレージ装置の障害メッセージに統一的なSeverityを定義し、その定義に応じたSANマネージャの障害通報機能を提供することができる。
【0096】
なお、SANマネージャが実施するストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理、障害切り分け処理、Severity変換機能を含む障害通報処理は、ストレージ装置A 40000がバーチャリゼーション装置であることを想定していたが、ストレージ装置A40000とは異なる装置をバーチャリゼーション装置として管理ネットワーク70000及びSAN60000に接続した構成であっても、上述の処理は同様に実現可能である。
【0097】
以上に説明した実施形態によれば、バーチャリゼーション装置を有するSANにおいて、SANマネージャが実行される装置がSANを構成する複数の装置からの障害メッセージを受信したとき、SANマネージャが、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、SAN管理者による障害の切り分け負担を軽減することができる。
【0098】
また、SANにおいてSANマネージャが受信する複数のストレージ装置の障害メッセージに統一的なSeverityを定義し、その定義に応じた方法でSANマネージャが障害を通報することで、SAN管理者や上位システム管理ソフトが、必要十分な障害情報のみを受信することになり、通報後の障害対策の迅速化が可能となる。
【0099】
【発明の効果】
本発明によれば、SANに接続される装置から障害メッセージが発行された場合に、SAN管理者による障害の切り分けを支援することができる。
【0100】
また、SANにおいて、SAN管理者や上位システム管理ソフトは、SAN内に存在する装置から発行された障害メッセージのうち、必要な障害情報を受信することができる。
【図面の簡単な説明】
【図1】SANの構成例を示す図である。
【図2】SAN管理サーバの構成例を示す図である。
【図3】サーバの構成例を示す図である。
【図4】スイッチの構成例を示す図である。
【図5】仮想化機能を有するストレージ装置の構成例を示す図である。
【図6】ストレージ装置の構成例を示す図である。
【図7】SAN管理サーバが保持する実ボリュームマッピング管理テーブルの例を示す図である。
【図8】SAN管理サーバが保持する仮想ボリュームマッピング管理テーブルの例を示す図である。
【図9】SAN管理サーバが保持する装置検出リストの例を示す図である。
【図10】サーバが保持するデータI/F管理テーブルの例を示す図である。
【図11】サーバが保持するボリューム管理テーブルの例を示す図である。
【図12】スイッチが保持するFC接続管理テーブルの例を示す図である。
【図13】ストレージ装置が保持するデータI/F管理テーブルの例を示す図である。
【図14】ストレージ装置が保持する実ボリューム管理テーブルの例を示す図である。
【図15】ストレージ装置が保持する仮想ボリューム管理テーブルの例を示す図である。
【図16】SAN管理サーバが保持するストレージ装置に関する障害解析辞書テーブルの例を示す図である。
【図17】SAN管理サーバが保持する障害ログの例を示す図である。
【図18】SAN管理サーバが保持する障害Severity変換テーブルの例を示す図である。
【図19】SAN管理サーバが行うストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理の一例を示すフローチャートである。
【図20】SAN管理サーバが行う仮想ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図21】SAN管理サーバが行う実ボリュームマッピング管理テーブル作成ステップの詳細な処理内容の一例を示すフローチャートである。
【図22】SAN管理サーバが行う障害切り分け処理の一例を示すフローチャートである。
【図23】SAN管理サーバが出力する、障害切り分け結果表示の一例を示す図である。
【図24】SAN管理サーバが行うSeverity変換機能を含む障害通報処理の一例を示すフローチャートである。
【図25】SNMP Trapメッセージの構成例を示す図である。
【図26】SANの構成例を示す図である。
【図27】SANの構成例を示す図である。
【符号の説明】
10000:SAN管理サーバ
13100:SANマネージャ
20000:サーバ
30000:スイッチ
40000:ストレージ装置A
50000:ストレージ装置B
23100:サーバの管理エージェント
33100:スイッチの管理エージェント
43100:ストレージ装置Aの管理エージェント
53100:ストレージ装置Bの管理エージェント
47000:ストレージ装置Aの提供する実ボリューム
48000:ストレージ装置Aの提供する仮想ボリューム
57000:ストレージ装置Bの提供する実ボリューム
[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a computer system having a storage system. In particular, the present invention relates to a method and apparatus for managing a storage system failure in a storage area network (hereinafter referred to as SAN) in which a real volume provided from a storage system is provided to a server as a virtual volume. .
[0002]
[Prior art]
(1) About SAN
In recent years, SAN, which is a network dedicated to storage input / output that separates and aggregates storage from each server, is becoming popular. With the introduction of SAN, it has become possible to achieve high-speed data transfer, high scalability and availability of storage systems, and effective use of storage resources.
[0003]
(2) About SAN management
The high scalability of storage systems based on SANs has allowed devices from multiple vendors (servers, switches, storage devices) to be mixed in the SAN. In order to operate such a SAN without interruption, SAN management is required.
[0004]
An overview of SAN management is described in Non-Patent Document 1, for example. Among SAN management, it is particularly important to monitor the operational status of each device connected to the SAN, which is the basis of daily operations. The software for monitoring the operating status of the SAN is hereinafter referred to as the SAN manager.
[0005]
The SAN manager has two major functions: a configuration management function and a fault monitoring function.
[0006]
The configuration management function periodically acquires information from the management agent that exists in each device connected to the SAN, detects the physical connection relationship (topology) of the SAN from the acquired information, and always maintains the latest topology. This is a function that is visualized and provided to SAN manager users, in other words, SAN managers.
[0007]
The fault monitoring function is a fault or performance degradation based on event notifications such as hardware faults or performance degradation issued by each device connected to the SAN, or device information periodically acquired from the management agent that exists in each device. It is a function that grasps the occurrence of such events and notifies the SAN administrator of the events.
[0008]
With these two functions, the SAN manager can centrally manage the operation status of the devices using the SAN manager, so the operating cost can be reduced by reducing the number of SAN managers.
[0009]
(3) Virtualization device
There is a virtual volume technology as a storage management technology in the SAN. The virtual volume technique is disclosed in Patent Document 1. This patent document discloses that a device called a storage server has the following two functions.
[0010]
1) A function for managing a volume (hereinafter referred to as a real volume) that is a storage area in a storage medium of each storage device connected to a storage server and generating a volume pool.
[0011]
2) Create a virtual volume based on one or more real volumes in the volume pool, and convert I / O access to the virtual volume from the server to I / O requests to the real volume sequentially. A function that responds to I / O.
[0012]
The device having these two functions is hereinafter referred to as a virtualization device. By introducing the virtualization device to the SAN, the volume allocation to the server is unified by the virtual volume, and it becomes unnecessary to be aware of the physical arrangement of the storage device connected to the virtualization device. That is, the SAN administrator can perform volume allocation in a centralized manner.
[0013]
[Patent Document 1]
British Patent Application No. 2351375
[Non-Patent Document 1]
Richard Barker, Paul Massiglia, “Storage Area Network Essentials”, John Wiley & Sons, Inc, 2002, p.331- 334
[0014]
[Problems to be solved by the invention]
With the fault monitoring function of the SAN manager, the SAN manager performs the task of identifying which part of which device is the cause of the failure based on events issued from a plurality of devices. This is hereinafter referred to as “failure isolation”. By providing the virtual volume by the virtualization apparatus, the degree of freedom of configuration of the volume provided to the server increases. However, in order to isolate a failure based on a failure message (such as SNMP Trap) issued from a device of multiple vendors connected to the SAN, a manual operation by a SAN administrator with advanced knowledge of each device Relying on the current situation, there is a problem that the management cost is very high.
[0015]
Also, depending on the severity of the failure (hereinafter referred to as “Severity”), the SAN manager notifies the event to the management software that manages and manages the entire business system (hereinafter referred to as “high-level system management software”). It has a failure notification function such as sending e-mail. However, since the definition of failure severity depends on each device connected to the SAN, it is necessary for the SAN administrator to determine which event of which device has a higher severity each time. There is a problem.
[0016]
A first object of the present invention is to assist a SAN administrator in isolating a failure when a failure message is issued from a device connected to the SAN.
[0017]
The second object of the present invention is to enable a SAN administrator or higher system management software to receive necessary failure information among failure messages issued from devices connected to the SAN. That is.
[0018]
[Means for Solving the Problems]
For the first purpose, a management server that receives multiple failure notifications from a device connected to the SAN associates multiple failure notifications based on the correspondence between the real volume and virtual volume managed by the virtualization device. Output.
[0019]
In addition, for the second purpose, the management server that receives a plurality of failure notifications from devices connected to the SAN includes information indicating the importance of failure information based on different criteria included in the failure notification, It converts into the information which shows the importance based on a common reference | standard, and processes a failure notification based on the importance after conversion.
[0020]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below with reference to the drawings. However, this does not limit the present invention.
[0021]
<SAN configuration>
First, a configuration example of a SAN in this embodiment will be described. 1 to 6 show a configuration example of each device connected to the SAN and FIG. 9 to FIG. 18 show management information provided in each device.
[0022]
Fig. 1 shows an example of a SAN configuration. The SAN in the present invention includes one or more servers having a management agent, one or more switches having a management agent, one or more virtualization devices having a management agent, one or more storage devices having a management agent, and a SAN Has one SAN management server with a manager.
[0023]
For convenience of the following description, in the SAN of this embodiment, one server (server A) 20000, one switch (switch A) 30000, and one virtualization device / storage device (storage device A) Assume that 40000 and one storage device (storage device B 50000) are connected to each other via a fiber channel 60000. In this connection mode, the storage device A40000 recognizes the real volume 57000 of the storage device B50000 via the switch 30000 and applies the virtual volume function to the real volume 57000 of the storage device B50000 to the server. Provided as a virtualized volume of device A40000. Note that the connection form of the storage device A40000 and the storage device B50000 is not connected via the switch A30000 as in the example shown in FIG. 1, but for example, as in the second configuration example shown in FIG. With 60000, the storage apparatus A40000 and the storage apparatus B50000 may be directly connected. Further, as in the third configuration example shown in FIG. 27, a path to which the storage apparatus A40000 and the storage apparatus B50000 are directly connected and a path to which both storage apparatuses are connected via a switch may be mixed.
[0024]
The SAN management server 10000 is connected to each server, switch, and storage device via the management network 70000, and the management agent of each device communicates with the SAN manager 13100 in the SAN management server 10000 via the management network. it can. The SAN manager 13100 performs configuration management of the virtual volume and real volume in the SAN, fault isolation in the SAN, and fault notification in the SAN by processing described later.
[0025]
FIG. 2 shows a configuration example of the SAN management server 10000. The SAN management server 10000 is executed by a processor 11000, a memory 13000, a management interface control unit (hereinafter referred to as I / F) 14000 for connecting to the management network 70000, and a SAN manager 13100 to perform processing described later. Output unit 15000 such as a display device that outputs the execution result in the event of a failure, and an input unit 16000 such as a keyboard for the SAN administrator to input instructions to the SAN manager, which are communication paths 17000 such as an internal bus Are connected to each other.
[0026]
The memory 13000 includes a SAN manager 13100, which is a program executed by the SAN management server, a real volume mapping management table 13200 that holds real volume mapping information in the SAN, and a virtual volume mapping management that holds virtual volume mapping information in the SAN. Table 13300, real topology repository 13400, which is an area for storing information collected from the management agents provided in each device in the SAN, and a device that holds a list of devices managed by the SAN manager 13100 in the SAN Detection list 13500, one or more failure analysis dictionaries 13600 for interpreting the contents of failure notification messages received from each device in the SAN, a failure log 13700 for recording event contents, and a severity conversion function described later To perform the Severity conversion definition defined in advance by the SAN administrator. One or more failure severity conversion tables 13800 for holding are stored.
[0027]
FIG. 3 shows a configuration example of the server 20000. The server 20000 has a processor 21000, a memory 23000, a management I / F 24000 for connection to the management network 70000, and one or more data I / F 26000 for connection to the Fiber Channel 60000, which are internal They are connected to each other via a communication path 27000 such as a bus.
[0028]
The memory 23000 includes a management agent 23100 that is a program for communicating with the SAN manager 13100 to send and receive management information of the server, and a data I / F management table 23200 that holds management information of the data I / F of the server And a volume management table 23300 that holds management information of volumes accessed by the server.
[0029]
In this embodiment, the server is one server A and the server A has one data I / F. However, the number of servers and the number of data I / Fs are not limited to one, and there are a plurality of servers in the SAN. Even if connected, one server may be provided with a plurality of data I / Fs. Each server's data I / F is assigned a unique identifier (data I / F ID) within each server. In this embodiment, the value of the data I / F ID of server A is a1. .
[0030]
FIG. 4 shows a configuration example of the switch 30000. The switch 30000 includes a controller 31000 that realizes switching of data transmitted / received via the Fiber Channel 60000, a memory 33000, a management I / F 34000 for connection to the management network 70000, and a connection for the Fiber Channel 60000. The memory 33000, the management I / F 34000, and the data I / F 36000 are connected to each other via the controller 31000.
[0031]
The memory 33000 includes a management agent 33100, which is a program for communicating with the SAN manager 13100 to send and receive management information of the switch A, and a fiber channel 60000 between the switch and each server or each storage device. An FC connection management table 33200, which is information indicating a connection relationship, is stored.
[0032]
In this embodiment, the switch existing in the SAN is one switch A, and the switch A has six data I / Fs. However, the number of switches and the number of data I / Fs are any number. There may be. Each data I / F has a unique identifier (data I / F ID) in the apparatus (in the switch), and in the present embodiment, the values are s1, s2, s3, s4, s5, and s6.
[0033]
FIG. 5 shows a detailed configuration example of the storage apparatus A that is a virtualization apparatus and storage apparatus. The storage device A 40000 includes a controller 41000 for controlling the storage device, a memory 43000, a management I / F 44000 for connection to the management network 70000, and one or more data I for connection to the fiber channel 60000. / F46000 and one or more real volumes 47000 that are storage areas in the disk device for storing data used by the server, and the memory 43000, management I / F 44000, data I / F 46000, and real volume 47000 Are connected to each other via a controller 41000. FIG. 5 shows one or more virtual volumes 48000 in addition to the real volume 47000 as a storage area connected to the controller 41000. This virtual volume 48000 is obtained by virtualizing a real volume held by another storage device (for example, storage device B50000) using the virtual volume function of storage device A. The virtual volume 48000 is provided to the server as a volume of storage device A The storage area is displayed as a component of the storage apparatus A in FIG. 5, but the actual storage area exists in another storage apparatus connected to the storage apparatus A.
[0034]
The memory 43000 includes a management agent 43100 that is a program for communicating with the SAN manager 13100 to send and receive management information of the storage device A, and a data I / F management that holds management information of the data I / F of the storage device A A table 43200, a real volume management table 43300 for holding management information of the real volume 47000 of the storage device A, a virtual volume management program 43400 for realizing the virtual volume function, and the storage device provided to each server A virtual volume management table 43500 that holds management information of virtual volumes that are stored is stored.
[0035]
In this embodiment, the storage device A has two data I / Fs, two real volumes, and two virtual volumes, but the number of data I / Fs, real volumes, and virtual volumes is any number. May be. Each data I / F, each real volume, and each virtual volume has a unique identifier (data I / F ID, real volume ID, virtual volume ID) in the device. In this embodiment, the data I / F ID value is used. Assume that c1, c2, real volume ID values are va1, va2, and virtual volume ID values are vv1, vv2.
[0036]
FIG. 6 shows a detailed configuration example of the storage apparatus B. The storage apparatus B has the same configuration as the storage apparatus A except that it does not have a virtual volume function. Therefore, the virtual volume management program and the virtual volume management table do not exist in the memory 53000. In this embodiment, the storage apparatus B has two data I / Fs and three real volumes, but the number of data I / Fs and real volumes may be any number. In addition, the data I / F ID values of the storage apparatus B are d1, d2, and the volume ID values are vb1, vb2, vb3.
[0037]
FIG. 9 shows an example of a device detection list 13500 held by the SAN management server 10000. In the detection target ID column of FIG. 9, a number arbitrarily assigned in the SAN management server is registered, the type of device in the SAN is registered in the device type column, the vendor of each device, each device in the device information column In the IP address information column, the address on the management network 70000 of each device is registered, and in the virtualization function column, whether each device has a virtualization function is registered, In the virtualization target ID column, an entry in which storage is registered as device information, and when the real volume of the storage device is virtualized by another device, detection of the other device that performs the virtualization process is detected The target ID is registered. These pieces of information are set in advance by the SAN administrator using the output unit 15000 and the input unit 16000 of the SAN management server 10000. Based on this list, the SAN manager 13100 identifies the management agent of each device and communicates with the management agent.
[0038]
FIG. 10 shows an example of the data I / F management table held by the server A 20000. The data I / F ID value of each server is registered in the data I / F ID column of FIG. 10, and the fiber assigned to the data I / F in the Port WWN (World Wide Name) column. The Port WWN, which is a unique identifier within the channel, is registered, and the identifier (SCSI ID number) of the SCSI target device to which the data I / F is connected is registered in the SCSI ID column.
[0039]
FIG. 11 shows an example of a volume management table held by the server A 20000. Server A has been provided with three volumes, and server A holds information on the volumes that it has received in the volume management table. In the LU (Logical Unit) ID column of the volume management table, an identifier arbitrarily assigned to the volume provided by the server A itself is registered. In the Data I / F ID column, the identifier of the data I / F on the server A used for accessing the volume is registered, and in the SCSI ID column, the SCSI of the SCSI target device to which the data I / F is connected is registered. The ID number is registered, the SCSI logical unit number for accessing the volume in the SCSI target device is registered in the LUN column, and the volume for the server that can be acquired by the SCSI INQUIRY command, etc. in the volume information column Vendor name, device name, and identifier of the volume are registered.
[0040]
In the example of FIG. 11, the server A uses the real volume va1 from the storage device A and the virtual volume vv1 that exists in the storage B but is virtualized by the storage device A. The real volume vb3 is provided from the storage device B and used. Note that the real volume vb3 of the storage apparatus B is provided to the server A without being virtualized by the storage apparatus A.
[0041]
FIG. 12 shows an example of the FC connection management table 33300 held by the switch A 30000. The FC connection management table holds information related to the connection destinations s1 to s6, which are the data I / F of the switch A 30000. The data I / F ID value of switch A 30000 is registered in the data I / F ID column of the FC connection management table, and the port WWN of the data I / F is registered in the switch Port WWN column. In the WWN column, the port WWN of the data I / F on the server or storage device to which the data I / F is connected is registered.
[0042]
FIG. 13 shows an example of a data I / F management table held by the storage apparatus. The data I / F management table 43200 is a table that the storage apparatus A has, and the data I / F management table 53200 is a table that the storage apparatus B has. The data I / F identifier value of the storage apparatus is registered in the data I / F ID column of the data I / F management table, and the Port WWN of the data I / F is registered in the Port WWN column.
[0043]
FIG. 14 shows an example of a real volume management table held by the storage apparatus. The real volume management table 23300 is a table that the storage apparatus A has, and the real volume management table 53300 is a table that the storage apparatus B has. The real volume ID value of the storage device is registered in the real volume ID column of the real volume management table, and the presence / absence of the path used when another device accesses the real volume is registered in the path presence / absence column. In the data I / F ID column, the identifier value of the data I / F on the storage device used to access the volume is registered, and the SCSI ID column is assigned to the data I / F. The SCSI ID number is registered, and the SCSI logical unit number for accessing the real volume is registered in the SCSI LUN column. A real volume whose path is registered as “none” in the path presence / absence column in the real volume management table is an unused real volume. Therefore, “N / A” indicating that the values in the data I / F ID column, SCSI ID column, and SCSI LUN column are undefined is registered.
[0044]
FIG. 15 shows an example of the virtual volume management table 43500 held by the storage apparatus A 40000. First, the contents of the virtual volume column will be described. In the virtual volume ID column, an identifier arbitrarily assigned to the virtual volume provided to the server is registered, and in the path presence / absence column, the presence / absence of a path used when another device accesses the virtual volume is registered. Registered, the data I / F ID column registers the identifier value of the data I / F on the storage device used to access the volume, and the SCSI ID column assigns it to the data I / F. The SCSI ID number is registered, and the SCSI logical unit number for accessing the real volume is registered in the LUN column. In this embodiment, the storage apparatus A 40000 provides the virtual volume vv1 from the data I / F c1. The virtual volume vv2 is unused.
[0045]
Next, the contents of the real volume column of the virtual volume management table 43500 will be described. In the real data I / F ID column, the identifier of the data I / F on the storage device A that is used to access the real volume that constitutes the virtual volume indicated by the identifier registered in the virtual volume ID column Is registered. In the SCSI ID column, the SCSI ID number of the SCSI target device to which the actual data I / F is connected is registered. In the LUN column, the volume provided from the storage device is accessed via the actual data I / F. SCSI logical unit number is registered. Registered in the real volume information column is the name of the storage device that provides the real volume that can be obtained via the SCSI INQUIRY command and is accessed via the real data I / F, and the identifier and storage capacity of the real volume. Is done.
[0046]
In the virtual volume management table, only the volume data virtualized by the virtualization apparatus (for example, storage apparatus A) is registered. Therefore, the real volumes vb1 and vb2 that are accessible from the data I / F c2 and exist in the storage device B are recognized by the storage device A, virtualized by the storage device A, and provided to the server as virtual volumes. Registered in the volume management table. Further, since the real volume va1 accessible from the data I / F c1 is provided to the server without being virtualized in the storage apparatus A, information on va1 is not registered in the virtual volume management table 43500. In addition, since the real volume vb3 of the storage apparatus B is directly recognized by the server A via the data I / Fd2, information regarding vb3 is not registered in the virtual volume management table 43500. As described above, the virtualization device that holds the volume virtualization function may not virtualize the real volumes of all the storage devices.
[0047]
FIG. 16 shows an example of a failure analysis dictionary 13600 that the SAN management server 10000 has. (a) is the storage device A, (b) is the storage device B, (c) is the server A, and (d) is the failure analysis dictionary of the switch A. These dictionaries are used for analyzing an SNMP Trap message issued when a failure occurs from each device, and the details will be described later. The fault code column contains the fault code in the Variable Bindings field of the SNMP Trap message, the fault part column contains the fault part corresponding to each fault code, and the identifier field contains the identifier for identifying the fault part. The reason for the message issuance is registered in the column, and the Severity of the Trap in the Specific Trap Type field of the SNMP Trap message is registered in the Severity column.
[0048]
FIG. 17 shows a failure log 13700 that the SAN management server 10000 has. In the failure log, the event ID assigned when the SAN manager receives the failure notification message, the time when the failure occurred, the name of the source device of the failure notification message, the failure code in the failure notification message, the ID of the actual mapping including the relevant part, The relationship between the ID of the virtual mapping that includes the part and other fault events is registered
FIG. 18 shows an example of a failure severity conversion table that the SAN management server 10000 has. This conversion table shows the common Severity for failure messages of multiple devices received by the SAN manager and the operations that the SAN manager performs according to the common severity in the failure notification process including the Severity conversion function of the SAN manager described later. To define. This table is defined by the SAN administrator when building the SAN environment. In the failure severity conversion table, a common severity for failure messages of a plurality of devices, a severity of each device corresponding to the common severity, and an operation executed by the SAN manager according to the common severity are registered. For example, in the case of Figure 18, when Severity of storage device A is "3" and Severity of storage device B is "4", "5", or "6", it is regarded as common Severity "3" in the SAN environment. As a result, the SAN manager sends only the failure message information of the storage device A as an SNMP Trap and sends it to the SAN administrator by e-mail. The Severity conversion table is defined based on SAN configuration information. In the Severity conversion table shown in FIG. 18, for example, Severity 3 of storage A and Severity 4 to 5 of storage B are associated as common Severity 3, and only failure information related to storage A is transmitted as an SNMP Trap for the failure notification message of common Severity 3. And is defined to be emailed to the SAN administrator. This is because the storage A virtualizes the real volume that the storage B has and provides it to the server, and the I / O request sent and received by the storage B is sent and received by the server via the storage A. It is defined that the Severity of A and the Severity of storage B are associated with each other, and only failure information related to storage A virtualizing the real volumes of storage A and storage B is output.
[0049]
<SAN Manager virtual volume mapping and real volume mapping creation processing>
Next, virtual volume mapping and real volume mapping creation processing executed by the SAN manager 13100 on the SAN management server 10000 will be described. This processing is periodically executed by the processor 11000 of the SAN management server 10000 executing a program stored in the memory 13000, and creates the latest virtual volume mapping and real volume mapping in the SAN environment, While outputting it, it uses for the fault isolation process and report process which are mentioned later. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0050]
FIG. 19 shows a flowchart 1700 showing an outline of real topology and virtual topology display processing executed by the SAN manager 13100. The SAN manager 13100 detects a device in the SAN based on the device detection list 13500, communicates with the management agent of each device, and copies the information shown in FIGS. 10 to 15 held by each device (step 1710). ). Next, the SAN manager 13100 stores the copied information in the actual topology repository 13400 (step 1720). Thereafter, a virtual volume mapping management table 13300, which will be described later, is created based on the information stored in step 1720 (step 1730). Further, based on the information in the real topology repository 13400 and the virtual volume mapping management table 13300, a real volume mapping management table 13200 described later is created (step 1740). Finally, based on the contents of the virtual volume mapping management table 13300 and the real volume mapping management table 13200, the result such as the actual topology is output (step 1750), and the process ends.
[0051]
FIG. 20 is a flowchart showing detailed processing of the virtual volume mapping management table creation step 1730 executed by the SAN manager 13100. FIG. 8 shows an example of the virtual volume mapping management table 13300 created by the processing shown in FIG.
[0052]
The SAN manager 13100 executes the following processing for all entries in each volume management table for all volume management tables 23300 received from each server and stored in the real topology repository 13400 (step 1810).
[0053]
First, the SAN manager creates a new entry in the virtual volume mapping management table and registers the newly assigned virtual mapping ID 13301. Further, the SAN manager registers the transmission source server name 13302 of the volume management table 23300 currently being processed, and the data I / F ID 13304 and LU ID 13303 stored in the volume management table (step 1820). Next, the SAN manager investigates the data I / F of the switch to which the registered data I / F 13304 is connected, and registers the switch name 13305 and the data I / F ID 13306. Specifically, the SAN manager first uses the data I / F ID 13304 of the server registered in the virtual volume mapping management table 13300 as a key, and receives the data I / F stored in the actual topology repository 13400 from the server. The management table 23200 is searched to check the Port WWN of the data I / F ID. Furthermore, the SAN manager uses the Port WWN as a key to search the FC connection management table 33200 received from the switch A and stored in the actual topology repository 13400, and the server connects to which data I / F of which switch. And the result is registered as a connection destination switch name 13305 and a connection destination switch data I / F ID 13306 (step 1830). Through the above processing, information about the server is registered in the left half (server field) of the virtual volume mapping management table 13300.
[0054]
Next, the SAN manager performs a process for registering information in the left half (storage column) of the virtual volume mapping management table 13300. The SAN manager checks whether the volume registered in the volume management table is provided by the virtualization device from the vendor name and device name registered as volume information in the volume management table 23300. Specifically, the SAN manager searches the device detection list 13500 using the device name as a key, checks whether or not the device has a virtualization function, and if the device has a virtualization function, is provided by the virtualization device. to decide. (Step 1840). Depending on the result of step 1840, processing branches as follows (step 1850).
[0055]
When the volume is provided from a storage device other than the virtualization device, the SAN manager uses the device name and volume ID registered in the volume information column of the volume management table 23300, and the storage name in the storage column of the virtual volume mapping management table 13300. Registered as 13309 and volume ID 13311. Further, the SAN manager searches the real volume management table received from the storage device using the registered volume ID 13311 as a key, investigates the ID of the data I / F used to access the real volume, and stores the result in the storage Registration is made as a data I / F ID 13310 (step 1860). Then, the SAN manager investigates the data I / F of the switch to which the registered storage data I / F 13310 is connected, and registers the switch name and data I / F ID. Specifically, the SAN manager first searches the data I / F management table received from the storage device using the storage data I / F ID 13310 as a key, checks the port WWN of the storage data I / F, and further determines the WWN. As a key, the FC connection management table 33200 received from the switch A is searched, and it is investigated which data I / F of which switch the storage data I / F is connected to. Then, the SAN manager registers the investigation result as a connection destination switch name 13307 and a connection destination switch data I / F ID 13308 (step 1870).
[0056]
If it is determined in step 1850 that the volume is provided from the virtualization device, the SAN manager performs the following processing. First, the SAN manager registers the device name and volume ID registered in the volume information column of the volume management table 23300 in the virtual volume mapping management table 13300 as the storage name 13309 and volume ID 13311. Further, the SAN manager searches the virtual volume management table 43500 and the real volume management table 43300 received from the virtualization device using the registered volume ID 13311 as a key, and the data I / F of the storage device A used to access the volume. And the result is registered as a storage data I / F ID 13310 (step 1861). Next, the switch data I / F corresponding to the data I / F of the storage apparatus A is examined, and the switch name and data I / F ID are registered. Specifically, the SAN manager searches the data I / F management table 33400 received from the switch A using the storage data I / F ID 13310 as a key, and sets the data I / F ID of the switch corresponding to the data I / F. The investigation is performed, and the result is registered as a connection destination switch name 13307 and a connection destination switch data I / F ID 13308 (step 1871).
[0057]
If the volume management table 23300 is not stored in the actual topology repository 13400 because the device is not registered in the device detection list 13500, and if the device does not have a management I / F, in step 1850 the type of device is exceptionally specified. I can't judge. If there is no information registered in the volume information column of the volume management table 23300, the storage column is left blank (step 1862).
[0058]
When the SAN manager executes the above steps for all entries of all volume management tables received from each server by the SAN management server and stored in the real topology repository 13400, the processing of step 1730 ends.
[0059]
FIG. 21 shows a detailed processing flow of the real volume mapping management table creation step 1740 performed by the SAN manager 13100. FIG. 7 shows an example of an actual volume mapping management table created by the processing shown in FIG.
[0060]
The SAN manager 13100 executes the following processing for all entries in the virtual volume mapping management table 13300 created in step 1730 (step 1910).
[0061]
First, the SAN manager creates a new entry and registers the newly assigned real mapping ID 13201 (step 1920). Next, based on the storage name 13309 of each entry in the virtual volume mapping management table 13300, the SAN manager determines whether the device indicated by the storage name has a virtualization function. Specifically, the device detection list 13500 is searched using the storage name 13309 as a key, and the presence / absence of the virtualization function of the device is checked (step 1930).
[0062]
When having a virtualization function, the SAN manager performs the following steps. The SAN manager searches the virtual volume management table 33500 received from the device indicated by the storage name 13309 using the volume ID 13311 in the virtual volume mapping management table entry as a key, and extracts the entry of the virtual volume ID that matches the volume ID 13311 ( Step 1940). Next, the SAN manager prepares the same number of entries as the number of entries obtained by the search in the real volume management mapping table (step 1950). Then, the SAN manager copies the contents of the server column (13302 to 13306) of the entry currently being processed in the virtual volume mapping management table 13300 to the server column (13202 to 13206) for the prepared entry. The contents of the real data I / F ID in the real volume information column of the entry of the virtual volume management table 33500 extracted in step 1940 are copied into the switch data I / F ID column 13208 in the storage column. Further, the storage name and volume ID registered as the real volume information in the real volume information column of the virtual volume management table 43500 are copied to the storage name entry 13209 and the volume ID entry 13211 in the storage column. In the corresponding virtual mapping ID column 13212, the contents of the virtual mapping ID 13301 in the virtual volume mapping management table 13300 are registered. The contents of the switch name 13307 in the storage column of the virtual volume mapping management table are copied to the switch name column 13207 in the storage column (step 1960). Further, the SAN manager searches the real volume management table received from the storage device using the volume ID registered in the volume ID 13211 of the storage column of the real volume mapping management table 13212 as a key, and the data I / The ID of F is searched and registered in the storage data I / F ID 13210 in the storage column of the virtual volume mapping management table.
[0063]
When it is determined in step 1930 that the virtual machine does not have a virtualization function, the SAN manager changes the currently processed entry (13302 to 13311) in the virtual volume mapping management table 13300 to the entry (13202 in the real volume mapping management table 13200). And the contents of the virtual mapping ID 13301 of the virtual volume mapping management table 13300 are registered in the corresponding virtual mapping ID 13212 of the real volume mapping management table 13200.
[0064]
Through the above processing, entries 13201 to 13212 of the real volume mapping management table 13200 are registered.
[0065]
When the SAN manager has executed the above steps for all entries in the virtual volume mapping management table 13300, the processing shown in step 1740 ends.
[0066]
FIG. 23 shows an example of the actual topology display output from the SAN manager 13100 to the output unit 15000 based on the actual volume mapping table shown in FIG. An output example showing the connection relationship among servers, switches, and storages based on the contents of the real volume mapping management table 13200 is the real topology display 2010.
[0067]
<SAN manager failure isolation process>
An example of fault isolation processing by the SAN manager is shown below.
[0068]
The fault monitoring function by the current SAN management software often uses an SNMP protocol Trap message defined by RFC 1157 “A Simple Network Management Protocol (SNMP)” created by the Internet Engineering Task Force (IETF). However, since the volume allocated to the server by the virtual volume technology is virtualized, it is difficult to identify the fault location at the virtual volume level. Also, SAN administrators rely on manual operations by SAN administrators who have advanced knowledge of individual devices to isolate faults based on events issued from multiple devices. Very expensive.
[0069]
Therefore, in this process, the SAN manager that has received the failure notification issued by multiple devices, based on the failure analysis dictionary and the SAN configuration information obtained from each management agent and stored in the actual topology repository, Analyzes the impact of I / O on I / O access to real and virtual volumes. Further, it analyzes whether there is a failure message related to the failure message among failure messages received during a certain period before receiving the failure message, and examines the relationship between the failure messages. Then, these results are output by the SAN manager, thereby reducing the analysis of multiple failure messages and the failure identification work by the SAN administrator.
[0070]
Before explaining the fault isolation process, Fig. 25 shows the format of the SNMP Trap message received from each device in the SAN by the SAN manager on the SAN management server 10000, and an example of the SNMP Trap message. deep. Here, the SNMP Trap message is a failure notification message transmitted from the management agent of each device in the SAN to the SAN management server 10000. FIG. 25 (a) illustrates the format of the SNMP Trap message. SNMP message, message header, message destination community name, PDU (Protocol Data Unit) Type indicating the message type, Enterprise indicating the vendor name of the source device, Agent Address indicating the destination IP address, It consists of Generic Trap Type indicating the type of Trap message, Specific Trap Type indicating the Severity of Trap message, Timestamp indicating the transmission time of the message, and Variable Bindings fields for storing the message contents. When the value of the PDU Type field is “4”, the message is identified as an SNMP Trap message. When the value of the Generic Trap Type field is "6", the SNMP Trap message is identified as a Trap message based on the definition unique to the transmission source device vendor, and the Severity described in the Specific Trap Type field defined by each vendor It is necessary to interpret the Trap message based on the contents of the fault code described in the Variable Bindings field.
[0071]
FIG. 25 (b) shows an example of an SNMP Trap message transmitted from the storage A 40000 to notify the hardware failure of its own device in this embodiment. The message shown in FIG. 25 (b) is recognized as an SNMP Trap message because the PDU Type is “4”, and the Trap message based on the definition unique to the transmission source vendor because the Generic Trap Type is “6”. It is recognized that Further, it is assumed that the vendor defines that the Specific Trap Type field stores a failure severity, and the Variable Bindings field stores a failure code indicating a failure occurrence site. Therefore, the SNMP Trap message shown in FIG. 25 (b) represents that a failure with a failure code “30c1” has occurred with a severity of “1”.
[0072]
FIG. 22 shows a flowchart 2400 showing an example of a fault isolation process performed by the SAN manager 13100 on the SAN management server 10000. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0073]
The SAN manager 13100 waits until an SNMP Trap message is received from a certain device (step 2410). Upon receipt of the message, the SAN manager extracts the IP address of the device that issued the message from the Agent Address field of the message (step 2415), and the device detection list stored in the actual topology repository 13400 using the extracted IP address as a key. Search for 13500 (step 2420).
[0074]
If the IP address does not exist in the device detection list 13500, the SAN manager cannot analyze the contents of the Trap message because it is a Trap message from an unregistered device. Therefore, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, outputs the IP address as the failed device, outputs the Trap message itself as the failed part (step 2465), and jumps to the processing of step 2455 described later.
[0075]
In step 2420, if the extracted IP address exists in the device detection list 13500 and the device that issued the Trap message can be identified, the SAN manager checks whether the SAN management server 10000 has a failure analysis dictionary for the device. (Step 2425).
[0076]
If a failure analysis dictionary is provided in step 2425, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, extracts the failure occurrence time from the message Timestamp field, and registers it in the time column. Furthermore, the device name is registered. Further, the failure analysis dictionary is searched using the Variable Bindings field of the Trap message as a key. If a failure code is registered, the failure code is registered in the failure code column (step 2430).
[0077]
If it is determined in step 2425 that the failure analysis dictionary is not provided, the SAN manager creates a new entry in the failure log 13700, assigns an event ID, extracts the failure occurrence time from the message Timestamp field, and enters the time column. Register as well as the device name. Further, the SAN manager regards the failure part as the whole device, registers it as “whole device” in the failure code column, and continues the subsequent steps (step 2431).
[0078]
After step 2430 or step 2431 is completed, the SAN manager investigates whether or not the failure part indicated by the registered failure code is related to real volume mapping and virtual volume mapping (step 2435). Specifically, first, the failure part and its identifier are searched for the entry of the failure analysis dictionary of the registered failure device name using the failure code as a key. Next, a search is made for a matching entry in the real volume mapping management table 13200 using the faulty device name and the faulty part or faulty part identifier obtained previously as keys. If there is a matching entry, the SAN manager extracts the real mapping ID 13201 and virtual mapping ID 13212 from the entry, and registers them in the real volume column and virtual volume column of the entry being created in the failure log 13700.
[0079]
Thereafter, the SAN manager investigates whether the identified failure part is related to virtual volume management (step 2440). Specifically, the virtual volume management table 43500 is searched for a matching entry by using the faulty device name searched in step 2435 and the faulty part or faulty part identifier as keys. If there is a matching entry, the SAN manager extracts the virtual volume ID from the entry. Further, using the extracted virtual volume ID as a key, a search is made for a matching entry in the real volume mapping management table 13200, the real mapping ID 13201 and the virtual mapping ID 13212 are extracted, the real volume column of the entry being created in the fault log 13700, the virtual Register in the volume column.
[0080]
In step 2435 and step 2440, after registering the relationship between the real volume mapping and virtual volume mapping of the failure log creation entry, the SAN manager investigates the relationship between the creation entry and another failure log entry. First, the SAN manager investigates whether the entry being created is due to a hardware failure or an access error to another part (step 2445). Specifically, the cause of the failure analysis dictionary entry of the registered failure device name is searched for using the failure code as a key.
[0081]
If the cause investigated in step 2445 is a hardware failure, it is determined that the event being created is a “parent event” that may trigger another failure event, and “parent event” is displayed in the event relation column. Register (step 2450). If the cause investigated in step 2445 is due to an access error to another part, it is determined that the event being created is a “child event” that may have been issued due to another failure event. Then, “child event” is registered in the event relation column (step 2451).
[0082]
Finally, the SAN manager outputs the contents of the created failure log entry as a failure message (step 2455). Thus, the flowchart 2400 is completed.
[0083]
Here, a specific example of the fault isolation process of the SAN manager 10000 shown in the flowchart 2400 will be described. FIG. 23 is a diagram illustrating an example of how the failure log entry illustrated in FIG. 17 is output by the failure isolation process illustrated in the flowchart 2400. Here, event IDs 1000, 1001, 1002, and 1003 are four failure messages generated by a hardware failure in the data I / F ID d1 of the storage apparatus B. Thus, the following describes how the four failure messages are analyzed and related.
[0084]
When the failure message of event ID 1000 is received, the SAN manager analyzes a hardware failure of the data I / F ID d1 of the storage apparatus B in step 2430. Further, in step 2435, it can be seen that the actual volume mapping pm2 and the virtual volume mapping vm2 are related. Further, step 2445 reveals that the hardware failure is a “parent event”.
[0085]
Next, when the failure message of event ID 1001 is received, the SAN manager analyzes that an access error has occurred when expanding the I / O of the virtual volume vv1 of the storage device A to the real volume vb1 in step 2430. Further, in step 2435, it can be seen that the actual volume mapping pm2 and the virtual volume mapping vm2 are related. Further, step 2445 reveals that the access error is a “child event”. Similarly, it can be seen that the failure message with event ID 1002 and the failure message with event ID 1003 are also “child events”.
[0086]
When outputting a failure message in step 2455, the SAN manager investigates the real volume column, virtual volume column, and event relationship column of the failure message issued within a certain period of time, and whether there is a relationship between each failure message or not. In this case, specify either "parent event" or "child event". Here, the “certain time” is a time specified in advance by the SAN administrator and serving as a unit of fault association. The event IDs 1000, 1001, 1002, and 1003 in FIG. 17 are all associated with the real volume mapping pm2 and the virtual volume mapping vm2, and the event ID 1000 is a “parent event”. In the event list window 2020, for example, the association can be shown in the event relevance column like a symbol 2021.
[0087]
For example, when the SAN administrator designates a specific failure event such as event designation 2022, the SAN manager 10000 displays an event designated as real topology mapping display 2011 in the real topology display window 2010. The actual topology mapping corresponding to may be illustrated. Further, the content of the designated event may be displayed in an easy-to-understand manner as in the failure notification window 2012.
[0088]
As described above, when a SAN manager receives fault messages from multiple devices that make up the SAN through fault isolation processing, the SAN manager automates the analysis of the fault messages and the association with other fault messages. Can reduce the burden of carving
<Failure report processing including Severity conversion function of SAN manager>
An example of failure notification processing including the severity conversion function by the SAN manager is shown below. In this process, the SAN manager holds the Severity conversion function of multiple storage devices connected to the virtualization device. When a failure message is received according to the failure severity conversion table definition predefined by the SAN administrator, the conversion is performed. In accordance with the common severity defined in the table, reports to the upper management program and reports to the administrator are implemented.
[0089]
FIG. 24 shows a flowchart 2500 of failure isolation processing performed by the SAN manager 13100 on the SAN management server 10000. Hereinafter, unless otherwise specified, each step is performed by the SAN manager 13100.
[0090]
The SAN manager 13100 waits until an SNMP Trap message is received from a certain device (step 2510). When receiving the message, the SAN manager extracts the IP address of the device that issued the message from the Agent Address field of the message (step 2515).
[0091]
Based on the extracted IP address, the SAN manager investigates whether the message issuing device is related to the common severity definition (step 2520). In particular,
First, by checking whether or not the extracted IP address exists in the device detection list 13500, the device that issued the message is specified. Next, it is investigated whether or not the Severity column relating to the identified device exists in the failure severity conversion table 13800.
[0092]
If it is determined in step 2520 that the message issuing device is not related to the common severity definition, the SAN manager does not perform the severity conversion function and transfers the trap message as it is to the upper management software (step 2526).
[0093]
If it is determined in step 2520 that the message issuer device is related to the common severity definition, the message issuer device severity is extracted from the specific trap type field of the SNMP Trap message (step 2525). Based on the device name of the message issuer and the extracted Severity, the failure severity conversion table 13800 is examined to identify the common severity and action (step 2530). Finally, the action specified in step 2530 is executed (step 2535). Thus, the flowchart 2500 is completed.
[0094]
Here, a specific example of the failure notification process of the SAN manager 10000 shown in the flowchart 2500 will be described. Consider a case where an event with event ID 2000 is received among the entries in the failure log shown in FIG. The failure message of event ID 2000 is determined in step 2515 that the storage apparatus B is the issuing source apparatus, and is therefore determined in step 2520 as being related to the common severity definition. Since the Severity in the Trap message is “4” in Step 2525, the action “Trap transmission and email transmission of storage A information” described in the failure Severity conversion table 13800 is applied. Not reported to management software and SAN administrator.
[0095]
As described above, the SAN manager defines unified Severity in the failure messages of multiple storage devices received by the SAN manager through notification processing including the severity conversion function, and provides the failure notification function of the SAN manager according to the definition. be able to.
[0096]
Note that the storage manager's actual topology mapping and virtual topology mapping creation processing, failure isolation processing, and failure notification processing including Severity conversion function assumed that the storage device A 40000 is a virtualization device. Even in a configuration in which a device different from the storage device A40000 is connected to the management network 70000 and the SAN 60000 as a virtualization device, the above-described processing can be similarly realized.
[0097]
According to the embodiment described above, when a device in which the SAN manager is executed receives a failure message from a plurality of devices constituting the SAN in the SAN having the virtualization device, the SAN manager analyzes the failure message. And automating the association with other failure messages, reducing the burden of SAN administrators on fault isolation.
[0098]
In addition, by defining a unified Severity in the failure messages of multiple storage devices received by the SAN manager in the SAN, the SAN manager and higher system management software can report the failure using a method according to the definition. However, only necessary and sufficient failure information is received, and it becomes possible to speed up failure countermeasures after reporting.
[0099]
【The invention's effect】
According to the present invention, when a failure message is issued from a device connected to the SAN, it is possible to support the failure identification by the SAN administrator.
[0100]
Further, in the SAN, the SAN administrator and the upper system management software can receive necessary failure information among failure messages issued from devices existing in the SAN.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a configuration example of a SAN.
FIG. 2 is a diagram illustrating a configuration example of a SAN management server.
FIG. 3 is a diagram illustrating a configuration example of a server.
FIG. 4 is a diagram illustrating a configuration example of a switch.
FIG. 5 is a diagram illustrating a configuration example of a storage apparatus having a virtualization function.
FIG. 6 is a diagram illustrating a configuration example of a storage apparatus.
FIG. 7 is a diagram showing an example of an actual volume mapping management table held by a SAN management server.
FIG. 8 is a diagram showing an example of a virtual volume mapping management table held by a SAN management server.
FIG. 9 is a diagram illustrating an example of a device detection list held by a SAN management server.
FIG. 10 is a diagram illustrating an example of a data I / F management table held by a server.
FIG. 11 is a diagram showing an example of a volume management table held by a server.
FIG. 12 is a diagram illustrating an example of an FC connection management table held by a switch.
FIG. 13 is a diagram showing an example of a data I / F management table held by the storage apparatus.
FIG. 14 is a diagram showing an example of a real volume management table held by the storage apparatus.
FIG. 15 is a diagram showing an example of a virtual volume management table held by the storage apparatus.
FIG. 16 is a diagram showing an example of a failure analysis dictionary table related to storage devices held by the SAN management server.
FIG. 17 is a diagram illustrating an example of a failure log held by a SAN management server.
FIG. 18 is a diagram showing an example of a failure severity conversion table held by the SAN management server.
FIG. 19 is a flowchart illustrating an example of storage network real topology mapping and virtual topology mapping creation processing performed by the SAN management server;
FIG. 20 is a flowchart illustrating an example of detailed processing contents of a virtual volume mapping management table creation step performed by the SAN management server.
FIG. 21 is a flowchart showing an example of detailed processing contents of a real volume mapping management table creation step performed by the SAN management server.
FIG. 22 is a flowchart illustrating an example of failure isolation processing performed by a SAN management server.
FIG. 23 is a diagram illustrating an example of a fault isolation result display output by the SAN management server.
FIG. 24 is a flowchart illustrating an example of a failure notification process including a severity conversion function performed by the SAN management server.
FIG. 25 is a diagram illustrating a configuration example of an SNMP Trap message.
FIG. 26 is a diagram illustrating a configuration example of a SAN.
FIG. 27 is a diagram illustrating a configuration example of a SAN.
[Explanation of symbols]
10000: SAN management server
13100: SAN manager
20000: Server
30000: Switch
40000: Storage device A
50000: Storage device B
23100: Server management agent
33100: Switch management agent
43100: Management agent for storage device A
53100: Management agent for storage device B
47000: Real volume provided by storage device A
48000: Virtual volume provided by storage device A
57000: Real volume provided by storage device B

Claims (16)

各々実ボリュームを有する一又は複数の記憶装置と、
第1のネットワークを介して前記一又は複数の記憶装置と接続され、前記一又は複数の記憶装置の実ボリュームを仮想ボリュームとして構成し、上位装置に提供するバーチャリゼーション装置と、
前記一又は複数の記憶装置及び前記バーチャリゼーション装置と第2のネットワークを介して接続される管理サーバとを有するシステムにおける、障害情報管理方法であって、
前記一又は複数の記憶装置が複数の実ボリュームについての障害を検知する第1の障害検知ステップと
前記バーチャリゼーション装置が複数の仮想ボリュームについての障害を検知する第2の障害検知ステップと、
前記管理サーバが、前記第1の障害検知ステップにより検知される前記複数の実ボリュームについての障害通知、又は前記第2の障害検知ステップにより検知される前記複数の仮想ボリュームについての障害通知を受信する障害通知受信ステップと、
前記バーチャリゼーション装置が管理する前記仮想ボリュームがいずれの前記実ボリュームから構成されるかの対応情報を示すボリューム管理テーブルに基づいて、前記管理サーバが、障害が通知された前記複数の実ボリューム各々について対応する仮想ボリュームを特定し、特定した仮想ボリュームについての障害通知を受信している場合、前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知とを関連付け関連付けステップと、
前記仮想ボリュームについての障害通知、前記実ボリュームについての障害通知、及び前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知とが関連付けられることを示す情報を出力する障害通知出力ステップとを有することを特徴とする障害情報管理方法。
One or more storage devices each having a real volume;
A virtualization device is connected to the one or more storage devices via a first network, which constitutes the real volume of the one or more storage devices as a virtual volume is provided to the host device,
A failure information management method in a system having a management server connected to the one or more storage devices and the virtualization device via a second network,
A first failure detection step in which the one or more storage devices detect failures for a plurality of real volumes;
A second failure detection step in which the virtualization device detects failures for a plurality of virtual volumes ;
The management server receives a failure notification for the plurality of real volumes detected by the first failure detection step or a failure notification for the plurality of virtual volumes detected by the second failure detection step. A fault notification receiving step;
Based on a volume management table indicating correspondence information indicating which real volume the virtual volume managed by the virtualization device is configured to , the management server handles each of the plurality of real volumes notified of the failure. to identify the virtual volume, when receiving the failure notification for a particular virtual volume, the steps associated with a failure notification for said virtual volume the to associate a failure notification for real volume,
A failure notification for the virtual volume, a failure notification for the real volume, and a failure notification output step for outputting information indicating that the failure notification for the virtual volume is associated with the failure notification for the real volume. Fault information management method characterized by the above.
請求項1記載の障害情報管理方法において、
前記関連付けステップにおいて、一定期間内に前記管理サーバが受信した複数の障害通知の中から、障害が通知された前記複数の実ボリュームについての障害通知と、前記複数の実ボリューム各々について対応する仮想ボリュームについての障害通知とを関連する障害通知として関連付けることを特徴とする障害情報管理方法。
The failure information management method according to claim 1,
In the association step , out of a plurality of failure notifications received by the management server within a predetermined period, a failure notification for the plurality of real volumes notified of the failure, and a virtual volume corresponding to each of the plurality of real volumes A failure information management method comprising: associating a failure notification with respect to a failure notification as a related failure notification .
請求項1記載の障害情報管理方法において、
更に、前記管理サーバが、前記第1のネットワークに接続される装置から該第1のネットワークの構成情報を受信するステップと、
前記管理サーバが、前記構成情報に基づいて、前記実ボリュームの識別情報と前記仮想ボリュームの識別情報との対応関係を特定するステップとを有することを特徴とする障害情報管理方法。
The failure information management method according to claim 1,
Further, the management server, receiving configuration information of the first network from the device connected to the first network,
A failure information management method comprising: a step of specifying a correspondence relationship between the identification information of the real volume and the identification information of the virtual volume based on the configuration information.
請求項1記載の障害情報管理方法において、
前記関連付けステップは、更に、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知について、各々の障害通知についての障害の原因を前記ボリューム管理テーブルに基づいて特定する障害要因特定ステップを有し、
前記障害通知出力ステップにおいて前記仮想ボリュームについての障害通知、前記実ボリュームについての障害通知とともに、前記障害要因特定ステップにより特定された前記原因を出力することを特徴とする障害情報管理方法。
The failure information management method according to claim 1,
The associating step further includes a failure factor specifying step of specifying a cause of failure for each failure notification for the failure notification for the associated virtual volume and the failure notification for the real volume based on the volume management table. Have
In the failure notification output step , the failure information about the virtual volume and the failure notification for the real volume are output together with the cause specified in the failure factor specifying step .
請求項4記載の障害情報管理方法において、
前記障害要因特定ステップにおいて、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知のうち、前記実ボリュームについての障害通知の障害原因に起因して、前記実ボリュームに対応する仮想ボリュームについての障害が発生したことを示す障害通知が発行されることを特定することを特徴とする障害情報管理方法。
The failure information management method according to claim 4,
Corresponding to the real volume due to the cause of failure in the failure notification for the real volume among the failure notification for the associated virtual volume and the failure notification for the real volume in the failure factor specifying step A failure information management method characterized by specifying that a failure notification indicating that a failure has occurred in a virtual volume is issued.
請求項4記載の障害情報管理方法において、
前記障害要因特定ステップにおいて、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知のうち、ハードウェアの故障によって通知される実ボリュームまたは仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される実ボリュームまたは仮想ボリュームについての障害通知とを特定することを特徴とする障害情報管理方法。
The failure information management method according to claim 4,
Of the failure notification for the associated virtual volume and the failure notification for the real volume in the failure factor identification step , the failure notification for the real volume or virtual volume notified by a hardware failure, and the hardware A failure information management method characterized by identifying a failure notification for a real volume or a virtual volume notified by an access error caused by an influence of a failure.
請求項1記載の障害情報管理方法において、
更に、前記一又は複数の記憶装置及び前記バーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害通知の重要度を表す複数の重要度情報を、前記一又は複数の記憶装置及び前記バーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に前記管理サーバが変換するステップを有し、
前記障害通知出力ステップにおいて、変換後の重要度情報に基づいて、予め定められた方法で、前記管理サーバが障害通知出力することを特徴とする障害情報管理方法。
The failure information management method according to claim 1,
Further, a plurality of pieces of importance information representing importance of failure notifications based on different criteria included in the plurality of failure notifications received from the one or more storage devices and the virtualization device are stored in the one or more storage devices. And the management server converts to importance information based on common criteria in a system including the virtualization device ,
A failure information management method, wherein in the failure notification output step, the management server outputs a failure notification by a predetermined method based on the importance information after conversion.
請求項1記載の障害情報管理方法において、
前記システムは、更に、前記一又は複数の記憶装置、前記バーチャリゼーション装置、および前記管理サーバを相互に接続するスイッチを有し、
前記障害検知ステップは、前記スイッチの障害を検知するステップを有し、
前記障害通知受信ステップにおいて、更に、前記管理サーバが前記スイッチから障害通知を受信し、
前記関連付けステップにおいて、更に、前記バーチャリゼーション装置内の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記一又は複数の記憶装置内の実ボリュームについての障害通知と、前記スイッチからの障害通知が関連するかを判断し、ある実ボリュームについての障害通知の障害を原因として、前記実ボリュームに対応する仮想ボリュームについての障害通知及び前記スイッチからの障害通知が発行されることを特定し、
前記障害通知出力ステップにおいて、更に、前記実ボリュームについての障害通知を第1の障害通知とし、前記仮想ボリュームについての障害通知及び前記スイッチについての障害通知を第2の障害通知として、前記第2の障害通知が前記第1の障害通知と関連付けられることを示す情報を出力することを特徴とする障害情報管理方法。
The failure information management method according to claim 1,
The system further includes a switch for interconnecting the one or more storage devices, the virtualization device, and the management server,
The failure detection step includes a step of detecting a failure of the switch,
In the failure notification receiving step , the management server further receives a failure notification from the switch ,
In the association step , a failure notification for the virtual volume in the virtualization device, a failure notification for the real volume in the one or more storage devices connected via the switch, and a failure from the switch Determining whether the notification is relevant, specifying that a failure notification for a virtual volume corresponding to the real volume and a failure notification from the switch are issued due to a failure in the failure notification for a certain real volume ,
In the failure notification output step , the failure notification for the real volume is a first failure notification, the failure notification for the virtual volume and the failure notification for the switch are a second failure notification , fault information management method, wherein a failure notification outputs information indicating that associated with the first fault notification.
各々実ボリュームを有する一又は複数の記憶装置と、第1のネットワークを介して前記一又は複数の記憶装置と接続され、前記一又は複数の記憶装置の実ボリュームを仮想ボリュームとして構成し、上位装置に提供するバーチャリゼーション装置とに、第2のネットワークを介して接続される管理サーバであって、
前記第2のネットワークに接続するためのインタフェース制御部と、
プロセッサと、
前記プロセッサが実行するプログラム及び前記プロセッサが使用する情報が格納されているメモリと、
前記プロセッサによって実行される処理の処理結果を出力する出力部とを有し、
前記インタフェース制御部は、前記一又は複数の記憶装置から複数の実ボリュームについての障害通知を受信し、前記バーチャリゼーション装置から複数の仮想ボリュームについての障害通知を受信し、
前記プロセッサは、前記バーチャリゼーション装置が管理する前記仮想ボリュームがいずれの前記実ボリュームから構成されるかの対応情報を示すボリューム管理テーブルに基づいて、障害が通知された前記複数の実ボリューム各々について対応する仮想ボリュームを特定し、特定した仮想ボリュームについての障害通知を受信している場合、前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知とを関連付け、
前記出力部は、前記プロセッサが前記仮想ボリュームについての障害通知、前記実ボリュームについての障害通知、及び前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知とが関連付けられることを示す情報を出力することを特徴とする管理サーバ。
One or more storage devices each having a real volume and the one or more storage devices connected via a first network, and configuring the real volume of the one or more storage devices as a virtual volume, A management server connected via a second network to the virtualization device provided to
An interface controller for connecting to the second network;
A processor;
A memory storing a program executed by the processor and information used by the processor;
An output unit for outputting a processing result of processing executed by the processor;
The interface control unit receives a failure notification for a plurality of real volumes from the one or a plurality of storage devices, receives a failure notification for a plurality of virtual volumes from the virtualization device,
The processor responds to each of the plurality of real volumes notified of a failure based on a volume management table indicating correspondence information indicating which of the real volumes the virtual volume managed by the virtualization apparatus is configured with. When the virtual volume is specified and the failure notification for the specified virtual volume is received, the failure notification for the virtual volume is associated with the failure notification for the real volume,
The output unit outputs information indicating that the processor is associated with a failure notification for the virtual volume, a failure notification for the real volume, and a failure notification for the virtual volume and a failure notification for the real volume. A management server characterized by:
請求項9記載の管理サーバにおいて、
前記プロセッサは、一定期間内に前記インタフェース制御部が受信した複数の障害通知の中から、障害が通知された前記複数の実ボリュームについての障害通知と、前記複数の実ボリューム各々について対応する仮想ボリュームについての障害通知とを関連する障害通知として関連付けることを特徴とする管理サーバ。
The management server according to claim 9,
The processor includes a failure notification for the plurality of real volumes notified of the failure from a plurality of failure notifications received by the interface control unit within a predetermined period, and a virtual volume corresponding to each of the plurality of real volumes. A management server characterized by associating a failure notification with respect to a failure notification as related.
請求項9記載の管理サーバにおいて、
前記インタフェース制御部は、前記第1のネットワークに接続される装置から該第1のネットワークの構成情報を受信し、
前記プロセッサは、前記構成情報に基づいて、前記実ボリュームの識別情報と前記仮想ボリュームの識別情報との対応関係を特定することを特徴とする管理サーバ。
The management server according to claim 9,
The interface control unit receives configuration information of the first network from the device connected to the first network,
The management server, wherein the processor specifies a correspondence relationship between the identification information of the real volume and the identification information of the virtual volume based on the configuration information.
請求項9記載の管理サーバにおいて、
前記プロセッサは、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知について、各々の障害通知についての障害の原因を前記ボリューム管理テーブルに基づいて特定し、
前記出力部は、前記仮想ボリュームについての障害通知、前記実ボリュームについての障害通知とともに、特定された前記原因を出力することを特徴とする管理サーバ。
The management server according to claim 9,
The processor specifies the cause of failure for each failure notification for the failure notification for the associated virtual volume and the failure notification for the real volume based on the volume management table,
The output unit outputs the specified cause together with a failure notification for the virtual volume and a failure notification for the real volume .
請求項12記載の管理サーバにおいて、
前記プロセッサは、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知のうち、前記実ボリュームについての障害通知の障害原因に起因して、前記実ボリュームに対応する仮想ボリュームについての障害が発生したことを示す障害通知が発行されることを特定することを特徴とする管理サーバ。
In the management server according to claim 12,
The processor of the failure notification for failure notification for associated said virtual volume and the real volume, due to the cause of the failure notification failure for the real volume, the virtual volume corresponding to the real volume A management server that specifies that a failure notification indicating that a failure has occurred is issued.
請求項12記載の管理サーバにおいて、
前記プロセッサは、関連付けられた前記仮想ボリュームについての障害通知と前記実ボリュームについての障害通知のうち、ハードウェアの故障によって通知される実ボリュームまたは仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される実ボリュームまたは仮想ボリュームについての障害通知とを特定することを特徴とする管理サーバ。
In the management server according to claim 12,
The processor includes a failure notification for a real volume or a virtual volume notified by a hardware failure, and a failure notification for the hardware failure among a failure notification for the associated virtual volume and a failure notification for the real volume. A management server that identifies a failure notification for a real volume or a virtual volume that is notified by an access error caused by the influence.
請求項9記載の管理サーバにおいて、
前記プロセッサは更に、前記一又は複数の記憶装置及び前記バーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害通知の重要度を表す複数の重要度情報を、前記一又は複数の記憶装置及び前記バーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に変換し、
前記出力部は、変換後の重要度情報に基づいて、予め定められた方法で障害通知を出力することを特徴とする管理サーバ。
The management server according to claim 9,
The processor further includes a plurality of pieces of importance information representing importance of failure notifications based on different criteria included in the plurality of failure notifications received from the one or more storage devices and the virtualization device. Conversion into importance information based on common criteria in the system including the storage device and the virtualization device,
The output server outputs a failure notification by a predetermined method based on the importance information after conversion.
請求項9記載の管理サーバにおいて、
前記管理サーバは、前記一又は複数の記憶装置および前記バーチャリゼーション装置とスイッチを介して相互に接続され、
前記インタフェース制御部は、前記スイッチから障害通知を受信し、
前記プロセッサは、前記バーチャリゼーション装置内の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記一又は複数の記憶装置内の実ボリュームについての障害通知と、前記スイッチからの障害通知が関連するかを判断し、
ある実ボリュームについての障害通知の障害を原因として、前記実ボリュームに対応する仮想ボリュームについての障害通知及び前記スイッチからの障害通知が発行されることを特定し、
前記出力部は、前記実ボリュームについての障害通知を第1の障害通知とし、前記仮想ボリュームについての障害通知及び前記スイッチについての障害通知を第2の障害通知として、前記第2の障害通知が前記第1の障害通知と関連付けられることを示す情報を出力することを特徴とする管理サーバ。
The management server according to claim 9,
The management server is connected to the one or more storage devices and the virtualization device via a switch,
The interface control unit receives a failure notification from the switch,
The processor relates to a failure notification for a virtual volume in the virtualization device, a failure notification for a real volume in the one or more storage devices connected via the switch, and a failure notification from the switch. To decide,
Specifying that a failure notification for a virtual volume corresponding to the real volume and a failure notification from the switch are issued due to a failure in a failure notification for a real volume,
The output unit uses the failure notification for the real volume as a first failure notification, the failure notification for the virtual volume and the failure notification for the switch as a second failure notification, and the second failure notification is A management server that outputs information indicating that it is associated with the first failure notification.
JP2003189954A 2002-10-07 2003-07-02 Fault information management method and management server in a network having a storage device Expired - Fee Related JP4130615B2 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2003189954A JP4130615B2 (en) 2003-07-02 2003-07-02 Fault information management method and management server in a network having a storage device
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 (en) 2003-07-02 2003-07-02 Fault information management method and management server in a network having a storage device

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2008027598A Division JP4575462B2 (en) 2008-02-07 2008-02-07 Fault information management method and management server in a network having a storage device

Publications (2)

Publication Number Publication Date
JP2005025483A JP2005025483A (en) 2005-01-27
JP4130615B2 true JP4130615B2 (en) 2008-08-06

Family

ID=33432316

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003189954A Expired - Fee Related JP4130615B2 (en) 2002-10-07 2003-07-02 Fault information management method and management server in a network having a storage device

Country Status (3)

Country Link
US (1) US7076688B2 (en)
EP (1) EP1494118A3 (en)
JP (1) JP4130615B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012164616A1 (en) 2011-05-31 2012-12-06 Hitachi, Ltd. Computer system and its event notification method

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10163282B4 (en) * 2001-12-21 2005-06-09 Visteon Global Technologies, Inc., Dearborn Rack and pinion, in particular rack and pinion steering gear and method for its preparation
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 (en) * 2004-01-23 2010-09-29 株式会社日立製作所 Management computer and storage device management method
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
US7359831B2 (en) * 2004-05-21 2008-04-15 Bea Systems, Inc. Diagnostic context
US7379849B2 (en) * 2004-05-21 2008-05-27 Bea Systems, Inc. Diagnostic image
US7395458B2 (en) * 2004-05-21 2008-07-01 Bea Systems, Inc. Diagnostic instrumentation
US8490064B2 (en) * 2004-05-21 2013-07-16 Oracle International Corporation Hierarchical debug
US7376534B2 (en) * 2004-05-21 2008-05-20 Bea Systems, Inc. Watches and notifications
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
US7567974B2 (en) 2004-09-09 2009-07-28 Microsoft Corporation Method, system, and apparatus for configuring 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
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
JP2006228078A (en) * 2005-02-21 2006-08-31 Hitachi Ltd Method for managing access between a plurality of devices constituted of hierarchical relation and management computer or computer system
JP4652090B2 (en) * 2005-03-15 2011-03-16 富士通株式会社 Event notification management program, event notification management apparatus, and event notification management method
JP4588500B2 (en) * 2005-03-16 2010-12-01 株式会社日立製作所 Storage session management system in storage area network
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 (en) * 2005-07-07 2007-01-25 Hitachi Ltd Storage system, adapter device, information processor, and its control method
EP1903441B1 (en) * 2005-07-14 2016-03-23 Fujitsu Ltd. Message analyzing device, message analyzing method and message analyzing program
JP4698316B2 (en) * 2005-07-15 2011-06-08 株式会社日立製作所 Access path management method and program
US8234378B2 (en) 2005-10-20 2012-07-31 Microsoft Corporation Load balancing in a managed execution environment
US7926071B2 (en) * 2005-10-20 2011-04-12 Microsoft Corporation Load balancing interfaces
JP2007128437A (en) * 2005-11-07 2007-05-24 Hitachi Ltd Disk array device and path fault detection method thereof
JP4736783B2 (en) * 2005-12-19 2011-07-27 株式会社日立製作所 Volume and failure management method in a network having a storage device
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
US8032621B1 (en) * 2006-01-03 2011-10-04 Emc Corporation Methods and apparatus providing root cause analysis on alerts
US8185639B2 (en) * 2006-01-03 2012-05-22 Emc Corporation Server identification in storage networks
JP4920391B2 (en) * 2006-01-06 2012-04-18 株式会社日立製作所 Computer system management method, management server, computer system and program
JP4818768B2 (en) * 2006-03-24 2011-11-16 富士通株式会社 Information processing system, failure notification method, and failure notification program
JP5068023B2 (en) * 2006-03-29 2012-11-07 株式会社日立製作所 Computer system and logical path switching method
US7676694B2 (en) * 2006-03-31 2010-03-09 Emc Corporation Managing system components
JP4939102B2 (en) * 2006-04-21 2012-05-23 株式会社日立製作所 Reliable method for network boot computer system
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
US20080140724A1 (en) 2006-12-06 2008-06-12 David Flynn Apparatus, system, and method for servicing object requests within a storage controller
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 (en) * 2007-04-26 2009-07-10 Aleksander Baczko A DEVICE ENHANCING THE AVAILABILITY OF TECHNICAL SYSTEMS
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 (en) * 2007-12-05 2010-06-16 富士通株式会社 Storage management device, storage system control device, storage management program, data storage system, and data storage method
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 (en) * 2008-03-26 2009-10-15 Hitachi Ltd Storage system and volume management method therefor
US9501305B2 (en) * 2008-04-23 2016-11-22 Inernational Business Machines Corporation System for virtualisation monitoring
JP5140633B2 (en) * 2008-09-04 2013-02-06 株式会社日立製作所 Method for analyzing failure occurring in virtual environment, management server, and program
JP5468067B2 (en) * 2009-04-23 2014-04-09 株式会社日立製作所 A computer that identifies the cause of an event in a computer system that includes multiple node devices
US8255525B2 (en) * 2009-08-19 2012-08-28 International Business Machines Corporation System and method for circuit and path based event correlation
US8381033B2 (en) * 2009-10-30 2013-02-19 International Business Machines Corporation Fault management in virtual computing environments
US8086896B2 (en) * 2009-12-28 2011-12-27 International Business Machines Corporation Dynamically tracking virtual logical storage units
JP5696470B2 (en) * 2010-03-18 2015-04-08 株式会社リコー DEVICE MANAGEMENT DEVICE, DEVICE MANAGEMENT METHOD, DEVICE MANAGEMENT PROGRAM, AND RECORDING MEDIUM CONTAINING THE PROGRAM
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 (en) * 2011-02-02 2014-12-10 株式会社日立製作所 Computer system and control method thereof
JP5652333B2 (en) 2011-05-31 2015-01-14 富士通株式会社 Storage device, storage system, and storage device control method
US8782525B2 (en) * 2011-07-28 2014-07-15 National Insturments Corporation Displaying physical signal routing in a diagram of a system
JP5747765B2 (en) * 2011-09-27 2015-07-15 日本電気株式会社 Failure analysis apparatus, failure analysis method, and program
WO2014054076A1 (en) * 2012-10-04 2014-04-10 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 (en) * 2013-09-23 2018-02-16 伊姆西公司 Based on daily record similitude come the method and apparatus of handling failure
US9258242B1 (en) 2013-12-19 2016-02-09 Emc Corporation Path selection using a service level objective
RU2013156784A (en) 2013-12-20 2015-06-27 ИЭмСи КОРПОРЕЙШН METHOD AND DEVICE FOR SELECTING THE READING AND WRITING DATA ROUTE
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
US10353780B1 (en) * 2015-03-31 2019-07-16 EMC IP Holding Company LLC Incremental backup in a distributed block storage environment
US9998537B1 (en) 2015-03-31 2018-06-12 EMC IP Holding Company LLC Host-side tracking of data block changes for incremental backup
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
TWI587661B (en) * 2015-11-26 2017-06-11 財團法人工業技術研究院 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 (en) * 2020-12-14 2021-04-13 武汉绿色网络信息服务有限责任公司 Network element management method, device and storage medium
JP2023003988A (en) 2021-06-25 2023-01-17 富士通株式会社 Information processing apparatus and operation monitoring program

Family Cites Families (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US208589A (en) * 1878-10-01 John gardner
US191904A (en) * 1877-06-12 Improvement in hames
US47482A (en) * 1865-04-25 Improved landing-platform for steamboats and other vessels
US204597A (en) * 1878-06-04 Improvement in beading attachments to cutter-heads
US49572A (en) * 1865-08-22 Improved mode for cutting soles for boots and shoes
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 (en) 1999-08-27 2010-08-04 株式会社キーエンス Charge control type inkjet printer
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 (en) 1999-11-10 2001-05-25 Nec Corp Disk drive monitor system
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
JP4794068B2 (en) 2000-06-05 2011-10-12 富士通株式会社 Storage area network management system
US7103653B2 (en) 2000-06-05 2006-09-05 Fujitsu Limited Storage area network management system, method, and computer-readable medium
EP1370950B1 (en) * 2001-02-13 2017-12-27 NetApp, Inc. System and method for policy based storage provisioning and management
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
US20030154271A1 (en) 2001-10-05 2003-08-14 Baldwin Duane Mark Storage area network methods and apparatus with centralized management
US7080140B2 (en) 2001-10-05 2006-07-18 International Business Machines Corporation Storage area network methods and apparatus for validating data from multiple sources
US20030149762A1 (en) 2001-10-05 2003-08-07 Knight Gregory John Storage area network methods and apparatus with history maintenance and removal
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
US6996670B2 (en) 2001-10-05 2006-02-07 International Business Machines Corporation Storage area network methods and apparatus with file system extension
US6952698B2 (en) 2001-10-05 2005-10-04 International Business Machines Corporation Storage area network methods and apparatus for automated file system extension
US7430593B2 (en) 2001-10-05 2008-09-30 International Business Machines Corporation Storage area network for topology rendering
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
US6920494B2 (en) 2001-10-05 2005-07-19 International Business Machines Corporation Storage area network methods and apparatus with virtual SAN recognition
US7069395B2 (en) 2001-10-05 2006-06-27 International Business Machines Corporation Storage area network methods and apparatus for dynamically enabled storage device masking
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
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
US7177935B2 (en) 2001-10-05 2007-02-13 International Business Machines Corporation Storage area network methods and apparatus with hierarchical file system extension policy
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
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
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
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 (en) 2002-04-05 2003-10-17 Hitachi Ltd Computer system
JP2003316522A (en) 2002-04-26 2003-11-07 Hitachi Ltd Computer system and method for controlling the same system
JP4100968B2 (en) 2002-06-06 2008-06-11 株式会社日立製作所 Data mapping management device
US7260628B2 (en) 2002-09-06 2007-08-21 Hitachi, Ltd. Event notification in storage networks
JP4124331B2 (en) 2002-09-17 2008-07-23 株式会社日立製作所 Virtual volume creation and management method for DBMS
US7219300B2 (en) 2002-09-30 2007-05-15 Sanavigator, Inc. Method and system for generating a network monitoring display with animated utilization information
JP4202709B2 (en) 2002-10-07 2008-12-24 株式会社日立製作所 Volume and failure management method in a network having a storage device
US6957303B2 (en) 2002-11-26 2005-10-18 Hitachi, Ltd. System and managing method for cluster-type storage

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012164616A1 (en) 2011-05-31 2012-12-06 Hitachi, Ltd. Computer system and its event notification method
US8793707B2 (en) 2011-05-31 2014-07-29 Hitachi, Ltd. Computer system and its event notification method

Also Published As

Publication number Publication date
EP1494118A3 (en) 2007-05-23
JP2005025483A (en) 2005-01-27
US7076688B2 (en) 2006-07-11
EP1494118A2 (en) 2005-01-05
US20050015685A1 (en) 2005-01-20

Similar Documents

Publication Publication Date Title
JP4130615B2 (en) Fault information management method and management server in a network having a storage device
JP4202709B2 (en) Volume and failure management method in a network having a storage device
JP4736783B2 (en) Volume and failure management method in a network having a storage device
US7669077B2 (en) Volume and failure management method on a network having a storage device
JP4294353B2 (en) Storage system failure management method and apparatus having job management function
US7949882B2 (en) Storage session management system in storage area network
US7971089B2 (en) Switching connection of a boot disk to a substitute server and moving the failed server to a server domain pool
US8924499B2 (en) Operating system migration with minimal storage area network reconfiguration
US10057124B2 (en) Resolving configuration errors through recommendations
US8244924B2 (en) Discovery and configuration of device configurations
US20140207929A1 (en) Management apparatus and management method
JP5953109B2 (en) Management server and verification method
US9660883B2 (en) Computer product, monitoring method, and monitoring apparatus
US7231503B2 (en) Reconfiguring logical settings in a storage system
WO2013171865A1 (en) Management method and management system
JP4575462B2 (en) Fault information management method and management server in a network having a storage device
JP4256912B2 (en) Volume and failure management method in a network having a storage device
JP2006040025A (en) Storage connection change method, storage management system and program

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