JP5476485B2 - サービスの予約管理方法、仮想計算機システム及び記憶媒体 - Google Patents

Description

本発明は、仮想計算機システムにおいて、物理計算機のリソースの予約に関し、特に複数のサービスを仮想マシンで実行する際に、物理計算機上で稼動させるサービスの組み合わせを制御する技術に関する。

仮想化環境を利用した業務システムでは、複数のサービスを連続的に、また複数の仮想マシン上で並列的に稼働させることで、ユーザからの要求に対する処理を実行する。サービスとは、例えば各々仮想マシン上で処理される１つのアプリケーションが提供する業務であったり、データベースシステムやＷｅｂサーバが提供するサービス等である。業務システムでは、このような複数の種類のサービスを組み合わせて仮想計算機システムで実行することでユーザからの要求を処理する。

このような業務システムは１台もしくは複数の物理サーバ上で稼働し、また個々のサービスはある物理サーバ上で稼働する１つの仮想マシン上で実行される。業務システムを提供する仮想マシン環境では、ハイパーバイザ（仮想化部）が複数の仮想マシンを管理し制御している。具体的には、ハイパーバイザが仮想マシンの実行や停止、仮想マシンへのプロセッサや、メモリ等のリソース割り当てを行う。またハイパーバイザは、稼動中の仮想マシンが使用するプロセッサやメモリなどのリソースを割り当てる量を動的に変更することもできる。計算機リソースの動的な配分を行うハイパーバイザは、例えば、Dynamic Logical Partitioning等として知られている。

このような業務システムを構成する複数のサービスを複数の仮想マシンでそれぞれ稼働させる場合、予め使用するリソースの予約を行い計算機のリソースを確保する。例えば特許文献１においては、仮想マシンで使用するリソースを確保するために事前予約を行う技術が開示されている。

また１台の物理計算機上に複数の仮想マシンを稼働させる場合は、実際に複数の仮想マシンを稼働させるとユーザからの要求数が予想以上に増大し、仮想マシンの負荷に応じて上記動的な割当変更を実施すると、リソース不足が発生することがある。リソース不足が発生すると、ハイパーバイザはホットマイグレーション機能を用いて稼動中の仮想マシンの１つを別の物理サーバへ移動させることができる。仮想マシンを他の物理計算機へ移動させることで、使用されていたリソースが解放され、ハイパーバイザは空きリソースとして確保できる。そしてリソース不足となった別の仮想マシンへ当該空きリソースを再割り当てすることによりリソース不足を解消することができる。

リソース不足を解消するためのリソースの再割り当てにおいては、例えば特許文献２において、性能不足が生じないようにリソースを割り当てる技術が開示されている。具体的には、過去の実行履歴からリソースの使用状態についての相関関係を算出しリソース量を決定している。そしてリソース不足が起きたときに、算出したリソース量に基づいて動的に割り当てを変更する技術が開示されている。

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

しかしながら、予約されたリソース量に基づいて仮想マシンを稼働させても、仮想マシン上で実行するサービスに対する処理要求数の変動は、その様態や利用形態によって様々である。特に複数の業務システムを同じ物理サーバ上の仮想マシンで実行する場合、相互の業務システムで同時に稼働するサービスを考慮する必要がある。

例えば、ある業務システムＡで稼働するサービスＡと、業務システムＢで稼働するサービスＢとを仮想マシンａと仮想マシンｂに割り当てて、同時に一つの物理サーバ上で実行する場合を想定する。サービスＡとサービスＢとを同時に実行中、サービスＢに対する処理要求数が想定以上に増大し、サービスＢの仮想マシンでリソース不足となる場合がある。この場合の対処方法としては、サービスＡの仮想マシンａをホットマイグレーションによって別の物理サーバへ退避させ、サービスＡで使用していたリソースをサービスＢを実行する仮想マシンｂに再割り当てすることでリソース不足を解消することができる。

しかし、予約システムにおいてはこのような突発的な変動を事前に推測して考慮することができない。例えば、特許文献１におけるリソースの事前予約を行ったとしても、当該サービスに対するリソース不足をサービスを開始した後では解消することが困難である。

さらに、上記ホットマイグレーションでは、移動元の物理計算機から移動先の物理計算機間でネットワークの負荷が高くなる。このため、リソース不足で負荷の高い状態の物理計算機でホットマイグレーションを行うことは避けることが望ましい。

また、特許文献２においては、物理計算機の性能不足を実行履歴から把握するが、これは仮想マシンで実行するサービスが、固定的に特定の物理計算機上で稼動していることが前提である。サービスを固定的に特定の物理計算機上で実行することで過去の実行履歴からの性能不足を特定でき、かつ適切なリソース量を決定することができる。ところが予約システムにより複数の業務システムの予約を行うと、予約システムは、サービスを実行するのに必要なリソース量の最適な組み合わせから、自由にかつ柔軟にサービスを配置することができる。即ち予約システムに基づいてサービスを配置すると、同じ時間に稼働するサービスの組み合わせはいつも同じとは限らなくなる。すると、過去の実行履歴から性能を把握して適切なリソース量を決定できたとしても、測定された実行履歴と同じサービスの組み合わせを実行する環境でなければ活用することができない、という問題があった。特に、予約システムに基づいてサービスの組み合わせが変動する仮想マシン環境の場合、サービスを実行する物理計算機は、計算機システムのリソースの状況に応じて変動するため、過去の実行履歴を活用することが困難となる、という問題があった。

そこで本発明は上記問題点に鑑みてなされたもので、複数のサービスを複数の仮想マシンで実行させる際に、サービスの組み合わせによって物理計算機のリソースが不足するのを防止することを目的とする。

本発明は、プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する１つ以上の仮想マシンと前記仮想マシンに割り当てるサービスと前記仮想化部を管理計算機で管理するサービスの予約管理方法であって、前記管理計算機が、前記物理計算機に異常が発生したことを検知し、前記物理計算機に異常が発生したときのサービスの組み合わせと、前記異常が発生した曜日と日時と、をサービス組み合わせ情報に格納する第１の手順と、前記管理計算機が、開始日時と終了日時の予約要求期間を含むサービスの予約を受け付ける第２の手順と、前記管理計算機が、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納した予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第３の手順と、前記管理計算機が、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、前記サービス組み合わせ情報を参照して、前記サービスの組み合わせと前記物理計算機に異常が発生した曜日と日時の履歴から、前記予約要求期間を評価する第４の手順と、前記管理計算機が、前記評価の結果に基づいて、前記予約要求期間で物理計算機に異常が発生する可能性を予測する第５の手順と、を含む。

本発明によれば、過去にリソース不足等の異常発生となったサービスの組み合わせをサービス組み合わせ情報に格納しているので、新たにサービスを予約する場合、管理計算機は、リソース不足となる組み合わせについて警告を出力することができる。これにより、リソース不足など、物理計算機で異常発生の可能性とならないサービスの組み合わせを設定することができ、適切にサービスを物理計算機に配置する予約を実現することができる。

本発明の実施形態を示し、仮想計算機システムの一例を示すブロック図である。 本発明の実施形態を示し、管理サーバの機能部位の一例を示すブロック図である。 本発明の実施形態を示し、物理サーバの構成の一例を示すブロック図である。 本発明の実施形態を示し、物理サーバ構成テーブルの一例を示す図である。 本発明の実施形態を示し、仮想マシン構成テーブルの一例を示す図である。 本発明の実施形態を示し、サービス一覧テーブルの一例を示す図である。 本発明の実施形態を示し、テンプレート一覧テーブルの一例を示す図である。 本発明の実施形態を示し、予約テーブルの一例を示す図である。 本発明の実施形態を示し、サービス組み合わせテーブルの一例を示す図である。 本発明の実施形態を示し、管理サーバが取得した区間リストの一例を示す図である。 本発明の実施形態を示し、物理サーバ＃１の割当判定テーブルの一例を示す図である。 本発明の実施形態を示し、物理サーバ＃２の割当判定テーブルの一例を示す図である。 本発明の実施形態を示し、物理サーバ＃３の割当判定テーブルの一例を示す図である。 本発明の実施形態を示し、物理サーバ２−１（物理サーバ＃１）の評価結果テーブルの一例を示す図である。 本発明の実施形態を示し、物理サーバ２−３（物理サーバ＃３）の評価結果テーブルの一例を示す図である。 本発明の実施形態を示し、予約管理部が管理する割当先評価値テーブルの一例を示す図である。 本発明の実施形態を示し、本発明の処理の概要を示す図である。 本発明の実施形態を示し、管理サーバで行われるリソースした仮想マシンの情報を取得する処理の一例を示すフローチャートである。 本発明の実施形態を示し、管理サーバで行われるテンプレート作成処理の一例を示すフローチャートである。 本発明の実施形態を示し、管理サーバが受け付ける予約要求情報の一例を示す図である。 本発明の実施形態を示し、管理サーバが提供するテンプレート選択画面の一例を示す画面イメージである。 本発明の実施形態を示し、管理サーバで行われる予約処理の一例を示すフローチャートである。 本発明の実施形態を示し、管理サーバで行われる割り当て先検索処理の一例を示すフローチャートである。 本発明の実施形態を示し、割当先候補の一例を示す図である。 本発明の実施形態を示し、予約テーブルのうち予約要求情報の予約要求区間と予約済みの区間が重複する物理サーバ＃１の予約情報の一例を示す図である。 本発明の実施形態を示し、管理サーバで行われる区間リストの取得処理の一例を示すフローチャートである。 本発明の実施形態を示し、物理サーバ毎の予約要求区間と区間リストの一例を示す図である。 本発明の実施形態を示し、図２２のステップＳ１２５で行われる割当先候補の評価処理の一例を示すフローチャートである。 本発明の実施形態を示し、予約管理部が使用する評価値テーブルの一例を示す図である。 本発明の実施形態を示し、予約管理部が評価値テーブルを使用した一例を示す図である。

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

