Ceph 对象存储分层增强。第二部分
介绍 Ceph 的基于策略的数据检索 ¶
请注意,截至撰写本文时(2025 年 4 月中旬),此功能可能尚未发布在 Ceph Squid 版本中,但将出现在 Tentacle 中,并可能出现在未来的 Squid 版本中。
介绍和功能概述 ¶
在这一系列的第一部分中,我们探讨了 Ceph 对象存储的基本原理及其基于策略的归档到云/磁带功能,该功能可实现无缝的数据迁移到远程 S3 兼容存储类。此功能对于将数据卸载到具有成本效益的存储层(例如云或磁带系统)至关重要。但是,过去,该过程一直是单向的。一旦对象被转换,检索它们需要直接访问云提供商的 S3 端点。这种限制引入了操作挑战,尤其是在访问归档或冷层数据时。
我们正在 Ceph 对象存储生态系统中引入基于策略的数据检索,以解决这些差距。此增强功能使管理员和操作团队能够将过渡到云或磁带层的对象直接检索回 Ceph 集群,从而与运营效率和数据可访问性需求保持一致。
为什么这很重要 ¶
基于策略的数据检索改变了 Ceph 中云转换对象的可用性。无论数据位于具有成本效益的磁带归档中,还是位于高延迟/低成本的云层中,此功能都能确保用户可以无缝访问和管理其对象,而无需依赖外部提供商的 S3 端点。这简化了工作流程并增强了对运营策略和数据生命周期要求的合规性。
基于策略的数据检索 ¶
此新功能提供了两种方法来检索过渡到远程云/磁带 S3 兼容端点的对象
S3 RestoreObject API 实现:类似于 AWS S3
RestoreObjectAPI,此功能允许用户使用 S3RestoreObjectAPI 手动检索对象。对象恢复操作可以根据RestoreObjectAPI 调用中指定的保留期限是永久性的还是临时的。直通模式:通过引入可配置的
--allow-read-through功能,Ceph 可以为云层存储类配置中的过渡对象提供读取请求。收到GET请求后,系统会异步地从云层检索对象,将其存储在本地,并将数据提供给用户。这消除了之前遇到过的云过渡对象上的InvalidObjectState错误。

