《构建高可用Linux服务器 第3版》—— 2.5 紧急处理线上服务器故障的办法-阿里云开发者社区

开发者社区> 华章出版社> 正文
登录阅读全文

《构建高可用Linux服务器 第3版》—— 2.5 紧急处理线上服务器故障的办法

简介:

本节书摘来自华章出版社《构建高可用Linux服务器 第3版》一 书中的第2章,第2.5节,作者:余洪春 ,更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.5 紧急处理线上服务器故障的办法

很多时候,网站或业务系统的服务器出现了故障,我们必须紧急修复,保证网站或业务系统能够使用。一般我们会遇到哪些系统故障,又该如何来处理呢?接下来逐个分析。

2.5.1 更改Administrator密码导致计划任务无法执行

问题描述:公司有位系统管理员离职了,他曾负责管理多台Windows Server 2003服务器,于是负责安全的部门要求接手的系统管理员更改Administrator密码,粗心的系统管理员急急忙忙地更改了Windows Server 2003的Administrator密码,却发现Windows Server2003的计划任务(即Scheduled Tasks)全都执行不了,出现这个问题其实是因为Windows Server2003的计划任务都要求输入正确的Administrator密码。

解决办法:大家养成好习惯,每次更改完Windows Server 2003密码后一定要检查一下计划任务能否正常执行,否则很容易导致公司的重要业务执行不了,进而影响整个网站的运维及业务,希望此问题能引起大家的注意。

2.5.2 CentOS 5.8的root密码被恶意篡改

在公司的内部CentOS 5.8开发机器下,用户基本都是由su-切换到root,不过这时有一个问题,假如多人知道root的账号和密码,那么如果出现问题,你就不知道到底是谁干的坏事,日志里记录的都是root干的。新上架的开发服务器的root密码就曾被开发人员乱改。其实,这时候可以给他们的账户分配sudo权限,这样就可以通过log或last等命令查询开发人员做的事情了。

实际部署:我们可以建立一个admin组,让这个组的用户权限和root一样。我们的某开发小组有4个开发人员正准备使用新添置的开发服务器,我们可以准备给每一个开发人员分配一个账户,密码由他们各自保管,以后考虑将权限细化分配。具体步骤如下。

1)修改sudoers文件,即/etc/sudoers文件(执行visudo命令效果一样),在最后加入以下内容:

%admin ALL=(ALL) ALL
2)添加admin组,命令如下:

groupadd admin
3)添加用户,这里添加4个用户,分别对应4个开发人员,添加命令如下:

useradd yuhongchun

useradd wangxiaona

useradd zhanghua

useradd tangyihe
密码均由4个开发人员自己设置和保管,相互之间不知道对方的密码。

4)添加用户到admin组,命令如下:

usermod -a -G admin yuhongchun

usermod -a -G admin wangxiaona

usermod -a -G admin zhanghua

usermod -a -G admin tangyihe
这样每个开发人员就都有sudo权限了,而每个用户所做的事情基本可以通过日志查询到。注意:以上操作只适应于开发或测试环境,线上机器为了安全考虑,不建议分配具有sudo权限的用户。

2.5.3 bash文件损坏该如何正确处理

故障描述:在IP为192.168.21.36的FreeBSD 8.1 x86_64机器上安装软件时不小心将其依赖的库文件libintl.so.8丢失了,导致所有以bash为基础的shell用户不能登录。由于大家都喜欢在此机上用bash,所以均将其配置成了默认的shell,也就是说所有的用户都不能登录了,系统报错如下:

/libexec/ld-elf.so.1: Shared object "libintl.so.8" not found, required by "bash"

Connection to 192.168.21.36 closed.
解决方法如下所示。

1)用单用户模式进入系统;

2)扫描磁盘(此步操作是安全的),命令如下:

fsck -y
3)将文件系统重新挂载,命令如下:

mount -a
4)将root的默认shell切换到sh,命令如下:

chsh -s sh
5)其实进行到第4步,我们就可以用root以sh模式进入系统了,但为了完美解决问题,这时候可以安装一下bash,命令如下:

pkg_add -r-v bash
重启后一切正常,故障排除。

2.5.4 正确操作nohup让程序始终在后台运行

我的Nginx负载均衡器监控Nginx进程的脚本nginx_pid需要放入后台不间断运行,所以想用命令/bin/sh /data/nginx_pid.sh &来达到此目的,在输入完命令后我就关闭了终端,可再次登录终端时发现此程序并没有运行。忽然想起可能是因为没有使用nohup命令,试了试,果然如此,在带上nohup命令后就正常了。

我们的很多程序只是普通的程序,即使它们以&结尾,如果终端关闭,那么程序也会被关闭。为了能够在后台运行,我们需要使用nohup这个命令,原程序的标准输出被自动改向到当前目录下的nohup.out文件里,起到了log的作用。

但是有时候这样做会有问题,如果把终端关闭,进程也会被自动关闭,查看nohup.out可以看到在关闭终端的瞬间服务自动关闭了。

产生此问题的原因是:虽然Shell中提示了nohup成功,但还是需要按终端上的键盘任意键退回到Shell输入命令窗口,然后通过在Shell中输入exit来退出终端,而不是每次在nohup执行成功后直接关闭终端。这个问题很多朋友容易忽视,希望大家在工作中多加注意。

2.5.5 Nginx负载均衡器出现故障

在主Nginx负载均衡器上,由于nginx.conf配置文件有误,导致客户不能正常访问网站。网站架构用的是Nginx+Keepalived,这时我们可以紧急停掉主Nginx上的Keepalived,让从机接管;等网站稳定后,再来修复主Nginx负载均衡器。

注意 其实单纯停掉Nginx是解决不了问题的,因为我们的VIP此时还挂在主Nginx上面,要让从Nginx生效,停掉主Nginx上面的Keepalived是最好的方法(这个从Nginx机器就会将VIP地址接管过来)。

总而言之,线上环境的服务器排障要求我们在最短的时间内解决问题,这其实也是对系统管理员经验和能力的要求。我们平时应该总结在线上环境中容易出现的故障,做到未雨绸缪;平时在维护网站或系统时应该着重注意容易Crash的部分,多花些精力和时间在系统日志或服务日志上面,如果觉得压力过大,单机负载承受不了,可以考虑采用集群的方法来处理。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

华章出版社

官方博客
官网链接