腾讯混合云网络设计白皮书

高歌猛进中的云市场

从1999年，公认的云计算先驱-Saleforce.com公司成立，到2006年，Amazon发布了名声大噪的EC2（Elastic Compute Cloud)，首次面向公众提供基础架构的云服务产品-IaaS，中间经历了七年的时间。

2007之后，云计算的商业化发展阶段也经历了从准备到起飞再到成熟的发展过程，2015开始进入成熟发展期后的云计算市场，2017年Q2相比2015年，公有云市场收益增加了35%，如果加上私有云，云化IDC收益则增加了整整51%，而传统IDC业务则下降了18%，在2017年到2018年云化IDC收益更是增加了53%。

即便受2020年开始的新冠疫情影响，全球经济下行的背景之下，2021年相比于2020公有云市场也增加了20%。

应运而生的混合云

在这样的大背景下，随着云计算的普及，企业逐渐将传统数据中心的业务应用迁移到云化数据中心。过去以IDC为中心的星形网络结构，正在演进到以云为中心网络结构。

迁移总是逐步、渐进进行的，这就势必会出现一种【客户传统数据中心业务和云化数据中心业务共存】的情况，我们把这种情况叫做混合云，这种共存的情况反映在网络层面，就是【传统DC网络和云数据中心虚拟化网络共存】，所以叫混合云网络，当然，随着时代的进步，传统数据中心也是要进行技术迭代的，在公有云普及之前，他们很可能已经利用不同厂家的技术进行了技术架构改造，比如使用了Vmvare或Docker等技术完成了传统架构向虚拟化私有云架构改造，另外基于行业不同特征而出现了像政务云、金融云、自动驾驶云等的行业云，因此广义上的混合云还应该包含公有云和私有云的混合。

辩证法认为事物发展的本质是新事物的产生和旧事物的灭亡，云市场的繁荣可能让人们直观上认为公有云势必会取代传统数据中心，混合云只不过是过渡的产物，但是从新事物的产生到旧事物的灭亡有时是一个漫长而又曲折的过程，一方面，出于平台异构容灾的考虑，很多企业将自己的数据或业务分布在不同的云厂商平台，形成多点开花的多云部署形态，并逐步被人们接受，另一方面，很多行业云用户既要出于安全性、隔离性等考虑将敏感业务或数据在行业云中闭环，同时又有能够使用公有云弹性计算能力，形成云上计算-云下存储的格局。因此混合云并非仅仅是过渡的产物，而是为满足客户业务上云且上云后稳定运行的长期产品形态。

混合云网络产品的选型

经济学中有个著名的“不可能三角”理论告诉人们在同一时间内，你没办法达成彼此相互作用的三个目标，例如你没办法找到一个同时满足低风险、高收益、高流通的理财产品，同样在混合云产品选型中你没办法找一个同时满足低成本、高效率、稳定性强的网络产品。

目前主流的混合云网络产品有两种，一种是云专线，以铺路的方式铺设一条用户机房到云数据中心的独享或与其他租户共享的物理链路，一种是VPN，以搭桥的方式构建一条用户机房到云数据中心加密的逻辑通道，前者兼具高效率、稳定性强的优势，后者由于大多数的VPN都基于运营商公网环境构建，因此在传输效率、和稳定性方面相比于云专线不具备优势，例如在腾讯云工单平台上我们统计分析发现运营商公网抖动、用户出口带宽拥塞是长期处于VPN工单TOP2的两类问题，VPN的优势更多体现在快速上线、成本低廉上。

但是我们不能因为产品天然的劣势，就采取“取长就短”的产品策略，而是坚持“取长也补短”，例如腾讯云持续加大投入新建专线接入点和边缘节点，尽可能靠近用户数据中心，降低用户采购长距光缆的费用等；持续加大投入新建公网基础设施，与国内外运营商/IXP平台加强合作提升腾讯云自身公网质量，进而提升用户VPN体验，助力用户迁移上云。

我们见到过在数据备份业务场景中，用户不堪VPN抖动之扰转而采用云专线来构建混合云的案例，特别是在大规模数据迁移或交互的混合云场景下，虽然专线前期投入的成本相对较高，但一旦在生产环境投产，随着数据量的上升，边际成本实际上比VPN越来越小，资金和时间成本反而会成为优势，这就是所谓的规模效应。

