IBM Cloud での vSRX のアップグレード

アップグレード

IBM Cloud® Juniper vSRX をアップグレードする前に、いくつかの方法と考慮事項を理解しておく必要があります。

vSRX バージョンレベル
ベアメタルサーバープロセッサーモデル
帯域幅:1G 対 10G
スタンドアロンまたは高可用性(HA)

次の表は、これらの要因を使用して、OS のリロードオプションを使用して vSRX をアップグレードできるかどうかを示しています。表には、アップグレードでロールバックがサポートされるかどうかも示されています。アップグレードを完了するために vSRX 設定を手動で移行する必要があるかどうかも考慮する必要があります。

次の表を参照して、OS のリロードを使用して vSRX をアップグレードできるかどうかを確認します。詳細については、「一般的なアップグレードに関する考慮事項」を参照してください。

以下に示す vSRX バージョンの詳細については、 IBM Cloud Juniper vSRX でサポートされているバージョンを参照してください。

現在の vSRX バージョン	プロセッサーのモデルと速度	スタンドアロンまたは HA	アップグレード方法	ロールバックに対応
15.1	1270v6(すべての1G導入)	スタンドアロンと HA	サポートされていません	N/a
15.1	すべての 10G 導入	スタンドアロンと HA	OS のリロードを使用したアップグレード	スタンドアロン:いいえ Ha：手動(自動ではない)ロールバックは、最初のサーバーがOSのリロードを完了した後に許可されます。 2番目のサーバーがOSのリロードを完了した後、ロールバックは許可されません。
18.4	1270v6(一部の1G導入)	スタンドアロンと HA	サポートされていません	N/a
18.4	4210(一部の 1G 導入)	スタンドアロン	OS のリロードを使用したアップグレード	いいえ
18.4	4210(一部の 1G 導入)	Ha	OS のリロードを使用したアップグレード	はい – 新しいアーキテクチャでバージョン18.4を実行している場合、最初のサーバーがOSのリロードを完了した後、手動(自動化されていない)ロールバックが許可されます。詳細については、ロールバックオプションを参照してください。いいえ – 新しいアーキテクチャなしでバージョン18.4を実行している場合。
18.4	すべての 10G 導入	スタンドアロン	OS のリロードを使用したアップグレード	いいえ
18.4	すべての 10G 導入	Ha	OS のリロードを使用したアップグレード	はい – 新しいアーキテクチャでバージョン18.4を実行している場合、最初のサーバーがOSのリロードを完了した後、手動(自動化されていない)ロールバックが許可されます。詳細については、ロールバックオプションを参照してください。いいえ – 新しいアーキテクチャなしでバージョン18.4を実行している場合。
19.4 以降	すべての 1G および 10G の導入	スタンドアロンと HA	OS のリロードを使用したアップグレード	はい – 最初のサーバーがOSのリロードを完了した後、手動(自動化されていない)ロールバックが許可されます。詳細については、ロールバックオプションを参照してください。

アップグレードに関する一般的な考慮事項

vSRX アップグレードを実行する前に、以下の点に注意してください。

vSRX バージョンをアップグレードすると、ネットワークが中断されることがあります。中断を避けるために、潜在的なネットワークダウンタイムをサポートするメンテナンス期間中にアップグレードを実行します。アップグレードが完了するまでフェイルオーバーは利用されず、数時間かかる場合があります。高可用性(HA)環境では、vSRX 構成設定が移行されます。ただし、アップグレードする前に設定をエクスポートすることをお勧めします。
スタンドアロン環境では、以前の設定は復元されないため、設定をエクスポートしてインポートする必要があります。詳細については、「 vSRX 設定のインポートとエクスポート」を参照してください。
HA vSRX でのリロードを成功させるには、プロビジョニングされた vSRX ゲートウェイの root パスワードが、vSRX ポータルで定義されている root パスワードと一致する必要があります。さらに、vSRXプライベートIPへのルートSSHログインを有効にする必要があります。

メモ：
ゲートウェイのプロビジョニング時にポータルでパスワードを定義しました。これは、現在のゲートウェイパスワードと一致しない場合があります。プロビジョニング後にパスワードが変更された場合は、SSHを使用してvSRXゲートウェイに接続し、rootパスワードを一致するように変更します。パスワードが一致していない場合、準備状況チェックは失敗します。
OSのリロード中にvSRX設定を変更しないでください。アップグレードプロセスは、プロセスの開始時に現在の vSRX クラスター構成のスナップショットを取得します。そのため、アップグレードプロセス中にvSRX設定を変更すると、障害が発生したり、予測不能な結果が発生したりする可能性があります。たとえば、vSRX ノードの一方または両方を変更しようとする自動ソフトウェアエージェントなどです。設定の変更により、OS のリロードプロセスが破損する可能性があります。さらに、ロールバックが開始された場合、これらの設定変更は保存されません。

HA クラスタで OS リロードアップグレードを実行する前に、コマンド show chassis cluster status を実行します。ノードは、1 つのノードがプライマリ、もう一方がセカンダリとしてクラスター化されている必要があります。監視エラーがないことを確認します。アップグレード前にクラスタが正常でない場合、アップグレードが失敗し、トラフィックが停止する可能性があります。

正常なクラスターの例:

