JP2019192006A - リソース管理装置及びリソース管理プログラム - Google Patents

Abstract

【課題】ユーザが要求する性能に適したＶＭを提供すること。【解決手段】リソース管理装置１は、受付部１１と、受付情報記憶部１２と、決定部１６と、提供部２０とを有する。受付部１１は、ユーザからＶＭの使用用途と必要スコアとストレージ容量を受け付けて受付情報記憶部１２に格納する。そして、決定部１６は、受付情報記憶部１２から使用用途と必要スコアとストレージ容量を読み出してリソース構成を決定し、ＶＭを構築する。提供部２０は、構築されたＶＭをユーザに提供する。【選択図】図５

Description

本発明は、リソース管理装置及びリソース管理プログラムに関する。

クラウドサービスでは、クラウドシステムのリソース群を管理するリソース管理装置は、コンポーネント単位でユーザにリソースを割り当てる。コンポーネントとしては、ＣＰＵ（Central Processing Unit）、メモリ、ストレージ、グラフィックカードがある。

ユーザは、ＣＰＵをコア数で指定し、メモリをｘギガバイト等の量で指定し、ストレージをｙテラバイト等の量で指定し、グラフィックカードをグラフィックカード名で指定する。

図１４は、従来のリソース指定を説明するための図である。図１４では、メモリはＤＩＭＭ（Dual Inline Memory Module）で表される。図１４に示すように、ユーザは、リソース管理装置９に対して、コンポーネントを指定する。リソース管理装置９は、指定されたコンポーネントに基づいてＶＭ（Virtual Machine：仮想マシン）を構築してユーザへ提供する。

なお、従来技術として、コンピュータリソースサービスのコンピュータシステム上で試験仮想マシンを始動し、試験仮想マシンの性能を経時的に示した種々のメトリックを監視することで、コンピュータリソースサービスの性能をリアルタイムで監視する技術がある。

また、従来技術として、仮想共有ストレージを有する仮想デスクトップインフラストラクチャのプロビジョニングを容易にする技術がある。この技術では、プロビジョニングマネージャが、デスクトッププールの種類を受け取り、あるクラスタのホスト間に仮想共有ストレージをプロビジョンする。また、プロビジョニングマネージャは、デスクトッププールの種類に基づいて仮想共有ストレージを構成し、ホストクラスタ内の各ホストに少なくとも１つの仮想マシンをプロビジョンする。そして、プロビジョニングマネージャは、各ホストからのストレージパフォーマンスベンチマークを受け取る。そして、プロビジョニングマネージャは、ストレージパフォーマンスベンチマークの結果が所定の許容範囲内で閾値を満たさない場合、そのホストクラスタに最適化を実行することによって仮想共有ストレージを最適化する。

特表２０１６−５２２９４７号公報 特表２０１５−５１８９９７号公報

図１４に示した従来のリソース指定には、ユーザが要求する性能に適したＶＭが構築されないという問題がある。クラウドシステムのリソース群には、様々な性能のＣＰＵ、メモリ、ストレージ等が含まれ、ＣＰＵのコア数、メモリ量、ストレージ量及びグラフィックカードだけでは、構築されるＶＭの性能は決定されない。また、構築されるＶＭの性能は、個々のコンポーネントが有する単一性能だけでなく、コンポーネント間で連携して動作した際の性能に影響を受ける。

本発明は、１つの側面では、ユーザが要求する性能に適したＶＭを提供することを目的とする。

１つの態様では、リソース管理装置は、受付部と決定部とを有する。前記受付部は、ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付ける。前記決定部は、前記受付部により受け付けられた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する。

１つの側面では、本発明は、ユーザが要求する性能に適したＶＭを提供することができる。

図１は、ベンチマークスコアの出力例を示す図である。 図２は、項目のベンチマークスコアの計算方法を説明するための図である。 図３は、実施例１に係るリソース管理装置によるリソース割り当て方法を説明するための図である。 図４は、実施例１に係るクラウドシステムの構成を示す図である。 図５は、リソース管理装置の機能構成を示す図である。 図６は、予測情報記憶部の一例を示す図である。 図７は、ＶＭの再構築、スコアの測定及びスコアの比較の繰り返しによる性能レベル探索を説明するための図である。 図８は、リソース管理装置による処理のフローを示すフローチャートである。 図９は、ＶＭ構築処理のフローを示すフローチャートである。 図１０は、比較処理のフローを示すフローチャートである。 図１１は、実施例２に係る構築部によるＶＭ構築処理のフローを示すフローチャートである。 図１２は、調整コンポーネントの例を示す図である。 図１３は、実施例１及び２に係るリソース管理プログラムを実行するコンピュータのハードウェア構成を示す図である。 図１４は、従来のリソース指定を説明するための図である。

以下に、本願の開示するリソース管理装置及びリソース管理プログラムの実施例を図面に基づいて詳細に説明する。なお、実施例は開示の技術を限定するものではない。

実施例１に係るリソース管理装置は、ベンチマークスコアに基づいてリソースを割り当てる。そこで、まずベンチマークスコアについて図１〜図２を用いて説明する。図１は、ＳＰＥＣｗｐｃ（登録商標、以下同様）ベンチマークスコアの出力例を示す図である。ＳＰＥＣｗｐｃベンチマークスコアは、ワークステーション用の性能指標である。

