vSphere 8 U3亮點速寫　實戰新版RDU更新機制

在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版本中。

vSphere 8 Update3亮眼新功能介紹

在最新vSphere 8 U3版本中，新功能將針對提高企業組織的營運效率及加速創新速度，同時提升工作負載效能和安全性為主軸。

ESXi Live Patching

在過去的虛擬化基礎架構中，無論採用哪一家虛擬化平台，都需要定期為虛擬化平台安裝安全性更新，除了相關臭蟲的修補外，更需要抵抗日趨嚴重的網路安全威脅和不斷升高的惡意攻擊。

然而，在為虛擬化平台安裝安全性更新的流程中，除了必須將虛擬化平台上的VM虛擬主機和容器進行中的工作負載遷移外，當虛擬化平台套用安全性更新後，必須重新啟動虛擬化平台主機，待重新啟動完成後，確認安全性更新是否套用生效，確認無誤後，再將原本的VM虛擬主機和容器遷移回來繼續運作。

全新推出的「ESXi Live Patching」機制，則強調「即時升級」（Faster Upgrades）和「無停機時間」（No Downtime），透過ESXi Live Patching即時修補功能，可以達成套用安全性更新至虛擬化平台中，而無須遷移VM虛擬主機等工作負載，並且虛擬化平台也無須重新啟動，如圖2所示。

管理人員可能好奇這一切是怎麼辦到的？簡單來說，虛擬化平台進入「部分維護模式」（Partial Maintenance Mode）後，如圖3所示，套用安全性更新進行修補作業，而其上運作的VM虛擬主機工作負載，則進入「快速暫停恢復」（Fast-Suspend-Resumed，FSR）狀態，達到修補虛擬化平台且VM虛擬主機工作負載持續運作的目的。

一旦企業或組織需要評估最新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所示。

在vSphere Lifecycle Manager的協調運作下，載入含有最新安全性更新和臭蟲修補的版本，順利載入並掛載完成後，執行修補程序進行套用至ESXi虛擬化平台的動作，如圖5所示，當然，線上運作的VM虛擬主機工作負載不受任何影響。

線上運作的VM虛擬主機，透過FSR快速暫停恢復機制，改為切換運作在套用最新安全性更新和臭蟲修補的版本上，如圖6所示，再手動將不支援FSR快速暫停恢復機制的VM虛擬主機，透過vSphere vMotion機制線上遷移回來，順利達成修補ESXi虛擬化平台，並且不影響VM虛擬主機工作負載的目的。

值得注意的是，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所示。

最後，再次提醒管理人員，由於ESXi虛擬化平台進入部分維護模式後，在套用安全性更新期間，便無法將VM虛擬主機線上遷移至別台主機，所以在執行ESXi Live Patch即時修補機制之前，務必先透過vSphere Lifecycle Manager進行檢查作業，如圖8所示，確保目前ESXi虛擬化平台上的VM虛擬主機皆支援稍後的FSR快速暫停恢復機制，倘若檢查出不支援FSR機制的VM虛擬主機時，應先透過vSphere vMotion線上遷移至別台主機，以避免後續造成非預期的影響。

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無縫接手原有的工作負載並繼續運作。

另一種則是採用「Full Isolation」架構，如圖10所示，將每個DPU都連接至獨立的vDS分佈式虛擬交換器，能讓每台ESXi主機的DPU卸載容量加倍。值得注意的是，此架構雖然提升卸載容量，但卻會犧牲DPU的高可用性，至於採用VMware Cloud Foundation（VCF）的企業組織則只要採用「5.2」版本即可開始支援雙DPU架構。

此外，在vSphere 8 U3版本中的vSphere Lifecycle Manager（vLCM），也同步支援雙DPU架構。在安裝和管理DPU上的ESXi映像檔操作體驗和過去相同，vLCM在安裝及部署ESXi至DPU時，將會確保主機上的兩個DPU採用相同的ESXi版本，如圖11所示，避免發生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所示，一旦完成版本更新作業，便自動進行切換，無須管理人員手動操作介入處理。

獨立且脫勾的TKG服務

在過去版本中，Tanzu Kubernetes Grid（TKG）必須與vSphere版本對應，這會導致TKG和上游的Kubernetes版本不一致的情況。新版vSphere中的TKG則能夠獨立且脫勾運作，如圖13所示，便能與上游Kubernetes版本保持一致，並具備獨立的發布週期，確保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運作環境的原生驅動程式。

實作vCenter RDU更新機制

接下來，就開始實戰新版vCenter RDU的更新機制。

檢查產品相容性

在本文實作環境中，如圖15所示，將從原有舊版vCenter 8.0版本，透過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映像檔成功卻無法使用的情況。

在vCenter管理介面中，依序點選「vCenter Server > Updates」，在Update區塊內可以看到1. Target Version階段中將顯示目前vCenter管理平台版本資訊，接著點選Target version欄位中的Select Version連結，在彈出視窗中將顯示相容版本更新的vCenter版本，建議選擇上傳的ISO映像檔版本，以避免透過網際網路下載最新版本而浪費等待時間和網路頻寬。

