(57)【要約】【課題】  ストレージ装置の運用管理を行うストレージ管理装置の利便性を向上させる。【解決手段】  ストレージ運用管理システムを構築する。管理サーバ１００の要否判断部３６ａは、ストレージ装置の運用手順を記述した運用シナリオに含まれるコマンドと、リフレッシュ要否対応表３７とに基づいて、運用シナリオの実行に際しての、リフレッシュの要否を判断する。シナリオ制御部３６ｂは、要否判断部３６ａが、リフレッシュが必要と判断したときに、ストレージ装置の構成情報を収集するための収集ジョブを運用シナリオに自動的に挿入する。管理サーバ１００は、運用シナリオ実行時には、挿入された収集ジョブを実行し、構成情報の変更内容を運用シナリオに反映させる。【選択図】  図２
2005190260.tif 000002
【特許請求の範囲】
【請求項１】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置であって、
前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶するシナリオ記憶部と、
前記コマンドに基づいて、前記ストレージ装置の構成情報の収集の要否を判断する要否判断部と、
前記収集が必要と判断されたときに、前記運用シナリオの実行に伴い、前記ストレージ装置の構成情報を収集するための構成情報収集ジョブを前記運用シナリオに挿入するシナリオ制御部と、
を備えるストレージ管理装置。
【請求項２】
請求項１記載のストレージ管理装置であって、さらに、
前記コマンドと、前記収集の要否との対応関係を表す要否対応表を記憶する要否対応表記憶部を備え、
前記要否判断部は、前記要否対応表に基づいて、前記収集の要否を判断する、
ストレージ管理装置。
【請求項３】
請求項１記載のストレージ管理装置であって、
前記要否判断部は、前記構成情報に変更があったことを検出したときに、前記判断を行う、
ストレージ管理装置。
【請求項４】
請求項１記載のストレージ管理装置であって、
前記要否判断部は、前記運用シナリオの実行時に、前記判断を行う、
ストレージ管理装置。
【請求項５】
請求項１記載のストレージ管理装置であって、
前記運用シナリオは、複数の前記コマンドを含み、
前記要否判断部は、さらに、前記コマンドに基づいて、前記構成情報収集ジョブの挿入箇所を決定する、
ストレージ管理装置。
【請求項６】
請求項１記載のストレージ管理装置であって、さらに、
前記収集が必要と判断されたときに、前記構成情報収集ジョブを実行する構成情報収集部と、
該収集された構成情報に基づいて、前記運用シナリオの内容を更新するシナリオ更新部と、
を備えるストレージ管理装置。
【請求項７】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置であって、
前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶するシナリオ記憶部と、
前記運用シナリオを実行するときに、ユーザからの指示とは無関係に、前記ストレージ装置の構成情報を収集する構成情報収集部と、
を備えるストレージ管理装置。
【請求項８】
請求項７記載のストレージ管理装置であって、さらに、
前記コマンドに基づいて、前記構成情報の収集の適否を判断する適否判断部を備え、
前記構成情報収集部は、前記収集が不適と判断されたときに、前記収集を禁止する、
ストレージ管理装置。
【請求項９】
請求項８記載のストレージ管理装置であって、さらに、
前記コマンドと、前記収集の適否との対応関係を表す適否対応表を記憶する適否対応表記憶部を備え、
前記適否判断部は、前記適否対応表に基づいて、前記収集の適否を判断する、
ストレージ管理装置。
【請求項１０】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置を制御する制御方法であって、
（ａ）前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶する工程と、
（ｂ）前記コマンドに基づいて、前記ストレージ装置の構成情報の収集の要否を判断する工程と、
（ｃ）前記収集が必要と判断されたときに、前記運用シナリオの実行に伴い、前記ストレージ装置の構成情報を収集するための構成情報収集ジョブを前記運用シナリオに挿入する工程と、
を備える制御方法。
【請求項１１】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置を制御する制御方法であって、
（ａ）前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶する工程と、
（ｂ）前記運用シナリオを実行するときに、ユーザからの指示とは無関係に、前記ストレージ装置の構成情報を収集する工程と、
を備える制御方法。
【請求項１２】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置を制御するためのコンピュータプログラムであって、
前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶する機能と、
前記コマンドに基づいて、前記ストレージ装置の構成情報の収集の要否を判断する機能と、
前記収集が必要と判断されたときに、前記運用シナリオの実行に伴い、前記ストレージ装置の構成情報を収集するための構成情報収集ジョブを前記運用シナリオに挿入する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【請求項１３】
ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置を制御するためのコンピュータプログラムであって、
前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶する機能と、
前記運用シナリオを実行するときに、ユーザからの指示とは無関係に、前記ストレージ装置の構成情報を収集する機能と、
をコンピュータに実現させるためのコンピュータプログラム。
【請求項１４】
請求項１２または１３記載のコンピュータプログラムをコンピュータ読み取り可能に記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ装置の運用管理に関するものである。
【背景技術】
【０００２】
近年、大容量のデータを格納するストレージ装置が普及している。これに伴い、ストレージ装置を管理するためのストレージ管理装置も普及している。ストレージ管理装置には、種々の技術が適用される。このうちの１つとして、バックアップや、リストアなど、ストレージ装置の運用管理を自動化する技術がある。この技術では、管理者がストレージ装置の運用手順を記述した運用シナリオを用意し、ストレージ管理装置がこの運用シナリオを予め設定されたタイミングで実行することによって、ストレージ装置の運用管理の自動化を実現している。運用シナリオは、複数の運用ジョブによって構成されており、各運用ジョブは、バックアップや、リストアなど、ストレージ装置を制御するためのコマンドを含んでいる。
【０００３】
このようなストレージ装置の運用管理には、下記特許文献１〜４に記載された種々の技術を適用することができる。
【０００４】
運用シナリオは、ストレージ装置の構成情報に基づいて実行される。構成情報は、ディスクや、論理ボリュームや、格納するデータベースなどに関する情報を含んでおり、ディスクの増設や、論理ボリュームの追加や、データベースの変更などが行われたときには、構成情報が変更される。この場合、管理者は、構成情報の再収集をストレージ管理装置に指示して構成情報の収集を行い、その変更内容を運用シナリオに反映させる必要がある。構成情報の変更が運用シナリオに反映されないまま実行されると、実際の構成情報と運用シナリオとの間に不整合が生じ、処理不能となったり、誤った処理がおこなわれたりする場合があるからである。
【０００５】
【特許文献１】特開２００２−５５９５１号公報
【特許文献２】特開平９−８１２２６号公報
【特許文献３】特開２００２−９９６８８号公報
【特許文献４】特開平１１−２７２８５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、構成情報が変更されたときや、運用シナリオの実行時などに、その都度、管理者が構成情報の再収集をストレージ管理装置に指示して構成情報の収集を行うことは、管理者にとって負担が大きかった。
【０００７】
本発明は、上述の課題を解決するためになされたものであり、ストレージ装置の運用管理を行うストレージ管理装置の利便性を向上させることを目的とする。
【課題を解決するための手段】
【０００８】
上述の課題の少なくとも一部を解決するため、本発明では、以下の構成を採用した。すなわち、本発明の第１の装置は、ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置であって、前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶するシナリオ記憶部と、前記コマンドに基づいて、前記ストレージ装置の構成情報の収集の要否を判断する要否判断部と、前記収集が必要と判断されたときに、前記運用シナリオの実行に伴い、前記ストレージ装置の構成情報を収集するための構成情報収集ジョブを前記運用シナリオに挿入するシナリオ制御部と、を備えることを要旨とする。
【０００９】
シナリオ制御部は、運用シナリオに構成情報収集ジョブを挿入して更新するようにしてもよいし、運用シナリオの更新は行わずに、運用シナリオの実行時に構成情報収集ジョブを割り込ませるようにしてもよい。前者によれば、次回の運用シナリオ実行時には、構成情報収集ジョブが挿入された運用シナリオを実行することによって、構成情報の自動収集を行うことができる。後者によれば、運用シナリオ記憶部の容量の増大を抑制することができる。
【００１０】
本発明によって、運用シナリオを実行するに際し、ストレージ装置の構成情報の収集が必要な場合に、構成情報を自動収集するようにすることができる。したがって、先に説明した管理者の管理負担を軽減することができる。つまり、ストレージ管理装置の利便性を向上させることができる。
【００１１】
なお、収集した構成情報は、種々の利用が可能である。例えば、構成情報を運用シナリオに反映させたり、運用シナリオを正常に実行可能であるか否かをチェックし、警告を発したりするようにすることができる。
【００１２】
本発明の第２の装置は、ストレージ装置の運用手順を記述した所定の運用シナリオを実行することによって、前記ストレージ装置の運用管理を行うストレージ管理装置であって、前記ストレージ装置を制御するための所定のコマンドを含む前記運用シナリオを記憶するシナリオ記憶部と、前記運用シナリオを実行するときに、ユーザからの指示とは無関係に、前記ストレージ装置の構成情報を収集する構成情報収集部と、を備えることを要旨とする。
【００１３】
こうすることによって、運用シナリオを実行するに際し、ストレージ装置の構成情報を自動収集することができる。したがって、先に説明した管理者の管理負担を軽減することができる。つまり、ストレージ管理装置の利便性を向上させることができる。
【００１４】
本発明は、上述のストレージ管理装置としての構成の他、ストレージ管理装置の制御方法の発明として構成することもできる。また、これらを実現するコンピュータプログラム、およびそのプログラムを記録した記録媒体、そのプログラムを含み搬送波内に具現化されたデータ信号など種々の態様で実現することが可能である。
【００１５】
本発明をコンピュータプログラムまたはそのプログラムを記録した記録媒体等として構成する場合には、ストレージ管理装置の動作を制御するプログラム全体として構成するものとしてもよいし、本発明の機能を果たす部分のみを構成するものとしてもよい。また、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置などコンピュータが読み取り可能な種々の媒体を利用できる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態について、実施例に基づき以下の順序で説明する。
Ａ．ストレージ運用管理システムの構成：
Ｂ．管理サーバ（第１実施例）：
Ｃ．実行登録処理：
Ｄ．実行登録処理の変形例：
Ｅ．運用シナリオ実行処理：
Ｆ．第２実施例：
Ｇ．変形例：
【００１７】
Ａ．ストレージ運用管理システムの構成：
図１は、本発明の一実施例としてのストレージ運用管理システム１０００の構成を示す説明図である。本実施例のストレージ運用管理システム１０００は、管理サーバ１００と、業務サーバ２００と、ストレージ装置３００とを備えている。管理サーバ１００と、業務サーバ２００とは、ＬＡＮ（Local Area Network）を介して接続されている。また、業務サーバ２００と、ストレージ装置３００とは、ＳＡＮ（Storage Area Network）を介して、それぞれ接続されている。ＳＡＮは、ファイバーチャネル技術を利用した高速通信が可能なネットワークである。ＳＡＮの代わりに、インターネットや、ＬＡＮなど、他のネットワークを適用するようにしてもよい。
【００１８】
このストレージ運用管理システム１０００は、バックアップや、リストアなどストレージ装置３００の自動運用管理を行うシステムである。管理サーバ１００は、予め用意されたストレージ装置３００の運用手順を記述した運用シナリオを実行し、運用シナリオに含まれる運用ジョブの実行を業務サーバ２００に指示する。業務サーバは、管理サーバ１００から指示された、運用ジョブを実行する。管理サーバ１００は、本発明におけるストレージ管理装置に相当する。
【００１９】
管理サーバ１００は、ＣＰＵ１０や、ＲＡＭ２０や、記憶装置３０や、ＮＩＣ（ネットワーク・インタフェース・カード）４０を備えている。記憶装置３０は、ストレージ装置３００の運用管理を行うための種々のプログラムや、データを記憶している。ＮＩＣ４０は、ＬＡＮを介して他の機器と通信を行うためのインタフェースである。
【００２０】
業務サーバ２００は、ＣＰＵ２１０や、ＲＡＭ２２０や、記憶装置２３０や、ＮＩＣ２４０や、ＨＢＡ（ホスト・バス・アダプタ）２５０を備えている。記憶装置２３０は、管理サーバ１００から指示された運用ジョブを実行するための種々のプログラムや、データを記憶している。ＮＩＣ２４０、および、ＨＢＡ２５０は、それぞれＬＡＮ、および、ＳＡＮを介して他の機器と通信を行うためのインタフェースである。
【００２１】
ストレージ装置３００は、ＣＰＵや、メモリや、複数のディスクＤＫを備えるコンピュータであり、ディスクＤＫに大容量のデータを格納する。ＨＢＡ３１０は、ＳＡＮを介して他の機器と通信を行うためのインタフェースである。
【００２２】
ストレージ装置３００内の複数のディスクＤＫには、プライマリ・ボリュームと、セカンダリ・ボリュームとが論理的に構成されている。プライマリ・ボリュームは、ＳＡＮに接続された図示しないサーバが常時利用するデータを格納するボリュームである。セカンダリ・ボリュームは、プライマリ・ボリュームをバックアップするためのボリュームである。ストレージ装置３００は、バックアップ時やリストア時に、プライマリ・ボリュームとセカンダリ・ボリュームとの同期、および、分離のペア制御を行いつつ、両者間で高速にデータのコピーを行う。
【００２３】
図中に管理サーバ１００の記憶装置３０、および、業務サーバ２００の記憶装置２３０に記憶されているプログラム等を併せて示した。
【００２４】
記憶装置３０は、構成情報収集プログラム３２と、運用シナリオデータベース３４と、シナリオ編集プログラム３６と、ジョブ実行マネージャ３８と、後述するリフレッシュ要否対応表とを記憶している。構成情報収集プログラム３２は、業務サーバ２００の記憶装置２３０が記憶する構成情報データベース２３４から、ストレージ装置３００の構成情報を収集するためのプログラムである。シナリオ編集プログラム３６は、運用シナリオを編集するためのプログラムである。管理者は、シナリオ編集プログラム３６によって、運用シナリオの編集を行うことができる。また、シナリオ編集プログラム３６は、後述するように、必要に応じて運用シナリオを自動編集する機能も有している。編集された運用シナリオは、運用シナリオデータベース３４に格納される。ジョブ実行マネージャ３８は、運用シナリオを実行し、業務サーバ２００の記憶装置２３０が記憶するジョブ実行エージェント２３２に、運用ジョブの実行を指示するためのプログラムである。
【００２５】
記憶装置２３０は、ジョブ実行エージェント２３２と、構成情報データベース２３４とを記憶している。構成情報データベース２３４は、ストレージ装置３００の構成情報を格納している。ジョブ実行エージェント２３２は、ジョブ実行マネージャ３８からのジョブ実行指示に従って、運用ジョブを実行する。
【００２６】
Ｂ．管理サーバ（第１実施例）：
図２は、第１実施例の管理サーバ１００のソフトウェア構成を示す説明図である。ここでは、運用シナリオを自動編集するための構成についてのみ説明する。
【００２７】
運用シナリオデータベース３４は、複数の運用シナリオを格納しており、各運用シナリオは、先に説明したように、複数の運用ジョブによって構成されている。各運用ジョブは、ストレージ装置３００を制御するためのコマンドを含んでいる。このコマンドとしては、「ｂａｃｋｕｐ」や、「ｒｅｓｔｏｒｅ」や、「ｒｅｓｙｎｃ」などがある。「ｂａｃｋｕｐ」は、ストレージ装置３００に設定されたプライマリ・ボリュームからセカンダリ・ボリュームへのバックアップを行うためのコマンドである。「ｒｅｓｔｏｒｅ」は、セカンダリ・ボリュームからプライマリ・ボリュームへのリストアを行うためのコマンドである。「ｒｅｓｙｎｃ」は、プライマリ・ボリュームとセカンダリ・ボリュームとの再同期を行うためのコマンドである。
【００２８】
リフレッシュ要否対応表３７には、各コマンドと、リフレッシュの要否との対応関係が記されている。リフレッシュとは、ストレージ装置３００の構成情報を収集することを意味している。図示した例では、「○」は、リフレッシュが必要であることを示しており、「×」は、リフレッシュが不要であることを示している。例えば、バックアップ時には、バックアップ時のストレージ装置３００の構成情報が必須であるから、コマンド「ｂａｃｋｕｐ」に対しては、リフレッシュが必要であることを示す「○」が設定されている。このリフレッシュ要否対応表３７によって、後述する要否判断部３６ａは、リフレッシュの要否を容易に判断することができる。
【００２９】
シナリオ編集プログラム３６は、要否判断部３６ａと、シナリオ制御部３６ｂとを備えている。シナリオ制御部３６ｂは、シナリオ更新部３６ｃを備えている。要否判断部３６ａは、ストレージ装置３００の構成情報が変更された報告を受けたときに、運用シナリオに含まれるコマンドと、リフレッシュ要否対応表３７に基づいて、リフレッシュの要否を判断する。こうすることによって、要否判断部３６ａは、ストレージ装置の構成情報に変更があった場合に、リアルタイムでリフレッシュの要否判断を行うことができる。
【００３０】
シナリオ制御部３６ｂは、要否判断部３６ａによって、リフレッシュが必要と判断されたときに、リフレッシュを行うための「収集ジョブ」を運用シナリオの先頭に挿入する。この収集ジョブは、ジョブ実行マネージャ３８が運用シナリオを実行する時に、構成情報収集プログラム３２によって実行される。
【００３１】
シナリオ更新部３６ｃは、構成情報収集プログラム３２によって取得された構成情報に基づいて、各運用ジョブの内容を更新する。シナリオ更新部３６ｃは、例えば、ボリュームＡをボリュームＣにバックアップする運用シナリオが予め用意されている場合、ボリュームＡがボリュームＢに変更されたときに、この構成情報の変更を反映させて、ボリュームＢをボリュームＣにバックアップする運用シナリオに更新する。こうすることによって、構成情報の変更内容を運用シナリオに自動的に反映させることができる。したがって、先に説明した運用シナリオ実行時に、処理不能となったり、誤った処理がおこなわれたりするエラーを解消することができる。
【００３２】
Ｃ．実行登録処理：
図３は、実行登録処理の流れを示すフローチャートである。ストレージ装置３００の構成情報が変更された報告を受けたときに、管理サーバ１００のＣＰＵ１０が実行する処理である。
【００３３】
まず、ＣＰＵ１０は、運用シナリオの先頭の運用ジョブを参照する（ステップＳ１００）。次に、リフレッシュ要否対応表３７を参照して、当該運用ジョブに含まれるコマンドに対してリフレッシュが必要であると設定されているか否かを判断する（ステップＳ１１０）。リフレッシュが必要であると設定されている場合には（ステップＳ１１０：ＹＥＳ）、運用シナリオの先頭に収集ジョブを挿入し（ステップＳ１２０）、運用シナリオを実行登録し（ステップＳ１４０）、処理を終了する。
【００３４】
ステップＳ１１０において、リフレッシュが不要であると設定されている場合には（ステップＳ１１０：ＮＯ）、当該運用ジョブが最終ジョブであるか否かを判断する（ステップＳ１３０）。当該運用ジョブが最終ジョブでない場合には（ステップＳ１３０：ＮＯ）、ステップＳ１００に戻り、次の運用ジョブについて、同様の処理を行う。
【００３５】
ステップＳ１３０において、当該運用ジョブが最終ジョブである場合には（ステップＳ１３０：ＹＥＳ）、収集ジョブの挿入を行わずに、そのまま運用シナリオを実行登録し（ステップＳ１４０）、処理を終了する。
【００３６】
Ｄ．実行登録処理の変形例：
図４は、変形例としてのリフレッシュ要否対応表３７を示す説明図である。このリフレッシュ要否対応表３７には、コマンドごとのリフレッシュの要否とともに、運用シナリオにおける収集ジョブの挿入箇所も設定されている。本実施例では、挿入箇所として、運用シナリオの先頭と、運用ジョブの直前との２カ所が設定されている。要否判断部３６ａは、このリフレッシュ要否対応表３７に基づいて、リフレッシュの要否判断を行うとともに、収集ジョブの挿入箇所を決定する。こうすることによって、より適切なタイミングでリフレッシュを行うことができる。
【００３７】
図５は、変形例としての実行登録処理の流れを示すフローチャートである。本変形例では、運用シナリオの先頭に収集ジョブが挿入されているか否かを表すフラグ（以下、先頭フラグと呼ぶ）が用意されている。先頭フラグがＯＮのときには、運用シナリオの先頭に収集ジョブが挿入されていることを示している。先頭フラグがＯＦＦのときには、運用シナリオの先頭に収集ジョブが挿入されていないことを示している。本処理の初期状態では、運用シナリオの先頭に収集ジョブは挿入されておらず、先頭フラグはＯＦＦであるものとする。
【００３８】
まず、ＣＰＵ１０は、運用シナリオの先頭の運用ジョブを参照する（ステップＳ２００）。次に、リフレッシュ要否対応表３７を参照して、当該運用ジョブに含まれるコマンドに対してリフレッシュが必要であると設定されているか否かを判断する（ステップＳ２１０）。リフレッシュが必要であると設定されている場合には（ステップＳ２１０：ＹＥＳ）、収集ジョブの挿入箇所が当該運用ジョブの直前に設定されているか否かを判断する（ステップＳ２２０）。収集ジョブの挿入箇所が当該運用ジョブの直前に設定されている場合には（ステップＳ２２０：ＹＥＳ）、収集ジョブを当該運用ジョブの直前に挿入する（ステップＳ２５０）。収集ジョブの挿入箇所が運用シナリオの先頭に設定されている場合には（ステップＳ２２０：ＮＯ）、先頭フラグがＯＮであるか否かを判断する（ステップＳ２３０）。先頭フラグがＯＦＦである場合には（ステップＳ２３０：ＮＯ）、運用シナリオの先頭に収集ジョブを挿入して、先頭フラグをＯＮに切り換える（ステップＳ２４０）。
【００３９】
次に、当該運用ジョブが最終ジョブであるか否かを判断する（ステップＳ２６０）。当該運用ジョブが最終ジョブである場合には（ステップＳ２６０：ＹＥＳ）、運用シナリオを実行登録し（ステップＳ２７０）、処理を終了する。当該運用ジョブが最終ジョブでない場合には（ステップＳ２６０：ＮＯ）、ステップＳ２００に戻り、次の運用ジョブについて、同様の処理を行う。
【００４０】
また、ステップＳ２１０において、リフレッシュが不要であると設定されている場合（ステップＳ２１０：ＮＯ）と、ステップＳ２５０の収集ジョブの挿入後と、ステップＳ２３０において、先頭フラグがＯＮである場合（ステップＳ２３０：ＹＥＳ）にも、ステップＳ２６０に進む。
【００４１】
Ｅ．運用シナリオ実行処理：
図６は、運用シナリオ実行処理の流れを示すフローチャートである。運用シナリオの実行時刻になったときに、管理サーバ１００のＣＰＵ１０が実行する処理である。
【００４２】
まず、ＣＰＵ１０は、運用シナリオの先頭の運用ジョブを参照し（ステップＳ３００）。当該運用ジョブが収集ジョブであるか否かを判断する（ステップＳ３１０）。当該運用ジョブが収集ジョブである場合には（ステップＳ３１０：ＹＥＳ）、この収集ジョブを実行して、構成情報収集プログラム３２によって業務サーバ２００から構成情報を収集する（ステップＳ３２０）。次に、収集された構成情報に基づいて、構成情報の変更内容を反映させて、運用シナリオの内容を更新する（ステップＳ３３０）。そして、当該運用ジョブが最終ジョブであるか否かを判断する（ステップＳ３５０）。当該運用ジョブが最終ジョブである場合には（ステップＳ３５０：ＹＥＳ）、処理を終了する。当該収集ジョブが最終ジョブでない場合には（ステップＳ３５０：ＮＯ）、ステップＳ３００に戻り、次の運用ジョブを参照する。
【００４３】
ステップＳ３１０において、当該運用ジョブが収集ジョブでない場合には（ステップＳ３１０：ＮＯ）、当該運用ジョブを実行し（ステップＳ３４０）、ステップＳ３５０に進む。
【００４４】
以上説明した第１実施例の管理サーバ１００によれば、運用シナリオを実行するに際し、ストレージ装置３００の構成情報の収集が必要な場合に、構成情報を自動収集することができる。したがって、先に説明した管理者の管理負担を軽減することができる。つまり、ストレージ管理装置の利便性を向上させることができる。
【００４５】
Ｆ．第２実施例：
第１実施例の管理サーバ１００では、要否判断部３６ａによって、リフレッシュの要否を判断し、運用シナリオに収集ジョブを挿入するか否かを判断した。第２実施例の管理サーバでは、デフォルトで、つまり、ユーザからの指示や、リフレッシュの要否判断に関わらず、運用シナリオの実行時に、運用シナリオの先頭に収集ジョブを挿入する。
【００４６】
さらに、第２実施例の管理サーバは、要否判断部３６ａの代わりに、適否判断部を備え、また、リフレッシュ要否対応表３７の代わりに、運用シナリオに含まれるコマンドと、リフレッシュの適否との対応関係を記したリフレッシュ適否対応表を用いる。リフレッシュ適否対応表には、各コマンドについて、リフレッシュの適否が記されている。適否判断部は、運用シナリオに含まれるコマンドと、リフレッシュ適否対応表とに基づいて、リフレッシュの適否を判断し、運用シナリオにリフレッシュを行うことが不適当なコマンドが含まれる場合に、運用シナリオへの収集ジョブの挿入を禁止する。こうすることによって、リフレッシュを行うことが適当でない場合に、リフレッシュを行わないようにすることができる。
【００４７】
なお、リフレッシュ適否対応表の代わりに、リフレッシュを行うことが適当なコマンド、あるいは、リフレッシュを行うことが不適なコマンドのリストを用いるものとしてもよい。こうすることによっても、適否判断部は、このリストに基づいて、リフレッシュの適否を容易に判断することができる。
【００４８】
以上説明した第２実施例の管理サーバによれば、運用シナリオを実行するに際し、ストレージ装置３００の構成情報を自動収集することができる。したがって、先に説明した管理者の管理負担を軽減することができる。つまり、ストレージ管理装置の利便性を向上させることができる。
【００４９】
Ｇ．変形例：
以上、本発明のいくつかの実施の形態について説明したが、本発明はこのような実施の形態になんら限定されるものではなく、その要旨を逸脱しない範囲内において種々なる態様での実施が可能である。例えば、以下のような変形例が可能である。
【００５０】
Ｇ１．変形例１：
上記第１実施例では、判断部３６ａは、ストレージ装置３００の構成情報が変更された報告を受けたときに、リフレッシュの要否を判断するものとしたが、これに限られない。運用シナリオの実行時に、リフレッシュの要否を判断するようにしてもよい。この態様は、図６に示した運用シナリオ実行処理において、破線で示したタイミング（ステップＳ３００ａ）で、図３、あるいは、図５に示した実行登録処理を行う態様である。こうすることによって、ストレージ装置３００の構成情報に変更があるごとに要否判断を行う必要がないので、管理サーバ１００の処理負荷を軽減することができる。
【００５１】
Ｇ２．変形例２：
上記第１実施例では、リフレッシュの要否判断に、リフレッシュ要否対応表３７を用いるものとしたが、これに限られない。リフレッシュ要否対応表３７の代わりに、リフレッシュが必要なコマンド、あるいは、リフレッシュが不要なコマンドのリストを用いるものとしてもよい。こうすることによっても、要否判断部３６ａは、このリストに基づいて、リフレッシュの要否を容易に判断することができる。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施例としてのストレージ運用管理システム１０００の構成を示す説明図である。
【図２】第１実施例の管理サーバ１００のソフトウェア構成を示す説明図である。
【図３】実行登録処理の流れを示すフローチャートである。
【図４】変形例としてのリフレッシュ要否対応表３７を示す説明図である。
【図５】変形例としての実行登録処理の流れを示すフローチャートである。
【図６】運用シナリオ実行処理の流れを示すフローチャートである。
【符号の説明】
【００５３】
１０００...ストレージ運用管理システム
１００...管理サーバ
１０...ＣＰＵ
２０...ＲＡＭ
３０...記憶装置
３２...構成情報収集プログラム
３４...運用シナリオデータベース
３６...シナリオ編集プログラム
３６ａ...要否判断部
３６ｂ...シナリオ制御部
３６ｃ...シナリオ更新部
３７...リフレッシュ要否対応表
３８...ジョブ実行マネージャ
４０...ＮＩＣ
２００...業務サーバ
２１０...ＣＰＵ
２２０...ＲＡＭ
２３０...記憶装置
２３２...ジョブ実行エージェント
２３４...構成情報データベース
２４０...ＮＩＣ
２５０...ＨＢＡ
３００...ストレージ装置
３１０...ＨＢＡ
ＤＫ...ディスク
【図１】
2005190260.tif 000003
【図２】
2005190260.tif 000004
【図３】
2005190260.tif 000005
【図４】
2005190260.tif 000006
【図５】
2005190260.tif 000007
【図６】
2005190260.tif 000008