一起聊聊 Ceph 對象存儲多站點復制的性能

作者：祝祥 2025-04-16 08:01:05

存儲存儲架構

在每個Ceph集群中，我們配置了兩個RGW服務。默認情況下，這些RGW服務同時處理客戶端S3請求和站點間的復制請求，共享資源和處理時間。

在本系列的前兩部分中，我們介紹了Ceph對象存儲的多站點特性，并詳細講解了如何在兩個Ceph集群之間配置多站點復制。第三部分將重點討論如何優化多站點復制的性能，包括配置專用的RGW服務以及介紹Reef版本中引入的"復制同步公平性"特性。

多站點復制專用RGW服務

在每個Ceph集群中，我們配置了兩個RGW服務。默認情況下，這些RGW服務同時處理客戶端S3請求和站點間的復制請求，共享資源和處理時間。為了優化這一配置，我們可以將RGW服務分為兩組：

客戶端請求處理組：專門處理客戶端S3請求
復制請求處理組：專門處理多站點復制請求

這種配置方式雖然不是強制性的，但能帶來以下優勢：

資源獨立擴展：可以根據性能需求（如吞吐量或延遲）獨立擴展客戶端和復制RGW服務
避免任務沖突：防止復制同步因客戶端請求繁忙而停滯，反之亦然
簡化故障排查：專用RGW服務可以簡化問題診斷，復制日志和客戶端日志不會混雜
網絡隔離：可以為不同RGW組配置不同網絡，實現安全隔離

a.對外提供服務的的 RGW 可以使用網絡 A

b.對內復制服務的 RGW 可以使用網絡 B

配置多站點部署時，通常的做法是將特定 RGW 服務專用于客戶端操作，將其他 RGW 服務專用于多站點復制。

默認情況下，所有 RGW 都參與多站點復制。需要執行兩個步驟才能將 RGW 排除在多站點復制同步之外。

為 RGW 設置此 Ceph 選項：ceph config set ${KEY_ID} rgw_run_sync_thread false。如果為 false，則阻止此對象存儲的網關傳輸多站點復制數據
前面的參數只是告訴RGW不要發送復制數據，但可以繼續接收。為了避免接收，我們需要從區域組和區域復制端點中刪除 RGW。

配置專用RGW服務

在上一章中，我們為每個 Ceph 集群配置了兩個 RGW，它們當前為客戶端 S3 請求和復制請求流量提供服務。在以下步驟中，我們將為每個集群配置兩個額外的 RGW，以便每個集群內總共有四個 RGW。在這四個 RGW 中，兩個將專用于服務客戶端請求，另外兩個將專用于服務多站點復制。

1.添加主機標簽

我們使用標簽來控制RGW服務的調度和部署。對于面向客戶端的RGW服務，我們使用rgw標簽：

[root@ceph-node-00 ~]#  ceph orch host label add ceph-node-02.cephlab.com rgw
Added label rgw to host ceph-node-02.cephlab.com
[root@ceph-node-00 ~]#  ceph orch host label add ceph-node-03.cephlab.com rgw
Added label rgw to host ceph-node-03.cephlab.com

我們為面向公眾的 RGW 創建 RGW 規范文件。在此示例中，我們對所有 RGW 服務使用相同的 CIDR 網絡。不過，如果需要，我們可以為部署的不同 RGW 集配置不同的網絡 CIDR。我們使用與已運行的服務相同的領域、區域組和區域，因為我們希望所有 RGW 屬于同一個領域命名空間。

2.創建RGW配置文件

為面向客戶端的RGW服務創建配置文件：

[root@ceph-node-00 ~]# cat << EOF >> /root/rgw-client.spec
service_type: rgw
service_id: client-traffic
placement:
  label: rgw
  count_per_host: 1
networks:
- 192.168.122.0/24
spec:
  rgw_frontend_port: 8000
  rgw_realm: multisite
  rgw_zone: zone1
  rgw_zonegroup: multizg
EOF

3.應用配置并驗證

我們應用規范文件并檢查現在是否有四個新服務正在運行：兩個用于多站點復制，另一個用于客戶端流量。

檢查服務狀態：

[root@ceph-node-00 ~]# ceph orch apply -i spec-rgw.yaml
Scheduled rgw.rgw-client-traffic update…
[root@ceph-node-00 ~]# ceph orch ps | grep rgw
rgw.multisite.zone1.ceph-node-00.mwvvel     ceph-node-00.cephlab.com  *:8000                running (2h)      6m ago   2h     190M        -  18.2.0-131.el9cp  463bf5538482  dda6f58469e9
rgw.multisite.zone1.ceph-node-01.fwqfcc     ceph-node-01.cephlab.com  *:8000                running (2h)      6m ago   2h     184M        -  18.2.0-131.el9cp  463bf5538482  10a45a616c44
rgw.client-traffic.ceph-node-02.ozdapg  ceph-node-02.cephlab.com  192.168.122.94:8000   running (84s)    79s ago  84s    81.1M        -  18.2.0-131.el9cp  463bf5538482  0bc65ad993b1
rgw.client-traffic.ceph-node-03.udxlvd  ceph-node-03.cephlab.com  192.168.122.180:8000  running (82s)    79s ago  82s    18.5M        -  18.2.0-131.el9cp  463bf5538482  8fc7d6b06b54

