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 天后的恢复流程主要包括以下步骤:

  1. 恢复前准备 - 检查集群状态、备份配置、确认硬件正常
  2. 节点检查 - 时间同步、网络配置、Ceph 版本、磁盘状态
  3. 恢复 OSD - 标记 OSD 为 in、启动 OSD 服务
  4. 数据同步 - 监控恢复进度、调整恢复参数、数据平衡
  5. 验证收尾 - 验证集群健康、性能测试、恢复默认参数
  6. 故障排查 - 处理常见问题、记录恢复过程

关键注意事项:

  • ✅ 确保时间同步(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/

发表回复

后才能评论