Update 2不只是更新　強化版vSphere 7功能快覽

隨著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基礎架構和工作負載，避免發生效能瓶頸的情況。

vSphere 7 Update 2 亮眼特色功能

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基礎架構在擴充和版本升級時的難題。

事實上，在過去的vSphere vGPU版本中，主要採用「共享」GPU資源的運作機制，所以當管理人員組態設定VM虛擬主機時，可以針對支援的VM虛擬主機指派適當的「Framebuffer Memory」，也就是VM虛擬主機屆時能夠共享使用的GPU記憶體資源，例如為VM虛擬主機配置「5GB」的GPU記憶體資源，如圖3所示，值得注意的是，在NVIDIA GRID vGPU Profile下拉式選單中，每個項目中結尾「c」前面的數字，便是指派多少GPU記憶體空間的GB數值。

新版的MIG vGPU採用硬體層級隔離機制，除了支援過去採用共享GPU資源的方式外，也支援將多個或所有的GPU資源全部指派給單一或特定的VM虛擬主機使用，例如管理人員可以選擇「grid_a100-7-40c」項目，如圖4所示，讓VM虛擬主機能夠獨佔整個A100的GPU資源，以便VM虛擬主機需要大量運算各種演算法和訓練模型時可有效縮短整體時間。

vSphere with Tanzu再增強

從vSphere 7 Update2版本開始，管理人員可以在vSphere with Tanzu的Supervisor叢集中搭配SEV-ES安全加密虛擬化機制，來建立具備高安全性的vSphere Pod和容器運作環境，如圖5所示，啟用和部署高安全性vSphere Pod後，在vSphere Client管理介面中，可以看到Encryption mode欄位顯示為「Confidential Compute」。當啟用和部署高安全性vSphere Pod之後，除了能夠防止Hypervisor直接存取CPU暫存器內的資訊外，還可阻擋外部對CPU暫存器的惡意修改行為，有效保護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負載平衡機制後，即可支援Supervisor叢集、TKG（Tanzu Kubernetes Grid）叢集，以透過分配一個虛擬VIP的方式，來存取Supervisor叢集中的Kubernetes API，同時在嘗試存取API的流量時，會平均分佈至Supervisor叢集中的3個Kubernetes Controller。

此外，當開發人員建立TKG叢集時，系統也會自動分配新的VIP，以便VIP與TKG叢集之前的流量也能進行負載平衡。最後，當開發人員部署應用程式至TKG叢集時，若指定部署的類型為LoadBalancer的Kubernetes服務，這些應用程式的Kubernetes服務便會自動分配到一個VIP，讓開發人員可以存取應用程式，並自動達成應用程式的負載平衡機制，如圖6所示。

vMotion自動偵測傳輸頻寬

vSphere vMotion線上遷移機制，從一開始的VC 1.0（ESX 2.0）時代開始亮相，如圖7所示。在當時的VMworld大會上展示時，便讓企業和組織開始相信，虛擬化技術已經不僅僅限於使用在研究和測試環境，而是真正可以用於正式營運的技術。

隨著時代演變和技術的推進，vSphere vMotion線上遷移機制的功能也不斷強化。在過去的vSphere版本中，由於企業組織的資料中心內，主流的乙太網路傳輸速率為10GbE，即便採用新式的25GbE、40GbE、50GbE、100GbE傳輸速率，只要手動搭配相關的組態設定，即可在高頻寬的網路環境下發揮vSphere vMotion傳輸效能。

因為，在預設情況下vMotion採用「Single Stream」傳輸機制，並且使用的網路頻寬大約在「15GbE」左右，所以採用10GbE網路環境時，無須進行任何調整也能發揮vMotion最大傳輸效能，所以一旦是處於超過10GbE的網路環境時，管理人員必須手動調整相關進階設定，例如vMotion Stream、TCP/IP VMkernel、更新網路卡驅動程式等等，才能讓vMotion發揮最大傳輸效能。

然而，在企業組織的資料中心內，10GbE乙太網路傳輸速率已不再是主流，那麼每次新加入ESXi主機至vSphere叢集時，便還要記得手動調整vMotion進階設定才能vMotion發揮最大傳輸效能，便太過麻煩。

因此，從vSphere 7 Update 2版本開始，預設啟用「vMotion自動縮放」（vMotion Auto Scaling）機制，如圖8所示，當ESXi主機配置使用vMotion流量的網路卡頻寬超過10GbE時，系統中的vMotion執行程序將會在偵測網路卡頻寬後自動增加vMotion Stream數量，無須管理人員再手動調整vMotion進階組態設定。原則上，每15GbE網路頻寬會建立「1個」Single Stream，所以不同的網路頻寬便會依序建立多個vMotion Stream：

‧25GbE：2個vMotion Stream

‧40GbE：3個vMotion Stream

‧50GbE：4個vMotion Stream

