JPWO2014184893A1 - 計算機システム及びリソース管理方法 - Google Patents

Abstract

計算機システムは、複数の実リソースを有する１以上の実ストレージ装置で構成されたストレージシステムと、ストレージシステムに接続された管理システムとを有する。管理システムは、複数の実リソースを有する１以上の実ストレージ装置各々の実リソースに関する上限値を含む第１情報と、テナントが使用可能なリソースであるテナント用リソース又はそのテナント用リソースの基になるリソースとして割り当てられる実リソースに関する上限値である第２情報とに基づいて、前記１以上の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとしてテナントに割り当てる。

Description

本発明は、複数のリソースを有する実ストレージ装置を含む計算機システムにおけるリソースの管理技術に関する。

複数の実ストレージ装置がネットワークを介して互いに接続された計算機システムにおいて、複数の実ストレージ装置の複数の論理ボリュームを、一つの仮想ストレージ装置の同一の論理ボリュームとしてホスト計算機及び管理計算機に提供する、ボリューム識別子管理方法が利用されている（例えば特許文献１参照）。

上記ボリューム識別子管理方法により、ホスト計算機上のボリューム利用業務やボリューム管理を停止することなく、仮想ストレージ装置の論理ボリュームを、任意の実ストレージ装置からネットワーク内の任意の実ストレージ装置に移行することができる。

一方、近年、実ストレージ装置を複数の会社や複数の部署などで共有して使用する大規模ストレージ集約環境では、ストレージ管理者の負担を軽減するために、ストレージ管理方法として、会社毎又は部署毎に管理者を配置し、それぞれの管理者に実ストレージリソースを配分するマルチテナンシ型の管理方法が求められている。このような環境においては、例えば、複数クラスタに実ストレージリソースを論理分割するリソース構成管理方法が、利用されている（特許文献２参照）。

米国特許出願公開第２００８／００３４００５号明細書 米国特許出願公開第２００６／０２２４８５４号明細書

例えば、マルチテナンシ型の管理方法によると、各テナントの管理者は、自身が担当する仮想的なストレージ装置のみを意識してリソースの管理を行うことができる。

しかしながら、複数のテナントが実ストレージ装置を共用することとなるので、他のテナントによるリソースの割り当てに応じて、自身のリソースの割り当てが制限されてしまう可能性がある。例えば、或るテナントがボリュームを割り当てる際に、そのテナントが利用している実ストレージ装置に他のテナントによって多くのボリュームが割り当てられている場合には、実ストレージ装置の作成可能なボリューム数の制約によって、ボリュームを割り当てることができない可能性がある。また、各テナントの管理者は、他のテナントによるリソースの使用状況を把握することができないので、リソースの割り当てが制限されることを予め把握することもできない。

計算機システムは、複数の実リソースを有する１以上の実ストレージ装置で構成されたストレージシステムと、ストレージシステムに接続された管理システムとを有する。管理システムは、複数の実リソースを有する１以上の実ストレージ装置各々の実リソースに関する上限値を含む第１情報と、テナントが使用可能なリソースであるテナント用リソース又はそのテナント用リソースの基になるリソースとして割り当てられる実リソースに関する上限値である第２情報とに基づいて、前記１以上の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとしてテナントに割り当てる。

ストレージシステムのテナントに対して、実ストレージ装置の実リソースを適切に割り当てることができる。

図１は、実施例１に係る計算機システムの一例の構成図である。 図２は、実施例１に係る計算機システムの他の例の構成図である。 図３は、実施例１に係るストレージ装置の構成図である。 図４は、実施例１に係る制御情報用メモリの構成図である。 図５は、実施例１に係る外部管理サーバの構成図である。 図６は、実施例１に係るユーザアカウント管理テーブルの構成図である。 図７は、実施例１に係るＲＰＵ管理テーブルの構成図である。 図８は、実施例１に係るリソースＩＤ管理テーブルの構成図である。 図９は、実施例１に係るストレージ装置モデルリストの構成図である。 図１０は、実施例１に係る物理リソース上限テーブルの構成図である。 図１１は、実施例１に係る仮想リソース上限テーブルの構成図である。 図１２は、実施例１に係る物理リソーステーブルの構成図である。 図１３は、実施例１に係る仮想リソースプール物理リソース対応テーブルの構成図である。 図１４は、実施例１に係るタスク管理テーブルの構成図である。 図１５は、実施例１に係るライセンス管理テーブルの構成図である。 図１６は、実施例１に係る性能履歴テーブルの構成図である。 図１７は、実施例１に係る構成管理テーブルの構成図である。 図１８は、実施例１に係る性能下限テーブルの構成図である。 図１９は、実施例１に係るＶＤＫＣ上限値設定処理の第１の例のフローチャートである。 図２０は、実施例１に係るＶＤＫＣ上限値設定処理の第２の例のフローチャートである。 図２１は、実施例１に係る平準化設定処理のフローチャートである。 図２２は、実施例１に係る変更対象選択処理の第１のフローチャートである。 図２３は、実施例１に係る変更対象選択処理の第２のフローチャートである。 図２４は、実施例１に係る設定変更処理の第１のフローチャートである。 図２５は、実施例１に係る設定変更処理の第２のフローチャートである。 図２６は、実施例２に係る仮想リソースプール物理リソース対応テーブル作成処理のフローチャートである。 図２７は、実施例２に係る平準化設定処理のフローチャートである。 図２８は、実施例２に係るテーブル作成詳細処理のフローチャートである。 図２９は、実施例２に係る変更対象選択処理の第１のフローチャートである。 図３０は、実施例２に係る変更対象選択処理の第２のフローチャートである。 図３１は、実施例２に係る変更対象選択処理の第３のフローチャートである。 図３２は、実施例２に係る設定変更処理のフローチャートである。 図３３は、実施例３に係るＶＤＫＣ下限値設定処理のフローチャートである。 図３４は、実施例３に係る平準化設定処理のフローチャートである。 図３５は、実施例３に係るＲＰＵ作成処理のフローチャートである。 図３６は、実施例３に係るリソース決定割当処理の第１の例のフローチャートである。 図３７は、実施例３に係るリソース決定割当処理の第２の例の第１のフローチャートである。 図３８は、実施例３に係るリソース決定割当処理の第２の例の第２のフローチャートである。 図３９は、実施例４に係るリソース集約時の変更対象選択処理の第１のフローチャートである。 図４０は、実施例４に係るリソース集約時の変更対象選択処理の第２のフローチャートである。 図４１は、実施例４に係るリソース集約時の変更対象選択処理の第３のフローチャートである。 図４２は、実施例４に係る設定変更処理のフローチャートである。 図４３は、実施例５に係るＶＤＫＣの上限値設定処理のフローチャートである。

幾つかの実施例を、図面を参照して説明する。なお、以下に説明する実施例は特許請求の範囲にかかる発明を限定するものではなく、また実施例で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

なお、以後の説明では「ａａａテーブル」等の表現にて本発明の情報を説明する場合があるが、これら情報は、テーブル等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」等について「ａａａ情報」と呼ぶことがある。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェース装置（例えばポート）を用いながら行うため、処理の主語がプロセッサとされても良い。プログラムを主語として説明された処理は、プロセッサを含むコントローラーが行う処理としても良い。また、コントローラーは、プロセッサそれ自体であっても良いし、プロセッサに代えて又は加えて、プロセッサが行う処理の一部又は全部を行うハードウエア回路を含んでも良い。コンピュータプログラムは、プログラムソースから装置にインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機が読み取り可能な記憶メディアであっても良い。

まず、実施例１に係る計算機システムについて説明する。

図１は、実施例１に係る計算機システムの一例の構成図である。

計算機システムは、例えば、ホスト計算機１０００と、複数のストレージ装置（実ストレージ装置）２０００と、外部管理サーバ３０００とを有する。外部管理サーバ３０００と、ストレージ装置２０００とは、ストレージネットワーク７０００を介して接続されている。また、外部管理サーバ３０００、ホスト計算機１０００、及びストレージ装置２０００は、ストレージネットワーク５０００を介して接続されている。

複数のストレージ装置２０００は、バックエンドストレージネットワーク６０００を介して相互に接続されている。各ストレージ装置２０００は、他のストレージ装置２０００に、バックエンドストレージネットワーク６０００を介してＳＣＳＩコマンドを転送することができる。なお、バックエンドストレージネットワーク６０００とストレージネットワーク５０００とは同一のネットワークであっても良い。

計算機システムにおいては、複数のストレージ装置２０００により、ＤＫＣプール４０００を構成している。このＤＫＣプール４０００は、ホスト計算機１０００からのＳＣＳＩコマンドの送信可能範囲である。

ＤＫＣプール４０００は、複数のストレージ装置２０００に跨る１以上のＲＰＵ（ＲＥＳＯＵＲＣＥ ＰＡＲＴＩＴＩＯＮＩＮＧ ＵＮＩＴ）２９００を含む。ここで、ＲＰＵが、テナントが使用するオブジェクトの概念の一例であり、ＲＰＵに割り当てられたリソースが、テナントが使用可能でありテナントに割り当てられたリソースの一例である。ＲＰＵ２９００は、複数のストレージ装置２０００の複数のリソースにより構成される。ＲＰＵ２９００は、ホスト計算機１０００及び外部管理サーバ３０００に仮想的なストレージ装置（仮想ストレージ装置又はＶＤＫＣと呼称する）として提供される。ここでは仮想ストレージ装置はテナントの一例であり、ホスト計算機に対してストレージ装置として提供されるテナントである。一方でテナントと表記する場合には、ホスト計算機にストレージ装置として提供される必要はなく、また、テナントに割り当てるリソース群は必ずしもストレージを構成するに十分なリソース構成でなくてもよい。本実施例では仮想ストレージ装置について説明するが、本リソース管理技術は仮想ストレージに限定されるものではなくテナントであれば適用可能な発明である。また、ＤＫＣプール４０００において、複数のＲＰＵ２９００を構成するようにしても良い。また、複数のＲＰＵ２９００により、１つの仮想ストレージ装置を構成しても良い。

外部管理サーバ３０００は、管理者からの指示に従って各種処理を実行する。ここで、管理者としては、例えば、１つの仮想ストレージ装置に対する管理操作の権限のみを有している管理者（ＶＤＫＣ管理者）８０００や、ＤＫＣプール４０００を構成するすべてのストレージ装置２０００に対する管理操作の権限を有している管理者（ＤＫＣＰＯＯＬ管理者）８５００がいる。

図２は、実施例１に係る計算機システムの他の例の構成図である。

計算機システムは、ホスト計算機１０００と一つのストレージ装置（実ストレージ装置）２０００とを含む。ホスト計算機１０００とストレージ装置２０００とは、ストレージネットワーク５０００を介して接続される。

外部管理サーバ３０００は、管理者（ユーザ）８０００、８５００が、ストレージ装置２０００にアクセスする際に利用される。外部管理サーバ３０００は、管理者８０００、８５００からの指示に従って管理コマンドをストレージ装置２０００に送信する。また、外部管理サーバ３０００は、仮想ストレージ装置（ＲＰＵ２９００）に実リソースを割り当てる処理を制御する。なお、外部管理サーバ３０００の少なくとも一部の処理を、いずれかのストレージ装置２０００の内部管理サーバ２６００が実行するようにしても良い。

ストレージ装置２０００は、内部管理サーバ２６００を有する。内部管理サーバ２６００は、ネットワーク７０００を介して、外部管理サーバ３０００から管理コマンドを受信し、その管理コマンドを内部制御コマンドに変換して、ストレージ装置２０００内の他の要素に転送する。また、内部管理サーバ２６００は、外部管理サーバ３０００からのアクセス制御を行う。

ストレージ装置２０００は、複数のリソース（実リソース）を含み、１以上のＲＰＵ２９００を有する。図２の例では、ＲＰＵ２９００には、仮想ストレージ装置を構成するリソースを含むＲＰＵ２９００（ＲＰＵ＃０１、ＲＰＵ＃０２）と、仮想ストレージ装置に割り当てられていないリソースを含むＲＰＵ２９００（ＲＰＵ＃００）とがある。図２の例では、１つのＲＰＵが１つの仮想ストレージ装置を構成している。各リソースには、ストレージ装置２０００内でリソースを識別可能な実リソース識別子が付与されている。

ＲＰＵ２９００に含まれるリソース（実リソース）としては、例えば、ポート２８１０、ボリューム２８００、パリティグループ２８２０等がある。パリティグループ２８２０は、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｄｅｐｅｎｄｅｎｔ Ｄｉｓｋｓ）グループであり、ＲＡＩＤを構成する複数のドライブのグループである。ボリューム２８００は、例えば、論理デバイス（ＬＤＥＶ）である。ボリューム２８００は、例えば、１つのパリティグループを構成する記憶領域の一部の記憶領域に対応する。なお、後述するＭＰＰＫ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｏｒ ＰａｃＫａｇｅ）２２００、ＣＭＰＫ（Ｃａｃｈｅ Ｍｅｍｏｒｙ ＰａｃＫａｇｅ）２３００等の他の種類のリソースをＲＰＵ２９００に含めても良い。

図２の例では、ＲＰＵ＃０１（ＲＰＵ ＩＤ＝０１のＲＰＵ２９００）は、ＶＳＡ＃１１１１の仮想ストレージ装置を構成し、ＲＰＵ＃０２（ＲＰＵ ＩＤ＝０２のＲＰＵ２９００）は、ＶＳＡ＃１２１２の仮想ストレージ装置を構成している。ＲＰＵ＃０１及びＲＰＵ＃０２に割り当てられている各リソースには、仮想ストレージ装置のリソースとして、仮想リソース識別子（ＶＩＤ）２３２６Ｄが付与されている。なお、ＲＰＵ＃００（ＲＰＵ ＩＤ＝００のＲＰＵ２９００）に含まれている仮想ストレージ装置に未割り当てのリソースに対して、仮想リソース識別子は付与されていない。

本実施例に係る計算機システムでは、初期状態において、全てのリソース（本例では、ポート２８１０、ボリューム２８００、パリティグループ２８２０）がＲＰＵ＃００に含まれており、その後に、ＲＰＵ＃０１、ＲＰＵ＃０２が作成される際にＲＰＵ＃００から各ＲＰＵに割り当てるリソースが移動される。なお、ボリューム２８００は、ＲＰＵ＃０１、ＲＰＵ＃０２において新たに作成可能である。

