mfs1.6.x故障一例,血的经验教训 推荐

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: mfs集群故障报告故障描述:    从2017年3月8日04:20--2017年3月8日06:20期间,调度系统mfs集群出现故障,导致无法正常使用。造成承载的虚拟机业务出现大批量的ping告警,同时影响到凌晨调度系统正常运行。

mfs集群故障报告

故障描述:

    从2017年3月8日04:20--2017年3月8日06:20期间,调度系统mfs集群出现故障,导致无法正常使用。造成承载的虚拟机业务出现大批量的ping告警,同时影响到凌晨调度系统正常运行。造成4点-6点间调度任务失败和虚拟机无法正常使用。

 

故障原因分析:

    对故障期间的系统日志记录进行查看和分析,发现以下异常信息:

1、所有的mfschunkserver互连时候出现大量超时的情况。

2、mfs挂载点只能读,不能写。

3、4点左右mfschunkserver出现cpu wio过高的情况

 

4、mfsmaster机器硬件故障----------查看dmesg信息,未发现有异常。

5、mfsmaster日志信息 ----------- 查看/var/log/message,未见异常报错

 

故障排除:

    1、由于出现mfs集群读写异常的情况,初步判断可能是mfsmaster异常造成。故计划重启mfsmaster,由于调度系统mfs集群使用的hearbeat和drbd构建的master双机。在确认备用master服务器正常后,进行了切换操作。

    mfsmaster未能正常启动,通过日志发现是由于metadata文件异常导致无法读写。随后切回主节点时,主节点也无法正常启动,报错原因同上。

    metadata是mfs集群中存储chunk块的元信息,损坏后会导致master无法正常读取到chunk块信息,从而无法正常启动。

   

    2、mfs官方提供了metadata的修复工具mfsmetarestore工具,使用此工具能进行metadata数据异常的修复。在完成相关文件备份后,使用mfsmetarestore –a 进行了metadata的自动修复。修复完成后,master恢复正常启动。与6点28分,开始mfs集群恢复正常使用。

 

    3、通过监控发现,在4点20分左右,10.39.3.87mfschunkserver出现swap跑满的情况,导致该chunkserver无法正常使用,影响了部分chunkserver与其进行块复制和读写。造成到mfs集群正常使用。10.39.3.87无法正常登陆,重启后恢复正常。(由于mfsmaster重启,对mfs集群造成影响的10.39.3.87连接断开,mfs集群暂时恢复正常。)

   

 

    如上所述,影响到mfs集群正常运行的主要原因是由于10.39.3.87导致了大量读写超时的情况,对调度系统、虚拟机业务造成很大影响。3.87上承载部分虚拟机业务,前期出现过由于虚拟机负载过高导致宿主机swap被耗尽,导致无法正常使用的情况。

 

 

 

   

整改措施:

1、升级mfs版本,进行优化

2、升级操作系统版本

3、升级kvm,控制虚拟机的过度使用

4、增加宿主机内存,降低单个虚拟机内存

 

 

 

后续故障:

    经过1天时间后,发现mfs元信息存储目录出现空间不够告警。检查发现changelog文件不轮转。一直都写在changlog.0.mfs中。导致文件都达到60G 。

   

查看元信息目录发现:

***@***.***mfs]# ll -h

-rw-r-----1 mfs mfs 177M Mar 9 15:20 bak.changelog.0.mfs

 -rw-r----- 1 mfs mfs 673M Mar 8 05:27bak.metadata.mfs.back

 -rw-r----- 1 mfs mfs 4.0G Mar 9 20:18changelog.0.mfs

-rw-r--r--1 mfs mfs 845M Mar 9 15:27 metadata.mfs.back

-rw-r-----1 mfs mfs 854M Mar 8 05:24 metadata.mfs.back.tmp

 -rw-r----- 1 mfs mfs 530M Mar 9 15:21metadata.mfs.emergency

 -rw-r----- 1 mfs mfs 22K Mar 9 19:59sessions.mfs

 -rw-r----- 1 mfs mfs 745K Mar 9 20:00stats.mfs

 

      默认changelog是1小时轮转一次,并将log信息合并到metadata中。查看master的日志信息/var/log/message发现:

