JP2008165822A - ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ - Google Patents
ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ Download PDFInfo
- Publication number
- JP2008165822A JP2008165822A JP2008027598A JP2008027598A JP2008165822A JP 2008165822 A JP2008165822 A JP 2008165822A JP 2008027598 A JP2008027598 A JP 2008027598A JP 2008027598 A JP2008027598 A JP 2008027598A JP 2008165822 A JP2008165822 A JP 2008165822A
- Authority
- JP
- Japan
- Prior art keywords
- failure
- volume
- virtual volume
- real
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
【課題】仮想ボリュームを提供するSANで障害の切り分けるには、SAN管理者の高度な知識が必要とされ、また、各装置から発行される障害イベントの相対的な重要性はSAN管理者が評価しなければならない。
【解決手段】SANマネージャは、SAN内の各装置の管理エージェントから情報を取得し、取得した情報をもとにSANにおけるサーバと仮想ボリュームと実ボリュームの対応関係を管理する。複数の装置から障害メッセージを受信したSANマネージャは、対応関係及び障害解析辞書テーブルを用いて、障害メッセージの内容と複数の障害メッセージ間の関連を調べ、原因となる障害を特定して表示する。またSANマネージャは、複数のストレージ装置から発行される障害メッセージのSeverityを共通のSeverityに変換するため変換テーブルを有し、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムや管理者へ障害を通報する。
【選択図】図1
【解決手段】SANマネージャは、SAN内の各装置の管理エージェントから情報を取得し、取得した情報をもとにSANにおけるサーバと仮想ボリュームと実ボリュームの対応関係を管理する。複数の装置から障害メッセージを受信したSANマネージャは、対応関係及び障害解析辞書テーブルを用いて、障害メッセージの内容と複数の障害メッセージ間の関連を調べ、原因となる障害を特定して表示する。またSANマネージャは、複数のストレージ装置から発行される障害メッセージのSeverityを共通のSeverityに変換するため変換テーブルを有し、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムや管理者へ障害を通報する。
【選択図】図1
Description
本発明は、ストレージシステムを有する計算機システムに関する。特に本発明は、ストレージシステムから提供される実ボリュームが、仮想ボリュームとしてサーバに提供されるストレージエリアネットワーク(Storage Area Network、以下SAN)において、ストレージシステムの障害を管理する方法及び装置に関するも
のである。
のである。
(1)SANについて
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるSANが浸透しつつある。SANの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
近年、各サーバからストレージを切り離して集約化した、ストレージ入出力専用のネットワークであるSANが浸透しつつある。SANの導入により、高速なデータ転送、ストレージシステムの高い拡張性と可用性、ストレージ資源の有効利用が実現可能となった。
(2)SAN管理について
SANによるストレージシステムの高い拡張性は、SANにおける複数ベンダの装置(サーバ、スイッチ、ストレージ装置)の混在を可能とした。このようなSANを無停止で運用するために、SAN管理が必要である。
SANによるストレージシステムの高い拡張性は、SANにおける複数ベンダの装置(サーバ、スイッチ、ストレージ装置)の混在を可能とした。このようなSANを無停止で運用するために、SAN管理が必要である。
SAN管理の概要については、例えば非特許文献1で説明されている。SAN管理の中でも、日々の運用の基本となる、SANに接続される各装置の稼動状況監視が特に重要である。SANの稼動状況を監視するためのソフトウェアを、以降SANマネージャとよぶ。
SANマネージャは、構成管理機能と障害監視機能の二大機能を持つ。
構成管理機能とは、SANに接続される各装置に存在する管理エージェントから情報を定期的に取得し、取得した情報からSANの物理的な接続関係(トポロジ)を検出し、常に最新のトポロジを視覚化してSANマネージャのユーザ、言い換えるとSAN管理者に提供する機能である。
障害監視機能とは、SANに接続される各装置が発行するハードウェア障害や性能低下などのイベント通知や、各装置に存在する管理エージェントから定期的に取得する装置情報に基づき、障害や性能低下等のイベントの発生を把握し、そのイベントをSAN管理者に通知する機能である。
これら二つの機能により、SAN管理者はSANマネージャを用いて装置の稼動状況を一元的に管理できるので、SAN管理者の少人数化など運用コストの削減を図ることができる。
(3)バーチャリゼーション装置について
SANにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献1に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。
SANにおけるストレージ管理技術として、仮想ボリューム技術がある。仮想ボリューム技術は特許文献1に開示されている。本特許文献には、ストレージサーバと呼ばれる装置が以下の二つの機能を有することが開示されている。
1)ストレージサーバに接続された各ストレージ装置が有する記憶媒体内の記憶領域であるボリューム(以下実ボリューム)を管理し、ボリュームプールを生成する機能。
2)ボリュームプール内の一つ以上の実ボリュームをもとに仮想ボリュームを生成し、サーバからの仮想ボリュームへのI/Oアクセスを逐次実ボリュームへのI/O要求に変換してサーバからのI/Oに応答する機能。
これら二つの機能を有する装置を、以降ではバーチャリゼーション装置と呼ぶ。バーチャリゼーション装置をSANに導入することにより、サーバへのボリューム割当は仮想ボリュームにより一元化され、バーチャリゼーション装置に接続されたストレージ装置の物理配置を意識する必要がなくなる。つまり、SAN管理者は一元的にボリュームの割当を行うことができる。
SANマネージャの持つ障害監視機能により、SAN管理者は、複数の装置から発行されたイベントを元に、どの装置のどの部位が障害の原因かを切り分ける作業を行う。以降これを、「障害の切り分け」と呼ぶ。バーチャリゼーション装置が仮想ボリュームを提供することにより、サーバに提供されるボリュームの構成自由度は高まる。しかし、SANに接続される複数ベンダの装置から発行された障害メッセージ(SNMP Trapなど)をもとに障害の切り分けをするには、個々の装置について高度な知識を持ったSAN管理者の手動作業に頼っているのが現状であり、管理コストが非常に高いという課題がある。
また、SANマネージャは、障害の深刻さ(以降Severityと呼ぶ)に応じて、業務システム全体を運用管理する管理ソフトウェア(以降上位システム管理ソフトと呼ぶ)へイベントを通知したり、SAN管理者へのメールを送信したりといった、障害通報機能を持つ。しかし、障害のSeverityの定義はSANに接続される各装置に依存するため、どの装置のどのイベントが高いSeverityを持つか、その都度SAN管理者が判断する必要があり、障害対策に時間を要するという課題がある。
本発明の第一の目的は、SANに接続される装置から障害メッセージが発行された場合に、SAN管理者による障害の切り分けを支援することである。
本発明の第二の目的は、SANにおいて、SAN管理者や上位システム管理ソフトが、SANに接続される装置から発行された障害メッセージのうち、必要な障害情報
を受信することができるようにすることである。
を受信することができるようにすることである。
第一の目的に対して、SANに接続された装置から複数の障害通知を受信する管理サーバは、バーチャリゼーション装置が管理する実ボリュームと仮想ボリュームの対応関係に基づいて、複数の障害通知を関連づけて出力する。
又、第二の目的に対して、SANに接続された装置から複数の障害通知を受信する管理サーバは、障害通知内に含まれる各々異なる基準に基づいた障害情報の重要度を示す情報を、共通の基準に基づいた重要度を示す情報に変換し、変換後の重要度に基づいて障害通知を処理する。
本発明によれば、SANに接続される装置から障害メッセージが発行された場合に、SAN管理者による障害の切り分けを支援することができる。
また、SANにおいて、SAN管理者や上位システム管理ソフトは、SAN内に存在する装置から発行された障害メッセージのうち、必要な障害情報を受信することができる。
以下に、図面を参照しながら本発明の実施形態を説明する。尚これにより本発明が限定されるものではない。
<SANの構成>
まず本実施形態におけるSANの構成例について説明する。図1から図6はSAN及びSANに接続される各装置の構成例を示し、図9から図18は各装置内に具備された管理情報を示している。
まず本実施形態におけるSANの構成例について説明する。図1から図6はSAN及びSANに接続される各装置の構成例を示し、図9から図18は各装置内に具備された管理情報を示している。
図1にはSANの構成例を示す。本発明におけるSANは、管理エージェントを有する1台以上のサーバ、管理エージェントを有する1台以上のスイッチ、管理エージェントを有する1台以上のバーチャリゼーション装置、管理エージェントを有する1台以上のストレージ装置、そしてSANマネージャを有する1台のSAN管理サーバを有する。
以降の説明の都合上、本実施形態の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が直接接続されるパスと両ストレージ装置がスイッチ経由で接続されるパスとが混在していてもよい。
SAN管理サーバ10000は、管理用ネットワーク70000を介してサーバ、スイッチ、及びストレージ装置それぞれに接続されており、各装置の管理エージェントとSAN管理サーバ10000内のSANマネージャ13100は管理用ネットワークを介して通信できる。SANマネージャ13100は、後述する処理により、SANにおける仮想ボリュームと実ボリュームの構成管理と、SANにおける障害切り分けと、SANにおける障害通報を行う。
図2にはSAN管理サーバ10000の構成例を示す。SAN管理サーバ10000は、プロセッサ11000と、メモリ13000と、管理用ネットワーク70000に接続するための管理インタフェース制御部(以下、I/Fとする。)14000と、SANマネージャ13100によって後述する処理が実行された場合にその実行結果を出力するディスプレイ装置等の出力部15000と、SAN管理者がSANマネージャに指示を入力するためのキーボード等の入力部16000を有し、これらは内部バス等の通信路17000を介して相互に接続される。
メモリ13000には、SAN管理サーバによって実行されるプログラムであるSANマネージャ13100と、SANにおける実ボリュームマッピング情報を保持する実ボリュームマッピング管理テーブル13200と、SANにおける仮想ボリュームマッピング情報を保持する仮想ボリュームマッピング管理テーブル13300と、SAN内の各装置に備えられている管理エージェントから収集した情報を格納する領域である実トポロジリポジトリ13400と、SAN内でSANマネージャ13100が管理対象としている装置の一覧を保持する装置検出リスト13500と、SAN内の各装置から受信する障害通知メッセージの内容を解釈するための一つ以上の障害解析辞書13600と、イベント内容を記録するための障害ログ13700と、後述するSeverity変換機能を行うにあたり、SAN管理者により予め定義されるSeverity変換定義を保持するための一つ以上の障害Severity変換テーブル13800とが格納されている。
図3にはサーバ20000の構成例を示す。サーバ20000は、プロセッサ21000と、メモリ23000と、管理用ネットワーク70000に接続するための管理I/F24000と、ファイバチャネル60000に接続するための一つ以上のデータI/F26000を有し、これらは内部バス等の通信路27000を介して相互に接続される。
メモリ23000には、SANマネージャ13100と通信して当該サーバの管理情報を送受信するためのプログラムである管理エージェント23100と、当該サーバのデータI/Fの管理情報を保持するデータI/F管理テーブル23200と、当該サーバがアクセスするボリュームの管理情報を保持するボリューム管理テーブル23300とが格納されている。
なお、本実施形態ではサーバはサーバAの一台、サーバAの具備するデータI/Fは一つとしたが、サーバ台数及びデータI/F数は一には限られず、サーバがSANに複数台接続されていても、又1台のサーバが複数のデータI/Fを備えていても良い。また、各サーバのデータI/Fには各サーバ内で固有の識別子(データI/F ID)が割当てられており、本実施例では、サーバAのデータI/F IDの値をa1とする。
図4にはスイッチ30000の構成例を示す。スイッチ30000は、ファイバチャネル60000を介して送受信されるデータのスイッチングを実現するコントローラ31000と、メモリ33000と、管理用ネットワーク70000に接続するための管理I/F34000と、ファイバチャネル60000に接続するための一つ以上のデータI/F36000を有し、メモリ33000と管理I/F34000とデータI/F36000とはコントローラ31000を介して相互に接続される。
メモリ33000には、SANマネージャ13100と通信して当該スイッチAの管理情報を送受信するためのプログラムである管理エージェント33100と、当該スイッチと各サーバや各ストレージ装置との間のファイバチャネル60000を介した接続関係を示す情報であるFC接続管理テーブル33200とが格納されている。
なお、本実施形態ではSAN内に存在するスイッチはスイッチAの一台とし、スイッチAは6個のデータI/Fを有する構成としているが、スイッチの台数及びデータI/Fの個数は幾つであっても良い。また、各データI/Fは装置内(スイッチ内)で固有の識別子(データI/F ID)を持ち、本実施形態においてはその値をs1、s2、s3、s4、s5、s6とする。
図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に接続される他のストレージ装置内に存在する。
メモリ43000には、SANマネージャ13100と通信してストレージ装置Aの管理情報を送受信するためのプログラムである管理エージェント43100と、ストレージ装置AのデータI/Fの管理情報を保持するデータI/F管理テーブル43200と、当該ストレージ装置Aの実ボリューム47000の管理情報を保持する実ボリューム管理テーブル43300と、仮想ボリューム機能を実現するための仮想ボリューム管理プログラム43400と、当該ストレージ装置が各サーバに提供している仮想ボリュームの管理情報を保持する仮想ボリューム管理テーブル43500が格納されている。
なお本実施形態では、ストレージ装置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とする。
図6にはストレージ装置Bの詳細な構成例を示す。ストレージ装置Bは、仮想ボリューム機能を持たない点を除いて、ストレージ装置Aと同様の構成を有する。よって、メモリ53000には仮想ボリューム管理プログラムと仮想ボリューム管理テーブルは存在しない。なお、本実施形態では、ストレージ装置Bは2個のデータI/Fと3個の実ボリュームを有するが、データI/F及び実ボリュームの数は幾つであっても良い。また、ストレージ装置BのデータI/F IDの値はd1、d2、ボリュームIDの値はvb1、vb2、vb3とする。
図9にはSAN管理サーバ10000が保持する装置検出リスト13500の一例を示す。図9の検出対象ID欄にはSAN管理サーバ内で任意に割当てられる番号が登録され、装置種別欄にはSAN内の装置の種類が登録され、装置情報欄には各装置のベンダ、各装置の名称等が登録され、IPアドレス情報欄には各装置の管理用ネットワーク70000上でのアドレスが登録され、仮想化機能欄には各装置が仮想化機能を備えているか否かが登録され、仮想化対象ID欄には、装置情報としてストレージが登録されたエントリであり、当該ストレージ装置が有する実ボリュームが他の装置によって仮想化される場合、仮想化処理を実行する当該他の装置の検出対象IDが登録される。これらの情報はSAN管理者がSAN管理サーバ10000の出力部15000及び入力部16000を用いて予め設定するものとする。本リストに基づき、SANマネージャ13100は各装置の管理エージェントを特定して当該管理エージェントと通信する。
図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番号)が登録される。
図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コマンドなどにより取得可能な、サーバに対してボリュームを提供している装置のベンダ名、装置名、及び当該ボリュームの識別子が登録される。
尚、図11の例では、サーバAは、ストレージ装置Aから実ボリュームva1と、実ボリュームはストレージB内に存在するがストレージ装置Aによって仮想化されている仮想ボリュームvv1との提供を受けて使用しており、ストレージ装置Bから実ボリュームvb3の提供を受けて使用している。尚、ストレージ装置Bの実ボリュームvb3は、ストレージ装置Aによって仮想化されることなくサーバAに提供されている。
図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が登録される。
図13にストレージ装置が保持するデータI/F管理テーブルの一例を示す。データI/F管理テーブル43200はストレージ装置Aが、データI/F管理テーブル53200はストレージ装置Bが有するテーブルである。データI/F管理テーブルのデータI/F ID欄には、ストレージ装置が有するデータI/Fの識別子の値が登録され、Port WWN欄には当該データI/FのPort WWNが登録される。
図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”を登録する。
図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は未使用である。
次に仮想ボリューム管理テーブル43500の実ボリューム欄の内容を説明する。実データI/F ID欄には、仮想ボリュームID欄に登録された識別子が示す仮想ボリュームを構成している実ボリュームにアクセスするために使用される、ストレージ装置A上のデータI/Fの識別子が登録される。SCSI ID欄には当該実データI/Fの接続先であるSCSIターゲットデバイスのSCSI ID番号が登録され、LUN欄には当該実データI/Fを介してストレージ装置から提供されるボリュームにアクセスするためのSCSIロジカルユニット番号が登録さる。実ボリューム情報欄には、SCSI INQUIRYコマンドなどにより取得可能な、当該実データI/Fを介してアクセスされる実ボリュームを提供しているストレージ装置の名称、当該実ボリュームの識別子及び記憶容量が登録される。
なお、仮想ボリューム管理テーブルには、仮想化装置(例えばストレージ装置A)によって仮想化されるボリュームのデータのみが登録される。従って、データI/F c2からアクセス可能で、ストレージ装置B内に存在する実ボリュームvb1、vb2は、ストレージ装置Aに認識されストレージ装置Aによって仮想化され仮想ボリュームとしてサーバに提供されるので、仮想ボリューム管理テーブルに登録されている。また、データI/F c1からアクセス可能な実ボリュームva1は、ストレージ装置Aにおいて仮想化されることなくサーバに提供されるため、va1に関する情報は仮想ボリューム管理テーブル43500に登録されていない。また、ストレージ装置Bの実ボリュームvb3は、データI/Fd2を介してサーバAに直接認識されているため、vb3に関する情報も、仮想ボリューム管理テーブル43500に登録されない。このように、ボリューム仮想化機能を保持するバーチャリゼーション装置は、全てのストレージ装置の実ボリュームを仮想化していなくてもよい。
図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が登録されている。
図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に関する障害情報のみを出力するよう定義されているのである。
図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に関する障害情報のみを出力するよう定義されているのである。
<SANマネージャの仮想ボリュームマッピング及び実ボリュームマッピング作成処理>
次に、SAN管理サーバ10000上のSANマネージャ13100が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はSAN管理サーバ10000のプロセッサ11000がメモリ13000内に格納されているプログラムを実行することによって定期的に実行されるもので、SAN環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはSANマネージャ13100が実施するものとする。
次に、SAN管理サーバ10000上のSANマネージャ13100が実施する、仮想ボリュームマッピング及び実ボリュームマッピング作成処理について説明する。本処理はSAN管理サーバ10000のプロセッサ11000がメモリ13000内に格納されているプログラムを実行することによって定期的に実行されるもので、SAN環境における最新の仮想ボリュームマッピング及び実ボリュームマッピングを作成し、それを出力するとともに、後述する障害切り分け処理や通報処理で利用する。以下、特に明記のない限りは、各ステップはSANマネージャ13100が実施するものとする。
図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)、終了する。
図20にSANマネージャ13100によって実行される、仮想ボリュームマッピング管理テーブル作成ステップ1730の詳細な処理を表すフローチャートを示す。また図8に図20に示す処理によって作成される仮想ボリュームマッピング管理テーブル13300の一例を示す。
SANマネージャ13100は、各サーバから受信して実トポロジリポジトリ13400に格納した全てのボリューム管理テーブル23300について、各ボリューム管理テーブルの全てのエントリに対して、以下の処理を実行する(ステップ1810)。
まず、SANマネージャは、仮想ボリュームマッピング管理テーブルに新規エントリを作成し、新しく割り当てた仮想マッピングID13301を登録する。更にSANマネージャは現在処理中のボリューム管理テーブル23300の送信元サーバ名13302、ボリューム管理テーブルに記憶されているデータI/F ID13304及びLU ID13303を登録する(ステップ1820)。次にSANマネージャは、登録されたデータI/F13304が接続されるスイッチのデータI/Fを調査し、スイッチの名前13305とデータI/F ID13306を登録する。具体的には、SANマネージャはまず仮想ボリュームマッピング管理テーブル13300に登録されたサーバのデータI/F ID13304をキーとして、当該サーバから受信して実トポロジデポジトリ13400に格納されているデータI/F管理テーブル23200を検索し、当該データI/F IDのPort WWNを調べる。さらにSANマネージャは当該Port WWNをキーとして、スイッチAから受信して実トポロジデポジトリ13400に格納されているFC接続管理テーブル33200を検索し、当該サーバがどのスイッチのどのデータI/Fに接続しているかを検索し、結果を接続先スイッチ名13305と接続先スイッチデータI/F ID13306として登録する(ステップ1830)。以上の処理により、仮想ボリュームマッピング管理テーブル13300の左半分(サーバ欄)にサーバに関する情報が登録される。
次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の左半分(ストレージ欄)に情報を登録するための処理を行う。SANマネージャはボリューム管理テーブル23300にボリューム情報として登録されているベンダ名と装置名から、当該ボリューム管理テーブルに登録されているボリュームがバーチャリゼーション装置によって提供されているものか否かを調べる。具体的には、SANマネージャは装置名をキーとして装置検出リスト13500を検索し、当該装置が仮想化機能の有無をチェックし、仮想化機能を有する場合にはバーチャリゼーション装置から提供されているものと判断する。(ステップ1840)。ステップ1840の結果により、以下のように処理が分岐する(ステップ1850)。
ボリュームがバーチャリゼーション装置 以外のストレージ装置から提供されている場合、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)。
ステップ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)。
装置検出リスト13500に装置が未登録のためボリューム管理テーブル23300が実トポロジリポジトリ13400に格納されていない場合、及び、装置が管理I/Fを具備しない場合、ステップ1850では例外的に装置の種類を判断することができない。このようなボリューム管理テーブル23300のボリューム情報欄に登録されている情報がない場合は、ストレージ欄を空欄にする(ステップ1862)。
以上のステップを、SAN管理サーバが各サーバから受信し実トポロジリポジトリ13400に格納した全てのボリューム管理テーブルの全エントリに対して、SANマネージャが実行したとき、ステップ1730の処理は終了する。
図21に、SANマネージャ13100が行う実ボリュームマッピング管理テーブル作成ステップ1740の詳細な処理フローを示す。又図7に図21に示す処理によって作成される実ボリュームマッピング管理テーブルの一例を示す。
SANマネージャ13100は、ステップ1730で作成した仮想ボリュームマッピング管理テーブル13300の全てのエントリに対して、以下の処理を実行する(ステップ1910)。
まず、SANマネージャは新規エントリを作成し、新しく割り当てた実マッピングID13201を登録する(ステップ1920)。次に、SANマネージャは仮想ボリュームマッピング管理テーブル13300の各エントリのストレージ名13309をもとに、当該ストレージ名が示す装置が仮想化機能を持つかどうか判断する。具体的には、ストレージ名13309をキーとして装置検出リスト13500を検索し、当該装置の仮想化機能の有無をチェックする(ステップ1930)。
仮想化機能を有する場合、SANマネージャは以下のステップを実行する。SANマネージャは、仮想ボリュームマッピング管理テーブルエントリ中のボリュームID13311をキーとして、ストレージ名13309が示す装置から受信した仮想ボリューム管理テーブル33500を検索し、ボリュームID13311と一致する仮想ボリュームIDのエントリを抽出する(ステップ1940)。次にSANマネージャは、検索して得られたエントリの数と同数のエントリを実ボリューム管理マッピングテーブルに用意する(ステップ1950)。そして、SANマネージャは、用意したエントリに対して、サーバ欄(13202から13206)には仮想ボリュームマッピング管理テーブル13300の現在処理中のエントリのサーバ欄の内容(13302から13306)をコピーする。ストレージ欄のスイッチデータI/F ID欄13208にはステップ1940で抽出した仮想ボリューム管理テーブル33500のエントリの、実ボリューム情報欄の実データI/F IDの内容をコピーする。また、ストレージ欄のストレージ名エントリ13209及びボリュームIDエントリ13211には、仮想ボリューム管理テーブル43500の当該エントリの、実ボリューム情報欄の実ボリューム情報として登録されているストレージ名及びボリュームIDをコピーする。また対応仮想マッピングID欄13212には仮想ボリュームマッピング管理テーブル13300中の仮想マッピングID13301の内容を登録する。ストレージ欄のスイッチ名欄13207には仮想ボリュームマッピング管理テーブルのストレージ欄のスイッチ名13307の内容をコピーする(ステップ1960)。更に、SANマネージャは、実ボリュームマッピング管理テーブル13212のストレージ欄のボリュームID13211に登録したボリュームIDをキーとして、ストレージ装置から受信した実ボリューム管理テーブルを検索して、当該ボリュームが接続されるデータI/FのIDを検索し、これを仮想ボリュームマッピング管理テーブルのストレージ欄のストレージデータI/F ID13210に登録する。
ステップ1930にて仮想化機能を有しないとの判断がされた場合、SANマネージャは、仮想ボリュームマッピング管理テーブル13300の現在処理中のエントリ(13302から13311)を実ボリュームマッピング管理テーブル13200のエントリ(13202から13211)へコピーし、仮想ボリュームマッピング管理テーブル13300の仮想マッピングID13301の内容を実ボリュームマッピング管理テーブル13200の対応仮想マッピングID13212に登録する。
以上の処理により実ボリュームマッピング管理テーブル13200のエントリ13201から13212までが登録される。
以上のステップを仮想ボリュームマッピング管理テーブル13300の全てのエントリに対してSANマネージャが実行したとき、ステップ1740に示す処理が終了する。
図7で示された実ボリュームマッピングテーブルをもとに、SANマネージャ13100が出力部15000に出力する実トポロジ表示の例を図23に示す。実ボリュームマッピング管理テーブル13200の内容をもとに、サーバ、スイッチ、ストレージ間の接続関係を表した出力例が実トポロジ表示2010である。
<SANマネージャの障害切り分け処理>
以下に、SANマネージャによる障害切り分け処理の一例について示す。
以下に、SANマネージャによる障害切り分け処理の一例について示す。
現在のSAN管理ソフトによる障害監視機能は、IETF(Internet Engineering Task Force)で作成されたRFC1157「A Simple Network Management Protocol (SNMP)」によって定められたSNMPプロトコルのTrapメッセージを利用することが多い。しかし、仮想ボリューム技術によってサーバに割り当てられるボリュームは仮想化されているため、仮想ボリュームレベルで障害箇所を特定するのは困難である。また、SAN管理者は、複数の装置から発行されたイベントを元に、障害の切り分けするには、現状個々の装置の高度な知識を持ったSAN管理者の手動作業に頼るため、管理コストが非常に高い。
そこで本処理では、複数の装置が発行する障害通知を受けたSANマネージャは、障害解析辞書や、各管理エージェントから取得して実トポロジリボジトリに格納したSANの構成情報をもとに、それらの障害が実ボリューム及び仮想ボリュームへのI/Oアクセスに与える影響を解析する。また、当該障害メッセージ受信前の一定期間に受信した障害メッセージのうち、当該障害メッセージに関連する障害メッセージがあるかを解析し、障害メッセージ間の関係を調べる。そして、これらの結果をSANマネージャが出力することによって、SAN管理者による複数障害メッセージの解析及び障害きりわけ作業を軽減する。
ここで、障害切り分け処理を説明する前に、図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メッセージを解釈する必要がある。
本実施形態において、ストレージ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”の障害が生じている旨を表している。
図22に、SAN管理サーバ10000上のSANマネージャ13100が実施する、障害切り分け処理の一例を示すフローチャート2400を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。
SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2410)。メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出し(ステップ2415)、抽出したIPアドレスをキーとして実トポロジリポジトリ13400に格納されている装置検出リスト13500を検索する(ステップ2420)。
IPアドレスが装置検出リスト13500内に存在しない場合は、未登録の装置からのTrapメッセージであるためSANマネージャはTrapメッセージの内容を解析できない。従ってSANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、障害装置としてIPアドレスを、障害部位としてTrapメッセージそのものを出力し(ステップ2465)、後述するステップ2455の処理にジャンプする。
ステップ2420において、抽出したIPアドレスが装置検出リスト13500内に存在し、Trapメッセージ発行元の装置が特定できた場合、SANマネージャはSAN管理サーバ10000が当該装置の障害解析辞書を具備しているか確認する(ステップ2425)。
ステップ2425にて障害解析辞書を具備している場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録し、さらに装置名を登録する。さらに、TrapメッセージのVariable Bindingsフィールドをキーとして障害解析辞書を検索し、障害コードが登録されていれば、当該障害コードを障害コード欄に登録する(ステップ2430)。
ステップ2425で障害解析辞書を具備していないと判断した場合は、SANマネージャは障害ログ13700に新規エントリを作成し、イベントIDを割当て、メッセージのTimestampフィールドから障害発生時刻を抽出して時刻欄に登録するとともに、装置名を登録する。さらに、SANマネージャは、障害部位は装置全体みなし、障害コード欄には“装置全体”として登録し、以降のステップを継続する(ステップ2431)。
ステップ2430あるいはステップ2431が終了した後、SANマネージャは、登録した障害コードが示す障害部位が実ボリュームマッピング及び仮想ボリュームマッピングに関係があるかを調査する(ステップ2435)。具体的には、まず、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとして障害部位とその識別子を検索する。次に、障害装置名と、先に得られた障害部位または障害部位の識別子をキーとして、実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
その後、SANマネージャは、特定した障害部位が、仮想ボリューム管理に関係するかを調査する(ステップ2440)。具体的には、ステップ2435で検索した障害装置名と、障害部位または障害部位の識別子をキーとして、仮想ボリューム管理テーブル43500に一致するエントリがあるか検索する。一致するエントリがあれば、SANマネージャはそのエントリから仮想ボリュームIDを抽出する。さらに、抽出した仮想ボリュームIDをキーとして実ボリュームマッピング管理テーブル13200に一致するエントリがあるか検索し、実マッピングID13201と仮想マッピングID13212を抽出し、障害ログ13700の作成中エントリの実ボリューム欄、仮想ボリューム欄に登録する。
ステップ2435とステップ2440で障害ログの作成中エントリの、実ボリュームマッピングと、仮想ボリュームマッピングの関係を登録した後、SANマネージャは、当該作成中エントリと、他の障害ログエントリの関係について調査する。まず、SANマネージャは、作成中のエントリが、ハード故障によるものか、他の部位へのアクセスエラーによるものかを調査する(ステップ2445)。具体的には、登録された障害装置名の障害解析辞書のエントリに対して、障害コードをキーとしてその原因を検索する。
ステップ2445で調査した原因がハード故障であった場合は、作成中イベントは、他の障害イベントを誘発する可能性のある“親イベント”であると判断し、イベント関係欄に“親イベント”と登録する(ステップ2450)。ステップ2445で調査した原因が他の部位へのアクセスエラーによるものであった場合は、作成中イベントは、他の障害イベントが原因で発行された可能性のある“子イベント”であると判断し、イベント関係欄に“子イベント”と登録する(ステップ2451)。
最後にSANマネージャは作成した障害ログのエントリ内容を障害メッセージとして出力する(ステップ2455)。以上でフローチャート2400を終了する。
ここで、フローチャート2400で示されたSANマネージャ10000の障害切り分け処理の具体例について説明する。図23は、図17に記載された障害ログのエントリが、フローチャート2400で示された障害切り分け処理により、どのように出力されるかの例を示す図である。ここで、イベントID 1000、1001、1002、1003は、ストレージ装置BのデータI/F ID d1がハード故障したことにより発生した四つの障害メッセージである。よって以下では前記四つの障害メッセージがどのように解析され、関係付けられるかを説明する。
イベントID 1000の障害メッセージを受信したとき、SANマネージャは、ステップ2430でストレージ装置BのデータI/F ID d1のハード故障と解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりハード故障は“親イベント”であることがわかる。
次に、イベントID 1001の障害メッセージを受信したとき、SANマネージャは、ステップ2430でストレージ装置Aの仮想ボリュームvv1のI/Oを実ボリュームvb1に展開するとき、アクセスエラーが発生したと解析する。さらに、ステップ2435において、実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関係することがわかる。さらに、ステップ2445によりアクセスエラーは“子イベント”であることがわかる。同様に、イベントID 1002の障害メッセージ及びイベントID 1003の障害メッセージも“子イベント”であることがわかる。
ステップ2455で障害メッセージを出力するにあたり、SANマネージャは、一定時間内に発行された障害メッセージの実ボリューム欄、仮想ボリューム欄、イベント関係欄を調査し、各障害メッセージの関係の有無と、関係ある場合は“親イベント”と“子イベント”のどちらかを特定する。ここで、「一定時間」とは、あらかじめSAN管理者が指定した時間で、障害の関連付けの単位となる時間である。図17のイベントID 1000、1001、1002、1003は、いずれも実ボリュームマッピングpm2及び仮想ボリュームマッピングvm2と関連付けられ、かつ、イベントID 1000が“親イベント”であることがわかるので、図23の障害イベント一覧ウィンドウ2020では、例えばイベント関連性欄にシンボル2021のように関連付けを示すことができる。
また、例えば、SAN管理者がイベント指定2022のように、ある特定の障害イベントを指定したとき、SANマネージャ10000は、実トポロジ表示ウィンドウ2010中に、実トポロジマッピング表示2011のように指定されたイベントに対応する実トポロジマッピングを図示してもよい。さらに、障害通知ウィンドウ2012のように、指定されたイベントの内容を分かりやすく表示してもよい。
以上、SANマネージャは、障害切り分け処理により、SANを構成する複数の装置からの障害メッセージを受信したとき、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、SAN管理者による障害の切り分け負担を軽減することができる
<SANマネージャのSeverity変換機能を含む障害通報処理>
以下に、SANマネージャによるSeverity変換機能を含む障害通報処理の一例について示す。本処理では、SANマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のSeverity変換機能を保持し、SAN管理者により予め定義された障害Severity変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。
<SANマネージャのSeverity変換機能を含む障害通報処理>
以下に、SANマネージャによるSeverity変換機能を含む障害通報処理の一例について示す。本処理では、SANマネージャはバーチャリゼーション装置に接続される複数のストレージ装置のSeverity変換機能を保持し、SAN管理者により予め定義された障害Severity変換テーブル定義により、障害メッセージが受信されたとき、その変換テーブルに定義された共通のSeverityに応じて上位管理プログラムへの通報や管理者への通報を実施するものである。
図24に、SAN管理サーバ10000上のSANマネージャ13100が実施する、障害切り分け処理のフローチャート2500を示す。以下、特に明記のない場合は、各ステップはSANマネージャ13100が実施するものとする。
SANマネージャ13100は、ある装置からのSNMP Trapメッセージが受領されるまで待つ(ステップ2510)。メッセージを受領したら、SANマネージャはメッセージのAgent Addressフィールドから、メッセージ発行元の装置のIPアドレスを抽出する(ステップ2515)。
抽出したIPアドレスを元に、SANマネージャは、メッセージ発行元の装置が共通Severity定義に関係あるかどうかを調査する(ステップ2520)。具体的には、はじめに、抽出したIPアドレスが装置検出リスト13500内に存在するかどうかを調べることで、メッセージ発行元の装置を特定する。次に、特定された装置に関するSeverity欄が、障害Severity変換テーブル13800に存在するか調査する。
ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係ないと判断した場合は、SANマネージャはSeverity変換機能を行わず、Trapメッセージをそのまま上位管理ソフトに転送する(ステップ2526)。
ステップ2520において、メッセージ発行元の装置が共通Severity定義に関係あると判断した場合は、SNMP TrapメッセージのSpecific Trap Typeフィールドからメッセージ発行元装置のSeverityを抽出する(ステップ2525)。メッセージ発行元の装置名と、抽出したSeverityをもとに、障害Severity変換テーブル13800を調査し、共通Severityとアクションを特定する(ステップ2530)。最後に、ステップ2530で特定したアクションを実行する(ステップ2535)。以上でフローチャート2500を終了する。
ここで、フローチャート2500で示されたSANマネージャ10000の障害通報処理の具体例について説明する。図17に記載された障害ログのエントリのうち、イベントID 2000のイベントが受信されたときを考える。イベントID 2000の障害メッセージは、ステップ2515でストレージ装置Bが発行元装置であると判断されるので、ステップ2520で共通Severity定義に関係ある場合と判断される。ステップ2525においてTrapメッセージ中のSeverityは“4”であることから、障害Severity変換テーブル13800記載のアクション「ストレージAの情報をTrap送信及びメール送信」を適用し、イベントID 2000の障害メッセージは、上位管理ソフト及びSAN管理者には通報されない。
以上、SANマネージャは、Severity変換機能を含む通報処理により、SANマネージャが受信する複数のストレージ装置の障害メッセージに統一的なSeverityを定義し、その定義に応じたSANマネージャの障害通報機能を提供することができる。
なお、SANマネージャが実施するストレージネットワークの実トポロジマッピング及び仮想トポロジマッピング作成処理、障害切り分け処理、Severity変換機能を含む障害通報処理は、ストレージ装置A 40000がバーチャリゼーション装置であることを想定していたが、ストレージ装置A40000とは異なる装置をバーチャリゼーション装置として管理ネットワーク70000及びSAN60000に接続した構成であっても、上述の処理は同様に実現可能である。
以上に説明した実施形態によれば、バーチャリゼーション装置を有するSANにおいて、SANマネージャが実行される装置がSANを構成する複数の装置からの障害メッセージを受信したとき、SANマネージャが、その障害メッセージの解析と、他の障害メッセージとの関連付けを自動化し、SAN管理者による障害の切り分け負担を軽減することができる。
また、SANにおいてSANマネージャが受信する複数のストレージ装置の障害メッセージに統一的なSeverityを定義し、その定義に応じた方法でSANマネージャが障害を通報することで、SAN管理者や上位システム管理ソフトが、必要十分な障害情報のみを受信することになり、通報後の障害対策の迅速化が可能となる。
10000:SAN管理サーバ
13100:SANマネージャ
20000:サーバ
30000:スイッチ
40000:ストレージ装置A
50000:ストレージ装置B
23100:サーバの管理エージェント
33100:スイッチの管理エージェント
43100:ストレージ装置Aの管理エージェント
53100:ストレージ装置Bの管理エージェント
47000:ストレージ装置Aの提供する実ボリューム
48000:ストレージ装置Aの提供する仮想ボリューム
57000:ストレージ装置Bの提供する実ボリューム
13100:SANマネージャ
20000:サーバ
30000:スイッチ
40000:ストレージ装置A
50000:ストレージ装置B
23100:サーバの管理エージェント
33100:スイッチの管理エージェント
43100:ストレージ装置Aの管理エージェント
53100:ストレージ装置Bの管理エージェント
47000:ストレージ装置Aの提供する実ボリューム
48000:ストレージ装置Aの提供する仮想ボリューム
57000:ストレージ装置Bの提供する実ボリューム
Claims (12)
- 実ボリュームを有する記憶装置と、
ネットワークを介して前記記憶装置と接続され、前記記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置と、
前記記憶装置及び前記バーチャリゼーション装置と管理ネットワークを介して接続される管理サーバとを有するシステムにおける、障害情報管理方法であって、
一定期間における前記記憶装置内の第1及び第2の実ボリュームと関係のある障害を前記記憶装置が検知し、一定期間における前記バーチャリゼーション装置内の第3及び第4の仮想ボリュームと関係のある障害を前記バーチャリゼーション装置が検知する障害検知ステップと、
前記管理サーバが、前記記憶装置から前記第1及び第2の実ボリュームについての障害通知を、前記バーチャリゼーション装置から前記第3及び第4の仮想ボリュームについての障害通知を受信する障害通知受信ステップと、
前記バーチャリゼーション装置が管理する実ボリュームの識別情報と仮想ボリュームの識別情報との対応テーブルに基づいて、前記管理サーバが、前記第1の実ボリュームに対応する仮想ボリュームが前記第3の仮想ボリュームであることを特定し、前記第3の仮想ボリュームについての障害通知と前記第1の実ボリュームについての障害通知とを第1の障害関連情報として関連付け、前記第2の実ボリュームに対応する仮想ボリュームが前記第4の仮想ボリュームであることを特定し、前記第4の仮想ボリュームについての障害通知と前記第2の実ボリュームについての障害通知とを第2の障害関連情報として関連付ける関連付けステップと、
前記第1の障害関連情報と前記第2の障害関連情報とを異なる障害関連情報として出力する障害メッセージ出力ステップとを有することを特徴とする障害情報管理方法。 - 請求項1記載の障害情報管理方法において、
更に、前記管理サーバが、前記ネットワークに接続される装置から前記ネットワークの構成情報を受信するステップと、
前記管理サーバが、前記構成情報に基づいて、前記実ボリュームと前記仮想ボリュームとの対応関係を特定するステップとを有することを特徴とする障害情報管理方法。 - 請求項1記載の障害情報管理方法において、
更に、前記関連付けられた第1の障害関連情報について、前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知の障害を原因として、前記第3の仮想ボリュームまたは前記第1の実ボリュームについての障害通知が発行されることを特定する障害要因特定ステップを有することを特徴とする障害情報管理方法。 - 請求項3記載の障害情報管理方法において、
前記障害要因特定ステップは、前記第1の障害関連情報について、ハードウェアの故障によって通知される前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知とを特定するステップであることを特徴とする障害情報管理方法。 - 請求項1記載の障害情報管理方法において、
更に、前記記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害の重要度を表す複数の重要度情報を、前記記憶装置及びバーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に前記管理サーバが変換するステップと、
変換後の重要度情報に基づいて、予め定められた方法で、前記管理サーバが障害関連情報を出力するステップを有することを特徴とする障害情報管理方法。 - 請求項1記載の障害情報管理方法において、
前記システムは、更に、前記記憶装置、前記バーチャリゼーション装置、及び前記管理サーバを相互に接続するスイッチを有し、
前記障害検知ステップは、前記スイッチの障害を検知するステップを有し、
前記障害通知受信ステップは、前記管理サーバが前記スイッチから障害通知を受信するステップを有し、
前記関連付けステップは、前記バーチャリゼーション装置内の第3及び第4の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記記憶装置内の第1及び第2の実ボリュームについての障害通知と、前記スイッチからの障害通知とが関連するかを判断するステップを有し、
前記スイッチからの障害通知が前記第1の実ボリューム及び前記第3の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第1の障害関連情報として出力し、前記スイッチからの障害通知が前記第2の実ボリューム及び前記第4の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第2の障害関連情報として出力する障害メッセージ出力ステップとを有することを特徴とする障害情報管理方法。 - 実ボリュームを有する記憶装置と、ネットワークを介して前記記憶装置と接続され、前記記憶装置の実ボリュームを仮想ボリュームとして管理するバーチャリゼーション装置とに、管理ネットワークを介して接続される管理サーバであって、
前記管理ネットワークに接続するためのインタフェース制御部と、
プロセッサと、
前記プロセッサが実行するプログラム及び前記プロセッサが使用する情報が格納されているメモリと、
前記プロセッサによって実行される処理の処理結果を出力する出力部とを有し、
前記インタフェース制御部は、前記記憶装置から一定期間における第1及び第2の実ボリュームについての障害通知を、前記バーチャリゼーション装置から一定期間における第3及び第4の仮想ボリュームについての障害通知を受信し、
前記プロセッサは、前記バーチャリゼーション装置が管理する実ボリュームの識別情報と仮想ボリュームの識別情報との対応テーブルに基づいて、前記第1の実ボリュームに対応する仮想ボリュームが前記第3の仮想ボリュームであることを特定し、前記第3の仮想ボリュームについての障害通知と前記第1の実ボリュームについての障害通知とを第1の障害関連情報として関連付け、前記第2の実ボリュームに対応する仮想ボリュームが前記第4の仮想ボリュームであることを特定し、前記第4の仮想ボリュームについての障害通知と前記第2の実ボリュームについての障害通知とを第2の障害関連情報として関連付け、
前記出力部は、前記第1の障害関連情報と前記第2の障害関連情報とを異なる障害関連情報として出力することを特徴とする管理サーバ。 - 請求項7記載の管理サーバにおいて、
前記インタフェース制御部は、前記ネットワークに接続される装置から前記ネットワークの構成情報を受信し、
前記プロセッサは、前記構成情報に基づいて、前記実ボリュームと前記仮想ボリュームとの対応関係を特定することを有することを特徴とする管理サーバ。 - 請求項7記載の管理サーバにおいて、
前記プロセッサは、更に、前記関連付けられた第1の障害関連情報について、前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知の障害を原因として、前記第3の仮想ボリュームまたは前記第1の実ボリュームについての障害通知が発行されることを特定することを特徴とする管理サーバ。 - 請求項9記載の管理サーバにおいて、
前記プロセッサは、前記第1の障害関連情報について、ハードウェアの故障によって通知される前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知と、前記ハードウェアの故障の影響を受けて生じたアクセスエラーによって通知される前記第1の実ボリュームまたは前記第3の仮想ボリュームについての障害通知とを特定することを特徴とする管理サーバ。 - 請求項7記載の管理サーバにおいて、
前記プロセッサは更に、前記記憶装置及びバーチャリゼーション装置から受信する複数の障害通知に含まれる、各々異なる基準に基づく障害の重要度を表す複数の重要度情報を、前記記憶装置及びバーチャリゼーション装置を含むシステムにおける共通の基準に基づく重要度情報に前記管理サーバが変換し、
前記出力部は、変換後の重要度情報に基づいて、予め定められた方法で障害関連情報を出力することを特徴とする管理サーバ。 - 請求項7記載の管理サーバにおいて、
前記管理サーバは、前記記憶装置および前記バーチャリゼーション装置とスイッチを介して相互に接続され、
前記インタフェース制御部は、前記スイッチから障害通知を受信し、
前記プロセッサは、前記バーチャリゼーション装置内の第3及び第4の仮想ボリュームについての障害通知と、前記スイッチを介して接続される前記記憶装置内の第1及び第2の実ボリュームについての障害通知と、前記スイッチからの障害通知とが関連するかを判断し、
前記出力部は、前記スイッチからの障害通知が前記第1の実ボリューム及び前記第3の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第1の障害関連情報として出力し、前記スイッチからの障害通知が前記第2の実ボリューム及び前記第4の仮想ボリュームについての障害通知と関連する場合、前記スイッチからの障害通知を関連付けて前記第2の障害関連情報として出力することを特徴とする管理サーバ。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008027598A JP4575462B2 (ja) | 2008-02-07 | 2008-02-07 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008027598A JP4575462B2 (ja) | 2008-02-07 | 2008-02-07 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003189954A Division JP4130615B2 (ja) | 2002-10-07 | 2003-07-02 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2008165822A true JP2008165822A (ja) | 2008-07-17 |
JP4575462B2 JP4575462B2 (ja) | 2010-11-04 |
Family
ID=39695111
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008027598A Expired - Fee Related JP4575462B2 (ja) | 2008-02-07 | 2008-02-07 | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4575462B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10949287B2 (en) | 2018-09-19 | 2021-03-16 | International Business Machines Corporation | Finding, troubleshooting and auto-remediating problems in active storage environments |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6346534A (ja) * | 1986-08-14 | 1988-02-27 | Fujitsu Ltd | 分割化ボリユ−ム制御方式 |
JPH10133826A (ja) * | 1996-11-01 | 1998-05-22 | Fujitsu Ltd | Raid装置 |
-
2008
- 2008-02-07 JP JP2008027598A patent/JP4575462B2/ja not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6346534A (ja) * | 1986-08-14 | 1988-02-27 | Fujitsu Ltd | 分割化ボリユ−ム制御方式 |
JPH10133826A (ja) * | 1996-11-01 | 1998-05-22 | Fujitsu Ltd | Raid装置 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10949287B2 (en) | 2018-09-19 | 2021-03-16 | International Business Machines Corporation | Finding, troubleshooting and auto-remediating problems in active storage environments |
Also Published As
Publication number | Publication date |
---|---|
JP4575462B2 (ja) | 2010-11-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4130615B2 (ja) | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ | |
JP4736783B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
JP4202709B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
US7669077B2 (en) | Volume and failure management method on a network having a storage device | |
JP4294353B2 (ja) | ジョブ管理機能を有するストレージ系障害管理方法及び装置 | |
US7949882B2 (en) | Storage session management system in storage area network | |
US7619965B2 (en) | Storage network management server, storage network managing method, storage network managing program, and storage network management system | |
EP2738679A1 (en) | Computer program and management computer | |
EP2674865A1 (en) | MANAGEMENT COMPUTER AND METHOD FOR ROOT CAUSE ANALYSiS | |
WO2010137063A1 (ja) | 管理サーバ及び管理システム | |
US20140207929A1 (en) | Management apparatus and management method | |
US8656012B2 (en) | Management computer, storage system management method, and storage system | |
JP2010122971A (ja) | 情報処理システムを構成している装置の監視方法、情報処理装置、及び情報処理システム | |
US20110099273A1 (en) | Monitoring apparatus, monitoring method, and a computer-readable recording medium storing a monitoring program | |
US20140310409A1 (en) | Computer product, monitoring method, and monitoring apparatus | |
US9021078B2 (en) | Management method and management system | |
JP4575462B2 (ja) | ストレージ装置を有するネットワークにおける障害情報管理方法及び管理サーバ | |
WO2015019488A1 (ja) | 管理システム及びその管理システムによるイベント解析方法 | |
JP4256912B2 (ja) | ストレージ装置を有するネットワークにおける、ボリューム及び障害管理方法 | |
JP2014123172A (ja) | 計算機システム、及びシステム管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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: 20100817 |
|
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: 20100819 |
|
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: 20130827 Year of fee payment: 3 |
|
LAPS | Cancellation because of no payment of annual fees |