基准测试 Ceph 对象网关：深入了解安全、可扩展的对象存储性能。第三部分
此前，在我们的性能博客系列文章的第二部分中 ¶
我们探讨了 IBM Storage Ceph RGW 如何随节点数量扩展，揭示了对于四、八和十二个节点，PUT 和 GET 操作的吞吐量几乎呈线性提升。我们还检查了资源使用趋势如何随着集群规模的变化而演变，确认了即使对于资源密集型擦除编码工作负载，扩展也能提高效率。如果您还没有查看，以下是第二部分的链接：第二部分。
TLS 终止性能：S3 端点传输中的加密 ¶
为了评估 TLS 对 Ceph 对象网关 (RGW) S3 端点性能的影响，我们比较了三种常见的部署策略：端到端加密（RGW 上的 SSL）、在 cephadm 部署的入口服务（HAProxy）处终止 SSL，以及未加密的基线。HAproxy 服务与 Ceph 对象网关 (RGW) 服务共置。为每个节点配置一个虚拟 IP 地址 (VIP)，基准测试客户端在所有配置的 VIP 上平衡请求。这些测试是在一个十二节点集群上使用 EC 8+3 进行的，对象工作负载为中等（4 MiB）和小型（64 KiB）。
中型/大型对象工作负载（4 MiB） ¶
本节重点介绍 4 MiB 对象大小的结果，这代表了中到大型对象大小的典型案例。对于更大的对象，观察到的趋势通常会保持或进一步改善，因为每字节的开销较低，传输效率更高。
在 Ceph 对象网关 (RGW) 上使用 SSL 提供的吞吐量几乎与无 SSL 配置相同。对于 GET 请求，差异仅低 0.4%，而 PUT 吞吐量显示略有下降 4.2%。这种小的差异是可以预期的，因为集群受网络限制。尽管在这些测试期间，平均 Ceph 对象网关 (RGW) CPU 使用率对于 GET 增加了 40%，对于 PUT 增加了 71%，但每个 Ceph 主机的最大 CPU 利用率达到 ~83%，额外的负载对性能没有实质性影响，证实了在 RGW 上使用 SSL 是一种安全默认选项，对于大型对象工作负载几乎没有性能损失。
| 指标 | 无 SSL（基线） | RGW 上的 SSL | 与无 SSL 的 % 变化 |
|---|---|---|---|
| GET 吞吐量（MiB/s） | 96,351 | 95,965 | -0.4% |
| PUT 吞吐量（MiB/s） | 58,086 | 55,651 | -4.2% |
| GET 延迟（ms） | 42 | 42 | 0% |
| PUT 延迟（ms） | 64 | 70 | +9.4% |
| RGW CPU（GET） | 3.19 核 | 4.46 核 | +40% |
| RGW CPU（PUT） | 3.62 核 | 6.19 核 | +71% |
相反，在入口服务（HAProxy）处终止 SSL 显示出更明显的影响。GET 和 PUT 的吞吐量分别下降了约 27% 和 19%，并且延迟也相应增加。这种下降并非由于 SSL 开销本身，而是由于加密工作负载转移到 HAProxy 层。在高负载下，每个 HAProxy 守护进程消耗 3 到 6 个 vCPU（平均值），因为对象大小从 64 KiB 扩展到 1 GiB。Ceph 主机的峰值 CPU 利用率达到高达 90%，强调了适当的 HAProxy 调整和扩展以防止 CPU 成为瓶颈的必要性。
小型对象工作负载（64 KiB） ¶
对于小型对象，吞吐量自然会从受网络限制变为受 CPU 限制，从而使加密开销更加明显。尽管如此，在 Ceph 对象网关 (RGW) 上启用 SSL 的影响仍然可控。GET IOPS 下降了 5.2%，PUT IOPS 下降了 10.7%，相对于无 SSL 基线。Ceph 对象网关 (RGW) CPU 使用率对于 GET 增加了 4.2%，对于 PUT 增加了 11.3%，表明加密工作已很好地分布在整个集群中。尽管小型对象工作负载对 CPU 使用率的敏感性较高，但端到端 SSL 仍然是实用的，在大多数情况下，性能下降控制在个位数百分比以内。
| 指标 | 无 SSL（基线） | RGW 上的 SSL | 与无 SSL 的 % 变化 |
|---|---|---|---|
| GET IOPS | 137,226 | 130,089 | -5.2% |
| PUT IOPS | 75,074 | 67,013 | -10.7% |
| GET 延迟（ms） | 3.05 | 3.25 | +6.6% |
| PUT 延迟（ms） | 9.75 | 10.00 | +2.5% |
| RGW CPU（GET） | 6.11 核 | 6.37 核 | +4.2% |
| RGW CPU（PUT） | 2.20 核 | 2.45 核 | +11.3% |
再次，入口终止的 SSL 引入了更大的性能差距。与无 SSL 相比，GET IOPS 下降了约 18%，PUT IOPS 下降了 8%。这伴随着入口 CPU 消耗增加和请求延迟略微升高。虽然这些数字表明性能差异更大，但这种设置仍然适用于生产部署，其中安全策略规定 TLS 卸载，前提是入口扩展与并发性和吞吐量目标保持一致。
结论 – SSL/TLS S3 端点安全性 ¶
总而言之，Ceph 对象网关 (RGW) 上的 SSL/TLS 为大多数对象工作负载提供了安全性和性能之间的出色平衡。它为大型对象提供接近基线的吞吐量，并为小型对象提供适度的性能下降，同时保持端到端加密。
集群服务传输中加密：大规模保护内部流量 ¶
随着安全标准不断发展，保护 Ceph 守护进程之间的内部通信对于生产部署（尤其是在受监管的环境中）正成为一种最佳实践。在 Ceph 中，此内部加密通过 Messenger v2 安全模式启用，也称为集群网络加密或传输中的内部加密。与 TLS 不同，TLS 保护外部客户端与 S3 Ceph 对象网关 (RGW) 端点之间的流量，而 Messenger v2 确保所有守护进程间流量（包括 RGW 到 OSD、OSD 到监视器以及管理器通信）都经过加密和身份验证。
本节检查启用 Messenger v2 安全模式对 Ceph 对象网关 (RGW) SSL 启用基线性能的影响。两种配置——启用和禁用安全模式——均在客户端加密方面使用 RGW 上的 SSL。这些测试是在一个十二节点集群上使用 8+3 擦除编码和中到大型对象大小（1 MiB 到 256 MiB）进行的。
高级概述：更强的安全性带来的最小开销 ¶
我们评估了启用和禁用 Messenger v2 安全性的 GET 和 PUT 操作的吞吐量和延迟。如以下图表和表格所示，对于读写操作，性能差异可以忽略不计，这表明传输中的内部加密与高吞吐量对象存储用例兼容。
接下来是一个表格，提供了使用我们参考的 4 MiB 对象大小测量的百分比变化的完整比较。
| 指标 | 无加密 | 安全 Messenger v2 | % 变化 |
|---|---|---|---|
| GET 吞吐量 | 95,965 MiB/s | 95,671 MiB/s | -0.3% |
| PUT 吞吐量 | 55,651 MiB/s | 52,994 MiB/s | -4.8% |
| GET 延迟 | 42 ms | 42 ms | 0% |
| PUT 延迟 | 70 ms | 71 ms | +1.4% |
| RGW CPU（GET） | 4.46 核 | 4.38 核 | -1.8% |
| RGW CPU（PUT） | 6.19 核 | 6.55 核 | +5.8% |
| RGW 内存（GET） | 313 MiB | 336 MiB | +7.3% |
| RGW 内存（PUT） | 308 MiB | 329 MiB | +6.8% |
分析 ¶
吞吐量影响：在所有测试的对象大小（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 的设计确保了强大的安全保证，且权衡最小，使其与高吞吐量、企业级对象存储部署高度兼容。
最终建议 – 安全设计：TLS + Messenger v2 ¶
对于需要对客户端和集群服务之间的流量进行强数据保护的环境，S3 端点上的 TLS 和内部加密的 Messenger v2 的组合提供了强大的安全性，且对性能的影响最小。
无论您是保护 AI 管道、分析平台还是多租户对象存储服务，Ceph RGW 都证明了可以自信地部署全栈加密，而不会影响吞吐量、延迟或可扩展性。
静态加密（SSE-S3）：上下文和 4 MiB 结果 ¶
为什么选择 SSE-S3？ ¶
静态加密可确保对象数据在持久化之前被加密，并且仅在访问时才被解密。在 Ceph RGW 中，SSE-S3 使用信封加密：每个对象的密钥加密有效负载；该数据密钥本身由 KMS 存储和保护：我们使用 Vault Transit 通过 Vault 代理进行令牌管理和身份验证卸载期间的基准测试。这种设计提供了强大的安全保证和集中式密钥控制。
权衡是可预测的：每个对象 PUT/GET 都会增加加密工作和（对于 KMS 保护的密钥）密钥解包步骤。对象越小，固定的每对象成本就越占主导地位。对于较小的对象大小，我们观察到预期的模式：对象越小，来自每对象密钥操作和加密的相对开销越大
我们测量的内容（12 个节点，EC 8+3，512 个客户端线程，4 MiB 对象） ¶
配置
- 基线：RGW + TLS + msgr_v2（无 SSE）
- RGW 上的 SSE：基线 + SSE-S3（TLS 在 RGW 处终止）
- SSE @ 入口：SSE-S3，TLS 卸载在 HAProxy 处（msgr_v2）
SSE 与基线性能的吞吐量和延迟比较
| 指标 | 基线（无 SSE） | RGW 上的 SSE | 与基线的 Δ | SSE @ 入口 | 与基线的 Δ |
|---|---|---|---|---|---|
| PUT 吞吐量（MiB/s） | 44,121 | 39,643 | -10.1% | 33,922 | -23.1% |
| PUT 延迟（ms） | 44 | 50 | +13.6% | 57 | +29.5% |
| GET 吞吐量（MiB/s） | 85,951 | 46,815 | -45.5% | 63,574 | -26.0% |
| GET 延迟（ms） | 23 | 25 | +8.7% | 32 | +39.1% |
如何阅读此内容： ¶
- 在 4 MiB 时，RGW 上的 SSE 保持约 90% 的 PUT 吞吐量，并具有适度的延迟增加——对于大型对象、写入密集型管道来说是个好消息。
- GET 路径显示出更大的敏感性，因为每次读取都需要解包对象的数据密钥（KMS 往返 + 解密），这成为更高并发时的限制因素。将 TLS 卸载到入口可以释放 RGW 上的 CPU 并恢复部分 GET 差距，但 KMS/密钥解包成本仍然占主导地位。
结论 – 静态加密（SSE-S3） ¶
SSE-S3 提供强大的静态加密，且具有可预测的开销：它对于较大的对象（PUT 保持接近基线）是高效的，并且对于小型、繁忙的工作负载，KMS 敏感，您可以通过对象大小、KMS 扩展以及 RGW/入口容量规划来缓解。
接下来是什么 ¶
我们的未来基准测试目标
- 探索 Ceph 9.x 的快速 EC 改进，以提高小型对象 EC 性能。
- 使用 200/400 GbE 重新运行大型对象测试，以突破当前的 NIC 天花板。
- 研究在终止 SSL 时，Ingress 服务可能的更好的默认可调参数
结论 ¶
在这一系列三篇文章中，我们展示了启用安全性的可预测的扩展性：一个 12 节点集群提供约 111 GiB/s 的 GET 和 66 GiB/s 的 PUT，从 4→8→12 节点获得近乎线性的收益，延迟更低或保持稳定，并在 64 KB 时达到高达 ~391K/86K IOPS。在 RGW 上的 TLS 性能接近基线，Messenger v2 添加的开销可以忽略不计，而 SSE-S3 显示出大小相关的、可调的成本——这些强有力的结果证明了 IBM Storage Ceph Object 具备在规模上处理高吞吐量和低延迟工作负载的准备就绪。
作者感谢 IBM 对社区的支持，为我们提供时间来创建这些帖子。