Ceph企业级分布式存储实战课

分布式存储这件事，很多人是在面试里第一次认真面对。面试官问 PG 和 CRUSH 的关系，你答得出大概；再问一句"三副本池的 PG 数怎么定、定错了会怎样"，就开始含糊。真正上过生产集群的人，问题会更具体：OSD 掉了一个，数据重平衡要跑多久，期间业务会不会抖；换盘和换节点是两种操作，顺序错了会踩坑。这门课面向的就是这类缺口——不是没听过 Ceph，而是没把 Ceph 当作一个要长期维护的系统来对待。

先确认自己缺的是哪一块

如果你只是会用对象存储的 S3 接口读写文件，那缺的是底层那一层：RADOS、CRUSH 算法、Monitor 与 Manager 的职责边界。如果你已经在机房里搭过测试集群，能跑通但不敢上线，缺的是容量规划与故障域设计——副本数、PG 数、节点分布这几项一旦定下来，后面迁移数据的代价很高。如果你正在做 Kubernetes 的持久化方案，缺的是 RBD、CephFS、RGW 三种接口各自的适用场景和性能特征，选错了接口，后面调优会很别扭。

课程按系统规划、硬件选型、集群搭建、数据管理、性能优化、故障排除这条线展开，同时覆盖与 Kubernetes 的集成。建议对照上面三类缺口挑重点看，不必从头顺着走。

规划阶段比搭建阶段更值得慢下来

搭建本身是体力活，命令敲对就能出集群，出问题也有日志可查。规划则不同：集群规模、节点数量、每节点磁盘数与类型、网络带宽、副本策略，这些决定的是集群未来一两年的上限。课程在这个环节讲了硬件选择的取舍，包括 SSD 与 HDD 混布时的角色划分、日志盘该怎么放。看这部分时不妨带着自己的机房条件去算：现有几台机器、几张盘、多少可用容量、预期 IOPS 有多少，算完再决定要不要照着示例集群的结构做。

运维阶段要盯的是状态，不是命令

集群跑起来之后，日常动作主要是观察和判断：集群健康状态处在什么档位，哪些 PG 处于降级或回填状态，重平衡有没有挤占业务流量。课程涉及的数据管理、备份恢复和故障排除都建立在这个基础上。学的时候可以把注意力放在"看到什么现象，对应什么原因，先做哪一步"这条判断链上，而不是记住某条命令的参数。带 CRUSH 映射的存储系统，大多数事故不是命令敲错，而是对失衡原因判断错了方向。

看完应该能回答的问题

• 给定节点数和磁盘规格，如何估算可用容量与副本开销，并据此确定 PG 数量？
• 集群扩容、更换故障盘、下线节点，三种操作的执行顺序和各自的风险点是什么？
• 业务反馈写入延迟升高，你会依次查看哪些指标来区分是 OSD、网络还是 PG 分布的问题？
• 同一批业务，选 RBD 还是 CephFS，判断依据是什么？
• 和 Kubernetes 对接时，持久卷的动态供给依赖集群哪些组件，常见失败原因有哪些？

这几个问题答不上来，说明还没到能独立维护 Ceph 集群的程度。带着它们去看课，比从头到尾刷一遍更有效率。分布式存储的坑大多在细节里，缺哪补哪，别指望看一遍就什么都会。