網管人 196 期 - vSAN 7 Update 3 快覽實戰智慧式叢集關機重啟



網管人雜誌

本文刊載於 網管人雜誌第 196 期 - 2022 年 5 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

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





vSAN 7 Update 3 亮眼特色功能

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

許多企業和組織,已經在資料中心規模較小的分公司,部署 2 台 vSAN 節點主機建構小型 vSAN 叢集環境,擔任 vSAN 叢集中仲裁角色的見證主機,可能部署於總公司資料中心或第三地資料中心(如圖 2 所示)。然而,在過去的 2-Node vSAN 叢集架構中,只能承受較小型的災難和故障情況,舉例來說,倘若其中 1 台 vSAN 節點主機故障時,很有可能因為見證物件或 VM 虛擬主機物件,都存放在該台 vSAN 節點主機中,造成部份的 VM 虛擬主機可能產生資料遺失或無法正常運作的情況。

圖 2、分公司部署 2 台 vSAN 節點主機建構小型 vSAN 叢集示意圖

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

圖 3、2-Node vSAN 叢集遭遇重大災難事件仍能正常運作示意圖



支援新世代 TPM 模組

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

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

圖 4、vSphere NKP 和外部 KMS 完全支援整合 TPM 加密模組示意圖



更精細的 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 所示)。

圖 5、透過 VM 虛擬主機 I/O 效能分析機制,快速找出導致效能問題的根本原因



更全面的健康狀態檢查機制

自從 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 所示)。

圖 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 所示)。

圖 7、End-to-End 的 vSAN 網路組態設定檢測機制示意圖



雲端原生機制更新升級不受限

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

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

圖 8、供應商可輕鬆升級至任何版本的 vSphere、vCenter、vSAN 虛擬化環境





實戰演練- 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 叢集的熟悉度。

圖 9、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 叢集中哪一台主機擔任協調流程主機角色。

圖 10、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 分佈式虛擬交換器的組態設定,確保 3 台 vSAN 節點主機之間 vSAN Traffic 儲存流量交換順利,並且在相關前置作業完成後,於 vSAN 叢集中啟用 vSAN 超融合功能,以便將三台 vSAN 節點主機的本機儲存裝置,彙整成為高效能和高可用性的 vSAN Datastore 儲存資源(如圖 11 所示)。

圖 11、vSAN 叢集建置完成並運作正常

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

圖 12、執行關閉 vSAN 叢集的眾多預先檢查工作項目

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

圖 13、確認關閉 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 所示)。

圖 14、即時查看關閉 vSAN 叢集的執行進度和階段

當關閉 vSAN 叢集的執行進度達到 100% 完成時,系統確認 vSAN 叢集和 vSAN 節點主機都順利關機後,vSAN Services 頁面內容將會顯示「This vSAN cluster has been shut down.」訊息,並且只剩下「RESTART」鈕(如圖 15 所示),也就是稍後重新啟動 vSAN 叢集時使用。

圖 15、系統顯示已順利關閉 vSAN 叢集和所有 vSAN 節點主機



重新啟動 vSAN 叢集

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

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

圖 16、通過預先檢查項目並確定重新啟動 vSAN 叢集

同樣的,管理人員可以在 vCenter 管理介面中,再次依序點選「vSAN Cluster > Configure > vSAN > Services」項目,即可即時查看重新啟動 vSAN 叢集的執行進度和工作階段(如圖 17 所示)。

圖 17、即時查看重新啟動 vSAN 叢集的執行進度和工作階段

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

圖 18、vSAN 叢集成功重新啟動並正常運作





結語

透過本文的深入剖析和實作演練後,相信讀者已經深刻了解到,全新 vSAN 7 U3 版本新增哪些亮眼特色功能,並且實作演練最新的 vSAN 叢集感知智慧工作流機制,讓以往不熟悉 vSAN 叢集運作架構和機制的管理人員,也可以輕鬆達成關閉和重新啟動 vSAN 叢集的維護工作任務。