一次升级线上服务器内核的经历
服务器 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 权重调回来。
就不再动了，刚好把现在的做成一个高可用！
|