JP5395962B2 - 計算機システム、及びその管理方法、並びに、プログラム - Google Patents

Description

本発明は、計算機システム、及びその管理方法、並びに、プログラムに関し、例えば、１つ以上のメディア（記憶デバイス）の複数の記憶領域から構成されるストレージプールの容量を把握する技術に関するものである。

近年の各種業務のＩＴ化に伴い、企業が保持するデータ数は増得続けている。このような状況で、ＳＡＮ（Storage Area Network）によるストレージ集約が広く利用されつつある。

また、ストレージ管理コストを軽減する技術として、Thin Provisioningが注目を集めている。Thin Provisioningとは、ストレージがホストに対して仮想ボリュームを割り当て、かつ、ホストからのI/O要求に従って、動的かつ段階的に仮想ボリュームに対してストレージ内のディスク容量を割り当てる技術である。これにより、ホストに割り当てる全ボリュームに対して、ディスクを事前に購入することなく、ホストのストレージ利用状況（具体的には利用ディスクサイズ）を基に段階的にディスクを増強することができる。このようなThin Provisioningに関しては、ストレージ内部に複数のディスクから構成されたプールを構築し、このプールからホストに割り当てる仮想ボリュームを作成し、かつ、ホスト計算機からの当該仮想ボリュームへのI/O要求に伴いプール内のディスクを動的に割り当てる方法がある。このケースでは、プールを管理する必要がある。つまり、定期的にプールの空き容量を監視し、プールの容量枯渇によるI/Oエラーを防止する必要がある。

さらに、Thin Provisioningを拡張し、異なる物理特性のディスクの組合せでプールを構成し（例えばＳＳＤとＳＡＴＡディスク）、I/O頻度が高いデータを高速ディスク（例えばＳＳＤ）に配置し、I/O頻度が低いデータを低速ディスク（例えばＳＡＴＡ）に配置することもできる。この場合にもThin Provisioningのケースと同様にプールの空き容量を監視する必要がある。

特開２００３−２１６４６０号公報

ところで、上述したThin Provisioningにおける従来のプール容量監視技術（従来方法）では、プールの容量枯渇タイミングを予測するため、過去のプールの容量消費傾向から将来の消費傾向を予測し、容量枯渇が発生する時期を予測している。

しかしながら、上記従来方法では、外的環境の変更については考慮されていない。つまり、従来方法では、過去のプールの容量消費傾向にのみ基づいて将来の消費傾向を予測していたため、既存プールから新規アプリケーションへのボリューム割り当て等の構成変更によるプール容量消費傾向の変化を予測できない。

また、従来方法で構成変更によるプール容量消費傾向の変化を予測する場合、新規ボリュームのプール容量消費傾向を予測可能になるまで履歴を取得する必要があり、ボリューム追加のタイミングでプール容量枯渇タイミングを把握することができない。

本発明はこのような状況に鑑みてなされたものであり、新規アプリケーションの追加や既存アプリケーションの特性変更等の外部環境の変化があっても適切にプール容量枯渇のタイミングを予測することができるプール容量監視技術を提供するものである。

上記課題を解決するために、プールの容量枯渇タイミングを予測するため、アプリケーションの追加等の外部環境変化がある度にプールを構成するメディア毎の消費量を予測し、容量枯渇時期の予測を再計算する。また、仮想ボリュームを利用するアプリケーション毎のI/O消費傾向を、ストレージ内に貯めた過去の消費傾向からメディア毎に予測値を算出する。

即ち、本発明による計算機システムは、１つ以上の物理記憶デバイスの記憶領域を仮想ボリュームとしてホスト計算機に提供するストレージサブシステムと、ストレージサブシステムを管理する管理計算機と、を有している。そして、管理計算機は、アプリケーションが使用すべき仮想ボリュームの割り当てについての入力指示に応答して、アプリケーションとアプリケーション種別が同一或いは類似のアプリケーションが使用する仮想ボリュームの過去の消費容量動向に関する情報を取得し、当該消費容量動向に関する情報に基づいて、割当て予定の仮想ボリュームおける消費容量を予測する。

本発明によれば、新規アプリケーションの追加や既存アプリケーションの特性変更等の外部環境の変化があっても適切にプール容量枯渇のタイミングを予測することができるようになる。

なお、上述した以外の課題、構成及び効果は、以下の本発明を実施するための形態および添付図面によって明らかになるものである。

本発明の実施形態による計算機システムの概略構成を示す図である。 ホスト計算機の内部構成を示す図である。 ストレージサブシステムの内部構成を示す図である。 ＲＡＩＤグループ管理表の構成例を示す図である。 実領域管理表の構成例を示す図である。 仮想ボリューム（ＶＶＯＬ）管理表の構成例を示す図である。 階層定義表の構成例を示す図である。 プール−仮想ボリューム（ＶＶＯＬ）対応管理表の構成例を示す図である。 管理計算機の内部構成を示す図である。 アプリケーション名とアプリケーションタイプと仮想ボリュームＩＤの対応関係を示すマッピングテーブルの構成例を示す図である。 仮想ボリューム容量情報テーブルの構成例を示す図である。 プール容量予測テーブルの構成例を示す図である。 計算機システムにおける処理の全体的概要を説明するための図である。 アプリケーション情報入力画面（ＧＵＩ）の構成例を示す図である。 階層管理表設定画面（ＧＵＩ）の構成例を示す図である。 プール容量予測結果レポート画面の構成例を示す図である。 再配置処理を説明するためのフローチャートである。 管理計算機が実行する処理の概要について説明するためのフローチャートである。 アプリケーション追加時における、新規ＶＯＬへのＰａｇｅ割当て量予測エンジンの処理の詳細を説明するためのフローチャートである。 既存ＶＯＬへのＰａｇｅ割当て量予測エンジンの処理概要について説明するためのフローチャートである。 プールの各Ｔｉｅｒの予測容量消費量算出処理（ステップ２００１）の詳細を説明するためのフローチャートである。 プールの各Ｔｉｅrの容量消費量算出処理（ステップ２００２）の詳細を説明するためのフローチャートである。 アプリケーション削除画面（ＧＵＩ）の構成例を示す図である。 Ｔｉｅｒ毎の課金設定画面（ＧＵＩ）の構成例を示す図である。 Ｔｉｅｒ毎の課金管理テーブルの構成例を示す図である。 プール容量予測結果レポート画面の構成例を示す図である。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

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

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

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

＜計算機システムの構成＞
図１は、本発明の実施形態による計算機システム１００の概略構成を示す図である。計算機システム１００は、ホスト計算機１０１と、ストレージサブシステム１０２と、管理システム１０７と、を有している。ストレージサブシステム１０２とホスト計算機１０１とは、ストレージエリアネットワーク１０５によって接続されている。また、管理システム１０７とストレージサブシステム１０２及びホスト計算機１０１とは、管理用ネットワーク１０６によって接続されている。

管理システム１０７は、管理計算機１０３とＷｅｂブラウズ用計算機１０４を含む。なお、管理計算機１０３とＷｅｂブラウズ用計算機１０４とは、同じ計算機でもよく、また、それぞれ複数の計算機で同等の機能を実現していてもよい。管理システム１０７は、管理用ネットワーク１０６を介してストレージサブシステム１０２に制御要求を送信する。

ホスト計算機１０１は、管理用ネットワーク１０６を介して管理システム１０７にアクセス要求を送信する。

ストレージサブシステム１０２は、管理システム１０７から管理用ネットワーク１０６を介して制御要求を受信し、要求に従う処理を実行する。なお、本計算機システム１００に含まれるホスト計算機１０１、ストレージサブシステム１０２、及び管理システム１０７は、それぞれ複数設置しても良い。

＜ホスト計算機の構成＞
図２は、ホスト計算機１０１の内部構成を示す図である。ホスト計算機１０１は、ストレージエリアネットワーク１０５との接続を実現するためのＳＡＮポート２０３と、管理用ネットワーク１０６との接続を実現するためのＬＡＮポート２０５と、メモリ２０２と、メモリ２０２およびＳＡＮポート２０３、ＬＡＮポート２０５に接続されたＣＰＵ２０１と、を有する。

ＳＡＮポート２０３は、ストレージエリアネットワーク１０５に接続されている。また、ＬＡＮポートは管理用ネットワーク１０６に接続されている。

メモリ２０２には、１つ以上のアプリケーションプログラム２０４が格納されている。各アプリケーションプログラム２０４は、ＣＰＵ２０１によって実行され、ＬＡＮポート２０５、および管理用ネットワーク１０５を介して、ストレージサブシステム１０２にアクセス要求を送信する。

＜ストレージサブシステムの構成＞
図３は、ストレージサブシステム１０２の内部構成を示す図である。ストレージサブシステム１０２は、ディスク回転数等の物理特性の異なる複数の物理記憶デバイス３０５と、コントローラ３１２を有し、これらは内部バス等の回路を介して相互に接続されている。同種の物理記憶デバイス３０５が複数ある場合、それらはＲＡＩＤ構成を組んでいてもよい。ＲＡＩＤ構成を組んでいる複数の物理記憶デバイス３０５は、ＲＡＩＤグループ３０６を構成する。

コントローラ３１２は、ストレージエリアネットワーク１０５に接続するための少なくとも１つのＳＡＮポート３０２と、管理用ネットワーク１０６に接続するための少なくとも１つのＬＡＮポート３０３と、メモリ３０４と、それらに接続されたＣＰＵ３０１と、を有する。

