Ceph性能优化之路 之 带掉电保护的Rbd Cache方案

 

Ceph是一款开源的统一存储,在单一的系统上提供块、对象及文件存储接口。近年随着公有云/私有云的快速普及,凭借其自身良好的稳定性、扩展性及与Openstack的深度整合,CephRbd块存储被大量的使用,作为VM的数据存储。...



        Ceph是一款开源的统一存储,在单一的系统上提供块、对象及文件存储接口。近年随着公有云/私有云的快速普及,凭借其自身良好的稳定性、扩展性及与Openstack的深度整合,Ceph Rbd块存储被大量的使用,作为VM的数据存储。有Ceph Rbd部署实践经验的IT工程师们对Rbd Cache一定不会陌生,它是Ceph Rbd客户端缓存,开启后能显著提高快设备i/o性能,但是它存在两个问题:

1.   由于以内存作为缓存,缓存空间不能太大

2.   还是因为以内存做缓存,所以存在掉电数据丢失的风险

为了克服原生Rbd Cache存在的上述不足,盛大游戏G云对Rbd Cache进行了改良,我们的方案是:用高速非易失存储介质(如:SSD、SAS)替换内存作为Rbd Cache,通过用空间换时间的方式,保证i/o性能并规避上述的缺陷。下文将对原生Rbd Cache及改良后的方案分别加以说明。

下文称未经修改的Ceph Rbd Cache为原生Rbd Cache,改良后的方案称为G云版Rbd Cache,引用的对象术语及代码片段来自HammerCeph-0.94.1

原生Rbd Cache

根据上述逻辑图,Rbd Cache是Ceph块存储客户端库librbd内实现的一个缓存层,主要提供读缓存和写合并功能,用来提高读写性能,默认情况下Rbd Cache处于开启状态。需要注意的是:Ceph既支持以内核模块方式动态地为Linux主机提供块设备,也支持以Qemu Block Driver的形式为VM提供虚拟块设备,本文描述的是第二种形式。下面我们来看看Rbd Cache的内部实现

上述逻辑图并未完整画出i/o流经的所有组件,还请读者注意。

Rbd Cache的实现机制librbd模块内默认以4MB为单位对虚拟磁盘进行切分,每个4MB的chunk称为一个Object,以ObjectExtent为单位进行数据缓存;应用i/o通常会有不同的大小,每个i/o请求的数据以Object为单位缓存到一个或多个ObjectExtent中。Rbd Cache常用配置参数如下:

·        rbd cache size : librbd能使用的最大缓存大小

·        rbd cache max dirty :缓存中允许的脏数据最大值,用来控制回写大小,不能超过rbd cache size

·        rbd cache target dirty :开始执行回写的脏数据阀值,不能超过rbd cache maxdirty

·        rbd cache max dirty max :缓存中脏数据的最大缓存时间,用来避免因脏数据未达到回写要求而长时间存在

在i/o处理过程中,根据ObjectExtent中的创建数据缓存结构BufferHead或者合并/拆分原有BufferHead得到一个满足当前i/o需求的BufferHead并将i/o数据缓存到该结构中,BufferHead添加到bh_lru_dirty队列。

i/o数据缓存后librbd会立即尝试合并相邻的i/o请求,以提高数据写入性能。并基于配置参数通知flush_thread线程向后端Ceph集群发送i/o数据,i/o请求完成BufferHead从bh_lru_dirty队列移除并添加到bh_lru_rest队列。当缓存数据达到缓存大小限制后,bh_lru_rest队列中的数据会被删除。

下图展示了一个虚拟磁盘Image、应用i/o映射、Object及BufferHead的关系:



上图中磁盘Image逻辑切割为多个Object,每个Object可能包含0到多个BufferHead,每个BufferHead包含一个应用数据片段,如果是脏数据会被加入到bh_lru_dirty队列,如果数据已经下刷到Ceph集群就会加入到bh_lru_rest队列;

