Nexus Dashboard プラットフォーム

Cisco Nexus Dashboard は、複数のデータ センター ファブリックのための中央管理コンソールで、ネットワーク ポリシーと運用のためのリアルタイム分析、可視性、保証を実現し、Cisco ACI や NX-OS などのデータ センター ファブリックのポリシー オーケストレーションを提供しています。

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

（注）	この文書は、Cisco Nexus Dashboard クラスタを最初に展開し、ファブリックをオンボードする方法について説明します。クラスタが稼働したら、日常の操作に関する Nexus Dashboard の設定と操作に関する記事を参照してください。

統合 Nexus Dashboard のデプロイメント

Nexus Dashboard（ND）プラットフォームと関連サービスは、以前に次の方法で利用できました。

• ND リリース 3.1 より前のリリースでは、 Nexus Dashboard にはプラットフォーム ソフトウェアのみが付属しており、サービスは含まれていませんでした。最初の ND プラットフォームの展開後、サービス（NDI、NDO、NDFC またはそのいずれか）を個別にダウンロード、インストール、および有効化します。

• ND リリース 3.1 および 3.2 では、 Nexus Dashboard は ND プラットフォーム ソフトウェアと個々のサービスのソフトウェアを統合されたパッケージ形式でパッケージ化しました。ただし、サービスは個別に有効にしたままです。ファブリックの管理とインサイトは、まだ統合されていない、独立した 2 つのピースでした。

  さらに、 Nexus Dashboard リリース 3.1 および 3.2 には「展開モード」の概念があり、展開モードを選択することで、Nexus Dashboard で特定のサービスを静的に有効にできます。ただし、展開モードの変更は、データや再インストールを含むサービス全体を消去する破壊的な試みでした。最後に、 Nexus Dashboard リリース 3.1 および 3.2 の単一の Nexus Dashboard クラスタですべてのサービスを実行することはできませんでした。

ND リリース 4.1 以降、プラットフォームと個々のサービスが 1 つの製品に統合されました。サービスを個別に展開および構成する必要がなくなり、個々のサービスをアクティブ化したり、展開モードを静的に構成したりする必要がなくなります。さらに、フォーム ファクタに応じて、以前のリリースでサービスとして出荷されていた機能を Nexus Dashboard で使用できます。独立したサービスの概念がなくなったため、ユーザー エクスペリエンスが統合され、代わりに、単一のダッシュボード ビューからすべての機能を利用できるようになりました。

（注）	展開したクラスタの形式とクラスタ ノードの数によっては、特定の機能（コントローラ、オーケストレータ、テレメトリなど）がユニファイド Nexus Dashboard 製品で使用できない場合があります。 Nexusダッシュボード キャパシティ プランニング ツール の情報を確認して、クラスターインストールで使用できる機能を確認します。

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

Nexus Dashboardは、ソフトウェアフレームワーク（Nexus Dashboard）がプリインストールされた、特殊なCisco UCSサーバ（Nexus Dashboardプラットフォーム）のクラスタとして提供されます。Cisco Nexus Dashboard ソフトウェアスタックは、ハードウェアから分離して、多数の仮想フォームファクタで展開できます。このドキュメントでは、「Nexus Dashboard worker」はハードウェアを指し、「Nexus Dashboard」はソフトウェア スタックと GUI コンソールを指します。さらに、「物理 Nexus Dashboard」または「pND」という用語を使用して、 Nexus Dashboard ソフトウェア スタックが事前にインストールされている Cisco UCS 物理アプライアンス ハードウェアを指し、「リモート対応 Nexus Dashboard」または「vND」という用語を指します。をデータ ノードとアプリケーション ノードをサポートするリモート対応フォームファクタに追加します。

このガイドでは、 Nexus Dashboardソフトウェアの初期デプロイメントについて説明します。これは、物理および仮想フォームファクタに共通です。物理クラスターを展開する場合は、 UCSサーバーのハードウェアの概要、仕様、およびラッキングの手順について 、 Nexus Dashboard ハードウェア セットアップ ガイドを 参照してください。

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

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

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

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

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

