VPC最佳实践(一):网络规划篇

专有网络VPC(Virtual Private Cloud)是阿里云推荐的网络类型,越来越多的用户选择使用VPC,可以说VPC是现在用户上云第一个考虑的产品。使用VPC主要有两方面的核心优势。一是安全,即用户需要更安全的网络隔离,VPC基于隧道技术,实现数据链路层的隔离,为每个租户提供一张独立、隔离的安全网络。二是VPC让用户有了网络管理能力,比如IP规划,路由管理等等。在VPC出现之前,云上用户是缺乏网络管理能力的。

 

关于VPC详细信息可以访问:VPC产品

 

 

 

用户在考虑使用VPC的时候,首先遇到的一个问题就是,如何进行VPC网络规划?本文拆分成下面几个小问题进行分析。

 

问题一,应该使用几个VPC?

问题二,应该使用几个虚拟交换机?

问题三,应该选择什么网段?

问题四,考虑一个比较复杂的业务系统,云上存在多个VPC且需要和云下IDC互通,如何规划网段?

 

问题一,我应该使用几个VPC?

这个问题,从下面两点考虑,如果

1)没有多地域部署系统的要求

2)各系统之间也不需要通过VPC进行隔离

 

那么推荐使用一个VPC。如图1.1所示。

 

图1.1 单VPC示意图

 

使用一个VPC,容量和性能是不是够呢?阿里云有用户在单VPC内运行了近5000个实例,实际上还可以支撑更多的实例。这样的容量基本上可以绝大多数用户需求。

 

 

如果有多地域部署系统的要求,就必然需要使用多个VPC,因为VPC是地域级别的资源,是不能跨地域的。如图1.2所示

图1.2 多地域部署VPC 示意图

 

大家可能会问,使用多个VPC,怎么能内网互通呢?基于阿里巴巴骨干网构建的高速通道产品能轻松实现跨地域,跨国VPC间的互通。后面的文章会再详细介绍,先回到网络规划问题上。

 

上文提到在多地域部署系统是需要多个VPC的,但如果在一个地域的多个业务系统需要通过VPC进行严格隔离,比如生产环境和测试环境要严格进行隔离,那么,也需要使用多个VPC。如图1.3所示。

 

图1.3 一个地域使用多个VPC隔离生产和测试环境

 

 

问题二,应该使用几个虚拟交换机?

 

 

首先,即使只使用一个VPC,也尽量使用至少两个虚拟交换机,并且两个虚拟交换机分布在不同可用区,做到跨可用区容灾。

 

注:

可用区是指在同一地域内,电力和网络互相独立的物理区域,在同一地域内可用区与可用区之间内网互通。

 

同一地域不同可用区之间的网络通信延迟很小,但也需要经过业务系统的适配和验证,系统调用复杂加上系统处理时间,跨可用区调用也可能产生期望之外的延迟。建议进行系统优化和适配,能够容忍这种延迟,在高可用和低延迟之间找到平衡。

 

其次,使用多少个虚拟交换机还和系统规模和系统规划有关。如前端系统都可以被公网访问并且都有主动访问公网的需求。考虑到容灾,可以考虑将不同的前端系统,部署在不同的虚拟交换机下。而后端系统部署在另外的虚拟交换机下。

 

问题三,应该选择什么网段?

 

网段选择涉及到两处,一是创建VPC的时候,二是创建虚拟交换机的时候。

 

对于VPC使用的网段,目前阿里云公有云默认提供下面三个标准私网网段给用户选择。

 


网段


可以主机数


备注


192.168.0.0/16


65532


去除系统占用地址


172.16.0.0/12


1048572


去除系统占用地址


10.0.0.0/8


16777212


去除系统占用地址

 

用户可以使用这些网段及其子网作为VPC的网段。

 

如果可能有多个VPC或者VPC和线下IDC有构建混合云的需求,建议使用上面这些标准网段的子网作为VPC的网段,掩码建议不超过/16。

 

注:如有除此之外的特殊网段要求,也可以提工单或者通过客户经理申请开通。

 

如果云上只有一个VPC并且不需要和线下IDC互通,那么选择以上任何一个网段或其子网均可,用户可自由选择,但需要注意的是,一旦选择后不可修改。

 

最后,VPC网段的选择还需要考虑到是否使用了经典网络。大家知道,经典网络的网段是10.0.0.0/8,如果用户在云上使用了经典网络,并且计划将经典网络的主机和VPC网络打通(阿里云正计划提供ClassicLink功能),以实现将经典网络迁移到VPC,那么,建议用户选择非10.0.0.0/8作为VPC的网段。

 

