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，寫入這個數據后就不再寫入數據了

每一輪測試步驟如下：

1. 恢復集群狀態為active+clean
2. 設置nobackfill，norecover
3. 清空緩存
4. 設置需要調整的參數
5. 重啟osd進程
6. 停止osd，out osd
7. 觀察需要遷移的數據（盡量每次監測同一個PG）
8. 清空日志，設置OSD debug 10
9. 開啟監控磁盤腳本
10. 解除設置nobackfill，norecover
11. 動態監控遷移狀態，等待指定PG遷移完畢
12. 停止磁盤監控腳本
13. 獲取PG遷移的情況，獲取磁盤的讀寫情況
14. 數據處理

每一輪測試需要按上面的步驟進行處理

測試分析

我的測試選擇的是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崩潰的情況