図１は本発明の実施形態の仮想計算機システムの構成の一例を示すブロック図である。仮想計算機システムは、複数の仮想マシン４０−１〜４０−５を提供する物理サーバ２−１〜２−３と、これら管理対象の物理サーバ２−１〜２−３を管理する管理サーバ１と、管理サーバ１に指令を行う管理クライアント６と、物理サーバ２−１〜２−３と管理サーバ１と管理クライアント６を接続する通信ネットワーク５０と、を主体にして構成される。物理サーバ２−１〜２−３は、同一の構成を備える。なお、以下の説明では、物理サーバ２−１〜２−３の総称を物理サーバ２とし、仮想マシン４０−１〜４０−５の総称を仮想マシン４０とする。

物理サーバ２は、プロセッサ２０とメモリ２２とストレージ装置２１を備えた物理計算機である。物理サーバ２では、それぞれハイパーバイザ３０が実行され、ハイパーバイザ３０が複数の仮想マシン４０を提供する。ハイパーバイザ３０は、物理サーバ２の物理資源を分割して論理区画に割り当てて、各論理区画でそれぞれ仮想マシン４０を実行させる。なお、ハイパーバイザ３０は、論理区画に割り当てる物理サーバ２の資源を動的に変更するDynamic Logical Partitioning（以下、動的割当変更）の機能を含む。ハイパーバイザ３０は、仮想マシン４０上で実行中のサービス等が必要とするリソースが増大した場合、当該サービスを実行する仮想マシン４０に割り当てるリソースを追加または変更することができる。例えば、ハイパーバイザ３０の動的割当変更部３００（図３参照）は、仮想マシン４０の負荷が増大した場合、未割当のリソース（ＣＰＵやメモリ）を負荷が増大した仮想マシン４０に自動的に割り当てる。

図１の例では、物理サーバ２−１のハイパーバイザ３０が仮想マシン４０−１、４０−２（ＶＭ１、ＶＭ２）を提供し、物理サーバ２−２のハイパーバイザ３０が仮想マシン４０−３（ＶＭ３）を提供し、物理サーバ２−３のハイパーバイザ３０が仮想マシン４０−４、４０−５（ＶＭ４、ＶＭ５）を提供する例を示す。各仮想マシン４０は、通信ネットワーク５０を介して図示しないユーザ端末にサービスを提供する。また、各物理サーバ２のハイパーバイザ３０は、物理サーバ２のリソースが不足したり不具合が発生すると管理サーバ１に所定の警報を通知する。

管理サーバ１は、プロセッサ１０とメモリ１２とストレージ装置１１を備えた物理計算機である。管理サーバ１はストレージ装置１１から管理プログラムをメモリ１２へ読み込んでプロセッサ２０で実行し、複数の物理サーバ２を後述するように管理する。なお、ストレージ装置１１は管理プログラムを格納する非一時的な記憶媒体としても機能する。

管理クライアント６は、プロセッサ６０とメモリ６２とストレージ装置６１と入力装置６３と出力装置６４を備えた物理計算機である。管理クライアント６は、仮想計算機システムの管理者などが使用する。管理者等は入力装置６３を介して管理サーバ１に指令や設定を入力する。そして、管理クライアント６は、管理サーバ１から受信した情報を出力装置６４に表示する。管理者は、管理クライアント６から物理サーバ２の構成情報の取得や仮想マシン４０で実行するサービスや仮想マシン４０の予約などを管理サーバ１に対して要求する。

＜管理サーバの構成＞

図２は、管理サーバ１で実行する管理プログラムの機能要素を示すブロック図である。物理サーバ２を管理するプログラムは、リソース管理部１００と、テンプレート管理部１１０と、予約管理部１２０と、リソース監視部１３０と各種テーブル２００〜２８０を主体に構成される。

リソース管理部１００は、管理クライアント６や予約管理部１２０からの要求に基づいて、物理サーバ２−１〜２−３で実行する仮想マシン４０−１〜４０−５及びサービスを制御する。リソース管理部１００は、各物理サーバ２のハイパーバイザ３０から構成情報を取得して、物理サーバ構成テーブル２００と仮想マシン構成テーブル２１０をメモリ１２に格納する。また、リソース管理部１００は、仮想マシン４０で実行するサービスの種類を管理するサービス一覧テーブル２２０をメモリ１２に格納する。

リソース監視部１３０は、物理サーバ２のハイパーバイザ３０からリソース不足等を示す警報を受信すると、物理サーバ２の仮想マシン４０で実行しているサービスの組み合わせとリソースの情報をサービスの組み合わせテーブル２７０に格納する。サービス組み合わせテーブル２７０には、物理サーバ２でリソース不足などの異常が発生したときのサービスの組み合わせとリソースの状態の履歴が蓄積される。つまり、サービス組み合わせテーブル２７０には、物理サーバ２で同時に実行すると、リソース不足などの異常が発生する可能性のあるサービスの組み合わせが保持される。

予約管理部１２０は、管理クライアント６からのサービスの予約要求情報３１０を受け付けて予約テーブル（予約情報）２４０に格納し、予約テーブル２４０に含まれる開始時刻に達するとリソース管理部１００に対して当該サービスを仮想マシン４０で実行するように要求する。また、予約管理部１２０は、予約テーブル２４０に含まれる終了時刻に達するとリソース管理部１００に対して当該サービス及び仮想マシン４０を終了するように要求する。

予約管理部１２０は、サービスを実行させる仮想マシン４０を物理サーバ２上に予約するため、サービスの稼動期間（または予約期間）を判定する区間リスト２５０と、物理サーバ２上で実行されるサービスの組み合わせを評価するための評価結果テーブル２６０と、予約するサービスが実行可能か否かを判定する割当判定テーブル２８０と割当先評価値テーブル２９０とをメモリ１２に格納する。

そして、予約管理部１２０は、予約の要求（予約要求情報３１０）を管理クライアント６から受け付けると、物理サーバ２の仮想マシン４０に予約するサービスの組み合わせが、サービス組み合わせテーブル２７０に記録されたリソース不足が発生したサービスの組み合わせとならないように、予約されたサービスを実行する物理サーバ２−１〜２−３を選択する。

テンプレート管理部１１０は、仮想マシン４０で実行するサービスと、仮想マシン４０に要求されるリソース量（割当量の要求値）とを対応付けたテンプレートを生成し、テンプレートテーブル２３０に格納しておく。

予約管理部１２０は、管理クライアント６からサービスの予約を受け付けるときに、テンプレートテーブル２３０を提示して、管理者にテンプレートを選択させることで、サービスの予約を簡易にすることができる。つまり、管理クライアント６を操作する管理者は、テンプレートから所望のサービスを選択するだけで、当該サービスに必要な仮想マシン４０のリソース量を自動的に設定することが可能となる。これにより、管理者は、サービスを予約する度に仮想マシン４０で必要となるリソース量を設定する手間を省略することができ、サービスの予約を効率よく行うことが可能となる。

上記管理プログラムの処理の詳細と各テーブルの詳細については後述する。

＜物理サーバの構成＞

図３は、物理サーバ２で実行するプログラムの機能要素を示すブロック図である。なお、物理サーバ２−１〜２−３は同一の構成であるので、物理サーバ２−１について説明し、他の物理サーバ２−２〜２−３の説明を省略する。

プロセッサ２０は、ストレージ装置２１からハイパーバイザ３０をメモリ２２に読み込んでから実行する。ハイパーバイザ３０は、管理サーバ１からサービスの実行開始の指示を受け付けると、指示されたリソース量を物理サーバ２−１の物理資源から仮想マシン４０を実行する論理区画に割り当てる。そして、ハイパーバイザ３０は仮想マシン４０−１、４０−２を起動させてそれぞれＯＳ４１を実行させ、管理サーバ１から指示されたサービス４２−１、４２−２を各仮想マシン４０のＯＳ４１上で実行させる。なお、ＯＳ４１とサービス４２−１、４２−２はストレージ装置２１または管理サーバ１のストレージ装置１１から読み込む。なお、以下の説明では、サービス４２−１（サービス＃１）、４２−２（サービス＃２）の総称をサービス４２とする。

ここで、各仮想マシン４０で実行されるサービス４２は、プログラムの実行によってクライアントに提供される。そして、サービス４２のプログラムはアプリケーション、デーモン、サービスの何れかの形態で実行される。

ハイパーバイザ３０は、上述のように仮想マシン４０の負荷の変化に応じてリソースの割り当て量を動的に変更する動的割当変更部３００を有する。動的割当変更部３００の構成は、周知または公知のものを用いればよいのでここでは詳述しない。

＜各テーブルの構成＞

以下、管理サーバ１で使用する各テーブルの詳細について説明する。

図４は、リソース管理部１００が管理する物理サーバ構成テーブル２００の一例を示す図である。物理サーバ構成テーブル２００は、物理サーバ２の識別子を格納する物理サーバ２０１と、物理サーバ２のプロセッサ２０の性能を格納するＣＰＵ性能２０２と、物理サーバ２に実装されたメモリ２２の容量（ＧＢ）を格納するメモリ容量２０３からひとつのエントリが構成される。なお、ＣＰＵ性能２０２には、プロセッサ２０の動作周波数（ＧＨｚ）とコア数が格納される。

リソース管理部１００は、所定の周期（例えば、１時間）で各ハイパーバイザ３０から物理サーバ２の構成情報を取得し、物理サーバ構成テーブル２００を更新する。

