JP2006048703A - トランザクションベースのパフォーマンスモデルの自動的な妥当性検査および較正 - Google Patents

Abstract

【課題】トランザクションベースのパフォーマンスプラニングを正確に実行する。
【解決手段】インフラストラクチャのモデル１１０が、そのインフラストラクチャを監視するように設計された既存管理ツール１２０によって供給されるデータ１２３を使用して作成され、自動的に構成される。これらの自動的に構成されたモデル１０３を使用して、現在の構成または他の潜在的な構成でインフラストラクチャのパフォーマンスをシミュレートする。シミュレーションからの結果と測定されたデータを比較することによって、自動的に妥当性検査および較正を行う。
【選択図】図１

Description

トランザクションベースのパフォーマンスモデルの自動構成に関する。

コンピュータシステムインフラストラクチャは、多くの会社の最も重要な資産の１つになってきた。これは、ネットワークベースのサービスに強く頼る会社について特にそうである。円滑で信頼できる動作を保証するために、かなりの量のリソースが、コンピュータシステムインフラストラクチャの獲得および維持に投資される。通常、コンピュータシステムインフラストラクチャの各サブシステムは、パフォーマンスカウンタなど、そのサブシステムに特化したコンポーネントによって監視される。その特化したコンポーネントによって生成されるデータを、そのサブシステムの専門知識を有する管理者が分析して、そのサブシステムが円滑に動作していることを保証することができる。

成功している会社は、多くの場合、顧客の需要についていくためにその能力を改善し、拡張しなければならない。理想的には、そのような会社のコンピュータシステムインフラストラクチャは、この変化するビジネス環境に常に適合できなければならない。実際には、既存インフラストラクチャのパフォーマンスを分析し、査定できるようになるのに、大量の労力と専門知識を要する。たとえば、ある会社が、ある種のトランザクションの増加を期待する場合、しばしば、この増加を処理するために既存インフラストラクチャのパフォーマンスをどのように拡張するかを判定するために、パフォーマンスプラニングが必要である。

パフォーマンスプラニングを実行する形の１つが、アナリストに相談することである。ワークロードデータが、サブシステムごとに入手可能である場合があるが、アナリストが、既存インフラストラクチャのパフォーマンスを高めるためにどのコンポーネントを追加または再構成する必要があるかを予測できるようになるために、各システムのかなりの知識および大量の労力が必要である。専門知識および労力に関するかなりの要件のゆえに、パフォーマンスプラニングを実行するためにアナリストを雇うことは、通常は、高価な提案である。

パフォーマンスプラニングを実行するもう１つの形が、使用可能な分析ツールを使用して、ワークロード増大に関する要件を予測することである。しかし、現在使用可能な普通のツールの多くは、ヒストリカルデータから単純に外挿するプログラムであり、全く正確でも柔軟でもない。また、予測された要件を引き渡すコンポーネントを選択するために、主観的決定を行わなければならない。

パフォーマンスプラニングを正確に実行できるユーザフレンドリなツールは、これまで当業者によって発見されていなかった。

本発明の上記および他の特徴および利益は、添付図面に鑑みて読まれる次の詳細な説明からよりよく理解される。

本明細書に記載のシステム、方法、およびデータ構造は、トランザクションベースのパフォーマンスモデルの自動構成に関する。インフラストラクチャを監視するように設計された既存管理ツールによって提供されるデータを使用して、インフラストラクチャのモデルが、作成され、自動的に構成される。これらの自動的に構成されるモデルを使用して、現在の構成または他の潜在的な構成でインフラストラクチャのパフォーマンスをシミュレートすることができる。

以下で説明する自動化パフォーマンスモデル構成システムは、パフォーマンスモデリングを効率的で正確に実行することを可能にする。このシステムは、ユーザが、さまざまな種類の分析を素早く、コスト効率のよい形で実行することを可能にする。たとえば、本明細書で説明するシステムを使用して、ハードウェアコンポーネントとソフトウェアコンポーネントの両方を含む現在のインフラストラクチャに関するパフォーマンス分析を実行することができる。このシステムは、情報テクノロジ（ＩＴ）インフラストラクチャの最新のまたは過去の配備を表すデータをさまざまな構成データベースからインポートすることができる。このモデル構成は、システムのパフォーマンス分析のベースラインとして働くことができる。分析の種類に、キャパシティプラニング、ボトルネック分析等を含めることができる。キャパシティプラニングに、システムの将来の使用量要件を予測し、システムがこれらの要件を満足するのに十分なキャパシティを有することを保証するプロセスが含まれる。ボトルネック分析に、システムのどのコンポーネントが最大キャパシティに最も近い状態で動作しているかを判定するために既存システムを分析するプロセスが含まれる。これらは、通常、システム全体のキャパシティを増やさなければならない場合に最初に交換される必要があるコンポーネントである。

本明細書で説明するシステムは、ｗｈａｔ−ｉｆ分析の実行にも使用することができる。ベースラインモデルを使用することによって、ユーザは、構成に対する１つまたは複数の変更を伴うインフラストラクチャのパフォーマンスを予測することができる。ｗｈａｔ−ｉｆシナリオの例に、ワークロードの増加、ハードウェア構成パラメータおよび／またはソフトウェア構成パラメータに対する変更、および類似物が含まれる。

本明細書で説明するシステムは、さらに、自動化キャパシティレポート作成に使用することができる。たとえば、ユーザは、システムが自動キャパシティプラニングレポートを作る特定のタイムインターバルを定義することができる。このタイムインターバルが経過した時に、システムは、最後のレポート作成期間のデータをインポートし、自動的にモデルを構成する。次に、システムは、構成されたモデルを使用してシミュレーションを実行し、システムの将来のキャパシティに関するレポートを作成する。システムは、システムのキャパシティが次のレポート作成期間に不十分になる場合にアラームを送出することができる。

本明細書で説明するシステムは、動作トラブルシューティングに使用することができる。たとえば、ＩＴ管理者に、パフォーマンス閾値を超えたことを動作管理アプリケーションによって通知することができる。管理者は、本明細書に記載のシステムを使用して、システムの現在の構成を表すことができる。次に、管理者は、シミュレーションを実行して、パフォーマンスアラームがキャパシティ問題の原因であるか否かを識別することができる。具体的に言うと、管理者は、パフォーマンスアラームが、システムの固有のキャパシティ限度によってまたは、追加のアプリケーションが他のユーザによってシステムで実行されているなど、他の要因によって引き起こされたか否かを判定することができる。

図１に、トランザクションベースパフォーマンスモデルを自動的に構成する例のシステムを示す。一実施形態で、この例のシステムに、自動化モデル構成モジュール１００およびシミュレーションモジュール１３０が含まれ、これらは、図１では例示のために別々のモジュールとして示されている。実際の実施形態では、自動化モデル構成モジュール１００およびシミュレーションモジュール１３０を、単一のコンポーネントに組み合わせることができる。この例のシステムは、さまざまな構成でインフラストラクチャ１１０のパフォーマンスをシミュレートするために、インフラストラクチャ１１０をモデリングし、イベントおおよびトランザクションをエミュレートするように構成されている。

