アプリケーション テンプレート

Nexus ダッシュボード オーケストレータ では、それぞれ特定の目的のために設計されたアプリケーション テンプレートとも知られている 3 種類のスキーマ テンプレートを使用できます。

• ACI マルチクラウド — Cisco ACI オンプレミスおよびクラウド サイトに使用されるテンプレート。このテンプレートは、次の 2 つの展開タイプをサポートしています。

  • [マルチサイト（Multi-Site）]：テンプレートは、単一のサイト（サイトローカル ポリシー）または複数のサイト（拡張ポリシー）に関連付けることができます。マルチサイト ネットワーク（ISN）または複数のサイトの間にテンプレートとオブジェクト ストレッチングを許可するために VXLAN サイト間通信用にオプションを選択する必要があります。

  • [自律（Autonomous）]：テンプレートは、独立して運用され、サイト間ネットワークを介して接続されていない（サイト間 VXLAN 通信なしの）1 つ以上のサイトに関連付けることができます。

    自律 サイトは、孤立されていると定義されていてサイト間接続が一切ないので、サイトに渡ってシャドウ オブジェクト 構成はありません。そしてpctag のクロスプログラムまたは、サイト間トラフィック フローのスパイン スイッチ内に VNID はありません。

    自律 テンプレートは、かなり高い展開拡張を許可します。

  次のセクションでは、主にこのタイプのテンプレートに焦点を当てます。

• [NDFC]：Cisco Nexus Dashboard ファブリック コントローラ（以前のデータセンター ネットワーク マネージャ）サイト用に設計されたテンプレート。

  このガイドでは、オンプレミスの Cisco ACI ファブリック向けの Nexus Dashboard Orchestrator 構成について説明しています。Cisco NDFC サイトの操作については、代わりに『Cisco Nexus Dashboard Orchestrator Configuration Guide for NDFC Fabrics』を参照してください。

• [クラウド ローカル（Cloud Local）]：Google Cloud サイト接続など、特定のクラウド ネットワーク コントローラのユース ケース向けに設計されたテンプレートであり、複数のサイト間で拡張することはできません。

  このガイドでは、オンプレミスの Cisco ACI ファブリック向けの Nexus Dashboard Orchestrator 構成について説明しています。クラウド ネットワーク コントローラ ファブリックの操作については、代わりに Nexus Dashboard Orchestrator のユース ケース ライブラリを参照してください。

スキーマとアプリケーション テンプレートを作成するときは、次の単純なアプローチのいずれかを採用することを選択できます。

• [単一テンプレートの展開（Single Template Deployment）]

  スキーマ設計の最も簡単なアプローチは、単一のスキーマで単一のテンプレートを導入することです。単一のテンプレートを含む単一のスキーマを作成し、そのテンプレートにすべての VRF、ブリッジドメイン、EPG、コントラクト、およびその他の要素を追加して、1 つまたは複数のサイトに展開することができます。

  Multi-Site スキーマを作成する最も簡単な方法は、同じスキーマとテンプレート内にすべてのオブジェクトを作成することです。ただし、サポートされているスキーマの数に制限があるため、このアプローチは大規模な展開に適していない場合があります。これは、これらの制限を超える可能性があります。

  また、このアプローチでは、テンプレートで定義されたすべてのオブジェクトが「ストレッチ オブジェクト」になり、テンプレートに加えられたすべての変更が、そのようなテンプレートに関連付けられたすべてのサイトに常に同時に展開されることに注意してください。

• [ネットワーク分離での複数テンプレート（Multiple Templates with Network Separation）]

  スキーマ設計のもう 1 つのアプローチは、ネットワーク オブジェクトをアプリケーション ポリシー設定から分離することです。ネットワーク オブジェクトには、VRF、ブリッジ ドメイン、サブネットなどがあり、アプリケーションポリシーオブジェクトには EPG 、コントラクト、フィルタ、外部 EPG、およびサービス グラフが含まれます。

  最初に、ネットワーク要素を含むスキーマを定義します。すべてのネットワーク要素を含む単一のスキーマを作成するか、または、それらを参照するアプリケーション、またはネットワークが拡張するサイトに基づいて、複数のスキーマに分割します。

  その後、各アプリケーションのポリシー オブジェクトを含む、1 つ以上の個別のスキーマを定義します。この新しいスキーマは、前のスキーマで定義されたブリッジ ドメインなどのネットワーク要素を参照できます。

  ポリシー スキーマとテンプレートを作成して展開すると、ネットワーク スキーマのネットワーキング オブジェクトに、ポリシー スキーマ要素による外部参照の数が表示されます。外部参照を含むオブジェクトは、リボンのアイコンでも示されます。

  この方法で設計されたスキーマは、ネットワーキング オブジェクトをポリシー オブジェクトから論理的な分離します。ただし、これにより、各スキーマで外部参照されたオブジェクトの追跡はさらに複雑になります。

