文章目录
- 组件职责速查
- 三个架构精髓
- 想继续生长时
这个主题适合展开成两幅图：先看整体分层架构，再看一次写入在集群里的旅程——把“组件是什么”和“组件怎么协作”分开讲。
分层结构就是“接口层（按需）→ 控制面（元数据）→ 数据面（真存储）”。理解 Ceph 最关键的一步是看懂数据是怎么流动的——它最反直觉的地方是：写入路径完全不经过 mon 和 mgr。看第二幅图：
两幅图合起来就是完整的 Ceph。最后把组件职责和你集群的部署现状对齐成一张表：
组件职责速查
| 组件 | 职责 | 你的集群 | 备注 |
|---|---|---|---|
| MON | 集群“宪法法院”：维护 monmap/OSDmap/PG map，Paxos 多数派裁决，civet 认证 | 3 个（每台一个） | 容忍 1 台故障，生产最低配 |
| MGR | 集群“大管家”：cephadm 编排、dashboard、prometheus 指标、balancer、telemetry | 3 个（active + 2 standby） | 同一时刻只有一个 active |
| OSD | 真正干活的存储引擎：存对象、副本复制、心跳、恢复 | 3 个（每台一块 HDD） | 底层是 BlueStore |
| crash | 崩溃转储收集器：守护进程 crash 后收集 core dump 供分析 | 3 个 | 就是这次排障的主角 |
| cephadm | 容器化编排器（跑在 mgr 模块里）：部署/升级/扩缩容 | 已启用 | 所有守护进程都是 podman 容器 |
| MDS | CephFS 元数据服务器 | 未部署 | 想用文件存储时再加 |
| RGW | 对象网关：提供 S3/Swift API | 未部署 | 想做对象存储时再加 |
三个架构精髓
控制面与数据面彻底分离。MON/MGR 挂了，客户端读写完全不受影响（只是不能做管理操作）——这是 Ceph 高可用的根基。你上次 mgr.hanyw202 error 时数据面毫无感觉，就是这个设计的体现。
去中心化数据路由。没有“主节点转发”这回事——每个客户端内嵌 CRUSH 算法，本地算出数据在哪，直连对应的 OSD。集群从 3 个 OSD 扩到 3000 个，路由开销不变，吞吐线性增长。
一切皆 Pool。RBD 云盘、RGW 的 bucket、CephFS 数据，最终都归结为“某个 pool 里的对象”，统一享受三副本、CRUSH 分布、自动恢复。上层接口只是不同的“翻译官”。
想继续生长时
# 开启监控面板（Web UI，https://<hanyw200>:8443）ceph mgr moduleenabledashboard ceph mgr moduleenableprometheus# Prometheus 指标（9283 已在监听）# 需要对象存储（S3）时ceph orch apply rgw myrgw--placement="hanyw200,hanyw201,hanyw202"# 需要文件存储（POSIX 挂载）时ceph orch apply mds myfs--placement="2 hanyw201 hanyw202"一句话总结：你的集群目前是“纯 RADOS 内核 + cephadm 管理”（mon/mgr/osd/crash），属于任何上层服务的地基；接口层（RBD/RGW/CephFS）按业务需要随时可以往上长，不动地基。
