JP6051228B2 - 計算機システム、ストレージ管理計算機及びストレージ管理方法 - Google Patents

Description

本発明は、ストレージ装置を含む計算機システムに関し、特にシステムの状態改善のための対策技術に関する。

近年、シンプロビジョニングと呼ばれる技術がストレージシステムにおいて盛んに用いられてきている。特許文献１には、シンプロビジョニングにおけるプールの容量監視方法が開示されている。ストレージ装置または管理サーバが、ストレージプールに属する物理ボリュームの記憶領域から、業務サーバにシンプロビジョニングボリュームを提供する。管理サーバは、ストレージプールの使用容量を監視し、業務サーバが所定の期間稼動するために必要な記憶容量が、ストレージプールに存在するか否かを判定し、必要な記憶容量が存在しない場合には所定の対策を行う。

また、特許文献２には、複数の仮想領域で構成された仮想的な論理ボリューム（以下、ＶＶＯＬと呼ぶ）の状況を管理し、不適切な状況にあるＶＶＯＬの状況改善のためにＶＶＯＬに関連付けられているプールに関わるマイグレーションを行う技術が開示されている。

特開２００８−０９７５０２号公報 国際公開第２０１１０９２７３８号パンフレット

計算機システムの運用管理において、ストレージシステムの状態を改善するための対策案を生成した後、例えば実際に採用する対策案の選定や、上位管理者による対策実行の承認作業などの都合により、状態の改善が必要と判断されてから実際に対策を実行するまでに一定の時間を要することが考えられる。

その間も、通常業務、すなわちホスト計算機からストレージシステムへのＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）発行は継続して行われるために、実際の対策実行までにストレージシステムの状態が変化し、変化前の状態に基づいて生成された対策案によっては期待する効果が得られなくなる場合がある。

本発明は、ストレージシステムの状態の変化を考慮した対策案の生成を目的の１つとする。

本発明の提供する管理計算機は、ストレージ装置によりホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第１の要求性能を示す情報を含む仮想論理ボリューム管理情報と、ストレージ装置により提供される、データの物理的な記憶領域群で構成され、ホスト計算機からのライトアクセスに応じて仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプールの使用状況に関する情報を示す、プール管理情報とをメモリに格納する。管理計算機のプロセッサが、ストレージ装置へのアクセスに関する性能情報をホスト計算機より取得し、取得したアクセスに関する性能情報が、前記第１の要求性能を満たすか否かを判断し、第１の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第１の要求性能を示す情報を含む仮想論理ボリューム管理情報に基づいて状態の原因である仮想論理ボリュームを特定する。プール管理情報に基づき、各プールに含まれるデータの物理的な記憶領域の容量消費傾向を算出し、特定した仮想論理ボリュームの情報と、算出した容量消費傾向とに基づいて、所定の時間後に実施し得る前記第１の要求性能が満たされるための複数の対策案を生成し、出力装置に出力する。

本発明によれば、ストレージシステムの状態の変化を考慮した効果的な対策案を生成することができる。

図１は、実施例１に係る計算機システムの構成を示す。 図２は、実施例１に係る計算機システムの概念図を示す。 図３は、実施例１に係るプール管理テーブルを示す。 図４は、実施例１に係るＶＯＬ管理テーブルを示す。 図５は、実施例１に係るＶＶＯＬ管理テーブルの一部を示す。 図６は、実施例１に係るＶＶＯＬ管理テーブルの残りを示す。 図７は、実施例１に係るプール容量消費傾向管理テーブルを示す。 図８は、実施例１に係るポート負荷傾向管理テーブルを示す。 図９は、実施例１に係るＴｉｅｒ定義管理テーブルを示す。 図１０は、実施例１に係るタスク実行権限管理テーブルを示す。 図１１は、実施例１に係る生成中対策案管理テーブルを示す。 図１２は、実施例１に係る自動実行判定管理テーブルを示す。 図１３は、実施例１に係る対策案生成処理のフローチャートである。 図１４は、実施例１に係るプール別対策案生成処理のフローチャートである。 図１５は、実施例１に係る対策案効果算出処理のフローチャートである。 図１６は、実施例１に係る実行推奨度算出処理のフローチャートである。 図１７は、実施例１に係る自動実行可否判定処理のフローチャートである。 図１８は、実施例１に係る自動実行最終時間判定処理のフローチャートである。 図１９は、実施例１に係る対策案実行予定時間指定インタフェースを示す。 図２０は、実施例１に係る対策案一覧提示インタフェースの例を示す。 図２１は、実施例１に係る対策案一覧提示インタフェースの別の例を示す。 図２２は、実施例２に係る生成中対策案管理テーブルを示す。 図２３は、実施例２に係る対策案生成処理のフローチャートである。 図２４は、実施例２に係る対策案一覧提示インタフェースを示す。 図２５は、実施例３に係る生成中対策案管理テーブルを示す。 図２６は、実施例３に係る実行タスク選択インタフェースを示す。

幾つかの実施例について、図面を参照して説明する。なお、以下に説明する実施例は請求の範囲にかかる発明を限定するものではなく、また実施例の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。さらに、テーブル内の各列の値からなる情報要素をエントリと呼び、「ａａａテーブル」のエントリを、説明のために、「ａａａテーブルエントリ」と称する。

また、以下の説明では、単に管理計算機及びホスト計算機を主語として処理を説明する場合があるが、これら処理は、計算機が備える制御デバイスが有するプロセッサ（例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって、実行されていることを示す。同様に、単にストレージ装置を主語として処理を説明する場合には、ストレージ装置が備えるコントローラが実行していることを示す。また、上記制御デバイス及びコントローラのうちの少なくとも１つは、プロセッサそれ自体であっても良いし、制御デバイス又はコントローラが行う処理の一部又は全部を行うハードウェア回路を含んでも良い。

プログラムは、プログラムソースから各計算機或いはストレージシステムにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。

図１は、実施例１の計算機システムの構成を示す。

ストレージ装置１０２が、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの第１の通信ネットワーク２３１を介して、管理計算機２０１及びホスト計算機１０１に接続されている。また、ストレージ装置１０２は、例えばＳＡＮなどの第２の通信ネットワーク２３２を介して、ホスト計算機１０１に接続されている。なお、第１の通信ネットワーク２３１、及び第２の通信ネットワーク２３２は一体に形成されても良い。

ストレージ装置１０２は、物理記憶デバイス群と、物理記憶デバイス群に接続されたコントローラ２５１とを有する。物理記憶デバイス群は、１以上の物理記憶デバイスより構成される。物理記憶デバイス群としては、図２で示す通りＳＳＤ群３０９Ａ、ＳＡＳ群３０９Ｂ及びＳＡＴＡ群３０９Ｃがある。ＳＳＤ群３０９Ａは、１以上のＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）であり、ＳＡＳ群３０９Ｂは、１以上のＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）−ＨＤＤであり、ＳＡＴＡ群３０９Ｃは、１以上のＳＡＴＡ（Ｓｅｒｉａｌ ＡＴＡ（Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ））−ＨＤＤである。このように、ストレージ装置２０３は、性能の異なる複数の物理記憶デバイスが混在している。なお、物理記憶デバイス群は、ストレージ装置１０２の外部から提供されるものであっても良い。

コントローラ２５１は、管理Ｉ／Ｆ（以下、Ｍ−Ｉ／Ｆと記載）２４１と、通信Ｉ／Ｆ２４２（以下、Ｃ−Ｉ／Ｆと記載）２４２と、デバイスＩ／Ｆ（以下、Ｄ−Ｉ／Ｆと記載）２４５と、メモリ２４３と、それらに接続されたプロセッサ２４４とを有する。

Ｍ−Ｉ／Ｆ２４１は、第１のプロトコルで通信するための通信インタフェース装置であり、例えば、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）である。Ｃ−Ｉ／Ｆ２４２は、第２のプロトコルで通信するための通信インタフェース装置である。

Ｄ−Ｉ／Ｆ２４５は、第３のプロトコルで物理記憶デバイスと通信するための通信インタフェース装置である。Ｄ−Ｉ／Ｆ２４５は、物理記憶デバイスの種類毎に有していても良い。コントローラ２５１は、Ｄ−Ｉ／Ｆ２４５を介して、物理記憶デバイスに対してアクセスをする。

メモリ２４３は、プロセッサ２４４で実行されるコンピュータプログラムや、種々の情報を記憶する。また、メモリ２４３は、キャッシュメモリ領域を有する。キャッシュメモリ領域には、ホスト計算機１０１から受けたライトコマンドに従うデータや、ホスト計算機１０１から受けたリードコマンドに応答して、物理記憶デバイス上の実データ保存領域（以下、ページと呼ぶ）から読み出されたデータが一時格納される。キャッシュメモリ領域内のライト対象のデータは、ライト先の仮想領域に割り当てられた物理記憶デバイスに格納される。キャッシュメモリ領域内のリード対象のデータは、ホスト計算機１０１に提供される。

メモリ２４３には、プール管理テーブル３０２、ＶＯＬ管理テーブル３０４、プール管理プログラム３０５が記憶される。プール管理プログラム３０５は、ストレージシステム１０２が有する後述のプール１０７を管理するためのプログラムである。プール管理プログラム３０５は、プロセッサ２４４に実行され、各種テーブルに基づき、各種処理が実現される。

なお、１以上のストレージ装置１０２の集合によって、後述のストレージシステム１０３が構成される。

ホスト計算機１０１は、Ｍ―Ｉ／Ｆ２２４と、Ｃ―Ｉ／Ｆ２２６と、記憶資源２２１と、それらに接続されたプロセッサ２２２と、Ｉ／Ｏデバイス２２３とを含んで構成される。Ｍ−Ｉ／Ｆ２２４は例えばＮＩＣであり、Ｃ−Ｉ／Ｆ２２６は例えばＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）である。記憶資源２２１は、例えば、メモリであり、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の補助記憶装置を含んでも良い。記憶資源２２１は、例えば、業務プログラムなどのアプリケーションプログラムやＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を記憶し、プロセッサ２２２が、そのアプリケーションプログラムやＯＳを実行する。Ｉ／Ｏデバイス２２３としては、ユーザからの入力を受け付ける入力部（例えば、キーボード、スイッチ、ポインティングデバイス及び／又はマイクロフォン等）と各種情報をユーザに対して表示する出力部（例えば、ディスプレイ装置及び／又はスピーカ等）とを有する。

管理計算機２０１は、Ｍ−Ｉ／Ｆ２１４と、記憶資源２１１と、それらに接続されたプロセッサ２１２と、Ｉ／Ｏデバイス２１３とを含んで構成される。Ｍ−Ｉ／Ｆ２１４は、例えばＮＩＣである。Ｉ／Ｏデバイス２１３は、Ｉ／Ｏデバイス２２３と同様である。

記憶資源２１１は、例えば、メモリであり、ＨＤＤ等の補助記憶装置を含んでも良い。記憶資源２１１は、コンピュータプログラムや種々の情報を記憶する。コンピュータプログラムは、プロセッサ２１２で実行される。記憶資源２１１には、情報としてＶＶＯＬ管理テーブル８０１、プール容量消費傾向管理テーブル８０２、ポート負荷傾向管理テーブル８０３、ティア定義管理テーブル８０４、タスク実行権限管理テーブル８０６、生成中対策案管理テーブル８０７、自動実行判定管理テーブル８０８が記憶され、プログラムとして、状態監視プログラム８１０、対策案生成プログラム８１１が記憶される。

以上が、実施例１に係る計算機システムのハードウェア等構成である。なお、前述のＭ−Ｉ／Ｆ、Ｃ−Ｉ／Ｆなどの通信インタフェースデバイスは、例えば、そのＩ／Ｆが接続されるネットワークの種類や、そのＩ／Ｆを有する装置の種類によって異なる。

図２は、実施例１に係る計算機システムの概念図である。

ストレージシステム１０３は、１以上のストレージ装置１０２で構成される。ストレージ装置１０２のうちの少なくとも１つが、シンプロビジョニング技術が適用されたストレージ装置である。ストレージシステム１０３は、物理記憶デバイスの実領域から構成された性能の異なる複数の論理ボリューム（以下、ＬＤＥＶと呼ぶ）を有する。

本実施例では、３種類のＬＤＥＶの集合を考える。具体的には、ＳＳＤから構成されるＬＤＥＶ１０９Ａと、ＳＡＳから構成されるＬＤＥＶ１０９Ｂと、ＳＡＴＡから構成されるＬＤＥＶ１０９Ｃとがある。

なお、ストレージシステム１０３が有する論理ボリュームの集合は、例えば、これら３つの集合のうちの少なくとも１つが別種の論理ボリュームの集合であっても良い。また、論理ボリュームの集合の数は、２以上であれば良い。例えば、同種の論理ボリュームが、アクセス性能に応じて２以上の異なる集合に分けられても良い。例えば、ＳＡＳから構成されるＬＤＥＶ１０９Ｂは、ＳＡＳ［１０Ｋ／ｒｐｍ］（回転数が１０、０００［回転／分］のＳＡＳ）から構成される集合と、ＳＡＳ［１５Ｋ／ｒｐｍ］（回転数が１５、０００［回転／分］のＳＡＳ）から構成される集合とに分けられても良い。また、プール１０７を有するストレージ装置とは別のストレージ装置から提供された論理ボリュームであっても良い。