ＳＡＮポート３０２は、ストレージエリアネットワーク１０５に接続されるポートである。ＳＡＮポート３０２は、ホスト計算機１０１からのアクセス要求を受信する。

ＬＡＮポート３０３は、管理用ネットワーク１０６に接続されるポートである。ＬＡＮポート３０３は、管理システム１０７からの制御要求を受信する。

メモリ３０４には、ストレージ制御プログラム３０７と、ＲＡＩＤグループ管理表３０８と、実領域管理表３０９と、階層管理表３１０と、ＶＶＯＬ管理表３１１とストレージ情報取得エージェント３１３と、プール−仮想ボリューム対応管理表３１４と、が格納されている。

ストレージ情報取得エージェント３１３は、ストレージサブシステム１０２内コントローラ３１２より、ストレージサブシステム１０２から、各ＶＯＬについて、Ｔｉｅｒ毎の割当て容量の情報を取得するプログラムである。なお、取得する情報については後述する。

ストレージ制御プログラム３０７は、ＣＰＵ３０１で実行されることにより、指定された管理システム１０７に対してのみ、後述する仮想ボリュームに対してアクセス可能とするアクセス制御処理とデータ書き込み処理と再配置処理を行う。

ストレージ制御プログラム３０７は次のようにデータ書き込み処理を実行する。つまり、まず、ストレージ制御プログラム３０７は、データ書き込み要求をホスト計算機１０１から受信すると、データ書き込み要求が有するアクセス先情報を基に、データを書き込む先の仮想領域（以下、書き込み先仮想領域）を特定する。

次に、ストレージ制御プログラム３０７は、書き込み先仮想領域に実領域が割り当てられているか否かを判断する。具体的には、書き込み先仮想領域がＶＶＯＬ管理表３１１に登録されているか否かを判断する。

書き込み先仮想領域に実領域が割り当てられている場合、ストレージ制御プログラム３０７は、書き込み対象データを書き込み先仮想領域に割り当てられている実領域に書き込む。書き込み先仮想領域に実領域が割り当てられていない場合、ストレージ制御プログラム３０７は、書き込み先仮想領域に割り当てられる未割当の実領域が存在するか否かを判断する。具体的には、ストレージ制御プログラム３０７は、実領域管理表３０９の割当状況５０４が「未割当」である実領域が存在するか否かを判断する。

書き込み先仮想領域に未割当の実領域が存在する場合、ストレージ制御プログラム３０７は、書き込み先仮想領域に未割当の実領域を割り当てて、書き込み対象データを当該実領域に書き込む。

書き込み先仮想領域に未割当の実領域が存在しない場合、ストレージ制御プログラム３０７は、ホスト計算機１０１にエラーを送信する。

また、ストレージ制御プログラム３０７は書き込み先仮想領域がプールの構成要素であるかを判断する。プールの構成要素で合った場合はプールの識別子であるプールＩＤ２３０２と仮想ボリュームの識別子であるＶＶＯＬＩＤ２３０１の組の値をプールと仮想ボリュームとの対応管理表２３０１に書き込む。

最後に、ストレージ制御プログラム３０７は、書き込み元仮想領域に対応するアクセス数６０４の値を更新する。

＜仮想ボリュームの実現方法＞
ストレージ制御プログラム３０７は、後述する図４に示すように、複数の物理記憶デバイスからＲＡＩＤグループを構築する。ストレージ制御プログラム３０７は、ホスト計算機１０１から指定された仮想ボリュームを割当てる際、ボリュームサイズに対応した物理ディスクを当該ホスト計算機１０１に割当てるわけではなく、ボリュームの利用状況に応じて動的に物理ディスクを割当てる。以降では、このボリュームを仮想ボリューム（「ＶＶＯＬ」ともいう）と呼ぶこととする。

上述の仮想ボリュームを実現する方法として、ストレージ制御プログラム３０７は、まず、各ＲＡＩＤグループを固定サイズ（例えば１０００ブロック）に分割する。以降では分割した単位をセグメントと呼ぶ。また、ストレージ制御プログラム３０７は、後述する図５に示すように、各セグメントの割当て状況を把握し、ある仮想ボリュームに新規セグメントを割当てる際に、未割当セグメントを利用する。

なお、ストレージ制御プログラム３０７が実行する再配置処理については、後述する。

＜ＲＡＩＤグループ管理表３０８＞
図４は、ストレージサブシステム１０２が有するＲＡＩＤグループ管理表３０８の構成例を示す図である。ＲＡＩＤグループ管理表３０８は、ＲＡＩＤグループ３０６の性能に関する情報を有する。

例えば、ＲＡＩＤグループ管理表は、ＲＡＩＤグループの識別子を表すＲＡＩＤグループＩＤ４０１と、ＲＡＩＤグループを構成する物理記憶デバイスの種類を表すデバイス種別４０２と、ＲＡＩＤグループのＲＡＩＤレベルおよびコンビネーションを表すＲＡＩＤレベル４０３と、ＲＡＩＤグループを構成する物理記憶デバイスの識別子を表すＰＤＥＶ_ＩＤ４０４と、を構成項目として含んでいる。なお、情報４０１〜４０４のうちの少なくとも１つに代えてまたは加えて、他種の情報が含まれていてもよい。

＜実領域管理表３０９＞
図５は、ストレージサブシステム１０２が有する実領域管理表３０９の構成例を示す図である。実領域管理表３０９は、各ＲＡＩＤグループ３０６が持つ実領域が、仮想ボリュームに割当済か否かの情報を有する。

例えば、実領域管理表３０９は、実領域を持つＲＡＩＤグループの識別子を表すＲＡＩＤグループＩＤ５０１と、実領域の識別子を表す実領域ＩＤ５０２と、実領域に対応するＲＡＩＤグループのＬＢＡ範囲を表すＲＧ_ＬＢＡ範囲５０３と、実領域が割当済か否かを表す割当状況５０４と、を構成項目として含んでいる。

＜ＶＶＯＬ（仮想ボリューム）管理表３１１＞
図６は、ストレージサブシステム１０２が有するＶＶＯＬ管理表３１１の構成例を示す図である。ＶＶＯＬ管理表３１１は、仮想ボリューム内の各仮想領域と、その仮想領域に割り当てられている実領域に関する情報を有する。

例えば、ＶＶＯＬ管理表３１１は、仮想ボリュームの識別子を表すＶＶＯＬ ＩＤ６０１と、仮想ボリューム内の仮想領域に対応するＬＢＡ範囲を表すＶＶＯＬ ＬＢＡ範囲６０２と、仮想ボリューム内の仮想領域に割り当てられている実領域を表す実領域ＩＤ６０３と、仮想ボリューム内の仮想領域に対する、ホスト計算機１０１からのアクセス数（一定期間内での累計のＩ／Ｏ数）を表すアクセス数６０４と、後述する再配置処理（図１７参照）において仮想ボリューム内の仮想領域にその階層内の実領域を割り当てるべきであると判定された当該階層の識別子を表す再配置判定結果６０５を構成項目として含んでいる。

上記ＶＶＯＬ管理表３１１において、ＶＶＯＬ_IＤ６０１は、ホスト計算機１０１から指定される識別子ではなく、ストレージサブシステム１０２の内部で認識される識別子を示す情報である。アクセス数６０４は、当該仮想領域に対するアクセス回数の値を持っており、ストレージサブシステム１０２は一定期間、例えば２４時間ごとに、アクセス数６０４の値を０にリセットする。また、再配置判定結果６０５には、ストレージ制御プログラム３０７がＴｉｅｒの許容アクセス数を監視し、図７に示す階層管理表３１０の許容アクセス数範囲７０３の値に基づいて判定した結果を格納する。

なお、図６における再配置判定結果６０５は、再配置判定を実行した後であるが、再配置処理は実行していない状態での判定結果の情報を示している。従って、再配置判定結果６０５が示す階層の情報と、実領域ＩＤ６０３が示す領域が属するデバイスが属する階層が合致していないことに注意すべきである。再配置処理を実行した直後は、両者の情報は合致したものとなっている。

＜階層定義表３１０＞
図７は、ストレージサブシステム１０２が有する階層定義表３１０の構成例を示す図である。階層定義表３１０は、階層の性能及び許容するアクセス数の範囲に関する情報を有する。

例えば、階層定義表３１０は、階層毎に、階層の識別子を表す階層ＩＤ７０１と、階層の性能要件を表す性能要件７０２と、階層に対応した、単位時間当たりの許容アクセス数の範囲を表す許容ＩＯＰＳ範囲７０３と、を構成項目として含んでいる。階層定義表３１０において、階層の性能要件７０２は、例えば、物理記憶デバイスの種別と、ＲＡＩＤグループのＲＡＩＤレベルとで定義される。

階層ＩＤで特定される各階層７０１は、性能要件７０２を満たす物理記憶デバイスまたは／およびＲＡＩＤグループに属する実領域を要素に持っている。

なお、階層定義表３１０は、管理計算機１０３或いはホスト計算機１０１からの要求に応じて管理用ネットワークを介してストレージサブシステム１０２のＬＡＮポート３０３のメモリ３０４の階層管理表３１０に設定される。

＜プール−仮想ボリューム対応管理表３１４＞
図８は、プールと仮想ボリュームとの対応関係を管理する、プール−仮想ボリューム（ＶＶＯＬ）対応管理表３１４の構成例を示す図である。

