善用vSphere 7優勢　建構高效能基礎架構

根據最新Flexera 2020 State of the Cloud Report市調結果顯示，企業和組織已經有高達98%的比例使用雲端技術，其中採用公有雲的比例高達96%，採用地端私有雲的企業組織也有76%的比例，如圖1所示。

雖然，目前因為COVID-19疫情的關係，讓企業採用公有雲服務的比例增加，如圖2所示。然而，從市調結果可知，仍然有許多企業在內部資料中心內，透過虛擬化或容器技術承載各種營運服務所需的工作負載。

因此，本文將針對目前企業組織中，地端資料中心內市占率最高的VMware vSphere虛擬化基礎架構，提供不同層面的最佳化和組態設定技巧，幫助管理人員確保VM虛擬主機或容器內應用程式效能和回應速度之外，也讓企業不因COVID-19疫情的影響而降低服務品質。

x86硬體伺服器規劃

事實上，從vSphere ESXi 4.x版本開始便為64位元的運作環境，因此在採購x86硬體伺服器的64位元CPU中央處理器時，選擇具備更多「定址空間」和大容量「L2/L3/L4快取」空間的CPU中央處理器，以便擔任vSphere虛擬化技術架構的ESXi虛擬化平台，能夠擁有更多定址空間和CPU指令集，屆時提供上層運作的VM虛擬主機和容器更多的運算資源。

此外，管理人員在選擇CPU中央處理器時可能遭遇的另一個難題，便是要選擇「多運算核心」（Multiple Cores）或「高時脈」（Highest Clock）類型的處理器？事實上，這兩種類型的CPU處理器有不同的適用情境，舉例來說，如果運作的工作負載屬於「單一執行緒」（Single-Thread）類型，應該選擇「高時脈」類型的CPU處理器，因為這種類型的工作負載給予多個運算核心也無濟於事。反觀，應用程式若屬於「多重執行緒」（Multi-Thread）類型時，則建議選擇「多運算核心」類型的CPU處理器，讓VM虛擬主機或容器中的應用程式，能夠透過多個運算核心達到平行運算，進而為工作負載提供最佳化的運算效能。

值得注意的是，當企業和組織選擇多運算核心的CPU處理器，例如新一代AMD EYPC處理器時，必須注意ESXi軟體授權的部分，因為從2020年4月30日開始，每顆ESXi CPU處理器軟體授權只要超過「32核心」，便需要加買CPU處理器軟體授權，如圖3所示。

深度學習效能最佳化

此外，當企業組織需要在vSphere虛擬化術架構中，運作「向量神經網路指令集」（Vector Neural Network Instructions，VNNI）深度學習技術時，在選擇CPU處理器時可以考慮針對這類型工作負載最佳化的CPU處理器。

舉例來說，第一代Intel Xeon Scalable「Skylake」處理器，與第二代的「Cascade Lake」處理器相較之下，由於Cascade Lake處理器針對VNNI指令集的全面支援，以及最佳化相關工作負載如int8和fp32。因此，在運算同樣深度學習訓練模型的工作負載之下，採用第二代Cascade Lake處理器可提升「2.x～3.x倍」的執行效能，如圖4所示。更多詳細的測試結果，可參考VMware技術白皮書「Optimize Virtualized Deep Learning Performance with New Intel Architectures」。

UEFI最佳化組態設定

在x86硬體伺服器UEFI組態設定方面，應該依照伺服器供應商的最佳建議組態設定進行調整，確保安裝ESXi虛擬化平台的硬體伺服器，在運作效能方面能夠保持最佳化。舉例來說，許多x86硬體伺服器的UEFI預設值，可能不會啟用「VT-x」硬體輔助虛擬化技術，並且在電力使用方面也會採用「C States」節省電源的組態設定。

然而，此舉將會因為其上運作的VM虛擬主機或容器效能並未最佳化，而導致應用程式回應卡頓造成使用者體驗下降。因此，建議參考硬體伺服器供應商管理手動，當伺服器用途為擔任虛擬化平台時UEFI的最佳化組態設定為何。

如圖5所示，可以看到此伺服器的UEFI預設值選項為「General Power Efficient Compute」，因此「VT-x」虛擬化技術未啟用，並且啟用「C6 Retension」節省電源的組態設定。管理人員應調整為「Virtualization – Max Performance」選項，讓系統「啟用」VT-x虛擬化技術並「停用」C States電源節省的組態設定，讓運作效能方面能夠極大化，確保其上運作的VM虛擬主機和容器運算資源充足。

ESXi和VM虛擬主機最佳化組態設定