ストレージシステム１０３は、１以上のプール１０７を有する。各プール１０７は、性能の異なる複数のＬＤＥＶで構成されている。例えば、各プール１０７は、ＳＳＤから構成されるＬＤＥＶ１０９Ａのうちの１以上のＬＤＥＶと、ＳＡＳから構成されるＬＤＥＶ１０９Ｂのうちの１以上のＬＤＥＶと、ＳＡＴＡから構成される１０９Ｃのうちの１以上のＬＤＥＶとで構成されている。各ＬＤＥＶが、複数のページに区切られている。このため、各プール１０７は、ＳＳＤページ群と、ＳＡＳページ群と、ＳＡＴＡページ群とで構成されていることになる。各ＬＤＥＶは、１つのプールの構成要素となり、２以上のプールの共通の構成要素とならないで良い。なお、図２における、プール１０７と各ＬＤＥＶ１０９との間の結線は、物理的な接続を意味するものではなく、上述の通りプール１０７がＬＤＥＶ１０９から構成されることを示している。

なお、１つのプール１０７には、複数のティアがある。１つのティアは、同じ性能の１以上のＬＤＥＶで構成される。例えば、上位のティアとして、ＳＳＤで構成されたティアがあり、中位のティアとして、ＳＡＳで構成されたティアがあり、下位のティアとして、ＳＡＴＡで構成されたティアがある。なお、「同じ性能」とは、完全に同じ性能であっても良いし、例えば、アクセス性能の差が所定の差以下であるなど、実質的にほぼ同じ性能の場合を含んで良い。

各ティアには、アクセス頻度範囲が関連付けられる。アクセス頻度は、単位時間当りのアクセスの数であり、例えば、ＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）で表される。なお、ＩＯＰＳは、１秒間当たりに行われるアクセス（Ｉ／Ｏ）の数の単位である。

ストレージシステム１０３は、複数のＶＶＯＬ１０５を有する。ＶＶＯＬ１０５は、シンプロビジョニング技術に従う仮想的な論理ボリュームであり、複数の、仮想的な記憶領域である仮想領域で構成されている。仮想領域は、例えば、ＬＢＡ（Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓｉｎｇ）などのアドレスである。ストレージシステム１０３は、ホスト計算機１０１からＶＶＯＬ１０５を指定したライトコマンドを受信した場合、そのライトコマンドから特定されるライト先の仮想領域に、実領域であるページが割り当てられていれば、当該ページにデータを書き込み、ページが割り当てられていなければ、そのライト先のＶＶＯＬ１０５が関連付けられているプールから、未使用のページを割り当て、その割り当てたページに、そのライトコマンドに従うライト対象のデータを書き込む。

ホスト計算機１０１は、ストレージシステム１０３へのアクセス元の一例である。ホスト計算機１０１は、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）１１１を論理的に生成してＶＭ１１１を実行できるハイパーバイザ１１２を有する。ハイパーバイザは一度に複数のＶＭ１１１を制御することができる。複数のＶＭ１１１の夫々は、あたかもスタンドアローンの物理計算機のようにアプリケーションを実行できる。また、ハイパーバイザ１１２は、あるホスト上で稼働しているＶＭ１１１を他のホストに移動するＶＭマイグレーションを行うことができる。

ＶＶＯＬ１０５は、複数のＶＭ１１１のうちのいずれか１つのＶＭ１１１に提供される。実施例１では、ＶＶＯＬ１０５とＶＭ１１１が１対１で対応する。なお、図２における、ホスト計算機１０１とＶＶＯＬ１０５との間の結線は、物理的な接続を意味するものではなく、ＶＶＯＬ１０５がホスト計算機１０１に提供され、ホスト計算機１０１から認識されていることを示す。同様に、プール１０７とＶＶＯＬ１０５との間の結線も、物理的な接続を意味するものではなく、ＶＶＯＬ１０５がプール１０７に関連付けられていることを示す。

ホスト計算機はＶＭ１１１のリクエストに従い、提供されたＶＶＯＬ１０５にアクセスする。具体的には、ホスト計算機１０１は、アクセス先情報を有するアクセスコマンドを、ストレージシステム１０３に送信する。アクセス先情報は、アクセス先を表す情報であり、例えば、ＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）などのＶＶＯＬ１０５のＩＤと、ＬＢＡなどの仮想領域のＩＤとを含んでいる。

図３は、プール管理テーブル３０２を示す。プール管理テーブル３０２は、プール１０７の情報を格納する。プール管理テーブル３０２により、プールを構成するＬＤＥＶ及びＬＤＥＶの属するティア、各ページと仮想領域との対応関係、ページ毎のＩＯＰＳなどが分かる。コントローラ２５１は、定期的に、または外部からの情報収集要求の受け付けを契機として、ストレージ装置１０３の各構成要素より情報を収集し、プール管理テーブル３０２に格納する。

具体的に、プール管理テーブル３０２は、以下の情報を有する。プールＩＤ５０１は、プール１０７を識別するための情報である。ページＩＤ５０２は、プール１０７に属するページを識別するための情報である。ＬＤＥＶ ＩＤ５０３は、ページを有するＬＤＥＶを識別するための情報である。ティアレベル５０４は、ＬＤＥＶが属するティアのレベルを表す情報である。アクセス頻度限界５０５は、ＬＤＥＶに対するアクセス頻度の上限値を示す情報である。図３では、アクセス頻度限界５０５は、ＬＤＥＶへの単位時間内のＩ／Ｏ数（ＩＯＰＳ）の上限として示されている。ＬＤＥＶアクセス頻度５０６は、ＬＤＥＶへのアクセス頻度を示す情報である。図３では、ＬＤＥＶアクセス頻度５０６は、ＬＤＥＶへの単位時間内のＩ／Ｏ数（ＩＯＰＳ）を示す。ＬＤＥＶ ＬＢＡ５０７は、ＬＤＥＶにおけるページの位置（例えば、ページの先頭のＬＢＡとそのページの末端のＬＢＡ）を示す情報である。

ＶＶＯＬ ＩＤ５０８は、ページの割当先の仮想領域を有するＶＶＯＬを識別するための情報である。「Ｎ／Ａ（Ｎｏｔ／Ａｓｓｉｇｎｅｄ）」は、ページがどの仮想領域にも割り当てられていないことを示す。ＶＶＯＬ ＬＢＡ５０９は、ページの割当先の仮想領域の位置（例えば、仮想領域の先頭のＬＢＡとその仮想領域の末端のＬＢＡ）を示す情報である。ページアクセス頻度５１０は、ページに対するアクセスの頻度を示す情報である。アクセス頻度は、「ライトの頻度」と、「リードの頻度」とに分けて管理されても良い。アクセス頻度は、ページに対するアクセスが行われた場合に更新され、アクセスコマンドを受けたもののページに対するアクセスが行われなかった場合には、更新されない。

図４は、ＶＯＬ管理テーブル３０４を示す。ＶＯＬ管理テーブル３０４は、ストレージシステム１０３が有するボリュームに関する情報を有する。ＶＯＬ管理テーブル３０４は、ストレージシステム１０３がホスト計算機１０１に提供可能なボリュームの情報を格納しており、情報が格納される対象はストレージシステム１０３が有する全てのボリュームであっても、その一部のみであってもよい。ＶＯＬ管理テーブル３０４により、ボリュームがＶＶＯＬである場合、そのＶＶＯＬが仮想領域を提供するホスト計算機１０１、そのＶＶＯＬにページを割り当てているプール１０７が分かる。

ＶＯＬ ＩＤ７０１は、ＶＶＯＬ又はＬＤＥＶを識別するための情報である。容量７０２は、ＶＶＯＬ又はＬＤＥＶの記憶容量を示す。ボリュームタイプ７０３は、ボリュームのタイプが、ＶＶＯＬ又はどのＬＤＥＶであるかを示す。ボリュームがＬＤＥＶである場合、ボリュームタイプ７０３は、ＳＳＤ、ＳＡＳ、或いはＳＡＴＡを示す。ポートＩＤ７０４は、ＶＶＯＬに関連づけられているストレージポートを識別するための情報である。ホストＩＤ７０５は、ボリュームの提供先のホスト計算機を識別するための情報である。図４の例では、ＬＤＥＶ１、ＬＤＥＶ２は、ホスト計算機１０１に直接割り当てられていない。プールＩＤ７０６は、ＶＶＯＬに関連付けられたプールを識別するための情報である。

プール管理プログラム３０５は、プール管理テーブル３０２及びＶＯＬ管理テーブル３０４に基づいて、例えば、以下の処理を行う。
（Ａ）プール管理プログラム３０５は、以下の（ａ１）〜（ａ９）の処理を含んだライト処理を行う。
（ａ１）ホスト装置１０１からのライトコマンドを受け付ける。
（ａ２）ライトコマンドに含まれるアクセス先情報を基に、ライト先ＶＶＯＬとライト先仮想領域を特定する。
（ａ３）ライトコマンドに従うライト対象のデータをキャッシュメモリ領域に格納する。この時点で、ホスト装置１０１にライト完了と応答して良い。
（ａ４）プール管理テーブル３０２を参照して、上記（ａ２）で特定されたライト先仮想領域にページが割り当てられているかを判断する。
（ａ５）上記（ａ４）の判断の結果が肯定的であれば、プール管理プログラム３０５ライト先仮想領域に割り当てられているページに、キャッシュメモリ領域内のライト対象のデータを書き込む。
（ａ６）上記（ａ４）の判断の結果が否定的であれば、ＶＯＬ管理テーブル３０４と、プール管理テーブル３０２とに基づき、ライト先ＶＶＯＬに関連付けられているプールにおける、どの仮想領域にも割り当てられていないページ未使用のページを特定する。ここで、なるべく上位の階層に属するＬＤＥＶから未使用のページを特定して良い。
（ａ７）（ａ６）で特定したページをライト先仮想領域に対応付ける。具体的には、プール管理プログラム３０５は、プール管理テーブル３０２のＶＶＯＬ ＬＢＡ５０６に、割り当てたページに対応するライト先仮想領域の先頭ＬＢＡ及び末端ＬＢＡを書き込む。
（ａ８）上記（ａ６）で特定したページに、キャッシュメモリ領域内のライト対象のデータを書き込む。この段階で、ホスト装置１０１にライト完了と応答しても良い。
（ａ９）上記（ａ５）又は（ａ８）において、プール管理テーブル３０２における、データの書込み先のページのアクセス頻度を更新する。また、それに伴い、プール管理プログラム３０５は、プール管理テーブル３０２における、そのページを有するＬＤＥＶのアクセス頻度を更新する。

（Ｂ）プール管理プログラム３０５は、以下の（ｂ１）〜（ｂ８）の処理を含んだリード処理を行う。
（ｂ１）ホスト装置１０１からのリードコマンドを受け付ける。
（ｂ２）リードコマンドに含まれるアクセス先情報を基に、リード元ＶＶＯＬとリード元仮想領域を特定する。
（ｂ３）リード対象のデータがキャッシュメモリ領域に残っているか否かを判断する。
（ｂ４）上記（ｂ３）の判断の結果が肯定的の場合、プール管理プログラム３０５は、キャッシュメモリ領域内のリード対象データを、ホスト装置１０１に送信する。この場合、リード元仮想領域に割り当てられているページのアクセス頻度（及び、そのページを有するＬＤＥＶのアクセス頻度）は、更新されない。
（ｂ５）上記（ｂ３）の判断の結果が否定的の場合、プール管理プログラム３０５は、プール管理テーブル３０２を参照して、上記（ｂ２）で特定されたリード元仮想領域にページが割り当てられているかを判断する。
（ｂ６）上記（ｂ５）の判断の結果が否定的であれば、プール管理プログラム３０５は、所定のデータ（例えばエラー応答）をホスト装置１０１に送信する。
（ｂ７）上記（ｂ５）の判断の結果が肯定的であれば、プール管理プログラム３０５は、リード元仮想領域に割り当てられているページからデータを読み出し、そのデータをキャッシュメモリ領域に書き込む。そして、キャッシュメモリ領域内のそのデータをホスト装置１０１に送信する。
（ｂ８）プール管理プログラム３０５は、上記（ｂ６）において、プール管理テーブル３０２における、データの書込み先のページのアクセス頻度を更新する。また、それに伴い、プログラムは、プール管理テーブル３０２における、そのページを有するＬＤＥＶのアクセス頻度を更新する。

