淺析 vSAN 磁碟組架構和快取盤的“消亡”
一、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
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
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69974533/viewspace-2920626/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- http快取策略以及強快取和協商快取淺析HTTP快取
- Java快取淺析Java快取
- 淺析HDFS架構和設計架構
- 淺析雲原生應用安全組織架構架構
- 電商架構淺析架構
- [轉] 淺析x86架構中cache的組織結構架構
- 淺析瀏覽器快取瀏覽器快取
- Underscore 整體架構淺析架構
- 淺析大型網站的架構(轉)網站架構
- 淺析雲端儲存的TCS和LCA兩大架構架構
- iOS MVC、MVVM、MVP架構模式淺淺析iOSMVCMVVMMVP架構模式
- Linux系統——架構淺析Linux架構
- MyBatis(十一):MyBatis架構流程淺析MyBatis架構
- 微服務架構專案淺析微服務架構
- [轉載]淺析大型網站的架構網站架構
- redis快取架構概述Redis快取架構
- 淺解強快取和協商快取快取
- 淺析Kubernetes架構之workqueue架構
- 淺談快取寫法(一):快取的雪崩和穿透快取穿透
- 架構與思維:一次快取雪崩的災難覆盤架構快取
- 【深入淺出jQuery】原始碼淺析–整體架構jQuery原始碼架構
- 系統架構設計:程式快取和快取服務,如何抉擇?架構快取
- 漫談Web快取架構Web快取架構
- 多級快取架構(六)快取架構
- Linux的磁碟快取和刷髒頁Linux快取
- Java高併發快取架構,快取雪崩、快取穿透之謎Java快取架構穿透
- 【LiteApp系列】愛奇藝小程式架構淺析APP架構
- 淺析Nordic nRF5 SDK例程架構架構
- 雲端高效能技術架構淺析架構
- ASP.NET快取概念及其應用淺析ASP.NET快取
- 淺析ASP.NET頁面快取的幾點體會ASP.NET快取
- 架構設計(三):引入快取架構快取
- 分散式快取架構綜述分散式快取架構
- 高併發快取架構實戰和最佳化快取架構
- 【深入淺出 Yarn 架構與實現】6-3 NodeManager 分散式快取Yarn架構分散式快取
- 快取架構,一篇足夠?快取架構
- 分散式快取GemFire架構介紹分散式快取架構
- 小工匠聊架構 - 分散式快取技術_快取設計架構分散式快取