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

2025-05-08 19:18 新鈦雲服

新鈦雲服已累計為您分享840篇技術乾貨
系類回顧目標
在本系列的前幾篇文章中，我們探討了Ceph物件儲存的多站點複製配置，以及如何透過專用RGW服務和同步公平性特性最佳化效能。本文將重點介紹如何透過負載均衡實現RGW S3端點的高可用性和效能提升。
RGW S3 的負載均衡
背景介紹
在上一部分中，我們配置了四個 RGW 例項：兩個專用於客戶端 S3 API 請求，其餘用於多站點複製請求。透過此配置，客戶端可以單獨連線到每個 RGW 端點以使用 HTTP Restful S3 API。例如，他們可以使用執行和 RGW 服務的節點之一的 IP/FQDN 作為端點，例如，可以使用AWS s3客戶端發出LIST請求。
以下是 AWS s3 客戶端的示例：
$ aws –endpoint https://ceph-node02 s3 ls 。他們將能夠訪問他們的儲存桶和資料。
問題是，如果ceph-node02宕機了會發生什麼？使用者將開始收到錯誤訊息和失敗的請求，即使其他RGW服務在存活的節點上正常執行。為了避免這種情況，提供高可用性和更高的效能，我們需要在RGW服務前面配置一個負載均衡器。由於RGW端點使用HTTP協議，我們有很多解決方案來實現負載均衡HTTP請求。這些包括基於硬體的商業解決方案以及開源軟體負載均衡器。
我們需要找到一個能夠滿足我們效能需求的解決方案，這取決於我們叢集的規模和效能需求。
Github:https://github.com/mmgaggle/ceph-lb，該Github倉庫有一些比較好的推薦。

站點間複製網路

每個站點的網路必須提供足夠的頻寬來支援複製物件或糾刪碼物件分片的讀寫。我們建議每個站點的網路結構要麼沒有超額訂閱（1:1），要麼超額訂閱最小（例如2:1）。Ceph叢集部署中最常用的網路拓撲之一是Leaf和Spine，因為它具有比較高的可擴充套件性。
參與同一區域組的區域之間的網路將用於非同步複製流量。站點間的頻寬必須等於或大於寫入吞吐量，以防止同步滯後增加和資料丟失的風險。站點間網路不依賴於讀取流量或物件的重構，因為所有物件在本地都是持久的。建議為站點間網路提供路徑多樣性，因為我們通常討論的是WAN連線。站點間網路應該是路由的（L3）而不是交換的（L2擴充套件VLAN），以便在每個站點提供獨立的網路堆疊。最後，即使我們在實驗室示例中沒有這樣做，Ceph物件網關同步應配置為使用HTTPS端點，以在生產中使用SSL/TLS加密複製流量。

Ingress 服務概述

從Pacific版本開始，Ceph提供了基於Keepalived和HAproxy的ingress服務，簡化了高可用性和負載均衡的部署。
ingress服務允許使用最少的配置選項，為 RGW 建立高可用性端點。編排器將部署和管理 HAproxy 和 Keepalived ，以實現不同配置的浮動虛擬 IP 上的負載均衡。
部署ingress服務的主機有多臺。每個主機都有一個 HAproxy 和一個 keepalived。

預設配置

在預設配置下，Keepalived會在其中一個主機上自動配置單個虛擬IP地址（VIP）。這種配置存在以下侷限性：
  • 單點瓶頸：所有負載均衡流量都透過單個主機轉發
  • 效能限制：難以應對高併發客戶端請求
  • 擴充套件性不足：無法充分利用多節點資源

最佳化配置

為了突破這些限制，我們推薦採用以下最佳化方案：
  1. 多VIP配置：
    • 為每個入口節點配置獨立的VIP地址
    • 透過輪詢DNS機制在所有VIP之間分配請求
  2. 效能優勢：
    • 充分利用多主機資源
    • 顯著提升系統吞吐量
    • 實現更高效的請求分發
  3. 擴充套件方案：
    • 對於大規模部署，建議採用更高階的負載均衡方案
    • 使用等價多路徑路由，例如：BGP + ECMP

配置概要

下面主要提供的是一些簡單的配置內容。
多VIP配置示例
virtual_ips_list:  - 192.168.122.150/24  - 192.168.122.151/24  - 192.168.122.152/24
DNS輪詢配置
s3.cephlab.com.    IN    A    192.168.122.150s3.cephlab.com.    IN    A    192.168.122.151s3.cephlab.com.    IN    A    192.168.122.152

方案優勢對比

部署Ingress服務

服務部署架構

在本文中，我們將配置入口負載均衡服務。
Zone1 區域：
  • 節點：ceph-node-02, ceph-node-03
  • 服務：面向外部的RGW服務
Zone2 區域：
  • 節點：ceph-node-06, ceph-node-07
  • 服務：面向外部的RGW服務
在下圖中，簡單描述了整個訪問的架構，透過該架構，我們可以實現物件儲存的負載均衡訪問。

