系列回顾与目标

在本系列的前几篇文章中，我们探讨了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.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服务

在下图中，简单描述了整个访问的架构，通过该架构，我们可以实现对象存储的负载均衡访问。

方案优势

采用先进的多站点复制架构，具备以下核心优势：

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 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:rgwsync

3. 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: |
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
​
    -----BEGIN CERTIFICATE-----
    -----END CERTIFICATE-----
    -----BEGIN PRIVATE KEY-----
    -----END PRIVATE KEY-----
EOF
​
​
[root@ceph-node-00 ~]# ceph orch apply -i rgw-ingress.yaml
Scheduled ingress.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   3d    8904k        -  2.4.22-f8e3218    0d25561e922f  9e3bc0e21b4b
haproxy.rgw.client.ceph-node-03.rupwfe     ceph-node-03.cephlab.com  *:443,1967             running (3d)     9m ago   3d    9042k        -  2.4.22-f8e3218    0d25561e922f  63cf75019c35
keepalived.rgw.client.ceph-node-02.wvtzsr  ceph-node-02.cephlab.com                        running (3d)     9m ago   3d    1774k        -  2.2.8             6926947c161f  031802fc4bcd
keepalived.rgw.client.ceph-node-03.rxqqio  ceph-node-03.cephlab.com                        running (3d)     9m ago   3d    1778k        -  2.2.8             6926947c161f  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"
frontend frontend
    bind *:443 ssl crt /var/lib/haproxy/haproxy.pem
    default_backend backend
​
backend backend
    option forwardfor
    balance static-rr
    option httpchk HEAD / HTTP/1.0
    server rgw.client-traffic.ceph-node-02.yntfqb 192.168.122.94:8000 check weight 100
    server rgw.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
PING s3.cephlab.com (192.168.122.150) 56(84) bytes of data.
[root@ceph-node-00 ~]# ping -c 1 s3.zone1.cephlab.com
PING s3.cephlab.com (192.168.122.151) 56(84) bytes of data.

现在可以将 S3 客户端指向s3.zone1.cephlab.com以访问 RGW S3 API 端点。

[root@ceph-node-00 ~]# aws --endpoint https://s3.zone1.cephlab.com:443 s3 ls
2024-01-04 13: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地址或主机名列表

示例配置：

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服务。

在第五部分中，我们将详细介绍新的同步策略功能，该功能为对象多站点复制提供精细且灵活的同步策略方案。