1、背景說明
參考說明：
https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/object_gateway_guide_for_ubuntu/administration_cli#configuring-bucket-index-sharding
https://ceph.com/community/new-luminous-rgw-dynamic-bucket-sharding/
1.1、問題描述
性能測試中出現性能暴跌（間歇性性能波動），出現一段時間無法寫入情況（時延一百多秒）
1.2、問題排查
查看rgw日志，發現單桶對象數寫入太多，觸發自動分片resharding操作
[root@node113 ~]# cat /var/log/ceph/ceph-client.rgw.node113.7480.log | grep reshard
2020-09-16 04:51:50.239505 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000009 ret=-16
2020-09-16 06:11:56.304955 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000013 ret=-16
2020-09-16 06:41:58.919390 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000004 ret=-16
2020-09-16 08:02:00.619906 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000002 ret=-16
2020-09-16 08:22:01.038502 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000012 ret=-16
2020-09-16 08:31:58.229956 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000000 ret=-16
2020-09-16 08:52:06.020018 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000006 ret=-16
2020-09-16 09:22:12.882771 7fe71d0a7700 0 RGWReshardLock::lock failed to acquire lock on reshard.0000000000 ret=-16查看rgw相關配置，集群每個分片最大存放10w個對象，當前設置每個桶分片數為8，當寫入對象數超過80w時，則會觸發自動分片操作reshard
[root@node111 ~]# ceph --show-config | grep rgw_dynamic_resharding
rgw_dynamic_resharding = true
[root@node111 ~]# ceph --show-config | grep rgw_max_objs_per_shard
rgw_max_objs_per_shard = 100000
[root@node111 ~]# ceph --show-config | grep rgw_override_bucket_index_max_shards
rgw_override_bucket_index_max_shards = 8
[root@node111 ~]# radosgw-admin bucket limit check
"user_id": "lifecycle01",
"buckets": [
{
"bucket": "cosbench-test-pool11",
"tenant": "",
"num_objects": 31389791,
"num_shards": 370,
"objects_per_shard": 84837,
"fill_status": "OK"
},
{
"bucket": "cycle-1",
"tenant": "",
"num_objects": 999,
"num_shards": 8,
"objects_per_shard": 124,
"fill_status": "OK"
},參數說明
- rgw_dynamic_resharding
[L版官方引入新的參數](https://ceph.com/community/new-luminous-rgw-dynamic-bucket-sharding/，該參數默認開啟，當單個bucketfill_status達到OVER 100.000000%時（objects_per_shard > rgw_max_objs_per_shard），動態進行resharding（裂變新的分片，重新均衡數據）
這個參數有個致命的缺陷，resharding過程中bucket無法進行讀寫，因為元數據對象正在重新分散索引，需要保證一致性，同時，數據量越大時間會越來越長
- rgw_override_bucket_index_max_shards
單個bucket創建分片數，默認參數值為0，最大參數值為7877（即單bucket最大寫入對象數為7877x100000）
分片數參數計算方式為number of objects expected in a bucket / 100,000，若預估單桶對象數為300w，則分片數設置為30（300w/10w）
示例集群分片數為8，即創建bucket時默認創建8個分片，當每個分片對象數超過10w時，繼續resharding創建新的分片，同時重新均衡索引到所有的分片內 - rgw_max_objs_per_shard
單個分片最大存放對象數，默認參數值為10w - rgw_reshard_thread_interval
自動分片線程掃描的間隔，默認為十分鍾
1.3、分片說明
- 索引對象
RGW為每個bucket維護一份索引，里邊存放了bucket中全部對象的元數據。RGW本身沒有足夠有效遍歷對象的能力，bucket索引影響到對象寫入、修改、遍歷功能（不影響讀）。
bucket索引還有其他用處，比如為版本控制的對象維護日志、bucket配額元數據和跨區同步的日志。
默認情況下，每個bucket只有一個索引對象，索引對象過大會導致以下問題，所以每個bucket所能存儲的對象數量有限
--會造成可靠性問題，極端情況下，可能會因為緩慢的數據恢復，導致osd進程掛掉
--會造成性能問題，所有對同一bucket的寫操作，都會對一個索引對象進行修改和序列化操作
- bucket分片
Hammer版本以后，新增bucket分片功能用以解決單桶存儲大量數據的問題，bucket的索引數據可以分布到多個RADOS對象上，bucket存儲對象數量隨着索引數據的分片數量增加而增加。
但這只對新增的bucket有效，需要提前根據bucket最終存放數據量規划分片數。當存儲桶寫入對象超過分片所能承載的最大數時，寫入性能暴跌，此時需要手動修改分片數量，以此去承載更多的對象寫入。
- 動態bucket分片
Luminous版本以后，新增動態 bucket分片功能，隨着存儲對象的增加，RADOSGW 進程會自動發現需要進行分片的 bucket，並安排進行自動分片。
2、解決措施
主要分為以下兩種情況
2.1、確定單bucket最終寫入對象數
關閉動態分片功能（避免調整過程中出現性能暴跌問題），根據最終單bucket寫入對象數設置分片數
示例最終單bucket寫入對象數為300w，設置分片數為30
追加參數配置在/etc/ceph/ceph.conf配置文件[global]字段內
[root@node45 ~]# cat /etc/ceph/ceph.conf
[global]
rgw_dynamic_resharding = false
rgw_max_objs_per_shard = 30
重啟RGW服務進程
[root@node45 ~]# systemctl restart ceph-radosgw.target2.2、不確定單bucket最終寫入對象數
不關閉動態分片功能，大概設置一個分片數
追加參數配置在/etc/ceph/ceph.conf配置文件[global]字段內
[root@node45 ~]# cat /etc/ceph/ceph.conf
[global]
rgw_max_objs_per_shard = 8
重啟RGW服務進程
[root@node45 ~]# systemctl restart ceph-radosgw.target