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

計算機システム及びストレージシステム管理方法 Download PDF

Info

Publication number
WO2012169027A1
WO2012169027A1 PCT/JP2011/063165 JP2011063165W WO2012169027A1 WO 2012169027 A1 WO2012169027 A1 WO 2012169027A1 JP 2011063165 W JP2011063165 W JP 2011063165W WO 2012169027 A1 WO2012169027 A1 WO 2012169027A1
Authority
WO
WIPO (PCT)
Prior art keywords
pool
performance
data
predicted
resource
Prior art date
Application number
PCT/JP2011/063165
Other languages
English (en)
French (fr)
Inventor
喜彦 安藤
野島　博
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2011/063165 priority Critical patent/WO2012169027A1/ja
Priority to US13/384,910 priority patent/US8683162B2/en
Publication of WO2012169027A1 publication Critical patent/WO2012169027A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G06F3/0649—Lifecycle management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0653—Monitoring storage devices or systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]

Definitions

  • the host server 300 is a computer that accesses the resources of the storage system 340 and performs business.
  • the host server 300 includes a host bus adapter (HBA) 303 that is a network interface, a processor 301, a memory 302 that is a main storage device, and an auxiliary storage device 305.
  • HBA host bus adapter
  • Each field of the Tier column 1105 stores the type of the hierarchy in which the page of each record is stored. This value is updated in data evacuation and inter-tier relocation for resource movement.
  • FIG. 12 shows an example of the time zone average IOPS information table 519.
  • the time zone average IOPS information table 519 includes a pool ID column 1201, a time zone column 1202, a time zone average IOPS column 1203, and an update count column 1204.
  • the time zone average IOPS is an average value of measured values of IOPS in each time zone (a time zone of 10 minutes in this example) as described in S602 of the flowchart in FIG.
  • the information collection function 501 updates this value. The update is performed in a monitoring period cycle.
  • the performance management function 502 determines whether or not a performance problem has occurred in response to the result of the performance monitoring process performed in S1701 (S1702). If a performance problem has occurred (S1702: YES), the performance management function 502 executes S1703. If no performance problem has occurred in S1701 (S1702: NO), the performance management function 502 ends the process.
  • the performance management function 502 immediately adds unused resources to the dangerous pool, predicts the page arrangement after page rebalancing (page rearrangement within the hierarchy) in the dangerous pool, Along with the history information, the response time of the danger pool in each time zone after adding the resource is predicted. Rebalancing will be described in the description of S1707.
  • the release of the pool volume from the pool will fail. Since the data in the Tier is distributed and arranged in the pool volumes constituting the Tier, the save page is also distributed and written among the free pool volumes.
  • the performance management function 502 repeats S1801 to S1805 for each virtual volume.
  • the performance management function 502 calculates a performance surplus rate for the virtual volume (S1802).
  • the performance management function 502 refers to the virtual volume information table 522, and calculates the performance surplus rate from the latest response time of the virtual volume and the request response time upper limit of the virtual volume by the following formula.
  • Virtual volume performance surplus rate (%) (100-(latest response time / requested response time upper limit) x 100)
  • the performance management function 502 determines that the pool whose performance surplus rate is lower than the lower threshold in S1802 is a dangerous pool, and stores information on the risk pool (pool ID and virtual volume performance surplus rate) in the risk pool group table. Add to 518.
  • the performance management function 502 repeats S2302 to S2307 for each pool other than the dangerous pool.
  • the performance management function 502 calculates the estimated time required for resource release. Specifically, the performance management function 502 calculates the transfer data amount for each transfer route, obtains the transfer rate for each transfer route, and determines the resource based on the transfer data amount for each transfer route and the transfer rate for each transfer route. Calculate the estimated time required for release.
  • the transfer path is a transfer path between Tiers in the pool.
  • the management system can use a value different from the response time as an index of the performance requirement that the pool should satisfy. For example, transfer rate (MB / s), throughput (Max-IOPS), and other indicators can be used.
  • the management system performs a simulation for performance prediction based on the historical information of the storage system that is periodically acquired. Thus, more accurate performance prediction can be performed. Depending on the design, performance prediction may be performed using certain preset data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　本発明の一実施形態において、ストレージシステムは、それぞれが複数の記憶リソースを含みアクセス性能が異なる複数の階層に分けられた、複数のプールを含む。管理システムは、上記複数のプールのアクセス性能を監視し、予め定められたアクセス性能要求を満たさなくなることが予測される危険プールを検知する。上記管理システムは、上記複数のプールの１以上の候補プールのそれぞれについて、記憶リソースを上記危険プールに移動する場合のアクセス性能を、上記記憶リソースの上記移動のために上記記憶リソースに格納されているデータを同一プール内で退避することによるプール内データ配置の変動に基づくシミュレーションにより予測する。上記管理システムは、上記予測したアクセス性能が予め定められた性能要求を満たす提供元プールから上記記憶リソースを上記危険プールに移動することを決定する。

Description