例えば、プール−仮想ボリューム対応管理表３１４は、プールＩＤ３１４１と、ＶＶＯＬ_ＩＤ３１４２と、を構成項目として含んでいる。

プール−仮想ボリューム対応管理表３１４により、各プールがどの仮想ボリュームから構成されているかが分かる。例えば、プールＡは、仮想ボリューム（ＶＶＯＬ）ＡとＢとから構成されている。この情報は、ストレージ制御プログラム３０７によって取得され、必要な処理に用いられる。

＜管理計算機の構成＞
図９は、管理計算機１０３の内部構成を示すブロック図である。管理計算機１０３は、管理用ネットワーク１０６に接続するためのＬＡＮポート８０２と、構成管理プログラム８０４を実行するＣＰＵ８０１と、ＣＰＵ８０１が用いるメモリ８０３とを有し、これらは内部バス等の回路を介して相互に接続されている。

メモリ８０３は、アプリケーション情報取得エンジン８０４と、プール容量予測エンジン８０５と、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６と、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７と、結果表示エンジン８０８と、Ｔｉｅｒ定義取得エンジン８０９と、ストレージ情報取得エンジン８１０を格納している。ここで、「エンジン」とはリクエストを出して所望の情報を取得するプログラムを意味し、特に断らない限り、「プログラム」と読み替えても良い。

また、管理計算機１０３は、記憶装置８１１と、表示装置８１３と、入力装置８１４を有している。記憶装置８１１はデータ格納用ＤＢ８１２を有している。

なお、管理計算機５０が有する入力装置４００の例としてキーボードとポインタデバイスが考えられるが、これ以外の装置であっても良い。また、表示装置４０１に代えて、或いはそれに加えて、それ以外の出力装置（例えば、プリンタ）を設けるようにしても良い。

入力装置及び表示装置（出力装置）の代替としてシリアルインターフェースやイーサーネットインターフェースを入出力装置とし、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。

以後、計算機システム１００を管理し、本願発明の表示用情報を表示する１つ以上の計算機の集合を管理システムと呼ぶことがある。管理計算機１０３が表示用情報を表示する場合は管理計算機１０３が管理システム１０７であり、また、管理計算機１０３とＷｅｂブラウズ用計算機（表示用計算機）１０４の組み合わせも管理システム１０７である。また、管理処理の高速化や高信頼化のために複数の計算機で管理計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が管理システム１０７である。

（i）アプリケーション情報取得エンジン
アプリケーション情報取得エンジン８０４は、アプリケーション情報入力画面１３０１（図１４参照）で入力したユーザが割当て予定のＶＯＬとアプリケーションとの対応関係を取得し、管理計算機１０３の記憶装置８１１のデータ格納用ＤＢに存在するアプリケーションとボリュームとのマッピングテーブル９０１に格納する。なお、マッピングテーブル９０１は、データ格納用ＤＢ８１２の中に含まれている。

アプリケーション情報取得エンジン８０４は、入力画面１３０１から入力された新規に追加されるアプリケーション名と、アプリケーションタイプと、仮想ボリュームの情報を取得し、それらをマッピングテーブル９０１（図１０参照）に格納する。

マッピングテーブル９０１は、図１０に示されるように、アプリケーション名９０２と、アプリケーションタイプ９０３と、仮想ＶＯＬ_ＩＤ９０４と、を構成項目として含んでいる。このテーブルを確認することにより、どのようなアプリケーションがどの仮想ボリュームに割り当てられているか把握することができるようになっている。

なお、アプリケーション情報取得エンジン８０４の処理の延長で割当て予定のボリューム（ＶＯＬ）をホスト計算機１０１に割当ててもよい。また、ユーザからの割当て指示の入力がなされて直ぐにＶＯＬを割り当てても良いし、割当て予定のＶＯＬをユーザから指示された指定期間経過後に割当てるというように予約できるようにしても良い。

（ii）Ｔｉｅｒ定義取得エンジン
Ｔｉｅｒ定義取得エンジン８０９は、階層管理表設定画面１４０１（図１５参照）を用いてユーザが入力した情報を取得し、管理計算機１０３のＬＡＮポート８０２と管理用ネットワーク１０６とストレージサブシステム１０２のＬＡＮポート３０３を介してストレージサブシステム１０２のメモリ３０４内の階層管理表３１０に格納する。

より具体的には、Ｔｉｅｒ定義取得エンジン８０９は、例えばストレージサブシステム１０２のストレージ制御プログラム３０７と協働して、階層管理表３１０に対して、階層ＩＤ１４０２を階層ＩＤ７０１に、デバイス種別１４０３及びＲＡＩＤレベル１４０４を性能要件７０２に、許容アクセス数範囲１４０５を許容アクセス数範囲７０３に、それぞれ格納することになる。

（iii）ストレージ情報取得エンジン
ストレージ情報取得エンジン８１０は、定期的に管理計算機１０３のＣＰＵ８０１で実行される。実行時、ストレージ情報取得エンジン８１０は、ストレージサブシステム１０２のメモリ３０４のストレージ情報取得エージェント３１３から各ＶＶＯＬについてＴｉｅｒ毎の割当て容量を取得する。そして、ストレージ情報取得エンジン８１０は、取得した情報を、ＬＡＮポート３０３と管理用ネットワーク１０６とＬＡＮポート８０２と記憶装置８１１を介して、データ格納用ＤＢ８１２内の仮想ボリューム容量情報テーブル１００１へ格納する。

より具体的には、ストレージ情報取得エンジン８１０は、仮想ボリューム容量情報テーブル１００１のＶＶＯＬＩＤ１００４に、ＶＯＬ管理表３１１のＶＶＯＬ_ＩＤ６０１を格納する。また、ストレージ情報取得エンジン８１０は、ＶＶＯＬのトータル容量をＶＶＯL容量１００５に、ＶＶＯＬの各Ｔｉｅｒ利用量の情報をＴｉｅr１利用量１００６、Ｔｉｅｒ２利用量１００７、及びＴｉｅｒ３利用量１００８に、データ収集した時刻を収集時間１００２に、それぞれ格納する。さらに、ストレージ情報取得エンジン８１０は、当該ＶＶＯＬが属するプール名をプール−仮想ボリューム対応管理表３１４のプールＩＤ３１４１から取得してプールＩＤ１００３に格納する。

（iv）プール容量予測エンジン
プール容量予測エンジン８０５は、アプリケーション及びＶＶＯLの追加または、既存のＶＶＯLへのＰａｇｅ割当て、増加後のプールの容量を予測するエンジンである。具体的には、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６と既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７を起動し、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６と既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７が算出した値を合計した上で結果をプール容量予測テーブル１１０１（図１２参照）に格納する。なお、本実施形態では、従来のＰｏｏl単位での容量予測ではなく、各Ｔｉｅrについて容量予測を行うようにしている。

（v）新規ＶＯＬへのＰａｇｅ割当て量予測エンジン
新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６は、アプリケーション情報入力画面１３０１のアプリケーション名１３０７とアプリケーションタイプ１３０８と予測期間１３０９の情報から、過去に導入済みの同一、同種或いはアプリケーションの利用するボリュームの消費傾向が類似するアプリケーション（以下、「類似等するアプリケーション」ということとする）の情報をアプリケーションとボリュームとのマッピングテーブル９０１から特定する。そして、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６は、導入当初から測期間１３０９で指定した期間分の過去のＶＶＯLの容量消費傾向を仮想ボリューム容量情報テーブル１００１から取得する。さらに、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６は、上記類似等するアプリケーションのＶＶＯＬの容量消費傾向から、各Ｔｉｅｒの利用率を算出しプール容量予測エンジン８０５に算出した値を返す。なお、各Ｔｉｅｒの利用率の算出方法については、図１９を用いて後述する。

（vi）既存ＶＯＬへのＰａｇｅ割当て量予測エンジン
既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７は、ストレージサブシステム１０２が管理する各プールについて、Ｔｉｅｒ毎の割当て済みＰａｇe数の履歴情報を仮想ボリューム容量情報テーブル１００１から取得し、最尤推定法（例えば、最小二乗法）を用いて、アプリケーション情報入力画面１３０１で指定した予測期間１３０９後のプールの容量消費量を予測する。予測した算出結果をプール容量予測エンジン８０５に返す。なお、算出方法については、図２０乃至２２を用いて後述する。

（vii）結果表示エンジン
結果表示エンジン８０８は、プール容量予測エンジンが起動する。プール容量予測テーブル１１０１から、データを取得し、表示装置８１３にプール容量予測結果レポート画面１５０１を出力する。

＜本システムにおける処理概要＞
本実施形態によるストレージサブシステム１０２は、定期的に、ストレージサブシステム１０２が提供するプールと仮想ボリュームの構成情報と容量情報を収集する処理と、ユーザが指定するＴｉｅｒの階層管理を行うための入力情報を基にＴｉｅｒを再配置する処理と、を実行する。

プールは、複数の階層で構成されている。階層は、同じ性能を有する実領域の集合である。階層は例えば性能を表す特定の値によって定義され、その値が表す性能と同じ性能を有する実領域を内包する。階層は、他の階層と比較した高低の概念を持つ。階層の高さは、階層の性能の高さに依存する。なお、ここで言う「性能」とは、例えばアクセス性能であり、レスポンスタイム、あるいはデータ転送速度、ＩＯＰＳ（単位時間当たりに処理したアクセス要求の数）等が含まれる。アクセス要求の一例としてはライト要求又はリード要求がある。

