JP2007531130A

JP2007531130A - サービス品質保証契約のコンプライアンスを予測するオンデマンドインフラのリアルタイムテストを可能にする方法

Info

Publication number: JP2007531130A
Application number: JP2007505558A
Authority: JP
Inventors: チャン、イェン、フー; ダンスモア、ジョン; プラダーン、アバイ; シャンカール、ハリ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-03-31
Filing date: 2005-03-30
Publication date: 2007-11-01
Anticipated expiration: 2025-03-30
Also published as: WO2005096192A8; EP1745376A1; US8417499B2; US20050222885A1; WO2005096192A1; IL178386A0; US20140006624A1; JP4688224B2; US9020794B2; CN1906628A; TW200612343A

Abstract

【課題】共有ＩＴ環境、又は電子ビジネスオンデマンド環境で動作する顧客の情報技術（ＩＴ）システムおよびアプリケーションの効率と有効性を実証する装置および方法を提供する。
【解決手段】テストスーツはオンデマンドサービス環境（１２９）で仮想設定を模倣し、その後設定がオンデマンドサービス環境（１２９）のリソースの割り当てにどのように影響するかを判断する。さらに、計算したリソースの割り当てを一又は複数のサービス品質保証契約（ＳＬＡ）と比較して、ある特定のＳＬＡへのコンプライアンスを判断する。
【選択図】図１

Description

本発明は、一般的に電子ビジネスオンデマンド（ＥＢＯＤ）に関係し、より具体的にはＥＢＯＤ環境でリアルタイムでのインフラのシナリオテストを提供するシステムおよび方法に関係する。

数十年にわたり、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーション（ＩＢＭ）はビジネスコンピューティングにおいて常に新たな方策を生み出してきた。現在ＩＢＭは、新たなコンピューティングユーティリティサービス構想、すなわち「ｅ−ビジネスオンデマンド」（ＥＢＯＤ）を開発中である。簡単にいうと、ＥＢＯＤとは、クライアントが実際に使用したコンピューティングサービスレベルの対価のみ支払う「時間課金制」に基づく情報技術（ＩＴ）の一形態である。ＥＢＯＤの顧客はそのＩＴ環境をユーティリティ管理インフラ（ＵＭＩ）に移して、実際に受けるコンピューティングサービスの対価のみ支払う。電気や水道、ガスと同様、ＩＴをもうひとつのユーティリティとして扱うのである。このように、ＩＴ運営の構築と維持の責任、アドミニストレータに必要な教育や訓練を行う責任、適用される規制を遵守する義務をなくすことによって、顧客はＩＢＭが提供する共有インフラの変動価格制、自動化プロセス、および非常に貴重な障害許容力や応答性を享受しながら、自社の中核事業に専念できる。

顧客が専用のＩＴ環境からＥＢＯＤ環境に移行するのは、新たな方策の効率や実際のＩＴ運営の制御ロスに関心があるといえる。共有ＩＴインフラの現在のベンダーは顧客にそのＩＴシステムの応答性の解析を認めているかもしれないが、ＩＢＭのＥＢＯＤインフラのような新たに出現したユーティリティ同様のミドルウェアをサポートするリアルタイムのサービステストツールはない。

現在ある製品には、カリフォルニア州サニーベールのマーキュリー・インタラクティブ・インクが発行する代表的なシステムテストスーツであるＷｉｎＲｕｎｎｅｒや、ＩＢＭの近日発表のＢｌｕｅＴｙｐｈｏｏｎグラフィカルユーザーインターフェース（ＧＵＩ）がある。代表的なシステムテストスーツは「ｔｏｐ」、「ｓａｒ」、「ｗａｉｔ」、「ｖｍａｓｔａｔ」、「ｎｅｔｓｔａｔ」、「ｐｉｎｇ」などのコンピュータコマンドを採用して、ＣＰＵ、メモリー、ディスク、およびネットワークなどのリソースの利用を判別しているだけで、仮想負荷をテストする方法は提供していない。

ＷｉｎＲｕｎｎｅｒは実際のＩＴイベントを捕捉した後、捕捉したイベントに基づいて、クライアントまたはウエブベースの一連のＧＵＩでユーザーが手作業を行うのをエミュレートする。ユーザーの数は調整できるが、ＷｉｎＲｕｎｎｅｒはある種のユーザーインターフェースを必要とするアプリケーション固有機能にテストを行う、すなわち、ＷｉｎＲｕｎｎｅｒは、特定のアプリケーションに対するストレスや、処理、ネットワークの機能性、およびデータ記憶容量などの個々の共有能力の使用をシミュレートするのではなく、ユーザーインターフェースをテストするのである。

ＢｌｕｅＴｙｐｈｏｏｎＧＵＩは、顧客がコンピューティング能力を変更したり、コンピューティングリソースを割り当ておよび割り当て解除もしくは割り当てまたは割り当て解除できるＪａｖａスイング／アプレットアプリケーションである。このアプローチは顧客にリソースの受動的な見方を提供するが、ＢｌｕｅＴｙｐｈｏｏｎは現実のリアルタイムテストで能動的に共有システム／アプリケーションデータを検索する方法を提供するわけではない。

