XSKY星辰天合
作者XSKY星辰天合2021-09-17 14:07
技术支持, XSKY星辰天合

为什么业界很少支持块EC?性能搞不定啊!

字数 4622阅读 1402评论 0赞 0

前言

正在加速数字化转型升级的政企机构,对于数据的刚需不仅仅是安全可靠,还有能够带来高性能 \ 低成本、绿色低碳、便捷管理的先进技术始终能够贯穿于数据的全生命周期。一个半月前, XSKY 星辰天合发布了企业级软件定义存储 XKSY SDS V5 系列,通过底座升级、全场景延伸、全生命周期管理,再次定义统一存储,打造全协议统一、全场景统一的数据管理平台。

自今日起, XSKY 星辰天合技术专家将全面解析 XKSY SDS V5 的技术细节,以期能进一步为政企机构数字化转型升级提供高性能低成本的数据存储、管理技术和方案,同时推动行业的高质量发展。

其中,在 XKSY SDS V5 底座升级方面,取得技术突破,可以采用 EC 纠删码的 XSpeed ,相比副本方式,得盘率从 33% 提升至 80% ,同时保持平稳输出。

EC 的得盘率比三副本高, XSKY SDS V5 版本已经支持块存储场景使用 EC ,但目前分布式块存储场景直接使用 EC 的还非常少,这为什么?我们先从 EC 的原理说起。

EC的原理

大家知道三副本的得盘率是 33.3% , EC 4+2 的得盘率是 66.6% , EC 8+2 的得盘率是 80% ,但 EC 具有高得盘率的同时也有很多性能缺点。

纠删码( Erasure Coding , EC )是一种编码容错技术,最早用在通信行业解决部分数据在传输中的损耗问题。在数据存储中,纠删码将数据分割成片段,并生成校验数据块片段,将其存储在不同硬盘上。从纠删码的形态看,它是 K 个数据块和 M 个校验块的结构,其中 K 和 M 值可以按照一定的规则设定,可以 N=K+M 公式来表示。变量 K 代表原始数据。变量 M 代表校验数据。变量 N 代表纠删码过程后创建的数据的总值。当小于或等于 M 个存储块(数据块或校验块)损坏时,整体数据块可以通过计算剩余存储块上的数据得到,整体数据不会丢失。

下面以 K=4 , M=2 为例,介绍一下如何以纠删码的形式将一个名称为 test.obj 的对象(大小为 128KB )存放在分布式存储系统中,假定该对象的内容为 A1~A4B1~B4C1~C4D1~D4 ,客户端在将 test.obj 上传到分布式存储系统以后,主 OSD 会使用相应的纠删码算法对数据进行编码计算:将原来的 A1~A4B1~B4C1~C4D1~D4 拆分成 4 个分片,之后再计算出另外两个校验条带分片(内容为 P1~P4Q1~Q4 ),然后按照数据分布算法,将这 6 个分片分布在 6 个不同的 OSD 上面,完成对这个对象的写入操作。每个分片数据块大小是 32KB 。

下面图片列举了不同情况下的读写操作流程。


【图 1 :满条带写】


【图 2 :满条带读】


【图 3 :非条带读】


【图 4 :非条带写】


【图 5 :有硬盘故障时的满条带读】


【图 6 :有硬盘故障时的非条带读】

EC和三副本的读写消耗对比

假设 EC 4+2 的分片数据块大小是 32KB ,下面是不同数据块大小的读写请求所消耗的 IO 次数和带宽,消耗倍数越多,性能越差。

【表 1 : EC 和三副本的读写消耗对比】

EC和三副本的性能对比

由此我们可以得出 EC 和三副本的性能对比,可以看到 EC 在小块随机读写的性能比三副本差,但是 EC 在大块顺序写的性能比三副本要好很多。

【表 2 : EC 和三副本的性能表现对比】

假设 EC 4+2 , EC 分片数据块大小是 32KB 。假设写入的文件 / 对象大小都是小于 128KB ,则存在空间浪费。假如平均文件大小是 64KB ,则会浪费 50% ,假如平均文件大小是 32KB ,则会浪费 75%

从上可知 EC 的三大缺点是:

  • 小块随机写的 IO 消耗很大,导致在 HDD 配置下性能很差。
  • 对于小文件场景,空间浪费严重。
  • 小块随机读在命中故障盘情况下的 IO 消耗很大,导致在 HDD 配置性能很差。

我们已经知道了 EC 的三大缺点,那么在块存储应该如何使用 EC 呢?

块存储该如何使用 EC

块存储承接的场景很多,包括虚拟化、云平台、数据库等。这些场景会产生非常多的小块随机读写负载(特别是虚拟化平台,俗称 IO 搅拌机),这就要求块存储系统需要支持万级别的小块随机读写 IOPS ,并且时延要在 5ms 级别内,这正好是普通 EC 的缺点,应该如何解决呢?

目前对于块存储使用 EC ,有三种方案来解决。

第一种, vSAN

vSAN 支持 EC ,但仅支持在全闪配置下使用 EC ,属于硬刚 EC ,也就是要使用硬件 SSD 的性能去弥补 EC 的性能缺点。

【表 3 : vSAN 如何解决 EC 的问题】

第二种, Ceph Cache Tiering

社区版 Ceph 的 Cache Tiering 的初衷很好,是希望通过增加新的一层的办法,也就是分层架构 ( 三副本 SSD 存储池 + EC HDD 存储池 ) 来规避 EC 的缺点,充分利用 EC 的优点。

但社区版 Ceph 的 Cache Tiering 架构的设计有很多问题没有考虑到,导致无法在生产环境中使用。已经有很多案例证明,社区版 Ceph 的 Cache Tiering 在块存储生产环境上出现问题。

