軟體定義儲存 vSAN 超融合基礎架構

vSAN 7 U1新增實用功能 省下硬體儲存採購預算

啟用原生檔案服務 vSAN也能運作NFS/SMB

2021-03-02
本文將介紹全新的VMware vSAN 7 U1版本新增哪些亮眼特色功能,說明建構vSAN 7 U1超融合叢集後,可提供運作VM虛擬主機和容器等各項應用,然後實作vSAN叢集啟用原生檔案服務,示範如何提供企業常用的NFS和SMB檔案共享服務。

 

在2020年4月VMware官方發佈全新vSAN 7版本,2020年10月時又推出最新的「vSAN 7 Update 1」版本。或許,一般對於Update 1版本的認知僅是小版本的更新,然而vSAN 7 Update 1版本,卻是除了增強原有特色功能之外,又同時新增了許多亮眼的特色功能。本文因篇幅關係,僅說明部分亮眼特色功能,詳細資訊請參考VMware vSAN 7.0 Update 1 Release Notes。

事實上,VMware vSAN超融合基礎架構,已經不僅僅是企業和組織內部資料中心的主要基礎架構,更是軟體定義資料中心(SDDC)願景和VMware Cloud Foundation(VCF)的主要基礎架構。現在,無論是地端的SDS軟體定義儲存,或是混合SDC和SDS的HCI超融合基礎架構,甚至是各大公有雲供應商(例如Amazon AWX、Microsoft Azure、Google GCP、IBM Cloud等等),都已經支援原生vSAN超融合基礎架構,達成串接公有雲和私有雲形成更具彈性的混合雲運作環境,如圖1所示。

圖1  VMware雲端核心基礎架構vSphere和vSAN運作架構示意圖。 (圖片來源:VMware Blogs - Announcing General Availability of vSAN 7 Update 1)

vSAN 7 Update 1亮眼特色功能介紹

事實上,根據VMware官方壓力測試數據的結果顯示,最新的vSAN 7 Update 1版本,除了下列說明的亮眼特色功能之外,與舊有的vSAN 6.7 Update 3版本相較,整體儲存效能提升約30%之多,這表示企業無須更換原有硬體,只要升級至新版vSAN 7 Update 1運作環境,即可享有儲存效能提升30%的好處。

vSAN HCI Mesh

在過去的vSAN叢集架構中,雖然可以透過Scale-Up或Scale-Out方式擴充vSAN叢集規模,或者整合vSAN iSCSI Target機制,提供vSAN儲存資源給其他工作負載使用。然而,管理人員更希望vSAN叢集之間的儲存資源能夠彼此共享互助,以便其上運作的VM虛擬主機和容器等工作負載,能夠更容易地在vSAN叢集之間無縫遷移。

而全新的vSAN 7 U1版本新增了vSAN叢集分佈式機制,稱之為「超融合網狀」(HCI Mesh)架構。簡單來說,在多個vSAN叢集運作架構下,每個vSAN叢集不僅可使用自身建構的本地端vSAN Datastore,還能掛載及使用其他vSAN叢集的vSAN Datastore儲存資源,如圖2所示。

圖2  新版vSAN 7 U1 HCI Mesh運作架構示意圖。 (圖片來源:VMware Tech Zone - VMware vSAN HCI Mesh Tech Note)

vSAN DPp資料持續性平台

vSAN「資料持續性平台」(Data Persistence platform,DPp),支援在Kubernetes容器平台的vSphere Supervisor叢集中,部署第三方軟體和工作負載並原生支援儲存物件複寫和保護機制,如圖3所示。

圖3  vSAN DPp資料持續性平台運作架構示意圖。 (圖片來源:VMware Tech Zone – vSAN Data Persistence platform (DPp))

簡單來說,即便管理人員採用「FTT=0」的vSAN儲存原則進行部署,仍然不影響部署工作負載的可用性,真正達到「無共享」(Shared-Nothing)儲存資源的目標,如圖4所示。

圖4  vSphere Shared Nothing Storage運作架構示意圖。 (圖片來源:VMware Docs - Using vSAN Data Persistence Platform with vSphere with Tanzu)

