JP5262724B2 - プロビジョニングシステム、方法、及び、プログラム - Google Patents

Description

本発明はプロビジョニングシステム、方法、及び、プログラムに関し、更に詳しくは、サーバ上で動作するアプリケーションシステムの切替えを行うプロビジョニングシステム、方法、及び、プログラムに関する。

限られた計算機を利用して複数のアプリケーションシステムを運用するデータセンタや企業内情報システムにおいて、サーバのプロビジョニングによる資源の有効活用が進められている。サーバのプロビジョニングとは、複数のアプリケーションシステムで共用されたプールサーバを、特定のアプリケーションサーバ向けに構成変更する処理である。構成変更処理は、ＯＳの入れ替え、アプリケーションのセットアップ、ネットワーク機器やストレージ装置の設定変更処理を含む。

プロビジョニング機能は、ソフトウェア製品として販売提供されているが、実際に利用する際には、プロビジョニングにかかる処理時間が問題となる。例えば大規模で複雑なシステムで利用する場合には、ＯＳの入れ替え処理やネットワークの構成変更処理に、数十分以上の時間がかかることがある。このため、システムの規模が大きく、複雑になるほど、突発的な負荷変動や障害発生に対応して迅速にサーバのプロビジョニングを行うことは難しくなる。

特許文献１には、典型的な負荷分散のためのプロビジョニングシステムの例が記載されている。特許文献１に記載されたシステムは、負荷分散装置（ＬＢ）によって、クライアント計算機からＷｅｂサーバへの要求を負荷分散するシステムであり、負荷状況に応じて負荷分散対象のＷｅｂサーバを増減し、稼動するサーバの台数を最適化する。このシステムは、Ｗｅｂサーバによる単純なシステムを前提としているため、プロビジョニングは、ＯＳのアプリケーションのブート処理だけで済む。

一方、多くのＷｅｂアプリケーションシステムは、アプリケーションサーバ（ＡＰサーバ）やデータベースサーバ（ＤＢサーバ）、アプリケーションサーバやネットワークを管理するための管理サーバなど、複数のサーバシステムから構成されている。従って、ＡＰサーバをプロビジョニングする場合には、ＯＳとアプリケーションのブート処理だけでなく、ＤＢサーバへの接続設定や管理サーバへの登録、アプリケーションの更新適用、ネットワークの構成変更処理などが必要となる。このため、特許文献１で示される手法をＷｅｂアプリケーションシステムに適用する場合、ＯＳとアプリケーションのブート処理以外の処理にかかるオーバヘッドを無視できない。

また、特許文献１で示される手法は、ＯＳとアプリケーションイメージとをストレージエリアネットワーク（ＳＡＮ）に格納して共有する構成を前提としている。このようなシステム構成は、現時点で一般的とは言えず、既存のシステムに適用する場合には、システムそのものを再構築する必要がある。例えば、ＳＡＮを統合したブレードシステムを新たに導入するということが考えられるが、それは、稼働中のシステムを有効活用する目的にはそぐわない。

特許文献２には、計算機の設定にかかる時間を短縮化する手法として、共有された計算機上で、ＯＳやアプリケーションを駆動してスタンバイ状態を作成する方法が示されている。特許文献２では、特定のアプリケーションシステムとしてスタンバイ（ホットスタンバイ）するのではなく、別のアプリケーションシステムにも設定可能な中間状態でスタンバイしており、このようにすることで、複数のアプリケーションシステムへの計算機設定時間を平均的に短縮化できる。

特許文献２で示される手法は、特定のアプリケーションシステムとして利用されていないプールサーバのプロビジョニングを高速化できる。しかしながら、アプリケーションシステムの一部として利用されているプールサーバを、別のアプリケーションシステムに切り替えるためのプロビジョニング処理を高速化することはできない。

一方、分散したサーバを、一つのサーバに統合し、コストや管理の手間を削減する目的で、サーバの仮想化技術が導入される事例が近年見られる。様々な仮想化技術の中でも、非特許文献１に示されるような仮想マシンモニタを用いた仮想化方式は、仮想化環境で動作するＯＳ環境の性能低下が小さく、既存サーバ上で複数のＯＳを動作させても十分な性能が発揮できる。更に、仮想マシンモニタで生成された仮想マシンは、ＣＰＵやメモリなどの計算機資源をＯＳ稼働中に動的に変更することができ、ハードウェアのパーティショニングに比べても利便性が高い。資源の有効活用のために、仮想マシンモニタによる動的な資源割当て変更機能を応用することができると考えられる。
特開２００５−１１３３１号公報 特願２００６−１９４０９号 B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt,A. Warfield, P. Barham and R. Neugebauer, Xen and the Art of Virtualization, 19th ACM Symposium on Operating Systems Principles (SOSP19), 2003.

従来のプロビジョニングシステムでは、以下の問題点がある。第１の問題点は、ネットワークの構成や複数サーバの構成に依存したシステムにおいて、突発的な負荷変動や障害発生に対応して、迅速にサーバのプロビジョニングを行うことが難しい点である。その理由は、プロビジョニング処理は、ネットワークの構成変更や管理サーバへの登録処理、アプリケーションの更新適用処理などを含んでおり、これらの処理に時間がかかるためである。

第２の問題点は、既存のシステムを有効活用して、突発的な負荷変動や障害発生に対応して迅速にサーバをプロビジョニングすることができない点である。その理由は、ＳＡＮを構成要素として持たないシステムでは、ＯＳのディスクイメージを共有して高速にブートを行う構成が取れず、ＯＳの入れ替えやアプリケーションシステムのセットアップに時間がかかるからである。

第３の問題点は、稼働中のアプリケーションシステムを別のアプリケーションシステムとしてプロビジョニングする際に、高速に切替えを行うことができない点である。その理由は、従来は、稼働中のアプリケーションを停止した後に、新たにプロビジョニングを一から開始する必要があり、スタンバイ状態を用いたプロビジョニング高速化の手法が適用できないためである。

本発明は、上記従来技術の問題点を解消し、ネットワークの構成や複数のサーバ構成に依存したシステムにおいて、突発的な負荷変動や障害発生に対応して、迅速にサーバのプロビジョニングを行うことができるプロビジョニングシステム、方法、及び、プログラムを提供することを目的とする。

本発明の別の目的は、既存システムを有効活用して、迅速にサーバのプロビジョニングを行うことができるプロビジョニングシステム、方法、及び、プログラムを提供することである。

本発明の別の目的は、稼働中のアプリケーションシステムを、別のアプリケーションシステムとして、高速に切り替えることができるプロビジョニングシステム、方法、及び、プログラムを提供することである。

上記目的を達成するために、本発明のプロビジョニングシステムは、複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニングシステムであって、前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、アプリケーションシステムを稼動させるためのアクティブ仮想マシンが構成された共用サーバ上に、前記アクティブ仮想マシンに割り当てられた資源量よりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築手段と、プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行手段とを備え、前記スタンバイ構築手段は、前記サーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、前記プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とする。

本発明のプロビジョニング方法は、コンピュータを用い、複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニング方法であって、前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、前記コンピュータが、アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築ステップと、プロビジョニング要求が発生した場合、前記コンピュータが、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行ステップとを有し、前記スタンバイ構築ステップでは、前記コンピュータは、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、前記プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とする。

本発明のプログラムは、コンピュータに、複数のサーバで２つ以上のアプリケーションシステムを動作させ、前記複数のサーバが複数の仮想マシンを構成可能な共有サーバを少なくとも１台含むシステムで、サーバのプロビジョニングを行う処理を実行させるプログラムであって、前記コンピュータに、アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築処理と、プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行処理とを実行させ、前記スタンバイ構築処理では、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいて前記プロビジョニング要求の発生の有無を予測し、プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とする。

