介绍

Ceph 提供了对象存储分层功能，通过在不同存储类别之间无缝迁移数据来优化成本和性能。这些层级可以在本地基础设施内配置，也可以扩展到基于云的存储类别，从而为多样化的工作负载提供灵活且可扩展的解决方案。借助基于策略的自动化功能，管理员可以定义生命周期策略，将数据从高性能存储迁移到经济高效的归档层级，确保在速度、持久性和成本效益之间取得最佳平衡。

Ceph 的本地存储类别允许配置在本地 Ceph 集群内，将数据在快速的 NVMe 或 SAS/SATA SSD 存储池与经济型的 HDD 或 QLC 存储池之间进行分层存储。这对于需要不同性能级别的应用程序或数据“老化”后不再需要高性能的场景尤为有益，此时可以将数据迁移到速度较慢但更经济的存储中。

除了本地分层存储外，Ceph 还提供了基于策略的数据归档和检索功能，能够与 S3 兼容平台集成，实现异地数据管理。组织可以利用此功能将数据归档到基于云的存储层级，例如 IBM Cloud Object Storage、AWS S3、Azure Blob 或 S3 磁带端点，以实现长期保留、灾难恢复或成本优化的冷存储。通过基于策略的自动化功能，Ceph 确保数据能够根据预定义的生命周期规则迁移到云端或其他目标位置，从而增强其在混合云策略中的价值。

Squid 版本中的新功能：基于策略的数据检索

最初，Ceph 基于策略的数据归档（云同步）功能仅支持单向数据流，即数据只能从本地存储池归档到指定的云存储层级。虽然这使用户能够利用经济高效的云平台进行冷存储或长期数据保留，但缺乏数据检索能力限制了该解决方案在数据管理中的灵活性。这意味着，一旦数据被归档到云存储，就无法再通过 Ceph 直接主动检索或重新集成到本地工作流中。

Ceph Squid 引入了基于策略的数据检索功能，这标志着其能力的重大演进，目前作为技术预览版提供。这一增强功能使用户能够将 S3 云存储或磁带存储中的对象直接检索回本地 Ceph 环境，消除了之前单向数据流的限制。数据可以作为临时或永久对象进行恢复。

• 临时恢复：恢复的数据会绕过生命周期云迁移规则，并在指定时间后自动删除，对象将恢复为之前的存根状态。

• 永久恢复：这些对象会完全重新集成到 Ceph 集群中，被视为（并成为）常规对象，并遵循标准的生命周期策略和复制流程。

对象检索可以通过两种不同的方式实现：

1. S3 RestoreObject API：允许用户使用 S3RestoreObject API 请求从远程 S3 端点检索对象。

2. 读取时透明检索：支持对已迁移对象执行标准的 S3 GET 请求，从而透明地将对象恢复到 Ceph 集群中。

在此版本中，我们不支持从使用不同 Glacier API（例如 IBM Deep Archive）的 S3 云/磁带端点检索对象。此功能增强针对 Ceph 的 Tentacle 版本。

基于策略的数据归档测试

在本节中，我们将配置和设置 Ceph 的基于策略的数据归档功能。我们将讨论使用数据生命周期策略，通过将冷数据归档到 IBM Cloud Object Storage (COS)，将其转换为异地、经济高效的存储类。

Ceph 术语说明

• 区域组（Zonegroup）：通常位于同一地理区域（也称为区域）的多个区域的集合。

• 区域（Zone）：包含对象网关（RGW）端点的一个或多个实例，属于某个区域组。

• 放置（Placement）：在同一区域内对 RADOS 数据池进行逻辑分离。

• 存储类别（Storage Class）：存储类别用于自定义对象数据的放置位置，S3 存储桶生命周期规则则用于自动化这些类别之间的数据迁移。

[!CAUTION]

注意：此处描述的 RGW 存储类别不应与 Kubernetes 的 PV/PVC 存储类别混淆。

生命周期策略介绍

下表总结了 Ceph 对象网关支持的各种生命周期策略：

