テンプレートの概要と操作

スキーマとテンプレート設計上の考慮事項

Nexus ダッシュボード オーケストレータには、1 つ以上のポリシーを一緒に定義し、それらを 1 つ以上のサイトに同時に展開できる多数のポリシー テンプレートが用意されています。これらには、アプリケーション テンプレート、テナント ポリシー テンプレート、ファブリック ポリシーおよびファブリック リソース ポリシー テンプレート、モニタリング テンプレートが含まれます。スキーマは、アプリケーション ポリシーの定義に使用されるアプリケーション テンプレートの集合であり、各テンプレートは特定のテナントに割り当てられます。スキーマはアプリケーション テンプレートのみに適用されます。展開の使用例に固有のテンプレートの構成を作成する際に、複数のアプローチを実行できます。ここでは、マルチサイト ドメインでスキーマ、テンプレート、およびポリシーを定義する方法を決定する際に実行できる、いくつかの簡単な設計方針について説明します。

スキーマを設計する際には、スキーマ、テンプレート、およびスキーマあたりのオブジェクトの数に対してサポートされているスケーラビリティ制限を考慮する必要があることに注意してください。検証済みスケーラビリティ制限の詳細については、お使いのリリースの『Nexus Dashboard Orchestrator 検証済みスケーラビリティ ガイド』を参照してください。

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

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)] 追加を保存することを許可しません。

設定の同時更新

Nexus ダッシュボード オーケストレータ GUI は、同じサイトまたはスキーマオブジェクトでの同時更新が意図せずに相互に上書きされることがないようにします。自分が開いた後に別のユーザによって更新されたサイトまたはテンプレートに変更を加えようと、GUI はそれ以降の変更を拒否し、追加の変更を行う前にオブジェクトを更新するように求める警告を表示します。テンプレートを更新すると、その時点までに行った編集内容は失われるため、再度変更する必要があります。

ただし、既存のアプリケーションとの下位互換性を維持するために、デフォルトの REST API 機能は変更されていません。つまり、UI はこの保護を常に有効にしていますが、設定変更を追跡するためには、NDO の API コールに対しても明示的に有効にする必要があります。


(注)  


この機能を有効にする場合は、次の点に注意してください。

  • このリリースでは、サイト オブジェクトとスキーマ オブジェクトの競合する設定変更の検出のみがサポートされています。

  • PUT および PATCH API コールのみがバージョンチェック機能をサポートします。

  • API コールでバージョン チェック パラメータを明示的に有効にしていない場合、NDO は内部的に更新を追跡しません。その結果、設定の更新は、後続の API コールまたは GUI ユーザの両方によって上書きされる可能性があります。


設定のバージョン チェックを有効にするには、使用している API エンドポイントの末尾に enableVersionCheck = true パラメータを追加して、API コールにこのパラメータを渡します。次の例をご覧ください。

https://<mso-ip-address>/mso/api/v1/schemas/<schema-id>?enableVersionCheck=true

スキーマ内のテンプレートの表示名を更新する簡単な例を使用して、 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"
}

サイトへのテンプレートの割り当て

ここでは、サイトにテンプレートを割り当てる方法について説明します。

始める前に

このドキュメントの前のセクションで説明したように、作成されたサイトには、展開するスキーマ、テンプレート、およびオブジェクトが必要です。

手順


ステップ 1

展開する 1 つ以上のテンプレートを含むスキーマに移動します。

ステップ 2

左側のサイドバーで、サイトに割り当てるテンプレートを選択します。

ステップ 3

[テンプレート プロパティ(Template Properties)] 表示内で [アクション(Actions)] をクリックして [サイトの関連付け(Sites Association)] を選択します。

[ <template-name> にサイトの関連付け(Associate Sites to <template-name>)] ウィンドウが開きます。

ステップ 4

[サイトの関連付け(Associate Sites)] ウィンドウで、テンプレートを展開するサイトの横のチェックボックスをオンにします。

選択したテンプレートのタイプとサイト間のサイト間接続によっては、一部のサイトを割り当てに使用できない場合があることに注意してください。

  • クラウド ローカル テンプレートを割り当てる場合は、単一のクラウド サイトにのみ割り当てることができます。

  • テンプレートを複数のサイトに割り当てる場合、BGP-EVPN プロトコルを使用して、それらのサイト間のサイト間接続を確立する必要があります。パーシャル メッシュ接続があるサイトを選択した場合、サイト間接続がないサイト、または BGP-IPv4 を使用してサイト間接続が確立されているサイトはグレー表示され、割り当てに使用できません。

ステップ 5

[OK] をクリックします。

一度に 1 つのテンプレートを展開するため、展開できるようにするには、少なくとも 1 つのサイトにテンプレートを関連付ける必要があります。


サイトからのテンプレートの関連付け解除

展開を解除せずに、サイトからテンプレートの関連付けを解除することもできます。これにより、NDO からサイトに展開された設定を保持しながら、スキーマのテンプレートとサイトの関連付けを削除できます。管理対象オブジェクトとポリシーの所有権が NDO からサイトのコントローラに移されます。

