定安县网站建设_网站建设公司_一站式建站_seo优化

新钛云服已累计为您分享874篇技术干货

01

介 绍

本文是关于Ceph 对象网关性能深入探讨：构建安全且可扩展的对象存储系列的第二篇。若尚未阅读第一部分，建议从第一篇入手。前文详细介绍了测试环境，包括硬件软件配置、网络架构及基准测试方法论。

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

关于资源配置的注意事项：所有服务（RGW、Monitor、Manager、OSD 和 Ingress）都部署在所有节点上。这种部署方式虽反映典型实际场景，但资源共享可能引发内部资源争用。本次结果收集已考虑了该影响因素，若采用服务分离的部署方式，部分服务可能获得更高性能。

02

峰值吞吐量

为了达到 Ceph 对象网关 （RGW） 的性能上限，我们在理想条件下测试了一个 12 节点全 NVMe （288 OSD） 集群：采用优化纠删码配置、较大对象和高客户端并发性，以充分释放平台性能。

最大GET吞吐量

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

• 相当于单节点 9.25 GiB/s 的吞吐量，已逼近 Ceph 节点硬件物理网络容量极限。

• 瓶颈因素：网络。每个节点配备通过 LACP 绑定的双 100GE 网卡，但所使用的英特尔网卡每卡所有端口总带宽限制为 100Gbps（12.5 GiB/s）。集群级约 111 GiB/s 的结果表明，在计入帧开销后，我们已非常接近线速饱和状态。

最大PUT吞吐量

• 在类似测试条件下达到 65.8 GiB/s 的总 PUT 吞吐量。

• PUT 操作因数据复制需要额外 I/O（尤其采用纠删码时会产生集群内数据倍增），故吞吐量低于 GET。

• 尽管如此，每个节点仍平均交付约 5.5 GiB/s 吞吐量。若计入复制流量，该结果同样接近节点网卡的有效带宽极限。

CPU和内存利用率

• RGW 进程的 CPU 使用率始终保持在可控范围内（跨 768 个 vCPU 的集群总 RGW CPU 占用率为 8-14%），这证实了大对象工作负载下 RGW 与 CPU 资源均未成为瓶颈。

• 不同纠删码配置（2+2、4+2、8+3）下的延迟表现保持稳定，进一步表明测试期间的瓶颈在于网络而非计算资源。

03

峰值 IOPS

虽然大对象测试展现了集群的原始吞吐潜力，但小对象（64 KiB）工作负载则有助于揭示元数据与 IOPS 的扩展性边界。我们采用十二节点全 NVMe 集群和高客户端并发，通过多种纠删码配置分别测试 GET 与 PUT 操作，以获取该平台在处理小对象时可持续的峰值的 IOPS。

最大 GET IOPS

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

• 限制因素：RGW 上的 CPU 使用率开始上升（768 个 vCPU 的 ~9.8%），但系统仍有空间。跨客户端线程的低延迟和一致的扩展表明，集群可以通过额外的客户端资源/并发来推送更高的 IOPS。

最大 PUT IOPS

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

• 限制因素：由于纠删码写入，PUT 作涉及更多的后端。虽然 RGW CPU 使用率仍然适中 （~2.9%），但 OSD 层和 I/O 复杂性可能会限制进一步的性能。GET 和 PUT IOPS 之间的差距反映了工作负载成本的不对称性。

CPU 和内存利用率

对于小型对象应用 （64 KB），RGW CPU 使用率显示出 GET 和 PUT 作之间的明显区别。GET 操作类型应用的每个 RGW 守护进程消耗的 CPU 要多得多，从低并发时的 ~3 个内核扩展到每个 RGW 的近 10 个核心，有 8 个客户端（1,024 个线程）。相比之下，PUT 工作负载始终保持较轻，即使在最大并发性下，每个 RGW 的峰值也略低于三个核心。

该现象源于 GET 请求的极高吞吐量。尽管单个请求处理轻量，但海量请求频率导致 CPU 周期消耗激增。而 PUT 请求虽涉及更复杂的 I/O 路径，但因执行频率较低（约 8.7 万 IOPS），且受益于写入路径优化，反而 CPU 负担更轻。

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

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

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

