我們一起聊聊負載均衡實現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）。這種配置存在以下局限性：
- 單點瓶頸：所有負載均衡流量都通過單個主機轉發
- 性能限制：難以應對高并發客戶端請求
- 擴展性不足：無法充分利用多節點資源
優化配置
為了突破這些限制，我們推薦采用以下優化方案：
- 多VIP配置：
- 為每個入口節點配置獨立的VIP地址
- 通過輪詢DNS機制在所有VIP之間分配請求
- 性能優勢：
- 充分利用多主機資源
- 顯著提升系統吞吐量
- 實現更高效的請求分發
- 擴展方案：
- 對于大規模部署，建議采用更高級的負載均衡方案
- 使用等價多路徑路由，例如：BGP + ECMP
配置概要
下面主要提供的是一些簡單的配置內容。
多VIP配置示例
virtual_ips_list:
- 192.168.122.150/24
- 192.168.122.151/24
- 192.168.122.152/24DNS輪詢配置
s3.cephlab.com. IN A 192.168.122.150
s3.cephlab.com. IN A 192.168.122.151
s3.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服務
在下圖中，簡單描述了整個訪問的架構，通過該架構，我們可以實現對象存儲的負載均衡訪問。
圖片
方案優勢
采用先進的多站點復制架構，具備以下核心優勢：
- 高可用性（HA）：
- 自動故障轉移
- 服務不間斷
- 負載均衡：
- 智能請求分發
- 資源利用率優化
- 擴展性：
- 支持多區域部署
- 易于橫向擴展
配置步驟
- 創建服務規范文件：
- 服務類型：ingress
- 指定現有RGW服務名稱：rgw.client-traffic
- 配置service_id和backend_service參數
- 獲取服務信息：我們可以使用cephadm orch ls命令獲取 cephadm 服務的名稱。
[root@ceph-node-00 ~]# ceph orch ls | grep rgw
rgw.client-traffic ?:8000 2/2 4m ago 3d count-per-host:1;label:rgw
rgw.multisite.zone1 ?:8000 2/2 9m ago 3d count-per-host:1;label:rgwsync3.VIP配置：
- 每個入口服務守護進程配置一個VIP
- 每個Ceph集群配置兩個節點管理入口服務
4.SSL/TLS配置：
- 啟用HTTPS加密
- 配置SSL證書
示例配置
[root@ceph-node-00~]# cat << EOF > rgw-ingress.yaml
service_type: ingress
service_id: rgw.client-traffic
placement:
hosts:
-ceph-node-02.cephlab.com
-ceph-node-03.cephlab.com
spec:
backend_service: rgw.client-traffic
virtual_ips_list:
-192.168.122.150/24
-192.168.122.151/24
frontend_port: 443
monitor_port: 1967
ssl_cert: |
-----BEGINCERTIFICATE-----
-----ENDCERTIFICATE-----
-----BEGINCERTIFICATE-----
-----ENDCERTIFICATE-----
-----BEGINPRIVATE KEY-----
-----ENDPRIVATE KEY-----
EOF
[root@ceph-node-00~]# ceph orch apply -i rgw-ingress.yaml
Scheduledingress.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 client
haproxy.rgw.client.ceph-node-02.icdlxn ceph-node-02.cephlab.com *:443,1967 running (3d) 9m ago 3d8904k - 2.4.22-f8e3218 0d25561e922f 9e3bc0e21b4b
haproxy.rgw.client.ceph-node-03.rupwfe ceph-node-03.cephlab.com *:443,1967 running (3d) 9m ago 3d9042k - 2.4.22-f8e3218 0d25561e922f 63cf75019c35
keepalived.rgw.client.ceph-node-02.wvtzsr ceph-node-02.cephlab.com running (3d) 9m ago 3d1774k - 2.2.86926947c161f 031802fc4bcd
keepalived.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 -A 15 "frontend frontend"
frontendfrontend
bind*:443 ssl crt /var/lib/haproxy/haproxy.pem
default_backendbackend
backendbackend
optionforwardfor
balancestatic-rr
optionhttpchk HEAD / HTTP/1.0
serverrgw.client-traffic.ceph-node-02.yntfqb 192.168.122.94:8000 check weight 100
serverrgw.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.com
PINGs3.cephlab.com (192.168.122.150) 56(84) bytesofdata.
[root@ceph-node-00 ~]# ping-c 1 s3.zone1.cephlab.com
PINGs3.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 ls
2024-01-0413:44:00 firstbucket此時，我們已經為zone1配置了高可用性和負載均衡。如果一臺運行 RGW 服務的服務器出現故障，客戶端請求將被重定向到另外一臺正常的 RGW 服務。
我們需要對托管zone2第二個 Ceph 集群執行相同的步驟，最終每一個區域都擁有一個訪問的入口域名：
s3.zone1.cephlab.com
s3.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地址或主機名列表
示例配置：
- 多區域組復制端點：
[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
方案選擇
選擇因素
因素包含配置復雜度，性能，擴展性，功能特性，管理成本等，如下表所示：
圖片
推薦方案
針對不同的規模場景，推薦的方案如下：
- 小型部署：
- 推薦使用RGW內置輪詢機制
- 配置簡單，維護成本低
- 中大型部署：
- 推薦使用專用負載均衡器
- 提供更高級的負載均衡功能
- 支持更復雜的流量管理策略
最佳實踐
如果負載平衡器至少能提供與配置的專用 RGW 服務循環相同的吞吐量，那么外部負載均衡會更好。舉例來說，如果我們的外部負載均衡是運行在單個虛擬機上的 HAproxy，只有一個 VIP，而且網絡吞吐量有限，那么我們最好使用 RGW 循環復制端點列表選項。對于合并了 2024 年初的 PR 之后的版本，我認為這兩個選項都可以。我們需要權衡兩種方案，一種是只需為端點設置一個 IP 列表的簡單性，另一種是完整的負載均衡所能提供的更高級功能。
要實現最佳配置，總結為如下條件：
- 性能評估：
- 確保負載均衡器的吞吐量不低于RGW輪詢方案
- 避免單點性能瓶頸
- 配置自動化：
- 利用RGW管理模塊自動生成端點列表
- 簡化配置流程
- 監控與優化：
- 實時監控負載均衡狀態
- 根據流量模式動態調整策略
總 結
在本系列的第四部分中，我們深入探討了RGW S3端點的負載均衡方案。我們涵蓋了多種負載均衡技術，包括Ceph原生提供的負載均衡器——Ingress服務。
在第五部分中，我們將詳細介紹新的同步策略功能，該功能為對象多站點復制提供精細且靈活的同步策略方案。