共有ＩＴ環境で動作する顧客の情報技術（ＩＴ）システムおよびアプリケーションの効率と有効性をモデル化する装置および方法を提供する。請求する主題は、ユニバーサル管理インフラ（ＵＭＩ）プロバイダーが、実際の顧客の要求が顧客のサービス品質保証契約（ＳＬＡ）の限度に見合っているかまたはそれを超えているかどうかを実証できるようにする。所望のＩＴ設定は、テストスーツによってＵＭＩ環境でシミュレートできる。テストスーツは、顧客が仮想コンピュータに対する生産レベルの負荷とストレスを生成できるようにするため、顧客特有のｅ−ビジネスオンデマンド（ＥＢＯＤ）環境に見通しを与える。この能力で、顧客は事前に起こりえるシステムの欠陥を突き止めて、加入するサービスの効率を最大限にするために必要な調整を行える。すなわち、請求する主題は、顧客が自身のＥＢＯＤ環境のリアルタイムテストを構成し、実施できるようにする。

上記課題を解決するために、利用できるコンピューティングリソースのセットから動的に割り当てたコンピューティングリソースのサブセットを有するユーティリティコンピューティング環境でサービスレベルを予測する方法で、前記方法が、サービス品質保証契約に従い割り当てた第１サブセットのコンピューティングリソースに対応するリソースプロファイルを作成するステップと、企業の需要プロファイルを表す作業負荷プロファイルをロードするステップと、リソースプロファイルを使って作業負荷プロファイルの処理をシミュレートして、サービスレベルの結果を出すステップとを有する方法において、リソースプロファイルリソースサブセットをサービス品質保証契約に従いシミュレーション中に修正する、方法。ＩＢＭのＵＭＩ環境は、システム内の多数のユーザーやトランザクションを処理できるプロセッシング、ネットワーク、およびデータ記憶容量などのリソースからなる。あるクライアントは典型的にはこの能力のほんの小部分しか必要ないため、所望のレベルのサービスを受けるために契約する。例えばＩＢＭが提供するチボリ・サービス・デスク（ＴＳＤ）などのヘルプデスクソフトウェアを使って、請求する主題はシステム応答を検出するアクセス、エンドポイントマシンがネットワーク／記憶容量などのリソースを最適にしているかどうかを検出するアクセス、典型的なエンドユーザー（ヘルプデスクエージェント）が日々行う代表的な負荷を送信するアクセスをシミュレートできる。このように、顧客は仮想コンピュータの挙動を、何よりＵＭＩ内の自社の必須のアプリケーションの挙動を分析して把握できる。

本発明は、顧客が仮想負荷をＳＬＡと比較して、必要ならＳＬＡを管理または最適化するための調整を行えるようにする。加えて、ＳＬＡの作成の前に、潜在的な顧客が提案されるＳＬＡが最適化され、自身のニーズにあっているかを確認できる。

本要約は請求する主題の包括的な説明と考えているわけではなく、むしろそれに関連する機能の一部の簡単な概要を提示することを目的としている。発明の他のシステム、方法、機能、特徴、および利点は、以下の図面と詳細な説明を吟味すれば当業者には明らかである、または明らかになるであろう。

あるＵＭＩ環境を特に参照して説明するが、請求する主題は負荷およびストレステストもしくは負荷またはストレステストが望まれるあらゆる情報技術（ＩＴ）システムに実装できる。コンピューティング技術の熟練者には、開示する実施例が以下に説明するものに加えて非常に多様なコンピューティング環境に関連していることは理解されるであろう。さらに、開示する発明の方法は、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組合せにも実装できる。ハードウェア部分は専門のロジックを使って実装し、一方ソフトウェア部分はメモリーに格納して、マイクロプロセッサ、パーソナルコンピュータ（ＰＣ）、またはメインフレームなどの適切な命令実行システムで実行できる。

ここで図に移ると、図１は、請求する主題を組み込む例示的なユニバーサル管理インフラ（ＵＭＩ）アーキテクチャのブロック図である。企業１０１は、顧客１１０３、顧客２１０４、顧客３１０５、顧客４１０６、顧客５１０７などの多数の顧客にサービスを提供する。企業１０１はまた、納入業者１１１３、納入業者２１１４、納入業者３１１５など多数の納入業者と関係がある。ＵＭＩアーキテクチャ１００並びに請求する主題は情報技術（ＩＴ）インフラを採用する事実上どの種類の事業にも適用できるため、この例のために企業１０１が従事する事業の特定の種類は規定しない。事実、ＵＭＩアーキテクチャ１０１は顧客および納入業者もしくは顧客または納入業者をもたない仮想ビジネスでさえ適用できる。

この例では、納入業者１１３〜１１５は企業に部品とサービス１２１を供給し、顧客１０３〜１０７は製品、すなわち提供物１１９を購入する。企業１０１は、企業１０１が部品とサービス１２１を提供物１１９に変えることのできるビジネスプロセス１１２３、ビジネスプロセス２１２４、およびビジネスプロセス３１２５を有する。ビジネスプロセスの種類の例には、製造供給システム、会計システム、請求処理システム、顧客管理システム、給与システムが含まれるが、それだけに限定されない。顧客１０３〜１０７、納入業者１１３〜１１５、およびビジネスプロセス１２３〜１２５とした具体的な数は単なる例として使用する。請求される主題は、あらゆる具体的な数の上記関係をもつ中小企業にも大企業にも同様に適用する。

企業１０１は、仮想インフラ、すなわち「オンデマンドサービス（ＯＤＳ）フレームワーク」１２９を組み込み、この例では、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーション（ＩＢＭ）が設計するｅ−ビジネスオンデマンド（ＥＢＯＤ）環境である。ＩＢＭのＥＢＯＤ環境は法人顧客向けに設計しており、従量課金制でインターネット上で会計アプリケーション、人事アプリケーション、および顧客関係管理アプリケーションを配信でき、または例えば、プロセッサ、記憶装置、メモリーなどのコンピューティングリソースを必要に応じて会社に提供してその業務を支援するために使う。