方案優勢

採用先進的多站點複製架構，具備以下核心優勢：
  1. 高可用性（HA）：
    • 自動故障轉移
    • 服務不間斷
  2. 負載均衡：
    • 智慧請求分發
    • 資源利用率最佳化
  3. 擴充套件性：
    • 支援多區域部署
    • 易於橫向擴充套件

配置步驟

  1. 建立服務規範檔案：
    • 服務型別：ingress
    • 指定現有RGW服務名稱：rgw.client-traffic
    • 配置service_id和backend_service引數
  2. 獲取服務資訊：
    我們可以使用cephadm orch ls命令獲取 cephadm 服務的名稱。
[root@ceph-node-00 ~]# ceph orch ls | grep rgwrgw.client-traffic         ?:80002/2  4m ago     3d   count-per-host:1;label:rgwrgw.multisite.zone1        ?:80002/2  9m ago     3d   count-per-host:1;label:rgwsync
3.VIP配置：
    • 每個入口服務守護程序配置一個VIP
    • 每個Ceph叢集配置兩個節點管理入口服務
4.SSL/TLS配置：
    • 啟用HTTPS加密
    • 配置SSL證書
示例配置
[root@ceph-node-00~]# cat << EOF >  rgw-ingress.yamlservice_type: ingressservice_id: rgw.client-trafficplacement:hosts:-ceph-node-02.cephlab.com-ceph-node-03.cephlab.comspec:backend_service: rgw.client-trafficvirtual_ips_list:-192.168.122.150/24-192.168.122.151/24frontend_port: 443monitor_port:  1967ssl_cert: |-----BEGINCERTIFICATE----------ENDCERTIFICATE----------BEGINCERTIFICATE----------ENDCERTIFICATE----------BEGINPRIVATE KEY----------ENDPRIVATE KEY-----EOF[root@ceph-node-00~]# ceph orch apply -i rgw-ingress.yamlScheduledingress.rgw.client update...
[!CAUTION]
注意：入口服務根據我們新增到ssl_cert列表的所有證書構建一個名為HAproxy.pem的單個證書檔案。為了使證書發揮作用，HAproxy 要求您按以下順序新增證書：首先是cert.pem ，然後是鏈證書，最後是私鑰。
很快我們就可以看到我們的 HAproxy 和 Keepalived 服務在ceph-node-[02/03]上執行：
[root@ceph-node-00~]# ceph orch ps | grep -i clienthaproxy.rgw.client.ceph-node-02.icdlxn     ceph-node-02.cephlab.com  *:443,1967running (3d)     9m ago   3d8904k        -2.4.22-f8e3218    0d25561e922f  9e3bc0e21b4bhaproxy.rgw.client.ceph-node-03.rupwfe     ceph-node-03.cephlab.com  *:443,1967running (3d)     9m ago   3d9042k        -2.4.22-f8e3218    0d25561e922f  63cf75019c35keepalived.rgw.client.ceph-node-02.wvtzsr  ceph-node-02.cephlab.com                        running (3d)     9m ago   3d1774k        -2.2.86926947c161f  031802fc4bcdkeepalived.rgw.client.ceph-node-03.rxqqio  ceph-node-03.cephlab.com                        running (3d)     9m ago   3d1778k        -2.2.86926947c161f  3d7539b1ab0f
可以從容器內部檢查 HAproxy 的配置：它在配置為後端的兩個面向客戶端的 RGW 之間使用靜態迴圈負載平衡。前端使用路徑/var/lib/haproxy/haproxy.pem中的證書偵聽埠 443：
[root@ceph-node-02~]# podman exec -it ceph-haproxy-rgw-client-ceph-node-02-jpnuri cat /var/lib/haproxy/haproxy.cfg | grep -A15"frontend frontend"frontendfrontendbind*:443 ssl crt /var/lib/haproxy/haproxy.pemdefault_backendbackendbackendbackendoptionforwardforbalancestatic-rroptionhttpchk HEAD/HTTP/1.0serverrgw.client-traffic.ceph-node-02.yntfqb 192.168.122.94:8000 check weight 100serverrgw.client-traffic.ceph-node-03.enzkpy 192.168.122.180:8000 check weight 100
對於此示例，我們使用負載均衡器 CoreDNS 外掛配置了基本的 DNS 迴圈。我們在所有入口 VIP 配置解析s3.zone1.cephlab.com 。正如在以下示例中看到的，對s3.zone1.cephlab.com的每個請求都會輪詢解析為不同的 Ingress VIP。
[root@ceph-node-00 ~]# ping-c 1 s3.zone1.cephlab.comPINGs3.cephlab.com (192.168.122.150) 56(84) bytesofdata.[root@ceph-node-00 ~]# ping-c 1 s3.zone1.cephlab.comPINGs3.cephlab.com (192.168.122.151) 56(84) bytesofdata.
現在可以將 S3 客戶端指向s3.zone1.cephlab.com以訪問 RGW S3 API 端點。
[root@ceph-node-00 ~]# aws --endpoint https://s3.zone1.cephlab.com:443 s3 ls2024-01-0413:44:00 firstbucket
此時，我們已經為zone1配置了高可用性和負載均衡。如果一臺執行 RGW 服務的伺服器出現故障，客戶端請求將被重定向到另外一臺正常的 RGW 服務。
我們需要對託管zone2第二個 Ceph 叢集執行相同的步驟，最終每一個區域都擁有一個訪問的入口域名：
s3.zone1.cephlab.coms3.zone2.cephlab.com

