Ceph 集群快速部署：三节点小规模集群从零到可用
Ceph 常给人「组件多、上手难」的印象，其实自从官方改用 cephadm 部署后，小规模集群的搭建已经大幅简化。本文用三台主机从零拉起一套 Ceph 集群，走通到「RBD 块设备实际挂载可用」为止，并把健康检查命令的读法、数量口径和常见故障的判断方法一并说清，适合拿测试环境先练一遍再考虑生产。
适用环境：Ceph Reef（18.2）版本口径，cephadm 容器化部署；三台主机 ceph-01（192.0.2.41）、ceph-02（192.0.2.42）、ceph-03（192.0.2.43），每台一块系统盘加至少一块空数据盘，操作系统为 Ubuntu 22.04 或同级发行版。
前置条件（部署前规划）
- 网络：管理/业务流量走同一网段即可开始（小规模可不拆 public/cluster 双网），三台主机名互相可解析，先写好 /etc/hosts；
- 磁盘：OSD 用的数据盘必须是空盘（无分区表残留），cephadm 会拒绝有数据的盘；SSD 与 HDD 混用时要规划好设备类（device class），入门阶段先同构；
- 时间同步：三台主机必须开启 chrony 并确认偏差在毫秒级，Ceph 对时钟偏移极其敏感，这是第一大故障源；
- 基础软件：每台装好 chrony、lvm2 与容器运行时（podman 或 docker），并已配置免密 SSH 到其余节点的管理账号；
- 容量口径：三副本下可用容量约为裸容量的三分之一，先按这个数评估是否够用。
第一步：bootstrap 拉起第一个节点
在 ceph-01 上安装 cephadm 并初始化集群，第一个 MON 与 MGR 会以容器形式起在本机：
curl --silent --remote-name --location https://download.ceph.com/rpm-reef/el9/noarch/cephadm
chmod +x cephadm
./cephadm add-repo --release reef
./cephadm install
mkdir -p /etc/ceph
cephadm bootstrap --mon-ip 192.0.2.41 --initial-dashboard-user admin \
--initial-dashboard-password CHANGE_ME --allow-fqdn-hostname
bootstrap 成功后会输出 Dashboard 地址与登录信息，并把 ceph 命令装进 PATH（通过 cephadm shell 或安装 ceph-common 均可）。此时执行 ceph -s 应能看到 1 个 mon、1 个 mgr，健康状态大概率是 HEALTH_WARN，先不用管——节点和 OSD 还没齐，警告是预期内的。
第二步：纳管其余主机
cephadm 通过 SSH 管理其他节点。把 bootstrap 生成的集群公钥分发到 ceph-02、ceph-03，再逐台添加：
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-02
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph-03
ceph orch host add ceph-02 192.0.2.42
ceph orch host add ceph-03 192.0.2.43
ceph orch host ls
添加成功后 cephadm 会自动在新主机上部署监控组件（node-exporter、crash 收集等）。随后把 MON 扩到 3 个、MGR 保持 2 个（1 活跃 1 备用）：
ceph orch apply mon --placement="ceph-01 ceph-02 ceph-03"
ceph orch apply mgr --placement=2
第三步：添加 OSD
先看 cephadm 发现了哪些可用盘，再把所有空闲盘一次性纳为 OSD：
ceph orch device ls
ceph orch apply osd --all-available-devices
ceph osd tree
ceph orch device ls 输出里 AVAILABLE 为 Yes 的盘才会被采用；如果某块盘显示 No 且原因含 LVM 或分区信息，多半是旧分区残留，用 cephadm zap-osd 或手工 wipefs 清掉后再试（操作前务必确认盘上无数据）。osd tree 里应看到三台 host 各挂着自己的 OSD，状态 up。生产环境更推荐用 DriveGroup 的 YAML 精确声明哪些盘做数据盘、哪些做 WAL/DB，这里入门从简。
第四步：读懂状态与健康检查
ceph -s
ceph health detail
ceph osd df
ceph pg stat
ceph -s 的关键行读法：
- health：HEALTH_OK 才是全绿；HEALTH_WARN 要结合 detail 看，不要养成长期带警告运行的习惯。
- mon：应显示 3 daemons, quorum 后跟三台主机名，说明三方仲裁成立。
- osd：数量应为「总数 up、总数 in」，有 OSD down 时先看它所在主机的磁盘与日志。
- pgs：理想状态全部是 active+clean。active+undersized 表示副本不足（常因 OSD 掉线），active+degraded 表示正在恢复，长时间停在 creating/remapping 要结合下文排查。
ceph health detail 会把每个警告展开成具体对象与建议命令，比 -s 的汇总信息可操作得多，排障时优先看它。
第五步：创建 RBD 池并做块存储验证
# 建池并启用 rbd 应用
ceph osd pool create rbd_pool 64
ceph osd pool application enable rbd_pool rbd
rbd pool init rbd_pool
# 创建 10G 镜像
rbd create rbd_pool/img01 --size 10G
rbd info rbd_pool/img01
64 是 PG 数量，小规模集群的经验口径是每 OSD 约对应数十个 PG 起步，池多或盘多时再按官方 PG 计算器调整，PG 数过少会导致数据分布不均、过多则拖累性能。在一台客户端主机上（可以是 ceph-01 兼任）把镜像映射成本地块设备并挂载验证：
# 客户端需有集群的 ceph.conf 与 client.admin 密钥环（测试环境从 ceph-01 拷贝）
rbd map rbd_pool/img01
mkfs.xfs /dev/rbd0
mkdir -p /mnt/rbdtest
mount /dev/rbd0 /mnt/rbdtest
dd if=/dev/zero of=/mnt/rbdtest/testfile bs=1M count=512 conv=fsync
ls -lh /mnt/rbdtest
能完成格式化、挂载并写入 512 MB 数据，说明 MON、OSD、RBD 全链路可用。验证完 umount 并 rbd unmap 释放映射。
第六步：数量与容错口径
- MON 数量：必须为奇数，靠多数派仲裁。小规模 3 个起步，允许挂 1 个；5 个允许挂 2 个。不要用 2 个 MON——挂 1 个就失去仲裁，等于没有容错。
- MGR：1 个也能跑（功能受影响但数据面不受影响），建议 2 个做主备。
- 副本与容错：默认 3 副本且故障域为 host 时，能忍受整台主机宕机且数据不丢；写入要求多数副本确认。两节点加仲裁的玩法不适合 Ceph，别在这上面省机器。
- 容量水位：集群用量到 85%（nearfull）开始告警，95%（full）会停写。OSD 分布不均时单块盘先满也会触发，要定期看 ceph osd df 的利用率离散程度。
验证
ceph -s # 期望 health: HEALTH_OK，pgs 全部 active+clean
ceph osd tree # 三台 host 下 OSD 均为 up
rbd ls rbd_pool && rbd du rbd_pool/img01
进阶验证可以停掉 ceph-03 的电源或网络，观察 ceph -s 在几分钟内转为 HEALTH_WARN 并自动开始数据恢复，恢复主机后 PG 回到 active+clean——这一步做过，才算真正见过 Ceph 的自愈行为。
常见问题
- 时钟偏移警告（clock skew）：health detail 报 mon 时钟偏差过大。检查三台 chrony 的同步状态（chronyc tracking 与 sources），虚拟机环境尤其常见；修时间而不是屏蔽警告，偏移超过阈值时 MON 会被踢出仲裁。
- OSD 起不来或反复重启：先 ceph osd tree 确认哪个 OSD down，再看该主机上 cephadm 容器日志与系统日志，常见原因是数据盘故障、盘被误格式化、或内存不足被 OOM。单块盘损坏时按「标记 out → 摘除 → 换盘 → 重新 apply osd」流程处理。
- PG 长期不是 active+clean：undersized 多为副本数不足（OSD 掉线或池的 size 大于可用故障域数量，比如只有 2 台主机却要求 3 副本跨主机）；inconsistent 需要 scrub 修复；先 health detail 看它点名了哪个 PG 与 OSD，再 ceph pg <pgid> query 看细节，不要盲目改 PG 数。
- ceph orch 操作无反应：编排动作都经 MGR 的 cephadm 模块下发，MGR 假死时 orch 命令会排队。ceph mgr stat 确认活跃 MGR，必要时 ceph mgr fail 触发主备切换再重试。
边界说明：三节点小规模集群适合学习、测试与内部小业务，它的上限也很明显——节点太少时数据恢复的余量和 I/O 并行度都有限，单机房部署也没有地域级容灾。把它当作理解 Ceph 数据分布与运维动作的练功房最合适；真要上生产核心业务，节点数、网络（万兆起步、双网分离）与磁盘规划要重新按容量和性能目标做设计。
小结：cephadm 把部署门槛降到了「bootstrap、加主机、apply osd」三步，日常运维的重点随之转移到读状态上——ceph -s 看全局，health detail 看细节，osd tree 与 pg stat 看数据面。先在三节点上把自愈流程亲手演一遍，再谈调优。