（Ｃ）プール管理プログラム３０５は、以下の（ｃ１）〜（ｃ３）の処理を含んだＬＤＥＶ追加処理（プール拡張）を行う。なお、（ｃ３）の後に、後述の（Ｅ）リバランス処理が行われて良い。
（ｃ１）追加対象のＬＤＥＶにＬＤＥＶ ＩＤを付与する。
（ｃ２）追加対象のＬＤＥＶをページに分割し、分割により得られた各ページにＰａｇｅ ＩＤを付与する。
（ｃ３）追加対象のＬＤＥＶに関する情報（ＬＤＥＶの追加先のプールのＩＤ、（ｃ１）で付与されたＬＤＥＶ ＩＤ、（ｃ２）で付与されたページＩＤ等）を、プール管理テーブル３０２に追加する。
（Ｄ）プール管理プログラム３０５は、以下の（ｄ１）及び（ｄ２）の処理を含んだＬＤＥＶ削除処理（プール縮小）を行う。
（ｄ１）削除対象のＬＤＥＶ内の全ての使用ページ（いずれかの仮想領域に割り当てられているページ）内のデータを他のＬＤＥＶにマイグレーションするリバランス処理を実行する。
（ｄ２）削除対象のＬＤＥＶに関する情報を、プール管理テーブル３０２から削除する。

（Ｅ）プール管理プログラム３０５は、以下の（ｅ１）〜（ｅ４）の処理を含んだリバランス処理を行うことができる。その場合、例えば、メモリ２４３は、管理計算機２０１が有する後述のティア定義管理テーブル８０４を有していて良い。このリバランス処理は、定期的に行われて良い。また、このリバランス処理は、上記（ｄ１）でのリバランス処理に適用されて良い。
（ｅ１）プール管理プログラム３０５は、不適切に配置されているデータが記憶されているページをマイグレーション元のページとして特定する。具体的には、ページのアクセス頻度がそのページを有する階層のアクセス頻度範囲に含まれないページをプール管理テーブル３０２より検索する。なお、マイグレーション元のページは、上記（ｄ１）のリバランス処理では、削除対象のＬＤＥＶ内の使用ページである。
（ｅ２）上記（ｅ１）で見つけたマイグレーション元ページのアクセス頻度５０５が属するアクセス頻度範囲に対応した階層を特定する。
（ｅ３）上記（ｅ２）で特定した階層から、未使用のページを特定する。ここで特定された未使用のページが、マイグレーション先のページである。
（ｅ４）上記（ｅ１）で特定したマイグレーション元ページ内のデータを、上記（ｅ３）で特定したマイグレーション先ページにマイグレーションする。また、プール管理プログラム３０５は、マイグレーション元ページが割り当てられている仮想領域に、マイグレーション元ページに代えて、マイグレーション先ページを割り当て、プール管理テーブル３０２を更新する。

図５、図６は、ＶＶＯＬ管理テーブル８０１を示す。ＶＶＯＬ管理テーブル８０１は、ＶＶＯＬに関する情報を有する。ＶＶＯＬ管理テーブル８０１により、各ＶＶＯＬを使用しているＶＭ、各ＶＶＯＬに要求される要求性能、及び各ＶＶＯＬの仮想領域にページを提供しているプールが分かる。

ＶＶＯＬ管理テーブル８０１は、ＶＶＯＬ毎に、下記情報を有する。ＶＶＯＬ ＩＤ９０１は、ＶＶＯＬを識別するための情報である。サブシステムＩＤ９０２は、ＶＶＯＬを有するストレージ装置１０２を識別するための情報である。容量９０３は、ＶＶＯＬの容量を表す情報である。使用容量９０４は、ページが割り当てられている仮想領域の総記憶容量を表す情報である。プールＩＤ９０５は、ＶＶＯＬに関連付けられているプールを識別するための情報である。ポートＩＤ９０６は、ＶＶＯＬに関連づけられているストレージポートを識別するための情報である。ホストＩＤ９０７は、ＶＶＯＬが割り当てられているホスト計算機１０１を識別するための情報である。ＶＭ ＩＤ９０８は、ＶＶＯＬが割り当てられているＶＭを識別するための情報である。ＶＭ稼働時間９０９は、ＶＭが稼働している時間帯を示す情報である。要求性能９１０は、ＶＭがボリュームにアクセスする際に求められる応答性能を示す情報である。

許容ダウンタイム９１１は、ＶＭに関して許容されるダウンタイムである。ここでいうダウンタイムとは、ＶＭがボリュームにアクセスすることが完全にできなくなることだけでなく、応答性能が要求性能よりも遅延している状態が続いている時間も含む。許容コスト９１２は、ＶＭに関して、状態改善のための対策にかけることが認められているコストである。具体的な金額ではなく、Ｈｉｇｈ、Ｍｉｄｄｌｅ、Ｌｏｗ、といった相対的な値を記載してもよい。時間９１３は、計測時間帯を示す情報である。ＶＭ性能９１４は、ＶＭの応答性能を表す情報である。ＶＶＯＬ性能９１５は、ＶＶＯＬの応答性能を表す情報である。アクセス分布９１６は、アクセス頻度範囲毎に、そのアクセス頻度範囲に該当するページの総数を表す情報である。図６では、アクセス頻度範囲は、ＩＯＰＳの数値範囲を２５０毎に区切ってカウントしているが、１以上で整数であればこれに限定されない。状態監視プログラム８１０が、ストレージシステム１０３の有するプール管理テーブル３０２を基に、ＶＶＯＬ毎のアクセス分布を算出することができる。新規ページ割り当て容量９１７は、計測時間帯にＶＶＯＬに新規に割り当てられたページ割り当て総容量を示す情報である。ポート負荷９１８は、計測時間帯にＶＶＯＬにアクセスするために使用したポートにかかる負荷を示す情報である。

ここで要求性能９１０は、ＶＭ性能９１４と比較される閾値である。要求性能９１０は、ＶＭがストレージ装置に格納されたデータにアクセスする際に満たされるべきレスポンスタイムが登録される。例えば、ＶＭがＶＶＯＬを指定したアクセスコマンドを発行してからその応答をＶＭが受け取るまでの時間長である。ＶＶＯＬ性能９１５は、ＶＶＯＬの平均のレスポンスタイムである。例えば、ＶＶＯＬを指定したアクセスコマンドがストレージ装置１０２に入ってから応答がホスト装置１０１に返されるまでの時間長である。

要求性能９１０は例えば管理者がＶＭの使用状況等を考慮して決定する。ＶＶＯＬの平均レスポンスタイムは、例えば、状態監視プログラム８０１が下記の（１）式により算出して、ＶＶＯＬ管理テーブル８０１に格納する。

（ＶＶＯＬの平均レスポンスタイム）＝（ＶＶＯＬに割り当てられている全てのページについての、アクセス頻度とレスポンスタイムの積の和）／（ＶＶＯＬに割り当てられている全てのページについてのアクセス頻度の和）・・・（１）。ここで、アクセス頻度の単位は、例えば、ＩＯＰＳである。

例えば、ＶＶＯＬにページ１〜６が割り当てられているとする。ページ１〜６のそれぞれについて、「ページが属する階層／その階層でのアクセス速度［ｍｓｅｃ］／ページのアクセス頻度［ＩＯＰＳ］」は、次の通りであるとする。ページ１：上位階層（ＳＳＤ）／１／１００、ページ２：中位階層（ＳＡＳ）／１０／５０、ページ３：中位階層（ＳＡＳ）／１０／２０、ページ４：下位階層（ＳＡＴＡ）／２０／１０、ページ５：下位階層（ＳＡＴＡ）／２０／５、ページ６：下位階層（ＳＡＴＡ）／２０／０。

この場合、（１）式によれば、ＶＶＯＬの平均レスポンスタイムＫは、
Ｋ＝（１００×１＋５０×１０＋２０×１０＋１０×２０＋５×２０＋０×２０）／（１００＋５０＋２０＋１０＋１５）＝約５．３７ｍｓ
となる。アクセス速度は、後述のティア定義管理テーブル８０４から取得する。

このようにして求められた平均レスポンスタイム（性能）は、要求性能９１０から求められるＶＶＯＬについての要求応答性能と比較される。ＶＶＯＬ性能９１５には、ホストとストレージ装置間のデータ転送にかかる時間は含まれないため、環境に応じたデータ転送時間を考慮してＶＶＯＬの要求応答性能を算出する。例えば、あるＶＭの要求性能が５ｍｓと指定されているとする。ＶＭがＶＶＯＬに対するアクセスコマンドを発行してからその応答をホストが受け取るまでの時間長のうち、ＶＭとストレージ装置間のデータ転送にかかる時間として２０％が必要とされる場合、期待されるＶＶＯＬのレスポンスタイムＬは、
Ｌ＝５ｍｓ×（１００−２０）÷１００ ＝４ｍｓ
となる。

ＶＭがＶＶＯＬに対するアクセスコマンドを発行してからその応答をホスト計算機１０１が受け取るまでの時間が８ｍｓだったとする。ＶＶＯＬ性能９１５に登録された平均レスポンスタイムが４ｍｓよりも小さければ、ＶＶＯＬに期待されるレスポンスタイムは満たしているものの、ＶＭとストレージ装置間のデータ転送が遅延していると判断される。一方、ＶＶＯＬ性能９１５に登録された平均レスポンスタイムが４ｍｓよりも大きければ、ＶＶＯＬのレスポンスタイム自体が期待される要求応答性能を満たしていないと判断される。

なお、要求性能９１０、許容ダウンタイム９１１、許容コスト９１２については、当該ＶＭがハイパーバイザにより生成される際などを契機として、管理者の設定を入力部により受け付け、コントローラ２５１がＶＶＯＬ管理テーブル８０１に格納することとしてよい。また、上記例のように、ＶＶＯＬに期待されるレスポンスタイムを、ＶＭの要求性能９１０（レスポンスタイム）の所定割合の値とする代わりに、要求性能９１０から、規定値としてＶＭとストレージ装置間のデータ転送時間を差し引いた値としてもよい。また、ＶＶＯＬに期待されるレスポンスタイムを、ＶＶＯＬ管理テーブル８０１の追加エントリ（図示せず）として格納してもよい。

図７は、プール容量消費傾向管理テーブル８０２を示す。プール容量使用傾向管理テーブル８０２は、ストレージシステム１０３が有するプールの使用傾向に関する情報を有する。

プールＩＤ１１０１は、プールを識別するための情報である。サブシステムＩＤ１１０２は、プールを有するストレージ装置１０２を識別するための情報である。時間１１０３は、計測時間帯を示す情報である。新規ページ割り当て容量１１０４は、計測時間帯に新規に割り当てられたページの総容量を示す情報である。

図８は、ポート負荷傾向管理テーブル８０３を示す。ポート負荷傾向管理テーブル８０３は、ストレージ装置１０２が有するポートの使用傾向に関する情報を有する。ポートＩＤ１２０１は、ポートを識別するための情報である。

最大許容負荷１２０２は、ポートが許容できる負荷の最大値を示す情報である。
サブシステムＩＤ１２０３は、ポートを有するストレージ装置１０２を識別するための情報である。時間１２０４は、計測時間帯を示す情報である。ポート負荷１２０５は、計測時間帯においてポートにかかった負荷を示す情報である。

図９は、ティア定義管理テーブル８０４を示す。ティア定義テーブル８０４は、ティアの定義を表す。ティア定義テーブル８０４により、各ティアを構成するＬＤＥＶの種類、そのＬＤＥＶの性能、及びそのＬＤＥＶに対する最大のアクセス頻度が分かる。

ティアレベル１３０１は、ティアのレベルを表す情報である。「ティアのレベル」とは、ティアの高さを表す数値である。本実施例では、数値が小さいティアほど、高いティアである。ＬＤＥＶタイプ１３０２は、ティアに属するＬＤＥＶのタイプを表す情報である。速度１３０３は、ティアに対するアクセスの速度を表す情報である。最大アクセス頻度１３０４は、ティアに対応するアクセス頻度の最大値を示す情報である。コスト１３０５は、ティアに属するボリュームのビットコストを表す情報である。図９では仮に、ＳＡＴＡのビットコストを１としたときの値を格納している。

各ティアの最大アクセス頻度により、各ティアのアクセス頻度範囲が表されている。図９の例によれば、上位ティア（ＳＳＤ）のアクセス頻度範囲は、２５０００〜２５００（２５００を含まない）である。中位ティア（ＳＡＳ）のアクセス頻度範囲は、２５００〜１２５０（１２５０を含まない）である。下位ティア（ＳＡＴＡ）のアクセス頻度範囲は、１２５０〜０である。

図１０は、タスク実行権限管理テーブル８０６を示す。タスク実行権限管理テーブル８０６は、ストレージ装置１０２（ストレージシステム１０３）やホスト計算機１０１に対する操作などのタスクを実行する際に必要となる管理権限を表す。

タスク種別１５０１は、ホスト計算機、ストレージ装置等に対する操作を識別するための情報である。実行可能管理権限１５０２は、タスクを実行するのに必要な管理権限を示す情報である。図１０の例では、ボリュームマイグレーション、プール拡張の実行にはストレージ管理権限を必要とし、ＶＭマイグレーションの実行にはサーバ管理権限を必要とすることが分かる。タスク実行権限は、管理者の設定を入力部から受け付けて管理計算機２０１のＣＰＵがタスク実行権限管理テーブル８０６に格納することとしてもよいし、予め管理計算機２０１がタスク実行権限管理テーブル８０６を備えることとしてもよい。

図１１は、生成中対策案管理テーブル８０７を示す。生成中対策案管理テーブル８０７は、生成した１以上の対策案とその効果を表す。生成中対策案管理テーブル８０７により、各対策案を構成するタスクと、対策案を実行したときの効果が分かる。

