隨著 VMworld 2021 大會的舉行，最新版本 HCI 超融合基礎架構的「vSAN 7 Update 3」也同步推出。事實上，對於 IT 管理人員來說，對於 Update 版本的認知，通常大多為安全性更新或者是臭蟲修正，然而最新發佈的 vSAN 7 Update 3 版本，除了將原有特色功能大幅增強之外，更同時新增許多亮眼的特色功能（如圖 1 所示）。

現在，最新的 vSAN 7 U3 版本中，針對 2-Node vSAN 節點主機的小型 vSAN 叢集儲存原則進行增強，新增「巢狀式容錯網域」（Nested Fault Domains）機制，在每台 vSAN 節點主機的「磁碟群組」（Disk Group）當中，套用新的儲存原則並分散 vSAN 儲存物件，讓 vSAN 叢集整體可承受災難程度大幅提升。

簡單來說，一旦管理人員為部署的 VM 虛擬主機，套用新式「Host mirroring（2-node）」儲存原則之後，則該台 VM 虛擬主機所有相關的 vSAN 儲存物件，都會透過新式的巢狀式容錯網域機制所保護。因此，當 vSAN 節點主機的磁碟群組發生故障時，甚至另一台 vSAN 節點主機也同時發生故障，這種對於 2-Node vSAN 叢集來說是重大災難事件的情況（如圖 3 所示），VM 虛擬主機相關的 vSAN 儲存物件仍然可用，VM 虛擬主機和內部運作的企業服務仍然正常運作。

在過去的 vSAN 版本中，支援靜態資料加密機制，管理人員可以使用 vSphere NKP（Native Key Provider），或是使用外部 KMS 主機進行加密金鑰的管理。

現在，最新的 vSAN 7 U3 版本中，完整支援 vSAN 叢集中的 vSAN 節點主機，安裝和配置硬體式的 TPM（Trusted Platform Modules）加密模組，以便在加密金鑰和應用程式的通訊出現問題時，能夠保留分佈式的加密金鑰在其中。簡單來說，vSphere NKP 和外部 KMS 已經完全支援整合 TPM 加密模組，這也是建構和儲存加密金鑰的最佳實作方法之一（如圖 4 所示）。

事實上，在 vSAN 叢集架構中，一旦 VM 虛擬主機發生效能不足或效能上遇到瓶頸時，相較於傳統的 vSphere 虛擬化環境架構來說，管理人員必須熟悉原有的 vSphere 基礎之外，還必須了解 vSAN 叢集的分佈式儲存架構，以及 VM 虛擬主機相關物件放置的情況後，逐一追查才有可能找出導致效能問題的原因。

現在，最新的 vSAN 7 U3 版本中，直接在 vCenter Server 管理平台內，整合 VM 虛擬主機「I/O 效能分析」（I/O Trip Analyzer）機制，除了幫助管理人員更容易辨別出 VM 虛擬主機的效能問題之外，同時也補足原有「vSAN 效能服務」（vSAN Performance Service）和「I/O 洞察」（I/O Insight）的盲點。

因此，當 VM 虛擬主機出現效能問題時，管理人員可以直接透過 vCenter 管理介面，查看 VM 虛擬主機每個 vDisk 虛擬硬碟的讀取和寫入效能數據之外，透過可視化的資料存取路徑有效幫助管理人員，能夠馬上判斷並找出導致 VM 虛擬主機效能問題的根本原因（如圖 5 所示）。

自從 Skyline 健康檢查機制支援 vSAN 叢集環境後，有效幫助管理人員在建置和故障排除 vSAN 叢集時，都能透過 Skyline 機制詳細檢查 vSAN 叢集的健康情況，快速辨別和找出可能的組態設定錯誤原因，或者是 SSD 固態硬碟等儲存裝置是否發生故障的情況。

簡單來說，過去 Skyline 檢查項目是眾多項目逐一進行檢查，雖然檢查範圍非常全面且詳盡，但有時組態設定錯誤或災難發生的情況很複雜，甚至也有可能是複合式的故障而引起的災難事件，舉例來說，倘若 vSAN 節點主機發生 vSAN 網路組態問題，進而導致 vSAN 節點主機進入隔離分割區，但這個災難事件的根本原因可能有很多種情況，有可能是 vSAN 網路所連接的實體網路交換器故障，也有可能是 vSAN 節點主機負責處理 vSAN 網路的實體網路卡故障，也有可能是中間連接的網路線或光纖線故障所引起的……等。

現在，最新的 vSAN 7 U3 版本中，將針對 vSAN 叢集健康情況的 Skyline 檢查機制再增強，能夠將眾多健康檢查項目之間，有可能關聯的部份進行連結，幫助管理人員能夠更快速判斷並找出複合式問題的原因，讓整體故障排除時間有效縮短。

