JP2009238114A - ストレージ管理方法、ストレージ管理プログラム、ストレージ管理装置およびストレージ管理システム - Google Patents

Abstract

【課題】仮想ボリューム装置で、スループットが低下しないように動的割当てプールの割当てを行う。
【解決手段】運用管理サーバ２は、仮想ボリューム機構を有するストレージ装置において実ボリュームの仮想ボリュームへの割当てを管理している動的割当てプールを決定する。さらに、業務サーバ３で実行されているアプリケーションのＩ／Ｏ特性を取得し、アプリケーションと、アプリケーションのＩ／Ｏ特性とを対応付けたアプリケーション管理表を作成・維持する。アプリケーション管理表のＩ／Ｏ特性に基づいて、業務サーバ３で実行されるアプリケーションをグループ化したアプリケーショングループを作成し、スループットが低下しないように、作成したアプリケーショングループと動的割当てプールとを対応付ける。
【選択図】図１

Description

本発明は、ストレージ管理方法、ストレージ管理プログラム、ストレージ管理装置およびストレージ管理システムの技術に関する。

電子商取引の普及やマルチメディアデータの利用の増大に伴い、企業において扱われるデータが急激に増加しつつある。このため、大量のデータを効果的に取り扱うことのできるストレージ・エリア・ネットワーク（Storage Area Network：ＳＡＮ）に代表されるストレージの集中管理技術が普及しつつある。また、データ容量は右肩上がりで増加する傾向があるため、ストレージ領域の有効活用、およびストレージ運用コストの低減のために、ストレージ装置から業務サーバに予め大きなサイズの仮想的なボリューム（仮想ボリューム）を公開し、業務サーバからデータの書き込み要求があった時に初めて実ボリュームにおけるストレージ領域を動的に割当てる仮想ボリューム機構によるストレージ仮想化のニーズが高まってきている。仮想ボリューム機構においては、仮想ボリュームに対して動的割当ての際に実際に割当てる実ボリューム群を、通常、ストレージ装置の動的割当てストレージプール（以下、動的割当てプール）に格納しておくのが一般的である。

一般的な技術におけるストレージをプール化する技術は、仮想ボリューム機構特有のものではなく、従来のボリューム割当て技術においても、未割当てのボリュームをまとめて管理する技術として存在している。従来のストレージプール（以下、プールと記載）運用法としては、ストレージの特性視点でプールを構成する方法が一般的であった（例えば、特許文献１参照）。この場合、システム管理者は大きく以下の２つの手順でストレージの運用を行う。

第１の手順として、システム管理者は、プールの定義を行う。ストレージ管理者がストレージ運用管理システムを使って、保有するストレージをボリュームの種別ごとに分類し、この分類ごとにプールを定義して、プールに予め全てのボリュームを格納する。これにより、例えば、ハイエンド向けプールや、アーカイブ向けプールといった、ボリューム種別に対応するプール群が定義されることになり、ストレージ運用管理ソフトウェアの運用管理情報として利用される。この手順は、ストレージ装置導入に伴う事前設定として一括して行われることが多い。

第２の手順として、システム管理者は、業務サーバへのボリューム割当てを行う。アプリケーションの性能期待値（ＩＯＰＳ（Input/Output per Second）、単位時間当たり転送量、Ｒｅｓｐｏｎｓｅ Ｔｉｍｅなど）、信頼性、コストなどの情報（ストレージ要件）に基づいて、どのプールのボリュームを業務サーバへの割当て対象とするかをストレージ管理者が決定する。続いて、ストレージ運用管理システムを使って、プールからアプリケーションが必要とする容量のボリュームを選択してアプリケーションに割当てる。割当て対象とするボリュームは、ストレージ機器内の構成から、選択したボリュームへのアクセスが他のボリュームのパフォーマンスに影響することを考慮した上で決定する。この手順は、ストレージ装置導入後の日々運用として行われることが多い。
また、前記第２の手順でプールを決定する際には、ホスト上のアプリケーションのアクセスパターンがＳｅｑｕｅｎｔｉａｌ指向かＲａｎｄｏｍ指向かという特性に着目して、割当て対象とするボリュームの種別を決定する技術（例えば、特許文献２参照）が利用されることもある。
特開２００４−３３４５６１号公報 特開２００４−１３５４７号公報

前記した技術は、ストレージ領域を動的に割当てる仮想ボリューム機構の動的割当てプールの管理に適用した場合、動的割当てプールの仮想化レイヤによって、異なるＩ／Ｏ(Input/Output)特性（アクセスパターン、具体例としては、Ｒｅａｄ／Ｗｒｉｔｅ比率、Ｒａｎｄｏｍ／Ｓｅｑｕｅｎｔｉａｌ比率、等）を持つアプリケーションからのアクセスが最終的に同一の物理ディスクに対して発生する点で配慮がなされていない。その結果、物理ディスクにおけるアクセス競合によって、ストレージ装置が十分なスループットを発揮できなくなるという問題がある。

このような問題は、物理ディスク固有のスループット低下要因の起因となるものである。例えば、Ｓｅｑｕｅｎｔｉａｌアクセスの最中にＲａｎｄｏｍアクセスが発生すると、ディスクのヘッドシークが発生し、Ｓｅｑｕｅｎｔｉａｌアクセスの単位時間当たり転送量が低下したり、Ｒａｎｄｏｍアクセスの最中にＳｅｑｕｅｎｔｉａｌアクセスが発生するとＳｅｑｕｅｎｔｉａｌアクセスが長時間ディスクヘッドを占有することになり、Ｒａｎｄｏｍアクセスにおいて待ち時間が発生することによりレスポンスタイムが悪くなったりする。

このような背景に鑑みて、本発明は、スループットが低下しないよう動的割当てプールの割当てを行うことを目的とする。

前記課題を解決するため、本発明は、アプリケーション実行装置で実行されているアプリケーションのＩ／Ｏ特性を取得し、前記アプリケーションと、前記アプリケーションのＩ／Ｏ特性とを対応付けたＩ／Ｏ特性情報を前記アプリケーション毎に記憶部に格納し、
前記記憶部のＩ／Ｏ特性に基づいて、前記アプリケーションをグループ化し、前記グループと、前記動的割当てプールとを対応付けることを特徴とする。

本発明によれば、スループットが低下しないよう動的割当てプールの割当てを行うことが可能となる。

次に、本発明を実施するための最良の形態（「実施形態」という）について、適宜図面を参照しながら詳細に説明する。

図１は、本実施形態に係るストレージ運用管理システムの構成例を示すブロック図である。
ストレージ運用管理システム１は、運用管理サーバ２（ストレージ管理装置）、複数の業務サーバ３（アプリケーション実行装置）、複数のストレージ装置４、運用管理端末５を有してなる。
運用管理サーバ２と、運用管理端末５とは、ＬＡＮ（Local Area Network）などのネットワーク６を介して接続している。運用管理サーバ２と、各業務サーバ３とは、社内ＬＡＮなどを介して互いに接続されている。業務サーバ３とストレージ装置４とは、ストレージ・エリア・ネットワーク（ＳＡＮ）７を介して互いに接続されている。

運用管理サーバ２、業務サーバ３およびストレージ装置４の概略は、図２〜図４を参照して後記する。運用管理端末５は、例えばパーソナルコンピュータで構成され、図示しない表示部、入出力部、および記憶部などを有する。運用管理端末５は、システムの状況が表示部に表示されると共に、ストレージの運用管理を行うためにシステム管理者が種々の指示を入力したり、監視したりする機能を備える。

（運用管理サーバ）
図２は、本実施形態に係る運用管理サーバの構成例を示すブロック図である。
運用管理サーバ２は、処理装置であるＣＰＵ（Central Processing Unit）２１、主記憶装置２２、ハードディスク装置のような補助記憶装置２３およびネットワーク６（図１）や、ＬＡＮなどを介して通信を行う通信インタフェース２５を有してなる。ＣＰＵ２１と、主記憶装置２２と、補助記憶装置２３と、通信インタフェース２５は、バス２４を介して互いに接続されている。
補助記憶装置２３に保持されているストレージ運用管理プログラムが主記憶装置２２に展開され、ＣＰＵ２１によって実行されることにより、主記憶装置２２は、アプリケーションソフトウェアとして、ストレージ運用管理部２２１、業務サーバ管理処理部２２２およびストレージ装置管理処理部２２３を実現するソフトウェアを保持する。また、ストレージ運用管理部２２１は、アプリケーション管理処理部２２４、動的割当てプール管理処理部２２５、実ボリューム管理処理部２２６および仮想ボリューム管理処理部２２７を有する。

アプリケーション管理処理部２２４は、業務サーバ３で実行されているアプリケーション３２１（図３）に固有のＩ／Ｏ特性と要件指標を管理する機能、およびＩ／Ｏ特性に基づいてアプリケーション３２１をグループ化する機能などを有する。
動的割当てプール管理処理部２２５は、アプリケーショングループと、図４において後記するストレージ装置４の動的割当てプール４４とを対応付ける機能、アプリケーション３２１のＩ／Ｏ特性に基づいて動的割当てプール４４の初期容量を算出する機能、および動的割当てプール４４に実ボリューム４３１を対応付けさせる機能などを有する。

実ボリューム管理処理部２２６は、後記するストレージ装置４内における実ボリューム４３１の動的割当てプール４４への割当て状態を管理する機能などを有する。
仮想ボリューム管理処理部２２７は、動的割当てプール４４から仮想ボリューム４５を作成する機能、および仮想ボリューム４５とアプリケーション３２１との対応付けを管理する機能などを有する。