04

EC 2+2 的水平可扩展性（4MB 对象）

为了评估横向扩展 Ceph 对象网关 （RGW） 的影响，我们使用纠删码 2+2 配置文件、4MB 对象大小和在 RGW 层启用的 SSL 进行了受控测试。之所以选择此特定的 EC 配置文件，是因为它在 4、8 和 12 节点部署中都有效，从而可以进行公平的同类比较。

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

分析

• 可预测的线性扩展：随着集群从 4 个节点扩展到 12 个节点，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 核心；内存使用亦从约 1035 MiB 减少至约 698 MiB。GET 操作呈现相似趋势：单 RGW 内存占用降低约 35%，CPU 使用率始终维持低位。

本测试表明：扩展 Ceph 集群节点不仅能提升原始存储容量，还可按比例增强吞吐量与运行效率。对于包含备份、媒体处理流水线或 AI 训练集暂存等大对象工作负载的场景，这种水平扩展模式至关重要。在保持配置一致性与适度调优的前提下，Ceph 对象网关（RGW）能够实现线性且可预测的扩展，以满足持续增长的性能需求。

05

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

为深入比较复制与纠删码在不同对象下的性能表现，我们在四节点集群上分别采用副本数 3（replica 3）与 EC 2+2 配置对 Ceph RGW 进行测试（网关层启用 SSL）。虽然理想情况下应在十二节点集群进行对比，但由于时间限制，副本数 3 配置仅于四节点环境完成测试。我们计划在支持快速纠删码优化的 Tentacle 功能可用后，使用更大规模部署重新进行基准测试。

所有测试场景均采用 512 客户端线程，以避免四节点小集群出现过载。测试对象大小从 64 KiB 到 256 MiB 不等，以观察复制与纠删码在不同 I/O 模式下的扩展特性。

下表是吞吐量与延迟相对差异对比：副本数 3 vs EC 2+2

正值表示副本数 3 配置性能更优（吞吐量更高/延迟更低）

分析：吞吐量和延迟比较

• 对于小对象（64 KiB），副本数 3 配置显著优于 EC 2+2：PUT 吞吐量高出 18%，GET 吞吐量高出 37%。该现象符合预期：纠删码的编解码开销会增加延迟与计算成本，使副本数 3 更适用于高操作频率的小对象工作负载。

• 随着对象增大，副本数 3 的吞吐量优势逐渐收窄。在 1 MiB 和 4 MiB 对象测试中，性能差异依然存在但缩小——副本数 3 的 GET 吞吐量领先 8-9%，PUT 吞吐量领先 6-7%。

• 当对象尺寸增至 64 MiB 等大尺寸时，两种方案均逼近四节点集群的网络饱和点，导致吞吐量趋于平稳。此时性能差异变得微不足道，两种架构均无法充分发挥其优势，因此 64 MiB 的测试结果对于复制效率比较的参考价值有限。

• 延迟趋势与吞吐量表现一致。副本数 3 在所有尺寸下均保持更低的 PUT 与 GET 延迟，但其相对优势随对象尺寸增大而减弱：GET 延迟优势从 64 KiB 时的 33%收窄至 64 MiB 时的约 16%。

06

展望未来：EC 性能增强

预计小对象场景下的性能差距将在未来版本中收窄。Ceph Tentacle 引入的快速纠删码（Fast EC）技术，通过优化纠删码填充机制提升小对象性能，使纠删码即使在高频小对象工作负载中也成为更具吸引力的选择。

07

接下来

在下一篇文章中，我们将深入探讨不同安全配置方案——包括 TLS/SSL 传输加密、SSE-S3 服务器端加密及 msgr v2 通信协议——对 Ceph 对象网关（RGW）性能的影响机制，并分析这些安全措施在大/小对象工作负载场景中的性能权衡。同时，我们将结合真实场景基准测试结果，开始解析 Ceph 对象网关与 CPU 资源的最优配比方案。

如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。

推荐阅读

推荐视频