図１に示すように、ＳＰＥＣｗｐｃベンチマークスコアは、Media and Entertainment、Product Development、Life Sciences、Financial Services、Energy、及び、General Operationsの６つの項目についての性能を示す。Media and Entertainmentは、動画作成・編集等の用途で用いられ、Product Developmentは、ＣＡＤ、流体計算等の用途で用いられ、Life Sciencesは、分子運動シミュレーション等の用途で用いられる。また、Financial Servicesは、オプションシミュレーション等の用途で用いられ、Energyは、地震断層シミュレーション等の用途で用いられ、General Operationsは、一般用途、ｚｉｐの解凍等の用途で用いられる。

各項目のベンチマークスコアは、複数のベンチマークプログラムのベンチマークスコアから計算される。例えば、Media and Entertainmentは、Blender、HandBrake、LuxRender、IOMeter、及び、Mayaのベンチマークスコアから計算される。

ベンチマークスコアは、一般のＷｅｂサイトに公開されており、主にユーザが装置を購入したり、リースやレンタルする際の装置の選定等に使用される。ユーザが今所有している装置のサポート終了にあたり装置を買い替えたい時、今の性能で満足している場合は、ユーザは同じベンチマークスコアの装置を購入すればよい。その際、どの項目のベンチマークスコアを参照するかはユーザの使用用途に基づいて決められる。

また、例えばＯＳ（Operating System）やアプリケーション等をそのままに、処理性能を倍にしたい（かかる時間を半分に減らしたい）場合は、ユーザはベンチマークスコアが２倍の装置を購入すればよい。ただし、ユーザが実際に使用するプログラムとベンチマークプログラムは同じではないので、ベンチマークスコアが２倍でも処理性能は必ずしも２倍にはならない。しかしながら、ベンチマークスコアは、高い精度でこのような性能換算を可能にする。

図２は、項目のベンチマークスコアの計算方法を説明するための図である。なお、以下では、「ベンチマークスコア」を単に「スコア」で表す。図２（ａ）に示すように、Media and Entertainmentのスコアの「３．１１」は、「１．１６＾（０．２）×１．２３＾（０．２）×１．２７＾（０．２）×７．３７＾（０．２）×２１．８４＾（０．２）」により計算される。ここで、ｐ＾ｑはｐ^qを表す。また、各ベンチマークプログラムのスコアは「１．１６」、「１．２３」、「１．２７」、「７．３７」及び「２１．８４」であり、各ベンチマークプログラムの重みは「０．２」で全て等しい。

Blender、HandBrake及びLuxRenderは、主にＣＰＵ系（ＣＰＵとＤＩＭＭ）に関係するベンチマークプログラムであり、IOMeterは、ＩＯ系（ストレージへの入出力）のベンチマークプログラムであり、Mayaは、ＧＦＸ系（グラフィックス）のベンチマークプログラムである。このため、図２（ａ）は、図２（ｂ）のように簡易的に表すこともできる。図２（ｂ）において、ＣＰＵ系の「１．２２」は、３つのスコアの幾何平均である。このように、Media and Entertainment等の項目のスコアは、ＣＰＵ系、ＧＦＸ系、ＩＯ系それぞれのスコアに影響を受ける。

図２（ｂ）に基づいて、ＣＰＵ系、ＧＦＸ系、ＩＯ系の比率を１：２０：６とすると、図２（ｂ）は、図２（ｃ）のように書き換えられる。図２（ｃ）から、Media and Entertainment等の項目のスコアが決まれば、ＣＰＵ系、ＧＦＸ系、ＩＯ系それぞれのスコアが決定される。すなわち、項目のスコアからｋを計算し、ＣＰＵ系、ＧＦＸ系、ＩＯ系それぞれのスコアを計算することができる。

次に、実施例１に係るリソース管理装置によるリソース割り当て方法について説明する。図３は、実施例１に係るリソース管理装置によるリソース割り当て方法を説明するための図である。

図３に示すように、リソース割り当てを要求するユーザは、使用用途と必要スコアを入力する（１、２）。実施例１に係るリソース管理装置１は、ユーザにより入力された使用用途と必要スコアに基づいてコンポーネント毎の必要スコアを計算し（３）、必要なコンポーネント構成を予測する（４）。なお、リソース管理装置１は、ＣＰＵとＤＩＭＭを１つのコンポーネントとして扱う。すなわち、リソース管理装置１は、ＣＰＵ系のスコアに基づいてＣＰＵ＋ＤＩＭＭの構成を予測し、ＧＦＸ系のスコアに基づいてＧＦＸカード（グラフィックカード）の構成を予測し、ＩＯ系のスコアに基づいてストレージの構成を予測する。

そして、リソース管理装置１は、予測したコンポーネント構成に基づいて、ＶＭを構築し（５）、構築したＶＭをベンチマークソフト入りＯＳ（Operating System）で起動する（６）。そして、リソース管理装置１は、ベンチマーク測定結果を取得し（７）、必要スコアと比較する（８）。

そして、リソース管理装置１は、ベンチマーク測定結果が必要スコアより小さい、又は必要以上に大きい場合、すなわち、ユーザの要求にマッチしない場合は、コンポーネント構成を変更し、ＶＭの構築に戻る。一方、ベンチマーク測定結果がユーザの要求にマッチする場合には、リソース管理装置１は、構築したＶＭをユーザに提供する（９）。

このように、リソース管理装置１は、使用用途と必要スコアに基づいてリソース構成を予測してＶＭを構築し、構築したＶＭをベンチマークソフト入りＯＳで起動してベンチマーク測定結果を取得する。そして、リソース管理装置１は、ベンチマーク測定結果がユーザの要求にマッチするまで、リソース構成を変更してＶＭの構築とベンチマーク測定結果の取得を繰り返す。したがって、リソース管理装置１は、ユーザが要求する性能に適したＶＭを提供することができる。