始める前に

  • テンプレートとその設定がサイトにすでに展開されている必要があります。

  • テンプレートは、単一のサイトにのみ展開し、サイト間で展開しないようにする必要があります。

  • テンプレートで定義されたオブジェクトは、他のサイトのシャドウ オブジェクトとして展開しないでください。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

関連付けを解除するテンプレートを含むスキーマをクリックします。

ステップ 4

スキーマ ビューで、関連付けを解除する特定のサイトの下のテンプレートを選択します。

ステップ 5

[アクション (Actions)] メニューから [テンプレートの関連付け解除 (Disassociate Template)] を選択します。

ステップ 6

確認ウィンドウで、[アクションの確認 (Confirm Action)] をクリックします。


テンプレートの展開

ここでは、新しいポリシーまたは更新されたポリシーを ACI ファブリックに展開する方法について説明します。

始める前に

  • このドキュメントの前のセクションで説明したように、作成されたサイトには、展開するスキーマ、テンプレート、およびオブジェクトと、1 つまたは複数のサイトに割り当てられるテンプレートが必要です。

  • テンプレートのレビューと承認で説明しているように、テンプレートの確認と承認が有効になっている場合は、必要な数の承認者によってテンプレートがすでに承認されている必要があります。

  • スキーマとテンプレート設計上の考慮事項で説明されている必要な展開の順序とオブジェクトの依存関係を理解していることを確認してください。

手順


ステップ 1

展開するテンプレートを含むスキーマに移動します。

ステップ 2

[表示(View)] ドロップダウン メニューから、展開するテンプレートを選択します。

ステップ 3

テンプレート ビューで、[サイトに展開(Deploy to site)] をクリックします。

[サイトに展開 (Deploy to Sites)] ウィンドウが開き、展開するオブジェクトの概要が表示されます。

ステップ 4

テンプレートに変更を加えた場合は、[展開の計画(Deployment Plan)] を確認して新しい構成を確認します。

以前にこのテンプレートを展開したが、それ以降に変更を加えていない場合は、[展開] の概要に変更がないことが示され、テンプレート全体を再展開することを選択できます。この場合は、この手順をスキップできます。

[サイトに展開 (Deploy to Sites)] ウィンドウには、サイトに展開される構成の違いの概要が表示されます。次のスクリーンショットは、サイト 2 の既存の EPG(EPG1-S2)にコンシューマコントラクトを追加する簡単な例を示しています。

(注)  

 

この場合、構成の違いのみがサイトに展開されます。テンプレート全体を再展開したい場合、違いを同期するために1 回展開をする必要があります。そして、前のパラグラフに記されている通り、構成全体をプッシュするためにまた再展開する必要があります。

情報目的で [作成日 (Created)][変更日 (Modified)]、および [削除済み (Deleted)] チェックボックスを使用してビューをフィルタリングすることもできますが、[展開 (Deploy)]をクリックするとすべての変更が展開されることに注意してください。

ここでは、次のことも選択できます。

  • [バージョン履歴の表示(View Version History)] を選択すると、完全なバージョン履歴とバージョンアップグレードで行われた更新内容を表示します。バージョン履歴の詳細については、履歴の表示と以前のバージョンの比較を参照してください。

  • [展開プラン (Deployment Plan)]を確認して、このテンプレートから展開される構成の可視化と XML ペイロードを表示します。

    この機能により、テンプレートに変更を加えて 1 つ以上のサイトに展開した後に、Orchestrator がマルチサイトドメインの一部であるさまざまなファブリックにプロビジョニングする構成の変更を、より適切に可視化できます。

    テンプレートとサイト構成に加えられた特定の変更のリストを引き続き提供していた Nexus Dashboard Orchestrator の以前のリリースとは異なり、展開プランでは、テンプレートの展開によってさまざまなファブリック全体にプロビジョニングされる、すべてのオブジェクトに対する完全な可視性が提供されます。たとえば、変更内容によっては、特定の変更が 1 つのサイトのみに適用された場合でも、シャドウオブジェクトが複数のサイトに作成される場合があります。

    (注)  

     

    テンプレートを展開する前に、この手順で説明されているように、展開プランを使用して変更を確認することをお勧めします。構成変更の視覚的に示すことは、意図しない構成変更の展開による潜在的なエラーを低減するのに役立ちます。

  1. [展開プラン(Deployment Plan)] ボタンをクリックします。

    前のステップで示したのと同じ例で続けると、コンシューマコントラクトがサイト 2 の既存の EPG に追加され、展開計画では、サイト 2 への変更の結果として、サイト 1 に展開される追加の変更があることも確認できます。

  2. 最初にリストされたサイトで変更を確認します。

    強調表示された凡例に基づいて、Orchestrator がサイト 2 の EPG に追加したコントラクトに必要なシャドウ オブジェクトをサイト 1 に作成することがわかります。

  3. 前のサブステップを繰り返して、他のサイトの変更を確認します。

    ここでは、コントラクト(C1-EFT)をサイト 2 に割り当てたときに、サイト 2 の EPG(EPG1-S2)に明示的に加えた変更と、そのコントラクトを提供している他のサイトの EPG(EPG1-S1)のシャドウオブジェクトを確認できます。

  4. (オプション)[ペイロードの表示(View Payload)] をクリックすると、各サイトの XML ペイロードを表示できます。

    新規および変更されたオブジェクトの視覚的表現に加えて、各サイトの変更について [ペイロードの表示(View Payload)] を選択することもできます。

  5. 変更の確認が完了したら、[X] アイコンをクリックして [展開プラン(Deployment Plan)] 画面を閉じます。

