GlusterFS企业级功能之EC纠删码

10、EC卷的性能总结
相同EC配置下Distributed-Disperse卷比Disperse卷具有更好的IO性能；相同disperse-data个数的Disperse卷的性能相近；相同冗余配置的EC卷比复制卷具有更大的空间利用率,但读写性能均比复制卷略差；相对于分布式复制卷,Distributed-Disperse卷的优点是具有较高的磁盘利用率和容错性,但是其IOPS性能下降较多.
在配置为1 x (2+1)的disperse卷中任意挂掉一个brick后,不影响数据的正常访问；数据的修复是通过计算其他两个节点中的brick来修复的；在修复100G数据时,替换brick用时约2.2秒,但是发现替换成功后新的brick中并没有数据,需要同步访问来触发才能修复数据；修复100M 数据,则不需要同步访问来触发修复；EC卷的稳定性良好,测试过程无报警.

(二)EC性能测试

1、测试环境

2、测试工具

IOzone,文件系统测试基准工具,可以测试不同操作系统中文件系统的读写性能.主要测试文件系统的write、re-write、read、re-read、random read、random write等性能.注意：在单进程的测试中,测试文件的大小一定要大过内存的大小(最佳值为内存大小的两倍),否则linux会给读写的数据进行缓存,从而造成测试数值不准确.

3、测试方法
搭建3个节点的glusterfs集群,创建6x(2+1)的Distributed Dispersed卷,启动卷.在每个节点使用Gluster原生协议本地挂载卷,然后分别在每个节点中使用测试工具iozone,测试进程数为4、块大小为512KB、文件大小为16GB时,EC卷的读写性能,测试命令为：

# ./iozone -s 16g -r 512k -i 0 -i 1 –t 4.

4、测试结果

5、测试总结
在配置为6x(2+1)的Distributed-Disperse卷测试中,无论是写性能,还是读性能,都达到了1GB/s,特别是写性能更是高达1.5GB/s.由此得出,EC卷是可以满足企业对于性能的一般需求的,是可以在实际环境中使用的.

(三)EC配置推荐

基于Glusterfs搭建的集群中,创建EC卷推荐以下几种配置：
a. 冗余度为1,推荐创建配置为(2+1) EC卷；
b. 冗余度为2,推荐创建配置为(4 +2) EC卷；
c. 冗余度为3,推荐创建配置为(8 +3) EC卷；
d. 冗余度为4,推荐创建配置为(8 + 4) EC卷.
由于在相同的EC配置下,Distributed Disperse卷比Disperse卷具有更好的IO性能,所以推荐在硬盘数量足够的情况下创建Distributed Disperse卷.

在底层的配置中,推荐逻辑盘(如/dev/sda)不分区直接格式化为块大小512B的XFS文件系统,且逻辑盘与brick是一一对应的关系；推荐有n个节点,B就等于n,即同一组的Disperse卷配置中,一个brick对应一个节点.比如,三个节点的gluster集群就推荐创建配为(B=3,R=1)的EC卷,每组Disperse卷配置中,一个brick对应一个节点.

五、EC卷的优化方向

对于如何优化EC卷的性能主要在于以下几点：一是如何提高编/解码的速度；二是如何提高编码速度的稳定性；三是EC卷参数的可配置；四是如何降低修复的开销.

其中如何提高编/解码的速度是最重要,也是最基础的一点.编/解码的运算速度主要依赖于分布式系统的计算能力以及网络速度,那么可以从三个方面来提高.第一,服务器硬件性能的升级；第二,网络环境的升级；第三,则是使用成熟的库来加速RS码的计算速度,如Intel ISA-L库、Jerasure库等.虽然从这三个方面都能够提高纠删码的编/解码的速度,但其中服务器硬件性能的升级以及网络环境的升级都会增大企业的成本,所以推荐使用第三中方式,即使用成熟的库来提高编/解码的运算速度.其中Jerasure库早已成为开源Ceph分布式存储系统的默认纠删码库,相对于ISA-L库,Jerasure库在这一点上具有一定的先天优势,所以在Gluster存储中推荐使用Jerasure库来加速EC卷的编/解码速度.除了以上几点外,还可以从分布式集群这一特性入手,分布式集群存储中单一节点的计算能力不算很好,但如果能让集群中每个节点协同完成编/解码的计算,就能够拥有足够的计算能力,集群中节点越多,集群的计算能力越强,编/解码的运算速度也就越快,相应的EC卷性能也就越好.

编码策略在理论范围内可随意切换,即参数可配置,可以大大降低了后续的开发和维护所需要的精力.在Gluster存储中,EC卷的性能会随着chunk的大小改变而改变,那么实现chunk大小的参数可配置就显得尤为必要了.实践中,得知chunk的大小等于Fragment_size*(B-R),但其中R的大小在Disperse卷创建之后就确定,且不可修改；而Fragment_size在GlusterFS的源码中又是一个宏定义,其大小等于EC_METHOD_WORD_SIZE * EC_GF_BITS = 64*8 = 512 bytes,这也就是说chunk的大小在disperse卷创建成功后就不可修改,而这极大降低了EC卷在实际应用中的灵活度,例如根据数据的冷热程度和数据重要程度选择不同冗余配置、根据存储文件的大小调整底层块大小从而提高性能等.

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!