Chapter1. 新機能および変更された機能に関する情報

- 新機能および変更された機能に関する情報

新機能および変更された機能に関する情報

次のテーブルは、ガイドが最初に発行されたリリースから現行リリースまでの、このガイドの組織と機能に対する重要な変更の概要を示しています。テーブルは、ガイドに加えられたすべての変更のすべてを網羅したリストを提供しているわけではありません。

最新のアップデート

リリース

新機能またはアップデート

参照先

Nexus Dashboard Insights リリース 6.5.1

Cisco Application Centric Infrastructure（ACI）ファブリックで Cisco ACI マルチサイト ファブリック間ネットワークおよびポッド間ネットワーク（IPN）デバイスをオンボードできるようになりました。

Insights 用 Cisco ACI ファブリックでの Cisco マルチサイト サイト間ファブリック ネットワークおよびポッド間ネットワーク デバイスの導入準備

Insights 向け Cisco ACI ファブリックにおける Cisco マルチサイト サイト間ネットワークおよびポッド間ネットワーク デバイスの注意事項と制限事項

PartI. Nexus Dashboard の展開の準備

- 展開の概要と要件

- 前提条件：Nexus Dashboard

- 前提条件：ファブリックコントローラ

- 前提条件：オーケストレータ

- 前提条件：Insights

Chapter2. 展開の概要と要件

- デプロイ概要

デプロイ概要

Nexus Dashboardプラットフォーム

Cisco Nexus Dashboard は、複数のデータ センター ファブリック向けの中央管理コンソールであり、Insights、Orchestrator、Fabric Controller などの Cisco データセンター運用サービスをホストするための共通プラットフォームです。これらのサービスはすべてのデータ センター ファブリックで利用でき、ネットワーク ポリシーと運用のためのリアルタイム分析、可視性、保証、また Cisco ACI や Cisco NDFC などのデータ センター ファブリックのポリシー オーケストレーションを提供しています。

Nexus Dashboard は、上述のマイクロサービスベースのアプリケーションに共通のプラットフォームと最新のテックスタックを提供し、さまざまな最新アプリケーションのライフサイクル管理を簡素化しながら、これらのアプリケーションを実行し維持するための運用オーバーヘッドを削減します。また、ローカルにホストされているアプリケーションと外部のサードパーティ製アプリケーションの中央統合ポイントも提供します。

（注）

このドキュメントでは、Nexus Dashboard クラスタを最初に展開し、1 つ以上のサービスを有効にし、それらのサービスによって管理されるファブリックをオンボードする方法について説明します。クラスタが稼働したら、Nexus Dashboard の設定と操作に関する記事、および日常の操作に関するサービス固有のドキュメントを参照してください。

Nexus Dashboard サービスと統合インストール

Nexus ダッシュボードは、一貫した統一された方法ですべての Nexus Dashboard 製品を使用できるようにするサービスを構築および展開するための標準のアプライアンス プラットフォームです。Nexus Dashboard プラットフォームは、Nexus Dashboard サービス（Insights、Orchestrator、Fabric Controller など）を有効にして、ネットワーク ポリシーと運用のリアルタイム分析、可視性、保証を提供できます。また、Cisco ACI、Cisco NDFC、またはコントローラのないスタンドアロン NX-OS スイッチなどのデータセンター ファブリックのポリシー オーケストレーションを実現します。

以前は、Nexus Dashboard にはプラットフォーム ソフトウェアのみが付属しており、サービスは含まれていませんでした。これらのサービスは、最初のプラットフォームの展開後に個別にダウンロード、インストール、および有効化するようになっていました。現在は、プラットフォームと個々のサービスは単一のイメージに統合され、クラスタの初期構成時に展開して有効にすることができるようになりました。こうして、よりシンプルで合理化されたエクスペリエンスを実現しています。

（注）

Nexus Dashboard プラットフォームの以前のリリースでは、多くの場合、個々のサービスの複数のバージョンがサポートされていましたが、統合インストールにより、各 Nexus Dashboard リリースは、各サービスの特定の単一バージョンをサポートし、それらをクラスタの展開時に有効にすることを選択できるようになりました。

さらに、統合インストールにより、クラスタ展開時にサポートされているサービスの組み合わせのみを有効にできるため、サポートされていないサービスの組み合わせが発生する可能性はなくなりました。サービスの共同ホスティングに関する詳細情報は、 Nexus Dashboard クラスタ サイジング ツールで入手できます。

ハードウェアとソフトウェアのスタック

Nexus Dashboardは、ソフトウェアフレームワーク（Nexus Dashboard）がプリインストールされた、特殊なCisco UCSサーバ（Nexus Dashboardプラットフォーム）のクラスタとして提供されます。Cisco Nexus Dashboard ソフトウェアスタックは、ハードウェアから分離して、多数の仮想フォームファクタで展開できます。このドキュメントでは、「Nexus Dashboard worker」はハードウェアを指し、「Nexus Dashboard」はソフトウェア スタックと GUI コンソールを指します。

このガイドでは、Nexus Dashboard ソフトウェアの初期導入について説明します。これは、物理、仮想、クラウドのフォームファクタに共通です。物理クラスタを展開する場合は、Nexus Dashboard ハードウェア セットアップ ガイドで、UCS サーバーのハードウェアの概要、仕様、ラック搭載の方法などについて参照してください。

（注）

Nexus Dashboard ソフトウェアへの root アクセスは、Cisco TAC のみに制限されています。一連の操作とトラブルシューティング コマンドを有効にするために、すべての Nexus Dashboard 展開のために特別なユーザー rescue-user が作成されます。使用可能な rescue-user コマンドの詳細については、Nexus Dashboard ドキュメント ライブラリの「トラブルシューティング」の章を参照してください。

利用可能なフォームファクタ

Cisco Nexus Dashboardのこのリリースは、さまざまなフォームファクタを使用して展開できます。ただし、すべてのノードに同じフォーム ファクタを使用する必要があります。同じクラスタ内で異なるフォーム ファクタのノードを混在させることはサポートされていません。物理フォーム ファクタは現在、クラスタ ノード用に 2 つの異なる Cisco UCS サーバー（SE-NODE-G2 と ND-NODE-L4）をサポートしており、これらは同じクラスタ内で混在させることができます。

- 物理アプライアンス（.iso）

このフォームファクタは、Cisco Nexus Dashboard ソフトウェア スタックがプレインストールされた、Cisco UCS 物理アプライアンス ハードウェアを指します。

このドキュメントの後半のセクションでは、既存の物理アプライアンスハードウェアでソフトウェアスタックを設定してクラスタを展開する方法について説明します。Nexus Dashboard ハードウェアのセットアップについては、特定の UCS モデルの Nexus Dashboard ハードウェア セットアップ ガイドを参照してください。

- 仮想アプライアンス

- VMware ESX (.ova)

VMware ESX仮想マシンを使用して、Nexus Dashboardクラスタを展開できる仮想フォームファクタ。

- Linux KVM（.qcow2）

Linux KVM仮想マシンを使用して、Nexus Dashboardクラスタを展開できる仮想フォームファクタ。

- パブリッククラウド

- Amazon Web Services (.ami)

AWSインスタンスを使用して、Nexus Dashboardクラスタを展開できるクラウドフォームファクタ。

- Microsoft Azure (.arm)

Azureインスタンスを使用して、Nexus Dashboardクラスタを展開できるクラウドフォームファクタ。

（注）

すべてのサービスがすべてのフォーム ファクタでサポートされているわけではありません。展開を計画するときは、このドキュメントの次のいずれかのセクションで、展開するフォームファクタに固有の「前提条件とガイドライン」のリストを確認してください。サポートされているフォーム ファクタ、サービス、スケール、およびクラスタ サイジングの要件のクイック リファレンスは、Nexus Dashboard クラスタ サイジング ツールで入手できます。

スケールとクラスタ サイジングのガイドライン

基本的な Nexus Dashboard の展開は、通常、クラスタを起動するために必要な 1 つまたは 3 つの プライマリ ノードで構成されます。サービスとスケールの要件に応じて、 セカンダリ ノードを追加して 3 ノードクラスタを拡張し、サービスの共同ホスティングとより大きなスケールをサポートできます。物理クラスタの場合、プライマリノードに障害が発生した場合にクラスタを容易に回復できるようにするため、最大 2 つの スタンバイ ノードを追加することもできます。

（注）

- 単一ノード展開は、限られた数のサービスでサポートされています。最初の展開後に 3 ノード クラスタに拡張することはできません。

単一ノード クラスタを展開したものの、それを 3 ノード クラスタに拡張する必要が生じた場合、またはセカンダリ ノードを追加する必要が生じた場合は、基本の 3 ノード クラスタとして再度展開する必要があります。

- 単一ノード展開では、追加の セカンダリ ノードまたは スタンバイ ノードはサポートされません。

- 3 ノード クラスタの場合、クラスタが動作し続けるには、少なくとも 2 つのプライマリ ノードが必要です。

特定のユースケースに必要な追加のセカンダリ ノードの正確な数は、Nexus Dashboard クラスタ サイジング ツールから入手できます。

Chapter3. 前提条件：Nexus Dashboard

- すべての有効なサービスの前提条件と注意事項

- 通信ポート

- ファブリック接続

- ファブリック間のノード分散

- サービスのコロケーションの使用例

- インストール前のチェックリスト

すべての有効なサービスの前提条件と注意事項

このセクションでは、Nexus Dashboard クラスタで有効にできるすべてのサービスに共通の要件とガイドラインについて説明します。サービス固有のその他の要件は、このドキュメントの次のセクションに記載されています。

Network Time Protocol（NTP）とドメイン ネーム システム（DNS）

Nexus Dashboard ノードでの展開とアップグレードには、常に、有効な DNS サーバーと NTP サーバーが必要です。有効な DNS 接続がない場合（到達不能な IP アドレスまたはプレースホルダ IP アドレスを使用している場合など）、システムを正常に展開またはアップグレードできない可能性がありますし、通常のサービスの機能にも影響が及びます。

（注）

Nexus Dashboard は、DNS クライアントとリゾルバーの両方として機能します。内部サービス向けには、DNS リゾルバーとして機能する内部の Core DNS サーバーを使用します。また、DNS クライアントとしても動作して、イントラネット内またはインターネットの外部ホストに到達できるようにするためには、外部 DNS サーバーを構成する必要があります。

Nexus Dashboard は、ワイルドカード レコードを持つ DNS サーバーはサポートしていません。

Nexus Dashboard は対称キーを使用した NTP 認証もサポートしています。NTP 認証を有効にする場合は、クラスタの構成時に次の情報を入力する必要があります。

- [NTP キー（NTP Key）]：Nexus Dashboard と NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- [キー ID（Key ID）]：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- [認証タイプ（Auth Type）]：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

NTP 認証を有効にする場合は、次の注意事項が適用されます。

- 対称認証の場合、使用するキーは、NTP サーバーと Nexus Dashboard の両方で同じ構成にする必要があります。

ID、認証タイプ、およびキー/パスフレーズ自体は、NTP サーバーと Nexus ダッシュボードの両方で一致し、信頼されている必要があります。

- 複数のサーバーが同じキーを使用できます。

この場合、キーは Nexus Dashboard で 1 回だけ構成してから、複数のサーバーに割り当てる必要があります。

- キー ID が一意である限り、Nexus Dashboard と NTP サーバの両方に複数のキーを設定できます。

- このリリースでは、NTP キーの SHA1、MD5、および AES128CMAC 認証/エンコーディング タイプがサポートされています。

（注）

セキュリティが高い AES128CMAC を使用することを推奨します。

- Nexus Dashboard で NTP キーを追加する場合は、信頼できるとしてタグ付けする必要があります。信頼できないキーは認証に失敗します。

このオプションを使用すると、キーが侵害された場合に Nexus Dashboard で特定のキーを簡単に無効にすることができます。

- Nexus Dashboard で一部の NTP サーバーを優先としてタグ付けすることを選択できます。

NTP クライアントは、RTT、応答時間の差異、およびその他の変数を考慮することで、時間の経過に伴う NTP サーバーの「品質」を推定できます。プライマリ サーバーを選択する場合、優先サーバーの優先順位が高くなります。

- ntpd を実行している NTP サーバーを使用している場合は、少なくともバージョン 4.2.8p12 を推奨します。

- 以下の制限事項がすべての NTP キーに適用されます。

- SHA1 および MD5 キーの最大長は 40 文字ですが、AES128 キーの最大長は 32 文字です。

- 20 文字未満のキーには、「#」とスペースを除く任意の ASCII 文字を含めることができます。長さが 20 文字を超えるキーは、16 進形式である必要があります。

- キー ID は 1 ～ 65535 の範囲で指定する必要があります。

- 1 つの NTP サーバーのキーを構成する場合は、他のすべてのサーバーのキーも構成する必要があります。

NTP 認証の有効化と構成については、後のセクションで展開手順の一部として説明します。

Nexus Dashboard 外部ネットワーク

Nexus Dashboardはクラスタとして展開され、各サービスノードは2つのネットワークに接続されます。最初に Nexus Dashboard を構成するときは、2 つの Nexus Dashboard インターフェイスに 2 つの IP アドレスを指定する必要があります。1 つはデータ ネットワークに接続し、もう 1 つは管理ネットワークに接続します。

Nexus Dashboard にインストールされる個々のサービスは、次のセクションで説明するように、追加の目的で 2 つのネットワークを使用する場合があります。

外部ネットワークの目的

データ ネットワーク

管理ネットワーク

- Nexus Dashboardノードのクラスタリング

- サービス間通信

- Cisco APIC、クラウド ネットワーク コントローラ、および NDFC 通信へのNexus Dashboard ノード

たとえば、Nexus ダッシュボード Insights などのサービスのネットワーク トラフィックです。

- スイッチおよびオンボード ファブリックのテレメトリ トラフィック

- Nexus ダッシュボード GUI へのアクセス

- SSH を介した Nexus Dashboard CLI へのアクセス

- DNS および NTP 通信

- Nexus Dashboard ファームウェアのアップロード

- Intersight デバイス コネクタ

- AAAトラフィック

2つのネットワークには次の要件があります。

- すべての Nexus Dashboard 展開では、管理ネットワークとデータネットワークが異なるサブネットに存在する必要があります。

（注）

Nexus Dashboard ファブリック コントローラ サービスだけを実行するNexus Dashboard クラスタは例外です。これは、データ ネットワークと管理ネットワークで同じサブネットを使用して展開できます。

- データ サブネットを変更するにはクラスタを再展開する必要があるため、今後の追加サービスを考慮して、ノードとサービスの必要最低限よりも大きなサブネットを使用することをお勧めします。

- 物理クラスタの場合、管理ネットワークは各ノードの CIMI に対して、TCP ポート 22/443 を介して IP 到達可能性を提供する必要があります。

Nexus Dashboardのクラスタ設定では、各ノードのCIMC IPアドレスを使用してノードを設定します。

- データ ネットワーク インターフェイスで、Nexus Dashboard トラフィックに使用できる最小 MTU が 1500 である必要があります。

必要に応じて、ノードが接続されているスイッチでより高い MTU を構成できます。

（注）

データ ネットワーク トラフィックに使用されるスイッチ ポートに外部 VLAN タグが構されている場合は、ジャンボ フレームを有効にするか、ノードが接続されているスイッチ ポートで 1504 バイト以上のカスタム MTU を構成する必要があります。

- 両方のネットワークでノード間の接続が必要です。そして、次の追加のラウンド トリップ時間（RTT）要件があります。

（注）

Nexus Dashboard クラスタからファブリック コントローラまたはスイッチへの接続に関する RTT 要件は、有効にする予定のサービスに応じて異なります。以下のサービス固有の章の「ネットワーク要件」セクションを参照してください。

クラスタの RTT 要件

接続

最大 RTT

同じ Nexus Dashboard クラスタ内のノード間

50 ミリ秒

あるクラスタ内のノードと別のクラスタ内のノード間（クラスタがマルチクラスタ接続を介して接続されている場合）

マルチクラスタ接続の詳細については、『Cisco Nexus Dashboard インフラストラクチャ管理』を参照してください。

500 ミリ秒

外部 Domain Name System（DNS）サーバと Nexus ダッシュボード クラスタ間

5 秒

Nexus Dashboard の内部ネットワーク

Nexus Dashboard で使用されるコンテナ間の通信には、さらに2つの内部ネットワークが必要です。

- アプリケーション オーバーレイは、Nexus ダッシュボード内のアプリケーションで内部的に使用されます。

アプリケーションオーバーレイは /16 ネットワークである必要があり、導入時にデフォルト値が事前入力されます。

- サービス オーバーレイは、Nexus ダッシュボードによって内部的に使用されます。

サービスオーバーレイは /16 ネットワークである必要があり、導入時にデフォルト値が事前入力されます。

複数の Nexus Dashboard クラスタの展開を計画している場合、同じアプリケーションサブネットとサービスサブネットをそれらに使用できます。

（注）

異なる Nexus ダッシュボード ノードに展開されたコンテナ間の通信は VXLAN でカプセル化され、送信元と宛先としてデータ インターフェイスの IP アドレスを使用します。これは、アプリケーション オーバーレイとサービス オーバーレイのアドレスがデータ ネットワークの外部に公開されることはなく、これらのサブネット上のトラフィックは内部でルーティングされ、クラスタノードから出ないことを意味します。

たとえば、オーバーレイ ネットワークの 1 つと同じサブネット上に別のサービス（DNS など）がある場合、そのサブネット上のトラフィックはクラスタの外部にルーティングされないため、Nexus ダッシュボードからそのサービスにアクセスできません。そのため、これらのネットワークは一意であり、クラスタの外部にある既存のネットワークまたはサービスと重複しないようにしてください。これらは Nexus ダッシュボード クラスタ ノードからアクセスする必要があります。

同じ理由で、アプリまたはサービスのサブネットには 169.254.0.0/16（Kubernetes br1 サブネット）を使用しないことをお勧めします。

IPv4 および IPv6 のサポート

Nexus Dashboard は、クラスタ ノードおよびサービスの純粋な IPv4、純粋な IPv6、またはデュアル スタック IPv4/IPv6 構成をサポートします。

IP アドレス構成を定義するとき、以下の注意事項が適用されます。

- クラスタ内のすべてのノードとネットワークは、純粋な IPv4、純粋な IPv6、またはデュアル スタック IPv4/IPv6 のいずれかの均一な IP 構成を持つ必要があります。

- クラスタを純粋な IPv4 モードで展開し、デュアル スタック IPv4/IPv6 または純粋な IPv6 に切り替える場合は、クラスタを再展開する必要があります。

- デュアル スタック構成の場合：

- 外部（データと管理）ネットワークと内部（アプリケーションとサービス）ネットワークの両方がデュアル スタック モードである必要があります。

IPv4 データ ネットワークやデュアル スタック管理ネットワークなどの混合構成はサポートされていません。

- 物理的なサーバーの CIMC にも IPv6 アドレスが必要です。

- ノードの初期起動時にノードの管理ネットワークに IPv4 または IPv6 アドレスを構成できますが、クラスタのブートストラップ ワークフロー中に両方のタイプの IP アドレスを指定する必要があります。

管理 IP アドレスは、初めてノードにログインしてクラスタのブートストラップ プロセスを開始するために使用されます。

- Kubernetes 内部コア サービスは IPv4 モードで開始されます。

- DNS は IPv4 要求と IPv6 要求の両方を処理し、転送します。

- ピア接続用の VXLAN オーバーレイは、データ ネットワークの IPv4 アドレスを使用します。

IPv4 パケットと IPv6 パケットは両方とも、VXLAN の IPv4 パケット内にカプセル化されます。

- GUI は、IPv4 と IPv6 の両方の管理ネットワーク アドレスでアクセスできます。

- 純粋な IPv6 構成の場合：

- 純粋な IPv6 モードは、物理および仮想フォーム ファクタのみでサポートされます。

AWS および Azure に展開されたクラスタは、純粋な IPv6 モードをサポートしていません。

- ノードを最初に構成するときに、IPv6 管理ネットワーク アドレスを指定する必要があります。

ノードが起動した後、これらの IP アドレスを使用して GUI にログインし、クラスタのブートストラップ プロセスを続行します。

- 前述の内部アプリケーションおよびサービス ネットワークに IPv6 CIDR を提供する必要があります。

- 前述のデータ ネットワークと管理ネットワークに IPv6 アドレスとゲートウェイを提供する必要があります。

- すべての内部サービスは IPv6 モードで開始されます。

- ピア接続用の VXLAN オーバーレイは、データ ネットワークの IPv6 アドレスを使用します。

IPv6 パケットは、VXLAN の IPv6 パケット内にカプセル化されます。

- すべての内部サービスは IPv6 アドレスを使用します。

BGP 構成と永続的な IP アドレス

Nexus Dashboard の以前の一部のリリースでは、サービスが異なる Nexus Dashboard ノードに再配置された場合でも、同じ IP アドレスを保持する必要があるサービス（Insights やファブリック コントローラなど）に対しては、1 つ以上の永続的な IP アドレスを構成できました。ただし、これらのリリースでは、永続的な IP アドレスは管理サブネットとデータサブネットの一部である必要があり、クラスタ内のすべてのノードが同じレイヤ 3 ネットワークの一部である場合にのみ機能を有効にできました。ここで、サービスは、Gratuitous ARP やネイバー探索などのレイヤ 2 メカニズムを使用して、レイヤ 3 ネットワーク内で永続的な IP アドレス をアドバタイズします。

この機能は引き続きサポートされていますが、このリリースでは、異なるレイヤ 3 ネットワークにクラスタ ノードを展開する場合でも、永続的な IP アドレス機能を構成することができます。この場合、永続的な IP アドレスは、「レイヤ 3 モード」と呼ばれる BGP を介して各ノードのデータリンクからアドバタイズされます。また、IP アドレスは、ノードの管理サブネットまたはデータサブネットと重複していないサブネットの一部である必要があります。永続 IP アドレスがデータネットワークおよび管理ネットワークの外部にある場合、この機能はデフォルトでレイヤ 3 モードで動作します。IP アドレスがそれらのネットワークの一部である場合、機能はレイヤ 2 モードで動作します。BGP は、クラスタの展開中、またはクラスタの稼働後に Nexus Dashboard GUI から有効にすることができます。

BGP を有効にして永続的な IP 機能を使用することを計画している場合は、次のことを行う必要があります。

- ピア ルータが、ノードのレイヤ 3 ネットワーク間でアドバタイズされた永続的 IP アドレスを交換することを確認します。

- 以降のセクションで説明されているように、クラスタの展開時に BGP を有効にするか、インフラストラクチャ管理ドキュメントの「永続的な IP アドレス」セクションで説明されているように、Nexus ダッシュボード GUI で後で有効にするかを選択します。

- 割り当てる永続的な IP アドレスが、ノードの管理サブネットまたはデータ サブネットと重複しないようにしてください。

- 以下のサービス固有のセクションに記載されている、サービス固有の永続 IP アドレス要件を満たしていることを確認します。

各サービスに必要な永続 IP アドレスの総数は、以下のサービス固有の要件のセクションに記載されています。

通信ポート

Nexus Dashboard クラスタには、次のポートが必要です。

（注）

すべてのサービスは、暗号化を備えた TLS または mTLS を使用して、移行中にデータのプライバシーと完全性を保護します。

Nexus Dashboard ポート（管理ネットワーク）

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

ICMP

ICMP

ICMP

入力／出力

他のクラスタ ノード、CIMC、デフォルト ゲートウェイ

SSH

22

TCP

入力／出力

クラスタ ノードの CLI および CIMC

TACACS

49

TCP

発信

TACACS サーバー

DNS

53

TCP/UDP

アウト

DNS サーバ

HTTP

80

TCP

発信

インターネット/プロキシ

NTP

123

UDP

発信

NTP サーバー

HTTPS

443

TCP

入力／出力

UI、他のクラスタ (マルチクラスタ接続用)、ファブリック、インターネット/プロキシ

LDAP

389

636

TCP

発信

LDAP サーバ

RADIUS

1812

TCP

発信

Radius サーバー

KMS

9880

TCP

入力／出力

その他クラスタ ノードおよび ACI ファブリック

インフラサービス

30012

30021

30500 ～ 30600

TCP および UDP

入力／出力

その他のクラスタ ノード

Nexus Dashboard ポート（データ ネットワーク）

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

ICMP

ICMP

ICMP

入力／出力

他のクラスタ ノード、デフォルト ゲートウェイ

SSH

22

TCP

発信

スイッチと APIC の帯域内

DNS

53

TCP および UDP

入力／出力

他のクラスタノードと DNS サーバー

NFSv3

111

TCP および UDP

入力／出力

リモート NFS サーバー

HTTPS

443

TCP

発信

スイッチと APIC の帯域内

NFSv3

608

UDP

入力／出力

リモート NFS サーバー

SSH

1022

TCP および UDP

入力／出力

その他のクラスタ ノード

NFSv3

2049

TCP

入力／出力

リモート NFS サーバー

VXLAN

4789

UDP

入力／出力

その他のクラスタ ノード

KMS

9880

TCP

入力／出力

その他クラスタ ノードおよび ACI ファブリック

インフラサービス

3379

3380

8989

9090

9969

9979

9989

15223

30002 ～ 30006

30009 ～ 30010

30012

30014-30015

30018-30019

30025

30027

TCP

入力／出力

その他のクラスタ ノード

インフラサービス

30016

30017

TCP および UDP

入力／出力

その他のクラスタ ノード

インフラサービス

30019

UDP

入力／出力

その他のクラスタ ノード

インフラサービス

30500 ～ 30600

TCP および UDP

入力／出力

その他のクラスタ ノード

ファブリック接続

ここでは、Nexus Dashboard クラスタ ノードを管理ネットワークとデータ ネットワークに接続し、クラスタをファブリックに接続する方法について説明します。

- オンプレミス APIC または NDFC ファブリックの場合、Nexus ダッシュボード クラスタは次の2つの方法のいずれかで接続できます。

- レイヤ 3 ネットワーク経由でファブリックに接続された Nexus Dashboard クラスタ。

- リーフ スイッチに接続された Nexus Dashboard ノードは、一般的なホストです。

- Cloud Network Controller ファブリックの場合は、レイヤ 3 ネットワーク経由で接続する必要があります。

外部レイヤ 3 ネットワークを介した接続

Nexus Dashboard クラスタは、外部のレイヤ 3 ネットワーク経由でファブリックに接続することを推奨します。これは、クラスタをどのファブリックにも結び付けず、すべてのファブリックに同じ通信パスを確立できるためです。特定の接続は、Nexus Dashboard に展開されたアプリケーションのタイプによって異なります。

- Cisco ACI ファブリックのみを管理するために Nexus Dashboard Orchestrator を展開する場合は、データ インターフェイスまたは管理インターフェイスから各ファブリックの APIC のインバンドまたはアウトオブバンド（OOB）インターフェイスまたは両方への接続を確立できます。

ファブリック接続が Nexus ダッシュボードの管理インターフェイスからのものである場合は、特定のスタティック ルートを設定するか、管理インターフェイスが APIC インターフェイスの同じ IP サブネットの一部であることを確認する必要があります。

- Nexus ダッシュボード Insights などの Day-2 Operations アプリケーションを展開する場合は、データ インターフェイスから各ファブリックおよび APIC のインバンド ネットワークへの接続を確立する必要があります。

レイヤ 3 ネットワークを介してクラスタを接続する場合は、次の点に注意してください。

- ACI ファブリックの場合、管理テナントで Cisco Nexus Dashboard データ ネットワーク接続用の L3Out および外部 EPG を設定する必要があります。

ACI ファブリックでの外部接続の設定については、 『Cisco APIC Layer 3 Networking Configuration Guide』を参照してください。

- NDFC ファブリックの場合、データ インターフェイスと NDFC のインバンド インターフェイスが異なるサブネットにある場合は、Nexus Dashboard のデータ ネットワーク アドレスに到達するためのルートを NDFC で追加する必要があります。

NDFC UI からルートを追加するには、[管理者（Administration）] > [カスタマイズ（Customization）] > [ネットワーク設定（Network Preference）] > [インバンド（In-Band）（eth2）]に移動し、ルートを追加して保存します。

- クラスタのセットアップ中にデータ インターフェイスの VLAN ID を指定する場合、そのVLANを許可するトランクとしてホスト ポートを設定する必要があります。

ただし、ほとんどの一般的な導入では、VLAN ID を空のままにして、ホスト ポートをアクセス モードに設定できます。

次の 2 つの図は、Nexus Dashboard クラスタをレイヤ 3 ネットワーク経由でファブリックに接続する場合の 2 つの異なるネットワーク接続シナリオを示しています。それぞれの主な目的は、Nexus ダッシュボードで実行しているアプリケーションのタイプによって異なります。

レイヤ 3 ネットワークを介した接続、2 日目の運用アプリケーション

レイヤ3ネットワーク、Nexus Dashboard Orchestratorを介した接続

リーフ スイッチへのノードの直接接続

Nexus Dashboard クラスタをファブリックの 1 つに直接接続することもできます。これにより、クラスタとファブリックのインバンド管理が容易になりますが、クラスタを特定のファブリックに結び付け、外部接続を介して他のファブリックに到達できるようにする必要があります。これにより、クラスタが特定のファブリックに依存するようになるため、ファブリック内の問題が Nexus Dashboard の接続に影響を与える可能性があります。前の例と同様に、接続はNexus Dashboard に展開されたアプリケーションのタイプによって異なります。

- Cisco ACI ファブリックのみを管理するために Nexus Dashboard Orchestrator を展開する場合は、データ インターフェイスまたは管理インターフェイスから各ファブリックの APIC のインバンドまたはアウトオブバンド（OOB）インターフェイスまたは両方への接続を確立できます。

ファブリック接続が Nexus ダッシュボードの管理インターフェイスからのものである場合は、特定のスタティック ルートを設定するか、管理インターフェイスが APIC インターフェイスの同じ IP サブネットの一部であることを確認する必要があります。

- Nexus ダッシュボード Insights を展開する場合は、データインターフェイスから各ファブリックのインバンドインターフェイスへの接続を確立する必要があります。

ACIファブリックの場合、データインターフェイスIPサブネットはファブリック内のEPG / BDに接続し、管理テナントのローカルインバンドEPGに対して確立されたコントラクトが必要です。Nexus Dashboard は、管理テナントおよびインバンドVRFに導入することを推奨します。他のファブリックへの接続は、L3Out経由で確立されます。

- ACIファブリックを使用してNexus Dashboard Insightsを展開する場合は、データインターフェイスのIPアドレスとACIファブリックのインバンドIPアドレスは、異なるサブネット内にある必要があります。

クラスタをリーフスイッチに直接接続する場合は、次の点に注意してください。

- VMware ESX または Linux KVM で展開する場合、ホストはトランク ポート経由でファブリックに接続する必要があります。

- クラスタのセットアップ中にデータ ネットワークの VLAN ID を指定する場合は、Nexus ダッシュボード インターフェイスと接続されたネットワークデバイスのポートをトランクとして設定する必要があります。

ただし、ほとんどの場合、VLAN をデータ ネットワークに割り当てないことを推奨します。この場合、ポートをアクセス モードで設定する必要があります。

- ACI ファブリックの場合：

- 管理テナントのCisco Nexus Dashboard接続用にブリッジドメイン(BD)、サブネット、およびエンドポイントグループ(EPG)を設定することを推奨します。

Nexus DashboardはインバンドVRFのインバンドEPGへの接続を必要とするため、管理テナントでEPGを作成すると、ルートリークが不要になります。

- ファブリックのインバンド管理 EPG と Cisco Nexus ダッシュボード EPG 間のコントラクトを作成する必要があります。

