• 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