計算機システム及びストレージシステム管理方法
　本発明は、計算機システム及びストレージシステム管理方法に関し、特に、ストレージシステムにおけるリソースの再割り当てに関する。
　ストレージシステムからホストに対してボリュームを提供する際、ストレージシステム内の性能の異なる複数のメディアから階層化されたプールを構成し、そのプールから構築した仮想ボリュームをホストに割り当てる運用が知られている（例えば、特許文献１を参照）。
　ストレージシステムは、仮想ボリュームに対するホストからのＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）負荷を分析し、Ｉ／Ｏ負荷の高いページを、性能の高い高価なディスクで構成されたリソースから成る上位階層に、そうでないページを性能の低い安価なディスクで構成されたリソースから成る下位階層に自動配置する。これにより、少ないＴＣＯ（Ｔｏｔａｌ　Ｃｏｓｔ　ｏｆ　Ｏｗｎｅｒｓｈｉｐ）で、効率的に要求性能を満たすことが出来る。
米国特許出願公開第２００７／２３４１０９号明細書
　複数ホストに同じストレージシステムからボリュームを提供する場合、それぞれのＩ／Ｏの競合を避けるため、プールを分ける場合がある。従来技術は、プール毎にＴｉｅｒの配分を決めて運用するため、プール毎のＩ／Ｏ負荷に偏りが生じた場合に、ホストの要求性能を満たせなくなる危険度にプール間でのバラつきが生じる。
　ホストの要求性能を満たせなくなる可能性の高いプール（危険プール）がある場合、速やかにそのプールの性能を改善する必要がある。そのため、管理者は、細やかに各プールの性能を監視しなければならず、管理コストが増大する。また、従来技術においては、危険プールの性能を改善するにあたり、使用されていないリソースを危険プールに追加する必要がある。これに伴い、ストレージシステム内にリソースを待機させておく必要が生じ、システムコストが増大する。
　ストレージシステムにおいて、管理コストを抑えつつ、各プールがホストの要求性能を満たせることを保証することが要求される。これに加えて、システムコストを抑えるために、ストレージシステム内で使われていないリソースの量を削減することが重要である。
　本発明の一態様の計算機システムは、ストレージシステムと、上記ストレージシステムとネットワークを介して接続し前記ストレージシステムを管理する管理システムとを含む。上記ストレージシステムは、それぞれが複数の記憶リソースを含みアクセス性能が異なる複数の階層に分けられた、複数のプールを含む。上記管理システムは、上記複数のプールのアクセス性能を監視し、予め定められたアクセス性能要求を満たさなくなることが予測される危険プールを検知する。上記管理システムは、上記複数のプールの１以上の候補プールのそれぞれについて、記憶リソースを上記危険プールに移動する場合のアクセス性能を、上記記憶リソースの上記移動のために上記記憶リソースに格納されているデータを同一プール内で退避することによるプール内データ配置の変動に基づくシミュレーションにより予測する。上記管理システムは、上記予測したアクセス性能が予め定められた性能要求を満たす提供元プールから上記記憶リソースを上記危険プールに移動することを決定する。
　本発明の一態様によれば、効率的にストレージシステムの各プールの要求性能を満たすことができる。
本実施形態の概要を説明する図である。 本実施形態の概要を説明する図である。 本実施形態におけるシステム構成を模式的に示す。 本実施形態におけるストレージシステム内論理構成を模式的に示す。 本実施形態における管理サーバの保持するプログラム及び情報を模式的に示す。 本実施形態における情報収集処理の例を示すフローチャートである。 本実施形態における仮想ボリューム情報テーブルの例を示す。 本実施形態におけるプール情報テーブルの例である。 本実施形態におけるプールボリューム情報テーブルの例である。 本実施形態におけるプール内Ｔｉｅｒ情報テーブルの例である。 本実施形態におけるページ情報テーブルの例である。 本実施形態における時間帯平均ＩＯＰＳ情報テーブルの例である。 本実施形態におけるＩ／Ｏ履歴情報テーブルの例である。 本実施形態におけるＩＯＰＳ対レスポンスタイム相関情報テーブル更新処理の例を示すフローチャートである。 本実施形態におけるプール内Ｔｉｅｒ性能情報テーブルの例である。 本実施形態のＩＯＰＳ対レスポンスタイム相関情報テーブルの例である。 本実施形態の性能管理処理のフローチャートである。 本実施形態における性能監視処理の例を示すフローチャートである。 本実施形態における危険プール群テーブルの例である。 本実施形態における性能問題改善計画処理の例を示すフローチャートである。 本実施形態における追加リソース算出処理の例を示すフローチャートである。 本実施形態におけるＴｉｅｒ定義テーブルの例である。 本実施形態におけるリソース移動計画作成処理の例を示すフローチャートである。 本実施形態におけるリソース移動計画候補テーブルの例である。 本実施形態におけるデータ退避中性能チェック処理の例を示すフローチャートである。 本実施形態におけるデータ退避後性能チェック処理の例を示すフローチャートである。 本実施形態におけるリソース移動計画テーブルの例である。 本実施形態におけるリソース移動（データ退避）開始後の提供元プールの性能の予測値を模式的に示すグラフである。 本実施形態におけるリソース移動（データ退避）開始後の提供元プールの性能の予測値を模式的に示すグラフである。
　以下、図面を参照しつつ、本発明を実施するための形態を説明する。説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。又、各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略されている。
　本実施形態は、プール間のリソース（記憶リソース）の再割り当てに関する。図１及び図２を参照して、本実施形態の概要を説明する。本実施形態のストレージシステムは、図１に示すように、複数のプールボリューム（実ボリューム）からなるプール１００を構築する。プール１００はアクセス性能によって階層化されており、複数の階層、本例において３つの階層を有する。Ｔｉｅｒ０のボリュームのアクセス性能が最も高く、Ｔｉｅｒ２のボリュームのアクセス性能が最も低い。
　各階層は、複数の実ボリュームで構成されており、本例において、Ｔｉｅｒ０がプールボリューム１０１、１０２からなり、Ｔｉｅｒ１がプールボリューム１１１、１１２からなり、Ｔｉｅｒ２がプールボリューム１２１、１２２からなる。各プールボリュームは複数ページに分割され、各ページにデータが格納される。図１において、ページ内の数字は、そのページの所定期間におけるＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）量を示す。
　ストレージシステム内で構築した複数のプールから、複数のホストサーバに対してボリュームを提供している環境において、プールの性能がホストサーバの性能要件（サービス要求項目：ＳＬＯ）を満たせなくなる場合がある。本実施形態のシステムは、この兆候を検知した場合、性能に余裕のある別のプール（以下において提供元プール）から、プールを構成する記憶リソース（実ボリューム）を、ＳＬＯを満たせなくなる可能性が高いプール（以下において危険プール）に移動することによって、危険プールの性能を改善する。
　本実施形態のシステムは、各プールのアクセス性能を監視する。監視される典型的なアクセス性能の指標は、レスポンスタイムである。いずれかのプールのアクセス性能がそのプールに対する要求性能を満たすことができない可能性があると判定すると、自動的に、他のプールから記憶リソースであるプールボリュームを解除し、そのプールボリュームを上記の危険プールに追加する。
　これにより、アクセス性能が低下しているプールの性能を上げる。さらに、管理者の負担を軽減し、管理コストを削減できるとともに、ストレージシステム内に待機させておく必要のあるリソース量を低減でき、システムコストを削減できる。
[規則91に基づく訂正 25.07.2011]　
　図１の例は、プールボリューム１０２のページ（格納データ）を同一プール１００内のプールボリューム１２２に退避し、プールボリューム１０２をプール１００から解除する。プールボリューム102は、それを必要とする他の危険プールに追加される。プールボリューム１０２が追加された階層においては、ページのＩ／Ｏ量を均一化するように、ページが再配置（リバランス）される。
　図１において、高負荷なページ、つまり、所定期間のＩ／Ｏ量が大きいページが低速なＴｉｅｒ２に退避されている。本実施形態のシステムは、プールボリューム１０２を解除した後、提供元プール１００内のページ（データ）を階層間再配置する。これにより、Ｉ／Ｏ量の多いページを高性能の階層に格納することで、プールのアクセス性能を向上する。システムは、予め設定されている定期的な階層間再配置及び／又は、定期的な階層間再配置とは異なる時刻での階層間再配置を行う。
　この階層間再配置の実行中、プールのアクセス性能が低下する。上述のように、プールの仮想ボリュームに対しては、予めホストサーバからの要求性能が存在している。各仮想ボリューム（各プール）は、この要求性能を常に満たすことが要求される。ボリュームを追加されたプールの性能は向上するが、プールボリュームを解除されたプールの性能は低下する。従って、ボリューム解除後も要求性能を満たすことができるプールから、プールボリュームを移動することが必要となる。
　さらに、プール内でのページの階層間移動は、プール（仮想ボリューム）のアクセス性能を低下させる。これは、ページ移動の負荷が、ストレージシステムの仮想ボリュームへのアクセスの処理能力を低下させるからである。アクセス性能の低下は、プールボリューム移動のためのプール内でのページ退避（図１を参照）及び各ページのアクセス性能の向上のためのページの階層間再配置において発生する。
　図２は、プールボリュームの提供元プールのレスポンスタイムの時間変化の一例を模式的に示している。図２において、Ｙ軸はレスポンスタイム、Ｘ軸は時刻を示す。実線はボリューム移動前のレスポンスタイムを示し、一点鎖線はボリューム移動後のレスポンスタイム予測値を示し、破線はＳＬＯで要求されているレスポンスタイムである。
　時刻Ｔ２１において、提供元プールからプールボリュームを解除するために、プール内でのページ移動（データ退避）が開始する。レスポンスタイム予測値のラインが示すように、ページ移動の負荷により、レスポンスタイムが大きく増加する。ページが性能の低い階層に移動するため（図１を参照）、移動開始Ｔ２１からレスポンスタイムが徐々に増加する。時刻Ｔ２２において、ページ退避のための移動が終了する。ページ移動の負荷がなくなるため、レスポンスタイムが大幅に短くなる。
　高性能の階層に格納されていたページが低性能の階層に移動しているため、ページ退避後のレスポンスタイムは、リソース移動前（実線で示されている）のレスポンスタイムよりも遅い。時刻Ｔ２３において定期的階層間再配置が開始し、時刻Ｔ２４において終了する。これにより、プール内のページ配置が最適化される。階層間再配置は、監視期間中に記録したプール内の各ページのＩ／Ｏ量を基に、Ｉ／Ｏ量の多かったページから順に上位Ｔｉｅｒに再配置する。階層間再配置はプール単位で実行される。
　階層間再配置におけるページ移動処理の負荷のため、時刻Ｔ２３から時刻Ｔ２４において、レスポンスタイムが大きく増加している。階層間再配置により、相対的にＩ／Ｏ量が多いページが高性能の階層に移動するため、レスポンスタイムが時刻Ｔ２３から時刻Ｔ２４において徐々に減少する。時刻Ｔ２４において階層間再配置が終了すると、レスポンスタイムが大きく低下する。
　危険プールでＳＬＯ違反が発生する高い可能性を察知した場合、速やかにリソースを追加することにより性能を改善する必要がある。図１及び図２を参照して説明したように、提供元プールからリソース（プールボリューム）を移動するためには、そのリソースを提供元プールから解除する必要があり、解除するリソースに格納されているデータをプール内の他のリソース（プールボリューム）に退避しなければならない。
　これにより、提供元プール内の最適ページ配置が損なわれ、階層間再配置によりページ配置が最適化されるまでは、性能が劣化した状態が維持される。ページ配置最適化のための階層間再配置は、任意のタイミングで実行できるが、多くの場合は、定期的に特定の時間帯に実施されるよう設定されている。そのため、プール内でのデータ退避の開始（リソース解除の開始）から階層間再配置の完了までの期間に、提供元プールの性能がＳＬＯ違反を起こさないことを保証することが要求される。
　上述のように、プール間のプールボリューム移動及び定期的なページ階層間再配置のためのプール内ページ移動の間、プールのアクセス性能は大きく劣化し、レスポンスタイムは大幅に長くなる。そのため、プール内ページ移動の間において、プールはＳＬＯのアクセス性能要求を満たしていることが必要である。
　本実施の形態のシステムは、プール間のリソース移動の計画を立てる。リソース移動は、提供元プールからリソースを解除し、それを危険プールへ追加する。計画立案において、システムは、リソース移動後、プール内ページの階層間再配置を実施した後の危険プール及び提供元プール候補のアクセス性能を予測する。予測結果を基にリソースの提供元プールと、移動するリソースの種類、容量を決定する。
　好ましい構成において、本実施形態のシステムは、リソースの提供元プールを選択する際に、リソース提供による提供元プールの性能劣化を、履歴データを基にしたシミュレーションにより予測する。そして、提供元プール（の仮想ボリューム）の性能がＳＬＯを満たせるかどうかを予測し、提供元プールとなりえるプールの候補を特定する。
　性能予測は、リソース解除のためのプール内でのページ移動による性能劣化、そして階層間再配置におけるプール内での階層間ページ移動による性能劣化を予測する。好ましい構成において、本実施形態のシステムは、提供元プールからのリソース移動後、提供元プールの階層間再配置を即時実行する場合と、即時階層間再配置を実行しない場合の、双方のプール性能を予測する。
　性能劣化の予測は、リソース移動（データ退避）の開始時刻に依存する。本実施形態のシステムは、予測対象のプールについて、リソース移動開始時刻を変化させながらその性能を予測する。
　危険プールの性能は早期に改善することが重要である。そのため、好ましい構成において、システムは、提供元プールの候補のうち、リソース提供可能時刻（プール内データ退避完了時刻）が最も早いプールを選択し、そのプールから危険プールにリソースを移動する。これにより、早期に危険プールの性能を改善しつつ、ストレージシステム全体においてＳＬＯを満たせなくなる可能性を低減できる。
　以下において、本実施形態の計算機システム及びその動作を、図面を参照して説明する。図３は、本実施形態の計算機システムの概略構成を模式的に示すブロック図である。本計算機システムは、複数のホストサーバ３００、管理サーバ３２０、複数のストレージシステム３４０を含む。複数のホストサーバ３００はそれぞれ同様の構成を有し、複数のストレージシステム３４０は、それぞれ同様の構成を有する。計算機システムが含みえるホストサーバ３００、管理サーバ３２０、ストレージシステム３４０の数は、１以上の任意の数である。
　ホストサーバ３００、管理サーバ３２０、及びストレージシステム３４０は、管理ネットワーク３７０により、通信可能に接続されている。本構成においては、ＩＰネットワークである。なお、管理ネットワーク３７０は、データ通信用のネットワークであればＩＰネットワーク以外のネットワークでもよい。
　ホストサーバ３００及びストレージシステム３００は、データネットワーク３６０により接続されている。データネットワーク３６０はデータ通信用のネットワークであって、本構成においては、ＳＡＮ（Ｓｔｏｒａｇｅ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）である。データネットワーク３６０は、データ通信用のネッットワークであれば、ＳＡＮと異なるネットワークでもよい。
　ホストサーバ３００はストレージシステム３４０のリソースにアクセスし、業務を行う計算機である。ホストサーバ３００は、ネットワークインタフェースであるホストバスアダプタ（ＨＢＡ）３０３、プロセッサ３０１、主記憶デバイスであるメモリ３０２及び補助記憶デバイス３０５を有している。
　ホストサーバ３００のデバイスは、バスにより通信可能に接続されている。プロセッサ３０１は、メモリ３０２に記憶されているプログラムを実行することによってホストサーバ３００の所定の機能を実現する。メモリ３０２は、プロセッサ３０１によって実行されるプログラム及びプログラムの実行に必要なデータを記憶する。プログラムは、不図示のＯＳの他、アプリケーション３０４を含む。
　典型的には、プログラムは、補助記憶デバイス３０５からメモリ３０２にロードされる。補助記憶デバイス３０５は、ホストサーバ３００の所定の機能を実現するために必要なプログラム及びデータを格納する、不揮発性の非一時的記憶媒体を備える記憶装置である。補助記憶デバイス３０５は、ネットワークを介して接続された外部の記憶デバイスでもよい。
　図３は、一つのアプリケーション３０４を例示するが、複数のアプリケーションが、ホストサーバ３００において動作していてもよい。アプリケーション３０４は、例えば、グループウェア／電子メールサーバプログラムやデータベース管理システムである。ストレージシステム３４０は、アプリケーション３０４に対して、一つ又は複数のボリュームを提供する。
　管理サーバ３２０は、ネットワークインタフェースであるＬＡＮポート３２５、プロセッサ３２１、主記憶デバイスであるメモリ３２２、補助記憶デバイス３２３、入出力デバイス３２４を含む。管理サーバ３２０は、管理プログラム３２６を実行し、それに従って動作する。管理サーバ３２０のデバイスは、バスにより通信可能に接続されている。
　入出力デバイス３２４は、ディスプレイ、ポインタ又はキーボード等のデバイスの一つ又は複数のデバイスを含む。管理者は、これら入出力デバイス３２４により、管理サーバ３２０を操作することができるほか、ネットワークを介して接続するクライアント計算機から管理サーバ３２０にアクセスしてもよい。クライアント計算機は、管理サーバ３２０と共に管理システムに含まれる。
　管理者は、入力デバイス（例えばマウス及びキーボード）により必要な情報を入力し、表示デバイスにより必要な情報を視認することができる。管理システムは、一つの管理サーバ３２０で構成されていてもよく、それぞれが管理サーバ３２０の機能の一部又は全部を備える複数のサーバを含むことができる。
　プロセッサ３２１は、メモリ３２２に記憶されているプログラムを実行することによって管理サーバ３２０の所定の機能を実現する。メモリ３２２は、プロセッサ３２１よって実行されるプログラム及びプログラムの実行に必要なデータを記憶する。プログラムは、不図示のＯＳの他、管理プログラム３２６を含む。管理プログラム３２６の詳細は後述する。
　典型的には、プログラムは、補助記憶デバイス３２３からメモリ３２２にロードされる。補助記憶デバイス３２３は、管理サーバ３２０の所定の機能を実現するために必要なプログラム及びデータを格納する、不揮発性の非一時的記憶媒体を備える記憶装置である。補助記憶デバイス３２３は、ネットワークを介して接続された外部の記憶装置でもよい。
　ストレージシステム３４０は、コントローラ３４１、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）群３４６、ＳＡＳ（Ｓｅｒｉａｌ　Ａｔｔａｃｈｅｄ　ＳＣＳＩ）ドライブ群３４７、ＳＡＴＡ（Ｓｅｒｉａｌ　ＡＴＡ）ドライブ群３４８を含む。これらは、内部ネットワークにより接続されている。
　コントローラ３４１は、プロセッサ３４２、主記憶デバイスであるメモリ３４３、データ通信インタフェースであるＳＡＮポート３４４を含む。プロセッサ３４２（コントローラ３４１）は、ストレージ制御プログラム３４５及び必要な他のプログラムを実行することで、ホストサーバ３００からのＩ／Ｏの制御及びストレージシステム３４０のプール及びボリュームの管理制御を含む所定の機能を実現する。典型的には、プログラムは、いずれかのディスクからメモリ３４３にロードされる。本実施形態で説明するコントローラ３４１の機能の少なくとも一部は、ハードウェアによって実現されてもよい。
　本計算機システムにおいて、プログラムは、プロセッサによって実行されることで、定められた処理を記憶デバイス及び通信インタフェースを用いながら行う。従って、本実施形態においてプログラム、例えば、管理プログラム３２６やストレージ制御プログラム３４５を主語とする説明は、プロセッサを主語とした説明でもよい。若しくは、プログラムが実行する処理は、そのプログラムが動作する装置及びシステムが行う処理である。
　プロセッサは、プログラムに従って動作することによって、所定の機能を実現する機能部として動作する。例えば、プロセッサ３２１は、管理プログラム３２６に従って動作することでストレージシステムの管理部として機能し、プロセッサ３４２は、ストレージ制御プログラム３４５に従って動作することでストレージ制御部として機能する。他のプログラム、プロセッサ及び装置についても同様である。プロセッサは、各プログラムが実行する複数の処理のそれぞれを実現する機能部としても動作する。プロセッサ及びプログラムを含む装置及びシステムは、これらの機能部を含む装置及びシステムである。
　図４は、ストレージシステム３４０がホストサーバ３００に提供するボリュームの論理構成及びボリュームとドライブ群３４６～３４８との関係を模式的に示している。ストレージシステム３４０のコントローラ３４１（ストレージ制御プログラム３４５）は、複数の実ボリューム（プールボリューム）からなるプール４０２を構築する。図４に示すように、コントローラ３４１は複数のプール４０２を構築する。さらに、コントローラ３４１は、プール内の記憶領域が動的に割り当てられる仮想ボリューム４０１を構築する。ホストサーバ３００は、仮想ボリューム４０１が提供される。
[規則91に基づく訂正 25.07.2011]　
　コントローラ３４１は、ドライブ群３４６～３４８が与える実記憶領域により構成される複数の実ボリュームを構築する。本構成例において、コントローラ３４１は、ドライブの種類に応じて、３種類のボリュームを構築する。具体的には、ＳＳＤ群３４６はＳＳＤボリューム群４０６を与え、ＳＡＳドライブ群３４７はＳＡＳボリューム群４０７を与え、ＳＡＴＡドライブ群３４８はＳＡＴＡボリューム群４０８を与える。
　上記３種類のドライブのアクセス性能は異なり、ＳＳＤの性能が最も高くＳＡＴＡドライブの性能が最も低い。アクセス性能は、レスポンスタイムやスループットといった指標で表される。本構成例においては、同一種類のドライブは同一のアクセス性能を有するとする。典型的には、複数のドライブから構成されたＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ　Ａｒｒａｙｓ　ｏｆ　Ｉｎｅｘｐｅｎｓｉｖｅ　Ｄｉｓｋｓ）が複数のボリューム（リソース）を与える。
　プール４０２の複数ボリューム（プールボリューム）は、階層化されている。本構成例において、プール４０２は、Ｔｉｅｒ０～Ｔｉｅｒ２の３つの階層４０３～４０５を有している。階層はそれぞれ異なるボリューム群で構成されている。Ｔｉｅｒ０はＳＳＤボリューム群４０６で構成され、Ｔｉｅｒ１はＳＡＳボリューム群４０７で構成され、Ｔｉｅｒ２はＳＡＴＡボリューム群４０８で構成されている。Ｔｉｅｒ０のアクセス性能が最も高く、Ｔｉｅｒ２のアクセス性能が最も低い。
　プール４０２において、各プールボリュームは複数ページに分割される。プール４０２は、ページ単位で管理される。ホストサーバ３００に提供されるボリュームは、仮想ボリュームであって、その容量は仮想化されている。仮想ボリューム４０１にホストサーバ３００から書き込みがありデータ格納領域が必要になる度に、ストレージ制御プログラム３４５は、ページを仮想ボリューム４０１に割り当てる。
　ストレージシステム３４０は、ホストサーバ３００により認識される仮想ボリューム４０１の容量を、仮想ボリューム４０１に割り当てられている実容量（全ページの容量）よりも大きくすることができ、ホストサーバ３００に割り当てられる容量を実現するために必要な実容量を、それよりも小さくすることができる（ダイナミックプロビジョニング）。ストレージシステム３４０は、プール内のページから構成され実容量とホストサーバ３００により認識される容量が一致するボリュームを、ホストサーバ３００に提供してもよい。
　好ましい本構成例において、ストレージ制御プログラム３４５は、仮想ボリューム４０１に対するホストサーバ３００からの書き込みがあった場合、プール４０２の最上位のＴｉｅｒ０（４０３）のページから、必要容量のページを新たに仮想ボリューム４０１に割り当てる。ストレージ制御プログラム３４５は、これと異なる方法により、書き込むページを決定してもよい。
　ストレージ制御プログラム３４５は、所定期間(監視期間)、ストレージシステム３４０内の階層化された各プール４０２に関して、プール４０２内の全てのページに対するＩ／Ｏ量（本例でリードコマンド及びライトコマンドの合計数）を監視し、記憶する。監視期間中のプール４０２内の各ページのＩ／Ｏ量を基に、ストレージ制御プログラム３４５は、Ｉ／Ｏ量の多かったページから順に上位階層に再配置する（階層間再配置）。ストレージ制御プログラム３４５は、階層間再配置をプール単位で行う。階層間再配置は公知の技術であり、本実施形態において必要な範囲で説明を行う。
　図５は、管理サーバ３２０の管理プログラム３２６の構成及び管理サーバ３２０が使用する情報を模式的に示している。メモリ３２２は、管理プログラム３２６を格納しており、管理プログラム３２６は、情報収集機能５０１及び性能管理機能５０２を有する。図５は、便宜的に、管理プログラム３２６及びテーブル５１１～５２３をメモリ３２２内に図示しているが、これらデータは、典型的に、補助記憶デバイス３２３からメモリ３２２に格納される。
　管理プログラム３２６の情報収集機能５０１は、ストレージシステム３４０からのデータの収集及び各テーブルへの情報格納を行う機能である。また、情報収集機能５０１は、各テーブルの初期設定を行う。情報管理機能５０２は、定期的に各仮想ボリュームの性能を監視する。ホストサーバ３００の要求性能（ＳＬＯ）を満たせなくなる可能性のある仮想ボリューム（危険仮想ボリューム）を検知した場合、情報管理機能５０２は、性能改善処理を実施する。
　具体的には、情報管理機能５０２は、他のプールから危険プールへの記憶リソース移動の計画を立案し、リソース移動にともなう、提供元プールでのＳＬＯ違反の発生を防ぐ。なお、管理プログラム３２６の有する各機能は、必ずしも一つのプログラムの機能である必要は無く、それぞれが別々のプログラムコードであってもよい。管理プログラム３２６の機能及び動作の詳細は後述する。
　図５に示すように、メモリ３２２は、プール情報テーブル５１１、プールボリューム情報テーブル５１２、プール内Ｔｉｅｒ情報テーブル５１３、ページ情報テーブル５１４、リソース移動計画候補テーブル５１５、リソース移動計画テーブル５１６、Ｔｉｅｒ定義テーブル５１７、危険プール群テーブル５１８、時間帯平均ＩＯＰＳ（Ｉｎｐｕｔ　Ｏｕｔｐｕｔ　Ｐｅｒ　Ｓｅｃｏｎｄ）情報テーブル５１９を格納している。ＩＯＰＳは、単位時間（１秒）当たりのＩ／Ｏ量である。
　メモリ３２２は、さらに、Ｉ／Ｏ履歴情報テーブル５２０、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１、仮想ボリューム情報テーブル５２２、プール内Ｔｉｅｒ性能情報テーブル５２３を格納している。各テーブルの詳細は後述する。図５は、便宜的に、テーブルをメモリ３２２内に図示しているが、管理サーバ３２０の処理において必要とされるデータは、典型的に、補助記憶装置３２３からメモリ３２２に格納される。各情報（を表すデータ）は、メモリ３２２、補助記憶装置３２３における記憶領域内に格納される。
　図５の例において、管理プログラム３２６が使用する情報（データ）は、テーブルに格納されている。本実施形態のシステムが使用する、データ記憶領域に格納される情報は、データ構造に依存せず、どのようなデータ構造で表現されていてもよい。例えば、テーブル、リスト、データベースあるいはキューから適切に選択したデータ構造体が、情報を格納することができる。
　管理プログラム３２６は、その情報収集機能５０１により、危険プールの監視とプール間のリソース再配置のため、ストレージシステム３４０の情報を収集する。図６は、この情報収集の一例を示すフローチャートである。情報収集機能５０１は、定期的に(本例では１０分に一度とする)、ストレージシステム３４０のコントローラ３４１から、各種情報を収集し、対応するテーブルに格納する（Ｓ６０１）。
　収集する情報の種類及びそれを格納するテーブルは、以下における各テーブルの説明で言及する。管理者が予め設定する情報及び収集した情報から得られる情報以外の情報は、情報収集機能５０１により収集される。
　情報収集機能５０１は、プール情報テーブル５１１のリアルタイムＩＯＰＳカラム８０６（図８を参照）から、ストレージシステム３４０内の各プール４０２における最新のＩＯＰＳを取得し、時間帯平均ＩＯＰＳ情報テーブル５１９（図１２を参照）の、当該プールＩＤ及び時刻に対応するレコードの時間帯平均ＩＯＰＳカラム１２０３及び更新回数カラム１２０４を更新する（Ｓ６０２）。
　時間帯平均ＩＯＰＳカラム１２０３の値を更新する際は、情報収集機能５０１は、当該レコードの時間帯平均ＩＯＰＳカラム１２０３に格納されている値に、当該レコードの更新回数カラム１２０４に格納されている値を掛け合わせ、その結果に上記取得した最新のＩＯＰＳを足し合わせる。さらに、その結果を、当該レコードの更新回数カラム１２０４に格納されている値に１を足した値で割り、その結果で当該レコードの時間帯平均ＩＯＰＳカラム１２０３の値を更新する。
　情報収集機能５０１は、さらに、前記算出した当該レコードの更新回数カラム１２０４に格納されている値に１を足した値で、当該レコードの更新回数カラム１２０４の値を更新する。
　次に情報収集機能５０１は、ＩＯＰＳ対レスポンスタイム相関情報テーブル更新処理を実施する（Ｓ６０３）。情報収集機能５０１は、Ｓ６０１でストレージシステム３４０のコントローラ３４１から取得した情報を基に、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１（図１６を参照）を更新する。ＩＯＰＳ対レスポンスタイム相関情報テーブル更新処理の詳細は、後ほど図１４を用いて説明する。
　図７は、仮想ボリューム情報テーブル５２２の一例を示す。仮想ボリューム情報テーブル５２２は、各仮想ボリュームの所属プールとレスポンスタイムに関する情報を格納する。具体的には、仮想ボリュームＩＤのカラム７０１、プールＩＤのカラム７０２、要求レスポンスタイム上限のカラム７０３、最新レスポンスタイムのカラム７０４を有する。
　プールＩＤのカラム７０２、仮想ボリュームＩＤのカラム７０１は、それぞれ、プールの識別情報及び仮想ボリュームの識別情報を格納する。本明細書において、要素を識別する情報の呼び名は、ＩＤ、名前、番号等、任意であり、これらは置換可能である。この点は、他の識別情報について同様である。
　仮想ボリューム情報テーブル５２２は、各仮想ボリュームの要求レスポンスタイムと最新の実際のレスポンスタイムを格納している。管理者は、仮想ボリュームの作成時に、提供先ホストサーバから要求されているレスポンスタイムの上限を設定し、その値が、要求レスポンスタイム上限カラム７０３に格納される。
　その値が設定されない場合は、デフォルト値として、充分に大きな値(例えば１００ｍｓ)が設定される。情報収集機能は、情報収集処理にて、各仮想ボリュームの最新のレスポンスタイムをストレージシステム３４０のコントローラ３４１から取得し、最新レスポンスタイムカラム７０４に格納する。
　図８は、プール情報テーブル５１１の一例を示す。プール情報テーブル５１１は、プールＩＤで同定されるプールの監視期間、定期階層間配置、ＩＯＰＳそして性能余剰率についての情報を格納する。具体的には、このテーブル５１１は、プールＩＤのカラム８０１、監視期間開始時刻のカラム８０２、監視期間終了時刻のカラム８０３、監視期間周期のカラム８０４、実行モードのカラム８０５、リアルタイムＩＯＰＳのカラム８０６、性能余剰率一日平均のカラム８０７を有する。性能余剰率については後述する。
　情報収集機能５０１は、所定期間（監視期間）、ストレージシステム３４０内の階層化された各プールに関して、プール内の全てのページに対するＩ／Ｏ量を監視し、その値を記憶する（例えば、ページ情報テーブル５１４参照）。この監視期間の周期は、デフォルト値の０：００から２４時間おきの他、２時間おき、４時間おき、８時間おきの何れかを管理者が選択できる。監視期間周期と監視期間長の数値は一致する。管理者は、監視期間の周期を設定する代わりに、監視期間の開始時刻（カラム８０２）と終了時刻（カラム８０３）を指定することもできる。
　監視期間開始時刻及び監視期間終了時刻は、それぞれ、プール内ページへのＩ／Ｏ量を収集する監視期間の開始及び終了時刻である。周期のデフォルト（２４時間）に対応する開始時刻は０：００、終了時刻は翌０：００である。０：００丁度は、開始時刻に含まれる。デフォルトの開始時刻と終了時刻は、それぞれの周期に対応して決められている。これらは、管理者により指定することも可能である。
　リアルタイムＩＯＰＳは、情報収集機能５０１がストレージシステム３４０のコントローラ３４１から情報を収集した時点のプールへのＩＯＰＳである。この値は、定期的にストレージシステム３４０のコントローラ３４１から収集するタイミングでの更新の他に、図１７が示す性能管理処理によるリソース移動計画を基にしたリソース移動（Ｓ１７０５）の際及びその他のタイミングで、必要に応じて取得してもよい。
　実行モードのカラム８０５は、定期的な階層間再配置の実行モードを示すデータを格納する。管理者は、実行モードのカラム８０５に、"自動"又は"手動"を設定する。本実施形態の階層間再配置は、監視期間中に記録したプール内の各ページのＩ／Ｏ量を基に、Ｉ／Ｏ量の多かったページから順に上位Ｔｉｅｒに再配置する。
　自動実行モードにおいて、ストレージシステム３４０のコントローラ３４１は、階層間再配置を監視期間後即時に実行する。自動実行モードで実行される階層間再配置を、定期階層間再配置と呼ぶ。手動実行モードにおいて、階層間再配置は、管理者が指示した任意のタイミングで行われる。手動実行モードの場合は、監視期間の開始時刻、終了時刻及び周期は、全て未設定である。管理者は、監視期間の開始及び終了を任意のタイミングで指示する。
　図９は、プールボリューム情報テーブル５１２の一例を示し、各プールボリュームの構成情報を格納する。プールボリューム情報テーブル５１２は、プールボリュームＩＤのカラム９０１、Ｔｉｅｒのカラム９０２、プールボリューム容量のカラム９０３、プールボリューム空き容量のカラム９０４、プールＩＤのカラム９０５を有する。
　プールボリュームＩＤは、プールボリュームの識別情報である。Ｔｉｅｒのカラム９０２は、プール内での階層の識別情報（階層種別の識別情報）を格納する。本例において、全てのプールボリューム(リソース)の容量は同一であるが、容量はプールボリューム毎に異なってもよい。
　図１０は、プール内Ｔｉｅｒ情報テーブル５１３の一例を示す。プール内Ｔｉｅｒ情報テーブル５１３は、各プールにおける各階層の構成情報を格納する。プール内Ｔｉｅｒ情報テーブル５１３は、プールＩＤのカラム１００１、Ｔｉｅｒのカラム１００２、構成リソース数のカラム１００３、Ｔｉｅｒ容量のカラム１００４を有する。構成リソース数は、階層内のプールボリューム数である。
　図１１は、ページ情報テーブル５１４の一例を示す。ページ情報テーブル５１４は、各ページの所属ボリューム及びＩ／Ｏ量に関する情報を格納する。具体的には、ページ情報テーブル５１４は、プールＩＤのカラム１１０１、ページＩＤのカラム１１０２、仮想ボリュームＩＤのカラム１１０３、プールボリュームＩＤのカラム１１０４、Ｔｉｅｒのカラム１１０５、前回監視期間Ｉ／Ｏ量のカラム１１０６を有する。
　Ｔｉｅｒのカラム１１０５の各フィールドは、各レコードのページが格納されている階層の種別を格納する。この値は、リソース移動のためのデータ退避及び階層間再配置において更新される。
　前回監視期間Ｉ／Ｏ量のカラム１１０６は、前回の監視期間で計測したページへのＩ／Ｏ量を格納する。情報収集機能５０１は、ストレージシステム３４０のコントローラ３４１からその値を取得し、ページ情報テーブル５１４に格納する。
　図１２は、時間帯平均ＩＯＰＳ情報テーブル５１９の一例を示す。時間帯平均ＩＯＰＳ情報テーブル５１９は、プールＩＤのカラム１２０１、時間帯のカラム１２０２、時間帯平均ＩＯＰＳのカラム１２０３、更新回数のカラム１２０４を有する。時間帯平均ＩＯＰＳは、図６におけるフローチャートのＳ６０２で説明したように、各時間帯（本例において１０分の時間帯）におけるＩＯＰＳの測定値の平均値である。情報収集機能５０１が、この値を更新する。更新は監視期間周期で行われる。
　図１３は、Ｉ／Ｏ履歴情報テーブル５２０の一例を示す。Ｉ／Ｏ履歴情報テーブル５２０は、各プールについて、直近４８時間以内の定期的な（本例では１０分間隔）ＩＯＰＳの履歴を格納するテーブルである。Ｉ／Ｏ履歴情報テーブル５２０は、プールＩＤのカラム１３０１、日時のカラム１３０２、ＩＯＰＳのカラム１３０３を有する。日時のカラム１３０２のフィールドは、該当レコードのプールＩＤが示すプールにおける、ＩＯＰＳ測定期間を示す時刻を格納する。情報収集機能５０１は、各プールのＩＯＰＳをストレージシステム３４０のコントローラ３４１から取得する。
　次に、図１４のフローチャートを参照して、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１の更新処理（図６におけるＳ６０３）を説明する。この処理の流れを説明する前に、本処理が使用するプール内Ｔｉｅｒ性能情報テーブル５２３及びＩＯＰＳ対レスポンスタイム相関情報テーブル５２１を説明する。
　図１５は、プール内Ｔｉｅｒ性能情報テーブル５２３の一例を示している。プール内Ｔｉｅｒ性能情報テーブル５２３は、各プールの各Ｔｉｅｒのアクセス性能情報、本例において、レスポンスタイムを格納している。
　図１５に示すように、プール内Ｔｉｅｒ性能情報テーブル５２３は、プールＩＤのカラム１５０１、Ｔｉｅｒのカラム１５０２、日時のカラム１５０３、レスポンスタイムのカラム１５０４を有する。情報収集機能５０１は、各プールの各Ｔｉｅｒを構成するリソースのレスポンスタイムを、ストレージシステム３４０のコントローラ３４１から取得し、Ｔｉｅｒのレスポンスタイムとして、レスポンスタイムのカラム１５０４に格納する。
　図１６は、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１の一例を示す。ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１は、ストレージシステム内の各ＴｉｅｒのＩＯＰＳとレスポンスタイムの相関関係を示す情報を格納し、ＩＯＰＳをレスポンスタイムに換算するために参照される。
　このテーブル５２１は、ストレージシステム３４０内の全てのプールに共通である。ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１は、Ｔｉｅｒのカラム１６０１、ＩＯＰＳ帯のカラム１６０２、ＩＯＰＳ帯平均レスポンスタイムのカラム１６０３、累計Ｉ／Ｏ量のカラム１６０４を有する。
　ＩＯＰＳ帯平均レスポンスタイムのカラム１６０３は、各ＩＯＰＳ帯の過去のレスポンスタイム測定値の平均値を格納する。本例において、この平均値は、Ｉ／Ｏ量の加重平均である。累計Ｉ／Ｏ量のカラム１６０４は、各ＩＯＰＳ帯での、過去の監視測定におけるＩ／Ｏ量の累計を格納する。
　図１４に戻って、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１の更新処理は、情報収集処理において行われる。情報収集機能５０１は、この更新処理において、Ｓ１４０１とＳ１４１１の間のステップをプール毎に繰り返す。
　まず、情報収集機能５０１は、Ｉ／Ｏ履歴情報テーブル５２０を参照し、該当プールの最新のＩＯＰＳを取得する（Ｓ１４０２）。情報収集機能５０１は、ページ情報テーブル５１４を参照し、Ｔｉｅｒカラム１１０５の値が同一の前回監視期間Ｉ／Ｏ量カラム１１０６の値を合算し、Ｔｉｅｒ毎のＩ／Ｏ量合計を算出する（Ｓ１４０３）。情報収集機能５０１は、さらに、同一プール内のＴｉｅｒのＩ／Ｏ量合計を合算し、プールのＩ／Ｏ量合計を算出する（Ｓ１４０４）。
　情報収集機能５０１は、Ｓ１４０５とＳ１４１０の間のステップをプールのＴｉｅｒ毎に繰り返す。まず、情報収集機能５０１は、Ｓ１４０３で算出した該当ＴｉｅｒのＩ／Ｏ量合計を、Ｓ１４０４で算出したプールのＩ／Ｏ量合計で割り、該当ＴｉｅｒのＩ／Ｏ比率を算出する（Ｓ１４０６）。情報収集機能５０１は、Ｓ１４０２で取得したプールのＩＯＰＳに、ステップＳ１４０４で算出した該当ＴｉｅｒのＩ／Ｏ比率を掛け合わせ、該当ＴｉｅｒのＩＯＰＳを算出する（Ｓ１４０７）。
　情報収集機能５０１は、プール内Ｔｉｅｒ性能情報テーブル５２３を参照し、該当Ｔｉｅｒの最新のレスポンスタイムを取得する（Ｓ１４０８）。情報収集機能５０１は、Ｓ１４０８で取得した該当Ｔｉｅｒのレスポンスタイムと、Ｓ１４０７で算出した該当ＴｉｅｒのＩＯＰＳを基に、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１の、ＩＯＰＳ帯平均レスポンスタイムカラム１６０３の値を更新する（Ｓ１４０９）。さらに、情報収集機能５０１は、累計Ｉ／Ｏ量カラム１６０４を更新する。
　具体的には、情報収集機能５０１は、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１のＴｉｅｒカラム１６０１とＩＯＰＳ帯カラム１６０２を参照して、該当Ｔｉｅｒの識別情報及び該当ＴｉｅｒのＩＯＰＳをキーに、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１から該当レコードを選択する。
　情報収集機能５０１は、該当レコードのＩＯＰＳ帯平均レスポンスタイムのカラム（フィールド）１６０３に格納されている値に、上記当該レコードの累計Ｉ／Ｏ量カラム（フィールド）１６０４に格納されている累計Ｉ／Ｏ量を掛け合わせる（積算値１）。さらに、情報収集機能５０１は、Ｓ１４０８で取得した該当Ｔｉｅｒの最新レスポンスタイムとＳ１４０３で算出した該当ＴｉｅｒのＩ／Ｏ量合計を掛け合わせる（積算値２）。
　情報収集機能５０１は、上記積算値１と積算値２を加算する（加算値１）。さらに、当該レコードの上記累計Ｉ／Ｏ量とＳ１４０３で取得した該当ＴｉｅｒのＩ／Ｏ量合計とを加算する（加算値２）。この加算値２は、累計Ｉ／Ｏ量の新しい更新値である。
　情報収集機能５０１は加算値１を加算値２で割り、この計算結果が、ＩＯＰＳ帯平均レスポンスタイムの新しい更新値であり、レスポンスタイムのＩ／Ｏ量の加重平均である。情報収集機能５０１は、更新値を、当該レコードのＩＯＰＳ帯平均レスポンスタイムのカラム１６０３に格納する。情報収集機能５０１は、当該レコードの上記累計Ｉ／Ｏ量とＳ１４０６で取得した該当ＴｉｅｒのＩＯＰＳとの加算値（加算値２）を、当該レコードの累計Ｉ／Ｏ量カラム１６０４に格納する。
　以下において、管理サーバ３２０による性能管理処理を説明する。管理プログラム３２６の性能管理機能５０２は、情報収集機能５０１により収集された情報を使用して、性能管理処理を実行する。図１７は、性能管理処理例のフローチャートを示す。図１７のフローチャートを参照して説明する前に、性能管理機能５０２の処理の概略を説明する。
　性能管理機能５０２は定期的に、ストレージシステム３４０内のプールの性能使用率をチェックし、性能が不足しているプール（危険プール）が存在しているかチェックする。性能管理機能５０２は危険プールを検知した場合、危険プールの性能を回復するための処理を実施する。
　具体的には、性能管理機能５０２は、追加する必要のあるリソース（プールボリューム）の種別及び量を算出する。性能管理機能５０２は、算出したリソースを解除し、階層間再配置を行った後にＳＬＯ違反を起こさない見込みのプールを、シミュレーションにより特定する。性能管理機能５０２は、ＳＬＯを違反せずにリソース解除が可能と判断されたプールを提供元プール候補に追加する。
　全てのプールに関して上記処理を実施したら、好ましくは、性能管理機能５０２は、提供元プール候補の中から、リソース解除完了時刻（危険プールへのリソース追加時刻）が最も早いプールを提供元プールに決定する。通常、リソース解除完了時刻はデータ退避完了時刻と一致する。最も早い時刻にリソース解除完了可能なプールが複数ある場合、その中から階層間再配置後の性能劣化度合いが最も低いプールを採用することが好ましい。
　具体的には、性能管理機能５０２は、提供元プール候補のそれぞれに関して、プールからリソースを解除した後に即時に階層間再配置を行う場合と、即時の階層間再配置を行わない場合の両方について、リソース移動開始（データ退避開始）から階層間再配置完了までの期間にＳＬＯを違反しない、リソース移動開始時刻及びリソース解除完了時刻（データ退避完了時刻）を算出する。
　両方の提供パターンでＳＬＯを違反しないリソース解除開始時刻及びリソース解除完了時刻が見つかった場合、より早いリソース解除完了時刻（危険プールへのリソース追加可能時刻）を持つパターンを、そのプールからの提供パターンとする。
　性能管理機能５０２は、最も早いリソース解除完了時刻の提供パターンの提供元プールから、その提供パターンにおけるリソース解除開始時刻に、リソース移動（リソース解除及び危険プールへの追加）を開始する。好ましい構成において、性能管理機能５０２は、データ退避中に、リアルタイムのＩ／Ｏ情報を取得する。Ｉ／Ｏ量が予測に反して多く、ＳＬＯ違反が発生する危険性を性能管理機能５０２が検知した場合は、リソース移動を中断する。性能管理機能５０２はリアルタイムのＩ／Ｏの監視を行わなくともよい。
　性能管理機能５０２は、危険プールに関しても、移動元プールと同様の方法でＳＬＯ違反が発生するか否かを予測する。ＳＬＯ違反が発生する可能性が高い場合、性能管理機能５０２は、いずれのプールにも属していないボリュームを危険プールに追加した場合にＳＬＯ違反を回避できるかをシミュレーションにより判定する。
　ＳＬＯ違反が回避可能と判定した場合、性能管理機能５０２は、いずれのプールにも属していない不使用ボリュームを危険プールに追加する。ＳＬＯ違反が回避不可能と判定した場合は、性能管理機能５０２は、危険プールにおいてＳＬＯ違反発生の可能性が高く、プールへのボリューム追加では回避不可能であることを入出力デバイス３２４の画面に表示し、管理者に通知する。
　図１７を参照して、性能管理処理を説明する。性能管理機能５０２は、性能監視処理を行う（Ｓ１７０１）。具体的には、性能管理機能５０２は、ストレージシステム３４０内の各仮想ボリューム４０１及び各プール４０２の性能を確認し、性能問題が発生している仮想ボリューム４０１を検知する。性能管理機能５０２は、当該仮想ボリューム４０１が属するプール（危険プール）のＩＤ及び性能余剰率を、危険プール群テーブル５１８に追加する。性能余剰率及び性能監視処理（Ｓ１７０１）の詳細は、後ほど図１８を用いて説明する。
　図１９は、危険プール群テーブル５１８の一例を示している。危険プール群テーブル５１８は、危険プールＩＤのカラム１９０１、仮想ボリューム性能余剰率のカラム１９０２を有する。危険プールＩＤのカラム１９０１は、性能監視処理で危険プールと判定されたプールのＩＤを格納し、仮想ボリューム性能余剰率のカラム１９０２は、各プール（の仮想ボリューム）の性能余剰率を格納する。
　図１７に戻って、性能管理機能５０２は、Ｓ１７０１で実施した性能監視処理の結果を受けて、性能問題が発生していたか否かを判定する（Ｓ１７０２）。性能問題が発生していた場合（Ｓ１７０２：ＹＥＳ）、性能管理機能５０２は、Ｓ１７０３を実行する。Ｓ１７０１において性能問題が発生していない場合（Ｓ１７０２：ＮＯ）、性能管理機能５０２は、処理を終了する。
　Ｓ１７０３において、性能管理機能５０２は、性能問題改善計画処理を行い、Ｓ１７０１で検知した性能問題の発生しているプールの性能を改善する計画を立てる。具体的には、性能管理機能５０２は、ストレージシステム３４０内の他のプールからリソース（実ボリューム）を危険プールに移動する計画の候補を作成し、リソース移動計画候補テーブル５１５に格納する。性能問題改善計画処理（Ｓ１７０３）の詳細は、後ほど図２０を用いて説明する。リソース移動計画候補テーブル５１５の詳細は、後ほど図２４を用いて説明する。
　性能管理機能５０２は、Ｓ１７０３で実行した性能問題改善計画処理の結果を受けて、Ｓ１７０１で検知した危険プールの性能問題が、プール間のリソース移動で解決可能かどうかを判定する（Ｓ１７０４）。危険プールの性能問題が解決可能な場合（Ｓ１７０４：ＹＥＳ）、性能管理機能５０２は、Ｓ１７０５を実行する。危険プールの性能問題が解決可能でない場合（Ｓ１７０４：ＮＯ）、性能管理機能５０２は、Ｓ１７０６を実行する。
　Ｓ１７０６において、性能管理機能５０２は、即時にストレージシステム３４０内の不使用リソースを危険プールに追加することにより、危険プールでのＳＬＯ違反発生を回避できるかを判定する。ＳＬＯ違反発生を回避出来ると判定した場合（Ｓ１７０６：ＹＥＳ）、性能管理機能５０２は、Ｓ１７０７を実行する。ＳＬＯ違反発生を回避出来ないと判定した場合（Ｓ１７０６：ＮＯ）、性能管理機能５０２は、Ｓ１７０８を実行する。
　上記Ｓ１７０６における判定において、性能管理機能５０２は、性能問題改善計画処理（Ｓ１７０３）で呼ばれるリソース移動計画作成処理（図２０及び図２３のＳ２００３を参照）と同様の方法を、危険プールに適用することができる。
　具体的には、性能管理機能５０２は、危険プールに即時に不使用リソースを追加し、危険プール内でページのリバランス（階層内ページ再配置）が行われた後のページ配置を予測し、履歴情報と併せて、リソース追加後の各時間帯における危険プールのレスポンスタイムを予測する。リバランスについてはＳ１７０７の説明で述べる。
　この予測は、提供元プールのリソース移動後のレスポンスタイムの予測と同様の方法でよい。性能管理機能５０２は、レスポンスタイムの予測値を基に、危険プールがＳＬＯ違反を起こさないかどうかを確認する。リソース移動計画作成処理（Ｓ２００３）の詳細は後述する。
　Ｓ１７０７において、性能管理機能５０２は、危険プールにストレージシステム３４０内のリソースを即時追加する。そして、性能管理機能５０２は、各Ｔｉｅｒにおいて、ページのリバランス処理を実行する。リバランス処理は、配置されているページのＩ／Ｏ量が、Ｔｉｅｒ内のリソース（プールボリューム）間で均一となる様に、Ｔｉｅｒ内でページを再配置する。
　Ｓ１７０８において、性能管理機能５０２は、危険プールの性能が危険プールへのリソース追加では解決困難であることを伝えるアラートを、管理プログラムの画面表示にて管理者に通知する。
　上述のように、プール間のリソース移動により危険プールの性能問題が解決可能な場合（Ｓ１７０４：ＹＥＳ）、性能管理機能５０２は、Ｓ１７０５を実行する。性能管理機能５０２は、Ｓ１７０３で作成したリソース移動計画を基に、リソースの移動を実行する。具体的には、性能管理機能５０２は、リソース移動計画テーブル５１６を参照し、リソース移動計画テーブル５１６のレコードに従ってリソースを移動する。
　性能管理機能５０２は、ストレージシステム３４０のコントローラ３４１にリソース移動を指示し、コントローラ３４１が、その指示に応じて転送元プールから危険プールにリソースを移動する。コントローラ３４１は、性能管理機能５０２からの指示に従って、転送元プールにおいて移動リソースから空きリソースにデータを退避し、さらに、リソースを転送元プールから危険プールに追加する。コントローラ３４１は、必要により、転送元プールにおけるリソース解除後の階層間再配置及び定期階層間再配置を実行する。
　図２７は、リソース移動計画テーブル５１６の例を示している。リソース移動計画テーブル５１６は、図２３を参照して後述するリソース移動計画作成処理（Ｓ２００４）にて、リソース移動計画候補から採用されたリソース移動計画を格納するテーブルである。リソース移動計画テーブル５１６の情報を基に、性能管理機能５０２がリソース移動を実行する。リソース移動計画テーブル５１６の詳細は後述する。
　リソース移動に伴い、性能管理機能５０２は、移動するリソースからのデータ退避を含む移動するリソースの提供元プールからの解除、移動するリソースの危険プールへの追加、危険プールのリソースが追加されたＴｉｅｒ内でのリバランス（階層内ページ再配置）、転送元プールでの階層間再配置、を実行する。
　本例において、プールからプールボリューム（リソース）を解除する際、性能管理機能５０２は、プールから解除するプールボリュームに配置されているページを、プール内の別のプールボリュームに退避する。具体的には、性能管理機能５０２は、解除対象プールボリュームの属するＴｉｅｒのプールボリュームの空き領域に、退避ページを退避する。
　同一Ｔｉｅｒ内のプールボリュームに、充分な空きが無い場合、性能管理機能５０２は、一つ上のＴｉｅｒのプールボリュームの空き領域に残りの退避ページを退避する。一つ上のＴｉｅｒが存在しない場合、つまり解除対象のプールボリュームが最上位Ｔｉｅｒに属している場合、もしくは、一つ上のＴｉｅｒ内のプールボリュームに充分な空きが無い場合、性能管理機能５０２は、一つ下のＴｉｅｒに属するプールボリュームに残りの退避ページを退避する。
　一つ下のＴｉｅｒ内のプールボリュームに充分な空きが無い場合、性能管理機能５０２は、さらに一つ下のＴｉｅｒ（存在すれば）に属するプールボリュームに残りの退避ページを退避する。性能管理機能５０２は、この方法による退避先検索を繰り返す。
　プール内に、全退避ページを退避するための充分な空き容量が無い場合、プールからのプールボリュームの解除は失敗する。Ｔｉｅｒ内のデータは、そのＴｉｅｒを構成するプールボリュームに分散して配置されているため、退避ページも空きプールボリューム間で分散して書き込まれる。
　なお、本構成例では、退避ページの退避される順番は、監視期間中に計測したＩ／Ｏ量の高いページから順に退避されることとする。より正確な性能予測のために、ページ退避の規則が決まっていることが必要であるが、そのページ退避方法は、上記方法と異なっていてもよい。
　リソースを移動している間（データ退避中）、性能管理機能５０２は、プール情報テーブル５１１を参照し、提供元プールへのリアルタイムＩＯＰＳを一定時間おきに監視する。性能管理機能５０２は、リアルタイムＩＯＰＳがＳ１７０３の性能問題改善計画処理で予測した提供元プールへのＩＯＰＳよりも多く、ＳＬＯ違反を引き起こす可能性が高いと判定した場合、リソース移動の実行を中止する。性能管理機能５０２は、その旨を管理者に伝えるために、管理サーバ３２０の表示画面にアラートを表示する。
　性能管理機能５０２は、提供元プールのリアルタイムＩＯＰＳが予測に反して高く、ＳＬＯ違反を引き起こす可能性が高いか否かの判定を、例えば、以下の方法で行う。性能管理機能５０２は、一定間隔のリアルタイムＩＯＰＳの近似直線を最小二乗法により算出する。性能管理機能５０２は、その近似直線の一定間隔毎の値と、近似直線よりも低い値であるＩＯＰＳ予測値との乖離を算出する。
　乖離が増加傾向にあり、ＩＯＰＳのピーク予測値と現在の乖離との和と、ＳＬＯの要求レスポンスタイムに対応するＩＯＰＳとの差が、所定閾値より小さい場合、性能管理機能５０２は、提供元プールがＳＬＯ違反を起こす可能性が高いと判定する。
　図１８のフローチャートを参照して、性能管理処理で呼ばれる性能監視処理（Ｓ１７０１）の例を説明する。性能管理機能５０２は、Ｓ１８０１からＳ１８０５を仮想ボリューム毎に繰り返す。性能管理機能５０２は、仮想ボリュームについて、性能余剰率を算出する(Ｓ１８０２)。具体的には、性能管理機能５０２は、仮想ボリューム情報テーブル５２２を参照し、当該仮想ボリュームの最新レスポンスタイムと、当該仮想ボリュームの要求レスポンスタイム上限から、以下の式により性能余剰率を算出する。
　仮想ボリュームの性能余剰率（％）＝（１００－（最新レスポンスタイム／要求レスポンスタイム上限）×１００）
　次に、性能管理機能５０２は、Ｓ１８０２で算出した仮想ボリュームの性能余剰率が、管理者の設定した性能余剰率の下限閾値を下回っているか判定する(Ｓ１８０３)。性能余剰率が閾値よりも小さい場合（Ｓ１８０３：ＹＥＳ）、性能管理機能５０２は、ステップＳ１８０４を実行する。性能余剰率が閾値以上である場合（Ｓ１８０３：ＮＯ）、性能管理機能５０２は、該当仮想ボリュームについての処理を終了する。
　Ｓ１８０４において、性能管理機能５０２は、Ｓ１８０２で性能余剰率が下限閾値を下回っているプールを危険プールと判定し、その危険プールの情報（プールＩＤ及び仮想ボリュームの性能余剰率）を危険プール群テーブル５１８に追加する。
　図２０のフローチャートを参照して、性能問題改善計画処理（Ｓ１７０３）の例を説明する。性能問題改善計画処理（Ｓ１７０３）は、性能管理処理（図１７参照）で呼ばれる。
　性能管理機能５０２は、危険プール群テーブル５１８を参照し、性能余剰率が低い危険プールから順に、Ｓ２００１からＳ２００５を繰り返し実行する。Ｓ２００２において、性能管理機能５０２は、危険プールの性能を改善するための追加リソース算出処理を行う。これは、危険プールのどの階層にどれだけのリソースを追加する必要があるかを算出する。追加リソース算出処理（Ｓ２００２）の詳細は、図２１を用いて後ほど説明する。
　次に、性能管理機能５０２は、危険プール以外のプールに関して、性能余剰率一日平均及び、リソース移動後性能余剰率一日平均を算出し、リソース移動計画候補テーブル５１５を更新する（Ｓ２００３）。リソース移動計画候補テーブル５１５は、危険プールの性能を回復するためのリソース移動計画の候補一覧を格納する。
　図２４は、リソース移動計画候補テーブル５１５の一例を示す。リソース移動計画候補テーブル５１５は、提供元プールＩＤのカラム２１０１、即時階層間再配置有無のカラム２１０２、リソース移動開始時刻のカラム２１０３、リソース解除完了見込み時刻のカラム２１０４、性能余剰率一日平均のカラム２１０５、リソース解除後性能余剰率のカラム２１０６を有する。
　図２０に戻って、性能管理機能５０２は、Ｓ２００３において、まず、該当プール（危険プール以外のプール）のレスポンスタイム一日平均を算出する。性能管理機能５０２は、プール内Ｔｉｅｒ性能情報テーブル５２３を参照し、該当時間帯から２４時間前の時間帯までの各Ｔｉｅｒのレスポンスタイムを取得し、その平均値を算出する。
　また、ページ情報テーブル５１４の前回監視期間Ｉ／Ｏ量カラム１１０６から、プールの各Ｔｉｅｒ内の全てのページのＩ／Ｏ量の合計を算出する。この値は、各ＴｉｅｒのＩ／Ｏ量合計である。性能管理機能５０２は、これらの値を使用し、以下の式によりプールのレスポンスタイム一日平均を算出する。
　プールのレスポンスタイム一日平均＝（Σ（ＴｉｅｒのＩ／Ｏ量合計×Ｔｉｅｒのレスポンスタイム一日平均））／プールのＩ／Ｏ量合計
　性能管理機能５０２は、次に、プールのレスポンスタイム一日平均を基に、以下の式によりプールの性能余剰率一日平均を算出する。要求レスポンスタイム上限値は、例えば、該当プールの全ての仮想ボリュームに対して定義された要求レスポンスタイム上限値の内の最小値である。
　プールの性能余剰率一日平均（％）＝１００－（プールのレスポンスタイム一日平均／要求レスポンスタイム上限）×１００
　性能管理機能５０２は、プールＩＤ及び算出した性能余剰率一日平均を、リソース移動計画候補テーブル５１５に追加する。また、プール情報テーブル５１１の該当プールのレコードの性能余剰率一日平均カラム８０７の値を更新する。
　次に、性能管理機能５０２は、リソース解除後のプールのレスポンスタイム一日平均を算出する。性能管理機能５０２は、Ｓ２００１で算出した危険プールに追加するリソースをプールから解除して、階層間再配置を実行した後のページ配置を予測する。性能管理機能５０２は、そのページ配置を基に、プールの各ＴｉｅｒのＩ／Ｏ量合計予測値を算出する。そして、以下の式により、リソース解除後のプールのレスポンスタイム一日平均を予測する。
　プールのレスポンスタイム一日平均予測値＝（Σ（ＴｉｅｒのＩ／Ｏ量合計予測値×Ｔｉｅｒのレスポンスタイム一日平均））／プールのＩ／Ｏ量合計
　次に、性能管理機能５０２は、プールのレスポンスタイム一日平均を基に、以下の式によりプールの性能余剰率一日平均を算出する。
　リソース解除後性能余剰率一日平均（％）＝１００－（プールのレスポンスタイム一日平均予測値／要求レスポンスタイム上限）×１００
　さらに、性能管理機能５０２は、リソース移動計画候補テーブル５１５の該当プールのレコードのリソース移動後性能余剰率一日平均カラム２４０６を更新する。Ｓ２００４において、性能管理機能５０２は、リソース移動計画作成処理を行う。リソース移動計画作成処理の詳細は、後ほど図２３を用いて説明する。
　次に、図２１を参照して、追加リソース算出処理（Ｓ２００２）の例を説明する。この処理は、危険プールに追加する必要のあるリソースを算出する。性能管理機能５０２は、追加コストを１から危険プールの総コストまで１ずつ増やしながら、Ｓ２１０１からＳ２１１１を繰り返す。
　追加コストは、危険プールに追加するリソースの合計コストである。Ｔｉｅｒ定義テーブル５１７は、各ドライブ種別のコストを格納している。コストは、例えば、単位容量当たりのドライブの価格から算出される。図２２はＴｉｅｒ定義テーブル５１７の一例を示す。Ｔｉｅｒ定義テーブル５１７は、Ｔｉｅｒ毎の構成ドライブ種別、及びプールボリューム（リソース）一つあたりのコスト、Ｔｉｅｒを構成するドライブの転送性能を格納する。
　つまり、Ｔｉｅｒ定義テーブル５１７は、Ｔｉｅｒのレベルを格納するカラム２２０１、ドライブ種別のカラム２２０２、コストのカラム２２０３、そして転送性能のカラム２２０４を有する。本実施例では、各プールボリュームの容量を同一としているため、Ｔｉｅｒ定義テーブル５１７はプールボリューム（リソース）あたりのコストを格納するが、特定容量あたりのコストを格納してもよい。本テーブル５１７が格納する各値は、管理者があらかじめ設定する。
　危険プールが必要とする性能を、最も少ない追加コスト（提供元プールから危険プールに移動するプールボリュームの総コスト）で回復することが好ましい。そこで、本例において、性能管理機能５０２は、追加コストを上げながら、追加コストで追加できるボリュームパターン（リソースパターン）を算出し、パターンのボリュームを危険プールに追加した場合の危険プールの性能をチェックする。危険プールの性能がＳＬＯを満たす場合、性能管理機能５０２は、そのボリューム追加パターンを採用する。
　設計によっては、追加コストに拠らず、ボリューム追加パターンを決定してもよい。例えば、性能管理機能５０２は、性能が高いボリューム又は性能が低いボリュームから順次選択して、危険プールの性能がＳＬＯを満たすボリューム追加パターンを決定してもよい。
　ボリューム追加パターンは、危険プールの各Ｔｉｅｒに追加するプールボリューム（リソース）の数を示すパターンである。つまり、危険プールのどのＴｉｅｒにどれだけのプールボリューム（リソース）を追加するかを示す。例えば、パターンの一例は、Ｔｉｅｒ０の追加ボリューム数が０、Ｔｉｅｒ１の追加ボリューム数が１、そしてＴｉｅｒ２の追加ボリューム数が２である。
　図２１に戻って、性能管理機能５０２は、追加リソース数を（追加コスト／最下位Ｔｉｅｒコスト）から（追加コスト／最上位Ｔｉｅｒコスト）まで１ずつ減らしながら、Ｓ２１０２からＳ２１１０を繰り返す。性能管理機能５０２は、さらに、最下位リソース数を（追加コスト／最下位Ｔｉｅｒコスト）から０まで１ずつ減らしながら、Ｓ２１０３からＳ２１０５を繰り返す。このように、本例は、より下位のＴｉｅｒのプールボリューム数（リソース数）がより多いボリューム追加パターンから試す。
　Ｓ２１０４において、性能管理機能５０２は、追加コストと追加リソース数に合致するリソースの追加パターンをリストに追加する。性能管理機能５０２は、Ｓ２１０６からＳ２１０９を、上記追加パターンのリストの先頭から繰り返す。Ｓ２１０７において、性能管理機能５０２は、追加パターン適用時の性能余剰率をチェックする。
　Ｓ２１０８において、性能管理機能５０２は、ボリューム追加後の性能余剰率と下限閾値とを比較する。性能余剰率が下限閾値以上である場合（Ｓ２１０８：ＮＯ）、性能管理機能５０２は、その追加パターンを採用する。性能余剰率が下限閾値より小さい場合（Ｓ２１０８：ＹＥＳ）、性能管理機能５０２は、ループを繰り返す。
　Ｓ２１０７における性能余剰率のチェックにおいて、性能管理機能５０２は、リソース移動計画作成処理（図２０及び図２３のＳ２００３を参照）と同様の方法を、危険プールに適用することができる。
　具体的には、性能管理機能５０２は、危険プールに追加パターンに従ったプールボリュームを追加し、危険プール内でページのリバランス（階層内ページ再配置）が行われた後のページ配置を予測する。さらに、その予測と履歴情報と併せて、プールボリューム追加後の各時間帯における危険プールのレスポンスタイムを予測する。この予測は、提供元プールのリソース移動後のレスポンスタイムの予測と同様の方法でよい。性能管理機能５０２は、レスポンスタイムの予測値を基に、危険プールがＳＬＯ違反を起こさないかどうかをチェックする。
　上記追加リソースパターンの決定方法は一例であって、性能管理機能５０２は、これと異なる方法を使用することができる。例えば、性能管理機能５０２は、最上位リソースの数が最も多くなるように、追加リソースパターンを決定してもよい。
　図２３を参照して、リソース移動計画作成処理（Ｓ２００４）の例を説明する。図２３のフローチャートにおいて、性能管理機能５０２は、Ｓ２３０１からＳ２３０９を、リソース移動開始時刻（転送元プールにおけるデータ退避開始時刻）を、本処理の実行時刻からシミュレーション終了時刻まで所定時間間隔ずつ進めながら繰り返す。時間間隔は例えば１０分であり、典型的には一定である。
　本例において、シミュレーション終了時刻は、本処理の実行時刻、即ち、危険プールを検知した時刻より、２４時間後の時刻とする。これは、仮想ボリュームへのＩ／Ｏ負荷の変動周期は２４時間であるという仮定に基づく。２４時間後の時刻の代わりに、２４時間から危険プールの階層間再配置見込み所要時間を引いた時間が経過した後の時刻としてもよい。
　性能管理機能５０２は、階層間再配置にかかる時間を、下に説明するリソース解除見込み所要時間算出（Ｓ２３０３）と同様の方法で算出する。
　性能管理機能５０２は、Ｓ２３０２からＳ２３０７を、危険プール以外のプール毎に繰り返す。性能管理機能５０２は、Ｓ２３０３において、リソース解除見込所要時間を算出する。具体的には、性能管理機能５０２は、転送経路毎の転送データ量を算出し、転送経路毎の転送速度を得て、転送経路毎の転送データ量及び転送経路毎の転送速度を基にリソース解除の見込み所要時間を算出する。転送経路は、プール内のＴｉｅｒ間の転送経路である。
　転送経路毎の転送データ量の算出において、性能管理機能５０２は、プールボリューム情報テーブル５１２を参照し、解除対象のリソースのプールボリュームＩＤをキーに、プールボリューム容量及び空き領域を取得し、プールボリュームの使用容量を算出する。そして、同一プールに属するプールボリュームのうち、空き領域のあるプールボリュームを検索する。
　性能管理機能５０２は、各退避ページの退避先Ｔｉｅｒを決定する。Ｓ１７０５で説明したプールからのリソース解除時のページ退避手順により、各退避ページの退避先Ｔｉｅｒが決まる。性能管理機能５０２は、ページの転送元Ｔｉｅｒ（解除対象リソース（プールボリューム）が属するＴｉｅｒ）と各転送先Ｔｉｅｒの組み合わせ（転送経路）毎の転送データ量を求める。
　さらに、性能管理機能５０２は、プール内Ｔｉｅｒ間でデータを転送する際の転送速度を、転送経路毎に求める。特定の転送経路の転送速度を求める際は、性能管理機能５０２は、Ｔｉｅｒ定義テーブル５１７を参照し、データの転送元Ｔｉｅｒ及び転送先Ｔｉｅｒの転送性能を取得する。性能管理機能５０２は、より低速な転送性能の値を、該当転送経路の転送速度として使用する。
　性能管理機能５０２は、転送経路毎の転送データ量及び転送経路毎の転送速度を基に、以下の式によりリソース解除の見込み所要時間を算出する。
　リソース解除見込み所要時間＝Σ［転送経路毎］（転送経路の転送データ量／転送経路の転送速度）
　次に、性能管理機能５０２は、データ退避中性能チェック処理を行う（Ｓ２３０４）。データ退避中性能チェック処理については、図２５を参照して、後に詳述する。さらに、性能管理機能５０２は、データ退避後性能チェック処理を行う（Ｓ２３０５）。データ退避後性能チェック処理については、図２６を参照して、後に詳述する。
　データ退避中性能チェック処理（Ｓ２３０４）及びデータ退避後性能チェック処理（Ｓ２３０５）の結果を受けて、性能管理機能５０２は、ＳＬＯ違反の発生の有無を判定する（Ｓ２３０６）。ＳＬＯ違反が発生していない場合（Ｓ２３０６：ＮＯ）、性能管理機能５０２は、リソース移動計画候補テーブル５１５の当該プールのレコードを更新し（Ｓ２３０８）、Ｓ２３０７に進む。ＳＬＯ違反が発生している場合（Ｓ２３０６：ＹＥＳ）、性能管理機能５０２は、Ｓ２３０７に進む。
　上記二重ループを抜けた後、Ｓ２３１０において、性能管理機能５０２は、採用するリソース移動計画を決定する。具体的には、性能管理機能５０２は、リソース移動計画候補テーブル５１５を参照し、リソース解除完了見込み時刻（データ退避完了見込み時刻）が最も早いレコード（リソース移動計画）を探す。それが一意に決まる場合、性能管理機能５０２は、そのリソース移動計画を採用する。
　同一解除完了見込み時刻の複数のリソース移動計画がヒットした場合、性能管理機能５０２は、その中からリソース解除後（リソース移動後）のプールの性能余剰率が最も高いリソース移動計画を探す。それが一意に決まる場合、性能管理機能５０２は、そのリソース移動計画を採用する。
　同一性能余剰率の複数のレコードがヒットした場合（提供元プールは決定している見込）、性能管理機能５０２は、即時階層間再配置有無カラム２４０２のフィールドの値が「無」であるリソース移動計画を採用する。
　性能管理機能５０２は、採用したリソース移動計画を基に、リソース移動計画テーブル５１６を更新する。図２７は、リソース移動計画テーブル５１６の例を示している。リソース移動計画テーブル５１６は、提供元プールＩＤのカラム２７０１、提供先プールＩＤのカラム２７０２、移動リソースＩＤのカラム２７０３、即時階層間再配置有無のカラム２７０４、移動開始時刻のカラム２７０５を有する。
　性能管理機能５０２は、リソース移動計画テーブル５１６の移動リソースＩＤのカラム（フィールド）２７０３に入る値を、プール情報テーブル５１１から取得する。具体的には、性能管理機能５０２は、プール情報テーブル５１１を参照し、提供元プールを構成するリソース（プールボリューム）から、図２１の追加リソース算出処理（Ｓ２００２）で算出した危険プールに追加するリソースと合致するものを検索し、その値を格納する。
　リソース移動計画の選択は、上記方法に従うことが好ましいが、性能管理機能５０２は、これと異なる方法によって複数のリソース移動計画候補の中から適切なリソース移動計画を選択することができる。選択基準の優先度の順序は、上記順序と異なっていてもよく、リソース移動開始時刻が同一の計画候補から任意に一つの計画を選択してもよい。
　以下において、データ退避中性能チェック処理（Ｓ２０３４）及びデータ退避後性能チェック処理（Ｓ２３０５）を説明する。図２８Ａ及び図２８Ｂは、性能予測グラフの一例を模式的に示している。図２８Ａは、ＩＯＰＳの時間変化を示す。図２８Ｂは、図２８のＩＯＰＳのグラフに対応する、レスポンスタイムのグラフである。
　図２８Ｂのグラフは、図２３を参照して説明したリソース移動計画作成処理（Ｓ２００４）における、データ退避中性能チェック処理（Ｓ２３０４）及びデータ退避後性能チェック処理（Ｓ２３０５）が算出する提供元プールのレスポンスタイムを示す概念図である。この概念図は、データ退避後の即時階層間再配置を行う場合と行わない場合の双方を示す。
　図２８Ａにおいて、実線２８０１は提供元プールのＩＯＰＳ平均値、破線２８０２は時刻Ｔ８１でリソース移動（データ退避）開始したときのＩＯＰＳ予測値、そして一点鎖線２８０３は時刻Ｔ８２でリソース移動開始したときのＩＯＰＳ予測値を示している。
　図２８Ｂにおいて、実線２８０４は提供元プールのレスポンスタイム平均値、破線２８０５は時刻Ｔ８１でリソース移動開始した時のレスポンスタイム予測値、一点鎖線２８０６は時刻Ｔ８２でリソース移動開始したときのレスポンスタイム予測値、そして二点鎖線２８０７は、ＳＬＯで規定されたレスポンスタイム上限値を示している。
　図２８Ｂのグラフは、時刻Ｔ８１でリソースの移動を開始した場合は、リソース解除による負荷で提供元プールがＳＬＯ違反を起こすが、時刻Ｔ８２で移動を開始した場合は提供元プールがＳＬＯ違反を起こさないことを表す。性能管理機能５０２は、ＳＬＯ違反を起こさないリソース移動計画を、リソース移動計画候補テーブル５１５に追加する。
　図２５のフローチャートを参照して、データ退避中性能チェック処理（Ｓ２３０４）の例を説明する。データ退避中性能チェック処理において、性能管理機能５０２は、提供元プールに関して、Ｔｉｅｒ間のデータ転送速度及びＴｉｅｒ毎のＩＯＰＳとレスポンスタイムの相関関係モデルを基に、ページ移動による追加ＩＯＰＳを予測する。
　さらに、性能管理機能５０２は、この追加ＩＯＰＳ予測値とリソース解除に伴うデータ退避中のプール内ページ配置の変動予測とを併せて、ページ退避中の各ＴｉｅｒのＩＯＰＳ増加量を予測する。これを基にデータ退避中の各Ｔｉｅｒの性能を予測する。
　性能管理機能５０２は、データ退避中の提供元プールの性能を、プール内のページ配置とＴｉｅｒ間のデータ転送速度情報を基に予測する。性能管理機能５０２は、この予測値を基に、データ退避中に提供元プールがＳＬＯ違反を起こすかどうかを予測する。
　図２５に示すように、性能管理機能５０２は、Ｓ２５０１からＳ２５０４を、リソース移動開始時刻（データ退避開始時刻）からデータ退避完了見込時刻まで、所定時間間隔ずつ進めながら繰り返す。つまり、性能管理機能５０２は、データ退避開始からデータ退避完了までの各選択時刻において、ＳＬＯ違反が発生するか否かを予測する。所定時間は、例えば１０分であり、時間間隔は一定でなくともよい。これは、図２６のフローチャートにおいて同様である。
　Ｓ２５０２において、性能管理機能５０２は、データ退避中のＩＯＰＳを算出する。具体的には、性能管理機能５０２は、まず、時間帯平均ＩＯＰＳ情報テーブル５１９を参照し、該当時間帯におけるプールの時間帯平均ＩＯＰＳを取得する。次に、性能管理機能５０２は、データ退避中の該当時刻（該当時間帯）における、提供元プールのページ配置を予測する。
　ページ配置予測において、図１７を参照して説明したように、データ退避において、ページは一つずつ、前回監視期間のＩ／Ｏ量が多いものから順にプール内の空き領域に移動されると仮定する。上述のように、ページ移動方法の規則が決まっていれば、これと異なる方法でページを移動してもよい。
　さらに、性能管理機能５０２は、Ｔｉｅｒ間のデータ転送速度を求める。この方法は、図２３を参照して説明したリソース移動計画作成処理（Ｓ２００４）において転送経路毎の転送速度を求めた方法と同様である。性能管理機能５０２は、上記ページ移動方法の規則とＴｉｅｒ間のデータ転送速度とから、該当時刻におけるページ配置を予測することができる。
　次に、性能管理機能５０２は、データ退避で転送するデータ量と、リソース解除見込所要時間（図２３のリソース移動計画作成処理のＳ２３０３で算出済）から、プールの平均転送速度（プール内データ移動における平均転送速度）を以下の数式に従って算出する。
　プールの平均転送速度＝転送するデータ量／リソース解除見込み所要時間
　性能管理機能５０２は、転送速度（ＭＢ／ｓ）と１Ｉ／Ｏで処理可能なデータ量（ＭＢｐｅｒＩ／Ｏ）とから、データ退避に伴う追加ＩＯＰＳ（追加ＩＯＰＳに相当する値）を、以下の数式に従って算出（推測）する。なお、１Ｉ／Ｏで処理可能なデータ量は固定値（例えば４ＫＢ）でもよいが、実測値を用いて動的に変更してもよい。
　データ退避に伴う追加ＩＯＰＳ＝プールの平均転送速度／１Ｉ／Ｏで処理可能なデータ量
　性能管理機能５０２は、プール内の各ＴｉｅｒのＩ／Ｏ比率を算出する。算出方法は、図１４を参照して説明したＩＯＰＳ対レスポンスタイム相関情報テーブル更新処理（Ｓ６０３）における算出方法と同様である。つまり、性能管理機能５０２は、時間帯平均ＩＯＰＳ情報テーブル５１９から取得したプール平均ＩＯＰＳから、プール内各ＴｉｅｒのＩ／Ｏ比率を基に、プール内各ＴｉｅｒのＩＯＰＳを算出する。プール平均ＩＯＰＳにＴｉｅｒのＩ／Ｏ比率を掛けた値が、当該ＴｉｅｒのＩＯＰＳである。
　性能管理機能５０２は、上述のように算出した追加ＩＯＰＳを、データ退避元Ｔｉｅｒとデータ退避先ＴｉｅｒのＩＯＰＳに加算する。これにより、プール内の各ＴｉｅｒのＩＯＰＳ予測値を得る。
　次に、Ｓ２５０３において、性能管理機能５０２は、性能余剰率予測値を算出する。具体的には、性能管理機能５０２は、ＩＯＰＳ対レスポンスタイム相関情報テーブル５２１を参照し、Ｓ２５０２で算出したデータ退避中の各ＴｉｅｒのＩＯＰＳとＴｉｅｒの種別をキーに、ＩＯＰＳ帯平均レスポンスタイムのカラム１６０３から、各Ｔｉｅｒのレスポンスタイム予測値を取得する。
　さらに、性能管理機能５０２は、ページ情報テーブル５１４の前回監視期間Ｉ／Ｏ量カラム１１０６から、プールの各Ｔｉｅｒ内の全てのページのＩ／Ｏ量の合計を算出する。この値は、各ＴｉｅｒのＩ／Ｏ量合計である。
　性能管理機能５０２は、これらの値を使用し、以下の式によりプールのレスポンスタイム予測値を算出する。これは、ＴｉｅｒのレスポンスタイムのＩ／Ｏ量加重平均である。
　プールのレスポンスタイム予測値＝（Σ（ＴｉｅｒのＩ／Ｏ量合計×Ｔｉｅｒのレスポンスタイム予測値））／プールのＩ／Ｏ量合計
　性能管理機能５０２は、算出したプールのレスポンスタイム予測値を基に、プールの性能余剰率予測値を算出する。図２０に示す性能問題改善計画処理で求めたプールの性能余剰率は、プールのレスポンスタイム一日平均を基に算出された。プールの性能余剰率予測値は、プールのレスポンスタイム予測値を基に以下のように算出される。要求レスポンスタイム上限の値は、例えば、プールのレスポンスタイム一日平均と同様の基準で決定される。
　性能余剰率予測値（％）＝１００－（プールのレスポンスタイム予測値／要求レスポンスタイム上限）×１００
　次に、Ｓ２５０４において、性能管理機能５０２は、算出した性能余剰率予測値と管理者によって予め設定されている下限閾値とを比較する。性能余剰率予測値が下限閾値以下である場合（Ｓ２５０４：ＮＯ）、性能管理機能５０２は、ＳＬＯ違反があると判定し（Ｓ２５０７）、処理を終了する。性能余剰率予測値が下限閾値より大きい場合（Ｓ２５０４：ＹＥＳ）、性能管理機能５０２はＳ２５０５に進む。データ退避完了見込み時刻まで性能余剰率予測値が下限閾値より常に大きい場合、性能管理機能５０２はＳＬＯ違反がないと判定し（Ｓ２５０６）、処理を終了する。
　次に、図２６のフローチャートを参照して、データ退避後性能チェック処理（Ｓ２３０５）の例を説明する。この例において、性能管理機能５０２は、データ退避完了後、即時に階層間再配置を実施する場合と、即時階層間再配置を実施せず、定期的に予定されている階層間再配置まで待つ場合の二つのパターンに関して、提供元プールの性能及びＳＬＯ違反の有無を予測する。
　性能管理機能５０２は、図２３を参照して説明したように、各選択時刻でのページ配置を予測し、そのページ配置におけるＩＯＰＳ及びレスポンスタイムを予測することができる。さらに、階層間再配置における追加ＩＯＰＳの予測は、図２３を参照して説明したデータ退避における追加ＩＯＰＳの予測と同様の方法を使用することができる。
　図２６のフローチャートにおいて、性能管理機能５０２は、Ｓ２６０１からＳ２６０９を、データ退避後の即時階層間再配置有りと無しの両方のパターンに関して繰り返す。つまり、性能管理機能５０２は、即時階層間再配置を行う場合と即時階層間再配置を行わない場合の双方の提供元プールの性能予測を行う。
　性能管理機能５０２は、Ｓ２６０２からＳ２６０６を、データ退避完了見込時刻から定期階層間再配置開始時刻まで一定時間間隔ずつ進めながら繰り返す。つまり、性能管理機能５０２は、データ退避完了から定期階層間再配置開始までの期間から選択した各時刻において、性能及びＳＬＯ違反の有無を予測する。
　性能予測を行う提供元プールに対する定期階層間再配置が設定されていない場合（プール情報テーブル５１１において実行モードが"手動"の場合）、性能管理機能５０２は、データ退避完了から２４時間後までの期間における性能予測及びＳＬＯ違反の有無のチェックを行う。
　Ｓ２６０３において、性能管理機能５０２は、該当時刻のＩＯＰＳを算出する。ＩＯＰＳの算出方法は、即時階層間再配置を行う場合と、即時階層間再配置を行う場合とで異なる。即時階層間再配置を行わない場合、性能管理機能５０２は、データ退避完了時のページ配置から、各ＴｉｅｒのＩＯＰＳを算出する。この算出方法は、図２３に示すデータ退避中の性能チェックにおける方法と同様である。
　即時階層間再配置を行う場合、性能管理機能５０２は、階層間再配置行っている間において、ページ移動に伴うページ移動元及びページ移動先のＴｉｅｒでの追加ＩＯＰＳを算出する。さらに、性能管理機能５０２は、該当時刻でのページ配置と上記算出した追加のＩＯＰＳから、該当時刻での各ＴｉｅｒのＩＯＰＳを算出する。この算出方法は、図２３に示すデータ退避中の性能チェックにおける方法と同様である。
　即時階層間再配置完了から定期階層間再配置開始までの期間におけるＩＯＰＳの算出は不要である。算出する場合、性能管理機能５０２は、即時階層間再配置完了時のページ配置から、該当時刻での各ＴｉｅｒのＩＯＰＳを算出する。この算出方法は、即時階層間再配置を行わない場合と同様である。即時階層間再配置後のページ配置は、ページ退避完了後に即時階層間再配置を行わない場合のページ配置とは異なる。
　次に、Ｓ２６０４において、性能管理機能５０２は、性能余剰率予測値を算出する。この算出方法は、図２５のデータ退避中性能チェックのフローチャートにおけるＳ２５０３と同様である。
　Ｓ２６０５において、性能管理機能５０２は、算出した性能余剰率予測値と管理者によって予め設定されている下限閾値とを比較する。性能余剰率予測値が下限閾値以下である場合（Ｓ２６０５：ＮＯ）、性能管理機能５０２は、ＳＬＯ違反があると判定し（Ｓ２６０８）、Ｓ２６０９に進む。性能余剰率予測値が下限閾値より大きい場合（Ｓ２６０５：ＹＥＳ）、性能管理機能５０２はＳＬＯ違反がないと判定し（Ｓ２６０７）、Ｓ２６０９に進む。
　図２６を参照して説明した上記例は、定期階層間再配置の間のプール性能及びＳＬＯ違反の予測を行わないが、性能管理機能５０２は、その期間におけるプール性能及びＳＬＯ違反の予測も行ってもよい。
　以上のように、本実施形態によれば、ＴＣＯを低く抑えつつ、ストレージシステム全体で、ボリューム提供先ホストの要求する性能を確保することができる。また、そのための管理者の負担を大きく低減することができる。ＳＬＯ違反の可能性が低くかつ早期にリソース解除完了可能な提供元プールを特定とすることによって、ＳＬＯ違反発生の確率を低減することができる。
　以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。プログラムの少なくとも一部は、専用ハードウェアによって実現されてもよい。プログラムは、プログラム配布サーバや、計算機読み取り可能な非一時的記憶媒体によって計算機にインストールすることができ、計算機の不揮発性記憶装置に格納することができる。
　本実施形態において入出力デバイスを介して管理者により行われた設定処理の少なくとも一部は、プログラムにより実行されてもよい。上記構成において、プール間の移動リソースは移動元の１以上のプールボリュームであるが、プール間移動リソースは、移動元プールボリュームの一部の実記憶領域であってもよい。
　管理システムは、プールが満たすべき性能要求の指標として、レスポンスタイムと異なる値を使用することができる。例えば、トランスファレート（ＭＢ／ｓ）、スループット（Ｍａｘ－ＩＯＰＳ）、その他の指標を使用することができる。
　上述のように、より早いリソース移動を実現するため、管理システムは、データ退避後に即時階層間再配置を行う場合と行わない場合の双方の性能予測を行うことが好ましいが、それらの内の一方のみの性能予測を行ってもよい。
　上記構成例は、リソース提供元プールにおけるデータ退避後、即時に、階層間再配置を行う。これと異なり、管理システムは、データ退避完了から所定時間経過後、定期階層間再配置前に、階層間再配置を行ってもよい。管理システムは、データ退避と階層間再配置とを分離して、シミュレーションを行うことができる。
　管理システムは、データ退避中の性能予測（シミュレーション）を行った後、階層間再配置の開始時刻をデータ退避完了時刻から所定時間ずつ進めながら、階層間再配置中及びその後の性能予測（シミュレーション）を行う。これにより、ＳＬＯ違反を起こさない、より早いデータ退避完了時刻のリソース移動計画を得る可能性が高まる。
　上述のように、管理システムは、定期的に取得していているストレージシステムの履歴情報に基づいて、性能予測のためのシミュレーションを行うことが好ましい。これによって、より正確な性能予測を行うことができる。設計によっては、予め設定されている一定のデータを使用して、性能予測を行ってもよい。
　管理システムは、プール内データ移動を行わない期間において、シミュレーションによる性能予測を行わなくともよい。例えば、管理システムは、データ退避中の性能及び、行う場合には即時階層間再配置の期間の性能を予測し、その結果によってＳＬＯ違反の有無を予測する。
　上記構成例は、性能余剰率により危険プールの判定及び転送元プールの選択を行うが、これと異なる指標によりこれらを行ってもよい。上述のように、危険プールへのリソース追加見込み時刻が最も早い移動計画を選択することが好ましいが、設計によっては、これと異なる基準で移動計画を選択してもよい。例えば、転送元プールのリソース移動後性能余剰率を最優先の基準として使用してもよい。
　上述のように、階層間再配置を行った後にＳＬＯを満たすと予想されるプールについて、詳細なシミュレーションによる性能予測を行うことが効率的であるが、全てのプールについて、データ退避開始からの詳細なシミュレーションを行ってもよい。