業務サーバ管理処理部２２２（Ｉ／Ｏ特性取得部）は、アプリケーション管理処理部２２４が、図３において後記する業務サーバ３のＩ／Ｏ情報監視処理部３２２からアプリケーション特性管理情報３３１（図３）を取得する機能などを有する。
ストレージ装置管理処理部２２３は、動的割当てプール管理処理部２２５、実ボリューム管理処理部２２６、および仮想ボリューム管理処理部２２７に、図４において後記するストレージ装置４のストレージ設定処理部４２１に対してストレージ設定の指示を出させる機能などを有する。

補助記憶装置２３は、ストレージ運用管理情報２３１として、アプリケーション管理表２３２（Ｉ／Ｏ特性表）、動的割当てプール管理表２３３（アプリケーショングループと、動的割当てプールとが対応付けられている情報）、実ボリューム管理表２３４、仮想ボリューム管理表２３５およびアプリケーショングループ再構成管理表２３６を保持している。これらの各表２３２〜２３６の構成は、図６〜図１０を参照して後記する。

（業務サーバ）
図３は、本実施形態に係る業務サーバの構成例を示すブロック図である。
業務サーバ３は、処理装置であるＣＰＵ３１、主記憶装置３２、ハードディスク装置のような補助記憶装置３３およびネットワーク６（図１）や、ＬＡＮを介して通信を行う通信インタフェース３５を有してなる。ＣＰＵ３１と、主記憶装置３２と、補助記憶装置３３と、通信インタフェース３５とは、バス３４を介して互いに接続されている。
補助記憶装置３３に保持されているストレージ運用管理プログラムが主記憶装置３２に展開され、ＣＰＵ３１によって実行されることにより、主記憶装置３３は、ストレージ装置４を利用するアプリケーションソフトウェアであるアプリケーション３２１と、Ｉ／Ｏ情報監視処理部３２２を実現するソフトウェアを保持する。

Ｉ／Ｏ情報監視処理部３２２は、アプリケーション３２１の入出力状況を監視し、アプリケーション特性管理情報３３１として入出力状況を補助記憶装置３３に保持する機能、および運用管理サーバ２のアプリケーション管理処理部２２４（図２参照）に対してアプリケーション特性管理情報３３１を提供する機能などを有する。

補助記憶装置３３は、アプリケーション特性管理情報３３１として、アプリケーションＩ／Ｏ特性表３３２とアプリケーションスループット表３３３とを保持している。アプリケーションＩ／Ｏ特性表３３２とアプリケーションスループット表３３３の構成は、図１１および図１２を参照して後記する。

（ストレージ装置）
図４は、本実施形態に係るストレージ装置の構成例を示すブロック図である。
ストレージ装置４は、処理装置であるＣＰＵ４１、主記憶装置４２、ネットワーク６（図１）やＬＡＮを介して通信を行う通信インタフェース４８を有する。さらに、ストレージ装置４は、ストレージ装置４とＳＡＮ７とを接続する少なくとも１つのＰＯＲＴ４４、ＰＯＲＴ４４を介して業務サーバ３からデータ格納用に利用される少なくとも１つの仮想ボリューム４５、仮想ボリューム４５に対するストレージプールとして仮想ボリューム４５にデータ格納領域を供給する少なくとも１つの動的割当てプール４４および動的割当てプール４４にデータ格納領域を供給する少なくとも１つのアレイグループ４３を有してなる。ＣＰＵ４１、主記憶装置４２、通信インタフェース４８、各アレイグループ４３および動的割当てプール４４は、バス４７を介して互いに接続されている。また、ＰＯＲＴ４４、仮想ボリューム４５および動的割当てプール４４は、接続線を介して互いに接続されている。

アレイグループ内の実ボリューム４３１に保持されているストレージ運用管理プログラムが主記憶装置４２に展開され、ＣＰＵ４１によって実行されることにより、主記憶装置４２は、アプリケーションソフトウェアとして、ストレージ設定処理部４２１を実現するソフトウェアを保持する。

ストレージ設定処理部４２１は、動的割当てプール４４と実ボリューム４３１とを対応付ける機能、動的割当てプール４４から仮想ボリューム４５を作成する機能、および仮想ボリューム４５がＰＯＲＴ４４を介してアプリケーション３２１からアクセス可能にする機能などを有する。

アレイグループ４３は、少なくとも１つの物理ディスクから構成され、動的割当てプール４４にデータ格納領域を供給する単位となる少なくとも１つの実ボリューム４３１を有する。

（処理概略）
図５は、本実施形態における処理の概略を示す図である。
図５では、アプリケーション３２１のＩ／Ｏ特性（Ｒｅａｄ／Ｗｒｉｔｅ比率、およびＲａｎｄｏｍ／Ｓｅｑｕｅｎｔｉａｌ比率）に基づいて、Ｉ／Ｏ特性の類似したアプリケーション３２１をグループ化する概念が例示されている。
図５における、グラフ５０１，５０２は、アプリケーション３２１におけるＩ／Ｏ特性をグラフ化したものであり、縦軸は、Ｒｅａｄ／Ｗｒｉｔｅ比率を示し、横軸は、Ｒａｎｄｏｍ／Ｓｅｑｕｅｎｔｉａｌ比率を示している。また、「ＡＰ１」〜「ＡＰ４」は、個別のアプリケーション３２１を示している。

つまり、グラフ５０１，５０２の縦軸において、上に行くほどＲｅａｄ中心のアプリケーション３２１であることを示し、下にいくほどＷｒｉｔｅ中心のアプリケーション３２１であることを示している。また、縦軸の中心は、ＲｅａｄとＷｒｉｔｅとの割合が、ほぼ同じアプリケーション３２１であることを示している。
同様に、グラフ５０１，５０２の横軸において、右に行くほどＳｅｑｕｅｎｔｉａｌ中心のアプリケーション３２１であることを示し、左にいくほどＲａｎｄｏｍ中心のアプリケーション３２１であることを示している。また、横軸の中心は、ＳｅｑｕｅｎｔｉａｌとＲａｎｄｏｍとの割合が、ほぼ同じアプリケーション３２１であることを示している。

グラフ５０１より、「ＡＰ２」および「ＡＰ３」は、類似したＩ／Ｏ特性を示し、「ＡＰ１」および「ＡＰ４」には、類似したアプリケーション３２１が存在しないことがわかる。従って、グラフ５０２に示すように、「ＡＰ２」および「ＡＰ３」を同一のアプリケーショングループである「ＡＧ２」としてグループ化し、「ＡＰ１」および「ＡＰ４」は、それぞれ「ＡＧ１」および「ＡＧ３」として、単独のアプリケーショングループとする。

本実施形態は、このようなアプリケーショングループを基に、ストレージ装置４における動的割当てプール４４を決定するものである。

（アプリケーション管理表）
次に、図６から図１３を参照して、本実施形態で使用される表の構造について説明する。
図６は、運用管理サーバに保持されるアプリケーション管理表の構成例を示す図である。アプリケーション管理表２３２は、業務サーバ３上で稼動する業務を担うアプリケーション３２１に関わる情報を管理するための表である。
アプリケーション管理表２３２は、フィールドとしてアプリケーションＩＤ欄２３２１、Ｒｅａｄ比率欄２３２２、Ｓｅｑｕｅｎｔｉａｌ比率欄２３２３、仮想ボリューム容量欄２３２４、データ容量欄２３２５およびアプリケーショングループ欄２３２６を有する。
欄２３２１のアプリケーションＩＤは、アプリケーション３２１の識別子となる情報で、アプリケーション管理表２３２における主キーである。欄２３２２のＲｅａｄ比率は、アプリケーションＩＤに対応しているアプリケーション３２１（以下、「対象となるアプリケーション３２１」と記載）におけるストレージ装置４に対するＩ／ＯをＲｅａｄとＷｒｉｔｅとに分類した時のＲｅａｄが占める割合である。行２３２７での場合、Ｒｅａｄ比率は０．４であり、「ＡＰ１」における全Ｉ／Ｏの４０％がＲｅａｄのＩ／Ｏであることを示す。Ｉ／Ｏの計測単位は、直近の単位時間内を想定しているが、ある時刻から現在までとしてもよい。

欄２３２３のＳｅｑｕｅｎｔｉａｌ比率は、対象となるアプリケーション３２１におけるストレージ装置４に対するＩ／ＯをＳｅｑｕｅｎｔｉａｌとＲａｎｄｏｍとに分類した時のＳｅｑｕｅｎｔｉａｌが占める割合である。行２３２７での場合、Ｓｅｑｕｅｎｔｉａｌ比率は０．２であり、「ＡＰ１」における全Ｉ／Ｏの２０％がＳｅｑｕｅｎｔｉａｌのＩ／Ｏであることを示す。ここで、ＳｅｑｕｅｎｔｉａｌとＲａｎｄｏｍの判断基準とするデータ長は、何らかの固定値とすることを想定しているが、統計的な平均値または統計的に求められる値としてもよい。
欄２３２４の仮想ボリューム容量は、対象となるアプリケーション３２１が利用するデータ格納領域（例えば、ファイルシステム）を作成するに当たり、長期的な運用を考慮して必要とされるボリュームのサイズである。
欄２３２５のデータ容量は、対象となるアプリケーション３２１が運用開始された後の当面の期間で、前記した仮想ボリューム４５内に実際に書き込まれ格納された状態となるデータの容量を示す。行２３２７で示される具体例としては、仮想ボリューム容量として、１０ＴＢのファイルシステムを作成し、当面の運用で書き込まれた状態となるデータの容量（データ容量）は１ＴＢというケースである。

