idc迁移上云之路

简介

由于公司旧机房服务器硬件寿命将到而且旧机房多次网络不稳定等问题，决定整体idc的线上环境迁移到阿里云（2019年实施的），迁移动作很大，与线上环境的所有业务相关，涉到整个技术部门配合

迁移详单

现有服务器一共40台+，idc机房架构一共分为4层，代理层，应用服务层，基础服务层，数据层，云上规划的机器为50台+，服务器变多是因为架构有变动，而且新增了部分服务

架构图详解

这里我的整体迁移方案为，在阿里云上新搭一套服务，然后再将idc机房该迁移的数据整理，通过公网ip进行数据传输，这里由于阿里云vpc环境不支持lvs，而且也不能用keepalived虚拟ip，所以只能用slb

迁移方案

1. 整理旧机房所有服务资料，与开发人员确认一些服务的存放以及配置
2. 在阿里云上搭建一套新的服务（这里我进行了挺多架构变更优化）
3. 服务搭建完成后开始进行数据迁移，先预迁移一批整体数据，后续增量同步
4. 云上服务测试（这里我使用了测试域名，然后由测试人员和研发人员进行新环境可用性测试）
5. 确认无误后进行整体迁移，为了避开业务高峰我们在晚上进行迁移
6. 补充后续脚本和配置项（这里基本上就已经迁移完成了）

迁移流程

整理旧机房所有服务资料，与开发人员确认一些服务的存放以及配置

• 首先我们要梳理出迁到云上可能会变更的配置信息，这里我们有较大改变的是数据库的架构和实例存放以及代理层到应用层的变更，见图
• 这里首先我们去除掉了应用机上的nginx，请求到达的中间少了一层，加快了请求速度，并且，旧机房模式为两个机器一组互相代理提高高可用，但是实际上如果此组内python进程都挂掉，请求会仍有到达，因为nginx端口还在的话，虽然nginx剔除掉了不可用进程，但lvs会认为改服务仍然可用，继续发送请求，出了问题会导致部分用户使用业务故障。
• 而新架构很好的解决了这些问题，并且nginx直接代理应用进程会更好的分发请求，提高了容错性
• 阿里云上使用了分组方案，原先是所有微服务都集中在一组服务器上，横向扩容，这样服务太集中，而且端口不能共用，变更后的是根据服务负载情况将几个微服务作为一组，分配在4-5台为一组的机器上，以此将所有的微服务平均分配在几组机器上，达到服务分散，不同机器端口可重用，易管理，流量均衡
• 再就是原idc各种中间件版本太低，迁到新环境需要升级版本，并测试服务接入有无异常，能否兼容
• 然后再就是云上机器购买方案，包括配置，台数，带宽，其他服务像nat网关，共享带宽，slb公网出口高配版等等
• 规划好后即可规划机器ip，部署什么服务，统计剩余ip，规划哪些服务该使用哪些ip段，公网ip需要几个，这里肯定需要不少，因为要做数据同步
• 这里slb有个坑，创建内网实例免费但是内网ip不可自定，需要通过阿里云openapi来创建指定参数配置详情https://api.aliyun.com

在阿里云上搭建一套新的服务

• 这里就比较好弄一点了，因为有规划表格以及文档，将阿里云上网络架构构建好后去修改对于机器配置的ip，然后优化linux系统，部署服务，配置slb，对公司以前架构内的老服务进行版本升级，优化
• 这里slb还有个坑，如果你的机器使用的是eip网卡可见模式，则需要添加一条route add -net 100.64.0.0/10 gw 内网网关 才能被代理到
• 使用直接绑定，即nat映射模式是没有坑的，但是这里我推荐像ftp，vpn，长连接这些服务的机器最好使用eip网卡可见模式，方便运维且服务不易报错

服务搭建完成后开始进行数据迁移，先预迁移一批整体数据，后续增量同步

