概要
このドキュメントでは、設定やデータベースのアップグレードが不要な場合、または新しいコードが同じソフトウェアトレインにある場合の3ノードvManageクラスタのプロセスについて説明します。
前提条件
- ソリューションがオンプレミスの場合にvManage管理者が取得したvManageノードごとに3つのVMのスナップショット、またはソリューションがシスコでホストされている場合にCisco CloudOpsチームが取得したスナップショット。
- request nms configuration-db backup path path/filenameコマンドを使用して、configuration-dbのバックアップを作成します
- configuration-dbバックアップファイルをvManageノードからコピーします。
使用するコンポーネント
- バージョン20.3.4の3ノードのvManageクラスタ。
- 20.3.4.1 vManageイメージ。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
背景説明
このドキュメントで説明するプロセスは、configuration-dbのアップグレードを必要としないアップグレードを指します。
各コードのリリースノートにある『Cisco vManage Upgrade Paths』ドキュメントを参照して、configuration-dbのアップグレードが必要かどうかを確認します。
注:Cisco vManageリリース18.4.x/19.2.xからCisco vManage 20.3.x/20.4.xに、またはCisco vManageリリース20.3.x/20.4.xからCisco vManageリリース20.5.x/20.6.xにアップグレードする場合は、configuration-dbをアップグレードする必要があります。『Cisco vManageクラスタのアップグレード』を参照してください。
アップグレード プロセス
- 各vManageクラスタノードで、次のことを確認します。
- 各vManageノード間でコントロール接続が確立されます。
- Network Configuration Protocol(NETCONF)が安定している
- アウトオブバンドインターフェイスは、各vManageノード間で到達可能です。
- Data Collection Agent(DCA)は
RUN
クラスタ内のすべてのノードの状態。
NETCONFのステータスを確認するには、 Tools > SSH Session
各vManageノードにログインします。ログインが成功した場合は、NETCONFは正常です。
「 show control connections
図に示すように、vManageノード間にコントロール接続があるかどうかを示します。
接続を確認するには、リモートのアウトオブバンドIPに対してpingを実行し、いずれかのvManageノードからアウトオブバンドのインターフェイスを発信します(この例では、IPアドレスは1000です)。
request nms data-collection-agent status
コマンドを発行して、DCAのステータスを確認します。
2. 1つのノードのvManageソフトウェアリポジトリに新しいCisco Viptela vManageコードをアップロードします。
3.に移動します。 Maintenance > Software Upgrade.
4. 3つのvManageノードのチェックボックスをオンにし、 Upgrade,
新しいバージョンを選択します。
5.選択 Upgrade
を選択し、プラットフォームとして[vManage]をオンにします。
6.ドロップダウンメニューから新しいコードを選択し、 Upgrade.
.
7.ソフトウェアのインストールは、ノードごとに実行されます。最初のvManageノードが新しいコードのインストールを開始する間、他のノードは Scheduled
ステータス.
最初のノードが成功すると、3つのノードにイメージが正常にインストールされるまで、次のvManageノードに新しいコードのインストールが開始されます。
注:vManageクラスタのアップグレードアクションは、スタンドアロンvManageまたはオーバーレイ内の他のデバイスのアップグレードアクションとは異なります。GUIによるアップグレードアクションでは、イメージはvManageノードにのみインストールされます。vManageノードの新しいコードはアクティブになりません。
新しいコードのアクティベーションは、次の方法で手動で行います。 request software activate
コマンドが表示されない場合もあります。
注:NETCONFセッションが正常でない場合、新しいコードのインストールは失敗します。vmanagersノード間に制御接続がないか、アウトオブバンドインターフェイス間に到達可能性の問題がある。
8.新しいコードをダウンロードして各vManageノードにインストールしたら、新しいコードを手動でアクティブ化します。
「 show software
新しいコードがインストールされたことを示す出力が表示されます。次を確認します。 show software
コマンドを各ノードで発行し、各ノードがイメージを正常にインストールしたことを確認します。
9. request nms all status
コマンドを使用して、各vManageノードの出力を取得し、アップグレード前にどのサービスが有効になっているかを確認します。
10. request nms all stop
各vManageノードのすべてのサービスを停止するコマンド。
ヒント:予期しない問題を回避するために、すべてのnmsサービスが停止するまでCLIセッションと対話しないでください。
11. request software activate
コマンドを使用して、vManageノードごとの各CLIセッションで準備を続けます。
12. request software activate
コマンドを各vManageノードで実行し、新しいコードのアクティベーションを確認します。
アクティブ化後、各ノードは新しいパーティションコードで起動するためにリブートされます。次の図に示すように、vManage GUIに一時的に到達できません。
13.システムの準備が整うと、各vManageノードにログインでき、vManageの新しいバージョンが表示されます。
request software upgrade-confirm
各vManageノードでアップグレードを確認します。
ステータスが次によって確認されたかどうかを確認します。 user
または auto
14 . アクティベーションが完了すると、最終的にすべてのNMSが個別に起動します。
一部のサービスが起動しなかった場合は、アクティブ化の後に各vManageノード上のすべてのサービスを再度停止し、NMSをノードごと、サービスごとに手動で再起動します。
「vManageプロセスを手動で再起動する」に記載されている手順に従ってください。
アプリケーションサーバが起動したら、各ノードでウォッチポイントが確立されていることを確認します。
確認
request nms all status
アップグレード前に機能していたすべてのサービスが RUN
新しいコードがアクティブになった後の状態です。
いずれかのCisco vManage GUIノードに参加し、vManageダッシュボードで3つのvManageノードが良好なステータスであることを確認します。
移動先 Administration > Cluster Management
各vManageノードがオンになっていることを確認する ready
ステータスとサービスが正しく機能している(オプションとしてSD-AVCのみ)。
vManage GUIからSSHツールを使用して、すべてのノードが到達可能であることを確認します。ログインして各vManageノードクラスタとcedges/vedgesの制御接続を確認できる場合、クラスタは良好な状態にあり、ノード間でNETCONFセッションが確立されます。
関連情報
vManageクラスタガイド
テクニカル サポートとドキュメント – Cisco Systems