図２は、図１のＯＤＳフレームワーク１２９の詳細なブロック図である。図２には、ＩＢＭのＥＢＯＤ環境などのＯＤＳ環境で利用できる様々なオンデマンドサービスを表すＯＤＳブロック１６７が含まれる。前述したように、ＯＤＳサービスの例１２は、製造供給システム、会計システム、請求処理システム、顧客管理システム、および給与システムが含まれるが、それだけに限定されない。この例では、ＯＤＳサービス１６７はサービスプログラミングインターフェース（ＳＰＩ）１６５を介してＯＤＳフレームワーク１２９に結合される。この例では、ＳＰＩ１６５はアプリケーションプログラミングインターフェース（ＡＰＩ）のセットである。コンピューティング技術の熟練者には、これだけには限定されないがセキュアソケットなど、ＳＰＩ１６５以外のＯＤＳフレームワーク１２９とＯＤＳブロック１６７との接続を実施する他の方法があることは理解されるはずであろう。

図２にはまた、ビジネスシステムブロック１６９が含まれ、企業１０１（図１）が提供する一または複数の様々なＯＤＳサービスにアクセス権を提供するのに必要となりうるあらゆる個々のビジネスプロセス１２３〜１２５（図１）を表す。ビジネスシステム１６９は命令許可ブロック１７１を介してＯＤＳフレームワーク１２９に結合されるが、命令許可ブロック１７１はビジネスシステムからＯＤＳフレームワーク１２９に情報を通信するソフトウェア、ハードウェア、または人間オペレータでありうる。

ＯＤＳフレームワーク１２９はビジネスシステム１６９、ＯＤＳサービス１６７、およびＯＤＳフレームワーク１２９の間の相互関係を調整する統合ハブ１４１を含む。統合ハブ１４１は、ワークフローコンポーネント１４３と統合ミドルウェアコンポーネント１４５を含む。ワークフローコンポーネント１４３は、ビジネスシステム１６９からの通信と要求を管理し、統合ミドルウェアコンポーネント１４５はＯＤＳブロック１６７からの通信と要求を管理する。ワークフローコンポーネント１４３は、主に統合ミドルウェアコンポーネント１４５と通信する一方、統合ミドルウェアコンポーネント１４５は、ワークフローコンポーネント１４３からＯＤＳサービスブロックへの通信と要求およびＵＭＩ基本サービス１４７からＯＤＳコンポーネント１６７への通信と要求の両処理を担う。

ＵＭＩ基本サービス１４７はポータル１５１を含むが、ポータル１５１はＵＭＩ基本サービス１４７、ＯＤＳフレームワーク１２９の残り、そしてＯＤＳフレームワーク１２９の外部の別のベンダーのソフトウェアなどあらゆるエンティティとの間の通信インターフェースであり、ＵＭＩ基本サービス１４７との直接的な通信リンクを必要とする。コンピューティング技術の熟練者には、ＡＰＩやセキュアソケットを含むが、それだけに限定されないポータル１５１を実装する多数の方法があることは理解されるであろう。ＵＭＩ基本サービス１４７の他のコンポーネントには、ヘルプデスクコンポーネント１５２、サービス品質保証契約（ＳＬＡ）コンポーネント１５３、プロビジョニングコンポーネント１５４、レポーティングコンポーネント１５５、モニタリング・管理コンポーネント１５６、請求処理コンポーネント１５７、メータリングコンポーネント１５８、テストセンターコンポーネント１５９が含まれる。

ヘルプデスクコンポーネント１５２は、典型的な電話応答システムなどの自動化システムでも、またはヘルプデスクコンポーネント１５２が企業１０１（図１）の対応するヘルプデスク部で働く従業員の通信およびデータ検索作業を自動化する役割を果たす人員スタッフを完全または一部にを配備したシステムでもよい。

サービス品質保証契約（ＳＬＡ）管理コンポーネント１５３は、ＯＳＤフレームワーク１２９とクライアント企業とのインタラクションを監視し、制御する。インタラクションは、顧客１０３〜１０７（図１）および納入業者１１３〜１１５（図１）もしくは顧客１０３〜１０７（図１）または納入業者１１３〜１１５（図１）によるシステムリソースへのアクセスを含む。ＳＬＡは典型的にはＯＤＳフレームワーク１２９のプロバイダーと、企業が使用許可されるＯＤＳフレームワーク１２９のリソースの量およびそのリソースのコストに関わる企業との契約上の合意である。すなわち、ＳＬＡ管理コンポーネント１５３は、企業の使用量とＵＭＩサービスがその固有のＳＬＡを満たしているか、超えているか、あるいはそれを遵守しているかどうかを判別し、その後その情報を基に適切な措置を取る。ＳＬＡに関わるデータは、データストア１６１に格納される。

プロビジョニングエンジン１５４は、ＯＤＳフレームワーク１２９内のリソースソースに関係するタスクの自動化とリソースの分散を担う。具体的には、プロビジョニングエンジン１５４は、サーバー、データ記憶装置、ネットワークリソース、およびファイヤウォールなどのリソースの割り当てを、ＳＬＡが要求する企業の需要を満たせるようにする。加えて、プロビジョニングエンジン１５４は、ＯＤＳフレームワーク１２９内でのソフトウェアの分散を促す。

