JP2008519322A - 電気通信サービスおよび／またはネットワーク管理用のプラットフォームにおけるリソースの管理方法、対応プラットフォーム、およびそのコンピュータ・プログラム生成物 - Google Patents

Abstract

本発明は、電気通信サービスおよびネットワークのリソースを管理する方法およびシステムに関する。本方法およびシステムは、ネットワーク上で所定のタスクを実行すべくプロセス機械（Ｈ）上の分散エージェント（Ａ１、Ａ２、Ａ３）によるプロセス（ＷＦ１、．．．、ＷＦｎ）の実行に関するものであり、プロセス（ＷＦ１、．．．、ＷＦｎ）におけるシステムが達成すべき目標およびリソース使用に対する制約を含む目標データを設定するステップと、エージェントによる計算リソースの使用状況およびプロセスの実行を監視するステップと、リソース使用状況およびプロセスの実行を表わす性能データを収集するステップと、収集された性能データを設定データと比較して、性能データが目標データを達成していない場合に違約を規定するステップと、前記比較に基づいて決定された違約を最小化すべくエージェント（Ａ１、Ａ２、Ａ３）によるプロセスの実行のためのリソースを再割当てするステップとにより特徴付けられる。

Description

本発明は、電気通信ネットワークおよび／またはサービスの管理を目的とするプラットフォームにおけるリソース管理方法に関する。特に、本発明は、電気通信ネットワークおよび／またはサービスの管理用プラットフォームにおけるリソース割り当て方法および対応する管理プラットフォームに関する。

通信ネットワーク／サービス分野において、階層的アーキテクチャで構成され、時としてエージェントを利用する動作支援システム（ＯＳＳ）等、複数の構成要素を含む管理用プラットフォームが提供されている。

例えば米国特許第６，２４３，３９６号明細書に、電気通信ネットワーク・リソースを制御する相互接続された管理局の多層階層アーキテクチャを有する通信ネットワーク管理システムまたはプラットフォームが開示されている。各々の局は、プロセスの実行に責任を負う多数のエージェントを有しており、これらは知的または単なる応答的エージェントであってよい。

公知のアーキテクチャにおいて、応答的エージェントは局のプラットフォーム部分に置かれ、知的エージェントは局の制御部分に置かれる。知的および応答的エージェントは、当該プラットフォームにＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）に機能を提供すべく機能構成要素に分類される。

国際公開第０１／０２９７３号パンフレットは、分散エージェントを調整するための集中型プロセス・コーディネータを含むプラットフォームの利用を教示しており、これは典型的には構成要素（エージェント）へのジョブの委譲、エージェントからの応答の収集等を含むワークフロー記述（フロー図と同様）を実行するワークフロー・エンジンにより実現される。
米国特許第６，２４３，３９６号明細書 国際公開第０１／０２９７３号パンフレット

出願人は、上記のアーキテクチャでは、エージェントがワークフロー・エンジンにより委譲されたジョブを実行することが保障されないと考える。実際に、計算能力等、エージェントが利用できるＩＴリソースには限界があり、プラットフォームに求められる業務目標や作業負荷に合致するにはＩＴリソースが十分であるとは限らない。

換言すれば、エージェントが利用できるＩＴリソース如何により、例えば顧客へのサービス提供等、エージェントにより実行されるタスクを必要とする所定の業務目標の達成が妨げられる場合がある。

例えば、タスクとして、規定されたプロセスを所定の持続期間より短い平均時間で完了すること、または一定の期限内に所定数のプロセスを完了することが挙げられる。

エージェントにかかる膨大な作業負荷により、エージェントが所定の平均時間または定められた期限内にタスクを完了することができなくなり、従って業務目標が達成されない恐れがある。

集中型プロセス・コーディネータを用いるエージェントに基づくアーキテクチャの別の問題は、国際公開第０１／０２９７３号パンフレットに開示されているように、コーディネータ自体がプラットフォームの動作のボトルネックになる点であり、柔軟性を向上させるべくコーディネータにワークフローを加えるエージェントから外出しされたプロセスロジックが増えるほど、コーディネータが遅くなる。これにより、実行に期限を有するプロセス等、業務性能目標を達成するためのアーキテクチャの能力が低下する恐れがある。

ＩＴリソース管理分野において、米国特許出願公開第２００３／０１６７２７０号明細書に、スケーラブルなアプリケーションのコピーのインスタンス生成を行なうホスト機を含む分散環境におけるリソース管理システムが開示されている。当該リソース管理システムは、アプリケーションのコピーに関する情報およびホストの性能に基づいて、ホスト群をまたがってスケーラブルなアプリケーションの選択されたコピーを起動、停止、または移動させる信号を生成する。

この種のソリューションは、少なくとも以下の理由により、プロセス・コーディネータまたはワークフロー・エンジンにより調整される分散型エージェント・アーキテクチャを含むプラットフォームには適していない。
−全てのエージェントが既にいくつかのタスクを実行している場合、緊急のタスクまたはアプリケーションを新たに実行するための空きエージェントが存在する余地がない。
−新規ワークフロー（すなわち新たな機能）が規定される都度、業務目標（例：業務プロセスの期限）を実現すべく、既知のシステムはアプリケーションのパラメータを測定して、全てのエージェントの挙動を調整すべく新たなモデルを構築する必要がある。
−既知のリソース管理システムは、複数のコピーにインスタンスが生成され得るアプリケーションまたは機能に対してのみ作用する。

本発明の目的は従って、電気通信サービスおよび／またはネットワークを管理するエージェント利用プラットフォームにおけるリソースを管理する方法を提供することであり、これにより所定の業務目標を達成すべくリソース使用状況における最適な性能を実現してプラットフォームの効率を向上させる。

本発明の他の目的は、プラットフォームの柔軟性を向上させながら性能向上を実現するために分散型プロセスロジックを有する管理プラットフォームである。

本発明によれば、これらの目的は、電気通信サービスおよび／またはネットワークを管理するプラットフォームにおけるリソース管理の方法により、かつ独立請求項に記述された特徴を有する管理プラットフォームにより実現される。

本発明のさらなる目的は、特許請求の範囲に記述されるように、電気通信管理プラットフォームの設定および運転を行なうコンピュータ・プログラム生成物またはコンピュータ・プログラムの組、電気通信ネットワークおよび方法である。

要約すれば、従来技術の短所を克服すべく、本発明は、所定の指標（例：主要業務指標）および目標により駆動される、予測および適応型の機構に基づく方法および対応プラットフォームを開示するものであり、管理プラットフォームにおけるＩＴリソースの使用状況の測定および自動制御を行なう。

