基准测试 Ceph 对象网关：深入了解安全、可扩展的对象存储性能。第二部分

2025年9月16日 Daniel Alexander Parkes, Anthony D'Atri

简介

本文是我们关于基准测试 All-Flash IBM Storage Ceph (Dell) Ready Nodes 上的 Ceph 对象网关 (RGW) 的博客系列第二篇。如果您还没有阅读 第一部分，我们建议您从那里开始。它提供了我们测试环境的全面细节，包括硬件和软件配置、网络架构和基准测试方法。

在本篇中，我们将深入研究关键性能结果，重点关注峰值吞吐量、最大 IOPS 和水平可扩展性结果。

关于资源共置的说明：所有服务——RGW、Monitor、Manager、OSD 和 Ingress——都在所有节点上以共置方式部署。虽然这反映了典型的实际部署模式，但也意味着资源共享可能会引入内部争用。这些结果是在考虑到这种权衡的情况下收集的，并且进一步分离服务可能会为特定工作负载带来更高的性能。

峰值吞吐量性能亮点

为了发现 Ceph 对象网关 (RGW) 的上限，我们测试了一个十二节点的全 NVMe (288 OSD) 集群，在理想条件下，使用优化的 EC 配置、大对象大小和高客户端并发度，以将平台推至其最大能力。

最大 GET 吞吐量

  • 使用 32 MiB 对象（EC 2+2，RGW SSL 已启用，12 个节点，1024 个客户端线程）实现了 111 GiB/s 的聚合 GET 吞吐量。

  • 这相当于每个节点 9.25 GiB/s，将 Ceph 节点硬件的物理网络容量推至极限。

  • 限制因素：网络。每个节点都配备了通过 LACP 绑定的双 100 GE NIC；但是，所使用的 Intel 卡限制了每个卡上所有端口的总带宽为 100 Gbps (12.5 GiB/s)。鉴于此，~111 GiB/s 的整个集群结果证实，考虑到帧开销，我们非常接近线路速率饱和。

最大 PUT 吞吐量

  • 在相似的测试条件下，达到了 65.8 GiB/s 的聚合 PUT 吞吐量。

  • PUT 操作本质上需要额外的 I/O 用于复制，尤其是在使用 EC 时，这会增加集群内的的数据移动。这解释了为什么 PUT 吞吐量低于 GET。

  • 尽管如此，每个节点仍然平均提供 ~5.5 GiB/s，考虑到复制流量，这再次使我们接近节点的有效 NIC 限制。

CPU 和内存利用率

  • RGW 进程的 CPU 使用率保持在合理范围内（整个集群 RGW CPU 占 768 个 vCPU 的 8–14%），确认 RGW 或 CPU 资源不是大型对象工作负载的瓶颈。

  • 延迟在 EC 配置（2+2、4+2、8+3）中保持一致，进一步表明网络而不是计算资源是测试期间的限制因素。

峰值 IOPS 性能亮点

虽然大型对象测试揭示了集群的原始吞吐量潜力，但小型对象工作负载（64 KiB）有助于暴露元数据和 IOPS 可扩展性的限制。使用十二节点的全 NVMe 集群和高客户端并发度，我们测试了 GET 和 PUT 操作，并使用了多种 EC 配置，以隔离平台在小对象大小下可以维持的峰值每秒操作数。

最大 GET IOPS

  • 使用 64 KiB 对象（EC 2+2，无 SSL，12 个节点，1024 个客户端线程）实现了 ~391K GET IOPS。这对应于 ~24.4 GiB/s 的总 GET 吞吐量和 ~2 ms 的平均延迟。

  • 限制因素：RGW 上的 CPU 使用率开始上升（~9.8% 在 768 个 vCPU 上），但系统仍然有余量。低延迟和跨客户端线程的一致缩放表明，如果拥有额外的客户端资源/并发度，集群可以推动更高的 IOPS。

