ここでは、デプロイメントタイプに関係ない Nexus Dashboard クラスターの要件とガイドラインについて説明します。

全般的な展開のガイドラインと制限

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

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

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

  サポートする構成。スタンバイ ノードを使用せずにこのクラスターを再展開します。クラスター内のノードの 1 つで障害が発生した場合は、新しいノードを再インストールして、次に移動します： Admin > System Status > Nodes、その後に次をクリックします。 Actions > Re-Register をクリックして、再インストールしたノードをクラスターに追加し直します。

• リモートストレージでの仮想 Nexus Dashboard VM の展開はサポートされていないため、予期しない動作が発生する可能性があります。

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

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

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

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

DNS については次のガイドラインが適用されます。

• 外部 DNS サーバーの場合、 TCPと UDP トラフィックの両方を許可する必要があります。参照先： LAN 展開用の通信ポート および SAN 展開用の通信ポート 」を参照してください。

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

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

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

• キー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 で特定のキーを簡単に無効にすることができます。

• 一部の NTP サーバーには Preferred として Nexus Dashboard でタグを付けることができます。

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

• 以下を実行するNTPサーバーを使用している場合： ntpdのバージョン 4.2.8p12 以降をお勧めします。

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

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

  • 20 文字未満のキーには、任意の ASCII 文字を含めることができますが、#、' とスペースは使用できません。長さが 20 文字を超えるキーは、16 進形式である必要があります。

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

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

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

IPv4 および IPv6 のサポート

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

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

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

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

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

  • データ、管理、アプリ、およびサービス ネットワークはデュアル スタック モードである必要があります。

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

  • IPv6 ベースの Nexus Dashboard の展開では、すべての物理サーバーの CIMC にも IPv6 アドレスが必要です。

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

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

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

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

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

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

  • GUI は、構成されている限り、IPv4 と IPv6 の両方の管理ネットワーク アドレスでアクセスできます。

• 純粋な IPv6 構成の場合：

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

    AWS パブリック クラウドでの vNDデプロイメント プロセスを介して展開されたクラスタは、純粋な IPv6 またはデュアル スタック モードをサポートしません。

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

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

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

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

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

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

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

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

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

特定の接続に必要な URL

これらの接続に必要な、Nexus Dashboard が到達する必要がある特定の URL があります。

• Cisco Intersight： Nexus DashboardクラスターをCisco Intersightに接続すると、次の利点があります。

  • メタデータの自動更新（特定の機能で、更新されたデータを提供するために使用できる）

  • TAC ログの収集とアップロード

• スマート ライセンスへの接続

• 電力マップからのエネルギー管理統計の取得

次に、 Nexus Dashboard がこれらの接続で到達する必要がある URL と、その理由を示します。

次のネットワークの前提条件が LAN の導入に適用されます：

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

• データ ネットワークと管理ネットワークの両方のインターフェイスは、レイヤ 2 またはレイヤ 3 隣接のいずれかにすることができます。データ ネットワークのレイヤ 3 隣接関係については、ブートストラップ プロセス中に BGP を構成する必要があります。管理ネットワーク インターフェイスは、BGPプロトコルをサポートしていません。異なるサブネット内の管理アドレスを使用して異なるNexus Dashboard ノードを展開する場合、それらは単に相互にルーティングされます。

• 永続的なデータIPアドレスを使用してクラスターを起動する必要があるため、設定に応じて特定の数の永続 IP アドレスを割り当てる必要があります。

  • クラスターに 1 つのノードがある場合は、3 つの永続 IP アドレスを割り当てます。

  • クラスターに 3 つ以上のノードがある場合は、永続 IP アドレスを 5 つ割り当てます。

  • デュアルスタックIPv4 および IPv6 を設定する場合は、IPv6 に同じ数の永続 IP アドレスを追加します（つまり、デュアル スタックを設定する場合は、5 つの IPv4 と 5 つの IPv6 の永続的IPアドレス）。

  永続 IP アドレスの詳細については、次を参照してください： Nexus Dashboardの 永続 IP アドレス。ブートストラップ プロセス中に、必要最小限の永続 IP アドレスを割り当てる必要があります。追加の永続 IP アドレスの割り当ては、クラスタの展開後に GUI の外部サービス プール設定を使用して行うことができます。