IBM Cloudアカウントに同じポッドに複数のvSRXゲートウェイインスタンスがある場合は、1度に1つのゲートウェイのみがアップグレードされていることを確認してください。複数の vSRX を一度にアップグレードすると、IP コリジョンが発生し、アップグレードプロセスが中断し、障害が発生する可能性があります。
HA クラスタの場合、アップグレードプロセスでは、冗長性グループ 1 の vSRX シャーシクラスタプリエンプションフラグを無効にする必要があります。そのため、アップグレード完了後、フラグは無効になりますが、再度有効にできます。show chassis cluster status を実行して、プリエンプト設定を表示します。

OS のリロードを使用したアップグレード

OSのリロードを使用してvSRXをアップグレードするには、次の手順を実行します。

スタンドアロン環境のみ: vSRX 構成の一部のエクスポートを参照してください。
ゲートウェイの詳細ページにアクセスする、ゲートウェイ・アプライアンスの詳細の表示を参照してください。
「OSのリロード」の準備状況チェックを実行します。 vSRXの準備状況の確認を参照し、見つかったエラーに対処します。
ベアメタルサーバーごとに OS のリロードを実行します。 OS のリロードの実行を参照してください。

メモ：
HA クラスタをアップグレードするとき、プロセスはアップグレードプロセスの終わりで OS リロードを受けなかったノードの電源をオフにします。これにより、クラスタのプライマリノードとアクティブなネットワークトラフィックが新しくアップグレードされたネットワークトラフィックに移行されます。クラスタ内の最初のノードの OS リロードが完了すると、そのノードをアップグレードするための OS のリロードが送信されて実行されるまで、2 番目のノードの電力が供給されません。OS をリロードする前にノードの電源を入れると、vSRX バージョンが一致していないクラスタが稼働し、各ノードがプライマリ所有権を主張しようとする「スプリットブレイン」シナリオが発生する可能性があります。これは通常、停止を引き受けます。最初のノードの OS のリロード後、ゲートウェイは「アップグレードアクティブ」ステータスに移行します。
スタンドアロン環境のみ:vSRX構成をインポートし、必要に応じて設定を新しいアーキテクチャに移行します。

vSRX 移行の構成に関する考慮事項

高可用性環境では、アップグレードにより以前の vSRX 設定が復元されます。これ以上の手順は必要ありません。

スタンドアロン環境では、アップグレードによって以前の設定が復元されないため、設定をエクスポートしてインポートする必要があります。詳細については、「 vSRX 設定のインポートとエクスポート」を参照してください。

さらに、15.1 などの古いバージョンから移行する場合、インターフェイスマッピングが変更されている可能性があります。インポート後にvSRX設定を変更する必要があります。詳細については、 1G vSRXスタンドアロン構成の移行を参照してください。

ロールバックオプション

スタンドアロン環境では、ロールバックはサポートされていません。

vSRX バージョンからアップグレードする高可用性環境では、最初のノードが OS 再ロードされた後、および 2 番目のノードが OS 再ロードされた後にのみ、ロールバックがサポートされます。ゲートウェイは、この時点で「アップグレードのアクティブ」状態になります。最初のノードを以前のバージョンにロールバックするには、次の手順に従う必要があります。

メモ：

セカンダリノードの電源がオンになるのを待ち、トラフィックがこのノードにフェイルオーバーするのを待つ間、トラフィックの中断が発生することに注意してください。

virsh コマンドのシャットダウン<ドメインを使用して、ロールバックするノード(プライマリノード)で vSRX の電源を切ります>先に進む前にノードの電源が完全にオフになるのを待ちます。
コマンド virsh start <ドメイン>を使用して、ロールバックされていないノードで vSRX の電源を入>。そうすることで、プライマリノードが元の vSRX バージョンに戻ります。

元の vSRX イメージを復元する前に、/var/lib/libvirt/images/vSRXvM2/vSRX_Image.qcow2.backup の vSRX qcow2 ファイルの名前を/var/lib/libvirt/images/vSRXvM2/vSRX_Image.qcow2 に名前変更し、virsh が元のイメージを検出するようにします。
OSリロードの準備状況チェックを実行し、必要に応じて vSRXの準備状況を確認し、問題を解決します。
ロールバックするホストでOSのリロードを実行して、元のvSRXバージョンに戻します。

これで、クラスタは元の設定で実行されます。

サポートされていないアップグレード

1G vSRX 15.1および18.4ゲートウェイの初期の導入では、Linuxブリッジングをベースにしたネットワーク設計が採用されました。新しい 1G の導入では、SR-IOV に基づくネットワーク設計が使用されています。詳細については、 vSRXのデフォルト設定についてを参照してください。

初期の 1G の導入では、一般的に Intel 1270v6 4 コア、Sky-Lake ベースのプロセッサを使用していました。このプロセッサーは SR-IOV をサポートしていません。新しい vSRX バージョン(19.4 など)には、SR-IOV ネットワーク設計が必要です。そのため、vSRX バージョンのアップグレードは、この 1270v6 プロセッサーに基づく導入環境ではサポートされていません。

新しい vSRX バージョン(19.4 など)にアップグレードするには、新しい vSRX を注文する必要があります。完了後、設定を古い設計から新しい設計に移行できますが、手動で設定変更を新しいvSRXに適用する必要もあります。詳細については、「従来の設定を現在の vSRX アーキテクチャに移行する」を参照してください。