除了指定策略外，生命周期规则还可以使用标签（tags）或前缀（prefixes）进行过滤，从而更精细地控制哪些对象受到影响。标签可以根据每个对象的标签标识特定对象子集，而前缀则有助于根据对象键名（key names）定位对象。

配置远程云服务进行分层

首先，我们将远程 S3 云服务配置为本地迁移对象的未来目标。在本示例中，我们将创建一个名为 ceph-s3-tier 的 IBM COS 存储桶。

值得注意的是，我们需要为我们的存储桶创建一个启用了 HMAC 密钥的服务凭证。

为 Cloud-S3 分层创建新的存储类

在默认区域组内的默认位置上创建新的存储类；我们使用 rgw-admin --tier-type=cloud-s3 参数来根据我们之前在 COS S3 中配置的存储桶来配置存储类别。

# radosgw-admin zonegroup placement add --rgw-zonegroup=default --placement-id=default-placement --storage-class=ibm-cos --tier-type=cloud-s3

[!CAUTION]

注意：Ceph 允许使用任意名称创建存储类别，但某些客户端和客户端库仅接受 AWS 存储类别名称，或者在存储类别为 GLACIER 等特定名称时表现出独特的行为。

我们可以验证默认区域组和放置目标中的可用存储类：

# radosgw-admin zonegroup get --rgw-zonegroup=default | jq .placement_targets[0].storage_classes
[
  "STANDARD_IA",
  "STANDARD",
  "ibm-cos"
]

配置具有分层设置的 Cloud-S3 存储类别

接下来，我们使用 radosgw-admin 命令配置 cloud-s3 存储类别，并指定 IBM COS 存储桶的相关参数：端点（endpoint）、区域（region）和账户凭证（credentials）。

# radosgw-admin zonegroup placement modify --rgw-zonegroup default  --placement-id default-placement --storage-class ibm-cos --tier-config=endpoint=https://s3.eu-de.cloud-object-storage.appdomain.cloud,access_key=YOUR_ACCESS_KEY,secret=YOUR_SECRET_KEY,target_path="ceph-s3-tier",multipart_sync_threshold=44432,multipart_min_part_size=44432,retain_head_object=true,region=eu-de

应用生命周期策略

一旦 COS cloud-S3 存储类就位，我们将把用户切换为 Ceph Object S3 API 的使用者，并通过 RGW S3 API 端点配置生命周期策略。我们的用户名为tiering ，并且我们已使用分层用户的凭据预先配置了 S3 AWC CLI。

# aws --profile tiering --endpoint https://s3.cephlabs.com s3 mb s3://databucket
# aws --profile tiering --endpoint https://s3.cephlabs.com s3 /etc/hosts s3://databucket

我们将把一个 JSON 生命周期策略附加到之前创建的存储桶中。例如，存储桶databucket将具有以下策略，将所有超过 30 天的对象转换为 COS 存储类别：

{
  "Rules": [
    {"ID": "Transition objects from Ceph to COS that are older than 30 days",
      "Prefix": "",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "ibm-cos"
        }
      ]
    }
   ]
}

作为 S3 API 使用者，我们将使用 AWS S3 CLI 将存储桶生命周期配置应用到名为ibm-cos-lc.json的本地文件中：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api put-bucket-lifecycle-configuration --lifecycle-configuration file://ibm-cos-lc.json --bucket databucket

验证该策略是否已应用：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-bucket-lifecycle-configuration  --bucket databucket

我们还可以通过以下 radosgw-admin 命令检查 Ceph/RGW 是否已注册此新的生命周期（LC）策略。状态显示为 UNINITIAL，因为此生命周期策略尚未被处理；一旦处理完成，状态将变为 COMPLETED：

# radosgw-admin lc list | jq .[1]
{
  "bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1",
  "shard": "lc.23",
  "started": "Thu, 01 Jan 1970 00:00:00 GMT",
  "status": "UNINITIAL"
}

我们可以使用以下命令获取应用于存储桶的规则的更多详细信息：

