博通的 VMware：2026 年技術長決策框架

在過去十八個月裡，我與基礎架構架構師們的對話，開場白如出一轍：「我們需要談談我們的 VMware 續約問題。」接下來的話則各有不同。有時是一個數字——4 倍、6 倍，在我印象最深刻的一個案例中是 11 倍。有時是一個期限。越來越多的情況是，兩者皆有。

這些對話的重點已不再是是否要離開 VMware，而是探討該去哪裡、速度該有多快，以及如果專案拖延超過續約日期會有什麼後果。戰略層面的問題早在 2024 年就由博通 (Broadcom) 拍板定案了。現在剩下的，就是執行。

這篇文章是寫給負責執行的專業人士。這不是廠商推銷——雖然 Storware 剛好也涉足這個領域，但無論你最終選擇哪種備份或遷移工具，以下的框架都適用。我試著寫出當我們的客戶開始問我們這些問題時，我希望當時就存在的那份文件。

用白話文說，到底改變了什麼

多數關於博通變革的報導都會用「地震級」、「顛覆性」、「史無前例」等形容詞。但現實情況更為枯燥，也更具永久性。具體發生了四件事：

1. 永久授權已於 2024 年初終止。所有客戶都轉為訂閱制，期限為一年、三年或五年。
2. 產品目錄大幅縮減，從 160 多個 SKU 縮減為四個主要組合包——VCF、VVF、vSphere Standard、vSphere Enterprise Plus。獨立的 vSAN、NSX 和 Aria 不再作為單一產品銷售。
3. 從 2025 年 4 月 10 日起，最低授權購買量從每個產品線 16 核心提高到 72 核心。對於執行小型或邊緣伺服器的企業來說，你現在購買的是物理上不存在的容量。
4. 延遲續約將面臨 20% 的罰款。如果你錯過了週年紀念日，第一年的訂閱價格將會追溯加上這筆漲幅。

整體的價格影響因人而異。公佈的數字從 150% 到超過 1,000% 不等，受打擊最嚴重的是中端市場的企業，他們以前執行 vSphere Essentials Plus——該產品已停產，取而代之的是包含了他們從未要求的功能的組合包。據報導，AT&T 的續約提案漲幅為 1,050%，這是個吸睛的數字，但這並非中位數。

根據我的經驗，中位數大約是 3 到 6 倍。這足以為一個嚴肅的遷移專案提供資金，但不足以讓你採取五年的觀望態度。

戰略層面的問題早在 2024 年就由博通 (Broadcom) 拍板定案了。現在剩下的，就是執行。

我最常看到技術長犯的錯誤

在這些對話中，最常見的錯誤不是選錯了目標平台，而是先選了目標平台.

供應商很喜歡這種框架，因為這讓他們能以自己的產品為主導。「遷移到 Nutanix。」「遷移到 OpenStack。」「遷移到 Proxmox。」對正確的工作負載來說，這些都是合理的歸宿——但「正確的工作負載」這個部分往往被跳過了。

在討論目標平台變得有意義之前，必須先回答四個問題。這些問題沒有一個是關於目標平台的。

問題 1：工作負載分佈為何？

一個通用的 Linux 網頁層、一個具有多路徑 FC 儲存的狀態 Oracle 資料庫、一個 2014 年遺留下來且沒人想碰的 Windows 單體應用，以及一個具有 GPU 直通的 HPC 叢集，它們都需要不同的目標平台。如果一個遷移計畫把這些都當作可以互換的虛擬機器來處理，那麼簡單的部分會成功，困難的部分會失敗——而且通常是在生產環境中，以非常引人注目的方式失敗。

這裡的原則是，在任何供應商展示之前，將每個虛擬機器歸類到三個類別之一：

