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

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

各 Nexus ダッシュボード クラスタは通常、1 つまたは 3 つのマスターノードで構成されます。また、3 ノード クラスタの場合、マスターノードで障害が発生した際に簡単にクラスタを回復させられるよう、いくつかのワーカーノードをプロビジョニングして、水平スケーリングやスタンバイノードを有効化できます。このリリースでサポートされるワーカー ノードとスタンバイ ノードの最大数については、Cisco Nexus ダッシュボード リリース ノートの「検証済みのスケーラビリティ制限」セクションを参照してください。

（注）	このドキュメントでは、ベース クラスタの初期設定について説明します。クラスタが稼働したら、 『Cisco Nexus Dashboard User Guide』の説明に従って追加ノードを設定して展開できます。このガイドは、Nexus Dashboard GUI から直接入手することもできます。

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

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

このガイドでは、Nexus ダッシュボード ソフトウェアの初期導入について説明します。ハードウェアのセットアップについては 『Nexus Dashboard Hardware Setup Guide』で説明しています。その他の Nexus ダッシュボードの操作手順については、 『Cisco Nexus Dashboard User Guide』を参照してください。

[サービス（Services）]

Nexus ダッシュボードは、一貫した統一された方法ですべての Nexusダッシュボード製品を使用できるようにするサービスを構築および展開するための標準のアプライアンス プラットフォームです。Insights、Orchestrator、Fabric Controller、Data Broker などのサービスをサブスクライブして使用するには、Nexus ダッシュボード プラットフォームを使用して、これらのサービスに必要な容量とライフサイクル管理操作を提供します。

通常、Nexus ダッシュボード プラットフォームには、これらのサービスのライフサイクルを管理するために必要なソフトウェアのみが同梱されていますが、実際のサービスはアプライアンスにパッケージ化されていません。データ センターからのパブリック ネットワーク接続を許可している場合は、数回クリックするだけでサービスをダウンロードしてインストールできます。ただし、パブリック ネットワークに接続していない場合は、これらのサービスを手動でダウンロードしてプラットフォームにアップロードし、インストール操作を実行してから使用する必要があります。

物理的な Nexus ダッシュボードサーバーを購入する場合、Nexus ダッシュボード Insights および Nexus Dashboard Orchestrator サービスを、出荷前にハードウェアに事前インストールすることを選択できます。詳細については、『Nexus ダッシュボードの注文ガイド』を参照してください。Nexus ダッシュボードの仮想またはクラウド フォーム ファクターを展開している場合、サービスのインストールに変更はなく、クラスターの準備が整った後にサービスを個別に展開する必要があることに注意してください。

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

Cisco Nexus Dashboardのこのリリースは、さまざまなフォームファクタを使用して展開できます。ただし、すべてのノードに同じフォームファクタを使用する必要があります。同じクラスタ内で異なるフォームファクタを混在させることはサポートされていません。

• Cisco Nexus ダッシュボード物理アプライアンス（.iso）

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

  このドキュメントの後半のセクションでは、既存の物理アプライアンスハードウェアでソフトウェアスタックを設定してクラスタを展開する方法について説明します。元の Cisco Nexus ダッシュボード プラットフォーム ハードウェアのセットアップについては、 『Cisco Nexus Dashboard Hardware Setup Guide』を参照してください。

• VMware ESX (.ova)

  3つのVMware ESX仮想マシンを使用してNexusダッシュボードクラスタを展開できる仮想フォームファクタ。

• Linux KVM（.qcow2）

  3つのLinux KVM仮想マシンを使用してNexusダッシュボードクラスタを展開できる仮想フォームファクタ。

• Amazon Web Services (.ami)

  3つのAWSインスタンスを使用してNexusダッシュボードクラスタを展開できるクラウドフォームファクタ。

• Microsoft Azure (.arm)

  3 つの Azure インスタンスを使用して Nexus ダッシュボード クラスタを展開できるクラウド フォーム ファクタ。

