網管人 166 期 - 實作 vSphere 6.7 最佳化高效與高安全性兼備

網管人雜誌

本文刊載於 網管人雜誌第 166 期 - 2019 年 11 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。






前言
BIOS 組態設定最佳化
          ESXi 主機網路組態設定最佳化
新增 SCAv2 調度選項有效改善執行效能
          阻擋 L1TG 漏洞的安全性邊界防護機制
          如何採用新式 SCAv2 調度程序
增強 DRS 調度工作負載
          增強初始化放置機制
          增強主機維護模式
          支援採用 vPMem 和 vPMemDisk 的虛擬主機
          增強資源集區預留機制
結語

前言

雖然，企業和組織已經將內部資料中心上雲，並且採取搭配多個雲端供應商的策略，為企業和組織的營運服務提供最佳的可用性。然而，在企業內部的資料中心內，或多或少仍有工作負載運作在虛擬環境上，或是尚未上雲的企業在內部的工作負載大多運作在虛擬化環境中。

根據 Flexera 最新的 2019 State of the Cloud Report 市調結果顯示，企業和組織已經有高達 94 %的比例使用相關雲端技術，其中高達 91 % 的比例為採用公有雲，而採用私有雲的企業和組織也仍然有 72 %比例之多（如圖 1 所示）。


從調查結果可知，仍然有許多企業和組織在內部資料中心內，透過虛擬化技術運作各種營運服務的工作負載。然而，虛擬化環境是否最佳化，將會大大影響運作於其上的 VM 虛擬主機，以及 VM 虛擬主機內執行的應用程式效能和回應速度。

因此，本文將針對目前企業和組織中，主流使用的 VMware 虛擬化環境提供多種最佳化使用技巧，除了確保營運服務能夠提供高效能之外，更能因此運作更多的工作負載在虛擬化環境中。

BIOS 組態設定最佳化

首先，在硬體伺服器的 BIOS 組態設定方面，建議依照下列組態設定值，以確保安裝 ESXi 虛擬化平台的硬體伺服器，在運作效能方面能夠保持最佳化，舉例來說，在硬體伺服器的 BIOS 層級上，便將 C States 和 C1E 等節省電源的組態設定停用，避免無謂的省電措施影響屆時 VM 虛擬主機的運作效能和回應速度。

• Power Management：建議調整為 OS Controlled或 High Performance。
• Hyperthreading：建議調整為 Enabled。
• Turbo Boost：建議調整為 Enabled。
• C States：建議調整為 Disabled。
• C1E：建議調整為 Disabled。
• Intel VT technology：建議調整為 Enabled。
• QPI Power Management：建議調整為 Disabled。
• Execute Disable Bit：建議調整為 Enabled。
• Node Interleaving：建議調整為 Disabled。

ESXi 主機網路組態設定最佳化

針對 ESXi 主機網路組態設定的部份，我們將會採用 esxcli（vSphere command-line interface）管理指令，進行 ESXi 主機網路組態設定最佳化的工作任務。

首先，請透過「esxcli network nic list」指令，確認目前 ESXi 主機中實體網路卡數量以及相關資訊，例如，MTU 為標準的 1500或是已開啟 Jumbo Frame的 9000。接著，透過「esxcli network nic get -n vmnic0」指令，查看指定實體網路卡的名稱的詳細組態設定內容（如圖 2 所示）。



啟用 TSO 卸載功能
啟用實體網路卡卸載功能，除了最大化網路傳輸效能之外，也能避免 ESXi 主機的 CPU 運算資源無謂的開銷，確保屆時營運服務能夠獲得最充足的 CPU 運算資源。

首先，為 ESXi 主機的 VMkernel 啟用TSO（TCP Segmentation Offload）網路卸載功能，確保網路卡能夠以較大的網路封包（最大至 64 KB）進行傳送，以減少 ESXi 主機處理 TCP/IP 網路封包的 CPU 工作負載。

請透過「esxcli network nic tso get」指令，確認 ESXi 主機的實體網路卡支援 TSO 卸載功能，接著執行「esxcli system settings advanced set -o /Net/UseHwTSO -i 1」指令，在 ESXi kernel 進階組態設定中，將 TSO 卸載功能組態設定為啟用，然後執行「esxcli system settings advanced list -o /Net/UseHwTSO」指令，確保 Int Value 欄位值為「1」即表示啟用 TSO 卸載成功（如圖 3 所示）。

有關啟用和停用 TSO 網路卸載機制的詳細資訊，請參考 VMware KB 2055140文章內容。

