勿忘初心

个人签名

530篇博客

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

勿忘初心2018-12-11 16:26

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


背景

   维护巡检云主机时,发现有一台运行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数据安全性保障