緣起：Open-Channel

Open-Channel SSD的出現(xiàn)

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

主機(jī)控制權(quán)

主機(jī)端可以根據(jù)自身的業(yè)務(wù)來控制盤的行為，包括寫入順序，寫在哪個(gè)NAND的Block上，什么時(shí)候擦除和寫入，取代傳統(tǒng)的SSD firmware控制權(quán)?；谥鳈C(jī)對自身讀寫行為及業(yè)務(wù)運(yùn)行的負(fù)載感知了解，可以從主機(jī)端直接進(jìn)行優(yōu)化處理。

I/O隔離

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

可預(yù)測和可控制的命令時(shí)延

由于主機(jī)控制所有命令的操作，并知道每一個(gè)物理PU上正在執(zhí)行的（或者pending的）所有NAND操作，所以主機(jī)對自己下發(fā)后的讀寫命令時(shí)延就有準(zhǔn)確的把握。

Open-Channel SSD的實(shí)現(xiàn)

為了實(shí)現(xiàn)上述功能和控制，Open-Channel SSD實(shí)現(xiàn)了把大部分傳統(tǒng)NVMe SSD FTL功能從SSD Firmware內(nèi)部遷移到上層的主機(jī)端，遷移的功能有Data Placement, Garbage Collection, L2P table , I/O Scheduling, Wear Leveling等。???? FTL功能上移后，為了實(shí)現(xiàn)上述功能，Open-Channel SSD將本來位于NVMe SSD上Firmware中的對NAND Flash管理和控制的部分功能，交給了主機(jī)端的應(yīng)用軟件。讓應(yīng)用根據(jù)自身的業(yè)務(wù)特點(diǎn)，對盤上的NAND Flash進(jìn)行有效的管理，如下圖所示。很多情況下，主機(jī)端的應(yīng)用管理，可以有效避免垃圾回收等后臺操作對前端應(yīng)用I/O請求的影響，更好控制QoS和延遲。

普通NVMe SSD架構(gòu)

Open-Channel SSD架構(gòu)

與此同時(shí)，Open-Channel SSD向主機(jī)展示出內(nèi)部NAND布局的細(xì)節(jié)，主機(jī)可以決定數(shù)據(jù)實(shí)際存放的物理位置。這樣，Host就可以根據(jù)IO請求的發(fā)起方，將IO 數(shù)據(jù)寫到不同的位置，實(shí)現(xiàn)不同應(yīng)用、用戶數(shù)據(jù)的物理隔離，達(dá)到更好的QoS效果。

傳統(tǒng)NVMe SSD vs Open-Channel SSD NAND布局 (來源[2])

為了實(shí)現(xiàn)NAND物理位置的定義，Open-Channel Spec定義了[3]：

Chunk

Chunk是指一系列連續(xù)的邏輯塊。在一個(gè)Chunk內(nèi)，主機(jī)側(cè)只能按照邏輯塊地址LBA順序?qū)懭耄绻匦聦懭肭懊鎸戇^的某個(gè)邏輯塊，需要重啟該邏輯塊所在的Chunk。

Chunk示意圖

并行單元（Parallel Unit，PU）

SSD是通過并行操控閃存來實(shí)現(xiàn)高速讀寫的。PU是SSD內(nèi)部并行資源的一個(gè)單位，主機(jī)側(cè)可以指定數(shù)據(jù)寫到哪一個(gè)PU上，一個(gè)PU可能包含一個(gè)或多個(gè)閃存Die。

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

值得說明的是，在最新的NVMe協(xié)議里面，I/O determinism已經(jīng)解決了物理隔離的問題，而在Open-Channel提出的時(shí)候，尚沒有標(biāo)準(zhǔn)解決方案，這也是Open-Channel的價(jià)值所在。

Chunk和PU邏輯拓?fù)鋱D如下：

Open-Channel SSD邏輯拓?fù)鋱D

很多Chunk組成了PU；

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

很多Group組成了SSD。

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

LBA Encoding格式

