(57)【要約】【課題】ネットワーク内のヘテロジニアス・コンピュータのネットワークでソフトウェアをプロビジョニングする装置および方法を提供すること。【解決手段】プロビジョナが、パッケージおよびパッケージのデプロイメント・スコープのリストを受け取り、次に、インストールされたアプリケーションについて各ノードを検査し、依存性および潜在的なアプリケーション衝突を記録する。さらに、プロビジョナは、複数のネットワーク・メトリックおよびノード・メトリックを測定する。依存性情報、衝突情報、およびメトリックに基づいて、１つまたは複数のノードが選択され、ソフトウェアが、依存性情報および衝突情報に従って、プロビジョニングされ、または除去され、あるいはその両方を行われる。【選択図】図７
2007128521.tif 000002
【特許請求の範囲】
【請求項１】
分散情報処理システム内の複数の計算ノードでソフトウェアを提供する方法であって、ノード・マネージャ上の前記方法が、
ネットワークを介して通信するように結合された複数の計算ノードのうちの少なくとも１つでのインストールに関するソフトウェア・パッケージ内のソフトウェア・モジュールのリストを受け取るステップと、
インストールのために前記ソフトウェア・モジュールを受け取る資格を有するノードのリストを受け取るステップであって、該リストが、インストールに関するソフトウェア・モジュールの前記リストと前記複数のノードの所与のノードにインストールされているすべてのソフトウェア・モジュールとの間のすべての依存性を含む、ステップと、
前記依存性のリストが所与の閾値未満であることに応答して、前記ソフトウェア・モジュールのインストールのために前記複数のノードのうちの少なくとも１つのノードを選択することと
を含む方法。
【請求項２】
前記ソフトウェア・モジュールを前記選択されたノードにインストールするステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
各選択されたノードから、前記インストールの結果を示すメッセージを受け取るステップ
をさらに含む、請求項２に記載の方法。
【請求項４】
前記依存性に従って、選択されたノード上のソフトウェアをアンインストールするステップ
をさらに含む、請求項１に記載の方法。
【請求項５】
選択された各ノードの識別子をユーザ・インターフェースに提示するステップと、
どのソフトウェアを前記選択されたノードにインストールするかを示すユーザ入力を受け取るステップと、
前記ユーザ入力に従って、インストールされるソフトウェア・モジュールおよび除去されるソフトウェアの識別のうちの少なくとも１つを少なくとも１つの選択されたノードに送るステップと
をさらに含む、請求項１に記載の方法。
【請求項６】
前記リストが、１つまたは複数の計量を含み、前記計量が、
提供待ち時間と、
ライセンス付与コストと
のうちの少なくとも１つを含む、請求項１に記載の方法。
【請求項７】
前記依存性が、
データ結合と、
スタンプ結合と、
制御結合と、
外部結合と、
共通結合と、
内容結合と
のうちの少なくとも１つを含む、請求項１に記載の方法。
【請求項８】
分散情報処理システム内の複数の計算ノードでソフトウェアを提供する装置であって、
ネットワークを介して通信するように結合された複数の計算ノードのうちの少なくとも１つでのインストールに関するソフトウェア・パッケージ内のソフトウェア・モジュールのリストを受け取るＬＡＮインターフェースと、
インストールに関するソフトウェア・モジュールの前記リストと前記複数のノードの所与のノードにインストールされているすべてのソフトウェア・モジュールとの間の依存性に関する情報を保管するメモリと、
依存性の前記リストが所与の閾値未満であることに応答して、前記ソフトウェア・モジュールのインストールのために前記複数のノードのうちの少なくとも１つのノードを選択するコンパレータと
を含む装置。
【請求項９】
前記ソフトウェア・モジュールを前記選択されたノードにインストールするのに使用されるパッケージ・リポジトリ
をさらに含む、請求項８に記載の装置。
【請求項１０】
前記ＬＡＮインターフェースが、各選択されたノードから、前記インストールの結果を示すメッセージを受け取る手段をさらに含む、請求項８に記載の装置。
【請求項１１】
前記依存性に従って、選択されたノード上のソフトウェアをアンインストールする手段
をさらに含む、請求項８に記載の装置。
【請求項１２】
選択された各ノードの識別子をユーザに提示し、どのソフトウェアを前記選択されたノードにインストールするかを示すユーザ入力を受け取るユーザ・インターフェースと、
前記ユーザ入力に従って、インストールされるソフトウェア・モジュールおよび除去されるソフトウェアの識別のうちの少なくとも１つを少なくとも１つの選択されたノードに送る手段と
をさらに含む、請求項８に記載の装置。
【請求項１３】
前記リストが、１つまたは複数の計量を含み、前記計量が、
提供待ち時間と、
ライセンス付与コストと
のうちの少なくとも１つを含む、請求項８に記載の装置。
【請求項１４】
分散情報処理システム内の複数の計算ノードでソフトウェアを提供するコンピュータ・プログラム製品であって、
処理回路によって可読であり、
ネットワークを介して一緒に通信的に結合された複数の計算ノードのうちの少なくとも１つでのインストールに関するソフトウェア・パッケージ内のソフトウェア・モジュールのリストを受け取るステップと、
インストールのために前記ソフトウェア・モジュールを受け取る資格を有するノードのリストを受け取ることであって、前記リストが、インストールに関するソフトウェア・モジュールの前記リストと前記複数のノードの所与のノードにインストールされているすべてのソフトウェア・モジュールとの間のすべての依存性を含む、受け取ることと、
依存性の前記リストが所与の閾値未満であることに応答して、前記ソフトウェア・モジュールのインストールのために前記複数のノードのうちの少なくとも１つのノードを選択するステップと
を含む方法を実行するための前記処理回路による実行のための命令を保管する記憶媒体
を含むコンピュータ・プログラム製品。
【請求項１５】
前記ソフトウェア・モジュールを前記選択されたノードにインストールするステップ
をさらに含む、請求項１４に記載のコンピュータ・プログラム製品。
【請求項１６】
各選択されたノードから、前記インストールの結果を示すメッセージを受け取ること
をさらに含む、請求項１５に記載のコンピュータ・プログラム製品。
【請求項１７】
前記依存性に従って、選択されたノード上のソフトウェアをアンインストールすること
をさらに含む、請求項１４に記載のコンピュータ・プログラム製品。
【請求項１８】
選択された各ノードの識別子をユーザ・インターフェースに提示することと、
どのソフトウェアを前記選択されたノードにインストールするかを示すユーザ入力を受け取ることと、
前記ユーザ入力に従って、インストールされるソフトウェア・モジュールおよび除去されるソフトウェアの識別のうちの少なくとも１つを少なくとも１つの選択されたノードに送ることと
をさらに含む、請求項１４に記載のコンピュータ・プログラム製品。
【請求項１９】
前記リストが、１つまたは複数の計量を含み、前記計量が、
提供待ち時間と、
ライセンス付与コストと
のうちの少なくとも１つを含む、請求項１４に記載のコンピュータ・プログラム製品。
【請求項２０】
前記依存性が、
データ結合と、
スタンプ結合と、
制御結合と、
外部結合と、
共通結合と、
内容結合と
のうちの少なくとも１つを含む、請求項１４に記載のコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的にはコンピュータ・ネットワークに関し、具体的には、異種（ｈｅｔｅｒｏｇｅｎｅｏｕｓ）コンピューティング・デバイスのネットワークでソフトウェアを管理する方法および装置に関する。
【背景技術】
【０００２】
分散システムは、仕事の高いスループットまたは、システムを連続的あるいは、ほぼ連続的に利用することを必要とする状況で特に利用される、高い可用性のスケーラブル・システムである。
【０００３】
リソースを共用する機能を有する分散システムを、クラスタと称する。クラスタに、オペレーティング・システム・インスタンスが含まれ、このオペレーティング・システム・インスタンスは、リソースを共用し、互いに協力して、システム・リソースを最大化するためにシステム・タスクを調整し、実行する。効率的な調整を容易にするために、スケジューラが、システム・リソースの間でジョブを分配するのに利用される。
【０００４】
現在、スケジューラは、ジョブをどのように最適化できるかに関してオプションがかなり限られている。ほとんどのスケジューラは、所望のプロセスを実行するのに必要なアプリケーションを現在有する、クラスタ内のマシンしか考慮しない。すなわち、ほとんどのスケジューラは、あるマシンにアプリケーションをインストールし、その後、ジョブをそのデバイスに割り当てるというオプションを考慮するようにプログラムされていない。多くの状況では、これは、事前にインストールされたアプリケーションを有する、過度に利用されているマシンにジョブを割り当てることより有利である。
【０００５】
さらに、ほとんどのスケジューラは、マシンの固定的に定義されたグループを有し、各グループがあるタイプのジョブを実行する能力を有するか、すべてのジョブをすべてのマシンで実行できると仮定し、これによって均質なシステムを強制するかのいずれかである。ＩＢＭ  Ｔｉｖｏｌｉ  Ｉｎｔｅｌｌｉｇｅｎｔ  ＴｈｉｎｋＤｙｎａｍｉｃ  Ｏｒｃｈｅｓｔｒａｔｏｒ（ＩＴＩＴＯ）またはウィスコンシン大学のＣｏｎｄｏｒなどの高度なシステムさえ、スケジューリング・オプションとして個々のマシンでのソフトウェアの提供（ｐｒｏｖｉｓｉｏｎｉｎｇ）を考慮し、実行するようにはプログラムされていない。
【０００６】
管理者は、システムのプロビジョニングに関する２つのオプションを与えられる。第１のオプションは、「個別的（ｇｒａｎｕｌａｒ）」提供方法であり、これによれば、システム管理者は、各必要なアプリケーションを個々のコンピュータに手作業でインストールする。この戦略は、明らかに非効率的である。第２のプロビジョニング・モデルは、たとえばＩＢＭ社のＴｉｖｏｌｉ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  Ｍａｎａｇｅｒ（ＴＰＭ）で使用されている、「ロール（役割）ベース」モデルまたは「イメージベース」モデルである。このソリューションは、それぞれが１つまたは複数のロールを割り当てられたさまざまなマシンにインストールされる完全なソフトウェア・スタックを定義することを必要とする。このオートメーションは、事前に定義されたソフトウェア・スタックを有する傾向がある既存グリッド・ユーザについて、管理者の時間および作業をよく節約する。しかし、イメージベース・プロビジョニング・モデルは、常に変化するアプリケーション（新しいリビジョン、新しいソフトウェア）を利用したマシンではうまく働かない。イメージベース・プロビジョニング・モデルは、グラニュラプロビジョニング・モデルに固有のきめ細かな制御に欠け、したがって、ヘテロジニアス・モードのネットワークにまたがるスケジューリングという問題に適用された時に、うまく働かない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
したがって、異種アプリケーション・スタック、異種オペレーティング・システム、および異種マシン・タイプにまたがる提供を可能にする提供技法の必要が存在する。
【課題を解決するための手段】
【０００８】
簡単に、本発明によれば、分散情報処理システム内の複数の計算ノードでソフトウェアを提供（ｐｒｏｖｉｓｉｏｎｉｎｇ）する装置および方法が開示される。前記装置は、複数の計算ノードのうちの少なくとも１つでのインストールに関するソフトウェア・パッケージ内のソフトウェア・モジュールのリストを受け取るＬＡＮインターフェースを含み、前記ノードは、ネットワークを介して一緒に通信的に結合される。前記装置は、インストールに関するソフトウェア・モジュールの前記リストと前記複数のノードの所与のノードにインストールされているすべてのソフトウェア・モジュールとの間の依存性に関する情報を保管するメモリをも含む。前記装置は、さらに、依存性の前記リストが所与の閾値未満であることに応答して、前記ソフトウェア・モジュールのインストールのために前記複数のノードのうちの少なくとも１つのノードを選択するコンパレータを含む。
【０００９】
本発明の一実施形態で、前記装置は、前記ソフトウェア・モジュールを前記選択されたノードにインストールするのに使用されるパッケージ・リポジトリを含む。
【００１０】
本発明のもう１つの実施形態で、前記ＬＡＮインターフェースは、各選択されたノードから、前記インストールの結果を示すメッセージを受け取る手段をさらに含む。
【００１１】
本発明は、前記依存性に従って、選択されたノード上のソフトウェアをアンインストールする手段をも含む。
【００１２】
本発明は、選択された各ノードの識別子をユーザに提示し、どのソフトウェアを前記選択されたノードにインストールするかを示すユーザ入力を受け取るユーザ・インターフェースと、前記ユーザ入力に従って、インストールされるソフトウェア・モジュールまたは除去されるソフトウェアの識別あるいはその両方を少なくとも１つの選択されたノードに送る手段とをさらに含む。
【００１３】
本発明の一実施形態で、前記リストは、１つまたは複数の計量（ｍｅｔｒｉｃ）を含み、前記計量は、提供待ち時間と、ライセンス付与コストとのうちの少なくとも１つを含む。
【００１４】
本発明は、分散情報処理システム内の複数の計算ノードでソフトウェアを提供する方法をも含む。前記方法は、ノード・マネージャ上で実行され、ネットワークを介して通信するように結合された複数の計算ノードのうちの少なくとも１つでのインストールに関するソフトウェア・パッケージ内のソフトウェア・モジュールのリストを受け取ることと、インストールのために前記ソフトウェア・モジュールを受け取る資格を有するノードのリストを受け取ることであって、前記リストが、インストールに関するソフトウェア・モジュールの前記リストと前記複数のノードの所与のノードにインストールされているすべてのソフトウェア・モジュールとの間のすべての依存性を含む、受け取ることと、依存性の前記リストが所与の閾値未満であることに応答して、前記ソフトウェア・モジュールのインストールのために前記複数のノードのうちの少なくとも１つのノードを選択することとを含む。
【００１５】
前記方法は、前記ソフトウェア・モジュールを前記選択されたノードにインストールすることと、その後、各選択されたノードから、前記インストールの結果を示すメッセージを受け取ることとをも含む。
【００１６】
本発明のもう１つの実施形態で、前記方法は、選択された各ノードの識別子をユーザ・インターフェースに提示することと、どのソフトウェアを前記選択されたノードにインストールするかを示すユーザ入力を受け取ることと、前記ユーザ入力に従って、インストールされるソフトウェア・モジュールおよび除去されるソフトウェアの識別のうちの少なくとも１つを少なくとも１つの選択されたノードに送ることとを含む。
【００１７】
本発明の前述および他の特徴および利益は、添付図面に図示された本発明の好ましい実施形態の次のより具体的な説明から明白になる。
【００１８】
本発明と考えられる主題は、添付の特許請求の範囲で具体的に指摘され、明瞭に請求されている。本発明の前述および他の特徴ならびに利益は、添付図面と共に解釈される次の詳細な説明から明白になる。
【発明を実施するための最良の形態】
【００１９】
これらの実施例は、本明細書の新規な教示の多くの有利な使用の例にすぎないことを理解されたい。一般に、本願の明細書で行われる記述は、必ずしも、特許請求の範囲に記載された発明を限定するものではない。さらに、いくつかの記述は、ある発明の特徴にあてはまるが、別の発明の特徴にあてはまらない場合がある。一般に、特に断らない限り、一般性を失わずに、単数の要素を複数にすることができ、逆も同様である。図面では、類似する符号が、複数の図面を通じて類似する部分を指すものとする。
【００２０】
本発明は、一実施形態によれば、分散システム内のすべての既知のマシンの現在の状態ならびに必要なアプリケーションをインストールし、構成することの既知のコストまたは推定されたコストに基づいて、どこでジョブを実行するかを判定する方法およびシステムを提供することによって、従来技術に伴う問題を克服する。本発明は、分散システム内の同質的コンピュータまたは異種コンピュータのネットワーク上でソフトウェアを自動的にインストールし、構成し、アンインストールし、管理する、統一された構造をも提供する。
【００２１】
分散データ処理システム
図１を参照すると、本発明を実施できる分散データ処理システム１００が示されている。分散データ処理システムは、本発明を実施できるコンピュータのネットワークである。分散データ処理システム１００に、ネットワーク１０２が含まれ、ネットワーク１０２は、分散データ処理システム１００内で一緒に接続された計算ノード１０８ａ〜１０８ｎ（さまざまなコンピュータおよびデバイス）の間の通信リンクを提供するのに使用される媒体である。ネットワーク１０２に、有線接続または無線接続を含めることができる。少数の例示的な有線接続が、ケーブル、電話回線、および光ファイバである。例示的な無線接続に、ラジオ周波数（ＲＦ）伝送および赤外線（ＩＲ）伝送が含まれる。多数の他の有線接続および無線接続が、当技術分野で既知であり、本発明と共に使用することができる。
【００２２】
本発明の一実施形態で、分散データ処理システム１００は、広域ネットワーク１１０を介して他の分散データ処理システムに接続される。広域ネットワーク１１０に、通常、ゲートウェイ、ルータ、ハブ、および１つまたは複数のローカル・エリア・ネットワーク（ＬＡＮ）などのさまざまなネットワーク・デバイスが含まれ、これらのネットワーク・デバイスは、おそらくは銅線、同軸ケーブル、光ファイバ・ケーブル、および無線媒体を含むさまざまな媒体を用いて相互接続される。広域ネットワーク１１０は、インターネットの一部分を表すか含むことができる。当技術分野で既知のように、インターネットに、データおよびメッセージをルーティングする数千台の商用コンピュータ・システム、政府コンピュータ・システム、教育コンピュータ・システム、および他のコンピュータ・システムからなる主要なノードまたはホスト・コンピュータの間の高速データ通信回線のバックボーンが含まれる。本発明のもう１つの実施形態で、分散データ処理システム１００は、たとえばイントラネット、ローカル・エリア・ネットワーク（ＬＡＮ）、または広域ネットワーク（ＷＡＮ）など、１つまたは複数のタイプのネットワークとして実施される。
【００２３】
やはり図１に示されているのが、ネットワーク１０２に接続されたノード・マネージャ１０４である。さらに、ストレージ・ユニット１０６および計算ノード１０８ａ〜１０８ｎも、ネットワーク１０２に接続される。分散コンピューティング・システムでは、複数のサーバおよびクライアント・デバイスを使用することができ、本発明は、特定の個数のデバイスに限定されない。計算ノード１０８ａ〜１０８ｎは、たとえば、パーソナル・コンピュータまたはネットワーク・コンピュータとすることができる。ネットワーク・コンピュータは、永久的にまたは一時的にのいずれかでネットワークに結合された別のコンピュータからプログラムまたは他のアプリケーションを受け取る、ネットワークに結合された任意のコンピュータである。
【００２４】
図１に示されたシステムでは、計算ノード１０８ａ〜１０８ｎが、サーバとしてのノード・マネージャ１０４に対するクライアントである。他の実施形態では、計算ノード１０８ａ〜１０８ｎのうちの１つまたは複数を、ネットワーク１０２に接続された他のサーバに対するクライアントとすることができる。サーバとしてのノード・マネージャ１０４は、オペレーティング・システム・イメージなどのデータおよびアプリケーションをクライアント・デバイスとしての計算ノード１０８ａ〜１０８ｎに供給するため、およびクライアント・デバイスのデバイス・メトリックを測定し、取り込むために、クライアント・デバイスと通信することができる。
【００２５】
本発明は、異種システムまたは同質的システムと共に使用することができる。用語「異種」は、個々のデバイスが異なるハードウェア、アプリケーション・スタック、オペレーティング・システムなどを有することができる環境を説明するのに一般に使用される。逆に、用語「同質的」は、個々のデバイスが類似するハードウェア、アプリケーション・スタック、オペレーティング・システムなどを有する環境を説明するのに一般に使用される。
【００２６】
クラスタ
リソースを共用する機能を有する分散コンピューティング環境を、クラスタと称する。具体的には、コンピューティング環境に、１つまたは複数のクラスタを含めることができる。たとえば、図２に示されているように、コンピューティング環境２００に、２つのクラスタすなわち、クラスタＡ  ２０２およびクラスタＢ  ２０４が含まれる。各クラスタに、１つまたは複数のノード２０６が含まれ、ノード２０６は、リソースを共用し、システム・タスクの実行において互いに協力する。
【００２７】
ノードのクラスタＡ  ２０２およびクラスタＢ  ２０４のそれぞれが、それぞれノード・マネージャ２０８および２１０によって管理される。１つのノード・マネージャ２０８を、広域ネットワーク２１２を介して他のノード・マネージャ２１０に通信するように結合することができる。
【００２８】
ノード・マネージャ・オペレーティング・システム
ノードが結合される、図１に示されたノード・マネージャ１０４は、たとえば、拡張対話式エグゼクティブ（ＡＩＸ）オペレーティング・システムが動作する、米国ニューヨーク州アーモンクのＩｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ社の製品であるＩＢＭ  ＲＩＳＣ／Ｓｙｓｔｅｍ  ６０００システムとすることができる。ノード・マネージャは、複数の他のコンピュータ・オペレーティング・システムのどれであっても実行することもできる。周知のオペレーティング・システムに、たとえば、Ｎｏｖｅｌｌ  ＮｅｔＷａｒｅ（Ｒ）、ＩＢＭ  ＯＳ／２  Ｗａｒｐ  Ｓｅｒｖｅｒ（Ｒ）、ＩＢＭ  ＡＳ／４００（Ｒ）、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（Ｒ）  ＮＴ（Ｒ）、およびＯＳＦ  ＵＮＩＸ（Ｒ）の多数の変形形態が含まれる。サーバ・システムは、特定の機能についてクライアント・システムにアクセスすることができ、これらの機能に、ストレージ、アプリケーションのインストールまたは実行あるいはその両方、ならびにプロセスの実行が含まれるが、これらに限定はされない。
【００２９】
ノード
次に図３を参照すると、本発明の一実施形態による、ノード情報処理システムを示すブロック図が示されている。ノード情報処理システム３００は、ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）ローカル・バス・アーキテクチャを使用するデータ処理システムである。マイクロ・チャネルおよびＩＳＡなどの代替バス・アーキテクチャも使用できることに留意されたい。プロセッサ３０２およびメイン・メモリ３０４が、ＰＣＩブリッジ３０８を介してＰＣＩローカル・バス３０６に接続される。ＰＣＩブリッジ３０８には、プロセッサ３０２用の統合されたメモリ・コントローラおよびキャッシュ・メモリをも含めることができる。ＰＣＩローカル・バス３０６への追加接続は、直接構成要素相互接続を介してまたはアドイン・ボードを介して行うことができる。本発明の一実施形態では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ３１０、ＳＣＳＩホスト・バス・アダプタ３１２、および拡張バス・インターフェース３１４が、直接構成要素相互接続を介してＰＣＩローカル・バス３０６に接続される。対照的に、オーディオ・アダプタ３１６、グラフィックス・アダプタ３１８、およびオーディオ／ビデオ・アダプタ３１９は、拡張スロットに挿入されるアドイン・ボードによってＰＣＩローカル・バス３０６に接続される。拡張バス・インターフェース３１４は、キーボードおよびマウス・アダプタ３２０、モデム３２２、および追加メモリ３２４の接続を提供する。ＳＣＳＩホスト・バス・アダプタ３１２は、ハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、およびＣＤ−ＲＯＭドライブ３３０の接続を提供する。追加のＰＣＩ拡張スロットまたはＰＣＩアドイン・コネクタをサポートすることもできる。
【００３０】
当業者であれば、図３に示されたハードウェアが例示的であり、他の実施形態で使用されるハードウェアを、実施形態に応じて、図３に示され、上で説明したものから変更できることを了解するであろう。さらに、本発明のプロセスは、複数のマルチプロセッサを有するノード情報処理システム３００に適用することができる。
【００３１】
本発明の一実施形態で、ノード情報処理システム３００は、ネットワーク・コンピュータとして構成され、したがって、どれもが図３の破線３３２によって示される、ＳＣＳＩホスト・バス・アダプタ３１２、ハード・ディスク・ドライブ３２６、テープ・ドライブ３２８、またはＣＤ−ＲＯＭドライブ３３０を有しないか必要としない。この実施形態では、クライアント・コンピュータに、ＬＡＮアダプタ３１０、モデム３２２、または類似物など、あるタイプのネットワーク通信インターフェースが含まれる。
【００３２】
ソフトウェアおよびコンピュータ・プログラム媒体
本発明の一実施形態で、コンピュータ可読媒体３３６を読み取ることができる、ＣＤ−ＲＯＭドライブなどのデバイス３３４が、ＰＣＩローカル・バス３０６に接続される。本文書では、用語「コンピュータ・プログラム媒体」、「コンピュータ使用可能媒体」、「機械可読媒体」、「コンピュータ・プログラム製品」、および「コンピュータ可読媒体」が、一般に、不揮発性プログラム・メモリ、データ・メモリ、取外し可能ストレージ・ドライブ、ハード・ディスク・ドライブにインストールされたハード・ディスク、および信号などの媒体を指すのに使用される。これらのコンピュータ・プログラム製品は、ノード情報処理システム３００にソフトウェアを供給する手段である。コンピュータ可読媒体は、ノード情報処理システム３００が、データ、命令、メッセージもしくはメッセージ・パケット、および他のコンピュータ可読情報をコンピュータ可読媒体から読み取ることを可能にする。コンピュータ可読媒体に、たとえば、フロッピ、ＲＯＭ、フラッシュ・メモリ、ディスク・ドライブ・メモリ、ＣＤ−ＲＯＭ、および他の永久ストレージなどの不揮発性メモリを含めることができる。たとえば、データおよびコンピュータ命令などの情報をコンピュータ・システムの間で転送することが有用である。さらに、コンピュータ可読媒体に、有線ネットワークまたは無線ネットワークを含むネットワーク・リンクまたはネットワーク・インターフェースあるいはその両方など、コンピュータがコンピュータ可読情報を読み取ることを可能にする、一時的状態媒体内のそのようなコンピュータ可読情報を含めることができる。
【００３３】
この例示的システムに関して、さまざまなソフトウェア実施形態を説明する。この説明を読んだ後に、他のコンピュータ・システムまたはコンピュータ・アーキテクチャあるいはその両方を使用して本発明をどのように実施するかが、当業者に明らかになるはずである。
【００３４】
クライアント・オペレーティング・システム
プロセッサ３０２は、図３のノード情報処理システム３００内のさまざまな構成要素を調整し、制御するオペレーティング・システムを実行するのに利用される。オペレーティング・システムの一例が、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ社が市販するＯＳ／２（Ｒ）である。「ＯＳ／２」は、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｂｕｓｉｎｅｓｓ  Ｍａｃｈｉｎｅｓ  Ｃｏｒｐｏｒａｔｉｏｎ社の商標である。さらに、Ｊａｖａ（Ｒ）などのオブジェクト指向プログラミング・システムが、オペレーティング・システムとあいまって実行されることができ、ノード情報処理システム３００上で実行されるＪａｖａ（Ｒ）プログラムまたはＪａｖａ（Ｒ）アプリケーションからオペレーティング・システムへの呼出しを提供する。「Ｊａｖａ（Ｒ）」は、Ｓｕｎ  Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．社の商標である。オペレーティング・システム、オブジェクト指向オペレーティング・システム、およびアプリケーションまたはプログラムの命令は、ハード・ディスク・ドライブ３２６などのストレージ・デバイスに置かれ、プロセッサ３０２による実行のためにメイン・メモリ３０４にロードすることができる。
【００３５】
提供フレームワーク
本発明は、異種コンピュータまたは「ノード」のネットワークでソフトウェアを自動的にインストールし、構成し、アンインストールし、管理する統一されたインフラストラクチャを有するプロビジョニング・フレームワークを提供する。本発明のフレームワークは、アプリケーションの異なるバージョン、パッチ、および構成情報をインストールすることができ、コンピュータ・ハードウェアおよびオペレーティング・システムのすべての組合せにまたがってこれを行うのに十分に拡張可能である。
【００３６】
図４を参照すると、本発明による、提供フレームワーク４００の構成要素が示されている。図４には、提供フレームワーク４００内の構成要素の間のプロセス・フローも示されている。提供フレームワーク４００に、プロビジョニング・フレームワーク４００内の他の構成要素と通信し、これらを調整するノード・マネージャ４０２が含まれる。ステップ４０４で、必要なパッケージおよびデプロイメント・スコープのリストが、フロント・エンド４０６からノード・マネージャに送られる。一実施形態で、フロント・エンド４０６は、通常のクライアント・デバイスである。もう１つの実施形態で、フロント・エンド４０６は、下で説明するように、「スケジューラ」である。ステップ４０８で、ノード・マネージャ４０２が、ソフトウェア・パッケージおよび配置（ｄｅｐｌｏｙｍｅｎｔ）スコープのリストを「依存性」チェッカ４１０に送る。
【００３７】
「依存性」とは、あるプログラム・モジュールまたはソフトウェア・アプリケーションが別のモジュールに頼る度合を指す。依存性は、「高」結合または「低」結合を有することができる。結合が「低」の場合に、別のモジュールの内部実装は、問題でなく、モジュールは、安定したインターフェースと相互作用することができる。低結合の場合に、あるモジュールの変更は、別のモジュールの実装の変更を必要としない。しかし、高結合されたシステムを利用することによって、改善された効率を得ることができる。高結合の場合に、各マシンに追加されるか各マシンンでアップグレードされるアプリケーションに対して、慎重に注意を払わなければならない。
【００３８】
結合の少数の例示的タイプ（最低から最高まで）は、次の通りである。
データ結合  −  データ結合は、モジュールが、たとえばパラメータを介してデータを共用する時である。各データは、要素片であり、これらだけが、共用されるデータである（たとえば、平方根を計算する関数に整数を渡す）。
スタンプ結合（データ構造化結合）  −  スタンプ結合は、モジュールが、複合データ構造を共有し、各モジュールが、他のモジュールによってそのデータ構造のどの部分が使用されるかを知らない時である（たとえば、学生のＧＰＡ（成績評価点平均）を計算する関数に学生レコードを渡す）。
制御結合  −  制御結合は、行うべきことに関する情報を渡すことによって、あるモジュールが別のモジュールの論理を制御することである（たとえば、行うべきことのフラグを渡す）。
外部結合  −  外部結合は、２つのモジュールが、外部から課せられたデータ・フォーマット、通信プロトコル、またはデバイス・インターフェースを共用する時に発生する。
共通結合  −  共通結合は、２つのモジュールが、同一のグローバル・データ（たとえば、大域変数）を共用する時である。
内容結合  −  内容結合は、あるモジュールが、別のモジュールの内部作業を変更するかこれに頼る時である（たとえば、別のモジュールのローカル・データにアクセスする）。
【００３９】
オブジェクト指向プログラミングでは、親クラスがその子に結合されている場合に、サブクラスを結合することができる。
【００４０】
依存性は、ソフトウェア・パッケージ管理で関係を記述するのにも使用される。あるソフトウェア・パッケージが、他のソフトウェア・パッケージに依存する場合があり、しばしば、別のソフトウェア・パッケージの特定のバージョンに依存する。Ａｐｔパッケージ・フォーマットならびにＲＰＭパッケージ・フォーマットの一部のバージョンに、パッケージ間の依存性情報が含まれる。
【００４１】
依存性チェッカ４１０は、現在の依存性または潜在的な依存性を識別することができ、その結果、依存性によって引き起こされる現在の衝突または潜在的な衝突を判定することができる。ステップ４１２で、依存性チェッカ４１０は、提案されたジョブに関して資格を有するすべてのノードを判定する。依存性チェッカ４１０は、ノード・キャッシュ４１４に照会することによって、各マシンの状態に関する情報を引き出す。ノード・キャッシュ４１４は、ノード内の各マシンの状態に関する情報を保管する。それと同時に、ステップ４１２で、依存性チェッカ４１０が、依存性情報および衝突情報などのパッケージ・データをパッケージ・メタデータ・リポジトリ４１６から引き出して、ステップ４０４で受け取ったパッケージ・リストを成功裡にインストールするためにどのパッケージをインストールする必要があるかを判定する。
【００４２】
たとえば、ネットワークが、１つのサーバと３つのコンピュータまたはノードからなると仮定する。何がインストールされているかを知るために照会する時に、依存性チェッカ４１０は、各ノード４２８ａ〜４２８ｎにインストールされたパッケージのリストを得る。この例では、ノードＡが、ＤＢ２バージョン８．１をインストールされ、ノードＢが、Ｊａｖａ（Ｒ）バージョン１．４．２およびＷｅｂｓｐｈｅｒｅバージョン５をインストールされ、ノードＣが、Ｗｅｂｓｐｈｅｒｅバージョン５、ＤＢ２バージョン７．１、およびＭｏｄｅｌｅｒバージョン０．９をインストールされている。パッケージ・メタデータ・リポジトリ４１６に照会することによって、依存性情報、衝突、パッケージ・サイズ、ライセンス・コスト、および他の情報が、パッケージごとに入手される。下の表１に、この状況を記述したメタデータの例を示す。
【００４３】
【表１】
2007128521.tif 000003
【００４４】
図５に、Ｍｏｄｅｌｅｒ  １．０を取り巻く依存性を示す構成された依存性ツリー５００を示す。この依存性ツリーは、上の表１のデータの視覚的表現である。ＷｅｂｓｐｈｅｒｅおよびＤＢ２  ８．１が、Ｍｏｄｅｌｅｒ  １．０に依存する。しかし、Ｍｏｄｅｌｅｒ  ０．９は、Ｍｏｄｅｌｅｒ  １．０と衝突し、したがって、Ｍｏｄｅｌｅｒ  ０．９を除去しなければならないはずである。さらに、ＤＢ２  ７．１は、ＤＢ２  ８．１と衝突し、これも除去されなければならないはずである。上で説明したように、いくつかの依存性衝突は、プログラムに深刻に悪影響せずに存在することができる。２つのプロセスが同一ノードに存在するか同一ノードで実行されることを許容しなくなる前に達しなければならない結合の量を判定するために、閾値を事前に選択することができる。依存性をこの値と比較することができ、依存性結合が閾値未満の場合に、ソフトウェアがインストールされる。
【００４５】
次に、ステップ４１８で、依存性チェッカ４１０が、有資格ノードのリストをノード・マネージャ４０２に返す。このリストに、プロビジョニング待ち時間、ライセンス・コスト、ディスク使用量などのことに関する計画されたコストが含まれる。表２に、上で与えた例のコスト・リストを示す。
【００４６】
【表２】
2007128521.tif 000004
【００４７】
次に、ステップ４２０で、ノード・マネージャ４０２が、計画されたコストおよび重み付きメトリックに基づいて、プロビジョニングに最適のノードを判定する。この判定は、あるノードで新しいアプリケーションをプロビジョニングすることのコストを比較するコンパレータを用いて行うことができる。表２に示された例を調べると、ノードＡの使用は、ＷｅｂｓｐｈｅｒｅおよびＭｏｄｅｌｅｒ  １．０のインストールを必要とし、ノードＢの使用は、ＤＢ２およびＭｏｄｅｌｅｒ  １．０のインストールを必要とし、ノードＣの使用は、ＤＢ２のアップグレードおよびＭｏｄｅｌｅｒ  ０．９のアップグレードを必要とする。完全に自動化されたプロビジョニング・システムの場合には、最適ノードが、ポリシの組によって決定され、必要なアプリケーションを提供される。ウィザード駆動モデルの場合には、ノードのリストが、システム管理者または他のユーザに、コンピュータ端末などのユーザ・インターフェースを介して提示され、管理者は、プロビジョニング・プランを実施する前に、そのプロビジョニング・プランを編集するためにユーザ入力を与えることができる。システム管理者は、ネットワークおよびユーザの知識に基づいて判断を行うことができる。金銭が大きい重みを与えられる要因であることを知っていれば、管理者は、ノードＣを使用し、アップグレードを行うことによってライセンス付与コストを低く保つことを選ぶことができる。その代わりに、ユーザのうちの１人がＭｏｄｅｌｅｒ  ０．９を頻繁に使用することを知っていれば、管理者は、異なるマシンにＭｏｄｅｌｅｒ  １．０をインストールし、余分なライセンス料金を支払うことを選ぶ可能性がある。ポリシ・エンジンが、ディスク・スペース節約、ライセンス料金節約、またはこの２つのある組合せについて最適化を試みるためにそれ自体のルールを有することもできる。
【００４８】
ステップ４２２で、ターゲットにされたノード４２８ａ〜４２８ｎに、インストールするパッケージのリストを送る。次に、ステップ４２４で、パッケージ・リポジトリ４２６が、ノード４２８ａ〜４２８ｎに、そのノードにインストールされる実際のバイナリ・パッケージを供給する。これに、構成パッケージを含めることもでき、この構成パッケージは、アプリケーションのデフォルト構成を変更するためにこれらのアプリケーションと共にインストールされる構成ファイルを含むパッケージである。
【００４９】
ステップ４３０で、各ターゲットにされたノードが、インストールの結果を別々に報告する。最後に、ステップ４３２で、ノード・マネージャ４０２が、結果についてノード・キャッシュ４１４に通知する。さらに、このプロセス全体を通じて、提供フレームワーク４００の状態が、ノード・マネージャ４０２にパス・スルーされ、ノード・マネージャ４０２は、状況情報を用いてフロント・エンド４０６を更新する。
【００５０】
例示的なアンインストール（またはアップグレード）は、次のように行われるはずである。提供フレームワークは、最適インストール経路に既存パッケージのアップグレードまたはインストールが含まれることを判断する。当初に、アップグレードまたはインストールが可能であるかどうかを判定する。この判定は、そのパッケージに依存するすべてのパッケージおよびジョブが、提案されるアップグレードまたはインストールと衝突しないことを保証するために、当のパッケージの依存性ツリーを再帰的にトラバースすることが含まれる。次に、ノード・マネージャが、除去されるパッケージの完全なリストをターゲット・ノードに送り、このターゲット・ノードが、要求された動作を実行する。
【００５１】
一例として、図６に、サンプルの依存性ツリー６００を示す。パッケージＡをアップグレードする必要があるが、パッケージＢおよびパッケージＣがパッケージＡに依存する。これらのパッケージを介して再帰的に進んで、パッケージＢがＡの現在のバージョンを必要とすることと、パッケージＢを必要とする実行中のジョブがあることが判定される。パッケージＣは、より柔軟であり、変更を必要としない。したがって、パッケージＢに関するオプションは、これをＡ．２を使用するバージョンにアップグレードすること、またはジョブ１が完了した後にパッケージＢを除去することである。この判断は、マシン上のパッケージＢのインスタンスに関する必要に基づいて、ノード・マネージャによって行われる。次に、コマンドのリスト、たとえば、「Ａをバージョン１からバージョン２にアップグレードし、Ｂをアンインストールせよ」が、ジョブ１が終了するや否や、マシンに送られる。
【００５２】
しかし、提供フレームワークは、ネットワーク上でソフトウェアをインストールし、構成し、アンインストールし、管理するために、そうする命令を受け取らなければならない。これらの命令は、「スケジューラ」から来る。
【００５３】
スケジューラ
タスク・スケジューラは、分散システム内でＣＰＵの実行を複数の異なるタスクに割り振ることができる。これらのタスクの一部は、アプリケーションであり、一部は、オペレーティング・システム・タスク、バッチ・ファイル、スクリプトなどである。ヘテロジニアス・ノードのネットワークにまたがるスケジューリングは、インテリジェント・スケジューラすなわち、マシンでのソフトウェアの状態を知っており、必要な時と場合に追加ソフトウェアをプロビジョニングすることによってこの情報を利用できるスケジューラを必要とする。本発明は、ジョブの要件をサポートしないオペレーティング環境でのジョブのスケジューリングを可能にすることによって、既存スケジューラを改善する。本発明は、ヘテロジニアス・ノードにまたがるワークフローを最適化することができ、提供フレームワーク４００と通信して、ジョブを実行するためにノードに提供することができるかどうかを判定し、その後、最良の戦略すなわち、既存の可能なノードでジョブを実行するか新しいノードに提供するかを判断することができる。
【００５４】
図７を参照すると、本発明による、スケジューリング・プロセスの流れ図が示されている。この流れは、ステップ７００で開始され、直接にステップ７０２に移動し、ここで、通信的に一緒に結合された複数の計算ノードのうちの少なくとも１つでの実行についてスケジューリングされるべきジョブが、スケジューラにサブミットされる。一実施形態で、スケジューラは、サーバに常駐する。ステップ７０４で、スケジューラが、提供フレームワーク４００を呼び出し、提供フレームワーク４００は、分散システム内の複数の計算ノードを測量し、事前定義のメトリックの組を測定する。この測量に、とりわけ、各リソースの位置および各デバイス上の使用可能ハードウェアが含まれる。この測量は、ジョブをスケジューリングできるノードの可能な組を、そのジョブの要件をサポートできる環境を動作させることが既知の組に制限することを可能にする。たとえば、一部のジョブが、ハードウェア要件または位置要件の特定の組の下で動作することを必要とする場合がある。
【００５５】
次に、ステップ７０６で、スケジューラが、提供フレームワークと通信し、プロビジョニング・フレームワークは、ＣＰＵ負荷、ＣＰＵ容量、メモリ負荷、メモリ容量、ディスク使用量、個々のシステムのネットワーク速度、全体としてのネットワークの特性、および入ってくるプロセスの量およびタイプなどの入ってくるジョブのキューに関する情報などのスケジューリング・メトリックを含むがこれらに限定されないシステムに関する事実を示す計量を収集する。さらに、提供フレームワークは、ターゲットにされたシステムのソフトウェア・スタックと、各コンピューティング環境に現在インストールされているアプリケーションおよびこのジョブをサポートするために各コンピューティング環境で提供される必要があるアプリケーションの組とを含むがこれらに限定されない追加の事実を収集する。さらに、各必要なアプリケーションのディスク要件、プロセッサ要件、メモリ要件、およびライセンス・コストが、事実の組に追加される。最後に、各既知のアプリケーションをプロビジョニングするのに要するヒストリカル時間が、将来にアプリケーションをインストールするのに必要になる可能性がある時間の長さに関する洞察をもたらすことができる。履歴的時間として、過去のインストールの平均時間、中央値時間、または最長時間があり、単一ノードまたは複数ノードでのインストール時間を考慮することができる。
【００５６】
収集された事実を使用して、本発明は、次に、ステップ７０８および７１０で、構成を調べ、これらに事前定義の重み付け係数を割り当てるが、重み付け係数は、任意の個数の方法（ＨＴＴＰ、ウェブ・サービス、コマンド・ラインなど）を介して周期的に更新することができる。一実施形態では、重み付け係数は、ハードワイヤされ、変更されない。重み付け係数は、各ジョブをどこにスケジューリングするかをスケジューラが数学的に決定することを可能にする。各重み付け係数は、特定のノードでプロセスを実行するコストを表す。たとえば、下の表３に示されているように、構成を、高優先順位ジョブがライセンス・コストを考慮に入れず、これによって、アプリケーションがプレインストールされていないすなわちライセンスがまだ支払われていないマシンを含めることによって使用可能なマシンの数を増やすようにすることができる。したがって、ライセンス付与コストに、０が乗算される。この例では、プロセッサ速度が、ジョブをどこにスケジューリングするかを判断するための重要な態様であり、したがって、プロセッサ速度に４の係数によって重みが付けられる。これによって、ジョブをスケジューリングされる潜在的なデバイスの数が減る場合がある。最後に、使用可能メモリは、考慮されなければならない要因であり、したがって、２の係数によって重みを割り当てられる。
【００５７】
【表３】
2007128521.tif 000005
【００５８】
ステップ７１２で、係数が、それに割り当てられた重みと共に、評価され、比較され、どのオペレーティング環境にジョブをスケジューリングしなければならないかに関する選択が行われる。この判断を行うセレクタは、ユーザ、命令の事前にプログラムされた組に基づいて自動的に選択するコンピュータ、または回路とすることができる。スケジューラが、ジョブがスケジューリングされるオペレーティング環境に関する判断を行ったならば、次のステップであるステップ７１４は、そのシステムがそのジョブをサポートするように十分に提供（ｐｒｏｖｉｓｉｏｎｉｎｇ）されているかどうかを検査することである。十分に提供されていない場合には、本発明は、ステップ７１６で、プロビジョニング・フレームワークを利用して、ターゲットにされた環境に、必要なアプリケーションをプロビジョニングする。環境に成功裡にプロビジョニングしたならば、または環境が既にプロビジョニングされている場合には、スケジューラは、ステップ７１８で、ジョブをその環境の実行キューに追加する。このプロセスは、ステップ７２０で停止する。
【００５９】
シナリオの例として、次のようなものがある。まず、「アプリケーションＡ」を必要とする新しいジョブが、ユーザによってスケジューラにサブミットされる。スケジューラは、それが管理するシステム内のノードの状態を検査し、そのジョブをスケジューリングできると判定する。たとえば、アプリケーションＡが、あるサーバにインストールされているが、そのサーバは、他のジョブによって集中的に使用されつつある。次に、スケジューラは、過度に使用されているマシンでそのジョブを実行するか、アプリケーションＡの別のインスタンスを提供するかの選択に直面する。ここで、コスト計量が使用される。スケジューラは、低速マシンでそのジョブを実行することのコスト（完了のための長い時間）と、余分のサイクルを有するマシンにそのアプリケーションをインストールすることのコスト（インストール・コスト）とを調べる。この場合に、アプリケーションＡは、かなり高いライセンス・コストを有するが、そのジョブは、高優先順位ジョブとしてフラグを立てられてもいる。スケジューラは、さまざまなマシンに照会して、時間、ディスク使用量などに関するインストール・コストを判定し、次に、スケジューラがそれを用いて構成されている計量に対して、収集した事実（ジョブ優先順位、時間のコスト、ディスクのコスト、ソフトウェア・ライセンスのコストなど）を検査する。結果の判定が、ライセンス・コストを節約する必要がジョブの緊急性に優るというものである場合には、スケジューラは、単純に、事前にプロビジョニングされたマシンにそのジョブをスケジューリングするはずである。そうではなく、ジョブの緊急性が金銭を節約する要望に優る場合には、スケジューラは、前に収集したインストール・コストに基づいて、アプリケーションＡをインストールするノードを選択する。次に、スケジューラは、提供フレームワークを呼び出して、そのノードにアプリケーションＡを提供する。提供フレームワークが成功裡にリターンするや否や、スケジューラが、新たに提供されたマシンでそのジョブをスケジューリングする。
【００６０】
結論
本発明の特定の実施形態を開示したが、当業者は、本発明の趣旨および範囲から逸脱せずに、この特定の実施形態に対して変更を行うことができることを理解するであろう。したがって、本発明の範囲は、この特定の実施形態に制限されない。さらに、添付の特許請求の範囲は、本発明の範囲内にそのような応用、変更、および実施形態のすべてを含むことが意図するものである。
【図面の簡単な説明】
【００６１】
【図１】本発明の実施形態を実施できる分散データ処理システムを示すブロック図である。
【図２】本発明の一態様による、複数のクラスタを有するコンピューティング環境の一実施形態を示すブロック図である。
【図３】本発明の諸実施形態による、クライアントとして実施できるデータ処理システムを示すブロック図である。
【図４】本発明の一実施形態による、プロビジョニング・フレームワークを示すブロック図およびプロセス・フロー図である。
【図５】本発明の一実施形態による、依存性ツリーの視覚的表現を示す図である。
【図６】本発明の一実施形態による、依存性ツリーの視覚的表現を示す図である。
【図７】本発明の一実施形態による、スケジューラのプロセス・フローを示す図である。
【符号の説明】
【００６２】
１００  分散データ処理システム
１０２  ネットワーク
１０４  ノード・マネージャ
１０６  ストレージ・ユニット
１０８ａ  計算ノード
１０８ｂ  計算ノード
１０８ｃ  計算ノード
１０８ｎ  計算ノード
１１０  広域ネットワーク
２００  コンピューティング環境
２０２  クラスタＡ
２０４  クラスタＢ
２０６  ノード
２０８  ノード・マネージャ
２１０  ノード・マネージャ
２１２  広域ネットワーク
３００  ノード情報処理システム
３０２  プロセッサ
３０４  メイン・メモリ
３０６  ＰＣＩローカル・バス
３０８  ＰＣＩブリッジ
３１０  ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ
３１２  ＳＣＳＩホスト・バス・アダプタ
３１４  拡張バス・インターフェース
３１６  オーディオ・アダプタ
３１８  グラフィックス・アダプタ
３１９  オーディオ／ビデオ・アダプタ
３２０  キーボードおよびマウス・アダプタ
３２２  モデム
３２４  追加メモリ
３２６  ハード・ディスク・ドライブ
３２８  テープ・ドライブ
３３０  ＣＤ−ＲＯＭドライブ
３３２  破線
３３４  デバイス
３３６  コンピュータ可読媒体
４００  プロビジョニング・フレームワーク
４０２  ノード・マネージャ
４０４  必要なパッケージおよびデプロイメント・スコープのリストをフロント・エンド４０６からノード・マネージャに送るステップ
４０６  フロント・エンド
４０８  ノード・マネージャ４０２がソフトウェア・パッケージおよびデプロイメント・スコープのリストを「依存性」チェッカ４１０に送るステップ
４１０  依存性チェッカ
４１２  依存性チェッカ４１０が提案されたジョブに関して資格を有するすべてのノードを判定し、依存性情報および衝突情報などのパッケージ・データをパッケージ・メタデータ・リポジトリ４１６から引き出して、ステップ４０４で受け取ったパッケージ・リストを成功裡にインストールするためにどのパッケージをインストールする必要があるかを判定するステップ
４１４  ノード・キャッシュ
４１６  パッケージ・メタデータ・リポジトリ
４１８  依存性チェッカ４１０が、有資格ノードのリストをノード・マネージャ４０２に返すステップ
４２０  ノード・マネージャ４０２が、計画されたコストおよび重み付きメトリックに基づいて、プロビジョニングに最適のノードを判定するステップ
４２２  ターゲットにされたノード４２８ａ〜４２８ｎに、インストールするパッケージのリストを送るステップ
４２４  パッケージ・リポジトリ４２６が、ノード４２８ａ〜４２８ｎに、そのノードにインストールされる実際のバイナリ・パッケージを供給するステップ
４２６  パッケージ・リポジトリ
４２８ａ  ノード
４２８ｎ  ノード
４３０  各ターゲットにされたノードが、インストールの結果を別々に報告するステップ
４３２  ノード・マネージャ４０２が、結果についてノード・キャッシュ４１４に通知するステップ
５００  依存性ツリー
６００  依存性ツリー
７０２  スケジューラが新しいジョブを受け取るステップ
７０４  ノードの可能な組にジョブを制限するステップ
７０６  スケジューラが、システムに関する事実を収集するステップ
７０８  スケジューラが、最適化について構成を検査するステップ
７１０  重み付け係数を割り当てるステップ
７１２  スケジューラが、最適ノードを選択し、そのノードにプロビジョニングする必要があるかどうかを判定するステップ
７１４  ノードにプロビジョニングする必要があるかどうかを判定するステップ
７１６  プロビジョニング・コマンドをプロビジョニング・ソフトウェアに送るステップ
【図１】
2007128521.tif 000006
【図２】
2007128521.tif 000007
【図３】
2007128521.tif 000008
【図４】
2007128521.tif 000009
【図５】
2007128521.tif 000010
【図６】
2007128521.tif 000011
【図７】
2007128521.tif 000012
【外国語明細書】
2007128521000001.pdf
2007128521000002.pdf
2007128521000003.pdf
2007128521000004.pdf