【分布式系统百科】Ceph 与 CRUSH：去中心化存储的工程实现
内容提要
Ceph通过CRUSH算法实现去中心化存储，无需元数据服务器，客户端直接计算数据位置。文章详解CRUSH映射、故障域、PG管理、强一致性、BlueStore后端及运维经验，并对比RBD、CephFS、RadosGW三种接口，强调其统一存储优势与工程实践要点。
延伸解读
CRUSH 与一致性哈希的取舍
CRUSH 算法在去中心化数据放置上比一致性哈希更进一步：它原生支持多层故障域（如机架、数据中心）和精确权重分配，而一致性哈希通常需要虚拟节点近似均匀分布，且难以表达复杂的拓扑约束。但 CRUSH 的计算复杂度为 O(N)（每层 Bucket），高于一致性哈希的 O(log N)，在超大集群中可能成为性能瓶颈。理解这一权衡有助于在缓存、负载均衡（适合一致性哈希）与持久化存储（适合 CRUSH）之间做出合理选择。
PG 数量：性能与稳定性的平衡点
PG 数量是 Ceph 集群最关键的配置之一。过少会导致数据分布不均，某些 OSD 负载过高；过多则增加内存开销和 Peering 时间。Red Hat 推荐公式（OSD 数×100/副本数）并向上取 2 的幂，但实际部署中还需考虑对象大小、访问模式等因素。Ceph Nautilus 引入的 PG Autoscaler 可自动调整，但生产环境仍建议结合监控数据手动验证，避免自动调整引发不必要的迁移。
BlueStore 为何取代 FileStore
BlueStore 绕过文件系统直接管理裸设备，消除了 FileStore 的双重写入和 POSIX 元数据开销，显著提升性能（4K 随机写 IOPS 提升约 67%），并支持校验和与内联压缩。其核心设计是将元数据存入 RocksDB，数据直接写入块设备，并通过 WAL 保证崩溃一致性。对于 SSD/NVMe，调整 bluestore_min_alloc_size 和将 WAL/DB 分离到快速设备可进一步优化。这一演进体现了分布式存储后端对底层硬件特性的深度适配。
故障域与数据安全的现实权衡
CRUSH 的故障域配置直接决定数据可靠性：副本分散在不同机架或数据中心可抵御更大范围的故障，但也会增加延迟和成本。min_size 参数在可用性和数据安全之间提供折中：min_size=2 可防止单副本丢失导致的数据永久丢失，但会降低可用性。生产环境需根据业务容忍度谨慎设置，并监控 unfound 对象——这是数据丢失的最后警告。
Q&A
Ceph 如何实现去中心化存储，避免元数据服务器瓶颈？
Ceph 通过 CRUSH 算法实现去中心化存储。客户端只需知道存储池的 PG 数量和集群拓扑信息（CRUSH Map），即可本地计算出对象存储位置，无需查询中心元数据服务器。CRUSH 算法是确定性的，任何持有相同 CRUSH Map 的节点都能独立计算出相同结果，从而消除了中心化元数据服务器的瓶颈。
CRUSH 算法相比一致性哈希有哪些优势？
CRUSH 算法相比一致性哈希的主要优势包括：1) 支持多层故障域感知，可精确控制副本在不同机架、数据中心等故障域的分布；2) 原生支持精确权重分配，按容量比例分布数据；3) 提供完全可控的副本放置规则；4) 在节点变更时实现最小数据迁移。一致性哈希虽然也支持最小迁移，但不支持拓扑感知，且权重分配需通过虚拟节点近似。
Ceph 中 PG 的作用是什么？如何确定 PG 数量？
PG（Placement Group）是对象到 OSD 的中间抽象层，用于将数十亿对象的映射问题降维为数千个 PG 的映射。PG 数量是集群关键配置，Red Hat 推荐公式为：Total PGs = (OSD 数量 × 100) / 副本数，然后向上取 2 的幂次。例如 100 个 OSD、3 副本时，PG 数约为 4096。PG 太少会导致数据分布不均，太多则增加内存和 Peering 开销。Ceph Nautilus 引入了 PG Autoscaler 可自动调整。
Ceph 如何保证强一致性？
Ceph 采用 Primary-Copy 协议保证强一致性。写入时，客户端将请求发送到 Primary OSD，Primary 分配版本号并写入本地，然后转发给所有副本，只有所有副本确认写入后，客户端才收到成功响应。读取默认只从 Primary 进行，确保读取到最新数据。此外，min_size 参数控制最小可用副本数，低于该值则停止写入，以保障数据安全。
BlueStore 相比 FileStore 有哪些改进？
BlueStore 相比 FileStore 的主要改进包括：1) 绕过文件系统直接管理裸设备，消除双重写入，降低写放大；2) 元数据存储在 RocksDB 中，避免 POSIX 文件系统元数据开销；3) 支持数据校验和，检测静默数据损坏；4) 支持内联压缩；5) 性能显著提升，如 4K 随机写 IOPS 提升约 67%，顺序写吞吐提升约 20%。
Ceph 提供哪三种存储接口？分别适用于什么场景？
Ceph 提供三种接口：RBD（块设备）、CephFS（文件系统）、RadosGW（对象存储）。RBD 适用于虚拟化、容器场景，如 OpenStack Cinder 和 Kubernetes PV；CephFS 适用于共享文件存储、HPC 等需要 POSIX 语义的场景；RadosGW 提供 S3/Swift 兼容接口，适用于备份归档、日志存储等。三者都基于 RADOS 统一存储层。
Ceph 运维中如何处理 OSD 抖动（Flapping）问题？
OSD Flapping 指 OSD 反复 down/up，常见原因包括网络不稳定、负载过高、磁盘延迟等。处理方法：1) 设置 noout 标志防止数据迁移；2) 排查根因（网络、磁盘、CPU）；3) 调整心跳超时参数，如 osd_heartbeat_grace 和 osd_heartbeat_interval；4) 问题解决后取消 noout。noout 是常用“急刹车”，为排查留出时间。
Ceph 集群容量规划时，可用容量如何计算？
Ceph 集群可用容量经验公式为：可用容量 = 原始容量 × (1 / 副本数) × 0.80。例如 100TB 原始容量、3 副本，可用容量约为 26.7TB。0.80 的安全系数预留了再平衡和碎片空间。同时应避免任何 OSD 使用率超过 85%，否则可能触发再平衡和性能下降。
