JP4129988B2 - リソースのプロビジョニング方法 - Google Patents

Description

本発明は、リソースのプロビジョニング方法に関する。さらに詳しくはＩＴ環境下におけるリソースのプロビジョニング方法、システム、および制御プログラムに関する。

現在のＩＴ環境、特にリソースが一箇所に集中しているデータ・センターのような場所では、サービスの負荷変動に応じて、余剰リソース（サーバ、ネットワーク機器、ストレージなど）を効率的（処理時間および資源利用率）に各サービスに割り当てる仕組み（プロビジョニング）が必要とされている。この余剰リソースをサービスに割り当てるためには、そのサービスに合ったハード構成、ＯＳやアプリケーションのインストール、およびその設定作業が必要であり、その過程で発生する設定処理（ＯＳ／アプリケーションのインストール、ＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）の切り替えなど）は、一般に比較的時間のかかる作業事である。

そこで、迅速なプロビジョニングをするための方法として、ネットワーク機器に対してプロビジョニングデータをバックアップすることで短時間にデータアップロード行う方法（特許文献１）がすでに考案されている。また、あらかじめ所定のＯＳ／アプリケーションをインストールしたサーバのディスク・イメージを保存しておいて、プロビジョニング時、そのディスク・イメージをコピーするクローン・インストール（例えば、非特許文献１、２）が公開されている。
特開平１１−３０８３０２号公報 http://www.symantec.com/region/jp/products/ghost_enterprise/index.html http://sea.symantec.com/content/product.cfm?productid=9

現在のデータ・センターや企業内のＩＴシステムは、サービス（データ・センターでは顧客、企業内ＩＴシステムでは業務）ごとに別々にＩＴリソースが確保されており、それぞれが独立してシステム構築・運用がされている。さらに、サービスごとに、ピーク時の負荷に耐えうるだけのＩＴリソースがあらかじめ用意されている。このため、ピーク時以外のＩＴリソースの稼働率は、一般に低くなってしまっている。ある米国調査会社の調査によると、「世界中のサーバの約７５％のＣＰＵパワーが使用されていない。」との報告がある。一方、ＩＴリソースを使って稼動している各サービスのピークの時期を調べてみると、それぞれのサービスのピークが完全に一致していることは少なく、ほとんどの場合、それぞれのサービスのピークは分散している。従って、あるサービスに、想定した以上の負荷が発生した場合においても、他のサービス用のリソースを利用することによって、リソースを有効利用することが図れるが、現在のシステムでは、このような使い方を想定してシステムが構成されていないために、一般には困難である。

このような背景の下、オンデマンド・コンピューティングやユーティリティ・コンピューティングといったシステムが求められ始めてきた。これは、各種のサービスを統合的に管理して、各サービスが独立に持っていた余剰ＩＴリソースを、全サービスで共通のリソース・プールに蓄えておき、あるサービスで使われているリソースにおいてその負荷が急増した際に、このリソース・プールからリソースをそのサービスに動的に追加するという仕組みである。このリソース・プールから、リソースをサービスに割り当てることをプロビジョニングと呼ぶが、この際に、追加すべきリソースをそのサービスが必要としている設定に事前に変更して利用開始する必要がある。

図１は、従来のプロビジョニング・システム例の手順を示したものである。以下の図では、リソースとしてサーバを例に示してあるが、リソースの種類としては、ネットワーク機器、ストレージ、その他ハードウェアなどが含まれる。

図１では、ソフトウェアがなにもインストースされていない、いわゆるベア・メタルサーバから各サービスに必要なソウトウェアを順次インストールしていく手順が示されている。すなわち、サービスＡに対しては、ＯＳとして、まずＷｉｎｄｏｗｓ（登録商標）をインストールし、次にミドルウェアとして、ＷＡＳ（Ｗｅｂｓｐｈｅｒｅ（登録商標） Ａｐｌｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）をインストールし、更に、ＷＡＳ上で動作するアプリケーションとして、ＷＡＳ−ＡＰＰ１をインストールして、サービスＡに適合するサーバを構築する。サービスＢに対しては、ハードウェア（Ｈ／Ｗ）に対して、Ｗｉｎｄｏｗｓ（登録商標）、ＷＡＳをインストールするまではサービスＡと共通であるが、ＷＡＳ−ＡＰＰ２の部分がサービスＡと異なる。また、サービスＣでは、ＯＳがＬｉｎｕｘ（登録商標）であり、ＷＡＳはなく、アプリケーションとしてＤＢ２（登録商標）がインストールされているのでＨ／Ｗ以外はサービスＡ、Ｂと異なっている。図１では、このように各種ソウトウェアをサービスの要求する構成や台数にあわせて、順にインストールしていき、サービスＡにサーバが３台、サービスＢにサーバが２台、サービスＣにサーバが１台、それぞれデプロイ（割り当て）されていく過程を示している。

しかしながら、このような単純なプロビジョニング・システムでは、特定のサービスに対してプロビジョニングの要求が発生してから、リソース・プールのリソースに対して、様々の設定作業を行い、全ての設定作業完了後にサービスとしてデプロイされるため、設定作業自体に時間がかかってしまい、要求発生ののちデプロイされるまで待たなければならない。このような単純なシステムの場合、時間的に急激に増大する負荷の変動に対応することは困難となる。特に、サーバをプロビジョニングする場合、サービスが必要とするＯＳ／アプリケーションをサーバに順次インストールする必要があるが、周知のようにＯＳ／アプリケーションのインストールには多大な時間がかかる。