ステップ 5

[サイトに展開(Deploy to sites)] ウィンドウで、[展開(Deploy)] をクリックしてテンプレートを展開します。


テンプレートの展開解除

ここでは、サイトからテンプレートを展開解除する方法について説明します。テンプレートを展開解除すると、そのテンプレートで定義されているすべての構成がテンプレートが展開されている特定のサイトから削除されます。


(注)  


このアクションにより、管理対象オブジェクト(MO)とそのプロパティがサイトのコントローラから削除され、それらの構成に依存するネットワーク接続が中断される可能性があります。


始める前に

  • テンプレートを最後に展開してから、テンプレートに変更を加えていないことを確認します。

    最後に展開された後に変更されたテンプレートを展開解除すると、テンプレートに展開されたオブジェクトのセットが、テンプレートに変更を加えた後に展開解除しようとするオブジェクトのセットと異なるため、設定がずれる可能性があります。

  • ルート リーク構成で使用される VRF を含むテンプレートを展開解除する場合、そのテンプレートを展開解除する前に、ルート リークを削除する必要があります。

手順


ステップ 1

展開解除するテンプレートを含むスキーマを選択します。

ステップ 2

[表示(View)] ドロップダウンから、展開を解除するテンプレートを選択します。

ステップ 3

[アクション(Action)] メニューで、[すべてのサイトから展開を解除する(Undeploy from all sites)] をクリックします。


テンプレート オブジェクトの一括更新

一括更新機能を使用すると、テンプレート内の同じタイプの複数の異なるオブジェクトの複数のプロパティを一度に更新できます。たとえば、各オブジェクトを個別に変更する代わりに、同時に 2 つ以上の EPG にインフラ EPG 分離を適用できます。このワークフローを使用する場合、選択したすべてのオブジェクトは同じタイプである必要があります。たとえば、EPG と BD を同時に更新することはできません。

選択したオブジェクトにすでに別のプロパティ値が構成されている場合、更新により、それらのプロパティが指定した値で上書きされます。この機能により、オンプレミスのテンプレート レベルのオブジェクト プロパティを更新できます。サイトローカル プロパティとクラウド プロパティの更新はサポートされていません。


(注)  


この機能は、Cisco APIC および Cisco NDFC ファブリックのみのアプリケーション テンプレートでのみサポートされます。他のテンプレート タイプまたは Cisco Cloud Network Controller サイトではサポートされていません。


手順


ステップ 1

更新するオブジェクトが含まれているスキーマとテンプレートに移行します。

ステップ 2

メインのペインから、[選択(Select)] を選択します。同じタイプのオブジェクトを複数選択できます。

ステップ 3

更新するすべてのオブジェクトを選択した後。

  1. キャンセル オプションの横にある […] を選択します。

  2. ドロップダウンから [編集(Edit)] を選択します。

異なるタイプのオブジェクトを選択した場合、ドロップダウンに [編集(Edit)] オプションは表示されません。

ステップ 4

[編集(Edit)] を選択すると、ポップアップが表示されます。選択したオブジェクトのプロパティのサブセットが表示されます。

選択したオブジェクトのタイプに基づいて、次のプロパティを更新できます。

  1. [EPG]:ブリッジ ドメイン、コントラクト、EPG タイプ、インフラ EPG、優先グループ。

  2. [コントラクト(Contracts)]:範囲、フィルターチェーン、QOS レベル。

  3. [VRF]:IP データ プレーン学習。

  4. [ブリッジ ドメイン(Bridge Domain)]:仮想ルーティングとフォワーワーディング、L2 ストレッチ、L2 不明なユニキャスト、不明なマルチキャスト フラッディング、IPv6 不明なマルチキャスト フラッディング、複数宛先フラッディング、DHCP ポリシー、ユニキャスト ルーティング。

  5. [外部 EPG(External EPG)]:コントラクト、外部 EPG タイプ、優先グループ。

ステップ 5

すべてのフィールドを選択したら、更新します。[保存(Save)] を選択すると、先ほど行った更新が実装されます。

ステップ 6

更新を保存すると、行った変更を確認できます。


テンプレートのバージョニング

テンプレートが保存されるたびに、新しいバージョンのテンプレートが作成されます。NDO UI 内から、テンプレートのすべての設定変更の履歴を、変更者と変更日時に関する情報とともに表示できます。以前のバージョンを現在のバージョンと比較することもできます。

新しいバージョンはスキーマ レベルではなくテンプレート レベルで作成されるため、各テンプレートを個別に設定、比較、ロールバックできます。

