網管人雜誌
本文刊載於
網管人雜誌第 180 期 - 2021 年 1 月 1 日出刊，NetAdmin 網管人雜誌
為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology
Learning
技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份
1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。
本文目錄
前言
VMware 全新的 vSphere 7 解決方案，在 2020 年 3 月正式發佈同時內建 Kubernetes 叢集環境，並在 2020 年 10 月正式推出 vSphere 7 Update 1 更新版本。雖然，vSphere 7 Update 1 看似小版本更新，然而在這個 Update 1 版本中，除了原有運作規模大幅成長之外，也增強和新增許多特色功能。
首先，在 vSphere 叢集運作規模方面，vSphere 7 版本中「單台」ESXi 虛擬化平台，實體記憶體空間最大支援至「16 TB」，而新版 vSphere 7 Update 1 則一舉拉升至「24 TB」，在 vSphere 叢集支援 ESXi 成員主機數量部份，也從原有的「64 台」提升為「96 台」，至於 vSphere 叢集運作 VM 虛擬主機的數量，也從原有「6,400 台」大幅提升為「10,000 台」。
請注意，vSAN 叢集仍維持最多支援「64 台」vSAN 成員主機的運作規模。
同時，在 VM 虛擬主機運作規模方面，在 vSphere 7 版本中「單台」VM 虛擬主機的 vCPU 數量最多支援至「256 vCPU」，在 vSphere 7 Update 1 版本中提升至「768 vCPU」，在 vRAM 虛擬記憶體方面，也從原有最大支援從「6 TB」大幅提升為「24 TB」（如圖 1 所示）。
圖 1、vSphere 7 Update 1 Monster VM 運作規模示意圖
vSphere 7 Update 1 亮眼特色功能
vSphere with Tanzu
在新版 vSphere 7 發佈時，企業和組織可以採用 VCF（VMware Cloud Foundation），因為它包含 vSphere、NSX、vSAN、vRealize、SDDC Manager 等私有雲管理工具組合，讓企業和組織可以同時輕鬆打造傳統 VM 虛擬主機，以及新世代工作負載的容器和應用程式。
現在，最新發佈的 vSphere 7.0 Update 1，讓 TKG（Tanzu Kubernetes Clusters）可以直接和企業與組織資料中心內，已經建構好的 vDS（vSphere Distributed Switch）分佈式虛擬交換器連接，並且搭配由 HAProxy 所提供的負載平衡機制後，便可無須導入 NSX 軟體定義網路解決方案，也能夠建構 vSphere with Tanzu 容器管理平台。
vSphere with Tanzu 舊稱，便是 vSphere 7.0 版本所推出的 vSphere 7 with Kubernetes。
首先，由於「K8s 控制平面」（Kubernetes Control Plane）已經嵌入 vSphere 核心當中，並且每台 ESXi 虛擬化管理平台內，皆已部署 K8s 代理程式（稱之為 Spherelets），由眾多 ESXi 成員主機建構的 Kuberntes 叢集稱之為「Supervisor Cluster」，並且每台 ESXi 成員主機便是擔任 Kubernetes Worker Nodes 的角色。所以，在 vDS 分佈式虛擬交換器組態設定的部份，只要確保 vCenter Server 管理平台和 K8s 控制平面之間能夠通訊即可（如圖 2 所示）。
圖 2、vSphere with Tanzu 正式支援 vDS 分佈式虛擬交換器
然而，因為環境中沒有導入 NSX 軟體定義網路的話，表示沒有 NSX 內建負載平衡機制幫忙引導容器和相關流量，此時可以導入 TKG 正式支援的第一個負載平衡器「HAProxy」（如圖 3 所示），部署的方式也非常容易只要導入 OVF 即可。
請注意 ! 目前 vSphere Pod Service 和 Registry Service，仍須導入 NSX 軟體定義網路解決方案才行。
圖 3、部署 HAProxy 流量負載平衡器
當管理人員規劃完成，並且組態設定 HAProxy 使用的負載平衡 VIPs 位址，以及 TKG 叢集節點所需的 IP 位址之後，便能啟用 vSphere with Tanzu 特色功能，在啟用頁面中可以看到環境中並沒有導入 NSX-T 軟體定義網路解決方案，而是選擇 vCenter Server Network（如圖 4 所示），也就是採用 vDS 分佈式虛擬交換器搭配 HAProxy 負載平衡器。
圖 4、採用 vDS 分佈式虛擬交換器搭配 HAProxy 負載平衡器搭建 TKG 容器執行環境
vLCM 生命週期管理員再升級
vLCM（vSphere LifeCycle Manager）為 vSphere 7 版本新增特色功能，但是僅針對 vSphere 和 vSAN 提供基本支援，其它 VMware 產品如 NSX-T 便無法支援。
現在，全新推出的 vSphere 7.0 Update 1 版本中，增強 vLCM 生命週期管理員功能，除了全面支援原有的 vSphere 和 vSAN 之外，包括，安全性更新、版本升級、整合韌體……等。現在，連 NSX-T 也同樣支援。舉例來說，部署的 NSX Manager 可以透過 vLCM API 應用程式開發介面，管理 NSX-T 運作環境生命週期，包括，安裝、組態設定、運作、升級……等維護項目（如圖 5 所示）。
圖 5、vLCM 生命週期管理員功能全面升級並支援 NSX-T 運作環境
AMD SEV-ES 安全加密虛擬化
在 2019 年 8 月時，VMware 官方正式宣佈 vSphere 支援 AMD EPYC 處理器。同時，在新版 vSphere 7.0 Update 1 中，全面支援「安全加密虛擬化 - 加密狀態」（Secure Encrypted Virtualization – Encrypted State，SEV-ES）機制，幫助企業和組織從底層硬體直接防堵 Spectre 和 Meltdown 等，令人困擾的硬體底層漏洞。
或許，管理人員會有這樣的疑惑，為何 ESXi 和 VM 虛擬主機已經具備隔離的特性，舉例來說，VM Runtime 和 Guest OS 客體作業系統，其實是運作在由 ESXi 虛擬化平台所建構的「沙箱」（Sandbox）隔離環境中（如圖 6 所示），為何還需要底層硬體伺服器的安全性保護機制呢？
圖 6、VM Runtime 和 Guest OS 客體作業系統運作在 ESXi 提供的沙箱隔離環境
簡單來說，VM Runtime 和 Guest OS 運作的沙箱隔離環境其實是軟體式的，然而當 Guest OS 客體作業系統需要硬體資源時，其實還是會透過 ESXi 虛擬化平台，向底層發出使用硬體資源的請求，倘若底層硬體未進行加密保護機制的話，那麼受到侵入感染的 Hypervisor，便能夠讀取或修改底層硬體資源中，VM 虛擬主機存放於底層硬體處理器或記憶體內的機敏資料。
因此，透過 SEV-ES 安全加密虛擬化保護機制搭配加密金鑰，即便 Hypervisor 受到侵入感染之後，也將因為沒有加密金鑰，而無法讀取或修改底層硬體資源中 VM 虛擬主機的機敏資料，搭配原有的 VM Runtime 和 Guest OS 沙箱隔離環境保護機制，幫助企業和組織達到雙重保護效果機敏資料不外洩。
請注意 ! 第一代 AMD EPYC 處理器僅支援「15」個加密金鑰，第二代 AMD EPYC 處理器則擴充支援至「500」個加密金鑰。
針對大型工作負載最佳化的 vSphere vMotion
事實上，在新版 vSphere 7 版本中，已經重構 vSphere vMotion 即時遷移機制，並在 vSphere 7 Update 1 再度增強，以便企業和組織運作大型工作負載，例如，SAP HANA、Epic Operational Databases、InterSystems Cache、IRIS……等大型規模怪獸等級的 VM 虛擬主機時，能夠有效縮短即時遷移的作業時間，並避免「切換時間」（Switch-Over Time）或稱「擊暈時間」（Stun-Time），對大型規模應用程式造成的影響。
在舊版 vSphere 6.7 時，採用「Stop-Based Trace」機制，針對執行即時遷移的 VM 虛擬主機，停止「所有」vCPU 執行任何客體作業系統發出的請求指令，執行追蹤作業完成後再讓 VM 虛擬主機恢復運行。雖然，這樣的即時遷移機制對於中小型規模的 VM 虛擬主機效果很好，造成的停止時間也僅僅幾百「微秒」（microseconds），然而對於大型規模的 VM 虛擬主機則不然，因為 vCPU 數量越多的情況下，停止和恢復作業所需花費的時間越長，有可能導致 VM 虛擬主機內的應用程式發生中斷事件。
新版 vSphere 7 Update 1，採用「Loose Trace」機制（如圖 7 所示），針對執行即時遷移的 VM 虛擬主機，僅會停止「單一」vCPU 執行任何客體作業系統發出的請求指令，其它 vCPU 則繼續執行客體作業系統發出的請求指令，所以在即時遷移期間對於 VM 虛擬主機的效能影響最小，同時不會造成應用程式發生中斷事件。
圖 7、新舊版本 vSphere vMotion 即時遷移頁面追蹤技術示意圖
在「頁面追蹤」（Page Tracing）資料區塊大小的部份，舊版的 vSphere 6.7 採用「4 KB」小型資料區塊，傳輸即時遷移的 VM 虛擬主機 vRAM 虛擬記憶體空間，同樣的對於中小型規模的 VM 虛擬主機效果很好，然而對於大型規模的 VM 虛擬主機來說，除了容易造成 vMotion 即時遷移時間過長之外，也會影響大型應用程式的運作。
新版 vSphere 7 Update 1，採用「Large Trace」機制（如圖 8 所示），並且改為採用「1 GB」資料區塊，傳輸即時遷移的 VM 虛擬主機 vRAM 虛擬記憶體空間，同時搭配其它最佳化機制，例如，Bitmap、Switch-Over、Large Page Handling……等。
圖 8、新舊版本頁面追蹤資料區塊大小示意圖
首先，在 VMware 官方測試環境中，為 VM 虛擬主機配置「72 vCPU 和 1 TB vRAM」虛擬硬體資源，應用程式工作負載的部份則是採用 Oracle 資料庫，並且搭配 Hammer DB 模擬工作負載，可以看到舊版 vSphere vMotion 的即時遷移機制，和重構與最佳化之後的新版 vSphere vMotion 相較之下，新版 vSphere vMotion 除了更快遷移完成之外，在即時遷移和切換恢復期間的 Oracle 資料庫，整體的 Commits 數量都優於舊版的 vSphere vMotion（如圖 9 所示）。
圖 9、舊版和重構及最佳化的新版 vSphere vMotion 即時遷移測試結果
事實上，VMware 官方除了針對剛才大型 VM 虛擬主機進行測試之外，也針對一般企業和組織中典型的 VM 虛擬主機，例如，「12 vCPU 和 64 GB vRAM」，甚至測試超大型的 Monster VM 虛擬主機，配置「192 vCPU 和 4 TB vRAM」硬體資源，同樣也採用 Oracle 資料庫和 Hammer DB 模擬工作負載。如圖 10 所示，可以看到不管哪種規格的 VM 虛擬主機，重構及最佳化的新版 vSphere vMotion 即時遷移機制，都有「2 ~ 11 倍」的提升，甚至超大型的 Monster VM 虛擬主機更達到「19 倍」的效能提升。
圖 10、重構及最佳化的新版 vSphere vMotion 即時遷移提升數倍效能
實戰 vCLS（vSphere Clustering Services）
vCLS（vSphere Clustering Services），為最新 vSphere 7 Update 1 的新增特色功能。這是 VMware 官方，嘗試將 vSphere 叢集服務和 vCenter Server 進行脫勾，為 vSphere 叢集服務建立「分佈式控制平面」（Distributed Control Plane）的第一個版本。
熟悉 vSphere 基礎架構的管理人員便知，當 vSphere 基礎架構中 vCenter Server 發生故障損壞事件時，其上運作的 VM 虛擬主機和容器等相關工作負載，並不會受到影響且能夠持續運作，然而管理人員也將因為 vCenter Server 損壞，而無法針對 VM 虛擬主機和容器等工作負載進行管理作業。
此外，在 vCenter Server 故障損壞期間，ESXi 虛擬化平台中的 vSpehre HA Agent 仍然能夠正常運作，確保 ESXi 虛擬化平台若不幸同時發生故障損壞事件時，能夠透過 vSphere HA 高可用性機制，自動將 VM 虛擬主機和容器等工作負載，重新啟動在 vSphere 叢集中，其它仍然存活的 ESXi 虛擬化平台中繼續運作。
對於小型 vSphere 基礎架構來說，這樣的高可用性機制已經足夠。但是，對於中大型的 vSphere 基礎架構來說就顯得不足，舉例來說，因為 vCenter Server 發生故障損壞事件時，原本能夠將 VM 虛擬主機和容器等工作負載，自動進行遷移的 vSphere DRS（Distributed Resource Scheduler）機制便無法運作。
雖然，管理人員可以整合 vSphere HA（High Availability）或 vCHA（vCenter Server High Availability）高可用性機制，確保 vCenter Server 管理平台能夠在最短時間內復原上線，繼續擔任 vSphere 基礎架構管理平台的重任。然而，諸如 vSphere DRS、Storage DRS 等 vSphere 叢集服務，仍然圍繞在 vCenter Server 管理平台身上。
因此，VMware 官方打造出 vCLS 叢集服務，讓 vSphere 叢集服務和 vCenter Server 管理平台能夠脫勾。簡單來說，在新版 vSphere 7 U1 建構的 vSphere 叢集環境中，當 vCenter Server 管理平台發生故障損壞事件時，透過 vCLS 叢集服務能夠讓 vSphere DRS 等 vSphere 叢集服務，不因 vCenter Server 管理平台故障而停擺並且持續運作。
vCLS 運作架構
在 vCLS 叢集服務的運作架構中（如圖 11 所示），將會在 vSphere 叢集中建立「1 ~ 3 台」vCLS VM 虛擬主機，這個特殊的 VM 虛擬主機，稱為「System VMs」或「Agent VMs」。
vCLS VM 虛擬主機數量，取決於 vSphere 叢集中 ESXi 成員主機數量，當 ESXi 成員主機只有 1 台時則建立 1 台 vCLS VM 虛擬主機，當 ESXi 成員主機只有 2 台時則建立 2 台 vCLS VM 虛擬主機，當 ESXi 成員主機為 3 台或 3 台以上時建立 3 台 vCLS VM 虛擬主機。
圖 11、vCLS 叢集服務運作架構示意圖
值得注意的是，vCLS VM 虛擬主機並非一般典型的 vSphere VM 虛擬主機，而是 VMware 官方透過 Photon OS 運作的客製化 VM 虛擬主機，使用非常少的硬體資源，並且必須採用或升級至 vCenter Server 7 Update 1 版本，系統才會在 vSphere 叢集中自動部署 vCLS VM 虛擬主機。下列為 vCLS VM 虛擬主機所使用的硬體資源列表：
- 1 vCPU（Reservation 100MHz）
- 128 vRAM（Reservation 100MB）
- 2 GB vDisk（Thin Provision）
- No Ethernet Adapter
vCLS VM 虛擬主機沒有配置網路卡如何互相溝通？ 因為，vCLS VM 虛擬主機為透過 VMCI 和 vSOCKET 介面，與底層的 vSphere ESXi Hypervisor 進行溝通，所以無須配置 vNIC 虛擬網路卡。
此外，倘若 vSphere 叢集建立時，尚未建構共享儲存資源時，那麼系統便會將 vCLS VM 虛擬主機，部署在 ESXi 成員主機的本地端儲存資源當中，後續管理人員也可以透過 Storage vMotion，將 vCLS VM 虛擬主機的儲存資源，線上儲存遷移至支援高可用性機制的共享儲存資源中。
部署 vCLS VM 虛擬主機
當 vSphere 基礎架構運作環境時，只要採用或升級至 vCenter Server 7 Update 1 版本後，將會發現只要建立 vSphere 叢集後，系統便會依序自動執行「Deploy OVF template > Reconfigure virtual machine > Initialize powering on > Power On virtual machine」等工作任務（如圖 12 所示），也就是執行自動化部署 vCLS VM 虛擬主機的動作。
即便 vSphere 叢集尚未啟動 vSphere DRS 進階功能，系統仍然會自動部署 vCLS VM 虛擬主機的動作。
圖 12、系統自動部署 vCLS VM 虛擬主機
管理人員可以在 Cluster 層級中，隨時查看 vCLS 運作的健康狀態。登入 vCenter Server 管理介面後，依序點選「vCenter Server > Datacenter > Cluster > Summary」項目，展示「Cluster Services」項目後，即可從「Cluster Service health」欄位看到目前的 vCLS 健康狀態（如圖 13 所示）。如下所示，便是 vCLS 的三種健康狀態和說明：
- Healthy ： 健康情況良好。在 vSphere 叢集中，至少有一台 vCLS VM 虛擬主機正常運作中，並且為了確保 vCLS VM 虛擬主機的高可用性，系統將會依據 vSphere 叢集中 ESXi 成員主機數量，最多部署 3 台 vCLS VM 虛擬主機。
- Degraded ： 已降級。在 vSphere 叢集中，發生至少一台 vCLS VM 虛擬主機未正常運作，當系統重新部署 vCLS VM 虛擬主機，或是重新啟動 vCLS VM 虛擬主機時，vCLS 叢集健康情況便會處於此狀態。
- Unhealthy ： 不健康。當 vCLS 控制平台無法使用，並且導致 DRS 自動化負載平衡機制被跳過時，vCLS 叢集健康情況便會處於此狀態。
有關 vSphere Cluster Service 的健康情況詳細說明，請參考 VMware KB 79892 文件。
圖 13、管理人員可隨時查看 vCLS 健康狀態
由於，vCLS VM 虛擬主機的特殊性，所以當管理介面切換至管理人員常用的「Hosts and Clusters」模式時，並無法看到部署的 vCLS VM 虛擬主機，必須切換至「VMs and Templates」模式，才會在「vCLS」資料夾下，看到已經部署並運作中的 vCLS VM 虛擬主機。
同時，vCLS VM 虛擬主機的部署和維運管理作業，是由系統中的 vSphere Cluster Services 自動化進行，完全無須管理人員介入。所以，當管理人員切換到任意一台 vCLS VM 虛擬主機時，即可看到提示訊息，說明 vCLS VM 虛擬主機的「資源使用、電力狀態、健康狀態」，由 vSphere Cluster Services 進行維護管理（如圖 14 所示），並且在 Notes 中說明 vCLS VM 虛擬主機的詳細資訊。
圖 14、查看 vCLS VM 虛擬主機相關資訊
因此，倘若管理人員嘗試編輯 vCLS VM 虛擬主機時，系統便會跳出警告訊息，提示管理人員無須人為介入（如圖 15 所示），因為 vCLS VM 虛擬主機將由 vSphere Cluster Services 進行維運管理作業。
圖 15、系統提示管理人員無須人為介入 vCLS VM 虛擬主機的維運管理作業
在 vCLS VM 虛擬主機生命週期管理的部份，由 vSphere EAM（ESX Agent Manager）維護管理（如圖 16 所示）。因此，當使用者嘗試刪除或關閉 vCLS VM 虛擬主機電源時，vSphere EAM 將會執行自動「開機」（Power On）或「重新建立」（Re-Create）的動作。
圖 16、vCLS VM 虛擬主機生命週期由 vSphere EAM 負責維護管理
vCLS 高可用性測試
如前所述，vCLS VM 虛擬主機由 vSphere Cluster Services 進行維運管理作業，所以管理人員可以手動測試 vCLS VM 虛擬主機的高可用性。首先，測試強制關閉 vCLS VM 虛擬主機電源，查看將會發生什麼情況，請點選 vCLS VM 虛擬主機後，依序點選「Power > Power Off」項目，強制關閉 vCLS VM 虛擬主機電源，同樣的當管理人員嘗試強制關閉 vCLS VM 虛擬主機電源時，系統也會出現警告資訊，並建議管理人員參考 VMware KB 79892 文件內容。
管理人員將會發現，手動強制關閉 vCLS VM 虛擬主機電源後，系統偵測到 vCLS VM 虛擬主機電源狀態的異動，在「10 秒鐘」之後自動執行「Power On」將 vCLS VM 虛擬主機自動開機（如圖 17 所示）。
圖 17、手動強制關閉 vCLS VM 虛擬主機電源 10 秒後系統自動開機
在本文實作環境中，vSphere 叢集中共有三台 ESXi 成員主機，因此系統分別在每台 ESXi 成員主機中，部署一台 vCLS VM 虛擬主機。管理人員可以測試，當 vCLS VM 虛擬主機所在的 ESXi 成員主機，進入「維護模式」（Maintenance Mode）時，vCLS VM 虛擬主機將會如何運作。
在目前 vSphere 叢集運作環境中，名稱為「vCLS（3）」的 vCLS VM 虛擬主機，運作在名稱為「esxi7-n03.lab.weithenn.org」的 ESXi 成員主機中，當 ESXi 成員主機進入維護模式後，可以看到系統自動將「vCLS（3）」vCLS VM 虛擬主機，遷移至「esxi7-n02.lab.weithenn.org」ESXi 成員主機上繼續運作（如圖 18 所示）。
目前，vSphere DRS 版本中的「反關聯性規則」（Anti-Affinity Rules），並不適用於 vCLS VM 虛擬主機。因此，當 ESXi 成員主機離開維護模式後，管理人員必須手動遷移 vCLS VM 虛擬主機至原本的 ESXi 成員主機中。
圖 18、ESXi 成員主機進入維護模式後，vCLS VM 虛擬主機自動遷移後繼續運作
值得注意的是，若 vCLS VM 虛擬主機，採用的儲存資源為 ESXi 成員主機的「本地儲存資源」時，當 ESXi 成員主機進入維護模式時，則 vCLS VM 虛擬主機將會執行「Power Off」關機作業，並且在 ESXi 成員主機離開維護模式時，自動執行「Power On」開機作業。
因為 ESXi 成員主機進入維護模式時，僅會針對採用共享儲存資源的工作負載，進行遷移「運算資源」的動作，而不會同時遷移工作負載的「運算和儲存資源」。
最後，測試當管理人員強制刪除 vCLS VM 虛擬主機後，系統是否會執行生命週期維護管理作業，執行重新部署和開機運作等工作任務。請先針對名稱為「vCLS（1）」的 vCLS VM 虛擬主機，強制執行關閉電源的動作，緊接著執行「Delete from Disk」的刪除作業。
在 vSphere 叢集中的工作負載，必須處於「關機」（Power Off）狀態才能執行刪除的工作任務。
從系統工作任務清單中可以看到，當管理人員手動刪除 vCLS VM 虛擬主機後，在「30 秒鐘」之後執行 vCLS VM 虛擬主機生命週期維護管理作業，自動執行重新部署、組態設定、開機等工作任務（如圖 19 所示），而重新部署 vCLS VM 虛擬主機的新名稱為「vCLS（4）」，並且運作在原本「esxi7-n01.lab.weithenn.org」的 ESXi 成員主機中。
圖 19、系統自動執行 vCLS VM 虛擬主機生命週期維護管理作業