因此混合云网络产品中，云专线一直备受企业青睐，腾讯云专线上线至今，单客户最大接入带宽已达19T，同时，不断匹配和挖掘用户需求，在技术架构云专线产品也从第一代演进到了第三代。

云专线接入模型选择

传统的网络架构从容灾能力和复杂度由低到高依次可以划分为单链路、V字型、口字型、CLOS等4类，这种先入为主的设计理念毫无例外的扩展到了混合云云专线接入模型的选择中。腾讯云专线接入架构中通过广泛分布的POP（Point-Of-Presence）支持客户采用单链路、V字型、口字型组网以及基于这三类基础组网模型派生的混合型组网。

与其说是接入模型的选择，实则是容灾标准、业务场景的选择，单链路组网模型由于没有链路备份一旦出现故障赖以维系租户DC和公有云之间的桥梁便会中断，彼此之间形成孤岛，无法通信，这种模型显然不适合生产或实时通信业务，更适合例如非生产环境业务或实时性不强的业务。口字型组网则更适合生产环境业务，但是和一味追求成本优势就会损失容灾能力一样，如果我们持有容灾主义，一味追求容灾能力而忽视业务自身的特性和需求，实则也是一种效率损失。基于业务关键程度和故障容忍度选择满足容灾需求的组网模型是不二原则之一。

也正因为不同的组网模型反馈了用户业务的关键程度和故障的容忍度，腾讯云专线SLA承诺也会因客户选择的组网模型不同而有所差异，单链路组网以及基于单链路组网衍生出的双线单POP点组网模型不再SLA承诺的服务可用性范围内。

混合云的网络设计与规划

专线接入模型选定后就可以开始着手进行网络设计与规划了，设计一词更多被解释成“解决当下问题而给出的实现路径”，它着眼于当下需求；而规划一词体现的意义则更多着眼于未来而制定计划，这样的区分也是在提示人们混合云网络设计时既要考虑当下业务需求，解决实际问题，也要着眼未来网络设计时要考虑向下兼容和高扩展。混合云专线接入网络设计大致分为以下关键事项：

1. 网络架构设计
2. 路由设计
3. 可靠性设计
4. 容量规划
5. IP地址规划

网络架构设计

网络架构设计旨在依托业务布局，化繁为简地满足业务连通性需求并实现网络的可管可控，在经典的“云上计算-云下存储”业务布局基础上，云上业务布局又常常分为同城容灾和异地灾备，腾讯云通过在相同region建设物理距离相隔30-50公里不同AZ来支持租户业务分布式部署进而实现同城不同机房的容灾；另外通过遍布全球的region来支持租户业务实现异地灾备，腾讯云基础设施不仅覆盖京津冀、长三角、粤港澳大湾区等经济发展区，同时积极协同国家“东数西算”，优化数据中心布局的发展战略，在贵安新区、内蒙古张家口等中西部地区的云数据中心相继投产。

（一）同城双活

1）单AZ架构：业务在单AZ部署时，我们只需要在物理专线上创建逻辑的专线通道并关联到VPC所属的专线网关，便可实现云上与云下互通的基础架构。其中专线网关是云下IDC传统物理与云网络的纽带，他既是业务报文的翻译器，负责协议转换，又是路由的分发器，负责云上和云下路由分发。

2）双AZ单VPC架构：业务架构基于性能和容灾考量，可能会把单AZ部署的业务，扩展成双AZ或者三AZ形成同城双活的布局，显然使用上面的网络架构还是能适配应付这种情况，因为作为翻译器的专线网关节点是Region化基于VPC来创建并生产、管理整个VPC的信息的节点，因此单个专线网关实例可以与相同VPC下不同AZ的业务主机实现透明通信。

