EN 正规买球app加入我们
典型案例
您现在的位置:首页 > 典型案例
【合法买球平台】ceph集群异常处理报告

一、故障描述


客户反馈一套Openstack+ceph的超融合集群由于异常断电导致ceph状态异常,虚拟机无法启动。


最初的告警如下:


1.png

查看OSD状态如下:


2.png

3.png

二、报错现象

将Down掉的osd移除并等待Recovery一天后,集群仍旧有以下告警,需逐步排查问题并修复。

1. ceph -w 命令的输出中看到集群状态仍为HEALTH_ERR。

4.png

对上面报错解释如下:

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集群的元数据服务器,它们的宕机可能会影响集群的元数据一致性和健康状态。


三、处理过程

  1. ceph osd tree 输出显示osd都是up状态

5.png


2. ceph health detail输出

6.png

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正在等待恢复被调度执行

7.png

官网参数介绍:

如果集群丢失了一个或多个对象,并且您决定取消搜索丢失数据,您必须将未找到的对象标记为 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上所以没办法删除,且只有一个副本,主副本都丢失。

8.png

5. 修复可以repair的pg

下面这些pg除了不是在osd.28上面的通过ceph pg repair pgid进行修复。

9.png

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即可。

10.png

ceph -s 查看集群状态

此时集群正在做recovery,再一次执行ceph pg 10.25b mark_unfound_lost revert发现unfound object已经没有了

但是有部分虚拟机还是无法启动,大量的misplaced的pg,应该是之前osd有问题时造成的,正在做重新平衡和恢复,只能等待集群recovery。


11.png

四、问题解决

经过了一天的recovery后,继续对以下的pg再次进行ceph pg repair pgid后正常

12.png

测试虚拟机可以正常启动,问题处理完毕。



版权所有 正规买球app 备案号:京ICP备17074963号-1
技术支持:创世网络