網管人雜誌
本文刊載於 網管人雜誌第 176 期 - 2020 年 9 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
根據最新 Flexera 2020 State of the Cloud Report 市調結果顯示，企業和組織已經有高達「98 %」的比例使用雲端技術，其中採用公有雲的比例高達「96 %」，採用地端私有雲的企業和組織也有「76 %」的比例（如圖 1 所示）。
採用「多雲環境」（Multi-Cloud）的比例高達 93 %，其中採用多個公有雲環境的佔比為 6 %，而採用混合雲環境的比例則高達 87 %。
圖 1、企業和組織採用雲端技術比例示意圖
圖 2、企業和組織因 COVID-19 疫情採用公有雲服務比例增加示意圖
x86 硬體伺服器規劃
事實上，從 vSphere ESXi 4.x 版本開始便為「64 位元」的運作環境。因此，在採購 x86 硬體伺服器的 64 位元 CPU 中央處理器時，請選擇具備更多「定址空間」和大容量「L2 / L3 / L4 快取」空間的 CPU 中央處理器，以便擔任 vSphere 虛擬化技術架構的 ESXi 虛擬化平台，能夠擁有更多定址空間和 CPU 指令集，屆時提供上層運作的 VM 虛擬主機和容器更多的運算資源。
有關 vSphere ESXi 版本採用 32 位元或 64 位元的詳細資訊，請參考 VMware KB 1003661、KB 1003945 文章內容。
此外，管理人員在選擇 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 所示）。
圖 3、新版 ESXi CPU 處理器軟體授權購買示意圖
深度學習效能最佳化
此外，當企業和組織需要在 vSphere 虛擬化技術架構中，運作「向量神經網路指令集」（Vector Neural Network Instructions，VNNI）深度學習技術時，在選擇 CPU 處理器時可以考慮針對這類型工作負載最佳化的 CPU 處理器。
最新 vSphere 7 版本，已經完整支援 VNNI 深度學習指令集，詳細資訊請參考 VMware KB 1003212 文章內容。
舉例來說，第一代 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」
圖 4、Skylake 和 Cascade Lake 處理器工作負載效能比較表
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 虛擬主機和容器運算資源充足。
圖 5、硬體伺服器用於虛擬化用途時 UEFI 最佳化組態設定參考
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。
圖 6、透過 ESXCLI 指令，確保網路卡啟用 TCP 分割卸載特色功能
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 所示）。
新式 ESX-OSData 分割區採用的檔案系統為「VMFS-L」，詳細資訊請參考 VMware KB 2004299、KB 77009 文章內容。
圖 7、舊版 ESXi 6.x 和新版 ESXi 7 系統分割區差異示意圖
圖 8、新版 ESXi 7.0 系統分割區儲存空間配置示意圖
值得注意的是，當新版 ESXi 7.0 找不到本機磁碟時，將會採用「降級模式」（Degraded Mode）運作並禁用某些系統功能，同時「/scratch」分割區將會直接連接到「/tmp」掛載點。因此，在 VMware 官方最佳建議作法中，為了確保 ESXi 能夠極大化效能和資源調度，請避免採用降級模式運作 ESXi 虛擬化平台。
仍然希望將 ESXi 安裝在 USB 或 SD Card 的管理人員，請參考 VMware KB 2004784 文章內容，注意安裝程序或系統分割區規劃細節。
最佳化 ESXi 電源管理原則
如前所述，在 x86 硬體伺服器的 UEFI 組態設定中，調整為採用「Virtualization – Max Performance」選項，讓硬體效能層級的效能方面能夠極大化。
然而，ESXi 虛擬化平台層級也必須要互相搭配才能相得益彰，舉例來說，ESXi 預設電力原則組態設定值為「Balanced」，這表示 ESXi 虛擬化平台會感知並使用硬體伺服器的節省電源功能，讓 ESXi 無法發揮最大效能。因此，請將 ESXi 電力原則設定值調整為「High performance」（如圖 9 所示），不使用任何硬體伺服器的節省電源功能，確保 ESXi 層級的電源管理設定和硬體伺服器互相搭配，達到效能最大化的效果。
圖 9、應該將 ESXi 電力原則設定值調整為 High performance
採用新式 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，更能確保運作效能不受影響。
圖 10、新版 SCAv2 資源調度機制不受 L1TF 漏洞影響更確保運作效能
值得注意的是，新版 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 主機以便套用生效。
管理人員也可以採用 ESXCLI 指令模式，為 ESXi 主機組態設定採用新版 SCAv2 資源調度機制，詳細資訊請參考 VMware KB 67577 文章內容。
圖 11、組態設定 ESXi 7.0 採用新版 SCAv2 資源調度機制
CRX 虛擬主機-最佳化容器運作環境
在過去的 vSphere 虛擬化基礎架構中，管理人員若要建立 Kubernetes 叢集時，必須在 ESXi 虛擬化平台中透過「Hypervisor」機制，將底層 x86 硬體伺服器資源抽象化後，提供給上層 VM 虛擬主機使用，然後在 VM 虛擬主機中安裝 Linux 作業系統後，建構 Kubernetes 叢集並運作容器等工作負載，然後透過 vSphere 叢集提供硬體資源，給上層傳統 VM 虛擬主機和容器進行資源調度（如圖 12 所示）。
圖 12、傳統 Kubernetes 運作在 vSphere 虛擬基礎架構功能比較示意圖
現在，新版 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 所示）。
圖 13、CRX 虛擬主機運作架構示意圖
圖 14、vSphere Pod、CRX 虛擬主機、容器運作架構示意圖
全新 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 的得分範圍共有 5 個部份，分別是「0-20 %、20-40 %、40-60 %、60-80 %、80-100 %」，當 VM 虛擬主機被系統判定得分為「80-100 %」時，表示這台 VM 虛擬主機的資源使用情況良好未發生資源爭奪的情況（如圖 15 所示）。
圖 15、增強後的 vSphere 7 DRS v2.0 採用 Goodness Modelling 判斷邏輯
增強式 DRS 動態資源調整
新版 vSphere DRS v2.0 自動化負載平衡機制，除了針對不同工作負載進行最佳化負載平衡調度之外，新增「DRS with Scalable Shares」的增強功能，可以有效改善過去Resource Pool規劃上可能出現盲點的問題，確保 VM 虛擬主機和容器可以取得高份額資源。
舉例來說，叢集中 CPU 運算資源總共為「30 GHz」，其中管理人員建立二個Resource Pool（Dev / Production），其中Resource Pool 1（Dev）設定的 CPU Shares 為「normal」，總共取得三分之一的資源也就是 10 GHz，而 Resource Pool 2（Production）的 CPU Shares 則為「high」，總共取得三分之二的資源也就是 20 GHz（如圖 16 所示）。
圖 16、舊版 Resource Pool 可能出現的資源調度盲點
然而，因為運作在 Resource Pool 2 中有「二台」VM 虛擬主機，所以每台也是取得「10 GHz」運算資源，與 Resource Pool 1 的 VM 虛擬主機取得一樣的資源，假設 Resource Pool 2 中運作「四台」VM 虛擬主機時，那麼結果將會更慘，因為每台 VM 虛擬主機僅能分得「5 GHz」的運算資源。
現在，同樣的 Resource Pool 組態設定，但是啟用「DRS with Scalable Shares」增強功能後，由於 vSphere 7 DRS v2.0 採用增強的「動態計算」（Dynamically Calculates）運作機制，所以同樣的 VM 虛擬主機數量，管理人員可以發現在 Resource Pool 1（Dev）中的 VM 虛擬主機取得「6 GHz」運算資源，而 Resource Pool 2 的二台VM虛擬主機分別取得「12 GHz」運作資源，有效改善過去 Resource Pool 規劃上可能出現盲點的問題（如圖 17 所示）。
圖 17、新版 Resource Pool 解決資源調度盲點
圖 18、為 vSphere 叢集啟用 DRS with Scalable Shares 增強功能
實戰演練 vCenter Server 自動化更新機制
在過去的 vCenter Server 版本中，針對 vCenter Server 進行更新或安全性修復時，需要管理人員手動介入並執行相關指令才行。現在，透過新版 vCenter Server 7 Update Planner 機制，將過去管理人員手動查詢新版、確認更新版本相容性、版本升級資訊……等，全部合併在 vCenter Server 管理介面中，並且自動化處理的工作流程內，達到 vCenter Server 生命週期管理的目的。
Update Planner 為 vSphere Lifecycle Manager 的一部份，主要用途便是處理 vCenter Server 更新和安全性修復程序。
值得注意的是，Update Planner 機制僅支援新版 vCenter Server 7 和後續更新版本，無法支援舊版 vCenter Server 6.x 升級至新版 vCenter Server 7，並且管理人員必須啟用「VMware 使用者體驗改善計劃」（VMware Customer Experience Improvement Program，CEIP）後（如圖 19 所示），才能順利使用 Update Planner 更新機制。
vCenter Server 必須能存取網際網路，或透過 Proxy 代理伺服器存取網際網路，才能順利啟用 VMware CEIP 使用者體驗改善計劃。
圖 19、啟用 VMware CEIP 使用者體驗改善計劃後才能使用 Update Planner 更新機制
簡單來說，Update Planner 更新機制，可以幫助管理人員管理 vCenter Server 的更新和版本升級，同時還能建立相容性報表。登入 vCenter Server 管理介面後，按下「VIEW UPDATES」或「Updates Available」鈕之後，系統便會自動觸發執行 vCenter Server Update Planner 更新機制（如圖 20 所示）。
圖 20、準備執行 vCenter Server Update Planner 更新機制
在 Update Planner 視窗中（如圖 21 所示），可以看到適合 vCenter Server 更新的版本、Build number、類型、嚴重程度、發行說明……等，以及最重要的此更新是否需要重新啟動 vCenter Server，倘若「Reboot Required」欄位為「Yes」時，那麼管理人員應該挑選離峰或維護時間進行 vCenter Server 的更新作業，並重新啟動 vCenter Server 以便套用生效。
本文實作環境為單純 vSphere 虛擬化運作架構，所以產品互通性檢查結果只有看到 vSphere Hypervisor 的部份。
圖 21、查詢 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 文章內容。
圖 22、Update Planner 更新機制檢查安裝來源是否適用於 vCenter Server
圖 23、備份作業完成後鈕開始執行 vCenter Server 更新下載和安裝作業
圖 24、vCenter Server 順利下載更新並安裝完成
圖 25、順利更新 vCenter Server 至 7.0.0.10400 版本
結語
透過本文的深入剖析和實作演練之後，讀者已經了解全新 vSphere 7 無論在 vSphere 基礎架構，或是 vCenter Server 管理平台及 VM 虛擬主機和容器層級，都增加許多亮眼特色功能或增強原有機制。值得注意的是，管理人員在一開始規劃 x86 硬體伺服器時，在規格選擇上以及 BIOS/UEFI 針對虛擬化組態的部份，是比較容易疏忽的地方，只要注意這些小細節並搭配最佳化組態設定，定能輕鬆打造出高效能和高可用性的 vSphere 虛擬化基礎架構。