JP6035363B2 - 管理計算機、計算機システム、及び管理方法 - Google Patents

Description

本発明は、管理計算機、計算機システム、及び管理方法に関し、例えば、ストレージシステムにおけるストレージボリュームプールの階層を管理するための技術に関する。

近年、シンプロビジョニングと呼ばれる技術（例えば、特許文献１参照）がストレージシステムにおいて盛んに用いられてきている。ここで、シンプロビジョニングとは、仮想ボリューム（仮想論理ボリュームともいう）をホスト計算機に割り当てる技術である。また、仮想ボリュームとは、ホスト計算機から仮想ボリュームへデータの書き込みがあって初めて、プール化された論理ボリューム（以降、プールボリュームと呼ぶ）から、物理ディスク上の実データ保存領域（以降、ページと呼ぶ）が割り当てられるボリュームである。

また、特許文献２に開示されているように、仮想ボリュームに割り当てられたページに対するホスト計算機からのＩ／Ｏ量に応じて、当該ページを、当該ページの格納されているプールボリュームから、性能やコストの異なる別のプールボリュームへ移行させる（再配置処理）ように運用されている。つまり、ストレージ装置は仮想ボリュームを構成する各ページに対するＩ／Ｏ数を記録し（以降、この記録の実行をＩ／Ｏモニタと呼ぶ）、Ｉ／Ｏ数に応じてページの配置先階層（性能およびコストで分類したプールボリューム）を決定する。例えば高Ｉ／Ｏ数のページから順に上位階層（高性能かつ高コストのプールボリューム）に配置する。

特開２００３−１５９１５号公報 特開２００７−６６２５９号公報

しかしながら、ストレージ装置は、実際にＩ／Ｏを発行しているホスト計算機上のタスクが何であるかを認識しないため、仮想ボリュームを構成する各ページに対する全Ｉ／Ｏを記録してしまう。このため、高レスポンス不要のタスクのＩ／Ｏ数が一時的に多くなる場合等に、高レスポンス要のタスクのデータを格納するページ群に対するＩ／Ｏ数が、高レスポンス不要のタスクのデータを格納するページ群に対するＩ／Ｏ数に比べて相対的に低くなり、結果として高レスポンス要のタスクのデータを格納するページ群が下位階層に配置されてしまい、性能が劣化する可能性があった。

本発明はこのような状況に鑑みてなされたものであり、タスクの種類および稼働状態に応じて再配置処理における移動先階層を決定するための判断基準を適切に設定し、高レスポンス要のタスクのデータが下位階層に配置されて性能が劣化することを防ぐための技術を提供するものである。

上記課題を解決するために、本発明では、ストレージは、レスポンス性能が異なる複数の物理記憶デバイスと、物理記憶デバイスの実記憶領域、該実記憶領域から構成されるプール、該プールから割り当てられる仮想論理ボリューム、及び業務用計算機上で実行されるタスクから実記憶領域に対して発行されるＩ／Ｏ数を対応付けるボリューム管理情報を格納するメモリと、業務用計算機に仮想論理ボリュームに含まれる実記憶領域を割り当てる処理、及びボリューム管理情報のＩ／Ｏ数を参照して、レスポンス性能が異なる物理記憶デバイスの実記憶領域間でデータを移動する再配置処理を実行するプロセッサと、を有する。また、管理計算機は、タスク及び該タスクを再配置の対象として監視するか否かを示す監視要否フラグを含むタスク監視情報を格納するメモリと、タスク監視情報を参照して、監視要否フラグが否となっているタスクから発生するＩ／Ｏについては、ボリューム管理情報のＩ／Ｏ数に反映しないことをストレージに行わせるプロセッサと、を有している。

本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、本発明の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。

本明細書の記述は典型的な例示に過ぎず、本発明の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。

本発明の一実施形態によれば、ホスト上のタスクの種類および稼働状態に応じて、再配置処理の対象とするか否か（Ｉ／ＯモニタのＯＮ／ＯＦＦ）を制御することで、高レスポンス要のタスクのデータが下位階層に配置されて性能が劣化することを防ぐことが可能となる。また、ユーザは、どのタスクを再配置処理の対象とすれば良いか（どのタスクのＩ／ＯモニタのＯＮ／ＯＦＦを制御すればよいか）を容易に判断できるようになる。

本発明の実施形態による計算機システム（ストレージシステム）の概略構成を示す図である。 本発明の実施形態におけるホスト計算機および管理サーバのハードウェアシステム構成例を示す図である。 本発明の実施形態におけるストレージ装置のハードウェアシステム構成例を示す図である。 本発明の実施形態における計算機システムのソフトウェアシステム構成例を示す図である。 本発明の実施形態におけるストレージ装置のソフトウェアシステム構成例を示す図である。 本発明の実施形態における論理ボリュームと物理ディスクの関係例を示す概念図である。 本発明の実施形態における論理ボリューム管理テーブルの構成例を示す図である。 本発明の実施形態における仮想ボリュームと論理ボリュームの関係例を示す概念図である。 本発明の実施形態における仮想ボリューム管理テーブルの構成例を示す図である。 本発明の実施形態におけるボリュームプール管理テーブルの構成例を示す図である。 本発明の実施形態におけるプール階層管理テーブルの構成例を示す図である。 本発明の実施形態における未使用領域管理テーブルの構成例を示す図である。 本発明の第１の実施形態における仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブルの構成例を示す図である。 本発明の第１の実施形態におけるＩ／Ｏモニタ処理を説明するためのフローチャートである。 本発明の実施形態におけるページ階層再配置処理を説明するためのフローチャートである。 本発明の実施形態における再配置ページ管理テーブルの構成例を示す図である。 本発明の実施形態におけるホストボリューム管理テーブルの構成例を示す図である。 本発明の実施形態におけるＩ／Ｏモニタ要否管理テーブルの構成例を示す図である。 本発明の第１の実施形態におけるＩ／ＯモニタのＯＮ／ＯＦＦ制御処理を説明するためのフローチャートである。 本発明の実施形態におけるタスク稼働情報の構成例を示す図である。 本発明の実施形態におけるＩ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面の構成例を示す図である。 本発明の実施形態における再配置容量管理テーブルの構成例を示す図である。 本発明の実施形態におけるタスク稼働情報管理テーブルの構成例を示す図である。 本発明の実施形態におけるＩ／ＯモニタＯＦＦ推奨表示処理を説明するためのフローチャートである。 本発明の実施形態におけるタスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブルの構成例を示す図である。 本発明の実施形態におけるＩ／Ｏモニタ制御設定推奨表示処理を説明するためのフローチャートである。 本発明の第２の実施形態におけるページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブルの構成例を示す図である。 本発明の第２の実施形態におけるＩ／Ｏモニタ処理を説明するためのフローチャートである。 本発明の第２の実施形態におけるＩ／ＯモニタのＯＮ／ＯＦＦ制御処理を説明するためのフローチャートである。 本発明の第３の実施形態におけるＩ／ＯモニタのＯＮ／ＯＦＦ制御処理を説明するためのフローチャートである。 本発明の第４の実施形態におけるＩ／ＯモニタのＯＮ／ＯＦＦ制御処理を説明するためのフローチャートである。 本発明の実施形態におけるＩ／Ｏモニタ制御設定推奨表示画面の構成例を示す図である。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。

なお、以後の説明では「テーブル」形式によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

以下では「プログラム」を主語（動作主体）として本発明の実施形態における各処理について説明を行うが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

本発明の各実施形態は、タスクの種類および稼働状態に応じてＩ／ＯモニタのＯＮ／ＯＦＦを制御し、高レスポンス要のタスクのデータが下位階層に配置されて性能が劣化することを防ぐことができる技術を提供する。また、各実施形態は、Ｉ／ＯモニタのＯＮ／ＯＦＦ制御を実行する場合、ユーザがどのタスクについてＩ／ＯモニタのＯＮ／ＯＦＦを制御することを要するかについて、判断するための有効な情報を提示する。

（１）第１の実施形態
図１から図２６、及び図３２に基づいて、本発明による第１の実施形態について説明する。

＜計算機システムの構成＞
図１は、本発明の実施形態による計算機システム（ストレージシステム、ＩＴシステムとも言う）の全体概要を示すブロック図である。

計算機システム１０は、少なくとも１つのホスト計算機１００（単に、「ホスト」ということもある）と、少なくとも１つの管理サーバ（「管理計算機」とも言う）２００と、１つ以上のストレージ装置（「ストレージサブシステム」とも言う）４００と、を有し、互いにＬＡＮ３０１で接続されている。また、ストレージ装置４００とホスト計算機１００は互いにＳＡＮ３００で接続されている。なお、ホスト計算機は、複数存在してもよく、その場合は管理用のＬＡＮ３０１に加えてデータ転送用のＬＡＮでホスト計算機が互いに接続されていてもよい。

＜ホスト計算機の内部構成＞
図２Ａは、ホスト計算機１００の内部構成を示す図である。ホスト計算機１００は、１つ以上のＣＰＵ１１０と、１つ以上のメモリ１１１と、１つ以上のＳＡＮアダプタ１１２と、１つ以上のＬＡＮアダプタ１１３と、１つ以上のストレージデバイス１１４と、を有し、それらは互いに内部バス１１５で接続されている。

ホスト計算機１００は、ＳＡＮアダプタ１１２を介してストレージ装置４００と接続されている。また、ホスト計算機１００は、ＬＡＮアダプタ１１３を介して管理サーバ２００に接続されている。なお、ストレージデバイス１１４は必ずしも備えなくてもよい。備えない場合は、ストレージ装置４００内のボリュームをソフトウェアの記憶領域として用いるようにすると良い。

＜管理サーバの内部構成＞
図２Ｂは、管理サーバ２００の内部構成を示す図である。管理サーバ２００の内部構成はホスト計算機１００と同様だが、必ずしもＳＡＮアダプタを備えていなくても良い。

管理サーバ２００は、ＬＡＮアダプタ２１２を介して、ストレージ装置４００およびホスト計算機１００と接続されている。

＜ストレージ装置の内部構成＞
図３は、ストレージ装置４００の内部構成を示す図である。ストレージ装置４００は、１つ以上のコントローラ４１０および１つ以上の物理ディスク４１１を有する。

コントローラ４１０は、１つ以上のＣＰＵ４１２と、１つ以上のメモリ４１３と、１つ以上のＮＶＲＡＭ４１４と、１つ以上のキャッシュメモリ４１５と、１つ以上のバックエンドインターフェース４１６および４１７と、１つ以上のＬＡＮアダプタ４１８と、１つ以上のＳＡＮアダプタ４１９と、を有し、それらは相互に内部バス４２０で接続されている。