テンプレート バージョンは、次のルールに従って作成および管理されます。

  • すべてのテンプレート バージョンは、Deployed または Intermediate のいずれかです。

    Deployed — サイトに展開されたテンプレートのバージョン。

    Intermediate — 変更および保存されたが、サイトに展開されていないテンプレートのバージョン。

  • テンプレートごとに最大 20 の Deployed バージョンと 20 の Intermediate バージョンをいつでも保存できます。

  • 20 バージョンの制限を超える新しい Intermediate バージョンが作成されると、最も古い既存の Intermediate バージョンが削除されます。

  • テンプレートが展開され、新しい Deployed バージョンが作成されると、すべての Intermediate バージョンが削除されます。新しい Deployed バージョンが 20 バージョン制限を超えると、最も古い既存の Deployed バージョンが削除されます。

  • バージョンに Golden のタグを付けても、保存されているテンプレート バージョンの数には影響しません。

  • Golden のタグが付いたテンプレートは削除できません。

    テンプレートを削除する前に、まずタグを解除する必要があります。

  • テンプレートが変更されて保存または展開されると、20 のDeployed および 20 の Intermediate スケールを超えるバージョンは、上記のルールに従って削除されます。

  • 4.0(1) より前のリリースからリリース 4.0(1) 以降にアップグレードする場合、テンプレートの最新バージョンのみが保持されます。

タギング テンプレート

任意の時点で、テンプレートの現在のバージョンに「ゴールデン」のタグを付けることができます。たとえば、完全に検証された設定で確認、承認、および展開されたバージョンを示すために、今後の参照用に選択できます。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

テンプレートのアクション(...)メニューから、[タグ(Tag)] を選択します。

テンプレートがすでにタグ付けされている場合、オプションは [タグを解除(Un-Tag)] に変更され、現在のバージョンからタグを削除できます。

タグ付けされたバージョンは、テンプレートのバージョン履歴画面でスターアイコンで示されます。


履歴の表示と以前のバージョンの比較

ここでは、テンプレートの以前のバージョンを表示し、現在のバージョンと比較する方法について説明します。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

テンプレートのアクション(...)メニューから、[履歴(History)] を選択します。

ステップ 6

[バージョン履歴 (Version History)] ウィンドウで、適切な選択を行います。

  1. [ゴールデン バージョン (Golden Versions)] チェックボックスをオンにして、以前のバージョンのリストをフィルタリングし、Golden としてマークされていたこのテンプレートのバージョンのみを表示します。

    「Golden」としてのテンプレートのタグ付けについては、タギング テンプレートを参照してください。

  2. 以前のバージョンのリストをフィルタリングして、サイトに展開されていたこのテンプレートのバージョンのみを表示するには、[展開済みバージョン (Deployed Versions)]チェックボックスをオンにします。

    新しいテンプレート バージョンは、テンプレートが変更され、スキーマが保存されるたびに作成されます。ある時点でサイトに実際に展開されたテンプレートのバージョンのみを表示するように選択できます。

  3. 特定のバージョンをクリックして、現在のバージョンと比較します。

    選択したバージョンは、常にテンプレートの現在のバージョンと比較されます。[ゴールデンバージョン (Golden Versions)] または [導入済みバージョン (Deployed Versions)] フィルタを使用してリストをフィルタリングした場合でも、導入済みまたはゴールデンとしてタグ付けされていない場合でも、現在のバージョンが常に表示されます。

  4. [編集 (Edit)] アイコンの上にマウスを置くと、バージョンの作成者と作成日時に関する情報が表示されます。

ステップ 7

[OK] をクリックして、バージョン履歴ウィンドウを閉じます。


以前の製品バージョンへの復元

ここでは、以前のバージョンのテンプレートを復元する方法について説明します。テンプレートを元に戻す場合、次のルールが適用されます。

  • ターゲット バージョンが存在しないオブジェクトを参照している場合、復元操作は許可されません。

  • ターゲットバージョンが NDO で管理されなくなったサイトを参照している場合、復元操作は許可されません。

  • 現在のバージョンが、ターゲット バージョンが展開されていない 1 つ以上のサイトに展開されている場合、復元操作は許可されません。

    テンプレートを元に戻す前に、まずそれらのサイトから現在のバージョンを展開解除する必要があります。

  • ターゲット バージョンが、現在のバージョンが展開されていない 1 つ以上のサイトに展開されている場合、復元操作は許可されます。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

[スキーマ (Schema)]ビューで、確認するテンプレートを選択します。

ステップ 5

[アクション(Actions)][...])メニューから、[ロールバック(Rollback)] を選択します。

ステップ 6

[ロールバック(Rollback)] ウィンドウで、復元する以前のバージョンのいずれかを選択します。

[ゴールデン バージョン (Golden Versions)] チェックボックスと[展開済みバージョン (Deployed Versions)] チェックボックスを使用して、バージョンのリストをフィルタリングできます。

バージョンを選択すると、そのバージョンのテンプレート設定をテンプレートの現在のバージョンと比較できます。

ステップ 7

[復元 (Restore) ] をクリックして、選択したバージョンを復元します。

以前のバージョンを復元すると、前の手順で選択したバージョンと同じ設定の新しいバージョンのテンプレートが作成されます。

たとえば、最新のテンプレートバージョンが 3 で、バージョン 2 を復元すると、バージョン 4 が作成されます。バージョン 2 の設定と同じだからです。復元を確認するには、テンプレートのバージョン履歴を参照し、現在の最新バージョンと復元時に選択したバージョンを比較します。

