Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

Routing Directorのアップグレード

デプロイメントシェルが提供するアップグレード機能により、Routing Directorのインストールとそれで実行されているすべてのアプリケーションを最新リリースにアップグレードできます。

以下のリリースから、最新のJuniper Routing Directorリリース2.9.0にアップグレードできます。

既存の古いリリースからリリース2.9.0へのアップグレードパスを以下に示します。

  • 2.8.0 → 2.9.0

  • 2.7.0 → 2.9.0

  • 2.6.0 → 2.8.0 → 2.9.0

  • 2.5.0 → 2.7.0 → 2.9.0

  • 2.4.1 → 2.7.0 → 2.9.0

  • 2.4.0 → 2.4.1または2.5.0または2.6.0 → 2.7.0 → 2.9.0

  • 2.3.0 → 2.4.1または2.5.0 → 2.7.0 → 2.9.0

  • 2.2.0 → 2.4.1 → 2.7.0 → 2.9.0

  • 2.1.0 → 2.2.0 → 2.4.1 → 2.7.0 → 2.9.0

ここでは、 → 直接アップグレードを示しています。

アップグレードプロセスは、一連のデプロイメントシェルコマンドによって自動化され、必要なシステムチェックを実行し、アップグレードパッケージを取得して、クラスターノードでアップグレードプロセスを実行します。プライマリノードにローカルにダウンロードするか、Webページから直接ダウンロードしたファイルを使用してアップグレードできます。

アップグレード中は、デバイスのオンボーディング、サービスのプロビジョニング、その他の設定の変更などの変更アクティビティがシステム内で行われないことが重要です。アップグレードを行うと、すべてのコンポーネントが自動的に再起動され、その間は短時間使用できなくなります。アップグレードプロセスはネットワークを介したトラフィックには影響せず、アップグレードが完了してもデバイスとサービスは再設定されません。

注:

アップグレードする前に設定をバックアップすることをお勧めします。バックアップについては、既存の以前のリリースに対応するリリースの『インストールおよびアップグレードガイド』の「Backup Routing Directorの設定手順」を参照してください。

upgrade_routing-director-release-build-ID.imgディスクイメージファイルを使用して、最新リリースにアップグレードできます。

Routing Directorリリース2.9.0にアップグレードするには、以下の手順を実行します。

  1. アップグレードの前提条件—すべてのアップグレードの前提条件が満たされていることを確認します。

  2. Routing Director導入クラスターのアップグレード— ローカルファイル名オプションを使用したアップグレード または リモートURLオプションを使用したアップグレードのいずれかを使用して、クラスターをアップグレードします。

  3. 導入シェルとOVAシステムファイルのアップグレード—すべてのクラスターノード上の導入シェルとOVAシステムファイルをアップグレードします。

  4. クラスターアップグレード後のタスク—クラスターのアップグレード後のすべてのタスクを実行して、アップグレードプロセスを完了します。

アップグレードの前提条件

Routing Director導入クラスターをアップグレードする前に、以下を確認してください。

  • 展開シェルにアクセスでき、運用可能です。

  • VM ディスクのサイズは、推奨される システム要件に合わせて増加します。 VMディスクサイズの増加で説明されている手順を実行します。

  • (オプション) show deployment version コマンドを使用して、デプロイメントシェルから既存のリリースの現在のビルドとOVAバージョンを確認します。

  • クラスター ノードには、以下の空きディスク領域があります。

    • クラスターがデプロイされたプライマリ ノードには、合計ディスク領域の 15% + アップグレード ファイル サイズの 2 倍の空き領域が必要です。

    • 残りのプライマリ ノードには、総ディスク容量の 15% + アップグレード ファイル サイズと同じ量の空き容量が必要です。

    • ワーカー・ノードには、ディスク領域全体の 15% の空き領域が必要です。

    プライマリ ノードとワーカー ノード、およびクラスターがインストールされたインストーラ ノードを確認するには、以下の手順を実行します。

    1. いずれかのクラスターノードにログインします。

    2. exit を入力して、デプロイメントシェルから Linux ルートシェルに出ます。

    3. kubectl get nodes -o wide コマンドを使用して、クラスターのプライマリ ノードとワーカー ノードを判別します。

    4. cat /root/epic/host.mainコマンドを使用して、インストーラープライマリノードを決定します。

Routing Director導入クラスターのアップグレード

サポートされている古いリリースから最新のリリース2.9.0にアップグレードする場合は、以下の手順を実行します。