次に、実施例１に係るクラウドシステムの構成について説明する。図４は、実施例１に係るクラウドシステムの構成を示す図である。図４に示すように、実施例１に係るクラウドシステムは、リソース管理装置１と、ベンチマークＯＳストレージ２と、クラウドリソース群３とを有する。リソース管理装置１、ベンチマークＯＳストレージ２及びクラウドリソース群３は、ネットワーク４で接続される。ネットワーク４は、別のネットワーク５を介して、ユーザが使用するクライアントＰＣ６と接続される。

リソース管理装置１は、ユーザが要求する性能に適したリソース構成を特定し、特定したリソース構成のＶＭをユーザに提供する。ベンチマークＯＳストレージ２は、ベンチマークソフトがインストールされたＯＳイメージを記憶する。クラウドリソース群３には、サーバ３１を構成するＣＰＵ、ＤＩＭＭ、ＧＦＸカード及びストレージと、ストレージ装置３２を構成するストレージが含まれる。クラウドリソース群３に含まれるＣＰＵ、ＤＩＭＭ、ＧＦＸカード及びストレージの一部を用いてＶＭが構築される。

図５は、リソース管理装置１の機能構成を示す図である。図５に示すように、リソース管理装置１は、受付部１１と、受付情報記憶部１２と、算出情報記憶部１３と、予測情報記憶部１４と、リソース情報記憶部１５と、決定部１６と、測定部１７と、測定結果記憶部１８と、比較部１９と、提供部２０とを有する。

受付部１１は、ユーザがクライアントＰＣ６を用いて入力した使用用途、必要スコア及びストレージ容量を受け付け、受付情報記憶部１２に書き込む。なお、ストレージ容量は、ＶＭが使用するストレージの容量を決定するために用いられる。受付情報記憶部１２は、受付部１１が受け付けた使用用途、必要スコア及びストレージ容量をユーザ毎に記憶する。また、受付情報記憶部１２は、後述する算出部２１がコンポーネント毎に算出した必要スコアを記憶する。

算出情報記憶部１３は、受付部１１が受け付けた使用用途と必要スコアからコンポーネント毎の必要スコアを算出するための情報を記憶する。算出情報記憶部１３は、例えば、Media and Entertainmentについては、図２（ｃ）に示したスコア算出情報を記憶する。算出情報記憶部１３は、図２（ｃ）と同様の情報を他の項目についても記憶する。

予測情報記憶部１４は、ＣＰＵ、ＧＦＸ、ＩＯのそれぞれについて、構成毎のスコアを項目毎に記憶する。図６は、予測情報記憶部１４の一例を示す図である。図６に示すように、予測情報記憶部１４は、（ａ）ＣＰＵ性能・コンポーネント予測表、（ｂ）ＧＦＸ性能・コンポーネント予測表、及び、（ｃ）ＩＯ性能・コンポーネント予測表を記憶する。

ＣＰＵ性能・コンポーネント予測表はＣＰＵ性能について構成毎のスコアを項目毎に示し、ＧＦＸ性能・コンポーネント予測表はＧＦＸ性能について構成毎のスコアを項目毎に示し、ＩＯ性能・コンポーネント予測表はＩＯ性能について構成毎のスコアを項目毎に示す。

図６（ａ）に示すように、ＣＰＵ性能・コンポーネント予測表は、（ＣＰＵ＋ＤＩＭＭ）レベル、（ＣＰＵ＋ＤＩＭＭ）構成及び予想スコアを対応付ける。（ＣＰＵ＋ＤＩＭＭ）レベルは、ＣＰＵ性能のレベルである。レベルの値が大きいほどＣＰＵ性能が高い。（ＣＰＵ＋ＤＩＭＭ）構成は、ＣＰＵとＤＩＭＭの構成であり、ＣＰＵのＣｏｒｅの数、ＣＰＵの周波数、ＤＩＭＭの容量である。

予想スコアは、項目毎のスコアである。Ｍ＆ＥはMedia and Entertainmentを表し、ＰＤはProduct Developmentを表し、ＬＳはLife Sciencesを表し、ＦＳはFinancial Servicesを表し、ＥはEnergyを表しＧＯはGeneral Operationsを表す。

例えば、（ＣＰＵ＋ＤＩＭＭ）レベルが「５」である場合、ＣＰＵは「２Ｃｏｒｅ」で「中周波数」であり、ＤＩＭＭの容量は「８ＧＢ（ギガバイト）」である。また、Ｍ＆Ｅ、ＰＤ、ＬＳ、ＦＳ、Ｅ及びＧＯのスコアはそれぞれ「５．０」、「５．１」、「５．２」、「５．３」、「５．４」及び「５．５」である。

図６（ｂ）に示すように、ＧＦＸ性能・コンポーネント予測表は、ＧＦＸレベル、ＧＦＸカード構成及び予想スコアを対応付ける。ＧＦＸレベルは、ＧＦＸ性能のレベルである。レベルの値が大きいほどＧＦＸ性能が高い。ＧＦＸカード構成は、ＧＦＸカードの種類である。

例えば、ＧＦＸレベルが「５」である場合、ＧＦＸカードの種類は「ＧＦＸカードＥ」であり、Ｍ＆Ｅ、ＰＤ、ＬＳ、ＦＳ、Ｅ及びＧＯのスコアはそれぞれ「２１．１」、「２１．３」、「２１．５」、「２１．７」、「２１．９」及び「２２．１」である。