• ポッド プロファイル ポリシーは、展開するノードの数に基づいて動的に設定されます。

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

次の表に、LAN 展開用の管理ネットワーク通信ポートを示します。 方向 列：

• 入力 はクラスター向けを意味し、

• 発信 ：クラスタからファブリックまたは外界を意味します。

次の表に、LAN 展開用のデータ ネットワーク通信ポートを示します。 方向 列：

• 入力 はクラスター向けを意味し、

• 発信 ：クラスタからファブリックまたは外界を意味します。

SAN 展開には、次のネットワークの前提条件が適用されます。

• データ ネットワークに同じサブネットを使用して、 Nexus Dashboard に SAN ファブリックを展開できます。

• データ ネットワークと管理ネットワークの両方のインターフェイスは、レイヤ 2 またはレイヤ 3 隣接のいずれかにすることができます。データ ネットワークのレイヤ 3 隣接関係については、ブートストラップ プロセス中に BGP を構成する必要があります。BGP は管理ネットワークのレイヤ 3 隣接関係をサポートしません。

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

  • クラスターに 1 つのノードがある場合は、2 つの永続 IP アドレスを割り当てます。SAN Insights を使用する場合は、合計 3 つの永続 IP アドレスを割り当てます。

  • クラスターに 3 つのノードがある場合は、2 つの永続 IP アドレスを割り当てます。SAN Insights を使用する場合は、合計 5 つの永続 IP アドレスを割り当てます。

  永続 IP アドレスの詳細については、次を参照してください： Nexus Dashboardの 永続 IP アドレス。ブートストラップ プロセス中に、必要最小限の永続 IP アドレスを割り当てる必要があります。追加の永続 IP アドレスの割り当ては、クラスタの展開後に GUI の外部サービス プール設定を使用して行うことができます。

  管理インターフェイスは同じサブネット内に存在する必要があります。

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

次の表に、 SAN 展開での管理ネットワーク通信ポートを示します。

次の表に、 SAN 展開での管理ネットワーク通信ポートの一覧を示します。

次の表に、シングルノード クラスタでの Nexus Dashboard SAN 展開に必要なポートを示します。

永続 IP アドレス（外部サービス IP アドレスとも呼ばれる）は、Nexus ダッシュボード クラスター内のさまざまなコントローラおよびテレメトリ機能に使用される IP アドレスです。「永続」という用語が使用されるのは、ノードまたはポッドに障害が発生した場合にサービスが異なる Nexus Dashboard ノード間を移動する可能性があるものの、ファブリック内のスイッチによって参照されるサービスの IP アドレスが保持されるためです。これにより、 Nexus ダッシュボード関連の障害イベントが発生した場合にスイッチの設定更新が不要になります。永続 IP アドレスは、展開される機能に応じて、管理サブネットとデータ サブネットの両方でプログラムできます。

リリース 4.1.1 での永続 IP アドレスの更新

このセクションでは、永続 IP アドレスの Nexus Dashboard リリース 4.1.1 での変更に関する情報を提供します。また、Nexus Dashboard リリース 4.1.1 へのアップグレードに進む前に、永続的な IP アドレスを特定の数に更新する方法についても説明します。

• 必要な IP アドレス数の削減

  リリース 4.1.1 以降、以前の Nexus Dashboard リリースで排他的 IP アドレスが必要であった一部のサービスが他のサービスにマージされました。たとえば、 Nexus ダッシュボード ノードごとに、データ ネットワーク上のソフトウェア テレメトリ、フロー テレメトリ、および IPFM テレメトリ コレクタがマージされ、コレクタ サービスごとに 1 つの IP アドレスで 3 つの機能をすべて果たすようになりました。