妥善規劃ESXi用途的硬體伺服器後，管理人員可以針對ESXi虛擬化平台和VM虛擬主機層級進行最佳化。舉例來說，在ESXi虛擬化平台網路堆疊最佳化的部分，管理人員可透過ESXCLI（vSphere Command-Line Interfaces）管理指令，組態設定最佳化網路工作負載。

管理人員可以為ESXi虛擬化平台的實體網路卡啟用「TCP分割卸載」（TCP Segmentation Offload，TSO）功能，除了能夠極大化網路封包傳輸效能外，還可同時降低ESXi虛擬化平台處理網路封包時的運算資源耗損。如圖6所示，管理人員可以透過「esxcli system settings advanced list -o /Net/UseHwTSO」指令，查詢「Int Value」欄位是否為數值「1」，確保TCP分割卸載功能已經啟用。有關TCP分割卸載功能和其他最佳化網路組態設定的詳細資訊，可參考VMware KB 2055140、KB 1038827說明。

ESXi本機磁碟空間重新規劃

過去的ESXi版本，在安裝流程中系統會針對本機磁碟空間建立固定大小的分割區，然而卻存在一些支援限制。因此，從新版ESXi 7.0開始，系統針對本機磁碟空間有不同的規劃，除了更方便支援第三方解決方案之外，合併後的系統分區也將更容易進行擴充。

簡單來說，從ESXi 7.0版本開始，本機磁碟區僅劃分出「四個」系統分割區，分別是System boot、Boot-banks、ESX-OSData以及VMFS Datastore，其中「ESX-OSData」又區分出ROM-data和RAM-data，過去舊版ESXi的VMware Tools Locker、Core Dump、Scratch，便是合併到ESX-OSData中的ROM-data分割區內，如圖7所示。

此外，過去習慣使用USB或SD Card安裝ESXi虛擬化平台的管理者，可能會發現安裝新版ESXi 7之後，無法看到任何VMFS Datastore分割區？原因在於，新版ESXi 7版本中的ESX-OSData系統分割區，最大會占用「128GB」儲存空間，如圖8所示，並且當本機磁碟劃分完預設系統分割區之後，剩餘空間至少要大於「4GB」時才會額外建立「VMFS-6 Datastore」。簡單來說，當安裝ESXi 7.0的本機硬碟空間「小於142GB」，系統便不會建立VMFS-6 Datastore。

值得注意的是，當新版ESXi 7.0找不到本機磁碟時，將會採用「降級模式」（Degraded Mode）運作並禁用某些系統功能，同時「/scratch」分割區將會直接連接到「/tmp」掛載點。因此，在VMware官方最佳建議作法中，為了確保ESXi能夠極大化效能和資源調度，避免採用降級模式運作ESXi虛擬化平台。

最佳化ESXi電源管理原則

如前所述，在x86硬體伺服器的UEFI組態設定中，調整為採用「Virtualization – Max Performance」選項，讓硬體效能層級的效能方面能夠極大化。

然而，ESXi虛擬化平台層級也必須要互相搭配才能相得益彰，舉例來說，ESXi預設電力原則組態設定值為「Balanced」，這表示ESXi虛擬化平台會感知並使用硬體伺服器的節省電源功能，讓ESXi無法發揮最大效能，因此將ESXi電力原則設定值調整為「High performance」，如圖9所示，不使用任何硬體伺服器的節省電源功能，確保ESXi層級的電源管理設定和硬體伺服器互相搭配，達到效能最大化的效果。

採用新式SCAv2資源調度機制

由於Intel CPU處理器爆發嚴重的L1TF漏洞攻擊，所以從ESXi 6.7 U2版本之後支援新式「SCAv2」（Side-Channel Aware Scheduler v2）資源調度機制，除了確保運作於ESXi虛擬化平台上，VM虛擬主機和容器內的服務不受L1TF漏洞影響之外，也能確保VM虛擬主機和容器能夠完整使用多個運算核心，確保運作效能不受影響。

舊有的SCAv1資源調度機制，僅能避免VM虛擬主機和容器不受L1TG漏洞影響，但運作效能卻至少下降30%。有關SCAv1和SCAv2資源調度差異的詳細資訊，請參考VMware KB 55806文章內容。

如圖10所示，採用新版SCAv2資源調度機制時，除了能夠不受L1TF漏洞影響外，與舊版SCAv1運作相同的工作負載，例如HammerDB on SQL Server，更能確保運作效能不受影響。