テンプレートのレビューと承認(変更管理)が無効になっており、アカウントにテンプレートを展開するための適切な権限がある場合は、復元したバージョンを展開できます。

ただし、変更制御が有効になっている場合は、次のようになります。

  • 以前に展開したバージョンに戻し、アカウントにテンプレートを展開するための正しい権限がある場合は、すぐにテンプレートを展開できます。

  • 以前に展開されていなかったバージョンに戻す場合、またはアカウントにテンプレートを展開するための適切な権限がない場合は、復元されたバージョンを展開する前にテンプレートの承認を要求する必要があります。

    レビューと承認プロセスに関する追加情報については、テンプレートのレビューと承認セクションを参照してください。


テンプレートのレビューと承認

テンプレートのレビューと承認(変更管理)ワークフローは、テンプレートの設計者、レビュー担当者、承認者、およびテンプレートの導入者に指定されたロールを設定し、また、導入した設定が検証プロセスを確実にパスできるようにします。

テンプレート設計者は、NDO UI 内から、作成したテンプレートのレビューを要求できます。その後、レビュー担当者は、テンプレートのすべての設定変更の履歴と、誰がいつ変更したかに関する情報を表示できます。この時点で、テンプレートの現在のバージョンを承認または拒否できます。テンプレート設定が拒否された場合、テンプレート設計者は必要な変更を行い、レビューを再要求できます。テンプレートが承認されると、展開担当者のロールを持つユーザがサイトに展開できます。最後の点として、導入者自身が承認済みテンプレートの導入を拒否し、レビュー プロセスを最初からやり直すことができます。

ワークフローはスキーマ レベルではなくテンプレート レベルで実行されるため、各テンプレートを個別に設定、確認、承認できます。

テンプレート承認要件の有効化

テンプレートの設定と展開に確認と承認のワークフローを使用するには、Nexus Dashboard Orchestrator のシステム設定でこの機能を有効にする必要があります。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左側のナビゲーション メニューで、[インフラストラクチャ (Infrastructure)] > [システムの設定 (System Configuration)]を選択します。

ステップ 3

[変更制御 (Change Control)] タイルで、[編集 (Edit)] アイコンをクリックします。

ステップ 4

[コントロールを変更(Change Control)] ウィンドウで、[有効(Enabled)] を選択して機能を有効にします。

ステップ 5

[承認者 (Approvers)] フィールドに、テンプレートを展開する前に必要な一意の承認の数を入力します。

ステップ 6

[保存(Save)] をクリックして、変更内容を保存します。


必要なロールを持つユーザの作成

テンプレートの設定と展開のため、レビューと承認のワークフローを実施する前に、NDO サービスが展開されている Nexus ダッシュボードで必要な権限を持つユーザーを作成する必要があります。

手順


ステップ 1

Nexus Dashboard の GUI にログインします。

NDO GUI でユーザーを作成または編集することはできません。サービスが展開されている Nexus ダッシュボード クラスタに直接ログインする必要があります。

ステップ 2

左のナビゲーション メニューから、[管理 コンソール(Admin Console)] > [管理ユーザー(Administrative Users)] > [ユーザー(Users)]を選択します。

ステップ 3

必要なユーザーを作成します。

ワークフローは、テンプレート設計者、承認者、および展開者という 3 つの異なるユーザー ロールに依存します。各ロールを異なるユーザーに割り当てることも、同じユーザーにロールの組み合わせを割り当てることもできます。管理者権限を持つユーザは、3 つのアクションすべてを実行できます。

Nexus Dashboard にはデザイナー ロールが事前定義されていないため、デザイナーの義務は、デフォルトの管理者ユーザーロールに加えて、書き込み権限を持つテナント マネージャーまたはサイト マネージャー ユーザーに割り当てられます。

  • テナント マネージャーは、デザイナーが特定のテナント(またはテナントのサブセット)にのみ関連付けられているテンプレートに変更を加える必要がある場合に使用する必要があります。この場合、ユーザーを特定のテナントにマッピングする必要があります。

  • サイト マネージャーは、デザイナーが異なるテナントに属するテンプレートに変更を加える必要がある場合使用する必要があります。

デザイナー ロールとは対照的に、Nexus Dashboard には、ユーザーに関連付けることができる事前定義された承認者および展開者の役割があります。承認者および展開者のロールは、設計上、特定のテナントにバインドされていません。ただし、デザイナーと承認者(またはデザイナーと展開者)の両方の権限を持つユーザーロールを作成する場合は、上記と同じガイドラインに従ってください。

ローカルまたはリモートの Nexus ダッシュボード ユーザーのユーザーとその権限の設定の詳細については、 『Nexus Dashboard User Guide』を参照してください。

承認者ロールを持つ別個のユーザーが、テンプレート承認要件の有効化で設定した承認の最小数と同数以上必要です。

(注)  

 

変更制御ワークフロー機能を無効にすると、承認者展開者のユーザーは Nexus Dashboard Orchestrator に読み取り専用でアクセスできます。


テンプレートのレビューと承認の要求

ここでは、テンプレートのレビューと承認を要求する方法について説明します。

