Ceph 对象存储多站点复制系列。第五部分
IBM Storage Ceph 对象存储多站点复制系列 第五部分 ¶
在上一篇博文中，我们讨论了负载均衡 RGW S3 端点的一切。我们涵盖了多种负载均衡技术，包括捆绑的 Ceph 提供的负载均衡器和 Ingress 服务。 在本系列第五篇文章中，我们将详细讨论多站点同步策略。
多站点同步策略介绍 ¶
从 Quincy 版本开始的 Ceph 发布版，Ceph 对象存储提供细粒度的存储桶级别复制，解锁了许多有价值的功能。用户可以为单个存储桶启用或禁用同步，从而可以精确控制复制工作流程。这使得全区域复制成为可能，同时可以选择退出特定存储桶的复制，将单个源存储桶复制到多个目标存储桶，并实现对称和定向数据流配置。下图显示了同步策略功能的一个示例
使用我们以前的同步模型，我们将执行全区域同步，这意味着所有数据和元数据将在区域之间同步。新的同步策略功能为我们提供了新的灵活性和粒度，使我们能够配置每个存储桶的复制。
存储桶同步策略适用于归档区域。从归档区域的移动不是双向的，其中所有对象都可以从活动区域移动到归档区域。但是，您无法从归档区域移动对象到活动区域，因为归档区域是只读的。我们将在博客系列的第六部分中详细介绍归档区域。
以下是 Quincy 和 Reef 版本中可用的功能列表
Qunicy ¶
- 一对一存储桶复制
- 区域组级别策略配置
- 存储桶级别策略配置
- 可配置的数据流 - 对称
- 仅支持 Greenfield/新的多站点部署
Reef ¶
- 对象名称过滤
- 从遗留多站点同步（全区域复制）迁移到同步策略（在区域组或存储桶级别）
- 归档区域同步策略（启用/禁用到归档区域的每个存储桶复制）
- 数据流 - 对称或定向
- 部分用户 S3 复制 API (GetBucketReplication, PutBucketReplication, DeleteBucketReplication)
- 同步到和从不同的存储桶（一对一或一对多）
- 目标参数修改：存储类、目标所有者转换、用户模式
在开始动手操作之前，我们需要了解一些同步策略概念
- 组：我们有一个或多个组，可以包含数据流配置列表
- 数据流：定义了区域之间复制的数据流。它可以定义对称数据流，其中多个区域同步数据。它还可以定义定向数据流，其中数据从一个区域单向移动到另一个区域。
- 管道：管道定义了可以使用这些数据流及其相关属性的区域和存储桶。
同步策略组可以处于三种状态
已启用：- 允许并启用了同步。启用后将开始复制。例如，我们可以启用全区域组同步，然后禁用（禁止）每个存储桶的基础。允许：允许同步。允许复制，但不会开始。例如，我们可以将区域组策略配置为允许，然后启用每个存储桶的策略同步。禁止：根据此组定义的同步不允许。
我们可以在区域组和存储桶级别配置同步策略（组、流和管道）。存储桶同步策略始终是其所属区域组定义的策略的子集。因此，例如，如果我们不允许区域组级别上的流，即使在存储桶级别上允许，它也不会起作用。官方文档中有关于预期行为的更多详细信息。
多站点同步策略配置 ¶
以下部分将解释如何使用新的多站点同步策略功能。默认情况下，一旦我们设置了多站点复制，就像在本系列的第一篇文章中所做的那样，所有元数据和数据都将在区域组中的区域之间复制。在本文的其余部分中，我们将这种同步方法称为 遗留。
如前所述，同步策略由组、流和管道组成。我们首先配置一个区域组策略，该策略非常宽松，将允许所有存储桶在所有区域的双向流量。设置后，我们将添加每个存储桶的同步策略，这些策略本质上是区域组策略的子集，具有更严格的规则集。
我们首先添加区域组策略。我们创建一个名为 group1 的新组，并将状态设置为 允许。回想一下，区域组将允许同步流量流动。策略将设置为 允许 而不是 启用。当处于 允许 状态时，区域组级别不会发生数据同步，其想法是在每个存储桶的基础上启用同步。
[root@ceph-node-00 ~]# radosgw-admin sync group create --group-id=group1 --status=allowed --rgw-realm=multisite --rgw-zonegroup=multizg
我们现在创建一个对称/双向流，允许数据在我们的区域之间双向同步：zone1 和 zone2。
[root@ceph-node-00 ~]# radosgw-admin sync group flow create --group-id=group1 --flow-id=flow-mirror --flow-type=symmetrical --zones=zone1,zone2
最后我们创建一个管道。在管道中，我们指定要使用的组 ID，然后为源和目标存储桶和区域设置星号通配符，这意味着所有区域和存储桶都可以用作数据源和目标。
[root@ceph-node-00 ~]# radosgw-admin sync group pipe create --group-id=group1 --pipe-id=pipe1 --source-zones='*' --source-bucket='*' --dest-zones='*' --dest-bucket='*'
区域组同步策略修改需要更新周期；存储桶同步策略修改不需要周期更新。
[root@ceph-node-00 ~]# radosgw-admin period update --commit
一旦我们提交了新的周期，区域组中的所有数据同步都将停止，因为我们的区域组策略设置为 允许。如果我们将它设置为 启用，同步将以与初始多站点配置相同的方式继续。
区域之间双向同步单个存储桶 ¶
现在我们可以为每个存储桶启用同步。我们将为现有的存储桶 testbucket 创建一个存储桶级别策略规则。请注意，必须在设置此策略之前创建存储桶，并且修改存储桶策略的管理员命令必须在主区域上运行。但是，存储桶同步策略不需要周期更新。无需更改数据流，因为它从区域组策略继承而来。存储桶策略流仅是区域组策略中定义的流的子集；管道也是如此。
我们创建存储桶
[root@ceph-node-00 ~]# aws --endpoint https://s3.zone1.cephlab.com:443 s3 mb s3://testbucket
make_bucket: testbucket
创建一个存储桶同步组，使用 --bucket 参数指定存储桶并将状态设置为 已启用，以便为我们的存储桶 testbucket 启用复制
[root@ceph-node-00 ~]# radosgw-admin sync group create --bucket=testbucket --group-id=testbucket-1 --status=enabled
无需指定流，因为我们将从区域组继承流，因此我们只需要为我们的存储桶同步策略组 testbucket-1 定义一个管道。一旦应用此命令，此存储桶的数据同步复制将开始。
[root@ceph-node-00 ~]# radosgw-admin sync group pipe create --bucket=testbucket --group-id=testbucket-1 --pipe-id=test-pipe1 --source-zones='*' --dest-zones='*'
注意：您可以安全地忽略以下警告
警告：无法找到名称=*的源区域 ID
使用 sync group get 命令，您可以查看您的组、流和管道配置。我们在区域组级别运行该命令，看到状态为 允许。
"allowed"
我们使用 sync group get 命令在存储桶级别运行，并提供 --bucket 参数。在这种情况下，testbucket 的状态为 已启用
[root@ceph-node-00 ~]# radosgw-admin sync group get --bucket testbucket | jq .[0].val.status
"Enabled"
另一个有用的命令是 sync info。使用 sync info，我们可以预览使用当前配置将实施的同步复制。因此，例如，如果我们的区域组同步策略处于 允许 状态，则区域组级别不会发生任何同步，因此 sync info 命令不会显示任何配置的源或目标。
[root@ceph-node-00 ~]# radosgw-admin sync info
{
"sources": [],
"dests": [],
"hints": {
"sources": [],
"dests": []
},
"resolved-hints-1": {
"sources": [],
"dests": []
},
"resolved-hints": {
"sources": [],
"dests": []
}
}
我们也可以在存储桶级别使用 sync info 命令，使用 --bucket 参数，因为我们配置了双向管道。我们将拥有 zone2 -> zone1 作为源，以及 zone1 -> zone2 作为目标。这意味着在 testbucket 存储桶上进行复制发生在两个方向。如果在 zone1 中向 testbucket 中 PUT 对象，它将被复制到 zone2，如果在 zone2 中 PUT 对象，它将被复制到 zone1。
[root@ceph-node-00 ~]# radosgw-admin sync info --bucket testbucket
{
"sources": [
{
"id": "test-pipe1",
"source": {
"zone": "zone2",
"bucket": "testbucket:89c43fae-cd94-4f93-b21c-76cd1a64788d.34553.1"
},
"dest": {
"zone": "zone1",
"bucket": "testbucket:89c43fae-cd94-4f93-b21c-76cd1a64788d.34553.1"
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": "user1"
}
}
],
"dests": [
{
"id": "test-pipe1",
"source": {
"zone": "zone1",
"bucket": "testbucket:89c43fae-cd94-4f93-b21c-76cd1a64788d.34553.1"
},
"dest": {
"zone": "zone2",
"bucket": "testbucket:89c43fae-cd94-4f93-b21c-76cd1a64788d.34553.1"
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": "user1"
}
}
],
因此，例如，如果我们只看源，您会看到它们会根据运行 radosgw-admin 命令的集群而变化。例如，从 cluster2 (ceph-node04)，我们看到 zone1 作为源
[root@ceph-node-00 ~]# ssh ceph-node-04 radosgw-admin sync info --bucket testbucket | jq '.sources[].source, .sources[].dest'
{
"zone": "zone1",
"bucket": "testbucket:66df8c0a-c67d-4bd7-9975-bc02a549f13e.45330.2"
}
{
"zone": "zone2",
"bucket": "testbucket:66df8c0a-c67d-4bd7-9975-bc02a549f13e.45330.2"
}
在 cluster1 (ceph-node-00) 中，我们看到 zone2 作为源
[root@ceph-node-00 ~]# radosgw-admin sync info --bucket testbucket | jq '.sources[].source, .sources[].dest'
{
"zone": "zone2",
"bucket": "testbucket:66df8c0a-c67d-4bd7-9975-bc02a549f13e.45330.2"
}
{
"zone": "zone1",
"bucket": "testbucket:66df8c0a-c67d-4bd7-9975-bc02a549f13e.45330.2"
}
让我们使用 AWS CLI 进行快速测试，以验证配置并确认 testbucket 的复制是否正常工作。我们在 zone1 中 PUT 一个对象，并检查它是否已复制到 zone2
[root@ceph-node-00 ~]# aws --endpoint https://s3.zone1.cephlab.com:443 s3 cp /etc/hosts s3://testbucket/firsfile
upload: ../etc/hosts to s3://testbucket/firsfile
我们可以使用 radosgw-admin bucket sync checkpoint 命令检查同步是否完成
[root@ceph-node-00 ~]# ssh ceph-node-04 radosgw-admin bucket sync checkpoint --bucket testbucket
2024-02-02T02:17:26.858-0500 7f3f38729800 1 bucket sync caught up with source:
local status: [, , , 00000000004.531.6, , , , , , , ]
remote markers: [, , , 00000000004.531.6, , , , , , , ]
2024-02-02T02:17:26.858-0500 7f3f38729800 0 bucket checkpoint complete
另一种检查同步状态的方法是使用 radosgw-admin bucket sync status 命令
[root@ceph-node-00 ~]# radosgw-admin bucket sync status --bucket=testbucket
realm beeea955-8341-41cc-a046-46de2d5ddeb9 (multisite)
zonegroup 2761ad42-fd71-4170-87c6-74c20dd1e334 (multizg)
zone 66df8c0a-c67d-4bd7-9975-bc02a549f13e (zone1)
bucket :testbucket[66df8c0a-c67d-4bd7-9975-bc02a549f13e.37124.2])
current time 2024-02-02T09:07:42Z
source zone 7b9273a9-eb59-413d-a465-3029664c73d7 (zone2)
source bucket :testbucket[66df8c0a-c67d-4bd7-9975-bc02a549f13e.37124.2])
incremental sync on 11 shards
bucket is caught up with source
我们看到该对象在 zone2 中可用。
[root@ceph-node-00 ~]# aws --endpoint https://object.s3.zone2.dan.ceph.blue:443 s3 ls s3://testbucket/
2024-01-09 06:27:24 233 firsfile
由于复制是双向的，我们在 zone2 中 PUT 一个对象，它被复制到 zone1
[root@ceph-node-00 ~]# aws --endpoint https://object.s3.zone2.dan.ceph.blue:443 s3 cp /etc/hosts s3://testbucket/secondfile
upload: ../etc/hosts to s3://testbucket/secondfile
[root@ceph-node-00 ~]# aws --endpoint https://object.s3.zone1.dan.ceph.blue:443 s3 ls s3://testbucket/
2024-01-09 06:27:24 233 firsfile
2024-02-02 00:40:15 233 secondfile
总结与下一步 ¶
在本系列的第五部分中，我们讨论了多站点同步策略并分享了一些配置细粒度存储桶双向复制的实践示例。在第六部分中，我们将继续配置多站点同步策略，包括从多个目标存储桶到单个源的单向复制。
脚注 ¶
作者谨此感谢 IBM 对社区的支持，通过促使我们有时间创建这些帖子。