本発明のプロビジョニングシステム、方法、及び、プログラムでは、実際にプロビジョニングを行う前の段階で、共有サーバ上に起動したスタンバイ仮想マシンでプロビジョニングを事前に行い、プロビジョニングが要求された際には、アクティブ仮想マシンに割り当てる資源量と、スタンバイ仮想マシンに割り当てる資源量とを変更してスタンバイ仮想マシンに十分な資源量を割り当て、スタンバイ仮想マシンをアプリケーションシステムの稼動に用いることでプロビジョニングを行う。実際にプロビジョニングを行う前の段階で、共有サーバ上に起動したスタンバイ仮想マシンを用いて事前にプロビジョニングの準備を行い、ＯＳ及びアプリケーションの起動や、ネットワーク構成変更、別のサーバへの登録設定処理などを、スタンバイ仮想マシン上で事前に実行することにより、サーバのプロビジョニングを高速に行うことができ、突発的な負荷変動や障害発生に対応して、迅速にサーバのプロビジョニングを行うことができる。また、共有サーバにスタンバイ仮想サーバを構成することでプロビジョニングを高速化できるので、ＳＡＮなどを用意する必要がなく、既存システムを有効活用して、迅速にサーバのプロビジョニングを行うことができる。更に、事前に行うプロビジョニングの時点でスタンバイ仮想マシンに割り当てる資源量を必要最小限の資源量とし、アクティブ仮想マシンに十分な資源量を割り当てておき、プロビジョニングに際して、スタンバイ仮想マシンに十分な資源量を割り当て、アクティブ仮想マシンに割り当てる資源量を必要最小限の資源量とすることで、アプリケーションシステムを高速に切り替えることができる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、前記サーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシンを起動させる構成を採用できる。将来的なプロビジョニング要求の発生を予測し、そのプロビジョニングに備えて、共有サーバ上でスタンバイ仮想マシンを起動し、そのスタンバイ仮想マシンにて事前にプロビジョニングを行っておく。この場合、実際にプロビジョニング要求が発生したとき、プロビジョニング対象のアプリケーションシステムと、スタンバイ仮想マシンにて事前に行っておいたアプリケーションシステムとが一致するときには、事前にプロビジョニングを行っておいたスタンバイ仮想マシンを用いてプロビジョニングを完了させることで、プロビジョニング要求発生時点からプロビジョニングを開始する場合に比して、プロビジョニングを高速化できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する構成を採用できる。例えば、プロビジョニングをサーバの負荷状態が高くなったときに行うとするとき、実際にサーバの負荷状態が高くなる前に、サーバの負荷状態から、サーバの負荷状態が高くなる兆候をつかむことができると考えられる。このような兆候を、例えば過去のプロビジョニング要求の発生状況と、サーバの負荷状態との対応関係からつかみ、これに基づいてプロビジョニング要求の発生を予測することで、将来的なプロビジョニングの発生を予測できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する構成を使用できる。プロビジョニング要求発生の確率は、例えば、ロジスティック解析分析を用いて算出できる。各アプリケーションシステムについて、所定時間後にプロビジョニング要求が発生する確率を計算し、何れかのアプリケーションシステムについて、プロビジョニング要求が発生する確率が所定のしきい値以上となるときには、将来的にプロビジョニング要求が発生すると予測してスタンバイ仮想マシンを起動し、スタンバイ仮想マシンを用いて将来的に発生するであろうプロビジョニングに備えることで、実際にプロビジョニング要求が発生したときのプロビジョニングに要する時間を短縮できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する構成を採用できる。一のアプリケーションシステムから他のアプリケーションシステムへの切替えに要する時間を、各アプリケーションシステムについてあらかじめ見積もり、状態遷移コストグラフを作成しておく。この状態遷移コストグラフと、各アプリケーションシステムについてのプロビジョニング要求発生確率とに基づき、各アプリケーションシステムをスタンバイ仮想マシンを用いて行う事前プロビジョニングのプロビジョニング対象と想定したときのプロビジョニング時間の期待値を算出する。この期待値が最小となるアプリケーションシステムを、事前プロビジョニングのプロビジョニング対象とすることで、プロビジョニング要求が発生したときのプロビジョニング時間を、確率的に最小化できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びプリケーションの起動を実行させる構成を採用できる。また、前記スタンバイ構築手段は、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる構成を採用できる。スタンバイ仮想マシン上で、プロビジョニング要求が発生する前に事前に行うプロビジョニングでは、スタンバイ仮想マシンを他のサーバと共にアプリケーションシステムを稼動させる前の状態までの処理、すなわち、ＯＳの起動やアプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定までの処理を行っておく。これらの処理を事前に行っておくことで、プロビジョニング要求が発生した際には、スタンバイ仮想マシンの負荷分散装置への登録やスタンバイ仮想マシンに対する十分な資源量の割当てを行うことでプロビジョニングを完了でき、プロビジョニングを高速化できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる構成を採用できる。この場合、ディスクイメージを用いてＯＳ及びアプリケーションを起動することで、それらの起動に要する時間を短縮化できる。

本発明のプロビジョニングシステムでは、前記スタンバイ構築手段は、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる構成を採用できる。プロビジョニングを、あらかじめ定められたスケジュールに従って行う場合には、プロビジョニングがスケジュールされた時刻よりも所定の時間だけ前の時点で、スタンバイ仮想マシンを起動して事前にプロビジョニングを行い、スケジュールされたプロビジョニング要求の発生に備えることで、プロビジョニングを高速化できる。

本発明のプロビジョニングシステムでは、前記プロビジョニング実行手段は、前記２つ以上のアプリケーションシステムのうちの何れかに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う構成を採用できる。この場合、例えば、同一アプリケーションシステムを構成するサーバの平均負荷が所定のしきい値を超えたときにプロビジョニングを行うことで、サーバ負荷を下げることができ、アプリケーションシステムのサービス品質低下を避けることができる。

本発明のプロビジョニングシステムでは、前記プロビジョニング実行手段は、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う構成を採用できる。プロビジョニングを行う前は、アクティブ仮想マシンに対してアプリケーションの稼動に十分な資源量を割り当てる一方、スタンバイ仮想マシンには、必要最小限の資源を割り当てておく。プロビジョニングを行う際には、アクティブ仮想マシンに割り当てる資源量を必要最小限の資源量に変更し、スタンバイ仮想マシンに対してアプリケーションの稼動に十分な資源量を割り当てる。このようにすることで、見かけ上、アクティブ仮想マシンとスタンバイ仮想マシンとが入れ替わり、割当て資源量の変更により、スタンバイ仮想マシンによるアプリケーションの稼動が可能となる。

本発明のプロビジョニングシステムでは、前記プロビジョニング実行手段は、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築手段によって前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。プロビジョニングを行う際に、プロビジョニング対象のアプリケーションシステムが、スタンバイ構築手段によってスタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムと一致するときには、スタンバイ仮想マシンに十分な資源量を割り当てることで、見かけ上、アクティブ仮想マシンとスタンバイ仮想マシンとの入替えを行い、負荷分散装置への登録等を行ってスタンバイ仮想マシンによるアプリケーションシステムの運用を開始させることで、プロビジョニングを初めから行う場合に比して、プロビジョニングを高速化できる。

本発明のプロビジョニングシステムでは、前記プロビジョニング実行手段は、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築手段によって前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。プロビジョニング対象のアプリケーションシステムと、スタンバイ構築手段によってスタンバイ仮想マシン上で事前に行ったプロビジョニングのアプリケーションシステムとが一致しないときには、スタンバイ仮想マシン上で改めてＯＳ及びアプリケーションを起動し、スタンバイ仮想マシン上でその他必要な処理を行った後に、アクティブ仮想マシンの割当て資源量とスタンバイ仮想マシンの割当て資源量とを変更し、見かけ上、アクティブ仮想マシンとスタンバイ仮想マシンとを入れ替えて、スタンバイ仮想マシンによるアプリケーションの運用を開始させればよい。

本発明のプロビジョニングシステムでは、前記プロビジョニング実行手段は、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。この場合、負荷分散装置に、負荷分散対象のサーバとしてスタンバイ仮想マシンを登録することで、スタンバイ仮想マシンに対して、ユーザからの要求などが届くようになり、スタンバイ仮想マシンが、アプリケーションシステムの一部として運用されることになる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシンを起動させる構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びプリケーションの起動を実行させる構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる構成を採用できる。

本発明のプロビジョニング方法は、前記スタンバイ構築ステップでは、前記コンピュータは、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる構成を採用できる。

本発明のプロビジョニング方法は、前記プロビジョニング実行ステップでは、前記コンピュータは、前記アプリケーションシステムに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う構成を採用できる。

本発明のプロビジョニング方法は、前記プロビジョニング実行ステップでは、前記コンピュータは、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う構成を採用できる。

本発明のプロビジョニング方法は、前記プロビジョニング実行ステップでは、前記コンピュータは、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプロビジョニング方法は、前記プロビジョニング実行ステップでは、前記コンピュータは、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプロビジョニング方法は、前記プロビジョニング実行ステップでは、前記コンピュータは、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシンを起動させる構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びプリケーションの起動を実行させる構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる構成を採用できる。

本発明のプログラムは、前記スタンバイ構築処理では、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる構成を採用できる。

