JP2005502104A

JP2005502104A - 計算インフラストラクチャに対する変更を管理するシステム

Info

Publication number: JP2005502104A
Application number: JP2003504264A
Authority: JP
Inventors: ノーセラ、デイヴィッド
Original assignee: TOTALECARE Inc
Current assignee: TOTALECARE Inc
Priority date: 2001-06-11
Filing date: 2002-06-11
Publication date: 2005-01-20
Also published as: US20050120101A1; EP1405199A4; WO2002101572A1; EP1405199A1

Abstract

要約書なし。

Description

【技術分野】
【０００１】
［関連出願への相互参照／優先権の主張］
本出願は、２００１年６月１１日出願の米国特許出願第６０／２９７，５１２号に対する優先権の利益を主張し、当該出願は全体として参照により本明細書に援用される。
【０００２】
［連邦政府による資金提供を受けた研究または開発に関する記載］
該当なし。
【０００３】
［付録の参照］
該当なし。
［発明の分野］
【０００４】
本発明は、包括的には計算および／またはネットワーク管理に関し、特に計算インフラストラクチャに対する変更を管理する改善された方法、装置、および製品に関する。
［発明の背景］
【０００５】
従来、計算インフラストラクチャ変更管理技法は、すべての潜在的影響が理解され適当なサインオフが達成され得るように、変更が起こる前に変更を公開するプロセスおよび方法を伴う。上記の手法は、必要ではあるが、しばしば時間がかかり面倒である。
【０００６】
さらに、公式の変更プロセスを実施する組織はしばしば、許可された変更と混在した無許可の変更に悩まされている。業界で使用されている変更管理のための典型的手法は先行型(proactive)であるが、無許可の、またはさらには偶発的な変更は扱われない。
【０００７】
したがって、計算インフラストラクチャに対する変更を管理する包括的方法、特に計算インフラストラクチャに対する無許可の、および偶発的な変更を検出するための解決法が必要とされている。
［発明の概要］
【０００８】
本解決法は、とりわけ、計算インフラストラクチャに対する変更を管理する改善された装置、方法、および製品を提供することによって従来技術の上記の問題を解決する。
【０００９】
したがって、「レポーティングとグルーピング」のセクションでさらに説明する本発明の一態様によれば、例示的な計算インフラストラクチャに対する変更を管理するためにノードおよび属性のグルーピングのための少なくとも１つの例示的手法が提供される。
【００１０】
「複数行コンフィギュレーション」のセクションでさらに説明する本発明の第２態様によれば、複数行の値を単一値に要約するためにチェックサムやデジタル署名のような値を用いて、複数の属性を高レベルでの単一属性として報告する少なくとも１つの例示的手法が提供される。この場合ユーザが変更の詳細にドリルダウンすることができる。
【００１１】
「データベース更新」のセクションでさらに説明する本発明の第３態様によれば、変更通知イベントを用いて複数のデータベーステーブルとソースコピーとの同期を保つ少なくとも１つの例示的手法が提供される。
【００１２】
「ダイナミックビーンと制御ビーンのペア」のセクションでさらに説明する本発明の第４態様によれば、１つをダイナミックビーンとし、もう１つを制御ビーンとするデュアルビーンを用いてダイナミックビーンの属性およびコンフィギュレーションを管理する少なくとも１つの例示的手法が提供される。
【００１３】
「属性テスト」のセクションでさらに説明する本発明の第５態様によれば、属性に関連する値を設定する手段としてコマンドを使用する少なくとも１つの例示的手法が提供される。コマンドはシンプルまたはダイナミックビーンを用いて実行される。コマンドは、内部Ｊａｖａコマンド、メソッドもしくは機能、外部システム、アプリケーションユーティリティまたは対話的プログラムであってもよい。
【００１４】
「Ｊａｖａ／ＪＭＸの拡張」のセクションでさらに説明する本発明の第６態様によれば、対話的コマンド等の非ＪａｖａアプリケーションコマンドにＪａｖａを接続するパイプの使用を含む、Ｊａｖａプログラムと、システムもしくはアプリケーションユーティリティまたは対話的コマンドとの間のブリッジが提供される。
【００１５】
「ゲートウェイ」のセクションでさらに説明する本発明の第７態様によれば、Ｊａｖａ／ＪＭＸを用いてエージェントレスノードを管理する少なくとも１つの例示的手法およびファイアウォールを通るトンネルとしてＪａｖａ／ＪＭＸを拡張する方法が提供される。
【００１６】
「新しいデータウェアハウスアーキテクチャ」のセクションでさらに説明する本発明の第８態様によれば、アーカイブオブジェクトを活用した法人データウェアハウスアーキテクチャ構築のための少なくとも１つの例示的手法が提供される。この新しいデータウェアハウスモデルは、データを集中的に格納せず、被管理ノード(Managed Node)またはゲートウェイにあるアーカイブオブジェクトを用いてデータを格納する。これは、大規模な集中化データウェアハウスノードの購入を避け、法人被管理ノード上の既存の未利用資源（ＣＰＵ、ディスクおよびメモリ）¹を利用してデータウェアハウス機能を実行する。
【００１７】
本発明のこれらおよびその他の態様、特徴および利点は、以下の説明および添付図面によって、より良く理解されるであろう。
【００１８】
本発明の実施形態は添付図面を参照して説明される。
［発明の詳細な説明］
【００１９】
さらに詳細に図面を参照すると、例示目的で、本発明は、図１〜図１２に包括的に示されるシステム構成、動作方法および製品または製造物として具現化される。このシステム、動作方法および製品は、本明細書に開示される基本概念から逸脱することなく、その構成および動作の詳細について変更してもよいことが理解されるであろう。したがって、本明細書の諸実施形態に関して記載される以下の説明は、限定的な意味で解釈されてはならない。
【００２０】
［高レベルの説明］
図１は、本発明の全体的アーキテクチャを示している。これは、マネージャ（図１−１．０、２．０、２．１、２．２）、ゲートウェイを有するマネージャ（図１−３．０）、ゲートウェイ（図１−４．０）、エージェントを有する被管理ノード（図１−５．１、５．２、５．３等）、エージェントレス(Agentless)である被管理ノード²（図１−６．０、６．１、６．２等）、ノードのように管理可能なアプリケーションソフトウェア等のソフトウェア³（図１−７．０、７．１等）、および管理可能なスペシャルデバイス⁴（図１−８．０、８．１等）からなる。
【００２１】
エージェントは被管理ノード上に構成可能であり（図２−Ａ．１）、ゲートウェイ（図２−Ａ．３）は、エージェントソフトウェアがインストールされていない被管理ノードによるエージェントレスのコンフィギュレーション（図−Ａ．４）を可能にするように構成可能である。エージェントレス被管理ノードは、特殊なエージェントソフトウェアを被管理ノードにインストールすることを必要とせずに本発明が管理することができるノードである⁵。例えば、ルータやストレージエリアネットワークスイッチがエージェントレスデバイスとして管理されてもよい。それはあるコンフィギュレーションのエージェントを用いてこのエージェントレス接続を達成する。そのエージェントは本例ではゲートウェイとして示されている（図１３．０、４．０−図２Ａ．３）。ゲートウェイは、マネージャから独立した専用ゲートウェイノード（図１−４．０）上で実行されてもよく、またはゲートウェイ機能はマネージャノード上で実行されてもよい（図１−３．０）。
【００２２】
エージェントは、複数のシンプルまたはダイナミックビーン（図２−１．０、３．０、４．０および６．０）からなる。シンプルおよびダイナミックビーンは属性のリスト（図５−２．ｘ、３．ｘおよび４．ｘ）を管理するために使用される。シンプルビーン（図９−３．０）は属性の固定リストを管理し、ダイナミックビーン（図９−１．０）は制御ビーン（図９−２．０）経由で環境設定される可変リストを管理する。
【００２３】
ダイナミックビーン内の属性は、被管理ノードでグルーピングされて（図９−２．３ Attribute-Group1）単一属性として報告されてもよく、または各属性が独立に報告されてもよい。属性は、同じくレポーティングおよび表示の目的で、マネージャでグルーピングされてもよい（図７−１．ｘ）。ノードもまた、マネージャでグルーピングされてもよい（図６−５．０および５．３）。これらのオプションは、ユーザによって完全に構成可能な計算インフラストラクチャに対する変更の特殊なレポーティングおよび表示（図５−１．１、図６−１．１、図７−１．１）を可能にする。場合によっては、複数行変更が検出されると、チェックサムまたはデジタル署名を用いて複数の出力行を単一値に要約する（図８−３．１）。ドリルダウン機能⁶を用いて特定の属性を表示することができる（図８−５．０）。これらのレポートおよび表示は、マネージャノード（図２−Ａ．２）のデータベーステーブル（図２−２．５．ａ、２．５ｂおよび２．５ｃ）から導出される。
【００２４】
ノード固有のコンフィギュレーションおよびレポーティングは、エージェントのコマンドおよび制御インタフェース（図３−４．０）経由で被管理ノード上で実行することができる。企業規模のコンフィギュレーションおよびレポーティングは、ノード固有のものとともに、マネージャのコマンドおよび制御インタフェース（図３−３．２）から行われる。
【００２５】
機能はビーンを用いて分散される。シンプルビーンは、特定のタスクのために「ハードコード」され、一定の属性を含む。より包括的なダイナミックビーン機能は通常ペアで分散され⁷、その場合、制御ビーンがダイナミックビーンを管理するために使用される（図９）。制御ビーンは、属性の名前と、ダイナミックビーンが実行することになる特定のテストを指定する。制御ビーンは選択されたテストを実行せず、それはダイナミックビーンが実行することになるテストを環境設定するために使用される。シンプルビーンはテストの固定リストを有するが、これは環境設定可能でないため、制御ビーンを必要としない⁸。ダイナミックビーンはテストを実行し、属性に対する値を設定する（fill）。これは、属性に対する変更された値として通知(Notify)イベント（図２−５．１、５．２、５．３および５．４）経由でマネージャ（複数可）に返される。ダイナミックビーンのPoll()メソッドが、例えば関連するデータベースを属性の最新値に同期させるために、マネージャによってコールされることも可能である（図９−１．２）。ダイナミックビーンに対してPoll()を使用すると、データベースは最初に属性に対する正しい名前および値で環境設定され、かつ／または１つもしくは複数のノードの停止後に最新に維持される。Notify()メカニズムを使用すると、変更のみがマネージャに送信される。
【００２６】
［エージェント］
ビーン
ビーンは、有益な作業を実行するために使用されるコードの独立した断片である。ビーンは、１つまたは複数のマネージャに接続されたエージェント内で実行される。本解決法は、複数のエージェントを含む。すなわち、エージェントはビーンのコンテナである。ビーンは、１つまたは複数の属性のために実行される独立の作業主体である。ビーンは、独立に、またはペアで配備される。ペアで配備される場合、制御ビーンとダイナミックビーンが協力して、マネージャ（複数可）のための属性のリストを維持することをサポートする（図９）。スケジューラ（図２２．０、７．０）は、ダイナミックビーンのためのテストをスケジューリングする特殊目的のビーンである（図２２．０、３．０、４．０および６．０）。
【００２７】
ダイナミックビーンと制御ビーンのペア
ペアで配備される場合、制御ビーンがダイナミックビーンを管理するために使用される⁹。図９はその関係を示している。マネージャが属性およびテストのリストで制御ビーンを更新する。図９−２．３、１．２および２．２において、memoryおよびnsocketsという名前は属性の例である。テストは、制御ビーンに対してマネージャによって指定される値である（図９−２．２）。図９におけるテスト値の例は、「getmemory」および「netstat -an | grep EST」である。制御ビーンは、マネージャにより更新されると、属性およびテストの名前をビーンコンフィグファイル（図９−２．３）に書き出す。ビーンコンフィグファイル内の値フィールドは、ダイナミックビーンが属性の値を導出するために実行する実際のテストである。例えば、ダイナミックビーンが「netstat -an | grep EST」コマンドを実行すると、これはnsocketsの値として被管理ノード上でオープンされているソケット接続の個数を設定する。マネージャは、複数の方法（例えば、図９−１．２に指定されているPoll()メソッド）でダイナミックビーンから属性の値を受け取り、テストの名前を制御ビーンにセットする。マネージャが制御ビーンのPoll()メソッドを呼び出すと（図９−２．２）、これは属性の値を、ダイナミックビーンが実行するように設定されているテストとみなす。ダイナミックビーンは、インスタンス化（起動）されるか、またはその公開インタフェース（図４−９．１）経由でreset()を受信すると、そのインコア(in-core)制御リストにビーンコンフィグ設定を再読込して適用する。それぞれの指定されている属性ごとに、ダイナミックビーンに対して、マネージャがExecuteNow()を実行するか、またはスケジューラがExecute()を実行すると、インコア制御リストに設定されているテストが実行され、属性の値がダイナミックビーンに設定される。ダイナミックビーンのPoll()メソッドが実行される場合にはいつでも、それは最新の属性値を返す¹⁰。ダイナミックビーンは、テストを実行している間に変更を検出した場合にはいつでも、マネージャへの通知イベント（図２−５．１、５．２、５．３、５．４）を発生し、マネージャがデータベースを更新する。マネージャ（図３−３．２）またはエージェント（図３−４．０）のコマンドおよび制御インタフェースが制御ビーンコンフィギュレーションを更新した場合にはいつでも、制御ビーンはマネージャへのNotify()イベントを発生してデータベースを更新する。なお、被管理ノードにより格納または所有されているデータについて、データベースはこのNotify()イベントメカニズムを用いて更新されることに留意されたい。これにより、あるマネージャでなされた変更が、被管理ノードまたはゲートウェイからイベントを受信するように登録されているすべてのマネージャと同期することが可能となる。シンプルビーンについても同様である。
【００２８】
ビーンインタフェース
シンプルビーンは、マネージャに対して一定の属性と、ダイナミックビーンによって公開されるインタフェースのサブセットを公開する。特殊なシンプルまたはダイナミックビーンは、追加のインタフェースを公開することができる。ダイナミックビーン（図４−１．）は、制御ビーン（図４−２．０）経由で設定されたテストまたは機能を実行する。これらのテストおよびすべてのビーンは、ダイナミックビーンに対するいくつかの公開インタフェース¹¹経由で制御することができる。公開インタフェースには以下のものがある（図４）が、これらには限定されない：
ａ）Execute()−これには属性名が渡され、その名前に関連するテストを実行する。Execute()（図２−２．１）は、変更が発生したかどうかを判定する。Execute()は、テストの結果をアーカイブ（図２−１．３）と比較することによってその判定を行い、変更が発生している場合、マネージャ（複数可）へのNotify()（図２−５．１）イベントを発生する。
ｂ）ExecuteNow()−これには属性名が渡され、テストを実行し、テストの結果を呼出し側に返す。ExecuteNow()は、通知イベントを発生してもしなくてもよい。
ｃ）Poll()−これは属性および値のリストを呼出し側に返す。Poll()がダイナミックビーン（図９１．２）に対してコールされた場合に返される値は、最近のExecute()の最新値である。換言すると、Poll()は、テストに関連する最新の値を表示するだけであり、そのテストを実行しない。Poll()は、マネージャ（複数可）を実際の値と再同期させるために使用される。それらの実際の値は、好ましい実施形態では被管理ノードに格納される（しかし、代替実施形態ではその必要はない）。Poll()が制御ビーンに対して実行される場合、それは名前と、各属性ごとに設定されているテストへの引数を返す。
ｄ）Reset()−resetは、ダイナミックビーンに対して、ビーンコンフィグファイル（図９２．３）を再読込してインコア制御リストを更新するように通知する。インコア制御リストは、ビーンコンフィグファイルのメモリバージョンである。制御ビーンに対するreset()は、ビーンコンフィグファイルを再読込する。すなわち、制御ビーンをその最後にセーブされた状態に戻すようにリセットする。
ｅ）Save()−ダイナミックビーンに対するSaveは、属性の名前および値をディスクにセーブして、ダイナミックビーンが再起動する時にその最後の既知の状態に復帰するようにする。それにより、属性の値はダイナミックビーンのインスタンス化を越えてセーブされ、ダイナミックビーンが起動するごとにテストを再実行する必要がなくなる。制御ビーンに対して実行されるSaveは、属性およびテストのインコアバージョンをビーンコンフィグファイルにセーブする（図９２．１）。
【００２９】
スケジューラ
スケジューラは、マネージャから（図３−３．２）または被管理ノード（もしくはゲートウェイ）上でローカルに（図３−４．０）のいずれかで事前にプログラムされた被管理ノード（図２−２．０、７．０）上で実行される。スケジューラは、ビーン（図２−１．０、３．０、４．０、６．０）の１つでビーンのExecuteメソッド経由で呼び出される特定の属性テストのスケジュールを含む。スケジューラは、スケジュール条件（例えば、毎時、毎月、毎日午後５時等）が検出されるとこれらのテストを自動的に呼び出す。本明細書では、スケジューラはダイナミックビーンとして（制御ビーンとともに）実施される¹²。
【００３０】
アーカイブオブジェクト
被管理ノード上のデータはアーカイブオブジェクトによって保管される。これは、通常は被管理ノード上に格納される複数回の変更を保持する¹³。アーカイブオブジェクトは、１）変更の世代を維持し、２）最小量のディスクストレージにデータを維持する、という方法を同時にサポートする。シンプルまたはダイナミックビーンがテストを実行すると、それ（ビーン）はテストからの出力をアーカイブオブジェクトに格納する。アーカイブオブジェクトは、データの挿入および抽出を行うメソッドをサポートする。アーカイブオブジェクトはまた、Diff()メソッドを用いてアーカイブの２つの世代を比較する能力もサポートする。シンプルおよびダイナミックビーンはこのDiff()メソッドを用いて変更を検出する。変更がDiff()によって検出された場合、ビーンは、すべてのマネージャへの変更通知を発生することを知る。
【００３１】
アーカイブのDiff()メソッドは、以下の「属性変換基準」のセクションに開示されるコンフィギュレーション比較基準に基づいて、複雑な変更通知を実行する。
【００３２】
属性テスト
スケジューリングされる属性テストの名前は属性と同じ名前でもよい¹⁴。属性テストが呼び出されると、シンプルまたはダイナミックビーンがテストを実行し、そのテストが属性の値を設定する。例えば、属性テストはスケジューリングされて「memory」と名付けられてもよい。スケジューラによって呼び出されると、ダイナミックビーンは「インコア」制御リスト内で属性名（例えばmemory）を検索してテストを探し、見つかったら、その属性を設定する実行すべき機能（例えばgetmemory)にその属性名（例えばmemory）を関連づける。テストからの返値（例えばgetmemoryは512を返す）は、ダイナミックビーンのmemory属性に値を設定することになる（例えばmemory=512 MB）。
【００３３】
図２において、executeメソッド（図２−１．０）がコールされると、それはテストの出力（図２−１．２）をアーカイブログ（図２−１．３）に書き出すローカル作業を実行する。アーカイブログは通常、エージェントを有する被管理ノード（図２−Ａ．１）にローカルに存在する。execute()およびexecuteNow()の公開インタフェースは、指定されたテストを実行するだけでなく、テストからの出力が以前の実行と異なるかどうかを検出する。これは、アーカイブオブジェクトのDiff()メソッドを用いて行われる。テストからの出力が以前の出力と異なる場合、シンプルまたはダイナミックビーンは、変更通知イベントを発生し、マネージャノード（図２−Ａ．２）上のイベントハンドラ（図２−５．０）に転送してもよい。
【００３４】
ＪａｖａＪＭＸの拡張
ＪａｖａＪＭＸは、Ｊａｖａアプリケーションを管理するシステムおよび方法を規定する。本発明は、Ｊａｖａを超えてＪＭＸの概念を拡張し、非Ｊａｖａアプリケーションを管理するためのブリッジを提供する。これは、以下のような２つの例示的技法を用いて達成される：
１）シンプルまたはダイナミックビーン（図２−３．０）が、Ｓｈｅｌｌ、Ｐｅｒｌ、Ｎａｗｋ、Ｃ、Ｃ＋＋等のような言語で書かれたシステム（非Ｊａｖａ）コマンド（図２−３．２）を呼び出してテストを実行し、その結果（図２３．１）をビーンに返す。このメカニズムによれば、Ｊａｖａプログラム（またはある言語もしくはフレームワークで書かれたプログラム）が異なるフレームワークにおけるアプリケーションを管理することが可能となる。
２）ビーンはパイプ（図２−４．１）を用いてコマンドをシステムコマンドインタプリタまたは対話的プロセス（図２−４．２）に送る。このメカニズムによれば、Ｊａｖａプログラム（またはある言語もしくはフレームワークで書かれたプログラム）が異なるフレームワークにおける対話的アプリケーションを管理することが可能となる。
【００３５】
なお、ＪａｖａＪＭＸフレームワークは、アダプタがＪａｖａＪＭＸから非Ｊａｖａインタフェース（例えば、ＳＮＭＰ、ＨＴＴＰ等）への橋渡しをするために使用され得ることを開示していることに留意されたい。上記の技法は、より頑強でより簡易なＪＭＸアダプタを書くためにも使用可能である。例えば、本明細書に開示されるシステムおよび方法を用いて、データベースを管理するようにＪＭＸを拡張して、データベースマネージャの対話的コンフィギュレーションユーティリティ（例えば、ＯｒａｃｌｅＳＱＬＤＢＡタスク）を管理するために、ＪＭＸアダプタを書くことができる。同時に、本発明は、ＪＭＸアダプタを必要とせずに非Ｊａｖａアプリケーションまたはシステムを管理する方法を提供する。
【００３６】
ゲートウェイ
エージェントは、被管理ノードから独立したノード上で実行されるように構成されることが可能であり、その場合、ＳＮＭＰ、Ｔｅｌｎｅｔ、ＦＴＰ、ＨＴＴＰ、ＳｅｃｕｒｅＳｈｅｌｌ等のネットワーク相互接続ソフトウェアが、エージェントとエージェントレス被管理デバイスの間の橋渡しをするために使用される。この構成では、マネージャ（図２−Ａ．２）は、エージェントレスデバイスと通信するためにゲートウェイ（図２−Ａ．３）エージェントと通信する。ゲートウェイはまた、ファイアウォールを通るオープンされているプロトコル経由でゲートウェイがトンネルすることを可能にすることによって、ファイアウォールを通って通信を行うようにＪａｖａ／ＪＭＸフレームワークを拡張する。ゲートウェイはさらに、既存のＶＰＮソリューション、またはＳｅｃｕｒｅＳｈｅｌｌ、Ｔｅｌｎｅｔ、ＦＴＰまたは任意のリモート管理ソリューションの実施を活用してマネージャの到達範囲を拡張することにより、リモート管理がいかなるプロトコルでいかなる場所のノードやエージェントレスノードをも管理することを可能にすることができる。
【００３７】
新しいデータウェアハウスアーキテクチャ
本解決法のもう１つの態様はさらに、法人データウェアハウスアーキテクチャを構築する新規な技法を提供することである。通常、データウェアハウスは、複数のフィーダシステムからのデータを含み、そのデータを、ビジネスを管理するために使用される法人データウェアハウスのデータモデルへと再フォーマットするためにＥＴＬ（抽出、変換およびロード）メカニズムが使用される。データウェアハウスアーキテクチャは集中化され、ビジネスデータのコピーをこれらの大規模な集中化されたデータウェアハウスに格納する。データウェアハウスアーキテクチャは、時には、そのデータの全部または一部を、処理のために操作データストアまたはデータマートに供給する。
【００３８】
本解決法のアーカイブオブジェクトは、被管理ノードにデータを保管する。そのデータは、変更データのみである必要はなく、組織がビジネス意思決定を行うために格納することを必要とするいかなるデータであってもよい。マネージャ上のデータベースは変更を格納するだけである必要はなく、「データマート」または「操作データストア」およびアーカイブオブジェクトとみなすことができ、すべてがまとまって作用して「データウェアハウス」とみなすことができる。
【００３９】
本発明のアーカイブオブジェクトおよびフレームワークは、計算インフラストラクチャにおけるすべての被管理ノードまたはゲートウェイの間に分散したデータウェアハウスを格納するデータウェアハウスを構築するために使用されてもよい。データを被管理ノードから中央ウェアハウスに移動させるのではなく、被管理ノード上のディスクスペースがデータウェアハウスを構築するために利用され、これが組織のためのデータウェアハウスとして使用される。エージェントのextractメソッドは、この高度に分散したデータウェアハウスのコピーが操作データストアまたはデータマートに供給されることを可能にする。ビーンへの拡張された公開インタフェース（例えば、ＳＱＬシンタックス、ＬｉｓｔＰｕｌｌ、Ｅｘｔｒａｃｔ）のセット経由であらゆるエージェントにクエリを分散させることによって、アーカイブに対する高度に分散したクエリがサポートされる。
【００４０】
［マネージャ］
マネージャ
マネージャは、管理機能をサポートするためのＧＵＩおよびビジネスロジックの両方を含む¹⁵。マネージャは、本解決法の諸態様および特徴にグラフィカルインタフェースを提供する。複数のマネージャがマネージャビーンを用いて相互接続されてもよい。それらのマネージャビーンは、あるマネージャが別のマネージャに対しエージェントとして見えるようにする特殊目的のビーンである¹⁶。複数のマネージャが単一のデータベースを共有してもよく、複数のマネージャがそれぞれ自己の独立のデータベースを有してもよい。
【００４１】
属性変換基準
属性変換基準は、ベースライン値とターゲット値の間の、より複雑な比較を可能にする。これは、ベースライン属性内の変換機能を用いて達成される¹⁷。ベースライン（図６−１．０）は、ベースライン属性のリストが、属性一致基準のために使用される複数の変換機能を含むことも例示している。属性一致基準には以下のものがあるが、これらには限定されない：
１）属性は、（図６−１．０）のAttribute-Cのシンタックスを用いて表現されるベースラインに等しくなければならない。
２）属性は、（図６−１．０）のシンタックスAttribute-Bを用いて表現されるベースライン（しきい値）を超えてはならない。50.le−これは、ターゲット属性が５０以下でなければならないと解釈される。
３）属性は、（図６１．０）のシンタックスAttribute-Aを用いて表現されるベースライン（範囲）で指定される値の範囲内に入らなければならない。ターゲット属性は２５以上５０未満でなければならないと解釈される。
４）システムは、比較のためのオペレータの完全なリストを含む（例：.le、gt、(And)、| Or、if、While等）。
属性比較基準のリストはプログラム可能であり、このことは、フレキシブルで、拡張可能で、複雑な比較を可能にする。
【００４２】
比較は、複数属性の集計を含んでもよい。これは、複数のノードに由来する複数のターゲット属性間の比較を複雑なルールと関連づけることを可能にする。これは、Attribute-E（図６−１．０）に表されており、この場合、関連づけオブジェクトが引数（この例ではルール）とともに指定される。
【００４３】
属性変換基準は、レポーティングおよび表示のためにマネージャで使用されることも、変更を検出するために被管理ノードで使用されることも、いずれも可能である。
【００４４】
データベース更新
このセクションは、変更通知メッセージまたはイベントの内容に基づいてデータベーステーブルへ変更をルーティングする方法を説明する。
【００４５】
データベースはマネージャ上に配置され、変更データは被管理ノードに保管される。属性データのソースはアーカイブに由来し、ダイナミックビーンコンフィギュレーションデータのソースは被管理ノード（複数可）に格納される¹⁸。このデータ（アーカイブ／ビーンコンフィグ）のコピーがマネージャ内のデータベーステーブルに存在する。ダイナミックビーンのコンフィギュレーションに対する更新は、被管理ノード（複数可）上で制御ビーンを用いてビーンコンフィグファイルに格納される。ビーンコンフィグファイルに対する更新が発生すると、通知イベントが制御ビーンからマネージャ（複数可）に送られ、マネージャは自己のデータベーステーブルを更新してその変更を反映させる。テストがビーン（シンプルまたはダイナミック）上で実行される時、変更が検出された場合、ビーンはマネージャ（複数可）への変更通知をトリガし、マネージャは自己のテーブルを更新してその変更を反映させる。
【００４６】
マネージャ（複数可）は、被管理ノード（複数可）に行き、それぞれのシンプルまたはダイナミックビーンのPoll()機能を実行し、その結果を用いて、Poll()機能から受け取ったデータで自己のデータベースコピーを更新することができる¹⁹。例えば、図９−１．２は、ダイナミックまたはシンプルビーンに対するPoll()機能がどのようにして属性の値を返すかを示している。データの有効なソースが被管理ノード（複数可）であるため、このPoll()要求を行うマネージャは、そのポーリングからの出力を用いて自己のデータベーステーブルを更新し、Poll()から返されたものを最新の値として書き込むことができる。同様に、制御ビーンのPoll()は、テストの有効なコンフィギュレーションを示し、制御ビーンをポーリングしたマネージャは、自己のテーブルを更新して、Poll()から返される値を最新のものとして反映させることができる。
【００４７】
一実施形態では、本解決法は、属性値への変更のみをマネージャ（複数可）へ送信する。これは、変更通知メカニズムにより達成される。図２は、本発明の通知メカニズムがどのようにしてマネージャ（複数可）上のデータベースを属性およびビーンコンフィグデータと同期した状態に保つかを示している²⁰。エージェントを有する被管理ノード（図２−Ａ．１）またはゲートウェイ機能（図２−Ａ．３）は、変更通知イベントを、マネージャ（複数可）（図２−Ａ．２）内のイベント通知ハンドラ（図２−５．０）に送る。これらのメッセージ（図２−５．１、５．２、５．３、５．４）の内容は、イベント通知ハンドラ（図２−５．０）がメッセージ（図２−２．４−ａ、２．４−ｂ、２．４−ｃ）を適当なデータベーステーブル（図２−２．５−ａ、２．５−ｂ、２．５−ｃ）へルーティングすることを可能にする情報を含む。なお、プロセスは通常非同期的（ノンブロッキング）であるが、同期的であってもよい（管理ダイナミックビーン（図２−１．０、３．０、４．０６．０）はデータベース更新が完了するまでブロックすなわち待機する）。作業をスケジューリングするように事前に構成されたスケジューラ（図２−２．０、７．０）は、事前にスケジューリングされたテストによりexecuteメソッド（図２−２．１、２．２、２．３、図２−７．１）を実行する。executeメソッドは、ダイナミックビーン（図２−１．０、３．０、４．０および６．０）に対するいくつかの公開インタフェースの１つである。ダイナミックビーンのexecute()メソッドがテストを実行し、テストを実行するプロセスで変更の検出が生起すると、マネージャへの変更通知イベントが発生する。
【００４８】
図１０は、再び変更通知プロセスを示している。スケジューラ２．０、Execute ２．１、ビーン１．０、変更通知イベント５．１が示されている。しかし、図１０はさらに、イベントハンドラ５．０がルーティング機能５．１を用いてデータベース変更２．４−ｘを適当なテーブル２．５−ｘに送ることを示している。
【００４９】
図１０はまた、本発明の持続性通知メカニズム（６．１、６．２および６．３）も示している。これは持続性²¹ＦＩＦＯキューを利用してメッセージを格納する²²。
【００５０】
図１０はさらに、ポーリングメカニズム８．ｘが通知メカニズム５．ｘとともに使用されることを示している。マネージャ起動ルーチンは、マネージャのために、図１０で再同期ループ８．０として示されているビーンのポーリングを実行するスレッドの起動を開始する²³。この名前によって暗示されるように、ポーリングは一般的に、データベースをビーンと再同期させるために使用されるが、それがポーリングの唯一の目的ではない。マネージャ起動（図１０３．０）、コマンドおよび制御（図１０−７．０）、内部マネージャ機能（図１０−７．２）が、ポーリングまたは１つもしくは複数のビーンの単一のポーリングを開始してもよい。本発明において公開される２種類のポーリングは、最新値をとる標準のPoll()と、ビーンにテストを実行させるとともにそのテストの結果をとってもよいPollNow()機能²⁴である。
【００５１】
図１０はまた、PollまたはPollNow()（７．４−７．５）がコマンド機能（７．２）によって実行され得ることも示している。コマンド機能は、実施目的で直接にビーンに対してデータを要求する、マネージャ内の任意の機能である。コマンド機能は通常、データベースに行き、属性の最新値を求めることができる。あるいは、コマンド機能はポーリング機能（図１０７．４、７．５）を用いて直接にビーンに行くこともできる。あるいは、コマンド機能は、再同期ループ（図１０８．０）に行き、データベースに対する更新を開始した後、データベースからその更新を読み出すこともできる。
【００５２】
［レポーティングとグルーピング］
このセクションは、多様なネットワーク上の複数の計算ノードに対する変更を管理する能力にとって極めて重要なレポーティングコンストラクトを開示する。
【００５３】
複数行コンフィギュレーション
表示およびレポートには複数行のものがある。図８は、詳細を、直接結果レベル（図８３．１）におけるデジタル署名（例えばチェックサム）と、図８５．０のさらなる詳細へのドリルダウンとにカプセル化することを可能にするドリルダウン（図８５．０）機能を示している。
【００５４】
ベースラインノードに対するシステム比較
本発明は、計算インフラストラクチャ内の変更を検出し報告する方法を提供する。図５は、ベースラインノード（図５−１．０）に対するシステム間比較を示している。この場合、ベースラインノード（図５−１．０）およびターゲットノード（図５−２．０、３．０および４．０）が選択されてから、比較され（図５−７．０）、結果が生成される。結果は、詳細へのドリルダウンを有するレポートまたは対話的表示とすることが可能である。本発明は、単一ノード（図５−１．０）（物理または論理、ハードウェアまたはソフトウェア）をベースラインとして使用し、それと複数のターゲットノード（図５−２．０、３．０、４．０）を比較して（図５−７．０）、システム間比較結果（図５−１．１）を生成することができる。結果は、ノード上の属性間のコンフィギュレーションの差を示す。これには例えば以下のものがあるが、これらには限定されない：
グループ内のファイルサーバの１つが、ソフトウェアパッチに関して最新とみなされ、そのファイルサーバを、選択された、すなわちターゲットとするファイルサーバと比較して、どのターゲットファイルサーバがソフトウェアパッチアップグレードを必要としているかを知る。
ベースラインノード（図５−１．０）からの属性（図５−１．３）が比較機能（図５−７．０）に供給され、ターゲットノード（図５−２．０、３．０、および４．０）からの属性（図５−２．２、３．２、４．２）と比較される。
【００５５】
ノードグループに対するシステム比較
次に図６を参照する。図６は、グループノード（図６−５．０）に対するベースライン（図６−１．０）のシステム間比較を示している。ここで、ベースライン（図６−１．０）は物理ノードではなく、ターゲットノード（図６−２．０、３．０および４．０）に対して期待される属性のリスト（図６−１．０）である。ノードグループ（図６−５．０）は、ターゲットノード（図６−２．０、３．０、および４．０）のグループが捕捉されてグループとしてラベルされ、レポーティングのためにそのように選択されるものとして示されている。このグルーピングは通常、レポーティングの前に行われ、意味のある名前（例えば、図６５．０ではNode-Group I）にセーブされる。例えば、ウェブサーバのグループが、同じ属性設定を要求するため、まとめてweb-groupという名前の単一のグループとして管理されるかもしれない。個別にターゲットノード（図６−２．０、３．０および４．０）を選択するのではなく、ノードグループ（図６−５．０）がレポーティングのために選択される。これは、レポートを生成するため、または対話的表示を設定するために使用可能である。考え方としては、属性のベースラインリスト（図６−１．０）は、グループ内の（図６−５．０）または個別に選択された（図６−４．０）複数のターゲットノードと比較する（図６−７．０）ためのマスタコピーとして使用可能である。ノードグループ（図６−５．０）の概念は、ターゲットノード（図６−４．０、３．０）のグループの選択をそれ自身の固有名とともにグループとしてセーブすることを可能にすることによって、その選択および管理を簡単にする。ベースラインノード（図６−１．０）からの属性（図６−１．３）が比較機能（図６−７．０）に供給され、ターゲットノード（図６−２．０、３．０、および４．０）上の属性（図６−２．２、３．２、５．２）と比較される。比較の結果（図６−１．１）は、属性のもとのベースラインリスト（図６−１．２）と、基準に一致するターゲット属性のリスト（図６−２．１、３．１、４．１）とを含む。基準には、属性がベースラインに一致しなければならない、属性がベースラインで指定される値の範囲内に入らなければならない、等がある。属性比較基準のリストはプログラム可能であり、これによりフレキシブルな比較が可能となる（詳細は「属性変換基準」を参照されたい）。１つの重要な主張は、ノードグループがノードもしくは他のノードグループ（図６−５．３）、またはその両方の組合せ（図６−５．０）を含み得ることである。この主張は、非常に多数のノードの表示および対話の場合に極めて重要である。
【００５６】
ノードおよび／またはノードグループに対する属性間比較
図７は、ノード（図７−２．０）またはグループノード（図７−５．０）およびノード（図７−２．０）に対するベースラインの属性間比較を示している。ここで、ベースライン（図７−１．０）は物理ノードではなく、属性グループ（図７−１．７）のリストである。属性グループ（図７−１．１、１．６）は、属性のリスト（図７−１．４、１．５）のためのコンテナである。ユーザは、ベースラインを選択する（図５、図６）のではなく、これらのグループを選択することができる。属性グルーピングの利点は、ノードに関連する属性のサブセットを用いて、ターゲットノードの集団全体のベースラインとしての比較ができることである。例えば、「TCP-CONFIG」という名前の属性グループ内のＴＣＰ／ＩＰ設定が、ネットワーク上のあらゆるノードに対してＴＣＰ／ＩＰ設定を比較するために使用されるかもしれない。属性グループを用いてレポーティングをする場合、ユーザはグループ（図７−１．７）を選択する。これは実際にはグループに含まれる属性のリスト（図７−１．４）である。これらは比較（図７−７．０）機能に供給される（図７−１．３）。ターゲットノードは、個別に選択されても（図７−２．０）、ノードグループを用いて選択されてもよい（図７−５．０）。比較機能（図７−７．０）は、ターゲットノード（図７−２．１）またはノードグループ（図７−５．１）から供給を受ける。ノードグループ（図７−５．０）は、それらの値をノード（図７−３．１および４．１）から受け取る。図７は、属性をグルーピングすることができることを示している（図７−１．７は１．４を含み、１．６は１．５を含む）。図７は、レポーティングのためにノード（図７−２．０）およびノードグループ（図７−５．０）の混合が使用可能であることを示している。ターゲットノード（３．０、および４．０）を含むノードグループ（図７−５．０）は、捕捉されてグループとしてラベルされ、レポーティングのためにそのように選択されてもよい。このグルーピングは通常、レポーティングの前に行われ、意味のある名前（node-Group II）にセーブされる。例えば、ルータ、サーバのグループが、同じコンフィギュレーション設定を要求するため、まとめてrouter-groupという名前の単一のグループとして管理されるかもしれない。個別にターゲットノード（図７−２．０、３．０および４．０）を選択するのではなく、ノードグループ（図７−５．０）がレポーティングのために選択される。これは実在のノード（図７−２．０）と混在している。比較（図７−７．０）の結果はレポートであっても対話的表示であってもよい。考え方としては、ベースラインは属性（図７−１．４、１．５）（物理または論理、ハードウェアまたはソフトウェア）のグループ（図７−１．７、１．６）からなり、複数のターゲットノード（図７−２．０、３．０、４．０）と比較（図７−７．０）するためのベースラインとして使用可能である。ノードグループ（図７−５．０）は、ターゲットノードのグループの選択をそれ自身の固有名とともにグループとしてセーブすることを可能にすることによって、その選択を簡単にする。ベースラインノード（図７−１．０）からの属性（図７−１．３）が比較機能（図７−７．０）に供給され、ターゲットノード（図７−２．０、３．０、および４．０）上の属性（図７−３．２、４．２）と比較される。比較の結果（図７−１．１）は、属性のもとのベースラインリスト（図７−１．２）と、基準に一致するターゲット属性のリスト（図７−２．１、３．１、図７−４．１）とを含む。基準には、属性がベースラインに一致しなければならない、属性がベースラインで指定される値の範囲内に入らなければならない、等がある。属性比較基準のリストはプログラム可能であり、これによりフレキシブルな比較が可能となる²⁵。
【００５７】
結果（図７〜図５、図６および図７の１．１参照）は、複数のグルーピングもしくは属性、属性グループ、ノードもしくはノードグループの個別の選択、またはこれらの選択を混合した変形を可能にする比較機能の出力である。
【００５８】
属性グルーピングと集計
図１１および前セクションは、レポーティングおよび表示の目的で属性を属性グループ（図１１−１．１および１．２）にグルーピング可能であることを示している。本発明は、属性グループが複数の集計機能（図１１−１．７）を含むことができることも開示する。これらは、グループ（図１１−１．１および１．２）内の属性に作用する機能である。図１１−７．４に示すように、集計機能１．６および１．５は、属性の値が表示またはレポートの一部として参照される時に計算される（図１１−７．０）。それにより結果が属性グループのプロパティとして表示される（図１１−７．２）。個別のプロパティ（図１１−１．５および１．６）が表示されてもよい（図１１−７．５および７．６）。集計機能は、例えばサイトにおけるユーザ数を計算して表示するために有用である。ここで、集計機能は、各ノード上のユーザ数のような属性をカウントし、それらのすべてのノードごとの属性が単一の属性グループに含まれる。属性グループが参照される場合、そのプロパティの１つは集計を含むSUMプロパティであってもよい。
【００５９】
ルート属性グループが他の属性グループ（図１１−１．４）またはグループのグループまたはグループさえも含む状況では、図１１−７．３に例示されているように、ツリー内のすべてのリーフノードについてリーフノード属性が集計される²⁶。
【００６０】
属性変換機能と属性集計機能
「属性変換基準」のセクションに既に開示したように、属性は、より複雑な属性間の比較を実施する変換機能を含むことができる。これは図１２にも示されている。特定の属性（図１２−１．４ａ）が変換機能（例えばRANGE()）を含む。これは、この属性をターゲット属性のリストと比較するために使用されてもよい。図１２は、変換機能が、RANGE、IF、GT等のようなオペレータとともに多種多様であり得ることを示している。変換機能は、値（図１２−１．４−ｂ）またはステータス（図１２−１．４−ｃ、１．４−ｄ）を返すことができる。
【００６１】
属性グループもまた変換機能を有し得る（図１２−１．４−ｄ）。属性グループは集計機能（図１２−１．３、１．３ａ）（「属性グルーピングと集計」のセクション）を含み、これらの集計機能は属性変換から参照されてもよい（図１２−１．２ａ、１．２ｂ）。これは、属性の集計および変換を単一の値またはステータスにまとめるために有益である。
【００６２】
変換および集計機能の拡張
頑強な属性変換機能および頑強な集計機能の組合せにより、プログラムを開発することを必要とせずに属性間の相互関連づけが可能となる。しかし、本発明の一部として現在定義されていない属性変換機能またはオブジェクトが参照された場合、それはまず本システム内の内部機能またはオブジェクトとして探索される。それが内部オブジェクトとして見つからない場合、集計機能の変換機能を評価するために外部コマンドスクリプトをコールする。このようにして本発明は、他の言語でカスタム機能を書き、コマンドスクリプト実行経由で本発明へとインタフェースする能力を含む、新しくより頑強な変換および集計機能を含むように拡張される。
【００６３】
［結論］
以上、本発明のいくつかの実施形態を説明したが、上記は単に例示であって限定的なものではなく、単に例として提示されているだけであることが当業者には明らかなはずである。本明細書（添付の特許請求の範囲、要約、および図面を含む）に開示されるすべての特徴は、特に明示的に断りのない限り、同じ目的、および同等または類似の目的に適う代替的特徴で置き換えてもよい。したがって、添付の特許請求の範囲により規定される本発明およびその均等物の範囲内に入るその変更例の数多くの他の実施形態が想定される。
【００６４】
例えば、本明細書に記載される技法は、ハードウェアもしくはソフトウェア、またはその２つの組合せのいずれで実施されてもよい。さらに、それらの技法は、少なくともプロセッサおよびそのプロセッサによって読み出し可能なストレージ媒体（揮発性および不揮発性のメモリおよび／またはストレージ要素を含む）をそれぞれ含むプログラム可能デバイス上で実行される制御プログラムとして実施されてもよい。それぞれのそのような制御プログラムは、コンピュータシステムと通信するために高水準の手続き型またはオブジェクト指向プログラミング言語で実施されてもよいが、所望であればプログラムはアセンブリ言語または機械語で実施することも可能である。それぞれのそのような制御プログラムはストレージ媒体またはデバイス（例えば、ＣＤ−ＲＯＭ、ハードディスクまたは磁気ディスケット）に格納されてもよい。このストレージ媒体またはデバイスは、本文書に記載される手続きを実行するためにコンピュータによって読み出される時に、コンピュータを設定し動作させるための汎用または専用プログラム可能コンピュータによって読み出し可能なものである。さらに、本明細書に記載される技法は、コンピュータプログラムを備えて構成されたコンピュータ可読ストレージ媒体として実施されてもよい。その場合、そのように構成されたストレージ媒体によりコンピュータが特定のあらかじめ規定された方法で動作する。
【００６５】
参考
１）本発明の時点では、ほとんどの大型コンピュータは３０％のＣＰＵ使用率で動作し、過剰のディスク、メモリおよびネットワーク帯域資源を有していた。
２）エージェントレス被管理ノードは、ゲートウェイエージェント構成により管理され、マネージャノード自身の上、またはゲートウェイ構成内の別個のノード上の両方で動作し得る。
３）複数のノードの管理をカプセル化するソフトウェア（例えば、ＥｌｅｍｅｎｔＭａｎａｇｅｒｓ、ＨＰＯｐｅｎＶｉｅｗ、ＢＭＣＰａｔｒｏｌ等）は、このアーキテクチャでは単一のノードとみなして管理することができる。
４）ネットワークから管理可能ないかなるデバイスまたは特殊ソフトウェアも、このシステムおよび方法を用いて管理可能である。
５）ＪａｖａＪＭＸは、非ＪＭＸアプリケーションを管理するためのアダプタ（例えばＳＮＭＰまたはＨＴＴＰアダプタ）をサポートするが、ＪａｖａＪＭＸは、ある種のアダプタがシステムもしくはアプリケーションユーティリティまたは対話的ユーティリティさえも実行可能であることを必要とすることは開示していない。本システムおよび方法は、ＪａｖａＪＭＸアダプタの概念を、いかなるシステムもしくはアプリケーションユーティリティまたは対話的プログラムにも適応するように、より頑強なＪＭＸアダプタのセットへと拡張するために使用可能である。
６）ドリルダウンを使用する場合、差分を含むデータファイルが被管理ノード、マネージャに格納されてもよく、または差分はドリルダウン時間中に計算され、その場合、もとのソースが被管理ノードもしくはマネージャに格納されてもよい。図８−２．１「node:path」は、差分の位置がフレキシブルであるとともに変動することを示すことを意図している。
７）ダイナミックおよび制御ビーン機能は同じビーン内にあってもよく、これはシンプルビーンとダイナミックビーンの間のハイブリッドを作る。実際にはこれは依然としてダイナミックであり、制御の機能をビーン内に結合している。
９）制御ビーンおよびダイナミックビーンの機能が別個のビーンとして配備される必要はない。
１０） pollNow()メソッドは、ExecuteNow()メソッドと同様に、各テストを実行することによって最新値を実際に更新するが、すべての属性テストを実行する。
１１）新たなインタフェース機能をビーン（制御ビーンおよびダイナミックビーンの両方とも）に追加することができる。
ここで、
１２）スケジューラはシンプルビーンもしくはカスタムコードとして実施されてもよく、または外部スケジューラ（例えばCronまたはAt）が使用されてもよい。
１３）アーカイブデータは、マネージャ、被管理ノード、およびファイルサーバのような別個のノード等、どこに格納されてもよい。
１４）テストの名前と属性の名前は異なっていてもよい。例えば、属性：SHMMAX=2500；テスト：SHMMAX_TEST="grep SHMMAX /etc/system"。
１５）代替実施形態では、ＧＵＩはマネージャから分離されていてもよい。
１６）代替実施形態では、マネージャビーンはプロキシエージェントとして作用し、エージェントのプライマリマネージャから別のセカンダリマネージャ（複数可）へのすべてのアクティビティ（例えば通知イベント）を代理するとともに、セカンダリマネージャ（複数可）が同じプロキシメカニズムにより同じマネージャビーン経由で要求を送信することも可能にする。
１７）代替実施形態では、属性変換機能はターゲット属性に対して実施されてもよい。
１８）ａ）属性およびビーンコンフィグデータはマネージャを出所としてもよく、ｂ）ノードとマネージャの間で共有されてもよく、ｃ）ここで指定されていない別のノードまたは外部データソースに由来してもよい。
１９）本解決法の代替実施形態では、すべてのデータがアーカイブ、集中化データベース、またはその２つの組合せのいずれかに格納される。データベースまたはアーカイブに格納される場合、データが格納される場所は可変でありフレキシブルであるが、好ましい実施形態では、データはアーカイブを出所とし、開示されているPollおよびNotifyメカニズムを用いてマネージャで最新に維持される
。
２０）データベースに返される通知は、ｈｔｔｐプロキシのようなプロキシによってもたらされてもよい。
２１）ＦＩＦＯ（図１０６．２）が持続性である（すなわちディスク上に格納される）必要はない。
２２）ＦＩＦＯ（図１０６．２）が被管理ノード上にある必要はない。
ここで、
２３）再同期（図１０８．０）はここでは単一のオブジェクト／スレッドとして示されているが、代替実施形態では、再同期は、ポーリングを必要とし得る多くの管理機能（図１０−７．２）に分散していてもよい。
２４） PollNow()には２つの形式がある。管理機能にデータを返すPollNowと、通知メカニズム（図１０５．１または６．１）の１つによってデータを返すPollNowとである。
２５）図７１．６ Attribute-Group-Yは属性グループを含む。これは属性および別の属性グループの両方を含む。
２６）含まれている属性のリストに個別に割当て可能な属性集計機能のリストも開示されている。これは、個別の属性（リーフノード）が、他のリーフノードを無視して集計リストを設定するために使用されることを可能にする。これはまた、リーフノードを包含または除外する、分岐ノードの集計も可能にする。
【図面の簡単な説明】
【００６６】
【図１】本解決法の態様および特徴を図式的に説明する図である。
【図２】本解決法の態様および特徴を図式的に説明する図である。
【図３】本解決法の態様および特徴を図式的に説明する図である。
【図４】本解決法の態様および特徴を図式的に説明する図である。
【図５】本解決法の態様および特徴を図式的に説明する図である。
【図６】本解決法の態様および特徴を図式的に説明する図である。
【図７】本解決法の態様および特徴を図式的に説明する図である。
【図８】本解決法の態様および特徴を図式的に説明する図である。
【図９】本解決法の態様および特徴を図式的に説明する図である。
【図１０】本解決法の態様および特徴を図式的に説明する図である。
【図１１】本解決法の態様および特徴を図式的に説明する図である。
【図１２】本解決法の態様および特徴を図式的に説明する図である。

Claims

本出願の明細書に示され記載される計算インフラストラクチャに対する変更を管理するシステム。
複数のノードを有する計算インフラストラクチャにおいて、この計算インフラストラクチャに対する変更を管理するシステムであって、このシステムは、１つまたは複数の被管理ノードと通信する１つまたは複数のマネージャノードを備え、このマネージャノードは、本明細書に提示される技法に従って、前記計算インフラストラクチャで発生する無許可の、および偶発的な変更を動的に検出するように構成される計算インフラストラクチャに対する変更を管理するシステム。