インフラストラクチャ１１０は、１つまたは複数のネットワークによって接続された装置のシステムである。インフラストラクチャ１１０は、ビジネスエンティティが、従業員、顧客、ベンダ、パートナ等へネットワークベースのサービスを提供するのに使用することができる。図１からわかるように、インフラストラクチャ１１０に、サーバ１１１、ストレージ１１２、ルータおよびスイッチ１１３、ロードバランサ１１４等、さまざまな種類の装置を含めることができる。装置１１１〜１１４のそれぞれに、アプリケーション、オペレーティングシステム、または他の種類のソフトウェアなど、１つまたは複数の論理コンポーネントを含めることもできる。

管理モジュール１２０は、インフラストラクチャ１１０を管理するように構成されている。管理モジュールに、変更および構成管理（ＣＣＭ）アプリケーションまたは動作管理（ＯＭ）アプリケーションなど、インフラストラクチャ１１０に関連するデータを収集し、処理するハードウェアコンポーネントまたはソフトウェアコンポーネントを含めることができる。たとえば、管理モジュール１２０に、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ（ＭＯＭ）、Ｓｙｓｔｅｍ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｅｒ（ＳＭＳ）、Ｓｙｓｔｅｍ Ｃｅｎｔｅｒスイートの製品等、ＭＩＣＲＯＳＯＦＴ（登録商標）社によって開発されたサーバ管理ツールを含むことができる。通常、管理モジュールによって提供されるデータは、インフラストラクチャ１１０の管理および監視に使用される。たとえば、システム管理者は、管理モジュール１２０によって提供されるデータを使用して、通常の基準でシステムパフォーマンスを保守することができる。この例では、管理モジュールによって供給されるデータが、シミュレーション用のモジュールの自動作成にも使用される。

管理モジュール１２０は、インフラストラクチャ１１０に関連するさまざまな種類のデータを提供するように構成されている。たとえば、管理モジュール１２０を、インフラストラクチャ１１０の論理トポロジからのアプリケーションコンポーネントのリスト、トランザクションワークフロー、ユーザワークロードからのパラメータ名のリスト、アクションコスト等の定数入力を提供するように構成することができる。管理モジュール１２０を、インフラストラクチャ１１０の物理トポロジ、論理トポロジから物理ハードウェアへのアプリケーションコンポーネントの論理マッピング、またはユーザワークロードからのパラメータの値等の構成可能入力を提供するように構成することができる。

管理モジュール１２０に、特定の分散サーバアプリケーションの構成に関する情報を返すように特に記述されたディスカバリアプリケーションを含めることもできる。たとえば、ディスカバリアプリケーションに、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒ、およびＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）Ｓｅｒｖｅｒ用のＷＭＩイベントコンシューマ等を含めることができる。これらのディスカバリアプリケーションは、特定の応用例のためのＣＣＭ／ＯＭの特化されたバージョンと考えることができる。しかし、これらのアプリケーションは、通常、ＣＣＭ／ＯＭサービスとしてではなく、オンデマンドで実行される。ディスカバリアプリケーションを使用して、ＣＣＭ／ＯＭデータベースについて説明されたものに類似する形でパフォーマンスモデルを構成するのに必要な物理トポロジ、論理マッピング、およびパラメータ値を入手することができる。ＣＣＭ／ＯＭデータベースを、各ディスカバリアプリケーション用にカスタマイズされた変換ステップと共に使用することができる。データは、データベースから抽出されるのではなく、直接に返すことができる。しかし、この方法は、ディスカバリアプリケーションが実行される間の余分な遅延を伴う可能性がある。

データストア１２３は、管理モジュール１２０によって供給されるデータを格納するように構成されている。データは、１つまたは複数の動作データベース、またはデータウェアハウス等、いかなる種類のデータ構造で編成することができる。データストア１２３に、インフラストラクチャ１１０の物理トポロジおよび論理トポロジに関するデータを含めることができる。データストア１２３に、ワークロード、トランザクションワークフロー、またはアクションコストに関するデータも含めることができる。そのようなデータは、Ｅｖｅｎｔ Ｔｒａｃｉｎｇ ｆｏｒ ＷＩＮＤＯＷＳ（登録商標）（ＥＴＷ）またはＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｔｒａｃｅｓなど、イベントトレーシング技法によって作られたトレースの形で実施することができる。

自動化モデル構成モジュール１００は、インフラストラクチャ１１０に関する情報を入手し、シミュレーションのためにインフラストラクチャ１１０の各コンポーネントのモデル１０３を自動的に作成し、構成するように構成されている。モデル１０３は、シミュレーションモジュール１３０への入力として働く。

自動化モデル構成モジュール１００は、インフラストラクチャ１１０と相互作用し、ネットワークディスカバリを実行して、モデルを構成するデータを取り出すことができる。しかし、自動化モデル構成モジュール１００は、通常、インフラストラクチャ１１０の管理コンポーネントによって収集された情報をストアする動作データベースおよびデータウェアハウスからデータを入手するように構成される。たとえば、自動化モデル構成モジュール１００は、データストア１２３からデータを取り出すことができ、このデータストア１２３には、管理モジュール１２０によって供給されるデータが含まれる。

自動化モデル構成モジュール１００は、シミュレーションモジュール１３０への入力のための任意の種類のモデルを提供することができる。一実施形態で、自動化モデル構成は、物理トポロジ、論理トポロジ、ワークロード、トランザクションワークフロー、およびアクションコストに関する、インフラストラクチャ１１０のモデルを生成する。

インフラストラクチャ１１０の物理トポロジをモデリングするデータに、各コンポーネントの機能およびコンポーネントを相互接続する方法を含む、シミュレートされるハードウェアのリストを含めることができる。詳細のレベルは、通常、パフォーマンスデータを簡単入手できるレベルと一致するように選択される。たとえば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムは、パフォーマンスカウンタを使用して、パフォーマンスデータを表すことができる。これらのカウンタは、通常、ＣＰＵ、ネットワークインターフェースカード、およびディスクドライブのレベルまで列挙される。自動化モデル構成モジュール１００は、物理トポロジ記述内の個々のＣＰＵ、ネットワークインターフェースカード、およびディスクドライブとしてシステムを表すことによって、そのようなシステムをモデリングすることができる。各コンポーネントタイプは、そのコンポーネントでのイベントに要する時間を計算するのに使用される、一致するハードウェアモデルを有することができる。したがって、ＣＰＵコンポーネント型は、ＣＰＵハードウェアモデルによって表され、このモデルでは、計算など、ＣＰＵアクションに要する時間が計算される。