local filenameまたはremote urlのいずれかのオプションを使用して、インストールとインストールで実行されているすべてのアプリケーションをアップグレードできます。

local filenameオプションを使用したアップグレード

このオプションは、Routing Directorのインストールがインターネットにアクセスできないエアギャップ環境に使用します。ただし、アップグレードおよびアップグレードシグネチャファイルをプライマリノードにコピーできる必要があります。

アップグレードファイルをローカルにダウンロードする場合、クラスターのアップグレードが成功するとファイルが削除されることに注意してください。

リリース2.9.0にアップグレードするには、以下の手順を実行します。

  1. 既存のクラスターがインストールされたプライマリノードにrootユーザーとしてログインします。デプロイメントシェルにログインします。

  2. exit を入力して、デプロイメントシェルから Linux ルートシェルに終了します。

  3. upgrade_routing-director-release-build-ID.imgファイルをノード上の/root/epic/tempの場所にコピーします。

  4. (オプション)アップグレードファイルのシグネチャを検証する場合は、対応する upgrade_routing-director-release-build-ID.img.psig シグネチャファイルを同じ /root/epic/temp フォルダにコピーします。

  5. (オプション) gpg --verify img-psig-file img-file コマンドを使用して、アップグレードファイルのデジタル署名を検証します。次に例を示します。

    こちら primary1 インストーラのプライマリノードです。検証が完了するまでに数分かかります。

  6. cli を入力して、展開シェルに入ります。

  7. 次のコマンドを使用して、Routing Director導入クラスターをアップグレードします。

    request deployment cluster upgrade local filename upgrade_routing-director-release-build-ID.img

    次に例を示します。

    こちら primary1 インストーラのプライマリノードです。アップグレードコマンドは、アップグレード前にクラスターの状態をチェックします。クラスターヘルスチェックが GREEN ステータスを返した場合、クラスターはアップグレードされ、それ以上の入力は不要です。クラスターヘルスチェックが RED ステータスを返した場合、クラスターはアップグレードされません。クラスターのヘルスチェックが AMBER ステータスを返した場合は、アップグレードを続行するか停止するかを選択するよう求められます。

    追加のアップグレード コマンド オプション:

    また、アップグレード中に、以下のコマンドオプションのいずれか1つ以上をアップグレードコマンドとともに使用することもできます。

    1. no-confirm—使用例:

      no-confirmオプションを使用すると、AMBERステータスを無視し、プロンプトが表示されずにアップグレードを続行できます。ただし、no-confirmオプションはREDステータスを無視しません。

    2. skip-health-check—使用例:

      skip-health-checkオプションを使用すると、自動的に実行されるアップグレード前のクラスターヘルスチェックをスキップできます。ただし、アップグレードを実行する前に、クラスターの健全性が良好であることを確認する必要があります。

    3. detach-process—使用例:

      アップグレードプロセスが完了するまでに1時間から2時間かかるため、アップグレードをバックグラウンドで実行し、CLI画面を他のタスクに解放することができます。コマンドは、初期ヘルスチェックを実行してから、アップグレードを続行します。アップグレード プロセスが開始されると、プロセスは切り離されてバックグラウンドに移動し、コマンド プロンプトに戻ります。アップグレードの出力は 、/epic/temp/upgrade.log ファイルに記録されます。アップグレードプロセスのステータスを監視し、出力を画面に出力するには、 monitor start /epic/temp/upgrade.log コマンドを使用します。アップグレード プロセスが完了すると、次のような成功メッセージがすべてのクラスター ノードに表示されます。

      アップグレード プロセス中に VM から切断された場合は、アップグレード ログ ファイルでアップグレードの状態を定期的に確認できます。

    4. input—使用例:

      inputオプションを使用して、追加のAnsible入力パラメーターをアップグレードコマンドに渡します。たとえば、アップグレード中に詳細ログを有効にしたい場合は、-vオプションを使用します。

      request deployment cluster upgrade local filename upgrade_routing-director-release-build-ID.img input "-v"

    Routing Directorのインストールと、それで実行されているすべてのアプリケーションがアップグレードされます。

    アップグレードプロセスが完了するまでに1時間から2時間かかることに注意してください。アップグレード プロセス中に VM から切断された場合は、次のような出力が表示されるまで、アップグレード ログ ファイルを定期的に確認できます。

  8. 導入シェルとOVAシステムファイルをアップグレードします。

    導入シェルとOVAシステムのファイルのアップグレードに進みます。

