(57)【特許請求の範囲】
【請求項１】
提供するべき仮想化資源を複数の物理サーバに割り当てる資源割り当て装置であって、
物理サーバの障害を認識する認識手段と、
前記障害が認識された物理サーバにおける仮想化資源を検索する検索手段と、
前記障害が認識された物理サーバ以外の物理サーバの中で、前記検索手段で検索された仮想化資源と冗長構成となる仮想化資源が割り当てられた物理サーバを除いた、仮想化資源が既に割り当てられている物理サーバを含む物理サーバの中から選択した物理サーバに、前記検索手段で検索された仮想化資源を割り当てた場合に残る資源が既に選択された他の物理サーバの残りの資源よりも少ないと、前記選択した前記物理サーバを検索された前記仮想化資源を割り当て可能な物理サーバと決定する決定手段と
を備えた、資源割り当て装置。
【請求項２】
前記決定手段は、前記検索手段で検索された仮想化資源を割り当て可能な物理サーバが存在しないとき、確保可能な資源が最大の物理サーバを割り当て可能な物理サーバとして決定する、請求項１記載の資源割り当て装置。
【請求項３】
前記決定手段は、前記障害発生時における冗長性及び資源効率と配備時間を考慮したインスタンス配置設計を行う、請求項１記載の資源割り当て装置。
【請求項４】
前記決定手段は、クラスタ構成変更時の冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行い、クラスタは冗長性を意識して設計したインスタンス群である、請求項１記載の資源割り当て装置。
【請求項５】
提供するべき仮想化資源を複数の物理サーバに割り当てる割当処理をコンピュータに行わせるプログラムであって、
物理サーバの障害を認識する手順と、
前記障害が認識された物理サーバにおける仮想化資源を検索する手順と、
前記障害が認識された物理サーバ以外の物理サーバの中で、前記検索手順で検索された仮想化資源と冗長構成となる仮想化資源が割り当てられた物理サーバを除いた、仮想化資源が既に割り当てられている物理サーバを含む物理サーバの中から選択した物理サーバに、前記検索手順で検索された仮想化資源を割り当てた場合に残る資源が既に選択された他の物理サーバの残りの資源よりも少ないと、前記選択した前記物理サーバを検索された前記仮想化資源を割り当て可能な物理サーバと決定する手順と
を前記コンピュータに実行させる、プログラム。
【請求項６】
前記決定する手順は、前記検索する手順で検索された仮想化資源を割り当て可能な物理サーバが存在しないとき、確保可能な資源が最大の物理サーバを割り当て可能な物理サーバとして決定する、請求項５記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資源割り当て方法及び装置並びにプログラムに係り、特に複数の顧客が資源を仮想化によって共用する環境で用いる資源割り当て方法、そのような資源割り当て方法を採用した資源割り当て装置、及びコンピュータにそのような資源割り当て方法を用いた資源割り当てを実行させるプログラムに関する。
【０００２】
インターネットデータセンタの中でも複数顧客が資源を仮想化によって共用する仮想化データセンタで利用される仮想環境管理システムにおいて、サービスの信頼性の保証や管理を行うことが望まれている。
【背景技術】
【０００３】
近年、インターネットデータセンタ等のデータセンタにおいて、資源を顧客に貸し出すホスティングサービスに加え、物理的なものではない仮想資源を貸し出す仮想化データセンタサービスの提供が始められている。このような仮想化データセンタサービスでは、物理的なサーバやネットワーク配線を貸し出すのではなく、指定された処理能力を持った仮想サーバや要求された帯域幅を貸し出す。仮想化データセンタは、提供する仮想資源を物理資源から供給するが、その際に単一の物理資源を仮想化することにより複数の顧客で共用させる。
【０００４】
一般に、顧客から要求されるサーバ資源量は必ずしも物理サーバ単位の資源量とは一致せず、又、近年のサーバの性能向上により物理サーバを占有させると過剰な資源量を提供してしまう傾向がある。更に、セキュリティへの要望が強くなっていることから、単純に複数の顧客で単一の物理サーバを共用する運用形態では適切なサービスを提供できなくなってきている。そこで、資源の仮想化により個々の仮想空間を独立化することで、各顧客から見るとは物理サーバを占有しているのと同等のセキュリティを提供し、これと同時に物理資源の有効利用を図ることができる。
【０００５】
このような仮想化による資源の共用は、資源の効率利用という利点をもたらすが、信頼性の面で新たな問題を引き起こす。例えば、顧客が信頼性の向上のために複数の仮想サーバで処理を行うような設計をしても、それらの複数の仮想サーバの処理が全て同一の物理サーバ上で実行されてしまっては、複数の仮想サーバの処理が単一の障害点を共有することになってしまい、処理を多重化した意味がなくなってしまう。一方、顧客に仮想サーバの物理配置を意識させたのでは、仮想化データセンタによる資源配置の最適化が行えなくなってしまう。
【０００６】
上記の如き問題は、仮想化データセンタからサービスを開始する場合に限らず、機器障害等によるサービスの再構成や再割当を行う場合にも発生する。特に障害回復のための再割当を行う際には、処理の冗長性だけでなく処理時間の短縮についても考慮する必要がある。これは、仮想化データセンタにおいては、処理で活用されない資源は通常稼動させないため、新規に物理サーバに論理サーバを割り当てる場合には仮想環境の初期化にかかる時間も必要となるためである。
【０００７】
このような信頼性の問題は、複数の顧客が資源を共用する仮想化データセンタに限らず、仮想化によりサーバの統合を行う顧客内データセンタの場合にも起こり得る。
【０００８】
従来の仮想データセンタは、動作するサービスの信頼性については言及しておらず、同時に保障もしていないが、今後、より高度なサービスのインフラストラクチャとして仮想データセンタが利用がされることが予想されるので、サービスの可用性や信頼性の評価及び保証を行うことが必要となってくると考えられる。このため、今後は、仮想化データセンタが提供するサービスの信頼性保証と資源の利用効率の最適化を両立させる要望がより一層強まると予想される。
【０００９】
特許文献１では、オンデマンドセンタにおける負荷分散及びリソース管理の方法についての提案がされているが、サービスの信頼性の評価や保証についての提案はない。
【００１０】
又、特許文献２では、データセンタにおける可用性を向上する方法についての提案がされているが、仮想化環境を考慮したものではなく、配置済みのサービスを利用しての可用性の向上に関してのものである。
【特許文献１】特許第３６２７００５号公報
【特許文献２】特表２００５−５１２１９０号公報
【特許文献３】特開平１０−１８７６３８号公報
【特許文献４】特開２０００−２０７３７４号公報
【特許文献５】特開２００１−２０９６２７号公報
【特許文献６】特開２００４−４６３７２号公報
【特許文献７】特開２００６−２６８７１１号公報
【特許文献８】特開２００２−２４１９２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
今後は、仮想化データセンタが提供するサービスの信頼性保証と資源の利用効率の最適化を両立させる要望がより一層強まると予想されるものの、従来は仮想化データセンタが提供するサービスの信頼性保証と資源の利用効率の最適化を両立する対策は取られていなかった。
【００１２】
そこで、本発明は、仮想化データセンタが提供するサービスの信頼性保証と資源の利用効率の最適化を両立可能な資源割り当て方法及び装置並びにプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の一観点によれば、提供するべき仮想化資源を複数の物理サーバに割り当てる資源割り当て装置であって、物理サーバの障害を認識する認識手段と、前記障害が認識された物理サーバにおける仮想化資源を検索する検索手段と、前記障害が認識された物理サーバ以外の物理サーバの中で、前記検索手段で検索された仮想化資源と冗長構成となる仮想化資源が割り当てられた物理サーバを除いた、仮想化資源が既に割り当てられている物理サーバを含む物理サーバの中から選択した物理サーバに、前記検索手段で検索された仮想化資源を割り当てた場合に残る資源が既に選択された他の物理サーバの残りの資源よりも少ないと、前記選択した前記物理サーバを検索された前記仮想化資源を割り当て可能な物理サーバと決定する決定手段とを備えた資源割り当て装置が提供される。
【００１５】
本発明の一観点によれば、提供するべき仮想化資源を複数の物理サーバに割り当てる割当処理をコンピュータに行わせるプログラムであって、物理サーバの障害を認識する手順と、前記障害が認識された物理サーバにおける仮想化資源を検索する手順と、前記障害が認識された物理サーバ以外の物理サーバの中で、前記検索手順で検索された仮想化資源と冗長構成となる仮想化資源が割り当てられた物理サーバを除いた、仮想化資源が既に割り当てられている物理サーバを含む物理サーバの中から選択した物理サーバに、前記検索手順で検索された仮想化資源を割り当てた場合に残る資源が既に選択された他の物理サーバの残りの資源よりも少ないと、前記選択した前記物理サーバを検索された前記仮想化資源を割り当て可能な物理サーバと決定する手順とを前記コンピュータに実行させるプログラムが提供される。
【発明の効果】
【００１６】
開示の資源割り当て方法及び装置並びにプログラムによれば、仮想化データセンタが提供するサービスの信頼性保証と資源の利用効率の最適化を両立可能とすることができる。
【発明を実施するための最良の形態】
【００１７】
仮想化データセンタが提供するサービスの信頼性を保証するためには、多重化された仮想サーバ群が単一障害点を共有しないように物理サーバへ割り当てる必要がある。開示の資源割り当て方法及び装置並びにプログラムでは、顧客側で仮想サーバの多重化に関する情報を付与し、仮想化データセンタ側でこの情報に基づいて仮想サーバの物理サーバへの割り当てを決定する。
【００１８】
具体的には、提供するべき仮想化資源を複数の物理サーバに割り当てるコンピュータによる資源割り当て方法において、任意の１つの物理サーバの障害を認識するステップと、障害が認識された物理サーバで冗長構成の仮想化資源を検索するステップと、任意の１つの物理サーバ以外の物理サーバの中から冗長構成が可能であり、且つ、仮想化資源を割り当て可能な物理サーバを決定するステップとをコンピュータに実行させる。資源割り当て装置は、これらのステップに対応する手段を備える。
【００１９】
仮想化データセンタが提供するサービスの信頼性の保証は、従来技術にはない思想であり、提供するサービスの信頼性保証と資源の利用効率の最適化を両立させることは、今後仮想化データセンタが提供するサービスの高付加価値化に伴い必要になると考えられる。
【００２０】
開示の資源割り当て方法及び装置並びにプログラムによれば、提供するサービスの信頼性の保証を考慮した上でインスタンス（又は、論理）の物理サーバへの再割当を行うことができるため、仮想環境においても信頼性の高いサービスを提供することが可能となる。
【００２１】
又、本発明は仮想化データセンタに限らず、仮想化技術を利用するサービス運用システム全般に適用可能である。
【００２２】
以下に、本発明の資源割り当て方法及び装置並びにプログラムの各実施例を、図面と共に説明する。
【実施例】
【００２３】
図１は、本発明の第１実施例における仮想環境管理システムの概略構成を示すブロック図である。図1に示す仮想環境管理システム１は、管理サーバ２、インターネットデータセンタ等の仮想データセンタ３、及び複数のクライアント４を含む。管理サーバ２は、汎用コンピュータにより構成可能であり、仮想データセンタ３と接続されている。仮想データセンタ３は、インターネット等のネットワーク５を介して複数のクライアント４と接続される。各クライアント４は、汎用コンピュータにより構成可能である。仮想データセンタ３は、サーバプールを形成する複数の共用物理サーバ３１を含む。各物理サーバ３１は、汎用コンピュータにより構成可能である。各物理サーバ３１は、サーバ仮想化機構を利用して複数の仮想サーバ３５に分割され、その仮想サーバ３５が複数連携することでサービスを形成する。サービスを形成する際、仮想サーバ３５間は仮想ネットワークで接続される。尚、サーバ仮想化機構による物理サーバ３１の仮想化の方式が様々なものが提案されて、仮想化方式は特に限定されない。このように、本実施例は特定の仮想化方式に依存するものではないので、仮想化方式自体の詳細な説明は省略する。
【００２４】
管理サーバ２、物理サーバ３１及びクライアント４を構成する汎用コンピュータは、ＣＰＵ，ＭＰＵ等のプロセッサと、内部及び／又は外部記憶部とを備える。記憶部は、プロセッサが実行するプログラムや後述するテーブルを含む各種データを格納すると共に、プロセッサが実行する演算に用いたり中間データ等を格納するために用いられるワークエリアを提供する。
【００２５】
図１に示す如き環境において、本実施例では以下に説明するように仮想サーバ３５を物理サーバ３１に割り当てる。尚、以下の説明に用いられるパラメータ及び記号の定義は次の通りである。
【００２６】
物理サーバ台数Ｋ（Ｋは２以上の整数）は、仮想データセンタ３内で利用可能な物理サーバ３１の台数を示す。物理サーバ性能Ｐ（ｋ）は、各物理サーバ３１が有する資源量を示し、１≦ｋ≦Ｋである。クラスタグループＳ＝｛クラスタＡ，Ｂ，Ｃ，．．．｝は、仮想サーバ３５の冗長性を考慮したクラスタ（即ち、仮想サーバ３５が提供するサービス）Ａ，Ｂ，Ｃ，．．．のグループを示す。クラスタｓ毎のインスタンス数Ｎ（ｓ）は、各クラスタｓに含まれるインスタンスの数を示し、ｓ∈Ｓである。インスタンスの要求資源量Ｒ（ｓ，ｎ）は、各インスタンスに割り当てる資源量を示し、ｓ∈Ｓ、且つ、１≦ｎ≦Ｎ（ｓ）である。クラスタｓへの割当保証資源量Ｇ（ｓ）は、サービスＡ，Ｂ，Ｃ，．．．の設計性能を維持するために必要な資源量を示し、ｓ∈Ｓである。クラスタｓへの割当済み資源量Ｃ（ｓ）は、インスタンスを物理サーバ３１に割り当てた結果として割り当てられた資源量を示し、ｓ∈Ｓである。物理サーバ３１へのインスタンス割当量Ｍ（ｋ）＝｛（ｓ，ｎ），．．．，割当インスタンス群｝は、各物理サーバ３１に割り当てられたインスタンスのリストを示し、１≦ｋ≦Ｋである。物理サーバ３１への割当済資源量
0005211766.tif 000002
は、各物理サーバ３１でインスタンスの割り当てによって使用済みの資源量を示し、１≦ｋ≦Ｋである。再割り当てが必要な仮想サーバ群Ｕは、Ｕ＝｛（ｓ，ｎ），．．．｝で表される。性能達成度Ｔ（ｓ）は、クラスタの割当保証値に対する割当済の比率を示し、０≦Ｔ（ｓ）≦１．０で表される。インスタンスへの資源割当量Ｅ（ｓ，ｎ）は、各インスタンスに実際に割り当てられた資源量を示し、ｓ∈Ｓ、且つ、１≦ｎ≦Ｎ（ｓ）である。
【００２７】
次に、本実施例で使用する各種テーブル４１〜４４について説明する。
【００２８】
図２は、仮想データセンタ３内の記憶部に格納されるクラスタ定義テーブル４１の一例を示す図である。顧客は冗長性を意識して設計したインスタンス群をクラスタとして定義する。仮想データセンタ３は、各顧客からの定義情報をまとめてクラスタ定義テーブル４１を作成する。クラスタ定義テーブル４１は、仮想データセンタ３の運用開始前に定義され、運用開始後はクラスタ構成の変更時、新クラスタの追加時、及びクラスタの削除時に変更される。クラスタ定義テーブル４１には、インスタンスの要求資源量Ｒ（ｓ，ｎ）及びクラスタへの割当保証資源量Ｇ（ｓ）の情報が記述される。
【００２９】
図３は、仮想データセンタ３内の記憶部に格納される物理サーバ定義テーブル４２の一例を示す図である。物理サーバ定義テーブル４２には、仮想データセンタ３が利用可能な物理サーバ３１を登録する。図３中、「物理１」等は、物理サーバ３１のサーバ名を示す。物理サーバ定義テーブル４２は、仮想化データセンタ３の運用開始前に定義さる。仮想化データセンタ３の運用開始後は、物理サーバ３１に障害（又は、異常）が発生した場合には周知の方法で認識され該当物理サーバ３１が物理サーバ定義テーブル４２から削除され、障害が発生した物理サーバ３１の修復された場合や仮想データセンタ３の資源拡張時に物理サーバ３１が追加されると物理サーバ定義テーブル４２に追加される。物理サーバ定義テーブル４２には、物理サーバ性能Ｐ（ｋ）の情報が記述される。
【００３０】
図４は、仮想データセンタ３内の記憶部に格納される割当状況テーブル４３の一例を示す図である。割当状況テーブル４３は、以下で述べるような手順に従い、新規割当又は再割当の際に作成又は更新される。割当状況テーブル４３は、仮想データセンタ３の運用開始時に後述する手順（ＰＲ１）で作成され、運用中は物理サーバ定義テーブル４２又はクラスタ定義テーブル４１の変更に合わせて後述する手順（ＰＲ２）以降により順次更新される。割当状況テーブル４３の定義に基づき、実際の物理サーバ３１にインスタンスの配備や移動が行われる。割当状況テーブル４３は、物理サーバ３１へのインスタンス割当量Ｍ（ｋ）、物理サーバ３１への割当済資源量Ａ（ｋ）及びインスタンスへの資源割当量Ｅ（ｓ，ｎ）の情報が記述される。インスタンス割当量Ｍ（ｋ）は、物理サーバ定義テーブル４２の物理サーバ性能Ｐ（ｋ）からコピーされる。
【００３１】
図５は、仮想データセンタ３内の記憶部に格納される再割当優先度判定テーブル４４の一例を示す図である。再割当優先度判定テーブル４４は、クラスタ、クラスタ保証値、クラスタ割当量、性能達成度Ｔ（ｓ）及び優先度の情報が記述される。クラスタ保証値は、クラスタ定義テーブル４１の割当保証資源量Ｇ（ｓ）からコピーされる。再割当優先度判定テーブル４４は、以下の手順（ＰＲ１）〜（ＰＲ４）にて割り当てを調整する際に、優先するべきインスタンスを判断するために用いられる。
【００３２】
手順（ＰＲ１）は、多重化を考慮した仮想サーバ３５の物理サーバ３１への割り当てを行う。多重化時の配備制約を考慮した上で仮想サーバ３５を物理サーバ３１に割り当てる方法は、次の通りである。
手順（ＰＲ１）：
ステップＰＲ１−１：全てのkに対してＭ（ｋ）＝｛φ｝とし、割当状況を初期化する。
ステップＰＲ１−２：Ｎ（ｓ）が大きい順に以降の処理を行う。これは、必要となる仮想サーバ３５の台数が多いものを優先することで最大物理サーバ３１の台数をできるだけ少なくするためである。複数のクラスタが同数の物理サーバ３１からなる場合は、それらの中でＲ（ｓ，ｎ）が最大となるクラスタｓを優先させる。
ステップＰＲ１−３：選択したクラスタｓに対してＲ（ｓ，ｎ）（１≦ｎ≦Ｎ（ｓ））が大きい順に以降の処理を行う。これは、インスタンスの要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能が高い仮想サーバ３５の方が割当制約が厳しいことから効率的な割り当てになるようにするためである。
ステップＰＲ１−４：全ての物理サーバkに対し、任意のnに対し¬（（ｓ，ｎ）∈Ｍ（ｋ））であり、（Ａ（ｋ）＋Ｒ（ｓ，ｎ））≦Ｐ（ｋ）であり、且つ、（Ｐ（ｋ）−（Ａ（ｋ）＋Ｒ（ｓ，ｎ）））が最小となるようなｋを選択する。これは、物理サーバ３１がクラスタｓの仮想サーバ３５が割り当てられておらず、割り当てることで未割当性能が最小となる物理サーバ３１を選択することを意味する。尚、（Ｐ（ｋ）−（Ａ（ｋ）＋Ｒ（ｓ，ｎ）））が同値で最小となるkが複数ある場合は任意のものを選んで良い。選択したｋは、物理サーバ３１へのインスタンス割当量Ｍ（ｋ）に追加される。
【００３３】
図６は、初期割当処理をより詳細に説明するフローチャートである。図６において、ステップＳ１は割当状況テーブル４３をゼロに初期化する。ステップＳ２は、クラスタ定義テーブル４１でインスタンスが多い順に仮想サーバ３５を割り当てる処理を開始し、全てのインスタンスに対する仮想サーバ３５の割り当てが完了すると処理は終了する。ステップＳ３は、各インスタンスについて、要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能が高い順に仮想サーバ３５を割り当てる割当処理を開始して処理はステップＳ４へ進み、全てのインスタンスに対する割当処理が完了すると処理はステップＳ２へ戻る。
【００３４】
ステップＳ４は、選択された仮想サーバ３５を未定義として設定し、ステップＳ５は、全ての物理サーバ３１を順に調べる処理を開始する。ステップＳ６は、物理サーバ３１が既にクラスタ内で利用済であるか否かを判定する。ステップＳ６の判定結果がＹＥＳであると、ステップＳ７は、この物理サーバ３１がインスタンスの要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能を確保可能であるか否かを判定する。ステップＳ７の判定結果がＹＥＳであると、ステップＳ８は、既に選択された他の物理サーバ３１が有るか否かを判定する。ステップＳ８の判定結果がＹＥＳであると、ステップＳ９は、この物理サーバ３１の資源を選択された仮想サーバ３５に割り当てた後に残る資源が、既に選択された他の物理サーバ３１の残りの資源より少ないか否かを判定する。ステップＳ９の判定結果がＹＥＳであると、ステップＳ１０は、この物理サーバ３１を選択された仮想サーバ３５を割り当てる物理サーバ３１として選択する。ステップＳ６〜Ｓ９のいずれかの判定結果がＮＯであるか、或いは、ステップＳ１０の後、処理はステップＳ５へ戻る。
【００３５】
ステップＳ５において、全ての物理サーバ３１についてステップＳ６〜Ｓ１０の処理が完了すると、処理はステップＳ１１へ進む。ステップＳ１１は、選択された仮想サーバ３５を割り当てる物理サーバ３１が選択されたか否かを判定する。ステップＳ１１の判例結果がＹＥＳであると、ステップＳ１２は、選択された物理サーバ３１を割当状況テーブル４３に登録し、処理はステップＳ３戻る。一方、ステップＳ１１の判定結果がＮＯであると、ステップＳ１３は、仮想データセンタ３又は管理サーバ２の管理者に、仮想サーバ３５を割り当てる物理サーバ３１が選択されなかった旨を含む警告を出力し、処理はステップＳ３へ戻る。
【００３６】
このようにして、余剰性能の量を抑制しつつ多重構成の物理サーバ３１の重複割当を回避することができる。尚、上記の手順（ＰＲ１）では最適な構成となることは保証されないが、仮想データセンタ３の運用時において多くの場合に妥当となる程度の効率化は可能である。
【００３７】
手順（ＰＲ２）は、物理サーバ３１の障害発生時における冗長性及び資源効率と配備時間を考慮したインスタンス配置設計を行う。
【００３８】
物理サーバ３１やソフトウェアに障害が発生した場合、検索の結果冗長構成を取っていた場合には非冗長構成に、冗長構成を取っていなかった場合には縮退運用又はサービス停止といった事態が発生する。このような場合、仮想化データセンタ３においては、利用可能な資源が存在しているのであれば、障害が発生した物理サーバ３１を別の物理サーバ３１に割り当て直すことで障害から回復させることが可能である。この際、冗長性の維持等を考慮しながら再割り当てを行う方法は次の通りである。尚、再割当処理は、物理サーバ定義テーブル４３から物理サーバ３１が削除されることで開始される。削除と同時に追加される物理サーバ３１がある場合は、先ず本手順（ＰＲ２）が行われ、その後に後述する手順（ＰＲ３）が行われる。
手順（ＰＲ２）：
ステップＰＲ２−１：割り当て状況テーブル４３において、削除された物理サーバ３１に関係しているインスタンスを再割り当てが必要なインスタンスとして仮想サーバ群Ｕに登録する。仮想サーバ群Ｕ＝｛φ｝であれば（障害が発生した物理サーバ３１上でインスタンスが動いていなかった場合)、これ以上何も処理は行わない。これと同時に、該当インスタンスは割り当て状況テーブル４３から削除する。
ステップＰＲ２−２： 仮想サーバ群Ｕに含まれる仮想サーバ３５が含まれるクラスタｓに対し、現在割り当て済みの性能Ｃ（ｓ）を計算する。
ステップＰＲ２−３：性能達成度Ｔ（ｓ）＝Ｃ（ｓ）／Ｇ（ｓ）を計算する、但し、Ｇ（ｓ）がゼロの場合もしくはＴ（ｓ）が１．０を超える場合にはＴ（ｓ）＝１．０とする。
ステップＰＲ２−４：Ｔ（ｓ）が最も小さいクラスタｓ内を選択する。同値の場合はＧ（ｓ）が大きいものを優先する(障害の影響が大きいと思われるものを優先する)。その中に含まれるインスタンスのうち、要求資源量が大きいものを選択する。
ステップＰＲ２−５：現在稼動している物理サーバ３１（Ｍ（ｋ）≠φ）の中で、クラスタｓに含まれる仮想サーバ３５が割り当てられておらず、且つ、再割り当てを行う（ｓ，ｎ）に割り当てる資源Ｒ（ｓ，ｎ）を確保できる物理サーバがあるか否かを検索する。そのような物理サーバ３１が複数ある場合には、残りの資源量が最小になる物理サーバ３１を優先する。
ステップＰＲ２−６：ステップＰＲ２−５において割り当てができない場合は、未稼動状態の物理サーバ３１の中からＲ（ｓ，ｎ）が割り当て可能な物理サーバ３１を選択する。
ステップＰＲ２−７：ステップＰＲ２−６において割り当てができない（必要な大きさの仮想サーバ３５のための資源を選択できない）場合は、確保可能な最大量を割り当てる。
ステップＰＲ２−８：ステップＰＲ２−４で選択されたインスタンスを再割り当て優先度判定テーブル４４から削除し、部分的に割り当てた結果状況が改善したクラスタの優先度を再判定するためにステップＰＲ２−２から処理を繰り返す。全てのインスタンスが処理されるまで上記ステップＰＲ２−２〜ＰＲ２−８が繰り返される。
【００３９】
図７は、障害発生時の再割当処理を説明するフローチャートである。図７において、ステップＳ２１は、障害を起こした物理サーバ３１内のインスタンスを再割当候補に選択する。ステップＳ２２は、障害を起こした物理サーバ３１内のインスタンスの割当を解除する。ステップＳ２３は、再割当処理を行い、処理は終了する。
【００４０】
図８乃至図１０は、再割当処理を説明するフローチャートである。図８において、ステップＳ３１は、選択されたインスタンスが残っているか否かを判定し、判定結果がＮＯであると処理は終了する。一方、ステップＳ３１の判定結果がＹＥＳであると、ステップＳ３２は、再割当優先度判定テーブル４４を構築する処理を開始する。ステップＳ３３は、割当優先度の高いクラスタを選択し、ステップＳ３４は、要求性能の高いインスタンスを選択する。ステップＳ３５は、選択された仮想サーバ３５を未定義として設定し、ステップＳ３６は、稼働中の物理サーバ３１を順に調べる処理を開始する。ステップＳ３７は、物理サーバ３１が既にクラスタ内で利用済であるか否かを判定する。ステップＳ３７の判定結果がＹＥＳであると、ステップＳ３８は、この物理サーバ３１がインスタンスの要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能を確保可能であるか否かを判定する。ステップＳ３８の判定結果がＹＥＳであると、ステップＳ３９は、既に選択された他の物理サーバ３１が有るか否かを判定する。ステップＳ３９の判定結果がＹＥＳであると、ステップＳ４０は、この物理サーバ３１の資源を選択された仮想サーバ３５に割り当てた後に残る資源が、既に選択された他の物理サーバ３１の残りの資源より少ないか否かを判定する。ステップＳ４０の判定結果がＹＥＳであると、ステップＳ４１は、この物理サーバ３１を選択された仮想サーバ３５を割り当てる物理サーバ３１として選択する。ステップＳ３７〜Ｓ４０のいずれかの判定結果がＮＯであるか、或いは、ステップＳ４１の後、処理はステップＳ３６へ戻る。
【００４１】
ステップＳ３６において、全ての物理サーバ３１についてステップＳ３７〜Ｓ４１の処理が完了すると、処理は図９に示すステップＳ５１へ進む。ステップＳ５１は、選択された仮想サーバ３５を割り当てる物理サーバ３１が選択されたか否かを判定する。ステップＳ５１の判例結果がＹＥＳであると、処理は図１０と共に後述するステップＳ７０へ進む。一方、ステップＳ５１の判定結果がＮＯであると、ステップＳ５２は、全ての物理サーバ３１を順に調べる処理を開始する。ステップＳ５３は、物理サーバ３１が既にクラスタ内で利用済であるか否かを判定する。ステップＳ５３の判定結果がＹＥＳであると、ステップＳ５４は、この物理サーバ３１がインスタンスの要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能を確保可能であるか否かを判定する。ステップＳ５４の判定結果がＹＥＳであると、ステップＳ５５は、既に選択された他の物理サーバ３１が有るか否かを判定する。ステップＳ５５の判定結果がＹＥＳであると、ステップＳ５６は、この物理サーバ３１の資源を選択された仮想サーバ３５に割り当てた後に残る資源が、既に選択された他の物理サーバ３１の残りの資源より少ないか否かを判定する。ステップＳ５６の判定結果がＹＥＳであると、ステップＳ５７は、この物理サーバ３１を選択された仮想サーバ３５を割り当てる物理サーバ３１として選択する。ステップＳ５３〜Ｓ５６のいずれかの判定結果がＮＯであるか、或いは、ステップＳ５７の後、処理はステップＳ５２へ戻る。
【００４２】
ステップＳ５２において、全ての物理サーバ３１についてステップＳ５３〜Ｓ５７の処理が完了すると、処理はステップＳ５８へ進む。ステップＳ５８は、選択された仮想サーバ３５を割り当てる物理サーバ３１が選択されたか否かを判定する。ステップＳ５８の判例結果がＹＥＳであると、処理は図１０と共に後述するステップＳ７０へ進む。一方、ステップＳ５８の判定結果がＮＯであると、ステップＳ５９は、全ての物理サーバ３１を順に調べる処理を開始する。ステップＳ６０は、物理サーバ３１がインスタンスの要求資源量Ｒ（ｓ，ｎ）、即ち、要求性能を確保可能であるか否かを判定する。ステップＳ６０の判定結果がＹＥＳであると、ステップＳ６１は、既に選択された他の物理サーバ３１が有るか否かを判定する。ステップＳ６１の判定結果がＹＥＳであると、ステップＳ６２は、この物理サーバ３１の資源を選択された仮想サーバ３５に割り当てた後に残る資源が、既に選択された他の物理サーバ３１の残りの資源より少ないか否かを判定する。ステップＳ６２の判定結果がＹＥＳであると、ステップＳ６３は、この物理サーバ３１を選択された仮想サーバ３５を割り当てる物理サーバ３１として選択する。ステップＳ６０〜Ｓ６２のいずれかの判定結果がＮＯであるか、或いは、ステップＳ６３の後、処理はステップＳ５９へ戻る。
【００４３】
ステップＳ５９において、全ての物理サーバ３１についてステップＳ６０〜Ｓ６３の処理が完了すると、処理はステップＳ６４へ進む。ステップＳ６４は、選択された仮想サーバ３５を割り当てる物理サーバ３１が選択されたか否かを判定する。ステップＳ６４の判例結果がＹＥＳであると、処理は図１０に示すステップＳ７０へ進み、ＮＯであると処理は図１０に示すステップＳ６５へ進む。
【００４４】
図１０において、ステップＳ６５は、全ての物理サーバ３１を順に調べる処理を開始する。ステップＳ６６は、既に選択された他の物理サーバ３１が有るか否かを判定する。ステップＳ６６の判定結果がＹＥＳであると、ステップＳ６７は、この物理サーバ３１に未割当資源があり、且つ、既に選択された他の物理サーバ３１より多くの資源が確保可能であるか否かを判定する。ステップＳ６７の判定結果がＹＥＳであると、ステップＳ６８は、この物理サーバ３１を選択された仮想サーバ３５を割り当てる物理サーバ３１として選択する。ステップＳ６６又はＳ６７のいずれかの判定結果がＮＯであるか、或いは、ステップＳ６８の後、処理はステップＳ６５へ戻る。
【００４５】
ステップＳ６５において、全ての物理サーバ３１についてステップＳ６６〜Ｓ６８の処理が完了すると、処理はステップＳ６９へ進む。ステップＳ６９は、選択された仮想サーバ３５を割り当てる物理サーバ３１が選択されたか否かを判定する。ステップＳ６９の判例結果がＹＥＳであると、ステップＳ７０は、選択された物理サーバ３１を割当状況テーブル４３に登録する。一方、ステップＳ６９の判定結果がＮＯであると、ステップＳ７１は、仮想データセンタ３又は管理サーバ２の管理者に、仮想サーバ３５を割り当てる物理サーバ３１が選択されなかった旨を含む警告を出力する。ステップＳ７０又はＳ７１の後、処理はステップＳ７２へ進む。ステップＳ７２は、処理したインスタンスを処理対象から除外し、処理は図８に示すステップＳ３１へ戻る。
【００４６】
図１１は、再割当優先度判定テーブル構築処理を説明するフローチャートである。図１１において、ステップＳ８１は、再割当優先度判定テーブル４４をゼロに初期化する。ステップＳ８２は、再割当インスタンスをクラスタ毎にまとめる。ステップＳ８３は、各再割当インスタンスをクラスタ毎に登録する処理を開始する。ステップＳ８５は、クラスタ内のインスタンスを再割当優先度判定テーブル４４に登録する。ステップＳ８６は、そのクラスタで現在割当済のインスタンスの資源量の合計を示すクラスタ割当量を登録する。ステップＳ８７は、そのクラスタの割当保証値がゼロであるか否かを判定する。ステップＳ８７の判定結果がＮＯであると、ステップＳ８８は、そのクラスタの割当保証値に対する割当済の比率を性能達成度Ｔ（ｓ）として算出する。ステップＳ８９は、性能達成度Ｔ（ｓ）≧１．０であるか否かを判定する。ステップＳ８７又はＳ８９の判定結果がＹＥＳであると、ステップＳ９０は、性能達成度Ｔ（ｓ）を１．０に設定する。ステップＳ８９の判定結果がＮＯ、又は、ステップＳ９０の後、処理はステップＳ８３へ戻る。ステップＳ８３において、全てのクラスタについてステップＳ８５〜Ｓ９０の処理が完了すると、処理はステップＳ８４へ進む。ステップＳ８４は、性能達成度Ｔ（ｓ）が大きい順に優先度を設定し、処理は終了する。例えば、性能達成度Ｔ（ｓ）が同値であれば、ステップＳ８４はクラスタ保証値の大きい方を優先して優先度を設定する。
【００４７】
上記の如く、障害により割り当て性能の劣化が大きいものを優先することで、障害の影響が大きいクラスタの復旧を優先させる。又、十分な資源が確保できない場合でも割り当て可能な資源があれば融通することで、クラスタを部分的にでも復旧させる。
【００４８】
手順（ＰＲ３）は、物理サーバ障害回復時における冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行う。
【００４９】
障害が発生した物理サーバ３１を修理したり代替機を新規に調達した時は、新たな余剰資源により適切に配置されなかったインスタンスについて再調整により配置を適切に修正することができる。尚、障害回復時の再割当処理は、物理サーバ定義テーブル４２に物理サーバ３が追加されることで開始される。物理サーバ定義テーブル４２への物理サーバ３１の追加と同時に削除される物理サーバ３１がある場合は、先ず手順（ＰＲ２）が行われ、その後本手順（ＰＲ３）が行われる。
手順（ＰＲ３）：
ステップＰＲ３−１：割当状況テーブル４３とクラスタ定義テーブル４１より、再割り当てが必要なインスタンスを選択する。先ず、割り当てられていないインスタンスや割当量が要求量に達していないインスタンスを再割り当てが必要な仮想サーバ群Ｕに登録する。その後、クラスタ内で同一物理サーバ３１に割り当てられたインスタンスを探して見つかった場合は、資源量が少ないものから優先して仮想サーバ群Ｕに登録していく。仮想サーバ群Ｕに登録されたインスタンスは、割当状況テーブル４３から削除する。又、Ｕ＝｛φ｝である（再割り当てが必要なインスタンスが無い）場合は、ここで処理を終える。同時に、該当インスタンスは割当状況テーブル４３から削除する。
ステップＰＲ３−２：ステップＰＲ３−１の後は、上記手順（ＰＲ２）のＰＲ２−２以降と同様の処理を行う。
【００５０】
図１２は、障害回復時の再割当処理を説明するフローチャートである。図１２において、ステップＳ９１は、クラスタ定義テーブル４１のインスタンスを順に選択する。ステップＳ９２は、割当状況テーブル４３に選択されたインスタンスが存在するか否かを判定する。ステップＳ９２の判定結果がＹＥＳであると、ステップＳ９３は、割当状況テーブル４３のインスタンス割当量Ｍ（ｋ）がクラスタ定義テーブル４１の要求資源量Ｒ（ｓ，ｎ）と等しいか否かを判定し、判定結果がＹＥＳであると処理はステップＳ９１へ戻る。一方、ステップＳ９２又はＳ９３の判定結果がＮＯであると、ステップＳ９４は、インスタンスを再割当候補に選択し、この再割当候補のインスタンスを割当状況テーブル４３から削除し、処理はステップＳ９１へ戻る。
【００５１】
ステップＳ９１において、クラスタ定義テーブル４１の全てのインスタンスについてステップＳ９２〜Ｓ９４の処理が完了すると、処理はステップＳ９５へ進む。ステップＳ９５は、割当状況テーブル４３の物理サーバ３１を順に選択する。ステップＳ９６は、同一クラスタのインスタンスが複数存在するか否かを判定する。ステップＳ９６の判定結果がＹＥＳであると、ステップＳ９７は、同一クラスタ内の最大資源量のインスタンス以外のインスタンスを再割当候補に選択し、この再割当候補のインスタンスを割当状況テーブル４３から削除する。ステップＳ９６の判定結果がＮＯ、又は、ステップＳ９７の後、処理はステップＳ９５へ進む。ステップＳ９５において、割当状況テーブル４３の全ての物理サーバ３１についてステップＳ９６及びＳ９７の処理が完了すると、処理はステップＳ９８へ進む。ステップＳ９８は、再割当処理を行い、処理は終了する。
【００５２】
これにより、適切でない割り当て状況にあったインスタンスをより適切になるよう調整することができる。
【００５３】
手順（ＰＲ４）は、クラスタ構成変更時の冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行う。
【００５４】
仮想データセンタ３の運用中にサービス規模が変化したり、新しいクラスタが追加されたり、クラスタが削除される場合があり得る。又、クラスタ内のインスタンスの増減や要求資源量の増減が発生する場合もある。クラスタ更新時の再割当処理は、このような場合にインスタンスの割り当てを調整するものであり、クラスタ定義テーブル４１が更新された時に実行される。
手順（ＰＲ４）：
ステップＰＲ４−１：割当状況テーブル４３とクラスタ定義テーブル４１を比較し、割当状況テーブル４３に含まれクラスタ定義テーブル４１に含まれないインスタンス(更新された結果存在しなくなったインスタンス)を割当状況テーブル４３から削除する。
ステップＰＲ４−２：割当状況テーブル４３とクラスタ定義テーブル４１を比較し、割当状況テーブル４３上のインスタンスへの資源割当量Ｅ（ｓ，ｎ）がクラスタ定義テーブル４１上の要求資源量Ｒ（ｓ，ｎ）よりも多い場合は資源割当量Ｅ（ｓ，ｎ）を削減する。
ステップＰＲ４−３：割当状況テーブル４３とクラスタ定義テーブル４１を比較し、割当状況テーブル４３上のインスタンスへの資源割当量Ｅ（ｓ，ｎ）がクラスタ定義テーブル４１上の要求資源量Ｒ（ｓ，ｎ）よりも少ないインスタンスを列挙し、必要資源量Ｒ（ｓ，ｎ）が大きいものから順に以下の処理を施す。
ステップＰＲ４−３Ａ：物理サーバ３１内で要求資源量Ｒ（ｓ，ｎ）まで資源割り当てを拡張可能であれば割り当てを変更する。
ステップＰＲ４−３Ｂ：資源割り当てを拡張不可能であれば、割当状況テーブル４３から該当インスタンスを削除する処理、即ち、次の処理で新規と同様の割当処理を行う。
ステップＰＲ４−４：割当状況テーブル４３とクラスタ定義テーブル４１を比較し、クラスタ定義テーブル４１上に含まれ割当状況テーブル４３に含まれない、即ち、(新規に追加された、若しくはステップＰＲ４−３において一旦削除されたインスタンスを仮想サーバ群Uに登録する。
ステップＰＲ４−５：ステップＰＲ４−４以降の処理は、手順（ＰＲ２）のＰＲ２−２以降と同様である。
【００５５】
図１３及び図１４は、クラスタ構成更新時の再割当処理を説明するフローチャートである。図１３において、ステップＳ１０１は、割当状況テーブル４３のインスタンスを順に選択する。ステップＳ１０２は、選択されたインスタンスがクラスタ定義テーブル４１上に存在するか否かを判定する。ステップＳ１０２の判定結果がＹＥＳであると、ステップＳ１０３は、クラスタ定義テーブル４１上の要求資源量Ｒ（ｓ，ｎ）が割当状況テーブル４３上の割当済み資源量Ａ（ｋ）より少ないか否かを判定し、判定結果がＮＯであると処理はステップＳ１０１へ戻る。一方、ステップＳ１０３の判定結果がＹＥＳであると、ステップＳ１０４は、インスタンスを割当調整候補に登録し、インスタンスの割当量を縮小する。ステップＳ１０２の判定結果がＮＯであると、ステップＳ１０５は、インスタンスを削除候補として登録し、このインスタンスを割当状況テーブル４３から削除する。ステップＳ１０３，１０４，１０５のいずれかの後、処理はステップＳ１０１へ戻る。
【００５６】
ステップＳ１０１は、割当状況テーブル４３の全てのインスタンスについてステップＳ１０２〜Ｓ１０４の処理が完了すると、処理はステップＳ１０６へ進む。ステップＳ１０６は、割当状況テーブル４３の物理サーバ３１を順に選択する。ステップＳ１０７は、物理サーバ３１に割り当てられたインスタンスの要求資源量Ｒ（ｓ，ｎ）をクラスタ定義テーブル４１から調査する。ステップＳ１０８は、インスタンスの要求資源量Ｒ（ｓ，ｎ）の大きい順に物理サーバ３１を選択する。
【００５７】
ステップＳ１０９は、要求資源量Ｒ（ｓ，ｎ）が割当済資源量Ａ（ｋ）より大きいか否かを判定する。ステップＳ１０９の判定結果がＹＥＳであると、ステップＳ１１０は、その物理サーバ３１上で資源量を要求資源量Ｒ（ｓ，ｎ）まで拡張可能であるか否かを判定する。ステップＳ１１０の判定結果がＹＥＳであると、ステップＳ１１１は、その物理サーバ３１を割当調整候補として登録し、インスタンスの割当量を拡大する。一方、ステップＳ１１０の判定結果がＮＯであると、ステップＳ１１２は、インスタンスを割当候補として登録し。このインスタンスを割当状況テーブル４３から削除する。ステップＳ１０９の判定結果がＮＯ、又は、ステップＳ１１１又はＳ１１２の後、処理はステップＳ１０８へ戻る。
【００５８】
ステップＳ１０８において、クラスタ定義テーブル４１の全てのインスタンスについてステップＳ１０９〜Ｓ１１２の処理が完了すると、処理はステップＳ１０６へ戻る。ステップＳ１０６において、割当状況テーブル４３の全てのインスタンスについてステップＳ１０７〜Ｓ１１２の処理が完了すると、処理は図１４に示すステップＳ１１３へ進む。
【００５９】
図１４において、ステップＳ１１３は、クラスタ定義テーブル４１上のインスタンスを順に選択する。ステップＳ１１４は、選択されたインスタンスが割当状況テーブル４３上に存在するか否かを判定し、判定結果がＹＥＳであると処理はステップＳ１１３へ戻る。ステップＳ１１４の判定結果がＮＯであると、ステップＳ１１５は、インスタンスを割当候補として登録し、処理はステップＳ１１３へ戻る。ステップＳ１１３において、クラスタ定義テーブル４１の全てのインスタンスについてステップＳ１１４及びＳ１１５の処理が完了すると、処理はステップＳ１１６へ進む。ステップＳ１１６は、再割当処理を行い、処理は終了する。
【００６０】
この手順（ＰＲ４）により、インスタンスの移動をできるだけ少なくすると共に、できるだけ資源利用効率を高くすることができる。
【００６１】
尚、以上の処理は全て割当状況の更新を行うものである。インスタンスの起動や終了、移動といった処理は、全てのテーブル更新が完了した時点で更新前後のテーブルの差分を調査して一括で行う。
【００６２】
図１５は、本実施例で利用する物理サーバ構成及びクラスタ構成を示す図である。図１５（ａ）は物理サーバ構成を示し、図１５（ｂ）はクラスタ構成を示す。ここでは説明の便宜上、物理サーバ３１の台数は４台であり、夫々の資源量、即ち、物理サーバ機能Ｐ（ｋ）は５０である。又、配備されるクラスタはＡ〜Ｄの４つである。クラスタＡは３つのインスタンスからなり、（２＋１）冗長構成となっている。クラスタＢは２つのインスタンスからなり、資源量としては冗長性はないが単一障害に際しての縮退運転が可能となっている。クラスタＣ，Ｄはいずれも冗長構成となっていない。このような物理サーバ構成及びクラスタ構成の場合のクラスタ定義テーブル４１は図２のようになり、物理サーバ定義テーブル４２は図３のようになる。
【００６３】
初期割り当ての一例として、割当順序はインスタンス数が多い順で、且つ、同数なら資源量が多い順となるので、Ａ→Ｂ→Ｃ→Ｄとなる。図１６は、初期割り当て時の割当手順を示す図である。
【００６４】
図１６（ａ）は、クラスタＡの割り当てを示し、（１）のインスタンス（Ａ，１）をサーバ名が物理１の物理サーバ３１に割り当て、（２）のインスタンス（Ａ，２）の割り当てではサーバ名が物理１以外の物理サーバ３１から選択して割り当て（この例では物理２に割り当て）、（３）のインスタンス（Ａ，３）の割り当てはサーバ名が物理１，２以外の物理サーバ３１から選択して割り当てる（この例では物理３に割り当てる）。
【００６５】
図１６（ｂ）は、クラスタＢの割り当てを示し、（４）のインスタンス（Ｂ，１）の割り当てはサーバ名が物理１，２，３のいずれかの物理サーバ３１に割り当てた場合に物理サーバ３１の余剰分が最小になるのでいずれかを選択して割り当て（この例では物理１に割り当て）、（５）のインスタンス（Ｂ，２）の割り当てはサーバ名が物理１の物理サーバ３１を避けて、余剰が最小になるサーバ名が物理２，３の物理サーバ３１を選択して割り当てる（この例ではサーバ名が物理２の物理サーバ３１を割り当てる）。
【００６６】
図１６（ｃ）は、クラスタＣの割り当てを示し、（６）のインスタンス（Ｃ，１）の割り当てはサーバ名が物理１の物理サーバ３１に割り当てた場合が余剰分最小なのでサーバ名が物理１の物理サーバ３１を選択して割り当てる。
【００６７】
図１６（ｄ）は、クラスタＤの割り当てを示し、（７）のインスタンス（Ｄ，１）の割り当てはサーバ名が物理２の物理サーバ３１に割り当てた場合が余剰分最小なのでサーバ名が物理２の物理サーバ３１を選択して割り当てる。
【００６８】
この結果作成される割当状況テーブル４３は、図４のようになる。
【００６９】
次に、物理サーバ３１の削減等による障害発生時に資源が十分に残っている場合について図１７と共に説明する。図１７は、障害発生時に資源が十分残っている場合の割当手順を示す図である。
【００７０】
図１６（ｄ）のようにクラスタが物理サーバ３１に割り当てられた状態で、図１７（ａ）に示すようにサーバ名が物理１の物理サーバ３１で障害が発生したとする。この障害発生により、インスタンス
（Ａ，１），（Ｂ，１），（Ｃ，１）の再割当が必要となる。
【００７１】
先ず、再割当優先度判定テーブル４４を作成する。判定が必要となるクラスタＡ，Ｂ，Ｃで再割当が必要なインスタンスを分類し、既にそのクラスタ内で割り当てられているインスタンスの資源割当量の合計をクラスタ割当量に設定する。このクラスタ割当値とクラスタ保証値との比を性能達成度Ｔ（ｓ）とする。
【００７２】
図１７（ｂ）に（１１）で示すように、作成した再割当優先度判定テーブル４４より、最初に処理すべきクラスタはクラスタＣとなる。そしてクラスタＣ内で再割当が必要なインスタンスとしてこの場合唯一のインスタンス（Ｃ，１）が選択される。稼働中の物理サーバ３１内でインスタンス（Ｃ，１）が割当可能なのは物理サーバ３１なので、インスタンス（Ｃ，１）は物理サーバ３１に割り当てられ、再割当候補から除外される。
【００７３】
又、図１７（ｂ）に（１２）で示すように、再度インスタンス（Ａ，１），（Ｂ，１）で再割当優先度判定テーブル４４を作成する。次に処理するクラスタとしてクラスタＢが選択され、インスタンスとしてはインスタンス（Ｂ，１）が選択される。稼働中の物理サーバ３１内で（Ｂ，１）が割り当て可能なのは、サーバ名が物理３の物理サーバ３１のみなので (サーバ名が物理２の物理サーバ３１はインスタンス（Ｂ，２）が存在するため選択できないので）、サーバ名が物理３の物理サーバ３１に割り当てられ、インスタンス（Ｂ，１）は再割当候補から除外される。最後にインスタンス（Ａ，１）の処理を行う。稼働中の物理サーバ３１にインスタンス（Ａ，１）が割当可能な物理サーバ３１は存在しない。非稼働中の物理サーバ３１を含めて探索すると、サーバ名が物理４の物理サーバ３１に割当が可能であるため、このサーバ名が物理４の物理サーバ３１に割り当てられる。
【００７４】
図１７（ｃ）は、再割当優先度判定テーブル４４の状態を図１７（ｂ）に対応させて示す。
【００７５】
次に、物理サーバ３１の削減等による障害発生時に十分な資源が残っていない、即ち、資源が不足している場合について図１８と共に説明する。図１８は、障害発生時に資源が不足している場合の割当手順を示す図である。
【００７６】
図１７の場合、冗長性及び要求資源量を満たすことが可能なだけの予備資源があったが、図１８の場合は十分な資源が確保できないものとする。一例として、図１７の場合にサーバ名が物理４の物理サーバ３１が存在しない場合の割当手順を説明する。図１８（ａ）は、図１７（ａ）と同じである。
【００７７】
先ず、図１７（ｃ）の場合と同様に図１８（ｃ）に示す再割当優先度判定テーブル４４を作成する。図１８（ｂ）に（１１）で示すように、作成した再割当優先度判定テーブル４４より、最初に処理するべきクラスタはクラスタＣとなる。クラスタＣ内で再割当が必要なインスタンスとしてこの場合唯一のインスタンス（Ｃ，１）が選択される。稼働中の物理サーバ３１内でインスタンス（Ｃ，１）が割当可能なのはサーバ名が物理３の物理サーバ３１なので、インスタンス（Ｃ，１）はサーバ名が物理３の物理サーバ３１に割り当てられ、再割当候補から除外される。
【００７８】
図１８（ｂ）に（１２）で示すように、再度インスタンス（Ａ，１），（Ｂ，１）で再割当優先度判定テーブル４４を作成する。次に処理するクラスタとしてクラスタＢが選択され、インスタンスとしてはインスタンス（Ｂ，１）が選択される。稼働中の物理サーバ３１内でインスタンス（Ｂ，１）が割当可能なのは、サーバ名が物理３の物理サーバ３１のみであり、サーバ名が物理３の物理サーバ３１はインスタンス（Ｂ，２）が存在するため選択できないので、サーバ名が物理２の物理サーバ３１に割り当てられ、インスタンス（Ｂ，１）は再割当候補から除外される。
【００７９】
図１８（ｂ）に（１４）で示すように、最後にインスタンス（Ａ，１）の処理を行う。稼働中の物理サーバ３１内でインスタンス（Ａ，１）が割当可能な物理サーバ３１は存在しない。非稼働中の物理サーバ３１を含めて探索しても割当可能な物理サーバ３１はない。更に、冗長性を無視しても要求資源量を確保可能な物理サーバ３１が存在しないため、最大の資源確保が可能なサーバ名が物理２の物理サーバ３１上に確保可能な最大の資源を割り当てる。
【００８０】
次に、物理サーバ３１の増加等による物理サーバ３１の障害回復時の割当手順を、図１９と共に説明する。図１９は、障害回復時の割当手順を説明する図である。
【００８１】
ここでは、図１８において障害が完全に回復できない場合に、その後の障害回復により資源の再割当が行われる場合について説明する。図１９では、図１８においてサーバ名が物理１の物理サーバ３１が復旧されるものとする。
【００８２】
先ず、処理対象のインスタンスの探索を行うと、インスタンス（Ａ，１）の割当済資源量が要求資源量と異なるため、インスタンス（Ａ，１）が選択される。そして、この選択されたインスタンス（Ａ，１）に基づいて再割当優先度判定テーブル４４を作成する。
【００８３】
稼働中の物理サーバ３１内にインスタンス（Ａ，１）が割当可能な物理サーバ３１は存在しない。非稼働中の物理サーバ３１を含めて探索すると、サーバ名が物理１の物理サーバ３１に割当が可能であるため、サーバ名が物理１の物理サーバ３１にインスタンス（Ａ，１）が割り当てられる。
【００８４】
尚、インスタンスを割り当てる物理サーバ３１を決定する際には、一旦割当を解除した上で再割当という手順を踏むが、実際の再割当作業においては、インスタンスを物理サーバ３１間で移動させるようにしても良い。
【００８５】
図２０は、クラスタ構成の変更時の割当手順を示す図である。図２０（ａ）はクラスタ定義テーブル４１を示し、図２０（ｂ）はクラスタの割り当てを示し、図２０（ｃ）は再割当優先度判定テーブル４４を示す。ここでは、上記実施例の処理を実施した後に、クラスタＡのインスタンスに割り当てる資源量を増加させる場合を例にとって説明する。又、変更されるインスタンスは（Ａ，１），（Ａ，２），（Ａ，３）であるものとする。インスタンス（Ａ，１）は、現在の物理サーバ３１内では拡張不可能なため、再割当が行われる。インスタンス（Ａ，２），（Ａ，３）は、現在の物理サーバ３１内で拡張可能なため、割当済みの物理サーバ３１はそのままで割当量の拡張が行われる。そして、インスタンス（Ａ，１）の再割当処理が行われ、結果としてサーバ名が物理４の物理サーバ３１に割り当てられる。
【００８６】
尚、インスタンスを割り当てる物理サーバ３１を決定する際には、一旦割当を解除した上で再割当という手順を踏むが、実際の再割当作業においては、インスタンスを物理サーバ３１間で移動させるようにしても良い。
【００８７】
尚、本発明は、以下に付記する発明をも包含するものである。
（付記１）
提供するべき仮想化資源を複数の物理サーバに割り当てるコンピュータによる資源割り当て方法であって、
任意の１つの物理サーバの障害を認識するステップと、
該障害が認識された物理サーバで冗長構成の仮想化資源を検索するステップと、
該任意の１つの物理サーバ以外の物理サーバの中から冗長構成が可能であり、且つ、該仮想化資源を割り当て可能な物理サーバを決定するステップと
を該コンピュータに実行させることを特徴とする、コンピュータによる資源割り当て方法。
（付記２）
該物理サーバを決定するステップは、該障害発生時における冗長性及び資源効率と配備時間を考慮したインスタンス配置設計を行うことを特徴とする、付記１記載の資源割り当て方法。
（付記３）
該物理サーバを決定するステップは、クラスタ構成変更時の冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行い、クラスタは冗長性を意識して設計したインスタンス群であることを特徴とする、付記１記載の資源割り当て方法。
（付記４）
該物理サーバを決定するステップは、
該障害が発生した物理サーバ内のインスタンスを再割当候補に選択し、
該障害を発生した物理サーバ内のインスタンスの割当を解除し、
再割当処理を行い、
利用可能な物理サーバの資源が存在すれば、該障害が発生した物理サーバを別の物理サーバに割り当て直すことで障害から回復させることを特徴とする、付記１記載の資源割り当て方法。
（付記５）
提供するべき仮想化資源を複数の物理サーバに割り当てる資源割り当て装置であって、
任意の１つの物理サーバの障害を認識する認識手段と、
該障害が認識された物理サーバで冗長構成の仮想化資源を検索する検索手段と、
該任意の１つの物理サーバ以外の物理サーバの中から冗長構成が可能であり、且つ、該仮想化資源を割り当て可能な物理サーバを決定する決定手段とを備えたことを特徴とする、資源割り当て装置。
（付記６）
該決定手段は、該障害発生時における冗長性及び資源効率と配備時間を考慮したインスタンス配置設計を行うことを特徴とする、付記５記載の資源割り当て装置。
（付記７）
該決定手段は、クラスタ構成変更時の冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行い、クラスタは冗長性を意識して設計したインスタンス群であることを特徴とする、付記５記載の資源割り当て装置。
（付記８）
該決定手段は、
該障害が発生した物理サーバ内のインスタンスを再割当候補に選択する手段と、
該障害を発生した物理サーバ内のインスタンスの割当を解除する手段と、
再割当処理を行う手段とを含み、
利用可能な物理サーバの資源が存在すれば、該障害が発生した物理サーバを別の物理サーバに割り当て直すことで障害から回復させることを特徴とする、付記５記載の資源割り当て装置。
（付記９）
提供するべき仮想化資源を複数の物理サーバに割り当てる割当処理をコンピュータに行わせるプログラムであって、
任意の１つの物理サーバの障害を認識する手順と、
該障害が認識された物理サーバで冗長構成の仮想化資源を検索する手順と、
該任意の１つの物理サーバ以外の物理サーバの中から冗長構成が可能であり、且つ、該仮想化資源を割り当て可能な物理サーバを決定する手順と
を該コンピュータに実行させることを特徴とする、プログラム。
（付記１０）
該物理サーバを決定する手順は、該障害発生時における冗長性及び資源効率と配備時間を考慮したインスタンス配置設計を行うことを特徴とする、付記９記載のプログラム。
（付記１１）
該物理サーバを決定する手順は、クラスタ構成変更時の冗長性、資源効率及び配備時間を考慮したインスタンス配置設計を行い、クラスタは冗長性を意識して設計したインスタンス群であることを特徴とする、付記９記載のプログラム。
（付記１２）
該物理サーバを決定する手順は、
該障害が発生した物理サーバ内のインスタンスを再割当候補に選択し、
該障害を発生した物理サーバ内のインスタンスの割当を解除し、
再割当処理を行い、
利用可能な物理サーバの資源が存在すれば、該障害が発生した物理サーバを別の物理サーバに割り当て直すことで障害から回復させることを特徴とする、付記９記載のプログラム。
【００８８】
以上、本発明を実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは言うまでもない。
【図面の簡単な説明】
【００８９】
【図１】本発明の第１実施例における仮想環境管理システムの概略構成を示すブロック図である。
【図２】クラスタ定義テーブルの一例を示す図である。
【図３】物理サーバ定義テーブルの一例を示す図である。
【図４】割当状況テーブルの一例を示す図である。
【図５】再割当優先度判定テーブルの一例を示す図である。
【図６】初期割当処理をより詳細に説明するフローチャートである。
【図７】障害発生時の再割当処理を説明するフローチャートである。
【図８】再割当処理を説明するフローチャートである。
【図９】再割当処理を説明するフローチャートである。
【図１０】再割当処理を説明するフローチャートである。
【図１１】再割当優先度判定テーブル構築処理を説明するフローチャートである。
【図１２】障害回復時の再割当処理を説明するフローチャートである。
【図１３】クラスタ構成更新時の再割当処理を説明するフローチャートである。
【図１４】クラスタ構成更新時の再割当処理を説明するフローチャートである。
【図１５】実施例で利用する物理サーバ構成及びクラスタ構成を示す図である。
【図１６】初期割り当て時の割当手順を示す図である。
【図１７】障害発生時に資源が十分に残っている場合の割当手順を示す図である。
【図１８】障害発生時に資源が不足している場合の割当手順を示す図である。
【図１９】物理サーバの障害回復時の割当手順を示す図である。
【図２０】クラスタ構成の変更時の割当手順を示す図である。
【符号の説明】
【００９０】
１      仮想環境管理システム
２      管理サーバ
３      仮想データセンタ
４      クライアント
５      ネットワーク
３１      物理サーバ
３５      仮想サーバ
【図１】
0005211766.tif 000003
【図２】
0005211766.tif 000004
【図３】
0005211766.tif 000005
【図４】
0005211766.tif 000006
【図５】
0005211766.tif 000007
【図６】
0005211766.tif 000008
【図７】
0005211766.tif 000009
【図８】
0005211766.tif 000010
【図９】
0005211766.tif 000011
【図１０】
0005211766.tif 000012
【図１１】
0005211766.tif 000013
【図１２】
0005211766.tif 000014
【図１３】
0005211766.tif 000015
【図１４】
0005211766.tif 000016
【図１５】
0005211766.tif 000017
【図１６】
0005211766.tif 000018
【図１７】
0005211766.tif 000019
【図１８】
0005211766.tif 000020
【図１９】
0005211766.tif 000021
【図２０】
0005211766.tif 000022