JP6336041B2 - 論理的多次元ラベルベースのポリシーモデルを使用した分散型ネットワークマネージメントシステム - Google Patents

Description

本明細書に記載される主題は、概して、管理ドメインのマネージングサーバ（物理的または仮想的）の分野に関し、特に、論理的多次元ラベルベースのポリシーモデルを忠実に守る、管理ドメイン規模のポリシーに係る、マネージングサーバに関する。

管理ドメインのサーバ（物理的または仮想的）は、ポリシーに従って管理される。例えば、セキュリティポリシーは、アクセス制御および／またはセキュア接続を指定することができ、一方、リソース利用のポリシーは、管理ドメインのコンピューティングリソース（例えば、ディスクおよび／または周辺機器）の利用を指定することができる。従来のポリシーは、物理的デバイスを参照し、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（以下ＩＰ））アドレス、ＩＰアドレスレンジ、サブネットワーク、および、ネットワークインターフェース、などの下位レベルの構成概念の観点で表現される。これらの下位レベルの構成概念は、きめの細かいポリシーを、抽象的で自然な方法で書くことを困難にする。

上記および他の論点は、管理ドメイン内の特定の被管理サーバの状態に対する変更を処理するための、方法、非一時的コンピュータ可読記憶媒体、およびシステム、によって対処される。管理ドメインが、複数の被管理サーバを含み、被管理サーバは、マネージメント命令を使用してマネージメントモジュールを構成し、構成されたマネージメントモジュールが、１つまたは複数のルールのセットを備える管理ドメイン規模のマネージメントポリシーを実装するようにする。方法の一実施形態は、特定の被管理サーバの第１の記述を修正して、特定の被管理サーバの変更された状態を示し、それによって、特定の被管理サーバの第２の記述を指定する、ステップを含む。方法は、未修正の第１の記述を、第２の記述と比較し、それによって、記述変更を指定するステップを、さらに含む。方法は、記述変更に基づき、特定の被管理サーバに以前送られたマネージメント命令を更新すべきかどうかを判定するステップを、さらに含む。方法は、特定の被管理サーバのマネージメント命令を更新するという判定に応答して、第２の記述に基づき、ルールのセット内のどのルールが、特定の被管理サーバに現在関連するのかを判定し、それによって、現在の関連ルールを指定する、ステップと、現在の関連ルールが、以前の関連ルールと異なるかどうかを判定するステップであって、以前の関連ルールは、未修正の第１の記述に基づき判定された、ステップと、現在の関連ルールが、以前の関連ルールと同一であるという判定に応答して、それ以上何の行動も取らないステップと、をさらに含む。

媒体の一実施形態には、ステップを実行するべく実行可能なコンピュータプログラムモジュールを記憶する。ステップには、特定の被管理サーバの第１の記述を修正して、特定の被管理サーバの変更された状態を示し、それによって、特定の被管理サーバの第２の記述を指定する、ステップが含まれる。ステップには、未修正の第１の記述を、第２の記述と比較し、それによって、記述変更を指定するステップが、さらに含まれる。ステップには、記述変更に基づき、特定の被管理サーバに以前送られたマネージメント命令を更新すべきかどうかを判定するステップが、さらに含まれる。ステップには、特定の被管理サーバのマネージメント命令を更新するという判定に応答して、第２の記述に基づき、ルールのセット内のどのルールが、特定の被管理サーバに現在関連するのかを判定し、それによって、現在の関連ルールを指定する、ステップと、現在の関連ルールが、以前の関連ルールと異なるかどうかを判定するステップであって、以前の関連ルールは、未修正の第１の記述に基づき判定された、ステップと、現在の関連ルールが、以前の関連ルールと同一であるという判定に応答して、それ以上何の行動も取らないステップと、がさらに含まれる。

システムの一実施形態には、ステップを実行するべく実行可能なコンピュータプログラムモジュールを記憶する非一時的コンピュータ可読記憶媒体が含まれる。ステップには、特定の被管理サーバの第１の記述を修正して、特定の被管理サーバの変更された状態を示し、それによって、特定の被管理サーバの第２の記述を指定する、ステップが含まれる。ステップには、未修正の第１の記述を、第２の記述と比較し、それによって、記述変更を指定するステップが、さらに含まれる。ステップには、記述変更に基づき、特定の被管理サーバに以前送られたマネージメント命令を更新すべきかどうかを判定するステップが、さらに含まれる。ステップには、特定の被管理サーバのマネージメント命令を更新するという判定に応答して、第２の記述に基づき、ルールのセット内のどのルールが、特定の被管理サーバに現在関連するのかを判定し、それによって、現在の関連ルールを指定する、ステップと、現在の関連ルールが、以前の関連ルールと異なるかどうかを判定するステップであって、以前の関連ルールは、未修正の第１の記述に基づき判定された、ステップと、現在の関連ルールが、以前の関連ルールと同一であるという判定に応答して、それ以上何の行動も取らないステップと、がさらに含まれる。

一実施形態に係る、管理ドメインのマネージングサーバ（物理的または仮想的）のため環境を説明する、上位レベルのブロック図である。 一実施形態に係る、図１で説明される１つまたは複数のエンティティとして使用するための、コンピュータの一例を説明する上位レベルのブロック図である。 一実施形態に係る、グローバルマネージャの詳細な概念を説明する上位レベルのブロック図である。 一実施形態に係る、被管理サーバのポリシー実装モジュールの詳細な概念を説明する上位レベルのブロック図である。 一実施形態に係る、特定の被管理サーバ用のマネージメント命令を生成する方法を説明するフローチャートである。 一実施形態に係る、被管理サーバのマネージメントモジュールの構成を生成する方法を説明するフローチャートである。 一実施形態に係る、被管理サーバのローカル状態を監視し、かつ、ローカル状態情報をグローバルマネージャに送る、方法を説明するフローチャートである。 一実施形態に係る、管理ドメインのコンピュータネットワークインフラの状態に対する変更を処理する方法を説明するフローチャートである。

図面および以下の記載では、単なる説明として、特定の実施形態について記載。当業者は、本明細書において説明される構造および方法の代替えの実施形態が、本明細書に記載される原理から逸脱することなく具現化されてよいことを、以下の記載から容易に認識するであろう。ここで、いくつかの実施形態が参照され、その例が添付の図面において説明される。実用可能な限り、同様または同類の参照番号が、図面において使用されてよく、また、同様または同類の機能性を示してよい、ことに留意されたい。

図１は、一実施形態に係る、管理ドメイン１５０のマネージングサーバ（物理的または仮想的）１３０のための環境１００を説明する、上位レベルのブロック図である。管理ドメイン１５０は、例えば、サービスプロバイダ、法人、大学、または政府系機関、などの企業に相当してよい。環境１００は、企業自身により、または、企業がそのサーバ１３０を管理するのを助ける、サードパーティ（例えば、第２の企業）によって、維持されてよい。図示のように、環境１００には、ネットワーク１１０、グローバルマネージャ１２０、複数の被管理サーバ１３０、および、複数の非管理デバイス１４０、が含まれる。複数の被管理サーバ１３０および複数の非管理デバイス１４０は、管理ドメイン１５０に関連付けられる。例えば、これらは、企業、または、企業の代わりにサードパーティ（例えば、公的クラウドサービスプロバイダ）によって操作される。図１に示す実施形態では、明確にするために、１つのグローバルマネージャ１２０、２つの被管理サーバ１３０、および、２つの非管理デバイス１４０が、図示されるが、他の実施形態では、異なる数のグローバルマネージャ１２０、被管理サーバ１３０、および／または非管理デバイス１４０を、有することができる。

ネットワーク１１０は、グローバルマネージャ１２０と、被管理サーバ１３０と、非管理デバイス１４０と、の間の通信経路を表す。一実施形態において、ネットワーク１１０は、標準の通信術および／またはプロトコルを使用し、インターネットを含むことができる。別の実施形態において、ネットワーク１１０上のエンティティは、カスタムおよび／または専用のデータ通信技術を使用することができる。

被管理サーバ１３０は、管理ドメイン規模のマネージメントポリシー３３０（図３に示す）を実装する機械（物理的または仮想的）である。一実施形態において、サーバは、オペレーティングシステムのカーネルが、１つのみのインスタンスの代わりに、複数の分離されたユーザの空間インスタンスを有効にする、サーバ仮想化方法である、オペレーティングシステムレベルの仮想化に従う、仮想サーバ（コンテナ、仮想化エンジン、仮想プライベートサーバ、またはジェイルとも称されることがある）のユーザの空間インスタンスである。被管理サーバ１３０が物理的機械である場合、被管理サーバ１３０は、コンピュータまたはコンピュータのセットである。被管理サーバ１３０が仮想機械である場合、被管理サーバ１３０は、コンピュータまたはコンピュータのセット上で実行する。管理ドメイン規模のマネージメントポリシー３３０は、管理ドメイン１５０に関連付けられるエンティティが、他のエンティティにアクセスすること（もしくは、他のエンティティによってアクセスされること）を許可されるかどうか、またはサービスを消費する（もしくは提供する）かどうか、および／または、管理ドメイン１５０に関連付けられるエンティティが、どのように、他のエンティティにアクセスすること（もしくは、他のエンティティによってアクセスされること）に許可されるのか、またはサービスを消費する（もしくは提供する）のか、を指定する。例えば、管理ドメイン規模のマネージメントポリシー３３０は、セキュリティまたはリソース利用を指定する。セキュリティポリシーは、アクセス制御、セキュア接続、ディスク暗号化、および／または、実行可能プロセスの制御、を指定することができ、一方、リソース利用のポリシーは、管理ドメインのコンピューティングリソース（例えば、ディスク、周辺機器、および／または、帯域幅）の利用を規定することができる。

被管理サーバ１３０には、マネージメントモジュール１３２、マネージメントモジュール構成１３４、および、ポリシー実装モジュール１３６、が含まれる。マネージメントモジュール１３２は、管理ドメイン規模のマネージメントポリシー３３０を実装する。例えば、セキュリティの場合、マネージメントモジュール１３２は、オペレーティングシステムレベルのファイアウォール、インターネットプロトコルセキュリティ（ＩＰｓｅｃ）エンジン、またはネットワークトラフィックフィルタリングエンジン（例えば、ウィンドウズフィルタリングプラットフォーム（Ｗｉｎｄｏｗｓ Ｆｉｌｔｅｒｉｎｇ Ｐｌａｔｆｏｒｍ（ＷＦＰ））開発プラットフォームに基づく）、などの下位レベルのネットワークまたはセキュリティエンジンとすることができる。リソース利用の場合、マネージメントモジュール１３２は、ディスク利用のエンジンまたは周辺機器利用のエンジンとすることができる。

マネージメントモジュール構成１３４は、マネージメントモジュール１３２の動作に影響を与える。例えば、セキュリティの場合、マネージメントモジュール構成１３４は、ファイアウォールによって適用されるアクセス制御ルール、ＩＰｓｅｃエンジンによって適用されるセキュア接続ポリシー（例えば、Ｌｉｎｕｘオペレーティングシステムのｉｐｔａｂｌｅｓエントリーおよびｉｐｓｅｔエントリーとして、具現化される）、または、フィルタリングエンジンによって適用されるフィルタリングルール、とすることができる。リソース利用の場合、マネージメントモジュール構成１３４は、ディスク利用のエンジンによって適用されるディスク利用のポリシー、または、周辺機器利用のエンジンによって適用される周辺機器利用のポリシー、とすることができる。

ポリシー実装モジュール１３６は、ａ）グローバルマネージャ１２０から受け取るマネージメント命令、および、ｂ）被管理サーバ１３０の状態、に基づき、マネージメントモジュール構成１３４を生成する。マネージメント命令は、管理ドメイン規模のマネージメントポリシー３３０に部分的に基づき生成される。ポリシー実装モジュール１３６によって生成されるマネージメントモジュール構成１３４は、その管理ドメイン規模のマネージメントポリシー３３０を実装する（ポリシーが被管理サーバ１３０に関与する範囲で）。この２段階のプロセス（マネージメント命令を生成する、および、マネージメントモジュール構成１３４を生成する）は、マネージメントポリシーの「インスタンス化」と称される。ポリシー実装モジュール１３６はまた、被管理サーバ１３０のローカル状態を監視し、ローカル状態情報をグローバルマネージャ１２０に送る。

一実施形態において、ポリシー実装モジュール１３６は、より大きなプロプライエタリモジュール（図示せず）の一部である。プロプライエタリモジュールは、マネージメントモジュール１３２およびマネージメントモジュール構成１３４をすでに有するデバイス上にロードされ、それによって、デバイスを、非管理デバイス１４０から被管理サーバ１３０に変換させる。ポリシー実装モジュール１３６については、図４、６、および７を参照して、以下でさらに説明する。

非管理デバイス１４０は、ポリシー実装モジュール１３６を含まないコンピュータ（またはコンピュータのセット）である。非管理デバイス１４０は、管理ドメイン規模のマネージメントポリシー３３０を実装しない。しかし、被管理サーバ１３０と非管理デバイス１４０との間の相互作用が、（被管理サーバ１３０により実装されるような）管理ドメイン規模のマネージメントポリシー３３０に統轄されてよい。非管理デバイス１４０の一例は、管理ドメイン１５０によって使用されるネットワーク回路である。非管理デバイス１４０の別の例は、管理ドメイン１５０（例えば、ノートブックもしくはデスクトップコンピュータ、タブレットコンピュータ、または携帯電話）に対して自身を認証する人によって使用されるデバイスである。

グローバルマネージャ１２０は、被管理サーバ１３０用のマネージメント命令を生成して、生成したマネージメント命令をサーバに送る、コンピュータ（またはコンピュータのセット）である。マネージメント命令は、ａ）管理ドメインのコンピュータネットワークインフラの状態３２０、および、ｂ）管理ドメイン規模のマネージメントポリシー３３０、に基づいて生成される。管理ドメインのコンピュータネットワークインフラの状態３２０には、被管理サーバ１３０の記述と、（選択的に）非管理デバイス１４０の記述と、が含まれる。グローバルマネージャ１２０はまた、被管理サーバ１３０から受け取るローカル状態情報を処理する。