各階層は、２以上の実領域で構成されている。したがって、プールは複数の実領域で構成されていると言うことができる。また、実領域は、物理記憶デバイスまたは／およびＲＡＩＤグループの記憶領域の一部である。階層の性能は、階層を構成する実領域の性能に依存する。実領域の性能は、例えば、当該実領域を有する物理記憶デバイスの種別、ＲＡＩＤグループのＲＡＩＤレベル、または／およびＲＡＩＤグループに参加する記憶デバイスの数に依存する。物理記憶デバイスの種別として、例えば、ＳＳＤと、ＳＡＳ−ＨＤＤ、およびＳＡＴＡ−ＨＤＤがある。

仮想ボリュームは、複数の仮想領域（仮想的な記憶領域）で構成されている。各仮想領域には、それぞれ１つ以下の実領域が割り当てられている。なお、仮想領域には、実領域が割り当てられていなくてもよい。ストレージサブシステム１０２は、そのような仮想領域（未割当の仮想領域）に対するライト要求をホスト計算機から受けたときには、いずれの仮想領域にも割り当てられていない実領域（未割当の実領域）を、当該仮想領域に割り当てるようにする。

一方、管理計算機１０３は、ユーザが指定する追加すべきアプリケーションとＶＶＯＬの情報の情報を基に、アプリケーションが利用するＶＶＯＬの容量消費傾向を予測し、予測結果をレポーティング（出力）する処理を実行する。これらついては、データ構造と処理フローを中心にシステム全体の概略は図１３を用いて説明する。図１３は、本システムにおける処理の全体的概要を説明するための図である。

（i）追加すべきアプリケーションの情報入力からプール要領予測結果出力までの処理
管理システム１０７に表示されるアプリケーション情報入力画面１３０１から追加或いは、ボリュームの対応を変更するアプリケーションについての情報が入力されると、アプリケーション情報取得エンジン８０４は、その入力情報をアプリケーションとボリュームとのマッピングテーブル９０１に格納する。

そして、プール予測エンジン８０６は、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６及び既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７を起動する。両エンジン８９６及び８０７はそれぞれの処理を実行し、実行結果をプール容量予測エンジン８０５に提供する。実行結果を受け取ったプール容量予測エンジン８０５は、当該プール容量予測結果をプール容量予測テーブル１１０１に格納すると共に、結果表示エンジン８０８を起動する。また、起動された結果表示エンジン８０８は、プール容量予測テーブル１１０１から該当するプール容量予測結果を取得し、プール容量予測結果レポート画面１５０１（図１６参照）に表示する。

（ii）ストレージ情報取得処理
ストレージ情報取得エンジン８１０は、定期的にストレージサブシステム１０２内のデータをポーリングして各仮想ボリュームの容量を取得し、当該容量の情報を仮想ボリューム容量情報テーブル１００１に格納する（図１１参照）。

（iii）階層定義取得処理
管理システム１０７に表示される階層管理表設定画面１４０１（図１５参照）を用いて設定された階層の情報が入力されると、階層定義取得エンジン８０９は、ストレージサブシステム１０２の階層管理表３１０に格納する。

＜ストレージサブシステム１０２の定期的に実行するＴｉｅｒ再配置処理＞
管理計算機１０３は、定期的にＴｉｅrの再配置処理の実行をストレージサブシステム１０２に定期的に指示する。例えば、1時間や３０分毎に、当該仮想ボリューム内の仮想領域に対する実領域の割当状況を見直す。

管理計算機１０３は、当該仮想ボリューム内の各仮想領域について、仮想領域へのアクセス数が、当該仮想領域に割り当てられている実領域を有する階層に対応したアクセス数範囲を超えているか否かを判断する。管理システムは上記の判断の結果、範囲外であると判断した仮想領域に対して、当該仮想領域に割り当てられている実領域（以下、移行元の実領域）に代えて、当該仮想領域へのアクセス数が収まるアクセス数範囲に対応する階層内の実領域（以下、移行先の実領域）を割り当てる。具体的には、管理計算機１０３はストレージサブシステム１０２に、移行元の実領域のデータを移行先の実領域に移行するよう指示する。なお、ここで、仮想領域へのアクセス数とは、対象仮想領域の全てまたは一部について、アドレス範囲として指定し、処理が完了したアクセス要求数を意味する。

＜再配置処理＞
図１７は、再配置処理の詳細を説明するためのフローチャートである。再配置処理は、ＶＶＯＬ管理表３１１のＶＶＯＬＩＤ６０１登録されている仮想ボリューム（以下、図１７の説明において対象ＶＶＯＬ）に対して行う処理である。

（ステップ１７００の処理内容）
管理計算機１０３は、一定時間毎（例えば３０分毎や１時間毎）に、ストレージサブシステム１０２のストレージ制御プログラム３０７へ再配置処理の実行を要求する。

（ステップ１７０１の処理内容）
ストレージ制御プログラム３０７は、ＶＶＯＬ管理表３１１に登録される各ＶＶＯＬＩＤ６０１のアクセス数６０４の値を取得し、各仮想領域のアクセス数６０４の値と階層管理表３１０の許容アクセス数範囲７０３とを突き合わせることで、現配置箇所が妥当かを判断した上で該当する階層ＩＤ７０１を特定する。この結果、記録された階層ＩＤは、当該仮想領域に割り当てられている実領域を含む階層の階層ＩＤと同じであることもあれば異なることもある。

（繰り返し処理）
次に、ストレージ制御プログラム３０７は、ステップ１７０１で取得したすべての仮想領域に対してステップ１７０３〜１７０８の処理を実行する。

（ステップ１７０３の処理内容）
ストレージ制御プログラム３０７は、現在対象仮想領域に割り当てられている実領域に対応する階層（「対象領域配置元階層」という）のＩＤとステップ１７０１で特定した再配置判定結果の値とが一致するか否かを判定する。具体的には、ストレージ制御プログラム３０７は、対象仮想領域に割り当てられている実領域のＩＤ６０３を基に、その実領域を含むＲＡＩＤグループのＩＤ５０１を特定し、そのＲＡＩＤグループに対応するデバイス種別４０２または／およびＲＡＩＤレベル４０３が適合する性能要件７０２に対応する階層ＩＤ７０１を特定する。特定した階層ＩＤ７０１と、ステップ１７０１で特定した再配置判定結果の値が一致するか否かを判定する。

対象領域配置元階層が配置されるべき階層の場合（ステップ１７０３でＹｅｓの場合）、対象の仮想領域のデータ移行は不要のため、対象の仮想領域に対する処理は終了する。一方、対象領域配置元階層が配置されるべき階層でない場合（ステップ１７０３でＮｏの場合）、処理はステップ１７０４に移行する。

（ステップ１７０４の処理内容）
ストレージ制御プログラム３０７は、実領域管理表３０９を基にステップ１７０１で特定した再配置判定結果の階層ＩＤによって示される階層（「対象領域配置先階層」という）内に、未割当の実領域が存在するか否かを判定する。

配置されるべき階層に空きがある場合（ステップ１７０４でＹｅｓの場合）、処理はステップ１７０６に移行し、配置されるべき階層に空きがない場合（ステップ１７０４でＮｏの場合）、処理はステップ１７０５に移行する。

（ステップ１７０６の処理内容）
ストレージ制御プログラム３０７は、対象仮想領域に現在割り当てられている実領域（「データ移行元実領域」という）に代えて、対象領域配置先階層内の未割当の実領域（「データ移行先実領域」という）を割り当てる。具体的には、ストレージ制御プログラム３０７は、実領域管理表３０９の、データ移行元実領域に対応する割り当て状況３０９の値を未割当に更新し、データ移行先実領域に対応する割り当て状況３０９の値を割当済みに更新する。なお、本実施形態では、例えば、実領域と仮想領域は同じ容量で区切られるように管理され、移行元と移行先の容量を考慮する必要がないようになっている。

また、ストレージ制御プログラム３０７は、ＶＶＯＬ管理表３１１の、対象仮想領域に対応する実領域ＩＤ６０３の値を、データ移行先実領域のＩＤに更新する。また、ストレージ制御プログラム３０７はデータ移行元実領域からデータ移行先実領域にデータを移行する。

なお、ステップ１７０６の処理を行うと、他の仮想ボリュームの性能に影響を及ぼす場合がある。例えば、ある仮想ボリュームの再配置処理において、ステップ１７０６の処理を行った結果、性能が高い階層内の未割当実領域を全て使い切ってしまう場合がある。この場合、この後に再配置処理を行う仮想ボリューム内の仮想領域には、当該階層内の未割当実領域を割り当てることができない。したがって、当該階層内の実領域を割り当てるべきであると判定された仮想領域が存在する場合、後述するステップ１７０７および１７０８の処理のように、当該階層内の実領域が割り当てられている他の仮想領域と割り当て状況およびデータを入れ替えたり、性能が近い他の階層の実領域を割り当てたりすることとなり、性能に影響を及ぼす場合がある。本事象に対処するためには、例えば、再配置処理において、対象ＶＶＯＬの仮想領域に未割当の実領域を割り当てることは行わず、常に対象ＶＶＯＬ内の他の仮想領域との入れ替えのみによって、対象ＶＶＯＬ内仮想領域への実領域割り当て状況の最適化を実現する方法が考えられる。再配置処理において未割当の実領域を使用するか否かは、例えば、各階層内において未割当である実領域の個数または／および割合によって、ストレージ制御プログラム３０７が判断する。より具体的には、ストレージ制御プログラム３０７は、ステップ１７０４の処理において、対象領域配置先階層内に未割当実領域が存在したとしても、その個数が対象領域配置先階層内の全実領域数の１割よりも少ない場合は、ステップ１７０６の処理ではなくステップ１７０５の処理に移行する。

