在本系列的第七部分中，我们将介绍归档区域（Archive Zone）的概念和架构，并通过实践示例展示如何将归档区域添加到正在运行的Ceph对象多站点集群中

功能概述

归档区域功能利用多站点复制和S3对象版本控制特性，确保即使生产区域中的对象被删除，归档区域仍保留所有对象版本。通过这种方式，即使从生产站点中删除，它也将保持每个对象的所有版本可用。

通过归档区域，我们可以获得对象不变性，而无需在生产区域中启用对象版本控制，降低资源消耗，从而节省了版本化 S3 对象的副本在非归档区域中消耗的空间，这适合在硬件成本比较高的环境中。

这可以保护您的数据免受逻辑或物理错误的影响。例如，它可以防止用户因逻辑故障（如在生产区域意外删除存储桶）而丢失数据，同时也能保护数据免受大规模硬件故障或整个生产站点故障的影响。

由于归档区域提供了生产数据的不可变副本，它可以作为勒索软件防护策略的关键组成部分。

可以通过生产存储桶的生命周期策略来控制归档区域的存储空间使用情况，例如定义要为对象保留的版本数量。

我们可以按存储桶选择要发送/复制到归档区域的数据。例如，如果我们有一些预生产存储桶，其中没有重要数据，我们可以禁用这些存储桶的归档区域复制。

归档区域架构

归档区域作为多站点区域组（multisite zonegroup）中的一个区域，可以拥有与生产区域不同的配置，包括其自己的存储池和复制规则。

Ceph 归档区域具有以下主要特性：

• 版本控制：RGW 归档区域中的所有存储桶都启用了版本控制。

• 异步复制：每次用户上传新对象时，该对象都会异步复制到归档区域。

• 版本生成：在生产区域中每次修改对象时，归档区域都会生成一个新的对象版本。

• 数据不可变性：如果生产区域中的对象被删除，归档区域中的对象将保持完整。但需要注意的是，归档区域不会锁定其接收的对象。如果用户具有适当的权限并访问 S3 端点，仍然可以删除归档区域中的对象。

• 私有网络配置：归档区域的 S3 端点可以配置在仅对运维管理员团队开放的私有网络中。如果需要恢复生产对象，请求必须通过该团队处理。

我们可以将归档区域添加到 Ceph 对象存储的单站点配置中。通过这种配置，我们可以将归档区域附加到运行中的单区域、单 Ceph 集群中，如下图所示：

或者，我们可以将归档区域附加到 Ceph 对象存储的多站点配置中。例如，如果我们有一个在两个区域之间进行复制的领域（realm）/区域组（zonegroup），我们可以添加第三个区域，代表第三个 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

一旦我们在本地拉取了领域（realm）和周期（period），我们的第三个集群将拥有所有必需的领域和区域组配置。如果我们运行 radosgw-admin zonegroup get 命令，就可以查看当前多站点设置的所有详细信息。接下来，我们将配置一个名为 archive 的新区域。我们需要提供以下信息：

• 端点列表：这些是将在新集群上部署的专用同步 RGW（Rados Gateway）的地址。

• 同步用户的访问密钥和密钥：用于同步操作的认证信息。

• 区域类型：通过设置 tier type 标志，明确该新区域将被创建为归档区域。

这一步骤是确保新区域能够正确配置并作为归档区域运行的关键。

[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（Rados Gateway）服务，这些服务将从生产区域复制数据。在本示例中，我们使用 cephadm 的 RGW CLI 而不是规格文件（spec file）来展示另一种配置 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

现在我们要开始将数据复制到归档区域，因此我们需要创建区域组策略。回想一下我们之前的文章，我们配置了一个区域组策略以allow在区域组级别进行复制，然后我们在每个存储桶的基础上配置了复制。

在这种情况下，我们将对归档区域采取不同的方法。我们将在区域组级别配置单向同步，并将策略状态设置为enabled ，因此默认情况下，区域zone1中的所有存储桶都将复制到archive归档区域。

和以前一样，要创建同步策略，我们需要一个组、一个流和一个管道。让我们创建一个名为grouparchive的新 zonegroup 组策略：

[root@ceph-node-00 ~]#  radosgw-admin sync group create --group-id=grouparchive --status=enabled 

我们正在创建一个“directional”（unidirectional）流，它将所有数据从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 的任意存储桶时（这里我们选择了单向同步的存储桶，但也可以是其他存储桶），可以看到现在配置了一个新的同步策略，其 ID 为 pipe-archive。这一策略源自我们刚刚应用的区域组策略，因为这是单向同步的配置。我们在 zone1 的 ceph-node-00 节点上运行命令，发现只有 dests 字段被填充，其中源区域为 zone1，目标区域为归档区域。

[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 的数据都将被复制到归档区域。在这种配置下，我们只需设置从 zone1 到归档区域的单向数据流。例如，如果在 zone2 中写入了新对象，由于我们为 unidirectionalbucket 配置了双向存储桶同步策略，对象复制的流向将如下所示：

zone2 → zone1 → 归档区域

总结

在本系列的第七部分中，我们介绍了归档区域（Archive Zone）功能，并分享了一个在实际运行的 Ceph 对象存储多站点集群中配置归档区域的实操示例。在本系列的最后一篇文章中，我们将展示归档区域功能如何帮助您从生产站点恢复关键数据。