網管人雜誌
本文刊載於 網管人雜誌第 204 期 - 2023 年 1 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
在 2022 年 VMware Explore 大會上，VMware 官方正式發佈最新 vSphere 8 版本。同時，從 vSphere 8 版本開始，VMware 官方採用新的版本發佈模型，分別稱為「初始可用性」（Initial Availability，IA）和「通用可用性」（General Availability，GA），簡單來說，新的版本發佈方式和 vSphere+ 雲端服務版本將保持一致。
首先，當 VMware 官方發佈 RC 和 RTM 發佈之後，將會採用和 GA 相同測試品質和發佈標準的流程，在「2 週」之後發佈 IA 版本，接著在「4 - 6 週」之後發佈 GA 版本，而無須像過去必須等待「6 個月」之久，才能取得帶有新功能和增強功能的版本（如圖 1 所示）。
圖 1、RC、RTM、IA 和 GA 版本發佈週期示意圖
vSphere 8 亮眼特色功能
新世代傳輸架構 DPU 和 DSE
在過去虛擬化基礎架構中，管理人員已經很熟悉各種資源的規劃和調度，例如，負責運算資源的 CPU 和 Memory、負責圖形運算的 GPU。同時，隨著 AI 人工智慧和 ML 機器學習的興起，許多管理人員應該已經發現到，底層負責傳輸大量資料的網路資源也必須跟上，才能讓各項資源的整合與整體服務之間相得益彰，這項新技術稱之為「資料處理單元」（Data Processing Unit，DPU）（如圖 2 所示）。
圖 2、企業和組織資料中心除了原有的 CPU/GPU 資源之外，現在也需要 DPU 資源
目前，DPU 以 SmartNIC 的型態推出（如圖 3 所示），它的外型雖然和 PCIe 介面卡相同，但是 SmartNIC 內含 ARM CPU 處理器，和支援編譯功能的加速器，並且通常配置 10Gb 到 100Gb 的多個通訊埠，以及一個用於管理用途的乙太網路通訊埠，最重要的是 SmartNIC 有個本地端儲存資源，提供管理人員安裝軟體，例如，將 ESXi 虛擬化管理程序安裝於其中。
目前，NVIDIA、AMD、Pensado、Intel、Dell、HPE……等廠商，皆有推出 SmartNIC 產品。
圖 3、SmartNIC 運作架構示意圖
現在，我們已經知道 SmartNIC 能夠整合高效能的網路介面進行資料傳輸，那麼安裝在 x86 硬體伺服器上的 SmartNIC，以及 x86 硬體伺服器上原有的工作負載，例如，NSX Service、vSAN Data Servies……等，如何無縫並且有效的卸載至 SmartNIC 上，這便是我們接下來所要討論的 Project Monterey（如圖 4 所示）。
圖 4、Project Monterey 運作架構示意圖
簡單來說，在最新 vSphere 8 版本中，推出的「分佈式服務引擎」（Distributed Services Engine，DSE）特色功能（如圖 5 所示），就是剛才所提到的 Project Monterey 正式版本。現在，管理人員可以在 vSphere 8 運作架構中，直接在 DPU 上安裝另一個 ESXi 執行程序，讓上層的 ESXi 專心處理運算的工作負載即可，而 NSX 及 vSAN Data 網路傳輸作業的部份，則直接卸載給底層 DPU 上的 ESXi 處理，讓上層的 ESXi 能夠處理和承載更多的 VM 虛擬主機和容器。
圖 5、vSphere DSE 分佈式服務引擎運作架構示意圖
值得注意的是，企業和組織除了配置 DPU 硬體介面卡之外，必須搭配最新的 vDS 虛擬分佈式交換器「8.0」的版本和 NSX 服務，並且在新增 vDS 分佈式交換器時，組態設定採用的 DPU 廠商（如圖 6 所示），才能順利將工作負載卸載到底層的 DPU 上，並且不會增加任何 ESXi 的 CPU 運算資源開銷。
圖 6、選擇 DPU 技術以便卸載網路服務至 DPU
整合 GPU 和 NIC 裝置
透過最新的「裝置群組」（Device Group）機制，讓連接在同一個 PCIe Switch 的 GPU 和 NIC 裝置，除了支援原有廠商所提供的「互連」（Interconnect）機制之外，不同的裝置之間可以透過裝置群組機制整合在一起，並且提供給上層運作的 VM 虛擬主機使用，有效減少管理人員手動處理的流程和時間（如圖 7 所示）。
圖 7、裝置群組機制運作示意圖
因此，透過裝置群組整合後的單一裝置，對於 VM 虛擬主機來說同樣只是新增一個單一 PCI Device 即可，並且配置裝置群組的這樣的 VM 虛擬主機，仍然支援 DRS VM Placement 機制，以及 vSphere HA 高可用性機制。
當管理人員為 VM 虛擬主機配置裝置群組時，在新增 PCI Device 作業流程中，系統將會顯示已經裝置群組後的狀態，如圖 8 所示，第一個 PCI 裝置便是二個 GPU 透過 NVLink 所組合，第二個 PCI 裝置則是 GPU 整合 NIC 的裝置。
圖 8、為 VM 虛擬主機新增裝置群組後的 PCI Device
彈性化虛擬硬體裝置 DVX
在過去的版本中，一旦組態設定 VM 虛擬主機使用 DirectPath I/O 直連機制時，可以得到完全使用底層硬體裝置效能的好處，然而這個直連機制的副作用，便是導致 VM 虛擬主機喪失某些 vSphere 特色功能，舉例來說，這樣的 VM 虛擬主機無法執行 vSphere vMotion 進行遷移，也無法被 vSphere DRS 自動執行調度作業，更無法被 vSphere HA 高可用性機制所保護，此外也無法針對 VM 虛擬主機進行暫停作業，和針對 vMemory 記憶體及 vDisk 虛擬硬碟進行快照。
現在，最新的 vSphere 8 版本中，推出「虛擬裝置擴充模組」（Device Virtualization Extensions，DVX），是基於 Dynamic DirectPath I/O 技術之上，並為裝置廠商提供新的運作框架和 API。因此，底層的 ESXi 安裝 DVX 驅動程式，上層的 VM 虛擬主機使用支援 DVX 機制的虛擬裝置，達成高效能使用底層硬體的目的，同時又能保有 vSphere 特色功能，例如，透過 vSphere DRS 自動執行調度作業，並被 vSphere HA 高可用性機制所保護（如圖 9 所示）。
圖 9、DVX 虛擬裝置擴充模組運作流程示意圖
TKG 2.0 和 vSphere Zone
事實上，在 vSphere 7 版本時，便加入 vSphere with Tanzu 新特色功能，也就是將原有 vSphere 叢集，重新建構為支援容器工作負載的 Kubernetes 叢集，讓 ESXi 虛擬化平台成為 Kubernetes 容器平台的 Worker 節點，並在 ESXi 上直接運作容器 Pod。
同時，也推出支援有雲和公有雲部署的 TKG（Tanzu Kubernetes Grid），也就是支援企業和組織在地端資料中心內部署的 TKGs（Tanzu Kubernetes Grid Service for vSphere），以及部署至公有雲的 TKGm（Tanzu Kubernetes Grid Multi-Cloud）。
現在，最新的 vSphere 8 版本中，重新整合為統一的 Kubernetes 容器平台，無論是部署到地端資料中心或公有雲，都是採用同一套的 TKG 2.0 版本，並且加入新的「vSphere Zone」隔離機制，支援跨越多個 vSphere 叢集進行整合，以便獲得最大的可用性和資源，搭配來自 Cluster API 開放源始碼中的 ClusterClass 宣告機制，以便能夠管理人員能夠決定將容器部署成跨 vSphere 叢集，或是在各自的 vSphere 叢集中互相隔離工作負載（如圖 10 所示）。
圖 10、TKG 2.0 和 vSphere Zone 運作架構示意圖
vCenter 智慧型復原 DKVS
對於 vSphere 基礎架構有管理經驗的人來說，一定知道整個 vSphere 運作架構的組態設定和統計資料，都是儲存在 vCenter Server 管理平台當中。雖然，統一式的集中管理有其優勢，然而碰上災難事件時卻有可能會產生盲點。
舉例來說，管理人員定期在「每天凌晨 3 點」為 vCenter Server 執行備份作業，但是 vCenter Server 卻在晚上 8 點時發生災難事件，此時即便立即為 vCenter Server 執行備份復原作業，但是從凌晨 3 點到晚上 8 點之間，仍然發生許多事件和各項工作負載的統計資料，因此復原後的 vCenter Server 管理平台，將會遺失這段期間的事件和統計資料。
在最新 vSphere 8 版本中，推出「分散式鍵值儲放區」（Distributed Key-Value Store，DKVS） 機制，這項機制的設計原理，在於當 vCenter Server 管理平台發生災難時，事實上這段期間發生的事件和統計資料，也都儲存在 ESXi 主機當中。
因此，當 vCenter Server 管理平台進行災難復原後，與 vSphere 叢集中的眾多 ESXi 節點主機進行溝通，並將災難發生至上次備份時間期間的事件和統計資料取回，讓 vCenter Server 管理平台能夠迅速恢復，並且取得 vSphere 叢集和 ESXi 節點主機的最新資訊（如圖 11 所示）。
圖 11、DKVS 分散式鍵值儲放區運作架構示意圖
vMMR v2 增強記憶體監控機制
在 vSphere 虛擬化基礎架構中，對於工作負載的記憶體使用量和監控機制，一直是 VMware 努力增強和改進的方向，以便能夠承載更多的工作負載於 vSphere 架構中。從 vSphere 7 U3 版本開始，推出「vSphere 記體體監控和修復」（vSphere Memory Monitoring and Remediation，vMMR）機制。
現在，最新 vSphere 8 版本中，將原有 vMMR 記體體監控和修復增強至 vMMR v2 版本（如圖 12 所示），透過更智慧的記憶體監控和修復機制，有效增強 vSphere DRS 自動化調度工作負載，讓 VM 虛擬主機和容器等工作負載，能夠在最佳化的 DRS 調度決策中得到最充足的資源，確保 VM 虛擬主機和容器內的營運服務得到最佳效能和各項資源。
圖 12、vMMR v2 記體體監控和修復管理畫面示意圖
vMotion Notifications 敏感型應用程式專用
在過去的 vSphere 版本中，雖然 vMotion 線上遷移機制，能夠滿足絕大多數應用程序的需求，並且在遷移過程中和遷移後，對於應用程式都是無縫且透過的遷移，並不會對應用程式造成任何影響。
然而，對於某些「時間敏感應用程式」（Time-Sensitive Application）、VoIP、叢集服務等，可能會產生不良的影響，舉例來說，可能在執行 vMotion 遷移期間導致 VoIP 掉線，或者是觸動到叢集服務的心跳機制，導致引發容錯移轉叢集切換的動作。
因此，在 vSphere 8 版本中推出「vMotion 通知」（vMotion Notifications）機制，能夠針對這些特定的應用程式進行通知後才遷移，確保應用程式準備完畢後才進行遷移的動作。下列為 VM 虛擬主機執行 vMotion 通知時的執行步驟（如圖 13 所示）：
1. 管理人員為 VM 虛擬主機執行 vMotion 線上遷移。
2. VM 虛擬主機中的應用程式，收到 vMotion 遷移程序開始執行的通知。
3. 應用程式開始準備 vMotion 遷移作業。
4. 應用程式發送「確認」（Acknowledgement）訊息，給 vMotion 遷移程序確認可以開始執行遷移作業。
5. 系統透過 vMotion 機制線上遷移 VM 虛擬主機至別台 ESXi 節點主機。
6. 應用程式收到 vMotion 遷移程序通知遷移作業已完成。
圖 13、vSphere vMotion Notification 遷移流程示意圖
值得注意的是，預設並不會為 VM 虛擬主機啟用 vMotion 通知機制，因為必須要為應用程式進行改寫的動作才行。此外，啟用 vMotion 通知機制的 VM 虛擬主機，也將無法透過 vSphere DRS 進行自動化調度，僅能由管理人員手動觸發進行 vMotion 遷移作業。
實戰 – vSphere vMotion UDT 傳輸機制
在過去的 vSphere 版本中，不斷增強和提升 vSphere vMotion 線上遷移的能力，讓企業和組織在需要遷移運作中的 VM 虛擬主機工作負載時，無論是遷移運算資源的 vSphere vMotion，或是遷移儲存資源的 vSphere Storage vMotion 機制，都能以最快的速度完成線上遷移作業，避免 VM 虛擬主機中的營運服務產生任何卡頓甚至中斷的情況。
然而，有些管理人員可能發現，透過 vSphere vMotion 機制線上遷移運作中的 VM 虛擬主機時，確實能夠在最短時間內遷移完成，倘若是遷移「關閉」（Power Off）的 VM 虛擬主機，尤其是配置大容量儲存空間時，那麼遷移時間將需要很長時間，甚至同樣的遷移情境，將 VM 虛擬主機「開機」（Power On）後進行遷移，反而遷移時間縮短許多，為何會有這種遷移時間差異的情況出現 ？
主要原因在於，「線上遷移」（Hot Migration）的執行程序、I/O 同步機制、傳輸效能，都與「離線遷移」（Cold Migration）不同所導致，舉例來說，VM 虛擬主機運作中執行遷移時採用的 Hot Migration，將會採用最佳化後的「多執行緒」（Multi-Thread），與 ESXi 節點主機的多核心協同運作，傳輸效能最高可達 80Gbps。
反觀 VM 虛擬主機關閉時執行遷移採用的 Cold Migration，採用的則是「網路文件複製」（Network File Copy，NFC）通訊協定，並且僅採用「單執行緒」（Single-Thread），僅使用 ESXi 節點主機的單顆核心進行運算，傳輸效能最高僅能到達 1.3Gbps（如圖 14 所示）。
請注意，VM 虛擬主機帶有快照時，即便執行 Hot Migration 線上遷移作業，也會自動改為採用 NFC 通訊協定進行資料傳輸。
圖 14、vSphere vMotion 與 NFC 通訊協定和傳輸效能比較表
UDT 傳輸機制
在新版 vSphere 8 當中，採用「統一資料傳輸」（Unified Data Transport，UDT）機制，來處理 Cold Migration 遷移的 VM 虛擬主機傳輸作業。一旦 VM 虛擬主機關閉並且觸發 Cold Migration 遷移作業時，系統將會以原有的 NFC 通訊協定為「控制通道」（Control Channel），而「資料傳輸」（Data Transfer）的部份則會改採 vSphere vMotion 通訊協定，以便提升傳輸效能和傳輸速度節省大量時間。
值得注意的是，有些管理人員會忽略 ESXi 節點主機的 VMkernel Port 組態設定，進而造成傳輸速度上異常緩慢，舉例來說，管理人員並未將 ESXi 節點主機的傳輸流量類型隔開，將 Management 和 vMotion 流量類型混用，而一般來說 Management 管理網路可能只有 1Gbps 的傳輸速度，因此執行 Migration 遷移作業時便導致傳輸效率不彰。
又或者是，已經將實體網路和 ESXi 節點主機的傳輸流量類型隔開，但是在組態設定上卻忽略 VMkernel Port 的部份，未將原有共用 Management 網路的 vMotion 取消勾選，造成 Migration 遷移作業時仍舊使用 Management 慢速網路進行傳輸（如圖 15 所示）。
圖 15、在 Management 慢速管理網路中啟用 vMotion 傳輸流量類型
當管理人員執行 Migration 遷移作業時，系統如何判斷使用的遷移網路 ？舉例來說，執行 Hot Migration 時將會使用 vMotion Network，而使用 Cold Migration 時則會使用 Management Network（如圖 16 所示），管理人員也可以使用此方式，確認組態設定和實體網路的規劃是否一致，確保 Migration 遷移作業執行時，網路傳輸能夠如同規劃般順利執行並快速傳輸完畢。
圖 16、Hot Migration 和 Cold Migration 使用傳輸網路流程圖
採用傳統 NFC 的 Cold Migration
在實戰演練小節中，採用最新的 vSphere 8 IA 版本，搭配最新的 vCenter Server 8.0（Build 20519528）管理平台，在 UDT 傳輸測試流程的 VM 虛擬主機，則是配置 2 vCPU、8 GB vRAM、50 GB Thick Provision Eager Zeroed 類型的虛擬硬碟（如圖 17 所示）。
圖 17、測試新式 UDT 傳輸機制的 VM 虛擬主機配置
首先，在此實作中率先測試使用傳統 NFC 通訊協定進行 Cold Migration，針對這樣的 VM 虛擬主機配置將其關機之後進行遷移，觀察將會花費多少傳輸時間。
目前，測試的「UDT-TestVM」虛擬主機運作於 Node02 節點主機上，在 vCenter 管理介面中，依序點選「UDT-TestVM > Actions > Migrate」，在彈出的 Migration 互動視窗中，選擇「Change both compute resource and storage」選項後，按下 Next 鈕繼續 Cold Migration 流程（如圖 18 所示）。
圖 18、針對關機中的 VM 虛擬主機，執行 Cold Migration 遷移作業
在 2. Select a compute resource 頁面中，選擇要將 UDT-TestVM 虛擬主機運算資源，遷移至虛擬化基礎架構中哪一台 ESXi 主機，在本文實作環境中選擇「node01.lab.weithenn.org」，並確認下方相容性檢查結果為「Compatibility checks succeeded.」後按下 Next 鈕。
在 3. Select storage 頁面中，選擇要將 UDT-TestVM 虛擬主機儲存資源，遷移至虛擬化基礎架構中哪一個 Datastore 中，在本文實作環境中選擇「Node01-datastore」，此時在下方相容性檢查結果，將會警告管理人員「This can lead to lower network copy throughput.」，目前的傳輸網路吞吐量不佳的警告訊息，但是仍然能夠按下 Next 鈕繼續遷移流程。
在 4. Select networks 頁面中，選擇 UDT-TestVM 虛擬主機虛擬網路，是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組，在本文實作環境中採用預設值即可。最後，在 5. Ready to complete 頁面中，確認相關資訊無誤後按下 Finish 鈕，便立即執行 NFC 通訊協定的 Cold Migration 遷移作業。
此時，可以在 vCenter 管理介面下方 Recent Tasks 區塊，看到 Cold Migration 遷移作業的執行進度，或是切換到「Cluster > Monitor > Tasks and Events > Tasks」，查看更詳細的 Cold Migration 遷移作業內容，從結果中可以看到此次採用傳統 NFC 通訊協定的遷移作業花費「6 分 12 秒」（如圖 19 所示）。
圖 19、採用傳統 NFC 通訊協定執行 Cold Migration 遷移作業所花費的時間
使用新式 UDT 的 Cold Migration
在使用新式 UDT 機制進行 Cold Migration 遷移之前，必須先為來源端和目的端的 ESXi 節點主機，針對 VMkernel Port 進行組態設定，才能確保稍後使用 Cold Migration 遷移作業時，使用新式的 UDT 機制，而非傳統的 NFC 通訊協定進行資料傳輸。
請在 vCenter 管理介面中，依序點選「ESXi Host > Configure > Networking > VMkernel adapters > Edit」，在 VMkernel Port 組態設定視窗中，勾選「Provisioning」項目後按下 OK 鈕（如圖 20 所示）。
圖 20、在 VMkernel Port 組態設定視窗中勾選 Provisioning 項目
確保來源端和目的端的 ESXi 節點主機，都已經為遷移網路的 VMkernel Port 啟用「Provisioning」類型後，同樣的遷移情境，此時的 UDT-TestVM 虛擬主機，將從剛才的 Node01 遷移回 Node02，並觀察遷移作業時間與剛才傳統的 NFC 通訊協定有何不同。
請在 vCenter 管理介面中，依序點選「UDT-TestVM > Actions > Migrate」，在彈出的 Migration 互動視窗中，選擇「Change both compute resource and storage」選項後，按下 Next。在 2. Select a compute resource 頁面中，選擇要將 UDT-TestVM 虛擬主機運算資源，遷移至虛擬化基礎架構中哪一台 ESXi 主機，在本文實作環境中選擇「node02.lab.weithenn.org」，並確認下方相容性檢查結果無誤後按下 Next 鈕。
在 3. Select storage 頁面中，選擇要將 UDT-TestVM 虛擬主機儲存資源，遷移至虛擬化基礎架構中哪一個 Datastore 中，在本文實作環境中選擇「Node02-datastore」，此時在下方相容性檢查結果，並不會像剛才實作 NFC 通訊協定時產生警告訊息，而是通過相容性檢查的「Compatibility checks succeeded.」訊息（如圖 21 所示），請按下 Next 鈕繼續遷移流程。
圖 21、選擇儲存資源時順利通過系統相容性檢查作業
在 4. Select networks 頁面中，選擇 UDT-TestVM 虛擬主機虛擬網路，是否要連接至不同的 vSwitch 虛擬網路交換器或 Port Group 連接埠群組，在本文實作環境中採用預設值即可。最後，在 5. Ready to complete 頁面中，確認相關資訊無誤後按下 Finish 鈕，便立即執行採用新式 UDT 機制的 Cold Migration 遷移作業。
同樣的，在 vCenter 管理介面下方 Recent Tasks 區塊，看到 Cold Migration 遷移作業的執行進度，或是切換到「Cluster > Monitor > Tasks and Events > Tasks」，查看更詳細的 Cold Migration 遷移作業內容，從結果中可以看到改採新式 UDT 機制的遷移作業僅花費「39 秒」便遷移完成（如圖 22 所示）。
圖 22、改採新式 UDT 機制的遷移作業僅花費 39 秒便遷移完成
結語
透過本文的深入剖析和實作演練後，相信管理人員對於最新 vSphere 8 的亮眼特色功能，已經有更深一層的認識和理解。同時，在實作演練小節中，實作最新 vSphere 8 中支援的新式 UDT 機制，讓關機中卻有遷移需求的 VM 虛擬主機，同樣達到快速遷移的目的有效縮短資料傳輸時間。