管理ドメイン規模のマネージメントポリシー３３０は、ＩＰアドレス、ＩＰアドレスレンジ、サブネットワーク、およびネットワークインターフェース、などの下位レベルの構成概念を使用する被管理サーバ１３０を参照しない、論理的マネージメントモデルに基づく。代わりに、論理的マネージメントモデルは、本明細書では「ラベル」と称される上位レベルの特徴に基づく被管理サーバ１３０を参照する。ラベルは、「次元」（上位レベルの特徴）と、「値」（上位レベルの特徴の値）とを含む一対である。この多次元空間内に構築されるマネージメントポリシーは、単一特徴ネットワーク／ＩＰアドレスベースのポリシーモデルに従って構築されるマネージメントポリシーよりも、表現豊かである。特に、より上位レベルの抽象化である「ラベル」を使用してマネージメントポリシーを表現することで、人々が、マネージメントポリシーをより良く理解、可視化、および修正することを可能にする。

論理的マネージメントモデル（例えば、利用可能な次元の数および型と、それらの次元の可能性のある値）は、構成可能である。一実施形態において、論理的マネージメントモデルには、表１に示すように、以下の次元と値とが含まれる。

論理的マネージメントモデルは、グループ内の被管理サーバ１３０の全てを記述する１つまたは複数のラベル（本明細書において、「ラベルセット」と称する）を指定することにより、複数の被管理サーバ１３０がまとめてグループ化されることができるようにする。ラベルセットは、論理的マネージメントモデルにおいて、１つの次元についてゼロ個の値または１個の値のどちらかを含む。ラベルセットは、論理的マネージメントモデルにおいて、全ての次元についてラベルを含む必要があるわけではない。このように、論理的マネージメントモデルは、管理ドメインの被管理サーバ１３０の区分および分類と、被管理サーバ１３０の任意のグループ分けの作成と、を可能にする。論理的マネージメントモデルはまた、単一の被管理サーバ１３０が、複数の重複するセット（すなわち、被管理サーバの複数の重複するグループ）内に存在できるようにする。論理的マネージメントモデルは、単一の被管理サーバ１３０を、ネストされたセットの階層内に存在することに限定しない。

例えば、セキュリティの場合、区分は、アクセス制御ポリシーと共に使用されて、特定のポリシーに統轄される被管理サーバ１３０のグループを定義することができる。同様に、区分は、セキュア接続ポリシーと共に使用されて、被管理サーバ１３０のグループと、グループ内通信およびグループ間通信に適用されるポリシーと、を定義することができる。従って、第１のグループの被管理サーバ１３０（第１のラベルセットにより指定される）内での通信は、第１のセキュア接続設定（例えば、要求されないセキュア接続）に制限されてよく、第１のグループの被管理サーバおよび第２のグループの被管理サーバ（第２のラベルセットにより指定される）との間の通信は、第２のセキュア接続設定（例えば、ＩＰｓｅｃ暗号ペイロード（Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ（ＥＳＰ））／認証ヘッダ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｈｅａｄｅｒ（ＡＨ）高度暗号化規格（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ（ＡＥＳ））／セキュアハッシュルゴリズム（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ−２（ＳＨＡ−２）））に制限されてよい。

環境１００内の各被管理サーバ１３０は、管理ドメイン規模のマネージメントポリシー３３０を実装する（ポリシーが被管理サーバ１３０に関与する範囲で）。その結果、管理ドメイン規模のマネージメントポリシー３３０が、管理ドメイン１５０全体に分散するように適用され、チョークポイントが無い。また、管理ドメイン規模のマネージメントポリシー３３０は、管理ドメインの物理ネットワークトポロジおよびネットワークアドレッシングスキームとは無関係の論理レベルで、適用される。

グローバルマネージャ１２０、管理ドメインのコンピュータネットワークインフラの状態３２０、および管理ドメイン規模のマネージメントポリシー３３０について、図３、５、および８を参照して、以下でさらに説明する。

図２は、一実施形態に係る、図１で説明される１つまたは複数のエンティティとして使用するための、コンピュータ２００の一例を説明する上位レベルのブロック図である。チップセット２０４に連結される少なくとも１つのプロセッサ２０２について、説明される。チップセット２０４には、メモリコントローラハブ２２０、および入力／出力（Ｉ／Ｏ）コントローラハブ２２２が含まれる。メモリ２０６およびグラフィックアダプタ２１２が、メモリコントローラハブ２２０に連結され、ディスプレイ装置２１８が、グラフィックアダプタ２１２に連結される。記憶装置２０８、キーボード２１０、ポインティングデバイス２１４、およびネットワークアダプタ２１６が、Ｉ／Ｏコントローラハブ２２２に連結される。コンピュータ２００の他の実施形態は、異なるアーキテクチャを有する。例えば、メモリ２０６は、いくつかの実施形態において、プロセッサ２０２に直接連結される。

記憶装置２０８には、ハードドライブ、ＣＤ−ＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｋ ｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ））、ＤＶＤ、またはソリッドステートメモリデバイス、などの１つまたは複数の非一時的コンピュータ可読記憶媒体が含まれる。メモリ２０６は、プロセッサ２０２により使用される命令およびデータを保持する。ポインティングデバイス２１４は、キーボード２１０と組み合わせて使用されて、データをコンピュータシステム２００に入力する。グラフィックアダプタ２１２は、画像および他の情報をディスプレイ装置２１８上に表示する。いくつかの実施形態において、ディスプレイ装置２１８には、ユーザの入力および選択を受信するためのタッチスクリーン能力が含まれる。ネットワークアダプタ２１６は、コンピュータシステム２００をネットワーク１１０に連結する。コンピュータ２００のいくつかの実施形態は、図２に示すものとは異なるおよび／または他の構成要素を有する。例えば、グローバルマネージャ１２０および／または被管理サーバ１３０は、複数のブレードサーバで形成されて、ディスプレイ装置、キーボード、および他の構成要素が無くてもよく、一方、非管理デバイス１４０は、ノートブックもしくはデスクトップコンピュータ、タブレットコンピュータ、または携帯電話、であってよい。

コンピュータ２００は、本明細書に記載される機能性を提供するためのコンピュータプログラムモジュールを実行するべく適合される。本明細書で使用されるとき、用語「モジュール」は、コンピュータプログラム命令および／または特定の機能性を提供するために使用される他の論理、を指す。従って、モジュールは、ハードウェア、ファームウェア、および／またはソフトウェアで実装されてよい。一実施形態において、実行可能コンピュータプログラム命令から形成されるプログラムモジュールは、記憶装置２０８上に記憶され、メモリ２０６にロードされ、プロセッサ２０２によって実行される。

図３は、一実施形態に係る、グローバルマネージャ１２０の詳細な概念を説明する上位レベルのブロック図である。グローバルマネージャ１２０には、リポジトリ３００、およびプロセシングサーバ３１０、が含まれる。リポジトリ３００は、管理ドメインのコンピュータネットワークインフラの状態３２０と、管理ドメイン規模のマネージメントポリシー３３０と、を記憶するコンピュータ（またはコンピュータのセット）である。一実施形態において、リポジトリ３００には、プロセシングサーバ３１０に、要求に応じて、管理ドメイン状態３２０とマネージメントポリシー３３０とへのアクセスを提供するサーバが含まれる。

管理ドメインのコンピュータネットワークインフラの状態３２０には、被管理サーバ１３０の記述と、（選択的に）非管理デバイス１４０の記述と、が含まれる。被管理サーバ１３０の記述には、例えば、一意識別子（ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（以下ＵＩＤ））、オンライン／オフラインインジケータ、１つまたは複数の構成特徴（選択的）、ネットワーク露出情報、サービス情報、および、被管理サーバ１３０を記述する１つまたは複数のラベル（ラベルセット）、が含まれる。

ＵＩＤは、被管理サーバ１３０を一意的に識別する。オンライン／オフラインインジケータは、被管理サーバ１３０がオンラインかオフラインか、を示す。「構成特徴」は、被管理サーバ１３０に関連する値を記憶し、任意のタイプの情報（例えば、どのオペレーティングシステムが被管理サーバ上で実行中であるのかの指標であってよい）。構成特徴は、ルールの条件部分（以下で説明する）と組み合わせて使用される。

ネットワーク露出情報は、被管理サーバのネットワークインターフェースに関与する。一実施形態において、ネットワーク露出情報には、被管理サーバのネットワークインターフェースのそれぞれについて、ネットワークインターフェースがアタッチされる「双方向到達可能ネットワーク（ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｒｅａｃｈａｂｌｅｎｅｔｗｏｒｋ（以下ＢＲＮ））」の識別子、および、ＢＲＮ内での動作に使用されるゼロ個以上のＩＰアドレス（およびそのサブネット）、が含まれる。別の実施形態において、ネットワーク露出情報には、ルーティング情報、および／または、被管理サーバが、ネットワークアドレス変換器（ｎｅｔｗｏｒｋ ａｄｄｒｅｓｓ ｔｒａｓｎｌａｔｏｒ（以下ＮＡＴ））の後方にあるかどうか（および、ＮＡＴの後方にある場合は、どのタイプのＮＡＴ、すなわち、１：１または１：Ｎ、であるのか）、が含まれる。ＢＲＮは、組織内の、または組織を超えた、サブネットのセットであり、ＢＲＮ内のいずれのノードも、ＢＲＮ内の任意の他のノードとの通信を確立することができる。例えば、ＢＲＮ内のノードの全てが、一意ＩＰアドレスを有する。換言すると、ＢＲＮは、ＮＡＴを何も含まない。ネットワーク露出情報（例えば、ネットワークインターフェースのＢＲＮ識別子）は、ルールの条件部分と併せて使用されてよい。

サービス情報には、例えば、プロセス情報および／またはパッケージ情報、が含まれる。プロセス情報には、例えば、被管理サーバ１３０が実行中のプロセスの名称、どのネットワークポートおよびネットワークインターフェース上で、それらのプロセスがリスンしているのか、どのユーザがそれらのプロセスを起動したのか、それらのプロセスの構成、および、それらプロセスのコマンドラインｌａｕｎｃｈ引数、が含まれる。（それらのプロセスは、被管理サーバ１３０がサービスを提供すること、または、サービスを利用すること、に相当する）パッケージ情報には、例えば、どのパッケージ（実行ファイル、ライブラリ、または他の構成要素）が被管理サーバ１３０にインストールされるのか、それらのパッケージのバージョン、それらのパッケージの構成、および、それらのパッケージのハッシュ値、が含まれる。

非管理デバイス１４０の記述には、例えば、ネットワーク露出情報（例えば、非管理デバイスのＩＰアドレス、および、非管理デバイスが接続されるＢＲＮの識別子）が含まれる。非管理デバイス１４０は、「非管理デバイスグループ」（ｕｎｍａｎａｇｅｄ ｄｅｖｉｃｅ ｇｒｏｕｐ（以下ＵＤＧ））の一部である。ＵＤＧには、１つまたは複数の非管理デバイス１４０が含まれる。例えば、「本部ＵＤＧ」には、管理ドメインの本部によって使用される一次回路およびバックアップ回路が含まれてよく、各回路はＩＰアドレスに関連付けられる。ＵＤＧは、一意識別子（ｕｎｉｑｕｅ ｉｄｅｎｔｉｆｉｅｒ（以下ＵＩＤ））に関連付けられる。ＵＤＧに関する管理ドメイン状態３２０内に記憶される情報には、ＵＤＧのＵＩＤ、および、ＵＤＧ内の非管理デバイス１４０に関する情報（例えば、非管理デバイスのネットワーク露出情報）、が含まれる。

被管理サーバ１３０および非管理デバイス１４０の記述は、種々の方法で、例えば、グラフィカルユーザインターフェース（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ（以下ＧＵＩ））またはアプリケーションプログラミングインターフェース（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍｍｉｎｇ ｉｎｔｅｒｆａｃｅ（以下ＡＰＩ））を介して、グローバルマネージャ１２０と相互作用することにより、管理ドメイン状態３２０にロードされてよい。被管理サーバ１３０の記述はまた、被管理サーバから受け取るローカルステータス情報（以下で説明する）に基づき、管理ドメイン状態３２０にロードされてよい。

特に被管理サーバのラベルに関して（および、ある場合は、構成特徴）、次元についての値の割り当て（または再割り当て）（または、構成特徴の値の設定）が、さらに多くの方法で実行されてよい。例えば、割り当て／設定は、被管理サーバ１３０をプロビジョニングすることの一部として、展開および構成のツールを使用して実行されてよい。任意のそのようなツールが使用可能であり、既成のサードパーティのツール（例えば、Ｐｕｐｐｅｔ Ｌａｂｓ社のＰｕｐｐｅｔというソフトウェア、Ｏｐｓｃｏｄｅ社のＣｈｅｆというソフトウェア、または、ＣＦＥｎｇｉｎｅ ＡＳ社のＣＦ Ｅｎｇｉｎｅというソフトウェア）、および、管理ドメイン１５０が有してよいカスタムツール、が含まれる。

別の例として、割り当て／設定は、ラベルおよび／または構成特徴（「ＣＣ」）値を計算する「ラベル／構成特徴エンジン」（図示せず）によって実行されてよい。一実施形態において、ラベル／ＣＣエンジンが、ラベル／ＣＣ割り当てルールに基づき、ラベル／ＣＣ値を計算する。ラベル／ＣＣ割り当てルールは、管理ドメイン状態３２０からのデータにアクセスし、ラベルまたはＣＣ値を割り当てる（または、割り当てを示唆する）、機能である。ラベル／ＣＣ割り当てルールは、プリセットまたはユーザ構成可能であってよい。例えば、グローバルマネージャ１２０には、あらかじめ定義されたルールのセットが含まれるが、エンドユーザは、それらのルールを修正および／または削除すること、および、ユーザ自身のカスタム要件に基づき、新しいルールを追加すること、ができる。ラベル／ＣＣ割り当てルールは、初期化プロセス中に、被管理サーバ１３０について評価されてよい。そして、ラベル／ＣＣ値の示唆は、任意の次元／ＣＣについてなされてよく、エンドユーザは、それらの示唆を受け入れても拒否してもよい。例えば、被管理サーバ１３０が、ＰｏｓｔｇｒｅｓデータベースまたはＭｙＳＱＬデータベースを実行中である場合、示唆されたラベルは、＜役割、データベース＞であってよい。被管理サーバが、Ｌｉｎｕｘオペレーティングシステムを実行中である場合、オペレーティングシステムについて示唆された値ＣＣは、「Ｌｉｎｕｘ」であってよい。

