(57)【要約】  ホスト装置に接続されたストレージ装置が、複数の仮想領域で構成された仮想的な論理ボリュームである仮想ボリュームと、性能が異なる複数の実領域群で構成されたプールとを有する。コントローラは、どの仮想領域にどの実領域が割り当てられているかと仮想領域に関するアクセス負荷とを表す情報であるプール状況情報を管理する。ストレージ装置の管理システムが、現在から過去における複数の時点での前記プール状況情報と、１以上のアクセス負荷閾値とに基づいて、将来の時点での実領域群毎の使用容量を予測し、予測された使用容量と現在の記憶容量との差分である増設／減設量を実領域群毎に計算し、その計算の結果に基づく処理を実行する。
2011092739.tif 000002
【特許請求の範囲】
【請求項１】
ホスト装置に接続されたストレージ装置の管理システムであって、
前記ストレージ装置が、
複数の仮想領域で構成された仮想的な論理ボリュームである仮想ボリュームと、
性能が異なる複数の実領域群で構成されたプールと、
前記ホスト装置からのアクセスコマンドに応答して、そのアクセスコマンドから特定された仮想領域に割り当てられた実領域にアクセスするコントローラと
を有し、
前記コントローラは、どの仮想領域にどの実領域が割り当てられているかと仮想領域に関するアクセス負荷とを表す情報であるプール状況情報を管理し、
前記管理システムが、
記憶資源と、
前記記憶資源に接続されたプロセッサと
を有し、
前記記憶資源が、各実領域群の現在の記憶容量を表す情報である容量管理情報を記憶し、
前記プロセッサが、
（Ａ）現在から過去における複数の時点での前記プール状況情報と、１以上のアクセス負荷閾値とに基づいて、将来の時点での実領域群毎の使用容量を予測し、
（Ｂ）予測された使用容量と前記容量管理情報が表す現在の記憶容量との差分である増設／減設量を実領域群毎に計算し、
（Ｃ）前記（Ｂ）の計算の結果に基づく処理を実行する、
管理システム。
【請求項２】
請求項１記載の管理システムであって、
前記１以上のアクセス負荷閾値の各々を上限又は下限とした複数のアクセス負荷範囲に前記複数の実領域群が対応し、
前記プロセッサが、前記（Ａ）において、
（ａ０１）前記複数の時点での前記プール状況情報を基に、将来の時点での、アクセス負荷と実領域数との分布を予測し、
（ａ０２）前記複数のアクセス負荷範囲を基に想定される、前記プールに関する第１種の値が、所定の条件を満足するような、１以上のアクセス負荷閾値の１以上の組合せを、特定し、
（ａ０３）前記１以上の組合せのうち、前記プールに関する第２種の値が最も優れた値となる組合せを特定し、
（ａ０４）前記（ａ０３）で特定された組合せから一義的に定まる前記複数のアクセス負荷範囲と、前記（ａ０１）で特定された分布とを基に、前記将来の時点での実領域群毎の使用容量を予測する、
管理システム。
【請求項３】
請求項２記載の管理システムであって、
前記第１種の値は、前記プールの性能と、前記プールに記憶容量を増設する際のコストである増設コストとのうちの一方であり、
前記第２種の値は、前記プールの性能と前記プールの増設コストとのうちの他方である、
管理システム。
【請求項４】
請求項３記載の管理システムであって、
前記プロセッサは、前記（Ｃ）において、下記の（ｃ０１）又は（ｃ０２）を表示する、
（ｃ０１）前記（Ｂ）で算出された、実領域群毎の増設／減設量、
（ｃ０２）前記プールの性能、及び／又は、前記プールの増設コスト、
管理システム。
【請求項５】
請求項４記載の管理システムであって、
前記（Ｃ）での表示では、実領域群毎の増設／減設量の組合せが、前記プールの性能又は前記プールの増設コストの順で並んでいる、
管理システム。
【請求項６】
請求項３記載の管理システムであって、
前記プールの想定される性能は、前記複数の実領域群に対応した複数のアクセス期待時間と、前記分布とに基づいて算出され、
前記アクセス期待時間は、実領域に対するアクセスにかかると期待される時間長である、
管理システム。
【請求項７】
請求項３記載の管理システムであって、
前記コストは、費用又は消費電力である、
管理システム。
【請求項８】
請求項１記載の管理システムであって、
前記プロセッサが、前記（Ａ）において、
（ａ１１）各時点で、前記プール状況情報と１以上のアクセス負荷閾値とに基づいて、仮想領域に割り当てられている実領域の総記憶容量である使用容量を各実領域群について算出し、時点を表す情報と実領域群毎の使用容量を表す情報とを前記記憶資源に書込み、それにより、前記複数の時点での実領域群毎の使用容量を表す履歴情報が前記記憶資源に蓄積され、
（ａ１２）前記履歴情報を基に、将来の時点での実領域群毎の使用容量を予測する、
管理システム。
【請求項９】
請求項８記載の管理システムであって、
各実領域群にアクセス負荷範囲が対応しており、
前記コントローラは、第１の実領域群における第１の実領域内のデータを、前記第１の実領域のアクセス負荷が属するアクセス負荷範囲に対応した第２の実領域群における第２の実領域にマイグレーションし、前記第１の実領域が割り当てられた仮想領域に、前記第１の実領域に代えて前記第２の実領域を割り当て、
前記１以上のアクセス負荷閾値は、前記複数の実領域群に対応した複数のアクセス負荷範囲のうちの少なくとも１つのアクセス負荷範囲の上限及び／又は下限である、
管理システム。
【請求項１０】
請求項１記載の管理システムであって、
前記プロセッサは、所定のイベントが発生したときにだけ、前記将来の時点での実領域群毎の使用容量の予測を行う、
管理システム。
【請求項１１】
請求項１０記載の管理システムであって、
前記所定のイベントは、前記プールの使用容量が所定の閾値を超えたことである、
管理システム。
【請求項１２】
請求項１０記載の管理システムであって、
前記所定のイベントは、前記プールの性能が目標性能を下回ったことである、
管理システム。
【請求項１３】
請求項１記載の管理システムであって、
前記プロセッサが、前記プールに対して記憶容量の増設及び／又は減設が実施された後、
（Ｄ）前記プール状況情報を基に算出される、前記プールの性能が、目標性能を下回ったか否かを判断し、
（Ｅ）前記（Ｄ）の判断の結果が肯定的の場合、前記プールの性能と前記目標性能との差分の大きさに基づいて、前記プールの性能が前記目標性能を下回った原因を表す情報を表示する、
管理システム。
【請求項１４】
請求項１記載の管理システムであって、
前記プロセッサが、前記（Ｃ）において、以下の（ｃ１１）又は（ｃ１２）を行う、
（ｃ１１）或る実領域群について増設量が算出されている場合、自動で、総記憶容量が前記増設量以上である、前記或る実領域群と同じ性能の１以上の実領域を増設する、
（ｃ１２）或る実領域群について減設量が算出されている場合、自動で、前記或る実領域群から、総記憶容量が前記減設量以下である１以上の実領域を減設する、
管理システム。
【請求項１５】
ホスト装置に接続されたストレージ装置の管理方法であって、
前記ストレージ装置が、
複数の仮想領域で構成された仮想的な論理ボリュームである仮想ボリュームと、
性能が異なる複数の実領域群で構成されたプールと、
前記ホスト装置からのアクセスコマンドに応答して、そのアクセスコマンドから特定された仮想領域に割り当てられた実領域にアクセスするコントローラと
を有し、
前記コントローラは、どの仮想領域にどの実領域が割り当てられているかと仮想領域に関するアクセス負荷とを表す情報であるプール状況情報を管理し、
前記管理方法が、
（Ａ）現在から過去における複数の時点での前記プール状況情報と、１以上のアクセス負荷閾値とに基づいて、将来の時点での実領域群毎の使用容量を予測し、
（Ｂ）予測された使用容量と現在の記憶容量との差分である増設／減設量を実領域群毎に計算し、
（Ｃ）前記（Ｂ）の計算の結果に基づく処理を実行する、
管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ装置の管理に関する。
【背景技術】
【０００２】
複数の物理記憶デバイスを有するストレージ装置が知られている。物理記憶デバイスとしては、ハードディスクドライブ、フラッシュメモリデバイスなどがある。ストレージ装置は、一般に、ＲＡＩＤ（Redundant Array of Independent （or Inexpensive） Disks）の技術に従うＲＡＩＤグループを有する。ＲＡＩＤグループは、複数の物理記憶デバイスで構成されており、ＲＡＩＤグループには、所定のＲＡＩＤレベルに従ってデータが格納される。ＲＡＩＤグループの記憶空間を基に、１又は複数の論理的な記憶デバイス（論理ボリューム）が作成される。論理ボリュームは、ストレージ装置に接続されたホスト計算機に提供される。ホスト計算機は、提供された論理ボリュームを指定したアクセスコマンド（例えば、ライトコマンド又はリードコマンド）をストレージ装置に送信する。これにより、その論理ボリュームに対して、データのアクセスが行われる。【０００３】
ストレージ装置として、シンプロビジョニング（Thin Provisioning）技術が適用されたストレージ装置が知られている（例えば、特許文献１）。シンプロビジョニング（ダイナミックプロビジョニングと呼ばれることもある）によれば、記憶容量が固定された論理ボリュームに代えて、仮想的な論理ボリュームである仮想ボリューム（以下、ＶＶＯＬ）と言う）がホスト計算機に提供される。ＶＶＯＬは、複数の仮想領域（仮想的な記憶領域）の集合である。ホスト計算機からＶＶＯＬに対する書込みが発生した場合、仮想領域にプールからセグメントが割り当てられる。このため、シンプロビジョニングによれば、ホスト計算機に提供される記憶容量を動的に拡張することができる。なお、プールは、複数のセグメントで構成された記憶領域である。セグメントは、実領域（実体的な記憶領域）であり、具体的には、例えば、プールを構成する論理ボリューム（以下、ＰＶＯＬ）をＬＢＡ（Logical
Block Address）等によって分割することにより得られた記憶領域である。ここで、「ＬＢＡ」とは、ホスト計算機がストレージ装置との間でデータを読み書きする場合に、論理ボリューム上の位置を指定するために用いるアドレスである。【０００４】
また、性能の異なる複数のセグメント群が混在するプールが知られている（特許文献２）。以下、１つのセグメント群を「メディア」と呼称する。例えば、高性能のメディアは、高性能のＰＶＯＬで構成されており、低性能のメディアは、低性能のＰＶＯＬで構成されている。ＰＶＯＬの性能は、そのＰＶＯＬの基になっている物理記憶デバイスの性能（及び／又は、ＲＡＩＤグループのＲＡＩＤレベル）に依存する。或るメディア内の或るセグメントから別のメディア内のセグメントへのデータマイグレーション（以下、セグメントマイグレーション）を行うことができる。【０００５】
プールを運用する上では、未だＶＶＯＬに割り当てられていないセグメントが不足した場合に、プールの記憶容量を増やすことが必要となる。追加する記憶容量を決定する方法が、例えば特許文献３に開示されている。特許文献３によれば、仮想ボリュームに割り当てられるセグメントの増加率を基に、将来不足する記憶容量が予測され、予測の結果を基に、追加する記憶容量が決定される。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−０１５９１５号公報
【特許文献２】特開２００７−０６６２５９号公報
【特許文献３】特開２００８−０９７５０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
性能が異なる複数のメディアが混在するプールにおいて、記憶容量（例えばＰＶＯＬ）の追加（以下の説明において「増設」と言う）を行う際、増設する記憶容量（以下、「増設量」）を決定する必要がある。特許文献３によれば、プール全体の増設量を決定することができるが、どのメディアにどれだけの記憶容量を増設するかを適切に決定することはできない。このため、必要以上に性能がアップされてしまう増設、または、性能を大きく低下させる増設が行われる可能性がある。【０００８】
以上の問題は、記憶容量の除去（以下、減設）についても生じ得る。【０００９】
そこで、本発明の目的は、性能が異なる複数の実領域群で構成されたプールについて、適切な増設／減設量を実領域群毎に求められるようにすることにある。
【課題を解決するための手段】
【００１０】
ホスト装置に接続されたストレージ装置が、複数の仮想領域で構成された仮想的な論理ボリュームである仮想ボリュームと、性能が異なる複数の実領域群で構成されたプールと、ホスト装置からのアクセスコマンドに応答して、そのアクセスコマンドから特定された仮想領域に割り当てられた実領域にアクセスするコントローラとを有する。コントローラは、どの仮想領域にどの実領域が割り当てられているかと仮想領域に関するアクセス負荷とを表す情報であるプール状況情報を管理する。ストレージ装置の管理システムが、記憶資源と、前記記憶資源に接続されたプロセッサとを有する。前記記憶資源が、各実領域群の現在の記憶容量を表す情報である容量管理情報を記憶する。前記プロセッサが、現在から過去における複数の時点での前記プール状況情報と、１以上のアクセス負荷閾値とに基づいて、将来の時点での実領域群毎の使用容量を予測する。前記プロセッサが、予測された使用容量と前記容量管理情報が表す現在の記憶容量との差分である増設／減設量を実領域群毎に計算し、その計算の結果に基づく処理を実行する。【００１１】
例えば、前記コントローラは、第１の実領域群における第１の実領域内のデータを、前記第１の実領域のアクセス負荷に適した種類の第２の実領域群における第２の実領域にマイグレーションし、前記第１の実領域が割り当てられた仮想領域に、前記第１の実領域に代えて前記第２の実領域を割り当てることができる。【００１２】
ホスト装置は、計算機であっても良いし、前記ストレージ装置とは別のストレージ装置であっても良い。また、実領域群の性能としては、例えば、アクセスに関する性能がある。アクセスに関する性能としては、例えば、データのアクセスのためのコマンドが入力されてからそのコマンドに対する応答が出力されるまでの時間長であるレスポンスタイム、或いは、単位時間当たりに入出力されるデータの量がある。また、アクセス負荷は、アクセスに関する負荷であり、例えば、アクセス頻度（単位時間当たりに行われるアクセスの回数）、又は、データ転送速度（単位時間当たりに転送されるデータの量）である。また、「仮想領域に関するアクセス負荷」とは、仮想領域のアクセス負荷（仮想領域内のデータのアクセス負荷）であっても良いし、仮想領域に割り当てられている実領域のアクセス負荷であっても良い。また、アクセスは、例えば、リード及び／又はライトである。【００１３】
前記管理システムは、前記ストレージ装置の外に存在する１以上の計算機であっても良いし、前記コントローラと一体になっていても良いし、前記ホスト装置と一体になっていても良いし、前記ストレージ装置と前記ストレージ装置の外に存在する装置との組合せで実現されても良い。
【発明の効果】
【００１４】
性能が異なる複数の実領域群で構成されるプールについて、適切な増設／減設量を実領域群毎に求められる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施例１に係るストレージシステムの構成を示す。
【図２】実施例１に係るストレージ装置１０００内のメモリ１５００に記憶されるプログラム及び情報を示す。
【図３】物理リソーステーブル１５５０の例を示す。
【図４】セグメント管理テーブル１５６０の例を示す。
【図５】仮想ボリューム管理テーブル１５７０の例を示す。
【図６】マイグレーションポリシテーブル１５８０の例を示す。
【図７】実施例１に係る管理計算機２０００内のメモリ２５００に記憶されるプログラムおよびテーブルを示す。
【図８】プール容量管理テーブル２５６０の例を示す。
【図９】ＩＯＰＳ性能評価テーブル２５７０の例を示す。
【図１０】容量推移履歴テーブル２５８０の例を示す。
【図１１】実施例１に係るホスト計算機３０００のメモリ３５００内に存在するプログラムを示す。
【図１２】セグメントＩＯ評価プログラム２５３０の処理のフローチャートである。
【図１３】容量予測（１）プログラム２５４０の処理のフローチャートである。
【図１４】図１３のステップ４０４０の処理のフローチャートである。
【図１５】実施例１の増設量の見積例を示すグラフ。
【図１６】図１３のステップ４０１０で表示されるＧＵＩ５１００の例を示す。
【図１７】図１４のステップ４０４７で表示されるＧＵＩ５２００の例を示す。
【図１８】実施例２に係る管理計算機２０００内のメモリ２５００に記憶されるプログラム及び情報を示す。
【図１９】セグメントＩＯＰＳ分布履歴テーブル２６４０の例を示す。
【図２０】増設パターン保持テーブル２６５０の例を示す。
【図２１】実施例２のパラメータの意味を説明するグラフを示す。
【図２２】セグメントＩＯＰＳ予測プログラム２６１０の処理のフローチャートを示す。
【図２３】容量予測（２）プログラム２６２０の処理のフローチャートを示す。
【図２４】図２３のステップ４３４０の処理の一部のフローチャートを示す。
【図２５】図２３のステップ４３４０の処理の残りのフローチャートを示す。
【図２６】図２３のステップ４３１０で表示されるＧＵＩ５３００の例を示す。
【図２７】図２５のステップ４３５８で表示されるＧＵＩ５４００の例を示す。
【図２８】実施例３に係る容量予測（２）プログラム２６２０の処理の一部分のフローチャートを示す。
【図２９】図２８のステップ４３７３で表示されるＧＵＩ５５００の例を示す。
【図３０】実施例４に係る管理計算機２０００のメモリ２５００に記憶されるプログラム及び情報を示す。
【図３１】プール性能監視プログラム２７００の処理のフローチャートを示す。
【図３２】図３１のステップ４５５０で表示されるＧＵＩ５７００の例を示す。
【図３３】実施例５に係る管理計算機２０００内のメモリ２５００に記憶されるプログラム及び情報を示す。
【図３４】実施例５に係るストレージ装置１０００内のメモリ１５００に記憶されるプログラムおよび情報を示す。
【図３５】本発明の実施例６に係るストレージシステムを示す。
【図３６】実施例６に係るプール管理の概念を示す。
【図３７】実施例６に係るホスト計算機３０００内のメモリ３５００に記憶されるプログラム及び情報を示す。
【図３８】リソース管理テーブル３６１０の例を示す。
【図３９】実施例６に係る容量予測プログラム３５７０が行った予測の結果を示すＧＵＩの例を示す。
【発明を実施するための最良の形態】
【００１６】
本発明の幾つかの実施例を説明する。なお、本発明の技術的範囲が各実施例に限定されてはならない。【００１７】
なお、以後の説明では、「ｘｘｘテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｘｘｘテーブル」を「ｘｘｘ情報」と呼ぶことができる。【００１８】
また、以後の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信制御装置（例えば通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。また、プログラムを主語として説明された処理は、管理システムが行う処理としても良い。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。このため、プログラムを主語として説明された処理は、コントローラが行う処理としても良い。コントローラは、プロセッサと、プロセッサに実行されるコンピュータプログラムを記憶する記憶資源とを含んでも良いし、上記の専用ハードウェアを含んでも良い。また、コンピュータプログラムは、プログラムソースから各計算機にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアであっても良い。【００１９】
なお、管理システムは、一以上の計算機、例えば、管理計算機、又は、管理計算機と表示用計算機との組み合わせである。具体的には、例えば、管理計算機が表示用情報を表示する場合は、管理計算機が管理システムである。また、処理の高速化や高信頼化のために、複数の計算機で管理計算機と同等の機能が実現されてもよく、この場合は、当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機を含んで良い）が、管理システムである。
【実施例１】
【００２０】
＜概要＞。【００２１】
まず、本発明の実施例１を説明する。【００２２】
実施例１では、シンプロビジョニング技術およびセグメントマイグレーション技術が適用されたストレージ装置と、そのストレージ装置を管理する計算機（以下、管理計算機）とがある。ストレージ装置は、各セグメントのアクセス頻度を計測する。ストレージ装置は、各セグメントのアクセス頻度と、予め用意された、複数のメディアに対応した複数の許容アクセス頻度範囲とを基に、移行元のセグメントと移行先のセグメントとを決定する。そして、ストレージ装置は、移行元のセグメントから移行先のセグメントへのデータのマイグレーションを行う。これにより、データが、そのデータのアクセス頻度に相応しいメディアに配置されることになる。なお、管理計算機が、各セグメントのアクセス頻度を表す情報をストレージ装置から取得し、各セグメントのアクセス頻度と、複数のメディアに対応した複数の許容アクセス頻度とを基に、移行元のセグメントと移行先のセグメントとを決定して良い。そして、管理計算機は、決定した移行元のセグメントを表す情報と移行先のセグメントを表す情報とを有したセグメントマイグレーション指示をストレージ装置に送信することで、ストレージ装置に、移行元のセグメントから移行先のセグメントへのデータのマイグレーションを行わせても良い。【００２３】
管理計算機が、一定間隔で、その時点でのプールの使用状況を表す情報（以下、プール状況情報）、例えば、下記の（Ａ）乃至（Ｃ）を含んだ情報を、ストレージ装置から取得する。
（Ａ）ＶＶＯＬに割り当てられているセグメントの識別情報。
（Ｂ）ＶＶＯＬに割り当てられているセグメントのアクセス頻度を表す情報。
（Ｃ）ＶＶＯＬに割り当てられているセグメントが属するメディアの識別情報。【００２４】
管理計算機は、複数の時点で取得されたプール状況情報から、各時点での、アクセス頻度とセグメント数の分布を求める。管理計算機は、アクセス頻度とセグメント数の分布の推移と、複数のメディアに対応した複数の許容アクセス頻度とを基に、メディア毎に、現在から所定期間後にＶＶＯＬに割り当てられることになるセグメントの数（以下、将来のセグメント数）を予測する。メディアについての将来のセグメント数Nfutureからそのメディアを構成する現在のセグメントの数（以下、現在のセグメント数）Ncurrentを引いた値（Nfuture−Ncurrent）が、そのメディアについての増設量である。例えば、メディアＡについて、増設量が、正の値であれば、所定期間後にセグメントが不足すると可能性が高いので、現時点で増設量分のセグメントをメディアＡに増設することが望ましい。一方、メディアＡについて、増設量が、ゼロ又は負の値であれば、所定期間経ってもセグメントが不足しない可能性が高いので、現時点でセグメントをメディアＡに増設することは不要である（増設量分のセグメントがメディアＡから減設されても良い）。【００２５】
以上のように、管理計算機は、各時点のプール状況情報を基に、メディア毎に増設量を算出することができる。このため、必要以上に性能がアップされてしまいそれによりコストが無駄に増えてしまうような増設や、性能を大きく低下させてしまう増設を回避することができる。なお、本実施例で言う「コスト」とは、負荷を意味する。負荷は、費用面での負荷であっても良いし、消費電力面での負荷であっても良い。【００２６】
以下、図面を参照して、実施例１を詳細に説明する。【００２７】
＜構成説明＞。【００２８】
図１は、本発明の実施例１に係るストレージシステムの構成を示す。【００２９】
実施例１のストレージシステムは、ストレージ装置１０００と、ストレージ装置１０００に接続しこれを管理する管理計算機２０００と、ストレージ装置１０００が提供する記憶領域を利用するホスト計算機３０００とを有する。なお、ホスト計算機３０００は、複数存在してもよい。【００３０】
ストレージ装置１０００の管理ＩＦ（図では、Ｍ−ＩＦ）１０１０、および、ホスト計算機３０００の管理ＩＦ３４００は、管理計算機２０００の管理ＩＦ２４００に、ＳＡＮ（Storage Area Network）やＬＡＮ（Local Area Network）等のデータネットワーク１００を通じて接続されている。ストレージ装置１０００の通信ＩＦ１０２０が、ホスト計算機の通信ＩＦ３３００に、ＳＡＮやＬＡＮ等のデータネットワーク２００を通じて接続されている。各管理ＩＦおよび通信ＩＦは、データネットワークがＳＡＮの場合、計算機ではＨＢＡ（Host Bus Adapter）等、ストレージ装置ではポート等であり、データネットワークがＬＡＮの場合、計算機でもストレージ装置でもＮＩＣ（Network Interface Card）等である。つまり、管理ＩＦ及び通信ＩＦがどのような通信インタフェースデバイスであるかは、そのＩＦが接続されるネットワークの種類や、そのＩＦを有する装置の種類によって異なる。なお、データネットワーク１００とデータネットワーク２００は同一のネットワークであってもよい。また、各ＩＦ間は、１本のケーブルで直接接続されていてもよいし、スイッチ等を介して接続されても良い。【００３１】
次に、ストレージ装置１０００のハードウェア構成を説明する。【００３２】
ストレージ装置１０００は、複数の物理リソース１４００を備える。物理リソース１４００は、物理的な記憶領域である。物理リソース１４００を基に、論理的な記憶デバイスである論理ボリュームが設けられている。ここで、「物理的な記憶領域」とは、一つの物理的な記憶デバイスにであってもよいし、複数の物理的な記憶デバイスで構成されたＲＡＩＤグループであってもよい。また、物理的な記憶デバイスは、ＳＳＤ（Solid State Disk）、ＳＡＳ（Serial Attached SCSI）−ＨＤＤ（Hard Disk Drive）、ＳＡＴＡ（Serial Advanced Technology Attachment）−ＨＤＤ等である。このように、ストレージ装置１０００には、性能の異なる複数の物理リソース１４００が混在している。【００３３】
また、ストレージ装置１０００は、データの入出力を制御するための制御装置であるコントローラ１１００を備える。コントローラ１１００は、前述した管理ＩＦ１０１０及び通信ＩＦ１０２０の他に、物理リソース１４００と通信するためのディスクＩＦ１３００と、メモリ１５００と、それらに接続されたＣＰＵ１２００とを有する。メモリ１５００は、ホスト計算機３０００からのアクセスコマンドに応答して物理リソース１４００にアクセスされるデータを一時記憶しておくためのキャッシュメモリを含んでいてもよい。【００３４】
図２は、メモリ１５００に記憶されるプログラム及び情報を示す。【００３５】
プログラムとして、構成情報通信プログラム１５１０、物理リソース管理プログラム１１５２０、プール管理プログラム１５３０及びセグメントマイグレーションプログラム１５４０がある。プログラム１５１０、１５２０、１５３０及び１５４０が行う処理は、実際には、それらのプログラムを実行するＣＰＵ１２００によって行われる。情報として、物理リソーステーブル１５５０、セグメント管理テーブル１５６０、仮想ボリューム管理テーブル１５７０及びマイグレーションポリシテーブル１５８０がある。【００３６】
構成情報通信プログラム１５１０は、管理ＩＦ１０１０経由の情報取得要求に応じて後述のテーブルを外部に送信する処理と、設定処理要求に応じて各プログラムに処理を行わせる。【００３７】
物理リソース管理プログラム１５２０は、論理ボリュームの構成の管理を行う。具体的には、そのプログラム１５２０は、物理リソーステーブル１５５０を管理する。【００３８】
図３は、物理リソーステーブル１５５０の例を示す。【００３９】
物理リソーステーブル１５５０は、物理リソースに基づく論理ボリュームに関する情報を有する。具体的には、物理リソーステーブル１５５０は、ストレージ装置１０００が管理する論理ボリューム毎に、下記の情報、
＊論理ボリュームを識別するためのＩＤであるＶＯＬ  ＩＤ１５５１、
＊論理ボリュームの基になっている物理リソース１４００の種別を示すリソース種別１５５２、
＊論理ボリュームの記憶容量を表す容量１５５３、
＊論理ボリュームが属する階層のＩＤである階層ＩＤ１５５４
を有する。ここで、階層とは、同じ性能及び運用コストの複数の論理ボリュームの集合であり、前述した「メディア」に相当する。例えば、ＳＳＤに基づく論理ボリュームの集合としての階層（メディア）は、高性能が見込まれるので、高位の階層を示すＩＤ「ＴＩＥＲ０」が割り振られる。ＳＡＳ−ＨＤＤに基づく論理ボリュームの集合としての階層（メディア）は、ＳＳＤに基づく階層より性能が低いと見込まれるので、ＳＳＤに基づく階層より低い階層を示すＩＤ「ＴＩＥＲ１」が割り振られる。ＳＡＴＡ−ＨＤＤに基づく論理ボリュームの集合としての階層（メディア）は、ＳＡＳ−ＨＤＤに基づく階層より性能が低いと見込まれるので、ＳＡＳ−ＨＤＤに基づく階層より低い階層を示すＩＤ「ＴＩＥＲ２」が割り振られる。階層ＩＤ１５５４は、論理ボリューム作成時に物理リソース管理プログラム１５２０によって自動的に割り振られても良いし、ストレージ装置１０００を管理する管理者が手動で割り振ってもよい。加えて、テーブル１５５０は、ＲＡＩＤの冗長化の程度を示すＲＡＩＤレベル等を含んでも良く、その場合、リソース種別１５５２に加えてＲＡＩＤレベルに従う性能や運用コストを考慮した階層ＩＤ１５５４が振られていてもよい。以下、階層を「メディア」と言うことがある。なお、階層（メディア）は、３種類以上であっても良い。【００４０】
再び図２を参照する。【００４１】
プール管理プログラム１５３０は、シンプロビジョニング技術を実現するためのプールおよび仮想ボリュームを管理する。具体的には、例えば、そのプログラム１５３０は、セグメント管理テーブル１５６０と、仮想ボリューム管理テーブル１５７０を管理する。【００４２】
図４は、セグメント管理テーブル１５６０の例を示す。【００４３】
セグメント管理テーブル１５６０は、セグメントに関する情報を有する。具体的には、セグメント管理テーブル１５６０は、プールを構成するセグメント毎に、下記の情報、
＊セグメントを一意に識別するためのＩＤであるセグメントＩＤ１５６１、
＊セグメントが存在する論理ボリューム（プールボリューム）を表すＩＤであるＶＯＬ  ＩＤ１５６２、
＊その論理ボリュームでの開始位置（セグメントの開始位置）を表すＬＢＡである開始ＬＢＡ１５６３、
＊セグメントのサイズを示すセグメントサイズ１５６４、
＊セグメントの割当先の仮想ボリューム（ＶＶＯＬ）のＩＤである割当先ＶＶＯＬ  ＩＤ１５６５、
を有する。このテーブル１５６０によれば、例えば、セグメントＩＤ：００００は、論理ボリューム：ＤＥＶ１において、ＬＢＡ：０からセグメントサイズ：１０００分（ＬＢＡ：０からＬＢＡ：９９９まで）を占めており、仮想ボリューム：ＶＶＯＬ１に割り当てられている。また、割当先ＶＶＯＬ  ＩＤ：ＮＵＬＬとなっているセグメントは、まだＶＶＯＬに割り当てられていないことを示す。以降の説明を分かり易くするため、全てのセグメントのサイズが１００ＭＢ（Mega Bytes）であるとする。しかし、各セグメントのサイズは、１００ＭＢでなくても良いし、固定サイズでなく可変サイズであっても良いし、全てのセグメントのサイズが同じでなくても良い。【００４４】
本実施例では、プールの数は１つであるとする。しかし、プールは複数存在しても良い。【００４５】
また、「セグメント」とは、プールを構成する実領域（実体的な記憶領域）である。プールは、性能の異なる複数のセグメント群を有する。各セグメント群は、性能の同じ複数の論理ボリュームで構成されている。プールの構成要素としての論理ボリュームを「プールボリューム」と言うことがある。プールボリュームは、物理リソース１４００に基づく実体的な論理ボリュームであっても良いし、図示しない外部のストレージ装置のストレージリソース（論理ボリューム又は物理リソース）に基づく論理ボリュームであっても良い。つまり、セグメントは、ＶＶＯＬに割り当て可能な記憶領域であれば良い。【００４６】
ＶＶＯＬは、複数の仮想領域（仮想的な記憶領域）で構成された仮想的な論理ボリューム（シンプロビジョニング技術に従うボリューム）である。ＶＶＯＬは、ホスト計算機３０００に提供される。【００４７】
図５は、仮想ボリューム管理テーブル１５７０の例を示す。【００４８】
仮想ボリューム管理テーブル１５７０は、ＶＶＯＬに関する情報を有する。具体的には、仮想ボリューム管理テーブル１５７０は、仮想領域毎に、下記の情報、
＊仮想領域を有するＶＶＯＬのＩＤであるＶＶＯＬ  ＩＤ１５７１、
＊そのＶＶＯＬの記憶容量（ホスト計算機３０００が認識する記憶容量）を表す容量１５７２、
＊仮想領域のＶＶＯＬでの開始位置を示すＬＢＡである開始ＬＢＡ１５７３、
＊仮想領域に割り当てられたセグメントのサイズを示すセグメントサイズ１５７４、
＊仮想領域に割り当てられたセグメントのＩＤであるセグメントＩＤ１５７５、
＊仮想領域に割り当てられているセグメントへのアクセス頻度であるＩＯＰＳ（Input Output Per Second）１５７６、
を有する。このテーブル１５７０によれば、例えば、ＶＶＯＬ：ＶＶＯＬ１は、１０ＴＢ（テラバイト）のボリュームとしてホスト計算機３０００に認識される。ＶＶＯＬ：ＶＶＯＬ１のＬＢＡ：０から１０００分の仮想領域に、セグメントＩＤ：００００のセグメントが割り当てられている。そのセグメントのアクセス頻度は、１００００である。【００４９】
なお、セグメントが割り当てられていない仮想領域は、次の（ａ）又は（ｂ）の方法で判別可能である。
（ａ）その仮想領域に対応したセグメントＩＤ１５７５が「ＮＵＬＬ」である。
（ｂ）テーブル１５７０にその仮想領域に対応したレコードが存在しない。【００５０】
また、アクセス頻度は、各一定期間におけるアクセス回数であれば、ＩＯＰＳに限らなくて良い。ＩＯＰＳは、後述するセグメントマイグレーションの間隔内で発生したＩＯ（Input Output）単位などであってもよい。また、マイグレーションポリシテーブル１５８０によっては、仮想ボリューム管理テーブル１５７０は、上述の情報に加え、データの移行元を判断するための基準となる情報（例えば、各セグメントへの最終アクセス日時）を保持していてもよい。【００５１】
ＩＯＰＳは、セグメントのＩＯＰＳであるため、セグメントに対してアクセスが行われた場合に更新される。言い換えれば、仮想領域に対するアクセスが発生しても、セグメントにアクセスしなくても済んだ場合には（例えば、キャッシュメモリにリード対象のデータがあったが故に、キャッシュメモリ内のデータをホスト計算機３０００に提供することで、リード処理が終了した場合には）、その仮想領域に割り当てられているセグメントのＩＯＰＳは更新されない。なお、仮想領域に対するアクセスが発生した場合には、その仮想領域に割り当てられているセグメントにアクセスしたか否かに関わらず、仮想領域に対応したＩＯＰＳ１５７６は更新されても良い。また、仮想領域に対するアクセスが特定種類のアクセスである場合には（例えば、アクセスがリードの場合には）、仮想領域に対応したＩＯＰＳ１５７６は更新されなくても良い。【００５２】
再び図２を参照する。プール管理プログラム１５３０は、セグメント管理テーブル１５６０と仮想ボリューム管理テーブル１５７０を用いることにより、仮想領域とセグメントとの対応関係を管理するとともに、セグメント未割当の仮想領域にアクセスがあった場合に、未使用のセグメントをその仮想領域に割り当てる。【００５３】
アクセス先情報（例えば、ＶＶＯＬのＩＤ、及び、ＬＢＡ）を有するライトコマンドをストレージ装置２０００がホスト計算機３０００から受信した場合、以下の処理を含んだライト処理が行われる。
（Ｓ００１）プール管理プログラム１５０３が、ライトコマンドに従うデータをキャッシュメモリに格納する。この時点で、プログラム１５０３は、ライトの完了応答をホスト計算機３０００に返して良い。
（Ｓ００２）プール管理プログラム１５３０が、アクセス先情報を基に、ライト先となるＶＶＯＬ及び仮想領域を特定する。
（Ｓ００３）プログラム１５３０が、ライト先仮想領域にセグメントが割り当てられているか否かを、テーブル１５７０を基に判断する。
（Ｓ００４）Ｓ００３の判断が否定的であれば、プログラム１５３０が、空きのセグメント（どの仮想領域にも割り当てられていないセグメント）を、テーブル１５６０を基に特定する。プログラム１５３０が、特定したセグメントをライト先仮想領域に割り当てる。具体的には、プログラム１５３０が、ライト先仮想領域に対応したレコード（テーブル１５７０におけるレコード）に、特定したセグメントのＩＤ、サイズ及びＩＯＰＳを登録する。
（Ｓ００５）Ｓ００３の判断が肯定的、又は、Ｓ００４の後、プログラム１５３０が、ライト先仮想領域に割り当てられているセグメントに、キャッシュメモリ内のデータを書き込む。この時点で、プログラム１５０３は、ライトの完了応答をホスト計算機３０００に返して良い。なお、この時点で、そのセグメントのＩＯＰＳ１５７６が、セグメントマイグレーションプログラム１５４０によって更新される。【００５４】
アクセス先情報（例えば、ＶＶＯＬのＩＤ、及び、ＬＢＡ）を有するリードコマンドをストレージ装置２０００がホスト計算機３０００から受信した場合、以下の処理を含んだリード処理が行われる。
（Ｓ０１１）プール管理プログラム１５３０が、アクセス先情報を基に、リード元となるＶＶＯＬ及び仮想領域を特定する。
（Ｓ０１２）プログラム１５３０が、リード対象のデータがキャッシュメモリに残っているか否かを判断する。
（Ｓ０１３）Ｓ０１２の判断が肯定的の場合、プログラム１５３０は、キャッシュメモリ内のリード対象データを、ホスト計算機３０００に送信する。この場合、リード元仮想領域に割り当てられているセグメントのＩＯＰＳ１５７６は、更新されない。
（Ｓ０１４）Ｓ０１２の判断が否定的の場合、プログラム１５３０が、リード元仮想領域に割り当てられているセグメントを、テーブル１５７０を基に判断する。
（Ｓ０１５）プログラム１５３０が、特定されたセグメントからリード対象データをリードし、キャッシュメモリに格納する。この時点で、そのセグメントのＩＯＰＳ１５７６が、セグメントマイグレーションプログラム１５４０によって更新される。
（Ｓ０１６）プログラム１５３０は、Ｓ０１５でキャッシュメモリに格納されたリード対象データを、そのリード対象データをホスト計算機３０００に送信する。【００５５】
セグメントマイグレーションプログラム１５４０とマイグレーションポリシテーブル１５８０について説明する。【００５６】
セグメントマイグレーションプログラム１５４０は、各セグメントへのアクセスを監視し、仮想ボリューム管理テーブル１５７０のＩＯＰＳ１５７６を更新する。加えて、セグメントマイグレーションプログラム１５４０は、システムまたは管理者によって指定された間隔で、マイグレーションポリシテーブル１５８０を基に、テーブル１５８０に従ったメディア間（階層間）のセグメントマイグレーションを行う。そして、プログラム１５４０は、仮想領域とセグメントの関係（セグメント管理テーブル１５６０と仮想ボリューム管理テーブル１５７０）を更新する。具体的には、プログラム１５４０は、移行元のセグメントが割り当てられている仮想領域に、その移行元のセグメントに代えて、移行先のセグメントを割り当てる。【００５７】
図６は、マイグレーションポリシテーブル１５８０の例を示す。【００５８】
マイグレーションポリシテーブル１５８０は、ポリシ毎に、下記の情報、
＊ポリシを識別するためのＩＤ１５８１、
＊マイグレーション実施契機１５８２、
＊実行すべき処理を記載したポリシ１５８３、
を有する。契機１５８２およびポリシ１５８３は、ストレージ初期出荷時に設定されたものであってもよいし、あとで管理者によって手動で設定されたものであってもよい。例えば、図６に示したＩＤ：０とＩＤ：１のポリシに従った場合、セグメントマイグレーションプログラム１５４０は、ＩＯＰＳが大きいセグメントから順に、セグメント内のデータを、階層：ＴＩＥＲ０（ＳＳＤメディア）内のセグメントへマイグレーションする。ＳＳＤメディアに空きのセグメントが無くなった場合には、次の階層：ＴＩＥＲ１（ＳＡＳメディア）内の空きのセグメントにデータがマイグレーションされる。これにより、セグメントのアクセス頻度に応じたメディア利用が可能である。【００５９】
次に、管理計算機２０００内のハードウェア構成について、図１を参照して説明する。【００６０】
管理計算機２０００は、管理ＩＦ２４００に加え、メモリ２５００と、補助記憶装置であるディスク２２００と、それらに接続されたＣＰＵ２１００とを備える。【００６１】
図７は、メモリ２５００が記憶するプログラムおよび情報を示す。【００６２】
プログラムとして、構成管理プログラム２５１０、構成情報取得プログラム２５２０、セグメントＩＯ評価プログラム２５３０、容量予測（１）プログラム２５４０、表示（１）プログラム２５５０がある。これらのプログラムは、ＣＰＵ２１００で実行される。情報として、プール容量管理テーブル２５６０、ＩＯＰＳ性能評価テーブル２５７０、容量推移履歴テーブル２５８０がある。【００６３】
構成管理プログラム２５１０は、ストレージ管理者からの設定指示を受け取り、ストレージ装置１０００へ設定指示を行う。例えば、管理者は、構成管理プログラム２５１０を用いて、ストレージ装置１０００が持つマイグレーションポリシテーブル１５８０の設定等が可能である。構成管理プログラム２５１０が管理する情報の一つとして、プール容量管理テーブル２５６０がある。【００６４】
図８は、プール容量管理テーブル２５６０の例を示す。【００６５】
プール容量管理テーブル２５６０は、プールの容量に関する情報を有する。具体的には、テーブル２５６０は、メディア毎に、下記の情報、
＊メディアの種類を表す分類２５６１、
＊メディアを構成する全てのセグメントの総記憶容量を表す容量２５６２、
を有する。分類２５６１として、“プール全体”があっても良く、その場合、容量２５６２として、プールを構成する全てのメディアの総記憶容量が記録される。図８のテーブル２５６０によれば、プールは、階層：ＴＩＥＲ０が３０ＴＢ、階層：ＴＩＥＲ１が１１０ＴＢ、階層：ＴＩＥＲ２が５００ＴＢであり、プールの容量は、それらの合計である６４０ＴＢである。テーブル２５６０は、実質的に、ストレージ装置１０００のプールの状態と常に一致している。なぜなら、構成管理プログラム２５１０が、構成情報取得プログラム２５２０を用いて、ストレージ装置１０００が持つプールの状態を常に監視する等を行うからである。【００６６】
構成情報取得プログラム２５２０は、ストレー装置１０００が持つ管理ＩＦ１０１０を介して、構成情報通信プログラム１５１０と通信し、ストレージ装置１０００が持つ情報を取得する。【００６７】
セグメントＩＯ評価プログラム２５３０は、ＩＯＰＳ評価テーブル２５７０を用いて、セグメントのアクセス頻度から、そのセグメント内のデータが配置されることが望ましいメディアを算出し、算出結果を容量推移履歴テーブル２５８０に記録する。【００６８】
容量予測（１）プログラム２５４０は、容量推移履歴テーブル２５８０を用いて、今後必要となる容量をメディア毎に予測する。【００６９】
これらのプログラムが行う処理については、後述のフローチャートを用いて、詳細に説明する。【００７０】
図９は、ＩＯＰＳ性能評価テーブル２５７０の例を示す。【００７１】
ＩＯＰＳ性能評価テーブル２５７０は、どのＩＯＰＳ範囲に属するＩＯＰＳのセグメント内のデータがどの種類のメディア内に配置されるべきかを表す情報を有する。具体的には、テーブル２５７０は、メディア毎に、下記の情報、
＊メディア（階層）を識別するためのＩＤである階層ＩＤ２５７１、
＊メディアの種別（メディアを構成する論理ボリュームの基になっている物理リソースの種別）を表すリソース種別２５７２、
＊メディアに配置されることが望ましいデータを有するセグメントの望ましいＩＯＰＳ範囲である許容ＩＯＰＳ範囲２５７３、
＊メディアにおける全ての使用セグメント（仮想領域に割り当てられているセグメント）のＩＯＰＳが許容ＩＯＰＳ範囲２５７３におさまっている時に期待される性能（レスポンスタイム）である想定レスポンスタイム２５７４、
を有する。ここで言う「レスポンスタイム」は、ストレージ装置１０００内でのレスポンスタイム、具体的には、セグメントにアクセスするためのコマンドがコントローラ１１００から発行されてからそのセグメントに対するアクセスが完了するまでの時間長である。「想定レスポンスタイム」は、想定されるレスポンスタイム（期待されるレスポンスタイム）である。【００７２】
本テーブル２５７０は、前述のマイグレーションポリシテーブル１５８０とは異なり、セグメント内のＩＯＰＳを基にそのセグメント内のデータが配置されることが望ましいＴＩＥＲを算出するためのテーブルである。【００７３】
許容ＩＯＰＳ範囲２５７３および想定レスポンスタイム２５７４の導出の一例として、次のようなものがある。【００７４】
一般に、物理リソース１４００は、ＩＯＰＳが特定のＩＯＰＳ（以下、境界ＩＯＰＳ）以下ならば常に同程度のレスポンスタイム（想定レスポンスタイム）を期待できるが、ＩＯＰＳがその境界ＩＯＰＳを超えると、レスポンスタイムは急激に大きくなる（想定レスポンスを超える）。高性能なメディアほど境界ＩＯＰＳが大きい。このことから、メディア毎の境界ＩＯＰＳを組み合わせることにより、図９に示した許容ＩＯＰＳ範囲２５７３が導出可能である。加えて、管理者が直接入力することにより、ＩＯＰＳ性能評価テーブル２５７０が決定されてもよい。また、実施例１においては、想定レスポンスタイム２５７４は無くても良い。【００７５】
図１０は、容量推移履歴テーブル２５８０の例を示す。【００７６】
容量推移履歴テーブル２５８０は、各時点で、ストレージ装置１０００から取得された情報を基に算出されたメディア毎の使用容量（使用セグメントの総記憶容量）を表す情報を有する。具体的には、テーブル２５８０は、時点毎に、下記の情報、
＊時点の日時を表す時刻２５８１、
＊その時点でのＴＩＥＲ０（ＳＳＤメディア）の使用容量を表す情報２５８２、
＊その時点でのＴＩＥＲ１（ＳＡＳメディア）の使用容量を表す情報２５８３、
＊その時点でのＴＩＥＲ２（ＳＡＴＡメディア）の使用容量を表す情報２５８４、
を有する。各時点での各メディアの使用容量は、セグメントＩＯ評価プログラム２５３０により算出される。ＴＩＥＲが４つ以上ある場合は、その分、列の数が増える。【００７７】
本テーブル２５８０によれば、例えば、（ｘ−１）年４月には、各セグメントのＩＯＰＳを鑑みて、ＴＩＥＲ０が１０ＴＢ、ＴＩＥＲ１が４０ＴＢ、ＴＩＥＲ２が２００ＴＢであることが望ましいと判断することができる。なお、容量推移履歴テーブル２５８０の更新の詳細については、後述のセグメントＩＯ評価プログラム２５３０の処理を説明する際に合わせて説明する。【００７８】
図７に示した表示（１）プログラム２５５０は、ディスプレイ装置等の出力装置に、ＧＵＩ（Graphical User Interface）等を表示し、管理者に各設定値の入力を求めたり、プログラムの実行結果を出力したりする。具体的な表示例は、後述の説明の中で行う。【００７９】
次に、ホスト計算機３０００内のハードウェア構成について、図１を用いて説明する。【００８０】
ホスト計算機３０００は、前述の通信ＩＦ３３００と管理ＩＦ３４００に加えて、メモリ３５００と、補助記憶装置であるディスク３２００と、それらに接続されたＣＰＵ３１００とを備える。【００８１】
図１１に示すように、メモリ３５００には、ＣＰＵ３１００に実行されるコンピュータプログラムとして、例えば、業務プログラム３５１０が記憶されている。業務プログラム３５１０は、例えば、データベースを管理するプログラム等であり、データベース等に格納されるデータが、ＶＶＯＬを通じてプールに格納される。【００８２】
管理計算機２０００およびホスト計算機３０００は、例えば、パーソナルコンピュータやワークステーション等である。各計算機のメモリ（２５００およびメモリ３５００）には、ＯＳ（Operating System）やデータを一時記憶しておくためのキャッシュメモリが含まれてもよい。加えて、各計算機は、前述のハードウェア構成に加え、キーボード等の入力装置や、ディスプレイ装置等の出力装置を備えてもよい。また、各計算機において、データを全てストレージ装置１０００に記憶する等の場合は、ディスク（２０００および３０００）は無くてもよい。【００８３】
＜処理説明：セグメントＩＯ評価プログラム２５３０＞。【００８４】
図１２は、セグメントＩＯ評価プログラム２５３０の処理のフローチャートである。【００８５】
例えば、予め設定したスケジュールに従うタイミング、または、管理者が指定したタイミングで、処理が開始される。【００８６】
ステップ４１１０において、セグメントＩＯ評価プログラム２５３０は、一定間隔で、ステップ４１２０からステップ４１７０までの処理を繰り返す。「一定間隔」とは、例えば、ストレージ装置１０００のセグメントマイグレーションプログラム１５４０が行うセグメントマイグレーションの開始時間間隔であってもよいし、管理者が指定した任意の時間間隔であってもよい。【００８７】
ステップ４１２０において、プログラム２５３０は、構成情報取得プログラム２５２０を介して、ストレージ装置１０００から、仮想ボリューム管理テーブル１５７０を取得する。【００８８】
ステップ４１３０において、プログラム２５３０は、ステップ４１２０で取得した仮想ボリューム管理テーブル１５７０を基に各使用セグメントＡ（ＶＶＯＬに割当済みのセグメント）について、ステップ４１４０からステップ４１６０の処理を行う。以下、１つの使用セグメントＡを例に採り（図１２の説明において「対象セグメントＡ」と言う）、ステップ４１４０からステップ４１６０を説明する。【００８９】
まず、プログラム２５３０は、ＩＯＰＳ性能評価テーブル２５７０にある各ＴＩＥＲ  Ｘ（Ｘ＝０，１，…）について（ステップ４１４０）、対象セグメントＡのＩＯＰＳが、ＴＩＥＲ  Ｘの許容ＩＯＰＳ範囲２５７３内にあるか否かを判断する（ステップ４１５０）。【００９０】
ステップ４１５０の判断の結果が肯定的であれば、プログラム２５３０は、ＴＩＥＲ  Ｘのセグメントカウント値を１増やす（ステップ４１６０）。ステップ４１５０の判断の結果が否定的であれば、ステップ４１４０に戻り、ＴＩＥＲ  （Ｘ＋１）について、ステップ４１５０が行われる。セグメントカウント値は、ＩＯＰＳ性能評価テーブル２５７０に従う理想的なデータ配置になっていると仮定したときの、使用セグメントの数を意味する。【００９１】
具体例を挙げて説明する。例えば、プログラム２５３０は、セグメントＩＤ：２００１（図５参照）のＩＯＰＳが、ＴＩＥＲ０の許容ＩＯＰＳ範囲２５７３（図９参照）にあるか判断を行う。ＴＩＥＲ０の許容ＩＯＰＳ範囲は５０１以上であるため、その判断の結果が否定的となる。このため、プログラム２５３０は、セグメントＩＤ：２００１のＩＯＰＳが、ＴＩＥＲ１の許容ＩＯＰＳ範囲内にあるか判断を行う。その判断の結果は肯定的となるので、プログラム２５３０は、ＴＩＥＲ１のセグメントカウント値を１増やす。【００９２】
ステップ４１４０からステップ４１６０の処理を、全ての使用セグメントに対して実施することとなる。【００９３】
そして、ステップ４１７０において、プログラム２５３０は、各ＴＩＥＲのセグメントカウント値（ＴＩＥＲにおける理想的な使用セグメント数）を容量に変換し、容量推移履歴テーブル２５８０の現在の時刻部分に追記する。例えば、Ｘ年４月に、ＴＩＥＲ０のセグメントカウント値が２２００００であったとすると、本実施例では、１セグメントが１００ＭＢであることから、２２ＴＢが、ＴＩＥＲ０の理想的な使用容量（仮想領域に割り当てられるセグメントの総記憶容量）であると算出される。以下、同様に、ＴＩＥＲ１とＴＩＥＲ２についても、Ｘ年４月での理想的な使用容量が計算され、その結果が、容量推移履歴テーブル２５８０のＸ年４月のレコードに追記される。【００９４】
管理者の中止指示、セグメントマイグレーションプログラム１５４０の停止、或いは、容量予測（１）プログラム２５４０の停止等により（つまり任意のタイミングで）、図１２に示す処理が終了して良い。【００９５】
＜処理説明：容量予測（１）概要＞。【００９６】
図１３は、容量予測（１）プログラム２５４０の処理のフローチャートである。【００９７】
例えば、予め設定したスケジュールに従うタイミング、または、管理者が指定したタイミングで、本処理が開始される。【００９８】
まず、ステップ４０１０において、容量予測（１）プログラム２５４０は、容量閾値Ｔｈ１、目標性能Ｔｈ２及び予測期間Ｔの入力を管理者から受け付ける。容量閾値Ｔｈ１は、プールの使用容量（使用セグメントの総記憶容量）と比較される値である。目標性能Ｔｈ２は、プールの性能（例えば平均レスポンスタイム）と比較される値である。予測期間Ｔは、現在から将来のどの時点での増設量を算出するかを意味する値である。予測期間Ｔが１ヶ月で、現在が２００９年４月であれば、２００９年５月での増設量が算出される。なお、容量閾値Ｔｈ１、目標性能Ｔｈ２及び予測期間Ｔのうちの少なくとも１つは、出荷時等に初期設定しておくことでステップ４０１０が省略されてもよい。また、これらの初期値を入力するためのＧＵＩの表示例は後に述べる。
その後、ステップ４０２０に示すように、ステップ４０３０およびステップ４０４０の処理が、例えば定期的に行われる。【００９９】
ステップ４０３０で、プログラム２５４０は、構成情報取得プログラム２５２０を用いて取得されたプール状況情報（例えば、仮想ボリューム管理テーブル１５７０）と、ＩＯＰＳ性能評価テーブル２５７０とを基に、プールの使用容量及び性能（例えば平均レスポンスタイム）を算出する。プログラム２５４０は、プールの使用容量が容量閾値Ｔｈ１を超えたか否か、及び、プールの性能が目標性能Ｔｈ２を超えたか否かを判断する。【０１００】
ステップ４０３０の判断の結果が肯定的の場合、具体的には、プールの使用容量が容量閾値Ｔｈ１を超えた、又は、プールの性能が目標性能Ｔｈ２を下回った場合（例えば、平均レスポンスタイムが目標性能Ｔｈ２を超えた長い時間となった場合）、ステップ４０４０が実行される。すなわち、プログラム２５４０は、増設量の予測および結果の表示処理を行う。この処理については、図１４を用いて後に説明する。【０１０１】
ステップ４０２０で示すループにおいて、任意のタイミングで管理者の中止指示、またはセグメントマイグレーションプログラム１５４０の停止により、容量予測（１）プログラム２５４０の処理が終了して良い。【０１０２】
図１４は、図１３のステップ４０４０の処理のフローチャートである。【０１０３】
ステップ４０４２で、プログラム２５４０は、容量推移履歴テーブル２５８０を基に、各メディアの使用容量の増加率を算出する。プログラム２５４０は、各メディアの使用容量の増加率を基に、現在から予測期間Ｔ後の時点について、メディア毎の使用容量を予測する。予測方法の例については、後述する。【０１０４】
ステップ４０４３に示すように、各メディア（ＴＩＥＲ  Ｘ（Ｘ＝０、１、…）について、ステップ４０４４からステップ４０４６が行われる。以下、１つのメディアを例に採り（以下、図１４の説明において、「対象メディア」と言う）、ステップ４０４４からステップ４０４６を説明する。【０１０５】
ステップ４０４４で、プログラム２５４０は、対象メディアの現在の容量Ｙが、予測期間Ｔ経過しても不足しないかどうかを判断する。具体的には、プログラム２５４０は、プール容量管理テーブル２５６０を基に、対象メディアの容量Ｙ（対象メディアの容量２５６０が表す容量）が、ステップ４０４２で予測した使用容量Ｚ（対象メディアの使用容量）以上か否かを判断する。【０１０６】
ステップ４０４４の判断の結果が肯定的であれば、プログラム２５４０は、対象メディアには容量追加は不要（対象メディアの増設量＝０）と判断する（ステップ４０４５）。なお、ステップ４０４５において、プログラム２５４０は、対象メディアの増設量＝（Ｚ−Ｙ）と判断しても良い。（Ｚ−Ｙ）の値は負の値となるので、具体的には、プログラム２５４０は、（Ｙ−Ｚ）の容量が対象メディアから除去可能と判断しても良い。【０１０７】
一方、ステップ４０４４の判断の結果が否定的であれば、プログラム２５４０は、対象メディアの増設量＝（Ｚ−Ｙ）と判断する（ステップ４０４６）。【０１０８】
以上のステップ４０４４からステップ４０４６の処理が、各メディアについて行われる。【０１０９】
ステップ４０４７において、プログラム２５４０が、表示（１）プログラム２５５０に、各メディアの判断された増設量を表示させる。表示されるＧＵＩの例を後述する。なお、ステップ４０４７では、各メディアの判断された増設量を表示することに代えて又は加えて、プログラム２５４０が、ストレージ装置１０００で未使用の論理ボリューム（或いは、未使用の論理ボリュームのうちの、増設量に相当する部分）を、その論理ボリュームの種類に対応したメディアに自動的に追加するという処理を行っても良い。【０１１０】
ステップ４０４２からステップ４０４７までの具体例を、図１５を用いて説明する。【０１１１】
図１５の各グラフ９１１０〜９１４０は、横軸９１１１が時刻であり、縦軸９１１２がプール全体または各ＴＩＥＲの容量を示している。グラフ９１１０がプール全体の容量、グラフ９１２０がＴＩＥＲ０の容量、グラフ９１３０、がＴＩＥＲ１の容量、グラフ９１４０が、ＴＩＥＲ２の容量に関するグラフである。また現在が、Ｘ年４月であり、予測期間Ｔ＝１ケ月とする。プールの使用容量が容量閾値Ｔｈ１を超えた場合（又は、プールの性能が目標性能Ｔｈ２を下回った場合）、以下の処理が行われる。【０１１２】
すなわち、容量予測（１）プログラム２５４０は、容量推移履歴テーブル２５８０（図１０参照）を基に、１ケ月後の使用容量を予測することができる。例えば、１次関数を用いて１ケ月後に必要となる容量を予測する場合、ＴＩＥＲ０の使用容量（厳密には、理想的な記憶容量）は、毎月１ＴＢずつ増加していることから、１ケ月後のＸ年５月には、１ＴＢ増加した２３ＴＢになると予測される。ＴＩＥＲ１及びＴＩＥＲ２についても、同様の方法で、Ｘ年５月での使用容量を予測することができる。なお、予測に用いた１次関数の推定には、最小２乗法などの数学的手法を用いることにより、誤差の少ない増加率（使用容量の増加率）を算出することができる。また、予測においては、多次元関数等を用いることにより、精度を向上させることができる。このように、各時点でのメディア毎の使用容量（理想的な記憶容量）が得られたならば、任意の方法で、将来の使用容量を予測することができる（つまり、予測の方法が、１次関数や多次元関数等に限定されるものではない）。【０１１３】
容量推移履歴テーブル２５８０（図１０参照）から特定される使用容量（理想的な記憶容量）の増加率には、周期的な特性がある場合がある。例えば、図１０によれば、ＴＩＥＲ２の使用容量は、基本的には２０ＴＢずつ増加しているが、（Ｘ−１）年４月から５月のみに急激な増加がみられるようなケースがある。この場合、Ｘ年５月の予測に、直近の増加率ではなく、１年前の増加率を用いた方がより精度の高い予測が実現できることがある。例えば、一般的な企業の社員管理データベースの情報を保存するＶＶＯＬを含むプールは、１年のうち、新入社員が入社する４〜５月にかけて急激に容量が拡大し、それ以外の期間には大きな増加をしないと見込まれる。このため、容量予測（１）プログラム２５４０は、周期的な特性を考慮するか否か、または予測に用いる履歴データの期間の指定を、管理者に求めてもよい。【０１１４】
図１５によれば、Ｘ年５月について、ＴＩＥＲ０の予測使用容量（予測された使用容量）Ｚは、ＴＩＥＲ０の容量Ｙ（３０ＴＢ）を超えず、また、ＴＩＥＲ１の予測使用容量Ｚは、ＴＩＥＲ１の容量Ｙ（１１０ＴＢ）を超えない。このため、ＴＩＥＲ０及びＴＩＥＲ１のいずれについても、前述したステップ４０４５で、Ｘ年５月の時点では、増設は不要（増設量＝０）と判断される。【０１１５】
しかし、ＴＩＥＲ２については、予測使用容量Ｚが、５２０ＴＢであるにも関わらず、ＴＩＥＲ２の現在の容量Ｙは５００ＴＢしかなく、故に、前述したステップ４０４６で、増設量は、（Ｚ−Ｙ）＝２０ＴＢと判断される。【０１１６】
以上より、ステップ４０４７において、ＴＩＥＲ０およびＴＩＥＲ１は増設不要、ＴＩＥＲ２に２０ＴＢの増設が必要という結果が、表示される。なお、ＴＩＥＲ０およびＴＩＥＲ１については、（Ｙ−Ｚ）の容量削減が可能という結果が表示されても良い。また、容量削減が可能と言う判断は、（Ｙ−Ｚ）の値が所定値以上の場合にのみされても良い（例えば、その所定値はゼロより大きな値）。【０１１７】
＜表示例＞。【０１１８】
図１６は、図１３のステップ４０１０で表示（１）プログラム２５５０によって表示されるＧＵＩ５１００の例を示す。【０１１９】
ＧＵＩ５１００は、管理者に各設定値の入力を求めるＧＵＩである。ＧＵＩ５１００には、容量閾値Ｔｈ１を入力するためのテキストボックス５１１２や、目標性能Ｔｈ２として監視する目標性能の種類を選択するコンボボックス５１２２と、目標性能Ｔｈ２を入力するテキストボックス５１２３を備える。また容量および性能を監視するか否かを選択するためのチェックボックス５１１１および５１２１を備えてもよい。ここで目標性能５１２２の選択肢としては、プールの平均レスポンスタイムやパーセンタイル値等がある。平均レスポンスタイムとは、１つのＩＯ（コントローラ１１１０からセグメントに対する１つのアクセス）あたりのレスポンスタイムの平均値である。また、例えば、レスポンスタイムの８０パーセンタイル値がＰとは、全体の８０％のレスポンスタイム（１つのＩＯあたりのレスポンスタイム）がＰ以下であることを意味する値である。加えて、ＧＵＩ５１００は、予測期間Ｔを入力するために、テキストボックス５１３２と期間の単位を選択するためのコンボボックス５１３３を備える。加えて、ユーザが直接入力するか、システムが持つ適当な期間の値、例えばセグメントマイグレーションの間隔、を用いるかを選択するためのラジオボタン５１３１を備えてもよい。このほか予測に周期的な予測を入れるかを選択させるチェックボックス５１４１や、予測期間を指定するテキストボックスを備えてもよい。また入力を確定するためのボタン５１５１や取り消すためのボタン５１５２等を備えてもよい。【０１２０】
Ｋパーセンタイル値がレスポンスタイムでＶｍｓ（ミリ秒）と指定された場合、想定レスポンスタイムがＶｍｓ以下である全てのメディアの全ての使用セグメントのＩＯＰＳの合計が、プールの全ての使用セグメントのＩＯＰＳの合計のＫパーセントを下回った場合には、図１３のステップ４０３０でＹＥＳとなる。すなわち、想定レスポンスタイムがＶｍｓ以下のセグメントが増加（つまり、高性能なメディアを使用したセグメントの割合が増加）した場合、全体として性能は向上となる。一方、想定レスポンスタイムがＶｍｓ以下となるセグメントの割合がＫパーセントを下回る（つまり、想定レスポンスタイムがＶｍｓ以上のセグメントが増加した場合、全体として性能が悪化となる。なお、ストレージが、Ｃ−ＩＦ上でリード要求から実際にデータが返されるまでに生じる実測のレスポンスタイムを監視し、任意の一定期間でレスポンスタイムがＶｍｓ以下のリード要求回数がＫパーセントを超えた場合に、ステップ４０３０でＹＥＳとなるようにしても良い。また、レスポンスタイムは、実測値であっても良い。【０１２１】
図１７は、図１４のステップ４０４７で表示されるＧＵＩ５２００の例を示す。【０１２２】
ＧＵＩ５２００は、ＴＩＥＲ毎に必要となる増設量を管理者に通知するためのＧＵＩである。ＧＵＩ５２００では、予測期間Ｔ後の予測であることを示すテキスト５２０１を表示し、各増設量を表示するためのテーブル５２１１を備える。テーブル５２１１には、各ＴＩＥＲおよび対応するリソース種別毎に必要となる増設量を示す。またテーブル５２１１の代わりに、ストレージ装置内で使用可能であり、かつ、増設量を満足する論理ボリュームの一覧が表示されてもよい。また、管理者が上記の内容を了解しＧＵＩ５２００を閉じるために用いるボタン５２３１が備えられてもよい。【０１２３】
加えて、ＧＵＩ５２００は、Ｉｎｆｏｒｍａｔｉｏｎエリア５２２１において、テーブル５２１１に示した増設量が必要となる理由の説明するテキストが表示されてもよい。例えば、高位のＴＩＥＲに記憶容量（論理ボリューム）を増設するか否かを判断基準として、Ｉｎｆｏｒｍａｔｉｏｎエリア５２２１に表示されるテキストが次のように決定されて良い。まず、最高位ＴＩＥＲであるＴＩＥＲ０の増設量が０か否かを判断し、ＴＩＥＲ０の増設量が０の場合は、高性能なＴＩＥＲは十分にあり今回の増設では低性能なＴＩＥＲの増設のみでも性能が十分であることを表すテキストが表示されて良い。一方で、ＴＩＥＲ０の増設が必要な場合、つまり増設量が０でない場合は、高頻度でアクセスされる領域が拡大されており性能維持のため高性能なＴＩＥＲの増設が必要であることを表すテキストが表示されてよい。３種類以上のＴＩＥＲがプールに存在する場合でも、最高位ＴＩＥＲか否かや増設費用の観点からＴＩＥＲを分類した上で前述のような処理が適用されてよい。これによりＩｎｆｏｒｍａｔｉｏｎエリア５２２１に表示するテキスト（文言）を決定することができる。
【実施例２】
【０１２４】
以下、本発明の実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。【０１２５】
＜概要＞。【０１２６】
実施例１では、あらかじめ用意しておいたＩＯＰＳ評価テーブル２５６０を用いて、メディア毎に使用容量の増加率が算出され、メディア毎の使用容量の増加率を基に、メディア毎に増設量が算出される。【０１２７】
本発明の実施例２では、目標性能と、メディアの容量を増設する際のコスト（以下、増設コスト）とを基に、目標性能以上の性能が出る範囲で増設コストが最も小さくなるような増設量が決定される。【０１２８】
＜構成説明＞。【０１２９】
実施例２に係るストレージシステムの物理的な構成は、図１に示した構成と同じで良い。管理計算機２０００内のメモリ２５００に記憶されるプログラムが実施例１のプログラムと異なる。【０１３０】
図１８は、実施例２に係るメモリ２５００が記憶するプログラム及び情報を示す。【０１３１】
構成管理プログラム２５１０、構成情報取得プログラム２５２０、ＩＯＰＳ性能評価テーブル２５７０、プール容量管理テーブル２５６０は実施例１と同じものである。ただし、ＩＯＰＳ性能評価テーブル２５７０において、許容ＩＯＰＳ範囲２５７３は含んでいなくてもよいが、想定レスポンスタイム２５７４は含まれている必要がある。【０１３２】
上記プログラムおよび情報に加えて、実施例２に係るメモリ２５００は、ＩＯＰＳ毎のセグメント数の推移を予測するセグメントＩＯＰＳ予測プログラム２６１０、将来的に必要となるＴＩＥＲ毎の増設量を予測する容量予測（２）プログラム２６２０、初期設定値の入力ためのＧＵＩや増設量を通知するためのＧＵＩを表示する表示（２）プログラム２６３０、セグメントＩＯＰＳ分布履歴テーブル２６４０、及び、増設パターン保持テーブル２６５０を記憶する。ただし、増設パターン保持テーブル２６５０は、便宜上用いるテーブルであって、一時的に記憶されれば良い。【０１３３】
図１９は、セグメントＩＯＰＳ分布履歴テーブル２６４０の例を示す。【０１３４】
セグメントＩＯＰＳ分布履歴テーブル２６４０は、使用セグメント数のＩＯＰＳに基づく分布を表す。具体的には、例えば、テーブル２６４０の横軸はＩＯＰＳ２６４３を表し、縦軸は時刻２６４１を表し、行と列の交点である各セル２６４４には、セグメント数を表す情報が格納される。例えば、Ｘ年４月においてＩＯＰＳが１００であるセグメントの数は、６２００であることがわかる。また、将来の時刻２６４２における、ＩＯＰＳ別のセグメント予測数（予測されるセグメントの数）２６４５を、便宜上、ｎ［ＩＯＰＳ数］、と書くこととする。なお、ＩＯＰＳ数２６４３は、１刻みの他に、特定の範囲単位（例えば、１０ＩＯＰＳ単位）であっても良い。また、セグメントＩＯＰＳ分布履歴テーブル２６４０の作成および更新方法については、後述するセグメントＩＯＰＳ予測プログラムの処理の流れの中で説明する。【０１３５】
図２０は、増設パターン保持テーブル２６５０の例を示す。【０１３６】
増設パターン保持テーブル２６５０は、容量の増設パターンに関する情報を有する。具体的には、テーブル２６５０は、増設パターン毎に、下記の情報、
＊各メディアの割合に関連したパラメータを表すパラメータ２６５１、
＊パラメータ２６５１を実現するようにプールの容量を増設した場合に生じる増設コストを表す増設コスト２６５２、
＊その時に期待される性能を表す想定性能２６５３、
を有する。パラメータ、増設コスト、具体的な算出方法および利用方法については、後述する容量予測（２）プログラム２６２０の処理の流れで説明する。【０１３７】
ここで、パラメータの意味について、図２１を用いて説明する。【０１３８】
図２１に示すグラフ９２００において、横軸９２０２はＩＯＰＳであり、縦軸９２０１はセグメント数である。そして、曲線９２０３は、ＩＯＰＳ９２０２毎のセグメント数を示している。【０１３９】
パラメータとして、ＡとＢがある（Ａ＜Ｂ）。２つのパラメータＡ及びＢは、どのＩＯＰＳのセグメント内のデータはどのメディアに配置されるべきかを定義するためのものである。【０１４０】
具体的には、ＩＯＰＳがＡ以下のセグメント内のデータはＴＩＥＲ２に配置され、ＩＯＰＳがＢ以上のセグメント内のデータはＴＩＥＲ０に配置され、ＩＯＰＳがＡより大きくＢより小さいＩＯＰＳのセグメント内のデータはＴＩＥＲ１に配置される。この場合、ＴＩＥＲ０に割り振られるべきセグメント数は領域９２０４の面積で表され、ＴＩＥＲ１に割り振られるべきセグメント数は領域９２０５の面積で表され、ＴＩＥＲ２に割り振られるべきセグメント数は領域９２０６の面積で表される。なお、ＴＩＥＲが４つ以上ある場合は、パラメータの数を３以上に増やすことで対応可能となる。【０１４１】
また、本実施例２では、図２０に示した増設コスト２６５２は、容量増設に必要となる金額として示している。しかし、増設コストは、金額に限らず、増設によって増加する消費電力量などであってもよい。想定性能２６５３は、ＩＯＰＳ性能評価テーブル２５７０の想定レスポンスタイム２５７４と各ＴＩＥＲに割り振られるべきセグメントのＩＯＰＳにより導出される、想定される平均レスポンスタイムである。つまり、想定性能２６５３は、下記の式、
（想定性能２６５３）＝
｛（１ｍｓ（ミリ秒）×（図２０でＴＩＥＲ０となったセグメントのＩＯＰＳの総和）＋
１０ｍｓ×（図２０でＴＩＥＲ１となったセグメントのＩＯＰＳの総和）＋
１００ｍｓ×（図２０でＴＩＥＲ２となったセグメントのＩＯＰＳの総和）｝
÷（全セグメントの総ＩＯＰＳ）、
で算出することができる。この他、想定性能は、レスポンスタイムのパーセンタイル値であってもよい。また想定レスポンスタイムは、ＴＩＥＲが３種類以上の場合であっても、前述と同様の方法で算出することが出来る。【０１４２】
＜処理説明：セグメントＩＯＰＳ予測＞
図２２は、セグメントＩＯＰＳ予測プログラム２６１０の処理のフローチャートを示す。【０１４３】
例えば、予め設定したスケジュールに従うタイミング、または、管理者が指定したタイミングで、処理が開始される。【０１４４】
ステップ４４１０に示すように、セグメントＩＯＰＳ予測プログラム２６１０は、一定間隔で、ステップ４４２０からステップ４４６０までの処理を繰り返す。なお、ここで言う「一定間隔」とは、例えば、ストレージ装置１０００のセグメントマイグレーションプログラム１５４０が行うセグメントマイグレーションの開始間隔であってもよいし、管理者が指定した任意の間隔等であってもよい。【０１４５】
ステップ４４２０において、プログラム２６１０は、構成情報取得プログラム２５２０を用いて、ストレージ装置１０００から仮想ボリューム管理テーブル１５７０を取得する。【０１４６】
次に、ステップ４４３０において、プログラム２６１０は、取得した仮想ボリューム管理テーブル１５７０のＩＯＰＳ１５７６を基に、ＩＯＰＳ毎にセグメント数をカウントする。そして、ステップ４４４０において、プログラム２６１０は、ステップ４４３０でカウントした、ＩＯＰＳ毎のセグメント数を用いて、セグメントＩＯＰＳ分布履歴テーブル２６４０を更新する。なお、前述のように、ＩＯＰＳの範囲毎に、セグメント数がカウントされても良い。【０１４７】
ステップ４４５０において、プログラム２６１０は、ステップ４４４０で更新されたセグメントＩＯＰＳ分布履歴テーブル２６４０を用いて、後述する容量予測（２）プログラムで指定された予測期間Ｔ後のＩＯＰＳ毎のセグメント数を予測する。ステップ４４６０において、プログラム２６１０は、その予測結果を、セグメントＩＯＰＳ分布履歴テーブル２６４０に追記する。【０１４８】
例えば、図１９に示したセグメントＩＯＰＳ分布履歴テーブル２６４０によれば、現在がＸ年４月である場合、ＩＯＰＳが１００であるセグメント数は、１ケ月あたり１００ずつ増加している。図１４のステップ４０４２と同様に、１次関数に基づく予測が行われる場合、１ケ月後であるＸ年５月のセグメント数の予測値ｎ［１００］は６３００と予測される。予測方法については、実施例１と同様、１次関数に限らず多次元関数を用いる等の種々の方法が考えられる。このようにして、将来のセグメント数の予測値２６４５であるｎ［ＩＯＰＳ数］を求めることができる。【０１４９】
管理者の中止指示、セグメントマイグレーションプログラム１５４０の停止、或いは、セグメントＩＯＰＳ予測プログラム２６１０の停止等により（つまり任意のタイミングで）、図２２に示す処理が終了して良い。【０１５０】
＜処理説明：容量予測（２）プログラム＞。【０１５１】
図２３は、容量予測（２）プログラム２６２０の処理のフローチャートを示す。【０１５２】
例えば、予め設定したスケジュールに従うタイミング、または、管理者が指定したタイミングで、処理が開始される。【０１５３】
まず、ステップ４３１０において、容量予測（２）プログラム２６２０は、容量閾値Ｔｈ１、目標性能Ｔｈ２、および、各ＴＩＥＲのメディアを増設する際に発生する単位容量あたりの増設コストＣの入力を管理者に求める。加えて、プログラム２６２０は、予測期間Ｔの入力も求める。そして、プログラム２６２０は、入力された予測期間Ｔを、セグメントＩＯＰＳ予測プログラム２６１０に通知する。なお、容量閾値Ｔｈ１、目標性能Ｔｈ２、増設コストＣ及び予測期間Ｔは、出荷時等に初期設定しておくことで、ステップ４３１０が省略されてもよい。また、増設コストＣは、単位容量あたりのメディアを増設する際に発生する費用又は消費電力を指すものとする。【０１５４】
ステップ４３２０に示すように、ステップ４３３０およびステップ４３４０の処理が、例えば定期的に行われる。【０１５５】
ステップ４３３０で、プログラム２６２０は、構成情報取得プログラム２５２０を用いて取得されたプール状況情報（例えば、仮想ボリューム管理テーブル１５７０）と、増設パターン保持テーブル２６５０とを基に、プールの使用容量及び性能（例えば平均レスポンスタイム）を算出する。プログラム２５４０は、プールの使用容量が容量閾値Ｔｈ１を超えたか否か、及び、プールの性能が目標性能Ｔｈ２を超えたか否かを判断する。【０１５６】
ステップ４３３０の判断の結果が肯定的の場合、具体的には、プールの使用容量が容量閾値Ｔｈ１を超えた、又は、プールの性能が目標性能Ｔｈ２を下回った場合（例えば、平均レスポンスタイムが目標性能Ｔｈ２を超えた長い時間となった場合）、ステップ４３４０が実行される。すなわち、プログラム２６２０は、増設量の予測および結果の表示処理を行う。この処理については、図２４を用いて後に説明する。【０１５７】
ステップ４３２０で示すループにおいて、任意のタイミングで管理者の中止指示、またはセグメントマイグレーションプログラム１５４０の停止により、容量予測（２）プログラム２６２０の処理が終了して良い。【０１５８】
図２４及び２５は、図２３のステップ４３４０の処理のフローチャートである。ここでは、ＴＩＥＲが３種類の例について述べることとする。なおＴＩＥＲが４種類上であっても、前述のパラメータの数を増やすことにより、同様に算出することが可能である。【０１５９】
ステップ４３４２において、容量予測（２）プログラム２６２０が、増設パターン保持テーブル２６５０を初期化する（ブランクにする）。加えて、プログラム２６２０が、パラメータＡとＢを用いて、各ＴＩＥＲに割り当てられるべきセグメント数を分類する。【０１６０】
ステップ４３４３及びステップ４３４４は、ＡはＢより小さい（Ａ＜Ｂ）という条件が成立する全ての（Ａ、Ｂ）において、ステップ４３４５からステップ４３４７が実行することを示している。以下、１つの（Ａ、Ｂ）を例に採り（図２４の説明で「対象（Ａ、Ｂ）」と言う）について、ステップ４３４５からステップ４３４７を説明する。【０１６１】
ステップ４３４５において、プログラム２６２０が、対象（Ａ、Ｂ）に基づく、プールの想定性能Ｋを、ＩＯＰＯＳ性能評価テーブル２５６０と、セグメントＩＯＰＳ分布履歴テーブル２６４０における、各ＩＯＰＳにおけるセグメント予測数２６４５とを基に、算出する。例えば、想定性能がプールの平均レスポンスタイムである場合、図２１を参照して説明したような想定性能Ｋ：
想定性能＝
｛（１ｍｓ×（図２０でＴＩＥＲ０となったセグメントのＩＯＰＳの総和）＋
１０ｍｓ×（図２０でＴＩＥＲ１となったセグメントのＩＯＰＳの総和）＋
１００ｍｓ×（図２０でＴＩＥＲ２となったセグメントのＩＯＰＳの総和））｝
÷（全セグメントの総ＩＯＰＳ）
で求めることができる。【０１６２】
次に、ステップ４３４６において、プログラム２６２０が、ステップ４３４５で算出した想定性能Ｋが目標性能Ｔｈ２より優れているか（つまりＫ＜Ｔｈ２）か否かを判断する。【０１６３】
ステップ４３４６の判断の結果が否定的の場合、プログラム２６２０は、次の（Ａ、Ｂ）について、ステップ４３４５以降を行う。【０１６４】
一方、ステップ４３４６の判断の結果が肯定的の場合、プログラム２６２０が、対象（Ａ、Ｂ）と想定性能Ｋ、および対象（Ａ、Ｂ）から求められる増設コストＪを、増設パターン保持テーブル２６５０に追記する。その後、次の（Ａ、Ｂ）についてステップ４３４５以降が行われる。【０１６５】
ここで、増設コストＪは、ステップ４３１０で設定された各メディアの増設コストＣを用いることで、算出することができる。具体的には、下記の式、
増設コストＪ＝
（ＴＩＥＲ０の増設コスト）×（ＴＩＥＲ０の増設量）＋
（ＴＩＥＲ１の増設コスト）×（ＴＩＥＲ１の増設量）＋
（ＴＩＥＲ２の増設コスト）×（ＴＩＥＲ２の増設量）
である。ここで、例えば、ＴＩＥＲ０の増設量は、下記の式、
ＴＩＥＲ０の増設量＝
（（図２１の領域９２０４の面積）×１００ＭＢ）−
（プール容量管理テーブル２５６０のＴＩＥＲ０の容量）
で計算することができる。ＴＩＥＲ１及びＴＩＥＲ２の増設量も同様に計算することができる。なお、増設量が正の値か否かのみしか考えない場合、増設量が負の値であるＴＩＥＲについては、増設コストＪの計算式から除外されて良い。【０１６６】
全ての（Ａ、Ｂ）について、ステップ４３４３及び４３４４に示すループが行われた後、図２５に示す処理が行われる。【０１６７】
ステップ４３５０において、プログラム２６２０が、増設パターン保持テーブル２６５０が空か否か判断する。【０１６８】
ステップ４３５０の判断の結果が肯定的の場合、目標性能を実現するような増設パターンが存在しないということになる。このため、ステップ４３５１に示すように、プログラム２６２０は、表示（２）プログラム２６３０を用いて、目標性能等の再設定を求めるＧＵＩを表示する。または、再度、ステップ４３４１から処理が行われても良い。【０１６９】
一方、ステップ４３５０の判断の結果が否定的の場合、ステップ４３５３において、プログラム２６２０は、増設パターン保持テーブル２６５０から、最も増設コストが小さい（Ａ、Ｂ）（すなわち、パラメータの組み合わせ）を求める。【０１７０】
次に、ステップ４３５４において、プログラム２６２０は、ステップ４３５３で求めた（Ａ、Ｂ）を用いて、セグメント予測数２６４５から、予測期間Ｔ後の時点における、各ＴＩＥＲの使用容量を求める。そして、プログラム２６２０は、各ＴＩＥＲの使用容量（予測値）と各ＴＩＥＲの現在の使用容量とを基に、図２１を参照した説明したような、各ＴＩＥＲの増設量を算出する。【０１７１】
そして、ステップ４３５５およびステップ４３５６において、プログラム２６２０は、全てのＴＩＥＲの増設量が正の値か否かを判断する。【０１７２】
ステップ４３５６の判断の結果が否定的の場合（すなわち、いずれか１つの増設量がゼロ以下の場合）、ステップ４３５７において、プログラム２６２０は、当該（Ａ、Ｂ）を採用しないものとし、増設パターン保持テーブル２６５０から、当該（Ａ、Ｂ）を有するレコードを除去し、ステップ４３５３に戻る。【０１７３】
一方、ステップ４３５６の判断の結果が肯定的の場合、ステップ４３５８行われる。なお、ステップ４３５８において、増設量が負の場合を除いて増設パターン保持テーブル２６５０を作成している場合は、ステップ４３５５およびステップ４３４６の処理は不要となる。【０１７４】
そして、ステップ４３５８において、プログラム２６２０は、図２４及び図２５に示す処理で求められた、ＴＩＥＲ毎の増設量を有するＧＵＩを、表示（２）プログラム２６３０に表示させる。なお、ステップ４３５８は、ＴＩＥＲ毎の増設量を表示することに代えて又は加えて、プログラム２６２０が、ストレージ装置１０００で未使用の論理ボリュームを、その論理ボリュームの種類に対応したメディアに自動的に追加するという処理を行っても良い。【０１７５】
＜表示例＞。【０１７６】
図２６は、図２３のステップ４３１０で表示（２）プログラム２６３０によって表示されるＧＵＩ５３００の例を示す。【０１７７】
ＧＵＩ５３００には、容量閾値Ｔｈ１を入力するためのテキストボックス５３１１と、目標性能Ｔｈ２として監視する目標性能の種類を選択するコンボボックス５３２２と、その値を入力するテキストボックス５３２３を備える。加えて、目標性能を直接指定するか、現状の性能を維持することを目標性能とするかを選択するためのラジオボタン５３２１が備えられても良い。ここで、目標性能５１２２の選択肢としては、プール全体の平均レスポンスタイムやパーセンタイル値等がある。加えて、ＧＵＩ５３００は、予測期間Ｔを入力するために、テキストボックス５３３２と期間の単位を選択するためのコンボボックス５３３３を備える。ユーザが直接入力するか、システムが持つ適当な期間の値、例えばセグメントマイグレーションの間隔、を用いるかを選択するためのラジオボタン５３３１が備えられてもよい。このほか、予測に周期的な予測を入れるかを選択させるチェックボックス５３４１や、予測期間を指定するテキストボックスが備えられてもよい。そして、各ＴＩＥＲの増設コストＣを指定するためのテキストボックス５３５１が備えられる。入力単位は、増設に係る費用の他に消費電力などであってもよい。また入力を確定するためのボタン５３６１や取り消すためのボタン５３６２等が備えられてもよい。【０１７８】
図２７は、図２５のステップ４３５８で表示されるＧＵＩ５４００の例を示す。【０１７９】
図１７に示したＧＵＩ５２００の表示に加え、実施例２では、想定性能および増設で発生する増設コストを表示するテーブル５２２１の表示が可能である。なお、テーブル５２２１に表示される値は、増設パターン保持テーブル２６５０を参照することで表示することができる。また別の表示方法として、増設パターン保持テーブル２６５０にある全ての増設方法が、テーブル５２１１とテーブル５２２１の表示する要素、少なくともＴＩＥＲ毎の増設量と増設コストまたは想定性能を一つのテーブルとして、増設コスト順または想定性能順に表示されてもよい。【０１８０】
＜実施例２のバリエーションの例＞。【０１８１】
なお、実施例２のステップ４３４０は、目標性能および増設コストを基に増設量が算出される。これを、管理者が望む任意のタイミングで実施可能とすることにより、以下に述べるユースケースがサポートされてもよい。【０１８２】
第一に、管理者によってプールの目標性能が指定されており、その目標性能を満足する各メディアの増設量が、増設コストとともに表示されてよい。管理者は、目標性能の指定と、算出される増設コストの表示を繰り返すことにより、目標性能と増設コストを両立するメディア（ＴＩＥＲ）毎の増設量を得ることが出来る。【０１８３】
第二に、管理者によって、増設により必要となる増設コストが指定されることにより、指定された増設コストを満足する各メディアの増設量と、そのときの想定性能を見積もることが出来る。これにより、管理者は、望んだ増設コストの範囲内で実現可能な各メディアの増設量と、そのときの性能を得ることが出来る。【０１８４】
実施例２のステップ４３４０では、与えられた目標性能を満足する制約のもとで、増設コストが最小となる各ＴＩＥＲの増設量が決定される、最適化問題（optimization problem）とみなすことができる。つまり、以下のような問題に書き直すことができる。ｎ［ｘ］をＩＯＰＳがｘのときのセグメント数、パラメータＡをＴＩＥＲ１とＴＩＥＲ２の境界となるＩＯＰＳ、パラメータＢをＴＩＥＲ０とＴＩＥＲ１の境界となるＩＯＰＳとする。また定数値Ｃ０、Ｃ１、Ｃ２を、それぞれ、ＴＩＥＲ０、ＴＩＥＲ１、ＴＩＥＲ２の単位容量を増設したときの増設コストとし、定数値ｒ０、ｒ１、ｒ２を、それぞれ、ＴＩＥＲ０、ＴＩＥＲ１、ＴＩＥＲ２の想定レスポンスタイムとし、変数Ｊ０、Ｊ１、Ｊ２を、それぞれ、増設前のＴＩＥＲ０、ＴＩＥＲ１、ＴＩＥＲ２の容量とし、変数ｒを、ユーザが設定した目標性能とする。目標関数（コスト）は、次の数１に従い、制約は、次の数２及び数３に従う。【０１８５】
【数１】
2011092739.tif 000003
【０１８６】
【数２】
2011092739.tif 000004
【０１８７】
【数３】
2011092739.tif 000005
上記の問題は、パラメータＡ、Ｂを変数とする最適化問題とみなせる。ＴＩＥＲが増えた場合は、パラメータ数が増えることとなる。上記の問題は、非線形の凸計画問題（non-linear convex programming problem）となるため、図２４及び図２５を参照して説明した方法以外に、例えば次のような方法を用いることも出来る。ｎ［ｘ］が微分可能関数(differentiable function)に近似できる場合は、ペナルティ法（penalty method）や逐次二次計画法（sequential quadratic programming method）により計算することが出来る。またｎ［ｘ］が微分可能関数に近似できない場合であっても、離散計画問題（Discreate Programming Problem）で研究されている各種手法を用いることで効率よく計算することが出来る可能性がある。なお上記の問題の解法は本発明の技術的範囲を限定するものではない。【０１８８】
また、実施例１と実施例２では、単一プールを扱っているが、プール内に複数のサブプールが存在する場合は、それらサブプール毎に、実施例１及び実施例２に従う技術が適用しても良い。ここで、「サブプール」とは、プール内のプールボリュームをグループ分けしたものである。例えば、特定のＶＶＯＬが使うプールボリュームを制限する際に、ＶＶＯＬとサブプールを対応付け、サブプールからその特定のＶＶＯＬへセグメントが割り当てられる。
【実施例３】
【０１８９】
本発明の実施例３を説明する。その際、実施例１及び／又は実施例２との相違点を主に説明し、実施例１及び／又は実施例２との共通点については説明を省略或いは簡略する。【０１９０】
＜概要＞。【０１９１】
実施例１および実施例２では、セグメントのアクセス頻度（ＩＯＰＳ）が考慮され、各ＴＩＥＲの適切な増設方法について説明した。実施例３では、実施例２で説明した想定性能が目標性能を上回っている場合（例えば、高性能なＴＩＥＲが過剰である場合）、目標性能を達成しつつ高性能なメディアの容量がプールから除去されその容量が別の用途に使用される。これにより、ストレージ装置全体として記憶領域を有効に活用することができる。なお、実施例３のハードウェア的な構成は、実施例２と同じである。【０１９２】
＜処理説明＞。【０１９３】
実施例３で行われる処理は、実施例２で行われる処理のうち、図２５に示したステップ４３５６以降が異なるのみである。よって、図２８を参照して、ステップ４３５６以降について説明する。【０１９４】
プログラム２６２０は、ステップ４３５６により求めたＴＩＥＲ  Ｘ（Ｘ＝０、１、…）の増設量が正の場合、ＴＩＥＲ  Ｘは増設が必要と判断する（ステップ４３７１）。一方、ＴＩＥＲ  Ｘの増設量がゼロ以下の場合、ステップ４３７２において、プログラム２６２０は、ＴＩＥＲ  Ｘは減設可能と判断し、ＴＩＥＲ  Ｘの減設量を、ＴＩＥＲ  Ｘの増設量の絶対値とする。各ＴＩＥＲについて、上記処理を行った後、ステップ４３７３において、プログラム２６２０は、表示（２）プログラム２６３０に、その結果を有するＧＵＩを表示させる。なお、ステップ４３７３では、結果を有するＧＵＩを表示することに代えて又は加えて、自動的に論理ボリューム増減設が行われてもよい。【０１９５】
図２９は、図２８のステップ４３７３で表示されるＧＵＩ５５００の例を示す。【０１９６】
ＧＵＩ５５００では、増設量を表示するテーブル５５１１に加え、減設量を表示するテーブル５５２１が表示される。加えて、その時の想定性能を表示するテーブル５５３１も表示される。なお、実施例２と同じく、増設コストが、想定性能と併記されてもよい。
【実施例４】
【０１９７】
＜概要＞。【０１９８】
実施例１〜３では、増設量が計算される。その増設量は、予測された使用容量に基づく値のため、実施例１〜３で算出された増設量通りの容量増設が行われても、性能低下又は容量不足が生じる可能性が無いわけではない。そこで、実施例４では、実施例１〜３で算出された増設量通りの容量増設が行われた後に性能低下または容量不足が発生した際の原因分析が行われる。【０１９９】
＜構成説明＞。【０２００】
ハードウェア的な構成は、実施例１または実施例２と変わらない。管理計算機２０００内のメモリ２５００内に含まれるプログラムが異なる。具体的には、図３０に示すように、実施例４では、メモリ２５００に、プール性能監視プログラム２７００が存在する。なお、プール性能監視プログラム２７００は、実施例１や実施例３のメモリ２５００内に存在してもよい。【０２０１】
＜処理説明＞。【０２０２】
図３１は、プール性能監視プログラム２７００の処理のフローチャートを示す。【０２０３】
図３１では、性能監視の例が挙げられている。「性能」を「容量」と読み替えることにより、容量監視にも適用することが出来る。なお、実施例４では、前述の通り、実施例１〜３に示した方法で、容量の増設を行ったことを前提としている。前述の容量予測プログラムの開始や、管理者が指定したタイミング（つまり任意のタイミング）で、処理が開始される。【０２０４】
ステップ４５１０において、プール性能監視プログラム２７００は、構成情報取得プログラム２５２０を用いて、ストレージ装置１０００のプールの実測性能値を取得する。ここでの「実測性能値」とは、後述する目標性能値と同じ指標であり、プール内の各セグメントに対するＩＯの実測レスポンスタイム値や、ホスト計算機に提供しているＶＶＯＬに対するＩＯの実測レスポンスタイム値を用いて算出することが出来る。【０２０５】
ステップ４５２０において、プログラム２７００は、ステップ４５１０で取得した前述の実測性能値を、ステップ４３１０等で指定された目標性能と比較し、実測性能値が目標性能より劣っている場合は（例えば、レスポンスタイムが目標のレスポンスタイムより長くなっている場合は）、ステップ４５３０に進む。実測性能値が目標性能と同じか良い場合は、ステップ４５１０に戻り、監視が続けられる。【０２０６】
ステップ４５３０では、プログラム２７００は、構成情報取得プログラム２５２０を用いて、現在のプールのセグメント毎のＩＯＰＳを、仮想ボリューム管理テーブル１５７０より取得する。そして、プログラム２７００は、予測結果が格納されているセグメントＩＯＰＳ分布履歴テーブル２６４０と、前記取得した現在のプールから算出したＩＯＰＳ毎のセグメント数と比較を行う。比較を行った結果、現在のプールから取得したＩＯＰＳ毎のセグメント数の方が、セグメントＩＯＰＳ分布履歴テーブル２６４０のＩＯＰＳ毎のセグメント予測数２６４５より大きい場合は、ステップ４５５０が行われる。そうでない場合は、予測の範囲内に収まっていると判断し、ステップ４５４０が行われる。【０２０７】
ステップ４５４０が行われるということは、セグメント数の増加は予測の範囲内であるが性能が低下しているということである。このため、ステップ４５４０において、プログラム２７００は、プールとホスト計算機３０００間の間に原因があることが想定されることを表す情報を表示する（その情報を管理者に通知する）。または、プールとホスト計算機３０００の状態を解析するプログラム（図示せず）を管理計算機２０００が備える場合には、プログラム２７００が、その解析プログラムを起動し、解析プログラムに原因分析処理を継続させてもよい。【０２０８】
一方、ステップ４５５０が行われるということは、予測値を上回るＩＯＰＳまたはセグメント数の増加があったということである。このため、プログラム２７００は、その結果を有するＧＵＩを表示する。【０２０９】
図３２は、図３１のステップ４５５０で表示されるＧＵＩ５７００の例を示す。【０２１０】
ＧＵＩ５７００には、ステップ４５５０に述べた分析結果を示すテキスト５７１０と、予測値の線５７２３と実測値の線５７２４の差異を示すグラフ５７２０とを備える。グラフ５７２０は、横軸５７２２が時間であり、縦軸５７２１が容量である。なお、横軸５７２１の容量はセグメント数であってもよい。また、グラフ５７２０は、ＩＯＰＳ毎のセグメント数を示すのではなく、ステップ４５３０において、範囲外と判断されたＩＯＰＳ部分、またはＩＯＰＳ性能評価テーブル２５７０の許容ＩＯＰＳ範囲２５７３の範囲ごとに示すことができる。また管、理者が確認した際に押下するボタン５７３０が備えられてもよい。
【実施例５】
【０２１１】
＜概要＞。【０２１２】
実施例１〜４では、プールの各ＴＩＥＲの容量予測が、管理計算機２０００内で行われるが、本発明の実施例５では、容量予測処理が、ストレージ装置１０００内で実施される。【０２１３】
＜構成説明＞。【０２１４】
実施例５に係るハードウェア的な構成は、図１に示した構成と同じである。【０２１５】
図３３は、管理計算機２０００内のメモリ２５００に記憶されるプログラム及び情報を示す。【０２１６】
実施例５では、ストレージ装置１０００により、各処理が実行されるため、メモリ２５００内には、プログラムとして、前述の構成管理プログラム２５１０があればよい。加えて、実施例１や実施例２で述べた表示（1）プログラム２５５０や、表示（２）プログラム２６３０が含まれてもよい。また、実施例１〜４の少なくとも１つに係る管理計算機２０００が有する機能をストレージ装置１０００が有する場合、管理計算機２０００が無くても良い。【０２１７】
図３４は、ストレージ装置１０００内のメモリ１５００に記憶されるプログラムおよび情報を示す。【０２１８】
実施例５では、セグメントＩＯＰＳ解析プログラム１６１０、容量予測プログラム１６２０、ＩＯＰＳ性能評価テーブル１６３０、セグメントＩＯＰＳ履歴テーブル１６４０、プール容量管理テーブル１６５０がメモリ１５００に記憶される。このうち、ＩＯＰＳ性能評価テーブル１６３０は、実施例１または実施例２で述べたＩＯＰＳ性能評価テーブル２５７０と同じものである。また、プール容量管理テーブル１６５０は、セグメント管理テーブル１５６０から算出できるため必須のテーブルではない。【０２１９】
ストレージ装置１０００が、実施例１で管理計算機２０００が行った処理と同じ容量予測処理を行うためには、例えば、セグメントＩＯＰＳ解析プログラム１６１０がセグメントＩＯ評価プログラム２５３０と同じプログラムであり、容量予測プログラム１６２０が容量予測（１）プログラム２５４０と同じプログラムであり、セグメントＩＯＰＳ履歴テーブル１６４０が容量推移履歴テーブル２５８０と同じテーブルであればよい。【０２２０】
また、ストレージ装置１０００が、実施例２で管理計算機２０００が行った処理と同じ容量予測処理を行う場合は、セグメントＩＯＰＳ解析プログラム１６１０がセグメントＩＯＰＳ予測プログラム２６１０と同じプログラムであり、容量予測プログラム１６２０が容量予測（２）プログラム２６２０と同じプログラムであり、セグメントＩＯＰＳ履歴テーブル１６４０がセグメントＩＯＰＳ分布履歴テーブル２６４０と同じテーブルであればよい。【０２２１】
ただし、容量予測プログラム１６２０については、容量予測（１）プログラムまたは容量予測（２）プログラムのフローチャートにおいて、管理者に入力を求める処理の入力方法が、ストレージ装置が備える入力方法に変更される、または、初期値を保持しておくことにより初期値の入力が不要とされて良い。また、算出した容量増設結果の通知も、ストレージ装置が備える出力方法に変更されて良い。
【実施例６】
【０２２２】
＜概要＞。【０２２３】
本発明の実施例６として、ホスト計算機上のプールを備える場合のおける、増設時の容量予測方法について述べる。【０２２４】
＜構成説明＞。【０２２５】
図３５は、本発明の実施例６に係るストレージシステムを示す。【０２２６】
ストレージ装置１およびストレージ装置２の管理ＩＦ１０１０が、ホスト計算機３０００の管理ＩＦ３４００にデータネットワーク１００を介して接続されている。また、ストレージ装置１およびストレージ装置２のポート１０２０が、ホスト計算機３０００の通信ＩＦ３３００にデータネットワーク２００を介して接続している。ここで、ホスト計算機３０００に接続されているストレージ装置１およびストレージ装置２は、それぞれが持つ記憶領域をホスト計算機に提供するのみであって、ストレージ装置の数は０以上の任意の数であってよい。また、ホスト計算機３０００自体に後述するプールの管理機能を持たない場合には、プールや記憶領域を管理するための管理計算機が存在してもよい。【０２２７】
図３６は、実施例６に係るプール管理の概念を示す。【０２２８】
ホスト計算機３０００は、ストレージ装置１の提供する記憶領域１４００（図中ＬＵ１）やストレージ装置２の提供する記憶領域１４００（図中ＬＵ２）を、ホスト計算機３０００のボリューム３２１０（図中ＤＥＶ１およびＤＥＶ２）として認識している。また、ホスト計算機３０００が持つディスク３２００もボリューム３２２０（図中ＤＥＶ３）として認識されてもよい。ホスト計算機３０００は、このようなボリューム３２１０やボリューム３２２０で構成されたプール３２３０を管理しており、プール３２３０に対応付けられたＶＶＯＬ３２４０を業務プログラム３５１０等に提供している。また、プール３２３０には、ボリュームのほかに、メモリ３５００の空き領域などが含められてもよい。このようなプール３２３０にも、本発明を適用することができる。【０２２９】
図３７は、実施例６に係るホスト計算機３０００内のメモリ３５００に記憶されるプログラム及び情報を示す。【０２３０】
構成管理プログラム３５２０は、実施例１において管理計算機２０００が持つ構成管理プログラム２５１０と同じであり、構成情報取得プログラム３５３０は、実施例１において管理計算機２０００が持つ構成情報取得プログラム２５２０と同じである。【０２３１】
また、セグメントマイグレーションプログラム３５４０は、実施例１においてストレージ装置１０００が持つセグメントマイグレーションプログラム１５４０と同じであり、プール管理プログラム３５５０は、実施例１においてストレージ装置１０００が持つプール管理プログラムと同じである。【０２３２】
セグメントＩＯＰＳ解析プログラム３５６０は、実施例５に述べたストレージ装置１０００が持つセグメントＩＯＰＳ解析プログラム１６１０と同じであり、容量予測プログラム３５７０は、実施例５に述べたストレージ装置１０００が持つ容量予測プログラム１６２０と同じであり、実施例１または実施例２で述べたいずれかの予測方法を可能とするプログラムである。【０２３３】
リソース管理テーブル３６１０は、ホスト計算機３０００が認識するボリュームを管理するためのテーブルである。【０２３４】
図３８は、リソース管理テーブル３６１０の例を示す。【０２３５】
リソース管理テーブル３６１０は、ホスト計算機３０００で認識されるボリュームに関する情報を有する。具体的には、テーブル３６１０は、ホスト計算機３０００で認識されるボリューム毎に、下記の情報、
＊ボリュームのＩＤであるＶＯＬ  ＩＤ３６１１、
＊ボリュームの種別を表すリソース種別３６１２、
＊ボリュームの実体が存在する場所を示す実態ＶＯＬ  ＩＤ３６１３、
＊ボリュームが属する階層のＩＤである階層ＩＤ３６１４、
＊ボリュームの記憶容量を表す容量３６１５、
を有する。リソース種別３６１２、階層ＩＤ３６１４、容量３６１５は、実施例１等と同じ意味である。例えば、ホストが認識するボリュームとして、ホスト認識ＶＯＬ  ＩＤ：ＤＥＶ１は、ローカルつまりホスト計算機３０００内に存在するボリュームであると判別できる。また、ホスト認識ＶＯＬ  ＩＤ：ＤＥＶ２は、実体が、ストレージ装置１内に存在するＬＵ１であると判別することができる。また、階層ＩＤ３６１２は、リソース種別３６１２に加え、ホスト計算機内に存在するか否かで発生する遅延時間等を含めて設定することで、より予測精度を向上させることが出来ると期待できる。具体的には、例えば、ボリュームに基づく物理記憶デバイスがＳＡＳであっても、遅延時間が長いか短いかで、２つ以上の階層に分かれても良い。【０２３６】
セグメント管理テーブル３６２０は、実施例１においてストレージ装置１０００が持つセグメント管理テーブル１５６０と同じであり、仮想ボリューム管理テーブル３６３０は、仮想ボリューム管理テーブル１５７０と同じであり、マイグレーションポリシテーブル３６４０は、マイグレーションポリシテーブル１５８０と同じであり、ＩＯＰＳ性能評価テーブル３６５０は、ＩＯＰＳ性能評価テーブル１６３０と同じである。また、セグメントＩＯＰＳ履歴テーブル３６６０は、実施例５に述べたストレージ装置１０００が持つセグメントＩＯＰＳ履歴テーブル１６４０と同じであり、プール容量管理テーブル３６７０は、プール容量管理テーブル１６５０と同じである。【０２３７】
＜処理説明＞。【０２３８】
実施例６の各プログラムの処理の流れは、実施例５までに述べた各処理の流れと同じものである。ただし、容量予測プログラム３５７０が行った予測の結果を示すＧＵＩは、これまでと異なる。そのＧＵＩ例を図３９に示す。【０２３９】
図３９において、ＧＵＩ５８００は、テーブル５６１０が、これまでのＧＵＩ５２００等とは異なる。増設量の表示に加え、本実施例では、増設先５６１１の表示が必要となる。例えば、高性能なボリュームの増設が必要な場合には、増設先５６１１として、「ローカル」が表示されて良い。これは、ホスト計算機３０００に増設が必要となることを意味する。一方、低性能なボリュームの増設でも構わない場合などは、増設先５６１１として、「任意」が表示されて良い。増設先５６１１の判断に当たっては、増設先候補ごとに通信遅延を考慮した想定レスポンスタイム２５７４をＩＯＰＳ性能評価テーブル３６５０に保持しておく方法や、階層ＩＤに通信遅延を考慮した設定を行っていく方法を用いることで決定することができる。【０２４０】
＜バリエーション＞。【０２４１】
ストレージ装置１０００とは別のストレージ装置が備えるボリュームをストレージ装置１０００内に取り込み、ストレージ装置１０００が、別のストレージ装置のボリュームを自分のボリュームとして扱うことができる（以下、外部接続機能）。図３５のストレージ装置１において、ストレージ装置１が外部接続機能を供えることで、ストレージ装置２の持つボリュームをストレージ装置１のボリュームとして扱うことが可能となる。実施例６のホスト計算機が行ったプール管理技術および容量予測技術方法は、前述の外部接続機能を備えるストレージ装置１に適用してもよい。これによりストレージ装置１において、複数のストレージのボリュームからなるストレージ装置１のプールに対して、容量予測技術を提供することが出来る。また、ストレージ装置１が認識するボリュームは、別のストレージ装置だけでなく、ホスト計算機が保持するディスク３２００や、キャッシュメモリ領域を含めてもよい。【０２４２】
以上、本発明の幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。【０２４３】
例えば、ストレージ装置１０００、管理計算機２０００及びホスト計算機３０００の構成は、図１に示す構成でなくても良い。【０２４４】
また、初期値を入力するためのＧＵＩや予測された増設量を通知するためのＧＵＩについて、入力ツールは、図示の入力ツールに限らず、他種のツールが採用されてもよい。
【符号の説明】
【０２４５】
１０００…ストレージ装置  ２０００…管理計算機  ３０００…ホスト計算機
【図１】
2011092739.tif 000006
【図２】
2011092739.tif 000007
【図３】
2011092739.tif 000008
【図４】
2011092739.tif 000009
【図５】
2011092739.tif 000010
【図６】
2011092739.tif 000011
【図７】
2011092739.tif 000012
【図８】
2011092739.tif 000013
【図９】
2011092739.tif 000014
【図１０】
2011092739.tif 000015
【図１１】
2011092739.tif 000016
【図１２】
2011092739.tif 000017
【図１３】
2011092739.tif 000018
【図１４】
2011092739.tif 000019
【図１５】
2011092739.tif 000020
【図１６】
2011092739.tif 000021
【図１７】
2011092739.tif 000022
【図１８】
2011092739.tif 000023
【図１９】
2011092739.tif 000024
【図２０】
2011092739.tif 000025
【図２１】
2011092739.tif 000026
【図２２】
2011092739.tif 000027
【図２３】
2011092739.tif 000028
【図２４】
2011092739.tif 000029
【図２５】
2011092739.tif 000030
【図２６】
2011092739.tif 000031
【図２７】
2011092739.tif 000032
【図２８】
2011092739.tif 000033
【図２９】
2011092739.tif 000034
【図３０】
2011092739.tif 000035
【図３１】
2011092739.tif 000036
【図３２】
2011092739.tif 000037
【図３３】
2011092739.tif 000038
【図３４】
2011092739.tif 000039
【図３５】
2011092739.tif 000040
【図３６】
2011092739.tif 000041
【図３７】
2011092739.tif 000042
【図３８】
2011092739.tif 000043
【図３９】
2011092739.tif 000044
【国際調査報告】
2011092739.tif 000045
2011092739.tif 000046
2011092739.tif 000047