レポーティングコンポーネント１５５は、企業１０１、ビジネスプロセス１２３、１２５、および１２７、ＯＤＳフレームワーク１２９の一部もしくはすべてに関するレポートの作成を担う。レポートは、生産レポート、請求処理レポート、在庫レポート、顧客レポート、業績レポート、およびＳＬＡコンプライアンスレポートを含むが、それだけに限定されない。予め用意されたレポートのテンプレートと作成されたレポートはデータストア１６１に格納される。

モニタリング・管理（Ｍ＆Ｍ）コンポーネント１５６は、ＯＳＤフレームワーク１２９と他のＵＭＩ基本サービス１４７に関する情報の収集を担い、その管理のためのインターフェースを提供する。収集した情報はデータストア１６１に格納され、以下に説明するように、直接またはデータストア１６１から、ヘルプデスク１５２、レポーティングコンポーネント１５５、および請求処理コンポーネント１５７に利用できるようになされる。

請求処理コンポーネント１５７は、以下に説明するように、主にＳＬＡ管理コンポーネント１５３およびメータリングコンポーネント１５８からの情報を基に、ＯＤＳフレームワーク１２９の利用に関し、企業のインボイスを作成および請求処理情報を作成する。

メータリングコンポーネント１５８は企業のＯＤＳフレームワーク１２９の利用に関するトラックとともに、ＯＤＳフレームワーク１２９の運用に関わる必要な内部情報を維持する。メータリングコンポーネント１５８が収集した情報は、データストア１６４に格納し、ヘルプデスクコンポーネント１５２、レポーティングコンポーネント１５５、Ｍ＆Ｍコンポーネント１５６、および請求処理コンポーネント１５７の利用に応じられるようにする。

最後に、テストセンターコンポーネント１５９は、顧客プロファイリング、テストデータの生成、ＯＤＳフレームワーク１２９のテストストレージやスケジューリングなどの活動を制御する。テストセンターコンポーネント１５９は以下の図５と合わせて詳細に説明する。

図３は図２の統合ハブ１４１の詳細なブロック図であり、ＯＳＰＩ１６９の要求の処理中のＯＤＳフレームワーク１２９のある特定のコンポーネント間の通信に特に注目している。図２と合わせて上記で説明したように、ＯＤＳブロック１６７への通信もＯＤＳブロック１６７からの通信もＳＰＩ１６５を介して送信する。ＳＰＩ１６５を介したＯＤＳ１６７からの個々の要求は、統合ミドルウェア１４５に送信され、そこで要求を処理するのに適切なコンポーネントを判別する。個々の要求が許可されたソースからのものであることを確認する中央認証許可（ＣＡＡ）コンポーネント１７３と、あるソースがＣＡＡ１７３で認証されたらログインを促しトランザクションを記録する共通ログイン監査（ＣＬＡ）コンポーネント１７５を含む。

ＣＡＡ１７３で認証されて、ＣＬＡ１７５でログインされた後、統合ハブ１４１に到着する要求は、適切なＵＭＩコンポーネント１５１〜１５８に送られる。例えば、メータリングコンポーネント１５８は、あるユーザーのアクセスをＣＬＡ１７５で記録するとともに、そのユーザーのＯＤＳフレームワーク１２９の使用量を記録する。上記で説明したように、ワークフローコンポーネント１４３はＯＤＳフレームワーク１２９内のトランザクションの管理に関し、統合ミドルウェア１４５を統制する。ワークフローコンポーネント１４３はＵＭＩコンポーネント１５１〜１５８間の操作プロセスの自動化を可能にする。ワークフローコンポーネント１４３はまた、一部手動ステップで一部自動化ステップのプロセスを調整する。手動ステップに関し、ワークフローコンポーネント１４３は、これだけに限定されないが、設定したビジネスルールに基づいた進捗の追跡、時間制限の執行、および警告の送信などのタスクを行う。

図４は、すべてを図２および図３と合わせて上記で説明した統合ハブ１４１、ＵＭＩコンポーネント１５１〜１５８、ＯＤＳ１６７、ＣＡＡ１７３、およびＣＬＡ１７５間の相互関係を詳細に図示するブロック図である。ＯＤＳ１６７は要求１８１を送信し、応答１８３を受信することにより統合ハブ１４１と通信する。簡略化のために、ＳＰＩ１６５（図３）は図４には図示していない。

顧客１０３〜１０７または納入業者１１３〜１１５（図１）などのあるユーザーからの初期ＯＤＳ要求１８１は、典型的にはＯＤＳフレームワーク１２９（図２）で認証する必要がある。これは統合ハブ１４１で行うが、初期要求１８１のデジタル証明書からＯＤＳ同定（ＩＤ）を抽出し、ＯＤＳＩＤ１８５をＣＡＡ１８９に送信する。典型的には、そうとは限定されないがパスワードでありうるＯＤＳＩＤは、あるクライアントのためにＯＤＳ１６７がセットアップされるときに確立される。そのためＣＡＡ１７３は認証および許可のためにデジタル証明書を採用する。基本的に、ＣＡＡ１７３はデータストア１６１への要求１８９に応答して検索されるＯＤＳＩＤ／ＳＰＩマッピング１９１に基づいて認証および許可を行う。

そのユーザーが認証されたら、ＣＡＡ１７３はＯＤＳ許可１８７を統合ハブ１４１に戻す。統合ハブ１４１がこの許可を受け取ってしまえば、統合ハブ１４１は認証ユーザーのためにＵＭＩコンポーネント１５１〜１５８からの要求と応答１９３を送受信できる。簡略化のために、請求処理コンポーネント１５７は要求１９７および応答１９９を表す個別のパスに細分される要求と応答１９３のみを図示している。最後に、認証および許可活動はＣＬＡ１７５に記録される１９５。