欄２３２６のアプリケーショングループは、アプリケーション３２１をＩ／Ｏ特性に基づいてグループ化した結果におけるアプリケーショングループ名である。なお、図６に示す例は、図５にて例示したアプリケーショングループ構成に対応したものである。

（動的割当てプール管理表）
図７は、運用管理サーバに保持される動的割当てプール管理表の構成例を示す図である。動的割当てプール管理表２３３は、ストレージ装置４内の動的割当てプール４４の状態を管理するための表である。
動的割当てプール管理表２３３は、フィールドとしてプールＩＤ欄２３３１、アプリケーショングループ欄２３３２、Ｒｅａｄ比率欄２３３３、Ｓｅｑｕｅｎｔｉａｌ比率欄２３３４、データ容量欄２３３５、必要容量欄２３３６、ボリューム種別欄２３３７およびプール内ボリューム容量欄２３３８を有する。
欄２３３１のプールＩＤは、ストレージ装置４内の動的割当てプール４４の識別子となる情報で、動的割当てプール管理表２３３における主キーである。欄２３３２のアプリケーショングループは、図５および図６で説明したアプリケーショングループと同様であり、プールＩＤに１対１対応するものである。なお、図７では、後記する再構成処理のため、一時的に１対１の対応が維持できなくなることを考慮して別フィールドとしているが、一時的な不整合を許容することでプールＩＤと、アプリケーショングループとを同一フィールドにしてもよい。

Ｒｅａｄ比率欄２３３３のＲｅａｄ比率、欄２３３４のＳｅｑｕｅｎｔｉａｌ比率、欄２３３５のデータ容量および欄２３３６の必要容量は、プールＩＤに対応するアプリケーショングループおよび当該アプリケーショングループに属するアプリケーション３２１の特性から導出する。なお、データ容量は、当該アプリケーショングループに属するアプリケーション３２１が実際に必要とするデータの容量合計値であり、必要容量とは、データ容量を基に算出されるアプリケーションに必要な動的割当てプールの容量である。
必要容量の算出は、後記する式（１）を用いて動的割当てプール管理処理部２２５によって算出される。欄２３３７のボリューム種別は、プールＩＤで示される動的割当てプール４４を構成するのに用いられる実ボリューム４３１の種別である。動的割当てプール４４を作成した時点では「未設定」であるが、実ボリューム４３１との対応を決定する際に、ボリュームの種別（一例としては、「ＲＡＩＤ１」、「ＲＡＩＤ５」といったＲＡＩＤ構成の種類）が格納される。欄２３３８のプール内ボリューム容量は、プールＩＤで示される動的割当てプール４４に関連付けられた実ボリューム４３１の合計容量値が格納される。

（実ボリューム管理表）
図８は、運用管理サーバに保持される実ボリューム管理表の構成例を示す図である。実ボリューム管理表２３４は、ストレージ装置４内の実ボリューム４３１の、動的割当てプール４４への関連付けの状態を管理するための表である。
実ボリューム管理表２３４は、フィールドとしてボリュームＩＤ欄２３４１、アレイグループＩＤ欄２３４２、ボリューム種別欄２３４３、ボリューム容量欄２３４５およびプールＩＤ欄２３４６を有する。
欄２３４１のボリュームＩＤは、ストレージ装置４内の実ボリューム４３１の識別子となる情報で実ボリューム管理表２３４における主キーである。ストレージ運用管理システム１内にストレージ装置４が複数ある場合、ボリュームＩＤがストレージ装置４の識別子を含む形式となるが、ストレージ装置４の識別子をボリュームＩＤと別フィールドとしてもよい。欄２３４２のアレイグループＩＤは、ストレージ装置４内のアレイグループ４３の識別子となる情報である。欄２３４３のボリューム種別は、当該実ボリューム４３１の種別であり、一例としては、「ＲＡＩＤ１」や、「ＲＡＩＤ５」といったＲＡＩＤ構成の種類が保持される。欄２３４５のボリューム容量は、該当する実ボリューム４３１の容量である。欄２３４６のプールＩＤは、該当する実ボリューム４３１の動的割当てプール４４への関連付けの状態を保持し、このプールＩＤによって、実ボリューム管理表２３４は、図７の動的割当てプール管理表２３３と対応付けられている。なお、動的割当てプール４４へ割当てられていない場合、例えば「未割当て」がプールＩＤ欄２３４６に格納される。
なお、管理対象であるストレージ装置４内の全ての実ボリューム４３１の情報は、ストレージ設定処理部４２１およびストレージ装置管理処理部２２３を介して予め取得され、実ボリューム管理処理部２２６によって実ボリューム管理表２３４に格納されているものとする。

（仮想ボリューム管理表）
図９は、運用管理サーバに保持される仮想ボリューム管理表の構成例を示す図である。仮想ボリューム管理表２３５は、ストレージ装置４内の仮想ボリューム４５の状態を管理するための表である。
仮想ボリューム管理表２３５は、フィールドとしてボリュームＩＤ欄２３５１、供給元プールＩＤ欄２３５２および割当て先アプリケーションＩＤ欄２３５３を有する。
欄２３５１のボリュームＩＤは、ストレージ装置４内の仮想ボリューム４５の識別子となる情報で仮想ボリューム管理表２３５における主キーである。ストレージ運用管理システム１内にストレージ装置４が複数ある場合、ボリュームＩＤがストレージ装置４の識別子を含む形式となるが、ストレージ装置４の識別子をボリュームＩＤと別フィールドとしてもよい。欄２３５２の供給元プールＩＤは、当該仮想ボリューム４５のデータが実際に保持される動的割当てプール４４との対応を示し、動的割当てプール管理表２３３のプールＩＤに対応する値が格納される。欄２３５３の割当て先アプリケーションＩＤは、当該仮想ボリューム４５を利用する業務サーバ３内のアプリケーション３２１を示し、例えば、アプリケーション管理表２３２におけるアプリケーションＩＤ欄２３２１の値が格納される。

（アプリケーショングループ再構成管理表）
図１０は、運用管理サーバに保持されるアプリケーショングループ再構成管理表の構成例を示す図である。アプリケーショングループ再構成管理表２３６は、新規にアプリケーション３２１が追加された時、またはアプリケーション３２１のＩ／Ｏ特性が変化した時の再構成処理で一時的に用いられる表である。
アプリケーショングループ再構成管理表２３６は、フィールドとしてアプリケーションＩＤ欄２３６１、最新Ｒｅａｄ比率欄２３６２、最新Ｓｅｑｕｅｎｔｉａｌ比率欄２３６３および再構成用一時アプリケーショングループ欄２３６４を有してなる。
欄２３６１のアプリケーションＩＤは、アプリケーション３２１の識別子となる情報で、アプリケーショングループ再構成管理表２３６における主キーである。欄２３６２の最新Ｒｅａｄ比率は、図６のアプリケーション管理表２３２におけるＲｅａｄ比率と同じ定義で、当該アプリケーション３２１における再構成処理実行時のＲｅａｄ比率である。欄２３６３の最新Ｓｅｑｕｅｎｔｉａｌ比率は、図６のアプリケーション管理表２３２におけるＳｅｑｕｅｎｔｉａｌ比率と同じ定義で、当該アプリケーション３２１における再構成処理実行時のＳｅｑｕｅｎｔｉａｌ比率である。欄２３６４の再構成用一時アプリケーショングループは、前記した最新Ｒｅａｄ比率および最新Ｓｅｑｕｅｎｔｉａｌ比率によって導出された、再構成後の望ましいアプリケーショングループの構成状態を示す。

（アプリケーションＩ／Ｏ特性表）
図１１は、業務サーバに保持されるアプリケーションＩ／Ｏ特性表の構成例を示す図である。アプリケーションＩ／Ｏ特性表３３２は、業務サーバ３上で稼動するアプリケーション３２１の仮想ボリューム４５に対する入出力状況を管理するための表である。
アプリケーションＩ／Ｏ特性表３３２は、フィールドとしてボリュームＩＤ欄３３２１、アプリケーションＩＤ欄３３２２、Ｒｅａｄ数欄３３２３、Ｗｒｉｔｅ数欄３３２４、Ｓｅｑｕｅｎｔｉａｌ数欄３３２５およびＲａｎｄｏｍ数欄３３２６を有する。
欄３３２１のボリュームＩＤは、ストレージ装置４内の仮想ボリューム４５の識別子となる情報でアプリケーションＩ／Ｏ特性表３３２における主キーである。欄３３２２のアプリケーションＩＤは、業務サーバ３で実行されているアプリケーション３２１の識別子となる情報である。欄３３２３のＲｅａｄ数は、アプリケーションＩＤに対応するアプリケーション３２１（以下、アプリケーション３２１と記載）によるボリュームＩＤに対応する仮想ボリューム４５（以下、仮想ボリューム４５と記載）へのアクセスのうち、Ｒｅａｄ要求が行われた回数である。欄３３２４のＷｒｉｔｅ数は、アプリケーション３２１による仮想ボリューム４５へのアクセスのうち、Ｗｒｉｔｅ要求が行われた回数である。

欄３３２５のＳｅｑｕｅｎｔｉａｌ数は、アプリケーション３２１による仮想ボリューム４５へのアクセスのうち、１回のＩ／Ｏでのデータ長が、所定の値より長いアクセスの回数である。欄３３２６のＲａｎｄｏｍ数は、アプリケーション３２１による仮想ボリューム４５へのアクセスのうち、１回のＩ／Ｏでのデータ長が、所定の値より短いアクセスの回数である。ここで、ＳｅｑｕｅｎｔｉａｌとＲａｎｄｏｍの判断基準とするデータ長は、所定の固定値とすることを想定しているが、統計的な平均値または統計的に求められる値としてもよい。また、Ｒｅａｄ数、Ｗｒｉｔｅ数、Ｓｅｑｕｅｎｔｉａｌ数、Ｒａｎｄｏｍ数の計測単位は、直近の単位時間内を想定しているが、ある時刻から現在まで、または所定の時間帯における回数としてもよい。

