當談PCIe SSD的高效能,我們在談什麼(下)
上篇文章談到了PCIe SSD的發展和效能追求,並介紹了NVMe用以保障QoS的IOD。Memblaze已經對IOD進行了深入的調研,設計了一系列驗證試驗,這篇文章將基於兩個具有代表性的試驗說明NVM Set對於SSD提升QoS的重要作用。(上篇文章:《當談PCIe SSD的高效能,我們在談什麼(上)》)
在討論之前需要對PCIe SSD內部基於NVM set, 引入三種邏輯單元結構的資料佈局進行說明(如下圖),可以理解為這是一塊16通道,每個通道上有8個Die/Flash LUN的SSD。
第一種是傳統的資料佈局(Traditional),整個資源池不同區域沒有明顯的隔離策略,資料會分佈在所有的Flash LUN上,顯然如果多個應用同時對這塊SSD進行讀寫操作,I/O衝突造成的高延遲。
而下面兩種是引入了NVM Set的資料佈局。左側垂直邏輯單元(Vertical Sets)中Set1和Set2以通道為單位,各佔用一半的NAND資源;而水平邏輯單元(Horizontal Sets)中每個Set都享有每個通道上一半(即4個Die)的NAND資源。垂直和水平兩種不同的資源隔離策略會達到不同的效能效果,隨後試驗的解讀部分會詳細說明。
驗證NVM Set帶來的QoS提升
第一個試驗是2個應用同時對一塊PBlaze5 916 NVMe SSD進行讀/寫操作,並且採集傳統邏輯單元(Traditional)以及劃分了2個Set的水平邏輯單元(Horizontal Sets)兩種模式下的測試資料。
測試環境
System:Dell PowerEdge R730xd (Intel Xeon E5-2640 v3 x8 @ 2.6GHz)
IO patterns:
負載1: 32KB Sequential Write, 1job, QD = 4
負載2: 4KB Random Read, 1job, QD = 8
Namespace:2 Namespaces
我們在PBlaze5 916上配置了兩個Namespace,測試對Namespace1進行順序寫操作,同時對Namespace2進行隨機讀操作。使用水平邏輯單元(Horizontal Sets)模式時,兩個Namespace分屬兩個NVM Set。
這是一個非常典型的業務場景模型,有的業務以讀為主,有的業務以寫為主。測試擇取Namespace2的讀延遲資料,這一資料一定程度上可以評估應用之間的干擾影響(這裡的寫也可以看做讀的Nosiy Neighbors)。
Nosiy Neighbors
在Facebook對IOD的一系列測試中,就可以看到這一概念。當兩個應用同時對一塊SSD進行讀寫操作,兩者可以視對方為影響自身體驗的Nosiy Neighbor。我們的實驗以讀負載的測試結果為準,寫負載為其Nosiy Neighbors。
黃色線是傳統模式下的測試結果,可以看到雖然I/O也得到了及時的響應,延遲在200~250μs之間,但是不停的抖動,讀負載受到寫負載影響較大。下面這條藍色是一條平線,在使用了NVM Set的功能之後,讀的操作完全沒有受到寫的影響,延遲始終穩定在100微秒左右,平均延遲有2.25倍的提升。
從QoS的角度可以更直觀的看到NVM Set帶來的穩定性的提升,在 99.9999%下兩種模式有21倍的差距,這個影響還是非常可觀的。接下來我們進一步對最大讀延遲、不同佇列深度(QD)下IOPS進行一個對比。
延遲全面降低,IOPS效能提高,QoS得到最大限度的保障,使用者體驗穩定。這就是NVM Set帶來的收益!
NVM Set效果驗證二:傳統邏輯單元VS 垂直邏輯單元VS 水平資料邏輯單元
第一組試驗對NVM Set帶來的穩定性和效能收益進行了驗證和展示,第二組試驗測試環境、裝置和負載模型都沒有變化,但是將加入垂直邏輯單元的對比。
這裡紅線是垂直邏輯單元的結果,藍線是水平邏輯單元的結果,雖然垂直邏輯單元中兩個NVM Set會分別獨佔通道,但是比較反直覺的是並沒有帶來更好的測試結果。通過調查發現,水平邏輯單元模式中通道更多(16)擁有更高的I/O併發度,而垂直邏輯單元模式在較少的通道(8)上接入更多數量的Flash Lun後,通道內的讀命令之間阻塞影響不容忽視。
同樣接下來我們進一步對最大讀延遲、不同佇列深度(QD)下IOPS進行一個對比。對比結果如下圖:
左側的圖展示了整體的QoS資料。當QoS級別較低時,比如99.99%的時候,傳統邏輯單元模式下SSD的延遲已經迅速的升高,而使用了NVM Set的兩種模式則一直保持著平穩的低延遲,直到99.9999%以及更高的情況下,才會看到紅線、藍線上升,但即使在這種情況下,跟傳統的混合情況下還是有差距。相似的結果同樣出現在IOPS上,不論佇列深度多高,我們依然可以發現垂直邏輯單元模式和水平邏輯單元模式的效能都是線性增長的,並且它會比傳統模式要好得多。
最後再看一下寫頻寬的對比,當一個 Set 的 Flash 資源只有整體的一半時,寫頻寬到底會受多少影響?同樣是上面實驗的測試指令碼和環境,黃色柱形圖使用了100%的 Flash 資源,在沒有讀干擾的情況下,Pblaze5 916 有高達3GB/s +的寫頻寬,在本次實驗中,寫頻寬雖然會受到讀的影響,但是仍超過了 2GB/s。而另外兩種模式都僅使用了一半的Flash資源做寫操作,兩者均不能有效的利用到所有的寫頻寬資源,因而頻寬只有無影響寫頻寬的一半,約1.5GB/s。需要指出的是,垂直邏輯單元模式下,獨立的 Flash 通道使他獲得比水平模式略高一線的寫頻寬。
通過上面兩個實驗,可以看到不同的Set劃分方式有不同的優勢,他們都是非常有效的隔離手法。Memblaze 還在更加深入的研究 NVM Set 等資源隔離和管理的方法,力求讓 SSD 在實際的應用場景中擁有更高的效能和穩定性。
在 NVMe 生態演進層面,可以看到 Windows 驅動很快會加入 IOD 的支援,Linux 驅動也會加入 IOD 的支援,我們常用的管理工具 NVMe 的 Cli 也已經支援 IOD 。最後1.3C和1.4都已經把 IOD 擺上了日程。這些都再次印證 IOD 是一個非常明確的方向。
Open Channel SSD vs NVMe的IOD
在上文中提到了 Open Channel 的 SSD,這項技術為控制 QoS 和延遲而生。那麼接下來的問題是 Open Channel 的 SSD 與 NVMe 的 IOD 各有什麼樣的優缺點?是否 Open Channel 的效果會毫無疑問更好?
Open Channel將所有的Flash管理和控制權都交到了Host應用軟體手上,讓Host進行有效的管理,這種管理會可以避免在垃圾回收等各類對前端應用I/O請求的影響。
IOD 的效果比 OC 略低,雖然在上文中的兩個驗證試驗中看到的結果非常好,但是兩個試驗都僅僅是對單一 Set 進行了單一的操作,這種負載模型仍屬於理想化模擬。如果Host 能做到對每個 Namespace 都做純讀或者純寫操作,那麼 NVM Set 的使用效果會很明顯;如果 Host 上應用是混合讀寫負載,SSD 的效能和穩定性仍不可避免互相影響,進而影響到前端應用的體現。
但從實現的複雜度看,Open Channel 帶來的複雜度遠比IOD 帶來的要高,應用方需要有完善的 Flash 管理程式碼來替代廠商久經考驗的 SSD 韌體,確保工作正常。反之 IOD操作及其簡單,可以簡單的理解成為把一個 SSD 在物理上進行邏輯分割槽,host 使用與在一塊硬碟上使用不同分割槽是一樣的,只要通過前期的簡易配置就可以達到一勞永逸的效果。
第三個就是標準化的程度。 Open Channel 的標準化現在已經演進到 Open Channel2.0,但其標準化程式仍然不高,眾多需求需要通過定製化的方案實現。對應起來IOD是 NVMe1.4 的標準協議,相信它會很快成為所有SSD的標配功能,可以提供到使用者去使用,這不僅是IOD的優勢,更是 NVMe 多年發展築造的標準化生態的優勢。
最後,IT系統面臨的應用場景複雜多樣,不同的型別客戶,應該是根據自己的情況,根據自身應用可配置情況、可定製情況能夠去選擇最合適自己的產品和方案。
在這裡,Memblaze的NVMe SSD會隨著NVMe協議一起不停往前去演進,希望能夠提供給使用者層面更多有價值的功能,給更多使用者更好的使用者體驗。
相關文章
- 當談PCIe SSD的高效能,我們在談什麼(上)
- 當我們在談零信任時,我們談的是什麼?
- 當我們談論MOD時,我們在談論什麼?
- 當我們在談論極簡時,我們在談論什麼
- 當我們在談論HTTP快取時我們在談論什麼HTTP快取
- 當我們談 Java 併發的時候,你們在談什麼?Java
- 當我們談優化時,我們談些什麼優化
- 當我們談論格鬥遊戲時,我們在談論什麼遊戲
- 當我們談論Spring的時候到底在談什麼Spring
- 當我們在談論建構函式注入的時候我們在談論什麼函式
- 當我們在談論VR敘事的時候,我們究竟在談論什麼?VR
- 當我們談微服務,我們在談什麼 (3) — 如何保障微服務的穩定性微服務
- 當我們在談論高併發的時候究竟在談什麼?
- 當我們談論CloudTable時究竟在談論什麼?Cloud
- 當我們談論Promise時,我們說些什麼Promise
- 當我談跑酷遊戲時,我在談些什麼遊戲
- 當我談 HTTP 時,我談些什麼?HTTP
- 當我們談論Virtual DOM時,我們在說什麼——etch原始碼解讀原始碼
- 當我們談深度學習時,我們用它落地了什麼?深度學習
- 當我談自律的時候,我會談什麼(一)
- HMS Core Insights第三期直播預告—— 當我們在談論App的時候,我們還可以談論什麼?APP
- HMS Core Insights第三期直播回顧 – 當我們在談論App的時候,我們還可以談論什麼?APP
- 我們究竟在怕什麼?——談談恐怖遊戲的元素堆砌遊戲
- 今天我們來談談【畫素流送】到底是什麼?!
- 當我們聊kubernetes operator時,我們在聊些什麼
- 淺談入行Qt桌面端開發程式設計師-從畢業到上崗(1):當我們說到桌面端開發時,我們在談論什麼?QT程式設計師
- 85後來談談我們怎麼養老?
- 當我們在討論遊戲社群時,我們在討論什麼?遊戲
- 當我們在聊 RN 時,我們在聊什麼 | 技術點評
- 當我們談論版權保護的時候
- 當我們說外掛系統的時候,我們在說什麼
- 當小遊戲開始成為新的風口,讓我們從零到一的談談(下)遊戲
- 當我們談深度學習時,我們用它落地了什麼?阿里雲內容安全功能全新升級深度學習阿里
- 朱峰談概念設計(二):我們設計什麼
- 當提到“事件驅動”時,我們在說什麼?事件
- 當我們說開放世界的時候,我們到底在說些什麼?
- 當我們討論TCP的連線運輸管理時,我們在說什麼TCP
- 是時候談談JavaScript物件導向了!(我們什麼時候更需要它)JavaScript物件