经典网络迁移VPC最佳实践

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
公网NAT网关,每月750个小时 15CU
简介: 阿里云起步于经典网络,但已经全面转向VPC。专有网络VPC以其在安全、成本和网络功能方面的优势,正受到越来越多用户的欢迎。在9月6日云栖社区技术直播中,阿里云高级产品专家谭礼铨(李泉)为大家分享了经典网络迁移VPC最佳实践,本次分享介绍三种将ECS从经典网络迁移至VPC网络的途径,并阐述三种类型的迁移分别适合怎样的客户需求和场景。
#1. 云上进入VPC时代 如下图所示的是阿里云的网络演进情况。阿里云其实是在2009年就开始做云计算的,在一开始的时候使用的都是经典网络,也就是Classic网络。到了2014年9月份,阿里云推出了VPC产品。在2016年3月份阿里云推出了Default VPC,也就是说此时阿里云可以为每个用户提供VPC产品。在2016年的4月份,整个阿里云的云产品都全线接入到了VPC。再到2016年7月份,阿里云就开始推行对于新用户默认使用VPC。2017年6月份,阿里云就针对于经典网络迁移VPC推出了三个解决方案。

以上就是阿里云网络的演进历程,可以看到阿里云其实是慢慢地从经典网络向VPC进行过渡的,而经典网络终将退出历史舞台,所以在这里建议大家一定要使用VPC,这也是阿里云所推荐的网络类型。

同时也对比看一下AWS的网络演进情况,如下图所示,AWS在2009年推出了VPC,在2013年上线了Default VPC。在2013年4月份,AWS也开始推行针对新用户只能购买EC2-VPC这样的实例。而在2014年10月份,AWS推出了ClassLink功能,供经典网络用户迁移到VPC使用。

可以说云上已经进入了VPC时代,但是还有很多存量用户在使用经典网络。这是因为无论是阿里云还是AWS,只要是起步于经典网络的云服务商,在其上还是会存在很多经典网络的用户的,而这部分用户就需要从经典网络迁移到VPC。

对比经典网络和VPC来看,简单而言,VPC会更加安全,更加便宜,同时其网络功能也会更多,所以VPC也是推荐大家使用的网络类型。

首先,从安全角度来说,VPC网络是基于vxlan的,并且它是使用隧道技术实现的,存在二层的隔离,所以会更加安全;而经典网络是通过三层的隔离,比如使用像IP table这样三层的隔离手段实现的,所以相对而言经典网络的安全性更低一些。从成本的角度来看,因为阿里云现在推荐使用VPC,所以对于ECS实例,如果是相同类型的,在VPC网络环境下的ECS会更加便宜一些。除此之外,针对于VPC这种网络类型,阿里云还推出了共享带宽包这样的新型共享带宽方式,所以也能够帮助用户节约一些公网带宽的成本。在功能方面,VPC的优点就比较多了,只有使用了VPC,用户才有更多的网络管理功能,比如自定义网络、子网划分、多地域私网互通等,并且子网络有网络ACL或者共享带宽包这些产品。以上这些网络功能都是基于VPC的,所以可以说VPC是用户在云上具备网络管理功能的前提。在经典网络上,用户对于网络进行管理的功能不多,可能只有ECS上的共有IP地址以及安全组的使用,其他的像上面提到的自定义网络或者子网划分等功能,在经典网络上都是没有的。综上所述,可以说VPC是用户在云上具备网络管理能力的前提。

#2. 迁移提醒 ##2.1 了解VPC

首先,用户在迁移之前需要先去了解VPC。上面提到了VPC让用户在云上拥有网络管理能力,但是这些管理能力需要用户通过相关的网络产品来实现,所以在迁移到VPC之前一定要先多了解下VPC,比如如何规划自己的VPC网络,使用一个VPC还是两个VPC,使用什么网段等问题,以及在VPC内如何使用云产品、VPC内的ECS如何和公网通信以及多个VPC如何互通等等问题的解决都需要用户对于VPC有一定的了解。所以对于大家的第一个迁移提醒就是在迁移之前一定要去了解VPC。