別の実施形態において、ラベル／ＣＣエンジンは、クラスタ分析に基づき、ラベル／ＣＣ値を計算する。例えば、ラベル／ＣＣエンジンは、追加の発見的問題解決法と共に、連結したグラフの、ｍｉｎ−ｃｕｔアルゴリズムおよびＫ−ｍｅａｎｓアルゴリズムの組み合わせを使用して、上位に接続された被管理サーバ１３０のクラスタを自動的に識別する。被管理サーバ１３０のクラスタは、管理ドメイン１５０における「アプリケーション」（表１を参照）に相当し得る。エンドユーザは、アプリケーションの次元（または、任意の他の次元）について値を、それらの被管理サーバ１３０に、一斉に適用することを選択することができる。

管理ドメイン規模のマネージメントポリシー３３０には、１つまたは複数のルールが含まれる。大まかに言うと、「ルール」は、サービスの１つまたは複数のプロバイダと、そのサービスの１つまたは複数の消費者との間のリレーションシップを指定する。

ルール機能−リレーションシップは、ルールの実際の影響である、「ルール機能」に統轄される。例えば、セキュリティの場合、ルール機能は、アクセス制御、セキュア接続、ディスク暗号化、または、実行可能処理の制御、となり得る。アクセス制御機能でのルールは、消費者が、プロバイダのサービスを使用できるかどうかを指定する。一実施形態において、アクセス制御機能は、純粋な「ホワイトリスト」モデルを使用し、これは、許容可能なリレーションシップのみが表現され、全ての他のリレーションシップが、デフォルトでブロックされる、ということを意味する。セキュア接続機能でのルールは、どのセキュアなチャンネル上（例えば、２地点間データ暗号化を使用する、暗号化されたネットワークセッション）で、消費者がプロバイダのサービスを使用することができるのかを指定する。例えば、セキュア接続機能でのルールは、プロバイダが米国に置かれ、消費者がＥＵに置かれているときは、プロバイダのサービスの利用が暗号化されなれけばならない、ということを指定することができる。ディスク暗号化機能でのルールは、プロバイダが、そのデータを暗号化ファイルシステム上に記憶しなればならないかどうか、を指定する。実行可能処理の制御機能でのルールは、プロバイダが、暗号化ファイルシステム上で実行しなければならないかどうかを指定する。

リソース利用の場合、ルール機能は、ディスク利用または周辺機器利用、であってよい。ディスク利用機能でのルールは、消費者がプロバイダ上に記憶可能なデータの量を指定する。ここで、ルールは、単なるアクセス制御、セキュア接続、ディスク暗号化、実行可能処理の制御、ディスク利用、および周辺機器利用を超えて、同様に他のルール機能を指定することが可能である。例えば、ルール機能は、どの開放型システム間相互接続（ＯＳＩ）モデルの第７層のサービスを、ネットワークトラフィック、セキュリティ分析のための収集すべきメタデータの量、または、完全なネットワークパケットを獲得するためのトリガー、に適用するのかを指定する。マネージメントポリシーモデルは、適用可能な任意の数のルール機能をサポートする。

ルール機能は、ルールの実際の影響に関する詳細を指定する、１つまたは複数の設定（本明細書においては「機能プロファイル」と称する）に関連付けられてよい。例えば、セキュア接続のルール機能に関連する設定は、ネットワークトラフィックを暗号化に使用される暗号アルゴリズムのリストであってよい。一実施形態において、ルール機能は、複数の機能プロファイルに関連付けられ、機能プロファイルには優先度が含まれる。この優先度は、以下で説明するように、機能レベル命令生成モジュール３６０によって使用される。

サービス−一般に、「サービス」は、指定のネットワークポート上で、指定のネットワークプロトコルを使用して、実行される任意のプロセスである。マネージメントポリシー３３０内のルールのサービスは、ポート／プロトコルの対と、プロセス情報および／またはパッケージ情報（管理ドメイン状態３２０内の被管理サーバ１３０の記述について、上記で説明した）などの、（選択的）追加の適正、によって指定される。被管理サーバ１３０が、複数のネットワークインターフェースを有する場合、サービスを、全てのネットワーク上、または、それらのネットワークのサブセット上のみに、露出させることができる。エンドユーザは、どのネットワーク上に、サービスを露出させるかを指定する。

プロバイダ／消費者−サービスの１つまたは複数のプロバイダ、および、サービスの１つまたは複数の消費者（すなわち、ユーザ）は、被管理サーバ１３０および／または非管理デバイス１４０である。

一実施形態において、ルールは、ルール機能部分、サービス部分、提供元部分、使用元部分、および選択的ルール条件部分、を含む情報のセットを使用して、管理ドメイン規模のマネージメントポリシー３３０内に、表される。ルール機能部分は、ルールの実際の影響を記述し、１つまたは複数の設定（機能プロファイル）に関連付けられてよい。サービス部分は、ルールが適用されるサービスを記述する。サービス部分が「Ａｌｌ（全て）」を示す場合、ルールは全てのサービスに適用される。

提供元（ｐｒｏｖｉｄｅｄ−ｂｙ（以下ＰＢ））部分は、どの被管理サーバ１３０および／または非管理デバイス１４０が、サービスを提供可能であるか（すなわち、誰が「プロバイダ」か）、を記述する。ＰＢ部分が「Ａｎｙｂｏｄｙ（誰でも）」を示す場合、誰でも（例えば、任意の被管理サーバ１３０または非管理デバイス１４０）が、サービスを提供することが可能である。ＰＢ部分が「Ａｎｙ ｍａｎａｇｅｄ ｓｅｒｖｅｒ（どの被管理サーバでも）」を示す場合、どの被管理サーバ１３０も、サービスを提供することが可能である。（「Ａｎｙ ｍａｎａｇｅｄ ｓｅｒｖｅｒ（どの被管理サーバでも）」は、ワイルドカードを含むラベルセットを指定することと等価であり、それによって、全ての被管理サーバ１３０をマッチングする）。使用元（ｕｓｅｄ−ｂｙ（以下ＵＢ））部分は、どの被管理サーバ１３０および／または非管理デバイス１４０が、サービスを使用可能であるか（すなわち、誰が「消費者」であるのか）を記述する。ＰＢ部分と同様に、ＵＢ部分は、「Ａｎｙｂｏｄｙ」または「Ａｎｙ ｍａｎａｇｅｄ ｓｅｒｖｅｒ（どの被管理サーバでも」を示すこともできる。

ＰＢ部分およびＵＢ部分内には、被管理サーバ１３０が、ラベルセット（すなわち、被管理サーバを記述する１つまたは複数のラベル）またはＵＩＤを使用することにより、指定される。ラベルセットを使用して被管理サーバ１３０を指定する能力は、論理的マネージメントモデルに由来するもので、被管理サーバを、その次元および値（ラベル）に基づき参照する。非管理デバイス１４０は、非管理デバイスグループ（ＵＤＧ）のＵＩＤを使用することにより指定される。ルールがＵＤＧを指定する場合、ルールには、そのグループ内の非管理デバイス１４０に関する追加情報（例えば、デバイスのネットワーク露出情報）が含まれる。ルールのＰＢ部分および／またはルールのＵＢ部分には、ラベルセット（被管理サーバ１３０を指定するための）、被管理サーバのＵＩＤ、および／またはＵＤＧのＵＩＤ、を含む複数の項目が含まれてよい。

ルール条件部分は、選択的なものであり、ルールが、特定の被管理サーバ１３０、および／または、その被管理サーバの特定のネットワークインターフェース、に適用されるかどうかを指定する。ルール条件部分は、１つまたは複数の構成特徴（「ＣＣ」、管理ドメイン状態３２０内の被管理サーバの記述の一部である）、および／または、ネットワーク露出情報（例えば、ネットワークインターフェースのＢＲ識別子、これも管理ドメイン状態３２０内の被管理サーバの記述の一部）、を含む、ブール式である。式のＣＣ部分は、ルールが、特定の被管理サーバに適用されるかどうかを指定し、一方、式のネットワーク露出情報部分は、ルールが、その被管理サーバの特定のネットワークインターフェースに適用されるかどうかを指定する。式が、特定の被管理サーバの構成特徴について（詳細には、その被管理サーバの構成特徴の値について）、および、特定のネットワークインターフェースの情報について、「真」となる場合、ルールは、その被管理サーバ、および、その被管理サーバの関連ネットワークインターフェース、に適用される。式が「偽」となるを評価する場合、ルールは、その被管理サーバ、および、その被管理サーバの関連ネットワークインターフェース、には適用されない。例えば、構成特徴が、どのオペレーティングシステムが被管理サーバ上で実行中であるかの指標を記憶する場合、その構成特徴を含むルール条件部分は、ルールが特定の被管理サーバに適用されるかどうかを、そのサーバのオペレーティングシステムに基づき、制御することができる。

管理ドメイン規模のマネージメントポリシー３３０内のルールは、ルールリストとして編成される。詳細には、マネージメントポリシー３３０には、１つまたは複数のルールリストが含まれ、ルールリストには、１つまたは複数のルールと、（選択的に）１つまたは複数のスコープと、が含まれる。「スコープ」は、どこに（すなわち、どの被管理サーバ１３０に）ルールが適用されるのか、を制約する。スコープには、ルールリスト内のルールの適用を制限する、提供元（ＰＢ）部分および使用元（ＵＢ）部分が含まれる。スコープのＰＢ部分は、ルールのＰＢ部分を制限し、スコープのＵＢ部分は、ルールのＵＢ部分を制限する。スコープのＰＢ部分およびＵＢ部分は、被管理サーバ１３０のグループを、ラベルセットを使用することにより指定する。ラベルセットが、指定の次元のラベルを含まない場合、結果として得られる被管理サーバ１３０のグループについて、その次元のスコーピングが無い。ルールリストが、何のスコープも含まない場合、そのルールはグローバルに適用される。

異なるスコープが、単一のルールリストに適用されてよい。例えば、エンドユーザは、どのように、ウェブサービスティアが、データベースティアからサービスを消費するのか、どのように、ロードバランシングティアが、ウェブサービスティアからサービスを消費するのか、などを表現するルールのセットを構築することができる。そして、エンドユーザが、このルールリストを自分のプロダクション環境および自分のステージング環境に適用したい場合、エンドユーザは、ルールリストをコピーも複製もする必要が無い。代わりに、エンドユーザは、複数のスコープを単一のルールリストに適用する。スコープの抽象化により、有用性の観点および計算の観点の両方から、ルールリストが拡大縮小される。

ここで、管理ドメイン規模のマネージメントポリシー３３０が、記述されてあることは、いくつかの例に対処することに役立つ。ユーザデバイスがウェブサーバ（第１のティア）にアクセスし、ウェブサーバがデータベースサーバ（第２のティア）にアクセスする、２ティアアプリケーションを用いる管理ドメイン１５０について検討する。第１のティアにおいて、ユーザデバイスは消費者であり、ウェブサーバはプロバイダである。第２のティアにおいて、ウェブサーバは消費者であり、データベースサーバはプロバイダである。管理ドメイン１５０には、このアプリケーションの２つのインスタンスが含まれ、１つはプロダクション環境内、１つはステージング環境内、にある。

ウェブサーバおよびデータベースサーバは、被管理サーバ１３０であり、それらの記述（例えば、ラベルセット）は、管理ドメイン状態３２０内に存在する。例えば、それらのラベルセットは、
プロダクションにおけるウェブサーバ：＜役割，ウェブ＞および＜環境，プロダクション＞
プロダクションにおけるデータベースサーバ：＜役割，データベース＞および＜環境，プロダクション＞
ステージングにおけるウェブサーバ：＜役割，ウェブ＞および＜環境，ステージング＞
ステージングにおけるデータベースサーバ：＜役割，データベース＞および＜環境，ステージング＞
（アプリケーション次元、業種次元、およびロケーション次元は、この例に関連しないため、それらのラベルは省略する。）

ここで、アクセス制御およびセキュア接続を指定するセキュリティポリシーである、以下の管理ドメイン規模のマネージメントポリシー３３０について検討する。
ルールリスト＃１
・スコープ
ｏ＜環境，プロダクション＞
ｏ＜環境，ステージング＞
・ルール
ｏ＃１
□機能：アクセス制御
□サービス：アパッチ
□ＰＢ：＜役割，ウェブ＞
□ＵＢ：Ａｎｙｂｏｄｙ
ｏ＃２
□機能：アクセス制御
□サービス：ＰｏｓｔｇｒｅＳＱＬ
□ＰＢ：＜役割，データベース＞
□ＵＢ：＜役割，ウェブ＞
ルールリスト＃２
・スコープ：無
・ルール
ｏ＃１
□機能：セキュア接続
□サービス：Ａｌｌ
□ＰＢ：＜役割，データベース＞
□ＵＢ：Ａｎｙ ｍａｎａｇｅｄ ｓｅｒｖｅｒ（どの被管理サーバでも）

なお、上記のルールは、明確にするために、単に「アパッチ」および「ＰｏｓｔｇｒｅＳＱＬ」として、サービスを参照する。サービスが、プロセスであり、ポート／プロトコルの対と、プロセス情報および／またはパッケージ情報（管理ドメイン状態３２０内の被管理サーバ１３０の記述について、上記で説明した）などの、（選択的）追加の適正、によって指定されるということを、思い出されたい。

ルールリスト＃１／ルール＃１では、任意のデバイス（例えば、ユーザデバイス）が、ウェブサーバに接続して、アパッチサービスを使用することが許可される。詳細には、接続の許可が、機能部分の「アクセス制御」によって指定される。「任意のデバイス」が、ＵＢ部分の「Ａｎｙｂｏｄｙ」によって指定される。「ウェブサーバ」が、ＰＢ部分の「＜役割，ウェブ＞」（１つのラベルのみを含むラベルセット）によって指定される。アパッチサービスが、サービス部分の「アパッチ」によって指定される。

ルールリスト＃１／ルール＃２では、ウェブサーバが、データベースサーバ上のＰｏｓｔｇｒｅＳＱＬに接続することが許可される。詳細には、接続の許可が、機能部分の「アクセス制御」によって指定される。「ウェブサーバ」が、ＵＢ部分の「＜役割，ウェブ＞」によって指定される。「ＰｏｓｔｇｒｅＳＱＬ」が、サービス部分の「ＰｏｓｔｇｒｅＳＱＬ」によって指定される。「データベースサーバ」が、ＰＢ部分の「＜役割，データベース＞」（１つのラベルのみを含むラベルセット）によって指定される。

