Ceph 对象网关性能深入探讨：构建安全且可扩展的对象存储（下）

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

01

前 言

本文是关于Ceph 对象网关性能深入探讨：构建安全且可扩展的对象存储系列的第二篇。若尚未阅读第一与第二部分，建议从第一篇入手。前文详细介绍了测试环境，包括硬件软件配置、网络架构及基准测试方法论以及通过测试 Ceph RGW 在 4 节点、8 节点及 12 节点集群的扩展表现，我们揭示了 PUT 与 GET 操作吞吐量随节点增加呈现近似线性提升的规律。研究同时验证了横向扩展可提升资源使用效率——即使是资源密集型的纠删码工作负载，其单节点资源消耗也随集群扩大而显著降低。

02

TLS 终端性能：S3 端点传输加密评估

为评估 TLS 对 Ceph 对象网关（RGW）S3 端点性能的影响，我们对比了三种常见部署策略：端到端加密（RGW 层 SSL）、cephadm 部署的 Ingress 服务（HAProxy）SSL 终端卸载，以及未加密基准方案。HAProxy 服务与 Ceph 对象网关（RGW）服务采用共用节点部署模式，每节点配置虚拟 IP 地址（VIP），基准测试客户端在所有 VIP 间实现请求负载均衡。本次测试在十二节点集群上采用 EC 8+3 配置，分别针对中/大对象（4 MiB）与小对象（64 KiB）工作负载进行。

中/大型对象工作负载 （4 MiB）

本节重点介绍 4 MiB 对象大小结果，作为中大型对象大小的代表性案例。对于更大的对象，由于传输效率更高，每字节开销更低，本文观察到的趋势通常保持不变或进一步优化。

RGW 层 SSL 加密方案的吞吐量与无 SSL 配置几乎持平：GET 请求仅低 0.4%，PUT 吞吐量下降幅度稍大为 4.2%。这种微小差异符合预期，因为集群处于网络瓶颈状态。尽管测试期间 RGW 平均 CPU 使用率 GET 增加 40%、PUT 增加 71%，但单主机最高 CPU 利用率仅达约 83%，额外负载未对性能产生实质影响。这表明 RGW 层 SSL 加密作为默认安全选项，对大对象工作负载的性能影响可忽略不计。

相比之下，在 Ingress 服务层（HAProxy）终止 SSL 的方案表现出更明显的性能影响：GET 吞吐量下降约 27%，PUT 吞吐量降低 19%，延迟相应增加。这种下降并非源于 SSL 本身开销，而是由于加密工作负载转移至 HAProxy 层所致。在重负载下，随着对象大小从 64 KiB 增至 1 GiB，单个 HAProxy 守护进程平均消耗 3 至 6 个 vCPU。Ceph 主机峰值 CPU 使用率最高达 90%，这表明需要针对 HAProxy 进行适当调优与扩展，以避免 CPU 成为性能瓶颈。

小对象工作负载 （64 KiB）

在处理小对象时，吞吐量瓶颈自然从网络转移至 CPU，使得加密开销更为显著。尽管如此，在 Ceph 对象网关（RGW）启用 SSL 的影响仍处于可控范围：相较于无 SSL 基准，GET IOPS 下降 5.2%，PUT IOPS 降低 10.7%。RGW 的 CPU 使用率 GET 增加 4.2%，PUT 增加 11.3%，这表明加密工作在集群中分布良好。虽然小对象工作负载对 CPU 使用率更为敏感，但端到端 SSL 方案仍具实用性——在多数场景下性能损耗被控制在个位数百分比范围内。

Ingress 层 SSL 终端方案再次呈现更显著的性能差距：相较于无 SSL 配置，GET IOPS 下降约 18%，PUT IOPS 降低 8%，同时伴随 Ingress 服务 CPU 使用率上升与请求延迟微增。尽管数据显示性能差异较大，该方案仍适用于生产环境——当安全策略要求 TLS 卸载时，只需确保 Ingress 服务的扩展能力与并发量及吞吐量目标匹配即可实现有效部署。

结论 - SSL/TLS S3 端点安全性

总而言之，在 Ceph 对象网关（RGW）层配置 SSL/TLS 可在安全性与性能间实现出色平衡：该方案为大对象工作负载提供接近基准的吞吐量，对小对象仅造成轻微性能衰减，同时保持端到端加密优势。

03

集群服务传输加密：大规模内部流量保护

随着安全标准的不断发展，保护 Ceph 守护进程之间的内部通信正在成为生产部署的最佳实践，尤其是在受监管的环境中。在 Ceph 中，此内部加密是通过 Messenger v2 安全模式启用的，也称为集群网络加密或传输中的内部加密。与保护外部客户端和 S3 Ceph 对象网关 （RGW） 端点之间的流量的 TLS 不同，Messenger v2 确保所有守护进程间流量（包括 RGW 到 OSD、OSD 到 Monitor 和 Manager 通信）都经过加密和身份验证。

本节介绍在启用 Ceph 对象网关 （RGW） SSL 的基准之上启用 Messenger v2 安全模式对性能的影响。两种配置（带安全模式和不带安全模式）都在 RGW 上使用 SSL 进行面向客户端的加密。测试是在 12 节点集群上进行的，使用 8+3 纠删码，中/大型对象大小（1 MiB 至 256 MiB）。

核心结论：强安全性的最小性能开销