????從實(shí)際應(yīng)用的部署情況來看，Open-Channel SSD主機(jī)端實(shí)現(xiàn)了一個(gè)復(fù)雜的FTL(Flash Translation Layer), 替代SSD中本已健壯成熟的Firmware層實(shí)現(xiàn)的功能，來管理NAND flash和數(shù)據(jù)存放。而且Open-Channel Specification 僅僅定義了Open-Channel涉及的最為通用的部分。不同廠商的SSD產(chǎn)品特性不同，它們或者難以統(tǒng)一，或者涉及敏感內(nèi)容，不便公開，實(shí)際Open-Channel產(chǎn)品往往在兼容Open-Channel Spec的基礎(chǔ)上，各有一部分私有定義。不同業(yè)務(wù)方的需求獨(dú)特，往往需要在自己的FTL內(nèi)加入定制化的內(nèi)容。因此，至今尚未有通用的Open-Channel SSD和針對獨(dú)特業(yè)務(wù)的通用FTL。這些制約嚴(yán)重影響了Open-Channel的發(fā)展速度。????當(dāng)前全球市場，實(shí)現(xiàn)了Open-Channel SSD商用的廠商只有Shannon Systems。部分互聯(lián)網(wǎng)頭部廠商基于Shannon Systems的代碼和產(chǎn)品定制化自己的Open-Channel SSD產(chǎn)品用于業(yè)務(wù)效能提升。

進(jìn)化：ZNS更進(jìn)一步

Open-Channel SSD的缺點(diǎn)

然而Open-Channel也有以下缺點(diǎn)：

需要主機(jī)側(cè)軟件層面的支持，或者重新增加一個(gè)軟件層來匹配原來的軟件堆棧。目前其軟件生態(tài)并未完善，有些上層應(yīng)用需要的改動比較大；

主機(jī)側(cè)存儲開發(fā)人員需要透徹了解SSD內(nèi)部原理，并且實(shí)現(xiàn)定制的FTL；

主機(jī)側(cè)與SSD分工協(xié)作復(fù)雜，尤其是在處理后端糾錯(cuò)過程，以及解決數(shù)據(jù)在閃存上的數(shù)據(jù)磨損問題的時(shí)候。

最后為了規(guī)避上述問題，有沒有可能既可以做到允許主機(jī)側(cè)盡量自由擺放數(shù)據(jù)，同時(shí)有標(biāo)準(zhǔn)的軟件生態(tài)呢？答案就是ZNS，它作為Open-Channel的下一代協(xié)議被提出來。ZNS協(xié)議由NVMe工作組提出，旨在：

標(biāo)準(zhǔn)化Zone接口；

減少設(shè)備端的寫放大問題；

更好配合上層軟件生態(tài)；

減少OP，節(jié)省客戶成本；

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

增加帶寬，減少時(shí)延。

那ZNS都說了什么？什么是Zone？以及它能否以及如何達(dá)成上述目標(biāo)呢？

ZNS實(shí)現(xiàn)模型

Zoned Namespace NVME Spec起草作者和Open-Channel SSD Spec作者是同一人，兩個(gè)標(biāo)準(zhǔn)有很大的相似性，所以ZNS可以說是Open-Channel的進(jìn)化，是在Open-Channel基礎(chǔ)上更加商業(yè)化和標(biāo)準(zhǔn)化的實(shí)現(xiàn)。????相對于傳統(tǒng)的NVMe Namespace, Zoned Namespace將一個(gè)Namespace的邏輯地址空間切分成多個(gè)Zone。如下圖所示，Zone是Namespace內(nèi)的一種固定大小的子區(qū)間，每個(gè)Zone都有一段LBA(Logical Block Address, 邏輯地址空間)區(qū)間，這段區(qū)間只能順序?qū)?，而且如果要覆蓋寫，則必須顯示的進(jìn)行一次擦除操作。這樣，Namespace就可以把NAND內(nèi)部結(jié)構(gòu)的邊界透露給主機(jī)，也就能夠?qū)⒌刂酚成浔淼葍?nèi)部管理工作交由主機(jī)去處理，從而減少寫放大、選擇合適的GC(Garbage Collection, 垃圾回收)時(shí)機(jī)。

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

Zone的基本操作

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

Zone的大小和地址示意圖

對比傳統(tǒng)NVMe SSD，Zoned Namespace優(yōu)點(diǎn)：

更高效的垃圾回收GC操作

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

延遲可預(yù)測

傳統(tǒng)的NVMe SSD GC的時(shí)機(jī)和耗時(shí)對于應(yīng)用是不可控的，ZNS讀、寫、擦和GC的實(shí)際完全由主機(jī)和應(yīng)用掌控，相比于傳統(tǒng)NVMe SSD延遲表現(xiàn)更穩(wěn)定。