特許文献１のバックアップデータを用いる方法や、非特許文献１のクローン・インストールでは、このような設定作業を短縮するための手法である。しかしながら、いずれの方法も、バックアップデータや元のディスク・イメージ中にデバイス・ドライバなどＨ／Ｗと関連づいた情報を事前に含めておく必要がある。例えば、クローン・インストールでは、ディスク・イメージを抽出したサーバとまったく同じタイプのサーバにしかインストールすることができない。さらに、ホスト名やＩＰアドレスなどのサーバ固有の情報もディスク・イメージ中に残されるため、クローン・インストール後、適切に設定を変更する必要がある。これらの情報はＯＳやアプリケーションそれぞれが保持していることがあり、全ての項目を適切設定することは困難である。また、プロビジョニング先となるサービスの種類数だけディスク・イメージが必要になり、新たにパッチを適用したい、パッチのレベルを複数持ちたい、といった柔軟な構成変更をすることができないという欠点がある。つまり、バックアップデータのアップロードやディスク・イメージ・クローニングのようなプロビジョニングの方法では、事前にそれらを用意しておくことが必ず必要となるため、リソースに対する複数の異なった要求に対して、短時間でプロビジョニングを行うことが困難である。

従って、本発明は上記課題を解決するために、複数の異なった要求によるプロビジョニング時間をより柔軟に短縮する方法、システム、およびそれを制御するプログラムを提供することを目的とする。

本発明の第１の形態によると、複数のサービスが必要とするリソースの割り当てを行うプロビジョニング方法であって、複数のサービスが共有するリソース・プール内にプロビジョニングの過程における中間状態として一または複数のステージを設けるステージング段階と、一または複数の前記リソースの状態を、一または複数の前記ステージに、事前に与えられた初期状態として割り当てる段階と、割り当てられた前記リソースの状態を他の前記ステージに遷移させるために要する設定作業時間に基づいて、所定のアルゴリズムによる所定のコストを算出し、前記所定のコストが最小となるように全てのリソースを各ステージに最適に配置する段階と、を備える、プロビジョニング方法を提供する。

本発明の第２の形態によると、複数のサービスが必要とするリソースのプロビジョニングを行うステージング・エンジンであって、前記ステージング・エンジンは、前記サービスが共有するリソース・プール内に、プロビジョニングの過程における中間状態として一または複数のステージを設け、ステージをノード、ノード間の遷移をエッジとするグラフを作成するグラフ作成部と、所定のアルゴリズムによる所定のコストが最小となるように、前記リソース・プール中の全てのリソースの状態の最適配置を求める遷移計画部と、前記遷移計画部が発行した遷移計画に基づいて、リソース遷移処理要求の発行を行う遷移要求発行部と、外部からのイベントを待つ、イベント処理部と、前記イベントがサービス・リクエストの場合、要求を発生した該サービスに最も近いノードを求めるデブロイ部と、を備える、ステージング・エンジンを提供する。

本発明の第３の形態によると、複数のサービスが必要とするリソースの割り当てを行うプロビジョニングをコンピュータに実行させるコンピュータ・プログラムであって、前記サービスが共有するリソース・プール内に前記プロビジョニングの過程における中間状態として一または複数のステージを設けるステージング機能と、一または複数の前記リソースの状態を、一または複数の前記ステージに、事前に与えられた初期状態として割り当てる機能と、割り当てられたリソースの状態を他のステージに遷移させるために要する設定作業時間に基づいて、所定のアルゴリズムによる所定のコストを算出し、前記の所定のコストが最小となるように全てのリソースを各ステージに最適に配置する機能と、をコンピュータに実行させる、コンピュータ・プログラムを提供する。

上記発明においては、いくつかのサービスで共有の余剰リソースを管理するためリソース・プールを考え、リソース・プールから各サービスへのプロビジョニング過程における複数の中間状態（ステージ）を仮想的に設定する。外部からのサービスに対するリソースの要求が発生してから、プロビジョニングに必要な設定処理を最初から開始するのではなく、あらかじめプロビジョニング途中の中間ステージに複数のリソースを効率的に割り当てて置くことによって、外部からのサービスに対するリクエストからプロビジョニング完了までにかかる時間を短縮することができる。例えば、リソースとしてサーバを考えてみると、サーバに、あらかじめＯＳをインストールしておけば、その上で動作する複数のアプリケーションのみをリクエストに応じて動的にインストールすることによりプロビジョニングが完了するまでの時間を短縮することができる。

本発明の手法によって、従来のリソースを割り当てる単位であるクラスタ毎にリソース・プールを保持していた場合に比べて、複数のサービスでリソース・プールを共有することで、リソース・プールに配置するリソースの数を相対的に削減することができる。一方、従来のクラスタ間でリソース・プールを共有していた場合に比べて、本発明の手法を用いることによって、リソースのプロビジョニングの要求が生じたときには、最も適切なステージからプロビジョニングを行うことができ、プロビジョニングが完了する時間をより短縮することができる。

以下、本発明の実施形態について図を参照しながら説明する。

本発明の好適な実施形態では、各リソースの初期状態から各サービスにデプロイするまでの手順を洗い出し、各段階におけるリソースの状態をノード（ステージ）、設定作業をエッジとした有向グラフとして表現する。ただし、異なるサービスにデプロイする場合においても、初期状態やいくつかの中間状態は、共通であることがあるので、そのような共通の中間状態は同じノードとして表現する。

例えば、リソースとしてサーバを考え、設定作業としてＯＳ／アプリケーションのインストール作業を考える。何もＯＳがインストールされていないベア・メタルサーバ（Ｈ／Ｗ）の状態が初期ノードに相当し、ＯＳのみがインストールされた状態が中間ノード１、ミドルウェアなどがインストールされた状態が中間ノード２、さらにサービスに必要なアプリケーションがインストールされた状態が最終ノードとなる。また、ミドルウェアが存在しない場合や、多数のアプリケーションがインストールされている場合、同じアプリケーションでも設定が異なる場合など、様々な中間状態が存在し得る。

ここで、初期ノードと中間ノード１の間、中間ノード１と中間ノード２の間、中間ノード２と最終ノードの間は明らかに遷移が可能なため有向エッジが張られる。また、別のサービスが同じＯＳを使う場合は、中間ノード１を共有することになる。さらに、いずれのノードからでも、ＯＳのインストールからやり直すことができるため、各ノードから初期ノードへはエッジで結ばれる。また、設定作業を取り消すことができる場合（例えば、アプリケーションのアンインストールが可能な場合など）は、逆方向にもエッジを結ぶ。

