Ceph 对象存储多站点复制系列。第三部分
Ceph 对象存储多站点复制系列 ¶
在上一集里，我们通过 rgw 管理器模块配置了 Ceph 对象存储多站点复制的示例。
多站点复制专用 RGW ¶
我们为每个 Ceph 集群设置了两个 RGW。默认情况下，RGW 服务管理来自客户端的 S3 请求以及站点之间的复制请求。RGW 服务在两项任务之间共享其资源和处理时间。为了改进此配置，我们可以分配一个特定的 RGW 子集来管理客户端 S3 请求，并分配另一个 RGW 子集来管理两个 Ceph 集群之间的多站点复制请求。
使用这种方法不是强制性的，但会提供以下好处
由于我们有一组专门用于公共和多站点复制的资源，因此可以根据需要在更高的性能（例如更高的吞吐量或更低的延迟）方面独立扩展面向客户端和复制 RGW 的子集。
隔离的 RGW 可以避免同步复制停滞，因为 RGW 忙于面向客户端的任务，反之亦然。
改进了故障排除：专门的 RGW 子集可以改善故障排除体验，因为我们可以根据具体问题定位要调查的 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 不要发送复制数据，但它仍然可以接收数据。为了也避免接收数据，我们需要从 zonegroup 和 zone 复制端点中删除 RGW。
配置用于公共和复制请求的专用 RGW 服务。 ¶
在上一章中，我们配置了每个 Ceph 集群的两个 RGW，它们目前同时提供客户端 S3 请求和复制请求流量。在以下步骤中，我们将配置每个集群中的另外两个 RGW，总共每个集群四个 RGW。在这四个 RGW 中，两个将专门用于提供客户端请求，而另外两个将专门用于提供多站点复制。下图说明了我们想要实现的目标。
我们将使用标签来控制 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。我们使用与我们已经运行的服务相同的 realm、zonegroup 和 zone，因为我们希望所有 RGW 属于相同的 realm 命名空间。
[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
我们应用规范文件并检查现在是否运行了四个新服务：两个用于多站点复制，另一个用于客户端流量。
[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
如我们在本节开始时提到的，要禁用 RGW 上的复制流量，我们需要确保两件事：
- 已禁用同步线程
- RGW 未列在 zonegroup / zone 配置中的复制端点中
因此，首先使用 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 未列在 zonegroup 配置中的复制端点中。我们不应该在 zone1 下看到 ceph-node-02 或 ceph-node-03 列出为端点
[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。
7.0 中的新性能改进！复制同步公平性 ¶
Reef 版本引入了对象存储多站点复制中的一项改进，称为“复制同步公平性”。这项改进解决了早期版本中遇到的复制工作没有得到优化分配的问题。在早期版本中，一个 RGW 会获取复制操作的锁，而其他 RGW 服务很难获得该锁。这导致多站点复制在添加额外的 RGW 服务时无法线性扩展。为了改进复制工作的分配，Quincy 版本中进行了重大改进。但是，借助 Reef 中的同步公平性，复制数据和元数据将在所有 RGW 服务之间均匀分布，使它们能够更有效地协作完成复制任务。
感谢 IBM Storage DFG 团队运行规模测试，以突出显示并验证同步公平性功能引入的改进。在测试期间，DFG 团队将 Ceph Reef 与 Quincy 和 Pacific 进行比较，配置了多站点复制的对象摄取。
DFG 提供的以下结果比较了每个测试用例中每个同步 RGW 的参与程度。图表绘制了每十五分钟轮询的 avgcount（通过数据同步获取的对象和字节数）。最佳结果是所有同步 RGW 均匀地分担负载。
在此示例中，请注意，其中一个 Pacific RGW（蓝色线标有 RHCS 5.3）处理了 13M 范围内的对象（二级同步为 18M），而其他两个 RGW 处理了 500 万和 150 万，导致同步时间更长：超过 24 小时。但是，Reef RGW（绿色线标有 RHCS 7）RGW 都在彼此接近的范围内。每个处理 5M 到 7M 个对象，并且同步速度更快，远低于 19 小时。
图表中同色线条越接近，同步参与度越高。如您所见，对于 Reef，绿色线条非常接近，这意味着复制工作负载在配置测试的三个同步 RGW 之间均匀分布。
在下图中，我们展示了每个版本将完整工作负载（小对象）同步到其他区域所需的时间：时间越短越好。我们可以看到，这里标有 7 的 Reef 提供了显著改进的同步时间。
总结与下一步 ¶
总而言之，在本系列的第三部分中，我们讨论了为公共和复制请求配置专用 RGW 服务。此外，我们还探讨了同步公平性功能提供的性能增强。在第四部分中，我们将深入研究平衡面向客户端的 RGW 端点。
脚注 ¶
作者谨此感谢 IBM 对社区的支持，通过促使我们有时间创建这些帖子。