計算機システムでは、各仮想ストレージ装置に対して個別のネームスペースが定義されている。各ネームスペースは独立しているため、仮想ストレージ装置内において、他の仮想ストレージ装置及びストレージ装置２０００で使用されているリソース識別子（仮想リソース識別子及び実リソース識別子）を考慮することなく、仮想ストレージ装置内で一意である仮想リソース識別子を自由にＲＰＵ２９００内のリソースに割り当てることができる。

図３は、実施例１に係るストレージ装置の構成図である。

ストレージ装置２０００は、１以上のＦＥＰＫ（ＦｒｏｎｔＥｎｄ ＰａｃＫａｇｅ）２１００、１以上のＭＰＰＫ２２００、１以上のＣＭＰＫ２３００、１以上のＢＥＰＫ（ＢａｃｋＥｎｄ ＰａｃＫａｇｅ）２４００、記憶デバイスの一例としての１以上のＨＤＤ（ハードディスクドライブ）２７００、内部ネットワーク２５００、及び内部管理サーバ２６００を含む。なお、図３では、ＦＥＰＫ２１００、ＭＰＰＫ２２００、ＣＭＰＫ２３００、及びＢＥＰＫ２４００等のパッケージについては、そのパッケージ内の一部の構成要素のみを図示しており、図示した構成要素以外の構成要素が含まれていても良い。

内部ネットワーク２５００は、ＦＥＰＫ２１００、ＭＰＰＫ２２００、ＣＭＰＫ２３００、ＢＥＰＫ２４００、及び管理サーバ２６００は、内部ネットワーク２５００を介して接続されている。これにより、ＭＰＰＫ２２００の各ＭＰ（Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｏｒ）２２１０は、内部ネットワーク２５００を介して、ＦＥＰＫ２１００、ＣＭＰＫ２３００、ＢＥＰＫ２４００、及び管理サーバ２６００と通信することができる。

ＦＥＰＫ２１００は、ホスト計算機１０００と通信するためのインタフェースデバイスである。ＦＥＰＫ２１００は、複数のホストＩ／Ｆ２１１０を有する。ホストＩ／Ｆ２１１０は、ネットワーク５０００を介してホスト計算機１０００のＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ）と接続し、ホスト計算機１０００との間の通信におけるプロトコル制御を行う。例えば、１つのホストＩ／Ｆ２１１０は、１つのポートに対応する。なお、ホストＩ／Ｆ２１１０が複数のポートを有していても良い。

ＢＥＰＫ２４００は、ＨＤＤ２７００と通信するためのインタフェースデバイスである。ＢＥＰＫ２４００は、複数のディスクＩ／Ｆ２４１０を有する。ディスクＩ／Ｆ２４１０は、例えば、ケーブルを介してＨＤＤ２７００と接続されるとともに、内部ネットワーク２５００と接続される。ディスクＩ／Ｆ２４１０は、内部ネットワーク２５００側とＨＤＤ２７００との間におけるリード又はライト対象のデータの受け渡しを仲介する。

ＣＭＰＫ２３００は、データキャッシュ用メモリ２３１０と、制御情報用メモリ２３２０とを有する。データキャッシュ用メモリ２３１０と、制御情報用メモリ２３２０とは、不揮発性メモリ、又は、揮発メモリ、例えば、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。

データキャッシュ用メモリ２３１０は、ＨＤＤ２７００へライトするライト対象のデータを一時的に格納（キャッシュ）し、又はＨＤＤ２７００からリードしたリード対象のデータを一時的に格納（キャッシュ）する。制御情報用メモリ２３２０は、ストレージ装置２０００における処理に必要なプログラムや情報を格納する。制御情報用メモリ２３２０が格納しているプログラムや情報については後述する。

ＭＰＰＫ２２００は、複数のＭＰ２２１０と、ローカルメモリ（ＬＭ）２２２０と、バス２２３０とを有する。ＭＰ２２１０と、ＬＭ２２２０とは、バス２２３０を介して接続されている。ＬＭ２２２０は、制御情報用メモリ２３２０に格納されている制御情報の一部を格納する。

内部管理サーバ２６００は、計算機であり、制御情報用メモリ２３２０からＬＭ２２２０にロードされ、ＭＰ２２１０により実行されている制御プログラムへ、外部管理サーバ３０００からの各種情報（例えば、管理者による各種指示等）を伝達する。内部管理サーバ２６００は、キーボード、スイッチ、ポインティングデバイス、マイクロフォンなどの入力デバイス（図示せず）と、ディスプレイやスピーカなどの出力デバイスとを有していても良い。

図４は、実施例１に係る制御情報用メモリの構成図である。

制御情報用メモリ２３２０は、ストレージ装置制御プログラム２３２１、ＲＰＵ管理プログラム２３２２、リソースＩＤ管理プログラム２３２３、及びユーザアカウント管理プログラム２３２４を格納している。

ストレージ装置制御プログラム２３２１は、ホスト計算機１０００から受け取ったリード要求及びライト要求に対応する処理を実行する。また、ストレージ装置制御プログラム２３２１は、ストレージ装置２０００内における様々の制御処理を行う。

ＲＰＵ管理プログラム２３２２は、ストレージ装置２０００内のＲＰＵの管理処理を行う。リソースＩＤ管理プログラム２３２３は、ストレージ装置２０００のリソースに付与されている実リソース識別子及び仮想リソース識別子を管理する処理を行う。ユーザアカウント管理プログラム２３２４は、ユーザ認証の処理、ストレージ装置２０００のユーザアカウントの管理処理（例えば、各ユーザのアクセス権限の情報の管理処理）を実行する。

制御情報用メモリ２３２０は、ＲＰＵ管理テーブル２３２５、リソースＩＤ管理テーブル２３２６、ユーザアカウント管理テーブル２３２７、ストレージ装置モデルリスト２３２８、物理リソース上限テーブル２３３０、仮想リソース上限テーブル２３３１、及び物理リソーステーブル２３３２を格納する。なお、各テーブルの詳細は後述する。

図５は、実施例１に係る外部管理サーバの構成図である。

外部管理サーバ３０００は、例えば、パーソナルコンピュータ、ワークステーション、またはメインフレームなどの計算機により構成され、プロセッサ３１００、メモリ３２００、入力デバイス３７００、出力デバイス３６００、及びＩ／Ｆ３８００を有する。プロセッサ３１００、メモリ３２００、入力デバイス３７００、及び出力デバイス３６００及びＩ／Ｆ３８００は、内部バスを介して接続されている。

入力デバイス３７００は、例えば、キーボード、スイッチやポインティングデバイス等により構成され、ユーザからの入力を受け付ける。出力デバイス３６００は、ディスプレイやスピーカ等により構成され、ユーザに対して各種情報を出力する。Ｉ／Ｆ３８００は、ストレージ装置２０００との間の通信を行うインタフェースデバイスである。

プロセッサ３１００は、外部管理サーバ３０００全体を統括制御する。プロセッサ３１００は、メモリ３２００に格納されたプログラムを実行することにより各種処理を実行する。メモリ３２００は、ストレージ管理プログラム３２１０、リソース割当決定プログラム３２２０、及び上限値計算プログラム３２３０を格納する。各プログラムによる処理の詳細は、後述する。また、メモリ３２００は、仮想リソースプール物理リソース対応テーブル３２４０、管理側物理リソース上限テーブル３２５０、管理側仮想リソース上限テーブル３２６０、性能下限テーブル３２６５、ライセンス管理テーブル３２７０、管理側物理リソーステーブル３２８０、管理側リソースＩＤ管理テーブル３２９０、タスク管理テーブル３２９５、性能履歴テーブル３２９７、及び構成管理テーブル３２９８を格納する。

管理側物理リソース上限テーブル３２５０は、各ストレージ装置２０００の物理リソース上限テーブル２３３０を集約したテーブルである。なお、管理側物理リソース上限テーブル３２５０は、１つのテーブルとして構成しても良く、各ストレージ装置２０００の物理リソース上限テーブル２３３０を有する構成としても良い。

管理側仮想リソース上限テーブル３２６０は、各ストレージ装置２０００の仮想リソース上限テーブル２３３１を集約したテーブルである。なお、管理側仮想リソース上限テーブル３２６０は、１つのテーブルとして構成しても良く、各ストレージ装置２０００の仮想リソース上限テーブル２３３１を有する構成としても良い。

管理側物理リソーステーブル３２８０は、各ストレージ装置２０００の物理リソーステーブル２３３２を集約したテーブルである。なお、管理側物理リソーステーブル３２８０は、１つのテーブルとして構成しても良く、各ストレージ装置２０００の物理リソーステーブル２３３２を有する構成としても良い。

管理側リソースＩＤ管理テーブル３２９０は、各ストレージ装置２０００のリソースＩＤ管理テーブル２３２６を集約したテーブルである。なお、管理側リソースＩＤ管理テーブル３２９０は、１つのテーブルとして構成しても良く、各ストレージ装置２０００のリソースＩＤ管理テーブル２３２６を有する構成としても良い。なお、他のテーブルの詳細は、後述する。

図６は、実施例１に係るユーザアカウント管理テーブルの構成図である。

ユーザアカウント管理テーブル２３２７は、ユーザＩＤ欄２３２７Ａ、ＲＰＵ ＩＤ欄２３２７Ｂ、権限欄２３２７Ｃ、及びパスワード欄２３２７Ｄを有するエントリを格納する。

ユーザＩＤ欄２３２７Ａには、管理者のユーザＩＤが格納される。ＲＰＵ ＩＤ欄２３２７Ｂには、ユーザＩＤに対応する管理者に割り当てられているＲＰＵのＩＤ（ＲＰＵ ＩＤ）が格納される。なお、管理者に対して全てのＲＰＵが割り当てられている場合には、ＲＰＵ ＩＤ欄２３２７Ｂには、「ＲＰＵ＃ＦＦ」が設定される。

権限欄２３２７Ｃには、ユーザＩＤに対応する管理者に対して与えられている操作権限の種別が格納される。

操作権限の種別が「ＳＴＯＲＡＧＥ ＡＤＭＩＮ」である場合には、ユーザＩＤに対応する管理者は、割り当てられているＲＰＵ（仮想ストレージ装置）内において、全ての操作を行うことができる。例えば、この権限を有するユーザは、ボリュームの作成及び削除やコピーペアの制御等を行うことができる。一方、この権限を有するユーザは、ＲＰＵの作成、ＲＰＵの物理リソースの変更（追加・削除）など、ＲＰＵの物理リソースを制御すること、仮想ストレージ装置の仕様を変更することはできない。ここで、ＲＰＵの物理リソースは、ポート及びパリティグループである。

操作権限の種別が「ＭＯＤＩＦＹ ＶＩＲＴＵＡＬ ＳＴＯＲＡＧＥ」である場合には、ユーザＩＤに対応する管理者は、仮想ストレージ装置の作成及び変更を行うことができる。この権限を有するユーザは、新たにＲＰＵを作成し、ＲＰＵの物理リソースを変更し（リソース割り当て）、新たに仮想ストレージ装置を定義してＲＰＵを割り当て、仮想ストレージ装置の仕様を変更することができる。ＲＰＵの物理リソースの変更は、ＲＰＵ間の物理リソースの移動を意味する。したがって、一つのＲＰＵの物理リソースを変更するためには、ユーザが、他のＲＰＵに対する「ＭＯＤＩＦＹ ＶＩＲＴＵＡＬ ＳＴＯＲＡＧＥ」の権限も有することが必要である。なお、操作権限の種類及びその内容は、図６に示す例に限られず、これらと異なる権限が定義されていても良い。

パスワード欄２３２７Ｄには、ユーザＩＤに対応する管理者のパスワードが格納される。

図６に示すユーザアカウント管理テーブル２３２７によると、例えば、「ＶＤＫＣ１．ＡＤＭＩＮ」の管理者（例えば図１における管理者８０００）は、ＰＤＫＣ１．ＲＰＵ＃０１、ＰＤＫＣ２．ＲＰＵ＃０１、ＰＤＫＣ３．ＲＰＵ＃０１に対して、「ＳＴＯＲＡＧＥ ＡＤＭＩＮ」の権限を有していることがわかる。また、「ＤＫＣＰＯＯＬ．ＡＤＭＩＮ」の管理者（例えば図１における管理者８５００）は、全てのＲＰＵ（ＲＰＵ＃ＦＦ）に対して、「ＳＴＯＲＡＧＥ ＡＤＭＩＮ」と「ＭＯＤＩＦＹ ＶＩＲＴＵＡＬ ＳＴＯＲＡＧＥ」との操作権限を有している。

ユーザアカウント管理プログラム２３２４は、外部管理サーバ３０００からの指示に従って、ユーザアカウント管理テーブル２３２７においてユーザアカウントを登録する。具体的には、内部管理サーバ２６００が、外部管理サーバ３０００から、ユーザアカウントの追加、変更、削除等の指示を登録内容の情報と共に受信し、それらを起動したユーザアカウント管理プログラム２３２４に転送する。ユーザアカウント管理プログラム２３２４は、転送された指示に従って、ユーザアカウント管理テーブル２３２７を更新する。

上述のように、内部管理サーバ２６００は、ユーザアカウント管理テーブル２３２７の情報に従って、ユーザからのアクセスを制御する。例えば、内部管理サーバ２６００は、外部管理サーバ３０００から、ログインを行うためのユーザＩＤ及びパスワードを受信し、それをユーザアカウント管理プログラム２３２４に転送する。

ユーザアカウント管理プログラム２３２４は、ユーザＩＤ及びパスワードをユーザアカウント管理テーブル２３２７の情報と比較して、ユーザＩＤが、ユーザアカウント管理テーブル２３２７に登録されているか確認する。ユーザＩＤが登録されている場合、ユーザアカウント管理プログラム２３２４は、ユーザが登録されている旨の認証結果とこのユーザＩＤのユーザの権限情報を内部管理サーバ２６００に送信する。ユーザＩＤが登録されていない場合、ユーザアカウント管理プログラム２３２４は、ユーザが登録されていない旨の認証結果を内部管理サーバ２６００に送信する。