3）双AZ双VPC架构：随着业务种类的越来越多，在满足同城双活容灾前提下，不同业务可能还有相互隔离的诉求，VPC（Virtual Private Cloud，VPC）是基于腾讯云构建的专属云上网络空间，每个租户可以创建多个VPC，不同VPC之间无法直接通信，将有隔离诉求的不同业务部署在不同VPC被广泛应用在云网络中，于是通过支持802.1q协议，在一条物理链路上创建不同的子接口，即不同的子接口对应了不同的专用通道，不同的专用通道关联加入到不同VPC的专线网关，便形成了IDC与云上多个VPC这样的点到多点的网络架构：

由此可见VPC数量与通道数量成线性增长关系：dcx_q=k.vpc_q（dcx_q是通道数量，vpc_q是vpc数量，k是常量系数，表示DC与POP之间的物理线路数量），这种通道与VPC强耦合的网络设计增加后期网络管理的复杂度，这种复杂度上升直接导致的就是风险度上升，而且在DC网络内部往往具有很强的传导性，例如频繁的VPC上线带来的频繁的新通道配置变更可能会导致旧通道的配置覆盖或删除，并传导到DC内部引发路由震荡、产生瞬时路由黑洞，网络质量发生抖动。

（二）异地灾备

1）异地容灾架构：中国幅员辽阔，以秦岭-淮河划分的南北之间跨度多达5500公里，气候、地理地貌也有显著差异，租户业务异地灾备具备天然的地理条件，可以有效化解气象灾害和地质灾害引发的机房故障风险。例如华北region作为业务主站，同时选择华南region作为灾备业务部署区，那这种情况下如何解决华北的租户DC与华南Region之间的网络互通问题也是网络设计的重要环节。

云联网(Cloud Connect Network，CCN)：在腾讯云中将跨Region的流量分发和QOS/计费功能集成到了CCN即云连接网，因此CCN作为核心枢纽的网络架构，被应用到了同城灾备和异地容灾相结合的业务场景中，如下图所示，将专线网关和华北、华南VPC同时加入到一个云联网实例就可以便捷的实现用户IDC与本地域和跨地域的VPC实现全互通。值得注意的是：我们并没有为北京和广州VPC单独创建专线网关，而是通过云联网“代理”的方式实现与多个VPC的全连接，打破了“VPC数量与通道数量成线性增长”的关系，通道数量就等于物理线路数量，将网络架构化繁为简。

同时关联到云联网的不同VPC之间默认实现联通，长久以来实现VPC之间点对点互通对等连接(vpc peering)将逐步被云联网取代，成为实现VPC间互通的新生代网络产品，相比于对等连接，云联网在网络转发性能、集群容灾能力以及用户功能和操作方面进行了全面升级。

（三）总结

上述章节以V字型作为专线接入模型，依据租户业务同城灾备和异地容灾不同场景需求，陈述了对应的典型混合云网络架构，以及与混合云网络架构设计息息相关的主要有4个网络产品：

1. VPC：VPC控制器基于Region级别来设计，这就决定了租户VPC的通信范围是整个Region；
2. 子网：子网必须归属于某个VPC，因此子网内的主机通信范围也是整个Region，但出于租户网络可管可控、明晰边界的考虑，控制器严格限制子网必须归属某个AZ。
3. 专线网关：专线网关是混合云中协议的翻译器和路由的分发器，它被划分为两个大类：VPC型和云联网型，直接和VPC型关联实现点到点互通的专线网关即被定义为VPC型；和云联网关联的专线网关即被定义为云联网型，二者不支持混用，也无法直接进行转换，也就是你不能把VPC型的网关关联到云联网，更不能将已创建成功的VPC型专线网关转换为云联网型，反之亦然。
4. 云联网：云联网控制器基于全局Global设计，维护了全局的转发规则和路由信息，使得租户业务通信范围突破了地域限制，通过关联VPC/专线网关/VPN等丰富的实例类型实现混合云网络同地域或跨地域互通，此外他作为对等连接演进后的新生代产品，承接了VPC之间互访的功能。

路由设计

路由设计环节主要要考虑：

1. 在专用通道上使用何种路由协议向公有云发送租户DC的路由和从公有云接收VPC的路由；
2. 发送或者接收什么样的路由，将在《5.1 IP地址规划》阐述
3. 发送或者接收多少的路由，将在《5.1 IP地址规划》阐述

VPC和租户专线接入网络的边界