（ステップ１７０５の処理内容）
ストレージ制御プログラム３０７は、対象仮想領域に割り当てられている実領域と、データを入れ替え可能な実領域が存在するか否かを判定する。具体的には、ストレージ制御プログラム３０７は、対象領域配置先階層内の割当済の実領域の中で、その実領域が割り当てられている仮想領域に対応するステップ１７０１で特定した再配置判定結果の階層ＩＤが、対象領域配置元階層の階層ＩＤと一致するものが存在するか否かを判定する。

入れ替え可能な実領域が存在する場合（ステップ１７０５でＹｅｓの場合）、処理はステップ１７０７に移行し、入れ替え可能な実領域が存在しない場合（ステップ１７０５でＮｏの場合）、処理はステップ１７０８に移行する。

（ステップ１７０７の処理内容）
ストレージ制御プログラム３０７は、対象仮想領域に割り当てられている実領域（以下、ステップ１７０７の説明において「対象実領域１」という）と、対象領域配置先階層が有する割当済実領域（以下、ステップ１７０７の説明において「対象実領域２」という）との間で、仮想領域への割り当て状況を入れ替える。具体的には、ストレージ制御プログラム３０７は、ＶＶＯＬ管理表３１１の実領域ＩＤ６０３において、対象実領域１のＩＤが格納されている箇所に対象実領域２のＩＤを格納し、対象実領域２のＩＤが格納されている箇所に対象実領域１のＩＤを格納する。また、ストレージ制御プログラム３０７は、対象実領域１と対象実領域２の間のデータの入れ替えを行う。例えば、ストレージ制御プログラム３０７は、下記の処理を行うことによりデータの入れ替えを実現する。なお、下記処理におけるキャッシュメモリ領域は、ストレージサブシステム１０２が有する未割当実領域でもよい。

手順１：ストレージ制御プログラム３０７は、対象実領域１内のデータをキャッシュメモリ領域に書く。

手順２：ストレージ制御プログラム３０７は、対象実領域２内のデータをキャッシュメモリ領域に書く。

手順３：ストレージ制御プログラム３０７は、対象実領域１のデータをキャッシュメモリ領域から対象実領域２に書き込む。

手順４：ストレージ制御プログラム３０７は、対象実領域２のデータをキャッシュメモリ領域から対象実領域１に書き込む。

（ステップ１７０８の処理内容）
ストレージ制御プログラム３０７は、対象階層に性能が最も近い階層内の未割当の実領域に、対象仮想領域に割り当てられている実領域内のデータを移行する。また、ストレージ制御プログラム３０７は、ＶＶＯＬ管理表３１１と実領域管理表３０９を更新する。

＜管理計算機１０３が実行する全体的処理の概要＞
図１８は、本実施形態における管理計算機１０３が実行する全体的処理の概要について説明するためのフローチャートである。

（ステップ１８０１）
ユーザ（管理者）がアプリケーション情報入力画面１３０１（図１４参照）にＨｏｓｔ識別子１３０２と、Ｓｔｏｒａｇｅ識別子１３０３と、ＰｏｏｌＩＤ１３０４と、ＶＶＯＬＩＤ１３０５と、ＶＶＯＬＳＩＺＥ１３０６と、ＶＶＯＬＳＩＺＥ１３０７と、アプリケーション名１３０７と、アプリケーションタイプ１３０８と、予測期間１３０９の情報を入力し、実行１３１０を投下すると、アプリケーション情報取得エンジン８０４が入力された情報を取得する。なお、新規追加アプリケーション、或いは使用態様（使用ボリューム）を変更するアプリケーションの情報が入力され、実行ボタン１３１０が押下されると即時にプール容量予測処理を実行するようにしても良いが、ユーザの指定した期間後にプール容量予測処理を実行するようにしても良い。この場合、割当て予定の仮想ボリュームは、他のユーザが利用できないように予約する必要がある。また、上述のように、アプリケーションは新規追加や変更だけでなく、削除をして削除後のプール容量を予測するようにしても良い。以下、アプリケーションを追加する場合と削除する場合のアプリケーション情報入力（Ｓ１８０１）に付随する処理について説明する。

（i）アプリケーション追加の場合：アプリケーション追加指示に伴う仮想ボリュームの追加
アプリケーション情報の入力画面は図１４に示したとおりである。また、アプリケーションを追加した場合には、マッピングテーブル９０１と、仮想ボリューム容量情報テーブル１００１に情報が追加される。つまり、アプリケーション情報取得エンジン８０４は、アプリケーション追加画面１３０１に入力されたアプリケーション名１３０２とアプリケーションタイプ１３０３とＶＶＯＬＩＤ１３０４から、アプリケーションとボリュームとのマッピングテーブル９０１のアプリケーション名９０２とアプリケーションタイプ９０３とＶＶＯＬＩＤ９０４に該当する行を追加する。

また、ストレージ情報取得エンジン８１０は、ＶＶＯＬＩＤ１３０４とＰＯＯＬＩＤ１３０５から、仮想ボリューム容量情報テーブル１００１のプールＩＤ１００３とＶＶＯＬＩＤ１００４に該当する行を追加する。

そして、管理計算機１０３は、ＶＶＯＬＩＤ１３０４に基づいて、管理用ネットワーク１０６を経由してストレージサブシステム１０２内のストレージ制御プログラム３０７に対して、ＶＶＯＬＩＤ２００４に対応する実領域管理表３０９の割当状況５０４を「割当」に変更するように指示する。より具体的には、当該指示を受けたストレージ制御プログラム３０７は、ＶＶＯＬ管理表３１１のＶＶＯＬＩＤ６０１とＶＶＯＬＩＤ２００４が一致するＶＶＯＬＬＢＡ範囲６０２と実領域ＩＤ６０３を取得し、実領域管理表３０９の実領域ＩＤ５０２とＲＧＬＢＡ範囲５０３がＶＶＯＬＬＢＡ範囲６０２と実領域ＩＤ６０３に一致する割当状況５０４を「割当」に変更する。

（ii）アプリケーション削除の場合：アプリケーション削除に伴う仮想ボリュームの削除
上述したように、アプリケーションの新規追加に加えて、本実施形態では、アプリケーション削除に伴う割当て済み仮想ボリュームの削除も可能である。割当て済み仮想ボリュームを削除することで、対象プールの各Ｔｉｅｒ利用量の精度向上及び無駄な領域の解放が見込まれる。

アプリケーション削除の場合、アプリケーションに割り当てられる仮想ボリュームの削除を実現する。具体的には、図２３に示すようにアプリケーション削除画面２００１を作成し、削除対象のアプリケーション名２００２とアプリケーションタイプ２００３とＶＶＯＬＩＤ２００４とＰＯＯＬＩＤ２００５を入力し、実行２００６を投下する。

アプリケーション情報取得エンジン８０４は、アプリケーション削除画面２００１に入力されたアプリケーション名２００２とアプリケーションタイプ２００３とＶＶＯＬＩＤ２００４から、アプリケーションとボリュームとのマッピングテーブル９０１のアプリケーション名９０２とアプリケーションタイプ９０３とＶＶＯＬＩＤ９０４に該当する行を削除する。

また、ストレージ情報取得エンジン８１０は、ＶＶＯＬＩＤ２００４とＰＯＯＬＩＤ２００５から、仮想ボリューム容量情報テーブル１００１のプールＩＤ１００３とＶＶＯＬＩＤ１００４に該当する行を全て削除する。

そして、管理計算機１０３は、ＶＶＯＬＩＤ２００４に基づいて、管理用ネットワーク１０６を経由してストレージサブシステム１０２内のストレージ制御プログラム３０７に対して、ＶＶＯＬＩＤ２００４に対応する実領域管理表３０９の割当状況５０４を「未割当」に変更するように指示する。より具体的には、当該指示を受けた制御プログラム３０７は、ＶＶＯＬ管理表３１１のＶＶＯＬＩＤ６０１とＶＶＯＬＩＤ２００４が一致するＶＶＯＬＬＢＡ範囲６０２と実領域ＩＤ６０３を取得し、実領域管理表３０９の実領域ＩＤ５０２とＲＧＬＢＡ範囲５０３が前記ＶＶＯＬＬＢＡ範囲６０２と実領域ＩＤ６０３に一致する割当状況５０４を「未割当」に変更する。

（ステップ１６０２）
アプリケーション情報取得エンジン８０４は、アプリケーション情報入力画面１３０１から取得したアプリケーション名１３０７、アプリケーションタイプ１３０８、ＶＶＯＬＩＤ１３０５の情報を記憶装置８１１のデータ格納用ＤＢ８１２内アプリケーションとボリュームとのマッピングテーブル９０１へ格納する。

（ステップ１６０３）
アプリケーション情報取得エンジン８０４は、ステップ１６０１で取得したＶＶＯLＳＩＺＥ１３０６と予測期間１３０９とアプリケーションタイプ１３０８とＰＯＯＬＩＤ１３０４の情報を入力に、プール容量予測エンジン８０５に予測処理実行を指示する。

（ステップ１８０４）
プール容量予測エンジン８０５は、アプリケーションが利用するＶＶＯＬの容量消費傾向の予測に必要な入力パラメータを得るため、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６と既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７を起動する。