• LAN デバイスの接続性

  LAN デバイス接続のタイプ（データまたは管理）は、[管理（Administration）] > [システム設定（System Settings）] > [ファブリック管理（Fabric management）] > [詳細設定（Advanced settings）] > [管理（Administration）] > [LAN デバイス管理の接続性（LAN Device Management Connectivity）] で設定できます。

  リリース 4.1.1 より前のリリースでは、LAN デバイス接続のデフォルト設定は [管理（Management）] でした。リリース 4.1.1 以降、このデフォルトは [データ（Data）] に変更されました。ただし、 Nexus Dashboard リリース 3.2.x から 4.1.1 にアップグレードする場合、LAN デバイス接続のユーザー設定は保持されます。

• テレメトリのためのレイヤ 3 永続 IP サポート

  Nexus Dashboard リリース 4.1.1 以降、テレメトリコレクタ X の永続 IP は、レイヤ 3 隣接 Nexus Dashboard クラスタでサポートされます。レイヤ 3 BGP のデプロイメントの詳細については、以下を参照してください。

Nexus Dashboard リリース 4.1.1 では、永続 IP アドレスの数とサービスへのマッピング方法が変更されました。次のサービスは、 Nexus Dashboard の永続 IP アドレスを使用します。

• テレメトリ コレクタ x：データ ネットワークでは、1 ノード クラスターの場合は 1 つの永続 IP アドレス、3 ノード以上のクラスターの場合は 3 つの永続 IP アドレスが必要です。

• SNMP トラップおよび syslog 受信者：LAN デバイスの接続タイプがデータに設定されている場合はデータ ネットワーク上の 1 つの永続 IP アドレス、LAN デバイスの接続タイプが管理に設定されている場合は管理ネットワーク上の 1 つの永続 IP アドレス。

• スイッチ ブートストラップ サービス（POAP/ PnP ）：LAN デバイスの接続タイプがデータに設定されている場合はデータ ネットワーク上の 1 つの永続 IP アドレス、LAN デバイスの接続タイプが管理に設定されている場合は管理ネットワーク上の 1 つの永続 IP アドレス。

• （オプション）エンドポイント ロケータ（EPL）：EPL が有効になっている各ファブリックのデータ ネットワーク上の 1 つの永続 IP アドレス。EPL 機能は、特定の Nexus ダッシュボードクラスターで最大 4 つのファブリックに対して有効にできます。

• （オプション）IPFM（メディア用の IP ファブリック） テレメトリ コレクタ x：LAN デバイスの接続がデータに設定されている場合、追加の永続的な IP は必要ありません。ただし、LAN デバイスの接続タイプが管理に設定されている場合、管理ネットワークには、1ノードクラスターの場合は 1 つの永続 IP アドレス、3 ノード以上のクラスターの場合は 3 つの永続 IP アドレスが必要です。

IPv4 のみの Nexus Dashboard クラスター デプロイメントの場合、上記の各サービスは 1 つの永続 IPv4 アドレスを消費します。純粋な IPv6 のみの Nexus Dashboard クラスター デプロイメントの場合、各サービスは1つの永続 IPv6アドレスを消費します。デュアルスタック Nexus Dashboard クラスター デプロイメントの場合、永続 IP が必要な各サービスが 1 つの IPv4 アドレスと 1 つの IPv6 アドレスを消費します。

新規インストールまたはアップグレード

必要な永続 IP アドレスの総数は、必ずしも新規インストールまたはアップグレードを実行しているかどうかに基づいて必ずしも変更されるわけではありません。さらに、 Nexus Dashboard の新規インストール（グリーンフィールド デプロイメント）の場合、データ ネットワークでのみ永続 IP アドレスを設定する必要があります。クラスターのインストールが完了した後、LAN デバイスの接続タイプをデータから管理に変更できます。

