網管人雜誌

本文刊載於網管人雜誌第 243 期 - 2026 年 4 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。

本文目錄

前言

實戰 – VCF 9 vSAN 檔案服務

啟用 vSAN 檔案服務

vSAN 檔案服務健康狀態

建立 NFS 檔案共用

掛載 NFS 檔案共用

測試 NFS 檔案共用 Quota 機制

查看 NFS 執行效能

查看 NFS 整體佔用空間

結語

前言

在過去，倘若要達成跨站台高可用性時，企業和組織往往需要依賴，傳統的 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

實戰 – VCF 9 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」項目中，旁邊的 3 個小點，在提示視窗中點選「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 所示）：

Name：屆時 SMB/NFS 檔案共用的顯示名稱，本文實作環境名稱為 NFS-Share。
Protocol：檔案共用的通訊協定，在下拉式選單中將會出現 SMB 或 NFS 選項供管理人員選擇。
Versions：採用的通訊協定版本，在下拉式選單中支援採用 NFS 3、NFS 4.1、NFS 4.1 and NFS3 選項供管理人員選擇。
Storage policy：採用的 vSAN 儲存原則，管理人員選擇適合運作環境的 vSAN 儲存原則。
Storage space quotas：是否啟用空間限制原則，預設採用儲存單位為 GB，也支援使用 MB 和 TB 為儲存單位，管理人員選擇是否啟用限制原則，其中 Share warning threshold 門檻值到達時，系統只會顯示警告，然而一旦使用空間到達 Share hard quota 限制門檻值時，便會強制中止寫入資料。

圖 6、組態設定 NFS 檔案共用及儲存空間限制門檻值

在 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」指令，寫入 1 個檔案名稱為 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 檔案共用 3 大系統服務時，便會發現其中「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 所示）。