本文將深入剖析讓管理人員理解最新vSphere 8 U1版本推出哪些亮眼功能，並透過實作vCP組態設定檔管理機制，幫助企業在管理vSphere叢集和ESXi節點主機時能夠輕鬆確保ESXi主機間組態設定一致性，同時避免人為疏忽造成的組態設定錯誤和故障排除時間。
在2022年10月時VMware官方發佈最新的vSphere 8版本，經過六個月之後，在2023年4月正式發佈vSphere 8 Update 1版本。最新的vSphere 8 Update 1版本並非僅是現有功能增強或臭蟲更新，而是包含了多項新增特色功能。本文將逐一剖析各式亮眼特色功能，並且實戰演練最新發佈的vCP組態設定檔機制。
vSphere 8 U1亮眼特色功能介紹
接著，說明vSphere 8 U1所提供的亮眼功能。
新世代vSphere組態設定檔機制
隨著企業和組織內各項專案和服務不斷成長，必須建立更多的VM虛擬主機和容器，以便提供高效能和高可用性的營運服務，因此vSphere叢集和ESXi節點主機數量也逐漸增加，然而維持vSphere叢集與其下每台ESXi節點主機組態設定一致性，卻是一件令管理人員困擾的事情。
雖然過去的vSphere版本針對此項管理需求推出Host Profiles機制，但並無法完全解決管理人員的困擾。因此，前一版的vSphere 8版本推出「vSphere組態設定檔」（vSphere Configuration Profiles，vCP）技術預覽版本，而最新的vSphere 8 Update 1則正式推出完整版本，如圖1所示。
圖1 新世代vCP（vSphere Configuration Profiles）組態設定檔機制運作示意圖。 （圖片來源：Introducing vSphere 8 Update 1 - VMware vSphere Blog）
簡單來說，雖然舊版的Host Profiles與新式的vSphere Configuration Profiles機制有點類似，但新世代vCP組態設定檔機制支援度和範圍更全面，並且支援將現有Host Profiles機制轉換為新世代的vCP組態設定檔機制，協助管理人員順利過渡到新式vCP組態設定檔機制。
vLCM正式支援獨立主機
在過去的vSphere版本當中，vLCM生命週期管理員機制，僅支援vSphere叢集和ESXi節點主機，並不支援尚未納入vSphere叢集的「獨立主機」（Standalone Host）。
現在最新的vSphere 8 U1版本中，vLCM生命週期管理員機制透過vSphere API與vCenter Server管理平台進行溝通，進而支援獨立主機。因此，過往在vSphere叢集和ESXi節點主機環境中，進行映像檔、修復、檢查合規性等等工作任務，現在也都可以針對ESXi獨立主機進行套用，如圖2所示。
圖2 vLCM生命週期管理員機制正式支援獨立主機。 （圖片來源：vSphere Lifecycle Manager for Standalone Hosts | VMware）
單一GPU支援不同工作負載
在過去的vSphere版本中，ESXi主機在組態設定NVIDIA vGPU工作負載時，必須使用相同的vGPU組態設定和記憶體大小。
而最新的vSphere 8 U1版本，支援同一個GPU當中，可以組態設定不同類型的NVIDIA vGPU工作負載，舉例來說，Profile-B是針對VDI虛擬桌面的工作負載，Profile-C為針對ML機械學習的工作負載，Profile-Q為針對圖形密集型應用的工作負載，如圖3所示。
圖3 單一GPU支援組態設定不同類型的NVIDIA vGPU工作負載。 （圖片來源：Host different GPU workloads on a single GPU | VMware）
支援NVIDIA NVSwitch
vSphere 8 U1版本全面支援NVIDIA最新推出的NVSwitch技術，當企業組織需要多個GPU並行運算，例如HPC、AI深度學習、科學模擬等等，便非常需要此項技術。
主要原因在於，過去許多AI人工智慧和HPC高效能運算應用，受到硬體伺服器內部總傳輸速率的頻寬限制，而產生效能不彰的情況，因此NVIDIA建立名稱為NVSwitch的技術，允許最多「8個GPU」並且以極快的傳輸速度進行互相通訊。
簡單來說，NVLink和NVSwitch的主要區別在於，NVLink是NVSwitch的後端協議，其中NVLink Bridge點對點連接，因為採用Hopper運作架構，能夠提供極高的傳輸頻寬連接多個GPU。當連接「2個GPU」時可以提供雙向傳輸450GB/s傳輸頻寬，連接「4個GPU」時提供900GB/s總傳輸頻寬。然而，當需要連接的GPU超過4個時，便需要改為採用NVSwitch技術，如圖4所示。
圖4 NVIDIA NVLink和NVSwitch運作架構示意圖。 （圖片來源：Nvidia NVSwitch Support | VMware）
VM DirectPath I/O正式支援熱插拔
在過去的vSphere版本中，當VM虛擬主機需要新增或刪除VM DirectPath IO設備時，VM虛擬主機必須處於「關機」（Power Off）狀態才行。
而最新的vSphere 8 U1版本，在vSphere虛擬化層級中已經支援VM DirectPath IO設備能夠「熱新增」（Hot-Add）和「熱移除」（Hot-Remove）機制，只要搭配採用的底層硬體伺服器已通過PCIe Native Surprise Hot Plug認證，便能全面支援VM DirectPath IO設備，讓VM虛擬主機能夠在「運作中」（Power On）的情況下，熱新增及熱移除VM DirectPath IO設備，例如NVMe裝置，如圖5所示。
圖5 VM DirectPath IO設備支援熱新增和熱移除運作示意圖。 （圖片來源：VM DirectPath I/O Hot-Plug for NVMe | VMware）
vSphere with Tanzu再進化
在vSphere 8 U1版本中，除了VM服務外，當建立vSphere with Tanzu環境後，安裝和管理Supervisor服務時，也能夠順利使用vSphere vDS分佈式虛擬網路交換器的網路堆疊功能，如圖6所示。如此一來，DevOps工程師便能使用API在Kubernetes命名空間中，透過Supervisors建立容器並使用vDS網路堆疊功能。
圖6 Supervisor服務支援使用vSphere vDS網路堆疊功能示意圖。 （圖片來源：Supervisor Services with vSphere Distributed Switch | VMware）
此外，VM服務已經增強並支援VM映像檔，以便DevOps工程師能夠建立及部署Cloudinit或vAppConfig映像檔。同時，DevOps工程師現在可以使用kubectl指令輕鬆存取他們所部署的VM虛擬主機Console，以便進行遠端連線故障排除作業，並且vSphere管理人員無須指派和設定vSphere Client權限。
因為，透過kubectl指令產生的VM網路控制台，將向執行指令的使用者提供一次性且限制2分鐘的URL網址，接著使用者便能夠透過該安全性URL網址，連線至VM網路控制台進行故障排除作業，即便該台VM虛擬主機已經無法使用SSH遠端連線也可進行，如圖7所示。
圖7 透過kubectl產生安全性連線的Web Console VM網路控制台示意圖。 （圖片來源：VM Consoles for DevOps | VMware）
支援Okta識別身分同盟機制
在現今充滿各式網路威脅和惡意攻擊的時代，使用者身分驗證管理和多因素身分驗證機制，是目前網路安全中不可缺少的一環。
從vSphere 8 U1版本開始，vCenter管理平台的使用者身分驗證機制，正式支援Okta識別身分同盟機制，一旦導入後，vSphere便永遠看不到使用者身分憑證，此舉能夠有效提升安全性以及合規性，並且運作方式與現今大部分的Web身分驗證服務一樣，當需要進行使用者身分驗證時便會重新導向至該服務，一旦通過身分驗證機制的審核，再重新導向回登入頁面，並執行登入作業，如圖8所示。
圖8 導入Okta使用者身分驗證同盟機制示意圖。 （圖片來源：Okta Identity Federation for vCenter | VMware）
TPM安全性和快速啟動完全整合
在vSphere 6.7時，VMware推出「ESXi快速啟動」（ESXi Quick Boot）機制，能夠有效縮短ESXi主機重新啟動所花費的時間，然而整合TPM 2.0安全性機制的主機，在舊版vSphere運作環境中並不相容。
新版vSphere 8 U1則安裝並啟用TPM 2.0安全性機制的ESXi主機，已經與快速啟動機制完全相容，協助企業在享有安全啟動和認證並檢測惡意軟體時，也能整合快速啟動機制有效縮短重新啟動時間，如圖9所示。
圖9 整合TPM 2.0安全性和快速啟動機制操作畫面。 （圖片來源：ESXi Quick Boot for Secure Systems | VMware）
Fault Tolerance支援vTPM安全性機制
在新世代的作業系統中經常會使用TPM安全性機制，因此當VM虛擬主機內的客體作業系統需要使用TPM安全性機制時，能夠透過vTPM機制讓客體作業系統也擁有TPM安全性機制，例如Windows主機便能啟用Device Guard、Credential Guard、Secure Boot、OS Attestation等等安全性機制。
然而，過去的vSphere版本啟用FT（Fault Tolerance）的VM虛擬主機並不相容，所以無法使用vTPM。現在從最新的vSphere 8 U1版本開始，啟用FT機制的VM虛擬主機能夠完全相容使用vTPM安全性機制，讓VM虛擬主機層級的高可用性和高安全性兼具，如圖10所示。
圖10 啟用FT（Fault Tolerance）的VM虛擬主機也能使用vTPM操作。 （圖片來源：vSphere Fault Tolerance with vTPM | VMware）
實作新世代vSphere組態設定檔機制
接下來，將實戰演練vSphere 8 Update 1推出的「vSphere組態設定檔」（vSphere Configuration Profiles，vCP）機制。值得注意的是，在實作之前必須確保運作環境符合下列需求：
‧vSphere叢集中各項元件的生命週期，必須使用vLCM（vSphere Lifecycle Manager）進行管理，例如ESXi主機映像檔、ESXi版本、Firmware、驅動程式等等。
‧vSphere叢集中的ESXi節點主機，必須採用ESXi 8.0或後續版本。
‧vSphere叢集必須採用Enterprise Plus版本軟體授權。
簡單來說，vCP組態設定檔機制是透過JSON檔案的形式，儲存vSphere叢集中ESXi節點主機的組態設定內容，然後以參考主機為主要來源，檢查vSphere叢集中其他ESXi節點主機的組態設定是否「合規」（Compliance），倘若不符合便執行「修復」（Remediate）作業，將不符合的部分套用建議設定後使其合規，如圖11所示。
圖11 新世代vCP組態設定檔機制工作流程圖。 （圖片來源：Configuration Management using vSphere Configuration Profiles | VMware）
建立新的vSphere叢集
在本文實作環境中，採用最經典的應用情境，準備建立一個新的vSphere叢集，相關映像檔的生命週期由vLCM管理，而組態設定的部分則由vCP組態設定檔機制進行管理。
登入後，在vCenter Server管理介面中依序點選「vCenter Server > Datacenter > Actions > New Cluster」，在建立新的vSphere叢集對話窗內設定vSphere叢集名稱為「vCP-Cluster」，並勾選「Manage all hosts in the cluster with a single image」選項，表示採用vLCM機制管理映像檔生命週期，勾選「Manage configuration at a cluster level」選項，表示針對vSphere叢集啟用vCP組態設定檔機制，如圖12所示。
圖12 建立新的vSphere叢集並啟用vLCM和vCP組態設定檔機制。
在選擇ESXi映像檔頁面中，選擇屆時加入此vSphere叢集的ESXi節點主機版本。本次實作採用最新的ESXi 8.0 U1版本，如圖13所示，值得注意的是，必須選擇至少ESXi 8.0版本，才能完整且正確支援vCP組態設定機制。後續，皆採用系統預設值，即可輕鬆建立啟用vLCM和vCP組態設定機制的vSphere叢集。
圖13 選擇採用的ESXi節點主機版本。
組態設定參考來源主機
在本文實作環境中共有三台vSphere主機，可以選擇其中一台擔任屆時的參考來源主機，本文選擇「vsphere8-n01」擔任屆時的參考主機。
首先，組態設定參考主機使用NTP Server時間校對機制，依序點選「vsphere8-n01 > Configure > System > Time Configuration > Add Service > Network Time Protocol」，然後填入NTP時間伺服器的IP位址或FQDN。
接著，點選「vsphere8-n01 > Configure > Hardware > Overview > Power Management > Edit Power Policy」，將電力選項由預設的Balanced調整為「High performance」。
回到vSphere Cluster層級後，點選「Configure > Desired State > Configuration > Settings > Extract from reference host」，在選擇參考主機頁面中，選擇剛才進行組態設定的「vsphere8-n01」主機，如圖14所示。
圖14 選擇vsphere8-n01主機為組態設定參考來源主機。
在下一步Download Configuration頁面中，系統檢查作業完成後將會顯示組態設定檔案為準備下載狀態，按下〔Download〕按鈕便會自動下載JSON檔案格式的組態設定檔。開啟JSON檔案格式後，可以看到內容有設定NTP時間校對伺服器的IP位址，以及組態設定電力選項為High Performance，在最後「host-specific」區段，則是看到vsphere8-n01的組態設定內容，可以將這個區段複製後貼上，然後調整為vsphere8-n02的資訊，如圖15所示，其中ESXi UUID的內容，可以切換至「vsphere8-n02 > Configure > Hardware > Overview > System > Tag」內容得知。
圖15 在JSON組態設定檔案內容中，加上vsphere8-n02主機資訊。
執行合規檢查作業
完成JSON組態設定檔的修改動作後，回到vCP-Cluster層級中，依序點選「Configure > Desired State > Configuration > Import」，然後在彈出的匯入組態設定檔案視窗內按下〔BROWSE〕按鈕，選擇剛才修改的JSON組態設定檔，再按下〔IMPORT〕按鈕進行匯入組態設定的動作。
匯入動作執行後，系統將會自動進行「合規性」（Compliance）檢查作業，當匯入作業完成，在Settings視窗中點選「esx > system > system_time」項目，就會看到該項目的值為「Configured」，這就是剛才匯入參考來源主機vsphere8-n01，組態設定NTP時間校對伺服器的部分，如圖16所示。
圖16 查看匯入JSON組態設定檔內容和組態設定項目。
執行修復作業
切換到Compliance頁籤中，可以看到vsphere-n02主機目前的狀態並不符合規組態設定內容，例如系統提示Cluster value在電源設定的部分為「High Performance」，但是Host value部分則顯示空白或Not Configured，表示尚未設定。
此時，按下〔REMEDIATE〕按鈕，系統在彈出的Remediate視窗中將會自動執行Pre-check作業，確認Pre-check工作程序執行完成後，按下〔NEXT〕按鈕進入下一個程序。
在Review Impact視窗中，點選Host-Level Details選項，可以看到vsphere8-n02稍後會執行的修復作業項目，例如Power電源組態設定、NTP時間校對組態設定等等，如圖17所示，確認無誤後按下〔REMEDIATE〕按鈕，便會進行修復作業。
圖17 查看vsphere8-n02稍後會執行的修復作業項目。
稍待一段時間後，系統將會顯示「Remediation completed successfully.」，表示修復作業已經執行完成，此時在Compliance視窗中，可以看到vsphere8-n02主機的組態設定已經合規，如圖18所示。
圖18 修復作業完成vsphere8-n02節點主機已經合規。
vSphere叢集新增ESXi節點主機
隨著企業組織的專案增加，勢必會在vSphere叢集中新增ESXi節點主機，以便承載更多的VM虛擬主機和容器等工作負載，透過vCP組態設定檔機制，可以讓加入的ESXi節點主機在最短的時間內進行合規檢查並套用設定，而非逐一手動設定和進行檢查作業。
在vCenter管理介面中，依序點選「vCP-Cluster > Actions > Add Host」項目，將vsphere8-n03節點主機加入。同樣地，當新的ESXi節點主機加入時，系統將自動進行合規性檢查作業，將會發現系統無法進行合規性檢查，主要是剛才匯入的JSON組態設定檔內容中並沒有包括vsphere8-n03節點主機資訊，所以系統提示「1 hosts have unknown status」，有一台ESXi節點主機為未知狀態，並且錯誤訊息為「Check compliance is skipped」，表示省略合規檢查作業，如圖19所示。
圖19 新加入的ESXi節點主機由於狀態未知所以略過合規性檢查。
此時，同樣開啟剛才修改的JSON檔案資訊，將vsphere8-n03節點主機的IP位址和主機名稱加入，如圖20所示，並且記得前一段的vsphere8-n02節點主機內容中，最後一個大括號的結尾加上逗號，確保稍後JSON組態設定檔內容能夠順利匯入。
圖20 修改JSON組態設定檔內容，加上vsphere8-n03節點主機資訊。
完成JSON組態設定檔的修改動作後，回到vCP-Cluster層級中，依序點選「Configure > Desired State > Configuration > Import」，在彈出的匯入組態設定檔案視窗中，按下〔BROWSE〕按鈕選擇剛才修改的JSON組態設定檔後，按下〔IMPORT〕按鈕進行匯入組態設定的動作。
同樣地，匯入作業完成後，系統自動執行合規性檢查作業，切換到Compliance頁籤中，可以看到vsphere-n03節點主機目前的狀態並不符合規組態設定內容，例如系統提示在Setting為ntp_config中Cluster value的部分為「Configured」，但是Host value的部分則顯示Not Configured，表示vsphere-n03節點主機尚未設定NTP時間校對，如圖21所示。
圖21 vsphere-n03節點主機合規性檢查結果。
此外，也可以看到在安裝vsphere-n03節點主機時，由於人為疏忽而誤將DNS伺服器的IP位址「10.10.75.10」，設定錯誤為該台節點主機的IP位址「10.10.75.33」，在合規性檢查作業中也檢查出來，所以vCP組態設定檔機制，不僅能確保組態設定一致性，更可確保人為疏忽造成的組態設定錯誤。
在確認將進行修復作業時，按下〔REMEDIATE〕按鈕，系統在彈出的Remediate視窗中，將會自動執行Pre-check作業，一旦Pre-check工作程序順利執行完成後，按下〔NEXT〕按鈕進入下一個程序。在Review Impact視窗中，點選Host-Level Details選項，可以看到vsphere8-n03節點主機稍後執行的修復作業項目，與剛才修復vsphere8-n02節點主機稍有不同，包括進入維護模式、Power電源組態設定、NTP時間校對組態設定、DNS伺服器IP位址等等，如圖22所示，確認無誤後按下〔REMEDIATE〕按鈕，便會進行修復作業。
圖22 查看vsphere8-n03節點主機準備執行的修復作業項目。
事實上，vCP組態設定檔機制會視需要修復的作業項目採取相對應的動作，舉例來說，此次vsphere8-n03節點主機需要修復的項目，便須將主機進入維護模式後才進行修改作業，並且在修改作業完成後自動離開維護模式，稍待一段時間修復作業後，在Compliance視窗中可以看到vsphere8-n03主機的組態設定已經合規，如圖23所示。
圖23 修復作業完成，vsphere8-n03節點主機已經合規。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