新しいVMでのApstraのアップグレード(VM-VM) |Apstra 5.1 |ジュニパーネットワークス

ステップ1:アップグレード前の検証

「アップグレードパス」を参照して、サポートされているバージョンにアップグレードすることを確認します。Apstra GUIで現在のApstraバージョンを確認するには、左側のナビゲーションメニューの左上隅にあるJuniper Apstraのロゴを確認します。
Apstraサーバーにadminとしてログインします(たとえば、ApstraサーバーのIPアドレスが10.28.105.3の場合、コマンドはssh admin@10.28.105.3になります)。

コマンドservice aos statusを実行して、サーバーがアクティブであり、問題がないことを確認します。

データプレーンに影響を与える可能性のある設定レンダリングの変更がないか、新しいApstraバージョンのリリースノートを確認してください。
各ブループリントを確認して、すべてのサービス構成が SUCCEEDED 状態であることを確認します。必要に応じて、デバイスをブループリントからアンデプロイして削除し、保留中または失敗したサービス設定を解決します。
プローブの異常がないか各ブループリントを確認し、可能な限り解決します。残りの異常をメモします。
新しいApstraバージョンでデバイスモデルとNOSバージョンが認定されていることを確認するには、Apstraユーザーガイド(参考資料>>認定デバイスおよびNOSバージョン)を参照してください。必要に応じて、サポートされているバージョンのいずれかにアップグレードまたはダウングレードします。
Junosデバイスを使用する場合、元の状態の設定に不可欠なmgmt_junosが含まれている必要がありますVRF詳細については、ジュニパーサポートナレッジベース記事KB77094をご覧ください。

注意：

元の設定に mgmt_junos VRF が含まれていない場合、展開は失敗します。
デバイスAAA設定をすべて削除します。デバイスのアップグレード中に、SSHアクセス用に設定されたデバイスエージェントの認証情報が必要になります。
ファイアウォールの設定に使用されていたコンフィグレットをすべて削除します。デバイスで FW のルーティングエンジンフィルターを使用する場合は、新しいコントローラーとワーカー VM の IP アドレスを含めるようにフィルターを更新する必要があります。
デバイスシステムエージェントをアップグレードするには、エージェントの作成時に設定された認証情報を使用して、ApstraがすべてのデバイスにSSH接続できる必要があります。Apstra GUIからこれを確認するには、[デバイス>管理対象デバイス]に移動し、チェックするデバイスのチェックボックスを選択してから、[エージェント]メニューの[チェック]ボタンをクリックします。すべてのジョブの状態が SUCCESS であることを確認します。チェックジョブが失敗した場合は、Apstraのアップグレードを続行する前に問題を解決してください。
rootユーザーとして、sudo aos_backupコマンドを実行し、Apstraサーバーをバックアップします。
注意：

アップグレードされたApstraサーバーには、タイムボイジャーのリビジョンは含まれていないため、過去の状態に戻す必要がある場合は、このバックアップが必要です。リファレンスデザインとの密結合のため、以前の状態は含まれておらず、Apstraのバージョン間で変更される可能性があります。
バックアップファイルを /var/lib/aos/snapshot/<shapshot_name> から外部の場所にコピーします。
新しいVMに、Apstraサーバーに必要なサーバーリソースがあることを確認します。

ステップ2:新しいApstraサーバーを展開する

手記：

古いApstraサーバーで /etc/aos/aos.conf ファイルをカスタマイズした場合(たとえば、別のネットワークインターフェイスを使用するように metadb フィールドを更新した場合)、新しいApstraサーバーVMの同じファイルに変更を再適用する必要があります。自動的に移行されません。

登録サポートユーザーとして、ジュニパーサポートダウンロード(for example, aos_server_5.0.0-63)からApstra VMイメージをダウンロードし、新しいApstraサーバーに転送します。
新しいIPアドレスを使用して、新しいApstra VMイメージをインストールして構成します(同じFQDNまたは新しいFQDNを使用できます)。
Apstraクラスタ(オフボックスエージェント、IBAプローブ)を使用していて、ワーカーVMを再利用する場合は、sudo bash aos_<aos_version>.runを実行して新しいソフトウェアをインストールします。新しいワーカー VM を使用している場合は、この手順をスキップします。