対策案ＩＤ１６０１は、対策案を識別するための情報である。タスクＩＤ１６０２は、対策案を構成するタスクを識別するための情報である。タスク種別１６０３は、タスクの種別を示す情報である。タスクパラメタ１６０４は、タスクの実行に必要なパラメタを識別するための情報である。例えば、タスクが、ボリュームマイグレーションであれば、移動するＶＶＯＬの識別情報、移動するＶＶＯＬが移動前に使用しているプールの識別情報、移動先プールの識別情報を登録する。ＶＭマイグレーションであれば、移動するＶＭの識別情報、移動するＶＭが移動前に使用しているホストの識別情報、移動先ホストの識別情報を登録する。プール拡張であれば、ＬＤＥＶ追加対象プールの識別情報、追加ＬＤＥＶ種別・容量を登録する。

タスク実行権限１６０５は、タスクの実行に必要な管理権限を示す情報である。応答性能１６０６は、対策案実行後のＶＶＯＬ性能（応答時間）を示す情報である。例えば、ＶＶＯＬ１の性能（応答時間）が悪化した時に応答性能を改善する対策案であれば、対策実行後のＶＶＯＬ１の性能（応答時間）を登録する。実行時間１６０７は、対策実行に要する時間を示す情報である。実行コスト１６０８は、対策実行に要するコストを示す情報である。影響ＶＭ ＩＤ１６０９は、対策実行中に対策の影響が及ぶ可能性があるＶＭを示す情報である。実行推奨度１６１０は、対策案の実行推奨度を示す情報である。実行推奨度の算出方法は、図１６で説明する。自動実行可否１６１１は、対策案の自動実行ができるかどうかを示す情報である。自動実行最終１６１２は、対策案が自動実行できる最後の時間であるかを示す情報である。

ここで、自動実行とは、実行順序に依存関係を有する１以上のタスクを、特定の権限により一連の処理として実行することを指す。自動実行が許可されるとは、特定の権限を有する管理者の操作を管理計算機２０１等が受け付けることによる、一連の処理の自動実行のための制御が許可されることを示す。

なお、対策案を自動実行できるか否かを判定する処理、対策案を自動実行できる最終の時間か否かを判定する処理は、図１７、図１８で説明する。

図１２は、自動実行判定管理テーブル８０８を示す。自動実行判定管理テーブル８０８には、図１１に示す生成中対策案管理テーブル８０８で管理される各対策案の自動実行を許すか否かを判定するための条件（ポリシ）が登録される。

大規模システムの運用管理においては、システム構成に変更を加える場合、画一的に、全体の構成を把握、管理している上位管理者の承認を要することが通例である。しかし、例えば重要度の低いリソースにのみ影響する対策案についてまで、上位管理者が全件の検討、承認を行わなければならないとすると、管理対象が膨大となり、無駄な管理コストの増大につながる。また、対策案に複数のタスクが含まれる場合、タスク実行権限を有する管理者がタスクごとに異なると、対策案の検討、承認作業が煩雑となる。また、タスク種別としてはストレージ管理者に実行権限がある場合でも、対策案実行予定時間に稼動しているＶＭがあれば、業務に影響を与える可能性があるため、結局、実際の運用においては、対策案について、システム運用管理に関与している他の管理者（サーバ管理者や上位管理者）の検討、承認も要するのが実情である。

このような管理負荷の削減のために、例えばシステム全体への影響が比較的少ない対策案や、コストのかからない対策案については、予め設定されたポリシに基づいて、上位管理者や他の管理者の権限に拠らずに自動実行を許可する。自動実行判定管理テーブル８０８により、対策案の自動実行が許される条件が分かる。

自動実行判定属性１７０１は、自動実行を許すか否かを判定する属性を示す情報である。判定パラメタ１７０２は、自動実行を許す場合の自動実行判定属性に示す属性の値を示す情報である。図１２の例では、自動実行判定属性として以下のエントリが登録されている。「使用リソース」は、対策案で使用するリソースである。ＳｔｏｒａｇｅＸのリソースであれば自動実行可能であり、また、ＶＭ Ｘが使っているリソースの場合は、重要な業務を行っているＶＭ Ｘに影響を与えるおそれがあるため、自動実行否とする。「実行権限」は、対策案を構成するタスクの実行に必要な実行権限である。サーバ管理者権限が不要であれば、自動実行可能とする。「影響ＶＭ数」は、対策案の実行予定時刻に稼動しているため、対策案実行によって応答性能が下がるなどの影響を受ける可能性のあるＶＭの数である。影響ＶＭが５つ以下であれば、サーバ管理者に問い合わせずに自動実行可能とする。「実行時間」は、対策案の実行に要する時間である。２時間以内に実行可能であれば、システムに与える影響が比較的小さいために、上位管理者等の権限に拠らずに自動実行可能とする。「実行コスト」は、対策案の実行に要するコストである。＄１０００以下であれば、上位管理者の権限に拠らずに自動実行可能とする。

なお、実施例１に記載している属性は一例であり、記載した属性のみに限定されるものでない。例えば管理者の設定を入力部より受け付けて、対策案生成プログラム８１１などが、自動実行判定管理テーブル８０８を生成することとしてもよい。

実施例１では、自動実行判定管理テーブル８０８に登録された全ての判定条件を満足した場合のみ自動実行を許すケースを例として説明する。例えば、図１２の例では、以下条件をすべて満たした対策案のみ自動実行が許される。対策案に使用するリソースはＳｔｏｒａｇｅ１であり、対策案に使用するリソースはＶＭ Ｘが使っていない。対策案を構成する全てのタスクの実行にはサーバ管理権限は不要である。対策案によって影響が及ぶＶＭの数は５つ以下である。対策案の実行に要する時間は２時間以下で、要するコストは＄１０００である。

ただし、全ての自動実行判断条件に該当した場合のみ自動実行を許可するのではなく、自動実行条件に優先度を設け、優先度の高い自動実行条件に所定数該当した場合は、優先度の低い自動実行条件に該当していなくても自動実行する、としてもよい。

次に、記憶資源２１１上の状態監視プログラム８１０、対策案生成プログラム８１１について説明する。

状態監視プログラム８１０は、一定時間ごとに、あるいは外部からの情報収集要求を受け付けたことを契機として、ＶＶＯＬ、プール、ポートの使用傾向情報及びＶＭの性能情報を収集し、それらの情報を、ＶＶＯＬ管理テーブル８０１、プール容量消費傾向管理テーブル８０２、ポート負荷傾向管理テーブル８０３などに記録する。

（Ｆ）状態監視プログラム８１０は、例えば１時間毎に、以下の処理を実行する。
（ｆ１）状態監視プログラム８１０は、プール管理テーブル３０２に登録された情報をストレージ装置１０２より取得する。
（ｆ２）（ｆ１）で取得した情報を基に、状態監視プログラム８１０は、ＶＶＯＬ毎の使用容量、アクセス分布、新規ページ割り当て容量を算出し、その結果と計測時間情報を、ＶＶＯＬ管理テーブル８０１の使用容量９０４、ＶＶＯＬ性能９１５、アクセス分布９１６、新規ページ割り当て容量９１７、時間９１２に追加更新する。
（ｆ３）（ｆ１）で取得した情報を基に、状態監視プログラム８１０は、プール毎の新規ページ割り当て容量を算出し、その結果と計測時間情報を、プール容量消費傾向管理テーブル８０２の時間１１０３、新規ページ割り当て容量１１０４、時間１１０３に追加更新する。
（ｆ４）状態監視プログラム８１０は、ＶＭ１１１がＶＶＯＬに対するアクセスコマンドを発行してからその応答をＶＭ１１１が受け取るまでの時間長（ＶＭ性能）をホスト計算機１０１から取得する。例えば、ＶＭ１１１がストレージ装置１０２に格納されたデータにアクセスする際に、ＶＭ１１１やハイパーバイザ１１２がそのレスポンスタイムを記録しておき、状態監視プログラム８０１はその記録結果を取得する。そして、取得したＶＭ応答性能情報を、ＶＶＯＬ管理テーブル８０１のＶＭ性能９１４に記録する。
（ｆ５）状態監視プログラム８１０は、ポート負荷情報をストレージ装置１０２から取得する。例えば、ストレージ装置１０２のメモリ２４３上のプログラムが、ポート２４１の負荷情報とそのポートを使ったアクセスが発生したＶＶＯＬに関する情報を定期的にメモリ２４３に記録しておき、状態監視プログラム８１０はその記録結果を取得する。そして、取得したポート負荷情報をＶＶＯＬ管理テーブル８０１のポート負荷９１８に記録する。
（ｆ６）（ｆ５）で取得した情報を基に、状態監視プログラム８１０は、ＶＶＯＬ毎のポート負荷情報を算出し、その結果と計測時間情報を、ポート負荷傾向管理テーブル８０３の時間１２０４、ポート負荷１２０５に追加更新して、処理を終了する。

状態監視プログラム８１０はさらに、ＶＭ１１１に関して不適切な状態が発生していないかを監視する。ここでいう不適切な状態とは、例えば、ストレージ装置に格納されているデータにＶＭがアクセスする際の応答性能が要求する応答性能よりも遅い状態（ＶＭ応答遅延）、である。なお、応答性能が過剰に速いケースも、無駄に良いリソースが割り当てられており、不要な投資が生じていると言えるので、不適切な状態として扱うことができる。

（Ｇ）状態監視プログラム８１０は、例えば、以下のステップでシステムの状態の監視を行う。
（ｇ１）状態監視プログラム８１０は、ＶＶＯＬ管理テーブルの要求性能９１０と、ＶＭ性能９１４とを比較する。ＶＭ性能９１４に登録された性能値が要求性能値よりも大きい（遅い）場合は、期待されている性能をＶＭが満たしていないと判断し、（ｇ２）を実施する。反対にＶＭ性能９１４に登録された性能値が要求性能値よりも小さい（速い）場合は、処理を終了する。ただし、ＶＭ性能９１４に登録された性能値が要求性能値よりも小さすぎる場合は、無駄に良いリソースが割り当てられていると判断し、（ｇ２）を実施してもよい。
（ｇ２）次に状態監視プログラム８１０は、要求性能９１０から求められるＶＶＯＬの要求応答性能とＶＶＯＬ性能９１５を比較する。ＶＶＯＬ性能９１５に登録された値が要求性能９１０に登録された値の所定割合を上回る（遅い）場合は、ＶＶＯＬ応答時間が期待を下回っていることを根本原因とするＶＭ応答遅延が発生していることをアラートとして出力部に出力する。反対に、ＶＶＯＬ性能９１５に登録された値が要求性能９１０に登録された値の所定割合を下回っていたら、ＶＶＯＬ応答時間遅延以外を根本原因とするＶＭ応答遅延が発生していることをアラートとして出力部に出力する。

なお、応答遅延等に対する根本原因の特定には、応答遅延アラートのようなイベント情報に基づいて根本原因を特定するＲＣＡ（Ｒｏｏｔ Ｃａｕｓｅ Ａｎａｌｙｓｉｓ）技術を使ってもよい。また、本実施例の以下の説明では、主にＶＶＯＬを原因としてＶＭの応答遅延が発生していることを想定しているが、他に、ストレージポートやネットワーク、ホスト計算機のＣＰＵの過負荷が原因であることも考えられる。

図１３から図１８は、対策案生成処理の流れを示すフローチャートである。例えば、対策案生成プログラム８１１は、対策案生成指示を受信したときに対策案生成処理を実行する。対策案生成指示は、状態監視プログラム８０９からアラートが発せられた場合などに管理者による入力を受け付けて発行されることとしてよい。

図１３は、例としてＶＭ１で応答遅延が発生し、その根本原因がＶＶＯＬ１であった場合の対策案を生成する処理フローを説明する。

対策案生成プログラム８１１は、状態監視プログラム８１０の出力結果及び、対策案生成指示の内容として、対策案生成の動機である状態は、ＶＭ１の応答遅延であり、上記状態の根本原因は、ＶＶＯＬ１である、及び管理者が対策を実行する予定時間である対策実行予定時間を受け付ける（Ｓ１００００）。

次に対策案生成プログラム８１１は、管理計算機１０１が管理しているストレージシステム１０３が所有するプール一覧の情報をストレージシステム１０３より取得する（Ｓ１０００１）。対策案生成プログラム８１１は、ＶＶＯＬ１が使用しているプールを特定した上で、取得したプール一覧のうち、特定したプール以外のプール、すなわちＶＶＯＬ１の移行先候補であるプールそれぞれに対してプール別対策案生成処理を実行する（Ｓ１０００２、Ｓ１０００３）。なお、Ｓ１０００３の処理の詳細は図１４で説明する。以降、ＶＶＯＬ１が使用しているプールをプール１とする。