Claims (15)

  1. 　ストレージシステムと、前記ストレージシステムとネットワークを介して接続し前記ストレージシステムを管理する管理システムと、を含み、
    　前記ストレージシステムは、それぞれが複数の記憶リソースを含みアクセス性能が異なる複数の階層に分けられた、複数のプールを含み、
    　前記管理システムは、前記複数のプールのアクセス性能を監視し、予め定められたアクセス性能要求を満たさなくなることが予測される危険プールを検知し、
    　前記管理システムは、前記複数のプールの１以上の候補プールのそれぞれについて、記憶リソースを前記危険プールに移動する場合のアクセス性能を、前記記憶リソースの前記移動のために前記記憶リソースに格納されているデータを同一プール内で退避することによるプール内データ配置の変動、に基づくシミュレーションにより予測し、
    　前記管理システムは、前記予測したアクセス性能が予め定められた性能要求を満たす提供元プールから前記記憶リソースを前記危険プールに移動することを決定する、計算機システム。
  2. 　前記管理システムは、前記データ退避中の期間において、前記記憶リソースのデータ移動により変化するデータ配置の予測配置と、前記記憶リソースのデータ移動による追加の予測負荷と、を使用して、前記候補プールの前記アクセス性能を予測する、請求項１に記載の計算機システム。
  3. 　前記管理システムは、前記アクセス性能の時間変化のシミュレーションによる予測において、
    　前記候補プール内でのデータ移動が発生しない期間において、前記候補プール内の予測データ配置を使用して、前記候補プールの前記アクセス性能を予測し、
    　前記候補プール内でのデータ移動が発生する期間において、前記候補プール内の予測データ配置に加えて、前記候補プール内のデータ移動による追加の予測負荷を使用して、前記候補プールの前記アクセス性能を予測する、請求項２に記載の計算機システム。
  4. 　前記管理システムは、前記データ退避の開始時刻を進めながら前記候補プールの前記アクセス性能の予測を繰り返し、前記予測アクセス性能が前記候補プールの前記予め定められた性能要求を満たすデータ退避開始時刻を探す、請求項３に記載の計算機システム。
  5. 　前記管理システムは、前記予測したアクセス性能が予め定められた性能要求を満たす複数の候補プールにおいて、データ退避完了予測時刻が最も早い候補プールを、前記提供元プールとして選択する、請求項４に記載の計算機システム。
  6. 　前記管理システムは、前記ストレージシステムから収集した前記候補プールへのアクセスの履歴情報と前記候補プールの各階層のアクセス性能に関する情報とを記憶しており、
    　前記管理システムは、前記データ退避中及び前記データ退避完了後の期間において、前記アクセスの履歴情報と前記アクセス性能関する情報を使用して、前記候補プールのアクセス性能を予測する、請求項５に記載の計算機システム。
  7. 　前記管理システムは、前記シミュレーションが前記記憶リソースのデータ退避完了後の階層間再配置を含む場合、前記データ退避完了後の階層間再配置中の前記候補プールのアクセス性能を、前記候補プール内のデータ階層間移動により変化するデータ配置の予測配置と、データ階層間移動による予測追加負荷と、を使用して予測する、請求項６に記載の計算機システム。
  8. 　前記管理システムは、前記記憶リソースのデータ退避後の即時階層間再配置を行う場合と行わない場合の双方の、前記候補プールのアクセス性能を予測する、請求項７に記載の計算機システム。
  9. 　前記管理システムは、前記提供元プールから前記危険プールに前記記憶リソースを移動する間において、前記提供元プールへのアクセスを監視し、
    　前記管理システムは、前記監視している前記提供元プールへのアクセスと前記提供元プールの予測性能とに基づき前記リソースの移動を中止するか否かを判定する、請求項８に記載の計算機システム。
  10. 　それぞれが複数の記憶リソースを含みアクセス性能が異なる複数の階層に分けられた複数のプールを含むストレージシステムと、前記ストレージシステムとネットワークを介して接続し前記ストレージシステムを管理する管理システムと、を含む計算機システムにおいて、前記ストレージシステムを管理する方法であって、
    　前記管理システムが、前記複数のプールのアクセス性能を監視し、予め定められたアクセス性能要求を満たさなくなることが予測される危険プールを検知し、
    　前記管理システムが、前記複数のプールの１以上の候補プールのそれぞれについて、記憶リソースを前記危険プールに移動する場合のアクセス性能を、前記記憶リソースの前記移動のために前記記憶リソースに格納されているデータを同一プール内で退避することによるプール内データ配置の変動、に基づくシミュレーションにより予測し、
    　前記管理システムが、前記予測したアクセス性能が予め定められた性能要求を満たす提供元プールから前記記憶リソースを前記危険プールに移動することを決定する、ストレージシステム管理方法。
  11. 　前記管理システムが、前記データ退避中の期間において、前記記憶リソースのデータ移動により変化するデータ配置の予測配置と、前記記憶リソースのデータ移動による追加の予測負荷と、を使用して、前記候補プールの前記アクセス性能を予測する、請求項１０に記載のストレージシステム管理方法。
  12. 　前記管理システムが、前記データ退避の開始時刻を進めながら前記候補プールの前記アクセス性能の予測を繰り返し、前記予測アクセス性能が前記候補プールの前記予め定められた性能要求を満たすデータ退避開始時刻を探し、
    　前記管理システムが、前記予測したアクセス性能が予め定められた性能要求を満たす複数の候補プールにおいて、データ退避完了予測時刻が最も早い候補プールを、前記提供元プールとして選択する、請求項１０に記載のストレージシステム管理方法。
  13. 　前記管理システムが、前記ストレージシステムから収集した前記候補プールへのアクセスの履歴情報と前記候補プールの各階層のアクセス性能に関する情報とを記憶し、
    　前記管理システムが、前記データ退避中及び前記データ退避完了後の期間において、前記アクセスの履歴情報と前記アクセス性能関する情報を使用して、前記候補プールのアクセス性能を予測する、請求項１０に記載のストレージシステム管理方法。
  14. 　前記管理システムが、前記シミュレーションが前記記憶リソースのデータ退避完了後の階層間再配置を含む場合、前記データ退避完了後の階層間再配置中の前記候補プールのアクセス性能を、前記候補プール内のデータ階層間移動により変化するデータ配置の予測配置と、データ階層間移動による予測追加負荷と、を使用して予測する、請求項１０に記載のストレージシステム管理方法。
  15. 　前記管理システムが、前記記憶リソースのデータ退避後の即時階層間再配置を行う場合と行わない場合の双方の、前記候補プールのアクセス性能を予測する、請求項１４に記載のストレージシステム管理方法。
