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

在不同的云厂商中的网络类型的叫法都不一样。阿里云的经典网络和腾讯云的基础网络是一个东西,阿里云的专有网络和腾讯云的私有网络也是一个东西。两个厂商不约而同的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