OSリロードによるアップグレード
このドキュメントでは、スタンドアロンおよび高可用性(HA) vSRX ゲートウェイアプライアンスの両方について、Junos バージョンを更新するプロセスの概要を説明します。 アップグレードには、テスト済みの特定の Ubuntu バージョンと Junos バージョンの組み合わせのデプロイも含まれます。 Juniper vSRX のアップグレードメンテナンスウィンドウを開始する前に、以下のセクションで説明する完全なプロセスを確認してください。
スタンドアロンでの vSRX アップグレードは影響が大きく、リロードと再構成の間、トラフィックのダウンタイムが発生する。 アップグレード処理によってすべての構成が消去されるため、手動で構成をバックアップして復元する必要があります。
スタンドアロン vSRX デプロイのアップグレード
スタンドアロン vSRX 配備をアップグレードするには、次の手順に従います:
-
現在の vSRX 設定をエクスポート します:リロードするとすべての設定が削除されるため、配置を開始する前に設定をバックアップしてください。
-
ゲートウェイの詳細ページにアクセス します:ゲートウェイアプライアンスの詳細ページに移動して、ゲートウェイアプライアンスの詳細を表示します。
-
「バージョン・アップグレード」の作動可能検査を実行し、見つかったエラーを修正します。
アップグレードメンテナンスの数時間前に準備チェックを実行し、アップグレードメンテナンスの前に未解決のアクセスおよび構成要件に対処できるようにします。 レディネス・チェックの実行には約30分かかり、レディネス・チェックのステータスは5時間後に失効する。
-
ベアメタルサーバーの OSリロードを 実行する。 選択を編集し、システムがリロードまたはアップグレードするバージョンを指定します。
高可用性 vSRX 展開のアップグレード
HA vSRX アップグレードによるダウンタイムは、プライマリからバックアップへのフェイルオーバー期間に限定され、最小限にとどまる。 以前の設定は自動的に保存され、復元されますが、セキュリティを高めるためにオフサイト・バックアップをとっておくことが重要です。 各ノードのアップグレードに2~5時間を計画し、クラスタ全体のアップグレードを完了するために8~10時間を確保します。
HA vSRX 展開をアップグレードするには、次の手順に従います:
-
「バージョン・アップグレード」の作動可能検査を実行し、見つかったエラーを修正します。
アップグレードメンテナンスの数時間前に準備チェックを実行し、アップグレードメンテナンスの前に未解決のアクセスおよび構成要件に対処できるようにします。 レディネス・チェックの実行には約30分かかり、レディネス・チェックのステータスは5時間後に失効する。
-
各ベアメタル サーバーで OS のリロードを 1 つずつ実行し、前のリロードが完了した後にのみ次のリロードを開始します。 リロードのたびに、インストールまたはアップグレードするOSのバージョンを手動で選択します。
HAクラスタをアップグレードする場合、アップグレード終了時にOSのリロードが行われていないノードの電源が自動的に落とされます。 最初のノードでアップグレードを開始した場合、2 番目のノードはリロード中にアクティブなネットワーク・トラフィックを処理します。 最初のノードがリロードを終えると、2番目のノードのVMは自動的にパワーオフされ、トラフィックは新しいバージョンのプライマリノードとなる最初のノードに移行する。 この段階では、2番目のノードの電源はオフのままにしておく。 これは、両方のノードがプライマリになろうとして機能停止を引き起こす、バージョンの不一致を防ぐための意図的な措置である。 1台目のノードのOSリロードが完了し、トラフィックが正しく流れることを確認したら、必要に応じてアップグレード準備チェックを再実行し、2台目のノードに進みます。
vSRX 構成のマイグレーションに関する考慮事項
高可用性環境では、アップグレードによって直前の vSRX 構成が復元されます。 追加ステップは不要です。
スタンドアロン環境の場合、アップグレードによって以前の構成が復元されるわけではありませんので、構成をエクスポートしてインポートする必要があります。 詳しくは、vSRX 構成のインポートおよびエクスポートを参照してください。
また、 15.1 のような古いバージョンから移行した場合、インターフェイスのマッピングが変更されていることに気づくかもしれません。 このプロセスでは、インポート後、 vSRX のコンフィギュレーションを多少修正する必要がある。 詳細は、 1G vSRX スタンドアロン構成の移行を 参照。