ルールリスト＃１ではまた、環境間の接続を防ぐ。例えば、ウェブサーバとデータベースサーバとの両方が、同じ環境内にある場合（例えば、両方ともプロダクション環境内にある、または、両方ともステージング環境内にある）、ウェブサーバは、データベースサーバ上のＰｏｓｔｇｒｅＳＱＬに接続することが許可される。プロダクション環境内の両サーバは、スコープ部分の＜環境，プロダクション＞」（１つのラベルのみを含むラベルセット）によって指定され、一方、ステージング環境内の両サーバは、スコープ部分の「＜環境，ステージング＞」（１つのラベルのみを含むラベルセット）によって指定される。その結果、サーバが、異なる環境内にある場合（例えば、ウェブサーバがステージング環境内にあり、データベースサーバがプロダクション環境内にある場合）は、ウェブサーバは、データベースサーバ上のＰｏｓｔｇｒｅＳＱＬにアクセスすることが許可されない。

ルールリスト＃２は、任意の被管理サーバが、データベースサーバに接続するときはいつでも、その接続が暗号化されたチャンネルを介して実行されなければならない、ということを提示する。詳細には、「データベースサーバ」が、ＰＢ部分の」＜役割，データベース＞」によって指定される。「暗号化されたチャンネル」が、機能部分の「セキュア接続」によって指定される。「任意の被管理サーバ」が、ＵＢ部分の「Ａｎｙ ｍａｎａｇｅｄ ｓｅｒｖｅｒ（どの被管理サーバでも）」によって指定される。「いつでも」が、サービス部分の「Ａｌｌ」によって指定される。

上記の例から離れて、以下の２つの被管理サーバ１３０について検討する。サーバ１は、プロダクションの一部であり、ａｐｐ１の一部であり、カリフォルニアのエンジニアリングが所有する、ウェブサーバである。以下のようにラベル付けされる。
＜役割，ウェブ＞
＜環境，プロダクション＞
＜アプリケーション，ａｐｐ１＞
＜業種，エンジニアリング＞
＜ロケーション，ＵＳ＞
サーバ２は、プロダクションの一部であり、ａｐｐ１の一部でもあり、ドイツのエンジニアリングが所有する、データベースサーバである。以下のようにラベル付けされる。
＜役割，データベースサーバ＞
＜環境，プロダクション＞
＜アプリケーション，ａｐｐ１＞
＜業種，エンジニアリング＞
＜ロケーション，ＥＵ＞

アクセス制御ルールが、ａｐｐ１の一部である全ての被管理サーバ１３０への全てのアクセスを許可する、と仮定する。このルールでは、サーバ１とサーバ２とが、お互いに通信することが許可され、ａｐｐ２の一部であるドイツの被管理サーバ１３０が、サーバ１またはサーバ２と通信することが許可されない。ここで、セキュア接続ルールが、ＥＵとＵＳとの間の全てのネットワークトラフィックは、暗号化されなければならない、ことを指定する、と仮定する。ルール機能は、単独で適用される。換言すると、セキュア接続ルールは、アクセス制御ルールとは無関係に適用される別個のポリシーである。その結果、サーバ１からサーバ２へのネットワークトラフィックが、許可されて（アクセス制御ルールが与えられて）、暗号化される（セキュア接続ルールが与えられる）。

図３に戻って、プロセシングサーバ３１０は、被管理サーバ１３０用のマネージメント命令を生成して、生成したマネージメント命令をサーバに送る。プロセシングサーバ３１０はまた、被管理サーバ１３０から受け取るローカル状態情報を処理する。プロセシングサーバ３１０には、ポリシーエンジンモジュール３４０、関連ルールモジュール３５０、機能レベル命令生成モジュール３６０、アクターエニュメレーションモジュール３７０、関連アクターモジュール３８０、および、管理ドメイン状態更新モジュール３８５、などの種々のモジュールが含まれる。一実施形態において、プロセシングサーバ３１０には、リポジトリ３００と通信して、データを（例えば、ポリシーエンジンモジュール３４０、関連ルールモジュール３５０、機能レベル命令生成モジュール３６０、アクターエニュメレーションモジュール３７０、関連アクターモジュール３８０、および管理ドメイン状態更新モジュール３８５、を実行することにより）処理するコンピュータ（またはコンピュータのセット）が含まれる。

関連ルールモジュール３５０は、管理ドメイン規模のマネージメントポリシー３３０と、特定の被管理サーバ１３０の指標（例えば、そのサーバのＵＩＤ）と、を入力として取り込み、そのサーバに関連するルールのセットを生成し、ルールのセットを出力する。これは、関連ルールモジュール３５０が、マネージメントポリシー３３０を検査して、所与の被管理サーバ１３０用の関連ルールのみを抽出することによる、フィルタリングプロセスである。関連ルールモジュール３５０は、フィルタリングの実行を、マネージメントポリシー３３０内のルールリストの全てを反復すること、各ルールリストのスコープを分析して、スコープがこの被管理サーバ１３０に適用されるかどうかを判定すること、および（スコープがこの被管理サーバ１３０に適用される場合）各ルールリストのルールを分析して、それらのルールがこの被管理サーバ１３０に適用されるかどうかを判定すること、によって行う。ルールが被管理サーバ１３０に適用されるのは、ａ）ルールのＰＢ部分および／またはルールのＵＢ部分が、被管理サーバを指定する場合、および、ｂ）ルールの条件部分（存在する場合）が、その被管理サーバについて（詳細には、被管理サーバの構成特徴の値およびネットワーク露出情報について）、「真」となる場合、である。最終結果（本明細書において、マネージメントポリシー観点」と称する）は、２セットのルールのコレクションであり、１つは、この被管理サーバ１３０がサービスを提供するルール、１つは、この被管理サーバ１３０がサービスを消費するルール、である。

機能レベル命令生成モジュール３６０は、ルールのセット（例えば、関連ルールモジュール３５０により生成されるマネージメントポリシー観点）を入力として取り込み、機能レベルの命令を生成し、機能レベルの命令を出力する。機能レベルの命令は、後で、マネージメント命令の一部として被管理サーバ１３０に送られる。機能レベルの命令は、それぞれが、ルール機能部分、サービス部分、ＰＢ部分、およびＵＢ部分を含む、という点で、ルールに類似する。しかし、ルールが、そのＰＢ部分および／またはＵＢ部分内に複数の項目（ラベルセット、被管理サーバＵＩＤ、および／または、ＵＤＧのＵＩＤを含む）を含むことができる一方、機能レベルの命令は、そのＰＢ部分内に１項目のみ、およびそのＵＢ部分に１項目のみ、しか含まない。また、ルールが、そのＰＢ部分および／またはＵＢ部分内に、被管理サーバ（その複数のネットワークインターフェースを含む）を指定することができる一方、機能レベルの命令は、そのＰＢ部分およびＵＢ部分内に、１つのネットワークインターフェースのみしか含まない。

機能レベル命令生成モジュール３６０は、ルールを分析し、そのルールに基づき１つまたは複数の機能レベルの命令を生成する。ルールのＰＢ部分が、複数の項目を含む場合、ルールのＵＢ部分が、複数の項目を含む場合、または、ルール（ＰＢ部分またはＵＢ部分）により参照される被管理サーバが、複数のネットワークインターフェースを有する場合、機能レベル命令生成モジュール３６０は、複数の機能レベルの命令を生成する（例えば、ＰＢ項目、ＵＢ項目、および特定のネットワークインターフェースの、可能な組み合わせごとに１つの機能レベルの命令）。

ＰＢ部分に２つの項目（ＡおよびＢ）、ならびに、ＵＢ部分に２つの項目（ＣならびにＤ）を含むルールについて検討する。機能レベル命令生成モジュール３６０は、以下のＰＢ部分およびＵＢ部分を用いて４つの機能レベルの命令を生成する。１）ＰＢ＝Ａ、ＵＢ＝Ｃ；２）ＰＢ＝Ａ、ＵＢ＝Ｄ；３）ＰＢ＝Ｂ、ＵＢ＝Ｃ；４）ＰＢ＝Ｂ、ＵＢ＝Ｄ。ここで、ＰＢ部分またはＵＢ部分で被管理サーバをカバーするルール（例えば、ＵＩＤまたはラベルセットを指定することにより）であって、その被管理サーバが複数のネットワークインターフェースを有する場合を検討する。機能レベル命令生成モジュール３６０は、複数の機能レベルの命令を生成する（例えば、被管理サーバのネットワークインターフェースごとに１つの機能レベルの命令）。

機能レベル命令生成モジュール３６０は、ルール、それらのルール内の機能、および、それらのルールにより参照される機能プロファイル、を分析する。ルールリストに、複数のスコープが含まれる場合、機能レベル命令生成モジュール３６０は、それらのスコープをルールリストに、複数回繰り返し適用する（それによって、スコープごとに機能レベルの命令の完全なセットを生成する）。ルール機能が、複数の機能プロファイルに関連付けられてよいこと、および、機能プロファイルが優先度を含むことができること、を思い出されたい。機能レベル命令生成モジュール３６０は、種々の機能プロファイルの優先度に基づきルールを順序付けて、最高優先度の機能プロファイルが使用されるようにする。機能レベル命令生成モジュール３６０は、順序付けされたルールを、被管理サーバ１３０が実行できるように、機能レベルの命令に変換する。機能レベルの命令は、適切な被管理サーバ１３０および／または非管理デバイス１４０（例えば、入力されたルールにおいて参照された被管理サーバ１３０および／または非管理デバイス１４０）を参照し、ルールに関連するサービスのネットワーク露出の詳細を考慮に入れる。

ここで、機能レベル命令生成モジュール３６０は、特定の被管理サーバ１３０用の機能レベルの命令を生成することができるが、該命令は、そのサーバには無意味なものとなる。例えば、その被管理サーバが、ルールの提供元（ＰＢ）部分によりカバーされ、そのため、機能レベル命令生成モジュール３６０が対応する機能レベルの命令を生成する。しかし、ルールには、被管理サーバのローカル状態を指定する部分も含まれる（例えば、提供されるサービスを記述するサービス部分）。グローバルマネージャ１２０には、被管理サーバのローカル状態（例えば、被管理サーバが実際にそのサービスを提供中であるかどうか）が分からないため、生成された機能レベルの命令が被管理サーバに送られる。被管理サーバは、そのローカル状態をチェックし（例えば、そのサービスを提供中であるかどうか）、それに従って、以下で説明するように、ポリシーコンパイルモジュール４１０を参照して、機能レベルの命令を処理する。

アクターエニュメレーションモジュール３７０は、被管理サーバ１３０および非管理デバイスグループ（ＵＤＧ）の記述（例えば、管理ドメインのコンピュータネットワークインフラの状態３２０）のコレクションを、入力として取り込み、サーバおよびＵＤＧのそれらの記述の表現を、エニュメレート（列挙）された形式（「アクターセット」と称する）で生成し、アクターセットを出力する。例えば、アクターエニュメレーションモジュール３７０は、被管理サーバ１３０およびＵＤＧを、管理ドメイン状態３２０および可能性のあるラベルセット内にエニュメレートし、それぞれに一意識別子（ＵＩＤ）を割り当てる。これらのアクターセットは、次に、ルールおよびスコープのＵＢ部分およびＰＢ部分と併せて使用されてよく、これにより、被管理サーバのＵＩＤ、ＵＤＧのＵＩＤ、および／または、ラベルセットを使用して、アクターを指定する。

Ｎ個の次元Ｄ_i（ｉ＝１，．．．，Ｎ）の集合を含み、各次元Ｄ_iが、可能性ある値Ｖ_j（ｊ＝１，．．．，Μ_i）の集合Ｓ_iを含む（ここで、ワイルドカード「＊」は可能性のある値のうちの１つである）、論理的マネージメントモデルについて検討する。一実施形態において、アクターエニュメレーションモジュール３７０は、論理的マネージメントモデルに基づき可能性のある全てのラベルセットをエニュメレートし、これは、Ｓ_i×Ｓ₂×．．．×Ｓ_Nで得られるデカルト積に等しい。この集合のサイズはＭ₁×Ｍ₂×．．．×Ｍ_Nである。エニュメレーションプロセスでは、被管理サーバ１３０の多次元ラベル空間を、単純なエニュメレートされた形式に縮約する。

別の実施形態において、アクターエニュメレーションモジュール３７０は、管理ドメイン状態３２０に基づき（例えば、管理ドメイン１５０内の被管理サーバの記述に基づき）可能性のあるラベルセットだけをエニュメレートする。例えば、２つの次元（ＸおよびＹ）を含み、各次元が３つの可能性のある値（Ａ、Ｂ、および＊）を含む、論理的マネージメントモデルについて検討する。ラベルセット「＜Ｘ＝Ａ＞，＜Ｙ＝Ｂ＞」を持つ被管理サーバは、以下の４つの可能性のあるラベルセットのうちのメンバーであり得る。１）「＜Ｘ＝Ａ＞＜Ｙ＝Ｂ＞」、２）「＜Ｘ＝Ａ＞＜Ｙ＝＊＞」、３）「＜Ｘ＝＊＞＜Ｙ＝Ｂ＞」、および、４）「＜Ｘ＝＊＞＜Ｙ＝＊＞」。ここで、被管理サーバのラベルセットは、二次元空間（ＸおよびＹ）に存在し、一方、可能性のあるラベルセット２、３、および４は、被管理サーバのラベルセットの、サブ次元空間への投影である（ラベルセット２は一次元空間（Ｘ）、ラベルセット３は一次元空間（Ｙ）、ラベルセット４は０次元空間）。それ故、アクターエニュメレーションモジュール３７０は、それら４つの可能性のあるラベルセットをエニュメレートする。ラベルセット「＜Ｘ＝Ａ＞，＜Ｙ＝Ｂ＞」を持つ被管理サーバが、ラベルセット「＜Ｘ＝Ａ＞，＜Ｙ＝Ａ＞」のメンバーであることはなく、そのため、アクターエニュメレーションモジュール３７０は、そのラベルセットをエニュメレートしない。