ClassicLink功能可以允许经典网络ECS和192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 三个VCP网段的主机通信,但只能和10.0.0.0/8中的特定虚拟交换机的网段通信,即,如果用户经典网络的ECS要和使用了10.0.0.0/8作为VPC网段的主机通信,那么该主机必须是某个特定的10.0.0.0/8下的子网,具体子网还未确定。因此,有ClassicLink功能需求的用户,建议选择非10.0.0.0/8作为VPC的网段。

对于虚拟交换机的网段。首先掩码必须在16到29之间。做这个限制的原因是/16掩码也能支持65532个主机,规模足够大了,没必要更大。而小于/29有太小,没有意义。

 

其次,虚拟交换机的网段要求和其VPC网段一样或者是其VPC网段的子网。比如VPC的网段是192.168.0.0/16,那么该VPC下的虚拟交换机的网段可以是192.168.0.0/16,也可以是192.168.0.0/17,一直到192.168.0.0/29。

 

最后,虚拟交换机网段的确定还需要考虑该交换机下容纳主机的数量。

 

问题四,云上存在多个VPC且和云下IDC需要互通,如何规划网段?

考虑如下图1.4,云上多VPC和云下IDC互通网段规划示意图,用户在华东1,华北2,华南1三个地域分别有VPC,并且华东1和华北2两个地域的VPC需要通过高速通道-VPC互联功能实现私网互通,华南1地域的VPC暂时没有和其它地域通信需求,但未来也可能和华北2的VPC私网通信。另外,用户在上海还有一个自建IDC,需要通过高速通道-专线功能和华东1的VPC私网互通。

 

图1.4 云上多VPC和云下IDC互通网段规划示意图

 

由于VPC之间,VPC和线下IDC之间需要互通的IP段不能相同,因此,上图中用户上海IDC,华东1 VPC1,华北2 VPC2 使用不同的网段。而华南1暂时没有和其它VPC之间互通的需求,因此,可以使用和华北2相同的网段,但考虑到将来华南1有和华北2可能有私网互通的需求,华南1 VPC3中的两个虚拟交换机的网段和华北2 VPC2 中虚拟交换机的网段规划使用不同的网段,也就是说VPC网段一样,但虚拟交换机的网段不一样。

 

总结一下,阿里云VPC互通要求要求地址不能冲突,指的是虚拟交换机的网段不能一样,但VPC的网段可以一样。当然,如前文说述,尽量规划不同VPC的网段不一样。

因此,在多VPC需要互通并且和线下IDC需要互通的情况下,可以总结如下的网段规划原则:

1)尽可能做到不同VPC的网段不同。不同VPC可以使用标准网段的子网来增加VPC可用的网段数。

2)如上面1)做不到,则尽量保证不同VPC的虚拟交换机网段不同。

3)如上面2)也做不到,则保证要通信的虚拟交换机网段不同。

 

可能还会有极端情况,如果线下IDC网段已经确定无法修改,云上VPC的网段也已经确定无法修改,但现在要通信怎么办呢?阿里云正在规划专线网关功能,可以解决这一问题。

 

另外,阿里云也会提供虚拟交换机网段可修改的功能,尽量帮助用户解决地址冲突和网络规划修改的问题。

时间: 2024-10-27 13:29:33

VPC最佳实践(一):网络规划篇的相关文章

经典网络迁移VPC最佳实践

摘要:阿里云起步于经典网络,但已经全面转向VPC.专有网络VPC以其在安全.成本和网络功能方面的优势,正受到越来越多用户的欢迎.在9月6日技术直播中,阿里云高级产品专家谭礼铨(李泉)为大家分享了经典网络迁移VPC最佳实践,本次分享介绍三种将ECS从经典网络迁移至VPC网络的途径,并阐述三种类型的迁移分别适合怎样的客户需求和场景. 直播回顾视频地址:https://yq.aliyun.com/webinar/play/287 9月21日,2017阿里云网络技术高峰论坛将独家线上直播,欢迎预约:ht

Web前端优化最佳实践之JavaScript篇

Web 前端优化最佳实践之 JavaScript 篇,这部分有 6 条规则,和 CSS 篇 重复的有几条.前端优化最佳实践,最重要的还是"实践",要理解这东西容易得很,关键是要去"实践",去"执行",去"反馈",去获取受益. 1. 脚本放到 HTML 代码页底部 (Put Scripts at the Bottom) 当一个脚本在下载的时候,浏览器干不了其它的事儿(串行了).所以,把它扔到最后面去处理.对于一些功能性的脚本,可