正如上一节中所述,librbd将所有的数据都缓存在内存中,如果宿主出现掉电故障,bh_lru_dirty队列中的脏数据将丢失,也就是用户数据丢失。DT时代,数据是企业的核心资产,关键业务数据的丢失会给企业带来不可估量的损坏。为解决该缺陷,盛大游戏G云对原生的Rbd Cache进行了改良。

G云版Rbd Cache

我们的方案是:将Rbd Cache移到高速非易失性存储介质(如:SSD,SAS),每个虚拟磁盘的Rbd Cache是存储介质上的一个文件。多个虚拟磁盘的Rbd Cache可以存储在同一个存储介质上。通过使用更大的磁盘缓存空间,空间换时间思想,实现i/o的高速读写及避免掉电引起的数据丢失。

设计该方案时,我们需要考虑的问题有:

·        如何最大化利用原有的代码框架?

·        如何设计缓存文件的格式?

如何最大化利用原有的代码框架由上文的分析我们知道,librbd内部与i/o紧密相关的结构主要有Object、BufferHead以及bufferlist,Object是虚拟磁盘Image基于固定大小逻辑切分的一个数据块,从0开始编号;BufferHead可以理解为Object内的一个连续数据分片,数据分片大小随机,BufferHead之间的间隔表示空闲空间,由于应用i/o大小不固定,一个BufferHead可能被拆分,相邻的BufferHead也可能被合并;BufferHead中包含的应用数据实际存储在bufferlist标示的内存结构中。三个结构间的关系如下;



有了上述的理论基础,本着最大化利用原有代码的原则,我们设计了如下的磁盘对象与内存对象映射关系:

·        定义ObjectMeta结构,持久存储Object对象信息,并定义相关的转换接口

·        定义BufferMeta结构,持久存储BufferHead对象信息,并定义相关的转换接口

·        bufferlist是承载用户数据的内存区,直接用缓存文件存储用户数据

如何设计缓存文件的格式数据结构映射关系建立起来了,那该按怎样一种方式在缓存文件中组织各种对象,并能实现高效的对象查找、更新呢?由于上层应用i/o的不确定性,缓存层可能就会出现大量的随机操作,缓存层的查找算法效率的高低直接决定了缓存层的性能。从实现的复杂度和效率两个维度考虑,我们最终选择了用bitmap来组织管理各种对象。

再次,从上文的分析我们了解到一个Object对象包含的Bufferhead对象个数是动态变动的,并且每个Bufferhead包含的数据长度也各不一样;换句话说就是,缓存文件中每个ObjectMeta对象包含的BufferMeta对象个数不固定。然而采用bitmap来组织对象,需要预先知道各类对象的个数,这样才能确定bitmap的大小。为了解决这组矛盾,我们引入了一个参数rbd ssd chunk size来表示上层应用i/o的大小。再继续前,让我们先了解下新引入的配置参数:

·        rbd ssd cache : 缓存开关,默认开启

·        rbd ssd chunk size :预设的i/o数据块大小,最小值为16(2^16 = 64KB)librbd基于此值组织缓存文件,不能超过Object大小

·        rbd ssd cache size : librbd能使用的最大磁盘缓存

·        rbd ssd cache max dirty : 缓存中允许的脏数据最大值,用来控制回写大小,不能超过rbd cache size

·        rbd ssd cache target dirty :开始执行回写的脏数据阀值,不能超过rbd cache maxdirty

·        rbd ssd cache path : 缓存文件路径

回到上面的问题,引入rbd ssd chunk size参数后,我们基于如下的公式来确定各对象的个数:

·        ObjectMeta的个数 = rbd ssd cache size/rbd ssd chunk size

·        BufferMeta的个数 = ObjectMeta的个数 * 4

加上日志文件头部FileHead,最终的缓存文件格式是这样的:



缓存文件中的各部分都按512字节对齐。另外,为了加快查找速度,FileHead及所有的bitmap会加载到内存,同时在原有的Object及BufferHead结构中增加了offset字段,分别用来加快ObjectMeta及BufferMeta的查找更新,如下:

