基准测试 Ceph 对象网关：深入了解安全、可扩展的对象存储性能。第一部分
引言：为什么性能对于安全对象存储至关重要 ¶
当今，组织不仅面临管理海量数据的挑战（通常达到数十 PB），还承担着在混合和多云环境中保护这些数据的责任。对象存储系统（尤其是 Ceph）提供了满足这些挑战所需的扩展性和灵活性，提供与 S3 兼容的访问、本机冗余以及不断增长的企业级功能。
随着 Ceph 对象网关 (RGW) 部署中配置和分层加密传输和静态加密，了解其对延迟、吞吐量和资源利用率的影响至关重要。
本博客系列展示了 IBM Storage Ceph 性能和互操作性团队进行的一项全面的性能基准测试结果。特别感谢 Jay Rajput 领导测试用例的执行和数据收集。我们的评估侧重于实际工作负载与不同加密、数据保护和水平扩展配置的交互方式，为架构师、管理员和开发人员提供实用的见解。
硬件和软件设置 ¶
我们使用配备了共置 RGW、OSD、Monitor、Manager 和 Ingress 服务的生产级 Ceph 集群进行了测试。
硬件规格 ¶
| 组件 | 角色 | 数量 | CPU | 内存 | 存储 |
|---|---|---|---|---|---|
| Dell R760 | Monitor、Manager、OSD、RGW、Ingress | 12 | 2× Intel Xeon Gold 6438N (64 线程) | 512 GB | 24 × 3.84 TB NVMe |
| Dell R660 | 基准测试客户端、监控 | 13 | 2× Intel Xeon Gold 5418Y (48 线程) | 384 GB | 2 × 3.84 TB NVMe |
每个测试集群配置（4 节点、8 节点和 12 节点）都保持一致的 OSD 密度（每个节点 24 个）和每个节点 4 个 RGW 守护进程，并为基于 Ingress 的负载均衡配置了专用的 VIP。
| Ceph 集群设置 | 详细信息 |
|---|---|
| 集群大小 | 4 节点、8 节点、12 节点 |
| 总 OSD 数量 | 96, 192, 288 |
| OSD | 每个节点 24 个 |
| RGW | 每个节点 4 个 |
| Ingress | 每个节点 1 个 VIP |
| RGW 数据池 | 副本 3，EC 2+2，4+2，8+3 |
| 每个 OSD 的 PG 副本数 | ~400 |
| 共置 Ceph 守护进程 | Monitor、Manager、OSD、RGW、Ingress |
| 每个 bucket shard 的对象数 | 默认值：100K |
软件版本矩阵 ¶
| 组件 | 版本/备注 |
|---|---|
| Ceph | 19.2.0-52 |
| Elbencho | 3.0-26 (基准测试工具) |
| HashiCorp Vault | 1.19.1 (用于 SSE 密钥管理) |
| Prometheus + Grafana | 监控堆栈 |
| RHEL | 9.5，BIOS 配置文件设置为“性能” |
Ceph 集群配置 ¶
| Ceph 集群配置 | 值 |
|---|---|
| Scrub/Deep-scrub | 禁用 |
| Ceph Balancer | 禁用 |
| 进度模块 | 禁用 |
| PG 自动缩放器 | 禁用 |
| OSDMAP_FLAGS | 静音 |
| 动态 Bucket 重分片 | 禁用 |
PG 计数 ¶
| 集群大小 | OSD 计数 | 目标 PG 副本/OSD | 池类型 | PG 计数（索引/数据池） |
|---|---|---|---|---|
| 4 节点 | 96 | 400 | EC 2+2 / 复制 | 512 / 8192 |
| 8 节点 | 192 | 400 | EC 2+2 | 1024 / 32768 |
| 8 节点 | 192 | 400 | EC 4+2 | 1024 / 16384 |
| 8 节点 | 192 | 400 | EC 8+3 | 1024 / 8192 |
| 12 节点 | 288 | 400 | EC 2+2 | 1024 / 32768 |
| 12 节点 | 288 | 400 | EC 4+2 | 1024 / 16384 |
| 12 节点 | 288 | 400 | EC 8+3 | 1024 / 8192 |
网络架构和硬件连接 ¶
为了补充计算/存储设置，我们的网络支撑着集群的高吞吐量性能
叶脊拓扑：我们正在运行一个 100 GE 叶脊网络，一个脊 (QFX5120) 和三个叶交换机 (QFX5120)，实现可扩展、低延迟的设计。这提供了现在的端口密度和一个未来的升级路径（例如，添加一个真正的脊并重新利用当前的脊），而不会影响性能。
每个服务器双 100 Gbps 上行链路通过 LACP：每个 Ceph 节点使用单个 NIC 上的两个 100 GE 端口，通过 LACP 连接到两个叶交换机，以实现冗余和链路聚合。
每节点限制：每个 Ceph 存储节点配备了 Intel NIC，支持最大聚合吞吐量为 100 Gbps，即使有两个端口可用并通过 LACP 绑定。这意味着每节点吞吐量在最佳条件下限制为 ~12.5 GB/s。
集群范围内的交换容量：我们基于一个 QFX5120 脊和三个 QFX5120 叶交换机的叶脊拓扑，为所有十二个存储节点提供全线速连接。每个叶连接到四个节点并以 100 Gbps 的速度上行到脊。这导致总集群理论交换容量约为 ~150 GB/s。在我们的大型对象基准测试中，系统实现了 ~115 GB/s 的聚合吞吐量，表明我们正在达到物理网络上限，特别是对于大型对象读取密集型工作负载。
测试方法
我们设计了性能评估，以回答有关如何部署 Ceph 对象网关 (RGW) 以实现性能和安全性的基本问题
TLS (SSL) 对 RGW 吞吐量和延迟有什么影响？
服务器端加密 (SSE-S3/KMS) 会引入多少开销？
保护内部守护进程通信 (msgr v2) 是否会影响 CPU 利用率？
EC 配置文件 (2+2、4+2、8+3) 与 3 倍复制相比如何？
使用基于 HAProxy 的 Ingress 与直接访问的性能影响是什么？
性能如何随着节点数量和并发性扩展？
每个测试用例都在 PUT 和 GET 工作负载上重复进行，对象大小各不相同，范围从 64 KB 到 1 GiB。Elbencho 以客户端-服务器模式使用，线程数为 128（SSE 测试除外，使用 64 个线程），运行多达八个并发客户端。每个 Elbencho 客户端使用一个单独的 bucket。Bucket 预先创建，使用默认的分片计数，即每个 bucket 十一个 shard。对于大于 1 GiB 的对象，使用多部分上传。
| 有效载荷大小 | 工作负载类别 | 代表 |
|---|---|---|
| ≤ 64KB | 小对象 | 缩略图、遥测数据和小元数据文件 |
| 1MB | 中型对象 | 文档、电子邮件、附件 |
| ≥ 32MB | 大型对象 | 备份、高清媒体、机器学习数据集 |
执行摘要 ¶
IBM Storage Ceph 在最先进的、全闪存基础设施和 100 GE 网络上部署时，表现出卓越的性能和灵活性，例如 IBM Storage Ceph Ready Nodes。 随着企业扩展到数十亿个对象和多 PB 工作负载，Ceph 处理各种数据模式的能力（从高 IOPS、低延迟、元数据密集型工作负载到高吞吐量、带宽密集型工作负载）变得至关重要。
大型对象工作负载（吞吐量重点） ¶
对于超过 32 MiB 的对象，集群在最多十二个存储节点上实现了近乎线性的扩展，峰值聚合 PUT 吞吐量为 65 GiB/s，聚合 GET 吞吐量约为 ~115 GiB/s。超过这些点，单个节点的 100 GE NIC 饱和成为主要瓶颈。这表明未来的基准测试将受益于更高带宽的 NIC，因为大型对象工作负载仍然有空间从当前节点的可用资源中实现更高的吞吐量结果。请注意，NIC 的标称端口速度之和与多个端口在使用时可以处理的带宽之间的区别，因为后者可能小于前者。
对于大型对象，完全传输加密的配置（TLS + msgr v2）在保持高吞吐量的同时保持合理的开销，表明 Ceph 对象网关 (RGW) 适用于大规模的安全数据管道。
小型对象工作负载（IOPS 和延迟重点） ¶
小型对象测试 (6i4 KB) 证明了 Ceph 对象网关 (RGW) 在增加并发性和集群大小时高效扩展 IOPS 的能力。使用 64 KiB 对象，该系统在十二节点集群上使用擦除编码实现了高达 391K GET IOPS 和 86K PUT IOPS。
为了释放小型对象工作负载的最佳性能，尤其是在高并发性下，必须在配备强大 CPU 容量和充足 RGW 线程的 инфраструктуре 上部署，从而使 Ceph 对象网关能够充分利用其并行处理能力。
接下来会发生什么 ¶
本文介绍了测试平台、方法和关键结果。在接下来的系列文章中，我们将深入探讨每个性能轴，探索 TLS 和 SSE 对 RGW 吞吐量的影响、使用擦除编码与复制的扩展行为、并发性和守护进程密度如何影响延迟等等。您将看到从生产级测试中得出的详细图表和架构指导。无论您是为 AI 管道、备份或多租户云服务构建安全对象存储，请继续关注，还有更多内容值得探索。
阅读第二部分 此处。
作者感谢 IBM 对社区的支持，为我们提供时间来创建这些帖子。