好適には、本発明によるプラットフォームのアーキテクチャの特徴は以下の通りである。
−エージェントが提供する全ての機能を実装するエージェント内部のプロセス（ワークフローおよびルール）エンジンを提供することにより、エージェントが実行しなければならないジョブがワークフローの実行となる。ルールエンジンは、特定種類のジョブを実行すべくワークフロー・エンジンに結合することができる。
−プロセス記述を定義および保存してこれらの記述をエージェントに分散するための集中型プロセス記述データベースの提供、
−業務目標（例：ＳＬＡ、サービスレベル合意）および機能およびその集計（例：履行、保証、支払い請求等の業務プロセス領域への）の定義に基づく処理優先順位を含む目標データの指定を可能にする目標および制約コンソールの提供、
−プラットフォームの各エージェントにおける各々のプロセスの実行並びに業務プロセスによるワークフローの実行によるＩＴリソースの使用を監視、すなわち、例えば経過時間、実行頻度等を監視すべく構成された制御エージェントの提供、および、
−業務目標を最大限に達成すべく、指定された目標データ（業務目標）およびリソースの使用状況を示す監視された性能データに基づいて、適応型の方法でプラットフォームの各エージェントにＩＴリソースを再割当てすべく構成されたリソース割り当てモジュールの提供。

本発明の好適な実施形態によれば、リソースの再割当てルールを規定すべくグラフィカル・ユーザー・インターフェースとして再割り当てコンソールが提供されていると共に、監視コンソールが提供されていることにより、ＳＬＡの達成状況および対応ＩＴリソースの使用状況および関連コストの制御が可能になる点が好都合である。

エージェント内部にプロセス・エンジンを提供することが、全てのエンジンが集中型プロセス・コーディネータに置かれている場合にボトルネックを生じることなく柔軟性を向上させ、エージェント間でＩＴリソースを動的に割当てる際に有利な特徴であることがわかる。エージェント内のプロセス・エンジンにより、各々の機能実行（すなわちプロセスの実行）に際してエージェント内でのリソース使用状況（例：使用されたＣＰＵ時間またはＲＡＭ）を分析的に測定することが可能になる。

集中型データベースにおけるプロセス記述は、プラットフォーム横断的に各エージェントへそれらのプロセス・エンジン内で利用すべく分散され、プラットフォームの全ての動作機能と自動的に同期化が行なわれるため、ジョブのセマンティクスと協働するリソースの管理プロシージャを調整することが可能である。

実際には、電気通信サービスおよびネットワークを管理するプラットフォームの管理者は、プロセス・データベース内で１個以上のワークフローおよび／またはルールを規定するかまたは既存のものの組み合わせる任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能を構築することができ、次いで必要なときにエージェントが新規プロセス（ワークフローおよびルール）の定義を自動的に取得して実行することができる。自動的に、目標コンソールが新規プロセスに対するＳＬＡおよび優先順位の規定を可能にする。実行時に、制御エージェントは、新規プロセスのＳＬＡ傾向および対応ＩＴリソースの使用状況の制御を可能にして、再割り当てモジュールが全体構成を最適化できるように、すなわちエージェントにおけるワークフロー優先順位を変更するか、またはより多くの計算リソース（ＣＰＵ、メモリ等）を与える。

本発明によるリソース管理は好適には、分散されたモジュール（制御エージェント）と共に、集中型モジュール（マネージャ・モジュール）によりプラットフォーム内で実装される。集中および分散機能の組合せは、ソリューションの適応型機構の基礎となる。

本発明のさらなる特徴および利点を、添付図面に関して非限定的な例を用いて以下の記述においてさらに詳しく説明する。

図１に、本発明による電気通信サービスおよびネットワーク管理システムの例証的なアーキテクチャを示す。本システムは好適には、各々が１個以上のソフトウェア・エージェント（Ａ１、Ａ２、Ａ３）を含み得る複数のプロセスホスト機Ｈを含む分散プロセスアーキテクチャに実装されている。

本システム（またはプラットフォーム）は、ホスト機上で動作してプロセス記述の分散、動作の起動、管理統制等、各種の協調動作のために分散エージェントと対話するプログラムまたはプログラムの組を含む集中型制御モジュールまたはマネージャ・モジュールＭＭを含んでいる。マネージャ・モジュールＭＭはまた、好適にはシステム管理者等のユーザーと対話するためのグラフィカル・ユーザー・インタフェースを含んでいてよい。

本明細書において、プロセスという用語は、１個以上のワークフロー、１個以上のルールまたは、好適には１個以上のワークフローと１個以上のルールの組合せを表わすために用いられる。

ワークフローは、手続きのルールの組に従い、実行中にあるエージェントから別のエージェントへ情報またはタスクが渡される業務プロシージャの自動化されたものとして規定することができる。

ワークフローは、一連のタスク並びに代替的なまたは並列分枝を含むタスク間の時間的かつ論理的依存関係を有するフロー図を介して表わすことができる。ワークフロー記述を定式化するＸＰＤＬ（ＸＭＬプロセス記述言語）等の特殊言語が存在する。これらのルールは特定の組の条件／イベントが発生した際に実行すべきアクションの宣言である。

マネージャ・モジュールＭＭは、全てのプロセス、すなわちプラットフォームの挙動および機能的態様を表わすワークフローおよびルールを保存すべく構成されたプロセス記述データベースＰＤＢを含んでいる。

データベースＰＤＢはさらに、例えば、ワークフローおよびルールにより扱われるデータ・モデルを含んでいる。

当業者には知られているように、プロセス記述データベースＰＤＢは例えば、任意の従来型ネットワーク在庫管理システムのカタログ部分に関連付けられてよい。

図１のアーキテクチャは、多層エージェント・モジュール、例えば各々がいくつかのエージェントＡ１、Ａ２、Ａ３を含む３層を含んでいる。同一レベルに属しているエージェントは相互に接続していても、または互いに独立していてもよい。これらは、より高いレベルのエージェントがあれば、これに結合されている。より低いレベルにおいて、エージェントは、制御下にあるネットワーク要素（一般に通信ネットワークＮとして示す）、例えばＡＴＭスイッチ、あるいはメールサーバー・アプリケーションまたはＶＡＳサーバー・アプリケーション等の他のサービス・アプリケーションＡＰＰ、すなわち携帯電話の留守番電話サービス等の付加価値サービス・アプリケーションに結合されている。

マネージャ・モジュールＭＭは、例えば、通信バスＢを介してプラットフォームの他の動作支持システムＯＳＳに接続されている。

コーディネータとして機能しているマスター・エージェントＭＡ、あるいは実装方式の種類に応じて複数のマスター・エージェント群ＭＡ（図１に開示せず）が、マネージャ・モジュールＭＭに関連付けられた多層エージェント・アーキテクチャのルートに提供されている。

各エージェントＡ１、Ａ２、Ａ３は、プロセス・エンジンＰＥを含んでいて、プロセス・エンジンＰＥを用いるいくつかのプロセスの実行責任を負う。

プロセス・エンジンは、ワークフローおよび／またはルールを実行するソフトウェア・モジュールである。プロセス・エンジンの外部設置は性能低下を引き起こし得る遠隔起動を有することを意味するため、プロセス・エンジンＰＥは各エージェント内に埋め込まれていることが好都合である。

好適には、各エージェントのプロセスは、同レベルまたはより高いレベルを有する他のエージェントにより、外部から起動することができ、各エージェントが起動エージェントに提供するサービスに対応している。