次に、対策案生成プログラム８１１は、生成中対策案管理テーブル８０７を参照し、Ｓ１０００３の処理によって登録された対策案一覧を取得する（Ｓ１０００４）。対策案生成プログラム８１１は、取得した対策案一覧に含まれる対策案それぞれに対して、対策案効果算出処理を実行する（Ｓ１０００５、Ｓ１０００６）。なお、Ｓ１０００５の処理の詳細は図１５で説明する。次に、対策案生成プログラム８１１は、生成中対策案管理テーブル８０７から、生成した対策案一覧を取得し、出力装置に出力して処理を終了する（Ｓ１０００７）。なお、上記ステップの代わりに、生成した対策案について生成中対策案管理テーブル８０７に格納する前に対策案効果算出処理を行った上で、算出した効果とともに対策案を生成中対策案管理テーブル８０７に格納することとしてもよいし、あるいは直接出力装置に出力することとしてもよい。

図１４では、図１３のＳ１０００３で実行されるプール別対策案生成処理の詳細を説明する。図１４は、Ｓ１０００２で選択したプールにＶＶＯＬを移動するタスクを含む対策案を生成する処理の流れを示すフローチャートである。ＶＶＯＬをＳ１０００２で選択したプールに移動することで性能改善が見込めるかを予測し、性能改善が見込める場合にはＳ１０００２で選択したプールにＶＶＯＬを移動するタスクを含む対策案を生成する。なお、以降の説明では、Ｓ１０００２で処理対象プールとして選択したプールをプールＸとして説明する。

対策案生成プログラム８１１は、プール１とプールＸが、同一ストレージ装置１０２が提供するプールか否かを判断する（Ｓ１００１０）。Ｓ１００１０の判断が否定的な場合は、ＶＭ１からＶＶＯＬ１にアクセスするのに使用するストレージポートを変更してもよい。

具体的には、ＶＭ１がＶＶＯＬ１にアクセスする際に使用するストレージポートを、プール１を有するストレージ装置のポートからプールＸを有するストレージ装置のポートに変更する。ストレージポートを変更しないと、プール１を有するストレージ装置を介して、プールＸを有するストレージ装置にアクセスしなければならないため、直接アクセスするときよりも性能が遅延する可能性がある。当然ＶＭ１が稼働しているホスト計算機１０１から当該ポートが接続されていなくてはならないため、もし、ＶＭ１が稼働しているホスト計算機１０１から当該ポートが接続されていなければ、ＶＭ１を稼働させるホスト計算機自体を変更する処理を実施するか、新規にホスト計算機１０１とストレージ装置を接続させる必要がある。実施例１では、ＶＭ１と当該ポートとが接続されているものとする。

対策案生成プログラム８１１は、プールＸを有するストレージのポートを特定する（Ｓ１００１８）。なお、以降、Ｓ１００１８で特定したストレージのポートをポートＸとする。次に、対策案生成プログラム８１１は、ＶＭ１がＶＶＯＬ１にアクセスする際に使用するストレージポートを、プール１を有するストレージ装置のポートからプールＸを有するストレージ装置のポートに変更したと仮定して、対策実行予定時間が、ポートＸの閾値超過予定時間から対策に要する時間を差し引いた値よりも前になるか後になるかを判断する（Ｓ１００１９）。

ポートＸの閾値超過予定時間は、例えば、対策案生成プログラム８１１が以下の方法で求める。
（１）ＶＶＯＬ管理テーブル８０１などから、ＶＶＯＬ１が使用しているポート１のポート負荷履歴を取得し、ＶＶＯＬ１によるポート１の負荷傾向式を算出する。例えば、回帰分析等の手法を使うことができる。
（２）ポート負荷傾向管理テーブル８０３から、ポートＸのポート負荷傾向を取得し、ポートＸの負荷傾向式を算出する。
（３）（１）で算出したＶＶＯＬ１によるポート１の負荷傾向式と、（２）で算出したポートＸの負荷傾向式を使って、ポートＸにかかる負荷がポート負荷傾向管理テーブル８０３に登録されているポートＸの最大許容負荷を超過する時間を算出する。

例えば、ＶＶＯＬ１がポート１にかける負荷が単調増加する傾向にあって、Ｙ＝２Ｔ＋２（Ｔ：時間）という式で表されたとする。また、ポートＸにかかる負荷が単調増加する傾向にあって、Ｋ＝２Ｔ＋１０（Ｔ：時間）という式で表されたとする。

ＶＶＯＬ１が使用するポートをポート１からポートＸに変更すると、予測されるポートＸの負荷増加傾向は、以下式で表されることになる。

Ｗ＝（２Ｔ＋２）＋（２Ｔ＋１０）＝４Ｔ＋１２
上記式と、ポート負荷傾向管理テーブル８０３に登録されているポートＸの最大許容負荷から、ポート最大許容負荷を超過する時間を算出する。例えば、ポート負荷傾向管理テーブル８０３によるとポートＸの最大許容負荷が４０であったとする。ポートＸの負荷増加傾向は、Ｗ＝４Ｔ＋１２、と予測されるため、Ｗの値が４０を超えるＴは、７、である。このため、現在時刻から７時間後がポート最大許容負荷を超過する時間、と算出することができる。なお、対策実行時間の算出方法の例は、図１５のＳ１００３０で説明する。Ｓ１００１０の判断が肯定的な場合は、ストレージポートの変更は不要なため、Ｓ１００１８とＳ１００１９の処理は省略する。

対策案生成プログラム８１１は、ＶＶＯＬ１をプールＸに移動したと仮定して、対策実行予定時間が、プールＸの容量枯渇予定時間から対策実行時間を差し引いた値よりも前か否かを判断する（Ｓ１００１１）。プールＸの容量枯渇予定時間は、例えば、対策案生成プログラム８１１が以下方法で求める。
（１）ＶＶＯＬ管理テーブル８０１から、ＶＶＯＬ１が使用しているプール１の新規ページ割り当て容量傾向を取得し、ＶＶＯＬ１によるプール１の単位時間当たりの新規ページ割り当て傾向式を算出する。
（２）プール容量消費傾向管理テーブル８０２から、プールＸのプール消費傾向を取得し、プールＸの単位時間当たりのプール容量消費傾向式を算出する。
（３）（１）で取得したＶＶＯＬ１によるプール１の単位時間当たりのプール容量消費傾向式と、（２）で取得したプールＸの単位時間当たりのプール容量消費傾向式を使って、プールＸの未使用容量が枯渇する時間を算出する。

なお、対策が完了してすぐにプール容量が枯渇することや、ポート負荷が最大許容量を超過してしまうことを防止するために、Ｓ１００１９とＳ１００１１で対策実行予定時間とポートＸの閾値超過予定時間（又はプールＸの容量枯渇予定時間）から対策実行時間を差し引いた値を比較する際に、一定の余裕がなければその対策案は不適切であると判断してもよい。

また、Ｓ１００１１ではプールＸの容量枯渇予定時間と対策実行予定時間とを比較して判断を行うが、時間でなく、対策実行予定時間におけるプールＸの残存容量を予測し、残存容量が十分でなければその対策案が不適切であると判断しても良い。また、例えば、ＨＤＤが納入されるのが３日後なので３日間だけ性能を維持したい、その後は納入されたＨＤＤを使って抜本的な対策を実施するというように、その対策実行による効果（性能）を維持させたい日数が予め決まっているような場合、効果を維持させたい日数について管理者の指定を入力部により受け付け、その日数に耐えられなければその対策案は不適切であると判断してもよい。また、Ｓ１００１９の説明ではポート負荷が単調増加傾向にあった場合を例として説明したが、単調増加傾向になくてもポートを変更することで最大許容負荷を超えてしまう場合は、当該ポートに使用を変更することは不適切だと判定してもよい。

次に、対策案生成プログラム８１１は、ＶＶＯＬ１をプールＸに移動したと仮定して、ＶＶＯＬ１アクセス時の応答性能を予測する（Ｓ１００１２）。ＶＶＯＬ１アクセス時の応答性能は、例えば、ＶＶＯＬ管理テーブル８０１からＶＶＯＬ１のアクセス分布履歴を取得し、対策実行予定時間のプールＸのアクセス分布を算出し、算出したアクセス分布からＶＶＯＬ性能の予測値を算出する。アクセス分布からＶＶＯＬ性能を算出する方法は、例えば特許文献２に示された方法を用いてよい。

次に、Ｓ１００１２で算出した応答性能が、ＶＭ１の要求性能９１０から求められるＶＶＯＬ１の要求応答性能を満足しているかを判断する（Ｓ１００１３）。Ｓ１００１３の判断が否定的な場合は、対策案生成プログラム８１１はフロー２の処理を終了する。Ｓ１００１３の判断が肯定的な場合は、対策案生成プログラム８１１は、ＶＶＯＬ管理テーブル８０１に基づき、既にプールＸから切り出されているＶＶＯＬおよびそのＶＶＯＬを使用しているＶＭを特定する（Ｓ１００１４）。

対策案生成プログラム８１１は、ＶＭ１をプールＸに移動したと仮定した場合に、Ｓ１００１４で特定したＶＶＯＬ（およびＶＭ）が、要求性能を満足するか否かを判断する（Ｓ１００１５）。これは、Ｓ１００１２で算出したプールＸのアクセス分布からプールＸから切り出されたＶＶＯＬの応答性能を算出し、その結果と、ＶＶＯＬ管理テーブル８０１の要求性能９１０から求められるＶＶＯＬの要求応答性能とを比較し、判断する。

Ｓ１００１５の判断が否定的な場合は、要求性能を満足しないと判定されたＶＶＯＬをＶＶＯＬ Ｙ、ＶＶＯＬ Ｙが割り当てられているＶＭをＶＭ Ｙとすると、改善すべき状態は、ＶＭ Ｙの応答遅延であり、その根本原因がＶＶＯＬ Ｙであり、対策実行予定時間は、Ｓ１００００で受け付けた対策実行予定時間であるとする対策案（タスク）生成処理を再帰的に実行する（Ｓ１００１６）。Ｓ１００１５の判断が肯定的な場合は、Ｓ１００１６の処理を省略する。

なお、ＶＶＯＬ Ｙのアクセス性能を改善するための対策案（タスク）生成処理のＳ１００１９と、Ｓ１００１１の処理は、ＶＶＯＬ１のアクセス性能を改善する対策案を実施したという前提で行う。つまり、ＶＶＯＬ１の対策案生成処理で、ＶＶＯＬ１にアクセスするためのストレージポートを変更するとした場合は、ＶＶＯＬ１のポート負荷がポートＸに加算されていることを仮定して（逆に、ポート１の負荷はＶＶＯＬ１が移動した分下がる）、ＶＶＯＬ Ｙについてのプール別対策案生成処理のＳ１００１９を実施する。ＶＶＯＬ１の対策案生成処理で、ＶＶＯＬ１をプールＸに移動するとした場合は、ＶＶＯＬ１の容量消費傾向がプールＸに加算されていることを仮定して（逆に、プール１で消費されるページ容量はＶＶＯＬ１が移動した分少なくなる）、ＶＶＯＬ Ｙについてのプール別対策案生成処理のＳ１００１１を実施する。

次に、対策案生成プログラム８１１は、生成した対策案を生成中対策案管理テーブル８０７に登録して処理を終了する（Ｓ１００１７）。例えば、Ｓ１００１０の判断で肯定的と判定されてＳ１００１５の判断も肯定的であった場合は、ＶＶＯＬ１をプール１からプールＸに移動するタスクを一対策案として生成中対策案管理テーブル８０７に登録する。Ｓ１００１０の判断で否定的と判定された場合は、ＶＶＯＬ１をプール１からプールＸに移動するタスクと、ＶＭ１がＶＶＯＬ１にアクセスするのに使用するポートをポートＸに変更するタスクとを含む対策案を生成中対策案管理テーブル８０７に登録する。このとき、登録するタスクの種別に応じて、タスク実行権限管理テーブル８０６を基にタスク実行権限１６０５を登録し、Ｓ１００１２で算出した予測性能を応答性能１６０６に登録する。

なお、対策案によって性能の変更が見込まれるＶＶＯＬが複数ある場合には、それぞれについての予測性能を登録することとしてもよい。また、ＶＭとストレージ間のデータ転送時間を考慮して、ＶＭの予測性能を登録し、以降の処理ではＶＶＯＬでなくＶＭの予測性能を判断に用いることとしてもよい。図１１では、ＶＭの予測性能を対策案の効果として格納している。

以上、図１３、図１４の処理をもって、ＶＭ１に性能遅延が発生しその原因がＶＶＯＬ１の応答性能遅延であった場合の対策案を生成することができる。なお、図１３、図１４の処理は、ＶＶＯＬ応答遅延が根本原因だった場合の処理であるが、根本原因が例えば、ホスト計算機１０１のＣＰＵにある場合は、ＶＭをプロセッサ負荷の低い他のホスト計算機１０１に移動するＶＭマイグレーションの対策案を生成してもよい。

また、根本原因がＶＶＯＬにあった場合の対策としては、ＶＶＯＬをプール間でマイグレーションする対策だけでなく、プールにＬＤＥＶを追加する（プール拡張）対策も考えられるため、そのような対策案を生成してもよい。例えば、ＶＶＯＬ管理テーブルで管理されている各ＶＶＯＬのアクセス分布から、各ティアに必要とされるＬＤＥＶ容量を算出する。