• 既存のRed Hat Enterprise Linux(RHEL)システムの場合

  リリース2.2(1)以降、既存のRed Hat Enterprise LinuxサーバーでNexus Dashboardノードを実行できます。

以前のバージョンの Nexus ダッシュボードからのアップグレード

すでに Nexus ダッシュボード リリース 2.0.1 以降を実行している場合は、Nexus ダッシュボードのアップグレードの説明に従って、クラスタ設定とアプリケーションを保持したまま、最新リリースに直接アップグレードできます。

Application Services Engineからのアップグレード

Cisco Application Services Engine を実行している場合は、Nexus ダッシュボード リリース 2.1(x) 以降にアップグレードする前に、Cisco Nexus ダッシュボード展開ガイド、リリース 2.0(x)の説明に従って、Nexus ダッシュボード リリース 2.0(2g) にアップグレードする必要があります。

クラスタのサイジングと可用性の注意事項

前述のように、各 Nexus ダッシュボード クラスターは、最初に 1 つまたは 3 つのマスター ノードを使用してデプロイされます。実行するサービスの種類と数によっては、クラスタに追加のワーカーノードを展開することが必要な場合があります。クラスタのサイジング情報と、特定の使用例に基づく推奨ノード数については、 『Cisco Nexus Dashboard Cluster Sizing』を参照してください。

（注）

単一ノード クラスタは、限られた数のサービスでサポートされており、最初の展開後に 3 ノード クラスタに拡張することはできません。 追加のワーカー ノードをサポートするのは 3 ノード クラスタのみです。 単一ノード クラスターをデプロイし、それを 3 ノード クラスターに拡張するか、ワーカー ノードを追加する場合は、基本の 3 ノード クラスターとして再デプロイする必要があります。 3 ノード クラスタの場合、クラスタが動作し続けるには、少なくとも 2 つのマスター ノードが必要です。2 つのマスター ノードに障害が発生した場合、クラスタはオフラインの読み取り専用モードになり、回復するまで使用できません。その点は Cisco Nexus ダッシュボード ユーザー ガイドで説明されています。

最初のクラスタが稼働したら、Cisco Nexus ダッシュボード ユーザー ガイドの説明に従って追加ノードを設定して展開できます。このガイドは、Nexus ダッシュボード GUI から直接利用することもできます。

サポートされるサービス

サポートされるアプリケーションと関連する互換性および相互運用性情報の完全なリストについては、『Nexus ダッシュボードおよびサービスの互換性マトリクス』を参照してください。

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

Nexus ダッシュボード ノードでの展開とアップグレードには、常に、有効な DNS サーバーと NTP サーバーが必要です。

有効な DNS 接続がない場合（到達不能またはプレースホルダ IP アドレスを使用している場合など）、システムを正常に展開またはアップグレードできない可能性があります。

（注）	Nexus Dashboard は、DNS クライアントとリゾルバーの両方として機能します。内部サービス向けには、DNS リゾルバーとして機能する内部の Core DNS サーバーを使用します。また、DNS クライアントとしても動作して、イントラネット内またはインターネットの外部ホストに到達できるようにするためには、外部 DNS サーバーを構成する必要があります。 加えて、Nexus Dashboard は、ワイルドカード レコードを持つ DNS サーバーをサポートしていません。

Nexus ダッシュボード外部ネットワーク

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

Nexus ダッシュボードにインストールされた個々のサービスは、追加の目的で 2 つのネットワークを使用する場合があるため、展開計画については、このドキュメントに加えて特定のサービスのドキュメントを参照することを推奨します。

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

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

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

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

• Nexus ダッシュボード Insights サービスの場合、データ ネットワークは、各ファブリックおよび APIC のインバンド ネットワークに IP 到達可能性を提供する必要があります。

• Nexus Dashboard InsightsとAppDynamicsの統合では、データネットワークがAppDynamicsコントローラにIP到達可能性を提供する必要があります。

