前言：

        由(you)于對(dui)象(xiang)(xiang)存儲主要運用于影像、多媒體等數(shu)據規模(mo)較大的(de)場景，單個bucket的(de)對(dui)象(xiang)(xiang)數(shu)量通常(chang)(chang)在(zai)千萬甚至上(shang)億(yi)規模(mo)，在(zai)對(dui)對(dui)象(xiang)(xiang)存儲日常(chang)(chang)巡檢和運維的(de)時(shi)候，經常(chang)(chang)會遇到對(dui)象(xiang)(xiang)存儲的(de)索引存儲池(chi)出(chu)現(xian)large objects告警(jing)，影響數(shu)據訪問速(su)度，甚至出(chu)現(xian)slow requests告警(jing)，進而導致存儲集群服務異常(chang)(chang)。針對(dui)這(zhe)種(zhong)情況，下面(mian)我們介紹出(chu)現(xian)這(zhe)種(zhong)告警(jing)后的(de)分(fen)析處(chu)理方(fang)式(shi)。

原因分析：

       當對象(xiang)存儲(chu)(chu)單個bucket存儲(chu)(chu)的(de)對象(xiang)數量過多，超過閾值(zhi)(zhi)后(hou)，將引(yin)發集群large omap objects告警，以對象(xiang)存儲(chu)(chu)索引(yin)池為(wei)例：閾值(zhi)(zhi)上(shang)限為(wei)    bucket_index_max_shard*osd_deep_scrub_large_omap_object_key_threshold。

如果不及時(shi)處理，將影(ying)響(xiang)這個bucket的(de)讀寫性能，甚至會給集群(qun)故障埋下隱患(huan)。

處理步驟：

處理思路：

向上調整(zheng)osd_deep_scrub_large_omap_object_key_threshold消除告警(jing)，但是單個shard的對象(xiang)數量過大時，會影響bucket的查詢性能，不推薦。

增加shard數量(liang)，保(bao)持單個shard的(de)閾(yu)值(zhi)(zhi)不變，通過(guo)增加shard的(de)操作消除告(gao)警，默(mo)認(ren)shard值(zhi)(zhi)為16，osd_deep_scrub_large_omap_object_key_threshold默(mo)認(ren)值(zhi)(zhi)為20萬(wan)，單個bucket不產生large omap objects告(gao)警的(de)對象數量(liang)為320萬(wan)，調(diao)整(zheng)bucket_index_max_shard為128，bucket對象數量(liang)閾(yu)值(zhi)(zhi)變為2560萬(wan)，已經滿(man)足大部分場景的(de)需(xu)求，同是，對性能的(de)影響很小。所以此(ci)次我們采用此(ci)方(fang)法(fa)來處(chu)理(li)告(gao)警，方(fang)法(fa)如下：

1. 先找到出現問題的pool

ceph health detail

2. 找到對應的PG

ceph pg ls-by-pool |awk '{print "ceph pg "$1 " query|grep num_large_omap_objects"}'|sh -x

3. 找到對應的OSD

4. 查看OSD日志找到bucket

zcat ceph-osd.40.log-20190614.gz |grep omap

5. 根據對象ID確定bucket名稱

radosgw-admin bucket stats --bucket-id=8b824a20-985f-11e8-a8d1-0cc47a57b678.225330637.1 > buckets.json

有報錯可以忽略(lve)，查看buckets.json，根據關鍵字8b824a20-985f-11e8-a8d1-0cc47a57b678.225330637.1找到bucket名

6. 備份原bucket的index為本地文件

100W個對象(xiang)的(de)index大約占用1GB備份(fen)文(wen)件空間

radosgw-admin bi list --bucket=dutestreshard1 > dutestreshard1.list.backup

若后續操(cao)作出(chu)現問題，恢復index的操(cao)作為

radosgw-admin bi put --bucket= < .list.backup

7. 修改zonegroup的bucket_index_max_shards

此值(zhi)不宜過大不宜太小，依(yi)據集(ji)群規模和單(dan)桶對象數(shu)設(she)計，每(mei)個shard超過20W條index就(jiu)會產生告(gao)警

radosgw-admin zonegroup get > zonegroup.json

radosgw-admin zonegroup set < zonegroup.json

radosgw-admin period update --commit

8. 關閉所有rgw，避免reshard操作時新數據變更

systemctl stop ceph-radosgw.target

9. 執行bucket reshard操作

注意記(ji)錄新老bucket id, 100W對象reshard時(shi)間約30秒(miao)

10. reshard后檢查，bucket id和marker信息應改變

11. 啟動rgw，驗證數據正確性和bucket可操作性

systemctl start ceph-radosgw.target

12. 刪除reshard前的舊的bucket index instance，

注意此處的bucket-id為第九步的old bucket instance id，刪除耗時較久，耐心等(deng)待其執行完(wan)成

radosgw-admin bi purge --bucket="dutestreshard1" --bucket-id=8b824a20-985f-11e8-a8d1-0cc47a57b678.225330637.1

總結

        從以上處理(li)步驟可以看到我們主要通過提(ti)高(gao)bucket的(de)(de)shard數(shu)(shu)量和單個shard的(de)(de)object數(shu)(shu)量，來處理(li)large omap objects告(gao)警(jing)，單個bucket的(de)(de)對象數(shu)(shu)量還(huan)是存(cun)在理(li)論上閾(yu)值，為了保持存(cun)儲環(huan)境(jing)的(de)(de)可靠性和數(shu)(shu)據安全，在規(gui)劃數(shu)(shu)據存(cun)儲環(huan)境(jing)時(shi)，應(ying)該根據業務(wu)(wu)數(shu)(shu)量規(gui)模，合理(li)規(gui)劃bucket相(xiang)關參數(shu)(shu)，同時(shi)，對使用(yong)業務(wu)(wu)方進行相(xiang)關知識普及，引導使用(yong)者根據業務(wu)(wu)類型、數(shu)(shu)據類型、組織架構等(deng)規(gui)劃不同的(de)(de)bucket，避免出現超(chao)大數(shu)(shu)量規(gui)模的(de)(de)bucket，為數(shu)(shu)據存(cun)儲服務(wu)(wu)可靠、安全、高(gao)效保駕護航。