同じVM上でのApstraのアップグレード(インプレース)

手記：

インプレースでアップグレードした場合、セキュリティの脆弱性の更新を含むUbuntu Linux OSの修正は受け取れません。これらの更新プログラムを受け取るには、新しい VM でアップグレードする必要があります。代わりにインプレースでアップグレードするには、読み続けてください。

Apstraサーバーをアップグレードするには、Apstra OS管理者権限とApstra管理者ユーザーグループの権限が必要です。

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

「アップグレードパス」を参照して、サポートされているバージョンにアップグレードしていることを確認します。(現在のApstraのバージョンを確認するには、Apstra GUIの[プラットフォーム>バージョン情報]に移動します。Apstraバージョン4.2.1以降、ApstraバージョンはGUIの左側のナビゲーションメニュー、Juniper Apstraロゴの下にも表示されます)。
デフォルトでは、Apstraをアップグレードすると、追加のDockerサブネット172.18.0.1/16が作成されます。このサブネットをネットワーク内の他の場所で使用している場合、Apstraのアップグレードに失敗する可能性があります。これが当てはまる場合は、別のサブネットの使用方法について、DockerネットワークとApstraのアップグレードを参照してください。
Apstraサーバーに管理者としてログインします(例えば、ApstraサーバーのIPアドレスが10.28.105.3の場合、コマンドはssh admin@10.28.105.3になります)。
VMに、2つのバージョンのApstraソフトウェアを同時に保持するのに十分なメモリがあることを確認します。コマンドfree -hを実行して、メモリ使用率が50%未満かどうかを確認します。
使用率が50%を超える場合は、Apstraサーバーを適切にシャットダウンし、リソースを追加してから、Apstraサーバーを再起動します。

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

データプレーンに影響を与える可能性のある設定レンダリングの変更がないか、新しいApstraバージョンのリリースノートを確認してください。必要に応じてコンフィグレットを更新します。
各ブループリントを確認して、すべてのサービス構成が成功したことを確認します。必要に応じて、デバイスをブループリントから展開解除して削除し、保留中または失敗したサービス構成を解決します。
各ブループリントにプローブ異常がないか確認し、可能な限り解決します。残っている異常をメモします。
「認定デバイスとNOSバージョン」を参照して、お使いのNOSバージョンが新しいApstraバージョンに適合していることを確認してください。必要に応じて、サポートされているバージョンのいずれかにアップグレードまたはダウングレードします。
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>から外部の場所にコピーします。

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

ジュニパーサポートダウンロード(aos_server_4.1.2-269など)からお使いのプラットフォームのApstraインストーラパッケージをダウンロードし、Apstraサーバーに転送します。

Apstraインストーラパッケージを解凍します。

Apstraクラスター(オフボックスエージェント、IBAプローブ)を使用している場合は、インストーラーパッケージをワーカーノードにもダウンロードします。後の手順でワーカーノードをアップグレードします。
管理者としてApstraサーバーにログインします。

sudo bash aos_<aos_version>.runコマンドを実行します。<aos_version> は実行ファイルのバージョンです。たとえば、バージョンが4.0.1-1045の場合、コマンドは次のようにsudo bash aos_4.1.1-287.runされます。

このコマンドを実行すると、以前のバージョンのApstraが検出されると、スクリプトは新規インストールモードではなくアップグレードモードになります。新しい Docker コンテナーは、以前のバージョンの Docker コンテナーの横にインストールされます。スクリプトは、以前のバージョンからデータをインポートし、新しいバージョンのApstra SysDBに移行します。

アップグレードスクリプトは、アップグレード中に設定変更を受け取るファブリック内のデバイスの概要ビューを表示します。Apstraバージョン4.1.2以降、先に進む前にリリースノートとアップグレードパスのドキュメントを読むことを推奨する警告が画面に表示されます。リリースノートには、Apstraバージョン4.1.2以降の コンフィギュレーションレンダリングの変更のカテゴリが含まれています。設定レンダリングの変更は、各変更がネットワークに与える影響を説明する上部に明確に文書化されています。

Apstraバージョン4.0.1では、 Apstraアップグレードの概要 には、デバイスの役割(スーパースパイン、スパイン、リーフ、リーフペア、アクセススイッチなど)ごとに分けられた情報が表示されます。完全な構成ではなく増分構成が適用された場合は、変更に関する詳細が表示されます。

概要を確認したら、「q」と入力して概要を終了します。AOSアップグレード:インタラクティブメニューが表示され、各デバイスの正確な構成変更を確認できます。コンフィグレットを使用している場合は、アップグレードによってプッシュされる新しい設定が既存のコンフィグレットと競合しないことを確認します。
注意：