図６（ｃ）に示すように、ＩＯ性能・コンポーネント予測表は、ＩＯレベル、ストレージ構成及び予想スコアを対応付ける。ＩＯレベルは、ＩＯ性能のレベルである。レベルの値が大きいほどＩＯ性能が高い。ストレージ構成は、ストレージの種類である。

例えば、ＩＯレベルが「５」である場合、ストレージの種類は「ＰＣＩｅ ＳＳＤ」又は「ＳＳＤ×ｎ ｓｔｒｉｐｅ」であり、Ｍ＆Ｅ、ＰＤ、ＬＳ、ＦＳ、Ｅ及びＧＯのスコアはそれぞれ「５．９」、「５．８」、「５．７」、「５．６」、「５．５」及び「５．４」である。

図５に戻って、リソース情報記憶部１５は、所在場所、使用可否等のリソースに関する情報をリソース毎に記憶する。リソース情報記憶部１５は、ＣＰＵについては、Ｃｏｒｅ数、周波数等の情報を記憶する。リソース情報記憶部１５は、ＤＩＭＭについては、容量等の情報を記憶する。リソース情報記憶部１５は、ＧＦＸカードについては、カードの種類等の情報を記憶する。リソース情報記憶部１５は、ストレージについては、ストレージの種類等の情報を記憶する。

決定部１６は、受付情報記憶部１２、算出情報記憶部１３、予測情報記憶部１４及びリソース情報記憶部１５を用いて、ＶＭを構築するリソース構成を決定し、決定したリソース構成のＶＭを構築する。決定部１６は、算出部２１と、予測部２２と、構築部２３とを有する。

算出部２１は、受付情報記憶部１２から使用用途と必要スコアを読み出して、算出情報記憶部１３に基づいてコンポーネント毎の必要スコアを算出し、受付情報記憶部１２に格納する。

予測部２２は、コンポーネント毎に必要スコアを満たすコンポーネント構成を予測情報記憶部１４に基づいて予測する。すなわち、予測部２２は、ＣＰＵとＤＩＭＭについては、ＣＰＵの必要スコアより図６（ａ）の予想スコアが大きい構成の内、（ＣＰＵ＋ＤＩＭＭ）レベルが最小の（ＣＰＵ＋ＤＩＭＭ）構成を選択する。また、予測部２２は、ＧＦＸカードについては、ＧＦＸの必要スコアより図６（ｂ）の予想スコアが大きい構成の内、ＧＦＸレベルが最小のＧＦＸカード構成を選択する。また、予測部２２は、ストレージについては、ＩＯの必要スコアより図６（ｃ）の予想スコアが大きい構成の内、ＩＯレベルが最小のストレージ構成を選択する。

構築部２３は、予測部２２により選択された（ＣＰＵ＋ＤＩＭＭ）構成、ＧＦＸカード構成、ストレージ構成を用いてＶＭを構築できるか否かをリソース情報記憶部１５を参照して判定する。ＶＭを構築できない場合とは、例えば、予測部２２により選択されたリソースが使用可能でない場合、リソース間の距離が離れていて組み合わせることができない場合である。

そして、構築部２３は、ＶＭを構築できる場合には、ＶＭを構築する。一方、ＶＭを構築できない場合には、構築部２３は、（ＣＰＵ＋ＤＩＭＭ）レベル、ＧＦＸカードレベル及びストレージレベルの内、いずれかのレベルを上げることでＶＭを構築できるリソース構成を決定し、決定したリソース構成のＶＭを構築する。

測定部１７は、ベンチマークＯＳストレージ２から使用用途のＯＳイメージをロードしてＶＭを起動するように、ＶＭが構築されたサーバ３１に指示する。そして、ＶＭが起動されてベンチマークソフトが実行されると、測定部１７は、ベンチマークソフトが測定したコンポーネント毎の測定スコアをサーバ３１から取得し、測定結果記憶部１８に格納する。測定結果記憶部１８は、ベンチマークソフトが測定した測定スコアをコンポーネント毎に記憶する。

比較部１９は、測定結果記憶部１８がコンポーネント毎に記憶する測定スコアと受付情報記憶部１２がコンポーネント毎に記憶する必要スコアをそれぞれ比較して、構築部２３により構築されたＶＭがユーザの要求にマッチするか否かを判定する。そして、比較部１９は、構築部２３により構築されたＶＭがユーザの要求にマッチする場合には、ＶＭの構築を完了し、マッチしない場合には、コンポーネント毎に性能レベルを指定して構築部２３にＶＭの再構築を依頼する。ここで、性能レベルは、（ＣＰＵ＋ＤＩＭＭ）レベル、ＧＦＸレベル及びＩＯレベルである。

図７は、ＶＭの再構築、スコアの測定及びスコアの比較の繰り返しによる性能レベル探索を説明するための図である。図７（ａ）は、性能レベルを上げていくことでユーザの要求にマッチする性能レベルに到達する場合を示し、図７（ｂ）は、性能レベルを下げていくことでユーザの要求にマッチする性能レベルに到達する場合を示す。図７では、コンポーネントについてユーザが要求する必要スコアが「２３」であるとする。

図７（ａ）に示すように、最初の測定スコアが「２０」であり性能が不足している（１）と、比較部１９は、性能レベルを「１０」から「１１」に上げて、構築部２３にＶＭの再構築を依頼する。そして、再構築後の再測定の結果、測定スコアが「２２」になる。この測定スコアでは性能が不足している（２）ので、比較部１９は、性能レベルを「１１」から「１２」に上げて、構築部２３にＶＭの再々構築を依頼する。そして、再々構築後の再々測定の結果、測定スコアが「２４」になる。この測定スコアは、ユーザが要求するスコアの「２３」を上回るので、ユーザが要求する性能にマッチする（３）。したがって、性能レベルが「１２」である構成がユーザの要求にマッチする構成と判定される。