図５は、リソース管理部１００が管理する仮想マシン構成テーブル２１０の一例を示す図である。仮想マシン構成テーブル２１０は、仮想マシン４０の識別子を格納する仮想マシン２１１と、仮想マシン４０を稼動させる物理サーバ２の識別子を格納する物理サーバ２１２と、仮想マシン４０に割り当てられたプロセッサ２０の割り当て量を格納するＣＰＵ割り当て量２１３と、仮想マシン４０に割り当てられたメモリ２２の割り当て量を格納するメモリ割り当て量２１４と、仮想マシン４０で実行するサービス４２の識別子を格納するサービス２１５からひとつのエントリが構成される。なお、ＣＰＵ割り当て量２１３には、仮想マシン４０に割り当てたプロセッサ２０のコア数に動作周波数（ＧＨｚ）を乗じた値を割り当て量として設定する。

リソース管理部１００は、所定の周期（例えば、１分）で各ハイパーバイザ３０から各仮想マシン４０の構成情報を取得し、仮想マシン構成テーブル２１０を更新する。

図６は、リソース管理部１００が管理するサービス一覧テーブル２２０の一例を示す図である。サービス一覧テーブル２２０は、サービス４２の識別子を格納するサービス２２１から一つのエントリが設定される。サービス一覧テーブル２２０は、管理クライアント６から管理者が設定した情報を格納する。

図７は、テンプレート管理部１１０が管理するテンプレート一覧テーブル２３０の一例を示す図である。テンプレート一覧テーブル２３０は、テンプレートの識別子を格納するテンプレート２３１と、テンプレートに定義されたサービス４２の識別子を格納するサービス２３２と、当該サービス４２を実行する仮想マシン４０に必要なプロセッサ２０の割り当て量を格納するＣＰＵ割当量２３３と、当該サービス４２を実行する仮想マシン４０に必要なメモリ２２の割り当て量を格納するメモリ割当量２３４とから一つのエントリが設定される。テンプレート一覧テーブル２３０は、管理クライアント６から管理者が設定した情報を格納する。

図８は、予約管理部１２０が管理する予約テーブル２４０の一例を示す図である。予約テーブル２４０は、予約情報として、予約したサービスを割り当てる仮想マシン４０の識別子を格納する仮想マシン２４１と、予約したサービスの識別子を格納するサービス２４２と、当該サービスを実行する仮想マシン４０を割り当てる物理サーバ２の識別子を格納する割り当て先２４３と、当該仮想マシン４０に割り当てるプロセッサ２０の割当量を格納するＣＰＵ割当量２４４と、当該仮想マシン４０に割り当てるメモリ２２の割当量を格納するメモリ割当量２４５と、当該サービスを開始する日時を予約する開始日時２４６と、当該サービスを終了する日時を予約する終了日時２４７とから一つのエントリが設定される。予約テーブル２４０は、管理クライアント６から要求された予約情報を、予約管理部１２０で後述のように調整した値を格納する。

図９は、リソース監視部１３０が管理するサービス組み合わせテーブル２７０の一例を示す図である。サービス組み合わせテーブル２７０は、リソース不足等の障害が発生したときの履歴情報として、ハイパーバイザ３０から受信した警報の内容に識別子を加えた情報を格納する事象２７１と、物理サーバ２で実行しているサービス４２の識別子を格納するサービス２７２、２７３、２７４と、事象２７１の発生時点で利用が予約されていないプロセッサ２０の割当量を格納する未予約ＣＰＵ性能２７５と、事象２７１の発生時点で利用が予約されていないメモリ２２の割当量を格納する未予約メモリ容量２７６と、事象２７１が発生した物理サーバ２の識別子を格納する物理サーバ２７７と、事象２７１が発生した日時を格納する日時２７８とから一つのエントリが設定される。

リソース監視部１３０は、ハイパーバイザ３０から警報を受信すると、当該警報を送信したハイパーバイザ３０から物理サーバ２と仮想マシン４０のリソースの情報を取得して、サービス組み合わせテーブル２７０に新たなエントリを追加する。なお、物理サーバ２で実行しているサービス４２の数を３つとしてサービス２７２〜２７４のフィールドにサービスの識別子を格納する例を示したが、一つの物理サーバ２で実行されるサービス４２の数に応じて適宜フィールドの数を設定すればよい。

また、サービス組み合わせテーブル２７０は、事象２７１が発生したときに物理サーバ２の余剰リソース量を格納するフィールドを設けてもよく、例えば、未割当のＣＰＵ性能と未割当のメモリ容量を格納するフィールドを設けた場合には、事象２７１が発生した時点でリソース不足がＣＰＵとメモリのどちらで発生したのかを記録することができる。

なお、未予約のリソース量（ＣＰＵ性能またはメモリ容量）は、物理サーバ２のリソースのうち予約テーブル２４０で指定されていないリソース量を示す。例えば、未予約メモリ容量２７６は、日時２７８の時点で予約テーブル２４０で設定されたメモリ容量２４６の総和を、物理サーバ２７７のメモリ容量２０３から差し引いた値であり、利用が予約されていないメモリ容量である。

一方、未割当のリソース量は、物理サーバ２でハイパーバイザ３０が割り当て可能なリソースのうち、仮想マシン４０に割り当てられていないリソース量を示す。例えば、未割当のメモリ容量は、ハイパーバイザ３０が割り当てることのできるメモリ容量２０３から実際に使用しているメモリ容量を差し引いたメモリ容量である。

図１０は、予約管理部１２０が管理する物理サーバ＃１の区間リスト２５０の一例を示す図である。区間リスト２５０は、区間の識別子を格納する区間２５１と、区間の開始日時を格納する開始日時２５２と、区間の終了日時を格納する終了日時２５３から一つのエントリが設定される。区間リスト２５０は、予約管理部１２０がサービスの予約の要求を受け付けたときに、当該サービスの予約期間と重複する他のサービスの予約期間を比較するために予約管理部１２０が物理サーバ２毎に設定する。メモリ２２には、物理サーバ２−１〜２−３の区間リスト２５０がそれぞれ設定される。

図１１、図１２、図１３は、予約管理部１２０が管理する割当判定テーブル２８０の一例を示す図である。割当判定テーブル２８０は、予約管理部１２０によって物理サーバ２毎に生成される。図１１は、物理サーバ２−１（物理サーバ＃１）の割当判定テーブル２８０−１を示し、図１２は、物理サーバ２−２（物理サーバ＃２）の割当判定テーブル２８０−２を示し、図１３は、物理サーバ２−３（物理サーバ＃３）の割当判定テーブル２８０−３を示し、割当判定テーブル２８０−１〜２８０−３の総称を割当判定テーブル２８０とする。

割当判定テーブル２８０は、区間の識別子を格納する区間２８１と、区間の開始日時を格納する開始日時２８２と、区間の終了日時を格納する終了日時２８３と、仮想マシン４０へのプロセッサ２０の割当量を格納するＣＰＵ割当量２８４と、仮想マシン４０へのメモリ２２の割当量を格納するメモリ割当量２８５と、仮想マシン４０の割り当ての可否を格納する割当可否２８６とからひとつのエントリが構成される。

図１４、図１５は、予約管理部１２０が管理する評価結果テーブル２６０の一例を示す図である。評価結果テーブル２６０は、予約管理部１２０によって物理サーバ２毎に生成される。図１４は、物理サーバ２−１（物理サーバ＃１）の評価結果テーブル２６０−１を示し、図１５は、物理サーバ２−３（物理サーバ＃３）の評価結果テーブル２６０−３を示し、評価結果テーブル２６０−１、２６０−３の総称を評価結果テーブル２６０とする。

評価結果テーブル２６０は、区間の識別子を格納する区間２６１と、予約を要求されたサービスの識別子を格納する予約要求サービス２６２と、予約されたサービスの識別子を格納するサービス２６４、２６６と、予約されたサービス２６４、２６６を実行する仮想マシン４０の識別子を格納する仮想マシン２６３，２６５と、当該区間で予約されていないプロセッサ２０のリソース量を格納する未予約ＣＰＵ性能２６７と、当該区間で予約されていないメモリ２２のリソース量を格納する未予約メモリ容量２６８と、予約管理部１２０で求めた評価値２６９からひとつのエントリが構成される。なお、評価値の演算については後述する。

図１６は、予約管理部１２０が管理する割当先評価値テーブル２９０の一例を示す図である。割当先評価値テーブル２９０は、予約管理部１２０によって生成される。

割当先評価値テーブル２９０は、予約するサービスを割り当てる物理サーバ２の識別子を格納する割当先２９１と、予約管理部１２０が求めた物理サーバ２毎の評価値２９２からからひとつのエントリが構成される。なお、評価値の演算については後述する。

＜概要＞

図１７は、本発明の処理の概要を示す図である。図１７は、物理サーバ２−１（以下、物理サーバ＃１）でリソース不足が発生し、その後、管理クライアント６からサービス＃５の予約要求があったときの処理を示す。

管理サーバ１は、物理サーバ＃１のハイパーバイザ３０からリソース不足などの警報を受信すると（Ｓ１）、物理サーバ＃１からリソースの情報と、実行しているサービスの組み合わせを取得し、警報の発生時点の履歴情報としてサービス組み合わせテーブル２７０に新たなエントリを追加する（Ｓ２）。図示の例では、物理サーバ＃１でサービス＃１、サービス＃２、サービス＃５が実行されていたときにリソース不足が発生した例を示している。管理サーバ１は、ハイパーバイザ３０が警報を通知したときのサービスの組み合わせ（サービス＃１、サービス＃２、サービス＃５）とリソースの予約量をリソース不足の履歴情報としてサービス組み合わせテーブル２７０に蓄積していく。