ログインを試みているユーザが登録されていない場合、内部管理サーバ２６００は、ログインエラーを外部管理サーバ３０００に返す。一方、ユーザが登録されている場合、内部管理サーバ２６００は、その後の外部管理サーバ３０００からのこのユーザによる管理コマンドを、このユーザの操作権限内において処理する。具体的には、内部管理サーバ２６００は、ユーザの管理操作範囲を、このユーザに割り当てられているＲＰＵ内のリソースに限定し、さらに実行できる操作を割り当てられた権限内で許される操作に限定する。

例えば、内部管理サーバ２６００は、ユーザによる、割り当てられていないＲＰＵの仮想ストレージ装置におけるボリューム操作（ボリューム作成や削除、ペア形成等）の要求を拒否する。また、内部管理サーバ２６００は、「ＭＯＤＩＦＹ ＶＩＲＴＵＡＬ ＳＴＯＲＡＧＥ」権限を有していないユーザからの仮想ストレージ装置の作成要求やリソース移動（リソース割り当て）の要求を拒否する。

図７は、実施例１に係るＲＰＵ管理テーブルの構成図である。

ＲＰＵ管理テーブル２３２５は、ＲＰＵ ＩＤ欄２３２５Ａ、ベンダ欄２３２５Ｂ、モデル欄２３２５Ｃ、シリアル番号（Ｓ／Ｎ）欄２３２５Ｄ、管理ポートＩＰアドレス欄２３２５Ｅ、及び状態欄２３２５Ｆを有するエントリを格納する。ＲＰＵ管理テーブル２３２５においては、欄の値に「０」が設定されている場合には、値が割り当てられていないことを意味する。

ＲＰＵ ＩＤ欄２３２５Ａには、ストレージ装置２０００内でＲＰＵを一意に特定可能な識別子（ＲＰＵ ＩＤ）が格納される。ベンダ欄２３２５Ｂ、モデル欄２３２５Ｃ、及びＳ／Ｎ欄２３２５Ｄには、それぞれ、ＲＰＵが表現する（ＲＰＵが割り当てられている）仮想ストレージ装置の仮想ベンダ名（ベンダの仮想識別子）、仮想モデル名（モデルの仮想識別子）、仮想シリアル番号が格納される。

これら仮想ベンダ名、仮想モデル名、及び仮想シリアル番号の組が、ストレージ装置２０００内で一意である、仮想ストレージ装置を特定する仮想識別子に相当する。なお、ベンダ欄２３２５Ｂ、モデル欄２３２５Ｃ、又はシリアル番号欄２３２５Ｄに「ＤＥＦＡＵＬＴ」が設定されている場合には、対応する欄には、ストレージ装置２０００の実値が割り当てられていることを意味する。

管理ポートＩＰアドレス欄２３２５Ｅには、ＲＰＵ管理用に定義されている内部管理サーバ２６００へアクセスするためのＩＰアドレス（アクセスＩＰアドレス）が格納される。例えば、一つの物理ポートにおいて、アクセスＩＰアドレスがマスカレードされ、各仮想ストレージ装置に一つのアクセスＩＰアドレスが割り当てられている。

状態欄２３２５Ｆには、ＲＰＵの状態を示す値（ＲＰＵステータス）が格納される。ＲＰＵステータスが「アクティブ」の場合には、エントリに対応するＲＰＵが仮想ストレージ装置を表現中、すなわち、この仮想ストレージ装置が動作中であることを示す。この場合には、ストレージ装置２０００は、ホスト計算機１０００と外部管理サーバ３０００からの識別子応答要求に対して、仮想識別子（仮想ストレージ装置の仮想識別子と仮想リソース識別子とを含む）を応答する。

ＲＰＵステータスが「非アクティブ」の場合には、エントリに対応するＲＰＵが仮想ストレージ装置を表現しておらず、すなわち、この仮想ストレージ装置は動作していないことを示す。この場合、ストレージ装置２０００は、ホスト計算機１０００と外部管理サーバ３０００からの識別子応答要求に対して、このＲＰＵの仮想識別子を応答しない。

図８は、実施例１に係るリソースＩＤ管理テーブルの構成図である。

リソースＩＤ管理テーブル２３２６は、実リソースＩＤ欄２３２６Ａ、種別欄２３２６Ｂ、ＲＰＵ ＩＤ欄２３２６Ｃ、及び仮想リソースＩＤ欄２３２６Ｄを有するエントリを格納する。

実リソースＩＤ欄２３２６Ａには、ストレージ装置２０００に対して定義されているネームスペースにおいて、各リソースをストレージ装置２０００内で一意に特定可能な識別子（実リソース識別子）が格納される。

種別欄２３２６Ｂには、エントリに対応するリソースの種別が格納される。本実施例においては、リソースの種別としては、ＰＯＲＴ（ポート）、ＶＯＬＵＭＥ（ボリューム）、ＰＡＲＩＴＹ ＧＲＯＵＰ（パリティグループ）がある。なお、種別欄２３２６Ｂにこれ以外の種別が登録されてもよい。

ＲＰＵ ＩＤ欄２３２６Ｃには、エントリに対応するリソースが所属するＲＰＵの識別子（ＲＰＵ ＩＤ）が格納される。本実施例においては、全てのリソースがいずれかのＲＰＵに属しているので、ＲＰＵ ＩＤ欄２３２６Ｃには、いずれかのＲＰＵ ＩＤが格納されている。

仮想リソースＩＤ欄２３２６Ｄには、エントリに対応するリソースに対応する仮想リソース識別子が格納される。仮想リソース識別子は、ＲＰＵに対して定義されているネームスペースにおいてリソースを一意に特定可能な識別子である。仮想識別子（ＩＤ）は、仮想ストレージ装置の仮想識別子（ＩＤ）又はリソースに付与される仮想リソース識別子（ＩＤ）を示す。仮想リソースＩＤ欄２３２６Ｄに「ＮＵＬＬ」が設定されている場合には、エントリに対応するリソースに、仮想リソース識別子が付与されていないことを示す。

各ＲＰＵにおいて仮想リソース識別子を付与するために、それぞれにネームスペースが定義される。そのため、各ＲＰＵ（仮想ストレージ装置）において、他のＲＰＵの仮想リソース識別子及び実ストレージ装置２０００において付与される実リソース識別子と独立して、各リソースに対して仮想リソース識別子を付与することができる。これにより、各ＲＰＵにおいて自由に仮想リソース識別子を付与でき、実ストレージ装置２０００において複数の仮想ストレージ装置を提供するための管理を容易化することができる。

ＲＰＵ ＩＤは、ストレージ装置２０００において一意であり、ＲＰＵ ＩＤと仮想リソース識別子との組で構成される識別子は、実リソース識別子と同様に、ストレージ装置２０００においてリソースを一意に特定可能である。同様に、ＲＰＵが表現する仮想ストレージ装置の仮想ベンダＩＤ、仮想モデル名、及び仮想シリアル番号の組で構成される仮想識別子と、仮想リソース識別子とにより、ストレージ装置２０００においてリソースを一意に特定可能である。

リソースＩＤ管理プログラム２３２３は、リソースＩＤ管理テーブル２３２６を管理する。リソースがＲＰＵ間で移動され、仮想リソース識別子が付与されるようなリソース構成に変更があると、リソースＩＤ管理プログラム２３２３は、その変更に応じてリソースＩＤ管理テーブル２３２６を更新する。

図９は、実施例１に係るストレージ装置モデルリストの構成図である。

ストレージ装置モデルリスト２３２８は、ベンダＩＤ欄２３２８Ａと、モデル欄２３２８Ｂとを有するエントリを格納する。

ベンダＩＤ欄２３２８Ａには、表現可能なベンダのベンダＩＤが格納される。モデル欄２３２８Ｂには、ベンダＩＤ欄２３２８ＡのベンダＩＤのベンダにより提供される仮想ストレージ装置のモデルのモデル名が格納される。

管理者は、ストレージ装置モデルリスト２３２８のエントリから、一つのエントリを選択し、ストレージ装置２０００において作成する仮想ストレージ装置に対して、ベンダ名とモデル名とを付与することができる。ＲＰＵは、ストレージ装置モデルリスト２３２８に登録されているベンダ名とモデル名との組合せを有する仮想ストレージ装置を表現可能である。

リソースＩＤ管理プログラム２３２３は、ストレージ装置モデルリスト２３２８を管理する。例えば、リソースＩＤ管理プログラム２３２３は、外部管理サーバ３０００から受信した指示に従って、ストレージ装置モデルリスト２３２８を更新する。

図１０は、実施例１に係る物理リソース上限テーブルの構成図である。

物理リソース上限テーブル２３３０は、種別欄２３３０Ａと、上限値欄２３３０Ｂとを有するエントリを格納する。

種別欄２３３０Ａには、物理リソースの種別が格納される。上限値欄２３３０Ｂには、物理ストレージ装置２０００におけるエントリの種別欄２３３０Ａの物理リソースの種別に対応する物理リソースに関する上限値（第１情報の一例）が格納される。ここで、上限値２３３０Ａに設定される上限値としては、物理リソースの種別によって設定される値の種類が異なっても良く、例えば、物理リソースの個数、性能値、又は容量の上限値であっても良い。例えば、上限値２３３０Ａには、物理リソースの種別がボリュームの場合には、作成可能なボリュームの個数の上限値が設定され、物理リソースの種別がＰＯＲＴの場合には、ＰＯＲＴの数の上限値が設定され、物理リソースの種別がストレージプールの場合には、ストレージプールの容量の上限値が設定されても良い。

図１１は、実施例１に係る仮想リソース上限テーブルの構成図である。

仮想リソース上限テーブル２３３１は、ＲＰＵ ＩＤ欄２３３１Ａ、種別欄２３３１Ｂ、及び上限値欄２３３１Ｃを有するエントリを格納する。

ＲＰＵ ＩＤ欄２３３１Ａには、ＲＰＵ ＩＤが格納される。種別欄２３３１Ｂには、仮想リソースの種別が格納される。仮想リソースの種別は、物理リソースの種別と同様である。上限値欄２３３１Ｃには、ＲＰＵ ＩＤのＲＰＵにおけるエントリの種別欄２３３１Ｂの種別の仮想リソースに関する上限値が格納される。なお、仮想リソースには、物理リソースが割り当てられることとなるので、この仮想リソースの上限値は、物理リソースの上限値に対応し、第２情報の一例である。ここで、上限値２３３１Ｃに設定される上限値としては、仮想リソースの種別によって設定される値の種類が異なっても良く、例えば、仮想リソースの個数、性能値、又は容量の上限値であっても良い。例えば、上限値２３３１Ｃには、仮想リソースの種別がボリュームの場合には、作成可能なボリュームの個数の上限値が設定され、仮想リソースの種別がＰＯＲＴの場合には、ＰＯＲＴの数の上限値が設定され、仮想リソースの種別がストレージプールの場合には、ストレージプールの容量の上限値が設定されても良い。

図１２は、実施例１に係る物理リソーステーブルの構成図である。

物理リソーステーブル２３３２は、リソース種別欄２３３２Ａ、実リソースＩＤ欄２３３２Ｂ、及びスペック欄２３３２Ｃを有するエントリを格納する。

リソース種別欄２３３２Ａには、リソースの種別が格納される。実リソースＩＤ欄２３３２Ｂには、エントリのリソース種別欄２３３２Ａのリソースの種別に対応する実リソースの識別子（実リソースＩＤ）が格納される。スペック欄２３３２Ｃには、エントリの実リソースＩＤ欄２３３２Ｂの実リソースに関するスペックが格納される。スペック欄２３３２Ｃに格納されるスペックとしては、例えば、リソース種別がボリュームの場合には、ボリュームのサイズであり、リソース種別がパリティグループの場合には、パリティグループのサイズであり、リソース種別がポートの場合には、通信速度である。

図１３は、実施例１に係る仮想リソースプール物理リソース対応テーブルの構成図である。

仮想リソースプール物理リソース対応テーブル３２４０は、ＲＰＵに属するリソースプールを管理するテーブルであり、ＲＰＵ ＩＤ欄３２４０Ａ、リソースプールＩＤ欄３２４０Ｂ、リソース種別欄３２４０Ｃ、ＰＤＫＣ ＩＤ欄３２４０Ｄ、及び実リソースＩＤ欄３２４０Ｅを有するエントリを格納する。

ＲＰＵ ＩＤ欄３２４０Ａには、ＲＰＵ ＩＤが格納される。リソースプールＩＤ欄３２４０Ｂには、ＲＰＵ ＩＤ欄３２４０ＡのＲＰＵ ＩＤのＲＰＵ（仮想ストレージ装置）におけるリソース種別毎のリソースが属するリソースプールの識別子（リソースプールＩＤ）が格納される。リソース種別欄３２４０Ｃには、エントリのリソースプールＩＤ欄３２４０ＢのリソースプールＩＤのリソースプールに属するリソースの種別が格納される。ＰＤＫＣ ＩＤ欄３２４０Ｄには、エントリのＲＰＵ ＩＤのＲＰＵを構成するストレージ装置（ＰＤＫＣ）２０００の識別子（ＰＤＫＣ ＩＤ）が格納される。実リソースＩＤ欄３２４０Ｅには、エントリに対応するリソースプールに属する実リソースの実リソースＩＤが格納される。

図１４は、実施例１に係るタスク管理テーブルの構成図である。

タスク管理テーブル３２９５は、タスクＩＤ欄３２９５Ａ、実行ユーザＩＤ欄３２９５Ｂ、処理名欄３２９５Ｃ、対象装置欄３２９５Ｄ、対象リソースプールＩＤ欄３２９５Ｅ、対象リソースＩＤ欄３２９５Ｆ、スペック欄３２９５Ｇ、実行予定（済）時間欄３２９５Ｈ、及び実行状況欄３２９５Ｉを有するエントリを格納する。

タスクＩＤ欄３２９５Ａには、タスクを識別する識別子（タスクＩＤ）が格納される。実行ユーザＩＤ欄３２９５Ｂには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクを実行させるユーザの識別子（実行ユーザＩＤ）が格納される。処理名欄３２９５Ｃには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクで実行する操作内容の処理名が格納される。対象装置３２９５Ｄには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクで操作を実行する対象のＲＰＵのＲＰＵ ＩＤが格納される。