始める前に

次のものが必要です。

手順


ステップ 1

テナント マネージャサイト マネージャ、または管理者 ロールを持つユーザーとして Nexus Dashboard Orchestrator GUI にログインします。

ステップ 2

テナント マネージャ ロールを割り当てた場合は、ユーザーをテナントに関連付けます。

サイト マネージャ または 管理者 ロールを使用していた場合は、この手順をスキップしてください。

テナント マネージャ ロールを割り当てる場合は、ユーザーが管理する特定のテナントにユーザーを関連付ける必要もあります。

  1. 左型のナビゲーションメニューから、[アプリケーション管理(Application Management)] > > [テナント(Tenants)] を選択します。

  2. ユーザーが管理するテナントを選択します。

  3. Nexus Dashboard で作成したデザイナー ユーザーの横にあるチェックボックスをオンにします。

  4. ユーザーが管理する他のすべてのテナントについて、この手順を繰り返します。

ステップ 3

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 4

承認を要求するテンプレートを含むスキーマをクリックします。

ステップ 5

スキーマビューで、テンプレートを選択します。

ステップ 6

メイン ペインで、[承認のために送信 (Send for Approval)] をクリックします。

[承認のために送信 (Send for Approval)] ボタンは、次の場合には使用できません。
  • グローバル変更制御オプションが有効になっていない

  • テンプレートにポリシー設定がないか、どのサイトにも割り当てられていない

  • ユーザにテンプレートを編集する権限がない

  • テンプレートは承認のためにすでに送信されている

  • テンプレートが承認者ユーザによって拒否された


テンプレートのレビューと承認

ここでは、テンプレートのレビューと承認を要求する方法について説明します。

始める前に

次のものが必要です。

手順


ステップ 1

承認者 (Approver) または管理者 (admin) ロールを持つユーザとして Nexus Dashboard Orchestrator GUIにログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

確認して承認するテンプレートを含むスキーマをクリックします。

ステップ 4

スキーマビューで、テンプレートを選択します。

ステップ 5

メインペインで、[承認 (Approve)] をクリックします。

すでにテンプレートを承認または拒否している場合は、テンプレート デザイナが変更を行い、再確認のためにテンプレートを再送信するまで、このオプションは表示されません。

ステップ 6

[テンプレートの承認 (Approving template)] ウィンドウでテンプレートを確認し、[承認 (Approve)] をクリックします。

承認画面には、テンプレートがサイトに展開するすべての変更が表示されます。

[バージョン履歴の表示 (View Version History)] をクリックすると、完全なバージョン履歴と、バージョン間で行われた増分変更を表示できます。バージョン履歴の詳細については、履歴の表示と以前のバージョンの比較を参照してください。

[展開計画 (Deployment Plan)] をクリックして、このテンプレートから展開される設定の可視化と XML を表示することもできます。[展開計画 (Deployment Plan)] ビューの機能は、現在展開されている設定の表示で説明した、すでに導入されているテンプレートの [展開ビュー (Deployed View)] に似ています。


設定のばらつき

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

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

アプリケーション テンプレートにおける構成のずれの調整

Nexus ダッシュボード オーケストレータへマルチ サイトドメインの一部のサイトの APIC コントローラ内の適用された構成で定義されているようにテンプレートの構成を比べるためにばらつきの調整ワークフローを使用することができます。これにより、Nexus ダッシュボード オーケストレータまたは APIC で直接行われた可能性のある変更をよりよく可視化し、それらのドリフトを正しく解決する機会を提供します。


(注)  


構成のばらつきの調整は、アプリケーション テンプレートでのみサポートされます。

テンプレートは、調整ワークフローの最後に [保存(Save)] または [展開(Deploy)] を選択した後にのみ更新および保存されます。ワークフローの途中で、すでに選択した変更を元に戻したい場合は、スキーマを閉じてから再度開いて、元の構成を復元できます。その後、ワークフローを最初から再実行できます。


手順


ステップ 1

設定のばらつきを確認するテンプレートを含むスキーマに移動します。

ステップ 2

テンプレートの [アクション (Actions)] メニューから、[ばらつきの調整 (Reconcile Drift)] を選択します。

[ばらつきの調整 (Reconcile Drift)] ウィザードが開きます。

ステップ 3

[ばらつきの調整 (Reconcile Drift)] 画面で、各サイトのテンプレートレベルの構成を比較し、希望のものを選択します。

テンプレートレベルのプロパティは、テンプレートに関連付けられているすべてのサイトに共通です。Nexus Dashboard Orchestrator で定義されたテンプレート レベルのプロパティを各サイトでレンダリングされた構成と比較し、Nexus Dashboard Orchestrator テンプレートの新しい構成を決定できます。サイト構成を選択すると、既存の Nexus Dashboard Orchestrator テンプレート内のこれらのプロパティが変更されますが、Nexus Dashboard Orchestrator 構成を選択した場合は、既存の Nexus Dashbaord Orchestrator テンプレートの設定はそのまま保持されます。

ステップ 4

[サイト特有のプロパティに移動(Go to Site Specific Properties)] をクリックして、サイトレベルの構成に切り替えます。

