为什么需要Scrub-京东云开发者社区

# 概述
存储可能发生数据静默损坏，某位异常反转：

- 硬件错误

- 传输过程信噪干扰

- 固件 bug

- 软件 bug

ceph的scrubbing类似于对象存储层上的 fsck。对于每个 pg，Ceph 生成所有对象的目录，并比较每个主对象及其副本，以确保没有对象丢失或不匹配。通过对比各个对象副本的数据和元数据，完成副本一致性检查。
可以在后台发现由于磁盘损坏导致的数据不一致，缺点是发现的时机比较滞后。
scrubbing 分两种：

- shallow scrub：对比对象各个副本的元数据来检查数据的一致性。

- deep scrub：进一步检查对象数据的内容是否一致。耗时长，占用资源多。

scrubbing 对于数据完整性的管理十分重要，却会削减性能。
# Scrub代码流程
scrub是一个生产者消费者模型，生产者生成scrub job，消费者消费。
## 生产者
生产者由定时任务触发，具体流程如下
1. 首先判断osd正在执行scrub的pg数是否大于**osd_max_scrubs**，如果大于则返回。
2. 是否达到pg的预期scrub时间，如果没达到则返回。
3. 判断当前时间是否大于deadline，如果小于，则判断是否在osd_scrub_begin_hour和osd_scrub_end_hour，如果处于则判断集群负载是否在osd_scrub_load_thredhold之下，如果不满足则等待时间再重试。**如果当前时间大于deadline，则不会判断时间和负载，强制执行scrub任务**，到这一步仍然是min_interval和max_interval起作用。
```
if ((scrub.deadline.is_zero() || scrub.deadline >= now) && !(time_permit && load_is_low)) {       dout(10) << __func__ << " not scheduling scrub for " << scrub.pgid << " due to "                << (!time_permit ? "time not permit" : "high load") << dendl;       continue;    }
```
4. 一个scrub任务最后会经过判断，从而决定这个scrub任务到底是shallow scrub还是deep scrub，接下来我来分析一下这个判断流程。
5. 首先只有主osd才会执行。
```
if (!(is_primary() && is_active() && is_clean())) {   return false;}
```

6. 判断deep scrub的时间有没有超过周期，有这个任务会是deep scrub。
```
scrubber.time_for_deep = ceph_clock_now() >=         info.history.last_deep_scrub_stamp + deep_scrub_interval;
```

7.如果没过期，这时osd_deep_scrub_randomize_ratio这个参数会起作用。
```
deep_coin_flip = (rand() % 100) < cct->_conf->osd_deep_scrub_randomize_ratio * 100;scrubber.time_for_deep = (scrubber.time_for_deep || deep_coin_flip);
```

8. 之后就是具体将任务加到队列，这里是用统一的数据结构表示**scrub**和**deep scrub**任务。
9. 获取deep scrub和scrub的标志位，如果设置了no deep scrub或者no scrub，则不执行相应任务。

从代码中看到的几个细节：

1. 预期的scrub时间，是由 last_scrub_time + min_interval + random_postpone_time，从而错开了pg的开始时间，这里起到了消峰的作用，并且随着系统的运行，这个时间是会错开的。
```
sched_time += scrub_min_interval;double r = rand() / (double)RAND_MAX;sched_time += scrub_min_interval * cct->_conf->osd_scrub_interval_randomize_ratio * r;deadline += scrub_max_interval;
```

2. last_scrub_time + max_interval作为deadline，所以如果max interval设置的不对，就会导致系统在业务的正常时间出现deep scrub和scrub，并且不会受到load thredhold的限制。
3. osd_deep_scrub_randomize_ratio这个参数会把普通的scrub任务变成deep scrub任务，但是只要max interval设置的合理，是有均衡deep scrub任务的作用的。
## 消费者

消费者是由线程池控制，具体流程如下：

