網管人雜誌
本文刊載於
網管人雜誌第 210 期 - 2023 年 7 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
在 2022 年 10 月時 VMware 官方發佈最新 vSphere 8 版本，經過六個月之後，在 2023 年 4 月正式發佈 vSphere 8 Update 1 版本。管理人員應該可以發現，在最新的 vSphere 8 Update 1 版本中，並非僅是現有功能增強或臭蟲更新，而是包含了多項新增特色功能。在本文中，將為讀者逐一剖析各式亮眼特色功能，並且實戰演練最新發佈的 vCP 組態設定檔機制。
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）組態設定檔機制運作示意圖
簡單來說，雖然舊版的 Host Profiles 與新式的 vSphere Configuration Profiles 機制有點類似，但新世代 vCP 組態設定檔機制支援度和範圍更全面，並且支援管理人員將現有 Host Profiles 機制，轉換為新世代的 vCP 組態設定檔機制，協助管理人員順利過渡到新式 vCP 組態設定檔機制。
請注意! 目前 vCP 並不支援 VMware NSX 環境。
vLCM 正式支援獨立主機
在過去的 vSphere 版本中，vLCM 生命週期管理員機制，僅支援 vSphere 叢集和 ESXi 節點主機，並不支援尚未納入 vSphere 叢集的「獨立主機」（Standalone Host）。
現在，最新的 vSphere 8 U1 版本中，vLCM 生命週期管理員機制透過 vSphere API，與 vCenter Server 管理平台進行溝通，進而支援獨立主機。因此，過往在 vSphere 叢集和 ESXi 節點主機環境中，進行映像檔、修復、檢查合規性……等工作任務，現在也都可以針對 ESXi 獨立主機進行套用（如圖 2 所示）。
圖 2、vLCM 生命週期管理員機制正式支援獨立主機
單個 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 工作負載
支援 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」時可以提供雙向傳輸 450 GB/s 傳輸頻寬，連接「4 個 GPU」時提供 900 GB/s 總傳輸頻寬。然而，當需要連接的 GPU 超過 4 個時，便需要改為採用 NVSwitch 技術（如圖 4 所示）。
圖 4、NVIDIA NVLink 和 NVSwitch 運作架構示意圖
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 設備支援熱新增和熱移除運作示意圖
vSphere with Tanzu 再進化
在 vSphere 8 U1 版本中，除了 VM 服務之外，當管理人員建立 vSphere with Tanzu 環境後，安裝和管理 Supervisor 服務時，也能夠順利使用 vSphere vDS 分佈式虛擬網路交換器的網路堆疊功能（如圖 6 所示），如此一來 DevOps 工程師，便能使用 API 在 Kubernetes 命名空間中，透過 Supervisors 建立容器並使用 vDS 網路堆疊功能。
圖 6、Supervisor 服務支援使用 vSphere vDS 網路堆疊功能示意圖
此外，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 網路控制台示意圖
支援 Okta 識別身份同盟機制
在現今充滿各式網路威脅和惡意攻擊的時代，使用者身份驗證管理和多因素身份驗證機制，是目前網路安全中不可缺少的一環。
從 vSphere 8 U1 版本開始，vCenter 管理平台的使用者身份驗證機制，正式支援 Okta 識別身份同盟機制，一旦導入後 vSphere 便永遠看不到使用者身份憑證，此舉能夠有效提升安全性以及合規性，並且運作方式和現今大部份的 Web 身份驗證服務一樣，當需要進行使用者身份驗證時便會重新導向至該服務，一旦通過身份驗證機制的審核後再重新導向回登入頁面並執行登入作業（如圖 8 所示）。
圖 8、導入 Okta 使用者身份驗證同盟機制示意圖
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 安全性和快速啟動機制操作畫面示意圖
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 組態設定檔機制
在實戰小節中，將實戰演練最新 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 組態設定檔機制工作流程圖
建立新的 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 所示）。
請注意 ! vSphere 叢集無法僅啟用 vCP 組態設定檔機制。
圖 12、建立新的 vSphere 叢集並啟用 vLCM 和 vCP 組態設定檔機制
圖 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」內容得知。
在 vsphere8-n01 組態設定內容最後的大括號結尾，記得加上「逗號」後，才將 vsphere8-n02 的內容貼上，屆時 JSON 檔才能正確執行匯入作業。
圖 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 稍後會執行的修復作業項目
圖 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 組態設定檔內容能順利匯入。
管理人員也可以將 JSON 組態設定內容，複製後貼上至線上檢查 JSON 語法的網站，例如，jsonlint.com 進行內容正確性檢查。
圖 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-n02 節點主機已經合規
結語
透過本文的深入剖析和實作演練後，相信管理人員除了理解最新 vSphere 8 U1 版本，推出哪些亮眼特色功能之外，也能經由實作 vCP 組態設定檔管理機制，幫助企業或組織在管理 vSphere 叢集和 ESXi 節點主機時，輕鬆確保 ESXi 主機間組態設定一致性，同時避免人為疏忽造成的組態設定錯誤和故障排除時間。