前述のように、以前の Nexus Dashboard リリースと比較して、 Nexus Dashboard 4.1.1 のデフォルト設定に変更があります。Nexus Dashboard 4.1.1 では、デフォルトのLAN デバイス管理の接続性はデータに設定されています。以前のリリースでは管理に設定されていました。統合された Nexus Dashboard の提供に向けた取り組みの一環として、目標は、推奨されるベストプラクティスのデプロイメントをできるだけ簡単にすることです。Nexus Dashboard からスイッチへの到達可能性は、Nexus Dashboard データ インターフェイスを介して行うことを推奨します。Nexus Dashboard 管理インターフェイスは、主に UI/ APIアクセス、およびAAA、DNS、プロキシ、 NTP 、Intersight などの到達可能性のために使用されます。最後に、 Nexus Dashboard リリース 3.2.x からNexus Dashboard リリース 4.1.1 へのインライン アップグレードを実行すると、ユーザーが設定した接続設定が保持されることに注意してください。

留意すべきその他の考慮事項

上記の要因に加えて、永続 IP アドレスに関して留意すべきいくつかの追加の考慮事項があります。

• Nexus Dashboard の展開モード:

  • レイヤ 2：ここでは、クラスター内の Nexus Dashboard ノードはレイヤ 2 隣接です。これは、すべての Nexus Dashboard ノードがそれぞれ同じ管理サブネットとデータ サブネットを共有することを意味します。永続 IP アドレスは、データネットワークまたは管理ネットワークと同じネットワーク上にある必要があります。

  • レイヤ3 BGP : このモードでは、クラスター内の Nexus Dashboard ノードはレイヤ 3 隣接です。つまり、クラスター内の各 Nexus Dashboard ノードに、一意の管理サブネットとデータ サブネットが関連付けられます。クラスターを形成するには、ノード間に IP 到達可能性がある必要があります。永続 IP アドレスは、 Nexus Dashboard ノードのデータまたは管理インターフェイス サブネットのいずれかに属するサブネットから取得することはできません。この場合、LAN デバイス管理の接続性はデータに設定する必要があり、変更できません。

必要な永続 IP アドレスの合計数の決定

必要な永続 IP アドレスの合計数とその取得元のネットワークを決定しようとする際には、上記のすべての要因が考慮されます。最終的な Nexus Dashboard 展開構成を確認して、十分な数の永続 IP アドレスがデプロイメントのための適切なサブネット範囲にあることを確かめてください。また、必要に応じ、追加の永続 IP アドレスがあることも確かめてください。これは、設定した LAN デバイスの接続性のタイプと、エンドポイント ロケータ（EPL）など、有効にする可能性のあるサービスに応じて決まります。

次に、永続 IP アドレスがどのように使用されるかを示すシナリオの例を示します。

新規インストール

まず、クラスターの起動時に、前述のように、クラスターのサイズに基づいて、データネットワーク上に特定の数の永続 IP アドレスが必要になります。

• 物理または仮想ノードを含む 1 ノード クラスター：最小 3 データ ネットワークで必要な永続 IP アドレス

• 物理または仮想ノードを使用した 3 ノード以上のクラスター：最小 5 データ ネットワークで必要な永続 IP アドレス

ブートストラップ後、次のシナリオに応じて、必要に応じて永続 IP アドレスを追加する必要がある場合があります。

• LAN デバイスの接続タイプを データに設定したの場合、エンドポイント ロケータ（EPL）機能を有効にしない限り、追加の永続 IP アドレスは必要ありません。この機能では、EPL が有効になっているファブリックごとにデータ ネットワーク上で 1 つの追加の永続 IP アドレスが必要です。

