前言
正在加速数字化转型升级的政企机构，对于数据的刚需不仅仅是安全可靠，还有能够带来高性能\低成本、绿色低碳、便捷管理的先进技术始终能够贯穿于数据的全生命周期。一个半月前，XSKY星辰天合发布了企业级软件定义存储 XSKY SDS V5系列，通过底座升级、全场景延伸、全生命周期管理，再次定义统一存储，打造全协议统一、全场景统一的数据管理平台。
自今日起，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刷盘技术保证大压力下性能平稳
【图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，实现了可靠性、性能和经济性三者兼顾。