1. OSD 会以 PG 为粒度触发 Scrub 流程，而一个 PG 的 Scrub 启动都是由该 PG 的 Master 角色所在 OSD 启动。
2. 一个 PG 在普通的环境下会包含几千个到数十万个不等的对象，因为 Scrub 流程需要提取对象的校验信息然后跟其他副本的校验信息对比，这期间被校验对象的数据是不能被修改的。因此一个 PG 的 Scrub 流程每次会启动小部分的对象校验，Ceph 会以每个对象名的哈希值的部分作为提取因子，每次启动对象校验会找到符合本次哈希值的对象，然后进行比较。这也是 Ceph 称其为 Chunky Scrub 的原因。
3. 在找到待校验对象集后，发起者需要发出请求来锁定其他副本的这部分对象集。因为每个对象的 master 和 replicate 节点在实际写入到底层存储引擎的时间会出现一定的差异。这时候，待校验对象集的发起者会附带一个版本发送给其他副本，直到这些副本节点与主节点同步到相同版本。
4. 在确定待校验对象集在不同节点都处于相同版本后，发起者会要求所有节点都开始计算这个对象集的校验信息并反馈给发起者。
5. 该校验信息包括每个对象的元信息如大小、扩展属性的所有键和历史版本信息等等，在 Ceph 中被称为 ScrubMap。
6. 发起者会比较多个 ScrubMap并发现不一致的对象，不一致对象会被收集最后发送给 Monitor，最后用户可以通过 Monitor 了解 Scrub 的结果信息。
```
* Chunky scrub scrubs objects one chunk at a time with writes blocked for that* chunk.** The object store is partitioned into chunks which end on hash boundaries. For* each chunk, the following logic is performed:** (1) Block writes on the chunk* (2) Request maps from replicas* (3) Wait for pushes to be applied (after recovery)* (4) Wait for writes to flush on the chunk* (5) Wait for maps from replicas* (6) Compare / repair all scrub maps* (7) Wait for digest updates to apply
```

从流程也可以看出几个细节：
1. chunky scrub里面的object会被锁住，写请求受到影响。
2. osd_scrub_sleep是控制两次chunky scrub的间隔，从而会拉长一次scrub（这里包括deep scrub 和 shallow scrub）的时间，睡眠是通过定时器实现的。
# 总结

我们首先可以解决之前的几个迷惑的问题：
1. 针对正在执行的scrub任务，即便时间超过配置的 end hour 后，仍然会执行，新的任务在**OSD::sched_scrub()**开始时 **OSD::scrub_time_permit** 返回 false不会执行。
2. 如果**osd_scrub_max_interval**配置的不合理，则会导致scrub任务的deadline超出，那么就会导致在规定时间外的任意时间出现scrub/deep scrub，从而影响业务IO。
3. 一个scrub任务到底是deep还是shallow，和**osd_deep_scrub_interval**还有**osd_deep_scrub_randomize_ratio**参数有关，超过**osd_deep_scrub_interval**的一定是deep，否则按照**osd_deep_scrub_randomize_ratio**对应的概率转换成deep。
4. 不管是deep还是shallow scrub任务，执行的逻辑都是一样的，函数也一样，状态机也一样，唯一不同的是ScrubMap如果是deep会额外的请求CRC校验值。

其次我们可以总结出参数调优的主要方向

1. 重中之重，确定**osd_scrub_max_interval**，这个时间很重要，如果设置的太小就会导致业务在正常时间IO受到影响，并且此时**osd_scrub_load_thredhold**、begin hour、end hour都不会生效，**osd_scrub_sleep**时间生效。这里结合了杨兵的标Y机器在设置**osd_scrub_max_interval**以及线上jrss1集群，通过命令
```
ceph pg dump --format json | jq -r  .pg_stats[] | [ .last_clean_scrub_stamp ] | @csv  | sort -r
```
可以看到较多scrub任务在设置的scrub时间之外执行，所以这个参数需要调整，后续杨兵调整到一个月之后，没有出现类似现象。
2. 其次，end hour的设置，如果业务7点开始使用，那么如果设置成7点，可能最后一个任务没有执行完，deep scrub任务会持续到7点之后，具体取决于最后一个pg scrub的执行时间，那么这个值可以再提前一点。
3. 其次**osd_scrub_load_threshold**的设置，这个值默认0.5，假如在begin hour和end hour之间，如果cpu高于这个值，那么是不会执行scrub的，这个值太小会导致在正常规定时间不能执行**scrub**，从而影响deadline，一旦超过deadline会出现第一种情况。
4. bucket index对应的shard对象不宜过大，如果太大，这个对象在执行deep scrub的时候，会影响bucket级别的对象无法写入。这个参数通过修改**osd_scrub_chunk_min，osd_scrub_chunk_max**，可以缓解但是如果一个shard对象太多，仍然会比较严重。
5. osd_scrub_sleep参数可以降低客户端在scrub时间内的感知，代价是增加了一次scrub任务的时间，所以如果修改这个参数，仍然需要确保一个osd_scrub_max_interval周期里，所有的pg能够被正确执行完scrub任务。

总结一下，优化的思路就是首先确保scrub任务不会在begin hour 和 end hour之外的时间执行，其次就是在begin hour和end hour之间，尽可能减少业务的感知。