手記：
すべてのVMを置き換える例:コントローラと2つのワーカーノードがあり、それらすべてを新しいVMにアップグレードする場合は、新しいApstraバージョンで3つのVMを作成し、そのうちの1つをコントローラに指定します。
新しいApstraサーバーに、古いApstraサーバーへのSSHアクセスがあることを確認します。
新しいApstraサーバーがシステムエージェントに到達できることを確認します。(「必要な管理ポート」を参照してください)。
新しいApstraサーバーが、該当する外部システム(NTP、DNS、vSphereサーバー、LDAP/TACACs+サーバーなど)に到達できることを確認します。

ステップ3:状態のインポート

注意：

新しいVMのインポートを開始した後に、古いApstraサーバーにAPI/GUI書き込み操作を実行しても、それらの変更は新しいApstraサーバーにコピーされません。

新しいApstraサーバーにユーザーadminとしてログインします。
sudo aos_import_state コマンドを実行して、古いサーバーから SysDB をインポートし、必要な変換を適用し、構成をインポートします。必要に応じて、次の引数を含めます。
- --ip-address <old-apstra-server-ip>
管理者のユーザー名を入力します。
- --username <admin-username>
- 新しいワーカーノードIPアドレスを持つApstraクラスターの場合は、以下を含めます。 --cluster-node-address-mapping <old-node-ip> <new-node-ip>
- 古いApstraサーバーを保持するには、--disable-original-apstra-server {prompt,disable,keep}コマンドにkeep引数を追加します。
  
  例えば： --disable-original-apstra-server keep
- 実際のアップグレードを実行せずにアップグレードの前提条件チェックを実行するには、以下を使用します。--dry-run-connectivity-validation
- 接続性の検証をチェックしない場合は、以下を含めます。 --skip-connectivity-validation
- 古いApstraバージョンのSSH認証情報が新しいApstraバージョンの要件ほど厳格でない場合は、データベースを新しいApstraバージョンにインポートするときに、aos_import_stateコマンドに--override-cluster-node-credentials引数を追加する必要があります。そうしないと、アップグレードが失敗します。
- 管理 VRF が設定されていない Junos デバイスが存在する場合に、障害が発生しないアップグレードプロセスを実行するには、 --skip-junos-mgmt-vrf-check 引数を追加します。
コマンド例: 同じワーカーノードを持つ単一のVMまたはApstraクラスター
コマンド例:新しいワーカーノードを使用したApstraクラスター
上記の例では、 10.28.105.4 と 10.28.105.7 は古いワーカーノードIPアドレスで、 10.28.105.6 と 10.28.105.8 は新しいワーカーノードIPアドレスです。
データベースのインポートにはルートが必要なため、リモートApstra VMのSSHパスワードとルートパスワードの入力を求められます。

手記：
Apstraクラスタをアップグレードする場合、古いコントローラ、古いワーカー、新しいワーカーのSSHパスワードが同一である必要があり、そうでない場合、アップグレードは認証に失敗します。上記の例では、「リモートAOS VMのSSHパスワード」に入力したパスワードが、リモートコントローラー、古いワーカー、および新しいワーカーVMに使用されます(AOS-27351)

アップグレード後にワーカーVMのSSHパスワードを変更する場合は、Apstra GUI(Platform > Apstra Cluster > Nodes)でもワーカーのパスワードを更新する必要があります。

手記：
ブループリントとApstraサーバーのVMリソースのサイズによって、インポートの完了にかかる時間が決まります。データベースのインポートがデフォルト値(40分または2400秒)を超えると、操作が「タイムアウト」する可能性があります。このような場合は、 AOS_UPGRADE_DOCKER_EXEC_TIMEOUT コマンドでタイムアウト値を増やすことができます。

たとえば、次のコマンドは、タイムアウトまでの時間を 2 時間 (7200 秒) に増やします。
admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

アップグレード・スクリプトは、アップグレード中に設定変更を受けるファブリック内のデバイスの概要ビューを表示します。画面に警告が表示され、先に進む前にリリースノートとアップグレードパスのドキュメントを読むことを推奨します。リリースノートには、 コンフィギュレーションレンダリングの変更のカテゴリが含まれています。構成レンダリングの変更は、各変更がネットワークに与える影響を説明するために、上部に明確に文書化されます。
Apstraアップグレードの概要には、デバイスの役割(スーパースパイン、スパイン、リーフ、リーフペア、アクセススイッチなど)ごとに情報が表示されます。完全な構成ではなく増分構成が適用された場合は、変更に関する詳細が表示されます。
概要を確認したら、「q」と入力して概要を終了します。AOSアップグレード:インタラクティブメニューが表示され、各デバイスの正確な設定変更を確認できます。コンフィグレットを使用している場合は、アップグレードによってプッシュされた新しいコンフィグレットが既存のコンフィグレットと競合しないことを確認します。
注意：