上图所示，以专线网关为分界线，划分为VPC和租户专线接入网络上下两个部分，正是因为专线网关处于VPC和专线接入网络边界这样一个得天独厚的位置，专线网关才被赋予了既是协议翻译器又是路由分发器的角色。

1. 面向租户接入网络方向：专线网关作为路由的载体，通过专线通道接收来自的DC的路由以及向DC发送VPC以及VPC中子网 CIDR；
2. 面向VPC内部方向：专线网关作为路由的载体，通过API向专线控制器上报更新DC的路由条目以及通过API接收来自专线控制器下发的VPC以及VPC中子网 CIDR。

路由协议设计

在网络边界明晰后，路由协议显然指的是租户接入网络侧即专用通道的路由协议选择，由于租户DC和公有云DC是不同的自治域，二者之间鲜有使用OSPF/ISIS等IGP路由协议进行路由交互，一方面，诸如OSPF这样的主流IGP协议路由的生成与发布依赖底层SPF算法，导致不同自治域间路由发布和策略不够灵活，导致网络管理上过于复杂，另一方面，IGP路由协议的路由过滤策略相较于BGP显得捉襟见肘，不利于实施灵活的安全管控。

腾讯云专用通道支持两种路由协议：1）BGP；2）静态路由，二者均遵循RFC标准协议设计，其中BGP路由协议，因其可控的路由发布和灵活的路由策略广泛被应用在公有云混合云网络中，腾讯云BGP支持用户将携带origin/as-path/next-hop公共属性以及MED/Community等可选属性的路由发布到专线网关，同时专线网关当关联多条专用通道形成ECMP之前，支持按照标准的BGP选路原则选取一条主用通道转发流量。另外静态路由常常被应用在路由规模较小且业务相对稳定，网络变更较少的网络模型中，除此之外租户DC或者职场的设备无法支持BGP协议和遵循安全管理规范也是导致网络管理员不得已使用静态路由的两个主要原因。附：BGP协议关键技术指标

专线网关与云联网间路由传递

在异地容灾网络架构中，专线网关会被关联到云联网，专线网关的路由将会通过云联网与VPC网络进行交互，同样他们间的所有交互都使用了API，如图所示，1）VPC路由通过{CCN控制器->DC控制器}路径下发到专线网关转发面，这个流程是自动实现的，不需要租户参与其中；2）专线网关上DC的路由通过{DC控制器->CCN控制器}路径上报到云联网，云联网控制器再负责下发到VPC，这个流程中专线网关将DC路由发送给云联网控制器时，可以选择两种方式：1）静态配置：租户在专线网关路由发布界面直接手工配置发布给云联网的网段，这些网段理论上应该被包含在专线网关通过专用通道从DC学习的网段范围之内，否则会导致路由黑洞；2）动态传递：当租户在专线网关界面选择动态传递后，专线网关默认会把当前专线网关的从DC学习的所有路由自动传递到云联网，值得关注的是，路由自动传递时会保留BGP路由的AS-PATH属性，用来云联网支持负载分担和主备的业务通信场景。

总结与建议

以专线网关为界限，租户路由设计指的是专线接入网络即专用通道路由协议设计，同时在云联网场景中还要考虑专线网关将DC路由传递到云联网的方式，我们建议二者均采用动态路由传递，主要原因如下：1）动态路由传递相比于静态配置方式更为简便更富有弹性，路由的新增或删除无需网络管理员频繁的变更；2）动态路由传递天然具备底层链路故障感知、路由切换的能力；3）专线网关路由自动传递到云联网能够有效规避因路由黑洞问题。

可靠性设计

我们已经通过专线接入模型进行了线路级、设备级、POP机房级的容灾选型，同时又进行了跨AZ或跨Regoin设计来支持业务同城双活或异地灾备的业务容灾需求，本节重点阐述从租户DC到租户VPC之间的路径上关键节点的可靠性设计以及关键节点故障切换设计。

关键网络节点的可靠性设计