アクターセットには、ＵＩＤおよび、ゼロ個またはそれ以上のアクターセットレコードが、含まれる。アクターセットレコードには、ＵＩＤ（被管理サーバのＵＩＤまたはＵＤＧのＵＩＤのいずれか）、アクターのオペレーティングシステムの識別子、および、指定のＢＲＮが与えられたアクター（被管理サーバ１３０または非管理デバイス１４０）のＩＰアドレス、が含まれる。例えば、アクターセットには、＜役割，データベース＞および＜環境，プロダクション＞のラベルセットによりカバーされる被管理サーバ１３０の全てに対応するＩＰアドレスを持つ、アクターセットレコードが含まれてよい。別の例として、アクターセットには、本部ＵＤＧにおける非管理デバイス１４０の全てに対応するＩＰアドレスを持つ、アクターセットレコードが含まれてよい。単一のアクター（例えば、被管理サーバ１３０または非管理デバイス１４０）が、複数のアクターセット内に見られてよい。

アクターセット計算における別の要因は、複数のネットワークインターフェースを持つアクターと、ネットワークアドレス変換器（ＮＡＴ）などのネットワークトポロジを含むこと、である。従って、＜役割，データベース＞および＜環境，プロダクション＞のラベルセットついて２つのアクターセットがあり得、１つのアクターセットが、それら被管理サーバ１３０のインターネットに接続するＩＰアドレス（すなわち、第１のＢＲＮに関連する）を持ち、それら同じ被管理サーバ用の異なるアクターセットが、それら被管理サーバのプライベートネットワークに接続するＩＰアドレス（すなわち、第２のＢＲＮに関連する）を持つ。

一実施形態において、アクターエニュメレーションモジュール３７０は、管理ドメインの状態３２０に対する変更に基づき、アクターセットを更新することもできる。例えば、アクターエニュメレーションモジュール３７０は、アクターセット（以前、アクターエニュメレーションモジュールによって出力された）、および、被管理サーバの記述（管理ドメイン状態３２０内の）に対する変更、を入力として取り込み、更新されたアクターセット（変更されたサーバ記述と一致する）を生成し、更新されたアクターセットを出力する。アクターエニュメレーションモジュール３７０は、被管理サーバの記述に対する変更のタイプに応じた異なる方法で、更新されたアクターセットを生成する。

オフライン／オンラインの変更−記述変更が、サーバがオンラインからオフラインになったことを示す場合、アクターエニュメレーションモジュール３７０は、サーバのアクターセットレコードを、サーバがメンバーだった全ての入力アクターセットから削除することにより、更新されたアクターセットを生成する。記述変更が、サーバがオフラインからオンラインになったことを示す場合、アクターエニュメレーションモジュール３７０は、サーバのアクターセットレコードを、任意の関連する入力アクターセットに追加することにより、更新されたアクターセットを生成する。（必要に応じて、アクターエニュメレーションモジュール３７０は、新しいアクターセットを作成し、サーバのアクターセットレコードをその新しいアクターセットに追加する。）

ラベルセットの変更−記述変更が、サーバのラベルセットが変更されたことを示す場合、アクターエニュメレーションモジュール３７０は、これを、第１のサーバ（古いラベルセットを持つ）がオフラインになり、第２のサーバ（新しいラベルセットを持つ）がオンラインになる、というように扱う。

ネットワーク露出情報の変更−記述変更が、サーバがネットワークインターフェースを削除したことを示す場合、アクターエニュメレーションモジュール３７０は、サーバのアクターセットレコードを、サーバがメンバーだった全ての入力アクターセット（そのネットワークインターフェースのＢＲＮに関連する）から削除することにより、更新されたアクターセットを生成する。記述変更が、サーバがネットワークインターフェースを追加したことを示す場合、アクターエニュメレーションモジュール３７０は、サーバのアクターセットレコードを、任意の関連する入力アクターセット（そのネットワークインターフェースのＢＲＮに関連する）に追加することにより、更新されたアクターセットを生成する。（必要に応じて、アクターエニュメレーションモジュール３７０は、新しいアクターセット（そのネットワークインターフェースのＢＲＮに関連する）を作成し、サーバのアクターセットレコードをその新しいアクターセットに追加する。）記述変更が、サーバがネットワークインターフェースのＢＲＮを変更したことを示す場合、アクターエニュメレーションモジュール３７０は、これを、第１のネットワークインターフェース（古いＢＲＮを持つ）が削除され、第２のネットワークインターフェース（新しいＢＲＮを持つ）が追加される、というように扱う。記述変更が、サーバがネットワークインターフェースのＩＰアドレス（ＢＲＮではなく）を変更したことを示す場合、アクターエニュメレーションモジュール３７０は、サーバがメンバーだった全ての入力アクターセット（そのネットワークインターフェースのＢＲＮに関連する）内のサーバのアクターセットレコードを修正することにより、更新されたアクターセットを生成する。

関連アクターモジュール３８０は、１つまたは複数のアクターセット（例えば、管理ドメイン状態３２０内の、エニュメレートされた形式の被管理サーバ１３０およびＵＤＧ）と、ルールのセット（例えば、マネージメントポリシー観点）と、を入力として取り込み、どのアクターセットが、それらのルールに関連するのかを判定し、それらのアクターセットのみを出力する。これは、関連アクターモジュール３８０が、アクターセットを検査して、所与のルールのセット用の関連アクターセットのみを抽出するために用いる、フィルタリングプロセスである。関連アクターモジュール３８０は、フィルタリングの実行を、入力アクターセット全てを反復すること、および、入力されたルールのＰＢ部分およびＵＢ部分を分析して、特定のアクターセットが、ルールのＰＢ部分またはＵＢ部分のいずれかによって参照されるかどうかを判定すること、によって行う。最終結果（本明細書において、「アクター観点」と称する）は、アクターセットのコレクションである。アクター観点は、後で、マネージメント命令の一部として被管理サーバ１３０に送られる。

一実施形態において、関連アクターモジュール３８０は、入力されたルールのセットを使用して、「アクターセットフィルタ」を生成する。アクターセットフィルタは、入力アクターセットから、入力されたルールに関連するアクターセットのみを選択する。換言すると、関連アクターモジュール３８０は、アクターセットフィルタを使用して、入力アクターセットをフィルタリングして関連アクターセットにする。

ポリシーエンジンモジュール３４０は、被管理サーバ１３０用のマネージメント命令を生成して、生成したマネージメント命令をサーバに送る。ポリシーエンジンモジュール３４０は、ａ）管理ドメインのコンピュータネットワークインフラ３２０の状態、および、ｂ）管理ドメイン規模のマネージメントポリシー３３０、に基づき、マネージメント命令を生成する（関連ルールモジュール３５０、機能レベル命令生成モジュール３６０、アクターエニュメレーションモジュール３７０、および関連アクターモジュール３８０を使用して）。

例えば、ポリシーエンジンモジュール３４０は、関連ルールモジュール３５０を実行して、管理ドメイン規模のマネージメントポリシー３３０と、特定の被管理サーバ１３０のＵＩＤと、を入力として提供する。関連ルールモジュール３５０は、そのサーバに関連するルールのセット（「マネージメントポリシー観点」）を出力する。ポリシーエンジンモジュール３４０は、アクターエニュメレーションモジュール３７０を実行して、管理ドメイン状態３２０を入力として提供する。アクターエニュメレーションモジュール３７０は、管理ドメイン状態３２０内のエニュメレートされた形式の、被管理サーバ１３０および非管理デバイスグループ（ＵＤＧ）の記述の表現（「アクターセット」）を出力する。ポリシーエンジンモジュール３４０は、機能レベル命令生成モジュール３６０を実行して、マネージメントポリシー観点（関連ルールモジュール３５０によって出力された）を、入力として提供する。機能レベル命令生成モジュール３６０は、機能レベルの命令を出力する。ポリシーエンジンモジュール３４０は、関連アクターモジュール３８０を実行して、アクターセット（エニュメレーションモジュール３７０により出力された）と、マネージメントポリシー観点（関連ルールモジュール３５０により出力された）と、を入力として提供する。関連アクターモジュール３８０は、それらのルールに関連するアクターセット（「関連アクターセット」）のみを出力する。ポリシーエンジンモジュール３４０は、機能レベルの命令（機能レベル命令生成モジュール３６０により出力された）と、関連アクターセット（関連アクターモジュール３８０により出力された）とを、特定の被管理サーバ１３０に送る。

一実施形態において、ポリシーエンジンモジュール３４０は、上記のプロセスの間に生成された情報をキャッシュする。例えば、ポリシーエンジンモジュール３４０は、特定の被管理サーバ１３０に関連して、マネージメントポリシー観点、機能レベルの命令、アクターセットフィルタ、および／または関連アクターセット、をキャッシュする。別の例として、ポリシーエンジンモジュール３４０は、（特定の被管理サーバ１３０に特有でない）アクターセットをキャッシュする。

管理ドメインのアクターセットは、管理ドメイン状態３２０に基づくため、管理ドメイン状態３２０に対する変更が、管理ドメインのアクターセットに対する変更を要求することができる。同様に、被管理サーバのマネージメント命令は、管理ドメイン状態３２０および管理ドメイン規模のマネージメントポリシー３３０に基づくため、管理ドメイン状態３２０に対する変更および／または管理ドメイン規模のマネージメントポリシー３３０に対する変更が、被管理サーバのマネージメント命令に対する変更を要求することができる。一実施形態において、ポリシーエンジンモジュール３４０は、管理ドメインのアクターセットを更新すること、および／または、被管理サーバのマネージメント命令を更新すること、ができ、これらの変更を（必要に応じて）被管理サーバ１３０に配布することができる。上記で言及したキャッシュされた情報は、ポリシーエンジンモジュール３４０が、管理ドメインのアクターセットおよび／または被管理サーバのマネージメント命令を、より効率的に更新して、変更を分配することに、役立つ。

一実施形態において、ポリシーエンジンモジュール３４０は、以下のように、管理ドメインのアクターセットを更新し（管理ドメイン状態３２０に対する変更に基づき）、変更を被管理サーバ１３０に分配する。ポリシーエンジンモジュール３４０は、アクターエニュメレーションモジュール３７０を実行して、キャッシュされたアクターセット（以前、アクターエニュメレーションモジュールにより出力された）と、管理ドメイン状態３２０の変更された部分（すなわち、変更されたサーバ記述）と、を入力として提供する。アクターエニュメレーションモジュール３７０は、更新されたアクターセットを出力する。一実施形態において、ポリシーエンジンモジュール３４０は、次に、更新されたアクターセットの全てを、管理ドメイン１５０内の被管理サーバ１３０の全てに送る。しかし、その実施形態は不十分であり、それは、全てのアクターセットに対する変更によって、全ての被管理サーバが影響を受けるわけではないからである。

別の実施形態において、選択されたアクターセットのみが、選択されたサーバに送られる。例えば、特定の被管理サーバには、ａ）以前に、そのサーバに送られたアクターセット、および、ｂ）変更されているアクターセット、のみが送られる。キャッシュされた関連アクターセットは、どのアクターセットがそのサーバに以前送られたのかを示す（上記（ａ）を参照のこと）。ポリシーエンジンモジュール３４０は、キャッシュされたアクターセットを、更新されたアクターセットと比較して、どのアクターセットが変更されているかを判定する（上記（ｂ）を参照のこと）。そして、ポリシーエンジンモジュール３４０は、（ａ）と（ｂ）との共通部分を計算する。その共通部分のアクターセットが、特定の被管理サーバに送られる。一実施形態において、さらに効率を上げるために、アクターセットが「ｄｉｆｆ」形式で送られる。例えば、ｄｉｆｆ形式は、アクターセット識別子、アクター識別子（例えば、被管理サーバのＵＩＤまたはＵＤＧのＵＩＤ）、および、そのアクターが、追加、削除または修正されるべきかどうかの指標、を指定する。

さらに別の実施形態において、２つの表が保持され、効率を向上させるために使用される。第１の表では、被管理サーバ１３０を、その被管理サーバがメンバーであるアクターセットに関連付ける。第２の表では、被管理サーバ１３０を、その被管理サーバに関連するアクターセットに（例えば、関連アクターモジュール３８０により判定されるように）関連付ける。これらの表において、被管理サーバ１３０は、例えば、その被管理サーバのＵＩＤによって表され、アクターセットは、例えば、そのアクターセットのＵＩＤで表される。ポリシーエンジンモジュール３４０は、管理ドメイン状態３２０の変更された部分（すなわち、変更されたサーバ記述）を使用して、どの被管理サーバの記述が変更されたのかを判定する。ポリシーエンジンモジュール３４０は、第１の表を使用して、その被管理サーバが、どのアクターセットのメンバーだったのかを判定する。それらのアクターセットは、変更されたサーバ記述の結果、変更されてよい。従って、ポリシーエンジンモジュール３４０は、第２の表を使用して、どの被管理サーバに、それらのアクターセットが関連するのかを判定する。ポリシーエンジンモジュール３４０は、それらの被管理サーバのみについて、上記で説明した共通部分の計算を実行する。

一実施形態において、ポリシーエンジンモジュール３４０は、以下のように、被管理サーバのマネージメント命令を（管理ドメイン状態３２０に対する変更に基づき）更新し、更新されたマネージメント命令を被管理サーバに送る。ポリシーエンジンモジュール３４０は、関連ルールモジュール３５０を実行して、管理ドメイン規模のマネージメントポリシー３３０と、被管理サーバ１３０のＵＩＤと、を入力として提供する。関連ルールモジュール３５０は、そのサーバに関連するルールのセット（「マネージメントポリシー観点」）を出力する。ポリシーエンジンモジュール３４０は、出力されたばかりのマネージメントポリシー観点を、キャッシュされたマネージメントポリシー観点と比較して、それらが異なるかどうかを判定する。出力されたばかりのマネージメントポリシー観点と、キャッシュされたマネージメントポリシー観点が同一の場合、ポリシーエンジンモジュール３４０は、それ以上何の行動も取らない。この状況において、以前生成された被管理サーバのマネージメント命令（詳細には、機能レベルの命令および関連アクターセット）は、管理ドメイン状態３２０に対する変更と一致し、再生成されて被管理サーバに再送信される必要はない。

