关于服务器业务整体迁移到另一个机房的方案

公司业务包含mysql，redis，mongodb，rabbitmq，es这些中间件

服务部署采用k8s集群，项目流水线使用的是自建的gitlab-runner，网络打通使用的是openvpn

迁移方案

1.阿里云数据dts建立mysql，mongodb的双向同步关系（当然像redis啥的也可以建立，我们的业务在redis中大部分存储的是验证码还有一些锁，在流量低谷期迁移过去问题不大，所以数据选择直接抛弃）

2.es不同步过来，因为业务本身自带刷es数据的逻辑，所以搬迁到新的机房后再刷一次es数据基本问题不大

3.网络打通，新的服务器安装openvpn，开放公网

4.k8s搬迁（由于我们的整体搬迁时间太短，整个k8s去安装集群，监控，日志这些插件时间上来不及），我们选择的是老机房导出镜像，新的服务器导入镜像，直接整体迁移

5.找一个流量低谷期迁移网关

每个环节遇到的问题，和解决方案

数据同步环节在建立同步关系后发现并不是双向同步，在全量以后才发现，这个问题给阿里提工单，那边的后台人员会帮你开通建立双向同步的权限

es这一块，由于老的采用的是云服务，新的是自建的，中间缺少分词插件导致刷数据出现问题，最终的解决方案是将插件目录挂载到服务器上，然后把插件赋值到对应的容器目录重启es容器即可解决问题

网络打通这块，是所有工作的第一个环节，首先第一步就要购买一台低配ecs，安装好vpn，配置好路由，使用vpn代理整个服务器网络，基本没遇到什么问题，就是哪个ip段需要代理在openvpn的server.conf中最后加入需要代理的网段就好了

k8s整体迁移，这个是遇到问题最多的，第一个问题就是k8s完全启动不了，这个问题好解决，只要将新的机房每个节点的局域网ip和老的保持一致就能启动了，但是对于一些原先将k8s运行目录挂载到扩展硬盘的机器都是无法启动的，因为镜像的方式迁移新的这边硬盘数据肯定是没有的，处理方案，手动完成硬盘挂载，从老的机器上使用scp将数据拷贝到新的机器对应的硬盘，该节点就能正常启动，所有节点启动成功后发现k8s集群中运行的所有pod都出现问题，问题原因是硬盘找不到，排查发现是我们使用的是openebs这个做存储的组件，通过openebs创建了一个storageclass，每个服务器都要创建一个lvmvg的存储卷，解决方案是，将原先所有的pvc和pv全部删除，然后到所有节点上运行vgcreate lvmvg /dev/sdb 完成存储卷创建，这个时候再来创建pvc，大部分组件这个时候已经启动成功了

流水线运行到新的k8s集群中遇到了一些问题，由于我们的gitlab运行在线下，不在同一个机房，老的环境我们是通过openvpn打通网络环境，将线上的6443端口代理到线下，因为原先的整个流水线都是正常运行，所以我们找到线下运行openvpn的对应的pod，然后修改pod中的openvpn客户端配置，这个时候把我们发布镜像的地址改成新的机房的nexus域名，改完后发现一次性就成功了，镜像能够运行到新的机房

安装中间件es，rabbitmq遇到的问题，首先我们使用的是集群的方案安装，然后利用label来控制集群运行到不同的节点上去，发现不管怎么运行，集群的三个字节点都会运行到同一台物理节点去，我们准备了三台物理节点专门用于安装中间件的，经过检查发现是其他两台节点资源不够，硬盘资源计算了几次发现都是够的，最后通过kubectl describe node xxx发现另外两个节点被其他服务占用了内存，导致无法再分配出内存了，我们选择了最简单粗暴的方式解决，直接扩容，增加机器内存

至此所有的服务都运行起来，数据也在实时同步，这个时候就是测试新环境所有的业务了，开始想的办法就是直接使用新的环境的ip+端口然后使用postman去测试接口，后面测试人员抱怨工作量太大了，最终选择的方案是改本地dns，直接测试我们所有的网站和app，pc端改本地dns最简单直接改hosts文件，pc端很快完成所有逻辑的验证，app端我们选择使用adway这个软件，使用它的vpn模式，可以直接通过代理的方式修改本地dns，至此整个新的机房都可以直接测试而不用担心直接去切dns影响线上，因为我们压根不切dns

最关键的一步，也是差点引发灾难的一步，线上流量从老的迁移到新的，最开始讨论出来的方案是从老的网关通过配置4层代理规则把流量引到新的机房，但是一般的服务商他们的网关只能指向内网的ecs服务器，没办法我们通过配置规则把80和443的流量导向三台ecs服务器的80和443，然后从那三台服务器使用nginx-stream配置4层代理走公网代理到新的机房，想法是好的，现实却给了我当头一棒，由于时间紧，仅仅只有几天的迁移时间，等到所有业务测试完成刚好到了老的机房要欠费的这一天，就是服务商给的消息是晚上就停服，我心想那完犊子了，玩意还没迁移老的就停了那就完了，所以我们选择了在下午5点开始迁移，于是我就立马禁用掉原来的网关规则，将我新配置的80和443的规则开放，开始几分钟所有流量都是正常的，大概过了10分钟，3台ecs的nginx全部堵死，瞬间流量太大，直接玩完，现如今只能去改dns解析记录解析到新的机房的网关ip，改了后大概15分钟大部分人的dns已经生效，然后重启下三台ecs服务器，dns生效的流量就直接跑到新的环境，没生效的跑到老的网关，再从三台ecs服务器转发到新的环境，至于如果说老的停机了导致部分有dns缓存的用户无法访问怎么解决，那个就没办法了，要怪只能怪上面又不愿意续费，给的时间又短

至此整个迁移工作还算顺利的完成了，这个时候关闭数据dts的同步，清理掉用于测试而开启的公网ip，所有工作在4天全部完成留了一天用来测试

本人是一名开发人员，整个运维环境是上一位运维大哥留下的，由于他离职了，也没有找新的韵味，我只能接下这个活了，以上是整个迁移的方案和在每个环节遇到的问题，没有过多细节，如果要把所有环节的处理命令拿出来那太多了，如果你也遇到了相同的问题欢迎给我留言，说不定我可以帮你解决