【科技范】百度:走在自动化运维的路上

标签:大数据安全存储技术产品

访客:38310  发表于:2014-05-21 15:01:37

用过百度的人都有着这样的认识:访问速度快、信息刷新快、资料全面、使用便捷等。也正是有了如上的体验,越来越多的人喜欢并使用上了百度。作为一家互联网企业,百度就像一台“大型IT机器”,通过互联网为数亿用户提供便捷的信息服务,以满足用户的高体验感需求以及使用规模的快速膨胀。


目前,百度这台大型IT机器,已发展到15000个机架、200000台服务器、2000PB的存储规模,但令人意想不到的是,所有这些IT设备,只有不到50人的运维团队进行维护,平均每人维护5000台服务器。为了支撑这台“大”机器的正常运转,百度量化了维护能力:服务器装机能力要达到1500台/天,硬盘更换能力3000块/周,每个新业务上线不得多于12天……只有这样,才能满足互联网公司业务快速部署的要求。事实上,所有这些都应归功于百度公司的“自动化平台”,正是因为有了这个平台,百度的运维才有了高效可靠的实时保障。

 

所谓“自动化平台”


如今看来简单易用的自动化平台,在运维安全的保障方面发挥了不可或缺的作用。


百度自动化平台肇始于2008年,作为当时的第一个版本还比较简单,只是个部署在服务器上的Agent,网络用的还是SNMP、Syslog进行告警的简单应用。不过到今天为止,百度的自动化平台已经产生过7、8个版本,两次重构。面对越来越复杂的实际情况,百度实现自动化主要从三方面进行考虑。


首先,实现平台化。平台化的实现需要把所有逻辑业务在平台上的关系由接口间调用变成模块对模块的关系。这个关系就像H3C的OS ,他的底层有个Kernal平台,它上面的每一个功能,如OSPF协议、VTP协议、温度传感协议都是一个模块。这样就使得所有新功能的上线不需要研发团队开发。只要开放接口,有业务需求的任何团队,在接口标准下都可以自己去开发前端。同时,这也使得逻辑流程关系的梳理变得非常简单,就是模块对模块,所以平台是非常重要的。


其次,要有开放的平台和系统。作为一个平台,不可能汇总所有的需求,这样会面临漫长的研发计划,同时业务部门上线也会非常着急。所以平台和系统必须有开放的接口,让业务部门有能力按照这种规范去自行开发。类似于苹果的APP开发,只需给个工具包,自己就可以进行简单的开发。所以首先应当是平台的开放。其次,即使是自动化,也要有管理实体,比如通常的三大块:服务器、网络设备、数据中心的基础设施——风火水电、UPS、柴油机、风冷系统、水冷系统、低空管道、传感器等。这三大块不是一个黑盒子,可以从中提取信息,确保在发现问题时,对它进行合理的控制、操作。所以开放可定义的系统是非常重要的。


目前,百度的软硬件系统都是基于开放系统自研或定制的。比如,基于大数据的Deep learning系统、基于SDN架构开发的网络平台、LVS的LoadBalance,防攻击的检测, TOR交换机、CDN平台等。


最后,应实现通用的架构设计。整个服务器架构、网络的架构,或是整个基础设施的基础架构,必须是非常通用的。否则,自动化平台就会面临严重的问题,比如在管理两个数据中心时,不同的架构设计,使得你没有办法进行扩展和统一化管理。

 

肇始:规模效应的推动


那么经过这么多年的发展,究竟是什么推动着百度的自动化运维呢?答案就是“规模”,包括了容量、密度、扩展性和传输四个纬度。


百度数据中心最初只有500台服务器,后来由于业务需要,希望一个中心能够放置2000台、10000台,现在甚至会出现一个数据中心集群10万台、30万台的规模。耗能也是如此,最开始单机架的密度功耗10A就够了(7~8台通用服务器),通过对通用服务器核心部件进行优化,x86服务器单机一天的功耗已经由原来的2A降到了0.8A。同样的空间内,要安装更多实体的服务器,单机架就需要更高的供电能力。目前,百度自建的DC,单机架供电是32A~40A,规模从区域性到全国。就现有的几十个DC来看,每个DC都有几百G甚至1T的数据互联。


面对效益,自动化虽然解决了很多问题,但当自动化发展到极致时,自动化平台也会成为其最大的隐患。很多公司都出现过类似的案例:上线运营的DC由于程序间的逻辑错误,使得大量服务器重新安装了一遍系统、刷了一遍BIOS,把这些机器当成了新上线的设备。所以,必须有一个专门做DC基础设施、全自动化平台风险管控的团队。


除了容量、密度等方面的因素,互联网企业还会遇到扩展性以及传输等问题。例如,网元节点的爆炸式增长所带来诸多的问题。如果在线有10万台的网络设备,传统的网络协议是否还吃得消, OSPF协议的规划还行吗?是否有优化的协议,或者优化组合的协议?是优化现在的还是迁移到更优质的协议上去?


海量数据的跨地域交互也是一个问题。数据读取和计算需要把数据拖来拖去。某互联网公司曾经要求应用开发人员,增加本地的计算能力,但后来发现,数据就是要反复的被拖拽,经常有被计算了20轮的中间结果,被其他应用作为其初始数据的情况发生。所以,会有海量的跨地域计算出现。现在看来单波100G是够的,一根光纤可以跑3T,那么,未来上了粗媒体等业务后是否够呢?

  

奠基:网路架构演进


2008年到2010年,百度服务器的性能还不足1000Mbits,并为此进行了一次改造,最大的改变是把服务器的双网卡变成了单网卡,实现服务器瘦身,同时,计算环境的简化也使得网络更适合进行自动化管理。在这个过程中,发现做互联网中心最大的问题是内外网的负载均衡,于是百度采用了基于LVS的技术架构自己开发产品。