##2.2 了解迁移方案以及其限制

第二个迁移提醒就是了解迁移方案以及其限制。阿里云针对于从经典网络迁移到VPC提出了三种解决方案,这三个解决方案各有自己的适用场景以及相关的限制,所以在选择迁移方案的时候需要先去了解这些。

##2.3 确定迁移方案

第三个迁移提醒就是要去确定一个比较详细的迁移方案。因为云上的用户在经典网络中可能会存在非常复杂的系统,所以想要迁移到VPC中,可能在正常情况下无法实现一次性迁移完成。因此整个迁移过程必然是分步骤、有节奏、有次序地向VPC中迁移,所以迁移方案就会显得非常重要。首先可能需要将系统的依赖梳理清楚,然后决定先迁移什么后迁移什么,也就是将整体的迁移方案的步骤细化,之后再开始从简单系统到复杂系统的迁移。除此之外,特别要说明的一点就是在迁移的过程中要注意观察。需要观察系统的表现以及相关的监控指标,以及留好回退的准备,比如系统迁移过程中发现一些异常,需要做好预案来退回到原来的系统,来避免一些问题。

#3. 迁移方案概述

阿里云针对于从经典网络向VPC网络迁移提供了三个解决方案,它们分别是混挂和混访方案、ClassicLink方案以及单ECS迁移方案。这三个方案可以独立使用,也可以组合使用。在大多数情况下,大家都会更具不同的场景使用其中的一个、或者两个甚至是三个方案。

##3.1 混挂和混访方案概述 接下来对于这三个迁移方案进行简单的概述。第一个方案就是混挂和混访的方案,这个方案首先需要声明的一点就是它是系统的迁移方案,而不是将经典网络ECS直接迁移到VPC上去。混挂和混访方案的基本迁移基本流程如下:
  1. 新建VPC ECS
  2. 在新VPC ECS 部署系统
  3. 将VPC ECS 加入现有业务系统
  4. 将现有业务系统的经典网络ECS 从系统中移除
  5. 将经典ECS释放
  6. 完成迁移
对于混挂和混访方案更加详细说明一下,其中的混挂就是负载均衡SLB的混挂,也就是如下图所示的一个SLB的实例可以同时挂载经典和VPC的ECS,而这在之前是存在限制的,也就是不允许这样去做的。分开来讲,这里的混挂一方面是说公网SLB支持混挂,另外就是私网的SLB也支持混挂,还有就是私网的VPC类型的SLB也支持混挂。但是,对于私网VPC的SLB混挂存在一个限制就是如果使用4层监听时经典ECS无法获取真实来源IP,所以大家需要关注一下是否影响了系统。

混访的意思指的是RDS以及OSS等云产品支持混合访问,也就如下图所示的像RDS、Mongo、Redis以及OSS等这些云产品可以被经典和VPC的ECS访问到。这里有个注意事项就是这种混访是需要使用不同的域名的,比如RDS实例A,从经典网络ECS访问的域名是Classic.RDSA.aliyun.com,从VPC ECS访问的域名是VPC.RDSA.aliyun.com,访问的都是同一个实例。还有这里需要说明的一点就是:混挂和混访的方案虽然能够满足大部分的场景,但是它不能满足经典网络和VPC ECS需要直接通信的场景,也就是说如果用户的业务系统中经典网络需要和VPC ECS进行直接通信的话,使用混挂和混访的方案就无法满足,比如像使用kafka这种数据分析以及大数据相关的系统,就无法直接使用混挂和混访的方案,这种场景下就需要使用后面将会提到的方案。


##3.2 ClassicLink方案概述