1. DC：租户单DC场景中设备级容灾：至少满足双线双设备接入公有云POP；租户双DC场景中机房级容灾：至少满足双线双机房接入公有云POP。
2. 运营商专线：由于不同的专线提供商大多是有不同的物理铺设管道和路径，所以在双线接入场景下还是推荐使用不同的提供商，避免同一家运营商多条专线采用相同管道而出现的共点风险。
3. POP：腾讯云专线标准接入架构采用的是双POP，实现跨AZ容灾；专线控制器反亲和策略强制相同租户ID的两条专线接入每个POP内的不同交换机，用以实现单POP内设备级的容灾。
4. 专线网关和云联网：专线网关和云联网实例上的转发规则所在的物理集群，采用多AZ集群化部署，集群内部转发器故障和单AZ故障都可以实现故障自动化剔除，专线网关和云联网的是容灾能力是云平台基础能力，不仅在常规故障演习中切换性能表现不俗，而且在鲜有发生的AZ内部机房模块断电故障中实现故障秒级切换，实现故障切换过程业务无感知。

1. VPC：VPC仅仅是逻辑的概念，VPC内业务CVM访问时可以通过VPCID和租户ID来进行流量的隔离，VPC的容灾能力设计指的是VPC内业务主机的容灾部署即前文提到的单AZ部署、跨AZ部署、跨Region部署，在单AZ业务部署时可以通过置放群组策略，将置放群组内的CVM部署在不同宿主机、不同机柜甚至是不同机房模块进而实现主机级、机柜级、机房模块级别的AZ内部的物理容灾。

故障切换设计

巧妇难为无米之炊，如果我们在上述的关键节点或关键路径没有进行可靠性的设计，本身就存在单点风险，那故障切换便无从谈起，因此访问链路上存在备选节点和路径是故障切换的基本前提，根据备选节点类型和位置的不同以及路径上的不同又划分了不同的故障切换场景，分别是1）单网关双专线场景故障切换；2）双专线网关场景故障切换；3）双云联网场景故障切换；4）公网逃生故障切换

单网关双专线故障切换

• 前提条件

租户DC通过双线双点标准接入架构接入腾讯云，并创建运行BGP协议的专用通道关联到相同网关，DC与VPC的交互流量在两条专线上负载分担。

• 容灾等级

线路容灾-机房级容灾

• 故障切换

①POP2机房线路故障

②bgp进程在holdtime内未收到相应neighbor的keepalive报文

③相应BGP邻居状态机立刻进入Idle状态

④撤销RIB和FIB表项，路由收敛到POP1所在机房线路

⑤BGP邻居状态机与此同时会从Idle进入到connect再到Active进行反复TCP重连直到恢 复，路由重新收敛

注：处于亚健康状态下的线路频繁抖动时且短期内无法修复，为避免线路频繁抖动引发路由震荡，建议手工关闭BGP PEER或配置接口error-down。

• 关键配置项和技术标准

1. 腾讯云侧BFD采用控制报文双向检测模式，并非采用echo模式
2. 腾讯云侧BFD默认是单跳，但支持开启BFD多跳
3. 在BFD会话建立前，腾讯云专线网关会主动发起BFD控制报文进行协商；
4. 在BFD会话建立后，腾讯云专线网关会周期性发起控制报文进行保活检测；

NQA 基于ICMP单向探测，应用在腾讯云到租户DC方向，当租户静态路由未绑定BFD时，则强制租户开启并绑定NQA，来实现专线故障路由自动切换。

双专线网关场景故障切换

• 前提条件

租户使用双专线网关上联至云联网实例，并使用【自动传递(关于自动传递参见5.2 路由设计说明)】将DC路由自动发布至云联网，实现专用通道因专线故障发生的路由撤销能通过专线网关自动传导至云联网，DC与VPC的交互流量在两个专线网关上负载分担。

• 容灾等级

专线网关容灾-跨专线网关集群容灾

• 故障切换

①专线网关实例2所在的物理集群以及关联控制器发生故障

②专线网关实例2撤销发布至云联网的路DC，同时撤销发布至DC的VPC路由

③DC与VPC之间的流量交互从之前的双网关负载分担切换至专线网关实例1

• 关键配置项与技术标准

双云联网场景故障切换

• 前提条件

租户创建两个云联网实例，用户VPC分别加入到两个不同的云联网实例（该特性目前处于内测阶段，详情需咨询您的客户服务经理或通过腾讯云智能客服咨询）

