多数派决定可用性
MON 之间的状态更新需要多数成员同意才能提交，这个多数派就是法定人数。三个 MON 的集群可以容忍一个成员不可用，五个可以容忍两个；一旦剩余成员不足半数，集群就无法更新映射，新建存储池、调整配置等管理操作会全部阻塞。因此 MON 的数量应为奇数，且分散在不同的物理位置。
基本信息
| 适用平台 | 分布式存储集群的控制平面 |
|---|---|
| 常见数量 | 三个或五个，取奇数 |
| 法定人数 | 超过成员总数的一半 |
| 查看命令 | 集群状态、仲裁状态与成员列表命令 |
| 存储后端 | 成员保存集群映射，建议使用低时延介质 |
| 关键约束 | 成员间需要低时延稳定网络并保持时间同步 |
典型使用场景
- 部署规划：确定成员数量与分布位置，避免集中在一处
- 排查管理操作阻塞：确认仲裁是否完整可用
- 变更成员：按官方步骤增删成员并观察仲裁恢复情况
- 告警配置：把仲裁状态纳入监控，而不是只看读写是否正常
- 恢复演练：验证失去一名成员后集群仍能提交映射更新
数量与容错
| 成员数量 | 可容忍故障 | 适用判断 |
|---|---|---|
| 1 | 0 | 仅适用于测试环境 |
| 2 | 0 | 没有实际容错能力，不建议 |
| 3 | 1 | 常见的小规模生产配置 |
| 5 | 2 | 规模较大或分布更广 |
| 更多 | 相应提高 | 需权衡共识与同步开销 |
排查与维护
排查与维护
ceph mon stat # 成员数量与仲裁概览
ceph quorum_status # 当前参与仲裁的成员列表
ceph mon dump # 成员地址与选举轮次
ceph -s | head -n 15 # 总览中的仲裁行是否正常
systemctl status ceph-mon@$(hostname -s) # 单个成员的服务状态
journalctl -u ceph-mon@$(hostname -s) -n 50 # 该成员近期日志成员自身保存集群映射与元数据，读写频繁而数据量很小：放在低时延介质上能明显改善管理操作与选举速度，放在繁忙设备上则会拖慢整个控制平面。
成员集中分布在同一机架或同一台宿主机上，是隐蔽的可用性风险：日常运行毫无异常，直到那一处设施故障同时带走多个成员，集群立刻失去法定人数，连恢复动作都会被阻塞。
法定人数丢失时数据面未必立刻中断，但所有依赖映射更新的操作都会失败。恢复的第一原则是先让足够多的成员重新可见并形成多数派，而不是急于修改集群配置——缺少多数派时配置根本无法提交。
成员数量并非越多越好：数量增加会提高容错个数，同时也拉长共识过程并增加网络与管理开销。小规模集群三个成员即可容忍一名失效，规模较大或分布更广时用五个，再多通常不会带来可用性提升。
跨机房的两难
把成员分散到两个机房可以抵御单机房故障，但两地数量相等时，一旦链路中断，两侧都无法凑出多数派，集群会停止提交映射更新。常见做法是引入位于第三处的仲裁成员打破平局，或让某一侧多一个成员形成明确多数方；具体模式与前置条件以官方文档为准。