任意の層におけるプロセス・エンジンは、例えば、ワークフローと、ワークフローおよびルールの各々を管理可能なルールエンジンの組合せであることを意図されている。例えば、プロビジョニングプロセスはワークフローとして表わす方が適している一方、アラームコリレーションはルールの組合せとして表わす方が適している。可能ならば、ワークフローを利用する方が、ルールの矛盾およびルールの管理を取扱う煩雑さが含まれないため好ましい。

図１に示す多層アーキテクチャは、異なるレベルでのプロセスの分割を可能にする。エージェントが配置可能であるレベルの数に制約がない。このように、可能な限り層の数を少なくすることと、分散型組織と集中型組織との間で自由にプロセスの割当てを許すことのトレードオフを見つけるべくアーキテクチャを設定することが可能である。この分割はまた、業務ビューからシステム・ビューまで、異なるサービス・ビューを提供することも可能にする。
以下において、ワークフロー・エンジンが好ましいと思われるが、ルールエンジンもまた適用可能である。

エージェント（マスター・エージェントおよびサブレベル・エージェントの両方）を実行している各ホスト機は好適には、１個以上の制御エージェントＣＡを含んでいる。これらは、ローカル・エージェント（すなわち当該ホストで動作しているエージェント）のリソース使用状況および性能の測定、並びにリソース管理の局所最適化の実行に責任を負うモジュールである。制御エージェントＣＡは、マネージャ・モジュールおよび他の制御エージェントに結合されていて、測定されたデータをマネージャ・モジュールおよび／または他の制御エージェントへ送信する。

以下にその構造を記述するマネージャ・モジュールＭＭは、プラットフォームの管理、構成、および制御に責任を負う。人間オペレータおよび外部ＯＳＳからの入力データを解析して、業績目標を満たすようにプラットフォームの構成を如何に調整するかを決定すべく構成されている。その主なタスクは以下の通りである。
プロセス記述およびデータ・モデルをプロセス・データベース（ＰＤＢ）からエージェントへ分散する、
制御エージェントから提供された情報を用いて、ホスト機上でのエージェントの分散、ドメイン管理（ネットワーク全体をエージェントに分割）、性能監視を含むプラットフォームの状態を監視する、
関連する制御エージェントとの対話を介してエージェントによるプロセスの実行用に割当てられたリソースを最適に使用すべくアクションを実行する（これらのアクションの例として、エージェント間の負荷バランシングの変更およびワークフローの優先順位の変更、すなわち１個以上のエージェント内の待ち行列ジョブの再スケジューリングがある）、
他の動作支援システムと同様、外部システムとの対話。

以下にその構造を記述するマスター・エージェントＭＡは、プロセスの実行の最上位レベル調整の責任を負う。実際には、最上位層のエージェントに課せられたプロセスには、サブ層エージェントに課せられたサブプロセスが含まれていてよい。さらに、（エージェント以外の）外部エンティティとの対話または下位層エージェントにより分散的には容易にまたは効率的に実行することができないエージェント同士の調整を必要とする機能を提供すべく特徴付けられたプロセスが存在する。エージェントにより実行されるプロセスは、分散的に実行する必要があるものである。

各エージェント（Ａ１、Ａ２、Ａ３）は、任意のＦＣＡＰＳ（故障、設定、課金、性能、セキュリティ）機能等、任意のネットワークもおよびサービス管理機能（すなわちプロセス）を支援することができる。これにより、例えば、日中はサービスプロビジョニングにより多くのエージェントを投入し、夜間はネットワークの最適化により多くのエージェントを投入する等、タスクの優先順位およびリソースへのニーズに基づいてエージェントの実行時にタスクのカスタマイズおよびエージェントへの機能の再割当てが可能になる。

エージェントにプロセス・エンジンＰＥの提供することにより、各機能（すなわちプロセス）によるリソースの使用状況並びに機能の起動生起を監視することが可能になる。これらのデータは、マネージャ・モジュールＭＭにより制御される自動プラットフォーム制御の主な情報源である。

各エージェント（Ａ１、Ａ２、Ａ３）は応答的および能動的な挙動の両方を示し、イベントにより生起されるだけでなく、プロセスを自発的に起動させる。

好適には、エージェント・モジュールは、例えばフォールト・トレランス問題に対応すべく配備が容易になるように制御エージェントまたはマネージャ・モジュールにより処理装置間を移動可能である。

図２に、本発明の好適な実施形態によるマネージャ・モジュールＭＭの内部構造を示す。

集中型マネージャ・モジュールＭＭは、例えばサブモジュールに編成されている。

サブモジュールのうち１個はＭＮＧ_ＣＮＳコンソールであり、一般に、管理コンソールＭＮＧ_ＣＮＳとして示される。好適な実施形態において、管理コンソールＭＮＧ_ＣＮＳは、以下のものを含んでいる。
−プラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに関連付けられた監視コンソールＭＣ、
−目標および制約コンソールＧＣ、
−再割り当てコンソールＲＣ、
−管理用コンソールにより管理される管理データを含む管理データベースＡＤＢが関連付けられている管理用コンソールＡＣ、
−サービス生成環境コンソールＳＣＣ
並びに
−容量計画モジュール（図示せず）、
−予測コンソール（図示せず）。

目標コンソールＧＣ、管理用コンソールＡＣおよびサービス生成コンソールＳＣＣは全て、プロセス記述データベースＰＤＢに結合されている。

マネージャ・モジュールＭＭは、目標および制約コンソールＧＣおよび再割り当てコンソールＲＣに直接結合されたリソース割り当てＲＡを含んでいる。

リソース割り当てＲＡはまた、例えば管理用データベースＡＤＢ、並びにプラットフォーム性能データを保持している性能データベースＰＦＭ_ＤＢに結合されている。

好適な実施形態において、マネージャ・モジュールＭＭはさらに、監視データ取得モジュールＭＤＭおよびプラットフォーム・コントローラＰＣを含んでいる。

監視データ取得モジュールＭＤＭは、プラットフォーム・コントローラＰＣから性能データベースＰＦＭ_ＤＢへ性能データを転送すべく構成されている。

さらに、リソース割り当ては、例えば、外部ＯＳＳと管理プラットフォームとの間の対話を監視する外部インタフェース・モジュールＩに結合されていてよい。

プラットフォーム・コントローラＰＣは、一般に、マネージャ・モジュールとエージェントとの間のメディエーターとして動作する。

特に、プラットフォーム・コントローラＰＣは、マネージャ・モジュールの外部にあるマスター・エージェントＭＡ（図示せず）、およびリソース割り当てモジュールＲＡとの接続を実装し、監視コンソールＭＣ、監視データ取得モジュールＭＤＭ、管理用コンソールＡＣおよび管理用データベースＡＤＢ、並びにプロセス記述データベースＰＤＢに結合されている。

目標および制約コンソールＧＣは、プロセス記述データベースＰＤＢに保存されているプロセスに関連付けられていて、合わせて目標データと呼ばれる業務目標（例：サービスレベル合意すなわちＳＬＡ）および制約の規定を意図としている。