• 原封不動遷移 (Lift-and-shift) 的候選者：大多數通用的 Linux 和 Windows 工作負載。遷移是機械化的——磁碟格式轉換、驅動程式注入、網路重新對應。這些構成了資產的大部分。
• 重構 (Refactor) 的候選者：那些已經接近生命週期結束或適合容器化的應用程式，遷移是改變架構的好時機。這個類別比人們最初想像的要小。
• 特殊處理案例：硬體直通、vGPU、NSX 特定的網路、僅限 vSAN 的儲存功能、對延遲敏感的交易型工作負載。這些需要個別處理。有時它們根本不會被遷移——它們會等待硬體更新或重新架構。

在我看過的大多數環境中，比例大約是 70/15/15。這 70% 決定了你的平台決策。另外的 30% 決定了你的特殊處理預算。

問題 2：你的維運團隊已經具備哪些技能？

在紙面上最便宜的目標平台，在考慮了重新培訓、招募以及陡峭學習曲線帶來的生產力成本後，很少會是真正最便宜的。這是供應商的推銷中不會包含的成本，因為供應商不用付這筆錢。根據我自己的觀察，一個粗略的經驗法則是：

如果你的團隊規模很小，而你的 VMware 環境規模卻很大，那麼授權成本最低的平台，幾乎肯定不是三年內總擁有成本 (TCO) 最低的平台。

問題 3：法律上允許你的資料存放在哪裡？

這是總部位於美國的供應商最常跳過的問題，因為對他們來說，這個問題通常沒有一個乾淨俐落的答案。

對於歐洲組織而言，有三條線索很重要。GDPR 是底線——個人資料必須在歐盟管轄區或同等制度下進行處理。NIS2 於 2024 年 10 月起在歐盟成員國生效，提高了事件通報和供應鏈安全的標準，且適用的組織範圍比其前身更廣。DORA 將於 2025 年 1 月生效，對金融服務實體施加具體的維運彈性要求，並賦予主管機關對關鍵 ICT 第三方供應商（包括資料保護供應商）的直接監督權。

覆蓋在這三者之上的是《雲端法案》(CLOUD Act)，該法案為美國當局提供了法律依據，可以迫使總部位於美國的供應商提供保存在世界任何地方的資料。這與 GDPR 第 48 條產生了明文衝突，歐盟監管機構對此也越來越明確。

具體來說：如果你退出 VMware 的時機，也是你更廣泛地重新評估對美國供應商依賴的時機，那麼與新平台並行運作的資料保護供應商也是該決策的一部分。如果主權對你的組織不重要，請忽略本節。如果重要，這不是一個軟性因素——它是一個限制條件。

如果你的團隊規模很小，而你的 VMware 環境規模卻很大，那麼授權成本最低的平台，幾乎肯定不是三年內總擁有成本 (TCO) 最低的平台。

問題 4：你的續約日期何時到來？

20% 的延遲續約罰款改變了專案計畫的計算方式。你的遷移時間表不是由你的專案計畫決定的。它是由你的續約週年紀念日決定的。

有三種情況。你要麼續約（伴隨價格上漲）。你要麼在續約前遷移（這意味著專案有一個硬性期限）。或者你續約，並在下一個訂閱窗口期間遷移（這是大多數大型企業最終選擇的路徑，因為考慮到庫存的複雜性，替代方案是不切實際的）。

無論你採取哪種立場，請深思熟慮地做出決定。最糟糕的結果是意外錯過續約日期，並且還要為你原本不想要的訂閱支付額外的罰款。

三種遷移方法，以及它們分別適合哪種環境

一旦回答了上述四個問題，技術對話就變得容易處理了。VMware 到任何平台的遷移主要由三種架構模式主導。這些取捨是真實存在的。