本発明のプログラムは、前記プロビジョニング実行処理では、前記アプリケーションシステムに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う構成を採用できる。

本発明のプログラムは、前記プロビジョニング実行処理では、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う構成を採用できる。

本発明のプログラムは、前記プロビジョニング実行処理では、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプログラムは、前記プロビジョニング実行処理では、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプログラムは、前記プロビジョニング実行処理では、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる構成を採用できる。

本発明のプロビジョニングシステム、方法、及び、プログラムでは、実際にプロビジョニングを行う前の段階で、共有サーバ上に起動したスタンバイ仮想マシンでプロビジョニングを事前に行い、プロビジョニングが要求された際には、アクティブ仮想マシンに割り当てる資源量と、スタンバイ仮想マシンに割り当てる資源量とを変更してスタンバイ仮想マシンに十分な資源量を割り当て、スタンバイ仮想マシンをアプリケーションシステムの稼動に用いることでプロビジョニングを行う。実際にプロビジョニングを行う前の段階で、共有サーバ上に起動したスタンバイ仮想マシンを用いて事前にプロビジョニングの準備を行い、ＯＳ及びアプリケーションの起動や、ネットワーク構成変更、別のサーバへの登録設定処理などを、スタンバイ仮想マシン上で事前に実行することで、サーバのプロビジョニングを高速に行うことができ、突発的な負荷変動や障害発生に対応して、迅速にサーバのプロビジョニングを行うことができる。これにより、データセンタや企業内情報システムで動作するアプリケーションシステムのサービスレベル（応答性能、可用性）を維持できる。また、共有サーバにスタンバイ仮想サーバを構成することでプロビジョニングを高速化できるので、ＳＡＮなどを用意する必要がなく、既存のサーバ資源を有効活用して、迅速にサーバのプロビジョニングを行うことができ、システム全体のコストを削減することができる。

以下、図面を参照し、本発明の実施の形態を詳細に説明する。図１は、本発明の第１実施形態のプロビジョニングシステムの構成を示している。プロビジョニングシステム１０は、負荷分散装置１１、管理サーバ２０、アプリケーションシステムの実行に用いる複数のサーバ機（サーバ１〜サーバ６）３１〜３６、及び、共有サーバ（サーバ７）４０を有する。サーバ機３１〜３６は、二つ以上のアプリケーションシステムを運用する。図１の例では、サーバ機３１及び３２は、ＡＰ１のアプリケーションシステムを運用し、サーバ機３３及び３４は、ＡＰ２のアプリケーションシステムを運用する。また、サーバ機３５及び３６は、ＡＰ３のアプリケーションを運用する。

共有サーバ４０は、仮想マシンモニタ４３を有する。仮想マシンモニタ４３は、共有サーバ４０上に、仮想マシン（アクティブ仮想マシン４１及びスタンバイ仮想マシン４２）を構成する。仮想マシンモニタ４３は、共有サーバ４０上で動作するソフトウェアであり、仮想マシンの構築／解体や、仮想マシンに対する資源の割当てなどを行う。アクティブ仮想マシン４１は、アプリケーションシステムの一部として運用され、仮想マシンモニタ４３により、アプリケーション稼動に十分な資源（ＣＰＵ、メモリ、Ｉ／Ｏ帯域）が割り当てられる。図１の例では、アクティブ仮想マシン４１は、サーバ機３５及び３６と共に、ＡＰ３のアプリケーションシステムを運用する。スタンバイ仮想マシン４２は、プロビジョニング要求が発生する可能性が高いアプリケーションシステムを事前に用意するための環境として利用され、仮想マシンモニタ４３により、アクティブ仮想マシン４１に割り当てられた資源量よりも少ない必要最小限の資源が割り当てられる。

負荷分散装置１１は、各アプリケーションシステムに対するクライアントからの要求を負荷分散する。管理サーバ２０は、情報監視部２１、スタンバイ構築決定部２２、プロビジョニング決定部２３、及び、制御実行部２４を有し、アプリケーションシステムの負荷変動や障害に応じてシステムの構成変更を管理する。情報監視部２１は、システム全体の構成や性能、障害を監視する。制御実行部２４は、共有サーバ４０に対する制御、及び、負荷分散装置１１や図示しないネットワーク機器に対する制御を実行する。スタンバイ構築決定部２２は、プロビジョニング要求の発生を予測し、制御実行部２４を介して、共有サーバ４０上にスタンバイ仮想マシン４２を構成し、スタンバイ仮想マシン４２上でプロビジョニングを実行させる。

スタンバイ構築決定部２２は、負荷変動や過去の統計データから、各アプリケーションシステムに対するプロビジョニング要求を予測する。より詳細には、スタンバイ構築決定部２２は、例えば、負荷変動や過去の統計データから、アプリケーションシステムごとに、５分後にプロビジョニング要求が発生する確率を計算する。計算した確率が所定のしきい値を超えるときには、将来的に発生するであろうプロビジョニング要求に備えて、スタンバイ仮想マシン４２上でプロビジョニングを実行させる。

プロビジョニング決定部２３は、現在のシステム内の負荷状態に基づいて、プロビジョニング要求を発生するか否かを決定し、制御実行部２４を介して、共有サーバ４０にプロビジョニングを実行させる。プロビジョニング決定部２３は、例えばアプリケーションの平均利用率が８０％を超えたことを検出すると、プロビジョニング要求を発生し、サーバ追加を決定する。スタンバイ仮想マシン４２にて事前にプロビジョニングが行われていないとき、又は、プロビジョニングの対象が、事前にプロビジョニングが行われたアプリケーションシステムとは異なるアプリケーションシステムであるときには、スタンバイ仮想マシン４２にて、初めからプロビジョニングを行う。

図２は、スタンバイ構築決定部２２が、スタンバイ仮想マシン４２に対して事前にプロビジョニングを行う際の動作手順を示している。スタンバイ構築決定部２２は、情報監視部２１に、現在のシステムの状態、例えば各アプリケーションシステムにおけるサーバのＣＰＵ平均利用率やディスクＩ／Ｏの平均値、ネットワークＩ／Ｏの平均値などを取得する（ステップＳ１０００）。スタンバイ構築決定部２２は、取得したシステム状態と、過去の統計データと照らし合わせ、アプリケーションシステムに対するプロビジョニング要求が発生するか否かを予測する（ステップＳ１００１）。より詳細には、ステップＳ１００１では、過去の統計データから得られた所定の算出式と、現在のシステム状態とから、各アプリケーションシステムについて、プロビジョニング要求が発生する確率を求める。

スタンバイ構築決定部２２は、ステップＳ１００１での予測結果から、プロビジョニング要求が発生する可能性が高いか否かを判断する（ステップＳ１００２）。ステップＳ１００２では、例えば、何れかのアプリケーションシステムについて、プロビジョニング要求が発生する確率が所定のしきい値以上のときに、プロビジョニング要求が発生する可能性が高いと判断する。スタンバイ構築決定部２２は、プロビジョニング要求が発生する確率が低いと判断したときには、所定の時間だけ待機し（ステップＳ１００５）、その後にステップＳ１０００に戻り、再度システム状態の確認を行う。

スタンバイ構築決定部２２は、プロビジョニング要求が発生する確率が高いと判断すると、プロビジョニングのためのスタンバイ状態を決定する（ステップＳ１００３）。このスタンバイ状態の決定には、特許文献２に記載される手法が利用できる。詳細については、実施例で説明する。その後、スタンバイ構築決定部２２は、ステップＳ１００３で決定したスタンバイ状態に基づいて、実際にプロビジョニングを行う条件が成立する前の段階で、制御実行部２４を介して、共有サーバ４０内にスタンバイ仮想マシン４２を構築し、構築したスタンバイ仮想マシン４２上でプロビジョニングの一部を実行させる（ステップＳ１００４）。

ステップＳ１００４では、スタンバイ仮想マシン４２内のＯＳの入替えやアプリケーションのセットアップ、ネットワーク機器の設定変更などを行う。ただし、スタンバイ仮想マシン４２に割り当てられた資源量は必要最小限のものであり、スタンバイ仮想マシン４２は、クライアントからの要求を受け付けてサービスを提供できるだけの能力は有していない。このため、スタンバイ仮想マシン４２は、スタンバイ状態で待機するのみであり、実際のアプリケーションシステムの運用には利用されない。

