Ceph集群縮容及相關(guān)故障處理的示例分析

這篇文章主要介紹Ceph集群縮容及相關(guān)故障處理的示例分析，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

引言

由于目前機(jī)器比較緊張，需要將我集群中的一批機(jī)器提供給其他業(yè)務(wù)使用，這時問題來了，集群機(jī)器的退出意味著數(shù)據(jù)要重新分布，數(shù)據(jù)遷移的過程中比較容易出故障。

處理過程

處理測試POOL對應(yīng)的機(jī)器

集群中有很多POOL， 有些POOL是客戶數(shù)據(jù)，這非常重要；有些POOL是我測試用，這些POOL對應(yīng)的OSD可以直接刪除，即時集群報pg異常，也無需關(guān)心，在刪除對應(yīng)OSD后將對應(yīng)POOL刪除即可，相應(yīng)的pg異常也消失。

注：為了避免關(guān)閉OSD的過程中發(fā)生數(shù)據(jù)遷移，請?jiān)O(shè)置norecover標(biāo)記。

ceph osd set norecover

刪除對應(yīng)主機(jī)上的所有OSD信息的命令如下：

killall -9 ceph-osd

for i in {108..119} 
do 
ceph osd out  osd.$i; 
ceph osd crush remove osd.$i; 
ceph auth del osd.$i;
ceph osd rm $i; 
ceph auth del osd.$i;
done


ceph osd crush remove hostname
removed item id -10 name 'hostname' from crush map

處理業(yè)務(wù)需要的POOL對應(yīng)的機(jī)器

對于業(yè)務(wù)用到的POOL分布在了10臺機(jī)器上，現(xiàn)在要從這10臺機(jī)器中釋放出五臺,這需要涉及到數(shù)據(jù)遷移了。有三種辦法進(jìn)行處理。

方法一之設(shè)置out

將要退出的機(jī)器依次設(shè)置為out狀態(tài)。一臺機(jī)器做完后做另外一臺，由系統(tǒng)負(fù)責(zé)將數(shù)據(jù)遷走；

方法二之設(shè)置權(quán)重

將要推出的機(jī)器權(quán)重調(diào)整為0，由系統(tǒng)負(fù)責(zé)將數(shù)據(jù)遷走；

方法三 構(gòu)建新規(guī)則

1. 構(gòu)建新group,將要保留的機(jī)器放到新group下；

2. 構(gòu)建新crushrule, take from newgroup;

3. 將業(yè)務(wù)pool的規(guī)則設(shè)置為new crush rule下；

這是最快的辦法，只涉及到一次遷移，等待數(shù)據(jù)遷移完畢后，就可以將不需要的OSD關(guān)閉并移除了。

處理后碰到的問題

癥狀表現(xiàn)，在集群狀態(tài)中顯示少量PG狀態(tài)異常。 active + remapped + backfilling active + remapped

[root@gnop029-ct-zhejiang_wenzhou-16-11 ~]# ceph -s
    cluster c6e7e7d9-2b91-4550-80b0-6fa46d0644f6
     health HEALTH_WARN
            2 pgs backfilling
            3 pgs stuck unclean
            recovery 24/2148593 objects misplaced (0.001%)
            norecover,noscrub,nodeep-scrub flag(s) set
     monmap e3: 3 mons at {a=101.71.4.11:6789/0,b=101.71.4.12:6789/0,c=101.71.4.13:6789/0}
            election epoch 446, quorum 0,1,2 a,b,c
     osdmap e69909: 120 osds: 120 up, 120 in; 3 remapped pgs
            flags norecover,noscrub,nodeep-scrub
      pgmap v8678900: 10256 pgs, 16 pools, 2763 GB data, 1047 kobjects
            7029 GB used, 197 TB / 214 TB avail
            24/2148593 objects misplaced (0.001%)
               10253 active+clean
                   2 active+remapped+backfilling
                   1 active+remapped

[root@ceph]# ceph pg dump_stuck unclean
ok
pg_stat	state	up	up_primary	acting	acting_primary
23.1c1	active+remapped+backfilling	[59,37]	59	[76,84]	76
23.23b	active+remapped	[35,7]	35	[82,119]	82
23.221	active+remapped+backfilling	[15,18]	15	[70,82]	70

后來我開啟了scrub和deepscrub， 將所有pg掃描后就恢復(fù)為active + clean。

在發(fā)生數(shù)據(jù)遷移時，有時候某些osd會因?yàn)樨?fù)載過高，導(dǎo)致osd進(jìn)程退出，這是需要做兩方面工作：

1. 調(diào)低osd backfill的線程數(shù)量，降低osd工作負(fù)載；

2. down掉的osd即時恢復(fù)，要不會有很多Pg狀態(tài)異常，osd回復(fù)后這些異常的pg也會很快恢復(fù)正常；

以上是“Ceph集群縮容及相關(guān)故障處理的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！