ここで、動的割当変更部３００を備えたハイパーバイザ３０でリソース不足が発生する例について説明する。図１７において、物理サーバ＃１で仮想マシン＃１がサービス＃１を実行し、仮想マシン＃２がサービス＃２を実行し、仮想マシン＃３がサービス＃５を実行している。各サービス＃１の実行開始当初は、ハイパーバイザ３０が物理サーバ＃１のリソースを、予約テーブル２４０で予約された割当量（ＣＰＵ割当量２４４、メモリ割当量２４５）で割り当てる。ハイパーバイザ３０がメモリ２２を割り当てる例では、仮想マシン＃１に１ＧＢ、仮想マシン＃２に１ＧＢ、仮想マシン＃３に２ＧＢを割り当てたとする。物理サーバ構成テーブル２００より物理サーバ＃１のメモリ容量２０３は「６ＧＢ」であるので、この時点での未割当（かつ未予約）のメモリ容量は、６−（１＋１＋２）＝２ＧＢとなる。

次に、サービス＃５の負荷が増大する。サービス＃５を実行する仮想マシン＃３の負荷も増大するため、ハイパーバイザ３０の動的割当変更部３００は、仮想マシン＃３に未割当のメモリを割り当てる。動的割当変更部３００は、仮想マシン＃３に未割当の２ＧＢのメモリ２２を追加して割り当てたとする。この時点での未割当のメモリ容量は、６−（１＋１＋４）＝０ＧＢとなる。

次に、サービス＃２の負荷が増大する。サービス＃２を実行する仮想マシン＃２の負荷も増大するため、ハイパーバイザ３０の動的割当変更部３００は、仮想マシン＃２に未割当のメモリを割り当てようとする。しかし、現時点で物理サーバ＃１には未割当のメモリはないので、ハイパーバイザ３０はリソース不足となり、警報を出力することになる。この例では、サービス＃２とサービス＃５を同一の物理サーバで実行した結果、リソース不足になった例であり、サービス＃１とサービス＃２の組み合わせ、またはサービス＃１とサービス＃５の組み合わせを同一の物理サーバで実行してもリソース不足は発生しないことを意味する。

そこで、本発明の管理サーバ１は、ハイパーバイザ３０が警報を出力したときのサービスの組み合わせをサービス組み合わせテーブル２７０に蓄積しておく。そして、管理サーバ１は、物理サーバ２にサービス４２を割り当てる予約を生成する際に、同一の物理サーバで実行するサービスの組み合わせが、サービス組み合わせテーブル２７０に一致した場合は、新たに予約するサービスを他の物理サーバへ変更することで、将来、リソース不足が発生するのを防止するものである。

管理サーバ１は、管理クライアント６からサービス＃３の予約要求（予約要求情報３１０）を受け付ける（Ｓ３）。管理サーバ１の予約管理部１２０は、サービス＃３の実行の際に要求されるリソース量や、各物理サーバ２の物理資源の状況を予約テーブル２４０から取得し、物理サーバ＃２の仮想マシン（ＶＭ＃５）にサービス＃５を割り当てることを検討する。

予約管理部１２０は、物理サーバ＃２にサービス＃５を予約した場合のサービスの組み合わせをサービス組み合わせテーブル２７０から検索する。予約管理部１２０は、サービス＃１、サービス＃２、サービス＃５の組み合わせで、物理サーバ＃１がリソース不足となった履歴を検出する（Ｓ４）。予約管理部１２０は、サービス＃５の割り当て先として物理サーバ＃２を除外し、新たな割り当て先として、物理サーバ＃３を選択して新たなサービス＃５を仮想マシン＃７に予約する（Ｓ５）。

つまり、予約の時点では、物理サーバ＃２のリソースは十分であってサービス＃１、サービス＃２、サービス＃５を同時に実行するのに支障がないと、予約管理部１２０は判定できる。しかし、過去のリソース不足の履歴からサービス＃１、サービス＃２、サービス＃５を同時に実行したときに物理サーバ＃１でリソース不足が発生したことを予約管理部１２０はサービス組み合わせテーブル２７０から検知する。リソース不足の発生履歴を検知すると、予約管理部１２０は、サービス＃５を物理サーバ＃２へ割り当てるのを中止して、新たに空きリソースのある他の物理サーバ＃３を選択し、この物理サーバ＃３に新たなサービス＃５を予約する。

本発明によれば、管理サーバ１は、過去にリソース不足となったサービスの組み合わせをサービス組み合わせテーブル２７０に蓄積しているので、新たにサービスを予約する場合、リソース不足とならない組合せを抽出することができ、物理サーバに配置するサービスの予約を適切な組み合わせで実現することができる。また、管理サーバ１は、サービス組み合わせテーブル２７０に、リソース不足となったサービス（仮想マシン４０）の各々のリソース割り当て量も記録しているので、より正確にリソース不足とならない組合せを抽出して、予約することが可能となる。

＜処理の詳細＞

以下、管理サーバ１で行われる処理の詳細について説明する。図１８は、管理サーバ１のリソース監視部１３０で行われる処理の一例を示すフローチャートである。この処理は、物理サーバ２のハイパーバイザ３０から警報を受信したときに実行されるリソース不足情報の取得処理である。

ステップＳ１０１では、リソース監視部１３０は、警報を通知したハイパーバイザ３０に対して稼動中の全ての仮想マシン４０の一覧（例えば、識別子の一覧など）を取得する。そして、ステップＳ１０２では、リソース監視部１３０が、上記一覧を取得した全ての仮想マシン４０のそれぞれについて、ステップＳ１０３の処理を順次実行する。

ステップＳ１０３では、リソース監視部１３０は、仮想マシン４０毎に実行しているサービス４２と、使用しているリソースの量とをハイパーバイザ３０から取得する。リソース不足が発生したハイパーバイザ３０から全ての仮想マシン４０の情報の取得が完了すると、リソース監視部１３０はサービス組み合わせテーブル２７０に新たなエントリを加える（Ｓ１０４）。

例えば、図９で示すように、サービス組み合わせテーブル２７０へ「リソース不足３」を事象２７１に加える場合、リソース監視部１３０は、リソース不足３が発生した時点で実行していたサービスの組み合わせ「サービス＃１、サービス＃４」と、物理サーバ２の識別子「物理サーバ＃３」と日時を、サービス組み合わせテーブル２７０の各サービス２７３、２７４、物理サーバ２７７及び日時２７８に加える。

そして、リソース監視部１３０は、日時２７８に格納したリソース不足が発生した時点のリソースの予約量を予約テーブル２４０から集計し、当該日時でのＣＰＵ割当量２４４とメモリ割当量２４５で予約したリソース量の合計を求める。つまり、リソース監視部１３０は、日時２７８において物理サーバ＃３で実行していた仮想マシン４０に割り当てる予定のリソース量の合計値を、ＣＰＵの予約量とメモリの予約量としてそれぞれ求める（Ｓ１０３）。

そして、リソース監視部１３０は、物理サーバ構成テーブル２００からリソース不足３が発生した物理サーバ＃３の構成情報として、ＣＰＵ性能２０２とメモリ容量２０３を取得する。なお、ＣＰＵ性能２０２は、プロセッサのコア数に動作周波数（定格周波数）を乗じた値を用いる。

次に、リソース監視部１３０は、物理サーバ＃３のＣＰＵ性能２０２から上記ステップＳ１０３で取得した物理サーバ＃３上の仮想マシン４０のプロセッサの予約量の合計値を差し引いた値を、未予約ＣＰＵ性能として求め、未予約ＣＰＵ性能２７５に格納する。

また、リソース監視部１３０は、物理サーバ＃３のメモリ容量２０３から、上記ステップＳ１０３で取得した物理サーバ＃３上の仮想マシン４０のメモリの予約量の合計値を差し引いた値を、未予約メモリ容易として求め、未予約メモリ容量２７６に格納する。

以上の処理により、リソース監視部１３０は、リソース不足等の障害が発生した履歴をサービス組み合わせテーブル２７０に追加して、ハイパーバイザ３０から警報を受けた時点の、サービスの組み合わせと、リソースの予約量を蓄積する。

図１９は、管理サーバ１のテンプレート管理部１１０で行われる処理の一例を示すフローチャートである。この処理は、管理クライアント６からテンプレートの登録要求があったときにテンプレート管理部１１０で実行される。

まず、ステップＳ１１１では、管理サーバ１のテンプレート管理部１１０が管理クライアント６からテンプレートに設定するサービスの識別子を受け付ける。管理クライアント６では、入力装置６３から追加するテンプレートに含めるサービスの識別子を受け付けて、管理サーバ１に送信する。

ステップ１１２では、テンプレート管理部１１０は、図６に示したサービス一覧テーブル２２０を検索して、受け付けた識別子と同一の識別子が存在するか否かを判定する。サービス一覧テーブル２２０に、受け付けた識別子と同一の識別子が存在しなければ、ステップＳ１１３へ進む一方、受け付けた識別子と同一の識別子がサービス一覧テーブル２２０に既に登録されている場合にはステップＳ１１４へ進む。

ステップＳ１１３では、テンプレート管理部１１０は未登録のサービスを受け付けたので、受け付けたサービスの識別子をサービス一覧テーブル２２０に登録する。

ステップＳ１１４では、テンプレート管理部１１０が、サービス一覧テーブル２２０を管理クライアント６へ送信し、サービスの一覧からテンプレートに加えるサービスを管理クライアント６で選択させる。このとき、テンプレート管理部１１０は、選択されたサービスを仮想マシン４０で実行する際のＣＰＵ割当量２２３とメモリ割当量２３４を管理クライアント６から受け付ける。なお、管理クライアント６から、テンプレートのＣＰＵ割当量２２３とメモリ割当量２３４を指定しない場合は、テンプレート管理部１１０は、予め設定されたＣＰＵ割当量２２３とメモリ割当量２３４の初期値（例えば、１ＧＨｚ、１ＧＢ）を、追加するテンプレートに適用するリソース量として設定する。