出力されたばかりのマネージメントポリシー観点と、キャッシュされたマネージメントポリシー観点が異なる場合、ポリシーエンジンモジュール３４０は、どのルールが、キャッシュされた観点に追加されるべきなのか、どのルールが、キャッシュされた観点から削除されるべきなのか、を判定する。ポリシーエンジンモジュール３４０は、機能レベル命令生成モジュール３６０を実行して、追加すべきルールと、削除すべきルールと、を入力として提供する。機能レベル命令生成モジュール３６０は、（以前被管理サーバに送られた、キャッシュされた機能レベルの命令と比較して）追加すべき機能レベルの命令と、削除すべき機能レベルの命令と、を出力する。ポリシーエンジンモジュール３４０は、必要に応じて、被管理サーバに命令して、種々の機能レベルの命令を追加または削除させる。一実施形態において、より効率を上げるために、機能レベルの命令が、「ｄｉｆｆ」形式で送られる。例えば、ｄｉｆｆ形式は、機能レベルの命令識別子、および、機能レベルの命令が、以前送られた機能レベルの命令に対して追加、または、削除されるべきかどうかの指標、を指定する。

ポリシーエンジンモジュール３４０は、アクターエニュメレーションモジュール３７０を実行して、キャッシュされたアクターセットと、管理ドメイン状態３２０の変更された部分（すなわち、変更されたサーバ記述）と、を入力として提供する。アクターエニュメレーションモジュール３７０は、更新されたアクターセットを出力する。ポリシーエンジンモジュール３４０は、関連アクターモジュール３８０を実行して、更新されたアクターセットと、出力されたばかりのマネージメントポリシー観点と、を入力として提供する。関連アクターモジュール３８０は、それらのルール（「更新された関連アクターセット」）に関連する、更新されたアクターセットのみを出力する。

ポリシーエンジンモジュール３４０は、更新された関連アクターセットを、キャッシュされた関連アクターセットと比較して、それらが異なるかどうかを判定する。更新された関連アクターセットと、キャッシュされた関連アクターセットと、が同一の場合、ポリシーエンジンモジュール３４０は、アクターセットを何も被管理サーバに送らない。この状況において、以前生成された関連アクターセットは、管理ドメイン状態３２０に対する変更と一致し、被管理サーバに再送信される必要はない。更新された関連アクターセットと、キャッシュされた関連アクターセットとが異なる場合、ポリシーエンジンモジュール３４０は、どのアクターセットが、キャッシュされた関連アクターセットと比較して、追加、削除、または修正されるべきか、を判定する。ポリシーエンジンモジュール３４０は、必要に応じて、被管理サーバに命令して、種々のアクターセットを追加、削除、または修正させる。一実施形態において、より効率を上げるために、アクターセットが「ｄｉｆｆ」形式で送られる。例えば、ｄｉｆｆ形式は、アクターセット識別子、および、そのアクターセットが、以前送られたアクターセットと比較して、追加、削除または修正されるべきかどうかの指標、を指定する。

ポリシーエンジンモジュール３４０が、被管理サーバのマネージメント命令を（管理ドメイン規模のマネージメントポリシー３３０に対する変更に基づき）更新し、更新されたマネージメント命令を、被管理サーバに送ることができること、を思い出されたい。マネージメントポリシー３３０に対する変更は、例えば、ルールまたはルールのセットの追加、削除、または修正、である。一実施形態において、マネージメントポリシー３３０に対する変更が、ＧＵＩまたはＡＰＩを介したグローバルマネージャ１２０との相互作用により、生成される。別の実施形態において、マネージメントポリシー３３０に対する変更が、グローバルマネージャ１２０内で、自動化されたプロセスにより生成される（例えば、グローバルマネージャにより検出されるセキュリティ脅威に応じて）。ポリシーエンジンモジュール３４０は、マネージメントポリシー３３０に対する変更または管理ドメイン状態３２０に対する変更、があるかどうかにかかわらず、同様の方法で、被管理サーバのマネージメント命令を更新し、更新されたマネージメント命令を、被管理サーバに送る。しかし、多少の違いが存在する。

マネージメントポリシー３３０に対する変更の場合、ポリシーエンジンモジュール３４０は、必ずしも全ての被管理サーバ１３０用のマネージメント命令を更新するわけではない。代わりに、ポリシーエンジンモジュール３４０は、以前のマネージメントポリシー３３０を、新しいマネージメントポリシー３３０と比較して、どのルールが、以前のマネージメントポリシー３３０と比較して、追加、削除、または修正されるべきか、を判定する。ポリシーエンジンモジュール３４０は、どの被管理サーバ１３０が、変更されたルールにより影響を受けるのか（例えば、どの被管理サーバが、ａ）ルールおよび／またはスコープの、ＰＢおよび／またはＵＢ部分、および、ｂ）ルールの条件付きの部分（ある場合）、によりカバーされるのか）、を判定する。ポリシーエンジンモジュール３４０は、関連ルールモジュール３５０を実行し、変更されたルール（新しいマネージメントポリシー３３０全体の代わりに）と、被管理サーバ１３０のＵＩＤ（変更されたルールにより影響を受けるサーバのみについて）と、を入力として提供する。

管理ドメイン状態更新（ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｄｏｍａｉｎ ｓｔａｔｅ ｕｐｄａｔｅ（以下ＡＤＳＵ））モジュール３８５は、管理ドメイン状態３２０に対する変更を受け取り、それらの変更を処理する。管理ドメイン状態３２０に対する変更は、例えば、被管理サーバ１３０の記述の、追加、削除、もしくは修正（被管理サーバのラベルセットまたは構成特徴の修正を含む）、または、非管理デバイスもしくは非管理デバイスグループの記述の、追加、削除、もしくは修正、である。一実施形態において、管理ドメイン状態３２０に対する変更が、特定の被管理サーバ１３０から受け取るローカル状態情報に由来する。別の実施形態において、管理ドメイン状態３２０に対する変更が、ＧＵＩまたはＡＰＩを介したグローバルマネージャ１２０との相互作用により、生成される。さらに別の実施形態において、管理ドメイン状態３２０に対する変更が、グローバルマネージャ１２０内で、自動化されたプロセスにより生成される（例えば、グローバルマネージャにより検出されるセキュリティ脅威に応じて）。

例えば、ＡＤＳＵモジュール３８５は、特定の被管理サーバ１３０に関する変更を受け取る。ＡＤＳＵモジュール３８５は、新しい情報を、特定の被管理サーバ１３０の記述の一部として、管理ドメイン状態３２０内に記憶する。そして、ＡＤＳＵモジュール３８５は、（選択的に）被管理サーバの記述を分析して、サーバに関する追加情報を判定し、その情報を記述内に記憶する。次に、ＡＤＳＵモジュール３８５は、被管理サーバの記述に対する変更に基づき、管理ドメインのアクターセットおよび／または被管理サーバのマネージメント命令を更新すべきかどうかを判定する。ＡＤＳＵモジュール３８５が、管理ドメインのアクターセットを更新する、と判定する場合、ＡＤＳＵモジュール３８５は、ポリシーエンジンモジュール３４０に命令して、管理ドメインのアクターセットを更新させる。一実施形態において、ＡＤＳＵモジュール３８５は、イベントが発生するのを待ってから、ポリシーエンジンモジュール３４０に命令して管理ドメインのアクターセットを更新させる。ＡＤＳＵモジュール３８５が、被管理サーバのマネージメント命令を更新する、と判定する場合、ＡＤＳＵモジュール３８５は、ポリシーエンジンモジュール３４０に命令して、被管理サーバのマネージメント命令を更新する。一実施形態において、ＡＤＳＵモジュール３８５は、イベントが発生するのを待ってから、ポリシーエンジンモジュール３４０に命令して被管理サーバのマネージメント命令を更新させる。上述のイベントとは、例えば、ユーザコマンドの受領、または、特定のメンテナンスウィンドウの発生、であってよい。

ＡＤＳＵモジュール３８５が、管理ドメインのアクターセットおよび／または被管理サーバのマネージメント命令を更新する、と判定するかしないかは、被管理サーバの記述に対する変更のタイプに依存する。一実施形態において、ＡＤＳＵモジュール３８５は、この判定を、表２に示すように行う。

一実施形態において、ＡＤＳＵモジュール３８５は、ラベル／構成特徴エンジンを実行して、サーバの記述を入力として提供することにより、サーバに関する追加情報を判定する。ラベル／ＣＣエンジンは、サーバの記述と、ラベル／ＣＣ割り当てルールとに基づき、サーバについてラベル／ＣＣ値を計算する。

別の実施形態において、ＡＤＳＵモジュール３８５は、サーバが、ネットワークアドレス変換器（ＮＡＴ）の後方にあるかどうか（および、ＮＡＴの後方にある場合は、どのタイプのＮＡＴ、すなわち、１：１または１：Ｎ、であるのか）、を判定する。例えば、ＡＤＳＵモジュール３８５は、（ａ）グローバルマネージャとサーバとの間のＴＣＰ接続に係る、サーバのＩＰアドレスと、（ｂ）サーバから受け取るローカル状態情報に係る、サーバのＩＰアドレスと、を比較することにより、ＮＡＴが、グローバルマネージャ１２０と被管理サーバ１３０との間に存在するかどうかを判定する。（ａ）と（ｂ）とが異なる場合、ＮＡＴは、グローバルマネージャ１２０と被管理サーバ１３０との間に存在する。ＮＡＴが存在しない場合、ＡＤＳＵモジュール３８５は、データセンター決定を実行することにより、ＮＡＴのタイプ（１：１または１：Ｎ）を判定する。例えば、ＡＤＳＵモジュール３８５は、サーバのデータセンターを、データセンターのパブリックＩＰアドレスによって、識別する。（あるいは、被管理サーバが、サーバの外部だが、データセンター内部にある情報を問い合わせることにより、データセンター決定を実行する。そして、サーバが、その情報をグローバルマネージャに、ローカルステータスの一部として送る。）構成情報は、どのタイプのＮＡＴがどのデータセンターによって使用されるのか、を示す。何のＮＡＴ情報も、特定のデータセンターに関連付けされない場合、ＡＤＳＵモジュール３８５は、ＮＡＴのタイプが１：Ｎであると想定する。

図４は、一実施形態に係る、被管理サーバ１３０のポリシー実装モジュール１３６の詳細な概念を説明する上位レベルのブロック図である。ポリシー実装モジュール１３６には、ローカル状態リポジトリ４００、ポリシーコンパイルモジュール４１０、および、ローカル状態更新モジュール４２０が含まれる。ローカル状態リポジトリ４００は、被管理サーバ１３０のローカル状態に関する情報を記憶する。一実施形態において、ローカル状態リポジトリ４００は、被管理サーバのオペレーティングシステム（ＯＳ）、ネットワーク露出、およびサービス、に関する情報を記憶する。ＯＳ情報には、例えば、どのＯＳが実行中であるかの指標が含まれる。ネットワーク露出情報およびサービス情報は、管理ドメイン状態３２０内の被管理サーバ１３０の記述について、上記で説明した。

ポリシーコンパイルモジュール４１０は、マネージメント命令と、被管理サーバ１３０の状態と、を入力として取り込み、マネージメントモジュール構成１３４を生成する。例えば、マネージメント命令は、グローバルマネージャ１２０から受け取られ、機能レベルの命令（機能レベル命令生成モジュール３６０により生成される）と、関連アクターセット（関連アクターモジュール３８０により出力される）と、を含む。被管理サーバ１３０の状態は、ローカル状態リポジトリ４００から回収される。一実施形態において、ポリシーコンパイルモジュール４１０の実行は、ａ）被管理サーバが電源が入るか、オンラインになる、ｂ）被管理サーバが機能レベルの命令を受け取る、および／または、ｃ）ローカル状態リポジトリ４００の内容が変更される、ことによりトリガーされる。

ポリシーコンパイルモジュール４１０は、機能レベルの命令および関連アクターセットを、マネージメントモジュール構成１３４にマッピングする。例えば、ポリシーコンパイルモジュール４１０は、アクセス制御機能レベルの命令（ポートおよびアクターセット参照含む）を、Ｌｉｎｕｘオペレーティングシステムのｉｐｔａｂｌｅｓエントリーおよびｉｐｓｅｔエントリー、または、ウィンドウズオペレーティングシステムのウィンドウズフィルタリングプラットフォーム（ＷＦＰ）のルール、にマッピングする。

被管理サーバ１３０におけるマネージメントポリシーの適用は、そのサーバのローカル状態により影響を受け得る。一実施形態において、ポリシーコンパイルモジュール４１０は、受け取った機能レベルの命令に関連する条件を評価し、その評価の結果に基づき、マネージメントモジュール構成１３４を生成する。例えば、ポリシーコンパイルモジュール４１０は、被管理サーバのピア（すなわち、リレーションシップ内の他方のアクター）のオペレーティングシステムを参照する条件を評価し、その評価の結果に基づき、機能プロファイル属性を選択し、選択した機能プロファイル属性は、マネージメントモジュール構成１３４内に表現される。

別の例として、被管理サーバ１３０が、そのサーバには無意味なものとなる機能レベルの命令を受け取り得ることを思い出されたい。例えば、ルールには、被管理サーバのローカル状態を指定する部分が含まれる（例えば、提供されるサービスを記述するサービス部分）。グローバルマネージャ１２０には、被管理サーバのローカル状態（例えば、被管理サーバが実際にそのサービスを提供中であるかどうか）が分からないため、生成された機能レベルの命令が被管理サーバに送られる。ポリシーコンパイルモジュール４１０は、被管理サーバのローカル状態をチェックする（例えば、被管理サーバがそのサービスを提供中であるかどうかを判定する）。この判定は、被管理サーバのローカル状態を参照する条件を評価することを意味する。ポリシーコンパイルモジュール４１０は、それに従って、機能レベルの命令を処理する。ポリシーコンパイルモジュール４１０が、条件が「真」となる（例えば、被管理サーバが、そのサービスを提供中である）と判定する場合、ポリシーコンパイルモジュール４１０は、その機能レベルの命令を、マネージメントモジュール構成１３４に組み込む。詳細には、ポリシーコンパイルモジュール４１０が、機能レベルの命令をマネージメントモジュール構成１３４に組み込むのは、（そのサーバのローカル状態に関与する）関連付けられた条件を評価した後だけである。条件の評価が「偽」の場合、ポリシーコンパイルモジュール４１０は、機能レベルの命令をマネージメントモジュール構成１３４内に表現しない。特定の条件（例えば、その種類および特定の値）は、拡張可能である。一実施形態において、条件は、「サービス」の定義に関連し、プロセス情報および／またはパッケージ情報を含む（管理ドメイン状態３２０内の被管理サーバ１３０の記述について、上記で説明した）。