特定のサイトの構成を比較するために、サイトを選択できます。テンプレートレベルの設定とは異なり、各サイトの Nexus Dashboard Orchestrator 定義または実際の既存の設定を個別に選択して、そのサイトのテンプレートのサイトローカル プロパティとして保持できます。

ほとんどのシナリオでは、テンプレートレベルとサイトレベルの両方の構成で同じ選択を行いたとしても、ばらつきの調整ウィザードでは、サイトのコントローラで「テンプレートのプロパティ」レベルで定義された構成と Nexus Dashboard Orchestratorで定義された構成またはその逆を選択できます。

ステップ 5

[変更のプレビュー(Preview Changes)] をクリックして、選択内容を確認します。

プレビューは [ばらつきの調整 (Reconcile Drift)] ウィザードの選択肢に基づいて調整された完全なテンプレート構成を表示します。その後、[サイトに展開(Deploy to site)] をクリックして構成を展開し、そのテンプレートのばらつきを調整できます。


テンプレートの複製

ここでは、スキーマ ビューで [テンプレートの複製 (Clone Template)]機能を使用して既存のテンプレートのコピーを作成する方法について説明します。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

複製するテンプレートを含むスキーマをクリックします。

ステップ 4

[表示(View)] メニューで、テンプレートを選択して開きます。

ステップ 5

[アクション (Actions)] メニューから [テンプレートのクローン (Clone Template)] を選択します。

ステップ 6

クローンの複製先の詳細を入力します。

  1. [複製先スキーマ (Destination Schema)]ドロップダウンから、テンプレートのクローンを作成するスキーマの名前を選択します。

    このテンプレートのクローンを含めるために、同じスキーマまたは異なるスキーマを選択できます。まだ存在しないスキーマにテンプレートを複製する場合は、スキーマの名前を入力し、[作成 (Create) <schema-name>]オプションを選択して新しいスキーマを作成できます。

    (注)  

     

    異なるスキーマ間で複製する場合、テンプレートには他のテンプレートのオブジェクトを参照するオブジェクトを含めることはできません。

  2. [テンプレート名(Template Name)] フィールドに、テンプレートの名前を入力します。

  3. [保存 (Save)] をクリックして、クローンを作成します。

    新しいテンプレートが、選択したテナントと元のテンプレートとまったく同じオブジェクトおよびポリシー設定で複製先スキーマに作成されます。

    選択した複製先スキーマがソーステンプレートと同じスキーマである場合、スキーマ ビューがリロードされ、新しいテンプレートが左側のサイドバーに表示されます。別のスキーマを選択した場合は、そのスキーマに移動して新しいテンプレートを表示および編集できます。

    テンプレート オブジェクトと設定はコピーされますが、サイトの関連付けは保持されないため、複製したテンプレートを展開するサイトに再度関連付ける必要があります。同様に、テンプレート オブジェクトをサイトに関連付けた後に、テンプレート オブジェクトのサイト固有の設定を指定する必要があります。


テンプレート間でのオブジェクトの移行

ここでは、テンプレートまたはスキーマ間でオブジェクトを移動する方法について説明します。1 つ以上のオブジェクトを移動すると、次の制約事項が適用されます。

  • テンプレート間で移動できるのは、EPG および Bridge Domain (BD) オブジェクトのみです。

  • クラウド ネットワーク コントローラ サイトとの間でのオブジェクトの移行はサポートされていません。

    オンプレミスサイト間でのみオブジェクトを移行できます。

  • 送信元と宛先のテンプレートは同じスキーマにも異なるスキーマにもすることができますが、テンプレートは同じテナントに割り当てる必要があります。

  • 宛先テンプレートが作成され、少なくとも 1 つのサイトに割り当てられている必要があります。

  • 宛先テンプレートが展開されておらず、他のオブジェクトがない場合、そのテンプレートは、オブジェクトの移行後に自動的に展開されます。

  • 1 つのオブジェクト移行を開始すると、同じ送信元またはターゲット テンプレートを含む別の移行を実行することはできません。テンプレートがサイトに展開されると、移行が完了します。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左のナビゲーションメニューから [スキーマ(Schemas)] を選択します。

ステップ 3

移行するオブジェクトが含まれているスキーマをクリックします。

ステップ 4

[スキーマ (Schema)] ビューで、移行するオブジェクトが含まれているテンプレートを選択します。

ステップ 5

メインペインの右上にある [選択 (Select)] をクリックします。

これにより、移行する 1 つ以上のオブジェクトを選択できます。

ステップ 6

移行する各オブジェクトをクリックします。

選択したオブジェクトには、右上隅にチェックマークが表示されます。

ステップ 7

メインペインの右上にある [アクション (actions)] (...) アイコンをクリックし、[オブジェクトの移行 ( Migrate Objects)] を選択します。

ステップ 8

[オブジェクトの移行 (Migrate objects)] ウィンドウで、オブジェクトを移動する宛先スキーマとテンプレートを選択します。

リストには、少なくとも 1 つのサイトが接続されているテンプレートのみが表示されます。ドロップダウン リストにターゲット テンプレートが表示されない場合は、ウィザードをキャンセルし、そのテンプレートを少なくとも 1 つのサイトに割り当てます。

