博通的 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 技術團隊。