业界支持不了的块EC，XSKY星辰天合是如何搞定的-DOIT-数据产业媒体与服务平台

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

其中，在XSKY 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刷盘技术保证大压力下性能平稳。