摘要：通常发生该问题的场景有二一云主机和宿主机繁忙，云主机的请求得不到及时的响应，从而产生磁盘错误，为了保护磁盘数据会分区为只读二云主机被强制关机，导致磁盘出现文件系统错误故障。
本文由作者朱益军授权网易云社区发布。
背景
维护巡检云主机时，发现有一台运行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.
[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、当前云主机的日志收集功能尚不完善，呈现的日志比较杂、乱、实用性不高，需要适当进行修改调整。另外，运维人员也不知道要收集哪些日志可支撑开发定位；
开发正在考虑开发一个一键式日志收集工具，集成到版本中，定期采集系统数据并归档，或者在发生故障时，由运维先收集分析，再交给开发定位，这样效率会高一些。
更多网易技术、产品、运营经验分享请访问网易云社区。
文章来源： 网易云社区
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/25323.html
摘要：执行容器内部运行的执行工作作为容器的执行驱动，负责创建容器运行命名空间，负责容器资源使用的统计与限制，负责容器内部进程的真正运行等。典型的在启动后，首先将设置为进行一系列检查然后将其切换为供用户使用。 在https://segmentfault.com/a/11... 容器，隔离，云的概述。这篇对其中用途广泛的docker,k8s做详细介绍，并给出云搭建的生态环境体系。 docker ...
摘要：执行容器内部运行的执行工作作为容器的执行驱动，负责创建容器运行命名空间，负责容器资源使用的统计与限制，负责容器内部进程的真正运行等。典型的在启动后，首先将设置为进行一系列检查然后将其切换为供用户使用。 在https://segmentfault.com/a/11... 容器，隔离，云的概述。这篇对其中用途广泛的docker,k8s做详细介绍，并给出云搭建的生态环境体系。 docker ...
摘要：为了满足在更多复杂场景科研攻坚时，对于超高性能算力高速网络传输海量数据存储的更高需求，再次发力，于近日推出了为科研量身定制的新一代超算产品，并将正式更名为云极高性能计算以下简称。科研是科技创新的基础，而高性能计算则是科研的基石。随着数字化走向纵深，科研教育进入信息化时代。在科研项目的推进过程中，往往会面对复杂的数据密集型计算任务，例如仿真、数据建模、渲染等大量运算场景。此时如果使用单一的通用...
摘要：为了满足在更多复杂场景科研攻坚时，对于超高性能算力高速网络传输海量数据存储的更高需求，再次发力，于近日推出了为科研量身定制的新一代超算产品，并将正式更名为云极高性能计算以下简称。科研是科技创新的基础，而高性能计算则是科研的基石。随着数字化走向纵深，科研教育进入信息化时代。在科研项目的推进过程中，往往会面对复杂的数据密集型计算任务，例如仿真、数据建模、渲染等大量运算场景。此时如果使用单一的通用...
阅读 2616·2021-09-28 09:36
阅读 2228·2021-09-07 09:58
阅读 1491·2019-08-26 13:53
阅读 1275·2019-08-23 17:53
阅读 3023·2019-08-23 15:34
阅读 1849·2019-08-23 15:34
阅读 2863·2019-08-23 12:04
阅读 3716·2019-08-23 10:56