ステップＳ１１５では、テンプレート管理部１１０が管理クライアント６で選択したサービスと、当該サービスを実行する仮想マシン４０に割り当てるリソース量の組み合わせを、新たにテンプレート一覧テーブル２３０へ加える。このとき、テンプレート管理部１１０は、新たな識別子を追加するテンプレートに設定する。

図７の例では、テンプレート管理部１１０が、サービス＃６のテンプレートを登録する例を示す。新たな「サービス＃６」をテンプレートに登録する場合、テンプレート管理部１１０はサービス一覧テーブル２２０を検索し、既登録の値が存在しないので新たな「サービス＃６」をサービス一覧テーブル２２０に追加する。そして、テンプレート管理部１１０は、管理クライアント６から「サービス＃６」を仮想マシン４０で実行する際のリソース量をＣＰＵ割当量２２３とメモリ割当量２３４として受け付ける。テンプレート管理部１１０は、当該受け付けたサービスの識別子とリソース量の組み合わせにテンプレートの識別子を付与し、テンプレート一覧テーブル２３０に新たなエントリとして追加する。

なお、テンプレート一覧テーブル２３０は、ひとつのサービスについて複数のテンプレートが存在することを許容し、これら複数のテンプレートは、ひとつのサービスに対して複数のリソース量の組み合わせを設定できる。

次に、管理サーバ１が管理クライアント６から受け付けた予約の処理について説明する。予約の要求は、例えば、図２０で示すような予約要求情報を含む。図２０の予約要求情報３１０は、予約するサービスの識別子を格納するサービス３１１と、当該サービスを実行する仮想マシン４０に割り当てるプロセッサ２０の割当量を格納するＣＰＵ割当量３１２と、当該サービスを実行する仮想マシン４０に割り当てるメモリ２２の割当量を格納するメモリ割当量３１３と、当該サービスを開始する日時３１４と、当該サービスを終了する日時３１５から構成される。

すなわち、予約要求情報３１０は、図７に示したテンプレート一覧テーブル２３０の情報に開始日時３１４と終了日時３１５を付加して生成することができる。このため、予約要求情報３１０の受付は、図２１に示すテンプレート選択画面２１３０を用いることができる。

図２１は、予約の受け付け時に管理サーバ１が管理クライアント６へ提供するテンプレート選択画面の一例を示す画面イメージである。管理サーバ１は、管理クライアント６から所定の予約要求を受け付けると、図２１のテンプレート選択画面２３００を管理クライアント６へ出力する。

テンプレート選択画面２３００は、サービスの開始日時を入力する開始日時入力領域２３０１と、サービスの終了日時を入力する終了日時入力領域２３０２と、テンプレート一覧テーブル２３０を表示して管理者などに所望のサービスを選択させる選択領域２３０３と、予約の実行を指令する予約ボタン２３０４とから構成される。

管理クライアント６を利用する管理者は、入力装置６３及び出力装置６４を使用して、開始日時入力領域２３０１にサービスの開始日時を入力し、サービスの終了日時を終了日時入力領域２３０２へ入力し、選択領域２３０３では所望のテンプレートのチェックボックス２３１０を選択する。そして、管理クライアント６を利用する管理者がテンプレート選択画面２３００の予約ボタン２３０４を操作すると、管理サーバ１の予約管理部１２０で処理が開始される。

予約管理部１２０は、予約ボタン２３０４が操作されると、開始日時入力領域２３０１の値を予約要求情報３１０の開始日時３１４へ格納し、終了日時入力領域２３０２の値を予約要求情報３１０の終了日時３１５へ格納し、チェックボックス２３１０で選択されたテンプレート一覧テーブル２３０のサービスの識別子２３２とＣＰＵ割当量２３３とメモリ割当量２３４を、それぞれ予約要求情報３１０のサービス３１１、ＣＰＵ割当量３１２、メモリ割当量３１３へ格納する。なお、これらの処理は管理クライアント６で実行し、予約要求情報３１０を管理サーバ１へ送るようにしてもよい。

図２２は、管理サーバ１の予約管理部１２０で行われる予約処理の一例を示すフローチャートである。この処理は、管理クライアント６から予約要求情報を受け付けたとき、あるいは、上記図２１の予約ボタン２３０４が操作されたときに実行される。

ステップＳ１２１では、予約管理部１２０が、管理クライアント６から予約要求情報を取得する。

ステップＳ１２２では、予約管理部１２０は、取得した予約要求情報３１０から要求されたサービス３１１を実行する仮想マシン４０に割り当てるリソース量を満たす物理サーバ２を割り当て先として検索する。なお、割り当て先の物理サーバ２を検索する処理（割当先検索処理）については、後述する。

ステップＳ１２３では、予約管理部１２０はステップＳ１２２で検索した割り当て先の物理サーバ２の有無を判定する。予約管理部１２０は割り当て先の物理サーバ２が存在する場合にはステップＳ２１４の処理へ進み、割り当て先の物理サーバ２が存在しなければステップＳ１２８へ進む。

ステップＳ１２４では、予約管理部１２０はステップＳ１２２で検索した全ての割当先候補の物理サーバ２についてステップＳ１２５の割当先候補の評価を実施する。ステップＳ１２５では、予約管理部１２０が割当先候補となる物理サーバ２毎に評価値を後述するように演算する。

ステップＳ１２６では、予約管理部１２０はステップＳ１２５で求めた評価値のうち最も小さい評価値の物理サーバ２を、予約を割り当てる物理サーバ２として選択する。ここでは、予約管理部１２０が割当先評価値テーブル２９０の評価値２９２が最も小さい物理サーバ２の識別子２９１を選択する。

ステップＳ１２７では、予約管理部１２０はステップＳ１２６で選択した物理サーバ２で、受け付けた予約要求情報３１０を実行する予約を予約テーブル２４０に追加してから予約処理を終了する。

一方、ステップＳ１２３の判定で、予約の割当先候補となる物理サーバ２がひとつも存在しない場合には、ステップＳ１２８へ進む。ステップＳ１２８では、予約管理部１２０は、管理クライアント６に対して予約が不能であることを警告し、予約要求情報３１０を再入力またはリソース量の再考を示唆するメッセージを出力する。

次に、図２３は、上記図２２のステップＳ１２２で行われる割当先候補の検索処理の一例を示すフローチャートである。

ステップＳ１３０では、予約管理部１２０がステップＳ１３１〜Ｓ１３７の処理を、管理サーバ１の管理対象となる全ての物理サーバ２について、物理サーバ２毎に順次繰り返して実行する。

ステップＳ１３０では、予約管理部１２０が物理サーバ構成テーブル２００から未選択の物理サーバ２を一つ選択する。ステップＳ１３１では、予約管理部１２０は、上記ステップＳ１２１で取得した予約要求情報３１０の開始日時３１４と終了日時３１５と日時が重複する予約を予約テーブル２４０から検索する。この検索は、ステップＳ１３０で選択した物理サーバ２の予約情報について実施する。予約管理部１２０は、選択した物理サーバ２の予約情報について、予約テーブル２４０の開始日時２４６が、予約要求情報３１０の終了日時３１５以前で、かつ、予約テーブル２４０の終了日時２４７が、予約要求情報３１０の開始日時３１４以降の予約情報を重複する予約情報として取得する。

ステップＳ１３２では、物理サーバ構成テーブル２００からステップＳ１３０で選択した物理サーバ２のリソース量としてＣＰＵ性能２０２とメモリ容量２０３を取得する。

ステップＳ１３３では、予約要求情報３１０の開始日時３１４〜終了日時３１５までの予約要求区間を、上記ステップＳ１３１で取得した重複する予約情報から複数の区間に分割し、各区間のリストを図１０で示す区間リスト２５０として後述するように取得する。この区間リスト２５０は、予約要求区間の始点（開始日時３１４）から終点（終了日時３１５）までの間で、始点から終点に向けて、既に予約済みの仮想マシン４０（サービス）が開始または終了する時点毎に区間を設定して区間のリストを生成する処理である。なお、本実施形態では、ひとつの仮想マシン４０上でひとつのサービスを実行する例について説明する。

ステップＳ１３４では、上記ステップＳ１３３で取得した区間リスト２５０の全ての区間についてステップＳ１３５、Ｓ１３６の処理を、区間毎に順次繰り返す。

ステップＳ１３５では、予約管理部１２０は、区間リスト２５０から未選択の区間を一つ選択し、当該区間内で予約テーブル２４０に予約された物理サーバ２のリソースの予約量と予約要求情報３１０のリソース量の合計を演算する。本実施形態の例では、リソース量として、ＣＰＵ性能とメモリ容量を用いるので、選択した区間内でのＣＰＵ性能の予約量の合計と、メモリ容量の予約量の合計をそれぞれ予約管理部１２０が演算する。つまり、予約管理部１２０は、リソースの種類毎にリソースの予約量の合計を選択した区間内でそれぞれ求めればよい。

次に、ステップＳ１３６では、現在選択した物理サーバ２のリソース量が、ステップＳ１３５で求めた予約量の合計より少ないか否かを判定する。つまり、既に予約されたリソースの予約量に、予約要求情報３１０のリソース量を加えた値が、物理サーバ２のリソース量を超えていれば割当先として不適であるので、除外する。本実施形態の例では、予約管理部１２０は、現在の区間内で、物理サーバ２のＣＰＵ性能２０２が予約量の合計未満または物理サーバ２のメモリ容量２０３が予約量の合計未満であれば割当先として不適切と判定する。一方、予約管理部１２０は、現在の区間内で、物理サーバ２のＣＰＵ性能２０２が予約量の合計以上かつ、物理サーバ２のメモリ容量２０３が予約量の合計以上であれば割当先として適切と判定する。

