インプレースアップグレード

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

アップグレード前の検証(インプレース)

サポートされているバージョンにアップグレードしていることを確認します。
管理者としてApstraサーバーにログインします(例えば、ApstraサーバーのIPアドレスが10.28.105.3の場合、コマンドはになりますssh admin@10.28.105.3)。
メモリ使用率が50%未満であることを確認して、VMに2つのバージョンのApstraソフトウェアを同時に保持するのに十分なメモリがあることを確認します。コマンドfree -hを実行してリソースを確認します。
使用率が50%>の場合、Apstraサーバーを正常にシャットダウンし、リソースを追加してから、Apstraサーバーを再起動します。

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

各ブループリントを確認して、すべてのサービス設定が成功したことを確認します。必要に応じて、ブループリントからデバイスをアンデプロイして削除し、保留中または失敗したサービス設定を解決します。
プローブ異常の各ブループリントを確認し、可能な限り解決します。残りの異常をメモします。
デバイスのNOSバージョンが新しいApstraバージョンで認定されていることを確認するには、認定デバイスとNOSを参照してください。必要に応じてアップグレードまたはダウングレードして、サポートされているバージョンのいずれかにアップグレードします。
デバイスAAA設定を削除します。デバイスのアップグレード中に、SSHアクセスには設定されたデバイスエージェント認証情報が必要です。
ファイアウォールの設定に使用するコンフィグレットを削除します。デバイスでFWのルーティングエンジンフィルターを使用する場合は、新しいコントローラとワーカーVMのIPアドレスを含むように更新する必要があります。
すべてのデバイス(デバイス>エージェント)に対してApstra Systemの「チェック」ジョブを実行し、すべてのジョブ状態が成功していることを確認します。

メモ：
デバイスシステムエージェントをアップグレードするには、Apstraソフトウェアは、デバイスシステムエージェントの作成時に使用された設定された認証情報を使用して、すべてのデバイスにSSHする必要があります。これらの認証情報を使用してSSHを検証するには、すべてのデバイスでApstra Systemの「チェック」ジョブを実行することをお勧めします。チェックジョブに失敗した場合は、Apstraのアップグレードを続行する前に問題を解決してください。

rootユーザーとして、コマンドsudo aos_backupを実行してApstraサーバーをバックアップします。

メモ：

バックアップファイル/var/lib/aos/snapshot/<shapshot_name>を外部の場所にコピーします。

新しいApstraサーバーの導入(インプレース)

Juniper Support Downloads(aos_4.0.1-1045.run.gz例:)からプラットフォーム用のApstraインストーラパッケージをダウンロードし、Apstraサーバーに転送します。

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

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

実行ファイルのsudo bash aos_<aos_version>.runバージョンである <aos_version> コマンドを実行します。例えば、バージョンがコマンドである場合、4.0.1-1045以下に示すようにコマンドになりますsudo bash aos_4.0.1-1045.run。

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

アップグレードの一環としてデバイスにプッシュされる設定変更の概要が表示されます。

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

サマリーを確認したら、を入力qしてサマリーを終了します。AOSアップグレード:インタラクティブメニューが表示され、追加情報にアクセスし、アップグレードを続行または終了できます。
注意：

新しいApstraリリースのApstraリファレンスデザインは、コンフィグレットを無効にする方法で変更されている場合があります。予期しない結果を避けるために、コンフィグレットが新しくレンダリングされたコンフィグと競合しないように確認します。コンフィグレットを更新する必要がある場合は、アップグレードを終了し、コンフィグレットを更新してから、もう一度アップグレードを実行してください。
保留中の変更を確認した後にアップグレードを続行する場合は、を入力しますc。古いApstraバージョンが削除され、新しいApstraバージョンがサーバーで有効になります。アップグレードが完了したら、Apstra GUIの[Platform > About]に移動してバージョンを確認します。

注意：

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

動作モードを「ノーマル(インプレース)」に変更

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

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

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

メモ：
この機能は、Juniper Apstra技術プレビュー機能に分類されています。これらの機能は「そのまま」で、自由に使用できます。ジュニパーサポートは、これらの機能を使用する際にカスタマーが経験する問題の解決を試み、サポートケースに代わってバグレポートを作成します。ただし、ジュニパーは技術プレビュー機能に対して包括的なサポートサービスを提供していない場合があります。

詳細については、 Juniper Apstra技術プレビューページを参照するか、ジュニパーサポートにお問い合わせください。

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

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

オンボックスエージェントのアップグレード(インプレース)

デバイスは引き続き古いApstraサーバーに接続されています。(「管理対象デバイス>デバイス」を参照してください)。エージェントをアップグレードすると、デバイスは古いApstraサーバーから切断し、新しいApstraサーバーに接続します。

注意：

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

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

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

ワーカーノードのアップグレード(Apstraクラスタのみ)

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

ApstraサーバーにダウンロードしたときにApstraインストーラパッケージをワーカーノードにダウンロードしなかった場合は、今すぐダウンロードしてください。

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