- 複数のファブリックが Nexus ダッシュボード クラスタのアプリケーションでモニタされている場合、デフォルトルートまたは他の ACI ファブリックインバンド EPG への特定のルートを持つ L3Out をプロビジョニングし、クラスタ EPG と L3Out の外部 EPG の間でコントラクトを確立する必要があります。

次の2つの図は、Nexus Dashboard クラスタをファブリックのリーフスイッチに直接接続する場合の2つの異なるネットワーク接続シナリオを示しています。それぞれの主な目的は、Nexus Dashboard で実行しているアプリケーションのタイプによって異なります。

リーフ スイッチへの直接接続、2 日目の運用アプリケーション

リーフ スイッチ、Nexus ダッシュボード オーケストレータへの直接接続

ファブリック間のノード分散

Nexus Dashboard は、複数のファブリックへのクラスタ ノードの分散をサポートします。次のノード分散の推奨事項は、物理クラスタと仮想クラスタの両方に適用されます。

Nexus ダッシュボード インサイトのノード配布

Nexus Dashboard Insights サービスには、一元化された単一ファブリックの展開をお勧めします。このサービスは、2 つのプライマリ ノードが使用できない場合には回復をサポートしていないため、分散クラスタからの冗長性の利点は得られません。むしろ、ノードが異なるファブリックにある場合、クラスタで相互接続障害が発生する可能性があります。

ファブリック コントローラのノード分散

Nexus Dashboard Fabric Controller には、一元化された単一ファブリックの展開をお勧めします。このサービスは、2 つのプライマリ ノードが使用できない場合には回復をサポートしていないため、分散クラスタからの冗長性の利点は得られません。むしろ、ノードが異なるファブリックにある場合、クラスタで相互接続障害が発生する可能性があります。

Nexus Dashboard Orchestrator のノードの分散

Nexus Dashboard Orchestrator の場合は、分散クラスタをお勧めします。クラスタが動作し続けるには、少なくとも 2 つの Nexus Dashboard プライマリ ノードが必要であるため、Nexus Dashboard クラスタを 2 つのファブリックに展開する場合は、次の図に示すように、1 つのプライマリ ノードを持つファブリックにスタンバイ ノードを展開することを推奨します。

（注）

スタンバイノードは、物理クラスタでのみサポートされます。仮想クラスタの場合は、障害が発生したノードと同じ設定で新しい VM を起動できます。

Nexus Dashboard Orchestrator の 2 つのファブリックにまたがるノードの分散

サービスのコロケーションの使用例

このセクションでは、特定の単一サービスまたは複数サービスの共同ホストの使用例について、いくつかの推奨される展開シナリオについて説明します。

（注）

このリリースは、Linux KVM、AWS、Azure、または RHEL に展開されている Nexus ダッシュボードクラスタでの共同ホスティングサービスをサポートしていません。以下のすべてのサービス共同ホスティングのシナリオは、物理フォームファクタまたは VMware ESX クラスタフォームファクタに適用されます。クラスタのサイジングと展開計画の参考情報については、Cisco Nexus Dashboard Cluster Sizing tool を参照してください。

単一サイト、Nexus Dashboard Insights および Orchestrator

Nexus Dashboard Insights および Orchestrator サービスを使用する単一ファブリックのシナリオでは、両方のサービスを共存させて単一の Nexus ダッシュボード クラスタを展開できます。

単一サイト、Nexus Dashboard Insights および Orchestrator

Nexus Dashboard Insights および Orchestrator の複数ファブリック、単一クラスタ

Nexus Dashboard Insights および Orchestrator サービスを使用する複数ファブリックのシナリオでは、両方のサービスを共存させて単一の Nexus Dashboard クラスタを展開できます。この場合、ノードはファブリック間で分散できますが、Insights サービスは分散クラスタから冗長性の利点を得ることができず、ノードが異なるファブリックにあるときに相互接続障害にさらされる可能性があるため、左側の展開オプションを推奨します。

Nexus Dashboard Insights および Orchestrator の複数ファブリック、単一クラスタ

Nexus Dashboard Insights および Orchestrator の複数のファブリック、複数のクラスタ

この場合、2 つの Nexus Dashboard クラスタを導入することを推奨します。そのうちの 1 つは、仮想またはクラウド フォーム ファクタを使用する Nexus Dashboard Orchestrator サービス専用で、ファブリック全体に分散されたノードです。

Nexus Dashboard Insights および Orchestrator の複数のファブリック、複数のクラスタ

インストール前のチェックリスト

Nexus ダッシュボード クラスタの展開に進む前に、プロセス中に参照しやすいように次の情報を準備します。

クラスタの詳細

パラメータ（Parameters）

例

入力する値

クラスタ名

nd-cluster

NTP サーバー

170.78.48.55

DNS プロバイダー

170.71.68.83

DNS 検索ドメイン

cisco.com

アプリ ネットワーク

172.17.0.0/16

サービスネットワーク

100.80.0.0/16

（注）

リリース 3.1(1) 以降では、クラスタの初期展開時に、 セカンダリ ノードとスタンバイ ノードを含むすべてのノードを定義できます。わかりやすくするために、次の表では 3 ノードの基本クラスタを想定していますが、より大きなクラスタを展開する場合は、すべての追加ノードのノードの詳細も必要です。

ノードの詳細

パラメータ（Parameters）

例

入力する値

物理ノードの場合、最初のノードの CIMC アドレスとログイン情報

10.196.220.84/24

ユーザ名: admin

パスワード：Cisco1234

物理ノードの場合、2 番目のノードの CIMC アドレスとログイン情報

10.196.220.85/24

ユーザ名: admin

パスワード：Cisco1234!

物理ノードの場合、3 番目のノードの CIMC アドレスとログイン情報

10.196.220.86/24

ユーザ名: admin

パスワード：Cisco1234!

各ノードのレスキュー ユーザに使用されるパスワードと初期GUIパスワード。

クラスタ内のすべてのノードに同じパスワードを設定することを推奨します。

Welcome2Cisco!

最初のノードの 管理 IP

192.168.11.172/24

最初のノードの管理ゲートウェイ

192.168.11.1

最初のノードのデータ ネットワーク IP

192.168.8.172/24

最初のノードのデータ ネットワーク ゲートウェイ

192.168.8.1

（オプション）最初のノードのデータ ネットワーク VLAN

101

BGP を有効にする場合、最初のノードの ASN

63331

BGP を有効にし、純粋な IPv6 展開を使用する場合、最初のノードのルータ ID（IPv4 アドレスの形式）

1.1.1.1

BGP を有効にする場合、最初のノードの BGP ピアの IP アドレス