简单而言,ClassicLink方案就是允许Classic的ECS和VPC通信。如上图所示,Classic的ECS Link到达一个VRouter上,这样Classic的ECS就能访问VPC中的ECS以及云产品等云资源了。这里给出了大家在使用ClassicLink方案时的五点提醒:
  1. Classic ECS可Link到VPC,Classic网络以单ECS为粒度的,用户可以把一台、两台甚至更多的ECS Link到VPC上。而VPC网络以VPC为粒度,就是将一台Classic ECS Link到VPC,这个Classic的ECS就能够访问VPC中的所有资源了。
  2. 已Link到VPC的Classic ECS可以访问VPC内所有资源
  3. VPC网络的ECS只能访问已Link的Classic ECS,而不能访问未Link的Classic ECS和Classic云产品。
  4. 目标VPC如是10网段,则要和经典网络ECS通信的交换机网段必须10.111.0.0/16。这是因为经典网络和VPC的通信使用的是路由的方式来实现的,为了规避地址冲突,在经典网络中这个地址段没有使用,留下来给VPC中的需要使用ClassicLink的ECS使用
  5. 目标VPC如采用192.168.0.0/16网段,需要在经典网络ECS增加到该网段路由。这是因为最早阿里云的私网主要使用的10网段,对于192网段默认是没有这条路由的,所以需要用户进行增加。
##3.3 单ECS方案概述

单ECS方案就是经典网络ECS通过本方案直接迁移到专有网络中。当然,这个方案需要重启ECS,但是不需要用户去创建镜像、重新购买ECS等,只需要将ECS重启之后就能够迁移到VPC里面了。需要说明的是目前使用该方案迁移还需要进行预约,用户需要将要迁移的实例列表发给客户经理。待阿里云处理后,用户方可通过控制台进行预约迁移时间。预约完成后,阿里云会根据用户设置的迁移时间进行迁移,迁移完成后,用户将收到迁移成功的短信消息提醒。后续该功能还会实现成为用户可以全部自助完成的,这个功能目前还在开发之中。单ECS迁移方案存在一些限制需要大家注意:
  • 暂时还不支持经典网络系列1类型ECS的迁移,阿里云现在也正在解决这个问题。目前用户可以先将系列1类型的ECS升级之后再进行迁移。
  • 迁移过程中ECS需要进行重启,需要用户关注对系统的影响。
  • 目前使用此迁移方案,ECS的公网IP和私网IP都会变化。后续阿里云将会先支持公网不变,在未来,也会努力实现私网IP不变。
  • 迁移到的目标VPC的交换机的可用区必须和待迁移的ECS的可用区相同,也就是目前不能跨可用区迁移。
  • 迁移过程中实例ID及登录信息不变。
  • 包年包月购买方式的实例迁移过程中不需要额外付费。从新的计费周期开始,按同规格专有网络的价格计算。并且迁移到VPC后,ECS的使用费用会降低。
  • 迁移前如有续费变配未生效订单或未支付订单,迁移后该订单将被取消且不能恢复,客户需要重新下单。
  • 迁移到VPC后,若ECS有使用其它云服务,需将访问方式调整到VPC访问方式(云产品混访方案)。

#4. 混挂和混访方案 ##4.1 混挂和混访方案Demo 在如图下所示的简单系统中,经典网络中的一个公网负载均衡SLB挂载了2台ECS实例,并使用了RDS和OSS这两个云产品,而现在要将这个业务系统通过混挂和混访方案迁移到VPC中。


##4.2 混挂和混访方案迁移核心流程