值得注意的是，新版ESXi 7.0預設組態設定並未採用新版SCAv2資源調度機制，管理人員可以在登入vCenter Server管理介面後，依序點選「Datacenter > Cluster > ESXi Host > Configure > System > Advanced System Settings」項目，組態設定「VMkernel.Boot.hyperthreadingMitigation = true」以及「VMkernel.Boot.hyperthreadingMitigationIntraVM = false」，如圖11所示。重新啟動ESXi主機，以便套用生效。

CRX虛擬主機 - 最佳化容器運作環境

在過去的vSphere虛擬化基礎架構中，管理人員若要建立Kubernetes叢集，必須在ESXi虛擬化平台中透過「Hypervisor」機制，將底層x86硬體伺服器資源抽象化後，提供給上層VM虛擬主機使用，然後在VM虛擬主機中安裝Linux作業系統，再建構Kubernetes叢集並運作容器等工作負載，接著透過vSphere叢集提供硬體資源，給上層傳統VM虛擬主機和容器進行資源調度，如圖12所示。

現在，新版的vSphere 7 with Kubernetes運作架構，則採用新世代叢集運作架構「Supervisor」。簡單來說，過去vSphere虛擬化基礎架構僅能建構傳統的Kubernetes叢集，而Supervisor Cluster新世代叢集，則內建整合於ESXi中並將傳統管理工具Kubelet整合為「Spherelet」。

值得一提的是，在Supervisor Cluster中運作的vSphere Pod，以及vSphere Pod內運作的1個或多個容器，都是在獨立的VM虛擬主機中運作稱為「CRX」，除了提供容器更好的安全性隔離環境之外，因為CRX虛擬主機採用「Container Runtime for ESXi」的設計，包括Linux核心也都經過最佳化調校，所以能為容器工作負載提供最佳運作環境，如圖13所示。

在vSphere Pod運作規模的部分，每個Supervisor Cluster最多可運作8,000台CRX虛擬主機，每台ESXi成員主機可運作1,000台CRX虛擬主機，如圖14所示。在CRX虛擬主機方面，它能夠在「100ms」內便啟動完成，相較於在傳統VM虛擬主機內安裝Linux作業系統，並組態設定Container Runtime是很難達成的。最後，在VMware官方測試結果中，CRX虛擬主機內的容器運作Java工作負載時，相較於傳統的Kubernetes Pod傳輸量多出「30%」，相較於裸機運作的Linux主機也多出「8%」的效能。

全新vSphere DRS v2.0自動化負載平衡機制

全新打造的vSphere 7在叢集特色功能中，也增強原有的運作機制以便因應新世代的工作負載。舉例來說，自動化負載平衡機制「vSphere DRS」，第一版在2006年時首度發佈。時至今日，最新vSphere 7版本的DRS為了因應現代化工作負載，同樣也進行相對應的功能改進和增強。簡單來說，過去的vSphere DRS v1.0著重在「叢集」（Cluster），而新版vSphere 7 DRS v2.0則著重在「工作負載」（Workload）的部分，以便最佳化調度VM虛擬主機、Pods、容器等等工作負載。

新版vSphere 7 DRS v2.0自動化工作負載平衡邏輯，採用「Goodness Modelling」運作機制，不將資源負載平衡的重點放在「叢集中ESXi成員主機」，而是將工作負載平衡的焦點放在「VM虛擬主機」身上，並且舊版的vSphere DRS v1.0為「每隔5分鐘」判斷一次資源平衡狀態，而新版vSphere DRS v2.0則改為「每隔1分鐘」便檢查一次VM虛擬主機的資源平衡狀態，計算叢集中運作的VM虛擬主機工作負載得分「VM DRS Score」，然後判斷以vMotion線上遷移VM虛擬主機後，對於其他VM虛擬主機的影響為何，以達成最佳化且更細緻的資源使用率。

VM DRS Score的得分範圍共有五個部分，分別是0-20%、20-40%、40-60%、60-80%、80-100%，當VM虛擬主機被系統判定得分為80-100%時，表示這台VM虛擬主機的資源使用情況良好未發生資源爭奪的情況，如圖15所示。

增強式DRS動態資源調整

新版vSphere DRS v2.0自動化負載平衡機制，除了針對不同工作負載進行最佳化負載平衡調度外，新增「DRS with Scalable Shares」的增強功能，可以有效改善過去Resource Pool規劃上可能出現盲點的問題，確保VM虛擬主機和容器可以取得高份額資源。

舉例來說，叢集中CPU運算資源總共為「30GHz」，其中管理人員建立二個Resource Pool（Dev/Production），其中Resource Pool 1（Dev）設定的CPU Shares為「normal」，總共取得三分之一的資源（也就是10GHz），而Resource Pool 2（Production）的CPU Shares則為「high」，總共取得三分之二的資源（亦即20GHz），如圖16所示。

