版权声明:本文由梁定安原创文章,转载请注明出处:
文章原文连接:https://www.qcloud.com/community/article/224服务器
来源:腾云阁 https://www.qcloud.com/community网络
做者简介:梁定安,现就任于腾讯社交网络运营部,负责社交平台、增值业务的运维负责人,开放运维联盟专家委员,腾讯云布道师,腾讯课堂运维讲师。架构
SNG社交网络运营部管理着近10万台的Linux服务器,以此支撑着腾讯社交业务海量业务与用户,如日活2.47亿的QQ、月活5.96亿的QQ空间(数据来源:腾讯2016Q2财报)等众多千万级在线的胖子业务。框架
面对业务体量的不断增胖的社交类UGC业务,如何能既保证业务的发展,又能有效的控制运营成本的增加?是运维团队迫在眉睫要解决的运营成本难题。通过不断的探索和深挖,咱们庆幸在过去的2年中,找到了一条有效的设备成本管理的路子——精细化容量管理的设备成本优化之路,并连续2年,每一年为公司节约过亿的运营成本。运维
众所周知,提高设备的使用率是运维界经常使用的管控运营成本的有效办法,那么如何可以针对不一样的设备使用场景、不一样的设备类型制定出适宜的度量与管理办法呢?请看腾讯运维在实践中总结出的6个方法:分布式
在衡量服务器的使用合理性中,CPU使用率当仁不让的成为头号被关注对象。随着多核超线程技术CPU的普及,CPU负载不均的问题逐渐在海量运维场景下,成为了设备运营成本的吞噬者。性能
为了发现并优化多核CPU负载不均的现象,咱们提出了CPU极差的度量指标,
CPU(极差)=CPU(max)-CPU(min)
,若CPU(极差)>30%,则该设备存在CPU使用率不合理的问题,需优化整改。
(备注:优化方法可参考多队列网卡优化与CPU亲和,本文不展开)。优化
同理,在分布式集群的模块容量管理中,运维规范要求实现模块的一致性管理,包括容量一致性,为此咱们一样提出模块的容量极差的度量指标,模块CPU使用率极差= CPU最高的IP的CPU使用率 - CPU最低的设备的CPU使用率
,若同模块下不一样设备的CPU使用率极差>30%,则该模块容量使用不合理,须要优化整改。
(备注:通常此类状况源于配置、权重、调度等不一致管理问题,不问不展开。)spa
对于内存使用的合理性,很难直接用内存使用率来度量,为此,在内存型设备使用中,咱们提出了密度管理的管控办法——访问密度。访问密度计算公式:,模块下的设备内存访问密度应该一致,不然归入负载不均的一致性整改范畴。经过对全量内存型模块访问密度的统计分析,咱们能够得出一条平均负载水平线,结合容量管理的实际须要,提升平均水平线或优化低于水平线的模块,都能实现优化设备成本管理的目的。同时,密度管理法也适用于SSD盘的使用场景。(备注:访问密度会受业务请求包大小的影响,可是在海量的运维场景下,个别状况能够忽略。)线程
特性管理法,同功能模块的QPS管理相似,就是用来衡量在特定业务场景下,业务逻辑的处理性能是否最优,要结合不一样产品下的同类应用场景的QPS同比来得出分析结论。这种管理办法因业务逻辑而异,本文主要举例说明下。
例如,在移动互联网的业务运维场景中,有些场景是很是规容量管理手段能度量的,针对一些个性可是规模庞大的模块,咱们提出了特性管理法。举个例子,QQ、QQ空间、信鸽等业务都有长链接功能模块,该场景的容量CPU少而使用内存多,所以可使用每G内存维持的长链接数量来横向比较QQ、QQ空间、信鸽等业务,督促性能低的业务程序整改优化。
又例如,在直播场景中,有对主播视频实时在线转码的需求,不一样的开发可能使用的转码技术方案不一,也能够利用一样的特性管理法来衡量在线转码的性能是否有优化空间。
腾讯社交网络业务历史悠久,从“大哥”QQ到“新秀”企鹅FM,业务类型覆盖IM、UGC、多媒体、阅读、动漫、游戏、直播等主流的娱乐化社交玩法,其中有当红的产品,也有长尾的产品;有几十亿次每秒功能模块,也有几十次每秒的功能模块。碎片化管理法,就是针对请求量不高的小集群准备的。由于分布式高可用的运维要求,一般生产环境的部署最小单元都为2台设备,在物理机时代,访问量小的模块浪费成本严重,但随着虚拟化技术的普遍应用,该场景遇到的问题迎刃而解。利用虚拟化技术将硬件资源碎片化,让小模块能够很好的兼顾设备成本和高可用。
与虚拟化解决碎片资源利用率的方案相似,咱们还有PaaS平台“蜂巢”,基于腾讯社交的标准开发框架SPP,解决小业务小模块的容量管理难题。(后续专题聊蜂巢。)
腾讯平台级的业务,如QQ、QQ空间、QQ音乐等,基本上都普及了三地三活的SET(专区)容灾架构能力,这是真正意义上的异地多活。(正巧在923上海运维大会的海量运维专场,会有个主题与异地容灾的海量运维实践分享,若是你们感兴趣的话,诚邀你们参加。)对于平台级业务的运维,咱们会根据运维规范管理的要求,将实现必定业务场景的多个模块划分为SET(减小运维对象),在不一样的社交场景下,咱们就得出了各类不一样类型的SET,经过自动化运维能力扩大到SET的自动化运维能力,运维能很轻松的实现SET异地化部署,如此实现该业务场景异地多活的容灾容错。
再说SET的容量管理,平台级SET就意味着用户量和请求量不会暴增,那么对于SET的可运维性而言,咱们必需要对SET的请求量和用户量等指标进行量化度量。为此,运维赋予SET一个可量化的指标,在咱们的场景下,如在线用户数、核心请求量等视SET的用途而定,基于压测能够获得单SET的最合理的容量值,该值符合木桶原理,也就是咱们的木桶管理法,SET由多个模块组成(SET=木桶,模块=木板),支撑必定的用户量,SET的容量管理就像木桶原理同样,木桶的水位高低取决于最短板,所以SET的最大容量取决于SET中性能最低的模块容量。
腾讯的平台级业务同时在线用户数是相对稳定的,也就意味着全国要实现多地多活,须要准备多少冗余容量是可预期可规划的,换而言之,要部署的SET的数量是能被提早量化的。同时,结合业务的自动化部署、调度方案、柔性策略和有损服务能力,咱们就能够利用很合理的成本就能实现异地多活。
举例说明,假设咱们共有1000w的同时在线用户,且用户量相对稳定,咱们就能够规划3个支撑500w在线的SET,利用业务架构的调度能力分别让3个SET的容量平均化,在灾难场景时,1个SET不可用,另外两个SET能够彻底容灾,在此规划下,极端场景2个SET不可用是要开有损服务的。经过量化SET管理,业务运维则能够灵活的根据成本管理的需求调整SET的容量水位,以达到最优性价比的高可用架构。
关注硬件瓶颈,升级硬件下降单机运营成本。好比,过去作UGC内存存储时(QQ相册、视频),使用了大量2T硬盘,当4T、8T硬盘成本量产使用,及时的升级硬盘容量,能够有效的提高单机存储量,以规模效应实现花小价格换来了大成本。又如,在图片社交或视频社交的业务场景下,因玩法的多样性需求,会延伸出不少计算量繁重的逻辑,像人脸识别、鉴黄等功能,这时候选用GPU设备代替CPU设备,也是让性能飞的一种有效作法。(该方法尤其适用于UGC类的存储量只增不减的业务,如微云、网盘、图片存储、视频存储等。)
包括但不限于上述6种容量管理的方法,使得咱们能在用户数据只增不减社交UGC业务中,能稳步的可持续前行。设备成本管理还涉及不少细节的技术手段和业务代码优化,本文只是从运维的视角阐述对容量管理的思考,但愿可以抛砖引玉,对各位同行有帮助。带宽成本管理的优化带来的成本节省价值会更大,由于其中涉及的技术点和方法论更多,此文不深刻探讨。