舉例來說,現代化應用程式中有許多工作負載的儲存資源,都是透過本地端儲存資料後,藉由分散式架構進行資料的複寫和壓縮等等,例如MinIO Object Storage、NoSQL Database等等。此時,管理人員便可以透過vSAN Direct機制,如圖5所示,讓工作負載不要使用傳統的vSAN Datastore,而是適用於現代化應用程式的「vSAN-D」Datastore儲存資源。

圖5  vSAN Direct運作架構示意圖。 (圖片來源:VMware Tech Zone – vSAN Direct)

同時支援NFS和SMB檔案共享

過去,企業組織若希望vSphere運作環境能夠支援NFS檔案共享時,唯一的解決方案是採用Storage VM提供NFS檔案共享機制,如圖6所示。在前一版vSAN 7版本中,vSAN叢集已經透過「原生檔案服務」(Native File Services)支援NFS檔案共享機制,並採用Photon OS架構運作「檔案服務虛擬主機」(File Service VM,FSVM),除了有效解決過去Storage VM提供NFS檔案共享機制的缺點外,同時提升NFS檔案共享效能並降低vSphere ESXi工作負載。

圖6  傳統Storage VM提供的NFS檔案共享機制有許多缺點。 (圖片來源:VMware Tech Zone – Storage Controller Virtual Appliance Disadvantages)

現在,最新的vSAN 7 U1版本,除了原有支援的NFS v3和NFS v4.1通訊協定外,還新增支援SMB v2.1和SMB v3通訊協定。簡單來說,無論是Windows主機和Linux主機或容器都能夠輕鬆透過NFS或SMB檔案共享機制,掛載使用並運作於高效能和高可用性的vSAN Datastore儲存資源之上,如圖7所示。

圖7  最新vSAN 7 Update 1原生檔案服務運作架構示意圖。 (圖片來源:VMware Tech Zone – Native File Services)

共享vSAN Witness

在vSAN叢集運作架構中,當vSAN叢集的節點主機數量為小型規模的「2」台時,管理人員必須額外部署「vSAN見證主機」(vSAN Witness Host),以避免小型規模的vSAN叢集發生「腦裂」(Split-Brain)的情況。然而,當企業有許多分公司或辦事處時,可能會建構許多小型規模的vSAN叢集,並部署同等數量的vSAN見證主機,形成無謂的資源閒置和浪費。

因此,在新版vSAN 7 U1版本中,小型規模的vSAN叢集可以共同使用,由總公司建置單一且具備高可用性的vSAN見證主機即可,無須再為每個小型規模的SAN叢集建構獨立的vSAN見證主機,如圖8所示。在新版vSAN 7 U1中,單一vSAN見證主機最多支援「64」個小型規模vSAN叢集。

圖8  新版的vSAN 7 U1支援2-Node vSAN叢集共用單一vSAN見證主機。 (圖片來源:VMware Tech Zone – Cluster Types – 2 Node Cluster)

儲存資源可用率增加

在vSAN叢集架構中,除了VM虛擬主機和容器等工作負載使用的儲存物件之外,vSAN叢集的各項操作,例如重新負載平衡vSAN節點主機儲存資源、重新配置vSAN儲存原則、受損儲存物件重建工作任務、vSAN節點主機之間儲存物件重新同步等等,皆會佔用儲存空間。

因此,在過去的vSAN叢集架構中,將會針對這些vSAN叢集維運操作步驟預留「25~30%」的儲存空間,並且這個預留空間是「固定」(Fixed)且無法進行任何變更。固定不可變更的預留空間,稱之為「寬限儲存空間」(Slack Space)。

新版vSAN 7 U1版本中,除了將這個預留空間從過去固定不可變更調整為「可變」(Varies)之外,並拆解為「操作預留」(Operations Reserve,OR)以及「主機重建預留」(Host reBuild Reserve,HBR),如圖9所示,更在vSAN叢集中針對儲存堆疊進行最佳化,達到最大化程度縮小儲存預留空間的目的。

圖9  新版vSAN 7 U1將固定不可變改為視情況變動的預留儲存空間機制。 (圖片來源:VMware Blogs - Effective Capacity Management with vSAN 7 Update 1)

此外,管理人員可以依據vSAN叢集規模和專案需求,直接透過vSphere管理介面調整OR操作預留和HBR主機重建預留儲存空間比率,如圖10所示。下列則是VMware官方依據不同vSAN叢集規模,預設採用的儲存空間比率和總預留儲存空間比率:

