網管人雜誌
本文刊載於 網管人雜誌第 182 期 - 2021 年 3 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言
在 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 軟體定義資料中心願景和 VCF（VMware Cloud Foundation）的主要基礎架構。現在，無論是地端的 SDS 軟體定義儲存，或是混合 SDC 和 SDS 的 HCI 超融合基礎架構，甚至是各大公有雲供應商，例如，Amazon AWX、Microsoft Azure、Google GCP、IBM Cloud……等，都已經支援原生 vSAN 超融合基礎架構，達成串接公有雲和私有雲形成更具彈性的混合雲運作環境（如圖 1 所示）。
圖 1、VMware 雲端核心基礎架構 vSphere 和 vSAN 運作架構示意圖
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 7 U1 版本中，HCI Mesh 機制僅支援最多串連「16」個 vSAN 叢集，並且每個 vSAN 叢集支援最多掛載「5」個遠端 vSAN Datastore 儲存資源。
圖 2、新版 vSAN 7 U1 HCI Mesh 運作架構示意圖
vSAN DPp 資料持續性平台
vSAN「資料持續性平台」（Data Persistence platform，DPp），支援在 Kubernetes 容器平台的 vSphere Supervisor 叢集中，部署第三方軟體和工作負載並原生支援儲存物件複寫和保護機制（如圖 3 所示）。
圖 3、vSAN DPp 資料持續性平台運作架構示意圖
圖 4、vSphere Shared Nothing Storage 運作架構示意圖
圖 5、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 檔案共享機制有許多缺點
現在，最新的 vSAN 7 U1 版本，除了原有支援的 NFS v3 和 NFS v4.1 通訊協定外，新增支援 SMB v2.1 和 SMB v3 通訊協定。簡單來說，無論是 Windows 主機和 Linux 主機或容器，都能夠輕鬆透過 NFS 或 SMB 檔案共享機制，掛載使用並運作於高效能和高可用性的 vSAN Datastore 儲存資源之上（如圖 7 所示）。
在 vSAN 7 版本中，每個 vSAN 叢集最多支援運作「8」台 File Service 虛擬主機。最新 vSAN 7 U1 版本，則支援每個 vSAN 叢集最多運作「32」台 File Service 虛擬主機。
圖 7、最新 vSAN 7 Update 1 原生檔案服務運作架構示意圖
共享 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 見證主機
儲存資源可用率增加
在 vSAN 叢集架構中，除了 VM 虛擬主機和容器等工作負載使用的儲存物件之外，vSAN 叢集的各項操作，例如，重新負載平衡 vSAN 節點主機儲存資源、重新配置 vSAN 儲存原則、受損儲存物件重建工作任務、vSAN 節點主機之間儲存物件重新同步……等，皆會佔用儲存空間。
因此，在過去的 vSAN 叢集架構中，將會針對這些 vSAN 叢集維運操作步驟預留「25 – 30 %」的儲存空間，並且這個預留空間是「固定」（Fixed）且無法進行任何變更。
固定不可變更的預留空間稱之為「寬限儲存空間」（Slack Space）。
新版 vSAN 7 U1 版本中，除了將這個預留空間，從過去固定不可變更調整為「可變」（Varies）之外（如圖 9 所示），並拆解為「操作預留」（Operations Reserve，OR）和「主機重建預留」（Host reBuild Reserve，HBR），更在 vSAN 叢集中針對儲存堆疊進行最佳化，達到最大化程度縮小儲存預留空間的目的。
圖 9、新版 vSAN 7 U1 將固定不可變改為視情況變動的預留儲存空間機制
此外，管理人員可以依據 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 % 總預留儲存空間比率）
圖 10、組態設定 OR 操作預留和 HBR 主機重建預留儲存空間比率
實戰 vSAN 7 原生檔案服務
現在，新版 vSAN 7 U1 已經支援提供 SMBv2.1 和 SMBv3 檔案共享機制，除了提供給 Windows 主機和 Linux 主機和容器進行檔案共享儲存資源外，同時整合企業和組織內的 Active Directory 進行身份驗證（如圖 11 所示）。
請注意，vSAN 7 版本僅支援 NFSv3 和 NFSv4.1 檔案服務，必須採用最新 vSAN 7 U1 版本才支援 SMBv2.1 和 SMBv3 檔案服務。
圖 11、最新版本 vSAN 原生檔案服務，同時支援 NFS 和 SMB 協定運作架構示意圖
啟用 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 節點主機。
值得注意的是，採用自動下載檔案服務代理程式選項時，一旦管理人員按下 Next 鈕之後，vCenter Server 便會立即至 VMware 官網下載檔案服務代理程式，並在下方 Task Panel 顯示下載進度，工作進度名稱為「Download vSAN File Service OVF」。
倘若，vCenter Server 無法接觸網際網路，則管理人員必須預先下載好 vSAN File Service OVF，並改為選擇「Manual Approach」項目，以手動的方式上傳檔案服務代理程式。
圖 13、採用自動前往 VMware 官方下載最新穩定版本的檔案服務代理程式
在 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 所示）。
選項中「Primary」的 IP 位址，表示屆時將負責 NFS/SMB 主要重新導向介面，將檔案共享服務網路流量，重新導向至不同台 vSAN 節點主機的檔案服務代理程式。
圖 16、組態設定檔案服務代理程式所要使用的 IP 位址資源池
在 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 節點主機。
圖 17、系統自動化部署 vSAN File Service Node 虛擬主機
檢查檔案服務健康狀態
順利部署 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 檔案共享儲存空間限制，本文實作組態設定觸發儲存空間警告的臨介值為「5 GB」，並且限制最大儲存空間為「10 GB」（如圖 20 所示）。
圖 20、組態設定 SMB 檔案共享網路名稱和儲存空間警告並限制最大儲存空間
圖 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 檔案共享儲存空間警告和最大儲存空間限制機制，在本文實作環境中觸發儲存空間警告的臨介值為「5 GB」，而最大儲存空間限制為「10 GB」。首先，在 Windows 主機端，透過檔案總管複製 7.53 GB 的測試檔案過去，然後切換至 SMB 檔案共享管理介面中，可以看到已經觸發儲存空間警告，並且距離最大儲存空間限制的門檻也已達「75 %」使用率（如圖 23 所示）。
圖 23、查看 SMB 檔案共享儲存空間警告和儲存空間限制資訊
由於，仍然未達到 SMB 檔案共享最大儲存空間限制 10 GB，所以 Windows 主機端仍然能夠寫入檔案，然而當我們寫入資料達到最大儲存空間限制 10 GB 門檻時，嘗試再寫入資料時便會出現錯誤訊息，並且無法再繼續寫入任何資料（如圖 24 所示）。
圖 24、寫入資料達到最大儲存空間限制 10 GB 時便無法再寫入任何資料
此時，切換至 vSphere 管理介面，依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health」項目，可以看到「File Service > Share health」子項目出現黃色警告訊息，原因便是 SMB 檔案共享儲存資源達到最大儲存空間限制（如圖 25 所示）。
管理人員可以擴充 SMB 檔案共享最大儲存空間限制，或者刪除 SMB 檔案共享儲存資源中不必要的檔案，那麼 SMB 檔案共享便會再次恢復健康狀態。
圖 25、透過 Skyline Health 健康偵測機制，查看 SMB 檔案共享儲存資源健康情況
圖 26、查看 SMB 檔案共享的儲存效能資訊
圖 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 所示）。
一旦 vsan-smb01.lab.weithenn.org 主機修復後回到 vSAN 叢集中，系統將會自動執行受損儲存物件的修復作業，或者 60 分鐘後自動由其它 vSAN 節點主機接手重建相關儲存物件。
圖 29、原本由 vsan-smb01.lab.weithenn.org 節點主機負責儲存的物件狀態轉變為 Absent
此外，我們切換到「smb-share」檔案共享儲存資源頁面，可以看到原本由「vsan-smb01.lab.weithenn.org」負責 SMB 檔案共享服務，因為發生斷電故障損壞情況後，系統改為指派由「vsan-smb02.lab.weithenn.org」vSAN 節點主機，接手負責 SMB 檔案共享服務（如圖 30 所示）。
當然，在 vsan-smb01 節點主機故障損壞期間，Windows 主機端仍然能夠正常存取 SMB 檔案共享儲存資源。
圖 30、由 vSAN 節點主機 vsan-smb02.lab.weithenn.org 接手 SMB 檔案共享服務
結語
透過本文的深入剖析和實作演練後，讀者已經了解全新 vSAN 7 U1 版本新增哪些亮眼特色功能，同時建構 vSAN 7 U1 超融合叢集後，不僅提供企業和組織運作 VM 虛擬主機和容器等各項應用之外，只要為 vSAN 叢集啟用原生檔案服務之後，便能立即提供企業和組織常用的 NFS 和 SMB 檔案共享服務，並且無須再額外採購硬體儲存設備節省寶貴的 IT 預算。