一般升級考量
在執行 vSRX 升級之前，請注意以下事項：
-
當您升級 vSRX 版本時，可能會遇到網路中斷。 為了避免中斷，請在支援潛在網路關閉時間的維護時間期間執行升級。 在升級完成之前，無法使用故障轉移功能，且此過程可能需要數小時。 對於高可用性 (HA) 環境，會移轉您的 vSRX 配置設定; 不過，建議在升級之前匯出您的設定。
-
對於獨立式環境，不會還原先前的配置，因此您應該匯出及匯入配置。 如需相關資訊，請參閱 匯入及匯出 vSRX 配置。
-
為了在 HA vSRX,所調配的vSRX閘道的 root 密碼必須與vSRX入口網站中定義的 root 密碼相符。 此外，您必須啟用 root SSH 登入 vSRX 專用 IP。
當您佈建閘道時，已在入口網站中定義密碼。 這可能不符合現行閘道密碼。 如果密碼在配置完成後已變更，請使用 SSH 連線至 vSRX 閘道器，並將 root 密碼變更為與之相符的密碼。 如果密碼不符，「備妥檢查」會失敗。
-
在 OS 重新載入期間，請勿修改 vSRX 配置。 升級程序會在程序開始時擷取現行 vSRX 叢集配置的 Snapshot。 因此，在升級程序期間修改 vSRX 配置可能會導致失敗或無法預期的結果。 例如，嘗試修改一個或兩個 vSRX 節點的自動化軟體代理程式。 配置變更可能會毀損 OS 重新載入程序。 此外，如果起始回復，則不會保留這些配置變更。
-
在 HA 叢集上執行 OS 重新載入升級之前，請先執行指令
show chassis cluster status。 節點應該與一個列為主要節點的節點及另一個列為次要節點的節點形成叢集。 請確定沒有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 帳戶在相同 Pod 中具有多個 vSRX 閘道實例，請確保一次只升級一個閘道。 一次升級多個 vSRX 可能會導致 IP 衝突、中斷升級程序，並可能導致失敗。
-
如果您將 HA 叢集配置成使用「侵入偵測原則 (IDP)」及簽章資料庫，建議您在完成升級之後更新簽章資料庫。 這是因為資料庫可能已過期。 如需線上及離線資料庫更新項目的相關資訊，請參閱 Intrusion Detection and Prevention on IBM Cloud
-
升級程序不會備份或還原任何位於受升級虛擬機器（ VM ）本機端的 vSRX 憑證。 升級程序會刪除現有的
VM，並建立一個新的，以取代JunOS檔案系統。 例如，IKE_POLICY_CERT之類的本端憑證必須在升級之前備份，並在完成之後手動還原。
set security ike policy MY_VPN_IKE_POLICY certificate local-certificate IKE_POLICY_CERT
Ubuntu 虛擬化平台升級的注意事項
vSRX 作為 VM 在 Ubuntu 虛擬化平台上運行。 通常，此虛擬機器管理程式作業系統會作為 vSRX 更新的一部分重新載入。 然而，有時僅需對 Ubuntu 虛擬機器管理程式進行維護，例如套用核心更新、安全性修補程式或漏洞修復，而無需升級 vSRX 虛擬機器本身。
在這些情況下，通常使用標準的 apt update 指令就足夠了，但有幾點重要的注意事項您必須留意。 一般認為，僅升級 Ubuntu 虛擬機器管理程式是一項安全的維護操作，且通常可在對正在運行的 vSRX 虛擬機器造成最小干擾的情況下執行。 大多數套件更新（包括標準的使用者空間函式庫和工具程式）無需中斷虛擬機器 VM 的運作。
然而，管理員在進行升級之前，必須仔細檢視升級包中所包含的套件。 某些更新可能會影響正在運行的虛擬機器的穩定性或連線狀態，直到重新啟動虛擬機器管理程式為止。
以下類型的更新需要特別注意：
- 核心套件
systemd以及udev的更新libvirt套件- 與網路相關的套件，例如
nftables、bridges 或其他虛擬化網路元件 qemu以及kvm的套件更新
在某些情況下，若在虛擬機器保持運作狀態時升級虛擬化或網路相關套件，可能會導致 VM 網路功能下降、介面停滯，或 libvirt 狀態不一致，此狀況將持續至虛擬化主機節點重新啟動為止。 重新啟動 Ubuntu 虛擬機器管理程式通常即可恢復正常運作。
在對超管理程式執行「apt upgrade」時，請參考以下建議：
- 在套用更新之前，請先檢視待處理的套件。
- 若需升級核心、
libvirt或網路元件，請安排維護時段。 - 請預先規劃在必要時重新啟動虛擬機器管理程式。
- 請盡可能避免同時對多個高可用性節點進行維護。
範例：
apt update
apt list --upgradable
apt upgrade