図５は、図２、図３および図４のテストセンター１５９の詳細なブロック図である。図５にも請求する主題に関わる例示的なデータ領域を表すデータストア１６１が含まれる。テストセンター１５９はリソースプロファイラーコンポーネント２０１、作業負荷プロファイラーコンポーネント２０３、シミュレーションエンジン２０５、シミュレーションデータ生成プログラム２０６、プロファイル比較器２０７、コンプライアンスモニター２０９を含む。

リソースプロファイラーコンポーネント２０１は、データストア１６１に格納されるリソースプロファイルデータ２１１をコンパイルする。リソースプロファイルデータ２１１は、ＯＤＳフレームワーク１２９内のあるクライアントのリソース割り当てと、その他利用できるリソースを表す。割り当てられたリソースの例には、処理サイクル、必要なサーバーの数、ネットワーク帯域幅、およびデータ記憶容量の必要条件を含むであろうが、これだけに限定されない。割り当てられたリソースの各々は、基本リソース割り当て、最大リソース割り当て、リソースコスト、およびクライアントの作業負荷需要に基づくリソースの動的な再割り当てのルールなど、それに関連するパラメータをもつ。利用できるリソースの例は利用できるプロセッサの種類である。例えば、ユーザーはインテルのアーキテクチャを採用する契約をしているかもしれないが、よりロバストなサーバー環境でそのアプリケーションがどのように機能するかを知る必要がある。

作業負荷プロファイラーコンポーネント２０３は、作業負荷プロファイルデータ２１３を生成し、これもデータストア１６１に格納される。作業負荷プロファイルデータ２１３は、顧客のリソースプロファイルデータ２１１で説明したようにあるクライアントの割り当てリソースに関してクライアントの代表的な作業負荷、またはリソースを利用する割り当てに対する作業負荷を表す。例えば、企業１０１（図１）のビジネスプロセス１１２３は代表的にＯＤＳフレームワーク１２９（図２）の請求処理コンポーネント１５７に１日あたり１００回の呼び出しを生成し、各要求１９７の平均が１キロバイトで、各応答１９９の平均が２キロバイトかもしれない。加えて、１トランザクションは、平均要求１９７から応答１９９を生成し、データ記憶装置１６１（図２および図４）の１メガバイトを生成するのに平均１００回の処理サイクルを要するかもしれない。この情報はビジネスプロセス１１２３の代表的な作業負荷として作業負荷プロファイルデータ２１３に格納される。各ビジネスプロセス１２３〜１２５は、その典型的なトランザクションや、各トランザクションの処理サイクル、帯域幅、およびデータ記憶容量などのパラメータの利用に対応するデータを作業負荷プロファイルデータ２１３にもつ。

ある顧客の実際の使用量に基づく作業負荷プロファイルデータ２１３に加えて、ワークフロープロファイルデータ２１３は、おそらく集合平均または予想平均に基づく仮想クライアントに対応するデータを含む。このように、潜在的な顧客は潜在的な作業負荷に対応するシナリオを生成して検証できるため、ＯＤＳフレームワーク１２９がビジネスを処理できるかを確かめるか、または潜在的なクライアントに十分であろうＳＬＡのあるレベルを予測できる。作業負荷プロファイルデータ２１３はまた、構成ファイルに保管して、将来参照するために様々な仮想シナリオを保存したり、必要なら修正できる。

シミュレーションエンジン２０５は、作業負荷プロファイルデータ２１３を採用して、クライアントまたはアドミニストレータがＧＵＩ（図示せず）のパラメータ操作で入力したクライアントの作業負荷の予定変更に基づき仮想作業負荷を生成する。例えば、請求処理コンポーネント１５７とのトランザクションの平均回数の数値に基づき、シミュレーションエンジン２０５は、平均ワークフローを１日あたり１００回のトランザクションから１日当たり２００回のトランザクションに増やす必要があるＯＤＳフレームワーク１２９のリソースを見積もることができる。シミュレーションは、細分性の程度を変えて生成できる。例えば、ビジネスプロセス１１２３は、ある決まった日の需要が急増することになることをクライアントが把握している場合もあるだろう。この場合、ワークフロープロファイルデータ２１３は、ビジネスプロセス１１２３で典型的に請求処理コンポーネント１５７とトランザクションを１００回実行し、レポーティングコンポーネント１５５の場合は５０回、メータリングコンポーネント１５８の場合は２００回を実行する等々を示す情報を含む。さらに、シミュレーションエンジン２０５は各その該当のコンポーネント１５１〜１５８に対応する仮想作業負荷を生成する。クライアントは様々なパラメータの組合せを保存して、パラメータ個々のセットが表すあるシミュレーションを返す、または格納したパラメータセットを変更するだけで微調整できる。この特徴により不必要なパラメータの再入力はなくなる。

ある仮想需要に対するＯＤＳフレームワーク１２９の応答の見積もりを作成することに加えて、シミュレーションエンジン２０５は実際にシミュレートしたデータを使って、ＯＤＳフレームワーク１２９に物理テストをすることができる。例えば、１００回の処理サイクルと１メガバイトのデータ記憶容量１６１を必要とするあるトランザクションの上記例を使うと、シミュレーションデータ生成プログラム２０６は適切な規模のダミープログラム、ネットワークデータパケット、シミュレートしたデータの塊を生成して、シミュレーションエンジン２０５が実際に処理サイクルを費し、ネットワークトラフィックを送信し、仮想負荷と等しい量でデータ記憶容量１６１の塊を割り当てることができる。このように、実際に利用できるリソースとインフラを使って仮想作業負荷をシミュレートする。例示的なデータ取得プロセス２４０を図７と合わせて以下に説明する。

