【Ceph RADOS】MON/MGR 与 Map：quorum、epoch 传播与客户端可见性
内容提要
本文介绍Ceph RADOS中MON/MGR与Map机制：MON用Paxos变体维护OSDMap等强一致状态，epoch递增触发增量传播；MGR聚合PGMap提供弱一致统计；客户端通过Objecter缓存map并透明追赶，epoch变化影响peering与可见性窗口，中心化架构在超大规模下存在瓶颈。
延伸解读
quorum 丢失的误诊风险
当超过半数 MON 不可用时，集群无法提交新的 OSDMap epoch。此时客户端可能仍持有旧 map，对“看似存活”的 OSD 进行短暂读写，但任何需要新 epoch 的操作（如 OSD 真正 down、Pool 变更）都会卡住。这种状态常被误诊为存储层故障，实则是管理面权威停摆。理解这一点有助于快速定位问题，避免在 MON 故障时错误地重启 OSD 或客户端。
epoch 变化不等于数据重写
OSDMap epoch 递增可能仅因无关 OSD 状态变化，当前 PG 的 acting set 未变时，客户端无需重发请求。Objecter 只在路由结果变化时重路由 pending Op。因此，将“epoch 变了”等同于“需要重做所有 I/O”会误导限流与重试策略。运维时应关注 acting set 是否变化，而非单纯 epoch 数值。
MGR 故障不影响数据面
MGR 主备切换在秒级完成，数据读写路径不依赖 MGR。MGR 宕机期间仅影响 Dashboard、Prometheus 等监控面，I/O 可继续。但需注意，PGMap 由 MGR 聚合，是最终一致数据，与 OSDMap 的强一致语义不同。监控工具可能展示短暂不一致状态，这是正常现象，不应误判为数据面异常。
epoch 速率与 peering 的耦合
过快的 map 变更会放大 past intervals 集合，拉长 peering 时间，并增加客户端追赶次数。运维上可通过 NOSCRUB、NOREBALANCE 等 flags 降低无关 epoch 噪声，缩小可见性窗口。同时，开启 balancer 的 upmap 模式会提高 epoch 速率，需与 flags 统一考虑，避免无谓的 map 抖动。
Q&A
Ceph MON 使用什么一致性协议来维护 OSDMap 等状态？
Ceph MON 使用自研的 Paxos 变体（而非 Raft 或教科书 Multi-Paxos）来维护 OSDMap 等强一致状态。该变体通过 Leader 发起提案、Peon 转发写请求，并采用两阶段提交（Collect → 多数 Accept → Commit）以及读租约（MMonLease）机制。
Ceph 中 OSDMap 的 epoch 是什么？它如何递增和传播？
OSDMap 的 epoch 是单调递增的版本号，每次 OSD 状态变更（如 OSD down/up、pool 修改、CRUSH 规则变更）都会递增。MON Leader 生成增量（OSDMap::Incremental）并通过 MOSDMap 消息推送给订阅的 OSD 和客户端，客户端和 OSD 优先拉取增量，避免全量传输。
Ceph 中 PGMap 和 OSDMap 有什么区别？
OSDMap 由 MON 维护，是强一致的数据面权威描述，记录 OSD 状态、权重、pool 等信息，epoch 单调递增。PGMap 由 MGR 聚合各 OSD 上报的 pg_stat_t 生成，是最终一致的统计信息，记录 PG 状态、对象数等，但不包含 PG log。两者 epoch 语义不同，ceph status 显示的 PG 统计来自 MGR 而非 MON。
Ceph MGR 的作用是什么？它宕机时会影响数据读写吗？
MGR 是 Luminous 引入的管理守护进程，负责监控聚合和插件逻辑（如 Dashboard、Prometheus、balancer 等），采用主备模式，Active 宕机时 Standby 秒级切换。MGR 不参与数据读写路径，因此宕机时仅影响监控命令和模块功能，不影响 I/O。
客户端如何感知 OSDMap 的更新？
客户端通过 librados 的 Objecter 缓存 OSDMap，并在发送 MOSDOp 时携带当前 epoch。若 OSD 发现客户端 map 偏旧，会在回复中附带更新的 MOSDMap，Objecter 合并后按新 acting set 重算目标并重发；若客户端偏新，请求可能被推迟等待 OSD 追上。整个过程对应用透明，表现为延迟毛刺。
Ceph 中 epoch 变化过快会带来哪些问题？
epoch 变化过快会放大 past intervals 集合，拉长 peering 时间，增加客户端追赶次数，并可能提高 MON CPU 负载。运维上可通过设置 NOSCRUB、NOREBALANCE 等 flags 减少无关 epoch 噪声，缩小可见性窗口。
Ceph MON 使用 Paxos 与 Dynamo 的 gossip 相比有什么优缺点？
Ceph 选择中心化 map 服务（Paxos）提供全局有序的 epoch，使 peering 和 recovery 的正确性更容易推理，但 MON 成为单一 quorum 依赖点，超大规模下可能成为瓶颈。Dynamo 采用去中心化 gossip，无单点瓶颈，可线性扩展，但最终一致性，epoch 风格协议难以直接移植。
Ceph 中客户端可见性窗口是什么？它如何影响读写？
客户端可见性窗口指持有旧 epoch 的客户端在 MON 已发布新 epoch 后，仍可能向旧目标发送 Op 的时间段。这由 osd_op_timeout 和 Messenger keepalive 决定，换取不必每 I/O 询问 MON 的性能。故障刚发生时，监控上可能先显示更糟再恢复，这是异步差导致的，而非存储变慢。
