背景
一方面,作为阿里云老用户,默认使用的经典网络,曾经简便易用,入门简单;然而,时过境迁,虽然规模的不断扩大,产品的不断丰富,经典网络也开始暴露各种如安全性、配置复杂甚至阿里云地址池不够用等等问题。阿里云也在2016年6月启动了专用网络策略,没有经典网络ECS实例的用户,只能购买专有网络ECS实例,各项新功能和各种新产品也不再支持经典网络,所以必须迁移到专用网络。
另一方面,公司业务已运行多年,系统众多,主要使用微服务架构,但是服务规划和治理水平没有跟上,服务间调用关系复杂,系统间相互依赖也不少;同时系统和服务数量庞大,无法直接整体迁移VPC。
所以,我们独辟蹊径,不从业务系统级别,而是从云产品级别逐步迁移改造,使所有相关依赖都可以在两个网络环境中访问。
SLB的迁移
我们的业务系统间甚至服务间不仅通过服务注册发现来相互调用,也会通过SLB来相互调用。曾经,因为SLB无法平滑过渡,我们的VPC迁移计划搁置了很久。因为整个业务系统没法整体迁移,调用关系又很复杂,所以阿里云提供的迁移工具SLB混挂,在我们的场景下没法完成预期目标。
1.当A系统在经典网络,B系统在VPC时,如果是A访问B,那么给B系统挂载个经典网络的SLB,确实可以完成目标;但是如果还有个C系统在VPC,也要访问B系统,那么这个B系统的经典网络的SLB,C系统就访问不到了。所以这样做不行。
2.那么,反过来呢?也就是先给B系统挂载个VPC的SLB,然后让C和A系统来访问呢?C系统当然可以直接访问了,然而A系统是经典网络的,同样没法直接访问B系统在VPC的SLB。
3.好吧。既然,不管是挂载VPC的SLB还是挂载经典网络的SLB都不行,那么挂载公网的总行了吧?确实行。不过,本来是内网的SLB,现在换成了公网的SLB,虽然是过渡阶段,但是安全风险还是很大。如果要用这个方案,那么必须给每个SLB的每个监听加上访问控制。由于我们的SLB和监听端口数量非常大,ECS也经常新购和释放,人肉来做效率很低,也很容易出错,所以我们决定开发个自动处理SLB访问控制的程序来做这个事情。甚至,这个程序我们都做好了。
4.然而,就在我们测试ECS Classlink时,我们发现,当经典网络的ECS接入对应VPC的classlink后,这个ECS即可访问VPC内的所有产品,包括SLB。不过,这个SLB要在classlink允许访问的交换机网段上。
所以,迁移SLB的方案就变成了这样:先把所有相关的ECS都开启classlink,然后把所有的内网SLB都切换到VPC里。这样,SLB的迁移就完成了。当然,重新配置SLB以及其监听,重新发布部署服务挂载到VPC SLB上,把上游调用方的访问地址切换到新的SLB上,然后再下掉老的SLB和服务都是必须的,而且要很小心去做。
ECS的迁移
对于ECS,阿里云提供了直接迁移的方法,可以在实例的【更多】-【网络和安全组】里选择【预约迁移至专有网络】然后按照步骤就可以完成迁移。不过这种操作ECS需要重启,而且只能主账号操作,我们只有在个别情况下才使用。这种迁移方式有个好处,公网IP会被保留下来,在一些特殊场景比如公网IP被外部依赖的时候会非常有用。
ECS我们一般不使用直接迁移的方式,而是在VPC内新购买机器,重新部署和搭建服务,并开放给经典网络和VPC网络中的所有调用方使用。不过,虽然不做迁移,但是必须要跟VPC能互访,所以所有ECS都开启classlink是必须的。这个也是迁移VPC第一步要完成的。
其他产品
除了SLB和ECS,阿里云的其他产品,如RDS、MongoDB、Redis、OSS、MNS/MQ等,都提供了混访模式,也就是在过渡期间,给每个实例都分配一个VPC地址,同时继续保留原来的经典网络地址,这样,不管使用方所在的网络是经典网络还是VPC网络,都可以访问到。
当全部迁移VPC完成后,经典网络的地址就可以释放掉,所有产品就完全变成了VPC网络。这里要注意的是,当这些产品切换到VPC后,虽然经典网络地址还继续保留,但是是有保留时间限制的,需要在一段时间内迁移完毕或者经常续期。另外,一旦切换到VPC后,默认显示的各种信息就都是VPC网络的,要使用经典网络地址时需要特别留心注意不要搞错地址。
总结
以上就是我们从经典网络迁移到专有网络VPC时将阿里云产品逐个切换到VPC网络的方法,其实都是阿里云官方方式,classlink、混挂、混访。通过这种方式,我们基本解除了系统间的依赖,不管先迁移哪个系统,都没有太大的影响。不过,在具体场景下,要完全做到平滑,还是需要特别注意,要多做测试,同时也还是要注意操作步骤和相互依赖。