スキーマとテンプレート設計上の考慮事項
Nexus ダッシュボード オーケストレータには、1 つ以上のポリシーを一緒に定義し、それらを 1 つ以上のサイトに同時に展開できる多数のポリシー テンプレートが用意されています。これらには、テナント ポリシー テンプレート、ファブリックおよびファブリック 情報技術 ポリシー テンプレート、モニタリング テンプレートおよびアプリケーション テンプレートが含まれます。スキーマは、アプリケーション ポリシーの定義に使用されるアプリケーション テンプレートの集合であり、各テンプレートは特定のテナントに割り当てられます。展開の使用例に固有のスキーマとアプリケーション テンプレートの構成を作成する際に、複数のアプローチを実行できます。ここでは、マルチサイト環境でスキーマ、テンプレート、およびポリシーを定義する方法を決定する際に実行できる、いくつかの簡単な設計方針について説明します。
スキーマを設計する際には、スキーマ、テンプレート、およびスキーマあたりのオブジェクトの数に対してサポートされているスケーラビリティ制限を考慮する必要があることに注意してください。検証済みスケーラビリティ制限の詳細については、お使いのリリースの『Cisco Multi-Site Verified Scalability Guides』を参照してください。
アプリケーション テンプレート
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 ダッシュボード オーケストレータは、テンプレートの設計と展開に関して、いくつかのベスト プラクティスを検証して適用します。作成するテンプレートの種類に関係なく、次の点に注意してください。
-
すべてのポリシー オブジェクトは、依存関係に応じた順序で[展開（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）]追加を保存することを許可しません。
フィードバック