（アプリケーションスループット表）
図１２は、業務サーバに保持されるアプリケーションスループット表の構成例を示す図である。アプリケーションスループット表３３３は、業務サーバ３上で稼動するアプリケーション３２１の仮想ボリューム４５に対する入出力状況を管理するための表である。
アプリケーションスループット表３３３は、フィールドとしてボリュームＩＤ欄３３３１、アプリケーションＩＤ欄３３３２およびＲｅｓｐｏｎｓｅ Ｔｉｍｅ欄３３３３を有する。
欄３３３１のボリュームＩＤは、ストレージ装置４内の仮想ボリューム４５の識別子となる情報でアプリケーションスループット表３３３における主キーである。欄３３３２のアプリケーションＩＤは、アプリケーション３２１の識別子となる情報である。欄３３３３のＲｅｓｐｏｎｓｅ Ｔｉｍｅは、アプリケーションＩＤに対応するアプリケーション３２１によるボリュームＩＤに対応する仮想ボリューム４５へのアクセスの応答時間である。Ｒｅｓｐｏｎｓｅ Ｔｉｍｅの計測の単位は、直近の単位時間内を想定しているが、ある時刻から現在まで、または所定の時間帯における応答時間としてもよい。

（要件指標付きアプリケーション管理表）
図１３は、運用管理サーバに保持される要件指標付きアプリケーション管理表の構成例を示す図である。
要件指標付きアプリケーション管理表２３２’は、図６に示すアプリケーション管理表２３２に、ストレージ装置４に関する要件指標を追加した表である。要件指標付きアプリケーション管理表２３２’は、図６に示すアプリケーション管理表２３２を代替する表として位置づけられる。なお、図１３において、図６と同様の構成要素に対しては同一の符号を付して説明を省略する。
要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ欄２３２８に格納される要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅは、アプリケーションＩＤに対応するアプリケーション３２１によるストレージ装置４への入出力に関わる応答時間である。欄２３２８の要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅは、アプリケーション３２１が業務で求められるスループットを達成するために必要な性能指標の一つである。なお、本実施形態では、性能指標としてＲｅｓｐｏｎｓｅ Ｔｉｍｅを採用したが、ＩＯＰＳや、単位時間当たりのデータ転送量など、別の性能指標を使用してもよい。また性能以外の要件指標として、信頼性やコストなどの度合いを要件指標として使用してもよい。

次に、図１から図１３を参照しつつ、図１４から図１７に沿って本実施形態におけるストレージ運用管理処理の流れを説明する。
本実施形態の処理の詳細として、ストレージ運用管理での適用シーンに応じて、（１）すでにインストールされている既存アプリケーション３２１の動的割当てプール４４環境への移行、（２）稼動中の動的割当てプール４４環境への新規アプリケーション３２１の追加、（３）Ｉ／Ｏ特性の変化によるアプリケーショングループ再構成、（４）要件指標に基づいたアプリケーショングループ再構成、（５）実ボリューム枯渇に伴う動的割当てプール４４において、ボリューム種別変更の５つのシーンに対応する実施形態について述べる。

（既存アプリケーションの動的割当てプール環境への移行）
図１４は、本実施形態に係る既存アプリケーションの動的割当てプール環境への移行処理の流れを示すフローチャートである。
図１４に示す処理動作は、動的割当てプール４４の導入直後に、既存アプリケーション３２１のＩ／Ｏ特性が分かっていて、それらのアプリケーション３２１を動的割当てプール４４の環境で稼動させるように移行をする際に行われる。

ストレージ管理プログラムが起動されると、業務サーバ３のＩ／Ｏ情報監視処理部３２２は、当該業務サーバ３で実行されているアプリケーション３２１の動作の監視を行う。そして、Ｉ／Ｏ情報監視処理部３２２によって、取得されたアプリケーション３２１のＩ／Ｏ特性およびスループット情報がアプリケーションＩ／Ｏ特性表３３２およびアプリケーションスループット表３３３に格納される。

運用管理サーバ２のアプリケーション管理処理部２２４は、業務サーバ管理処理部２２２を介して、業務サーバ３から、アプリケーションＩ／Ｏ特性表３３２の各欄３３２１〜３３２６よりアプリケーションＩＤ、Ｒｅａｄ数、Ｗｒｉｔｅ数、Ｓｅｑｕｅｎｔｉａｌ数およびＲａｎｄｏｍ数といったアプリケーション３２１のＩ／Ｏ特性を取得する（Ｓ１０１）。なお、アプリケーションＩＤは、業務サーバ３にアプリケーション３２１がインストールされる際に、業務サーバ３によって発行される。そして、アプリケーション管理処理部２２４は、取得したＲｅａｄ数およびＷｒｉｔｅ数から、Ｉ／Ｏ特性に関するＲｅａｄ比率を算出し、Ｓｅｑｕｅｎｔｉａｌ数およびＲａｎｄｏｍ数からＩ／Ｏ特性に関するＳｅｑｕｅｎｔｉａｌ比率を算出する。そして、アプリケーション管理処理部２２４は、アプリケーションＩＤ、Ｒｅａｄ比率およびＳｅｑｕｅｎｔｉａｌ比率をアプリケーション管理表２３２のアプリケーションＩＤ欄２３２１、Ｒｅａｄ比率欄２３２２およびＳｅｑｕｅｎｔｉａｌ比率欄２３２３に格納する。この際、一つのアプリケーション３２１の情報は、アプリケーション管理表２３２の一つの行として保持される。

このとき、アプリケーション管理表２３２の仮想ボリューム容量、データ容量は、システム管理者が運用管理端末５経由で、運用管理サーバ２に入力し、アプリケーション管理処理部２２４がアプリケーション管理表２３２に登録することを想定しているが、業務サーバ３のＩ／Ｏ情報監視処理部３２２が、アプリケーション３２１から仮想ボリューム容量およびデータ容量を取得して、運用管理サーバ２へ送信し、運用管理サーバ２の業務サーバ管理処理部２２２経由でアプリケーション管理処理部２２４に入力されるようにしてもよい。なお、ステップＳ１０１の時点では、アプリケーション管理表２３２のアプリケーショングループ欄２３２６には値は設定されない。また、アプリケーション３２１のＩ／Ｏ特性を、Ｉ／Ｏ情報監視処理部３２２を使わずに、システム管理者がアプリケーション３２１のＩ／Ｏ特性を机上予測した結果を運用管理端末５から運用管理サーバ２に入力し、アプリケーション管理処理部２２４が、アプリケーション管理表２３２に登録するように構成してもよい。

ステップＳ１０１の次に、アプリケーション管理処理部２２４は、アプリケーション管理表２３２のＲｅａｄ比率欄２３２２およびＳｅｑｕｅｎｔｉａｌ比率欄２３２３を参照し、Ｒｅａｄ比率とＳｅｑｕｅｎｔｉａｌ比率を基に算出されるＩ／Ｏ特性の類似度に基づいてアプリケーショングループを作成する（Ｓ１０２）。類似度の計算方法の一例としては、Ｒｅａｄ比率とＳｅｑｕｅｎｔｉａｌ比率とを２軸とした時の距離が既定値以下のアプリケーション３２１を同一グループとするようにアプリケーショングループを作成する方法が考えられる。例えば、既定値として０．３を採用し、図６の「ＡＰ１」〜「ＡＰ４」に対応するＲｅａｄ比率とＳｅｑｕｅｎｔｉａｌ比率とから距離を算出すると、「ＡＰ２」および「ＡＰ３」間の距離のみ規定値内に入っていることから、「ＡＰ２」と「ＡＰ３」とを同一のアプリケーショングループとしてグループ化する。このような概念を模式的に示したのが、図５である。グループ化の結果はアプリケーション管理表２３２のアプリケーショングループ欄２３２６に保持される。

ステップＳ１０２の次に、ステップＳ１０３を実行する。このステップＳ１０３において動的割当てプール管理処理部２２５は、アプリケーション管理表２３２のアプリケーショングループを、ストレージ装置４により発行される動的割当てプール４４のプールＩＤに対応させ、動的割当てプール管理表２３３のプールＩＤ欄２３３１とアプリケーショングループ欄２３３２に登録することで、アプリケーショングループと、動的割当てプール４４とを１対１で対応付ける（Ｓ１０３）。続いて、ステップＳ１０３では、動的割当てプール管理処理部２２５は、アプリケーション管理表２３２を参照して、対応付けられたアプリケーショングループに属するアプリケーション３２１のＲｅａｄ比率や、Ｓｅｑｕｅｎｔｉａｌ比率（Ｉ／Ｏ特性）の平均値（Ｉ／Ｏ特性値）を算出する（Ｓ１０３）。すなわち、動的割当てプール４４ごとのＩ／Ｏ特性値を算出する。平均値の算出は、単純平均でも、容量ベースでの加重平均でもよい。さらに、ステップＳ１０３において動的割当てプール管理処理部２２５は、動的割当てグループごとに対応するアプリケーショングループに含まれるアプリケーション３２１が必要とするデータ容量の合計値を算出し、動的割当てプール４４のデータ容量とし、動的割当てプール管理表２３３におけるデータ容量欄２３３５へ格納する。
さらに、動的割当てプール管理処理部２２５は、アプリケーション管理表２３２におけるＳｅｑｕｅｎｔｉａｌ比率とデータ容量から、動的割当てプール４４の初期容量として動的割当てプール４４への格納が必要な実ボリューム４３１の容量を算出する。すなわち、Ｉ／Ｏ特性に基づいて必要な動的割当てプール４４の初期容量（必要容量）を算出する（Ｓ１０３）。以下、係数を使った初期容量（必要容量）算出の計算式の一例を式（１）に示す。なお、ここでは計算式で表現したが、Ｓｅｑｕｅｎｔｉａｌ比率と必要容量の関係を定義したテーブルを用意してもよい。

