一、故障描述
客户反馈一套Openstack+ceph的超融合集群由于异常断电导致ceph状态异常,虚拟机无法启动。
最初的告警如下:
查看OSD状态如下:
二、报错现象
将Down掉的osd移除并等待Recovery一天后,集群仍旧有以下告警,需逐步排查问题并修复。
1. ceph -w 命令的输出中看到集群状态仍为HEALTH_ERR。
对上面报错解释如下:
729061/36742527 objects misplaced (1.984%)有729,061个对象被错误地放置在了不合适的OSD上,占集群中所有对象的1.984%。
67/12247509 objects unfound (0.001%)有67个对象无法找到,占集群中所有对象的0.001%。这通常表示数据丢失,可能是由于OSD损坏、硬盘故障或配置错误导致的。
74 scrub errorsScrub是Ceph中用于数据一致性和完整性检查的过程。这里报告了74个错误,表明在数据扫描过程中发现了不一致或损坏。
14 pgs recovery_unfound, 39 pgs inconsistent在恢复过程中,有14个PG找不到,且39个PG状态不一致。
47746/36742527 objects degraded (0.130%), 14 pgs degraded, 3 pgs undersized有47,746个对象的数据冗余度降低(即副本数量不足),占所有对象的0.130%。此外,有14个PG处于降级状态,3个PG大小不足。这通常是由于OSD故障或配置问题导致的。
37 slow ops, oldest one blocked for 138041 sec, daemons[osd,10,osd.11,osd.28,osd.29,osd.35,osd.47,osd.9] have slow ops集群中有37个操作运行缓慢,其中最慢的一个操作已被阻塞了138,041秒。这些操作涉及到多个OSD守护进程(daemons),表明这些OSD可能存在性能问题或资源争用。
1/3 mons down, quorum controller0l,controller03集群中有3个监控节点(mon),但其中1个已经宕机。当前quorum(即有效的监控节点集合)包括controller0l和controller03。监控节点是Ceph集群的元数据服务器,它们的宕机可能会影响集群的元数据一致性和健康状态。
三、处理过程
ceph osd tree 输出显示osd都是up状态
2. ceph health detail输出
3. OBJECT_UNFOUND 修复过程
先对OBJECT_UNFOUND的14个pg进行处理
(1)通过ceph pg 10.34d mark_unfound_lost delete命令进行删除
(2)删除后发现59/12247510 objects unfound (0.001%),执行后与之前相比少了7个变成59个
(3)另外13个pg也按照此方法进行删除
删除后的状态如下:
可以看到10.34d这个pg的状态为active+recovery_wait+degraded
PG正在等待恢复被调度执行
官网参数介绍:
如果集群丢失了一个或多个对象,并且您决定取消搜索丢失数据,您必须将未找到的对象标记为 lost。
如果查询了所有可能的位置,并且对象仍然丢失,您可能需要放弃丢失的对象。这是可行的失败组合,允许集群了解在写入本身恢复之前执行的写入操作。
目前唯一支持的选项为 "revert",该选项可回滚到对象的旧版本,或者完全忘记了它(如果它是新对象)。要将 "unfound" 对象标记为 "lost",请执行以下操作:
ceph pg PG_ID mark_unfound_lost revert|delete
风险提示:
谨慎使用此功能,因为它可能会混淆预期对象存在的应用程序。
4. 解决osd阻塞问题
通过之前的repair修复发现,osd,10,osd.11,osd.28,osd.29,osd.35,osd.47,osd.9这几个osd上面的pg通过repair修复不成功。
通过systemctl restart ceph-mon.target命令将集群的mon服务重启后发现由原来的osd,10,osd.11,osd.28,osd.29,osd.35,osd.47,osd.9只剩下osd.28这一个阻塞,但是有个pg 10.25b正好在这个osd.28上所以没办法删除,且只有一个副本,主副本都丢失。
5. 修复可以repair的pg
下面这些pg除了不是在osd.28上面的通过ceph pg repair pgid进行修复。
6. 修复 unfound object
Pg 10.208修复
10.208在osd.28和osd.40上,10.25b只有在osd.28上面
执行如下,将osd踢出集群后加入集群后发现10.208 已经写在其他osd上面。
systemctl stop ceph-osd@28.service
ceph osd out 28
ceph osd in 28
执行如下进行回退:
ceph pg 10.208 mark_unfound_lost revert
ceph pg 10.25b mark_unfound_lost revert
日志如下:
只有10.25b有问题,现在只需要在继续处理这个10.25b即可。
ceph -s 查看集群状态
此时集群正在做recovery,再一次执行ceph pg 10.25b mark_unfound_lost revert发现unfound object已经没有了
但是有部分虚拟机还是无法启动,大量的misplaced的pg,应该是之前osd有问题时造成的,正在做重新平衡和恢复,只能等待集群recovery。
四、问题解决
经过了一天的recovery后,继续对以下的pg再次进行ceph pg repair pgid后正常
测试虚拟机可以正常启动,问题处理完毕。