圖10  組態設定OR操作預留和HBR主機重建預留儲存空間比率。 (圖片來源:VMware Tech Zone – Capacity Management Guidance)

‧4台vSAN叢集節點主機:10% OR + 25% HBR(30%總預留儲存空間比率)

‧6台vSAN叢集節點主機:10% OR + 17% HBR(27%總預留儲存空間比率)

‧7台vSAN叢集節點主機:10% OR + 13% HBR(23%總預留儲存空間比率)

‧12台vSAN叢集節點主機:10% OR + 8% HBR(18%總預留儲存空間比率)

‧18台vSAN叢集節點主機:10% OR + 6% HBR(16%總預留儲存空間比率)

‧24台vSAN叢集節點主機:10% OR + 4% HBR(14%總預留儲存空間比率)

‧32台vSAN叢集節點主機:10% OR + 3% HBR(13%總預留儲存空間比率)

‧48台vSAN叢集節點主機:10% OR + 2% HBR(12%總預留儲存空間比率)

‧64台vSAN叢集節點主機:10% OR + 2% HBR(12%總預留儲存空間比率)

實戰vSAN 7原生檔案服務

現在,新版vSAN 7 U1已經支援提供SMBv2.1和SMBv3檔案共享機制,除了提供給Windows主機和Linux主機和容器進行檔案共享儲存資源外,同時整合企業和組織內的Active Directory進行身分驗證,如圖11所示。

圖11  最新版本vSAN原生檔案服務,同時支援NFS和SMB協定運作架構示意圖。 (圖片來源:VMware Virtual Blocks - vSAN 7 U1 File Services)

啟用vSAN原生檔案服務

在本文實作環境中,在vSAN叢集內共部署3台vSAN叢集節點主機,並完成vDS分佈式虛擬交換器的組態設定,如圖12所示,確保屆時3台vSAN節點主機之間vSAN Traffic儲存流量交換。同時,在相關前置作業完成後,於vSAN叢集中啟用vSAN超融合功能,以便將3台vSAN節點主機的本機儲存裝置,彙整成為高效能和高可用性的vSAN Datastore儲存資源。

圖12  用於vSAN叢集環境的vDS分佈式虛擬交換器組態設定示意圖。

確認vSAN叢集和超融合功能正常運作後,依序點選「vSAN Cluster > Configure > vSAN > Services > File Service > Enable」項目,系統便會彈出組態設定原生檔案服務精靈的對話視窗。必須留意的是,在組態設定畫面中,系統會再次提醒管理人員繼續下一個操作步驟之前,應先確認是否已經準備好運作環境,例如固定IP位址、DNS名稱解析、AD網域環境等等。

在File service agent頁面中,選擇採用「Automatic Approach」預設值項目,並且勾選「Trust the certificate」選項,如圖13所示,以便vCenter Server能夠直接前往VMware官網下載最新穩定版本的檔案服務代理程式,並於下載完成後部署至vSAN叢集中的每一台vSAN節點主機。

圖13  採用自動前往VMware官方下載最新穩定版本的檔案服務代理程式。

值得注意的是,採用自動下載檔案服務代理程式選項時,一旦管理人員按下〔Next〕按鈕之後,vCenter Server便會立即至VMware官網下載檔案服務代理程式,並在下方Task Panel顯示下載進度,工作進度名稱為「Download vSAN File Service OVF」。

在Domain頁面中,管理人員必須提供vSAN檔案服務的相關資訊,例如本文實作環境中檔案服務網域名稱為「vsanfs」,而DNS名稱解析伺服器的IP位址為「10.10.75.10」、DNS尾碼是「lab.weithenn.org」,並勾選「Active Directory」項目啟用AD身分驗證機制、AD網域名稱、網域管理員帳號和密碼等等資訊,如圖14所示。

圖14  組態設定vSAN檔案服務的網域相關資訊。

而在Networking頁面中,管理人員必須選擇屆時部署檔案服務代理程式,所要使用的SMB檔案共享網路環境vDS Port Group,點選Network欄位下拉式選單,選擇本文實作環境採用的「SMB Network」,並鍵入子網路遮罩「255.255.255.0」和預設閘道「10.10.75.254」,如圖15所示。

圖15  組態設定檔案服務代理程式使用的SMB檔案共享網路環境Port Group。

