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

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

手順 1: アップグレード前の検証

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

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

データプレーンに影響を与える可能性のある設定レンダリングの変更がないか、新しいApstraバージョンのリリースノートを確認してください。
各ブループリントを確認して、すべてのサービス構成が SUCCEEDED 状態であることを確認します。必要に応じて、デバイスをブループリントから展開解除して削除し、保留中または失敗したサービス構成を解決します。
各ブループリントにプローブ異常がないか確認し、可能な限り解決します。残っている異常をメモします。
Apstraユーザーガイド(リファレンス>デバイス>認定デバイスとNOSバージョン)を参照して、デバイスモデルとNOSバージョンが新しいApstraバージョンで認定されていることを確認します。必要に応じて、サポートされているバージョンのいずれかにアップグレードまたはダウングレードします。(Apstraバージョン4.2.0以降、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>から外部の場所にコピーします。
新しい仮想マシンに、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サーバーにユーザー管理者としてログインします。
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)。

アップグレード後にワーカー仮想マシンのSSHパスワードを変更する場合は、Apstra GUI(プラットフォーム>Apstraクラスター>ノード)でもワーカーのパスワードを更新する必要があります。

手記：
ブループリントのサイズと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 アドレスを保持する (省略可能)

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

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

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

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

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

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

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

手順 6: オンボックスエージェントをアップグレードする

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

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

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

ジョブの状態が [進行中] に変わります。エージェントが以前のバージョンの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ユーザーガイドを参照してください。)

このページの目次