自動化モデル構成モジュール１００は、階層的なＥｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（ＸＭＬ）フォーマットを使用して、ハードウェア情報をエンコードし、サーバに物理的に含まれる装置のコンテナとしてサーバを表すことができる。コンポーネントは、テンプレートを用いて記述することができ、このテンプレートは、そのコンポーネントの機能をエンコードすることができる。たとえば、「ＰＩＩＩ Ｘｅｏｎ ７００ＭＨｚ」テンプレートは、７００ＭＨｚのクロックスピードで動作するＩｎｔｅｌ社のＰＩＩＩ Ｘｅｏｎ ＣＰＵのパフォーマンスおよび機能をエンコードする。コンポーネントが、命名され、この階層的な形で記述された後に、物理トポロジ記述に、コンポーネントの間のネットワークリンクも含めることができる。物理トポロジ記述は、対応するネットワークのプロパティによってタグ付けされたコンポーネント名の対のリストとして表現することができる。１台のサーバに複数のネットワークインターフェースカード（ＮＩＣ）が存在する場合に、使用される特定のＮＩＣを指定することもできる。下は、例示的な物理トポロジモデリングに関するコードである。

インフラストラクチャ１１０の論理トポロジのデータモデリングに、モデリングされるアプリケーションのソフトウェアコンポーネント（またはサービス）のリストと、コンポーネントが物理トポロジに記述されたハードウェアにどのようにマッピングされるかの記述を含めることができる。ソフトウェアコンポーネントのリストは、アプリケーションモデルの一部として供給することができる。たとえば、ｅ−コマースウェブサイトのアプリケーションモデルに、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｉｃｅｓなどのウェブサーバを表す１つのアプリケーションコンポーネントと、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳＱＬ Ｓｅｒｖｅｒなどのデータベースサーバを表すもう１つのアプリケーションコンポーネントを含めることができる。各アプリケーションコンポーネントの記述に、アプリケーションコンポーネントが実行のために必要とするハードウェアアクションを含めることができる。

ハードウェアへのアプリケーションコンポーネントの論理−物理マッピングは、各アプリケーションコンポーネントを実行するサーバ（物理トポロジで記述された）の、ロードバランシングがサーバ間でどのように実行されるかの記述を伴うリストを使用して表すことができる。これが、必ずしも１対１マッピングでないことに留意されたい。単一のアプリケーションコンポーネントが、複数のサーバに広がる場合があり、単一のサーバが、複数のアプリケーションコンポーネントをホスティングする場合がある。下は、例示的な論理トポロジモデリングに関するコードである。

インフラストラクチャ１１０のワークロードをモデリングするデータに、シミュレートされるシステムのパフォーマンスに影響する数値パラメータを定義する、名前／値対のリストを含めることができる。たとえば、上で説明したｅ−コマースウェブサイトに、同時ユーザ数、異なるトランザクションを実行する頻度などのパラメータを含めることができる。下は、ワークロードモデリングに関する例のコードである。

一実施形態で、自動化モデル構成モジュール１００は、管理モジュール１２０によって供給されたデータストア１２３内の既存データを用いてインフラストラクチャ１１０のモデルを自動的に構成するように構成されている。たとえば、自動化モデル構成モジュール１００は、物理トポロジ、論理トポロジから物理ハードウェアへのアプリケーションコンポーネントの論理マッピング、およびワークロードからのパラメータの値を自動的に構成することができる。通常、自動化モデル構成モジュール１００は、まず、一般的な項目でハードウェアまたはソフトウェアを記述したテンプレートとして、モデルを作成することができる。次に、自動化モデル構成モジュール１００は、ハードウェアモデルがどのように接続されるか、ソフトウェアモデルがどのように構成され、または使用されるか等、モデリングされるアイテムの特定のインスタンスを反映するようにモデルを構成する。

シミュレーションモジュール１３０は、自動化モデル構成モジュール１００によって生成され、および構成されたモデルを使用するインフラストラクチャ１１０によって実行されるアクションをシミュレートするように構成される。シミュレーションモジュール１３０は、インフラストラクチャ１１０のイベントをシミュレートするイベントベースのシミュレーションエンジンを含むことができる。たとえば、イベントに、ソフトウェアコンポーネントのアクションを含めることができる。イベントは、ユーザロードに従って生成され、その後、基礎になるハードウェアによって実行される。各イベントに要する時間を計算し、イベント間の依存性を考慮に入れることによって、モデリングされるハードウェアおよびソフトウェアのパフォーマンスの諸態様がシミュレートされる。

上で図１に関して説明したシステムは、どのＩＴインフラストラクチャにおいても使用することができる。たとえば、通常のエンタープライズＩＴ環境は、複数の全世界スケールのデータセンタを有し、数百台のサーバが複雑なネットワークに編成されている。ユーザが、そのような環境の構成を手動でキャプチャすることは、多くの場合困難である。通常、ユーザは、その環境の小さいサブセットをモデリングすることだけを要求される。この状況であっても、モデリングプロセスは、労働集約的である。本明細書に記載のシステムは、イベントベースシミュレーションに関するパフォーマンスモデリングを、広範囲のユーザの基礎が使用できるようにする。このシステムは、エンタープライズ管理ソフトウェアから入手可能な既存の情報を使用することによって、パフォーマンスモデルを自動的に構成する。

モデルの構成を自動化し、単純化することによって、本明細書に記載のシステムは、ユーザがさまざまな状況でパフォーマンスプラニングを実行することを可能にする。たとえば、ユーザが、現在の配備を表すモデルを素早く構成できるようにすることによって、このシステムは、ユーザが、素早く変化する環境内であっても、毎週または毎日のキャパシティレポートを作成できるようにする。頻繁なキャパシティレポート作成によって、ＩＴプロフェッショナルが、発生する前にパフォーマンス問題を予測し、訂正するなど、インフラストラクチャを積極的に管理できるようになる。

上記で説明したシステムは、ユーザが、広範囲のパフォーマンス要因を分析するために組織のより大きい部分を簡単にモデル化することも可能にする。たとえば、メールサーバ配備が、複数のデータセンタに影響する可能性がある。関連する構成データが使用可能である場合に、メールサーバを有する既存インフラストラクチャのモデルを自動的に構成することができ、そのモデルを使用して、たとえばアジアのオフィスからアメリカ本社へ電子メールが送信されるまでの待ち時間の判定など、エンドツーエンドのトランザクションの待ち時間を予測することができる。そのような分析の利点のもう１つの例が、アジア／アメリカＷＡＮリンクのメールトラフィックに起因する使用率の計算である。

本明細書に記載のシステムを使用するパフォーマンス分析は、データセンタの動作のトラブルシューティングにも使用することができる。たとえば、ＭＯＭなどの動作管理ソフトウェアが、メールサーバでの遅い応答に関してアラートを発行することができる。ＩＴプロフェッショナルは、このシステムを使用して、システムの現在の状態を表すモデルを自動的に構成し、期待されるパフォーマンスをシミュレートし、その問題がキャパシティ問題に起因するか他の原因に起因するかを判定することができる。

図２に、図１に示された自動化モデリングモジュール１００の例示的なコンポーネントを示す。図２に示すように、自動化モデリングモジュール１００に、物理トポロジモデリングモジュール２０１、論理トポロジモデリングモジュール２０２、およびイベント分析モジュール２０３を含めることができる。モジュール２０１〜２０３は、例示のみのために示されている。実際の実施形態では、モジュール２０１〜２０３が、通常は１つのコンポーネントに統合される。