サービスレベル合意すなわちＳＬＡは、業務プロセス・レベル品質の（契約締結または単に同意された）定量化である。ＳＬＡは、性能指標（平均実行時間、パーセンタイル値等）に基づいており、これらの指標の値がプラットフォームで保証される旨を宣言する。一般に、ＳＬＡはＳＬＡ目標（性能指標）およびＳＬＡ違約条項（ＳＬＡ目標と収集された性能データとの比較に基づくＳＬＡコスト関数）、例えばＳＬＡ違反の経済的違約の見積、を識別する特定の言語（「文法」）により記述することができる。

ＳＬＡは一般的な業務プロセス（例：ワークフロー）または（１個以上のワークフロー属性において定義可能な）その特化されたものの１個に関連付けることができ、その場合、特化されたものに対するＳＬＡは通常、ルート業務プロセスのＳＬＡを上書きする。

制約は、リソース使用状況に関するデータに注目する。これらは、好適には以下のものを含んでいる。
−保証すべき最低スループット、管理可能な最少数のネットワーク要素（より理解し易い業務測定基準を用いるために、パーセンテージではなく「スループット」という用語を用いるのが好適である）で表わされる、予め割当られたリソース、
−割当て可能なリソースの最大数（大域的リソースのコストまたはパーセンテージで表わされ、デフォルト値は例えば５０％）。
業務制約を変更する際に、予め割当られたリソースが割当て可能な最大容量を上回るか否かを検証することが必要である。

本発明の好適な実施形態によるリソース割り当てＲＡ（以下、再割り当てと呼ぶ）は集中型であって、プラットフォームを適応的に制御すべくエージェントへのリソース割当てを管理する。これは、例えば以下を受容すべく構成されている。
ｉ）目標コンソールＧＣからの業務目標。
ｉｉ）全てのホスト機の性能データ（実行時間等）およびハードウェア・リソース使用状況を監視して、これらのデータを性能データベースＰＦＭ_ＤＢから取得する。
ｉｉｉ）オプションとして、負荷テストから得た情報、すなわちワークフローをより多く使用した場合のリソース使用状況に関する測定値。
ｉｖ）利用可能なホスト機およびそれらのハードウェア特性（正規化されたＣＰＵ速度、例えば標準性能評価協会によるＳＰＥＣＩＮＴ２０００レートを用いたもの）に関するデータ。これは、全体的な処理能力（例えば基準ＣＰＵの１時間当たり秒数で測定）を監視する。
ｖ）全てのホスト機のハードウェア・リソース使用状況（性能データベースＰＦＭ_ＤＢから）。

再割り当てＲＡは好適には、評価モジュールおよび決定モジュールの２個のサブモジュールを含んでいて、本明細書の以下にその例証的な記述および機能を述べる。
評価モジュールは、
−最上位レベル（ＭＡ）ワークフロー実行要求、および
−全てのエージェント内のワークフロー実行要求待ち行列
に関するデータを受信すべく構成されている。

さらに、評価モジュールは、過去のワークフロー実行要求の履歴的傾向および要素および複雑度に関する管理された通信ネットワークの傾向を分析すべく構成されている。

決定モジュールは、過去情報に基づいて、プラットフォームが後述するいくつかの基準に従い全ての要求に対応可能か否かを決定すべく構成されている。

プラットフォームが全ての要求を管理することが不可能な場合、決定モジュールは、例えば警告メッセージを送信、どのアクションが状況を改善できるかを決定すべく構成されている。

特に、リソースは十分あるが、ＳＬＡが完全に満足されていない場合、決定モジュールは処理（すなわちワークフロー実行）をプラットフォーム全体にわたり再配分させるべく構成されている。好適には、これらのアクションは、ワークフローの異なるインスタンスに関連付けられた制約および優先順位を考慮している。

管理用コンソールＡＣは、例えば、少なくとも以下のうち一組を定義および監視することを意図している。
ｉ）プラットフォーム、すなわち分散エージェントによるプロセスの実行の処理能力を保持するホストＨのハードウェア構成。例えば、新規のホスト機が所定のホスト群に追加された際に、自動的にプラットフォーム全体に結合される。これは、例えば、ホストが自身の存在を通知するか、または、管理用コンソールが例えばＧＵＩを介してオペレータにより入力されたコマンドを受信することによりホストＨを認識するためである。
ｉｉ）ソフトウェア分散／割り当てを規定するためのＧＵＩ（すなわち目標および制約コンソールＧＣにおける制約に関するデータを受信するインタフェース）。
特に、これを用いて、ホスト機群を例えば以下に基づいて設定する。
−地理的制約（例えば、特定のワークフローは、ある領域にインストールされているが別の領域にはインストールされていないエージェントだけで実行することができ、あるいは、特定のホスト機だけで実行することができる）、
−階層的制約（例えば、特定のマシンでは第２レベルのワークフローのみ動作可能である）。
−業務制約（すなわち、特定の種類のプロセスに対する制約）。
ｉｉｉ）ワークフロー・スケジュール（例えば、サービスプロビジョニングワークフローは朝の時間帯にのみスケジュールされる）。

再割り当てコンソールＲＣは、リソース再割当てポリシ、すなわち、業務制約および監視されたデータに基づいて業務目標の満足度を最適化すべくリソースをいつ、どのように再割り当てするか、の命令を規定すべく構成されている。再割り当てコンソールでは、集中型および分散型制御の両方のポリシを入力することができる。特に、以下の定義が可能である。
ｉ）最高レベルのＳＬＡ満足度に達すべく、いつ、どのようにワークフロー優先順位に作用すべきかを規定する、集中制御用のルール。これらのルールは、管理されたプラットフォームを全体として見て（すなわち、マシンに対して直接的には作用しない）、リソース割り当てモジュールの全ての入力データおよび予測的データに基づいて作用する。
ｉｉ）ローカル・ソフトウェアおよびハードウェアのリソースの使用状況を最適化する目的で、関連ＣＡ（スレッド並列度およびロード・バランシング）を通じて単一エージェントに作用する、分散制御用のルール。
ｉｉｉ）ルールに関する複雑な式を計算する機能。

監視コンソールＭＣは、以下のような監視情報を閲覧すべく構成されている。
ｉ）定時（例：１日当たり）平均スループット、待ち行列（例：１日当たり）の要求数、平均実行時間（例：１日当たり）、目標が設定された全ての業務トランザクションの期限。
ｉｉ）合意されたＳＬＡ指標の測定値間の差違に関する、サンプリング期間にわたり計算されたＳＬＡの状況（違反したものは強調表示）、および関連コスト関数の評価。
ｉｉｉ）全てのワークフローにおけるハードウェア・リソースの使用状況、例えば秒単位でのＣＰＵ使用量および／または使用ＲＡＭ（単一レベルおよびそれを下回る全てのレベルについて）。これは、全てのホスト機が他とは計算能力が異なるため、ハードウェア・リソースの使用状況、例えばＣＰＵ使用量、は基準ＣＰＵに正規化される。
ｉｖ）アカウント情報。全てのワークフローにおいて使用されたリソース（合計に対するパーセンテージ、およびコストに関して）。

監視コンソールＭＣにより、階層的に、ワークフロー（特に、ワークフローの全てのブロック）の性能およびリソース使用状況を閲覧することが可能になる。全てのＳＬＡについて、リソースの使用が多いために、最適化する価値があるワークフローについてレポートを提出することが可能である。ワークフローの異なるレベルに他の測定点が設定された場合、それらはＭＣにも提示される。また、ＭＣは、ワークフローにより使用されたリソースに関して、支払い請求に関する情報を表示する。