• 仮想アプライアンス：Nexus Dashboardクラスタを展開できる仮想フォームファクタで、VMware ESX（.ova）または RHEL KVM (.qcow2）を使用します。

  仮想フォームファクタは、次の 2 つのプロファイルをサポートしています。

  • データ ノード：このプロファイルは、システム要件が高いため、より大規模な展開や統合型のデプロイメント向けに設計されています。

  • アプリ ノード：システム要件が低いこのプロファイルは、セカンダリ ノードとして展開できます。プライマリ ノードとして展開することもできますが、統合型のデプロイメントはサポートしていません。

  AWS パブリック クラウド上で仮想 Nexus Dashboard（vND）を実行するためのサポートも提供されています。詳細については、「Amazon Web Services（AWS）での仮想 Nexus Dashboard（vND）の展開」を参照してください。

  Nexus Dashboard リリース 4.2(1) 以降では、Nutanix 上で仮想 Nexus Dashboard (vND) を実行するサポートも提供されます。詳細については、「Nutanix での仮想 Nexus Dashboard（vND）の展開」を参照してください。

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

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

基本的な Nexus Dashboard の展開は、通常、クラスタを起動するために必要な 1 つまたは 3 つの プライマリ ノードで構成されます。スケール要件に応じて、3 ノード以上のクラスターを最大 3 つのセカンダリ ノードを追加して拡張し、より高いスケールをサポートできます。クラスタへのセカンダリ ノードの追加は、クラスタのデプロイメント中に行う必要があり、クラスターの初期化後に追加することはできません。

• 物理クラスタの場合、プライマリノードに障害が発生した場合にクラスタを容易に回復できるようにするため、最大 2 つの スタンバイ ノードを追加することもできます。

• 仮想クラスタの場合、最大 2 つのスタンバイ ノードもサポートされますが、コントローラのみまたはオーケストレーションのみの展開の場合は 3 ノードの vND (アプリ) プロファイルでのみサポートされます。

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

スケールとクラスター サイジングの制限

次の制限は、スケーリングとクラスターのサイジングに適用されます。

• ND-NODE-G5L（UCS-C225-M8）ノードは、3ノード クラスター構成でのみ使用できます。

• 4 クラスター ノードの展開。ここでクラスターの構成は次のとおりです。

  • 3 つの仮想ノード（データ）、および

  • 1 つのスタンバイ ノード

  サポートする構成。スタンバイ ノードを使用せずにこのクラスターを再展開します。クラスター内のいずれかのノードに障害が発生した場合は、新しいノードを再インストールし、 [管理（Administration > ）] [システム（System）] [ステータス（Status）] > [ノード（Nodes）]に移動してから、 [アクション（Actions）] > [再登録（Re-Register）] をクリックして、再インストールしたノードをクラスターに戻します。

• 単一ノード展開は、初期の展開後に 3 ノード クラスタに拡張することはできません。

  単一ノード クラスターを展開し、それを 3 ノード クラスターに拡張するか、セカンダリ ノードを追加する場合は、それをバックアップし、新しい 3 ノード ベース クラスターを展開して、後でそのバックアップを復元する必要があります詳細については、「Nexus Dashboard のバックアップと復元」を参照してください。

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

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

  詳細については、「Cisco Nexus Dashboard を使用した高可用性サービスの展開」を参照してください。

• 既存のクラスタ全体のサイズを変更するために、プライマリ ノードまたはセカンダリ ノードを動的に追加または削除することはできません。クラスタのサイズを変更するには、クラスターをバックアップし、クラスタを必要なサイズに再構築してから、設定を復元する必要があります。新しいクラスタ サイズが、デプロイメントでサポートされているスケールおよび機能の要件を満たしていることを確認します。

• クラスタ サイズの変更が必要な場合は、一度に 1 つのセカンダリノードだけを削除します。クラスターが正常な状態に戻るまで待ってから、次のセカンダリノードを削除します。Nexus Dashboard GUI で、または acs health コマンドを実行して、クラスタの正常性を確認します。複数のセカンダリ ノードを同時に削除したり、クラスタの収束中に削除したりしないでください。

• 検証済みのスケールの場合、 Nexus Dashboard クラスタを初期展開する時に全ての必要なワーカー ノードを含める必要があります。追加のワーカー ノードは、既存のクラスタに追加することができます。しかし、現在のリリースでは、初期展開後にワーカー ノードを追加してもクラスタの検証済みスケール キャパシティがダイナミックに増加することはありません。追加ノードは、技術情報の大きいセットに渡ってワークロードを配布することに役立ち、個々のノードへの集中を軽減します。ワーカー ノードが追加された後にスケールのキャパシティを増やす必要がある場合、拡張されたトポロジがスケール構成に反映されるようにクラスタのバックアップと復元ができます。