OSD 在数据路径上的位置
OSD（Object Storage Daemon）是 Ceph 中唯一真正读写磁盘的守护进程，常规部署一块盘一个 OSD。上层写入的数据先被切成对象，对象按名称哈希落到某个归置组（PG），再由 CRUSH 算出承载这个 PG 的 OSD 列表，列表首位是 primary，负责协调副本写入。客户端与服务端各自用同一份 Map 计算，因此不需要中心节点记录数据位置。
基本信息
| 部署粒度 | 常规一块物理盘一个 OSD，单盘多 OSD 在性能敏感场景不推荐 |
|---|---|
| 落盘引擎 | 新版本默认 BlueStore，直接管理裸设备，元数据放 RocksDB |
| 权重语义 | CRUSH 权重按容量比例设置，通常 1TB 记 1.0 |
| 状态维度 | up/down 表示进程是否存活，in/out 表示是否参与数据分布 |
| 内存占用 | 每 OSD 常驻数百 MB 起，PG 与对象数量大时更高 |
| 数据校验 | 默认周期性 scrub 校验副本一致性，deep-scrub 会读取数据区 |
典型使用场景
- 新集群盘位规划：按实际容量设定权重，避免大盘小盘一视同仁
- 单盘性能异常定位：锁定到具体 OSD 后查看其延迟、队列与内核错误
- 核对数据落点：用 osd map 与 pg map 确认副本实际分布在哪几块盘
- 扩容前的容量与 PG 预算：新增 OSD 后确认每 OSD 的 PG 数与使用率
- 恢复过程观察：down 或 out 之后要迁移多少数据由 OSD 侧参数决定
分布查看命令
分布查看命令
ceph osd stat # 总数、up 与 in 的数量
ceph osd tree # 层级结构、权重、up/down、in/out
ceph osd df # 每 OSD 的容量使用率与偏差
ceph osd map <pool> <object> # 对象所属 PG 与承载集合
ceph pg map <pgid> # 指定 PG 的承载 OSD 列表
ceph osd metadata <id> # 该 OSD 的设备型号与所在主机输出逐列读法
| 字段 | 含义 | 判读要点 |
|---|---|---|
| ID | OSD 编号 | 后续定位单盘的唯一依据 |
| WEIGHT | CRUSH 权重 | 与真实容量不符时使用率会长期不均 |
| UP/DOWN | 进程是否存活 | down 且未 out 会拖住对应的 PG 恢复 |
| IN/OUT | 是否参与数据分布 | out 表示数据正在被迁出，迁移未完成前不要删 OSD |
| PRI-AFF | 主副本亲和度 | 长期远低于 1 说明分布可能需复核 |
| USE% 与 VAR | 使用率与偏差系数 | VAR 越大表示各 OSD 之间越不均衡 |
BlueStore 把数据写在裸设备上，元数据与 WAL 可放到独立介质：小规模常与数据同盘，容量或性能敏感时会把 block.db 放到 NVMe。介质组合需要在建 OSD 时确定，后期更换等于重建 OSD。
不先 out 就直接删除或重建 OSD，会让 PG 丢失副本并可能进入 incomplete 状态，此时只能从未损坏副本尽力恢复。规范顺序是 out、等待数据迁移完成、再移除 OSD。
分布不均的排查顺序
使用率长期不均，先看权重是否按容量设置，再看 CRUSH 规则是否把部分 OSD 排除在外，然后确认 PG 数量是否过少导致分配粒度太粗，最后才考虑微调 reweight。临时 reweight 在 OSD 重启后失效，需要持久效果就改 CRUSH 权重。