物理トポロジモジュール２０１は、インフラストラクチャの物理トポロジをモデリングするように構成されている。物理トポロジは、ＣＣＭアプリケーション、ＯＭアプリケーション、またはディスカバリアプリケーションから直接に取り出されたデータから導出することができる。たとえば、データを、図１の管理モジュール１２０から取り出すことができる。通常、物理トポロジは、管理モジュール１２０の動作データベースまたはデータウェアハウスから取り出されたデータを使用することによって導出される。

取り出されたデータに、通常、サーバおよびそれに含まれるハードウェアコンポーネントのリスト、およびネットワークの物理トポロジ（たとえば、サーバ間の相互接続）等、インフラストラクチャのモデルを構成する情報が含まれる。物理トポロジモジュール２０１を、取り出されたデータをシミュレーションに使用可能なモデルを作成するためのフォーマットに変換するように構成することもできる。たとえば、取り出されたデータを、ＸＭＬフォーマットに変換することができる。物理トポロジモジュール２０１を、余分な情報をフィルタリングするように構成することもできる。たとえば、メモリサイズが通常はシミュレーションについて直接にモデル化されない場合であっても、取り出されたデータにインフラストラクチャのコンポーネントのメモリサイズが含まれる場合がある。物理トポロジモジュール２０１を、さらに、取り出されたデータの「セマンティック拡張（ｓｅｍａｎｔｉｃ ｅｘｐａｎｓｉｏｎ）」を実行するように構成することができる。たとえば、物理トポロジモジュール２０１が、単純なストリングとして表すことができるディスクドライブの名前を、ディスクサイズ、アクセスタイム、回転速度、または類似物の値を有する適当なテンプレートに変換することができる。物理トポロジモジュール２０１を、異なるディスカバリアプリケーションからのさまざまな型のフォーマットのデータを変換するように構成することができる。

論理トポロジモデリングモジュール２０２は、ソフトウェアコンポーネントを、管理モジュール１２０によって供給されるデータから導出された物理ハードウェアモデルにマッピングするように構成されている。ＣＣＭアプリケーションとＯＭアプリケーションの両方からのデータを使用することができる。たとえば、ＣＣＭアプリケーションは、ＭＩＣＲＯＳＯＦＴ（登録商標）Ｅｘｃｈａｎｇｅ ＳｅｒｖｅｒがＥｘｃｈａｎｇｅシステムでの複数の別個の役割の１つを有する場合であっても、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒの単純な存在または不在を記録することができる。対照的に、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒの監視に使用されているＯＭアプリケーションに、Ｅｘｃｈａｎｇｅ Ｓｅｒｖｅｒの役割などのフル構成情報を含めることもでき、この情報を使用して、Ｅｘｃｈａｎｇｅのパフォーマンスモデルが対応するアプリケーションコンポーネントを宣言することができる。論理トポロジモデリングモジュール２０２を、基礎になるフォーマットのデータをシミュレーションモデルに使用可能なフォーマットに変換し、モデリングされていないアプリケーションの存在など、不要な情報をフィルタリングするように構成することができる。

ワークロードモデリングモジュール２０３は、ユーザワークロードからパラメータの値を導出するように構成されている。通常、値は、管理モジュール１２０から取り出されたデータから導出される。取り出されたデータに、監視されている１つまたは複数のアプリケーションが経験したワークロードに関する現在の情報またはヒストリカル情報が含まれる場合がある。通常のパフォーマンスカウンタに、同時ユーザ数、要求されている異なるトランザクションの個数等を含めることができる。必要な場合に、変換ステップを実行して、取り出されたデータの基礎になるフォーマットからシミュレーション用のモデルに使用可能なフォーマットに変換し、数学的変換を実行することができる。たとえば、ＯＭデータベースが、１時間の間に要求された異なる種類のトランザクションの個々の個数を記録する場合があるが、モデルが、この同一の情報を、１時間のトランザクションの総数と、異なる種類のそれぞれのトランザクションの比率とで表す場合がある。

図３に、インフラストラクチャのパフォーマンスをシミュレートする例のプロセス３００を示す。ブロック３０１で、インフラストラクチャに関連するトポロジデータおよびパフォーマンスデータを識別する。識別されるデータを、インフラストラクチャの１つまたは複数の管理アプリケーションによって供給することができる。データは、管理アプリケーションによって直接に、または動作データベースもしくはデータウェアハウスを介して供給することができる。

ブロック３０３で、識別されたデータを処理して、インフラストラクチャのモデルの入力を入手する。たとえば、トポロジデータを、ＸＭＬフォーマットなど、モデリングモジュールまたはシミュレーションモジュールによって使用可能なフォーマットに変換することができる。パフォーマンスデータを、ワークロードを表すのにすぐに使用されるフォーマットに変換することができる。

ブロック３０５で、モデリング入力を使用して、インフラストラクチャのモデルを自動的に構成する。インフラストラクチャのモデルを自動的に構成する例のプロセスを、図４で説明する。短く言うと、モデルは、物理トポロジ、論理トポロジ、ワークロード、トランザクションワークフロー、アクションコスト等に関するデータなど、管理アプリケーションからの既存データを使用して構成される。

ブロック３０７で、モデルに基づいて１つまたは複数のシミュレーションを実行する。このシミュレーションは、インフラストラクチャの物理コンポーネントおよび論理コンポーネントのモデルを用いてイベントおよびアクションをエミュレートすることに基づいて実行される。シミュレーションは、インフラストラクチャの現在の構成または潜在的な構成に対して実行することができる。自動的に構成されたモデルを使用してインフラストラクチャをシミュレートする例示的なプロセスを、図５で説明する。ブロック３０９で、シミュレーションの結果を出力する。

図４に、インフラストラクチャのモデルを自動的に構成する例のプロセス４００を示す。プロセス４００は、図１および２に示された自動化モデル構成モジュール１００によって実施することができる。ブロック４０１で、インフラストラクチャの管理アプリケーションによって供給された物理トポロジデータを使用して、ハードウェアモデルを構成する。物理トポロジデータに、インフラストラクチャの装置のハードウェア構成およびこれらの装置のコンポーネントを含めることができる。物理トポロジデータに、装置がどのように接続されるかに関する情報も含めることができる。

ブロック４０３で、インフラストラクチャの管理アプリケーションによって供給された論理トポロジデータからソフトウェアモデルを決定する。論理トポロジデータに、インフラストラクチャの装置のソフトウェアコンポーネントおよびソフトウェアコンポーネントの構成に関する情報を含めることができる。ブロック４０５で、ソフトウェアモデルをハードウェアモデルにマッピングする。

ブロック４０７で、インフラストラクチャの管理アプリケーションから、ワークロードデータ、トランザクションワークフローデータ、およびアクションコストデータを決定する。具体的に言うと、このデータは、ハードウェアコンポーネントおよびソフトウェアコンポーネントによって実行されるイベントおよびアクションと、これらのイベントおよびアクションに関連する時間およびワークロードを定義することができる。ブロック４０９で、データをモデルに統合する。たとえば、ソフトウェアモデルとハードウェアモデルとを、定義されたイベントおよびアクションを実行する時のモデルのパフォーマンスを反映するように構成することができる。

