为什么要滚动升级
Ceph 集群升级不能停机，只能逐个守护进程替换：同一时刻只让少量组件处于新版本，其余仍在服务，靠多副本与仲裁撑住可用性。官方只支持逐个小版本递进升级，跨版跳跃会因为数据格式与协议差异导致组件无法互相通信。
基本信息
| 适用平台 | Ceph 集群（Nautilus 及以后，以官方文档为准） |
|---|---|
| 典型顺序 | MON → MGR → OSD → MDS → 客户端 |
| 编排工具 | cephadm 的 ceph orch upgrade，或逐节点包管理升级 |
| 权限要求 | 集群管理员，且需能逐节点登录 |
典型使用场景
- 小版本升级修漏洞与缺陷：需要最小化业务中断窗口
- 大版本演进：按官方升级路径逐版推进，先升级后启用新特性
- 异构集群拉齐：部分节点落后版本导致特性开关不一致
- 升级前演练：在测试集群验证流程与耗时，再安排生产窗口
升级主流程
升级主流程
ceph -s && ceph versions # 升级前记录健康状态与各组件版本
ceph osd set noout # 暂停因 OSD 离线触发的回填
ceph orch upgrade check <目标版本> # 用 cephadm 检查并预检（以官方文档为准）
ceph orch upgrade start <版本> # 由编排器按顺序逐个替换组件
ceph orch upgrade status # 观察进度
ceph osd unset noout # 升级完成确认健康后再放开升级过程观察要点
| 观察项 | 命令 | 正常表现 |
|---|---|---|
| 集群健康 | ceph -s | 健康告警只与当前重启的组件相关 |
| PG 状态 | ceph pg stat | 以 active+clean 为主，无大量降级 |
| 组件版本 | ceph versions | 同类型组件版本逐步收敛到目标版本 |
逐节点手动升级时，每重启一个组件都要等集群回到健康再动下一个；批量并行重启是升级中最常见的自伤方式。
升级前务必确认有配置与密钥环的可用备份、并预留回退窗口；升级中不要同时修改配置或调整 PG 数，避免把问题归因复杂化。
升级前检查清单
- 确认全集群健康，PG 基本处于 active 且已完成状态
- 确认升级路径符合官方支持的逐版递进要求
- 确认配置与密钥环备份已导出并可读取
- 确认监控与告警在升级窗口有人值守，能第一时间看到降级
- 确认业务方已知晓窗口，且有回退时间余量
升级完成后要复核新版本已弃用的配置项：废弃参数会以告警形式反复出现，继续保留可能在新版本中彻底失效。