九台nosql同时宕机故障

2015年3月17日 发表评论 阅读评论

一、故障现象

3月16号22:20分左右,手机收到现网主机的宕机拨测短信告警。收到宕机短信本属正常,现网业务有二千多台 server 难保其中哪台不出问题。可是还未能赶着打开电脑,紧接着同一时间又是8台主机的宕机短信。未查看工程文档核对主机之前,猜测怀疑是某一刀框出了问题,导致同一机框内的所有刀片不能服务。不过等查看过第一台以后,发现是pc server ,另外8台和第一台是同一业务下的另外几个节点。

二、处理过程

1、先是登录其他主机,ping 该主机的业务网口,发现是通的。松了一口气,以为是误告警。不过ssh 进行跳转时,报没有权限。连试三台都这样。

2、通过ILO4 远程管理口查看,并使用用户名密码登录,发现如下报错:

User not known to the underlying authentication module

under-auth

网上查询了下,该报错一般是由于/etc/passwd和/etc/shadow 内容不同步导致,需要通过pwconv进行同步。不过对网上的这个结果感到怀疑,不可能同时9台都出这问题啊。由于当晚业务侧有升级操作,这时候也由同事协调问业务侧是不是做了什么操作。同时问下负责自动化相关人员是否有什么操作。(此时已经怀疑人为的可能性比较大,后来得的结果是没有人进行操作。)

3、和相关人员沟通完想法后,先将其中一同进入到单用户下进行pwconv 文件同步。重启主机时,又报别一个错:

libselinux.so.1: cannot open shared	object file: Permission denied

libselinux-deny

4、由于SUSE下没有selinux,对这个摄氏感觉很奇怪,不过还是重新进入单用户,find到了libselinux.so.1文件,并和正常系统下的该文件进行权限比对。发现并无不同,同时又查看了各主用户的家目录下的环境变量文件、/etc/profile、bashrc文件、家目录的权限等。都未发现异常。同时又尝试新建了一个test并启,再次重启,发现还是停留在步骤3中的界面。通过其他主机ssh test用户,报错内容同步骤1的报错。

5、以上操作已经过去了1个多小时(此九台主机相当核心),此时手机一边电话会议,另一个手机已经被各路领导打爆。其中一些指令执行时已经没时间查看结果,只能不停的向各路领导汇报同样的结果。--- 该时间段有人提到过查看history 记录,执行未细看就又开始接电话。未细看的原因也因为对此未报希望,平时有相关厂家会进行使用工具定期扫描、加固、抓取数据等操作,认为很可能history记录已被覆盖。

6、拉上了SUSE原厂人员,并简单报了下情况。另一同事到达机房现场同业务侧相关人员在对另外一台主机操作是,有了新进展,在执行chmod 777 / 后,主机启动成功---- ,好暴力的感觉 。将该情况也反馈给了SUSE 二线人员 。此时二线人员进入单用户后,进入根目录,立即发现了一个问题,lib、lib64、etc等目录都变成了600权限-----好犀利,之前怎么就没想到先看看根目录呢?

问题主机的根目录:

root

正常主机的根目录:

root2

7、修改完成后,重启主机,进入系统正常。

三、根因定位

1、histroy记录

查看在故障发生时间点之前有进行过大量chmod 600 操作,这点和单用户查看到很多目录是600权限对应。以下为部分截图:

histroy

2、last记录

经查看ts_user用户(从10.211.94.198登录)的用户从21:11登录到主机发生crash时一直登录在主机上

last

3、message日志

message日志里在故障发生前,也发现有ts_user用户在22:14:16有su切到root的操作(而且使用的也是/dev/pts/6)

message

通过查看9台主机的操作记录,都存在相同的histroy记录、ts_user用户登录和su操作(故障发生时间点之前几分钟内)。

4、在9台主机上也通过echo $变量名 ,发现history记录中的部分变量是不存在的。导致前面一部分被解析成空,例如如下:

[root@361way ~]# ls $ABC/
bin  boot  data  data1  dev  download  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var

在我的测试机中不存在变量$ABC ,所以$ABC被解析为空,这里执行ls  $ABC/ 的结果相当于执行成了 ls  / ,同样,上面的chmod操作中,不存在的变量执行后的结果可想而知。

四、经验教训

1、通过相关日志定位和IP地址定位到了业务侧误操作的人员。所以第一教训是:诚实,做了误操作要勇于承认,如果当初把情况描述清楚,问题会提早很多完成修复。带来的损失也是最小的。

2、遇到问题要学会寻找帮助。目前的环境所能寻求的资源相当多,由于之前在"小作坊" 似的企业做惯了思维定式的运维,未能及时想到寻求帮助。这里也很感谢公司领导最后给提供的资源。

3、戒骄戒躁,注意最普通的地方。同时N个领导来问情况,大的压力下可能会打乱正常的思维方式,这里有两次可以发现问题的机会,一次没抓住,一次没想到。如果最早细看histroy记录,肯定能发现问题,和权限和环境相关的地方都考虑到了,根目录忽略了。

4、暴力方法有时可取,chmod 777 /解决了一部分问题,后面启动后部分文件无权限时,被现场的兄弟来了个更暴力的操作---直接加-R递归了所有文件的权限。虽然看起来不专业,不过临时可以将业务恢复。后面无非麻烦的就是要重装过。但相对损失也是小的。无非平常不做这一部是存在安全隐患,不过重装后,隐患也就不存在了。




本站的发展离不开您的资助,金额随意,欢迎来赏!

You can donate through PayPal.
My paypal id: itybku@139.com
Paypal page: https://www.paypal.me/361way

分类: Linux/unix/mac 标签:
  1. Penn.Gregory
    2015年4月3日17:03 | #1

    真是一个有意思得故障排错,冲着博主分享精神和坚韧不拔,果断捐助。

    • admin
      2015年4月3日17:31 | #2

      感谢支持,需要学习的东西还很多。呵呵!

  2. xyz
    2015年4月27日08:51 | #3

    感谢分享实战经验,博主加油。

  3. Liao
    2015年6月14日18:04 | #4

    建议在脚本中加上 set -u 选项,检测脚本中变量是否赋值,对于未赋值的变量不予通过,如果执行命令中的变量未赋值命令将直接报错而不会执行。

  1. 本文目前尚无任何 trackbacks 和 pingbacks.