• [オブジェクトの関係性に基づく複数テンプレート（Multiple Templates Based On Object Relationships）]

  共有オブジェクト参照を使用して複数のスキーマを設定する場合、それらのオブジェクトを変更する際に注意を払うことが大切です。たとえば、共有ネットワーク オブジェクトを変更または削除すると、1 つ以上のサイトのアプリケーションに影響を与える可能性があります。そのため、サイトとそのアプリケーションで使用されているオブジェクト (VRF、BD、EPG、コントラクト、フィルタなど) のみを含む、個々のサイトのためのテンプレートを作成するのがよいでしょう。それから、共有オブジェクトを含む別のテンプレートを作成します。

  例えば、サイト1 にローカルなオブジェクトとそのサイトだけに展開されているテンプレートのみを含む[サイト（Site1）] テンプレートを作成することができます。同様に、 [サイト2 （site2）]テンプレートには Site2 に関連するオブジェクトのみが含まれており、そのサイトのみに展開されます。これらのテンプレートのいずれかのオブジェクトに変更を加えても、他のテンプレートのオブジェクトには影響しません。そして、サイト間で共有されているオブジェクトが含まれる共有 テンプレートを作成することができます。

  このシナリオは、次のテンプレート レイアウトを持つ追加サイトに拡張できます。

  • サイト 1 テンプレート

  • サイト 2 テンプレート

  • サイト 3 テンプレート

  • サイト 1 と 2 の共有テンプレート

  • サイト 1 と 3 の共有テンプレート

  • サイト 2 と 3 の共有テンプレート

  • すべての共有テンプレート

  同様に、展開されているサイトに基づいてオブジェクトを分離するのではなく、個々のアプリケーションに基づいてスキーマとテンプレートを作成することもできます。これにより、各アプリケーション プロファイルを簡単に特定し、それらをスキーマとサイトにマッピングし、さらには各アプリケーションをローカルまたは拡張されたサイト全体のものとして設定することができます。

  ただし、これはスキーマごとのテンプレート数の制限（使用しているリリースの Verified Scalability Guide に記載）をすぐに越えてしまう可能性があるため、複数の組み合わせに対応するために追加のスキーマを作成することが必要になります。これにより、複数のスキーマとテンプレートが追加され、さらに複雑になりますが、サイトまたはアプリケーションに基づいてオブジェクトを正確に分離できます。

ファブリック ポリシー テンプレート

リリース 4.0（1）では、3 種類のアプリケーション テンプレートに加えて、ファブリック全体のポリシー用に設計された 3 つの新しいテンプレートが追加されています。

• [ファブリック ポリシー（Fabric Policies）] テンプレートは、次のファブリック全体のポリシーの管理に使用できます。

  • VLAN Pool

  • 物理ドメイン

  • SyncE インターフェイス ポリシー

  • インターフェイス設定

  • ノード 設定

  • ポッド設定

  • MACsec

  • NTP ポリシー

  • PTP ポリシー

  • QoS DSCP ポリシー

  • QoS SR-MPLS ポリシー

  • QoS クラス ポリシー

  詳細については、ファブリック ポリシーを作成 を参照してください。

• [ファブリック情報技術ポリシー（Fabric Resource Policies）] テンプレートは、次のファブリック全体のポリシーの管理に使用できます。

  • 物理インターフェイス

  • ポート チャネル インターフェイス

  • 仮想ポート インターフェイス

  • ノードプロファイル

  これらのテンプレート参照ポリシーはファブリック ポリシー テンプレートで定義されているため、これらのテンプレートを最初に作成して展開する必要があります。詳細については、ファブリック 技術情報 ポリシーを作成 を参照してください。

