一、核心定位
| 组件集群 | 核心定位 | 核心职责 | 一句话类比 |
|---|---|---|---|
| Monitor 集群（MON） | 集群状态管理者 | 维护元数据、认证授权、决策集群拓扑 | 数据中心的 监控调度室 |
| OSD 集群（OSD） | 数据存储执行者 | 数据写入 / 读取、副本同步、故障恢复 | 数据中心的 存储服务器阵列 |
二、Monitor 集群（MON）—— 集群的 “大脑”
1. 核心作用
Monitor 集群是 Ceph 的集中式状态管理中心，不存储用户数据，只负责维护集群的核心元数据：
-
维护 Cluster Map：这是 Ceph 集群的 “全局地图”，包含 OSD 状态、Pool 配置、PG 映射关系、CRUSH 规则等关键信息，所有组件都通过 Cluster Map 感知集群拓扑。
-
集群认证与授权：验证客户端、OSD、MDS 等组件的身份（通过密钥环），控制谁能访问集群、能操作哪些 Pool。
-
仲裁集群状态：通过 Paxos 算法 实现 MON 节点间的状态一致性，确保集群决策（如 OSD 上下线、PG 迁移）的唯一性。
-
集群特点
- 高可用部署：为了保证“大脑”不宕机，生产环境必须部署奇数个 MON 节点（通常是 3 个或 5 个）。
- 仲裁机制：Ceph 依赖“大多数”原则（Quorum）。例如，一个 3 节点的 MON 集群，只要有 2 个节点存活，集群就能正常工作；即使坏掉 1 个，剩下的 2 个也能形成仲裁，继续提供服务。
2. 部署要求
-
数量要求：必须部署 奇数个节点（3/5 个），目的是避免脑裂，确保 Paxos 算法能选出唯一的主节点。
- 3 个 MON 节点：最多容忍 1 个节点故障，集群仍能正常工作。
- 5 个 MON 节点：最多容忍 2 个节点故障，适合超大规模集群。
-
硬件要求：对 CPU / 内存要求不高，但需要 低延迟、高可靠的网络（因为要同步 Cluster Map），推荐用 SSD 存放 MON 的数据目录（提升元数据读写速度）。
3. 工作机制
- MON 集群通过 Paxos 算法选举出一个 Leader 节点，负责处理集群的写请求（如更新 OSD 状态）。
- 其他 MON 节点作为 Follower，同步 Leader 的状态，确保集群元数据一致。
- 当 Leader 故障时，剩余 MON 节点会重新选举新 Leader，整个过程自动完成，无需人工干预。
4. 常用运维命令
# 查看 MON 集群状态
ceph mon stat# 查看 Cluster Map
ceph osd tree# 添加一个 MON 节点
ceph mon add <mon-name> <ip>:<port>
三、OSD 集群（OSD）—— 集群的 “驱干”
1. 核心作用
OSD（Object Storage Daemon）是 Ceph 的数据存储核心，每个 OSD 对应一块物理磁盘，用户数据最终都落地在 OSD 的磁盘上。核心职责包括：
- 数据读写：接收客户端或其他 OSD 的请求，完成 Object 的写入、读取操作。
- 副本同步：根据 Pool 的副本策略（如 3 副本），自动将数据同步到其他 OSD 节点，确保数据冗余。
- 故障检测与恢复：通过 心跳机制 监控其他 OSD 的状态；当某个 OSD 故障时，自动触发 PG 数据重建，将故障 OSD 上的数据迁移到健康 OSD 上。
- PG 管理：每个 OSD 会负责多个 PG 的存储，按 CRUSH 算法的映射关系管理 PG 的主副本角色。
集群特点
- 大规模扩展：一个 Ceph 集群可以包含成百上千个 OSD，通过增加 OSD 数量可以线性地扩展集群的存储容量和 I/O 性能。
- 智能分布：数据在 OSD 间的分布不是随机的，而是由 CRUSH 算法智能计算得出，确保数据在不同主机、机架甚至数据中心之间均匀分布，避免单点故障。
2. 部署要求
- 数量要求：至少 3 个 OSD（满足 3 副本的最低要求）
- 硬件要求：
- 磁盘：推荐用 SSD/NVMe 提升 IO 性能，每块磁盘对应一个 OSD（避免单盘故障影响多个 OSD）。
- CPU / 内存：需要一定的计算资源（用于数据校验、副本同步），大规模集群建议每个 OSD 分配 1-2 CPU 核心、2-4GB 内存。
- 网络：高带宽、低延迟的网络（万兆网起步），因为 OSD 间需要频繁同步数据。
3. 工作机制（以数据写入为例）
- 客户端向 MON 集群请求 最新的 Cluster Map，获取目标 Pool 的 PG 分布信息。
- 客户端根据 CRUSH 算法，计算出数据对应的 PG 以及该 PG 对应的 主 OSD 和副本 OSD。
- 客户端直接将数据写入 主 OSD，主 OSD 完成数据写入后，再将数据同步到 副本 OSD。
- 所有 OSD 写入完成后，主 OSD 向客户端返回写入成功的响应。
4. 常用运维命令
# 查看 OSD 集群状态
ceph osd stat# 查看 OSD 详细信息（包括负载、状态）
ceph osd dump# 标记一个 OSD 为下线状态
ceph osd down <osd-id># 删除一个故障 OSD
ceph osd rm <osd-id>
四、Monitor 集群与 OSD 集群的协作流程
以 OSD 节点上线 为例，看二者如何配合：
- 新 OSD 节点启动后，向 MON 集群发送 注册请求，携带自身的 ID、磁盘信息、密钥。
- MON 集群验证 OSD 身份后，更新 Cluster Map，将新 OSD 加入集群拓扑。
- MON 集群通过 心跳广播，将更新后的 Cluster Map 同步给所有 OSD 和客户端。
- CRUSH 算法根据新的 Cluster Map，重新计算 PG 的映射关系，触发部分 PG 从旧 OSD 迁移到新 OSD，实现数据均衡。
五、核心区别与协作总结
| 对比维度 | Monitor 集群 | OSD 集群 |
|---|---|---|
| 核心功能 | 管理集群状态、元数据、认证 | 存储用户数据、副本同步、故障恢复 |
| 数据类型 | 只存元数据（Cluster Map） | 只存用户数据（Object） |
| 部署数量 | 奇数个（3/5） | 越多越好（至少 3 个） |
| 硬件要求 | 低 CPU / 内存，高可靠网络 | 高 IO 磁盘，高带宽网络 |
| 容错能力 | 3 节点容忍 1 个故障 | 3 副本容忍 1 个 OSD 故障 |
MON 集群的容灾是 仲裁层面，依赖节点数量的奇偶性。不能超过半数节点挂掉
OSD 集群的容灾是 数据层面，依赖副本数 / 纠删码（比如 3 副本 OSD 集群，单盘故障不丢数据）
为什么monitor集群必须部署奇数个
Ceph Monitor 集群必须部署奇数个节点，核心原因是 为了满足 Paxos 算法的仲裁（Quorum）要求，避免集群出现脑裂、无法达成一致决策的情况。
底层核心：仲裁数（Quorum）的计算逻辑
MON 集群的核心作用是维护集群元数据（Cluster Map）的一致性，这个过程依赖 Paxos 一致性算法。算法的关键规则是：
只有当存活节点数 ≥ 仲裁数时，集群才能正常工作、做出有效决策。
仲裁数的计算公式是固定的：
仲裁数=⌊2n⌋+1
其中 n 是 MON 节点总数，仲裁数本质是集群的 “最小有效存活节点数”。
核心目的：避免脑裂（Split-Brain）
脑裂是分布式集群的致命问题 —— 当集群网络分区时，节点被分成多个独立的小集群，每个小集群都认为自己是 “合法集群”，进而导致元数据不一致。
奇数节点能从根本上避免这种情况：
- 假设 3 节点 MON 集群发生网络分区，只能分成 2 节点 + 1 节点 两个阵营。
- 2 节点阵营满足仲裁数（2 ≥ 2），可以正常工作；1 节点阵营不满足仲裁数，会自动停止服务。
- 最终只有一个 “合法集群”，不会出现多个集群各自决策的脑裂现象。
如果是 4 节点偶数集群，若发生网络分区变成 2 节点 + 2 节点：
- 两个阵营的存活节点数（2）都小于仲裁数（3），整个集群直接瘫痪，无法提供服务。