プール容量予測エンジン８０５が、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６の起動時に、パラメータとしてＶＶＯLＳＩＺＥ１３０６と予測期間１３０９とアプリケーションタイプ１３０８を渡すことで、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６は、割当て予定のＶＶＯLＳＩＺＥ１３０５に対する予測期間１３０９後の各Ｔｉｅrの容量消費量を取得する。具体的な処理内容に関しては後述する。

また、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７は、割当て予定のＶＶＯＬを構成するプールに対して、ＶＶＯL追加に伴う既存のプールへの影響を予測する。起動時にパラメータとしてＰＯＯＬＩＤ１３０４と予測期間１３０９を受け取ることで、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７は、ＰＯＯＬＩＤ１３０４における予測期間１３０９後のプールの各Ｔｉｅrの予測容量消費量を取得する。具体的な処理内容に関しては後述する。なお、アプリケーションの削除が管理計算機１０３から指示された場合には、上述のように、当該指示に応答して、削除対象のアプリケーションを削除すると共に、対応する仮想ボリュームを「未割当」に変更する。そして、削除対象のアプリケーションを除く他の全ての既存アプリケーションが全体で消費する容量を予測する。なぜなら、アプリケーション削除後はデータが高性能のＴｉｅｒ１等に残っていることがあり、資源の無駄となる可能性があるからである。このため、アプリケーション削除が指示された場合には、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６による予測処理は実行されない。ただし、アプリケーションを一時的に削除（停止）するような場合には、該当する仮想ボリュームにデータを残したまま他の既存アプリケーションの消費容量を予測するようにしても良い。一時的に停止したアプリケーションを復活させた場合には、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６による処理を実行し、復活させて指定期間経過した後の消費容量を予測するようにしても良い。

プール容量予測エンジン８０５は、各予測エンジン８０６及び８０７から得た結果を合計し、プール容量予測テーブル１１０１に格納する。具体的には、プール容量予測エンジン８０５は、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７で算出した予測期間１３０９後のプールの各Ｔｉｅrの予測容量消費量に、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６で予測した結果を加算し、算出結果を１ヶ月後の容量消費量１１０５に格納する。また、プール容量予測エンジン８０５は、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７のステップ２２１２で算出した現時点でのプールの各Ｔｉｅrの容量消費量を現在の容量消費量１１０４に格納する。また、プール容量予測エンジン８０５は、割り当てるＶＶＯLのＶＶＯＬＳＩＺＥ１３０６をＶＶＯＬ容量１１０３に格納する。

（ステップ１８０５）
プール容量予測エンジン８０５は、結果表示エンジン８０８を起動する。結果表示エンジン８０８は、プール容量予測テーブル１１０１のデータをプール容量予測結果レポート画面１３０１に出力する。

なお、Ｔｉｅｒ購入時に発生するＴｉｅｒ毎の金額をレポートするようにしても良い。この場合、プール容量予測エンジン８０５と結果表示エンジン８０８を拡充することで、容量消費量の予測と共に、各Ｔｉｅｒの購入に必要な金額をレポートすることが可能となる。

図２４に示されるように、各Ｔｉｅｒのコストを設定するために、Ｔｉｅｒ毎の課金設定画面２１０１が作成される。Ｔｉｅｒ毎の課金設定画面２１０１では、Ｔｉｅｒ毎のコスト入力２１０２〜２１０４を行い、実行２１０５が押下される。

そして、この場合、プール容量予測エンジン８０５は、Ｔｉｅｒ毎の課金設定画面２１０１で入力した情報をＴｉｅｒ毎の課金管理テーブル２２０１（図２５参照）に格納する。具体的には、プール容量予測エンジン８０５は、Ｔｉｅｒ毎のコスト入力２１０２〜２１０４をＴｉｅｒ毎の課金管理テーブル２２０１に格納する。データを算出する場合、プール容量予測エンジン８０５は、ステップ１８０４の処理を実行した後、プール容量予測テーブル１１０１の一カ月後の容量消費量１１０５から各Ｔｉｅｒのデータを取得し、Tier毎の課金管理テーブル ２２０１のＣｏｓｔ２２０３のデータと掛け合わせた値をプール容量予測テーブル １１０１に格納する。

続いて、プール容量予測エンジン８０５は、ステップ１８０５で結果表示エンジン８０８がプール容量予測テーブル１１０１のデータをプール容量予測結果レポート画面２３０１に出力する。この場合の画面描画結果は図２６に示されるように表示される。図２６と図１６との差異は、予測コスト２３０２が表示されることである。なお、ここでは、容量が足りない場合にデバイス購入に掛かるコストを表示しているが、消費容量で課金するシステムの場合には、消費容量によるコストを表示するようにしても良い。

＜新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６の処理の詳細＞
図１９は、アプリケーション追加時における、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン（以下、「新規割当て量予測エンジン」ということもある）８０６の処理の詳細を説明するためのフローチャートである。

(ステップ１９０１)
割当て予定のＶＶＯＬと類似する使用傾向が見られるＶＶＯLを検索するため、新規割当て量予測エンジン８０６は、割当て予定のＶＶＯLのアプリケーションタイプから、ＶＶＯＬ ＩＤ９０４をアプリケーションとボリュームとのマッピングテーブル９０１より取得する。つまり、追加するアプリケーションのタイプと類似する既存のアプリケーションが特定される。ここで、「類似」とは、「同一」も含む概念である。例えば、追加されるアプリケーションが、検索エンジンである場合には、同一の検索エンジンが既にあればそれが選択されるが、同一ではないが他の検索エンジンがあればそれが選択される。複数の類似タイプのアプリケーションがある場合には、何れか１つのアプリケーションを選択してその導入当初の動向を用いて予測するようにしても良いし、複数のアプリケーションを選択し、それらの導入当初の動向を平均するようにしても良い。

（ステップ１９０２）
新規割当て量予測エンジン８０６は、ステップ１９０１で取得した類似使用用途のＶＶＯLＩＤ９０４の一覧全てに対してステップ１９０３ないし１９０６の処理を実行する。一覧全てに対して処理が実行された場合は、処理はステップ１９０７に移行する。

（ステップ１９０３）
新規割当て量予測エンジン８０６は、仮想ボリューム容量情報テーブル１００１から、現在対象とする類似使用用途のＶＶＯLについて収集を開始した最も古い時刻を運用開始時刻として仮定する。なお、仮想ボリューム容量情報テーブル１００１において、最新時刻から遡った所定期間の情報を用いるのでなければ、運用開始時刻は任意に設定することができる。当該類似タイプのアプリケーションの導入当初の使用状況が追加された新規のアプリケーション等の運用予定と比べてあまりにも特異な場合には、類似のアプリケーションの使用状態が安定している時期を選択して予測処理に用いるようにしても良い。

（ステップ１９０４）
新規割当て量予測エンジン８０６は、ステップ１９０３で取得した時刻（運用開始時刻）からユーザが指定した予測したい期間（例えば、１ヶ月）までのデータを、仮想ボリューム容量情報テーブル１００１から取得する。

（ステップ１９０５）
新規割当て量予測エンジン８０６は、ステップ１９０４の実行結果１件ずつに対して、Ｔｉｅｒ０利用量１００６÷ＶＶＯL容量１００５、Ｔｉｅｒ１利用量１００７÷ＶＶＯL容量１００５、Ｔｉｅｒ２利用量１００８÷ＶＶＯL容量１００５を実行し、各Ｔｉｅrについて、ＶＶＯＬの割当て容量に対する消費比率を算出する。

（ステップ１９０６）
新規割当て量予測エンジン８０６は、類似するアプリケーションの中においてステップ１９０５で算出した各ＴｉｅrのＶＶＯＬ割当て容量に対する消費比率が、最大となる値を安全係数として見積もるために、現在の中で最大の値が算出されれば、予測値の候補として、Ｔｉｅｒの利用量１００６〜１００８と、ＶＶＯL容量１００５の組として保持する。即ち、ステップ１９０６では、最終的に、運用開始時刻からの指定期間内における容量消費量が最大のＴｉｅｒ利用量とＶＶＯＬ容量を見つけ出す処理が行われている。

（ステップ１９０７）
新規割当て量予測エンジン８０６は、対象とする類似用途のＶＶＯL全てについて検証後、候補の組について、各Ｔｉｅrについて、ＶＶＯＬの割当て容量に対する消費比率を算出する。この処理は、最大値を取る候補の組み合わせ（Ｔｉｅｒ利用量１００６とＶＶＯＬ容量１００５）に対して、ステップ１９０５と同等の演算を実行するものである。演算結果が保持されていれば、再度同じ演算を行う必要はないが、ここでは保持されない場合を想定している。

（ステップ１９０８）
新規割当て量予測エンジン８０６は、ステップ１９０７で算出した値とユーザの指定する新規割当て予定のＶＶＯLを乗算する。このようにすることで、ユーザの指定したＶＶＯＬに対する指定期間後の各Ｔｉｅrの予測容量消費量が算出できる。

（ステップ１９０９）
新規割当て量予測エンジン８０６は、ステップ１９０８で算出した値を追加されたアプリケーションによって消費されるプール容量の予測値として、プール容量予測エンジン８０５に返す。

