Ceph之所以被大量云平台和私有数据中心采用，核心原因在于它能用一套集群同时提供三种存储服务：RADOS块设备（RBD）给虚拟机当云盘，CephFS提供 POSIX 兼容的文件系统，对象网关（RGW）则兼容 S3 协议。这种统一存储架构可以显著降低运维复杂度，避免为不同业务分别维护 SAN、NAS 和对象存储。但 Ceph 对硬件和配置的要求并不低，规划不到位，上线后往往面临性能不达标或者扩容困难的问题。这篇文章结合实际部署经验，把硬件规划和关键配置讲透。
一、硬件规划：CPU、内存与磁盘的配比逻辑
硬件规划是 Ceph 部署的第一道关口，也是最容易被忽视的环节。很多人认为存储集群只要硬盘够大就行，实际上 CPU 和内存的配比直接决定了集群的性能上限。
首先是 CPU 规划。Ceph 的每个 OSD 守护进程在写入数据时都要做主存储（即数据落盘前的计算校验、压缩等操作），这部分会持续消耗 CPU 资源。经验值是每个 OSD 守护进程预留 0.5 到 1 个物理核心。如果部署的是全闪集群，且开启了压缩或者纠删码，建议按每个 OSD 一个核心来计算。举个例子，一台 12 盘位的存储节点，CPU 至少要配 8 到 12 个物理核心，选型时可以倾向主频较高的型号，因为 Ceph 的很多操作是单线程瓶颈，主频比核心数量有时更重要。
其次是内存规划。每个 OSD 守护进程本身占用并不算大，通常 2 到 4GB 就够，但操作系统页缓存才是性能的关键。Ceph 严重依赖页缓存来做读加速，内存充足时命中率高，读取延迟可以低一个数量级。一般建议每 TB 原始容量预留 1 到 2GB 内存，再叠加每个 OSD 约 4GB 的基础开销。一台 96TB 原始容量的节点，配置 128GB 内存是比较稳妥的方案。
最后是磁盘搭配。生产环境强烈建议 OSD 数据盘使用独立的设备作为 WAL 和 DB 分区（也就是俗称的分区盘或 NVMe 缓存盘）。HDD 做 OSD 时，把 RocksDB 的 WAL 和 DB 放到 NVMe 上，写入性能可以提升数倍。NVMe 盘的容量按数据盘总容量的百分之二到百分之四规划即可，例如 12 块 8TB 硬盘配一块 1.6TB 的 NVMe 做共享分区盘是比较常见的组合。另外别忘了系统盘单独配置，容量 200GB 左右，避免与数据盘混用。
二、网络设计：集群网络的分层与带宽冗余
Ceph 是一个对网络极度敏感的系统，数据副本的同步、客户端的读写流量全部走网络。网络规划不到位，再好的硬盘也发挥不出性能。
标准做法是采用双网络平面：公共网络（public network）承载客户端与集群的通信，集群网络（cluster network）专门用于 OSD 之间的副本同步和心跳。两个网络平面物理隔离，可以避免后台数据恢复流量挤占前端业务带宽。在 ceph.conf 中需要分别配置 public network 和 cluster network 两个网段，交换机也要分开。
带宽方面，万兆是起步配置，全闪集群建议上 25GbE 甚至 100GbE。一个简单的估算方法：单块 HDD 的顺序写入约 200MB/s，换算成网络流量约 1.6Gbps，一台 12 盘位的节点满载写入就需要接近 20Gbps 带宽，万兆口明显不够。因此 HDD 节点至少配两个万兆口做绑定，全闪节点建议直接上 25G 以上。交换机要单独为存储网络准备，避免与业务网络共用导致拥塞。另外，跨机房的 stretched 集群场景下，两个机房之间的专线延迟要控制在 10ms 以内，否则性能会严重劣化。
三、集群部署：Monitors、Managers 与 OSD 的配置要点
p>硬件到位后，进入软件部署阶段。以目前主流的 Ceph Reef 版本为例，推荐使用 cephadm 配合容器方式部署，管理起来比手工部署省心很多。Monitor 节点建议部署 3 个或者 5 个，数量必须是奇数，用于仲裁。Monitor 对磁盘延迟敏感，最好用 SSD 做系统盘，并且不要和 OSD 节点混布（小规模集群可以接受）。Manager 与 Monitor 同节点部署即可。OSD 部署时要注意，如果使用 HDD 加 NVMe 分区盘的方案，需要用 LVM 卷把 NVMe 划分成多个 WAL/DB 分区，再通过 ceph-volume 以 db-devices 参数关联到各个 OSD。
副本策略是配置阶段的核心决策。三副本是最经典的高可用方案，可用容量是总容量的三分之一，可靠性极高。如果容量成本压力大，纠删码（EC）是更经济的选择，比如 4 2 的 EC 配置，可用容量达到总容量的三分之二，但代价是随机写入性能下降和恢复时间变长。常见的做法是热数据池用三副本，冷数据池用纠删码，按业务分层。同时要设置好 size 和 min_size 参数，min_size 建议设为 size 减一，例如三副本时 min_size 设为 2，保证单副本故障时集群仍能写入。
四、参数调优与上线前的验证
默认配置的 Ceph 只能发挥六七成的性能，上线前做一轮调优很有必要。几个关键点：开启 ms_async 模式提升网络线程效率；调整 osd_op_threads 和 osd_disk_threads，让 OSD 并发处理更多请求；如果前端是 RBD 虚拟盘场景，开启 RBD 缓存并设置合理的回收阈值。文件系统层面，BlueStore 已经是默认选项，它直接管理裸设备，绕过了内核页缓存的double copy 问题，性能比旧的 FileStore 好很多，不要再用 FileStore 建新集群。
调优完成后，务必做一轮验证测试：用 fio 对 RBD 卷做顺序和随机的读写压测，观察 IOPS 和延迟是否达标；用 rados bench 测试对象存储的吞吐；模拟拔盘场景，观察数据恢复速度和集群状态变化。恢复期间要关注 degraded 对象数量和恢复流量，必要时通过 osd_recovery_max_active 参数限速，避免恢复流量打满网络影响业务。
最后提醒一点：Ceph 集群上线后不是一劳永逸的。要建立常态化的监控，重点盯 OSD 的延迟、磁盘 SMART 状态、集群容量水位。容量使用率超过百分之七十五就要规划扩容，超过百分之八十五就必须马上行动，因为满载集群在扩容和恢复时风险会成倍增加。硬件留好扩展槽位，后续扩容时保持各节点配置一致，CRUSH 会自动完成数据均衡，整个集群才能长期稳定运行。