• [モニタリング ポリシー（Monitoring Policy）] テンプレートは、[テナント SPAN（Tenant SPAN）] または [アクセス SPAN（）] ポリシーの管理に使用できます。

  詳細については、モニタリング ポリシーを作成 を参照してください。

テンプレート デザイン ベストプラクティス

リリース 4.0(1) 以降、Nexus Dashboard Orchestrator は、テンプレートの設計と展開に関して、いくつかのベスト プラクティスを検証して適用します。作成するテンプレートの種類に関係なく、次の点に注意してください。

• すべてのポリシー オブジェクトは、依存関係に応じた順序で[展開（deployed）]する必要があります。

  たとえば、ブリッジ ドメイン（BD）を作成するときは、それを VRF に関連付ける必要があります。この場合、BD には VRF 依存関係があるため、VRF は BD の前または一緒にファブリックに展開する必要があります。これらの 2 つのオブジェクトが同じテンプレートで定義されている場合、Orchestrator は展開時に VRF が最初に作成され、ブリッジ ドメインに関連付けられるようにします。

  ただし、これら 2 つのオブジェクトを別々のテンプレートで定義し、最初に BD を使用してテンプレートを展開しようとすると、関連付けられている VRF がまだ展開されていないため、Orchestrator は検証エラーを返します。この場合、最初に VRF テンプレートを展開してから、BD テンプレートを展開する必要があります。

• すべてのポリシー オブジェクトは、依存関係に応じた順序で[展開解除（undeployed）]する必要があります。展開された順序と逆の順序で展開する必要があります。

  上記の結果から、テンプレートを展開解除するときは、他のオブジェクトが依存しているオブジェクトを展開解除してはなりません。たとえば、VRF が関連付けられている BD を展開解除する前に、VRF を展開解除することはできません。

• 複数のテンプレートにまたがる循環的な依存関係は許可されません。

  ブリッジ ドメイン ( bd1 ) に関連付けられた VRF ( vrf1 ) の場合を考えてみます。これは、次に EPG ( epg1 ) に関連付けられます。[テンプレート 1（template1）] に vrf1 を作成してそのテンプレートをデプロイし、次に [テンプレート 2（template2）] に bd1 を作成してそのテンプレートをデプロイすると、オブジェクトが正しい順序でデプロイされるため、検証エラーは発生しません。ただし、その後 [テンプレート1（template1）] に epg1 を作成しようとすると、2 つのテンプレート間に循環依存関係が作成されるため、Orchestrator は、EPG の [テンプレート1（template1）] 追加を保存することを許可しません。

例

スキーマ内のテンプレートの表示名を更新する簡単な例を使用して、 PUT または PATCH コールでバージョンチェック属性を使用する方法を示します。

最初に、変更するスキーマを GET します。これにより、コールの応答で現在の最新バージョンのスキーマが返されます。

{
    "id": "601acfed38000070a4ee9ec0",
    "displayName": "Schema1",
    "description": "",
    "templates": [
        {
            "name": "Template1",
            "displayName": "current name",
            [...]
        }
    ],
    "_updateVersion": 12,
    "sites": [...]
}

次に、リクエスト URL に、2 つの方法のいずれかで、enableVersionCheck = true を追加して、スキーマを変更します。

（注）	ペイロードの _updateVersion フィールドの値が、元のスキーマで取得した値と同じであることを確認する必要があります。

• PUT API を使用して、更新されるスキーマ全体ペイロードとします。

  PUT /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

  {
      "id": "601acfed38000070a4ee9ec0",
      "displayName": "Schema1",
      "description": "",
      "templates": [
          {
              "name": "Template1",
              "displayName": "new name",
              [...]
          }
      ],
      "_updateVersion": 12,
      "sites": [...]
  }

• PATCH API 操作のいずれかを使用して、スキーマ内のオブジェクトの 1 つに特定の変更を加えます。

  PATCH /v1/schemas/601acfed38000070a4ee9ec0?enableVersionCheck=true

  [ 
      {
          "op": "replace", 
          "path": "/templates/Template1/displayName", 
          "value": "new name",
          "_updateVersion": 12
      }
  ]

リクエストが行われると、APIは現在のスキーマバージョンを 1 ずつ増やし（12 から 13 など）、新しいバージョンのスキーマの作成を試みます。（enableVersionCheck が有効で）新しいバージョンがまだ存在しない場合、操作は成功し、スキーマは更新されます。別の API コールまたは UI がその間にスキーマを変更していた場合、操作は失敗し、API コールは次の応答を返します。