4.禁用復制流量

要禁用RGW服務的復制流量，需要完成以下兩個步驟：

禁用同步線程
從zonegroup/zone配置中移除復制端點

首先禁用rgw_run_sync_thread，要做的第一件事是使用ceph config命令禁用rgw_run_sync_thread 。我們指定服務名稱client.rgw.client-traffic以同時在兩個面向客戶端的 RGW 上應用更改。我們首先檢查rgw_run_sync_thread的當前配置并確認它默認設置為 true。

[root@ceph-node-00 ~]# ceph config get client.rgw.client-traffic rgw_run_sync_thread
true

現在，我們將參數更改為 false，以便為這組 RGW 禁用同步線程。

[root@ceph-node-00 ~]# ceph config set client.rgw.client-traffic  rgw_run_sync_thread false
[root@ceph-node-00 ~]# ceph config get client.rgw.client-traffic rgw_run_sync_thread false

第二步是確保我們部署的新 RGW 不會在區域組配置中列為復制端點。我們不應該看到ceph-node-02或ceph-node-03在zone1下列為端點：

[root@ceph-node-00 ~]# radosgw-admin zonegroup get | jq '.zones[]|.name,.endpoints'
"zone1"
[
  "http://ceph-node-00.cephlab.com:8000",
  "http://ceph-node-01.cephlab.com:8000"
]
"zone2"
[
  "http://ceph-node-04.cephlab.com:8000",
  "http://ceph-node-05.cephlab.com:8000"
]

請注意，必須為此任務安裝 JSON 解析實用程序jq 。

確認后，我們就完成了這部分的配置，并在集群中運行了針對每種類型請求的專用服務：客戶端取消請求和復制請求。

需要重復相同的步驟，將相同的配置應用到我們的第二個集群zone2 。

Reef 版本中的新性能改進

Reef版本引入了對象存儲多站點復制的改進特性——"復制同步公平性"。這一改進解決了早期版本中復制工作分配不均的問題。在早期版本中，一個RGW會獨占復制操作鎖，導致其他RGW服務難以獲取鎖，從而無法通過增加RGW服務數量來線性提升多站點復制性能。

Quincy版本在復制工作分配方面已經做出了顯著改進。而在Reef版本中，通過同步公平性特性，復制數據和元數據得以在所有RGW服務之間均勻分配，使它們能夠更高效地協作完成復制任務。

感謝IBM存儲DFG團隊進行的規模測試，驗證了同步公平性特性的改進效果。在測試中，DFG團隊比較了配置多站點復制的Ceph Reef、Quincy和Pacific版本在對象寫入時的表現。

以下是DFG提供的測試結果，比較了每種測試情況下各同步RGW的參與度。圖表繪制了每15分鐘采集一次的avgcount（數據同步獲取的對象數和字節數）。理想情況下，所有同步RGW應均勻分擔負載。

在這個示例中，請注意Pacific版本（RHCS 5.3，藍色線）的表現：

一個RGW處理約1300萬對象（次級同步1800萬）
其他兩個RGW分別處理500萬和150萬對象
同步時間超過24小時

相比之下，Reef版本（RHCS 7，綠色線）的表現：

所有RGW處理量相近（500-700萬對象）
同步時間顯著縮短，不到19小時
各RGW負載均衡，綠色線緊密相鄰

圖表中同色線條越接近，說明同步參與度越好。如您所見，Reef版本的綠色線條非常接近，表明三個測試配置的同步RGW均勻分擔了復制工作負載。

圖片

在下圖中，我們顯示了每個版本將完整工作負載（小對象）同步到其他區域所需的時間：時間越少越好。我們可以看到，此處標記為7 Reef 提供了顯著改進的同步時間。

圖片

總結

在本系列的第三部分中，我們深入探討了兩個關鍵內容：

專用RGW服務配置詳細講解了如何為客戶端請求和復制請求配置獨立的RGW服務分析了這種配置方式的優勢，包括資源隔離、性能優化和故障排查簡化
同步公平性特性介紹了Reef版本中引入的這一重要改進通過實際測試數據展示了其在負載均衡和性能提升方面的顯著效果

責任編輯：武曉燕來源：新鈦云服

Ceph 對象存儲