網管人雜誌
本文刊載於
網管人雜誌第 216 期 - 2024 年 1 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
最初的 vSphere 8 版本在 2022 年 10 月發佈，經過六個月後發佈 vSphere 8 Update 1 版本，最新的 vSphere 8 Update 2 版本，則是在 2023 年 VMware Explore 大會中正式發佈（如圖 1 所示）。事實上，管理人員可以察覺，即便 VMware 每六個月便發佈新版本，然而每一版更新並非僅是功能增強或臭蟲更新，反而包含許多新增特色功能。在本文中，將逐一剖析各項亮眼特色功能，並且實戰演練最新發佈的 vCLS 撤退機制，讓企業和組織的管理人員，能夠更輕鬆管理 vCLS 叢集服務。
圖 1、隨著 VMware Explore 2023 大會發佈的最新 vSphere 8 U2 版本
vSphere 8 U2 亮眼特色功能
減少新版升級停機時間
在 VMware 運作架構中，許多特色功能或進階功能，都圍繞在 vCenter Server 管理平台中。然而，只要是軟體產物便需要進行安全性更新、臭蟲修補、版本升級……等，一旦 vCenter 執行安全性更新、臭蟲修補、版本升級等工作任務時，便會處於離線狀態從而產生「停機時間」（Downtime）。
雖然，vCenter 管理平台產生停機時間時，對於上層的 VM 虛擬主機或容器等工作負載，並不會造成營運服務中斷或無法運作的情況，但此時因為 vCenter 處於離線狀態，而無法執行許多進階功能。
因此，在最新 vSphere 8 U2 版本中，將 vSphere+ 雲端環境的 vCenter 更新機制（如圖 2 所示），下放到地端 vCenter 管理平台中，以便減少 vCenter 因為更新而造成的停機時間，那麼 vSphere+ 雲端和原有地端環境更新機制有什麼不同之處呢？
圖 2、vSphere+ 雲端環境的 vCenter 更新機制流程示意圖
簡單來說，vSphere+ 更新機制的重點為「遷移」（Migration-Base），在更新動作執行時，先部署新的 vCenter，並將原有 vCenter 的資料和組態設定配置，複製到新部署的 vCenter 當中，其實這樣的機制類似於地端 vCenter 跨大版本升級作業。
然而，這之間的主要差別在於，新舊 vCenter 資料和組態設定複製階段期間，原有 vCenter 的所有服務仍正常運作，管理人員仍能透過 vCenter，執行相關進階特色功能並管理虛擬化基礎架構，整個流程中唯一會發生 vCenter 停機的時間點，就是資料和組態設定複製階段完成後，原有 vCenter 停止服務，由新部署的 vCenter 接手並啟動服務，原則上來說通常在五分鐘之內完成，這和過往地端 vCenter 的停機時間相比大量減少許多。
新式更新機制共有如下五個步驟，並且管理人員也可以在實際更新期間，查看工作任務的執行進度（如圖 3 所示）：
1. 掛載 ISO 映像檔： 將準備部署新版本的 vCenter ISO 映像檔進行掛載。值得注意的是，這個 ISO 映像檔是完整的安裝 ISO 映像檔，而非安全性更新或修補臭蟲的 ISO 映像檔。
2. 檢查備份： 系統將檢查和確認，原有運作中的 vCenter 管理平台，是否已經執行備份工作任務。
3. 更新外掛程式： 系統將在原有 vCenter 管理平台中，更新 vCenter 生命週期服務，以便後續部署新的 vCenter 管理平台，這也是更新機制對於原有 vCenter 的唯一變更。
4. 組態設定新的 vCenter： 針對新部署的 vCenter 進行組態設定，包括，VM 虛擬主機名稱、臨時的 root 管理帳號密碼、臨時的 vNetwork 虛擬網路設定……等，管理人員可以選擇繼承原有 vCenter 組態設定，也可以選擇自行組態設定。預設情況下，新部署的 vCenter，將會繼承原有 vCenter 的 root 管理帳號密碼和網路身份驗證。
5. 升級與執行切換： 一旦新部署的 vCenter 複製和組態設定完畢，並且兩台 vCenter 都保持正常運作狀態時，管理人員便能決定何時執行切換作業，原則上可以立即執行切換 vCenter 的工作任務，也可以排程設定一天後或一週後都可以。值得注意的是，切換期間原有 vCenter 停止服務，新部署的 vCenter 接手並啟動服務，通常還是未產生五分鐘之內的停機時間。
圖 3、新式 vCenter 更新機制操作畫面示意圖
可靠的網路組態設定復原機制
無論企業和組織，針對 VMware 虛擬化基礎架構部署多少高可用性機制，在面對意外的災難事件時，仍有可能需要最後一道防線「備份 / 還原」。然而，執行備份作業時，通常也僅是針對當時的資料和組態設定進行備份，但是備份作業完成後，仍然會有其中工作任務執行，例如，新增 / 修改 / 刪除 VM 虛擬主機，新增 / 修改 / 刪除 vNetwork 虛擬網路……等。
因此，雖然管理人員在遭遇意外災難事件後，選擇最接近的備份時間點進行還原後，仍然需要處理這些備份後至災難發生期間的組態設定值，舉例來說，備份作業完成後，新增 / 修改 / 刪除 vNetwork 虛擬網路，還原後則仍需要管理人員手動處理這些 vNetwork 的異動作業。
現在，最新 vSphere 8 U2 版本中，將「分散式鍵值儲存」（Distributed Key-Value Store）機制擴充，包含 vSphere 和 NSX 中的 vDS 分散式虛擬網路交換器組態設定。因此，當災難發生並執行還原作業後，在 vSphere 叢集中 ESXi 主機的最新 vDS 分散式虛擬網路交換器組態設定資訊，將會自動被推送到還原後的 vCenter 資料庫內（如圖 4 所示），所以管理人員便無須於還原作業後，手動更新 vDS 分散式虛擬網路交換器組態設定。
圖 4、vCenter 可靠網路組態設定復原機制運作流程示意圖
最佳化放置 GPU 工作負載
企業和組織為了因應這波 AI 浪潮，紛紛在虛擬化環境中部署 vGPU 環境，以便加快 ML 機器學習和 LLM 大型語言模型的訓練和調校。雖然，在透過 vGPU 機制，可以有效將 2、4、8 個 vGPU 圖形運算資源，分配給 VM 虛擬主機使用，甚至最新 vSphere 8 U2 版本，可以支援最大指派 16 個 vGPU 圖形運算資源給 VM 虛擬主機，以便最大化使用 GPU 資源並縮短 AI 模型的訓練和調校時間。
然而，和過往 VM 虛擬主機會碰到的資源碎片問題相同，環境中配置不同資源大小的 vGPU 虛擬主機時，這種情況便更容易發生，一旦發生資源碎片的問題時，便可能造成雖然整體 vSphere 叢集，還有足夠的 vGPU 資源，但是新部署的 vGPU 虛擬主機卻無法使用並順利啟動。
舉例來說，運作環境中有三台 ESXi 虛擬化平台，每台 ESXi 共有四個實體 GPU 圖形運算資源，並且每台 ESXi 虛擬化平台上，已經分別運作一台配置 2 vGPU 虛擬主機。此時，新的專案需要一台配置 4 vGPU 虛擬主機，雖然整體 vSphere 叢集仍有 6 vGPU 圖形運算資源，但是並沒有任何一台 ESXi 虛擬化平台，擁有足夠運作一台 4 vGPU 虛擬主機的圖形運算資源（如圖 5 所示）。此時，這台新增部署的 4 vGPU 虛擬主機，便會處於等待放置狀態且無法開機運作。
圖 5、實體 GPU 圖形運算資源碎片問題示意圖
因此，在新版 vSphere 8 U2 版本中，新增 GPU 最佳化放置機制，以便解決實體 GPU 圖形運算資源碎片問題。舉例來說，上述 GPU 資源碎片問題發生時，管理人員只需要組態設定 vSphere 叢集中，新增「VgpuVmConsolidation = 1」進階功能參數，系統便會將 vGPU 資源大小相同的 VM 虛擬主機，遷移到同一台 ESXi 虛擬化平台上，同時搭配「LBMaxVmotion = 1」進階功能參數，還可以避免 ESXi 虛擬化平台，觸發執行多次 vGPU 虛擬主機 vMotion 遷移事件。更多最佳化放置 vGPU 圖形運算資源，進階功能參數的詳細資訊，請參考 VMware KB88271、KB66813 知識庫文章。
因此，一旦管理人員將上述二項進階功能參數，組態設定至 vSphere 叢集時，系統便會遷移組態定2 vGPU 虛擬主機，到同一台 ESXi 虛擬平台上，從而空出完整支援 4 vGPU 虛擬主機的資源，讓新增部署的 4 vGPU 虛擬主機，能夠成功放置並順利開機運作（如圖 6 所示），以便充分利用 vSphere 叢集中的 GPU 圖形運算資源。
圖 6、最佳化放置 vGPU 圖形運算資源示意圖
VM 虛擬主機最新虛擬硬體版本 v21
在每一版的 VM 虛擬主機虛擬硬體版本中，除了擴充原有支援限制之外，也同步新增支援各種硬體，以便因應各種現代化工作負載。在最新 vSphere 8 U2 版本中，開始支援最新 VM 虛擬硬體版本 v21（如圖 7 所示）。
圖 7、最新 VM 虛擬硬體版本 v21 增強或新增功能示意圖
在最新 VM 虛擬硬體 v21 版本中，增強或新增支援 VM 虛擬主機虛擬硬體項目如下：
- 每台 VM 虛擬主機，支援組態設定最多使用 16 vGPU 圖形運算資源。
- 每台 VM 虛擬主機，支援組態設定最多 4 個 vNVMe 儲存控制器，每個 vNVMe 儲存控制器支援掛載 64 個 vNVMe 儲存裝置，總共支援掛載 256 個 vNVMe 儲存裝置。
- 針對 Windows 11 和 Windows Server 2022 客體作業系統，新增支援 NVMe 1.3 。
- 在 WSFC 容錯移轉叢集運作架構中，新增支援 NVMe 儲存裝置。
- 支援安裝最新的 RHEL 10、Oracle Linux 10、Debian 13 和 FreeBSD 15 的客體作業系統。
VM 服務正式支援 Windows 虛擬主機
在前一版 vSphere 8 U1 版本中，新增支援「VM 服務」（VM Service）機制，並支援從內容庫部署自訂的 Linux VM 虛擬主機。
在最新 vSphere 8 U2 版本中，VM 服務正式支援 Windows VM 虛擬主機（如圖 8 所示）。因此，管理人員或開發人員，可以透過 kubectl 指令部署 Windows VM 虛擬主機到命名空間，並且搭配標準的 SysPrep 格式的自定義檔案，客製化企業和組織需要的 Windows VM 虛擬主機運作環境。
圖 8、VM 服務正式支援 Windows VM 虛擬主機運作示意圖
NSX ALB 負載平衡機制成為主流
事實上，VMware 官方宣佈從 NSX-T Data Center 3.2.0 版本開始，過往的 NSX-T LB（Load Balancer）負載平衡機制將被棄用，並在後續的新版本將完全從內建清單中刪除。
因此，從 NSX 4.x 版本開始，或 vSphere with Tanzu 中的 Supervisor Cluster 運作環境，都建議使用 NSX ALB（Advanced Load Balancer）負載平衡機制（如圖 9 所示），取代過往且已經棄用的 NSX-T LB 負載平衡機制，以便更容易整合及維護管理，vSphere vDS 分散式虛擬網路交換器和網路堆疊。
圖 9、NSX ALB（Advanced Load Balancer）負載平衡機制運作示意圖
實戰演練 – vCLS 叢集服務撤退模式
在過去 vSphere 7 U1 版本中，VMware 官方正式發佈 vCLS（vSphere Clustering Services）特色功能，為原本的 vSphere 叢集服務，新增建立「分佈式控制平面」（Distributed Control Plane）的第一個版本，以便將 vSphere 叢集服務和 vCenter 進行脫勾（如圖 10 所示）。
圖 10、vCLS 叢集服務運作架構示意圖
在 vSphere 基礎架構中，一旦 vCenter 管理平台發生災難事件時，上層運作的 VM 虛擬主機和容器等工作負載，雖然不會受到任何影響並持續正式運作，但是管理人員也因為 vCenter 的損壞，而無法對 VM 虛擬主機和容器等工作負載進行任何的管理任務。
然而，在 vCenter 管理平台尚未恢復期間，雖然 vSphere HA（High Availability）高可用性，仍然能夠正常運作，但是 vSphere vMotion 線上遷移機制，或自動化遷移機制的 vSphere DRS（Distributed Resource Scheduler）……等其它機制，都將因為 vCenter 故障而無法運作。
這就是為什麼，VMware 官方推出 vCLS 叢集服務，讓 vSphere 叢集服務與 vCenter 脫勾，一旦 vCLS 叢集服務部署完成並正確運作後，當 vCenter 發生災難事件時，因為 vCLS 叢集服務會在 vSphere 叢集中，建立一至三台的 vCLS VM 虛擬主機，所以即便有部份 vCLS VM 虛擬主機受到影響，仍然能夠在 vCenter 尚未恢復時，讓自動化遷移 vSphere DRS 等進階功能繼續運作。詳細資訊請參考 VMware KB80472 知識庫文章。
在本小節中，將實戰演練舊版 vSphere 7 U3，手動執行「vCLS 撤退模式」（vCLS Retreat Mode），以及最新 vSphere 8 U2 版本中，新增圖形介面輕鬆操作 vCLS 撤退模式特色功能。
舊版 vCLS 叢集服務缺點
原則上，vCLS 叢集服務會讓原有 vSphere 叢集服務更穩定，並且和自動化遷移機制 vSphere DRS 互相協作配合。然而，有時可能因為某些因素或臭蟲，導致自動化遷移機制 vSphere DRS 無法正常運作，舉例來說，即便管理人員啟用 vSphere DRS，但是可能會發現 vSphere DRS 並沒有正常運作，不會自動化將 VM 虛擬主機遷移至其它工作負載低的 ESXi 虛擬化平台。
此外，也因為自動化遷移機制 vSphere DRS 無法正常運作，所以當災難事件發生觸發 vSphere HA 時，也將因為 vSphere DRS 最佳工作負載放置機制失效，雖然 vSphere HA 能夠順利把受影響的 VM 虛擬主機，重新在其它存活的 ESXi 虛擬化平台上開機，但是可能會產生工作負載放置極度不平均的狀態。詳細資訊請參考 VMware KB91891、KB79892 知識庫文章。
如何刪除舊版 vCLS
由於在舊版 vCLS 叢集服務運作環境中，預設所有的 vCLS VM 虛擬主機，是由「vSphere 叢集服務」（vSphere Cluster Service）所管理，因此當管理人員嘗試干預 vCLS VM 虛擬主機時，系統便會跳出警告資訊，說明無須管理人員介入，而是由 vSphere 叢集服務自動管理 vCLS VM 虛擬主機（如圖 11 所示）。
圖 11、舊版 vCLS 叢集服務，管理人員無法管理 vCLS VM 虛擬主機
然而，一旦發生 vCLS 叢集服務在運作上有臭蟲的情況發生時，此時由於管理人員無法介入管理 vCLS VM 虛擬主機，所以便會無法徹底執行，將 vCLS VM 虛擬主機刪除後重新部署的動作，以便嘗試修復 vCLS 叢集服務臭蟲的情況。
此時，可以嘗試手動組態設定 vCenter 管理平台，將所有納管的 vSphere Cluster 都進入「撤退模式」（Retreat Mode），達到刪除所有 vSphere Cluster 內的 vCLS VM 虛擬主機的目的，然後再重新部署 vSphere Cluster 內的 vCLS VM 虛擬主機。
請注意! 除非出現 vCLS 叢集服務出現臭蟲或運作失敗的情況，否則管理人員不應隨意組態設定撤退模式。
在刪除 vCLS VM 虛擬主機之前，確認目前 vCLS VM 虛擬主機的情況，請依序點選「VMs and Templates > vCLS > VMs」項目，即可看到目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊（如圖 12 所示）。
圖 12、目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊
請在 vCenter 管理介面中，點選希望刪除 vCLS VM 虛擬主機的 vSphere Cluster 後，查看 URL 內中間關鍵字「domain-c + <數字>」，舉例來說，本文實作環境為「domain-c8」（如圖 13 所示）。值得注意的是，這個數值必須正確，假設稍後組態設定撤退模式時填錯數值，將會造成 vpxd 服務啟動失敗。
圖 13、確認要刪除 vCLS VM 虛擬主機所在的 vSphere Cluster
複製完成後，請依序點選「vCenter > Configure > Settings > Advanced settings > Edit Settings」項目，在彈出的組態設定視窗中，請移至視窗最底部在 Name 欄位中，填入「config.vcls.clusters.domain-c8.enabled」，並在 Value 欄位填入「False」後，按下 Add 鈕新增組態設定，最後按下 Save 鈕套用生效。
原則上，在 30 秒之內系統便會自動執行刪除作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Initiate guest OS shutdown」和「Delete virtual machine」的刪除工作任務，完成後可以看到在 vSphere Cluster 內，所有的 vCLS VM 虛擬主機已經刪除完畢（如圖 14 所示）。
圖 14、系統自動刪除 vSphere Cluster 內所有 vCLS VM 虛擬主機
接著，便可以回到剛才的組態設定視窗，點選 Name 頁籤中的過濾關鍵字圖示，鍵入「vcls」關鍵字後，即可找到剛才新增的組態設定值，請將剛才新增的組態設定值中 Value 欄位，由原本的 False 修改為「True」後（如圖 15 所示），按下 Save 鈕套用生效。
圖 15、修改 Value 組態設定值重新部署 vCLS VM 虛擬主機
同樣的，在 30 秒之內系統便會自動執行重新部署作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務，重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機（如圖 16 所示）。
圖 16、系統自動重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機
新版直接支援 vCLS 撤退模式
原則上，只要是採用 vSphere 8.0 U2 之前的版本，即便是前一版的 vSphere 8.0 U1，都只能使用上述方法組態設定，刪除和重新部署 vCLS VM 虛擬主機。在最新 vSphere 8.0 U2 版本中（如圖 17 所示），直接支援組態設定 vSphere Cluster 進入撤退模式。
圖 17、最新 vSphere 8 U2 版本，直接支援 vSphere Cluster 撤退模式
新版重新部署 vCLS VM 虛擬主機
因此，在最新 vSphere 8.0 U2 版本中，同樣出現 vCLS VM 虛擬主機運作異常或臭蟲的情況時，管理人員可以透過 vCenter 管理介面，直接為所屬的 vSphere Cluster 組態設定 vCLS 撤退模式。
同樣的，在刪除 vCLS VM 虛擬主機之前，確認目前 vCLS VM 虛擬主機的情況，請依序點選「VMs and Templates > vCLS > VMs」項目，即可看到目前 vSphere Cluster 內 vCLS VM 虛擬主機資訊（如圖 18 所示）。
圖 18、目前 vSphere 8 U2 Cluster 內 vCLS VM 虛擬主機資訊
請在 vCenter 管理介面中，依序點選「Cluster > Configure > vSphere Cluster Services > General > vCLS Mode > Edit vCLS Mode」項目，在彈出視窗中可以看到，預設情況下系統採用「System Managed」系統管理模式，當管理人員希望刪除 vCLS VM 虛擬主機時，請選擇至「Retreat Mode」撤退模式後，系統出現警告訊息再次提醒管理人員，應該在 vCLS 機制運作異常時才組態設定採用撤退模式，確認後按下 OK 鈕套用生效（如圖 19 所示）。
圖 19、選擇 Retreat Mode 撤退模式準備刪除 vCLS VM 虛擬主機
組態設定套用生效後，系統立即執行自動刪除作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Reconfigure cluster」、「Initiate guest OS shutdown」和「Delete virtual machine」的刪除工作任務，完成後可以在 vSphere Cluster 內看到，所有 vCLS VM 虛擬主機已經刪除完畢（如圖 20 所示）。
圖 20、系統自動刪除 vSphere Cluster 內所有 vCLS VM 虛擬主機
回到剛才 vCLS 模式組態設定視窗，改為選擇「System Managed」系統管理模式後，按下 OK 鈕套用生效。同樣的，系統立即自動執行重新部署作業，管理人員可以在 vCenter 管理介面中，看到系統自動執行「Reconfigure cluster > Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務，重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機（如圖 21 所示）。
圖 21、系統自動重新部署 vSphere Cluster 內所有 vCLS VM 虛擬主機
結語
透過本文的深入剖析和實作演練後，除了理解最新 vSphere 8 U2 版本的亮眼技術之外，也實作演練舊版 vSphere 7，以及新版 vSphere 8 U2 的 vCLS VM 虛擬主機管理作業，讓企業和組織的 vSphere 叢集能夠更穩定，不受 vCenter 故障所影響。
