通过新的 HTTP 同步状态头增强 Ceph 对象多站点复制的可视性
简介 ¶
在一个数据必须在多个地理区域内快速访问和保护的世界中，多站点复制是对象存储的关键特性。无论运行全球应用程序还是维护强大的灾难恢复计划，在不同区域之间复制对象对于冗余和业务连续性至关重要。
Ceph 对象存储多站点复制是异步且基于日志的。异步复制的性质可能会给验证数据当前所在位置或确认其已完全复制到所有远程站点带来挑战。这对于某些需要接近强一致性的写入以及所有对象在所有站点上都已复制并可供应用程序或用户访问的应用程序和用例来说是不可接受的。
作为补充说明，可以使用 Ceph Stretch 集群解决方案提供同步复制来实现完全的写入一致性，但对于地理分布的解决方案而言，这存在局限性，因为延迟是 Stretch 集群的关键因素。因此，如果您需要地理复制，通常会为对象存储实施多站点异步复制作为解决方案。
挑战 ¶
应用程序所有者通常需要在对象在目标站点上可用之前知道它是否可用，然后才能触发后续操作（例如，分析作业、进一步的数据处理或法规归档）。存储操作团队可能希望清楚地了解复制需要多长时间，从而能够提醒并诊断缓慢或有故障的网络链接。自动化和数据管道可能需要一种以编程方式跟踪复制状态才能继续工作流中下一步的方法。
Ceph Squid 引入复制头 ¶
为了解决此可见性差距，Ceph Squid 引入了新的 HTTP 响应头，这些头公开了每个对象在复制过程中的确切位置
x-amz-replication-status
一种快速确定对象是否正在等待复制、正在进行中或已完全复制的方法。状态可能显示PENDING、COMPLETED或REPLICA，具体取决于配置。x-rgw-replicated-from
显示对象最初复制的源站点。x-rgw-replicated-at
提供一个时间戳，指示对象何时成功复制。通过将其与对象的Last-Modified头进行比较，您可以获得即时复制延迟的度量，这对于实时监控或性能调整非常宝贵。
这些头信息提供了一种以编程方式确定数据是否已传播到目标站点的方法。重要的是要注意，这些新的 HTTP 复制头的主要用例是在摄取期间查询对象的状态，以帮助应用程序根据对象的复制状态做出决策。这不适用于基础架构团队通过扫描数十亿个对象来检查所有对象的复制状态。
HTTP 复制头的示例用例 ¶
应用程序工作流 ¶
开发人员可以将这些头信息集成到他们的应用程序逻辑中。上传对象后，应用程序可以轮询 x-amz-replication-status 头信息，以确保对象在触发后续操作之前已完全在目标站点上可用。
运营金丝雀监控 ¶
自动化作业（有时称为合成测试或金丝雀测试）可以定期上传和删除对象，检查复制需要多长时间。如果延迟超过某个阈值，可以提醒运营团队调查潜在的网络或配置问题。
数据管道和通知 ¶
虽然轮询头信息通常是最直接的方法，但您可以为某些复制相关事件利用 Ceph S3 存储桶通知。将这些与消息代理（如 Kafka）集成可以帮助协调更大的、事件驱动的工作流。有关更多信息，请参阅 Ceph 文档关于 S3 通知。
基本动手示例 ¶
我已在两个 Ceph 集群之间设置了多站点复制。它们是名为 multizg 的区域组的一部分，并且我们配置了 zone1 和 zone2 之间的双向完全区域复制。
# radosgw-admin sync info
{
"sources": [
{
"id": "all",
"source": {
"zone": "zone2",
"bucket": "*"
},
"dest": {
"zone": "zone1",
"bucket": "*"
},
"dests": [
{
"id": "all",
"source": {
"zone": "zone1",
"bucket": "*"
},
"dest": {
"zone": "zone2",
"bucket": "*"
},
...
有关 Ceph 对象存储多站点复制的详细信息，请参阅博客系列，该系列深入介绍了此功能，从架构到设置和微调
multisite part1
multisite part2
multisite part3
multisite part4
multisite part5
multisite part6
multisite part7
multisite part8
一种查看这些新复制头信息的方法是使用 s3cmd 和 --debug 标志，该标志会打印来自 Ceph 对象网关的原始 HTTP 响应头信息。通过筛选 rgw- 或 x-amz- 行，我们可以轻松地发现与复制相关的信息。
让我们看看。我将一个对象上传到 zone1
# s3cmd --host ceph-node-00:8088 put /etc/hosts s3://bucket1/file20
upload: '/etc/hosts' -> 's3://bucket1/file20' [1 of 1]
640 of 640 100% in 0s 7.63 KB/s done
当我检查源站点上对象的状态时，它处于 PENDING 状态，表示该对象仍在复制。最终，一旦复制完成，状态将在源站点过渡到 COMPLETED，在目标站点过渡到 REPLICA。
# s3cmd --host ceph-node-00:8088 --debug info s3://bucket1/file20 2>&1 | grep -B 2 'rgw-'
'x-amz-replication-status': 'PENDING',
'x-amz-request-id': 'tx00000f2948c72a2d2fb8e-0067a5c961-35964-zone1',
'x-rgw-object-type': 'Normal'},
现在，让我们检查目标站点端点
# s3cmd --host ceph-node-05:8088 --debug info s3://bucket1/file20 2>&1 | grep -B 2 'rgw-'
'x-amz-replication-status': 'REPLICA',
'x-amz-request-id': 'tx00000a98cf7b6a584b95b-0067a5cac9-29779-zone2',
'x-rgw-object-type': 'Normal',
'x-rgw-replicated-at': 'Fri, 07 Feb 2025 08:50:07 GMT',
'x-rgw-replicated-from': 'b6c9ca95-6683-42a5-9dff-ba209039c61b:bucket1:b6c9ca95-6683-42a5-9dff-ba209039c61b.32035.1'},
在这里，相关的头信息告诉我们
x-amz-replication-status: REPLICA
对象已完成复制，并且在远程站点上可用。x-rgw-replicated-at: 'Fri, 07 Feb 2025 08:50:07 GMT'
显示完成复制的时间戳。x-rgw-replicated-from: 8f8c3759-aaaf-4e6d-b346-...:bucket1:...
标识对象复制的源站点（和存储桶）。
让我们检查一下源站点的对象状态是否已移动到 COMPLETE 状态
# s3cmd --host ceph-node-00:8088 --debug info s3://bucket1/file20 2>&1 | grep x-amz-replication-status
'x-amz-replication-status': 'COMPLETED',
如何在应用程序工作流中使用这些头信息的示例 ¶
这种直接的轮询机制——通过 HEAD 或信息请求——可以插入到应用程序工作流中，以在采取进一步操作之前确认完全复制。让我们看一个基本示例。
想象一下内容分发网络 (CDN) 的场景，您必须在全球范围内复制文件，以确保最终用户在多个地理区域内获得低延迟访问。一个区域中的应用程序上传媒体资产（图像、视频或静态网站内容），这些资产必须复制到其他 RGW 站点，然后我们才能将其提供给最终用户使用。
这里 是一个代码片段，其中包含一个使用 Python 库 boto3 将媒体内容上传到站点，然后通过查询复制状态头信息来轮询我们新上传的媒体内容的复制状态的示例。一旦对象被复制，我们就会打印出相关信息，包括源和目标 RGW 站点以及复制延迟。
应用程序示例输出
结论 ¶
Ceph Squid 对象存储中的新复制头信息标志着开发人员、DevOps 团队和存储管理员在多站点复制方面获得更多粒度控制和可见性的重要一步。通过查询 x-amz-replication-status、x-rgw-replicated-from 和 x-rgw-replicated-at 头信息，应用程序可以确认对象已完全同步，然后才能继续下游工作流。这种简单但强大的功能可以简化 CDN 分发、数据分析管道和其他需要多站点一致性的用例。
请注意，此处描述的一些功能可能在 Squid 19.2.2 版本发布之前不可用。
作者感谢 IBM 对社区的支持，为我们提供时间来创建这些帖子。