ポリシーベースの管理

ポリシーベース管理^{[1] [2] [3]は、ネットワークや}分散システムの管理という複雑な作業を簡素化できる技術です。このパラダイムでは、管理者はネットワークや分散システムのさまざまな側面を、その動作を規定する一連のポリシーを展開することで、柔軟かつ簡素化された方法で管理できます。^{[4] [5]}ポリシーは、基盤となる実装を変更することなく動的に変更できる解釈ロジックを導入することで、管理対象デバイスのハードコードされた機能を強化することを目的とした、技術に依存しないルールです。これにより、管理対象システムまたは管理システム自体の動作を中断することなく、ある程度のプログラミングが可能になります。ポリシーベース管理は、あらゆる分散システムまたはネットワークの自己管理の側面を大幅に向上させ、自律コンピューティングシステムによって実証されるより自律的な動作につながります。^{[6] [7]}

最もよく知られているポリシーベースの管理アーキテクチャは、IETFとDMTFによって共同で規定されました。これは、ポリシー管理ツール (PMT)、ポリシー リポジトリ、ポリシー決定ポイント (PDP)、およびポリシー適用ポイント (PEP) という 4 つの主要な機能要素で構成されています。

PMT は、管理対象ネットワークで強制されるポリシーを管理者が定義または更新するために使用されます。生成されたポリシーは、異なるベンダーの製品間での相互運用性を確保するために、情報モデル^[8]に対応する形式でリポジトリに格納されます。リポジトリに新しいポリシーが追加されたり、既存のポリシーが変更されたりすると、PMT は関連する PDP に通知を発行し、PDP はポリシーを解釈して PEP に伝達します。PEP は、ポリシー対応ノードで実行され、さまざまなポリシーを実行 (強制) できるコンポーネントです。アーキテクチャのコンポーネントは、さまざまなプロトコルを使用して相互に通信できます。PDP とネットワーク デバイス (PEP) の間でポリシー決定を伝達するための推奨される選択肢は、Common Open Policy Service (COPS) またはSNMPであり、PMT/PDP リポジトリ通信には LDAP を使用します。

ポリシー仕様の最も単純なアプローチは、一連のルールを使用することです。各ルールは、単純な条件とアクションのペアの形式です。IETF ポリシー フレームワークはこのアプローチを採用し、ポリシーを、定義された条件に応じて実行されるアクションを指定するルールと見なします。

       <条件>の場合、 <アクション>

ルールの条件部分は、連言標準形または選言標準形で指定される単純式または複合式にすることができます。ルールのアクション部分は、条件が真の場合に実行する必要がある一連のアクションにすることができます。IETF は、ネットワーク ポリシーを表現するための特定の言語ではなく、ポリシー情報を表すための汎用オブジェクト指向情報モデルを定義しています。このモデルは汎用モデルであり、関連付けによって抽象ポリシー クラスの構造を指定します。これにより、ベンダーはポリシー ルールで使用される独自の条件とアクションのセットを実装できます。

他のプログラム可能なシステムと同様に、ポリシー駆動型システムも、その動作を規定する矛盾したルールによって不整合が生じる可能性があります。これらはポリシー競合^{[9]と呼ばれ、仕様エラー、省略、または矛盾した管理操作の結果として発生し、場合によっては、管理対象システムの動作に壊滅的な影響を及ぼす可能性があります。また、ポリシー競合は、2 つ以上のポリシーが同時にアクティブ化され、システムに対して矛盾した管理操作が強制されるときに発生するソフトウェア バグ[10]}に類似していると説明されています。

ポリシー競合は、ドメインに依存しないポリシーとアプリケーション固有のポリシーに分類されます。 ^[11]前者は、その名前が示すように、ポリシーの適用とは独立しており、後者はアプリケーション ドメインの制約を受けます。文献で検討されているアプリケーション ドメインの例には、IP ネットワークのサービス品質 (QoS) ^{[9] [12]}、分散システム^{[11] [13]}、ファイアウォール セキュリティ^{[14] [15] [16} ] 、通信ネットワークの呼制御^[17]などがあります。ポリシー競合は、検出できる時間枠によっても分類できます。静的競合^[18]は、ポリシー仕様の時点でオフライン分析によって検出できますが、動的競合^[19]は、ポリシーが管理対象システムの現在の状態に依存するため、ポリシーが適用されたときにのみ検出できます。たとえば、リソースを動的に割り当てるポリシーと、ユーザーまたはサービス クラスの割り当てを設定するポリシーとの間に競合が発生する可能性があります。したがって、競合による運用上の影響を最小限に抑えるために、自動化は動的分析メカニズムの重要な側面となる必要があります。

