Ceph 对象存储分层增强功能。第一部分
IBM Storage Ceph 对象存储分层增强功能。第一部分 ¶
请注意,截至本文撰写之时(2025 年 4 月中旬),此功能可能尚未在 Ceph Squid 版本中发布,但将出现在 Tentacle 版本以及未来的 Squid 版本中。
简介 ¶
Ceph 提供对象存储分层功能,通过在存储类别之间无缝移动数据来优化成本和性能。这些层可以在本地内部部署基础设施中配置,也可以扩展到包括基于云的存储类别,为各种工作负载提供灵活和可扩展的解决方案。通过基于策略的自动化,管理员可以定义生命周期策略,在高性能存储和经济实惠的归档层之间迁移数据,确保速度、耐用性和成本效益的适当平衡。
Ceph 中的本地存储类别允许组织在其内部部署 Ceph 集群中,在基于快速 NVMe 或 SAS/SATA SSD 的池与基于经济型 HDD 或 QLC 的池之间对数据进行分层。这对于需要不同性能级别的应用程序,或数据“老化”不再需要高性能并可以迁移到更慢、更经济的存储的场景尤其有利。

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

Squid 版本中的新功能:基于策略的数据检索 ¶
最初,Ceph 基于策略的数据归档(云同步)到 S3 兼容平台提供单向数据流,数据只能从本地存储池归档到指定的云存储层。虽然这允许用户利用经济高效的云平台进行冷存储或长期数据保留,但缺乏检索功能限制了解决方案在数据管理方面的灵活性。这意味着一旦数据归档到云存储,就无法再通过 Ceph 直接主动检索或重新集成到本地工作流中。
Ceph Squid 引入了基于策略的数据检索,这标志着其能力的重大演变,现已作为技术预览版提供。此增强功能使用户能够将 S3 云或磁带转换的对象直接检索到其本地 Ceph 环境中,从而消除了以前单向流的限制。数据可以作为临时或永久对象恢复。
- 临时恢复:恢复的数据绕过生命周期云转换规则,并在指定时间后自动删除,将对象恢复到其先前的存根状态。
- 永久恢复:这些对象完全重新集成到 Ceph 集群中,并像(并成为)常规对象一样处理,并受标准生命周期策略和复制过程的约束。
可以通过两种不同的方式进行对象检索
- S3 RestoreObject API:允许用户使用
S3RestoreObjectAPI 请求从远程 S3 端点检索对象 - 直读对象检索:允许对已转换的对象执行标准 S3
GET请求,以透明地将它们恢复到 Ceph 集群。

在此版本中,我们不支持从使用不同 Glacier API 的 S3 云/磁带端点检索对象,例如 IBM Deep Archive。此功能增强目标是 Ceph 的 Tentacle 版本。
基于策略的数据归档分步演练 ¶
在本节中,我们将配置和设置 Ceph 的基于策略的数据归档功能。我们将讨论如何使用数据生命周期策略,通过将冷数据归档到 IBM Cloud Object Storage (COS) 来将其转换为异地、经济高效的存储类别。
我们将使用的 Ceph 术语 ¶
- Zonegroup:区域的集合,通常位于同一地理位置(又称区域)。
- Zone:包含对象网关 (RGW) 端点并属于区域组的一个或多个实例。
- Placement:同一区域内 RADOS 数据池的逻辑分离。
- Storage Class:存储类别自定义对象数据的放置,S3 桶生命周期规则自动完成这些类别之间的转换。
注意:我们在此描述的 RGW 存储类别不应与 Kubernetes PV/PVC 存储类别混淆。
生命周期策略简介 ¶
下表总结了 Ceph 对象网关支持的各种生命周期策略
| 策略类型 | 描述 | 示例用例 |
|---|---|---|
| 过期 | 在指定持续时间后删除对象 | 在 30 天后自动删除临时文件 |
| 非当前版本过期 | 在版本控制桶中,在指定持续时间后删除对象的非当前版本 | 通过删除对象的旧版本来管理存储成本 |
| 中止不完整的分段上传 | 取消在指定持续时间内未完成的分段上传 | 通过清理不完整的上传来释放存储空间 |
| 存储之间转换 类别 | 在指定持续时间后,在同一 Ceph 集群中的不同存储类别之间移动对象 将数据从 SSD/复制存储移动到 HDD/EC 存储,90 天后 | 将数据从 SSD/复制存储移动到 HDD/EC 存储,90 天后 将数据从 SSD/复制存储移动到 HDD/EC 存储,90 天后 |
| NewerNoncurrentVersions 过滤器 | 过滤比指定计数新的非当前版本,以进行过期或转换操作 | 仅保留对象的最后三个非当前版本 仅保留对象的最后三个非当前版本 |
| ObjectSizeGreaterThan 过滤器 | 仅将生命周期规则应用于大于指定大小的对象 | 将大型视频文件移动到成本较低的存储类别 |
| ObjectSizeLess 过滤器 | 仅将生命周期规则应用于小于指定大小的对象 | 在一定时间后归档小型日志文件 |
除了指定策略之外,生命周期规则还可以使用标签或前缀进行过滤,从而对受影响的对象进行更精细的控制。标签可以根据每个对象标签识别对象的特定子集,而前缀则有助于根据其键名定位对象。
配置用于分层的远程云服务 ¶
首先,我们将远程 S3 云服务配置为我们本地转换对象的未来目的地。在我们的示例中,我们将创建一个名为 ceph-s3-tier 的 IBM COS 桶。

需要注意的是,我们需要为我们的桶创建一个启用 HMAC 密钥的服务凭证。
为云-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
注意: Ceph 允许创建任意名称的存储类别,但某些客户端和客户端库只接受 AWS 存储类别名称,或者当存储类别是例如 GLACIER 时表现出独特的行为。
我们可以在默认区域组和放置目标中验证可用的存储类别
# radosgw-admin zonegroup get --rgw-zonegroup=default | jq .placement_targets[0].storage_classes
[
"STANDARD_IA",
"STANDARD",
"ibm-cos"
]
使用分层配置配置云-S3 存储类别 ¶
接下来,我们使用 radosgw-admin 命令配置 cloud-s3 存储类别,其中包含来自我们的 IBM COS 桶的特定参数:端点、区域和帐户凭据
# 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 云-S3 存储类别到位,我们将用户切换到 Ceph 对象 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,因为此 LC 从未处理过;一旦处理,它将转换为 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
}
},
}
}
}
测试已配置的生命周期策略 ¶
重要警告:更改此参数仅用于 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 集群。我们将介绍关键技术概念并提供详细的配置步骤,以帮助您实施云恢复,确保在需要时仍可访问您的冷数据。
脚注 ¶
有关 RGW 放置目标和存储类别的更多信息,请访问此页面
有关将数据定向到多个 RGW 存储类别的相关内容,请观看此演示
作者谨此感谢 IBM 对社区的支持,通过促使我们有时间创建这些帖子。