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

vSRX アップグレードを実行する前に、以下の考慮事項について検討してください。

• vSRX のバージョンをアップグレードする際、ネットワーク接続に一時的な障害が生じる可能性があります。 途絶させないためには、ネットワーク・ダウン時間が発生しても対応できるように、保守時間帯にアップグレードを行ってください。 フェイルオーバーは、アップグレードが完了するまで利用できません。これには数時間かかる可能性があります。 高可用性 (HA) 環境では、vSRX 構成設定がマイグレーションされますが、アップグレードする前に設定をエクスポートしておくことをお勧めします。

• スタンドアロン環境では、前の構成は復元されないので、構成をエクスポートしてインポートする必要があります。 詳しくは、vSRX 構成のインポートおよびエクスポートを参照してください。

• HA vSRX での再ロードが成功するためには、プロビジョン済み vSRX ゲートウェイのルート・パスワードが vSRX ポータルに定義されたルート・パスワードと一致している必要があります。 さらに、vSRX プライベート IP へのルート SSH ログインを有効にすることも必要です。

  ゲートウェイのプロビジョン時にポータルでパスワードを定義しました。 これが、現在のゲートウェイ・パスワードと一致しないことがあります。 プロビジョニング後にパスワードが変更されている場合は、SSH を使用して vSRX ゲートウェイに接続し、一致するルート・パスワードに変更します。 パスワードが一致しないと、作動可能検査が失敗します。

• OS 再ロード中に vSRX 構成を変更しないでください。 アップグレード・プロセスは、プロセスの最初に、現在の vSRX クラスター構成のスナップショットをキャプチャーします。 そのため、アップグレード・プロセス中に vSRX 構成を変更すると、障害や予期しない結果が生じることがあります。 例えば、自動化ソフトウェア・エージェントが一方または両方の vSRX ノードの変更を試行することがあります。 構成変更により、OS 再ロード・プロセスに不具合が発生することがあります。 また、ロールバックが開始した場合、これらの構成変更は保持されません。

• HA クラスター上で OS 再ロード・アップグレードを実行する前に、コマンド show chassis cluster status を実行します。 ノードはクラスタ構成とし、1つのノードをプライマリ、もう1つのノードをセカンダリとして指定する必要があります。 monitor failures がないことを確認してください。 アップグレード前にクラスタの状態が正常でない場合、アップグレードが失敗し、トラフィックの停止が長引く可能性があります。

  正常なクラスターの例:

   root@asloma-19-10g-ha1-vsrx-vSRX-Node0> show chassis cluster status
   Monitor Failure codes:
     CS  Cold Sync monitoring        FL  Fabric Connection monitoring
     GR  GRES monitoring             HW  Hardware monitoring
     IF  Interface monitoring        IP  IP monitoring
     LB  Loopback monitoring         MB  Mbuf monitoring
     NH  Nexthop monitoring          NP  NPC monitoring
     SP  SPU monitoring              SM  Schedule monitoring
     CF  Config Sync monitoring      RE  Relinquish monitoring
     IS  IRQ storm
  
   Cluster ID: 2
   Node   Priority Status               Preempt Manual   Monitor-failures
  
   Redundancy group: 0 , Failover count: 1
   node0  100      primary              no      no       None
   node1  1        secondary            no      no       None
  
   Redundancy group: 1 , Failover count: 1
   node0  100      primary              no      no       None
   node1  1        secondary            no      no       None
  
   {primary:node0}
  

  モニターに失敗した異常なクラスターの例:

    root@asloma-tc11-15-10g-pubpriv-ha1-vsrx-vSRX-Node1> show chassis cluster status
    Monitor Failure codes:
      CS  Cold Sync monitoring        FL  Fabric Connection monitoring
      GR  GRES monitoring             HW  Hardware monitoring
      IF  Interface monitoring        IP  IP monitoring
      LB  Loopback monitoring         MB  Mbuf monitoring
      NH  Nexthop monitoring          NP  NPC monitoring
      SP  SPU monitoring              SM  Schedule monitoring
      CF  Config Sync monitoring
    Cluster ID: 3
    Node   Priority Status         Preempt Manual   Monitor-failures
  
    Redundancy group: 0 , Failover count: 1
    node0  0        lost           n/a     n/a      n/a
    node1  1        primary        no      no       None
  
    Redundancy group: 1 , Failover count: 1
    node0  0        lost           n/a     n/a      n/a
    node1  0        primary        no      no       CS
  
    {primary:node1}
  

• お客様の IBM Cloud アカウントに属する同じポッド内に複数の vSRX ゲートウェイ・インスタンスがある場合、一度に 1 つのゲートウェイだけをアップグレードしてください。 一度に複数の vSRX をアップグレードすると、IP の競合が発生してアップグレード・プロセスが妨げられ、障害が発生する可能性があります。

• HAクラスタで侵入検知ポリシー（IDP）とシグネチャデータベースを使用するように設定している場合は、アップグレード完了後にシグネチャデータベースを更新することをお勧めします。 これは、データベースが古くなっている可能性があるためです。 オンラインおよびオフラインでのデータベースの更新に関する詳細については、以下を参照してください 侵入検知および防止 IBM Cloud

• アップグレード処理では、アップグレード対象の仮想マシン（ VM ）にローカルに保存されている vSRX 証明書は、バックアップも復元も行われません。 アップグレード処理では、既存の VM が削除され、新しいものが作成されます。これにより、 JunOS のファイルシステムが置き換えられます。 例えば、 IKE_POLICY_CERT のようなローカル証明書は、アップグレードの前にバックアップし、完了後に手動でリストアする必要があります。

set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT

apt update
apt list --upgradable
apt upgrade