図５に、自動的に構成されたモデルを使用してインフラストラクチャをシミュレートする例のプロセス５００を示す。プロセス５００は、図１に示されたシミュレーションモジュール１３０によって実施することができる。ブロック５０１で、シミュレーションを実行する命令を受け取る。この命令に、シミュレーションをどのように実行するかに関する情報を含めることができる。たとえば、この命令によって、インフラストラクチャの既存の構成または変更された構成を使用してシミュレーションを実行することを指定することができる。この命令によって、インフラストラクチャの現在のワークロードまたはインフラストラクチャの１つまたは複数のコンポーネントの異なるワークロードを使用するなど、シミュレーションのワークロードを指定することができる。

ブロック５０３で、既存インフラストラクチャのモデルを決定する。通常、モデルは、モデリングモジュールによって提供され、インフラストラクチャの現在の状態を反映するように自動的に構成される。判断ブロック５０５で、インフラストラクチャモデルの構成を変更するか否かに関する判定を行う。変更された構成を用いるインフラストラクチャのシミュレーションを実行して、その変更を実際に実施する前にパフォーマンス影響を予測することができる。構成変更がない場合には、プロセス５００はブロック５１３に移動する。

判断ブロック５０５に戻って、変更を行うという判定が行われた場合に、プロセス５００は、ブロック５０７に移動し、インフラストラクチャに対する変更を識別する。変更は、物理トポロジ、論理トポロジ、またはパフォーマンスパラメータなど、インフラストラクチャの任意の態様に関するものとすることができる。ブロック５０９で、識別された変更に従ってモデルを変更する。ブロック５１３で、変更されたモデルを使用してシミュレーションを実行する。

図６に、本明細書で説明するシステムおよび方法を実施する例示的なコンピュータ装置６００を示す。最も基本的な構成で、コンピューティング装置６００に、通常、少なくとも１つの中央処理装置（ＣＰＵ）６０５およびメモリ６１０が含まれる。

コンピューティング装置の正確な構成およびタイプに応じて、メモリ６１０を、揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュメモリなど）、またはこの２つの組合せとすることができる。さらに、コンピューティング装置６００は、追加の特徴／機能性も有することができる。たとえば、コンピューティング装置６００に、複数のＣＰＵを含めることができる。本明細書で説明する方法は、コンピューティング装置６００の任意の処理装置によって任意の形で実行することができる。たとえば、本明細書で説明するプロセスを、両方の複数のＣＰＵによって並列に実行することができる。

コンピューティング装置６００に、磁気ディスク、磁気テープ、光ディスク、または光テープを含むがこれに限定されない追加ストレージ（取り外し可能および／または固定）も含めることができる。そのような追加ストレージが、図６ではストレージ６１５によって示されている。コンピュータストレージ媒体に、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータなどの情報の格納の方法または技術で実施された、揮発性および不揮発性、取り外し可能および固定の媒体が含まれる。メモリ６１０およびストレージ６１５は、すべて、コンピュータストレージ媒体の例である。コンピュータストレージ媒体に、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリテクノロジ、ＣＤ−ＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気ストレージ装置、あるいは、所望の情報を格納するために使用でき、コンピューティング装置６００によってアクセスできる他のすべての媒体が含まれるが、これらに制限はされない。そのようなコンピュータストレージ媒体のどれでも、コンピューティング装置６００の一部とすることができる。

コンピューティング装置６００に、この装置が他の装置と通信できるようにする通信装置６４０も含めることができる。通信装置６４０は、通信媒体の一例である。通信媒体は、通常、搬送波または他のトランスポート機構などの変調されたデータ信号内でコンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータを実施し、すべての情報配布媒体を含む。用語「変調されたデータ信号」は、信号内で情報を符号化する形でその特性の１つまたは複数を設定または変更された信号を意味する。限定ではなく例として、通信媒体に、有線ネットワークまたは直接配線接続などの有線媒体と、音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体が含まれる。本明細書で使用される用語コンピュータ読み取り可能媒体に、コンピュータストレージ媒体と通信媒体の両方が含まれる。本明細書で説明する方法を、データ、コンピュータ実行可能命令、および類似物など、任意の形でコンピュータ読み取り可能媒体に符号化することができる。

コンピューティング装置６００は、キーボード、マウス、ペン、音声入力装置、接触入力装置などの入力装置６３５も有することができる。ディスプレイ、スピーカ、プリンタなどの出力装置６３０も含めることができる。これらの装置のすべてが、当技術分野で周知であり、詳細な説明を必要としない。

上述したように、本明細書で説明するシステム、方法、およびデータ構造は、使用可能な管理アプリケーションからのデータを使用して、インフラストラクチャモデルを自動的に構成することができる。これらのシステム、方法、およびデータ構造を、さらに、自動妥当性検査較正特徴を組み込むことによって機能強化することができる。モデルを、ユーザによって選択される正確さの度合まで妥当性検査し、較正することができる。

インフラストラクチャのモデルを自動的に構成した後に、妥当性検査を実行して、モデルのパフォーマンス予測がユーザ指定の範囲まで正確であることを確認することができる。指定された正確さの範囲が達成されない場合には、較正を実行して、指定された精度を達成するためにモデルの非構成可能な態様を変更することができる。ハードウェア、トポロジ、ワークロード、または類似物の表現などのモデルの構成可能な態様は、通常、較正によって変更されない。較正は、アクションコスト、バックグラウンドロード、またはモデルテンプレートの一部である他のパラメータなど、モデルに関連するパラメータを変更することができる。

アクションコストは、特定のハードウェアリソースでの特定のトランザクションステップのリソース要件を表す数値である。アクションコストは、使用されるハードウェア装置の種類に固有の項で測定される。通常、アクションコストは、装置の特定のインスタンスと独立である。たとえば、ＣＰＵのアクションコストは、計算のメガサイクル単位で測定でき、ディスクのアクションコストは、必要なディスク転送の回数および転送されるデータの量に関して測定することができる。異なるＣＰＵおよびディスクは、同一のアクションコストを必要とするアクションを処理するのに、異なる量のシミュレートされた時間を要する可能性がある。アクションコストは、通常、パフォーマンスラボラトリでシミュレートされるアプリケーションのベンチマークを行うことによって、インフラストラクチャモデルの開発中に入手される。

理想的には、特定の装置の種類（たとえば、ＣＰＵ）のすべてのアクションコストを、単一の数値（たとえば、メガサイクル）を使用して記述でき、その装置の種類のすべてのインスタンスにまたがって正確にスケーリングすることができる。実際には、スケーリングが単純でない場合がある。たとえば、２倍のクロックスピードを有するＣＰＵで同一のアクションを実行することが、半分の時間でのアクションの完了をもたらさない場合がある。この非線形スケーリングに影響するすべての要因を考慮に入れることは、多くの場合非実用的である。すべての可能な要因を考慮に入れた非常に複雑なモデルが提供される場合であっても、そのモデルが、さまざまな理由から使用されない場合がある。たとえば、最終的な結果を完了するのに必要な時間および／またはメモリが、単純なモデルよりはるかに多くなり、極端に長いシミュレーション時間がもたらされる可能性がある。また、必要な入力変数の数が、単純なデータ収集およびモデル構成には多すぎる可能性がある。アプリケーションおよびハードウェアに指示するのに大量の時間または労力を費やすことは、望ましくない可能性がある。

