用有限的带宽承载无限的需求:浅谈腾讯网络容量管理

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网络与服务器领域,规划、运营、研发、服务等层面的实战干货,期待与您的共同成长。

前言

又到一年春运时,在外忙碌了一整年的人们,为了实现春节回家全家团聚的愿望,“一票难求”的场面每年都在上演。尽管近年来由于航空、铁路、高速公路等各种交通方式的大力发展,交通运力在不断在提升,然而和社会需求相比运力仍然存在缺口,供需矛盾依然突出。如何在有限的交通运力情况下满足人们多样化出行需求是交通运输部门需要面对的问题。

随着腾讯业务的飞速发展,腾讯的网络带宽规模和承载的网络流量也在成倍的增长,我们构建了全球范围内的高速网络为腾讯业务提供7*24小时的网络服务,数据中心间互联达Tbps级别。然而由于实际客观因素网络带宽始终是有限的,如何合理的进行网络容量规划、分析,快速进行网络扩容与优化,在网络带宽有限的情况下满足业务需求是网络容量管理面临的挑战和要解决的问题。

网络容量管理类比城市交通治理

网络容量管理,是指对网络容量进行规划、分析、调整与优化的过程,其目的是在恰当的时间,以合理的成本,满足不同服务等级的业务需求。其核心理念分为三个阶段:

1事前:容量规划(你应该知道网络带宽能支撑多久)

2事中:容量监控(你应该知道网络带宽是否有瓶颈)

3事后:容量调整(你应该清楚该执行哪种带宽调整方案)

我们把网络容量管理类比城市交通治理,来对规划、监控、调整这三个阶段进行说明:首先,需要基于城市各片区的功能布局,做好交通调查和预测,制定一个宏观的交通总体规划,一个好的交通规划是能够以合理的出行成本,在各个时间段,满足居民通勤、货物运输等各种交通需求。其次,需要对城市交通运行情况进行监控,比如道路车流量、人流量和地铁客流量等,分析交通系统中可能存在的拥堵节点和路段,综合考虑建设周期(比如快速路和地铁新建至少需数年)在发生拥堵前启动交通调整方案。最后,根据实际需求进行城市交通调整,一方面需大力提升现有的交通运输能力,比如发展公共交通(地铁、公共汽车、电车)、修建快速主干道等;另外一方面也需加强城市交通管理,比如通过不同片区不同时段设置不同梯度的停车费来对车流量进行引导,比如在早晚高峰期设置公交车专用道优先保障大部分公众出行需求、设置潮汐车道来疏导交通等。

网络容量管理的难点与应对

网络容量管理是一项非常复杂的系统工程,下面笔者将结合腾讯网络容量管理工作实践就三个阶段面临的难点和应对方案进行阐述,希望可以起到抛砖引玉的作用。

1阶段一:事前容量规划

难点:业务需求难以预测,网络容量模型适用性

业务基于未来用户发展规模对产品做出相应的规划,然而由于互联网产品的特殊性,部分业务(如游戏)在其整个生命周期都难以实现set化部署,还有部分业务受制于服务器机型、机位资源供应等具体情况,最终也无法实现完全set化部署。因此,业务根据产品规划需要扩容时,无法类似集装箱一样精确计算需要的网络带宽资源,而只能根据接入、逻辑、存储各级的负载情况进行动态扩容,也就说业务对网络的带宽需求是不确定的,业务对现在和未来的网络容量难以预测。

应对方案:基于标准网络服务能力,构建通用网络容量模型

首先,我们根据业务服务器不同的通信用途将带宽区分为两种需求类型:内网和公网,其中内网又根据业务服务器之间的物理距离,从近到远依次定义不同的通信范围:Module(同一个IDC)、Campus(同一个园区)、Zone(同一个城市)、Region(由多个城市组成的片区)。

然后,我们通过对全网所有服务器的实际流量情况进行大数据分析,得出内网各个通信范围内和公网的流量现状以及增长趋势,我们定义为“网络服务能力”(如下图所示)。通过标准的“网络服务能力”可以构建通用的网络容量模型,从而指导网络架构需要具备的网络带宽能力,来满足未来可预见一段时间内业务的带宽需求。同时基于“网络服务能力”可以制定网络带宽年度预算并和业务进行对齐。

2阶段二:事中容量监控

难点:网络容量指标错综复杂,需要有限监控和分析

如何有限地监控网络容量指标,发现网络带宽存在的瓶颈,是网络容量管理中至关重要的一环。我们需要清楚地知道如下网络容量指标:设备负载、链路负载、流量要素组成、业务耦合关系等,基于网络容量指标运营情况来分析和判断网络带宽是否存在瓶颈,从而及时地启动容量调整方案。