＜既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７の処理の詳細＞
図２０は、既存ＶＯＬへのＰａｇｅ割当て量予測エンジン８０７の処理概要について説明するためのフローチャートである。既存ＶＯＬへのＰａｇｅ割当て量予測エンジン（以下、「既存割当て予測エンジン」ということもある）８０７は、プールの各Ｔｉｅｒの予測容量消費量算出処理（ステップ２００１）によって算出された値と、プールの各Ｔｉｅrの容量消費量算出処理（ステップ２００２）によって算出された値を、プール容量予測エンジン８０５に返す。以下、ステップ２００１及び２００２の詳細について説明する。

（i）プールの各Ｔｉｅｒの予測容量消費量算出処理（Ｓ２００１）の詳細
図２１は、プールの各Ｔｉｅｒの予測容量消費量算出処理（ステップ２００１）の詳細を説明するためのフローチャートである。

（ステップ２１０１）
既存割当て予測エンジン８０７は、アプリケーション情報入力画面１３０１から入力されたＰＯＯＬＩＤ１３０４の全ＶＶＯL一覧を取得する。この取得したＶＶＯＬに対してＳ２１０３からＳ２１０５の処理が実行される。

（ステップ２１０２）
既存割当て予測エンジン８０７は、ステップ２１０１で取得したＶＶＯＬＩＤ１００４の全てに対して処理（Ｓ２１０３乃至Ｓ２１０５）を実行したか否か判断する。処理が完了していれば、処理はステップ２１０６に移行する。

（ステップ２１０３）
既存割当て予測エンジン８０７は、ＶＶＯＬ毎に履歴データを取得する。ここでは、過去全てのデータを取得するようにするが、ユーザ（管理者）によって取得すべきデータの範囲（期間）が指定され、その指定期間中のデータを用いるようにしても良いし、固定期間のデータを用いるようにしても良い。

（ステップ２１０４）
既存割当て予測エンジン８０７は、ステップ２１０３で取得したデータに対して収集時間１００２毎に各Ｔｉｅｒの利用量の最尤推定（例えば、最小二乗法等を用いる）を行い、ＶＶＯＬの各Ｔｉｅrの利用量の増加傾向を示す関係式を算出する。

（ステップ１８０８）
既存割当て予測エンジン８０７は、ステップ２１０４で算出した関係式に対してアプリケーション情報入力画面１３０１で入力したユーザの指定した予測期間１３０９を乗算することでＶＶＯＬの各Ｔｉｅrの容量消費量の予測を算出する。つまり、過去の統計的データに基づいて、指定期間経過後の容量消費量を予測する。

（ステップ１８０９）
既存割当て予測エンジン８０７は、ステップ２１０５で算出したＶＶＯＬ毎の各Ｔｉｅrの容量消費量の予測値を合算し、プールの各Ｔｉｅrの予測容量消費量を算出する。

（ii）プールの各Ｔｉｅrの容量消費量算出処理（Ｓ２００２）の詳細
図２２は、プールの各Ｔｉｅrの容量消費量算出処理（ステップ２００２）の詳細を説明するためのフローチャートである。

（ステップ２２０１）
既存割当て予測エンジン８０７は、ステップ２１０１で取得したＶＶＯＬＩＤ１００４の全てに対して、ステップ２２０２の処理が完了したか否か判断する。Ｓ２２０２の処理が完了していれば、処理はステップ２２０３に移行する。

（ステップ２２０２）
既存割当て予測エンジン８０７は、現時点でのＶＶＯＬの各Ｔｉｅrの消費量を取得する。厳密な意味での現時点のデータがなければ、最新のデータでも良い。

（ステップ１８１２）
既存割当て予測エンジン８０７は、ステップ２２０２で算出したＶＶＯＬ毎の各Ｔｉｅrの容量消費量（現時点の容量）を合算し、プールの各Ｔｉｅrの容量消費量を算出する。

＜変形例＞
（i）アプリケーションの特性変更に伴うボリューム消費量の再予測
上記実施形態では、主にアプリケーション追加に伴う新規仮想ボリュームの割当てを想定しているが、本発明を拡充し既存アプリケーションの特性変化に応じた容量消費量の再予測も可能である。ここで「特性変更」とは、例えば、当初ＯＬＴＰに割り当てられた仮想ボリューム（ＶＶＯＬ）が別のアプリケーションに割り当てられたような場合等、一度アプリケーションに割り当てた仮想ボリュームの利用態様が変わる場合を意味する。

また、別の「特性変更」の例として、アプリケーションによっては、運用するにつれてその特性が変化する場合も考えられる。より具体的には、ある業務アプリケーションは通常アクセス量は少ないが、年度末や期末等といった特定の期間においてアクセス量が増え、ＯＬＴＰに近いアクセス量が発生するなどといった特性を持つ場合がある。

本発明をこのようなケースに適用し、アプリケーション特性の変化を考慮した反復的な容量予測を実行することが可能である。具体的にはステップ１８０１（図１８）を実行する際、ユーザ（管理者）が、アプリケーションタイプ１３０８（図１４）を変更し、割当たっている仮想ボリュームの残容量をＶＶＯＬＳＩＺＥ１３０７に入力した上で、ステップ１８０２と同様の情報をアプリケーション情報入力画面１３０１に入力し、実行１３１０を投下する。以降は本実施形態における管理計算機１０３が実行する処理と同じの処理が実行される。このように、既存のアプリケーションの特性を変更したときにも、上述のアプリケーションの新規追加の処理を適用することができる。これにより、アプリケーションの特性が変更した後の容量消費量が予測可能となる。

（ii）ＬＶＭ環境に対するボリューム消費量の予測
アプリケーションによっては、サーバ上のＯＳが提供するＬＶＭ（Logical Volume Manager）機能等を利用して、各割当論理ボリュームをグルーピングし、１つの仮想ボリュームとしてアプリケーションに見せて割り当てる環境も存在する。このような環境において、本発明の思想を適用（拡張）し、アプリケーションに割り当てられている個々の論理ボリュームの容量消費量の総和から将来の消費量を予測することでＬＶＭ環境の容量消費量を予測できるようになる。つまり、ＬＶＭ機能においては、１つのグループ（複数のＶＶＯＬで構成される）をアプリケーションに割り当てているが、その１つのグループの容量消費予測は、それぞれの構成ＶＶＯＬの容量消費予測を合算して表すことが可能である。ＬＶＭ機能を実現する環境では、アプリケーションに割り当てられているボリュームは、異なるプールから切り出されたＶＶＯＬである可能性もある。そこで、このような場合にグループ全体の消費容量を予測するには、１つのプールだけからではなく、それぞれの該当プールからも容量を予測する必要があるのである。そして、この環境に本発明を適用するためには、以下のように、情報入力画面とステップ１９０８の処理を拡張する必要がある。

まず、情報入力画面については、アプリケーションに割当たっている個々の仮想ボリュームの情報を入力可能とするため、アプリケーション情報入力画面１３０１のＶＶＯＬＩＤ１３０５と、ＶＶＯＬＳＩＺＥ１３０７に複数のボリュームの情報が入力できるようにリストを追加する。その上で、ユーザ（管理者）が、ＬＶＭを構成する全ての仮想ボリュームの情報を入力する。

また、新規ＶＯＬへのＰａｇｅ割当て量予測エンジン８０６は、Ｓ１９０８において、割り当て予定のＶＶＯL容量に関して、ＬＶＭを構成する全ての仮想ボリューム容量の総和に変更する。より具体的には、Ｓ１９０８を“ステップ１９０７で算出した各Ｔｉｅrの比率×アプリケーション情報入力画面１３０１のＶＶＯＬＳＩＺＥ１３０７に入力した各ＶＶＯL値の総和”とする。

以降は本実施形態における管理計算機１０３が実行する処理と同じの処理を実行すれば良い。

＜まとめ＞
本実施形態では、新規にアプリケーションの追加が指示された場合、或いは、既存のプリケーションが使用する仮想ボリュームの割り当ての変更が指示された場合、当該指示に応答して、新規のアプリケーション、或いは割り当て変更対象のアプリケーションと、アプリケーション種別が同一或いは類似のアプリケーションが使用する仮想ボリュームの過去の消費容量動向（例えば、アプリケーション導入当初から所定期間内における消費容量の傾向）に関する情報を取得する。そして、取得した消費容量動向に関する情報に基づいて、割当て予定の仮想ボリュームおける消費容量を予測する。このようにすることにより、アプリケーションの追加又はボリュームの割り当て変更に伴う容量（例えば、プールに割り当てられている容量）の枯渇タイミングを把握することができるようになる。アプリケーション導入当初からの消費容量傾向の情報を取得するのは、追加或いは割り当て変更に伴う消費容量の傾向をより正確に把握することができるからである。

また、ストレージサブシステムでは、１つ以上の物理記憶デバイスが階層を構成している。また、仮想ボリュームは、１つ以上の階層を用いて構成され、かつ、ホスト計算機が直接アクセスするターゲットと関連付けられたプールと対応付けられている。仮想ボリュームについては、各階層ごとに消費容量（利用量）が管理されている（図１１参照）。そして、割当て予定の仮想ボリュームにおける消費容量を予測する際には、当該仮想ボリュームを構成する１つ以上の階層における割り当て領域の過去の利用量に関する情報が用いられる。このようにすることにより、異なる物理特性のディスクの組み合わせでプールを構成する場合に、より正確にプールの消費容量枯渇のタイミングを把握することができるようになる。つまり、Thin Provisioningを拡張して運用する場合にも対応することができるようになる。

