Ceph 15.2 节点关机 5 天后恢复完整教程 - 生产环境故障处理实战指南
前言
在生产环境中,Ceph 集群的某个节点可能因为硬件故障、系统维护、断电等原因意外关机。当节点离线数天后重新启动,如何安全、正确地将其恢复至集群是一个常见的运维场景。本文基于 Ceph 15.2 (Octopus) 版本,详细介绍节点关机 5 天后的完整恢复流程,包括故障分析、恢复步骤、数据同步和常见问题处理。
Ceph 版本:15.2.x (Octopus)
适用场景:OSD 节点意外关机/离线后的恢复
环境要求:Ceph 15.2 集群,至少 3 个节点
一、故障背景分析
1.1 场景描述
# 集群环境
- Ceph 版本:15.2.15 (Octopus)
- 节点数量:3 个 MON + 3 个 OSD 节点
- 故障节点:node3 (关机 5 天)
- 集群状态:DEGRADED (降级运行)
1.2 节点离线 5 天的影响
| 影响项 | 说明 | 严重程度 |
|---|---|---|
| 数据冗余 | 副本数不足,存在数据风险 | 🔴 高 |
| 集群健康 | HEALTH_WARN 或 HEALTH_ERR | 🔴 高 |
| 数据重建 | 其他节点已重建缺失副本 | 🟡 中 |
| OSD 状态 | 故障节点 OSD 标记为 down/out | 🟡 中 |
| 数据差异 | 故障节点数据落后 5 天 | 🟢 低 |
1.3 恢复前检查清单
□ 确认故障节点硬件正常
□ 确认网络连接恢复
□ 确认时间同步正常
□ 确认 Ceph 版本一致
□ 确认配置文件一致
□ 备份当前集群状态
□ 通知相关人员维护窗口
---
二、恢复前准备工作
2.1 检查集群当前状态
在正常节点(node1 或 node2)上执行:
1. 查看集群健康状态
# 查看集群整体状态
ceph health detail
# 查看集群状态摘要
ceph -s
# 示例输出:
# cluster:
# id: abc12345-6789-defg-hijk-lmnopqrstuvw
# health: HEALTH_WARN
# reason: 6 osms are down; 3 osds are out
# mon: 3 daemons, quorum node1,node2,node3
# mgr: node1(active), standbys: node2
# osd: 30 osds: 24 up, 30 in
# data:
# avail: 5.2TiB
# usage: 12TiB
# objects: 1.2M
2. 查看故障 OSD 状态
# 查看所有 OSD 状态
ceph osd tree
# 示例输出:
# ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
# -1 10.00000 root default
# -3 3.33333 host node1
# 0 hdd 1.11111 osd.0 up 1.00000 1.00000
# 1 hdd 1.11111 osd.1 up 1.00000 1.00000
# 2 hdd 1.11111 osd.2 up 1.00000 1.00000
# -5 3.33333 host node2
# 3 hdd 1.11111 osd.3 up 1.00000 1.00000
# 4 hdd 1.11111 osd.4 up 1.00000 1.00000
# 5 hdd 1.11111 osd.5 up 1.00000 1.00000
# -7 3.33333 host node3 # 故障节点
# 6 hdd 1.11111 osd.6 down 0 1.00000 # 这些 OSD 已 down
# 7 hdd 1.11111 osd.7 down 0 1.00000
# 8 hdd 1.11111 osd.8 down 0 1.00000
# 查看具体 OSD 状态
ceph osd dump | grep -E "^osd\.(6|7|8)"
3. 查看 PG 状态
# 查看 PG 分布和状态
ceph pg stat
# 查看处于不一致状态的 PG
ceph pg dump_stuck stale,unclean,inactive -f plain
# 查看受影响的 PG
ceph pg ls_by_osd 6 # 查看 osd.6 相关的 PG
4. 记录当前状态(重要!)
# 备份集群状态信息
ceph -s > /tmp/ceph_status_before.txt
ceph osd tree > /tmp/ceph_osd_tree_before.txt
ceph health detail > /tmp/ceph_health_before.txt
# 导出 OSD map
ceph osd getmap -o /tmp/osd_map_before
# 导出 CRUSH map
ceph osd getcrushmap -o /tmp/crush_map_before
ceph osd getcrushmap -o - | crushtool -d - > /tmp/crush_map_decompiled_before.txt
echo "状态已备份,可以进行恢复操作"
---
2.2 故障节点检查(node3)
登录到故障节点 node3 执行以下检查:
1. 检查系统状态
# 检查系统运行时间(确认刚重启)
uptime
# 检查系统负载
top -bn1 | head -5
# 检查内存使用
free -h
# 检查磁盘空间
df -h
# 检查网络连接
ping -c 4 node1
ping -c 4 node2
# 检查主机名
hostname
hostname -f
2. 检查时间同步(非常重要!)
# 检查当前时间
date
# 检查 NTP 服务状态
systemctl status chronyd
# 或
systemctl status ntpd
# 检查时间同步状态
chronyc sources -v
# 或
ntpq -p
# 如果时间不同步,手动同步
systemctl restart chronyd
chronyc -a makestep
# 验证时间同步(与其他节点对比)
# 在 node1 执行:date
# 在 node3 执行:date
# 时间差应在 100ms 以内
3. 检查网络配置
# 检查网络接口
ip addr show
# 检查公共网络
ping <公共网络网关>
# 检查集群网络
ping <集群网络其他节点 IP>
# 检查端口连通性
telnet node1 6789 # MON 端口
telnet node1 6800 # OSD 端口范围
# 检查防火墙状态
systemctl status firewalld
firewall-cmd --list-all
# 如果需要,临时关闭防火墙测试
systemctl stop firewalld
4. 检查 Ceph 服务状态
# 检查 Ceph 版本(必须与其他节点一致)
ceph -v
# 与其他节点对比
# node1: ceph -v
# node2: ceph -v
# node3: ceph -v
# 版本必须完全一致!
# 检查 Ceph 配置文件
ls -la /etc/ceph/
cat /etc/ceph/ceph.conf
# 对比配置文件(从正常节点复制)
scp node1:/etc/ceph/ceph.conf /etc/ceph/ceph.conf
scp node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring
# 检查 Ceph 服务状态
systemctl status ceph-mon@node3
systemctl status ceph-osd@6
systemctl status ceph-osd@7
systemctl status ceph-osd@8
# 检查 OSD 数据目录
ls -la /var/lib/ceph/osd/
5. 检查磁盘状态
# 检查 OSD 磁盘
lsblk
# 检查磁盘健康状态(S.M.A.R.T)
smartctl -a /dev/sdb
smartctl -a /dev/sdc
smartctl -a /dev/sdd
# 检查文件系统
df -h | grep ceph
# 检查磁盘挂载
mount | grep ceph
# 如果有磁盘故障,需要先更换磁盘
---
三、恢复 OSD 节点
3.1 恢复策略选择
根据节点离线时间和集群状态,有两种恢复策略:
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 方案 A 直接启动 OSD |
离线时间短 (< 24 小时) 数据差异小 |
简单快速 自动同步 |
同步时间长 网络压力大 |
| 方案 B 清除数据重新加入 |
离线时间长 (> 24 小时) 数据差异大 |
同步可控 减少冲突 |
操作复杂 需要重建数据 |
本例选择方案 A(直接启动),因为 Ceph 的自动恢复机制可以处理 5 天的数据差异。
---
3.2 恢复 MON 服务(如果 node3 有 MON)
# 在 node3 上执行
# 1. 检查 MON 状态
ceph mon dump
# 2. 启动 MON 服务
systemctl start ceph-mon@node3
# 3. 检查 MON 状态
systemctl status ceph-mon@node3
# 4. 验证 MON 加入集群
ceph mon_status
# 5. 查看 MON quorum
ceph quorum_status
# 预期输出应包含 node3
# "quorum_names": ["node1","node2","node3"]
---
3.3 恢复 OSD 服务
步骤 1:将 OSD 标记为 in
在正常节点(node1 或 node2)上执行:
# 查看当前 OSD 状态
ceph osd tree
# 将 node3 的 OSD 标记为 in(允许接收数据)
# 注意:先不要设置 up,让 OSD 自己启动后标记
# 方法 1:逐个 OSD 恢复
ceph osd in osd.6
ceph osd in osd.7
ceph osd in osd.8
# 方法 2:批量恢复(推荐)
for osd_id in 6 7 8; do
ceph osd in osd.$osd_id
echo "osd.$osd_id 已标记为 in"
done
# 验证状态
ceph osd tree | grep node3
步骤 2:设置恢复参数
在恢复前,调整 Ceph 的恢复参数,避免对生产环境造成过大影响:
# 查看当前恢复参数
ceph config get mon osd_recovery_max_active
ceph config get mon osd_recovery_max_single_start
ceph config get mon osd_recovery_max_chunk
# 设置保守的恢复参数(降低对生产的影响)
ceph config set mon osd_recovery_max_active 3
ceph config set mon osd_recovery_max_single_start 1
ceph config set mon osd_recovery_max_chunk 1048576
# 设置恢复优先级(降低优先级)
ceph config set mon osd_recovery_sleep 0.1
# 如果是生产环境,建议在业务低峰期恢复
# 可以设置恢复时间窗口
ceph config set mon osd_recovery_forced_peers []
步骤 3:启动 OSD 服务
在故障节点 node3 上执行:
# 1. 检查 OSD 数据目录
ls -la /var/lib/ceph/osd/ceph-6/
ls -la /var/lib/ceph/osd/ceph-7/
ls -la /var/lib/ceph/osd/ceph-8/
# 2. 检查 OSD 权限
chown -R ceph:ceph /var/lib/ceph/osd/
# 3. 启动 OSD 服务
systemctl start ceph-osd@6
systemctl start ceph-osd@7
systemctl start ceph-osd@8
# 4. 启用开机自启
systemctl enable ceph-osd@6
systemctl enable ceph-osd@7
systemctl enable ceph-osd@8
# 5. 检查服务状态
systemctl status ceph-osd@6
systemctl status ceph-osd@7
systemctl status ceph-osd@8
# 6. 查看 OSD 日志(如果启动失败)
journalctl -u ceph-osd@6 -f
tail -f /var/log/ceph/ceph-osd.6.log
步骤 4:验证 OSD 状态
在正常节点上执行:
# 等待 1-2 分钟,让 OSD 完成初始化
# 1. 查看 OSD 状态
ceph osd tree
# 预期输出:
# ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
# -7 3.33333 host node3
# 6 hdd 1.11111 osd.6 up 1.00000 1.00000 # 已 up
# 7 hdd 1.11111 osd.7 up 1.00000 1.00000 # 已 up
# 8 hdd 1.11111 osd.8 up 1.00000 1.00000 # 已 up
# 2. 查看集群状态
ceph -s
# 3. 查看 OSD 详细信息
ceph osd dump | grep -E "^osd\.(6|7|8)"
# 4. 查看 PG 恢复状态
ceph -w # 实时查看集群状态变化
---
四、数据同步和平衡
4.1 监控数据恢复进度
# 在正常节点上执行
# 1. 实时查看恢复进度
watch -n 5 'ceph -s'
# 2. 查看 PG 恢复状态
ceph pg dump | grep -E "recovering|backfill"
# 3. 查看恢复详情
ceph pg ls recovering
# 4. 查看数据平衡进度
ceph osd df
# 5. 查看恢复速度
ceph -w | grep -E "recover|backfill"
# 示例输出:
# pg 1.2 recovering 10+ objects, 10+ kB
# pg 1.5 backfilling 5+ objects, 5+ kB
4.2 理解恢复过程
| 阶段 | 说明 | 预计时间 |
|---|---|---|
| Peering | OSD 与集群建立连接,确认 PG 状态 | 1-5 分钟 |
| Recovery | 从其他副本恢复缺失的数据对象 | 30 分钟 - 数小时 |
| Backfill | 填充新数据到 OSD(如果需要) | 取决于数据量 |
| Active+Clean | 恢复完成,PG 状态正常 | - |
4.3 加速恢复(可选)
如果恢复速度太慢,可以适当调整参数:
# 在业务低峰期,可以临时提高恢复速度
# 1. 增加恢复线程数
ceph config set mon osd_recovery_max_active 10
ceph config set mon osd_recovery_max_single_start 5
# 2. 增加恢复块大小
ceph config set mon osd_recovery_max_chunk 8388608 # 8MB
# 3. 减少恢复延迟
ceph config set mon osd_recovery_sleep 0
# 4. 增加 backfill 速度
ceph config set mon osd_max_backfills 10
# 恢复完成后,记得改回保守值
ceph config set mon osd_recovery_max_active 3
ceph config set mon osd_recovery_max_single_start 1
ceph config set mon osd_recovery_max_chunk 1048576
ceph config set mon osd_recovery_sleep 0.1
4.4 数据平衡
# 检查 OSD 使用率是否均衡
ceph osd df
# 如果某些 OSD 使用率过高,可以调整 CRUSH weight
# 查看 CRUSH weight
ceph osd crush weight-set dump
# 重新平衡数据(谨慎使用)
ceph osd reweight-by-utilization
# 或者手动调整特定 OSD 的权重
ceph osd reweight osd.6 1.0
ceph osd reweight osd.7 1.0
ceph osd reweight osd.8 1.0
# 查看平衡进度
ceph -w
---
五、验证和收尾
5.1 验证集群健康
# 1. 检查集群健康状态
ceph health
# 预期输出:HEALTH_OK
ceph health detail
# 应该没有警告或错误
# 2. 检查集群状态
ceph -s
# 预期输出:
# health: HEALTH_OK
# osd: 30 osds: 30 up, 30 in
# 3. 检查 PG 状态
ceph pg stat
# 预期输出:
# X PGs: Y active+clean
# 4. 检查所有 OSD 状态
ceph osd tree
# 所有 OSD 应该是 up 和 in 状态
# 5. 检查数据一致性
ceph pg scrub all
# 等待 scrub 完成
ceph pg ls | grep -v "active+clean"
5.2 性能测试
# 1. 写入测试
rados bench -p rbd 10 write --no-cleanup
# 2. 读取测试
rados bench -p rbd 10 seq
# 3. 检查 IOPS 和带宽
iostat -x 1 5
# 4. 检查网络流量
iftop -P -n
5.3 恢复默认参数
# 恢复前修改的 Ceph 参数
# 恢复默认值
ceph config rm mon osd_recovery_max_active
ceph config rm mon osd_recovery_max_single_start
ceph config rm mon osd_recovery_max_chunk
ceph config rm mon osd_recovery_sleep
# 或者设置为生产环境推荐值
ceph config set mon osd_recovery_max_active 3
ceph config set mon osd_recovery_max_single_start 1
ceph config set mon osd_recovery_max_chunk 1048576
ceph config set mon osd_recovery_sleep 0.1
# 验证配置
ceph config dump | grep recovery
5.4 清理和文档
# 1. 保存恢复后的状态
ceph -s > /tmp/ceph_status_after.txt
ceph osd tree > /tmp/ceph_osd_tree_after.txt
ceph health detail > /tmp/ceph_health_after.txt
# 2. 对比恢复前后状态
diff /tmp/ceph_status_before.txt /tmp/ceph_status_after.txt
# 3. 清理临时文件
rm -f /tmp/ceph_*.txt
rm -f /tmp/osd_map_before
rm -f /tmp/crush_map_before
# 4. 记录恢复过程和时间
cat > /var/log/ceph/node3_recovery_$(date +%Y%m%d).log << EOF
恢复时间:$(date)
故障节点:node3
离线时长:5 天
恢复 OSD: osd.6, osd.7, osd.8
恢复耗时:约 XX 分钟
恢复后状态:HEALTH_OK
操作人员:XXX
EOF
---
六、常见问题和故障排查
6.1 OSD 无法启动
# 问题 1:权限问题
# 症状:OSD 启动失败,日志显示权限错误
# 解决:
chown -R ceph:ceph /var/lib/ceph/osd/ceph-6/
chmod 755 /var/lib/ceph/osd/ceph-6/
systemctl restart ceph-osd@6
# 问题 2:磁盘故障
# 症状:OSD 启动失败,日志显示 I/O 错误
# 解决:
smartctl -a /dev/sdb # 检查磁盘健康
# 如果磁盘损坏,需要更换磁盘并重新创建 OSD
# 问题 3:配置文件不一致
# 症状:OSD 无法加入集群
# 解决:
scp node1:/etc/ceph/ceph.conf /etc/ceph/
scp node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/
systemctl restart ceph-osd@6
6.2 OSD 启动后频繁重启
# 查看日志
journalctl -u ceph-osd@6 -f
# 常见原因:
# 1. 内存不足 - 检查 free -h
# 2. 网络问题 - 检查 ping 和 telnet
# 3. 时间不同步 - 检查 chronyc sources
# 4. OSD map 冲突 - 重置 OSD
# 重置 OSD(谨慎操作)
ceph osd out osd.6
systemctl stop ceph-osd@6
ceph osd purge osd.6 --yes-i-really-mean-it
# 然后重新创建 OSD
6.3 PG 长时间处于 recovering 状态
# 查看卡住的 PG
ceph pg dump_stuck recovering -f plain
# 查看具体 PG 详情
ceph pg 1.2 query
# 尝试修复
ceph pg repair 1.2
# 如果还是不行,可以强制标记为 clean(有风险)
ceph pg force_create_clean_pg 1.2
6.4 数据不一致
# 检查不一致的 PG
ceph health detail | grep inconsistent
# 执行 scrub 检查
ceph pg scrub
# 执行 deep scrub
ceph pg deep-scrub
# 修复不一致
ceph pg repair
# 查看修复进度
ceph -w
6.5 恢复速度过慢
# 检查网络带宽
iftop -P -n
# 检查磁盘 I/O
iostat -x 1
# 临时提高恢复速度(见 4.3 节)
ceph config set mon osd_recovery_max_active 10
ceph config set mon osd_recovery_max_single_start 5
# 检查是否有其他 OSD 故障
ceph osd tree
ceph health detail
---
七、预防措施和最佳实践
7.1 监控告警配置
# 配置 Prometheus + Grafana 监控
# 关键指标:
# - ceph_health_status
# - ceph_osd_up
# - ceph_osd_in
# - ceph_pg_active
# - ceph_pg_clean
# 配置告警规则:
# - OSD down 超过 5 分钟
# - PG 处于 recovery 状态超过 1 小时
# - 集群健康状态不是 HEALTH_OK
7.2 定期维护
# 每周执行
ceph health detail
ceph osd stat
# 每月执行
ceph osd scrub all
ceph osd deep-scrub all
# 每季度执行
ceph osd reweight-by-utilization
检查磁盘 S.M.A.R.T 状态
7.3 备份策略
# 定期备份
# 1. CRUSH map
ceph osd getcrushmap -o /backup/crush_map_$(date +%Y%m%d)
# 2. OSD map
ceph osd getmap -o /backup/osd_map_$(date +%Y%m%d)
# 3. MON map
ceph mon getmap -o /backup/mon_map_$(date +%Y%m%d)
# 4. 配置文件
cp /etc/ceph/ceph.conf /backup/ceph.conf_$(date +%Y%m%d)
cp /etc/ceph/ceph.client.admin.keyring /backup/
7.4 故障恢复预案
# 制定详细的故障恢复预案,包括:
# 1. 联系人列表
# 2. 恢复步骤检查清单
# 3. 备份恢复流程
# 4. 测试计划(定期演练)
# 5. 文档更新机制
---
总结
Ceph 15.2 节点关机 5 天后的恢复流程主要包括以下步骤:
- 恢复前准备 - 检查集群状态、备份配置、确认硬件正常
- 节点检查 - 时间同步、网络配置、Ceph 版本、磁盘状态
- 恢复 OSD - 标记 OSD 为 in、启动 OSD 服务
- 数据同步 - 监控恢复进度、调整恢复参数、数据平衡
- 验证收尾 - 验证集群健康、性能测试、恢复默认参数
- 故障排查 - 处理常见问题、记录恢复过程
关键注意事项:
- ✅ 确保时间同步(NTP)正常
- ✅ 确保 Ceph 版本一致
- ✅ 确保网络连通性正常
- ✅ 恢复前备份集群状态
- ✅ 在业务低峰期执行恢复
- ✅ 监控恢复进度,避免影响生产
- ✅ 恢复完成后验证数据一致性
通过正确的恢复流程,可以确保 Ceph 集群在节点故障后快速、安全地恢复正常状态。🚀
注:本文基于 Ceph 15.2.15 (Octopus) 版本编写。不同版本可能在命令和参数上略有差异,请根据实际情况调整。生产环境操作前建议在测试环境验证。
参考资料:
- Ceph 官方文档:https://docs.ceph.com/en/octopus/
- Ceph 故障恢复指南:https://docs.ceph.com/en/octopus/rados/troubleshooting/troubleshooting-osd/
- Ceph 运维最佳实践:https://docs.ceph.com/en/octopus/rados/operations/
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。





