全国统一服务电话 400-108-0268

关于霄云科技

简述分布式存储中本地存储引擎

发布时间:2021-12-14 来源:本站

最近几年存储介质得到了高速发展,单位存储介质的性能越来越高,从原来的机械硬盘不足 100 IOPS 到现在的 NVMe SSD 一块就能达到 50W IOPS,但与之形成反差的是 CPU 的速度提升并没有那么多,根据 Red Hat 的相关数据统计,存储介质由原来的单盘几十 IOPS 到现在的单盘 50 万 IOPS,但是 CPU 的主频增长的速度相对并没有那么快,而不同的存储介质每个 IO 需要的 CPU 时钟周期也各不相同,如在 HDD 中一个 IO 需要 2000 万时钟周期,在 NMVE 设备中只需要 6000 时钟周期。

简述分布式存储中本地存储引擎 


▲图表及数据均来源于Red Hat

With a cpu clocked at 3ghz you can afford:

HDD: ~20 million cycles/IO

SSD: 300,000 cycles/IO

NVMe: 6000 cycles/IO

在这样的背景下,对于存储软件来说能否发挥出存储介质的高性能,其关键是如何高效利用 CPU,其中,单核 CPU 能够提供的 IOPS,是存储系统的一个关键指标。

而分布式存储作为当前存储系统的一个重要分支,其软件定义的特征,能够更好更快地适配新硬件的发展,成为了存储领域的热点。

我们先简单地聊聊分布式存储中开源领域在适配新硬件的进展,而说到开源的分布式存储,我们一定会想到明星开源项目 Ceph,它在国内外都被广泛使用,其良好的扩展性和稳定性也获得大家一致认可。

在 Ceph 的迭代发展中,其本地存储引擎 ObjectStore 也经过了两代的发展,由最初的 FileStore,到现在广泛使用的 BlueStore,但是这些存储引擎对于高性能的存储介质(如 NVMe SSD 等)都存在一定的不足。

所以 Ceph 社区也在 2018 年提出了新一代本地存储引擎 SeaStore,对细节感兴趣的读者可以访问 https://docs.ceph.com/docs/master/dev/seastore/。

下面笔者根据个人的理解对 SeaStore 的设计做一个简单解读。

SeaStore 的设计目标

面向NVMe 设计,不考虑 PEME 和 HDD。

使用SPDK 实现用户态 IO。

使用Seastar 框架进行基于 future&promise 的编程方式实现 run-to-completion。

结合Seastar 的网络消息层实现读写路径上的零(最小)拷贝。

对于目标 1、2,面向 NVMe 的设计,笔者认为主要是指当前的 NVMe 设备是可以使用用户态驱动的,即可以不通过系统内核,使用 Polling 模型能够明显降低 IO 延时。

同时对于 NVMe 设备来说,由于其 erase-before-write 特性带来的 GC 问题需要被高效解决,理论上通过 discard 作为一种 hint 机制可以让上层软件启发底层闪存去安排 GC,但实际上大部分闪存设备的 discard 实现的并不理想,因此需要上层软件的介入。

对于目标 3、4,是从如何降低 CPU 的角度去考虑底层存储设计的,如上文中也提到对于高性能的分布式存储,CPU 会成为系统瓶颈,如何提高 CPU 的有效使用率是一个重点考虑的问题。

目标 3 中采用 run-to-compleTIon 的方式能够避免线程切换和锁的开销,从而有效提高 CPU 的使用率,Intel 曾经发布报告说明,在 Block Size 为 4KB 的情况下,单线程利用 SPDK 能够提供高达 1039 万 IOPS,充分说明了使用单线程异步编程的方式能够有效提升 CPU 的使用率。

而目标 4 则需要充分结合网络模型,一致性协议等,实现零拷贝,来降低在模块中内存拷贝次数。

基于 SeaStore 的设计目标,具体的设计方案中主要考虑了通过 segment 的数据布局来实现的 NMVE 设备的 GC 优化,以及上层如果控制 GC 时的相关处理,同时在文档中也提到了用 B-tree 的方式实现元数据的存储,而没有采用类似 bluestore 中使用 RocksDB 来存储元数据的方式。

但是笔者认为,这个设计对于实现的难度可能比较高,当前的 rados 不仅仅是存储数据还有大量的元数据存储的功能。如 OMAP 和 XATTR,这些小的 KV 信息实际如果采用新写一个 B-tree 的方式进行存储,那相当于需要实现一个专有的小型 KV 数据库,这个功能实现难度会非常大,而类似直接使用简单的 B-tree 存储元数据就会落入类型 XFS 等文件系统存储元数据的困境,不能存储大量 xattr 的问题。

上文中只是简单的描述的 Ceph 对下一代存储引擎的设计构思,如果想等到具体的开源来实现估计还需要个 3 到 5 年的开发周期。

而我们对高性能分布式存储的需求又非常热切,所以深信服存储团队就独立设计了一个全新的存储引擎来满足高性能分布式存储的需求。

下面我们简单介绍深信服企业级分布式存储 EDS 团队在高性能本地存储的实践之路。

关键词标签:海量存储 文件存储 分布式存储 国产存储 私有云 企业级存储 软件定义存储

返回列表
上一篇:数据库中的行列存储区别介绍
下一篇:中国存储实力 江波龙持续打造存储品牌