デバイスNOSのアップグレード
GUIから、管理対象ネットワークデバイスのネットワークオペレーティングシステム(NOS)をアップグレードします。
アップグレードプロセスを開始する前に、この手順について理解しておくことを強くお勧めします。
NOSアップグレードの概要
数ステップで、GUIからデバイスNOSをアップグレードできます。独自のデバイスプロファイルを定義している場合は、最初にそれらを更新する必要がある場合があります。ベンダーから入手した新しいOSイメージを登録し、ボタンをクリックしてアップグレードを開始します。アップグレードタスクやその他の要件は処理され、元の設定が更新されます。
サポートされているアップグレードパスについては、「リファレンス」セクションの 「NOSアップグレードパス 」を参照してください。
サポートされているOSバージョンを含む定義済みのデバイスプロファイルが製品に含まれています。サーバーをアップグレードすると、新しいバージョンでサポートされているOSバージョンのデバイスプロファイルも更新されます。その後、NOSを新しくサポートされているバージョンのいずれかにアップグレードできます。
ただし、自分で作成(複製)したデバイスプロファイルは管理されないため、サーバーをアップグレードしても、それらのデバイスプロファイルが新しくサポートされているバージョンで自動的に更新されることはありません。次のセクションで説明するように、追加するには、いくつかの追加手順に従う必要があります。
プロセスを開始する前に、以下を確認してください。
- デバイス構成のライフサイクルを理解し、展開モードの管理に慣れていることを確認します。
- ソフトウェアがアップグレードするデバイスを管理していることを確認します。 デバイス>管理対象デバイス に移動し、デバイスがテーブルに表示され、確認済みであることを確認します(緑色のチェックマーク付き)。
- NOSをアップグレードする前に、設計図からデバイスAAA/TACACS+ コンフィグレットを削除します。アップグレードが完了したら、再度適用できます。
- デバイスの管理状態が normal に設定されていることを確認します。 デバイス>管理対象デバイスに移動し、デバイスの 管理IP をクリックして管理状態を確認します。(管理状態を MAINT/DECOMM に設定しないと、デバイスが回復不能な状態になる可能性があります)。
-
デバイスの展開モードが [ドレイン] に設定されていることを確認します。
- 指定されたバージョンがサーバーとデバイスの両方で同じであることを確認します。異なる場合、デバイスをアップグレードすることはできません。別のバージョンでアップグレードしようとしても、警告は表示されません。タスクのステータスは、無期限に「進行中」状態のままです。
デバイスをグループ化して、同時にアップグレードすることもできます。これをアップグレードグループと呼びます。アップグレードグループは、スタンドアロンのアドホックな方法でデバイスをアップグレードするのに比べて、もう少し構造的です。
グループのアップグレード
アップグレードグループを使用すると、デバイスをグループ化して、同時にアップグレードできます。これにより、実際のアップグレードに先立ってアップグレードを整理できます。
例えば、ネットワークがデュアルホーミングなどの冗長性を提供する場合、接続されたデバイスをネットワークから隔離したままにしないようにデバイスをアップグレードすることができます。これを実現するには、必要に応じてデバイスを同じグループまたは異なるグループに割り当て、各グループを個別にアップグレードします。これにより、アップグレードプロセスに構造が提供され、スタンドアロンのアドホックアップグレードと比較してエラーのリスクが低減されます。アップグレードグループを使用する追加の利点は、アップグレード前にアップグレードの結果または影響を確認できることです。詳細については 、「影響レポートの表示」 を参照してください。
どのデバイスをどのグループに配置するかに制限はありません。これらはすべて、同じOSバージョンにアップグレードする同種のデバイスである場合もあれば、異なるOSバージョンにアップグレードする異なるベンダーの異なるデバイスである場合もあります。アップグレードグループでは、スタンドアロンアップグレード(グループなし)の場合と同様の柔軟性が得られます。アップグレード グループは、アップグレードの計画、編成、実行を支援するだけです。
アップグレードグループには、少なくとも1人のメンバーが必要です。アップグレードグループから最後に残っているメンバーを削除すると、アップグレードグループは自動的に削除されます。
デバイスは、常に1つのアップグレードグループにのみ属しています。デバイスがどのグループに属しているかは、管理対象デバイスウィンドウのアップグレードグループ列からすぐに確認できます。アップグレードグループに基づいてデバイスエントリーをソートおよびフィルタリングできます。デフォルトでは、すべての新しいデバイスは デフォルト グループに属します。
デフォルトグループ
デフォルトグループは、 単にdefaultという名前のグループです。すべての確認済みデバイスは、最初はこのグループに属します。 デフォルト グループの目的は、グループに明示的に割り当てられていないデバイスにホームを提供することです。
技術的には正確ではありませんが、 デフォルト グループを表示する便利な方法は、割り当てられていないデバイスを含むグループであるということです。デバイスをグループに明示的に割り当てると、 デバイスはデフォルト グループから割り当てられたグループに移動します。また、デバイスを いつでもデフォルトの グループに戻すことができます。これは、グループからデバイスの割り当てを解除するのと同じです。
デフォルトグループには、以下のプロパティがあります。
-
グループの名前は デフォルトです。
-
デフォルトグループの名前を変更すると、デフォルトグループは一時的に消えます。
-
すべての新しいデバイスは、確認されると、最初に デフォルト グループに割り当てられます。 デフォルト と呼ばれるグループがない場合(前の箇条書きを参照)、 デフォルト グループが自動的に作成され、新しいデバイスがそのグループに割り当てられます。
-
他のグループの場合と同様に、 デフォルト グループとの間でデバイスを移動できます。
-
便宜上、デバイスを デフォルト グループに戻すためのUIショートカットを提供しています。
アップグレードグループの作成
この手順を使用して、アップグレードグループを作成します。
アップグレードグループの編集
この手順を使用して、アップグレード グループの名前を変更したり、そのメンバーを変更したりします。
デバイスをアップグレードグループに割り当てる
この手順を使用して、デバイスが現在属しているアップグレードグループとは異なるアップグレードグループにデバイスを割り当てます。
影響レポートを見る
アップグレードグループを使用する追加の利点は、アップグレード前にアップグレードの影響を評価できることです。アップグレードグループの影響レポートには、以下が含まれます。
-
アップグレード中のリーフスイッチに接続されたシングルホームサーバーを特定する
-
アップグレード中のリーフスイッチペアに接続されたデュアルホームサーバーを特定する
-
アップグレード中のアクセススイッチに接続されたシングルホームサーバーを特定する
-
アップグレード中のリーフスイッチに接続されたアクセススイッチに接続されたシングルホームサーバーの識別
-
一方のスイッチがアップグレードされ、もう一方のスイッチがドレインモードになっているリーフスイッチペアに接続されたデュアルホームサーバーまたはアクセススイッチを特定します。
図3 は、レポートの例を示しています。
上記レポートの主題は leaf2です。レポートは以下を示しています。
-
switch2-server1システムはleaf2へのシングルホームであるため、leaf2をアップグレードすると分離されますswitch2-server1 -
rack1-server1システムは、leaf1とleaf2の両方にデュアルホームです。つまり、leaf1稼働している限り、アップグレードleaf2rack1-server1を分離することはありません
影響レポートは、さまざまなウィンドウから表示できます。
ユーザー定義のデバイスプロファイルを更新する
上記の概要で説明したように、デバイスがアップグレードに適した状態になっていることを確認してください。
独自のデバイスプロファイルを作成(複製)した場合は、デバイスプロファイルとそのデバイスプロファイルを使用する設計図でOSバージョンを手動で指定する必要があります。(デバイスが定義済みのデバイスプロファイルを使用している場合は、次のセクションに進み、新しいOSイメージを登録します。)
OSイメージの登録・アップロード
デバイスベンダーからOSイメージを入手します。
注意:アップグレードするデバイスと互換性のあるデバイスのオペレーティングシステムイメージを選択してください。互換性のないイメージを使用していてアップグレードに失敗した場合、デバイスを復元しても導入ロックは自動的に解除されません。導入ロックを解除してデバイスを再度アクティブ化するには、ブループリントからデバイスの割り当てを削除し、デバイスを(デバイス>管理対象デバイスから)廃止して正規化してから、デバイスをブループリントに再割り当てします。サポートが必要な場合は、 ジュニパーサポートにお問い合わせください。
左側のナビゲーションメニューから、 デバイス>システムエージェント>OSイメージ に移動し、 OSイメージの登録 (右上)をクリックします。
新しいNOSイメージをアップロードするための残りスペースを確認できます。

