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へのroot 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 に変更し、元のイメージを検出します。
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 アーキテクチャに移行する」を参照してください。