在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所示。

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

vSAN DPp資料持續性平台

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

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

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

同時支援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工作負載。

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

共享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叢集。

儲存資源可用率增加

在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叢集中針對儲存堆疊進行最佳化，達到最大化程度縮小儲存預留空間的目的。

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

‧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所示。

啟用vSAN原生檔案服務

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

確認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節點主機。

值得注意的是，採用自動下載檔案服務代理程式選項時，一旦管理人員按下〔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所示。

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

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

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

管理人員可以觀察到，因為有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所示。

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

建立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所示。

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

掛載SMB檔案共享儲存資源

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

在Windows主機端開啟檔案總管後，依序點選「This PC > Map network drive」項目，在Folder欄位內貼上剛才複製的SMB檔案共享路徑，本