• 冷遷移 (Cold migration)：最簡單也最通用：關閉虛擬機器的電源，匯出磁碟映像，如果需要則轉換格式，再匯入到目標平台。像 virt-v2v 和 qemu-img 這樣的工具可以處理這些工作。每個工作負載的停機時間以小時計算，而不是分鐘。適用於長尾的低重要性工作負載，不適用於任何面向客戶的服務。
• 暖遷移 (Warm migration)：使用 VMware 的異動區塊追蹤 (Changed Block Tracking) 在來源端運作時進行大部分的資料傳輸，然後進行短暫的切換以傳輸增量資料。大多數獨立的商業遷移工具都屬於此類——Coriolis、Hystax，以及特定供應商的工具包。缺點是，在遷移窗口期間，你需要購買和維運一個獨立的產品，然後在遷移結束後將其停用，或者將其作為另一個堆疊元件進行維護。
• 備份即遷移 (Backup-as-migration)：這是我自己公司採用的架構方法，在描述它之前，我會公開聲明這一點。已經在備份 VMware 環境的同一個資料保護引擎，可以將這些備份還原到不同的 Hypervisor 類型上。備份就是遷移來源。目錄保持不變。你用於備份的產品，同時也是你用於遷移的產品——沒有第二個 SKU。

這第三種方法有三個在討論中常被低估的結構性優勢。首先，在遷移之前、期間和之後，你的保護覆蓋是不中斷的——專案期間沒有空窗期。其次，架構本身就包含了回復路徑：如果遷移後的工作負載在目標平台上運作不正常，原始備份仍在目錄中，可以透過相同的機制還原回 VMware。第三，遷移後的維運模式與你之前擁有的模式相同——相同的 WebUI、相同的策略、相同的 RBAC (角色基礎存取控制)、相同的團隊。你保護的平台改變了；保護層則沒有。

但這裡有一個（也是真實的）前提條件——備份即遷移只有在你的資料保護供應商確實將來源和目標都視為具有功能對等的一等平台時才有效。大多數供應商並非如此。這是一個供應商選擇的問題，而不是一個架構問題。

值得明確指出的兩個錯誤

我最常看到的兩種失敗模式：

如果我坐在那個位子上，我會怎麼做

把上述四個問題當作第一週的工作成果。將資產清單歸入三個類別。誠實評估維運成熟度。記錄主權限制。將續約日期貼在牆上。

然後，針對原封不動遷移 (lift-and-shift) 類別中最具代表性的工作負載執行範圍限定的概念驗證 (PoC)——不要選最簡單的，也不要選最難的，選最能代表整體情況的。測量它實際花費的時間、需要哪些人工介入、什麼東西損壞了。將這個數字乘以考慮了合理批次假設的總環境規模，這就是你的專案工期。它幾乎總是比供應商最初的估計還要長。

將你的保護策略和遷移策略視為一個決策來處理，而不是兩個。如果它們必須是不同的工具，請接受這一點並為此編列預算。如果它們可以是同一個工具，那這就是一個值得追求的結構性簡化。

然後開始行動。這些專案最困難的部分不是技術問題。而是克服一個已經順利運作了十五年的環境所帶來的慣性。

如果您想針對自己的環境討論上述任何內容，可以透過 storware.eu/book-meeting/ 聯繫 Storware 技術團隊。

「五年前，稽核員想看的是您理論上的安全控制措施；今天，他們想看的是您上一次成功復原測試中，可被驗證的時間戳記與測得的吞吐量。」

— Paweł Mączka，Storware 首席技術長（CTO）

---

法規範式重塑：將「系統性入侵」視為必然

現代合規性框架——特別是金融服務業的《數位營運韌性法案》（DORA）以及跨關鍵基礎設施產業的《NIS2 指令》——皆已放棄了「預防性防禦邊界即足夠」的假設。這些授權明文假定關鍵入侵終將發生，並將稽核焦點轉移至組織在危機期間「維持營運的實證能力」。

這一法規轉變改變了成功風險管理的衡量標準：

• 實證復原優於防禦性宣告： 組織必須主動展示持續、具備文件記錄的還原週期，而非僅指向靜態的防火牆配置。
• 遭遇侵害時的營運連續性： 資安維運中心花費數小時隔離威脅，這在程序上執行得完全正確；然而，若核心系統在這數小時內遭到加密且復原需要數週，該實體在合規基準上依然宣告失敗。
• 具防禦力的資料韌性： 備份架構已演變成企業能否承受持續性營運壓力的決定性證明。

視為基礎設施架構師的網路保險

在經歷連續數期的歷史性理賠支出後，網路保險的核保市場已不再將資料保護視為一個簡單的勾選框。保險公司正主動干預基礎設施架構，要求在簽發保單前必須做出技術承諾。現代核保指南通常要求：

