第 20/20 天
在本系列的前 19 天里,我们从零开始完成了 Ceph Squid v19 在 Ubuntu 24.04 LTS 上的完整生产环境搭建——涵盖架构选型、系统准备、Monitor/Manager/OSD 部署、CRUSH 规划、存储池策略、RBD/RGW/CephFS 三大接口、网络隔离、认证体系、监控告警、性能调优、集群扩容、高可用容灾以及故障排查与数据恢复。今天作为系列收官之作,我们将聚焦于 Ceph 生产环境中最具挑战性的运维场景:集群版本升级与长期维护策略。这是保障 Ceph 存储集群在数年内持续稳定运行的关键能力,也是每一位存储运维工程师必须掌握的核心技能。

一、架构与原理:Ceph 升级机制设计
1.1 Ceph 版本发布模型
Ceph 社区采用稳定的版本发布节奏,每个主版本(如 Squid v19)大约每 1-2 年发布一次,期间持续推送小版本(bugfix release)。理解版本命名规范对于生产环境升级规划至关重要:
| 版本代号 | 版本号 | 发布时间 | 支持状态 |
|---|---|---|---|
| Reef | v18 | 2023 | 已 EOL |
| Squid | v19 | 2024-2025 | 当前稳定版 |
| Tentacle | v20 | 预计 2026 | 开发中 |
Ceph 的升级机制基于以下核心设计原则:
- 滚动升级(Rolling Upgrade):逐节点升级,保证集群在升级过程中始终有可用副本服务请求
- 向后兼容性(Backward Compatibility):新版本 MON/OSD 能够理解旧版本的数据格式,允许混合版本短暂共存
- cephadm 编排升级:从 Octopus v15 开始,cephadm 提供了
ceph orch upgrade命令实现自动化滚动升级,大幅降低人工操作风险 - CRUSH 兼容性:升级期间 CRUSH Map 保持兼容,确保数据分布规则不受影响
1.2 升级数据流与状态机
Ceph 的滚动升级遵循一个有限状态机模型,其核心数据流如下:
[升级前检查] → [设置 noout/noin 标志] → [MON 滚动升级] → [MGR 滚动升级]
→ [OSD 滚动升级(逐个)] → [RGW/MDS 升级] → [验证集群健康] → [清除 noout 标志] → [升级完成]
在 cephadm 模式下,这一流程被封装在 ceph orch upgrade 命令中,但理解底层状态机对于排查升级故障至关重要。每个 OSD 升级时,其上的 PG(Placement Group)会被迁移到其他 OSD,完成后新 OSD 重新加入集群并承接数据。
1.3 升级路径规划
Ceph 不支持跨多个主版本直接升级。官方推荐的升级路径为:
- Reef v18 → Squid v19:直接升级(推荐路径)
- Quincy v17 → Squid v19:需要先升级到 Reef v18,再到 Squid v19
- Pacific v16 → Squid v19:需经过 Quincy → Reef → Squid 三步
# 检查当前集群版本与升级路径
ceph versions
# 输出示例:
# {
# "mon": { "ceph version 19.2.1 (…): squid": 3 },
# "mgr": { "ceph version 19.2.1 (…): squid": 2 },
# "osd": { "ceph version 19.2.1 (…): squid": 12 },
# "rgw": { "ceph version 19.2.1 (…): squid": 2 }
# }
# 检查集群健康状态(升级前必须为 HEALTH_OK)
ceph health detail
上述命令展示了升级前的两个关键检查点:ceph versions 确认所有守护进程运行版本一致,ceph health detail 确保集群无告警。在混合版本状态下,ceph versions 会显示各组件的不同版本分布,这是滚动升级过程中的正常中间态。
1.4 升级影响范围矩阵
| 组件 | 升级影响 | 停机时间 | 回滚难度 |
|---|---|---|---|
| Monitor (MON) | 短暂 quorum 变更 | 无(3+MON 仲裁) | 中等 |
| Manager (MGR) | 主动/备用切换 | 无 | 低 |
| OSD | PG 迁移与重平衡 | 单 OSD 临时下线 | 高 |
| RGW | 请求路由到其他实例 | 无(多实例负载均衡) | 中等 |
| MDS | 文件系统主备切换 | 短暂(秒级) | 中等 |
二、部署实战:Ceph 集群完整升级流程
2.1 升级前准备检查清单
生产环境升级的第一步是全面的预检查。以下脚本执行一系列关键验证:
#!/bin/bash
# upgrade_preflight.sh — Ceph 升级前预检查脚本
# 在 cephadm 节点(admin host)上执行
set -euo pipefail
echo "===== 1. 集群健康状态检查 ====="
HEALTH=$(ceph health)
echo "Health: $HEALTH"
if [ "$HEALTH" != "HEALTH_OK" ]; then
echo "ERROR: 集群非 HEALTH_OK,升级前必须修复所有告警"
ceph health detail
exit 1
fi
echo "===== 2. 当前版本检查 ====="
ceph versions
echo "===== 3. OSD 状态与容量检查 ====="
ceph osd stat
ceph df
# 确保可用空间 >= 30%,升级期间 PG 迁移需要额外空间
AVAILABLE=$(ceph df | awk '/TOTAL/ {print $8}' | tr -d '%')
echo "可用空间百分比: ${AVAILABLE}%"
if [ "${AVAILABLE:-0}" -lt 30 ]; then
echo "WARN: 可用空间不足 30%,升级可能导致 PG 迁移失败"
fi
echo "===== 4. PG 状态检查 ====="
ceph pg stat | head -5
# 确保无 degraded/undersized/recovery 状态的 PG
DEGRADED=$(ceph pg dump | grep -c "degraded" || echo 0)
echo "Degraded PGs: $DEGRADED"
echo "===== 5. cephadm 版本检查 ====="
cephadm version 2>/dev/null || echo "cephadm version check skipped"
echo "===== 6. 备份集群配置 ====="
BACKUP_DIR="/root/ceph_upgrade_backup_$(date +%Y%m%d)"
mkdir -p "$BACKUP_DIR"
ceph config dump > "$BACKUP_DIR/ceph_config.txt"
ceph osd dump > "$BACKUP_DIR/osd_dump.txt"
ceph mon dump > "$BACKUP_DIR/mon_dump.txt"
ceph fs dump > "$BACKUP_DIR/fs_dump.txt"
ceph mgr dump > "$BACKUP_DIR/mgr_dump.txt"
ceph crush dump > "$BACKUP_DIR/crush_dump.txt"
ceph auth list > "$BACKUP_DIR/auth_list.txt"
echo "配置已备份至 $BACKUP_DIR"
echo "===== 7. 下载新版本容器镜像 ====="
# Squid v19.2.2 示例(根据实际情况替换版本号)
NEW_IMAGE="quay.io/ceph/ceph:v19.2.2"
ceph orch upgrade check "$NEW_IMAGE" 2>/dev/null ||
echo "镜像检查完成,确保网络可达 quay.io"
echo "===== 预检查完成 ====="
这个预检查脚本覆盖了升级前的七个关键维度:集群健康、版本一致性、OSD 状态与容量、PG 健康度、cephadm 工具版本、配置备份以及目标镜像可用性。其中配置备份(步骤 6)是生产环境的底线要求——一旦升级出现不可逆故障,这些 dump 文件是回滚的最后一道防线。
2.2 设置集群维护标志
升级前必须设置 noout 和 noscrub 标志,防止 OSD 在升级过程中被标记为 out 导致数据重平衡风暴:
# 设置 noout:防止 OSD 被标记为 out(升级期间 OSD 短暂下线属正常)
ceph osd set noout
# 设置 noscrub 和 nodeep-scrub:暂停后台清洗任务,释放 IO 给 PG 迁移
ceph osd set noscrub
ceph osd set nodeep-scrub
# 可选:设置 noin 防止新 OSD 加入(适用于精确控制升级范围)
# ceph osd set noin
# 验证标志已设置
ceph osd dump | grep flags
# 期望输出包含:noout, noscrub, nodeep-scrub
2.3 执行 cephadm 编排升级
cephadm 的 ceph orch upgrade 命令是 Squid 版本升级的核心手段。它会自动执行滚动升级流程:
# 启动集群升级到指定镜像版本
ceph orch upgrade start
–image quay.io/ceph/ceph:v19.2.2
# 监控升级进度(实时跟踪)
ceph orch upgrade status
# 升级进度示例输出:
# {
# "target_image": "quay.io/ceph/ceph:v19.2.2",
# "in_progress": true,
# "services_complete": ["mon", "mgr"],
# "services_in_progress": ["osd"],
# "message": "upgrading OSD daemons"
# }
# 查看各守护进程升级状态
ceph orch ps –format json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for d in data:
print(f"{d['daemon_type']:6s} {d['daemon_id']:20s} {d['status']:10s} {d.get('version','N/A')}")
"
ceph orch upgrade 的工作原理是:cephadm 通过 SSH 连接到各存储节点,依次拉取新版本容器镜像、停止旧容器、启动新容器,并等待守护进程恢复 ONLINE 状态后再升级下一个。整个过程遵循 MON → MGR → OSD → RGW/MDS 的顺序。
2.4 升级期间监控与验证
升级过程中需要持续监控集群状态,以下是完整的监控命令组合:
# 实时查看集群健康变化
watch -n 5 'ceph health detail; echo "—"; ceph pg stat'
# 查看 PG 恢复进度
ceph pg dump pgs | awk '
/^pg/ {
state = $2;
if (state !~ /active+clean/) {
print $1, state
}
}' | head -20
# 监控 OSD 状态变化
ceph osd tree
# 查看升级日志(cephadm 日志)
journalctl -u ceph-* –since "10 min ago" –no-pager | tail -50
# 检查客户端连接是否受影响(RGW 示例)
radosgw-admin user list –rgw-realm=default
# 或通过 S3 API 验证
s3cmd ls s3://test-bucket –no-encrypt
2.5 升级后清理与验证
升级完成后,执行完整的验证与清理流程:
# 确认所有守护进程已升级到目标版本
ceph versions
# 所有组件版本应统一显示 v19.2.2
# 确认升级已完成
ceph orch upgrade status
# 期望:in_progress: false
# 清除维护标志
ceph osd unset noout
ceph osd unset noscrub
ceph osd unset nodeep-scrub
# 验证集群健康恢复 HEALTH_OK
ceph health
# 触发一次深度清洗验证数据完整性(可选,建议在低峰期)
ceph pg scrub <pg_id> # 对特定 PG 执行
# 全集群深度清洗(谨慎使用,会产生大量 IO)
# ceph osd deep-scrub all
2.6 升级配置参数详解
cephadm 升级行为可通过以下参数精细控制:
# cephadm 升级相关配置参数(通过 ceph config set 调整)
# 设置升级时每个 OSD 等待 ONLINE 的超时时间(秒)
# 默认值:300(5分钟),生产环境建议提高到 600
ceph config set mgr mgr/cephadm/osd_upgrade_timeout 600
# 设置容器镜像拉取重试次数
ceph config set mgr mgr/cephadm/container_image_retry 3
# 控制升级并发度(同时升级的 OSD 数量)
# 默认 cephadm 逐个升级 OSD,确保安全
# 可通过以下配置允许有限并发
ceph config set mgr mgr/cephadm/osd_upgrade_concurrency 1
# 设置升级期间 PG 最小可用副本数(低于此值将暂停升级)
# 默认值因 pool size 而异,生产环境建议 >= 2
ceph config set global mon_osd_min_up_ratio 0.3
三、生产环境注意事项与踩坑提示
3.1 升级窗口规划
生产环境升级应严格遵循维护窗口制度:
- 升级时间窗口:建议安排在业务低峰期(凌晨 2:00-6:00),整个滚动升级过程可能持续 2-6 小时(取决于 OSD 数量和数据量)
- 通知机制:升级前 48 小时通知所有依赖方,包括 RBD 客户端、RGW S3 用户、CephFS 挂载端
- 回滚预案:准备完整的回滚计划,包括回退到旧版本镜像和恢复配置备份
- 监控值守:升级期间必须有运维人员全程值守,监控告警面板
3.2 常见踩坑提示
踩坑 1:升级期间 PG 不可用导致客户端 IO 超时
cephadm 默认逐个 OSD 升级,但如果集群可用空间不足或副本数配置过低(size=2 min_size=1),升级单个 OSD 时可能导致 PG 降级到 min_size 以下。解决方案:
# 升级前确认所有存储池 min_size 设置合理
ceph osd pool ls | while read pool; do
size=$(ceph osd pool get "$pool" size | awk '{print $2}')
min_size=$(ceph osd pool get "$pool" min_size | awk '{print $2}')
echo "Pool: $pool | size=$size | min_size=$min_size"
done
# 生产环境建议:size=3, min_size=2(三副本池)
# 或:size=4+2, min_size=3(纠删码池)
踩坑 2:容器镜像拉取失败导致升级卡死
在内网无外网环境或 quay.io 访问受限时,cephadm 拉取镜像会超时失败,升级卡在中间状态。解决方案是预拉取镜像或使用本地镜像仓库:
# 在所有存储节点预拉取镜像
for node in node1 node2 node3 node4 node5; do
ssh root@$node "podman pull quay.io/ceph/ceph:v19.2.2"
done
# 或使用本地 Harbor 镜像仓库
ceph config set mgr mgr/cephadm/container_image
harbor.internal/ceph/ceph:v19.2.2
踩坑 3:升级后 CRUSH 兼容性问题
从旧版本升级时,CRUSH Map 可能使用 straw 算法,新版本默认使用 straw2。虽然两者兼容,但 straw 算法在权重变更时会导致不必要的数据迁移。升级后建议迁移到 straw2:
# 检查当前 CRUSH 算法
ceph osd crush get-tunable straw_calc_version
# 查看各 bucket 的 alg
ceph osd crush dump | python3 -c "
import json, sys
crush = json.load(sys.stdin)
for b in crush['buckets']:
print(f"{b['type_name']:10s} {b['name']:30s} alg={b['alg']}")
"
3.3 安全考量
- SSH 密钥安全:cephadm 依赖 SSH 连接存储节点,确保
cephadm的 SSH 私钥(/etc/ceph/cephadm/cephadm_ssh_key)权限为 600,且仅 admin 节点持有 - 容器镜像签名验证:生产环境应验证 Ceph 官方镜像的签名,防止供应链攻击
- 升级审计:所有升级操作应记录到运维审计系统,包括操作人、时间、版本变更
- 敏感配置保护:升级备份文件中包含 cephx 密钥,存储在加密目录或加密文件系统中
四、常见问题
Q1:升级过程中某个 OSD 升级失败,如何处理?
cephadm 会在 OSD 升级失败时自动重试。如果持续失败,首先检查该 OSD 的容器日志:cephadm ls --no-detail 查看守护进程状态,然后 journalctl -u ceph-$(ceph fsid)@osd.<id> 查看日志。常见原因包括磁盘空间不足、容器镜像损坏或 OSD 元数据损坏。修复后使用 ceph orch upgrade resume 继续升级。如果该 OSD 无法恢复,可手动将其标记为 down 并从集群中移除,待升级完成后再重新添加。
Q2:可以从 Squid v19 直接升级到未来的 Tentacle v20 吗?
可以。Ceph 官方支持相邻主版本之间的直接升级(v19 → v20)。但不建议跨两个主版本升级(如 v18 → v20),因为可能存在不兼容的配置格式变更。最佳实践是每次主版本发布后,在 6 个月内完成升级,保持与社区支持节奏同步。升级前务必阅读目标版本的 Release Notes,特别关注 Breaking Changes 和 Deprecation 部分。
Q3:升级后是否需要更新客户端(rbd-nbd、librados、s3cmd 等)?
是的。Ceph 客户端与服务端版本不需要严格一致(Ceph 保证服务端向后兼容旧客户端),但建议在集群升级后逐步升级客户端,以利用新版本的功能改进和性能优化。特别是内核态 RBD 客户端,建议保持与集群版本同一大版本。可以通过 ceph tell osd.* version 和 ceph features 命令检查集群当前支持的特性集,确保客户端兼容性。
五、总结
Ceph 生产环境的版本升级与长期维护是整个集群生命周期管理中最关键的运维能力。通过 cephadm 的 ceph orch upgrade 机制,Squid v19 的滚动升级已大幅简化,但生产环境升级仍需严格遵循预检查 → 设标志 → 执行升级 → 持续监控 → 验证清理的标准流程。核心要点包括:确保升级前集群 HEALTH_OK 且可用空间充足(≥30%),设置 noout/noscrub 标志防止数据迁移风暴,预拉取容器镜像避免网络问题卡死升级,以及做好完整的配置备份以备回滚。掌握这些策略和技巧,才能确保 Ceph 存储集群在数年运行周期内平稳完成版本迭代,持续提供高可用、高性能的分布式存储服务。
六、系列完结语
至此,「Ceph 生产环境搭建」20 篇系列文章全部完成。从第 1 天的架构概述与选型,到今天第 20 天的升级维护与版本迭代,我们完整覆盖了 Ceph Squid v19 在 Ubuntu 24.04 LTS 生产环境部署的每一个关键环节。希望这个系列能够成为您搭建和运维 Ceph 分布式存储集群的实战参考手册。感谢各位读者的持续关注,祝您的存储集群永远 HEALTH_OK!
七、系列目录
以下为本系列全部 20 篇文章的完整目录,均已发布:
- ✅ 第 1 天:Ceph 架构概述与生产环境选型指南
- ✅ 第 2 天:Ubuntu 系统准备:内核调优与磁盘规划
- ✅ 第 3 天:Cephadm 部署工具详解与集群引导初始化
- ✅ 第 4 天:Monitor 节点部署与高可用配置
- ✅ 第 5 天:Manager 节点部署与模块启用
- ✅ 第 6 天:OSD 存储节点部署:BlueStore 配置与磁盘管理
- ✅ 第 7 天:CRUSH Map 架构解析与故障域规划
- ✅ 第 8 天:存储池(Pool)创建与 PG 数量规划
- ✅ 第 9 天:副本与纠删码存储池策略对比实战
- ✅ 第 10 天:Ceph 块存储 RBD 配置与生产实践
- ✅ 第 11 天:Ceph 对象存储 RGW 网关部署与 S3 兼容
- ✅ 第 12 天:CephFS 分布式文件系统部署与挂载
- ✅ 第 13 天:Ceph 网络架构:集群网络与公共网络分离
- ✅ 第 14 天:Ceph 认证体系 cephx 与用户权限管理
- ✅ 第 15 天:Ceph 集群监控:Prometheus + Grafana + 内置仪表盘
- ✅ 第 16 天:Ceph 性能调优:OSD 参数与缓存分层
- ✅ 第 17 天:Ceph 集群扩容实战:OSD 动态添加与 CRUSH 重平衡
- ✅ 第 18 天:Ceph 高可用与容灾设计:多副本、跨机房与异地灾备
- ✅ 第 19 天:Ceph 故障排查与数据恢复实战
- ✅ 第 20 天:Ceph 生产环境升级维护与版本迭代策略(本文)


















暂无评论内容