• 容灾等级

专线网关容灾-跨云联网实例集群容灾

• 故障切换

①云联网实例2所在的物理集群以及关联控制器发生故障

②云联网实例2撤销已发布至VPC的DC路由，同时撤销发布至DC的VPC路由

③DC与VPC之间的流量交互从之前的双网关负载分担切换至云联网实例1

• 关键配置项与技术标准

公网逃生方案与VPC路由优先级

很多情况下，在地理距离、成本优化、业务上线周期等三重条件约束下，租户IDC更倾向于将专线铺设到公有云就近的一个接入点，但网络管理员严谨的工作作风势必会在效率与安全的冲突中另辟蹊径，专线和IPSEC VPN的组合方案便呼之欲出。

如下图所示，VPN网关实例直接关联到业务VPC，VPC路由表中存在两条相同前缀的DC但下一跳不同，一条指向云联网，一条指向VPN，由于云联网优先级高于VPN，则正常情况下主路径走专线去往DC，专线故障后，经过故障传导路由收敛后，自动切换至VPN的公网隧道路径上。除了支持云联网和VPN的主备，VPC路由表还支持下一跳为专线网关、云服务器、HAVIP等路由设置不同优先级，当前默认的优先级为：云联网>专线网关>VPN>云服务器或HAVIP。

在大带宽场景中，受限于VPN加解密性能以及公网质量，VPN逃生路径不可能完全承载全量业务，需要网络管理员进行业务分级，明细路由拆分的方式将容灾需求高的业务网段指向VPN实现逃生和服务降级。

总结及反亲和高可用设计

腾讯云为用户提供了基于自身业务需求通过上述产品组合来定制化网络可靠性的可选项，来应对低概率事件的发生，但公有云基础网络平台和依托基础网络业务需求催生的各种虚拟网关平台均实现了链路级、设备级、集群级、AZ级有些global业务组件还满足Region级容灾设计。

但是基础平台的可靠并不意味着租户业务就一定可靠，显而易见还要依赖业务自身的布局是否合理，例如云服务器通过加入到置放群组可以实现群组内的CVM分散在不同的物理机架或者不同的园区模块来避免鸡蛋放在一个篮子里，虽然腾讯云提供的篮子很多。在开源的openstack云操作系统中，nova-scheduler在选择计算节点前，会首先使用过滤器进行选择策略判断，其中有一个叫做反亲和的过滤器目的就是让虚拟机实例尽可能分散在不同的计算节点上，这便是反亲和策略。

为了避免鸡蛋放在一个篮子里带来的单点风险，腾讯云在专线接入、网关集群选择等方面均应用了反亲和策略：

• 同一个租户UIN，接入同一个POP点的所有物理专线反亲和，保证物理专线分散在不同的物理接入设备上；
• 同一个租户UIN，不同专线网关实例反亲和，保证不同实例分布到不同的物理集群。

容量规划

网络作为基础设施之一，以“公路”的形式为“汽车”提供服务，公路修的多宽要依据车流量来进行事先规划，道理虽然简单，但有的网络管理员，秉承“要想富先修路”的哲学，粗放型的修路搭桥，导致资源浪费，成本增加；另外有的网络管理员“节衣缩食”，不顾及业务的潜在增长，导致推到重来、重复建设，还有的网络管理员他们在粗放后走向过度集约，在过度集约后又走向粗放，在两个极端来回摇摆。

容量规划与成本息息相关，也正因如此，在具体实践中受到成本及其次生原因的影响尤为深刻，这也是造成上述三种情况的主要根因之一，但网络管理员需要自始至终习惯于把握业务发展的脉络，制定长期的容量规划。

直接容量规划法

• 侦察兵-问卷调查法：网络管理员充当侦察兵的角色深入业务线，特别是混合云场景下的业务以走访、问卷等形式调查各个业务的当前以及未来带宽容量需求
• 卧底警察-主动上报法：各个业务线运维人员作为“卧底警察”周期性主动上报业务运营水位和带宽压测数据，网络管理员进行过滤、聚合、分析后统计总需求

间接容量规划法

