ポリシーを作成する

内容
casp1032jp
内容
ポリシーは、ポリシー定義、1 つ以上のポリシー ルール、およびルール設定から構成されます。ポリシーを適用するには、ポリシーを事前に有効にしておく必要があります。
注:
レガシー ポリシーの場合は、XML ファイルを使用してポリシー定義を設定し維持します。詳細については、「レガシーの XML ベースのポリシー」を参照してください。
ポリシーについて
ポリシーでは、一連のポリシー ルールに対して、関連する属性のグループを定義します。1 つ以上のルールを結合して、1 つのポリシーを作成します。ポリシーの適用中にモデルに適用される設定は、複数のルールから得ることができます。ポリシー内でルール用の複数のグローバル コレクションに同一のモデルが存在する状況を処理するために、ルールには優先順位が付けられます。すべてのルールが徹底的に検討されるまで、各ルールは優先順に評価されます。モデルは、条件が最初に満たされたルールの設定を採用します。モデルが後続のルールの条件と一致した場合は、まだ検出されていない設定のみが適用されます。
たとえば、以下の図に、2 つの異なるグローバル コレクション(GC1 および GC2)で定義されているポリシーについて説明しています。Switch1 は、GC1 に排他的に属し、Rule1 の設定のみが適用されます。Switch3 は、GC2 に排他的に属し、Rule2 の設定のみが適用されます。Switch2 は GC1 と GC2 の両方に属します。ルール優先度のために、Rule1 内の設定(attr1 および attr2 が含まれる)が最初に適用されます。次に、このモデルにまだ適用されていない、Rule2 内の設定(attr3 のみ)が適用されます。attr1 はこのモデルにすでに適用されているので無視されます。
Policy definition example diagram
ポリシーを有効にする必要があります。ポリシーおよび影響を受けるデバイスのモデルにおけるイベントおよびアラームによって、ポリシーのアクティビティと適用が追跡されます。
ポリシー定義を正常に計画する方法
サイトで実装されるポリシーを設計する場合は、以下のガイドラインを考慮します。
  • 推奨されているポリシーを使用します。詳細については、「推奨するポリシー設定」を参照してください。
  • 事前定義済み設定を使用します。通常、ポリシーをセットアップする場合は、テンプレートを使用するのが最適な方法です。テンプレート内の属性のコレクションから開始し、次に、必要に応じて属性および属性の値を調整します。
  • 特定の条件に対処するポリシーを定義します。ネットワーク内の問題を識別した場合は、問題の性質に基づいて監視する属性を検討します。
  • 新しいポリシーをテスト環境で展開してから実稼働環境に移動します。詳細については、「ポリシーのエクスポートおよびインポート」を参照してください。
例: Port Fault Management ポリシー
ポート ステータスを監視するポリシーをセットアップすると仮定します。すべてのスイッチ ポートをパッシブに監視し、すべてのルータ ポートをアクティブに監視します。「推奨するポリシー設定」のレビューを基に、Port Fault Management ポリシーでこのポリシー シナリオが反映されることを確認します。このポリシーを実装するには、一連のポリシー ルールを定義します。
  • ルール 1: すべてのスイッチ ポートを識別するための検索条件を指定するグローバル コレクションを定義します。次に、このグローバル コレクション内のすべてのデバイスで、パッシブ ポート監視テンプレートにあるパッシブ監視用の事前定義済み設定を使用することができます。必要に応じて属性値を調整します。
  • ルール 2: すべてのルータ ポートを識別するための検索条件を指定するグローバル コレクションを定義します。次にコレクション内のすべてのデバイスで、ライブ パイプテンプレートに定義されているように、ライブ パイプを使用してポート ステータス監視用に事前定義済み設定を使用します。必要に応じて属性値を調整します。
これらの 2 つのポリシー ルールを組み合わせて、Port Fault Management ポリシーを作成します。次に、ポリシーを有効にして発効する必要があります。
注:
Port Fault Management ポリシーおよびその他の推奨するポリシーについては、「推奨するポリシー設定」を参照してください。
ポリシー定義の制限
ポリシーを定義する場合は以下の制限事項を考慮します。
ポリシーが有効かどうかにかかわらず、複数のポリシーに同じ属性を含めることができません。
  • 複数のルールが同じグローバル コレクションに適用される場合、それらのルールは同じ設定ターゲットを使用できません。1 つのルールを複数のグローバル コレクションに適用することはできますが、
    同じ
    設定ターゲットを使用する 2 つの
    異なる
    ルールを
    同じ
    グローバル コレクションに適用することはできません。
これらの制限を適所に配置することで、ポリシー定義内での競合を容易に防ぐことができます。
内部属性
Policy Manager は
CA Spectrum
内部属性を変更および適用するように設計されていますが、特定の属性の変更については Policy Manager を使用しないでください。
一部の属性は
CA Spectrum
の動作を制御およびカスタマイズするために使用され、カスタマイズについてはドキュメントに説明があります。これらの属性は、結果が予測される場合、Policy Manager ポリシーに含めることができます。
他の属性(Link_Condition 属性など)の値は、
CA Spectrum
モデル内で自動的に変化するか、またはステータスを示すだけとなります。これらの属性は、モデリングされたデバイスからポーリングされた場合、または値の計算に関与する他の属性変更に応じてポーリングされた場合に値を変更します。このような自動的な属性値への上書きは予測不能の動作につながる可能性があります。これらの属性を変更する場合は Policy Manager を使用しないでください。
外部属性
Policy Manager は、Spectrum 内部属性を適用するように設計されています。ポリシーに外部属性(sysContact、sysLocation、または Firmware_version など)を指定できます。ただし、結果は内部属性の場合と以下のように異なります。
  • 読み取り/書き込みコミュニティ文字列を使用してデバイスをモデリングした場合、ポリシー内の属性値はデバイスに書き込まれます。
  • 読み取り専用コミュニティ文字列を使用してデバイスをモデリングした場合、書き込みは失敗します。
  • SpectroSERVER
    には、書き込みロックがありません。外部属性は、OneClick または
    SpectroSERVER
    によって変更できます。
  • デバイス上の属性は他の手段(デバイスとの telnet/ssh など)によって変更することもできます。次回ポリシーを再度有効化すると、ポリシー内の属性値が再度適用されます。