• 数据迁移在这个项目里是最难的点，特别是mysql数据，所以我们得保证小心再小心，数据完整不丢失，这里我先说一般服务的数据迁移
• 其中有的数据需要迁有的不用，像memcace和rabbitmq这些就不用
• Redis数据直接rsync –agopz 同步/data目录下的rdb文件和/etc下的配置文件即可，其他服务一般都是导配置，代码方面提前弄一个分支或者新project，包括nginx，supervisor等都是，用来适配云上，这里我们比较多的是gfs的数据，两个gfs1.5个T
• 这里，我直接在idc机房弄出一台新机器，挂载目录后rsync同步到云上gfs（有公网ip），可能需要很长时间，但是先做一次全量，后面每3天做一次增量，保证数据不会丢失太多
• 这里有个坑，就是关于权限问题，同步过去的目录看上去是原用户web，实际上如果你云上的这个用户web的uid与旧机房的这个用户web的uid不相同，目录权限就会出问题，同样，其他机器这个用户web的uid也要相同，否则直接不可写
• 线上我们用的是小型git库gitolite，我们将内网环境的gitlab代码目录同步到线上的gitolite内，做好配置即可，这里同样使用的rsync同步
• Mysql的数据迁移，这是个很大的难题，如果你要直接rsync同步整个数据库目录是不可取的，如果mysql不停则拷贝过去的数据直接不可用，而且innodb引擎不支持直接拷贝。如果你想进行不停机迁移，那么最好的方案是用innobackupex热备mysql一个实例的库，然后rsync到云上进行恢复，再接入idc主从，云上当从，实时同步，当然想法是很好的，现实很残酷。
• 当你备份了一天一夜终于将1个多t实例的库备份好后再一天多传到云上，云上再花1天解压缩还原，中间就丢了2-3天左右的数据，你接入主从可能直接就会报错因为主从数据不同步，执行的某些操作从库没有这些数据
• 这里我找到了比较好的解决办法，就是执行备份脚本前，去实例里执行 show master status，记录当前binlog和pos存到文件，在云上还原接入主从的时候，将记录的binlog和pos填入主从配置并启动从，这时候查看从状态 show slave status 可能仍会有报错，不用担心，一般这时候的错都是 error 1062 1032，这个错的意思是从库重复执行了事务和更改的数据不存在，因为我们记录的点可能过早出现的，不用担心在my.cnf配置文件里加入 slave-skip-errors=1062,1032跳过该类型错误即可解决，自此数据同步成功
• 这里我再说个坑，innobackupex还原的时候先使用参数 –defaults-file=./my.cnf --apply-log 否则直接还原接入主从后可能会出现mysql无线重启的bug，这个bug也可能是innodb引擎损坏，修复比较麻烦
• 关于使用这个参数再还原的还有问题有bug的话，我只能推荐你新建库，然后在原机房的实例上用mysqldump导出了
• 关于使用了tokudb引擎的，有个修改版备份工具https://github.com/xelabs/tokudb-xtrabackup
• 如果使用这个还原仍出现找不到数据文件，错误的，我仍然推荐你使用mysqldump，虽然慢，但是导出的数据是完全没问题的，这里我有个3-400G的tokudb的库就是用mysqldump导出的，一把辛酸泪阿

云上服务测试

• 这里因为原域名还在使用，不可能切换流量测试，所以得使用测试域名，这里我们就使用了测试域名，这时候把线上服务全部启动，开发人员将代码同步上去后就可用开始测试业务可用性了，测试的差不多就可以准备迁移了

确认无误后进行整体迁移，为了避开业务高峰我们在晚上进行迁移

• 这里我们采用的迁移方法是，提前做好用户通告，告知维护期间，做好迁移失败回归旧机房准备以及相关措施，保证万无一失
• 我提前加了阿里云上ip白名单，只允许测试环境和公司内网访问接口，然后晚上12点在机房的nginx上deny所有ip，开发人员停掉旧机房相关定时服务，观察没有流量进入后，开始切换流量，切域名的指向ip，cdn源ip这时候因为阿里云有白名单所以业务不会进来，切换完成后我再次进行redis，gfs等增量同步，开发人员开始测试，测试完成后开发人员合并代码，再次测试，测试通过后，我开放流量，并观测线上服务状态，实际上到此就以及迁移完成了

补充后续脚本和配置项

员合并代码，再次测试，测试通过后，我开放流量，并观测线上服务状态，实际上到此就以及迁移完成了

如果觉得该文章对你有帮助的话请给我点个👍吧，感谢