{
    "code": 400,
    "message": "Update failed, object version in the DB has changed, refresh your client and retry"
}

APIC ドメインに実際に展開された構成が、Nexus Dashboard Orchestrator（NDO）でそのドメインに対して定義された構成と異なる場合があります。これらの構成の不一致は、[構成のばらつき（Configuration Drifts）] と呼ばれ、次の図に示すように、テンプレート ビュー ページのサイト名の横に[同期されていません（Out of Sync）]の注意で示されます。

（注）

場合によっては、NDO によって管理されるオブジェクトのプロパティの構成がサイトのコントローラで直接変更された場合、上記の構成ドリフトのテンプレート レベルの通知がトリガーされないことがあります。具体的には、次のプロパティの追加（およびその後の削除）では、NDO でドリフト通知が表示されません。 EPG または BD のサブネット ブリッジ ドメインの DHCL ラベル EPG の静的ポート構成 EPG 間の契約関係 このような場合でも、アプリケーション テンプレートにおける構成のずれの調整で説明されているように、ドリフト調整ワークフローを手動で実行することで、構成のドリフトを確認できます。 NDO からテンプレートを展開すると、そのテンプレート内のオブジェクトのドリフト通知が 60 秒間無効になります。

構成のばらつきの原因

設定のばらつきは、さまざまな理由で発生する可能性があります。構成のばらつきを解決するために必要な実際の手順は、その原因によって異なります。最も一般的なシナリオとその解決策を次に示します。

• NDO で設定が変更された：NDO GUIでテンプレートを変更すると、変更をサイトに展開するまでは、設定のばらつきとして表示されます。

  このタイプの設定のずれを解決するには、テンプレートを展開して変更をサイトに適用するか、スキーマの変更を元に戻します。

• 設定がサイトの APIC で直接変更された：NDO から展開されたオブジェクトは、サイトの APIC で警告アイコンとテキストで示されます。管理ユーザー、設定のずれの原因に対し、引き続き変更を加えられます。

  （注）

  APIC でオブジェクトが変更されるたびに、APIC は Nexus Dashboard Orchestrator に通知を送信します。通知を受信すると、Nexus Dashboard Orchestrator は 30 秒のタイマーを開始し（さらに通知が届くのを待ちます）、そのようなタイマーの期限が切れると、APIC への API 呼び出しを実行して、通知を受信したすべてのオブジェクトに加えられた変更に関する詳細情報を取得します。これにより、Nexus Dashboard Orchestrator は、それらのオブジェクトが定義されているすべてのテンプレートの UI にばらつきのシンボルを表示できます。この動作の唯一の例外は、Nexus Dashboard Orchestrator が、特定のテンプレートで定義されたオブジェクトのすべて（またはそのサブセット）の構成を展開する場合です。その場合、60 秒間、Nexus Dashboard Orchestrator は、それらの特定のオブジェクトに関して APIC から受信した通知を無視し、その結果、UI にばらつきのシンボルを表示できません。

• NDO 設定がバックアップから復元された：NDO のバックアップから設定を復元すると、バックアップが作成されたときのオブジェクトとその状態のみが復元され、復元された設定は自動的に再展開されません。そのため、バックアップが作成されてから構成に変更が加えられ、APIC に展開された場合、バックアップを復元すると構成のばらつきが作成される可能性があります。

• NDO 設定は、古いリリースで作成されたバックアップから復元された：新しいリリースで、以前のリリースではサポートされていなかったオブジェクト プロパティのサポートが追加された場合、これらのプロパティによって設定がずれる可能性があります。通常、これは、サイトの APIC GUI で新しいプロパティが直接変更され、Nexus Dashboard Orchestrator の想定値がデフォルトと異なる場合に発生します。

• NDO が以前のリリースからアップグレードされた：このシナリオは、新しいオブジェクト プロパティが新しいリリースに追加された場合に、既存の設定がずれている可能性がある、前のシナリオと似ています。

構成ドリフトを確認することをお勧めし、必要ならば、ドリフトの原因に対してもっと可視化して調整するためにテンプレートの「ばらつきの調整」ワークフローを実行します。この推奨事項は、このセクションで前述したすべてのばらつきのシナリオに適用されます。