新しいApstraリリースのApstraリファレンスデザインが変更され、コンフィグレットが無効化されている可能性があります。予期しない結果を回避するには、コンフィグレットが新しくレンダリングされたコンフィグと競合しないことを確認します。コンフィグレットを更新する必要がある場合は、アップグレードを終了し、コンフィグレットを更新してから、再度アップグレードを実行してください。
保留中の変更を確認した後にアップグレードを続行する場合は、「c」と入力します。
アップグレードを停止する場合は、「q」と入力してプロセスを中止します。この時点で終了し、後でアップグレードする場合は、プロセスを最初から開始する必要があります。

手記：
Apstraのアップグレードが失敗した場合(またはその他の誤動作の場合)は、新しいApstraサーバーを正常にシャットダウンし、古いApstraサーバーを再起動して運用を続行できます。

ステップ 4: インテントベース分析の状態をインポートする

手記：

Apstra 5.0.0以降、プローブとステージへのタグの割り当て、 evpn-host-flap-count テレメトリサービスのサポートは終了しました。

インテントベース分析用のウィジェットまたはプローブを削除または無効にするには、 sudo aos_import_state コマンドに次の引数を追加します。

ダッシュボードで使用されていないウィジェットを削除するには、 --iba-remove-unused widgets 引数を追加します。
Apstra 5.0.0以降、プローブとステージにタグを割り当てなくなりました。プローブとステージからタグを削除するには、 --iba-remove-probe-and-stage-tags 引数を追加します。
一意でないプローブラベルにシリアル番号を追加するには、 --iba-number-non-unique-probe-labels 引数を追加します。
一意でないダッシュボードラベルにシリアル番号を追加するには、 --iba-number-non-unique-dashboard-labels 引数を追加します。
Apstra 5.0.0をもって、 evpn-host-flap-count サービスのサポートは終了しました。このサービスを使用する定義されていないプローブを無効にするには、 --iba-disable-probe-with-evpn-host-flap-count-service 引数を追加します。
ダッシュボードラベルとそのウィジェットラベルから先頭または末尾の空白を削除するには、 --iba-strip-dashboard-labels-widget-labels 引数を追加します。
プローブラベルとそのプロセッサ名から先頭または末尾の空白を削除するには、 --iba-strip-probe-labels-processor-names 引数を追加します。

手順 5: 古い VM の IP アドレスを保持する (省略可能)

古い仮想マシンのIPアドレスを保持する場合は、操作モードを変更してデバイスのエージェントをアップグレードする前に、次の追加手順を実行する必要があります。

古い VM をシャットダウンするか、その IP アドレスを別のアドレスに変更して、IP アドレスを解放します。これは、IPアドレスの重複の問題を回避するために必要です。
CLIから新しいVMのApstraインタラクティブメニューに移動します。
[ネットワーク] をクリックして IP アドレスを更新し、他のパラメーターを確認します。
新しいIPアドレスを有効にするには、終了する前に同じメニューから、またはメニューを終了した後にCLIから、ネットワークサービスを再起動します。

ステップ6:Apstraのアップグレード後にフロー設定でApstra IPを変更する(元のIPを再利用しない場合)

仮想マシン間のApstraアップグレード中に、ステップ5で古いIPを再利用しない限り、ApstraのIPアドレスが変更されます。

IPアドレスが変更された場合は、以下のようにApstraフローコンポーネントを更新して新しいIPをキャプチャします。

ApstraフローCLIにSSH接続します(デフォルトの認証情報はapstra/apstraです)。
/etc/juniper/flowcoll.ymlを開きます。
EF_JUNIPER_APSTRA_API_ADDRESSフィールドを新しい IP アドレスに変更します。
sudo systemctl restart flowcoll.serviceを実行します。

ステップ7:動作モードを通常に変更する

Apstraサーバーのアップグレードを開始すると、動作モードが自動的に [通常] から [メンテナンス] に変わります。メンテナンスモードは、オフボックスエージェントが早期にオンラインになるのを防ぎます。設定はプッシュされず、テレメトリもプルされません。この時点で、アップグレードせずに以前のバージョンのApstraを引き続き使用することにした場合は、新しいApstraサーバーをシャットダウンするだけで済みます。アップグレードを完了する場合は、モードを [通常] に戻します。