在IP Pool頁面中,必須鍵入檔案服務代理程式所要使用的IP位址資源池,在VMware最佳建議作法中,建議為vSAN叢集中的每一台vSAN節點主機,額外配置專用於SMB檔案共享服務IP位址資源池,並建議採用連續的IP位址。在本文實作環境中,設定第一筆IP位址「10.10.75.31」後,按下「Lookup DNS」確保能夠正確進行DNS名稱解析,然後按下「AutoFill」,系統將依序遞增IP位址,並再次按下「Lookup DNS」,以確保新加入的IP位址能夠順利地進行DNS名稱解析,如圖16所示。

圖16  組態設定檔案服務代理程式所要使用的IP位址資源池。

在Review頁面中,再次檢視所有組態設定內容正確無誤後按下〔Finish〕按鈕,系統便立即進行檔案服務代理程式的部署作業。一旦部署工作任務完成,在vSAN叢集中的每一台vSAN節點主機上,便會運作一台「vSAN File Service Node」的虛擬主機,如圖17所示,採用的客體作業系統為「VMware Photon OS」,並由vSphere ESX Agent Manager所管理。

圖17  系統自動化部署vSAN File Service Node虛擬主機。

管理人員可以觀察到,因為有3台vSAN節點主機,所以部署3台vSAN File Service Node,並且系統會優先部署Primary的vSAN節點主機,接著建立快照後再複製並部署至其他台vSAN節點主機。

檢查檔案服務健康狀態

順利部署vSAN File Service Node虛擬主機後,在組態設定SMB檔案共享機制之前,先在管理介面中依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health > File Service > Infrastructure Health」項目,確認vSAN叢集檔案服務的基礎架構系統服務健康狀態,例如部署的vSAN File Service Node、VDFS服務、根目錄檔案系統、檔案服務負載平衡機制等等,如圖18所示。

圖18  檢查vSAN叢集檔案服務的基礎架構系統服務健康狀態。

接著,點選「File Service > File Server Health」項目,檢查vSAN叢集檔案服務中,檔案服務網域名稱是否正確、NFS和SMB檔案共享服務是否運作正常、根目錄檔案系統是否能正常存取等等,如圖19所示。

圖19  檢查vSAN叢集檔案服務健康狀態。

建立SMB檔案共享機制

確認vSAN檔案服務皆運作正常後,在管理介面中依序點選「vSAN Cluster > Configure > vSAN > File Shares」項目,按下「Add」準備新增SMB檔案共享機制。

在本文實作環境中,SMB檔案共享網路名稱為「smb-share」,在通訊協定的部分,由於vSAN 7 U1版本已經同時支援NFS和SMB檔案共享機制,所以記得通訊協定選擇至「SMB」項目,而vSAN儲存原則採用「vSAN Default Storage Policy」預設值。同時,可以啟用SMB檔案共享儲存空間限制,本文實作組態設定觸發儲存空間警告的臨介值為「5GB」,並且限制最大儲存空間為「10GB」,如圖20所示。

圖20  組態設定SMB檔案共享網路名稱和儲存空間警告並限制最大儲存空間。

在Review頁面中,再次檢視所有組態設定內容是否正確無誤,確認無誤後按下〔Finish〕按鈕,立即執行SMB檔案共享的工作任務。當SMB檔案共享機制建立完成後便能看見相關資訊,後續管理人員也可以依照專案需求,隨時調整套用的vSAN儲存原則,以及儲存空間警告和儲存空間限制臨界值,如圖21所示。

圖21  SMB檔案共享機制建立完成。

掛載SMB檔案共享儲存資源

那麼從Windows主機端該如何掛載SMB檔案共享儲存資源?管理人員可以從管理介面中,點選本文實作的SMB檔案共享資源項目,然後按下SMB export path欄位的「Copy Path」圖示,系統便會自動複製SMB檔案共享資源掛載路徑至主機的剪貼簿內。

在Windows主機端開啟檔案總管後,依序點選「This PC > Map network drive」項目,在Folder欄位內貼上剛才複製的SMB檔案共享路徑,本文實作環境為「\\vsan-fs01.lab.weithenn.org\vsanfs\smb-share」,然後按下〔Finish〕按鈕即可,如圖22所示。

圖22  掛載SMB檔案共享儲存資源。

測試警告和儲存空間限制機制

接著,測試先前組態設定的SMB檔案共享儲存空間警告和最大儲存空間限制機制,在本文實作環境中觸發儲存空間警告的臨介值是「5GB」,而最大儲存空間限制為「10GB」。