class Object:public LRUObject {

...

loff_toffset;  //对应的ObjectMeta在缓存文件中的位置

...

class BufferHead : public LRUObject {

...

loff_toffset;  //对应的BufferMeta在缓存文件中的位置

...工作原理盛大游戏G云版的Rbd Cache内部修改就是上面描述的那个样子(其实也不全是哦!亮点在下面),下面让我们一起来看看它是怎么工作的。

·        librbd收到i/o请求后,根据将文件i/o映射为块设备i/o,生成ObjectExtent数组

·        从内存中的Obj Bitmap,为ObjectExtent数组中指向的Object获取一个存放位置,创建ObjectMeta对象并赋值,然后存储到缓存文件上述指定的位置处

·        创建BufferHead或者从缓存中合并/拆分出满足要求的BufferHead,接着创建BufferMeta对象并用前述BufferHead对其赋值,然后从内存中的Buffer Bitmap获取一个空闲位置,将BufferMeta存储到缓存文件中上述指定位置处

·        从内存中的Chunk Bitmap获取一个空闲位置,将i/o数据存储到缓存文件上述指定位置处

上述4步概要的描述了写i/o在librbd内部的处理逻辑。读i/o也是相似的处理逻辑,不同的是,Ceph集群作为了librbd的数据写入方,写入缓存文件的数据来自Ceph集群。

优化还记得上面我们是基于预设的rbd ssd chunk size来确定缓存文件bitmap大小的吗。细心的读者,一定注意到了这种假设很可能带来缓存空间的巨大浪费,而且也影响性能,让我们一起来看看到底是怎么回事吧。

假定我们有如下的缓存配置:

·        rbd ssd chunk size = 4M

·        rbd ssd cache size = 10G

·        rbd ssd cache max dirty = 8G

·        rbd ssd cache target dirty = 5G

那么基于上面的计算公式:

·        ObjectMeta个数 = 10G/4M = 2560

也就是最大能缓存2560个对象,实际上写入1280(rbd ssd cache target dirty= 5G)个对象后会写线程就会触发回写,写入2048个对象后清理线程就会触发缓存清理, 由于缓存文件的独占访问,写入性能会极大的下降。如果应用i/o的平均大小是我们设定的4M,那持续写入5G的数据才触发回写,这也是我们期望的;但如果应用i/o的平均大小是64KB呢,写入160M(2560*64KB)就触发了回写。一个是5G,一个是160M,空间浪费有多大不言而喻。用户看到的现象是,10G的缓存,怎么写了320M就满了,性能达不到要求。

为解决上面的问题,我们引入了“存储应用感知”功能,原理就是:librbd周期性的统计应用i/o的平均大小,动态调整rbd ssd chunk size,在业务不繁忙的时候, 重置缓存。

性能对比说了这么多,来看看实际的测试效果吧,测试参数如下:

·        测试命令:fio--filename=/vdisk/fio --direct=1 --ioengine=libaio --rw={randwrite/randread/read/write} -numjobs=2 --bs={4k/8k/4m}--size=5G --runtime=300 --iodepth=16 --group_reporting --name=test

·        缓存磁盘:SAS 10000 RPM, 缓存大小 10G

通过挂载Rbd块设备到KVM虚拟机上,并格式为xfs文件系统进行测试;其中的一组测试结果如下:



表格中SAS Cache表示用SAS作缓存的情况;Mem Cache表示原生Rbd Cache;表格的前半部分,显示的是用单台VM测试情况下的性能对比;后半部分,显示的是用20台VM压测情况下的性能对比;结果表明,性能提升效果还是挺明显的。如果用SSD作为缓存磁盘,相信性能提升会更明显。

至此我们对于Rbd Cache的改进介绍就结束了,如有不正确的地方欢迎指正,有更好的想法也欢迎留言。


    关注 G云定制云


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册