zhuqibs
作者zhuqibs2020-04-06 20:20
软件开发工程师, Adidas

Ceph不同存储策略的性能对比分析

字数 2993阅读 2534评论 0赞 6

Ceph中有两种数据冗余策略:副本策略和纠删码策略。基于36盘位服务器6节点集群的环境,我们做了一个不同数据冗余策略下性能比较的测试分析。本文将首先简单介绍一本策略和纠删码策略的数据分发机制,随后介绍36盘位6节点集群的测试环境概况,最后放出测试结果以及相关结论。

副本策略的数据分发机制
在Sage A. Weil的论文RADOS:A Scalable. Reliable Storage Service for Petabyte-scale Storage Clusters中,第三节智能存储设备描述了副本策略的三种实现模式:Primary-copy,Chain,Splay。无论具体是那种实现方式,客户端都会将所有I/O操作写入到PG组中的主OSD上,再由主OSD向后分发。当所有副本都更新好后返回确认信息给客户端。在副本策略下,同一个PG内各OSD放置的数据分片是完全一样的(都是一个副本)。

Primary-copy
这种方式的特点为,主OSD在接收到数据后,并行的向同一PG内的从OSD更新副本。当从OSD完成数据更新,确认信息将会返回给主OSD,主OSD确认所有从OSD均已完成写入后,给自己写入数据并返回确认信息给客户端。主OSD负责处理客户端的读操作和写操作。

Chain
这种方式的特点为,主OSD在接收到数据后立即向自己写入,完成后向同一PG内的下一个从OSD写,该从OSD完成后再向下一个从OSD写,依次完成。写请求发送给主OSD,即最头的OSD。读请求发送给最尾部的从OSD,这样能够确保读取操作总是读取那些完全完成副本更新的数据。这种模式有一个比较明显的缺点,那就是时延高。

Splay
这种方式结合了Primary-copy的并行操作与Chain的读写分离。主OSD在接收到数据后,并行分发给同一PG内的其它从OSD,各从OSD完成更新后,将确认信息发给最后一个从OSD,最后一个从OSD在确认PG组内其它OSD都写入完成后为自身写入数据,并由其返回确认信息给客户端。主OSD接收写请求,而最后一个从OSD接收读请求。

纠删码策略的数据分发机制
在官方文档的Architecture部分完整描述了纠删码的实现机理。对于纠删码来说,一个数据会被分片存储。纠删码策略为K+M,K为数据分片数,M为纠删码分片数,对于1体积的数据,其实际占用存储空间为1*(1+M/K)。对于K+M的纠删码策略,可以最多容许M片数据丢失。

在纠删码策略下,主OSD负责接收全部数据,并且负责将数据切片为K块数据块并编码M块纠删码块,对于1体积的数据,这些数据块的大小均为1/K。编码完成后,主OSD负责将这些数据块分发到对应的从OSD中。与副本策略中Primary-copy模式相同的是,各从OSD在完成数据写入后返回确认信息给主OSD,主OSD在确认所有从OSD都已完成数据写入后返回确认信息给客户端。此外,读操作也由主OSD接收执行。

例如,对于4+2纠删码下的PG组[21, 42, 1, 74, 43, 56],OSD21负责接收来自客户端的完整的一份数据,同时把完整的数据编码为4块数据块并计算出2块纠删码块,随后按PG内的顺序依次分发数据块与纠删码块。也就是说,OSD21、42、1、74依次得到了数据块1-4,而OSD43得到了纠删码块1,OSD56得到了纠删码块2。在纠删码下,同一PG内各OSD存放的数据块是完全不一样的。

读取时,主OSD从各个OSD中取得任意K块数据块(无论是数据块还是纠删码块)解码返回给客户端,如图所示。

测试环境与节点规划
测试环境使用6台36盘位服务器组成一个集群,集群部署采用Ceph Jewel版本(v10.2.3)其具有支持跨数据中心、跨机房的数据容灾保护,具有极强的水平扩展能力,提供AWS S3和Openstack Swift API以及个性化工具,支持对象多版本、生命周期等高级特性。单节点硬件配置和各节点规划如下。

测试环境的部署方案为,每6块机械硬盘使用1块SSD作为日志盘,最后每个节点剩下1块SSD用于存放元数据。业务网与存储网各使用一组万兆卡部署。在当前部署方案下,采用0.95的full ratio,实际可用空间为3.7TB3060.95=632TB。若采用三副本策略,则实际可用容量为632/3=210TB;若采用4+2纠删码策略,则实际可用容量为632(4/6)=421TB。(此处不考虑OSD的omap及meta所占用的空间)

测试使用COSBench执行,版本采用的0.4.2.c4。COSBench部署于节点2,这是一个纯OSD节点。读测试与写测试之前,均对全集群执行清缓存处理,使用如下命令:sudo sync && echo 3 | sudo tee /proc/sys/vm/drop_caches

测试结果与结论
测试使用100并发执行,分别测试了512KB文件100万操作和4M文件10万操作,结果如下。显而易见的是,纠删码的性能是比三副本要偏差一些的。从两种数据冗余策略的数据分发过程上也可以看到,纠删码相对于副本而言,多了一个计算与切片的过程。

此外,为了验证纠删码策略集群是否能够平稳运行,我们在6盘组RAID5的基础上执行了一次纠删码策略下100并发4M文件两千万(100万乘20组连续测试)的压力测试,测试以近乎满带宽的方式执行,提前解决了相关由于配置参数不合适而卡住性能的问题并进行了部分优化。测试结果证实纠删码策略集群能够平稳执行。相关测试数据如下。

测试中的问题及相关建议
在正式测试前的预测试中,发现许多影响测试的因素均和36盘位服务器这一基础条件相关。譬如,性能异常降级的问题。在测试中发现,读测试与删测试均会在执行一段时间后急剧降级。

读测试降级主要表现为,读测试在高水平执行约25分钟后急剧降至原有性能的三分之一,删除测试在执行一段时间后集群出现大量慢请求。经分析认为,读测试降级是由于RGW混合部署,内存交换频繁,影响了RGW的正常工作造成。实验发现,当降级发生后,直接在RGW节点执行清缓存指令,性能会立刻恢复正常。之后为RGW节点添加定时清除缓存任务,不再发生这种情况。

删除测试降级则是因为RGW的参数设置不合理。经测算,在满负荷的情况下,集群每小时可以打入三千万甚至更多的删除请求,默认配置rgw gc max objs值32过小。将该参数改大为1024后,不再出现慢请求。

故而,对于36盘位服务器,我们的使用建议是:
——可以使用SSD作为日志与元数据盘,并针对SSD做相关优化,可以考虑优化日志盘大小与下刷间隔相关参数。SSD与机械硬盘的比例视情况调整;
——36盘位服务器仅部署OSD,不部署其它任何组件;
——36盘位服务器可以使用纠删码策略,以充分利用其容量优势,尽可能降低存储成本。在使用纠删码策略的情况下,由于其性能较三副本偏差,故建议将其作为后端存储使用,存放只读数据或冷数据,或用于视频监控等场景。
——36盘位服务器由于单节点容量巨大,若节点宕机,会产生很大的数据恢复压力,这也是建议将36盘位服务器作为后端存储而不是前端存储的重要原因,其不适合压力大的场景。

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

6

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广