IBMクラウドでの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	サポートされていません	該当なし
15.1	すべての10G導入	スタンドアロンおよび HA	OS リロードを使用したアップグレード	スタンドアロン: いいえ HA: 手動 (自動ではない) ロールバックは、最初のサーバーが OS のリロードを完了した後に許可されます。 2 番目のサーバーが OS のリロードを完了した後は、ロールバックは許可されません。
18.4	1270v6(一部の1G展開)	スタンドアロンおよび HA	サポートされていません	該当なし
18.4	4210(一部の1G展開)	スタンドアロン	OS リロードを使用したアップグレード	いいえ
18.4	4210(一部の1G展開)	はぁ	OS リロードを使用したアップグレード	はい – 新しいアーキテクチャでバージョン 18.4 を実行している場合、最初のサーバーが OS のリロードを完了した後、手動 (自動ではない) ロールバックが許可されます。詳細については、「ロールバックオプション」を参照してください。いいえ – 新しいアーキテクチャなしでバージョン 18.4 を実行している場合。
18.4	すべての10G導入	スタンドアロン	OS リロードを使用したアップグレード	いいえ
18.4	すべての10G導入	はぁ	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 つのノードがプライマリとしてリストされ、もう 1 つのノードがセカンダリとしてリストされるようにクラスター化する必要があります。モニターに障害がないことを確認します。アップグレード前にクラスターが正常でない場合、アップグレードが失敗し、トラフィックの停止が長引く可能性があります。

正常なクラスターの例:

IBM Cloud アカウントの同じポッド内に複数の vSRX 仮想ファイアウォールゲートウェイインスタンスがある場合は、一度に 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 shutdown <domain) コマンドを使用して、ロールバックするノード(プライマリノード)の vSRX 仮想ファイアウォールの電源をオフにします> ノードの電源が完全にオフになるのを待ってから続行します。
virsh start <domain> コマンドを使用して、ロールバックされていないノードで 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 をサポートしていません。19.4などの新しいバージョンのvSRX仮想ファイアウォールでは、SR-IOVネットワーク設計が必要です。そのため、vSRX仮想ファイアウォールのバージョンアップは、この1270v6プロセッサをベースにした導入ではサポートされていません。

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

このページの目次