前端代码标准最佳实践:HTML篇

Web前端代码中,HTML是根本,CSS和JavaScript也是围绕着既有的HTML结构来构建,所以良好的HTML代码结构,除了提高了HTML代码的可读性,可维护性和执行性能之外,也可以让相对应的CSS和JavaScript代码更好的构建.距前面两篇探讨JavaScript(前端代码标准最佳实践:JavaScript篇)和CSS(前端代码标准最佳实践:CSS篇)之后,我们今天来探讨Web前端HTML的一些最佳实践. (1)HTML代码的基本规范 1. HTML的命名和格式 任何代码的混乱都是从

Web前端优化最佳实践之Cookie篇

Web 前端优化最佳实践第三部分面向 Cookie .目前只有 2 条实践规则. 1. 缩小 Cookie (Reduce Cookie Size) Cookie 是个很有趣的话题.根据 RFC 2109 的描述,每个客户端最多保持 300 个 Cookie,针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多,比如 Firefox 是 50 个) ,每个 Cookie 最多 4K,注意这里的 4K 根据不同的浏览器可能不是严格的 4096 .别扯远了,对于 Cookie

前端代码标准最佳实践:javascript篇

前言 最近一直重构项目的前端代码,也参考了各种前端代码的最佳实践,目的是让前端的HTML,CSS,JavaScript代码更符合标准,有更好的性能,更好的可维护性,尝到了重构后的甜头,也萌生了写这个系列博客的念头.前端代码有其固有的灵活性,这就导致了目前前端代码非常混乱的局面,本系列文章希望能起到抛砖引玉的作用,让更多的人重视前端代码的质量,编写更标准的前端代码. 本系列文章共有三篇,分别讨论HTML,CSS,Javascript,本篇将讨论Javascript. 目前,Javascript已广

前端代码标准最佳实践:CSS篇

上一篇<前端代码标准最佳实践:javascript>发表后,大家讨论还是很热烈,从侧面体现了前端工程师对写标准的前端代码的重视程度很高.这些最佳标准实践并不是那个权威组织发布的,而是由大量的前端工程师们在实践过程中的经验总结,目的在于提高代码的可读性,可维护性和性能.那么接着上一篇,我们再来谈谈CSS代码的一些标准实践. 1,命名 和其他语言规范一样,css的命名也讲究命名要有意义,命名要尽可能短但是要足够表达含义:命名的词用连字符连接. 不规范的命名: #navigation{ } .dem

Web前端优化最佳实践之Server篇

Web 前端优化最佳实践第二部分面向 Server .目前共计有 6 条实践规则.[注,这最多算技术笔记,查看最原始内容,还请访问:Exceptional Performance : Best Practices for Speeding Up Your Web Site ] 1. 使用 CDN (Use a Content Delivery Network) 国内 CDN 的普及还不够.不过我们有独特的电信.网通之间的问题,如果针对这个作优化,基本上也算能收到 CDN 或类似的效果吧(假装如此

Web前端优化最佳实践之CSS篇

Web 前端优化最佳实践第四部分面向 CSS.目前共计有 6 条实践规则.另请参见 Mozilla 开发者中心的文章:Writing Efficient CSS 1. 把 CSS 放到代码页上端 (Put Stylesheets at the Top) 官方的解释我觉得多少有点语焉不详.这一条其实和用户访问期望有关.CSS 放到最顶部,浏览器能够有针对性的对 HTML 页面从顶到下进行解析和渲染.没有人喜欢等待,而浏览器已经考虑到了这一点. 2. 避免 CSS 表达式 (Avoid CSS Ex

Canvas 最佳实践(性能篇)

Canvas 想必前端同学们都不陌生,它是 HTML5 新增的「画布」元素,允许我们使用 JavaScript 来绘制图形.目前,所有的主流浏览器都支持 Canvas. Canvas 最常见的用途是渲染动画.渲染动画的基本原理,无非是反复地擦除和重绘.为了动画的流畅,留给我渲染一帧的时间,只有短短的 16ms.在这 16ms 中,我不仅需要处理一些游戏逻辑,计算每个对象的位置.状态,还需要把它们都画出来.如果消耗的时间稍稍多了一些,用户就会感受到「卡顿」.所以,在编写动画(和游戏)的时候,我无时