• Nexus Dashboard Orchestrator サービスの場合、データネットワークは、Cisco APIC サイトに対してインバンドおよび/またはアウトオブバンド IP 到達可能性を持ちますが、Cisco DCNMサイトに対してはインバンド到達可能性が必要です。

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

  必要に応じて、高いMTUを設定できます。

• 次の表は、管理ネットワークとデータネットワークのサービス固有の要件をまとめたものです。

  （注）	データサブネットを変更するにはクラスタを再展開する必要があるため、今後の追加サービスを考慮して、ノードとサービスの必要最低限よりも大きなサブネットを使用することをお勧めします。このセクションに記載されている要件に加えて、展開を計画している特定のサービスのリリースノートを参照してください。

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

  永続的な IP 構成に関連する追加の要件と警告については、特定のサービスのドキュメントを参照することをお勧めします。

  表 2. サービス固有のネットワーク要件

  Nexus Dashboard サービス	管理インターフェイス	データ インターフェイス	永続的 IP の総数
  Nexus Dashboard Orchestrator	レイヤ 3 隣接	レイヤ 3 隣接	なし
  SFLOW/NetFlow のない Nexus Dashboard Insights（ACI ファブリック）	レイヤ 3 隣接	レイヤ 3 隣接	なし
  SFLOW/NetFlow（NDFC/DCNMファブリック）のない Nexus Dashboard Insights	レイヤ 3 隣接	レイヤ 2 隣接	IPv4 を使用している場合、データ インターフェイス ネットワーク内の 6 つの IP IPv6 を使用している場合、データ インターフェイス ネットワーク内の 7 つの IP
  SFLOW/NetFlow（ACI または NDFC/DCNMファブリック）を使用した Nexus ダッシュボード Insights	レイヤ 3 隣接	レイヤ 2 隣接	データ インターフェイス ネットワーク内の 6 つの IP
  Nexus ダッシュボード ファブリック コントローラ、リリース 12.0.x	レイヤ 2 隣接	レイヤ 2 隣接	[LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [管理（Management）]（デフォルト） に設定されている場合： SNMP/Syslog および SCP サービス用の管理ネットワーク内の 2 つの IP [EPL] が有効になっている場合、各ファブリックのデータネットワークに 1 つの追加 IP [メディア用の IP ファブリック（IP Fabric for Media）] が有効になっている場合、テレメトリ用の管理ネットワークに 1 つの追加の IP [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [データ（Data）] に設定されている場合： SNMP/Syslog および SCP サービス用のデータネットワーク内の 2 つの IP [EPL] が有効になっている場合、各ファブリックのデータネットワークに 1 つの追加 IP [メディア用の IP ファブリック（IP Fabric for Media）] が有効になっている場合、テレメトリ用のデータネットワークに 1 つの追加の IP
  Nexus ダッシュボード ファブリック コントローラ、リリース 12.1.1 以降	レイヤ 2 またはレイヤ 3 隣接	レイヤ 2 またはレイヤ 3 隣接	LAN 展開タイプで [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [管理（Management）]（デフォルト）に設定されたレイヤー 2 モードで動作している場合 SNMP/Syslog および SCP サービス用の管理ネットワーク内の 2 つの IP [EPL] が有効になっている場合、各ファブリックのデータネットワークに 1 つの追加 IP [メディア用の IP ファブリック（IP Fabric for Media）] が有効になっている場合、テレメトリ用の管理ネットワークに 1 つの追加の IP LAN 展開タイプで [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [データ（Data）]（デフォルト）に設定されたレイヤー 2 モードで動作している場合 SNMP/Syslog および SCP サービス用のデータネットワーク内の 2 つの IP [EPL] が有効になっている場合、各ファブリックのデータネットワークに 1 つの追加 IP [メディア用の IP ファブリック（IP Fabric for Media）] が有効になっている場合、テレメトリ用のデータネットワークに 1 つの追加の IP LAN 展開タイプのレイヤ 3 モードで動作している場合： [LAN デバイス管理の接続性（LAN Device Management Connectivity）] が [データ（Data）] に設定されている必要があります SNMP/Syslog および SCP サービス用の 2 つの IP [EPL] が有効になっている場合、各ファブリックのデータネットワークに 1 つの追加 IP すべての永続的 IP は、管理サブネットまたはデータサブネットと重複していない別のプールの一部である必要があります。 永続的 IP のレイヤ 3 モードの詳細については、ユーザーガイドの「永続的 IP」のセクションを参照してください。 SAN コントローラ展開タイプのレイヤ 3 モードで動作している場合： SSH 用の 1 つの IP SNMP/Syslog 用の 1 つの IP SAN Insights 機能用の 1 つの IP メディア モードの IP ファブリックは、レイヤ 3 モードではサポートされていません。
  Cisco Nexus Dashboard Data Broker	レイヤ 3 隣接	なし	なし

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

  （注）	Nexus ダッシュボード クラスタとサービスを展開する場合は、常に最も低い RTT 要件を使用する必要があります。例えば、Insights とオーケストレータ サービスを共同ホストする場合、サイト接続性 RTT は 50ms を超えないようにします。

  。

  表 3. RTT 要件

  サービス	接続	最大 RTT
  Nexus Dashboardクラスタ	ノード間	150 ミリ秒
  Nexus Dashboard Orchestrator	ノード間	150 ミリ秒
  	サイトへ	APIC サイトの場合：500 ミリ秒 NDFC サイトの場合：150 ミリ秒
  Nexus Dashboard Insights	ノード間	50 ミリ秒
  	サイトへ	50 ミリ秒
  Nexusダッシュボード ファブリック コントローラ	ノード間	50 ミリ秒
  	サイトへ	50 ミリ秒
  Cisco Nexus Dashboard Data Broker	ノード間	150 ミリ秒
  	サイトへ	500 ミリ秒

Nexus ダッシュボードの内部ネットワーク

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

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

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

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

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

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

（注）

異なる Nexus ダッシュボード ノードに展開されたコンテナ間の通信は VXLAN でカプセル化され、送信元と宛先としてデータ インターフェイスの IP アドレスを使用します。これは、アプリケーション オーバーレイとサービス オーバーレイのアドレスがデータ ネットワークの外部に公開されることはなく、これらのサブネット上のトラフィックは内部でルーティングされ、クラスタノードから出ないことを意味します。 たとえば、オーバーレイ ネットワークの 1 つと同じサブネット上に別のサービス（DNS など）がある場合、そのサブネット上のトラフィックはクラスタの外部にルーティングされないため、Nexus ダッシュボードからそのサービスにアクセスできません。そのため、これらのネットワークは一意であり、クラスタの外部にある既存のネットワークまたはサービスと重複しないようにしてください。これらは Nexus ダッシュボード クラスタ ノードからアクセスする必要があります。 同じ理由で、アプリまたはサービスのサブネットには 169.254.0.0/16（Kubernetes br1 サブネット）を使用しないことをお勧めします。

BGP 構成と永続的な IP

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

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

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

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

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

• 以降のセクションで説明されているようにクラスタの展開時に BGP を有効にするか、『ユーザーガイド』の「永続的な IP アドレス」セクションで説明されているように Nexus ダッシュボード GUI で後で有効にするかを選択します。

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

Nexus Dashboard ポート

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

Nexus Dashboard Insights ポート

上記の Nexus Dashboard クラスタ ノードに必要なポートに加えて、Nexus Dashboard Insights サービスには次のポートが必要です。

Nexus Dashboard Fabric Controller ポート

Nexus Dashboard（ND）クラスタ ノードに必要なポートに加えて、Nexus Dashboard Fabric Controller（NDFC）サービスには次のポートが必要です。

（注）	次のポートは、NDFC サービスからスイッチへの IP 到達可能性を提供するインターフェイスに応じて、Nexus Dashboard 管理ネットワークおよび/またはデータ ネットワーク インターフェイスに適用されます。

（注）	次のポートは、一部の NDFC サービスで使用される永続的 IP とも呼ばれる外部サービス IP に適用されます。これらの外部サービス IP は、展開のタイプに応じて、特定のサブネット プールから取得される場合があります。 LAN 展開の場合、これらの外部サービス IP は、構成された設定に応じて、Nexus Dashboard の管理サブネット プールまたはデータ サブネット プールから取得される場合があります。 SAN 展開の場合、これらの外部サービス IP は Nexus Dashboard データ サブネット プールから取得されます。

SAN 展開向けの Nexus Dashboard Fabric Controller ポート

Nexus Dashboard Fabric Controller は、単一ノードまたは 3 ノードの Nexus Dashboard クラスタに導入できます。単一ノード クラスタでの NDFC SAN 展開には、次のポートが必要です。

（注）	次のポートは、一部の NDFC サービスで使用される、永続的 IP とも呼ばれる外部サービス IP に適用されます。これらの外部サービス IP は、構成された設定に応じて、Nexus Dashboard の管理サブネット プールまたはデータ サブネット プールから取得される場合があります。

ここでは、Nexus ダッシュボード クラスタをファブリックに接続する方法について説明します。

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

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

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

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

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

仮想またはクラウド フォーム ファクタ クラスタを展開する場合は、このセクションをスキップできます。

次の図に、Nexus Dashboard の物理ノード インターフェイスを示します。

• eth1-1 および eth1-2 は管理ネットワークに接続する必要があります。

• eth2-1 および eth2-2 はデータ ネットワークに接続する必要があります。

インターフェイスは、アクティブ/スタンバイ モードで実行されている、データインターフェイス用と管理インターフェイス用の Linux ボンドとして設定されます。すべてのインターフェイスは個々のホストポートに接続する必要があります。PortChannelおよびvPCはサポートされていません。

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

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

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

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

• Cisco NDFC ファブリックを管理するために Nexus Dashboard Orchestrator を展開する場合は、データインターフェイスから各サイトの NDFC のインバンドインターフェイスへの接続を確立する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

  ACIファブリックの場合、データインターフェイスIPサブネットはファブリック内のEPG / BDに接続し、管理テナントのローカルインバンドEPGに対して確立されたコントラクトが必要です。Nexusダッシュボードは、管理テナントおよびインバンド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ダッシュボードクラスタをファブリックのリーフスイッチに直接接続する場合の2つの異なるネットワーク接続シナリオを示しています。それぞれの主な目的は、Nexusダッシュボードで実行しているアプリケーションのタイプによって異なります。

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

Nexus Dashboard インサイトのノード配布

Nexus ダッシュボード Insights サービスには、一元化された単一サイトの展開をお勧めします。このサービスは、ノードが異なるサイトにある場合に、クラスタを相互接続障害にさらす可能性がある分散クラスタの冗長性の利点を得ることができません。

Nexus Dashboard オーケストレータ およびファブリック コントローラのノード配布

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

（注）	次の図は、NDO または NDFC サービスを使用した物理または仮想 Nexus ダッシュボード クラスタの可能な展開シナリオのいくつかの例を示しています。特定のユース ケースに必要なノード数の詳細については、Nexus ダッシュボード キャパシティ プランニング ツールを参照してください。

次の表に、複数のサイトにまたがる物理的な Nexus ダッシュボード マスター（M1、M2、M3) およびスタンバイ（ S1）ノードの分散でサポートされる追加のシナリオをまとめます。

単一サイト、Nexus ダッシュボード Insights およびオーケストレータ

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

Nexus ダッシュボード Insights およびオーケストレータの複数サイト、単一クラスタ

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

Nexus ダッシュボード Insights およびオーケストレータの複数のサイト、複数のクラスタ

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