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

打赏通道


打赏