本篇內(nèi)容介紹了“RGW Bucket Shard設(shè)計(jì)與優(yōu)化方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)是專業(yè)的松溪網(wǎng)站建設(shè)公司，松溪接單;提供成都做網(wǎng)站、成都網(wǎng)站建設(shè),網(wǎng)頁(yè)設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行松溪網(wǎng)站開發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來(lái)合作!

OMAP過大的OSD服務(wù)恢復(fù)

當(dāng)bucket index所在的OSD omap過大的時(shí)候，一旦出現(xiàn)異常導(dǎo)致OSD進(jìn)程崩潰，這個(gè)時(shí)候就需要進(jìn)行現(xiàn)場(chǎng)"救火"，用最快的速度恢復(fù)OSD服務(wù)，于是有了下面這篇文章。

先確定對(duì)應(yīng)OSD的OMAP大小，這個(gè)過大會(huì)導(dǎo)致OSD啟動(dòng)的時(shí)候消耗大量時(shí)間和資源去加載levelDB數(shù)據(jù)，導(dǎo)致OSD無(wú)法啟動(dòng)（超時(shí)自殺）。特別是這一類OSD啟動(dòng)需要占用非常大的內(nèi)存消耗，一定要注意預(yù)留好內(nèi)存。（物理內(nèi)存40G左右，不行用swap頂上）

root@demo:/# du -sh /var/lib/osd/ceph-214/current/omap/
22G     /var/lib/osd/ceph-214/current/omap/

  2017-08-11 11:52:46.601938 7f298ae2e700  1 heartbeat_map is_healthy 'FileStore::op_tp thread 0x7f2980894700' had suicide timed out after 180
     0> 2017-08-11 11:52:46.605728 7f298ae2e700 -1 common/HeartbeatMap.cc: In function 'bool ceph::HeartbeatMap::_check(ceph::heartbeat_handle_d*, const char*, time_t)' thread 7f298ae2e700 time 2017-08-11 11:52:46.601952
common/HeartbeatMap.cc: 79: FAILED assert(0 == "hit suicide timeout") #超時(shí)自殺

 啟動(dòng)OSD服務(wù)之前調(diào)整osd超時(shí)設(shè)置

在故障節(jié)點(diǎn)ceph.conf配置中加上

[osd]
debug osd = 20 #調(diào)整debug級(jí)別

[osd.214]
            ...
        filestore_op_thread_suicide_timeout = 7000 #設(shè)置對(duì)應(yīng)的osd超時(shí)，防止osd自殺

 啟動(dòng)OSD進(jìn)程

觀察日志

tailf /home/ceph/log/ceph-osd.214.log

啟動(dòng)服務(wù)

/etc/init.d/ceph start osd.214

后臺(tái)多啟動(dòng)一個(gè)top觀察進(jìn)程的資源消耗，目前OMAP在16G左右的OSD，需要大概37G的內(nèi)存?；謴?fù)過程中OSD進(jìn)程會(huì)占用非常高的內(nèi)存和CPU，如下圖

 擇機(jī)釋放內(nèi)存

當(dāng)觀察到日志中有下面的記錄就可以啟動(dòng)內(nèi)存的釋放操作（也可以放到最后去做）

2017-08-11 15:08:14.551305 7f2b3fcab900  0 osd.214 29425 load_pgs opened 181 pgs

釋放內(nèi)存命令如下

ceph tell osd.214 heap release

OSD服務(wù)恢復(fù)過程中的監(jiān)測(cè)

經(jīng)過上面的操作以后osd會(huì)持續(xù)進(jìn)行Omap數(shù)據(jù)的恢復(fù)，整個(gè)過程比較漫長(zhǎng)，可以同時(shí)開 watch ceph -s 進(jìn)行觀察，一般恢復(fù)速率為每秒14MB，恢復(fù)時(shí)長(zhǎng)估算公式

恢復(fù)時(shí)長(zhǎng)(單位:秒) = OMAP總?cè)萘?nbsp;/ 14
注意:其中OMAP總?cè)萘渴乔懊鎑u命令得到的

恢復(fù)過程中的日志如下

2017-08-11 15:11:25.049357 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_message: 0x651131200
2017-08-11 15:11:25.049380 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] handle_push ObjectRecoveryInfo(6f648ab6/.dir.hxs1.55076.1.6/head//76@29425'5676261, copy_subset: [], clone_subset: {})ObjectRecoveryProgress(!first, data_recovered_to:0, data_complete:false, omap_recovered_to:0_00001948372.1948372.3, omap_complete:false)
2017-08-11 15:11:25.049400 7f2a3b327700 10 osd.214 pg_epoch: 29450 pg[76.2b6( v 29425'5676261 lc 29425'5676260 (29296'5672800,29425'5676261] local-les=29449 n=4 ec=20531 les/c 29449/29447 29448/29448/28171) [70,23,214] r=2 lpr=29448 pi=20532-29447/35 luod=0'0 crt=29425'5676261 lcod 0'0 active m=1] submit_push_data: Creating oid 6f648ab6/.dir.hxs1.55076.1.6/head//76 in the temp collection
2017-08-11 15:11:25.123153 7f2a3b327700 10 osd.214 29450 dequeue_op 0x651131200 finish
2017-08-11 15:11:25.138155 7f2b357a1700  5 osd.214 29450 tick
2017-08-11 15:11:25.138186 7f2b357a1700 20 osd.214 29450 scrub_should_schedule should run between 0 - 24 now 15 = yes
2017-08-11 15:11:25.138210 7f2b357a1700 20 osd.214 29450 scrub_should_schedule loadavg 3.34 >= max 0.5 = no, load too high
2017-08-11 15:11:25.138221 7f2b357a1700 20 osd.214 29450 sched_scrub load_is_low=0
2017-08-11 15:11:25.138223 7f2b357a1700 10 osd.214 29450 sched_scrub 76.2a9 high load at 2017-08-10 11:39:35.359828: 99109.8 < max (604800 seconds)
2017-08-11 15:11:25.138235 7f2b357a1700 20 osd.214 29450 sched_scrub done
2017-08-11 15:11:25.138237 7f2b357a1700 10 osd.214 29450 do_waiters -- start
2017-08-11 15:11:25.138239 7f2b357a1700 10 osd.214 29450 do_waiters -- finish
2017-08-11 15:11:25.163988 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.164042 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b4e0260 already has epoch 29450
2017-08-11 15:11:25.268001 7f2aaef77700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450
2017-08-11 15:11:25.268075 7f2ab077a700 20 osd.214 29450 share_map_peer 0x66b657a20 already has epoch 29450

當(dāng)OSD對(duì)應(yīng)的PG狀態(tài)都恢復(fù)正常就可以進(jìn)行下面的收尾操作了。

收尾工作

1. 清理內(nèi)存

   OSD完成數(shù)據(jù)恢復(fù)以后，CPU會(huì)下降，但是內(nèi)存不會(huì)釋放，必須使用前面的命令去釋放內(nèi)存。

   

2. 調(diào)整日志級(jí)別

    ceph tell osd.214 injectargs "--debug_osd=0/5"

3. 刪除ceph.conf里面之前臨時(shí)新加的內(nèi)容

至此bucket shard部分三篇內(nèi)容就分享完了。

“RGW Bucket Shard設(shè)計(jì)與優(yōu)化方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！