我4天前就注意到了这个问题，不知道现在该怎么办。问题如下:
我有一个6节点3监视器ceph集群，有84个磁盘，72x7200rpm旋转磁盘和12xnvme用于日志记录的ssd。擦洗配置的每个值都是默认值。集群中的每个pg都是active+clean，每个集群状态都是绿色的。然而，没有被及时深度洗牌的控卫还在不断增加，现在是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，在客户端可能会面临多大的性能损失?
通常在集群上的低I/O间隔期间，集群会对自己进行深度刷洗。默认情况是每个控球球员每周都要进行一次深度清洗。如果硬盘坏了，就不能进行深度清理，当然，这可能会导致一些延迟。你可以这样运行，看看哪些pg在后面，如果它们都在同一个OSD上:
ceph pg dump pgs | awk '{print $1" "$23}' | column -t
如果需要对输出进行排序，您可以对一个受影响的pg发出手动深度清除，以查看数量是否减少以及深度清除本身是否有效。
ceph pg deep-scrub <PG_ID>
还请添加ceph osd pool ls detail，看看是否设置了任何标志。
可以将深度刷洗周期设置为2周，以延长深度刷洗窗口。本月的
osd_deep_scrub_interval = 604800
使用:
osd_deep_scrub_interval = 1209600
。Eblock有一个好主意，手动强制一些pgs进行深度擦洗，在2周内分散行动事件。
你有两个选择:
- 增加深度擦洗间隔
- 使用独立脚本手动控制深度扫描。
我已经写了一个简单的PHP脚本，为我照顾深度擦洗:https://gist.github.com/ethaniel/5db696d9c78516308b235b0cb904e4ad
它列出了所有的PG，选择一个PG在2周以上做了最后一次深度擦洗(脚本取最老的)，检查PG所在的osd是否没有被用于另一次擦洗(处于活动+清洁状态)，然后才开始对该PG进行深度擦洗，否则它会寻找另一个PG。
我将osd_max_scrubs设置为1(否则OSD守护进程会由于Ceph中的错误而崩溃)，因此该脚本可以很好地与常规调度程序一起工作-首先在PG-OSD上启动擦洗的是哪个。