從Open-Channel到ZNS

緣起：Open-Channel

01

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

傳統(tǒng)的NVMe SSD，對于上層的系統(tǒng)來說，是一個通用型的塊設(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)化。這些缺點并不是由于硬件限制引起的，而是傳統(tǒng)NVMe SSD設(shè)計決定的。這時候，一種新的想法Open-Channel開放接口SSD產(chǎn)生了，顧名思義，開放接口把SSD底層接口開放給主機，這樣做有什么好處呢？

· 主機控制權(quán)

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

· I/O隔離

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

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

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

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

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

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

普通NVMe SSD架構(gòu)

Open-Channel SSD架構(gòu)

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

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

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

· Chunk

Chunk是指一系列連續(xù)的邏輯塊。在一個Chunk內(nèi)，主機側(cè)只能按照邏輯塊地址LBA順序?qū)懭?，如果要重新寫入前面寫過的某個邏輯塊，需要重啟該邏輯塊所在的Chunk。

Chunk示意圖

· 并行單元（Parallel Unit，PU）

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

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

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

Chunk和PU邏輯拓撲圖如下：

Open-Channel SSD邏輯拓撲圖

·很多Chunk組成了PU；

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

·很多Group組成了SSD。

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

LBAEncoding格式

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

當(dāng)前全球市場，實現(xiàn)了Open-Channel SSD商用的廠商只有Shannon Systems。部分互聯(lián)網(wǎng)頭部廠商基于Shannon Systems的代碼和產(chǎn)品定制化自己的Open-Channel SSD產(chǎn)品用于業(yè)務(wù)效能提升。

進化：ZNS更進一步

02

2.1Open-Channel SSD的缺點

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

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

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

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

最后為了規(guī)避上述問題，有沒有可能既可以做到允許主機側(cè)盡量自由擺放數(shù)據(jù)，同時有標(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中的成本舉足輕重；

·增加帶寬，減少時延。

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

2.2ZNS實現(xiàn)模型

Zoned Namespace NVME Spec起草作者和Open-Channel SSD Spec作者是同一人，兩個標(biāo)準(zhǔn)有很大的相似性，所以ZNS可以說是Open-Channel的進化，是在Open-Channel基礎(chǔ)上更加商業(yè)化和標(biāo)準(zhǔn)化的實現(xiàn)。

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

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)點：

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

機械硬盤中文件系統(tǒng)可以直接將新數(shù)據(jù)寫入到舊數(shù)據(jù)存儲的位置，可以直接覆蓋舊數(shù)據(jù)。在固態(tài)硬盤中，如果想讓某個存有無效數(shù)據(jù)的塊寫入新數(shù)據(jù)，就需要先把整個塊擦除，才可以寫入新的數(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ū)憽o覆蓋寫因此GC操作比Open Channel更高效可控, 從而性能也比較穩(wěn)定。

· 延遲可預(yù)測

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

· 減少OP

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

· 成本更低

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

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

ZNSvs傳統(tǒng)SSD展現(xiàn)的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

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

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

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

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

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

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

ZNS生態(tài)探索：

RocksDB + ZenFS + ZNS SSD

04

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

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

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

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

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

RocksDB特點是數(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ù)量達到指定數(shù)量，會執(zhí)行壓縮功能，把多個sst文件進行去舊壓縮合并成新的sst文件并寫入到下層Level，這些被合并的sst文件會被刪除。

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

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

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

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

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

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

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

4)性能對比

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

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

展望

05

當(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ù)在一段時間內(nèi)占用了Zone空間，造成一定程度的空間放大。未來同對ZenFS數(shù)據(jù)管理邏輯的進一步優(yōu)化，降低空間放大效應(yīng)，對Compaction壓力將會起到積極的作用。

對于Compaction過程，我們正在探索以Copyback方式實現(xiàn)數(shù)據(jù)直接在盤內(nèi)轉(zhuǎn)移，降低RocksDB的負載，提高用戶數(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è)計的基于ZBD設(shè)備的文件系統(tǒng)，其讀寫方式也有機會稍做修改，從而應(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，這是一個IO Interface抽象層，提供了多種支持ZNS設(shè)備的內(nèi)核IO Interface，包括Linux和Windows版本。開發(fā)者可以面向xNVMe提供的API進行上層應(yīng)用開發(fā)，而不必關(guān)心設(shè)備訪問實現(xiàn)細節(jié)，同時只要修改xNVMe配置即可實現(xiàn)不同操作系統(tǒng)的兼容。在xNVMe的基礎(chǔ)上，以FlexAlloc作為Backend，向RocksDB提供對象分配器，使得RocksDB可以直接運行在ZNS裸設(shè)備上，相比目前商用SSD方案，有希望獲得更好的性能體驗。

審核編輯 ：李倩