Ceph recover的速度控制

前言

磁盘损坏对于一个大集群来说，可以说是必然发生的事情，即使再小的概率，磁盘量上去，总会坏那么几块盘，这个时候就会触发内部的修复过程，修复就是让不满足副本要求的PG，恢复到满足的情况

一般是踢掉坏盘和增加新盘会触发这个修复过程，或者对磁盘的权重做了修改，也会触发这个迁移的过程，本篇是用剔除OSD的方式来对这个修复的控制做一个探索

大部分场景下要求的是不能影响前端的业务，而加速迁移，忽略迁移影响不在本篇的讨论范围内，本篇将用数据来说明迁移的控制

本次测试在无读写情况下进程的

几个需要用到脚本和命令

磁盘本身的大概速度

[root@lab8106 ~]# ceph tell osd.0 bench
{
    "bytes_written": 1073741824,
    "blocksize": 4194304,
    "bytes_per_sec": 102781897
}

得到的结果为102MB/s

获取osd上pg迁移的对象的脚本

OSD的日志需要开启到10，这里采取动态开启的方式

ceph daemon osd.0 config set debug_osd 10

日志解析的脚本

cat  /var/log/ceph/ceph-osd.0.log | awk  '$7=="finish_recovery_op"&&$8=="pg[0.15(" {sub(/.*/,substr($2,1,8),$2); print $0}'|awk '{a[$1," ",$2]++}END{for (j in a) print j,a[j]|"sort -k 1"}'

获取osd.0上的pg0.15的迁移速度
运行后的效果如下：

2017-08-08 17:14:33 1
2017-08-08 17:14:34 2
2017-08-08 17:14:35 2
2017-08-08 17:14:36 1
2017-08-08 17:14:37 2
2017-08-08 17:14:38 2
2017-08-08 17:14:39 1
2017-08-08 17:14:40 2
2017-08-08 17:14:41 1
2017-08-08 17:14:42 2
2017-08-08 17:14:43 2

设置不迁移和恢复迁移

ceph osd set nobackfill;ceph osd set norecover
ceph osd unset nobackfill;ceph osd unset norecover

获取当前的正在迁移的PG

[root@lab8106 ~]# ceph pg dump|grep recovering
dumped all
3.e         513                  0      978         0       0 2151677952 513      513    active+recovering+degraded 2017-08-07 16:40:44.840780 118'513  332:7367 [2,3]          2  [2,3]              2        0'0 2017-07-28 14:28:53.351664             0'0 2017-07-28 14:28:53.351664 
3.2c        522                  0      996         0       0 2189426688 522      522    active+recovering+degraded 2017-08-07 16:40:44.882450 118'522  332:1177 [3,2]          3  [3,2]              3    118'522 2017-07-29 16:21:56.398682             0'0 2017-07-28 14:28:53.351664

过滤下输出结果

[root@lab8106 ~]# ceph pg dump|grep recovering|awk '{print $1,$2,$4,$10,$15,$16,$17,$18}'
dumped all in format plain
0.1d 636 1272 active+recovering+degraded [5,3] 5 [5,3] 5
0.14 618 1236 active+recovering+degraded [1,0] 1 [1,0] 1
0.15 682 1364 active+recovering+degraded [0,5] 0 [0,5] 0
0.35 661 1322 active+recovering+degraded [2,1] 2 [2,1] 2

动态监控PG的迁移

watch -n 1 -d "ceph pg dump|grep recovering|awk '{print ,,,,,,,}'"

我们要看PG 0.15的

防止缓存影响

同步数据然后清空缓存

sync
echo 3 > /proc/sys/vm/drop_caches

重启OSD进程

systemctl restart ceph-osd.target

磁盘的读写速度

dstat -td -D /dev/sdb -o disk.csv

sdb为需要监控的盘

测试的步骤与流程

整个测试需要保证每一次获取数据的过程都近似，这样才能最大程度减少环境对数据的影响

开始需要写入一些测试数据，这个可以用

rados -p rbd bench 3600 --no-cleanup

这个让每个PG上面大概有600-700个object，写入这个数据后就不再写入数据了

每一轮测试步骤如下：

恢复集群状态为active+clean
设置nobackfill，norecover
清空缓存
设置需要调整的参数
重启osd进程
停止osd，out osd
观察需要迁移的数据（尽量每次监测同一个PG）
清空日志，设置OSD debug 10
开启监控磁盘脚本
解除设置nobackfill，norecover
动态监控迁移状态，等待指定PG迁移完毕
停止磁盘监控脚本
获取PG迁移的情况，获取磁盘的读写情况
数据处理

每一轮测试需要按上面的步骤进行处理

测试分析

我的测试选择的是osd.4,按上面的步骤进行处理后，到了观察PG的步骤，此时因为做了不迁移的标记，只会状态改变，不会真正的迁移我们来观察下需要迁移的pg
默认情况下的

[root@lab8106 ~]# ceph pg dump|grep recovering|awk '{print $1,$2,$10,$15,$16,$17,$18}'
dumped all in format plain
0.15 682 active+recovering+degraded [0,5] 0 [0,5] 0
0.24 674 active+recovering+degraded [5,2] 5 [5,2] 5
0.35 661 active+recovering+degraded [2,1] 2 [2,1] 2
0.37 654 active+recovering+degraded [1,0] 1 [1,0] 1

可以看到这个环境下，每个OSD上面基本上是一个PG的写入，和一个PG的读取，实际上是读写同时在进行的

默认的

osd_max_backfills = 1
osd_recovery_max_active = 3

两个参数是一个是每个OSD上面启动的恢复的PG数目，下面一个是控制同时恢复的请求数目

默认的参数的情况

上图为迁移的对象数目

上图为OSD的磁盘读取写入的情况

可以看到迁移的对象每秒在6-15之间
磁盘上的读取为20-60MB/s，写入为80MB左右

这个只是默认的情况下的,占用了磁盘带宽的80%左右，在真正有写入的时候，因为有优先级的控制，占的带宽可能没那么多，本篇目的是在静态的时候就把磁盘占用给控制下来，那么即使有读写，恢复的磁盘占用只会更低

调整一个参数

osd_recovery_max_active = 3
调整如下
osd_recovery_max_active = 1

从磁盘占用上和迁移上面可以看到，磁盘的负载确实降低了一些，峰值从16降低到了11左右

sleep 参数的控制

下面是一个关键的参数了

osd_recovery_sleep = 0

这个在jewel最新版本下还是0，在luminous版本已经设置成ssd是0，sata变成0.1，相当于增加了一个延时的过程，本篇主要就是对这个参数进行研究，看下能控制最低到一个什么程度

下面的测试的数据就统计到一个图当中去了，这样也便于对比的

上面测试了几组参数:

sleep=0;sleep=0.1;sleep=0.2;sleep=0.5

从上面的图中可以看到：
迁移速度从12降低到1-2个
磁盘读取占用从40Mb/s降到 8Mb/s左右
磁盘写入的占用从60MB/s-80MB/s降低到8MB/s-40MB/s

结论

通过sleep的控制可以大大的降低迁移磁盘的占用，对于本身磁盘性能不太好的硬件环境下，可以用这个参数进行一下控制，能够缓解磁盘压力过大引起的osd崩溃的情况