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