Apstra GUIにログインします。
保留中のサービス構成の変更を表示する場合は、ブループリントのダッシュボードに移動し、[保留中] をクリックして、影響を受けるデバイスを確認します
左側のナビゲーションメニューから、[Platform > Apstra Cluster]>[Cluster Management]に移動します。
「動作モードの変更」ボタンをクリックし、「標準」を選択してから、「更新」をクリックします。オフボックスエージェントは、コントローラーまたはワーカー VM 上にあるかどうかにかかわらず、自動的にオンラインになり、デバイスを再接続して、保留中の構成変更をプッシュします。しばらくすると、ダッシュボードの一時的な異常が解決し、サービス構成セクションに操作が成功したことが表示されます。

[ クラスタ管理(Cluster Management )] ページには、任意のページの左下のセクションからアクセスすることもできます。ここからも、プラットフォームの正常性を色に基づいて継続的に可視化できます。

左側のナビゲーションメニューの下部で、ドットの 1 つをクリックし、[ 操作モード ] をクリックして [クラスタ管理] に移動します。「動作モードの変更」ボタンをクリックし、「標準」を選択してから、「更新」をクリックします。

手順 8: Onbox エージェントのアップグレード

Apstraサーバーとオンボックスエージェントは、同じバージョンのApstraを実行している必要があります。バージョンが異なる場合、エージェントはApstraサーバーに接続しません。

マルチステートのブループリント、特に 5 ステージを実行している場合は、エージェントを段階的にアップグレードすることをお勧めします: 最初にスーパースパインをアップグレードし、次にスパインをアップグレードし、次にリーフをアップグレードします。パスハンティングのため、この順序をお勧めします。すべてをスパインまで、またはスパインからスーパースパインまでルーティングするのではなく、ルーティングで一時的にリーフからスパインに移動して別のリーフに戻り、別のスパインに戻すことが可能です。これが発生する可能性を最小限に抑えるために、段階的にデバイスをアップグレードすることをお勧めします。

Apstra GUIにユーザーadminとしてログインします。
左側のナビゲーションメニューから [デバイス>管理対象デバイス] に移動し、アップグレードするデバイスのチェックボックスをオンにします(一度に最大 100 台のデバイス)。複数のオンボックスエージェントを同時にアップグレードできますが、デバイスのアップグレードの順序が重要です。
- まず、スーパースパインのエージェントをアップグレードします。
- スパインのエージェントをアップグレードします。
- リーフのエージェントをアップグレードします 3番目。
1 つ以上のデバイスを選択すると、テーブルの上に [デバイス ] メニューと [ エージェント ] メニューが表示されます。
[インストール]ボタンをクリックして、インストールプロセスを開始します。

ジョブの状態が IN PROGRESS に変わります。エージェントが以前のバージョンのApstraソフトウェアを使用している場合は、自動的に新しいバージョンにアップグレードされます。次に、サーバーに接続し、保留中の設定変更をデバイスにプッシュします。テレメトリも再開され、ジョブの状態が SUCCESS に変わります。
ブループリントダッシュボードの [Liveness] セクションで、デバイスの異常がないことを確認します。

手記：
エージェントのアップグレードを開始した後に、以前のApstraバージョンにロールバックする必要がある場合は、以前のApstraバージョンで新しいVMを構築し、そのVMに設定を復元する必要があります。ご不明な点がございましたら、ジュニパーテクニカルサポートにお問い合わせください。

ステップ9:古いApstraサーバーをシャットダウンする

設定に基づいて、新しいApstraサーバーのIP/FQDNを使用するようにDNSエントリーを更新します。
Apstraサーバーのプロキシを使用している場合は、新しいApstraサーバーを指していることを確認します。
古いApstraサーバーを正常にシャットダウンします。古いApstraサーバーをシャットダウンするかどうかを尋ねられます。「はい」と答えた場合は、service aos stopコマンドが自動的に実行され、古いApstraサーバーがシャットダウンされます。
Apstraクラスタをアップグレードし、ワーカーノードを新しいVMに置き換えた場合は、古いワーカーVMもシャットダウンします。

次のステップ:

お使いのデバイスのNOSバージョンが新しいApstraバージョンで認定されていない場合は、認定バージョンにアップグレードしてください。(詳細については、 Juniper Apstraユーザーガイドを参照してください。)

項目一覧

新しいVMでのApstraのアップグレード(VM-VM)