系列回顾与目标

在本系列的前两部分中，我们介绍了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 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 提供了显着改进的同步时间。

总结

在本系列的第三部分中，我们深入探讨了两个关键内容：

1. 专用RGW服务配置

   详细讲解了如何为客户端请求和复制请求配置独立的RGW服务

   分析了这种配置方式的优势，包括资源隔离、性能优化和故障排查简化

2. 同步公平性特性

   介绍了Reef版本中引入的这一重要改进

   通过实际测试数据展示了其在负载均衡和性能提升方面的显著效果

在即将到来的第四部分中，我们将重点关注：

• 面向客户端的RGW端点的负载均衡配置

• 高可用性架构的最佳实践

• 性能调优技巧