図３は、プロビジョニング決定部２３によるプロビジョニング決定の動作手順を示している。このプロビジョニング決定の動作は、図２に示すスタンバイ仮想マシン４２に対する事前プロビジョニングの動作とは独立に行われる。プロビジョニング決定部２３は、情報監視部２１から、現在のシステム状態を取得する（ステップＳ２０００）。状態確認後、プロビジョニング決定部２３は、あらかじめプログラムされた、或いは、ルール化された制御に基づいて、プロビジョニングを行うか否かを判断する（ステップＳ２００１）。例えば、プロビジョニング決定部２３は、何れかのアプリケーションシステムの平均のＣＰＵ利用率が所定のしきい値を超えたことを検出すると、プロビジョニングを行うと決定する。プロビジョニングを行わないと判断したときには、所定時間だけ待機し（ステップＳ２００６）、その後、ステップＳ２０００に戻って再度システム状態の確認を行う。

プロビジョニング決定部２３は、プロビジョニングを行うと決定したときには、システムの構成情報、及び、プロビジョニングするサーバの構成に基づいて、プロビジョニングをどのような手順で実行するかを示すプロビジョニングプランを生成する（ステップＳ２００２）。プロビジョニングプランの生成では、システム構成情報を参照して、例えば使用するＯＳやアプリケーションを特定し、ＯＳの入れ替えやアプリケーションのセットアップの手順を生成する。また、ＶＬＡＮを用いてネットワークを分けるシステム構成となっているときには、プロビジョニングプランに、ＶＬＡＮの設定変更を行う手順を追加する。

プロビジョニング決定部２３は、プロビジョニングが必要であることを、アラートを通して管理者に伝える。（ステップＳ２００３）。プロビジョニング決定部２３は、プロビジョニングプランに対して管理者の承諾が得られたか否かを判断し（ステップＳ２００４）、承諾が得られたときには、制御実行部２４に対して、プロビジョニングを実行させる（ステップＳ２００５）。承諾がなかったときには、プロビジョニングは行わない。この
管理者による承諾は、省略することもできる。

図４は、プロビジョニング実行の際の動作手順を示している。制御実行部２４は、まず、スタンバイ仮想マシン４２の状態を確認する（ステップＳ３０００）。ステップＳ３０００では、図２のステップＳ１００４で構築されたスタンバイ仮想マシン４２におけるアプリケーションシステムと、プロビジョニング実行対象のアプリケーションシステムとが一致しているか否かを判断する（ステップＳ３００１）。一致していた場合には、制御実行部２４は、仮想マシンモニタ４３を制御し、ステップＳ２００２（図３）で生成したプロビジョニングプランに従って、アクティブ仮想マシン４１に割り当てられている資源量とスタンバイ仮想マシン４２に割り当てられている資源量とを変更する（ステップＳ３００８）。

ステップＳ３００８の割当資源量の変更では、アクティブ仮想マシン４１の資源量を削減し、スタンバイ仮想マシン４２に十分な資源量を割り当てる。このようにすることで、見かけ上、アクティブ仮想マシン４１とスタンバイ仮想マシン４２とが入れ替わる。スタンバイ仮想マシン４２に対して十分な資源量が割り当てられることで、スタンバイ仮想マシン４２上でスタンバイ状態であったアプリケーションシステムは、サービス開始可能な状態となる。スタンバイ仮想マシン４２に対して十分な資源量が割り当てられた後、負荷分散装置１１に、スタンバイ仮想マシン４２を負荷分散対象のサーバとして登録することで、スタンバイ仮想マシン４２は、クライアントからの要求受付を開始する（ステップＳ３００９）。スタンバイ仮想マシン４２がアプリケーションシステムの一部として運用されることで、プロビジョニングが完了する。

一方、スタンバイ仮想マシン４２におけるアプリケーションシステムと、プロビジョニング実行対象のアプリケーションシステムとが一致しないと判断したときには、ステップＳ２００２（図３）で生成したプロビジョニングプランに従って、通常のプロビジョニング処理を行う。すなわち、スタンバイ仮想マシン４２上で既に起動しているアプリケーションがあるか否かを調べ（ステップＳ３００２）、起動しているアプリケーションがあるときには、そのアプリケーションを停止する（ステップＳ３００３）。その後、ＯＳを入れ替え（ステップＳ３００４）、アプリケーションのセットアップを行い（ステップＳ３００５）、ネットワーク機器の設定変更をしてネットワーク構成を変更し（ステップＳ３００６）、管理サーバ２０への登録を行う（ステップＳ３００７）。更に、ステップＳ３００８で、スタンバイ仮想マシン４２に割り当てられる資源量を変更し、ステップＳ３００９で負荷分散装置１１への登録を行う。

共有サーバ４０におけるアプリケーションシステムの状態遷移の様子を、図５を参照して説明する。初め、アクティブ仮想マシン４１では、ＡＰ３のアプリケーションシステムが稼動しており、スタンバイ仮想マシン４２は停止状態にある（図５（ａ））。この状態で、ＡＰ１のアプリケーションシステムの負荷が上昇傾向にあると、図２に示す手順で、ＡＰ１に対してプロビジョニング要求が発生すると予測され、スタンバイ仮想マシン４２上でＡＰ１のアプリケーションシステムが構築される（図５（ｂ））。ただし、この状態では、スタンバイ仮想マシン４２はクライアントからの要求を受け付けないので、プロビジョニングは完了していない。

ＡＰ１のアプリケーションシステムの負荷が増加し、予測どおりにＡＰ１に対するプロビジョニング要求が発生すると（図３のステップＳ２００１）、プロビジョニングの実行では、図４のステップＳ３００１からステップＳ３００８に進み、アクティブ仮想マシン４１の割当て資源量が削減され、スタンバイ仮想マシン４２に十分な資源が割り当てられることで、スタンバイ仮想マシン４２が、アプリケーションシステムの運用が可能なアクティブ状態となり、アクティブ仮想マシン４１はスタンバイ状態となる。つまり、見かけ上、アクティブ仮想マシン４１とスタンバイ仮想マシン４２とが入れ替わる（図５（ｃ））。その後、負荷分散装置１１にＡＰ１のアプリケーションが動作するスタンバイ仮想マシン４２が負荷分散対象として登録されることで、アクティブ状態となったスタンバイ仮想マシン４２がクライアントから利用可能となり、プロビジョニングが完了する。

本実施形態では、共有サーバ４０に、仮想マシンモニタ４３を用いてアクティブ仮想マシン４１とスタンバイ仮想マシン４２とを構成する。管理サーバ２０は、プロビジョニングが予測されるときには、スタンバイ仮想マシン４２上で、事前にプロビジョニングの一部を実行しておき、実際にプロビジョニングが必要となったときには、スタンバイ仮想マシン４２に対する資源割当量を変更し、スタンバイ仮想マシンをアプリケーションシステムの運用に用いることで、プロビジョニングを行う。このようにプロビジョニングの一部を、共有サーバ４０上でアプリケーションシステムの運用を行うアクティブ仮想マシン４１とは別個に構成したスタンバイ仮想マシン４２上で事前に実行しておくことで、プロビジョニングを高速化できる。

本実施形態では、事前にスタンバイ仮想マシン４２にてプロビジョニングの一部を行っておくことで、プロビジョニングを迅速に行うことができるため、突発的な負荷変動や障害の発生時に、迅速にサーバのプロビジョニングを実行し、負荷の低減や障害サーバの代替を行うことができる。これにより、データセンタや企業内情報システムの可用性を向上させることができる。また、プロビジョニングにより、データセンタや企業内情報システムで動作するアプリケーションシステムのサービスレベル（応答性能、可用性）を維持できる。

本実施形態では、既存サーバ機に、仮想マシンモニタ４３をインストールし、サーバ上で複数の仮想マシンを構成可能とすることで、迅速なプロビジョニングを実現できる。このため、システム全体を作り変えることなくプロビジョニングを高速化することができる。また、本実施形態では、アプリケーションシステムの一部として稼働中のサーバ上で、スタンバイ状態を構築でき、スタンバイ用のサーバ機を新たに用意する必要はない。したがって、既存のサーバ資源を有効活用することができ、システム全体のコストを削減することができる。

以下、具体的な実施例を用いて本実施形態のプロビジョニングシステムの動作について説明する。図６に、本実施例のプロビジョニングシステムの構成を示す。このプロビジョニングシステムは、企業内データセンタにおけるプロビジョニングシステムとして構成されており、負荷分散装置１００、ＶＬＡＮスイッチ１０１、ファイヤウォール１０２、管理／監視サーバ１０３、サーバ機（サーバ１〜サーバ６）１１１〜１１６、及び、データベースサーバ１３１〜１３３で構成されている。サーバ機１１１〜１１５は、アプリケーションシステムに利用されるサーバ機（図１におけるサーバ機３１〜３６）に相当し、サーバ機１１６は、仮想マシンモニタ１２０により仮想マシンを構成可能なサーバ機（共有サーバ４０）に相当する。