予約管理部１２０が割当先として不適切と判定した場合には、現在選択している物理サーバ２では、予約を要求したサービスを予約要求区間で係属して処理できないので割当先候補から除外し、ステップＳ１３０に戻って次の未処理の物理サーバ２について上記処理を繰り返す。

そして、ステップＳ１３４〜Ｓ１３６の処理を繰り返して全ての予約要求区間で、現在選択している物理サーバ２のリソース量が予約要求情報３１０を満たしていれば、予約管理部１２０はステップＳ１３７で当該物理サーバ２の識別子を割当先候補に設定する。

上記処理を全ての物理サーバ２について繰り返して実行することで、全ての予約要求区間で、リソース量が予約要求情報３１０を満たす物理サーバ２の一覧が割当先候補に設定される。なお、図２４で示すように、割当先候補３２０は、物理サーバ２の識別子を格納するテーブルとしてもよいし、あるいは変数としてもよく、メモリ２２上に格納される。割当先候補３２０は、物理サーバ２のうち予約要求情報３１０のリソース量を満たす物理サーバの一覧を保持する。

図２５は、予約要求区間と予約テーブル２４０で予約済みの区間（予約済み区間）が重複する物理サーバ２の識別子が＃１の予約状況を示す。上記図２３の処理の結果、予約管理部１２０は、物理サーバ２毎に予約テーブル２４０の予約済み区間と予約要求区間が重複する仮想マシン４０を取得することができる。

図２６は、図２３の割当先候補検索処理のステップＳ１３３で行われる区間リスト２５０の取得処理の一例を示すフローチャートである。

予約管理部１２０は、図２２のステップＳ１２１で取得した予約要求情報３１０の開始日時３１４を、区間開始日時に設定する。予約管理部１２０は、ステップＳ１４１〜Ｓ１４７の処理を区間開始日時が予約要求情報３１０の終了日時３１５（予約終了日時）に到達するまでの間繰り返す。

ステップＳ１４２では、予約管理部１２０は予約テーブル２４０を検索し、区間開始日時以降で、現在選択している物理サーバ２の予約情報で最も早い（近い）予約開始日時２４６を取得する。そして、取得した予約開始日時２４６を変数：日時Ａに設定する。

ステップＳ１４３では、予約管理部１２０は予約テーブル２４０を検索し、区間開始日時以降で、現在選択している物理サーバ２の予約情報で最も早い（近い）予約終了日時２４７を取得する。そして、取得した予約終了日時２４７を変数：日時Ｂに設定する。

ステップＳ１４４では、予約管理部１２０は、日時Ａと日時Ｂが共に存在しないことを判定する。日時Ａと日時Ｂが共に存在しない（値がない）場合には、ステップＳ１４８へ進んで予約管理部１２０はステップＳ１４１〜Ｓ１４７のループを終了する。

ステップＳ１４８では、予約管理部１２０は、区間終了日時に予約要求情報３１０の終了日時３１５を設定する。次に、ステップＳ１４９では予約管理部１２０が、ステップＳ１４０で設定した区間開始日時と、ステップＳ１４８の区間終了日時に、区間の識別子を加えて、現在の物理サーバ２の区間リスト２５０に追加する。

一方、ステップＳ１４４の判定で、日時Ａまたは日時Ｂの少なくとも一方が存在する場合には、予約要求区間が複数の予約済み区間と重複するためステップＳ１４５へ進む。

ステップＳ１４５では、区間終了日時を次式により設定する。
区間終了日時 ＝ ＭＩＮ（日時Ａ、日時Ｂ、予約要求終了日時） ………（１）
ただし、ＭＩＮは日時Ａ、日時Ｂ、予約要求終了日時のうち最も小さい値を選択する関数である。

ステップＳ１４６では、予約管理部１２０は、ステップＳ１４０で設定した区間開始日時と、ステップＳ１４５で求めた区間終了日時に、区間の識別子を加えて、現在の物理サーバ２の区間リスト２５０に追加する。

ステップＳ１４７では、予約管理部１２０は、区間開始日時に現在の区間終了日時を設定して、次の区間を求めるためステップＳ１４２の処理に戻る。

上記処理により、予約要求情報３１０で要求された開始日時３１４と終了日時３１５の予約要求区間は、物理サーバ２毎に一つまたは複数の期間に分割された区間リスト２５０が生成される。区間リスト２５０は、予約テーブル２４０で予約済み区間と重複し、かつ、予約済み区間が開始または終了する日時で予約要求区間を分割したリストとなる。

図２７は、各物理サーバ２毎の予約要求区間の区間リストである。図１０で示すように、予約要求情報３１０の予約要求区間は、物理サーバ＃１では予約済み区間によって、区間１〜区間３の３つの区間に分割される。つまり、図２６の処理では、区間リストの開始日時を、図２７に示す予約要求区間の開始日時に設定してから、予約要求区間内で予約済みの開始日時及び終了日時を探索する。

図２７において、物理サーバ＃１の予約済みの区間で、予約要求区間と重複するサービスは、仮想マシン＃１のサービス＃１と、仮想マシン＃２のサービス＃２である。仮想マシン＃２のサービス＃１の開始日時がサービス＃２終了日時よりも始点に近いため、予約要求区間は、始点からサービス＃２の開始日時までの区間が区間１となる。次に、サービス＃２の開始日時からサービス＃１の終了日時までが区間２となり、サービス＃１の終了日時から予約要求区間の終了日時までが区間３となる。

一方、物理サーバ＃３では、予約要求区間内で仮想マシン＃４のサービス＃１の開始と終了がないため、予約要求区間がひとつの区間１となる。

このように、区間リスト２５０は、物理サーバ２毎の予約済みの状況に応じて予約要求区間の区間が異なる。

予約管理部１２０は、上記区間リスト２５０に加えて、図１１、図１２、図１３に示す割当判定テーブル２８０−１〜２８０−３を生成することができる。なお、図１２の物理サーバ＃２の割当判定テーブル２８０−２では、区間２で割当可否２８６が「不可」となっているので、区間２以降の区間についてはエントリを作成しなくてもよい。すなわち、予約要求情報３１０のサービスを、ひとつの物理サーバ２で継続して処理することを目的とするため、割当可否２８６が不可の区間を含む物理サーバ２は、割当先候補３２０から除外する。

図２８は、図２２のステップＳ１２５で行われる割当先候補の評価処理の一例を示すフローチャートである。この処理は、図２２の処理で、割当先候補の一覧（割当先候補３２０）と区間リスト２５０を取得した後に実行される。

ステップＳ１５０では、予約管理部１２０が区間リスト２５０を取得する。そして、予約管理部１２０は、区間リスト２５０の全ての区間毎にステップＳ１５１〜Ｓ１５７の処理を繰り返す。ステップＳ１５１では、予約管理部１２０が区間リスト２５０から未選択の区間をひとつ選択する。このとき、当該区間の物理サーバ２の識別子も取得する。

ステップＳ１５２では、予約管理部１２０が現在選択した区間の開始日時２５２と終了日時２５３から物理サーバ２の識別子で予約テーブル２４０を検索し、当該区間で予約済みのサービスの組み合わせを取得する。そして、予約管理部１２０は、取得した予約済みのサービスの組み合わせに、予約要求情報３１０のサービス３１１を加えた検索用のサービスの組み合わせを生成する。

ステップＳ１５３では、予約管理部１２０はステップＳ１５２で生成した検索用のサービスの組み合わせを含む組み合わせを、サービス組み合わせテーブル２７０から検索する。ステップＳ１５４では、予約管理部１２０は、サービス組み合わせテーブル２７０に検索用のサービスの組み合わせを含むエントリがあるか否かを判定する。予約管理部１２０は、検索用のサービスの組み合わせを含むエントリがなければ、ステップＳ１６０で現在の区間の評価値を「０」としてからステップＳ１５１に戻って次の区間について上記処理を繰り返す。

一方、予約管理部１２０は、検索用のサービスの組み合わせを含むエントリがサービス組み合わせテーブル２７０に存在する場合、ステップＳ１５５に進む。このとき、予約管理部１２０は、検索用のサービスの組み合わせ＝予約を要求された新たなサービスと、既に予約済みのサービスの組み合わせでは、過去にリソース不足などの異常があった履歴を検知する。予約管理部１２０は、予約を要求されたサービス（予約要求情報３１０）と既に予約済みのサービスの組み合わせが、過去に不具合（物理計算機の異常発生）を招いたことがある警告を管理クライアント６に出力してもよい。つまり、サービスの割り当て当初は、物理サーバ２のリソース量を超えることはないが、既に予約されたサービスと受け付けたサービスを同時に稼動させていくと、いずれ物理サーバ２のリソース量が不足する可能性が高いサービスの組み合わせであることを管理サーバ１は管理クライアント６に警告することができる。

すなわち、本実施形態では、現在選択中の区間で予約済みのサービスに、予約を要求されたサービス＃５を加えた組み合わせ（検索用のサービスの組み合わせ）を、現在選択中の物理サーバ２（＃１）で実行した場合に、過去にリソース不足となった履歴があった場合、検索用のサービスの組み合わせを含む履歴について評価を行う。

ステップＳ１５５では、予約管理部１２０はサービス組み合わせテーブル２７０からステップＳ１５３の条件を満たすリソース不足の履歴から未選択のエントリをひとつ選択する。そして、ステップＳ１５６では、予約管理部１２０は、サービス組み合わせテーブル２７０から選択したリソース不足の履歴について、日付と曜日または時期から評価値を演算する。

