網管人雜誌
本文刊載於 網管人雜誌第 174 期 - 2020 年 7 月 1 日出刊，NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它，或透過城邦出版人讀者服務網進行訂閱。本文目錄
前言vSAN 7 亮眼特色功能
PowerCLI 12 支援 vSAN 7
原生檔案服務
雲端原生儲存整合 vSphere with Kubernetes
增強 vSAN 儲存資源報表
實戰 vSAN 7 原生檔案服務
啟用 vSAN 原生檔案服務
建立 NFS 檔案共享機制
掛載檔案共享儲存資源
限制檔案共享儲存空間
vSAN 檔案服務容錯移轉
結語
前言
在 2020 年 4 月 2 日時，由 VMware 官方宣佈 vSAN 7 正式發行。事實上，在 VMware 的 SDDC 軟體定義資料中心的願景中，擔任 SDC 軟體定義運算角色的部份，為管理人員所熟悉的 vSphere 虛擬化解決方案，擔任 SDN 軟體定義網路角色的則是 NSX 網路虛擬化解決方案，至於 SDS 軟體定義儲存角色則是本文即將深入剖析和實戰演練的 vSAN 超融合解決方案。過去，企業或組織希望打造 SDDC 軟體定義資料中心時，可能必須分別導入上述的 SDC/SDN/SDS 三種軟體定義技術。現在，透過 VCF（VMware Cloud Foundation）便能一次掌握這三大關鍵的軟體定義技術，同時搭配 SDDC Manager 之後，除了打造企業內部 SDDC 軟體定義資料中心架構之外，甚至能夠串接公有雲和私有雲環境，達成更具彈性的混合雲運作環境（如圖 1 所示）。
圖 1、VCF（VMware Cloud Foundation）運作架構示意圖
vSAN 7 亮眼特色功能
全新打造的 vSAN 7 不僅是 VCF 運作架構中的儲存資源基石，並且因應商業數位化和新興容器技術的需求，新版的 vSAN 7 不僅能夠原生提供 NFS 檔案共享服務，同時更增強和擴大雲端原生儲存資源的支援度。舉例來說，過去 vSAN 運作環境所建立的 VMFS 儲存資源，僅支援運作 VM 虛擬主機使用，至於企業和組織在 Linux 容器環境中經常使用的 NFS 檔案共享服務，則必須依賴其它外部硬體儲存設備來提供。現在，新版 vSAN 7 直接原生支援 NFS 檔案共享服務（如圖 2 所示），減少企業和組織需要額外採購外部儲存設備之外，這個 NFS 檔案共享服務也同時支援 Kubernetes 建立「永續性磁碟區」（Persistent Volumes，PV），讓企業和組織同時解決傳統 NFS 檔案共享服務，以及容器技術所需儲存資料的永續性磁碟區。
vSAN 7 原生檔案服務，支援 NFSv3 和 v4.1 版本檔案共享機制。
圖 2、新版 vSAN 7 直接原生支援 NFS 檔案共享服務
PowerCLI 12 支援 vSAN 7
熟悉 Windows PowerShell 的管理人員，對於 VMware PowerCLI 應該不陌生，簡單來說 PowerCLI 便是以 PowerShell 為底層基礎的指令工具，PowerCLI 提供一系列的 Cmdlet 指令和相關模組，幫助管理人員維運 vSphere 和 vSAN 運作環境，舉例來說，管理人員需要建立 100 台虛擬主機時，雖然可以透過 vSphere HTML 5 Client 圖形化管理工具達成，但是必須花費大量時間並且有可能發生人為操作失誤的情況，此時透過 PowerCLI 便可以輕鬆且快速的達成工作任務。現在，最新版本的 PowerCLI 12 新增許多 Cmdlet，協助管理人員組態設定和管理 vSAN 7 新增的原生檔案服務，舉例來說，管理人員透過 Cmdlet 組態設定 vSAN 7 檔案服務後，可以透過「Get-VsanFileShare」這個 Cmdlet 指令，查詢 vSAN 7 原生檔案服務的相關資訊（如圖 3 所示）。
有關 PowerCLI Cmdlet 的詳細用途和指令語法，請參考 VMware PowerCLI Cmdlets Reference。
圖 3、查詢 vSAN 7 原生檔案服務的相關資訊
原生檔案服務
在新版 vSAN 7 運作環境中，已經正式支援「原生檔案服務」（Native File Services），以便快速提供 NFS 檔案共享服務，因此企業和組織無須再額外採購外部儲存設備來提供 NFS 檔案共享服務。那麼，我們來看看在 vSAN 運作架構中，如何建構和提供原生檔案服務。首先，在 vSAN 運作架構中，必須具備「3 ~ 8」台 vSAN 節點伺服器才能建構原生檔案服務，並且每台節點伺服器都必須具備唯一的 IP 位址，以及 DNS 正向和反向解析紀錄。值得注意的是，在 vSAN 叢集中必須準備「檔案服務網域」（File Services Domain），這是屆時提供 NFS 檔案共享服務時使用的唯一名稱空間。
建構的 NFS 檔案共享服務，支援「Layer 2」和「Layer 3」（Routing）環境。
事實上，當 vSAN 叢集啟用原生檔案服務特色功能時，系統將會在 vSAN 叢集中建立「VMware 分佈式檔案系統」（VMware Distributed File System，VDFS），這個檔案系統的主要目的在於管理用途（如圖 4 所示）。此外，在 vSAN 叢集中的每台 vSAN 節點主機，將會運作一台「檔案服務虛擬主機」（File Service VM，FSVM），每台檔案服務虛擬主機都會提供 NFS 檔案共享服務，而 NFS 檔案共享服務的原始儲存資源，則是採用 vSAN Datastore 儲存資源，以便保持儲存資源的資料保存可用性。
圖 4、vSAN 原生檔案服務運作架構示意圖
雲端原生儲存整合 vSphere with Kubernetes
在全新的 vSphere 7 和 VCF（VMware Cloud Foundation）運作架構中，已經整合新興應用的容器技術管理平面 Kubernetes，管理人員可以選擇採用 TKG（Tanzu Kubernetes Grid）或 vSphere with Kubernetes，部署 K8s 叢集並且運作和管理各式各樣的容器。基本上，無論管理人員選擇採用 TKG 或 vSphere with Kubernetes，都可以透過 Pod Service CSI 或 TKG Service CSI 驅動程序，存取座落於底層的 vSAN 儲存資源和原生檔案服務（如圖 5 所示）。
圖 5、雲端原生儲存資源整合 TKG 和 vSphere with Kubernetes 運作架構示意圖
增強 vSAN 儲存資源報表
由於新版的 vSAN 7 超融合解決方案，已經不像舊版著重於 VM 虛擬主機的工作負載，更支援新興的容器技術應用。同時，增強 vSAN 儲存資源報表功能和呈現方式，方便管理人員了解 vSAN 叢集的各項工作負載和資源耗用情況，以便管理人員判斷是否該為 vSAN 叢集中每台 vSAN 節點主機，擴充運算和儲存資源達成「垂直擴展」（Scale-Up），或者是為 vSAN 叢集增加更多台 vSAN 節點主機，達成「水平擴展」（Scale-Out）的運作架構。在 VM 虛擬主機的部份，當管理人員點選 VM 虛擬主機的 Summary 頁籤後，可以發現有「Switch to New View」鈕，按下後可以發現新版更精簡清淅的 VM 虛擬主機工作負載和資源使用情況，例如，管理人員最在意的動態記憶體和儲存資源使用率（如圖 6 所示）。
圖 6、新版 VM 虛擬主機工作負載和資源使用率示意圖
此外，當 vSAN 叢集啟用原生檔案服務，那麼在 vSAN 容量使用報表中，依序展開「vSAN > Capacity > Usage breakdown before dedup and compression > User Objects > File shares」項目後，即可查看 vSAN 原生檔案服務儲存資源使用率（如圖 7 所示）。
圖 7、即可查看 vSAN 原生檔案服務儲存資源使用率
實戰 vSAN 7 原生檔案服務
如上所述，新版 vSAN 7 已經可以透過啟用原生檔案服務，讓 vSAN 7 叢集能夠提供 NFS v3 和 v4.1 檔案共享機制，並且這個 NFS 檔案共享機制不僅可以分享給 VM 虛擬主機使用，也能因應新興容器技術的使用，同時企業和組織無須額外採購儲存設備，便能輕鬆將 NFS 檔案共享的資料，儲存在高效能和高可用性的 vSAN Datastore 儲存資源內（如圖 8 所示）。
圖 8、vSAN 原生檔案服務運作架構示意圖
舉例來說，新興應用微服務架構上「雲端原生」（Cloud Native）類型的工作負載，例如，Apache、Nginx、Tomcat 等網頁應用伺服器使用儲存資源的特性，便是透過 NFS v4.1 協定存取儲存資源，以便達到分佈式應用程序的運作架構。
在開始實戰演練 vSAN 原生檔案服務之前，我們先了解相關前置作業以及運作環境需求，以便稍後能夠順利啟用 vSAN 原生檔案服務：
- 在 vSAN 叢集中的每台 vSAN 節點主機，必須具備唯一 IP 位址，倘若需要 Layer 3 路由轉送的話，則必須組態設定預設閘道和路由機制。
- 在 vSAN 原生檔案服務運作環境中，必須具備 DNS 名稱解析伺服器，以便處理 DNS 正向和反向名稱解析服務。
- 在啟用 vSAN 原生檔案服務時，必須組態設定「檔案服務網域」（File Services Domain），這在 vSAN 叢集中必須具備唯一性的「命名空間」（Namespace）。
啟用 vSAN 原生檔案服務
在本文實作環境中，vSAN 叢集內共有 3 台 vSAN 節點主機，已經在 vSphere 叢集中啟用 vSAN 特色功能，將 3 台 vSAN 節點主機的本機儲存裝置匯整為 vSAN Datastore 儲存資源，並且完成組態設定 vDS 分佈式虛擬交換器，以利 3 台 vSAN 節點主機之間 vSAN Traffic 儲存流量交換。確認 vSAN 叢集為正常運作狀態後，依序點選「vSAN Cluster > Configure > vSAN > Services > File Service > Enable」項目，系統便會彈出組態設定原生檔案服務精靈對話視窗（如圖 9 所示）。
在組態設定 vSAN 檔案服務畫面中可以看到，系統提醒管理人員在繼續下一個操作步驟之前，應先確認是否已經準備好相關資訊，例如，固定 IP 位址、DNS 名稱……等。
圖 9、準備啟用並組態設定 vSAN 檔案服務
由於，啟用 vSAN 檔案服務之後，系統將會在 vSAN 叢集中透過 vSphere ESX Agent Manager，為每一台 vSAN 節點主機安裝「檔案服務代理程式」（File Service Agent），這個檔案服務代理程式為採用 Photon OS 的輕量型「虛擬設備」（Virtual Appliance，VA）運作架構，並已經啟用 NFS 伺服器服務，以便提供 NFS 檔案共享服務。
因此，在 File Service Agent 頁面中，我們可以選擇採用預設值「Automatic Approach」（如圖 10 所示），並且勾選「Trust the certificate」選項。讓 vCenter Server 自動前往 VMware 官方網站下載，最新穩定版本的檔案服務代理程式，並安裝至 vSAN 叢集中每一台 vSAN 節點主機。倘若，vCenter Server 無法接觸網際網路，則請改為選擇「Manual Approach」項目，以手動的方式上傳檔案服務代理程式。
採用自動下載檔案服務代理程式選項時，當管理人員按下 Next 鈕後，vCenter Server 便會立即至 VMware 官網下載檔案服務代理程式，並在下方 Task Panel 顯示下載進度，工作進度名稱為「Download vSAN File Service OVF」。
圖 10、採用預設值自動下載最新穩定版本的檔案服務代理程式
在 Domain 頁面中，管理人員必須提供 vSAN 檔案服務的網域資訊，在本文實作環境中檔案服務網域名稱為「vsan-nfs」，而 DNS 伺服器的 IP 位址為「10.10.75.60」，DNS 尾碼則是「weithenn.org」（如圖 11 所示）。
在 vSAN 7 版本中，目前僅支援採用「AUTH_SYS」的 NFS 檔案共享服務身份驗證機制。
圖 11、組態設定 vSAN 檔案服務的網域資訊
在 Networking 頁面中，管理人員必須選擇屆時部署檔案服務代理程式，所要使用的 NFS 檔案共享網路環境 Port Group，點選 Network 下拉式選單，選擇本文實作環境採用的「NFS Network」，並鍵入使用的子網路遮罩「255.255.255.0」，以及預設閘道「10.10.75.254」（如圖 12 所示）。
圖 12、組態設定檔案服務代理程式使用的 NFS 檔案共享網路環境 Port Group
在 IP Pool 頁面中，鍵入檔案服務代理程式所要使用的 IP 位址資源池，根據 VMware 的最佳建議作法，便是為 vSAN 叢集中的每台 vSAN 節點主機，額外配置專用於 NFS 檔案共享服務的 IP 位址資源池，並且建議採用連續的 IP 位址。在本文實作環境中，鍵入第一筆 IP 位址「10.10.75.71」後，按下「Lookup DNS」確保能夠正確進行 DNS 名稱解析，然後按下「AutoFill」則會依序遞增 IP 位址，並再次按下「Lookup DNS」確保新加入的 IP 位址能夠正確進行 DNS 名稱解析（如圖 13 所示）。
選項中「Primary」的 IP 位址，主要用於 NFS v4.1 檔案共享存取用途，並且在後端透過 NFSv4 轉介機制，重新導向至不同台 vSAN 節點主機的檔案服務代理程式。
圖 13、組態設定檔案服務代理程式所要使用的 IP 位址資源池
在 Review 頁面中，再次檢視所有組態設定內容是否正確無誤，確認無誤後按下 Finish 鈕，便立即進行檔案服務代理程式的部署作業。當部署的工作任務完成後，可以看到在 vSAN 叢集中每台 vSAN 節點主機上，皆會運作一台名稱為「vSAN File Service Node」的虛擬主機（如圖 14 所示），採用的客體作業系統為「VMware Photon OS」，並由「vSphere ESX Agent Manager」所管理。
首先，系統會部署至 Primary 的 vSAN 節點主機，接著建立快照後再複製至其它台 vSAN 節點主機上。
圖 14、檔案服務代理程式部署完畢
建立 NFS 檔案共享機制
順利組態設定和啟用 vSAN 檔案服務後，在 vSphere HTML 5 Client 管理介面中，「vSAN Cluster > Configure > vSAN」的選項中，將會多出「File Service Shares」子項目，請按下「Add」準備新增 NFS 檔案共享機制。在本文實作環境中，NFS 檔案共享網路名稱為「nfs-share」，採用的 vSAN 儲存原則為預設的「vSAN Default Storage Policy」，在 NFS 檔案共享儲存空間限制中，觸發儲存空間警告的臨介值為「7 GB」，而最大儲存空間則為「10 GB」（如圖 15 所示）。
圖 15、組態設定 NFS 檔案共享網路名稱和儲存空間警告及限制
在 Net Access Control 頁面中，組態設定能夠存取 NFS 檔案共享的網段和權限，本文實作環境允許「10.10.75.0/24」網路環境的主機，皆能夠存取 NFS 檔案共享儲存空間，並且具備「讀取 / 寫入」（Read/Write）的權限（如圖 16 所示）。
NFS 檔案共享權限支援三種方式，分別是「禁止存取」（No Access）、「僅能讀取」（ReadOnly）、「讀取 / 寫入」（Read/Write）。
圖 16、組態設定存取 NFS 檔案共享的網段和權限
在 Review 頁面中，再次檢視所有組態設定內容是否正確無誤，確認無誤後按下 Finish 鈕，便立即進行建立 NFS 檔案共享的工作任務。當 NFS 檔案共享機制建立完成後，便能看見建立的 NFS 檔案共享儲存資源，後續管理人員也可以依照專案需求，隨時調整套用的 vSAN 儲存原則，以及儲存空間警告和儲存空間限制臨界值（如圖 17 所示）。
圖 17、NFS 檔案共享機制建立完成
掛載檔案共享儲存資源
雖然，vSAN 檔案服務同時支援 NFS v3 和 v4.1 機制，然而當管理人員在 Linux 主機端，透過「showmount」指令查詢 NFS 檔案共享資源時，將會發現僅查詢 Primary IP「10.10.75.71」時，才得獲得 NFS 檔案共享資源（如圖 18 所示）。
圖 18、查詢 vSAN 檔案服務建立的 NFS 檔案共享儲存資源
那麼，從 Linux 主機端該如何掛載 NFS v3 和 v4.1 檔案共享儲存資源？ 管理人員可以從 vSphere HTML 5 Client 管理介面中，點選本文實作的 NFS 檔案共享資源項目後，按下「Copy URL」選擇 NFSv3 或 NFSv4.1 項目，便會顯示 NFS 檔案共享資源掛載路徑（如圖 19 所示）。
此時，系統已經將 NFS 檔案共享掛載路徑複製至主機的剪貼簿中。
圖 19、顯示 NFS 檔案共享資源掛載路徑
此時，便可以切換至 Linux 主機端，採用「mount」指令搭配剛才複製的 NFS 檔案共享資源掛載路徑「10.10.75.71:/vsanfs/nfs-share」，以及 Linux 主機端的掛載點「/mnt/nfs-share」。當 NFS 檔案共享資源掛載工作任務執行完成後，執行「mount | egrep "nfs-share|4.1"」指令，確認成功掛載 NFS 檔案共享儲存資源並採用 NFS v4.1 版本（如圖 20 所示）。
圖 20、掛載 NFS 檔案共享儲存資源並確認採用的 NFS 版本
限制檔案共享儲存空間
接著，我們測試先前組態設定的 NFS 檔案共享儲存空間警告和限制機制，在本文實作環境中觸發儲存空間警告的臨介值為「7 GB」，而最大儲存空間則為「10 GB」。我們可以在 Linux 主機端，透過「dd if=/dev/zero of=/mnt/nfs-share/8gb.txt bs=1G count=8」指令，建立一個佔用空間大小為「8 GB」的測試檔案（如圖 21 所示）。
圖 21、透過 dd 指令建立 8 GB 空間大小的測試檔案
此時，切換至 vSphere HTML 5 Client 管理介面，可以看到 NFS 檔案共享使用空間已達組態設定的「80 %」（如圖 22 所示）。
圖 22、查看 NFS 檔案共享儲存空間警告和限制資訊
由於，仍然未達到 NFS 檔案共享最大儲存空間限制 10 GB，所以 Linux 主機端仍然能夠寫入檔案，然而當我們寫入資料達到最大儲存空間限制 10 GB 時，嘗試再寫入資料時便會出現「Disk quota exceeded」的錯誤訊息（如圖 23 所示），無法再繼續寫入任何資料。
圖 23、寫入資料達到最大儲存空間限制 10 GB 時便無法再繼續寫入任何資料
此時，切換至 vSphere HTML 5 Client 管理介面，依序點選「vSAN Cluster > Monitor > vSAN > Skyline Health」項目，可以看到「File Service > Share health」子項目出現紅色錯誤訊息，原因便是 NFS 檔案共享儲存資源超過限制大小（如圖 24 所示）。
管理人員可以擴充 NFS 檔案共享儲存資源限制大小，或刪除 NFS 檔案共享儲存資源中不必要的檔案，那麼 Skyline Health 健康偵測機制便會恢復正常。
圖 24、透過 Skyline Health 健康偵測機制，查看 NFS 檔案共享儲存資源健康情況
vSAN 檔案服務容錯移轉
由於，NFS 檔案共享儲存資源為運作在 vSAN 叢集之上的應用服務，所以就像在 vSAN Datastore 當中受保護的 VM 虛擬主機一樣，除了享有 vSAN 高效能之外也同樣具備高可用性。首先，請於 vSphere HTML 5 Client 管理介面中，依序點選「vSAN Cluster > Monitor > vSAN > Virtual Objects > Affected inventory objects > File Shares」，接著點選本文實作的 NFS 檔案共享儲存資源「nfs-share」，然後按下「View Placement Details」，即可看到 NFS 檔案共享儲存資源物件，分佈在 vSAN 叢集中的所有 vSAN 節點主機（如圖 25 所示）。
圖 25、查看 NFS 檔案共享儲存資源物件分佈情況
在本文實作環境中，建立的「nfs-share」NFS 檔案共享儲存資源，系統指派由「vsan-n02.weithenn.org」vSAN 節點主機負責，我們將此台 vSAN 節點主機直接斷電以便模擬故障損害的情況，測試 NFS 檔案共享儲存資源的高可用性。
當「vsan-n02.weithenn.org」vSAN 節點主機斷電後，再次查看 NFS 檔案共享儲存資源物件分佈情況，可以發現原本由「vsan-n02.weithenn.org」vSAN 節點主機儲存的物件，狀態由先前健康良好的「Active」轉變為「Absent」（如圖 26 所示）。
圖 26、原本由 vsan-n02.weithenn.org 節點主機負責儲存的物件狀態轉變為 Absent
此外，我們切換到「nfs-share」NFS 檔案共享儲存資源頁面，可以看到原本由「vsan-n02.weithenn.org」vSAN 節點主機負責 NFS 檔案共享服務，因為發生斷電的故障損壞情況後，系統改為指派由「vsan-n01.weithenn.org」vSAN 節點主機，接手負責 NFS 檔案共享服務（如圖 27 所示）。
圖 27、由 vSAN 節點主機 vsan-n01.weithenn.org 接手 NFS 檔案共享服務
