最近看到了有人的环境出现了出现了卡在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(原因未知)
参考资料
变更记录
| Why | Who | When |
|---|---|---|
| 创建 | 武汉-运维-磨渣 | 2016-05-14 |
| 修改 | 武汉-运维-磨渣 | 2016-09-23 |