应对方案:网管系统立体监控,合理设置预警阈值

腾讯智能网管系统从“点”到“线”到“面”实现了对网络容量指标的全方向立体监控,通过网元监控实时关注网络中各个节点的运营状态:如CPU利用率、端口流量等;通过网络监控实时了解各个节点通信形成的"线"和"面"的运营状态:如专线流量、出口流量、业务Netflow会话等。基于网管系统立体监控,我们对各项网络容量指标运营情况了如指掌,不但从全局上了解网络链路流量和利用率情况,并且从局部上也清晰业务流量中的要素组成以及业务模块间的依赖关系。

同时我们建立了网络容量管理规范,基于不同的网络结构和功能,明确网络容量管理标准,结合网络架构冗余理念通过预警阈值来判断网络带宽是否存在瓶颈。以下图为例来说明预警阈值如何设置,腾讯通过两台公网核心和运营商进行互联,将公网核心和运营商互联的所有链路作为一个容量管理单元来进行管理。

架构冗余最大可利用率

为了满足设备级冗余,即当两台核心中的其中一台故障时,出口流量能够通过另外一台核心完全支撑,同时考虑到链路负载不均衡的情况,将架构冗余最大可利用率设定为45%。

扩容周期

假设从发起扩容到扩容完成需要3个月,出口流量增长率为20%。

预警阀值

在扩容完成之前,出口利用率不能超过架构冗余最大可利用率,因此发起扩容时的出口利用率最多不能超过37.5%=45%/(1+20%),向下取整我们将预警阈值设定为35%。当出口利用率连续超过预警阀值,我们认为网络带宽存在瓶颈,需要启动容量调整方案。

3阶段三:事后容量调整

难点一:业务需求变化快,网络扩容周期不匹配

当发现网络带宽存在瓶颈时,网络扩容是一项行之有效、立竿见影的容量调整方案。对于常规业务带宽需求,我们在预警阈值触发后按照正常的网络扩容周期即可满足;然而并非所有业务需求都可提前预见,对于紧急突发场景带来的带宽需求(比如产品全新特性发布),相比业务两天一小版本、一周一大版本的迭代速度,网络扩容周期快则两个月,慢则半年的扩容周期根本无法匹配,不是网络容量管理团队不去想办法缩短网络扩容周期,实在是网络扩容涉及到的资源和环节太多,臣妾做不到啊。

应对方案:提前储备部分资源,进行应急支撑

网络扩容周期和紧急突发业务需求时间无法匹配,是不是网络扩容就只能被动挨打呢?我们换一种思路,既然网络扩容周期难以缩短,那么我们是不是可以想办法提前储备部分资源进行应急支撑,这样看似无解的问题就迎刃而解了,这就是我们所说的“提前储备应急支撑”的思路。实际上这种提前储备的方案操作起来并不简单,腾讯网络容量管理团队也在逐步摸索:我们将年度容量规划分节奏进行拆分,拿出部分网络扩容所需的内部资源,比如IDC中的光缆,DWDM波道等进行提前储备;而所需的外部资源,比如运营商出口带宽,我们提前和运营商对齐信息,确保运营商骨干网、省网/城域网、IDC网各个环节的带宽都能够满足腾讯的网络容量需求。我们变被动为主动,提前储备部分网络扩容所需的内部和外部资源,顺利支撑了业务紧急突发需求。

难点二:业务流量要素组成多样,需满足不同服务等级

网络扩容是容量调整的一项有效方案,然而受制于实际客观因素并非所有的网络带宽瓶颈都可以通过网络扩容来解决,在这种情况下有必要考虑通过业务流量优化来进行容量调整。一方面我们结合“网络服务能力”中不同范围的通信成本(距离越远,成本越高)推动业务主动进行碎片整理、腾挪迁移和流量整合,从而降低不必要的带宽需求;另一方面在异常流量导致网络拥塞的情况下,对于业务来讲,流量要素组成是多种多样的,不同流量的重要程度也不尽相同,有些流量涉及到核心模块需要重点保障,有些流量结合业务柔性可降级提供有损服务,还有部分非重点流量可接受丢弃。我们为业务提供不同等级的保障服务,根据业务不同的需求场景采取差异化处理。

应对方案:区分流量重要等级,实现差异化服务