新しいApstraリリースのApstraリファレンスデザインは、コンフィグレットを無効にする方法で変更されている可能性があります。予期しない結果を回避するには、コンフィグレットが新しくレンダリングされたコンフィグと競合しないことを確認します。コンフィグレットを更新する必要がある場合は、アップグレードを終了し、コンフィグレットを更新してから、アップグレードを再度実行します。
保留中の変更を確認した後にアップグレードを続行する場合は、「c」と入力します。古いバージョンのApstraが削除され、新しいバージョンのApstraがサーバーでアクティベートされます。アップグレードが完了したら、Apstra GUIの[プラットフォーム]>バージョン情報に移動して、バージョンを確認します。

注意：

Apstraサーバーのアップグレードは、中断を伴うプロセスです。インプレース (同じ VM) をアップグレードし、この時点からアップグレードを続行する場合、アップグレードをロールバックすることはできません。以前のバージョンに戻す唯一の方法は、以前のバージョンで新しい VM を再インストールし、以前に作成したバックアップからデータベースを復元することです。バックアップを取ったでしょ?
アップグレードを停止する場合は、q を入力してプロセスを中止します。この時点で終了し、後でアップグレードする場合は、プロセスを最初から開始する必要があります。
Apstraクラスターを使用している場合、ワーカーノードはApstraコントローラーから切断され、FAILED状態に変わります。この状態は、オフボックスエージェントとワーカーノード上にあるIBAプローブコンテナが使用できないことを意味します。ただし、オフボックスエージェントによって管理されているデバイスは引き続き使用されます。後のステップでエージェントをアップグレードした後、Apstraクラスター内のワーカーノードをアップグレードすると、エージェントやプローブが使用可能になります。

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

Apstraサーバーのアップグレードを開始すると、動作モードが [通常 ]から [メンテナンス ]に自動的に変わります。アップグレードが完了したら、手動でモードを [通常] に戻す必要があります。

Apstra GUIの左側のナビゲーションメニューから、[プラットフォーム]>[Apstraクラスター]>クラスター管理に移動します。
「動作モードの変更」ボタンをクリックし、「通常」を選択してから、「更新」をクリックします。モードを [通常(Normal)] に変更すると、構成済みのオフボックスエージェントがすべてアクティブ化されますが、(次のセクションで) オンボックスエージェントのアップグレードを開始する必要があります。

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

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

エージェントはまだアップグレード中であるため、エージェントは接続されません。アップグレードが完了すると、エージェントはサーバーに再接続し、オンラインに戻ります。ブループリントダッシュボードでは、スパインとリーフの活性異常も解決されます。

ステップ 4: オンボックスエージェントのアップグレード

注意：

エージェントのアップグレードを開始すると、以前のバージョンにロールバックすることはできません。以前のバージョンに戻す唯一の方法は、以前のバージョンで新しい VM を再インストールし、以前に作成したバックアップからデータベースを復元することです。

ユーザー管理者としてApstra GUIにログインします。
左側のナビゲーションメニューから、[デバイス]>[システムエージェント]>[エージェント]に移動し、アップグレードするデバイスを選択します(Apstraバージョン4.0.1以降、一度に最大100台のデバイス)。複数のオンボックスエージェントを同時にアップグレードできますが、デバイスのアップグレードの順序は重要です。
- 最初にスーパースパイン用のエージェントをアップグレードします。
- スパイン用のエージェントを2番目にアップグレードします。
- リーフのエージェントをアップグレードします。
[インストール]ボタンをクリックして、インストールプロセスを開始します。ジョブの状態が [進行中] に変わります。エージェントが以前のバージョンのApstraソフトウェアを使用している場合は、自動的に新しいバージョンにアップグレードされます。次に、サーバーに接続し、保留中の構成変更をデバイスにプッシュします。テレメトリも再開され、ジョブの状態が SUCCESS に変わります。
ブループリントダッシュボードの [Liveness] セクションで、デバイスに異常がないことを確認します。

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

ステップ5:ワーカーノードをアップグレードする(Apstraクラスタのみ)

Apstraクラスター(オフボックスエージェントやIBAプローブ用)を使用している場合は、ワーカーノードとアップグレード済みのコントローラーノードをアップグレードする必要があります。

ApstraサーバーにダウンロードしたときにApstraインストーラーパッケージをワーカーノードにダウンロードしなかった場合は、ここでダウンロードします。

各Apstraワーカーノードから、sudo bash aos_<aos_version>.runコマンドを実行します。<aos_version>は実行ファイルのバージョンです。たとえば、バージョンが 4.1.1-287 の場合、コマンドは sudo bash aos_4.1.1-287.run (オプションなし) になります。これは、コントローラのアップグレードに使用したのと同じファイルです。ワーカーノードのアップグレード中にプロンプトは表示されません。

次のステップ:

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