remote urlオプションを使用したアップグレード

このオプションは、Routing Directorのインストールがインターネットにアクセスでき、アップグレードファイルがリモートにある場合に使用します。

リリース2.9.0にアップグレードするには、以下の手順を実行します。

  1. 既存のクラスターがインストールされたプライマリノードにrootユーザーとしてログインします。デプロイメントシェルにログインします。

  2. 次のコマンドを使用して、Routing Director導入クラスターをアップグレードします。

    request deployment cluster upgrade remote url "https://juniper.software.download.site/upgrade_routing-director-release-build-ID.img?query_string"

    次に例を示します。

    こちら primary1 インストーラのプライマリノードです。アップグレードコマンドは、アップグレード前にクラスターの状態をチェックします。クラスターヘルスチェックが GREEN ステータスを返した場合、クラスターはアップグレードされ、それ以上の入力は不要です。クラスターヘルスチェックが RED ステータスを返した場合、クラスターはアップグレードされません。クラスターヘルスチェックで AMBER ステータスが返された場合は、アップグレードを続行するか停止するかを選択するよう求められます。

    追加のアップグレード コマンド オプション:

    また、アップグレード中に、以下のコマンドオプションのいずれか1つ以上をアップグレードコマンドとともに使用することもできます。

    1. no-confirm—使用例:

      no-confirmオプションを使用すると、AMBERステータスを無視し、プロンプトが表示されずにアップグレードを続行できます。ただし、no-confirmオプションはREDステータスを無視しません。

    2. skip-health-check—使用例:

      skip-health-checkオプションを使用して、自動的に実行されるアップグレード前のクラスターヘルスチェックをスキップします。ただし、アップグレードを実行する前に、クラスターの健全性が良好であることを確認する必要があります。

    3. detach-process—使用例:

      アップグレードプロセスが完了するまでに1時間から2時間かかるため、アップグレードをバックグラウンドで実行し、CLI画面を他のタスクに解放することができます。コマンドは、初期ヘルスチェックを実行してから、アップグレードを続行します。アップグレード プロセスが開始されると、プロセスは切り離されてバックグラウンドに移動し、コマンド プロンプトに戻ります。アップグレードの出力は 、/epic/temp/upgrade.log ファイルに記録されます。アップグレードプロセスのステータスを監視し、出力を画面に出力するには、 monitor start /epic/temp/upgrade.log コマンドを使用します。アップグレード プロセスが完了すると、次のような成功メッセージがすべてのクラスター ノードに表示されます。

    4. input—使用例:

      inputオプションを使用して、追加のAnsible入力パラメーターをアップグレードコマンドに渡します。例えば、アップグレード中に詳細ログを有効にしたい場合は、-vオプションを使用します。

      request deployment cluster upgrade remote url "https://juniper.software.download.site/upgrade_routing-director-release-build-ID.img?query_string" input "-v"

    Routing Directorのインストールと、それで実行されているすべてのアプリケーションがアップグレードされます。

    アップグレードプロセスが完了するまでに1時間から2時間かかることに注意してください。アップグレード プロセス中に VM から切断された場合は、次のような出力が表示されるまで、アップグレード ログ ファイルを定期的に確認できます。

  3. 導入シェルとOVAシステムファイルをアップグレードします。

    導入シェルとOVAシステムのファイルのアップグレードに進みます。

導入シェルとOVAシステムファイルのアップグレード

Routing Directorのインストールとそれで実行されているすべてのアプリケーションが正常にアップグレードされたら、展開シェルとOVAシステムファイルをアップグレードする必要があります。

  1. exit と入力して、インストーラー プライマリ ノードの Deployment Shell から Linux ルート シェルに終了します。

  2. デプロイメントシェルのアップグレードスクリプトを実行します。

    導入シェルとOVAシステムファイルがアップグレードされます。

  3. (オプション)アップグレードされたクラスターのビルドと OVA バージョンをデプロイメントシェルから確認します。

アップグレードされたクラスターが正常で動作していることを確認します。続行する前に、 request deployment health-check コマンドを実行してください。

Overall Cluster StatusはGREENである必要があります。

重要:ベースOSを更新するまで、クラスターのアップグレードは完了しません。クラスターのアップグレード後のタスクに進む前に、ベースOSを更新する必要があります。ノード上のOSの更新を参照してください。

ベースOSを更新したら、クラスターアップグレード後のタスクを実行します。 クラスターのアップグレード後のタスクを参照してください。

関連ドキュメント