サービス生成環境コンソールＳＣＣは、ＰＤＢにおけるプロセス、すなわち管理プラットフォームにおいて提供される全ての業務機能を定義、生成、および変更すべく構成されている。これは、本タスクの実施を容易にすべく、グラフィック・インタフェースに基づいている。本コンソールもまた、ワークフローに新規の監視点を挿入可能にしている。

さらなる実施形態において、ＭＭモジュールにより管理されるデータはまた、ＭＭモジュールに予測コンソールおよび容量計画モジュールを追加することにより、有用な容量計画を実現するために用いられる。

予測コンソールは、有用な容量計画活動を実現するための使用状況予測を設定すべく構成されている。本コンソールの入力は以下の通りである。
ｉ）期待スループット、および
ｉｉ）ネットワーク・ホストの期待個数および種類（この数値は、プロセス記述データベースにおけるデータの予測として計算することもできる）。

容量計画モジュールは、時間経過に伴ないハードウェア・リソースを保証すべく構成されている。これは、予測コンソールおよび他のコンソール（目標および制約コンソール、管理用コンソールおよび再割り当てコンソール））から入力を受信して、リソースの可用性を確認すべく構成されている。
リソースが十分でない場合、容量計画モジュールは、予想される増加傾向に対処するために必要なハードウェアの量について、コンソールのオペレータに警告すべく構成されている。本モジュールは、以下のうち少なくとも１個を含む一組のパラメータに基づいて分析を行う。
ｉ）期待スループット（履歴傾向に関して）、
ｉｉ）全てのワークフロー（特に第一レベルのワークフロー）のリソース使用状況の情報、
ｉｉｉ）地理的制約。

容量計画モジュールは不確実なデータ（特に長期データ）に基づいているため、主に通知目的で構成されている。将来のニーズを強調することができるが、好適には割り当てＲＡと対話することはない。

図３に、ホストの全体的な性能および当該ホストで動作する全てのエージェントの制御に責任を負うエージェント・モジュールＡおよび制御エージェントＣＡを含むホスト機の内部構造の例を示す。

各エージェントＡは、以下の構成要素のうち少なくとも一組を含んでいる。
−ワークフロー待ち行列または待ち行列ＷＦＱ。これは、各々の下位待ち行列が同一優先順位の要求を保持している多レベルの優先順位待ち行列である。エージェントへ送信された各々のワークフロー要求は、自身の優先順位に基づいて対応する下位待ち行列に挿入される。図３において、異なるワークフローをＷＦ１、．．．、ＷＦｎで示す。下位待ち行列内でワークフロー要求の欠乏を避けるため、待ち行列ＷＦＱは、例えばタイムアウト基準に基づいて、下位待ち行列内の要求について優先順位の更新を実施する。

待ち行列ＷＦＱ上の情報、特に以下のものが待ち行列ＷＦＱに関連付けられている。
各種のワークフローについて測定されたワークフローのＣＰＵ消費時間（これらのデータはＰＦＭ_ＤＢから取得された）を加算して計算された推定ＣＰＵ消費時間、
特定種類のワークフローが他のエージェントにより実行されることを要求される速度（例：ワークフロー／時間）（要求はエージェント内の待ち行列に入れられる）を統計的に推定する、要求入力速度、
−ワークフロー待ち行列ＷＦＱに関連付けられたワークフロー・スケジューラＷＦＳ。これは、待ち行列に含まれるワークフローＷＦｎをそれらの優先順位に基づいてスケジューリングすべく構成されている。エージェントの１個以上のプロセス・エンジンがワークフローを実行する準備ができる都度、スケジューラは、待機中のプロセス・エンジン・スレッドの１個へ待ち行列内でより高い優先順位のワークフローを送信する。
−ワークフロー・スケジューラＷＦＳにより制御される複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ。全てのエージェントは、設定可能な個数のワークフローを同時に実行することが可能である。これは、エージェント内で複数のプロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎ（独立エグゼキュータ）を設定することにより実現される。各プロセス・エンジン・スレッドＴＨ１、．．．、ＴＨｎは、同時に１個のワークフロー、例えばＪａｖａ言語で実装されたスレッド、を実行することが可能である。

制御エージェントＣＡは、好適にはソフトウェアで実装された以下の構成要素の少なくとも一組を含んでいる。
−リソース・モニタＲＭ：本構成要素は、自身の制御下にあるエージェントにおけるハードウェアおよびソフトウェアのリソース使用状況に関するデータを監視および収集すべく構成されている。
その役割は、ホスト上でのエージェント（エージェントホスト）を含む現在のリソース使用状況およびワークフローの実行によるＣＰＵとメモリ消費の両方を測定することである。測定された値は、マネージャ・モジュールＭＭおよびスレッド・コントローラＴＣへ送信される。
−スレッド・コントローラＴＣ。これは、リソース・モニタＲＭおよびワークフロー待ち行列ＷＦＱに結合されていて、局所性能を制御すべく構成されている。これは、能動的にエージェント・スレッドの並列性を管理すること意図している。これは、入力として、待ち行列内で実行待ちであるワークフローの個数、実行中のマシンのＰＥスレッドのＣＰＵ使用量およびＰＥの総数を受信すべく構成されている。上記の入力に基づいて、スレッド・コントローラＴＣは、最適なワークフロー実行並列性を実現すべくプロセス・エンジン・スレッド（ＰＥスレッド）の個数を増減させる。これは、例えば、実行待ちであるワークフローを待ち行列が含んでいる場合、ＰＥスレッドの総数が許容された最大個数を下回る場合、かつＣＰＵ使用量が指定された閾値を下回る場合に、新規のＰＥスレッドを生成する。しかし、エージェントが、外部リソース（装置、ネットワーク機器等）との直接対話を担当している場合、ＰＥスレッドの許容最大個数は外部リソースの許容可能な並列性により制限される。さらに、いくつかのＰＥスレッドが所定の期間使用されていないことがわかった場合、スレッド・コントローラはＰＥスレッドのガーベージ・コレクタを実行する。
−プロセス・エンジン・スレッドに結合されたディスパッチャＤ。本構成要素は、他のエージェントへワークフロー実行要求を送信すべく構成されている。各ＰＥスレッドはディスパッチャＤを用いてそのような要求を送信する。

ディスパッチャは、例えば、以下のようにロード・バランシング・アルゴリズムを用いて、他のエージェントへ要求を送信する。これは、要求を送信するための最適なエージェントを、２段階で選択する。

第一に、ＣＰＵおよびメモリの観点から負荷がより少ないホストを選択する。第二に、エージェント待ち行列の推定ＣＰＵ消費時間の最小量に基づいて選択されたホストの利用可能なエージェントを選択する。

制御エージェントＣＡは、好適には自身の側に、好適な実施形態による重要な特徴を有している。これらは、自身のプロセス・スレッドの並列性を能動的に管理する（局所最適化）ことが可能である。待ち行列の再順序付けおよび並列性管理の二つの能力が合わさって、本発明の一態様による適応型機構の基礎をなす。