予約管理部１２０は、図２５に示す評価値テーブル３３０に基づいて、選択したリソース不足のエントリの曜日と日付または時期に基づく評価値を演算する。図２９は、評価値テーブル３３０の一例を示す。評価値テーブル３３０は、評価値の変数を示す評価値３３１と、評価する項目を示す評価項目３３２と、評価値を付与する内容を格納する評価基準３３３とからひとつのエントリが構成される。

変数Ａは、評価項目３３２が「曜日」の評価基準３３３で採点した値を設定する。

評価項目３３２が「曜日」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ週及び曜日を含む場合は、変数Ａ＝２点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ曜日のみを含む場合は、変数Ａ＝１点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ曜日を含まない場合は、変数Ａ＝０点とする。

変数Ｂは、評価項目３３２が「日付」の評価基準３３３で採点した値を設定する。

評価項目３３２が「日付」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ月日を含む場合は、変数Ｂ＝２点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ日のみを含む場合は、変数Ｂ＝１点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時２７８と同じ日を含まない場合は、変数Ｂ＝０点とする。

変数Ｃは、評価項目３３２が「期末」の評価基準３３３で採点した値を設定する。

評価項目３３２が「期末」の評価基準３３３は、現在選択したリソース不足の履歴の発生日時２７８が期末で、現在選択した区間が期末の場合は、変数Ｃ＝４点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択したリソース不足の履歴の発生日時２７８が月末で、現在選択した区間が期末の場合は、変数Ｃ＝２点とする。

評価項目３３２が「曜日」の評価基準３３３は、現在選択したリソース不足の履歴の発生日時２７８が月末ではなく、また現在選択した区間が月末ではない場合は、変数Ｃ＝０点とする。

予約管理部１２０は、現在選択した区間とリソース不足の履歴の日付２７８から評価値テーブル３３０を用いて変数Ａ、Ｂ，Ｃをそれぞれ求める。そして、予約管理部１２０は、次式により、
評価値 ＝ １＋Ａ＋Ｂ＋Ｃ ………（２）
として評価値を求める。

次に、ステップＳ１５７では、現在選択した区間に対応する物理サーバ２が有するリソース量に基づいて上記評価値を補正する。予約管理部１２０は、現在選択した区間に対応する物理サーバ２のリソース量を物理サーバ構成テーブル２００から取得して以下の変数Ｒ１、Ｒ２を求める。

Ｒ１＝履歴の未予約ＣＰＵ性能／物理サーバの未予約ＣＰＵ性能 ………（３）

履歴の未予約ＣＰＵ性能は、サービス組み合わせテーブル２７０の未予約ＣＰＵ性能２７５であり、物理サーバの未予約ＣＰＵ性能は、図１４、図１５の評価結果テーブル２６０の未予約ＣＰＵ性能２６７である。なお、ＣＰＵ性能は、上述したようにクロック数×コア数で表される。

Ｒ２＝履歴の未予約メモリ容量／物理サーバの未予約メモリ容量 ………（４）

履歴の未予約メモリ容量は、サービス組み合わせテーブル２７０の未予約メモリ容量２７６であり、物理サーバの未予約メモリ容量は、図１４、図１５の評価結果テーブル２６０の未予約メモリ容量２６８である。なお、ＣＰＵ性能は、上述したようにクロック数×コア数で表される。

また、予約管理部１２０は、上記（２）式で求めた日付と曜日に基づく評価値を変数Ｅに設定する。
Ｅ ＝ １＋Ａ＋Ｂ＋Ｃ ………（５）
予約管理部１２０は、上記変数Ｒ１、Ｒ２、Ｅから評価値を、
評価値 ＝ Ｅ × ｍａｘ（Ｒ１，Ｒ２） ………（６）
として更新する。ただし、ｍａｘ（Ｒ１，Ｒ２）は、Ｒ１とＲ２の値のうち、大きい値を選択する関数である。

例えば、図２０の予約要求情報３１０のサービス＃５を物理サーバ＃１に予約する場合、図２７において、区間２ではサービス＃２にサービス＃５の組み合わせは、図９のサービス組み合わせテーブル２７０のリソース不足２に該当するので、評価値を求める。

まず、予約管理部１２０は上記ステップＳ１５６で日付と曜日及び期末に関する評価値を評価値テーブル３３０で求める。ここで、物理サーバ＃１の区間２とサービス組み合わせテーブル２７０のリソース不足２の値から日付と曜日及び期末に関する評価値は図２６で示すように各変数Ａ〜Ｃが求められる。なお、図３０は、評価値３０３１が図２９の評価値テーブル３３０の評価値３３１の変数に対応し、評価項目３０３２が図２９の評価値テーブル３３０の評価項目３３２に対応し、履歴３０３３はリソース不足２の月日に関する情報を示し、区間３０３４は区間２の月日に関する情報を示す。

この結果、上記（５）式は、
Ｅ ＝ １＋１＋０＋０ ＝ ２
となり、上記（３）式は、
Ｒ１ ＝ ２／｛２×４−（２＋２＋１）｝ ＝ ２／３
となり、上記（４）式は、
Ｒ２ ＝ １／｛６−（２＋１＋１）｝ ＝ １／２
となる。この結果、上記６式より、
評価値 ＝ ２×ｍａｘ（２／３，１／２）＝ ４／３ ≒ １．３３
となる。ステップＳ１５７では、上記評価値を現在選択した区間の評価結果テーブル２６０に格納する。

そして、現在選択した区間のサービスの組み合わせに一致する全てのリソース不足の履歴について上記処理が完了すると、予約管理部１２０は、ステップＳ１５８の処理を行う。

ステップＳ１５８では、予約管理部１２０が上記ステップＳ１５７で求めた区間の評価値の合計を現在選択した区間の評価値として演算する。上記の例では、物理サーバ＃１の区間１の評価値が０、区間２の評価値が約１．３３、区間３の評価値が１．６となる。予約管理部１２０は、各区間毎に評価値を評価結果テーブル２６０に格納する。

上記ステップＳ１５１〜Ｓ１５８の処理が全ての区間について完了すると、ステップＳ１５９の処理へ進む。ステップＳ１５９では、予約管理部１２０は、物理サーバ２毎に上記各区間の評価値のうち最大の評価値を、当該物理サーバ２の評価値として割当先評価値テーブル２９０に設定する。例えば、割当先候補３２０の物理サーバ２の識別子が物理サーバ＃１、物理サーバ＃３の場合、図１４、図１５より、物理サーバ＃１の評価値＝１．６、物理サーバ＃３の評価値＝０が、それぞれ評価値２９２に格納される。

上記図２８の処理が終了すると、上述した図２２のステップＳ１２６に進み、予約管理部１２０は、割当先評価値テーブル２９０の評価値２９２が最も小さい物理サーバ２の識別子２９１を予約要求情報３１０の割り当て先として選択し、予約テーブル２４０に登録する。

以上のように、本実施形態によれば、管理サーバ１は、過去にリソース不足等の異常が発生したサービスの組み合わせと物理サーバ２とをサービス組み合わせテーブル２７０に記憶しているので、新たにサービスを追加予約する場合、リソース不足等の異常が発生する可能性のある組み合わせを回避できる。これにより、物理サーバ２上で実行される複数の仮想マシンでそれぞれサービスを提供する仮想計算機システムにおいて、管理サーバ１が適切に仮想マシン及びサービスを物理サーバ２上に配置し、最適な予約を実現することができる。すなわち、予約したサービスの組み合わせの実行を開始した時点ではリソース不足が発生しないが、稼動期間の経過によってサービスの負荷が増大した場合、仮想化部（ハイパーバイザ３０）が当該サービスを実行する仮想マシン４０へのリソースの割り当てを増やす場合がある。物理サーバ２上の複数のサービスでリソース量の割り当てを増やしていくと仮想化部はリソースを割り当て不能になる場合がある。そこで、管理サーバ１は過去の異常発生の履歴に基づいて、長期的に見て物理サーバ２のリソース量が不足するなどの異常が発生するサービスの組み合わせを警告または回避することができる。

また、管理サーバ１は、リソース不足等の異常が発生したときのサービスの各々のリソースの予約量も把握しているので、より正確にリソース不足とならない組合せを抽出して予約テーブル２４０に予約することができる。

さらに、サービス組み合わせテーブル２７０は、各サービスの処理特性としてリソース不足となった曜日や時間帯などの時期も記憶しているので、管理サーバ１は、サービスを新たに予約する時間帯や曜日を含む時期も考慮してリソース不足とならない組み合わせを抽出して予約することができる。つまり、サービスの種類によっては、週末や特定の日にちあるいは、月末または期末など、特定の時期になると負荷が増大して使用するリソース量が増大し、この結果、ハイパーバイザ３０がリソース不足となる場合がある。このため、予約する時点では、予約するサービスのリソース量と、予約済みのサービスのリソース量が、仮想マシン４０を実行する物理サーバ２のリソース量以内であっても、上記所定の時期になると、リソース不足になるサービスの組み合わせを予測することができる。

また、管理サーバ１は、過去にリソース不足等の異常が発生したサービスの組み合わせと物理サーバ２とをサービス組み合わせテーブル２７０に記憶しているので、新たにサービスを追加予約する場合、リソース不足となる組み合わせを管理クライアント６に通知することができる。これにより、管理クライアント６を利用する管理者などに、不適なサービスの組み合わせを通知することができる。

さらに、本実施形態の管理サーバ１は、サービスとリソースの要求量を予めセットしたテンプレートをテンプレートテーブル２３０に格納しておき、サービスの予約時にテンプレートを選択し、予約の開始と終了の日時を入力すればよいので、リソースの要求量を検討することなく予約を行うことができる。これにより、リソースの要求量を予約の度に設定する必要がなくなり、管理者やユーザなどの予約に関する労力を大幅に低減することが可能となる。

