既存の Nexus Dashbaord クラスターをアップグレードするための前提条件と注意事項
既存のNexusダッシュボードクラスタをアップグレードする前に、次の手順を実行します。
-
アップグレードに影響する可能性のある動作、ガイドライン、および問題の変更については、ターゲット リリースのリリース ノートを必ずお読みください。
-
Nexus Dashboard リリース 4.1.1 にアップグレードする前に、次の手順を実行します。
-
NTPとDNS サービスが設定されていることを確認します。システムを正常にアップグレードするには、少なくとも 1 つの NTP と DNS が必要です。
-
管理ネットワークとデータ ネットワークが異なるサブネットに存在することを確認する必要があります。管理ネットワークとデータ ネットワークが異なるサブネットに存在する場合にアップグレードは失敗します。
-
-
acs クラスタが健全であることを検証します。-
ssh -l rescue-user [management-ip-of-nd] を使用してNexusダッシュボードにアクセスします。 -
acs healthコマンドを発行します。
acs healthコマンドからの出力には、すべてのコンポーネントが正常であることが表示されるはずです。rescue-user@node1:~$ acs health ====== Status ====== All components are healthy -
-
アップグレードする前に Nexus Dashboard クラスターのバックアップを実行し、バックアップ ファイルを安全な場所に保存してください。バックアップを実行するためには、「Nexus Dashboard とサービスの統合バックアップおよび復元」 を参照してください。このバックアップを、4.1.1 リリースを実行している Nexus Dashboard クラスターに直接復元することはできないことに注意してください。
-
最新のバックアップに障害が発生していた場合、アップグレードは続行されません。アップグレードを進める前に、正常なバックアップがあることを確認してください。バックアップを正常に実行できず、アップグレードできない場合は、 Cisco Technical Assistance Center （TAC） （TAC） に連絡してサポートを受けてください。
-
NDI または NDFC のいずれかがあり、NDI がリモートで作成された NDFC クラスタのテレメトリを実行する場合、または複数の ND クラスタとのマルチクラスタ接続がある場合は、すべてのクラスタを Nexus Dashboard 4.1.1 にアップグレードする必要があります。マルチクラスタ接続を使用した Nexus Dashboard リリース 3.2x と 4.1.1 のクラスタの混在はサポートされていません。
-
物理的な Nexus Dashboard クラスタをアップグレードしている場合は、ノードにターゲットの Nexus Dashboard リリースでサポートされている最小の CIMC バージョンがあることを確認してください。
サポートされている CIMC バージョンは、ターゲット リリースの Nexus Dashboard リリース ノート にリストされています。
CIMC アップグレードについては、Nexus Dashboard ドキュメント ライブラリ の「トラブルシューティング」の記事で詳しく説明されています。
-
仮想 Nexus Dashboard クラスターをアップグレードする場合、 Nexus Dashboard は HDD の遅延のチェックを適用して、<30ms であることを確認します。HDD の遅延がさらに高い場合、アップグレードは失敗します。
-
VMware ESX に展開された仮想 Nexus Dashboard クラスタをアップグレードする場合は、ESX のバージョンがターゲット リリースで引き続きサポートされていることを確認します。
このリリースは、VMware ESXi 7.0、7.0.1、7.0.2、7.0.3、8.0、8.0.2、8.0.3 をサポートしています。
（注）
ESX サーバーをアップグレードする必要がある場合は、Nexus Dashboard をターゲット リリースにアップグレードする前に行う必要があります。ESX のアップグレードはこのドキュメントの範囲外ですが、簡単に説明すると次のとおりです。
-
既存の Nexus Dashboard ノード VM を実行している場合に通常行うように、ESX ホストの 1 つをアップグレードします。
-
ホストがアップグレードされた後、Nexus Dashboard クラスタが正常に動作していることを確認します。
-
他の ESX ホストで 1 つずつアップグレードを繰り返します。
-
すべての ESX ホストがアップグレードされ、既存の Nexus Dashboard クラスタが正常な状態になったら、このドキュメントの説明に従って、Nexus Dashboard をターゲット リリースにアップグレードします。
-
-
現在の Nexus ダッシュボードクラスタが正常であることを確認します。
Nexus ダッシュボードの管理コンソール（Admin Console）の [概要（Overview）] ページでシステムのステータスを確認するか、
rescue-userとしてノードの1つにログインし、acs healthコマンドを実行してAll components are healthyが返ってくることを確認します。 -
Nexus Dashboard ではプラットフォームのダウングレードはサポートされていません。
以前のリリースにダウングレードするには、新しいクラスタを展開する必要があります。
-
Nexus Dashboard リリース 3.2.1 で
ダッシュボード ユーザー（app-user）ユーザーロールのみを持っているユーザーがいる場合は、 Nexus Dashboard リリース 4.1.1 へのアップグレード後にダッシュボード ユーザーロールを持つユーザーで削除するか、Nexus Dashboard リリース 4.1.1 のユーザーの代わりにObserverロールを使用する必要があります。 -
永続 IP アドレスの数とそれらのマッピング方法は、以前のリリースから Nexus Dashboard リリース 4.1.1 で変更されました。Nexus Dashboardの 永続 IP アドレスを参照して、以前のリリースで必要だった永続的なIPアドレスの数と、 Nexus Dashboard リリース 4.1.1 にアップグレードする前に必要な永続的なIPアドレスの数で特定の更新を行う必要がある永続的な IP アドレスの数を理解してください。
-
サービスを提供する任意のペルソナ、特にNexus Dashboard Fabric Controller（NDFC）とNexus Dashboard Insights（NDI）のNexus Dashboard（NDI）があり、以前のリリース（ND 2.2.x 以下など）から ND 3.2.x にアップグレードしている場合、Elasticsearch（ES）インデックスサイズに関する次の重要な情報に注意してください。
クラスターが ND 2.2.x 以前に展開され、それ以降にアップグレードされた場合、ND 3.2.x から ND 4.1.1 へのアップグレードにより、時系列データベースのインデックスが作成されている可能性があります。このプロセスでは、サイズがこのクラスターの再インデックス化機能のサイズを超えている場合は、Cisco Technical Assistance Center （TAC） に連絡するように求められます。プロセスが再インデックス化できない場合、UI で提供された
acs recoverコマンドを使用して、失敗後にアップグレードを続行できます。 -
マルチクラスタ接続が構成されていて、 Nexus Dashboard リリース 3.2.x システムで NDFC と NDI が同じ場所に配置されており、
-
NDFC が 1 つのクラスターで実行されていて、
-
別のクラスターで NDI が実行されていた場合、
Nexus Dashboard リリース 4.1.1 へのアップグレードプロセスを開始する前に、クラスタを切断し、フェデレーションを削除することが必要です。これらの手順については、『 Nexus Dashboard Infrastructure Management』 の「Disconnecting Clusters」および「Deleting the Federation」の項を参照してください。アップグレードが完了したら、アップグレード後のタスクの一環としてマルチクラスタ接続を再度有効にします。
-
-
異なるデータ サブネットを持つ ND リリース 4.1.1 より前のクラスターの一部としてNexus Dashboard Orchestrator を使用している場合は、 Nexus Dashboard リリース 4.1.1 にアップグレードする前に、次の構成を行う必要があります。
-
すべてのノードで BGP 設定を追加します
-
永続 IP アドレスを追加します
アップグレード前にこれらの項目を設定していないと、アップグレード中のイメージの検証は失敗します。
-
アップグレード時の設定のばらつきの自動調整
4.2.(1) より前の NDO リリースから ND リリース 4.1.1 にアップグレードする場合は、マルチステップ アップグレードを実行する必要があります。
-
最初に 4.2(1) より前の NDO リリースを ND 3.0.1i にアップグレードしてから、『Cisco Nexus Dashboard and Services Deployment and Upgrade Guide, Release 3.2.x』の 「Supported Upgrade Paths」 の項の説明に従って、ND リリース 3.2.x に Cisco Nexus Dashboardします。。
-
次に、この章の説明に従って、ND リリース 3.2.x から ND リリース 4.1.1 にアップグレードします。
4.2(1) より前の NDO リリースを ND リリース 3.2.x にアップグレードすると、アプリケーション テンプレートの構成のばらつきが観察される場合があります。これらのばらつきは、NDO リリース 4.2(1) 以降で、以前のバージョンで管理されていなかった新しいアプリケーション テンプレート オブジェクト プロパティの管理がサポートされているために発生します。NDO 4.2(1) によって管理される新しいプロパティのリストについては、 Nexus Dashboard Orchestrator 4.2(1) リリース ノートを参照してください。
ND リリース 4.1.1 は、アップグレード プロセスの一環として構成のばらつきの自動調整をサポートしています。Nexus Dashboard は、テンプレートがファブリックと同期しているかどうかをチェックし、必要に応じて、ファブリック値を Nexus Dashboard にインポートして、ばらつきを自動的に解決します。
4.2(1) より前の NDO バージョンからマルチステップのアップグレードパスに従う場合は、ND リリース 3.2.x で検出されたばらつきを無視して、ND リリース 4.1.1 へのアップグレードを続行することをお勧めします。
ND リリース 4.1.1 へのアップグレード後に残ったばらつきは、手動で解決する必要があります。たとえば、構成されたオブジェクトが複数のファブリックにまたがる拡張テンプレートの一部であり、テンプレートレベルのプロパティに異なるファブリックで構成された異なる値がある場合、自動解決できないばらつきが発生します。
6 ノード pND クラスタから 3 ノード pND クラスタへの変換
Nexus Dashboard リリース 4.1.1 にアップグレードする前に、 Nexus Dashboard リリース 3.2.x で 6ノードpNDクラスターを 3ノードpNDクラスターに変換するには、次の手順を実行します。
-
Nexus Dashboard リリース 3.2.x で 6ノードpNDクラスターのバックアップを実行します。
詳細については、「Nexus Dashboard とサービスの統合バックアップと復元」の記事を参照してください。
-
既存のプライマリ ノードとクラスタが正常であることを確認し、1 つずつセカンダリ ノードを削除します。
-
リリース 3.2.x で実行されているNexus Dashboard で、 に移動します。
-
削除するセカンダリ ノードをオンにします。
-
[アクション（Actions）] メニューから [削除（Delete）] を選択してノードを削除します。
-
に移動し、各セカンダリノードが削除された後、クラスターの正常性ステータスが [GREEN] と表示されるまで待ちます。
（注）
ノードを削除後、Kafka が安定するまでに最大 30 分かかる場合があります。
-
セカンダリノードを削除した後にクラスターの正常性ステータスが GREEN と表示されたら、次のセカンダリノードの削除に進みます。
各セカンダリノードを1 つずつ削除するプロセスを続行し、クラスターのステータスが GREEN になるのを待ってから、次のセカンダリノードの削除に進みます。
-
-
すべてのセカンダリノードを削除したら、クラスターが正常であることを確認してから、 Nexus Dashboard リリース 3.2.x で新しいバックアップを実行します。
詳細については、「Nexus Dashboard とサービスの統合バックアップと復元」の記事を参照してください。
-
この章の手順に従って、クラスタを Nexus Dashboard リリース 3.2.x からリリース 4.1.1 にアップグレードします。
フィードバック