図４に示す本発明の別の実施形態によれば、例えば、ホスト機Ｈ上に単一のエージェント・モジュールＡが存在するならば、リソース・モニタＲＭ、スレッド・コントローラＴＣ、および、ディスパッチャＤをエージェント・モジュールに付加することができる。

本発明のシステムの好適な実施形態は、移動特性を有するエージェントを実装するＪＡＤＥ（Ｊａｖａエージェント開発フレームワーク）、プロセス定義を行なうＸＰＤＬ（ＸＭＬプロセス定義言語）、およびＳｈａｒｋなどのＸＰＤＬワークフロー・エンジンを使用して実装される。

以下に、動作を示す図と共に、リソース割り当てモジュールについてより詳細に記述する。

再割り当てＲＡは、制約プロセス、データ操作、および設定変更の機能を有するエキスパート・ルールベース・システムとして実装することができる。管理されたネットワーク、外部システム、人間の知識、および内部分析から得られた全てのデータ、制約、およびルールがその知識ベースを構成しており、これを関連する知識データベースにより具体的に表現することができる。

再割り当てモジュールＲＡは、シナリオの状況に応じてケース毎に設定可能な所定の分析期間で評価および決定モジュールを実行する。

第一に、再割り当ては、後続する期間のために予測されたサービス／機能要求の個数を評価すべくバスＢを介してプロセス要求に関するデータを外部システムから取得し、この情報を関連する知識データベースに保存する。

次いで、決定モジュールは、所定の業務目標を最適な仕方で達成すべく実行されるアクションを見出すためにリソース再割当てルールを有効化する。

詳細には、各々の期間Ｔで、リソース割り当てモジュールは、履歴情報に基づいて、待ち行列に入れられた要求の個数および予測された要求の個数を考慮する。当該モジュールは、利用可能なハードウェア・リソース（主にＣＰＵとＲＡＭ）の量の第一の評価を実行する。これらのデータは、後述する「バックグラウンド・エラー訂正」を考慮しつつ、当該期間の終わりで実際に測定されたデータを使用して調整される。

以下のデータが統計方法で集められる。
−各々のワークフローについて各々のレベルにおけるＣＰＵニーズ、および
−下位ワークフロー要求の観点での最上位レベルのワークフローの合成（アーキテクチャの全てのレベルに関連付けられたＣＰＵニーズがあれば、この情報はまた、地理的制約があればこれを考慮しなければならない）。

収集された情報は、時刻ｔにおける待ち行列の長さと内容、および期間[ｔ，ｔ＋Ｔ]の間に（予想により）期待される要求の個数に相関付けられて、後続する期間の組または複数の期間の後に置かれた期間の組として意図される後続期間におけるＣＰＵ能力の合計必要量を計算する。

次いでＣＰＵの総量、すなわち新たな期間（レベルおよび地理的制約を考慮して）に対して要求される計算能力が、利用可能なＣＰＵ能力と比較される。これが十分でない場合、コンソールに警告（新規ハードウェアを要求する）が生成されて、ワークフローの優先順位により負荷をどのように扱うかが決定される。

利用可能なハードウェア・リソースに関するデータを調整するために「バックグラウンド・エラー訂正」が考慮される場合、各期間毎に全てのワークフローについて、かつ全てのホスト機について、先行期間で使用されたＣＰＵの量が、異なるワークフローにより使用されたＣＰＵの量と比較される。この値を用いて、後続期間でのＣＰＵの実際の利用可能性を「修正する」ために用いる。

本発明による方法およびシステムでは、優先順位に基づくポリシを使用することにより、異なるレベルの優先順位がある。各期間Ｔ毎に、決定モジュールは管理アルゴリズムに従い、業務目標を達成すべく優先順位付き待ち行列を操作することができる。欠乏を避けるために、ワークフロー要求が優先順位の低い待ち行列で過大な時間を消費した場合、その優先順位が自動的に更新されて、より高い優先順位付き待ち行列へ要求が移動されるようにする。

本発明の好適な実施形態によれば、管理アルゴリズムは、ステップ毎にリソース設定を改良して、漸進的な挙動により最適設定に到達しようとする適応型ソリューションに基づいている。現行アプローチの結果は、平均的なワークフロー実行時間の少なくとも２〜３倍（合理的な期間は、アプリケーションの状況に応じて５分〜１時間以上の範囲で変動し得る）である分析の期間を用いて保証される。

優先順位は、以下を考慮しつつ、ワークフローの全ての実行に関連付けられている。
−同意されたＳＬＡ（リスクの大きいワークフローほど、高い重みを維持する）の状況、
−ワークフローの目標コンソールにおいて規定された初期優先順位、並びに各ＳＬＡの優先順位および経済的意味、
−ワークフロー用の予め割当られた最小限のリソース量、
−割当て可能なリソース最大量（ＳＬＡの初期交渉の間に規定される）。

これは、優先順位が時間依存であることを意味する。ワークフロー性能のインスタンスがＳＬＡに近づいている（すなわち、性能が低下している）場合、その優先順位がより高く設定される。

プロセス・エンジンの代わりに、例えば統計技法によるＣＰＵ評価等、機能の実行を定義および測定する任意の手段を用いてもよい。

以下において、提唱されたアーキテクチャに基づく性能適合シナリオの例を示す。最適化すべきリソースはＣＰＵ負荷である。

現行シナリオによれば、最上位レベルのワークフローは、時間ｔ＞＞ΔＴ（ΔＴは観測期間）内に完了されるワークフローのパーセンテージで表現された優先順位特性により特徴付けられるＳＬＡが関連付けられた業務である。最後の仮定は、プラットフォームに対し期間ｔ内に再調整するのに十分な時間を与えるために必要である。

最上位レベルのワークフローは、多くの下位ワークフローから構成されている。全てのワークフローは、実行前の待ち行列内での待ち時間およびワークフローＣＰＵ時間スライスに影響を及ぼす優先順位特性を有している。

入力データは以下の通りである。
−各ワークフローおよび各ホスト機のＣＰＵ負荷[秒]、
−制約、すなわち同一ワークフローはホスト機郡の一部だけで実行可能である、
−下位ワークフローの観点からの第一レベルのワークフロー構成、
−過去のΔＴ期間におけるワークフロー到着数、
−過去のΔＴ期間におけるワークフロー実行回数。

目標は以下の通りである。
−次のΔＴ期間で全てのワークフローを実行するのに計算リソースが十分であるか否かを予測する、
−計算リソースがＳＬＡを遵守するのに十分であるか否かを予測する、
−ワークフローの実行優先順位がＳＬＡの遵守に到達するための適合。

性能適合プロセスは、全てのΔＴ期間で実行された監視に基づいており、最短プラットフォーム適合時間を表わす。

