(57)【特許請求の範囲】
【請求項１】
複数のコンピューティング・ノード間でパフォーマンス情報を動的に共有する方法であって、
各コンピューティング・ノードそれぞれが、当該コンピューティング・ノードにインストールされたソフトウェアから前記パフォーマンス情報を動的に取得するステップであって、前記パフォーマンス情報は、前記コンピューティング・ノードのハードウェア及び前記ソフトウェアの現在の構成パラメータを含む、前記取得するステップと、
前記各コンピューティング・ノードそれぞれが、前記現在の構成パラメータの１つ以上の値が特定の閾値より上又は下に変化することに応じて、前記取得したパフォーマンス情報を、通信ネットワークを介してサーバへ送信するステップと、
前記サーバが、前記各コンピューティング・ノードそれぞれから送信された前記パフォーマンス情報それぞれを知識データベース内に記憶し、前記知識データベース内に記憶された前記パフォーマンス情報に基づき、前記コンピューティング・ノードのハードウェア及びソフトウェアの新たな構成パラメータを動的に判断し、前記新たな構成パラメータを前記知識データベース内に記憶し、前記新たな構成パラメータを、前記ネットワークを介して前記コンピューティング・ノードに送信するステップであって、前記送信によって、前記コンピューティング・ノードに前記新たな構成パラメータが動的に提供される、前記送信するステップと
を含み、
前記新たな構成パラメータを判断することは、前記知識データベース内の前記パフォーマンス情報に基づいて、前記コンピューティング・ノードのハードウェア及びソフトウェアの最適構成パラメータを判断することを含み、
前記最適構成パラメータを判断することは、前記コンピューティング・ノードの環境特徴に応じたタイプが同じであるコンピューティング・ノードのパフォーマンス情報に基づいて行われることを含み、
前記最適構成パラメータを判断することは、前記タイプについての最適構成パラメータが前記知識データベース内に存在することに応じて、当該存在する最適構成パラメータを提供することを含む、
前記方法。
【請求項２】
前記最適構成パラメータを判断することは、前記タイプについての最適構成パラメータが前記知識データベース内に存在しないことに応じて、前記タイプに関して前記知識データベース内にある前記構成パラメータに基づき最適構成情報を判断し、当該判断された最適構成情報を提供することを含む、請求項１に記載の方法。
【請求項３】
前記サーバが、前記判断された最適構成情報を前記知識データベース内に格納するステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記タイプが、ＳＭＢ又はエンタープライズである、請求項１に記載の方法。
【請求項５】
前記新たな構成情報を動的に判断することが、第１のコンピューティング・ノードのパフォーマンス目標を、第２のコンピューティング・ノードが達成できるように、前記第１のコンピューティング・ノードの構成情報を前記第２のコンピューティング・ノードに提案することを含む、請求項１に記載の方法。
【請求項６】
前記新たな構成情報を受信したコンピューティング・ノードが、前記新たな構成情報を適用するステップ
をさらに含む、請求項１に記載の方法。
【請求項７】
複数のコンピューティング・ノード間でパフォーマンス情報を動的に共有するシステムであって、
１つ以上のコンピューティング・ノードと、
サーバと
を含み、
各コンピューティング・ノードそれぞれが、当該コンピューティング・ノードにインストールされたソフトウェアから前記パフォーマンス情報を動的に取得し、ここで、前記パフォーマンス情報は、前記コンピューティング・ノードのハードウェア及び前記ソフトウェアの現在の構成パラメータを含み、
前記各コンピューティング・ノードそれぞれが、前記構成パラメータの１つ以上の値が特定の閾値より上又は下に変化することに応じて、前記取得したパフォーマンス情報を、通信ネットワークを介してサーバへ送信し、
前記サーバが、前記各コンピューティング・ノードそれぞれから送信された前記パフォーマンス情報それぞれを知識データベース内に記憶し、前記知識データベース内に記憶された前記パフォーマンス情報に基づき、前記コンピューティング・ノードのハードウェア及びソフトウェアの新たな構成パラメータを動的に判断し、前記新たな構成パラメータを前記知識データベース内に記憶し、前記新たな構成パラメータを、前記ネットワークを介して前記コンピューティング・ノードに送信し、
前記送信によって、前記コンピューティング・ノードに前記新たな構成パラメータが動的に提供され、
前記新たな構成パラメータを判断することは、前記知識データベース内の前記パフォーマンス情報に基づいて、前記コンピューティング・ノードのハードウェア及びソフトウェアの最適構成パラメータを判断することを含み、
前記最適構成パラメータを判断することは、前記コンピューティング・ノードの環境特徴に応じたタイプが同じであるコンピューティング・ノードのパフォーマンス情報に基づいて行われることを含み、
前記最適構成パラメータを判断することは、前記タイプについての最適構成パラメータが前記知識データベース内に存在することに応じて、当該存在する最適構成パラメータを提供することを含む、
前記システム。
【請求項８】
前記最適構成パラメータを判断することは、前記タイプについての最適構成パラメータが前記知識データベース内に存在しないことに応じて、前記タイプに関して前記知識データベース内にある前記構成パラメータに基づき最適構成情報を判断し、当該判断された最適構成情報を提供することを含む、請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的に、情報技術（ＩＴ：ｉｎｆｏｒｍａｔｉｏｎ  ｔｅｃｈｎｏｌｏｇｙ）製品／ソリューションを構成することに関し、特に、ＩＴ製品／ソリューション展開間で構成情報を共有することに関する。
【背景技術】
【０００２】
情報技術（ＩＴ）製品／ソリューションをプロダクション環境に展開するときに頻繁に起こる解決が難しい課題は、特定のサービス・レベルまたはパフォーマンス目標を達成する構成の最適集合を発見することである。今日、エンタープライズ・アプリケーションを展開し、最適パフォーマンスを実現する構成を判断することにおける問題は、アプリケーションが、そのアプリケーション（ミドルウェア）のランタイム・プラットフォームを提供する他のソフトウェア製品のセットに基づくようになってきているということである。別の問題は、アプリケーションが、多数のプラットフォーム（オペレーティング・システム）上で実行されるよう開発されているということである。さらに別の問題は、最適パフォーマンスの展開および提供に関するベスト・プラクティスが必ずしも従われるとは限らないことから、各アプリケーションが明確に調整されなければならないということである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
現在、同じＩＴ製品／ソリューションが別々の顧客環境で展開されると、各顧客が時間を費やして最適構成を発見しなければならない。２つの顧客が類似したコンピューティング環境を有し、それが結果として同じ最適構成につながる場合でも、この顧客が最適構成についての情報を共有する動的メカニズムがないことから、各顧客が時間を費やして最適構成を発見しなければならない。ＩＴサービス・プロバイダが製品／ソリューションを複数回構成しなければならない場合にも、同様の問題が生じる。
【課題を解決するための手段】
【０００４】
本発明の実施形態によれば、本発明は、別々の情報技術製品／ソリューション展開間でパフォーマンス・データを共有する方法およびシステムを提供する。一実装は、複数のコンピューティング・ノード間でパフォーマンス情報を動的に共有する方法およびシステムを含み、前記コンピューティング・ノードにおける情報技術（ＩＴ）製品／ソリューションの展開からパフォーマンス情報を動的に取得することと、取得されたパフォーマンス情報を知識データベース内に記憶するために、取得されたパフォーマンス情報を通信ネットワーク上でサーバに送信することとを含む。サーバは、データベース内の情報に基づき、新たな構成情報を動的に判断し、新たな構成をデータベース内に記憶し、新たな構成情報をネットワーク上で送信することによって前記展開に新たな構成情報を提供するよう動作する。
【０００５】
各展開におけるパフォーマンス情報は、その展開における現在の構成情報を含むとよく、新たな構成情報を判断することは、データベース内の構成情報に基づいて新たな構成情報を判断することをさらに含むとよい。
【０００６】
パフォーマンス情報は、展開の構成ポリシーに基づく展開それぞれにおけるハードウェアおよびソフトウェア構成に関する現在の構成パラメータ情報を含むとよく、新たな構成情報を判断することは、データベース内の情報に基づいて最適構成を判断することをさらに含むとよい。
【０００７】
展開の最適構成情報を判断することは、その展開から取得された情報に基づき、展開から取得されたパラメータ情報に基づいて展開タイプを展開に割り当てることであって、展開タイプは、展開のコンピューティング環境の特徴に応じたものである、該割り当てることと、その展開タイプに関してデータベース内に最適構成が存在すれば、その結果、その展開タイプに関して存在する最適構成を提供することとをさらに含むとよい。その展開タイプに関してデータベース内に最適構成が存在しなければ、その結果、その展開タイプに関してデータベース内にある構成情報に基づき展開の最適構成を判断し、展開の最適構成をデータベース内に格納し、展開の最適構成を提供する。
【０００８】
新たな構成情報は、展開における構成ポリシーに基づき展開において適用されるとよい。展開は、新たな構成情報をリクエストしてもよく、その結果、新たな構成情報を提供することは、リクエストしている展開に新たな構成情報を提供することを含むとよい。
【０００９】
本発明の他の側面および利点が、以下の詳細な説明から明らかになる。詳細な説明は、図面と併せて理解されると、本発明の原理の例示となる。
【００１０】
本発明の本質および利点、ならびに好適な使用形態をよりよく理解するためには、添付の図面と併せて読まれる、以下の詳細な説明を参照すべきである。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態による、別々の情報技術製品／ソリューション展開間でパフォーマンス・データを共有する知識共有システムの機能ブロック図を示す。
【図２】本発明の実施形態による、知識共有システム内のクライアント・モジュールの機能ブロック図を示す。
【図３】本発明の実施形態による、知識共有システム内のサーバ・モジュールの機能ブロック図を示す。
【図４】本発明の実施形態による、別々の情報技術製品／ソリューション展開間でパフォーマンス・データを共有するアーキテクチャの機能ブロック図を示す。
【図５】本発明の実施形態による、別々の情報技術製品／ソリューション展開間でパフォーマンス・データを共有するプロセスのフローチャートを示す。
【図６】本発明の実施形態による、別々の情報技術製品／ソリューション展開間で最適構成情報を判断および共有するプロセスのフローチャートを示す。
【図７】本発明の実施形態による、別々の情報技術製品／ソリューション展開間での最適構成情報の共有および適用の図形による例を示す。
【発明を実施するための形態】
【００１２】
以下の説明は、本発明の全般的な原理を示すためのものであり、本願明細書において請求される発明概念を限定することは意図されていない。さらに、本願明細書に記載される特定の特徴は、様々な可能な組み合わせおよび置換のそれぞれにおいて、記載されている他の特徴と組み合わせて使用可能である。本願明細書で明確に他の記載がない限り、すべての表現には、明細書が暗示する意味、ならびに当業者により理解される意味または辞書、論文などで定義されている意味あるいはその両方を含め、その最大限広範な解釈が与えられるものとする。
【００１３】
本発明は、構成情報などのパフォーマンス・データを、別々の情報技術（ＩＴ）製品／ソリューション展開間で動的に共有する方法およびシステムを提供する。一実施形態は、様々なコンピューティング環境における（ＩＴ）製品／ソリューション（例えばソフトウェア製品）の展開に関する新たな構成についての情報を含む情報を動的に取得してデータベース内に記憶し、そのような、或る環境向けの新たな構成情報を、データベースからその環境のクライアントに提供することによって構成情報を共有することを可能にする知識共有メカニズムを含む。
【００１４】
一実施形態では、新たな構成情報は、実質的に最適な構成情報を含む。知識共有メカニズムは、ＩＴ製品／ソリューションの複数の展開に適用され、そのような複数の展開における最適構成を発見する期間を短縮し、その結果、複数の展開で同じタスクへの取り組みが重複することを避ける。本発明はさらに、ＩＴ製品／ソリューションのパフォーマンス・モデルの動的な改善を提供し、その結果、静的なローカルの構成アドバイザを使用することの制限を克服する。
【００１５】
一実装は、エンタープライズ・レベルおよびエンタープライズ間で価値を提供する、Ｗｅｂ２．０のようなシステム（Ｅｎｔｅｒｐｒｉｓｅ２．０）を可能にする知識共有メカニズムを含む。これは、所定のＩＴ製品／ソリューションの複数展開間の知識共有システムを提供し、そのＩＴ製品／ソリューションの最適パフォーマンス構成を発見する。当該のシステムは、概して、各ＩＴ製品／ソリューション展開のクライアントと、サーバとを含む。クライアントは、対応するＩＴ製品／ソリューション展開を、その展開から必要なハードウェアおよびソフトウェア・データを収集し、そのデータをサーバへ送り、その展開に最適な構成を受信することにより最適化するよう構成されている。サーバは、ＩＴ製品／ソリューションのすべての展開からデータを収集し、各展開の最良（最適）構成を発見し、最適構成情報を各展開へ返送するよう構成されている。
【００１６】
１つの運用シナリオでは、クライアントは、特定のＩＴ製品／ソリューションに組み込まれたソフトウェア・モジュールを含み、コンピューティング環境におけるそのＩＴ製品／ソリューション展開の構成状況を、その展開に適用される最適化ポリシーとともに定期的にサーバへ送る。サーバは、当該情報を分析して、所望の顧客最適化ポリシーに従い、その環境にその構成が最適であるかどうかを判断する。サーバは、他の展開（顧客）からの、類似したコンピューティング環境（単数または複数）および類似した最適化ポリシーに関して既に公知である構成、または分析的構成最適化技術（ａｎａｌｙｔｉｃａｌ  ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｏｐｔｉｍｉｚａｔｉｏｎ  ｔｅｃｈｎｉｑｕｅｓ）、あるいはその両方を活用することで、構成が最適であるかどうかを判断する。
【００１７】
サーバが、コンピューティング環境におけるＩＴ製品／ソリューション展開の最適構成を判断すると、サーバは、その展開のクライアントへ最適構成情報を送る。次に、その展開の顧客は、最適構成状態に移行するよう構成変更を現在の構成に対し自動的にシステムに実装させること、または変更を処理する前に変更を検証するよう手動確認を要求することを決定することができる。
【００１８】
ＩＴ製品／ソリューションの展開の数が増えるにつれて、類似したコンピューティング環境の構成の最適性も増す。これはさらに、ＩＴ製品／ソリューションのパフォーマンス・モデルの動的強化を可能にする。別々の時間に別々の構成が必要な場合（例えば、コンピューティング負荷の季節ごとの変化）、このシステムは、サーバから各展開へのダウンロードを迅速にリクエストできる種々の構成を提供する。このシステムは、様々な構成についての情報（肯定的および否定的）収集に基づき各展開の最適構成を作り出すことによる、知識生成メカニズムを提供する。したがって、「否定的」知識（すなわち、ＩＴ製品／ソリューションに何か不具合が生じたときに作り出される知識）のみでなく、「肯定的」知識（すなわち、ＩＴ製品／ソリューションの優れた動作の知識）も活用される。
【００１９】
図１は、本発明の実施形態による、別々のＩＴ製品／ソリューション（例えば、顧客Ａおよび顧客Ｂコンピューティング環境での展開）間でパフォーマンス・データを共有するシステム１０の機能ブロック図を示す。クライアント・モジュール１１が、最適化されるコンピューティング環境にある各ＩＴ製品／ソリューション展開に提供され、サーバ１２は、最適構成を作り出すために、種々の展開の知識共有を活用する。クライアント・モジュール１１およびサーバ１２は、インターネットなどの通信ネットワークを介して接続されている（他の通信ネットワークが利用されてもよい）。各コンピューティング環境は、１つ以上のコンピューティング・ノードを含むとよく、各コンピューティング・ノードは、１つ以上のプロセッサ、ストレージ・デバイス、データベース・モジュール、通信モジュール、ネットワークなどを含むとよい。
【００２０】
図２は、データ・コレクタ１５、データ送信機１６、ソリューション受信機１７、構成アクチュエータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ａｃｔｕａｔｏｒ）１８、定期チェッカ（ｐｅｒｉｏｄｉｃａｌ  ｃｈｅｃｋｅｒ）１９、および最適化ポリシー・コンフィギュレータ（ｏｐｔｉｍｉｚａｔｉｏｎ  ｐｏｌｉｃｙ  ｃｏｎｆｉｇｕｒａｔｏｒ）２０を含むクライアント・モジュール１１の実施形態の機能ブロック図を示す。データ・コレクタ１５は、プローブ（ｐｒｏｂｅ）２１を使用してパフォーマンス・モデルに必要なデータを集める。一例では、プローブ２１は、ＯＳプローブ、ＨＷプローブ、およびＳＷプローブを含み、それぞれ展開コンピューティング環境のＯＳ、ハードウェア、ミドルウェアとインターフェースで接続するソフトウェア・モジュールを含み、最適構成およびパフォーマンス・モデルに必要なデータを抽出する。
【００２１】
データ送信機１６は、パフォーマンス・モデル・データをサーバ１２（図１）へ送る。ソリューション受信機１７は、サーバから構成の最適セット（すなわち「ソリューション」）を受信し、それをストレージ２２に記憶する。構成アクチュエータ１８は、ＩＴ製品／ソリューション展開にて必要な構成変更を実行する。定期チェッカ１９は、パフォーマンス・モデルに関して展開においてパラメータのセットを監視し、前記パラメータの１つ以上の値が特定の閾値より上／下に変化すると、データ・フローを開始する（すなわち、パフォーマンス・モデル・データをサーバへ送り構成の最適セットを受信する）。最適化ポリシー・コンフィギュレータ２０は、適用される最適化ポリシーを顧客が指定できるようにする。
【００２２】
図３は、サーバ１２の実施形態の機能ブロック図を示す。サーバ１２は、各ＩＴ製品／ソリューションのプラグイン２５を提供する製品独立インフラストラクチャを利用する。プラグイン２５は、ＩＴ製品／ソリューションの構成を記述するのに必要なパフォーマンス・データのセットを含むパフォーマンス・モデル・データを、ＩＴ製品／ソリューション展開の各クライアント１１から受信すること、および対応する展開を最適化するために必要なデータのセットを各クライアントへ送ることを可能にする。サーバ１２は、知識データベース１４に存在するデータに基づき各ＩＴ製品／ソリューション展開に関して実質的に最良の構成を提供するパフォーマンス・モデルを操作するよう構成された最適化エンジン（ソリューション・ファインダ（ｓｏｌｕｔｉｏｎ  ｆｉｎｄｅｒ））１３を含む。最適化エンジン１３は、線形補間アルゴリズムまたは遺伝的アルゴリズム（またはその他任意の最適化手法）を利用して、各展開の最適構成を提供するとよい。
【００２３】
ＩＴ製品／ソリューション（例えばソフトウェア製品Ｘ、ソフトウェア製品Ｙ）のプラグイン２５は、そのＩＴ製品／ソリューションの展開にあるクライアント１１と通信するとよい。一実施形態では、ＩＴ製品／ソリューションのプラグイン２５は、データ受信機２６、製品パフォーマンス・モデル２７、およびソリューション送信機２８を含むソフトウェア・モジュールを含む。データ受信機２６は、対応するＩＴ製品／ソリューションの展開に関してクライアント１１により送られたデータを受信する。製品パフォーマンス・モデル２７は、ＩＴ製品／ソリューションのパフォーマンス・モデルを表す。一例では、分析されるパフォーマンス・パラメータのセットは、ベクトルＡ＝｛ＨＷデータ，ＳＷデータ，展開ディメンション｝であり、最適化されるパラメータのセットはベクトルＰであり、ベクトルＰの各要素Ｐｉに適用される最適化ポリシーのセットは要素Ｐｉの現在の値の所望の変化として顧客により指定されることができ、状態ｉでの構成はｄｉ＝Ａ∪Ｐとしての和集合であり、パフォーマンス・モデルは、φ（ｄｉ）により構成状態の関数として表される。
【００２４】
最適化エンジン１３は、ＩＴ製品／ソリューションの所定のパフォーマンス・モデルの最適構成を、ＩＴ製品／ソリューションの別々の展開（別々の顧客）間で共有されるデータにアクセスすることによって判断する。最適化エンジン１３は、各ＩＴ製品／ソリューション（ソフトウェア製品Ｘ、ソリューション製品Ｙ）のクライアント１１に、対応する最適構成を提供する。したがって、図４において例示アーキテクチャ３０により示されているように、サーバ１２は、各ＩＴ製品／ソリューションの複数展開にある関連クライアント１１の、対応するプラグイン２５を介して、複数ＩＴ製品／ソリューションの最適構成分析を実行するとよい。
【００２５】
図５は、本発明の実施形態による、異なるＩＴ製品／ソリューション展開間でパフォーマンス・データを共有するクライアント・プロセス４０のフローチャートを示す。プロセス・ブロック４１は、ハードウェア・データ、ソフトウェア・データ（例えばＯＳ、ミドルウェア、製品特有）、展開ディメンション（例えばこの展開によりサポートされるクライアントの数）などの分析されるパラメータのセット、最適化されるパラメータのセット（例えば、以前のデータ・グループのサブセット）を、各パラメータに関する所望の最適化ポリシーとともに含む、ＩＴ製品／ソリューション展開に関するクライアント側の現在の構成データをスキャンする。プロセス・ブロック４２は、そのようなデータがサーバにアップロードされているかどうかを判断する。されていれば、プロセスは、ブロック４１へと戻り、そうでなければブロック４３へ進む。
【００２６】
プロセス・ブロック４３において、クライアントは、スキャンされたデータをサーバへ送る。例えば、スキャンされたデータは、定期的に、またはパラメータ値の一部が所定の閾値より上／下に変化したときに、サーバにアップロードされることが可能である。図６に関係して以下にさらに記載するように、サーバ側でのプロセス・ブロック４４において、ＩＴ製品／ソリューションの別々のクライアントすべてからデータが収集され、各展開の最適構成が判断される。プロセス・ブロック４５において、最適構成情報が、リクエストしているクライアントそれぞれにダウンロードされる。クライアント側でのプロセス・ブロック４６において、新たに受信された構成情報が、ＩＴ製品／ソリューション展開に自動／手動で適用される。具体的には、クライアントが、自動（すなわち、サーバからプッシュされる構成変更を常に適用）、閾値未満／超のとき（すなわち、所定の閾値未満／超の構成パラメータに構成変更を適用）、手動介入が必要（すなわち、オペレータが変更の承認またはその逆を行わなければならない）などのポリシー設定に基づき、最適構成を適用するとよい。
【００２７】
図６は、本発明の実施形態による、ＩＴ製品／ソリューションの各展開の最適構成を判断するサーバ・プロセス５０のフローチャートを示す。処理ブロックについて以下に記載する。
【００２８】
ブロック５１：展開カテゴリを定義。このプロセスは、展開タイプに従って、クライアントから受信されたパフォーマンス・モデル・パラメータ・データをフィルタリングすることを含む。各製品パフォーマンス・モデルは、各展開のカテゴリを定義するよう、分析されるパラメータのサブセットの範囲を定義する。
【００２９】
ブロック５２：最適化ポリシー・カテゴリを定義。展開は、カテゴリ（例えばＳＭＢ展開、エンタープライズ展開など）に割り当てられると、展開の顧客により指定された最適化ポリシーに従いさらにフィルタリングされる（例えば、ウェブ・アプリケーションの２つの異なるポリシーは、「スループットを最大化」または「応答時間を最小化」であることもある）。
【００３０】
ブロック５３：展開が既知の展開タイプ（Ａ）であるかどうかを判断。そうであれば、ブロック５４ａへ進み、そうでなければブロック５４ｂへ進む。
【００３１】
ブロック５４ａ：展開の未知の構成（ｄｉ）が既に最適であるかどうかを判断。最適でなければ、ブロック５５へ進み、他の場合は停止する。
【００３２】
ブロック５４ｂ：展開の構成（ｄｉ）が既に最適であるかどうかを判断。最適でなければ、ブロック５５へ進み、他の場合は停止する。
【００３３】
ブロック５５：展開の新たなよりよい／最適な構成を発見。
【００３４】
ブロック５６：新たな構成をその展開のクライアントへ送る。
【００３５】
よって、ブロック５４ａおよび５４ｂにおいて、その展開環境の最適構成が既に存在すれば（例えば、同じ顧客または他の顧客に関して以前に特定されているため）、さらなる処理は生じない。ブロック５５では、その環境の最適ソリューションが存在しないため、ソリューション・エンジン１３（図３）が、別々の展開からのデータを活用することで最適構成を判断する。
【００３６】
図７の例示プロセス６０を参照する。分析されるパフォーマンス・モデル・パラメータのセット（Ｐｉ，ｉ＝１，．．．，８）により表されるＩＴ製品／ソリューションの展開（顧客Ａ）であって、その最適化ポリシーを、パラメータＰ２の値の所望の増分として表すことができる展開について考える。展開タイプおよび最適化ポリシーが顧客Ａと同じである別の顧客（顧客Ｂ）が、その展開の最適構成に既に達していると仮定すると、ソリューション・エンジン１３は、パフォーマンス・モデル・パラメータの２つのセット（すなわち顧客Ａおよび顧客Ｂのパフォーマンス・モデル・パラメータ）を比較して、そのうち２つ（例えばＰ５およびＰ７）を変えると、顧客Ａは、顧客Ｂでの展開に類似した、その展開の所望の最適構成に達することができると発見できる。
【００３７】
以下の例は、新たな次善ＩＴ製品／ソリューション構成（ＩＴ製品／ソリューションの新たなインストールに相当）を処理するための知識共有のプロセスを説明するシナリオを提供し、その展開の既知の「優れた」構成を提案する。知識共有システムは、ＸＭＬファイルを使用して製品／ソリューションに関係するすべての構成情報を管理すると仮定する。このシナリオを示すために考案されたサンプル製品は、次のＸＭＬスキーマにより定義されたパフォーマンス・モデルを有する：
【００３８】
【表１】
0005629261.tif 000002
【００３９】
【表２】
0005629261.tif 000003
【００４０】
【表３】
0005629261.tif 000004
【００４１】
【表４】
0005629261.tif 000005
【００４２】
製品開発およびテスト段階の間に定義される製品パフォーマンス・モデルは、そのパフォーマンスに影響し得るすべてのパラメータ（例えばハードウェア、オペレーティング・システム、および製品構成のパラメータ）を、主要／重要メトリクスの現在の値（当該システム上で製品が現在どのように機能しているかを表す）、およびそうした値の顧客により指定された所望の変化（そのパフォーマンス目標または最適化ポリシー）と共に含む。説明を簡潔にするために、パラメータおよびメトリクスの数およびタイプは、少数にとどめた。例えば、サンプル製品は、単一サーバ・トポロジを有し、サーバ・モジュールが、その構成が製品全体のパフォーマンスに影響を及ぼす唯一のモジュールである。他の製品およびパフォーマンス・モデルは、さらなる情報を含み得る。サンプル製品の各インストール／展開は、そのＸＭＬスキーマのインスタンス（ＸＭＬファイル）により表現される。
【００４３】
サンプル製品は、４つの異なる顧客サイト（顧客Ａ、Ｂ、Ｃ、Ｄ）にて展開され、顧客のうち３つ（顧客Ａ、ＣおよびＤ）は、しばらくの間製品を実行しており、その構成は既に知識共有システム１０のサーバ１２上のデータベース内に記憶されている（例えば、図６のプロセス５０により）。製品の前記３つの顧客展開の構成は、以下のＸＭＬコードにより表される。
【００４４】
顧客Ａは、知識共有システム１０が「大型」と分類した（ＸＭＬファイルでは「Ｅｎｔｅｒｐｒｉｓｅ」）環境でサンプル製品を展開したクライアント１１を表す。その構成は、顧客がまだパフォーマンス・メトリクスの一部の「ｕｐ」または「ｄｏｗｎ」の変更を行うことをリクエストしているため、まだ「最適」ではない。顧客Ａの構成：
【００４５】
【表５】
0005629261.tif 000006
【００４６】
【表６】
0005629261.tif 000007
【００４７】
顧客Ｃは、知識共有システム１０が「小規模」と分類した（ＸＭＬファイルでは「ＳＭＢ」）環境でサンプル製品を展開したクライアントを表す。顧客Ａのように、そのパフォーマンス目標はまだ達成されていない。顧客Ｃの構成：
【００４８】
【表７】
0005629261.tif 000008
【００４９】
【表８】
0005629261.tif 000009
【００５０】
顧客Ｄは、知識共有システム１０が、顧客Ｃのものなど、「ＳＭＢ」として分類した環境にサンプル製品を展開したクライアントを表す。顧客Ｄは、製品パフォーマンス主要メトリクスのいかなる変化も指定していないため、その構成は「最適」と見なされる。顧客Ｄの構成：
【００５１】
【表９】
0005629261.tif 000010
【００５２】
【表１０】
0005629261.tif 000011
【００５３】
４番目の顧客（顧客Ｂ）は、サンプル製品のそのインスタンスを展開したばかりであり、その構成が初めて知識共有システム１０に送られる。顧客Ｂの構成：
【００５４】
【表１１】
0005629261.tif 000012
【００５５】
【表１２】
0005629261.tif 000013
【００５６】
顧客Ｂの展開タイプは、システム１０によって「ＳＭＢ」として分類されている。したがって、サーバ１２が他の顧客の構成を照合すると、顧客Ｃおよび顧客Ｄのみがさらなる比較対象として考慮され、その一方で、展開が「Ｅｎｔｅｒｐｒｉｓｅ」として分類された顧客Ａは、この最適化分析から除外される。
【００５７】
知識共有システム１０が、次の分類ステップ（すなわち、顧客最適化ポリシーの比較を含む）へ進むと、その結果、顧客Ｃが、顧客Ｂに対し異なる最適化ポリシーを有することが発見される。したがって、顧客Ｂのデータは、この場合最適化に使用されない。
【００５８】
代わりに、顧客Ｄは、その最適化ポリシーを達成しており、顧客Ｂにより指定されたパフォーマンス目標の「方向」にあるそのメトリクスの現在の値のセットを提供する。例えば、顧客ＤのＣＰＵ利用および応答時間は、顧客ＢのＣＰＵ利用および応答時間よりも低く、顧客Ｂはまさに、顧客ＢのＣＰＵ利用および応答時間の値を低くすることができる新たな構成をリクエストしている。さらに、顧客Ｄは、顧客Ｂのスループットの値よりも高いスループットの値を有し、顧客Ｂは、そのスループットを上げようとしている。
【００５９】
したがって、知識共有システム１０は（サーバ１２の動作を介して）顧客Ｂのパフォーマンス目標を顧客Ｂが達成できるよう、顧客Ｄの構成を顧客Ｂにも提案できると判断するとよい。２つの構成間の比較を実行することで、製品パフォーマンスに違いをもたらしそうなパラメータ値は、スレッド・プール・サイズおよびＤＢ接続プール・サイズであることが分かる。新たな構成の提案が、サーバによって顧客Ｂへ送られ、スレッド・プール・サイズおよびＤＢ接続プール・サイズ構成パラメータの変化を提供する。
【００６０】
よって、本発明の知識共有システムの実施形態によれば、クライアント間で共有される知識が動的に作り出されて、複数のクライアントからサーバに与えられ、貢献者（クライアント）の数が増えるにつれて、作り出される知識の有効性が向上する。知識共有システムは、クライアントと共有される構成の動的なセットを含む知識ベースを利用する。知識共有システムは、知識ベースが、それを使用するクライアント（例えば、異なるインストール／展開間で一般的アプリケーションの構成情報を共有する）の数とともに動的に更新および改善されることを可能にする。共有メカニズムは、クライアントが、任意の他のクライアントにより使用されている構成にアクセスできるようにする。具体的には、或るクライアントのニーズに適した新たな構成について、当該構成を使用してその利用から何らかの恩恵（例えば、応答時間のよりよいパフォーマンス）を受けた別のクライアントによって当該構成が利用可能にされると、クライアントはすぐに「通知」される。
【００６１】
当業者には周知のように、本発明による、上記に記載した上述の例示実施形態は、例えばプロセッサにより実行されるプログラム命令、ソフトウェア・モジュール、コンピュータ可読媒体上のコンピュータ・プログラム製品、論理回路、シリコン・ウエハー、集積回路、特定用途向け集積回路、ファームウェアなど、多数の方法で実装することができる。本発明は、その特定のバージョンを参照して記載されたが、そのほか複数のバージョンが考えられる。したがって、添付の特許請求の範囲に記載の意図および範囲は、本願明細書に含まれている好適なバージョンの記載に制限されるべきではない。
【００６２】
「コンピュータ・プログラム媒体」、「コンピュータ使用可能媒体」、および「コンピュータ可読媒体」、「コンピュータ・プログラム製品」という用語は、全般的に、メイン・メモリ、二次メモリ、リムーバブル・ストレージ・ドライブ、ハード・ディスク・ドライブに取り付けられたハード・ディスク、および信号などの媒体を指すために使用されている。こうしたコンピュータ・プログラム製品は、ソフトウェアをコンピュータ・システムに提供する手段である。コンピュータ可読媒体は、コンピュータ・システムが、データ、命令、メッセージまたはメッセージ・パケット、およびその他のコンピュータ可読情報を、コンピュータ可読媒体から読み取ることができるようにする。コンピュータ可読媒体は、例えば、フレキシブル・ディスク、ＲＯＭ、フラッシュ・メモリ、ディスク・ドライブ・メモリ、ＣＤ−ＲＯＭ、およびその他の永久ストレージなどの不揮発性メモリを含むとよい。例えば、データおよびコンピュータ命令などの情報をコンピュータ・システム間で輸送するのに有用である。さらに、コンピュータ可読媒体は、コンピュータがそのようなコンピュータ可読情報を読み取ることができるようにする、有線ネットワークまたは無線ネットワークを含むネットワーク・リンクまたはネットワーク・インターフェースあるいはその両方などの一時的状態媒体（ｔｒａｎｓｉｔｏｒｙ  ｓｔａｔｅ  ｍｅｄｉｕｍ）にあるコンピュータ可読情報を含み得る。コンピュータ・プログラム（コンピュータ制御論理とも呼ばれる）は、メイン・メモリまたは二次メモリあるいはその両方に記憶される。さらにコンピュータ・プログラムは、通信インターフェースを介して受信されてもよい。そのようなコンピュータ・プログラムは、実行されると、コンピュータ・システムが本願明細書に記載された本発明の機能を実行できるようにする。特に、コンピュータ・プログラムは、実行されると、マルチコア・プロセッサがコンピュータ・システムの機能を実行できるようにする。したがって、そのようなコンピュータ・プログラムは、コンピュータ・システムのコントローラに相当する。
【００６３】
当業者であれば当然のことであるが、記載したばかりの好適な実施形態の様々な適応および変更を、本発明の範囲および意図から逸脱することなく構成することができる。したがって、当然のことながら、添付の特許請求の範囲に記載の範囲内で、本願明細書に具体的に記載された以外の本発明の実践が可能である。
【図１】
0005629261.tif 000014
【図２】
0005629261.tif 000015
【図３】
0005629261.tif 000016
【図４】
0005629261.tif 000017
【図５】
0005629261.tif 000018
【図６】
0005629261.tif 000019
【図７】
0005629261.tif 000020