去中心化的数据路径
Ceph 的核心设计是客户端不需要经过中心节点转发数据:客户端拿到集群映射后,用 CRUSH 算法自己算出某个对象应该落在哪些 OSD 上,然后直接与这些 OSD 通信。因此集群里没有承担全部流量的数据网关,MON 只负责维护集群映射与成员状态,数据面随 OSD 数量横向扩展。
基本信息
| 适用平台 | 分布式统一存储集群 |
|---|---|
| MON | 维护集群映射与成员一致性,需要多数派 |
| OSD | 存储对象数据、参与复制与恢复 |
| MGR | 提供监控指标、面板与模块托管 |
| MDS | 为文件接口提供元数据服务 |
| 对象网关 | 对外提供兼容对象存储的接口 |
组件职责
| 组件 | 职责 | 异常时的表现 |
|---|---|---|
| MON | 集群映射与共识 | 映射无法更新,集群管理操作受限 |
| OSD | 数据存储、复制与恢复 | 数据降级、可用容量下降 |
| MGR | 指标与模块服务 | 监控与面板数据中断,数据面通常不受影响 |
| MDS | 文件系统元数据 | 文件接口不可用或元数据操作变慢 |
| 对象网关 | 对象接口与多站点同步 | 对象访问失败,文件与块接口可能正常 |
查看组件状态
查看组件状态
ceph -s # 集群总览:健康、MON/OSD 数量、PG 概况
ceph mon dump # MON 成员与选举信息
ceph osd tree # OSD 与故障域层级
ceph mgr services # MGR 对外暴露的服务地址
ceph fs status 2>/dev/null # 文件接口与 MDS 状态(如已启用)区分「管理面」与「数据面」是读懂 Ceph 告警的关键:MON 或 MGR 出问题时,正在运行的数据读写可能完全正常,但集群无法接受新的配置变更;反之 OSD 数量下降会直接影响数据可用性与容量,而管理面看上去一切正常。
OSD 是唯一存放数据的组件,它的数量与介质决定了集群的容量与性能上限;MON 与 MGR 的资源需求小得多,但 MON 的一致性依赖低时延的稳定网络。部署时应把这两类角色的网络与时延要求区分开来。