集群有200余台虚拟机，运行在分布式文件系统mfs上。

现象：

1、每天凌晨0:10 ，出现批量虚拟机分区出现readonly问题，导致用户无法正常写入。

原因分析：

1、之前偶尔也会出现个别readonly的情况，没有深入排查，只是推测和chunkserver磁盘坏道有关，当vm读写正好在chunkserver坏道的块上时，可能出现报错，导致异常。2、此次出现大批量readonly，且监控和日志显示均是在凌晨出现，故排除磁盘坏道问题。3、如果虚拟机上承载docker 、mysql 等可能造成大并发的业务，也可能造成此类问题。但是虚拟机镜像在mfs上是连续的空间，正常的mysql读写并不会有问题。有出现在vm上进行批量docker容器删除时，出现异常的情况。4、推测有vm用户提交了大量并发的读写任务，而我们并未对虚拟机读写进行限制，也有可能造成此类问题。前期有vm出现load 90+ 报警,紧接着就有chunkserver出现load 100+的报警，和此问题非常类似。

排查定位：

1、检查宿主机负载、网络等，未发现异常情况。2、检查mfschunkserver ，发现有部分磁盘出现raid errro。3、检查mfschunkserver ，发现有一台chunkserver出现load +100，iowait达到90%以上的情况，带宽未见异常，写入的数据量也很低，现象大概持续3分钟左右。4、检查vm在凌晨的监控情况，发现批量机器出现iowait达到100%，流量、load均未见明显异常。有部分vm上有大量的sendmail进程。5、检查虚拟机上凌晨的crontab、进程等，没有发现异常。6、检查mfs上的读写情况，未见在凌晨有大量的 chunk create 和replica，但是 max operations in queue 值特别高。7、检查虚拟机备份程序，发现正好是在凌晨0:10进行备份，执行了snapshot操作，而且每台vm备份间隔仅1s，初步确认此备份为导致异常的主要原因。

由于snapshot操作并未带来大量的读写，之前并未关注到。在深入剖析了snapshot的原理，发现是执行了类似linux 系统的硬链接操作，此时批量的snapshot虚拟机，200台vm大概20TB，按照mfs的每个chunk块 64MB的划分，换算下来执行一次操作，会产生 2010241024/64 = 327680 创建链接的操作，每台vm备份也会产生1600次操作，如果在1s内没有完成，那么cpu队列就会越来越大，从而产生了load和iowait都非常高的现象。由于镜像备份并不是十分紧急的任务，故将间隔时间修改到60s执行一台。

可能造成虚拟机readonly故障的原因：

1、虚拟机备份进程的批量操作产生大量的并发，导致chunkserver 的cpu队列拥塞，产生vm读写出现iowait过高超时的情况，从而造成了磁盘remount为readonly的情况。故有此类批量操作的动作，一定要考虑并发负载的问题。 因为chunkserver是存储型服务器，cpu配置都比较低。

2、个别vm用户大量的提交任务导致后端异常。针对此现象，使用cgroug 进行io限制。可避免此类问题发生。

3、mfschunkser 规格建议配置一致，避免读写负载出现不均衡的情况。

此次定位问题耗时一周：

1、监控不到位，由于zabbix 进行大批量机器对比时，效率很低，临时部署了openfalcon和grafana，耗时较长。2、没有关注到备份任务，之前一致以为是vm用户的问题，但是通过监控定位并不是用户的问题。3、对mfs的snapshot未深入理解。

欢迎交流： QQ: 249016681