例えば、ポート８０にインバウンドするアパッチサービスのみへのアクセスを許可する機能レベルの命令について検討する（すなわち、被管理サーバ１３０が、「プロバイダ」またはエンドポイントである）。被管理サーバ１３０が、この機能レベルの命令を、マネージメントモジュール構成１３４内に表現して、ポート８０上でのアクセスの許可を、ポート８０上でリスンしている（そのサーバ上で実行中の）アプリケーションが、実際にアパッチであって、何らかの他のアプリケーションではない（不正なもの、その他）かどうか、に関与する関連付けられた条件を評価した後だけに行う。被管理サーバ１３０は、この機能レベルの命令をマネージメントモジュール構成１３４内に表現するのは、関連付けられた条件が「真」となると判定した後だけである。関連付けられた条件が、「偽」となる場合、被管理サーバ１３０は、この機能レベルの命令をマネージメントモジュール構成１３４内に表現しない。その結果、ネットワークトラフィックがブロックされる。

一実施形態において、被管理サーバ１３０は、そのアウトバウンド接続を監視する。被管理サーバ１３０は、アウトバウンドネットワークトラフィックを、その内部処理テーブルと比較して、そのテーブル内のどのプロセスが、それらのアウトバウンド接続を確立しているのかを判定する。被管理サーバ１３０は、（上記で言及した、要件のセットが与えられた）特定の処理のみに、アウトバウンド接続を確立することを許可するルールを、履行する。

一実施形態において（図示せず）、ポリシーコンパイルモジュール４１０が、被管理サーバ１３０に代えて、グローバルマネージャ１２０に配置される。その実施形態において、グローバルマネージャ１２０は、マネージメント命令を被管理サーバ１３０に送らない。代わりに、被管理サーバ１３０は、そのローカル状態をグローバルマネージャ１２０に送る。ポリシーコンパイルモジュール４１０が、マネージメントモジュール構成１３４を（グローバルマネージャ１２０にて）生成した後、マネージメントモジュール構成１３４は、グローバルマネージャ１２０から被管理サーバ１３０に送られる。

ローカル状態更新（ｌｏｃａｌ ｓｔａｔｅ ｕｐｄａｔｅ（以下ＬＳＵ））モジュール４２０は、被管理サーバ１３０のローカル状態を監視し、ローカル状態情報をグローバルマネージャ１２０に送る。一実施形態において、ＬＳＵモジュール４２０は、被管理サーバ１３０の初期ローカル状態を判定し、適切なローカル状態情報をローカル状態リポジトリ４００に記憶し、そのローカル状態情報をグローバルマネージャ１２０に送る。ＬＳＵモジュール４２０は、被管理サーバ１３０のローカル状態を、サーバのオペレーティングシステム（ＯＳ）および／またはファイルシステムの種々の部分を調査することにより、判定する。例えば、ＬＳＵモジュール４２０は、サービス情報を、ＯＳのカーネルテーブル（ネットワーキング情報）、ＯＳのシステムテーブル（パッケージ情報）、および、ファイルシステム（ファイルおよびハッシュ値）、から取得する。ＬＳＵモジュール４２０は、ネットワーク露出情報を、ＯＳのカーネルおよび／またはＯＳレベルのデータ構造から取得する。

ＬＳＵモジュール４２０は、初期ローカル状態情報をグローバルマネージャ１２０に送った後、ＬＳＵモジュールは、ローカル状態に対する変化を監視する。ＬＳＵモジュールは、例えば、ポーリングする（例えば、調査を周期的に実行する）こと、またはリスンする（例えば、イベントストリームにサブスクライブする）こと、により変更を監視する。ＬＳＵモジュール４２０は、直近に取得されたローカル状態情報を、ローカル状態リポジトリ４００に記憶済みの情報と比較する。情報が一致する場合、ＬＳＵモジュール４２０は、それ以上何の行動も取らない（ローカル状態情報が再度取得されるまで）。それらが異なる場合、ＬＳＵモジュール４２０は、直近に取得された情報を、ローカル状態リポジトリ４００内に記憶し、ポリシーコンパイルモジュール４１０を実行して、マネージメントモジュール構成１３４を再生成し（および、それに従って、マネージメントモジュール１３２を再構成し）、グローバルマネージャ１２０に変更を通知する。一実施形態において、ＬＳＵモジュール４２０は、ローカル状態情報に対する変更を、グローバルマネージャ１２０に「ｄｉｆｆ」形式で送る。例えば、ｄｉｆｆ形式では、ローカル状態情報のタイプ（例えば、オペレーティングシステム）、および、その情報タイプについての新しい値を指定する。別の実施形態において、ＬＳＵモジュール４２０は、ローカル状態リポジトリ４００の全体の内容を、グローバルマネージャ１２０に送る。

図５は、一実施形態に係る、特定の被管理サーバ１３０用のマネージメント命令を生成する方法５００を説明するフローチャートである。他の実施形態が、異なる順番でステップを実行することができ、異なるおよび／または追加のステップを含むことができる。加えて、ステップのうちのいくつかまたは全てが、図１に示されるもの以外のエンティティによって実行されてよい。一実施形態において、方法５００は、複数回実行される（例えば、管理ドメイン１５０内の被管理サーバ１３０ごとに１回）。

方法５００が開始されるとき、管理ドメインのコンピュータネットワークインフラの状態３２０と、管理ドメイン規模のマネージメントポリシー３３０とは、グローバルマネージャ１２０のリポジトリ３００内に既に記憶されてある。この時点で、方法５００が開始される。

ステップ５１０にて、管理ドメイン状態３２０と、管理ドメイン規模のマネージメントポリシー３３０が、アクセスされる。例えば、ポリシーエンジンモジュール３４０が、リポジトリ３００に要求を送り、管理ドメイン状態３２０と、管理ドメイン規模のマネージメントポリシー３３０と、を応答として受け取る。

ステップ５２０にて、１つまたは複数の関連ルールが判定される。例えば、ポリシーエンジンモジュール３４０は、関連ルールモジュール３５０を実行して、管理ドメイン規模のマネージメントポリシー３３０と、特定の被管理サーバ１３０のＵＩＤと、を入力として提供する。関連ルールモジュール３５０は、そのサーバに関連するルールのセット（マネージメントポリシー観点）を出力する。

ステップ５３０にて、アクターがエニュメレートされる。例えば、ポリシーエンジンモジュール３４０は、アクターエニュメレーションモジュール３７０を実行して、管理ドメイン状態３２０を入力として提供する。アクターエニュメレーションモジュール３７０は、管理ドメイン状態３２０内のエニュメレートされた形式の、被管理サーバ１３０および非管理デバイスグループ（ＵＤＧ）の表現（「アクターセット」）を生成する。

ステップ５４０において，１つまたは複数の機能レベルの命令が生成される。例えば、ポリシーエンジンモジュール３４０は、機能レベル命令生成モジュール３６０を実行して、マネージメントポリシー観点（ステップ５２０にて生成された）を入力として提供する。機能レベル命令生成モジュール３６０が、機能レベルの命令を生成する。

ステップ５５０にて、１つまたは複数の関連アクターが判定される。例えば、ポリシーエンジンモジュール３４０は、関連アクターモジュール３８０を実行して、アクターセット（ステップ５３０にて生成された）と、マネージメントポリシー観点（ステップ５２０にて生成された）と、を入力として提供する。関連アクターモジュール３８０は、それらのルールに関連するアクターセット（関連アクターセット）のみを出力する。

ステップ５６０にて、マネージメント命令が特定の被管理サーバ１３０に送られる。例えば、ポリシーエンジンモジュール３４０は、機能レベルの命令（ステップ５４０にて生成された）と、関連アクターセット（ステップ５５０にて生成された）と、を特定の被管理サーバ１３０に送る。

なお、ステップ５２０および５４０は、特定の被管理サーバ１３０についてのマネージメントポリシー観点（および、結果として得られる機能レベルの命令）を生成することに関与し、一方、ステップ５３０および５５０は、その被管理サーバについてのアクター観点を生成することに関与する。ステップ５２０で、ステップ５５０によって使用されるルールのセットが生成されるため、マネージメントポリシー観点の生成と、アクター観点の生成とは、最小限でもお互いに依存する。そうであっても、マネージメントポリシーの計算（すなわち、ステップ５２０および５４０）と、アクターセットの計算（すなわち、ステップ５３０および５５０）と、を別々に維持することは、ポリシーエンジンモジュール３４０の拡張性を向上させる。マネージメントポリシーの計算と、アクターセットの計算が、ほどんど別々に維持されるため、それらは、並行して実行されてよい（例えば、同じ被管理サーバ１３０についてであっても）。加えて、異なる被管理サーバ１３０についての観点の計算も、並行して実行されてよい。また、アクターが変更される場合、アクターセットのみが、再計算されればよい。（機能レベルの命令は、再計算される必要が無い。）ルールが変更される場合、機能レベルの命令および関連アクターセットのみが再計算されればよい。（アクターは、再エニュメレートされる必要が無い。）

図６は、一実施形態に係る、被管理サーバ１３０のマネージメントモジュール１３２の構成１３４を生成する方法６００を説明するフローチャートである。他の実施形態が、異なる順番でステップを実行することができ、異なるおよび／または追加のステップを含むことができる。加えて、ステップのうちのいくつかまたは全てが、図１に示されるもの以外のエンティティによって実行されてよい。

方法６００が開始されるとき、被管理サーバ１３０のローカル状態に関する情報が、被管理サーバ１３０のポリシー実装モジュール１３６のローカル状態リポジトリ４００内に既に記憶されてある。この時点で、方法６００が開始される。

ステップ６１０にて、マネージメント命令が、グローバルマネージャ１２０から受け取られる。例えば、ポリシーコンパイルモジュール４１０は、機能レベルの命令と、関連アクターセットと、をグローバルマネージャ１２０から受け取る。

ステップ６２０にて、ローカル状態がアクセスされる。例えば、ポリシーコンパイルモジュール４１０は、ローカル状態リポジトリ４００内に記憶される、被管理サーバ１３０のローカル状態に関する情報にアクセスする。

ステップ６３０にて、マネージメントモジュール構成１３４が生成される。例えば、ポリシーコンパイルモジュール４１０は、マネージメント命令（ステップ６１０にて受け取られた）と、ローカル状態（ステップ６２０にてアクセスされた）と、を入力として取り込み、マネージメントモジュール構成１３４を生成する。

ステップ６４０にて、マネージメントモジュール１３２が構成される。例えば、ポリシーコンパイルモジュール４１０は、マネージメントモジュール構成１３４（ステップ６３０にて生成された）に従って動作するべく、マネージメントモジュール１３２を構成する。

図７は、一実施形態に係る、被管理サーバ１３０のローカル状態を監視し、かつ、ローカル状態情報をグローバルマネージャ１２０に送る、方法７００を説明するフローチャートである。他の実施形態が、異なる順番でステップを実行することができ、異なるおよび／または追加のステップを含むことができる。加えて、ステップのうちのいくつかまたは全てが、図１に示されるもの以外のエンティティによって実行されてよい。

方法７００が開始されるとき、被管理サーバ１３０のローカル状態に関する情報が、被管理サーバ１３０のローカル状態リポジトリ４００内に既に記憶されてある。この時点で、方法７００が開始される。

ステップ７１０にて、被管理サーバ１３０の現在のローカル状態に関する情報が判定される。例えば、ＬＳＵモジュール４２０は、被管理サーバ１３０のローカル状態を、サーバのオペレーティングシステム（ＯＳ）および／またはファイルシステムの種々の部分を調査することにより、判定する。

ステップ７２０にて、現在のローカル状態に関する情報が、ローカル状態リポジトリ４００内に記憶された情報と異なるかどうかに関して、判定が行われる。例えば、ＬＳＵモジュール４２０がこの判定を実行する。情報が異ならない場合、方法はステップ７３０に進み、終了する。情報が異なる場合、方法はステップ７４０に進む。

ステップ７４０にて、異なる情報が、ローカル状態リポジトリ４００内に記憶される。例えば、ＬＳＵモジュール４２０が、このステップを実行する。

ステップ７５０にて、マネージメントモジュール構成１３４は、再生成され（ローカル状態リポジトリ４００の内容が変更されたため）、マネージメントモジュール１３２がそれに従って、再生成される。例えば、ＬＳＵモジュール４２０は、ポリシーコンパイルモジュール４１０を実行し、これによりマネージメントモジュール構成１３４が再生成される。

ステップ７６０にて、異なる情報が、グローバルマネージャ１２０に送られる。例えば、ＬＳＵモジュール４２０が、このステップを実行する。

図８は、一実施形態に係る、管理ドメインのコンピュータネットワークインフラの状態３２０に対する変化を処理する、方法８００を説明するフローチャートである。他の実施形態が、異なる順番でステップを実行することができ、異なるおよび／または追加のステップを含むことができる。加えて、ステップのうちのいくつかまたは全てが、図１に示されるもの以外のエンティティによって実行されてよい。

ステップ８１０にて、特定の被管理サーバ１３０に関する変更が受け取られる。例えば、管理ドメイン状態更新（ＡＤＳＵ）モジュール３８５は、オンライン／オフラインインジケータ、オペレーティングシステムインジケータ、ネットワーク露出情報、および／または、サービス情報を、被管理サーバ１３０から、ローカル状態情報の一部として受け取る。

ステップ８２０にて、受け取った情報が記憶される。例えば、ＡＤＳＵモジュール３８５は、受け取ったオンライン／オフラインインジケータ、ネットワーク露出情報、および／または、サービス情報を、管理ドメイン状態３２０内（詳細には、情報が関連する被管理サーバ１３０の記述内）に記憶する。

ステップ８３０にて、サーバ記述が分析されて、サーバに関する追加情報を判定する。例えば、ＡＤＳＵモジュール３８５は、ラベル／構成特徴エンジンを使用して、サーバについてラベル／ＣＣ値を計算し、および／または、サーバが、ネットワークアドレス変換器（ＮＡＴ）の後方にあるかどうか（および、ＮＡＴの後方にある場合は、どのタイプのＮＡＴ、すなわち、１：１または１：Ｎ、であるのか）、を判定し、その情報をサーバ記述内に記憶する。ステップ８３０は選択的（optional）なものである。

ステップ８４０にて、管理ドメインのアクターセットを更新すべきかどうかに関して、判定がなされる。例えば、ＡＤＳＵモジュール３８５は被管理サーバの記述に対する変更に基づき、管理ドメインのアクターセットを更新すべきかどうかを判定する。管理ドメインのアクターセットを更新するという判定がなされる場合、方法はステップ８５０に進む。管理ドメインのアクターセットを更新しないという判定がなされる場合、方法はステップ８６０に進む。