図６に示すシステムでは、販売管理、売上解析、開発評価の３つのＷｅｂアプリケーションシステムが稼動している。サーバ機１１１及び１１２は、販売管理用のサーバとして利用されており、サーバ機１１３及び１１４は、売上解析用のサーバとして利用され、サーバ機１１５は、開発評価用のサーバとして利用されている。サーバ機１１６は、プールサーバであり、通常は開発評価システムの一部として利用されているが、販売管理や売上解析の負荷急増時や障害時には、販売管理や売上解析用のサーバとして利用される。各アプリケーションが利用するデータは、同じネットワークに接続されたデータベースサーバ１３１〜１３３に格納される。

販売管理及び売上解析のアプリケーションは、負荷分散装置１００を介して、クライアントからの要求を負荷分散して処理する。また、図６では、各アプリケーションの運用管理グループが異なる場合を想定し、各アプリケーシステムを、ＶＬＡＮスイッチ１０１とファイヤウォール１０２とによってネットワーク的に隔離している。システム全体の監視及び管理は、管理／監視サーバ１０３により行う。管理／監視サーバ１０３は、図１における管理サーバ２０に相当し、スタンバイ仮想マシンの構成やプロビジョニングの決定及び実行を行う。

ここで、月末にかけて、販売管理システムの利用者数、及び、アクセス頻度が上昇し、サーバ機１１１及び１１２の処理能力では十分な応答性能が得られなくなる状況を考える。この場合、管理／監視サーバ１０３が、販売管理システムの高負荷状態を検出し、サーバ機１１６を、販売管理システムとしてプロビジョニングする決定を行う。サーバ機１１１及び１１２に、サーバ機１１６を加えた３台のサーバで負荷分散することで、販売管理システムの応答性能を維持することができる。本実施例では、プロビジョニング要求が発生する前の段階で、プロビジョニング要求の発生を予測し、プロビジョニング要求が予測されるときには、その時点で、スタンバイ仮想マシン１２２上で事前にプロビジョニングを開始しておくことにより、プロビジョニングを高速化する。

プロビジョニングの予測について説明する。プロビジョニングが、例えば、同一アプリケーションシステムを構成するサーバの平均ＣＰＵ利用率が８０％を超えたときに実行されるとした場合、ＣＰＵ平均利用率が８０％を超える前に、システム内の資源状態の変動から、何らかの兆候を見出すことができると考えられる。そこで、過去の資源状態の変動データから、プロビジョニング要求発生のパターンを抽出し、これを用いてプロビジョニングを予測する。プロビジョニング要求発生のパターンの抽出では、例えば各アプリケーションシステムに擬似的なクライアント要求を入力して、各サーバのＣＰＵ利用率、ディスクＩ／Ｏ、ネットワークＩ／Ｏ、クライアント接続数など資源状態データを適当なウインドウサイズ（例えば５秒）で取り出し、そのデータ系列が観察されてからｘ秒後（例えば１分後）におけるプロビジョニング要求発生の有無を、プロビジョニング要求発生のパターンとして抽出する。

図７に、性能特徴ベクトルと、プロビジョニング要求発生のパターンとを示す。資源状態データを適当なウィンドウサイズで取り出したデータを、性能特徴ベクトルとして定義する。図７（ａ）は、性能特徴ベクトルの一例を示しており、この例では、販売管理、売上解析、及び、開発評価のそれぞれについて、ＣＰＵ利用率の平均値とディスクＩ／Ｏの平均値とを性能特徴ベクトルのデータ（ｘ１〜ｘ６）として定義している。ここでは、平均値としたが、その他の統計値や差分をとって性能特徴ベクトルとしてもよい。

プロビジョニング要求発生のパターンの抽出では、性能特徴ベクトルの観察データと、そのデータが観察されてから所定時間後におけるプロビジョニング要求の発生の有無（プロビジョニング要求発生の場合は、その対象となるアプリケーションシステム）との組を、パターンとして抽出する（図７（ｂ））。図７（ｂ）では、例えば、販売管理におけるＣＰＵ利用率が「７０．６」、ディスクＩ／Ｏが「１５２．８」、売上解析におけるにおけるＣＰＵ利用率が「５．４」、ディスクＩ／Ｏが「８」、開発評価におけるＣＰＵ利用率が「９．４」、ディスクＩ／Ｏが「１７３．６」のデータが観察された時点から所定時間後に、販売管理のアプリケーションシステムについてプロビジョニング要求が発生したことを示している。

次に、上記抽出されたパターンデータに基づいて、プロビジョニング要求を予測するモデルを用意する。一例として、ロジスティック回帰分析を用いる方法を示す。ロジスティック回帰分析は、多数の説明変数を用いて、比率や２値変数の値を推定する際に用いられる分析手法である。プロビジョニングが要求される場合を「１」、要求されない場合を「０」とし、各アプリケーションに対してプロビジョニングが要求される確率ｑを推定する。説明変数としては、パターンデータで用いた性能特徴ベクトルｖ（図７（ａ））を用いる。

ロジスティック回帰分析の一般式は以下のように定義される。
ｖ＝（ｘ１，ｘ２，．．，ｘｎ）
ｑ（ｖ）＝ｅｘｐ（β０＋Σβｉ×ｘｉ）／（１＋ｅｘｐ（β０＋Σβｉ×ｘｉ））
ここで、β０，．．，βｎは回帰係数列であり、パターンデータ（図７（ｂ））を入力データとして、最尤法によって求めることができる。回帰係数を求めた後の販売管理システムについてのロジスティック回帰式の例を、以下に示す。
f(v)=exp(-2.6+1.04×x1+0.17×x2-6×x3+0.03×x4+0.38×x5+0.17×x6)
ｑ（ｖ）＝ｆ（ｖ）／（１＋ｆ（ｖ）） （１）
各アプリケーションシステムについて、上記と同様に、ロジスティック回帰分析で、プロビジョニングが要求される確率の算出式を導出する。また、何れのアプリケーションシステムに対してプロビジョニングが要求されない場合についても、ロジスティック回帰分析で確率の算出式を導出する。この確率算出式の導出は、プロビジョニングシステムの運用開始前に、あらかじめ行っておく。

スタンバイ構築決定部２２は、図２のステップＳ１０００で情報監視部２１から取得した現在のシステム状態に対応した性能特徴ベクトルを生成し、ステップＳ１００１で、この性能特徴ベクトルを、上記導出した確率算出式に当てはめて、各アプリケーションシステムについて、プロビジョニング要求が発生する確率を算出する。例えば、販売管理システムについてのプロビジョニング要求の発生確率が所定のしきい値、例えば０．８５を超えていたときには、ステップＳ１００２からステップＳ１００３へ進んで、プロビジョニングのためのスタンバイ状態を決定する。

スタンバイ状態の決定では、選択し得るスタンバイ状態から、各アプリケーションシステムをプロビジョニングする際にかかる処理時間を事前に測定又は予測して状態遷移コストグラフをあらかじめ作成しておき、その状態遷移コストグラフと、各アプリケーションのプロビジョニング要求の発生確率とに基づいて、スタンバイ仮想マシン１２２にてプロビジョニングするアプリケーションシステムを決定する。図８に、状態遷移コストグラフの具体例を示す。この同図では、例えば現在のアプリケーションシステムが販売管理であるときに、アプリケーションシステムを売上解析に入れ替えるためには、時間的コストが「４９」かかることを示している。

図９に、各アプリケーションシステムについて算出されたプロビジョニング要求の発生確率を示し、図１０に、期待プロビジョニング時間の算出結果を示す。ステップＳ１００１で算出された各アプリケーションシステムのプロビジョニング要求発生確率が、販売管理「０．９２」、売上解析「０．２１」、開発評価「０．０１」で、プロビジョニング要求発生なしの確率が「０．３４」であったとする（図９（ａ））。この場合、スタンバイ状態の決定では、各確率を、これら確率の総和で割り、プロビジョニング要求発生確率の比率を求める。プロビジョニング要求発生確率の比率を求めると、販売管理に対する要求比率は「０．６２」、売上解析に対する要求比率は「０．１４」、開発評価に対する要求比率は「０．００６」、プロビジョニング要求なしに対する要求比率は「０．２３」と算出される（図９（ｂ））。