首先,要规划VPC网络,并且建立VPC网络环境,也就是需要创建好VPC并且创建好交换机。如果大家对这一部分不熟悉可以参考VPC最佳实践-网络规划篇( https://yq.aliyun.com/topic/94)。

第二步就是在VPC内新建ECS,并且在VPC ECS上部署应用。这个时候特别需要注意的是在VPC ECS上部署的应用在访问OSS和RDS的域名时需要使用VPC域名,这也是与在经典网络上应用访问OSS和RDS的不同之处。在部署完成之后,还需要测试应用能否正常访问OSS和RDS。

第三步就是将VPC的ECS加入到公网SLB当中,也就是如下图所示通过混挂把VPC的ECS也加入到SLB里面。这个时候需要注意公网SLB中VPC ECS的健康检查状态,如果没有问题的话,经典网络和VPC中的ECS应该能够同时提供服务。

第四步就是去检查如果业务系统工作是否正常。如果系统正常,并且VPC中的这两台ECS实例也能够正常地处理业务的请求和访问,这时候就可以将经典网络中的这两台ECS从公网SLB中移除掉。在将经典网络中的ECS移除之后,便只剩下VPC这两台ECS提供服务了,只不过此时VPC中的ECS会跨网络地访问经典网络中的RDS和OSS。

第五步就是将RDS切到VPC中。RDS提供了切换网络类型的功能,能够从经典网络切换到VPC并且将经典网络的域名删除。而OSS本身不需要切换,因为OSS的每个地域都提供了一个统一的域名,所以只需要不使用经典网络访问域名即可。

最后,如果运行一段时间之后发现系统运行正常,没有任何问题,就可以将经典网络这两台ECS释放掉,此时也就完成了整个系统从经典网络到VPC的迁移。这里需要说明的一点就是公网SLB不需要迁移,因为公网SLB其实是在VPC外面的,所以它既可以挂载经典网络的ECS也可以挂载VPC的ECS,而本身不需要迁移。

如下图所示的是一个相对比较复杂的系统,整个系统经过了SLB之后挂载了两台ECS,之后这两台ECS又去访问私网的SLB,私网的SLB下面又挂载了两台ECS,而它们又要去访问OSS和RDS。对于这样一个比较复杂的系统而言,与前面提到的相比有一个特别的地方就是之前提到了混挂指的是SLB的混挂,混访指的是RDS以及OSS这些的混访,但是SLB只支持混挂不支持混访,所以在如下图所示的这个系统里面需要先迁移私网的SLB。那么,首先需要在VPC里面新建ECS,用于私网SLB后的ECS迁移。之后再在VPC中建立对应的SLB VPC实例并挂载ECS。最后,迁移公网SLB的ECS并配置,也就是修改程序使用SLB VPC实例。需要说明的核心的一点就是:对于私网SLB而言,是不支持混访的,所以对于私网SLB的迁移是需要在VPC中建立对应的SLB实例来处理的。


#5. ClassicLink迁移方案
##5.1 ClassicLink迁移方案底层的技术和原理 首先简单介绍一下ClassicLink方案底层的技术和原理。经典网络和VPC互通与经典网络和经典网络互通的底层实现是一致的,其实是同一套系统,因此内网延迟不变,私网带宽限速这些相关的网络属性是不会发生变化的。另外,宕机迁移、热迁移、停止、启动、重启、更换系统盘等操作不会改变已建立的ClassicLink链接。也就是说如果一个经典网络的ECS Link到一个VPC上,那么这台ECS发生了宕机迁移或者重启这些都不会改变ClassicLink。经典网络是一个网络平面,VPC是另一个网络平面,ClassicLink是通过路由将这两个网络平面拉齐,让其具备互通的条件。因此使用ClassicLink功能,首先要避免网络地址冲突,做好网络地址规划。阿里云经典网络中使用的地址段是10.0.0.0/8(不包括10.111.0.0/16),因此只要VPC的地址段与经典网络的地址段不冲突,就可以通过ClassicLink功能私网通信。可以与经典网络互通的VPC地址段有172.16.0.0/12、10.111.0.0/16、192.168.0.0/16。

##5.2 ClassicLink迁移方案Demo ClassicLink方案的基本迁移流程也比较简单。首先,针对VPC去开启ClassicLink的功能。第二步,将经典网络ECS链接到VPC来打通。第三步,添加ClassicLink安全组规则。当这三步完成之后,这台经典的ECS就可以和VPC进行通信了,接下来可以结合他们的通信做数据迁移或者使用混挂的方案进行迁移。

下图所展示的就是第一步开启VPC的ClassicLink功能。这里需要注意的就是在VPC的路由表中,不能有目标网段为10.0.0.0/8自定义路由条目。若VPC的网段是10.0.0.0/8,需要确保和经典网络ECS通信的VPC的交换机的网段在10.111.0.0/16内。若VPC的网段是192.168.0.0/16,需要在经典网络ECS中增加192.168.0.0/16指向私网网卡的路由。

第二步就是将经典网络的ECS连接到VPC。这里需要注意的是最多允许1000台经典网络ECS链接到同一个VPC,并且一台经典网络ECS只能链接到一个VPC,并且这个链接必须要是同账号同地域的,比如北京的ECS链接到上海的VPC是不可以的,同时也不支持A账号的ECS链接到B账号的VPC。如果要将账号A的ECS链接到账号B的VPC,可以ECS从账号A过户到账号B。而申请ECS过户需要通过提交工单的方式,并且在过户前,用户需要确保已了解ECS实例过户须知。

第三步就是添加ClassicLink安全组规则。

目前为了方便用户的使用,阿里云提供了以下三种授权方式:
  1. 经典网络与专有网络相互授权访问,这种方式也是阿里云推荐使用的授权类型。
  2. 授权专有网络实例访问经典网络实例。
  3. 授权经典网络实例访问专有网络实例。

#6. 单ECS迁移方案
##6.1 单ECS迁移方案Demo 之前也提到了目前如果想要使用单ECS迁移方案还需要用户提供实例ID给客户经理,客户经理给到阿里云处理之后,用户就可以在阿里云进行预约迁移了。下图所展现的就是预约迁移的截图,如果预约完成,在ECS控制页的概览页面里面会有一个待迁移事件,用户之后可以再去选择预约迁移的时间,阿里云就会帮助用户在这个预约的时间点里面进行迁移,迁移完成之后还会通过短信通知用户。

更多详细信息请参考:
经典网络迁移VPC [详细文档](https://help.aliyun.com/document_detail/55051.html)
相关实践学习
使用ROS创建VPC和VSwitch
本场景主要介绍如何利用阿里云资源编排服务,定义资源编排模板,实现自动化创建阿里云专有网络和交换机。
阿里云专有网络VPC使用教程
专有网络VPC可以帮助您基于阿里云构建出一个隔离的网络环境,并可以自定义IP 地址范围、网段、路由表和网关等;此外,也可以通过专线/VPN/GRE等连接方式实现云上VPC与传统IDC的互联,构建混合云业务。 产品详情:https://www.aliyun.com/product/vpc
相关文章
|
4月前
|
缓存 数据安全/隐私保护 Kotlin
Kotlin 中的网络请求代理设置最佳实践
Kotlin 中的网络请求代理设置最佳实践
|
2月前
|
数据采集 存储 监控
网络爬虫的最佳实践:结合 set_time_limit() 与 setTrafficLimit() 抓取云盘数据
本文探讨了如何利用 PHP 的 `set_time_limit()` 与爬虫工具的 `setTrafficLimit()` 方法,结合多线程和代理 IP 技术,高效稳定地抓取百度云盘的公开资源。通过设置脚本执行时间和流量限制,使用多线程提高抓取效率,并通过代理 IP 防止 IP 封禁,确保长时间稳定运行。文章还提供了示例代码,展示了如何具体实现这一过程,并加入了数据分类统计功能以监控抓取效果。
65 16
网络爬虫的最佳实践:结合 set_time_limit() 与 setTrafficLimit() 抓取云盘数据
|
6月前
|
弹性计算 监控 开发工具
【阿里云弹性计算】阿里云ECS的网络优化实践:VPC配置与网络性能提升
【5月更文挑战第29天】阿里云ECS通过虚拟私有云(VPC)提供高性能、安全的网络环境。VPC允许用户自定义IP地址、路由规则和安全组。配置包括:创建VPC和交换机,设定安全组,然后创建ECS实例并绑定。优化网络性能涉及规划网络拓扑、优化路由、启用网络加速功能(如ENI和EIP)及监控网络性能。示例代码展示了使用Python SDK创建VPC和交换机的过程。
424 3
|
1月前
|
安全 物联网 物联网安全
探索未来网络:物联网安全的最佳实践
随着物联网设备的普及,我们的世界变得越来越互联。然而,这也带来了新的安全挑战。本文将探讨在设计、实施和维护物联网系统时,如何遵循一些最佳实践来确保其安全性。通过深入分析各种案例和策略,我们将揭示如何保护物联网设备免受潜在威胁,同时保持其高效运行。
49 5
|
2月前
|
机器学习/深度学习 安全 物联网安全
探索未来网络:物联网安全的最佳实践与创新策略
本文旨在深入探讨物联网(IoT)的安全性问题,分析其面临的主要威胁与挑战,并提出一系列创新性的解决策略。通过技术解析、案例研究与前瞻展望,本文不仅揭示了物联网安全的复杂性,还展示了如何通过综合手段提升设备、数据及网络的安全性。我们强调了跨学科合作的重要性,以及在快速发展的技术环境中保持敏捷与适应性的必要性,为业界和研究者提供了宝贵的参考与启示。
|
3月前
|
SQL 安全 API
数字堡垒之下:网络安全漏洞、加密技术与安全意识的博弈探索RESTful API设计的最佳实践
【8月更文挑战第27天】在数字化浪潮中,网络安全成为守护个人隐私与企业资产的关键防线。本文深入探讨了网络漏洞的成因与影响,分析了加密技术如何为数据保驾护航,并强调了提升公众的安全意识对于构建坚固的信息防御系统的重要性。文章旨在为读者提供一场思维的盛宴,启发更多关于如何在日益复杂的网络世界中保护自己的思考。
|
2月前
|
存储 安全 物联网
探索未来网络:物联网安全的最佳实践与挑战
在数字化浪潮中,物联网作为连接万物的关键技术,已深刻改变我们的工作与生活方式。然而,随着其应用的广泛化,安全问题日益凸显,成为制约物联网发展的重要瓶颈。本文旨在深入探讨物联网的安全架构、风险点及应对策略,通过分析当前技术趋势和实际案例,提出一套切实可行的安全防护方案,以促进物联网技术的健康发展。
|
3月前
|
监控 安全 网络安全
保护网络免受 DDoS 攻击的最佳实践
【8月更文挑战第24天】
95 1
|
3月前
|
开发者 图形学 API
从零起步,深度揭秘:运用Unity引擎及网络编程技术,一步步搭建属于你的实时多人在线对战游戏平台——详尽指南与实战代码解析,带你轻松掌握网络化游戏开发的核心要领与最佳实践路径
【8月更文挑战第31天】构建实时多人对战平台是技术与创意的结合。本文使用成熟的Unity游戏开发引擎,从零开始指导读者搭建简单的实时对战平台。内容涵盖网络架构设计、Unity网络API应用及客户端与服务器通信。首先,创建新项目并选择适合多人游戏的模板,使用推荐的网络传输层。接着,定义基本玩法,如2D多人射击游戏,创建角色预制件并添加Rigidbody2D组件。然后,引入网络身份组件以同步对象状态。通过示例代码展示玩家控制逻辑,包括移动和发射子弹功能。最后,设置服务器端逻辑,处理客户端连接和断开。本文帮助读者掌握构建Unity多人对战平台的核心知识,为进一步开发打下基础。
118 0
|
3月前
|
安全 开发者 数据安全/隐私保护
Xamarin 的安全性考虑与最佳实践:从数据加密到网络防护,全面解析构建安全移动应用的六大核心技术要点与实战代码示例
【8月更文挑战第31天】Xamarin 的安全性考虑与最佳实践对于构建安全可靠的跨平台移动应用至关重要。本文探讨了 Xamarin 开发中的关键安全因素,如数据加密、网络通信安全、权限管理等,并提供了 AES 加密算法的代码示例。
58 0

相关产品

  • 专有网络VPC