ポリシーを効果的に使用し、管理対象システムの機能を一貫した方法で駆動するには、新しく作成されたポリシーが互いに、またはシステムにすでに導入されているポリシーと競合していないことを確認する必要があります。これを実現するために、検出プロセスは、競合が発生する可能性のある条件に関する情報を利用してポリシー空間を検索し、競合基準を満たすポリシーを特定します。文献で特定された競合の種類と、競合が発生するさまざまなアプリケーションドメインに基づいて、研究は、それらを効果的に検出するためのメカニズムと手法の開発に集中してきました。単純な競合（モダリティ競合など）は構文解析によって検出できますが、より特殊な不一致には、競合の条件を正確に定義する必要があります。これには、ドメイン固有の知識が含まれる場合があり、そのような情報を使用して競合の発生を通知するプロセスが必要です。競合を検出するための一般的なアプローチは、メタポリシー（検出ルール）^{[9] [11] [20]、}ポリシー関係、^{[14] [15] [16]、}適用性空間、^[21]、および情報モデルに基づいています。^[22]

解決はポリシー分析の後半部分であり、検出された不一致を、できれば自動化された方法で処理して、ポリシー間の一貫性を回復することを目的とします。競合を解決するプロセスには、ポリシーの撤回、抑制、優先順位付け、または修正が含まれる場合があり、場合によっては、ポリシールール間の一貫性を回復できるように、新しいポリシーを完全に適用することもあります。これを行う方法論は、関係するポリシーの種類と競合が発生するドメインに大きく依存します。状況によっては人間の介入が避けられませんが、いくつかの研究では、可能な限り解決プロセスを自動化する手法に焦点を当てています。競合を解決するための一般的なアプローチは、メタポリシー（解決ルール）^{[9] [19] [20]}優先順位、^[11]ポリシーの順序付け、^{[15] [21]}および競合の予防に基づいています。^[23]

競合を検出できる時間枠は、競合に対処するための分析方法と要件に影響します。静的な競合は通常、システム管理者が手動で開始する分析によって検出されます。競合はポリシー間の不一致を表し、通常はポリシーを修正することで解決されます。^{[9] [18]}対照的に、実行時の競合は、ポリシーの適用を監視し、システムの実行における不一致な状況を検出するプロセスによって検出する必要があります。解決は、解決ルールの適用などによって自動的に達成される必要があります。^{[9] [19]}実行時の競合の処理が自動化されていないと、特に遅延の影響を受けやすいアプリケーションの QoS を管理する場合に、正しいシステム操作に壊滅的な結果をもたらす可能性があります。

理想的には、ポリシーベースの管理システムは、人間が表現して理解しやすい高レベルの管理目標の定義を容易にし、それを低レベルのポリシーに変換し、それに応じて管理対象デバイスを構成するコマンドにマッピングする必要があります。高レベルの目標はネットワーク管理者のビジネス目標を反映しますが、低レベルのポリシーはデバイスレベルの構成を担当します。

ポリシーの改良とは、高レベルの目標または抽象的なポリシー仕様を、管理対象システムで適用できる低レベルの具体的なポリシーに変換するプロセスです。改良プロセスの主なタスクは次のとおりです。

• ポリシーの要件を満たすために必要なリソースを決定する
• 高レベルの目標をシステムが実行できる運用ポリシーに変換する
• 低レベルのポリシーが実際に高レベルの目標で指定された要件を満たしていることを確認する

いくつかのポリシー改良アプローチが開発されている。最も注目すべきものは線形時相論理、^[24]、 イベント計算、^[25]、ユーティリティコンピューティングに基づくものである。^{[26] [27]}

• ネットワーク内管理
• ネットワークとサービス管理の分類
• ネットワーク管理
• ネットワーク管理システム
• ネットワークパフォーマンス管理
• ネットワークとサービス管理の分類
• システム管理