Ceph 对象存储多站点复制系列。第七部分
IBM Storage Ceph 对象存储多站点复制系列第七部分：归档区 ¶
在本 Ceph 多站点系列第七部分中，我们介绍归档区概念和架构。我们将分享一个将归档区附加到正在运行的 Ceph 对象多站点集群的实践示例。
简介 ¶
使用归档区功能将存储在 Ceph 上的关键对象数据进行归档。
归档区使用多站点复制和 S3 对象版本控制功能。 这样，即使从生产站点删除，它也会保留每个对象的每个版本。
使用归档区，您可以在不启用生产区对象版本控制的开销下实现对象不可变性，从而节省非归档区中版本化 S3 对象副本将消耗的空间，这些非归档区可能部署在更快但更昂贵的存储设备上。
这可以保护您的数据免受逻辑或物理错误的影响。它可以拯救用户免受逻辑故障的影响，例如生产区中意外删除存储桶。它可以保护您的数据免受大规模硬件故障或整个生产站点故障的影响。
由于归档区提供生产数据的不可变副本，因此它可以作为勒索软件保护策略的关键组成部分。
您可以通过生产存储桶的生命周期策略来控制归档区的存储空间使用量，您可以在其中定义要为对象保留的版本数。
我们可以按存储桶选择要发送/复制到归档区的数据。 例如，如果我们有不包含任何有价值数据的预生产存储桶，我们可以禁用这些存储桶上的归档区复制。
归档区架构 ¶
归档区作为多站点组中的一个区域，其设置可能与生产区域不同，包括其自己的池和复制规则。
Ceph 归档区具有以下主要特征
- RGW 归档区中的所有存储桶都启用了版本控制
- 每次用户上传新对象时，该对象都会异步复制到归档区。
- 生产区域中的每个对象修改都会在归档区域中生成一个新的对象版本。
- 我们提供不可变性，以便如果对象在生产区域中被删除，则该对象将完好无损地保存在归档区域中。 但重要的是要注意，归档区不会锁定其摄取的对象。 如果用户具有访问具有适当权限的 S3 端点的权限，则对象可以在归档区域中被删除。
归档区的 S3 端点，用于数据恢复，可以配置在只能由运营管理团队访问的专用网络上。 如果需要恢复生产对象，则请求需要通过该团队进行处理。
我们可以将归档区添加到 Ceph 对象存储单站点配置。 使用此配置，我们可以将归档区附加到正在运行的单区域、单个 Ceph 集群，如图所示
或者，我们可以将归档区附加到 Ceph 对象存储多站点配置。 例如，如果我们有一个在两个区域之间复制的领域/区域组，我们可以添加一个代表第三个 Ceph 集群的第三个区域。 这是我们将在此示例中使用的架构，建立在我们之前的工作基础上，我们设置了一个 Ceph 多站点复制集群。 现在我们将向我们的区域组添加一个配置为不可变归档区的第三个区域。 下图显示了此架构的示例。
让我们从我们的归档区配置开始。 我们有一个新部署的第三个 Ceph 集群，该集群在名为 ceph-node-[08-11].cephlab.com 的四个节点上运行。
[root@ceph-node-08 ~]# ceph orch host ls
HOST ADDR LABELS STATUS
ceph-node-08.cephlab.com ceph-node-08 _admin,osd,mon,mgr,rgwsync
ceph-node-09.cephlab.com 192.168.122.135 osd,mon,mgr,rgwsync
ceph-node-10.cephlab.com 192.168.122.204 osd,mon,mgr,rgw
ceph-node-11.cephlab.com 192.168.122.194 osd,rgw
4 hosts in cluster
归档区当前无法使用 Manager rgw 模块进行配置，因此我们必须运行 radosgw-admin 命令来配置它。 首先，我们从我们已经部署的 multisite 领域中提取信息。 我们使用区域组端点以及 RGW 多站点同步用户的访问和密钥。 如果您需要检查同步用户的详细信息，可以运行： radosgw-admin user info --uid sysuser-multisite。
[root@ceph-node-08]# radosgw-admin realm pull --rgw-realm=multisite --url=http://ceph-node-01.cephlab.com:8000 --access-key=X1BLKQE3VJ1QQ27ORQP4 --secret=kEam3Fq5Wgf24Ns1PZXQPdqb5CL3GlsAwpKJqRjg --default
[root@ceph-node-08]# radosgw-admin period pull --url=http://ceph-node-01.cephlab.com:8000 --access-key=X1BLKQE3VJ1QQ27ORQP4 --secret=kEam3Fq5Wgf24Ns1PZXQPdqb5CL3GlsAwpKJqRjg
一旦我们在本地提取了领域和周期，我们的第三个集群就拥有所有必需的领域和区域组配置。 如果我们运行 radosgw-admin zonegroup get，我们将看到我们当前多站点设置的所有详细信息。 接下来，我们将配置一个名为 archive 的新区域。 我们提供端点列表，这些是我们将要在我们的新集群上部署的专用同步 RGW，以及同步用户的访问和密钥，最后但并非最不重要的是层类型。 此标志定义了将此新区域创建为归档区。
[root@ceph-node-08]# radosgw-admin zone create --rgw-zone=archive --rgw-zonegroup=multizg --endpoints=http://ceph-node-08.cephlab.com:8000,http://ceph-node-09.cephlab.com:8000 --access-key=X1BLKQE3VJ1QQ27ORQP4 --secret=kEam3Fq5Wgf24Ns1PZXQPdqb5CL3GlsAwpKJqRjg --tier-type=archive --default
有了新区域，我们可以更新周期，将我们的新区域配置推送到区域组中的其余区域
[root@ceph-node-08]# radosgw-admin period update --commit
使用 cephadm，我们部署两个 RGW 服务，这些服务将从生产区域复制数据。 在此示例中，我们使用 cephadm RGW CLI 而不是规范文件，以展示使用 cephadm 配置 Ceph 服务的不同方式。 我们启动的两个新 RGW 都将属于归档区。 使用 --placement 参数，我们配置两个 RGW 服务，这些服务将在 ceph-node-08 和 ceph-node-09 上运行，这些节点是我们通过之前的命令配置为区域复制端点的节点。
[root@ceph-node-08 ~]# ceph orch apply rgw multi.archive --realm=multisite --zone=archive --placement="2 ceph-node-08.cephlab.com ceph-node-09.cephlab.com" --port=8000
Scheduled rgw.multi.archive update...
我们可以检查 RGW 是否已正确启动
[root@ceph-node-08]# ceph orch ps | grep archive
[root@ceph-node-08]# ceph orch ps | grep archive
rgw.multi.archive.ceph-node-08.hratsi ceph-node-08.cephlab.com *:8000 running (10m) 10m ago 10m 80.5M - 18.2.0-131.el9cp 463bf5538482 44608611b391
rgw.multi.archive.ceph-node-09.lubyaa ceph-node-09.cephlab.com *:8000 running (10m) 10m ago 10m 80.7M - 18.2.0-131.el9cp 463bf5538482 d39dbc9b3351
一旦新的 RGW 启动，归档区的新的池就会为我们创建。 请记住，如果我们要对 RGW 数据池使用擦除编码，那么现在是创建它之前启用从生产到归档区的复制的时刻。 否则，数据池将使用默认数据保护策略复制，即三个副本，也称为 R3。
[root@ceph-node-08]# ceph osd lspools | grep archive
8 archive.rgw.log
9 archive.rgw.control
10 archive.rgw.meta
11 archive.rgw.buckets.index
当我们现在从归档区的一个节点检查同步状态时，我们看到当前没有配置复制。 这是因为我们正在使用 sync policy，并且没有为归档区配置区域组同步策略
[root@ceph-node-08]# radosgw-admin sync status --rgw-zone=archive
realm beeea955-8341-41cc-a046-46de2d5ddeb9 (multisite)
zonegroup 2761ad42-fd71-4170-87c6-74c20dd1e334 (multizg)
zone bac4e4d7-c568-4676-a64c-f375014620ae (archive)
current time 2024-02-12T17:19:24Z
zonegroup features enabled: resharding
disabled: compress-encrypted
metadata sync syncing
full sync: 0/64 shards
incremental sync: 64/64 shards
metadata is caught up with master
data sync source: 66df8c0a-c67d-4bd7-9975-bc02a549f13e (zone1)
not syncing from zone
source: 7b9273a9-eb59-413d-a465-3029664c73d7 (zone2)
not syncing from zone
现在我们想开始将数据复制到我们的归档区，因此我们需要创建一个区域组策略。 回顾我们之前的帖子，我们有一个区域组策略配置为允许区域组级别进行复制，然后我们在每个存储桶的基础上配置复制。
在这种情况下，我们将对归档区采取不同的方法。 我们将配置区域组级别上的单向同步，并将策略状态设置为 enabled，因此默认情况下，zone1 中的所有存储桶都将被复制到 archive 归档区。
与之前一样，要创建同步策略，我们需要一个组、一个流和一个管道。 让我们创建一个名为 grouparchive 的新的区域组组策略
[root@ceph-node-00 ~]# radosgw-admin sync group create --group-id=grouparchive --status=enabled
我们正在创建一个“定向”（单向）流，该流将从 zone1 复制所有数据到 archive 区域
[root@ceph-node-00 ~]# radosgw-admin sync group flow create --group-id=grouparchive --flow-id=flow-archive --flow-type=directional --source-zone=zone1 --dest-zone=archive
最后，我们创建一个管道，其中我们使用 * 通配符表示所有字段，以避免键入完整的区域名称。 * 表示配置在流中的所有区域。 我们可以选择输入 zone1 和 archive 到区域字段中。 在此处使用通配符有助于避免拼写错误并推广该过程。
[root@ceph-node-00 ~]# radosgw-admin sync group pipe create --group-id=grouparchive --pipe-id=pipe-archive --source-zones='*' --source-bucket='*' --dest-zones='*' --dest-bucket='*'
区域组同步策略始终需要提交
[root@ceph-node-00 ~]# radosgw-admin period update --commit
当我们检查配置的区域组策略时，我们现在看到两个组，group1 来自我们之前的博客文章和我们刚刚创建和配置的 grouparchive
[root@ceph-node-00 ~]# radosgw-admin sync group get
[
{
"key": "group1",
"val": {
"id": "group1",
"data_flow": {
"symmetrical": [
{
"id": "flow-mirror",
"zones": [
"zone1",
"zone2"
]
}
]
},
"pipes": [
{
"id": "pipe1",
"source": {
"bucket": "*",
"zones": [
"*"
]
},
"dest": {
"bucket": "*",
"zones": [
"*"
]
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": ""
}
}
],
"status": "allowed"
}
},
{
"key": "grouparchive",
"val": {
"id": "grouparchive",
"data_flow": {
"directional": [
{
"source_zone": "zone1",
"dest_zone": "archive"
}
]
},
"pipes": [
{
"id": "pipe-archive",
"source": {
"bucket": "*",
"zones": [
"*"
]
},
"dest": {
"bucket": "*",
"zones": [
"*"
]
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": ""
}
}
],
"status": "enabled"
}
}
]
当我们检查 zone1 中的任何存储桶时（这里我们选择 unidrectional 存储桶，但可以是任何其他存储桶；我们看到现在配置了一个新的同步策略，其 ID 为 pipe-archive。 这来自我们刚刚应用的区域组策略，因为它是单向的。 我们从 zone1 中的 ceph-node-00 运行该命令。 我们只看到填充了 dests 字段，其中 source 是 zone1，目标是 archive 区域。
[root@ceph-node-00 ~]# radosgw-admin sync info --bucket unidirectional
{
"sources": [],
"dests": [
{
"id": "pipe-archive",
"source": {
"zone": "zone1",
"bucket": "unidirectional:66df8c0a-c67d-4bd7-9975-bc02a549f13e.36430.1"
},
"dest": {
"zone": "archive",
"bucket": "unidirectional:66df8c0a-c67d-4bd7-9975-bc02a549f13e.36430.1"
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": ""
}
},
{
"id": "test-pipe1",
"source": {
"zone": "zone1",
"bucket": "unidirectional:66df8c0a-c67d-4bd7-9975-bc02a549f13e.36430.1"
},
"dest": {
"zone": "zone2",
"bucket": "unidirectional:66df8c0a-c67d-4bd7-9975-bc02a549f13e.36430.1"
},
"params": {
"source": {
"filter": {
"tags": []
}
},
"dest": {},
"priority": 0,
"mode": "system",
"user": "user1"
}
},
当我们再次运行 radosgw-admin sync status 命令时，我们看到 zone1 的状态已从 not syncing from zone 更改为同步已启用且 data is caught up with source。
[root@ceph-node-08 ~]# radosgw-admin sync status --rgw-zone=archive
realm beeea955-8341-41cc-a046-46de2d5ddeb9 (multisite)
zonegroup 2761ad42-fd71-4170-87c6-74c20dd1e334 (multizg)
zone bac4e4d7-c568-4676-a64c-f375014620ae (archive)
current time 2024-02-12T17:09:26Z
zonegroup features enabled: resharding
disabled: compress-encrypted
metadata sync syncing
full sync: 0/64 shards
incremental sync: 64/64 shards
metadata is caught up with master
data sync source: 66df8c0a-c67d-4bd7-9975-bc02a549f13e (zone1)
syncing
full sync: 0/128 shards
incremental sync: 128/128 shards
data is caught up with source
source: 7b9273a9-eb59-413d-a465-3029664c73d7 (zone2)
not syncing from zone
现在，注入到 zone1 中的所有数据都将被复制到 archive 区域。 这样，我们只需要设置从 zone1 toarchive的单向流。 例如，如果在zone2中注入了一个新对象，因为我们对unidirectional存储桶有一个双向存储桶同步策略，对象复制流将是：zone2→zone1 → Archive。
总结与下一步 ¶
我们在本系列的第七部分中介绍了归档区功能。 我们分享了一个配置正在运行的 Ceph 对象多站点集群中的归档区的实践示例。 在本系列的最后一部分中，我们将演示归档区功能如何帮助您从生产站点恢复关键数据。
脚注 ¶
作者谨此感谢 IBM 对社区的支持，通过促使我们有时间创建这些帖子。