また、図７（ｂ）に示すように、最初の測定スコアが「２６」であり性能が過剰であると推定すると、比較部１９は、性能レベルを「１３」から「１２」に下げて、構築部２３にＶＭの再構築を依頼する。そして、再構築後の再測定の結果、測定スコアが「２４」になる。この測定スコアでは性能が過剰であると推定すると、比較部１９は、性能レベルを「１２」から「１１」に下げて、構築部２３にＶＭの再々構築を依頼する。そして、再々構築後の再々測定の結果、測定スコアが「２２」になる。この測定スコアは、ユーザが要求するスコアの「２３」を下回るので、前の測定スコアの「２４」がユーザが要求する性能にマッチする。したがって、性能レベルが「１２」である構成がユーザの要求にマッチする構成と判定される。

図５に戻って、提供部２０は、比較部１９がユーザの要求にマッチすると判定したＶＭをユーザに提供する。

なお、予測部２２は、コンポーネント毎の必要スコアに基づいてコンポーネント構成を予測するので、予測部２２が予測したコンポーネント構成に基づいてユーザにＶＭを提供することも考えられる。しかしながら、ＣＰＵ＋ＤＩＭＭ、ＧＦＸカード及びストレージの物理的位置（サーバ３１内の電気・電子回路配線上、又は、サーバ３１とストレージ装置３２とを繋ぐネットワーク上の物理的距離）には違いがあり、性能に違いが生じる。

例えば、ＣＰＵとストレージには、以下のような様々な接続形態があるため、ＣＰＵとストレージの物理的位置に違いがあると、ＩＯ性能が異なる。
・チップセットを介した接続
・ＲＡＩＤ（Redundant Arrays of Inexpensive Disks）カードを介した接続
・ネットワークカードから接続（ＳＡＮ）
・ＣＰＵのＰＣＩｅレーンに接続（ＰＣＩｅ−ＳＳＤ（Solid State Drive））
・インターコネクトで接続されたＣＰＵのＰＣＩｅレーンに接続（ＰＣＩｅ−ＳＳＤ）

また、コンポーネントの組合せによる性能の違いもある。例えば、ＩＯの場合、ＩＯベンチマークの大きな要因はストレージのスループット、レイテンシになるが、Ｒｅａｄ／Ｗｒｉｔｅする処理はＣＰＵが行うため、ＣＰＵの能力もＩＯベンチマークに影響する。特にＣＰＵ性能が低い場合は影響が比較的大きい。

このため、リソース管理装置１は、予測部２２が予測したリソース構成を初期構成として、リソース構成の変更とベンチマーク測定を繰り返しながらリソース構成を決定する。

次に、リソース管理装置１による処理のフローについて説明する。図８は、リソース管理装置１による処理のフローを示すフローチャートである。図８に示すように、リソース管理装置１は、ユーザから、使用用途と必要スコアを受け付け（ステップＳ１）、ストレージ容量を受け付ける（ステップＳ２）。

そして、リソース管理装置１は、ユーザから受け付けた使用用途と必要スコアに基づいて、コンポーネント毎の必要スコアを算出し（ステップＳ３）、コンポーネント構成を予測する（ステップＳ４）。そして、リソース管理装置１は、ＶＭの構築を行うＶＭ構築処理を実行し（ステップＳ５）、構築したＶＭをベンチマークソフト搭載ＯＳで起動する（ステップＳ６）。

そして、リソース管理装置１は、ベンチマークソフトにより測定された測定スコアを取得し（ステップＳ７）、比較処理を実行する（ステップＳ８）。ここで、比較処理とは、ユーザが要求する必要スコアと測定された測定スコアをコンポーネント毎に比較することで、構築したＶＭがユーザの要求にマッチするか否かを判定する処理である。

そして、リソース管理装置１は、構築したＶＭがユーザの要求にマッチするか否かを判定する（ステップＳ９）。リソース管理装置１は、ユーザの要求にマッチする（１）か否（０）かを示すコンポーネント毎の完了フラグが全て１か否かを判定することで、構築したＶＭがユーザの要求にマッチするか否かを判定する。各完了フラグは、比較処理で設定される。

そして、リソース管理装置１は、構築したＶＭがユーザの要求にマッチしない場合には、性能レベルを指定してステップＳ５に戻り、マッチした場合には、構築したＶＭをユーザに提供する（ステップＳ１０）。

このように、リソース管理装置１は、ユーザから受け付けた使用用途と必要スコアに基づいてＶＭを構築するので、ユーザの要求にマッチするＶＭを構築することができる。

次に、ＶＭ構築処理のフローについて説明する。図９は、ＶＭ構築処理のフローを示すフローチャートである。なお、ＶＭ構築処理は、ＣＰＵ＋ＤＩＭＭ、ＧＦＸカード、ストレージそれぞれに対して行われる。図９に示すように、構築部２３は、選択されたコンポーネントでＶＭを組むことができるか否かを判定し（ステップＳ２１）、ＶＭを組むことができる場合には、ＶＭを構築する（ステップＳ２２）。

一方、選択されたコンポーネントでＶＭを組むことができない場合には、構築部２３は、エラーカウントに１を加える（ステップＳ２３）。ここで、エラーカウントはＶＭを組むことができないと判定された回数であり、エラーカウントの初期値は０である。そして、構築部２３は、エラーカウントがｎより大きいか否かを判定し（ステップＳ２４）、ｎより大きい場合には、エラー終了する（ステップＳ２５）。ここで、ｎは、整数の閾値である。一方、エラーカウントがｎより大きくない場合には、構築部２３は、性能レベルに１を加え（ステップＳ２６）、ステップＳ２１へ戻る。