また、Ｓ１００１６で対策案（タスク）生成処理を再帰的に実施してもなお要求性能を満足しないＶＭが存在し続けることがある。このようなケースに対応するために、あらかじめ対策案（タスク）生成処理を実施する最大回数を決めておき、対策案（タスク）生成処理が最大回数分実施された場合は処理を打ち止めとしてもよい。また、対策案（タスク）生成処理を再帰的に実行するうちに、解消したはずの状態が再度生じることがある。この場合も処理を打ち止めにする。

例えば、ＶＶＯＬ１（ＶＭ１）の応答遅延を解消しようとするとＶＶＯＬ３（ＶＭ３）の応答遅延が発生し、さらにＶＶＯＬ３（ＶＭ３）の応答遅延を解消しようとすると再度ＶＶＯＬ１（ＶＭ１）の応答遅延が生じるという場合は、それが判明した段階で（具体的には、Ｓ１００１５の判定で過去に解消したはずの状態が再度生じていないかを確認する）、その対策案生成処理を中止する。これらの場合、当該対策案を生成、出力しないこととするか、または、当該対策案を実行しても残される状態（当該対策案により新たに生じる状態）を、対策案と合わせて出力することとしてよい。

また、要求応答性能を満足しないＶＭのうち、要求性能と現在性能（予測性能）のギャップが大きいＶＭについて優先的に対策案（タスク）生成処理を実施してもよい。対策案生成処理が途中で打ち止めされたとしても、優先的に解決することができる。

また、実施例１では、応答遅延が発生したＶＶＯＬ自体を他のプールに移動するタスクを含む対策案を生成する。しかし、応答遅延が発生したＶＶＯＬ自体ではなく、同じプールを共有しているＶＶＯＬを他のプールに移動させることで、状態が解消されることもある。このため、例えば、高Ｔｉｅｒからの割り当てページ量が多いＶＶＯＬを他のプールに移動する対策案を生成してもよい。

図１５は、図１３のＳ１０００６で実行される対策案効果算出処理の詳細である。図１５は、Ｓ１０００２、Ｓ１０００３で生成した対策案それぞれについて、対策案の効果（応答性能、実行時間、実行コスト、影響ＶＭ数）、実行推奨度、自動実行可否、自動実行最終かを算出する処理の流れを示すフローチャートである。なお、以降の説明では、Ｓ１０００５で処理対象対策案として選択した対策案を対策案Ｘとして説明する。また、効果とは、対策案を実行した場合にシステム全体等に与える影響を指す。

対策案生成プログラム８１１は、対策案Ｘを実行するのに要する時間を予測する（Ｓ１００３０）。例えば、対策案を構成するタスク毎に実行時間を算出し、各タスクをパラレルに実行できるのであれば、最も時間がかかるタスクの実行時間を対策案の実行に要する時間とし、シーケンシャルに実行する必要があるタスクであれば全てのタスクの実行時間の総和を対策案の実行時間とすることで算出する。

また、各タスクの実行時間算出方法としては、ＶＶＯＬをプール間でマイグレーションするタスクであれば、当該ＶＶＯＬ、および当該ＶＶＯＬ以外のＶＶＯＬの過去の移動履歴を使ってマイグレーションに要する時間を算出する。例えば、過去に移動したＶＶＯＬの容量とマイグレーション時の負荷情報（例えば、移動対象ＶＶＯＬのアクセス頻度、移動元・移動先プールのアクセス頻度、ＣＰＵ２４４及びポート２４２等にかかっている負荷）、マイグレーションにかかった時間を実績として保持しておき、移動対象となっているＶＶＯＬの容量と実績を比較することでＶＶＯＬのプール間移動に要する時間を算出する。

次に、対策案生成プログラム８１１は、対策案Ｘの実行によって新規に使われるリソースを特定し、そのリソースを使っているＶＭのうち対策実行時間帯に稼働しているＶＭを特定する。例えば、プール１から切り出されているＶＶＯＬ１をプール３に移動する対策案である場合、プール３に関連づいているＶＶＯＬ、ＶＭを特定する。図２の例では、プール３に関連づいているＶＶＯＬ３、ＶＶＯＬ３を使っているＶＭ３が特定される。そして、特定したＶＭの中からさらに、Ｓ１００００で取得した「対策実行予定時間」から「対策実行予定時間＋対策案の実行に要する時間」までの時間に稼働しているため、当該対策案によって影響を受ける可能性があるＶＭを特定する（Ｓ１００３１）。

次に、対策案生成プログラム８１１は、対策案Ｘを実行するのに要するコストを算出する（Ｓ１００３２）。例えば、プールにＬＤＥＶを追加する対策案の場合は、プールに新規追加するＬＤＥＶの容量とＬＤＥＶの種別に応じたビットコスト情報から、追加で必要となるボリュームのコストを算出してもよい。

次に、対策案生成プログラム８１１は、対策案Ｘの実行推奨度算出処理を算出する（Ｓ１００３３）。実行推奨度算出処理の詳細は図１６で説明する。

対策案生成プログラム８１１は、算出した対策案の実行に要する時間、対策実行予定時間帯に稼働しているＶＭの数、対策案の実行に要するコスト、実行推奨度の情報を、生成中対策案管理テーブル８０７の対策案Ｘの実行時間１６０７、影響ＶＭ数１６０９、実行コスト１６０８、実行推奨度１６１０に登録する（Ｓ１００３４）。

対策案生成プログラム８１１は、自動実行可否判定処理を実行して、処理を終了する（Ｓ１００３５）。なお、Ｓ１００３５の処理の詳細は図１７で説明する。

図１６は、図１５のＳ１００３２で実行される実行推奨度算出処理の詳細である。図１６は、Ｓ１０００５で選択した対策案Ｘの実行推奨度を算出する処理の流れを示すフローチャートである。生成した各対策案を、ＶＶＯＬ管理テーブル８０１で保持されている要求／許容要件をより満たす順に出力装置に出力し、管理者に提示することができる。

対策案生成プログラム８１１は、ＶＶＯＬ管理テーブル８０１から、ＶＶＯＬ１を使っているＶＭ１の要求性能、許容ダウンタイム、許容コストを取得する（Ｓ１００４０）。対策案生成プログラム８１１は、Ｓ１００４０で取得した要求性能と、対策案Ｘを実行した場合の達成性能とから、対策案Ｘによる性能満足度を算出する（Ｓ１００４１）。次に、対策案生成プログラム８１１は、Ｓ１００４０で取得した許容ダウンタイムと、対策案Ｘの実行時間とから対策案Ｘによる実行時間満足度を算出する（Ｓ１００４２）。次に、対策案生成プログラム８１１は、Ｓ１００４０で取得した許容コストと、対策案Ｘの実行コストから対策案Ｘによる実行コスト満足度を算出する（Ｓ１００４３）。

次に、対策案生成プログラム８１１は、Ｓ１００４１、Ｓ１００４２、Ｓ１００４３で算出した値を使って、対策案Ｘの実行推奨度を算出する（Ｓ１００４４）。

例えば、図５、図６のＶＶＯＬ管理テーブルで８０１を例にとると、ＶＭ１の要求性能は４ｍｓ、許容ダウンタイムは５時間、許容コスト＄１００００である。それに対して、図１１の対策案１を実行した場合のＶＭ１の応答性能は３ｍｓ、対策案の実行に要する時間は４時間、実行コスト＄０である。以上より、性能満足度は、（３÷４）×１００＝７５とする。実行時間満足度は、許容ダウンタイム内に実行可能なため１００とする。実行コスト満足度も、許容コスト以内であるため、１００とする。これらの値から、対策案１の実行推奨度を（７５＋１００＋１００）÷３＝約９０．３と求める。

性能については、遅くても早くても性能遅延またはオーバープロビジョニングという状態が生じているといえるため、どちらの場合でも要求性能と予測性能の差分を算出する。一方、実行時間、実行コストについては、短ければ短いほど、小さければ小さいほどよいといえる。このため、実行時間については、許容ダウンタイムより短いか長いか、長い場合は許容ダウンタイムと比較してどれくらい長いのかを算出する。また、実行コストについても、許容コストより小さいか大きいか、大きい場合は許容コストと比較してどれくらい大きいのかを算出する。上記の例では、実行時間、実行コストともに許容ダウンタイムよりも短く、許容コストよりも小さいため、満足度１００として算出している。もし、実行時間が、許容ダウンタイムよりも長ければ、許容ダウンタイムと実行時間の差分を算出する。実行コストと許容コストについても同様である。

それに対して、図１１の対策案２を実行した場合のＶＭの応答性能は１ｍｓ、対策案の実行に要する時間は２時間、実行コスト＄５０００であるため、性能満足度は（１÷４）×１００＝２５とする。実行時間満足度は、１００とする。実行コスト満足度は、１００とする。以上より、対策案２の実行推奨度を（２５＋１００＋１００）÷３＝７５と求める。

対策案１と対策案２の実行推奨度を比較すると、対策案１の実行推奨度の方が高い。対策案１、２ともに要求／許容要件は満たしているが、対策案２は対策案１と比較して過剰に性能が出ており、オーバープロビジョニングが生じている。このため、対策案１の方が対策案２と比較して無駄がない対策案といえ、対策案１の推奨度が高くなっている。

このように、要求性能や許容コスト、許容されるダウンタイムをあらかじめ定義しておき、上記情報と、対策案の達成性能、実行時間、実行コストとから対策案の実行推奨度を算出することで、「多少実行コストがかかってもよいから、応答性能を早くしたい」というケースや、逆に「実行コストはかけたくないから応答性能はそこそこでよい」「性能は最低限改善されれば良いから対策に時間をかけたくない」というケース等、システム管理の事情に応じた対策案を選び出すことができる。

図１７、図１８は、図１５のＳ１００３５で実行される自動実行可否判定処理の詳細を示す。まず図１７は、Ｓ１０００５で選択した対策案Ｘが自動実行できるか否か、自動実行できる場合は自動実行できる最後のタイミングなのかを示すフローチャートである。なお、自動実行判定属性について判断する各処理の順序は、以下に限定されるものではない。

対策案生成プログラム８１１は、生成中対策案管理テーブル８０７から対策案Ｘの詳細情報、実行権限、実行時間、実行コスト、影響ＶＭ ＩＤの情報を取得する（Ｓ１００５０）。対策案生成プログラム８１１は、自動実行判定管理テーブル８０８より登録されている自動実行判定条件を取得する（Ｓ１００５１）。

次に、対策案生成プログラム８１１は、対策案Ｘの実行によって新規に使われるリソースを対策案詳細情報から取得し（Ｓ１００５２）、自動実行否と判断されるリソースが含まれていないかを判断する（Ｓ１００５３）。例えば、図１５の対策案１では、ＶＶＯＬ１の移動先であるプール３が新規に使われるリソースとして特定される。そして、プール３が、自動実行判定管理テーブル８０８の自動実行判定属性１７０１が「使用リソース」であるエントリの判定パラメタ１７０２に登録されたリソースに含まれているか否かを判断する。例えば、図１２の例では、プール３が、ＳｔｏｒａｇｅＸが有するプールか否か、ＶＭ Ｘが使っていないリソースか否かを判断する。

Ｓ１００５３の判断が否定的な場合は、生成中対策案管理テーブル８０７の自動実行可否１６１１に自動実行できない（Ｎｏ）ことを登録して（Ｓ１００６０）、処理を終了する。Ｓ１００５３の判断が肯定的な場合は、対策案生成プログラム８１１は次に、対策案Ｘに、自動実行否と判断される管理権限を必要とするタスクが含まれていないかを判断する（Ｓ１００５４）。例えば、自動実行判定管理テーブル８０８の自動実行判定属性１７０１が「実行権限」であるエントリの判定パラメタ１７０２に登録された管理権限を取得し、Ｓ１００５２で取得した対策案Ｘを構成する各タスクの管理権限に含まれているか否かを判断する。

Ｓ１００５４の判断が否定的な場合は、Ｓ１００６０の処理を実行して、処理を終了する。Ｓ１００５４の判断が肯定的な場合は、対策案生成プログラム８１１は、移動先プールを共有しているＶＭを特定し（Ｓ１００５５）、対策実行予定時間に稼働しているＶＭの数が、自動実行可とされるＶＭの数よりも小さいかを判定する（Ｓ１００５６）。例えば、自動実行判定管理テーブル８０８の自動実行判定属性１７０１が「影響ＶＭ数」であるエントリの判定パラメタ１７０２に登録されたＶＭ数を取得し、Ｓ１００５０で取得した対策案Ｘによって影響が及ぶＶＭの数と比較して判断する。

Ｓ１００５６の判断が否定的な場合は、Ｓ１００６０の処理を実行して、処理を終了する。Ｓ１００５６の判断が肯定的な場合は、対策案生成プログラム８１１は、対策案Ｘを実行するのに要するコストが、自動実行否と判断されるコストよりも小さいかを判断する（Ｓ１００５７）。例えば、自動実行判定管理テーブル８０８の自動実行判定属性１７０１が「実行コスト」であるエントリの判定パラメタ１７０２に登録されたコストを取得し、Ｓ１００５０で取得した対策案Ｘの実行に要するコストと比較して判断する。