间接规划法，不再直接去统计业务数据，而是通过计算“锅灶”数量来推测“军队总兵力”，这里涉及两个环节：1）标的物的选择，除锅灶外，还有旗帜数量、厕所数量、香烟销售数量等，士兵可以不抽烟但不可以不上厕所、不吃不喝，因此锅灶、厕所数量比香烟销售数量更适合作为锚点；2）推算公式，我们可以按照历史数据（比如行军锅一般可以满足20人食用）和实地测试（比如现场做一锅饭来计算人数）来推测和演算。

1. 网络模块核心设备、网络园区核心设备、网络园区间边缘核心设备特别是混合云边缘设备基于月(或者周)统计平均流量，基于平均流量计算历史环比增长率；基于月均数据计算历史年均增长率，最终得到Rh，表示历史增长率，这个过程叫做基线和趋势分析
2. 此外还可以结合业务月活用户增长率或公司战略稳定性等调节上述流量增长率，最终得到调节后未来潜在增长率Rα
3. 基于历史增长率计算未来容量：V(t+n)=Vt(1+Rα)ⁿ，Vt表示当年容量，n表示未来n年，另一种比较直观的体现是按照70法则，如果每月保持10%的增长率，那么在70/10也就是7个月后可以实现总量翻一番；

容量管理

物理资源的扩容或缩容不是一蹴而就的，往往需要4-8周甚至更长时间的扩容周期，如果扩容周期内业务需求增长导致出现容量瓶颈就会出现业务性能问题，因此需要保证扩容周期要小于增长周期即N-X≧0，且X>T，X>T的意义在于网络管理员的基线趋势分析的时间周期至少要提前于扩容周期，前者在于何时启动扩容，后者在于基线分析算法优化，二者缺一不可。

按部就班的容量管理也会遭遇突如其来的非预期事件，例如链路故障、设备故障、机房电力故障这往往会导致健康的设备或链路短时间内发生排队和拥塞的情况发生，另外没有被充分评估过的变更事件也可能导致出现容量瓶颈，这就需要容量管理既要要考虑到安全的运营水位还要制定日常变更管理规范，保障网络的健康度。

IP地址规划

全局唯一

IP地址全局唯一是地址规划的首要原则，否则将产生子网冲突，不同网络机房间子网将无法实现三层路由，虽然使用NAT、大二层技术一定程度上可以解决此类问题，但是第一，增加了网络维护的复杂度；第二，支持NAT或者大二层并未是所有云服务提供商的基础通用能力，可能并不支持类似于VXLAN这样的大二层技术；第三，即便是云服务提供商提供了混合云场景中的NAT或大二层的能力，例如在混合云场景中，腾讯云专线网关通过支持单向和双向NAT的方式可以规避此类问题，但租户DC同样需要进行相应的网络配置甚至业务服务器上也要对服务IP进行变更，另外针对大二层场景，在DC接入设备、汇聚设备均有能力支持大二层技术的前提下，租户DC常常也要将纯三层网络调整为支持大二层技术（通常指VXLAN）的三层网络，这个调整属于重大网络变更，常常需要2-4小时的中断窗口。

同时网络管理员在地址规划时还有具有前瞻性，用以应对类似部门合并时网络融合产生的潜在地址冲突风险，我们知道，为避免因为人们的使用习惯、记忆惯性导致密码被轻易碰撞破解，网站管理员硬性要求用户密码不要包含生日、姓名、手机号等特殊字符，同样，地址规划时应尽可能避免使用192.168.10.0/24、172.16.10.0/24此类网段，因为相比之下诸如192.168.58.0/24、172.24.10.0/24更不容易与他人发生无意识“碰撞”。

可扩展

但是没有谁是天生的预言家，在一些情况下，网络管理员很难做到未雨绸缪，例如原本独立的两家垂直业务公司被战略整合成一家集团公司，于是他们间的网络互联互通变得顺理成章，而恰巧两家子公司存在子网规划冲突的问题。在上述预期之外地址冲突场景中腾讯云VPC支持租户通过增加辅助CIDR方式规避地址冲突问题，租户可以在云服务器上绑定分配了辅助CIDR下子网IP的弹性网卡，该子网可以关联在独立的路由表，专门用来与发生地址冲突的服务器来进行通信。

