IDF16：解读Ceph百万IOPS测试及优化

http://chuansong.me/n/313092348043

在去年春季IDF（深圳）期间，我撰写过一篇《IDF15：Ceph性能测试浅析及优化》。由于我不是软件方面的专业人士，今天班门弄斧再写一篇关于Ceph的“浅析”，把自己阅读资料的收获和理解分享出来，希望能给分布式存储爱好者带来一些参考。

 

注：本文引用资料主要来自IDF2016技术课程《借助当今的NVMExpress*固态盘和未来的英特尔®Optane™技术打造经济高效的高性能存储解决方案》

 

下载链接：http://pan.baidu.com/s/1c2x4Cc4（点击本文底部“阅读原文”也可下载）

 

上图既然是Intel建议的Ceph配置，其中自然包含人家的SSD，而CPU也反映出尽量捡好的用（Intel当然希望多卖贵的吧）。第一种配置“标准/好”是1个DC P3700 SSD（日志&缓存）+16个大容量硬盘；第二种“更好(最佳TCO)”为1个P3700（日志）+4个S3510的全闪存配置；“最佳性能”就全部用NVMe/PCIe的P3700，不计成本了。

 

 

那么，本文介绍的测试配置正是PCIe+SATA SSD这种有一定性价比的。整个环境包括5个存储节点（双10GbE连接）和5个客户端节点的全万兆网络环境，在每个S3510 SSD上起2个Ceph OSD。所有CPU竟全部是在Xeon E5 v4发布之前最高18核的E5-2699 v3，用自家东西果然土豪啊。

 

PCIe+SATASSD随机读破百万，写性能仍待提高

 

 

其实在之前，我就已经见到过有人列出超过100万IOPS的Ceph测试性能，印象中最早大概是OpenStack东京峰会，那个配置是每节点4个高性能的Intel P3700，每SSD上面跑4个OSD。

 

根据上面的图表，在前一张图的配置下基于4KB随机读测得108万IOPS和3.5ms延时；8KB随机读IOPS下降到50万，延时上升到8.8ms；16KB随机读的IOPS和延时分别为30万和10ms。

 

也就是说，全SSD Ceph集群平均每节点读IOPS可以超过20万了。

 

 

随机写就没有那么好看了。其中4KB随机写IOPS只有14.4万，比8KB的13.2万没高出太多。至于Intel所说的“效率约为60%”，我觉得是考虑了双副本和日志写方式的两倍开销（1.08M/2/2*0.6）。

 

 

根据随机混合性能测试结果，Intel的结论是“随机写会极大的影响随机读性能”，由于是50/50按比例操作所以整体被拖慢了。

 

 

Ceph集群的128KB顺序读性能达到了5248MB/s，基本发挥出每节点双万兆网口的带宽；128KB顺序写带宽测得1927MB/s（比随机写好多了）。

 

性能调优：RocksDB有提升，期待BlueStore

 

 

前面我们介绍过，每个Ceph存储节点配置的双CPU一共36个物理核心，而OSD一共只有8个，所以面临线程数不饱满的问题。早期版本Ceph使用的LevelDB CPU应该不够高效，从NewStore项目开始替换为使用RocksDB存储预写式日志和元数据，4KB随机写IOPS获得大约26%提升。

 

 

上图引用自SAGE WEIL的ppt《CEPH AND ROCKSDB》，里面介绍了最新版本Ceph的BlueStore设计（NewStore之后的重要升级）。下面我再引用一段Ceph社区翻译的文章《Ceph Jewel 版本预览  即将到来的新存储BlueStore》中的介绍：

 

“BlueStore有一些内部组件，从总体上看，Ceph数据对象是直接被写入块物理设备的。因此我们不再需要任何文件系统，BlueStoe直接使用一个原始分区。OSD附带的数据对象元数据被存储到Key-Value数据库RocksDB中。各个分层描述如下：

•       RocksDB，正如前文提到的，存储预写式日志和元数据（Ceph的omap数据信息）

•       BlueRocksEnv是与RocksDB交互的接口

•      BlueFS是使用C++语言开发的小的文件系统，并实现了rocksdb::Env接口(存储RocksDB日志和sst文件)。因为rocksdb常规来说是运行在文件系统的顶层，下面是BlueFS。它是数据存储后端层，RocksDB的数据和BlueStore中的真正数据被存储在同一个块物理设备。”

 

 

接下来再看看4KB随机读性能优化。第一步是减小预读——由默认的2048改为16（单位大小是不是512byte？如果理解有误请读者在文章底部留言告诉我）。总之预读的开销对小数据块随机读影响较大，仅这一步骤性能就提高了55%。

 

然后就是提高并发，第二步osd op线程修改为32，性能提高11%；第三步rbd op线程修改为4，再提高11%。

 

针对新兴应用需求的现代存储架构

 

 

最后这张图，来自另一节IDF2016技术课程资料，CCIC应该是“英特尔（中国）云创新中心”的缩写。

 

最左边一列是工作负载分类，第一行数据库对应的存储产品/项目只有EMC ScaleIO。这个应该与相应的性能要求有关——总（集群）随机8KB混合IOPS大于500K，独立（单节点）随机8KB混合IOPS大于200K，响应时间小于5毫秒。ScaleIO在分布式块存储（ServerSAN）中除了性能出色、良好兼容Oracle RAC+ASM之外，稳定性和成熟度也基本获得公认。

 

虚拟化这一行，除了VMware VSAN、Nutanix和Windows Server 2012R2（Storage Spaces）之外，由于是在中国的验证项目，也得照顾一下本土厂商，因此还可以看到华为FusionStorage和SMARTX。

 

Ceph在这里被归入了下面的“企业冷数据”，我猜可能与之前的性能表现和生产应用的比例有关？以前看到一些调查中Ceph处于评估测试的比较多，总之潜力空间应该还是比较大。

 

至于另外几家国内存储厂商，做分布式文件系统老牌的龙存、新兴的达沃时代，还有七牛云存储这几家的技术实力还算不错。

 

注：本文只代表作者个人观点，与任何组织机构无关，如有错误和不足之处欢迎批评指正。进一步交流技术，可以加我的QQ/微信：490834312。

 

请在本公众号发布2天后，才能转载本文（微博/微信等转发分享不限）。尊重知识，请必须全文转载，并包括本行及如下二维码。