シミュレーションエンジン２０５は、予測される作業負荷または仮想作業負荷の仮想スケジュールを作成して、タイミング問題の影響をシミュレーションに要因として考慮できるようにする。例えば、クライアントはウエブのトラフィックと対応する顧客からの製品注文が典型的に５：００ｐｍから６：００ｐｍの間にピークを迎え、レポート処理が５：００の混雑時の後まで遅れる可能性があることを把握しているかもしれない。この場合、様々な種類の処理を互いに分離して、多様な分離スキームの影響を評価できる。

代替実施例では、シミュレーションエンジン２０５は仮想シナリオと実際のリソースプロファイルデータ２１１および実際のデータが仮想シナリオにほぼ一致する第２クライアントに対応する作業負荷プロファイルデータ２１３との整合に基づいて、第１クライアントの仮想シナリオに予測を行える。

プロファイル比較器２０７は、シミュレーションエンジン２０５が作成する仮想作業負荷をリソースプロファイルデータ２１１と比較する。このように、テストセンター１５９は、十分なリソースが存在するかどうか、また仮想作業負荷を処理するのに既存のリソースで間に合うかどうかを判別する。この判別は、おそらくデータストア１６１の検索とシミュレーションそのものを行うのに必要な処理サイクル以外には、ＯＤＳフレームワーク１２９の実際のリソースになんの影響も与えずに行われることに注目するべきである。

コンプライアンスモニター２０９は、シミュレーションエンジン２０５とプロファイル比較器２０９の両結果を考慮して、予想される作業負荷または仮想作業負荷のいずれかが利用できないリソースを利用しようとするかどうか、またはデータストア１６１のＳＬＡデータ部分２１５に格納されるクライアントのＳＬＡの条件を違反するかどうかを判別する。複数の仮想作業負荷を作成し、それをシミュレーションエンジン２０５で評価できることで、クライアントは予定されるビジネスに適切なＳＬＡと、現在のＳＬＡがコスト効率がよいかどうかを判断できる。

シミュレーションエンジン２０５、プロファイル比較器２０７、およびコンプライアンスモニター２０９の処理が完了したら、ＯＤＳフレームワーク１２９はクライアントに結果を知らせる。

図６は、規定のワークフローがシステムのリソースに対して与える影響の予測を生成した後、その予測をクライアントのサービス品質保証契約と比較するシミュレーション・比較プロセス２２０のフローチャートである。プロセス２２０は「シミュレーション開始」ステップ２２１から始まり、処理はすぐに「リソースプロファイルの検索」ステップ２２３まで進み、そのプロセスでデータストア１６１（図２、図４、および図５）からあるクライアントのリソースプロファイルデータ２１１（図５）を検索する。図５と合わせて上記で説明したように、リソースプロファイルデータ２１１はＯＤＳフレームワーク１２９（図２）における、あるクライアントのリソース割り当てと関連パラメータを表す。

制御はさらに「作業負荷プロファイルの検索」ステップ２２５に進み、プロセス２２０がステップ２２１でリソースプロファイルデータ２１１を検索したクライアントに対応する作業負荷プロファイルデータ２１３を検索する。図５と合わせて上記で説明したように、作業負荷プロファイルデータ２１３は、顧客のリソースプロファイルデータ２１１で説明したようなクライアントの割り当てリソースに関してそのクライアントの代表的な作業負荷を表す。さらに、様々なパラメータがあるシミュレーションに影響を与える対応の重要性および優先順位属性もしくは重要性または優先順位属性をもつことがある。

あるクライアントのリソースプロファイルデータ２１１と作業負荷プロファイルデータ２１３を検索し終えたら、制御は「作業負荷プロファイルの修正」ステップ２２７に進み、クライアントは仮想シナリオまたはウエブサイトアクセスの需要の急増などの予定されるワークフローを表すために、検索したワークフロープロファイルデータ２１３のパラメータを修正できる。すなわち、ワークフロープロファイルデータ２１３を修正することによって、クライアントはクライアントの実際のワークフローに予想される変更をテストできる。ワークフロープロファイルデータ２１３への変更は、ＧＵＩ（図示せず）を介して行われ、その作成と操作はプログラミング技術の熟練者には理解されるはずである。また、代替シナリオ、およびその対応する作業負荷プロファイルデータ２１３は構成ファイルに保管し、ステップ２２５の間にプロセス２２０にロードされ、必要ならステップ２２７で修正できる。

クライアントがステップ２２７で所望のパラメータを修正し終えたら、制御は「動作のシミュレート」ステップ２２９に進み、プロセス２２０はクライアントのリソースプロファイルデータ２１１で定義したリソースに実施した場合の推定ワークフローをシミュレートする。シミュレーション動作ステップ２２９は、図７と合わせて以下で詳細に説明する。次に、制御は「動作をＳＬＡと比較」ステップ２３１に進み、まず、ＳＬＡデータ２１５（図５）をデータストア１６１から検索した後、ステップ２２９で行ったシミュレーション動作の結果をクライアントのＳＬＡデータ２１５と比較する。

