網管人雜誌
本文刊載於
網管人雜誌第 228 期 - 2025 年 1 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
在 2024 年 7 月，VMware 官方正式發佈最新 vSphere 8 Update 3 版本（如圖 1
所示），連帶底層虛擬化平台 ESXi 8 Update 3 版本一同推出。當然，現在 VMware
官方二個主要產品 VCF（VMware Cloud Foundation），和 VVF（VMware vSphere Foundation），皆整合在 VCF/VVF 5.2 版本中。
圖 1、最新 vSphere 8 Update 3 新功能示意圖
vSphere 8 Update3 亮眼新功能
在最新 vSphere 8 U3
版本中，新功能將針對提高企業和組織的營運效率及加速創新速度，同時提升工作負載效能和安全性為主軸。
ESXi Live Patching
在過去的虛擬化基礎架構中，無論採用哪一家虛擬化平台，都需要定期為虛擬化平台安裝安全性更新，除了相關臭蟲的修補之外，更需要抵抗日趨嚴重的網路安全威脅和不斷升高的惡意攻擊。
然而，在為虛擬化平台安裝安全性更新的流程中，除了必須將虛擬化平台上的 VM
虛擬主機和容器，進行中的工作負載遷移之外，當虛擬化平台套用安全性更新後，必須重新啟動虛擬化平台主機，待重新啟動完成後，管理人員確認安全性更新是否套用生效，確認無誤後，再將原本的
VM 虛擬主機和容器遷移回來繼續運作。
現在，全新推出的「ESXi Live Patching」機制，強調「即時升級」（Faster
Upgrades）和「無停機時間」（No Downtime），透過 ESXi Live Patching
即時修補功能，管理人員可以達成套用安全性更新至虛擬化平台中，而無須遷移 VM
虛擬主機等工作負載，並且虛擬化平台也無須重新啟動（如圖 2 所示）。
圖 2、ESXi Live Patching 即時修補操作畫面示意圖
圖 3、ESXi 虛擬化平台進入部份維護模式操作畫面示意圖
一旦企業或組織，需要評估最新 ESXi Live Patch
即時修補機制時，便需要注意整體運作細節，以避免影響企業和組織的營運服務。下列為
ESXi Live Patch 即時修補機制運作環境需求：
- 必須採用 vCenter Server 8.0 U3 或後續版本。
- 必須採用 vSphere ESXi 8.0 U3 或後續版本。
- 在 vSphere Lifecycle Manager 或 vSphere Cluster 組態設定中，必須啟用 Enforce Live Patch 選項。
- 在 vSphere Cluster 組態設定中，DRS 必須設定為「全自動模式」（Fully Automated Mode）
- 啟用 vSphere Fault Tolerance、啟用 DirectPath I/O devices 機制、掛載 Shared-Disk 的 Microsoft SQL Server VM、掛載和配置 TPM 裝置、擔任 vSphere Pods 角色、配置 DPU 的 vSphere Distributed Services Engine…… 等的 VM 虛擬主機，不支援 FSR 快速暫停恢復機制，管理人員必須透過 vSphere vMotion 機制，先行線上遷移至別台主機。
- 一旦 ESXi 虛擬化平台進入部份維護模式時，便不允許管理人員新增建立 VM 虛擬主機，也不允許執行 VM 虛擬主機線上遷移作業。
了解上述 ESXi Live Patch
即時修補機制的環境需求，以及相關限制條件之後，開始逐步拆解 ESXi Live Patch
即時修補機制的運作流程。首先，ESXi
主機進入部分維護模式，這個特殊狀態的運作模式，允許現有的 VM
虛擬主機能夠繼續運作不受干，但是進入部分維護模式的 ESXi
主機，不允許部署建立新的 VM 虛擬主機，或執行 vSphere vMotion 將 VM
虛擬主機進行線上遷移（如圖 4 所示）。
圖 4、ESXi 主機進入部分維護模式，線上 VM 虛擬主機繼續運作不受干擾
在 vSphere Lifecycle Manager
的協調運作下，載入含有最新安全性更新和臭蟲修補的版本，順利載入並掛載完成後，執行修補程序進行套用至
ESXi 虛擬化平台的動作（如圖 5 所示），當然，線上運作的 VM
虛擬主機工作負載不受任何影響。
圖 5、載入和套用含有最新安全性更新和臭蟲修補的版本
線上運作的 VM 虛擬主機，透過 FSR
快速暫停恢復機制，改為切換運作在套用最新安全性更新和臭蟲修補的版本上（如圖 6
所示），管理人員再手動將不支援 FSR 快速暫停恢復機制的 VM 虛擬主機，透過
vSphere vMotion 機制線上遷移回來，順利達成修補 ESXi 虛擬化平台，並且不影響
VM 虛擬主機工作負載的目的。
圖 6、VM 虛擬主機透過 FSR 機制，運作在已套用最新安全性更新版本上
值得注意的是，ESXi Live Patch
即時修補機制並非支援所有更新，舉例來說，在目前的安全性更新中，倘若需要更新或修補
VMkernel 時，尚未支援採用 ESXi Live Patch
即時修補機制，這表示管理人員仍需要採用過往舊有的更新方式才行。
因此，在採用 ESXi Live Patch 即時修補機制之前，建議管理人員先透過 vSphere
Lifecycle Manager
進行檢查作業，確保即將套用的安全性更新或臭蟲修補，與目前的 ESXi
運作版本相容，舉例來說，最新釋出的 vSphere 8.0 U3a 23658840
版本，僅支援及相容於 vSphere 8.0 U3 23653650 版本（如圖 7 所示）。
圖 7、ESXi Live Patch 即時修補機制必須採用支援且相容的版本
圖 8、啟用 vSphere Fault Tolerant 機制的 VM 虛擬主機不支援 FSR
快速暫停恢復機制
vSphere 分佈式服務引擎支援雙 DPU
在 vSphere 8.0 版本發佈時，隨著因應 AI 人工智慧和 ML
機器學習的興趣，企業和組織也開始慢慢認知，單靠運算資源的 CPU 和
Memory，以及負責圖形運算的
GPU，固然可以達成特定效果，然而多台主機之間要組成大型規模叢集時，底層需要傳輸大量資料的網路資源也必須跟上才行，所以官方推出「資料處理單元」（Data
Processing Unit，DPU）。
然而，在 vSphere 8.0 版本時，每台 ESXi 主機上的「vSphere
分佈式服務引擎」（Distributed Services Engine，DSE），僅支援採用一個 DPU
。現在，最新的 vSphere 8 U3 版本中，vSphere 分佈式服務引擎正式支援雙
DPU，以便增強虛擬化環境的安全性、彈性和高可用性。
管理人員在使用雙 DPU
架構時，可以採用兩種組態配置，一種是「Active/Standby」架構（如圖 9
所示），管理人員可以在 HA 組態設定中，將兩個 DPU 指定給同一個 NSX
當中，所支援的同一台 vDS 分佈式虛擬交換器，舉例來說，Active DPU 連接到 NSX
vDS 的 vmnic0 和 vmnic1，而 Standby DPU 連接到相同台 NSX vDS 的 vmnic2 和
vmnic3，那麼當 ESXi 主機上 Active DPU 發生故障損壞事件時，確保 Standby DPU
可以無縫接手原有的工作負載並繼續運作。
圖 9、vSphere 分佈式服務引擎支援雙 DPU 的 Active/Standby 架構示意圖
另一種則是採用「Full Isolation」架構（如圖 10 所示），將每個 DPU
都連接至獨立的 vDS 分佈式虛擬交換器，能讓每台 ESXi 主機的 DPU
卸載容量加倍，值得注意的是此架構雖然提升卸載容量，但是卻會犧牲 DPU
的高可用性，至於採用 VMware Cloud
Foundation（VCF）的企業和組織，則只要採用「5.2」版本即可開始支援雙 DPU
架構。
圖 10、vSphere 分佈式服務引擎支援雙 DPU 的 Full Isolation 架構示意圖
圖 11、vLCM 確保主機上的兩個 DPU 採用相同的 ESXi 版本
不斷改進的 vCenter RDU
事實上，從 vSphere 7 U3 版本開始，官方便開始將用於 VMC on AWS
公有雲環境中，vCenter Server 管理平台的版本更新和升級機制落地，由 Project
Arctic 專案演化而來的 API-Driven
技術，能夠落地至企業和組織的地端資料中心內，也就是 vCenter Server
Reduced Downtime Upgrade（RDU） 特色功能，讓 vCenter Server
管理平台，能夠在執行安全性更新或版本升級時，將整體的停機時間最大化限縮，在最新發佈的
vSphere 8 U3 版本中，甚至將版本更新或升級作業程序的停機時間限縮在「2 –
5」分鐘之內。
那麼，在新版本 vSphere 8 U3 中，vCenter RDU 機制有哪些增強功能
？首先，是支援新的拓撲機制，針對「增強型連結模式」（Enhanced Link Mode）的
vCenter 管理平台，即便現在處於同一個 SSO 網域的多台 vCenter
管理平台，也都可以透過 vCenter RDU 機制進行快速更新。
此外，在過去的 vCenter RDU
機制中，管理人員必須在進行更新動作之前，手動停用 vCenter HA
高可用性機制，待更新動作完成後，再手動重建 vCenter HA
高可性機制。現在，最新的 vCenter RDU 更新機制，已經能夠和 vCenter HA
高可性機制協同運作，無須管理人員手動介入。
在過去的 vCenter RDU 更新機制中，切換至新版本 vCenter
管理平台的動作，只能管理人員手動執行進行切換。現在，增強後的新版 vCenter
RDU 更新機制，支援自動切換功能（如圖 12
所示），一旦完成版本更新作業便自動進行切換，無須管理人員手動操作介入處理。
圖 12、新版 vCenter RDU 更新機制支援自動切換功能
獨立且脫勾的 TKG 服務
在過去版本中，Tanzu Kubernetes Grid（TKG）必須和 vSphere 版本對應，這會導致 TKG 和上游的 Kubernetes 版本不一致的情況。現在，新版 vSphere 中的 TKG 能夠獨立且脫勾運作（如圖 13 所示），便能和上游 Kubernetes 版本保持一致，並具備獨立的發佈週期，確保 TKG 服務能夠擁有最新功能，以及臭蟲修復和安全性更新。
圖 13、新版 vSphere 支援運作獨立且脫勾的 TKG 服務
此外，也允許進行非同步更新，讓企業和組織的管理人員能夠依照步調自行更新，減少中斷時間確保連續運作。當然，還是能夠透過 vSphere 管理 TKG 版本，以便簡化管理流程，提供 Kubernetes 基礎架構和容器部署及調度，提升地端資料中心維護效率。
支援 Intel Xeon CPU Max 系列處理器
在最新 Intel Xeon CPU Max 系列處理器，由於在 CPU 處理器中嵌入 High-Bandwidth Memory（HBM），因此能有效提升 AI/ML 類型的工作負載，以及其它 HPC 應用程式需求，舉例來說，在 Intel Sapphire Rapids 系列處理器中，便包含四個 On-Chip 加速器（如圖 14 所示）。此外，Intel 已經開發並提供，專門針對 QAT 和 DLB，用於 vSphere 運作環境的原生驅動程式。
圖 14、新版 vSphere 支援 Intel Xeon CPU Max 系列處理器
實戰 – 新版 vCenter RDU 更新機制
檢查產品相容性
在本文實作環境中，將從原有舊版 vCenter 8.0 版本（如圖 15 所示），透過 vCenter RDU 更新機制，升級更新至最新的 vCenter 8.0 U3 版本。請先下載最新版本的 vCenter Server 8.0 U3 版本 ISO 映像檔，並上傳至舊版 vCenter 8.0 能夠掛載的儲存資源中，然後組態設定掛載新版 vCenter Server 8.0 U3 ISO 映像檔。值得注意的是，在掛載時記得勾選「Connected」和「Connect At Power On」選項，避免看似掛載 ISO 映像檔成功卻無法使用的情況。
圖 15、現有環境中舊版 vCenter Server 8.0 管理平台
在 vCenter 管理介面中，請依序點選「vCenter Server > Updates」，在 Update 區塊中，可以看到 1. Target Version 階段中，將顯示目前 vCenter 管理平台版本資訊，點選 Target version 欄位中的 Select Version 連結，在彈出視窗中將顯示相容版本更新的 vCenter 版本，建議管理人員選擇上傳的 ISO 映像檔版本，以避免透過網際網路下載最新版本，浪費等待時間和網路頻寬。
此時，系統將自動執行來源檢查作業，一旦檢查作業完成後，請手動點選 Product Interoperability 頁籤，確保新版 vCenter 管理平台和底層 ESXi 虛擬化平台版本相容（如圖 16 所示）。
圖 16、確保新版 vCenter 管理平台和底層 ESXi 虛擬化平台版本相容
在 2. Backup 階段中，系統會再次提醒管理人員，執行 vCenter 版本升級前，應再次確認是否有良好的前次備份，避免版本升級過程中，倘若發生非預期錯誤時，還能透過先前良好的完整備份快速進行復原作業。
升級 LCM 生命週期管理員
在 3. Prepare source 階段中，系統提醒一旦 vCenter 管理平台版本升級後，將會連帶 Life-Cycle Manager（LCM） 生命週期管理員一起升級。請按下 Update Plugin（如圖 17 所示），執行 LCM Plugin 版本更新作業，當版本更新工作任務完成後，系統將自動重新整理管理頁面，重整後的 vCenter 圖形管理介面，將因 LCM Plugin 版本更新後而有些許改變，系統也會提示必須再次執行檢查作業，才能往下一個版本更新階段。
圖 17、更新 LCM 生命週期管理員
部署新版 vCenter 運作環境
在 4. Target Appliance 階段中，必須部署及組態設定新版 vCenter 管理平台的運作環境，請按下 Configure Target Appliance 進行組態設定。原則上，部署版本更新的 vCenter 工作流程，和初始建構 vCenter 管理平台流程相同，在 1. License Agreement 使用者授權協議畫面中，請勾選「I accept…」選項，在 2. CEIP 項目中，請勾選「Join the…」選項，確保後續相關特色功能持續運作。
在 3. Target Location 項目中，選擇「Deploy in the same location as source」選項時，系統會將新舊版本的 vCenter 管理平台，部署在同一台 ESXi 虛擬化平台上運作，選擇「Deploy in the different location as source」選項時，則會部署至其它台 ESXi 虛擬化平台，並且需要鍵入 ESXi 的主機名稱和管理帳密（如圖 18 所示）。
圖 18、決定部署新版 vCenter 在同一台或不同台 ESXi 虛擬化平台上
在 4. Deployment Type 項目中，選擇「Same Configuration」選項時（如圖 19 所示），部署的新版 vCenter 管理平台，將會完全採用舊有 vCenter 管理平台的組態設定，倘若管理人員需要調整新版 vCenter 管理平台組態設定時，例如，調整 vCenter 管理平台的 Size 規模、設定 vCenter 存放在不同資料夾、設定 vCenter 存放在不同 Datastore 儲存資源 …… 等，請點選「Detailed Configuration」選項即可。
圖 19、新版 vCenter 採用舊有組態設定或進行調整
在 5. VM Appliance details 項目中，請鍵入新版 vCenter 管理平台的 VM 虛擬主機名稱，以及暫時的 root 管理密碼。值得注意的是，VM 虛擬主機名稱避免使用「%」、「/」、「\」這幾個字元，否則將會發生非預期的錯誤，至於root管理密碼的部份除了必須符合複雜性原則之外，密碼的總長度不能超過「20」個字元。
在 6. Network Settings 項目中，鍵入部署新版 vCenter 網路組態設定內容（如圖 20 所示），例如，FQDN、IP位址 …… 等，值得注意的是，這裡鍵入的 FQDN 和 IP 位址皆為暫時用途。在 8. Review 項目中，再次檢視相關組態設定是否正確無誤，確認無誤後按下 Finish 鈕即可。
圖 20、鍵入新版 vCenter 網路組態設定內容
在 5. Upgrade 階段中，至此為止新版 vCenter 的預先部署和組態設定已經完成，管理人員只要選擇「Manual Switchover」選項，採用人工手動執行切換，或是選擇「Automated Switchover」選項（如圖 21 所示），在版本更新工作任務完成後，便自動執行切換作業。
圖 21、設定 vCenter 版本升級完成後手動切換或自動切換
現在，vCenter 版本更新的所有前置作業完成，只要按下 Start Upgrade 便立即執行，部署新版 vCenter 和複寫資料的動作，從 vCenter 管理介面下方工作項目清單中可以看到，系統開始自動部署新版 vCenter 管理平台（如圖 22 所示），組態設定新版 vCenter 後 Power On 開機，接收舊有 vCenter 資料，包括，vCenter 資料庫、組態設定、TLS/SSL 憑證 …… 等，此時舊有 vCenter 管理平台仍持續運作中，不受任何影響也尚未產生停機時間。
圖 22、系統開始部署新版 vCenter 管理平台
事實上，在部署新版 vCenter 管理平台時，即便發生部署失敗或版本更新失敗的情況，管理人員也無須擔心，系統會自動把失敗的新版 vCenter 虛擬主機斷電後刪除，整個系統環境自動恢復到原有的運作狀態。
手動或自動切換至新版 vCenter
在前述階段中選擇「Manual Switchover」選項時，一旦新版 vCenter 部署的工作任務完成後，此時的「SWITCHOVER」鈕便轉變為可執行狀態，執行切換動作後，系統便會正式將舊版 vCenter 組態設定，複寫套用至新版 vCenter 管理平台，相關系統服務也將正式啟動，以便回應各項管理操作。
選擇「Automated Switchover」選項時，則是將上述這一切交由系統自動執行切換動作。值得注意的是，vCenter 管理平台的停機時間，只發生在執行切換或手動按下 Switchover 鈕，開始執行切換工作任務，當系統確保新舊 vCenter 管理平台資料一致後，便會將舊有 vCenter 管理平台關機，新版 vCenter 管理平台開始接手，舊有 vCenter 管理平台的 FQDN、IP 位址、TLS/SSL 憑證、啟動系統服務 …… 等（如圖 23 所示）。
圖 23、新舊版本 vCenter 管理平台進行切換的工作任務
切換工作任務完成後，系統通知新版 vCenter 管理平台接手完成，可以使用新的 vCenter 管理平台，開始操作進行管理維護作業（如圖 24 所示）。
圖 24、新舊 vCenter 管理平台切換工作任務完成
現在，管理人員可以採用相同的 vCenter FQDN 和管理帳號及密碼登入，除了 vCenter VM 虛擬主機名稱改變之外（如圖 25 所示），其餘不變組態設定和 VM 虛擬主機的效能統計資訊 …… 等都在。此時，也建議管理人員應立即為新版 vCenter 執行備份工作任務，並將舊版 vCenter 虛擬主機的網路連接選項取消後，轉換為 VM Template 範本檔存放，避免不小心誤操作將舊版 vCenter 開機造成網路衝突的情況。
圖 25、順利從 vCenter 8 升級為最新 vCenter 8 U3 版本
結語
透過本文的深入剖析和實戰演練後，相信管理人員除了理解新版 vSphere 8 U3 的新功能外，對於 vCenter RDU 更新機制有更深一層的認識，並且能快速應用在所管理的 vCenter 管理平台中，輕鬆達到 vCenter 管理平台版本更新的工作任務。
