一次升级线上服务器内核的经历
服务器kernel版本过低,需要进行补丁升级,事实上升级的操作非常简单,也就那么一步两步搞定的问题,但是由于是对线上服务器进行的操作,因此不能鲁莽操作,要让其服务平稳过度才行。
于是,今天说起来是记录升级的,事实上却是要记录一下线上服务平稳过度的一些操作与注意事项的。
先来说明一下之前的情况是怎样的(事实上是有问题的,等下也会说明这个问题的原因)。
最最开始,这项服务事实上只有一个serverA的,这当然是非常有问题的,但是在没有出现问题以及没有强烈意识的情况下,有些问题始终也就不算问题。终于有一天,serverA因为一些原因(这个原因又是非常不应该的,即因服务器上其他服务日志突然增大,爆满之后直接影响到这个服务down掉了,这可是线上业务,影响当然是不小的。但是以前就是这么过来的,有那么一种原生的野性与鲁莽吧,你可以说这是一种无知或者懒惰,但是,某些规范化的章程还不完善,或者说某些创伤还没有出现,总是感觉不到痛痒,也就无从痛而后勇的。),终于要一变二起来。
变二也是非常简单的,新开一台服务器,部署上一样的服务,每台服务器上都添加nginx的代理解析,然后再在前端通过SLB进行负载分发,但有一个问题阻碍了这种想法。
原来serverA服务在阿里云上,现在进增加的服务器是从公司托管的机房里边开出来的一台机器,于是乎,之前想的用SLB的方案就破裂了,最后只是把两台服务都部署起来,然后通过nginx的一个负载方案,做了一个流量的分发,而并没有所谓高可用。
现在,就是在这样的一个现实情况下,要对这台服务器进行升级重启,而不能够影响到线上服务。
方法可能有很多,我今天用的方法如下,方法也简单,问题是里边有一些细节需要注意到。
# 1, 首先通过另一服务器配置nginx流量分发。
将本服务器上的nginx配置复制到另外一台服务器的nginx上去,注意,要暂时将本机的解析中的upstream删除,即暂时把将要重启的本机从负载当中踢出,把所有流量先全部放到另外那台serverB上去。
# 2, 然后创建一个SLB对两台nginx进行负载。
a) 首先新建负载均衡。
b) 然后进入到负载均衡详情当中添加端口的监听(443)。
c) 然后将后端两台nginx服务器添加进来。
d) 注意
要再去两台nginx服务器当中配置安全组(白名单)放开刚刚SLB的外网ip对本机的443端口的访问
e) 注意
添加两台服务器的时候,暂时先将另一台nginx的权重设置为0.
# 3,添加对应域名解析
去到解析配置界面,将刚刚服务器域名的解析资源记录更改成刚刚SLB的ip。
那么,此时的架构应该是这样的。
正如图中所见,就像接的水管一样的,掐住一头,另外一头接着流,并不影响水流一样。
现在需要掐住serverA上nginx这根管子,今天的操作是直接掐了,这样有可能导致问题。
为了避免一些不确定因素出现,有必要首先在内网做一些测试检验:
1, 在阿里云服务器内网中找一台服务器,将服务对应的域名以及另一台服务器上的nginx的ip写入服务器的hosts当中,然后直接本地curl -I 域名 进行访问验证,这一层是验证另一台的nginx到serverB上是否可用,毕竟等下是要干掉serverA的。看到返回200,则说明正常。
2, 然后启动另一台上的nginx。
3, 此时,服务器上监控nginx的日志输出,另一边SLB可以把这台服务器权重给调成0,看是否有流量过来。如果有流量进来了,则说明这一条线是可用的。
4, 实操,关权重,重启。
既然可以使用了,那么来到SLB,把serverA的权重调成0.此时看到serverA上监控的日志已经渐渐不刷了,而新的nginx则忙碌起来。
此刻,迅速做一些操作:
yum update kernel -y
shutdown -r now
2
连接上以后,将对应的服务跑起来。
然后再重新把SLB权重调回来。
就不再动了,刚好把现在的做成一个高可用!