PCT/JP2011/063165 2011-06-08 2011-06-08 計算機システム及びストレージシステム管理方法 WO2012169027A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2011/063165 WO2012169027A1 (ja) 2011-06-08 2011-06-08 計算機システム及びストレージシステム管理方法
US13/384,910 US8683162B2 (en) 2011-06-08 2011-06-08 Computer system and method of managing storage system monitoring access performance for risky pool detection

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/063165 WO2012169027A1 (ja) 2011-06-08 2011-06-08 計算機システム及びストレージシステム管理方法

Publications (1)

Publication Number Publication Date
WO2012169027A1 true WO2012169027A1 (ja) 2012-12-13

Family

ID=47294150

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/063165 WO2012169027A1 (ja) 2011-06-08 2011-06-08 計算機システム及びストレージシステム管理方法

Country Status (2)

Country Link
US (1) US8683162B2 (ja)
WO (1) WO2012169027A1 (ja)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014112104A1 (ja) * 2013-01-18 2014-07-24 株式会社日立製作所 計算機システム、データ管理方法、及びホスト計算機
WO2014118874A1 (ja) * 2013-01-29 2014-08-07 株式会社 日立製作所 ストレージシステム
WO2014128910A1 (ja) * 2013-02-22 2014-08-28 株式会社日立製作所 ストレージシステム、管理計算機、及び仮想論理ボリューム管理方法
WO2014147816A1 (ja) * 2013-03-22 2014-09-25 株式会社 日立製作所 ストレージ装置及び記憶領域検証方法
WO2014167716A1 (ja) * 2013-04-12 2014-10-16 株式会社日立製作所 計算機システムの管理システム及び管理方法
WO2015194033A1 (ja) * 2014-06-20 2015-12-23 株式会社日立製作所 計算機システム
US20160142335A1 (en) 2014-11-19 2016-05-19 Fujitsu Limited Storage management device, storage management method, and computer-readable recording medium
JP2016099761A (ja) * 2014-11-20 2016-05-30 富士通株式会社 ストレージ管理装置、性能調整方法及び性能調整プログラム
JP2017010196A (ja) * 2015-06-19 2017-01-12 富士通株式会社 ストレージ制御装置、ストレージ制御プログラム、及びストレージ制御方法
WO2017085792A1 (ja) * 2015-11-17 2017-05-26 株式会社日立製作所 ストレージシステム、及びストレージシステムの制御方法
US9990313B2 (en) 2014-06-19 2018-06-05 Hitachi, Ltd. Storage apparatus and interface apparatus
JP2018101440A (ja) * 2018-02-08 2018-06-28 株式会社日立製作所 計算機システム
US10037162B2 (en) 2015-06-15 2018-07-31 Fujitsu Limited Storage management device, storage management method, and computer-readable recording medium
JP2020042651A (ja) * 2018-09-12 2020-03-19 株式会社日立製作所 リソース割当ての最適化を支援するシステム及び方法
JP2022538028A (ja) * 2019-06-26 2022-08-31 インターナショナル・ビジネス・マシーンズ・コーポレーション ストレージ・ドライブの動的パフォーマンス・クラス調節

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9542125B1 (en) * 2012-09-25 2017-01-10 EMC IP Holding Company LLC Managing data relocation in storage systems
US9658983B1 (en) * 2012-12-14 2017-05-23 Amazon Technologies, Inc. Lifecycle support for storage objects having multiple durability levels specifying different numbers of versions
US9514162B2 (en) * 2013-06-07 2016-12-06 Internation Business Machines Corporation Smart polling frequency
CN104750538B (zh) * 2013-12-27 2020-03-03 伊姆西Ip控股有限责任公司 用于为目标应用提供虚拟存储池的方法和系统
US9542346B2 (en) * 2014-01-14 2017-01-10 Netapp, Inc. Method and system for monitoring and analyzing quality of service in a storage system
US9547445B2 (en) 2014-01-14 2017-01-17 Netapp, Inc. Method and system for monitoring and analyzing quality of service in a storage system
US9542103B2 (en) 2014-01-14 2017-01-10 Netapp, Inc. Method and system for monitoring and analyzing quality of service in a storage system
US9584599B2 (en) * 2014-01-14 2017-02-28 Netapp, Inc. Method and system for presenting storage in a cloud computing environment
US9658778B2 (en) 2014-01-14 2017-05-23 Netapp, Inc. Method and system for monitoring and analyzing quality of service in a metro-cluster
US9411834B2 (en) 2014-01-14 2016-08-09 Netapp, Inc. Method and system for monitoring and analyzing quality of service in a storage system
WO2015140931A1 (ja) * 2014-03-18 2015-09-24 株式会社 東芝 トライアル領域を備えた階層化ストレージシステム、ストレージコントローラ及びプログラム
GB2533405A (en) 2014-12-19 2016-06-22 Ibm Data storage resource assignment
JP6279816B2 (ja) * 2015-07-28 2018-02-14 株式会社日立製作所 ストレージ監視システムおよびその監視方法
US20170031600A1 (en) * 2015-07-30 2017-02-02 Netapp Inc. Real-time analysis for dynamic storage
US11853656B1 (en) * 2015-09-30 2023-12-26 EMC IP Holding Company LLC Data storage system modeling using application service level objectives and specified workload limits for storage tiers
JP6747018B2 (ja) * 2016-03-31 2020-08-26 日本電気株式会社 記憶システム、記憶システム制御装置、記憶システム制御方法及びプログラム
JP6946716B2 (ja) * 2017-04-28 2021-10-06 富士通株式会社 ストレージ制御装置，ストレージ制御プログラムおよびストレージ制御方法
WO2019017947A1 (en) 2017-07-20 2019-01-24 Hewlett-Packard Development Company, L.P. PERFORMANCE PREDICTION OF A COMPUTER SYSTEM
US11113090B1 (en) 2017-08-09 2021-09-07 United Services Automobile Association (Usaa) Systems and methods for container management
US10614012B2 (en) * 2018-01-09 2020-04-07 Microsemi Storage Solutions, Inc. System and method for controlling the performance of serial attached SCSI (SAS) target devices
US10503672B2 (en) * 2018-04-26 2019-12-10 EMC IP Holding Company LLC Time dependent service level objectives
US10884778B1 (en) * 2018-09-28 2021-01-05 Amazon Technologies, Inc. Adjusting dynamically scalable instance hosting based on compute resource usage
US10877786B1 (en) 2018-09-28 2020-12-29 Amazon Technologies, Inc. Managing compute resource usage based on prior usage
US11010091B2 (en) * 2019-08-29 2021-05-18 International Business Machines Corporation Multi-tier storage
US11169716B2 (en) * 2020-03-31 2021-11-09 EMC IP Holding Company LLC Prediction of maintenance window of a storage system
JP2023015664A (ja) * 2021-07-20 2023-02-01 株式会社日立製作所 管理システム、ＱｏＳ違反検知方法、及びＱｏＳ違反検知プログラム
US20230168934A1 (en) * 2021-12-01 2023-06-01 Fungible, Inc. Predictable and adaptive quality of service for storage
US11621882B1 (en) * 2022-01-28 2023-04-04 United Services Automobile Association (Usaa) Automated remedial actions for service level objective thresholds

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009238114A (ja) * 2008-03-28 2009-10-15 Hitachi Ltd ストレージ管理方法、ストレージ管理プログラム、ストレージ管理装置およびストレージ管理システム
JP2009252106A (ja) * 2008-04-09 2009-10-29 Nec Corp ディスクアレイ制御方法及びディスクアレイ装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1668486A2 (en) 2003-08-14 2006-06-14 Compellent Technologies Virtual disk drive system and method
US8543778B2 (en) * 2010-01-28 2013-09-24 Hitachi, Ltd. Management system and methods of storage system comprising pool configured of actual area groups of different performances
US8543786B2 (en) * 2010-09-29 2013-09-24 Hitachi, Ltd. Computer system and computer system management method for adding an unused real volume to a pool
US9348515B2 (en) * 2011-01-17 2016-05-24 Hitachi, Ltd. Computer system, management computer and storage management method for managing data configuration based on statistical information

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009238114A (ja) * 2008-03-28 2009-10-15 Hitachi Ltd ストレージ管理方法、ストレージ管理プログラム、ストレージ管理装置およびストレージ管理システム
JP2009252106A (ja) * 2008-04-09 2009-10-29 Nec Corp ディスクアレイ制御方法及びディスクアレイ装置

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9619154B2 (en) 2013-01-18 2017-04-11 Hitachi, Ltd. Computer system, data management method, and host computer
WO2014112104A1 (ja) * 2013-01-18 2014-07-24 株式会社日立製作所 計算機システム、データ管理方法、及びホスト計算機
WO2014118874A1 (ja) * 2013-01-29 2014-08-07 株式会社 日立製作所 ストレージシステム
US8886888B2 (en) 2013-01-29 2014-11-11 Hitachi, Ltd. Storage system
WO2014128910A1 (ja) * 2013-02-22 2014-08-28 株式会社日立製作所 ストレージシステム、管理計算機、及び仮想論理ボリューム管理方法
US9626110B2 (en) 2013-02-22 2017-04-18 Hitachi, Ltd. Method for selecting a page for migration based on access path information and response performance information
US9459973B2 (en) 2013-03-22 2016-10-04 Hitachi, Ltd. Storage subsystem, and method for verifying storage area
WO2014147816A1 (ja) * 2013-03-22 2014-09-25 株式会社 日立製作所 ストレージ装置及び記憶領域検証方法
WO2014167716A1 (ja) * 2013-04-12 2014-10-16 株式会社日立製作所 計算機システムの管理システム及び管理方法
US9442765B2 (en) 2013-04-12 2016-09-13 Hitachi, Ltd. Identifying shared physical storage resources having possibility to be simultaneously used by two jobs when reaching a high load
US9990313B2 (en) 2014-06-19 2018-06-05 Hitachi, Ltd. Storage apparatus and interface apparatus
WO2015194033A1 (ja) * 2014-06-20 2015-12-23 株式会社日立製作所 計算機システム
JPWO2015194033A1 (ja) * 2014-06-20 2017-04-20 株式会社日立製作所 計算機システム
JP2016099746A (ja) * 2014-11-19 2016-05-30 富士通株式会社 ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
US20160142335A1 (en) 2014-11-19 2016-05-19 Fujitsu Limited Storage management device, storage management method, and computer-readable recording medium
US10277676B2 (en) 2014-11-19 2019-04-30 Fujitsu Limited Storage management device, storage management method, and computer-readable recording medium
JP2016099761A (ja) * 2014-11-20 2016-05-30 富士通株式会社 ストレージ管理装置、性能調整方法及び性能調整プログラム
US10037162B2 (en) 2015-06-15 2018-07-31 Fujitsu Limited Storage management device, storage management method, and computer-readable recording medium
JP2017010196A (ja) * 2015-06-19 2017-01-12 富士通株式会社 ストレージ制御装置、ストレージ制御プログラム、及びストレージ制御方法
WO2017085792A1 (ja) * 2015-11-17 2017-05-26 株式会社日立製作所 ストレージシステム、及びストレージシステムの制御方法
JP2018101440A (ja) * 2018-02-08 2018-06-28 株式会社日立製作所 計算機システム
JP2020042651A (ja) * 2018-09-12 2020-03-19 株式会社日立製作所 リソース割当ての最適化を支援するシステム及び方法
US10977082B2 (en) 2018-09-12 2021-04-13 Hitachi, Ltd. Resource allocation optimization support system and resource allocation optimization support method
JP2022538028A (ja) * 2019-06-26 2022-08-31 インターナショナル・ビジネス・マシーンズ・コーポレーション ストレージ・ドライブの動的パフォーマンス・クラス調節
JP7558208B2 (ja) 2019-06-26 2024-09-30 インターナショナル・ビジネス・マシーンズ・コーポレーション ストレージ・ドライブの動的パフォーマンス・クラス調節