2011年至2012年,百度又做了一个网络,但容易出现层级、监控点较多的问题,不适宜提升效率,因此百度选择做扁平化的网络。架构的调整,意味着自动化平台更加简单,逻辑模块也更为简单。我们了解到百度4.0架构的目的就是让网络结构和服务器结构变得更加智能,去年百度提出了“让应用更好地感知到网络和服务器”,因为也只有这样软硬件的协同效率才会更好。

 

基于大数据的自动化运维


如果说统一平台化、开放的系统、通用的架设计三要素是百度实现自动化平台的基础,那么系统运行中的大数据分析则是自动化平台的核心。百度大数据系统,通过收集、分析微观数据,总结系统的运行、故障经验,并形成关键运维知识库,为百度自动化运维提供了决策依据。


百度基础设施运维要求所有的日常操作都需要工单审批,包括服务器的上下架、资产管理、变更等全部都要统一入口;另一个是监控平台查看服务器、系统OS;最后还有自动化平台,是服务器和网络的操作平台。


上面之间的互操作都是通过统一的API接口进行调用,好处是所有的操作数据、监控数据都是集中存储的,可以更好的实现数据共享和挖掘。


百度IDC的监控系统,可以进行机房监控。通过它帮助降低POE,降低POE最好的方式是降低用电。从变电站到机房可节省的部分是非常有限的,最好的方法就是让服务器降低能耗。而服务器耗电最多的就是主板、电源、风扇,其中最耗电的是风扇,让风扇少转,就是提高服务器的运行温度。


监控系统还可以监控服务器的温度、电压监控。这是一个数据共享、深度挖掘的典型案例,百度对数据可以作两件事情。很多人认为X86服务器硬盘坏了,唯一能做的事情就是换硬盘,硬盘换多了就是换机器。实际上,通过大量的数据分析发现,大多数的硬盘损坏,只是坏掉了一个扇区,自动化平台可以通过主动调用接口程序将这块磁盘的扇区隔离掉。另外,通过大数据分析,可以做硬盘故障预警。通过深度挖掘硬盘的告警、日志,可以提前预知哪些硬盘可能要坏了,这样就可以安排一个窗口进行统一的更换。


另外一块是网络监控,2010年百度就实现了基于大数据的故障告警的筛选功能,即从若干关联事件中筛选出重点事件进行告警,目前百度正在做人工辅助系统,它将基于以前的处理流程,在没有人工干预的前提下智能的推进进度。所有这些监控数据都可用于建模,使自动化平台建设更智能,而这一切都要归功于基于大数据的Deep Learning平台。

 

网络运维


再有,当百度遇到大规模网络建设时,主要挑战是更多网络设备的配置、告警;对带宽拥塞管理、提高使用率。


网络自动化做了几件事。大家通常的做法:比如网络设备的监控通常是基于SNMP、Syslog然后定期日志监控。但是SNMP是UTP协议,可能会存在一些误发、丢包,Syslog不同厂商的级别定义不一样、甚至没有定义。但是对于数据挖掘的时代任何数据都是有意义的。而百度用的是协议探针,通过在网络上部署探针,模拟网络设备,从而进行全网的路由协议互通,当网路出现故障时,这个设备也会故障,从而根据其故障特征,来判断他有什么问题。当然也会辅助SNMP、Syslog进行校正。另外,百度还采用了SDN Netconf技术,在做监控时可以配合很多操作,这些操作在百度自研的设备上、4~7层的设备上都很好实现,但对于第三方的网络核心设备却没有办法,而H3C的核心设备S12500是第一家实现与百度通过Netconf互通的。


再有就是交换机的初始化配置,比如自动化下发,百度的服务器和网络设备到了机房上柜后,工人就可以离开了。然后所有设备的安装全是通过自动化实现的,整个过程4~5小时。


另外一个就是批量问题,一般是通过脚本向设备上配置,但配置的生效性、完整性都不知道。百度仍然采用Netconf的方式,Netconf有三次握手来确保配置有效。2013年的自动化操作率已达到97%。 手动一般是大型割接,比如骨干网割接。


关于大规模网络运维的第二个关键问题是拥塞管理。当网络变大、服务器增多后,网络流量管理将成为问题,每个业务都说自己需要增长,如何提高每个业务的带宽使用率。解决办法就是Qos,但对于这么大的中心,怎么做?百度的思路是重服务器轻网络。通常学网络的人都喜欢在网络上打标记。而百度是通过服务器来打标记的,打标记是最耗资源的,因为服务器的CPU性能远远高于网络CPU性能。网络只要辨识、调度标记就行了。


(注:以上所有日志分析、训练模型都是复用百度公司的Deeplearning团队,在他们的帮助下建设了很多训练模型,包括日志存储平台。百度的整个服务器全是分布式架构、分布式存储,全都是基于HDFS的。所有的训练模型都是运行在分布式计算的通用平台上,百度叫它Mapreduse架构,这就形成了百度大数据挖掘的基础。) 


百度自动化运维包含:自动安装,资产管理(配置、厂商、规格、所在的机架位置等信息),内核升级几个模块。这些自动化管理的大多数操作都会基于百度DeepLearning的大数据挖掘系统完成,如果把百度公司比喻为一台大机器,那么自动化运维能力就代表了这台机器的先进性,则大数据能力就代表了这台机器的性能,大数据是百度自动化运维的基础。


来源:H3C内刊

评论(0)

您可以在评论框内@您的好友一起参与讨论!

<--script type="text/javascript">BAIDU_CLB_fillSlot("927898");