啟用 CSO 總和檢查碼卸載功能
在網路封包 TCP Header 中包含 16-bit 的總和檢查碼機制，以便驗證網路封包的完整性，透過啟用CSO（Checksum Segment Offload）網路卸載機制，可以讓計算和驗證網路封包完整性的工作任務，由實體網路卡處理以減少 ESXi 主機的 CPU 工作負載。

請透過「esxcli network nic cso set -n vmnic0 -e 1」指令，為 ESXi 主機的實體網路卡啟用 CSO 網路卸載機制後，執行「esxcli network nic cso get」指令，確保指定的實體網路卡是否已經啟用 CSO 網路卸載機制（如圖 4 所示）。



停用 LRO 大型接收卸載功能
雖然，透過 LRO（Large Receive Offload）網路卸載機制，可以將接收的網路封包重新組合為更大的緩衝區後，將大型且數量較少的網路封包進行傳送，以達到減少 ESXi 主機 CPU 工作負載的好處。然而，對於「網路延遲敏感」（Network Latency-Sensitive）的營運服務來說，會有回應速度變慢的情況，針對這類型的營運服務我們建議停用 LRO 網路卸載機制。

請透過「esxcli system settings advanced set -o /Net/TcpipDefLROEnabled -i 0」指令，為 ESXi 主機的實體網路卡停用 LRO 網路卸載機制後，執行「esxcli system settings advanced list -o /Net/TcpipDefLROEnabled」指令，確保指定的實體網路卡是否已經停用 LRO 網路卸載機制（如圖 5 所示）。

有關啟用和停用 LRO 網路卸載機制的詳細資訊，請參考 VMware KB 2055140文章內容。

新增 SCAv2 調度選項有效改善執行效能

在最新 VMware vSphere 6.7 U2版本中，新增不同的「調度選項」（Scheduler Options），除了能夠保護 VM 虛擬主機免於遭受採用 Intel 處理器的 L1TF 漏洞攻擊之外，新的工作負載調度選項能夠針對不同的工作負載，在避免安全性攻擊的同時維持過往高運作效能的表現。

有關 VMware 虛擬化環境修補 L1TF 漏洞的詳細資訊，請參考 VMSA-2018-0020安全建議和 KB 55806文章內容。

主要原因在於，在新的調度選項尚未發佈之前，依照 VMware 安全建議內的修補程序進行調整後，將會採用「SCAv1」（Side-Channel Aware Scheduler）調度機制，避免 VM 虛擬主機受到 L1TF 漏洞的影響產生安全性疑慮。

然而，啟用 SCAv1 運作機制後，每個 CPU 處理器的實體核心將僅能處理「一個執行緒」而已，雖然能夠解決 L1TF 漏洞產生的安全性疑慮，卻導致 vSphere ESXi 虛擬化平台的運作效能「下降 30 %」。因此，在最新 VMware vSphere 6.7 U2版本中，推出新的「SCAv2」調度選項允許同時處理多個執行緒，讓 VM 虛擬主機的工作負載效能提升。

如圖 6 所示，在上半部圖中可以看到當單台 VM 虛擬主機運作時，無論採用舊有 SCAv1 或新式 SCAv2 調度選項，都會在分配單一 vCPU 至底層 CPU 處理器的實體核心上。

然而，在下半部圖中可以看到，當多台 VM 虛擬主機同時運作的情況下，採用預設未修補的調度選項，可能會讓同一個底層 CPU 處理器的實體核心，運作來自不同台 VM 虛擬主機的 vCPU 而遭受 L1TF 漏洞攻擊，而採用「舊式的 SCAv1」調度選項時，雖然可以確保同一個底層 CPU 處理器的實體核心，僅會運作來自同一個 VM 虛擬主機的 vCPU，但是只能處理「一個執行緒」而已，然而採用「新式的 SCAv2」調度選項時，除了兼顧 VM 虛擬主機安全性之外，更可以處理多個執行緒有效提升 VM 虛擬主機運作效能。


那麼舊式的 SCAv1 和新式的 SCAv2 工作負載調度選項，在各種不同的工作負載中效能表現的差異究竟有多少？ 從 VMware 的測試結果中可以看到，以 SQL Server on Windows with HammerDB 項目來看，相較於舊式的 SCAv1 工作負載調度選項，新式的SCAv2 提升「32 % ~ 54 %」的運作效能（如圖 7 所示）。

阻擋 L1TG 漏洞的安全性邊界防護機制

事實上，由於 L1TF 漏洞是落在底層的 CPU 處理器層級，因此在 vSphere 虛擬化平台以及其上運作的 VM 虛擬主機，必須針對不同的層級進行防護，才能有效確保 VM 虛擬主機的機敏資料不會外洩。整體來說，針對 L1TF 漏洞的防護層級有三個安全性邊界的部份，分別是「ESXi 主機、VM 虛擬主機、vCPU 處理器」。