プロビジョニング要求発生確率の比率を算出すると、選択可能なスタンバイ状態に対し、各アプリケーションシステムに対するプロビジョニング要求発生確率の比率と状態遷移コスト（図８）との積和をとり、期待プロビジョニング時間を算出する。例えば、スタンバイ仮想マシン１２２を販売管理でプロビジョニングした場合を想定して、販売管理の要求比率「０．６２」に販売管理から販売管理への入れ替えに要する時間コスト「０」をかけたもの、売上解析の要求比率「０．１４」に販売管理から売上解析への入れ替えに要する時間コスト「６０」をかけたもの、開発評価の要求比率「０．００６」に販売管理から開発評価への入れ替えに要する時間コスト「５０」をかけたものの総和を算出する。このような期待プロビジョニング時間の計算を、スタンバイ仮想マシン１２２に対して何れのアプリケーションシステムもプロビジョニングしない場合を含めて計算すると、図１０に示す計算結果が得られる。

スタンバイ状態の決定では、期待プロビジョニング時間の算出結果から、期待プロビジョニング時間が最も短いアプリケーションシステムを、スタンバイ状態、つまり、スタンバイ仮想マシン１２２上でプロビジョニングするアプリケーションシステムとして選択する。図１０の例では、スタンバイ状態を販売管理のアプリケーションシステムとしたときに期待プロビジョニング時間が最短となっているので、スタンバイ状態を販売管理に決定する。その後、ステップＳ１００４で、スタンバイ仮想マシン１２２を構築し、構築したスタンバイ仮想マシン１２２上で、決定した販売管理のアプリケーションシステムをプロビジョニングする。このプロビジョニングでは、ＯＳの入れ替え、販売管理のアプリケーションのセットアップ、ＶＬＡＮスイッチ１０１やファイヤウォール１０２の設定変更、管理／監視サーバ１０３への登録、データベースサーバ１３１〜１３３への登録処理などを実行する。

スタンバイ状態の構築後、図３のステップＳ２００１で、サーバ機１１１及び１１２の平均ＣＰＵ利用率が８０％を超えたことが検出されると、ステップＳ２００２に移行して、実際のプロビジョニングが開始される。ここでは、サーバ機１１６がプロビジョニングの対象となる。ステップＳ２００２のプロビジョニングプランの生成では、システム構成を確認し、サーバ機１１６を販売管理のアプリケーションシステムとしてプロビジョニングするために、ＯＳの入れ替え、ＡＰのセットアップ、ＶＬＡＮスイッチ１０１とファイヤウォール１０２の設定変更、管理／監視サーバ１０３への登録、データベースサーバ１３１〜１３３への登録処理が必要であると判断され、これらがプランニングされる。

上記プランニングされたプロビジョニングの詳細なプロビジョニング手順は、図４に示す手順に基づく。ステップＳ３０００で、スタンバイ状態の確認を行い、スタンバイ仮想マシン１２２にて、事前に販売管理のアプリケーションシステムがプロビジョニング済みであるか否かを判断する。事前にプロビジョニング済みであれば、ＯＳの入れ替え、ＡＰのセットアップ、ＶＬＡＮスイッチ１０１とファイヤウォール１０２の設定変更、管理／監視サーバ１０３への登録、データベースサーバ１３１〜１３３への登録処理は、事前に行われているので、ステップＳ３００８のアクティブ仮想マシン１２１の資源量及びスタンバイ仮想マシン１２２の資源量の変更と、ステップＳ３００９の負荷分散装置１００の設定変更のみで、プロビジョニングが完了する。

図１１は、本発明の第２実施形態のプロビジョニングシステムの構成を示している。本実施形態のプロビジョニングシステム１０ａは、第１実施形態のプロビジョニングシステム１０の構成に加えて、ＳＡＮやＮＡＳ（Network Attached Storage）を使った共有ディスク装置５０を有する。共有ディスク装置５０には、各アプリケーションシステムを構成済みのＯＳイメージが格納されている。サーバ機３１〜３６は、共有ディスク装置５０に格納された共有ディスクイメージを使ってアプリケーションシステムを起動する。本実施形態におけるスタンバイ構築決定部２２によるスタンバイ仮想マシンの構築の動作、及び、プロビジョニング決定部２３によるプロビジョニング決定の動作は、第１実施形態における動作（図２、図３）と同様である。

図１２は、プロビジョニングの実行手順を示している。制御実行部２４は、まず、スタンバイ仮想マシン４２の状態を確認する（ステップＳ５０００）。ステップＳ５０００では、図２のステップＳ１００４で構築されたスタンバイ仮想マシン４２におけるアプリケーションシステムと、プロビジョニング実行対象のアプリケーションシステムとが一致しているか否かを判断する（ステップＳ５００１）。一致していた場合には、制御実行部２４は、仮想マシンモニタ４３を制御し、アクティブ仮想マシン４１に割り当てられている資源量とスタンバイ仮想マシン４２に割り当てられている資源量とを変更する（ステップＳ５００７）。

ステップＳ５００７では、アクティブ仮想マシン４１の資源量を削減し、スタンバイ仮想マシン４２に十分な資源量を割り当てる。このようにすることで、見かけ上、アクティブ仮想マシン４１とスタンバイ仮想マシン４２とが入れ替わる。スタンバイ仮想マシン４２に対して十分な資源量が割り当てられることで、スタンバイ仮想マシン４２上でスタンバイ状態であったアプリケーションシステムは、サービス開始可能な状態となる。スタンバイ仮想マシン４２に対して十分な資源量が割り当てられた後、負荷分散装置１１に、スタンバイ仮想マシン４２を負荷分散対象のサーバとして登録することで、スタンバイ仮想マシン４２は、クライアントからの要求受付を開始する（ステップＳ５００８）。スタンバイ仮想マシン４２がアプリケーションシステムの一部として運用されることで、プロビジョニングが完了する。

一方、制御実行部２４は、ステップＳ５０００で、スタンバイ仮想マシン４２におけるアプリケーションシステムと、プロビジョニング実行対象のアプリケーションシステムとが一致しないと判断したときには、通常のプロビジョニング処理を行う。すなわち、スタンバイ仮想マシン４２上で既に起動しているアプリケーションがあるか否かを調べ（ステップＳ５００２）、起動しているアプリケーションがあるときには、そのアプリケーションを停止する（ステップＳ５００３）。

アプリケーションの停止後、共有ディスク装置５０に格納された構成済みのアプリケーションシステムを含むＯＳのディスクイメージを指定し、リモートブートによってアプリケーションシステムを起動する（ステップＳ５００４）。その後、ネットワーク機器の設定変更をしてネットワーク構成を変更し（ステップＳ５００５）、管理サーバ２０への登録を行う（ステップＳ５００６）。更に、ステップＳ５００７で、スタンバイ仮想マシン４２に割り当てられる資源量を変更し、ステップＳ５００８で負荷分散装置１１への登録を行う。

本実施形態では、アプリケーションシステムとして構成済みのディスクイメージを共有し、リモートブートによってプロビジョニングを行う。これにより、ＯＳやアプリケーションの入れ替え、セットアップ処理を分けて行う場合に比して、プロビジョニングを高速化できる。ただし、共有ディスク装置５０として、ＳＡＮやＮＡＳなどのストレージ装置が必要となる。その他の効果は、第１実施形態と同様である。

図１３は、本発明の第３実施形態のプロビジョニングシステムにおける管理サーバの構成を示している。本実施形態のプロビジョニングシステムは、図１における管理サーバ２０を、図１３に示す管理サーバ２０ａで置き換えた構成である。本実施形態のプロビジョニングシステムにおける管理サーバ２０ａは、図１に示す管理サーバ２０の構成に加えて、スケジュール入力部２５、スケジュール管理部２６、及び、時刻監視部２７を有する。本実施形態では、プロビジョニングを、現在のシステム状態ではなく、あらかじめ定められたスケジュールに従って実行する。

スケジュール入力部２５は、管理者により入力された、プロビジョニング要求するスケールをスケジュール管理部２６に登録する。スタンバイ構築決定部２２は、スケジュール管理部２６に登録されたスケジュールと、時刻監視部２７から取得する現在時刻とを照らし合わせ、現在時刻が、スケジュールされた日時よりも所定時間だけ早い時刻となると、スタンバイ仮想マシン４２（図１）を構成し、スタンバイ仮想マシン４２上で、プロビジョニングの一部を実行させる。また、プロビジョニング決定部２３は、スケジュール管理部２６に登録されたスケジュールと、時刻監視部２７から取得する現在時刻とを照らし合わせ、現在時刻が、スケジュールされた日時となると、スタンバイ仮想マシン４２を用いて、プロビジョニングを実行する。