必要容量＝ｍｉｎ（仮想ボリューム容量，データ容量／（ｋ＋Ｓｅｑｕｅｎｔｉａｌ比率×（１−ｋ）））（ただし、０＜ｋ＜１）・・・（１）

ｋの値は、ストレージ管理システムで固定しても、アプリケーション３２１ごとに、あるいはアプリケーション３２１の種別ごとに、システム管理者が設定できるようにしてもよい。
また、実際に動的割当てプール４４から仮想ボリューム４５に割当てられたストレージ容量と実際のアプリケーション３２１のデータ容量とから、アプリケーション３２１ごとに、またはアプリケーション３２１の種別ごとに、ｋの値を設定してもよい。

動的割当てプール管理処理部２２５は、算出した必要な初期容量を、動的割当てプール管理表２３３の必要容量欄２３３６に登録する。

ステップＳ１０３に続いて、ストレージ装置管理処理部２２３は、動的割当てプール管理表２３３を参照し、該当するプールＩＤを管理するストレージ装置４のストレージ設定処理部４２１を呼び出し、呼び出されたストレージ設定処理部４２１は、ストレージ装置４内に動的割当てプール管理表２３３に格納されている設定に従った動的割当てプール４４を作成する（Ｓ１０４）。
ステップＳ１０４の処理が終了すると、動的割当てプール管理処理部２２５は、動的割当てプール管理表２３３および予め登録されている実ボリューム管理表２３４を参照して、ストレージ管理システム内におけるすべての実ボリューム４３１の容量、Ｒｅａｄ比率とＳｅｑｕｅｎｔｉａｌ比率との２軸図におけるアプリケーショングループの相対位置、必要容量などを基に各動的割当てプール４４のボリューム種別を決定する（Ｓ１０５）。なお、実ボリューム管理表２３４は、管理対象であるストレージ装置４内のすべての実ボリューム４３１の情報が、ストレージ装置４のストレージ設定処理部４２１と運用管理サーバ２のストレージ装置管理処理部２２３を介して予め取得され、実ボリューム管理処理部２２６によって実ボリューム管理表２３４に格納されているものとする。

ボリューム種別決定におけるロジックの一実施例として、Ｗｒｉｔｅ中心（すなわち、Ｒｅａｄ比率が低い値）のアプリケーショングループに対応する動的割当てプール４４にはＲＡＩＤ１を、Ｒｅａｄ中心（すなわち、Ｒｅａｄ比率が高い値）のアプリケーショングループに対応する動的割当てプール４４にはＲＡＩＤ５を割当てるポリシなどが考えられる。そして、全体のボリューム種別の分布の中で、このようなポリシに基づいて動的割当てプール４４に対し、順序付けを行い、全体のボリューム構成の中でポリシに基づいて動的割当てプール４４を順番にならべ、１つの動的割当てプール４４が同一種別の実ボリューム４３１で構成されるようなロジックにより、動的割当てプール４４のボリューム種別を決定する方法が考えられる。
動的割当てプール管理処理部２２５は、決定されたボリューム種別を動的割当てプール管理表２３３のボリューム種別欄２３３７に反映させる。

ステップＳ１０５に続いて、仮想ボリューム管理処理部２２７は、動的割当てプール管理表２３３を参照し、プール内ボリューム容量が必要容量未満のプールＩＤに対応する動的割当てプール４４を検索する。そして、ストレージ装置管理処理部２２３は、ストレージ装置４内のストレージ設定処理部４２１を呼び出し、検索した動的割当てプール４４に実ボリューム４３１の追加を行う（Ｓ１０６）。追加対象の実ボリューム４３１は、実ボリューム管理表２３４でプールＩＤ欄２３４６が「未割当て」の実ボリューム４３１とする。なお、仮想ボリューム管理処理部２２７は、物理ディスクでのアクセス競合を回避するため、実ボリューム管理表２３４において、同一のアレイグループＩＤを持つ実ボリューム４３１が複数の動的割当てプール４４に追加されないように配分する。

そして、仮想ボリューム管理処理部２２７は、アプリケーション管理表２３２および動的割当てプール管理表２３３に格納されている各データを、ストレージ装置管理処理部２２３を介してストレージ装置４へ送信し、ストレージ装置４のストレージ設定処理部４２１は、送信された各データに基づいてアプリケーション３２１が必要とする仮想ボリューム４５を作成する（Ｓ１０７）。ステップＳ１０７の処理の後、ストレージ設定処理部４２１は、作成した仮想ボリューム４５に関するデータ（ボリュームＩＤ、供給元プールＩＤなど）を運用管理サーバ２へ送信し、運用管理サーバ２の仮想ボリューム管理処理部２２７は、送信されたデータを仮想ボリューム管理表２３５に格納する。

そして、ストレージ設定処理部４２１は、ステップＳ１０７で作成された仮想ボリューム４５をＰＯＲＴ４４と関連付けることで、アプリケーション３２１からアクセス可能にする。すなわち、ストレージ設定処理部４２１は、ストレージ装置４の仮想ボリューム４５を業務サーバ３のアプリケーション３２１に公開する（Ｓ１０８）。ストレージ設定処理部４２１は、ステップＳ１０８においてアクセス可能となったアプリケーション３２１のＩＤ（割当て先のアプリケーションＩＤ）を取得すると、運用管理サーバ２へ送信する。運用管理サーバ２の仮想ボリューム管理処理部２２７は、送信された割当て先アプリケーションＩＤを仮想ボリューム管理表２３５の割当て先アプリケーションＩＤ欄２３５３に格納する。

（稼動中の動的割当てプール環境への新規アプリケーションの追加）
図１５は、本実施形態に係る稼動中の動的割当てプール環境への新規アプリケーションの追加処理の流れを示すフローチャートである。

ストレージ管理プログラムが起動されている状態で、業務サーバ３のＩ／Ｏ情報監視処理部３２２は、当該業務サーバ３で実行されているアプリケーション３２１の動作の監視を行う。そして、Ｉ／Ｏ情報監視処理部３２２によって、取得されたアプリケーション３２１のＩ／Ｏ特性およびスループット情報がアプリケーションＩ／Ｏ特性表３３２およびアプリケーションスループット表３３３に格納される。

そして、運用管理サーバ２のアプリケーション管理処理部２２４は、図１４のステップＳ１０１と同様の処理を行って、追加するアプリケーション３２１のＩ／Ｏ特性を取得し（Ｓ２０１）、追加されるアプリケーション３２１に関するＩ／Ｏ特性情報（アプリケーションＩＤ、Ｒｅａｄ比率およびＳｅｑｕｅｎｔｉａｌ比率）をアプリケーション管理表２３２のアプリケーションＩＤ欄２３２１、Ｒｅａｄ比率欄２３２２およびＳｅｑｕｅｎｔｉａｌ比率欄２３２３に追加する（Ｓ２０２）。

続いて、アプリケーション管理処理部２２４は、ステップＳ２０２でアプリケーション管理表２３２に追加された行と、ステップＳ２０２より前にアプリケーション管理表２３２に登録されていた行とで、Ｉ／Ｏ特性の類似度の比較を行い、追加されたアプリケーション３２１と、既存のアプリケーション３２１との距離が規定値以下のものが存在するか否かを判定する。すなわち、Ｉ／Ｏ特性が類似したアプリケーション３２１が存在するか否かを判定する（Ｓ２０３）。Ｉ／Ｏ特性の類似度の比較は、図１４のステップＳ１０２で行われた処理と同様の処理である。

ステップＳ２０３でＩ／Ｏ特性が類似したアプリケーション３２１が存在しない場合（Ｓ２０３→Ｎｏ）、ステップＳ２０４〜Ｓ２１０の処理を行うことによって、追加したアプリケーション３２１に対して新たなアプリケーショングループを作成し、このアプリケーショングループに動的割当てプール４４を割当てる処理を行う。なお、ステップＳ２０４〜Ｓ２１０は、処理の対象が追加されたアプリケーション３２１であること以外は、図１４のステップＳ１０２〜Ｓ１０８の処理と同様であるため説明を省略する。

ステップＳ２０３で類似したアプリケーション３２１が存在する場合（Ｓ２０３→Ｙｅｓ）、アプリケーション管理処理部２２４は、アプリケーション管理表２３２中の既存の行の中で、ステップＳ２０２で追加された行とＩ／Ｏ特性の類似度が最も大きい行（追加されたアプリケーション３２１とＩ／Ｏ特性の類似度が最も高いアプリケーション３２１）を参照し、その行のアプリケーショングループを、ステップＳ２０２で追加された行のアプリケーショングループ欄２３２６に反映する。すなわち、アプリケーション管理処理部２２４は、追加されたアプリケーション３２１を類似度が最も高い既存のアプリケーション３２１と同じアプリケーショングループに追加する（Ｓ２１１）。

