緣起：Open-Channel

01

1.1Open-Channel SSD的出現

傳統的NVMe SSD，對于上層的系統來說，是一個通用型的塊設備層。由于使用和磁盤相同的通用塊I/O接口，傳統NVMe SSD的控制權并不在SSD。受該接口限制，傳統SSD的FTL具有一定局限性，因而成為了SSD性能和效率的瓶頸。這些限制包括SSD底層策略，例如：數據放置位置、I/O調度、磨損均衡、以及其他涉及SSD的應用效能優化。這些缺點并不是由于硬件限制引起的，而是傳統NVMe SSD設計決定的。這時候，一種新的想法Open-Channel開放接口SSD產生了，顧名思義，開放接口把SSD底層接口開放給主機，這樣做有什么好處呢？

· 主機控制權

主機端可以根據自身的業務來控制盤的行為，包括寫入順序，寫在哪個NAND的Block上，什么時候擦除和寫入，取代傳統的SSD firmware控制權?；谥鳈C對自身讀寫行為及業務運行的負載感知了解，可以從主機端直接進行優化處理。

· I/O隔離

對于用戶端應用架構(multitenant architecture)，I/O隔離有助于解決由于物理資源共享導致不同邏輯分區不可避免地影響到彼此的性能表現，Open-Channel SSD里面的每個PU(NAND操作基本單元)在物理上是隔離的，主機端可以決策對哪個PU物理位置進行操作。

· 可預測和可控制的命令時延

由于主機控制所有命令的操作，并知道每一個物理PU上正在執行的（或者pending的）所有NAND操作，所以主機對自己下發后的讀寫命令時延就有準確的把握。

1.2Open-Channel SSD的實現

為了實現上述功能和控制，Open-Channel SSD實現了把大部分傳統NVMe SSD FTL功能從SSD Firmware內部遷移到上層的主機端，遷移的功能有Data Placement, Garbage Collection, L2P table , I/O Scheduling, Wear Leveling等。

FTL功能上移后，為了實現上述功能，Open-Channel SSD將本來位于NVMe SSD上Firmware中的對NAND Flash管理和控制的部分功能，交給了主機端的應用軟件。讓應用根據自身的業務特點，對盤上的NAND Flash進行有效的管理，如下圖所示。很多情況下，主機端的應用管理，可以有效避免垃圾回收等后臺操作對前端應用I/O請求的影響，更好控制QoS和延遲。

普通NVMe SSD架構

Open-Channel SSD架構

與此同時，Open-Channel SSD向主機展示出內部NAND布局的細節，主機可以決定數據實際存放的物理位置。這樣，Host就可以根據IO請求的發起方，將IO 數據寫到不同的位置，實現不同應用、用戶數據的物理隔離，達到更好的QoS效果。

傳統NVMeSSDvsOpen-ChannelSSDNAND布局 (來源[2])

為了實現NAND物理位置的定義，Open-Channel Spec定義了[3]：

· Chunk

Chunk是指一系列連續的邏輯塊。在一個Chunk內，主機側只能按照邏輯塊地址LBA順序寫入，如果要重新寫入前面寫過的某個邏輯塊，需要重啟該邏輯塊所在的Chunk。

Chunk示意圖

· 并行單元（Parallel Unit，PU）

SSD是通過并行操控閃存來實現高速讀寫的。PU是SSD內部并行資源的一個單位，主機側可以指定數據寫到哪一個PU上，一個PU可能包含一個或多個閃存Die。

·不同的PU可以完全做到物理隔離；

·值得說明的是，在最新的NVMe協議里面，I/O determinism已經解決了物理隔離的問題，而在Open-Channel提出的時候，尚沒有標準解決方案，這也是Open-Channel的價值所在。

Chunk和PU邏輯拓撲圖如下：

Open-Channel SSD邏輯拓撲圖

·很多Chunk組成了PU；

·很多PU組成了Group(其具體定義，請讀者參閱Open-Channel 協議)；

·很多Group組成了SSD。

在Open-Channel SSD中的邏輯塊地址(LBA)的概念被重新定義，它包含了PU、Chunk和Group的信息。

LBAEncoding格式

