Ceph亚太峰会RGW议题分享

Ceph亚太峰会RGW部分议题分享

本次Ceph亚太峰会干货最实在的的要数Redhat的《Common Support Issues and How to Troubleshoot Them》这里把RGW部分摘出来，和大家分享一下，本次议题主要是涉及到RGW中Object数量过多导致的OSD异常如何处理。

故障现象描述

RGW的index数据以omap形式存储在OSD所在节点的leveldb中，当单个bucket存储的Object数量高达百万数量级的时候，deep-scrub和bucket list一类的操作将极大的消耗磁盘资源，导致对应OSD出现异常，如果不对bucket的index进行shard切片操作(shard切片实现了将单个bucket index的LevelDB实例水平切分到多个OSD上)，数据量大了以后很容易出事。

RGW在处理大量DELETE请求的时候，会导致底层LevelDB频繁进行数据库compaction(数据压缩，对磁盘性能损耗很大)操作，而且刚好整个compaction在LevelDB中又是单线程处理，很容易到达osdopthreads超时上限而导致OSD自杀。

jewel以及之前的版本的OMAP都是以LevelDB作为存储引擎，如果是从旧版本升级到最新的luminous，那么底层OMAP仍然是LevelDB。

最新版本的Luminous开始，OMAP底层的存储引擎换成了rocksDB，rocksDB采用多线程方式进行compaction(默认8个），所以rocksdb在compaction效率上要比LevelDB强很多。

临时解决方案

临时方法1:通过关闭整个集群或者独立的pool的deep-scrub去实现对集群稳定性的提升。

临时方法2：调优一些op相关的timeout参数，减少触发OSD自杀的概率，比如下面的一些参数

临时方法3：当OMAP目录过大时，手工触发一些osd的Leveldb compaction操作，以压缩OSD的LevelDB体积。

永久方案

按每个index shard object去遍历index pool的对应的omap条目数(最好不要听PPT作者的去进行遍历，很容易雪上加霜)，按每个key占用200byte方式统计每个omap对象的容量大小，当超过20MB的时候去手工进行reshard操作，注意reshard操作过程中bucket有元数据丢失的风险，谨慎使用，具体可以看之前公众号的文章，怎么去备份bucket元数据信息。另外分享中还提到了最新的Luminous可以实现动态的reshard(根据单个bucket当前的Object数量，实时动态调整shard数量），其实这里面也有很大的坑，动态reshard对用户来讲不够透明，而且reshard过程中会造成bucket的读写发生一定时间的阻塞，所以从我的个人经验来看，这个功能最好关闭，能够做到在一开始就设计好单个bucket的shard数量，一步到位是最好。至于如何做好一步到位的设计可以看公众号之前的文章。(《RGW Bucket Shard设计与优化》系列)

另外可以做到的就是单独使用SSD或者NVME作为index pool的OSD，但是Leveldb从设计上对SSD的支持比较有限，最好能够切换到rocksdb上面去，同时在jewel之前的版本还不支持切换omap引擎到rocksdb，除非打上下面的补丁https://github.com/ceph/ceph/pull/18010

关于如何切换Leveldb到rocksdb，也给了详细的操作流程，但是简单起见，还是切换配置然后重建OSD要省心很多。具体操作如下

总结

从PPT分享结合个人经验来看，解决这类问题的思路基本上如下:

一定要有SSD作为index pool

bucket 的index shard数量提前做好规划，这个可以参考本公众号之前的几篇bucket index shard相关内容。

jewel之前的版本LevelDB如果硬件条件允许可以考虑切换到rocksdb同时考虑在业务高峰期关闭deep-scrub。如果是新上的集群用L版本的ceph，放弃Filestore，同时使用Bluestore作为默认的存储引擎。

总而言之bucket index的性能需要有SSD加持，大规模集群一定要做好初期设计，等到数据量大了再做调整，很难做到亡羊补牢！