(57)【要約】  コンピューティングリソースの割り振りは、アプリケーションプログラムによるリソースの利用について設定されたサービスレベル要件に基づいてリソースの量をアプリケーションプログラムへ割り振ること、アプリケーションプログラムのリソース利用が利用閾値を超過しているかどうかを決定すること、及びアプリケーションプログラムのリソース利用が利用閾値を超過しているとの決定に応答してリソースの割り振られた量を変更することを備える。利用閾値は、設定されたサービスレベル要件に基づいており、設定されたサービスレベル要件とは異なる。利用閾値に基づいてリソースの割り振りを変更するにより、アプリケーションプログラムのサービスレベル契約の違反に先立って十分なリソースをアプリケーションプログラムへ割り振ることが可能になる。
2011503713.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティングリソースを割り振るコンピュータ実現方法であって、
アプリケーションプログラムによるリソースの利用について設定されたサービスレベル要件に基づいて前記リソースの量を前記アプリケーションプログラムへ割り振るステップと、
前記アプリケーションプログラムのリソース利用が利用閾値を超過するかどうかをコンピュータ上で決定するステップであって、前記利用閾値は、前記設定されたサービスレベル要件に基づいており、前記設定されたサービスレベル要件とは異なっているステップと、
前記アプリケーションプログラムのリソース利用が前記利用閾値を超過するとの決定に応答して、コンピュータを介して前記リソースの前記割り振られた量を変更するステップと、
を備える方法。
【請求項２】
前記割り振りステップで割り振られた前記リソースの前記量が、前記リソースの前記サービスレベル要件に等しい、請求項１に記載の方法。
【請求項３】
前記割り振りステップで割り振られた前記リソースの前記量が、前記リソースの前記サービスレベル要件よりも少ない、請求項１に記載の方法。
【請求項４】
前記変更ステップが、前記サービスレベル要件を超過する前記アプリケーションプログラムのリソース利用に先立って起こる、請求項１に記載の方法。
【請求項５】
前記変更ステップが、前記リソースの追加の量を前記アプリケーションプログラムへ割り振ることを備え、前記アプリケーションプログラムへ割り振られた前記リソースの総量が、前記サービスレベル要件よりも少ないか等しい、請求項１に記載の方法。
【請求項６】
前記変更ステップが、前記リソースの追加の量を前記アプリケーションプログラムへ割り振ることを備え、前記アプリケーションプログラムへ割り振られた前記リソースの総量が前記サービスレベル要件よりも多い、請求項１に記載の方法。
【請求項７】
前記変更ステップが、前記アプリケーションプログラムへ割り振られる前記リソースの追加の量を取得するため、他のプログラムへ割り振られた前記リソースの量を低減することを備える、請求項１に記載の方法。
【請求項８】
前記変更ステップが、前記アプリケーションプログラムの前記サービスレベル要件に基づいて十分な能力を取得するため、前記アプリケーションプログラムを異なるリソースへ移行することを備える、請求項１に記載の方法。
【請求項９】
前記変更ステップが、前記アプリケーションプログラムの前記サービスレベル要件に基づいて十分な能力を取得するため及びアプリケーションプログラムのファミリーに順応するため、前記アプリケーションプログラムを含めてアプリケーションプログラムの前記ファミリーを異なるリソースへ移行することを備える、請求項１に記載の方法。
【請求項１０】
前記リソースの前記割り振られた量の変更に応答して、前記リソースの電力又は冷却要件を調節するステップを更に備える、請求項１に記載の方法。
【請求項１１】
前記変更ステップが、取引市場モデルに基づく、請求項１に記載の方法。
【請求項１２】
複数のリソース及び複数のアプリケーションプログラムについて、割り振り、決定、及び変更ステップを反復することを更に備える、請求項１に記載の方法。
【請求項１３】
請求項１に記載のコンピュータ実現方法を実行するコンピュータ実行可能命令を有するコンピュータ読み取り可能メディア。
【請求項１４】
コンピューティングリソースを割り振るシステムであって、
アプリケーションプログラムによるリソースの利用について設定されたサービスレベル要件に基づいて前記リソースの量を前記アプリケーションプログラムへ初期に割り振るリソース割り振りマネージャと、
前記アプリケーションプログラムのリソース利用が利用閾値を超過するかどうかを決定し、前記利用閾値は、前記設定されたサービスレベル要件に基づいており、前記設定されたサービスレベル要件とは異なっているサービス品質（「ＱＯＳ」）マネージャと
を備え、
前記リソース割り振りマネージャは、前記アプリケーションプログラムのリソース利用が前記利用閾値を超過しているとの決定に応答して、前記リソースの前記割り振られた量を更に変更する、システム。
【請求項１５】
前記アプリケーションプログラムのリソース利用を監視し、前記アプリケーションプログラムのリソース利用を前記ＱＯＳマネージャへ通信する監視モジュールを更に備える、請求項１４に記載のシステム。
【請求項１６】
前記アプリケーションプログラムへ割り振られた前記リソースの前記初期量が、前記リソースの前記サービスレベル要件と等しい、請求項１４に記載のシステム。
【請求項１７】
前記アプリケーションプログラムへ割り振られた前記リソースの前記初期量が、前記リソースの前記サービスレベル要件よりも少ない、請求項１４に記載のシステム。
【請求項１８】
前記リソース割り振りマネージャは、前記アプリケーションプログラムの前記リソースの利用が前記サービスレベル要件を超過することに先立って、前記リソースの前記割り振られた量を変更する、請求項１４に記載のシステム。
【請求項１９】
前記リソース割り振りマネージャは、前記リソースの追加の量を前記アプリケーションプログラムへ割り振ることによって前記リソースの前記割り振られた量を変更し、前記アプリケーションプログラムへ割り振られた前記リソースの総量が前記サービスレベル要件よりも少ないか等しい、請求項１４に記載のシステム。
【請求項２０】
前記リソース割り振りマネージャは、前記リソースの追加の量を前記アプリケーションプログラムへ割り振ることによって前記リソースの前記割り振られた量を変更し、前記アプリケーションプログラムへ割り振られた前記リソースの総量が前記サービスレベル要件よりも多い、請求項１４に記載のシステム。
【請求項２１】
前記リソース割り振りマネージャは、前記アプリケーションプログラムへ割り振られる前記リソースの追加の量を取得するため、他のプログラムへ割り振られた前記リソースの量を低減することによって前記リソースの前記割り振られた量を変更する、請求項１４に記載のシステム。
【請求項２２】
前記リソース割り振りマネージャは、前記アプリケーションプログラムの前記サービスレベル要件に基づいて十分な能力を取得するため、前記アプリケーションプログラムを異なるリソースへ移行することによって前記リソースの前記割り振られた量を変更する、請求項１４に記載のシステム。
【請求項２３】
前記リソース割り振りマネージャは、前記アプリケーションプログラムの前記サービスレベル要件に基づいて十分な能力を取得してアプリケーションプログラムのファミリーに順応するため、前記アプリケーションプログラムを含めてアプリケーションプログラムの前記ファミリーを異なるリソースへ移行することによって前記リソースの前記割り振られた量を変更する、請求項１４に記載のシステム。
【請求項２４】
前記リソース割り振りマネージャが前記リソースの前記割り振られた量を変更することに応答して、前記リソースについて電力を調節する電力調節システムを更に備える、請求項１４に記載のシステム。
【請求項２５】
前記リソース割り振りマネージャが前記リソースの前記割り振られた量を変更することに応答して、前記リソースについて冷却を調節する冷却調節システムを更に備える、請求項１４に記載のシステム。
【請求項２６】
前記リソース割り振りマネージャは、取引市場モデルに基づき前記リソースを割り振る取引市場を備える、請求項１４に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散されたコンピューティングリソースの割り振り及び管理に関する。より具体的には、本発明は、アプリケーションプログラムのサービスレベル契約の違反に先立ってリソースの割り振りを修正するため、利用可能なリソースの動的監視及び割り振り並びに利用可能なリソースの管理に関する。
【０００２】
（関連出願）
本特許出願は、２００７年１１月６日に出願された「サービス品質、サービスレベル契約マネージャ」と題する米国仮特許出願第６０／９８５，９１５号への、米国特許法第１１９条のもとでの優先権を主張する。本特許出願は、２００７年９月１１日に出願された「仮想リソース市場を介するリソースの経済的割り振り及び管理」と題する米国特許出願第１１／９００，４２４号にも関連する。この米国特許出願第１１／９００，４２４号は、２００７年３月２７日に出願された「仮想リソース市場を介するリソースの経済的割り振り及び管理」と題する米国仮特許出願第６０／９０８，３５０号への、米国特許法第１１９条のもとでの優先権を主張する。上記の識別された優先権及び関連出願の各々の完全な開示は、ここで参照して本明細書に全面的に組み入れられる。
【背景技術】
【０００３】
企業組織では、多数のアプリケーションプログラムを作動させるために、分散されたコンピューティングリソース、例えば、計算リソース、ネットワークリソース、及び記憶リソースが提供される。分散されたコンピューティングリソースは、１つの一般的な場所において提供されてもよい。この場合、リソースは１つ又は複数のローカル・エリア・ネットワークを介して通信する。あるいは、分散されたコンピューティングリソースは、幾つかの場所において提供されてもよい。この場合、リソースは１つ又は複数のローカル・エリア・ネットワーク及び１つ又は複数の広域ネットワーク、例えば、インターネットを介して通信する。
【０００４】
分散されたコンピューティングリソースは、アプリケーションプログラムの作動を調整するため、これらのプログラムの間で割り振られ得る。例えば、計算リソース、ネットワークリソース、及び記憶リソースは、各アプリケーションプログラムへ割り振られ、各アプリケーションプログラムは、その作動について、その割り振られたリソースを利用し得る。しかしながら、従来の割り振り方法は、特定のリソースが現在十分に利用されていないかどうか、及び追加のアプリケーションプログラムの作動を調整できるかどうかに基づいて、特定のリソースをアプリケーションプログラムへ割り振る。このようにして、追加のアプリケーションプログラムの作動は、リソースがその最大能力又はこれを超えて利用されるまで、リソースへ追加される。
【０００５】
リソースのそのような従来の割り振りは、ビジネス又は作動優先順位、又は作動要件、又はアプリケーションプログラムのサービス品質に対して責任を負わない。従って、高優先順位のアプリケーションプログラムより前に低優先順位のアプリケーションプログラムが最初にアドレスされたという単純な理由で、限定された価値あるリソースが、高優先順位のアプリケーションの代わりに低優先順位のアプリケーションプログラムへ割り振られるかも知れない。追加的に、リソースのそのような従来の割り振りは、アプリケーションプログラムによって又はアプリケーションプログラムのユーザによって特定のリソースへ付与された値に基づくリソースの経済効率的分散を生じない。故に、従来の方法を介して割り振られたリソースは十分に利用されない。なぜならば、それらのリソースは、割り振られたリソースの特定の性能特性を十分に利用できないアプリケーションプログラムによって消費されるからである。あるいは、従来の方法を介して割り振られたリソースは、十分に性能を発揮しない。なぜなら、それらのリソースは、割り振られたリソースの性能特性よりも精緻な性能特性を要求するアプリケーションプログラムによって消費されるからである。
【０００６】
更に、従来のリソース割り振り方法では、リソースの効率的及び／又は経済的分散を維持するために、又はサービスレベル契約の違反を予想及び防止するために、リソースが動的に再割り振りされることはない。一度、リソースがアプリケーションプログラムへ最初に割り振られると、アプリケーションプログラムはそれらのリソースの上で無限に作動する。益々多くのアプリケーションプログラムの作動がリソースへ追加されるにつれて、リソースが過度に利用されるようになったとき、従来の解決法はより多くのリソースを購入することである。その従来の解決法は、既存のリソースの未使用能力を発見するため、既存のリソースを再割り振りすることを考慮していない。その従来の解決法は、プログラムの作動を一層適切なリソースへ動的に移行する必要性もまた考慮していない。追加的に、従来の解決法は、リソースを利用しているアプリケーションプログラムに関連づけられたサービスレベル契約のサービスレベル要件をリソースが満たせなくなるまで、それらのリソースを再割り振りしない。従って、サービスレベル契約が既に違反されてしまうまで、追加的又は代替的なリソースはアプリケーションプログラムへ割り振られない。
【０００７】
従って、アプリケーションプログラムの間でリソースを効率的に割り振る必要性が、当技術分野に存在する。アプリケーションプログラムに関連づけられたサービスレベル契約の違反に先立って、一層適当なリソースの新しい割り振りを可能にするため、アプリケーションプログラムの間で割り振られたリソースの利用を監視する必要性が更に存在する。
【発明の概要】
【０００８】
本発明は、割り振られたリソースを利用しているアプリケーションプログラムに関連づけられたサービスレベル契約に違反することなく、適当なリソース割り振りを維持するため、分散されたコンピューティングリソースを割り振り及び管理する方法及びシステムを含む。本発明は、サービスレベル契約の潜在的な将来の違反を予想することができ、サービスレベル契約の違反を防止して要件を満たすため、追加又は代替のリソースをアプリケーションプログラムへ割り振ることができる。１つの態様において、高優先順位のアプリケーションプログラムに関連づけられたサービスレベル契約の違反を防止するため、低優先順位のアプリケーションプログラムへ割り振られたリソースは、高優先順位のアプリケーションプログラムへシフトされ得る。他の態様において、特定のアプリケーションプログラムに関連づけられたサービスレベル契約への違反を防止するため、特定のアプリケーションプログラム、又はその特定のアプリケーションプログラムを含むアプリケーションプログラムのファミリーが、代替のリソースへ移行され得る。
【０００９】
更に他の態様において、アプリケーションプログラムに関連づけられたサービスレベル契約の中に記述されたサービスレベル要件への順守を保証するため、リソースが監視される。アプリケーションプログラムによる特定のリソースの利用が、アプリケーションプログラムへ現在割り振られている特定のリソースの量よりも低い所定の閾値をいつ超過するかを決定するため、リソースが監視される。利用が閾値を超過するとき、追加又は代替のリソースがアプリケーションプログラムへ割り振られ、これにより割り振られた量を超過する利用に先立って十分なリソースを割り振る。これはサービスレベル要件に基づいており、従ってアプリケーションプログラムに関連づけられたサービスレベル契約の違反に先立つ。
【００１０】
更に他の態様では、リソース割り振りの後でリソースの電力及び／又は冷却要件が調節され得る。もし特定のリソースの割り振られた量が増加又は減少されるならば、そのリソースへ提供された電力及び／又は冷却の量が、それに従って調節され得る。もしアプリケーションプログラムが当初のリソースから代替のリソースへ移行されるならば、電力及び／又は冷却は、当初のリソースについて減少され、代替のリソースについて増加され得る。従って、増加されたエネルギー効率及びコスト節減が達成され得る。
【００１１】
追加的に、本発明は取引市場モデルを介して、分散されたコンピューティングリソースを割り振り及び管理する方法及びシステムを含む。取引市場モデルの利用は、アプリケーションプログラムによって使用されるリソースの効率的及び経済的割り振りを生じ得る。リソースは、各リソースの単位に対する市場価格に基づいて割り振られ得る。従って、アプリケーションプログラムによって使用されるリソースを提供するオファーが創出され得る。ここで各オファーは、対応するリソース単位に関連づけられた少なくとも１つの性能特性及び値を指定する。アプリケーションプログラムによって使用されるリソースを取得するビッドも創出される。各ビッドは、対応するアプリケーションプログラムの作動に要求される少なくとも１つのサービスレベル及び対応するアプリケーションプログラムの作動に関連づけられた認識価値又は対応するアプリケーションプログラムのサービスレベル要件を満たすか超過するリソースを取得する認識価値に対応する値を指定する。ビッドは、各ビッドのサービスレベル要件及び値を、オファーの１つの性能特性及び値にマッチさせることによって、取引市場モデルを介してオファーへマッチさせられる。次いで、各オファーに関連づけられたリソースは、マッチするビッドに関連づけられたアプリケーションプログラムへ割り振られ、アプリケーションプログラムの作動は、割り振られたリソースへ移行される。各ビッドのサービスレベル要件への順守を保証するためリソースが監視され、順守していないリソースは取引市場モデルを介して置換される。
【００１２】
分散コンピューティング環境においてリソースを割り振られた各アプリケーションプログラムについて、性能監視が実行され得る。このようにして、リソースがアプリケーションプログラムのサービスレベル要件を満たすことを保証するため、割り振られたリソースの性能が連続的又は定期的に監視される。もしリソースが、要求されるサービスレベルを提供していないならば、サービスレベル要件を満たすリソースを取得するため、新しいビッドが創出されて取引市場へ提出され得る。追加的に、このようにして、アプリケーションプログラムのユーザが未使用リソース（言い換えれば、リソースの過剰能力）に対して支払っていることを示す量だけリソースの性能がサービスレベル要件を超過していないことを保証するため、割り振られたリソースの性能が連続的又は定期的に監視される。もしリソースがアプリケーションプログラムによって十分に利用されていなければ、アプリケーションプログラムのサービスレベル要件に関して一層適切及び／又は経済的なリソースを取得するため、新しいビッドが創出されて取引市場へ提出され得る。
【００１３】
こうして、割り振られたリソースが十分利用されていないか性能を十分発揮していないかどうかを決定するため、それらのリソースの性能が監視され得る。もしそうであれば、新しいリソースが識別されてアプリケーションプログラムへ割り振られ、アプリケーションプログラムの作動が新しいリソースへ移行され、これによってアプリケーションプログラムのために適正な性能のリソースを提供し得る。
【００１４】
リソースが或る期間にわたって前述したように割り振られた後、リソースを管理するため、割り振られたリソースに関連した情報が使用され得る。関連する期間の間、リソースによって生成された実際又は理想的収入から、各リソースの実際又は理想的コスト及び費用を減じることによって、各リソースの利益及び損失情報が生成される。所有者はどのリソースに投資すべきか、所有者はその現在のポジションをどのリソースで維持すべきか、及び所有者はどのリソースを売却すべきかを決定するため、利益及び損失情報が比較される。所有者は、利益を生み出しているリソースに投資し、損失を発生しているリソースを売却し得る。
【００１５】
従って、所有者又はユーザは、価格及び性能を含めて、どのリソースが最も経済的であるかを決定するため、物理的リソースを評価し得る。例えば、計算リソースは様々なプラットフォームを備えることができ、プラットフォームの各々は異なる価格及び性能特性を有する。期間についての各リソースの利益及び損失計算書の比較は、どのプラットフォームが性能単位当たりより多くの収入を発生しているかを示す。この情報に基づいて、所有者は、どのプラットフォームを維持すべきか、又はどのプラットフォームで所有者のポジションを増加すべきか、及びどのプラットフォームを売却すべきかを決定し得る。リソースは前述したようにして割り振られているので、評価は、アプリケーションプログラムによって使用されるためにはどのリソースが一層望ましいかの表示を価格及び性能特性に基づいて提供する。
【００１６】
本発明のこれら及び他の態様、目的、及び特徴は、添付の図面と併せて読まれ及び添付の図面を参照する例示的実施形態の次の詳細な説明から明らかになるであろう。
【図面の簡単な説明】
【００１７】
【図１】本発明の例示的実施形態に従って、分散されたコンピューティングリソースを割り振り及び管理するシステムを描いたブロック図である。
【図２】本発明の例示的実施形態に従って、分散されたコンピューティングリソースを割り振り及び管理する方法を描いたフローチャートである。
【図３】本発明の例示的実施形態に従って、各仮想リソースについて性能単位当たりの指定価格で利用可能仮想リソースを提供するオファーを創出する方法を描いたフローチャートである。
【図４】本発明の例示的実施形態に従って、アプリケーションプログラムの作動に要求されるサービスレベル要件を識別する方法を描いたフローチャートである。
【図５】本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル要件を満たすために要求されるリソースの単位を取得するビッドを創出する方法を描いたフローチャートである。
【図６】本発明の例示的実施形態に従って、アプリケーションプログラムによって使用される仮想リソースを取得するため、リソースオファーを要件ビッドにマッチさせる方法を描いたフローチャートである。
【図７】本発明の例示的実施形態に従って、マッチするリソースオファー及び要件ビッドに基づきアプリケーションプログラムの作動に要求されるリソースを購入する取引を完了する方法を描いたフローチャートである。
【図８】本発明の例示的実施形態に従って、アプリケーションプログラムの作動を、購入されたリソースへ移行する方法を描いたフローチャートである。
【図９】本発明の例示的実施形態に従って、割り振られたリソースの性能及びアプリケーションプログラムのサービスレベル要件を監視する方法を描いたフローチャートである。
【図１０】本発明の例示的実施形態に従って、アプリケーションプログラムの分散されたコンピューティングリソースの再割り振りを描いたブロック図である。
【図１１】本発明の例示的実施形態に従って、或る期間にわたるリソース割り振りに基づいてリソースの維持、獲得、及び／又は売却を管理する方法を描いたフローチャートである。
【図１２】本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル契約に基づきリソース要件を管理する方法を描いたフローチャートである。
【図１３】本発明の例示的実施形態に従って、アプリケーションプログラムに関連づけられたサービスレベル契約の違反に先立ってアプリケーションプログラムの選択されたリソースの割り振りを修正する方法を描いたフローチャートである。
【図１４】本発明の例示的実施形態に従って、割り振られたリソースの変更に基づき当初及び代替リソースの冷却及び電力要件を調節する方法を描いたフローチャートである。
【図１５】本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル契約に基づきリソース要件を管理するシステムを描いたブロック図である。
【発明を実施するための形態】
【００１８】
同様の番号は同様の要素を表す図面を参照して、例示的実施形態の態様が説明される。
【００１９】
図１は、本発明の例示的実施形態に従って、分散されたコンピューティングリソースを割り振り及び管理するシステム１００を描いたブロック図である。システム１００は、図２〜図９及び図１１に示された方法を参照してより詳細に論議される。
【００２０】
図２は、本発明の例示的実施形態に従って、分散されたコンピューティングリソースを割り振り及び管理する方法２００を描いたフローチャートである。方法２００は、図１及び図２を参照して説明される。
【００２１】
１つの例示的実施形態によれば、分散されたコンピューティングリソースは、企業組織のリソースであり得る。この場合、リソースのユーザは組織の構成員である。あるいは、分散されたコンピューティングリソースは、そのリソースを割り振る中央システムに結合された多数の組織のリソースであり得る。
【００２２】
図２のステップ２０５で示されるように、リソース仲介者１０２は、１つ又は複数のアプリケーションプログラムを作動させるために利用可能なリソース能力を識別するため、コンピューティングサービスを提供する分散されたコンピューティングリソースを監視する。例示的実施形態において、分散されたコンピューティングリソースは、物理コンピューティングリソース１０３、例えば、計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８を備え得る。計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８の各々は、サービスを提供するように構成された１つ又は複数の仮想リソース１０９を備え得る。例えば、図１に示されるように、計算構造１０４は仮想計算構造Ｃ１及びＣ２を備え、ネットワーク構造１０６は仮想ネットワーク構造Ｎ１及びＮ２を備え、記憶構造１０８は仮想記憶構造Ｓ１及びＳ２を備える。
【００２３】
例示的実施形態において、リソース仲介者１０２は、分散されたコンピューティング環境で作動して仮想リソース１０９と取引市場１１２との間のインタフェースとして機能するソフトウェアモジュールを備え得る。
【００２４】
ステップ２１０において、リソース仲介者１０２は、各リソースについて性能単位当たりの指定価格で利用可能仮想リソース１０９を提供するオファーを創出する。そのようなオファーは、本明細書では「リソースオファー１１０」１１０と呼ばれる。構造１０４、１０６、１０８の各々について、１つ又は複数のリソースオファー１１０が創出され得る。例えば、図１に示されるように、リソースオファー１１０は、計算構造Ｃ１の３つのオファー、計算構造Ｃ２の２つのオファー、ネットワーク構造Ｎ１の３つのオファー、ネットワーク構造Ｎ２の２つのオファー、記憶構造Ｓ１の３つのオファー、及び記憶構造Ｓ２の２つのオファーを備える。ステップ２１０は、この後で図３を参照して更に詳細に説明される。
【００２５】
次いで、ステップ２１５において、リソース仲介者１０２は、リソースオファー１１０を取引市場１１２へ通信する。例示的実施形態において、取引市場１１２は、分散されたコンピューティング環境で作動してリソース仲介者１０２と要件仲介者１１４との間のインタフェースとして機能するソフトウェアモジュールを備え得る。
【００２６】
ステップ２２０において、要件仲介者１１４はアプリケーションプログラムの作動に要求されるサービスレベルリソース要件を識別する。例示的実施形態において、要求されたリソースは、コンピューティング、ネットワーク、及び記憶リソース、例えば、図１に示される１つ又は複数の計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８を備え得る。アプリケーションプログラムは、良好に確立されたアーキテクチャ、例えば、正統的アプリケーションアーキテクチャ１１６に適合し得る。図１に示される例示的な正統的アプリケーションアーキテクチャは、正統的アーキテクチャＡとして示されるメッセージハブ、正統的アプリケーションアーキテクチャＢとして示されるｎ階層アプリケーション、及び正統的アプリケーションアーキテクチャＣとして示される計算施設を備える。他のアプリケーションアーキテクチャは本発明の範囲の中に含まれる。ステップ２２０は、この後で図４を参照して更に詳細に説明される。
【００２７】
例示的実施形態において、要件仲介者１１４は、分散されたコンピューティング環境で作動してアプリケーションプログラムと取引市場１１２との間のインタフェースとして機能するソフトウェアモジュールを備え得る。
【００２８】
ステップ２２５において、アプリケーションプログラムのサービスレベル要件を満たすために要求されるリソースの単位を購入するビッドが創出される。そのようなビッドは、本明細書では「要件ビッド１１８」と呼ばれる。１つ又は複数の要件ビッド１１８が各アプリケーションプログラムについて創出され得る。例えば、図１に示されるように、要件ビッド１１８は各正統的アーキテクチャＡ、Ｂ、Ｃについて計算構造へのビッド、ネットワーク構造へのビッド、及び記憶構造へのビッドを備える。ステップ２２５は、この後で図５を参照して更に詳細に説明される。
【００２９】
ステップ２３０において、要件仲介者１１４は要件ビッド１１８を取引市場１１２へ通信する。次いで、ステップ２３５において、取引市場１１２は、各アプリケーションプログラムへのリソースの経済的及び効率的割り振りを決定するため、リソースオファー１１０を要件ビッド１１８へマッチさせる。ステップ２３５は、この後で図６を参照して更に詳細に説明される。
【００３０】
ステップ２４０において、取引市場１１２は、マッチするオファー及びビッドに基づきアプリケーションプログラムに要求されるリソースを割り振る取引を完了する。ステップ２４０は、この後で図７を参照して更に詳細に説明される。
【００３１】
ステップ２４５において、アプリケーションプログラムの作動は、割り振られたリソースへ移行される。ステップ２４５は、この後で図８を参照して更に詳細に説明される。
【００３２】
ステップ２５０において、要件仲介者１１４は、割り振られたリソースの性能が、各アプリケーションプログラムのサービスレベル要件を満たすことを保証するため、割り振られたリソースの性能及び各アプリケーションプログラムのサービスレベル要件を監視する。ステップ２５０は、この後で図１０を参照して更に詳細に説明される。
【００３３】
ステップ２５５において、ステップ２５０で完了された性能監視に基づき、要件仲介者１１４は、割り振られたリソースが、特定のアプリケーションプログラムのサービスレベル要件に関して十分に利用されていないか又は十分に性能を発揮していないかを決定する。もしイエスであれば、方法２００は、アプリケーションプログラムのサービスレベル要件を満たす新しいリソースを取得するため、ステップ２２５へ戻る。もし要件仲介者１１４が、ステップ２５５において、割り振られたリソースがアプリケーションプログラムのサービスレベル要件を満たしていると決定するならば、方法はステップ２６０へ分岐する。
【００３４】
ステップ２６０において、方法２００は、アプリケーションプログラムの作動が完了しているかどうかを決定する。もし完了していなければ、方法２００は、割り振られたリソースの性能及びアプリケーションプログラムのサービスレベル要件の監視を継続するため、ステップ２５０へ戻る。もし方法２００が、ステップ２６０において、アプリケーションプログラムの作動が完了していると決定するならば、方法２００は、割り振られたリソースからアプリケーションプログラムの作動が除去されるステップ２６５へ分岐する。
【００３５】
方法２００は、図１のステップ２７０で示されるように、所定の期間にわたるリソース割り振りに基づいてリソースの維持、獲得、及び売却を管理することを更に含む。ステップ２７０は、この後で図１１を参照して更に詳細に説明される。
【００３６】
図３は、図２のステップ２１０において参照されたように、本発明の例示的実施形態に従って、各仮想リソース１０９について性能単位当たりの指定価格で利用可能仮想リソース１０９を提供するオファーを創出する方法２１０を描いたフローチャートである。方法２１０は、図１及び図３を参照して説明される。
【００３７】
ステップ３０５において、リソース仲介者１０２は、アプリケーションプログラムによる使用に利用可能な物理的リソース１０３を選択する。例えば、リソース仲介者１０２は計算、ネットワーク、又は記憶リソース、例えば、計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８を選択し得る。例示的実施形態において、リソース仲介者１０２は、利用されていない各リソースの過剰能力を識別するため、各リソースの使用を監視し得る。そのような過剰能力は、アプリケーションプログラムによる使用に利用可能なリソースとして識別され得る。
【００３８】
次いで、ステップ３１０において、リソース仲介者１０２は、アプリケーションプログラムによる使用に利用可能な、選択された物理的リソース１０３の量を識別する。例示的実施形態において、各リソースの量は、特定の製造者及び／又はコンポーネントを含めてハードウェアタイプ及び／又は構成、並びに各リソースの現在利用可能な過剰能力を備え得る。この点に関して、利用可能な物理的リソース１０３は、仮想リソース１０９、例えば、仮想計算構造Ｃ１及びＣ２、仮想ネットワーク構造Ｎ１及びＮ２、及び仮想記憶構造Ｓ１及びＳ２を創出するため、組み合わせられ得る。例えば、分散された場所で利用可能なコンピュータプロセッサは、アプリケーションプログラムによる使用に利用可能な仮想コンピューティングリソースを創出するため、統合され得る。代表的リソース能力は、コンピューティングリソースについてＣＰＵサイクル、ネットワークリソースについて帯域幅、及び記憶リソースについてディスクスペース及び／又はメモリを備え得る。
【００３９】
利用可能なリソースの量は、各仮想リソース１０９に関連づけられた性能及び信頼度特性を更に備え得る。例えば、そのような特性は、実行時間、応答時間、結果の正確度（例えば、故障率）、利用可能性、信頼度、セキュリティ、又は仮想リソース１０９の性能を示す他の適切な特性を備え得る。
【００４０】
ステップ３１５において、リソース仲介者１０２は、アプリケーションプログラムによって使用される仮想リソース１０９を提供するため、オファーの中に含めるべき仮想リソース１０９の単位量を識別する。この点に関して、リソース仲介者１０２は、利用可能な仮想リソース１０９の最大量に達するまで、識別された単位の増分での割り振りに利用可能な、仮想リソース１０９の部分を識別し得る。もしリソース仲介者１０２が、ステップ３１０において、多数の仮想リソース１０９、例えば、仮想計算構造Ｃ１及びＣ２を識別したのであれば、リソース仲介者１０２は各仮想リソース１０９について単位量を識別し得る。
【００４１】
ステップ３２０において、アプリケーションプログラムによって使用される仮想リソース１０９を提供するため、オファーの中に含められる仮想リソース１０９の各単位について、価格が設定される。例示的実施形態において、リソース仲介者１０２は、リソースの精緻性、コストデータ、供給、需要、又はユーザによってリソース仲介者１０２へと入力されるか、完了されたリソース割り振り取引の履歴データに基づいてリソース仲介者１０２によって取得された他の経済データ入力に基づいて、仮想リソース１０９の単位当たりの価格を計算し得る。例えば、より精緻なリソースは、より精緻でないリソースよりも高価であり、高需要のリソースは低需要のリソースよりも高価であり得る。価格は、リソースがアプリケーションプログラムによって使用されるために販売される貨幣量を備え得る。あるいは、値は、実際の貨幣価値に基づかないリソースの認識価値を表し得る。例えば、認識価値は、ビジネス企業の内部で設定されたビジネス要件及び優先順位に基づき得る。
【００４２】
ステップ３２５において、リソース仲介者１０２は、アプリケーションプログラムによって使用される利用可能仮想リソース１０９を提供するため、１つ又は複数のリソースオファー１１０を生成する。リソースオファー１１０は、ステップ３１０〜３２０で取得された情報に基づいて、仮想リソース１０９、利用可能な仮想リソース１０９の量（能力及び性能を含む）、及び仮想リソース１０９の単位価格を指定し得る。
【００４３】
ステップ３３０において、リソース仲介者１０２は、他の仮想リソース１０９についてリソースオファー１１０を生成するかどうかを決定する。例えば、もしリソース仲介者１０２が、利用可能な計算構造１０４についてのみリソースオファー１１０を生成したのであれば、リソース仲介者１０２は、利用可能なネットワーク及び記憶構造１０６及び１０８についてリソースオファー１１０を生成すると決定し得る。この場合、方法２１０は、他のリソースについてリソースオファー１１０を生成するため、ステップ３０５へ戻る。もし方法２１０が、ステップ３３０において、他の仮想リソース１０９についてリソースオファー１１０を生成しないと決定するならば、方法２１０はステップ２１５（図２）へ分岐する。
【００４４】
図４は、図２のステップ２２０において参照されたように、本発明の例示的実施形態に従って、アプリケーションプログラムの作動に要求されるサービスレベル要件を識別する方法２２０を描いたフローチャートである。方法２２０は、図１及び図４を参照して説明される。
【００４５】
ステップ４０５では、アプリケーションプログラムが選択される。次いで、選択されたアプリケーションプログラムに対する特定のサービスレベル要件が、ステップ４１０〜４３５において識別される。
【００４６】
ステップ４１０では、アプリケーションプログラムを作動させるために利用可能な予算が識別される。例示的実施形態において、予算は、アプリケーションプログラムのユーザによって入力され、ユーザの予算制約を満たすように設計され得る。例えば、ユーザは、特定のプログラムに対する公知の財源に基づいて、アプリケーションプログラムの作動に利用可能な予算を入力し得る。他の例示的実施形態において、予算情報はアプリケーションプログラムの作動に関連づけられた値を備え得る。値は、アプリケーションプログラムの作動に必要なリソースを取得するため、ユーザが支払う意思のある貨幣量を備え得る。あるいは、値は、実際の貨幣価値に基づかないアプリケーションプログラムの認識価値を表し得る。例えば、認識価値は、分散されたコンピューティング環境の中で追加のアプリケーションプログラムを作動しているユーザ及び／又は他のユーザに対するアプリケーションプログラムの作動の優先順位に基づき得る。予算制約は、幾つかの代替形式、例えば、コストに関わらず利用可能な最良リソースを取得する命令、最小費用のリソースを取得する命令、指定総価格又はリソースの単位価格でリソースを取得する命令、又は他の適切な予算形式を介してリソースを取得する命令の形式で提供され得る。
【００４７】
ステップ４１５では、アプリケーションプログラムが作動しなければならない期間が識別される。例示的実施形態において、作動期間は、アプリケーションプログラムのユーザによって入力され、ユーザの予算及び顧客サービス制約を満たすように設計され得る。例えば、ユーザは、アプリケーションプログラムが作動しなければならない期間、例えば、２４／７（一日当たり２４時間、一週間に７日）、２４／５（一日当たり２４時間、一週間に５日）、月曜から金曜までの午前８：００〜午後５：００、又はアプリケーションプログラムが作動しなければならない他のいかなる適切な期間を入力し得る。ユーザは、予算制約に基づいて、指定された作動期間を更に調節し得る。例えば、ユーザは、アプリケーションプログラムの作動コストを低減するため、オフピーク期間でのアプリケーションプログラムの作動を指定し得る。
【００４８】
ステップ４２０〜４３５においては、コンピューティングリソース、ネットワークリソース、記憶リソース、及びアプリケーションプログラムを作動させるために要求される他のリソースが、それぞれ決定される。例示的実施形態によれば、ステップ４２０〜４３５は、特定の製造者及び／又はコンポーネントを含めてハードウェアタイプ及び／又は構成、並びに各リソースに要求される能力を識別することを備え得る。要求される代表的リソース能力は、コンピューティングリソースについてＣＰＵサイクル、ネットワークリソースについて帯域幅、及び記憶リソースについてディスクスペース及び／又はメモリを備え得る。ステップ４２０〜４３５は、特定のパラメータ内でアプリケーションプログラムを作動させるため、各々の要求されるリソースについて性能特性を識別することを更に備え得る。例えば、そのような特性は、実行時間、応答時間、結果の正確度（例えば、故障率）、利用可能性、信頼度、セキュリティ、又はリソースの性能を示す他の適切な特性を備え得る。
【００４９】
例示的実施形態において、要件仲介者１１４は、所望されるようにアプリケーションプログラムを作動させるために必要な最小又は最適リソース要件に基づいて、要求されるリソースを決定し得る。この場合、要件仲介者１１４は、この情報をアプリケーションプログラムの仕様から直接取得し得る。あるいは、アプリケーションプログラムのユーザは、１つ又は複数のリソースの量を指定するため、所望の構成可能なセッティングを入力し得る。この点に関して、ユーザは所望のレベルのサービスを提供する特性を入力し、それを要件仲介者１１４はステップ４２０〜４３５において読み取り得る。
【００５０】
例示的実施形態によれば、サービスレベル要件は閾値又は範囲で表現され得る。例えば、要求される応答時間は１秒より少ない時間に設定され得るが、これはリソースの性能がサービスレベル要件の閾値を満たすかどうかの将来の決定を可能にする。代替の例としては、要求される応答時間が、範囲、例えば、０．５秒から１．５秒で設定され得ることである。この場合、リソースの応答時間が指定範囲内に入れば、リソースはそのサービスレベル要件を満たす。性能の閾値及び範囲は、各サービスレベル要件について指定され得る。
【００５１】
ステップ４４０において、方法２２０は、他のアプリケーションプログラムについてサービスレベル要件を識別すべきかどうかを決定する。もしイエスであれば、方法２２０は、サービスレベル要件を識別する他のアプリケーションプログラムを選択するため、ステップ４０５へ戻る。この点に関して、方法２２０は、多数のアプリケーションプログラムについてサービスレベル要件を識別し得る。例えば、図１に示される正統的アーキテクチャＡ、Ｂ、Ｃの１つを利用しているアプリケーションについて、サービスレベル要件が識別され得る。もし方法２２０が、ステップ４４０において、他のアプリケーションプログラムについてサービスレベル要件を識別しないと決定するならば、方法２２０はステップ２２５（図２）へ分岐する。
【００５２】
ステップ４１０〜４３５を参照して説明された特定のサービスレベル要件は、特定のアプリケーションプログラムの特定の要件及びアプリケーションプログラムのユーザ又は分散されたコンピューティングリソースの所有者の特定の要件に依存し得る。従って、サービスレベル要件は、ステップ４１０〜４３５において説明された品目の全部または部分集合を備えてもよく、追加のサービスレベル要件は本発明の範囲の中に含まれる。
【００５３】
図５は、図２のステップ２２５において参照されたように、本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル要件を満たすために要求されるリソースの単位を取得するビッドを創出する方法２２５を描いたフローチャートである。方法２２５は、図１及び図５を参照して説明される。
【００５４】
ステップ５０５において、要件仲介者１１４は、１つ又は複数の要件ビッド１１８を創出する最初のアプリケーションプログラムを選択する。そして、ステップ５１０において、要件仲介者１１４は、選択されたアプリケーションプログラムの作動に要求される最初のリソースを選択する。例えば、要件仲介者１１４は、アプリケーションプログラムの作動に要求される計算、ネットワーク、又は記憶リソースの１つを選択し得る。
【００５５】
ステップ５１５において、要件仲介者１１４は、図４のステップ４１５〜４３５において決定されたサービスレベル要件に基づいて、選択されたリソースについてサービスレベル要件を読み取る。追加的に、ステップ５２０において、要件仲介者１１４は、図４のステップ４１０において決定された予算に基づいて、アプリケーションプログラムを作動させるための予算制約を示す予算情報を読み取る。
【００５６】
次いで、ステップ５２５において、要件仲介者１１４は、サービスレベル要件及び利用可能な予算に基づいて、アプリケーションプログラムの作動について、選択されたリソースを取得するために支払う、選択されたリソースの単位当たりの価格を設定する。例示的実施形態において、要件仲介者１１４は、ユーザによって要件仲介者１１４へと入力されるか、完了されたリソース割り振り取引の履歴データに基づいて要件仲介者１１４によって取得されたコストデータ、供給、需要、又は他の経済データに基づいて、リソースの単位当たり価格を計算し得る。要件仲介者１１４は、コストに関わらず利用可能な最良リソースを取得する命令、最小費用リソースを取得する命令、指定総価格又はリソースの単位当たり価格でリソースを取得する命令、又は予算情報及びアプリケーションプログラムの優先順位に依存して、他の適切な予算形式を介してリソースを取得する命令に基づいて、単位当たり価格を更に設定し得る。
【００５７】
ステップ５３０において、要件仲介者１１４は、選択されたアプリケーションプログラムによって使用される選択されたリソースを取得するため、１つ又は複数の要件ビッド１１８を生成する。要件ビッド１１８は、ステップ５１５〜５２５で取得された情報に基づいて、リソース、リソースが満たさなければならないサービスレベル要件、及びユーザがリソースを取得するために支払う単位価格を指定し得る。前に論議されたように、単位価格は実際の貨幣価値又は認識価値を備え得る。
【００５８】
ステップ５３５において、要件仲介者１１４は、アプリケーションプログラムを作動するために必要な他のリソースについて要件ビッド１１８を生成すべきかどうかを決定する。例えば、もし要件仲介者１１４が計算リソースについてのみ要件ビッド１１８を生成したのであれば、要件仲介者１１４は、ネットワーク又は記憶リソースについて要件ビッド１１８を生成すると決定し得る。この場合、方法２２５は、他のリソースについて要件ビッド１１８を生成するため、ステップ５１０へ戻る。もし方法２２５が、ステップ５３５において、他のリソースについて要件ビッド１１８を生成しないと決定するならば、方法２２５はステップ５４０へ分岐する。
【００５９】
次いで、ステップ５４０において、要件仲介者１１４は、他のアプリケーションプログラムについて要件ビッド１１８を生成すべきかどうかを決定する。もしイエスであれば、方法２２５は、他のアプリケーションプログラムについて要件ビッド１１８を生成するため、ステップ５０５へ戻る。もし方法２２５が、ステップ５４０において、他のアプリケーションプログラムについて要件ビッド１１８を生成しないと決定するならば、方法２２５はステップ２３０（図２）へ分岐する。
【００６０】
図６は、図２のステップ２３５において参照されたように、本発明の例示的実施形態に従って、アプリケーションプログラムによって使用される仮想リソース１０９を取得するため、リソースオファー１１０を要件ビッド１１８へマッチさせる方法２３５を描いたフローチャートである。方法２３５は、図１及び図６を参照して説明される。
【００６１】
ステップ６０２において、取引市場１１２は、選択されたアプリケーションプログラムを作動させるために利用可能なリソースを識別するアプリケーションプログラムを選択する。そして、ステップ６０５において、取引市場１１２は、選択されたアプリケーションプログラムを作動させるために要求されるリソースを選択する。更に具体的には、もし選択されたアプリケーションプログラムの作動に多数のリソースが要求されるならば、方法２３５は、ステップ６０５において、それらのリソースの１つを選択し、これによって、方法２３５が、選択されたリソースについてリソースオファー１１０を要件ビッド１１８へマッチさせることが可能になる。次いで、この後で説明されるように、マッチングステップは、アプリケーションプログラムの作動に必要な他のリソースについて反復され得る。
【００６２】
ステップ６１０において、取引市場１１２は、選択されたアプリケーションプログラムについて、選択されたリソースの単位を購入するための要件ビッドを選択する。次いで、ステップ６１５において、取引市場１１２は、選択された要件ビッドの中で指定されたサービスレベル要件及び価格パラメータで仮想リソース１０９を提供するリソースオファーが存在するかどうかを決定する。従って、ステップ６２０において、取引市場１１２は、そのようなマッチするオファーが存在するかどうかを決定する。もしイエスであれば、方法２３５はステップ６３０へ分岐する。もしそうでなければ、方法２３５はステップ６２５へ分岐する。このステップ６２５において、取引市場１１２は、マッチするオファーが識別されるまで、リソース及び要件仲介者１０２及び１１４がリソースオファー１１０及び／又は選択された要件ビッドを改訂することを許可する。方法２３５は、次いでステップ６３０へ進む。
【００６３】
選択された要件ビッドとマッチするリソースオファー１１０を識別するため取引市場１１２によって採用される方法は、経済市場で商品を割り振る任意の適切な形式を備え得る。例えば、取引市場１１２は、商品市場モデル、公示価格モデル、入札／契約ネットモデル、オークションモデル（逆競りモデルを含む）、独占／寡占モデル、及び／又はビッド基礎比例リソース共有モデルのような方法を利用し得る。これらの例示的実施形態において、取引市場１１２は、市場清算価格で及び選択された要件ビッドの中で指定された予算パラメータ内でリソースを効率的に割り振るため、経済市場を作動させる。
【００６４】
選択された要件ビッドの中で指定された予算パラメータを考慮するとき、取引市場１１２は、要件ビッドを満たす最良のリソースオファーを識別するため、リソースオファーを比較し得る。例えば、もし多数のリソースオファーが適当なタイプのリソースをオファーするならば、取引市場１１２は、予算制約、例えば、コストに関わらず利用可能な最良リソースを取得する要件ビッドの命令、最小費用リソースを取得する要件ビッドの命令、指定総価格又はリソースの単位当たり価格でリソースを取得する要件ビッドの命令、又は他の適切な予算形式を介してリソースを取得する要件ビッドの命令のもとで、最良のリソースオファーを識別し得る。
【００６５】
ステップ６３０において、取引市場１１２は、マッチするリソースオファーを、選択された要件ビッドへリンクする。次いで、ステップ６３５において、取引市場１１２は、選択されたリソースの追加の単位が、選択されたアプリケーションプログラムを作動するために要求されるかどうかを決定する。例えば、もしマッチするリソースオファーがサービスレベル要件を満たすことを要求されるリソースの一部分のみを提供するならば、取引市場１１２は、選択されたリソースの追加の単位が要求されると決定し得る。もしイエスであれば、方法２３５は、選択されたリソースの単位を指定価格で購入する他の要件ビッドを選択するため、ステップ６１０へ戻る。新しく選択された要件ビッドは、前に選択された要件ビッドの改訂版であり得るが、選択されるリソースの量は、マッチするリソースオファーによって提供されたリソースの量に等しい量だけ低減される。
【００６６】
ステップ６３５に戻って、もし選択されたリソースの追加の単位が要求されなければ、方法２３５はステップ６４０へ分岐する。ステップ６４０において、取引市場１１２は、選択されたアプリケーションプログラムを作動させるために他のリソースが要求されるかどうかを決定する。例えば、もし取引市場１１２が、計算リソースについてのみ、マッチするリソースオファー１１０を識別したならば、取引市場１１２は、アプリケーションプログラムを作動させるために必要なネットワーク又は記憶リソースについて、マッチするリソースオファー１１０を識別すると決定し得る。この場合、方法２３５は、他のリソースについてマッチするリソースオファー１１０を識別するため、ステップ６０５へ戻る。もし取引市場１１２が、ステップ６４０において、他のリソースについてマッチするリソースオファー１１０を識別しないと決定するならば、方法２３５はステップ６４５へ分岐する。
【００６７】
次いで、ステップ６４５において、取引市場１１２は、他のアプリケーションプログラムについて要件ビッド１１８及びリソースオファー１１０をマッチさせるべきかどうかを決定する。もしイエスであれば、方法２３５はステップ６０２へ戻る。もしそうでなければ、方法２３５はステップ２４０（図２）へ分岐する。
【００６８】
図７は、図２のステップ２４０において参照されたように、本発明の例示的実施形態に従って、マッチするリソースオファー１１０及び要件ビッド１１８に基づきアプリケーションプログラムの作動に要求されるリソースを購入する取引を完了する方法２４０を描いたフローチャートである。方法２４０は、図１及び図７を参照して説明される。
【００６９】
ステップ７０２において、取引市場１１２はアプリケーションプログラムを選択する。そして、ステップ７０５において、取引市場１１２は、アプリケーションプログラムについて要件ビッド及びそのマッチするリソースオファーを選択する。ステップ７１０において、要件仲介者１１４は、リソースオファーの中で指定された仮想リソース１０９を利用するため、リソース仲介者１０２に支払うことを約定する。ステップ７１５において、取引市場１１２は、要件仲介者１１４のアカウントを借方に記入し、リソース仲介者１０２のアカウントを貸方に記入することによって、仮想リソース１０９の使用に対する支払い約定を計上する。次いで、ステップ７２０において、取引市場１１２は要件仲介者１１４とリソース仲介者１０２との間のサービスレベル契約を発行する。このサービスレベル契約において、リソース仲介者１０２は、もしあれば、リソースオファーの中で指定されたコストの支払いとの交換で、リソースオファー（マッチする要件ビッドの中で指定されたサービスレベル要件を満たす約定を含む）の中で指定された仮想リソース１０９を提供することに合意する。
【００７０】
ステップ７２５において、取引市場１１２は、アプリケーションプログラムについて追加のマッチする要件ビッド１１８及びリソースオファー１１０が存在するかどうかを決定する。もしイエスであれば、方法２４０は、アプリケーションプログラムの作動に要求される他のリソースについて取引を完了するため、ステップ７０５へ戻る。もしそうでなければ、方法２４０はステップ７３０へ分岐する。
【００７１】
ステップ７３０において、取引市場１１２は、他のアプリケーションプログラムについてリソースを取得するため、取引を完了するかどうかを決定する。もしイエスであれば、方法２４０は、他のアプリケーションプログラムを選択するため、ステップ７０２へ戻る。もしそうでなければ、方法２４０はステップ２４５（図２）へ分岐する。
【００７２】
図８は、図２のステップ２４５において参照されたように、本発明の例示的実施形態に従って、アプリケーションプログラムの作動を、購入されたリソースへ移行する方法２４５を描いたフローチャートである。方法２４５は、図１及び図８を参照して説明される。
【００７３】
ステップ８０２では、アプリケーションプログラムが選択される。ステップ８０５において、リソース仲介者１０２は、選択されたアプリケーションプログラムについて購入された仮想リソース１０９を選択する。次いで、ステップ８１０において、リソース仲介者１０２は、購入された仮想リソース１０９をアプリケーションプログラムへ割り振り、ステップ８１５において、要件仲介者１１４は、割り振られた仮想リソース１０９をアプリケーションプログラムの作動に利用するようアプリケーションプログラムに指令する。
【００７４】
ステップ８２０において、方法２４５は、アプリケーションプログラムについて他のリソースが購入されたかどうかを決定する。もしイエスであれば、方法２４５は、他の仮想リソース１０９をアプリケーションプログラムへ割り振るため、ステップ８０５へ戻る。もしそうでなければ、方法２４５はステップ８２５へ分岐する。
【００７５】
ステップ８２５において、方法２４５は、他のアプリケーションプログラムの作動を、購入されたリソースへ移行すべきかどうかを決定する。もしイエスであれば、方法２４５は、他のアプリケーションプログラムを選択するため、ステップ８０２へ戻る。もしそうでなければ、方法２４５はステップ２５０（図２）へ分岐する。
【００７６】
図９は、図２のステップ２５０において参照されたように、本発明の例示的実施形態に従って、割り振られたリソースの性能及びアプリケーションプログラムのサービスレベル要件を監視する方法２５０を描いたフローチャートである。方法２５０は、図１及び図９を参照して説明される。
【００７７】
ステップ９０５において、要件仲介者１１４は、アプリケーションプログラムによって利用されているリソースを選択する。例えば、要件仲介者１１４は、アプリケーションプログラムによって利用されている計算、ネットワーク、又は記憶リソースの１つを選択し得る。
【００７８】
ステップ９１０において、要件仲介者１１４は、選択されたリソースについて要件ビッドの中で指定されたアプリケーションプログラムのサービスレベル要件を決定する。例示的実施形態において、要件仲介者１１４は、サービスレベル契約の中に列挙されたサービスレベル要件に基づいて、この決定を行い得る。次いで、ステップ９１５において、要件仲介者１１４は、（選択されたリソースについて要件ビッドの中で指定されたサービスレベル要件以外の）新しいサービスレベル要件が、このリソースについて設定されているかどうかを決定する。もしイエスであれば、方法２５０は、例えば、アプリケーションプログラムのユーザによって入力された新しい要件を読み取ることによって、アプリケーションプログラムの新しいサービスレベル要件を決定するため、ステップ９２０へ分岐する。方法２５０は、次いでステップ９２５へ進む。ステップ９１５へ戻って、もし要件仲介者１１４が、アプリケーションプログラムについて新しいサービスレベル要件が設定されていないと決定するならば、方法２５０はステップ９２５へ直接分岐し得る。
【００７９】
ステップ９２５において、要件仲介者１１４は、アプリケーションプログラムによって利用されるときの選択されたリソースの性能を監視する。ステップ９３０において、要件仲介者１１４は、選択されたリソースの性能を、アプリケーションプログラムのサービスレベル要件と比較する。次いで、ステップ９３５において、要件仲介者１１４は、リソースの性能がアプリケーションプログラムのサービスレベル要件を超過するかどうかを決定する。もしイエスであれば、方法はステップ９４０へ分岐する。
【００８０】
ステップ９４０において、要件仲介者１１４は、リソースの過剰について支払っているかどうかを決定する。例えば、要件仲介者１１４は、もしアプリケーションプログラムがリソースの最大利用か最大利用の近くで作動しており、リソースが過剰能力を有するならば、要件仲介者１１４がリソースの過剰について支払っていると決定し得る。あるいは、もしリソースが過剰能力を有しても、アプリケーションプログラムは現在リソースの最大利用を下回って作動しているならば、要件仲介者１１４は、リソースの過剰について支払っていないと決定し得る。もし要件仲介者１１４が、リソースの過剰について支払っていると決定するならば、方法２５０はステップ２５５（図２）へ分岐する。このステップ２５５において、要件仲介者１１４は、十分に利用されていないリソースについて支払っていると決定する。
【００８１】
ステップ９４０へ戻って、もし要件仲介者１１４が、リソースの過剰について支払っていないと決定するならば、方法２５０は、選択されたリソースの監視を継続するため、ステップ９５５へ分岐する。
【００８２】
ステップ９３５へ戻って、もし要件仲介者１１４が、リソースの性能がアプリケーションプログラムのサービスレベル要件を超過していないと決定するならば、方法２５０はステップ９４５へ分岐する。ステップ９４５において、要件仲介者１１４は、選択されたリソースの性能が、アプリケーションプログラムのサービスレベル要件を満たしていないかどうかを決定する。もしイエスであれば、方法はステップ９５０へ分岐する。このステップ９５０において、要件仲介者１１４は、リソースがサービスレベル要件を満たすことができないかどうかを決定する。例えば、もしアプリケーションプログラムがリソースの最大利用か最大利用を下回って作動しており、リソースがサービスレベル要件を満たす十分な性能を提供していないならば、要件仲介者１１４は、選択されたリソースがサービスレベル要件を満たすことができないと決定し得る。あるいは、もしアプリケーションプログラムがサービスレベル要件で指定された利用を超えて一時的に作動しているならば、要件仲介者１１４は、リソースがサービスレベル要件を満たすことができると決定し得る。もし要件仲介者１１４が、リソースがサービスレベル要件を満たすことができないと決定するならば、方法２５０はステップ２５５（図２）へ分岐する。このステップ２５５において、要件仲介者１１４は、十分な性能を発揮していないリソースについて支払っていると決定する。
【００８３】
ステップ９５０へ戻って、もし要件仲介者１１４が、リソースの過剰について支払っていないと決定するならば、方法２５０は、選択されたリソースの監視を継続するため、ステップ９５５へ分岐する。
【００８４】
ステップ９４５へ戻って、もし要件仲介者１１４が、リソースの性能がサービスレベル要件よりも劣ると決定するならば、方法２５０は、選択されたリソースの監視を継続するため、ステップ９５５へ分岐する。
【００８５】
ステップ９５５から、方法２５０はステップ９６０へ進む。このステップ９６０において、要件仲介者１１４は、アプリケーションプログラムによって利用されている他のリソースの性能を監視すべきかどうかを決定する。もしイエスであれば、方法２５０は、監視する他のリソースを選択するため、ステップ９０５へ戻る。もしそうでなければ、方法はステップ２５５（図２）へ分岐する。このステップ２５５において、要件仲介者１１４は、アプリケーションプログラムによって利用されたリソースが十分に利用されていること又は十分に性能を発揮していると決定し得る。
【００８６】
方法２５０は、分散されたコンピューティング環境でサービスレベル契約を介してリソースを割り振られた各アプリケーションプログラムについて実行され得る。このようにして、割り振られたリソースの性能は、リソースがサービスレベル要件を満たすことを保証するため、連続的又は定期的に監視される。もしリソースが、要求されたサービスレベルを提供していないならば、要件仲介者１１４は、サービスレベル要件を満たすリソースを取得するため、新しい要件ビッド１１８を生成して取引市場１１２へそれらのビッドを提出する。追加的に、このようにして、リソースの性能が、要件仲介者１１４が未使用リソース（言い換えれば、リソースの過剰能力）について支払っていることを示す量だけサービスレベル要件を超過することがないことを保証するため、割り振られたリソースの性能は連続的又は定期的に監視される。もしリソースがアプリケーションプログラムによって十分に利用されていなければ、要件仲介者１１４は、サービスレベル要件に関して一層適切及び／又は経済的なリソースを取得するため、新しい要件ビッド１１８を生成して取引市場１１２へそれらのビッドを提出する。
【００８７】
図９に示される方法２５０は、割り振られたリソースが十分に利用されていないか又は十分に性能を発揮していないかどうかを決定するため、それらのリソースの性能を監視する。もしそうであれば、方法２５０は、ステップ２２５〜２４５を実行するため、図２に示された方法２００へ戻る。方法２００のステップ２２５〜２４５において、新しいリソースが識別されてアプリケーションプログラムへ割り振られ、アプリケーションプログラムの作動は新しいリソースへ移行される。
【００８８】
図１０は、本発明の例示的実施形態に従って、システム１００におけるアプリケーションプログラムについての、分散されたコンピューティングリソースの再割り振りを描いたブロック図である。図１０に示されるように、要件仲介者１１４は、現在割り振られたネットワーク及び記憶仮想リソース１０９についてサービスレベル契約の違反を識別した。言い換えれば、現在割り振られているネットワーク及び記憶仮想リソース１０９の性能は、それらの仮想リソース１０９に関連したサービスレベル契約で指定されたサービスレベル要件を満たしていない。更に具体的には、仮想ネットワーク構造Ｎ２は、割り振られたリソース間の必要な通信レートを提供するのに十分ではなく、要件仲介者１１４は、より速いネットワークリソースを取得する必要がある。追加的に、仮想記憶構造Ｓ２は必要な記憶及び検索レートを提供するのに十分ではなく、要件仲介者１１４は、より弾性的な記憶リソースを取得する必要がある。
【００８９】
従って、要件仲介者１１４は、指定されたサービスレベル要件を満たすことのできる新しいネットワーク及び記憶リソースを取得するために新しい要件ビッド１１８を生成し、取引市場１１２へそれらのビッドを提出する。取引市場１１２は、マッチするリソースオファー１１０を識別し、新しいネットワーク及び記憶仮想リソース１０９をアプリケーションプログラムへ割り振るため、サービスレベル契約を完了する。次いで、アプリケーションプログラムの作動は、新しいネットワーク及び記憶仮想リソース１０９へ移行される。図１０に示されるように、アプリケーションプログラムの作動は、仮想ネットワーク構造Ｎ２から仮想ネットワーク構造Ｎ１へ移行され、仮想記憶構造Ｓ２から仮想記憶構造Ｓ１へ移行される。
【００９０】
図１０に更に示されるように、要件仲介者１１４は、現在割り振られている計算仮想リソース１０９について予算の違反を識別した。言い換えれば、現在割り振られた仮想計算構造Ｃ１の性能は、それらのリソースに関連したサービスレベル契約で指定されたサービスレベル要件を超過している。更に具体的には、要件仲介者１１４は、未使用計算リソースについて過大に支払っており、サービスレベル要件内で実行する新しいリソースを取得する必要がある。これは、アプリケーションプログラムを作動するコストを低減する可能性がある。
【００９１】
従って、要件仲介者１１４は、指定されたサービスレベル要件内で実行する新しい計算リソースを取得するため、１つ又は複数の新しい要件ビッド１１８を生成して、取引市場１１２へそれらのビッドを提出する。取引市場１１２は、マッチするリソースオファー１１０を識別し、新しい計算仮想リソース１０９をアプリケーションプログラムへ割り振るため、サービスレベル契約を完了する。次いで、アプリケーションプログラムの作動は、新しい計算仮想リソース１０９へ移行される。図１０に示されるように、アプリケーションプログラムの作動は、仮想計算構造Ｃ１から仮想計算構造Ｃ２へ移行される。
【００９２】
図１１は、図２のステップ２７０において参照されたように、本発明の例示的実施形態に従って、或る期間にわたるリソース割り振りに基づいてリソースの維持、獲得、及び／又は売却を管理する方法２７０を描いたフローチャートである。方法２７０は、図１及び図１１を参照して説明される。
【００９３】
ステップ１１０５において、リソースマネージャ、例えば、リソース仲介者１０２は、各物理的リソース１０３によって生成された収入を監視する。例示的実施形態において、リソースマネージャは、各々の特定の物理的リソース１０３に対応するサービスレベル契約について支払いを合計することによって、そのような生成された収入を監視し得る。各々の支払いは、サービスレベル契約に含まれる特定の物理的リソース１０３の利用について、要件仲介者１１４からリソース仲介者１０２へ支払われる金額を表す。この点に関して、リソースマネージャは、期間中に各物理的リソース１０３によって生成された収入の現在高を維持し得る。
【００９４】
次いで、ステップ１１１０において、方法は、期間が経過したかどうかを決定する。例示的実施形態において、期間は、四半期、半年、一年、又は物理的リソース１０３によって生成された収入を監視するのに適した任意の他の期間であり得る。他の例示的実施形態において、方法２７０は、リソース仲介者１０２によって監視される所定の期間に基づいて、期間が経過したかどうかを決定し得る。所定の期間の満了は期間が経過したことの警告をトリガし得る。あるいは、方法２７０は、ユーザがステップ１１０５から生成された収入情報に手動でアクセスすることに基づいて、期間が経過したかどうかを決定し得る。いずれにせよ、もし期間が経過していなければ、方法２７０は、各々の物理的リソース１０３によって生成された収入の監視を継続するため、ステップ１１０５へ戻る。もし期間が経過したのであれば、方法２７０はステップ１１１５へ分岐する。
【００９５】
ステップ１１１５において、方法は、特に、各物理的リソースの購買及び維持に関連づけられたコスト及び費用を識別する。例示的実施形態において、ユーザは、実際及び／又は計画された購買及び維持コストに基づいて、その情報を入力し得る。次いで、ステップ１１２０において、各物理的リソース１０３の利益及び損失は、物理的リソース１０３に関連づけられたコスト及び費用を、物理的リソース１０３によって生成された収入から減じることによって決定される。
【００９６】
ステップ１１２５において、特定の物理的リソース１０３が選択され、ステップ１１３０においては、選択されたリソースが期間中に利益又は損失を生じたかどうかが決定される。もし物理的リソースの収入が、そのコスト及び費用よりも大きければ、物理的リソースは期間中に利益を生じている。あるいは、もし物理的リソースの収入が、そのコスト及び費用よりも小さいならば、物理的リソースは期間中に損失を生じている。
【００９７】
もし選択された物理的リソースが利益を生じたのであれば、方法２７０はステップ１１３５へ分岐する。ステップ１１３５において、選択された物理的リソースの利益は、他の類似リソースの利益と比較される。次いで、ステップ１１４０において、選択された物理的リソースの現在のポジションを維持すべきかどうか、又は選択された物理的リソースに投資すべきかどうかの決定が行われる。例えば、もしリソースが他のリソースと比較して小さい利益しか生じていないならば、ユーザはリソースにおける現在のポジションを維持すると決定してもよい。言い換えれば、ユーザはより多くのリソースを購入することはしない。あるいは、もしリソースが他のリソースと比較して大きな利益を生じたか、もしリソースの需要の増加が推定されるのであれば、ユーザはより多くのリソースを購入することによって、又は既存のリソースをアップグレードすることによって、リソースへの投資を決定してもよい。選択された物理的リソースのポジションを維持すべきか又は投資すべきかを決定した後、方法２７０はステップ１１５０へ進む。
【００９８】
ステップ１１３０へ戻って、もし選択された物理的リソースが、期間中に損失を生じたのであれば、方法２７０はステップ１１４５へ分岐する。ステップ１１４５において、選択された物理的リソースの現在のポジションを維持すべきか又は選択された物理的リソースを売却すべきかの決定が行われる。例えば、もしリソースが小さい損失のみを経験したか、リソースがコストを正当化する高優先順位の必要性を満たすならば、ユーザはリソースにおける現在のポジションを維持すると決定してもよい。言い換えれば、ユーザはリソースを売却しない。あるいは、もしリソースが大きな又は望ましくない損失を経験したのであれば、ユーザは、リソースを販売することによって又はリソースのサポート又は維持を打ち切ることによって、リソースの売却を決定してもよい。他の実施形態において、ユーザは、リソースに関連づけられた損失を低減するため、リソースの使用を低減すると決定するか、又はユーザは、他のリソースによって生成された利益を使用してリソースの継続使用を助成すると決定してもよい。選択された物理的リソースのポジションを維持すべきか売却すべきかを決定した後、方法２７０はステップ１１５０へ進む。
【００９９】
ステップ１１５０において、他のリソースのポジションを評価すべきかどうかが決定される。もしイエスであれば、方法２７０は、他のリソースを選択するため、ステップ１１２５へ戻る。もしそうでなければ、方法２７０及び方法２００（図２）は終了する。
【０１００】
従って、方法２７０によって、ユーザが価格及び性能を含めてどのリソースが最も経済的であるかを決定するため物理的リソースを評価することが可能になる。例えば、計算リソースは様々なプラットフォームを備えることができ、各プラットフォームは異なる価格及び性能特性を有する。各リソースの利益及び損失計算書の比較は、どのプラットフォームがアプリケーションプログラムによって最も多く使用され、それによってより多くの収入を生じているかを示す。その情報に基づいて、ユーザは、どのプラットフォームを維持すべきか、又はどのプラットフォームで会社のポジションを増加すべきか、及びどのプラットフォームを売却すべきかを決定し得る。リソースは、方法２００（図２）を参照して説明されたようにして割り振られたので、方法２７０は、価格及び性能特性に基づいて、アプリケーションプログラムによって使用されるためにはどのリソースが一層望ましいかを示す。
【０１０１】
本発明は、分散されたコンピュータリソースの割り振り及び管理を参照して詳細に説明されたが、本発明は他の分散されたリソースの割り振り及び管理へも適用される。例えば、本発明は分散された労働力へも適用され得る。この場合、リソースオファー１１０は、労働力の利用可能な個人又はグループ構成員に関連づけられた特性及び価格を識別するために生成され、それらのオファーは取引市場１１２へ提出される。要件ビッド１１８は、特定の労働プロジェクトについて労働力からサービスを取得するために生成され、それらのビッドは取引市場１１２へ提出される。次いで、取引市場１１２は、マッチするビッド及びオファーを識別し、労働力リソースをプロジェクトへ割り振る。割り振られたリソースの性能が監視され得る。また、十分に利用されていないか十分に性能を発揮していない労働力構成員を是正するために必要に応じてリソースが再割り振りされ得る。時間の経過と共に、労働力の個人又はグループ構成員の利益及び損失が決定され得る。また、労働力の特定の態様に関して投資又は売却を決定するために利益及び損失情報が使用され得る。
【０１０２】
図１２は、本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル契約に基づきリソース要求を管理する方法１２００を描いたフローチャートである。方法１２００は図１２及び図１５を参照して説明される。ここで、図１５は、本発明の例示的実施形態に従って、アプリケーションプログラムのサービスレベル契約に基づきリソース要求を管理するシステム１５００を描いたブロック図である。
【０１０３】
ステップ１２０５において、アプリケーションプログラムによって使用されるべき各リソースについてサービスレベル要件を規定するため、サービスレベル契約が創出される。例示的実施形態において、要求されるリソースは、コンピューティング、ネットワーク、及び記憶リソース、例えば、図１５に示される１つ又は複数の計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８を備え得る。サービスレベル契約は、アプリケーションプログラムのユーザに適したやり方でアプリケーションプログラムを作動させるために要求される各リソースの単位量を規定する。規定された単位量は、各リソースの対応するサービスレベル要件である。サービスレベル要件は、各リソースの最小許容量、各リソースの最大量、及び／又は各リソースの許容量の範囲を含むことができる。
【０１０４】
ステップ１２１０において、各リソースの各サービスレベル要件について閾値が構成され、この閾値を超えると、アプリケーションプログラムへのリソースの割り振られる量を増加するアクションが開始される。具体的には、各リソースについて、各リソースのサービスレベル要件を下回る閾値が設定される。もし適当であるか所望されるならば、リソースのタイプ及びリソースの利用が測定される方法に依存して、閾値はサービスレベル要件を上回って設定され得る。閾値がサービスレベル要件を上回るか下回るかに関わらず、閾値は、リソースの利用がサービスレベル要件に近づいた時を識別するベンチマークを提供する。閾値は、リソースの追加の量又はリソースの代替源が割り振られ、これによりサービスレベル契約の違反前にリソースの十分な量を割り振るアクションを取るリソース利用を表す。例えば、サービスレベル契約は、ネットワークリソースについて９０から１００メガビット／秒（「Ｍｂｉｔｓ／ｓ」）のデータ転送速度を要求するかも知れない。利用可能なネットワークリソースは、１０００Ｍｂｉｔｓ／ｓの利用可能能力を有するかも知れず、ネットワークリソースの９０Ｍｂｉｔｓ／ｓがアプリケーションプログラムへ割り振られてもよい。ネットワークリソースについて設定された閾値は、９０Ｍｂｉｔｓ／ｓを下回る量であり得る。例えば、閾値は、８５Ｍｂｉｔｓ／ｓ、８０Ｍｂｉｔｓ／ｓ、又はアプリケーションプログラムへ割り振られるネットワークリソースの量よりも小さい他の適切な値であり得る。例示的実施形態において、閾値は、ネットワークリソースの割り振られた量のパーセンテージ、例えば、９５％、９０％、８５％、８０％、又は他の適切なパーセンテージとして設定され得る。閾値が８５Ｍｂｉｔｓ／ｓに設定される上記の例において、８５Ｍｂｉｔｓ／ｓはアプリケーションプログラムによるネットワークリソースの利用を表し、この値を超えると、１００Ｍｂｉｔｓ／ｓのサービスレベル要件に達するまで、ネットワークリソースの追加量をアプリケーションプログラムへ割り振るアクションが取られる。例えば、前に割り振られた９０Ｍｂｉｔｓ／ｓを超過するネットワークリソースの利用に先立って、ネットワークリソースの１００Ｍｂｉｔｓ／ｓがアプリケーションプログラムへ割り振られ得る。この実施形態において、閾値は、割り振られた量がリソースのサービスレベル要件よりも小さい、リソースの割り振られた量に基づく。あるいは、リソースの割り振られた量は、リソースのサービスレベル要件と等しくてもよく、閾値は、サービスレベル要件が増加され、リソースの割り振りが新しいサービスレベル要件へ増加される点を表し得る。例えば、サービスレベル要件は、利用の急上昇に順応するため一時的に増加されてもよい。追加的に、サービスレベル要件及びリソースの割り振られた量は、利用の急上昇が止まった後に減少され得る。
【０１０５】
各リソースの閾値は、システム１５００の中のサービス品質「ＱＯＳ」マネージャ１５０４内に記憶される。例示的実施形態において、閾値はＱＯＳマネージャ１５０４の中に事前に構成され得る。あるいは、ユーザは、入力デバイス（図示せず）を介して所望の閾値をＱＯＳマネージャ１５０４内に入力することによって、閾値を構成し得る。
【０１０６】
例示的実施形態において、ＱＯＳマネージャ１５０４は、分散されたコンピューティング環境で作動して本明細書で説明されるように機能するソフトウェアモジュールを備え得る。
【０１０７】
ステップ１２１５において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムへのリソースの初期割り振りを行う。例示的実施形態において、リソース割り振りマネージャ１５０６は、本明細書で前に説明された取引市場１１２を備えることができ、図１〜図１１を参照して前に説明されたように、要件仲介者１１４及びリソース仲介者１０２と関連してリソースを割り振ることができる。あるいは、リソース割り振りマネージャ１５０６は、取引市場１１２を参照して説明された市場経済プロセスを使用することなく、他のやり方でリソースを割り振ることができる。例えば、ユーザは、リソース割り振りマネージャ１５０６を介してアプリケーションプログラムへのリソースの初期割り振りを規定することができ、又はリソース割り振りマネージャ１５０６は、アプリケーションプログラムの規定された優先順位又は割り振られたリソースの規定された開始スケジュール（「先着順」モデル）に基づいて、利用可能なリソースを割り振ることができる。リソース割り振りマネージャ１５０６は、アプリケーションプログラムのサービスレベル契約で規定されたサービスレベル要件を満たすのに十分な適切な任意の量において、アプリケーションプログラムによって利用される各リソースの量を割り振ることができる。
【０１０８】
例えば、リソース割り振りマネージャ１５０６は、計算、ネットワーク、又は記憶リソース、例えば、計算構造１０４、ネットワーク構造１０６、及び記憶構造１０８を選択し得る。例示的実施形態において、この後で更に詳細に説明される監視モジュール１５０２からの入力に基づいて、リソース割り振りマネージャ１５０６は、利用されていない各リソースの過剰能力を識別し得る。そのような過剰能力は、アプリケーションプログラムによる使用に利用可能なリソースとして識別され得る。
【０１０９】
リソース割り振りマネージャ１５０６は、アプリケーションプログラムによる使用に利用可能な各物理的リソース１０３の量を識別する。例示的実施形態において、各リソースの量は、特定の製造者及び／又はコンポーネントを含めてハードウェアタイプ及び／又は構成、並びに各リソースについて現在利用可能な過剰能力を備え得る。この点に関して、利用可能な物理的リソース１０３は、仮想リソース１０９、例えば、仮想計算構造Ｃ１及びＣ２、仮想ネットワーク構造Ｎ１及びＮ２、及び仮想記憶構造Ｓ１及びＳ２を創出するため組み合わせられ得る。例えば、分散された場所で利用可能なコンピュータプロセッサは、アプリケーションプログラムによる使用に利用可能な仮想コンピューティングリソースを創出するため、統合され得る。代表的リソース能力は、コンピューティングリソースについてＣＰＵサイクル、ネットワークリソースについて帯域幅、及び記憶リソースについてディスクスペース及び／又はメモリを備え得る。
【０１１０】
利用可能なリソースの量は、各仮想リソース１０９に関連づけられた性能及び信頼度特性を更に備え得る。例えば、そのような特性は、実行時間、応答時間、結果の正確度（例えば、故障率）、利用可能性、信頼度、セキュリティ、又は仮想リソース１０９の性能を示す他の適切な特性を備え得る。
【０１１１】
リソース割り振りマネージャ１５０６は、アプリケーションプログラムによる使用に割り振るため、各仮想リソース１０９の単位量を識別する。この点に関して、リソース割り振りマネージャ１５０６は、利用可能な仮想リソース１０９の最大量に達するまで、識別された単位の増分で割り振りに利用可能な仮想リソース１０９の部分を識別し得る。もしリソース割り振りマネージャ１５０６が、多数の仮想リソース１０９、例えば、仮想計算構造Ｃ１及びＣ２を識別したのであれば、リソース割り振りマネージャ１５０６は各仮想リソース１０９について単位量を識別し得る。
【０１１２】
例示的実施形態において、リソース割り振りマネージャ１５０６は、分散されたコンピューティング環境で作動して本明細書で説明されるように機能するソフトウェアモジュールを備え得る。
【０１１３】
アプリケーションプログラムへのリソースの初期割り振りの後、割り振られたリソースは、割り振られたリソースがアプリケーションプログラムのサービスレベル契約の要件を満たすことを保証するために監視される。従って、ステップ１２２０において、アプリケーションプログラムによって利用されているリソースが選択される。ステップ１２２５において、アプリケーションプログラムの選択されたリソースに関連づけられた閾値が、ステップ１２１０において設定された閾値から識別される。そして、ステップ１２３０において、監視モジュール１５０２は、アプリケーションプログラムによって利用されるときの選択されたリソースの性能を監視する。監視モジュール１５０２は、選択されたリソースの性能をＱＯＳマネージャ１５０４へ通信する。
【０１１４】
例示的実施形態において、監視モジュール１５０２は、分散されたコンピューティング環境で作動して本明細書で説明されるように機能するソフトウェアモジュールを備え得る。或る一定の例示的実施形態において、監視モジュール１５０２は、リソース利用を監視するように設計された既製のソフトウェアを備え得る。
【０１１５】
ステップ１２３５において、ＱＯＳマネージャ１５０４は、アプリケーションプログラムによる選択されたリソースの利用が、閾値を超過するか、又は閾値を満たすか又は超過するか（双方の場合は、本明細書では閾値の超過と呼ばれる）をステップ１２４０において決定するため、選択されたリソースの利用を、選択されたリソースの閾値と比較する。もしイエスであれば、方法１２００は、アプリケーションプログラムに関連づけられたサービスレベル契約の違反に先立ってアプリケーションプログラムの選択されたリソースの割り振りを修正するため、ステップ１２４５へ分岐する。ステップ１２４５は、この後で図１３を参照して更に詳細に説明される。方法１２００は、次いでステップ１２５０へ進む。
【０１１６】
ステップ１２４０へ戻って、もしＱＯＳマネージャ１５０４が、アプリケーションプログラムによる選択されたリソースの利用が閾値を超過しないと決定するならば、方法１２００はステップ１２５０へ直接分岐する。
【０１１７】
ステップ１２５０において、ＱＯＳマネージャ１５０４は、アプリケーションプログラムについて他のリソースの性能を監視すべきかどうかを決定する。もしイエスであれば、方法１２００は、他のリソースを選択するため、ステップ１２２０へ戻る。もしそうでなければ、方法１２００は終了する。
【０１１８】
方法１２００は、多数のアプリケーションプログラムについて割り振られたリソースを連続的に監視及び維持するため、多数のアプリケーションプログラムについて、及び１つ又は複数のアプリケーションプログラムによって利用されているか利用可能な多数のリソースについて、同時又は直線的に実行され得る。
【０１１９】
図１３は、図１２のステップ１２４５において参照されたように、例示的実施形態に従って、アプリケーションプログラムに関連づけられたサービスレベル契約の違反の前にアプリケーションプログラムの選択されたリソースの割り振りを修正する方法１２４５を描いたフローチャートである。方法１２４５は、図１３及び図１５を参照して説明される。
【０１２０】
方法１２４５は、リソースの利用がアプリケーションプログラムのそのリソースに設定された閾値を超過したときに実行される。閾値は、アプリケーションプログラムへのリソースの割り振られた量を下回るレベルに設定されるので、ステップ１２４５は、リソースの割り振られた量を超過する利用に先立ってリソースの割り振りを修正するために実行され得る。このようにして、本明細書で説明された方法及びシステムは、サービスレベル契約の来たらんとする違反を予想又は予測することができ、十分なリソースをアプリケーションプログラムへ割り振るため、違反に先立ってアクションを取り得る。
【０１２１】
図１３を参照して、ステップ１３０５において、リソース割り振りマネージャ１５０６は、選択されたリソースが、アプリケーションプログラムへ割り振られ得る追加の未だ割り振られていない能力を有するかどうかを決定する。もしイエスであれば、方法１２４５はステップ１３１０へ分岐する。このステップ１３１０において、リソース割り振りマネージャ１５０６は選択されたリソースの追加の能力をアプリケーションプログラムへ割り振る。もし選択されたリソースの初期割り振りが、リソースのサービスレベル要件よりも小さかったならば、選択されたリソースの追加の量は、サービスレベル要件に達するまで、アプリケーションプログラムへ割り振られ得る。あるいは、もし選択されたリソースの初期割り振りが、リソースのサービスレベル要件と等しかったならば、より高いサービスレベル要件を創出するため、サービスレベル契約が自動的に調節され、選択されたリソースの追加の量は、より高いサービスレベル要件に達するまで、アプリケーションプログラムへ割り振られ得る。サービスレベル要件の増加は、一時的又は永続的であり得る。ステップ１３１０から、方法１２４５は、この後で説明されるステップ１３５５へ進む。
【０１２２】
ステップ１３０５へ戻って、もし選択されたリソースの追加の能力が利用可能でなければ、方法１２４５はステップ１３１５へ分岐する。ステップ１３１５において、リソース割り振りマネージャ１５０６は、低優先順位アプリケーションプログラムが、リソースに対する低優先順位アプリケーションプログラムの最小要件を上回るレベルで、選択されたリソースを利用しているかどうかを決定する。もしイエスであれば、方法１２４５は、監視されるアプリケーションプログラム及び低優先順位アプリケーションプログラムの割り振りにおける増加及び減少の純量に基づいて、監視されるアプリケーションプログラムの増加された能力及び低優先順位アプリケーションプログラムの低減された能力に順応するリソースの十分な能力が存在するかどうかを決定するため、ステップ１３１８へ分岐する。もしそうでなければ、方法１２４５は、この後で説明されるステップ１３３０へ分岐する。もしイエスであれば、方法１２４５は、低優先順位アプリケーションプログラムから、監視されている高優先順位アプリケーションプログラムへ、選択されたリソースの割り振りをシフトするため、ステップ１３２０へ分岐する。従って、ステップ１３２０において、リソース割り振りマネージャ１５０６は、低優先順位アプリケーションプログラムについて選択されたリソースの割り振りを低減するが、低優先順位アプリケーションプログラムの最小要件を維持する。次いで、ステップ１３２５において、リソース割り振りマネージャ１５０６は、監視されている高優先順位アプリケーションプログラムについて選択されたリソースの割り振りを増加する。ステップ１３１０と同じように、監視されるアプリケーションプログラムへ割り振られる選択されたリソースの量は、既存又は新しく設定されたサービスレベル要件に達するまで増加され得る。
【０１２３】
ステップ１３２５から、方法１２４５は、リソースの純利用が変更されたかどうかをリソース割り振りマネージャ１５０６が決定するステップ１３２８へ進む。もしそうでなければ、方法１２４５はステップ１２５０（図１２）へ分岐する。もしイエスであれば、方法１２４５は、この後で説明されるステップ１３５５へ分岐する。
【０１２４】
ステップ１３１５へ戻って、もし低優先順位アプリケーションプログラムが、選択されたリソース上で作動していないならば、方法１２４５は、アプリケーションプログラムを一層適切なリソースへ移行するため、ステップ１３３０へ分岐する。ステップ１３３０において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムがアプリケーションプログラムのファミリーの一部分であるかどうかを決定する。ここで、アプリケーションプログラムの「ファミリー」とは、相互に依存するサービスレベル契約を有するアプリケーションプログラムのグループである。もしイエスであれば、方法１２４５は、アプリケーションプログラムのファミリーを一層適切なリソースへ移行するため、ステップ１３３５へ分岐する。こうして、ステップ１３３５において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムのファミリーの中の各アプリケーションプログラムについて規定されたサービスレベル要件に従ってアプリケーションプログラムのファミリーをサポートすることのできるリソースの代替の源を識別する。
【０１２５】
ステップ１３３８において、リソース割り振りマネージャ１５０６は、識別されたリソースが、サービスレベル契約の中で設定されたサービスレベル要件を満たすために必要な電力及び冷却要件を含めて、アプリケーションプログラムのファミリーに対するサービスレベル契約に従ってアプリケーションプログラムのファミリーに順応するのに十分であるかどうかを決定する。もしそうでなければ、方法１２４５は、リソース割り振りマネージャ１５０６が警告通知をシステム管理者へ発行するステップ１３４８へ分岐する。例示的実施形態において、警告通知は、モニタ上に表示され、電子メール又はテキストメッセージを介して送られ、又は他の適切なやり方で通信され得る。次いで、システム管理者は１つ又は複数のアプリケーションプログラムについてサービスレベル規定を修正してもよく、リソースは修正されたサービスレベル規定に従ってアプリケーションプログラムの間で割り振られ得る。
【０１２６】
ステップ１３３８へ戻って、もし識別されたリソースが十分であれば、方法１２４５はステップ１３４０へ分岐する。ステップ１３４０において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムのファミリーを、ステップ１３３５で識別された代替のリソースへ移行する。例示的実施形態において、移行は、いかなるアプリケーションプログラムの作動も中断しない「生の」移行であり得る。ステップ１３４０から、方法１２４５は、この後で説明されるステップ１３５５へ進む。
【０１２７】
ステップ１３３０へ戻って、もしリソース割り振りマネージャ１５０６が、アプリケーションプログラムがアプリケーションプログラムのファミリーの一部分ではないと決定するならば、方法１２４５は、監視されるアプリケーションプログラムのみを一層適切なリソースへ移行するため、ステップ１３４５へ分岐する。こうして、ステップ１３４５において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムについて規定されたサービスレベル要件に従ってアプリケーションプログラムをサポートすることのできるリソースの代替の源を識別する。
【０１２８】
ステップ１３４７において、リソース割り振りマネージャ１５０６は、識別されたリソースが、サービスレベル契約において設定されたサービスレベル要件を満たすために必要な電力及び冷却要件を含めて、アプリケーションプログラムのサービスレベル契約に従ってアプリケーションプログラムに順応するのに十分であるかどうかを決定する。もしそうでなければ、方法１２４５は、前に説明されたステップ１３４８へ分岐する。
【０１２９】
もし識別されたリソースが十分であれば、方法１２４５はステップ１３５０へ分岐する。ステップ１３５０において、リソース割り振りマネージャ１５０６は、アプリケーションプログラムを、ステップ１３４５において識別された代替のリソースへ移行する。例示的実施形態において、移行は、アプリケーションプログラムの作動を中断しない「生の」移行であり得る。方法１２４５は、次いでステップ１３５５へ進む。
【０１３０】
ステップ１３５５において、電力／冷却調節システム１５０８は、ステップ１３１０、１３４０、又は１３５０において実行された、割り振られたリソースの変更に基づいて、当初及び代替のリソースの冷却及び電力要件を調節する。ステップ１３５５は、この後で図１４を参照して更に詳細に説明される。ステップ１３５５から、方法１２４５はステップ１２５０（図１２）へ進む。
【０１３１】
図１４は、図１３のステップ１３５５において参照されたように、例示的実施形態に従って、ステップ１３１０、１３４０、又は１３５０（図１３）において実行された、割り振られたリソースの変更に基づき、当初及び代替のリソースの冷却及び電力要件を調節する方法１３５５を描いたフローチャートである。方法１３５５は、図１４及び図１５を参照して説明される。
【０１３２】
ステップ１４０５において、リソース割り振りマネージャ１５０６は、ステップ１３１０、１３４０、又は１３５０（図１３）において実行された追加又は代替のリソースの割り振りに基づいて、特定のリソースの割り振りの増加又は減少の量を決定する。例えば、リソース割り振りマネージャ１５０６は、ステップ１３１０、１３４０、又は１３５０におけるリソース割り振りの実行後に存在する割り振りから、特定のリソースの初期割り振りを減じることによって、この決定を行い得る。差異は、特定のリソースの割り振りにおける増加又は減少である。リソース割り振りマネージャ１５０６は、この情報を電力／冷却調節システム１５０８へ報告する。
【０１３３】
ステップ１４１０において、電力／冷却調節システム１５０８は、特定のリソースの割り振りの変更に基づいて、特定のリソースを作動させるために要求される、対応する電力の増加又は減少を決定する。次いで、ステップ１４１５において、電力／冷却調節システム１５０８は、それに従って特定のリソースへ供給される電力を調節する。例えば、もしコンピューティングリソースのＣＰＵサイクルが低減されるならば、コンピューティングリソースを作動させるために要求される、対応する電力が低減されてもよい。あるいは、もしコンピューティングリソースのＣＰＵサイクルが増加されるならば、コンピューティングリソースを作動させるために要求される、対応する電力が増加してもよい。この点に関して、電力／冷却調節システム１５０８は、コンピューティングリソースへ供給される電流及び／又は電圧の量を変更するため、電力コントローラ（図示せず）と連結し得る。従って、アプリケーションプログラムへ割り振られるリソースの量に基づき、リソースを作動させるために必要な電力のみを提供することによって、電力がリソースへ効率的に供給され得る。
【０１３４】
同様に、ステップ１４２０において、電力／冷却調節システム１５０８は、特定のリソースの割り振りにおける変更に基づいて、特定のリソースを作動させるために要求される冷却における対応する増加又は減少を決定する。次いで、ステップ１４２５において、電力／冷却調節システム１５０８は、それに従って特定のリソースへ供給される冷却を調節する。例えば、もしコンピューティングリソースのＣＰＵサイクルが低減されるならば、コンピューティングリソースを作動させるために要求される、対応する冷却が低減されてもよい。あるいは、もしコンピューティングリソースのＣＰＵサイクルが増加されるならば、コンピューティングリソースを作動させるために要求される、対応する冷却が増加してもよい。この点に関して、電力／冷却調節システム１５０８は、コンピューティングリソースへ供給される冷却の量を変更するため、冷却システムコントローラ（図示せず）と連結し得る。従って、冷却は、アプリケーションプログラムへ割り振られるリソースの量に基づき、リソースを作動させるために必要な冷却のみを提供することによって、リソースへ効率的に供給され得る。例示的実施形態において、冷却システムコントローラは、特定のリソースが提供される室の中でＨＶＡＣシステムを制御し得る。あるいは、冷却システムコントローラは、特定のリソースの内部又は外部にあるファン（図示せず）を制御し得る。
【０１３５】
ステップ１４２５から、方法１３５５はステップ１２５０（図１２）へ進む。
【０１３６】
例示的実施形態において、電力／冷却調節システム１５０８は、分散されたコンピューティング環境で作動して本明細書で説明されるように機能するソフトウェアモジュールを備え得る。
【０１３７】
従って、ＱＯＳマネージャ１５０４は、サービスレベル契約の潜在的違反がいつ起こるかを予想又は予測することができ、サービスレベル契約の違反に先立って追加又は代替のリソースを割り振り、これによってサービスレベル契約の違反を防止するように行動し得る。
【０１３８】
例示的実施形態において、ＱＯＳマネージャ１５０４は、利用可能なリソースに基づき各アプリケーションプログラムの適当なリソースを決定するため、検査を連続的に実行し得る。検査は、既存のリソースを使用する新しいアプリケーションに基づいて、より多くのリソースの潜在的必要性を検出するために実行され得る。
【０１３９】
他の例示的実施形態において、人工知能アプリケーションは、リソースの利用を連続的に監視し得る。様々なサービスレベル契約が、本明細書で説明されたように規定されることができ、人工知能は、多数の可能なシナリオに基づいてリソースの効率的、初期、代替、又は他の割り振りを決定するため、検査を実行し得る。リソース割り振りマネージャは、例えば、利用可能なリソース能力、及び、もしあれば、関連コストを決定することができ、その情報を、様々なアプリケーションプログラムの間でリソース割り振りの多数のシナリオを評価する人工知能アプリケーションへ通信し得る。
【０１４０】
本発明は、上記で説明された方法及び処理機能を実行するコンピュータハードウェア及びソフトウェアを用いて使用され得る。当業者によって了解されるように、本明細書で説明されたシステム、方法、及び手順は、プログラム可能コンピュータ、コンピュータ実行可能ソフトウェア、又はディジタル回路で体現され得る。ソフトウェアは、コンピュータ読み取り可能メディア上に記憶され得る。例えば、コンピュータ読み取り可能メディアは、フロッピー（登録商標）ディスク、ＲＡＭ、ＲＯＭ、ハードディスク、取り外し可能メディア、フラッシュメモリ、メモリスティック、光学メディア、磁気光学メディア、ＣＤ−ＲＯＭなどを含み得る。ディジタル回路は、集積回路、ゲートアレイ、ビルディングブロック論理、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）などを含み得る。
【０１４１】
本発明の特定の実施形態が本明細書で詳細に説明されたが、説明は単に例証を目的とする。本明細書で説明された例示的方法は単なる例証であり、本発明の代替の実施形態において、或る一定のステップは、異なる順序で実行され、互いに並列に実行され、又は全く省略されることができ、及び／又は或る一定の追加のステップが、本発明の範囲及び趣旨から逸脱することなく実行され得る。追加的に、例示的実施形態の開示された態様の様々な修正、及び対応する同等のステップが、本明細書で説明されたものに加えて、下記の特許請求の範囲で規定された本発明の趣旨及び範囲から逸脱することなく当業者によって行われ得る。特許請求の範囲は、そのような修正及び同等の構造を包含するように最も広い解釈を付与されるべきである。
【図１】
2011503713.tif 000003
【図２】
2011503713.tif 000004
【図３】
2011503713.tif 000005
【図４】
2011503713.tif 000006
【図５】
2011503713.tif 000007
【図６】
2011503713.tif 000008
【図７】
2011503713.tif 000009
【図８】
2011503713.tif 000010
【図９】
2011503713.tif 000011
【図１０】
2011503713.tif 000012
【図１１】
2011503713.tif 000013
【図１２】
2011503713.tif 000014
【図１３】
2011503713.tif 000015
【図１４】
2011503713.tif 000016
【図１５】
2011503713.tif 000017
【国際調査報告】
2011503713.tif 000018