‧100GbE：7個vMotion Stream

針對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所示。

根據VMware官方測試結果，新式CPU調度程序針對不同的工作負載，相較於前一版本vSphere 7.0 U1環境，在工作負載效能表現上都能有所提升，如圖10所示，最多甚至能夠提升至50%的運作效能。

vTPM正式支援Linux虛擬主機

在現代化作業系統中，TPM（Trusted Platform Module）機制已經是基本的必須功能，舉例來說，在微軟最新的Windows 11作業系統中，必須先確認硬體已經支援TPM機制才能安裝。

然而，在過去的vSphere版本中，雖然支援vTPM（Virtual Trusted Platform Module）機制，讓VM虛擬主機工作負載能夠直接使用TPM，但是僅限於採用Winodws客體作業系統的VM虛擬主機。現在，最新版本的vSphere 7.0 U2版本，vTPM機制正式支援採用Linux客體作業系統的VM虛擬主機，如圖11所示。

大量減少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虛擬主機的運作狀態。

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所示。

現在，最新版本的vSphere已經支援VM虛擬主機採用Persistent Memory時，仍然能夠被vSphere HA高可用性機制所保護，如圖14所示。值得注意的是，VM虛擬主機必須採用虛擬硬體版本「19」，並且不能使用vPMemDisks機制的VM虛擬主機，才能順利地被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 Tools GuestStore

在本文實戰演練小節中，將實作最新發佈的VMware Tools GuestStore機制，這是一項VMware官方針對眾多使用者提出的意見回饋功能請求，所實作出來讓VM虛擬主機能夠安全且直接存取資料的一種新方式。

簡單來說，在vSphere虛擬化基礎架構中運作的VM虛擬主機，在確認已經安裝VMware Tools之後，即可透過VMware Tools GuestStore機制，快速存取由管理人員集中管理和準備的各種類型檔案，例如VMware Tools、代理程式、二進位檔案、組態設定檔等等，達成安裝、更新、升級等等動作，如圖16所示。

但必須留意的是，目前GuestStore僅支援Windows作業系統的VM虛擬主機，安裝VMware Tools的Linux作業系統虛擬主機暫不支援。此外，雖然支援各種類型檔案存放於GuestStore內，但是每個檔案大小必須「小於512MB」才行。

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，有效提升回應速度和傳輸效率。

組態設定GuestStore Repository路徑

了解VMware Tools GuestStore運作架構後，開始著手為ESXi虛擬化平台，組態設定GuestStore Repository存放機制。首先，管理人員必須到VM虛擬主機上，為稍後所要存取的共用Datastore儲存資源中，建立資料夾並放置相關檔案。在本文實作環境中，於共用的NFS Datastore儲存資源中，建立名稱為「tools」的資料夾，並在「Edge」子目錄內放置Windows Server預設未安裝的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所示。

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虛擬主機符合條件後，即可開啟命令提示字元，並切換至「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所示。

實作至此，可能許多管理人員會有困惑，這樣存取檔案的方式與傳統NAS存取方式相較之下，似乎也沒有比較便利或安全啊？事實上，當Windows虛擬主機執行指令，嘗試拉取GuestStore Repository內的相關檔案時，並非像存取傳統NAS儲存資源採用乙太網路傳輸的方式，而是透過Windows虛擬主機內的VMware Tools，直接與底層的ESXi虛擬化平台溝通並執行拉取檔案的動作。

因此，管理人員可以再次進行測試，在Windows虛擬主機再次拉取GuestStore Repository內相關檔案之前，先停用Windows虛擬主機的網路卡，確認無法透過乙太網路進行資料傳輸後，再次執行拉取GuestStore Repository路徑中檔案的動作，可以發現仍然能夠順利拉取檔案，如圖20所示。

後續，還可以在ESXi主機中查看「/var/logs/gstored.log」，在Windows虛擬主機中查看「C:\Windows\Temp\vmware-vmsvc-SYSTEM.log」，以便觀察GuestStore運作和檔案存取的日誌內容。

透過上述實作演練後，管理人員應該可以理解，為何說VMware Tools GuestStore機制是一種安全且直接存取資料的新方式，因為這樣的應用方案是在某些極度封閉且強調高安全性的運作環境中，能夠在持續封閉且不失高安全性的情況下，同時又能達到交換檔案的一種新方式。

結語

透過本文的深入剖析和實作演練後，相信大家已經了解最新發佈的vSphere 7.0 Update 2版本有哪些亮眼新功能和運作架構及原理，讓企業和組織可以評估哪些功能適合導入至新專案當中。此外，帶領大家實作演練新版本當中，最新發佈的VMware Tools GuestStore功能提供給VM虛擬主機安全且直接存取資料的方式，讓企業內部資料中心中某些極度封閉且高安全性的環境，在不失高安全性的情況下還能達到交換檔案的目的。

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