なお、上記実施形態では、ハイパーバイザ３０によって仮想マシン４０を稼動させる例を示したが、物理サーバ２の資源を仮想マシン４０に割り当てる仮想化部としては、ＶＭＭ（Virtual Machine Monitor）を用いてもよい。

また、上記実施形態では、リソース監視部１３０が、ハイパーバイザ３０からリソース不足の通知を受信したときにサービス組み合わせテーブル２７０にサービスの組み合わせやリソースの状態を記録したが、サービス組み合わせテーブル２７０に格納する情報はリソース不足に限定されるものではない。例えば、仮想マシン４０がハイパーバイザ３０へ異常の発生を通知したときや、ハイパーバイザ３０が仮想マシン４０の停止を検知したときに、管理サーバ１へ通知する。管理サーバ１は、ハイパーバイザ３０からの異常の発生の通知を受信し、異常の種類に応じて事象２７１を適宜設定してサービス組み合わせテーブル２７０にエントリを追加すればよい。

なお、上記実施形態では、管理サーバ１が物理計算機で構成された一例を示したが、管理サーバ１が仮想マシン４０で提供されてもよい。この場合、仮想マシン４０のひとつが管理部として機能し、サービスの予約と計算器資源を管理する。

なお、上記実施形態では、管理サーバ１がリソース不足などの異常の発生要因となるサービスの組み合わせを検知し、サービス組み合わせテーブル２７０に蓄積している例を示したが、図２のリソース監視部１３０を削除して、予め設定されたサービス組み合わせテーブル２７０を使用してもよい。この場合、サービス組み合わせテーブル２７０には、物理サーバ２のリソース不足などの異常が発生する可能性のあるサービスの組み合わせと、異常が発生する可能性のある時期とを予め記録しておけばよい。

本発明は、仮想マシンでサービスを提供し、サービスの実行を予約する仮想計算機システムに適用することができ、特に、複数の仮想マシンを割り当てる物理計算機を管理する管理計算機に適用することができる。

Claims (13)

1. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する１つ以上の仮想マシンと前記仮想マシンに割り当てるサービスと前記仮想化部を管理計算機で管理するサービスの予約管理方法であって、
   前記管理計算機が、前記物理計算機に異常が発生したことを検知し、前記物理計算機に異常が発生したときのサービスの組み合わせと、前記異常が発生した曜日と日時と、をサービス組み合わせ情報に格納する第１の手順と、
   前記管理計算機が、開始日時と終了日時の予約要求期間を含むサービスの予約を受け付ける第２の手順と、
   前記管理計算機が、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納した予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第３の手順と、
   前記管理計算機が、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、前記サービス組み合わせ情報を参照して、前記サービスの組み合わせと前記物理計算機に異常が発生した曜日と日時の履歴から、前記予約要求期間を評価する第４の手順と、
   前記管理計算機が、前記評価の結果に基づいて、前記予約要求期間で物理計算機に異常が発生する可能性を予測する第５の手順と、
   を含むことを特徴とするサービスの予約管理方法。
2. 請求項１に記載のサービスの予約管理方法であって、
   前記第４の手順は、
   前記予約要求期間が、前記サービス組み合わせ情報で異常が発生した前記履歴に一致する場合には、前記履歴の曜日または日時に応じて予め設定された評価項目と前記予約要求期間を比較して評価値を付与し、
   前記第５の手順は、
   前記評価値に基づいて、前記予約要求期間で物理計算機に異常が発生する可能性を予測することを特徴とするサービスの予約管理方法。
3. 請求項１に記載のサービスの予約管理方法であって、
   前記第２の手順は、
   前記管理計算機が、前記予約を受け付けたサービスを稼動させる第１の仮想マシンに割り当てる物理計算機のリソース量を受け付ける手順をさらに含み、
   前記第３の手順は、
   前記管理計算機が、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出する手順と、
   前記管理計算機が、前記抽出されたサービスを稼動させる第２の仮想マシンに割り当てる物理計算機のリソース量と、前記第１の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択する手順と、
   前記管理計算機が、前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索する手順と、
   を含むことを特徴とするサービスの予約管理方法。
4. 請求項１に記載のサービスの予約管理方法であって、
   前記第３の手順は、
   前記管理計算機が、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出する手順を含み、
   前記第４の手順は、
   前記管理計算機が、前記抽出されたサービスと前記予約を受け付けたサービスとの組み合わせが、前記サービス組み合わせ情報に含まれ、かつ、前記抽出されたサービスの稼動期間と、前記予約を受け付けたサービスの前記予約要求期間が前記サービス組み合わせ情報の前記異常が発生した曜日または日時を含む場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とするサービスの予約管理方法。
5. 請求項１に記載のサービスの予約管理方法であって、
   前記管理計算機は、前記サービスと、当該サービスを実行する仮想マシンに割り当てる物理計算機のリソース量を、前記サービス毎に予め設定した複数のテンプレートを保持し、
   前記第２の手順は、
   前記管理計算機が、前記テンプレートのいずれかひとつを受け付けることを特徴とするサービスの予約管理方法。
6. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、
   前記物理計算機で実行される仮想化部が提供する１つ以上の仮想マシンと、
   前記仮想マシンに割り当てるサービスと、前記仮想化部を管理する管理計算機とを備えた仮想計算機システムであって、
   前記管理計算機は、
   開始日時と終了日時の予約要求期間を含む前記サービスの予約を受け付けて、予約情報に格納する予約管理部と、
   前記物理計算機の構成と、前記仮想マシンの構成と、前記サービスの構成を管理するリソース管理部と、
   前記物理計算機に異常が発生したときのサービスの組み合わせと、前記異常が発生した曜日と日時と、をサービス組み合わせ情報に格納するリソース監視部と、を有し、
   前記予約管理部は、
   前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索し、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力し、
   前記サービス組み合わせ情報を参照して、前記物理計算機に異常が発生した曜日と日時の履歴から、前記予約要求期間を評価し、前記評価の結果に基づいて、前記物理計算機に異常が発生する可能性を予測することを特徴とする仮想計算機システム。
7. 請求項６に記載の仮想計算機システムであって、
   前記予約管理部は、
   前記予約要求期間が、前記サービス組み合わせ情報で異常が発生した前記履歴に一致する場合には、前記履歴の曜日または日時に応じて予め設定された評価項目と前記予約要求期間を比較して評価値を付与し、前記評価値に基づいて、前記予約要求期間で物理計算機に異常が発生する可能性を予測することを特徴とする仮想計算機システム。
8. 請求項６に記載の仮想計算機システムであって、
   前記予約管理部は、
   前記予約を受け付けたサービスを稼動させる第１の仮想マシンに割り当てる物理計算機のリソース量を受け付け、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出し、前記抽出されたサービスを稼動させる第２の仮想マシンに割り当てる物理計算機のリソース量と、前記第１の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択し、前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索することを特徴とする仮想計算機システム。
9. 請求項６に記載の仮想計算機システムであって、
   前記予約管理部は、
   前記サービスと、前記サービスの稼動期間を予約要求期間として受け付けて、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出し、前記抽出されたサービスと前記予約を受け付けたサービスの組み合わせが、前記サービス組み合わせ情報に含まれ、かつ、前記抽出されたサービスの稼動期間と、前記予約を受け付けたサービスの前記予約要求期間が前記サービス組み合わせ情報の時期を含む場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とする仮想計算機システム。
10. 請求項６に記載の仮想計算機システムであって、
    前記予約管理部は、
    前記サービスと、当該サービスを実行する仮想マシンに割り当てる物理計算機のリソース量を、前記サービス毎に予め設定した複数のテンプレートを保持し、前記テンプレートのいずれかひとつを予約するサービスとして受け付けることを特徴とする仮想計算機システム。
11. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する１つ以上の仮想マシンと、
    前記仮想マシンに割り当てるサービスと前記仮想化部を管理するプログラムであって、
    前記物理計算機に異常が発生したことを検知し、前記物理計算機に異常が発生したときのサービスの組み合わせと、前記異常が発生した曜日と日時と、をサービス組み合わせ情報に格納する第１のステップと、
    開始日時と終了日時の予約要求期間を含む前記サービスの予約を受け付ける第２のステップと、
    前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納する予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第３のステップと、
    前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力する第４のステップと、
    前記サービス組み合わせ情報を参照して、前記物理計算機に異常が発生した曜日と日時の履歴から、前記予約要求期間を評価する第５のステップと、
    前記評価の結果に基づいて、前記物理計算機に異常が発生する可能性を予測する第６のステップと、
    を管理計算機に実行させるプログラムを格納したことを特徴とする非一時的計算機読み取り可能な記憶媒体。
12. 請求項１１に記載の記憶媒体であって、
    前記第４のステップは、
    前記予約要求期間が、前記サービス組み合わせ情報で異常が発生した前記履歴に一致する場合には、前記履歴の曜日または日時に応じて予め設定された評価項目と前記予約要求期間を比較して評価値を付与し、
    前記第５のステップは、
    前記評価値に基づいて、前記予約要求期間で物理計算機に異常が発生する可能性を予測することを特徴とする記憶媒体。
13. 請求項１１に記載の記憶媒体であって、
    前記第２のステップは、
    前記予約を受け付けたサービスを稼動させる第１の仮想マシンに割り当てる物理計算機のリソース量を受け付けるステップをさらに含み、
    前記第３のステップは、
    前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出するステップと、
    前記抽出されたサービスを稼動させる第２の仮想マシンに割り当てる物理計算機のリソース量と、前記第１の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択するステップと、
    前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索するステップと、
    を含むことを特徴とする記憶媒体。

Images