JP5417287B2 - 計算機システム、及び、計算機システムの制御方法 - Google Patents

Description

本発明は、計算機システム、及び、計算機システムの制御方法に係り、特に、仮想計算機に対するリソースの割当を制御する計算機システム、及び、仮想計算機に対するリソースの割当方法に関するものである。

情報化社会の発展に伴って、企業の情報処理システムやデータセンタ等において、複数のサーバを集約して設置する傾向になってきており、かつ、サーバの設置台数も増加の一途を辿っている。しかも、サーバの設置台数の増加にしたがって、サーバの運用管理に必要な労力も増加し、その結果、管理コストも無視できないものになっている。

そこで、サーバの運用効率を改善するために、計算機を仮想化する技術が注目されるようになってきている。仮想化された計算機を実現するアーキテクチャ或いはソフトウェアは、計算機のプロセッサや記憶装置などの物理リソースを仮想化して複数の仮想計算機を稼働させるものであり、詳しくは、物理リソースを論理的に分割し、分割されたリソースを複数の仮想計算機の夫々に割り当てるというものである。計算機に仮想化環境を実現する仮想化ソフトウェアとして、Ｖｉｒｔａｇｅ、ＶＭｗａｒｅ、Ｈｙｐｅｒ−Ｖ（以上、商標名）などのハイパバイザが知られている。

複数の仮想計算機の夫々は、分割されたリソースを利用して、ＯＳやアプリケーションプログラムを稼働することができる。したがって、物理サーバの運用効率が改善され、その結果として、計算機の設置数を削減できるという利点がある。

物理サーバの仮想化技術を利用した事業形態として、サーバホスティングサービスがある。これは、物理サーバのリソースの一部を、ある期間、ユーザに貸し出す事業形態である。サーバホスティングサービスの事業者は、データセンタに複数のサーバを集約して設置し、リソースの管理者は、複数のユーザからのリソース割当て要求に応じて要求があったリソース量を確保しユーザが利用する仮想サーバに割当てるようにしている。

ユーザは、リソースが割当てられた仮想計算機を利用して業務システムを稼働させる。リソースの管理者は、複数の仮想計算機同士で一台の物理的なコンピュータのリソースを奪い合うことを防ぐため、複数の仮想サーバが将来的に利用するリソース量をスケジュール管理している。

そして、リソース管理者は、ユーザが業務システムの利用を開始する日時までに、仮想計算機をユーザが要求するリソース量の割当てが可能な物理サーバにデプロイする。

リソース管理者は、複数の仮想化環境を一元管理することができる管理システムを導入しており、この管理システムは、リソースの空き状況から仮想計算機のデプロイ先となる物理サーバを特定することができる。

ユーザに割当てるリソース量が不足した時には、リソース管理者は、ユーザとの間の契約や業務システムの優先度などに基づき、リソース量を複数の仮想サーバ間で調整するようにしている。しかしながら、リソース管理者が、ユーザが要求するリソース量を確保できないと判断した場合には、そのことをユーザに早く通知しなければならい。

仮想サーバにリソースを確保するための従来技術として、例えば、特開２００５−３０９６４４号公報に記載のリソース制御システムが存在する。

このものは、業務システムが稼働し、割当てられるリソース量が動的に変化する仮想サーバのリソース使用状況を、リソース制御システムが定期的に収集し、使用状況から仮想サーバが必要とするリソース量を算出し、算出結果に基づいて、仮想サーバに割当てたリソースから余分なリソース量を回収することを特徴とする。

特開２００５―３０９６４４号公報

従来技術に係るリソース管理システムは、物理計算機のリソースの空き状況を計測して、リソースを仮想計算機に確保しようとするものであるが、他の仮想計算機が一時的にリソースを使用していると、目的の仮想計算機に対してリソースをその時には確保できないと判断してしまうことがある。仮想計算機が、大きなリソース量を一度に確保しようとする時には、この傾向は益々顕著となる。しかしながら、時間を均せば、物理計算機のリソース量には余裕があり、目的の仮想計算機にリソースを十分確保できるケースも多々ある。

そこで、本発明は、物理計算機のリソースの仮想計算機に対する割当てを効率的に実行可能な計算機システム、及び、その制御方法を提供することを目的とするものである。

本発明の他の目的は、リソース量が一時的に不足していても、実質的にはリソース量に余裕がある場合を判別して、リソースを仮想計算機に割当てることができる計算機システム、及びその制御方法を提供することにある。

前記目的を達成するために、本発明は、計算機システムが、仮想計算機に保証するリソース量を一度に確保できる物理計算機がある場合は、当該物理計算機を前記仮想計算機に配置し、前記必要リソース量を一度に確保できる物理計算機がない場合は、前記必要リソース量より少ないリソース量を徐々に増加させてリソース確保しながら、前記仮想計算機の稼働開始までに、前記必要リソース量を確保できる物理計算機を決定し、この決定された物理計算機を前記仮想計算機に配置することを特徴とするものである。

本発明によれば、物理計算機のリソースの仮想計算機に対する割当てを効率的に実行可能な計算機システム、及び、その制御方法を提供することができ、リソース量が一時的に不足していても、実質的にはリソース量に余裕がある場合を判別して、リソースを仮想計算機に割当てることができる計算機システム、及び、その制御方法を提供することができる。

本発明の第１の実施形態に係る計算機システムのハードウェアブロック図である。 管理計算機１００、及び、物理計算機１０１に共通なハードウェア構成を示すブロック図である。 仮想計算機リソーステーブル２００の一例である。 業務テーブル３００の一例である。 物理計算機リソーステーブル４００の一例である。 対応テーブル５００の一例である。 管理対象物理計算機１０１にリソース確保用プール１１４を生成する処理を示すフローチャートである。 リソース確保用プールにリソースの確保を行う処理のフローチャートである。 リソース確保部１０４がリソース確保用プールに、仮想計算機が要求したリソース量を徐々に確保するための処理（図８のステップ９０２）の詳細なフローチャートである。 仮想計算機が行う業務システムの優先度に応じて、仮想計算機に、リソース確保用プールからリソースを配分する処理のフローチャートである。 仮想計算機が実行する業務システムのシステム構成に応じて、仮想計算機に、リソース確保用プールからリソース配分する処理のフローチャートである。 リソースの仮想計算機に対する割当をキューによって管理する処理のフローチャートである。 リソース確保用プール１１４から仮想計算機１１３へ確保したリソース量を引き継ぐための処理のフローチャートである。 リソース確保用プール１１４に、仮想計算機に必要なリソース量を確保できるか否かを、リソース確保処理の実行前に検証するためのフローチャートである。 仮想サーバ１１３を別の管理対象物理サーバ１０１に移動する要求を処理するためのフローチャートである。 仮想サーバ１１３の削除処理を実施するフローチャートである。 物理サーバを省電力モードにする際に、物理サーバから仮想サーバを退避させる際のフローチャートである。 本発明の他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。 本発明の更に他の実施形態に係る計算機システムのハードウェアブロック図である。

次に、本発明の実施形態を添付図面にしたがって説明する。図１は、本発明の第１の実施形態に係る計算機システムのハードウェアブロック図である。この計算機システムは、複数の物理サーバ１０１と、物理サーバのリソースの管理を主に実行する管理サーバ１００と、管理端末１０２と、これらを互いに接続するネットワーク１１５と、を備えている。

物理サーバ１０１には仮想化ソフトウェアが搭載されている。仮想化ソフトウェアは、物理計算機のＯＳ上で動作可能な複数の計算機を仮想的に作り出すものであり、このように仮想的に作り出された計算機を仮想計算機、又は、仮想機械という。仮想化ソフトウェアは、物理サーバのリソースを複数の領域に分割し、分割した領域を利用して複数の仮想的計算機が稼働可能な環境を実現する。

仮想計算機には、サーバとしてのものと、クライアントとしてのものがある。前者を仮想サーバといい、以後、物理サーバに複数の仮想サーバが設定される形態に基づいて本発明を説明する。ただし、仮想計算機であれば仮想サーバに限定せずいずれの用途であってもよく、仮想計算機をクライアント目的で使用してもよい。

