Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

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

新しいVMでApstraをアップグレードすると、セキュリティ脆弱性の更新を含むUbuntu Linux OSの修正が提供されます。Apstraサーバーをアップグレードするには、Apstra OS管理者ユーザー権限とApstra管理者ユーザーグループ権限が必要です。

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

  1. サポートされているバージョンにアップグレードすることを確認するには、アップグレードパスを参照してください。Apstra GUIで現在使用しているApstraのバージョンを確認するには、左側のナビゲーションメニューの左上隅にあるJuniper Apstraのロゴを確認します。
  2. Apstraサーバーに管理者としてログインします(たとえば、ApstraサーバーのIPアドレスが10.28.105.3の場合、コマンドはssh admin@10.28.105.3になります)。
  3. コマンドservice aos statusを実行して、サーバーがアクティブで問題がないことを確認します。
  4. データプレーンに影響を与える可能性のある構成レンダリングの変更について、新しいApstraバージョンのリリースノートを確認してください。
  5. 各ブループリントを確認して、すべてのサービス設定が SUCCEEDED 状態であることを確認します。必要に応じて、デバイスをアンデプロイし、ブループリントから削除して、保留中または失敗したサービス設定を解決します。
  6. プローブ異常がないか各設計図を確認し、可能な限り解決します。残っている異常をメモします。
  7. 新しい ApstraバージョンでデバイスモデルとNOSバージョンが認定されていることを確認します> Apstraユーザーガイド (デバイス>認定デバイスおよびNOSバージョンのリファレンス)を参照してください。必要に応じて、サポートされているバージョンのいずれかにアップグレードまたはダウングレードします。
  8. Junosデバイスを使用している場合は、元の設定に不可欠なmgmt_junosが含まれている必要がありますVRF。詳細についてはジュニパーサポートナレッジベースの記事KB77094を参照してください。
    注意:

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

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

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

注:

古いApstraサーバーで /etc/aos/aos.conf ファイルをカスタマイズした場合(たとえば、別のネットワークインターフェイスを使用するように metadb フィールドを更新した場合)、新しいApstraサーバーVMの同じファイルに変更を再適用する必要があります。自動的に移行されるわけではありません。
  1. 登録サポートユーザーは、ジュニパーサポートダウンロード(for example, aos_server_5.0.0-63)からApstra VMイメージをダウンロードし、新しいApstraサーバーに転送します。
  2. 新しいIPアドレスで新しいApstra VMイメージをインストールし、設定します(同じまたは新しいFQDNを使用できます)。
  3. Apstra クラスター(オフボックスエージェント、IBAプローブ)を使用していて、ワーカーVMを再利用する場合は、sudo bash aos_<aos_version>.runを実行して新しいソフトウェアをインストールします。新しいワーカー VM を使用している場合は、この手順をスキップします。
    注:

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

ステップ3:状態をインポートする

注意:

新しいVMのインポートを開始した後に、古いApstraサーバーに対してAPI/GUI書き込み操作を実行した場合、それらの変更は新しいApstraサーバーにはコピーされません。
  1. 新しいApstraサーバーにユーザー管理者としてログインします。
  2. sudo aos_import_stateコマンドを実行して、古いサーバーからSysDBをインポートし、必要な変換を適用して、設定をインポートします。必要に応じて、以下の引数を含めます。
    • --ip-address <old-apstra-server-ip>
  3. 管理者のユーザー名を入力します。
    • --username <admin-username>
    • 新しいワーカーノードのIPアドレスを持つApstraクラスターの場合は、以下を含めます。 --cluster-node-address-mapping <old-node-ip> <new-node-ip>
      注:ワーカーノードは、新しいコントローラと同じバージョンのApstra OSを実行する必要があります。同じバージョンでは、古いワーカーノードが新しいワーカーノードに1:1でマップされます。

    • 古いApstraサーバーを保持するには、--disable-original-apstra-server {prompt,disable,keep}コマンドにkeep引数を追加します。

      例えば： --disable-original-apstra-server keep

    • 実際のアップグレードを実行せずにアップグレード前提条件チェックを実行するには、以下を使用します。--dry-run-precondition

    • 接続の検証を確認しない場合は、以下を含めます。 --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アドレスです。

    データベースのインポートにはrootが必要なため、リモートのApstra VMのSSHパスワードとrootパスワードを求められます。

    注:

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

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

    ブループリントのサイズと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アップグレードサマリーには、デバイスの役割別(スーパースパイン、スパイン、リーフ、リーフペア、アクセススイッチなど)別に分けられた情報が表示されます。フル設定ではなく増分設定が適用された場合は、変更に関する詳細が表示されます。

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

    新しいApstraリリースのApstraリファレンスデザインが、コンフィグレットを無効にする方法で変更されている可能性があります。予期しない結果を回避するには、コンフィグレットが新しくレンダリングされたコンフィグと競合しないことを確認します。コンフィグレットを更新する必要がある場合は、アップグレードを終了し、コンフィグレットを更新してから、アップグレードを再実行してください。
  5. 保留中の変更を確認した後にアップグレードを続行する場合は、「c」と入力します。
  6. アップグレードを停止する場合は、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 アドレスを保持する (オプション)

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

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

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

VM間でのApstraアップグレード中は、 ステップ5で古いIPを再利用しない限り、Apstra IPアドレスは変更されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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