首先,在Windows主機端,透過檔案總管複製7.53GB的測試檔案過去,然後切換至SMB檔案共享管理介面中,可以看到已經觸發儲存空間警告,並且距離最大儲存空間限制的門檻也已達「75%」使用率,如圖23所示。

圖23  查看SMB檔案共享儲存空間警告和儲存空間限制資訊。

由於仍然未達到SMB檔案共享最大儲存空間限制10GB,所以Windows主機端仍然能夠寫入檔案,然而當寫入資料達到最大儲存空間限制10GB門檻時,嘗試再寫入資料時便會出現錯誤訊息,並且無法再繼續寫入任何資料,如圖24所示。

圖24  寫入資料達到最大儲存空間限制10GB時便無法再寫入任何資料。

此時,切換至vSphere管理介面,依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health」項目,可以看到「File Service > Share health」子項目出現黃色警告訊息,原因是SMB檔案共享儲存資源達到最大儲存空間限制,如圖25所示。

圖25  透過Skyline Health健康偵測機制,查看SMB檔案共享儲存資源健康情況。

除此之外,管理人員也可以直接查看SMB檔案共享的儲存效能資訊,例如Throughput、IOPS、Latency等等,如圖26所示,確保提供給Windows主機端最佳使用者操作體驗。

圖26  查看SMB檔案共享的儲存效能資訊。

值得注意的是,目前在vSphere管理介面中無法直接查看SMB客戶端存取資訊,例如哪些Windows主機存取SMB檔案共用資源、哪些網域使用者帳號進行存取、開啟哪些SMB儲存資源內的檔案等等。在剛才複製SMB檔案共用的視窗中,按下MMC command欄位的複製圖示,接著在Windows主機端中的命令提示字元內執行,即可透過Windows主機的MMC查看相關資訊,如圖27所示。

圖27  透過MMC指令查看SMB檔案共用資源存取資訊。

測試vSAN檔案服務高可用性

由於SMB檔案共享儲存資源為運作在vSAN叢集之上的應用服務,所以如同運作在vSAN Datastore內受保護的工作負載一樣,除了享有vSAN叢集提供的高效能之外,同樣兼具高可用性。

在vSphere管理介面內可以看到,目前建立的「smb-share」檔案共享儲存資源中,系統自動指派「vsan-smb01.lab.weithenn.org」主機負責,將此台vSAN節點主機直接斷電以便模擬故障損害的情境,同時測試SMB檔案共享儲存資源的可用性。

到管理介面中,依序點選「vSAN Cluster > Monitor > vSAN > Virtual Objects > Affected inventory objects > File Shares」項目,然後點選SMB檔案共享儲存資源「smb-share」,再按下「View Placement Details」,即可看到SMB檔案共享儲存資源物件,分佈在vSAN叢集中哪些vSAN節點主機上,如圖28所示。

圖28  查看SMB檔案共享儲存資源物件分佈情況。

當vSAN節點主機「vsan-smb01.lab.weithenn.org」斷電後,再次查看SMB檔案共享儲存資源物件分佈情況,將會發現原本由「vsan-smb01.lab.weithenn.org」主機負責的儲存物件,狀態由先前健康良好的「Active」轉變為「Absent」,如圖29所示。

圖29  原本由vsan-smb01.lab.weithenn.org節點主機負責儲存的物件狀態轉變為Absent。

此外,若切換到「smb-share」檔案共享儲存資源頁面,可以發現原本由「vsan-smb01.lab.weithenn.org」負責SMB檔案共享服務,因為發生斷電故障損壞情況後,系統改為指派由「vsan-smb02.lab.weithenn.org」vSAN節點主機接手負責SMB檔案共享服務,如圖30所示。

圖30  由vSAN節點主機vsan-smb02.lab.weithenn.org接手SMB檔案共享服務。

結語

透過本文的深入剖析和實作演練後,大家應該都已經了解全新vSAN 7 U1版本新增哪些亮眼特色功能,而建構vSAN 7 U1超融合叢集後,不僅提供運作VM虛擬主機和容器等各項應用,並且只要為vSAN叢集啟用原生檔案服務,便能立即提供企業常用的NFS和SMB檔案共享服務,無須再額外採購硬體儲存設備。

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

 


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!