減少OP

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

成本更低

ZNS的架構(gòu)特點(diǎn)，導(dǎo)致可以使用更少的DRAM，以及更少的OP，因此相對傳統(tǒng)NVMe SSD的成本有較大程度的降低。

最后，綜上ZNS有著以上的理論優(yōu)勢，實(shí)測性能如何呢？如下圖[1]，ZNS SSD由于Zone內(nèi)順序?qū)?、無覆蓋寫及可控的GC操作等特性，同樣穩(wěn)態(tài)滿盤條件下，ZNS盤展現(xiàn)出的寫性能和原始Host寫數(shù)據(jù)帶寬呈線性1:1關(guān)系，無由盤內(nèi)數(shù)據(jù)搬移如垃圾回收導(dǎo)致的寫性能損失。同時(shí)在線性增長的Host寫數(shù)據(jù)帶寬條件下（0-1GiB/s），ZNS SSD展現(xiàn)出可預(yù)測的讀時(shí)延（線性增加）。

ZNS vs 傳統(tǒng)SSD展現(xiàn)的Raw IO特性

實(shí)例：Shannon Systems SP4 ZNS盤評測

SP4 ZNS SSD介紹

SP4 ZNS 固件特性：Support 8 Open ZoneSupport 4K over-writeZone Index：

Zone Capacity：8~9 GB

Active Zone/Open Zone Number(max)：8

Total Capacity：8 TB

FIO Benchmark

* SP4 ZNS in FIO zbd mode; P5510 in FIO regular mode

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

SP4 ZNS vs P5510 QD1連續(xù)寫時(shí)延對比

SP4 ZNS vs P5510 QD1連續(xù)寫99.99%時(shí)延對比

SP4 ZNS vs P5510 QD1隨機(jī)讀時(shí)延對比

SP4 ZNS vs P5510 QD1隨機(jī)讀99.99%時(shí)延對比

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

ZNS生態(tài)探索：RocksDB + ZenFS + ZNS SSD

通用數(shù)據(jù)庫引擎和NAND Flash物理特性的沖突

????機(jī)械硬盤可以對一個(gè)塊原地修改，但是NAND Flash因?yàn)槭褂脡勖臀锢硖匦缘南拗?塊擦寫次數(shù)壽命，塊寫前要先擦除)，需要最大限度均衡地寫所有塊，頻繁讀寫Flash上的同一個(gè)塊，會快速縮短這個(gè)塊的壽命?；谶@個(gè)原因，要求對NAND Flash上的塊進(jìn)行順序?qū)?，即寫完一個(gè)塊后寫下一個(gè)塊。數(shù)據(jù)庫存在很多頻繁更新數(shù)據(jù)的場景，這些數(shù)據(jù)很多時(shí)候都會位于不同的塊上，此時(shí)需要把要修改的塊的數(shù)據(jù)拷貝出來，修改后寫入一個(gè)新的塊，并把舊塊標(biāo)記為可回收，這個(gè)Copy-Write Back過程會浪費(fèi)性能。所以，一種符合閃存物理特性的數(shù)據(jù)庫引擎對提升數(shù)據(jù)庫和閃存性能很重要。

RocksDB一種專為閃存設(shè)計(jì)的數(shù)據(jù)庫

針對閃存的物理特性，出現(xiàn)了一批新型數(shù)據(jù)庫，知名度和使用最廣泛的是RocksDB，從LevelDB發(fā)展而來的KV數(shù)據(jù)庫。RocksDB特點(diǎn)是對于WAL日志只會append，對于已經(jīng)落盤的數(shù)據(jù)文件不會修改，這是針對閃存特性做的設(shè)計(jì)。

RocksDB存儲結(jié)構(gòu) (來源[4])

RocksDB特點(diǎn)是數(shù)據(jù)先寫內(nèi)存的memtable，當(dāng)memtable寫滿后會被鎖定變成immutable memtable禁止修改，F(xiàn)lush線程會把immutable memtable刷到盤上。Rocksdb盤上文件是分層的，Level 0, Level 1…Level N, Level 0的文件最新，Level 1的次之，依次類推。????Compaction過程：參看上圖，上層Level中sst文件數(shù)量達(dá)到指定數(shù)量，會執(zhí)行壓縮功能，把多個(gè)sst文件進(jìn)行去舊壓縮合并成新的sst文件并寫入到下層Level，這些被合并的sst文件會被刪除。