図２は、このような初期、中間、または最終状態（ステージ）をノードとして表し、各ノードをエッジで連結した有向グラフとして示したものである。すなわち、初期状態１のベア・メタルサーバ（Ｈ／Ｗ）に、ＯＳのみがインストールされた状態、ミドルウェアがインストールされた状態、アプリケーションがインストールされた状態、それぞれをノードとした有向グラフを構成する。ここで、有向グラフとは、エッジに方向性を持つグラフをいう。また、図２では、初期ノード１にサーバが１台、中間ノード３にサーバが１台、最終ノード４、５、７にサーバが各１台割り当てられた状態を示している。ここで、最終ノードとは、サービスにそのままサーバをデプロイできる状態をいう。この場合、サービスＡに最も「近い」ノードはノード４であり、次に「近い」ノードはノード３であるという。この「近い」という用語は距離的な遠近でなく、ノード間を遷移させるためのトータルで必要なリソースの設定時間が短いこという。

リソース・プール中の各リソースは、いずれかのノードに割り当てられ、割り当てられたそれぞれのノード（ステージ）の状態をとることができる。また、エッジ（処理作業）に関連付けられた処理あるいは設定作業を行うことによって、リソースは、そのエッジに沿ってノードを遷移する。サービスを展開する状態に近いノード（例えば、図２のノード４、５、７など）に多くのリソースを配置した場合、そのサービスへのプロビジョニングにかかる時間を短縮することができる。一方、サービスから遠いノード（例えば、図２のノード１、２、６など）に配置したほど、様々なサービスへのプロビジョニングに対応できる。従って、現在のリソースを、各サービスからのリソース要求パターンやＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）を考慮して、適切なノードに遷移し、割り当てることにより、プロビジョニングにかかる時間を短縮することができる。

あるサービスからの要求が発生した際は、そのサービスを展開する状態に最も近いノードに配置されたリソースを、そのサービスにプロビジョニングする。プロビジョニング後は、プール中からリソースが一つ減少する。これに従い、再び、最適配置を計算し、リソースの割り当てを変更する。

以下、本発明に係るシステム構成の一例について説明する。

本発明の実施例としての全体の構成を図３に示す。図に示すように本システムは、上述のグラフの作成／リソース遷移計画／ノード間の遷移処理要求を発行するステージング・エンジン１０と、データ・センター３０（リソース・プール）中のリソースに対して、設定作業を行うプロビジョニング・マネージャ２０から構成される。

ステージング・エンジン１０における処理の全体フローを図４に示す。まず、ステップＳ１００においてグラフを作成する（グラフ作成部）。具体的なグラフ作成の詳細に関しては、後述する。

グラフの作成後、ステップＳ２００において、リソース・プール中のリソース、例えばサーバなどをグラフ上のどのノード（ステージ）に遷移させるかを求める（遷移計画部）。具体的な遷移計画のアルゴリズムに関しては、後述する。

ステップＳ３００では、現在のリソースの割り当てをステップＳ２００で算出した遷移計画に従って、リソースの遷移処理（遷移に沿ったエッジに関連した設定作業）命令を発行する（遷移要求発行部）。発行した命令は、実際に設定作業をコントロールするプロビジョニング・マネージャ２０が行う。ステップＳ３００では、処理命令を発行するだけであり、命令発行後、すぐにステップＳ４００に移る。遷移させる必要がなければ、何も処理しない。

ステップＳ４００では、外部（プロビジョニング・マネージャ、サービス要求システムなど）からのイベントを待つ（イベント処理部）。ここではイベントの種類としては、以下の三つを想定する。
１）リソース要求イベント：
サービスから、リソースの要求が発生したことを表すイベント
２）遷移処理完了イベント：
プロビジョニング・マネージャに発行した遷移命令（設定作業）が完了したことを表すイベント
３）リソース・プールへのリソースの追加／削除イベント：
リソース・プール中のリソースの台数が変更したことを表すイベント
上記いずれかのイベントが発生したら、ステップＳ５００に移る。

ステップＳ５００では、上記イベントの種類を判断し、リソースのリクエスト要求イベントの場合はステップＳ６００に、その他の場合は、ステップＳ２００に戻る。

ステップＳ６００では、要求を発生したサービスに最も近い（デプロイするまでの処理時間が最も短い）ステージにあるリソースを、そのサービスにデプロイするように、プロビジョニング・マネージャ２０などに命令を発行する（デプロイ部）。実際にデプロイを行うのはプロビジョニング・マネージャ２０でなく他のシステムであってもよい。ステージング・エンジン１０は、デプロイの命令発行後（ステップ６００）、すぐに、ステップＳ２００に遷移する。

図５にステップＳ１００で行うグラフ作成部の処理を示した。また、図６に説明に用いる例として、リソース・プールとそれを利用するサービスＡ、Ｂ、Ｃが示した。
まず、ステップＳ１１０において、リソース・プールとそれを利用するサービスＡ、Ｂ、Ｃを、各サービスへのプロビジョニング手順を中間状態（ステージ）に分割する。この分割された結果を図７に示した。
次に、ステップＳ１２０において、分割した中間状態のうち同一の状態となるものをまとめ、図８のようなグラフを作成する。
さらに、ステップ１３０において、設定作業が可逆できる場合（設定処理の取消しが可能、あるいは一つ前のステージに戻るための作業がある）における逆方向のエッジや、ＯＳインストールにおける初期状態（消去する作業により可能）へのエッジを追加する。
図９に、以上のステップにより作成された有向グラフの構造（トポロジ）を示した。

以下、具体的なシナリオを簡単な例をもとに図１０〜図１４に示す。これらの図は、３台のサーバをサービスのリソース要求に応じて、四つのノードに順次遷移させていく手順を示している。以下、図中ではノードの番号を○で囲み示すこととする。この例では、初期ステージがノード１、中間ステージがノード２、最終ステージがノード３とノード４である。また、図中のエッジ（矢印）の上にある下線付きの数字は、１台のサーバをノード間で遷移させるのに必要な設定作業時間を表している。

