Zoned Namespace: NVMe Spec对标Open-Channel的解决方案(上篇)

作者简介:刘孝冬,资深工程师 ,主要从事SPDK以及ISA-L软件开发工作

本文转载自DPDK与SPDK开源社区

背景

在大数据和云环境不断发展的前提下,时延(latency) 和QOS(quality of service, 服务质量)成为评价固态硬盘性能更为重要的标准。

多种KV (Key-Value, 键值)应用承载着众多信息时代数据存储与使用的需求。不管KV应用是什么样的I/O模型或者处理多小的I/O请求,每一个I/O都希望从固态硬盘上得到一个最及时的响应。这意味着在KV应用场景下,只有请求响应的延迟都很低,才能够体现出整个系统的低延迟。

随着单块固态硬盘容量越来越大,一块4TB、8TB,甚至更多。在云环境下,一个用户用不到这么大的容量,就会出现两个或多个用户共用一块盘的场景。这时候因为当多个应用同时在使用一块盘,会对对方有一些干扰。在应用共享SSD的时候,应用之间干扰造成延时忽高忽低,最坏时延巨幅升高。 保证为每一个硬盘用户提供稳定的服务质量,才能体现出云环境的服务质量。

Open-Channel的优势与缺点

Open-Channel被选中,用以控制 QoS 和延迟。Open-Channel将本来位于NVMe SSD上Firmware中的对Flash管理和控制的部分功能,交给了Host上的应用软件。让应用根据自身的业务特点,对盘上的Flash进行有效的管理,如图1与图2所示。很多情况下,Host上应用的管理,可以避免在垃圾回收等各类对前端应用IO请求的影响。

Figure 1 普通NVMe SSD软件功能

Figure 2 Open-Channel SSD软件功能

以此同时,Open-Channel向Host展示出内部NAND布局的细节,Host可以决定数据实际存放的物理位置。这样,Host就可以根据IO请求的发起方,将IO 数据写到不同的位置,实现不同应用、用户数据的物理隔离,达到更好的QOS效果,如图3所示。

Figure 3 Open-Channel SSD 的数据隔离

但就从实际应用的部署情况来看,Open-Channel的使用者需要实现一个复杂的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的发展速度。

NVMe工作组为改善延迟和QOS上做了诸多努力,例入新近加入的Multi-Stream,以及计划中的IOD(I/O Determinism), NVM set 与 Endurance Group。但与Open-Channel相比,对定制化应用和工作负载的需求,依旧欠缺灵活性。例如, KV类应用所面临的Log-on-log问题,如图4所示,在KV应用,文件系统以及NVMe通用SSD盘内部都各自维护了一份Log,冗余的Log显著的降低了整个存储软件栈的性能:

Figure 4 Log-on-log issue for KV,like RocksDB.
(1. KV, 2. VFS, 3. NVMe SSD)

Zoned Namespace

Zoned Namespace(ZNS)是NVMe工作组为增加对定制化需求提供灵活性,而计划加入NVMe协议的新特性。

相对于正常的NVMe Namespace, Zoned Namespace将一个Namespace的逻辑地址空间切分成一个个的zone。如图5所示,zone是Namespace内的一种固定大小的子区间。每个zone都有一段LBA(Logical Block Address, 逻辑地址空间)区间,这段区间只能顺序写,而且如果要覆盖写,则必须显示的进行一次擦除操作。这样,namespace就可以把NAND内部结构的边界透露给外界。NVMe SSD也就能够将地址映射表等内部管理工作交由host去处理,从而减少写放大、选择合适的GC(Garbage Collection, 垃圾回收)时机。

Figure 5 Zone and Zoned Namespace

Zone的基本操作有Read, Append Write,Zone Management 以及Get Log Page,如图6所示。Zone大小可以采用Open-Channel中Chunk的大小为单位,即与NAND介质的物理边界为单位。Zone Log Page也会与Open-Channel Spec 2.0中的Chunk Info Log相似。

Figure 6 Basic Zone Operations

与Open-Channel相比,最大的区别就是在Zoned Namespace中,Zone的地址是LBA(Logical Block Address, 逻辑块地址),如图7所示。Zone X的起始地址与Zone X-1的结束地址相连,Zone X的结束地址与Zone X+1的起始地址相连。Zone的容量总是小于等于Zone的逻辑大小。这样一来,Zone Namespace就可以避免Open-Channel里繁琐的各类地址转换。

Figure 7 Zone的地址与容量

上篇结语

通过对Zoned Namespace的认识,可以看做它是NVMe Spec对Open-Channel消化吸收。事实上,NVMe 工作组里Zoned Namespace 这个TP(Technical Proposal, 技术提案)的主要起草者,就是Open-Channel Spec的作者。

此篇文章初步介绍了Zoned Namespace的由来和概况,后面,我们将会继续介绍Zoned Namespace的设计考量,状态模型,软件生态以及SPDK支持Zoned Namespace的计划。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/23077.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于19-03-28
0