# radosgw-admin lc get --bucket databucket
{
    "prefix_map": {
        "": {
            "status": true,
            "dm_expiration": false,
            "expiration": 0,
            "noncur_expiration": 0,
            "mp_expiration": 0,
            "transitions": {
                "ibm-cos": {
                    "days": 30
                }
            },
        }
    }
}

测试配置的生命周期策略

[!WARNING]

更改此参数仅用于 LC 测试目的。不要在生产 Ceph 集群上更改它，并记住适当重置！

我们可以通过为生命周期进程启用调试间隔来加速生命周期策略的测试。在此设置中，存储桶生命周期配置中的每“天”相当于 60 秒，因此三天的过期时间实际上仅为三分钟：

# ceph config set client.rgw  rgw_lc_debug_interval 60
# ceph orch restart rgw.default

如果我们现在运行radosgw-admin lc list我们应该会看到转换存储桶的生命周期策略处于已完成状态：

[root@ceph01 ~]# radosgw-admin lc list| jq .[1]
{
  "bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1",
  "shard": "lc.23",
  "started": "Mon, 25 Nov 2024 10:43:31 GMT",
  "status": "COMPLETE"
}

如果我们在本地集群中列出过渡存储桶中的可用对象，可以看到对象大小为 0。这是因为它们已被迁移到云端。然而，由于在创建云存储类别时使用了 "retain_head_object": "true" 参数，对象的元数据/头部信息仍然保留在本地：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3 ls s3://databucket
2024-11-25 05:41:33          0 hosts

如果我们使用s3api get-object-attributes调用检查对象属性，我们可以看到该对象的存储类现在是ibm-cos ，因此该对象已成功转换到 S3 云提供商：

# aws --profile tiering --endpoint https://s3.cephlabs.com s3api  get-object-attributes --object-attributes StorageClass ObjectSize --bucket databucket --key hosts
{
    "LastModified": "2024-11-25T10:41:33+00:00",
    "StorageClass": "ibm-cos",
    "ObjectSize": 0
}

如果我们使用 AWS CLI S3 客户端（但使用 IBM COS 用户的端点和配置文件）在 IBM COS 中检查，可以看到对象已存在于 IBM COS 存储桶中。由于 API 限制，原始对象的修改时间和 ETag 无法保留，但它们会作为元数据属性存储在目标对象上。

aws --profile cos --endpoint https://s3.eu-de.cloud-object-storage.appdomain.cloud s3api head-object --bucket ceph-s3-tier --key databucket/hosts | jq .
{
  "AcceptRanges": "bytes",
  "LastModified": "2024-11-25T10:41:33+00:00",
  "ContentLength": 304,
  "ETag": "\"01a72b8a9d073d6bcae565bd523a76c5\"",
  "ContentType": "binary/octet-stream",
  "Metadata": {
    "rgwx-source-mtime": "1732529733.944271939",
    "rgwx-versioned-epoch": "0",
    "rgwx-source": "rgw",
    "rgwx-source-etag": "01a72b8a9d073d6bcae565bd523a76c5",
    "rgwx-source-key": "hosts"
  }
}

为了避免存储桶之间的冲突，源存储桶名称会添加到目标对象名称之前。如果对象有版本控制，则对象版本 ID 会附加到末尾。

以下是对象名称格式示例：

s3://<target_path>/<source_bucket_name>/<source_object_name>(-<source_object_version_id>)

以下对版本化和锁定对象应用了与 LifecycleExpiration 类似的语义。如果对象在迁移到云端后是当前版本，则会将其标记为非当前版本，并创建一个删除标记。如果对象是非当前版本且被锁定，则跳过其迁移过程。

结论

本篇博客介绍了如何通过分层和生命周期策略将冷数据迁移到更具成本效益的存储类别，并将其归档到 IBM Cloud Object Storage (COS)。在下一篇博客中，我们将探讨如何在需要时将归档数据恢复到 Ceph 集群。我们将介绍关键的技术概念，并提供详细的配置步骤，帮助用户实现云恢复，确保在需要时能够访问冷数据。

原文： https://ceph.io/en/news/blog/2025/rgw-tiering-enhancements-part2/