跳轉到

零停機升級（MVC）

叢集升級最怕「升到一半連線全斷」。Check Point 的 Multi-Version Cluster（MVC） 讓不同版本的成員之間還能同步連線，達成不中斷服務的滾動升級，還能先拿一台試新版再決定。

為什麼需要 MVC

一般升級時，新版成員和舊版成員的連線狀態表（State Sync）格式可能不相容 → 升級期間既有連線無法在成員間同步 → failover 會斷線。

MVC 解決這點：升級期間讓跨版本成員仍能交換連線狀態，所以可以一台一台升、流量平順切換、既有連線不掉。

graph LR
    A[成員1 舊版<br/>Active] -->|MVC 跨版本同步連線| B[成員2 升新版<br/>先 standby 驗證]
    B -->|驗證 OK 後切流量| C[再升成員1]

標準流程（概念）

  1. 先備份 / snapshot（見 Backup & Snapshot）。
  2. 在一台成員啟用 MVC。
  3. 把該成員轉 down（clusterXL_admin down）、升級它、它與舊版成員仍能同步連線狀態。
  4. 驗證新版成員流量正常、連線有同步過來。
  5. 沒問題 → 升其他成員；全部升完後關閉 MVC。

MVC 限制

  • 不支援 DAIP（動態 IP）成員。
  • 升級前務必確認來源 / 目標版本在官方 MVC 支援矩陣內。
  • 精確指令（cphaprob mvc 等）與支援組合以對應版本的 Installation and Upgrade Guide 與 SK 為準（sk107042 / sk107249）。

相關加速工具

  • Connectivity Upgrade（CU）：較舊的不中斷升級法，靠 sync 維持既有連線；MVC 是它的進階版（可跨版本同步）。
  • Blink Image：預先打包好「OS + 最新 JHF + 部分設定」的影像，clean install / 佈署比逐步 CPUSE 套件快很多，常用於量產或快速重建。
  • CPUSE Verifier：安裝前先 installer verify <ID> 檢查相依性、相容性、磁碟空間，確認可裝再裝，降低升級風險（見 CPUSE / JHF）。

R82 的新選擇：ElasticXL

ElasticXL（R82）

R82 推出 ElasticXL —— 不需實體 Orchestrator 就能做 Gateway 叢集，整個叢集用一個 SMO（Single Management Object） 代表：只設定第一台，後續成員自動 clone 設定與軟體（含未來變更），可 on-the-fly 加減成員。每台至少需 4 個介面（management / external / sync / internal）。它把 Maestro 的部分彈性下放到一般 appliance，是傳統 ClusterXL 之外的新擴充選項。

小結

  • MVC 讓跨版本成員同步連線，達成叢集零停機滾動升級。
  • 流程：備份 → 啟用 MVC → 逐台 down/升/驗證 → 全升完關 MVC。
  • 不支援 DAIP；版本組合查官方 MVC 矩陣。
  • 搭配 Blink image（快裝）、CPUSE verifier（先驗）降低風險；R82 可考慮 ElasticXL。