從實際應用的部署情況來看，Open-Channel SSD主機端實現了一個復雜的FTL(Flash Translation Layer), 替代SSD中本已健壯成熟的Firmware層實現的功能，來管理NAND flash和數據存放。而且Open-Channel Specification 僅僅定義了Open-Channel涉及的最為通用的部分。不同廠商的SSD產品特性不同，它們或者難以統一，或者涉及敏感內容，不便公開，實際Open-Channel產品往往在兼容Open-Channel Spec的基礎上，各有一部分私有定義。不同業務方的需求獨特，往往需要在自己的FTL內加入定制化的內容。因此，至今尚未有通用的Open-Channel SSD和針對獨特業務的通用FTL。這些制約嚴重影響了Open-Channel的發展速度。

當前全球市場，實現了Open-Channel SSD商用的廠商只有Shannon Systems。部分互聯網頭部廠商基于Shannon Systems的代碼和產品定制化自己的Open-Channel SSD產品用于業務效能提升。

進化：ZNS更進一步

02

2.1Open-Channel SSD的缺點

然而Open-Channel也有以下缺點：

·需要主機側軟件層面的支持，或者重新增加一個軟件層來匹配原來的軟件堆棧。目前其軟件生態并未完善，有些上層應用需要的改動比較大；

·主機側存儲開發人員需要透徹了解SSD內部原理，并且實現定制的FTL；

·主機側與SSD分工協作復雜，尤其是在處理后端糾錯過程，以及解決數據在閃存上的數據磨損問題的時候。

最后為了規避上述問題，有沒有可能既可以做到允許主機側盡量自由擺放數據，同時有標準的軟件生態呢？答案就是ZNS，它作為Open-Channel的下一代協議被提出來。ZNS協議由NVMe工作組提出，旨在：

·標準化Zone接口；

·減少設備端的寫放大問題；

·更好配合上層軟件生態；

·減少OP，節省客戶成本；

·減少DRAM使用，畢竟DRAM在SSD中的成本舉足輕重；

·增加帶寬，減少時延。

那ZNS都說了什么？什么是Zone？以及它能否以及如何達成上述目標呢？

2.2ZNS實現模型

Zoned Namespace NVME Spec起草作者和Open-Channel SSD Spec作者是同一人，兩個標準有很大的相似性，所以ZNS可以說是Open-Channel的進化，是在Open-Channel基礎上更加商業化和標準化的實現。

相對于傳統的NVMe Namespace, Zoned Namespace將一個Namespace的邏輯地址空間切分成多個Zone。如下圖所示，Zone是Namespace內的一種固定大小的子區間，每個Zone都有一段LBA(Logical Block Address, 邏輯地址空間)區間，這段區間只能順序寫，而且如果要覆蓋寫，則必須顯示的進行一次擦除操作。這樣，Namespace就可以把NAND內部結構的邊界透露給主機，也就能夠將地址映射表等內部管理工作交由主機去處理，從而減少寫放大、選擇合適的GC(Garbage Collection, 垃圾回收)時機。

Zone的基本操作有Read, Append Write，Zone Management 以及Get Log Page，如下圖所示。Zone大小可以采用Open-Channel中Chunk的大小為單位，即與NAND介質的物理邊界為單位。Zone Log Page也會與Open-Channel Spec 2.0中的Chunk Info Log相似。

Zone的基本操作

與Open-Channel相比，Zone的地址是LBA(Logical Block Address, 邏輯塊地址)，Zone X的起始地址與Zone X-1的結束地址相連，Zone X的結束地址與Zone X+1的起始地址相連，Zone的容量總是小于等于Zone的邏輯大小。這樣一來，Zone Namespace就可以避免Open-Channel里繁瑣的各類地址轉換。

Zone的大小和地址示意圖

對比傳統NVMe SSD，Zoned Namespace優點：

· 更高效的垃圾回收GC操作

機械硬盤中文件系統可以直接將新數據寫入到舊數據存儲的位置，可以直接覆蓋舊數據。在固態硬盤中，如果想讓某個存有無效數據的塊寫入新數據，就需要先把整個塊擦除，才可以寫入新的數據。固態硬盤并不具備直接覆蓋舊數據的能力，所謂GC（垃圾回收）是指把目標擦除位置現存有效數據重新轉移到其他閃存位置，然后把包括無效數據的該位置徹底擦除的過程。ZNS把LBA直接展示給上層應用，由上層應用來調度的GC操作，ZNS SSD由于Zone內順序寫、無覆蓋寫因此GC操作比Open Channel更高效可控, 從而性能也比較穩定。

· 延遲可預測