最大 PUT IOPS

  • 使用相同的配置（64KiB，EC 2+2，RGW 带 SSL，12 个节点，1024 个客户端线程）记录了 ~86.6K PUT IOPS。PUT 吞吐量在完全并发度（1024 个客户端线程）下达到峰值 ~5.4 GiB/s，平均延迟为 ~8 毫秒。

  • 限制因素：PUT 操作涉及更多的后端协调，因为擦除编码写入。虽然 RGW CPU 使用率保持适中（~2.9%），但 OSD 层和 I/O 复杂性可能限制了进一步的提升。GET 和 PUT IOPS 之间的差距反映了工作负载成本的这种内在不对称性。

CPU 和内存利用率

对于小型对象工作负载（64 KB），RGW CPU 使用率在 GET 和 PUT 操作之间显示出明显区别。GET 工作负载消耗更多的 CPU 每 RGW 守护进程，从低并发时的 ~3 个核心到八个客户端（1,024 个线程）时的近 10 个核心。相比之下，PUT 工作负载保持一致地更轻，即使在最大并发度下，每个 RGW 的峰值也仅为三个核心。

这种行为归因于 GET 请求的数量（如下所示）：峰值超过 390K IOPS，尽管单个请求的开销很小，但由于其频率而需要更多的 CPU 周期。此外，PUT 请求涉及更重的 I/O 路径，但发生频率较低（~87K IOPS），并且受益于写入路径优化。

注意：生产环境中的对象存储工作负载往往是读取密集型（GET 占主导地位）。这种模式与常见用例一致，包括分析管道、数据湖和媒体交付系统。

内存消耗在整个测试过程中在 RGW 守护进程中保持稳定，没有出现压力或泄漏的迹象。每个 RGW 守护进程在 PUT 操作期间消耗 170 到 260 MiB 内存，在 GET 操作期间消耗 205 到 260 MiB 内存，随着并发度的增加，内存消耗逐渐增加。

这些结果表明，对于小型对象工作负载，CPU 可用性成为主要的性能因素，尤其是在高 GET 请求速率下。随着 IOPS 扩展到数十万，提供足够的 CPU 资源对于保持低延迟和高吞吐量至关重要。

使用 EC 2+2（4MB 对象）进行水平可扩展性

为了评估 Ceph 对象网关 (RGW) 的扩展影响，我们进行了一项受控测试，使用了擦除编码 2+2 配置、4MB 对象大小，并在 RGW 层启用了 SSL。选择此特定 EC 配置是因为它在 4、8 和 12 个节点部署中有效，从而可以进行公平的比较。

通过逐步增加节点和 OSD 的数量，我们观察了系统在相同客户端并发度和请求大小下在吞吐量、延迟和资源消耗方面的响应方式。

分析

  • 可预测的线性扩展：随着集群从四到十二个节点扩展，GET 吞吐量几乎翻了两倍，从 ~39 GiB/s 增长到 ~113 GiB/s。PUT 吞吐量也增加了 3 倍以上，从 ~15.5 GiB/s 增加到略高于 50 GiB/s。这种线性增长强化了 Ceph 对象网关在读取和写入操作中的水平可扩展性的有效性。

  • 延迟、稳定性和改进：GET 延迟随着集群的扩展而保持稳定并得到改善。十二节点的部署表现出更低的延迟（36 毫秒），与八节点部署（52 毫秒）相比，尽管实现了更高的吞吐量。这表明规模扩大降低了争用和提高了并行性。

  • CPU 和内存资源

Ceph 分布式架构的关键优势之一是它能够随着集群规模的扩大而摊销每个服务的资源。使用 64 MiB 对象和 1024 个并发线程，我们的测试表明，即使吞吐量增加了三倍以上，RGW CPU 和内存使用率每守护进程也减少了。PUT 操作通常更耗资源，因为擦除编码计算，RGW CPU 使用率从四个节点上的 ~9.2 个核心降低到十二个节点上的 5.7 个核心。同样，RGW 内存使用量从 ~1035 MiB 降低到 ~698 MiB，随着集群的扩展。GET 操作显示了可比的趋势：内存下降了 ~35% 每 RGW，CPU 保持一致较低。

