1. 程式人生 > >ceph recovery的速度控制

ceph recovery的速度控制

轉自https://ceph.com/planet/ceph-recover的速度控制/

前言

磁碟損壞對於一個大叢集來說,可以說是必然發生的事情,即使再小的概率,磁碟量上去,總會壞那麼幾塊盤,這個時候就會觸發內部的修復過程,修復就是讓不滿足副本要求的PG,恢復到滿足的情況

一般是踢掉壞盤和增加新盤會觸發這個修復過程,或者對磁碟的權重做了修改,也會觸發這個遷移的過程,本篇是用剔除OSD的方式來對這個修復的控制做一個探索

大部分場景下要求的是不能影響前端的業務,而加速遷移,忽略遷移影響不在本篇的討論範圍內,本篇將用資料來說明遷移的控制

本次測試在無讀寫情況下程序的
幾個需要用到指令碼和命令
磁碟本身的大概速度

[[email protected] ~]# 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

[[email protected] ~]# 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

過濾下輸出結果

[[email protected] ~]# 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
預設情況下的

[[email protected] ~]# 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數目,下面一個是控制同時恢復的請求數目

預設的引數的情況
pg.png-37.1kB
上圖為遷移的物件數目
diskspeed.png-63.7kB
上圖為OSD的磁碟讀取寫入的情況

可以看到遷移的物件每秒在6-15之間
磁碟上的讀取為20-60MB/s,寫入為80MB左右

這個只是預設的情況下的,佔用了磁碟頻寬的80%左右,在真正有寫入的時候,因為有優先順序的控制,佔的頻寬可能沒那麼多,本篇目的是在靜態的時候就把磁碟佔用給控制下來,那麼即使有讀寫,恢復的磁碟佔用只會更低
調整一個引數

osd_recovery_max_active = 3
調整如下
osd_recovery_max_active = 1

pgactive1.png-30.9kB

diskactive1.png-66.4kB

從磁碟佔用上和遷移上面可以看到,磁碟的負載確實降低了一些,峰值從16降低到了11左右
sleep 引數的控制

下面是一個關鍵的引數了

osd_recovery_sleep = 0

這個在jewel最新版本下還是0,在luminous版本已經設定成ssd是0,sata變成0.1,相當於增加了一個延時的過程,本篇主要就是對這個引數進行研究,看下能控制最低到一個什麼程度

下面的測試的資料就統計到一個圖當中去了,這樣也便於對比的

sleeppg.png-76.6kB

sleepdiskread.png-86.7kB

sleepdiskwrite.png-130.8kB

上面測試了幾組引數:

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崩潰的情況