基于全HDD aarch64服务器的Ceph性能调优实践总结

1 简介

作为一个统一的分布式存储系统，Ceph为应用程序提供了对象，块和文件系统接口。
考虑到TCO，我们搭建了一个全HDD的Ceph集群（每个节点11个HDD + 1个SSD），它在存储利用率，性能和成本之间实现了最佳平衡，可以作为基于arm服务器来部署存储的参考设计。

2 Ceph架构

3 测试集群

硬件配置：3台arm服务器
每台arm服务器：

软件配置

性能测试工具

4 调优方式

4.1 硬件调优

近些年，磁盘的性能得到了成倍的提升，如下图。

网络带宽也成倍增长。

所以，我们可以基于不同的测试场景，不同的块大小，去选择升级磁盘和网络设备来提升性能。当然，TCO也是需要考虑的。

4.2 Ceph软件层面调优

arm的OSS组对这一块做了很多的优化工作，主要包括Ceph和SPDK两方面。

- 对于Ceph，软件中的一些基础算法使用了Neon和其它扩展进行了优化。还有加解密算法如CRC/SHA/AES以及一些存储库如ISA-L也都在arm平台上进行了优化。
- 对于SPDK，也是从软件层面在arm平台上进行了优化。

4.3 操作系统调优

从Linux内核来调优Ceph性能，这是一个范围很广很深的话题。
我们主要从磁盘和网络相关的两方面来考虑，举例来讲，
磁盘相关：

- I/O scheduler是存储路径中的一个关键部分，我们通常将HDD的I/O调度算法设置为deadline, 将SSD的调度算法设置为noop。
- 对于交换分区，考虑到当前内存一般不是瓶颈，所以我们建议直接关闭交换分区的使用。
- 对于顺序读的场景，调大read_ahead_kb的值有时可以提升顺序读的性能。

网络相关：

- 使用巨型帧在某些场景中可以提升吞吐率。
- Linux内核中有很多网络相关的参数，我们可以根据不同的应用场景，不同的块大小来调整这些网络参数，以达到最优的性能。
- 中断也是网络调优的一个方向，可以根据具体的情况来将中断合理的分配给不同的CPU core.

4.4 Ceph配置调优

Ceph中有太多的参数，所以这也是一个非常大的话题。
因为我们的集群关键路径主要集中在bluestore， 所以我们主要考虑从bluestore的参数来调优。

- 首先是Bluestore cache, 因为bluestore没有用文件系统，只是因为rocksdb而实现了一个轻量级的bluefs, 所以得自己实现cache功能，就像文件系统中的pagecache, bluestore cache对性能影响很大，考虑到当前系统的内存一般都很大，bluestore cache默认是4G，我们建议在系统允许范围内尽量地调大bluestore cache，以得到最佳的性能。

- 自从Ceph luminous版本出来后，Ceph引入了一个新的特性，叫做bluestore cache autotuning, 这个特性默认是启用的，主要功能是根据当前的系统负载来动态调整cache的分配比例， 在大多数情况下，这个特性能使当前应用场景性能达到最佳，但在一些特殊的场景中，如果关闭这个特性，然后手工的来根据当前的特点来调整cache的分配比例，可以达到更好的性能。

- 最后考虑到rocksdb在bluestore中的重要性， bluestore_rocksdb_options这个参数的调整有时可以极大地提高整个集群的性能。

5 测试结果及调优方向

我们选了4个测试用例，根据测试结果以及对于系统日志的分析，我们找出了每个测试用例的热点区域或瓶颈，然后简要地给出了调优的方向。

- 对于4k Seq Write用例，从sar log分析，热点是ssd磁盘，考虑到ssd用来作为rocksdb的block db, 所以可以从rocksdb层面来调优。
- 对于4k Rand Write用例，从sar log分析，HDD的磁盘使用率接近100%， 所以HDD是瓶颈，可以考虑从I/O scheduler层面来调优。
- 对于4M Seq/Rand Write用例，明显可以看出，网络带宽已经到了瓶颈，这个可以从网络层面来调优。

接下来我们对第一个测试用例（4k Seq Write）做一个具体的调优实践。

6 "4k Seq Write"用例调优

首先，我们看一个Ceph时延占比的测试，如下图：

从图中可以看出，当使用SATA SSD作为数据库设备时，在整个IO时延中，bluestore占用了大部分的比例，如果我们能优化bluestore的性能，就能直接的反应到整个Ceph集群的性能优化。考虑到rocksdb是bluestore中的一个关键点，以及刚才分析sar log的结果显示，ssd是热点，所以我们着重来调优rocksdb.

下面是rocksdb的架构图：

简单来讲，写入rocksdb的数据先写到memtable,当超过write_buffer_size大小后，就会将active memtable改为read only（immutable）,然后重新开启一个active memtable 供新数据写入。当read only的memtable的数量达到阈值后，就会被合并然后flush到磁盘。

对于我们的测试用例来讲，我们调整了如下参数：

然后，我们得到了大于10%的性能提升，如下图。

实际上，rocksdb也是非常的复杂，有非常多的参数，通常对于rocksdb的调优是对写放大，读放大，空间放大之间的权衡。

7 总结

本文介绍了基于全HDD aarch64服务器的Ceph性能调优实践，希望能对期望在arm服务器上部署Ceph存储的存储架构师，工程师起到借鉴参考作用。

原作者：Ker