Ceph物件儲存多站點複製：第三部分

2025-04-21 16:56 新鈦雲服

新鈦雲服已累計為您分享839篇技術乾貨
系列回顧與目標
在本系列的前兩部分中，我們介紹了Ceph物件儲存的多站點特性，並詳細講解了如何在兩個Ceph叢集之間配置多站點複製。第三部分將重點討論如何最佳化多站點複製的效能，包括配置專用的RGW服務以及介紹Reef版本中引入的"複製同步公平性"特性。
多站點複製專用RGW服務
在每個Ceph叢集中，我們配置了兩個RGW服務。預設情況下，這些RGW服務同時處理客戶端S3請求和站點間的複製請求，共享資源和處理時間。為了最佳化這一配置，我們可以將RGW服務分為兩組：
  1. 客戶端請求處理組：專門處理客戶端S3請求
  2. 複製請求處理組：專門處理多站點複製請求
這種配置方式雖然不是強制性的，但能帶來以下優勢：
  • 資源獨立擴充套件：可以根據效能需求（如吞吐量或延遲）獨立擴充套件客戶端和複製RGW服務
  • 避免任務衝突：防止複製同步因客戶端請求繁忙而停滯，反之亦然
  • 簡化故障排查：專用RGW服務可以簡化問題診斷，複製日誌和客戶端日誌不會混雜
  • 網路隔離：可以為不同RGW組配置不同網路，實現安全隔離
    • 對外提供服務的的 RGW 可以使用網路 A
    • 對內複製服務的 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 rgwAdded label rgw to host ceph-node-02.cephlab.com[root@ceph-node-00 ~]#  ceph orch host label add ceph-node-03.cephlab.com rgwAdded 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.specservice_type: rgwservice_id: client-trafficplacement:  label: rgw  count_per_host: 1networks:- 192.168.122.0/24spec:  rgw_frontend_port: 8000  rgw_realm: multisite  rgw_zone: zone1  rgw_zonegroup: multizgEOF
3.應用配置並驗證
我們應用規範檔案並檢查現在是否有四個新服務正在執行：兩個用於多站點複製，另一個用於客戶端流量。
檢查服務狀態：
[root@ceph-node-00 ~]# ceph orch apply -i spec-rgw.yamlScheduled rgw.rgw-client-traffic update…[root@ceph-node-00 ~]# ceph orch ps | grep rgwrgw.multisite.zone1.ceph-node-00.mwvvel     ceph-node-00.cephlab.com  *:8000                running (2h)      6m ago   2h190M        -  18.2.0-131.el9cp463bf5538482  dda6f58469e9rgw.multisite.zone1.ceph-node-01.fwqfcc     ceph-node-01.cephlab.com  *:8000                running (2h)      6m ago   2h184M        -  18.2.0-131.el9cp463bf5538482  10a45a616c44rgw.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.el9cp463bf5538482  0bc65ad993b1rgw.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.el9cp463bf5538482  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_threadtrue
現在，我們將引數更改為 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 提供了顯著改進的同步時間。
總  結
在本系列的第三部分中，我們深入探討了兩個關鍵內容：
  1. 專用RGW服務配置
    詳細講解了如何為客戶端請求和複製請求配置獨立的RGW服務
    分析了這種配置方式的優勢，包括資源隔離、效能最佳化和故障排查簡化
  2. 同步公平性特性
    介紹了Reef版本中引入的這一重要改進
    透過實際測試資料展示了其在負載均衡和效能提升方面的顯著效果
在即將到來的第四部分中，我們將重點關注：
  • 面向客戶端的RGW端點的負載均衡配置
  • 高可用性架構的最佳實踐
  • 效能調優技巧
如有相關問題，請在文章後面給小編留言，小編安排作者第一時間和您聯絡，為您答疑解惑。
    推薦閱讀   

    推薦影片    

相關文章