図１４は、スタンバイ構築決定部２２が、スタンバイ仮想マシン４２に対して事前にプロビジョニングを行う際の動作手順を示している。まず、準備段階の処理として、管理者は、スケジュール入力部２５を用いて、プロビジョニングを実施するスケジュールを設定する（ステップＳ６０００）。入力するスケジュールの例を、図１５に示す。スケジュールは、少なくとも、プロビジョニングを要求する日時、対象となる共有サーバ、要求するアプリケーションシステムの情報を含む。次いで、スタンバイ構築決定部２２は、時刻監視を開始し（ステップＳ６００１）、スケジュール管理部２６に登録されたスケジュールと、時刻監視部２７により提供される現在時刻とから、プロビジョニングの準備が必要であるか否かを判断する（ステップＳ６００２）。

ステップＳ６００２では、例えば、現在時刻が、スケジュールされた日時の１０分前となると、準備が必要であると判断する。スタンバイ構築決定部２２は、準備が必要ないと判断すると、所定時間だけ待機し（ステップＳ６００４）、その後に、ステップＳ６００２に戻る。スタンバイ構築決定部２２は、プロビジョニングの準備が必要と判断すると、制御実行部２４を介して、スタンバイ仮想マシン４２の構成を開始する（ステップＳ６００３）。ステップＳ６００３では、図２のステップＳ１００４と同様に、構成されたスタンバイ仮想マシン４２上で、プロビジョニングの一部を実行する。このとき、スタンバイ構築決定部２２は、スケジュールで指定されたアプリケーションを、スタンバイ仮想マシン４２上にセットアップする。

図１６は、プロビジョニング実行の際の動作手順を示している。プロビジョニング決定部２３は、スケジュールの入力後（図１４のステップＳ６０００）、時刻監視を開始し（ステップＳ７０００）、スケジュール管理部２６に登録されたスケジュールと、時刻監視部２７より提供される時刻情報とから、プロビジョニングが必要であるか否かを判断する（ステップＳ７００１）。ステップＳ７００１では、現在時刻が、スケジュールされた日時となると、プロビジョニングが必要であると判断する。現在時刻がスケジュールされた日時よりも前であれば、プロビジョニングは必要ないと判断して、所定時間だけ待機し（ステップＳ７００４）、その後、ステップＳ７００１に戻る。

現在時刻が、スケジュールされた日時となると、プロビジョニング決定部２３は、プロビジョニングを実行する。本実施形態では、スケジュールされた日時よりも前に、スタンバイ構築決定部２２によって、スタンバイ仮想マシン４２上でプロビジョニングの一部が既に実行されているので、プロビジョニングの実行では、アクティブ仮想マシン４１（図１）及びスタンバイ仮想マシン４２の資源量の変更、及び、負荷分散装置１１へのスタンバイ仮想マシン４２の登録を行う（ステップＳ７００２、Ｓ７００３）。ステップＳ７００２で資源量を変更することで、見かけ上、アクティブ仮想マシンとスタンバイ仮想マシンとの入替えを行い、ステップＳ７００３で、負荷分散装置１１への登録を行い、スタンバイ仮想マシン４２がユーザ要求を受け付ける状態とすることで、プロビジョニングが完了する。

本実施形態では、スケジュールに基づいて、事前にスタンバイ仮想マシン４２にスタンバイ状態を構成し、スケジュールで指定した日時となると、アクティブ仮想マシン４１の資源量とスタンバイ仮想マシン４２の資源量とを変更して、プロビジョニングを行う。これにより、スケジュールした日時に、迅速にアプリケーションシステムの入替えを行うことができる。その際、スケジュールで指定した日時までは、アクティブ仮想マシン４１が動作することで、共有サーバ４０（図１）をアプリケーションシステムの一部と運用することができる。長期間運用を継続しているシステムで、負荷変動があらかじめ予測できる場合には、プロビジョニングのスケジュールを事前に指定することで、運用の効率化を図ることができる。

なお、上記実施形態では、プロビジョニングシステムが、プロビジョニング対象の共有サーバ４０を１台備える構成を説明したが、共有サーバ４０は、１台には限らず、複数のサーバを、仮想マシンモニタ４３を有する共有サーバ４０として構成することもできる。また、上記各実施形態は、組み合わせて使用することができ、例えば第２実施形態の構成と第３実施携帯の構成とを組み合わせて用いることもできる。第３実施形態では、スケジュールによってプロビジョニングを制御したが、スケジュールを優先しつつ、スケジュールが存在しない時間帯では、第１実施形態と同様に、プロビジョニング予測によるプロビジョニングを行って、共有サーバ４０を最大限に有効活用することもできる。

以上、本発明をその好適な実施形態に基づいて説明したが、本発明のプロビジョニングシステム、方法、及び、プログラムは、上記実施形態にのみ限定されるものではなく、上記実施形態の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。

この出願は、２００７年１月１１日に出願された日本出願特願２００７−００３８２３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、仮想マシンを含むシステムを統合運用管理する管理ミドルウェアの用途に適用できる。本発明により、高速にプロビジョニングが行えるため、アプリケーションシステムのＳＬＡを維持しつつ、資源を有効活用することができ、システム全体のコストを削減できる。

本発明の第１実施形態のプロビジョニングシステムの構成を示すブロック図。 スタンバイ構築決定部が、スタンバイ仮想マシンに対して事前にプロビジョニングを行う際の動作手順を示すフローチャート。 プロビジョニング決定部によるプロビジョニング決定の動作手順を示すフローチャート。 プロビジョニング実行の際の動作手順を示すフローチャート。 (ａ)〜（ｃ）は、共有サーバにおけるアプリケーションシステムの状態遷移の様子を示すブロック図。 実施例のプロビジョニングシステムの構成を示すブロック図。 (ａ)は、性能特徴ベクトルを示す図、（ｂ）は、性能特徴ベクトルとプロビジョニング要求発生とのパターンを示す図。 状態遷移コストグラフの具体例を示す図。 (ａ)及び（ｂ）は、各アプリケーションシステムについて算出されたプロビジョニング要求の発生確率を示す図。 期待プロビジョニング時間の算出結果を示す図。 本発明の第２実施形態のプロビジョニングシステムの構成を示すブロック図。 第２実施形態におけるプロビジョニングの実行手順を示すフローチャート。 本発明の第３実施形態のプロビジョニングシステムにおける管理サーバの構成を示すブロック図。 第３実施形態における事前プロビジョニングの動作手順を示すフローチャート。 スケジュールの具体例を示す図。 第３実施形態におけるプロビジョニング実行の際の動作手順を示すフローチャート。

符号の説明

１０ プロビジョニングシステム
１１ 負荷分散装置
２０ 管理サーバ
２１ 情報監視部
２２ スタンバイ構築決定部
２３ プロビジョニング決定部
２４ 制御実行部
２５ スケジュール入力部
２６ スケジュール管理部
２７ 時刻監視部
３１〜３６ サーバ機
４０ 共有サーバ
４１ アクティブ仮想マシン
４２ スタンバイ仮想マシン
４３ 仮想マシンモニタ
５０ 共有ディスク装置

Claims (42)

1. 複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニングシステムであって、
   前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、
   アプリケーションシステムを稼動させるためのアクティブ仮想マシンが構成された共用サーバ上に、前記アクティブ仮想マシンに割り当てられた資源量よりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築手段と、
   プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行手段とを備え、
   前記スタンバイ構築手段は、前記サーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、前記プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とするプロビジョニングシステム。