首先，針對 vSphere ESXi 虛擬化平台提供「主機安全性邊界」（Host Security Boundary）防護機制（如圖 8 所示），可以針對 ESXi 虛擬化平台和其上運作的 VM 虛擬主機，視為整個安全性邊界進行防護，然而僅採用主機安全性邊界防護機制時，倘若 ESXi 主機被感染而遭受 L1TF 漏洞時，那麼攻擊者將可以透過被感染的 ESXi 主機，獲得其上運作所有 VM 虛擬主機的機敏資訊，包括，網域憑證、加密金鑰 …… 等。

預設情況下，ESXi 主機的工作負載調度選項為「hyperthreadingMitigation = FALSE」時，便是啟用主機安全性邊界防護機制。

接著，針對 VM 虛擬主機提供「VM 虛擬主機安全性邊界」（VM Security Boundary）防護機制（如圖 9 所示），可以針對同一台 ESXi 虛擬化平台上，不同的二台 VM 虛擬主機之間提供攻擊防護。當 ESXi 主機的工作負載調度選項，組態設定為「hyperthreadingMitigation = TRUE」和「hyperthreadingMitigationIntraVM = FALSE」時，便是啟用 VM 虛擬主機安全性邊界防護機制。簡單來說，採用 VM 虛擬主機安全性邊界防護機制後，除了獲得主要的安全性防護功能外更兼顧運作效能。


最後，管理人員可以針對 VM 虛擬主機中，運作的執行程序提供「執行程序安全性邊界」（VM Security Boundary）防護機制（如圖 10 所示），當 ESXi 主機的工作負載調度選項，組態設定為「hyperthreadingMitigation = TRUE」和「hyperthreadingMitigationIntraVM = TRUE」時，便會啟用執行程序安全性邊界防護機制。簡單來說，採用執行程序安全性邊界防護機制後，可以為 VM 虛擬主機提供最高的安全性等級，但是必須犧牲 VM 虛擬主機大量的運作效能來換取最佳安全性。

如何採用新式 SCAv2 調度程序

那麼，管理人員應該如何組態設定 ESXi 主機的工作負載調度機制，採用新版 vSphere 6.7 U2 才開始支援的 SCAv2 工作負載調度選項，以便兼顧 VM 虛擬主機的安全性和運作效能。在下列表格中，為各位讀者整理工作負載調度機制組態設定一覽表：

工作負載調度機制和參數值	hyperthreadingMitigation	hyperthreadingMitigationIntraVM
預設值（未進行防護）	FALSE	TRUE 或 FALSE
SCAv1	TRUE	TRUE
SCAv2	TRUE	FALSE

管理人員可以登入 vCenter Server 管理介面後，依序點選「Datacenter > Cluster > ESXi Host > Configure > System > Advanced System Settings」項目，組態設定「VMkernel.Boot.hyperthreadingMitigation = true」和「VMkernel.Boot.hyperthreadingMitigationIntraVM = false」後（如圖 11 所示），重新啟動該台 ESXi 主機以便套用生效，採用新式的 SCAv2 工作負載調度選項。

請注意 !必須採用 vSphere ESXi 6.7 U2（13006603）或後續版本，才能支援新式的 SCAv2 工作負載調度選項，其餘舊版 ESXi 6.0、6.5、6.7 僅支援舊式 SCAv1工作負載調度選項。

倘若，管理人員習慣使用指令管理 ESXi 主機組態設定時，請採用下列「esxcli system settings kernel <set | list>」指令（如圖 12 所示），組態設定 ESXi 主機採用新式的 SCAv2 工作負載調度選項，並再確認組態設定值無誤後，重新啟動以便套用生效。

增強 DRS 調度工作負載

事實上，從新版 vSphere 6.7 版本開始，在 DRS（Distributed Resource Scheduler）的部份便增強原有機制，讓 DRS 在調度 VM 虛擬主機工作負載方面能夠更彈性更靈活。

增強初始化放置機制

在過去的 vSphere 版本中，當 vSphere Cluster 啟動 DRS 分佈式資源調度機制之後，除了可能耗用更多的 vCenter Server 硬體資源之外（如圖 13 所示），在某些情況下也無法快速的啟動和放置 VM 虛擬主機，舉例來說，在多個同時併發的高工作負載運作環境下，新版 vSphere 6.7 的 DRS 運作環境將能更快的啟動 VM 虛擬主機，並且能更平均的擺放 VM 虛擬主機至每台 ESXi 叢集節點主機中。