ステップ８５０にて、管理ドメインのアクターセットが更新される。たとえば、ＡＤＳＵモジュール３８５は、ポリシーエンジンモジュール３４０に命令して管理ドメインのアクターセットを更新させる。一実施形態（図示せず）において、ＡＤＳＵモジュール３８５は、イベントが発生するのを待ってから、ポリシーエンジンモジュール３４０に命令して管理ドメインのアクターセットを更新させる。

ステップ８６０にて、被管理サーバのマネージメント命令を更新すべきかどうかに関して、判定がなされる。例えば、ＡＤＳＵモジュール３８５は、被管理サーバの記述に対する変更に基づき、被管理サーバのマネージメント命令を更新すべきかどうかを判定する。被管理サーバのマネージメント命令を更新するという判定がなされる場合、方法はステップ８７０に進む。被管理サーバのマネージメント命令を更新しないという判定がなされる場合、方法はステップ８８０に進む。

ステップ８７０にて、被管理サーバのマネージメント命令が更新される。たとえば、ＡＤＳＵモジュール３８５は、ポリシーエンジンモジュール３４０に命令して被管理サーバのマネージメント命令を更新させる。一実施形態（図示せず）において、ＡＤＳＵモジュール３８５は、イベントが発生するのを待ってから、ポリシーエンジンモジュール３４０に命令して被管理サーバのマネージメント命令を更新させる。

ステップ８８０にて、方法が終了する。

上記の説明は、特定の実施形態の動作を説明するために含まれ、本発明の範囲を制限することは意図されない。本発明の範囲は、以下の請求項によってのみ、制限されるべきである。上記の検討から、当業者には、本発明の精神および範囲によってさらに網羅されるであろう多くの変形が明らかとなるであろう。

Claims (15)

1. 管理ドメイン内で特定の被管理サーバの状態に対する変化を処理するための方法であって、前記管理ドメインは、マネージメントモジュールを構成するためのマネージメント命令を使用する複数の被管理サーバを含み、当該構成されたマネージメントモジュールが１つまたは複数のルールのセットを含む管理ドメイン規模のマネージメントポリシーを実装するようにし、前記方法が、
   前記１つまたは複数のルールのセットを記憶するステップであって、各ルールは、コンピュータネットワークを介して提供されるサービスを特定し、提供元部分は、どの被管理サーバが前記コンピュータネットワークを介して前記サービスを提供するルールによって制御されるかを示し、使用元部分は、どの被管理サーバが前記コンピュータネットワークを介してアクセスされる前記サービスを使用するルールによって制御されるかを示す、ステップと、
   前記特定の被管理サーバの第１の記述を修正して、前記特定の被管理サーバの修正された記述を生成し、前記特定の被管理サーバの変更された状態を示すステップと、
   前記第１の記述を、前記修正された記述と比較し、それによって、記述変更を特定するステップと、
   前記記述変更に基づき、前記特定の被管理サーバに以前送信された現在のマネージメント命令を更新するかどうかを判定するステップと、
   前記特定の被管理サーバの現在のマネージメント命令を更新するという判定に応答して、
   前記修正された記述に基づき、前記ルールのセット内のどのルールが前記特定の被管理サーバに適用可能な提供元部分又は前記特定の被管理サーバに適用可能な使用元部分を特定するのかを判定するステップであって、それによって、現在の関連ルールを特定するステップと、
   前記第１の記述に基づき以前に判定された、キャッシュされた以前の関連ルールを取得するステップと、
   前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるかどうかを判定するステップと、
   前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるという判定に応答して：
   前記キャッシュされた以前の関連ルールに応じて追加、除去又は修正されるべきルールを判定するステップと、
   当該判定されたルールに基づいて前記キャッシュされた以前の関連ルールを更新するステップと、
   前記判定されたルールに基づいて前記特定の被管理サーバによって実行される管理命令を生成するステップと、
   前記管理命令及び前記特定の被管理サーバ上での前記管理命令を追加、除去又は修正するための命令を前記特定の被管理サーバに送るステップと、
   を含むことを特徴とする方法。
2. 前記特定の被管理サーバのマネージメント命令を更新するという判定に応答して、かつ、前記現在の関連ルールが、前記キャッシュされた以前の関連ルールと異なるという判定に応答して、
   キャッシュされたアクターセットを更新して、前記特定の被管理サーバの変更された状態を示し、それによって、更新されたアクターセットを特定するステップと、
   どの更新されたアクターセットが、前記特定の被管理サーバに関連するのかを判定するステップであって、それによって、現在関連する更新されたアクターセットを特定するステップと、
   前記現在関連する更新されたアクターセットが、前記特定の被管理サーバに以前送られたアクターセットと異なるかどうか、を判定するステップと、
   前記現在関連する更新されたアクターセットが、前記以前送られたアクターセットと異なるという判定に応答して：
   前記以前送られたアクターセットに応じて追加、除去又は修正されるべき、更新されたアクターセットを判定するステップと、
   前記更新されたアクターセット及び前記更新されたアクターセットを追加、除去又は修正するための第２の命令を前記特定の被管理サーバに送るステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記記述変更は、オンライン／オフラインの変更、ラベルセットの変更、構成特徴の変更、またはネットワーク公開情報の変更を含むことを特徴とする請求項１に記載の方法。
4. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
   前記記述変更が、前記特定の被管理サーバがオフラインからオンラインになったことを示すかどうかを判定するステップと、
   前記記述変更が、前記特定の被管理サーバがオフラインからオンラインになったことを示す、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新する、と判定するステップと、
   を含むことを特徴とする請求項１に記載の方法。
5. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
   前記記述変更が、ラベルセットの変更または構成特徴の変更を含むかどうかを判定するステップと、
   前記記述変更が、ラベルセットの変更または構成特徴の変更を含む、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新すると判定するステップと、
   を含むことを特徴とする請求項１に記載の方法。
6. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
   前記記述変更が、ネットワーク公開情報の変更を含むかどうかを判定するステップと、
   前記記述変更が、ネットワーク公開情報の変更を含む、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新すると判定するステップと、
   を含むことを特徴とする請求項１に記載の方法。
7. 前記第１の記述を、前記修正された記述と比較する前に、
   前記修正された記述に基づき、前記特定の被管理サーバに関する追加情報を判定するステップと、
   前記修正された記述を修正して、前記追加情報を示すステップと、
   をさらに含むことを特徴とする請求項１に記載の方法。
8. 管理ドメイン内で特定の被管理サーバの状態に対する変化を処理するためのコンピュータプログラムを記憶する、非一時的コンピュータ可読記憶媒体であって、前記管理ドメインは、マネージメントモジュールを構成するためのマネージメント命令を使用する複数の被管理サーバを含み、当該構成されたマネージメントモジュールが１つまたは複数のルールのセットを含む管理ドメイン規模のマネージメントポリシーを実装するようにし、前記コンピュータプログラムは、
   前記１つまたは複数のルールのセットを記憶するステップであって、各ルールは、コンピュータネットワークを介して提供されるサービスを特定し、提供元部分は、どの被管理サーバが前記コンピュータネットワークを介して前記サービスを提供するルールによって制御されるかを示し、使用元部分は、どの被管理サーバが前記コンピュータネットワークを介してアクセスされる前記サービスを使用するルールによって制御されるかを示す、ステップと、
   前記特定の被管理サーバの第１の記述を修正して、前記特定の被管理サーバの修正された記述を生成し、前記特定の被管理サーバの変更された状態を示すステップと、
   前記第１の記述を、前記修正された記述と比較し、それによって、記述変更を特定するステップと、
   前記記述変更に基づき、前記特定の被管理サーバに以前送信された現在のマネージメント命令を更新するかどうかを判定するステップと、
   前記特定の被管理サーバの現在のマネージメント命令を更新するという判定に応答して、
   前記修正された記述に基づき、前記ルールのセット内のどのルールが前記特定の被管理サーバに適用可能な提供元部分又は前記特定の被管理サーバに適用可能な使用元部分を特定するのかを判定するステップであって、それによって、現在の関連ルールを特定するステップと、
   前記第１の記述に基づき以前に判定された、キャッシュされた以前の関連ルールを取得するステップと、
   前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるかどうかを判定するステップと、
   前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるという判定に応答して：
   前記キャッシュされた以前の関連ルールに応じて追加、除去又は修正されるべきルールを判定するステップと、
   当該判定されたルールに基づいて前記キャッシュされた以前の関連ルールを更新するステップと、
   前記判定されたルールに基づいて前記特定の被管理サーバによって実行される管理命令を生成するステップと、
   前記管理命令及び前記特定の被管理サーバ上での前記管理命令を追加、除去又は修正するための命令を前記特定の被管理サーバに送るステップと、
   をコンピュータプロセッサに実行させることを特徴とする非一時的コンピュータ可読記憶媒体。
9. 前記コンピュータプログラムは、
   前記特定の被管理サーバのマネージメント命令を更新するという判定に応答して、かつ、前記現在の関連ルールが、前記キャッシュされた以前の関連ルールと異なるという判定に応答して、
   キャッシュされたアクターセットを更新して、前記特定の被管理サーバの変更された状態を示し、それによって、更新されたアクターセットを特定するステップと、
   どの更新されたアクターセットが、前記特定の被管理サーバに関連するのかを判定するステップであって、それによって、現在関連する更新されたアクターセットを特定するステップと、
   前記現在関連する更新されたアクターセットが、前記特定の被管理サーバに以前送られたアクターセットと異なるかどうか、を判定するステップと、
   前記現在関連する更新されたアクターセットが、前記以前送られたアクターセットと異なるという判定に応答して：
   前記以前送られたアクターセットに応じて追加、除去又は修正されるべき、更新されたアクターセットを判定するステップと、
   前記更新されたアクターセット及び前記更新されたアクターセットを追加、除去又は修正するための第２の命令を前記特定の被管理サーバに送るステップと、
   を前記コンピュータプロセッサにさらに実行させることを特徴とする請求項８に記載の非一時的コンピュータ可読記憶媒体。
10. 前記記述変更は、オンライン／オフラインの変更、ラベルセットの変更、構成特徴の変更、またはネットワーク公開情報の変更を含むことを特徴とする請求項８に記載の非一時的コンピュータ可読記憶媒体。
11. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
    前記記述変更が、前記特定の被管理サーバがオフラインからオンラインになったことを示すかどうかを判定するステップと、
    前記記述変更が、前記特定の被管理サーバがオフラインからオンラインになったことを示す、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新する、と判定するステップと、
    を含むことを特徴とする請求項８に記載の非一時的コンピュータ可読記憶媒体。
12. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
    前記記述変更が、ラベルセットの変更または構成特徴の変更を含むかどうかを判定するステップと、
    前記記述変更が、ラベルセットの変更または構成特徴の変更を含む、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新する、と判定するステップと、
    を含むことを特徴とする請求項８に記載の非一時的コンピュータ可読記憶媒体。
13. 前記特定の被管理サーバに以前送られたマネージメント命令を更新するかどうかを判定するステップが、
    前記記述変更が、ネットワーク公開情報の変更を含むかどうかを判定するステップと、
    前記記述変更が、ネットワーク公開情報の変更を含む、という判定に応答して、前記特定の被管理サーバのマネージメント命令を更新すると判定するステップと、
    を含むことを特徴とする請求項８に記載の非一時的コンピュータ可読記憶媒体。
14. 管理ドメイン内で特定の被管理サーバの状態に対する変化を処理するためのシステムであって、前記管理ドメインは、マネージメントモジュールを構成するためのマネージメント命令を使用する複数の被管理サーバを含み、当該構成されたマネージメントモジュールが１つまたは複数のルールのセットを含む管理ドメイン規模のマネージメントポリシーを実装するようにし、前記システムが、
    コンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体と、
    コンピュータプロセッサと、
    を含み、
    前記コンピュータプログラムは、前記コンピュータプロセッサに、
    前記１つまたは複数のルールのセットを記憶するステップであって、各ルールは、コンピュータネットワークを介して提供されるサービスを特定し、提供元部分は、どの被管理サーバが前記コンピュータネットワークを介して前記サービスを提供するルールによって制御されるかを示し、使用元部分は、どの被管理サーバが前記コンピュータネットワークを介してアクセスされる前記サービスを使用するルールによって制御されるかを示す、ステップと、
    前記特定の被管理サーバの第１の記述を修正して、前記特定の被管理サーバの修正された記述を生成し、前記特定の被管理サーバの変更された状態を示すステップと、
    前記第１の記述を、前記修正された記述と比較し、それによって、記述変更を特定するステップと、
    前記記述変更に基づき、前記特定の被管理サーバに以前送信された現在のマネージメント命令を更新するかどうかを判定するステップと、
    前記特定の被管理サーバの現在のマネージメント命令を更新するという判定に応答して、
    前記修正された記述に基づき、前記ルールのセット内のどのルールが前記特定の被管理サーバに適用可能な提供元部分又は前記特定の被管理サーバに適用可能な使用元部分を特定するのかを判定するステップであって、それによって、現在の関連ルールを特定するステップと、
    前記第１の記述に基づき以前に判定された、キャッシュされた以前の関連ルールを取得するステップと、
    前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるかどうかを判定するステップと、
    前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるという判定に応答して：
    前記キャッシュされた以前の関連ルールに応じて追加、除去又は修正されるべきルールを判定するステップと、
    当該判定されたルールに基づいて前記キャッシュされた以前の関連ルールを更新するステップと、
    前記判定されたルールに基づいて前記特定の被管理サーバによって実行される管理命令を生成するステップと、
    前記管理命令及び前記特定の被管理サーバ上での前記管理命令を追加、除去又は修正するための命令を前記特定の被管理サーバに送るステップと、
    を実行させることを特徴とするシステム。
15. 前記ルールのセット内のどのルールが前記特定の被管理サーバに適用可能な提供元部分又は前記特定の被管理サーバに適用可能な使用元部分を特定するのかを判定するステップと、前記現在の関連ルールが、前記特定の被管理サーバのための前記キャッシュされた以前の関連ルールと異なるかどうかを判定するステップとは、制限されたルールのセットを識別して、前記特定の被管理サーバが前記制限されたルールのセットを効率的に分散することを可能にすることを特徴とする請求項１に記載の方法。