2. 前記スタンバイ構築手段は、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する、請求項１に記載のプロビジョニングシステム。
3. 前記スタンバイ構築手段は、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する、請求項１に記載のプロビジョニングシステム。
4. 前記スタンバイ構築手段は、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する、請求項３に記載のプロビジョニングシステム。
5. 前記スタンバイ構築手段は、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びアプリケーションの起動を実行させる、請求項１に記載のプロビジョニングシステム。
6. 前記スタンバイ構築手段は、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる、請求項１に記載のプロビジョニングシステム。
7. 前記スタンバイ構築手段は、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる、請求項５に記載のプロビジョニングシステム。
8. 前記スタンバイ構築手段は、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる、請求項１に記載のプロビジョニングシステム。
9. 前記プロビジョニング実行手段は、前記２つ以上のアプリケーションシステムのうちの何れかに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う、請求項１に記載のプロビジョニングシステム。
10. 前記プロビジョニング実行手段は、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う、請求項１に記載のプロビジョニングシステム。
11. 前記プロビジョニング実行手段は、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築手段によって前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項１０に記載のプロビジョニングシステム。
12. 前記プロビジョニング実行手段は、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築手段によって前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項１０に記載のプロビジョニングシステム。
13. 前記プロビジョニング実行手段は、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項１０に記載のプロビジョニングシステム。
14. コンピュータを用い、複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニング方法であって、
    前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、
    前記コンピュータが、アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築ステップと、
    プロビジョニング要求が発生した場合、前記コンピュータが、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行ステップとを有し、
    前記スタンバイ構築ステップでは、前記コンピュータは、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいてプロビジョニング要求の発生の有無を予測し、前記プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とするプロビジョニング方法。
15. 前記スタンバイ構築ステップでは、前記コンピュータは、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する、請求項１４に記載のプロビジョニング方法。
16. 前記スタンバイ構築ステップでは、前記コンピュータは、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する、請求項１４に記載のプロビジョニング方法。
17. 前記スタンバイ構築ステップでは、前記コンピュータは、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する、請求項１６に記載のプロビジョニング方法。
18. 前記スタンバイ構築ステップでは、前記コンピュータは、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びプリケーションの起動を実行させる、請求項１４に記載のプロビジョニング方法。
19. 前記スタンバイ構築ステップでは、前記コンピュータは、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる、請求項１４に記載のプロビジョニング方法。
20. 前記スタンバイ構築ステップでは、前記コンピュータは、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる、請求項１８に記載のプロビジョニング方法。
21. 前記スタンバイ構築ステップでは、前記コンピュータは、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる、請求項１４に記載のプロビジョニング方法。
22. 前記プロビジョニング実行ステップでは、前記コンピュータは、前記アプリケーションシステムに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う、請求項１４に記載のプロビジョニング方法。
23. 前記プロビジョニング実行ステップでは、前記コンピュータは、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う、請求項１４に記載のプロビジョニング方法。
24. 前記プロビジョニング実行ステップでは、前記コンピュータは、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項２３に記載のプロビジョニング方法。
25. 前記プロビジョニング実行ステップでは、前記コンピュータは、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項２３に記載のプロビジョニング方法。
26. 前記プロビジョニング実行ステップでは、前記コンピュータは、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項２３に記載のプロビジョニング方法。
27. コンピュータに、複数のサーバで２つ以上のアプリケーションシステムを動作させ、前記複数のサーバが複数の仮想マシンを構成可能な共有サーバを少なくとも１台含むシステムで、サーバのプロビジョニングを行う処理を実行させるプログラムであって、前記コンピュータに、
    アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築処理と、
    プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行処理とを実行させ、
    前記スタンバイ構築処理では、前記アプリケーションシステムを構成するサーバの負荷状態を取得し、該取得した負荷状態に基づいて前記プロビジョニング要求の発生の有無を予測し、プロビジョニング要求が発生すると予測すると前記スタンバイ仮想マシン上で前記プロビジョニングを実行させることを特徴とするプログラム。
28. 前記スタンバイ構築処理では、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、プロビジョニングの発生を予測する、請求項２７に記載のプログラム。
29. 前記スタンバイ構築処理では、前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、該計算した確率が所定のしきい値以上であると、プロビジョニング要求が発生すると予測する、請求項２７に記載のプログラム。
30. 前記スタンバイ構築処理では、前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定する、請求項２９に記載のプログラム。
31. 前記スタンバイ構築処理では、前記スタンバイ仮想マシン上で、少なくともＯＳの起動及びプリケーションの起動を実行させる、請求項２７に記載のプログラム。
32. 前記スタンバイ構築処理では、前記スタンバイ仮想マシン上で、ＯＳの起動、アプリケーションの起動、設定変更、パッチ適用、ネットワークの構成変更、管理／監視サーバへの登録設定、及び、連携サーバへの登録設定を実行させる、請求項２７に記載のプログラム。
33. 前記スタンバイ構築処理では、共有ディスクに格納されたディスクイメージを使用して、前記スタンバイ仮想マシン上でＯＳ及びアプリケーションを起動させる、請求項３１に記載のプログラム。
34. 前記スタンバイ構築処理では、プロビジョニング要求を発生させる時刻を定めたプロビジョニングスケジュールを記憶するスケジュール管理部を参照し、前記プロビジョニング要求を発生させる時刻よりも前の時点で、前記スタンバイ仮想マシンを起動し、該スタンバイ仮想マシン上でプロビジョニングを事前に実行させる、請求項２７に記載のプログラム。
35. 前記プロビジョニング実行処理では、前記アプリケーションシステムに対応するサーバの負荷状態が所定のしきい値を超えると、当該アプリケーションシステムのプロビジョニングを行う、請求項２７に記載のプログラム。
36. 前記プロビジョニング実行処理では、前記スタンバイ仮想マシンに割り当てる資源量を、前記アクティブ仮想マシンに割り当てる資源量よりも多くし、スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行う、請求項２７に記載のプログラム。
37. 前記プロビジョニング実行処理では、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致するときには、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項３６に記載のプログラム。
38. 前記プロビジョニング実行処理では、前記プロビジョニングするアプリケーションシステムと、前記スタンバイ構築ステップにて前記スタンバイ仮想マシン上で事前にプロビジョニングが実行されたアプリケーションシステムとが一致しないときには、前記スタンバイ仮想マシン上で少なくともＯＳの起動及びアプリケーションの起動を実行させ、ＯＳ及びアプリケーションの起動後、前記スタンバイ仮想マシンとアクティブ仮想マシンとの入替えを行い、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項３６に記載のプログラム。
39. 前記プロビジョニング実行処理では、アプリケーションシステムの負荷分散を行う負荷分散装置に前記スタンバイ仮想マシンを登録し、前記スタンバイ仮想マシンを用いたアプリケーションシステムの運用を開始させる、請求項３６に記載のプログラム。
40. 複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニングシステムであって、
    前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、
    アプリケーションシステムを稼動させるためのアクティブ仮想マシンが構成された共用サーバ上に、前記アクティブ仮想マシンに割り当てられた資源量よりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築手段と、
    プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行手段とを備え、
    前記スタンバイ構築手段は、前記サーバの負荷状態を取得し、
    前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、
    前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定することを特徴とするプロビジョニングシステム。
41. コンピュータを用い、複数のサーバで２つ以上のアプリケーションシステムを動作させるシステムでサーバのプロビジョニングを行うプロビジョニング方法であって、
    前記複数のサーバの少なくとも１つは複数の仮想マシンを構成可能な共有サーバとして構成されており、
    前記コンピュータが、アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築ステップと、
    プロビジョニング要求が発生した場合、前記コンピュータが、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行ステップとを有し、
    前記スタンバイ構築ステップでは、前記サーバの負荷状態を取得し、
    前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、
    前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定することを特徴とするプロビジョニング方法。
42. コンピュータに、複数のサーバで２つ以上のアプリケーションシステムを動作させ、前記複数のサーバが複数の仮想マシンを構成可能な共有サーバを少なくとも１台含むシステムで、サーバのプロビジョニングを行う処理を実行させるプログラムであって、前記コンピュータに、
    アプリケーションシステムを稼動させるアクティブ仮想マシンと同じ共有サーバ上で、前記アクティブ仮想マシンよりも少ない資源量でスタンバイ仮想マシンを起動させ、該スタンバイ仮想マシン上でプロビジョニングの一部を事前に実行させるスタンバイ構築処理と、
    プロビジョニング要求が発生した場合、前記アクティブ仮想マシンと前記スタンバイ仮想マシンとの資源割当量を変更し、前記スタンバイ仮想マシンがアプリケーションシステムの一部として運用されるのに応じて、前記プロビジョニングを完了させるプロビジョニング実行処理とを実行させ、
    前記スタンバイ構築処理は、前記サーバの負荷状態を取得し、
    前記サーバの負荷状態と、過去のサーバの負荷状態の統計情報とに基づいて、各アプリケーションシステムについて現時点から所定時間後にプロビジョニング要求が発生する確率を計算し、
    前記計算した確率と、アプリケーション間の切替えに要する時間コストを表した状態遷移コストグラフとに基づいて、前記スタンバイ仮想マシン上で事前に実行するプロビジョニングの対象となるアプリケーションシステムを決定することを特徴とするプログラム。

Images