「デバイスOSイメージの登録」ダイアログが開きます。パーティションの空き容量が 5 GB 未満の場合、警告が表示されます。
ドロップダウンリストからプラットフォーム(EOS、NXOS、SONIC、JUNOS)を選択し、説明を入力します。
イメージをサーバーに直接アップロードするか、アクセス可能なHTTPサーバー上のイメージファイルを指すURLダウンロードリンクを提供します(以下のセクションで説明します)。
方法1:画像をアップロードする
「 画像をアップロード」を選択し、「 ファイルを選択 」をクリックしてコンピューター上の画像に移動するか、コンピューターからダイアログウィンドウに画像をドラッグアンドドロップして 開くをクリックします。

チェックサムを追加します(オプション)(以下のセクションで説明します)。
アップロードをクリックします。
ソフトウェアは、ソフトウェア パッケージがスイッチ OS でサポートされていることを検証します。サポートされていない場合 (たとえば、ファイル拡張子が間違っているため)、アップロードが開始される前に、アップロードはすぐに失敗します。
ソフトウェアが(オプションの)チェックサムを検証します。確認できない場合、アップロードが開始される前に、アップロードプロセスは直ちに失敗します。
すべての検証に合格すると、イメージがアップロードされ、テーブルビューに表示されます。
方法 2: 画像の URL を指定する
ネットワーク管理ポートを介してアップグレードするデバイスに別のHTTPサーバーがアクセス可能な場合は、OSイメージをアップロードする代わりに登録できます。HTTPおよびHTTPS URLがサポートされています。(FTP、SFTP、SCPなどはサポートされていません。
[イメージURLを指定]を選択します。

他のサーバー上のイメージを指すURLを入力します。
チェックサムを追加します(オプション)(以下のセクションで説明します)。
登録 をクリックします。
ソフトウェアが(オプションの)チェックサムを検証します。検証できない場合は、プロセスを停止します。
検証に合格すると、テーブルビューにイメージが表示されます。
チェックサムの追加(オプション)
プラットフォームによって、使用するチェックサムのタイプが決まります。
- ジュニパー Junos - MD5(32文字)またはSHA256(64文字)
- Enterprise SONiC - MD5(32文字)
- Cisco NX-OS - SHA512(128文字)
- Arista EOS - SHA512(128文字)
デバイスベンダーがチェックサムファイルを提供する場合は、ファイルをダウンロードしてチェックサムフィールドにコピーすることをお勧めします。チェックサム ファイルが利用できない場合は、必要に応じて Linux の md5sum コマンドまたは shasum コマンド、または同等のプログラムを使用してチェックサムを生成できます。
$ shasum -a 512 EOS-4.20.11M.swi dbfd28d3597777a6ee5946b52277205fc714e11ab992574b7ef1156ffcd6e379979979f8c009f665fc21212e4d38d1794a412d79bab149f859aa72be417c0975 EOS-4.20.11M.swi $
デバイスへのイメージのコピー/ダウンロード(オプション)
アップグレードする前に、新しいOSイメージをデバイスにダウンロードするオプションがあります。これにより、アップグレード ウィンドウに制約されることなく、いつでも都合の良いときに OS イメージをダウンロードできるため、柔軟性と制御性が向上します。
OSイメージを個別にダウンロードしないことを選択した場合、OSイメージは通常のNOSアップグレードワークフローの一部として自動的にダウンロードされます。その結果、アップグレードにかかる時間が長くなりますが、状況によってはより便利な場合があります。
ダウンロードする前に、「 チェックサムの追加(オプション)」の説明に従って、OSイメージをチェックサムに登録していることを確認します。
インターフェイスを動作させ続ける(オプション)
アップグレードプロセスの初期に、デバイス設定が元の状態にロールバックされ、インターフェイスは自動的に無効になります。NOSがアップグレードされると、デバイスは新しい手付かずの設定になり、インターフェイスは無効のままになります。デバイスを再起動すると、レンダリングされた設定がデバイスにプッシュされ、インターフェイスが有効になります。
トラフィックのブラックホール化を防ぐために、意図した設定がプッシュされるまで、インターフェイスは無効のままになります。アップグレード中にインターフェイスを有効にしておくには、デフォルト設定を次のように変更できます。
イメージのダウンロードタイムアウトを設定(オプション)
(異なるネットワーク上の)コントローラーとデバイス間の接続のパフォーマンスが低下すると、タイムアウトが発生する可能性があります。イメージダウンロードのタイムアウト値は、次のように設定(増加)できます。
OSイメージのアップグレード
この手順を使用して、スタンドアロンでデバイスをアップグレードしたり、アップグレードグループ内のデバイスをアップグレードしたりします。
上記の概要で説明したように、デバイスがアップグレードに適した状態にあり、デバイスプロファイルがユーザー定義の場合は、それに応じて更新されていることを確認してください。
- スタンドアロンの方法(アップグレードグループなし)でデバイスをアップグレードする場合は、以下の手順を実行します。
- アップグレードグループ内のデバイスをアップグレードする場合は、以下の手順を実行します。
- い ずれかのデバイスでジョブが失敗した場合は、エージェントをクリックしてエラーを表示します。[ Show Log ] ボタンをクリックして、詳細な Ansible ジョブを表示することもできます。アップグレードに失敗した場合は、失敗の原因となっている問題を手動で解決する必要があります。例えば、チェックサムエラーが発生した場合、無効なチェックサムを修正するか、正しいチェックサムで新しいOSイメージを登録した後、アップグレードプロセスを繰り返す必要があります。
- チェックサムが正しく、他に障害が発生しない場合、そのデバイスのジョブ状態は成功に変わり、デバイスは再起動します。
- デバイスが新しいイメージで再起動し、コントローラとのエージェント接続を再確立すると、そのデバイスのアップグレードは完了です。管理対象デバイスページには、新しいOSバージョンが表示されます。