此测试表明，向 Ceph 集群添加节点不仅增加了原始存储容量，还按比例提高了吞吐量和效率。对于大型对象工作负载，包括备份、媒体管道或 AI 训练集暂存，这种水平增长模式至关重要。通过一致的配置和适度的调整，Ceph 对象网关 (RGW) 能够线性且可预测地扩展，以满足不断增长的性能需求。

副本 3 与 EC 2+2：对象大小对性能的影响

为了更好地了解复制和擦除编码在不同对象大小上的比较方式，我们使用四节点集群测试了 Ceph RGW，使用了副本 3 和 EC 2+2 配置，并在网关级别启用了 SSL。理想情况下，我们希望将此比较扩展到十二个节点，但由于时间限制，副本 3 仅在四个节点上进行了测试。我们计划在 Tentacle 可用后重新进行这些基准测试，Tentacle 引入了快速 EC 改进。

每个场景都使用 512 个客户端线程进行测试，以避免使较小的四节点集群饱和。对象大小范围从 64 KiB 到 256 MiB，以观察复制和擦除编码如何扩展到不同的 I/O 配置文件。

表 1：吞吐量和延迟的相对差异：副本 3 与 EC 2+2

正数 = 副本 3 表现更好（更高的吞吐量，更低的延迟）

对象大小PUT 吞吐量增加GET 吞吐量增加PUT 延迟改进GET 延迟改进
64 KiB+18%+37%+18%+33%
4 MiB+6%+22%+6%+16%
64 MiB+1%+21%+2%+16%
256 MiB+1%+21%+2%+17%

分析：吞吐量和延迟比较

  • 对于较小的对象（64 KiB），副本 3 明显优于 EC 2+2，PUT 吞吐量提高了 18%，GET 吞吐量提高了 37%。这种行为与预期一致：EC 中的编码/解码开销会增加延迟和计算成本，使副本 3 更适合高操作、小对象工作负载。

  • 随着对象大小的增长，副本 3 的吞吐量优势缩小。在 1 MiB 和 4 MiB 时，性能差异仍然明显但较小，副本 3 提供了 8–9% 更高的 GET 吞吐量和 6–7% 更高的 PUT 吞吐量。

  • 但是，在较大的客户端对象大小（如 64 MiB）下，两者都达到了四节点集群的网络饱和点，导致吞吐量停滞。因此，性能差异变得微不足道，并且任何方案都无法充分利用其架构优势。这使得 64 MiB 结果不太可靠，无法比较复制效率。

  • 延迟趋势与吞吐量相呼应。副本 3 在所有大小上都保持了更低的 PUT 和 GET 延迟，但相对改进随着对象大小的增加而降低，从 64 KiB 时 GET 快 33% 到 64 MiB 时快约 16%。

展望未来：EC 性能增强

预计未来版本中，小对象大小的性能差距将会缩小。Ceph Tentacle 引入了 快速 EC，它解决了擦除编码填充效率低下问题，并提高了小对象性能。这些进步使即使对于高频率的小对象工作负载，擦除编码也成为更具吸引力的选择。

请查看 Ceph Day London 幻灯片 和 视频 中 Fast EC 改进的详细信息。我们添加了一个来自 FastEC 初始基准测试结果的图表，以激起您的食欲

即将推出

在下一篇帖子中，我们将探讨不同安全配置（包括 TLS/SSL、SSE-S3 和 msgr v2）引入的权衡，以及它们如何影响 Ceph 对象网关 (RGW) 在小型和大型对象工作负载上的性能。我们还将开始分析最佳的 Ceph 对象网关与 CPU 比率，因为我们将更深入地研究实际基准测试结果。

阅读第三部分 这里

作者感谢 IBM 对社区的支持，为我们提供时间来创建这些帖子。