ceph卡在active+remapped状态

最近看到了有人的环境出现了出现了卡在active+remapped状态，并且卡住不动的状态，从pg的状态去看，这个pg值分配了主的pg，没有分配到副本的osd，集群的其他设置一切正常

这个从网上搜寻到的资料来看，大多数都是由于不均衡的主机osd引起的，所谓不平衡的osd

• 一台机器上面的磁盘的容量不一样，有的3T，有的1T
• 两台主机上面的OSD个数不一样，有的5个，有的2个

这样会造成主机的crush 的weight的差别很大的问题，以及分布算法上的不平衡问题，建议对于一个存储池来说，它所映射的osd至少需要是磁盘大小一致和个数一致的

这个问题我在我的环境下做了复现，确实有卡在remapped的问题

出现这个情况一般是什么操作引起的？

做osd的reweight的操作引起的，这个因为一般在做reweight的操作的时候，根据算法，这个上面的pg是会尽量分布在这个主机上的，而crush reweight不变的情况下，去修改osd 的reweight的时候，可能算法上会出现无法映射的问题

怎么解决这个问题？

直接做osd crush reweigh的调整即可避免这个问题，这个straw算法里面还是有点小问题的，在调整某个因子的时候会引起整个因子的变动

之前看到过sage在回复这种remapped问题的时候，都是不把这个归到bug里面去的，这个我也认为是配置问题引起的极端的问题，正常情况下都能避免的

更新

从FIREFLY (CRUSH_TUNABLES3)开始crush里面增加了一个参数：

chooseleaf_vary_r

是否进行递归的进行chooseleaf，如果非0，就递归的进行，这个基于parent已经做了多少次尝试，默认是0，但是常常找不到合适的mapping.在计算成本和正确性上来看最佳的值是1

对迁移的影响,对于已经有大量数据的集群来说，从0调整为1将会有大量的数值的迁移，调整为4或者5的话，将会找到一个更有效的映射，可以减少数据的移动

查看当前的值

[root@lab8106 ~]# ceph osd crush show-tunables |grep chooseleaf_vary_r
    "chooseleaf_vary_r": 0,

修改crushmap内容

修改chooseleaf_vary_r的值

hammer版本下这个参数默认为：

tunable chooseleaf_vary_r 0

jewel版本下这个参数默认为：

tunable chooseleaf_vary_r 1

这个是跟 tunables 的版本有关的

注意：在 3.15 之前的版本中，chooseleaf_vary_r 的值必须为0(原因未知)

参考资料

• 官网文档crushmap
• Issue列表
• sammyliu的blog

变更记录

Why	Who	When
创建	武汉-运维-磨渣	2016-05-14
修改	武汉-运维-磨渣	2016-09-23