モデルの精度と複雑さとの間の難しいトレードオフを多少なりとも解決するために、較正を行って、この両方の利益を得ることができ、たとえば、単純で高速なモデルを、さまざまな範囲の入力に関する指定された最低限の精度で使用することができる。妥当性検査を実施して、モデリング精度が十分であるか否かを判定することができる。較正を実施して、使用される入力の特定の組をよりよく反映するようにアクションコストを調整することができる。

バックグラウンドロードは、実際面においてしばしば出会うが、通常は普通のモデルで実施されないもう１つの変数である。バックグラウンドロードは、ワークロードモデルの一部でない、アプリケーションによるハードウェアリソースの使用率を指す。たとえば、ウィルスチェッカが、ウィルスシグネチャについてディスクの内容をスキャンするために、すべてのディスク読み取りに対する余分なＣＰＵオーバーヘッドを課す可能性がある。ローカルエリアネットワーク（ＬＡＮ）が、もう１つの例である。というのは、ＬＡＮが、単一のアプリケーション専用であることが非常に稀であるからである。しばしば、ＬＡＮは、複数のアプリケーションを実行する複数のコンピュータの間で共有され、これらのアプリケーションのそれぞれが、ネットワークに対するそれ自体の影響を有する。時々、ユーザが、このバックグラウンドロードに気付く場合があり、たとえばＬＡＮの使用率を固定値として指定することにより、最初のモデル構成の一部としてこのロードを含める場合がある。しかし、より多くの場合、ユーザは、これらの余分な影響を知らず、パフォーマンスモデルが不正確に見えることだけを知っている。

さらに、あるバックグラウンドロードが、一定ではなく、ワークロードに依存する場合がある。ウィルスチェッカがその例である。通常、ディスク動作は、ＣＰＵと独立にモデリングされる。ディスクモデルで「ＣＰＵコスト」フィールドが提供されない場合がある。ウィルスチェッカの影響は、ディスクアクセスアクションを含むすべてのトランザクションに関するＣＰＵコストの増加として捉えることができる。

パフォーマンスモデルの精度の妥当性検査を行うために、モデリングされるアプリケーションのパフォーマンスをキャプチャすることができる。パフォーマンスデータは、アプリケーションおよびそのアプリケーションが実行されるハードウェア装置のパフォーマンス態様を測定する統計カウンタを使用してキャプチャすることができる。たとえば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）によって公開される「パフォーマンスカウンタ」を使用することができる。他の例に、ハードウェア測定値（たとえば、ＣＰＵによって使用されるＣＰＵ時間の量）と、平均トランザクションレートなどのパフォーマンスを測定するためにアプリケーションによって作成されるカウンタとが含まれる。

モデルは、通常、モデルの構成情報の一部としてパフォーマンスカウンタ測定値を使用するように開発される。モデルの抽象化のレベルは、パフォーマンス情報の可用性と一致するように選択することができる。モデルの出力は、これらのパフォーマンスカウンタに関して表すこともできる。たとえば、出力に、シミュレートされる一連のトランザクション中に特定のＣＰＵにおいて、ＣＰＵ時間がどれだけ使用されるか、およびアプリケーションが維持する平均トランザクションレートを含めることができる。

上記で説明したように、自動構成中に、モデリングされるアプリケーションに関する情報を、ＯＭデータベースからインポートすることができる。そのようなデータベースの例が、Ｍｉｃｒｏｓｏｆｔ Ｏｐｅｒａｔｉｏｎ Ｍａｎａｇｅｒ（ＭＯＭ）であり、このＭＯＭには、モデリングされるアプリケーションのパフォーマンスカウンタのヒストリカル値が含まれる。これらのカウンタは、入力ワークロード（たとえば、処理されるトランザクションの個数）および観察された結果（たとえば、消費されたＣＰＵ時間）の両方をキャプチャすることができる。

妥当性検査に、自動的に構成されたモデルを使い、ＯＭデータベースからヒストリカルに観察されたパフォーマンスカウンタ値（たとえば、１時間あたりのトランザクション数）をモデルへの入力にセットし、パフォーマンスシミュレーションを実行し、予測された出力をヒストリカルに観察されたパフォーマンスカウンタ値（たとえば、消費されたＣＰＵ時間）と比較することを含めることができる。予測されたパフォーマンスカウンタ値について、パフォーマンスモデルの精度を、相対項（すなわち、パーセンテージ）と絶対項（たとえば、メガサイクル数）の両方で表すことができる。必要な精度を、これらの項のいずれかで表すことができる。さらに、パフォーマンスカウンタをグループ化することができる。必要な精度を、グループに全体として適用することができる。たとえば、ユーザは、すべてのディスク帯域幅予測が２０％以内の精度であること、またはフロントエンドウェブサーバでのすべてのＣＰＵメガヘルツ予測が５％以内の精度であることを要求することができる。

パフォーマンスカウンタを、カウンタのスコープに基づいて２つのカテゴリに編成することができる。一部のカウンタは、特定のアプリケーションに適用される。たとえば、メールサーバアプリケーションは、そのアプリケーションによって引き起こされるＣＰＵ使用量を公開することができる。これらのカウンタを、アプリケーション固有カウンタとして定義することができる。オペレーティングシステム（ＯＳ）は、システムの総合パフォーマンスを監視し、総ＣＰＵ使用量などのカウンタを公開する責任も負う。これらのシステムワイドカウンタに、システムで実行されるすべてのアプリケーションの使用量を含めることができる。モデルに誤差がある場合に、これらのカウンタを使用して、誤差の源を判定することができる。誤差は、ワークロード依存誤差およびワークロード独立誤差として特徴を表すことができる。

ワークロード依存誤差に、アプリケーションワークロードの関数として変化する大きさを有する誤差が含まれる。たとえば、ワークロード依存誤差は、不正なモデリング仮定、スタートアップ効果（たとえば、コールドキャッシュ）、アプリケーション飽和（たとえば、ロック）、または欠けているトランザクションクラス等から生じる可能性がある。欠けているトランザクションクラスは、非常に一般的である。というのは、通常、サポートされるすべてのトランザクションではなく、最も一般的なトランザクションだけがモデリングされるからである。ワークロード依存誤差の効果は、アプリケーション固有カウンタをモデリング結果と比較することによって計算することができる。たとえば、メールサーバアプリケーションの予測されたＣＰＵ使用率が１０％であり、そのアプリケーションの実際のＣＰＵ使用量が１５％である場合に、５％の差が、ワークロード依存誤差である。

