刪除osd的正確方式有如下(對比分析)
在ceph的集群當中關於節點的替換的問題，一直按照以前的方式進行的處理，處理的步驟如下：
- 停止osd進程
/etc/init.d/ceph stop osd.0 |
這一步是停止osd的進程，讓其他的osd知道這個節點不提供服務了
- 將節點狀態標記為out
ceph osd out osd.0 |
這個一步是告訴mon，這個節點已經不能服務了，需要在其他的osd上進行數據的恢復了
- 從crush中移除節點
ceph osd crush remove osd.0 |
從crush中刪除是告訴集群這個點回不來了，完全從集群的分布當中剔除掉，讓集群的crush進行一次重新計算，之前節點還占着這個crush weight，會影響到當前主機的host crush weight
- 刪除節點
ceph osd rm osd.0 |
這個是從集群里面刪除這個節點的記錄
- 刪除節點認證（不刪除編號會占住）
ceph auth del osd.0 |
這個是從認證當中去刪除這個節點的信息
這個一直是我處理故障的節點osd的方式，其實這個會觸發兩次遷移，一次是在節點osd out以后，一個是在crush remove以后，兩次遷移對於集群來說是不好的，其實是調整步驟是可以避免二次遷移的
新的處理方式（推薦）
- 調整osd的crush weight
ceph osd crush reweight osd.0 0.1 |
說明：這個地方如果想慢慢的調整就分幾次將crush 的weight 減低到0 ，這個過程實際上是讓數據不分布在這個節點上，讓數據慢慢的分布到其他節點上，直到最終為沒有分布在這個osd，並且遷移完成
這個地方不光調整了osd 的crush weight ，實際上同時調整了host 的 weight ，這樣會調整集群的整體的crush 分布，在osd 的crush 為0 后， 再對這個osd的任何刪除相關操作都不會影響到集群的數據的分布
- 停止osd進程
/etc/init.d/ceph stop osd.0 |
停止到osd的進程，這個是通知集群這個osd進程不在了，不提供服務了，因為本身沒權重，就不會影響到整體的分布，也就沒有遷移
- 將節點狀態標記為out
ceph osd out osd.0 |
停止到osd的進程，這個是通知集群這個osd不再映射數據了，不提供服務了，因為本身沒權重，就不會影響到整體的分布，也就沒有遷移
- 從crush中移除節點
ceph osd crush remove osd.0 |
這個是從crush中刪除，因為已經是0了 所以沒影響主機的權重，也就沒有遷移了
- 刪除節點
ceph osd rm osd.0 |
這個是從集群里面刪除這個節點的記錄
- 刪除節點認證（不刪除編號會占住）
ceph auth del osd.0 |
這個是從認證當中去刪除這個節點的信息
經過驗證，第二種方式只觸發了一次遷移，雖然只是一個步驟先后上的調整，對於生產環境的的集群來說，遷移的量要少了一次，實際生產環境當中節點是有自動out的功能，這個可以考慮自己去控制，只是監控的密度需要加大，畢竟這個是一個需要監控的集群，完全讓其自己處理數據的遷移是不可能的，帶來的故障只會更多
替換OSD操作的優化與分析
一、前言
之前有寫過一篇刪除OSD的正確方式，里面只是簡單的講了下刪除的方式怎樣能減少遷移量，本篇屬於一個擴展，講述了 Ceph 運維當中經常出現的壞盤提換盤的步驟的優化
基礎環境兩台主機每台主機8個 OSD，一共 16 個 OSD，副本設置為2，PG 數設置為800，計算下來平均每個 OSD 上的 P G數目為100個，本篇將通過數據來分析不同的處理方法的差別
開始測試前先把環境設置為 noout，然后通過停止 OSD 來模擬 OSD 出現了異常，之后進行不同處理方法
二、測試三種方法
方法一：首先 out 一個 OSD，然后剔除 OSD，然后增加 OSD
- 停止指定 OSD 進程
- out 指定 OSD
- crush remove 指定 OSD
- 增加一個新的 OSD
一般生產環境會設置為 noout，當然不設置也可以，那就交給程序去控制節點的 out，默認是在進程停止后的五分鍾，總之這個地方如果有 out 觸發，不管是人為觸發，還是自動觸發數據流是一定的，我們這里為了便於測試，使用的是人為觸發，上面提到的預制環境就是設置的 noout
開始測試前獲取最原始的分布
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg1.txt |
獲取當前的 PG 分布,保存到文件pg1.txt，這個 PG 分布記錄是 PG 所在的 OSD，記錄下來，方便后面進行比較，從而得出需要遷移的數據
停止指定的 OSD 進程
[root@lab8106 ~]# systemctl stop ceph-osd@15 |
停止進程並不會觸發遷移，只會引起 PG 狀態的變化，比如原來主 PG 在停止的 OSD 上，那么停止掉 OSD 以后，原來的副本的那個 PG 就會角色升級為主 PG 了
out 掉一個 OSD
[root@lab8106 ~]# ceph osd out 15 |
在觸發 out 以前，當前的 PG 狀態應該有 active+undersized+degraded,觸發 out 以后，所有的 PG 的狀態應該會慢慢變成 active+clean,等待集群正常后，再次查詢當前的 PG 分布狀態
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg2.txt |
保存當前的 PG 分布為pg2.txt
比較 out 前后的 PG 的變化情況，下面是比較具體的變化情況，只列出變化的部分
[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt --suppress-common-lines |
這里我們關心的是變動的數目，只統計變動的 PG 的數目
[root@lab8106 ~]# diff -y -W 100 pg1.txt pg2.txt --suppress-common-lines|wc -l |
第一次 out 以后有102個 PG 的變動,這個數字記住，后面的統計會用到
從 crush 里面刪除 OSD
[root@lab8106 ~]# ceph osd crush remove osd.15 |
crush 刪除以后同樣會觸發遷移，等待 PG 的均衡，也就是全部變成 active+clean 狀態
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg3.txt |
獲取當前的 PG 分布的狀態
現在來比較 crush remove 前后的 PG 變動
[root@lab8106 ~]# diff -y -W 100 pg2.txt pg3.txt --suppress-common-lines|wc -l |
我們重新加上新的 OSD
[root@lab8106 ~]# ceph-deploy osd prepare lab8107:/dev/sdi |
加完以后統計當前的新的 PG 狀態
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg4.txt |
比較前后的變化
[root@lab8106 ~]# diff -y -W 100 pg3.txt pg4.txt --suppress-common-lines|wc -l |
整個替換流程完畢，統計上面的 PG 總的變動
102 +137 +167 = 406
也就是按這個方法的變動為406個 PG，因為是只有雙主機，里面可能存在某些放大問題，這里不做深入的討論，因為我的三組測試環境都是一樣的情況，只做橫向比較，原理相通，這里是用數據來分析出差別
方法二：先crush reweight 0 ，然后out，然后再增加osd
首先恢復環境為測試前的環境
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg1.txt |
記錄最原始的 PG 分布情況
crush reweight 指定OSD
[root@lab8106 ~]# ceph osd crush reweight osd.16 0 |
等待平衡了以后記錄當前的 PG 分布狀態
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg2.txt |
比較前后的變動
[root@lab8106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt --suppress-common-lines|wc -l |
crush remove 指定 OSD
[root@lab8106 ~]# ceph osd crush remove osd.16 |
這個地方因為上面 crush 已經是0了所以刪除也不會引起 PG 變動
然后直接 ceph osd rm osd.16 同樣沒有 PG 變動
增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi |
等待平衡以后獲取當前的 PG 分布
[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 2pg3.txt |
來比較前后的變化
[root@lab8106 ~]# diff -y -W 100 2pg2.txt 2pg3.txt --suppress-common-lines|wc -l |
總的 PG 變動為
166+159=325
方法3：開始做norebalance，然后做crush remove，然后做add
恢復環境為初始環境，然后獲取當前的 PG 分布
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg1.txt |
給集群做多種標記，防止遷移
設置為 norebalance，nobackfill，norecover,后面是有地方會解除這些設置的
[root@lab8106 ~]# ceph osd set norebalance |
crush reweight 指定 OSD
[root@lab8106 ~]# ceph osd crush reweight osd.15 0 |
這個地方因為已經做了上面的標記，所以只會出現狀態變化，而沒有真正的遷移，我們也先統計一下
[root@lab8106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg2.txt |
注意這里只是計算了，並沒有真正的數據變動，可以通過監控兩台的主機的網絡流量來判斷,所以這里的變動並不用計算到需要遷移的 PG 數目當中
crush remove 指定 OSD
[root@lab8106 ~]#ceph osd crush remove osd.15 |
刪除指定的 OSD
刪除以后同樣是沒有 PG 的變動的
ceph osd rm osd.15 |
這個地方有個小地方需要注意一下，不做 ceph auth del osd.15 把15的編號留着，這樣好判斷前后的 PG 的變化，不然相同的編號，就無法判斷是不是做了遷移了
增加新的 OSD
[root@lab8106 ~]#ceph-deploy osd prepare lab8107:/dev/sdi |
我的環境下，新增的 OSD 的編號為16了
解除各種標記
我們放開上面的設置，看下數據的變動情況
[root@lab8106 ceph]# ceph osd unset norebalance |
設置完了后數據才真正開始變動了，可以通過觀察網卡流量看到，來看下最終pg變化
[root@lab8106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > 3pg3.txt |
這里我們只需要跟最開始的 PG 分布狀況進行比較就可以了，因為中間的狀態實際上都沒有做數據的遷移，所以不需要統計進去，可以看到這個地方動了195個 PG
總共的 PG 遷移量為
195
三、數據匯總
現在通過表格來對比下三種方法的遷移量的比較(括號內為遷移 PG 數目)
|
|
方法一 |
方法二 |
方法三 |
| 所做操作 |
stop osd (0) |
crush reweight osd(166) |
set 標記(0) |
| PG遷移數量 |
406 |
325 |
195 |
可以很清楚的看到三種不同的方法，最終的觸發的遷移量是不同的，處理的好的話，能節約差不多一半的遷移的數據量，這個對於生產環境來說還是很好的，關於這個建議先在測試環境上進行測試，然后再操作，上面的操作只要不對磁盤進行格式化，操作都是可逆的，也就是可以比較放心的做，記住所做的操作，每一步都做完都去檢查 PG 的狀態是否是正常的
四、總結
從我自己的操作經驗來看，最開始是用的第一種方法，后面就用第二種方法減少了一部分遷移量，最近看到資料寫做剔除OSD的時候可以關閉遷移防止無效的過多的遷移，然后就測試了一下，確實能夠減少不少的遷移量，這個減少在某些場景下還是很好的，當然如果不太熟悉，用哪一種都可以，最終能達到的目的是一樣的