Ｓ１００５７の判断が否定的な場合は、Ｓ１００６０の処理を実行して、処理を終了する。Ｓ１００５７の判断が肯定的な場合は、対策案生成プログラム８１１は、対策案Ｘを実行するのに要する時間が、自動実行否と判断される時間よりも小さいかを判断する（Ｓ１００５８）。例えば、自動実行判定管理テーブル８０８の自動実行判定属性１７０１が「実行時間」であるエントリの判定パラメタ１７０２に登録された実行時間を取得し、Ｓ１００５０で取得した対策案Ｘの実行に要する時間と比較して判断する。

Ｓ１００５８の判断が否定的な場合は、Ｓ１００６０の処理を実行して、処理を終了する。Ｓ１００５８の判断が肯定的な場合は、自動実行判定管理テーブル８０８に登録された全ての自動実行条件を満足したため、次に自動実行最終時間判定処理を実行し（Ｓ１００５９）、処理を終了する。

図１８は、図１７のＳ１００５９で実行される自動実行最終時間判定処理の詳細を示す。図１８は、Ｓ１０００５で選択した対策案Ｘが自動実行できる場合に、Ｓ１００００で受信した対策案実行予定時間が対策案Ｘを自動実行できる最終タイミングか否かを判定するフローチャートである。

本処理では、Ｓ１００００で受信した対策実行予定時間より後の時間に対策案Ｘを実行すると仮定して、対策案Ｘを自動実行できるか否かを判定し、自動実行できないと判定された場合には、Ｓ１００００で受信した対策実行予定時間が対策案Ｘを自動実行できる最後の時間として出力する。

なお、以下処理の説明では、対策案Ｘが自動実行できるかを判定した「対策実行予定時間よりも後の時間」を「対策実行予定時間＋Ｘ時間」と表記している。Ｘには、例えば、「１分」等の固定の値が入る。例えば、Ｓ１０００５で受信した対策実行予定時間が、「２０１２年４月１日１２：００」であれば、「２０１２年４月１日１２：０１」に対策案Ｘが自動実行できるか否かを判断し、自動実行できないと判断された場合は、「２０１２年４月１日１２：００」が、対策案Ｘを自動実行できる最終タイミングとして提示される。「対策実行予定時間＋Ｘ時間」のＸは、システム管理環境の実情に照らして、予め設定されることとしてよい。

以下、自動実行最終時間判定処理の詳細を説明する。対策案生成プログラム８１１は、対策に使用するプールの容量枯渇時間を予測し（Ｓ１００７０）、「対策実行予定時間＋Ｘ時間」がプールの容量が枯渇する時間より後か否かを判断する（Ｓ１００７１）。Ｓ１００７１の判断が肯定的な場合、「対策実行予定時間＋Ｘ時間」に示す時間には、移動先プールに必要容量を確保できなくなっており、対策案Ｘが実行できない。このため、生成中対策案管理テーブル８０７の自動実行可否１６１１に「自動実行できる（Ｙｅｓ）」であることと、「対策実行予定時間＋Ｘ時間」が「自動実行できる最終タイミングであること（Ｙｅｓ）」を登録して（Ｓ１００７８）、処理を終了する。なお、この場合はそもそも対策案の実行自体が「対策実行予定時間＋Ｘ時間」には不可であるので、対策案の実行の最終タイミングである旨を記録するするエントリ（図示せず）に登録することとしてもよい。

Ｓ１００７１の判断が否定的な場合は、対策案生成プログラム８１１は、「対策実行定時間＋Ｘ時間」に対策案Ｘを実行したと仮定して、対策案Ｘの実行に要する時間を算出する（Ｓ１００７２）。次に、対策案生成プログラム８１１は、対策案Ｘが使用するプールを使っているＶＭのうち、「対策実行予定時間＋Ｘ時間」から対策実行完了時間までに稼働しているＶＭを特定する（Ｓ１００７３）。次に、対策案生成プログラム８１１は、自動実行判定管理テーブル８０８から、自動実行可否条件を取得する（Ｓ１００７４）。

次に、対策案生成プログラム８１１は、Ｓ１００７２で算出した対策に要する時間が、自動実行可と判定される実行時間よりも大きいか否かを判断する（Ｓ１００７５）。Ｓ１００７５の判断が肯定的な場合は、「対策実行予定時間＋Ｘ時間」に示す時間には対策案Ｘが自動実行できないと判断し、Ｓ１００７８の処理を実行して終了する。Ｓ１００７５の判断が否定的な場合は、対策案生成プログラム８１１は、Ｓ１００７３で特定したＶＭの数が、自動実行可と判定される影響ＶＭ数より大きいか否かを判断する（Ｓ１００７６）。

Ｓ１００７６の判断が肯定的な場合は、「対策実行予定時間＋Ｘ時間」に示す時間には対策案Ｘが自動実行できないと判断し、Ｓ１００７８の処理を実行して終了する。Ｓ１００７６の判断が否定的な場合は、Ｓ１０００１で受信した対策実行予定時間に対策案Ｘを自動実行できるだけでなく、「対策実行予定時間＋Ｘ時間」に示す時間にも自動実行可能である。このため、生成中対策案管理テーブルの自動実行可否欄に自動実行できる（Ｙｅｓ）ことのみを登録して（Ｓ１００７７）、処理を終了する。

図１９は、対策案実行予定時間指定インフェース２４０００を示す。状態監視プログラム８１０によって状態を検知し、アラートを出力する際に表示してもよいし、その状態に対する対策案生成開始の指示を入力部により受け付けたときの最初の起動画面として表示させてもよい。

対策案実行予定時間指定インタフェース２４０００は、対策実行予定日指定欄２４００１、対策実行予定時間指定スライダー２４００２、対策案生成ボタン２４００３を有する。管理者は、対策案実行予定時間指定インタフェース２４０００により、希望する時刻に採りうる対策案の生成を指示することができる。

対策実行予定日指定欄２４００１では、対策の実行を予定している日の入力を受け付ける。加えて、対策実行予定時間指定スライダー２４００２を左右に動かすことによって実行予定時間を指定する。対策案生成ボタン２４００３が押下されることにより、指定された対策予定日時に対策案を実行すると仮定して対策案生成処理を実行する。なお、実際の日時でなく、何日後に実行を予定するかなど、現在時刻から対策実行予定時までの時間数の入力を受け付けるようにしても良い。

図２０は、対策案一覧提示インタフェース２５０００を示す。図１３から図１８の処理によって生成した対策案一覧を提示するための画面である。対策案一欄提示インタフェース２５０００は、対策案一覧２５００１を有する。対策案一覧には、生成中対策案管理テーブル８０７に登録されている対策案が実行推奨度順に提示される。対策案ＩＤは、対策案を識別するための情報である。タスクＩＤは、対策案を構成するタスクを識別するための情報である。タスク種別は、タスクの種別を示す情報である。タスクパラメタは、タスクの実行に必要なパラメタを識別するための情報である。タスク実行権限は、各タスクの実行に必要な管理権限を示す情報である。応答時間は、対策案実行後の応答時間を示す情報である。実行時間は、対策実行に要する時間を示す情報である。実行コストは、対策実行に要するコストを示す情報である。影響ＶＭは、対策実行中に対策の影響が及ぶ可能性があるＶＭを示す情報である。自動実行可否は、対策案を自動実行できるか否かを示す情報である。対策案が自動実行できる場合はさらに、入力を受け付けた対策案の実行予定時間が対策案を自動実行できる最終タイミングか否かを示す情報を提示する。図２０の例では、自動実行可否欄がＹｅｓの場合に、対策を自動実行できる最終時間か否か（Ｙｅｓ ｏｒ Ｎｏ）を提示している。

なお、対策を自動実行できる最終時間か否か（Ｙｅｓ ｏｒ Ｎｏ）ではなく、自動実行できる最終時間や自動実行できる期限を表示させてもよい。例えば、対策案実行予定時間を１０：００とした場合に自動実行できるか否か、１１：００とした場合に自動実行できるか、１２：００とした場合に自動実行できるか、というように、現在時刻からＸ１、Ｘ２、Ｘ３・・・・Ｘｎと一定時間毎に自動実行可否判定処理を実行する。そして、自動実行可否判定がＹｅｓからＮｏに切り替わった時間の直前を自動実行できる期限として提示する。例えば、Ｘ３の時間では自動実行可と判定されたが、Ｘ４の時間では自動実行否として判定されたら、Ｘ３の時間を自動実行できる最終時間として提示する。

また、ある時間に自動実行否と判定されても、一定時間経過すると再度自動実行できるようになる場合もある。このようなケースに対応するために、自動実行できる最終タイミングか否か（Ｙｅｓ ｏｒ Ｎｏ）や自動実行期限ではなく、自動実行できる時間帯情報を管理者に提示してもよい。

また、管理者の判断の参考となるよう、実行推奨度１６１０を対策案一覧提示インタフェース２５０００に提示してもよい。

管理者が実行したい対策案のチェックボックスを選択して対策案実行のボタンを押下することにより、管理計算機２０１のＣＰＵ２１２が、選択された対策案実行のための次の処理を行う。ここで、自動実行可の場合には、他の管理者の承認処理を行わずに、自動実行制御を行うこととしてよい。

また、図１９に示したインタフェースにより管理者に対策実行予定時間を指定させ、図２０に示した対策案一覧画面により対策案を管理者に提示するのではなく、図２１のような画面２６０００を出力してもよい。画面２６０００は対策実行日を選択する対策実行日選択欄２６００１、時間別対策案リスト２６００２を有する。対策実行日選択欄２６００１に提示された日付一覧から対策を実行する日付が選択されると、時間別対策案リスト２６００２に時間帯毎に推奨対策案が表示される。

以上、実施例１では、計算機システムの構成とインフラリソースの使用傾向とを考慮して、管理者が指定した実行予定時間に実行可能な対策案を生成し、自動実行可否とあわせて提示することにより、システム管理負荷を軽減できる。

以下、実施例２について説明する。以下の説明においては、実施例１と異なる構成について特に詳細に説明し、実施例１と同様の構成については詳細な説明は省略する。実施例１では、管理者が指定した対策案の実行予定時間を受け付け、その時間に有効な対策案を生成、出力して管理者に提示する、と例示した。一方、実施例２では、対策案の実行予定時間の入力を受け付けるのではなく、対策を実行する時間も考慮して、より効果の高い対策案を生成し、自動実行する処理を行う。

ここでいう効果が高いとは、要求／許容要件をより満足することを指す。例えば、対策案の実行に要する時間や、対策案の実行によって影響が及ぶＶＭの数等は、対策案を実行するタイミングによって変化する。このため、より対策案の実行に要する時間が短く、影響が及ぶＶＭ数が少ない時刻に実行可能な対策案を生成し、自動実行可否を判断する。なお、実施例１と同様、実際に自動実行できる対策案は一定の条件に合致した場合のみとし、それ以外の場合は各管理者の権限に基づく実行許可を要する。

図２２は、実施例２における生成中対策案管理テーブル８０７である。

実施例２の生成中対策案管理テーブル８０７では、実行予定時間毎に対策案とその効果を管理することができる。実施例２の生成中対策案管理テーブル８０７では、実施例１で示した生成中対策案管理テーブル８０７が保持する情報に加えて、対策案の実行予定時間である実行予定時間１６１３を格納する。

図２３は、実施例２における対策案生成処理の流れを示すフローチャートである。実施例１と同様、対策案生成プログラム８１１は、例えば対策案生成指示の受付を契機として対策案生成処理を実行する。対策案生成プログラム８１１は、実施例１と同様に、状態監視プログラム８１０によって検知された状態と、その根本原因とを取得する。ここで、実施例１の実行予定時間に替えて対策実行最遅時間を取得する（Ｓ１０１００）。対策実行最遅時間とは、対策実行が許される最も遅い時間である。すなわち、状態が解消されるべき最遅時間、である。生成した対策案は、対策案が生成された時間から対策実行最遅時間で指定された時間の間の、要求／許容要件をより満足する時間に実行されることになる。対策実行最遅時間は、入力部により管理者からの入力を受け付けて取得することとしてよい。

対策案生成プログラム８１１は、対策案実行予定時間として、現在時刻から対策実行最遅時間で指定された時間までの任意の時間Ｘ１、Ｘ２・・・Ｘｎを指定して、Ｓ１０１０２からＳ１０１０７までの処理を繰り返し実行する。Ｘ１・・・Ｘｎは、例えば、一時間間隔（１０：００、１１：００、１２：００・・・）などと予め設定されてよい。

Ｓ１０１０２からＳ１０１０７の処理は、実施例１の対策案生成処理のＳ１０００１からＳ１０００６の処理と基本的に同じである。生成した対策案を生成中対策案管理テーブル８０７に登録する際に、Ｓ１０１０１で指定した対策案実行予定時間を時間１６１３に登録する。Ｓ１０１０７までの処理を実行後、対策案生成プログラム８１１は、生成中対策案管理テーブル８０７から、生成した対策案一覧を取得し、推奨度が最も高い対策案を取得し、出力する（Ｓ１０１０８）。