舉例來說，有 vSAN 節點主機因為網路或硬體零件故障，脫離 vCenter Server 管理平台的掌控，同時也造成存放於本台 vSAN 節點主機上的 vSAN 儲存物件離線，導致相關使用該 vSAN 儲存物件的服務出現警告或錯誤的情況，但是這一切並非是儲存裝置故障導致的，而是同時間系統發現有 vSAN 節點主機離線所造成的，因為這樣的事件進行關聯並連結後，能夠快速判斷並總結出災難事件發生的根本原因（如圖 6 所示）。

對於 vSAN 叢集分佈式儲存架構來說，由於是眾多 vSAN 節點主機之間，透過 vSAN 網路互相同步和交換彼此之間的 vSAN 儲存物件，達到建構出高可用性和效能強大的分佈式儲存基礎架構。因此，vSAN 節點主機的網路健康情況，對於 vSAN 叢集的整體穩定性來說至關重要。

在新版 vSAN 7 U3 當中，新增幾項針對 vSAN 節點主機網路組態和健康狀態的檢測機制，從底層實體網路卡是否啟用進階功能，例如，TSO（TCP Segmentation Offload）、LRO（Large Receive Offload）……等，到 ESXi 主機層級檢查 vmnic 健康狀態，例如，選擇採用 IP-Hash 負載平衡演算法，但連接的實體網路交換器卻未配置 Port Channel 或配置錯誤……等，到上層組態設定 VMkernel Port 的 vSAN 網路 vmknic，是否有發生 IP 位址重複而導致衝突的情況……等，達到網路組態 End-to-End 的深層檢查（如圖 7 所示）。

對於 VMware 雲端策略有所了解的管理人員來說，應該都知道各大雲端供應商或者是與 VMware 深度整合的軟體供應商，都有提供經過 VMware 認證的 vSphere、vCenter、vSAN 虛擬化環境。在過去，只要 VMware 發佈版本更新時，各大雲端供應商和軟體供應商，便需要針對 vSphere、vCenter、vSAN 虛擬化環境進行版本更新，同時也要針對自家相關的產品發佈更新公告。

現在，從 vSAN 7 U3 版本開始，這些雲端供應商和軟體供應商無須再緊跟 VMware 的版本更新，即可升級至任何版本的 vSphere、vCenter、vSAN 虛擬化環境。簡單來說，整個產品生命週期正式脫勾原有的包袱，能夠更輕鬆的整合及升級產品（如圖 8 所示）。

雖然，vSAN 叢集基礎架構建立完成後便具備高效能和高可用性，然而企業和組織的地端資料中心，難免會有歲休、機房電力調整、UPS 更換、市電切換測試……等因素，需要將 VM 虛擬主機關機，以及 vSAN 叢集進入維護模式後暫時關機的需求。

在過去的 vSAN 版本中，當資料中心因為上述原因需要將 vSAN 叢集暫時關閉時，倘若對於 vSAN 叢集的運作機制沒有一定的熟悉度時，那麼管理人員很有可能在關閉 vSAN 叢集的過程中，輕者讓整體關閉 vSAN 叢集的時間過長，嚴重者可能會無意間造成 vSAN 物件發生遺失或損壞的情況，造成後續 VM 虛擬主機啟動不正常或失敗等情況。

舉例來說，當 vSAN 叢集需要關閉時，管理人員在將 vSAN 叢集上運作的 VM 虛擬主機和營運服務關閉之前，應該先將 vSAN 叢集的 DRS 負載平衡和 HA 高可用性機制關閉，避免在關閉 VM 虛擬主機的過程中，因為未關閉 DRS 負載平衡和 HA 高可用性機制，讓 vSAN 叢集誤以為 VM 虛擬主機停擺而自動重新啟動，甚至當 vSAN 節點主機上的 VM 虛擬主機關閉後，當 vSAN 節點主機需要進入維護模式時（如圖 9 所示），管理人員也必須選擇對 vSAN 節點主機中 vSAN 物件的處理情況，這些選擇都再再考驗著管理人員對於 vSAN 叢集的熟悉度。

假設一位對於 vSAN 叢集運作機制不熟悉的管理人員，需要將 vSAN 叢集關閉時，一開始為了確保所有 vSAN 物件能夠被遷移，可能會選擇「Full data migration」項目，但是選擇此項目後，等同於 vSAN 節點主機必須遷移其上所有 vSAN 物件後，才會正式進入維護模式，由於遷移所有 vSAN 物件需要花費大量時間，因此針對後續的 vSAN 節點主機時，管理人員為了縮短等待時間，而可能會選擇最快速進入維護模式的「No data migration」項目。