制御はさらに「ＳＬＡは十分か？」ステップ２３３に進み、プロセス２２０はステップ２２９で計算した推定ワークフローがクライアントのＳＬＡで決めたクライアントのリソースの限度を超えているかどうかを判別する。推定ワークフローがクライアントのＳＬＡを超えていなければ、クライアントにそのことを通知して、制御は「シミュレーション終了」ステップ２３７に進み、処理は完了する。ステップ３３５で推定ワークフローがＳＬＡで決めたクライアントの限度を超えている場合、制御は「新ＳＬＡの生成」ステップ２３５に進み、ＳＬＡデータ２１５がシミュレーションの結果に適合するようにＳＬＡデータ２１５を修正する。加えて、プロセス２２０は、シミュレーションが予測した必要なサービスレベルに伴うコストを計算するために、請求処理コンポーネント１５７（図２および図４）と対話できる。

修正したＳＬＡデータ２１５をさらにクライアントに提示して、クライアントがＯＤＳフレームワーク１２９が契約の範囲内で予想作業負荷を処理できるようにクライアントのＳＬＡを修正するかどうかを判断できるようにする。あるシミュレーションに基づいて、複数の適合するＳＬＡ候補をそのそれぞれのコストと共にクライアントに提案できる。例えば、シミュレーションは、インテルのアーキテクチャ契約からサーバーベースの契約に切り換えることによりクライアントのビジネスがより満足できる可能性を高められよう。代わりの方法では、プロセス２２０は、必要なレベルのＳＬＡを予測する代わりに、クライアントが契約を違反する前に、あるＳＬＡが許容できる最大作業負荷を予測する。

図７は、図６のシミュレーション動作ステップ２２９に対応する例示的なシミュレーション動作プロセス２４０のフローチャートである。プロセス２４０は「シミュレーション動作の開始」ステップ２４１から始まり、制御はすぐに「ソースの判別」ステップ２４３に進む。ステップ２４３で、プロセス２４０は過去のシミュレーションデータを走査して、負荷とＯＤＳフレームワーク１２９の中の影響を受けるリソースに対する負荷の影響を見積もるのに、仮想シナリオに関して、現在のクライアントまたは同様なクライアントのいずれかからのデータが十分にあるかどうかを判別する。負荷と負荷の影響は過去データの異なる２側面であり、次のステップで両方の十分性を検討しなければならない。

過去のデータが十分にある場合、制御は「データ検索」ステップ２４７に進み、データストア１６１から過去のデータを検索する。十分にない場合には、制御は「データ生成」ステップ２４９に進み、プロセス２４０はプロセスの次のステップのために適切なテストデータを作成する。適切なテストデータは、ダミークライアントのファイルやトランザクションなど実際にシミュレートしたデータでも、十分なサイズのランダムデータの塊だけでもよい。当然、過去のデータがある程度はあるが、意義あるシミュレーションとするには十分ではない場合、制御はステップ２４５からステップ２４９に進み、必要なデータのみを生成することになる。

ステップ２４７でデータを検索して、ステップ２４９でデータを生成して、または両方の組合せのいずれかでデータを取得し終えたら、制御は「実際のリソースか？」ステップ２５１に進み、プロセス２４０はＯＤＳフレームワーク１２９に対するシミュレートしたデータの負荷を計算するか、フレームワーク１２９のリソースに対する負荷を実際に作成するかを判別する。この決定はアドミニストレータまたはユーザーいずれかの選好によることができる。例えば、アドミニストレータは、閑散時の間のみ実際のリソースを利用するシミュレーションを許可して、他の時間帯は計算したシミュレーションだけを実行すると判断するかもしれない。

ステップ２５１で、プロセス２４０がシミュレーションに実際のリソースを利用すると判断したら、制御は「シミュレーションの実行」ステップ２５５に進み、検索および生成もしくは検索または生成したデータを実際に使ってパケットを送信し、処理サイクルを生成し、データストア１６１の一部を占有する等々する。ステップ２５５の間、ＯＤＳフレームワーク１２９のリソースに対する負荷の影響を判別するための関連情報を収集する。ステップ２５１で、プロセスが実際のリソースを利用しないことにした場合、制御は「シミュレーションの計算」ステップに進み、ＯＤＳフレームワーク１２９の負荷の影響に関する関連情報を、検索および生成もしくは検索または生成したデータに基づいて推測する。最後に、ステップ２５３および２５５から、制御は「シミュレーション動作終了」ステップ２５７に進み、プロセス２４０が完了する。

本発明は、開示される実施例の以下の詳細な説明を以下の図面と合わせて考えれば、よりよい理解が得られる。

請求する主題を組み込む例示的なユニバーサル管理インフラ（ＵＭＩ）アーキテクチャのブロック図である。請求する主題を実装するオンデマンドサービス（ＯＤＳ）フレームワークのブロック図である。図２で紹介した統合ハブの詳細なブロック図である。図２のＯＤＳフレームワークの統合ハブと他の様々なコンポーネントとの相互関係を図示するブロック図である。図２のＯＤＳフレームワークのテストセンターコンポーネントのブロック図である。規定のワークフローがシステムに対して与える影響の予測を生成した後、予想をクライアントのサービス品質保証契約と比較するシミュレーションプロセスのフローチャートである。図６のシミュレーションプロセスの一部を詳しく図示した、例示的なシミュレーション操作プロセスのフロー図である。

Claims