S3 RestoreObject 临时恢复 ¶
恢复的数据被视为临时数据,并且仅在恢复请求期间指定的时间内存在于 Ceph 集群中。一旦指定期限到期,恢复的数据将被删除,并且对象将恢复为存根,保留元数据和云转换配置。
跳过生命周期转换规则 ¶
在临时恢复期间,该对象将免于可能将其移动到不同层或删除它的生命周期规则。这确保了在到期日期之前不间断的访问。
恢复数据的默认存储类 ¶
恢复的对象默认写入 Ceph 集群中的 STANDARD 存储类。但是,对于临时对象,x-amz-storage-class 标头仍然会返回原始云层存储类。这与 AWS Glacier 语义一致,其中恢复对象的存储类保持不变。
S3 RestoreObject API 演练 ¶
我们正在使用名为 databucket 的存储桶将名为 2gb 的对象上传到本地 Ceph 集群。在本文博客系列的 第一部分中,我们配置了 databucket,并使用生命周期策略,该策略将在 30 天后将数据分层/归档到 IBM COS。我们使用名为 tiering 的配置文件设置了 AWS CLI 客户端,以与 Ceph 对象网关 S3 API 端点交互。
aws --profile tiering --endpoint https://s3.cephlabs.com s3 cp 2gb s3://databucket upload: ./2gb to s3://databucket/2gb
我们可以检查上传对象在我们的本地 Ceph 集群中 STANDARD 存储类的大小
aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key 2gb
{
"AcceptRanges": "bytes",
"LastModified": "2024-11-26T21:31:05+00:00",
"ContentLength": 2000000000,
"ETag": "\"b459c232bfa8e920971972d508d82443-60\"",
"ContentType": "binary/octet-stream",
"Metadata": {},
"PartsCount": 60
}
30 天后,生命周期转换生效,对象过渡到云层。首先,作为管理员,我们使用 radosgw-admin 命令检查生命周期 (LC) 处理是否完成,然后作为用户,我们使用 S3 HeadObject API 调用来查询对象的状态
# radosgw-admin lc list| jq .[1]
{
"bucket": ":databucket:fcabdf4a-86f2-452f-a13f-e0902685c655.310403.1",
"shard": "lc.23",
"started": "Tue, 26 Nov 2024 21:32:15 GMT",
"status": "COMPLETE"
}
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key 2gb
{
"AcceptRanges": "bytes",
"LastModified": "2024-11-26T21:32:48+00:00",
"ContentLength": 0,
"ETag": "\"b459c232bfa8e920971972d508d82443-60\"",
"ContentType": "binary/octet-stream",
"Metadata": {},
"StorageClass": "ibm-cos"
}
作为管理员,我们可以使用 radosgw-admin bucket stats 命令来检查使用的空间。我们可以看到 rgw.main 是空的,并且我们的 rgw.cloudtiered 放置是唯一存储数据的放置。
# radosgw-admin bucket stats --bucket databucket | jq .usage
{
"rgw.main": {
"size": 0,
"size_actual": 0,
"size_utilized": 0,
"size_kb": 0,
"size_kb_actual": 0,
"size_kb_utilized": 0,
"num_objects": 0
},
"rgw.multimeta": {
"size": 0,
"size_actual": 0,
"size_utilized": 0,
"size_kb": 0,
"size_kb_actual": 0,
"size_kb_utilized": 0,
"num_objects": 0
},
"rgw.cloudtiered": {
"size": 1604857600,
"size_actual": 1604861952,
"size_utilized": 1604857600,
"size_kb": 1567244,
"size_kb_actual": 1567248,
"size_kb_utilized": 1567244,
"num_objects": 3
}
}
现在对象已过渡到我们的 IBM COS 云层,让我们使用 S3 RestoreObject API 调用将其恢复到我们的 Ceph 集群。在此示例中,我们将请求临时恢复并将到期时间设置为三天
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api restore-object --bucket databucket --key 2gb --restore-request Days=3
如果尝试获取仍在恢复的对象,我们会收到如下错误消息
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object --bucket databucket --key 2gb /tmp/2gb
An error occurred (RequestTimeout) when calling the GetObject operation (reached max retries: 2): restore is still in progress
使用 S3 API,我们可以发出 HeadObject 调用并检查 Restore 属性的状态。在此示例中,我们可以看到我们的恢复从 IBM COS 云端点到 Ceph 已完成,因为 ongoing request 设置为 false。我们有对象的到期日期,因为我们使用带有 --restore-request days=3O 的 RestoreObject 调用。从此输出中还需要检查的其他事项:我们本地 Ceph 集群上的对象占用大小为 2GB,如恢复后预期。此外,存储类是 ibm-cos。如前所述,对于临时过渡对象,即使使用 STANDARD Ceph RGW 存储类,我们仍然保留 ibm-cos 存储类。现在对象已恢复,我们可以从客户端发出 S3 GET API 调用来访问该对象。
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key 2gb
{
"AcceptRanges": "bytes",
"Restore": "ongoing-request=\"false\", expiry-date=\"Thu, 28 Nov 2024 08:46:36 GMT\"",
"LastModified": "2024-11-27T08:36:39+00:00",
"ContentLength": 2000000000,
"ETag": "\"\"0c4b59490637f76144bb9179d1f1db16-382\"\"",
"ContentType": "binary/octet-stream",
"Metadata": {},
"StorageClass": "ibm-cos"
}
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object --bucket databucket --key 2gb /tmp/2gb
S3 RestoreObject 永久恢复 ¶
在永久恢复中恢复的数据将无限期地保留在 Ceph 集群中,使其可作为常规对象访问。与临时恢复不同,未定义任何到期期限,并且对象在检索后不会恢复为存根。这适用于需要无需额外重新恢复步骤即可长期访问对象的情况。
重新应用生命周期转换规则 ¶
永久恢复后,该对象被视为 Ceph 集群中的常规对象。所有生命周期规则(例如过渡到云存储或到期策略)都会重新应用,并且恢复的对象将完全集成到存储桶的数据生命周期工作流程中。
恢复数据的默认存储类 ¶
默认情况下,永久恢复的对象写入 Ceph 集群中的 STANDARD 存储类。与临时恢复不同,对象的 x-amz-storage-class 标头将反映 STANDARD 存储类,从而反映在集群中的永久驻留。
S3 RestoreObject API 永久恢复演练 ¶
通过不向 --restore-request 参数提供天数来恢复对象
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api restore-object --bucket databucket --key hosts2 --restore-request {}
验证恢复的对象:它是 STANDARD 存储类的一部分,因此该对象是 Ceph 集群的一流公民,已准备好集成到更广泛的运营工作流程中。
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api head-object --bucket databucket --key hosts2
{
"AcceptRanges": "bytes",
"LastModified": "2024-11-27T08:28:55+00:00",
"ContentLength": 304,
"ETag": "\"01a72b8a9d073d6bcae565bd523a76c5\"",
"ContentType": "binary/octet-stream",
"Metadata": {},
"StorageClass": "STANDARD"
}
对象直通 (/GET) 模式 ¶
通过直通恢复机制访问的对象会临时恢复到 Ceph 集群中。当对云过渡对象发出 GET 请求时,系统会异步地从云层检索对象。它会在由 read_through_restore_days 值定义的指定持续时间内使其可用。到期后,恢复的数据将被删除,并且对象将恢复为其存根状态,保留元数据和转换配置。
对象直通 (/GET) 模式演练 ¶
在启用直通模式之前,如果我们尝试访问我们的本地 Ceph 集群中的存根对象,该对象已通过基于策略的归档过渡到远程 S3 端点,我们将收到以下错误消息
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object --bucket databucket --key 2gb6 /tmp/2gb6
An error occurred (InvalidObjectState) when calling the GetObject operation: Read through is not enabled for this config
所以让我们首先启用直通模式。作为 Ceph 管理员,我们需要修改我们当前的 ibm-cos 云层存储类,并添加两个新的分层配置参数:--tier-config=allow_read_through=true,read_through_restore_days=3
# radosgw-admin zonegroup placement modify --rgw-zonegroup default \
--placement-id default-placement --storage-class ibm-cos \
--tier-config=allow_read_through=true,read_through_restore_days=3
如果您尚未执行任何多站点配置,则会自动为您创建一个默认区域和区域组,并且对区域/区域组的更改在重新启动 Ceph 对象网关 (RGW 守护程序) 之前不会生效。如果您为多站点创建了领域,则在提交更改后,区域/区域组的更改将生效 radosgw-admin period update --commit。在我们的例子中,重新启动 RGW 守护程序足以应用更改
# ceph orch restart rgw.default
Scheduled to restart rgw.default.ceph02.fvqogr on host 'ceph02'
Scheduled to restart rgw.default.ceph03.ypphif on host 'ceph03'
Scheduled to restart rgw.default.ceph04.qinihj on host 'ceph04'
Scheduled to restart rgw.default.ceph06.rktjon on host 'ceph06'
启用直通模式后,并且 RGW 服务重新启动,当对云层中的对象发出 GET 请求时,该对象将自动恢复到 Ceph 集群并提供给用户。
# aws --profile tiering --endpoint https://s3.cephlabs.com s3api get-object --bucket databucket --key 2gb6 /tmp/2gb6
{
"AcceptRanges": "bytes",
"Restore": "ongoing-request=\"false\", expiry-date=\"Thu, 28 Nov 2024 08:46:36 GMT\"",
"LastModified": "2024-11-27T08:36:39+00:00",
"ContentLength": 2000000000,
"ETag": "\"\"0c4b59490637f76144bb9179d1f1db16-382\"\"",
"ContentType": "binary/octet-stream",
"Metadata": {},
"StorageClass": "ibm-cos"
}
未来工作 ¶
Ceph 开发人员正在通过即将推出的增强功能改进基于策略的数据检索功能,包括
- 磁带/DiamondBack 支持:使用
RestoreObjectAPI 而不是使用 Glacier API 的 S3 端点来获取对象 - 用于增强监控的管理员命令:包括恢复状态、列出恢复/正在进行的对象的恢复以及为失败重新触发恢复操作
- 压缩和加密支持:有效地恢复压缩或加密的对象
结论 ¶
Ceph 存储的基于策略的数据检索是增强当前对象存储分层功能的至关重要的补充。欢迎在 ceph-users 邮件列表 上分享您对该功能的想法或问题。我们很乐意了解您计划如何使用它,或者您是否希望增强任何方面。
脚注 ¶
有关 RGW 放置目标和存储类的更多信息,请访问 此页面
有关将数据定向到多个 RGW 存储类的相关介绍,请查看 此演示文稿
作者谨此感谢 IBM 对社区的支持,通过促使我们有时间创建这些帖子。