仮想サーバは、自身に割当てられたリソースを利用して、ＯＳやアプリケーションを稼働することによって、あたかも一台の物理サーバであるかのように振る舞う。リソースには、プロセッサ、メモリ、ストレージ(ハードディスクやＳＳＤなど）、そして、ネットワークなどがある。

サーバの仮想化技術によって、１台の物理的なサーバ上に、Ｗｅｂサーバ、メールサーバなど、利用目的、ＯＳが異なる複数の仮想的計算機環境を構築することができる。管理サーバ１００は、管理対象としての物理サーバ１０１のリソースの仮想サーバに対する割当てを管理する。

図２は、管理サーバ１００、及び、物理サーバ１０１に共通なハードウェア構成を示したブロック図である。管理サーバ１００と管理対象物理サーバ１０１は、一般的な計算機と同様なハードウェア構成を備えている。

サーバは、ＣＰＵ６００と、主記憶装置６０１と、ネットワークアダプタ６０２と、ストレージアダプタ６０３と、ストレージデバイス６０４と、そして、これらを互いに接続する共有バス６０５と、を備えている。

ネットワークアダプタ６０２は管理ネットワーク１１５Ａに接続しており、ネットワーク１１５Ａを介して、ＣＰＵ６００は他のサーバに接続可能である。

ストレージアダプタ６０３は、ＳＡＮなどのストレージネットワーク１１５Ｂが接続している。したがって、ＣＰＵ６００は、ストレージネットワーク１１５Ｂを介して外部ストレージ装置に接続可能である。

物理サーバ１０１のストレージデバイス６０４には、仮想化ソフトウェアなどのリソース管理プログラムが格納されている。仮想化ソフトウェアは、リソースをリソースプールにプールし、リソースプールからリソース量を仮想サーバに割当てる処理を実行する。すなわち、仮想サーバがリソースプールに対応付けられていると、仮想サーバへのリソースの割当は、リソースプールから行われる。後述するリソース確保用プール１１４は、リソースプールをリソース確保目的に利用したプールのことである。

物理サーバ１０１は、図１に示すように、仮想化ソフトウェアを実行することにより、仮想サーバ１１３に割当てるリソースを物理サーバから確保するためのリソース確保用プール１１４と、リソース確保用プール１１４から仮想サーバ１１３へのリソースの割当てやリソース確保用プール１１４へのリソースの確保などのリソース管理処理を実行するリソース制御部１２０とを、計算機環境に構築する。

仮想サーバ１１３やリソースプールへ割当てられるリソース量を定義或いは設定するためのパラメータの一例として、「保証値」がある。保証値は、仮想サーバ１１３やリソースプールへの割当が保証されるリソース量に相当するパラメータである。したがって、ある仮想サーバ或いはリソースプールが他の仮想サーバとの間とでリソースを競合する状況になっても、前者の仮想サーバ或いはリソースプールに対するリソースの割当ては、保証値の範囲内で保証される。保証値は、仮想化ソフトウェアの備えるリソース割当てパラメータのひとつであり、一般に予約値または下限値とも呼ばれる。

管理サーバ１００は、仮想サーバに対する必要リソース量の確保のための管理・制御処理を実行して、仮想サーバのデプロイ先となる物理サーバを決定するなどのリソース管理処理を実行する。

管理サーバ１００は、リソース確保用プールに、仮想サーバの必要リソース量の目安となる予約値を設定する。予約値に相当するリソース量を確保できたリソース確保用プール１１４を有する物理サーバを仮想サーバのデプロイ先として決定する。

管理対象物理サーバのリソース制御御部１２０は、リソース確保用プール１１４から、予約値に相当するリソース量を、仮想サーバ１１３を起動させる際に、仮想サーバ１１３に確保する制御を実施する。なお、リソース量の管理は、物理サーバのプロセッサやメモリ、Ｉ／Ｏなどのリソースを論理ブロックに分割することに基づいて実行される。

管理サーバ１００は、全ての管理対象物理サーバ１０１の仮想サーバ１１３とリソース確保用プール１１４とを、仮想サーバ１１３に対する必要リソース量の確保の可否判定のために制御する。仮想サーバに必要リソース量を確保できる物理サーバが仮想サーバのデプロイ先となる。リソース確保用プール１１４は、複数の管理対象物理サーバ１０１のそれぞれに設定されている。

図１に示すように、管理サーバ１００のＣＰＵ６００は、ストレージデバイス６０４に記憶されている管理プログラムを主記憶装置６０１で取り込んで実行することにより、リソース管理部１０３と、リソース確保部１０４と、業務管理部１０５と、リソース割当部１１６と、プール制御部１０６と、プール生成部１０７と、仮想化環境管理部１０８と、性能情報収集部１０９と、構成情報収集部１１０と、そして、配置決定部１１１となど、物理サーバのリソースに対する種々の制御・管理機能を実現する。

さらに、管理サーバ１００は、ストレージ装置６０４に、当該制御・管理機能の実行に必要な管理データを有する管理テーブルを格納している。管理テーブルは、仮想サーバリソーステーブル２００と、物理サーバリソーステーブル４００と、業務テーブル３００と、仮想サーバとリソース確保用プールとの対応テーブル５００と、を含んでいる。

リソース管理部１０３は、他の処理部に対する統括機能やリソース管理の上位処理を実行する。リソース確保部１０４は、仮想サーバ１１３へ割当てるリソースをリソース確保用プール１１４に確保する処理を実行する。業務管理部１０５は、仮想サーバ１１３が実行する業務システムを管理するための処理を実行する。

リソース割当部１１６は、管理サーバ１００が管理するリソースを仮想サーバ１１３へ割当てる制御を、管理対象物理サーバ１０１のリソース制御部１２０を介して実行する処理部である。

プール制御部１０６は、リソース確保用プール１１４のリソース量を制御する処理を、リソース制御部１２０を介して実行する処理部である。

プール生成部１０７は、管理対象物理サーバ１０１にリソース確保用プール１１４を生成する処理を実行する。仮想化環境管理部１０８は、リソース制御部１２０を制御するＩ／Ｆを管理サーバ１００に提供する。管理サーバ１００は、ネットワーク１１５Ａを介して複数の管理対象物理サーバ１０１を制御する。

リソース確保部１０４、リソース割当部１１６、プール制御部１０６、プール生成部１０７、性能情報収集部１０９、そして、構成情報収集部１１０の各処理は、仮想化環境管理部１０８を介して管理対象物理サーバ１０１にアクセスする。

性能情報収集部１０９は、管理対象物理サーバ１０１、仮想サーバ１１３、リソース確保用プール１１４の性能情報および稼働情報を収集する処理部である。性能情報には、ＣＰＵ利用率、メモリ利用率、ストレージ容量、ストレージとの間のデータ転送速度、ネットワークのデータ転送速度や、ＣＰＵ割当て量、メモリ割当て量などの物理サーバから仮想サーバへのリソース割当て量などがある。

構成情報収集部１１０は、管理対象物理サーバ１０１、仮想サーバ１１３、リソース確保用プール１１４の構成情報を収集する処理部である。構成情報には、管理対象物理サーバ１０１のハードウェア構成、そのＷｅｂ３階構成などの論理的なシステム構成、その業務システム構成に係る情報などがある。

性能情報収集部１０９と構成情報収集部１１０は、それぞれ、所定のサンプリング間隔で管理対象に定期的にアクセスして情報を収集し、収集した情報を管理テーブルに登録する。

配置決定部１１１は、リソースを割り当てるべき仮想サーバ１１３をどの管理対象物理サーバ１０１に配置して稼働させるのかを決定する。配置決定部１１１は、仮想サーバを配置すべき物理サーバを決定する処理部である。

仮想化環境管理部１０８は、管理サーバ１００に存在していることとしたが、管理サーバ１００がネットワーク１１５を介してアクセス可能な別の物理サーバにあってもよい。この場合、管理サーバ１００のリソース確保部１０４等は当該物理サーバの仮想化環境管理部を介して管理対象物理サーバにアクセスする。また、仮想化環境管理部１０８は仮想サーバ１１３上にあってもよい。

なお、管理サーバの各処理部は、仮想化環境管理部１０８を介さずリソース制御部１１５のＩ／Ｆを介して管理対象物理サーバにアクセスしてもよい。

リソース制御部１２０は管理サーバ１００からコマンドを受信して、仮想サーバ１１３、リソース確保用プール１１５に対して、制御・管理処理を実行する。

管理端末１０２は、ネットワーク１１５Ａを介して、管理サーバ１００に対して、管理のための入力情報を送信し、さらに、管理サーバ１００から管理状況の出力情報を受信する。符号１１２は入力及び出力のための、キーボード、ディスプレイなどハードウェア、及び、インタフェースなどのソフトウェアからなる入出力部である。

管理ユーザは、管理端末１０２を介して、管理サーバ１００の管理対象である、管理対象物理サーバ１０１、仮想サーバ１１３、そして、リソース確保用プール１１４の性能情報や構成情報を参照したり、管理サーバ１００を介して、これら管理対象に制御・管理処理を適用する。

図３は、仮想サーバリソーステーブル２００の一例である。仮想サーバリソーステーブル２００は、仮想サーバ１１３、及び、リソース確保用プール（図２では「プール」と略記。）１１４のリソースを管理するためのものである。

仮想サーバリソーステーブル２００は、仮想サーバ・リソース確保用プールの識別欄２０１と、物理サーバの識別欄２０２と、実割当リソース量の欄２０３と、要求リソース量の欄２０４と、確保リソース量の欄２０５と、確保用フラグの欄２０６と、収集時刻の欄２０７と、確保予定リソース量欄２０８とを備えている。

仮想サーバ・リソース確保用プール識別欄２０１には、エンティティ（仮想サーバ１１３またはリソース確保用プール１１４、リソース確保用プール以外のリソースプール）を識別する情報が記録されている。この識別情報は、仮想サーバリソーステーブルの各レコードのキー情報となる。

物理サーバ識別欄２０２には、エンティティが稼働する管理対象物理サーバ１０１を識別する情報が記録される。

実割当リソース量欄２０３には、エンティティに現在割り当てられているリソース量が登録される。

確保リソース量欄２０５には、エンティティが確保したリソース量が記録される。エンティティが仮想サーバ１１３の場合は、確保リソース量は仮想サーバの既述の保証値に相当するかこれを基準としたものになる。エンティティがリソース確保用プールの場合には、確保リソース量は、リソース確保用プールの既述の保証値に相当するリソース量かこれを基準としたものになる。

もし、リソース確保用プールに仮想サーバが属している場合、リソース確保用プールの保証値はリソース確保用プールに属する仮想サーバの保証値の合算値よりも大きいのが通常である。 なお、管理サーバ１００は、物理サーバの空きリソース量を越える値を保証値としてリソース確保用プール１１４に設定することは通常できない。管理サーバ１００は、計測して取得できる現状の物理サーバの空きリソース量にもとづき、空きリソース量の範囲内でリソース確保用プールの保証値を増分していく。

要求リソース量欄２０４には、エンティティがリソース割当部１１６に割当てを要求したリソース量が登録される。監視対象物理サーバ１０１のリソース量が切迫していない場合、この要求リソース量欄２０４と実割当リソース量欄２０３の値は等しくなる。

一方、監視対象物理サーバ１０１のリソース量が切迫している状況では、リソース制御部１２０は、要求リソース量を満たすリソース量をエンティティに割当てることができないため、実割当リソース量は要求リソース量より少なくなることがある。要求リソース量が確保リソース量よりも少ない場合、通常、要求リソース量と実割当てリソース量とが等しくなる。逆に、要求リソース量が確保リソース量以上の場合、実割当てリソース量２０３が確保リソース量を下回ることは通常ない。

図３に示した実割当リソース量欄２０３と、要求リソース量欄２０４と、そして、確保リソース量欄２０５には、メモリサイズやストレージの容量を示すＧＢ（ギガバイト）が登録されているが、仮想サーバに割当てられるリソースがプロセッサ、ネットワーク等の場合は、ＣＰＵの周波数（Ｈｚ）、ディスク転送量やネットワーク転送量（ＭＢ／ｓ、パケット数／ｓ）がリソース量として記録される。リソースが複数種類に及ぶ場合には、複数種類のリソース量を組み合わせたものが記録されてもよいし、複数種類のリソース量から算出された値が記録されてもよい。

確保用フラグ欄２０６には、物理サーバから仮想サーバにリソースを割当てるためにリソースを確保するエンティティであるか否かを管理サーバ１００が区別するためのフラグ情報が記録される。

管理サーバ１００が、プールをリソース確保用プールとして設定する場合には、確保用フラグとして、「ｔｒｕｅ」を登録し、プールをリソース確保用プールとして設定しない場合には「ｆａｌｓｅ」を登録する。

仮想サーバは通常リソースの供給先であって、リソースの供給元にはならないために、通常、確保用フラグには、「ｆａｌｓｅ」が登録されるが、仮想サーバをリソースの供給元に設定する場合には、仮想サーバに対しても「ｔｒｕｅ」が設定される。例えば、リソース供給元の仮想サーバが、業務とは関係がない疑似的な負荷を受けている状態を特別プログラムによって作り出し、この擬似的な負荷に基づいて確保したリソースを業務実行用の仮想サーバに割当てる。なお、収集時刻欄２０７は、レコードの収集時刻が記憶される。

性能情報収集部１０９と構成情報収集部１１０とが仮想化環境管理部１０８を通して、管理対象物理サーバのリソース制御部１２０から情報を収集すると、これを仮想サーバリソーステーブル２００に初期登録或いは更新登録する。

プール生成部１０７が、リソース確保用プール１１４を定義して、これを仮想サーバリソーステーブル２００に登録する際に、確保用フラグ欄２０６に「ｔｒｕｅ」を設定する。

確保予定リソース量欄２０８には、エンティティの確保予定のリソース量を記憶している。リソース確保用プールやリソース確保用仮想サーバが確保することを要求されたリソース量を記憶する。確保するリソース量の目標値を示し、確保リソース量欄２０５の値は、確保予定リソース量欄２０８の値に到達するまで徐々に増加する。リソース確保用プールやリソース確保用仮想サーバに対応するリソース確保要求の予約値を合算した値を記憶する。

図４に、業務テーブル３００の一例を示す。業務テーブル３００は、仮想サーバ１１３により実行される業務内容の観点から業務システムを分類し、業務システム毎に、リソース割当て情報、リソース貸出予約情報等のリソース管理情報を記録している。

業務テーブル３００は、業務欄３０１と、業務優先度欄３０２と、要求リソース欄３０３と、予約期間欄３０４と、仮想サーバ欄３０５と、そして、システム要件欄３０６と、を備えている。

業務欄３０１には、業務システムの識別情報が記憶されている。この識別情報は、テーブルに記録されるレコードのキー情報となる。

業務優先度欄３０２には、業務システムの優先度情報が格納されている。この情報は、業務システムの重要度に応じて管理者によって設定されるものである。業務優先度は、例えば、業務システムに求められる信頼性やサービスレベル等に応じた値である。より具体的には、開発環境のリソース貸出の場合は低い優先度になり、高いサービスレベルが要求されるチケット販売システムの場合は高い優先度になる。

管理対象物理サーバ１０１に複数の業務システムが稼働している状況では、優先度に基づき、リソース割当部１１６は、リソース確保用プール１１４のリソースを業務毎の仮想サーバ１１３に割当てることによって、複数の業務システムに対してリソースの配分を妥当なものにしている。

要求リソース欄３０３には、業務システムに要求されるリソース量が登録される。
予約期間欄３０４には、業務システム欄３０１で特定される業務システムに、管理対象物理サーバ１０１からリソースの貸出を予約する時間の情報が登録される。

仮想サーバ欄３０５には、業務欄３０１で特定される業務システムを構成する仮想サーバ１１３を識別する情報が登録される。

システム要件欄３０６には、業務欄３０１で特定される業務システムに要求されるシステム要件情報が登録される。例えば、業務システムを構成する複数の仮想サーバ１１３がそれぞれ異なる管理対象物理サーバ１０１で稼働しなければならないという条件や、逆に同じ管理対象物理サーバ１０１で稼働しなければならないという条件が登録される。

前者の条件は、管理対象物理サーバ１０１のハードウェアが故障することを想定して、信頼性を高めるために設定されるものであり、後者の条件は、管理対象物理サーバ１０１のメモリの共有やキャッシュヒット率を高めて、業務の処理の高速化を図るためのものである。

業務管理部１０５は、性能情報収集部１０９と構成情報収集部１１０とが管理対象物理サーバから収集した情報に基づいて、業務テーブル３００を生成或いは更新する。

図５は、物理サーバリソーステーブル４００の一例である。物理サーバリソーステーブル４００は、物理サーバのリソース利用状況を管理するためのものである。

物理サーバリソーステーブル４００は、物理サーバ欄４０１と、全リソース量欄４０２と、空きリソース量欄４０３と、未確保リソース量欄４０４と、を含む。

物理サーバ欄４０１には、管理対象物理サーバ１０１を識別する情報が登録される。この識別情報は、物理サーバリソーステーブルの各レコードのキー情報である。

全リソース量欄４０２には、物理サーバ欄４０１で特定される、ある管理対象物理サーバ１０１の備えるリソース量の全体サイズが登録される。

空きリソース量欄４０３には、物理サーバ欄４０１で特定される、ある管理対象物理サーバ１０１の備えるリソース量のうち、仮想サーバ１１３やリソース確保用プール１１４のいずれにも割り当てられてない未使用のリソース量、すなわち、物理サーバ欄４０１（図５）と同じ物理サーバに属する実割当てリソース量欄２０３（図３）の合計値を全リソース量欄４０２から引いた値が登録される。

未確保リソース量欄４０４には、物理サーバ欄４０１で特定されたある管理対象物理サーバ１０１の備えるリソース量のうち、リソース確保用プール１１４に確保されてないリソース量が登録される。この値は、物理サーバ欄４０１（図５）と同じ物理サーバに属する確保リソース量欄２０６（図３）の合計値を全リソース量欄４０２から引いた値に相当する。

この物理サーバリソーステーブル４００は、性能情報収集部１０９と構成情報収集部１１０との収集情報に基づいてリソース管理部１０３によって生成及び更新される。

図６は、対応テーブル５００の一例である。対応テーブル５００には、仮想サーバ１１３と、仮想サーバにリソースを供給するリソース確保プール１１４（図６では「プール」と略記。）との対応関係が登録されている。配置決定部１１１が仮想サーバ１１３をデプロイすべき物理サーバ１０１を決定した段階で、仮想サーバが割当てられるリソース確保用プールを対応テーブル５００に登録する。

対応テーブル５００には、仮想サーバ欄５０１と、リソース確保用プール欄５０２がある。仮想サーバ欄５０１には、仮想サーバ１１３の識別情報が記録されている。リソース確保用プール欄５０２には、仮想サーバ欄５０１で特定される仮想サーバ１１３に、確保したリソースを割当てるためのリソース確保用プール１１４を識別する情報が登録される。

一方、仮想サーバの利用期間が終了すると、管理者は、仮想サーバのエントリを対応テーブルから削除する。この際、仮想サーバに対応していたリソース確保用プールが他の仮想サーバにも対応していない場合には、管理者はこのリソース確保用プールを対応テーブルから削除する。

図７は、プール生成部１０７（図１）の動作、すなわち、管理対象物理サーバ１０１にリソース確保用プール（図７では「プール」と略記。）１１４を生成する処理を示すフローチャートである。プール生成部１０７は、ネットワーク１１５Ａ（図２）を介してディスカバリを実行し、管理範囲に新たな管理対象物理サーバ１０１があればこの存在を検出する（ステップ７０１）。

プール生成部１０７は、検出した物理サーバ１０１にアクセスしてそのソフトウェア環境を分析し、管理対象物理サーバに仮想化環境が存在するか否かを判定する（ステップ７０２）。

プール生成部１０７が、ステップ７０２を肯定判定すると、管理対象物理サーバ１０１の構成情報、性能情報に基づいて、物理サーバ１０１にリソース確保用プール１１４が設定されているか否かを判定する（ステップ７０３）。

プール生成部１０７が、ステップ７０３を、リソース確保用のプールがない、と判定すると、物理サーバ１０１のハイパバイザ（リソース制御部１２０）にリソース確保用プール１１４の作成コマンドを供給する（ステップ７０４）。

プール生成部１０７は、作成したリソース確保用プールを管理対象として、仮想サーバリソーステーブル２００（図２）に登録する（ステップ７０５）。詳しくは、プール生成部１０７は、仮想サーバリソーステーブル２００に新たなレコードを生成し、仮想サーバ欄２０１に作成したリソース確保用プール１１４の識別子を記録し、物理サーバ２０２欄にリソース確保用プールを生成した管理対象物理サーバ１０１を記録し、確保用フラグ欄２０６に「ｔｒｕｅ」を記録する。実割当リソース量欄２０３や要求リソース量欄２０４には、性能情報収集部１０９が収集したリソース量の情報が登録される。プール生成部１０７は、確保リソース量欄２０５に予約値を設定する。

プール生成部１０７が、ステップ７０２を否定判定するとプール生成部１０７はフローチャートを終了する。ステップ７０３を、リソース確保用プールがある、と判定すると、既存のリソース確保用プールを管理対象として（ステップ７０６）、フローチャートを終了する。

図８は、リソース確保部１０４（図１）の動作、すなわち、リソース確保用プールにリソースの確保を行う処理のフローチャートである。リソース確保部１０４は、新たな仮想サーバのデプロイ先となる管理対象物理サーバを決定する際に、図８のフローチャートを実行する。

物理サーバに仮想サーバが稼働している状態では、リソース確保用プール１１４から既にリソースが仮想サーバ１１３に放出されているために、リソース確保部が仮想サーバにリソースを割当てようとする場合には、リソース確保プールには改めてリソースを確保する必要がある。

そこで、リソース確保部１０４は、新たな仮想サーバが要求するリソース量である予約値を管理端末１０２からの入力情報に基づいて決定し、リソース確保用プールに設定する予約値を算出する。

次いで、リソース確保部１０４は、予約値の大小を判定するための閾値を、主記憶装置６０１の所定領域から取得し、予約値と閾値とを比較する（ステップ９０１）。

リソース確保部１０４は、予約値が閾値以下の場合（ステップ９０１：Ｎｏ）には、図３のエンティティ識別欄２０１を参照して、確保リソース量が存在しない未使用のリソース確保用プール１１４に予約値を設定し、このリソース確保用プール１１４のリソース制御部１２０にコマンドを送信する。このコマンドの送信を受けたリソース制御部１２０は、リソース確保用プール１１４に予約値に相当するリソース量を確保する（ステップ９０６）。

この際、予約値は閾値より小さいため、管理対象物理サーバ１０１には、予約値に相当するリソース量に足る空き容量が存在するため、リソース確保部１０４は、仮想サーバの必要リソース量を一回でリソース確保用プール１１４に確保させることができる。なお、リソース確保部１０４は、閾値の代わりに物理サーバの空き容量を予約値と比較してもよい。

一方、リソース確保部１０４が、予約値を閾値超と判定すると（ステップ９０１：Ｙｅｓ）、リソース確保部１０４は、未使用のリソース確保用プール１１４のリソース制御部１２０に対して、リソース確保用プール１１４に予約値に相当するリソース量を複数回に分けて徐々に確保すべき、継続的リソース確保要求をリソース制御部１２０に送信する（ステップ９０２：詳細を図９で説明。）。

従来サーバホスティング事業者は、仮想サーバに要求リソース量を一度に割当てようとしてもこれができないことが多々あったが、ステップ９０１、９０２、９０６によれば、管理サーバは、物理サーバにデプロイしようとしている仮想サーバの要求リソース量が少ない場合には、これを一度に確保し、要求リソース量が大きい場合には、要求リソース量より少ないリソース量を継続的に累積確保することによって、目的の要求リソース量を仮想サーバの稼働開始時期までに確実に確保できるようにしている。

性能情報収集部１０９・構成情報収集部１１０は、リソース確保用プールにおけるリソース確保の進展状況を物理サーバ１０１から取得して、図２のテーブルの実割当リソース量欄２０３、要求リソース欄２０４、確保リソース量欄２０５に更新登録している。

リソース確保用プール１１４へのリソースの確保の進展にしたがって、実割当リソース量２０３、要求リソース欄２０４、確保リソース量２０５には、確保されたリソース量が更新登録される。

リソース確保用プール１１４に対する、目的リソース量の確保が完了すると、確保リソース量２０５に予約値に相当するリソース量が登録されている。

図３のプール１及びプール３はリソースの確保が完了し、仮想サーバへリソースが割当てる前の状態のものであり、プール２は、リソースが仮想サーバに放出された後、リソースが確保される前の状態のものである。

次に、リソース確保部１０４は、少なくとも一つのリソース確保用プール（図８では「プール」と略記。）について、予約値に相当する要求リソース量を確保できたか否かを、確保リソース量欄２０５（図３）を参照して判定する（ステップ９０３）。リソース確保部１０４がこの判定を肯定すると、仮想サーバをデプロイすべきリソース確保用プール１１４を決定する。

ステップ９０３において、リソース確保部１０４が、少なくとも一つのリソース確保用プールに対してリソースの確保を完了させた判定すると、この一つのリソース確保用プールの物理サーバが、仮想サーバをデプロイすべきものと決定し、一方、複数のリソース確保用プールについてリソースの確保を完了いた場合、所定の選択基準にしたがって、特定のリソース確保用プールが仮想サーバのデプロイ先として決定される。

選択基準としては、要求リソース量の確保が完了した時間的な先後、リソース確保用プールの物理サーバの空き容量（図５：４０３）の大小がある。

次いで、リソース確保部１０４は、デプロイ先として選択されなかったリソース確保用プールについて、確保されたリソース領域を解放し（ステップ９０４）、実割当リソース量欄２０３、要求リソース量欄２０４、確保リソース量欄２０５をクリアする。

閾値は、管理ユーザによって、予め、リソース確保部１０４に対して設定されることが一般的であるが、所定のデフォルト値、あるいは、閾値決定プログラムによって、管理対象物理サーバの空きリソース量（図４）、確保リソース量（図３）などに応じて、リソース確保部１０４が図８のフローチャートを実行する都度決定されてもよく、また、リソース確保部１０４が閾値を動的に変えてもよい。

例えば、管理対象物理サーバあたりの仮想サーバ数や管理対象物理サーバのスペック、物理サーバの空きサイズなどをもとに一度に確保が難しいリソース量を閾値として算出することができる。

次いで、仮想サーバのデプロイ先として決定されたリソース確保用プールのリソース制御部１２０は、確保したリソースの情報を管理サーバ１００のリソース管理部１０３に応答する（ステップ９０５）。

さらに、リソース確保部１０４は、リソース確保用プール１１４と仮想サーバ１１３との対応関係を対応テーブル５００に登録する。リソース管理部１０３は、図１のように、仮想サーバ１１３をリソース確保用プール１１４の外に設定することの他、仮想サーバをリソース確保用プール内に設定することもできる。また、リソース確保用プール内に別のリソース確保用プールを設定することもできる。すなわち、リソース確保用プールを階層化することができる。

図８を、複数の物理サーバについて、リソースの確保が実行されるものとして説明したが、管理サーバ１００が、過去に収集したリソースの割当て監視結果（図３の履歴情報）に基づいて、要求リソース量を確保する可能性が高い物理サーバから優先してリソースの確保を試みるものであってもよい。

図９は、リソース確保部１０４がリソース確保用プールに、仮想サーバが要求したリソース量を徐々に確保するための処理（図８のステップ９０２）の詳細を示すフローチャートである。

リソース確保部１０４は、前記閾値と同じか、又は、これよりも小さい係数値を決定し、係数値をリソース確保用プール１１４の保証値に加算して（ステップ１００１）、リソース確保用プールの保証値を漸増させ、これをリソース制御部１２０に送信する。リソース制御部１２０は、保証値の差分（係数値）に相当するリソース量を追加でリソース確保用プール１１４に確保する。

この係数値は一定値であってもよいし、物理サーバの切迫度、すなわち、空きリソース量（図４）に応じて、リソース確保部１０４が都度算出するものであってもよい。

リソース確保部１０４は、仮想サーバリソーステーブル（図３）のリソース確保用プールに対する確保リソース量２０５に係数値に相当するリソース量を加算し、加算後の値が要求リソース量（確保予定リソース量２０８の値）に到達したか否かを判定する（ステップ１００２）。

この判定を否定すると、その後一定時間経過した後（ステップ１００３）、ステップ１００１に戻り、リソース確保部１０４は、リソース制御部１２０に、係数値に相当するリソース量を追加確保する要求を送信する。

リソース確保部１０４が、ステップ１００１〜ステップ１００３を繰り返し実行することにより、リソース確保用プール１１４に、物理サーバにデプロイしようとしている仮想サーバの要求リソース量を継続的に確保することができる。

なお、リソース確保部１０４が、これら処理を所定回数実施しても、確保リソース量が要求リソース量に到達しない場合には、管理者は、仮想サーバにリソースを確保できない警告をユーザに対して通知する。

図８及び図９のフローチャートの結果、必要リソース量が確保されたリソース確保用プール１１４が決まると、配置決定部１１１は、仮想サーバの稼働開始時までにリソース確保用プール１１４が存在する特定物理サーバに仮想サーバをデプロイすることを決定する。

このデプロイの過程で、特定物理サーバのリソース制御部１２０は、リソース確保用プール１１４内に仮想サーバ１１３を格納して、リソース確保用プール１１４の確保済みリソース領域を仮想サーバ１１３に割当てる。この後、仮想サーバ１１３をリソース確保用プール１１４外に解放することによって、リソース確保用プール１１４のリソース量が仮想サーバ１１３に移譲される。リソース確保用プール１１４におけるリソース量の減少、仮想サーバのリソース量の増加は、図２のテーブルに登録される。

なお、リソース確保部１０４は、仮想サーバを物理サーバにデプロイする日時から、リソース確保用プールの確保済みリソース量のサンプリング間隔を調整してもよい。また、管理サーバ１００は、仮想サーバを物理サーバにデプロイする日時が近付いた際サンプリング間隔を短くして、リソースを積極的に取得するようにしてもよい。

図１０は、リソース割当部１１６のリソース割当て処理の事例であって、仮想サーバ１１３が行う業務システムの優先度に応じて、仮想サーバにリソース確保用プール１１４からリソースを配分する処理を示すフローチャートである。

リソース割当部１１６は、同一のリソース確保用プール１１４からの複数の仮想サーバへのリソース割当て、すなわち、複数の仮想サーバ１１３間でのリソースの競合を検知する（１１０１）。

次いで、リソース割当部１１６は、図４の業務テーブルを参照して、複数の仮想サーバが競合したリソースを利用して実行する業務システムを特定する（ステップ１１０２）。

次いで、リソース割当部１１６は、業務システムの優先度（図４：３０２）を取得して（ステップ１１０３）、優先度に応じて、複数の仮想サーバ間で、リソース確保用プールのリソース量を按分する（ステップ１１０４）。例えば、優先度が高い業務システムの仮想サーバのリソース確保用プールから順番に、要求されたリソース量を配分する。

次いで、リソース割当部１１６は、按分したリソース量の割当に関する要求を仮想サーバがデプロイされている物理サーバのリソース制御部１２０に送信して、複数の業務システム（仮想サーバ）それぞれの必要リソース量をリソース確保用プール１１４から配分する（ステップ１１０５）。

図１１は、リソース割当部１１６のリソース割当て処理の事例であって、仮想サーバ１１３が実行する業務システムのシステム構成に応じて、リソースをリソース確保用プールから仮想サーバに配分する処理を示すフローチャートである。業務システムのシステム構成とは、図４の業務管理テーブルに示されるシステム要件３０６に係る管理情報である。

管理者は、複数の仮想サーバを計算機システムにデプロイしようとする際、複数の仮想サーバによって実現される業務システム要件、例えば、複数の仮想計算機からなるＷｅｂ３階層システムの業務システム要件を参照し、複数の仮想計算機のリソースを纏めて確保しようとする。

その際、管理者は、異なる物理サーバに複数の仮想サーバをデプロイするか、或いは同じ物理サーバに複数の仮想サーバをデプロイするかを決定し、さらに、複数の仮想計算機のリソースを同じリソース確保用プールから取得するか、異なるプールから取得するかを決定する。そこで、仮想サーバの業務システム要件に応じて、リソース確保用プールから複数の仮想サーバにリソースを配分する制御が必要となる。

リソース割当部１１６は、業務システムのシステム構成要件情報を取得する（ステップ１２０１）。次いで、リソース割当部１１６は、リソース確保用プール１１４に確保されたリソース量を、ステップ１２０１で取得したシステム構成情報の要件を満たすように複数の仮想サーバにリソースを配分し（ステップ１２０２）、配分した値に応じてリソース量を仮想サーバに割り当てる（ステップ１２０３）。

例えば、ハードウェア故障の影響を最小化して信頼性を向上するため複数の仮想サーバ１１３を別の管理対象サーバ１０１に配置するシステム構成を要件としてもよい。逆に、高速化を目的として複数の仮想サーバ１１３を同じ管理対象物理サーバ１０１に配置するシステム構成を要件としてもよい。この場合、メモリ情報を共有でき、ネットワーク通信をメモリコピーで実現できるため高速化を図ることができる。

図１２は、リソース割当部１１６のリソース割当て処理であって、リソースの仮想サーバに対する割当をキューによって管理する処理のフローチャートである。リソース割当要求をキューイングするキューを内部的に管理しているリソース割当部１１６がリソース割当てキューから割当て要求を取り出し（ステップ１３０１）、取り出した割当て要求のリソース量を有するリソース確保用プール１１４を特定する（ステップ１３０２）。

次いで、リソース割当部１１６は、仮想サーバリソーステーブル２００で管理する情報のうち、特定したリソース確保用プール１１４に相当するレコードの確保リソース量欄２０５と確保予定リソース量欄２０８の値から割当て要求量（予約値）を減算する（ステップ１３０３）。さらに、リソース割当部１１６は、プール制御部１０６を通して、特定したリソース確保用プール１１４の保証値に割当て要求量（予約値）分減算した値を設定する。

次いで、リソース割当部１１６は、特定したリソース確保用プール１１４から割当て要求されたリソース量（予約値）を要求に対応する仮想サーバに割当てる（ステップ１３０４）。

図１３は、リソース割当部１１６のリソース割当て処理の具体例であって、リソース確保用プール１１４から確保したリソース量を仮想サーバ１１３へ引き継ぐための処理を説明するフローチャートである。

この引き継ぎは、リソース確保用プール１１４に仮想サーバ１１３を格納し、次いで、この格納を解放する過程で実行される。

リソース割当部１１６は、物理サーバに新たにデプロイしようしている仮想サーバ（Ａ）に対応する、確保したリソース量を割り当てるリソース確保用プール（Ｃ）を対応テーブル４００から特定する（ステップ１４０１）。

次に、リソース割当部１１６は、リソース確保用プール（Ｃ）の予約値に仮想サーバ（Ａ）の割当て要求リソース量（Ｄ）を加算する（ステップ１４０２）。リソース割当部１１６は、リソース確保用プール（Ｃ）に仮想サーバ（Ａ）を配置する（ステップ１４０３）。

次いで、リソース割当部１１６は、仮想サーバ（Ａ）の保証値に割当て要求リソース量（Ｄ）分の値を加算する（ステップ１４０４）。さらに、リソース割当部１１６は、リソース確保用プール（Ｃ）から仮想サーバ（Ａ）を取り出し（ステップ１４０５）、リソース割当部１１６は、リソース確保用プール（Ｃ）の保証値から仮想サーバ（Ａ）の割当て要求量（Ｄ）分を減算する（ステップ１４０６）。

リソース制御部１２０は、リソース割当部１１６からの要求によって、リソース確保用プール（Ｃ）から仮想サーバ（Ａ）に移譲される保証されたリソース割当てをリソース確保用プール（Ｃ）から仮想サーバ（Ａ）に変更する。リソース確保用プール（Ｃ）及び仮想サーバ（Ａ）のリソース量の変動は、リソース割当部１１６によってリソース管理テーブル２００に登録される。

なお、リソース確保用プールから仮想サーバへのリソースの引き継ぎを、リソース割当部１１６が、両者を同期させて、リソース確保用プール１１４の予約値を減らしながら、仮想サーバ１１３の保証値を増やして、リソース確保用プールから放出されリソースを仮想サーバがそのまま確保できるようにしてもよい。

図１４は、リソース確保用プール１１４に、仮想サーバに必要なリソース量を確保できるか否かを、リソース確保処理の実行前に検証するためのフローチャートである。

リソース確保部１０４が、リソース確保用プール１１４に、閾値（図８）を超えるリソース量を確保しようとする際、図９のフローチャートをシミュレートする。

そのために、リソース確保部１０４が、リソース確保用プールに対するリソースの確保要求を検出すると（ステップ１５０１）、物理サーバリソーステーブル４００（図５）を継続的に参照して、物理サーバの空きリソース量４０３を監視する（ステップ１５０２）。

物理サーバの空きリソース量の傾向から、リソース確保部１０４は、リソース確保用プール１１４に対する継続的なリソース量の確保の処理の過程における一回当たりのリソース量の増分（図９）を見積り、リソース確保用プール１１４の将来のリソース量の増加傾向を予測する（ステップ１５０３）。

なお、ここでは物理サーバの空きリソース量の傾向から確保リソース量の増分を見積もっているが、代わりに、実際に数回あるいは一定試行期間の間、リソース確保処理を試行的に行い、そこで確保できた値から将来的に確保可能なリソース量を見積もってもよい。

リソース確保部１０４は、予測結果に基づいて、リソース確保用プール１１４の予約値として設定された要求リソース量を、仮想サーバの起動予定日時までに確保できるか否かを判定する（ステップ１５０４）。

リソース確保部１０４が、ソース量の継続的な確保量を許容範囲内で増加させても、予定時日時までに割当て要求リソース量を確保できない、と判定すると、リソース確保部１０４は管理端末に警告メッセージを表示する（ステップ１５０５）。管理者はこの警告表示を受けて、ユーザに仮想サーバの起動開始の延期、仮想サーバの保証値の縮減を求めることができる。ユーザからの修正依頼に基づいて、管理サーバ１００は、図１４のフローチャートを再度実行し、管理者は、ステップ１５０４の肯定判定を確認した後、リソース確保用プールへの必要リソース量の確保を実際に開始すればよい。

図１５は、仮想サーバ１１３を別の管理対象物理サーバ１０１に移動する要求を処理するためのフローチャートである。プール生成部１０７は、管理対象物理サーバ（Ｄ）へ仮想サーバ（Ａ）を移動する要求を管理端末１０２から受信すると(ステップ１４０８)、対応テーブル５００を参照して、仮想サーバ（Ａ）に関連付けられたリソース確保用プールＣを特定する(ステップ１４０９)。

次いで、リソース生成部１０７は、管理対象物理サーバ（Ｄ）にリソース確保用プール（Ｃ）の予約値に基づく予約値を設定した新たなリソース確保用プール（Ｅ）を生成する（ステップ１４１０）。

さらに、リソース生成部１０７は、管理対象物理サーバ（Ｄ）に仮想サーバ（Ａ）を移動し（ステップ１４１１）、リソース確保用プール（Ｃ）を削除する（ステップ１４１２）。

さらに、プール生成部１０７は、仮想サーバ（Ａ）に対する対応付けをリソース確保用プール（Ｃ）からリソース確保用プール（Ｅ）に変更し（ステップ１４１３）、変更内容を対応テーブルに登録する。

次いで、リソース確保部１０４は、リソース確保用プール（Ｅ）の予約値に相当するリソース量を仮想サーバ（Ａ）に引き継ぐ処理を実行する（ステップ１４１４）。

図１６は、仮想サーバ１１３の削除処理を実施するフローチャートである。プール生成部１０７が仮想サーバ（Ａ）を削除する要求を管理端末１０２から受信すると（ステップ１４１５）、仮想サーバ（Ａ）に対応するリソース確保用プール（Ｆ）を特定する（ステップ１４１６）。

次いで、プール生成部１０７は、仮想サーバ（Ａ）を削除し、さらに、仮想サーバに対応するリソース確保用プール（Ｆ）を削除する（ステップ１４１７）。プール生成部１０７は、対応テーブル５００から仮想サーバ（Ａ）とリソース確保用プール（Ｆ）の対応を削除する。

なお、プール生成部１０７は、図３のテーブルの確保用フラグ２０６を参照して、後述のように仮想サーバが業務システムの仮想サーバへのリソース割当用のものである（フラグ；ｔｒｕｅ）場合には、この仮想サーバを削除しない。

図１７は、物理サーバを省電力モードにする際に、物理サーバから仮想サーバを退避させる際のフローチャートである。管理サーバ１００が、管理端末１０２から、計算機システムに対する省電力モードへの移行要求があったことを検出すると（ステップ２４００）、リソース管理部１０３は、複数の管理対象物理サーバのうち全ての仮想サーバを他の物理サーバに退避するのに適した物理サーバ（Ａ）を特定する（ステップ２４０１）。このような物理サーバの一例としては、最も稼働率が少ない物理サーバがある。

次いで、リソース管理部１０３は、物理サーバ（Ａ）の仮想サーバ（Ｂ）に対応するリソース確保用プール（Ｃ）を、対応テーブル５００（図６）を参照して特定する（ステップ２４０２）。

次いで、リソース管理部１０３は、物理サーバ（Ａ）の全リソース量分の予約値をリソース確保用プール（Ｃ）に設定し（ステップ２４０３）、リソース確保用プール（Ｃ）にこの予約値を、設定可能かどうかを判定する（ステップ２４０４）。

ステップ２４０４において、リソース確保部１０３は、予約値と閾値とを比較し、予約値が閾値以下の場合には一度に全予約値分の保証値をリソース確保用プールに設定できると判定し、一方、予約値が閾値を超えると判定すると、予約値分の保証値を一度にリソース確保用プール（Ｃ）に設定できないと判定して、リソース確保用プール（Ｃ）の保証値を物理サーバ（Ａ）の全リソース量分に至るまで徐々に上げる（ステップ２４０５）。なお、リソース確保部１０３は、物理サーバ（Ａ）から退避されるべき仮想サーバ（Ｂ）に対する保証値を削除する。

リソース管理部１０３が、一度に予約値をリソース確保用プール（Ｃ）に設定した場合や、ステップ２４０６を実行して、最終的に予約値がリソース確保用プール（Ｃ）に設定されることによって、仮想サーバ（Ｂ）からリソース量が、リソース確保用プール（Ｃ）に回収されて、その結果、物理サーバ（Ａ）上で稼働する仮想サーバが無くなったことを検出すると（ステップ２４０６）、管理サーバ１００は、物理サーバ（Ａ）を省電力モード（シャットダウンなど）に移行させる（ステップ２４０７）。なお、リソース管理部１０３は、仮想サーバリソーステーブル２００を参照し、物理サーバ（Ａ）には、実割当リソース量２０３を有する仮想サーバが存在しないこと確認することによって、ステップ２４０６を達成することができる。

図１７のフローチャートを実行することによって、管理サーバ１００は、仮想サーバ（Ｂ）を他の物理サーバに集約し、かつ、物理サーバ（Ａ）をリソースが使用されない未使用状態に積極的に移行させることができるために、物理サーバ（Ａ）を省電力状態に変更することができる。

なお、仮想サーバ（Ｂ）からリソース確保用プール（Ｃ）にリソースの回収を行うことなく、仮想サーバ（Ｂ）を物理サーバ（Ａ）から他の物理サーバに集約しようとすると、計算機システムに適用される負荷平準化プログラムなどにより、仮想サーバ（Ｂ）が移動元物理サーバ（Ａ）と移動先の他の物理サーバとを行き来する「ピンポン現象」が生じてしまう。

仮想サーバ（Ｂ）の移動元物理サーバ（Ａ）において、そのリソースがリソース確保用プール（Ｃ）に回収されることによって、負荷平準化プログラムが稼働している環境下でも既述の「ピンポン現象」を防止することができる。

次に、管理対象物理サーバ１０１における、リソース確保用プール１１４と仮想サーバ１１３の構成に関する他の実施形態について説明する。既述の実施形態（図１）では、仮想サーバ１００が、仮想サーバ１１３にリソース確保用プール１１４からリソースを割り当てると、仮想サーバ１１３をプール１１４外に解放するが、図１８の実施形態のものは、プール１１４内に仮想サーバ１１３を配置することを維持した形態を採用している。

この形態では、リソース確保用プール１１４への仮想サーバ１１３の割当てが維持されているために、仮想サーバ１１３の電源が遮断されている間も、仮想サーバ１１３はリソース確保用プール１１４のリソースを占有することができる。

図１９は、仮想サーバ１１３とリソース確保用プール１１４との対応関係について、さらに他の実施形態に係る計算機システムのブロック図である。図１の実施形態の計算機システムは、物理サーバ１０１において、物理サーバ１０１にデプロイされた複数の仮想サーバ１１３が同じリソース確保用プール１１４を共有するものであったが、図１９の実施形態に係るものは、一つの仮想サーバ１１３が一つのプール１１４を占有しているために、仮想サーバ１１３がプール１１４の外に設定されていても、他の仮想サーバとの間でリソースの競合が発生しない。

図２０は本発明に係る計算機システムの更に他の実施形態に係るブロック図であって、複数の管理対象サーバ１０１のリソース確保用プールをクラスタ化し、クラスタ化されたリソース確保用プール１１４から仮想サーバにリソースを割り当てる実施形態である。リソース確保用プール１１４は、複数の管理対象サーバ１０１を横断して設定されている。

図２０の実施形態によれば、複数の管理対象サーバ１０１間で仮想サーバ１１３が動的に移動するような環境であっても、複数の管理対象サーバ１０１を一つの単位としてリソースを確保できる。デプロイ先の物理サーバを特定せず、ある複数の管理対象サーバ１０１からなるグループに属するいずれかの管理対象サーバ１０１上にリソースを確保したい場合に有効である。

図２１は、本発明に係る計算機システムの更に他の実施形態に係る計算機システムのブロック図であって、管理対象物理計算機１０１が、リソース確保用プール１１４に代えて、仮想サーバ１１３自身がリソースを自発的に確保する機能を備えるものである。

仮想サーバ１１３は負荷を自発的に生成させる負荷生成部１１７を備えている。負荷生成部１１７は、管理サーバ１００からの要求を受けて、擬似的に負荷を生成し、擬似的な負荷に基づいてリソースを確保する。負荷生成部１１７の実体は、例えば、ループ状のプログラムであり、仮想サーバ１１３のＣＰＵが継続的、あるいは一時的に、このプログラムを実行してＣＰＵの使用率を増加させる。リソース制御部１２０は、仮想サーバのＣＰＵ使用率から負荷状態の増加を判定し、リソースを仮想サーバに割当てる。

リソースプールという概念がない仮想化環境であっても、本実施形態により、リソース確保を実現できる。

図２２は、本発明に係る計算機システムの更に他の実施形態に係る計算機システムのブロック図であって、物理サーバ１０１は、負荷を擬似的に発生する負荷生成部１１７を有し、擬似的に発生させた負荷によって確保したリソースを自身では利用せず、他の仮想サーバにアサインするだけの仮想サーバ１１８と、リソースの割当てを受けて業務システムを実現する仮想サーバ１１３とを区別した形態を備えるものである。業務用仮想サーバ１１３と、リソース確保用仮想サーバ１１８とは対応付けられて対応テーブル５００に登録される。

リソース確保部１０４は、リソース確保用仮想サーバ１１８から業務システム用仮想サーバ１１３にリソースを引き継がせる際、両者の仮想サーバ間でリソースの増減を同期させ、すなわち、前者の仮想サーバが負荷生成量を徐々に減少させながら一旦確保したリソースを徐々に放出するようにし、その放出分のリソース量を、後者の仮想サーバが保証値を徐々に増加させることによって確保できるようにすればよい。

なお、リソース確保用サーバ１１８はプールの一例として見ることもできる。リソースプールという概念がない仮想化環境であっても、本実施形態により、リソース確保を実現できる。また、リソース確保専用の仮想サーバはデフォルトで、物理サーバにデプロイされていてもよい。

図２３は、本発明に係る計算機システムの更に他の実施形態に係るブロック図であって、管理サーバ１００からのネットワーク１１５が直接、リソース確保用仮想サーバ１１８の負荷生成部１１７に接続する構成に係るものである。

ここで、リソース確保用仮想サーバ１１８は、他の管理対象サーバ１０１に動的に移動しないよう、固定化させておく必要がある。一方、仮想サーバ１１３は、管理対象サーバ１０１との関係を固定化させておく必要はない。

リソース制御部１２０と管理サーバとが直接ネットワーク１１５を介して接続されていなくてもよい。図２３の実施形態によれば、管理対象サーバ１０１ごとに一つの負荷生成部１１７を備えればよい。負荷生成部１１７を備えない仮想サーバ１１３を管理対象サーバ１０１上に稼働させることができるため、業務システムが稼働する仮想サーバ１１３上では負荷生成部１１７を動作させないことにより負荷生成部１１７と業務システムとの競合を防止できる。

また、仮想サーバ１１３上に業務システムに不要なプログラムを配備しないことで、仮想サーバ１１３の退避・リストアを容易にすることができる。さらに、管理サーバ１００上から負荷生成部１１７に処理を要求するために必要となるリソース確保用仮想サーバ１１８への認証情報が必要となるところ、管理対象サーバ１０１の台数分の認証情報があれば足りる点で管理情報が少なくて済む。また、リソースプールという概念がない仮想化環境であっても、本実施形態により、リソース確保を実現できる。

図２４は、本発明に係る計算機システムの更に他の実施形態に係るブロック図であって、管理サーバ１００がネットワーク１１５を介して直接、仮想サーバ１１３の負荷生成部１１７に接続する構成に係るものである。

図２４の実施形態では、仮想サーバ１１３と管理対象サーバ１０１との関係を固定化させておく必要はない。仮想サーバ１１３を動的に管理対象サーバ１０１間で移動させてもよい。この場合、複数の管理対象サーバ１０１のいずれかで要求したリソースを確保することになる。例えば、仮想サーバ１１３に設定されたIPアドレスベースで管理サーバ１００が仮想サーバ１１３を管理していれば、ある仮想サーバ１１３が第１の管理対象サーバから第２の管理対象サーバに移動したとしても、継続して負荷生成部に負荷を与え続けることができ、リソース確保処理を継続できる。すなわち、管理対象サーバ１０１の負荷平準化プログラムを利用して、仮想サーバ１１３を動的に再配置させながら、リソース確保することができる。

図２４の実施形態によれば、管理サーバ１００は、管理対象サーバ１０１と仮想サーバ１１３の関係を管理しなくてもよいため、管理情報を少なくすることができる。また、リソースプールという概念がない仮想化環境であっても、本実施形態により、リソース確保を実現できる。

１００ 管理サーバ
１０１ 管理対象物理サーバ
１１３ 仮想サーバ
１１４ リソース確保用プール
１２０ リソース制御部

Claims (11)

1. 複数の物理計算機と、
   前記複数の物理計算機を管理する管理計算機と、を備える計算機システムであって、
   前記複数の物理計算機は、それぞれ、
   仮想計算機を生成するプログラムを記憶するメモリと、
   前記プログラムを実行して前記仮想計算機を生成し、
   生成した仮想計算機にリソースを割り当てて、当該仮想計算機を稼働させる第１のコントローラと、を有し、
   前記管理計算機は、
   前記仮想計算機に対する前記リソースの割当てを管理する第２のコントローラを備え、
   前記第２のコントローラは、
   前記仮想計算機の必要リソース量を一度に確保できる物理計算機があれば、当該物理計算機を前記仮想計算機に配置し、
   前記仮想計算機の必要リソース量を一度に確保できる物理計算機がなければ、前記必要リソース量より少ないリソース量を徐々に増加させてリソース確保しながら、前記仮想計算機の稼働開始までに、前記必要リソース量を確保できる物理計算機を決定し、
   当該物理計算機に前記仮想計算機を配置し、
   当該仮想計算機が配置された物理計算機の前記第１のコントローラは、前記必要リソース量を前記配置された仮想計算機に割当てることにより当該仮想計算機を稼働させる、計算機システム。
2. 前記複数の物理計算機のそれぞれは、前記仮想計算機に割当てるリソースを確保するプールを備え、
   前記第１のコントローラは、当該プールから前記仮想計算機へ前記必要リソース量を割当てる、請求項１記載の計算機システム。
3. 前記第２のコントローラは、
   前記プールに前記必要リソース量に相当するパラメータを設定し、
   前記パラメータに基づいて前記必要リソース量を前記プールに確保できるか否かを判定し、
   当該判定結果に基づいて、前記必要リソース量を確保できるプールを有する物理計算機に、前記仮想計算機を配置する、
   請求項２記載の計算機システム。
4. 前記第２のコントローラは、
   前記パラメータと閾値とを比較し、
   前記パラメータが前記閾値より小さいと判定した場合、前記必要リソース量を前記複数の物理計算機の少なくとも一つの前記プールに一度に確保し、
   前記パラメータが前記閾値より大きいと判定した場合、前記必要リソース量を前記複数の物理計算機の少なくとも一つの前記プールに継続的に確保し、
   前記必要リソース量が確保できたプールを有する物理計算機に前記仮想計算機を配置先する、
   請求項３記載の計算機システム。
5. 前記第２のコントローラは、
   前記必要リソース量を一度に確保できる物理計算機がなければ、前記パラメータを徐々に増加させながら前記プールに前記リソースを徐々に確保する、請求項４記載の計算機システム。
6. 前記第２のコントローラは、
   前記プールから複数の仮想計算機に前記リソースを割当てる際、各仮想計算機が実行する業務システムの優先度に応じて、前記プールから前記リソースを前記複数の仮想計算機に配分する、
   請求項２記載の計算機システム。
7. 前記第２のコントローラは、
   前記プールから複数の仮想計算機に前記リソースを割当てる際、各仮想計算機が実行する業務システムのシステム構成に応じて、前記プールから前記リソースを前記複数の仮想計算機に配分する、
   請求項２記載の計算機システム。
8. 前記第２のコントローラは、
   前記プールのリソース量の増加傾向を予測し、
   前記予測結果に基づいて、仮想計算機の稼働が開始するまでに、前記プールに前記必要リソース量を確保できるか否かを判定し、
   判定結果を管理者に対して出力する、
   請求項５記載の計算機システム。
9. 仮想計算機を稼働する物理計算機と、仮想計算機に対する物理計算機のリソースの割当てを管理する管理計算機と、を備える計算機システムの制御方法であって、
   前記管理計算機が、
   前記仮想計算機に保証するリソース量を一度に確保できると判定する物理計算機があれば、当該物理計算機に前記仮想計算機を配置し、
   前記保証するリソース量を一度に確保できないと判定する場合には、前記仮想計算機の起動開始までに、前記仮想計算機に保証するリソース量を徐々に増加させて継続的にリソース確保できるか否かを判定し、
   この判定を肯定すると、前記確保したリソースの合計量を、前記仮想計算機に割当てて、当該仮想計算機を前記物理計算機に配置する、
   計算機システムの制御方法。
10. 仮想計算機を生成し、生成した仮想計算機にリソースを割り当てて、当該仮想計算機を稼働させる、複数の物理計算機の管理計算機であって、
    前記仮想計算機に対する前記リソースの割当てを管理するコントローラを備え、
    前記コントローラは、
    前記仮想計算機の必要リソース量を一度に確保できる物理計算機があれば、当該物理計算機に前記仮想計算機を配置し、
    前記必要リソース量を一度に確保できる物理計算機がなければ、前記必要リソース量もより少ないリソースを徐々に増加させてリソース確保しながら、前記仮想計算機の稼働開始までに、前記必要リソース量の確保を達成できる物理計算機を決定し、
    当該物理計算機に前記仮想計算機を配置し、
    当該仮想計算機が配置された物理計算機に、前記必要リソース量を前記配置された仮想計算機に割当てて当該仮想計算機を稼働させるようにした、
    管理計算機。
11. 仮想計算機と、
    リソースを確保するプールと、を備え、
    前記プールから前記確保されたリソースを前記仮想計算機に割当て、
    前記仮想計算機に前記割当てられたリソースに基づいて業務システムを実行させるコントローラを有する物理サーバであって、
    前記コントローラは、
    前記必要リソース量が閾値より小さい場合、前記必要リソース量を前記プールに一度に確保し、
    前記必要リソース量が閾値より大きい場合、前記必要リソース量を徐々に増加させて前記仮想計算機の稼働開始までに、当該仮想計算機の必要リソース量を前記プールに継続的に確保し、
    当該プールから確保された必要リソース量を前記仮想計算機に割当てる、
    物理サーバ。

Images