本文將介紹全新的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。＞