《Ceph集群数据同步异常的根因突破与恢复实践》
分布式存储是支撑业务数据流转的核心底座，其稳定性直接决定了整个系统的抗风险能力。某政务云平台采用Ceph作为统一存储解决方案，为电子政务、民生服务等核心系统提供块存储与对象存储服务，却在一次常规集群扩容后遭遇了严重的数据同步异常——部分存储池的PG（Placement Group）状态持续处于“degraded”，数据副本同步停滞，触发了平台最高级别的灾备预警。这起故障并非简单的硬件或配置问题，而是Ceph底层CRUSH算法、OSD（Object Storage Daemon）调度机制与云原生环境弹性特征碰撞产生的复杂问题，其排查与恢复过程，为理解分布式存储在云原生场景下的运维难点提供了关键参考。
该政务云平台的Ceph集群采用“3主3从”的混合部署架构，包含6个存储节点（每个节点配置24核CPU、128GB内存、10块10TB SATA硬盘），运行Ceph Quincy版本，部署模式为容器化（基于Kubernetes的StatefulSet管理OSD与MON组件），存储池采用“3副本+EC（Erasure Code）”混合策略—核心业务数据使用3副本确保低延迟，非核心归档数据使用EC模式节省空间。集群总容量1.2PB，承载着200余个政务应用的数据存储需求，其中电子证照、社保缴费等系统要求数据RTO（恢复时间目标）不超过15分钟，RPO（恢复点目标）接近0。故障发生于运维团队为扩容存储容量，新增2个存储节点并加入集群之后，初期仅表现为新节点的OSD上线缓慢，2小时后多个核心存储池出现PG状态异常。值得注意的是，此次扩容正值月末政务业务高峰期，电子证照系统需处理大量企业资质审核文件存储请求，社保缴费系统也面临市民医保参保登记的数据写入压力，这为故障的恶化埋下了业务层面的隐患。
故障初期的现象呈现出“渐进式恶化”特征。通过Ceph Dashboard监控发现，新增节点的8个OSD中，有5个始终处于“up但inactive”状态，无法参与数据均衡；同时，“user-data”“gov-cert”两个核心存储池的PG健康状态从“active+clean”变为“active+degraded”， degraded PG数量从0逐渐增至42个，占总PG数的18%。查看Ceph日志发现，OSD之间的心跳检测正常，但数据副本同步时频繁出现“p