6. PG 卡在 active + remapped 状态

问题现象

有时，我们的 Ceph 集群可能会出现 PG 长时间卡在 active + remapped 的状态。

  1. root@ceph1:~# ceph -s
  2.     cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
  3.       health HEALTH_WARN 88 pgs stuck unclean
  4.       monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
  5.       osdmap e71: 4 osds: 4 up, 3 in
  6.         pgmap v442: 256 pgs, 4 pools, 285 MB data, 8 objects
  7.             690 MB used, 14636 MB / 15326 MB avail
  8.                     88 active+remapped
  9.                   168 active+clean

产生问题的原因

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

如何解决

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

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

  1. chooseleaf_vary_r

是否递归的进行 chooseleaf 尝试，如果非 0 ，就递归的进行，这个基于 parent 已经做了多少次尝试。默认值是 0 ，但是常常找不到合适的 mapping 。在计算成本和正确性上来看最优值是 1 。对于已经有大量数据的集群来说，从 0 调整为 1 将会有大量数值的迁移，调整为 4 或者 5 的话，将会找到一个更有效的映射，可以减少数据的移动。

查看当前的值：

  1. root@ceph1:~# ceph osd crush show-tunables |grep chooseleaf_vary_r
  2.     "chooseleaf_vary_r": 0,

修改 chooseleaf_vary_r 的值。

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

  1. tunable chooseleaf_vary_r 0

修改 Crush Map 的方法请参考本手册第一部分 9. 管理 Crushmap 。

或者，直接修改 crush tunables 的值为 optimal 。

  1. ceph osd crush tunables optimal