• LAN デバイスの接続タイプを次から変更した場合： データ ～ Management:

  • Syslog/ SNMP トラップおよびスイッチのブートストラップ機能のために、管理ネットワーク上に 2 つの追加の永続 IP アドレスが必要です。

  • （オプション）エンドポイント ロケータ（EPL）を有効にする場合は、EPL が有効になっているファブリックごとにデータ ネットワーク上に 1 つの永続 IP アドレスが必要です。

  • （オプション）IP Fabric for Media（IPFM）ファブリックが必要な場合は、管理ネットワーク上に 1 ノードクラスターの場合は 1 つの永続 IP アドレス、3 ノード以上のクラスターの場合は 3 つの永続 IP アドレスが必要です。

アップグレード：

ここで、 Nexus Dashboard 3.2.x から 4.1.1 にアップグレードするとします。Nexus Dashboard 4.1.1 で必要な永続 IP アドレスの数は、実行していたサービスと Nexus Dashboard 3.2.x でのサービスの設定方法、および Nexus Dashboard 4.1 でのクラスターのサイズによって異なります。 1. Nexus Dashboard 3.2.x リリースで設定した LAN デバイス管理の接続性は、 Nexus Dashboard 4.1.1 リリースへのインライン アップグレードを実行するときはそのまま保持されることに注意してください。

• ユーザーが NDFC だけを Nexus Dashboard 3.2.xシステムで実行しており、

  • ユーザーが データ を Nexus Dashboard 3.2.x の LAN デバイス接続のタイプとして設定していて、

    • Nexus Dashboard 4.1.1 にアップグレードする 1 ノード クラスターがある場合、データ ネットワーク上に 3 つの永続 IP アドレスが必要です。

    • Nexus Dashboard 4.1.1 にアップグレードする 3 ノード以上のクラスターがある場合、データ ネットワーク上に 5 つの永続 IP アドレスが必要です。

  • ユーザーが Management を Nexus Dashboard 3.2.x の LAN デバイス接続のタイプとして設定していて、

    • Nexus Dashboard 4.1.1 にアップグレードする 1ノードクラスターがある場合、管理ネットワークにはすでに 2 または 3 つの永続 IP アドレスがあるはずです（IPFM / PTP 機能が有効になっている場合は追加の IP が必要です）。さらに、データ ネットワークに 1 つの永続 IP アドレスが必要です。そうでないと、4.1.1 へのアップグレードはアップグレード前の検証手順中に失敗します。

    • Nexus Dashboard 4.1.1 にアップグレードする3ノード以上のクラスターがある場合、管理ネットワークにはすでに 2 つまたは 5 つの永続 IP アドレスがあるはずです（IPFM / PTP機能が有効になっている場合は、3つの追加のIPが必要です）。データ ネットワークに次の 3 つの永続 IP アドレスを設定する必要があります。そうして初めて、4.1.1 へのアップグレードを続行できます。

• ユーザーが NDI だけを Nexus Dashboard 3.2.xシステムで実行しており、

  • Nexus Dashboard 4.1.1 にアップグレードする 1ノードクラスターがある場合、データ ネットワークにはすでに 4 つの永続 IP アドレスが設定されているはずです。4.1.1 へのアップグレード後には、3 つの永続 IP アドレスのみが使用されます。残りは再利用できます。

  • Nexus Dashboard 4.1.1 にアップグレードする 3 ノード以上のクラスターがある場合、スタンドアロン NX- OS デプロイメントをサポートするための 2 つの追加データ IP と、データ ネットワークの 8 つの永続 IP アドレスがすでに設定されているはずです。4.1.1 へのアップグレード後には、これらのデータ IP アドレスのうち 5 つだけが使用されます。残りは再利用できます。

• ユーザーが NDO だけを Nexus Dashboard 3.2.xシステムで実行している場合、 Nexus Dashboard 3.2.xシステムに永続 IP アドレスはありません。Nexus Dashboard 4.1.1 にアップグレードする際、 Nexus Dashboard 4.1.1 にアップグレードする 3ノードクラスターがある場合、アップグレードを続行するには、データ ネットワーク上に 5 つの永続 IP アドレスが必要です。