增強主機維護模式

在 vSphere 虛擬化環境中，當管理人員透過 vUM 更新管理機制結合 DRS 進行版本升級作業時，必須依靠 DRS 智慧演算法建議可以進入維護模式的 ESXi 節點主機，並且將其上運作的 VM 虛擬主機，透過 vMotion 線上遷移機制進行工作負載疏散的動作。

然而，在過去的 DRS 版本中，將會「同時」對所有運作中的 VM 虛擬主機進行 vMotion 線上遷移作業，造成大量併發的 vMotion 網路流量，有可能產生不可預期的錯誤和隱憂。現在，DRS 透過增強的主機維護模式，將會針對 VM 虛擬主機進行分批遷移的動作（每次僅遷移 8 台 VM 虛擬主機），同時受惠於分批遷移機制讓遷移後的 VM 虛擬主機，能夠更平均的分佈於 Cluster 當中的每台 ESXi 叢集主機上繼續運作。

支援採用 vPMem 和 vPMemDisk 的虛擬主機

新一代的 NVM（Non-Volatile Memory）持續性記憶體儲存裝置，由於提供類似 DRAM 的超低延遲時間和極大傳輸頻寬，而被企業和組織開始應用於關鍵性的營運服務中。當 ESXi 虛擬化平台配置 PMEM（Persistent Memory）儲存裝置時，支援下列二種 VM 虛擬主機掛載應用方式（如圖 14 所示）：

• vPMemDisk：透過此運作模式，可以將 PEME 儲存資源掛載至 VM 虛擬主機成為 vDisk 虛擬磁碟。因此，VM 虛擬主機內的作業系統和應用程式無須進行任何修改，即可使用 PMEM 儲存資源。
• vPMem：將 PMEM 儲存資源以 NVDIMM 儲存裝置提供給 VM 虛擬主機，大部份新版的作業系統，例如，Windows Server 2016、RHEL 7.4……等，皆支援 NVDIMM 儲存裝置。

值得注意的是，當管理人員為 VM 虛擬主機掛載使用 vPMemDisk 時，在 VM 虛擬主機組態設定方面，請確保該 vDisk 虛擬磁碟中的 VM Storage Policy 必須設定為「Host-local PMem Default Storage Policy」，當 VM 虛擬主機掛載使用 vPMem 時，則必須先新增 NVDIMM 儲存控制器後，再新增「NVDIMM 儲存裝置」（如圖 15 所示）。


了解 vMotion 線上遷移機制的管理人員應該了解，當 VM 虛擬主機採用標示為本地端的儲存資源時，必須搭配採用 Storage vMotion 機制才能夠遷移 VM 虛擬主機。現在，新版 DRS 分佈式資源調度機制，已經直接支援掛載使用這些新式儲存裝置的 VM 虛擬主機，因此無論是 VM 虛擬主機的自動化 vMotion 線上遷移（如圖 16 所示），進行 ESXi 節點主機工作負載平衡，或是 VM 虛擬主機啟動時的自動放置作業等都能完全支援。

增強資源集區預留機制

在新版 DRS 分佈式資源調度機制中，採用新的「兩階段演算法」（Two-Pass Algorithm），來處理「資源集區」（Resource Pool）分配資源給 VM 虛擬主機的部份。簡單來說，新的演算法在第一階段時，先在資源集區中根據 VM 虛擬主機的需求分配資源，在第二階段時依據預留和限制等組態設定值，分配相對應的資源給 VM 虛擬主機。

舉例來說，我們在新舊版本的 DRS 分佈式資源調度機制中，建立一個資源集區並指派 4 台 VM 虛擬主機於其中，同時在資源集區中記憶體的部份組態設定預留 10 GB（如圖 17 所示）。


可以看到舊版的 DRS 分佈式資源調度機制中，因為會根據需求將資源集區預留給子項目，所以 VM 虛擬主機能夠從資源集區中獲得的資源較少，而新式 DRS 分佈式資源調度機制中的 VM 虛擬主機，則可以充分獲得資源集區中所有分配的硬體資源（如圖 18 所示）。

結語

透過本文的深入剖析和實際進行最佳化組態設定後，相信讀者已經了解如何從一開始硬體伺服器的 BIOS 組態設定，到 ESXi 主機網路組態設定最佳化，並且採用新版 vSphere 6.7 U2 才支援的 SCAv2 調度選項，確保企業和組織的 vSphere 虛擬化資料中心，能夠擁有高安全性環境的同時仍然保有極佳的運作效能。