全域性負載均衡（GLB）配置

作為高可用負載均衡的最後一步，我們可以部署全域性負載均衡器（GLB）。需要注意的是，GLB並非Ceph原生解決方案，需要藉助第三方服務實現。目前市場上有多種DNS全域性負載均衡器可供選擇，它們支援不同的負載均衡策略。
使用 GLB 具有顯著的優點。
具體的優勢如下：
  • SSL/TLS配置：
    • 採用TLS透傳或重新加密方案
    • 確保從客戶端到站點負載均衡器的全程加密
  • 主動/主動模式：
    • 提供單一S3端點FQDN
    • 根據策略將請求路由到最優站點
    • 支援地理位置感知路由
  • 主動/被動災難恢復：
    • 主站點故障時自動切換
    • 使用者無感知故障轉移
    • 顯著降低故障切換時間
在下圖中，我們提供了一個示例，其中新增具有 FQDN s3.cephlab.com的 GLB。客戶端連線到s3.cephlab.com ，並將根據 GLB 級別應用的策略重定向到一個或另一個站點
RGW 複製端點的負載均衡
在之前的配置中，我們為S3客戶端請求配置了負載均衡服務，但尚未討論多站點同步請求的負載均衡問題。在本節中，我們將探討如何在沒有入口服務或外部負載均衡器的情況下，在兩個專用RGW服務之間實現同步請求的負載均衡。

解決方案

1. RGW內建輪詢機制

實現方式：
  • 在區域組（zonegroup）和區域（zone）級別實現輪詢
  • 配置以,分隔的RGW服務IP地址或主機名列表
示例配置：
  1. 多區域組複製端點：
[root@ceph-node-00 ~]# radosgw-admin zonegroup get | jq .endpoints["http://ceph-node-04.cephlab.com:8000","http://ceph-node-05.cephlab.com:8000"]
2. zone1和zone2的複製端點：
[root@ceph-node-00 ~]# radosgw-admin zonegroup get | jq .zones[].endpoints["http://ceph-node-00.cephlab.com:8000","http://ceph-node-01.cephlab.com:8000"]["http://ceph-node-04.cephlab.com:8000","http://ceph-node-05.cephlab.com:8000"]

2. 專用負載均衡器方案

實現方式：
  • 部署專用入口服務
  • 使用HTTP負載均衡器
  • 在區域組和區域端點列表中配置單個FQDN

方案選擇

選擇因素

因素包含配置複雜度，效能，擴充套件性，功能特性，管理成本等，如下表所示：

推薦方案

針對不同的規模場景，推薦的方案如下：
  1. 小型部署：
    • 推薦使用RGW內建輪詢機制
    • 配置簡單，維護成本低
  2. 中大型部署：
    • 推薦使用專用負載均衡器
    • 提供更高階的負載均衡功能
    • 支援更復雜的流量管理策略

最佳實踐

如果負載平衡器至少能提供與配置的專用 RGW 服務迴圈相同的吞吐量，那麼外部負載均衡會更好。舉例來說，如果我們的外部負載均衡是執行在單個虛擬機器上的 HAproxy，只有一個 VIP，而且網路吞吐量有限，那麼我們最好使用 RGW 迴圈複製端點列表選項。對於合併了 2024 年初的 PR 之後的版本，我認為這兩個選項都可以。我們需要權衡兩種方案，一種是隻需為端點設定一個 IP 列表的簡單性，另一種是完整的負載均衡所能提供的更高階功能。
要實現最佳配置，總結為如下條件：
  1. 效能評估：
    • 確保負載均衡器的吞吐量不低於RGW輪詢方案
    • 避免單點效能瓶頸
  2. 配置自動化：
    • 利用RGW管理模組自動生成端點列表
    • 簡化配置流程
  3. 監控與最佳化：
    • 即時監控負載均衡狀態
    • 根據流量模式動態調整策略
總  結
在本系列的第四部分中，我們深入探討了RGW S3端點的負載均衡方案。我們涵蓋了多種負載均衡技術，包括Ceph原生提供的負載均衡器——Ingress服務。
在第五部分中，我們將詳細介紹新的同步策略功能，該功能為物件多站點複製提供精細且靈活的同步策略方案。
如有相關問題，請在文章後面給小編留言，小編安排作者第一時間和您聯絡，為您答疑解惑。
    推薦閱讀   

    推薦影片    

相關文章