我们评估了启用和未启用 Messenger v2 安全性的配置中 GET 和 PUT 作的吞吐量和延迟。如下图和表格所示，读取和写入作的性能增量可以忽略不计，这表明传输中的内部加密与高吞吐量对象存储用例兼容。

接下来是一个表格，该表提供了使用我们的参考 4 MiB 对象大小测量的配置之间百分比变化的完整比较。

分析

• 吞吐量影响：在所有测试对象大小（1 MiB 至 256 MiB）中，启用 Messenger v2 安全模式后 GET 吞吐量基本保持不变。PUT 吞吐量出现适度下降，其中 1 MiB 对象下降最明显（-3.1%），随对象大小增大影响趋近于零（如 64 MiB 和 256 MiB 仅-0.4%）。该趋势符合预期：小对象会放大加密开销，而大对象更受吞吐量限制且能摊薄额外成本。

• 延迟影响：GET 与 PUT 延迟在所有场景下均保持稳定。观测到的波动极小（通常为 ±1 毫秒），这证实即使在高并发和不同对象大小下，启用 Messenger v2 安全模式也不会引入显著排队或处理延迟。

• 资源利用率：RGW 层 CPU 使用率在 PUT 操作中略有上升（约 2-6%，具体取决于对象大小），GET 操作 CPU 使用率基本持平。内存消耗同样呈现微小变化（约 5-7%范围内），未出现资源耗尽或饱和迹象。

结论 – Messenger v2 内部加密方案

启用 Messenger v2 安全模式可为内部 Ceph 守护进程通信添加加密保护，对性能的影响可以忽略不计。我们的测试显示，所有对象大小的吞吐量和延迟都很稳定，RGW 内存和 CPU 使用率仅略有增加，主要是用于 PUT 操作。Messenger v2 的设计以最小的代价确保了强大的安全保障，使其与高吞吐量、企业级对象存储部署高度兼容。

04

最终建议——安全架构：TLS + Messenger v2

对于需要同时保障客户端传输安全与集群内部服务通信安全的环境，采用 S3 端点 TLS 加密与 Messenger v2 内部加密的组合方案，可在实现强安全性的同时将性能影响降至最低。

无论是保护 AI 训练、分析平台还是多租户对象存储服务，Ceph RGW 证明了全栈加密方案可放心部署——在吞吐量、延迟与扩展性方面均不会受到明显影响。

05

静态加密（SSE-S3）：应用场景与 4 MiB 测试结果

为何选择 SSE-S3？

静态加密确保对象数据在持久化存储前完成加密，仅在访问时解密。Ceph RGW 中的 SSE-S3 采用信封加密机制：每个对象使用独立数据密钥加密载荷，该数据密钥本身由 KMS（本基准测试中采用 Vault Transit 并通过 Vault Agent 实现令牌管理与认证卸载）进行存储和保护。该设计提供强安全保证与集中式密钥管控。

性能权衡符合预期：每个对象的 PUT/GET 操作均增加加密工作及（KMS 保护密钥的）解包步骤。对象越小，固定每对象成本占比越高。小对象测试中我们观察到预期规律：对象大小越小，每对象密钥操作与加密的相对开销越大

测试数据（12 节点，EC 8+3，512 客户端线程，4 MiB 对象）

测试方案：

• 基准方案 ：RGW + TLS + msgr_v2（未启用 SSE）

• SSE@RGW 方案 ：基准方案 + SSE-S3（TLS 在 RGW 层终止）

• SSE@Ingress 方案 ：SSE-S3 + TLS 在 HAProxy 层卸载（msgr_v2 启用）

SSE 与基线性能的吞吐量和延迟比较：

• 对于 4 MiB 对象，SSE@RGW 方案可保持约 90%的 PUT 吞吐量，仅伴随适度延迟增长——这对大对象写入密集型而言属积极结果。

• GET 路径表现出更高敏感性，因为每次读取均需解包对象数据密钥（涉及 KMS 往返+解密操作），该过程在高并发下成为限速因素。将 TLS 卸载至 Ingress 层可释放 RGW 的 CPU 资源并部分弥补 GET 性能差距，但 KMS 密钥解包成本仍是主要开销。

结论 – 静态加密 （SSE-S3）

SSE-S3 以可预测的性能开销提供强静态加密保护：对于大对象可保持高效处理（PUT 操作接近基准性能），但对于频繁存取的小对象工作负载则受 KMS 性能影响。通过对象大小优化、KMS 扩展部署以及 RGW/Ingress 容量规划，可有效缓解此类权衡。

06

下一步

我们未来的目标

• 探索快速 EC 改进 （Ceph 9.x） 以实现小对象 EC 性能。

• 使用 200/400 GbE 重新运行大型对象测试，以突破当前的网卡上限。

• 研究 SSL 终端卸载场景下 Ingress 服务更优的默认调优参数

07

结 论

在整个三部分系列中，我们验证了启用安全功能后的可预测扩展能力：

• 12 节点集群实现约 111 GiB/s GET 与 66 GiB/s PUT 吞吐量，4→8→12 节点扩展呈现近线性增益且延迟保持稳定或降低，64 KB 对象场景下达成约 39.1 万/8.6 万 IOPS。

• RGW 层 TLS 加密性能接近基准，Messenger v2 带来的开销可忽略不计，SSE-S3 则呈现可基于对象尺寸调节的加密成本

上述结果充分证明 Ceph 对象存储是大规模高吞吐、低延迟工作负载场景下的不错选择。

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