ステップＳ２１１の次に、動的割当てプール管理処理部２２５は、ステップＳ２１１で対象となったアプリケーショングループに対応する動的割当てプール４４に対して、図１４のステップＳ１０３と同様の処理を行い、Ｉ／Ｏ特性値および必要容量の再計算を行う（Ｓ２１２）。
さらに、仮想ボリューム管理処理部２２７は、ステップＳ２１２で再設定された必要容量とプール内ボリューム容量を比較し、プール内ボリューム容量が必要容量未満であった場合、ステップＳ１０６と同様の処理を行って実ボリューム４３１を動的割当てプール４４に対応付ける。すなわち、仮想ボリューム管理処理部２２７は、割当て済みの実ボリューム４３１の容量合計値が必要容量未満の場合、対象となっている動的割当てプール４４に実ボリューム４３１を追加する（Ｓ２１３）。
ステップＳ２１３の処理後、ストレージ装置４は、ステップＳ２０９およびステップＳ２１０の処理を行う。

なお、追加されたアプリケーション３２１のＩ／Ｏ特性が未知のとき、システム管理者が机上計算した追加されたアプリケーション３２１に関するＩ／Ｏ特性を入力することによって、追加されたアプリケーション３２１を既存のアプリケーショングループに入れてしまうと、追加されたアプリケーション３２１の実際のＩ／Ｏ特性が机上計算したＩ／Ｏ特性から乖離する場合がある。つまり、システム管理者が認識しているアプリケーション３２１のＩ／Ｏ特性と、実際のＩ／Ｏ特性とが異なっている場合がある。このような場合、物理ディスクでのアクセス競合によるスループット低下が生じる可能性がある。
このような状態を回避するため、追加されたアプリケーション３２１のＩ／Ｏ特性値を不明扱いにして、既存のアプリケーショングループとは独立した新たなアプリケーショングループを生成し、この新たなアプリケーショングループに対して、新たな動的割当てプール４４を割当てるようにしてもよい。この場合、業務サーバ３のＩ／Ｏ情報監視処理部３２２で、追加されたアプリケーション３２１に関する実際のＩ／Ｏ特性が取得された時点で、図１６で後記するアプリケーショングループの再構成が行われ、適切なアプリケーショングループおよび動的割当てプール４４が利用されるようになる。

（Ｉ／Ｏ特性の変化によるアプリケーショングループ再構成）
図１６は、本実施形態に係るＩ／Ｏ特性の変化によるアプリケーショングループ再構成処理の流れを示すフローチャートである。なお、図１６および図１７では、アプリケーショングループを適宜ＡＧと略記する。
図１６に示す処理動作は、動的割当てプール４４でのアプリケーション運用を開始した後、稼動中のアプリケーション３２１のＩ／Ｏ特性が変わった場合に、物理ディスクでのアクセス競合によるスループットの低下を回避するためにアプリケーショングループおよび動的割当てプール４４の再構成をする際に行われる。なお、図１６に示す処理は、例えば、一週間に一回などの周期で、運用管理サーバ２が定期的に行ったり、常にアプリケーション３２１のＩ／Ｏ特性を監視している運用管理サーバ２が、ネットワーク６を介して運用管理端末５の図示しない表示部にＩ／Ｏ特性の各値を表示し、表示されている値を基に、管理者が運用管理サーバ２へ図１６の処理を行わせる指示を送ることで、行われる処理である。

ストレージ管理プログラムが起動されている状態で、業務サーバ３のＩ／Ｏ情報監視処理部３２２は、稼動中のアプリケーション３２１の動作を監視し、運用管理サーバ２のアプリケーション管理処理部２２４は、業務サーバ管理処理部２２２を介して業務サーバ３からアプリケーション３２１のＩ／Ｏ特性を再取得し（Ｓ３０１）、再取得した最新のＩ／Ｏ特性情報（アプリケーションＩＤ、最新Ｒｅａｄ比率、および最新Ｓｅｑｕｅｎｔｉａｌ比率）をアプリケーショングループ再構成管理表２３６のアプリケーションＩＤ欄２３６１、最新Ｒｅａｄ比率欄２３６２および最新Ｓｅｑｕｅｎｔｉａｌ比率欄２３６３に格納する。ステップＳ３０１の処理は、図１４のステップＳ１０１および図１５のステップＳ２０１と同様の処理であるため、詳細な説明は省略する。

そして、ステップＳ３０２で、アプリケーション管理処理部２２４は、アプリケーショングループ再構成管理表２３６の最新のＩ／Ｏ特性（最新Ｒｅａｄ比率、最新Ｓｅｑｕｅｎｔｉａｌ比率）に基づき、図１４のステップＳ１０２と同様の処理を行うことによって、Ｉ／Ｏ特性の類似度の算出を行い、アプリケーショングループを再作成する（Ｓ３０２）と、再作成したアプリケーショングループをアプリケーショングループ再構成管理表２３６の再構成用一時アプリケーショングループ欄２３６４に格納する。

ステップＳ３０４〜Ｓ３１１は、アプリケーション管理表２３２のアプリケーショングループ（以下、既存アプリケーショングループと記載）ごとに行われる処理である。また、アプリケーショングループ再構成管理表２３６におけるアプリケーショングループを再構成アプリケーショングループと記載する。

まず、アプリケーション管理処理部２２４は、対象となっている既存アプリケーショングループと、アプリケーション構成が一致する再構成アプリケーショングループ（ＡＧ）が存在するか否かを判定する（Ｓ３０４）。
ステップＳ３０４で一致する再構成アプリケーショングループが存在する場合（Ｓ３０４→Ｙｅｓ）、動的割当てプール４４の再構成は必要ないので、ストレージ運用管理部２２１は、ステップＳ３１２へ進み、次の既存アプリケーショングループに対して、ステップＳ３０４〜Ｓ３１１の処理を繰り返す。
ステップＳ３０４で一致する再構成アプリケーショングループが存在しない場合（Ｓ３０４→Ｎｏ）、アプリケーション管理処理部２２４は、構成するアプリケーション数が増加した再構成アプリケーショングループ（ＡＧ）が存在するか否かを判定する（Ｓ３０５）。
具体的には、アプリケーション管理処理部２２４は、アプリケーション管理表２３２と、アプリケーショングループ再構成管理表２３６とを参照して、既存アプリケーショングループを構成しているアプリケーション３２１を含み、かつ異なるアプリケーション３２１をも含んでいる再構成アプリケーショングループが存在するか否かを検索する。

ステップＳ３０５で、構成するアプリケーション３２１数が増加した再構成アプリケーショングループ（ＡＧ）が存在する場合（Ｓ３０５→Ｙｅｓ）、運用管理サーバ２およびストレージ装置４は、対象となっている再構成アプリケーショングループを対象としてステップＳ３０６〜Ｓ３０９の処理を行う。ステップＳ３０６〜Ｓ３０９の処理は、図１５のステップＳ２１２〜Ｓ２１３およびステップＳ２０９〜Ｓ２１０と同様の処理であるが、ステップＳ３０９において、ストレージ設定処理部４２１は、アプリケーショングループの再構成前に仮想ボリューム４５に格納されていたアプリケーション３２１のデータを、再構成後にそのままアクセスできるよう、仮想ボリューム４５の入れ替えを行う。より具体的には、ストレージ設定処理部４２１は、アプリケーショングループの再構成前の仮想ボリューム４５のデータを、再構成の際ステップＳ３０８で作成された仮想ボリューム４５にコピーした後、再構成前の仮想ボリューム４５の公開形式と同じ形式を利用して、ステップＳ３０８で作成された仮想ボリューム４５を業務サーバ３のアプリケーション３２１に公開し、再構成前の仮想ボリューム４５を解放する。さらに、前記異なるアプリケーション３２１のアプリケーション管理表２３２の対応するアプリケーショングループ欄２３２６を、既存アプリケーショングループ名に更新する。

ステップＳ３０５で、構成するアプリケーション３２１数が増加した再構成アプリケーショングループが存在しない場合（Ｓ３０５→Ｙｅｓ）、再構成アプリケーショングループ再構成管理表２３６を参照して、構成するアプリケーション３２１数が０の再構成アプリケーショングループが存在するか否かを判定する（Ｓ３１０）。なお、ステップＳ３１０の処理は、一度行った後、次のループ処理では省略してもよい。

ステップＳ３１０で、構成するアプリケーション３２１数が０の再構成アプリケーショングループが存在しない場合、すなわち既存アプリケーショングループから１つ以上のアプリケーションがなくなり、既存アプリケーショングループに１つ以上のアプリケーションが残っている場合（Ｓ３１０→Ｎｏ）、ストレージ運用管理部２２１は、ステップＳ３１２へ進み、次の既存アプリケーショングループに対して、ステップＳ３０４〜Ｓ３１１の処理を繰り返す。なお、ステップＳ３１０で、例えば１つのアプリケーショングループが再構成の結果２つ以上のアプリケーショングループに分かれたような場合は、いずれか１つのアプリケーショングループに関してはアプリケーション３２１のアプリケーション管理表２３２の対応するアプリケーショングループ欄２３２６をそのままにし、他のアプリケーショングループに関してはアプリケーション３２１のアプリケーション管理表２３２の対応するアプリケーショングループ欄２３２６に新しいアプリケーショングループ名を設定する。

ステップＳ３１０で、構成するアプリケーション３２１数が０の再構成アプリケーショングループが存在する場合（Ｓ３１０→Ｙｅｓ）、当該アプリケーショングループおよび対応する動的割当てプール４４は不要となるため、ストレージ装置管理処理部２２３は、ストレージ装置４のストレージ設定処理部４２１に、対応する動的割当てプール４４および関連する実ボリューム４３１の解放を行わせる（Ｓ３１１）。そして、ストレージ運用管理部２２１は、ステップＳ３１２へ進み、次の既存アプリケーショングループに対して、ステップＳ３０４〜Ｓ３１１の処理を繰り返す。すべての既存アプリケーショングループに関して、図１６に示す処理を終了したら、アプリケーション管理処理部２２４は、アプリケーショングループ再構成管理表２３６の各行を削除する。