コントローラ４１０は、バックエンドインターフェース４１６および４１７を介して物理ディスク４１１と接続されている。また、ストレージ装置４００はＬＡＮアダプタ４１８を介して管理サーバ２００と接続されている。また、ストレージ装置４００はＳＡＮアダプタ４１９を介してホスト計算機１００と接続されている。また、物理ディスク４１１はＳＡＳ （Serial Attached SCSI (Small Computer System Interface））ディスク、ＳＡＴＡ （Serial Advanced Technology Attachment）ディスク、ＳＳＤ （Solid State Drive）といった複数の種別のディスクから構成されていてもよい。

＜計算機システムのソフトウェア構成＞
図４は、本実施形態の計算機システム１０のソフトウェア構成の概要を示すブロック図である。ホスト計算機１００上では、あるアプリケーションによる１つ以上のタスク５００と、１つ以上のＯＳ（Operating System）５０１が動作する。これらソフトウェアはストレージデバイス１１４またはストレージ装置４００に格納されており、メモリ１１１にロードされ、ＣＰＵ１１０を用いて実行される。

また、管理サーバ２００上では、管理ソフトウェア６００が動作する。管理ソフトウェア６００は、メモリ２１１にロードされ、ＣＰＵ２１０を用いて実行される。

さらに、ストレージ装置４００上には１つ以上のボリュームプール７００があり、これらから作成された１つ以上の仮想ボリューム７０１（後述）がある。仮想ボリューム７０１は、ＳＡＮ３００を介してホスト計算機１００に割り当てられている。なお、本システム構成として仮想ボリューム７０１だけでなく、後述の論理ボリューム（実ボリューム）が混在していてもよい。

ＯＳ５０１は、複数のタスク５００を管理し、実行すると共に、仮想ボリューム７０１および論理ボリューム７０２を認識し、管理する。

管理ソフトウェア６００は、ホスト計算機１００およびストレージ装置４００から構成情報を取得し、管理テーブルに格納する。管理ソフトウェア６００の詳細については後述する。

＜ストレージ装置のソフトウェア構成＞
図５は、ストレージ装置４００内のソフトウェア構成の概要を示す図である。ストレージ装置４００上では、ストレージエージェント７０３、仮想ボリュームマネージャ７０４、及び論理ボリュームマネージャ７０５が動作している。これらは物理ディスク４１１またはＮＶＲＡＭ４１４に格納されており、メモリ４１３にロードされ、ＣＰＵ４１２を用いて実行される。

論理ボリュームマネージャ７０５は、物理ディスク４１１から１つ以上の論理ボリューム７０２を作成し、論理ボリューム７０２と物理ディスク４１１の間のマッピングを管理するソフトウェアである。

仮想ボリュームマネージャ７０４は、ボリュームプール７００に登録された論理ボリューム７０２から一つ以上の仮想ボリューム７０１を作成し、仮想ボリューム７０１と、論理ボリューム７０２の間のマッピングを管理するソフトウェアである。

仮想ボリュームマネージャ７０４は、仮想ボリューム７０１にデータの書き込みがあった際、論理ボリューム７０２から未使用の領域を仮想ボリューム７０１の書き込みがあった場所に割り当てるソフトウェアである。

＜論理ボリュームと物理ディスクの関係＞
図６は、論理ボリューム７０２と物理ディスク４１１の関係を示す概念図である。図６の例では、論理ボリューム７０２は４つの物理ディスク８００、８０１、８０２、８０３から構成されているものとする。１−１、１−２、１−３…とラベル付けされた物理ディスク内の領域は、あらかじめ決められたサイズに区切られた領域であり、ストライプと呼ばれる。また、Ｐ１、Ｐ２…とラベル付けされた領域は、対応するストライプのパリティ情報を格納する領域であり、パリティストライプと呼ばれる。

論理ボリュームマネージャ７０５が、論理ボリューム７０２と物理ディスク４１１のマッピング関係を管理するために、ボリューム管理テーブルがストレージ装置４００内に保持されている。ボリューム管理テーブルの詳細については後述する。

＜ボリューム管理テーブル＞
図７は、ストレージ装置４００が保持するボリューム管理テーブルの構成例を示す図である。ボリューム管理テーブルは、論理ボリュームＩＤ列９００と、ディスク列９０１と、ＲＡＩＤレベル列９０２と、ストライプサイズ列９０３と、ディスク種別列９０４とによって構成される。

論理ボリュームＩＤ列９００には、論理ボリュームマネージャ７０５が各ボリュームに割り当てられ、各ボリュームを特定・識別するための識別子（識別情報）が登録される。

ディスク列９０１には、論理ボリュームを構成する物理ディスクを特定・識別するための識別子（識別情報）が登録される。

ＲＡＩＤレベル列９０２には、論理ボリュームの構成に使用されているＲＡＩＤレベルが登録される。

ストライプサイズ列には、論理ボリュームの構成に使用されているストライプのサイズが登録される。

ディスク種別列９０４には論理ボリュームを構成する物理ディスクの種別が登録される。

＜仮想ボリュームと論理ボリュームの関係＞
図８は、仮想ボリューム７０１と論理ボリューム７０２の関係を示す概念図である。多くの場合、仮想ボリュームへの領域割り当ては物理ディスクの領域を直接割り当てるのではなく、図８のように論理ボリュームを構成した後、論理ボリューム内の一部領域を割り当てる形態を取る。

また、仮想ボリュームマネージャ７０４（図５）は、仮想ボリューム７０１とボリュームプール７００に含まれる論理ボリューム７０２との関係や、ボリュームプール内における論理ボリューム７０２の階層および使用状況を管理する。このため、仮想ボリューム管理テーブル１１００、ボリュームプール管理テーブル１２００、プール階層管理テーブル１３００、未使用領域管理テーブル１４００がストレージ装置４００内に保持される。なお、仮想ボリューム管理テーブル１１００、ボリュームプール管理テーブル１２００、プール階層管理テーブル１３００、未使用領域管理テーブル１４００の詳細については後述する。

＜仮想ボリューム管理テーブルの構成例＞
図９は、ストレージ装置４００が保持する仮想ボリューム管理テーブル１１００の構成例を示す図である。仮想ボリューム管理テーブル１１００は、仮想ボリュームＩＤ列１１０１と、開始ＬＢＡ列１１０２と、終了ＬＢＡ列１１０３と、プールＩＤ列１１０４と、ページＩＤ列１１０５と、によって構成される。

仮想ボリュームＩＤ列１１０１には、仮想ボリュームに付与され、それを特定・識別するための識別子（識別情報）が登録される。

開始ＬＢＡ列１１０２には、仮想ボリューム内の領域の開始ＬＢＡが登録される。終了ＬＢＡ列１１０３には、仮想ボリューム内の領域の終了ＬＢＡが登録される。

プールＩＤ列１１０４には、仮想ボリュームに対して領域を割り当てているボリュームプールを特定・識別するための識別子（識別情報）が登録される。

ページＩＤ列１１０５には、仮想ボリューム内の各領域（開始ＬＢＡと終了ＬＢＡで指定された領域）に対応するページ（詳細後述）を特定・識別するための識別子（識別情報）が登録される。

＜ボリュームプール管理テーブル＞
図１０は、ストレージ装置４００が保持するボリュームプール管理テーブル１２００の構成例を示す図である。

ボリュームプール管理テーブル１２００は、プールＩＤ列１２０１と、ページＩＤ列１２０２と、論理ボリュームＩＤ列１２０３と、開始ＬＢＡ列１２０４と、終了ＬＢＡ列１２０５と、ストレージＩ／Ｏ数列１２０６と、によって構成される。

プールＩＤ列１２０１には、ボリュームプールに付与され、それを特定・識別するための識別子（識別情報）が登録される。

ページＩＤ列１２０２には、ページに付与され、それを特定・識別するための識別子（識別情報）が登録される。なお、ここでページとは、仮想ボリューム７０１に対してボリュームプール７００から割り当てられる領域の単位である。各ページは、ボリュームプール内のいずれかの論理ボリュームに配置される。

論理ボリュームＩＤ列１２０３には、ページの配置先の論理ボリュームを特定・識別するための識別子（識別情報）が登録される。

開始ＬＢＡ列１２０４には、論理ボリューム内におけるページの開始ＬＢＡが登録される。また、終了ＬＢＡ列１２０５には、論理ボリューム内におけるページの終了ＬＢＡが登録される。開始ＬＢＡ及び終了ＬＢＡによって各ページのサイズを知ることができる。
一般的に、ページサイズは固定であるが、開始・終了ＬＢＡを適宜設定することにより、各ページを異なるサイズとして登録することもできる。

ストレージＩ／Ｏ数列１２０６には、各ページに対して発行されたＩ／Ｏ数が記録される。図１０では、プール２についてはＩ／Ｏ数カウント不要と設定されているため、プール２のストレージＩ／Ｏ数１２０６は全て「０」となっている。ストレージＩ／Ｏ数１２０６の詳細については後述する。

＜プール階層管理テーブル＞
図１１は、ストレージ装置４００が保持するプール階層管理テーブル１３００の構成例を示す図である。

プール階層管理テーブル１３００は、プールＩＤ列１３０１と、階層列１３０２と、論理ボリュームＩＤ列１３０３と、によって構成される。

プールＩＤ列１３０１には、ボリュームプールを特定・識別するための識別子（識別情報）が登録される。

階層列１３０２には、ボリュームプール内に設定されている階層が登録される。なお、階層は、論理ボリュームのディスク種別やＲＡＩＤレベルに基づいて決定されるが、ユーザが定義してもよい。

論理ボリュームＩＤ列１３０３には、各階層に所属する論理ボリュームを特定・識別するための識別子（識別情報）が登録される。

図１１からは、例えば、プール１が、Ｔｉｅｒ０とＴｉｅｒ１の２つの階層から構成され、Ｔｉｅｒ０は論理ボリューム１及び２、Ｔｉｅｒ１は論理ボリューム０及び３から構成されていることが分かる。

＜未使用領域管理テーブル＞
図１２は、ストレージ装置４００が保持する未使用領域管理テーブル１４００の構成例を示す図である。

未使用領域管理テーブル１４００は、各論理ボリュームにおいて使用されていない領域を管理するテーブルであり、論理ボリュームＩＤ列１４０１と、開始ＬＢＡ列１４０２と、終了ＬＢＡ列１４０３と、によって構成される。

論理ボリュームＩＤ列１４０１には、ボリュームプール７００に登録されている論理ボリュームを特定・識別するための識別子（識別情報）が登録される。

開始ＬＢＡ列１４０２および終了ＬＢＡ列１４０３には、論理ボリューム７０２の中で未使用の領域１００４の開始ＬＢＡおよび終了ＬＢＡ列がそれぞれ登録される。

通常、各論理ボリュームの領域はアドレス順に論理ボリュームに割り当てられて使用されていくが、使用中のボリュームが解放されて未使用領域になる場合もある。このため、図１２に示されるように、未使用領域が不連続になる場合がある。

＜仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル＞
仮想ボリュームマネージャ７０４は、ホスト計算機１００から、仮想ボリューム７０１を構成するページに対して発行されたＩ／Ｏ数（ストレージＩ／Ｏ数）を記録し、記録したストレージＩ／Ｏ数に基づいて定期的にページの配置先の階層を決定しページを移動する。本明細書では、ストレージＩ／Ｏ数を記録することをＩ／Ｏモニタ、ページの配置先の階層を決定しページを移動することをページ階層再配置（再配置処理）と呼ぶこととする。

仮想ボリュームマネージャ７０４は、Ｉ／Ｏモニタおよびページ階層再配置のため、前述の仮想ボリューム管理テーブル１１００、ボリュームプール管理テーブル１２００、プール階層管理テーブル１３００、未使用領域管理テーブル１４００に加え、ストレージ装置４００に保持されている仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブルを参照する。

図１３は、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００の構成例を示す図である。

仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００は、仮想ボリュームＩＤ列１５０１と、Ｉ／ＯモニタＯＮ／ＯＦＦ列１５０２と、によって構成される。

仮想ボリュームＩＤ列１５０１には、仮想ボリュームを特定・識別するための識別子（識別情報）が登録される。

Ｉ／ＯモニタＯＮ／ＯＦＦ列１５０２には、Ｉ／Ｏモニタ処理時に当該仮想ボリュームに対するＩ／Ｏ数を記録する（ＯＮ）か否（ＯＦＦ）かが登録される。なお、このＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の情報に関しては、初期値としてデフォルト値が設定されているが、システムを順次運用していくうちに、後述の図１９の処理によって値（ＯＮ／ＯＦＦ）は変化するようになっている。

＜Ｉ／Ｏモニタ処理＞
図１４は、仮想ボリュームマネージャ７０４によって実行されるＩ／Ｏモニタ処理を説明するためのフローチャートである。本処理はホスト計算機１００からストレージ装置４００内の仮想ボリューム７０１に対してＩ／Ｏが発行されたことを契機として開始される（ステップ１６００）。以下、ステップごとに説明を記述する。
ステップ１６０１：仮想ボリュームマネージャ７０４は、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００を参照し、Ｉ／Ｏ発行先の仮想ボリュームのＩ／ＯモニタがＯＮになっているかを確認する。ＯＮであれば（ステップ１６０１でＹｅｓの場合）、処理はステップ１６０２に移行する。ＯＦＦであれば（ステップＳ１６０１でＮｏの場合）、処理は終了（ステップ１６０３）する。

ステップ１６０２：仮想ボリュームマネージャ７０４は、ボリュームプール管理テーブル１２００の、Ｉ／Ｏ発行先のページのページＩＤおよびボリュームプールのプールＩＤで決定される行のストレージＩ／Ｏ数列１２０６の数字を１つ増加させる。

なお、ストレージＩ／Ｏ数の最新の傾向を得るため、ストレージＩ／Ｏ数列１２０６は一定時間ごとに０にリセットされるが、このときリセット前のストレージＩ／Ｏ数を履歴として保持しておいてもよい。この場合、ボリュームプール管理テーブル１２００はそのストレージＩ／Ｏ数が記録された時間帯情報を保持する。つまり、この場合、ボリューム管理テーブル１２００は、図２３のようになる。

また、Ｉ／ＯモニタのＯＮ／ＯＦＦは仮想ボリューム単位でなく、ホスト計算機１００のＳＡＮアダプタ１１２の識別子であるＷＷＮ単位で実行してもよい。この場合、ステップ１６０１において、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００の代わりに、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００の仮想ボリュームＩＤ列１５０１をホストＷＷＮ列で置き換えたものを使用し、Ｉ／Ｏ発行元のＷＷＮによってＩ／Ｏ記録の有無を判定する。つまり、Ｉ／Ｏ発行元のＩ／Ｏ数がカウントされることになる。

＜ページ階層再配置処理＞
図１５は、仮想ボリュームマネージャ７０４によって実行されるページ階層再配置処理を説明するためのフローチャートである。本処理は一定時間の経過、あるいはユーザの手動実行を契機として、各ボリュームプールに対して実行開始される（ステップ１７００）。以下、ステップごとに説明を記述する。

ステップ１７０１：仮想ボリュームマネージャ７０４は、ボリュームプール管理テーブル１２００のストレージＩ／Ｏ数列１２０６に記録された、各ページのストレージＩ／Ｏ数に基づいて、各ページの配置先階層を決定する。

配置先階層の決定方法は、例えば、ストレージＩ／Ｏ数の大きい順に上位階層から配置先を割り振る方法でも良いし、ストレージＩ／Ｏ数の小さい順に下位階層から配置先を割り振る方法でもよい。また、ストレージＩ／Ｏ数としてストレージＩ／Ｏ数列１２０６に記録された最新の記録だけでなく、過去のストレージＩ／Ｏ数履歴も考慮して各ページの配置先の階層を決定しても良いし、またストレージＩ／Ｏ数だけでなくその他の指標を利用して決定しても良い。履歴を考慮する場合には、過去数時間分のＩ／Ｏ数の平均値を取るようにする。このように履歴を考慮すれば、瞬間的にＩ／Ｏ数が増加しているが、他の期間（時間帯）ではほとんどＩ／Ｏ数がカウントされていない場合に再配置しないようにすることができる。

さらに、例えば、ホスト計算機１００からのリード／ライト回数の合計値（すなわちストレージＩ／Ｏ数）を考慮するのではなく、リード回数のみを考慮して配置先の階層を決定しても良い。また、ランダムアクセスの回数や、シーケンシャルリードの回数等の指標を考慮して、配置先の階層を決定しても良い。Ｉ／Ｏ数、ランダムアクセス数、シーケンシャルリード回数等を、まとめてアクセスの性質やアクセス特性ということができる。

なお、モニタＯＦＦに設定されている仮想ボリュームのページであっても再配置処理の対象になる。当該ページについてはＩ／Ｏ数＝０であるから、下位階層に移行される場合がある。

ステップ１７０２：仮想ボリュームマネージャ７０４は、ステップ１７０１で決定した各ページの階層配置に基づき、ページの移動（再配置）を実行する。この際、決定した階層と、現在配置されている階層とが異なるページのみ、移動の対象となる。なお、各ページの現在配置されている階層は、ボリュームプール管理テーブル１２００およびプール階層管理テーブル１３００を組み合わせることで確認できる。

ページの移動は、各ページに対する以下の３つのトランザクション処理からなる。つまり、（i）ページが現在配置されている論理ボリュームの領域（旧領域）のデータを、決定した階層に所属する論理ボリュームの未使用領域（新領域）にコピーすること、（ii）ボリュームプール管理テーブル１２００の論理ボリュームＩＤ列１２０３、開始ＬＢＡ列１２０４、終了ＬＢＡ列１２０５を新領域の値に更新すること、（iii）再配置ページ管理テーブル（詳細後述）を更新すること、である。（i）〜（iii）の処理が全ての移動対象のページに対して適用された後、処理は終了する（ステップ１７０３）。

＜再配置ページ管理テーブル＞
図１６は、ストレージ装置４００が保持する再配置ページ管理テーブル１８００の構成例を示す図である。

再配置ページ管理テーブル１８００は、ページ階層再配置処理において階層を移動したページの移動履歴の情報を保持するテーブルであって、プールＩＤ列１８０１と、ページＩＤ列１８０２と、移動元階層１８０３と、移動先階層１８０４とによって構成される。

プールＩＤ列には、ボリュームプールを特定・識別するための識別子（識別情報）が登録される。

ページＩＤ列には、ページ階層再配置処理において階層を移動されたページを特定・識別するための識別子（識別情報）が登録される。

移動元階層列１８０３および移動先階層列１８０４にはそれぞれ、ページ階層再配置処理前後のページ配置先階層が記録される。移動先階層１８０４は、次の再配置処理時には、移動元階層１８０３となる。

なお、再配置ページ管理テーブル１８００は、直前に実行したページ階層再配置処理の記録だけでなく、それより過去のページ階層再配置処理の履歴を保持してもよい。この場合、再配置ページ管理テーブル１８００は、ページ階層再配置処理が実行された時刻を保持する。また、図１６では、格上げ及び格下げのみ示されているが、階層が変化しない場合があっても良い。

＜ホストボリューム管理テーブル＞
ストレージエージェント７０３は、論理ボリューム７０２および仮想ボリューム７０１にストレージボリュームＩＤ（後述）を付与し、管理する。論理ボリューム７０２および仮想ボリューム７０１を総称してストレージボリュームと呼ぶ。

図１７は、管理サーバ２００が保持するホストボリューム管理テーブル１９００の構成例を示す図である。

ホストボリューム管理テーブル１９００は、管理ソフトウェア６００がホスト計算機１００から情報を取得し作成する。ホストボリューム管理テーブル１９００は、ホストＩＤ列１９０１と、ホストＷＷＮ列１９０２と、ホストボリュームＩＤ列１９０３と、ストレージボリュームＩＤ列１９０４と、によって構成される。

ホストＩＤ列１９０１には、管理ソフトウェア６００が付与する、ホスト計算機１００を特定・識別するための識別子（識別情報）が登録される。

ホストＷＷＮ列１９０２には、ホスト計算機１００のＳＡＮアダプタ１１２を特定・識別するための識別子（識別情報）が登録される。この情報は、ＷＷＮ単位でＩ／Ｏ数をモニタするときに用いることができる。

ホストボリュームＩＤ列１９０３には、ホスト計算機１００が認識し、付与するボリュームを特定・識別するための識別子（識別情報）が登録される。以降、ホスト計算機１００が認識するボリュームをホストボリュームと呼ぶ。

ストレージボリュームＩＤ列１９０４には、ホストボリュームに対応するストレージボリュームを特定・識別するための識別子（識別情報）が登録される。当該ストレージボリュームＩＤは、各ストレージボリュームに対して、ストレージエージェント７０３によって付与される情報である。

なお、ストレージボリュームＩＤは、ストレージエージェント７０３が付与・保持する情報であるが、ＯＳ５０１は、例えば、SCSI Inquiryを利用してストレージ装置４００から取得し、保持する。

簡単のため、図１７においてストレージボリュームＩＤは、「仮想ボリューム０」「論理ボリューム３」といった形で表現しているが、実際には、多くの場合、ストレージエージェント７０３が仮想ボリュームと論理ボリュームの区別なく、通し番号で付与し、管理する。この場合、管理ソフトウェア６００は、ストレージボリュームＩＤと、仮想ボリュームＩＤおよび論理ボリュームＩＤとの対応を、ストレージエージェント７０３に問い合わせることで取得できる。このように、ストレージボリュームＩＤと仮想ボリュームＩＤおよび論理ボリュームＩＤは容易に対応関係を特定できるため、以降「ストレージボリュームＩＤから特定した仮想ボリュームＩＤ」または「ストレージボリュームＩＤから特定した論理ボリュームＩＤ」と記載すべきところを、単に仮想ボリュームＩＤまたは論理ボリュームＩＤと表現することがある。

また、図１７では、ホストボリュームとストレージボリュームが１対１に対応しているが、必ずしも１対１でなくても良く、１対多、多対１であっても良い。

＜Ｉ／Ｏモニタ要否管理テーブル＞
図１８は、管理サーバ２００が保持し、管理ソフトウェア６００が参照するＩ／Ｏモニタ要否管理テーブル２０００の構成例を示す図である。

Ｉ／Ｏモニタ要否管理テーブル２０００は、ホストＩＤ列２００１と、タスク名列２００２と、タスク種別列２００３と、Ｉ／Ｏモニタ要否列２００４とによって構成される。

ホストＩＤ列２００１には、管理ソフトウェア６００が付与し、ホスト計算機１００を特定・識別するための識別子（識別情報）が登録される。

タスク名列２００２には、ＯＳ５０１上でタスク５００を区別する名称が登録される。

タスク種別列２００３には、タスク５００の一般的な分類が登録される。

Ｉ／Ｏモニタ要否列２００４には、各タスクが発行するＩ／Ｏ数を記録すべきか否かが登録される。この情報は、例えば、初期値としてデフォルトで全て「要」となっており（特定のタスクについてモニタの要否が最初から分かっている場合には、管理者が「要」或いは「否」に設定するようにしても良い）、計算機システム１０を運用していくうちに、後述の図２１の表示に基づいて、ユーザ（管理者）が決めるようにしても良いし、後述の図２４や２６の処理によって自動的にモニタ要否を「否」に決定するようにしても良い。

なお、Ｉ／Ｏモニタ要否管理テーブル２０００は、ユーザが管理ソフトウェア６００に入力して作成する方式でもよいし、管理ソフトウェア６００がＯＳ５０１上で稼働するタスク５００を検出して自動的に作成する方式でもよい。また、Ｉ／Ｏモニタ要否管理テーブル２０００はＩ／ＯモニタのＯＮ／ＯＦＦ制御処理の前に作成される。

一般的に、夜間集計バッチ処理はモニタ不要になりやすいが、バッチ処理も時間通りに完了するとは限らないため、モニタを要する場合もある。例えば、バッチ処理で、ボリューム対するアクセス数が多く、終了予定時間に間に合わない可能性がある場合に、アクセススピードが遅い階層に各ページが配置されたままであると、不都合である。この場合には、モニタして再配置処理を可能にした方が効率的である。このように、Ｉ／Ｏモニタしなくても良いタスクは必ずしも表面上明らかでない場合もあり、本発明の処理が非常に有効となってくるのである。

＜Ｉ／ＯモニタＯＮ／ＯＦＦ制御処理＞
図１９は、管理サーバ２００において、管理ソフトウェア６００が実行するＩ／ＯモニタのＯＮ／ＯＦＦ制御処理（例）を説明するためのフローチャートである。本処理は、定期的に、ホスト毎に実行開始される（ステップ２１００）。ここで、「定期的」とは、周期的に実行する場合、各タスクの実行起動時、ユーザ設定された時間に実行する場合等を含み、等間隔で実行する場合だけでなく、任意のタイミングで実行する場合を含むものである。なお、ストレージＩ／Ｏ数だけでなくその他の指標のモニタＯＮ／ＯＦＦを制御するようにしても良い。例えば、ホスト計算機１００からのリード／ライト回数の合計値（すなわちストレージＩ／Ｏ数）のモニタＯＮ／ＯＦＦを制御するのではなく、リード回数のみのモニタＯＮ／ＯＦＦを制御する。また、ランダムアクセスの回数や、シーケンシャルリードの回数等の指標のＯＮ／ＯＦＦであっても良い。つまり、本実施形態では、アクセスの性質或いはアクセス特性のモニタＯＮ／ＯＦＦを制御すると言うことが可能である。以下、Ｉ／ＯモニタのＯＮ／ＯＦＦの制御について、ステップごとに説明を記述する。

ステップ２１０１：管理ソフトウェア６００は、各ホスト計算機１００と通信し、ホスト計算機１００上のＯＳ５０１から、ホスト計算機１００毎のタスク稼働情報２２００（図２０参照）を取得する。

ステップ２１０２：管理ソフトウェア６００は、取得したタスク稼働情報において、「稼働状態２２０２がＯＮ」かつ「Ｉ／Ｏモニタ要否管理テーブル２０００においてＩ／Ｏモニタ要否列２００４の値が「否」である」ようなタスクが１つでも存在するかを判定する。これは、Ｉ／Ｏモニタすべきでないタスクが動いている仮想ボリュームについてはＩ／ＯモニタをＯＦＦにする趣旨である。なお、モニタＯＦＦの条件として「稼働状態２２０２がＯＮ」の代わりに「ホストＩ／Ｏ発行量２２０３が閾値以上であるもの」などとしてもよい。また「１つでも存在するかを判定する」としたが「閾値（例えば、「否」であるタスクが３つ）以上存在する」などとしても良く、また、全てのタスクが「否」でないとモニタＯＦＦとしないようにしても良い。ステップ２１０２で判定結果がｙｅｓであった場合、処理はステップ２１０３に進み、判定結果がｎｏであった場合、処理はステップ２１０４に進む。

ステップ２１０３：管理ソフトウェア６００は、ホスト計算機１００に割り当てられた仮想ボリュームのＩ／ＯモニタをＯＦＦにする。具体的には、まず、管理ソフトウェア６００は、ホストボリューム管理テーブル１９００（図１７）からホスト計算機１００に割り当てられた仮想ボリュームの仮想ボリュームＩＤを特定し、ストレージ装置４００に対して仮想ボリュームＩＤおよびＩ／ＯモニタのＯＦＦ命令を送信する。そして、そのＯＦＦ命令を受信したストレージ装置４００は、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００（図１３）の該当する仮想ボリュームＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の値をＯＦＦにする。

ステップ２１０４：管理ソフトウェア６００は、ホスト計算機１００に割り当てられた仮想ボリュームのＩ／Ｏモニタ１５０２をＯＮにする。具体的には、まず、管理ソフトウェア６００は、ホストボリューム管理テーブル１９００からホスト計算機１００に割り当てられた仮想ボリュームの仮想ボリュームＩＤを特定し、ストレージ装置４００に対して仮想ボリュームＩＤを含むＩ／ＯモニタのＯＮ命令を送信する。そして、そのＯＮ命令を受信したストレージ装置４００は、仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００の該当する仮想ボリュームＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の値をＯＮにする。

＜タスク稼働情報＞
図２０は、ホスト計算機毎のタスク稼働情報２２００の例を示す図である。タスク稼働情報２２００は、タスク名２２０１と、稼働状態２２０２と、ホストＩ／Ｏ発行量２２０３とによって構成される。

タスク名２２０１は、ＯＳ５０１上でタスク５００を区別する名称を特定するための情報である。

稼働状態２２０２は、各タスクが稼働している（ＯＮ）か否（ＯＦＦ）かを示す情報である。

ホストＩ／Ｏ発行量２２０３は、各タスクがＯＳ５０１上で発行している時間当たりＩ／Ｏ数を示す情報である。

なお、タスク稼働情報２２００は、メモリ使用量等、他の情報を含んでいてもよい。

＜Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面（ＧＵＩ）＞
図２１は、管理サーバ２００において、管理ソフトウェア６００が表示する、Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００の構成例を示す図である。Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００は、ユーザがＩ／Ｏモニタ要否管理テーブル２０００を入力する際に、どのタスクのＩ／ＯモニタをＯＦＦにすべきかを判断するために使用する画面である。図２１は、仮想ボリューム７０１のプール毎に再配置発生量を管理するためのユーザインタフェースとなっている。なお、プール単位で再配置発生量をモニタするのは、第１の実施形態だけでなく、第２乃至第４の実施形態でも同様である。

Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００は大きく分けて３つの構成要素からなる。すなわち、プール内再配置発生量グラフ２３０１と、ホスト内タスクＩ／Ｏ比率グラフ２３０６と、全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７である。なお、以下の記述においてホスト内タスクＩ／Ｏ比率グラフ２３０６、及び全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７は、特に階層格上げ（下位階層から上位階層への移動）に注目しているが、階層格下げ（上位階層から下位階層への移動）に関しても、以降で述べる計算により同様のグラフを表示してもよい。また、以降で述べる計算は一例であり、ユーザがプール内再配置発生量グラフ２３０１、ホスト内タスクＩ／Ｏ比率グラフ２３０６、全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７の各グラフから、以降で述べるのと同等の判断をできるのであれば、別の計算方法でもよい。

（i）プール内再配置発生量グラフ２３０１
プール内再配置発生量グラフ２３０１は、ボリュームプール７００の各時間帯でのページ階層再配置処理ごとに、階層格上げページ群（すなわち下位階層から上位階層に移動された一つ以上のページ）の合計容量（階層格上げ容量２３０４）およびそのページ群が割り当てられたホスト計算機の内訳２３０２を、ページ階層再配置処理が実行された時間帯ごとに表示する。また、階層格下げページ群（すなわち上位階層から下位階層に移動された１つ以上のページ）についても同様の情報を表示する（すなわち階層格下げ容量２３０５およびそのページ群が割り当てられたホスト計算機の内訳２３０３）。格上げページ或いは格下げページの別は再配置ページ管理テーブル１８００（図１６参照）から判断することができる。また、ボリュームプール管理テーブル１２００（図１０）から、各ページのＬＢＡの範囲が分かるので、これに基づいて各ページの容量を算出することができる。また、どのページがどのホスト計算機に割り当てられているかは、仮想ボリューム管理テーブル１１００（図９）を参照して、ページＩＤに対応する仮想ボリュームを特定し、その仮想ボリュームＩＤが割り当てられたホスト計算機を、ホストボリューム管理テーブル（図１７）を参照して取得することにより、決定することができる。

ユーザ（管理者）は、プール内再配置発生量グラフ２３０１により、どのホスト計算機１００が階層格上げおよび階層格下げの要因になっているかを判断できる。また、プール内再配置発生量グラフ２３０１は、再配置容量管理テーブル２４００（図２２参照）に基づいて表示される。

（ii）ホスト内タスクＩ／Ｏ比率グラフ２３０６
ホスト内タスクＩ／Ｏ比率グラフ２３０６は、例えば、プール内再配置発生量グラフ２３０１上の、確認したい時間帯におけるホスト計算機（例えば、24：00の「格上げのホスト３」）を選択することにより表示されるグラフである。

ホスト内タスクＩ／Ｏ比率グラフ２３０６は、ページ階層再配置処理の実行されたある時間帯における「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」を示すものである。

ユーザは、ホスト内タスクＩ／Ｏ比率グラフ２３０６により、ある時間帯のページ階層再配置処理において、各ホスト計算機１００に対応するページ群の階層格上げの要因となったタスク５００を判断できる。図２１に示されるように、24：00のホスト３の再配置処理では、アンチウィルスＡが要因で格上げとなったことが分かる。

ホストＩ／Ｏ発行量の比率については、当該ページ階層再配置処理のステップ１７０１において、管理ソフトウェア６００が、ページの配置先階層の決定に用いたストレージＩ／Ｏ数を記録した時間帯における、各タスク５００のホストＩ／Ｏ発行量に基づいて計算する。例えば、ステップ１７０１において、最新のストレージＩ／Ｏ数だけでなく、履歴として保持された過去のストレージＩ／Ｏ数も利用した場合、過去のストレージＩ／Ｏ数も計算に含まれる。ただし、多くの場合、過去のストレージＩ／Ｏ数は最新のストレージＩ／Ｏ数よりページ再配置処理における考慮の対象として重要性が低い。このため、仮想ボリュームマネージャ７０４はステップ１７０１実行時に、適当な定数（重み係数）を過去のストレージＩ／Ｏ数に乗算して、最新のストレージＩ／Ｏ数より寄与率を低くするようにしても良い。このような場合、管理ソフトウェア６００が「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」を計算する際に、ステップ１７０１で仮想ボリュームマネージャ７０４が過去のストレージＩ／Ｏ数に対して乗算したのと同じ係数を、当該時間帯の各タスクのホストＩ／Ｏ発行量に乗算する。なお、「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」の計算は、タスク稼働情報管理テーブル２５００（図２３参照）に基づいて実行される。

ここで、タスク稼働情報管理テーブル２５００を用いて「２４時のｈｏｓｔ３のホスト内タスクＩ／Ｏ比率グラフ２３０６の表示に用いる、ホストＩ／Ｏ発行量の比率」の計算の例を簡単に説明する。例えば、２４時のページ階層再配置処理において、ステップ１７０１でページの配置先階層の決定に用いられたストレージＩ／Ｏ数が１８時から２４時に記録されているとする（なおストレージＩ／Ｏ数が記録された時間帯は仮想ボリュームマネージャ７０４から取得できる）。管理ソフトウェア６００は、タスク稼働情報管理テーブル２５００のｈｏｓｔ３の各タスク、すなわちＯＬＴＰ３とアンチウィルスＡのそれぞれについて、１８時から２４時のホストＩ／Ｏ発行量を合計する。この合計値の比率が「２４時のｈｏｓｔ３のホスト内タスクＩ／Ｏ比率グラフ２３０６の表示に用いる、ホストＩ／Ｏ発行量の比率」となる。

（iii）全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７
全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７は、例えば、プール内再配置発生量グラフ２３０１上の、確認したい時間帯のホスト計算機（例えば、6：00の「格上げのホスト３」及び「格上げのホスト２」）を選択することにより表示されるグラフである。

全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７は、ページ階層再配置処理の実行された時間帯ごとに、「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」を示すものである。

ユーザは、全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７を参照することにより、ある時間帯のページ階層再配置処理において、どのホスト計算機１００のどのタスク５００が階層格上げの要因になったかを判断できる。図２１に示されるように、6：00の再配置処理では、ホスト２のＯＬＴＰ２が支配的であり、これが格上げの要因となったことが分かる。従って、ＯＬＴＰ２の処理が重要であればＩ／Ｏモニタ要否を「要」のままにし、重要でなければ「否」に設定すれば良いことになる。なお、割合が少ないＯＬＴＰ３やアンチウィルスＡを「否」にしても、下位階層に配置されてしまうことを防止することによる性能劣化防止の効果は少ないと言える。

なお、全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７で表示される「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」は、ホスト内タスクＩ／Ｏ比率グラフ２３０６で表示する「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」と「階層格上げ容量２３０４のホスト計算機の内訳２３０２」とから、管理ソフトウェア６００が計算する。すなわち、「階層格上げ容量２３０４のホスト計算機の内訳２３０２」の比率を「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」に対して、乗算したものが「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」である。

ここで、「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」の計算の例を示す。階層格上げ容量２３０４が１００ＧＢであり、その内訳がｈｏｓｔ２：７０ＧＢ、ｈｏｓｔ３：３０ＧＢであった場合、「階層格上げ容量２３０４のホスト計算機の内訳２３０２」の比率は、ｈｏｓｔ２：７０％、ｈｏｓｔ３：３０％となる。「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」が、それぞれ、ｈｏｓｔ２においてＯＬＴＰ２：１００％、ｈｏｓｔ３においてアンチウィルスＡ：４０％、ＯＬＴＰ３：６０％である場合、「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」は、ＯＬＴＰ２：７０％（＝７０％×１００％）、アンチウィルスＡ：１２％（＝３０％×４０％）、ＯＬＴＰ３：１８％（＝３０％×６０％）となる。

＜再配置容量管理テーブル＞
図２２は、管理ソフトウェア６００が作成し、管理サーバ２００内に保持される、再配置容量管理テーブル２４００の構成例を示す図である。

再配置容量管理テーブル２４００は、プールＩＤ列２４０１と、ホストＩＤ列２４０２と、再配置時間帯列２４０３と、階層格上げ容量列２４０４と、階層格下げ容量列２４０５とによって構成される。

プールＩＤ列２４０１には、ボリュームプール７００を特定・識別するための識別子（識別情報）が登録される。

ホストＩＤ列２４０２には、プールＩＤ列２４０１の値によって特定されるボリュームプールから作成された仮想ボリュームが割り当てられているホスト計算機を特定・識別するための識別子（識別情報）が登録される。

再配置時間帯列２４０３には、ストレージ装置４００においてページ階層再配置処理が実行された時間帯を示す情報が登録される。

階層格上げ容量列２４０４および階層格下げ容量列２４０５には、ページ階層再配置処理において、下位階層から上位階層、および上位階層から下位階層に移動されたページ群の合計容量がそれぞれ登録される。

階層格上げ容量列２４０４および階層格下げ容量列２４０５の値については、管理ソフトウェア６００が、ホストボリューム管理テーブル１９００と、ストレージ装置４００から取得する仮想ボリューム管理テーブル１１００と、ボリュームプール管理テーブル１２００と、再配置ページ管理テーブル１８００とにより計算する。例えば「ｐｏｏｌ１のｈｏｓｔ１の階層格上げ容量」を計算する場合、再配置ページ管理テーブル１８００に登録されたｐｏｏｌ１のページ群のうち、「移動先階層列１８０４の値が移動元階層列１８０３より上位」であり、かつ「対応する仮想ボリュームの割り当て先のホスト計算機がｈｏｓｔ１であるもの」が特定される。この特定は仮想ボリューム管理テーブル１１００およびホストボリューム管理テーブル１９００を組み合わせることで実行できる。特定した各ページの容量をボリュームプール管理テーブル１２００から取得し、合計することで「ｐｏｏｌ１のｈｏｓｔ１の階層格上げ容量」を計算できる。

＜タスク稼働情報管理テーブル＞
図２３は、管理サーバ２００が保持する、タスク稼働情報管理テーブル２５００の構成例を示す図である。

タスク稼働情報管理テーブル２５００は、各ホスト計算機１００のタスク稼働情報２２００の履歴情報を保持しており、管理ソフトウェア６００が各ホスト計算機１００から定期的にタスク稼働情報２２００を取得することにより、生成・更新されるテーブルである。

タスク稼働情報管理テーブル２５００は、ホストＩＤ列２５０１と、タスク名列２５０２と、稼働状態列２５０３と、ホストＩ／Ｏ発行量列２５０４と、採取時刻列２５０５と、によって構成される。

ホストＩＤ列２５０１には、ホスト計算機１００を特定・識別するための識別子（識別情報）が登録される。

タスク名列２５０２、稼働状態列２５０３、及びホストＩ／Ｏ発行量列２５０４に登録される情報は、タスク稼働情報２２００における同名称の項目と同じであり、ここでは説明を省略する。

採取時刻列２５０５には、管理ソフトウェア６００がタスク稼働情報２２００を取得した時刻が登録される。

＜Ｉ／ＯモニタＯＦＦ推奨表示処理（I）＞
図２４は、Ｉ／ＯモニタＯＦＦ推奨表示処理（例）を説明するためのフローチャートである。管理ソフトウェア６００は、本処理により、ユーザに対してＩ／ＯモニタをＯＦＦとすべきタスク５００を自動的に提示する。図２１では、表示された各グラフによりユーザ（管理者）がＩ／ＯモニタをＯＦＦとするタスクを判断しているので、自動的に対象のタスクを提示する点で図２１の場合と異なり、ユーザが判断しなくても良いという利点がある。

本処理によって提示される、Ｉ／ＯモニタをＯＦＦとすべきタスク５００は、階層格上げを発生させており、かつ一般的にＩ／ＯモニタをＯＦＦとすべき種別のタスクである。また、本処理は、定期的あるいはユーザの指示を契機として、再配置容量管理テーブル２４００のプール毎に実行される（ステップ２６００）。ただしステップ２６００の前に、少なくとも一度はページ階層再配置処理が実行されており、再配置容量管理テーブル２４００やタスク稼働情報管理テーブル２５００にデータが格納されている必要がある。ここで、「定期的」の意味については上述した通りである。以下、ステップごとに説明を記述する。

ステップ２６０１：管理ソフトウェア６００は、再配置容量管理テーブル２４００を参照し、階層格上げ容量列２４０４の値が所定の閾値を超過しているホスト計算機１００およびその再配置時間帯を検索する。例えば、閾値を２０ＧＢ（以上）とすると、再配置容量管理テーブル２４００からは、20:00-24:00のホスト１、12:00-18:00のホスト２、6:00-12:00のホスト２、24:00-6:00のホスト３が検出される。

ステップ２６０２：管理ソフトウェア６００は、ステップ２６０１の検索で見つかった各「ホスト計算機１００および再配置時間帯」について、「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」を計算する。なお、「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」はホスト内タスクＩ／Ｏ比率グラフ２３０６の表示時に用いるものと同じである。

ステップ２６０３：管理ソフトウェア６００は、ステップ２６０２の計算結果（各「ホスト計算機１００および再配置時間帯」に対する「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」）を用いて、「タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル２７００（図２５）にＩ／ＯモニタＯＦＦ候補として登録されている種別のタスクである」かつ「「各ホスト計算機１００における各タスク５００のホストＩ／Ｏ発行量の比率」が所定の閾値を超過している」ようなタスク５００を検索する。

ステップ２６０４：管理ソフトウェア６００は、ステップ２６０３の検索で得られたタスク５００があれば、Ｉ／ＯモニタをＯＦＦとすべきタスクとしてユーザに提示する。

なお、図３２は、ステップ２６０４において提示されるＩ／Ｏモニタ制御設定推奨表示画面３４００の構成例を示す図である。Ｉ／Ｏモニタ制御設定推奨表示画面３４００は、ホスト名３４０１と、タスク名３４０２と、Ｉ／ＯモニタＯＦＦチェックボックス３４０３と、実行ボタン３４０４と、キャンセルボタン３４０５とによって構成される。

ホスト名３４０１及びタスク名３４０２には、ステップ２６０３の検索で得た結果が表示される。

ユーザは、Ｉ／ＯモニタＯＦＦチェックボックス３４０３にチェックを入れ、実行ボタン３４０４を押下することにより、当該タスクのＩ／ＯモニタをＯＦＦにすることができるようになっている。すなわち、Ｉ／Ｏモニタ要否管理テーブル２０００における当該タスクの行のＩ／Ｏモニタ要否列２００４の値を「否」に変更できる。また、これ以外の情報を表示してもよい。さらに、本ステップにおいてユーザにＩ／ＯモニタをＯＦＦとすべきタスクを提示するだけでなく、自動的にＩ／ＯモニタをＯＦＦとしてもよい。

＜タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル＞
図２５は、管理サーバ２００で保持され、管理ソフトウェア６００が参照するタスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル２７００の構成例を示す図である。

タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル２７００は、タスク種別列２７０１と、Ｉ／ＯモニタＯＦＦ候補列２７０２とにより構成される。

タスク種別列２７０１には、ホスト計算機１００上で実行されるタスクの一般的な種別が登録される。

Ｉ／ＯモニタＯＦＦ候補列２７０２には、各タスク種別が、一般的にＩ／ＯモニタＯＦＦとすべき(yes)か否(no)かが登録される。例えば、一般的にインデックス構築のタスクは、インデックスを構築するために多量のＩ／Ｏを発行するが、本来高レスポンスが不要なデータに対してもＩ／Ｏを発行するため、このＩ／Ｏは記録すべきではない（Ｉ／ＯモニタＯＦＦとすべき）。なお、タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル２７００は管理ソフトウェア６００が初めから固定値（Default値）として保持していてもよいし、ユーザが適宜入力してもよい。

＜Ｉ／ＯモニタＯＦＦ推奨表示処理（II）＞
図２６は、図２４とは別のＩ／ＯモニタＯＦＦ推奨表示処理を説明するためのフローチャートである。管理ソフトウェア６００は本処理により、ユーザに対してＩ／ＯモニタをＯＦＦとすべきタスク５００を提示する。本処理によって提示される、Ｉ／ＯモニタをＯＦＦとすべきタスク５００（タスクＡ）は、あるページ階層再配置時間帯において所定の閾値以上の階層格上げを発生させており、かつ、その次のページ階層再配置時間帯においては別の１つ以上のタスク５００（タスクＢ群）が大量の階層格上げを発生させているものである。つまり、２つ（必ずしも２つでなくても良い）の連続する時間帯のうちで所定閾値以上の再配置処理が実行された時間帯が検出される。これは単発的に階層格上げの発生量が増加した時間帯ではなく、ある程度定常的に階層格上げが発生している時間帯を処理対象とする趣旨である。このようなタスクＡは、一時的にホストＩ／Ｏ発行量が増大し、ページ階層再配置処理においてタスクＡで使用されるページ群を階層格上げさせ、結果としてタスクＢ群のページを階層格下げさせている可能性がある。本処理は、定期的あるいはユーザの指示を契機として、再配置容量管理テーブル２４００のプール毎に実行される（ステップ２８００）。「定期的」の意味については上述した通りである。なお、ステップ２８００の処理の前に、少なくとも２度はページ階層再配置処理が実行されており、再配置容量管理テーブル２４００やタスク稼働情報管理テーブル２５００にデータが格納されている必要がある。以下、ステップごとに説明を記述する。

ステップ２８０１：管理ソフトウェア６００は、再配置容量管理テーブル２４００を参照し、着目する再配置時間帯（自再配置時間帯とも言う）およびその直後の再配置時間帯ともに、階層格上げ容量の全ホスト合計値が所定の閾値を超過しているような再配置時間帯を検索する。なお、「自再配置時間帯および直後の再配置時間帯」ではなく、「自再配置時間および直後のｋ個以内の再配置時間帯のいずれか」などとしてもよい（ｋは任意の自然数である）。例えば、24:00-6:00のホスト２とホスト３の階層格上げ容量の合計値（５０ＧＢ）と、6:00-12:00のホスト２とホスト３の階層格上げ容量の合計値（４０ＧＢ）の両方が所定の閾値（例えば、３５ＧＢ）を超えているので、これらの時間帯がその後の処理を続行する対象として検出される。

ステップ２８０２：管理ソフトウェア６００は、ステップ２８０１で得られた各再配置時間帯、およびその各々の直後の再配置時間帯について、「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」を計算する。「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」は全ホスト階層格上げページＩ／Ｏ寄与率グラフ２３０７の表示に用いる場合の情報と同じである。

ステップ２８０３：管理ソフトウェア６００は、ステップ２８０２で計算した、任意の再配置時間帯における「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」において寄与率が閾値を超過しているタスク５００で、かつその直後の再配置時間帯における「全ホスト計算機１００における各タスク５００の階層格上げ寄与率」において寄与率が閾値を下回っているタスク５００を取得する。例えば、アンチウィルスＡについて、18:00-24:00の時間帯での寄与率が閾値を上回っているが、24:00-6:00の時間帯での寄与率がその閾値を下回っている場合には、そのアンチウィルスＡが該当するタスクとして取得されることになる。

ステップ２８０４：管理ソフトウェア６００は、ステップ２８０３の検索で得られたタスク５００があれば、Ｉ／ＯモニタをＯＦＦとすべきタスクとしてユーザに提示する。なお、ステップ２８０４において提示される情報は、上述の図３２で示されるＩ／Ｏモニタ制御設定推奨表示画面３４００と同様である。なお、ユーザにＩ／ＯモニタをＯＦＦとすべきタスクを提示するだけでなく、自動的にＩ／ＯモニタをＯＦＦとしてもよい。

図２４および図２６に示したＩ／ＯモニタＯＦＦ推奨表示処理は例であり、他にもＩ／ＯモニタＯＦＦ推奨表示処理がある。例えば、下記のようなタスク５００をＩ／ＯモニタをＯＦＦとすべきタスクとしてユーザに提示してもよい。つまり、あるページ階層再配置時間帯に大量の階層格上げを発生させているタスク５００であり、かつその時に階層格上げされたページ群の多くが階層格上げ以降、あまりアクセスされていないようなタスク５００である。このようなタスク５００は、一時的にホストＩ／Ｏ発行量が増大して大量の階層格上げを発生させたが、それ以降はアクセスが減少し、結果として無意味な階層格上げを発生させた可能性が高い。なお、このようなタスク５００は、ボリューム管理テーブル１１００、再配置ページ管理テーブル１８００、仮想ホストボリューム管理テーブル１９００、再配置容量管理テーブル２４００、タスク稼働情報管理テーブル２５００を用いることで特定できる。

（２）第２の実施形態
次に、本発明の第２の実施形態による計算機システムについて、第１の実施形態で用いた図１から図１２、図１５から図１８、及び図２０から図２６、さらに新たに図２７から２９を参照して、説明する。なお、第１及び第２の実施形態の違いは、Ｉ／ＯモニタのＯＮ／ＯＦＦ制御の粒度である。すなわち、第１の実施形態では仮想ボリューム単位でＩ／ＯモニタのＯＮ／ＯＦＦを制御するが、第２の実施形態ではページ単位でＩ／ＯモニタのＯＮ／ＯＦＦを制御する。

第２の実施形態におけるシステム構成は、第１の実施形態において図１から図５を用いて説明したものと同様である。また図６から図１２、図１５から図１８、図２０から図２６に示す概念図、管理テーブル、フローチャートは、本実施形態にも適用される。ただし、第２の実施形態では、仮想ボリューム７０１をそのままホストボリュームとして利用するのではなく、１つ以上の仮想ボリューム７０１上の、一部または複数の領域を、仮想的なホストボリュームとしてホスト計算機１００上で利用するためのプログラム（ホストボリュームマネージャ）が、ホスト計算機１００上や別の計算機上に存在してもよい。なお、ホストボリュームマネージャは、当該仮想的なホストボリュームと、当該一部または複数の領域の間のマッピング情報を保持する。また、ホスト計算機１００として、物理マシンだけでなく、仮想マシンが存在してもよい。

＜ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル＞
図２７は、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００の構成例を示す図である。このテーブルは、ページ単位でＩ／ＯモニタのＯＮ及びＯＦＦを管理するためのものであり、第１の実施形態における図１３（仮想ボリューム単位でＩ／ＯモニタのＯＮ及びＯＦＦを管理するテーブル）に対応する。

ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００は、プールＩＤ列２９０１と、ページＩＤ列２９０２と、Ｉ／ＯモニタＯＮ／ＯＦＦ列２９０３と、によって構成される。

プールＩＤ列２９０１には、ボリュームプール７００を特定・識別するための識別子（識別情報）が登録される。

ページＩＤ列２９０２には、各ボリュームプール７００の各ページを特定・識別するための識別子（識別情報）が登録される。

Ｉ／ＯモニタＯＮ／ＯＦＦ列２９０３にはＩ／Ｏモニタ処理時に当該ページに対するＩ／Ｏを記録する（ＯＮ）か否（ＯＦＦ）かが登録される。なお、この情報は、図１３におけるＩ／ＯモニタＯＮ／ＯＦＦ列１５０２と同様に、初期値としてデフォルト値が設定されているが、システムを順次運用していくうちに、図２９の処理によって値（ＯＮ／ＯＦＦ）は変化するようになっている。

＜Ｉ／Ｏモニタ処理＞
図２８は、第２の実施形態において、仮想ボリュームマネージャ７０４によって実行されるＩ／Ｏモニタ処理（例）を説明するためのフローチャートである。本処理はホスト計算機１００からストレージ装置４００内の仮想ボリューム７０１に対してＩ／Ｏが発行されたことを契機として開始される（ステップ３０００）。

まず、仮想ボリュームマネージャ７０４は、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００を参照し、Ｉ／Ｏ発行先のページのＩ／ＯモニタＯＮ／ＯＦＦ列２９０３がＯＮになっているかを確認する（ステップ３００１）。このときＩ／ＯモニタＯＮ／ＯＦＦ列２９０３がＯＦＦであれば処理は終了する（ステップ３００３）。Ｉ／ＯモニタＯＮ／ＯＦＦ列２９０３がＯＮであれば処理はステップ３００２に移行する。

そして、仮想ボリュームマネージャ７０４は、ボリュームプール管理テーブル１２００の、Ｉ／Ｏ発行先のページのページＩＤおよびボリュームプールのプールＩＤで決定される行のストレージＩ／Ｏ数列１２０６の数字を１増加させ（ステップ３００２）、処理を終了する（ステップ３００３）。

＜Ｉ／ＯモニタのＯＮ／ＯＦＦ制御処理＞
図２９は、管理ソフトウェア６００が実行するＩ／ＯモニタのＯＮ／ＯＦＦ制御処理（例）を説明するための示すフローチャートである。本処理は定期的に、ホスト計算機１００毎に実行開始される（ステップ３１００）。なお、「定期的」の意義については、第１の実施形態において上述した通りである。以下ステップごとに説明を記述する。

ステップ３１０１：管理ソフトウェア６００は、ホスト計算機１００上のＯＳ５０１から、タスク稼働情報２２００（図２０参照）を取得する。

ステップ３１０２：管理ソフトウェア６００は、ホスト計算機１００に割り当てられたページ群を特定する。この処理では、まず管理ソフトウェア６００が、ホスト計算機１００上のＯＳ５０１からホスト計算機１００の使用する仮想ボリューム７０１上のＬＢＡ範囲を取得する。この場合、ホスト計算機１００のＯＳ５０１は、そのホスト計算機の使用する仮想ボリューム７０１上のＬＢＡ範囲を管理している。また、ホスト計算機１００がホストボリュームマネージャにより仮想ボリューム７０１上の一部領域を仮想的なホストボリュームとして利用している場合は、管理ソフトウェア６００は、当該領域に対応するＬＢＡ範囲をホストボリュームマネージャから取得する。次に、管理ソフトウェア６００は、取得したＬＢＡ範囲を、仮想ボリューム管理テーブル１１００（図９参照）を用いて照合することで、ホスト計算機１００に割り当てられたページ群を特定することができる。

ステップ３１０３：管理ソフトウェア６００は、ステップ３１０１で取得したタスク稼働情報２２００において、「稼働状態２２０２がＯＮ」かつ「Ｉ／Ｏモニタ要否管理テーブル２０００においてＩ／Ｏモニタ要否列２００４の値が「否」である」ようなタスクが１つでも存在するかを判定する。ステップ３１０３の判定結果がｙｅｓの場合、処理はステップ３１０４に移行し、当該判定結果がｎｏの場合、処理はステップ３１０５に移行する。なお、条件として「稼働状態２２０２がＯＮ」の代わりに「ホストＩ／Ｏ発行量２２０３が閾値以上であるもの」としてもよい。また「１つでも存在するかを判定する」としたが「閾値以上存在するかを判定する」などとしてもよい。当該変形例については、第１の実施形態の場合と同様である。

ステップ３１０４：管理ソフトウェア６００は、ステップ３１０２で特定したページ群のＩ／ＯモニタをＯＦＦにする。すなわち、ストレージ装置４００に対してボリュームプールの識別子およびページ群のページＩＤを含むＩ／ＯモニタのＯＦＦ命令を送信する。そして、それを受信したストレージ装置４００が、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００（図２７）の該当するプールＩＤかつページＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列２９０３の値をＯＦＦにする。

ステップ３１０５：管理ソフトウェア６００は、ステップ３１０２で特定したページ群のＩ／ＯモニタをＯＮにする。すなわち、ストレージ装置４００に対してボリュームプールのプールＩＤおよびページ群のページＩＤを含むＩ／ＯモニタのＯＮ命令を送信する。そして、それを受信したストレージ装置４００が、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００の該当するプールＩＤかつページＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列２９０３の値をＯＮにする。

（３）第３の実施形態
続いて、本発明の第３の実施形態による計算機システムについて、第１の実施形態で用いた図１から図１８、及び図２０から図２６、さらに新たに図３０を参照して、説明する。なお、第３の実施形態と第１の実施形態との違いは、Ｉ／ＯモニタのＯＮ／ＯＦＦ制御処理が管理サーバ２００の管理ソフトウェア６００によって実行されるのではなく、各ホスト計算機１００上のＯＳ５０１によって、或いは、代表のホスト計算機のＯＳ５０１によって実行されることである。従って、管理ソフトウェア６００の役割は、ユーザに対してＩ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００（図２１）を提示することとなる。

本実施形態におけるシステム構成は、第１の実施形態において図１から図５を用いて説明したものと同様である。また図６から図１８、図２０から図２６に示す概念図、管理テーブル、フローチャートは、本実施形態にも適用される。ただし、Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００を提示する必要がない場合、管理ソフトウェア６００は必ずしも必要ない。また、Ｉ／Ｏモニタ要否管理テーブル２０００は、管理ソフトウェア６００が保持するとともに、各々のホスト計算機１００が各自ホストＩＤの部分情報（タスク名、タスク種別、Ｉ／Ｏモニタ要否）を保持する。管理ソフトウェア６００の保持するＩ／Ｏモニタ要否管理テーブル２０００と、各ホスト計算機１００の保持するＩ／Ｏモニタ要否管理テーブルの部分情報は同期される。このため、Ｉ／Ｏモニタ要否管理テーブル２０００をユーザが入力する場合、管理ソフトウェア６００上で入力してもよいし、各ホスト計算機１００上で入力してもよい。

＜Ｉ／ＯモニタのＯＮ／ＯＦＦ制御処理＞
図３０は、Ｉ／ＯモニタのＯＮ／ＯＦＦ制御処理の一例を示すフローチャートである。本処理は定期的に、各ホスト計算機１００上のＯＳ５０１により実行開始される（ステップ３２００）。「定期的」の意義については上述の通りである。以下ステップごとに説明を記述する。

ステップ３２０１：各ホスト計算機１００上のＯＳ５０１は、各ホスト計算機（自ホスト）のタスク稼働情報２２００（図２０）を参照する。

ステップ３２０２：各ホスト計算機１００上のＯＳ５０１は、タスク稼働情報２２００において、「稼働状態２２０２がＯＮ」かつ「Ｉ／Ｏモニタ要否管理テーブル２０００においてＩ／Ｏモニタ要否列２００４の値が「否」である」ようなタスクが１つでも存在するかを判定する。ステップ３２０２の判定結果がｙｅｓの場合、処理はステップ３２０３に移行し、当該判定結果がｎｏの場合、ステップ３２０４に移行する。なお、タスクの前提条件として「稼働状態がＯＮ」の代わりに「ホストＩ／Ｏ発行量２２０３が閾値以上である」としてもよい。また「１つでも存在するかを判定する」としたが「閾値以上存在するかを判定する」などとしてもよい。当該変形例については、第１の実施形態の場合と同様である。

ステップ３２０３：各ホスト計算機１００上のＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）に割り当てられたボリュームのＩ／ＯモニタをＯＦＦにする。この処理は、例えばSCSI Inquiryにより、仮想ボリュームＩＤを含むＩ／ＯモニタのＯＦＦ命令が、ストレージ装置４００に発行される。そして、このＯＦＦ命令を受信したストレージ装置４００は仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００（図１３）の該当する仮想ボリュームＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の値をＯＦＦにする。

ステップ３２０４：各ホスト計算機１００上のＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）に割り当てられたボリュームのＩ／ＯモニタをＯＮにする。この処理は、例えばSCSI Inquiryにより、仮想ボリュームＩＤを含むＩ／ＯモニタのＯＮ命令が、ストレージ装置４００に発行される。そして、このＯＮ命令を受信したストレージ装置４００は仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル１５００の該当する仮想ボリュームＩＤのＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の値をＯＮにする。

（４）第４の実施形態
さらに続いて、本発明の第４の実施形態による計算機システムについて、第１の実施形態で用いた図１から図１２、図１５から１８、及び図２０から図２６、第２の実施形態で用いた図２７及び２８、さらに新たに図３１を参照して、説明する。なお、第１の実施形態と第４の実施形態との違いは、「Ｉ／ＯモニタのＯＮ／ＯＦＦ制御を管理ソフトウェア６００が実行するのではなく、各ホスト計算機１００上のＯＳ５０１が実行すること」および「Ｉ／ＯモニタのＯＮ／ＯＦＦ制御はページ単位で実行されること」である。つまり、第２の実施形態と第３の実施形態とを組み合わせたものとなっている。従って、管理ソフトウェア６００の役割は、ユーザに対してＩ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００を提示することとなる。

本実施形態におけるシステム構成は、第１の実施形態において図１から図５を用いて説明したものと同様である。また、図６から図１８、図２０から図２６に示す概念図、管理テーブル、フローチャートは、本実施形態にも適用される。ただし、Ｉ／ＯモニタＯＮ／ＯＦＦ判断用情報表示画面２３００を提示する必要がない場合、管理ソフトウェア６００は必ずしも必要ない。また、Ｉ／Ｏモニタ要否管理テーブル２０００は、管理ソフトウェア６００が保持するとともに、各々のホスト計算機１００が各自ホストＩＤの部分情報（タスク名、タスク種別、Ｉ／Ｏモニタ要否）を保持することとなる。また、管理サーバ２００が保持し、管理ソフトウェア６００によって使用されるＩ／Ｏモニタ要否管理テーブル２０００と、各ホスト計算機１００が保持するＩ／Ｏモニタ要否管理テーブルの部分情報は同期される。このため、Ｉ／Ｏモニタ要否管理テーブル２０００をユーザが入力する場合、管理サーバ２００の管理ソフトウェア６００上で入力してもよいし、各ホスト計算機１００上で入力してもよい。さらに、仮想ボリューム７０１をそのままホストボリュームとして利用するのではなく、１つ以上の仮想ボリューム７０１上の、一部または複数の領域を、仮想的なホストボリュームとしてホスト計算機１００上で利用するためのプログラム（ホストボリュームマネージャ）が、ホスト計算機１００上や別の計算機上に存在してもよい。なお、ホストボリュームマネージャは、当該仮想的なホストボリュームと、当該一部または複数の領域の間のマッピング情報を保持する。

＜Ｉ／ＯモニタのＯＮ／ＯＦＦ制御処理＞
図３１は、第４の実施形態によるＩ／ＯモニタのＯＮ／ＯＦＦ制御処理（例）を説明するためのフローチャートである。本処理は定期的に、各ホスト計算機１００上のＯＳ５０１により実行開始される（ステップ３３００）。「定期的」の意義については、上述の通りである。以下ステップごとに説明を記述する。

ステップ３３０１：各ホスト計算機１００上のＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）のタスク稼働情報２２００（図２０）を参照する。

ステップ３３０２：各ホスト計算機１００上のＯＳ５０１は、タスク稼働情報２２００において、「稼働状態２２０２がＯＮ」かつ「Ｉ／Ｏモニタ要否管理テーブル２０００においてＩ／Ｏモニタ要否列２００４の値が「否」である」ようなタスクが１つでも存在するかを判定する。ステップ３３０２の判定結果がｙｅｓの場合、処理はステップ３３０３に移行し、当該判定結果がｎｏの場合、処理はステップ３３０４に進む。なお、タスクの前提条件として「稼働状態がＯＮ」の代わりに「ホストＩ／Ｏ発行量２２０３が閾値以上である」としてもよい。また「１つでも存在するかを判定する」としたが「閾値以上存在するかを判定する」などとしてもよい。当該変形例については、第１の実施形態の場合と同様である。

ステップ３３０３：各ホスト計算機１００上のＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）に割り当てられた、仮想ボリューム７０１上の１つ以上の領域のＩ／ＯモニタをＯＦＦにする。この処理では、例えばSCSI Inquiryにより、仮想ボリュームＩＤおよびＬＢＡ範囲を含んだＩ／ＯモニタＯＦＦ命令をストレージ装置４００に送信する。このＯＦＦ命令を受信したストレージ装置４００は、仮想ボリューム管理テーブル１１００（図９）を参照して、指示された仮想ボリュームＩＤおよびＬＢＡ範囲に対応する、プールＩＤおよびページＩＤを特定し、この特定したプールＩＤおよびページＩＤをもとに、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００（図２７）のＩ／ＯモニタＯＮ／ＯＦＦ列２９０３の値をＯＦＦにする。この場合、ＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）が使用する仮想ボリューム７０１上のＬＢＡ範囲を管理している。なお、ホスト計算機１００がホストボリュームマネージャにより仮想ボリューム７０１上の一部領域を仮想的なホストボリュームとして利用している場合は、ホスト計算機１００上のＯＳ５０１は、当該仮想的なホストボリュームに関するＩ／ＯモニタＯＦＦ命令を、ホストボリュームマネージャに対して発行する。ホストボリュームマネージャはこの命令を受信し、例えばSCSI Inquiryにより、仮想ボリュームＩＤ、および当該仮想的なホストボリュームに対応する仮想ボリューム７０１上のＬＢＡ範囲、を含んだＩ／ＯモニタＯＦＦ命令をストレージ装置４００に送信する。

ステップ３３０４：各ホスト計算機１００上のＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）に割り当てられた、仮想ボリューム７０１上の１つ以上の領域のＩ／ＯモニタをＯＮにする。この処理では、仮想ボリュームＩＤおよびＬＢＡ範囲を含んだＩ／ＯモニタＯＮ命令を、例えばSCSI Inquiryにより、ストレージ装置４００に送信する。このＯＮ命令を受信したストレージ装置４００は仮想ボリューム管理テーブル１１００を参照して、指示された仮想ボリュームＩＤおよびＬＢＡ範囲に対応する、プールＩＤおよびページＩＤを特定し、この特定したプールＩＤおよびページＩＤをもとに、ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル２９００のＩ／ＯモニタＯＮ／ＯＦＦ列１５０２の値をＯＮにする。この場合、ＯＳ５０１は、該当する各ホスト計算機（自ホスト計算機）が使用する仮想ボリューム７０１上のＬＢＡ範囲を管理している。なお、ホスト計算機１００がホストボリュームマネージャにより仮想ボリューム７０１上の一部領域を仮想的なホストボリュームとして利用している場合は、ホスト計算機１００上のＯＳ５０１は、当該仮想的なホストボリュームに関するＩ／ＯモニタＯＮ命令を、ホストボリュームマネージャに対して発行する。ホストボリュームマネージャはこの命令を受信し、例えばSCSI Inquiryにより、仮想ボリュームＩＤ、および当該仮想的なホストボリュームに対応する仮想ボリューム７０１上のＬＢＡ範囲、を含んだＩ／ＯモニタＯＮ命令をストレージ装置４００に送信する。

（５）まとめ
（i）本発明の各実施形態において、ストレージ装置では、複数の計算機（ホスト計算機）上で実行されるタスクに関するアクセス特性（例えば、Ｉ／Ｏ数）に基づいて再配置処理が実行される。この際、管理計算機或いはホスト計算機は、仮想論理ボリューム単位のＩ／Ｏ数、仮想ボリュームを構成するページ単位（仮想論理ボリュームの実記憶領域に対するアクセス単位）のＩ／Ｏ数、或いは、ホスト計算機で発行される（タスクを実行するホスト計算機によるストレージサブシステムに対するアクセス単位で）Ｉ／Ｏ数をモニタすることにより、再配置処理実行の有無を判断している。ここで、本実施形態では、Ｉ／Ｏモニタを実行するか否かを示すＩ／ＯモニタＯＮ／ＯＦＦ管理情報（図１３及び２７参照）が設定される。そして、ストレージ装置は、このＩ／ＯモニタＯＮ／ＯＦＦ管理情報を参照し、モニタされたホスト計算機からのＩ／Ｏ数に基づいて再配置処理を実行する。実施形態では、Ｉ／Ｏモニタをするか否かの情報（Ｉ／ＯモニタＯＮ／ＯＦＦ管理情報）を設定しているが、Ｉ／Ｏ数（アクセス特性）をモニタしたとしてもそのＩ／Ｏ数を再配置処理の要否判断に用いなければ良いので、Ｉ／ＯモニタＯＮ／ＯＦＦ管理情報ではなく、単に「再配置処理における移動先決定の判断基準として考慮するか否かを示す再配置基準情報を設定する」と表現することができる。このようにすることにより、所定の仮想ボリューム、ページやホストのボリュームについて再配置処理の要否判断に用いる必要がなくなるので、不必要な再配置処理を防止することができるようになる。

また、本発明の各実施形態では、管理計算機或いはホスト計算機は、複数のホスト計算機（各ホスト計算機が管理計算機の機能を有する場合（第３の実施形態）には自身のホスト計算機）で実行されるタスクが使用する記憶領域毎のデータの再配置発生量（少なくとも階層格上げの容量）を示す情報（再配置発生情報：ホスト内タスクＩ／Ｏ比率や全ホスト階層格上げページＩ／Ｏ寄与率を含む）を生成し、これを出力する（図２１参照）ようにしている。このようにすることにより、ユーザ（管理者）は、出力された情報を参照して、各タスクについてＩ／Ｏモニタ要否（再配置処理の要否）を決定することができる。従って、各タスクの実行の傾向に合致して、ユーザはＩ／Ｏモニタ要否を決定できるため、ユーザにとって管理しやすい計算機システム（ストレージシステム）を提供することが可能となる。

一方、Ｉ／Ｏモニタ要否（再配置処理の要否）を自動的に設定、或いは、モニタＯＦＦにすることが推奨されるタスクをユーザに提示するようにしても良い。このようにすることにより、Ｉ／Ｏモニタ要否判断に精通していないユーザも適切にストレージシステムを管理することができるようになる。なお、具体的には、モニタＯＦＦ推奨タスク表示は、図２４及び２６に示す処理を実行することにより、実現することができる。

（ii）本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。

１００ ホスト計算機
２００ 管理サーバ（管理計算機）
３００ ＳＡＮ
３０１ ＬＡＮ
４００ ストレージ装置
７００ ボリュームプール
７０１ 仮想ボリューム（仮想論理ボリューム）
８００乃至８０３ 物理ディスク
１１００ 仮想ボリューム管理テーブル（仮想ボリューム管理情報）
１２００ ボリュームプール管理テーブル（ボリュームプール管理情報）
１３００ プール階層管理テーブル（プール階層管理情報）
１４００ 未使用領域管理テーブル（未使用領域管理情報）
１５００ 仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル（仮想ボリュームＩ／ＯモニタＯＮ／ＯＦＦ管理情報）
１８００ 再配置ページ管理テーブル（再配置ページ管理情報）
１９００ ホストボリューム管理テーブル（ホストボリューム管理情報）
２０００ Ｉ／Ｏモニタ要否管理テーブル（Ｉ／Ｏモニタ要否管理情報））
２２００ タスク稼働情報
２４００ 再配置容量管理テーブル（再配置容量管理情報）
２５００ タスク稼働情報管理テーブル（タスク稼働管理情報）
２７００ タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理テーブル（タスク種別毎Ｉ／ＯモニタＯＦＦ候補管理情報）
２９００ ページＩ／ＯモニタＯＮ／ＯＦＦ管理テーブル（ページＩ／ＯモニタＯＮ／ＯＦＦ管理情報）

Claims (15)

1. 業務用計算機及びストレージに接続する管理計算機であって、
   前記ストレージは、
   レスポンス性能が異なる複数の物理記憶デバイスと、
   前記物理記憶デバイスの実記憶領域、該実記憶領域から構成されるプール、該プールから割り当てられる仮想論理ボリューム、及び前記業務用計算機上で実行されるタスクから前記実記憶領域に対して発行されるＩ／Ｏ数を対応付けるボリューム管理情報を格納するメモリと、
   前記業務用計算機に前記仮想論理ボリュームに含まれる実記憶領域を割り当てる処理、及び前記ボリューム管理情報のＩ／Ｏ数を参照して、前記レスポンス性能が異なる物理記憶デバイスの実記憶領域間でデータを移動する再配置処理を実行するプロセッサと、を有し、
   前記管理計算機は、
   前記タスクに対応するＩ／Ｏを監視するか否かを示す監視要否フラグを含むタスク監視情報を格納するメモリと、
   前記タスク監視情報を参照して、前記監視要否フラグが否となっているタスクから発生するＩ／Ｏについては、前記ボリューム管理情報のＩ／Ｏ数に反映しないことを前記ストレージに行わせるプロセッサと、を有し、
   前記監視要否フラグは、前記タスクの実行状況に応じて動的に変更されることを特徴とする管理計算機。
2. 請求項１記載の管理計算機であって、
   前記タスク監視情報は、さらに、前記タスクについて監視する時刻に関する情報を含むことを特徴とする管理計算機。
3. 請求項２記載の管理計算機であって、
   前記タスクについて監視する時刻に関する情報は、前記タスクについて監視を開始する時刻及び前記タスクについて監視を終了する時刻を含むことを特徴とする管理計算機。
4. 請求項２記載の管理計算機であって、
   前記タスクについて監視する時刻に関する情報は、前記タスクが実行される時間であることを特徴とする管理計算機。
5. 請求項２記載の管理計算機であって、
   前記タスクについて監視する時刻に関する情報は、前記タスクに対する監視を周期的に行うことを含むことを特徴とする管理計算機。
6. 請求項１記載の管理計算機であって、
   前記管理計算機のプロセッサは、さらに、前記再配置処理の結果を出力することを特徴とする管理計算機。
7. 請求項６記載の管理計算機であって、
   前記再配置処理の結果は、前記プール毎に分けられて出力されることを特徴とする管理計算機。
8. 請求項６記載の管理計算機であって、
   前記再配置処理の結果は、前記再配置処理が行われた時間帯毎に分けられて出力されることを特徴とする管理計算機。
9. 請求項６記載の管理計算機であって、
   前記再配置処理の結果は、前記再配置処理に前記タスクがどれだけ寄与したかに関する原因情報を含むことを特徴とする管理計算機。
10. 業務用計算機、ストレージ及び管理計算機を含む計算機システムであって、
    前記ストレージは、
    レスポンス性能が異なる複数の物理記憶デバイスと、
    前記物理記憶デバイスの実記憶領域、該実記憶領域から構成されるプール、該プールから割り当てられる仮想論理ボリューム、及び前記業務用計算機上で実行されるタスクから前記実記憶領域に対して発行されるＩ／Ｏ数を対応付けるボリューム管理情報を格納するメモリと、
    前記業務用計算機に前記仮想論理ボリュームに含まれる実記憶領域を割り当てる処理、及び前記ボリューム管理情報のＩ／Ｏ数を参照して、前記レスポンス性能が異なる物理記憶デバイスの実記憶領域間でデータを移動する再配置処理を実行するプロセッサと、を有し、
    前記管理計算機は、
    前記タスクに対応するＩ／Ｏを監視するか否かを示す監視要否フラグを含むタスク監視情報を格納するメモリと、
    前記タスク監視情報を参照して、前記監視要否フラグが否となっているタスクから発生するＩ／Ｏについては、前記ボリューム管理情報のＩ／Ｏ数に反映しないことを前記ストレージに行わせるプロセッサと、を有し、
    前記監視要否フラグは、前記タスクの実行状況に応じて動的に変更されることを特徴とする計算機システム。
11. 請求項１０記載の計算機システムであって、
    前記タスク監視情報は、さらに、前記タスクについて監視する時刻に関する情報を含むことを特徴とする計算機システム。
12. 請求項１０記載の計算機システムであって、
    前記管理計算機のプロセッサは、さらに、前記再配置処理の結果を出力することを特徴とする計算機システム。
13. 業務用計算機、ストレージ及び管理計算機を含む計算機システムにおいて、前記ストレージで行われる処理を管理する管理方法であって、
    前記ストレージは、
    レスポンス性能が異なる複数の物理記憶デバイスと、
    前記物理記憶デバイスの実記憶領域、該実記憶領域から構成されるプール、該プールから割り当てられる仮想論理ボリューム、及び前記業務用計算機上で実行されるタスクから前記実記憶領域に対して発行されるＩ／Ｏ数を対応付けるボリューム管理情報を格納するメモリと、を有し、
    前記管理計算機は、前記タスクに対応するＩ／Ｏを監視するか否かを示す監視要否フラグを含むタスク監視情報を格納するメモリを有し、
    前記管理方法は、
    前記業務用計算機に前記仮想論理ボリュームに含まれる実記憶領域を割り当てるステップと、
    前記ボリューム管理情報のＩ／Ｏ数を参照して、前記レスポンス性能が異なる物理記憶デバイスの実記憶領域間でデータを移動する再配置処理を行うステップと、
    前記タスク監視情報を参照して、前記監視要否フラグが否となっているタスクから発生するＩ／Ｏについては、前記ボリューム管理情報のＩ／Ｏ数に反映しないステップと、を含み、
    前記監視要否フラグは、前記タスクの実行状況に応じて動的に変更されることを特徴とする管理方法。
14. 請求項１３記載の管理方法であって、
    前記タスク監視情報は、さらに、前記タスクについて監視する時刻に関する情報を含むことを特徴とする管理方法。
15. 請求項１３記載の管理方法であって、さらに、
    前記再配置処理の結果を出力するステップを含むことを特徴とする管理方法。

Images