• 6. PG 卡在 active + remapped 状态
    • 问题现象
    • 产生问题的原因
    • 如何解决

    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