vSAN 7 Update 3快覽　實戰智慧式叢集關機重啟

隨著VMworld 2021大會的舉行，最新版本HCI超融合基礎架構的「vSAN 7 Update 3」也同步推出。事實上，對於IT管理人員來說，對於Update版本的認知，通常大多為安全性更新或是臭蟲修正，然而最新發佈的vSAN 7 Update 3版本，除了將原有特色功能大幅增強外，更同時新增許多亮眼的特色功能，如圖1所示。本文因礙於篇幅的關係，僅挑選部分亮眼特色功能進行說明，詳細資訊請參考VMware vSAN 7.0 Update 3 Release Notes。

vSAN 7 Update 3亮眼特色功能

接下來，將介紹vSAN 7 Update 3中幾項亮眼的特色功能。

小型規模vSAN叢集可用性提升

許多企業和組織已經在資料中心規模較小的分公司，部署2台vSAN節點主機建構小型vSAN叢集環境，而擔任vSAN叢集中仲裁角色的見證主機，可能部署於總公司資料中心或第三地資料中心，如圖2所示。

然而，在過去的2-Node vSAN叢集架構中，只能承受較小型的災難和故障情況，舉例來說，倘若其中1台vSAN節點主機發生故障，很有可能因為見證物件或VM虛擬主機物件都存放在該台vSAN節點主機中，而造成部分的VM虛擬主機產生資料遺失或無法正常運作的情況。

現在最新的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虛擬主機和內部運作的企業服務依然正常運作。

支援新世代TPM模組

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

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

更精細的VM效能分析數據

事實上，在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 7叢集感知智慧工作流

雖然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叢集感知智慧工作流

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叢集

在本文實作環境中，共有兩個不同的叢集，分別是vCenter管理平台運作的專屬vSphere叢集（MGMT-Cluster），以及HCI超融合運作架構的vSAN叢集（vSAN-Cluster），在vSAN叢集內總共部署三台vSAN叢集節點主機，已完成vDS分佈式虛擬交換器的組態設定，確保三台vSAN節點主機之間vSAN Traffic儲存流量交換順利，並且在相關前置作業完成後，於vSAN叢集中啟用vSAN超融合功能，以便將三台vSAN節點主機的本機儲存裝置，彙整成為高效能和高可用性的vSAN Datastore儲存資源，如圖11所示。

當vSAN叢集必須執行「關閉」（Shutdown）動作時，只要在vCenter管理介面中依序點選「vSAN Cluster > Actions > vSAN > Shutdown Cluster」項目，系統便會彈出Shutdown cluster精靈互動視窗，並且自動執行關閉vSAN叢集的眾多預先檢查工作項目，如圖12所示，例如確保vSAN節點主機之間沒有發生通訊不良造成的隔離分割情況、確保vSAN儲存物件為健康狀態、使用HCI Mesh機制的遠端VM虛擬主機是否已經關機等等，確保vSAN叢集能夠正確且安全並順利關閉。

在步驟二確認關閉vSAN叢集視窗中，系統再次提醒管理人員稍後會執行的相關動作，例如關閉所有在vSAN叢集中運作的VM虛擬主機、關閉vSAN叢集的HA高可用性機制、暫停所有vSAN節點主機中vSAN儲存物件的狀態、vSAN節點主機進入維護模式、vSAN節點主機關機等等，並且在Shutdown reason下拉式選單中，選擇此次關閉vSAN叢集的理由並鍵入關閉的原因，再按下〔Shutdown〕按鈕便會立即執行關閉vSAN叢集的動作，如圖13所示。

原則上，預設情況下執行關閉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叢集的執行進度達到100%完成時，系統確認vSAN叢集和vSAN節點主機都順利關機後，vSAN Services頁面內將會顯示「This vSAN cluster has been shut down.」訊息，並且只剩下〔RESTART〕按鈕，如圖15所示，也就是稍後重新啟動vSAN叢集時使用。

重新啟動vSAN叢集

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

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

當vSAN叢集順利重新啟動後，原有的vSAN Services頁面便會恢復成vSAN叢集中各項vSAN服務啟用和組態設定管理畫面，如圖18所示。此時，vSAN叢集已經成功重新啟動並正常運作。

＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