然而，因為運作在Resource Pool 2中有「二台」VM虛擬主機，所以每台也是取得「10GHz」運算資源，與Resource Pool 1的VM虛擬主機取得一樣的資源，假設Resource Pool 2中運作「四台」VM虛擬主機時，那麼結果將會更慘，因為每台VM虛擬主機僅能分得「5GHz」的運算資源。

現在，同樣的Resource Pool組態設定，但是啟用「DRS with Scalable Shares」增強功能後，由於vSphere 7 DRS v2.0採用增強的「動態計算」（Dynamically Calculates）運作機制，所以同樣的VM虛擬主機數量，管理人員可以發現在Resource Pool 1（Dev）中的VM虛擬主機取得「6GHz」運算資源，而Resource Pool 2的二台VM虛擬主機分別取得「12GHz」運作資源，有效改善過去Resource Pool規劃上可能出現盲點的問題，如圖17所示。

那麼管理人員如何啟用DRS with Scalable Shares增強功能？在vCenter Server管理介面中，依序點選「Cluster > Configure > vSphere DRS > Edit > Additional Options」項目，然後勾選「Enable scalable shares for the resource pools on this cluster」選項即可，如圖18所示。

實戰演練vCenter Server自動化更新機制

在過去的vCenter Server版本中，針對vCenter Server進行更新或安全性修復的時候，需要管理人員手動介入並執行相關指令才行。

現在，透過新版vCenter Server 7 Update Planner機制，將過去管理人員手動查詢新版、確認更新版本相容性、版本升級資訊等等工作，全部合併在vCenter Server管理介面之中，並且在自動化處理的工作流程中，達到vCenter Server生命週期管理的目的。

值得注意的是，Update Planner機制僅支援新版vCenter Server 7和後續更新版本，無法支援舊版vCenter Server 6.x升級至新版vCenter Server 7，並且管理人員必須啟用「VMware使用者體驗改善計畫」（VMware Customer Experience Improvement Program，CEIP）後，如圖19所示，才能順利使用Update Planner更新機制。

簡單來說，Update Planner更新機制，可以幫助管理人員管理vCenter Server的更新和版本升級，同時還能建立相容性報表。登入vCenter Server管理介面後，按下〔VIEW UPDATES〕或〔Updates Available〕按鈕，系統便會自動觸發執行vCenter Server Update Planner更新機制，如圖20所示。

在Update Planner視窗中，如圖21所示，可以看到適合vCenter Server更新的版本、Build number、類型、嚴重程度、發行說明等等，以及最重要的此更新是否需要重新啟動vCenter Server。

倘若「Reboot Required」欄位為「Yes」時，那麼管理人員應該挑選離峰或維護時間進行vCenter Server的更新作業，並重新啟動vCenter Server以便套用生效。

接著，登入vCenter Server系統管理介面（Port 5480），可以看到目前vCenter Server版本為「7.0.0.10100」，也就是vCenter Server GA版本，而最近的更新則是「7.0.0.10400」，也就是vCenter Server 7.0b版本。在安裝更新之前，管理人員可以按下Pre-update checks欄位的「RUN PRE-UPDATE CHECKS」。通過系統檢查作業狀態為「Passed」後，如圖22所示，便可以準備下載和安裝vCenter Server更新。有關vCenter Server版本和Build Number的詳細對應資訊，可參考VMware KB 2143838文章內容。

通過檢查之後，按下「STAGE AND INSTALL」並同意使用者授權條款，系統就會再次提醒管理人員，執行更新作業之前必須先備份vCenter Server，以避免發生非預期的錯誤造成vCenter Server運作失敗。

備份作業完成之後，勾選「I have backed up vCenter Server and its associated databases.」項目，如圖23所示，即可按下〔Finish〕按鈕開始執行vCenter Server更新下載和安裝作業。

如圖24所示，順利下載更新並安裝完成，接著重新整理管理介面，即可看到，vCenter Server版本從原本的「7.0.0.10100」，順利更新為最新釋出的「7.0.0.10400」版本，如圖25所示。

結語

透過本文的深入剖析和實作演練，大家已經了解全新vSphere 7無論在vSphere基礎架構，或是vCenter Server管理平台及VM虛擬主機和容器層級，都增加許多亮眼特色功能或增強原有機制。

值得注意的是，管理人員在一開始規劃x86硬體伺服器時，在規格選擇上以及BIOS/UEFI針對虛擬化組態的部分，是比較容易疏忽的地方，只要注意這些小細節並搭配最佳化組態設定，定能輕鬆打造出高效能和高可用性的vSphere虛擬化基礎架構。

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