正在加速数字化转型升级的政企机构,对于数据的刚需不仅仅是安全可靠,还有能够带来高性能 \ 低成本、绿色低碳、便捷管理的先进技术始终能够贯穿于数据的全生命周期。一个半月前, XSKY 星辰天合发布了企业级软件定义存储 XKSY SDS V5 系列,通过底座升级、全场景延伸、全生命周期管理,再次定义统一存储,打造全协议统一、全场景统一的数据管理平台。
自今日起, XSKY 星辰天合技术专家将全面解析 XKSY SDS V5 的技术细节,以期能进一步为政企机构数字化转型升级提供高性能低成本的数据存储、管理技术和方案,同时推动行业的高质量发展。
其中,在 XKSY SDS V5 底座升级方面,取得技术突破,可以采用 EC 纠删码的 XSpeed ,相比副本方式,得盘率从 33% 提升至 80% ,同时保持平稳输出。
EC 的得盘率比三副本高, XSKY SDS V5 版本已经支持块存储场景使用 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 。
下面图片列举了不同情况下的读写操作流程。
假设 EC 4+2 的分片数据块大小是 32KB ,下面是不同数据块大小的读写请求所消耗的 IO 次数和带宽,消耗倍数越多,性能越差。
由此我们可以得出 EC 和三副本的性能对比,可以看到 EC 在小块随机读写的性能比三副本差,但是 EC 在大块顺序写的性能比三副本要好很多。
假设 EC 4+2 , EC 分片数据块大小是 32KB 。假设写入的文件 / 对象大小都是小于 128KB ,则存在空间浪费。假如平均文件大小是 64KB ,则会浪费 50% ,假如平均文件大小是 32KB ,则会浪费 75%
从上可知 EC 的三大缺点是:
我们已经知道了 EC 的三大缺点,那么在块存储应该如何使用 EC 呢?
块存储承接的场景很多,包括虚拟化、云平台、数据库等。这些场景会产生非常多的小块随机读写负载(特别是虚拟化平台,俗称 IO 搅拌机),这就要求块存储系统需要支持万级别的小块随机读写 IOPS ,并且时延要在 5ms 级别内,这正好是普通 EC 的缺点,应该如何解决呢?
目前对于块存储使用 EC ,有三种方案来解决。
vSAN 支持 EC ,但仅支持在全闪配置下使用 EC ,属于硬刚 EC ,也就是要使用硬件 SSD 的性能去弥补 EC 的性能缺点。
社区版 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 架构。
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 失败的原因包括:
如何在基准测试中快速验证社区 Ceph 的 Cache Tiering 的问题呢?假设 Ceph 存储池中, Cache Pool 是 1TB 可用容量, Backend Pool 是 60TB 可用容量。则可以通过以下方式进行快速验证:
在表 2 中,我们看到了三副本和 EC 的性能对比,想同时拥有三副本和 EC 的好处,应该怎么办?怎么才能解决 EC 小块随机写性能差的问题呢?我们设计和开发了 XSpeed 架构,三管齐下:
【图 9 :“永远不会被击穿的 Cache ”—— Log Append 刷盘技术】
XSpeed 分层技术消灭了随机小块写,兼顾高性能与经济性:
我们设计和开发的 XSpeed 存储池,搞定了块存储 EC ,并且可以更好支持 QLC ,包括以后的 SMR HDD 。 XSpeed 技术升级了 XSKY SDS V5 版本的底座,满足了全场景 EC ,实现了可靠性、性能和经济性三者兼顾。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞0
添加新评论0 条评论