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

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