点击关注哦
当Ceph遇到Flashcache（二）
Ceph是当前分布式存储最受关注的开源项目，flashcache也是facebook技术团队开源项目的一个力作，本文将浅析flashcache相关实现原理，并讨论其与ceph的集成方式，来发掘二者碰撞带来的火花。
本篇是系列文章之二，主要对flashcache与ceph的集成工作做相应总结。
一、Flashcache与SSD
前文中的分析可知，flashcache最终生成的是一个逻辑块设备，这个逻辑块设备使用ssd作为缓存，期望达到比单独使用hdd更好的IO性能。
但单就SATA 3.0接口的ssd与hdd而言，其性能对比如下表：
注
Out-of-box为ssd设备初始状态或者做过ATA Secure Erase操作后，底层cell存储单元未存放任何数据的状态。同时，由于ssd底层存在多通道，若ssd长期业务IO压力较小，garbage collection机制触发较少，ssd也可以工作在该状态。
Steady为在ssd经过长期使用，底层存储单元碎片较多，garbage collection、wear leveling机制在正常IO下发过程中持续运行，抢占底层通道的场景下，前端业务IO能够达到的一个性能稳定状态。
以上数据采集自实验室设备，HDD：昱科（HGST） 3TB 7200转企业级机械硬盘；SSD：宝存（Shannon）480GB 企业级固态硬盘。
可见，ssd在随机读写方面性能较hdd有较大提升，而顺序读写方面性能差异并不大。因此，flashcache生成的逻辑设备仅是对随机IO加速效果明显。
同时，需要注意，随机写操作的稳态与顺序写操作的稳态二者性能并不相同，当两种写模式进行切换时，会有一个缓慢的过渡过程（即ssd设备的历史写入状态会影响到当前写操作的性能），具体如下图：
当ssd被顺序写一段时间后转换为随机写，随机写带宽会相对较高，IOPS也会相应较高（bw=bs*iops），随后逐渐回落到随机写的“稳态”性能；
当ssd被随机写一段时间后转换为顺序写，顺序写带宽会相对较低，随后逐渐上升达到顺序写的“稳态”性能。
注
依据ssd设备内部通道数的差异，sata 3.0接口ssd的随机写稳态性能（iops）也略有不同，以本次使用的SSD设备为例，其稳态iops为8000，按4kb小块数据估算，bw=bs*iops，当ssd进入随机写稳态后，继而转为顺序写操作，其带宽性能是从32MB/s左右逐步上升（最终达到顺序写稳态性能，约180MB/s）。
因此，当对一块ssd设备进行性能测试，若发现它只能提供几十MB/s的带宽时，不必再惊讶，你的ssd太“累”了，它需要GC！
二、CEPH-OSD的写操作逻辑
为了缩小写事务处理时间，提高写事务处理能力并实现事务原子性，Ceph-osd的FileStore引入了FileJournal的概念。
在生产上，FileStore通常使用xfs文件系统，在该场景下，写事务会先向FileJournal进行提交，FileJournal处理以后立即返回，并将该事务塞到FileStore的op queue。FileStore使用多个thread从op queue里获取op，然后将数据写到xfs文件系统，xfs文件系统负责数据的最终落盘。当FileStore完成一个op后，对应的Journal可以丢弃这部分日志（Ceph的数据双写机制）。
Ceph-osd打开FileJournal（通常是块设备分区）时，会指定O_DIRECT和O_DSYNC参数，即对应到物理设备上是一种单线程的循环顺序写方式；而Ceph-osd对FileStore的使用，则是通过一层文件系统来管理，文件系统对块设备的管理则不可避免地会有随机IO操作。
因此，可根据上述理论推测，当Ceph-osd的Filestore与Filejournal共用一块ssd物理设备时，由于随机写操作与顺序写操作的并存，在IO压力较大时，会导致ssd工作于随机写稳态与顺序写稳态性能之间，即对于顺序写操作，其带宽性能范围落在[32MB/s，180MB/s]区间内。而生产实践上，由于价格因素，ssd一般会划分多分区，配比多块hdd使用，这样在使用flashcache加速场景下，ssd的性能可能达不到预期，甚至会出现使用flashcache方案加速后的集群性能低于全hdd组成的ceph集群性能的现象。
三、Flashcache与Ceph的集成方式对比
3.1对比用例
在实验室环境中，进行了三种部署方式的性能对比，部署方式如下：
全HDD部署：
Flashcache（ssd分区做FileJournal）：
Flashcache（hdd分区做FileJournal）：
3.2测试环境
3.3测试环境
随机读测试结果汇总：
随机写测试结果汇总：
顺序读测试结果汇总：
顺序写测试结果汇总：
3.4结果分析
随机读测试结果：
结果中显示使用flashcache方案随机读性能并没有全hdd方案随机读性能好。这种结果的出现是和测试场景相关的，读场景下，flashcahe发挥ssd高性能的前提是数据已在ssd中缓存，读命中之后，才能获得较好的IO效果，如果未命中，flashcache仍去hdd中读取，而且读取之后还要将数据fill到ssd中，这带来更多的IO处理。而我们的测试场景为虚机卷全卷随机读操作，数据的预热在测试的30min（随机读fio运行时间）内还未完成。
因此，使用flashcache的一个最大前提就是需要有热点数据，否则cache效果并不明显，极端情况（如本测试用例）下，还会出现性能下降。
随机写测试结果：
结果显示相较于全hdd方案，使用flashcache方案随机写性能会有较大提升。
同时，该结果也验证了我们的推测，对比第二组（flashcache + ssd journal）与第三组（flashcache + hdd journal）测试，第二组中Filestore与Filejournal混用ssd，导致了ssd性能下降，最终影响到ceph集群整体写入性能。
顺序读测试结果：
基本持平，因为顺序读操作已经在flashcache中配置为直接访问hdd，且Ceph-osd的Filejournal机制对读操作并无影响。该结果符合预期。
注
Ceph以4MB进行切块，虚机256kb的请求会在ceph-osd的filestore层面合并，即xfs向flashcache交付的请求应为4MB，flashcache中配置了参数skip_seq_thresh_kb=256，即每个4MB块的前256kb请求会发往ssd（查找ssd是否命中：命中，则直接返回；未命中，转向hdd进行访问），前256kb之后的请求直接发往hdd。
顺序写测试结果：
结果进一步验证了我们的推测，对比第二组与第三组测试，第二组中ssd的多个分区，既做Filestore（ssd与hdd构建的flashcache逻辑设备）又做Filejournal（ssd分区），确实会降低ssd写入性能，最终影响到整个集群的吞吐。
因此，可以得出结论，flashcache与ceph进行集成时，不要将同一块sata ssd同时作为filestore与filejournal使用，否则会导致ssd性能下降，最终影响集群的整体性能，达不到应有的加速效果。
四、总结
至此，本文接近尾声，由上述分析，可以清晰地看到Ceph与Flashcache二者有着不同的脾气秉性，一个成熟稳重，一个轻巧灵动，如何让他们更好地协同工作，达到1+1>2的效果，则需要更多地对二者机制进行深入了解。
1
END
1
更多精彩，猛戳
（记得长按图片，识别二维码，添加关注哦）