利用できるコンピューティングリソースのセットから動的に割り当てたコンピューティングリソースのサブセットを有するユーティリティコンピューティング環境でサービスレベルを予測する方法で、前記方法が、サービス品質保証契約に従い割り当てた第１サブセットのコンピューティングリソースに対応するリソースプロファイルを作成するステップと、企業の需要プロファイルを表す作業負荷プロファイルをロードするステップと、リソースプロファイルを使って作業負荷プロファイルの処理をシミュレートして、サービスレベルの結果を出すステップとを有する方法において、リソースプロファイルリソースサブセットをサービス品質保証契約に従いシミュレーション中に修正する、方法。
サービスレベルの結果とサービス品質保証契約とを比較するステップと、コンピューティングリソースプロファイルがサービス品質保証契約に対応する予想サービスレベルで作業負荷プロファイルを処理するかどうかの信号を出すステップとをさらに有する、請求項１に記載の方法。
コンピューティングリソースのサブセットが、クライアントのアカウントに割り当てられる処理リソースとメモリーリソースを含む、請求項１または請求項２に記載の方法。
サービス品質保証契約が、基本リソース割り当て、最大リソース割り当て、リソースコスト、および作業負荷需要に基づきリソースを動的に再割り当てするルールを含む、請求項１から３のいずれかひとつに記載の方法。
シミュレーションステップがピーク以外の時間帯に自動的に実行するよう計画される、請求項１から４のいずれかひとつに記載の方法。
サービスレベル需要の充足に伴うコストを判断するステップをさらに有する、請求項１から５のいずれかひとつに記載の方法。
リソースプロファイルのコンピューティングリソースのサブセットが通信帯域幅を含む、請求項１から６のいずれかひとつに記載の方法。
作業負荷プロファイルを、第２クライアントのアカウントの実際の需要プロファイルを表す第２作業負荷プロファイルと比較するステップをさらに有し、シミュレーションステップが比較ステップの結果に基づく、請求項１から７のいずれかひとつに記載の方法。
コンピューティングリソースプロファイルがサービス品質保証契約に対応する予想サービスレベルで作業負荷プロファイルを処理できない場合、修正したサービス契約を生成するステップをさらに有し、修正したサービス品質保証契約が予想サービスレベルで作業負荷プロファイルを処理することを含む、請求項１から８のいずれかひとつに記載の方法。
作業負荷プロファイルがスケジューリング情報を含み、シミュレーションステップが処理時にスケジューリング情報を組み込む、請求項１から９のいずれかひとつに記載の方法。
作業負荷プロファイルが、リソースの優先順位と個々のリソースの重要性の一方または双方に対応する情報を含む、請求項１から１０のいずれかひとつに記載の方法。
作業負荷プロファイルを構成ファイルからロードすることを含む、請求項１から１１のいずれかひとつに記載の方法。
利用できるコンピューティングリソースのセットから動的に割り当てられたコンピューティングリソースのサブセットを使って、企業の需要を満たすサービス品質保証契約を結ぶユーティリティコンピューティング環境でサービスをシミュレートするシステムであって、コンピューティングリソースのセットの中から割り当てられたサブセットと、クライアントのアカウントの仮想需要プロファイルを表す作業負荷プロファイルをロードするロジックと、コンピューティングリソースのサブセットを使って作業負荷プロファイルの処理をシミュレートして、サービスレベルの結果を出すロジックとを有する、システム。
サービスレベルの結果をサービス品質保証契約と比較するロジックと、コンピューティングリソースプロファイルがサービス品質保証契約に対応する予想サービスレベルで作業負荷プロファイルを処理できるかどうかを判断するロジックとをさらに有する、請求項１３に記載のシステム。
リソースプロファイルのコンピューティングリソースのサブセットが、処理リソースとメモリーリソースとを有する、請求項１３または請求項１４に記載のシステム。
コンピューティングリソースプロファイルが、基本リソース割り当てと、最大リソース割り当てと、リソースコストと、作業負荷需要に基づいてリソースを動的に再割り当てするルールとをさらに有する、請求項１５に記載のシステム。
リソースプロファイルのコンピューティングリソースのサブセットが通信帯域幅をも有する、請求項１５に記載のシステム。
作業負荷プロファイルを、第２クライアントのアカウントの実際の需要プロファイルを表す第２作業負荷プロファイルと比較するロジックをさらに有し、シミュレーションロジックで作成するシミュレーションが前記比較するロジックの結果に基づく、請求項１３から１７のいずれかひとつに記載のシステム。
コンピューティングリソースプロファイルがサービス品質保証契約に対応する予想サービスレベルで作業負荷プロファイルを処理できない場合、修正したサービス契約を生成するロジックをさらに有し、修正したサービス品質保証契約が予想サービスレベルで作業負荷プロファイルを処理する、請求項１３から１８のいずれかひとつに記載のシステム。
作業負荷プロファイルがスケジューリング情報を含み、シミュレーションロジックが処理時にスケジューリング情報を組み込む、請求項１３から１９のいずれかひとつに記載のシステム。
利用できるコンピューティングリソースのセットから動的に割り当てられたコンピューティングリソースのサブセットを使って、企業の需要を満たすサービス品質保証契約を締結するユーティリティコンピューティング環境において、サービスレベルのコンプライアンスを予測するプログラムであって、該プログラムがコンピュータに、利用できるコンピューティングリソースのセットのうち割り当てられたサブセットに基づきコンピュータリソースプロファイルを作成する機能と、クライアントのアカウントの仮想需要プロファイルを表す作業負荷プロファイルをロードするコンピュータリソースプロファイルを使って作業負荷プロファイルの処理をシミュレートしてサービスレベルの結果を出す機能と、メモリーに格納され、サービスレベルの結果とサービス品質保証契約とを比較する機能と、コンピューティングリソースプロファイルがサービス品質保証契約に対応する予想サービスレベルで作業負荷プロファイルを処理できるかどうかを信号を出す機能とを実現させるプログラム。