さらに、上記新規に追加されるアプリケーション等以外の、全ての既存のアプリケーション（仮想ボリュームの割り当て状況に変化がないもの）が使用する仮想ボリュームにおける過去の消費容量に関するデータを取得する。そして、このデータに基づいて、最尤推定法（例えば、最小二乗法）を用いて、これら全ての既存のアプリケーションが使用する仮想ボリュームにおける、指定予測期間後の消費容量を予測する。この既存アプリケーションの予測消費容量と、上記新規追加アプリケーション等に割当て予定の仮想ボリュームにおける予測消費容量とを合算して出力（表示やプリントアウト）する。このようにすることにより、既存のアプリケーションの消費容量の動向をも加味して、システム全体の消費容量の予測情報を提示することができ、ユーザ（管理者）は物理記憶デバイスの追加のタイミングを知ることができるようになる。

また、予測消費容量を提示すると共に、将来に掛かるコストを提示する。これにより、ユーザ（管理者）はコスト面を考慮しつつ、システムを効率よく運用することが可能となる。

アプリケーション削除に伴う仮想ボリュームの削除が指示された場合には、削除対象のアプリケーションを除いて全体の予測消費容量を演算する。この場合には、既存ＶＯＬへのＰａｇｅ割当て予測エンジン８０７を用いて消費容量を予測する。このようにすることにより、アプリケーション削除に伴う容量確保がどの程度効果があるか見極めることができる。また、アプリケーション削除後はデータが高性能のＴｉｅｒ１等に残っていると資源の無駄となるが、このような事態を回避することができる。

なお、本発明は、実施形態そのままに限定されるものではなく、実施段階では、その要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、実施形態で示された各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能等を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録或いは記憶装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録或いは記憶媒体に格納することができる。

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

１００ 計算機システム
１０１ ホスト計算機
１０２ ストレージサブシステム
１０３ 管理計算機
１０４ Ｗｅｂブラウズ用計算機
１０５ ストレージエリアネットワーク
１０６ 管理用ネットワーク
１０７ 管理システム

Claims (13)

1. １つ以上の物理記憶デバイスを有するストレージサブシステムと、前記ストレージサブシステムを管理する管理システムと、を有し、
   前記ストレージサブシステムは、前記物理記憶デバイスの記憶領域を、仮想ボリュームとしてホスト計算機に提供し、
   前記管理システムは、アプリケーションが使用すべき前記仮想ボリュームの割り当てについての入力指示に応答して、前記アプリケーションとアプリケーション種別が同一或いは類似のアプリケーションが使用する仮想ボリュームの過去の消費容量動向に関する情報を取得し、当該消費容量動向に関する情報に基づいて、前記割当て予定の仮想ボリュームにおける消費容量を予測し、
   前記入力指示は、新規にアプリケーションの追加の指示、或いは、既存のアプリケーションに割り当てられる前記仮想ボリュームに変更の指示を含むことを特徴とする計算機システム。
2. 請求項１において、
   前記管理システムは、前記新規追加のアプリケーションと同一又は類似のタイプのアプリケーション、或いは前記仮想ボリューム割り当て変更の既存アプリケーションの運用開始から所定期間における前記消費容量動向に関する情報を取得し、前記割当て予定の仮想ボリュームにおける消費容量を予測することを特徴とする計算機システム。
3. 請求項２において、
   前記１つ以上の物理記憶デバイスは、１つ以上の階層を構成し、
   前記仮想ボリュームは、前記１つ以上の階層を用いて構成され、かつ、前記ホスト計算機が直接アクセスするターゲットと関連付けられたプールと対応付けられ、
   前記管理システムは、前記割当て予定の仮想ボリュームにおける消費容量を予測する際に、当該仮想ボリュームを構成する前記１つ以上の階層における割当て領域の過去の利用量に関する情報を用いることを特徴とする計算機システム。
4. 請求項３において、
   前記管理システムは、さらに、前記仮想ボリュームの割り当てが不変の全ての既存のアプリケーションが使用する前記仮想ボリュームにおける過去の消費容量に関する情報を取得し、当該全ての既存のアプリケーションが使用する前記仮想ボリュームにおける消費容量であって、指定された予測期間後の消費容量を予測し、前記割当て予定の仮想ボリュームにおける予測消費容量と前記既存アプリケーションの予測消費容量を併せて出力することを特徴とする計算機システム。
5. 請求項４において、
   前記管理システムは、前記１つ以上の階層のコストに関するコスト設定情報、及び前記割当て予定の仮想ボリュームにおける予測消費容量と前記既存アプリケーションの予測消費容量に基づいて、前記１つ以上の階層における予測コストを出力することを特徴とする計算機システム。
6. 請求項１において、
   前記管理システムは、アプリケーションの削除と当該削除対象のアプリケーションに割り当てられた前記仮想ボリュームの削除についての入力指示に応答して、当該削除対象のアプリケーションが使用する前記仮想ボリュームの割り当てを解放し、前記削除対象のアプリケーションを除く全ての既存のアプリケーションが使用する前記仮想ボリュームにおける過去の消費容量に関する情報を取得し、前記削除対象のアプリケーションを除く全ての既存のアプリケーションが使用する前記仮想ボリュームにおける消費容量であって、指定された予測期間後の消費容量を予測し、当該予測消費量を出力することを特徴とする計算機システム。
7. １つ以上の物理記憶デバイスの記憶領域を仮想ボリュームとしてホスト計算機に提供するストレージサブシステムと、前記ストレージサブシステムを管理する管理システムと、を有する計算機システムの管理方法であって、
   前記管理システムのプロセッサが、アプリケーションが使用すべき前記仮想ボリュームの割り当てについて指示された場合、前記アプリケーションとアプリケーション種別が同一或いは類似のアプリケーションが使用する仮想ボリュームの過去の消費容量動向に関する情報を取得する工程と、
   前記プロセッサが、前記消費容量動向に関する情報に基づいて、前記割当て予定の仮想ボリュームにおける消費容量を予測する工程と、を有し、
   前記指示は、新規にアプリケーションの追加の指示、或いは、既存のアプリケーションに割り当てられる前記仮想ボリュームに変更の指示を含むことを特徴とする管理方法。
8. 請求項７において、
   前記プロセッサは、前記新規追加のアプリケーションと同一又は類似のタイプのアプリケーション、或いは前記仮想ボリューム割り当て変更の既存アプリケーションの運用開始から所定期間における前記消費容量動向に関する情報を取得し、前記割当て予定の仮想ボリュームにおける消費容量を予測することを特徴とする管理方法。
9. 請求項８において、
   前記１つ以上の物理記憶デバイスは、１つ以上の階層を構成し、
   前記仮想ボリュームは、前記１つ以上の階層を用いて構成され、かつ、前記ホスト計算機が直接アクセスするターゲットと関連付けられたプールと対応付けられ、
   前記プロセッサは、前記割当て予定の仮想ボリュームにおける消費容量を予測する際に、当該仮想ボリュームを構成する前記１つ以上の階層における割当て領域の過去の利用量に関する情報を用いることを特徴とする管理方法。
10. 請求項９において、
    さらに、前記プロセッサが、前記仮想ボリュームの割り当てが不変の全ての既存のアプリケーションが使用する前記仮想ボリュームにおける過去の消費容量に関する情報を取得する工程と、
    前記プロセッサが、当該全ての既存のアプリケーションが使用する前記仮想ボリュームにおける消費容量であって、指定された予測期間後の消費容量を予測し、前記割当て予定の仮想ボリュームにおける予測消費容量と前記既存アプリケーションの予測消費容量を併せて出力する工程と、
    を有することを特徴とする管理方法。
11. 請求項１０において、
    さらに、前記プロセッサが、前記１つ以上の階層のコストに関するコスト設定情報、及び前記割当て予定の仮想ボリュームにおける予測消費容量と前記既存アプリケーションの予測消費容量に基づいて、前記１つ以上の階層における予測コストを出力する工程を有することを特徴とする管理方法。
12. 請求項７において、
    さらに、前記プロセッサが、アプリケーションの削除と当該削除対象のアプリケーションに割り当てられた前記仮想ボリュームの削除について指示された場合、当該削除対象のアプリケーションが使用する前記仮想ボリュームの割り当てを解放する工程と、
    前記プロセッサが、前記削除対象のアプリケーションを除く全ての既存のアプリケーションが使用する前記仮想ボリュームにおける過去の消費容量に関する情報を取得する工程と、
    前記プロセッサが、前記削除対象のアプリケーションを除く全ての既存のアプリケーションが使用する前記仮想ボリュームにおける消費容量であって、指定された予測期間後の消費容量を予測する工程と、
    前記プロセッサが、前記予測消費量を出力する工程と、
    を有することを特徴とする管理方法。
13. １つ以上の物理記憶デバイスの記憶領域を仮想ボリュームとしてホスト計算機に提供するストレージサブシステムと、前記ストレージサブシステムを管理する管理システムと、
    を有する計算機システムにおいて、前記管理システムのプロセッサに、
    アプリケーションが使用すべき前記仮想ボリュームの割り当てについての入力指示であって、新規にアプリケーションの追加の指示、或いは、既存のアプリケーションに割り当てられる前記仮想ボリュームに変更の指示を含む入力指示に応答して、前記アプリケーションとアプリケーション種別が同一或いは類似のアプリケーションが使用する仮想ボリュームの過去の消費容量動向に関する情報を取得する処理と、
    前記消費容量動向に関する情報に基づいて、前記割当て予定の仮想ボリュームにおける消費容量を予測する処理と、
    を実行させるためのプログラム。

Images