1. 邏輯與網路實體隔離（Air-Gapping）： 次級資料儲存庫在常態營運下必須完全隔離，且在生產環境的路由表中不可觸及。
2. 不可變的保留鎖定（Immutable Retention Locks）： 在檔案系統層或物件儲存層強制執行儲存結構鎖定，阻止資料被竄改或刪除，防止管理員權限（Token）惡意縮短保留窗口。
3. 獨立的驗證邊界： 在備份管理主控台上直接部署多因素驗證（MFA），與企業身分識別供應商（IdP）完全解耦，以抵禦集中式身分系統淪陷的風險。
4. 復原前的惡意軟體分析： 在將歷史資料掛載回生產環境之前，以程式化方式掃描其是否存在入侵指標（IoC），防止在復原過程中造成二次自我感染。

虛擬化技術獨立性：航向後 VMware 時代

Broadcom 對 VMware 的收購徹底改變了企業基礎設施的地景。各組織正積極將其部分虛擬資產遷移至其他平台，以規避授權的不穩定性。較小規模的架構正轉向 Proxmox VE 或 XCP-ng，而大型企業環境與託管服務供應商（MSP）則開始大規模部署 OpenStack 架構。

這種遷移層給傳統備份工具帶來了嚴峻的整合挑戰，因為這些工具過往大多專為 VMware 環境而建。真正的資料安全需要一個能夠跨越個多個異質虛擬化架構、同時交付原生且無代理程式（Agentless）防護的平台，在複雜的基礎設施轉型期間，維護來源端與目的端架構的持續性資料保護。

虛擬化架構	架構特徵概況	資料保護需求
VMware vSphere	傳統企業基準；高度標準化與結構化。	維護歷史備份基準，同時支援安全的資料匯出路徑。
OpenStack	高度靈活、不綁定廠商的雲端框架；儲存與網路路徑多變。	需要動態資源發現能力，以清晰對應客製化的 Cinder、Neutron 與 Ceph 配置。
Proxmox VE / XCP-ng	針對分散式現代基礎設施的新興開源虛擬化替代方案。	需要原生、無代理程式的防護串流，避免耗費資源的客體作業系統（Guest OS）代理程式。

 

加固的 Linux：消滅架構上的立足點

由於大約 95% 鎖定企業的漏洞利用都聚焦於 Windows 環境，將資料保護引擎託管在基於 Windows 的伺服器上會使組織面臨不必要的系統性風險。將備份軟體直接建立在專屬、加固的 Linux 發行版之上，可直接消除整層常見的漏洞利用向量。

真正的維運加固要求剝離底層作業系統的所有通用功能靈活性。在加固的備份設備中，不必要的服務與未對映的核心級連接埠會被完全停用，且執行環境嚴禁安裝第三方軟體。透過將儲存的不可變性嵌套在 XFS 檔案系統層中，並將存取權限制在與硬體綁定的微碼驗證之後，儲存庫得以完全免疫外部配置的惡意操縱。

 

歐洲管轄權範式與資料主權

對於管理受規管國際資料集的現代組織而言，技術基礎設施的加固僅完成了合規要求的一半。資安主管還必須考慮控管其資料資產的管轄權邊界。在諸如美國《CLOUD 法案》等立法授權下，美國當局有權強迫總部位於其管轄權內的供應商提供其所持有的資料，無論其伺服器的實體地理位置是否位於歐盟境內。

為了滿足 NIS2 與 DORA 下嚴格的法規主權要求，企業需要對其雲端儲存路由擁有明確的控制權。這意味著必須具備選擇不綁定廠商、且與外部管轄權毫無資本或營運關聯之歐洲本土雲端供應商的能力。透過將這種嚴格的地理限制與自動化刪除碼（Erasure Coding）相結合，資料狀態將被系統性地拆分並分散至獨立的資料中心，確保任何單一節點的淪陷都不會向對手洩漏可還原的情報。

 

常見問答