（要件指標に基づいたアプリケーショングループ再構成）
図１７は、本実施形態に係る要件指標に基づいたアプリケーショングループ再構成処理の流れを示すフローチャートである。
図１７は、図１６に示すアプリケーショングループ再構成の他の例であり、Ｉ／Ｏ特性ではなく、性能要件によってアプリケーショングループの再構成を行う例である。なお、図１７に示す処理は、図１６に示す処理を行った後に行ってもよいし、図１６に示す処理とは独立して行ってもよい。また、図１７の処理は、要件指標が、図１３の符号２３２８に示すような要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅや、ＩＯＰＳや、単位時間当たり転送量などである場合は、アプリケーション３２１におけるこれらの要件指標を運用管理サーバ２が監視しており、運用管理サーバ２は、取得した要件指標を運用管理端末５の図示しない表示部に表示させ、管理者が、表示されている用件指標を基に、図１７の処理を行う旨の指示を運用管理サーバ２に送ることによって、運用管理サーバ２が図１７の処理を行ってもよい。また、運用管理サーバ２は、アプリケーショングループ内のアプリケーション３２１に対する要件指標が、所定の値以上に乖離しているか否かを監視し、所定の値以上に乖離したら、図１７の処理を開始してもよい。
さらに、要件指標が、信頼性やコストなどの度合いである場合は、管理者がこれらの要件指標を考慮して、運用管理端末５を介して運用管理サーバ２へ図１７の処理を行う旨の指示を送ってもよい。

アプリケーション３２１のＩ／Ｏ特性が類似していても、高負荷のアプリケーション３２１が同一のアプリケーショングループに入っており、同一の動的割当てプール４４を利用する状況下では、同一物理ディスクへのアクセスの集中によりアプリケーション３２１の要件指標を満たせなくなるケースがある。なお、要件指標とは、アプリケーション３２１の性能（ＩＯＰＳ、単位時間当たり転送量、Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ）や信頼性、コストなどの指標（度合い）が考えられ、それぞれ期待値／実測値の区分が考えられる。このような場合に対し、アプリケーショングループの分割による再構成を行う例を図１７で示す。ここでは要件指標としてＲｅｓｐｏｎｓｅ Ｔｉｍｅの実測値を採用するが、他の指標、あるいは複数指標の組み合わせを用いてもよい。

要件指標は、業務サーバ３のＩ／Ｏ情報監視処理部３２２経由でアプリケーション３２１から取得するか、またはシステム管理者が運用管理端末５を介して入力し、要件指標付アプリケーション管理表２３２の要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅに格納される。

運用管理サーバ２のアプリケーション管理処理部２２４は、定期的に、またはシステム管理者からの運用管理端末５を経由した随時要求に従って、業務サーバ管理処理部２２２を経由して、業務サーバ３のアプリケーションスループット表３３３から、現在のスループット（ここではＲｅｓｐｏｎｓｅ Ｔｉｍｅの実測値）を取得する。すなわち、アプリケーション管理処理部２２４は、業務サーバ３からアプリケーション３２１の性能要件を取得する（Ｓ４０１）。
そして、アプリケーション管理処理部２２４は、取得した性能要件に基づいてアプリケーショングループを分割する（Ｓ４０２）。具体的には、アプリケーション管理処理部２２４は、取得したＲｅｓｐｏｎｓｅ Ｔｉｍｅ（性能要件）と、要件指標付きアプリケーション管理表２３２’の要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅとを比較する。そして、アプリケーション管理処理部２２４は、要求Ｒｅｓｐｏｎｓｅ ＴｉｍｅがＲｅｓｐｏｎｓｅ Ｔｉｍｅを上回っていた場合は、性能指標が未達成ということであり、性能要求が未達成のアプリケーション３２１を含むアプリケーショングループを分割して、当該アプリケーショングループ内の１つ以上のアプリケーション３２１を含むアプリケーショングループを別に作成する。そして、アプリケーション管理処理部２２４は、前記作成したアプリケーショングループを、アプリケーション管理表２３２の対応するアプリケーション３２１のアプリケーショングループ欄２３２６に前記作成したアプリケーショングループ名を格納する。
分割のためのポリシの一例として、アプリケーショングループ内で最も要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅが小さかったものを独立したアプリケーショングループとして作成する方法が考えられるが、他の方法で独立させるアプリケーション３２１を選択してもよい。別のポリシとして、要求Ｒｅｓｐｏｎｓｅ ＴｉｍｅがＲｅｓｐｏｎｓｅ Ｔｉｍｅを上回っていた場合、すなわち性能指標が未達成のアプリケーション３２１のみを含む別のアプリケーショングループを独立して作成する方法も考えられる。
さらに、アプリケーション３２１によっては時間帯によって要件指標に変動があるケースが考えられるため、要件指標付きアプリケーション管理表２３２’において、要求Ｒｅｓｐｏｎｓｅ Ｔｉｍｅを時間帯で分割して複数格納してもよい。なお、Ｉ／Ｏ特性についても、同様に時間帯で分割してアプリケーション３２１をグループ化する際の判断条件に利用してもよい。

ステップＳ４０４〜Ｓ４１２は、アプリケーション管理表２３２のアプリケーショングループごとに行われる処理である。
まず、アプリケーション管理処理部２２４は、対象となっているアプリケーショングループがステップＳ４０２で分割されたものか否かを判定する（Ｓ４０４）。
ステップＳ４０４の結果、分割されたアプリケーショングループでないと判断された場合（Ｓ４０４→Ｎｏ）、処理は必要ないので、ストレージ運用管理部２２１は、ステップＳ４１３へ進み、次のアプリケーショングループに対して、ステップＳ４０４〜Ｓ４１２の処理を繰り返す。
ステップＳ４０４の結果、分割されたアプリケーショングループであると判断された場合（Ｓ４０４→Ｙｅｓ）、アプリケーション管理処理部２２４は、新規に作成されたアプリケーショングループか否かを判断する（Ｓ４０５）。
ステップＳ４０５の結果、新規作成されたアプリケーショングループでないと判断された場合（Ｓ４０５→Ｎｏ）、図１４のステップＳ１０３と同様の処理でＩ／Ｏ特性値とデータ容量を再計算し（Ｓ４１２）、当該アプリケーショングループに対応する動的割当てプール４４に対応する動的割当てプール管理表２３３の行の、Ｒｅａｄ比率欄２３３２、Ｓｅｑｕｅｎｔｉａｌ比率欄２３３３、およびデータ容量欄２３３５を更新する。
ステップ４０５の結果、新規作成されたアプリケーショングループと判断された場合（Ｓ４０５→Ｙｅｓ）、ステップＳ４０６〜Ｓ４１１の処理を行う。ステップＳ４０６〜Ｓ４１０の処理は、図１５のステップＳ２０５〜Ｓ２０９と同様の処理であるため説明を省略する。また、ステップＳ４１１は、図１６のステップＳ３０９と同様の処理であるため説明を省略する。

（実ボリューム枯渇に伴う動的割当てプール４４のボリューム種別の変更）
動的割当てプール４４の初期作成の後、仮想ボリューム４５の容量の拡張をしたり、アプリケーション３２１のデータ容量が増加したりすることによって、ある動的割当てプール４４の必要容量が増加していき、いずれその動的割当てプール４４のボリューム種別に関して追加可能な実ボリューム４３１がなくなるケースが想定される。
その場合、ストレージ装置４のストレージ設定処理部４２１は、任意のアプリケーショングループとそれに対応する動的割当てプールを選択し、当該動的割当てプールに対応付けられているすべての実ボリューム４３１を、十分な容量のある別のボリューム種別の実ボリューム４３１と入れ替えることで、実ボリューム４３１の枯渇を回避する処理を行ってもよい。

（効果）
本実施形態によれば、Ｉ／Ｏ特性が類似したアプリケーショングループを作成し、このアプリケーショングループに対して、動的割当てプール４４を割当てる。この結果、ある動的割当てプール４４内のデータを保持する物理ディスクに対してはＩ／Ｏ特性が類似したアプリケーション３２１がアクセスする状態が維持されることで、ディスクアクセスにおけるＩ／Ｏ特性の違いによるアクセス競合によるスループット低下が回避でき、ストレージ装置４の性能をより効果的に発揮できる。
また、本実施形態によればＩ／Ｏ特性に基づいてアプリケーション３２１の実データ容量から動的割当てプール４４が初期容量として必要とする容量を算出することで動的割当てプール４４の設計を容易化できる。
そして、本実施形態によれば、性能や信頼性およびセキュリティなどのアプリケーション３２１の要件を満たすように動的割当てプール４４を運用する。この結果、ストレージ装置４の性能をより効果的に発揮できる。
さらに、本実施形態によれば、アプリケーション３２１の運用に伴うＩ／Ｏ特性の変化に応じて、アプリケーショングループを再構成し、この再構成したアプリケーションに対して動的割当てプール４４を割当てる。この結果、アプリケーション３２１の運用中にアプリケーション３２１の要件が満たされた状態を維持できるという効果がある。

