从基础网络迁移到私有网络-以腾讯云为例

在不同的云厂商中的网络类型的叫法都不一样。阿里云的经典网络和腾讯云的基础网络是一个东西，阿里云的专有网络和腾讯云的私有网络也是一个东西。两个厂商不约而同的2017年6月14号前后禁止新帐号购买基础网络和经典网络的任何产品。这意味着从这个时间点开始，基础网络和经典网络已经不再是未来发展的潮流，在未来的新产品（如ElasticSearch）可能不再支持这两个网络类型。在双十一的营销活动中也早已不见这两个网络类型的踪影。为了保证公司业务的未来发展和降低云设施的采购成本，基础网络转私有网络（或经典网络转专有网络）是势在必行的一件事。这个事情你做得越晚，就越难推动。所以长痛不如短痛，我们现在开始吧！

1. 已知信息

在这里我们说的所有数据库包括mysql、tdsql、redis都是指腾讯云的saas产品，而非自建的数据库。所有已知信息均从腾讯云官方文档和售后技术人员得知。

1.1 私有网络

  • 基础网络切换到私有网络过程不可逆。
  • 私有网络和基础网络不能直接互通。
  • 不同的私有网络之间不能直接互通。
  • 同一个私有网络中，不同的子网可以直接互通。
  • 使用基础网络互通可以让私有网络和基础网络互通（数据库除外）。

1.2 服务器

  • 内网 IP 从基础网络 IP 改变为私有网络 IP。
  • cvm子网确定之后，还可以修改绑定其他子网。
  • 迁移过程中，实例需要进行重启。

1.3 数据库

  • 数据库（包括redis）转私有网络时，旧的基础网络地址还能提供最多7天的使用时间。
  • 数据库（包括redis）如果有只读实例或者灾备实例，最后还需要手动进行网络切换。
  • 如果要做跨可用区容灾，用高可用版本，选择主可用区和备可用区。

1.4 网关

  • 负载均衡CLB没有办法做转移，需要重新购买后重新配置监听。
  • Ddos高防ip需要重新配置转发的负载均衡CLB（如果有的话）

1.5 运维

  • 日志收集（cls）需要重新配置机器组。
  • jenkins的所有子节点需要重新配置。

1.6 其他

  • xxl-job的执行器地址需要重新配置。
  • Archery数据库地址重新配置。
  • Datax需要重新配置

2. 限制条件

  • 一旦开始就没有回头路。
  • 整个迁移计划最好在7天内完成。
  • 迁移过程不能影响正常业务运行。

3. 迁移方案

迁移方案有A、B两种。A方案利用了数据库切换私有网络的7天缓冲时间。假设因为某些原因，7天内未能完成所有服务器的私有网络切换，则使用方案B。方案B的则利用了Haproxy作为数据库的中转层，所以业务应用不必在乎数据库的网络类型，仅仅借助基础网络互通就可以保证业务的正常运转。

3.1 准备阶段

3.1.1 验证基础网络互通和Haproxy的稳定性
  1. 找一个基础网络的服务器A，部署Haproxy将流量转发到数据库。
  2. 找一个私有网络的服务器B，将服务器A和B通过基础网络互通链接起来。
  3. 在服务器B上部署业务应用，业务应用的数据库链接地址为Haproxy。
  4. 运行一个星期看业务、基础网络互通、Haproxy三者都稳定。
3.1.2 安装Haproxy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 安装编译需要的依赖
sudo yum install gcc pcre-devel tar make -y
# 下载安装包
wget http://www.haproxy.org/download/2.3/src/haproxy-2.3.2.tar.gz
# 解压压缩
tar -zxvf haproxy-2.3.2.tar.gz.tar
mv haproxy-2.3.2 /usr/local/
# 编译安装
make TARGET=linux-glibc
sudo make install
# 配置到path
sudo ln -s /usr/local/sbin/haproxy /usr/sbin/haproxy
# 创建配置文件目录
sudo mkdir -p /etc/haproxy
# 创建haproxy运行目录
sudo mkdir -p /var/lib/haproxy
# 创建获取haproxy状态的socket文件
sudo touch /var/lib/haproxy/stats
# 创建启动用户
sudo useradd -r haproxy
# 启动haproxy
haproxy -f /etc/haproxy/haproxy.cfg
# 重启haproxy
haproxy -f /etc/haproxy/haproxy.cfg -st `cat /var/run/haproxy.pid`
# 检查配置文件
haproxy -c -V -f /etc/haproxy/haproxy.cfg

haproxy的配置文件/etc/haproxy/haproxy.cfg。该配置文件转发了两台mysql实例的连接，一台主库一台从库。另外还开放了一个haproxy控制台的管理页面。输入http://ip:18367/stats即可访问。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
global
    log         127.0.0.1 local0
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     3000
    user        haproxy
    group       haproxy
    daemon
    stats socket /var/lib/haproxy/stats

defaults
        log     global
        log 127.0.0.1 local0 notice
        mode    tcp
        option  dontlognull
        retries 2
        option redispatch
        maxconn         3000          
        timeout queue           60s                   
        timeout connect         5s                  
        timeout client          30000s                   
        timeout server          30000s                  