ワークロード独立誤差は、ワークロードと独立である大きさを有する誤差を含む。ワークロード依存誤差は、通常、ＯＳからのオーバーヘッドから、またはモデルに含まれない他のワークロードから生じる。たとえば、単一のサーバ装置が、メールサーバアプリケーションとファイルサーバアプリケーションとの両方を実行する場合がある。メールサーバアプリケーションモデルは、ファイルサーバアプリケーションによって引き起こされる装置使用を考慮に入れていない可能性がある。ワークロード独立誤差の影響は、システムワイドカウンタをアプリケーション固有カウンタと比較することによって計算することができる。たとえば、メールサーバアプリケーションのＣＰＵ使用量が２５％であり、総ＣＰＵ使用量が３５％である場合に、１０％の差が、一定のロードまたはバックグラウンドロードに起因するワークロード独立誤差である。

必要な精度限度のデフォルト値を、基礎になるモデルの一部として供給することができる。たとえば、ディスクモデルが、実際に特に正確であることがわかっている場合に、デフォルトの必要精度を５％に設定することができる。というのは、この範囲外の値が、バックグラウンドロードなどの隠れた基礎になる要因の結果である可能性が高いからである。逆に、ＣＰＵモデルが、より不正確であることがわかっている場合に、デフォルトの必要精度を２０％に設定して、結果からの不正確な結論を避けることができる。

精度をグループ化して、情報の表示を単純にし、ユーザロードを減らすことができる。たとえば、データセンタ内のすべてのフロントエンドウェブサーバの精度を示すのではなく、妥当性検査ユーザインターフェースに、ある範囲の精度（たとえば、「−６％〜７％」）を有する、フロントエンドウェブサーバの単一の表現を示すことができる。さらに、カラーコーディングによって、インターフェースの可用性をさらに高めることができる。たとえば、十分にユーザが指定した限度内にある精度を有するパフォーマンスカウンタを緑で表示し、限度に近いものをオレンジで表示し、限度を超えるものを赤で表示することができる。

ユーザが、すべてのパフォーマンスカウンタの観察に対する予測精度に満足した場合に妥当性検査プロセスは完了し、ユーザは、そのモデルを使用して、最終的な結果でより高い信頼性を有するｗｈａｔ−ｉｆ分析を実行することができる。そうでない場合に、１つまたは複数のサイクルの較正およびそれに続く妥当性検査を実行することができる。

較正には、基礎になるパフォーマンスモデルのアクションコストまたはバックグラウンドロードのいずれかを調整して、モデル妥当性検査の精度を改善することが含まれる。不正確さの基礎になる原因がワークロードに依存する（すなわちワークロード依存誤差）場合、アクションコストの調整によって望みの効果をもたらすことができる。基礎になる原因が、たとえば別のアプリケーションがある比率のＬＡＮ帯域幅を使用しているなど、ワークロードに依存しない場合、アクションコストの調整は、妥当性検査のために選択されたものを除くワークロードのすべてのレベルについて不正確な結果をもたらす可能性がある。

バックグラウンドロードの調整を行って、ワークロード依存バックグラウンドロードの概念を含めることにより、モデル妥当性検査の精度を高めることができる。バックグラウンドロードは、定数または現在のワークロードを乗じられるスカラとすることができる。バックグラウンドロードは、アクションごとのレベルではなく、装置ごとのレベルで適用することができる。しかし、モデルがアプリケーションのパフォーマンスを低く見積もる事例をキャプチャするために、バックグラウンドロードを拡張して、負のロードを含めることができる（すなわち、装置のキャパシティを調整し、その結果、モデルに基づき、あるべき値より高くなるようにする）。負のロードは、装置がモデルの結果よりよくスケーリングされる事例を考慮に入れるために使用することができる。

バックグラウンドロードの概念を、シミュレーションに使用されている基礎になるハードウェアモデルのリソースキャパシティに適用することができる。バックグラウンドロードは、一定（すなわち、ワークロード独立誤差）とするか、ワークロード依存とすることができ、正または負の係数として働くことができる。バックグラウンドロードを調整する訂正量は、基礎になるモデルに依存する。モデルが線形である場合、訂正係数による乗算で十分である場合がある。しかし、より複雑なモデルは、適当な訂正係数を決定するために、独自の計算を必要とする場合がある。デフォルトの精度値と同様に、これらの計算を、ハードウェアモデル内の較正機能として提供することができる。この較正機能を、観察された不正確さを有する装置の種類毎に呼び出すことができる。較正機能は、不正確さを０にするためにリソースコストを変更する適当な係数または定数量を返すことができる。

不正確さ誤差が観察された後に、分析を実行して、不正確さのどの部分が定数効果に起因し、どの部分がワークロード依存効果に起因するかを判定することができる。この判定は、２つのシミュレーションの結果を比較することによって行うことができる。この判定は、アプリケーション固有カウンタの結果とシステムワイドパフォーマンスカウンタの結果を比較することによって行うことができる。

シミュレーションによる不正確さの査定に、２つの異なるワークロード値を使用して２つのシミュレーションを実行するステップと、この２つのシミュレーションの不正確さが同一であるか変化するかを判定するステップとが含まれる。第２のシミュレーションに関して、前のワークロードの半分または２倍など、任意のワークロード変更を行うことができる。ワークロードを２倍にすることによって、個々のコンポーネントが飽和に近いので、非線形パフォーマンス効果がもたらされる可能性がある。たとえば、システム全体の挙動が普通は線形である場合であっても、挙動が指数関数的になる場合がある。したがって、第２のシミュレーションで半分のワークロードを使用することによって、多くの場合に、よりよい結果をもたらすことができる。しかし、第２のシミュレーションでワークロードを半分にすることは、最初のワークロードが非常に小さく、モデルがパフォーマンスカウンタの粒度のレベルに近づき、パフォーマンス効果がノイズで失われる可能性がある場合には望ましくない可能性がある。したがって、この解決策を使用する較正は、次のステップからなる。

ａ）異なるワークロード強度を用いて（たとえばワークロードを半分にして）シミュレーションを２回実行する。

ｂ）較正を必要とするモデリングされたハードウェア装置ごとに、
ｉ）観察されたパフォーマンスカウンタと第１および第２のシミュレーションの予測されたパフォーマンスカウンタを比較して、装置に定数バックグラウンドロードまたは変数バックグラウンドロードのどちらを適用しなければならないかを判定する。

ｉｉ）適当なハードウェアモデルの較正機能を呼び出し、定数または変数のバックグラウンドロード誤差を供給し、対応する定数または変数のバックグラウンドロード係数を得る。

ｉｉｉ）ロード係数を基礎になる装置に適用する。

シミュレーションによる不正確さの査定は、次のように表すことができる。
ｅ＝Ｉ・ｅ_v＋ｅ_c⇒ｕ_m−ｕ_p＝Ｉ・ｅ_v＋ｅ

ここで、Ｉはロードを表し、ｅは総誤差を表し、ｅ_cは定数誤差（たとえば、バックグラウンドロードに起因する）を表し、ｅ_vはロードに起因する可変誤差を表し、ｕ_pは予測された装置使用率を表し、ｕ_mは測定された装置使用率を表す。

上の式では、ｕ_m、ｕ_p、およびＩが既知である。２つのロードを用いてシミュレーションを実行することによって、２つの未知数を有する２つの式という単純な系がもたらされる。したがって、ｅ_vおよびｅ_cを簡単に決定することができる。