此時，系統將自動執行來源檢查作業，一旦檢查作業完成後，手動點選Product Interoperability頁籤，確保新版vCenter管理平台和底層ESXi虛擬化平台版本相容，如圖16所示。

在2. Backup階段中，系統會再次提醒，執行vCenter版本升級前，應再次確認是否有良好的前次備份，避免版本升級過程中若發生非預期錯誤時，還能透過先前良好的完整備份快速進行復原作業。

升級LCM生命週期管理員

在3. Prepare source階段中，系統提醒一旦vCenter管理平台版本升級後，將會連帶Life-Cycle Manager（LCM）生命週期管理員一起升級。按下Update Plugin，如圖17所示，執行LCM Plugin版本更新作業，當版本更新工作任務完成後，系統會自動重新整理管理頁面，重整後的vCenter圖形管理介面，將因LCM Plugin版本更新後而有些許改變，系統也會提示必須再次執行檢查作業，才能往下一個版本更新階段。

部署新版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所示。

在4. Deployment Type項目中，選擇「Same Configuration」選項時，如圖19所示，部署的新版vCenter管理平台，將會完全採用舊有vCenter管理平台的組態設定。若需要調整新版vCenter管理平台組態設定時，例如調整vCenter管理平台的Size規模、設定vCenter存放在不同資料夾、設定vCenter存放在不同Datastore儲存資源等等，則點選「Detailed Configuration」選項即可。

在5. VM Appliance details項目中，鍵入新版vCenter管理平台的VM虛擬主機名稱，以及暫時的root管理密碼。值得注意的是，VM虛擬主機名稱避免使用「%」、「/」、「\」這幾個字元，否則會發生非預期的錯誤。至於root管理密碼的部分，除了必須符合複雜性原則之外，密碼的總長度不能超過「20」個字元。

在6. Network Settings項目中，則鍵入部署新版vCenter網路組態設定內容，如圖20所示，例如FQDN、IP位址等等，必須注意的是，這裡鍵入的FQDN和IP位址皆為暫時用途。而在8. Review項目中，再次檢視相關組態設定是否正確無誤，確認無誤後按下〔Finish〕鈕即可。

在5. Upgrade階段中，至此為止，新版vCenter的預先部署和組態設定已經完成，只要選擇「Manual Switchover」選項，採用人工手動執行切換，或是選擇「Automated Switchover」選項，如圖21所示，在版本更新工作任務完成後，便會自動執行切換作業。

現在vCenter版本更新的所有前置作業完成，只要按下Start Upgrade便立即執行部署新版vCenter和複寫資料的動作。從vCenter管理介面下方工作項目清單中可以看到，系統開始自動部署新版vCenter管理平台，如圖22所示，組態設定新版vCenter後Power On開機，接收舊有vCenter資料，包括vCenter資料庫、組態設定、TLS/SSL憑證等等。此時，舊有vCenter管理平台仍持續運作中，不受任何影響也尚未產生停機時間。

事實上，在部署新版vCenter管理平台時，即便發生部署失敗或版本更新失敗的情況，管理人員也無須擔心，系統會自動把失敗的新版vCenter虛擬主機斷電後刪除，整個系統環境自動恢復到原有的運作狀態。

手動或自動切換至新版vCenter

在前述階段中選擇「Manual Switchover」選項時，一旦新版vCenter部署的工作任務完成後，此時的〔SWITCHOVER〕鈕便轉變為可執行狀態。執行切換動作後，系統便會正式將舊版vCenter組態設定複寫套用至新版vCenter管理平台，相關系統服務也將正式啟動，以便回應各項管理操作。

選擇「Automated Switchover」選項時，則是將上述這一切交由系統自動執行切換動作。值得注意的是，vCenter管理平台的停機時間，只發生在執行切換或手動按下〔SWITCHOVER〕鈕，開始執行切換工作任務，當系統確保新舊vCenter管理平台資料一致後，便會將舊有vCenter管理平台關機，新版vCenter管理平台開始接手舊有vCenter管理平台的FQDN、IP位址、TLS/SSL憑證、啟動系統服務等等，如圖23所示。

切換工作任務完成後，系統通知新版vCenter管理平台接手完成，可以使用新的vCenter管理平台開始操作進行管理維護作業，如圖24所示。

現在管理人員可以採用相同的vCenter FQDN和管理帳號及密碼登入，除了vCenter VM虛擬主機名稱改變之外，如圖25所示，其餘不變組態設定和VM虛擬主機的效能統計資訊等等都在。

此時，也建議應立即為新版vCenter執行備份工作任務，並且將舊版vCenter虛擬主機的網路連接選項取消後，轉換為VM Template範本檔存放，避免不小心誤操作將舊版vCenter開機而造成網路衝突的情況。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