• 目前 Ceph 社区不建议在块存储上使用 Cache Tiering ,因为它有严重的性能问题,相关链接是 https://docs.ceph.com/en/latest/rados/operations/cache-tiering/#known-bad-workloads

• RedHat 也早就声明已弃用 Cache Tiering 功能,因为该功能不会为大多数 Ceph 工作负载提供任何性能改进,并且在在使用时会给集群带来稳定性问题,相关链接是 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2.0/html/release_notes/deprecated_functionality

下面我们来讲讲 Ceph 的 Cache Tiering 架构。


【图 7 : Ceph Cache Tiering 架构】

Cache Tiering 有四种模式:

【表 4 : Ceph Cache Tiering 的四种模式】

因为在 Cache Tier 和 Storage Tier 之间的数据迁移的粒度是 4MB ,当一个对象在做数据迁移时,至少需要等待 1~2 秒以上。那么依赖于数据迁移的小块读写请求就阻塞 1~2 秒。

只有当工作负载局部性很高并且是确定性的,这样大多数请求都只是访问少量对象时,则 Cache Tiering 才会有效。或者是 Cache Pool 足够大,能够保证大多数的读写请求都能够命中 Cache ,才能避免性能抖动。

但这导致 Cache Tiering 非常不实用,因为要高度依赖于工作负载模式 ( 有确定性的热数据集 ) 。但是大部分场景的热数据集是在不断变化的,这使得 Cache Tiering 在实际场景中的性能很糟糕, IOPS 会急剧跌落,并出现秒级别的时延。

而且 Cache Tiering 的另外一个缺点是配置复杂,学习成本高,用户需要很好地了解他们的工作负载,并且需要仔细调整缓存分层参数。

社区 Ceph 的 Cache Tiering 失败的原因包括:

  • 把重心放在 Tiering( 数据迁移 ) ,数据迁移的粒度是整个对象 (4M) ,迁移成本非常高。
  • 数据迁移和刷盘的触发机制太敏感 ( 太简单 ) ,导致性能剧烈抖动。

如何在基准测试中快速验证社区 Ceph 的 Cache Tiering 的问题呢?假设 Ceph 存储池中, Cache Pool 是 1TB 可用容量, Backend Pool 是 60TB 可用容量。则可以通过以下方式进行快速验证:

  • 创建 8 个 4TB 的卷。往 20 个卷中填满数据。保证卷的总大小大于 Backend Pool 的 50% ,保证卷的总大小是 Cache Pool 的 10 倍以上。
  • 使用 fio 或 vdbench 对这 8 个卷做 100%LBA 全盘 8K 随机读写 (3:7) ,数据量是 4T 。保证测试的数据集范围大于大于 Backend Pool 的 50% ,保证测试的数据量是 Cache Pool 的 4 倍。
  • 因为是在 32TB 的数据集里面做 100%LBA 的 8KB 随机读写,远远大于 Cache Pool 的容量,因此会导致频繁数据迁移,所以测试结果非常差。

第三种, XSpeed

在表 2 中,我们看到了三副本和 EC 的性能对比,想同时拥有三副本和 EC 的好处,应该怎么办?怎么才能解决 EC 小块随机写性能差的问题呢?我们设计和开发了 XSpeed 架构,三管齐下:

  • 分层: XSpeed 存储池采用全局分层架构,其中数据层可以使用 EC ,同时 Cache 层使用三副本提供高性能的读写能力。并且分层后, Cache 层的硬盘(主要是 SSD )和数据层的硬盘(主要是 HDD )没有绑定关系,换盘更方便。
  • 全局 Cache : Cache 粒度不是整个对象,而是 4~64KB 的数据块,通过智能 Cache 算法,保证写 Cache 刷盘和读 Cache Promote 的精细化控制。
  • LogAppend 刷盘技术: LogAppend 模块可以把随机小块写 IO 聚合成大块顺序写,然后再回刷到数据层中。数据层的大块顺序写性能很高,所以可以快速把脏数据回刷到数据层,腾出 Cache 空间给前端业务使用。对于 EC 数据层,聚合成大块顺序条带写入,不会有写放大问题,性能最高。 LogAppend 模块不仅聚合随机小块,而且还对数据进行压缩和缩减,为用户节省更多空间。 Log Append 刷盘技术保证大压力下性能平稳。


【图 8 : LogAppend 模块示意图】


【图 9 :“永远不会被击穿的 Cache ”—— Log Append 刷盘技术】

XSpeed 分层技术消灭了随机小块写,兼顾高性能与经济性:

  • Cache 层承接小 IO 写性能以及第一级读性能
  • 数据层承接大 IO 读写性能,以及第二级小 IO 读性能,提供持续高性能服务
  • 通过 LogAppend 刷盘写技术,保证写入数据层都是大块顺序写 IO ,充分发挥 HDD 和 QLC SSD 的顺序写吞吐能力
  • 假如数据层采用的是 QLC SSD ,则大块顺序写 IO 保证 QLC SSD 得性能和寿命
  • QLC 层提供稳定的小块 IO 读性能,解决混合场景 Cache 读 miss 带来的性能衰减问题
  • 缓存层和数据层分开,换盘方便,运维简单

XSpeed在混合存储中的优势

【表 5 : XSpeed 在混合存储中的优势】

XSpeed在全闪存储中的优势

【表 6 : XSpeed 在全闪存储中的优势】

总结

我们设计和开发的 XSpeed 存储池,搞定了块存储 EC ,并且可以更好支持 QLC ,包括以后的 SMR HDD 。 XSpeed 技术升级了 XSKY SDS V5 版本的底座,满足了全场景 EC ,实现了可靠性、性能和经济性三者兼顾。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关资料

X社区推广