網管人雜誌
本文刊載於 網管人雜誌第 188 期 - 2021 年 9 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
隨著 VMware vSphere 7 在 2020 年 4 月正式發佈後，VMware 官方也同步將發佈週期調整為 6 個月，所以在 2020 年 10 月推出 vSphere 7 Update 1 更新版本，並且在 2021 年 3 月正式發佈 vSphere 7 Update 2 更新版本。
同樣的，雖然 vSphere 7 Update 2 看似為小版本更新，實際上此更新版本中無論在容器技術，或者是 AI 人工智慧和 ML 機器學習支援度方面大幅提升之外，更新增許多亮眼特色新功能，幫助企業和組織快速建構現代化應用程式的基礎架構平台。
在 VMworld 2020 大會上，VMware 和 NVIDIA 共同宣佈提供 AI-Ready Enterprise Platform（如圖 1 所示），透過端到端的雲端原生 AI 工具和框架套件，直接在 vSphere 虛擬化基礎架構上執行，同時搭配 NVIDIA GPUDirect RDMA 和 vSphere DRS 分佈式資源調度機制，最佳化 AI 基礎架構和工作負載，避免發生效能瓶頸的情況。
圖 1、AI-Ready Enterprise Platform 運作架構示意圖
vSphere 7 Update 2 亮眼特色功能
不斷增強的 vGPU 機制
在新版 vSphere 7 Update 2 版本中，除了支援最新一代 NVIDIA Ampere GPU 之外，採用 A100 GPU 時能夠提供比上一代多達 20 倍的效能，並且無論是 vSphere vMotion 和 vSphere DRS 機制，都能完整支援使用 NVIDIA MIG vGPU 機制的 VM 虛擬主機（如圖 2 所示），簡化 vSphere 基礎架構在擴充和版本升級時的難題。
對於運作 ML 機器學習工作負載來說，VM 虛擬主能夠透過 MIG（Multi-Instance GPUs）機制，大幅提升效能並有效縮短模型訓練時間。
圖 2、MIG（Multi-Instance GPUS）機制運作架構示意圖
事實上，在過去的 vSphere vGPU 版本中，主要採用「共享」GPU 資源的運作機制，所以當管理人員組態設定 VM 虛擬主機時，可以針對支援的 VM 虛擬主機指派適當的「Framebuffer Memory」，也就是 VM 虛擬主機屆時能夠共享使用的 GPU 記憶體資源，例如，為 VM 虛擬主機配置「5 GB」的 GPU 記憶體資源（如圖所示）。
在 NVIDIA GRID vGPU Profile 下拉式選單中，每個項目中結尾「c」前面的數字，便是指派多少 GPU 記憶體空間的 GB 數值。
圖 3、傳統 vGPU 共享機制，設定 VM 虛擬主機使用 5GB 的 GPU 記憶體資源
現在，新版的 MIG vGPU 採用硬體層級隔離機制，除了支援過去採用共享 GPU 資源的方式之外，也支援將多個或所有的 GPU 資源，全部指派給單一或特定的 VM 虛擬主機使用，例如，管理人員可以選擇「grid_a100-7-40c」項目（如圖 4 所示），讓 VM 虛擬主機可以獨佔整個 A100 的 GPU 資源，以便 VM 虛擬主機需要大量運算各種演算法和訓練模型時，能夠有效縮短整體時間。
圖 4、新式 MIG vGPU 機制，支援共享和獨佔 GPU 記憶體資源
vSphere with Tanzu 再增強
從 vSphere 7 Update2 版本開始，管理人員可以在 vSphere with Tanzu 的 Supervisor 叢集中，搭配 SEV-ES 安全加密虛擬化機制，建立具備高安全性的 vSphere Pod 和容器運作環境（如圖 5 所示）。當管理人員啟用和部署高安全性 vSphere Pod 之後，除了能夠防止 Hypervisor 直接存取 CPU 暫存器內的資訊之外，還能阻擋外部對 CPU 暫存器的惡意修改行為，有效保護 vSphere Pod 和容器內的機敏資訊。
啟用和部署高安全性 vSphere Pod 之後，在 vSphere Client 管理介面中，可以看到 Encryption mode 欄位顯示為「Confidential Compute」。
圖 5、在 vSphere with Tanzu 的 Supervisor 叢集中，啟用和部署高安全性 vSphere Pod
事實上，在 vSphere 7.0 版本推出時，vSphere with Tanzu 運作環境，必須搭配 NSX 部署整個 SDN 軟體定義網路才能運作，在 vSphere 7.0 Update 1 版本中，新增支援部署開放源始碼的 HAProxy，以便擔任外部負載平衡器的角色，讓沒有部署 NSX 的企業和組織，也能輕鬆建構 vSphere with Tanzu 運作環境。
雖然，HAProxy 提供企業和組織快速建構容器環境的負載平衡機制，然而對於正式營運環境來說還是有些限制。現在，最新的 vSphere 7.0 Update 2 版本，直接提供適合正式營運環境的 NSX ALB（Advanced Load Balancer）Essentials，同樣讓沒有部署 NSX 的企業和組織，也能為 vSphere with Tanzu 運作環境輕鬆建構負載平衡機制。
NSX ALB（Advanced Load Balancer），為 VMware 併購 Avi Networks 公司之後，演化而來的負載平衡技術，無須部署 NSX SDN 環境即可運作。
當管理人員部署 NSX ALB 負載平衡機制後，即可支援 Supervisor 叢集、TKG（Tanzu Kubernetes Grid）叢集，以透過分配一個虛擬 VIP 的方式，來存取 Supervisor 叢集中的 Kubernetes API，同時在嘗試存取 API 的流量時，會平均分佈至 Supervisor 叢集中的 3 個 Kubernetes Controller 。
此外，當開發人員建立 TKG 叢集時，系統也會自動分配新的 VIP，以便 VIP 與 TKG 叢集之前的流量也能進行負載平衡。最後，當開發人員部署應用程式至 TKG 叢集時，指定部署的類型為 LoadBalancer 的 Kubernetes 服務後，這些應用程式的 Kubernetes 服務便會自動分配到一個 VIP，讓開發人員可以存取應用程式，並自動達成應用程式的負載平衡機制（如圖 6 所示）。
圖 6、NSX ALB（Advanced Load Balancer）負載平衡運作架構示意圖
vMotion 自動偵測傳輸頻寬
vSphere vMotion 線上遷移機制，從一開始的 VC 1.0（ESX 2.0）時代開始亮相（如圖 7 所示）。在當時的 VMworld 大會上展示時，便讓企業和組織開始相信，虛擬化技術已經不僅僅限於使用在研究和測試環境，而是真正可以用於正式營運當中的技術。
圖 7、vSphere vMotion 線上遷移機制版本演進示意圖
隨著時代演變和技術的推進，vSphere vMotion 線上遷移機制的功能也不斷強化。在過去的 vSphere 版本中，由於企業和組織的資料中心內，主流的乙太網路傳輸速率為 10 GbE，即便採用新式的 25 GbE、40 GbE、50 GbE、100 GbE 傳輸速率，只要手動搭配相關的組態設定後，即可在高頻寬的網路環境下發揮 vSphere vMotion 傳輸效能。
因為，在預設情況下，vMotion 採用「Single Stream」傳輸機制，並且使用的網路頻寬大約在「15 GbE」左右，所以採用 10 GbE 網路環境時，無須進行任何調整也能發揮 vMotion 最大傳輸效能，所以一旦網路環境超過 10 GbE 網路環境時，管理人員必須手動調整相關進階設定，例如，vMotion Stream、TCP/IP VMkernel、更新網路卡驅動程式……等，才能讓 vMotion 發揮最大傳輸效能。
每個 vMotion Single Stream，由三個部份所組成分別是 Completion helper、Crypto helper、Stream helper，其中佔用最多網路頻寬的便是 Stream helper。
然而，企業和組織的資料中心內，10GbE 乙太網路傳輸速率已不在是主流，那麼每次新加入 ESXi 主機至 vSphere 叢集時，便還要記得手動去調整 vMotion 進階設定，才能 vMotion 發揮最大傳輸效能便太過麻煩。
因此，從 vSphere 7 Update 2 版本開始，預設啟用「vMotion 自動縮放」（vMotion Auto Scaling）機制（如圖 8 所示），當 ESXi 主機配置使用 vMotion 流量的網路卡頻寬超過 10 GbE 時，系統中的 vMotion 執行程序，將會在偵測網路卡頻寬後自動增加 vMotion Stream 數量，無須管理人員在手動調整 vMotion 進階組態設定。原則上，每 15 GbE 網路頻寬會建立「1 個」Single Stream，所以不同的網路頻寬便會依序建立多個 vMotion Stream ：
- 25 GbE ：2 個 vMotion Stream 。
- 40 GbE ：3 個 vMotion Stream 。
- 50 GbE ：4 個 vMotion Stream 。
- 100 GbE ：7 個 vMotion Stream 。
請注意，倘若之前手動組態設定 vMotion 進階設定，請確保恢復設定內容至預設值，以避免影響新版 vMotion Auto Scaling 機制的運作。
圖 8、vMotion Auto Scaling 運作架構示意圖
針對 AMD EPYC 工作負載最佳化
在新版 vSphere 7.0 U2 版本中，已經在 ESXi 虛擬化平台「CPU 調度程序」（CPU Scheduler）中，針對 AMD EPYC 處理器進行工作負載最佳化。簡單來說，新版中的 CPU 調度程序，會充份利用 AMD EPYC 處理器的 LLC（Last-Level Caches）、CCXs（Two Core Complexes）、CCDs（Core Complex Dies）機制，讓具備多 vCPU 的 VM 虛擬主機，能夠盡量使用同一個 CCD 的運算資源，進而達到 VM 虛擬主機工作負載最佳化的目的（如圖 9 所示）。
圖 9、新式 CPU 調度程序最佳化 VM 虛擬主機工作負載示意圖
根據 VMware 官方測試結果，新式 CPU 調度程序針對不同的工作負載，相較於前一版本 vSphere 7.0 U1 環境，在工作負載效能表示上都能有所提升（如圖 10 所示），最多甚至能夠提升至「50 %」的運作效能。
圖 10、新式 CPU 調度程序對於 TKG Cluster 工作負載效能提升情況
vTPM 正式支援 Linux 虛擬主機
TPM（Trusted Platform Module）機制，在現代化作業系統中已經是基本的必須功能，舉例來說，在微軟最新的 Windows 11 作業系統中，必須先確認硬體已經支援 TPM 機制才能進行安裝。
然而，在過去的 vSphere 版本中，雖然支援 vTPM（Virtual Trusted Platform Module）機制，讓 VM 虛擬主機工作負載能夠直接使用 TPM，但是僅限於採用 Windows 客體作業系統的 VM 虛擬主機。現在，最新版本的 vSphere 7.0 U2 版本，vTPM 機制正式支援採用 Linux 客體作業系統的 VM 虛擬主機（如圖 11 所示）。
圖 11、vTPM 運作架構示意圖
大量減少 ESXi 開機時間
在 vSphere 虛擬化基礎架構中，管理人員在日常維運中，無論是 ESXi 主機的安全性更新或版本升級，或者是 ESXi 發生硬體故障必須更換料件的情況下，都必須為 ESXi 主機進行重新啟動的動作。雖然，在 ESXi 主機上運作的 VM 虛擬主機，可以透過 vSphere vMotion/DRS 機制，線上遷移至其它 ESXi 主機繼續運作，但是 ESXi 主機的重新啟動和恢復時間倘若能夠縮短，對於整體維運時間和資料中心的 SLA 品質將能有效提升。
因此，在新版中新增支援「暫停至記憶體」（Suspend to Memory，STM）機制（如圖 12 所示）。簡單來說，管理人員可以透過原有的 Quick Boot 機制，搭配 STM 機制將無須線上遷移的 VM 虛擬主機，例如，測試或研發用途的 VM 虛擬主機，將其狀態儲存至 ESXi 虛擬化平台的記憶體當中，後續便能快速恢復 VM 虛擬主機的運作狀態。
請注意，STM 必須搭配 Quick Boot 機制才能運作，並且 vSphere 叢集必須啟用 vLCM 進行管理才行。詳細資訊請參考 VMware KB 52477 知識庫文章內容。
圖 12、啟用 STM（Suspend to Memory）機制組態設定示意圖
vSphere DRS/HA 機制支援 Persistent Memory
管理人員對於 vSphere HA 高可用性機制應該不陌生。簡單來說，VM 虛擬主機工作負載能否被 vSphere HA 高可用性機制所保護，非常重要的前提在於，VM 虛擬主機的儲存資源必須存放於共享 Datastore 儲存資源中，因此發生災難事件時，vSphere 叢集中的另一台 ESXi 主機，才能接手共享 Datastore 儲存資源中 VM 虛擬主機的檔案，達成重新啟動 VM 虛擬主機的目的。
因此，在過去的 vSphere 版本中，倘若 VM 虛擬主機為了高儲存效能的考量下，例如，SAP HANA 虛擬主機，將 VM 虛擬主機儲存資源存放於 Persistent Memory 中，那麼此類型的 VM 虛擬主機便無法被 vSphere HA 高可用性機制所保護（如圖 13 所示）。
圖 13、舊版 vSphere 的 VM 虛擬主機，採用 Persistent Memory 時無法被 vSphere HA 機制保護
現在，最新版本的 vSphere，已經支援 VM 虛擬主機採用 Persistent Memory 時，仍然能夠被 vSphere HA 高可用性機制所保護（如圖 14 所示）。值得注意的是，VM 虛擬主機必須採用虛擬硬體版本「19」，並且不能使用 vPMemDisks 機制的 VM 虛擬主機，才能順利被 vSphere HA 高可用性機制所保護。
圖 14、新版 vSphere 的 VM 虛擬主機，採用 Persistent Memory 時也能被 vSphere HA 機制保護
VMware Tools 支援更全面
在最新版本中的 VMware Tools 支援許多特色功能，舉例來說，從 VMware Tools 11.2.0 版本開始，便會將 Carbon Black Plugin 一同安裝。另外，在 Windows 網域環境中非常重要的時間校對，也可以在安裝 VMware Tools 時，勾選「VMware Time Provider」項目進行安裝（如圖 15 所示），讓 Windows 虛擬主機只要透過 VMware Tools，也能夠輕鬆達成時間校對的目的。
請注意，VMware Time Provider 預設並不會安裝，必須在安裝 VMware Tools 時選擇 Custom 項目後，選擇「Will be installed on local hard dirve」項目才會進行安裝。
圖 15、安裝 VMware Tools 並一同安裝 VMware Time Provider
實戰 – VMware Tools GuestStore
在本文實戰演練小節中，將實作最新發佈的 VMware Tools GuestStore 機制，這是一項 VMware 官方針對眾多使用者提出的意見回饋功能請求，所實作出來讓 VM 虛擬主機能夠安全且直接存取資料的一種新方式。
簡單來說，在 vSphere 虛擬化基礎架構中運作的 VM 虛擬主機，在確認已經安裝 VMware Tools 之後，即可透過 VMware Tools GuestStore 機制，快速存取由管理人員集中管理和準備的各種類型檔案，例如，VMware Tools、代理程式、二進位檔案、組態設定檔 …… 等，達成安裝、更新、升級……等動作（如圖 16 所示）。
請注意，目前 GuestStore 僅支援 Windows 作業系統的 VM 虛擬主機，安裝 VMware Tools 的 Linux 作業系統虛擬主機暫不支援。此外，雖然支援各種類型檔案存放於 GuestStore 內，但是每個檔案大小必須「小於 512 MB」才行。
圖 16、GuestStore 運作架構示意圖
GuestStore 運作架構
在深入解析 VMware Tools GuestStore 主要元件和運作架構之前，管理人員必須了解 GuestStore 機制的重要運作概念，就是在 GuestStore 的運作框架中，系統並不會將集中管理的檔案內容主動「推送」（Push）給 VM 虛擬主機，而是 VM 虛擬主機的管理人員自行評估需求後，手動將存放於 GuestStore 內的檔案內容「拉取」（Pull）回 VM 虛擬主機內使用。
下列為 GuestStore 運作架構中（如圖 17 所示），各項主要運作元件的角色和功能說明：
- GuestStore Client ： 運作在 Windows 虛擬主機內的執行程序，以便屆時存取 GuestStore 內容。
- GuestStore Plugin ： 當 Windows 虛擬主機安裝 VMware Tools 時，系統便會一同安裝 GuestStore Plugin 至虛擬主機內，並負責處理 Windows 虛擬主機存取 GuestStore 的連線請求。同時，為了避免 VMX GuestStore Module 發生工作過載的情況，所以一次僅接受和處理一個連線請求，其它額外連線請求則必須排入等待佇列中，待一個連線請求消化後才處理另一個等待佇列中的連線請求。
- VMX GuestStore Module ： 在 GuestStore 運作架構中擔任代理伺服器的角色，將 GuestStore Plugin 主機端傳送過來的連線請求，轉送給 GuestStore Daemon 系統服務進行處理。
- GuestStore Daemon ： 這是在 vSphere 7.0 Update 2 版本中新增的系統服務，負責接收來自 VMX GuestStore Module 的連線請求之後，下載 GuestStore 內容後送回給 GuestStore Client 。同時，下載過的內容將會建立快取內容，以便其它 GuestStore Client 存取重複內容時，無須再次下載 GuestStore 內容，即可直接由快取內容回覆給 GuestStore Client 即可，有效提升回應速度和傳輸效率。
圖 17、VMware Tools GuestStore 主要元件和工作流程運作示意圖
組態設定 GuestStore Repository 路徑
了解 VMware Tools GuestStore 運作架構後，便開始著手為 ESXi 虛擬化平台，組態設定 GuestStore Repository 存放機制。首先，管理人員必須在 VM 虛擬主機，稍後所要存取的共用 Datastore 儲存資源中，建立資料夾並放置相關檔案。在本文實作環境中，於共用的 NFS Datastore 儲存資源中，建立名稱為「tools」的資料夾，並在「Edge」子目錄中，放置 Windows Server 預設未安裝的 Microsoft Edge 瀏覽器離線安裝檔案。
最新版本的 Windows Server 2022 作業系統，已經內建 Microsoft Edge 瀏覽器。
目前，因為 VMware Tools GuestStore 機制，尚未整合至 vSphere Client 管理介面中，所以管理人員必須為某一台 ESXi 主機開啟 TSM-SSH 服務後，透過 SSH Client 軟體登入該 ESXi 主機進行組態設定。值得注意的是，這台開啟 SSH 服務的 ESXi 主機，必須能夠存取準備分享的共用 Datastore 儲存資源才行。
順利登入 ESXi 主機後，首先確認共用資料夾路徑和相關檔案是否存在。在本文實作環境中，共用 NFS Datastore 的系統路徑為「/vmfs/volumes/NFS-Datastore/tools」，同時確認已經子目錄 Edge 內，存放好 Microsoft Edge 瀏覽器離線安裝檔案，確認無誤後請執行「esxcli system settings gueststore repository set --url」指令，搭配共用NFS Datastore 系統路徑「/vmfs/volumes/NFS-Datastore/tools」，建立 GuestStore Repository 分享路徑，接著執行「esxcli system settings gueststore repository get」指令，確認剛才建立的 GuestStore Repository 分享路徑是否已經套用生效（如圖 18 所示）。
圖 18、為共用 NFS Datastore 儲存資源，組態設定 GuestStore Repository 分享路徑
Windows 虛擬主機拉取檔案
當共用 NFS Datastore 儲存資源，組態設定 GuestStore Repository 機制完成後，便可以切換至 Windows 虛擬主機，準備從 GuestStore Repository 內拉取相關檔案至本機端。在開始拉取 GuestStore Repository 內相關檔案之前，必須確認 Windows 虛擬主機符合相關條件才行，否則稍後將會無法拉取相關檔案並遭遇錯誤。
首先，嘗試拉取 GuestStore Repository 內檔案的 Windows 虛擬主機，必須運作在 vSphere 7.0 U2 或後續版本的 ESXi 虛擬化平台上，並且 Windows 虛擬主機必須安裝 VMware Tools 11.2.5 或後續版本，屆時才能順利從 GuestStore Repository 拉取相關檔案。
本文實作的 Windows Server 2019 虛擬主機，安裝最新 VMware Tools 11.2.5（17337674）版本。
確認 Windows 虛擬主機符合條件後，即可開啟命令提示字元，並切換至「C:\Program Files\VMware\VMware Tools」資料夾，鍵入「VMwareToolboxCmd.exe gueststore getcontent」指令，搭配 GuestStore Repository 分享路徑中，所要拉取的檔案路徑「/Edge/MicrosoftEdgeEnterpriseX64.msi」，最後指定拉取的檔案，要存放於 Windows 虛擬主機的本機路徑「C:\tmp\Edge64.msi」，確認無誤後按下 Enter 鍵，即可立即從 GuestStore Repository 分享路徑中，拉取 Windows 虛擬主機所需的檔案（如圖 19 所示）。
倘若指定的 GuestStore Repository 路徑錯誤或檔案不存在時，系統將會出現「getcontent failed，GuestStore client library error : Content not found」的錯誤訊息。
圖 19、Windows 虛擬主機，順利從 GuestStore Repository 內拉取需要的檔案
實作至此，可能有許多管理人員會有困惑，這樣存取檔案的方式與傳統 NAS 存取方式相較之下，似乎也沒有比較便利或安全啊 ？事實上，當 Windows 虛擬主機執行指令，嘗試拉取 GuestStore Repository 內的相關檔案時，並非像存取傳統 NAS 儲存資源採用乙太網路傳輸的方式，而是透過 Windows 虛擬主機內的 VMware Tools，直接和底層的 ESXi 虛擬化平台溝通並執行拉取檔案的動作。
因此，管理人員可以再次進行測試，在 Windows 虛擬主機再次拉取 GuestStore Repository 內相關檔案之前，先將 Windows 虛擬主機的網路卡進行停用，確認無法透過乙太網路進行資料傳輸後，再次執行拉取 GuestStore Repository 路徑中檔案的動作，管理人員可以發現仍然能夠順利拉取檔案（如圖 20 所示）。
圖 20、即便網路卡停用，仍然能夠拉取 GuestStore Repository 路徑中的檔案
透過上述實作演練後，管理人員應該可以理解，為何說 VMware Tools GuestStore 機制，是一種安全且直接存取資料的新方式。因為，這樣的應用方式在某些極度封閉且強調高安全性的運作環境中，能夠在持續封閉且不失高安全性的情況下，同時又能達到交換檔案的一種新方式。
後續，管理人員可以在 ESXi 主機中查看「/var/logs/gstored.log」，在 Windows 虛擬主機中查看「C:\Windows\Temp\vmware-vmsvc-SYSTEM.log」，以便觀察 GuestStore 運作和檔案存取的日誌內容。
結語
透過本文的深入剖析和實作演練後，相信讀者已經了解最新發佈的 vSphere 7.0 Update 2 版本中，有哪些亮眼新功能和運作架構及原理，讓企業和組織可以評估哪些功能適合導入至新專案當中。此外，帶領讀者實作演練新版本當中，最新發佈的 VMware Tools GuestStore 功能，提供給 VM 虛擬主機安全且直接存取資料的方式，讓企業和組織內部資料中心中某些極度封閉且高安全性的環境，能夠在不失高安全性的情況下又能達到交換檔案的目的。