云主机文件系统readonly处理案例

Answer 1

本文由作者朱益军授权网易云社区发布。

背景

   维护巡检云主机时，发现有一台运行redis的云主机状态显示维护中，登录该实例查看，系统盘变成readonly。本文简单分析该问题出现原因，并为运维人员提供常见处理方法及建议。

故障分析

    查看云主机dmesg信息发现，系统运行过程中python进程发生segfault，随后vda（云主机配置virtio-blk，故盘符显示为vda）系统盘I/O error。

  基本可确定是业务把系统盘写坏了。通常发生该问题的场景有二：

  一、云主机和宿主机IO繁忙，云主机的IO请求得不到及时的响应，从而产生磁盘IO错误，为了保护磁盘数据会remount分区为只读；

  二、云主机被强制关机，导致磁盘出现文件系统错误故障。

故障处理

    通常的解决方法是重启系统以root用户进入单用户模式， 运行fsck.ext3 –y /dev/vda（如果是ext4使用fsck.ext4修复），/dev/vda是系统/根分区。修复完reboot进入系统。以debian系统为例：

  1、重启系统，grub菜单会出现正常启动和修复模式（ recovery mode ）启动两个菜单项，选择修复模式启动；

2、进入修复模式，运行fsck工具修复；

  3、重启进入正常模式启动。

  

  注意：

  1、运维人员在重启云主机之前尽量先收集一些关键的日志，如/var/log下面的一些日志、dmesg等，有条件也要收集宿主机的日志；

  2、fsck是Linux内核自带工具，它不仅可以对文件系统进行扫描，还能修正文件系统的一些问题。 fsck扫描文件系统时一定要在单用户模式、修复模式或把设备umount后进行。建议在单用户模式下运行。如果扫描正常运行中的系统，会造成系统文件损坏,需要root权限执行。

建议与思考

  1、当前开发要定位问题，需要申请宿主机权限等流程，无法及时上去定位；

  2、当前云主机的日志收集功能尚不完善，呈现的日志比较杂、乱、实用性不高，需要适当进行修改调整。另外，运维人员也不知道要收集哪些日志可支撑开发定位；

  开发正在考虑开发一个一键式日志收集工具，集成到版本中，定期采集系统数据并归档，或者在发生故障时，由运维先收集分析，再交给开发定位，这样效率会高一些。

更多网易技术、产品、运营经验分享请访问 网易云社区 。

相关文章：
【推荐】  网易云易盾发布多国家多语种内容安全服务，助力中国互联网出海
【推荐】  Spring-Boot自定义Starter实践
【推荐】  一文带你了解 Raft 一致性协议的关键点