Mar 9 20:00:00 yz381 mfsmaster[9276]:previous metadata save process hasn't finished yet - do not start another one

    每小时均是如此,所以一直没办法成功轮转。

    此时没有metadata.mfs.back文件(mfs运行时的元信息文件),也没有metadata.mfs 文件(mfs停止时的元信息文件)。文件变成了metadata.mfs.back.tmp,  经过与mfs社区联系,确认此文件为1.6版本bug,由于mfsmaster主备切换过程中产生了异常,导致了metadata.mfs.back.tmp文件产生。changelog轮转时候发现此文件存在,所以觉得有异常,不进行轮转。将此文件改名后,到整点的时候,changelog 正常开始轮转。一切恢复正常。


    经与社区沟通,此bug在新版本2.x之后已经修复。



    教训:  

      mfs集群出现故障,先检查mfsmaster、chunkserver、client日志,定位好故障的主要原因后再去处理,此次故障是由于单台的chunkserver的swap用完,导致chunkserver之间的块复制出现大量超时的情况,影响在mfs上运行的业务。并不是mfsmaster异常导致。最主要的还是看日志,根据日志来排查,不要盲目推测。


      另外主备切换过程需要非常谨慎小心。出问题会很严重。



      欢迎mfs使用者一起交流沟通:

         QQ  249016681


目录
相关文章
|
1月前
|
监控 Linux Shell
"揭秘!一键掌控Linux服务器健康的秘密武器——超实用系统检查脚本,让你的服务器稳如老狗,告别宕机烦恼!"
【8月更文挑战第14天】服务器宕机或资源耗尽会严重影响业务。为此,你需要一个Linux系统检查脚本来守护服务器健康。它可以自动检测潜在问题如磁盘满载、内存泄漏等,避免服务中断。脚本应包括磁盘空间、内存/CPU使用、系统时间准确性、关键服务状态及系统日志分析等检查项。通过编写并定期运行这样的脚本,可以显著提高服务器的稳定性和可靠性。
33 1
|
4月前
|
Shell Python
概率分析:为什么葫芦娃救爷爷是一个一个地救成功率最高?
概率分析:为什么葫芦娃救爷爷是一个一个地救成功率最高?
113 0
|
4月前
|
缓存 Java 关系型数据库
踩了定时线程池的坑,导致公司损失几千万,血的教训
踩了定时线程池的坑,导致公司损失几千万,血的教训
|
运维 安全 关系型数据库
Linux运维常见故障及处理的 32 个锦囊妙计
Linux 运维 常见故障及处理的
310 0
|
存储 Linux
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
翻车!误删/usr/lib/引发的血案,从棺材边成功抢救的过程分享。
|
存储 Kubernetes 应用服务中间件
《k8s 集群搭建》不要让贫穷扼杀了你学 k8s 的兴趣!
本文主要介绍 kubernetes集群的搭建
459 0
|
消息中间件 分布式计算 监控
RabbitMQ 线上事故!慌的一批,脑袋一片空白
1.什么是kafka Kafka是分布式发布-订阅消息系统,它最初是由LinkedIn公司开发的,之后成为Apache项目的一部分,Kafka是一个分布式,可划分的,冗余备份的持久性的日志服务,它主要用于处理流式数据。 2.为什么要使用 kafka,为什么要使用消息队列 缓冲和削峰: 上游数据时有突发流量,下游可能扛不住,或者下游没有足够多的机器来保证冗余,kafka在中间可以起到一个缓冲的作用,把消息暂存在kafka中,下游服务就可以按照自己的节奏进行慢慢处理。 解耦和扩展性: 项目开始的时候,并不能确定具体需求。消息队列可以作为一个接口层,解耦重要的业务流程。只需要遵守约定,针对数据
RabbitMQ 线上事故!慌的一批,脑袋一片空白
电脑主板最易故障
电脑主板最易故障
125 0
|
存储 运维 监控
十条运维经验,帮你远离故障
1. 确保变更可以回滚 佛说:“每次创伤都是一次成熟”。这是运维人员的真实写照。从某种意义上讲,运维是一份不断犯错、不断积累经验的工作。以前没有经历的东西,总是不定期的给你痛击。所以请保护好变更的现场,使得变更有回头的机会。
1101 0
日常环境莫名宕机的处理
## 背景 11.21 早上 pd 给讲法务评审的时候,操作日常环境,莫名就 down 机了,而且 pd 反馈经常会这样。(ps : pd 反馈系统请求时间过长,性能很差,后续也会排查解决) 于是排查了一下系统 down 机的原因 ## 原因 查看内存 setenv.sh 设置 if [ $memTotal -le 2048 ]; then SERVICE_OPTS="${SE
1271 0