本文將深入剖析及實作演練，讓管理人員理解最新vSAN 8 U1版本有哪些亮眼特色功能，並透過實際操作來驗證vSAN HCI Mesh Computer Cluster機制可為企業組織帶來那些效益，讓VM虛擬主機工作負載中的運算資源和儲存資源分別運作在不同的vSphere/vSAN叢集中。
在本文中，將深入剖析VMware於2023年4月所推出最新vSAN 8.0 Update 1超融合版本，有哪些亮眼特色功能能夠幫助企業和組織更容易地進行維護管理，或是幫助管理人員縮短問題分析和故障排除時間。
vSAN 8 U1帶來亮眼新功能
首先，介紹最新vSAN 8.0 Update 1超融合版本中的幾項亮眼特色功能。
Skyline健康指數儀表板
隨著企業和組織接受vSAN超融合解決方案帶來的管理和效益後，對於僅熟悉傳統vSphere架構的管理人員來說，在問題分析和故障排除時勢必產生一定程度的影響。
因此，在最新的vSAN 8 U1版本中，除了加強原有Skyline Health for vSAN之外，更推出全新的Skyline叢集健康儀表板。如圖1所示，全新儀表板中共有三大區塊，分別是vSAN叢集的健康評分、運作狀態趨勢和結果的健康指數、健康狀態和需要修復的項目。
圖1 全新推出的Skyline叢集健康儀表板。
首先，管理人員應該也會好奇vSAN叢集健康評分結果是如何產生的？事實上，這是系統根據「類別影響」（Category Impact）和「優先權影響」（Priority Impact）兩種方式，再依照不同事件產生的權重，最後所產生的評分結果。舉例來說，類別影響包含可用性、運作效能、儲存空間使用率、合規性等等，而優先影響則是類別中觸發的事件，對於vSAN叢集健康影響的程度所給予的權重。
簡單來說，當vSAN叢集健康評分結果落在81-100分時的健康狀態，表示管理人員無須擔心vSAN叢集的健康情況，而當評分結果落在61-80分時健康狀態惡化，此時應檢查系統建議的項目並進行排除或修復，以便將vSAN叢集恢復為健康狀態，當評分落在0-60分時為不健康狀態，應立即進行故障排除作業。
另一個儀表板為運作狀態趨勢和結果健康指數，透過這個運作趨勢歷史資料，可以輕鬆得知vSAN超融合叢集的健康評分，點選不同的時間點和評分時，下方的健康檢查項目和需要修復項目也會變化，讓管理人員一目了然健康情況不佳是因為哪個項目必須進行修復，以及修復後能夠獲得的健康權重，如圖2所示。
圖2 vSAN叢集健康儀表板中會顯示運作狀態趨勢和結果健康指數。
最後，透過健康狀態和需要修復項目，可以清楚看到每個事件的類別，以及帶來的健康權重影響為何，如圖3所示。因此，即便是資歷較淺的管理人員，透過說明和提供的資訊，也能輕鬆了解事件發生的根本原因以及如何進行故障排除，進而提升vSAN叢集的整體健康情況。
圖3 透過健康狀態和需要修復項目機制，輕鬆幫助管理人員進行故障排除。
不斷增強的效能檢測工具
在最新的vSAN 8 U1版本中，針對vSAN超融合叢集效能檢測的部分，也在三個部分進行加強。首先，透過「效能支援」（Performance for Support）檢測機制，可以針對vSAN超融合叢集的效能和穩定性進行故障排除。
事實上，過去管理人員只能透過vSAN Observer，也就是RVC（Ruby vSphere Console）工具，才能針對vSAN超融合叢集進行效能資料收集和分析作業，直到舊版vSAN 6.6.1版本中才推出效能支援內建工具，以便取代vSAN Observer工具，讓vSAN管理人員能夠輕鬆查看vSAN超融合叢集和節點主機之間，整體運作效能的統計資訊以利判斷。
現在，最新的vSAN 8 U1可以直接看到vSAN ESA叢集中，針對IOPS儲存效能、Latency延遲時間、Throughput傳輸量等統計資訊，如圖4所示，有效幫助管理人員進行判斷，縮短對於vSAN超融合叢集的故障排除時間。
圖4 透過效能支援儀表板有效縮短故障排除時間。 （圖片來源：Enhanced Performance Diagnostics tools for vSAN 8 U1 | VMware）
此外，vSAN 8 U1針對vSAN物件提供「物件追蹤」（Trace Objects）功能，系統每隔1分鐘將會自動複製或備份vSAN相關物件到vSAN Datastore儲存資源中，用於存放專用物件的路徑，而這些特殊物件僅保存6天，之後系統便會自動執行清除作業。在32台節點主機的vSAN叢集規模中，儲存6天的vSAN物件和物件追蹤日誌，大約會占用512GB的儲存空間。
一旦企業或組織碰上無法解決的問題而尋求VMware技術支援時，技術支援團隊便能透過取得物件追蹤日誌內容，以便在最短時間內能夠幫助企業組織識別和解決問題。
在vSAN超融合叢集環境中，節點主機之間的網路環境至關重要，無論是傳輸穩定性或傳輸效率，輕者影響vSAN叢集運作效能，重者在節點主機之間造成網路隔離的情況，因此vSAN8U1版本針對網路測試和健康檢測機制進行改進。舉例來說，在vSAN網路主機測試作業中，由於新式vSAN ESA和傳統vSAN OSA，在網路傳輸方便的基本要求並不相同，所以當vSAN ESA環境執行網路測試時，會自動忽略目標網路卡的傳輸速度，而嘗試採用並呈現最大網路吞吐量，如圖5所示，以避免產生混淆的情況。
圖5 改良的網路傳輸速率測試避免管理人員產生混淆。 （圖片來源：Enhanced Performance Diagnostics tools for vSAN 8 U1 | VMware）
此外，在網路延遲檢查作業中，也簡化vSAN叢集節點主機之間的測試結果，在過去的版本中，將會針對每台節點主機之間呈現ping測試的結果，然後在大規模的vSAN叢集環境中，由於節點主機數量較多，導致不易從測試結果中快速地得知是否有節點主機發生網路異常的情況。現在，除非有個別的節點主機網路發生異常，否則會直接呈現vSAN叢集整體測試結果，如圖6所示。
圖6 增強後的網路測試結果，協助管理人員快速判斷網路環境健康情況。 （圖片來源：Enhanced Performance Diagnostics tools for vSAN 8 U1 | VMware）
VM效能問題分析利器I/O Trip Analyzer
過去，在vSAN叢集中的VM虛擬主機，若發生儲存效能問題，主要依靠管理人員的經驗進行問題分析和故障排除。現在，透過最新vSAN 8 U1版本中的VM I/O Trip Analyzer機制，只要針對發生問題的VM虛擬主機執行一段時間的效能診斷資料收集作業，後續VM I/O Trip Analyzer便能進行效能問題分析。
從VM I/O Trip Analyzer分析結果可以看到，如圖7所示，可透過簡單的視覺化圖形，了解發生效能問題的VM虛擬主機，從vDisk虛擬硬碟的vSAN Policy到與其他VM虛擬主機進行通訊的路徑，系統也會在每個傳輸路徑中指示可能發生效能問題的原因。
圖7 透過VM I/O Trip Analyzer機制，有效分析VM虛擬主機效能問題。 （圖片來源：vSAN I/O Trip analyzer task scheduling in vSAN 8 U1 | VMware）
實戰演練vSAN ESA HCI Mesh
接著，將實作演練新版vSAN 8 Update 1版本中ESA超融合儲存架構最新支援的「解構式儲存」（Disaggregated Storage）運作架構，如圖8所示。值得注意的是，在vSAN 8 U1版本中，雖然ESA超融合叢集已經正式支援解構式儲存運作架構，然而與傳統的OSA超融合儲存架構相較之下，仍有下列功能項目尚未支援：
圖8 vSAN ESA超融合叢集支援解構式儲存架構運作示意圖。 （圖片來源：Evolutionary Improvements with disaggregated Storage in vSAN 8 U1 | VMware）
‧跨vCenter Server管理平台時，不支援運作解構式儲存架構。
‧在vSAN延伸叢集運作架構中，不支援運作解構式儲存架構。
‧在vSAN ESA解構式儲存架構中，不支援重複資料刪除，因為vSAN ESA超融合叢集本身尚未支援重複資料刪除功能。
‧在vSAN ESA解構式儲存架構中，不支援加密金鑰更新功能，因為vSAN ESA超融合叢集本身尚未支援加密金鑰更新功能。
在實作環境方面，除了採用最新vCenter Server 8 U1版本之外，共有三個vSphere叢集，分別是擔任管理用途的Management叢集、vSAN8-ESA超融合叢集，以及僅用於運算的Compute叢集，如圖9所示。在vSAN 8 ESA的部分，共有三台vSAN叢集節點主機，每台vSAN叢集節點主機除了安裝vSphere虛擬化平台系統硬碟外，還額外配置四顆600GB NVMe儲存裝置。此外，另有一台vSphere 8 U1虛擬化平台，屆時將遠端掛載使用由vSAN 8 ESA超融合叢集的儲存資源。
圖9 實作環境中共有三個不同用途和功能的vSphere及vSAN叢集。
部署vSAN ESA超融合叢集
在部署vSAN ESA超融合叢集的部分，有關建立DataCenter和Cluster，以及組態設定vDS分佈式虛擬交換器和vSAN VMkernel Port等等詳細資訊，請參考本刊第208期「vSAN 8新儲存架構開工‧實戰ESA超融合叢集」內容，因此不再贅述。
順利部署vSAN ESA超融合叢集後，在實作解構式儲存功能之前，先確認vSAN ESA超融合叢集一切運作正常，相關服務順利啟用，並採用正確的Storage types（圖10）。
圖10 確認vSAN ESA超融合叢集採用正確的Storage types。
暫時關閉vSphere HA服務
在本文實作環境中，將組態設定傳統的vSphere叢集，專責擔任Compute運算叢集的用途，讓其中運作的工作負載，例如VM虛擬主機或容器能夠充分使用Compute運算叢集的運算資源，至於儲存資源的部分，則使用高可用性高效能的vSAN ESA超融合叢集。
因此，在組態設定vSAN ESA超融合叢集解構式運作架構之前，先將vSphere HA高可用性機制暫時關閉，如圖11所示，以避免在組態設定過程中，可能不小心觸發vSphere HA高可用性機制，產生非預期的高負載工作量，進而導致對VM虛擬主機中持續運作的服務或應用程式產生中斷或影響。
圖11 暫時關閉vSphere HA高可用性服務，避免組態設定解構式儲存架構時產生非預期的影響。
規劃專屬vSAN VMkernel Port
在vSAN解構式儲存運作架構中，無論擔任Server Cluster、Client Cluster、Compute Cluster角色，一律建議必須為這些vSAN叢集節點主機或ESXi主機，組態設定專用於連接和掛載，遠端vSAN Datastore儲存資源的vSAN VMkernel Port。
在vSAN解構式儲存架構時，跨叢集的傳輸流量採用「RDT over TCP/IP」，和原有傳統vSAN超融合叢集的網路流量，採用幾乎完全相同的TCP/IP網路協定堆疊架構。此外，建議除了配置NIC Teaming容錯機制，並採用專屬的vDS分佈式虛擬交換器，且搭配NIOC網路流量管理機制之外，為了避免因為跨叢集之間的網路延遲，導致影響VM虛擬主機運作效能，建議至少應採用25GBps網路卡。
根據VMware官方最佳建議作法，採用傳統vSAN OSA超融合叢集運作解構式儲存架構時，一旦網路延遲時間超過5毫秒（ms）時，將會觸發系統的告警機制。而採用新式vSAN ESA超融合叢集運作解構式儲存架構時，當網路延遲時間超過1毫秒時，就會觸發系統告警機制。
事實上，從vSAN 7 Update 1版本開始，便支援整合Layer 3路由機制的網路層。因此，當企業因為某些原因不採用原有建議的Layer 2資料連結層時，可以採用具備路由機制的Layer 3網路層。只要在新增專屬的vSAN VMkernel Port時，勾選「override default gateway for this adapter」項目，並指定採用的預設閘道IP位址，即可立即支援具備路由機制的Layer 3網路層。
在本文實作環境中，已經為Compute叢集中的ESXi主機，配置另一個專屬實體網路卡，用於連接和掛載vSAN ESA超融合儲存資源。首先，在vCenter管理介面中依序點選「vCenter Server > Datacenter > Compute Cluster > ESXi > Configure > Networking > VMkernel adapters > Add Networking」項目，準備為Compute叢集中的ESXi主機，配置專屬的vSAN VMkernel Port。
在彈出的Add Networking視窗中，在1. Select connection type頁面中，選擇VMkernel Network Adapter項目，在2. Select target device頁面中，選擇Select an existing standard switch和vSwitch0，先使用系統預設的vSS標準虛擬網路交換器，稍後將會遷移至vDS分佈式虛擬網路交換器。
在3. Port properties頁面中，於Network label欄位鍵入vSAN-VMkernel，並在下方Enabled services區塊中勾選vSAN項目，表示這個新增的VMkernel Port將會啟用vSAN類型網路流量，在4. IPv4 settings頁面中，鍵入vSAN VMkernel Port的IPv4位址和網路遮罩，在5. Ready to complete頁面中，則確認組態設定正確無誤後，按下〔Finish〕按鈕即可套用生效。
接著，將剛才Compute叢集內，ESXi主機中的vSAN VMkernel Port，由原本的vSS標準虛擬網路交換器遷移至vDS分佈式虛擬網路交換器，依序點選「Inventories > Networking > Datacenter > vSAN-DSwitch > Actions > Add and Manage Hosts」項目，在1. Select task頁面中選擇Add hosts項目，在2. Select hosts頁面中勾選Compute叢集中的ESXi主機，而在3. Manage physical adapters頁面中，可以看到ESXi主機規劃專屬用於解構式儲存的vmnic1，接著在Assign uplink下拉式選單中選擇Uplink1項目，此時In use by switch將會顯示為This switch。
在4. Manage VMkernel adapters頁面中，由於剛才ESXi主機新增的vSAN VMkernel Port名稱為vmk1，所以在vmk1項目中點選Assign Port Group連結，而在Assign port group頁面中，可以看到採用vSAN-DPortGroup和vSAN-DSwitch，然後按下Actions中的Assign連結，確認使用這個vDS分佈式虛擬網路交換器和Port Group。
在5. Migrate VM networking頁面中，由於不需要將VM虛擬主機連接至vSAN網路環境中，因此採用系統預設值即可。在6. Ready to complete頁面中，確認組態設定正確無誤後，按下〔Finish〕按鈕即可套用生效。
現在，在vDS分佈式虛擬網路交換器中可以看到，除了vSAN ESA超融合叢集節點主機外，還有剛才加入Compute叢集中的ESXi主機，如圖12所示。
圖12 為Compute叢集ESXi主機規劃專屬的vSAN VMkernel Port和網路環境。
啟用HCI Mesh Compute Cluster
前置作業完畢，點選Compute叢集，接著依序點選「Configure > vSAN > Serivces > I don't need a local vSAN datastore > Configure cluster without vSAN datastore > Configure」。在彈出的視窗中，系統說明雖然會為vSphere Cluster啟用vSAN功能，但是並沒有使用本機儲存資源，確認無誤後按下〔Apply〕按鈕以便套用生效，如圖13所示。
圖13 啟用vSAN HCI Mesh Compute Cluster功能。
此時，管理人員可能會有疑問，這個Compute叢集啟用vSAN進階功能，並且稍後會掛載vSAN Datastore儲存資源使用，那麼企業是否需要為Compute叢集購買vSAN軟體授權？答案是，並不需要購買vSAN軟體授權。
掛載vSAN ESA Datastore儲存資源
系統經過一連串的組態設定作業後，順利地為傳統的vSphere叢集啟用vSAN HCI Mesh Compute Cluster進階功能，在掛載vSAN ESA Datastore儲存資源之前，先確保vSphere叢集的vSAN Service狀態和Storage Types運作模式，確保稍後能夠掛載vSAN ESA Datastore儲存資源，如圖14所示。
圖14 為傳統vSphere叢集，啟用vSAN HCI Mesh Compute Cluster進階功能。
確認無誤後，在Compute叢集中，依序點選「Configure > vSAN > Remote Datastores > Mount Remote Datastore」項目。然後，在1. Select datastore頁面中，選擇先前建立的vSAN ESA Datastore儲存資源，在2. Check compatibility頁面中，系統會針對剛才選擇的vSAN ESA Datastore儲存資源進行多種項目的相容性檢查，如圖15所示，例如遠端vSAN Datastore儲存資源是否為支援格式的版本、vSAN叢集是否已經達到Client Cluster的掛載上限、網路延遲時間是否符合最佳建議的5毫秒等等，確保稍後能順利掛載及使用vSAN ESA Datastore儲存資源。
圖15 系統進行掛載遠端vSAN Datastore儲存資源的相容性檢查作業。
值得注意的是，倘若vSAN叢集節點主機「停用IPv6」網路堆疊功能，那麼系統將無法進行相容性檢查作業，並且顯示「Failed to run the remote datastore mount pre-checks」錯誤訊息，又或者Compute叢集的ESXi主機雖然建立vSAN VMkernel Port，並且加入同一個vDS分佈式虛擬網路交換器，但是在vSAN VMkernel Port組態設定內容中，卻忘了勾選Enabled servies中的vSAN項目時，也會導致相容性檢查作業在「Server and client clusters have no connectivity issues」出現紅色錯誤，並提醒問題原因為「Cannot connect to any server host」，並且無法繼續掛載作業，如圖16所示。
圖16 遺漏的組態設定，導致無法通過相容性檢查作業程序。
現在，可以在Remote Datastore視窗中看到多出了vSAN ESA Datastore儲存資源，如圖17所示，並且後續在Compute叢集新增VM虛擬主機時，在選擇Datastore儲存資源頁面中，也會看到vSAN ESA Datastore儲存資源項目可供選擇。
圖17 Compute叢集順利掛載vSAN ESA Datastore儲存資源。
順利啟用並完成vSAN HCI Mesh Compute Cluster組態設定作業後，即可將剛才暫時關閉的vSphere HA高可用性機制進行啟用。值得注意的是，在為Compute叢集啟用vSphere HA高可用性機制時，因為vSAN HCI Mesh Compute Cluster並非一般普通vSphere叢集，假設vSAN ESA超融合叢集發生災難事件，將會導致Compute叢集中的VM虛擬主機受到影響，並觸發「設備永久遺失」（Permanent Device Loss，PDL）或「所有路徑關閉」（All Paths Down，APD）機制。
因此，建議在重新啟用vSphere HA高可用性機制時，應確認Datastore with APD和Datastore with PDL組態設定值，建議分別採用「Power off and restart VMs」和「Power off and restart VMs – Conservative restart policy」選項，如圖18所示。有關APD和PDL組態設定內容的詳細資訊，請參考VMware KB2004684、KB2032934、KB2032940、KB2004605、KB2059622知識庫文章內容。
圖18 Compute叢集啟用vSphere HA時建議採用的PDL和APD組態設定。
遷移VM虛擬主機儲存資源並套用vSAN原則
現在Compute運算叢集無論是部署新的VM虛擬主機，或是現有VM虛擬主機需要執行Storage vMotion遷移儲存資源時，都能選擇已經連接和掛載完成的遠端vSAN ESA Datastore儲存資源，並且套用具備高效能和高彈性的vSAN儲存原則。
在本文實作環境中，於Compute運算叢集中共有五台運作中的VM虛擬主機，這是在建立vSAN HCI Mesh Compute Cluster之前，便已經部署運作的VM虛擬主機。因此，這五台VM虛擬主機的儲存資源，仍然使用Compute運算叢集中ESXi主機的本機系統硬碟，如圖19所示。
圖19 現有運作的VM虛擬主機儲存資源位於ESXi主機本機硬碟內。
以其中名稱為DB01的VM虛擬主機為例，透過Storage vMotion線上儲存遷移機制，將VM虛擬主機的儲存資源，由原本的ESXi主機本機硬碟遷移至高可用性的vSAN ESA Datastore儲存資源。
點選DB01虛擬主機後，在右鍵選單中選擇Migrate項目，接著在1. Select a migration type頁面中選擇Change storage only選項。在2. Select storage頁面中，即可看到透過vSAN HCI Mesh Compute Cluster機制，掛載完成的vSAN ESA Datastore儲存資源。進入3. Ready to complete頁面後，確認無誤再按下〔Finish〕按鈕，系統便立即執行Storage vMotion線上遷移儲存資源的動作。
當Storage vMotion工作任務執行完畢，查看DB01虛擬主機的儲存資源時，可以發現轉為使用vsanDatastore儲存資源，並且查看DB01虛擬主機的vSAN儲存物件分佈情況時，可以看到套用高可用性的vSAN RAID-1儲存原則，並且將vSAN儲存物件分佈在不同的vSAN叢集節點主機中，如圖20所示，達成DB01虛擬主機使用Compute叢集的運算資源，而儲存資源則是使用遠端的vSAN ESA Datastore儲存資源。
圖20 遷移VM虛擬主機儲存資源至vSAN ESA Datastore。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