-
Ceph 对象网关性能深入探讨：构建安全且可扩展的对象存储（上）
引言 性能为何对安全对象存储至关重要 当今企业不仅面临管理海量数据（通常达数十 PB 级别）管理的挑战，更肩负着在混合云与多云环境中保障数据安全的责任。对象存储系统（尤其是 Ceph）通过提供 S3 兼容访问、原生冗余机制及日益丰富的企业级功能，为应对这些挑战提供了所需的可扩展性与灵活性。 随着传输加密与静态加密技术被逐层应用于 Ceph 对象网关（RGW）部署，准确评估其对延迟、吞吐量及资源利用率的影响变得至关重要。
本系列文章给大家展示了一次全面性能基准测试的研究成果。文章评估聚焦于真实场景工作负载如何与不同加密配置、数据保护方案及横向扩展模式的交互作用，为架构人员，运维人员以及开发人员提供具有实际生产意义的参考价值。
01 硬件和软件设置 我们在生产级 Ceph 集群上进行了测试，该集群采用 RGW（对象网关）、OSD（对象存储守护进程）、Monitor（监视器）、Manager（管理器）及 Ingress（入口）服务的部署架构。 硬件规格
服务器 角色 数量 CPU RAM 磁盘 Dell R760 Monitor, Manager, OSD, RGW, Ingress 12 2× Intel Xeon Gold 6438N (64 threads) 512 GB 24 × 3.84 TB NVMe Dell R660 Benchmarking Clients, Monitoring 13 2× Intel Xeon Gold 5418Y (48 threads) 384 GB 每种测试集群配置（4 节点、8 节点及 12 节点）均保持统一的 OSD 分布数量（每节点 24 个 OSD）与每节点 4 个 RGW 守护进程的部署标准，并通过专设虚拟 IP 实现基于 Ingress 的负载均衡。
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 每个存储桶分片的对象计数 软件版本
名称 版本/备注 Ceph 19.2.0-52 Elbencho 3.0-26 (benchmarking tool) HashiCorp Vault 1.19.1 (for SSE key management) Prometheus + Grafana Monitoring stack RHEL Ceph 集群配置
Ceph Cluster Config Value Scrubs/Deep-scrubs Disabled Ceph Balancer Disabled Progress Module Disabled PG Autoscaler Disabled OSDMAP_FLAGS Muted Dynamic Bucket Re-sharding PG 计数
集群大小 OSD 计数 每个 OSD 的目标 PG 副本 池类型 PG 计数（索引/数据池） 4 Node 96 400 EC 2+2 / Replicated 512 / 8192 8 Node 192 400 EC 2+2 1024 / 32768 8 Node 192 400 EC 4+2 1024 / 16384 8 Node 192 400 EC 8+3 1024 / 8192 12 Node 288 400 EC 2+2 1024 / 32768 12 Node 288 400 EC 4+2 1024 / 16384 12 Node 288 400 EC 8+3 网络架构和连接
为匹配计算/存储配置，我们的网络架构为集群高吞吐性能提供底层支撑：
- Leaf–Spine 拓扑：我们采用 100 GE Leaf–Spine 网络架构，配备一台 Spine 交换机（QFX5120）和三台 Leaf 交换机（QFX5120），构建可扩展的低延迟设计。该架构既满足当前端口密度需求，又支持未来升级（例如添加标准 Spine 交换机并重用现有设备），且全程不影响性能。
- 双 100 Gbps 服务器上行链路通过 LACP 聚合：每个 Ceph 节点利用单网卡上的两个 100 GE 端口，通过 LACP 绑定连接到两台 Leaf 交换机，实现冗余与链路聚合
- 单节点限制：尽管采用双端口 LACP 绑定，但每个 Ceph 存储节点搭载的英特尔网卡最大聚合吞吐量为 100 Gbps，这意味着单节点在理想条件下的吞吐量上限约为 12.5 GB/s。
- 集群交换容量：我们的 Leaf–Spine 拓扑由一台 QFX5120 Spine 交换机和三台 QFX5120 Leaf 交换机构建，为所有 12 个存储节点提供全线速连接。每台 Leaf 交换机连接四个节点，并以 100 Gbps 上行链路对接 Spine 交换机，使集群理论交换总容量达到约 150 GB/s。在大对象基准测试中，系统实际达成约 111 GB/s 聚合吞吐量，这表明已接近物理网络极限——尤其是在大对象读取密集型工作负载场景下。
02 测试方法 我们设计性能评估方案旨在解答以下关于 Ceph 对象网关（RGW）性能与安全部署的核心问题： - TLS（SSL）对 RGW 吞吐量和延迟有何影响？
- 服务器端加密（SSE-S3/KMS）会引入多少开销？
- 守护进程间安全通信（msgr v2）是否影响 CPU 利用率？
- 纠删码配置（2+2、4+2、8+3）与 3 副本复制模式的性能对比如何？
- 基于 HAProxy 的 Ingress 服务与直接访问的性能差异？
- 节点数量和并发量对性能的扩展性影响？
每个测试案例均针对 PUT 和 GET 工作负载，在 64 KiB 至 1 GiB 的对象尺寸范围内进行多轮测试。使用 Elbencho 客户端-服务器模式，线程数设置为 128（SSE 测试采用 64 线程），最多运行 8 个并发客户端。每个 Elbencho 客户端使用独立存储桶，存储桶预先创建并采用默认分片配置（每个存储桶 11 个分片）。大于 1 GiB 的对象启用分段上传功能。
有效负载大小 工作负载类别 例如 ≤ 64KB 小对象 缩略图、指标和小型元数据文件 1MB 中等对象 文档、电子邮件、附件 ≥ 32MB 大对象 03 结果摘要 Ceph 部署在 100 GE 网络的顶级全闪存基础架构上时表现出卓越的性能和灵活性。随着企业数据规模扩展至数十亿对象和 PB 级，Ceph 处理多样化数据模式的能力至关重要——无论是高 IOPS 低延迟的元数据密集型工作任务，还是高吞吐的带宽密集型场景，都能从容应对。 大型对象工作负载（吞吐量优先）
对于超过 32 MiB 的对象，集群实现了近乎线性的扩展，最多可扩展到 12 个存储节点，峰值为 65 GiB/s 的聚合 PUT 吞吐量和 ~115 GiB/s 的聚合 GET 吞吐量。除此之外，单个节点上的 100 GE 网卡饱和度成为主要瓶颈。这表明未来的基准测试将受益于更高带宽的网卡，因为大型对象工作负载仍有空间从当前节点的可用资源中实现更高的吞吐量结果。请注意，在使用多个端口时，NIC 的标称端口速度与其可以处理的带宽之和之间的区别，因为在多端口 NIC 上，后者可能小于前者。
对于大型对象，完全传输中的安全配置（TLS + msgr v2）以合理的开销保持高吞吐量，这表明 Ceph 对象网关 （RGW） 非常适合大规模的安全数据管道。启用服务器端加密 （SSE） 以提供静态对象加密时，还有性能改进的空间。
小型对象工作负载（IOPS 和延迟优先）
小型对象测试 （64 KiB） 展示了 Ceph 对象网关 （RGW） 能够通过增加并发性和集群大小来有效地扩展 IOPS。对于 64 KiB 对象，该系统使用纠删码在 12 个节点集群上实现了高达 391K GET IOPS 和 86K PUT IOPS。
为达到小对象工作负载的最佳性能（尤其在髙并发场景），必须部署在具有强大CPU容量和充足RGW线程的基础设施上，使Ceph对象网关能充分发挥其并行处理能力。
04 下一步 本文介绍了测试环境、方法论及核心结果。在本系列后续文章中，我们将深入每个性能维度：探究 TLS 和 SSE 对 RGW 吞吐量的影响、纠删码与复制的扩展特性、并发度与守护进程密度对延迟的作用机制等。我们将看到直接源自生产级测试的详细结果。从而不管用户是为 AI 流水线、备份系统还是多租户云服务构建安全对象存储，提供更多的参考。 如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。
云和安全管理服务专家
