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

セキュリティ脆弱性の更新を含むUbuntu Linux OSの修正を受けられるように、(同じ仮想マシンにインプレースでアップグレードするのではなく)新しい仮想マシンでApstraをアップグレードすることをお勧めします。Apstraサーバーをアップグレードするには、Apstra OS管理者ユーザー権限とApstra管理者ユーザーグループ権限が必要です。

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

「アップグレードパス」を参照して、サポートされているバージョンにアップグレードすることを確認します。(現在のApstraバージョンは、Apstra GUIの[Platform >About (プラットフォームバージョン情報)で確認できます。Apstraバージョン4.2.1では、GUIの左側のナビゲーションメニューのJuniper Apstraロゴの下にApstraバージョンも表示されます。
Apstraサーバーにadminとしてログインします(たとえば、ApstraサーバーのIPアドレスが10.28.105.3の場合、コマンドはssh admin@10.28.105.3になります)。

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

データプレーンに影響を与える可能性のある設定レンダリングの変更がないか、新しいApstraバージョンのリリースノートを確認してください。
各ブループリントを確認して、すべてのサービス構成が SUCCEEDED 状態であることを確認します。必要に応じて、デバイスをブループリントからアンデプロイして削除し、保留中または失敗したサービス設定を解決します。
プローブの異常がないか各ブループリントを確認し、可能な限り解決します。残りの異常をメモします。
新しいApstraバージョンでデバイスモデルとNOSバージョンが認定されていることを確認するには、Apstraユーザーガイド(参考資料>>認定デバイスおよびNOSバージョン)を参照してください。必要に応じて、サポートされているバージョンのいずれかにアップグレードまたはダウングレードします。(Apstraバージョン4.2.0以降、ApstraはEX4300を非推奨としました。Apstraバージョン4.2.1以降、EX4300がアクティブなブループリントに存在する場合、アップグレードはブロックされます。
Junosデバイスを使用していて、Apstraバージョン4.2.1にアップグレードする場合、元の状態の設定に必須の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_4.1.2-269)から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>
- 実際のアップグレードを実行せずにアップグレードの前提条件チェックを実行するには、以下を使用します。--dry-run-connectivity-validation
- 接続性の検証をチェックしない場合は、以下を含めます。 --skip-connectivity-validation
- 古いApstraバージョンのSSH認証情報が新しいApstraバージョンの要件ほど厳格でない場合は、データベースを新しいApstraバージョンにインポートするときに、aos_import_stateコマンドに--override-cluster-node-credentials引数を追加する必要があります。そうしないと、アップグレードが失敗します。
コマンド例: 同じワーカーノードを持つ単一の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リソースのサイズによって、インポートの完了にかかる時間が決まります。データベースのインポートがデフォルト値を超えると、操作が「タイムアウト」する可能性があります。(Apstra 4.1.2以降のデフォルト値は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バージョン4.1.2以降では、画面に警告が表示され、先に進む前にリリースノートとアップグレードパスのドキュメントを読むことを推奨します。リリースノートには、Apstraバージョン4.1.2の時点で、 設定レンダリングの変更に関するカテゴリが含まれています。構成レンダリングの変更は、各変更がネットワークに与える影響を説明するために、上部に明確に文書化されます。
Apstraバージョン4.0.1では、 Apstraアップグレードサマリー には、デバイスの役割(スーパースパイン、スパイン、リーフ、リーフペア、アクセススイッチなど)ごとに分けて情報が表示されます。完全な構成ではなく増分構成が適用された場合は、変更に関する詳細が表示されます。
概要を確認したら、「q」と入力して概要を終了します。AOSアップグレード:インタラクティブメニューが表示され、各デバイスの正確な設定変更を確認できます。コンフィグレットを使用している場合は、アップグレードによってプッシュされた新しいコンフィグレットが既存のコンフィグレットと競合しないことを確認します。
注意：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次のステップ:

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