什麼是「具備網路韌性」的備份平台？

傳統備份僅驗證磁碟上是否存在復原點。而具備網路韌性的平台則確保該復原點能夠在對手已掌握網路管理控制權的情況下存活。這種韌性是透過不可變檔案系統、自動化網路隔離、獨立的驗證邊界以及復原前的惡意軟體掃描來實現的。

DORA 與 NIS2 法規如何影響資料備份？

這兩個框架都將合規重點從純粹的預防性措施轉移到可實證的復原能力。稽核員要求提供記錄完善、帶有時間戳記的還原測試、能夠在全網淪陷中存活的隔離資料狀態，以及一個完全獨立於主要企業身分基礎設施運作的備份管理架構。

為什麼 OpenStack 給傳統備份工具帶來了挑戰？

與擁有高度僵化參考架構的標準虛擬化技術不同，OpenStack 允許系統管理員以幾乎無限種客製化組合來搭配 Cinder 驅動程式、Neutron 網路拓撲與 Ceph 備份儲存。傳統備份工具因假設了固定的基礎設施佈局而宣告失敗。韌性平台必須具備動態發現並對映這些客製化 OpenStack 環境的能力。

美國《CLOUD 法案》會影響實體儲存在歐盟資料中心內的資料嗎？

會。 《CLOUD 法案》允許外國當局強迫總部位於其管轄權內的供應商交付資料，不論實體伺服器位於何處。對資料駐留有嚴格法規要求的組織，需要一個端到端的主權技術堆疊，其軟體開發、技術支援和雲端基礎設施必須完全在外部法律邊界之外運作。

在真實壓力下評估您的維運韌性

如果您組織上一次成功的復原測試，早於最近一次董事會關於勒索軟體的討論，這項風險破口便不容忽視。歡迎與 Storware 團隊攜手，對照 DORA、NIS2 及現代核保基準的嚴格要求，深度分析您現行的基礎設施。

• 多重虛擬化技術靈活性： 透過單一介面，流暢地保護橫跨 VMware、OpenStack、Proxmox 及容器化架構中的資料。
• 可強制執行的網路隔離： 部署自動化 Isolator 模組，在備份任務完成後自動對次級資料複本執行實體隔離。
• 絕對的管轄權控制： 透過完全建基於歐洲境內的技術堆疊，維護端到端的資料主權。

面對現實世界的威脅，切勿依賴理論上的安全控制措施。歡迎立即聯絡我們的資料保護工程師，安排即時架構審查。

平台更新與戰略整合

各平台關鍵變更一覽

對於運行在OpenStack上的企業和服務提供者而言，全面的資料保護一直是個複雜的難題。如今，這個難題終於迎刃而解。 Storware 和 Sardina Systems 宣佈建立技術聯盟，旨在提供一個可用於生產環境的統一平台，實現全面的雲端資料保護。

整合的力量

FishOS 與 Storware 的整合透過在虛擬機器管理程式層和儲存層提供全面的備份和復原功能，增強了 OpenStack 環境。此解決方案直接連接到原生 OpenStack API，無需繁瑣的基於代理的設定。

• API驅動的自動化：無縫發現工作負載並自動執行備份計劃，無需管理單一代理程式。
• 原生 Ceph 支援：針對最常見的 OpenStack 儲存後端進行了最佳化，確保高效能資料傳輸。
• 多租戶保護：專為具有多樣化工作負載和獨立專案的大型環境而設計。
• 多種儲存目標：可將備份儲存於本機檔案系統、NFS、S3 相容物件儲存、磁帶或其他雲端。

企業的主要收益

面向服務提供者（BaaS）

直接向您的客戶提供高價值的備份即服務。降低營運複雜性，並為租戶工作負載提供業務連續性保障。

對於電信營運商

使用企業級系統保護關鍵任務工作負載，該系統可整合到現有部署中，而不會影響生產效能。

適用於私有雲企業

實現全面的資料保護——保護虛擬機器、磁碟區和應用程式元資料——而無需管理單獨的、孤立的備份基礎架構所帶來的額外開銷。