このように、構築部２３は、選択されたコンポーネントでＶＭを組むことができない場合に、性能レベルを上げることで、ＶＭを組むことができるコンポーネントを特定することができる。

次に、比較処理のフローについて説明する。図１０は、比較処理のフローを示すフローチャートである。図１０に示すように、比較部１９は、以下のステップＳ３１〜ステップＳ４１の処理をコンポーネントＩＤを１から３まで変化させて繰り返す。ここで、コンポーネントＩＤは、コンポーネントを識別する識別子である。ＣＰＵ＋ＤＩＭＭのコンポーネントＩＤは１であり、ＧＦＸカードのコンポーネントＩＤは２であり、ストレージのコンポーネントＩＤは３である。

比較部１９は、完了フラグが０であるか１であるかを判定し（ステップＳ３１）、１である場合には、次のコンポーネントを処理し、０である場合には、測定スコアは必要スコアより小さいか否かを判定する（ステップＳ３２）。

そして、比較部１９は、測定スコアが必要スコアより小さくない場合には、測定スコアは必要スコアよりａ以上大きいか否かを判定する（ステップＳ３３）。ここで、ａは性能が高すぎるか否かを判定するための閾値であり、測定スコアが必要スコアよりａ以上大きい場合は性能が高すぎる場合である。

そして、測定スコアが必要スコアよりａ以上大きくない場合には、比較部１９は、完了フラグを１にし（ステップＳ３４）、次のコンポーネントを処理する。一方、測定スコアが必要スコアよりａ以上大きい場合には、比較部１９は、下降中フラグが０であるか１であるかを判定する（ステップＳ３５）。ここで、下降中フラグは性能レベルを下げながらＶＭの再構築を行っているか否かを示すフラグであり、下降中フラグが１である場合は、性能レベルを下げながらＶＭの再構築を行っている場合である。

そして、下降中フラグが０である場合には、比較部１９は、上昇中フラグが０であるか１であるかを判定する（ステップＳ３６）。ここで、上昇中フラグは性能レベルを上げながらＶＭの再構築を行っているか否かを示すフラグであり、上昇中フラグが１である場合は、性能レベルを上げながらＶＭの再構築を行っている場合である。

そして、比較部１９は、上昇中フラグが０でない場合には、ステップＳ３４に移動し、上昇中フラグが０である場合には、下降中フラグを１に設定し、現在のコンポーネントを確保し、性能レベルを１下げる（ステップＳ３７）。そして、比較部１９は、次のコンポーネントを処理する。

また、ステップＳ３５において、下降中フラグが０でない場合には、比較部１９は、確保済みコンポーネントを解放し（ステップＳ３８）、ステップＳ３７に移動する。

また、ステップＳ３２において、測定スコアが必要スコアより小さい場合には、比較部１９は、下降中フラグが０であるか１であるかを判定し（ステップＳ３９）、０でない場合には、確保済みコンポーネントに確定し（ステップＳ４０）、ステップＳ３４に移動する。一方、下降中フラグが０である場合には、比較部１９は、上昇中フラグを１に設定し、性能レベルを１上げる（ステップＳ４１）。そして、比較部１９は、次のコンポーネントを処理する。

このように、比較部１９は、測定スコア、必要スコア、上昇中フラグ及び下降中フラグを用いて性能レベルを上下する必要があるか否かを判定することで、必要スコアにマッチするコンポーネントを特定することができる。

上述してきたように、実施例１では、受付部１１が、ユーザからＶＭの使用用途と必要スコアを受け付ける。そして、決定部１６が、受付部１１により受け付けられた使用用途と必要スコアに基づいてリソース構成を決定し、ＶＭを構築する。したがって、リソース管理装置１は、ユーザが要求する性能に適したＶＭを提供することができる。

また、実施例では、測定部１７が、決定部１６により決定されたリソース構成を用いてベンチマークプログラムを実行させ、測定スコアを取得する。そして、比較部１９が、必要スコアと測定スコアを比較して、ＶＭがユーザの要求にマッチするか否かを判定し、マッチしない場合には、決定部１６にＶＭを再構築させる。したがって、リソース管理装置１は、ユーザが要求する性能に正確にマッチするＶＭを提供することができる。

また、実施例では、算出部２１が、ＶＭの使用用途と必要スコアに基づいてコンポーネント毎の必要スコアを算出する。そして、予測部２２が、コンポーネント毎の必要スコアに基づいてコンポーネント構成を予測する。そして、構築部２３が、予測されたコンポーネント構成で実際にＶＭを構築できるか否かを判定し、ＶＭを構築できないと判定した場合に、コンポーネントの性能を上げることでコンポーネント構成を変更する。したがって、測定部１７は、決定部１６により決定されたコンポーネント構成を用いてベンチマークプログラムを実行させることができる。

ところで、上記実施例１では、構築部２３は、予測部２２により予測されたコンポーネントでＶＭが構築できない場合に、コンポーネントの性能レベルを上げることでコンポーネント構成を変更した。しかしながら、１つのコンポーネントの性能レベルを上げると、他のコンポーネントの性能レベルを下げることが考えられる。そこで、実施例２では、１つのコンポーネントの性能レベルを上げた場合に他のコンポーネントの性能レベルを調整する構築部２３について説明する。

