VMware 與 SmartX 分散式儲存快取機制淺析與效能對比
作者:深入細節的 SmartX 一線技術團隊
近日,VMware 釋出了 vSAN 8,對儲存架構進行了重大更新。其中最主要的變化,即引入了新的 Express Storage Architecture(ESA)架構:用“儲存池”替代了原儲存架構(OSA)中的“磁碟組”,並不再需要專用 SSD 承擔快取加速功能,一定程度上避免了 8.0 之前版本中的專用快取盤利用率低、易發生快取擊穿等問題。
而值得一提的是,在 vSAN 大版本更新之前,SmartX 即透過統一快取空間和智慧冷熱資料管理最佳化了分散式儲存快取機制,有效規避了上述問題。本文將透過重點解讀 vSAN(以 vSAN 7 為例)和 SmartX 分散式塊儲存元件 ZBS* 快取機制的原理,並測試對比兩種快取機制下虛擬機器效能表現,讓讀者更好地瞭解兩種技術實現機制的區別對業務可能帶來的實際影響。
* ZBS 內建於 SmartX 超融合軟體 SMTX OS,可與 SmartX 原生虛擬化 ELF 搭配提供服務。
本文重點
-
vSAN 7 採用劃分讀寫快取空間的機制,將快取磁碟按照容量佔比劃分為寫緩衝區(30%)和讀快取區(70%)。這種方式可能出現快取利用率低、在訪問資料量過大時導致快取擊穿,進而引起效能下降等問題。
-
ZBS 採用統一快取空間的機制,並透過 2 級 LRU 演算法對冷熱資料進行管理,在充分利用快取容量的同時避免了因訪問量激增導致虛擬機器效能下降的情況。
-
本文基於相同的硬體配置和 I/O 讀寫場景,分別測試 VMware 超融合(vSphere 虛擬化 + vSAN 分散式儲存)寫入 300 GB 資料、SMTX OS(ELF + ZBS)寫入 500 GB 資料時虛擬機器的效能表現。結果顯示, vSAN 7 難以充分利用快取介質,發生快取擊穿,導致儲存效能下降;而 SMTX OS 即便在寫入更多資料的情況下也未發生快取擊穿,虛擬機器效能保持穩定。
場景問題
混閃配置是超融合或分散式儲存現階段的主流落地模式。混閃配置是指機器中的磁碟使用 SSD + HDD 混合組成,其中 SSD 磁碟作為資料快取層,而 HDD 磁碟作為資料容量層。以該模式構建的分散式儲存池透過軟體演算法進行冷熱資料自動判斷,在提供高效能的同時,還可獲得較大的儲存容量,進而提升資源利用率,獲得相對全快閃記憶體儲更高的價效比。
在將 SSD 磁碟用作資料快取層時,部分超融合產品會將快取容量(Cache)劃分為讀和寫各自獨立的兩部分。例如,vSAN 7 及更早版本會將每個磁碟組(Disk Group)中的快取磁碟,按照容量佔比劃分為寫緩衝區(30%)和讀快取區(70%),當讀取資料未命中快取或者寫快取已滿,將會直接從容量層進行讀寫。
注:對於全閃配置的磁碟組,可以將全部快取盤容量(100%)用於寫快取,不再設定讀快取區。
這種劃分讀寫的方式,雖然可以保障讀寫 I/O 的快取擊穿空間隔離,但經常導致無法充分利用高速儲存介質的快取空間。例如,在業務虛擬機器寫資料較多、讀資料較少的場景,可能作為寫入資料的快取容量已經被佔滿,但是讀快取空間還有很多容量沒有被使用,反之亦然。
以醫療客戶的整合平臺建設為例,整合平臺透過將各個系統產生的資料集中儲存並重新組織,形成醫院的資料倉儲,幫助醫院挖掘資料價值、形成智慧化決策,進而加快數字化轉型。整合平臺透過 ETL 工具,從現有醫療業務系統(如 HIS、EMR 和 LIS 等)的資料庫直接抽取資料並進行轉換、載入。該過程都發生在中間資料庫中,最大程度降低對生產資料庫的影響。此時中間資料庫會有大量的資料進行寫入,使得快取空間容易被填滿,而如果讀寫快取採用固定容量分配,就可能會發生寫入資料量 > 寫快取空間容量,進而導致快取擊穿、業務訪問效能下降。大型三甲醫院整合平臺平均每天需要處理 900 萬條訊息,要求峰值處理能力需達到 1000 TPS,儲存效能不足易導致整個業務系統卡頓,嚴重情況下甚至會當機,因此非常考驗基礎架構 I/O 吞吐能力。
針對這一問題, ZBS 使用統一的快取空間,不劃分讀寫,所有快取層容量均被使用,不易出現快取空間不足從而影響儲存效能的情況。同時,透過冷熱資料分層技術,依據資料的訪問頻率,將頻繁讀寫的熱資料放置在 SSD 中、長時間無讀寫的冷資料放置在 HDD 中,有效提升資料快取層利用率,保證業務高效能穩定執行。
為了讓讀者更直觀地感受到不同的快取機制對效能的影響,本文將分別介紹 VMware 和 SmartX 分散式儲存快取機制的原理,並測試對比資料寫入場景中兩種快取機制下虛擬機器效能表現。
技術實現
1.vSAN
vSAN 7 使用磁碟組(Disk Group)將高效能儲存介質(如 NVMe / SATA SSD)與低效能儲存介質(如 SATA / SAS HDD)組成邏輯儲存空間,並透過網路 RAID 功能保障資料可靠性。
每臺 ESXi 主機可建立 5 個磁碟組,每個磁碟組中至多僅支援 1 塊高效能儲存介質與 1 ~ 7 塊低效能儲存介質組合構成。其中高效能儲存介質作為快取層,並以 7 : 3 容量比例劃分為讀和寫的空間使用,虛擬機器在進行資料 I/O 訪問時,可使用到其中單個磁碟組的快取空間。低效能儲存介質作為容量層,儲存因訪問頻率較低從快取層回寫(Write Back)的冷資料。
當資料寫入寫快取空間後,會基於電梯演算法(Elevator Algorithm),週期性地將資料回寫到容量層,從而保障快取層有充足的容量支援後續 I/O 的資料請求。當寫快取空間不足時,會直接寫入到容量層。冷資料被讀取訪問時,會將其載入進入讀快取空間中,快取空間不足時將直接訪問持久化快取層。
另外,vSAN 7 的快取資料僅能用於本磁碟組,且快取資料沒有冗餘。
2.ZBS
ZBS 在以混閃模式部署的時候會要求選擇至少 2 塊 SSD 作為快取容量(Cache), 並透過 2 級 LRU(Least Recently Used)演算法進行判定、管理資料冷熱程度。
在 Cache 中,資料會被劃分為 4 種狀態,分別是 Active、Inactive、Clean 和 Free。
- · Active:用來記錄訪問最頻繁和“冷轉熱”的資料,是 Cache 中“最熱”的資料。
- · Inactive:用來記錄首次寫入和短時間未訪問的資料,是 Cache 中“次熱級”的資料。
- · Clean:用來記錄長時間未訪問的資料,是 Cache 中的“冷”資料,且資料已經完成了 HDD 落盤。
-
· Free:用來記錄未使用或被回收的資料,是 Cache 中閒置的資料空間。
-
(1)透過 2 級 LRU 連結串列來管理資料冷熱程度
首次進行資料寫入時,由於 Cache 中沒有資料,會從 Free 中請求未使用的資料空間,資料寫入完成後將被記錄為 Inactive。
Active 中記錄了被訪問過多次的資料塊,當 Active 的資料超過 Inactive 後,將 Active 資料按照被訪問的先後順序進行排序,不經常被訪問的資料會轉移記錄到 Inactive 中,直到兩者的容量相同。
同時當 Active 和 Inactive 的資料容量超過 Cache 空間的 20% 之後, Inactive 資料將開始觸發落盤操作,按照時間先後順序進行排序,排名靠前的早期資料會被寫入到 HDD 並在快取層中被標記為 Clean(此時 Clean 資料在 HDD 和 Cache 中各有一份),後續當 Clean 資料有訪問請求時會被重新標記為 Active,否則將被回收為可用空間供寫入新資料使用。
(2)不同資料讀寫場景的處理機制
資料寫入場景
-
1.Cache 命中
-
a.寫入 Cache 空間並根據當前資料狀態發生“冷熱”變化。
-
2.Cache 未命中
-
a.Cache 未滿,寫入 Cache 中的閒置空間。
-
b.Cache 已滿,寫入容量層中。
資料讀取場景
-
1.Cache 命中
-
a.系統收到讀請求,透過後設資料優先查詢本地節點 Cache 是否命中請求資料,如果資料在 Cache(Active、Inactive、Clean)中,資料將直接從 Cache 中讀取。
-
2.Cache 未命中
-
a.Cache 未滿
-
系統會查詢本地 Data(容量層)中是否有請求資料,如果有則轉向本地容量層請求資料的副本。向本地容量層請求資料的副本,並不是直接讀取容量層上的資料,而是首先查詢本地 Cache 是否有富餘空間,如果 Cache 空間充足,請求資料副本會先從本地容量層中載入到 Cache 中,然後透過 Cache 讀取資料,並返回資料讀取成功。
-
b.Cache 已滿
-
系統收到讀請求,當發現請求資料副本沒有在本地 Cache,並且這個時候,本地 Cache 空間已經沒有富餘空間,請求資料副本會直接從容量層中讀取。
-
測試驗證對比
1.測試環境
(1)硬體環境
對比測試時採用相同的硬體環境,均使用 3 臺 Dell PowerEdge C6420 伺服器 ,每臺硬體配置如下:
(2)軟體版本
2.測試方法
透過 FIO 測試工具,分別在 vSAN 中寫入 300 GB 資料、在 SMTX OS 中寫入 500 GB 資料,觀察虛擬機器效能監控檢視的資料表現和變化。
3.測試結果
(1)vSAN
SSD 單盤容量 894.25 GB,讀快取 620.61 GB,寫快取 268.28 GB,讀寫快取容量比例為 7:3,符合《VMware vSAN Design Guide》中的描述。
在 256K 順序寫 300 GB 資料測試中,由於快取空間不足,發生寫快取擊穿,效能發生下降,從 280 MB 降低到 75 MB 左右。
在 4K 隨機寫 300 GB 測試中,同樣由於快取擊穿導致了很大的效能下降,IOPS 從 37176 跌落至 16060。
透過上面的測試可以發現,vSAN 7 採用讀寫快取空間各自獨立,在容量較大的資料請求場景中存在快取介質無法充分利用的情況,容易發生快取擊穿導致儲存效能下降。
(2)ZBS
從快取容量監控檢視可以看出每個節點均有 1.5 TiB 的快取容量可使用(不區分讀寫快取),即 2 塊 ~900GB SSD 的可用快取容量。
首先使用 FIO 在測試虛擬機器中 256K 順序寫入 500 GB 資料,觀察虛擬機器的效能變化。
透過虛擬機器效能監控檢視可以發現,FIO 測試虛擬機器無效能波動,一直處於快取 100% 命中狀態。此時首次寫入的 500 GB 資料儲存在 Inactive。
再次測試 4K 隨機寫入 500 GB 資料,觀察發現效能依然保持穩定,快取未擊穿。
從上述對比可以發現,在相同的資料容量和 I/O 讀寫場景中,SMTX OS 能夠更好地利用快取容量空間,即使發生大容量的資料突發請求也不易發生快取空間擊穿導致虛擬機器效能下降,進而更好地保障業務穩定執行。
總結
與 vSAN 7 劃分讀寫的快取機制相比而言, ZBS 在處理資料請求時,透過統一快取空間的方式,提升了快取利用率,即使面對業務突發性資料寫入和訪問激增場景,也能很好地保障業務效能需求。同時,ZBS 採用 2 級 LRU 演算法將資料劃分為多種熱度級別,可對冷熱資料進行生命週期管理,快取層也支援使用多種儲存介質(SATA SSD、NVMe SSD 等),使用者可根據不同業務的效能需求靈活選擇,節省硬體投入成本,獲得更高的價效比。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69974533/viewspace-2914991/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 基於 SmartX 分散式儲存的 RDMA 與 TCP/IP 技術與效能對比分散式TCP
- 基於 SmartX 分散式儲存的 iSCSI 與兩種 NVMe-oF 技術與效能對比分散式
- VMware 與 SmartX 超融合 I/O 路徑對比與效能影響解析
- 一文讀懂瀏覽器儲存與快取機制瀏覽器快取
- Web 快取機制 與 快取策略Web快取
- Web快取知多少(快取機制和資料儲存)Web快取
- Java快取機制:Ehcache與Guava Cache的比較Java快取Guava
- Nutanix 替代專題 | SmartX 與 Nutanix 超融合市場、技術與效能對比
- IO多路複用與epoll機制淺析
- 應對分散式快取當機的方案分散式快取
- Java快取淺析Java快取
- 瀏覽器的快取機制—強快取與協商快取瀏覽器快取
- 【深入淺出 Yarn 架構與實現】6-3 NodeManager 分散式快取Yarn架構分散式快取
- 也淺談下分散式儲存要點分散式
- Android快取機制-LRU cache原理與用法Android快取
- 億級流量客戶端快取之Http快取與本地快取對比客戶端快取HTTP
- 分散式快取--快取與資料庫一致性方案分散式快取資料庫
- 崑崙分散式資料庫儲存叢集 Fullsync 機制分散式資料庫
- 淺談瀏覽器快取機制瀏覽器快取
- 儲存過程與儲存函式儲存過程儲存函式
- Android 檔案儲存淺析Android
- MVVM機制淺析MVVM
- 淺析瀏覽器快取瀏覽器快取
- [分散式]分散式計算系統淺析分散式
- 分散式快取分散式快取
- 深度剖析分散式事務之 AT 與 XA 對比分散式
- 分散式儲存與傳統網路儲存系統相比有哪些區別分散式
- 深入淺出瀏覽器快取機制瀏覽器快取
- 對於前端快取的理解(快取機制和快取型別)前端快取型別
- 實時流處理與分散式儲存過程中對檔案的操作分散式儲存過程
- http快取策略以及強快取和協商快取淺析HTTP快取
- 儲存機制
- Redis 分散式儲存Redis分散式
- HDFS分散式儲存分散式
- Libco Hook 機制淺析Hook
- 儲存技術對比:NVMe與SATA孰強孰弱?
- Kubernetes 幾種儲存方式效能對比 (轉載)
- 通過 PHP 與 Python 程式碼對比淺析語法差異PHPPython