３台のサーバは初期状態においては全てノード１にあるとする。ここでまず、上記のようなグラフを作成し最適なサーバの配置計算を行う（図１０（ａ））。この例ではノード２、３、４にそれぞれ１台のサーバが割り当てられた状態が最適配置であるとする（図１０（ａ）右側の図）。

次に、配置計算の結果を元にサーバを遷移（ステージを移動）させる（図１０（ｂ））。その後、サービスＡから、サーバ要求が発生したとする（図１１（ｃ））。サーバ要求イベントが発生したので、サービスＡに最も近い（デプロイするまでの処理時間が最も短い）サーバをサービスＡにデプロイする（図１１（ｄ））。サーバ要求が発生し、リソース・プールにあるサーバが２台に減ったので、再びサーバの配置計算を行う。その結果に従い、サーバを遷移する（図１２（ｅ）、図１２（ｆ））。その後、サービスＡから、サーバ１台がリソース・プールに戻される（図１３（ｇ））と、リソース・プールへのサーバ追加イベントが発生したとみなし、再び、サーバの配置計算を行う（図１３（ｈ））。その配置計算に従い、再び最適な状態に全てのサーバを遷移（ステージを移動）させる（図１４（ｉ））。

図１５は、グラフのモデルを示したものである。既に述べたように、ノードの番号は○で囲んだ数字で表し、遷移可能なノードは矢印で表す。ここで、矢印２ａ〜７ａで示すようにどのノードからでも初期ノードには遷移可能（プロビジョニングによって処理した設定を、一度の処理で全て消去できるため）であるとする。また、点線の矢印３ａで示すように中間ノード間で双方向に遷移可能な場合もある。

図４におけるリソースの遷移計画（ステップＳ２００、または遷移計画部）では、上記のリソースのノードへの割り当て問題を解くために、次のように問題を一般化して定式化する。
入力：
・グラフのトポロジ（グラフの構造）
・エッジの重み
ノード間を遷移する時間（設定作業にかかる時間）をエッジの重みとする。
・各ノードに配置されている現在のリソース数
・サービスごとのデプロイ要求の発生分布
過去のデプロイ要求実績データからｎ台のデプロイ要求分布を推定する。
この前提には、過去の要求実績データが適用できるとする。
（例えば、一週間の日曜日から土曜日までの変化、あるいは一日の０−２３時の
変化のように過去と同じか、少しの誤差で一致することを前提とする。）
もしくは、予測手法などを用いて、その都度その都度、動的に決定しても良い。
（一般に発生確率は、単位時間ごとによって異なる発生確率を持つことができる
こととする。また、取るべき単位時間は、ノードを遷移する時間と比べて、同じ
程度とする。）
・サービスＸのデプロイが遅れることによるペナルティ
一般に、サービスごとに重要度が異なるため、重要なサービスに対しての遅れ
では、損失が大きく、そうでないサービスに対しては損失が小さくなるように
設定する。この値は、ＳＬＡによって決定される。
出力：
・各ノードに配置される最適なリソース数
目的関数：
・デプロイの遅れによるコストの最小化
コストは、デプロイ要求発生からデプロイ完了までにかかる時間と、その
デプロイ対象サービスのペナルティとの積によって決まる。

以下、上記問題を解くために具体的な３種類のアルゴリズム１、２、３について説明する。以後、次のようなパラメータ、表記を用いることにする。
ｄ（ｉ，ｊ）：
ノードｉからノードｊへの遷移にかかる時間（エッジの重み）
Ｓ（ｎ_１，ｎ_２，ｎ_３，・・・ｎ_ｍ）：
リソースがノード１にｎ_１台、ノード２にｎ_２台、
ノード３にｎ_３台、ノードｍにｎ_ｍ台配置されている状態を表す。
Ｘ（ｎ_１，ｎ_２、，・・・,ｎ_ｘ）：
サービスＡからｎ_１台、サービスＢからｎ_２台、
サービスＸからｎ_Ｘ台のリソース要求が発生したことを示す。
ω_Ｘ：サービスＸに対するペナルティ：
例えば、図１６に示すグラフの例では、ノード１からノード２に対してはｄ（１，２）＝６０、ノード２からノード３に対してはｄ（２，３）＝１０、ノード２、３、４からノード１への遷移ではｄ（ｉ，１）は全てゼロ、というように各エッジ上に対応する数字で表現する。また、サービスＡとサービスＢでペナルティの差がない場合は、ω_Ａ＝ω_Ｂ＝１とする。

＜アルゴリズム１＞
ここでは、第一のアルゴリズムについて説明する。
アルゴリズム１では、サービスごとのリソース要求発生分布を元に、シミュレーションを行い、現在の配置パターンから最もコストが小さい一手先または二手先の配置パターンを見つける。

現在のリソースの割り当てから、各リソースが隣接するノードに遷移するか、または、しないという、全ての組み合わせを考える。例えば、図１６の例で考えると、現在のリソース割り当てがＳ（２，０，０，０）の場合、リソースの区別がなければ、
２台とも遷移しない場合： Ｓ（２，０，０，０）
１台のみ遷移： Ｓ（１，１，０，０）
２台とも遷移： Ｓ（０，２，０，０）
と、３種類の割り当て候補が得られる。割り当て候補それぞれに対して、ある時間（０＜＝ｔ＜＝Ｔ）におけるサービスからのリソース要求を乱数または特定の確率分布にて発生させ、そのときの動作をシミュレートして、デプロイにかかるコストを計算する。シミュレーションを行う任意の回数をＮとすると、この計算をＮ回繰り返し、コストの平均値が最小となる候補を次の割り当て先として、その状態となるように遷移処理を行う。

