本文以實戰示範的方式說明vSAN檔案服務的運作機制，透過實際建立NFS檔案共用機制，驗證Quota儲存空間限制機制，以及利用系統內建的健康檢查機制、細部執行效能的情況，幫助管理人員在整體維運方面可以更輕鬆並節省時間。
在過去，倘若要達成跨站台高可用性時，企業和組織往往需要依賴傳統的Metro Storage Cluster運作架構才行，但這種運作架構不僅部署繁瑣，還必須高度依賴特定儲存廠商的解決方案才行，導致預算和維運複雜度大幅提升。
最新的VMware Cloud Foundation（VCF）9.0版本除了推出許多亮眼特色功能之外，原有的儲存功能增強也大幅提升，其中最引人注目的功能之一便是vSAN Storage Clusters延伸拓撲機制，它讓企業組織能在跨站台的運作環境中將儲存資源跨越兩個站台進行部署，同時將計算資源分離管理，讓整體架構設計更具彈性，這表示企業能在不同站台之間靈活調整資源配置，並確保VM虛擬主機的工作負載能夠完全依照DRS分散式原則進行合理的數量分布。
這項增強更新的運作核心，在於vSphere與vSAN大幅提升的「站台感知」（Site Awareness）能力，搭配「容錯網域」（Fault Domain）組態設定，能夠確保VM虛擬主機在不同站台之間的最佳化存取路徑，當其中一個站台發生災難事件時，受影響的VM虛擬主機便能自動在另一個站台上重新啟動，維持關鍵營運服務不中斷。
此外，也大幅簡化操作程序，管理人員只須建立vSAN Compute Clusters運作環境，並且定義容錯網域與站台的對應，完成之後即可掛載遠端vSAN Datastore儲存資源。這樣的設計機制，不僅降低部署的技術門檻，也讓跨站台的儲存整合更直覺，如圖1所示。
圖1 VCF9 vSAN Storage Clusters運作架構示意圖。 （圖片來源：Stretched Topologies using vSAN Storage Clusters in VMware Cloud Foundation 9.0 - VMware Cloud Foundation（VCF）Blog）
認識vSAN檔案服務
最新VCF 9的「vSAN File Services」（vSAN檔案服務）提供了下列兩種常見的檔案分享通訊協定，以便VM虛擬主機或實體伺服器能夠進行連線存取作業：
‧NFS（v3和v4.1）：主要分享情境為Linux運作環境，讓多台主機能夠從同一個儲存位置存取資料。NFS會透過「export」方式提供儲存資源，以便NFS客戶端進行掛載，常見的使用情境為LDAP使用者家目錄，和共用檔案庫或非結構化資料儲存區。此外，在雲端原生應用程式（Cloud Native Applications，CNA）的情境中，NFS分享資源也經常扮演重要角色，由於容器工作負載的生命週期是非常短暫的，所以運作於容器中的應用程式，需要一個持續性儲存位置來保存與讀取資料，這類型的持續性儲存通常稱為Read-Write-Many（RWX） Persistent Volume，能夠同時供應多個容器進行讀寫作業，非常適合雲端原生環境。
‧SMB（v2.1和v3）：主要分享情境為Windows運作環境，Windows客戶端透過磁碟機代號或UNC路徑的方式，掛載SMB分享儲存資源至Windows主機。常見的使用情境為各項專案的共用目錄，或是非結構化資料存放區，以及Active Directory使用者家目錄，支援多位使用者同時存取，適合企業內部的專案協作與檔案共享需求。
除了NFS和SMB檔案分享功能外，vSAN檔案服務也支援透過Kerberos驗證機制，提供一致性且安全的存取方式，不僅提升檔案分享的安全性，也讓vSAN檔案服務更好地融入企業組織中原有的身分驗證服務與存取管理架構。它支援多種Kerberos驗證模式（KRB5、KRB5I、KRB5P），以便滿足不同環境的彈性需求：
‧在NFS分享時，Kerberos機制能直接用於驗證與存取控制。
‧在SMB分享時，與Active Directory運作環境整合，讓使用者以企業既有的使用者帳號與密碼進行安全性存取。
vSAN檔案服務透過原有的Cluster-Level Object Manager（CLOM）機制，將檔案分享資料以「物件」（Object）的方式分散在整個vSAN叢集，就像處理VM虛擬主機物件的方式一樣。因此，當vSAN檔案服務啟用後，系統會自動新增一個「通訊服務層」（Protocol Services Layer），確保屆時vSAN檔案服務，分享的NFS/SMB儲存資源能夠在vSAN叢集內，每台叢集節點主機之間公平分配，避免叢集節點主機成為存取瓶頸，進而提升整體效能與可用性。
每個vSAN叢集中的vSAN檔案服務，最多支援500個檔案分享，如圖2所示，這樣的數量足以滿足大多數情境需求，無論是Linux或Windows運作環境的需求，以及需要NFS-based Persistent Volumes機制，提供持續性儲存的雲端原生工作負載環境。值得注意的是，SMB分享機制仍存在最多100個SMB分享的上限。
圖2 每個vSAN叢集中的vSAN檔案服務，最多支援500個檔案分享。 （圖片來源：Enhancements with vSAN File Services in VMware Cloud Foundation 9.0 - VMware Cloud Foundation（VCF）Blog）
啟用vSAN檔案服務
在啟用及組態設定vSAN檔案服務之前，必須先確保vSAN叢集運作環境已經滿足下列需求，避免啟用vSAN檔案服務時遭遇非預期的錯誤：
‧靜態IP位址：必須規劃1組靜態IP位址，以便作為vSAN檔案服務的單一存取入口點。在VMware最佳建議作法中，建議IP位址數量必須與vSAN叢集節點主機數量相同，才能確保存取流量分散與效能表現最佳化。舉例來說，vSAN叢集中有4台vSAN節點主機時，應該準備4個靜態IP位址，避免使用單一IP位址而成為存取的瓶頸。
‧DNS名稱解析：所有規劃用於vSAN檔案服務的靜態IP位址，必須在DNS名稱解析伺服器中完成「正向解析」（Forward Lookup Zone）和「反向解析」（Reverse Lookup Zone）組態設定，確保VM虛擬主機或應用程式在解析vSAN檔案服務的NFS/SMB位址時，不會遭遇到DNS名稱解析錯誤的情況。
‧處於同一個子網路：規劃的靜態IP位址必須處於同一個子網路，才能有效避免跨網段的路由問題，確保vSAN檔案服務的存取流暢性。
‧DVS版本與Port Group：最新VCF9中的vSAN檔案服務，僅支援Distributed Virtual Switch（DVS） 6.6.0或以上版本，管理人員應建立專用於vSAN檔案服務的Port Group，避免與其他網路流量混用，不僅能提升存取效能，也可降低故障排除的複雜度。
‧網路安全模式設定：預設情況下，當啟用vSAN檔案服務時，系統會自動把Promiscuous Mode與Forged Transmits設定為Allow。如果運作環境中有使用NSX網路，必須在NSX管理介面中進行相同的組態設定，確保檔案服務能夠正常運作。
在登入vCenter管理介面後，依序點選「Datacenter > Cluster > Configure > vSAN > Service」，在File Service區塊內按下Enable。隨後進入vSAN檔案服務互動精靈畫面，在1. File Service Domain選項中，於File service domain欄位內鍵入vSAN檔案服務網域名稱，例如fs.lab.weithenn.org。
在2. Network選項中，依序填入DNS伺服器IP位址、DNS尾碼、子網路遮罩、預設閘道IP位址，例如本文實作環境依序為10.10.75.10、lab.weithenn.org、255.255.255.0、10.10.75.254，如圖3所示。接著，往下捲到IP Pool區塊內，將規劃用於vSAN叢集節點主機的主機名稱和IP位址，條列於IP Pool當中，例如10.10.75.31、vsan-01b.fs.lab.weithenn.org等等依序填入。
圖3 組態設定vSAN檔案服務網路環境。
在3. Directory service選項中，若希望後續能夠提供SMB服務，在使用者身分驗證方面便需要啟用Active directory服務才行，勾選Active directory選項，並且填入AD Domain和AD username等等網域和驗證資訊。
值得注意的是，一旦組態設定後，Active directory選項內容便無法再做變更。
在4. Review頁面中，務必重新檢視組態設定vSAN檔案服務內容是否正確，確認後按下〔Finish〕鈕完成設定。完成啟動vSAN檔案服務的動作後，便能夠在File Service區塊中看到剛才組態設定的內容，如圖4所示。
圖4 順利啟動vSAN檔案服務。
事實上，系統在啟動vSAN檔案服務的同一時間，也會自動在vSAN叢集環境中為每一台vSAN叢集節點主機建立「檔案服務虛擬主機」（File Service VM，FSVM），名稱通常為vSAN File Service Node (1)，然後數字依序遞增。原則上，每個vSAN檔案服務虛擬主機，最多支援50個檔案共用，整個vSAN叢集最多支援500個檔案共用。
vSAN檔案服務健康狀態
雖然vSAN檔案服務已經順利啟動，但是在開始組態設定SMB/NFS檔案共用機制之前，建議先確認vSAN檔案服務的健康狀態，避免稍後進行組態設定時出現非預期的錯誤。
在vCenter管理介面中，依序點選「Cluster > Monitor > vSAN > Skyline Health > ALL」，並點選右邊過濾圖示，接著在彈出的選項框中勾選「File Service」項目，便能夠在眾多vSAN系統服務中過濾並顯示vSAN檔案服務的健康情況，如圖5所示，幫助管理人員一目了然三大vSAN檔案服務康健情況。
圖5 組態設定檔案共用前先確認vSAN檔案服務健康情況。
當然，個別的vSAN檔案服務還能夠再深入查看細項健康情況，舉例來說，當點選「File Server Health」項目中旁邊的三個小點，並在提示視窗中點選「View Current Result」項目，就可以查看每台vSAN叢集節點主機的檔案服務健康情況。
建立NFS檔案共用
在為vSAN檔案服務建立NFS檔案共用機制時，除了考量執行效能和網路架構之外，檔案共用名稱、檔案、資料夾的字元支援，也將是影響屆時使用者能否順利存取的重要因素。舉例來說，使用者帳號寬鬆是可以使用中文，但NFS檔案共用名稱就必須採用英文才行，而檔案和資料夾名稱，則必須依照NFS版本才能決定是否支援UTF-8。
這些規劃要點雖然看似細微，但卻是跨平台整合時最容易踩到的陷阱，倘若能夠在規劃階段就清楚掌握，便能大幅降低日後的故障排除成本，為企業組織及管理人員減少不必要的麻煩。下列為組態設定NFS檔案共用需要注意的事項：
‧支援非ASCII字元：使用者帳號可以包含非ASCII字元，並且仍然能夠正常存取NFS共用資料，這對於需要使用中文帳號的企業組織運作環境相對友善，避免必須強制轉換成英文帳號。
‧檔案共用名稱限制：NFS檔案共用名稱只能採用英文字元，這在跨平台或跨系統進行檔案存取時，才能避免因字元編碼差異而導致存取錯誤的情況發生。
‧純NFSv4字元支援：建立純NFSv4通訊協定的檔案共用機制時，檔案和資料夾名稱支援使用「UTF-8相容字元」，也就是支援多國語言字元，適合需要跨語系環境的企業和組織，例如檔案名稱同時有中文與日文的情況。
‧NFSv3與NFSv4混合：當建立的NFS檔案共用，採用舊版的NFSv3或混合型的NFSv3+NFSv4通訊協定時，那麼檔案與資料夾名稱只能使用「ASCII相容字元」，這表示名稱必須使用英文或數字，否則可能出現無法存取或顯示錯誤的情況。
另外，在vCenter管理介面中，依序點選「Cluster > Configure > vSAN > File Shares > ADD」，在彈出的Create File Share視窗中，在1. General頁面內，依據實際需求填入下列欄位，如圖6所示：
圖6 組態設定NFS檔案共用及儲存空間限制門檻值。
‧Name：屆時SMB/NFS檔案共用的顯示名稱，本文實作環境名稱為NFS-Share。
‧Protocol：檔案共用的通訊協定，在下拉式選單中將出現SMB或NFS選項以供選擇。
‧Versions：採用的通訊協定版本，在下拉式選單中支援採用NFS 3、NFS 4.1、NFS 4.1 and NFS 3選項以供選擇。
‧Storage policy：採用的vSAN儲存原則，選擇適合運作環境的vSAN儲存原則。
‧Storage space quotas：是否啟用空間限制原則，預設採用儲存單位為GB，也支援使用MB和TB為儲存單位，管理人員選擇是否啟用限制原則，其中Share warning threshold門檻值到達時，系統只會顯示警告，然而當使用空間到達Share hard quota限制門檻值時便強制中止寫入資料。
在2. Net access control頁面中，可以組態設定只有指定的IP網段才能存取這個NFS檔案共用，並且設定權限為Readonly或Read/Write，也可以用IP網段搭配No access權限來建立黑名稱機制，讓某個IP網段無法存取之外，其餘網段都可以存取。本文實作環境為了簡單起見，選擇「Allow access from any IP」項目，允許任何IP網段都能夠存取此NFS檔案共用，如圖7所示。
圖7 組態設定NFS檔案共用網路安全性設定。
在3. Review頁面中，再次確認組態設定內容無誤後，按下〔Finish〕鈕完成檔案共用設定。預設情況下，組態設定後的檔案共用，並不會顯示所有的欄位資訊。舉例來說，剛才組態設定的儲存空間門檻值便不會顯示，可以在點選下方的〔Show Or Hide Columns〕鈕，勾選要顯示的欄位即可，如圖8所示。
圖8 建立NFS檔案共用並顯示指定欄位。
掛載NFS檔案共用
完成NFS檔案共用後，便可使用Linux主機進行掛載的動作。值得注意的是，本文實作環境採用NFS混合通訊協定，以便相容於舊版的Linux主機，若採用最新版純NFSv 4.1版本通訊協定時，那麼便需要注意Linux主機端的作業系統和核心版本。例如，RHEL 7.3、CentOS 7.3-1611版本和後續版本，Kernel版本必須為3.10.0-514或後續版本，才開始支援NFS v.41版本。若是Debian系統的Linux主機，則Kernel版本必須為4.0.0或後續版本，才能支援NFS v.41版本。
在切換至Linux操作畫面之前，可以利用系統內建複製NFS路徑的方式，讓掛載NFS檔案共用的動作更簡單。只要先勾選NFS檔案共用項目，再點選Copy Path並選擇適用於NFSv3或NFSv4.1版本的路徑，系統便會顯示NFS檔案共用的路徑，如圖9所示。
圖9 快速複製NFS檔案共用路徑。
切換到Linux主機後，執行「sudo mount」指令搭配NFS檔案共用路徑和本機掛載點，例如「sudo mount vsan-05b.fs.lab.weithenn.org:/vsanfs/NFS-Share /mnt/nfsshare」。掛載完成後，執行「sudo mount | grep /mnt/nfsshare」指令，檢查Linux主機的掛載系統是否已經存在NFS檔案共用路徑，如圖10所示。
圖10 Linux主機掛載NFS檔案共用儲存資源至本機路徑。
測試NFS檔案共用Quota機制
現在可以開始測試Linux主機是否能夠讀寫檔案至NFS檔案共用路徑中。切換至「/mnt/nfsshare」本機掛載點路徑，執行「dd if=/dev/zero of=testfile bs=1G count=7」指令，寫入一個檔案名稱為「testfile」、大小為7GB的測試檔案，然後執行「ll -h」指令確認檔案是否建立成功，如圖11所示。
圖11 建立檔案名稱為testfile大小為7GB的測試檔案。
切換回vCenter管理介面之後便可以發現，由於儲存空間告警門檻值在前面的組態設定中為5GB，所以系統已經將此NFS檔案共用的狀態變更為橘色警告狀態，但此時仍然可以正常讀取和寫入資料至NFS檔案共用之中，如圖12所示。
圖12 寫入NFS檔案共用空間已達告警門檻值。
同樣地，切換至Linux主機後，使用同樣的指令再次建立測試檔案，只是這次檔案名稱為「testfile2」、大小為5GB。執行「dd if=/dev/zero of=testfile2 bs=1G count=5」指令後，可以看到當系統寫入的測試檔案占用空間達到3GB時，系統回報無法再寫入testfile2檔案，錯誤原因是「Disk quota exceeded」，也就是已經達到NFS檔案共用設定的Hard Quota門檻值，所以無法再寫入任何檔案，如圖13所示。值得注意的是，雖然無法再寫入任何檔案，但此時仍然可以讀取NFS檔案共用內的檔案和資料夾。
圖13 已達Hard Quota門檻值，Linux主機無法再寫入檔案。
切換回vCenter管理介面後，可以看到Linux主機寫入檔案所占用的儲存空間，已經達到先前組態設定中Hard Quota為10GB門檻值，所以系統已經將此NFS檔案共用的狀態變更為紅色緊急狀態，如圖14所示。
圖14 檔案占用空間達到Hard Quota門檻值無法再寫入檔案。
當然，在企業組織的營運環境中，管理人員不可能時時去查看每個NFS檔案共用的使用者情況，所以預設情況下，vSAN Skyline Health健康檢查機制每隔一段時間便會檢查使用情況。現在，可以立即觸發檢查作業進行驗證，在vCenter管理介面中，依序點選「Cluster > Monitor > vSAN > Skyline Health > RETEST」，讓系統立即執行系統健康情況檢查工作程序。檢查完成之後，再次查看vSAN檔案共用三大系統服務時，便會發現其中的「Share Health」服務，狀態由先前的Healthy變更為Yellow (Warning)狀態，並且說明理由是儲存空間已經達到Quota門檻值，如圖15所示。
圖15 vSAN Skyline Health健康檢查機制發現NFS檔案共用服務為警告狀態。
當然，此時只要切換回Linux主機中，將其中一個測試檔案，例如第1個測試檔案testfile刪除，然後再次執行vSAN Skyline Health健康檢查程序。
由於已經釋放出7GB的儲存空間，所以該NFS檔案共用占用的儲存空間，便回到運作良好的green健康狀態，如圖16所示。
圖16 刪除不必要的檔案釋放儲存空間後回到運作良好的健康狀態。
查看NFS執行效能
除了查看NFS檔案共用的使用空間之外，隨著企業的專案日漸增多，組態設定的NFS檔案共用項目也會相對增加，當需要針對個別NFS檔案共用效能進行觀察和排除效能疑慮的時候，便可以透過查看NFS檔案共用執行效能，例如IOPS、Throughput、Latency等等達成。
在vCenter管理介面中，依序點選「Cluster > Monitor > vSAN > Performance > File Share」，在File Share下拉式選單中選擇要觀察執行效能的NFS檔案共用名稱，例如NFS-Share，即可看到各項執行效能資料，預設情況下為顯示最近1小時的效能資訊，也可以視需求調整觀察的時間區段，如圖17所示。
圖17 觀察指定NFS檔案共用路徑的執行效能。
查看NFS整體占用空間
雖然在NFS檔案共用組態設定頁面中，可以看到個別的儲存空間占用資訊，然而依照目前每個vSAN叢集最大支援500個NFS檔案共用項目來看，若想要知道整體NFS檔案共用機制總共占用vSAN叢集多少儲存空間，除了一筆一筆計算之外，有沒有更好的方法？
在vCenter管理介面中，先依序點選「Cluster > Monitor > vSAN > Capacity」，在Usage breakdown after space efficiency savings區塊中分別有User data和System usage等兩大分類。展開User data分類後，即可看到File shares下的vSAN file shares項目，這裡所顯示的儲存空間占用資訊，便是vSAN檔案服務在vSAN叢集中整體占用的儲存空間，如圖18所示。
圖18 查看vSAN檔案服務在vSAN叢集中整體占用的儲存空間。
＜本文作者：王偉任，Microsoft MVP及VMware vExpert。早期主要研究Linux/FreeBSD各項整合應用，目前則專注於Microsoft及VMware虛擬化技術及混合雲運作架構，部落格weithenn.org。＞