listen  mysql_master
        bind 0.0.0.0:23308
        mode tcp
        server mysql_master 192.168.10.203:3306

listen  mysql_slave
        bind 0.0.0.0:23309
        mode tcp
        server mysql_slave 192.168.10.204:3306

listen stats
        bind 0.0.0.0:18367
        mode http
        option httplog
        maxconn 10
        stats refresh 30s
        stats uri /stats
        stats realm HAProxy\ Stats
        #访问控制台的帐号密码
        stats auth admin:wobeidaohao 
        stats hide-version
        stats admin if TRUE

3.2 实施阶段——Plan A

  1. 将数据库（cdb、redis、tdsql）转为私有网络，将基础网络地址回收时间设置为7天后（仅仅只需要设置一次）。
  2. 将要切换的服务器从负载均衡（CLB）中下线（如果有的话）。
  3. 解除弹性ip于该服务器的绑定（如果有的话）。
  4. 检查该服务器的其他影响范围（如xxl-job）。
  5. 修改业务应用的配置文件，将数据库地址改为私有网络地址。
  6. 优雅停止服务器上的所有业务应用。
  7. 将该服务器切换到私有网络，并重启。
  8. 将该主机加入基础网络互通。
  9. 重新绑定弹性ip（如果有的话）。
  10. 重启所有业务应用。
  11. 购买新的负载均衡，绑定到该服务器（如果需要的话）（注意Ddos高防ip转发）。
  12. 验证是否业务应用运行正常。如果正常，则删掉老的负载均衡（CLB）实例。
  13. 检查该服务器的其他影响范围（如xxl-job）。
  14. 重新配置jenkins的节点地址。
  15. 重新配置日志收集的机器组地址。

3.3 实施阶段——Plan B

此方案只有当迁移时间超过了数据库基于的缓冲时间才使用。

  1. 在私有网络的服务器中部署一台Haproxy，并且将数据转发到数据库（通过私有网络地址）。
  2. 将还在基础网络的服务器都加入同一个基础网络互通环境。
  3. 重新配置所有在基础网络的业务应用的数据库链接地址为Haproxy地址（只需要重启业务应用，应该很快）。
  4. 再一个一个按照Plan A来迁移服务器到私有网络，此时迁移不再有时间限制。但是稳定性完全依赖基础网络互通和Haproxy，所以还是应该尽快将所有服务器迁移到私有网络。
  5. 迁移完成之后，业务应用连接数据库的地址还是要改回私有网络地址，不再使用Haproxy。

3.4 中间件的迁移

对于一些中间件或者公共服务，如注册中心、xxl-job、seata、mq等的迁移方案和业务应用不同。因为他们以内网ip的形式被多个业务应用依赖着。假设切换到私有网络，内网ip必定会发生变化，此时所有与之产生依赖关系的业务应用统统都会出错。

3.4.1 单点部署的公共服务

seata server出于某些原因，只能部署一台服务器，不能做到集群部署。对于这种单点部署的公共服务，是非此即彼的。如果不做任何策略，直接切换到私有网络，需要更改所有与之依赖的业务应用并重启。重启所有的业务应用需要大量时间，这是不可接受的。

  1. 在一台私有网络的新服务器上部署seata server(redis使用私有网络地址)。
  2. 此时新的seata server会到注册中心登记，并开始提供服务。
  3. 马上下线基础网络的那台seata server。
  4. 将基础网络切换到私有网络，并重启seata server(redis使用私有网络地址)
  5. 马上下线第一步中启动的seata server。
3.4.2 集群部署的公共服务

注册中心、xxl-job、mq都属于这类公共服务，在正式环境上部署超过1台。为了不影响运行需要采取一下的迁移方式：

  1. 将要迁移的公共服务从业务应用的配置文件摘除，换上基础网络的公共服务。**【业务应用重启】**
  2. 将要迁移的服务器切私有网络，重启公共服务。
  3. 业务应用的配置文件使用刚刚迁移到私有网络的公共服务，基础网络的公共服务摘除。**【业务应用重启】**
  4. 将其他要迁移的服务器切私有网络，重启公共服务。
  5. 业务应用的配置文件使用集群的公共服务（此时所有都是私有地址）**【业务应用重启】**

4. 注意事项

  • 不同的数据库实例和类型（如redis）最好使用各自独立部署的Haproxy，防止故障产生时扩大影响范围。

5. 服务器迁移的顺序

决定迁移顺序的原则是：关联少、依赖简单、容易的先迁移；迁移难度大的后迁移。

  1. 业务应用
  2. Seata
  3. 注册中心
  4. nginx
  5. RabbitMq
  6. xxl-job
  7. ActiveMq

参考链接：
https://upcloud.com/community/tutorials/haproxy-load-balancer-centos/
https://www.jianshu.com/p/c9f6d55288c0
http://www.hangdaowangluo.com/archives/1526
https://docs.pingcap.com/zh/tidb/dev/haproxy-best-practices
https://www.haproxy.com/blog/exploring-the-haproxy-stats-page/

原文链接：https://www.jdkdownload.com/migration_net.html