200.11.11.2

] または [

200:11:11::2

BGP を有効にする場合、最初のノードの BGP ピアの ASN

55555

2 番目のノードの管理 IP

192.168.9.173/24

2 番目のノードの管理ゲートウェイ。

192.168.9.1

2 番目のノードのデータ ネットワーク IP

192.168.6.173/24

2 番目のノードのデータ ネットワーク ゲートウェイ

192.168.6.1

（オプション）2 番目のノードのデータ ネットワーク VLAN

101

BGP を有効にする場合、2 番目のノードの ASN

63331

BGP を有効にし、純粋な IPv6 展開を使用する場合、2 番目のノードのルータ ID（IPv4 アドレスの形式）

2.2.2.2

BGP を有効にする場合、2 番目のノードの BGP ピアの IP アドレス

200.12.12.2

] または [

200:12:12::2

BGP を有効にする場合、2 番目のノードの BGP ピアの ASN

55555

3 番目のノードの管理 IP

192.168.9.174/24

3 番目のノードの管理ゲートウェイ。

192.168.9.1

3 番目のノードのデータ ネットワークIP

192.168.6.174/24

3 番目のノードのデータ ネットワーク ゲートウェイ

192.168.6.1

（オプション）3 番目のノードのデータ ネットワーク VLAN

101

BGP を有効にする場合、3 番目のノードの ASN

63331

BGP を有効にし、純粋な IPv6 展開を使用する場合、3 番目のノードのルータ ID（IPv4 アドレスの形式）

3.3.3.3

BGP を有効にする場合、3 番目のノードの BGP ピアの IP アドレス

200.13.13.2

] または [

200:13:13::2

BGP を有効にする場合、3 番目のノードの BGP ピアの ASN

55555

Chapter4. 前提条件：ファブリックコントローラ

- ファブリック コントローラの要件

- Fabric Controller の通信ポート

ファブリック コントローラの要件

概要

Nexus Dashboard Fabric Controller（NDFC）は、シスコが提供するデータ センターの LAN ファブリック、SAN、および IP Fabric for Media（IPFM）ネットワークにまたがるすべての NX-OS 展開向けの包括的な管理ソリューションです。Cisco Nexus Dashboard Fabric Controller は、IOS-XE スイッチ、IOS-XR ルータ、シスコ以外のデバイスなど、他のデバイスもサポートしています。マルチファブリック コントローラである Cisco Nexus Dashboard Fabric Controller は、VXLAN EVPN、クラシック 3 層、FabricPath、LAN 向けのルーテッド ベース ファブリックなどの複数の展開モデルを管理すると同時に、これらすべての環境ですぐに使用できる制御、管理、モニタリング、および自動化機能を提供します。さらに、Cisco NDFC を SAN コントローラとして有効にすると、ストレージ固有の機能と分析機能に重点を置いた NX-OS モードで Cisco MDS スイッチと Cisco Nexus ファミリインフラストラクチャを自動化します。

NDFC は主に3つの主要な市場セグメントの制御と管理に焦点を当てています。

- VXLAN、マルチサイト、クラシックイーサネット、外部ファブリックを含む LAN ネットワークは、スタンドアロン NX-OS を実行する Cisco Nexus スイッチをサポートし、さらに IOS-XR、IOS-XE、隣接ホスト、計算機、仮想マシン、コンテナ管理システムにも対応します。

- スタンドアロン NX-OS を実行する Cisco MDS および Cisco Nexus スイッチの SAN ネットワーキング（ストレージ アレイ、さらにはホスト、コンピューティング、仮想マシン、およびコンテナ オーケストレーション システムとの統合を含む）。

- スタンドアロン NX-OS として動作する Cisco Nexus スイッチを実行するマルチキャスト ビデオ実稼働ネットワークのメディア制御、およびサード パーティ製メディア制御システムの追加統合。

NDFC を含む展開モードを使用して Nexus Dashboard を展開した後、次の手順を実行します。

- ファブリック検出：LAN 展開を検出、モニタ、および可視化します。

- ファブリックコントローラ：メディア展開用のクラシックイーサネット（vPC）、ルーテッド、VXLAN、および IP ファブリック用の LAN コントローラ。

- SAN コントローラ：MDS および Nexus スイッチ用の SAN コントローラ。ストリーミング テレメトリによる拡張 SAN 分析。

ネットワーク要件

（注）

このセクションでは、ファブリック コントローラ サービスを有効にする場合の追加の要件とガイドラインについて説明します。すべての有効なサービスの前提条件と注意事項 セクションに記載されているプラットフォーム レベルの要件をすでに満たしていることを確認します。

- Nexus Dashboard リリース 3.1.1 以降、サービスを個別にダウンロードする必要がなくなったため、Cisco DC App Center 接続は Nexus Dashboard から削除されました。

ファブリック コントローラを展開するには、[ソフトウェアのダウンロード（Software Download）] ページから統合インストール イメージをダウンロードします。個々のサービスのインストール イメージは、Cisco DC App Center から入手できなくなりました。

- 前のセクションで述べたとおり、すべての新しい Nexus Dashboard 展開では、管理ネットワークとデータネットワークが異なるサブネットに存在する必要があります。

（注）

SAN コントローラのペルソナだけが、データ ネットワークと管理ネットワークに同じサブネットを使用して Nexus Dashboard に展開できます。

- データ ネットワークと管理ネットワークの両方のインターフェイスは、レイヤ 2 またはレイヤ 3 隣接のいずれかにすることができます。

- 両方のネットワークでノード間の接続が必要です。そして、次の追加のラウンド トリップ時間（RTT）要件があります。

ファブリック コントローラの RTT 要件

接続

最大 RTT

スイッチ

200 ms*

* POAP（PowerOn Auto Provisioning）は、Nexus Dashboard ファブリック コントローラとスイッチ間で最大 RTT 50 ミリ秒でサポートされます。

- ユースケースに応じて、次の数の永続 IP アドレスを割り当てる必要があります。

LAN 展開タイプで [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [管理（Management）] に設定されている場合（デフォルト）：

- SNMP/Syslog および SCP サービス用の管理ネットワーク内に 2 つの IP

- [EPL] が有効になっている場合、各ファブリックのデータ ネットワークに 1 つの追加 IP

- メディア用 IP ファブリックが有効になっている場合は、次のいずれかになります。

- シングル ノード ND のテレメトリ用の 管理ネットワーク に 1 つの追加 IP

- 3 ノード ND クラスタのテレメトリ用の 管理ネットワーク に 3 つの追加 IP

LAN 展開タイプで [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [データ（Data）] に設定されている場合：

- SNMP/Syslog および SCP サービス用のデータネットワークに 2 つの IP

- [EPL] が有効になっている場合、各ファブリックのデータ ネットワークに 1 つの追加 IP

- メディア用 IP ファブリックが有効になっている場合は、次のいずれかになります。

- シングル ノードNDのテレメトリ用の データ ネットワーク に 1 つの追加 IP

- マルチノード ND クラスタのテレメトリ用の データ ネットワーク に 3 つの追加 IP

- LAN 展開タイプのレイヤ 3 モードで動作している場合は、[LAN デバイス管理接続（LAN Device Management Connectivity）] を [データ（Data）] に設定する必要があり、すべての永続 IP は、ND 管理サブネットまたはデータ サブネットとは重複しない別のプールの一部である必要があります。

SAN コントローラ展開タイプのレイヤ 2 モードで動作している場合：

- SSH 用の 1 つの IP

- SNMP/Syslog 用の 1 つの IP

- SAN Insights の機能に対して、Nexus Dashboard クラスタ ノードごとに 1 つの IP

永続 IP 機能の概要については、すべての有効なサービスの前提条件と注意事項を参照してください。永続的な IP アドレスの割り当ては、最初のクラスタ展開のときに行うこともできますし、クラスタの展開後に UI の外部サービス プール設定を使用して行うこともできます。

- 同じ Nexus Dashboard クラスタで NDFC と Nexus Dashboard Insights を共同ホスティングするには、Nexus Dashboard ノードがレイヤ 2 で隣接している必要があります。

Fabric Controller の通信ポート

上記の Nexus Dashboard クラスタ ノードに必要なポート（前のセクションに記載）に加えて、Fabric Controller サービスには次のポートが必要です。

- 次のポートは、NDFC サービスからスイッチへの IP の到達を可能にしているインターフェイスに応じて、Nexus Dashboard 管理ネットワークとデータ ネットワーク インターフェイスに適用されます。

Nexus Dashboard Fabric Controller ポート

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

（特に明記されていない限り、LAN と SAN の両方の展開に適用されます）

SSH

22

TCP

発信

SSH は、デバイスにアクセスするための基本的なメカニズムです。

SCP

22

TCP

発信

NDFC バックアップ ファイルをリモート サーバーにアーカイブする SCP クライアント。

SMTP

25

TCP

発信

SMTP ポートは、NDFC の [サーバー設定（Server Settings）] メニューから構成できます。

これはオプションの機能です。

DHCP

67

UDP

入力

NDFC ローカル DHCP サーバーがブートストラップ/POAP 用に構成されている場合。

これは、LAN 展開にのみ適用されます。

（注）

POAP の目的でローカル DHCP サーバーとして NDFC を使用する場合、すべての ND マスター ノードの IP を DHCP リレーとして構成する必要があります。ND ノードの管理 IP またはデータ IP が DHCP サーバーにバインドされるかどうかは、NDFC サーバー設定の LAN デバイス管理接続によって決定されます。

DHCP

68

UDP

発信

SNMP

161

TCP/UDP

アウト

NDFC からデバイスへの SNMP トラフィック。

HTTPS/HTTP（NX-API）

443/80

TCP

発信

NX-API HTTPS/HTTP クライアントは、構成可能でもあるポート 443/80 でデバイスの NX-API サーバーに接続します。NX-API はオプション機能であり、NDFC 機能の限られたセットで使用されます。

これは、LAN 展開にのみ適用されます。

HTTPS（vCenter、Kubernetes、OpenStack、Discovery）

443

TCP

発信

NDFC は、VMware vCenter や OpenStack などの登録済み VMM ドメインと、Kubernetes などのコンテナ オーケストレーターから取得した情報を関連付けることにより、統合されたホストおよび物理ネットワーク トポロジ ビューを提供します。

これはオプションの機能です。

NX-API

8443

TCP

入力／出力

NX-OS リリース 9.x 以降を搭載した Cisco MDS 9000 シリーズ スイッチでパフォーマンス モニタリングに使用されます。

- 次のポートは、一部の NDFC サービスで使用される、永続的 IP とも呼ばれる外部サービス IP に適用されます。

これらの外部サービス IP は、構成された設定に応じて、Nexus Dashboard の管理サブネット プールまたはデータ サブネット プールから取得できます。

Nexus Dashboard Fabric Controller 永続的 IP ポート

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

（特に明記されていない限り、LAN と SAN の両方の展開に適用されます）

SCP

22

TCP

入力

SCP は、デバイスと NDFC サービス間でファイルを転送するさまざまな機能によって使用されます。NDFC SCP サービスは、ダウンロードとアップロードの両方の SCP サーバーとして機能します。SCP は、POAP 関連ファイルをダウンロードするために、デバイス上の POAP クライアントによっても使用されます。

NDFC の SCP-POAP サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

TFTP（POAP）

69

TCP

入力

POAP 経由のデバイス ゼロタッチ プロビジョニングにのみ使用されます。デバイスは、基本的なインベントリ情報を NDFC に送信して (NDFC への制限付きの書き込み専用アクセス)、セキュアな POAP 通信を開始できます。NDFC ブートストラップまたは POAP は、TFTP または HTTP/HTTPS 用に構成できます。

NDFC の SCP-POAP サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

これは、LAN 展開にのみ適用されます。

HTTP（POAP）

80

TCP

入力

POAP 経由のデバイス ゼロタッチ プロビジョニングにのみ使用されます。デバイスは、基本的なインベントリ情報を NDFC に送信して (NDFC への制限付きの書き込み専用アクセス)、セキュアな POAP 通信を開始できます。NDFC ブートストラップまたは POAP は、TFTP または HTTP/HTTPS 用に構成できます。

NDFC の SCP-POAP サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

これは、LAN 展開にのみ適用されます。

BGP

179

TCP

入力／出力

エンドポイント ロケーターの場合、有効になっているファブリックごとに、独自の永続的な IP を使用して EPL サービスが生成されます。このサービスは、常に Nexus Dashboard データ インターフェイスに関連付けられています。エンドポイント情報を追跡するために必要な BGP アップデートを取得するために、ファブリック上の適切な BGP エンティティ（通常は BGP ルート リフレクタ）と NDFC EPL サービスはピアを行います。

この機能は、VXLAN BGP EVPN ファブリックの展開にのみ適用されます。

これは、LAN 展開にのみ適用されます。

HTTPS（POAP）

443

TCP

入力

セキュア POAP は、ポート 443 の NDFC HTTPS サーバーを介して実現されます。HTTPS サーバーは SCP-POAP サービスにバインドされ、そのポッドに割り当てられたのと同じ永続的 IP を使用します。

NDFC の SCP-POAP サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

これは、LAN 展開にのみ適用されます。

Syslog

514

UDP

入力

NDFC が Syslog サーバーとして構成されている場合、デバイスからの Syslog は、SNMP-Trap/Syslog サービス ポッドに関連付けられた永続的な IP に向けて送信されます。

NDFC の SNMP-Trap-Syslog サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

SCP

2022

TCP

発信

NDFC POAP-SCP ポッドの永続的な IP から、Nexus Dashboard Insights を実行している別の ND クラスターにテクニカル サポート ファイルを転送します。

NDFC の SCP-POAP サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の LAN デバイス管理接続設定によって制御されます。

SNMP トラップ

2162

UDP

入力

デバイスから NDFC への SNMP トラップは、SNMP-Trap/Syslog サービス ポッドに関連付けられた永続的な IP に向けて送信されます。

NDFC の SNMP-Trap-Syslog サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

HTTP（PnP）

9666

TCP

入力

Catalyst デバイス用の Cisco プラグ アンド プレイ（PnP）は、NDFC HTTP ポート 9666 および HTTPS ポート 9667 を介して実現されます。ポート 9666 の HTTP は、CA 証明書バンドルをデバイスに送信して HTTPS モード用にデバイスを準備するために使用され、実際の PnP はその後ポート 9667 で HTTPS を介して行われます。

POAP のような PnP サービスは、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP で実行されます。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

これは、LAN 展開にのみ適用されます。

HTTPS（PnP）

9667

TCP

入力

GRPC（テレメトリ）

33000

TCP

入力

NDFC 永続的 IP に関連付けられた GRPC トランスポートを介して SAN データ (ストレージ、ホスト、フローなど) を受信する SAN Insights Telemetry サーバー。

これは、SAN 展開でのみ有効です。

GRPC（テレメトリ）

50051

TCP

入力

メディア展開用の IP ファブリックおよび一般的な LAN 展開用の PTP のマルチキャスト フローに関連する情報は、ソフトウェア テレメトリを介して、NDFC GRPC レシーバー サービス ポッドに関連付けられた永続的 IP にストリーミングされます。

これは、LAN およびメディア展開でのみ有効です。

- 単一ノード クラスタでの NDFC SAN 展開には、次のポートが必要です。

単一ノード クラスタでの SAN 展開向けの Nexus Dashboard Fabric Controller ポート

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

（特に明記されていない限り、LAN と SAN の両方の展開に適用されます）

SSH

22

TCP

発信

SSH は、デバイスにアクセスするための基本的なメカニズムです。

SCP

22

TCP

発信

NDFC バックアップ ファイルをリモート サーバーにアーカイブする SCP クライアント。

SMTP

25

TCP

発信

SMTP ポートは、NDFC の [サーバー設定（Server Settings）] メニューから構成できます。

これはオプションの機能です。

SNMP

161

TCP/UDP

アウト

NDFC からデバイスへの SNMP トラフィック。

HTTPS（vCenter、Kubernetes、OpenStack、Discovery）

443

TCP

発信

NDFC は、VMware vCenter や OpenStack などの登録済み VMM ドメインと、Kubernetes などのコンテナ オーケストレーターから取得した情報を関連付けることにより、統合されたホストおよび物理ネットワーク トポロジ ビューを提供します。

これはオプションの機能です。

- 次のポートは、一部の NDFC サービスで使用される、永続的 IP とも呼ばれる外部サービス IP に適用されます。

これらの外部サービス IP は、構成された設定に応じて、Nexus Dashboard の管理サブネット プールまたはデータ サブネット プールから取得できます。

単一ノード クラスタでの SAN 展開向けの Nexus Dashboard Fabric Controller 永続的 IP ポート

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

SCP

22

TCP

入力

SCP は、デバイスと NDFC サービス間でファイルを転送するさまざまな機能によって使用されます。NDFC SCP サービスは、ダウンロードとアップロードの両方で機能します。

Syslog

514

UDP

入力

NDFC が Syslog サーバーとして構成されている場合、デバイスからの syslog は、SNMP-Trap/Syslog サービス ポッドに関連付けられた永続的 IP に向けて送信されます。

NDFC の SNMP-Trap-Syslog サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。これは、NDFC サーバー設定の [LAN デバイス管理接続（LAN Device Management Connectivity）] 設定によって制御されます。

SNMP トラップ

2162

UDP

入力

デバイスから NDFC への SNMP トラップは、SNMP-Trap/Syslog サービス ポッドに関連付けられた永続的な IP に向けて送信されます。

NDFC の SNMP-Trap-Syslog サービスには、管理サブネットまたはデータ サブネットのいずれかに関連付けられた永続的な IP があります。

GRPC（テレメトリ）

33000

TCP

入力

NDFC 永続的 IP に関連付けられた GRPC トランスポートを介して SAN データ (ストレージ、ホスト、フローなど) を受信する SAN Insights Telemetry サーバー。

これは、SAN 展開でのみ有効です。

Chapter5. 前提条件：オーケストレータ

- Orchestrator の要件

- Orchestrator の通信ポート

- オーケストレータのファブリック要件

Orchestrator の要件

（注）

このセクションでは、Orchestrator サービスを有効にする場合の追加の要件とガイドラインについて説明します。すべての有効なサービスの前提条件と注意事項 セクションに記載されているプラットフォーム レベルの要件をすでに満たしていることを確認します。

- Nexus Dashboard リリース 3.1.1 以降、サービスを個別にダウンロードする必要がなくなったため、Cisco DC App Center 接続は Nexus Dashboard から削除されました。

Orchestrator を展開するには、[ソフトウェアのダウンロード（Software Download）] ページから統合インストール イメージをダウンロードします。個々のサービスのインストール イメージは、Cisco DC App Center から入手できなくなりました。

- Cisco ACI ファブリックを管理するために Nexus Dashboard Orchestrator を展開する場合は、データ インターフェイスまたは管理インターフェイスから各ファブリックの APIC のインバンドまたはアウトオブバンド（OOB）インターフェイスまたは両方への接続を確立できます。

ファブリック接続が Nexus ダッシュボードの管理インターフェイスからのものである場合は、特定のスタティック ルートを設定するか、管理インターフェイスが APIC インターフェイスの同じ IP サブネットの一部であることを確認する必要があります。

- Cisco NDFC ファブリックを管理するために Nexus Dashboard Orchestrator を展開する場合は、データネットワークから Cisco NDFC ファブリックにインバンドで到達できる必要があります。

- 両方のネットワークでノード間の接続が必要です。そして、次の追加のラウンド トリップ時間（RTT）要件があります。

Orchestrator RTT の要件

接続

最大 RTT

管理対象 APIC ファブリックへ

500 ミリ秒

管理対象 NDFC ファブリックへ

150 ミリ秒

Orchestrator の通信ポート

上記の Nexus Dashboard クラスタ ノードに必要なポート（前のセクションに記載）に加えて、Orchestrator サービスには次のポートが必要です。

Nexus Dashboard Orchestrator ポート（管理ネットワーク）

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

SCP または SFTP

22

TCP

入力／出力

バックアップを保存し、ソフトウェア アップグレード イメージをダウンロードするためのリモート サーバー

HTTP

80

TCP

発信

外部ログストリーミングが有効になっている場合は、Splunk または syslog サーバー

HTTPS

443

TCP

入力／出力

外部ログストリーミングが有効になっている場合は、Splunk または syslog サーバー

Nexus Dashboard Orchestrator ポート（データ ネットワーク）

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

HTTPS

443

TCP

発信

スイッチと APIC の帯域内

Kafka

3001

TCP

入力／出力

スイッチと APIC/NDFC の帯域内 IP

オーケストレータのファブリック要件

次の追加のファブリック関連のガイドラインがオーケストレータ サービスに適用されます。

- Cisco Mini ACI ファブリックは、追加の構成を必要とせずに、一般的なオンプレミス ファブリックとしてサポートされます。

このタイプのファブリックの導入と設定に関する詳細情報は、Cisco Mini ACI ファブリックおよび仮想 APICに記述されています。

- リモート リーフ スイッチを含む ACI ファブリックを管理している場合は、次の制限が適用されます。

- 物理リモート リーフ スイッチのみがサポートされます。

- -EX および -FX 以降のスイッチのみが、リモート リーフ スイッチとしてサポートされています。

- リモート リーフは、IPN スイッチを使用しないバックツーバック接続ファブリックではサポートされていません。

- 1 つのファブリックのリモート リーフ スイッチで別のファブリックの L3Out を使用することはできません。

- あるファブリック（ローカル リーフまたはリモート リーフ）と別のファブリックのリモート リーフ間のブリッジ ドメインの拡張はサポートされていません。

また、Nexus Dashboard Orchestrator でファブリックを追加して管理するには、その前に次のタスクを実行する必要があります。

- ファブリックの APIC でリモート リーフの直接通信を直接有効にする必要があります。

直接通信を有効にするには、ファブリックの APIC にログインし、[システム（System）] > [システム設定（System Settings）] > [ ファブリック全体の設定（Fabric Wide Setting）]を選択し、[リモート リーフ直接トラフィック転送を有効にする（Enable Remote Leaf Direct Traffic Forwarding）] をオンにします。

（注）

有効にした後は、このオプションを無効にすることはできません。

- リモート リーフ スイッチの外部 TEP プールを設定する必要があります。

1 つ以上の外部 TEP プールを構成するには、ファブリックの APIC にログインし、[ファブリック（Fabric）] > [インベントリ（Inventory）] > [ポッド ファブリック セットアップ ポリシー（Pod Fabric Setup Policy）]に移動します。次に、サブネットを設定するポッドをダブルクリックし、[外部 TEP（External TEP）] 領域で [+] をクリックします。最後に、[IP]アドレスと[予約アドレスの数（Reserve Address Count）]を入力し、状態を [アクティブ（Active）] または [非アクティブ（Inactive）] に設定してから、[更新（Update）] をクリックしてサブネットを保存します。

ルーティング可能な TEP プールを設定する場合は、 /22 から /29 の範囲のネットマスクを指定する必要があります。異なる時点を含め、複数の非連続外部 TEP プールを設定できます。

- リモート リーフ スイッチに接続しているレイヤ 3 ルータのインターフェイスに適用されている DHCP リレー設定で、APIC ノード（定義済み外部 TEP プールから割り当てられたもの）のルーティング可能な IP アドレスを追加する必要があります。

各 APIC ノードのルーティング可能な IP アドレスは、APIC GUI の [システム（System）] > [コントローラ（Controllers）] > [<controller-name>]画面の [ルーティング可能 IP アドレス（Routable IP Address）] フィールドに表示されます。

- 次のセクションの説明に従って、ポッド プロファイル、ポリシー グループ、およびファブリック アクセス ポリシーを設定する必要があります。

- ポッド プロファイルとポリシー グループ

- ファブリック アクセス グローバル ポリシーの設定

- ファブリック アクセス インターフェイス ポリシーの設定

ポッド プロファイルとポリシー グループ

各ファブリックの APIC には、ポッド ポリシー グループを持つポッド プロファイルが 1 つ必要です。ファブリックにポッド ポリシー グループがない場合は、作成する必要があります。通常、これらの設定はすでに存在していて、ファブリックを最初に展開したときに設定したとおりになっているはずです。

手順

ステップ 1

ファブリックの APIC GUI にログインします。

ステップ 2

ポッド プロファイルにポッド ポリシー グループが含まれているかどうかを確認します。

[ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [プロファイル (Profiles)] > [ポッドのプロファイルのデフォルト (Pod Profile default)]に移動します。

ステップ 3

必要であれば、ポッド ポリシー グループを作成します。

1. [ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [ポリシー グループ (Policy Groups)]に移動します。

2. [ポリシー グループ (Policy Groups)] を右クリックし、[ポッド ポリシー グループの作成 (Create Pod Policy Groups)] を選択します。

3. 適切な情報を入力して、[Submit] をクリックします。

ステップ 4

新しいポッド ポリシー グループをデフォルトのポッド プロファイルに割り当てます。

1. [ファブリック (Fabric)] > [ファブリック ポリシー (Fabric Policies)] > [ポッド (Pods)] > [プロファイル (Profiles)] > [ポッド プロファイルのデフォルト (Pod Profile default)] に移動します。

2. デフォルトのプロファイルを選択します。

3. 新しいポッド ポリシー グループを選択し、[更新 (Update)] をクリックします。

ファブリック アクセス グローバル ポリシーの設定

このセクションでは、Nexus Dashboard クラスタにオンボードし、Nexus Dashboard Orchestrator で管理する前に、APIC ファブリックごとに作成する必要があるグローバル ファブリック アクセス ポリシーの構成について説明します。

手順

ステップ 1

ファブリックの APIC GUI にログインします。

ステップ 2

メイン ナビゲーション メニューから、[ファブリック (Fabric)] > [アクセス ポリシー (Access Policies)] を選択します。

ファブリックを Nexus Dashboard Orchestrator で管理するには、いくつかのファブリック ポリシーを構成する必要があります。APIC の観点からは、ベアメタル ホストを接続していた場合と同様に、ドメイン、AEP、ポリシー グループ、およびインターフェイス セレクタを構成することができます。同じマルチフサイト ドメインに属するすべてのファブリックに対して、スパイン スイッチ インターフェイスをファブリック間ネットワークに接続するための同じオプションを構成する必要があります。

ステップ 3

VLAN プールを指定します。

最初に設定するのは、VLAN プールです。レイヤ 3 サブインターフェイスは VLAN 4 を使用してトラフィックにタグを付け、スパイン スイッチをファブリック間ネットワークに接続します。

1. 左側のナビゲーション ツリーで、[プール (Pools)] > [VLAN] を参照します。

2. [VLAN] カテゴリを右クリックし、[VLAN プールの作成 (Create VLAN Pool)] を選択します。

[VLAN プールの作成 (CREATE VLAN Pool)] ウィンドウで、次の項目を指定します。

- [名前（Name）] フィールドで、VLAN プールの名前（たとえば、 mfabric）を指定します。

- [Allocation Mode (割り当てモード)]の場合は、[スタティック割り当て(Static Allocation)]を指定します。

- [Encap ブロック(Encap Blocks)] の場合は、単一の VLAN 4 だけを指定します。両方の [Range (範囲)] フィールドに同じ番号を入力することによって、単一の VLAN を指定できます。

ステップ 4

接続可能アクセス エンティティ プロファイル (AEP) を作成します。

1. 左側のナビゲーションツリーで、[グローバル ポリシー (Global Policies)] > [接続可能なアクセス エントリ プロファイル (Attachable Access Entity Profiles)] を参照します。

2. [接続可能なアクセス エンティティ プロファイル (Attachable Access Entry Profiles)] を右クリックして、[接続可能なアクセス エンティティ プロファイルの作成 (Create Attachable Access Entity Profiles)] を選択します。

[接続可能アクセス エンティティ プロファイルの作成（Create Attachable Access Entity Profiles）] ウィンドウで、AEP の名前（例：mfabric-aep）を指定します。

3. [次へ(Next)]] をクリックして [送信(Submit)] します。

インターフェイスなどの追加の変更は必要ありません。

ステップ 5

外部ルーテッド ドメインを設定します。

構成するドメインは、このファブリックを追加するときに、Nexus Dashboard Orchestrator から選択するものになります。

1. ナビゲーション ツリーで、[物理的ドメインと外部ドメイン (Physical and External Domains)] > [外部でルーテッド ドメイン (External Routed Domains)] を参照します。

2. [外部ルーテッド ドメイン(External Routed Domains)] カテゴリを右クリックし、[レイヤ 3 ドメインの作成 (Create Layer 3 Domain)] を選択します。

[レイヤ 3 ドメインの作成 (Create Layer 3 Domain)] ウィンドウで、次の項目を指定します。

- [名前（Name）] フィールドで、ドメインの名前を指定します。たとえば、[mfabric-l3] です。

- 関連付けられている接続可能エンティティ プロファイルの場合は、ステップ 4で作成した AEP を選択します。

- VLAN プールの場合は、ステップ 3で作成した VLAN プールを選択します。

3. [送信 (Submit)] をクリックします。

セキュリティ ドメインなどの追加の変更は必要ありません。

次のタスク

グローバル アクセス ポリシーを設定した後も、ファブリック アクセス インターフェイス ポリシーの設定 の説明に従って、インターフェイス ポリシーを追加する必要があります。

ファブリック アクセス インターフェイス ポリシーの設定

このセクションでは、各 APIC ファブリックの Nexus Dashboard Orchestrator で行わなければならないファブリック アクセス インターフェイスの設定について説明します。

始める前に

ファブリックの APIC では、ファブリック アクセス グローバル ポリシーの設定 の説明に従って、VLAN プール、AEP、および ドメインなどのグローバル ファブリック アクセス ポリシーを設定しておく必要があります。

手順

ステップ 1

ファブリックの APIC GUI にログインします。

ステップ 2

メイン ナビゲーション メニューから、[ファブリック (Fabric)] > [アクセス ポリシー (Access Policies)] を選択します。

前のセクションで構成した VLAN、AEP、およびドメインに加えて、ファブリック間ネットワークに接続するファブリックのスパイン スイッチ インターフェイスに対してインターフェイス ポリシーを作成します。

ステップ 3

スパイン ポリシー グループを設定します。

1. 左ナビゲーション ツリーで、[インターフェイス ポリシー (Interface Policie)] > [ポリシー グループ (Policy Groups)] > [スパイン ポリシー グループ (Spine Policy Groups)] を参照します。

これは、ベアメタル サーバを追加する方法と類似していますが、リーフ ポリシー グループの代わりにスパイン ポリシー グループを作成する点が異なります。

2. [スパイン ポリシー グループ (Spine Policy Groups)] カテゴリーを右クリックして、[スパイン アクセス ポート ポリシー グループの作成 (Create Spine Access Port Policy Group)] を選択します。

[スパイン アクセス ポリシー グループの作成 (Create Spine Access Port Policy Group)]ウィンドウで、以下のとおり指定します。

- [名前 (Name)] フィールドの場合、ポリシー グループの名前を指定します。たとえば Spine1-PolGrp です。

- [リンク レベル ポリシー (Link Level Policy)] フィールドには、スパイン スイッチと ISN の間のリンク ポリシーを指定します。

- [CDP ポリシー (CDP Policy)] の場合、CDP を有効にするかどうかを選択します。

- [アタッチしたエンティティ プロファイル（Attached Entity Profiel）] の場合、前のセクションで設定した AEP を選択します。たとえば mfabric-aep です。

3. [送信 (Submit)] をクリックします。

セキュリティ ドメインなどの追加の変更は必要ありません。

ステップ 4

スパイン プロファイルを設定します。

1. 左ナビゲーション ツリーで、[インターフェイス ポリシー (Interface Policies)] > [ポリシー グループ (Profiles)] > [スパイン ポリシー グループ (Spine Profiles)] を参照します。

2. [プロファイル (Profiles)] カテゴリを右クリックし、[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile] を選択します。

[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile)] ウィンドウで、次のとおり指定します。

- [名前 (name)] フィールドに、プロファイルの名前 (Spine1など) を指定します。

- [インターフェイス セレクタ (Interface Selectors)]では、+ 記号をクリックして、ISN に接続されるスパイン スイッチ上のポートを追加します。次に、[スパイン アクセス ポート セレクターの作成 (Create Spine Access Port Selector)] ウィンドウで、次のように指定します。

- [名前 (name)] フィールドに、ポート セレクタの名前を指定します (例: Spine1)。

- [インターフェイス ID (Interface IDs)] に、ISN に接続するスイッチ ポートを指定します (例5/32)。

- [インターフェイス ポリシー グループ (Interface Policy Group)] に、前の手順で作成したポリシー グループを選択します (例: Spine1-PolGrp)。

それから、[OK] をクリックして、ポート セレクタを保存します。

3. [送信 (Submit)] をクリックしてスパイン インターフェイス プロファイルを保存します。

ステップ 5

スパイン スイッチ セレクタ― ポリシーを設定します。

1. 左ナビゲーション ツリーで、[スイッチ ポリシー (Switch Policies)] > [プロファイル (Profiles)] > [スパイン プロファイル (Spine Profiles)] を参照します。

2. [スパイン プロファイル (Spine Profiles)[ カテゴリを右クリックし、[スパイン プロファイルの作成 (Create Spine Profile)] を選択します。

[スパイン インターフェイス プロファイルの作成 (Create Spine Interface Profile)] ウィンドウで、次のように指定します。

- [名前 (name)] フィールドに、プロファイルの名前を指定します (例: Spine1)。

- [スパインセレクタ (Spine Selectora)]で、[+] をクリックしてスパインを追加し、次の情報を入力します。

- [名前 (name)] フィールドで、セレクタの名前を指定します (例: Spine1) 。

- [ブロック (Blocks)] フィールドで、スパイン ノードを指定します (例: 201)。

3. [更新 (Update)] をクリックして、セレクタを保存します。

4. [次へ (Next)] をクリックして、次の画面に進みます。

5. 前の手順で作成したインターフェイス プロファイルを選択します。

たとえば、Spine1-ISNなどです。

6. [完了 (Finish)] をクリックしてスパイン プロファイルを保存します。

Chapter6. 前提条件：Insights

- Insights の要件

- Insights の通信ポート

- Insights のファブリック要件

Insights の要件

このセクションでは、Insights サービスを有効にする場合の 追加 の要件とガイドラインについて説明します。すべての有効なサービスの前提条件と注意事項 セクションに記載されているプラットフォーム レベルの要件をすでに満たしていることを確認します。

- Nexus Dashboard リリース 3.1.1 以降、サービスを個別にダウンロードする必要がなくなったため、Cisco DC App Center 接続は Nexus Dashboard から削除されました。

Insight を展開するには、[ソフトウェアのダウンロード（Software Download）] ページから、統合インストール イメージをダウンロードします。個々のサービスのインストール イメージは、Cisco DC App Center から入手できなくなりました。

- Nexus Dashboard Insights サービスの場合、データ ネットワークは、次の接続先に対し IP 到達可能である必要があります。

- 各ファブリックと APIC のインバンド ネットワーク。

- DNS サーバー。

- Panduit PDU 統合の場合は、Panduit PDU サーバーへの接続。

- 外部 Kafka 統合の場合は、外部 Kafka サーバー（コンシューマ）への接続。

- SysLog 統合の場合は、SysLog サーバーへの接続。

- ネットワーク接続ストレージ統合の場合は、ネットワーク接続ストレージ サーバーへの接続。

- VMware vCenter 統合の場合は、 VMware vCenter に移動します。

- AppDynamics 統合の場合は、AppDynamics コントローラへの接続。

- NDFC ファブリックで Insights サービスを使用している場合、または SFLOW/NetFlow を有効にしている場合、データ ネットワーク インターフェイスはレイヤ 2 隣接である必要があります。

- ユースケースに応じて、次の数の永続 IP アドレスを割り当てる必要があります。

永続 IP 機能の概要については、すべての有効なサービスの前提条件と注意事項 を参照してください。

Cisco ACI ファブリックの場合：

- Netflow または Panduit PDU 統合を使用しない Nexus Dashboard Insights：データ ネットワークに IP は必要ありません。

- Panduit PDU 統合を使用する Nexus Dashboard Insights：IPv4 を使用している場合、1 IP。純粋な IPv6 スタックでは統合はサポートされていません。

- Netflow を使用し、Panduit PDU 統合を使用する/使用しない Nexus Dashboard Insights：IPv4 を使用している場合、データ ネットワーク内に 8 IP。IPv6 を使用している場合、6 IP。

NDFC ファブリックの場合：

- IPv4 を使用している場合、データ ネットワーク内に 8 IP アドレス。IPv6 を使用している場合、6 IP アドレス。

スタンドアロン NX-OS スイッチの場合：

- IPv4 を使用している場合、データ ネットワーク内に 10 IP アドレス。IPv6 を使用している場合、8 IP アドレス。

永続的な IP アドレスの割り当ては、『Cisco Nexus ダッシュボード ユーザ ガイド』で説明されているように、UI の外部サービス プール設定を使用してクラスタが展開された後に行われます。

- 両方のネットワークでノード間の接続が必要です。そして、次の追加のラウンド トリップ時間（RTT）要件があります。

Insights の RTT 要件

接続

最大 RTT

スイッチ

150 ミリ秒

- Nexus Dashboard Insights は、レイヤ 3 隣接関係をサポートしていません。

Insights の通信ポート

上記の Nexus Dashboard クラスタ ノードに必要なポート（前のセクションに記載）に加えて、Insights サービスには次のポートが必要です。

（注）

デフォルトでは、Insights は、Nexus Dashboard クラスタノードのデータインターフェイスとスイッチのインバンド IP 間の接続のみを必要とします。ただし、スイッチが使用できなくなった場合、Insights はクラスタ ノードの管理またはデータ インターフェイス（ルート設定に応じて決まる）を使用してスイッチの OOB IP に接続しようとします。

Nexus Dashboard Insights ポート（データ ネットワーク）

サービス

ポート

プロトコル

方向

イン：クラスタに対して

アウト：クラスタからファブリックまたは世界外に対して

接続

テックコレクションを表示

2022

TCP

入力／出力

スイッチと APIC/NDFC の帯域内

フローテレメトリ

5640 ～ 5671

UDP

入力

スイッチの帯域内

TAC アシスト

8884

TCP

入力／出力

その他のクラスタ ノード

KMS

9989

TCP

入力／出力

その他クラスタ ノードおよび ACI ファブリック

Kafka

30001

TCP

入力／出力

スイッチと APIC/NDFC の帯域内 IP

SW テレメトリ

5695

30000

57500

30570

TCP

入力／出力

その他のクラスタ ノード

Insights のファブリック要件

ACI ファブリックの追加の前提条件

ACI ファブリックで Insights サービスを使用する場合は、次のことを確認します。

- NDFC ファブリックをACIファブリックと同じクラスタに導入準備しないでください。

- スタンドアロン NX-OS スイッチを ACI ファブリックと同じクラスタに搭載することは可能ですが、スケールは縮小され、物理クラスタのみになります。

- 3 ノード クラスタの場合、最大 15 台のスタンドアロン NX-OS スイッチ（サポートされる合計 300 台のスイッチのうち）を使用できます。

- 6 ノード クラスタの場合、最大 50 台のスタンドアロン NX-OS スイッチ（サポートされる合計 1000 台のスイッチのうち）を使用できます。

- Cisco APICでNTP設定を構成しておきます。

詳細については、ACI ファブリックソリューションでのNTPの設定を参照してください。

- Nexus Dashboard Insights でフロー テレメトリ機能を使用する計画の場合には、ACI ファブリック ノード制御ポリシーでテレメトリの優先順位を選択する必要があります。

Cisco APIC で、テレメトリの優先順位を選択するには、[ファブリック（Fabric）] > [ファブリック ポリシー（Fabric Policies）] > [ポリシー（Policies）] > [モニタリング（Monitoring）] > [ファブリック ノードの制御（Fabric Node Controls）] > [<policy-name>] > [機能選択（Feature Selection）]の順に選択します。<policy-name> のモニタリングは、[ファブリック（Fabric）] > [ ファブリック ポリシー（Fabric Policies）] > [スイッチ] > [リーフ/スパイン スイッチ（Leaf/Spine Switches）] > [プロファイル（Profiles）] > に続ける必要があります。

- Nexus Dashboard Insights でフローテレメトリ機能を使用する計画の場合には、Cisco APIC で Precision Time Protocol（PTP）を有効にして、Nexus Dashboard Insights が複数のスイッチからのフローを相互に適切に関連付けることができるようにする必要があります。

Cisco APIC で、[システム（System）] > [システム設定（System Settings）] > [PTP および遅延測定（PTP and Latency Measurement）] > [管理状態（Admin State）]の順に選択し、PTP を有効にします。

PTP による時刻同期の品質は、クロックのソースである PTP グランドマスター（GM）クロックの精度、およびその間の ACI スイッチや IPN デバイスなどの PTP デバイスの精度と数に依存します。

PTP GM デバイスには通常、PTP の標準要件であるナノ秒単位の精度を実現する GNSS/GPS ソースが装備されていますが、Nexus Dashboard Insights とそのフローテレメトリではマイクロ秒単位の精度で十分であるため、通常は GNSS/GPS ソースは必要ありません。

シングルポッド ACI ファブリックの場合、リーフスイッチを介して PTP GM を接続できます。それ以外の場合、スパインスイッチの1つがGMとして選出されます。マルチポッド ACI ファブリックの場合、リーフスイッチまたは IPN デバイスを介して PTP GM を接続できます。ACI スイッチノードがポッド間でクロックを同期できるように、IPN デバイスは PTP 境界クロックまたは PTP Transparent Clock にする必要があります。ポッド全体で同じ精度を維持するため、IPNデバイスを介してPTP GMを接続することをお勧めします。

PTP 接続オプションの詳細については、『Cisco APIC System Management Configuration Guide』の「Precision Time Protocol」の項を参照してください。

- Cisco APIC および静的管理アクセスの説明に従って、インバンド管理を構成しておきます。

- DNSプロファイルの下に1つ以上のDNSドメインが設定されている場合、1つのDNSドメインをデフォルトとして設定することが必須です。

Cisco APIC で、[ファブリック（Fabric）] > [ファブリックポリシー（Fabric Policies）] > [ポリシー（Policies）] > [グローバル（Global）] > [DNSプロファイル（DNS Profile）] > [デフォルト（Default）] > [DNS ドメイン（DNS Domains）]の順に選択し、デフォルトとして 1 つを設定します。

これを行わないと、同じスイッチが Nexus Dashboard Insights のフローマップに複数回表示されます。

- 次を使用して EPG を設定することにより、ACI インバンド ネットワークを展開します。

- テナント = mgmt

- VRF = inb

- BD = inb

- ノード管理 EPG = デフォルト/<any_epg_name>

- Nexus ダッシュボードのデータ ネットワーク IP アドレスと ACI ファブリックのインバンド IP アドレスは、異なるサブネットにある必要があります。

NDFC ファブリックまたはスタンドアロン NX-OS スイッチの追加の前提条件

NDFC ファブリックまたはスタンドアロン NX-OS スイッチで Insights サービスを使用する場合は、次のことを確認します。

- NDFC ファブリックとして同じクラスタに ACI ファブリックを導入準備しないでください。

- NDFC ファブリックとして同じクラスタにスタンドアロン NX-OS スイッチを導入準備しないでください。

- スタンドアロン NX-OS スイッチを ACI ファブリックと同じクラスタに搭載することは可能ですが、スケールは縮小され、物理クラスタのみになります。

- 3 ノード クラスタの場合、最大 15 台のスタンドアロン NX-OS スイッチ（サポートされる合計 300 台のスイッチのうち）を使用できます。

- 6 ノード クラスタの場合、最大 50 台のスタンドアロン NX-OS スイッチ（サポートされる合計 1000 台のスイッチのうち）を使用できます。

- データ ネットワークが、ファブリックのインバンドまたはアウトオブバンド IP アドレスへの IP 到達可能性を備えている必要があります。

（注）

フロー テレメトリ機能を使用している場合、データ ネットワークがファブリックの帯域内 IP アドレスへの IP 到達可能性を備えている必要があります。

- フロー テレメトリまたはトラフィック分析を有効にするには、Nexus Dashboard Insights でサポート対象にするすべてのノードで Precision Time Protocol（PTP）を構成する必要があります。

管理ファブリック モードとモニタ ファブリック モードの両方で、ファブリック内のすべてのノードで PTP が正しく構成されていることを確認する必要があります。NDFC Easy ファブリック セットアップの [詳細（Advanced）] タブで PTP を有効にするには、[精密時間プロトコル（PTP）を有効にする（Enable Precision Time Protocol） ] オプションをオンにします。

PTP グランドマスター クロックは、ネットワーク ファブリックの外部にあるデバイスによって提供される必要があります。Cisco Nexus 9000 シリーズ スイッチを PTP グランドマスターとして使用することはサポートされていません。

（注）

ファブリック内の N9k-C93180YC-FX3 スイッチは、PTP GM として使用できます。

PTP による時刻同期の品質は、クロックのソースである PTP グランドマスター（GM）クロックの精度、およびネットワークパスに沿った PTP デバイスの精度と数によって異なります。PTP GM デバイスは一般に、PTP の標準要件であるナノ秒精度を達成するために GNSS/GPS ソースを備えていますが、Nexus Dashboard Insights とそのフローテレメトリにはマイクロ秒精度で十分であるため、通常は GNSS/GPS ソースは不要です。

Precision Time Protocol の詳細については、Cisco NDFC LAN ファブリック コントローラ 構成ガイドを参照してください。

Nexus スイッチでの Precision Time Protocol の手動構成の詳細については、Cisco Nexus 9000 シリーズ NX-OS システム管理設定ガイドを参照してください。

PartII. クラスタの展開

- 物理アプライアンスとしての展開

- VMware ESX の展開

- Linux KVMでの展開

- Amazon Web Services での展開

- Microsoft Azure での展開

- ファブリックのオンボーディング

Chapter7. 物理アプライアンスとしての展開

- 物理アプライアンスとして Nexus Dashboard を展開する場合の前提条件と注意事項

- 物理ノードのケーブル接続

- 物理アプライアンスとしての Nexus ダッシュボードの展開

物理アプライアンスとして Nexus Dashboard を展開する場合の前提条件と注意事項

Nexus ダッシュボード クラスタの展開に進む前に、次の手順を実行する必要があります。

- 前提条件：Nexus Dashboard に記載されている一般的な前提条件およびサービス固有の前提条件を確認して完了します。

- 展開予定のサービスのリリース ノートに説明されている追加の前提条件を確認し、条件を満たすようにしてください。

サービス固有のドキュメントは、次のリンクで見つけることができます。

- Nexus Dashboard ファブリック コントローラ、リリース ノート

- Nexus Dashboard Insights リリース ノート

- Nexus Dashboard Orchestrator リリース ノート

- 使用しているサーバーのモデルに対応した、Cisco Nexus Dashboard ハードウェア セットアップ ガイドの説明に従って、以下のハードウェアを使用しており、サーバがラックに接続されていることを確認します。

物理アプライアンス フォーム ファクタは、UCS-C220-M5（SE-NODE-G2）および UCS-C225-M6（ND-NODE-L4）のオリジナルの Cisco Nexus Dashboard プラットフォーム ハードウェアでのみサポートされます。次の表に、サーバの物理的アプライアンス サーバの PID と仕様を示します。

サポートされる UCS-C220-M5 ハードウェア

製品 ID

ハードウェア

SE-NODE-G2

- Cisco UCS C220 M5シャーシ

- 2 X 10 コア 2.2 GHz Intel Xeon Silver CPU

- 256 GB の RAM

- 4 x 2.4-TB HDD

400-GB SSD

1.2 TB NVME ドライブ

- Cisco UCS 仮想インターフェイス カード 1455（4x25G ポート）

- 1050W 電源モジュール

SE-CL-L3

3 台の SE-NODE-G2= アプライアンスのクラスタ。

サポートされる UCS-C225-M6 ハードウェア

製品 ID

ハードウェア

ND-NODE-L4

- Cisco UCS C225 M6 シャーシ

- 2.8 GHz AMD CPU

- 256 GB の RAM

- 4 x 2.4-TB HDD

960-GB SSD

1.6 TB NVME ドライブ

- Intel X710T2LG 2x10 GbE（銅）

- 次のいずれかが必要です。

- Intel E810XXVDA2 2x25/10 GbE（光ファイバ）

- Cisco UCS 仮想インターフェイス カード 1455（4x25G ポート）

- 1050W 電源モジュール

ND-CLUSTER-L4

3 台の ND-NODE-L4= アプライアンスのクラスタ。

（注）

上記のハードウェアは、Cisco Nexus Dashboard ソフトウェアのみをサポートします。他のオペレーティングシステムがインストールされている場合、そのノードは Cisco Nexus Dashboard ノードとして使用できなくなります。

- Cisco Integrated Management Controller（CIMC）のサポートされているバージョンを実行していることを確認します。

CIMC のサポートおよび推奨される最小バージョンは、Cisco Nexus Dashboard リリースの リリース ノート の「互換性」セクションにリストされています。

- サーバーの CIMC の IP アドレスが構成済みであることを確認します。

Cisco Integrated Management Controller IP アドレスの構成を参照してください。

- Serial over LAN（SOL）が CIMC で有効になっていることを確認します。

Cisco Integrated Management Controller に対する Serial over LAN の有効化を参照してください。

ブートストラップ ピア ノード ポイントでブートストラップが次のエラーで失敗した場合は、SoL の構成が間違っている可能性があります。

Waiting for firstboot prompt on NodeX

- すべてのノードが同じリリース バージョン イメージを実行していることを確認します。

- Cisco Nexus Dashboard ハードウェアに、展開するイメージとは異なるリリース イメージが付属している場合は、まず既存のイメージを含むクラスタを導入してから、必要なリリースにアップグレードすることをお勧めします。

たとえば、受け取ったハードウェアにリリース 2.3.2 のイメージがプリインストールされているが、代わりにリリース 3.2.1 を展開する場合は、次の手順に従います。

1. 最初に、リリース 2.3.2 クラスタをそのリリースの展開ガイドに従って起動します。

2. 既存の ND クラスタをこのリリースへアップグレード の説明に従って、リリース 3.2.1 にアップグレードします。

（注）

まったく新しい展開の場合は、このドキュメントに戻ってクラスタを展開する前に、Cisco Nexus Dashboard の最新バージョンを使用してノードを再イメージ化することもできます（たとえば、GUI ワークフローを通じたこのリリースへの直接アップグレードをサポートしていないイメージがハードウェアに付属している場合）。このプロセスについては、このリリースのトラブルシューティングの記事の「ノードの再イメージング」セクションで説明されています。

- 少なくとも 3 ノードのクラスタが必要です。展開するサービスの数に応じて、水平スケーリング用に追加のセカンダリ ノードを追加できます。単一クラスター内のセカンダリ ノードとスタンバイ ノードの最大数については、ご使用のリリースのリリース ノートを参照してください。

- Cisco Integrated Management Controller IP アドレスの構成

- Cisco Integrated Management Controller に対する Serial over LAN の有効化

Cisco Integrated Management Controller IP アドレスの構成

以下の手順に従い、Cisco Integrated Management Controller（CIMC）IP アドレスを構成します。

手順

ステップ 1

サーバの電源をオンにします。

ハードウェア診断が完了すると、機能（Fn）キーによって制御されるさまざまなオプションが表示されます。

ステップ 2

F8 キーを押して Cisco IMC 構成ユーティリティを起動します。

ステップ 3

次のサブステップに従います。

1. NIC モードを専用モードに設定します。

2. IPv4 IP モードと IPv6 IP モードのいずれかを選択します。

DHCP を有効にするか無効にするかを選択できます。DHCP を無効にする場合は、静的 IP アドレス、サブネット、およびゲートウェイ情報を指定します。

3. [NIC 冗長性（NIC Redundancy）] で、[Active-active [x]] を選択します。

4. ホスト名、DNS、デフォルト ユーザー パスワード、ポート プロパティ、ポート プロファイルのリセットなどのその他のオプションを表示するには、 F1 を押します。

ステップ 4

F10 を押して、構成を保存し、サーバーを再起動します。

Cisco Integrated Management Controller に対する Serial over LAN の有効化

Serial over LAN（SoL）は、基本的な構成情報を提供するために物理アプライアンス ノードに接続するのに使用する connect host コマンドに必要です。SoL を使用するには、まず Cisco Integrated Management Controller （CIMC）で SoL を有効にする必要があります。

Cisco Integrated Management Controller で Serial over LANを有効にするには、次の手順に従います。

手順

ステップ 1

CIMC IP アドレスを使用してノードに SSH 接続し、サインイン情報を入力します。

ステップ 2

次のコマンドを実行します。

Server# scope sol
Server /sol # set enabled yes
Server /sol *# set baud-rate 115200
Server /sol *# commit
Server /sol *#
Server /sol # show

C220-WZP23150D4C# scope sol
C220-WZP23150D4C /sol # show

Enabled Baud Rate(bps)  Com Port SOL SSH Port
------- --------------- -------- -------------
yes     115200          com0     2400

ステップ 3

コマンド出力で、 com0 が SoL の comポートであることを確認します。

これにより、システムはCIMC CLI から connect host コマンドを使用してコンソールをモニタできます。これは、クラスタの起動に必要です。

物理ノードのケーブル接続

物理ノードは、次のガイドラインに従って、UCS-C220-M5（SE-NODE-G2）および UCS-C225-M6（ND-NODE-L4）物理サーバーに展開できます。

ノード接続に使用される mLOM および PCIe ライザー 01 カード

- 両方のサーバーに、Nexus Dashboard 管理ネットワークへの接続に使用する Modular LAN on Motherboard (mLOM) カードが付属しています。

- UCS-C220-M5 サーバーには、「PCIe-Riser-01」スロットに 4 ポートの VIC1455 カードが含まれており (上の図を参照)、Nexus Dashboard のデータ ネットワーク接続に使用します。

- UCS-C225-M6 サーバーには、 2x10GbE NIC (APIC-P-ID10GC) または 2x25/10GbE SFP28 NIC（APIC-P-I8D25GF）、または「PCIe-Riser-01」スロット（上の図に表示）の VIC1455 カードに含まれており、Cisco Nexus Dashboard のデータ ネットワーク接続に使用します。

ノードを管理ネットワークおよびデータ ネットワークに接続する場合：

- インターフェイスは、アクティブ/スタンバイ モードで実行されている、データインターフェイス用と管理インターフェイス用の Linux ボンドとして設定されます。

- 管理ネットワークの場合：

- mLOM カードで mgmt0 および mgmt1 を使用する必要があります。

- すべてのポートが同じ速度（1G または 10G）である必要があります。

- データ ネットワークの場合：

- UCS-C220-M5 サーバーでは、VIC1455 カードを使用する必要があります。

- UCS-C225-M6 サーバーで、2x10GbE NIC (APIC-P-ID10GC)、または 2x25/10GbE SFP28 NIC (APIC-P-I8D25GF)、または VIC1455 カードを使用できます。

（注）

25G Intel NIC を使用して接続する場合は、NIC の設定と一致するようにスイッチポートの FEC 設定を無効にする必要があります。

(config-if)# fec off
# show interface ethernet 1/34
Ethernet1/34 is up
admin state is up, Dedicated Interface
[...]
FEC mode is off

- すべてのインターフェイスは、個々のホストに向けたスイッチ ポートに接続する必要があります。PortChannel (PC) および Virtual PortChannel (vPC) はサポートされていません。

- すべてのポートは、10G または 25G のいずれかの同じ速度である必要があります。

- ポート 1 は Nexus Dashboard の fabric0 に対応し、ポート 2 は fabric1 に対応します。

データ ネットワーク接続には、fabric0 と fabric1 の両方を使用できます。

（注）

4 ポート カードを使用する場合、ポートの順序は、使用しているサーバーのモデルによって異なります。

- UCS-C220-M5 サーバーでは、左から右に、ポート 1、ポート 2、ポート 3、ポート 4 です。

- UCS-C225-M6 サーバーでは、左から右に、ポート 4、ポート 3、ポート 2、ポート 1 です。

- ノードを Cisco Catalyst スイッチに接続する場合は、 switchport voice vlan dot1p コマンドをスイッチ インターフェイスに追加する必要があります。

Cisco Catalyst スイッチに接続されている場合、VLAN が指定されていない場合、パケットは vlan0 でタグ付けされます。この場合、データ ネットワーク上での到達可能性を確保するために、ノードが接続されているスイッチ インターフェイスに switchport voice vlan dot1p コマンドを追加する必要があります。

物理アプライアンスとしての Nexus ダッシュボードの展開

Nexus ダッシュボードの物理ハードウェアを最初に受け取ると、ソフトウェア イメージがプリロードされています。ここでは、最初の Nexus Dashboard クラスタを設定して起動する方法について説明します。

始める前に

- 物理アプライアンスとして Nexus Dashboard を展開する場合の前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

最初のノードの基本情報を設定します。

この手順で説明するように、1 つの（「最初の」）ノードのみを構成する必要があります。他のノードは、次の手順で説明する GUI ベースのクラスタ展開プロセス中に構成され、最初の プライマリ ノードからの設定を受け入れます。他の 2 つの プライマリ ノードには、CIMC IP アドレスが最初の プライマリ ノードから到達可能であり、ログイン クレデンシャルが設定されていることと、データ ネットワーク上でノード間のネットワーク接続が確立されていることを確認する以外に、追加の設定は必要ありません。

1. CIMC 管理 IP を使用してノードに SSH 接続し、connect host コマンドを使用してノードのコンソールに接続します。

C220-WZP23150D4C# connect host
CISCO Serial Over LAN:
Press Ctrl+x to Exit the session

ホストに接続したら、 Enter を押して続行します。

2. Nexus Dashboard セットアップ ユーティリティのプロンプトが表示されたら、 Enterを押します。

Starting Nexus Dashboard setup utility
Welcome to Nexus Dashboard 3.2.1
Press Enter to manually bootstrap your first master node...

3. admin パスワードを入力して確認します。

このパスワードは、rescue-user CLI ログインおよび初期 GUI パスワードに使用されます。

Admin Password:
Reenter Admin Password:

4. 管理ネットワーク情報を入力します。

Management Network:
IP Address/Mask: 192.168.9.172/24
Gateway: 192.168.9.1

（注）

純粋な IPv6 モードを構成する場合は、代わりに上記の例の IPv6 を指定します。

5. 入力した譲歩をレビューし、確認します。

入力した情報を変更するかどうかを尋ねられます。すべてのフィールドが正しい場合は、 大文字の N を入力して続行します。入力した情報を変更する場合は、y を入力して基本設定スクリプトを再起動します。

Please review the config
Management network:
Gateway: 192.168.9.1
IP Address/Mask: 192.168.9.172/24

Re-enter config? (y/N): N

ステップ 2

初期ブートストラップ処理が完了するまで待ちます。

最初のノードの管理ネットワーク情報を入力して確認すると、初期セットアップでネットワーキングが設定され、UI が表示されることが分かります。この UI を使用して、他の 2 つのノードを追加して設定し、クラスタの導入を完了します。

Please wait for system to boot: [#########################] 100%
System up, please wait for UI to be online.

System UI online, please login to https://192.168.9.172 to continue.

ステップ 3

ブラウザを開き、https://<node-mgmt-ip> に移動して、GUI を開きます。

残りの設定ワークフローは、ノードの GUI の 1 つから実行します。展開したノードのいずれか 1 つを選択して、ブートストラッププロセスを開始できます。他の 2 つのノードにログインしたり、これらを直接構成したりする必要はありません。

前の手順で入力したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 4

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 5

[ノードの詳細（Node Details）] 画面で、最初のノードの情報を更新します。

前の手順の初期ノード構成時に現在ログインしているノードの管理ネットワークと IP アドレスを定義しましたが、他のプライマリノードを追加し、クラスタを作成する進む前に、ノードのデータ ネットワーク情報も指定する必要があります。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

ノードの[シリアル番号（Serial Number）]、[管理ネットワーク（Management Network）]情報、および[タイプ（Type）]が自動的に入力されます。ただし、他の情報は手動で入力する必要があります。

2. ノードの [名前（Name）] を入力します。

ノードの 名前 はホスト名として設定されるため、 RFC-1123 の要件に従う必要があります。

3. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

4. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

5. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。BGP が構成されている場合は、残りのすべてのノードで BGP を構成する必要があります。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

ステップ 6

[ノードの詳細（Node Details）] 画面で、[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

単一ノード クラスタを展開する場合は、この手順をスキップします。

1. [展開の詳細（Deployment Details）] エリアで、2 番目のノードに [CIMC IP アドレス（CIMC IP Address）]、[ユーザー名（Username）]、[パスワード（Password）] を指定します。

（注）

2 番目のノードの [ユーザー名（Username）] フィールドに、管理者ユーザー識別子 （ローカル ユーザー管理の識別子 1）を入力します。

2. [検証（Validate）] をクリックして、ノードへの接続を確認します。

CIMC 接続が検証されると、ノードの [シリアル番号（Serial Number）] が自動的に入力されます。

3. ノードの [名前（Name）] を入力します。

ノードの 名前 はホスト名として設定されるため、 RFC-1123 の要件に従う必要があります。

4. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

5. [管理ネットワーク（Management Network）] エリアで、ノードの管理ネットワークの情報を提供します。

管理ネットワークの IP アドレス、ネットマスク、ゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

6. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

7. （任意）必要に応じて、データ ネットワークの BGP を有効にします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

9. クラスタの最後の（3 番目の）プライマリ ノードでこの手順を繰り返します。

ステップ 7

（オプション）前の手順を繰り返して、追加のセカンダリ ノードまたはスタンバイ ノードに関する情報を入力します。

（注）

クラスタで複数のサービスを同時に有効にするか、より高いスケールをサポートするには、展開時に十分な数のセカンダリ ノードを提供する必要があります。特定のユースケースに必要な追加のセカンダリノードの詳しい数については、 Nexus Dashboard クラスタ サイジング ツールを参照してください

スタンバイ ノードを今すぐ追加するか、クラスタの展開後に追加するかを選択できます。

ステップ 8

[ノードの詳細（Node Details）] ページで、入力した情報を確認し、[次へ（Next）] をクリックして続行します。

ステップ 9

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

（注）

クラスタ内のノードの数によっては、一部のサービスまたは共同ホスティングのシナリオがサポートされない場合があります。必要な数のサービスを選択できない場合は、[戻る（Back）] をクリックし、前の手順で十分な数のセカンダリ ノードを指定したことを確認します。

クラスタの展開後に展開モードを変更することはできないため、このドキュメントの前の章で説明されているサービス固有の前提条件をすべて満たしていることを確認する必要があります。

- Nexus Dashboard ファブリック コントローラの前提条件

- Nexus Dashboard オーケストレータの前提条件

- Nexus Dashboard Insights の前提条件

2. ファブリック コントローラまたは Insights を含む展開モードを選択した場合は、[永続サービス IP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

必要に応じてこの時点でこのステップをスキップでき、クラスタが起動した後に永続的な IP を追加できることに注意してください。永続 IP の詳細については、 すべての有効なサービスの前提条件と注意事項 セクションおよびサービス固有の要件の章を参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 10

[概要（Summary）] 画面で設定情報をレビューして確認し、[保存（Save）] をクリックし、[続行（Continue）] をクリックして正しい展開モードを確認し、クラスタの構築を続行します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 11

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 12

Nexus Dashboard とサービスを展開したら、設定と操作の記事の説明に従って各サービスを設定できます。

- ファブリック コントローラについては、 NDFC ペルソナ設定 のホワイトペーパーとドキュメントライブラリを参照してください。

- Orchestrator については、 ドキュメント ページを参照してください。

- Insights については、 ドキュメント ライブラリを参照してください。

Chapter8. VMware ESX の展開

- VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項

- VMware vCenter を使用している Nexus ダッシュボードの展開

- VMware ESXi での Nexus ダッシュボードの展開

VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項

VMware ESX で Nexus ダッシュボード クラスタを展開する前に、次の手順を実行する必要があります。

- ファクターから ESX が拡張性とサービス要件をサポートしていることを確認します。

スケールとサービスのサポートと共同ホスティングは、クラスタのフォーム ファクターと、展開する予定の特定のサービスによって異なります。Nexus ダッシュボード キャパシティ プラン二ング ツールを使用して、仮想フォーム ファクタが展開要件を満たすことを確認できます。

（注）

一部のサービス (Nexus Dashboard Fabric Controller など) は、1 つ以上の特定のユース ケースに対して単一の ESX 仮想ノードのみを必要とする場合があります。その場合、キャパシティ プランニング ツールで要件が示されるので、次のセクションの追加のノード展開手順をスキップできます。

- 前提条件：Nexus Dashboard に記載されている一般的な前提条件を確認して完了します。

この文書は、ベースとなる Nexus ダッシュボードクラスタを最初に展開する方法について説明するものである点に留意してください。追加ノード（セカンダリまたはスタンバイなど）で既存のクラスタを拡張する場合は、代わりにCisco Nexus ダッシュボード ユーザー ガイドの「インフラストラクチャの管理」の章を参照してください。これは、Nexus ダッシュボード UI またはオンラインでCisco Nexus ダッシュボード ユーザー ガイドから利用できます。

- 展開予定のサービスのリリース ノートに説明されている追加の前提条件を確認し、条件を満たすようにしてください。

- Nexus ダッシュボード VM に使用される CPU ファミリが AVX 命令セットをサポートしていることを確認します。

- VMware ESXで展開する場合、2種類のノードを展開できます。

- データ ノード：追加のリソースを必要とする特定のサービス向けに設計された、より高いシステム要件を持つノード プロファイル。

- アプリケーション ノード：ほとんどのサービスに使用できる、リソース フットプリントが小さいノード プロファイル。

（注）

一部の大規模な Nexus Dashboard ファブリックコントローラの展開では、追加のセカンダリ ノードが必要になる場合があります。NDFC クラスタにセカンダリノードを追加する予定の場合には、OVA-App プロファイルを使用してすべてのノード（最初の 3 ノードのクラスタと追加のセカンダリ ノード）を展開できます。詳細なスケール情報は、使用しているリリースの Cisco Nexus Dashboard ファブリック コントローラの検証済みスケーラビリティ ガイドで入手できます。

十分なシステム リソースをもつことを確認します。

展開要件

データ ノードの要件

アプリケーション ノードの要件

- VMware ESXi 7.0、7.0.1、7.0.2、7.0.3、8.0、8.0.2

- VMware vCenter を使用して展開する場合、VMware vCenter 7.0.1、7.0.2、7.0.3、8.0、8.0.2

- 各 VM には次のものが必要です。

- 少なくとも 12,000 MHz の物理的に CPU 予約された 32 個の vCPU

- 物理予約された 128GB の RAM

- データ ボリューム用の 3TB SSD ストレージとシステム ボリューム用の追加の 50GB

データノードは、次の最小パフォーマンス要件を満たすストレージに展開する必要があります。

- SSD は、データストアに直接接続するか、RAID ホストバスアダプタ（HBA）を使用している場合は JBOD モードで接続する必要があります。

- SSD は、混合使用/アプリケーション用に最適化する必要があります（読み取り最適化ではありません）。

- 4K ランダム読み取り IOPS：93000

- 4K ランダム書き込み IOPS：31000

- 各Nexus Dashboardノードは、異なるESXiサーバーに展開することを推奨します。

- VMware ESXi 7.0、7.0.1、7.0.2、7.0.3、8.0、8.0.2

- VMware vCenter を使用して展開する場合、VMware vCenter 7.0.1、7.0.2、7.0.3、8.0、8.0.2

- 各 VM には次のものが必要です。

- 少なくとも 12,000 MHz の物理的に CPU 予約された 16 個の vCPU

- 物理予約された 64GB の RAM

- データ ボリューム用に 500GB HDD または SSD ストレージ、システム ボリューム用に追加の 50GB

一部のサービスでは、アプリ ノードをより高速な SSD ストレージに展開する必要がありますが、他のサービスでは HDD をサポートしています。Nexus ダッシュボード キャパシティ プランニング ツールをチェックして、正しいタイプのストレージを使用していることを確認してください。

（注）

Nexus Dashboard リリース3.0(1i) および Nexus Dashboard Insightsリリース6.3(1)以降では、Insights サービスにOVA-Appノード プロファイルを使用できます。ただし、Insights のホスティングに使用されるノード VM を展開する場合は、デフォルトの 500 GB のディスク要件から 1536 GB に変更する必要があります。

- 各 Nexus ダッシュボードノードは、異なる ESXi サーバに展開することを推奨します。

- クラスタ ノードのデータ インターフェイスの VLAN ID を構成する場合は、仮想ゲスト VLAN タギング（VGT）モードの VMware vCenter のデータ インターフェイス ポート グループで VLAN 4095 を有効にする必要があります。

Nexus Dashboard データ インターフェイスの VLAN ID を指定する場合、パケットはその VLAN ID を持つ Dot1q タグを伝送する必要があります。vSwitch のポート グループに明示的な VLAN タグを設定し、Nexus Dashboard VM の VNIC にアタッチすると、vSwitch は、パケットをその VNIC に送信する前に、アップリンクからのパケットから Dot1q タグを削除します。vND ノードは Dot1q タグを想定しているため、すべての VLAN を許可するには、データ インターフェイス ポート グループで VLAN 4095 を有効にする必要があります。

- 各ノードの VM を展開したら、次のセクションの展開手順で説明されているように、VMware ツールの定期的な時刻同期が無効になっていることを確認します。

- VMware vMotion は Nexus ダッシュボード クラスタ ノードではサポートされていません。

- VMware 分散リソース スケジューラ (DRS) は、Nexus ダッシュボード クラスタ ノードではサポートされていません。

ESXi クラスタ レベルで DRS を有効にしている場合は、次のセクションで説明するように、展開時に Nexus ダッシュボード VM に対して明示的に無効にする必要があります。

- コンテンツ ライブラリによる展開はサポートされていません。

- Nexus ダッシュボードはプラットフォーム インフラストラクチャであるため、すべてのサービスを停止することはできません。

つまり、デバッグ目的などで、仮想マシンのスナップショットを作成する場合、スナップショットではすべての Nexus ダッシュボード サービスが実行されている必要があります。

- ノードを ESXi に直接展開するか、VMware vCenter を使用して展開するかを選択できます。

VMware vCenter を使用して展開する場合は、VMware vCenter を使用している Nexus ダッシュボードの展開 で説明されている手順に従います。

ESXi に直接展開する場合は、VMware ESXi での Nexus ダッシュボードの展開 で説明されている手順に従います。

（注）

OVA-App ノード プロファイルを使用して Nexus Dashboard Insights を展開する場合は、VMware vCenter を使用して展開する必要があります。

Nexus Dashboard Insightsには、OVA-Appノード プロファイルのデフォルト値よりも大きなディスク サイズが必要です。OVA-App ノードプロファイルを使用して NDI を展開する場合は、VM の展開時に OVA-App ノードのデフォルトのディスク サイズを 500GB から 1.5TB に変更する必要があります。ディスク サイズのカスタマイズは、VMware vCenter を介して展開する場合にのみサポートされます。Insights の詳細な要件については、Nexus Dashboard Capacity Planningツールを参照してください。

VMware vCenter を使用している Nexus ダッシュボードの展開

ここでは、VMware vCenter を使用して Cisco Nexus ダッシュボード クラスタを展開する方法について説明します。ESXi に直接展開する場合は、代わりに VMware ESXi での Nexus ダッシュボードの展開 で説明されている手順に従ってください。

始める前に

- VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

Cisco Nexus Dashboard OVAイメージを取得します。

1. [ソフトウェア ダウンロード（Software Download）] ページを参照します。

https://software.cisco.com/download/home/286327743/type/286328258/

2. 左側のサイドバーから、ダウンロードする Nexus ダッシュボードのリリースバージョンを選択します。

3. Nexus ダッシュボード OVA イメージの横にあるダウンロードをクリックします（nd-dk9. <version>.ova）。

ステップ 2

VMware vCenter にログインします。

vSphereクライアントのバージョンによっては、設定画面の場所と順序が若干異なる場合があります。次の手順では、VMware vSphere Client 7.0を使用した導入の詳細を示します。

ステップ 3

新しい VM 展開を開始します。

1. VM を展開する ESX ホストを右クリックします。

2. [OVFテンプレートの展開（Deploy OVF Template）] を選択します。

[Deploy OVF Template] ウィザードが表示されます。

ステップ 4

[OVF テンプレートの選択（Select an OVF template）] 画面で、OVAイメージを指定します。

1. イメージの場所を指定します。

環境内の Web サーバでイメージをホストしている場合は、[URL] を選択し、イメージの URL を指定します。

イメージがローカルの場合は、[ローカル ファイル（Local file）] を選択し、[ファイルの選択（Choose Files）] をクリックしてダウンロードしたOVAファイルを選択します。

2. [次へ（Next）] をクリックして続行します。

ステップ 5

[名前とフォルダの選択（Select a name and folder）] 画面で、VM の名前と場所を入力します。

1. 仮想マシンの名前を入力します。

たとえば、nd-ova-node1 です。

2. 仮想マシンのストレージ場所を選択します。

3. [次へ（Next）] をクリックして、続行します。

ステップ 6

[コンピューティング リソースの選択（Select a compute resource）] 画面で、ESX ホストを選択します。

1. 仮想マシンの vCenter データセンターと ESX ホストを選択します。

2. [次へ（Next）] をクリックして、続行します。

ステップ 7

[詳細の確認（Review details）] 画面で、[次へ（Next）] をクリックして続行します。

ステップ 8

[設定] 画面で、展開するノードプロファイルを選択します。

1. ユースケースの要件に基づいて、アプリまたはデータ ノード プロファイルを選択します。

ノードプロファイルの詳細については、「VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項」を参照してください。

2. [次へ（Next）] をクリックして、続行します。

ステップ 9

[ストレージの選択（Select storage）] 画面で、ストレージ情報を入力します。

1. 仮想マシンのデータストアを選択します。

ノードごとに一意のデータストアを推奨します。

2. [この仮想マシンのストレージ DRS を無効にする（Disable Storage DRS for this virtual machine）] チェックボックスをオンにします。

Nexus DashboardはVMware DRSをサポートしていません。

3. [仮想ディスク フォーマットの選択（Select virtual disk format）] ドロップダウン リストから [シック プロビジョニング Lazy Zeroed（Thick Provisioning Lazy Zeroed）] を選択します。

4. [次へ（Next）] をクリックして、続行します。

ステップ 10

[ネットワークの選択] 画面で、Nexus ダッシュボードの管理およびデータ ネットワークの VM ネットワークを選択し、[次へ] をクリックして続行します。

Nexus ダッシュボードクラスタには 2 つのネットワークが必要です。

- fabric0 は、Nexus ダッシュボードクラスタのデータ ネットワークに使用されます

- mgmt0 は、Nexus ダッシュボードクラスタの管理ネットワークに使用されます。

これらのネットワークの詳細については、「展開の概要と要件」の章の「すべての有効なサービスの前提条件と注意事項」を参照してください。

ステップ 11

[テンプレートのカスタマイズ（Customize template）] 画面で、必要な情報を入力します。

1. ノードのデータ ボリュームのサイズを指定します。

デフォルト値は、展開するノードのタイプに基づいて事前に入力されます。アプリケーションノードには単一の500 GBディスクがあり、データノードには単一の 3TB ディスクがあります。データ ボリュームに加えて、2 つ目の 50GB のシステム ボリュームも構成されますが、カスタマイズすることはできません。

（注）

ノードのカスタム ディスク サイズを指定する場合は、VM の展開時に指定する必要があります。ノードの起動後のディスクのサイズ変更は、Nexus Dashboard ではサポートされていません。

OVA-App ノードプロファイルを使用して Nexus Dashboard Insights を展開する場合は、データディスクサイズをデフォルトの 500GB 値から 1536GB に変更する必要があります。クラスタのサイジング、システム リソース要件、およびノード プロファイルのサポートの詳細については、Nexus Dashboard Capacity Planningを参照してください。

2. パスワードを入力して確認します。

このパスワードは、各ノードの rescue-user アカウントに使用されます。

（注）

すべてのノードに同じパスワードを指定する必要があります。同じパスワードを指定しないと、クラスタの作成に失敗します。

3. 管理ネットワークの IP アドレスとネットマスクを入力します。

4. 管理ネットワークの IP ゲートウェイを入力します。

5. [次へ（Next）] をクリックして次に進みます。

ステップ 12

[完了準備（Ready to complete）] 画面で、すべての情報が正しいことを確認し、[終了（Finish）] をクリックして最初のノードの展開を開始します。

ステップ 13

以前のステップを繰り返し、追加のノードを展開します。

（注）

単一のノードクラスタを展開している場合は、この手順をスキップできます。

マルチノードク ラスタの場合は、2 つの追加のプライマリ ノードと、特定のユースケースで必要なだけのセカンダリ ノードを展開する必要があります。必要なノードの総数は、 Nexus Dashboard キャパシティ プランニング ツールで確認できます。

最初のノードの VM 展開が完了するのを待つ必要はありません。他の 2 つのノードの展開を同時に開始できます。2 番目と 3 番目のノードを展開する手順は、最初のノードの場合と同じです。

ステップ 14

VM の展開が完了するまで待ちます。

ステップ 15

VMware ツールの定期的な時刻同期が無効になっていることを確認してから、VM を起動します。

時刻の同期を無効にするには、次の手順を実行します。

1. VM を右クリックして、[設定の編集（Edit Settings）] を選択します。

2. [設定の編集（Edit Settings）] ウィンドウで、[VMオプション（VM Options）] タブを選択します。

3. [VMware ツール（VMware Tools）] カテゴリを展開し、[定期的な時刻の同期（Synchronize time periodically）] オプションのチェックボックスをオフにします。

ステップ 16

ブラウザを開き、https://<node-mgmt-ip> に移動して、GUI を開きます。

残りの設定ワークフローは、ノードの GUI の 1 つから実行します。展開したノードのいずれか 1 つを選択して、ブートストラッププロセスを開始できます。他の 2 つのノードにログインしたり、これらを直接構成したりする必要はありません。

前の手順で入力したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 17

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 18

[ノードの詳細（Node Details）] 画面で、最初のノードの情報を更新します。

前の手順の初期ノード構成時に現在ログインしているノードの管理ネットワークと IP アドレスを定義しましたが、他のプライマリノードを追加し、クラスタを作成する進む前に、ノードのデータ ネットワーク情報も指定する必要があります。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

ノードの[シリアル番号（Serial Number）]、[管理ネットワーク（Management Network）]情報、および[タイプ（Type）]が自動的に入力されます。ただし、他の情報は手動で入力する必要があります。

2. ノードの [名前（Name）] を入力します。

ノードの 名前 はホスト名として設定されるため、 RFC-1123 の要件に従う必要があります。

3. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

4. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

5. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。BGP が構成されている場合は、残りのすべてのノードで BGP を構成する必要があります。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

ステップ 19

[ノードの詳細（Node Details）] 画面で、[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

単一ノード クラスタを展開する場合は、この手順をスキップします。

1. [展開の詳細（Deployment Details）] エリアで、2 番目のノードに [管理 IP アドレス（Management IP Address）] および [パスワード（Password）] を指定します。

ノードの初期構成手順で、管理ネットワーク情報とパスワードを定義しました。

2. [検証（Validate）] をクリックして、ノードへの接続を確認します。

接続が検証されると、ノードのシリアル番号と管理ネットワーク情報が自動的に入力されます。

3. ノードの [名前（Name）] を入力します。

4. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

5. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

6. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

8. クラスタの最後の（3 番目の）プライマリ ノードでこの手順を繰り返します。

ステップ 20

（オプション）前の手順を繰り返して、追加のセカンダリ ノードまたはスタンバイ ノードに関する情報を入力します。

（注）

クラスタで複数のサービスを同時に有効にするか、より高いスケールをサポートするには、展開時に十分な数のセカンダリ ノードを提供する必要があります。特定のユースケースに必要な追加のセカンダリノードの詳しい数については、 Nexus Dashboard クラスタ サイジング ツールを参照してください

スタンバイ ノードを今すぐ追加するか、クラスタの展開後に追加するかを選択できます。

ステップ 21

[ノードの詳細（Node Details）] ページで、入力した情報を確認し、[次へ（Next）] をクリックして続行します。

ステップ 22

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

（注）

クラスタ内のノードの数によっては、一部のサービスまたは共同ホスティングのシナリオがサポートされない場合があります。必要な数のサービスを選択できない場合は、[戻る（Back）] をクリックし、前の手順で十分な数のセカンダリ ノードを指定したことを確認します。

クラスタの展開後に展開モードを変更することはできないため、このドキュメントの前の章で説明されているサービス固有の前提条件をすべて満たしていることを確認する必要があります。

- Nexus Dashboard ファブリック コントローラの前提条件

- Nexus Dashboard オーケストレータの前提条件

- Nexus Dashboard Insights の前提条件

2. ファブリック コントローラまたは Insights を含む展開モードを選択した場合は、[永続サービス IP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

必要に応じてこの時点でこのステップをスキップでき、クラスタが起動した後に永続的な IP を追加できることに注意してください。永続 IP の詳細については、 すべての有効なサービスの前提条件と注意事項 セクションおよびサービス固有の要件の章を参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 23

[概要（Summary）] 画面で設定情報をレビューして確認し、[保存（Save）] をクリックし、[続行（Continue）] をクリックして正しい展開モードを確認し、クラスタの構築を続行します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 24

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 25

Nexus Dashboard とサービスを展開したら、設定と操作の記事の説明に従って各サービスを設定できます。

- ファブリック コントローラについては、 NDFC ペルソナ設定 のホワイトペーパーとドキュメントライブラリを参照してください。

- Orchestrator については、 ドキュメント ページを参照してください。

- Insights については、 ドキュメント ライブラリを参照してください。

VMware ESXi での Nexus ダッシュボードの展開

ここでは、VMware ESXi で Cisco Nexus ダッシュボード クラスタを展開する方法について説明します。vCenter を使用して展開する場合は、代わりに VMware ESXi での Nexus ダッシュボードの展開 で説明されている手順に従ってください。

始める前に

- VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

Cisco Nexus Dashboard OVAイメージを取得します。

1. [ソフトウェア ダウンロード（Software Download）] ページを参照します。

https://software.cisco.com/download/home/286327743/type/286328258/

2. 左側のサイドバーから、ダウンロードする Nexus ダッシュボードのリリースバージョンを選択します。

3. Nexus ダッシュボード OVA イメージの横にあるダウンロードをクリックします（nd-dk9. <version>.ova）。

ステップ 2

VMware ESXi にログインします。

ESXiサーバのバージョンによっては、設定画面の場所と順序が若干異なる場合があります。次の手順では、VMware ESXi 7.0を使用した導入の詳細を示します。

ステップ 3

ホストを右クリックし、[VM の作成/登録（Create/Register VM）] を選択します。

ステップ 4

[作成タイプの選択（Select creation type）] 画面で、[OVF または OVA ファイルから仮想マシンを展開する（Deploy a virtual machine from an OVF or OVA file）] を選択し、[次へ（Next）] をクリックします。

ステップ 5

[OVF と VMDK ファイルの選択（Select OVF and VMDK files）] 画面で、最初の手順でダウンロードした仮想マシン名（nd-ova-node1 など）とOVAイメージを入力し、[次へ（Next）] をクリックします。

ステップ 6

[ストレージの選択（Select storage）] 画面で、VM のデータストアを選択し、[次へ（Next）] をクリックします。

ステップ 7

[OVF と VMDK ファイルの選択（Select OVF and VMDK files）] 画面で、最初の手順でダウンロードした仮想マシン名（nd-node1 など）とOVAイメージを入力し、[次へ（Next）] をクリックします。

ステップ 8

[展開オプション（Deployment options）] を指定します。

[展開オプション（Deployment options）] 画面で、次の情報を入力します。

- [ネットワーク マッピング（Network mappings）] ドロップダウンから、Nexus Dashboard の管理（mgmt0）およびデータ（fabric0）インターフェイスのネットワークを選択します。

Nexus Dashboard ネットワークについては、前提条件：Nexus Dashboard で説明しています。

- [展開タイプ（Deployment type）] ドロップダウンから、ノード プロファイル（[アプリケーション（App）] または [データ（Data）]）を選択します。

ノード プロファイルについては、VMware ESX で Nexus Dashboard クラスタを展開するための前提条件と注意事項 を参照してください。

- [ディスク プロビジョニング タイプ（Disk provisioning type）] で、[シック（Thick）] を選択します。

- [自動的に電源をオンにする（Power on automatically）] オプションを無効にします。

ステップ 9

[完了準備（Ready to complete）] 画面で、すべての情報が正しいことを確認し、[終了（Finish）] をクリックして最初のノードの展開を開始します。

ステップ 10

以前のステップを繰り返し、2 番目と 3 番目のノードを展開します。

（注）

単一のノードクラスタを展開している場合は、この手順をスキップできます。

最初のノードの展開が完了するのを待つ必要はありません。他の 2 つのノードの展開を同時に開始できます。

ステップ 11

VM の展開が完了するまで待ちます。

ステップ 12

VMware ツールの定期的な時刻同期が無効になっていることを確認してから、VM を起動します。

時刻の同期を無効にするには、次の手順を実行します。

1. VM を右クリックして、[設定の編集（Edit Settings）] を選択します。

2. [設定の編集（Edit Settings）] ウィンドウで、[VMオプション（VM Options）] タブを選択します。

3. [VMware ツール（VMware Tools）] カテゴリを展開し、[ホストとゲスト時刻の同期（Synchronize guest time with host）] オプションをオフにします。

ステップ 13

ノードのコンソールのいずれかを開き、ノードの基本情報を設定します。

1. 初期設定を開始します。

初回セットアップユーティリティの実行を要求するプロンプトが表示されます。

[ OK ] Started atomix-boot-setup.
Starting Initial cloud-init job (pre-networking)...
Starting logrotate...
Starting logwatch...
Starting keyhole...
[ OK ] Started keyhole.
[ OK ] Started logrotate.
[ OK ] Started logwatch.

Press any key to run first-boot setup on this console...

2. admin パスワードを入力して確認します。

このパスワードは、rescue-user SSH ログインおよび初期 GUI パスワードに使用されます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

Admin Password:
Reenter Admin Password:

3. 管理ネットワーク情報を入力します。

Management Network:
IP Address/Mask: 192.168.9.172/24
Gateway: 192.168.9.1

4. 最初のノードのみ、「クラスタ リーダー」として指定します。

クラスタ リーダー ノードにログインして、設定を完了し、クラスタの作成を完了します。

Is this the cluster leader?: y

5. 入力した譲歩をレビューし、確認します。

入力した情報を変更するかどうかを尋ねられます。すべてのフィールドが正しい場合は、n を選択して続行します。入力した情報を変更する場合は、y を入力して基本設定スクリプトを再起動します。

Please review the config
Management network:
Gateway: 192.168.9.1
IP Address/Mask: 192.168.9.172/24
Cluster leader: no

Re-enter config? (y/N): n

ステップ 14

以前のステップを繰り返し、追加のノードを展開します。

単一のノードクラスタを展開している場合は、この手順をスキップできます。

マルチノードク ラスタの場合は、2 つの追加のプライマリ ノードと、特定のユースケースで必要なだけのセカンダリ ノードを展開する必要があります。必要なノードの総数は、 Nexus Dashboard キャパシティ プランニング ツールで確認できます。

最初のノードの設定が完了するのを待つ必要はありません。他の 2 つのノードの設定を同時に開始できます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

追加のノードを展開する手順は同じですが、クラスタ リーダーではないことを示す必要がある点が異なります。

ステップ 15

ブラウザを開き、https://<node-mgmt-ip> に移動して、GUI を開きます。

残りの設定ワークフローは、ノードの GUI の 1 つから実行します。展開したノードのいずれか 1 つを選択して、ブートストラッププロセスを開始できます。他の 2 つのノードにログインしたり、これらを直接構成したりする必要はありません。

前の手順で入力したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 16

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 17

[ノードの詳細（Node Details）] 画面で、最初のノードの情報を更新します。

前の手順の初期ノード構成時に現在ログインしているノードの管理ネットワークと IP アドレスを定義しましたが、他のプライマリノードを追加し、クラスタを作成する進む前に、ノードのデータ ネットワーク情報も指定する必要があります。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

ノードの[シリアル番号（Serial Number）]、[管理ネットワーク（Management Network）]情報、および[タイプ（Type）]が自動的に入力されます。ただし、他の情報は手動で入力する必要があります。

2. ノードの [名前（Name）] を入力します。

ノードの 名前 はホスト名として設定されるため、 RFC-1123 の要件に従う必要があります。

3. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

4. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

5. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。BGP が構成されている場合は、残りのすべてのノードで BGP を構成する必要があります。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

ステップ 18

[ノードの詳細（Node Details）] 画面で、[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

単一ノード クラスタを展開する場合は、この手順をスキップします。

1. [展開の詳細（Deployment Details）] エリアで、2 番目のノードに [管理 IP アドレス（Management IP Address）] および [パスワード（Password）] を指定します。

ノードの初期構成手順で、管理ネットワーク情報とパスワードを定義しました。

2. [検証（Validate）] をクリックして、ノードへの接続を確認します。

接続が検証されると、ノードのシリアル番号と管理ネットワーク情報が自動的に入力されます。

3. ノードの [名前（Name）] を入力します。

4. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

5. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

6. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

8. クラスタの最後の（3 番目の）プライマリ ノードでこの手順を繰り返します。

ステップ 19

（オプション）前の手順を繰り返して、追加のセカンダリ ノードまたはスタンバイ ノードに関する情報を入力します。

（注）

クラスタで複数のサービスを同時に有効にするか、より高いスケールをサポートするには、展開時に十分な数のセカンダリ ノードを提供する必要があります。特定のユースケースに必要な追加のセカンダリノードの詳しい数については、 Nexus Dashboard クラスタ サイジング ツールを参照してください

スタンバイ ノードを今すぐ追加するか、クラスタの展開後に追加するかを選択できます。

ステップ 20

[ノードの詳細（Node Details）] ページで、入力した情報を確認し、[次へ（Next）] をクリックして続行します。

ステップ 21

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

（注）

クラスタ内のノードの数によっては、一部のサービスまたは共同ホスティングのシナリオがサポートされない場合があります。必要な数のサービスを選択できない場合は、[戻る（Back）] をクリックし、前の手順で十分な数のセカンダリ ノードを指定したことを確認します。

クラスタの展開後に展開モードを変更することはできないため、このドキュメントの前の章で説明されているサービス固有の前提条件をすべて満たしていることを確認する必要があります。

- Nexus Dashboard ファブリック コントローラの前提条件

- Nexus Dashboard オーケストレータの前提条件

- Nexus Dashboard Insights の前提条件

2. ファブリック コントローラまたは Insights を含む展開モードを選択した場合は、[永続サービス IP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

必要に応じてこの時点でこのステップをスキップでき、クラスタが起動した後に永続的な IP を追加できることに注意してください。永続 IP の詳細については、 すべての有効なサービスの前提条件と注意事項 セクションおよびサービス固有の要件の章を参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 22

[概要（Summary）] 画面で設定情報をレビューして確認し、[保存（Save）] をクリックし、[続行（Continue）] をクリックして正しい展開モードを確認し、クラスタの構築を続行します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 23

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 24

Nexus Dashboard とサービスを展開したら、設定と操作の記事の説明に従って各サービスを設定できます。

- ファブリック コントローラについては、 NDFC ペルソナ設定 のホワイトペーパーとドキュメントライブラリを参照してください。

- Orchestrator については、 ドキュメント ページを参照してください。

- Insights については、 ドキュメント ライブラリを参照してください。

Chapter9. Linux KVMでの展開

- Linux KVM で Nexus Dashboard クラスタを展開するための前提条件と注意事項

- Linux KVM での Nexus ダッシュボードの展開

Linux KVM で Nexus Dashboard クラスタを展開するための前提条件と注意事項

Linux KVM で Nexus Dashboard クラスタの展開に進む前に、KVM が次の前提条件を満たしている必要があり、次の注意事項に従う必要があります。

- KVM フォーム ファクタが拡張性とサービス要件をサポートする必要があります。

クラスタ フォーム ファクタに基づいて、拡張性とサービス サポートおよび共同ホストは異なります。Nexus ダッシュボード キャパシティ プラン二ング ツールを使用して、仮想フォーム ファクタが展開要件を満たすことを確認できます。

- 前提条件：Nexus Dashboard に記載されている一般的な前提条件を確認して完了します。

- 展開予定のサービスのリリース ノートに説明されている追加の前提条件を確認し、条件を満たすようにしてください。

- Nexus Dashboard VM に使用される CPU ファミリが AVX 命令セットをサポートしている必要があります。

- KVM には十分なシステム リソースが必要です。

- 16 vCPU

- 64 GB の RAM

- 550 GBのディスク

各ノードには専用のディスク パーティションが必要です。

- ディスクの I/O 遅延は 20 ミリ秒以下である必要があります。

「Linux KVM ストレージ デバイスの I/O 遅延の確認」を参照してください。

- KVM の展開は、Nexus Dashboard ファブリック コントローラでのみサポートされます。

- CentOS 7.9 または Red Hat Enterprise Linux 8.6 または 8.8 に展開する必要があります。

- Kernel および KVM のサポートされるバージョンが必要です。

- CentOS 7.9 の場合、Kernel バージョン 3.10.0-957.el7.x86_64 および KVM バージョン libvirt-4.5.0-23.el7_7.1.x86_64

- RHEL 8.6 の場合、Kernel バージョン 4.18.0-372.9.1.el8.x86_64 および KVM バージョン libvert 8.0.0

- RHEL 8.8 の場合、Kernel バージョン 4.18.0-477.10.1.el8_8.x86_64 および KVM バージョン libvirt 8.0.0-19

- 各 Nexus Dashboard ノードは異なる KVM ハイパーバイザに展開することを推奨します。

- Linux KVM ストレージ デバイスの I/O 遅延の確認

Linux KVM ストレージ デバイスの I/O 遅延の確認

Linux KVM に Nexus Dashboard クラスタを展開する場合、KVM のストレージ デバイスの遅延は 20 ミリ秒未満である必要があります。

Linux KVM ストレージ デバイスの I/O 遅延を確認するには、次の手順を実行します。

手順

ステップ 1

テスト ディレクトリを作成します。

たとえば、 test-dataという名前のディレクトリを作成します。

ステップ 2

フレキシブル I/O テスター（FIO）を実行します。

# fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

ステップ 3

コマンドの実行後に、fsync/fdatasync/sync_file_range セクションの 99.00th=[<value>] が 20 ミリ秒未満であることを確認します。

Linux KVM での Nexus ダッシュボードの展開

ここでは、Linux KVM で Cisco Nexus ダッシュボード クラスタを展開する方法について説明します。

始める前に

- Linux KVM で Nexus Dashboard クラスタを展開するための前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

Cisco Nexus ダッシュボード イメージをダウンロードします。

1. [ソフトウェア ダウンロード（Software Download）] ページを参照します。

https://software.cisco.com/download/home/286327743/type/286328258

2. [Nexus ダッシュボード ソフトウェア] をクリックします。

3. 左側のサイドバーから、ダウンロードする Nexus ダッシュボードのバージョンを選択します。

4. Linux KVM の Cisco Nexus ダッシュボード イメージをダウンロードします（nd-dk9.<version>.qcow2）。

ステップ 2

ノードをホストする Linux KVM サーバーにイメージをコピーします。

scp を使用してイメージをコピーできます。次に例を示します。

# scp nd-dk9.<version>.qcow2 root@<kvm-host-ip>:/home/nd-base

次の手順は、イメージを /home/nd-base ディレクトリにコピーしたことを前提としています。

ステップ 3

最初のノードに必要なディスクイメージを作成します。

ダウンロードしたベース qcow2 イメージのスナップショットを作成し、そのスナップショットをノードの VM のディスク イメージとして使用します。また、ノードごとに2番目のディスクイメージを作成する必要があります。

1. KVM ホストに root ユーザとしてログインします。

2. ノードのスナップショット用のディレクトリを作成します。

次の手順は、/home/nd-node1 ディレクトリにスナップショットを作成することを前提としています。

# mkdir -p /home/nd-node1/
# cd /home/nd-node1

3. スナップショットを作成します。

次のコマンドで、/home/nd-base//nd-dk9.<version>.qcow2 を以前のステップで作成したベース イメージの場所に置換します。

# qemu-img create -f qcow2 -b /home/nd-base/nd-dk9.<version>.qcow2 /home/nd-node1/nd-node1-disk1.qcow2

（注）

RHEL 8.6 で展開する場合は、宛先スナップショットの形式を定義するための追加のパラメータも指定する必要があります。その場合は、上記のコマンドを次のように更新します。

# qemu-img create -f qcow2 -b /home/nd-base/nd-dk9.2.1.1a.qcow2 /home/nd-node1/nd-node1-disk1.qcow2 -F qcow2

4. ノードの追加ディスクイメージを作成します。

各ノードには 2 つのディスクが必要です。ベースの Nexus ダッシュボードqcow2イメージのスナップショットと、2 番目の 500GB ディスクです。

# qemu-img create -f qcow2 /home/nd-node1/nd-node1-disk2.qcow2 500G

ステップ 4

前のステップを繰り返して、2 番目と 3 番目のノードのディスク イメージを作成します。

次の手順に進む前に、次の準備が必要です。

- 1 つ目のノードの場合、2 つのディスクイメージがある /home/nd-node1/ ディレクトリ：

- /home/nd-node1/nd-node1-disk1.qcow2 は、ステップ 1でダウンロードしたベース qcow2 イメージのスナップショットです。

- /home/nd-node1/nd-node1-disk2.qcow2。これは、作成した新しい 500GB のディスクです。

- 2 つ目のノードの場合、2つのディスクイメージがある/ home / nd-node2 /ディレクトリ。

- /home/nd-node2/nd-node2-disk1.qcow2 は、ステップ 1 でダウンロードした基本 qcow2 イメージのスナップショットです。

- /home/nd-node2/nd-node2-disk2.qcow2。これは、作成した新しい 500GB のディスクです。

- 3 つ目のノードの場合、2 つのディスク イメージがある /home/nd-node3/ ディレクトリ。

- /home/nd-node1/nd-node3-disk1.qcow2。ステップ 1 でダウンロードしたベース qcow2 イメージのスナップショットです。

- /home/nd-node1/nd-node3-disk2.qcow2。これは、作成した新しい 500GB のディスクです。

ステップ 5

最初のノードの VM を作成します。

1. KVM コンソールを開き、[新しい仮想マシン（New Virtual Machine）] をクリックします。

コマンド ラインから virt-manager コマンドを使用して KVM コンソールを開くことができます。

2. [新しい VM（New VM）] 画面で、[既存のディスク イメージのインポート（import existing disk image）] オプションを選択し、[転送（Forward）] をクリックします。

3. [既存のストレージ パスを指定（Provide existing storage path）]フィールドで [参照（Browse）] をクリックし、nd-node1-disk1.qcow2 ファイルを選択します。

各ノードのディスクイメージは、それぞれのディスクパーティションに保存することを推奨します。

4. OS タイプとバージョンに対して [Generic] を選択し、[転送] をクリックします。

5. 64GB のメモリと 16 個の CPU を指定し、[転送（Forward）] をクリックします。

6. 仮想マシンの名前（例：nd-node1）を入力し、[インストール前に構成をカスタマイズする（Customize configuration before install）]オプションをオンにします。次に、[完了（Finish）] をクリックします。

（注）

ノードに必要なディスクとネットワークカードをカスタマイズできるようにするには、[インストール前に構成をカスタマイズする] チェックボックスをオンにする必要があります。

[VMの詳細]ウィンドウが開きます。

[VMの詳細]ウィンドウで、NICのデバイスモデルを変更します。

1. NIC <mac> を選択します。

2. [デバイス モデル] で、[e1000] を選択します。

3. [ネットワーク ソース（Network Source）] で、ブリッジ デバイスを選択し、「mgmt」ブリッジの名前を指定します。

VMの詳細ウィンドウで、2番目のNICを追加します。

1. [ハードウェアを追加（Add Hardware）] をクリックします。

2. [新しい仮想ハードウェアの追加（Add new virtual hardware）] ウィンドウで、[ネットワーク] を選択します。

3. [ネットワーク ソース（Network Source）] で、ブリッジ デバイスを選択し、作成した「データ」ブリッジの名前を指定します。

4. デフォルトの MAC アドレス の値のままにします。

5. [デバイス モデル] で、[e1000] を選択します。

[VMの詳細（VM details）] ウィンドウで、2 番目のディスク イメージを追加します。

1. [ハードウェアを追加（Add Hardware）] をクリックします。

2. [新しい仮想ハードウェアの追加] 画面で、[ストレージ] を選択します。

3. ディスクのバス ドライバについては、[IDE] を選択します。

4. [カスタム ストレージの選択または作成（Select or create custom storage）] を選択し、[管理（Manage）]をクリックして、作成した nd-node1-disk2.qcow2 ファイルを選択します。

5. [終了（Finish）] をクリックして 2 番目のディスクを追加します。

（注）

仮想マシン マネージャの UI で [ホスト CPU 設定のコピー（Copy host CPU configuration）] オプションが有効になっていることを確認します。

最後に、[インストールの開始（Begin Installation）] をクリックして、ノードのVMの作成を終了します。

ステップ 6

以前のステップを繰り返し、2 番目と 3 番目のノードを展開して、すべての VM を開始します。

（注）

単一のノードクラスタを展開している場合は、この手順をスキップできます。

ステップ 7

ノードのコンソールのいずれかを開き、ノードの基本情報を設定します。

1. いずれかのキーを押して、初期設定を開始します。

初回セットアップユーティリティの実行を要求するプロンプトが表示されます。

[ OK ] Started atomix-boot-setup.
Starting Initial cloud-init job (pre-networking)...
Starting logrotate...
Starting logwatch...
Starting keyhole...
[ OK ] Started keyhole.
[ OK ] Started logrotate.
[ OK ] Started logwatch.

Press any key to run first-boot setup on this console...

2. admin パスワードを入力して確認します。

このパスワードは、rescue-user SSH ログインおよび初期 GUI パスワードに使用されます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

Admin Password:
Reenter Admin Password:

3. 管理ネットワーク情報を入力します。

Management Network:
IP Address/Mask: 192.168.9.172/24
Gateway: 192.168.9.1

4. 最初のノードのみ、「クラスタ リーダー」として指定します。

クラスタ リーダー ノードにログインして、設定を完了し、クラスタの作成を完了します。

Is this the cluster leader?: y

5. 入力した譲歩をレビューし、確認します。

入力した情報を変更するかどうかを尋ねられます。すべてのフィールドが正しい場合は、n を選択して続行します。入力した情報を変更する場合は、y を入力して基本設定スクリプトを再起動します。

Please review the config
Management network:
Gateway: 192.168.9.1
IP Address/Mask: 192.168.9.172/24
Cluster leader: yes

Re-enter config? (y/N): n

ステップ 8

前の手順を繰り返して、2 番目と 3 番目のノードの初期情報を構成します。

最初のノードの設定が完了するのを待つ必要はありません。他の 2 つのノードの設定を同時に開始できます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

2 番目と 3 番目のノードを展開する手順は同じですが、クラスタ リーダーではないことを示す必要がある点が異なります。

ステップ 9

初期ブートストラップ プロセスを待機して、すべてのノードで完了します。

管理ネットワーク情報を入力して確認すると、最初のノード（クラスタ リーダー）初期設定でネットワーキングが設定され、UI が表示されます。この UI を使用して、他の 2 つのノードを追加し、クラスタの展開を完了します。

Please wait for system to boot: [#########################] 100%
System up, please wait for UI to be online.

System UI online, please login to https://192.168.9.172 to continue.

ステップ 10

ブラウザを開き、https://<node-mgmt-ip> に移動して、GUI を開きます。

残りの設定ワークフローは、ノードの GUI の 1 つから実行します。展開したノードのいずれか 1 つを選択して、ブートストラッププロセスを開始できます。他の 2 つのノードにログインしたり、これらを直接構成したりする必要はありません。

前の手順で入力したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 11

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 12

[ノードの詳細（Node Details）] 画面で、最初のノードの情報を更新します。

前の手順の初期ノード構成時に現在ログインしているノードの管理ネットワークと IP アドレスを定義しましたが、他のプライマリノードを追加し、クラスタを作成する進む前に、ノードのデータ ネットワーク情報も指定する必要があります。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

ノードの[シリアル番号（Serial Number）]、[管理ネットワーク（Management Network）]情報、および[タイプ（Type）]が自動的に入力されます。ただし、他の情報は手動で入力する必要があります。

2. ノードの [名前（Name）] を入力します。

ノードの 名前 はホスト名として設定されるため、 RFC-1123 の要件に従う必要があります。

3. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

4. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

5. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。BGP が構成されている場合は、残りのすべてのノードで BGP を構成する必要があります。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

ステップ 13

[ノードの詳細（Node Details）] 画面で、[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

単一ノード クラスタを展開する場合は、この手順をスキップします。

1. [展開の詳細（Deployment Details）] エリアで、2 番目のノードに [管理 IP アドレス（Management IP Address）] および [パスワード（Password）] を指定します。

ノードの初期構成手順で、管理ネットワーク情報とパスワードを定義しました。

2. [検証（Validate）] をクリックして、ノードへの接続を確認します。

接続が検証されると、ノードのシリアル番号と管理ネットワーク情報が自動的に入力されます。

3. ノードの [名前（Name）] を入力します。

4. [タイプ（Type）] ドロップダウンから [プライマリ（Primary）] を選択します。

クラスタの最初の 3 つのノードは [プライマリ（ Primary）] に設定する必要があります。サービスの共同ホスティングや、より大規模なスケールを有効にする必要がある場合は、後の手順でセカンダリ ノードを追加します。

5. [データ ネットワーク（Data Network）] エリアで、ノードのデータ ネットワークを提供します。

データ ネットワークの IP アドレス、ネットマスク、およびゲートウェイを指定する必要があります。オプションで、ネットワークの VLAN ID を指定することもできます。ほとんどの導入では、[VLAN ID] フィールドを空白のままにできます。

前の画面で IPv6 機能を有効にした場合は、IPv6 アドレス、ネットマスク、およびゲートウェイも入力する必要があります。

（注）

IPv6 情報を提供する場合は、クラスタ ブートストラップ プロセス中に行う必要があります。後で IP 構成を変更するには、クラスタを再展開する必要があります。

クラスタ内のすべてのノードは、 IPv4 のみ、IPv6 のみ、またはデュアル スタック IPv4/IPv6 のいずれかで構成する必要があります。

6. （オプション）クラスタが L3 HA モードで展開されている場合は、データ ネットワークの [BGP を有効にする（Enable BGP）] をオンにします。

Insights やファブリック コントローラなどの、一部のサービスで使用される永続的な IP 機能には、BGP 構成が必要です。この機能については、すべての有効なサービスの前提条件と注意事項 と『Cisco Nexus Dashboard ユーザーガイド』の「永続的な IP アドレス」セクションで詳しく説明されています。

（注）

BGP をこの時点で、またはクラスタの展開後に Nexus ダッシュボード GUI で有効にすることができます。

BGP を有効にする際、次の情報も入力する必要があります。

- このノードの ASN（BGP 自律システム番号）。

すべてのノードに同じ ASN を構成することも、ノードごとに異なる ASN を構成することもできます。

- 純粋な IPv6 の場合、このノードのルータ ID。

ルータ ID は、1.1.1.1 などの IPv4 アドレスである必要があります。

- ピアの IPv4 または IPv6 アドレスとピアの ASN を含む BGP ピアの詳細。

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

8. クラスタの最後の（3 番目の）プライマリ ノードでこの手順を繰り返します。

ステップ 14

[ノードの詳細（Node Details）] ページで、入力した情報を確認し、[次へ（Next）] をクリックして続行します。

ステップ 15

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

リリース 3.1(1) より前では、クラスタの初期展開が完了した後に、個々のサービスをダウンロードしてインストールする必要がありました。今では、初期インストール時にサービスを有効にするように選択できます。

（注）

クラスタ内のノードの数によっては、一部のサービスまたは共同ホスティングのシナリオがサポートされない場合があります。必要な数のサービスを選択できない場合は、[戻る（Back）] をクリックし、前の手順で十分な数のセカンダリ ノードを指定したことを確認します。

2. [永続サービスIP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

永続的 IP の詳細については、ユーザー ガイドのすべての有効なサービスの前提条件と注意事項のセクションを参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 16

[サマリー（Summary）] 画面で設定情報を見直して確認し、[保存（Save）] をクリックしてクラスタを構築します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 17

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 18

Nexus Dashboard とサービスを展開したら、設定と操作の記事の説明に従って各サービスを設定できます。

- ファブリック コントローラについては、 NDFC ペルソナ設定 のホワイトペーパーとドキュメントライブラリを参照してください。

- Orchestrator については、 ドキュメント ページを参照してください。

- Insights については、 ドキュメント ライブラリを参照してください。

Chapter10. Amazon Web Services での展開

- Amazon Web Services で Nexus Dashboard クラスタを展開するための前提条件と注意事項

- Nexus Dashboard クラスタ向け Amazon Web サービスの準備

- AWS での Nexus ダッシュボードの展開

Amazon Web Services で Nexus Dashboard クラスタを展開するための前提条件と注意事項

Amazon Web Services（AWS）で Nexus ダッシュボード クラスタを展開する前に、次の手順を実行する必要があります。

- ファクターから AWS が拡張性とサービス要件をサポートしていることを確認します。

クラスタ フォーム ファクタに基づいて、拡張性とサービス サポートおよび共同ホストは異なります。Nexus ダッシュボード キャパシティ プラン ツールを使用して、仮想フォーム ファクタが展開要件を満たすことを確認できます。

- デプロイ概要 に記載されている一般的な前提条件を確認して完了します。

- 展開する予定のサービスのリリース ノートに記載されている追加の前提条件を確認して完了します。

- AWS アカウントに適切なアクセス権限があること。

Nexus ダッシュボード クラスタをホストするには、複数の Elastic Compute Cloud（m5.2xlarge）のインスタンスを起動できる必要があります。

- Nexus ダッシュボード VM に使用される CPU ファミリが AVX 命令セットをサポートしていることを確認します。

- Nexus Dashboard クラスタ向け Amazon Web サービスの準備の手順を実行します。

Nexus Dashboard クラスタ向け Amazon Web サービスの準備

Amazon Web Services（AWS）で Nexus Dashboard クラスタを展開する前に、いくつかの予備ステップを実行する必要があります。

Nexus Dashboard クラスタ用に Amazon Web Services を準備するには、次の手順に従います。

手順

ステップ 1

AWS アカウントに未使用の AWS Elastic IP アドレスが 6 つ未満の場合は、Elastic IPアドレスの制限の引き上げをリクエスト、要求など（文脈に応じて）します。

一般的な Nexus ダッシュボードの導入は 3 つのノードで構成され、各ノードには管理およびデータネットワーク用に 2 つの AWS Elastic IP アドレスが必要です。したがって、 Nexus Dashboard には 6 つの未使用の AWS Elastic IP アドレスが必要です。

1. AWS コンソールで、[コンピュータ（Computer）] > [EC2] の順に移動します。

2. EC2 Dashboard で、[ネットワークおよびセキュリティ（Network＆Security）] > [Elastic IPs] をクリックし、すでに使用されている Elastic IP の数を確認します。

3. EC2 ダッシュボードで、[制限（Limits）] をクリックし、許可されている EC2-VPC Elastic IP の最大数を確認します。

4. すでに使用されている Elastic IP アドレスの数を制限から差し引いて、未使用の Elastic IP アドレスの数を決定します。数が 6 未満の場合は、[制限の増加を要求（Request limit increase）] をクリックし、合計 6 つの未使用 IP アドレスを提供する数を指定します。

ステップ 2

VPC（仮想プライベート クラウド）を作成します。

VPC は、Amazon EC2 インスタンスなどの AWS オブジェクトによって入力される AWS クラウドの分離された部分です。

1. AWS コンソールで、[ネットワーキングおよびコンテンツ配布ツール（Networking＆Content Delivery Tools）] > [VPC] に移動します。

2. VPC ダッシュボードで、[お使いの VPC（Your VPCs）] をクリックし、[VPC の作成（Create VPC）] を選択し、[ネーム タグ（Name Tag）] と [IPv4 CIDR ブロック（IPv4 CIDR block）] を指定します。

CIDR ブロックは VPC の IPv4 アドレスの範囲であり、/16〜/24 の範囲である必要があります。たとえば、10.9.0.0/16 です。

ステップ 3

インターネット ゲートウェイを作成し、VPC に接続します。

インターネット ゲートウェイは、VPC がインターネットに接続できるようにする仮想ルータです。

1. [VPC ダッシュボード（VPC Dashboard）] > [インターネット ゲートウェイ（Internet Gateway）] の順にクリックしてから、[インターネット ゲートウェイの作成（Create Internet Gateway）] をクリックし、[ネーム タグ（Name Tag）] を提供します。

2. [インターネット ゲートウェイ（Internet Gateways）] 画面で、作成したインターネット ゲートウェイを選択し、[アクション（Actions）] > [VPC をアタッチ（Attach to VPC）] を選択します。

3. [使用可能な VPC（Available VPCs）] ドロップダウン メニューから、作成した VPC を選択し、[インターネット ゲートウェイのアタッチ（Attach Internet Gateway）] をクリックします。

ステップ 4

ルート テーブルを作成します。

ルート テーブルは、VPC およびインターネット ゲートウェイ内のサブネットを Nexus ダッシュボード クラスタに接続するために使用されます。

1. VPC ダッシュボードで、[ルート テーブル（Route Tables）] をクリックし、[ルート（Routes）] タブを選択して、[ルートの編集（Edit routes）] をクリックします。

2. [ルートの編集（Edit routes）] 画面で、[ルートの追加（Add route）] をクリックし、0.0.0.0/0 の宛先を作成します。

3. [ターゲット（Target ）] ドロップダウン メニューから [インターネット ゲートウェイ（Target Internet Gateway）] から、作成したゲートウェイを選択します。

4. [ルートの保存（Save Routes）] をクリックします。

ステップ 5

キー ペアを作成します。

キー ペアは、プライベート キーとパブリック キーで構成され、インスタンスへの接続時に ID を証明するために使用されるセキュリティ クレデンシャルとして使用されます。

1. [すべてのサービス（All services）] > [コンピュート（Compute）] > [EC2]に移動します。

2. EC2 Dashboard で、[ネットワークとセキュリティ（Network & Security）] > [キーペア（Key pairs）] をクリックし、[キー ペアの作成（Create Key Pairs）] をクリックします。

3. キー ペアの名前を入力し、pem ファイル形式を選択して、[キー ペアの作成 (Create Key Pair)] をクリックします。

これにより、.pem 秘密キー ファイルがシステムにダウンロードされます。ファイルを安全な場所に移動します。EC2 インスタンスのコンソールに初めてログインするときに使用する必要があります。

（注）

デフォルトでは、PEM ベースのログインのみが各ノードで有効になっています。GUI セットアップ ウィザードで要求されるパスワードを使用してノードに SSH で接続できるようにするには、生成されたキーを使用して各ノードにログインし、AWS での Nexus ダッシュボードの展開 の説明に従って必要なコマンドを実行することにより、パスワード ベースのログインを明示的に有効にする必要があります。

AWS での Nexus ダッシュボードの展開

ここでは、Amazon Web Services (AWS) で Cisco Nexus ダッシュボード クラスタを展開する方法について説明します。

始める前に

- Amazon Web Services で Nexus Dashboard クラスタを展開するための前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

AWS Marketplace で Cisco Nexus ダッシュボード製品に登録します。

1. AWS アカウントにログインし、AWS Management Console に移動します。

管理コンソールは https://console.aws.amazon.com/ で入手できます。

2. [サービス] > [AWS マーケットプレイス サブスクリプション（Services AWS Marketplace Subscriptions）]に移動します。

3. [Manage Subscriptions] をクリックします。

4. [製品の検出（Discover products）] をクリックします。

5. Cisco Nexus ダッシュボードを検索し、結果をクリックします。

6. 製品ページで、[続行して登録（Continue to Subscribe）] をクリックします。

7. [条件に同意する（Accept Terms）] をクリックします。

サブスクリプションが処理されるまでに数分かかる場合があります。

8. 最後に、[設定を続行 (Continue to Configuration)] をクリックします。

ステップ 2

ソフトウェア オプションと地域を選択します。

1. [入力オプション（Fulfillment Option）] ドロップダウンから、[Nexus Dashboard - クラウド展開（Nexus Dashboard - Cloud Deployment）] を選択します。

2. [ソフトウェア バージョン（Software Version）] ドロップダウンから、展開するバージョンを選択します。

3. [リージョン（Region）] ドロップダウンから、テンプレートを展開するリージョンを選択します。

これは、VPC を作成したのと同じリージョンである必要があります。

4. [続行して起動する（Continue to Launch）] をクリックします

この製品 ページが表示され、設定の概要が表示され、クラウド形成テンプレートを起動できます。

ステップ 3

[アクションの選択（Choose Action）] から、[CloudFormation の起動（Launch CloudFormation）] を選択し、[起動（Launch）] をクリックします。

[Create Stack（スタックの作成）] ページが表示されます。

ステップ 4

スタックを作成します。

1. [前提条件 - テンプレートの準備（Prerequisite-Prepare template）] 領域で、[テンプレート準備完了（Template is ready）] を選択します。

2. [テンプレートの指定（Specify Template）] フィールドで、テンプレート ソースとして [Amazon S3 URL] を選択します。

これは、自動的に入力されます。

3. [次へ（Next）] をクリックして続行します。

[スタック詳細の指定（Specify stack details）] ページが表示されます。

ステップ 5

スタックの詳細を指定します。

1. スタック名を入力します。

2. [VPC ID] ドロップダウンから、作成した VPC を選択します。

たとえば、vpc-038f83026b6a48e98（10.176.176.0/24）です。

3. ND クラスタ サブネット ブロックで、VPC サブネット CIDR ブロックを指定します。

定義した VPC CIDR からサブネットを選択します。より小さいサブネットを提供することも、CIDR 全体を使用することもできます。CIDR は /24 または /25 サブネットにすることができ、可用性ゾーン全体で使用されるようにセグメント化されます。

たとえば、10.176.176.0/24 です。

4. [可用性ゾーン（Availability Zones）] ドロップダウンから、1 つ以上の使用可能なゾーンを選択します。

3 つの可用性ゾーンを選択することをお勧めします。2 つの可用性ゾーンのみをサポートするリージョンの場合、クラスタの 2 番目と 3 番目のノードは 2 番目の可用性ゾーンで起動します。

5. [可用性ゾーンの数（Number of Availability Zones）] ドロップダウンから、前のサブステップで追加したゾーンの数を選択します。

この番号が、前のサブステップで選択した可用性ゾーンの数と一致していることを確認します。

6. データ インターフェイス EIP サポートを有効にします。

このフィールドは、ノードの外部接続を有効にします。AWS 以外の Cisco ACI ファブリックとの通信には、外部接続が必要です。

7. [パスワード（Password）] および [パスワードの確認（Confirm Password）] フィールドに、パスワードを提供します。

このパスワードは、Nexus ダッシュボードのレスキュー ユーザ ログインと、GUI の管理者ユーザの初期パスワードに使用されます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

8. [SSH key pair]ドロップダウンから、作成したキーペアを選択します。

9. [アクセス制御（Access control）] フィールドに、クラスタへのアクセスを許可する外部ネットワークを指定します。

たとえば、0.0.0.0/0 は、どこからでもクラスタにアクセスできます。

10. [次へ（Next）] をクリックして続行します。

ステップ 6

[詳細オプション（Advanced options）] 画面で、[次へ（Next）]をクリックします。

ステップ 7

[レビュー（Review）] 画面で、テンプレート設定を確認し、[スタックの作成（Create stack）] をクリックします。

ステップ 8

展開が完了するのを待ってから、VM を起動します。

[CloudFormation] ページでインスタンスの展開のステータス（CREATE_IN_PROGRESS など）を表示できます。ページの右上隅にある更新ボタンをクリックすると、ステータスを更新できます。

ステータスが CREATE_COMPLETE に変わったら、次の手順に進むことができます。

ステップ 9

すべてのノードのパブリック IP アドレスを書き留めます。

1. すべてのインスタンスが展開されたら、AWS コンソールの EC2 > Instances ページに移動します。

2. ND1-Master とラベル付けされているノードを書き留めます。

このノードのパブリック IP アドレスを使用して、クラスタ設定を完了します。

3. すべてのノードのパブリック IP アドレスを書き留めます。

次の手順で、この情報を GUI ブートストラップ ウィザードに提供します。

ステップ 10

すべてのノードでパスワードベースのログインを有効にします。

デフォルトでは、PEM ベースのログインのみが各ノードで有効になっています。パスワードを使用して SSH をノードに接続できるようにするには、GUI セットアップ ウィザードで要求されるように、パスワードベースのログインを明示的に有効にする必要があります。

（注）

次の手順で説明するクラスタ ブートストラップに進む前に、すべてのノードでパスワード ベースのログインを有効にする必要があります。そうしないと、クラスタ設定を完了できません。

1. パブリック IP アドレスと PEM ファイルを使用して、インスタンスの 1 つに SSH で接続します。

このために作成した PEM ファイルを Amazon Web Services で Nexus Dashboard クラスタを展開するための前提条件と注意事項 の一部として使用します。

# ssh -i <pem-file-name>.pem rescue-user@<node-public-ip>

2. パスワードベースのログインを有効にします。

各ノードで、次のコマンドを実行します。

# acs login-prompt enable

3. 他の 2 つのインスタンスについて、この手順を繰り返します。

ステップ 11

ブラウザを開き、https://<first-node-public-ip> に移動して、GUI を開きます。

（注）

最初のノード（ND1-Master）のパブリック IP アドレスを使用する必要があります。そうしないと、クラスタ構成を完了できません。

残りの設定ワークフローは、最初のノードの GUI から実行します。他の 2 つのノードに直接ログインまたは設定する必要はありません。

最初のノードに指定したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 12

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 13

[ノードの詳細（Node Details）] 画面で、ノードの情報を入力します。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

2. ノードの名前を入力します。

管理ネットワークとデータ ネットワークの情報は、クラスタを展開する前に構成した VPC サブネットから既に入力されています。

クラスタは、指定された VPC CIDR から 6 つのサブネットを作成し、そこからデータと管理ネットワークがクラスタの 3 つのノードに割り当てられます。

3. IPv6 アドレスと VLAN フィールドは空白のままにします。

Cloud Nexus ダッシュボード クラスタは、これらのオプションをサポートしていません。

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

ステップ 14

[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

[ノードの詳細（Node Details）] ウィンドウが開きます。

1. ノードの名前を入力します。

2. [資格情報（Credentials）] セクションで、ノードのパブリック IP アドレスとテンプレートの展開時に指定したパスワードを入力し、[検証（Verify）] をクリックします。

IP アドレスとパスワードは、そのノードの管理ネットワークとデータ ネットワーク情報を取得するために使用され、下のフィールドに入力されます。

3. ノード タイプの [プライマリ（Primary）] を選択していることを確認します。

3 ノード クラスタはクラウド展開でのみサポートされるため、すべてのノードは [プライマリ（Primary）] である必要があります。

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

ステップ 15

前の手順を繰り返して、3番目のノードを追加します。

ステップ 16

[ノードの詳細（Node Details）] ページで、[次へ（Next）] をクリックして続行します。

ステップ 17

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

リリース 3.1(1) より前では、クラスタの初期展開が完了した後に、個々のサービスをダウンロードしてインストールする必要がありました。今では、初期インストール時にサービスを有効にするように選択できます。

（注）

クラウド展開は Orchestrator 展開をサポートするため、他の展開モードを選択しないようにしてください。

2. [永続サービスIP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

永続的 IP の詳細については、ユーザー ガイドのすべての有効なサービスの前提条件と注意事項のセクションを参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 18

[概要（Summary）] 画面で設定情報をレビューして確認し、[保存（Save）] をクリックし、[続行（Continue）] をクリックして正しい展開モードを確認し、クラスタの構築を続行します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 19

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 20

必要なポートでノードのセキュリティ グループを更新します。

この手順では、Cisco NDFC サイトのオンボーディングに必要なポート構成で Nexus Dashboard ノードのインスタンスを更新する方法について説明します。Nexus Dashboard クラスタへの NDFC ファブリックのオンボーディングを計画していない場合は、この手順をスキップできます。

いずれかのノードのデータ インターフェイスに移動します。

1. AWS コンソールで、[インスタンス（Instances）] に移動します。

2. Nexus ダッシュボード インスタンスの 1 つを選択します。

デフォルトのセキュリティ グループに変更を加えるため、ノードの 1 つを選択するだけで済みます。

3. データ インターフェイスをクリックします（eth1）。

4. [インターフェイス ID（Interface ID）] をクリックします。

[ネットワークインターフェイス（Network Interface）] ページが開きます。

5. [ネットワーク インターフェイス（Network Interface）] ページで、インターフェイスの [セキュリティ グループ（Security groups）] 列の [デフォルト（default）] をクリックします。

新しいルールを追加します。

1. デフォルトのセキュリティ グループのページで、[インバウンド ルール（Inbound rules）] タブを選択します。

2. [インバウンド ルールの編集（Edit Inbound Rules）] をクリックします。

3. [インバウンド ルールの編集（Edit inbound rules）] ページで、[ルールの追加（Add rule）] をクリックして新しいインバウンド セキュリティ ルールを追加し、ポート 443 でのインバウンド通信を許可するための詳細を指定します。

新しいルールについて、次の情報を提供します。

- [タイプ（Type）] で、[カスタム TCP（Custom TCP）] を選択します。

- [ポート範囲（Port range）] に 443 を入力します。

- [ソース（Source）] には、Nexus ダッシュボードにオンボードする予定の NDFC コントローラの IP アドレスを指定します。

4. 引き続き [インバウンド ルールの編集（Edit inbound rules）] ページで、[ルールの追加（Add rule）] をクリックして別のインバウンド セキュリティ ルールを追加し、ポート 9092 でのインバウンド通信を許可するための詳細を指定します。

新しいルールについて、次の情報を提供します。

- [タイプ（Type）] で、[カスタム TCP（Custom TCP）] を選択します。

- [ポート範囲（Port range）] には、9092 と入力します。

- [ソース（Source）] には、Nexus ダッシュボードにオンボードする予定の NDFC コントローラの IP アドレスを指定します。

Chapter11. Microsoft Azure での展開

- Microsoft Azure で Nexus Dashboard クラスタを展開するための前提条件と注意事項

- Azure での Nexus ダッシュボードの展開

Microsoft Azure で Nexus Dashboard クラスタを展開するための前提条件と注意事項

Microsoft Azure で Nexus ダッシュボード クラスタを展開する前に、次の作業を行う必要があります。

- ファクターから Azure が拡張性とサービス要件をサポートしていることを確認します。

クラスタ フォーム ファクタに基づいて、拡張性とサービス サポートおよび共同ホストは異なります。Nexus ダッシュボード キャパシティ プラン ツールを使用して、仮想フォーム ファクタが展開要件を満たすことを確認できます。

- デプロイ概要 に記載されている一般的な前提条件を確認して完了します。

- 展開する予定のサービスのリリース ノートに記載されている追加の前提条件を確認して完了します。

- Azure アカウントとサブスクリプションに適切なアクセス権限を持っている。

- Nexus ダッシュボード クラスタ リソースのリソース グループを作成しました。

（注）

リソース グループは空である必要があり、既存のオブジェクトが含まれていない必要があります。既存のオブジェクトを持つリソース グループは、Nexus ダッシュボードの展開には使用できません。

リソース グループを作成するには:

- Azureポータルで、[すべてのリソース（All Resources）] > [リソース グループ（Resource Groups）] に移動します。

- 新しいメディア リソース グループを作成するには、[+追加（+Add）] をクリックします。

- [リソース グループの作成（Create a resource group）] 画面で、Nexus ダッシュボード クラスタに使用するサブスクリプションの名前、リソースグループの名前（nd-cluster など）、およびリージョンを入力します。

- Nexus ダッシュボード VM に使用される CPU ファミリが AVX 命令セットをサポートしていることを確認します。

- SSH キー ペアを生成します。

キー ペアは秘密キーと公開キーで構成され、Nexus ダッシュボード ノードを作成するときに、公開キーを入力するように求められます。

（注）

クラスタの展開手順中に一般的な SSH ログインを有効にするには、各ノードへの 1 回限りのログイン用の公開キーを作成するのと同じマシンを使用する必要があります。

SSH キーの作成については、以下の Linux または MacOS での SSH キー ペアの生成 および Windows での SSH キー ペアの生成 セクションで説明します。

- Linux または MacOS での SSH キー ペアの生成

- Windows での SSH キー ペアの生成

Linux または MacOS での SSH キー ペアの生成

次の手順では、Linux または MacOS で SSH 公開キーと秘密キーのペアを生成する方法について説明します。Windows で SSH 公開キーと秘密キーのペアを生成する手順については、を参照してください。Windows での SSH キー ペアの生成

手順

ステップ 1

Linux 仮想マシンまたは Mac で、ssh-keygen を使用して公開キーと秘密キーのペアを作成し、出力をファイルに送信します。

# ssh-keygen -f filename

次に例を示します。

# ssh-keygen -f azure_key

次のような出力が表示されます。パスフレーズを入力するように求められたら、テキストを入力せずに Enter キーを押します（パスフレーズがないようにフィールドを空のままにします）。

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in azure_key.
Your public key has been saved in azure_key.pub.
The key fingerprint is:
SHA256:gTsQIIAadjgNsgcguifIloh4XGpVWMdcXVV6U0dyBNs
...

ステップ 2

保存した公開キーファイルと秘密キーファイルを見つけます。

# ls

2 つのファイルが表示されます。

- 拡張子が .pub のファイルには、公開キー情報が含まれています。

- 同じ名前でサフィックスのないファイルに秘密キー情報が含まれている

たとえば、出力を azure_key という名前のファイルに送信すると、次の出力が表示されます。

# ls
azure_key
azure_key.pub

その場合、次のようになります。

- azure_key.pub ファイルには、公開キー情報が含まれています。

- azure_key ファイルには秘密キー情報が含まれています。

ステップ 3

公開キーファイルを開き、そのファイルから公開キー情報をコピーします。末尾に username @ hostname 情報は含めません。

（注）

秘密キーファイルは、インストールプロセスでは使用されません。ただし、SSH を介して Nexus ダッシュボード ノードにログインするなど、その他の理由で必要になる場合があります。

Windows での SSH キー ペアの生成

次の手順では、WindowsでSSH公開キーと秘密キーのペアを生成する方法について説明します。LinuxでSSH公開キーと秘密キーのペアを生成する手順については、を参照してください。Linux または MacOS での SSH キー ペアの生成

手順

ステップ 1

PuTTYキージェネレータ（puttygen）をダウンロードしてインストールします。

https://www.puttygen.com/download-putty

ステップ 2

Windows > [スタート]メニュー > [すべてのプログラム] > [PuTTY] > [PuTTYgen] に移動して、PuTTY キージェネレータを実行します。

画面にPuTTYキージェネレータのウィンドウが表示されます。

ステップ 3

[生成（Generate）] をクリックします。

公開キーを生成するために空白領域にマウスを移動するように求める画面が表示されます。

ステップ 4

空白領域の周囲にカーソルを移動して、公開キーのランダムな文字を生成します。

ステップ 5

公開キーを保存します。

1. 公開キーファイルを保存するラップトップ上のフォルダに移動し、この公開キーのテキストファイルを作成します。

2. PuTTYキージェネレータの情報をコピーします。

次の内容を含めて、ウィンドウに公開キー情報をコピーします。

- 公開キーの先頭にssh-rsaテキストを含める。

- 末尾の次のテキスト文字列を除外します。

== rsa-key-<date-stamp>

== rsa-key-を含まないようにキーを切り捨てます。<date-stamp>末尾のテキスト文字列。

（注）

次の一連の手順では、公開キー情報をAzure ARMテンプレートに貼り付けます。フォームがこの形式のキーを受け入れない場合は、キーの末尾に==を追加します。一部の地域ではこの形式が必要になるためです。

キーが正しい形式でない場合、Nexus ダッシュボードはインストールを完了しません。

3. で作成した公開キーテキストファイルに情報を貼り付け、ファイルを保存して、一意のファイル名を付けます。5.a

この公開キーテキストファイルには、1行のテキストのキーが含まれています。次の一連の手順では、この公開キーテキストファイルの情報が必要になります。

（注）

PuTTYキージェネレータの[公開キーの保存（Save public key）]オプションを使用して公開キーを保存しないでください。これにより、複数行のテキストを含む形式でキーが保存されます。これは、Nexus ダッシュボード展開プロセスと互換性がありません。

ステップ 6

秘密キーを保存します。

1. [プライベート キーの保存（Save private key）] をクリックします。

パスフレーズなしでファイルを保存するかどうかを確認する画面が表示されます。この画面で [はい（Yes）] をクリックします。

2. ラップトップのフォルダに移動し、一意のファイル名を付けて秘密キーファイルを保存します。

（注）

秘密キーファイルは、インストールプロセスでは使用されません。ただし、SSH を介して Nexus ダッシュボード ノードにログインするなど、その他の理由で必要になる場合があります。

Azure での Nexus ダッシュボードの展開

このセクションでは、Microsoft Azure で Cisco Nexus ダッシュボード クラスタを展開する方法について説明します。

始める前に

- Microsoft Azure で Nexus Dashboard クラスタを展開するための前提条件と注意事項 に記載されている要件とガイドラインを満たしていることを確認します。

手順

ステップ 1

Azure Marketplace で Cisco Nexus ダッシュボード製品に登録します。

1. Azure アカウントにログインし、https://azuremarketplace.microsoft.com に移動します

2. 検索フィールドに「Cisco Nexus ダッシュボード」と入力し、表示されるオプションを選択します。

[Nexus ダッシュボードの Azure Marketplace] ページにリダイレクトされます。

3. [今すぐ取得（Get it now）] をクリックします。

4. [プランを選択（Select a plan）] ドロップダウンで、バージョンを選択し、[作成（Create）] をクリックします。

ステップ 2

基本情報を提供します。

1. [サブスクリプション（Subscription）] ドロップダウンから、これに使用するサブスクリプションを選択します。

2. [リソース グループ（Resource group）] ドロップダウンから、このために作成したリソース グループを Microsoft Azure で Nexus Dashboard クラスタを展開するための前提条件と注意事項 の一部として選択します。

3. [リージョン（Region）] ドロップダウンから、テンプレートを展開するリージョンを選択します。

4. [パスワード (Password)] および [パスワードの確認 (Confirm Password)]フィールドにノードの管理パスワードを入力します。

このパスワードは、Nexus ダッシュボードのレスキュー ユーザ ログインと、GUI の管理者ユーザの初期パスワードに使用されます。

（注）

すべてのノードに同じパスワードを指定する必要があります。指定しない場合、クラスタ作成に失敗します。

5. [SSH 公共キー（SSH public key）]フィールドに、Microsoft Azure で Nexus Dashboard クラスタを展開するための前提条件と注意事項 セクションの一部として生成したキーペアの公開キーを貼り付けます。

6. [次へ (Next)] をクリックして、次の画面に進みます。

ステップ 3

ND 設定情報を提供します。

1. クラスタ名 を指定します。

2. [イメージ バージョン（Image Version）] ドロップダウンで、正しいバージョンが選択されていることを確認します。

3. [仮想ネットワーク名（Virtual Network Name）] フィールドに、クラスタ用に作成される VNET の名前を指定します。

VNET はまだ存在していてはならず、展開時に作成されます。既存の VNET を指定すると、展開を続行できません。

4. [サブネット アドレス プレフィックス（Subnet Address Prefix）] フィールドで、VNET 内のサブネットを指定します。

サブネットは /24 サブネットである必要があり、VNET の作成時に定義したデフォルトの VNET サブネットとは異なる必要があります。

5. [外部サブネット（External Subnets）] フィールドに、クラスタへのアクセスを許可する外部ネットワークを指定します。

たとえば、0.0.0.0/0 は、どこからでもクラスタにアクセスできます。

6. [次へ (Next)] をクリックして、次の画面に進みます。

ステップ 4

[確認 + 作成（Review + create）]ページで情報を確認し、[作成（Create）] をクリックします。

ステップ 5

展開が完了するのを待ってから、VM を起動します。

ステップ 6

すべてのノードのパブリック IP アドレスを書き留めます。

すべてのインスタンスが展開されたら、Azure コンソールに移動し、各 VM を選択して、すべてのノードのパブリック IP アドレスを書き留めます。次の手順で、この情報を GUI ブートストラップ ウィザードに提供します。

また、どちらが「最初の」ノードであるかに注意してください。これは、ノードの VM 名 vm-node1-<cluster-name> によって示されます。このノードのパブリック IP アドレスを使用して、クラスタ設定を完了します。

ステップ 7

ブラウザを開き、https://<first-node-public-ip> に移動して、GUI を開きます。

（注）

最初のノード（vm-node1-<cluster-name>）のパブリック IP アドレスを使用する必要があります。そうしないと、クラスタ設定を完了できません。

残りの設定ワークフローは、最初のノードの GUI から実行します。他の 2 つのノードに直接ログインまたは設定する必要はありません。

最初のノードに指定したパスワードを入力し、[ログイン（Login）] をクリックします。

ステップ 8

[クラスタの詳細（Cluster Details）] を入力します。

[クラスタ起動（Cluster Bringup）] ウィザードの [クラスタの詳細（Cluster Details）] 画面で、次の情報を入力します。

1. Nexus ダッシュボード クラスタの [クラスタ名（Cluster Name）] を入力します。

クラスタ名は、 RFC-1123 の要件に従う必要があります。

2. （オプション）クラスタの IPv6 機能を有効にする場合は、[IPv6 を有効にする（Enable IPv6）] チェックボックスをオンにします。

3. [+DNS プロバイダの追加（+Add DNS Provider）] をクリックして、1 つ以上の DNS サーバを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

4. （オプション）[+DNS 検索ドメインの追加（+Add DNS Search Domain ）] をクリックして、検索ドメインを追加します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

5. （オプション）NTP サーバー認証を有効にする場合には、[NTP 認証（NTP Authentication）] チェックボックスをオンにし、[NTP キーの追加（Add NTP Key）]をクリックします。

次のフィールドで、以下の情報を提供します。

- NTP キー：Nexus ダッシュボードと NTP サーバ間の NTP トラフィックを認証するために使用される暗号キー。次の手順で NTP サーバーを定義します。複数の NTP サーバで同じ NTP キーを使用できます。

- キー ID：各 NTP キーに一意のキー ID を割り当てる必要があります。この ID は、NTP パケットの検証時に使用する適切なキーを識別するために使用されます。

- 認証タイプ：このリリースでは、MD5、SHA、および AES128CMAC 認証タイプがサポートされています。

- このキーが信頼できるかどうかを選択します。信頼できないキーは NTP 認証に使用できません。

（注）

情報を入力した後、チェックマーク アイコンをクリックして保存します。

NTP 認証の要件とガイドラインの完全なリストについては、すべての有効なサービスの前提条件と注意事項 を参照してください。

6. [+ NTP ホスト名/IP アドレスの追加（+Add NTP Host Name/IP Address）] をクリックして、1 つ以上の NTP サーバを追加します。

次のフィールドで、以下の情報を提供します。

- NTP ホスト：IP アドレスを指定する必要があります。完全修飾ドメイン名（FQDN）はサポートされていません。

- キー ID：このサーバーの NTP 認証を有効にする場合は、前の手順で定義した NTP キーのキー ID を指定します。

NTP 認証が無効になっている場合、このフィールドはグレー表示されます。

- この NTP サーバーを [優先（Preferred）] にするかどうかを選択します。

情報を入力した後、チェックマーク アイコンをクリックして保存します。

（注）

ログインしているノードに IPv4 アドレスのみが設定されているが、前の手順で [IPv6 を有効にする（Enable IPv6）] をオンにして NTP サーバーの IPv6 アドレスを指定した場合は、次の検証エラーが表示されます。

これは、ノードに IPv6 アドレスがまだなく（次の手順で指定します）、NTP サーバーの IPv6 アドレスに接続できないためです。

この場合、次の手順の説明に従って他の必要な情報の入力を完了し、[次へ（Next）] をクリックして次の画面に進み、ノードの IPv6 アドレスを入力します。

追加の NTP サーバーを指定する場合は、[+NTP ホストの追加（+Add NTP Host）] を再度クリックし、このサブステップを繰り返します。

7. [プロキシ サーバー（Proxy Server）] を指定し、[検証（Validate）] をクリックします。

Cisco Cloud に直接接続できないクラスタの場合は、接続を確立するためにプロキシ サーバを構成することをお勧めします。これにより、ファブリック内の非適合ハードウェアおよびソフトウェアにさらされるリスクを軽減できます。

[+無視するホストを追加（+Add Ignore Host）] をクリックして、プロキシをスキップする 1 つ以上の IP アドレス通信を提供することもできます。

プロキシ サーバーでは、次の URL が有効になっている必要があります。

dcappcenter.cisco.com
svc.intersight.com
svc.ucs-connect.com
svc-static1.intersight.com
svc-static1.ucs-connect.com

プロキシ設定をスキップする場合は、[プロキシをスキップ（Skip Proxy）] をクリックします。

8. (オプション) プロキシ サーバで認証が必要な場合は、[プロキシで認証が必要（Authentication required for Proxy）] を [はい（Yes）] に変更し、ログイン資格情報を指定します。

9. (オプション) [詳細設定（Advanced Settings）] カテゴリを展開し、必要に応じて設定を変更します。

詳細設定では、次の設定を行うことができます。

- カスタム App Network と Service Network を提供します。

アプリケーション オーバーレイ ネットワークは、Nexus ダッシュボードで実行されるアプリケーションのサービスで使用されるアドレス空間を定義します。このフィールドには、デフォルトの 172.17.0.1/16 値が事前に入力されています。

サービス ネットワークは、Nexus ダッシュボードとそのプロセスで使用される内部ネットワークです。このフィールドには、デフォルトの 100.80.0.0/16 値が事前に入力されています。

以前に [IPv6 を有効にする（Enable IPv6）] オプションをオンにした場合は、アプリケーション ネットワークとサービス ネットワークの IPv6 サブネットを定義することもできます。

アプリケーションおよびサービスネットワークについては、このドキュメントの前の すべての有効なサービスの前提条件と注意事項 の項で説明します。

10. [次へ（Next）] をクリックして続行します。

ステップ 9

[ノードの詳細（Node Details）] 画面で、ノードの情報を入力します。

1. 最初のノードの横にある [編集（Edit）]ボタンをクリックします。

2. ノードの名前を入力します。

管理ネットワークとデータ ネットワークの情報は、クラスタを展開する前に構成した VNET サブネットから既に入力されています。

クラスタは、指定された VNET から 6 つのサブネットを作成し、そこからデータと管理ネットワークがクラスタの 3 つのノードに割り当てられます。

3. IPv6 アドレスと VLAN フィールドは空白のままにします。

Cloud Nexus ダッシュボード クラスタは、これらのオプションをサポートしていません。

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

ステップ 10

[ノードの追加（Add Node）] をクリックして、クラスタに 2 番目のノードを追加します。

[ノードの詳細（Node Details）] ウィンドウが開きます。

1. ノードの名前を入力します。

2. [資格情報（Credentials）] セクションで、ノードのパブリック IP アドレスとテンプレートの展開時に指定したパスワードを入力し、[検証（Verify）] をクリックします。

IP アドレスとパスワードは、そのノードの管理ネットワークとデータ ネットワーク情報を取得するために使用され、下のフィールドに入力されます。

3. ノード タイプの [プライマリ（Primary）] を選択していることを確認します。

3 ノード クラスタはクラウド展開でのみサポートされるため、すべてのノードは [プライマリ（Primary）] である必要があります。

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

ステップ 11

前の手順を繰り返して、3番目のノードを追加します。

ステップ 12

[ノードの詳細（Node Details）] ページで、[次へ（Next）] をクリックして続行します。

ステップ 13

クラスタの展開モードを選択します。

1. 有効にするサービスを選択します。

リリース 3.1(1) より前では、クラスタの初期展開が完了した後に、個々のサービスをダウンロードしてインストールする必要がありました。今では、初期インストール時にサービスを有効にするように選択できます。

（注）

クラウド展開は Orchestrator 展開をサポートするため、他の展開モードを選択しないようにしてください。

2. [永続サービスIP/プールの追加（Add Persistent Service IPs/Pools）] をクリックして、Insights またはファブリック コントローラ サービスに必要な 1 つ以上の永続 IP を指定します。

永続的 IP の詳細については、ユーザー ガイドのすべての有効なサービスの前提条件と注意事項のセクションを参照してください。

3. [次へ（Next）] をクリックして続行します。

ステップ 14

[概要（Summary）] 画面で設定情報をレビューして確認し、[保存（Save）] をクリックし、[続行（Continue）] をクリックして正しい展開モードを確認し、クラスタの構築を続行します。

ノードのブート ストラップとクラスタの起動中に、全体的な進捗状況と各ノードの個々の進捗状況がUIに表示されます。ブートストラップの進行状況が表示されない場合は、ブラウザでページを手動で更新し、ステータスを更新してください。

クラスタが形成され、すべてのサービスが開始されるまでに最大 30 分かかる場合があります。クラスタの設定が完了すると、ページが Nexus ダッシュボード GUI にリロードされます。

ステップ 15

クラスタが健全であることを検証します。

展開モードに応じて、クラスタが形成されすべてのサービスが開始されるまでに最大 30 分かかる場合があります。

クラスタが使用可能になったら、ノードの管理 IP アドレスのいずれかを参照してアクセスできます。admin ユーザーのデフォルト パスワードは、最初のノードに選択した rescue-user のパスワードと同じです。この間、UI は上部に「サービスのインストールが進行中です。Nexus Dashboard の設定タスクは現在無効になっています」という意味のバナーを表示します。

すべてのクラスタが展開され、すべてのサービスが開始されたら、[概要（Overview）] ページでクラスタが正常であることを確認できます。

または、SSH を使用し、rescue-user として、ノード展開中に指定したパスワードを使っていずれかのノードにログインし、acs health コマンドを実行してクラスタの状態を確認できます。

- クラスタが収束している間、次の出力が表示されることがあります。

$ acs health
k8s install is in-progress

$ acs health
k8s services not in desired state - [...]

$ acs health
k8s: Etcd cluster is not ready

- クラスタが稼働している場合は、次の出力が表示されます。

$ acs health
All components are healthy

（注）

場合によっては、ノードの電源を再投入（電源をオフにしてから再度オン）すると、この段階でスタックが停止することがある可能性があります。

deploy base system services

これは、pND（物理 Nexus Dashboard）クラスタの再起動後のノードの etcd の問題が原因です。

この問題を解決するには、影響を受けるノードで acs reboot clean コマンドを入力します。

ステップ 16

必要なポートでノードのセキュリティ グループを更新します。

この手順では、Cisco NDFC サイトのオンボーディングに必要なポート構成で Nexus Dashboard ノードのインスタンスを更新する方法について説明します。Nexus Dashboard クラスタへの NDFC ファブリックのオンボーディングを計画していない場合は、この手順をスキップできます。

1. Azure ポータルで、Nexus ダッシュボードを展開したリソース グループに移動します。

これは、手順 2 で選択したのと同じリソース グループです。

2. ノードのデータ インターフェイスにアタッチされているセキュリティ グループを選択します。

セキュリティ グループの名前は nsg-data-<region>-... で始まります。。

3. セキュリティ グループの設定ナビゲーション バーで、[受信セキュリティ ルール（Inbound security rules）] を選択します。

4. [+ 追加（+Add）] をクリックして新しいインバウンド セキュリティ ルールを追加し、ポート 443 でのインバウンド通信を許可する詳細を指定します。

新しいルールについて、次の情報を提供します。

- [送信元（Source）] で、[任意（Any）] を選択します。

- [送信元ポート範囲（Source port ranges）] には、443 と入力します。

- [宛先（Destination）] で、[任意（Any）] を選択します。

- [宛先ポート範囲（Destination port ranges）] に、443 と入力します。

- [プロトコル（Protocol）] には、[TCP] を選択します。

- [アクション（Action）] で、[許可（Allow）] を選択します。

- [優先度（Priority）] で、300 ～ 320 の優先度を選択します。

たとえば、305 です。

- ルールの名前を指定します。

5. [+ 追加（+Add）] をクリックして新しいインバウンド セキュリティ ルールを追加し、ポート 9092 でのインバウンド通信を許可する詳細を指定します。

前のサブステップを繰り返して、次の詳細を含む別のルールを追加します。

- [送信元（Source）] で、[任意（Any）] を選択します。

- [送信元ポート範囲（Source port ranges）] には、9092 と入力します。

- [宛先（Destination）] で、[任意（Any）] を選択します。

- [宛先ポート範囲（Destination port ranges）] に、9092 と入力します。

- [プロトコル（Protocol）] には、[TCP] を選択します。

- [アクション（Action）] で、[許可（Allow）] を選択します。

- [優先度（Priority）] で、300 ～ 320 の優先度を選択します。

例えば、310。

- ルールの名前を指定します。

Chapter12. ファブリックのオンボーディング

- Cisco ACI ファブリックの導入準備

- Insights 用 Cisco ACI ファブリックでの Cisco マルチサイト サイト間ファブリック ネットワークおよびポッド間ネットワーク デバイスの導入準備

- NDFC ファブリックの導入準備

- NX-OS スイッチの導入準備

Cisco ACI ファブリックの導入準備

このセクションでは、1 つ以上の Cisco ACI ファブリックを Nexus Dashboard に導入準備する方法について説明します。

始める前に

- NDFC ファブリックをACIファブリックと同じクラスタに導入準備しないでください。

- スタンドアロン NX-OS スイッチを ACI ファブリックと同じクラスタに搭載することは可能ですが、スケールは縮小され、物理クラスタのみになります。

- 3 ノード クラスタの場合、最大 25 台のスタンドアロン NX-OS スイッチ（サポートされる合計 300 台のスイッチのうち）を使用できます。

- 6 ノード クラスタの場合、最大 50 台のスタンドアロン NX-OS スイッチ（サポートされる合計 1000 台のスイッチのうち）を使用できます。

- ファブリック接続で説明しているように、ファブリック接続がすでに設定されている必要があります。

- ファブリック接続で説明されているように、Nexus Dashboard データ ネットワーク IP 接続の EPG/L3Out は、すでに設定されている必要があります。

- Nexus Dashboard からデータネットワークを介した Cisco Application Policy Infrastructure Controller（APIC） インバンド IP への IP 接続がすでに構成されている必要があります。

- Nexus Dashboard から、データネットワークを介したリーフ ノードおよびスパイン ノードのインバンド IP への IP 接続がすでに設定されている必要があります。

手順

ステップ 1

[管理（Manage）] > [ファブリック（Fabrics）] に移動します。

ステップ 2

[ファブリック ファブリックの追加（Add fabric site）] をクリックします。

これにより、ファブリックの導入準備ワークフローが開始します。

ステップ 3

[手動追加（Manually Add）] を選択し、[コントローラ ベースのファブリック（Controller Based Fabric）] を選択します。

Insights サービスがインストールされていない場合、この選択は表示されず、ファブリックの導入準備はデフォルトでこのオプションになります。

ステップ 4

ファブリック情報を提供します。

- [ホスト名/IP アドレス（Host Name/IP Address）]：Cisco APIC との通信に使用する IP アドレスを入力します。

（注）

アドレスを指定する場合、URL 文字列の一部としてプロトコル（http:// または https://）を含めないでください。追加すると、ファブリックの導入準備に失敗します。

- [ユーザー名（User Name）] と [パスワード（Password）]：追加するファブリックで管理者権限を持つユーザーのクレデンシャル。

- （オプション）[ログイン ドメイン（Login Domain）]：このフィールドを空白にすると、ファブリックのローカル ログインが使用されます。

- （オプション）[ピア証明書を検証（Validate Peer Certificate）]：Nexus Dashboard が、接続先ホスト（例えばファブリック コントローラ）の証明書が有効であることと、信頼されている認証局（CA）に署名されていることを検証できるようにします。

（注）

このオプションを使用してファブリックを追加する前に、このファブリックの証明書を Nexus Dashboard にインポートしておく必要があります。証明書をまだ追加していなければ、オンボーディング ワークフローをキャンセルし、まず Nexus Dashboard ドキュメント ライブラリの「管理者のタスク」の記事に記されている手順に従います。証明書をインポートしたら、ここに説明されている方法でファブリックを追加します。有効な証明書をインポートせずに [ピア証明書を検証] オプションを有効にするとファブリックの導入準備は機能不全になります。

- （オプション）このファブリックのコントローラへの接続にプロキシが必要な場合は、[プロキシの使用（Use Proxy）] オプションを有効にします。

プロキシは、Nexus Dashboard の 管理コンソールですでに設定されている必要があります。

ステップ 5

追加のファブリックの [詳細（Details）] を入力します。

- [名前（Name）]：ファブリックの説明的な名前。

- [場所（Location）]：サイトの地理的な場所。このオプションは、オンプレミス ファブリックでのみ使用できます。

ステップ 6

[概要（Summary）] ページで情報を確認し、[保存（Save）] をクリックしてファブリックの追加を完了します。

Insights 用 Cisco ACI ファブリックでの Cisco マルチサイト サイト間ファブリック ネットワークおよびポッド間ネットワーク デバイスの導入準備

Nexus Dashboard Insightsで使用するために、Cisco Application Centric Infrastructure（ACI）ファブリック内の Cisco ACI マルチサイト ファブリック間ネットワークおよびポッド間ネットワーク デバイスを導入準備できます。これにより、 Nexus Dashboard Insights がファブリック間ネットワークおよびポッド間ネットワーク デバイスのネットワークの正常性を可視性化できるようになります。

手順

ステップ 1

[管理（Manage）] > [ファブリック（Fabrics）] に移動します。

ステップ 2

[ファブリックの追加（Add fabric）] をクリックします。

これにより、ファブリックの導入準備ワークフローが開始します。

ステップ 3

[手動追加（Manually Add）] を選択し、 [NX-OS スタンドアロン ファブリック（NX-OS Standalone Fabric）] を選択します。

（注）

コントローラなしで NX-OS スイッチを初めてオンボーディングする場合は、[NX-OS 検出の有効化（Enable NX-OS Discovery）] をクリックします。

ステップ 4

ファブリック情報を入力します。

- [シード スイッチ IP アドレス（Seed Switch IP Address）]：ファブリック内の他のスイッチを検出するために使用されるシード スイッチの IP アドレスを指定します。

- [ユーザー名（Username）] と [パスワード（Password）]：シード スイッチのログイン クレデンシャルを提供します。

ステップ 5

追加のファブリックの [詳細（Details）] を入力します。

- [名前（Name）]：ファブリックのわかりやすい名前。

- [場所（Location）]：ファブリックの地理的な場所。このオプションは、オンプレミス ファブリックでのみ使用できます。

ステップ 6

[スイッチの選択（Switch Selection）] ページで、ファブリックに追加する 1 台以上のポッド間ネットワーク スイッチを選択します。

スイッチ検出プロセスのデフォルトでは、シード スイッチから 2 ホップ離れたスイッチが表示されます。デフォルトの設定は、[ホップ数（Number of Hops） ] ドロップダウンを使用し、[スイッチの再検出（Rediscover Switches）] をクリックして変更できます。

スイッチが検出されたら、左側のリストでファブリックに追加するすべてのスイッチを選択し、右矢印をクリックして右側のリストに移動します。

スイッチはデフォルトの リーフ ロールで追加されますが、必要に応じて他のロールに変更できます。[次へ（Next ）] をクリックして続行します。

ステップ 7

[概要（Summary）] ページで情報を確認し、[保存（Save）] をクリックしてファブリックの追加を完了します。

ステップ 8

（オプション）既存のスタンドアロン NX-OS ファブリックにスイッチを追加します。

最初にファブリックを追加した後、GUI でファブリックを選択してスイッチを追加できます。

- Insights 向け Cisco ACI ファブリックにおける Cisco マルチサイト サイト間ネットワークおよびポッド間ネットワーク デバイスの注意事項と制限事項

Insights 向け Cisco ACI ファブリックにおける Cisco マルチサイト サイト間ネットワークおよびポッド間ネットワーク デバイスの注意事項と制限事項

Cisco Application Centric Infrastructure （ACI）ファブリックに Cisco ACI マルチサイト サイト間ネットワーク（ISN）とポッド間ネットワーク（IPN）デバイスを導入準備する場合は、次の注意事項と制限事項が適用されます。

- スタンドアロン NX-OS スイッチを導入準備する場合は、 Nexus Dashboard の Insights 展開モードを使用する必要があります。サポートされるスケールの詳細については、「Nexus Dashboard キャパシティ プランニング」ツールを参照してください。

- ISN および IPN デバイスは、3 ノードまたは 6 ノードの物理 Nexus Dashboard クラスタでのみサポートされます。

- 3ノード物理クラスタは、最大 15 の ISN および IPN デバイスをサポートします。

- 6ノードの物理クラスタは、最大 50 の ISN および IPN デバイスをサポートします。

NDFC ファブリックの導入準備

このセクションでは、1 つ以上の NDFC ファブリックを Nexus Dashboard にオンボードする方法について説明します。

（注）

クラスタを展開したら、[ファブリック コントローラ（Fabric Controller）] > [管理（Admin）] > [システム設定（System Settings）] > [機能管理（Feature Management）] に移動し、サポートされているモードのいずれかを選択して、NDFC 展開ペルソナを構成します。

NDFC サービスでファブリックを作成すると、Nexus Dashboard にファブリックとして自動的に追加されます。次の手順は、各サービスが個別のクラスタに展開されているファブリックコントローラと Insights コロケーションの使用例で、異なる Nexus Dashboard クラスタからファブリックを導入準備する場合にのみ必要です。

始める前に

- NDFC ファブリックとして同じクラスタに ACI ファブリックを導入準備しないでください。

- NDFC ファブリックとして同じクラスタにスタンドアロン NX-OS スイッチを導入準備しないでください。

- ファブリック接続で説明しているように、ファブリック接続がすでに設定されている必要があります。

- ファブリックとスイッチへのレイヤ 3 接続がすでに設定されている必要があります。

- クラスタが AWS または Azure に展開されている場合は、データ インターフェイスでインバウンド ルールを設定する必要があります。

手順

ステップ 1

[管理（Manage）] > [ファブリック（Fabrics）] に移動します。

ステップ 2

[ファブリック ファブリックの追加（Add fabric site）] をクリックします。

これにより、ファブリックの導入準備ワークフローが開始します。

ステップ 3

[ファブリックの追加（Add Fabric）] 画面で、[コントローラベースのサイト（Controller Based Fabric）] を選択します。

ステップ 4

ファブリック情報を提供します。

- [ホスト名/IP アドレス（Host Name/IP Address）]： Cisco NDFC との通信に使用する IP アドレスを入力します。

（注）

NDFC ファブリックの場合、これは NDFC のインバンド IP アドレスである必要があります。

アドレスを指定する場合、URL 文字列の一部としてプロトコル（http:// または https://）を含めないでください。追加すると、ファブリックの導入準備に失敗します。

- [ユーザー名（User Name）] と [パスワード（Password）]：追加するファブリックで管理者権限を持つユーザーのクレデンシャル。

- （オプション）[ログイン ドメイン（Login Domain）]：このフィールドを空白にすると、ファブリックのローカル ログインが使用されます。

- （オプション）[ピア証明書を検証（Validate Peer Certificate）]：Nexus Dashboard が、接続先ホスト（例えばファブリック コントローラ）の証明書が有効であることと、信頼されている認証局（CA）に署名されていることを検証できるようにします。

（注）

このオプションを使用してファブリックを追加する前に、このファブリックの証明書を Nexus Dashboard にインポートしておく必要があります。証明書をまだ追加していなければ、導入準備ワークフローをキャンセルし、まず Nexus Dashboard ドキュメント ライブラリの「管理者」の記事に記されている手順に従います。証明書をインポートしたら、ここに説明されている方法でファブリックを追加します。有効な証明書をインポートせずに [ピア証明書を検証] オプションを有効にするとファブリックの導入準備は機能不全になります。

ステップ 5

追加のファブリックの [詳細（Details）] を入力します。

- [名前（Name）]：ファブリックの説明的な名前。

- [場所（Location）]：サイトの地理的な場所。このオプションは、オンプレミス ファブリックでのみ使用できます。

ステップ 6

[概要（Summary）] ページで情報を確認し、[保存（Save）] をクリックしてファブリックの追加を完了します。

NX-OS スイッチの導入準備

ここでは、1 つ以上のスタンドアロン Cisco NX-OS スイッチを Nexus Dashboard に導入準備する方法について説明します。

（注）

コントローラ（Cisco Application Policy Infrastructure Controller（APIC） や NDFC など）を使用せずにスタンドアロン NX-OS スイッチを導入準備する場合、次の制限が適用されます。

- NDFC ファブリックと同じクラスタにスタンドアロン NX-OS スイッチを導入準備しないでください。

- スタンドアロン NX-OS スイッチを ACI ファブリックと同じクラスタに搭載することは可能ですが、スケールは縮小され、物理クラスタのみになります。

- 3 ノード クラスタの場合、最大 25 台のスタンドアロン NX-OS スイッチ（サポートされる合計 300 台のスイッチのうち）を使用できます。

- 6 ノード クラスタの場合、最大 50 台のスタンドアロン NX-OS スイッチ（サポートされる合計 1000 台のスイッチのうち）を使用できます。

- Nexus Dashboard Insights サービスのみがスタンドアロン NX-OS スイッチをサポートします。つまり、スタンドアロン NX-OS スイッチを導入準備する Nexus Dashboard クラスタで複数のサービスを共同ホストすることはできません。

- NX-OS スイッチのオンボーディングをサポートするのは、物理 Nexus Dashboard クラスタのみです。

- スタンドアロン NX-OS スイッチをオンボードするのと同じ Nexus ダッシュボード クラスタに NDFC サービスをインストールしないでください。

- スタンドアロン NX-OS スイッチをオンボーディングする前に、以下のステップ 3 で説明するように、クラスタで「NX-OS スイッチ ディスカバリ」を有効にする必要があります。

- Nexus Dashboard Insights サービスが NDFC または NDO と共存している場合、NX-OS スイッチの検出は使用できません。

- NX-OS スイッチ検出の有効化は、管理者ユーザーが行う必要があります。

- また、データネットワークに 10 個の永続 IP（IPv4 を使用している場合）および 8 個の IP（IPv6 を使用している場合）を設定する必要があります。

永続IPは、 [Nexusダッシュボード（Nexus Dashboard）] > [管理コンソール（Admin Console）] > [システム設定（System Settings）] > [外部サービスプール（External Service Pools） ] > [データサービス IP（ Data Service IPs）] ページで設定できます。

- すべての NX-OS スイッチで NX-OS スイッチの自動検出のための Cisco Discovery Protocol（CDP）を有効にする必要があります。

トランスペアレント ファイアウォールは通常、ネットワークのプロトコル データ ユニット（PDU）をフラッディングし、望ましくない CDP ネイバーにつながる可能性があります。ディスカバリ関連の不一致を回避するために、トランスペアレント ファイアウォール デバイスに接続するインターフェイスで CDP を無効にすることを推奨します。

- NX-OS スイッチの自動検出はスイッチの管理インターフェイスを使用するため、Nexus Dashboard を NX-OS スイッチの管理ネットワークへ到達できるように設定する必要があります。

手順

ステップ 1

[管理（Manage）] > [ファブリック（Fabrics）] に移動します。

ステップ 2

[ファブリックの追加（Add fabric）] をクリックします。

これにより、ファブリックの導入準備ワークフローが開始します。

ステップ 3

[手動追加（Manually Add）] を選択し、 [NX-OS スタンドアロン ファブリック（NX-OS Standalone Fabric）] を選択します。

（注）

コントローラなしで NX-OS スイッチを初めてオンボーディングする場合は、[NX-OS 検出の有効化（Enable NX-OS Discovery）] をクリックします。

ステップ 4

ファブリック情報を提供します。

- [シード スイッチ IP アドレス（Seed Switch IP Address）]：ファブリック内の他のスイッチを検出するために使用されるシード スイッチの IP アドレスを指定します。

- [ユーザー名（Username）] と [パスワード（Password）]：シード スイッチのログイン クレデンシャル。

ステップ 5

追加のファブリックの [詳細（Details）] を入力します。

- [名前（Name）]：ファブリックの説明的な名前。

- [場所（Location）]：サイトの地理的な場所。このオプションは、オンプレミス ファブリックでのみ使用できます。

ステップ 6

[スイッチの選択（Switch Selection）] ページで、ファブリックに追加する 1 台以上のスイッチを選択します。

スイッチ検出プロセスのデフォルトでは、シード スイッチから 2 ホップ離れたスイッチが表示されます。デフォルトの設定は、[ホップ数（Number of Hops） ] ドロップダウンを使用し、[スイッチの再検出（Rediscover Switches）] をクリックして変更できます。

スイッチが検出されたら、左側のリストでファブリックに追加するすべてのスイッチを選択し、右矢印をクリックして右側のリストに移動します。

スイッチはデフォルトの リーフ ロールで追加されますが、必要に応じて他のロールに変更できます。[次へ（Next ）] をクリックして続行します。

ステップ 7

[概要（Summary）] ページで情報を確認し、[保存（Save）] をクリックしてファブリックの追加を完了します。

ステップ 8

（オプション）既存のスタンドアロン NX-OS ファブリックにスイッチを追加します。

最初にファブリックを追加した後、GUI でファブリックを選択してスイッチを追加できます。

PartIII. このリリースへのアップグレードまたは移行

- 既存の ND クラスタをこのリリースへアップグレード

- DCNM から NDFC への移行

Chapter13. 既存の ND クラスタをこのリリースへアップグレード

- 既存の Nexus Dashbaord クラスタをアップグレードするための前提条件と注意事項

- サポート対象のアップグレード パス

- Nexus ダッシュボードのアップグレード

- 既存の 9 ノード クラスタから 6 ノード クラスタへの変換

- アップグレードのトラブルシューティング

既存の Nexus Dashbaord クラスタをアップグレードするための前提条件と注意事項

既存のNexusダッシュボードクラスタをアップグレードする前に、次の手順を実行します。

- アップグレードに影響する可能性のある動作、ガイドライン、および問題の変更については、ターゲット リリースのリリース ノートを必ずお読みください。

- このリリースにアップグレードすると、クラスタで有効になっているサービスの数を変更できなくなります。

以前、各クラスタには、有効なサービスの組み合わせを定義する「展開モード」があり、サービスの組み合わせをクラスタの展開またはアップグレード後に変更することはできません。つまり、このリリースにアップグレードした後、クラスタを再展開せずにサービスの追加や削除を行うことはできません。クラスタ内のサービスを追加または削除する予定の場合は、リリース 3.2.1 にアップグレードする前に行うことをお勧めします。

（注）

場合によっては、リリース 3.2.1 でサポートされている展開モードが、以前のリリースではサポートされていなかった場合があります（たとえば、Insights と Orchestrator の共存は、リリース 3.0.1 の仮想クラスタではサポートされていません）。このような場合、現在のクラスタに単一のサービス（Insights など）が展開されていて、アップグレード後に別のサービス（Orchestrator など）を追加するには、次の手順を実行します。

1. 現在のクラスタ内の既存の Insights サービスを無効にします。

2. 現在のクラスタに追加の Orchestrator サービスをインストールします。

3. 現在のクラスタで Orchestrator サービスを有効にします。

この時点で、Insights と Orchestrator の両方が現在のクラスタにあって、Insights は無効になり、Orchestrator は有効になります。現在のリリースでサポートされている設定でない場合は、両方のサービスを同時に有効にしないでください。

4. Orchestrator サービスを無効にして、アップグレードを続行します。

- 4 ノードまたは 5 ノードの物理クラスタで Nexus Dashboard Insights サービスを実行している場合は、通常どおりにクラスタとサービスをこのリリースにアップグレードし、4 ノードまたは 5 ノードクラスタを引き続き使用できます。

Nexus Dashboard Insights を搭載した Nexus Dashboard リリース 3.2(1) で、グリーンフィールド展開を行う場合は、 3 ノードおよび 6 ノードのプロファイルのみがサポートされます。ただし、現在のスケールを変更せずに、既存の 4 ノードまたは 5 ノード クラスタを以前のリリースからアップグレードする場合は、リリース 3.2(1) で引き続き使用できます。

- 物理的な Nexus Dashboard クラスタをアップグレードしている場合は、ノードにターゲットの Nexus Dashboard リリースでサポートされている最小の CIMC バージョンがあることを確認してください。

サポートされている CIMC バージョンは、ターゲット リリースの Nexus Dashboard リリース ノート にリストされています。

CIMC アップグレードについては、Nexus Dashboard ドキュメント ライブラリ の「トラブルシューティング」の記事で詳しく説明されています。

- Linux KVM に展開された仮想 Nexus Dashboard クラスタをアップグレードする場合は、Virtual Machine Manager の UI で [ホスト CPU 設定のコピー（Copy host CPU configuration ）] オプションを有効にする必要があります。

このリリースは、次のカーネルおよび KVM バージョンを搭載した CentOS 7.9 または Red Hat Enterprise Linux 8.6 をサポートします。

- CentOS 7.9 の場合、Kernel バージョン 3.10.0-957.el7.x86_64 および KVM バージョン libvirt-4.5.0-23.el7_7.1.x86_64

- RHEL 8.6 の場合、Kernel バージョン 4.18.0-372.9.1.el8.x86_64 および KVM バージョン libvert 8.0.0

- VMware ESX に展開された仮想 Nexus Dashboard クラスタをアップグレードする場合は、ESX のバージョンがターゲット リリースで引き続きサポートされていることを確認します。

このリリースは、VMware ESXi 7.0、7.0.1、7.0.2、7.0.3、8.0、8.0.2 をサポートしています。

（注）

ESX サーバーをアップグレードする必要がある場合は、Nexus Dashboard をターゲット リリースにアップグレードする前に行う必要があります。ESX のアップグレードはこのドキュメントの範囲外ですが、簡単に説明すると次のとおりです。

1. 既存の Nexus Dashboard ノード VM を実行している場合に通常行うように、ESX ホストの 1 つをアップグレードします。

2. ホストがアップグレードされた後、Nexus Dashboard クラスタが正常に動作していることを確認します。

3. 他の ESX ホストで 1 つずつアップグレードを繰り返します。

4. すべての ESX ホストがアップグレードされ、既存の Nexus Dashboard クラスタが正常な状態になったら、このドキュメントの説明に従って、Nexus Dashboard をターゲット リリースにアップグレードします。

- Nexus Dashboard リリース 3.0(1) またはそれ以降を実行して、リリース 3.2(1) に直接アップグレードする必要があります。

それより前のバージョンの Nexus Dashboard を実行している場合は、それぞれの展開ガイドの説明に従って、最初にリリース 3.0(1) にアップグレードすることをお勧めします。

（注）

既存の Nexus Dashboard リリース 3.0(1) 以降のクラスタと互換性があり、展開されているサービス バージョンであれば、クラスタとともにターゲット リリースにアップグレードされます。

- 現在の Nexus ダッシュボードクラスタが正常であることを確認します。

Nexus ダッシュボードの管理コンソール（Admin Console）の [概要（Overview）] ページでシステムのステータスを確認するか、rescue-user としてノードの1つにログインし、acs health コマンドを実行して All components are healthy が返ってくることを確認します。

- このリリースにアップグレードする前に、クラスタで実行されているすべてのサービスを無効にする必要があります。

（注）

このリリースの統合インストールイメージにより、既存のすべてのサービスは、設定を保持しながら、このNexus Dashboardリリースと互換性のあるバージョンに自動的にアップグレードされます。また、アップグレードが完了すると、サービスは自動的に再度有効になります。

保持してターゲットリリースにアップグレードする必要のある既存のサービスについては、少なくとも 1 回有効になっていることを確認してください。インストールされているものの、既存のクラスタで有効にしたことがないサービスがある場合、アップグレードの検証は失敗します。アップグレードを再試行する前に、アクティブ化されていないサービスを削除するか、アクティブ化してください。

- アップグレードを続行する前に、データを保護し、潜在的なリスクを最小限に抑えるために、アップグレードの前に Nexus ダッシュボードとサービスの構成バックアップを実行する必要があります。

- アップグレードの進行中には、セカンダリまたはスタンバイノードを追加するなど、構成変更がクラスタに対して行われていないことを確認します。

- Nexus Dashboard ではプラットフォームのダウングレードはサポートされていません。

以前のリリースにダウングレードするには、新しいクラスタを展開してサービスを再インストールする必要があります。

サポート対象のアップグレード パス

Nexus Dashboard リリース3.1(1) より前では、プラットフォーム ソフトウェアと個々のサービスは、サポートされている特定のバージョンの組み合わせの範囲内で、相互に独立してアップグレードできました。そのため、以前のリリースのドキュメントには、各アップグレード段階ですべてのコンポーネント間の互換性を確保するために、複数のリリースにわたる特定のアップグレード パスが記載されていました。

この要件は、Nexus Dashboard と個々のサービス間のより緊密な結合により、各サービスの単一バージョンのみがプラットフォームの各バージョンと互換性があるため、削除されました。その結果、現在 Nexus Dashboard ソフトウェアの必要最小限のバージョン（既存の Nexus Dashbaord クラスタをアップグレードするための前提条件と注意事項 に記載）を使用している限り、プラットフォームと現在有効になっているすべてのサービスの両方をこのリリースに直接アップグレードできます。

次の表に、特定の展開の組み合わせに関するシナリオの例をいくつか示します。

現在の Nexus Dashboard リリース

互換性のあるサービス

（フォーム ファクタとクラスタ サイズによっては、これらのサービスの 1 つ以上が現在有効になっている場合があります）

アップグレードのワークフロー

3.1(1)

ファブリックコントローラ：12.2(1)

Orchestrator：4.3(x)

Insights：6.4(1)

次のセクションの説明に従って、リリース 3.2.1 に直接アップグレードします。

すべてのサービスは、プラットフォームとともに自動的にアップグレードされます。

3.0(1)

ファブリック コントローラ：12.1(3)

Orchestrator：4.2(x)

Insights：6.3(1)

次のセクションの説明に従って、リリース 3.2.1 に直接アップグレードします。

すべてのサービスは、プラットフォームとともに自動的にアップグレードされます。

3.0(1) より前のリリース

ファブリックコントローラ：12.1(2) 以前

Orchestrator：4.1(x) 以前

Insights：6.2(x) 以前

1. 『Nexus Dashboard 展開ガイド、リリース 3.0.x』の説明に従って、 Nexus Dashboard プラットフォームをリリース 3.0(1) にアップグレードします。

2. サービス固有のドキュメントに記載されているアップグレード パスまたは最小バージョン要件を使用して、以前に行ったように、個々のサービスを Nexus Dashboard リリース 3.0(1) と互換性のあるバージョンにアップグレードします。

- ファブリック コントローラ

- オーケストレータ

- [Insights]https://www.cisco.com/c/en/us/support/data-center-analytics/nexus-insights/products-installation-guides-list.html

3. リリース 3.0(1) からリリース 3.2(1) にアップグレードします。

すべてのサービスは、プラットフォームとともに自動的にアップグレードされます。

Nexus ダッシュボードのアップグレード

ここでは、既存の Nexus ダッシュボード クラスタをアップグレードする方法について説明します。

（注）

アップグレードのワークフローと機能はリリース 3.0(1) または 3.1(1) のどちらからアップグレードする場合でも同じですが、UI は過去のいくつかのリリースで変更されており、以下の各ステップで違いが示されています。

始める前に

- で説明している前提条件をすべて満たしていることを確認します。 既存の Nexus Dashbaord クラスタをアップグレードするための前提条件と注意事項

手順

ステップ 1

Nexusダッシュボードイメージをダウンロードします。

1. [ソフトウェア ダウンロード（Software Download）] ページを参照します。

https://software.cisco.com/download/home/286327743/type/286328258

2. ダウンロードするNexusダッシュボードのバージョンを選択します。

3. ターゲットとするリリース用の Nexus ダッシュボード イメージをダウンロードします。

（注）

アップグレード プロセスは、すべての Nexus ダッシュボード フォーム ファクタで同じで、Nexus ダッシュボード ISO イメージ（nd-dk9.<version>.iso）を使用します。言い換えると、最初の展開で仮想フォーム ファクターを使用していた場合（ESX での展開のための .ova イメージなど）やクラウド プロバイダーのマーケット プレースを使用していた場合であっても、アップグレードでは .iso イメージを使用する必要があります。

4. イメージを自分の環境内の Web サーバーでホストします。

環境内のサーバーでイメージをホストすることをお勧めします。イメージを Nexus Dashboard クラスタにアップロードする場合、イメージに直接 URL を指定するオプションがあります。そうすれば、プロセスは相当高速化されます。

ステップ 2

現在の Nexus ダッシュボードの管理コンソールに管理者ユーザーとしてログインします。

ステップ 3

リリース 3.0(1) からアップグレードする場合、クラスタにインストールされている既存のサービスを無効にします。

リリース3.1(1) からアップグレードする場合は、このステップをスキップできます。

（注）

リリース 3.0(1) で、クラスタのアップグレードをする前にすべてのサービスを無効化する必要があります。サービスを無効にしても、サービスを削除しないでください。無効化されたサービスは、アップグレード プロセスが完了すると自動的に再アクティブ化されます。

1. メイン ナビゲーション メニューから [操作（Operate）] > [サービス（Services）] を選択します。

2. サービスのタイルで、アクション（…）メニューをクリックし、[無効化（Disable）] を選択します。

3. クラスタに展開されているすべてのサービスについて、この手順を繰り返します。

ステップ 4

クラスタから既存のアップグレード イメージを削除します。

クラスタを初めてアップグレードする場合は、この手順をスキップできます。

1. [ソフトウェア管理（Software Management）] ページに移動します。

- リリース 3.0(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

- リリース 3.1(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

2. 前のアップグレードから既存のアップグレード イメージを削除します。

- リリース 3.0(1) では、[イメージ（Images）] タブを選択します。既存のアップグレード イメージの横にあるアクション メニュー（...）から、[イメージの削除（Delete Image）] を選択します。

- リリース3.1(1) では、既存のアップグレード イメージの並べて表示するのゴミ箱アイコンをクリックします。

3. すべての既存のアップグレード イメージについて、この手順を繰り返します。

ステップ 5

新しいイメージをクラスタにアップロードします。

1. [ソフトウェア管理（Software Management）] ページに移動します。

- リリース 3.0(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

- リリース 3.1(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

2. [Add Image] をクリックします。

- リリース3.0(1) では、最初に [イメージ（Images）] タブを選択し、[イメージの追加（Add Image）] をクリックします。

- リリース3.1(1) では、[イメージの追加（Add Image）] をクリックします。

3. [ソフトウェアイメージの追加（Add Software Image）] ウィンドウで、イメージがマシン上で [ローカル（Local）] であるか、Web サーバー上の [リモート（Remote）] であるかを選択します。

4. [ファイルの選択（Choose file）] をクリックするか、最初の手順でダウンロードしたイメージの URL を入力します。

5. [アップロード（Upload）] をクリックして、イメージを追加します。

6. イメージ ステータスが「ダウンロード済み」に変わるのを待ちます。

イメージが Nexus ダッシュボード クラスタにアップロードされ、解凍されて処理され、アップグレードに使用できるようになります。プロセス全体に数分かかる場合があり、[イメージ（Images）] タブでプロセスのステータスを確認できます。

ステップ 6

アップグレードをセットアップします。

1. [ソフトウェア管理（Software Management）] ページに移動します。

- リリース 3.0(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

- リリース 3.1(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

2. [更新の設定（Set Up Update）] をクリックします。

（注）

以前にクラスタをアップグレードしたことがある場合、ページには代わりに以前のアップグレードの詳細が表示されます。その場合は、ページの右上にある [詳細の変更（Modify Details）] ボタンをクリックして、新しいアップグレード情報を提供します。

[ファームウェアの更新（Update Firmware）] ダイアログボックスが開きます。

3. [セットアップ（Setup）] > [バージョン選択（Version selection）] 画面で、アップロードしたファームウェア バージョンを選択し、[次へ（Next）] をクリックします。

4. [セットアップ（Setup）] > [確認（Confirmation）] 画面で、詳細を確認し、[検証（Validate）] をクリックします。

セットアップは、アップグレードを確実に成功させるために、いくつかの準備段階と検証段階を経ます。終了するまでに数分かかる場合があります。

5. 検証が完了したら、[インストール（Install）] をクリックします。

インストールの進行状況ウィンドウが表示されます。更新中は、この画面から移動できます。後で更新ステータスを確認するには、[ソフトウェア管理（Software Management）] 画面に移動し、[続行（Continue）] をクリックします。

このステップには最大 20 分間かかります。これにより、必要な Kubernetes イメージとサービスがセットアップされますが、クラスタは新しいバージョンに切り替わりません。次の手順で新しいイメージをアクティブ化するまで、クラスタは既存のバージョンを実行し続けます。

ステップ 7

新しい画像をアクティブにします。

アップグレード画面から移動したことがない場合は、[アクティブ化（Activate）] をクリックして新しいイメージをアクティブ化します。

1. [ソフトウェア管理（Software Management）] ページに戻ります。

- リリース 3.0(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

- リリース 3.1(1) では、 [管理（Manage）] > [ソフトウェア管理（Software Management）] に移動します。

2. [最終更新ステータス（Last Update Status）] タイルで、[続行（Continue）] をクリックします。

3. [ファームウェア アップデート（Firmware Update）]の > [インストール（Install）] 画面で、[アクティブ化（Activate）] をクリックします。

[アクティブ化（Activate）] をクリックすると、クラスタはバックグラウンド サービスを停止します。これには数分かかる場合があります。その後、再起動します。アクティブ化の段階ですべてのノードが同時に再起動し、ノードの再起動後にすべてのクラスタサービスが開始されるので、GUI が使用可能になるまでにさらに最大 20 分かかる場合があることに注意してください。

[概要（Overview）] ページで進行状況とサービスステータスを確認できます。

アップグレードが完了すると、既存のサービスが [概要（Overview）] ページ に [正常（ Healthy）] と表示されます。

ステップ 8

(オプション) 新しい UCS-C225-M6 ハードウェアに移行します。

（注）

Nexus ダッシュボード ノードを新しい UCS-C225-M6 サーバーに置き換える予定がない場合は、この手順をスキップできます。

UCS-C220-M5 ハードウェアを使用して展開された既存の Nexus ダッシュボード クラスタを移行するには、新しい UCS-C225-M6 ノードを stadby ノードとして既存のクラスタに追加し、古いノードの 1 つをフェイルオーバーするだけです。次に、古いクラスターの残りのノードについて、一度に 1 ノードずつプロセスを繰り返します。スタンバイ ノードの追加と使用については、Nexus Dashboard ドキュメント ライブラリの「インフラストラクチャ管理」の記事で詳しく説明されています。

ステップ 9

9 ノードの仮想 ND クラスタをアップグレードした場合は、既存の 9 ノード クラスタから 6 ノード クラスタへの変換 で説明されているように、3 つのセカンダリ ノードを削除してリソース フットプリントを削減することをお勧めします。

リリース 3.2(1) より前は、サポートされている最大規模の Nexus Dashboard Insights を使用する仮想 Nexus Dashboard クラスタには、9 つのノード（3 つの プライマリ OVA-Data と 6 つの セカンダリ OVA-App）が必要でした。 プラットフォームの改善により、 Nexus Dashboard のリリース 3.2(1) は、代わりに 6 ノード（3 つの プライマリ OVA-Data と 3 つの セカンダリ OVA-App）で同じスケールをサポートできます。

既存の 9 ノード クラスタから 6 ノード クラスタへの変換

リリース 3.2(1) より前は、サポートされている最大規模の Nexus Dashboard Insights を使用する仮想 Nexus Dashboard クラスタには、9 つのノード（3 つの プライマリ OVA-Data と 6 つの セカンダリ OVA-App）が必要でした。 プラットフォームの改善により、 Nexus Dashboard のリリース 3.2(1) は、代わりに 6 ノード（3 つの プライマリ OVA-Data と 3 つの セカンダリ OVA-App）で同じスケールをサポートできます。

前のセクションの説明に従ってクラスタのアップグレードが完了したら、3 つの OVA-App ノードを削除してクラスタのフットプリントを減らすことをお勧めします。

始める前に

- 9 ノード クラスタをアップグレードしない場合は、このセクションをスキップしてください。

- 9 ノード クラスタをアップグレードする場合は、クラスタのサイズを縮小する前に、前のセクションで説明したアップグレード プロセスを完了しておく必要があります。

手順

ステップ 1

管理者ユーザーとして Nexus Dashboard [管理コンソール（Admin Console）] にログインします。

ステップ 2

クラスタが正常にアップグレードされ、正常であることを確認します。

1. [管理コンソール（Admin Console）] の [概要プラットフォーム ビュー（Overview > Platform View）] ページで、[クラスタの正常性（Cluster Health）] が [OK] であることを確認します。

2. [管理コンソール（Admin Console）] の [管理システム設定（Admin > System Settings）] ページで、システムの問題が表示されていないことを確認します。

ステップ 3

[ノードの管理（ > Manage Nodes）] に移動します。

ステップ 4

3 つの非プライマリ ノードを一度に 1 つずつ削除します。

1. 非プライマリ ノードの 1 つ（ [OVA-App]）の横にあるアクション（[...]）メニューをクリックし、[削除（Delete）] をクリックします。

ノードの [ロール（Role）] はページの表に表示されますが、最初にノードの名前をクリックすると、そのノード プロファイルを確認できます。

2. ノードを削除した後少なくとも 10 分待って、クラスタが安定し、[概要（Overview）] > [プラットフォーム ビュー（Platform View）] および [管理（Admin）] > [システム設定（System Settings）]にエラーが表示されないことを確認します。

3. このステップをさらに 2 回繰り返して、さらに 2 つの非プライマリ OVA-App ノードを削除します。

一度に 1 つのノードを削除し、クラスタが安定してから別のノードを削除する必要があります。

ステップ 5

3 つの OVA-App ノードを削除したら、クラスタが正常であることを確認し、 ESXi ホストからそれらのノードの VM を削除します。

アップグレードのトラブルシューティング

前のセクションで説明した、新しいイメージのアクティブ化段階で、すべてのノードが再起動した後、GUI にログインしてアップグレードワークフローのステータスを確認できます。最初は、クラスタの初期展開と同様のブートストラッププロセスを確認できます。ノードが起動すると、GUI の [概要（Overview）] ページでサービスのアクティブ化に関する追加情報を確認できます。

何らかの理由でアップグレードが失敗した場合、GUI にエラーと追加の回避策の手順が表示されます。それでも、GUI を使用して問題を解決できなかった場合は、 rescue-user としてノードにログインし、このセクションで説明されているコマンドを実行することで、手動でアップグレードを再試行できます。

手順

ステップ 1

すべての Nexus Dashboard クラスタ ノードに rescue-user としてログインします。

すべてのノードで同時にリカバリコマンドを実行する必要があるため、次の手順に進む前に各ノードにログインしてください。

ステップ 2

すべてのノードに rescue-user としてログインしていることを確認します。

ステップ 3

特定のシナリオに応じて必要なコマンドを実行します。

1 つ以上のノードが再起動せず、古いリリースがまだ実行されているためにアップグレードに失敗する場合は、手動アップグレードを試行できます。ただし、手動アップグレードには Cisco TACのみが生成できるルート アクセスが必要なため、Cisco TAC に連絡して手動アップグレードのサポートを受ける必要があります。

ステップ 4

すべてのノードでインストーラが完了するまで待ちます。

ステップ 5

acs reboot コマンドを使用して、すべてのノードを同時に再起動します。

ノードの再起動後、UI にログインして、通常の UI ベースのアップグレードと同様にブートストラップの進行状況を確認できます。

ステップ 6

ノードのアップグレード タスクが完了したら、ノードが正常であり、UI にログインできることを確認します。

ブートストラップ プロセスが完了すると、通常どおりに Nexus Dashboard ダッシュボード UI を表示できます。

[概要（Overview）] ページでシステム全体の正常性を確認し、[管理（Manage）] > [ソフトウェアの管理（Software Management）]ページで現在の実行中バージョンを確認できます。

さらに、[分析（Analyze）] > [サービス ステータス（Service Status ）]ページで、サービスのステータスを確認します。

Chapter14. DCNM から NDFC への移行

- DCNM から NDFC への移行の前提条件と注意事項

- 既存の DCNM 設定の NDFC への移行

DCNM から NDFC への移行の前提条件と注意事項

（注）

ファブリック コントローラ サービスで Nexus Dashboard をすでに実行している場合は、このセクションをスキップし、代わりに 既存の ND クラスタをこのリリースへアップグレード の説明に従ってアップグレードしてください。

DCNM 11.5(4) からのアップグレードは、次のワークフローで構成されます。

1. このセクションに記載されている前提条件とガイドラインが満たされていることを確認します。

2. ターゲット NDFC リリースに固有の移行ツールを使用して、既存の設定をバックアップします。

3. ファブリック コントローラ（NDFC）サービスを使用して、新しい Nexus Dashboard クラスタを展開します。

以前のリリースでは、クラスタがすでに展開された後にサービスをインストールし、有効にする必要がありましたが、このリリースでは、統合インストールの導入により、クラスタの初期展開時にサービスを有効にすることに注意してください。

4. ステップ 1 で作成した設定のバックアップを復元します。

（注）

アップグレードを実行する前に：

- 各ファブリックのクレデンシャルの検証

- LAN ファブリックの場合、[Web UI] > [管理（Administration）] > [クレデンシャルの管理（Credentials Manage）] > [LAN のクレデンシャル（LAN Credentials）] ページで、各ファブリックを選択し、[検証（Validate）] を選択して行います。

- SAN ファブリックの場合、[Web UI] > [管理（Administration）] > [クレデンシャルの管理（Credentials Manage）] > [SAN のクレデンシャル（SAN Credentials）] ページで、各ファブリックを選択し、[検証（Validate）] を選択して行います。

- Thousand Eyes 統合アプリケーションなどのアプリケーションを DCNM で実行している場合は、移行手順を進める前にそのアプリケーションを無効化にします。

ペルソナ互換性

適切なアップグレード ツールを使用することで、次の表に示すように、ペルソナのために新しく展開された Nexus Dashboard Fabric Controller に、DCNM リリース 11.5(4) からバックアップされたデータを復元できます。

DCNM 11.5（4）からのバックアップ

アップグレード後の NDFC でのペルソナの有効化

OVA/ISO/SE での DCNM 11.5（4）ローカル エリア ネットワーク（LAN）ファブリックの展開

ファブリック コントローラ + ファブリック ビルダー

OVA/ISO/SE でのDCNM 11.5（4）PMN の展開

ファブリック コントローラ +メディアの IP ファブリック（IPFM）

OVA/ISO/SE での DCNM 11.5（4）SAN の展開

SAN コントローラ

Linux での DCNM 11.5（4）SAN の展開

SAN コントローラ

Windows での DCNM 11.5（4）SAN の展開

SAN コントローラ

アップグレード後の機能の互換性

次の表に、アップグレード後に DCNM 11.5(4) のバックアップから復元される機能に関連する注意点を示します。

（注）

SAN Insights および VMM Visualizer 機能は、復元後に有効になりません。 Nexus Dashboard ファブリック コントローラ UI の [設定（Settings）] > [機能管理（Feature Management）] ページで有効にするように選択できます。

DCNM 11.5（4）の機能

アップグレードのサポート

構成された Nexus Dashboard Insights

詳細については、Cisco Nexus Dashboard ユーザー ガイドを参照してください。

サポート対象

コンテナ オーケストレータ (K8s) ビジュアライザ

サポート対象

vCenter による VMM の可視性

サポート対象

構成された Nexus Dashboard Orchestrator

未サポート

設定されたプレビュー フィーチャー

サポート対象外

SAN インストールの LAN スイッチ

サポート対象外

IPv6 で検出されたスイッチ

サポート対象外

DCNM トラッカー

サポート対象外

ファブリックのバックアップ

未サポート

レポート定義とレポート

未サポート

スイッチのイメージとイメージ管理ポリシー

サポート対象外

SAN CLI テンプレート

11.5(4)から繰り越されません

イメージ/イメージ管理データの切り替え

11.5(4)から繰り越されません

低速ドレイン データ

11.5(4)から繰り越されません

Infoblox 設定

11.5(4)から繰り越されません

エンドポイント ロケーションの設定

アップグレード後に、エンドポイント ロケータ（EPL）を再構成する必要があります。ただし、履歴データは最大 500 MB まで保持されます。

アラーム ポリシーの設定

11.5(4)から繰り越されません

パフォーマンス管理データ

アップグレード後、最大 90 日間の CPU/メモリ/インターフェイス統計情報が復元されます。

温度データ

温度データはバックアップに保存されないため、移行後に復元されません。移行後に温度データ収集を再度有効にする必要があります。

既存の DCNM 設定の NDFC への移行

このセクションでは、既存の DCNM 11.5(4) 設定をバックアップし、新しい Nexus Dashboard クラスタを展開し、設定を復元して移行を完了する方法について説明します。

手順

ステップ 1

アップグレード ツールをダウンロードします。

1. NDFC ダウンロードページに移動します。

https://software.cisco.com/download/home/281722751/type/282088134/

2. [最新のリリース（Latest Releases）] リストで、ターゲットとするリリースを選択します。

3. 展開タイプに適したアップグレード ツールをダウンロードします。

DCNM 11.5(4) 展開タイプ

アップグレード ツールのファイル名

ISO/OVA

DCNM_To_NDFC_12_2_2_Upgrade_Tool_OVA_ISO.zip

Linux または Windows

DCNM_To_NDFC_12_2_2_Upgrade_Tool_LIN_WIN.zip

4. sysadmin アカウントを使用して、アップグレード ツール イメージを既存の DCNM 11.5(4) サーバーにコピーします。

ステップ 2

アーカイブを抽出し、Linux/Windows 展開の署名を検証します。

（注）

ISO/OVA アーカイブを使用している場合は、次の手順へスキップします。

1. Python 3 がインストールされていることを確認します。

$ python3 --version
Python 3.9.6

2. ダウンロードしたアーカイブを解凍します。

# unzip DCNM_To_NDFC_12_2_2_Upgrade_Tool_LIN_WIN.zip
Archive: DCNM_To_NDFC_12_2_2_Upgrade_Tool_LIN_WIN.zip
extracting: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip
extracting: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip.signature
inflating: ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM
inflating: cisco_x509_verify_release.py3

3. 署名を検証します。

ZIP アーカイブ内にはアップグレード ツールと署名ファイルがあります。アップグレード ツールを検証するには、次のコマンドを使用します。

# ls -l
-rwxr-xr-x. 1 root root 16788 Apr 20 2023 cisco_x509_verify_release.py3
-rw-r--r--. 1 root root 1422 Aug 12 2023 ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM
-rw-r--r--. 1 root root 9541673 Jul 25 03:09 DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip
-rw-r--r--. 1 root root 256 Jul 25 03:09 DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip.signature
-rw-r--r--. 1 root root 9548328 Jul 26 06:11 DCNM_To_NDFC_12_2_2_Upgrade_Tool_LIN_WIN.zip

# ./cisco_x509_verify_release.py3 -e ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM -i DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip -s DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip.signature -v dgst -sha512

Retrieving CA certificate from https://www.cisco.com/security/pki/certs/crcam2.cer ...
Successfully retrieved and verified crcam2.cer.
Retrieving SubCA certificate from https://www.cisco.com/security/pki/certs/innerspace.cer ...
Successfully retrieved and verified innerspace.cer.
Successfully verified root, subca and end-entity certificate chain.
Successfully fetched a public key from ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM.
Successfully verified the signature of DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip using ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM

4. 検証スクリプト署名を確認したら、スクリプト自体を抽出します。

# unzip DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip
Archive: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN.zip
creating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/log4j2.properties
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/DCNMBackup.sh
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/DCNMBackup.bat
creating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/jarchivelib-0.7.1-jar-with-dependencies.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/bcprov-jdk15on-1.68.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/not-going-to-be-commons-ssl-0.3.20.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/jnm.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/slf4j-simple-1.7.21.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/log4j.properties
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/dcnmbackup.jar
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/sequences.info.oracle
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/tables.info.postgres
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/sequences.info.postgres
inflating: DCNM_To_NDFC_Upgrade_Tool_LIN_WIN/jar/tables.info.oracle

ステップ 3

アーカイブを抽出し、ISO/OVA 展開の署名を検証します。

（注）

Linux/Windows アーカイブを使用している場合は、次の手順にスキップします。

1. ダウンロードしたアーカイブを解凍します。

# unzip DCNM_To_NDFC_12_2_2_Upgrade_Tool_OVA_ISO.zip
Archive: DCNM_To_NDFC_12_2_2_Upgrade_Tool_OVA_ISO.zip
inflating: DCNM_To_NDFC_Upgrade_Tool_OVA_ISO
extracting: DCNM_To_NDFC_Upgrade_Tool_OVA_ISO.signature
inflating: cisco_x509_verify_release.py3
inflating: ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM

2. 署名を検証します。

ZIP アーカイブ内にはアップグレード ツールと署名ファイルがあります。アップグレード ツールを検証するには、次のコマンドを使用します。

# ./cisco_x509_verify_release.py3 -e ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM -i DCNM_To_NDFC_Upgrade_Tool_OVA_ISO -s DCNM_To_NDFC_Upgrade_Tool_OVA_ISO.signature -v dgst -sha512
Retrieving CA certificate from https://www.cisco.com/security/pki/certs/crcam2.cer ...
Successfully retrieved and verified crcam2.cer.
Retrieving SubCA certificate from https://www.cisco.com/security/pki/certs/innerspace.cer ...
Successfully retrieved and verified innerspace.cer.
Successfully verified root, subca and end-entity certificate chain.
Successfully fetched a public key from ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM.
Successfully verified the signature of DCNM_To_NDFC_Upgrade_Tool_OVA_ISO using ACI_4070389ff0d61fc7fbb8cdfdec0f38f30482c22e.PEM

ステップ 4

既存の設定をバックアップします。

バックアップ ツールは、過去 90 日間の Performance Management データを収集します。

1. DCNM リリース 11.5(4) アプライアンス コンソールにログインします。

2. スクリーン セッションを作成します。

次のコマンドは、追加のコマンドを実行するためのセッションを作成します。

dcnm# screen

このコマンドは、ウィンドウが表示されていない場合、または切断された場合でも実行を続けることに注意してください。

3. スーパー ユーザー（root）アクセス権を取得します。

dcnm# su
Enter password: <root-password>
[root@dcnm]#

4. OVA および ISO の場合は、アップグレード ツールの実行権限を有効にします。

[root@dcnm]# chmod +x ./DCNM_To_NDFC_Upgrade_Tool_OVA_ISO

5. 前の手順でダウンロードしたアップグレード ツールを実行します。

- Windowsの場合：

C:\DCNM_To_NDFC_Upgrade_Tool_LIN_WIN>DCNMBackup.bat
Enter DCNM root directory [C:\Program Files\Cisco Systems\dcm]:
Initializing, please wait...
*******************************************************************************
Welcome to DCNM-to-NexusDashboard Upgrade Tool for Linux/Windows.
This tool will analyze this system and determine whether you can move to Nexus Dashboard 3.2.1 or not.
If upgrade to Nexus Dashboard 3.2.1 is possible, this tool will create files to be used for performing the upgrade.
Thank you!
*******************************************************************************
This tool will backup config data. Exporting Operational data like Performance(PM) might take some time.
Do you want to export operational data also? [y/N]: y
*******************************************************************************
Sensitive information will be encrypted using an encryption key.
This encryption key will have to be provided when restoring
the backup file generated by this tool.
Please enter the encryption key:
Enter it again for verification:
…..
2024-07-25 22:35:34,944 [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection [id: 0][route: {s}->https://127.0.0.1:9200] can be kept alive indefinitely
2024-07-25 22:35:34,944 [main] DEBUG org.apache.http.impl.conn.DefaultManagedHttpClientConnection - http-outgoing-0: set socket timeout to 0
2024-07-25 22:35:34,944 [main] DEBUG org.apache.http.impl.conn.PoolingHttpClientConnectionManager - Connection released: [id: 0][route: {s}->https://127.0.0.1:9200][total kept alive: 1; route allocated: 1 of 20; total allocated: 1 of 20]
2024-07-25 22:35:34,969 [main] INFO DCNMBackup - Total number of Json data entries in backup/es/pmdb_sanportratedata_daily.data ==> 145
2024-07-25 22:35:35,036 [main] INFO DCNMBackup - ###### Total time to export Daily data: 7 seconds.
2024-07-25 22:35:35,036 [main] INFO DCNMBackup - ###### Total time to export PM data: 36 seconds.
2024-07-25 22:35:35,169 [main] INFO DCNMBackup - Creating data file...
2024-07-25 22:35:38,083 [main] INFO DCNMBackup - Creating metadata file...
2024-07-25 22:35:38,085 [main] INFO DCNMBackup - Creating final backup archive...
2024-07-25 22:35:38,267 [main] INFO DCNMBackup - Done

- Linuxの場合：

# ./DCNMBackup.sh
Enter DCNM root directory [/usr/local/cisco/dcm]:
Initializing, please wait...
*******************************************************************************
Welcome to DCNM-to-NexusDashboard Upgrade Tool for Linux/Windows.
This tool will analyze this system and determine whether you can move to Nexus Dashboard 3.2.1 or not.
If upgrade to Nexus Dashboard 3.2.1 is possible, this tool will create files to be used for performing the upgrade.
Thank you!

*******************************************************************************

This tool will backup config data. Exporting Operational data like Performance(PM) might take some time.
Do you want to export operational data also? [y/N]: y
*******************************************************************************
Sensitive information will be encrypted using an encryption key.
This encryption key will have to be provided when restoring
the backup file generated by this tool.

Please enter the encryption key:
Enter it again for verification:
……
2024-07-26 04:04:46,540 [main] INFO DCNMBackup - Total number of Json data entries in backup/es/pmdb_sanportratedata_daily.data ==> 92
2024-07-26 04:04:46,543 [main] INFO DCNMBackup - ###### Total time to export Daily data: 3 seconds.
2024-07-26 04:04:46,543 [main] INFO DCNMBackup - ###### Total time to export PM data: 11 seconds.
2024-07-26 04:04:46,958 [main] INFO DCNMBackup - Creating data file...
2024-07-26 04:04:47,456 [main] INFO DCNMBackup - Creating metadata file...
2024-07-26 04:04:47,467 [main] INFO DCNMBackup - Creating final backup archive...
2024-07-26 04:04:47,478 [main] INFO DCNMBackup - Done.

- OVA の場合：

# ./DCNM_To_NDFC_Upgrade_Tool_OVA_ISO
*******************************************************************************
Welcome to DCNM-to-NexusDashboard Upgrade Tool for OVA/ISO.
This tool will analyze this system and determine whether you can move to
Nexus Dashboard 3.2.1 or not.
If upgrade to Nexus Dashboard 3.2.1 is possible, this tool will create files
to be used for performing the upgrade.
NOTE:
Only backup files created by this tool can be used for upgrading,
older backup files created with 'appmgr backup' CAN NOT be used
for upgrading to Nexus Dashboard 3.2.1
Thank you!

*******************************************************************************
Continue? [y/n]: y
Collect operational data (e.g. PM, EPL)? [y/n]: y
Does this DCNM 11.5(4) have DCNM Tracker feature enabled on any switch on any fabric? [y/n]: n

Sensitive information will be encrypted using an encryption key.
This encryption key will have to be provided when restoring
the backup file generated by this tool.

Please enter the encryption key:
Enter it again for verification:
……
Adding backup header
Collecting DB table data
Collecting DB sequence data
Collecting stored credentials
Collecting Custom Templates
Collecting CC files
Collecting L4-7-service data
Collecting CVisualizer data
Collecting EPL data
Collecting PM data - WARNING: this will take a while!
Collecting AFW app info
Decrypting stored credentials
Adjusting DB tables
Creating dcnm backup file
Creating final backup file
Done.
Backup file: backup11_sandcnm_20240726-113054.tar.gz

ステップ 5

このドキュメントの前の章のいずれかの説明に従って、新規に Nexus Dashboard クラスタを展開します。

Nexus Dashboard プラットフォーム、ファブリック コントローラ サービス、および上記の導入の章に記載されている特定のフォーム ファクタのすべてのガイドラインと前提条件を満たしていることを確認します。

（注）

- DCNM 設定の復元に進む前に、Nexus Dashboard ファブリック コントローラ UI で、必要な数の永続 IP アドレスを指定する必要があります。

- 既存の設定で Cisco Smart Software Management（CSSM）に直接接続するスマート ライセンスを使用している場合は、新しい Nexus Dashboard に CSSM Web サイトに到達するために必要なルートがあることを確認する必要があります。

smartreceiver.cisco.com の IP アドレスのサブネットが、Nexus Dashboard 管理ネットワーク用に、Nexus Dashboard の [管理（Admin）] > [システム設定（System Settings）] > [ルート（Routes）]ページのルート テーブルに追加されていることを確認します。

最新のサブネットを見つけるには、smartreceiver.cisco.com に ping を実行します。次の例をご覧ください。

$ ping smartreceiver.cisco.com
PING smartreceiver.cisco.com (146.112.59.81): 56 data bytes
64 bytes from 146.112.59.81: icmp_seq=0 ttl=52 time=48.661 ms
64 bytes from 146.112.59.81: icmp_seq=1 ttl=52 time=44.730 ms
64 bytes from 146.112.59.81: icmp_seq=2 ttl=52 time=48.188 ms

さらに、NDFC は新しい製品インスタンスと見なされるため、信頼を再確立する必要があります。期限切れの信頼トークンを使用してバックアップを作成した場合は、アップグレード後にスマート ライセンス設定ウィザードを手動で実行し、有効なトークンを入力する必要があります。

ステップ 6

Nexus Dashboard リリース 3.2.1 で導入された統合バックアップおよび復元機能を使用して、新しいクラスタに構成のバックアップを復元します。

詳細については、「Nexus Dashboard とサービスの統合バックアップおよび復元」を参照してください。

1. バックアップから復元する前に、NDFC ファブリックを導入準備します。

これらの手順では、以前に作成したバックアップから復元します。バックアップが作成されたときに NDFC サービスが ND の一部であった場合は、この復元プロセスを開始する前に NDFC ファブリックを導入準備する必要があります。

2. 管理コンソール GUI の統合バックアップと復元ページに移動します。[管理（Admin）] > [バックアップと復元（」Backup & Restore）]。

すでに構成されているバックアップは、[バックアップ（Backups）] ページに表示されます。

3. 次のいずれかの方法を使用して、[復元（Restore）] スライダ ページにアクセスします。

- 復元するバックアップの省略記号（[…]）をクリックし、[復元（Restore）]を選択します。または、

- メインの [バックアップと復元（Backup and Restore）] ページの右上隅にある [復元（Restore）] をクリックします。

[復元（Restore）] スライド ページが表示されます。

4. 該当する場合、[送信元（Source）] フィールドで、復元するバックアップの場所を決定します。

（注）

特定のバックアップの省略記号（[…]）をクリックしてバックアップを復元する場合、このフィールドは編集できません。

- 構成バックアップ テーブルのアップロード：[バックアップ ファイル（Backup File）] エリアが表示され、復元するローカル バックアップ ファイルをドラッグ アンド ドロップするか、システム上のローカル エリアに移動して復元するバックアップ ファイルを選択できます。

- リモート ロケーション：」

1. [リモート ロケーション（Remote Location）] フィールドで、リストからすでに構成されているリモート ロケーションを選択するか（使用可能な場合）、[リモート ロケーションの作成（Create Remote Location）] をクリックします。

[リモート ロケーションの作成（Create Remote Location）] をクリックした場合は、「Nexus Dashboard とサービスの統合バックアップおよび復元」の「リモート ロケーションの構成」の手順に従ってから、ここに戻ります。リモート バックアップ プロセスの一部としてリモート ロケーションを構成しますが、リモート バックアップを構成したクラスタとは異なるクラスタにいる場合、復元プロセスの一部としてリモート ロケーションを設定する必要がある場合があります。この場合、この時点でリモート ロケーションを再度設定します。これにより、システムは、他のクラスタで構成したリモート バックアップを検出できるようになります。

2. [リモート パス（Remote Path）] フィールドに、リモート バックアップが存在するリモート経路を入力します。

5. [暗号キー（Encryption Key）] フィールドにバックアップ ファイルに対する暗号キーを入力します。

6. [検証（Validation）]エリアのバックアップの行で、[検証してアップロード（Validate and Upload）] をクリックします。

7. 検証の進行状況バーに 100% が表示されると、[次へ（Next） ] ボタンが現用系になります。[次へ（Next）] をクリックします。

8. （オプション）[外部サービス IP 構成を無視する（Ignore External Service IP Configuration）] チェックボックスをオンにします。

[外部サービスの IP 設定を無視する（Ignore External Service IP Configuration）] チェック ボックスがオンになっている場合、外部サービスの IP 設定は無視されます。この選択により、システムでバックアップを作成し、それを別の管理サブネットやデータサブネットを持つ別のシステムに復元することができます。

9. [復元（Restore）] をクリックします。

復元プロセスを開始することを確認する警告ウィンドウが表示されます。復元プロセスの実行中は、 Nexus Dashboard の機能にアクセスできません。復元プロセスには数分かかる場合があります。

10. 警告ウィンドウで [復元（Restore）] をクリックして、復元プロセスを続行します。

別のウィンドウが表示され、復元プロセスの進行状況が表示されます。[タイプ（Type）] 列のエントリの横にある矢印をクリックすると、復元プロセスの詳細が表示されます。

11. 復元プロセスが成功すると、[進行状況（Progress）] に 100% と表示され、[履歴の表示（View History） ] ボタンが現用系になります。

[履歴の表示（View History）] をクリックして [バックアップと復元（Backup and Restore）] ウィンドウの [履歴（History）]エリアに移動すると、復元プロセスが表示され、[ステータス（Status）] 列に [成功（Success）] と表示されます。

（注）

新しい ND 統合バックアップおよび復元機能を使用してバックアップされた構成を復元した後、ND レベルで表示される NDFC ファブリックの状態が、NDFC ファブリックの実際の状態と同期していない可能性があります。NDFC ファブリックのステータスを同期中に戻すには、[ファブリック概要（Fabric Overview）] ページで、ページ上部の [アクション（Actions）] をクリックし、[再計算と展開（Recalculate and Deploy）] を選択します。

ステップ 7

アップグレード後のタスクを完了します。

1. SAN コントローラ ペルソナを使用している場合：

バックアップからデータを復元すると、すべての server-smart ライセンスが OutofCompliance になります。

UI の[操作（Operations）] > [ライセンス管理（License Management）] > [スマート（Smart）] ページから、ポリシーを使用したスマート ライセンシングに移行し、SLP を使用して CCSM との信頼を確立できます。

2. ファブリック コントローラ ペルソナを使用している場合：

DCNM 11.5(4) からアップグレードする場合、次の機能については引き継がれないため、再設定が必要です。

- エンドポイント ロケータを再設定する必要があります

- IPAM 統合を再設定する必要があります

- アラーム ポリシーを再設定する必要があります

- カスタム トポロジを再作成して保存する必要があります

- ファブリックで PM 収集を再度有効にする必要があります

- データの収集を開始するには、温度データ収集を再度有効にする必要があります

- スイッチ イメージをアップロードする必要があります

リリース 11.5(4) の展開タイプ

11.5(4) では、トラップ IP アドレスは以下から収集されます：

LAN デバイス管理の接続性

アップグレード後のトラップ IP アドレス

結果

LAN ファブリック

メディア コントローラ

eth1（または HA システムの場合 vip1）

管理

管理サブネットに属する

Honored

構成の違いは、ありません。対応不要です。

LAN ファブリック

メディア コントローラ

eth0（または HA システムの場合 vip0）

管理

管理サブネットに属していない

無視されます。管理プールの別の IP がトラップ IP として使用されます。

構成の違いが作成されます。Web UIの[LAN]-[Fabrics]-[Fabrics] で、[Fabric]をダブルクリックして[Fabric Overview] を表示します。[ファブリック アクション（Fabrics Actions）]ドロップダウン リストから、[設定の再計算（Recalculate Config）] を選択します。[構成の展開（Deploy Config）] をクリックします。

LAN ファブリック

メディア コントローラ

eth0（または HA システムの場合 vip0）

データ

データ サブネットに属する

Honored

構成の違いは、ありません。対応不要です。

LAN ファブリック

メディア コントローラ

eth0（または HA システムの場合 vip0）

データ

データ サブネットに属していない

無視されます。データ プールの別のIPがトラップ IP として使用されます

構成の違いが作成されます。Web UIの[LAN]-[Fabrics]-[Fabrics] で、[Fabric]をダブルクリックして[Fabric Overview] を表示します。[ファブリック アクション（Fabrics Actions）]ドロップダウン リストから、[設定の再計算（Recalculate Config）] を選択します。[構成の展開（Deploy Config）] をクリックします。

SAN 管理

OVA/ISO –

- trap.registaddress（設定されている場合）

- eth0（trap.registaddress が設定されていない場合）

Windows/Linux –

- trap.registaddress（設定されている場合）

- イベントマネージャ アルゴリズムに基づくインターフェイス（trap.registaddress が設定されていない場合）

N/A

データ サブネットに属する

Honored

構成の違いは、ありません。対応不要です。

N/A

データ サブネットに属していない

無視されます。データ プールの別のIPがトラップ IP として使用されます

Trademarks

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS REFERENCED IN THIS DOCUMENTATION ARE SUBJECT TO CHANGE WITHOUT NOTICE. EXCEPT AS MAY OTHERWISE BE AGREED BY CISCO IN WRITING, ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS DOCUMENTATION ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.

The Cisco End User License Agreement and any supplemental license terms govern your use of any Cisco software, including this product documentation, and are located at: https://www.cisco.com/go/softwareterms.Cisco product warranty information is available at https://www.cisco.com/go/warranty. US Federal Communications Commission Notices are found here https://www.cisco.com/c/en/us/products/us-fcc-notice.html.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any products and features described herein as in development or available at a future date remain in varying stages of development and will be offered on a when-and if-available basis. Any such product or feature roadmaps are subject to change at the sole discretion of Cisco and Cisco will have no liability for delay in the delivery or failure to deliver any products or feature roadmap items that may be set forth in this document.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: www.cisco.com go trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)