RocksDB的性能優(yōu)化，一個(gè)memtable大小超過配置的write_buffer_size大小，會被標(biāo)記為immutable memtable，當(dāng)所有memtable包括immutable memtable數(shù)量達(dá)到max_write_buffer_number時(shí)，此時(shí)Rocksdb將會停止寫入，直到Flush線程把immu memtable刷到disk后，寫入才能繼續(xù)。因此當(dāng)通過iostat看到盤有較長空閑時(shí)間時(shí)，那么增大max_write_buffer_number減少盤的空閑時(shí)間，可降低寫失速現(xiàn)象。????增加max_background_flushes刷盤線程數(shù)量也會提升寫入速度。由于每次寫操作都會先寫wal日志，所以關(guān)閉wal對寫性能有一定提升，但是會導(dǎo)致宕機(jī)后數(shù)據(jù)丟失的風(fēng)險(xiǎn)，一般wal都會開啟。

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

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

ZenFS為ZNS + RocksDB設(shè)計(jì)的用戶態(tài)文件系統(tǒng)

ZenFS由Western Digital主導(dǎo)，ZenFS可以作為一個(gè)plugin編譯進(jìn)RocksDB，作為RocksDB的backend filesystem，封裝對ZNS塊設(shè)備的管理操作。ZenFS依賴libzbd管理和獲取ZNS的Zone信息，讀寫塊設(shè)備時(shí)通過pread、pwrite系統(tǒng)調(diào)用，并且專門針對ZNS實(shí)現(xiàn)了一個(gè)簡易的用戶態(tài)文件系統(tǒng)。

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

性能對比

最后，給出一組RocksDB+ZenFS環(huán)境下實(shí)測數(shù)據(jù)[1]，當(dāng)后臺寫無限制時(shí)，ZNS SSD寫性能是傳統(tǒng)盤的2倍；同樣后臺寫無限制時(shí)，ZNS SSD 99.99%讀時(shí)延是傳統(tǒng)盤的1/4。

RocksDB+ZenFS+ZNS SSD vs 傳統(tǒng)盤性能對比

展望

當(dāng)前ZNS應(yīng)用生態(tài)仍然有較大優(yōu)化空間，比如在對盤上數(shù)據(jù)組織方面，由于上層用戶數(shù)據(jù)可能被覆蓋寫入，必然會出現(xiàn)ZenFS中的extent數(shù)據(jù)塊變?yōu)闊o效，導(dǎo)致盤上Zone空間出現(xiàn)無效數(shù)據(jù)，雖然RocksDB通過Compaction可以丟棄無效數(shù)據(jù)，但這些無效數(shù)據(jù)在一段時(shí)間內(nèi)占用了Zone空間，造成一定程度的空間放大。未來同對ZenFS數(shù)據(jù)管理邏輯的進(jìn)一步優(yōu)化，降低空間放大效應(yīng)，對Compaction壓力將會起到積極的作用。

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

ZNS的寫入方式消除了盤上GC這一阻礙企業(yè)級SSD獲得更好Latency QoS的主要障礙，有充足的理由對包括內(nèi)核、文件系統(tǒng)、數(shù)據(jù)庫等上層應(yīng)用做更深入的優(yōu)化。

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

另外通過從內(nèi)核NVMe驅(qū)動導(dǎo)出專門的API，向應(yīng)用直接暴露Zone空間，用戶利用io_uring或SPDK等可以從內(nèi)核態(tài)或用戶態(tài)直接操作ZNS設(shè)備，向上提供更大的靈活性。

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

引用：

[1]《ZNS: Avoiding the Block Interface Tax for Flash-based SSDs》@USENIX ATC 2021

[2] SSDFans: 可可讀OpenChannelSSD之六_從OpenChannelSSD到ZNS (ssdfans.com)

[3] SSDFans: 一張圖了解Open-Channel SSD 2.0 (ssdfans.com)

[4] COONOTE: rocksdb原理與實(shí)現(xiàn)-菜鳥筆記 (coonote.com)

[5] CSDN: ZNS : 解決傳統(tǒng)SSD問題的高性能存儲棧設(shè)計(jì)（fs--＞io--＞device）_z_stand的博客-CSDN博客_ssd設(shè)計(jì)