パフォーマンスカウンタを使用することによる不正確さの査定は、通常、同一の装置の使用率レベルの特徴を表す、アプリケーション固有パフォーマンスカウンタおよびシステムワイドパフォーマンスカウンタの対の可用性を必要とする。較正は、下記によって実行することができる。

ａ）バックグラウンドロードに起因する誤差を決定する（たとえば、予測された使用率カウンタからシステムワイドカウンタを引く）。その結果が、装置に適用される定数バックグランドロードである。

ｂ）ワークロード依存誤差を決定する（たとえば、予測された使用率カウンタからアプリケーション固有カウンタを引く）。その結果が、ロードの関数として適用されるバックグラウンドロードである。

ｃ）組み合わされたロード係数を基礎になる装置に適用する。

較正ステップを完了した後に、妥当性検査をもう一度実行することができる。

図７に、妥当性検査されたモデルを使用してインフラストラクチャのパフォーマンスをシミュレートする例示的なプロセス７００を示す。プロセス７００は、図３に示されたプロセス３００に類似するが、ブロック３０７以降に余分なステップを含む。

判断ブロック７０３で、自動的に構成されたモデルの妥当性検査を実行するか否かの判定を行う。行わない場合に、プロセス７００は、ブロック３０９で継続される。妥当性検査を実行する場合には、プロセス７００は、ブロック７０７に移動し、ここで、モデルの妥当性検査を行う。モデルを妥当性検査する例示的なプロセスを、図８に関して説明する。このプロセスは、次に、ブロック７０７に移動し、シミュレーションの結果を出力する。

図８に、インフラストラクチャのモデルを妥当性検査する例のプロセス８００を示す。ブロック８０３で、シミュレーションからの結果を識別する。ブロック８０５で、測定値からワークロードデータを判定する。測定されたワークロードデータは、インフラストラクチャの管理モジュールによって供給することができる。ブロック８０７で、シミュレーション結果を、測定されたワークロードデータと比較する。この比較から誤差を計算することができる。判断ブロック８０９で、誤差が許容可能なレベルであるか否かを判定する。そうである場合に、処理８００は、ブロック８１５に移動し、モデルの妥当性検査を行う。

判断ブロック８０９に戻って、誤差が許容可能なレベルでない場合に、処理８００は、ブロック８１１に移動し、インフラストラクチャの各装置のロード係数を決定する。ロード係数は、総合パフォーマンスカウンタによって供給されるデータとアプリケーション固有カウンタによって供給されるデータを比較することによって判定することができる。ロード係数は、２つの異なるワークロードレベルを用いて実行された２つのシミュレーションによって生成された結果から決定することもできる。これらの方法の例を、図９および１０に関して説明する。

ブロック８１３で、ロード係数を用いてモデルを較正する。たとえば、モデルを構成して、定数バックグラウンドロードとしてシミュレーション中のワークロード独立誤差を考慮に入れ、ワークロードレベルに基づいてワークロード依存誤差をスケーリングすることができる。ブロック８１５で、較正の後にモデルの妥当性検査を行う。ブロック８０９、８１１、および８１３のステップが、誤差が許容可能なレベルになるまで繰り返されることを理解されたい。

図９に、アプリケーション固有カウンタによって提供されるデータを使用して装置モデルを較正する例示的なプロセス９００を示す。ブロック９０３で、装置の使用率値をシミュレーションから識別する。ブロック９０７で、システムワイドカウンタによって供給されるデータを使用して、総誤差を決定する。たとえば、総誤差は、システムワイドカウンタによって供給される使用率値から、シミュレーションからの装置の使用率値を引くことによって決定することができる。総誤差は、ワークロード依存成分（たとえば、モデリングされていないアプリケーションロード）およびワークロード独立成分（たとえば、装置のＯＳによって生成されるロード）を含むバックグラウンドロードを表すことができる。このバックグラウンドロードが、シミュレーション中にモデルによって考慮されなかったので、このロードは誤差をもたらした。

ブロック９０９で、アプリケーション固有カウンタによって供給されるデータを使用して、ワークロード依存誤差を決定する。アプリケーション固有カウンタによって、アプリケーションの使用率が判定される。ワークロード依存誤差は、アプリケーションに関連するシミュレートされた使用率値と実際の使用率値の間の差から決定することができる。残りの総誤差は、ワークロード独立である定数誤差である。ブロック９１１で、定数誤差およびワークロード依存誤差から較正のロード係数を計算する。

図１０に、異なるワークロードレベルを用いて繰り返されたシミュレーションによって提供されるデータを使用して装置モデルを較正する例示的なプロセス１０００を示す。ブロック１００５で、２つのワークロードレベルからの測定された使用率値を識別する。ブロック１００７で、２つのワークロードレベルのシミュレートされた使用率値を決定する。ブロック１００９で、２つのワークロードレベルの総誤差を計算する。たとえば、総誤差は、測定されたデータからシミュレーション結果を引くことによって計算することができる。総誤差は、モデルによって考慮されていないバックグランドロードを表す。

ブロック１０１５で、ワークロード依存誤差を、２つのワークロードレベルの総誤差を比較することによって計算する。たとえば、総誤差が、２つのワークロードレベルで異なる場合に、その差は、ワークロードに依存する誤差を表す。残りの誤差は、ワークロード独立である。ブロック１０１７で、ワークロード独立誤差およびワークロード依存誤差からロード係数を決定する。

自動的に構成されたモデルの妥当性検査および較正を実施するために、図１および２に示された自動化モデリングモジュール１００を構成して、上で述べたプロセス８００、９００、および１０００を実施することができる。

本発明の好ましい実施形態を図示し、説明したが、本発明の趣旨および範囲から逸脱せずに、さまざまな変更を行えることを理解されたい。

トランザクションベースパフォーマンスモデルを自動的に構成する例のシステムを示す図である。 図１に示された自動化モデリングモジュールの例のコンポーネントを示す図である。 インフラストラクチャのパフォーマンスをシミュレートする例のプロセスを示す図である。 インフラストラクチャのモデルを自動的に構成する例のプロセスを示す図である。 自動的に構成されたモデルを使用してインフラストラクチャをシミュレートする例のプロセスを示す図である。 本明細書で説明するシステムおよび方法を実施する例示的なコンピュータ装置を示す図である。 妥当性検査されたモデルを使用してインフラストラクチャのパフォーマンスをシミュレートする例のプロセスを示す図である。 インフラストラクチャのモデルの妥当性検査を行う例のプロセスを示す図である。 アプリケーション固有カウンタによって提供されるデータを使用して装置モデルを較正する例のプロセスを示す図である。 異なるワークロードレベルを用いて繰り返されたシミュレーションによって提供されるデータを使用して装置モデルを較正する例のプロセスを示す図である。

Claims (32)

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. 前記シミュレーションからの結果と前記収集されたデータとの間の誤差を計算する手段と、
    前記誤差に少なくとも部分的に基づき前記モデルを自動的に較正する手段と
    をさらに備えたことを特徴とする請求項３１に記載のシステム。
    

Images