図１１は、実施例２に係る構築部２３によるＶＭ構築処理のフローを示すフローチャートである。図１１に示すように、実施例２に係る構築部２３は、コンポーネントＩＤが１であるコンポーネントについて、再計算カウントを０に初期化する（ステップＳ５１）。ここで、再計算カウントは、性能レベルを上げる回数をカウントするためのものである。

そして、実施例２に係る構築部２３は、性能レベルに対応するコンポーネントがあるか否かを判定し（ステップＳ５２）、ある場合には、ステップＳ５１に戻り、次のコンポーネントについての処理を行う。また、３つのコンポーネントについて、性能レベルに対応するコンポーネントがある場合には、ＶＭを構築する（ステップＳ５３）。

一方、性能レベルに対応するコンポーネントがない場合には、実施例２に係る構築部２３は、コンポーネントの性能レベルに１を加え（ステップＳ５４）、性能レベルに対応するコンポーネントがあるか否かを判定する（ステップＳ５５）。そして、性能レベルに対応するコンポーネントがある場合には、実施例２に係る構築部２３は、調整コンポーネントの必要スコアを算出する（ステップＳ５６）。ここで、調整コンポーネントとは、性能レベルを上げたことを調整するためのコンポーネントであり、性能レベルを上げたコンポーネント以外の２つのコンポーネントである。

そして、実施例２に係る構築部２３は、調整コンポーネントの必要性能レベルを算出し（ステップＳ５７）、調整コンポーネントはあるか否かを判定する（ステップＳ５８）。そして、調整コンポーネントがある場合には、実施例２に係る構築部２３は、ステップＳ５３に移動する。

一方、２つの調整コンポーネントの内、１つでもない場合、あるいは、ステップＳ５５において性能レベルに対応するコンポーネントがない場合には、実施例２に係る構築部２３は、再計算カウントに１を加える（ステップＳ５９）。そして、実施例２に係る構築部２３は、再計算カウントがｎであるか否かを判定し（ステップＳ６０）、再計算カウントがｎでない場合には、ステップＳ５４に戻り、再計算カウントがｎである場合には、エラー終了する（ステップＳ６１）。

上述してきたように、実施例２では、構築部２３は、あるコンポーネントの性能レベルを上げた場合に、調整コンポーネントの必要スコアを再計算することで、不必要に性能が高いリソース構成でＶＭを構築することを防ぐことができる。図１２は、調整コンポーネントの例を示す図である。図１２に示すように、実施例２に係る構築部２３は、例えば、ＣＰＵ＋ＤＩＭＭの性能レベルを上げた場合に、ＧＦＸカードの性能レベルを下げる。

なお、構築部２３は、予測部２２で選択されたコンポーネントがない場合に、コンポーネントの性能レベルを上げる代わりに性能レベルを下げ、調整コンポーネントの性能レベルを上げてもよい。

また、実施例１及び２では、リソース管理装置１について説明したが、リソース管理装置１が有する構成をソフトウェアによって実現することで、同様の機能を有するリソース管理プログラムを得ることができる。そこで、リソース管理プログラムを実行するコンピュータについて説明する。

図１３は、実施例１及び２に係るリソース管理プログラムを実行するコンピュータのハードウェア構成を示す図である。図１３に示すように、コンピュータ５０は、メモリ５１と、プロセッサの一例であるＣＰＵ５２と、ＬＡＮ（Local Area Network）インタフェース５３と、ＨＤＤ（Hard Disk Drive）５４とを有する。また、コンピュータ５０は、スーパーＩＯ（Input Output）５５と、ＤＶＩ（Digital Visual Interface）５６と、ＯＤＤ（Optical Disk Drive）５７とを有する。

メモリ５１は、プログラムやプログラムの実行途中結果などを記憶するＲＡＭ（Random Access Memory）である。ＣＰＵ５２は、メモリ５１からプログラムを読み出して実行する中央処理装置である。ＣＰＵ５２は、メモリコントローラを有するチップセットを含む。

ＬＡＮインタフェース５３は、コンピュータ５０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ５４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ５５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ５６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ５７は、ＤＶＤ、ＣＤ−Ｒの読み書きを行う装置である。

ＬＡＮインタフェース５３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ５２に接続され、ＨＤＤ５４及びＯＤＤ５７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ５２に接続される。スーパーＩＯ５５は、ＬＰＣ（Low Pin Count）によりＣＰＵ５２に接続される。

そして、コンピュータ５０において実行されるリソース管理プログラムは、コンピュータ５０により読み出し可能な記録媒体の一例であるＣＤ−Ｒに記憶され、ＯＤＤ５７によってＣＤ−Ｒから読み出されてコンピュータ５０にインストールされる。あるいは、リソース管理プログラムは、ＬＡＮインタフェース５３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ５０にインストールされる。そして、インストールされたデータ処理プログラムは、ＨＤＤ５４に記憶され、メモリ５１に読み出されてＣＰＵ５２によって実行される。

また、実施例では、ＳＰＥＣｗｐｃベンチマークスコアを用いる場合について説明したが、リソース管理装置１は、他のベンチマークスコアを用いてもよい。
すなわち、

以上の実施例１〜２を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付ける受付部と、
前記受付部により受け付けられた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する決定部と
を有することを特徴とするリソース管理装置。

（付記２）前記決定部により決定されたリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させ、測定された測定ベンチマークスコアを取得する測定部と、
前記測定ベンチマークスコアと前記要求ベンチマークスコアに基づいて、構築された仮想マシンがユーザの要求にマッチするか否かを判定する判定部とをさらに有し、
前記決定部は、構築された仮想マシンがユーザの要求にマッチしないと前記判定部により判定された場合に、前記リソースを変更し、
前記測定部は、前記決定部により変更されたリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させ、測定された測定ベンチマークスコアを取得することを特徴とする付記１に記載のリソース管理装置。