傳統的NVMe SSD GC的時機和耗時對于應用是不可控的，ZNS讀、寫、擦和GC的實際完全由主機和應用掌控，相比于傳統NVMe SSD延遲表現更穩定。

· 減少OP

傳統NVMe SSD會預留一部分空間(Over Provisioning)用于垃圾回收GC和磨損均衡WL，通常OP空間占整個SSD容量的7-28%，OP空間對用戶時不可見的。ZNS SSD有更高效的GC機制，除了保留極少量OP空間用于替換壞塊，并沒有其他會大量消耗NAND空間的情況，并且ZNS固件本身所需要的運行空間遠低于傳統NVMe SSD。

· 成本更低

ZNS的架構特點，導致可以使用更少的DRAM，以及更少的OP，因此相對傳統NVMe SSD的成本有較大程度的降低。

最后，綜上ZNS有著以上的理論優勢，實測性能如何呢？如下圖[1]，ZNS SSD由于Zone內順序寫、無覆蓋寫及可控的GC操作等特性，同樣穩態滿盤條件下，ZNS盤展現出的寫性能和原始Host寫數據帶寬呈線性1:1關系，無由盤內數據搬移如垃圾回收導致的寫性能損失。同時在線性增長的Host寫數據帶寬條件下（0-1GiB/s），ZNS SSD展現出可預測的讀時延（線性增加）。

ZNSvs傳統SSD展現的Raw IO特性

實例：Shannon Systems SP4

ZNS盤評測SP4 ZNS SSD介紹

03

1) SP4 ZNS 固件特性：

Support 8 Open Zone
Support 4K over-write
Zone Index：

Zone Capacity：8~9 GB

Active Zone/Open Zone Number(max)：8

Total Capacity：8 TB

2)FIO Benchmark

* SP4 ZNS in FIOzbd mode;P5510 in FIOregular mode

結論：SP4 ZNS盤在FIO zbd模式下的性能測試，相比較于P5510傳統盤模式下的測試，128K連續讀性能基本相同，但128K連續寫性能提升26%，4K隨機讀性能提升16%。

SP4 ZNS vs P5510 QD1連續寫時延對比

SP4 ZNS vs P5510 QD1連續寫99.99%時延對比

SP4 ZNS vs P5510 QD1隨機讀時延對比

SP4 ZNS vs P5510 QD1隨機讀99.99%時延對比

結論：相比較P5510， SP4 ZNS盤連續寫和隨機讀 QD1時延，不同的Sector Size下，均不同程度的大幅減少，例如128K QD1 99.99% QoS, 連續寫是P5510的1/4, 隨機讀是P5510的1/3。同樣8K/16K/32K/64K QD1 99.99% QoS對比參見如上圖表。

ZNS生態探索：

RocksDB + ZenFS + ZNS SSD

04

1)通用數據庫引擎和NANDFlash物理特性的沖突

機械硬盤可以對一個塊原地修改，但是NAND Flash因為使用壽命和物理特性的限制(塊擦寫次數壽命，塊寫前要先擦除)，需要最大限度均衡地寫所有塊，頻繁讀寫Flash上的同一個塊，會快速縮短這個塊的壽命。基于這個原因，要求對NAND Flash上的塊進行順序寫，即寫完一個塊后寫下一個塊。數據庫存在很多頻繁更新數據的場景，這些數據很多時候都會位于不同的塊上，此時需要把要修改的塊的數據拷貝出來，修改后寫入一個新的塊，并把舊塊標記為可回收，這個Copy-Write Back過程會浪費性能。所以，一種符合閃存物理特性的數據庫引擎對提升數據庫和閃存性能很重要。

2)RocksDB一種專為閃存設計的數據庫

針對閃存的物理特性，出現了一批新型數據庫，知名度和使用最廣泛的是RocksDB，從LevelDB發展而來的KV數據庫。RocksDB特點是對于WAL日志只會append，對于已經落盤的數據文件不會修改，這是針對閃存特性做的設計。

RocksDB存儲結構(來源[4])

RocksDB特點是數據先寫內存的memtable，當memtable寫滿后會被鎖定變成immutable memtable禁止修改，Flush線程會把immutable memtable刷到盤上。Rocksdb盤上文件是分層的，Level 0, Level 1…Level N, Level 0的文件最新，Level 1的次之，依次類推。