なお、Ｓ１０１０８で取得した対策案が自動実行可能と判断されている場合は、実行予定時間１６１３に登録された時間に自動実行する。実施例２においては、対策案生成指示を受け付けたことをもって自動実行を「特定の権限」に基づくと判断し、管理者による実際の対策案実行指示を受け付けることなく実行してもよい。また、推奨度が最も高い対策案が自動実行否である場合などは、後述の図２４のように、自動実行可能な対策案の中で推奨度が最も高い対策案を、あわせて表示し、管理者の入力を受け付けなければ、自動実行可能な対策案を優先して実行することとしてもよい。また、実施例１と同様、実行推奨度が高い順に対策案を複数表示させることとしてもよい。

図２４は、対策案一覧提示インタフェース２９０００を示す。対策案一覧提示インタフェース２９０００は、生じたそれぞれの状態に対する対策案を提示する。各々の状態に対する対策案としては、図２３の処理によって生成された対策案のうち、最も推奨度が高かった対策案を提示する。

なお、改善すべき状態が複数のリソース（ＶＭ）において発生した場合も、対策案の生成方法は図２３の対策案生成処理と基本は同じであるが、プールの枯渇時間の予測、ポート負荷閾値超過時間、予測性能を算出する際に、複数のタスクを実行したと仮定して算出する必要がある。また、状態が発生した順に対策案を生成してもよいが、改善すべき状態のリソースが複数検知された状況で対策案（タスク）を生成する場合は、状態の深刻さ（性能遅延であれば要求性能と現状の性能との差分の大きさ、等）によって、対策案を生成する順序を決定してもよい。

対策案一覧２９００１には、図２０の対策案一覧２５００１の項目とほぼ同様の内容を含むが、自動実行可否の情報に替えて、自動実行可の対策案が実行される実行予定時間を表示する。実行予定時間には、生成中対策案管理テーブル８０７の実行予定時間１６１３に登録された時間を提示してもよいし、実行予定時間１６１３に登録された時間までのカウントダウンを表示してもよい。また、自動実行可の場合は、実行をキャンセルするボタンを表示し、自動実行をキャンセルすることを管理者に許可してもよい。実行予定時間までにキャンセルボタンの押下を受け付けなければ、ＣＰＵ２１２は当該対策案の自動実行制御を行う。

また、自動実行できないが通常の実行であれば可能な対策案も表示する場合は、対策案の提示とともに実行ボタンを表示し、各管理者の承認等を前提とする通常の対策案実行を選択できるようにしてもよい。図２４の例では、効果が高いと判断された時間が実行時間として指定されているが、入力部により管理者の実行時間指定を受け付けることとしてもよい。また、実行推奨度が高い順に対策案を複数表示させる場合は、自動実行可能な対策案のうちで、推奨度が高い対策案を優先して自動実行する設定としておき、自動実行が予定されている対策案の実行がキャンセルされたら、次に推奨度が高く自動実行可能な対策案を自動実行することとしてもよい。

以上、実施例２では、より効果の高い時間帯に対策案を自動実行し、管理負荷を軽減することができる。

以下の説明においては、実施例１と異なる構成について特に詳細に説明し、実施例１と同様の構成については詳細な説明は省略する。実施例１では、状態監視プログラム８１０によって発見された状態を解消するタスクと、その対策案を実行することによって新たに発生する状態を解消するタスクとを一つの対策案として提示していた。実施例３では、それらを分割して提示、実行できるようにする。

これにより、対策案を構成する全てのタスクを実行するには、対策にかけられる時間が不足する場合でも、一部のタスクのみを即時実行することで、最低限解消すべき状態については対策をすることができる。ここでいう最低限解消すべき状態の対策とは、例えば、状態監視プログラム８１０によって検知された状態についてのみ解消することである。ただし、この場合でも、当該状態への対策に伴って生じる新たな改善すべき状態や、その大きさについての情報を出力することで、対策案を構成する全てのタスクを実行しないことによる不利益を管理者が把握できるようにする。

図２５は、実施例３における生成中対策案管理テーブル８０７である。実施例３の生成中対策案管理テーブル８０７では、対策案を構成するタスク毎にそのタスクを実行した時の効果を管理することができる。実施例３の生成中対策案管理テーブル８０７では、実施例１で示した生成中対策案管理テーブル８０７が保持する情報に加えて、タスク毎の実行に要する実行時間１６１４、タスク毎に要する実行コスト１６１５、タスク実行によって解決される状態１６１６、タスク実行によって残される（新たに生じる）状態１６１７を格納する。

タスク毎の実行時間、タスク毎の実行コストは、図１５の対策案算出処理の対策案Ｘの実行に要する時間、対策案Ｘの実行に要するコストを算出する際に（Ｓ１００３０、Ｓ１００３２の処理）、その途中経過として算出した各タスクの実行時間やコストを登録すればよい。また、解決される状態１６１６には、図１３の対策案生成処理のＳ１００００で受け付けた状態を登録する。残される状態１６１７には、図１４のプール別対策案生成処理のＳ１００１５で特定した、要求を満たしていないＶＭに関する情報を登録する。

図２６は、実施例３における実行タスク選択インフェース３１０００を示す。実施例１で示した対策案一覧提示インタフェースを用いて、管理者による実行する対策案の選択を受け付けた後に、実行タスク選択インタフェース３１０００を出力してもよい。

図２６の実行タスク選択インタフェース３１０００は、対策案詳細３１００１、実行ボタン（活性）３１００２、実行ボタン（非活性）３１００３を有し、対策案を構成するタスク毎に実行ボタンを提示している。図２６のタスク２はタスク１の実行により生じる状態（ＶＭ３応答遅延）を解消するタスクであるため、タスク１実行後に初めて実行ボタンを活性化させる。

以上、実施例３では、生成した対策案を構成するタスクのうち、最低限の状態を解消するタスクのみを即時実行し、残りのタスクについては別の時間、例えば、Ｓ１００００で管理者が指定した対策案実行予定時間に実行することができる。これにより、全てのタスクを実行する時間がない場合でも、最低限解消すべき状態についての対策を行うことができ、システム管理の精度を向上させることができる。

１０１…ホスト計算機、１０３…ストレージシステム、２０１…管理計算機、２５１…コントローラ、８０１…ＶＶＯＬ管理テーブル、８１１…対策案生成プログラム

Claims (10)

1. ホスト計算機とストレージ装置とに接続され、
   前記ストレージ装置により前記ホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第１の要求性能を示す情報を含む仮想論理ボリューム管理情報と、
   前記ストレージ装置により提供される、データの物理的な記憶領域群で構成され、前記ホスト計算機からのライトアクセスに応じて前記仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプール、の使用状況に関する情報を示すプール管理情報と、
   を格納するメモリと、
   前記メモリに接続され、
   前記ストレージ装置へのアクセスに関する性能情報を前記ホスト計算機により取得し、
   取得した前記アクセスに関する性能情報が、前記第1の要求性能を満たすか否かを判断し、
   前記判断の結果、前記第1の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第１の要求性能を示す情報を含む仮想論理ボリューム管理情報に基づいて前記判断の結果の原因である仮想論理ボリュームを特定し、
   前記プール管理情報に基づき、各プールに含まれる前記データの物理的な記憶領域の容量消費傾向を算出し、
   前記特定した仮想論理ボリュームの情報と、算出した前記容量消費傾向とに基づいて、所定の時間後に実施し得る前記第1の要求性能が満たされるための複数の対策案を生成し、
   生成した前記複数の対策案のそれぞれについて、前記第1の要求性能及び予め定められた許容ダウンタイムと、各対策案を実行したと仮定した場合の前記ストレージ装置へのアクセスに関する性能及び前記対策案実行に要する時間とに基づいて、実行推奨度を算出し、
   生成した前記対策案及び算出した前記実行推奨度を共に出力装置に出力するプロセッサと、
   を有することを特徴とする管理計算機。
2. 前記第1の要求性能は、前記ホスト計算機で実行される仮想マシンについて予め定められており、
   前記プロセッサは、
   各仮想論理ボリュームの応答性能情報を前記ストレージ装置より取得して、前記仮想論理ボリューム管理情報に格納し、
   前記仮想マシンから、前記仮想マシンに提供される前記仮想論理ボリュームへのアクセスに関するＶＭ応答性能情報を、前記ホスト計算機より取得して、前記判断を行い、
   取得した前記ＶＭ応答性能情報が前記第1の要求性能を満たしていなければ、前記仮想論理ボリューム管理情報に基づき、前記仮想マシンに提供される仮想論理ボリュームの応答性能が、前記第1の要求性能に対応する第2の要求性能を満たすか否かを判断し、
   前記第2の要求性能が満たされていない場合、前記仮想論理ボリュームが、前記第1の要求性能が満たされていない状態の原因であると特定する
   ことを特徴とする請求項１に記載の管理計算機。
3. 前記メモリは、さらに、前記ストレージ装置の有するポートの性能情報を示すポート管理情報を格納し、
   前記プロセッサは、
   前記ポート管理情報に基づき、前記ホスト計算機からのアクセスに用いられるポートの負荷増加傾向を算出し、
   算出した前記負荷増加傾向にさらに基づいて、前記対策案を生成し、前記出力装置に出力する
   ことを特徴とする請求項１に記載の管理計算機。
4. 前記対策案は、前記仮想論理ボリュームの他のプールへの移動、前記仮想マシンの他のホスト計算機への移動、及び、前記プールへの前記データの物理的な記憶領域の追加のタスクのうち、少なくとも1種類のタスクにより構成される
   ことを特徴とする請求項２の記載の管理計算機。
5. 前記プロセッサは、
   前記プールが、前記状態の原因である前記仮想論理ボリュームの移動に必要な空き容量を前記所定の時間後に備えているか否かを、算出した前記容量消費傾向を用いて予測し、
   前記予測の結果が肯定的である場合に、前記プールへの前記仮想論理ボリュームの移動を、前記対策案を構成するタスクとして採用する
   ことを特徴とする請求項４に記載の管理計算機。
6. 前記メモリはさらに、
   実行順序に依存関係を有するタスクを第1の権限に基づき一連の処理として実行する自動実行制御を、前記プロセッサに許可するポリシを示す自動実行ポリシ情報を格納し、
   前記プロセッサは、
   前記自動実行ポリシ情報に基づき、生成した前記対策案の自動実行の可否を判断し、
   判断結果を前記出力装置に出力する
   ことを特徴とする請求項４に記載の管理計算機。
7. 前記メモリは、さらに、前記タスクの種別毎の実行権限情報を格納し、
   前記プロセッサは、前記実行権限情報と前記自動実行ポリシ情報とに基づいて、前記対策案の自動実行可否判断を行う
   ことを特徴とする請求項６に記載の管理計算機。
8. 前記プロセッサは、
   所定の時間幅の複数の時刻のそれぞれにおいて実施し得る前記対策案を生成し、
   生成した前記対策案の中で、前記実行推奨度が最も高い対策案を前記出力装置に出力する
   ことを特徴とする請求項１に記載の管理計算機。
9. 前記プロセッサは、
   所定の時間幅の複数の時刻のそれぞれにおいて実施し得る前記対策案を生成し、
   前記自動実行可否判断の結果、自動実行可能であると判断した対策案の中で、前記実行推奨度が最も高い対策案の自動実行制御を行う
   ことを特徴とする請求項７に記載の管理計算機。
10. ホスト計算機とストレージ装置の管理方法であって、
    前記ストレージ装置により前記ホスト計算機に提供される仮想論理ボリュームの情報であって、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報、および、前記ホスト計算機から前記ストレージ装置へアクセスする際に満たされるべき第１の要求性能を示す情報を含む仮想論理ボリューム管理情報と、
    前記ストレージ装置により提供される、データの物理的な記憶領域群で構成され、前記ホスト計算機からのライトアクセスに応じて前記仮想論理ボリュームに前記データの物理的な記憶領域を割り当てる複数のプール、の使用状況に関する情報を示すプール管理情報と、
    を記憶し、
    前記ストレージ装置へのアクセスに関する性能情報を前記ホスト計算機より取得し、
    取得した前記アクセスに関する性能情報が、前記第1の要求性能を満たすか否かを判断し、
    前記判断の結果、前記第1の要求性能が満たされていなければ、前記ホスト計算機を識別する情報、前記仮想論理ボリュームを識別する情報および前記第１の要求性能を示す情報を含む前記仮想論理ボリューム管理情報に基づいて前記判断の結果の原因である仮想論理ボリュームを特定し、
    前記プール管理情報に基づき、各プールに含まれる前記データの物理的な記憶領域の容量消費傾向を算出し、
    前記特定した仮想論理ボリュームの情報と、算出した前記容量消費傾向とに基づいて、所定の時間後に実行し得る前記第1の要求性能が満たされるための複数の対策案を生成し、
    生成した前記複数の対策案のそれぞれについて、前記第1の要求性能及び予め定められた許容ダウンタイムと、各対策案を実行したと仮定した場合の前記ストレージ装置へのアクセスに関する性能及び前記対策案実行に要する時間とに基づいて、実行推奨度を算出し、
    生成した前記対策案及び算出した前記実行推奨度を共に出力装置に出力する
    ことを特徴とする管理方法。

Images