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

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

背景

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

故障分析

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

[8349644.226151] Clock: inserting leap second 23:59:60 UTC
[8744049.152007] The scan_unevictable_pages sysctl/node-interface has been disabled for lack of a legitimate use case.  If you have one, please send an email to linux-mm@kvack.org.
[30940223.794815] python[28313]: segfault at 58 ip 00000000004aa8c7 sp 00007f2b44a2f560 error 4 in python2.7[400000+257000]
[42731185.176179] end_request: I/O error, dev vda, sector 12590864
[42731185.468491] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403168: block 1573613: comm updatedb.mlocat: unable to read itable block
[42731185.471307] Aborting journal on device vda1-8.
[42731185.472359] journal commit I/O error
[42731185.473183] EXT4-fs error (device vda1): ext4_journal_start_sb:327: Detected aborted journal
[42731185.474761] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.588205] EXT4-fs (vda1): Remounting filesystem read-only
[42731185.750067] end_request: I/O error, dev vda, sector 12590872
[42731185.751578] EXT4-fs error (device vda1): __ext4_get_inode_loc:3697: inode #403173: block 1573614: comm updatedb.mlocat: unable to read itable block
[42817852.384073] EXT4-fs (vda1): error count since last fsck: 4
[42817852.384077] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42817852.384081] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42904359.904061] EXT4-fs (vda1): error count since last fsck: 4
[42904359.904065] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42904359.904069] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614
[42990867.424056] EXT4-fs (vda1): error count since last fsck: 4
[42990867.424060] EXT4-fs (vda1): initial error at time 1517610339: __ext4_get_inode_loc:3697: inode 403168: block 1573613
[42990867.424064] EXT4-fs (vda1): last error at time 1517610340: __ext4_get_inode_loc:3697: inode 403173: block 1573614

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

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

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

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

相关文章：
【推荐】 如何用GO实现一个tail -f功能以及相应的思维发散
【推荐】 网易云复盘：云计算前端这一年（AngularJS粉慎入）
【推荐】 MySQL Group Replication数据安全性保障