(付記３)前記決定部は、
前記受付部により受け付けられた使用用途と要求ベンチマークスコアに基づいて、各リソースが要求されるリソースベンチマークスコアを算出する算出部と、
前記算出部により算出されたリソースベンチマークスコアに基づいて、前記仮想マシンの構築に用いる各リソースを予測する予測部と、
前記予測部により予測された各リソース用いて前記仮想マシンが実際に構築できるか否かをリソースの使用状況を含むリソース情報に基づいて判定し、構築できないと判定した場合に、１つ以上のリソースを変更する構築部と
を有することを特徴とする付記１に記載のリソース管理装置。

（付記４）前記構築部は、１つ以上のリソースの性能を変更することでリソースを変更することを特徴とする付記３に記載のリソース管理装置。

（付記５）前記構築部は、性能を上げることでリソースを変更した場合に、他のリソースの性能を下げる変更を行うことを特徴とする付記４に記載のリソース管理装置。

（付記６）コンピュータに、
ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付け、
受け付けた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する
処理を実行させることを特徴とするリソース管理プログラム。

（付記７）決定したリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させ、測定された測定ベンチマークスコアを取得し、
前記測定ベンチマークスコアと前記要求ベンチマークスコアに基づいて、構築された仮想マシンがユーザの要求にマッチするか否かを判定する処理をさらに前記コンピュータに実行させ、
前記決定する処理は、構築された仮想マシンがユーザの要求にマッチしないと判定した場合に、前記リソースを変更し、
前記測定させる処理は、変更したリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させることを特徴とする付記６に記載のリソース管理プログラム。

（付記８）前記決定する処理は、
受け付けた使用用途と要求ベンチマークスコアに基づいて、各リソースが要求されるリソースベンチマークスコアを算出し、
算出したリソースベンチマークスコアに基づいて、前記仮想マシンの構築に用いる各リソースを予測し、
予測した各リソース用いて前記仮想マシンが実際に構築できるか否かをリソースの使用状況を含むリソース情報に基づいて判定し、構築できないと判定した場合に、１つ以上のリソースを変更する
ことを特徴とする付記６に記載のリソース管理プログラム。

（付記９）コンピュータに、
ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付け、
受け付けた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する
処理を実行させるリソース管理プログラムを記憶したコンピュータ読み取り可能記憶媒体。

（付記１０）メモリと該メモリに接続されたプロセッサとを有するリソース管理装置において、
前記プロセッサに、
ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付け、
受け付けた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する
処理を実行させることを特徴とするリソース管理装置。

１，９ リソース管理装置
２ ベンチマークＯＳストレージ
３ クラウドリソース群
４ ネットワーク
５ ネットワーク
６ クライアントＰＣ
１１ 受付部
１２ 受付情報記憶部
１３ 算出情報記憶部
１４ 予測情報記憶部
１５ リソース情報記憶部
１６ 決定部
１７ 測定部
１８ 測定結果記憶部
１９ 比較部
２０ 提供部
２１ 算出部
２２ 予測部
２３ 構築部
３１ サーバ
３２ ストレージ装置
５０ コンピュータ
５１ メモリ
５２ ＣＰＵ
５３ ＬＡＮインタフェース
５４ ＨＤＤ
５５ スーパーＩＯ
５６ ＤＶＩ
５７ ＯＤＤ

Claims (6)

1. ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付ける受付部と、
   前記受付部により受け付けられた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する決定部と
   を有することを特徴とするリソース管理装置。
2. 前記決定部により決定されたリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させ、測定された測定ベンチマークスコアを取得する測定部と、
   前記測定ベンチマークスコアと前記要求ベンチマークスコアに基づいて、構築された仮想マシンがユーザの要求にマッチするか否かを判定する判定部とをさらに有し、
   前記決定部は、構築された仮想マシンがユーザの要求にマッチしないと前記判定部により判定された場合に、前記リソースを変更し、
   前記測定部は、前記決定部により変更されたリソースを用いて構築された仮想マシンでベンチマークプログラムを実行させてベンチマークスコアを測定させ、測定された測定ベンチマークスコアを取得することを特徴とする請求項１に記載のリソース管理装置。
3. 前記決定部は、
   前記受付部により受け付けられた使用用途と要求ベンチマークスコアに基づいて、各リソースが要求されるリソースベンチマークスコアを算出する算出部と、
   前記算出部により算出されたリソースベンチマークスコアに基づいて、前記仮想マシンの構築に用いる各リソースを予測する予測部と、
   前記予測部により予測された各リソース用いて前記仮想マシンが実際に構築できるか否かをリソースの使用状況を含むリソース情報に基づいて判定し、構築できないと判定した場合に、１つ以上のリソースを変更する構築部と
   を有することを特徴とする請求項１に記載のリソース管理装置。
4. 前記構築部は、１つ以上のリソースの性能を変更することでリソースを変更することを特徴とする請求項３に記載のリソース管理装置。
5. 前記構築部は、性能を上げることでリソースを変更した場合に、他のリソースの性能を下げる変更を行うことを特徴とする請求項４に記載のリソース管理装置。
6. コンピュータに、
   ユーザに提供される仮想マシンの使用用途と該ユーザが要求する要求ベンチマークスコアを受け付け、
   受け付けた使用用途と要求ベンチマークスコアに基づいて、前記仮想マシンの構築に用いるリソースを決定する
   処理を実行させることを特徴とするリソース管理プログラム。
   

Images