ステップ 9

[OK] をクリックし、[はい (YES)] をクリックしてオブジェクトを移動することを確認します。

オブジェクトは、ソーステンプレートから選択した宛先テンプレートに移行されます。設定を展開すると、ソーステンプレートが展開され、宛先テンプレートが展開されているサイトに追加されるサイトから、オブジェクトが削除されます。

ステップ 10

移行が完了したら、ソースと宛先の両方のテンプレートを再展開します。

宛先テンプレートが展開されておらず、他のオブジェクトがない場合、そのテンプレートはオブジェクトの移行後に自動的に展開されるため、この手順をスキップできます。


現在展開されている設定の表示

特定のテンプレートからサイトに現在展開されているすべてのオブジェクトを表示できます。任意のテンプレートを何度でも展開、展開解除、更新、および再展開できますが、この機能では、これらすべてのアクションの結果としての最終的な状態のみが表示されます。たとえば、Template1VRF1 オブジェクトのみが含まれ、Site1 に展開されている場合、API はそのテンプレートの VRF1 蚤を返します。その後、BD1 を追加して再展開すると、その時点から、API は BD1VRF1 の両方のオブジェクトを返すようになります。

この情報は Orchestrator データベースから取得されるため、サイトのコントローラで直接行われた変更によって発生する可能性のある設定の変動は考慮されません。

手順


ステップ 1

Cisco Nexus Dashboard Orchestrator の GUI にログインします。

ステップ 2

左型のナビゲーション メニューで、[アプリケーション管理 (Application Management) ] > [スキーマ (Schemas)] を選択します。

ステップ 3

表示するテンプレートを含むスキーマをクリックします。

ステップ 4

左側のサイドバーで、テンプレートを選択します。

ステップ 5

そのテンプレートの [展開ビュー (Deployed View)] を開きます。

  1. テンプレートの名前の横にある [アクション (Actions)] メニューをクリックします。

  2. [展開ビュー (Deployed View)] をクリックします。

ステップ 6

[展開ビュー (Deployed View)] 画面で、情報を表示するサイトを選択します。

サイトにすでに展開されているものと、テンプレートで定義されているものとのテンプレート設定の比較がグラフィカルに表示されます。

  1. 色分けされた凡例は、この時点でテンプレートを展開する場合に作成、削除、または変更されるオブジェクトを示します。

    テンプレートの最新バージョンがすでに展開されている場合、ビューには色分けされたオブジェクトは含まれず、現在展開されている設定が表示されます。

  2. サイト名をクリックすると、その特定のサイトの設定を表示できます。

  3. [XML/JSON 表示 (View XML/JSON)] をクリックすると、選択したサイトに展開されているすべてのオブジェクトの XML 設定が表示されます。


スキーマの概要と展開ビジュアライザ

1つ以上のオブジェクトが定義され、1つ以上のACIファブリックに展開されたスキーマを開くと、スキーマの [概要 (Overview)] ページに展開の概要が表示されます。

図 1. スキーマの概要

このページには、次の詳細が表示されます。

  1. [一般 (General)]:名前や説明など、スキーマの一般情報を提供します。

  2. [監査ログ (Audit Log)]:スキーマで実行されたアクションの監査ログの概要を提供します。

  3. [サイト (Sites)] > [正常性 (Health)]:サイトの正常性ステータスでソートされた、このスキーマのテンプレートに関連付けられているサイトの数を提供します。

  4. [サイト (Sites)] > [タイプ (Type)]:サイトのタイプでソートされた、このスキーマのテンプレートに関連付けられているサイトの数を提供します。

  5. [テンプレートとサイトの関連付け (Template to Site Associations)] > [展開ステータス ( Deployment Status)]:1 つ以上のサイトに関連付けられているこのスキーマ内のテンプレートの数とその展開ステータスを提供します。

  6. [テンプレートとサイトの関連付けの整合性(Template to Site Associations Consistency)]:展開されたテンプレートで実行された整合性チェックの数とそのステータスを提供します。 >

  7. [アプリケーション管理 (Application Management)]:このスキーマのテンプレートに含まれる個々のオブジェクトの概要を提供します。

[トポロジ (Topology)] タイルでは、次の図に示すように、1 つ以上のオブジェクトを選択してダイアグラムに表示することで、トポロジ ビジュアライザを作成できます。

図 2. 展開ビジュアライザ
  1. 凡例 (Legent):次のトポロジ図に表示するポリシーオブジェクトを選択できます。

  2. [フィルタ (Filter)]:表示されるオブジェクトを名前に基づいてフィルタリングできます。

  3. [トポロジ図 (Topology Diagram)]:サイトに割り当てられているすべてのスキーマ テンプレートで設定されたポリシーを視覚的に表示します。

    上記の [設定オプション (Configuration Options)] を使用して、表示するオブジェクトを選択できます。

    また、オブジェクトの上にマウスを置くと、すべての依存関係を強調表示できます。

    最後に、図内の任意のオブジェクトをクリックすると、他のオブジェクトとの関係だけが表示されます。たとえば、テンプレートをクリックすると、その特定のテンプレート内のすべてのオブジェクトのみが表示されます。