雖然，選擇「No data migration」項目，能夠讓 vSAN 節點主機無須遷移任何的 vSAN 物件，即可順利進入維護模式。然而，若是 vSAN 叢集中仍有 VM 虛擬主機尚未關機，並且該 VM 虛擬主機是採用「RAID-0」儲存原則進行部署時，那麼當該台 VM 虛擬主機 vSAN 物件，所屬的 vSAN 節點主機選擇採用「No data migration」進入維護模式時，便有可能造成該台 VM 虛擬主機資料遺失或損壞的可能，這也是為何在過去 vSAN 版本中，倘若遇到 vSAN 叢集必須暫時關閉的情況時，建議由熟悉 vSAN 叢集運作機制的管理人員，一步一步檢查和關閉相關服務及選擇最適合的選項，確保 vSAN 叢集能夠被正確關閉。

現在，最新的 vSAN 7 U3 版本中，新增「叢集感知智慧啟動和關閉工作流」（Intelligent Cluster Aware Shutdown and Start-up Workflows）機制，讓整個關閉和重新啟動 vSAN 叢集的流程，透過智慧型的引導式工作流變得簡單且一致，同時在關閉和重新啟動的過程中，將會隨時監控並檢查可能出現問題的環節，讓不熟悉 vSAN 叢集運作機制的管理人員，也能順利關閉和重新啟動 vSAN 叢集。

在 vSAN 叢集感知智慧工作流運作機制中（如圖 10 所示），執行 vSAN 叢集的關閉和重新啟動流程之前，會先在 vSAN 叢集中透過選舉的方式，由系統在眾多 vSAN 節點主機中，自動選出一台 vSAN 節點主機擔任「協調流程主機」（Orchestration Host）角色，一旦選舉和指派角色作業完成後，其它 vSAN 節點主機透過系統傳遞的「中繼資料」（Metadata），便會知道 vSAN 叢集中哪一台主機擔任協調流程主機角色。

值得注意的是，原則上協調流程主機會由系統在 vSAN 節點主機中任選一台。然而，當 vCenter 管理平台執行個體運作在 vSAN 叢集時，那麼協調流程主機的角色，便自動由 vCenter 管理平台所處的 vSAN 節點主機擔任。

此外，vSAN 叢集感知智慧工作流運作機制，不僅僅適用於一般 vSAN 叢集，也同時適用於大型規模的「vSAN 延伸叢集」（vSAN Stretched Cluster），和小型規模的 vSAN 雙節點叢集運作環境。

原則上，預設情況下執行關閉 vSAN 叢集的動作後，運作機制會連系統專用的 VM 虛擬主機也一併關機，舉例來說，維護 vSphere 叢集狀態專用的 vCLS 主機也會一併關機，但是有些系統專用的 VM 虛擬主機可能不會被關機，例如，vSAN 檔案服務虛擬主機、Pod 虛擬主機、NSX 管理主機 …… 等。此外，倘若 vSAN 節點主機啟用「鎖定模式」（Lockdown Mode）時，則 vSAN 節點主機屆時只會進入維護模式而不會自動關機。

在關閉 vSAN 叢集的過程中，管理人員可以從下方工作列看到「Execute power off logic on orchestration host」項目，並且從 Target 欄位也可以看到，此次 vSAN 叢集中選舉出來的協調流程主機角色由誰擔任。同時，管理人員也可以在 vCenter 管理介面中，依序點選「vSAN Cluster > Configure > vSAN > Services」項目，便能即時查看關閉 vSAN 叢集的執行進度和階段（如圖 14 所示）。

當資料中心維護動作執行完成後，首先管理人員必須手動為每台 vSAN 節點主機啟動電源，確保 vSAN 叢集中的每台 vSAN 節點主機，皆已經啟動完成並顯示 DCUI 登入畫面後，回到 vCenter 管理介面確認每台 vSAN 節點主機，是否已經從原本未回應且離線的關機狀態，恢復成為連線中的維護模式狀態。

確認後，請在 vCenter 管理介面中，依序點選「vSAN Cluster > Actions > vSAN > Restart Cluster」項目，此時系統將會再次執行眾多預先檢查項目，確保每台 vSAN 節點主機的健康狀態，是否能夠順利讓 vSAN 叢集成功啟用，倘若有任何狀態無法通過預先檢查項目時，Restart vSAN 叢集的精靈視窗中，將會顯示該檢查項目的警告或錯誤資訊，幫助管理人員進行故障排除作業，通過預先檢查並確認重新啟動 vSAN 叢集後，請按下「RESTART」鈕即可（如圖 16 所示）。