Compaction過程：參看上圖，上層Level中sst文件數量達到指定數量，會執行壓縮功能，把多個sst文件進行去舊壓縮合并成新的sst文件并寫入到下層Level，這些被合并的sst文件會被刪除。

RocksDB的性能優化，一個memtable大小超過配置的write_buffer_size大小，會被標記為immutable memtable，當所有memtable包括immutable memtable數量達到max_write_buffer_number時，此時Rocksdb將會停止寫入，直到Flush線程把immu memtable刷到disk后，寫入才能繼續。因此當通過iostat看到盤有較長空閑時間時，那么增大max_write_buffer_number減少盤的空閑時間，可降低寫失速現象。

增加max_background_flushes刷盤線程數量也會提升寫入速度。由于每次寫操作都會先寫wal日志，所以關閉wal對寫性能有一定提升，但是會導致宕機后數據丟失的風險，一般wal都會開啟。

增加compaction線程數量max_background_compactions可提升壓縮sst文件速度。寫盤速度造成Backpressure，當NVMe命令延遲過大會降低flush和compaction速度，從而會造成停止寫memtable。

最后，CPU性能可能是影響讀寫性能的重要因素。

3)ZenFS為ZNS + RocksDB設計的用戶態文件系統

ZenFS由Western Digital主導，ZenFS可以作為一個plugin編譯進RocksDB，作為RocksDB的backend filesystem，封裝對ZNS塊設備的管理操作。ZenFS依賴libzbd管理和獲取ZNS的Zone信息，讀寫塊設備時通過pread、pwrite系統調用，并且專門針對ZNS實現了一個簡易的用戶態文件系統。

ZenFS文件系統 (來源[5])

4)性能對比

最后，給出一組RocksDB+ZenFS環境下實測數據[1]，當后臺寫無限制時，ZNS SSD寫性能是傳統盤的2倍；同樣后臺寫無限制時，ZNS SSD 99.99%讀時延是傳統盤的1/4。

RocksDB+ZenFS+ZNSSSD vs傳統盤性能對比

展望

05

當前ZNS應用生態仍然有較大優化空間，比如在對盤上數據組織方面，由于上層用戶數據可能被覆蓋寫入，必然會出現ZenFS中的extent數據塊變為無效，導致盤上Zone空間出現無效數據，雖然RocksDB通過Compaction可以丟棄無效數據，但這些無效數據在一段時間內占用了Zone空間，造成一定程度的空間放大。未來同對ZenFS數據管理邏輯的進一步優化，降低空間放大效應，對Compaction壓力將會起到積極的作用。

對于Compaction過程，我們正在探索以Copyback方式實現數據直接在盤內轉移，降低RocksDB的負載，提高用戶數據的PCIe Bus傳輸效率。未來版本中，將嘗試向ZNS設備中加入可變Zone Size的功能，以更好地迎合RocksDB的LSMT文件存儲方式，低level的SST文件通常較少，適合放在Capacity較小的Zone，隨著level增加，SST數據變得更多，則更適合放入Size更大的Zone。

ZNS的寫入方式消除了盤上GC這一阻礙企業級SSD獲得更好Latency QoS的主要障礙，有充足的理由對包括內核、文件系統、數據庫等上層應用做更深入的優化。

如F2FS最初是為SMR HDD設計的基于ZBD設備的文件系統，其讀寫方式也有機會稍做修改，從而應用在ZNS設備上。又如業界已經提出并正在討論的，將Zone與文件名做Mapping，使得RocksDB或類似數據庫可以直接通過驅動訪問Zone空間，直接在盤內索引文件，剝離文件系統這一層的Overhead。

另外通過從內核NVMe驅動導出專門的API，向應用直接暴露Zone空間，用戶利用io_uring或SPDK等可以從內核態或用戶態直接操作ZNS設備，向上提供更大的靈活性。

目前業界已經可以看到初具雛形的中間件產品，如xNVMe，這是一個IO Interface抽象層，提供了多種支持ZNS設備的內核IO Interface，包括Linux和Windows版本。開發者可以面向xNVMe提供的API進行上層應用開發，而不必關心設備訪問實現細節，同時只要修改xNVMe配置即可實現不同操作系統的兼容。在xNVMe的基礎上，以FlexAlloc作為Backend，向RocksDB提供對象分配器，使得RocksDB可以直接運行在ZNS裸設備上，相比目前商用SSD方案，有希望獲得更好的性能體驗。

審核編輯 ：李倩