当然VPC辅助CIDR设计的另外一个目的是解决原有VPC CIDR地址容量不足的问题，因此不论怎样，网络管理员在地址规划时应当遵循可扩展的原则，进行地址预留，不同网络间的子网保留合理的“间隙”，尽可能在连续性的基础上保证可扩展性。

可管理

既要做到全局唯一，又要保持“间隙”，而且“间隙”要合理，否则会有出现地址浪费，这对于业务变更频率比较高的大型网络管理员来讲有时过于严苛，频繁的业务上线需求往往会使他们妥协，情非得已之下而以“见缝插针”的方式进行地址分配，这种情况下，就需要IP地址管理平台承接地址的分配和日常的管理，消解避免IP地址碎片化产生的复杂度以及可能出现的地址冲突、重叠、交叉等问题。

腾讯云云联网作为域内和域间VPC互联互通的“交通枢纽”，具有IP地址自动校验能力，当后加入到云联网路由与当前路由存在冲突、重叠、交叉时，后加入的路由条目将自动失效，避免发生目标地址路由异常后影响生产业务的情况发生。

技术演进

架构设计简化

在简化用户混合云网络架构设计方面，腾讯云进行了对等连接向云联网产品演进，将管理分散的对等连接整合到云联网统一管理，但通过云联网实现了租户DC与VPC全连接有时又无法满足租户隔离性或者按需连接的需求，因此云联网新增了【多路由表】的产品特性，租户将同一类安全级别的网络实例或者有连通需求的网络实例加入到相同路由表实现互通，不同路由表空间默认不能传递路由进而不能连通，借此实现架构归一的同时满足租户多样性的需求。

可靠性提升

腾讯云专线架构经历了第一代到第三代的技术迭代，第三代专线架构最明显特征之一是实现了转控分离，引入了腾讯自研分布式 SDN 路由系统（Disaggregated Software-Defined Router， DSR），从系统架构、路由控制、数据转发等层面避免单点故障：

• 在路由转发平面，DSR 通过多活技术为每个专用通道提供2个双活的路由系统，每个路由系统独立分布在不同的 DSR 集群上，同时 DSR 集群对外提供了2个腾讯云边界 IP 地址来实现控制面路由双活机制（active-active system），这样 IDC 侧本地路由器通过 BGP 协议分别与两个 DSR 集群分别建立了 BGP 邻居关系，有效的保证了 DSR 集群升级或者单集群故障时业务的高可用，避免因单 BGP 邻居中断导致路由收敛而对业务产生的影响 。
• 在数据转发面，DSR 系统通过大规模集群控制和自研集群扩展技术，实现海量数据和流量的分布式转发。在集群内通过实时监测机制动态调整并剔除异常服务节点，保证了单集群的可用性；集群间通过大规模集群扩展技术，实现用户业务在多个集群间横向扩容，确保了跨集群的可用性。

运营可视化

为支持租户容量管理与规划，在基础指标监控方面，腾讯云混合云产品支持全面的带宽、流量监控指标并提供丰富的 API接口供租户运营平台调用，在资源使用监控方面，腾讯云集成了专线、专线通道和专线网关不同周期和不同采集粒度的TOPN排名数据，供客户进行资源分析和规划。

另外经过不断的打磨的腾讯云顾问产品集成了云专线、云联网等混合云产品，可以对混合云架构进行主动分析和风险评级，识别网络架构中存在单点风险、架构版本隐患等问题，同时容量规划过程中，可以借助云顾问进行容量当前水位和未来趋势分析。

场景丰富化

• 云专线交付场景，腾讯云专线支持地图选点和专线自动化验收和通道自助调试
• 混合云演习场景，通过混沌系统支持租户进行专线主备切换演练
• 时延优化场景，支持租户相同地域和地域间时延可视化分析，同时借助于云联网精细化选路的特性对跨地域时延进行定向优化

腾讯混合云网络秉持以用户业务需求驱动技术演进的理念，始终贴合用户业务场景，以用户的视角审视混合云网络设计过程中的各个环节，不断进行技术打磨，支撑用户搭建一套架构简化、稳定可靠的高速混合云网络。

（完）