図５のフロー図を参照するに、全てのΔＴ期間で実行された監視の例をレポートしており、割り当てＲＡにより各ΔＴについて以下のステップが管理される。
１）各ホストでの各ワークフローのＣＰＵ負荷の評価（ステップ１００）。これは、ホスト・サンプル上でワークフローの負荷試験を実施して、ＣＰＵドキュメンテーションを用いることにより達成される（先験的予測）。得られた値は、ワークフロー実行に対する制約を考慮しつつ、先行ΔＴで実行された各ワークフローに関連付けられた実際のＣＰＵ時間を使用して微調整することができる、
２）未だ待ち行列で待機しているワークフローに加え次のΔＴ内に到着が予想されるワークフローを実行するために必要なＣＰＵ時間の予測（ステップ１２０）、
３）計算リソースの観点から必須であるホスト群を識別すべく、ステップ１２０で評価されたＣＰＵ時間を、利用可能なＣＰＵ時間と比較（ステップ１４０）して、影響を受けるＳＬＡに第一ワークフローを関連付ける。必要とされるＣＰＵリソースが利用可能なＣＰＵリソースより大きい場合、ＣＰＵリソース不足を通知する（ステップ１５０）、
４）各ＳＬＡについて、ＳＬＡ要求を満たす最小数のワークフローを実行するために必要なＣＰＵ時間を予想（ステップ１６０）し、次いでこれを利用可能なＣＰＵ時間と比較（ステップ１７０）して、ＳＬＡを遵守するために計算リソースが十分か否か判定する、
５）上のステップにおいて、ワークフローを実行する現行のプラットフォーム優先順位設定がＳＬＡ制約に対応できないとされた場合、（計算リソースの観点からワークフロー重みを考慮しつつ）ワークフロー優先順位のバランスを見直して、ワークフロー優先順位の適合手法（ステップ１８０）を通じて設定を調整しなければならない、
６）優先順位の適合が必要でない場合、または、優先順位適合が実施された場合、システムは性能適合プロセスを終了させ、次のΔＴ監視期間を待つ。

性能適合プロセスの予測手法の例を以下に詳述する。以下の定義を行なう。
− ΔＴ：監視期間および最短システム適合時間、
− Ｌ_Ｗｆ（ｎ）：ホストｎ上でのワークフローｗｆの実行に要するＣＰＵ負荷[秒]。これらの値は、先験的に（または、自動学習方式を用いて）推定し、次いでプラットフォーム動作の間に調整することができる。例えば、ある時間にわたる移動平均による。
− Ｖ_Ｗｆ（ｎ）：ホストｎ上のワークフローｗｆに対する制約であって、次式で与えられる。

次のΔＴ内に予見される全てのワークフローを実行するために必要な予想ＣＰＵ時間は次式で計算される。

ここで、
ｇは、集合ＷＦ（ｇ）内の全てのワークフローについて同等なホストのグループである。これは、集合ＷＦ（ｇ）に属する各ワークフローが、グループｇの中の１個のホストにより同じ確率で実行できることを意味している。
ｌ_ｗｆはグループｇのホスト上のワークフローｗｆを実行するために必要な予想ＣＰＵ時間であり、次式で与えられる。

ＮＥＰ_ｗｆはワークフローｗｆの予見される実行回数であり、次式で与えられる。
ＮＥＰ_ｗｆ（ｇ）＝ＮＱ_ｗｆ＋ＮＡＰ_ｗｆ（ｇ）
ここで、
ＮＱ_ｗｆは、次式により第一のレベル・ワークフロー呼び出しの観点で表わされた実行待ち行列のワークフローｗｆの総数である。

ＮＡＰ_ｗｆ（ｇ）は後続するΔＴ期間において予見されるワークフローｗｆの総予想数であり、次式で与えられる。

ここで、
Ｐ_ｉは先行するΔＴ_ｉに到着したワークフローの重みである。
ＮＡ_{ｗｆ（ｌ１），ｉ}（ｎ）は、期間ΔＴ_ｉにホストｎに到達した、第一のレベルのワークフローｗｆｌ１の下位ワークフローであるワークフローｗｆの数である。

上述の三種の目標を参照するに、予想および適合ステップは以下のように実行される。

利用可能なＣＰＵ時間が後続するΔＴで予見されるワークフローを実行するのに十分であるか否かを予想すべく、各々のグループｇについて、以下のようにＣＰＵ時間ＣｐｕＴｉｍｅＰ（ｇ）と、グループｇで利用可能なＣＰＵ時間との比較が実行される。

ならば、システムは全てのタスクを実行するための十分な計算リソースを有している。

ならば、システムはより多くのＣＰＵ時間を必要するため、
ａ）計算リソースの観点から必須であるホストのグループｇ
ｂ）このようなリソース不足でより重大な影響を受ける恐れのあるＳＬＡに関連付けられた第一レベルのワークフローを含むメッセージを送信する。

計算リソースがＳＬＡを遵守するのに十分であるか否かを予想すべく、第一レベルのワークフローｗｆ_ｌ１で規定された各ＳＬＡについて、ＳＬＡを遵守するために後続するΔＴで実行されるｗｆ_ｌ１の個数ＮＳＬＡ_ｗｆｌ１が計算される。

ＳＬＡが、時間ｔ（但しｔ＞＞ΔＴ）内に実行されるワークフローｗｆｌｌのパーセンテージｐ［％］として規定されている場合、ＮＳＬＡ_ｗｆｌｌは次式で与えられる。

ここで、
ＮＳＬＡＱ_ｗｆｌ１は、各ΔＴ_ｉについて、ΔＴｉ内に到着して未だ待ち行列内で待機しているワークフローｗｆｌ１の数と、ＳＬＡを遵守すべくこれらのワークフローを期限内に完了させるために依然として利用可能なΔＴｓの数ｎ＝（ｔ−ｋΔＴ）／ΔＴとの比の和により与えられる。ｋは、ワークフローが到着してから待ち行列内で待機している間のΔＴｓの数であり、
ＮＳＬＡＰ_ｗｆｌｌは、次のΔＴに到着するワークフローｗｆｌｌの予想数と、ＳＬＡを遵守すべくこれらのワークフローを完了するために依然として利用可能なΔＴｓの数との比（すなわちｔ／ΔＴ）である。

従って、ワークフローｗｆｌ１がＳＬＡを遵守すべく必要とされるＣＰＵ時間は、次式で与えられる。

ここで、

ここで

かつ

ここで、ＮＥ_{ｗｆ（ｗｆｌｌ）}（ｇ）は、ワークフローｗｆｌ１の各々の実行に対してホスト・グループｇで実行されるワークフローｗｆの予想数であり、次式で与えられる。

再び、

ならば、システムはワークフローｗｆｌ１がＳＬＡを遵守すべく十分な計算リソースを有している。

である場合、システムは、ワークフローｗｆｌ１がＳＬＡを遵守させることができず、従って、以下の節に述べるワークフロー優先順位適合手法が適用される。

ワークフロー優先順位適合手法は、ＳＬＡに関連付けられた少なくともタイプＡの第一レベル・ワークフローが存在する場合に適用され、このとき次式が成立する。

一方、他のタイプの第一レベル・ワークフローの場合、次式が成立する。

