一、vSAN 中的 DiskGroup 架構的問題與應對思路回顧
如何将分散在多個伺服器中的本地盤資源整合成叢集範圍可用的“共享存儲資源池”，是超融合架構中的一項關鍵技術。在 vSAN 中，這項技術是通過“盤組（DiskGroup）”來實作的。
1.vSAN DiskGroup 架構簡介
盤組内部采用兩級存儲架構：一層用于資料的臨時緩存 / 緩沖，被稱為“緩存層（Cache Tier）”，每個盤組内的緩存必須有且僅有 1 個采用閃存的高速儲存設備，通常為固态硬碟 SSD；另一層用于最終存儲資料，被稱為“容量層（Capacity Tier）”，由 1~7 個固态硬碟或普通磁媒體硬碟 HDD 組成。vSAN 允許每個主機使用 1~5 個這樣的磁盤組。如圖 1 所示的例子中，vSAN 超融合叢集的每個主機節點内僅有 1 個盤組，該盤組由 1 塊 SSD 緩存盤和 3 塊 HDD 容量盤組成。
圖 1 vSAN 超融合叢集及主機内的盤組結構
由兩級不同的儲存設備構成的盤組結構，最主要的目的是将經常使用的“熱資料”存放在高速 SSD 中，減少對低速 HDD 的直接通路，進而提升整個盤組的平均讀 / 寫速度。在 10 年之前，SSD 價格還很高的時代，通過使用相對小容量的緩存盤作為”杠杆“，在設定的盤組範圍内達到存儲性能提升的效果，是一種很好的技術思路。這種思路也在被 VMware 以外的其他超融合廠商使用，如深信服。
2.vSAN 盤組技術在實作中的限制
vSAN 的兩級存儲架構在産品化過程中存在一些要求和限制：
-
高速緩存盤的容量至少為盤組中所有低速盤總容量的 10%。
· 如圖 1 所示，每個盤組的容量層總和為 12TB，那麼理論上，緩存層至少為 1.2TB；
· 如果低于這個比例，可能達不到理想的緩存提速效果——通俗說，就是“緩存盤太小，帶不動容量盤”；
· 而 vSAN 還有一個技術限制：全閃配置下每個緩存盤上，隻有 600GB 空間可以被真正用于對寫資料進行緩沖。
- 每個盤組中隻能有 1 塊緩存盤，無法突破每盤組 600GB 可用緩沖空間的限制。
-
盤組中唯一的緩存盤存在單點故障的可能，如果它損壞了：
· 該盤組将從叢集資源池中退出。
· 該盤組内所有容量盤上的資料無法讀取。
· 損失的資料（數 TB ~ 數十 TB）有可能通過儲存在其他節點上的資料進行恢複，但背景的資料恢複過程中（幾小時 ~ 幾十小時），叢集存儲性能不可避免地會出現一定程度的下降。
3.vSAN 部署方案中應對盤組技術限制的思路
以上技術實作中的限制在 vSAN 7 及以前的版本中一直存在。為了降低這些限制對 vSAN 叢集部署的影響，VMware 的 vSAN 部署方案設計中給出的應對思路是：增加叢集中每台主機上的盤組數量（如圖 2 所示）。
圖 2 vSAN 叢集實施方案設計
vSAN 叢集的單台主機上，最多可以允許設定 5 個盤組。是以，可以通過增加主機内部的盤組數量方法，一定程度上減輕單個緩存盤故障的影響範圍，也就是“把雞蛋放到多個籃子裡”。VMware 經過測試，給出的最佳盤組設計方案是：每台主機内設定 2~3 個盤組，每個盤組内設定 3~5 個容量盤。這種設計與 vSAN 存儲政策中的條帶化數量設定相結合，可以把原本由單塊存儲盤承擔的讀 / 寫工作，盡可能地分散到多個主機、多個盤組的多個 SSD 上來完成，實作了叢集級别存儲性能的最優化。
4.“最優設計方案”面臨的困境
VMware 提供的最優設計解決方案卻很難落實到實際項目中，主要因為這個設計思路會導緻：
- 硬體成本提高：緩存層 SSD 和容量層 HDD 單盤容量減小，但數量都要增加，有可能還要增加 RAID 卡的數量——以圖 2 的配置舉例，由 1 塊 SSD + 3 塊 HDD，增加為 3 塊 SSD + 6 塊 HDD，1 塊 8 口 RAID 卡也不夠用了，需要再加 1 塊或換成 16 口的。
- 記憶體消耗增加：每增加 1 個盤組要增加 ~8GB 記憶體消耗，每增加 1 個容量盤要增加 240~300MB 記憶體消耗（具體算法參見文末參考文章 1 ）。
- 維護複雜度增加：運維人員面對更複雜的結構，更多的 SSD + HDD 數量必然引入更多的故障點。
- 主機機箱内的硬碟槽位消耗增加：壓縮了今後擴容的空間。
- 更難保持 vSAN 叢集的“一緻性”：VMware 建議一個 vSAN 叢集中所有主機上的盤組數量和盤組内部組成結構都應保持一緻（盡管允許存在個别主機、個别盤組的配置不同，但差異越大，造成的整體性能下降幅度就越大），初始設計采用的盤組結構越複雜，今後在同一叢集内部擴容時，就越難以保證結構的一緻性。
由于存在以上困難，大多數使用者的部署中難以滿足理想的 vSAN 盤組設計要求，僅僅選擇以“單盤組”方式運作 vSAN。這也是為什麼很多使用者抱怨他們使用的 vSAN 叢集的性能達不到 VMware 官方釋出的标準。
5.使用者對 vSAN 盤組結構的期望
對于以上技術限制，vSAN 使用者一直以來希望 VMware 能夠對盤組的實作方式進行改善，最主要的訴求包括但不限于：
- 支援緩存盤備援，消除盤組内部的單點故障。
- 解除緩存盤上 600GB 可用空間的限制，在同主機内部使用大容量的 SSD 作為共享緩存盤，簡化主機内部的盤組結構。
- 在叢集内各主機、各盤組上，支援緩存盤和容量盤的“異構”，在擴容時可以在更大範圍内靈活地選用新型号的儲存設備。
這些改進訴求的最終目的，是降低 vSAN 叢集硬體選配的複雜度以及硬體采購和維護上的成本。
二、vSAN 8 帶來了什麼？
1.vSAN 8 ESA 簡介
2022 年 8 月底，VMware 正式釋出了 vSAN 8 這個裡程碑性質的版本。在 vSAN 8 中，引入了“快速存儲架構（Express Storage Architecture）”，這為 vSAN 使用者提供了一種可選替代架構，目标是以全新級别的效率、可擴充性和性能來處理和存儲資料。ESA 不再使用“DiskGroup 盤組”的概念，而是使用“Storage Pool 存儲池”，主機中所有符合要求的儲存設備不再被分為不同的“組”，不再被分為“緩存層”和“容量層”。
同時，vSAN 原有的基于盤組的架構仍然保留，作為可選的 vSAN 方案之一，它現在被稱為 OSA（Original Storage Architecture）。
為了簡化，本文以下部分，就用 ESA 和 OSA 來指代兩種技術架構。
2.ESA 實作了使用者對 OSA 改進的期望嗎？
先公布答案：沒有。
先來看看啟用 ESA 需要什麼樣的條件：
資料來源：Comparing the Original Storage Architecture to the vSAN 8 Express Storage Architecture
- 啟用 ESA 的叢集每台主機上，必須使用至少 4 塊高性能、耐用的 TLC NVMe 存儲盤。VMware 表示，“之是以選擇它們，是因為它們能夠提供一緻的性能、低延遲和減少存儲處理所需的 CPU”3。由于閃存技術進步了，對應的商用化産品降價了，VMware 認為，磁媒體盤不再是性能提升的瓶頸，真正需要高性能的場景，一定會用基于閃存的儲存設備。是以通過高速緩存盤對低速磁盤進行加速，不是 ESA 需要解決的主要問題，ESA 不考慮對于混合盤配置的支援。
- 不是任何主機配備了 TLC NVMe 存儲盤都可以啟用 ESA，這個主機必須是 “vSAN 就緒節點”（vSAN ReadyNodesTM：經過 VMware 驗證的、符合 vSAN 部署要求的伺服器整機産品，元件配置相對固定，使用者不可自行更改，提供多種伺服器品牌和配置組合供選擇。）。
- “各節點配置一緻”是“vSAN ReadyNodesTM”的強制要求，也就是說，沒有提供“元件異構”或“節點異構”的選項。
- 25Gbps 将是對主機網絡的最低要求。
- 需要 vSAN Advanced 或 vSAN Enterprise 許可，才能使用 ESA；vSAN Standard 許可隻能使用 OSA。
在建立新的 vSAN ESA 叢集時，預檢查流程将確定客戶使用經過準許的硬體，檢查内容包括：是否與 vLCM 配置相容、最低實體網卡速度、主機的實體記憶體和磁盤類型。
也就是說，雖然 ESA 表面上符合了前文總結的使用者對 vSAN 的前兩條期望——精簡了主機内部的儲存設備層次、消除了原有緩存盤的單點故障——但需要更高的硬體配置和軟體許可才能實作。這意味着，ESA 并沒有滿足這些使用者期望背後對于“降低成本”的訴求。對于第三條期望，ESA 則完全是背道而馳，進一步嚴格了對主機、存儲和網絡元件的選型要求，提高了使用者使用 ESA 的門檻。
3.ESA 的主要提升展現在哪裡？
看上去 ESA 給使用者帶來的收益并不美麗，那麼 VMware 為什麼要推出這個架構呢？我們可以從 VMware 已經釋出的一系列關于 vSAN 8 的材料中，得到一些 ESA 技術思路的啟示。
(1)“全閃”取代“混閃”
首先，采用高速閃存的儲存設備越來越普及，能夠負擔全閃存儲價格的使用者也越來越多，在大量需要高速讀 / 寫的應用場景中，直接通過全閃配置就可以滿足性能的要求。是以，VMware 認為使用 SSD 作為 HDD 加速杠杆的做法可以不再保留。
(2)減少資料的存儲量
但是，基于 TLC NVMe 的儲存設備價格确實比機械硬碟高，從混閃配置到 TLC NVMe 裝置，使用者需要花更多的錢。怎麼能降低這部分成本？或者說，怎麼讓使用者覺得可以省錢呢？ESA 給出的思路是：推廣并普及基于糾删碼（Erasure Coding）的資料高可用方法和資料壓縮。這兩種技術可以減少原始資料在儲存設備上占用的空間，進而減少昂貴的閃存盤的數量。
注：由于篇幅所限，關于采用糾删碼提供資料高可用（RAID-5/6）的原理，以及與鏡像副本（RAID-1）方式在存儲容量需求方面的對比，本文中就不再涉及了。
(3)進一步為 RAID-5/6 提速
使用者對 RAID-5/6 的普遍擔心是寫性能的下降。RAID-5/6 對寫性能的影響主要有兩點：一是使用糾删碼計算校驗塊（Parity），需要消耗更多的 CPU 計算周期，二是寫入操作會引入額外的讀 / 寫操作（I/O 放大）。
對于第一點，VMware 認為現在 CPU 的計算能力大大提升了，不會成為瓶頸，可以放心使用。
vSAN 8 ESA 中，先接收來自客戶機的寫入資料，對這些資料以 4KB 塊為機關進行壓縮——“資料壓縮”現在也作為 ESA 中預設開啟的選項，新改進的壓縮算法的速度和壓縮效率更高——這減少了對存儲容量的需求，也減少了使用糾删碼計算校驗塊所需的 CPU 周期。但資料壓縮過程對 CPU 的消耗呢？
ESA 對 RAID-5/6 寫性能方面的主要改進，是針對以上第二點。
注：為了避免陷入性能泥沼，VMware 要求隻能在全閃配置的 vSAN 叢集上才能啟用 RAID-5/6。這種配置下，讀操作可以不經過緩存盤，直接從容量盤讀取，除非被讀取的資料正好就是緩存盤上的寫緩沖内容。vSAN 7 及以前的版本中，就是以這種方式來避免校驗塊計算可能引入 I/O 的放大。
vSAN 8 ESA 中引入了新的日志結構化檔案系統（LFS）和優化的日志結構化對象管理器。LFS 将壓縮後的資料塊與中繼資料打包，并使用鏡像（Mirroring / RAID-1）方式将這些資料 / 副本和對應的日志寫入到不同主機的閃存盤上。臨時存儲這些資料的區域被稱為“性能分支（Performance Leg）”，它不獨占某個特定的閃存盤，而是分布在每個閃存盤上。這個過程，由于不需要計算校驗塊，寫入速度會很快，客戶機可以在最短時間内獲得寫确認，表現出整體寫性能的提升。
暫時存放在“性能分支”的資料，會被整合為更大的資料塊，計算校驗塊之後，再寫入“容量分支（Capacity Leg）”。這次寫入發生在背景，發起寫入請求的客戶機（虛拟機）早已收到了寫确認，不會感受到其中的延遲。
圖 3 ESA 模式下 RAID-5 寫入流程簡圖
通過以上原理簡介，我們知道 ESA 所宣傳的“不需要專門的緩存盤”，不意味着不使用緩存機制，它隻是把“緩存盤”改成了“性能分支”。寫緩沖資料不再獨占某個閃盤，而是将臨時資料作為“性能分支”分散到所有閃盤上的，是以也不再受到原有 600GB 可用緩沖空間的限制。問題是，每個叢集上的“性能分支”總共需要占用多少空間？VMware 目前還沒有公布這方面的細節，而是在部落格中用了一種很模糊的說法：“它非常小 – 剛好足以将資料傳輸到持久存儲區域”4。
由于采用了“先鏡像、後糾删碼”的兩級資料存儲方式，VMware 釋出 vSAN 8 ESA 強調的最主要亮點是：“以 RAID-1 的性能，獲得 RAID-5/6 帶來的存儲空間節省”4。為了使使用者覺得，ESA 不需要那麼多硬體裝置，甚至将 OSA 中 RAID-5 采用的“3 資料塊 + 1 校驗塊”模式，“自适應”地降低為“2資料塊 + 1 校驗塊”，進而減少了所需的最低主機數量。以下對比了 OSA 與 ESA 中，RAID-5/6 對主機數量的最低要求。
資料來源：Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8
4.對 vSAN 8 ESA 和 OSA 的小結
至此已經可以看出：vSAN 8 ESA 并不能從根本上解決盤組結構（OSA）中被使用者長期诟病的幾個關鍵問題，而是鼓勵使用者使用更貴的閃盤來擷取更高的性能。OSA 使用者也無法直接遷移到 ESA，因為幾乎所有有意向使用 ESA 的使用者都要重新購買 vSAN ReadyNodesTM 伺服器。
為了平衡全閃盤叢集給使用者帶來的成本焦慮，ESA 通過：
- 鼓勵使用者使用 RAID-5/6 代替 RAID-1，以減少所需的閃盤容量和數量。
- 通過預設啟用壓縮功能以及對壓縮算法的改進，減少了對存儲空間的要求。
- 改進的 RAID-5 機制小幅降低了對主機數量的要求。
注：這些措施可能對減少存儲空間需求有幫助，但毫無疑問地增加了對于 CPU 資源的消耗。
ESA 在獲得一定程度改善的同時，部分原本在 OSA 上支援的功能，還不能在 ESA 上啟用。關于新版本受到的功能限制和後續更新，請參見 VMware 官方消息。
在 OSA 方面：
- vSAN 8 保留了對 OSA 的支援，原有 vSAN 使用者可以更新到 vSAN 8 後繼續使用 OSA 模式，不必強制改用全閃盤結構的 ESA，同一個 vCenter 可以同時管理 OSA 叢集和 ESA 叢集。
-
vSAN 8 的 OSA 模式下，緩存盤上的可用空間從 600GB 提高到 1.6TB，但要注意：
· 此空間僅可用于全閃盤組配置下的寫緩沖。
· 将在每台主機上、為每個盤組增加 5GB 記憶體消耗。
無論如何，ESA 消除了“盤組”這一級結構，是一種自我突破。vSAN 發展過程中的技術亮點和缺陷都值得所有其他超融合存儲産品不斷學習和借鑒，才能提供最符合使用者需求的産品。
三、其他解題思路：“共享緩存”與“智能冷熱資料分層”技術相結合
除了 ESA，是否存在其他避免“盤組”結構複雜化的解決方案？
有的。如國内獨立超融合廠商 SmartX，以自主研發的分布式塊存儲技術為核心，将“共享緩存”與“智能冷熱資料分層”技術結合，對比“盤組結構”的限制和不足，具有以下優點：
- 主機内沒有“盤組”這種結構：在叢集内的每個主機上允許共享 2 個以上大容量緩存盤組成的緩存層（單台主機最大支援 16TB 緩存盤和 80TB 容量盤），避免了緩存層裝置的單點故障。
- 通過 2 級 LRU（Least Recently Used）算法對冷熱資料進行生命周期管理，提升資料緩存層使用率。
- 緩存盤上 System 和 Meta data 分區在節點内部作鏡像，Journal 和 Cache 分區支援跨節點鏡像，進一步提升緩存層的高可用特性。
- 不同規格型号的主機、緩存盤、容量盤可以組成異構叢集，為使用者提供更靈活的擴容選擇。
- 對特定的存儲要求，也支援将全部盤資源用于存儲的“不分層”模式。
- 通過“本地優先”的讀寫路徑，提升虛拟機對存儲的通路性能。
SmartX 分布式存儲可以與 vSphere 進行超融合部署，為困擾于 OSA 盤組結構限制但又無法使用 ESA 的使用者，提供了一種選項。
更多 SmartX 超融合技術講解和測試對比，請參見：
VMware 替代合集 | 技術路線、廠商評估、技術分析與對比
https://www.smartx.com/blog/2022/10/vmware-replacement-collection/
VMware 替代專題 | VMware 超融合國産替代之性能對比篇
https://www.smartx.com/blog/2022/09/smartx-vs-vmware/
VMware 替代專題 | VMware 與 SmartX 分布式存儲緩存機制淺析與性能對比
https://www.smartx.com/blog/2022/09/cache-vs-vmware/
VMware 替代專題 | VMware 與 SmartX 快照原理淺析與 I/O 性能對比
https://www.smartx.com/blog/2022/08/snapshot-vs-vmware/
《不止彈性，更加靈活。一文了解 SmartX 超融合如何擴容》
https://www.smartx.com/blog/2022/06/flexible-expansion/
參考文章：
1. Understanding vSAN memory consumption in ESXi 6.x and 7.x (2113954) | VMware KB https://kb.vmware.com/s/article/2113954
2. Adaptive RAID-5 Erasure Coding with the Express Storage Architecture in vSAN 8 | VMware https://core.vmware.com/blog/adaptive-raid-5-erasure-coding-express-storage-architecture-vsan-8
3.Comparing the Original Storage Architecture to the vSAN 8 Express Storage Architecture | VMware https://core.vmware.com/blog/comparing-original-storage-architecture-vsan-8-express-storage-architecture
4.RAID-5/6 with the Performance of RAID-1 using the vSAN Express Storage Architecture | VMware https://core.vmware.com/blog/raid-56-performance-raid-1-using-vsan-express-storage-architecture
5. An Introduction to the vSAN Express Storage Architecture | VMware https://core.vmware.com/blog/introduction-vsan-express-storage-architecture
6. Increased Write Buffer Capacity for the vSAN 8 Original Storage Architecture https://core.vmware.com/blog/increased-write-buffer-capacity-vsan-8-original-storage-architecture
7. vSAN Frequently Asked Questions (FAQ) | VMware https://core.vmware.com/resourc