具体的には、以下のOptimalAllocation関数に従い最適な配置を求める。
OptimalAllocation
入力パラメータ：
現在のリソースの配置（s_cur）
現在の時刻（t_cur）
出力パラメータ：
コスト（c）
最適なリソースの配置（s_opt）
（cが最小コストとなったときの値）
方法：
現在のリソース配置（s_cur）から、一手先または二手先のリソースの配置候補の集合（S）
を求める。Sには、遷移を行わないs_curも含まれる。

foreach（s_next:S）{
c(s_ext)=0

for（count=0;count<N;count++）{
c(s_next,count）＝0

if (リソース配置候補（s_next）と現在のリソース配置（s_cur）が
異なっている場合) {
リソース配置候補になるように、リソースの遷移を開始させる。

for（ t=t_cur; t<T; t++ ）｛
サービスからのリクエストの発生の有無をシミュレートにより決定

if （リクエストがtで発生した場合）{
リクエストが発生したサービスに最も近いリソースを
デプロイする。
このときのデプロイにかかるコストをc(s_next, count）
に加算する。
リソースを一台デプロイ後のリソース配置をs_removed
と定義する。
if (次の計算)｛ //次の次の計算
OptimalAllocation（ s_removed, t）を計算し、
出力であるコストをc（s_next, count）に加算する。
}
｝
elseif （遷移が完了した場合）{
OptimalAllocation（ s_next, t）を計算し、出力である
コストをc（s_next, count）に加算する。
}
｝
｝
｝
（s_next）=（ c(s_next, 0）+...＋c(s_next, N））／N
｝
最小となるコストc（s_next）をc、および、そのときのリソース配置s_nextを
s_optとし、出力する。

図１７、１８のフローチャートは、上記のアルゴリズムにおいて、あるひとつのｓ＿ｎｅｘｔに対する処理を示したものである（OptimalAllocationの最初のｆｏｒ文内の処理）。

図１９は、上記アルゴリズムの簡単な具体例を示したものである。また、図２０は、図１９における各状態でのサーバの配置を示したものである。図１９、２０中、網掛けの楕円は遷移が完了した状態を示し、白抜きの楕円は遷移中の状態を示している。

まず、初期状態Ｓ１において２台のサーバが割り当てられている。Ｓ１から次にとり得る状態（一手先の状態）としては、なにも遷移しない状態Ｓ１−１（つまりＳ１−１＝Ｓ１）と、ノード２にサーバ１台が遷移途中の状態であるＳ１−２ａを考える。ここでＳ１におけるコストＣ（Ｓ１）として、Ｓ１−１とＳ１−２ａのコストの小さい方をとる。つまり、式で書くと、Ｃ（Ｓ１）＝Ｍｉｎ（Ｃ（Ｓ１−１），Ｃ（Ｓ１−２））となる。ただし、Ｃ（Ｓ１−２）＝Ｃ（Ｓ１−２ａ）である。

ここで、Ｓ１−１においてサービスからサーバ１台の要求が発生したとすると、サーバ１台は、まずそのサービスにデプロイし、このデプロイしたサーバを除いたサーバにつき再び次の遷移候補を考慮する。この場合、Ｓ１−１から次にとり得る状態としては、残ったサーバについては何も遷移がないＳ１−１−１（＝Ｓ１−１）と、ノード１からノード２への遷移状態であるＳ１−１−２の２種類となる。このとき、先のデプロイ自体にかかるコストをＣ１とすると、Ｓ１−１におけるコストＣ（Ｓ１−１）は、Ｃ１にＳ１−１−１とＳ１−１−２のコストの小さいほうを加えた値をとる。すなわち、Ｃ（Ｓ１−１）＝Ｃ１＋Ｍｉｎ（Ｃ（Ｓ１−１−１），Ｃ（Ｓ１−１−２））となる。

一方、Ｓ１−２ａからＳ１−２へ遷移完了時には、次の遷移候補を考慮する。次の遷移候補としては、Ｓ１−２−１（なにも遷移しない状態、すなわち＝Ｓ１−２）と、Ｓ１−２−２（ノード２からノード３ヘのサーバ１台が遷移中の状態）、および、Ｓ１−２−３（ノード２からノード４へサーバ１台が遷移中の状態）の３種類があり得る。このときＳ１−２のコストＣ（Ｓ１−２）としては、Ｓ１−２−１、Ｓ１−２−２、Ｓ１−２−３のコストのうちから最小のものをとる。すなわち、Ｃ（Ｓ１−２）＝Ｍｉｎ（Ｃ（Ｓ１−２−１），Ｃ（Ｓ１−２−２），Ｃ（Ｓ１−２−３））となる。

以上のような計算をシミュレートによってリクエストをＮ回発生させ、最小となるコストとそのときのリソース配置を求める。このリソースは配置が、最適なステージング時の配置となる。

＜アルゴリズム２＞
ここでは、第二のアルゴリズムについて説明する。アルゴリズム２では、以下のように全てのリソースの配置の組み合わせを考えて、組み合わせごとに、全ての発生しうるプロビジョニング要求を考慮した期待値を算出して、それが最小となる配置を見つけ出す。

１．ｆｏｒｅａｃｈ 割り当てＳ＝｛全てのリソースの割り当てパターン｝
（１）ｆｏｒｅａｃｈ 要求Ｘ＝｛リソース台数内の全ての発生要求パターン｝
（ａ） Ｅ（Ｓ）＝０
（ｂ） 割り当てＳ、発生要求Ｘにおけるコストｃ（Ｓ，Ｘ）を計算する。
割り当てＳの状態において、要求したサービスに最も近いリソースを
、そのサービスにデプロイする。リソースをそのサービスに遷移した
時の重み×ペナルティの和をｃ（Ｓ，Ｘ）とする。
（ｃ） Ｅ（Ｓ） ＋＝ ｐ（Ｘ）×ｃ（Ｓ，Ｘ）を計算する。
ここで、ｐ（Ｘ）： 要求Ｘの発生確率である。
すなわち、Ｅ（Ｓ）は次の式で求められる。

２．Ｅ（Ｓ）が最小となるリソースの割り当てＳを見つける。
３．現在のリソース配置から、２．で見つけたリソースの割り当てとなるように、どのリソースをどのように遷移させるか決定する。これに関しては、遷移コストを最小にする方法、優先度の高いサービスには優先的に遷移させる方法を使った、既存のグラフ・マッチング問題の解決法を用いる。

アルゴリズム２の計算を、リソースが１台の場合の例を図２１に、リソースが２台の場合の例を図２２において示す。

図２１上部の図では、サーバ１台のみがノード２に割り当てられている状態、すなわち、Ｓ（０，１，０，０）において、サービスＡからサーバ１台の要求、すなわち、Ｘ（１、０）が発生した場合を示している。このときのコストｃ（Ｓ，Ｘ）は、ノード２からノード３へ遷移する時間ｄ（２，３）とサービスＡのペナルティω_Ａを掛けた値となる。すなわち、ω_Ａが１とし、ｄ（２，３）＝１０とすればＣ（Ｓ，Ｘ）＝１０となる。

図２１の下部の表は、上記のような計算を全リソース割り当てパターンと、全要求パターンについて行った結果をまとめたものである。ここで、要求パターンの発生確率はそれぞれ１／２とし、例えば、Ｓ（０，１，０，０）におけるコストは、上記の計算から、Ｘ（１，０）については１０、同様にＸ（０，１）については２０と計算されるので、期待値は（１／２）＊（１０＋２０）＝３０／２となる。この期待値の計算を全リソース割り当てパターンについて行い、期待値が最小となる割り当てパターンを求める。

図２２では、サーバ２台の場合の計算を示したものである。図２２の上部には、ノード２にサーバが１台、ノード３にサーバが１台配置された状態、すなわち、Ｓ（０，１，０，１）において、サービスＡからサーバ１台の要求、すなわちＸ（１，０）、が発生した例を示している。コストの計算は、図２１の場合と同様である。ただし、ノード３にあるサーバをそのままサービスＡにデプロイするだけなので、このときのコストはペナルティω_Ａにかかわらずゼロとなる。

図２２下部の表は、図２１の場合と同様に上記のコスト計算を全リソース割り当てパターンと、全要求パターンについて行った結果をまとめたものである。ここでは、三つの要求パターンの発生確率が等しい場合、Ｓ（０，２，０，０）の割り当てパターンが最も期待値が小さいことが示されている。

アルゴリズム２は、アルゴリズム１に比べて、解析的に求めるため計算量が小さいが、２．で計算した割り当てのための遷移実行中に、別なリソース要求が発生した場合、ひどくコストがかかってしまう場合があり、最適な配置よりも少し異なる配置となる場合がある。ここで、プール中のリソース数をｎ、ノード数をｍ、クラスタ数をｒとすると、図２１、２２を構成するマトリックスの要素数は、（リクエスト要求の組み合わせ）×（リソース配置の組み合わせ）

となる。

＜アルゴリズム３＞
ここでは第三のアルゴリズムについて説明する。アルゴリズム３では、以下のように各サービスからのプロビジョニング要求を独立に扱い、計算量を削減する。

１．ｆｏｒｅａｃｈ 割り当てＳ＝｛全てのリソースの割り当てパターン｝
（１）ｆｏｒｅａｃｈ サービスＸ ＝｛全てのサービス｝
（ａ）サービスＸへの距離により昇順に全ノードをソートする。
（ｂ）サービスＸが、ｎ台のリクエストが発生したときに、サービスＸの近く
のノードに割り当てられているリソースから順にｎ台がプロビジョニング
されるとする。サービスＸがｉ台のリソースを要求する確率をＰｘ（ｉ）と
すると、サービスＸから最も近くに配置されているリソースはＰｘ（１）の
確率でデプロイされ、その次の近くのリソースはＰｘ（２）の確率で
デプロイされる。
同様に、サービスＸからｉ番目に近いリソースは、Ｐｘ（ｉ）の確率で
デプロイされる。
従って、コストの期待値は、次のように表現される

（ｃ） Ｅ（Ｓ）＋＝Ｅ（Ｓ，Ｘ）を計算する。
２．Ｅ（Ｓ）が最小となるリソースの割り当てＳを見つける。これが、効果的なリソース割り当てＳである。
３．現在のリソース配置から、２．で見つけたリソースの割り当てとなるように、どのリソースをどのように遷移させるか決定する。これに関しては、遷移コストを最小にする方法、優先度の高いサービスには優先的に遷移させる方法など、既存のグラフ・マッチング問題を用いる。

このアルゴリズム３における計算量は、（リソースの配置の組み合わせ）

のみとなるため、アルゴリズム２に比べて計算量が削減される。ただし、グラフのトポロジによっては、ひどく効率の悪い割り当てとなる場合がある。

図２３〜２６にアルゴリズム３の具体例を示した。図２３（ａ）では、まずノード数が４、サービス数が２であるとき、１０台のリソースがリソース・プール中にある場合を考える。ここで、サービスＡ、サービスＢのペナルティは１であるとする。

図２３（ｂ）では、１０台のリソースを各ノードに割り振る。ここでは、ノード１に４台、ノード２に１台、ノード３に３台、ノード４に２台が割り当てられたとする。

つぎに図２４（ｃ）で示すように、サービスＡについて注目し、図２４（ｄ）で示すようにサービスＡへの距離（重み）により昇順にソートする。すなわち、この例では、ノード３にあるサーバはそのままサービスＡにデプロイできるので、ノード３とサービスＡの距離はゼロである。次に、ノード２がノード３へ遷移する時間が１０なのでノード２とサービスＡの距離も１０となる。同様に、ノード１の距離はノード２への遷移とノード３への遷移時間の和６０＋１０＝７０となる。また、ノード４は、いったんノード１へ戻ってからノード２、ノード３へ遷移する必要があるため、サービスＡからの距離は、０＋６０＋１０＝７０となる。

図２５（ｅ）では、期待値Ｅ（Ａ）を計算する過程を示している。ここでは、三つまでのリクエストはノード３にあるリソースが使われ、次の一つまでのリクエストはノード２にあるリソースが使われる。同様にして、１０台までのリクエストが発生した場合の期待値は、サービスＡがｉ台のリソースを要求する発生確率Ｐ_Ａ（ｉ）と、サービスＡからｋ番目に近いノードの距離ｄ（ｋ）およびサービスＡのペナルティω_Ａから図中に示された式で計算される。

図２６（ｆ）では、Ｅ＋＝Ｅ（Ａ）を計算し、その後注目するサービスを変更する。すなわち、図２４（ｃ）の注目サービスＡを注目サービスＢに置き換えて、図２４（ｄ）から図２５（ｅ）までの計算を同様に行う。

さらに、図２６（ｇ）では、リソースの割り振りを変更し、図２３（ｂ）へ戻って期待値Ｅを再計算する。この例では、サーバをノード１に１台、ノード２に２台、ノード３に２台、ノード４に５台と割り振りを変更しているが、この割り振りは任意のパターンでよい。以上の計算を全てのリソース割り当てパターンについて繰返し、期待値Ｅが最小となる割り当てパターンを求めることができる。

以下、ＩＢＭ社のソウトウェア製品のＴｉｖｏｌｉ（登録商標） Ｉｎｔｅｌｌｉｇｅｎｔ Ｏｒｃｈｅｓｔｒａｔｏｒ（ＴＩＯ）を使ったオンデマンド・コンピューティングにおけるシステム実施例を説明する。この実施例では、ＴＩＯをプロビジョニング・マネージャとして、プロビジョニングを実行できるシステムを用いている。

複数のクラスタ・システムをサービスに利用しているデータ・センターをＴＩＯにて管理することを想定する。それぞれのサービスは異なる用途・顧客に使われているため、ピークは異なる。完全にピークを予測可能であれば、あらかじめプロビジョニングしておき、事前にピークに備えることは可能であるが、ピークをあらかじめ完全に予測することは困難であり、また予測を超える負荷には対応できない。

まず、サーバを各クラスタへプロビジョニングする際に行われるインストール手順（設定処理）より有向グラフを作成する。このとき、ノードは、あるＯＳ／アプリケーションがインストールされている状態を表し、また、エッジは、ＯＳ／アプリケーションのインストール作業工程を表す。

エッジの重みは、作業工程の処理時間（例えば、インストール時間や構成要素の変更のための時間）を表すが、これはテスト・インストール作業によって、初期値として自動的に取得される。もしくは、この初期値は、マニュアルで管理者から与えることもできることとする。各クラスタへのリクエストの発生確率は、過去の各クラスタにおけるサーバのリクエスト要求から決定され、時間の経過と共に常に更新することとする。また、クラスタへのプロビジョニングの時間の遅れによるペナルティは、各サービスのＳＬＡによって決定され、高いＳＬＡのクラスタでは、大きいペナルティを、そうでないクラスタには、低いペナルティを与える。

これらのデータを元に、現在プール中のサーバのどのノードへ割り当てるかが決定され、その状態にするために実際のインストール作業が実行される。ここでクラスタからリソース（サーバ）のリクエストがあった場合、プロビジョニング時間が最短となるステージにあるサーバがプロビジョニングされる。

さらにクラスタのピーク時間の予測機能をもっている場合、サービスへの要求確率を変化させることによって、より効率のよいプロビジョニングが可能となる。

以上、本発明を実施形態、および実施例を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されない。上記実施形態に、多様な変更または改良を加えることが可能である。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

本発明において一つの実施形態として説明したプロビジョニングの方法は、コンピュータ上のシステムまたはコンピュータにその機能を実行させるプログラムによって実現可能である。また、上記プログラムを格納する記憶媒体は、電子的、磁気的、光学的、電磁的、赤外線または半導体システム（または、装置または機器）あるいは伝搬媒体であることができる。コンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ可読の媒体の例には、半導体またはソリッド・ステート記憶装置、磁気テープ、取り外し可能なコンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、リジッド磁気ディスクおよび光ディスクが含まれる。現時点における光ディスクの例には、コンパクト・ディスク−リードオンリー・メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）およびＤＶＤが含まれる。

従来のプロビジョニング手順を示す図である。 本発明の好適な実施形態におけるプロビジョニング・システムの概略を示す図である。 本発明の好適な実施形態におけるシステム全体構成図である。 ステージング・エンジンの処理ステップを示すフローチャートを示す図である。 グラフの作成フローチャートを示す図である。 リソース・プールを共有するサービスの例を示す図である。 各サービスへのプロビジョニング手順を中間状態に分割するステップＳ１１０の例を示した図である。 同一状態をまとめ、グラフを作成するステップＳ１２０の例を示した図である。 状態間の遷移が可能な箇所にエッジを追加するステップＳ１３０の例を示した図である。 サーバ配置の遷移の具体例を示す図（その１）である。 サーバ配置の遷移の具体例を示す図（その２）である。 サーバ配置の遷移の具体例を示す図（その３）である。 サーバ配置の遷移の具体例を示す図（その４）である。 サーバ配置の遷移の具体例を示す図（その５）である。 有向グラフのモデルを示す概念図である。 ノード間の距離の具体例を示す図である。 アルゴリズム１のフローチャートを示す図（その１）である。 アルゴリズム１のフローチャートを示す図（その２）である。 アルゴリズム１の具体例を示す図である。 図１９の各状態でのサーバの状態を示す図である。 アルゴリズム２の計算例でリソースが一つの場合を示す図である。 アルゴリズム２の計算例でリソースが二つの場合を示す図である。 アルゴリズム３の手順の具体例を示す図（その１）である。 アルゴリズム３の手順の具体例を示す図（その２）である。 アルゴリズム３の手順の具体例を示す図（その３）である。 アルゴリズム３の手順の具体例を示す図（その４）である。

符号の説明

１ 初期ノード（ノード１）
２ 中間ノード（ノード２）
３ 中間ノード（ノード３）
４ 最終ノード（ノード４）
５ 最終ノード（ノード５）
６ 中間ノード（ノード６）
７ 最終ノード（ノード７）
２ａ ノード２からノード１への遷移
３ａ ノード３からノード２への遷移
４ａ ノード４からノード１への遷移
５ａ ノード５からノード１への遷移
６ａ ノード６からノード１への遷移
７ａ ノード７からノード１への遷移
１０ ステージング・エンジン
２０ プロビジョニング・マネージャ
３０ データ・センター

Claims (13)

1. 複数のサービスが必要とするリソースの割り当てについてシミュレーションを行うプロビジョニングの方法であって、
   前記複数のサービスが共有するリソース・プール内に前記プロビジョニングの過程における中間状態として一または複数のステージを設けるステージング段階と、
   一または複数の前記リソースの状態を、一または複数の前記ステージに初期状態として割り当てる段階と、
   割り当てられた前記リソースの状態を他の前記ステージに遷移させるために要する設定作業時間に基づいて、所定のアルゴリズムによる所定のコストを算出し、前記所定のコストが最小となるように全ての前記リソースを各前記ステージに配置する段階と、
   を備える、プロビジョニング方法。
2. 前記ステージング段階は、各前記ステージをノードとし、前期設定作業時間をエッジの重みとする有向グラフを作成することによる、請求項１に記載のプロビジョニング方法。
3. 前記所定のコストは、あるサービスからのリソース要求発生による該リソースの該サービスへのデプロイ完了までに要する時間と、該サービスにデプロイが遅れることによるペナルティの積によって決定される、請求項２に記載のプロビジョニング方法。
4. 前記所定のアルゴリズムは、前記サービスごとのリソース要求発生分布を元にしたシミュレーションによって、現在の全てのリソース割り当てパターンから、前記所定のコストが最小となる一手先あるいは、二手以上先の全てのリソースのステージへの割り当てパターンを見つける、請求項３に記載のプロビジョニング方法。
5. 前記所定のアルゴリズムは、全てのリソースのステージへの割り当てパターンごとに、次の式で求められる期待値Ｅ（Ｓ）を算出し、
   

   

   前記期待値Ｅ（Ｓ）が最小となる全てのリソースのステージへの割り当てパターンを見つけ、
   現在のリソース配置から当該割り当てパターンのリソース配置ヘの遷移を、グラフ・マッチング問題を用いることにより決定する、請求項３に記載のプロビジョニング方法。
6. 前記所定のアルゴリズムは、全てのリソースのステージへの割り当てパターンと全てのサービスごとに、次の式で求められるＥ（Ｓ，Ｘ）を算出し、
   

   

   さらに前記Ｅ（Ｓ，Ｘ）を全てのサービスＸについて総和である期待値Ｅ（Ｓ）を求め、前記期待値Ｅ（Ｓ）が最小となる全てのリソースのステージへの割り当てパターンを見つけ、
   現在のリソース配置から当該割り当てパターンのリソース配置ヘの遷移を、グラフ・マッチング問題を用いることにより決定する、請求項３に記載のプロビジョニング方法。
7. 前記シミュレーションは、リソース要求を特定の確率分布によって発生させる、請求項４に記載のプロビジョニング方法。
8. 複数のサービスが必要とするリソースの割り当てについてシミュレーションを行うプロビジョニングのステージング・エンジンであって、
   前記ステージング・エンジンは、
   前記サービスが共有するリソース・プール内に、前記プロビジョニングの過程における中間状態として一または複数のステージを設け、前記ステージをノード、前記ノード間の遷移をエッジとするグラフを作成するグラフ作成部と、
   所定のアルゴリズムによる所定のコストが最小となるように、前記リソース・プール中の全ての前記リソースの状態の配置を求める遷移計画部と、
   前記遷移計画部が発行した遷移計画に基づいて、リソース遷移処理要求の発行を行う遷移要求発行部と、
   外部からのイベントを待つ、イベント処理部と、
   前記イベントがサービス・リクエストの場合、要求を発生した該サービスに最も近い前記ノードを求めるデプロイ部と、
   を備える、ステージング・エンジン。
9. 前記遷移計画部は、
   割り当てられた前記リソースの状態を他の前記ノードに遷移させるために要する設定作業時間の入力を受け取る機能と、
   前記設定作業時間に基づいて、所定のアルゴリズムによる所定のコストを算出する機能と、
   を備える、請求項８に記載のステージング・エンジン。
10. 前記サービス・リクエストは、リソース要求、遷移処理完了、または、前記リソース・プールへのリソースの追加・削除のいずれかである、請求項８に記載のステージング・エンジン。
11. 請求項８乃至１０のいずれかに記載の前記ステージング・エンジンを含むプロビジョニング・システムであって、前記ステージング・エンジンからの前記リソース遷移処理要求に応じて、前記リソースの設定作業を実行するプロビジョニング・マネージャを更に含む、プロビジョニング・システム。
12. 複数のサービスが必要とするリソースの割り当てのためのシミュレーションを行うプロビジョニングをコンピュータに実行させるコンピュータ・プログラムであって、
    前記サービスが共有するリソース・プール内に前記プロビジョニングの過程における中間状態として一または複数のステージを設けるステージング機能と、
    一または複数の前記リソースの状態を、一または複数の前記ステージに、初期状態として割り当てる機能と、
    割り当てられた前記リソースの状態を他の前記ステージに遷移させるために要する設定作業時間に基づいて、所定のアルゴリズムによる所定のコストを算出し、前記所定のコストが最小となるように全ての前記リソースを各前記ステージに配置する機能と、
    をコンピュータに実行させる、コンピュータ・プログラム。
13. 請求項１２に記載のコンピュータ・プログラムを格納する記憶媒体。

Images