我们可以把网络带宽类比为道路通行能力,当非工作日闲时所有车辆都能正常通行,然而当工作日早晚高峰期道路拥堵时,公交车、消防车、救护车等车辆需引导到专用车道优先通行,而超载大货车在部分主干道禁止通行,其他私家车则共享除专用道之外的其他车道。同样,业务可根据不同的需求场景将流量区分为不同的重要等级,通过对重要等级进行标识对应不同的优先级,放入不同的转发队列中。当网络带宽充足时,各个队列的数据包都能及时转发;当异常流量导致网络拥塞的情况下,针对不同服务等级的业务流量快速识别并进行差异化处理:重要程度高的流量予以重点保障确保及时转发,重要程度低的流量进行临时丢弃,重要程度中等的流量共享剩余带宽。差异化服务的前提是业务清楚核心需求是什么,梳理出关键路径和非关键路径,在带宽有限的情况下优先保住核心关键路径,在非关键路径中启用柔性策略,提供有损服务。

总结

综上所述,我们对网络容量管理中规划、监控、调整三个阶段四个难点进行层层剖析并严格把控:1 事前:对业务进行合理规划,建立通用网络容量模型,提供与业务需求相匹配的“网络服务能力”2事中:通过网管系统立体监控,摸清网络容量指标运营情况,合理设置网络容量预警阈值,分析和判断网络中存在的系统瓶颈。3事后:网络带宽扩容方面对于常规需求按照正常网络扩容周期满足,对于紧急突发需求通过提前储备资源应急支撑;业务流量优化方面结合不同通信成本推动业务主动进行流量整合,基于业务需求场景区分重要等级提供差异化服务。

在腾讯业务蓬勃发展对网络带宽需求爆发式增长的浪潮中,我们始终致力于打造网络容量管理的核心能力,在恰当的时间,以合理的成本,满足不同服务等级的业务需求,用有限的网络带宽承载无限的业务需求!本文只是网络容量管理的开篇,简单介绍了网络容量管理的方法论以及各个阶段面临的挑战和应对方案,腾讯网络容量管理近几年来摸爬滚打的工作实践和经验教训我们会在后面几期文章和大家进行探讨。

注1:凡注明来自“鹅厂网事”的文字和图片等作品,版权均属于“深圳市腾讯计算机系统有限公司”所有,未经官方授权,不得使用,如有违反,一经查实,将保留追究权利;

注2:本文图片部分来至互联网,如涉及相关版权问题,请联系judithliu@tencent.com。

原文发布于微信公众号 - 鹅厂网事(tencent_network)

原文发表时间:2016-02-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏我是攻城师

云计算之浅入了解

4864
来自专栏DevOps时代的专栏

CI/CD 和 DevOps 的过去和未来

本文由 DevOps时代高翻院整理发布 十年前,DevOps 的理念在 Andrew Shafer 和 Patrick Debois 两位先驱的脑海中酝酿。一...

5177
来自专栏申龙斌的程序人生

零基础学编程001:用在线编程环境快速上手

上次写的第一篇《零基础学编程》的文章,没想到还挺火,给了我继续写下去的动力。 编程之路从来都不轻松,一路上你要学习各种知识点,会遇到无数的阻碍,所以你要找到编程...

3196
来自专栏SDNLAB

混合云的杀手级应用:数据保护

对于企业来说,数据保护是将大量数据存储在云端的关键原因。最终所有数据都需要备份和归档,很多IT组织将云计算视为本地存储的最具成本效益的替代方案。 ? 这一策略的...

39111
来自专栏程序员互动联盟

为什么一定要学习python?

前几天看到一条新闻,说是高中生课程里面开设python课程了,这小孩子都来抢占市场了,这就是打了很多人的脸,特别是已经毕业很多年或者正在学校的人,小孩子都作为标...

3935
来自专栏鹅厂网事

基于服务器部件标准化的弹性运营方案

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

42810
来自专栏Jerry的SAP技术分享

SAP成都研究院飞机哥: SAP C4C中国本地化之微信聊天机器人的集成

今天的文章仍然来自Jerry的老同事,SAP成都研究院的张航(Zhang Harry)。关于他的背景介绍,请参考张航之前的文章:SAP成都研究院飞机哥:程序猿和...

1440
来自专栏WeTest质量开放平台团队的专栏

锤子发布会,天知道服务器都经历了什么!

对于任何的活动,产品来说,服务器往往是最后一关,也是必须要过的一关,对于众多企业来说,为了不要让自己的汗水白流,为了让自己的产品顺利发布,一定要在上线之前对自己...

1794
来自专栏大数据文摘

[干货]手把手带你了解实时看板(50PPT)

6142
来自专栏互联网数据官iCDO

【精华知识】初学者的高级谷歌分析指南-Episode 1

主编前言: 这篇文章我们请朱玉雪女士帮我们翻译自Avinash Kaushik先生的文章。了解Avinash Kaushik先生的朋友不对他的行文风格不会陌生—...

4345

扫码关注云+社区

领取腾讯云代金券