"プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する1つ以上の仮想マシンと前記仮想マシンに割り当てるサービスと前記仮想化部を管理計算機で管理するサービスの予約管理方法であって、前記管理計算機が、サービスの予約を受け付ける第1の手順と、前記管理計算機が、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納する予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第2の手順と、前記管理計算機が、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力する第3の手順と、を含むことを特徴とするサービスの予約管理方法。請求項1に記載のサービスの予約管理方法であって、前記サービス組み合わせ情報は、前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせを格納し、前記第1の手順は、前記管理計算機が、前記サービスと、前記サービスの稼動期間を予約要求期間として受け付けて、前記第2の手順は、前記管理計算機が、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出する手順と、前記管理計算機が、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせで、前記サービス組み合わせ情報を検索する手順と、を含み、前記第3の手順は、前記管理計算機が、前記抽出されたサービスと前記予約を受け付けたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、前記抽出されたサービスと前記予約を受け付けたサービスとを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とするサービスの予約管理方法。請求項2に記載のサービスの予約管理方法であって、前記第1の手順は、前記管理計算機が、前記予約を受け付けたサービスを稼動させる第1の仮想マシンに割り当てる物理計算機のリソース量を受け付ける手順をさらに含み、前記第2の手順は、前記管理計算機が、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出する手順と、前記管理計算機が、前記抽出されたサービスを稼動させる第2の仮想マシンに割り当てる物理計算機のリソース量と、前記第1の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択する手順と、前記管理計算機が、前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索する手順と、を含むことを特徴とするサービスの予約管理方法。請求項2に記載のサービスの予約管理方法であって、前記サービス組み合わせ情報は、前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせと、異常発生の可能性がある時期を格納し、前記第3の手順は、前記管理計算機が、前記抽出されたサービスと前記予約を受け付けたサービスとの組み合わせが、前記サービス組み合わせ情報に含まれ、かつ、前記抽出されたサービスの稼動期間と、前記予約を受け付けたサービスの予約期間が前記サービス組み合わせ情報の時期を含む場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とするサービスの予約管理方法。請求項1に記載のサービスの予約管理方法であって、前記管理計算機が、前記物理計算機に異常が発生したことを検知する第4の手順と、前記管理計算機が、前記物理計算機に異常が発生したときに、前記物理計算機上の仮想マシンで稼動していたサービス組み合わせを前記サービス組み合わせ情報に格納する第5の手順と、をさらに含むことを特徴とするサービスの予約管理方法。請求項1に記載のサービスの予約管理方法であって、前記管理計算機は、前記サービスと、当該サービスを実行する仮想マシンに割り当てる物理計算機のリソース量を、前記サービス毎に予め設定した複数のテンプレートを保持し、前記第1の手順は、前記管理計算機が、前記テンプレートのいずれかひとつを受け付けることを特徴とするサービスの予約管理方法。プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する1つ以上の仮想マシンと、前記仮想マシンに割り当てるサービスと、前記仮想化部を管理する管理計算機とを備えた仮想計算機システムであって、前記管理計算機は、前記サービスの予約を受け付けて、予約情報に格納する予約管理部と、前記物理計算機の構成と、前記仮想マシンの構成と、前記サービスの構成を管理するリソース管理部と、を有し、前記予約管理部は、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索し、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とする仮想計算機システム。請求項7に記載の仮想計算機システムであって、前記サービス組み合わせ情報は、前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせを格納し、前記予約管理部は、前記サービスと、前記サービスの稼動期間を予約要求期間として受け付けて、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出し、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせで、前記サービス組み合わせ情報を検索し、前記抽出されたサービスと前記予約を受け付けたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とする仮想計算機システム。請求項8に記載の仮想計算機システムであって、前記予約管理部は、前記予約を受け付けたサービスを稼動させる第1の仮想マシンに割り当てる物理計算機のリソース量を受け付け、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出し、前記抽出されたサービスを稼動させる第2の仮想マシンに割り当てる物理計算機のリソース量と、前記第1の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択し、前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索することを特徴とする仮想計算機システム。請求項8に記載の仮想計算機システムであって、前記サービス組み合わせ情報は、前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせと、異常発生の可能性がある時期を格納し、前記予約管理部は、前記抽出されたサービスと前記予約を受け付けたサービスの組み合わせが、前記サービス組み合わせ情報に含まれ、かつ、前記抽出されたサービスの稼動期間と、前記予約を受け付けたサービスの予約期間が前記サービス組み合わせ情報の時期を含む場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とする仮想計算機システム。請求項7に記載の仮想計算機システムであって、前記管理計算機は、前記物理計算機に異常が発生したことを検知し、前記物理計算機に異常が発生したときに、前記物理計算機上の仮想マシンで稼動していたサービス組み合わせを前記サービス組み合わせ情報に格納するリソース監視部を、さらに有することを特徴とする仮想計算機システム。請求項7に記載の仮想計算機システムであって、前記予約管理部は、前記サービスと、当該サービスを実行する仮想マシンに割り当てる物理計算機のリソース量を、前記サービス毎に予め設定した複数のテンプレートを保持し、前記テンプレートのいずれかひとつを予約するサービスとして受け付けることを特徴とする仮想計算機システム。プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する1つ以上の仮想マシンと、前記仮想マシンに割り当てるサービスと前記仮想化部を管理するプログラムであって、前記サービスの予約を受け付ける第1のステップと、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納する予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第2のステップと、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力する第3のステップと、を管理計算機に実行させるプログラムを格納したことを特徴とする非一時的計算機読み取り可能な記憶媒体。請求項13に記載の記憶媒体であって、前記サービス組み合わせ情報は、前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせを格納し、前記第1のステップは、前記サービスと、前記サービスの稼動期間を予約要求期間として受け付けて、前記第2のステップは、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出するステップと、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせで、前記サービス組み合わせ情報を検索するステップと、を含み、前記第3のステップは、前記抽出されたサービスと前記予約を受け付けたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、前記抽出されたサービスと、前記予約を受け付けたサービスを同時に前記物理計算機で同時に実行したときに異常発生の可能性があるサービスの組み合わせである警告を出力することを特徴とする記憶媒体。請求項14に記載の記憶媒体であって、前記第1のステップは、前記予約を受け付けたサービスを稼動させる第1の仮想マシンに割り当てる物理計算機のリソース量を受け付けるステップをさらに含み、前記第2のステップは、前記予約情報に含まれる稼動期間が前記予約要求期間と重複するサービスを抽出するステップと、前記抽出されたサービスを稼動させる第2の仮想マシンに割り当てる物理計算機のリソース量と、前記第1の仮想マシンに割り当てるリソース量の和を満たすリソース量を備えた物理計算機を選択するステップと、前記選択された物理計算機で、前記抽出されたサービスと、前記予約を受け付けたサービスの組み合わせを実行したときに、前記物理計算機に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を検索するステップと、を含むことを特徴とする記憶媒体。しかしながら、予約されたリソース量に基づいて仮想マシンを稼働させても、仮想マシン上で実行するサービスに対する処理要求数の変動は、その様態や利用形態によって様々である。特に複数の業務システムを同じ物理サーバ上の仮想マシンで実行する場合、相互の業務システムで同時に稼働するサービスを考慮する必要がある。例えば、ある業務システムAで稼働するサービスAと、業務システムBで稼働するサービスBとを仮想マシンaと仮想マシンbに割り当てて、同時に一つの物理サーバ上で実行する場合を想定する。サービスAとサービスBとを同時に実行中、サービスBに対する処理要求数が想定以上に増大し、サービスBの仮想マシンでリソース不足となる場合がある。この場合の対処方法としては、サービスAの仮想マシンaをホットマイグレーションによって別の物理サーバへ退避させ、サービスAで使用していたリソースをサービスBを実行する仮想マシンbに再割り当てすることでリソース不足を解消することができる。しかし、予約システムにおいてはこのような突発的な変動を事前に推測して考慮することができない。例えば、特許文献1におけるリソースの事前予約を行ったとしても、当該サービスに対するリソース不足をサービスを開始した後では解消することが困難である。さらに、上記ホットマイグレーションでは、移動元の物理計算機から移動先の物理計算機間でネットワークの負荷が高くなる。このため、リソース不足で負荷の高い状態の物理計算機でホットマイグレーションを行うことは避けることが望ましい。また、特許文献2においては、物理計算機の性能不足を実行履歴から把握するが、これは仮想マシンで実行するサービスが、固定的に特定の物理計算機上で稼動していることが前提である。サービスを固定的に特定の物理計算機上で実行することで過去の実行履歴からの性能不足を特定でき、かつ適切なリソース量を決定することができる。ところが予約システムにより複数の業務システムの予約を行うと、予約システムは、サービスを実行するのに必要なリソース量の最適な組み合わせから、自由にかつ柔軟にサービスを配置することができる。即ち予約システムに基づいてサービスを配置すると、同じ時間に稼働するサービスの組み合わせはいつも同じとは限らなくなる。すると、過去の実行履歴から性能を把握して適切なリソース量を決定できたとしても、測定された実行履歴と同じサービスの組み合わせを実行する環境でなければ活用することができない、という問題があった。特に、予約システムに基づいてサービスの組み合わせが変動する仮想マシン環境の場合、サービスを実行する物理計算機は、計算機システムのリソースの状況に応じて変動するため、過去の実行履歴を活用することが困難となる、という問題があった。そこで本発明は上記問題点に鑑みてなされたもので、複数のサービスを複数の仮想マシンで実行させる際に、サービスの組み合わせによって物理計算機のリソースが不足するのを防止することを目的とする。本発明は、プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行される仮想化部が提供する1つ以上の仮想マシンと前記仮想マシンに割り当てるサービスと前記仮想化部を管理計算機で管理するサービスの予約管理方法であって、前記管理計算機が、サービスの予約を受け付ける第1の手順と、前記管理計算機が、前記物理計算器に異常発生の可能性があるサービスの組み合わせを格納したサービス組み合わせ情報を参照し、既に予約されたサービスを格納する予約情報のサービスと、前記受け付けたサービスとの組み合わせを検索する第2の手順と、前記管理計算機が、前記受け付けたサービスと前記予約情報に格納されたサービスの組み合わせが、前記サービス組み合わせ情報に含まれる場合には、異常発生の可能性があるサービスの組み合わせである警告を出力する第3の手順と、を含む。本発明によれば、過去にリソース不足等の異常発生となったサービスの組み合わせをサービス組み合わせ情報に格納しているので、新たにサービスを予約する場合、管理計算機は、リソース不足となる組み合わせについて警告を出力することができる。これにより、リソース不足など、物理計算機で異常発生の可能性とならないサービスの組み合わせを設定することができ、適切にサービスを物理計算機に配置する予約を実現することができる。以下、本発明の一実施形態について添付図面を用いて説明する。図1は本発明の実施形態の仮想計算機システムの構成の一例を示すブロック図である。仮想計算機システムは、複数の仮想マシン40-1~40-5を提供する物理サーバ2-1~2-3と、これら管理対象の物理サーバ2-1~2-3を管理する管理サーバ1と、管理サーバ1に指令を行う管理クライアント6と、物理サーバ2-1~2-3と管理サーバ1と管理クライアント6を接続する通信ネットワーク50と、を主体にして構成される。物理サーバ2-1~2-3は、同一の構成を備える。なお、以下の説明では、物理サーバ2-1~2-3の総称を物理サーバ2とし、仮想マシン40-1~40-5の総称を仮想マシン40とする。物理サーバ2は、プロセッサ20とメモリ22とストレージ装置21を備えた物理計算機である。物理サーバ2では、それぞれハイパーバイザ30が実行され、ハイパーバイザ30が複数の仮想マシン40を提供する。ハイパーバイザ30は、物理サーバ2の物理資源を分割して論理区画に割り当てて、各論理区画でそれぞれ仮想マシン40を実行させる。なお、ハイパーバイザ30は、論理区画に割り当てる物理サーバ2の資源を動的に変更するDynamicLogicalPartitioning以下、動的割当変更の機能を含む。ハイパーバイザ30は、仮想マシン40上で実行中のサービス等が必要とするリソースが増大した場合、当該サービスを実行する仮想マシン40に割り当てるリソースを追加または変更することができる。例えば、ハイパーバイザ30の動的割当変更部300図3参照は、仮想マシン40の負荷が増大した場合、未割当のリソースCPUやメモリを負荷が増大した仮想マシン40に自動的に割り当てる。図1の例では、物理サーバ2-1のハイパーバイザ30が仮想マシン40-1、40-2VM1、VM2を提供し、物理サーバ2-2のハイパーバイザ30が仮想マシン40-3VM3を提供し、物理サーバ2-3のハイパーバイザ30が仮想マシン40-4、40-5VM4、VM5を提供する例を示す。各仮想マシン40は、通信ネットワーク50を介して図示しないユーザ端末にサービスを提供する。また、各物理サーバ2のハイパーバイザ30は、物理サーバ2のリソースが不足したり不具合が発生すると管理サーバ1に所定の警報を通知する。管理サーバ1は、プロセッサ10とメモリ12とストレージ装置11を備えた物理計算機である。管理サーバ1はストレージ装置11から管理プログラムをメモリ12へ読み込んでプロセッサ20で実行し、複数の物理サーバ2を後述するように管理する。なお、ストレージ装置11は管理プログラムを格納する非一時的な記憶媒体としても機能する。管理クライアント6は、プロセッサ60とメモリ62とストレージ装置61と入力装置63と出力装置64を備えた物理計算機である。管理クライアント6は、仮想計算機システムの管理者などが使用する。管理者等は入力装置63を介して管理サーバ1に指令や設定を入力する。そして、管理クライアント6は、管理サーバ1から受信した情報を出力装置64に表示する。管理者は、管理クライアント6から物理サーバ2の構成情報の取得や仮想マシン40で実行するサービスや仮想マシン40の予約などを管理サーバ1に対して要求する。<管理サーバの構成>図2は、管理サーバ1で実行する管理プログラムの機能要素を示すブロック図である。物理サーバ2を管理するプログラムは、リソース管理部100と、テンプレート管理部110と、予約管理部120と、リソース監視部130と各種テーブル200~280を主体に構成される。リソース管理部100は、管理クライアント6や予約管理部120からの要求に基づいて、物理サーバ2-1~2-3で実行する仮想マシン40-1~40-5及びサービスを制御する。リソース管理部100は、各物理サーバ2のハイパーバイザ30から構成情報を取得して、物理サーバ構成テーブル200と仮想マシン構成テーブル210をメモリ12に格納する。また、リソース管理部100は、仮想マシン40で実行するサービスの種類を管理するサービス一覧テーブル220をメモリ12に格納する。リソース監視部130は、物理サーバ2のハイパーバイザ30からリソース不足等を示す警報を受信すると、物理サーバ2の仮想マシン40で実行しているサービスの組み合わせとリソースの情報をサービスの組み合わせテーブル270に格納する。サービス組み合わせテーブル270には、物理サーバ2でリソース不足などの異常が発生したときのサービスの組み合わせとリソースの状態の履歴が蓄積される。つまり、サービス組み合わせテーブル270には、物理サーバ2で同時に実行すると、リソース不足などの異常が発生する可能性のあるサービスの組み合わせが保持される。予約管理部120は、管理クライアント6からのサービスの予約要求情報310を受け付けて予約テーブル予約情報240に格納し、予約テーブル240に含まれる開始時刻に達するとリソース管理部100に対して当該サービスを仮想マシン40で実行するように要求する。また、予約管理部120は、予約テーブル240に含まれる終了時刻に達するとリソース管理部100に対して当該サービス及び仮想マシン40を終了するように要求する。予約管理部120は、サービスを実行させる仮想マシン40を物理サーバ2上に予約するため、サービスの稼動期間または予約期間を判定する区間リスト250と、物理サーバ2上で実行されるサービスの組み合わせを評価するための評価結果テーブル260と、予約するサービスが実行可能か否かを判定する割当判定テーブル280と割当先評価値テーブル290とをメモリ12に格納する。そして、予約管理部120は、予約の要求予約要求情報310を管理クライアント6から受け付けると、物理サーバ2の仮想マシン40に予約するサービスの組み合わせが、サービス組み合わせテーブル270に記録されたリソース不足が発生したサービスの組み合わせとならないように、予約されたサービスを実行する物理サーバ2-1~2-3を選択する。テンプレート管理部110は、仮想マシン40で実行するサービスと、仮想マシン40に要求されるリソース量割当量の要求値とを対応付けたテンプレートを生成し、テンプレートテーブル230に格納しておく。予約管理部120は、管理クライアント6からサービスの予約を受け付けるときに、テンプレートテーブル230を提示して、管理者にテンプレートを選択させることで、サービスの予約を簡易にすることができる。つまり、管理クライアント6を操作する管理者は、テンプレートから所望のサービスを選択するだけで、当該サービスに必要な仮想マシン40のリソース量を自動的に設定することが可能となる。これにより、管理者は、サービスを予約する度に仮想マシン40で必要となるリソース量を設定する手間を省略することができ、サービスの予約を効率よく行うことが可能となる。上記管理プログラムの処理の詳細と各テーブルの詳細については後述する。<物理サーバの構成>図3は、物理サーバ2で実行するプログラムの機能要素を示すブロック図である。なお、物理サーバ2-1~2-3は同一の構成であるので、物理サーバ2-1について説明し、他の物理サーバ2-2~2-3の説明を省略する。プロセッサ20は、ストレージ装置21からハイパーバイザ30をメモリ22に読み込んでから実行する。ハイパーバイザ30は、管理サーバ1からサービスの実行開始の指示を受け付けると、指示されたリソース量を物理サーバ2-1の物理資源から仮想マシン40を実行する論理区画に割り当てる。そして、ハイパーバイザ30は仮想マシン40-1、40-2を起動させてそれぞれOS41を実行させ、管理サーバ1から指示されたサービス42-1、42-2を各仮想マシン40のOS41上で実行させる。なお、OS41とサービス42-1、42-2はストレージ装置21または管理サーバ1のストレージ装置11から読み込む。なお、以下の説明では、サービス42-1サービス1、42-2サービス2の総称をサービス42とする。ここで、各仮想マシン40で実行されるサービス42は、プログラムの実行によってクライアントに提供される。そして、サービス42のプログラムはアプリケーション、デーモン、サービスの何れかの形態で実行される。ハイパーバイザ30は、上述のように仮想マシン40の負荷の変化に応じてリソースの割り当て量を動的に変更する動的割当変更部300を有する。動的割当変更部300の構成は、周知または公知のものを用いればよいのでここでは詳述しない。<各テーブルの構成>以下、管理サーバ1で使用する各テーブルの詳細について説明する。図4は、リソース管理部100が管理する物理サーバ構成テーブル200の一例を示す図である。物理サーバ構成テーブル200は、物理サーバ2の識別子を格納する物理サーバ201と、物理サーバ2のプロセッサ20の性能を格納するCPU性能202と、物理サーバ2に実装されたメモリ22の容量GBを格納するメモリ容量203からひとつのエントリが構成される。なお、CPU性能202には、プロセッサ20の動作周波数GHzとコア数が格納される。リソース管理部100は、所定の周期例えば、1時間で各ハイパーバイザ30から物理サーバ2の構成情報を取得し、物理サーバ構成テーブル200を更新する。図5は、リソース管理部100が管理する仮想マシン構成テーブル210の一例を示す図である。仮想マシン構成テーブル210は、仮想マシン40の識別子を格納する仮想マシン211と、仮想マシン40を稼動させる物理サーバ2の識別子を格納する物理サーバ212と、仮想マシン40に割り当てられたプロセッサ20の割り当て量を格納するCPU割り当て量213と、仮想マシン40に割り当てられたメモリ22の割り当て量を格納するメモリ割り当て量214と、仮想マシン40で実行するサービス42の識別子を格納するサービス215からひとつのエントリが構成される。なお、CPU割り当て量213には、仮想マシン40に割り当てたプロセッサ20のコア数に動作周波数GHzを乗じた値を割り当て量として設定する。リソース管理部100は、所定の周期例えば、1分で各ハイパーバイザ30から各仮想マシン40の構成情報を取得し、仮想マシン構成テーブル210を更新する。図6は、リソース管理部100が管理するサービス一覧テーブル220の一例を示す図である。サービス一覧テーブル220は、サービス42の識別子を格納するサービス221から一つのエントリが設定される。サービス一覧テーブル220は、管理クライアント6から管理者が設定した情報を格納する。図7は、テンプレート管理部110が管理するテンプレート一覧テーブル230の一例を示す図である。テンプレート一覧テーブル230は、テンプレートの識別子を格納するテンプレート231と、テンプレートに定義されたサービス42の識別子を格納するサービス232と、当該サービス42を実行する仮想マシン40に必要なプロセッサ20の割り当て量を格納するCPU割当量233と、当該サービス42を実行する仮想マシン40に必要なメモリ22の割り当て量を格納するメモリ割当量234とから一つのエントリが設定される。テンプレート一覧テーブル230は、管理クライアント6から管理者が設定した情報を格納する。図8は、予約管理部120が管理する予約テーブル240の一例を示す図である。予約テーブル240は、予約情報として、予約したサービスを割り当てる仮想マシン40の識別子を格納する仮想マシン241と、予約したサービスの識別子を格納するサービス242と、当該サービスを実行する仮想マシン40を割り当てる物理サーバ2の識別子を格納する割り当て先243と、当該仮想マシン40に割り当てるプロセッサ20の割当量を格納するCPU割当量244と、当該仮想マシン40に割り当てるメモリ22の割当量を格納するメモリ割当量245と、当該サービスを開始する日時を予約する開始日時246と、当該サービスを終了する日時を予約する終了日時247とから一つのエントリが設定される。予約テーブル240は、管理クライアント6から要求された予約情報を、予約管理部120で後述のように調整した値を格納する。図9は、リソース監視部130が管理するサービス組み合わせテーブル270の一例を示す図である。サービス組み合わせテーブル270は、リソース不足等の障害が発生したときの履歴情報として、ハイパーバイザ30から受信した警報の内容に識別子を加えた情報を格納する事象271と、物理サーバ2で実行しているサービス42の識別子を格納するサービス272、273、274と、事象271の発生時点で利用が予約されていないプロセッサ20の割当量を格納する未予約CPU性能275と、事象271の発生時点で利用が予約されていないメモリ22の割当量を格納する未予約メモリ容量276と、事象271が発生した物理サーバ2の識別子を格納する物理サーバ277と、事象271が発生した日時を格納する日時278とから一つのエントリが設定される。リソース監視部130は、ハイパーバイザ30から警報を受信すると、当該警報を送信したハイパーバイザ30から物理サーバ2と仮想マシン40のリソースの情報を取得して、サービス組み合わせテーブル270に新たなエントリを追加する。なお、物理サーバ2で実行しているサービス42の数を3つとしてサービス272~274のフィールドにサービスの識別子を格納する例を示したが、一つの物理サーバ2で実行されるサービス42の数に応じて適宜フィールドの数を設定すればよい。また、サービス組み合わせテーブル270は、事象271が発生したときに物理サーバ2の余剰リソース量を格納するフィールドを設けてもよく、例えば、未割当のCPU性能と未割当のメモリ容量を格納するフィールドを設けた場合には、事象271が発生した時点でリソース不足がCPUとメモリのどちらで発生したのかを記録することができる。なお、未予約のリソース量CPU性能またはメモリ容量は、物理サーバ2のリソースのうち予約テーブル240で指定されていないリソース量を示す。例えば、未予約メモリ容量276は、日時278の時点で予約テーブル240で設定されたメモリ容量246の総和を、物理サーバ277のメモリ容量203から差し引いた値であり、利用が予約されていないメモリ容量である。一方、未割当のリソース量は、物理サーバ2でハイパーバイザ30が割り当て可能なリソースのうち、仮想マシン40に割り当てられていないリソース量を示す。例えば、未割当のメモリ容量は、ハイパーバイザ30が割り当てることのできるメモリ容量203から実際に使用しているメモリ容量を差し引いたメモリ容量である。図10は、予約管理部120が管理する物理サーバ1の区間リスト250の一例を示す図である。区間リスト250は、区間の識別子を格納する区間251と、区間の開始日時を格納する開始日時252と、区間の終了日時を格納する終了日時253から一つのエントリが設定される。区間リスト250は、予約管理部120がサービスの予約の要求を受け付けたときに、当該サービスの予約期間と重複する他のサービスの予約期間を比較するために予約管理部120が物理サーバ2毎に設定する。メモリ22には、物理サーバ2-1~2-3の区間リスト250がそれぞれ設定される。図11、図12、図13は、予約管理部120が管理する割当判定テーブル280の一例を示す図である。割当判定テーブル280は、予約管理部120によって物理サーバ2毎に生成される。図11は、物理サーバ2-1物理サーバ1の割当判定テーブル280-1を示し、図12は、物理サーバ2-2物理サーバ2の割当判定テーブル280-2を示し、図13は、物理サーバ2-3物理サーバ3の割当判定テーブル280-3を示し、割当判定テーブル280-1~280-3の総称を割当判定テーブル280とする。割当判定テーブル280は、区間の識別子を格納する区間281と、区間の開始日時を格納する開始日時282と、区間の終了日時を格納する終了日時283と、仮想マシン40へのプロセッサ20の割当量を格納するCPU割当量284と、仮想マシン40へのメモリ22の割当量を格納するメモリ割当量285と、仮想マシン40の割り当ての可否を格納する割当可否286とからひとつのエントリが構成される。図14、図15は、予約管理部120が管理する評価結果テーブル260の一例を示す図である。評価結果テーブル260は、予約管理部120によって物理サーバ2毎に生成される。図14は、物理サーバ2-1物理サーバ1の評価結果テーブル260-1を示し、図15は、物理サーバ2-3物理サーバ3の評価結果テーブル260-3を示し、評価結果テーブル260-1、260-3の総称を評価結果テーブル260とする。評価結果テーブル260は、区間の識別子を格納する区間261と、予約を要求されたサービスの識別子を格納する予約要求サービス262と、予約されたサービスの識別子を格納するサービス264、266と、予約されたサービス264、266を実行する仮想マシン40の識別子を格納する仮想マシン263,265と、当該区間で予約されていないプロセッサ20のリソース量を格納する未予約CPU性能267と、当該区間で予約されていないメモリ22のリソース量を格納する未予約メモリ容量268と、予約管理部120で求めた評価値269からひとつのエントリが構成される。なお、評価値の演算については後述する。図16は、予約管理部120が管理する割当先評価値テーブル290の一例を示す図である。割当先評価値テーブル290は、予約管理部120によって生成される。割当先評価値テーブル290は、予約するサービスを割り当てる物理サーバ2の識別子を格納する割当先291と、予約管理部120が求めた物理サーバ2毎の評価値292からからひとつのエントリが構成される。なお、評価値の演算については後述する。<概要>図17は、本発明の処理の概要を示す図である。図17は、物理サーバ2-1以下、物理サーバ1でリソース不足が発生し、その後、管理クライアント6からサービス5の予約要求があったときの処理を示す。管理サーバ1は、物理サーバ1のハイパーバイザ30からリソース不足などの警報を受信するとS1、物理サーバ1からリソースの情報と、実行しているサービスの組み合わせを取得し、警報の発生時点の履歴情報としてサービス組み合わせテーブル270に新たなエントリを追加するS2。図示の例では、物理サーバ1でサービス1、サービス2、サービス5が実行されていたときにリソース不足が発生した例を示している。管理サーバ1は、ハイパーバイザ30が警報を通知したときのサービスの組み合わせサービス1、サービス2、サービス5とリソースの予約量をリソース不足の履歴情報としてサービス組み合わせテーブル270に蓄積していく。ここで、動的割当変更部300を備えたハイパーバイザ30でリソース不足が発生する例について説明する。図17において、物理サーバ1で仮想マシン1がサービス1を実行し、仮想マシン2がサービス2を実行し、仮想マシン3がサービス5を実行している。各サービス1の実行開始当初は、ハイパーバイザ30が物理サーバ1のリソースを、予約テーブル240で予約された割当量CPU割当量244、メモリ割当量245で割り当てる。ハイパーバイザ30がメモリ22を割り当てる例では、仮想マシン1に1GB、仮想マシン2に1GB、仮想マシン3に2GBを割り当てたとする。物理サーバ構成テーブル200より物理サーバ1のメモリ容量203は6GBであるので、この時点での未割当かつ未予約のメモリ容量は、6-112=2GBとなる。次に、サービス5の負荷が増大する。サービス5を実行する仮想マシン3の負荷も増大するため、ハイパーバイザ30の動的割当変更部300は、仮想マシン3に未割当のメモリを割り当てる。動的割当変更部300は、仮想マシン3に未割当の2GBのメモリ22を追加して割り当てたとする。この時点での未割当のメモリ容量は、6-114=0GBとなる。次に、サービス2の負荷が増大する。サービス2を実行する仮想マシン2の負荷も増大するため、ハイパーバイザ30の動的割当変更部300は、仮想マシン2に未割当のメモリを割り当てようとする。しかし、現時点で物理サーバ1には未割当のメモリはないので、ハイパーバイザ30はリソース不足となり、警報を出力することになる。この例では、サービス2とサービス5を同一の物理サーバで実行した結果、リソース不足になった例であり、サービス1とサービス2の組み合わせ、またはサービス1とサービス5の組み合わせを同一の物理サーバで実行してもリソース不足は発生しないことを意味する。そこで、本発明の管理サーバ1は、ハイパーバイザ30が警報を出力したときのサービスの組み合わせをサービス組み合わせテーブル270に蓄積しておく。そして、管理サーバ1は、物理サーバ2にサービス42を割り当てる予約を生成する際に、同一の物理サーバで実行するサービスの組み合わせが、サービス組み合わせテーブル270に一致した場合は、新たに予約するサービスを他の物理サーバへ変更することで、将来、リソース不足が発生するのを防止するものである。管理サーバ1は、管理クライアント6からサービス3の予約要求予約要求情報310を受け付けるS3。管理サーバ1の予約管理部120は、サービス3の実行の際に要求されるリソース量や、各物理サーバ2の物理資源の状況を予約テーブル240から取得し、物理サーバ2の仮想マシンVM5にサービス5を割り当てることを検討する。予約管理部120は、物理サーバ2にサービス5を予約した場合のサービスの組み合わせをサービス組み合わせテーブル270から検索する。予約管理部120は、サービス1、サービス2、サービス5の組み合わせで、物理サーバ1がリソース不足となった履歴を検出するS4。予約管理部120は、サービス5の割り当て先として物理サーバ2を除外し、新たな割り当て先として、物理サーバ3を選択して新たなサービス5を仮想マシン7に予約するS5。つまり、予約の時点では、物理サーバ2のリソースは十分であってサービス1、サービス2、サービス5を同時に実行するのに支障がないと、予約管理部120は判定できる。しかし、過去のリソース不足の履歴からサービス1、サービス2、サービス5を同時に実行したときに物理サーバ1でリソース不足が発生したことを予約管理部120はサービス組み合わせテーブル270から検知する。リソース不足の発生履歴を検知すると、予約管理部120は、サービス5を物理サーバ2へ割り当てるのを中止して、新たに空きリソースのある他の物理サーバ3を選択し、この物理サーバ3に新たなサービス5を予約する。本発明によれば、管理サーバ1は、過去にリソース不足となったサービスの組み合わせをサービス組み合わせテーブル270に蓄積しているので、新たにサービスを予約する場合、リソース不足とならない組合せを抽出することができ、物理サーバに配置するサービスの予約を適切な組み合わせで実現することができる。また、管理サーバ1は、サービス組み合わせテーブル270に、リソース不足となったサービス仮想マシン40の各々のリソース割り当て量も記録しているので、より正確にリソース不足とならない組合せを抽出して、予約することが可能となる。<処理の詳細>以下、管理サーバ1で行われる処理の詳細について説明する。図18は、管理サーバ1のリソース監視部130で行われる処理の一例を示すフローチャートである。この処理は、物理サーバ2のハイパーバイザ30から警報を受信したときに実行されるリソース不足情報の取得処理である。ステップS101では、リソース監視部130は、警報を通知したハイパーバイザ30に対して稼動中の全ての仮想マシン40の一覧例えば、識別子の一覧などを取得する。そして、ステップS102では、リソース監視部130が、上記一覧を取得した全ての仮想マシン40のそれぞれについて、ステップS103の処理を順次実行する。ステップS103では、リソース監視部130は、仮想マシン40毎に実行しているサービス42と、使用しているリソースの量とをハイパーバイザ30から取得する。リソース不足が発生したハイパーバイザ30から全ての仮想マシン40の情報の取得が完了すると、リソース監視部130はサービス組み合わせテーブル270に新たなエントリを加えるS104。例えば、図9で示すように、サービス組み合わせテーブル270へリソース不足3を事象271に加える場合、リソース監視部130は、リソース不足3が発生した時点で実行していたサービスの組み合わせサービス1、サービス4と、物理サーバ2の識別子物理サーバ3と日時を、サービス組み合わせテーブル270の各サービス273、274、物理サーバ277及び日時278に加える。そして、リソース監視部130は、日時278に格納したリソース不足が発生した時点のリソースの予約量を予約テーブル240から集計し、当該日時でのCPU割当量244とメモリ割当量245で予約したリソース量の合計を求める。つまり、リソース監視部130は、日時278において物理サーバ3で実行していた仮想マシン40に割り当てる予定のリソース量の合計値を、CPUの予約量とメモリの予約量としてそれぞれ求めるS103。そして、リソース監視部130は、物理サーバ構成テーブル200からリソース不足3が発生した物理サーバ3の構成情報として、CPU性能202とメモリ容量203を取得する。なお、CPU性能202は、プロセッサのコア数に動作周波数定格周波数を乗じた値を用いる。次に、リソース監視部130は、物理サーバ3のCPU性能202から上記ステップS103で取得した物理サーバ3上の仮想マシン40のプロセッサの予約量の合計値を差し引いた値を、未予約CPU性能として求め、未予約CPU性能275に格納する。また、リソース監視部130は、物理サーバ3のメモリ容量203から、上記ステップS103で取得した物理サーバ3上の仮想マシン40のメモリの予約量の合計値を差し引いた値を、未予約メモリ容易として求め、未予約メモリ容量276に格納する。以上の処理により、リソース監視部130は、リソース不足等の障害が発生した履歴をサービス組み合わせテーブル270に追加して、ハイパーバイザ30から警報を受けた時点の、サービスの組み合わせと、リソースの予約量を蓄積する。図19は、管理サーバ1のテンプレート管理部110で行われる処理の一例を示すフローチャートである。この処理は、管理クライアント6からテンプレートの登録要求があったときにテンプレート管理部110で実行される。まず、ステップS111では、管理サーバ1のテンプレート管理部110が管理クライアント6からテンプレートに設定するサービスの識別子を受け付ける。管理クライアント6では、入力装置63から追加するテンプレートに含めるサービスの識別子を受け付けて、管理サーバ1に送信する。ステップ112では、テンプレート管理部110は、図6に示したサービス一覧テーブル220を検索して、受け付けた識別子と同一の識別子が存在するか否かを判定する。サービス一覧テーブル220に、受け付けた識別子と同一の識別子が存在しなければ、ステップS113へ進む一方、受け付けた識別子と同一の識別子がサービス一覧テーブル220に既に登録されている場合にはステップS114へ進む。ステップS113では、テンプレート管理部110は未登録のサービスを受け付けたので、受け付けたサービスの識別子をサービス一覧テーブル220に登録する。ステップS114では、テンプレート管理部110が、サービス一覧テーブル220を管理クライアント6へ送信し、サービスの一覧からテンプレートに加えるサービスを管理クライアント6で選択させる。このとき、テンプレート管理部110は、選択されたサービスを仮想マシン40で実行する際のCPU割当量223とメモリ割当量234を管理クライアント6から受け付ける。なお、管理クライアント6から、テンプレートのCPU割当量223とメモリ割当量234を指定しない場合は、テンプレート管理部110は、予め設定されたCPU割当量223とメモリ割当量234の初期値例えば、1GHz、1GBを、追加するテンプレートに適用するリソース量として設定する。ステップS115では、テンプレート管理部110が管理クライアント6で選択したサービスと、当該サービスを実行する仮想マシン40に割り当てるリソース量の組み合わせを、新たにテンプレート一覧テーブル230へ加える。このとき、テンプレート管理部110は、新たな識別子を追加するテンプレートに設定する。図7の例では、テンプレート管理部110が、サービス6のテンプレートを登録する例を示す。新たなサービス6をテンプレートに登録する場合、テンプレート管理部110はサービス一覧テーブル220を検索し、既登録の値が存在しないので新たなサービス6をサービス一覧テーブル220に追加する。そして、テンプレート管理部110は、管理クライアント6からサービス6を仮想マシン40で実行する際のリソース量をCPU割当量223とメモリ割当量234として受け付ける。テンプレート管理部110は、当該受け付けたサービスの識別子とリソース量の組み合わせにテンプレートの識別子を付与し、テンプレート一覧テーブル230に新たなエントリとして追加する。なお、テンプレート一覧テーブル230は、ひとつのサービスについて複数のテンプレートが存在することを許容し、これら複数のテンプレートは、ひとつのサービスに対して複数のリソース量の組み合わせを設定できる。次に、管理サーバ1が管理クライアント6から受け付けた予約の処理について説明する。予約の要求は、例えば、図20で示すような予約要求情報を含む。図20の予約要求情報310は、予約するサービスの識別子を格納するサービス311と、当該サービスを実行する仮想マシン40に割り当てるプロセッサ20の割当量を格納するCPU割当量312と、当該サービスを実行する仮想マシン40に割り当てるメモリ22の割当量を格納するメモリ割当量313と、当該サービスを開始する日時314と、当該サービスを終了する日時315から構成される。すなわち、予約要求情報310は、図7に示したテンプレート一覧テーブル230の情報に開始日時314と終了日時315を付加して生成することができる。このため、予約要求情報310の受付は、図21に示すテンプレート選択画面2130を用いることができる。図21は、予約の受け付け時に管理サーバ1が管理クライアント6へ提供するテンプレート選択画面の一例を示す画面イメージである。管理サーバ1は、管理クライアント6から所定の予約要求を受け付けると、図21のテンプレート選択画面2300を管理クライアント6へ出力する。テンプレート選択画面2300は、サービスの開始日時を入力する開始日時入力領域2301と、サービスの終了日時を入力する終了日時入力領域2302と、テンプレート一覧テーブル230を表示して管理者などに所望のサービスを選択させる選択領域2303と、予約の実行を指令する予約ボタン2304とから構成される。管理クライアント6を利用する管理者は、入力装置63及び出力装置64を使用して、開始日時入力領域2301にサービスの開始日時を入力し、サービスの終了日時を終了日時入力領域2302へ入力し、選択領域2303では所望のテンプレートのチェックボックス2310を選択する。そして、管理クライアント6を利用する管理者がテンプレート選択画面2300の予約ボタン2304を操作すると、管理サーバ1の予約管理部120で処理が開始される。予約管理部120は、予約ボタン2304が操作されると、開始日時入力領域2301の値を予約要求情報310の開始日時314へ格納し、終了日時入力領域2302の値を予約要求情報310の終了日時315へ格納し、チェックボックス2310で選択されたテンプレート一覧テーブル230のサービスの識別子232とCPU割当量233とメモリ割当量234を、それぞれ予約要求情報310のサービス311、CPU割当量312、メモリ割当量313へ格納する。なお、これらの処理は管理クライアント6で実行し、予約要求情報310を管理サーバ1へ送るようにしてもよい。図22は、管理サーバ1の予約管理部120で行われる予約処理の一例を示すフローチャートである。この処理は、管理クライアント6から予約要求情報を受け付けたとき、あるいは、上記図21の予約ボタン2304が操作されたときに実行される。ステップS121では、予約管理部120が、管理クライアント6から予約要求情報を取得する。ステップS122では、予約管理部120は、取得した予約要求情報310から要求されたサービス311を実行する仮想マシン40に割り当てるリソース量を満たす物理サーバ2を割り当て先として検索する。なお、割り当て先の物理サーバ2を検索する処理割当先検索処理については、後述する。ステップS123では、予約管理部120はステップS122で検索した割り当て先の物理サーバ2の有無を判定する。予約管理部120は割り当て先の物理サーバ2が存在する場合にはステップS214の処理へ進み、割り当て先の物理サーバ2が存在しなければステップS128へ進む。ステップS124では、予約管理部120はステップS122で検索した全ての割当先候補の物理サーバ2についてステップS125の割当先候補の評価を実施する。ステップS125では、予約管理部120が割当先候補となる物理サーバ2毎に評価値を後述するように演算する。ステップS126では、予約管理部120はステップS125で求めた評価値のうち最も小さい評価値の物理サーバ2を、予約を割り当てる物理サーバ2として選択する。ここでは、予約管理部120が割当先評価値テーブル290の評価値292が最も小さい物理サーバ2の識別子291を選択する。ステップS127では、予約管理部120はステップS126で選択した物理サーバ2で、受け付けた予約要求情報310を実行する予約を予約テーブル240に追加してから予約処理を終了する。一方、ステップS123の判定で、予約の割当先候補となる物理サーバ2がひとつも存在しない場合には、ステップS128へ進む。ステップS128では、予約管理部120は、管理クライアント6に対して予約が不能であることを警告し、予約要求情報310を再入力またはリソース量の再考を示唆するメッセージを出力する。次に、図23は、上記図22のステップS122で行われる割当先候補の検索処理の一例を示すフローチャートである。ステップS130では、予約管理部120がステップS131~S137の処理を、管理サーバ1の管理対象となる全ての物理サーバ2について、物理サーバ2毎に順次繰り返して実行する。ステップS130では、予約管理部120が物理サーバ構成テーブル200から未選択の物理サーバ2を一つ選択する。ステップS131では、予約管理部120は、上記ステップS121で取得した予約要求情報310の開始日時314と終了日時315と日時が重複する予約を予約テーブル240から検索する。この検索は、ステップS130で選択した物理サーバ2の予約情報について実施する。予約管理部120は、選択した物理サーバ2の予約情報について、予約テーブル240の開始日時246が、予約要求情報310の終了日時315以前で、かつ、予約テーブル240の終了日時247が、予約要求情報310の開始日時314以降の予約情報を重複する予約情報として取得する。ステップS132では、物理サーバ構成テーブル200からステップS130で選択した物理サーバ2のリソース量としてCPU性能202とメモリ容量203を取得する。ステップS133では、予約要求情報310の開始日時314~終了日時315までの予約要求区間を、上記ステップS131で取得した重複する予約情報から複数の区間に分割し、各区間のリストを図10で示す区間リスト250として後述するように取得する。この区間リスト250は、予約要求区間の始点開始日時314から終点終了日時315までの間で、始点から終点に向けて、既に予約済みの仮想マシン40サービスが開始または終了する時点毎に区間を設定して区間のリストを生成する処理である。なお、本実施形態では、ひとつの仮想マシン40上でひとつのサービスを実行する例について説明する。ステップS134では、上記ステップS133で取得した区間リスト250の全ての区間についてステップS135、S136の処理を、区間毎に順次繰り返す。ステップS135では、予約管理部120は、区間リスト250から未選択の区間を一つ選択し、当該区間内で予約テーブル240に予約された物理サーバ2のリソースの予約量と予約要求情報310のリソース量の合計を演算する。本実施形態の例では、リソース量として、CPU性能とメモリ容量を用いるので、選択した区間内でのCPU性能の予約量の合計と、メモリ容量の予約量の合計をそれぞれ予約管理部120が演算する。つまり、予約管理部120は、リソースの種類毎にリソースの予約量の合計を選択した区間内でそれぞれ求めればよい。次に、ステップS136では、現在選択した物理サーバ2のリソース量が、ステップS135で求めた予約量の合計より少ないか否かを判定する。つまり、既に予約されたリソースの予約量に、予約要求情報310のリソース量を加えた値が、物理サーバ2のリソース量を超えていれば割当先として不適であるので、除外する。本実施形態の例では、予約管理部120は、現在の区間内で、物理サーバ2のCPU性能202が予約量の合計未満または物理サーバ2のメモリ容量203が予約量の合計未満であれば割当先として不適切と判定する。一方、予約管理部120は、現在の区間内で、物理サーバ2のCPU性能202が予約量の合計以上かつ、物理サーバ2のメモリ容量203が予約量の合計以上であれば割当先として適切と判定する。予約管理部120が割当先として不適切と判定した場合には、現在選択している物理サーバ2では、予約を要求したサービスを予約要求区間で係属して処理できないので割当先候補から除外し、ステップS130に戻って次の未処理の物理サーバ2について上記処理を繰り返す。そして、ステップS134~S136の処理を繰り返して全ての予約要求区間で、現在選択している物理サーバ2のリソース量が予約要求情報310を満たしていれば、予約管理部120はステップS137で当該物理サーバ2の識別子を割当先候補に設定する。上記処理を全ての物理サーバ2について繰り返して実行することで、全ての予約要求区間で、リソース量が予約要求情報310を満たす物理サーバ2の一覧が割当先候補に設定される。なお、図24で示すように、割当先候補320は、物理サーバ2の識別子を格納するテーブルとしてもよいし、あるいは変数としてもよく、メモリ22上に格納される。割当先候補320は、物理サーバ2のうち予約要求情報310のリソース量を満たす物理サーバの一覧を保持する。図25は、予約要求区間と予約テーブル240で予約済みの区間予約済み区間が重複する物理サーバ2の識別子が1の予約状況を示す。上記図23の処理の結果、予約管理部120は、物理サーバ2毎に予約テーブル240の予約済み区間と予約要求区間が重複する仮想マシン40を取得することができる。図26は、図23の割当先候補検索処理のステップS133で行われる区間リスト250の取得処理の一例を示すフローチャートである。予約管理部120は、図22のステップS121で取得した予約要求情報310の開始日時314を、区間開始日時に設定する。予約管理部120は、ステップS141~S147の処理を区間開始日時が予約要求情報310の終了日時315予約終了日時に到達するまでの間繰り返す。ステップS142では、予約管理部120は予約テーブル240を検索し、区間開始日時以降で、現在選択している物理サーバ2の予約情報で最も早い近い予約開始日時246を取得する。そして、取得した予約開始日時246を変数:日時Aに設定する。ステップS143では、予約管理部120は予約テーブル240を検索し、区間開始日時以降で、現在選択している物理サーバ2の予約情報で最も早い近い予約終了日時247を取得する。そして、取得した予約終了日時247を変数:日時Bに設定する。ステップS144では、予約管理部120は、日時Aと日時Bが共に存在しないことを判定する。日時Aと日時Bが共に存在しない値がない場合には、ステップS148へ進んで予約管理部120はステップS141~S147のループを終了する。ステップS148では、予約管理部120は、区間終了日時に予約要求情報310の終了日時315を設定する。次に、ステップS149では予約管理部120が、ステップS140で設定した区間開始日時と、ステップS148の区間終了日時に、区間の識別子を加えて、現在の物理サーバ2の区間リスト250に追加する。一方、ステップS144の判定で、日時Aまたは日時Bの少なくとも一方が存在する場合には、予約要求区間が複数の予約済み区間と重複するためステップS145へ進む。ステップS145では、区間終了日時を次式により設定する。区間終了日時=MIN日時A、日時B、予約要求終了日時.........1ただし、MINは日時A、日時B、予約要求終了日時のうち最も小さい値を選択する関数である。ステップS146では、予約管理部120は、ステップS140で設定した区間開始日時と、ステップS145で求めた区間終了日時に、区間の識別子を加えて、現在の物理サーバ2の区間リスト250に追加する。ステップS147では、予約管理部120は、区間開始日時に現在の区間終了日時を設定して、次の区間を求めるためステップS142の処理に戻る。上記処理により、予約要求情報310で要求された開始日時314と終了日時315の予約要求区間は、物理サーバ2毎に一つまたは複数の期間に分割された区間リスト250が生成される。区間リスト250は、予約テーブル240で予約済み区間と重複し、かつ、予約済み区間が開始または終了する日時で予約要求区間を分割したリストとなる。図27は、各物理サーバ2毎の予約要求区間の区間リストである。図10で示すように、予約要求情報310の予約要求区間は、物理サーバ1では予約済み区間によって、区間1~区間3の3つの区間に分割される。つまり、図26の処理では、区間リストの開始日時を、図27に示す予約要求区間の開始日時に設定してから、予約要求区間内で予約済みの開始日時及び終了日時を探索する。図27において、物理サーバ1の予約済みの区間で、予約要求区間と重複するサービスは、仮想マシン1のサービス1と、仮想マシン2のサービス2である。仮想マシン2のサービス1の開始日時がサービス2終了日時よりも始点に近いため、予約要求区間は、始点からサービス2の開始日時までの区間が区間1となる。次に、サービス2の開始日時からサービス1の終了日時までが区間2となり、サービス1の終了日時から予約要求区間の終了日時までが区間3となる。一方、物理サーバ3では、予約要求区間内で仮想マシン4のサービス1の開始と終了がないため、予約要求区間がひとつの区間1となる。このように、区間リスト250は、物理サーバ2毎の予約済みの状況に応じて予約要求区間の区間が異なる。予約管理部120は、上記区間リスト250に加えて、図11、図12、図13に示す割当判定テーブル280-1~280-3を生成することができる。なお、図12の物理サーバ2の割当判定テーブル280-2では、区間2で割当可否286が不可となっているので、区間2以降の区間についてはエントリを作成しなくてもよい。すなわち、予約要求情報310のサービスを、ひとつの物理サーバ2で継続して処理することを目的とするため、割当可否286が不可の区間を含む物理サーバ2は、割当先候補320から除外する。図28は、図22のステップS125で行われる割当先候補の評価処理の一例を示すフローチャートである。この処理は、図22の処理で、割当先候補の一覧割当先候補320と区間リスト250を取得した後に実行される。ステップS150では、予約管理部120が区間リスト250を取得する。そして、予約管理部120は、区間リスト250の全ての区間毎にステップS151~S157の処理を繰り返す。ステップS151では、予約管理部120が区間リスト250から未選択の区間をひとつ選択する。このとき、当該区間の物理サーバ2の識別子も取得する。ステップS152では、予約管理部120が現在選択した区間の開始日時252と終了日時253から物理サーバ2の識別子で予約テーブル240を検索し、当該区間で予約済みのサービスの組み合わせを取得する。そして、予約管理部120は、取得した予約済みのサービスの組み合わせに、予約要求情報310のサービス311を加えた検索用のサービスの組み合わせを生成する。ステップS153では、予約管理部120はステップS152で生成した検索用のサービスの組み合わせを含む組み合わせを、サービス組み合わせテーブル270から検索する。ステップS154では、予約管理部120は、サービス組み合わせテーブル270に検索用のサービスの組み合わせを含むエントリがあるか否かを判定する。予約管理部120は、検索用のサービスの組み合わせを含むエントリがなければ、ステップS160で現在の区間の評価値を0としてからステップS151に戻って次の区間について上記処理を繰り返す。一方、予約管理部120は、検索用のサービスの組み合わせを含むエントリがサービス組み合わせテーブル270に存在する場合、ステップS155に進む。このとき、予約管理部120は、検索用のサービスの組み合わせ=予約を要求された新たなサービスと、既に予約済みのサービスの組み合わせでは、過去にリソース不足などの異常があった履歴を検知する。予約管理部120は、予約を要求されたサービス予約要求情報310と既に予約済みのサービスの組み合わせが、過去に不具合物理計算機の異常発生を招いたことがある警告を管理クライアント6に出力してもよい。つまり、サービスの割り当て当初は、物理サーバ2のリソース量を超えることはないが、既に予約されたサービスと受け付けたサービスを同時に稼動させていくと、いずれ物理サーバ2のリソース量が不足する可能性が高いサービスの組み合わせであることを管理サーバ1は管理クライアント6に警告することができる。すなわち、本実施形態では、現在選択中の区間で予約済みのサービスに、予約を要求されたサービス5を加えた組み合わせ検索用のサービスの組み合わせを、現在選択中の物理サーバ21で実行した場合に、過去にリソース不足となった履歴があった場合、検索用のサービスの組み合わせを含む履歴について評価を行う。ステップS155では、予約管理部120はサービス組み合わせテーブル270からステップS153の条件を満たすリソース不足の履歴から未選択のエントリをひとつ選択する。そして、ステップS156では、予約管理部120は、サービス組み合わせテーブル270から選択したリソース不足の履歴について、日付と曜日または時期から評価値を演算する。予約管理部120は、図25に示す評価値テーブル330に基づいて、選択したリソース不足のエントリの曜日と日付または時期に基づく評価値を演算する。図29は、評価値テーブル330の一例を示す。評価値テーブル330は、評価値の変数を示す評価値331と、評価する項目を示す評価項目332と、評価値を付与する内容を格納する評価基準333とからひとつのエントリが構成される。変数Aは、評価項目332が曜日の評価基準333で採点した値を設定する。評価項目332が曜日の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ週及び曜日を含む場合は、変数A=2点とする。評価項目332が曜日の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ曜日のみを含む場合は、変数A=1点とする。評価項目332が曜日の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ曜日を含まない場合は、変数A=0点とする。変数Bは、評価項目332が日付の評価基準333で採点した値を設定する。評価項目332が日付の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ月日を含む場合は、変数B=2点とする。評価項目332が曜日の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ日のみを含む場合は、変数B=1点とする。評価項目332が曜日の評価基準333は、現在選択している区間が、現在選択したリソース不足の履歴の発生日時278と同じ日を含まない場合は、変数B=0点とする。変数Cは、評価項目332が期末の評価基準333で採点した値を設定する。評価項目332が期末の評価基準333は、現在選択したリソース不足の履歴の発生日時278が期末で、現在選択した区間が期末の場合は、変数C=4点とする。評価項目332が曜日の評価基準333は、現在選択したリソース不足の履歴の発生日時278が月末で、現在選択した区間が期末の場合は、変数C=2点とする。評価項目332が曜日の評価基準333は、現在選択したリソース不足の履歴の発生日時278が月末ではなく、また現在選択した区間が月末ではない場合は、変数C=0点とする。予約管理部120は、現在選択した区間とリソース不足の履歴の日付278から評価値テーブル330を用いて変数A、B,Cをそれぞれ求める。そして、予約管理部120は、次式により、評価値=1ABC.........2として評価値を求める。次に、ステップS157では、現在選択した区間に対応する物理サーバ2が有するリソース量に基づいて上記評価値を補正する。予約管理部120は、現在選択した区間に対応する物理サーバ2のリソース量を物理サーバ構成テーブル200から取得して以下の変数R1、R2を求める。R1=履歴の未予約CPU性能/物理サーバの未予約CPU性能.........3履歴の未予約CPU性能は、サービス組み合わせテーブル270の未予約CPU性能275であり、物理サーバの未予約CPU性能は、図14、図15の評価結果テーブル260の未予約CPU性能267である。なお、CPU性能は、上述したようにクロック数×コア数で表される。R2=履歴の未予約メモリ容量/物理サーバの未予約メモリ容量.........4履歴の未予約メモリ容量は、サービス組み合わせテーブル270の未予約メモリ容量276であり、物理サーバの未予約メモリ容量は、図14、図15の評価結果テーブル260の未予約メモリ容量268である。なお、CPU性能は、上述したようにクロック数×コア数で表される。また、予約管理部120は、上記2式で求めた日付と曜日に基づく評価値を変数Eに設定する。E=1ABC.........5予約管理部120は、上記変数R1、R2、Eから評価値を、評価値=E×maxR1,R2.........6として更新する。ただし、maxR1,R2は、R1とR2の値のうち、大きい値を選択する関数である。例えば、図20の予約要求情報310のサービス5を物理サーバ1に予約する場合、図27において、区間2ではサービス2にサービス5の組み合わせは、図9のサービス組み合わせテーブル270のリソース不足2に該当するので、評価値を求める。まず、予約管理部120は上記ステップS156で日付と曜日及び期末に関する評価値を評価値テーブル330で求める。ここで、物理サーバ1の区間2とサービス組み合わせテーブル270のリソース不足2の値から日付と曜日及び期末に関する評価値は図26で示すように各変数A~Cが求められる。なお、図30は、評価値3031が図29の評価値テーブル330の評価値331の変数に対応し、評価項目3032が図29の評価値テーブル330の評価項目332に対応し、履歴3033はリソース不足2の月日に関する情報を示し、区間3034は区間2の月日に関する情報を示す。この結果、上記5式は、E=1100=2となり、上記3式は、R1=2/{2×4-221}=2/3となり、上記4式は、R2=1/{6-211}=1/2となる。この結果、上記6式より、評価値=2×max2/3,1/2=4/3≒1.33となる。ステップS157では、上記評価値を現在選択した区間の評価結果テーブル260に格納する。そして、現在選択した区間のサービスの組み合わせに一致する全てのリソース不足の履歴について上記処理が完了すると、予約管理部120は、ステップS158の処理を行う。ステップS158では、予約管理部120が上記ステップS157で求めた区間の評価値の合計を現在選択した区間の評価値として演算する。上記の例では、物理サーバ1の区間1の評価値が0、区間2の評価値が約1.33、区間3の評価値が1.6となる。予約管理部120は、各区間毎に評価値を評価結果テーブル260に格納する。上記ステップS151~S158の処理が全ての区間について完了すると、ステップS159の処理へ進む。ステップS159では、予約管理部120は、物理サーバ2毎に上記各区間の評価値のうち最大の評価値を、当該物理サーバ2の評価値として割当先評価値テーブル290に設定する。例えば、割当先候補320の物理サーバ2の識別子が物理サーバ1、物理サーバ3の場合、図14、図15より、物理サーバ1の評価値=1.6、物理サーバ3の評価値=0が、それぞれ評価値292に格納される。上記図28の処理が終了すると、上述した図22のステップS126に進み、予約管理部120は、割当先評価値テーブル290の評価値292が最も小さい物理サーバ2の識別子291を予約要求情報310の割り当て先として選択し、予約テーブル240に登録する。以上のように、本実施形態によれば、管理サーバ1は、過去にリソース不足等の異常が発生したサービスの組み合わせと物理サーバ2とをサービス組み合わせテーブル270に記憶しているので、新たにサービスを追加予約する場合、リソース不足等の異常が発生する可能性のある組み合わせを回避できる。これにより、物理サーバ2上で実行される複数の仮想マシンでそれぞれサービスを提供する仮想計算機システムにおいて、管理サーバ1が適切に仮想マシン及びサービスを物理サーバ2上に配置し、最適な予約を実現することができる。すなわち、予約したサービスの組み合わせの実行を開始した時点ではリソース不足が発生しないが、稼動期間の経過によってサービスの負荷が増大した場合、仮想化部ハイパーバイザ30が当該サービスを実行する仮想マシン40へのリソースの割り当てを増やす場合がある。物理サーバ2上の複数のサービスでリソース量の割り当てを増やしていくと仮想化部はリソースを割り当て不能になる場合がある。そこで、管理サーバ1は過去の異常発生の履歴に基づいて、長期的に見て物理サーバ2のリソース量が不足するなどの異常が発生するサービスの組み合わせを警告または回避することができる。また、管理サーバ1は、リソース不足等の異常が発生したときのサービスの各々のリソースの予約量も把握しているので、より正確にリソース不足とならない組合せを抽出して予約テーブル240に予約することができる。さらに、サービス組み合わせテーブル270は、各サービスの処理特性としてリソース不足となった曜日や時間帯などの時期も記憶しているので、管理サーバ1は、サービスを新たに予約する時間帯や曜日を含む時期も考慮してリソース不足とならない組み合わせを抽出して予約することができる。つまり、サービスの種類によっては、週末や特定の日にちあるいは、月末または期末など、特定の時期になると負荷が増大して使用するリソース量が増大し、この結果、ハイパーバイザ30がリソース不足となる場合がある。このため、予約する時点では、予約するサービスのリソース量と、予約済みのサービスのリソース量が、仮想マシン40を実行する物理サーバ2のリソース量以内であっても、上記所定の時期になると、リソース不足になるサービスの組み合わせを予測することができる。また、管理サーバ1は、過去にリソース不足等の異常が発生したサービスの組み合わせと物理サーバ2とをサービス組み合わせテーブル270に記憶しているので、新たにサービスを追加予約する場合、リソース不足となる組み合わせを管理クライアント6に通知することができる。これにより、管理クライアント6を利用する管理者などに、不適なサービスの組み合わせを通知することができる。さらに、本実施形態の管理サーバ1は、サービスとリソースの要求量を予めセットしたテンプレートをテンプレートテーブル230に格納しておき、サービスの予約時にテンプレートを選択し、予約の開始と終了の日時を入力すればよいので、リソースの要求量を検討することなく予約を行うことができる。これにより、リソースの要求量を予約の度に設定する必要がなくなり、管理者やユーザなどの予約に関する労力を大幅に低減することが可能となる。なお、上記実施形態では、ハイパーバイザ30によって仮想マシン40を稼動させる例を示したが、物理サーバ2の資源を仮想マシン40に割り当てる仮想化部としては、VMMVirtualMachineMonitorを用いてもよい。また、上記実施形態では、リソース監視部130が、ハイパーバイザ30からリソース不足の通知を受信したときにサービス組み合わせテーブル270にサービスの組み合わせやリソースの状態を記録したが、サービス組み合わせテーブル270に格納する情報はリソース不足に限定されるものではない。例えば、仮想マシン40がハイパーバイザ30へ異常の発生を通知したときや、ハイパーバイザ30が仮想マシン40の停止を検知したときに、管理サーバ1へ通知する。管理サーバ1は、ハイパーバイザ30からの異常の発生の通知を受信し、異常の種類に応じて事象271を適宜設定してサービス組み合わせテーブル270にエントリを追加すればよい。なお、上記実施形態では、管理サーバ1が物理計算機で構成された一例を示したが、管理サーバ1が仮想マシン40で提供されてもよい。この場合、仮想マシン40のひとつが管理部として機能し、サービスの予約と計算器資源を管理する。なお、上記実施形態では、管理サーバ1がリソース不足などの異常の発生要因となるサービスの組み合わせを検知し、サービス組み合わせテーブル270に蓄積している例を示したが、図2のリソース監視部130を削除して、予め設定されたサービス組み合わせテーブル270を使用してもよい。この場合、サービス組み合わせテーブル270には、物理サーバ2のリソース不足などの異常が発生する可能性のあるサービスの組み合わせと、異常が発生する可能性のある時期とを予め記録しておけばよい。"