対象リソースプールＩＤ欄３２９５Ｅには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクで操作を実行する対象のリソースプールの識別子（リソースプールＩＤ）が格納される。対象リソースＩＤ欄３２９５Ｆには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクで操作を実行する対象のリソースの識別子（リソースＩＤ）が格納される。スペック欄３２９５Ｇには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクで操作するリソースに対する操作量が格納される。実行予定（済）時間欄３２９５Ｈには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクを実行する予定の時間又は、タスクの実行が済んだ時間が格納される。実行状況欄３２９５Ｉには、エントリのタスクＩＤ欄３２９５ＡのタスクＩＤのタスクの実行状況が格納される。実行状況欄３２９５Ｉに格納される実行状況としては、例えば、タスクが完了したことを示す「完了」、タスクの実行中であることを示す「実行中」、タスクがまだ実行されていないことを示す「未実行」がある。

図１５は、実施例１に係るライセンス管理テーブルの構成図である。

ライセンス管理テーブル３２７０は、ＲＰＵ ＩＤ欄３２７０Ａ及びライセンス料欄３２７０Ｂを有するエントリを格納する。ＲＰＵ ＩＤ欄３２７０Ａには、ＲＰＵ ＩＤが格納される。ライセンス料欄３２７０Ｂには、エントリのＲＰＵ ＩＤ欄３２７０ＡのＲＰＵ ＩＤのＲＰＵに対するライセンス料が格納される。なお、ライセンス料に代えて、ライセンス料を支払うことにより得られるＲＰＵの容量などの情報としても良い。

図１６は、実施例１に係る性能履歴テーブルの構成図である。

性能履歴テーブル３２９７は、物理リソースの性能値の情報を管理するテーブルであり、ＰＤＫＣ ＩＤ欄３２９７Ａ、実リソースＩＤ欄３２９７Ｂ、種別欄３２９７Ｃ、時間欄３２９７Ｄ、及び性能値欄３２９７Ｅを有するエントリを格納する。

ＰＤＫＣ ＩＤ欄３２９７Ａには、ＰＤＫＣのＰＤＫＣ ＩＤが格納される。実リソースＩＤ欄３２９７Ｂには、実リソースの実リソースＩＤが格納される。種別欄３２９７Ｃには、エントリの実リソースＩＤ欄３２９７ＢのリソースＩＤに対応する実リソースの種別が格納される。時間欄３２９７Ｄには、性能値欄３２９７Ｅの性能値を測定した時間が格納される。性能値欄３２９７Ｅには、エントリの実リソースＩＤ欄３２９７Ｂの実リソースＩＤに対応する実リソースの時間欄３２９７Ｄの時間における性能値が格納される。

図１７は、実施例１に係る構成管理テーブルの構成図である。

構成管理テーブル３２９８は、ＲＰＵ ＩＤ欄３２９８Ａ、仮想ＰＯＲＴリソースＩＤ欄３２９８Ｂ、ＷＷＮ欄３２９８Ｃ、仮想ＨｏｓｔＧｒｏｕｐ欄３２９８Ｄ、仮想ＶＯＬリソースＩＤ欄３２９８Ｅ、及びＬＵＮ欄３２９８Ｆを有するエントリを格納する。

ＲＰＵ ＩＤ欄３２９８Ａには、ＲＰＵのＲＰＵ ＩＤが格納される。仮想ＰＯＲＴリソースＩＤ欄３２９８Ｂには、仮想ポートのリソースＩＤ（仮想ＰＯＲＴリソースＩＤ）が格納される。ＷＷＮ欄３２９８Ｃには、仮想ＰＯＲＴリソースＩＤ欄３２９８ＢのリソースＩＤに対応する仮想ポートのＷＷＮ（World Wide Name）が格納される。仮想ＨｏｓｔＧｒｏｕｐ欄３２９８Ｄには、仮想ホストグループの識別子が格納される。仮想ＶＯＬリソースＩＤ欄３２９８Ｅには、仮想ボリュームのリソースＩＤが格納される。ＬＵＮ欄３２９８Ｆには、エントリの仮想ＶＯＬリソースＩＤ欄３２９８ＥのリソースＩＤに対応する仮想ボリュームのＬＵＮ（Logical Unit Number）が格納される。

図１８は、実施例１に係る性能下限テーブルの構成図である。

性能下限テーブル３２６５は、ＲＰＵ ＩＤ欄３２６５Ａ、仮想リソースＩＤ欄３２６５Ｂ、及び性能要件欄３２６５Ｃを有するエントリを格納する。

ＲＰＵ ＩＤ欄３２６５Ａには、ＲＰＵのＲＰＵ ＩＤが格納される。仮想リソースＩＤ欄３２６５Ｂには、エントリのＲＰＵ ＩＤ欄３２６５Ａに対応するＲＰＵにおける仮想リソースのリソースＩＤ（仮想リソースＩＤ）が格納される。性能要件欄３２６５Ｃには、エントリのＲＰＵ ＩＤ欄３２６５ＡのＲＰＵ ＩＤのＲＰＵにおける仮想リソースＩＤ欄３２６５ＢのリソースＩＤの仮想リソースに対する性能要件、すなわち、必要とされる性能の下限値が格納される。性能要件としては、例えば、仮想リソースがボリュームである場合には、ボリュームに対して要求されるＩＯＰＳ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｐｅｒ Ｓｅｃｏｎｄ）の下限値が格納される。なお、図１８に示す性能下限テーブル３２６５では、ボリュームに対する性能要件を管理する例を示しているが、Ｐｏｒｔ、ストレージ装置、又はアプリケーションに対する性能要件を管理するようにしても良い。

次に、第１実施例に係る計算機システムにおける処理動作について説明する。

まず、ＶＤＫＣ上限値設定処理について説明する。ＶＤＫＣ上限値設定処理は、例えば、計算機システムにＶＤＫＣを新たに設定した後等に外部管理サーバ３０００により実行される。ＶＤＫＣ上限値設定処理としては、例えば、ＶＤＫＣに対するライセンス料の情報に基づいて、ＶＤＫＣにおける仮想リソースに関する上限値を設定するＶＤＫＣ上限値設定処理（図１９参照）や、ＶＤＫＣに割当て済みのＰｏｏｌ容量に基づいて、ＶＤＫＣにおける他の仮想リソースに関する上限値を設定するＶＤＫＣ上限値設定処理（図２０参照）がある。

図１９は、実施例１に係るＶＤＫＣ上限値設定処理の第１の例のフローチャートである。

図１９に示すＶＤＫＣ上限値設定処理は、ＶＤＫＣに対するライセンス料の情報に基づいて、ＶＤＫＣにおける仮想リソースに関する上限値を作成して設定する処理である。

外部管理サーバ３０００の上限値計算プログラム３２３０は、ライセンス管理テーブル３２７０を参照し、各ＶＤＫＣ（ＲＰＵ）に対応するライセンス料の情報を取得する（ステップＦ１００１）。

次いで、上限値計算プログラム３２３０は、各ＶＤＫＣのライセンス料の比率に基づいて、各ＰＤＫＣにおける各ＶＤＫＣの各リソースに対する上限値を計算する（ステップＦ１００２）。例えば、各ＰＤＫＣに、ＲＰＵ＃０１と、ＲＰＵ＃０２とが存在し、これらのライセンス料の比率が２：１である場合には、各仮想リソースの上限値について、ＲＰＵ＃０１に対するリソースの上限値と、ＲＰＵ＃０２に対するリソースの上限値との比がライセンス料の比率となるように計算する。より具体的には、各ＰＤＫＣにおける各ＶＤＫＣのＰｏｏｌ容量の上限値については、各ＰＤＫＣのＰｏｏｌ容量合計を、ＲＰＵ＃０１に対するリソースの上限値と、ＲＰＵ＃０２に対するリソースの上限値との比がライセンス料の比率となるように計算する。

なお、全ての種類の仮想リソースに対して、各ＶＤＫＣのリソースの上限値の比が、ライセンス料の比率となるようにしても良く、また、仮想リソースの一部の種類の上限値については、ライセンス料の比率によらず、一定としても良い。より具体的には、例えば、各ＶＤＫＣのボリュームのサイズの上限値について一定とし、ボリュームの数の上限値をライセンス料の比率としても良く、また、各ＶＤＫＣのボリュームのサイズの上限値についてライセンス料の比率とし、ボリュームの数の上限値を一定としても良い。また、各ＶＤＫＣのリソースの上限値の比をライセンス料の比率とせずに、ライセンス料の比率に基づいて算出される比率としても良い。

次いで、上限値計算プログラム３２３０は、計算した各リソースの上限値を管理側仮想リソース上限値テーブル３２６０の各リソースに対応するエントリに設定する（ステップＦ１００３）。

次いで、ストレージ管理プログラム３２１０が内部管理サーバ２６００のストレージ制御プログラム２３２１と通信し、仮想リソース上限テーブル２３３１の各リソースに対応する上限値を更新する（ステップＦ１００４）。これにより、各ストレージ装置２０００の仮想リソース上限テーブル２３３１に、算出されたリソースの上限値が設定されることとなる。

図２０は、実施例１に係るＶＤＫＣ上限値設定処理の第２の例のフローチャートである。

図２０に示すＶＤＫＣ上限値設定処理は、ＶＤＫＣに割当て済みのＰｏｏｌ容量に基づいて、ＶＤＫＣにおける他の仮想リソースに関する上限値を作成して設定する処理である。

外部管理サーバ３０００の上限値計算プログラム３２３０は、管理側リソースＩＤ管理テーブル３２９０及び管理側物理リソース管理テーブル３２８０を参照して、各ＶＤＫＣ（ＲＰＵ）に割当て済みのＰＤＫＣ毎のＰｏｏｌ容量の合計（Ｐｏｏｌ容量合計）を算出する（ステップＦ１００５）。具体的には、管理側リソースＩＤ管理テーブル３２９０を参照することにより、各ＶＤＫＣに対して各ＰＤＫＣにより割り当てられているＰｏｏｌの実リソースＩＤを特定し、その実リソースＩＤを用いて管理者側物理リソース管理テーブル３２８０を参照することにより、実リソースＩＤに対応するＰｏｏｌ容量を特定し、このＰｏｏｌ容量をＰＤＫＣ毎に、各ＶＤＫＣの容量別に合計する。

次いで、上限値計算プログラム３２３０は、各ＰＤＫＣのＰｏｏｌ容量合計と、各ＰＤＫＣにおける各ＶＤＫＣに割り当て済みのＰｏｏｌ容量合計との比率とに基づいて、各ＰＤＫＣにおける各ＶＤＫＣの各リソースに対する上限値を計算する（ステップＦ１００６）。例えば、或るＰＤＫＣに、ＲＰＵ＃０１と、ＲＰＵ＃０２とが存在し、このＰＤＫＣにおける各ＲＰＵのＰｏｏｌ容量合計の比率が２：１である場合には、このＰＤＫＣにおける各仮想リソースの上限値について、ＲＰＵ＃０１に対するリソースの上限値と、ＲＰＵ＃０２に対するリソースの上限値との比が各ＲＰＵのＰｏｏｌ容量合計の比率となるように計算する。

なお、全ての種類の仮想リソースに対して、各ＶＤＫＣのリソースの上限値の比が、各ＰＤＫＣにおける各ＲＰＵのＰｏｏｌ容量合計の比率となるようにしても良く、また、仮想リソースの一部の種類の上限値については、各ＲＰＵのＰｏｏｌ容量合計の比率によらず、一定としても良い。より具体的には、例えば、各ＶＤＫＣのボリュームのサイズの上限値について一定とし、ボリュームの数の上限値を各ＲＰＵのＰｏｏｌ容量合計の比率としても良く、また、各ＶＤＫＣのボリュームのサイズの上限値について各ＲＰＵのＰｏｏｌ容量合計の比率とし、ボリュームの数の上限値を一定としても良い。また、各ＶＤＫＣのリソースの上限値の比を各ＰＤＫＣにおける各ＲＰＵのＰｏｏｌ容量合計の比率とせずに、各ＰＤＫＣにおける各ＲＰＵのＰｏｏｌ容量合計の比率に基づいて算出される比率としても良い。

次いで、上限値計算プログラム３２３０は、計算した各リソースの上限値を管理側仮想リソース上限値テーブル３２６０の各リソースに対応するエントリに設定する（ステップＦ１００７）。

次いで、ストレージ管理プログラム３２１０がストレージ制御プログラム２３２１と通信し、仮想リソース上限テーブル２３３１の各リソースに対応する上限値を更新する（ステップＦ１００８）。これにより、各ストレージ装置２０００の仮想リソース上限テーブル２３３１に、算出されたリソースの上限値が設定されることとなる。

次に、平準化設定処理について説明する。平準化設定処理は、仮想リソースをＲＰＵに対して割り当てる処理であり、ＶＤＫＣ上限値設定処理が終了した後に実行される。

図２１は、実施例１に係る平準化設定処理のフローチャートである。

外部管理サーバ３０００のストレージ管理プログラム３２１０は、管理者からＶＤＫＣに対する構成変更指示を受け付けると（ステップＦ１３００）、変更対象選択処理（図２２及び図２３参照）の実行を開始する（ステップＦ１４００）。この変更対象選択処理が実行されると、リソースの変更を行う対象のＰＤＫＣが選択される。ここで、構成変更指示には、例えば、仮想リソースを変更する対象のＶＤＫＣを特定する情報や、変更する対象の仮想リソースを特定する情報が含まれている。

次いで、リソース割当決定プログラム３２２０が設定変更処理（図２４及び図２５参照）の実行をＲＰＵ管理プログラム２３２２に対して指示する（ステップＦ１５００）。この際、リソース割当決定プログラム３２２０は、変更対象選択処理による処理結果（例えば、割当対象のＲＰＵのＲＰＵ ＩＤ、割当対象のリソースのリソースＩＤ、そのリソースに対する仮想リソースＩＤ等）をＲＰＵ管理プログラム２３２２に送信する。この設定変更処理により、ＶＤＫＣに対する構成変更が行われる。なお、設定変更処理が終了した後、ＶＤＫＣに対する構成変更の結果が外部管理サーバ３０００を介して管理者に通知される。

図２２は、実施例１に係る変更対象選択処理の第１のフローチャートである。図２３は、実施例１に係る変更対象選択処理の第２のフローチャートである。なお、図２２のフローチャートの記号Ａと、図２３のフローチャートの記号Ａとは、フローチャートが繋がっていることを示している。

変更対象選択処理は、図２１の平準化設定処理のステップＦ１４００の処理に対応する。なお、図２２及び図２３では、ＶＤＫＣに対してＰｏｒｔを追加する変更を行う場合における変更対象選択処理を説明する。

ストレージ管理プログラム３２１０は、ＤＫＣＰＯＯＬ管理者から指定された、Ｐｏｒｔ追加対象のＶＤＫＣと、必要なＰｏｒｔのスペック（例えば、Ｐｏｒｔの通信速度）とを受け付ける（ステップＦ１４０１）。なお、Ｐｏｒｔ追加対象のＶＤＫＣと、必要なＰｏｒｔのスペックとは、ステップＦ１３００の構成変更指示に含まれている。

次いで、リソース割当決定プログラム３２２０は、管理側仮想リソース上限テーブル３２６０を参照し、ストレージ管理プログラム３２１０が受け付けたＰｏｒｔのスペックを満たすために必要なＰｏｒｔ数が、ＶＤＫＣの割当て可能なＰｏｒｔ数の上限値を超えているか否かを判定する（ステップＦ１４０２）。この結果、受け付けたＰｏｒｔのスペックを満たすために必要なＰｏｒｔの数が、ＶＤＫＣの割当て可能なＰｏｒｔ数の上限値を超えている場合（ステップＦ１４０２：ＹＥＳ）には、リソース割当決定プログラム３２２０は、エラーを返して処理を終了する（ステップＦ１４０３）。

一方、受け付けたＰｏｒｔのスペックを満たすために必要なＰｏｒｔ数が、ＶＤＫＣの割当て可能なＰｏｒｔ数の上限値を超えていない場合（ステップＦ１４０２：ＮＯ）には、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに対してリソースを割り当てている各ＰＤＫＣに関して、管理側仮想リソース上限テーブル３２６０を参照して、割当て可能なＰｏｒｔ数の上限値を計算するとともに、管理側リソースＩＤ管理テーブル３２９０を参照し、現在の割当て済みＰｏｒｔ数を計算する（ステップＦ１４０４）。

次いで、リソース割当決定プログラム３２２０は、タスク管理テーブル３２９５を参照し、同一のＰＤＫＣを共有する他のＶＤＫＣに対する処理（タスク）の履歴、未実行タスクをチェックする（ステップＦ１４０５）。具体的には、リソース割当決定プログラム３２２０は、各ＰＤＫＣについて、同一のＰＤＫＣを共有する他のＶＤＫＣに対するタスクにおいて割り当てられたＰｏｒｔ数と、未実行タスクにより割り当てる予定のＰｏｒｔ数とを把握する。

次いで、リソース割当決定プログラム３２２０は、他のタスクにより割り当てられているＰｏｒｔ数及び割り当てられる予定のＰｏｒｔ数についても考慮にいれて、割当可能なＰｏｒｔ数の上限値に達することなく、受け付けたスペックを満足するＰｏｒｔ数を有するＰＤＫＣが存在するか否かを判定する（ステップＦ１４０６）。

この結果、このようなＰＤＫＣが存在しない場合（ステップＦ１４０６：ＮＯ）には、リソース割当決定プログラム３２２０は、エラーを返して処理を終了する（ステップＦ１４０７）。

一方、このようなＰＤＫＣが存在する場合（ステップＦ１４０６：ＹＥＳ）には、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎の、全ＶＤＫＣに割り当てているＰｏｒｔ／全ＶＤＫＣに割り当てているＬＵの比率（Ｒ１）、全ＰＤＫＣについてのＰｏｒｔ／ＬＵの比率（Ｒ１）の平均値（Ａ１）、及びＰＤＫＣ毎の、平均値（Ａ１）とＰｏｒｔ／ＬＵの比率（Ｒ１）との差（Ｄ１）を計算する（ステップＦ１４５１）。ここで、Ｄ１が小さいほど、そのＰＤＫＣにおける、Ｐｏｒｔ／ＬＵの比率（Ｒ１）が大きい、すなわち、Ｐｏｒｔの処理に余裕があることを示している。したがって、Ｄ１に基づいて、Ｐｏｒｔを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣから割当てられるＰｏｒｔにおける負荷を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに割り当てられているＰＤＫＣ毎の対象のＶＤＫＣに割り当てているＰｏｒｔ／対象のＶＤＫＣに割り当てられているＬＵの比率（Ｒ２）、全ＰＤＫＣについてのＰｏｒｔ／ＬＵの比率（Ｒ２）の平均値（Ａ２）、ＰＤＫＣ毎の、平均値（Ａ２）とＰｏｒｔ／ＬＵの比率（Ｒ２）との差（Ｄ２）を計算する（ステップＦ１４５２）。ここで、Ｄ２が小さいほど、対象のＶＤＫＣについて、そのＰＤＫＣにおけるＰｏｒｔ／ＬＵ（Ｒ２）の比率が大きい、すなわち、対象のＶＤＫＣについてみると、そのＰＤＫＣのＰｏｒｔの処理に余裕があることを示している。したがって、Ｄ２に基づいて、Ｐｏｒｔを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣから割当てられるＰｏｒｔにおける、対象のＶＤＫＣについての負荷を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎に、Ｄ１＋Ｄ２を計算する（ステップＦ１４５３）。

次いで、リソース割当決定プログラム３２２０は、Ｄ１＋Ｄ２の値が最小となるＰＤＫＣを、ＶＤＫＣに対してＰｏｒｔを割当対象のＰＤＫＣとして選択し（ステップＦ１４５４）、その選択したＰＤＫＣから割当対象のＰｏｒｔを選択し、そのＰｏｒｔに対して割り当てる仮想リソースＩＤを決定し、処理を終了する。この処理により、Ｄ１＋Ｄ２が最小となるＰＤＫＣ、すなわち、Ｐｏｒｔの処理に余裕があるとともに、対象のＶＤＫＣについてのＰｏｒｔの処理に余裕があるＰＤＫＣを適切に選択することができる。これにより、各ＰＤＫＣ間のＰｏｒｔの負荷を平準化することができるとともに、対象のＶＤＫＣにおける各ＰＤＫＣ間のＰｏｒｔの負荷を平準化することができる。

図２４は、実施例１に係る設定変更処理の第１のフローチャートである。図２５は、実施例１に係る設定変更処理の第２のフローチャートである。なお、図２４のフローチャートの記号Ｂと、図２５のフローチャートの記号Ｂとは、フローチャートが繋がっていることを示している。設定変更処理は、図２１の平準化設定処理のステップＦ１５００の処理に対応する。

ＲＰＵ管理プログラム２３２２は、変更対象選択処理による処理結果から、割当対象のリソースの実リソースＩＤと、割当対象のＲＰＵのＲＰＵ ＩＤとを取得する（ステップＦ１５０１）。ここで、このフローチャートの処理の説明においては、割当対象のリソースの実リソースＩＤを「Ｓ」、割当対象のＲＰＵのＲＰＵ ＩＤを「Ｔ」で示す。

次に、ＲＰＵ管理プログラム２３２２は、リソースＩＤ管理テーブル２３２６において、実リソースＩＤ欄２３２６Ａの値が「Ｓ」であるエントリを検索し、このエントリの仮想リソースＩＤ欄２３２６Ｄに仮想リソースＩＤが登録されているか否かを判定する（ステップＦ１５０２）。

この結果、エントリの仮想リソースＩＤ欄２３２６Ｄに仮想リソースＩＤが登録されている場合（ステップＦ１５０２：ＹＥＳ）には、実リソースＩＤ「Ｓ」のリソースに仮想リソースＩＤが既に付与されていることを示しており、ＲＰＵ管理プログラム２３２２は、内部管理サーバ２６００又はストレージ装置制御プログラム２３２１を介して、管理者に対してエラーメッセージを返し（ステップＦ１５０４）、処理をステップＦ１５０６に進める。

一方、エントリの仮想リソースＩＤ欄２３２６Ｄに仮想リソースＩＤが登録されていない場合（ステップＦ１５０２：ＮＯ）には、実リソースＩＤ「Ｓ」のリソースに仮想リソースＩＤが未付与であることを示しており、ＲＰＵ管理プログラム２３２２は、リソースＩＤ管理テーブル２３２６の実リソースＩＤ欄２３２６Ａの値が「Ｓ」であるエントリにおいて、ＲＰＵ ＩＤ欄２３２６Ｃの値を「Ｔ」に設定し（ステップＦ１５０３）、処理をステップＦ１５０６に進める。

ステップＦ１５０６では、ＲＰＵ管理プログラム２３２２は、変更対象選択処理による処理結果から、仮想リソースＩＤを付与するリソースの実リソースＩＤと、仮想リソースＩＤとを取得する。ここで、以降のステップの説明においては、仮想リソースＩＤを割当対象のリソースの実リソースＩＤを「Ｐ」、割り当てる仮想リソースＩＤを「Ｖ」で示す。

ＲＰＵ管理プログラム２３２２は、リソースＩＤ管理テーブル２３２６を参照し、取得した実リソースＩＤ「Ｐ」のエントリを特定し、このエントリのＲＰＵ ＩＤ欄２３２６Ｃから実リソースが属するＲＰＵのＲＰＵ ＩＤを取得する。ＲＰＵ管理プログラム２３２２は、取得したＲＰＵ ＩＤと、取得した仮想リソースＩＤ「Ｖ」との組が、リソースＩＤ管理テーブル２３２６に登録済みであるか否かを判定する（ステップＦ１５０７）。具体的には、ＲＰＵ管理プログラム２３２２は、ＲＰＵ ＩＤと、仮想リソースＩＤとの組が、いずれかのエントリのＲＰＵ ＩＤ欄２３２６Ｃ、及び仮想リソースＩＤ欄２３２６Ｄの値の組と一致するか否かを判定する。

この結果、ＲＰＵ ＩＤと、仮想リソースＩＤとの組が登録済みである場合（ステップＦ１５０７：ＹＥＳ）には、ＲＰＵ管理プログラム２３２２は、指定された仮想リソースＩＤが既に存在していることを示すエラーメッセージを、内部管理サーバ２６００又はストレージ装置制御プログラム２３２１を介して、要求者に返し（ステップＦ１５０９）、設定変更処理を終了する。これにより、ＶＤＫＣにおいて同一仮想リソースＩＤが重複することを避けることができる。

一方、ＲＰＵ ＩＤと、仮想リソースＩＤとの組が未登録である場合（ステップＦ１５０７：ＮＯ）には、ＲＰＵ管理プログラム２３２２は、リソースＩＤ管理テーブル２３２６の実リソースＩＤ欄２３２６Ａの値が「Ｐ」であるエントリにおいて、仮想リソースＩＤ欄２３２６Ｄに仮想リソースＩＤ「Ｖ」を格納し（ステップＦ１５０８）、設定変更処理を終了する。これにより、割当対象の実リソースを、ＶＤＫＣ内で仮想リソースＩＤによって特定することができるようになる。

次に、実施例２に係る計算機システムについて説明する。

実施例２に係る計算機システムは、ＲＰＵに既に割り当てられているＰｏｏｌからリソースとしてＬＵを割り当てる処理を行う。実施例２に係る計算機システムの構成は、基本的には、実施例１に係る計算機システムの構成と同様である。以下、実施例１に係る計算機システムと違う点を中心に説明する。

次に、実施例２に係る計算機システムの処理動作について説明する。

図２６は、実施例２に係る仮想リソースプール物理リソース対応テーブル作成処理のフローチャートである。

仮想リソースプール物理リソース対応テーブル作成処理は、後述する平準化設定処理の前に実施される。

まず、リソース割当決定プログラム３２２０が設定変更処理（図２４及び図２５と同様な処理）の実行を開始する（ステップＦ２１００）。なお、実施例２に係る設定変更処理においては、ステップＦ１５０１及びＦ１５０６では、割当対象のリソースの実リソースＩＤと、割当対象のＲＰＵのＲＰＵ ＩＤと、仮想リソースＩＤとを、外部管理サーバ３０００から送信されるＤＫＣＰＯＯＬ管理者による構成変更指示から取得する。

次いで、ストレージ管理プログラム３２１０がテーブル作成詳細処理（図２８参照）の実行を開始し（ステップＦ２２００）、テーブル作成詳細処理の終了後に仮想リソースプール物理リソース対応テーブル作成処理を終了する。

図２８は、実施例２に係るテーブル作成詳細処理のフローチャートである。

テーブル作成詳細処理は、図２６のステップＦ２２００の処理に対応する。

ストレージ管理プログラム３２１０は、仮想リソースプール物理リソース対応テーブル３２４０を参照し、追加されたリソースのリソース種別が、リソースを追加されたＶＤＫＣにおいて新規であるか否かを調べ（ステップＦ２２０１）、ＶＤＫＣに追加されたリソースのリソース種別が新規であるか否かを判定する（ステップＳ２２０２）。

この結果、リソース種別が新規である場合（ステップＦ２２０２：ＹＥＳ）には、ストレージ管理プログラム３２１０は、このリソース用の新規の仮想リソースプールを作成し（ステップＦ２２０３）、処理をステップＦ２２０４に進める。具体的には、ストレージ管理プログラム３２１０は、新規の仮想リソースプールの仮想リソースプールＩＤを決定する。一方、リソース種別が新規でない場合（ステップＦ２２０２：ＮＯ）には、ストレージ管理プログラム３２１０は、処理をステップＦ２２０４に進める。

ステップＦ２２０４では、ストレージ管理プログラム３２１０は、追加されたリソースを、そのリソースのリソース種別に対応する仮想リソースプールの要素として、仮想リソースプール物理リソース対応テーブル３２４０に追加する。具体的には、ストレージ管理プログラム３２１０は、仮想リソースプール物理リソース対応テーブル３２４０に、追加されたリソースの実リソースＩＤ、そのリソースが属するＰＤＫＣのＰＤＫＣ ＩＤ、そのリソースのリソース種別、そのリソース種別のリソースが属する仮想リソースプールのリソースプールＩＤ、及びそのリソースが追加されたＲＰＵのＲＰＵ ＩＤを含むエントリを追加する。

次に、実施例２に係る平準化設定処理について説明する。

図２７は、実施例２に係る平準化設定処理のフローチャートである。

外部管理サーバ３０００のストレージ管理プログラム３２１０は、管理者からＶＤＫＣに対する構成変更指示を受け付けると（ステップＦ２３００）、変更対象選択処理（図２９乃至図３１参照）の実行を開始する（ステップＦ２４００）。この変更対象選択処理が実行されると、リソースの変更を行う対象のＰＤＫＣ及びＰｏｏｌが選択される。ここで、構成変更指示には、例えば、ＬＵを作成する構成変更指示であれば、ＬＵを追加する対象のＶＤＫＣを特定する情報や、追加するＬＵの数を特定する情報が含まれている。

次いで、リソース割当決定プログラム３２２０が設定変更処理（図３２参照）の実行を開始する（ステップＦ２５００）。この設定変更処理により、ＶＤＫＣに対する構成変更が行われる。なお、設定変更処理が終了した後、ＶＤＫＣに対する構成変更の結果が管理者に通知される。

図２９は、実施例２に係る変更対象選択処理の第１のフローチャートである。図３０は、実施例２に係る変更対象選択処理の第２のフローチャートである。図３１は、実施例２に係る変更対象選択処理の第３のフローチャートである。なお、図２９のフローチャートの記号Ｃと、図３０のフローチャートの記号Ｃとは、フローチャートが繋がっていることを示している。また、図２９のフローチャートの記号Ｄと、図３１のフローチャートの記号Ｄとは、フローチャートが繋がっていることを示している。

変更対象選択処理は、図２７の平準化設定処理のステップＦ２４００の処理に対応する。なお、図２９乃至図３１では、ＶＤＫＣに対してＬＵを作成する場合における変更対象選択処理を説明する。

ストレージ管理プログラム３２１０は、ＶＤＫＣ管理者からＬＵを作成するＶＤＫＣのＰｏｏｌと、作成するＬＵのサイズ及び数を受け付ける（ステップＦ２４０１）。

次いで、リソース割当決定プログラム３２２０は、ストレージ管理プログラム３２１０が作成指示を受け付けたＬＵの総容量が、指定されたＶＤＫＣで作成可能なボリュームの容量の上限値を超えているか否かを判定する（ステップＦ２４０２）。この結果、ストレージ管理プログラム３２１０が受け付けたＬＵの総容量が、ＶＤＫＣで作成可能なボリュームの容量の上限値を超えている場合（ステップＦ２４０２：ＹＥＳ）には、リソース割当決定プログラム３２２０は、エラーを返して処理を終了する（ステップＦ２４０３）。

一方、ストレージ管理プログラム３２１０が受け付けたＬＵの総容量が、指定されたＶＤＫＣで作成可能なボリュームの容量の上限値を超えていない場合（ステップＦ２４０２：ＮＯ）には、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに対してリソースを割り当てている各ＰＤＫＣに関して、管理側物理リソース上限テーブル３２５０と、管理側物理リソーステーブル３２８０とを参照して、作成可能なＬＵの容量の上限値と、現在の作成済みのＬＵの容量と、空きＰｏｏｌ容量とを計算する（ステップＦ２４０４）。

次いで、リソース割当決定プログラム３２２０は、タスク管理テーブル３２９５を参照し、同一のＰＤＫＣを共有する他のＶＤＫＣに対する処理（タスク）の履歴、未実行タスクをチェックする（ステップＦ２４０５）。具体的には、リソース割当決定プログラム３２２０は、各ＰＤＫＣについて、同一のＰＤＫＣを共有する他のＶＤＫＣに対するタスクにおいて割り当てられたＬＵの数と、未実行タスクにより割り当てる予定のＬＵの数とを把握する。

次いで、リソース割当決定プログラム３２２０は、他のタスクにより割り当てられているＬＵの数及び割り当てられる予定のＬＵの数についても考慮にいれて、作成可能なＬＵの総容量の上限値に達していないＰＤＫＣが存在するか否かを判定する（ステップＦ２４０６）。

この結果、このようなＰＤＫＣが存在しない場合（ステップＦ２４０６：ＮＯ）には、リソース割当決定プログラム３２２０は、処理を図３１のステップＳ２４６１に進める。

一方、このようなＰＤＫＣが存在する場合（ステップＦ２４０６：ＹＥＳ）には、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎の全ＶＤＫＣに割り当てているＬＵの容量（Ｒ１）、全ＰＤＫＣについてのＬＵの容量（Ｒ１）の平均値（Ａ１）、ＰＤＫＣ毎の、平均値（Ａ１）とＬＵの容量（Ｒ１）との差（Ｄ１）を計算する（ステップＦ２４５１）。ここで、Ｄ１が大きいほど、そのＰＤＫＣにおいて割り当てられているＬＵの容量が小さいことを示している。したがって、Ｄ１に基づいて、ＬＵを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣ間で割り当てるＬＵの容量を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに割り当てられているＰＤＫＣ毎のＶＤＫＣに割り当てているＬＵの容量（Ｒ２）、全ＰＤＫＣについての、対象のＶＤＫＣのＬＵの容量（Ｒ２）の平均値（Ａ２）、ＰＤＫＣ毎の、平均値（Ａ２）とＬＵの容量（Ｒ２）との差（Ｄ２）を計算する（ステップＦ２４５２）。ここで、Ｄ２が大きいほど、そのＰＤＫＣにおける、対象のＶＤＫＣについてのＬＵの容量が小さいことを示している。したがって、Ｄ２に基づいて、ＬＵを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣ間で、対象のＶＤＫＣについてのＬＵの容量を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎に、Ｄ１＋Ｄ２を計算する（ステップＦ２４５３）。

次いで、リソース割当決定プログラム３２２０は、Ｄ１＋Ｄ２の値が最小となるＰＤＫＣを、ＬＵを作成する対象のＰＤＫＣとして選択し、そのＰＤＫＣの中のＰｏｏｌの１つを、ＬＵを作成する対象のＰｏｏｌとして選択し（ステップＦ２４５４）、処理を終了する。

一方、ステップＦ２４６１では、リソース割当決定プログラム３２２０は、作成予定のＬＵの個数（Ｎ個）を複数（Ｍ個：Ｍは、Ｎ以下の数）のグループに分割する（ステップＦ２４６１）。次いで、リソース割当決定プログラム３２２０は、グループの１つを処理対象として、ステップＦ２４５１〜Ｆ２４５５の処理を実行する（ステップＦ２４６２）。

次いで、リソース割当決定プログラム３２２０は、ステップＦ２４６１で分割した全てのグループに対してステップＦ２４６２の処理を実行したか否かを判定し（ステップＦ２４６３）、全てのグループに対して処理を実行していない場合（ステップＦ２４６３：ＮＯ）には、処理をステップＦ２４６２に進めて、未処理のグループに対する処理を実行する一方、全てのグループに対して処理を実行した場合（ステップＦ２４６３：ＹＥＳ）には、変更対象選択処理を終了する。ステップＦ２４６１〜Ｆ２４６３の処理によると、ＬＵのグループ毎に、ＬＵを作成する対象のＰＤＫＣ及びＰｏｏｌが選択される。上記処理によると、作成するＬＵを割り当てるＰＤＫＣ及びＰｏｏｌを適切に選択することができる。

図３２は、実施例２に係る設定変更処理のフローチャートである。

設定変更処理は、図２７の平準化設定処理のステップＦ２５００の処理に対応する。

ストレージ管理プログラム３２１０は、変更対象選択処理で選択したＰＤＫＣのＰｏｏｌと、作成するＬＵの数から設定処理を確定し、タスク管理テーブル３２９５へ設定処理に対応するタスクを登録する（ステップＦ２５０１）。次いで、ストレージ管理プログラム３２１０は、タスクの内容を、ＬＵを作成する対象の各ＰＤＫＣに通知し、タスクに対応する設定処理を実行させる（ステップＦ２５０２）。これにより、各ＰＤＫＣにおいて、選択されたＰｏｏｌに、指定された数のＬＵが作成されることとなる。

次に、実施例３に係る計算機システムについて説明する。

実施例３に係る計算機システムは、計算機システムにおけるストレージ装置のスケールアウト時においてリソースの割り当ての処理を行う。実施例３に係る計算機システムの構成は、基本的には、実施例１に係る計算機システムの構成と同様である。以下、実施例１に係る計算機システムと違う点を中心に説明する。

次に、実施例３に係る計算機システムの処理動作について説明する。

図３３は、実施例３に係るＶＤＫＣ下限値設定処理のフローチャートである。

ＶＤＫＣ下限値設定処理は、ユーザが決定したＳＬＡ（Service Level
Agreement）保証の範囲である目標性能に基づいて、ＶＤＫＣにおける仮想リソースに関する下限値を作成し、設定する処理である。

外部管理サーバ３０００の上限値計算プログラム３２３０は、ユーザからＶＯＬ毎もしくはストレージ装置単位での目標性能値を受け付ける（ステップＦ３００１）。次いで、ストレージ管理プログラム３２１０は、性能下限テーブル３２６５に受け付けた目標性能値を設定し（ステップＦ３００２）、処理を終了する。

図３４は、実施例３に係る平準化設定処理のフローチャートである。

平準化設定処理は、ストレージ装置が計算機システムに新規に追加された後に実行される。

ストレージ管理プログラム３２１０は、ＲＰＵ作成処理（図３５参照）を実行する（ステップＦ３３００）。このＲＰＵ作成処理によると、新規に追加されたストレージ装置２０００にＲＰＵが作成される。

次いで、ストレージ管理プログラム３２１０は、ＲＰＵに割り当てるリソースを決定するリソース決定割当処理を実行する（ステップＦ３４００）。リソース決定割当処理としては、追加したリソースのみを処理対象とするリソース決定割当処理（図３６参照）と、既存のリソースについても処理対象とするリソース決定割当処理（図３７及び図３８参照）とがある。

図３５は、実施例３に係るＲＰＵ作成処理のフローチャートである。

ＲＰＵ作成処理は、図３４の平準化設定処理のステップＦ３３００の処理に対応する。

ストレージ管理プログラム３２１０は、全ストレージ装置２０００のＲＰＵ管理プログラム２３２２と通信して、ＲＰＵ管理テーブル２３２５に設定されている既存の仮想ストレージ装置のＲＰＵ ＩＤ、ベンダ、モデル、及びＳ／Ｎを取得する（ステップＦ３３０１）。

次いで、ストレージ管理プログラム３２１０は、新規に追加したストレージ装置２０００のＲＰＵ管理プログラム２３２２と通信し、ステップＳ３３０１で取得したＲＰＵ ＩＤ、ベンダ、モデル、及びＳ／Ｎを、ＲＰＵ管理テーブル２３２５に登録させる（ステップＦ３３０２）。

ＲＰＵ管理プログラム２３２２は、ＲＰＵ管理テーブル２３２５の登録したＲＰＵに対応するエントリの状態欄２３２５Ｆをアクティブに設定する（ステップＦ３３０３）。この後、ストレージ管理プログラム３２１０は、ＲＰＵ作成処理を終了する。

図３６は、実施例３に係るリソース決定割当処理の第１の例のフローチャートである。

このリソース決定割当処理は、図３４の平準化設定処理のステップＦ３４００の処理に対応し、追加したストレージ装置のリソースのみを処理対象とする処理である。

ストレージ管理プログラム３２１０は、新たに追加されたストレージ装置２０００に具備されているＰｏｒｔの情報を取得する（ステップＦ３４０１）。次いで、ストレージ管理プログラム３２１０は、性能下限テーブル３２６５を参照して各ＶＤＫＣの平均性能要件（Ａ）を計算し、性能履歴テーブル３２９７を参照してＶＤＫＣの現在の平均性能値（Ｃ）を計算し、平均性能要件（Ａ）と、平均性能値（Ｃ）との差分（Ａ−Ｃ）を計算し、差分（Ａ−Ｃ）が小さい順にＶＤＫＣに対して点数Ｓ１（０、１、２・・・の順）を設定する（ステップＦ３４０２）。ここで、差分（Ａ−Ｃ）が負であれば、ＶＤＫＣに対する性能要件を超えており、性能に余裕がないことを示しており、差分（Ａ−Ｃ）が正であれば、ＶＤＫＣに対する性能要件を超えておらず、性能に余裕があることを示している。このため、差分（Ａ−Ｃ）の小さい順に点数Ｓ１を設定することにより、差分（Ａ−Ｃ）が小さい、すなわち、性能に余裕がないＶＤＫＣに対して少ない点数が設定されることとなる。

次いで、ストレージ管理プログラム３２１０は、性能履歴テーブル３２９７を参照して、単位期間（例えば、１日等）の性能増加の傾きが大きい順にＶＤＫＣに対して点数Ｓ２（０、１、２・・・の順）を設定する（ステップＦ３４０３）。ここで、性能増加の傾きが大きいＶＤＫＣは、今後必要となる性能が増加する可能性が高いことを示している。このため、性能増加の傾きが大きい順にＶＤＫＣに対して点数Ｓ２を設定することにより、今後性能に余裕がなくなる可能性の高いＶＤＫＣに対して少ない点数が設定されることとなる。

次いで、ストレージ管理プログラム３２１０は、各ＶＤＫＣ毎にＳ１＋Ｓ２を計算し、Ｓ１＋Ｓ２の値が小さい順にＶＤＫＣをランク付けする（ステップＦ３４０４）。ここで、Ｓ１＋Ｓ２の値が小さいほど、性能に余裕がない、且つ性能に余裕がなくなる可能性が高いＶＤＫＣであることを意味しており、このようなＶＤＫＣから順にランク付けされることとなる。

次いで、ストレージ管理プログラム３２１０は、追加されたＰＤＫＣのＰｏｒｔについて、Ｐｏｒｔのハードウエアのスペックがよい順に、ステップＦ３４０４のランク付けに基づいて、割り当てるＶＤＫＣを決定する（ステップＦ３４０５）。ここで、割り当て先の決定方法としては、Ｐｏｒｔを１つずつ、ランクに従った順番で各ＶＤＫＣに振り分けるように決定しても良いし、Ｓ１＋Ｓ２の比率に基づいて、各ＶＤＫＣにＰｏｒｔを振り分けるように決定しても良い。なお、ＶＤＫＣに割り当てられたＰｏｒｔ数が、このＶＤＫＣに割り当て可能なＰｏｒｔの上限値に達した場合には、このＶＤＫＣには、これ以上のＰｏｒｔが割り当てられないようにしている。

次いで、ストレージ管理プログラム３２１０は、図２１のステップＦ１５００の処理と同様な処理をＲＰＵ管理プログラム２３２２に実行させることにより、各ＶＤＫＣに対してＰｏｒｔを割り当て（ステップＦ３４０６）、処理を終了する。この処理によると、追加したストレージ装置のリソースを適切に割り当てることができる。

図３７は、実施例３に係るリソース決定割当処理の第２の例の第１のフローチャートである。図３８は、実施例３に係るリソース決定割当処理の第２の例の第２のフローチャートである。なお、図３７のフローチャートの記号Ｅと、図３８のフローチャートの記号Ｅとは、フローチャートが繋がっていることを示している。

このリソース決定割当処理は、図３４の平準化設定処理のステップＦ３４００の処理に対応し、全ストレージ装置２０００のリソースを処理対象とする処理である。

ストレージ管理プログラム３２１０は、全ストレージ装置２０００に具備されているＰｏｒｔの情報を取得する（ステップＦ３４０７）。次いで、ストレージ管理プログラム３２１０は、性能下限テーブル３２６５を参照して各ＶＤＫＣの平均性能要件（Ａ）を算出し、性能履歴テーブル３２９７を参照して各ＶＤＫＣの現在の平均性能値（Ｃ）を計算し、各ＶＤＫＣの平均性能要件（Ａ）と、平均性能値（Ｃ）との差分（Ａ−Ｃ）を計算し、差分（Ａ−Ｃ）が小さい順にＶＤＫＣに対して点数Ｓ１（０、１、２・・・の順）を設定する（ステップＦ３４０８）。

次いで、ストレージ管理プログラム３２１０は、性能履歴テーブル３２９７を参照して、単位期間の性能増加の傾きが大きい順にＶＤＫＣに対して点数Ｓ２（０、１、２・・・の順）を設定する（ステップＦ３４０９）。

次いで、ストレージ管理プログラム３２１０は、ＶＤＫＣ毎にＳ１＋Ｓ２を計算し、Ｓ１＋Ｓ２の値が小さい順にＶＤＫＣをランク付けする（ステップＦ３４１０）。

次いで、ストレージ管理プログラム３２１０は、全ＰＤＫＣのＰｏｒｔについて、Ｐｏｒｔのハードウエアのスペックがよい順に、ステップＦ３４１０のランク付けに基づいて、割り当てるＶＤＫＣを決定する（ステップＦ３４１１）。ここで、割り当て先の決定方法としては、Ｐｏｒｔを１つずつ、ランクに従った順番で各ＶＤＫＣに振り分けるように決定しても良いし、Ｓ１＋Ｓ２の比率に基づいて、各ＶＤＫＣにＰｏｒｔを振り分けるように決定しても良い。なお、ＶＤＫＣに割り当てられたＰｏｒｔ数が、このＶＤＫＣに割り当て可能なＰｏｒｔの上限値に達した場合には、このＶＤＫＣには、これ以上のＰｏｒｔが割り当てられないようにしている。

次いで、ストレージ管理プログラム３２１０は、ＶＤＫＣを跨ったリソース（ここでは、Ｐｏｒｔ）の移動があるか否かを判定する（ステップＦ３４１３）。

この結果、ＶＤＫＣを跨ったリソースの移動がない場合（ステップＦ３４１３：ＮＯ）には、ストレージ管理プログラム３２１０は、ＲＰＵ管理プログラム２３２２によりステップＦ１５００と同様な処理を実行させて、追加するＰｏｒｔをＶＤＫＣに割り当て（ステップＦ３４２１）、処理を終了する。

一方、ＶＤＫＣを跨ったリソースの移動がある場合（ステップＦ３４１３：ＹＥＳ）には、ストレージ管理プログラム３２１０は、更に、ＶＤＫＣへ割り当て予定の未割当てリソースがあるか否かを判定する（ステップＳ３４１４）。この結果、ＶＤＫＣへ割り当て予定の未割当てリソースがない場合（ステップＳ３４１４：ＮＯ）には、ストレージ管理プログラム３２１０は、エラーを返して処理を終了する（ステップＦ３４１５）。

一方、ＶＤＫＣへ割り当て予定の未割当てリソースがある場合（ステップＳ３４１４：ＹＥＳ）には、ストレージ管理プログラム３２１０は、ＲＰＵ管理プログラム２３２２によりステップＦ１５００と同様な処理を実行させて、ＶＤＫＣを変更する予定のＰｏｒｔが割り当てられるＶＤＫＣに対して割り当て予定の未割当てのポートを割り当てる（ステップＦ３４１６）。

次いで、ストレージ管理プログラム３２１０は、構成管理テーブル３２９８を参照して、新たに割り当てたＰｏｒｔに対して、変更予定のＰｏｒｔに割り当てられている仮想ポート番号を割り当てる（ステップＦ３４１７）。

次いで、ストレージ管理プログラム３２１０は、変更予定のＰｏｒｔに設定されているパスを、新たに割り当てたＰｏｒｔのパスに切り替えて、新たに割り当てたＰｏｒｔをメインパスとする（ステップＦ３４１８）。このように、新たに割り当てられたＰｏｒｔに対して、変更予定のＰｏｒｔの仮想ポート番号が設定されるので、ホスト１０００からＶＯＬに対してアクセスするためのＳＣＳＩ Ｉｎｑｕｉｒｙ ＩＤ（仮想装置ＩＤ、仮想ポート番号、及び仮想ＶＯＬ番号を含む）が送信された場合であっても、支障なく処理することができる。このため、変更予定のＰｏｒｔについて、ストレージ装置２０００を停止することなく、他のＶＤＫＣに割り当てることができるようになる。

次いで、ストレージ管理プログラム３２１０は、変更予定のＰｏｒｔを変更先のＶＤＫＣに対して割り当てる（ステップＦ３４１９）。具体的には、例えば、ストレージ管理プログラム３２１０は、リソースＩＤ管理テーブル２３２６から、変更予定のPortの仮想リソースＩＤを削除（例えば、変更予定のPortの仮想リソースＩＤを“null”に更新）し、その後、ステップＦ１５００と同様に、変更先ＶＤＫＣに変更予定のPortの情報を設定することをＲＰＵ管理プログラム２３２２に対して指示する。

次いで、ストレージ管理プログラム３２１０は、全てのＶＤＫＣに対して変更対象のＰｏｒｔの変更設定が完了したか否かを判定し（ステップＦ３４２０）、全てのＶＤＫＣに対して変更対象のＰｏｒｔの変更設定が完了していない場合（ステップＦ３４２０：ＮＯ）には、処理をステップＦ３４１７に進める。一方、全てのＶＤＫＣに対して変更対象のＰｏｒｔの変更設定が完了している場合（ステップＦ３４２０：ＹＥＳ）には、ストレージ管理プログラム３２１０は、処理を終了する。これにより、追加したストレージ装置のリソースだけでなく、全ストレージ装置２０００のリソースを対象に、リソースの割当ての変更を行うことができる。

次に、実施例４に係る計算機システムについて説明する。

実施例４に係る計算機システムは、ＲＰＵに既に割り当てられているＰｏｏｌからリソースとしてＳＳ（スナップショット）のＶＯＬを割り当てる処理を行う。ＳＳのＶＯＬは、同一のストレージ装置２０００に集約しておくことが好ましいので、実施例４に係る計算機システムは、ＳＳのＶＯＬをできるだけ同一のストレージ装置２０００に集約されるように割り当てる。実施例４に係る計算機システムの構成は、基本的には、実施例２に係る計算機システムの構成と同様である。以下、実施例２に係る計算機システムと違う点を中心に説明する。

実施例４に係る計算機システムによるリソースを集約するように設定するリソース集約設定処理は、実施例２に係る図２７に示す平準化設定処理において、変更対象選択処理（ステップＦ２４００）に代えて、図３９乃至図４１に示すリソース集約時の変更対象選択処理を実行し、構成変更処理（ステップＦ２５００）に代えて、図４２に示す設定変更処理を実行するようにしたものである。

図３９は、実施例４に係るリソース集約時の変更対象選択処理の第１のフローチャートである。図４０は、実施例４に係るリソース集約時の変更対象選択処理の第２のフローチャートである。図４１は、実施例４に係るリソース集約時の変更対象選択処理の第３のフローチャートである。なお、図３９のフローチャートの記号Ｆと、図４０のフローチャートの記号Ｆとは、フローチャートが繋がっていることを示している。また、図３９のフローチャートの記号Ｇと、図４１のフローチャートの記号Ｇとは、フローチャートが繋がっていることを示している。

ストレージ管理プログラム３２１０は、ＶＤＫＣ管理者からＳＳのＶＯＬを作成するＶＤＫＣのＲ−Ｐｏｏｌと、ＳＳの基になるプライマリーボリューム（Ｐ−ＶＯＬ）と、作成するＳＳの数との指定を受け付ける（ステップＦ４００１）。

次いで、リソース割当決定プログラム３２２０は、ストレージ管理プログラム３２１０が作成指示を受け付けたＳＳ数に対応するボリューム数が、指定されたＶＤＫＣで作成可能なボリューム数の上限値を超えているか否かを判定する（ステップＦ４００２）。この結果、ストレージ管理プログラム３２１０が受け付けたボリューム数が、ＶＤＫＣで作成可能なボリューム数の上限値を超えている場合（ステップＦ４００２：ＹＥＳ）には、リソース割当決定プログラム３２２０は、エラーを返して処理を終了する（ステップＦ４００３）。

一方、ストレージ管理プログラム３２１０が受け付けたＶＯＬ数が、指定されたＶＤＫＣで作成可能なボリューム数の上限値を超えていない場合（ステップＦ４００２：ＮＯ）には、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに対してリソースを割り当てている各ＰＤＫＣに関して、管理側仮想リソース上限テーブル３２５０と、管理側物理リソーステーブル３２８０とを参照して、作成可能なＶＯＬ数の上限値と、現在の作成済みのＶＯＬ数とを計算する（ステップＦ４００４）。

次いで、リソース割当決定プログラム３２２０は、タスク管理テーブル３２９５を参照し、同一のＰＤＫＣを共有する他のＶＤＫＣに対する処理（タスク）の履歴、未実行タスクをチェックする（ステップＦ４００５）。具体的には、リソース割当決定プログラム３２２０は、各ＰＤＫＣについて、同一のＰＤＫＣを共有する他のＶＤＫＣに対するタスクにおいて割り当てられたＶＯＬ数と、未実行タスクにより割り当てる予定のＶＯＬ数とを把握する。

次いで、リソース割当決定プログラム３２２０は、他のタスクにより割り当てられているＶＯＬ数及び割り当てられる予定のＶＯＬ数についても考慮にいれて、作成可能なＶＯＬ数の上限値に達していないＰＤＫＣが存在するか否かを判定する（ステップＦ４００６）。

この結果、このようなＰＤＫＣが存在しない場合（ステップＦ４００６：ＮＯ）には、リソース割当決定プログラム３２２０は、処理を図４１のステップＳ４０６１に進める。

一方、このようなＰＤＫＣが存在する場合（ステップＦ４００６：ＹＥＳ）には、リソース割当決定プログラム３２２０は、指定されたＰ−ＶＯＬを保持するＰＤＫＣが存在するか否かを判定する（ステップＦ４０５１）。

この結果、Ｐ−ＶＯＬを保持するＰＤＫＣが存在する場合（ステップＦ４０５１：ＹＥＳ）には、リソース割当決定プログラム３２２０は、このＰＤＫＣにおける、このＰＤＫＣ内部のＰｏｏｌを変更対象として選択し（ステップＦ４０５２）、処理を終了する。

一方、Ｐ−ＶＯＬを保持するＰＤＫＣが存在しない場合（ステップＦ４０５１：ＮＯ）には、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎の全ＶＤＫＣに割り当てているＶＯＬ数（Ｒ１）、全ＰＤＫＣについてのＶＯＬ数（Ｒ１）の平均値（Ａ１）、ＰＤＫＣ毎の、平均値（Ａ１）とＶＯＬ数（Ｒ１）との差（Ｄ１）を計算する（ステップＦ４０５３）。ここで、Ｄ１が大きいほど、そのＰＤＫＣにおいて割り当てられているＶＯＬ数が少ないことを示している。したがって、Ｄ１に基づいて、ＶＯＬを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣ間で割り当てるＶＯＬ数を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、対象のＶＤＫＣに割り当てられているＰＤＫＣ毎の対象のＶＤＫＣに割り当てているＶＯＬ数（Ｒ２）、全ＰＤＫＣについての、対象のＶＤＫＣのＶＯＬ数（Ｒ２）の平均値（Ａ２）、ＰＤＫＣ毎の、平均値（Ａ２）とＶＯＬ数（Ｒ２）との差（Ｄ２）を計算する（ステップＦ４０５４）。ここで、Ｄ２が大きいほど、そのＰＤＫＣにおける、対象のＶＤＫＣについてのＶＯＬ数が少ないことを示している。したがって、Ｄ２に基づいて、ＶＯＬを割り当てるＰＤＫＣを選択するようにすると、各ＰＤＫＣ間で、対象のＶＤＫＣについてのＶＯＬ数を平準化することができる。

次いで、リソース割当決定プログラム３２２０は、ＰＤＫＣ毎に、Ｄ１＋Ｄ２を計算する（ステップＦ４０５５）。

次いで、リソース割当決定プログラム３２２０は、Ｄ１＋Ｄ２の値が最大となるＰＤＫＣを、ＶＯＬを作成する対象のＰＤＫＣとして選択し、そのＰＤＫＣの中のＰｏｏｌの１つを、ＶＯＬを作成する対象のＰｏｏｌとして選択し（ステップＦ４０５６）、処理を終了する。これにより、全てのＳＳのＶＯＬを集約して格納することのできる１つのＰＤＫＣのＰｏｏｌを決定することができる。

一方、ステップＦ４０６１では、リソース割当決定プログラム３２２０は、作成予定のＳＳの個数（Ｎ個）を複数（Ｍ個：Ｍは、初期値が２である）のグループに分割する（ステップＦ４０６１）。次いで、リソース割当決定プログラム３２２０は、各グループを処理対象として、ステップＦ４０５１〜Ｆ４０５６の処理を実行する（ステップＦ４０６２）。

次いで、リソース割当決定プログラム３２２０は、ステップＦ４０６２の処理により、ステップＦ４０６１で分割した全てのグループに対してＶＯＬを作成するＰＤＫＣと、Ｐｏｏｌとが決定したか否かを判定し（ステップＦ４０６３）、全てのグループに対して決定できなかった場合（ステップＦ４０６３：ＮＯ）には、Ｍに１を加算させ（ステップＦ４０６４）、処理をステップＦ４０６１に進める。一方、全てのグループに対して決定できた場合（ステップＦ４０６３：ＹＥＳ）には、リソース割当決定プログラム３２２０は、処理を終了する。

このステップＦ４０６１〜Ｆ４０６４の処理によると、できるだけ少ない数のＰＤＫＣにＳＳに対応するＶＯＬを集約することができるようなＰＤＫＣ及びＰｏｏｌの組が選択される。

図４２は、実施例４に係る設定変更処理のフローチャートである。

ストレージ管理プログラム３２１０は、リソース集約時の変更対象選択処理で選択された変更対象のＰＤＫＣが、指定されたＰ−ＶＯＬが存在するＰＤＫＣであるか否かを判定する（ステップＦ４０７１）。

この結果、変更対象のＰＤＫＣが、指定されたＰ−ＶＯＬが存在するＰＤＫＣである場合（ステップＦ４０７１：ＹＥＳ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量があるか否かを判定する（ステップＦ４０７２）。

この結果、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量がない場合（ステップＦ４０７２：ＮＯ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣに対して新たにＰｏｏｌを作成して、ＶＯＬを作成するＰｏｏｌとして選択し、ＶＤＫＣに割り当て（ステップＦ４０７３）、処理をステップＦ４０７５に進める。一方、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量がある場合（ステップＦ４０７２：ＹＥＳ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣ内の最も空き容量の多いＰｏｏｌを、ＶＯＬを作成するＰｏｏｌとして選択し（ステップＦ４０７４）、処理をステップＦ４０７５に進める。

一方、変更対象のＰＤＫＣが、指定されたＰ−ＶＯＬが存在するＰＤＫＣでない場合（ステップＦ４０７１：ＮＯ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量があるか否かを判定する（ステップＦ４０７６）。

この結果、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量がない場合（ステップＦ４０７６：ＮＯ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣに対して新たにＰｏｏｌを作成して、ＶＯＬを作成するＰｏｏｌとして選択し、ＶＤＫＣに割り当て（ステップＦ４０７７）、処理をステップＦ４０７９に進める。一方、このＰＤＫＣのＰｏｏｌにＳＳのＶＯＬを作成可能な空き容量がある場合（ステップＦ４０７６：ＹＥＳ）には、ストレージ管理プログラム３２１０は、このＰＤＫＣ内の最も空き容量の多いＰｏｏｌを、ＶＯＬを作成するＰｏｏｌとして選択し（ステップＦ４０７８）、処理をステップＦ４０７９に進める。

ステップＦ４０７９では、ストレージ管理プログラム３２１０は、(a)Ｐ−ＶＯＬをこのＰＤＫＣに移行し、移行したＰ−ＶＯＬを選択したＰｏｏｌと関連付ける、(b)Ｐ−ＶＯＬをこのＰＤＫＣに外部接続でつなげ、選択したPoolと関連づける、(c)Ｐ−ＶＯＬをこのＰＤＫＣにコピーして選択したＰｏｏｌと関連付ける、のいずれかの処理を実行する。(a)(b)及び(c)のいずれかの処理を実行することで、変更対象のＰＤＫＣでＳＳのＶ−ＶＯＬを作成することが可能となる。その後、ストレージ管理プログラム３２１０は、処理をステップＦ４０７５に進める。

ステップＦ４０７５では、ストレージ管理プログラム３２１０は、ＳＳの仮想ＶＯＬ（Ｖ−ＶＯＬ）を生成する。

次いで、ストレージ管理プログラム３２１０は、選択されたＰＤＫＣのＰｏｏｌと、作成すべきＳＳの数とから設定処理（ＳＳ作成）を確定し、タスク管理テーブル３２９５へ設定処理に対応するタスクを登録する（ステップＦ４０８０）。次いで、ストレージ管理プログラム３２１０は、タスクの内容を、ＶＯＬを作成する対象のＰＤＫＣに通知し、タスクに対応する設定処理を実行させる（ステップＦ４０８１）。次いで、ストレージ管理プログラム３２１０は、作成したＳＳの仮想ＶＯＬをＶＤＫＣに割り当て（ステップＦ４０８２）、処理を終了する。これにより、ＰＤＫＣにおいて、選択されたＰｏｏｌに、指定された数のＳＳのＶ−ＶＯＬが作成されることとなる。

次に、実施例５に係る計算機システムについて説明する。

実施例５に係る計算機システムは、計算機システムにおいて、新たなライセンスが追加され、新たなＶＤＫＣを追加する際におけるリソースの割り当ての処理を行う。実施例５に係る計算機システムの構成は、基本的には、実施例１に係る計算機システムの構成と同様である。以下、実施例１に係る計算機システムと違う点を中心に説明する。

図４３は、実施例５に係るＶＤＫＣの上限値設定処理のフローチャートである。

ストレージ管理プログラム３２１０は、ＶＤＫＣ管理者またはＤＫＣＰＯＯＬ管理者から、新たに追加するＶＤＫＣのＲＰＵ ＩＤ、ベンダ、モデル、シリアル番号、及びライセンス情報の指定を受け付ける（ステップＦ５００１）。

次いで、ストレージ管理プログラム３２１０は、指定された、ＲＰＵ ＩＤ、ベンダ、モデル、及びシリアル番号を、全ストレージ装置２０００のＲＰＵ管理プログラム２３２２へ送信し、これら情報に基づいて、ＲＰＵ管理テーブル２３２５を更新させる（ステップＦ５００２）。次いで、上限値計算プログラム３３２０が、指定されたライセンス情報をライセンス管理テーブル３２７０に設定する（ステップＦ５００３）。

次いで、上限値計算プログラム３２３０は、各ＶＤＫＣのライセンス料の比率に基づいて、各ＰＤＫＣにおける各ＶＤＫＣの各リソースに対する上限値を計算する（ステップＦ５００４）。

次いで、上限値計算プログラム３２３０は、計算した上限値が既存のリソース数（又は容量、性能）を下回るか否かを判定する（ステップＦ５００５）。この結果、計算した上限値が既存のリソース数を下回る場合（ステップＦ５００５：ＹＥＳ）には、上限値計算プログラム３２３０は、既存のリソース数（又は、容量、性能）と計算した上限値との差分値を保存し（ステップＦ５００６）、処理をステップＦ５００７に進める。一方、計算した上限値が既存のリソース数を下回らない場合（ステップＦ５００５：ＮＯ）には、上限値計算プログラム３２３０は、処理をステップＦ５００７に進める。

ステップＦ５００７では、上限値計算プログラム３２３０は、全てのＶＤＫＣのリソースに対する上限値を計算したか否かを判定する。この結果、全てのＶＤＫＣのリソースに対する上限値を計算していない場合（ステップＦ５００７：ＮＯ）には、上限値計算プログラム３２３０は、処理をステップＦ５００４に進めて、未処理のＶＤＫＣを処理対象に処理を実行する一方、全てのＶＤＫＣのリソースに対する上限値を計算した場合（ステップＦ５００７：ＹＥＳ）には、処理をステップＦ５００８に進める。

ステップＦ５００８では、上限値計算プログラム３２３０は、差分値の合計（差分合計値）が０であるか否かを判定する。この結果、差分合計値が０でない場合（ステップＦ５００８：ＮＯ）には、上限値計算プログラム３２３０は、差分のなかったＶＤＫＣ（新しく分配予定の上限を既存割当リソース数（量）が下回っていないＶＤＫＣ）に関して、リソース上限値から差分合計値を除いた後、再分配を行う計算（ステップＦ５００４からの処理）を実行する（ステップＦ５０１０）。具体的には、例えば、上限値計算プログラム３２３０は、各種リソース上限値について、リソース上限値（仮想リソース上限値）の合計値（Ａ）から、差分のあった１個以上のＶＤＫＣに割当済みリソース数合計（Ｂ）を減算し、減算後の値（Ａ−Ｂ）に関して、差分のなかったＶＤＫＣと追加するＶＤＫＣのライセンス比率に応じて再分配計算を実施する。減算後の値（Ａ−Ｂ）が、分配可能なリソース上限数である。また、ＶＤＫＣが残り１個になるまで差分がなくならない場合は、エラーが出されても良い。つまり、新しい基準で上限が割り当てられるケースにおいて、既に割当済リソースがその上限を超えている場合は、そのＶＤＫＣの上限値は変更されず、残りのＶＤＫＣの中で、上限を超えているＶＤＫＣのリソースを除いた値で、再分配が実施される。

一方、差分合計値が０である場合（ステップＦ５００８：ＹＥＳ）には、ストレージ管理プログラム３２１０が、ストレージ制御プログラム２３２１と通信して、仮想リソース上限テーブル２３３１を更新し（ステップＦ５００９）、処理を終了する。

以上説明したように、実施例５に係る計算機システムによると、新たなライセンスが追加され、新たなＶＤＫＣを追加する際において、適切にリソースの割り当てを行うことができる。

以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、実施例１乃至実施例５の少なくともいずれか２つの実施例に係る計算機システムを組み合わせた計算機システムを構成するようにしても良い。また、例えば、実リソース及び実ストレージ装置はそれぞれ物理リソース及び物理ストレージ装置と呼ばれてもよい。

１０００：ホスト計算機、２０００：ストレージ装置、３０００：外部管理サーバ。

Claims (15)

1. 複数の実リソースを有する１以上の実ストレージ装置で構成されたストレージシステムと、
   前記ストレージシステムに接続された管理システムと
   を有し、
   前記管理システムは、各実ストレージ装置の実リソースに関する上限値を含む第１情報と、テナントが使用可能なリソースであるテナント用リソース又はそのテナント用リソースの基になるリソースとして割り当てられる実リソースに関する上限値である第２情報とに基づいて、前記１以上の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとして前記テナントに割り当てる
   計算機システム。
2. 前記１以上の実ストレージ装置は、複数の実ストレージ装置であり、
   前記管理システムは、前記複数の実ストレージ装置から前記テナントに実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとして割り当てる
   請求項１に記載の計算機システム。
3. 前記テナントに割り当てられている１以上のテナント用リソース又はそれらの基になっている複数の実リソースは、前記複数のストレージ装置に分散されている
   請求項２に記載の計算機システム。
4. テナント用リソースは、仮想リソースであり、
   前記第２情報は、前記テナント用リソースの基になる実リソースに関する上限値である
   請求項３に記載の計算機システム。
5. 前記実リソースに関する上限値は、前記実リソースの数についての上限値である
   請求項４に記載の計算機システム。
6. テナント用リソースとして、複数の実ストレージ装置に基づく仮想ストレージ装置に割り当てられる仮想ポートがあり、
   前記複数の実ストレージ装置が、複数の仮想ポートに基づく複数の実ポートを有し、
   前記管理システムは、前記テナントが利用可能な仮想ポートを追加する際に、前記第１情報と前記第２情報とに基づいて、前記テナントが利用可能な仮想ポートの基になる実ポートを前記テナントに割り当てる、
   請求項５に記載の計算機システム。
7. 少なくとも１つの実ストレージ装置が、論理的な記憶デバイスである実論理ユニットを提供し、
   前記仮想ストレージ装置は、その仮想ストレージ装置の基になっている１以上の実ストレージ装置が有する実論理ユニットが割り当てられた仮想論理ユニットを有し、
   前記管理システムは、仮想ポートの基になっている実ポートの数と、実ポートが担当し仮想ストレージ装置に割り当てられている実論理ユニットの数との比率に基づいて、仮想ポートを前記テナントに割り当てる
   請求項６に記載の計算機システム。
8. 前記テナント用リソースとして、仮想論理ユニットがあり、
   前記第１情報及び前記第２情報のうちの少なくとも１つについて、実リソースに関する上限値は、割当て可能な実論理ユニットの容量であり、
   請求項７に記載の計算機システム。
9. 前記管理システムは、前記テナントが利用可能な仮想論理ユニットを追加する際に、前記第１情報と前記第２情報とに基づいて、前記テナントが利用可能な仮想論理ユニットの基になる実論理ユニットを前記テナントに割り当てる
   請求項８に記載の計算機システム。
10. 前記テナントに割り当てられている１以上のテナント用リソース又はそれらの基になっている複数の実リソースは、１つのストレージ装置に集約されている
    請求項２に記載の計算機システム。
11. 少なくとも１つの実ストレージ装置が、論理的な記憶デバイスである実論理ユニットを提供し、
    複数の実ストレージ装置に基づく仮想ストレージ装置は、その仮想ストレージ装置の基になっている１以上の実ストレージ装置が有する実論理ユニットが割り当てられた仮想論理ユニットを有し、
    テナント用リソースとして、スナップショット用の仮想論理ユニットがあり、
    前記管理システムは、前記テナントが利用可能なスナップショット用の仮想論理ユニットを追加する際に、前記第１情報と前記第２情報とに基づいて、前記テナントが利用可能なスナップショット用の仮想論理ユニットの基になる実論理ユニットを前記テナントに割り当てる
    請求項１０に記載の計算機システム。
12. 前記管理システムは、前記計算機システムに実ストレージ装置を追加する際に、前記第１情報と前記第２情報とに基づいて、複数の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとして前記テナントに割り当てる
    請求項２に記載の計算機システム。
13. 前記第２情報は、前記テナントに対して割り当てるテナント用リソースの性能値についての上限値である
    請求項３に記載の計算機システム。
14. 前記管理システムは、前記テナントが使用可能な実ストレージ装置を追加する際、又は新たなテナントが使用可能なテナント用リソースを追加する際に、前記第１情報と前記第２情報とに基づいて、前記１以上の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとして前記テナント又は新たなテナントに割り当てる
    請求項１に記載の計算機システム。
15. 複数の実リソースを有する１以上の実ストレージ装置各々の実リソースに関する上限値を含む第１情報と、テナントが使用可能なリソースであるテナント用リソース又はそのテナント用リソースの基になるリソースとして割り当てられる実リソースに関する上限値である第２情報とを参照し、
    前記第１情報及び前記第２情報に基づいて、前記１以上の実ストレージ装置から実リソース又はその実リソースに基づく仮想リソースをテナント用リソースとして前記テナントに割り当てる
    リソース管理方法。

Images