概要
ここでは、Cisco Nexus Dashboard に展開されている Cisco Nexus Dashboard Orchestrator のリリース 3.2(x)以降からリリース4.0(1)以降までをアップグレードする方法について説明します。
(注) |
リリース 4.0(1) 以降を既に実行している場合は、このセクションをスキップして、代わりに既存の 4.0(x) リリースからのアップグレード で説明されている手順に従ってください。 |
リリース 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)]
追加を保存することを許可しません。
これらの追加のルールと要件により、以前のリリースからリリース 4.0(1) 以降にアップグレードするには、既存のすべてのテンプレートを分析し、新しい要件を満たさないテンプレートを変換する必要があります。これは、次のセクションで説明する移行プロセス中に自動的に実行され、既存のテンプレートを新しいベストプラクティスに準拠させるために適用する必要があったすべての変更の詳細なレポートを受け取ります。
(注) |
リリース 4.0(1) に移行する既存の設定をバックアップする前に、次の「前提条件とガイドライン」セクションで説明されているすべての要件を満たしていることを確認する必要があります。そうしないと、1 つ以上のテンプレートでテンプレートの変換が失敗し、手動で問題を解決するか、移行プロセスを再開する必要があります。 |
アップグレードのワークフロー
次のリストに、移行プロセスの概要と実行する必要があるタスクの順序を示します。
-
アップグレードガイドラインの確認と充します。
-
既存の Nexus Dashboard Orchestrator 構成をバックアップし、バックアップをローカル マシンにダウンロードします。
-
Nexus Dashboard Orchestrator サービスを無効にして、Nexus Dashboard クラスタから完全にアンインストールします。
これは、同じクラスタにリリース 4.0(1) を展開するため、物理的な Nexus ダッシュボード クラスタには必須です。
ただし、Nexus Dashboard クラスタが仮想の場合は、新しいクラスタを展開して、そこに Nexus Dashboard Orchestrator リリース 4.0(x) をインストールすることを選択できます。新しいクラスタが稼働したら、古いクラスタの VM を切断し、新しいクラスタで移行プロセスを完了することができます。これにより、既存のクラスタを保持し、移行手順で問題が発生した場合に簡単にサービスを再開できます。
-
必要に応じて、Nexus ダッシュボード クラスタをアップグレードします。
前の手順と同様に、クラスタが仮想の場合、それを保持し、新しい仮想クラスタを展開して移行を完了することを選択できます。
-
Nexus Dashboard Orchestrator のターゲットリリース 4.0(x) をインストールします。
-
バックアップ用のリモート ロケーションを新しい Nexus Dashboard Orchestrator インスタンスに追加し、以前のリリースで作成したバックアップをアップロードして、新しい NDO サービスで構成バックアップを復元します。