Also Published As

Publication number Publication date
US8683162B2 (en) 2014-03-25
US20120317358A1 (en) 2012-12-13

Similar Documents

Publication Publication Date Title
WO2012169027A1 (ja) 計算機システム及びストレージシステム管理方法
US9477407B1 (en) Intelligent migration of a virtual storage unit to another data storage system
US10754573B2 (en) Optimized auto-tiering, wherein subset of data movements are selected, utilizing workload skew point, from a list that ranks data movements based on criteria other than I/O workload
US8566546B1 (en) Techniques for enforcing capacity restrictions of an allocation policy
US10095425B1 (en) Techniques for storing data
US9021203B2 (en) Enhancing tiering storage performance
US8850152B2 (en) Method of data migration and information storage system
US9665630B1 (en) Techniques for providing storage hints for use in connection with data movement optimizations
US8122116B2 (en) Storage management method and management server
JP4914173B2 (ja) 再配置システムおよび再配置方法
US10013170B1 (en) Intelligent data compression
US9043571B2 (en) Management apparatus and management method
GB2496807B (en) Computer system, management method of the computer system, and program
WO2012140730A1 (ja) 管理システム、それを有する計算機システム、及び管理方法
JP5668151B2 (ja) 計算機システムの管理装置及び管理方法
CN107092442B (zh) 存储系统资源分配方法及装置
US8402214B2 (en) Dynamic page reallocation storage system management
JP6035991B2 (ja) ストレージ制御方法、およびストレージ制御装置
US9323682B1 (en) Non-intrusive automated storage tiering using information of front end storage activities
WO2014002213A1 (ja) 管理システム及び管理方法
US8954381B1 (en) Determining data movements in a multi-tiered storage environment
WO2010099992A1 (en) Method, system and computer program product for managing the placement of storage data in a multi tier virtualized storage infrastructure
WO2013098960A1 (ja) 計算機システム、ファイル管理方法及び記憶媒体
US20140372720A1 (en) Storage system and operation management method of storage system
US20180314427A1 (en) System and method for storage system autotiering using adaptive granularity

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 13384910

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11867241

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11867241

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP