JP5416860B2 - 計算機システムおよびその制御方法 - Google Patents

Description

本発明はストレージシステムに関し、特にストレージボリュームプールの容量管理に関する。

特開２００３−１５９１５号公報（特許文献１）に開示されているようなシンプロビジョニングと呼ばれる技術がある。シンプロビジョニングは、仮想ボリュームをホスト計算機に割り当てる技術である。仮想ボリュームは、ホスト計算機から仮想ボリュームへデータの書き込みがあって初めて、プール化された物理ディスクからデータ保存領域が割り当てられるボリュームである。

一方、一つのホスト計算機上に複数の仮想マシン（ＶＭ）を構築するサーバ仮想化技術がある。サーバ仮想化技術において「ＶＭｗａｒｅ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｆｉｌｅ Ｓｙｓｔｅｍ： Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ ａｎｄ Ｂｅｓｔ Ｐｒａｃｔｉｃｅｓ」（非特許文献１）に開示されているような技術が利用されている。この技術では、サーバ仮想化の管理プログラムであるハイパーバイザが、複数ボリュームを一括して管理し、管理者に単一のデータ保存領域として提供する。

特開２００３−１５９１５号公報

「ＶＭｗａｒｅ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ Ｆｉｌｅ Ｓｙｓｔｅｍ： Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ ａｎｄ Ｂｅｓｔ Ｐｒａｃｔｉｃｅｓ」、第６頁から第１１頁、［ｏｎｌｉｎｅ］、ＶＭｗａｒｅ Ｉｎｃ．発行、［平成２３年１月１４日検索］、インターネット＜ＵＲＬ：http://www.vmware.com/pdf/vmfs-best-practices-wp.pdf＞

従来技術において、仮想ボリュームがホスト計算機に割り当てられた場合、ホスト計算機は仮想ボリュームの空容量のみ認識し、仮想ボリュームのデータを実際に格納するボリュームプールの情報を認識しない。

このため、複数ボリュームプールからなる複数仮想ボリュームをホスト計算機に割り当てた環境で、管理者がＶＭを作成したとき、ハイパーバイザはボリュームプールのリソース使用量（使用容量、Ｉ／Ｏ量等）を考慮せずに、空容量の大きい仮想ボリュームにＶＭの実体であるイメージファイルを作成する。その結果、ボリュームプール間でのリソース使用量の偏りが発生又は助長される可能性がある。

この偏りを原因として「他のボリュームプールに空容量があるにもかかわらず、特定のボリュームプールの容量が枯渇してしまい、そのプールから切り出した仮想ボリュームへの書き込みができなくなる」、および「Ｉ／Ｏ性能が低下する」といった課題があった。偏りが発生した場合、解消するためにはボリュームプール間でのデータコピーが必要だが、このためには一時的にストレージのリソース（メモリ、ネットワーク帯域等）をデータコピーのために使用しなくてはならず、Ｉ／Ｏ性能低下の可能性がある。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。

本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、一つ以上の記憶装置と、前記記憶装置に接続される一つ以上のホスト計算機と、を備える計算機システムであって、前記ホスト計算機は、前記記憶装置に接続される第１インターフェースと、前記第１インターフェースに接続される第１プロセッサと、前記第１プロセッサに接続される第１記憶デバイスと、を含み、前記第１プロセッサは、各々が一つ以上のアプリケーションを実行する一つ以上の仮想マシンを制御し、前記記憶装置は、前記ホスト計算機に接続されるコントローラと、前記コントローラに接続される一つ以上の物理記憶デバイスと、を含み、複数の仮想ボリュームと、各々が前記物理記憶デバイスの実記憶領域を含む複数のプールと、を対応付ける情報を保持し、前記ホスト計算機から書き込み先のボリュームとして前記仮想ボリュームが指定されたデータの書き込み要求を受信した場合、書き込み先の前記仮想ボリュームに対応する前記プールに含まれる前記実記憶領域を前記書き込み先の仮想ボリュームに割り当てて、当該データを前記割り当てられた実記憶領域に格納し、前記計算機システムは、前記記憶装置が保持する情報に基づいて、前記ホスト計算機による書き込み先としての前記ボリュームの優先順位を決定し、決定した前記優先順位を保持することを特徴とする。

本発明の一実施形態によれば、ボリュームプール間でのリソース使用量の偏り発生を防止することによって、ストレージ側でのプール間データコピーの回数を減らすことができる。

本発明の第１の実施形態におけるＩＴシステムの全体概要を示すブロック図である。 本発明の第１の実施形態のホスト計算機の内部構成を示すブロック図である。 本発明の第１の実施形態の管理サーバの内部構成を示すブロック図である。 本発明の第１の実施形態のストレージ装置の内部構成を示すブロック図である。 本発明の第１の実施形態におけるＩＴシステムのソフトウェア構成の概要を示すブロック図である。 本発明の第１の実施形態のストレージ装置内のソフトウェア構成の概要を示すブロック図である。 本発明の第１の実施形態における論理ボリュームと物理ディスクとの関係を示した概念図である。 本発明の第１の実施形態の論理ボリュームマネージャが保持するボリューム管理テーブルの一例を示す説明図である。 本発明の第１の実施形態における仮想ボリュームと論理ボリュームの関係を示した概念図である。 本発明の第１の実施形態の仮想ボリュームマネージャが保持する仮想ボリューム管理テーブルの一例を示す説明図である。 本発明の第１の実施形態の仮想ボリュームマネージャが保持する未使用領域管理テーブルの一例を示す説明図である。 本発明の第１の実施形態の管理ソフトウェアが保持するホスト・ストレージボリューム管理テーブルの一例を示した説明図である。 本発明の第１の実施形態の追加モジュールが保持する書き込み先候補ボリューム管理テーブルの一例を示した説明図である。 本発明の第１の実施形態の管理ソフトウェアが、ハイパーバイザおよび各ストレージ装置の構成情報を取得して、追加モジュールが書き込み先候補ボリューム管理テーブルを保持するまでの処理を示したシーケンス図である。 本発明の第１の実施形態において、管理者がハイパーバイザ上でファイル作成を伴う操作を行い、追加モジュールが各ストレージ装置の指定ボリュームにファイルを書き込むまでの処理を示したシーケンス図である。 本発明の第１の実施形態において実行される、書き込み先候補ボリューム管理テーブルの優先順位決定の処理の一例を示すフローチャートである。 本発明の第２の実施形態の管理ソフトウェアがハイパーバイザおよび各ストレージ装置の構成情報を取得し、管理ソフトウェアが書き込み先候補ボリューム管理テーブルを保持するまでの処理を示したシーケンス図である。 本発明の第２の実施形態において、管理者が管理ソフトウェア上でファイル作成操作を行い、管理ソフトウェアがインターフェースを通して各ストレージ装置の指定ボリュームにファイルを書き込むまでの処理を示したシーケンス図である。 本発明の第３の実施形態の追加モジュールが、ハイパーバイザおよび各ストレージ装置の構成情報を取得し、書き込み先候補ボリューム管理テーブルを保持するまでの処理を示したシーケンス図である。 本発明の第１の実施形態のハイパーバイザが保持するホストボリューム管理テーブルの一例を示す説明図である。 本発明の第１の実施形態のストレージエージェントが保持するストレージボリューム管理テーブルの一例を示した説明図である。 本発明の第２の実施形態のハイパーバイザが保持するホストボリューム管理テーブルの一例を示す説明図である。

以下、添付図面に基づいて、本発明の実施形態を説明する。

＜第１の実施形態＞

図１から図１５、図１９、図２０に基づいて、本発明に従う第１の実施形態について説明する。

図１は、本発明の第１の実施形態におけるＩＴシステムの全体概要を示すブロック図である。

本システムは、ホスト計算機１００、管理サーバ２００、および一つ以上のストレージ装置４００から構成され、それらは互いにＬＡＮ３０１で接続されている。ストレージ装置４００とホスト計算機１００とは互いにＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）３００で接続されている。なお、本システムは複数のホスト計算機を含んでもよく、その場合は管理用のＬＡＮ３０１に加えてデータ転送用のＬＡＮで複数のホスト計算機が互いに接続されていてもよい。

図２Ａは、本発明の第１の実施形態のホスト計算機１００の内部構成を示すブロック図である。

ホスト計算機１００は、一つ以上のＣＰＵ１１０、一つ以上のメモリ１１１、一つ以上のＳＡＮアダプタ１１２、一つ以上のＬＡＮアダプタ１１３、および一つ以上のストレージデバイス１１４で構成され、それらは互いに内部バス１１５で接続されている。ホスト計算機１００はＳＡＮアダプタ１１２を介してストレージ装置４００と接続されている。またホスト計算機１００はＬＡＮアダプタ１１３を介して管理サーバ２００と接続されている。なお、ホスト計算機１００はストレージデバイス１１４を必ずしも備えなくてもよい。ホスト計算機１００は、ストレージデバイス１１４を備えない場合、ストレージ装置４００内のボリュームをソフトウェアの記憶領域として用いる。

図２Ｂは、本発明の第１の実施形態の管理サーバ２００の内部構成を示すブロック図である。

管理サーバ２００の内部構成はホスト計算機１００と同様だが、必ずしもＳＡＮアダプタを備えていない。図２Ｂに示す管理サーバ２００は、一つ以上のＣＰＵ２１０、一つ以上のメモリ２１１、一つ以上のＬＡＮアダプタ２１２、および一つ以上のストレージデバイス２１３で構成され、それらは互いに内部バス２１４で接続されている。管理サーバ２００はＬＡＮアダプタ２１２を介して、ストレージ装置４００およびホスト計算機１００と接続されている。

図３は、本発明の第１の実施形態のストレージ装置４００の内部構成を示すブロック図である。

ストレージ装置４００は一つ以上のコントローラ４１０および一つ以上の物理ディスク４１１で構成される。コントローラ４１０は、一つ以上のＣＰＵ４１２、一つ以上のメモリ４１３、一つ以上のＮＶＲＡＭ（Ｎｏｎ Ｖｏｌａｔｉｌｅ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４１４、一つ以上のキャッシュメモリ４１５、一つ以上のバックエンドインターフェース４１６および４１７、一つ以上のＬＡＮアダプタ４１８、ならびに一つ以上のＳＡＮアダプタ４１９で構成され、それらは相互に内部バス４２０で接続されている。

コントローラ４１０はバックエンドインターフェース４１６および４１７を介して物理ディスク４１１と接続されている。また、ストレージ装置４００はＬＡＮアダプタ４１８を介して管理サーバ２００と接続されている。また、ストレージ装置４００はＳＡＮアダプタ４１９を介してホスト計算機１００と接続されている。

図４は、本発明の第１の実施形態におけるＩＴシステムのソフトウェア構成の概要を示すブロック図である。

ホスト計算機１００上では一つ以上の仮想マシン５００、一つ以上のハイパーバイザ５０１、および追加モジュール５０２が動作する。なお、追加モジュールは、本実施形態においてハイパーバイザ５０１に追加されるプログラムモジュールである。これらのソフトウェア（すなわち仮想マシン５００、ハイパーバイザ５０１および追加モジュール５０２に対応するプログラム）はストレージデバイス１１４またはストレージ装置４００に格納されており、メモリ１１１にロードされ、ＣＰＵ１１０を用いて実行される。

以下の説明において仮想マシン５００、ハイパーバイザ５０１または追加モジュール５０２を主語として説明を行う場合があるが、上記のプログラムは、プロセッサ（ＣＰＵ１１０）によって実行されることで、定められた処理を、メモリ１１１および通信ポート（例えばＳＡＮアダプタ１１２またはＬＡＮアダプタ１１３のような通信制御デバイス）を用いながら行うため、それらの説明における主語をプロセッサに置き換えてもよい。ホスト計算機１００の場合、仮想マシン５００、ハイパーバイザ５０１または追加モジュール５０２が実行する処理を、ＣＰＵ１１０が上記のプログラムに従って実行する処理として説明することができる。また、以下の説明において仮想マシン５００、ハイパーバイザ５０１または追加モジュール５０２が保持する情報は、実際にはメモリ１１１またはストレージデバイス１１４に保持される。

また、プロセッサを主語として開示された処理は、そのプロセッサを含む計算機または情報処理装置（上記の仮想マシン５００、ハイパーバイザ５０１および追加モジュール５０２の場合は、ホスト計算機１００）、または、それを包含する計算機システムが実行する処理として説明してもよい。また、プログラムの一部または全部が専用ハードウェアによって実現されてもよい。また、各種プログラムは、プログラム配布サーバまたは計算機が読み取り可能な非一時的記憶メディアによって各計算機等にインストールされてもよい。以下に説明する管理サーバ２００およびストレージ装置４００についても同様である。

管理サーバ２００上では管理ソフトウェア６００が動作する。管理ソフトウェア６００はストレージデバイス２１３に格納されており、メモリ２１１にロードされ、ＣＰＵ２１０を用いて実行される。なお、ホスト計算機１００の場合と同様、以下の説明において管理ソフトウェア６００が実行する処理は、ＣＰＵ２１０が管理ソフトウェア６００に従って実行する処理、管理サーバ２００が実行する処理、または計算機システムが実行する処理として説明することもできる。また、以下の説明において管理ソフトウェア６００が保持する情報は、実際にはメモリ２１１またはストレージデバイス２１３に保持される。

なお、管理サーバ２００はさらに入出力デバイス（図示省略）を有する。入出力デバイスの例としてはディスプレイ、キーボードおよびポインティングデバイスが考えられるが、これ以外のデバイスであってもよい。あるいは、管理サーバ２００がシリアルインターフェースまたはイーサネットインターフェースを入出力デバイスとして有し、当該インターフェースにディスプレイ、キーボードまたはポインティングデバイスを有する表示用計算機（図示省略）を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信したりすることによって、表示用計算機による表示または入力の受付を行い、これによって入出力デバイスによる入力および表示を代替してもよい。

以後、計算機システムを管理し、本発明の表示用情報を表示する一つ以上の計算機の集合を管理システムと呼ぶことがある。管理サーバ２００が表示用情報を表示する場合、管理サーバ２００が管理システムである。また、管理サーバ２００と表示用計算機（図示省略）との組み合わせも管理システムである。また、管理処理の高速化および高信頼化のために複数の計算機が管理サーバ２００と同等の処理を実現してもよく、その場合は当該複数の計算機（さらに表示用計算機が表示を行う場合はその表示用計算機も含む）が管理システムである。

ストレージ装置４００上には一つ以上のボリュームプール７００があり、これらから作成された一つ以上の仮想ボリューム７０１（後述）がある。仮想ボリューム７０１は、ＳＡＮ３００を介してホスト計算機１００に割り当てられている。なお、ストレージ装置４００上には仮想ボリューム７０１だけでなく、後述の論理ボリュームが混在していてもよい。また、ハイパーバイザ５０１が複数のホスト計算機に跨っていてもよい。

ハイパーバイザ５０１は複数の仮想マシンを実行するための環境を提供する。また、ハイパーバイザ５０１はボリューム（すなわち仮想ボリューム７０１および論理ボリューム７０２（図５参照））を認識し、管理する。さらに、ハイパーバイザ５０１は、仮想マシン５００のイメージファイル５０３がどのボリュームに格納されているかを管理し、イメージファイル５０３への書き込み処理等を実行する。ただし、イメージファイルの新規作成時は、ハイパーバイザ５０１の新規ファイル作成処理をキャプチャした追加モジュール５０２が、イメージファイル格納先ボリュームを決定する。

図１９は、本発明の第１の実施形態のハイパーバイザ５０１が保持するホストボリューム管理テーブル２１００の一例を示す説明図である。

なお、以下の説明において、計算機システムに保持される情報を、「テーブル」の表現を用いて説明するが、これらの情報はテーブル以外のデータ構造、例えばリスト、データベース（ＤＢ）またはキュー等で表現されてもよい。これらの情報がデータ構造に依存しないことを示すために、例えば「ホストボリューム管理テーブル」を「ホストボリューム管理情報」のように呼ぶことがある。また、各情報の内容を説明する際に「識別情報」、「識別子」、「名」、「名前」または「ＩＤ」などの表現を用いる場合があるが、これらは互いに置換可能である。以下に説明するホストボリューム管理テーブル２１００以外のテーブルについても同様である。

ホストボリューム管理テーブル２１００は、ホストボリュームＩＤ列２１０１、ストレージＩＤ列２１０２、ストレージボリュームＩＤ列２１０３、および空容量列２１０４からなる。ホストボリュームＩＤ列２１０１には、ハイパーバイザ５０１が認識し、付与するボリューム（仮想ボリュームまたは論理ボリューム）の識別子が登録される。ストレージＩＤ列２１０２にはホストボリューム（すなわちホスト計算機１００によって認識されるボリューム）に対応するストレージボリューム（すなわちストレージ装置４００によって認識されるボリューム）が存在するストレージ装置の識別子が登録される。ストレージボリュームＩＤ列２１０３には、ホストボリュームに対応するストレージボリュームの識別子が登録される。空容量列２１０４にはホストボリュームの空容量が登録される。

ホストボリューム管理テーブル２１００は、上記以外の情報、例えば、各ホストボリュームに対するＩ／Ｏ量を示す情報を登録する列をさらに含んでもよい。例えば、ホスト計算機１００が各ホストボリュームへのＩ／Ｏ量を定期的に測定し、その結果をホストボリューム管理テーブル２１００に登録してもよい。

なお、ストレージＩＤおよびストレージボリュームＩＤは、ストレージ装置４００が付与および保持する情報であるが、ハイパーバイザ５０１は、例えば、ＳＣＳI Ｉｎｑｕｉｒｙを利用してこれらの情報をストレージ装置４００から取得できる。

管理ソフトウェア６００はホスト計算機１００およびストレージ装置４００から構成情報を取得し、管理テーブルに格納する。また管理ソフトウェア６００は追加モジュール５０２に対して書き込み先ボリュームの優先順位情報を送信する。管理ソフトウェア６００については詳細を後述する。

図５は、本発明の第１の実施形態のストレージ装置４００内のソフトウェア構成の概要を示すブロック図である。

ストレージ装置４００上では、ストレージエージェント７０３、仮想ボリュームマネージャ７０４、および論理ボリュームマネージャ７０５が動作している。これらは物理ディスク４１１またはＮＶＲＡＭ４１４に格納されており、メモリ４１３にロードされ、ＣＰＵ４１２を用いて実行される。なお、ホスト計算機１００の場合と同様、以下の説明においてストレージエージェント７０３、仮想ボリュームマネージャ７０４または論理ボリュームマネージャ７０５が実行する処理は、ＣＰＵ４１２がプログラムに従って実行する処理、ストレージ装置４００が実行する処理、または計算機システムが実行する処理として説明することもできる。また、以下の説明においてストレージエージェント７０３、仮想ボリュームマネージャ７０４または論理ボリュームマネージャ７０５が保持する情報は、実際にはメモリ１１１またはストレージデバイス１１４に保持される。

なお、図５の例において、仮想ボリューム７０１はホスト計算機１００に割り当てられるが、ボリュームプール７００に属する論理ボリューム７０２は、仮想ボリューム７０１に割り当てられるために使用されるものであり、直接（すなわち仮想ボリューム７０１を介さずに）ホスト計算機１００に割り当てられることはない。しかし、実際には、ストレージ装置４００は、ボリュームプール７００に属さない論理ボリューム７０２を含んでもよい。ボリュームプール７００に属さない論理ボリューム７０２は、仮想ボリューム７０１に割り当てることができないが、仮想ボリューム７０１を介さずに直接ホスト計算機１００に割り当てることができる。

図４を参照して、ストレージ装置４００上に仮想ボリューム７０１と論理ボリュームとが混在し得ることを記載したが、これは、ホスト計算機１００に割り当て可能な仮想ボリューム７０１と、ホスト計算機１００に割り当て可能な論理ボリューム７０２とが混在し得ること、言い換えると、ボリュームプール７００に属する論理ボリューム７０２と、ボリュームプール７００に属さない論理ボリューム７０２とが混在し得ることを意味する。

論理ボリュームマネージャ７０５は、物理ディスク４１１から一つ以上の論理ボリューム７０２を作成し、論理ボリューム７０２と物理ディスク４１１の間のマッピングを管理する。

図６は、本発明の第１の実施形態における論理ボリューム７０２と物理ディスク４１１との関係を示した概念図である。

図６の例では論理ボリューム７０２は四つの物理ディスク８００、８０１、８０２および８０３から構成されている。１−１、１−２、１−３…とラベル付けした物理ディスク内の領域は、あらかじめ決められたサイズに区切られた領域であり、ストライプと呼ばれる。一方、Ｐ１、Ｐ２…とラベル付けした領域は、対応するストライプのパリティ情報を格納する領域であり、パリティストライプと呼ばれる。論理ボリュームマネージャ７０５は論理ボリューム７０２と物理ディスク４１１のマッピング関係を管理するために、ボリューム管理テーブルを保持する。

図７は、本発明の第１の実施形態の論理ボリュームマネージャ７０５が保持するボリューム管理テーブルの一例を示す説明図である。

ボリューム管理テーブルは、論理ボリュームＩＤ列９００、ディスク列９０１、ＲＡＩＤレベル列９０２、およびストライプサイズ列９０３からなる。論理ボリュームＩＤ列９００には、論理ボリュームマネージャ７０５が各論理ボリュームに割り当てた識別子が登録される。ディスク列９０１には論理ボリュームを構成する物理ディスクの識別子が登録される。ＲＡＩＤレベル列９０２には論理ボリュームの構成に使用されているＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）レベルが登録される。ストライプサイズ列９０３には、論理ボリュームの構成に使用されているストライプのサイズが登録される。

仮想ボリュームマネージャ７０４は、ボリュームプール７００に登録された論理ボリューム７０２から一つ以上の仮想ボリューム７０１を作成し、仮想ボリューム７０１と、論理ボリューム７０２との間のマッピングを管理する。

図８は、本発明の第１の実施形態における仮想ボリューム７０１と論理ボリューム７０２の関係を示した概念図である。

多くの場合、仮想ボリューム７０１へは、物理ディスクの記憶領域（以下、実記憶領域と記載）が直接割り当てられるのではなく、図８のように論理ボリューム７０２が構成され、論理ボリューム７０２内の一部領域が割り当てられる。仮想ボリューム７０１にデータの書き込みがあった場合、仮想ボリュームマネージャ７０４は、論理ボリューム７０２内の未使用の（すなわちまだ仮想ボリューム７０１に割り当てられていない）領域を、仮想ボリューム７０１の書き込みがあった場所に割り当てる。

図８の例では、仮想ボリューム７０１の領域１０００に論理ボリューム７０２の領域１００３が割り当てられ、仮想ボリューム７０１の領域１００１に論理ボリューム７０２の領域１００５が割り当てられている。このことは、既にホスト計算機から領域１０００及び領域１００１へのデータの書き込みが行われたことを意味している。例えば、ストレージ装置４００がホスト計算機１００から領域１０００へのデータ書き込み要求を受信した場合、データは、領域１０００に割り当てられた論理ボリューム７０２の領域１００３（より正確には、その領域１００３に割り当てられた物理ディスク８０１内の実記憶領域）に格納される。なお、図７に示すように、論理ボリューム７０２内の全ての領域に、物理ディスク８０１内の実記憶領域が予め割り当てられている。

図８の例において、仮想ボリューム７０１のうち領域１０００及び１００１を除く残りの領域１００２には論理ボリューム７０２の領域が割り当てられていない。一方、論理ボリューム７０２のうち領域１００３及び１００５を除く残りの領域１００４は、まだ仮想ボリューム７０１に割り当てられていない（すなわち未使用である）。ストレージ装置４００が新たに領域１００２へのデータの書き込み要求を受信した場合、領域１００２のうち少なくともデータが書き込まれる部分には、領域１００４の少なくとも一部が割り当てられ、当該割り当てられた領域にデータが格納される。

なお、上記のように、多くの場合は（本実施形態の場合も含めて）仮想ボリューム７０１へは論理ボリューム７０２の一部領域が割り当てられるが、仮想ボリュームに物理ディスクの実記憶領域が直接割り当てられてもよい。上記のように論理ボリューム７０２の一部領域が割り当てられる場合であっても、最終的には、割り当ての結果、仮想ボリューム７０１の領域１０００、１００１等に、物理ディスクの実記憶領域が対応付けられる。

仮想ボリューム７０１と論理ボリューム７０２との関係、仮想ボリューム７０１の割り当て状況、および論理ボリューム７０２内の使用状況を管理するため、仮想ボリュームマネージャ７０４は、仮想ボリューム管理テーブル１１００および未使用領域管理テーブル１２００を保持する。

図９は、本発明の第１の実施形態の仮想ボリュームマネージャ７０４が保持する仮想ボリューム管理テーブル１１００の一例を示す説明図である。

仮想ボリューム管理テーブル１１００は大きく分けて、仮想ボリューム内の位置を示す仮想ボリューム列、および論理ボリューム内の対応する領域を示す論理ボリューム列からなる。

仮想ボリューム列は、ボリュームＩＤ列１１０１、開始ＬＢＡ列１１０２、および終了ＬＢＡ列１１０３からなる。ボリュームＩＤ列１１０１には、仮想ボリュームに付与されたボリュームの識別子が登録される。開始ＬＢＡ列１１０２には、仮想ボリューム内の領域の開始ＬＢＡ（Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ）が登録される。終了ＬＢＡ列１１０３には、仮想ボリューム内の領域の終了ＬＢＡが登録される。

論理ボリューム列も同様に、ボリュームＩＤ列１１０４、開始ＬＢＡ列１１０５、および終了ＬＢＡ列１１０６からなる。ボリュームＩＤ列１１０４には、対応する仮想ボリュームの領域へ割り当てられたデータ保存領域を持つ論理ボリュームの識別子が登録される。開始ＬＢＡ列１１０５には、論理ボリューム内の領域の開始ＬＢＡが登録される。終了ＬＢＡ列１１０６には、論理ボリューム内の領域の終了ＬＢＡが登録される。

例えば、図９の仮想ボリューム管理テーブル１１００の先頭の行のボリュームＩＤ列１１０１、開始ＬＢＡ列１１０２および終了ＬＢＡ列１１０３には、それぞれ、「３」、「０ｘ００００００００」および「０ｘ０００１ａｆ０ｆ」が登録され、ボリュームＩＤ列１１０４、開始ＬＢＡ列１１０５および終了ＬＢＡ列１１０６には、それぞれ、「０」、「０ｘ００００００００」および「０ｘ０００１ａｆ０ｆ」が登録されている。これは、ボリュームＩＤ「３」で識別される仮想ボリューム７０１のＬＢＡ「０ｘ００００００００」から「０ｘ０００１ａｆ０ｆ」までの領域に、ボリュームＩＤ「０」で識別される論理ボリューム７０２のＬＢＡ「０ｘ００００００００」から「０ｘ０００１ａｆ０ｆ」までの領域が割り当てられていることを示す。論理ボリューム内の領域にはあらかじめ物理ディスク４１１の実記憶領域が割り当てられているため（図６および図７参照）、結局、仮想ボリューム管理テーブル１１００に基づいて、仮想ボリューム７０１内の領域に割り当てられた物理ディスク４１１の実記憶領域を特定することができる。

図１０は、本発明の第１の実施形態の仮想ボリュームマネージャ７０４が保持する未使用領域管理テーブル１２００の一例を示す説明図である。

未使用領域管理テーブル１２００は、論理ボリュームＩＤ列１２０１、開始ＬＢＡ列１２０２、および終了ＬＢＡ列１２０３からなる。論理ボリュームＩＤ列１２０１には、仮想ボリューム７０１へのデータ保存領域割り当て用としてボリュームプール７００に登録されている論理ボリューム７０２の識別子が登録される。開始ＬＢＡ列１２０２および終了ＬＢＡ列１２０３には、論理ボリューム７０２の中で未使用の領域１００４の開始ＬＢＡおよび終了ＬＢＡ列がそれぞれ登録される。

ストレージエージェント７０３は、論理ボリューム７０２および仮想ボリューム７０１を管理する。

図２０は、本発明の第１の実施形態のストレージエージェント７０３が保持するストレージボリューム管理テーブル２２００の一例を示した説明図である。

ストレージボリューム管理テーブル２２００は、ストレージボリュームＩＤ列２２０１、プールＩＤ列２２０２、およびプール空容量列２２０３からなる。ストレージボリュームＩＤ列２２０１には、ストレージボリューム（すなわち、仮想ボリューム７０１または論理ボリューム７０２）の識別子が登録される。プールＩＤ列２２０２には、ストレージボリュームＩＤ列２２０１に登録された識別子によって識別されるボリューム（以下、図２０の説明において当該ボリュームと記載する）に対応するボリュームプールの識別子が登録される。プール空容量列２２０３には、当該ボリュームに対応するボリュームプールの空容量が登録される。ボリュームプールの空容量とは、ボリュームプール７００のうち、まだ仮想ボリューム７０１に割り当てられていない領域の容量である。

なお、当該ボリュームが論理ボリューム７０２である場合は、当該ボリュームにボリュームプール７００が対応付けられないため、プールＩＤ列２２０２には空欄が登録され、プール空容量列２２０３には、当該ボリュームの実際の容量および空容量にかかわらず、プール空容量列２２０３に登録され得る最大値が登録される。このような値が登録される理由については後述する（図１５参照）。

ただし、論理ボリューム７０２に関する情報は、上記以外の形式でストレージボリューム管理テーブル２２００に登録されてもよい。例えば、ストレージボリューム管理テーブル２２００に、当該ボリュームが論理ボリューム７０２または仮想ボリューム７０１のいずであるかを示す列を登録し、当該ボリュームが論理ボリューム７０２である場合のプールＩＤ列２２０２およびプール空容量列２２０３を空欄としてもよい。

ストレージボリューム管理テーブル２２００は上記以外の列をさらに含んでもよい。例えば、ストレージボリューム管理テーブル２２００は、各ストレージボリュームに対するＩ／Ｏ量または各ボリュームプールに対するＩ／Ｏ量を登録する列をさらに含んでもよい。例えば、ストレージ装置４００が各ストレージボリュームまたは各ボリュームプールへのＩ／Ｏ量を定期的に測定し、その結果をストレージボリューム管理テーブル２２００に登録してもよい。

図１１は、本発明の第１の実施形態の管理ソフトウェア６００が保持するホスト・ストレージボリューム管理テーブル１６００の一例を示した説明図である。

ホスト・ストレージボリューム管理テーブル１６００は大きく分けてホスト側情報列およびストレージ側情報列を持つ。

ホスト側情報列はホストボリュームＩＤ列１６０１および空容量列１６０２からなる。ホストボリュームＩＤ列１６０１にはハイパーバイザ５０１の認識するボリュームの識別子が登録される。以下、図１１の説明において、ホストボリュームＩＤ列１６０１に登録された識別子によって識別されるボリュームを当該ボリュームと記載する。当該ボリュームは、ホスト計算機に割り当てられた仮想ボリューム７０１または論理ボリューム７０２のいずれかである。空容量列１６０２には当該ボリュームの空容量が登録される。

ストレージ側情報列はストレージＩＤ列１６０３、ストレージボリュームＩＤ列１６０４、プールＩＤ列１６０５、およびプール空容量列１６０６からなる。ストレージＩＤ列１６０３およびストレージボリュームＩＤ列１６０４には、ホストボリュームＩＤ列１６０１に対応する、ストレージ装置およびストレージボリュームの識別子（言い換えると、当該ボリュームを格納するストレージ装置４００の識別子、および、そのストレージ装置４００が当該ボリュームに付与した識別子）がそれぞれ登録される。プールＩＤ列１６０５には、当該ボリュームに対応するボリュームプールの識別子が登録される。プール空容量列１６０６には、当該ボリュームに対応するボリュームプール７００の空容量が登録される。

なお、ホストボリュームＩＤ列１６０１の識別子とストレージボリュームＩＤ列１６０４の識別子は、一般に異なる。また、当該ボリュームが論理ボリュームである場合は、図２０の場合と同様、プールＩＤ列１６０５は空欄となり、プール空容量列１６０６の値は登録され得る最大値となる。

また、ホスト側情報列およびストレージ側情報列には、上記以外の列が含まれてもよい。例えば、ホストボリューム管理テーブル２１００が各ホストボリュームに対するＩ／Ｏ量を登録する列を含む場合、ホスト・ストレージボリューム管理テーブル１６００のホスト側情報列も同様の列を含んでよい。また、ストレージボリューム管理テーブル２２００が各ストレージボリュームまたは各ボリュームプールに対するＩ／Ｏ量を登録する列を含む場合、ホスト・ストレージボリューム管理テーブル１６００のストレージ側情報列も同様の列を含んでよい。

なお、ホスト・ストレージボリューム管理テーブル１６００は、「ホストボリューム管理テーブル２１００」および「ストレージボリューム管理テーブル２２００に各ストレージ装置４００の識別子（ストレージＩＤ）を付与したテーブル」から作成できる。具体的には、「ホストボリューム管理テーブル２１００の行」と「ストレージボリューム管理テーブル２２００に各ストレージ装置４００の識別子（ストレージＩＤ）を付与したテーブルの行」とを比較し、ストレージＩＤおよびストレージボリュームＩＤが一致するものを結合することによって、ホスト・ストレージボリューム管理テーブル１６００の各行が作成される。ただし、ホストボリューム管理テーブル２１００に登録されていないボリューム（すなわち、ホスト計算機１００の認識していないボリューム）は、ホスト・ストレージボリューム管理テーブル１６００に登録されない。

図１２は、本発明の第１の実施形態の追加モジュール５０２が保持する書き込み先候補ボリューム管理テーブル１７００の一例を示した説明図である。

書き込み先候補ボリューム管理テーブル１７００は優先順位列１７０１およびホストボリュームＩＤ列１７０２からなる。優先順位列１７０１には、追加モジュール５０２のファイル作成処理時に書き込み先のボリュームを検索するための順位が登録される。ホストボリュームＩＤ列１７０２には、ハイパーバイザ５０１が認識するボリュームの識別子が登録される。

なお、書き込み先候補ボリューム管理テーブル１７００に登録された順位は、各ボリュームの、イメージファイル５０３の格納先としての望ましさを示す指標である。高い順位が付与されたボリュームほど、イメージファイル５０３の格納先として望ましいことを意味する。ただし、後述するように、必ずしも優先順位の通りに格納先が選択されるとは限らず、単に警告を発するためだけに優先順位が参照される場合もある。

図１３は、本発明の第１の実施形態の管理ソフトウェア６００が、ハイパーバイザ５０１および各ストレージ装置４００の構成情報を取得して、追加モジュール５０２が書き込み先候補ボリューム管理テーブル１７００を保持するまでの処理を示したシーケンス図である。

なお、この処理は、書き込み先候補ボリューム管理テーブル１７００の更新のために定期的に実行される。ただし、図１３の処理は、定期的に実行されるほかに、ユーザが指示をした時、または、ハイパーバイザ５０１もしくはストレージ装置４０１からの情報プッシュ時など、所定のイベントを契機として実行されてもよいし、任意のタイミングで実行されてもよい。

最初に、管理ソフトウェア６００は、ハイパーバイザ５０１に対してホスト側構成情報の送信を要求する（ステップ１３００）。

次に、管理ソフトウェア６００は、ハイパーバイザ５０１からホスト側構成情報を受信する（ステップ１３０１）。取得する構成情報は、ホストボリューム管理テーブル２１００に含まれる情報項目である。なお、取得した構成情報に上記以外の情報が含まれていてもよい。また、ホスト側構成情報は、管理ソフトウェア６００からの要求なしに、ハイパーバイザ５０１から送信されてもよい。

次に、管理ソフトウェア６００は、各ストレージ装置４００に対してストレージ側構成情報の送信を要求する（ステップ１３０２）。

次に、管理ソフトウェア６００は、各ストレージ装置４００からストレージ側構成情報を受信する（ステップ１３０３）。取得する構成情報は、各ストレージ装置４００の識別子（ストレージＩＤ）、およびストレージボリューム管理テーブル２２００に含まれる情報項目である。なお、取得した構成情報に上記以外の情報が含まれていてもよい。また、ストレージ側構成情報は、管理ソフトウェア６００の要求なしに、各ストレージ装置４００から送信されてもよい。

次に、管理ソフトウェア６００は、ステップ１３０１およびステップ１３０３で取得した情報をもとに、ホスト・ストレージボリューム管理テーブル１６００を作成する（ステップ１３０４）。作成方法は、図１１を参照して説明した通りである。

次に、管理ソフトウェア６００は、後述の処理によって、書き込み先候補ボリュームの優先順位を決定する（ステップ１３０５）。

次に、管理ソフトウェア６００は、追加モジュール５０２に、書き込み先候補ボリュームの優先順位情報を送信する（ステップ１３０６）。

追加モジュール５０２は、管理ソフトウェア６００から受信した書き込み先候補ボリュームの優先順位情報に基づいて、書き込み先候補ボリューム管理テーブル１７００を保持する（ステップ１３０７）。

図１４は、本発明の第１の実施形態において、管理者１４００がハイパーバイザ５０１上でファイル作成を伴う操作を行い、追加モジュール５０２が各ストレージ装置４００の指定ボリュームにファイルを書き込むまでの処理を示したシーケンス図である。

なお、ファイル作成を伴う操作とは、「仮想マシン５００の新規作成」または「仮想マシン５００に新たにディスクイメージを追加する」等の、イメージファイル５０３の新規作成の指示を含む操作を指す。あるいは、イメージファイル５０３の新規作成の指示を含む他の操作であってもよい。また、図１４の処理の前に、図１３に示す処理を実行し、書き込み先候補ボリューム管理テーブル１７００を作成しておく必要がある。

最初に、管理者１４００がハイパーバイザ５０１上でファイル作成を伴う操作を行う（ステップ１４０１）。

次に、ハイパーバイザ５０１が、ステップ１４０１の操作に応じてファイル作成処理を実行する（ステップ１４０２）。

次に、追加モジュール５０２が、ハイパーバイザ５０１のファイル作成処理をキャプチャする（ステップ１４０３）。なお、キャプチャの実現方法の一例として、ハイパーバイザ５０１からのファイル作成処理イベントの発生通知を、追加モジュール５０２が受信する方法がある。

次に、追加モジュール５０２が、書き込み先候補ボリューム管理テーブル１７００を用いて、書き込み先ボリュームを決定する（ステップ１４０４）。基本的には追加モジュール５０２は書き込み先ボリュームとして優先順位が最高位であるボリュームを選択し、次のステップ１４０５において、Ｉ／Ｏエラーまたは容量不足等に起因する書き込み失敗が発生した場合に、順次、下位順位のボリュームを選択する。

次に、追加モジュール５０２が、ステップ１４０４で決定したボリュームに書き込み処理を行う（ステップ１４０５）。

なお、ステップ１４０５において、追加モジュール５０２は、ステップ１４０４で決定したボリュームではなく、ハイパーバイザ５０１が（優先順位に関係なく）指定したボリュームに書き込みを行ってもよい。この場合において、ハイパーバイザ５０１が指定したボリュームが、書き込み先候補ボリューム管理テーブル１７００における優先順位が低いボリュームである場合に、管理者１４００に対しての警告を、ハイパーバイザ５０１、または管理ソフトウェア６００が表示する。優先順位が低いか否かは、所定の閾値に基づいて判定されてもよい。例えば、上位１０パーセント以下の優先順位、１０位以下の優先順位、または、管理者１４００が定義した順位より低い優先順位を、低い優先順位と判定してもよい。

図１５は、本発明の第１の実施形態において実行される、書き込み先候補ボリューム管理テーブル１７００の優先順位決定の処理（ステップ１３０５）の一例を示すフローチャートである。

最初に、管理ソフトウェア６００は、プール空容量列１６０６の降順に、ホスト・ストレージボリューム管理テーブル１６００をソートする（ステップ１５０１）。これは次の理由による。すなわち、イメージファイル５０３が格納された後、そのイメージファイル５０３へのデータの書き込みが行われ、その結果、格納先の仮想ボリューム７０１に割り当てられたボリュームプール７００の容量が不足すると、この不足を解消するために、ボリュームプール７００間でのデータのコピーが必要になり、これによってＩ／Ｏ性能の低下が発生する。このようなデータのコピーの回数を減らすためには、空容量が大きいボリュームプール７００に割り当てられた仮想ボリューム７０１にイメージファイル５０３を格納することが望ましいためである。

なお、ホスト・ストレージボリューム管理テーブル１６００にボリュームプールへのＩ／Ｏ量が登録されている場合には、そのＩ／Ｏ量の昇順にホスト・ストレージボリューム管理テーブル１６００をソートしてもよい。特定の物理ディスクへのＩ／Ｏの集中による性能低下を防ぐためには、Ｉ／Ｏ量の少ないボリュームプール７００に割り当てられた仮想ボリューム７０１にイメージファイル５０３を格納することが望ましいためである。

次に、管理ソフトウェア６００は、変数ｎおよびｉを０で初期化する（ステップ１５０２）。ｎはステップ１５０３からステップ１５０７の繰り返し処理に用いる変数であり、繰り返しが何回目かを表す。ｉはステップ１５０３からステップ１５０７の繰り返し処理内で用いる変数であり、ホスト・ストレージボリューム管理テーブル１６００の何行目を処理するかを示す。

変数ｎがホスト・ストレージボリューム管理テーブル１６００に登録されている行数より小さい場合、管理ソフトウェア６００は、ステップ１５０３からステップ１５０７の繰り返し処理を実行する（ステップ１５０３）。その他の場合は、全行数分の処理が終了したため、ステップ１５０８に移る。

ステップ１５０３において変数ｎがホスト・ストレージボリューム管理テーブル１６００に登録された行数より小さいと判定された場合、管理ソフトウェア６００は、ホスト・ストレージボリューム管理テーブル１６００の第ｉ行が所定の条件を満たすか否かを判定する（ステップ１５０４）。

ここで、所定の条件とは、イメージファイル５０３の格納先として望ましくないボリュームの条件である。例えば、一般に、容量に余裕のないボリュームに新たなイメージファイル５０３を格納することは望ましくない。また、仮想マシン５００の性能を確保するためには、Ｉ／Ｏが混雑したボリュームプール７００に対応する仮想ボリューム７０１に新たなイメージファイル５０３を格納することは望ましくない。このため、ステップ１５０４の条件は、例えば、「第ｉ行に登録されたボリュームの空容量がしきい値未満」、または「第ｉ行に登録されたボリュームに対応するボリュームプールに対するＩ／Ｏ量がしきい値以上」等のいずれかであってもよいし、それらの組み合わせであってもよい。

管理ソフトウェア６００は、上記の条件が満たされる場合にステップ１５０５を実行し、満たされない場合にステップ１５０６を実行する。

ステップ１５０５において、管理ソフトウェア６００は、ホスト・ストレージボリューム管理テーブル１６００の第ｉ行を最終行に移動する。この処理の後、第ｉ行には、それまで第ｉ＋１行だった行がシフトしているので、ステップ１５０６でｉをインクリメントする必要はなく、ステップ１５０７に移るだけでよい。

ステップ１５０６において、管理ソフトウェア６００は、処理対象をホスト・ストレージボリューム管理テーブル１６００の次行に移すため、ｉをインクリメントする。

管理ソフトウェア６００は、ステップ１５０５または１５０６を実行した後、繰り返し処理のため、ｎをインクリメントし（ステップ１５０７）、ステップ１５０３に移る。

ステップ１５０３において変数ｎがホスト・ストレージボリューム管理テーブル１６００の行数以上と判定された場合、管理ソフトウェア６００は優先順位決定処理を終了する（ステップ１５０８）。この段階で、ホスト・ストレージボリューム管理テーブル１６００の行は優先順位降順にソートされている。すなわち、先頭の行に登録されたボリュームの優先順位が最も高く、末尾の行に登録されたボリュームの優先順位が最も低い。

ここで、図１１に示したホスト・ストレージボリューム管理テーブル１６００を参照して、図１５の優先順位決定処理の具体例を説明する。なお、記載を簡略化するため、ここでは例えばホストボリュームＩＤ列１６０１の値「１」によって識別されるホストボリュームを「ホストボリューム１」、ストレージＩＤ列１６０３の値「ｓｔｏｒａｇｅ １」によって識別されるストレージ装置４００を「ストレージ装置１」、ストレージボリュームＩＤ列１６０４の値「Ｖｏｌ １」によって識別されるストレージボリュームを「ストレージボリューム１」、プールＩＤ列１６０５の値「ｐｏｏｌ １」によって識別されるボリュームプール７００を「ボリュームプール１」のように記載する。他のＩＤの値についても同様である。

ステップ１５０１において、ホスト・ストレージボリューム管理テーブル１６００の行がプール空容量列１６０６の値の順にソートされる。ホストボリューム１、２、３、４、５のプール空容量列１６０６の値がそれぞれ３００ＧＢ、１７５ＧＢ、１０２４ＧＢ、１０５ＧＢおよびＭＡＸ（すなわち登録可能な最大値）であるため、ソートの結果、ホストボリューム５、３、１、２、４の順に行が並ぶ。

その後、並べ替えられた各行について、ステップ１５０４の判定が行われる。例えば、ステップ１５０４において、ボリュームの空容量のしきい値として「２０ＧＢ」が使用された場合、ホストボリューム１の空容量がしきい値より小さい「１０ＧＢ」であるため、ホストボリューム１の行がホスト・ストレージボリューム管理テーブル１６００の最後尾に移動する（ステップ１５０５）。その結果、図１５の処理が終了した時点で、ホスト・ストレージボリューム管理テーブル１６００の行は、ホストボリューム５、３、２、４、１の順に並ぶ。

この場合、ホストボリューム５、３、２、４、１の優先順位がそれぞれ１、２、３、４、５となり、それらの値が書き込み先候補ボリューム管理テーブル１７００に登録される。すなわち、イメージファイル５０３の書き込み先としてホストボリューム５が選択され、その書き込みに失敗した場合に、次に順位が高いホストボリューム３が選択され、さらに失敗した場合には同様に順位に従ってホストボリュームが選択される。

上記のように、ステップ１５０１においてボリュームプール７００の空容量の順に行がソートされているため、より空容量が大きいボリュームプール７００に対応する仮想ボリュームがイメージファイル５０３の格納先として優先的に選択される。

なお、本実施形態では、ホスト計算機１００に割り当て可能な論理ボリューム７０２のプール空容量列１６０６として、その項目に登録可能な最大値が登録される。図１１の例では、ホストボリューム５（すなわちストレージ装置２のストレージボリューム３）がこのような論理ボリューム７０２に相当する。このため、ストレージ装置４００に仮想ボリューム７０１とホスト計算機１００に割り当て可能な論理ボリューム７０２とが混在する場合、ステップ１５０１のソートの結果、論理ボリューム７０２の優先順位は仮想ボリューム７０１のそれより必ず高くなる。これは、一般に、論理ボリューム７０２へのＩ／Ｏが仮想ボリューム７０１へのＩ／Ｏより高速に処理されるため、それらが混在する場合には論理ボリューム７０２を優先的に選択することによって仮想マシン５００およびストレージ装置４０１の性能を確保することを意図している。仮想ボリューム７０１へのＩ／Ｏを実行するためには、仮想ボリューム７０１とボリュームプール７００内の論理ボリューム７０２とのマッピングを参照し、必要があれば割り当てを実行しなければならないが、ホスト計算機１００に直接割り当てられた論理ボリューム７０２へのＩ／Ｏを実行するためにはそのような参照および割り当ての処理が不要となるためである。

また、ステップ１５０４から１５０５において、イメージファイル５０３の格納先として望ましくないボリューム（例えば空容量が小さいボリュームまたはＩ／Ｏが混雑したボリューム）の優先順位が下げられるため、そのようなボリュームは、イメージファイル５０３の格納先として選択されにくい。

以上のように、本実施形態によれば、ボリュームプール間でのリソース使用量の偏り発生を防止することができ、その結果、ストレージ側でのプール間データコピーの回数を減らすことができる。

＜第２の実施形態＞

図１から図１２、図１５から図１７、および図１９から図２１に基づいて、本発明に従う第２の実施形態について説明する。本実施形態と第１の実施形態の相違は、管理者１４００の観点から、管理者１４００がファイル作成を伴う操作を実行するソフトウェアモジュールが異なる点である。第１の実施形態においては、管理者１４００はハイパーバイザ５０１上でファイル作成を伴う操作を実行したが、本実施形態においては、管理者１４００は管理ソフトウェア６００上でファイル作成を伴う操作を実行する。これに伴い、本実施形態の管理ソフトウェア６００、ハイパーバイザ５０１、および追加モジュール５０２の動作が、第１の実施形態のものと異なる。

本実施形態におけるシステム構成は、第１の実施形態において、図１から図５を用いて説明したものと同様である。また、各ソフトウェアモジュールの役割は、管理ソフトウェア６００、ハイパーバイザ５０１、および追加モジュール５０２を除いて、第１の実施形態と同様である。図６から図１２に示す第１の実施形態の概念図および管理テーブルは、本実施形態にも適用される。また、本実施形態の管理ソフトウェア６００は、第１の実施形態と同様、図１５に示す書き込み先候補ボリューム管理テーブル１７００の優先順位決定の処理を実行する。本実施形態の管理ソフトウェア６００、ハイパーバイザ５０１、追加モジュール５０２の役割の、第１の実施形態との相違については、後述する。

図１６は、本発明の第２の実施形態の管理ソフトウェア６００がハイパーバイザ５０１および各ストレージ装置４００の構成情報を取得し、管理ソフトウェア６００が書き込み先候補ボリューム管理テーブル１７００を保持するまでの処理を示したシーケンス図である。

ステップ１８００からステップ１８０５は、実施例１のステップ１３００からステップ１３０５と同様であるため、説明を省略する。

本実施形態では、ステップ１８０６において、管理ソフトウェア６００が、書き込み先候補ボリューム管理テーブル１７００を保持する。本処理は、書き込み先候補ボリューム管理テーブル１７００の更新のために、必要に応じて繰り返し実行される。なお本実施形態において、追加モジュール５０２はハイパーバイザ５０１上のインターフェースとして動作し、独立した処理は実行しない。

図１７は、本発明の第２の実施形態において、管理者１４００が管理ソフトウェア６００上でファイル作成操作を行い、管理ソフトウェア６００がインターフェース（追加モジュール５０２）を通して、各ストレージ装置４００の指定ボリュームにファイルを書き込むまでの処理を示したシーケンス図である。

なお、この処理の前に、管理ソフトウェア６００等が図１６に示す処理を実行し、書き込み先候補ボリューム管理テーブル１７００を作成しておく必要がある。

最初に、管理者１４００が管理ソフトウェア６００上で、ファイル作成操作を行う（ステップ１９００）。なお、ファイル作成操作とは、第１の実施形態において説明したとおり、「仮想マシン５００の新規作成」または「仮想マシン５００に新たにディスクイメージを追加する」等の、イメージファイル５０３の新規作成を伴う操作を指す。ただし、本実施形態のファイル作成操作は、ハイパーバイザ５０１上ではなく管理ソフトウェア６００上で行われる。

次に、管理ソフトウェア６００が、ファイル作成処理を実行し、イメージファイル５０３を、管理サーバ２００上のメモリ２１１またはストレージデバイス２１３上に保持する（ステップ１９０１）。

次に、管理ソフトウェア６００が、書き込み先候補ボリューム管理テーブル１７００を用いて、書き込み先ボリュームを決定する（ステップ１９０２）。管理ソフトウェア６００は、基本的には優先順位の最高位のボリュームを選択し、Ｉ／Ｏエラーまたは容量不足等に起因する書き込み失敗時に、順次、下位順位のボリュームを選択する。

次に、管理ソフトウェア６００が、ステップ１９０２で決定したボリュームを指定し、ハイパーバイザ５０１上のインターフェースである追加モジュール５０２を通して、ハイパーバイザ５０１にファイルを送信する（ステップ１９０３）。なお、管理ソフトウェア６００は、ボリュームを指定せずにファイルを送信してもよい。この場合、ステップ１９０４に記載の追加処理が行われる。

次に、ハイパーバイザ５０１が、ステップ１９０３において受信したファイルを、指定されたボリュームに書き込む（ステップ１９０４）。本実施形態において、追加モジュール５０２は、書き込むべきファイルと、そのファイルの書き込み先のボリュームの指定と、を受信した場合に、そのファイルを指定されたボリュームに書き込むためのインターフェースである。

なお、ステップ１９０３で、ボリュームを指定せずにファイルが送信された場合は、ハイパーバイザ５０１が優先順位に関係なくいずれかのボリュームにファイルを書き込む。以下、ステップ１９０３で、ボリュームを指定せずにファイルが送信された場合追加処理について説明する。

管理ソフトウェア６００は、ハイパーバイザ５０１にホスト側構成情報を要求し、図２１に示すようなイメージファイル列２１０５を含むホストボリューム管理テーブル２１０６を取得する。

図２１は、本発明の第２の実施形態のハイパーバイザ５０１が保持するホストボリューム管理テーブル２１０６の一例を示す説明図である。

ホストボリューム管理テーブル２１０６のホストボリュームＩＤ列２１０１〜空容量列２１０４は、ホストボリューム管理テーブル２１００（図１９）の対応する列と同様であるため、説明を省略する。ホストボリューム管理テーブル２１０６のイメージファイル列２１０５には、ホストボリュームに格納されるイメージファイル５０３のファイル名が登録されている。

管理ソフトウェア６００は、イメージファイル列２１０５を検索し、ステップ１９０４においてファイルの作成されたボリュームを特定する。特定したボリュームが、書き込み先候補ボリューム管理テーブル１７００における優先順位が低いボリュームである場合に、管理ソフトウェア６００は、管理者１４００に対して、警告を提示する。なお、優先順位の低さの判定は、第１の実施形態と同様に実行されてもよい。例えば、上位１０パーセント以下の優先順位、１０位以下の優先順位、または、管理者１４００が定義した順位より低い優先順位を、低い優先順位と判定してもよい。以上が、ステップ１９０３で、ボリュームを指定せずにファイルを送信した場合についての説明である。

以上の第２の実施形態によれば、管理者１４００が管理ソフトウェア６００上でファイル作成操作を行った場合にも、第１の実施形態と同様の効果を得ることができる。

＜第３の実施形態＞

図１から図１２、図１４、図１５、および図１８から図２０に基づいて、本発明に従う第３の実施形態について説明する。なお本実施形態と第１の実施形態との相違は、第１の実施形態において管理ソフトウェア６００が実行する処理を、本実施形態においては追加モジュール５０２が実行する点である。これに伴い、本実施形態の追加モジュール５０２の動作は、第１の実施形態のものと異なる。

本実施形態におけるシステム構成は、第１の実施形態において図１から図５を用いて説明したものと、管理サーバ２００およびＬＡＮ３０１を必要としない点を除いて同様である。また、各ソフトウェアモジュールの役割は、追加モジュール５０２を除いて、第１の実施形態と同様である。図６から図１２に示す第１の実施形態の概念図および管理テーブルは、本実施形態にも適用される。ただし、本実施形態は、管理サーバ２００上の管理ソフトウェア６００を必要としない。図１４に示すファイル作成処理時の処理を実行するためには、追加モジュール５０２等が事前に図１８に示す処理を実行し、追加モジュール５０２が書き込み先候補ボリューム管理テーブル１７００を保持しておく必要がある。また、図１５に示す処理も第１の実施形態と同様に実行される。ただし、ステップ１４０５において、追加モジュール５０２が書き込み先を制御せず、管理者１４００に対して警告を提示する場合、警告の提示は、ハイパーバイザ５０１によって実行される。

図１８は、本発明の第３の実施形態の追加モジュール５０２が、ハイパーバイザ５０１および各ストレージ装置４００の構成情報を取得し、書き込み先候補ボリューム管理テーブル１７００を保持するまでの処理を示したシーケンス図である。

なお、この処理は、書き込み先候補ボリューム管理テーブル１７００の更新のために、必要に応じて繰り返し実行される。

最初に、追加モジュール５０２は、ハイパーバイザ５０１に対してホスト側構成情報の送信を要求する（ステップ２０００）。

次に、追加モジュール５０２は、ハイパーバイザ５０１からホスト側構成情報を受信する（ステップ２００１）。取得する構成情報は、ホストボリューム管理テーブル２１００に含まれる情報項目である。なお、取得した構成情報に上記以外の情報が含まれていてもよい。また、追加モジュール５０２の要求なしに、ハイパーバイザ５０１が構成情報を送信してもよい。

次に、追加モジュール５０２は、各ストレージ装置４００に対してストレージ側構成情報の送信を要求する（ステップ２００２）。

次に、追加モジュール５０２は、各ストレージ装置４００からストレージ側構成情報を受信する（ステップ２００３）。取得する構成情報は、各ストレージ装置４００の識別子（ストレージＩＤ）、およびストレージボリューム管理テーブル２２００に含まれる情報項目である。取得した構成情報に上記以外の情報が含まれていてもよい。なお、ステップ２００２とステップ２００３において、要求の発行および返信を実行するために、ＳＣＳＩ Ｉｎｑｕｉｒｙを利用してもよい。この場合、追加モジュール５０２はＳＣＳＩ Ｉｎｑｕｉｒｙを発行して構成情報を要求し、各ストレージ装置４００はＩｎｑｕｉｒｙ ＤａｔａのＶｅｎｄｏｒ−ｓｐｅｃｉｆｉｃ領域に構成情報を格納して返送する。

次に、追加モジュール５０２が、ホストボリューム管理テーブル２１００およびストレージボリューム管理テーブル２２００をもとに、ホスト・ストレージボリューム管理テーブル１６００を作成する（ステップ２００４）。作成方法は第１の実施形態と同様であり、ホストボリューム管理テーブル２１００の行と、ストレージボリューム管理テーブル２２００の行とを比較し、ストレージＩＤ列２１０２およびストレージボリュームＩＤ列２１０３が一致する行を結合することによってホスト・ストレージボリューム管理テーブル１６００の各行が作成される。

次に、追加モジュール５０２が、図１５に示した処理によって、書き込み先候補ボリュームの優先順位を決定する（ステップ２００５）。

次に、追加モジュール５０２が、書き込み先候補ボリューム管理テーブル１７００を保持する（ステップ２００６）。

以上の第３の実施形態によれば、管理サーバ２００を備えない計算機システムにおいても、第１の実施形態と同様の効果を得ることができる。

１００ ホスト計算機
２００ 管理サーバ
３００ ＳＡＮ
３０１ ＬＡＮ
４００ ストレージ装置
５００ 仮想マシン
５０１ ハイパーバイザ
５０２ 追加モジュール
５０３ イメージファイル
６００ 管理ソフトウェア
７００ ボリュームプール
７０１ 仮想ボリューム
７０３ 論理ボリューム

Claims (14)

1. 一つ以上の記憶装置と、前記記憶装置に接続される一つ以上のホスト計算機と、を備える計算機システムであって、
   前記ホスト計算機は、前記記憶装置に接続される第１インターフェースと、前記第１インターフェースに接続される第１プロセッサと、前記第１プロセッサに接続される第１記憶デバイスと、を含み、
   前記第１プロセッサは、各々が一つ以上のアプリケーションを実行する一つ以上の仮想マシンを制御し、
   前記記憶装置は、
   前記ホスト計算機に接続されるコントローラと、前記コントローラに接続される一つ以上の物理記憶デバイスと、を含み、
   複数の仮想ボリュームと、各々が前記物理記憶デバイスの実記憶領域を含む複数のプールと、を対応付ける情報を保持し、
   前記ホスト計算機から書き込み先のボリュームとして前記仮想ボリュームが指定されたデータの書き込み要求を受信した場合、書き込み先の前記仮想ボリュームに対応する前記プールに含まれる前記実記憶領域を前記書き込み先の仮想ボリュームに割り当てて、当該データを前記割り当てられた実記憶領域に格納し、
   前記各プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量を示す情報を保持し、
   前記計算機システムは、
   まだ前記仮想ボリュームに割り当てられていない実記憶領域の量に基づいて、前記ホスト計算機による書き込み先としての前記ボリュームの優先順位を決定し、
   決定した前記優先順位を保持することを特徴とする計算機システム。
2. 請求項１に記載の計算機システムであって、
   前記計算機システムは、前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定することを特徴とする計算機システム。
3. 請求項２に記載の計算機システムであって、
   前記計算機システムは、
   ファイル作成指示が入力された場合、前記優先順位が最も高い前記ボリュームを書き込み先として指定し、前記書き込み先として指定されたボリュームへのファイルの書き込みを実行し、
   前記書き込み先として指定されたボリュームへのファイルの書き込みに失敗した場合、前記書き込み先として指定されたボリュームの次に前記優先順位が高い前記ボリュームを新たな書き込み先として指定することを特徴とする計算機システム。
4. 請求項３に記載の計算機システムであって、
   前記ホスト計算機および前記記憶装置は、第１ネットワークを介して相互に接続され、
   前記計算機システムは、第２ネットワークを介して前記ホスト計算機及び前記記憶装置に接続される管理計算機をさらに備え、
   前記管理計算機は、
   前記第２ネットワークに接続される第２インターフェースと、前記第２インターフェースに接続される第２プロセッサと、前記第２プロセッサに接続される第２記憶デバイスと、を含み、
   前記第２ネットワークを介して、前記記憶装置から、前記各プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量を示す情報を取得し、
   前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定し、
   前記決定した優先順位を保持し、
   前記ファイル作成指示を入力されると、ファイルを作成し、前記作成されたファイルに加えて、前記作成されたファイルの書き込み先を指定する情報として、前記優先順位が最も高い前記仮想ボリュームを識別する情報を前記ホスト計算機に送信し、
   前記第１プロセッサは、前記第１記憶デバイスに格納された仮想マシン制御プログラムを実行することによって、前記一つ以上の仮想マシンを制御し、
   前記仮想マシン制御プログラムは、ファイル及び当該ファイルの書き込み先を指定する情報を入力されると、当該指定された書き込み先に当該ファイルを書き込む処理を前記第１プロセッサに実行させ、
   前記ホスト計算機は、前記仮想マシン制御プログラムに従って、前記管理計算機から受信したファイルを、前記管理計算機によって指定されたボリュームに書き込むことを特徴とする計算機システム。
5. 請求項４に記載の計算機システムであって、
   前記記憶装置は、さらに、予め前記実記憶領域が割り当てられ、かつ、前記プールに対応付けられていない一つ以上の論理ボリュームを管理し、
   前記ホスト計算機は、前記各仮想ボリュームの空き容量を示す情報を保持し、
   前記管理計算機は、
   前記第２ネットワークを介して、前記ホスト計算機から、前記各仮想ボリュームの空き容量を示す情報を取得し、
   前記一つ以上の論理ボリュームのうち空き容量が所定の閾値より大きいものの順位がいずれの前記仮想ボリュームの順位より高くなり、空き容量が所定の閾値より大きい仮想ボリュームの順位が、前記空き容量が前記所定の閾値より小さい仮想ボリュームの順位より高くなり、かつ、前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定することを特徴とする計算機システム。
6. 請求項３に記載の計算機システムであって、
   前記ホスト計算機および前記記憶装置は、第１ネットワークを介して相互に接続され、
   前記計算機システムは、第２ネットワークを介して前記ホスト計算機及び前記記憶装置に接続される管理計算機をさらに備え、
   前記管理計算機は、
   前記第２ネットワークに接続される第２インターフェースと、前記第２インターフェースに接続される第２プロセッサと、前記第２プロセッサに接続される第２記憶デバイスと、を含み、
   前記第２ネットワークを介して、前記記憶装置から、前記各プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量を示す情報を取得し、
   前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定し、
   前記決定した優先順位を示す情報を前記ホスト計算機に送信し、
   前記第１プロセッサは、前記第１記憶デバイスに格納された仮想マシン制御プログラムを実行することによって、前記一つ以上の仮想マシンを制御し、
   前記ホスト計算機は、
   前記第１記憶デバイスに格納され、前記第１プロセッサによって実行される追加プログラムをさらに含み、
   前記管理計算機から受信した前記優先順位を示す情報を保持し、
   前記ファイル作成指示を入力されると、前記仮想マシン制御プログラムに従ってファイルを作成し、
   前記追加プログラムに従って、前記作成されたファイルを、前記優先順位が最も高い前記ボリュームに書き込むことを特徴とする計算機システム。
7. 請求項３に記載の計算機システムであって、
   前記ホスト計算機および前記記憶装置は、第１ネットワークを介して相互に接続され、
   前記第１プロセッサは、前記第１記憶デバイスに格納された仮想マシン制御プログラムを実行することによって、前記一つ以上の仮想マシンを制御し、
   前記ホスト計算機は、
   前記第１記憶デバイスに格納され、前記第１プロセッサによって実行される追加プログラムをさらに含み、
   前記追加プログラムに従って、前記第１ネットワークを介して、前記記憶装置から、前記各プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量を示す情報を取得し、
   前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定し、
   前記決定した優先順位を保持し、
   前記ファイル作成指示を入力されると、前記仮想マシン制御プログラムに従ってファイルを作成し、
   前記追加プログラムに従って、前記作成されたファイルを、前記優先順位が最も高い前記ボリュームに書き込むことを特徴とする計算機システム。
8. 請求項７に記載の計算機システムであって、前記ホスト計算機は、前記追加プログラムに従う前記第１ネットワークを介した前記記憶装置との通信に、ＳＣＳＩ Ｉｎｑｕｉｒｙを用いることを特徴とする計算機システム。
9. 請求項２に記載の計算機システムであって、
   前記計算機システムは、ファイル作成指示が入力された場合、前記ファイル作成指示に従っていずれかの前記ボリュームへのファイルの書き込みを実行し、前記ファイルが書き込まれたボリュームの前記優先順位が所定の順位より低い場合、警告を出力することを特徴とする計算機システム。
10. 一つ以上の記憶装置と、前記記憶装置に接続される一つ以上のホスト計算機と、を備える計算機システムであって、
    前記ホスト計算機は、前記記憶装置に接続される第１インターフェースと、前記第１インターフェースに接続される第１プロセッサと、前記第１プロセッサに接続される第１記憶デバイスと、を含み、
    前記第１プロセッサは、各々が一つ以上のアプリケーションを実行する一つ以上の仮想マシンを制御し、
    前記記憶装置は、
    前記ホスト計算機に接続されるコントローラと、前記コントローラに接続される一つ以上の物理記憶デバイスと、を含み、
    複数の仮想ボリュームと、各々が前記物理記憶デバイスの実記憶領域を含む複数のプールと、を対応付ける情報を保持し、
    前記ホスト計算機から書き込み先のボリュームとして前記仮想ボリュームが指定されたデータの書き込み要求を受信した場合、書き込み先の前記仮想ボリュームに対応する前記プールに含まれる前記実記憶領域を前記書き込み先の仮想ボリュームに割り当てて、当該データを前記割り当てられた実記憶領域に格納し、
    前記各プールへのＩ／Ｏ量を示す情報を保持し、
    前記計算機システムは、
    前記プールへのＩ／Ｏ量が少ないほど、当該プールに対応する前記仮想ボリュームの順位が高くなるように、前記ホスト計算機による書き込み先としての前記ボリュームの優先順位を決定し、
    決定した前記優先順位を保持することを特徴とする計算機システム。
11. 一つ以上の記憶装置と、前記記憶装置に接続される一つ以上のホスト計算機と、を備える計算機システムの制御方法であって、
    前記ホスト計算機は、前記記憶装置に接続される第１インターフェースと、前記第１インターフェースに接続される第１プロセッサと、前記第１プロセッサに接続される第１記憶デバイスと、を含み、
    前記第１プロセッサは、各々が一つ以上のアプリケーションを実行する一つ以上の仮想マシンを制御し、
    前記記憶装置は、
    前記ホスト計算機に接続されるコントローラと、前記コントローラに接続される一つ以上の物理記憶デバイスと、を含み、
    複数の仮想ボリュームと、各々が前記物理記憶デバイスの実記憶領域を含む複数のプールと、を対応付ける情報を保持し、
    前記ホスト計算機から書き込み先のボリュームとして前記仮想ボリュームが指定されたデータの書き込み要求を受信した場合、書き込み先の前記仮想ボリュームに対応する前記プールに含まれる前記実記憶領域を前記書き込み先の仮想ボリュームに割り当てて、当該データを前記割り当てられた実記憶領域に格納し、
    前記各プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量を示す情報を保持し、
    前記制御方法は、
    まだ前記仮想ボリュームに割り当てられていない実記憶領域の量に基づいて、前記ホスト計算機による書き込み先としての前記ボリュームの優先順位を決定する第１手順と、
    決定した前記優先順位を保持する第２手順と、を含むことを特徴とする計算機システムの制御方法。
12. 請求項１１に記載の計算機システムの制御方法であって、
    前記第１手順は、前記プールに含まれる実記憶領域のうち、まだ前記仮想ボリュームに割り当てられていない実記憶領域の量が多いほど、当該プールに対応する前記仮想ボリュームの順位が高くなるよう、前記優先順位を決定する手順を含むことを特徴とする計算機システムの制御方法。
13. 請求項１２に記載の計算機システムの制御方法であって、
    ファイル作成指示が入力された場合、前記優先順位が最も高い前記ボリュームを書き込み先として指定し、前記書き込み先として指定されたボリュームへのファイルの書き込みを実行する第３手順をさらに含み、
    前記第３手順は、前記書き込み先として指定されたボリュームへのファイルの書き込みに失敗した場合、前記書き込み先として指定されたボリュームの次に前記優先順位が高い前記ボリュームを新たな書き込み先として指定する手順をさらに含むことを特徴とする計算機システムの制御方法。
14. 一つ以上の記憶装置と、前記記憶装置に接続される一つ以上のホスト計算機と、を備える計算機システムの制御方法であって、
    前記ホスト計算機は、前記記憶装置に接続される第１インターフェースと、前記第１インターフェースに接続される第１プロセッサと、前記第１プロセッサに接続される第１記憶デバイスと、を含み、
    前記第１プロセッサは、各々が一つ以上のアプリケーションを実行する一つ以上の仮想マシンを制御し、
    前記記憶装置は、
    前記ホスト計算機に接続されるコントローラと、前記コントローラに接続される一つ以上の物理記憶デバイスと、を含み、
    複数の仮想ボリュームと、各々が前記物理記憶デバイスの実記憶領域を含む複数のプールと、を対応付ける情報を保持し、
    前記ホスト計算機から書き込み先のボリュームとして前記仮想ボリュームが指定されたデータの書き込み要求を受信した場合、書き込み先の前記仮想ボリュームに対応する前記プールに含まれる前記実記憶領域を前記書き込み先の仮想ボリュームに割り当てて、当該データを前記割り当てられた実記憶領域に格納し、
    前記各プールへのＩ／Ｏ量を示す情報を保持し、
    前記制御方法は、
    前記プールへのＩ／Ｏ量が少ないほど、当該プールに対応する前記仮想ボリュームの順位が高くなるように、前記ホスト計算機による書き込み先としての前記ボリュームの優先順位を決定する第１手順と、
    決定した前記優先順位を保持する第２手順と、を含むことを特徴とする計算機システムの制御方法。

Images