• ユーザーが NDO および NDI を Nexus Dashboard 3.2.x システムでデプロイメントモードにし、 Nexus Dashboard 4.1.1 にアップグレードする 3ノード以上のクラスターがある場合、データネットワークにはすでに 8 つの永続 IP アドレスが設定されているはずです。4.1.1 へのアップグレード後は、これらのデータ永続 IPアドレスのうち 5 つだけが使用されます。残りの永続 IP アドレスは再利用できます。

• ユーザーが NDFC および NDI だけを Nexus Dashboard 3.2.x システムでデプロイメント モードに設定していて、 Nexus Dashboard 4.1.1 にアップグレードする 3 ノード以上の物理 ND クラスターがある場合、LAN デバイス管理接続の設定に基づく次の 2 つのオプションがあります。

  • ユーザーが Management を Nexus Dashboard 3.2.x の LAN デバイス接続のタイプとして設定していた場合、すでに NDI のデータ ネットワークに 8 つの永続 IP アドレス、NDFC の管理ネットワークに 2 つの永続 IP アドレスが設定されています。4.1.1 へのアップグレード後、管理サブネットの永続 IP アドレスは 2 つ使用され、データ永続的 IP アドレスは 3 つだけ使用されます。残りの永続 IP アドレスは再利用できます。

  • ユーザーが データ を Nexus Dashboard 3.2.x の LAN デバイス接続のタイプとして設定していた場合、すでに NDI のデータ ネットワークに 8 つの永続 IP アドレス、NDFC に追加で 2 つの永続 IP アドレスが設定されています。4.1.1 へのアップグレード後は、これらのデータ永続 IPアドレスのうち 5 つだけが使用されます。残りの永続 IP アドレスは再利用できます。

（注）	EPL の永続 IP アドレスの要件は、リリース 4.1.1 でも リリース 3.2.x と同じです。

両方のネットワークでノード間の接続が必要です。そして、表示に示されているラウンド トリップ時間（RTT）要件があります。

ここでは、Nexus Dashboard クラスタ ノードを管理とデータ ネットワークに接続し、クラスタをファブリックに接続する方法について説明します。インバンドテレメトリ機能を有効にするためのファブリックの構成の詳細については、次のドキュメントを参照してください。

• Cisco ACI ファブリックの Cisco Nexus Dashboard Insights の準備

• Nexus Dashboard Insights を使用できるように NDFC ネットワーク サイトを準備する

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

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

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

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

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

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

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

• テレメトリを使用する場合は、データ インターフェイスから各ファブリックおよび APIC のインバンド ネットワークへの接続を確立する必要があります。

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

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

  ACI ファブリックでの外部接続の設定については、次を参照してください： Cisco APIC Layer 3 ネットワーキング設定ガイド。

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

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

次の 2 つの図は、Nexus Dashboard クラスタをレイヤ 3 ネットワーク経由でファブリックに接続する場合の 2 つの異なるネットワーク接続シナリオを示しています。最初の図は ACI と NX-OS ファブリック混在、2 番目の図は ACI ファブリックのみの場合です。

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

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

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

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

• テレメトリを使用する場合は、データ インターフェイスから各ファブリックの APIC のインバンドまたはアウトオブバンド（OOB）インターフェイスへの接続を確立できます。ただし、データインターフェイスからアウトオブバンド インターフェイスへの接続を確立する場合は、ルートを追加する必要があります。

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

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

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

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

  ただし、一般的には VLAN をデータネットワークに割り当てないことを推奨します。この場合、ポートを アクセス モードで使用します。

• APIC 側の設定では、以下の推奨設定があります。

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

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

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

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

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

次の図は、これらのタイプの接続を示しています。

• ACI ファブリックに直接接続

• NX- OS ファブリックに直接接続

• ACI および NX- OS ファブリックに直接接続