本実施形態に係るストレージ運用管理システムの構成例を示すブロック図である。 本実施形態に係る運用管理サーバの構成例を示すブロック図である。 本実施形態に係る業務サーバの構成例を示すブロック図である。 本実施形態に係るストレージ装置の構成例を示すブロック図である。 本実施形態における処理の概略を示す図である。 運用管理サーバに保持されるアプリケーション管理表の構成例を示す図である。 運用管理サーバに保持される動的割当てプール管理表の構成例を示す図である。 運用管理サーバに保持される実ボリューム管理表の構成例を示す図である。 運用管理サーバに保持される仮想ボリューム管理表の構成例を示す図である。 運用管理サーバに保持されるアプリケーショングループ再構成管理表の構成例を示す図である。 業務サーバに保持されるアプリケーションＩ／Ｏ特性表の構成例を示す図である。 業務サーバの保持されるアプリケーションスループット表の構成例を示す図である。 運用管理サーバに保持される要件指標付きアプリケーション管理表の構成例を示す図である。 本実施形態に係る既存アプリケーションの動的割当てプール環境への移行処理の流れを示すフローチャートである。 本実施形態に係る稼動中の動的割当てプール環境への新規アプリケーションの追加処理の流れを示すフローチャートである。 本実施形態に係るＩ／Ｏ特性の変化によるアプリケーショングループ再構成処理の流れを示すフローチャートである。 本実施形態に係る要件指標に基づいたアプリケーショングループ再構成処理の流れを示すフローチャートである。

符号の説明

１ ストレージ運用管理システム
２ 運用管理サーバ
３ 業務サーバ
４ ストレージ装置
５ 運用管理端末
６ ネットワーク
７ ＳＡＮ
４３ アレイグループ
４４ 動的割当てプール
４４ ＰＯＲＴ
４５ 仮想ボリューム
２２１ ストレージ運用管理部
２２２ 業務サーバ管理処理部（アプリケーション特性取得部）
２２３ ストレージ装置管理処理部
２２４ アプリケーション管理処理部
２２５ 動的割当てプール管理処理部
２２６ 実ボリューム管理処理部
２２７ 仮想ボリューム管理処理部
２３１ ストレージ運用管理情報
２３２ アプリケーション管理表（Ｉ／Ｏ特性情報）
２３３ 動的割当てプール管理表（アプリケーショングループと、動的割当てプールとが対応付けられている情報）
２３４ 実ボリューム管理表
２３５ 仮想ボリューム管理表
２３６ アプリケーショングループ再構成管理表
３２１ アプリケーション
３２２ Ｉ／Ｏ情報監視処理部
３３１ アプリケーション特性管理情報
３３２ アプリケーションＩ／Ｏ特性表
３３３ アプリケーションスループット表
４２１ ストレージ設定処理部
４３１ 実ボリューム

Claims (19)

1. ストレージ装置における実ボリュームの仮想ボリュームへの割当てを管理している動的割当てプールを決定するストレージ管理装置におけるストレージ管理方法であって、
   前記ストレージ管理装置は、
   アプリケーション実行装置で実行されているアプリケーションのＩ／Ｏ特性を取得し、
   前記アプリケーションと、前記アプリケーションのＩ／Ｏ特性とを対応付けたＩ／Ｏ特性情報を前記アプリケーション毎に記憶部に格納し、
   前記記憶部のＩ／Ｏ特性に基づいて、各アプリケーションのＩ／Ｏ特性の類似度を算出し、前記類似度によって前記アプリケーションを、複数のグループにグループ化し、
   前記グループと、前記動的割当てプールとを対応付けることを特徴とするストレージ管理方法。
2. 前記記憶部には、前記Ｉ／Ｏ特性と、前記仮想ボリューム内で実際に前記アプリケーションが使用するデータの容量とが対応付けられて格納されており、
   前記ストレージ管理装置は、
   前記記憶部における前記Ｉ／Ｏ特性と前記アプリケーションで使用されるデータの容量を基に、前記アプリケーションに必要な動的割当てプールの容量を算出し、前記算出した容量を前記動的割当てプールの初期容量とすることを特徴とする請求項１に記載のストレージ管理方法。
3. 前記記憶部には、前記アプリケーションの性能を示す性能要件が、アプリケーション毎に記憶されており、
   前記ストレージ管理装置は、
   前記性能要件を基に、さらに、前記アプリケーションの再グループ化を行うことを特徴とする請求項１に記載のストレージ管理方法。
4. 前記ストレージ管理装置は、
   前記動的割当てプールに対して、ボリュームの種別を示すボリューム種別を割当てることを特徴とする請求項１に記載のストレージ管理方法。
5. 前記Ｉ／Ｏ特性とは、前記アプリケーションによるストレージ装置へのアクセス方法の比率であることを特徴とする請求項１に記載のストレージ管理方法。
6. 前記性能要件は、アプリケーションによる前記ストレージ装置に対するレスポンス時間であることを特徴とする請求項３に記載のストレージ管理方法。
7. 前記性能要件は、前記アプリケーションに対する信頼性の高さの度合いであることを特徴とする請求項３に記載のストレージ管理方法。
8. 前記ストレージ管理装置は、
   前記Ｉ／Ｏ特性を新たに取得し、
   前記新たに取得したＩ／Ｏ特性を基に、アプリケーションの再グループ化を行うことを特徴とする請求項１に記載のストレージ管理方法。
9. 前記再グループ化の結果、前記アプリケーションが割当てられていないグループが存在する場合、
   当該グループに割当てられていた動的割当てプールを解放し、前記動的割当てプールに割当てられていた実ボリュームを解放することを特徴とする請求項８に記載のストレージ管理方法。
10. 前記ストレージ管理装置は、
    前記Ｉ／Ｏ特性を新たに取得し、
    前記新たに取得したＩ／Ｏ特性を基に、アプリケーションの再グループ化を行い
    前記再グループの結果、割当てられているアプリケーションの数が増大したグループが存在する場合、
    前記前記動的割当てプールの初期容量を再算出することを特徴とする請求項２に記載のストレージ管理方法。
11. 前記アクセス方法とは、ランダムアクセスおよびシーケンシャルアクセスであることを特徴とする請求項５に記載のストレージ管理方法。
12. 前記アクセス方法とは、前記ストレージ装置への書込みおよび前記ストレージ装置からの読込みであることを特徴とする請求項５に記載のストレージ管理方法。
13. ストレージ装置にアクセスする新たなアプリケーションが追加された場合、入力部または通信手段を介して前記追加されたアプリケーションのＩ／Ｏ特性を取得し、
    前記追加されたアプリケーションのＩ／Ｏ特性から所定の距離以内に存在するグループが存在する場合、前記追加されたアプリケーションを当該グループに追加することを特徴とする請求項１に記載のストレージ管理方法。
14. 前記追加されたアプリケーションのＩ／Ｏ特性から所定の距離以内に存在するグループが存在しない場合、前記追加されたアプリケーションに対し、新たなグループを生成し、当該グループに基づいて、動的割当てプールの割当てを決定することを特徴とする請求項１３に記載のストレージ管理方法。
15. 前記動的割当てプールにおいて必要な実ボリュームの容量が増大し、前記実ボリュームの容量が不足する状態となったとき、接続されている実ボリュームを、当該実ボリュームより大きな空き容量を有するボリューム種別の実ボリュームに交換することを特徴とする請求項４に記載のストレージ管理方法。
16. 請求項１から請求項１５のいずれか一項に記載のストレージ管理方法をコンピュータに実行させることを特徴とするストレージ管理プログラム。
17. ストレージ装置における実ボリュームの仮想ボリュームへの割当てを管理している動的割当てプールを決定するストレージ管理装置であって、
    アプリケーション実行装置で実行されているアプリケーションのＩ／Ｏ特性を取得するアプリケーション特性取得部と、
    前記アプリケーションと、前記アプリケーションのＩ／Ｏ特性とを対応付けたＩ／Ｏ特性情報を前記アプリケーション毎に記憶部に格納し、前記記憶部のＩ／Ｏ特性に基づいて、各アプリケーションのＩ／Ｏ特性の類似度を算出し、前記類似度によって前記アプリケーションを複数のグループにグループ化するアプリケーション管理処理部と、
    前記グループと、前記動的割当てプールとを対応付ける動的割当てプール管理処理部とを有することを特徴とするストレージ管理装置。
18. 前記記憶部には、前記Ｉ／Ｏ特性と、前記仮想ボリューム内で実際に前記アプリケーションが使用するデータの容量とが対応付けられて、さらに格納されており、
    前記動的割当てプール管理処理部は、
    前記記憶部における前記Ｉ／Ｏ特性と前記アプリケーションで使用されるデータの容量を基に、前記アプリケーションに必要な動的割当てプールの容量を算出し、前記算出した容量を前記動的割当てプールの初期容量とする機能をさらに有することを特徴とする請求項１７に記載のストレージ管理装置。
19. ストレージ装置における実ボリュームの仮想ボリュームへの割当てを管理している動的割当てプールを決定するストレージ管理装置と、アプリケーションを実行しているアプリケーション実行装置と、前記ストレージ装置とが互いに接続しているストレージ管理システムであって、
    前記ストレージ管理装置は、
    アプリケーション実行装置で実行されているアプリケーションのＩ／Ｏ特性を取得するアプリケーション特性取得部と、
    前記アプリケーションと、前記アプリケーションのＩ／Ｏ特性とを対応付けたＩ／Ｏ特性情報を前記アプリケーション毎に記憶部に格納し、前記記憶部のＩ／Ｏ特性に基づいて、各アプリケーションのＩ／Ｏ特性の類似度を算出し、前記類似度によって前記アプリケーションを複数のグループにグループ化するアプリケーション管理処理部と、
    前記グループと、前記動的割当てプールとを対応付ける動的割当てプール管理処理部とを有することを特徴とするストレージ管理システム。

Images