本手法は各種のアクションで構成され、以下にその少なくともいくつかの例を複雑度の順に記載する。
ａ）タイプＡワークフローの優先順位を上げる。
ｂ）タイプＢワークフローの優先順位を下げる
ｃ）各々の第一のレベル・ワークフローに重みを関連付けてアクションａ）またはｂ）を実行すべく最も関連のあるものを選択する
ｄ）違約条項が時間とともに増大しないＳＬＡについて、先行ΔＴにおいて既にＳＬＡの遵守に失敗したワークフローの優先順位を下げて、
ｅ）違約条項が時間とともに増大するＳＬＡについて、先行ΔＴにおいてＳＬＡの遵守に失敗したワークフローの優先順位を上げる。

アクションｄ）およびｅ）は、目標および制約コンソールＧＣで規定されたＳＬＡ違約のコスト影響を最小化しようと試みる機能に基づいている。

本手法は便利な点として、各々のワークフローに割当てられるＣＰＵ時間の最大量等、リソース使用に対する制約を考慮し続ける。これは、予約されたＣＰＵ時間の最大量を既に使用しているワークフローの優先順位をさらに上げることができないことを意味する。

各ワークフローの正確なコストの集計が重過ぎる場合、別の可能な方法として、実行された「構築ブロック」の数をエージェントが所定の間隔（例えば５分毎）で集計してシステムのリソース使用状況（例えばＣＰＵ使用）との相関を求めることができる。

負荷が過剰な状況下にあるコンピュータシステムの性能を推定するために多変量回帰技術がしばしば利用される。この選択は、容量を超えて実行された多くのインフィールドＯＳＳの回数の挙動の分析に基づいている。その結果、ＣＰＵ使用等、大多数のＯＳＳの共通の性能尺度を線形回帰によりモデル化できることがわかった。システム応答時間は、例えば、適度な指数法則に従い増大する。このように、システム性能予測の下限は、システム・リソースデータおよびワークフロー実行データに基づいて多変量線形回帰技術により得られる。

簡単な多項式モデルの例を次式に示す。
Ｕ_ｃｐｕ＝ａ_０＋ａ_１・Ｎ_Ａ＋ａ_２・Ｎ_Ｂ＋ａ_３・Ｎ_Ｃ
ここで、
Ｕ_ｃｐｕ ＝ エージェントのＣＰＵ使用
Ｎ_Ａ ＝ 構築ブロックＡの実行回数
Ｎ_Ｂ ＝ 構築ブロックＢの実行回数
Ｎ_Ｃ ＝ 構築ブロックＢの実行回数
である。

好適には、全ての尺度（特にＳＬＡ定義）は、一貫した方法で適合を最適化するための経済的数量で表現すべきである。

例えば図６に、本発明による柔軟性およびスケーラビリティに特徴を有する３層サービスプロビジョニングシナリオの設定を示す。

この例では、最下位層のエージェントは、ネットワーク要素との対話の責任を負っており、リソース・プロキシと呼ばれ、ＲＰｌ、ＲＰ２、ＲＰ３で示す。

「オファー１」と名付けられた広帯域サービスは、ＩＰ接続を得るすべく、アクセス装置（例：ＡＤＳＬ設備）を含む電気通信ネットワーク、ＡＴＭバックボーンおよびＢＡＳ（広帯域アクセス・サービス）を介して提供される。

ＲＰにより提供されるサービスの例として、ポートの設定、交差接続の生成、接続属性の変更がある。その各々は、設備へ／から、送信および／または受信される一連の基本命令を含んでいてよい。

ＡＡ１、ＡＡ２、ＡＡ３は各々、ＡＤＳＬ設備Ｅ（エンドツーエンド回路の端点Ａ）の画像を表わすリソース・プロキシＲＰ１、ＡＤＳＬ設備Ｅに接続しているＡＴＭスイッチＳＷの画像を表わすリソース・プロキシＲＰ２、およびＢＡＳ（エンドツーエンド回路の端点Ｚ）の画像を表わすリソース・プロキシＲＰ３を管理するエージェントである。

サービス「オファー１」の提供活動に関わる多レベル・ワークフローを図７に示す。

レベル１すなわち最上位レベルのワークフローは、２個のステップまたはタスクを含んでいて、マスター・エージェントＭＡにより実行される。第一のもの（ＡＤＳＬ接続性）は、エージェント・レベル（ＡＡ１、ＡＡ２、ＡＡ３）で実行されるレベル２のワークフローの実行を必要とする一方、第２のもの、すなわちメールボックス・タスク（本例では詳述しない）は外部プラットフォームにより実行可能である。

ＡＤＳＬ接続性タスクは従って、一連のレベル３ワークフローを含むレベル２ワークフローであり、リソース・プロキシレベル（ＲＰｌ、ＲＰ２、ＲＰ３）で実行されるベンダー依存の技術である。レベル３ワークフローは、リソース・プロキシにより通信ネットワーク設備側で実行する必要がある一連のコマンドを含んでいる。レベル２ワークフロー「ＡＤＳＬポート・ベンダーＡ生成」を拡張したことによるレベル３ワークフローの例を図７に示す。

監視コンソールＭＣは、各ワークフローのリソース使用状況（ＣＰＵ、ＲＡＭ）および経過時間を測定して、特定のベンダーまたは特定のワークフローに問題があれば強調表示する。

メールボックスが無い点以外はサービス「オファー１」と同様の別サービス「オファー２」が存在すると仮定すれば、目標コンソールは、ＳＬＡ制御ルールおよび関連コスト関数を用いてオファー１およびオファー２に対してＳＬＡを規定することができる。サービス「オファー２」に対するＳＬＡがより重要（例えば、「オファー２」に関連付けられたコスト関数は平均実行時間である１秒を超えた秒数に等しく、「オファー１」に関連付けられたコスト関数は平均実行時間である４秒を超えた秒数に等しい）場合、「オファー２」に対する優先順位は「オファー１」の優先順位より早く増大する。これは、同数の要求に対してハードウェア・リソース（例：ＣＰＵ）が不足している場合、「オファー２」のスループットが「オファー１」のスループットより高いことを意味する。

従って、プラットフォームは、外部オペレータにより設定されたにせよ、またはエージェント飽和によるものにせよ、自身の目標に達するようリソース使用を調整する。

当然ながら、本発明の原理は変わらず、実施形態の形式は単に非限定的な例として記述・図解されたものに関して各種の変更が可能であるが、これらは添付の特許請求の範囲により規定される本発明の保護範囲から逸脱するものではない。

本発明による電気通信ネットワークおよびサービスの管理システムまたはプラットフォームのアーキテクチャを示すブロック図である。 図１のマネージャ・モジュールの内部アーキテクチャを示すブロック図である。 エージェント・モジュールおよび制御エージェントと共に、図１のホスト機の内部アーキテクチャを示すブロック図である。 別の実施形態によるエージェント・モジュールの内部アーキテクチャを示すブロック図である。 本発明によるリソース管理方法のフロー図である。 本発明によるシステムを含む３層サービスプロビジョニングシナリオの模式図である。 図６のサービスプロビジョニングシナリオにおける多レベル・ワークフローを示す図である。

Claims (30)

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. 少なくとも１個のコンピュータのメモリにロード可能であって、請求項１〜１４のいずれか一項に記載のステップを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物のコンピュータ・プログラムの組。