未及时深度清理的 Ceph PG 不断增加答案

【问题标题】：Ceph PGs not deep scrubbed in time keep increasing未及时深度清理的 Ceph PG 不断增加
【发布时间】：2021-02-08 14:35:11
【问题描述】：

我大约 4 天前注意到了这一点，现在不知道该怎么办。问题如下：

我有一个 6 节点 3 监视器 ceph 集群，带有 84 个 osd、72x7200rpm 旋转磁盘和 12xnvme ssd 用于日志记录。清理配置的每个值都是默认值。集群中的每个 pg 都是 active+clean，每个集群 stat 都是绿色的。然而，没有及时进行深度清洗的 PG 不断增加，目前为 96。 ceph -s 的输出：

  cluster:
    id:     xxxxxxxxxxxxxxxxx
    health: HEALTH_WARN
            1 large omap objects
            96 pgs not deep-scrubbed in time

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 6h)
    mgr: mon2(active, since 2w), standbys: mon1
    mds: cephfs:1 {0=mon2=up:active} 2 up:standby
    osd: 84 osds: 84 up (since 4d), 84 in (since 3M)
    rgw: 3 daemons active (mon1, mon2, mon3)

  data:
    pools:   12 pools, 2006 pgs
    objects: 151.89M objects, 218 TiB
    usage:   479 TiB used, 340 TiB / 818 TiB avail
    pgs:     2006 active+clean

  io:
    client:   1.3 MiB/s rd, 14 MiB/s wr, 93 op/s rd, 259 op/s wr

我该如何解决这个问题？此外，ceph 健康详细信息输出显示此非深度清理 pg 警报于 1 月 25 日开始，但我之前没有注意到这一点。我注意到这一点的时间是一个 osd 宕机 30 秒然后起床的时候。可能与这个问题有关吗？它会自行解决吗？我应该篡改擦洗配置吗？例如，如果我将 osd_max_scrubs 从 1 增加到 2，我可能会在客户端面临多少性能损失？

【问题讨论】：

标签： ceph object-storage data-scrubbing

【解决方案1】：

您可以将深度磨砂期设置为 2 周，以延长深度磨砂期。安装的

 osd_deep_scrub_interval = 604800

使用：

 osd_deep_scrub_interval = 1209600

先生。 Eblock 有一个好主意，可以手动强制一些 pgs 进行深度清理，以便在 2 周内分散操作。

【讨论】：

【解决方案2】：

通常，集群会在集群上的低 I/O 间隔期间对自身进行深度清理。默认情况下，每个 PG 都必须每周进行一次深度清理。当然，如果 OSD 出现故障，它们就无法进行深度清理，这可能会导致一些延迟。你可以运行这样的东西来查看哪些 PG 在后面，以及它们是否都在同一个 OSD 上：

ceph pg dump pgs | awk '{print $1" "$23}' | column -t

如有必要，对输出进行排序，您可以对其中一个受影响的 PG 发出手动深度清理，以查看数量是否减少以及深度清理本身是否有效。

ceph pg deep-scrub <PG_ID>

另外请添加ceph osd pool ls detail 以查看是否设置了任何标志。

【讨论】：

非深度清理的 pg 计数卡在 96 处，直到清理计时器启动。我想今天它会再次卡在96。根据我的 cephmgr 仪表板，我在每个 osd 上有 96 pg 计数。我真的开始思考这是否与被击落的 osd 有关。
我还想问点别的，我停止了所有数据流到我的 cephfs 池，看看这个清理是如何进行的。已用空间为 273.3 TB，但可用空间不断减少。自从我停止数据传输以来，减少了大约 1.5 TB。同样与此相关的是，cephfs 数据池是 3+2 纠删码。我已经传输了大约 158-160 TB 的数据。在 3+2 上，如果我是正确的，它应该是大约 265-270 TB，所有块组合在一起，所以那部分没有问题吗？
如果这是您要的，擦洗不会释放空间。 (Deep-)Scrubbing 比较所有副本及其校验和以保持数据块的一致性。您对 3+2 配置文件的假设是正确的，但您必须记住，由于bluestore_min_alloc_size_hdd，实际使用量可能会更高，请阅读此 [lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/… 了解一些详细信息。
此时只要您没有停用 PG，就无需担心。你没有那么多 PG，你可以手动对几个 PG 进行深度清理，看看你能走多远。
Deep-scrubs 可以发现 PG 的副本之间的不一致。因此，在 DR 场景中，您最终可能会得到错误数据。为了安全起见，您绝对应该解决此问题，但这并不是非常紧急。

【解决方案3】：

你有两个选择：

增加深度磨砂的间隔时间。
使用独立脚本手动控制深度清理。

我编写了一个简单的 PHP 脚本，它负责为我进行深度清理：https://gist.github.com/ethaniel/5db696d9c78516308b235b0cb904e4ad

它列出所有 PG，挑选 1 个在 2 周前完成最后一次深度清理的 PG（脚本采用最旧的），检查 PG 所在的 OSD 是否没有被用于另一次清理（处于活动+清洁状态），然后才开始对该 PG 进行深度清理。否则它会寻找另一个 PG。

我已将 osd_max_scrubs 设置为 1（否则 OSD 守护程序会因 Ceph 中的错误而开始崩溃），因此该脚本可以很好地与常规调度程序配合使用 - 无论哪个先在 PG-OSD 上启动清理，都会获胜。

【讨论】：