百度SDN实践与思考

编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商、服务提供商等业界巨头纷纷参与此次大会。百度公司系统部副总监张诚发表了题为《百度SDN实践与思考》的演讲。

谢谢大家!谢谢组委会的组织!今天因为时间比较的有限,我讲的信息稍微多一些,时间上提醒我一下。今天跟大家分享的主题是“百度SDN实践与思考”,更多的是在过往七八年的时间,百度在SDN的尝试,以及在工程上的一些经验。

第一,我们为什么做SDN?我们的需求是什么?这个和传统的电信企业不太一样。

第一我管他叫还记得那年的青葱岁月,百度那个时候规模没有这么大,当时头疼的两个问题,我们4-7层用的都是商用交换机,在前端有前端的服务,有协议上的互通,我们业务向前迭代,商用的产品对我们来讲是黑盒子,厂商给我们的开发时间赶不上互联发展。

在那个时候开始很多的互联网的黑客比较喜欢攻击百度,那个时候我们有攻击流量,我们怎么预防,我们能不能把黑盒子功能抽出控制层面,然后我们开发迭代一些,我们有LVS的组织,我们想把流量分流出来进行分析,那个时候不是那么坚持,只是立项在调研开发。

然后之后我们听了一个名字,就是SDN网络,我觉得我们可以开始干了,在2009年的时候,百度的第一个产品,BVS以及我们BCS,就是把流量按照七比三分出来,进行缓冲预防。

以前大部分的开发适应我们的基础设施,因为他的工程建设周期相对比较长,你的产品的设计开发更多的适应硬件的平台,如果我们在数据中心基础层面,把控制层面剥离出来变成管理层,会使我们硬件发展变化一步,这样对软件开发有更多的好处,对我们互联网公司,我们网络平台不能直接的给公司带来利润或者商业的价值,对网络基础平台,对业务最大的好处是快速的支撑业务的发展和迭代。

但是当我们尝试做的时候,发现那个时候从2010到现在是中国互联网规模和信息爆炸的时候,服务器的快速的增长,他的扩张,我们跟不上硬件设施的发展,我们就没有办法控制了,我们回到价值的层面,在硬件基础设施平台上哪些东西需要抽象。按照SDN进行软件的管理,按照硬件工业的这种发展不断的进行快速标准的扩张。

最后我提出一个整个SDN在百度的思路是自我认知-不断否定-提升,谈不上某一个阶段对错,只有适合不适合。

第二,我们做SDN网络架构设计,做重构,但是我不提倡重构,他和软件开发不一样,他软件重构代价小很多,涉及硬件的,如果你重构的话你的成本非常大,另外你的周期非常的长,所以我认为,作为我们架构师或者我们基础设施的管理者,具备这样的素质,你在不同的阶段否定自己,但是你的重构应该是弹性可扩张的。

百度走过的路的时间纬度不一样,我们走的路不一定是自己最正确的方向,所以大家选择适合自己的方向是最好的。

百度为什么做SDN?主要是规模和效率的驱动,随着数据量的扩张,大概五六年前,中文有效的网络一百五六十亿的网页,现在超过了一千亿,现在百度面对数百万的要求,以及上线变更批量下线的要求,我们针对管理规模上的驱动。在SDN的一个架构在这个架构上面百度SDN的产品和系统开发,分成纵向三块的领域,右边我们更多的是在软件定义一些软件的功能。我们尝试用软件定义网络上的元器件,比如说流量检测、网络功能转发调度的设备,我们很多的产品在右边两个,最下面的是硬件,现在在百度,我们自己做了一个抽象层。我们今天做很多硬件上面最头疼的事情,我们面对不同的硬件的结构,这个跟我们互联网公司软件迭代的思路不相匹配,我们做了一个抽象层,他的意思就是说,对于下面的硬件,无论是硬件对上层开发是唯一的,他是一个翻译层,在我们自己研发的层面上,我们在百度他会去把我在硬件的芯片上,无论是你什么芯片等等的,对于我的OS来讲,我上层系统级的开发是整个层面都适配。

你想生产这样的产品要根据我们的规则产生,另外传输的层面,是一个很好的例子,SDN能给我们解决什么?其实对于百度来讲,给我解决最大的问题不要再纠结。因为我记得最早互联网公司,异地同传对于互联网公司我们运维和工程的人员大量的是网络出身,或者写编程出身的,转身做网络系统,运维产生的割裂,你要有人运维网络系统,所以在2008、2009、2010年我们使用其他技术,我们把传输和ED的网定义在一起,我们可以一个光纤分到很多的光波达到他的数据共享。

再往后发展,随着我们很多大量异地的数据中心,距离传输超过一千公里,而且带宽160、320、400G很难满足我们的要求,所以我们很难不建设这样的网络,所以SDN做了很好的融合。

我们自有的光产品,通过厂商的联合开发,运维拓展发展,我们可以把他剥离出来,并且和SDN做了一个融合,实现了统一的管理,这个我们做的不是很完善,我们在传输的层面不断的努力尝试,他的进展严格落后我们IP上面。

通过SDN解决的方案,反过来促使我们产品级的开发,和产品级的设计和我们硬件做一个结合。举出一个简单的例子,有的做过产品,那个时候没有做,很多的RD他很苦恼的,特别做高性能SPC,他很苦恼,你网络的带宽,为什么千兆,双千兆,我们可以提供以太网,或者我们可以提供40G的以太网,当你的基础平台不断迭代的时候,你可以给产品提供一个很大的想象的空间。

接下来是百度基于网络的架构,百度整个网络架构从2007到现在,经历了一个大版本的迭代,我简单的分享一下,从2007年到现在的话,最早我们做第一个版本的迭代,你的规模小的时候,我们把单用于,变成双用于,就是把胖的网络变成瘦的网络。

可以提高他的扩展性和稳定性,我们把三层的结构压成二层的结构,大家知道互联网数据中心,有内外网,那个时候我们用这种IPM的方式。把我们的内网流量,外网流量还有管理网的流量,通过控制层面做一个分流终结。4.0我们把IP并入我们的网络,5.0把数据中心做一个大的池子,使我们对外提供服务,未来基于开发者的公共的平台,包括百度的云平台再我们同一套基础设施,通过SDN的层面进行很好流量安全的控制和分发,时间的关系没有办法在每个幻灯片进行细说。

后面举几个例子,一个在运维管理上面的例子,第一,规模的问题的实践,现在基于SDN,我们在百度可以做到软件链路状态的监控,但是SNMP他经常会受到影响,你可以通过路由协议进行很好的监控。另外对于交换机你做到自己的研发,你在OS芯片进行监控,包括温度湿度感应。

包括降低数据中心的POE,就是省电,现在大家没有人用风能,大家得用水塔智能,另外提高数据中心的温度,你提高所有数据中心IT承载设备的温度,这样你可以探讨数据中心POE的提升。

另外报警,我们把很多的日志存储,做反复的迭代,我相信在很多的场合,现在百度对于服务器的硬盘的预警,我们在你没有发生故障的时候,我预测你会发生故障,然后进行批量的更换,这是人工的算法,如果没有SDN的架构,你很难把日志剥离出来。

大家现在说数据量越多越好,不是的,是你的高效数据和格式统一的数据越多,你的结果会更有效。在服务器的上线,插网线自动的安装,每年交互几千台服务器。

另外拥塞的监控,我们很多人基于SFLOW收集数据,很少建立好的模型,剔除到你的没有用的数据。

这是我们在工程产品上的例子,这是基于X86+DPDK的软件。这是我们百度自己研发的交换机,OS是我们自己研发的,加上ODMBOX,我们所有的都是用在我们百度自研的交换机。我现在在ODL的实践联盟里面,这是一个方向,我们在不断的尝试,我们和腾讯阿里在这个事情上不断的推进。

另外我们基于ODL做搭建一个网络,我们通过我们自己已有的TOR架构的网络,在流程自动化的层面看他的互动性和协作性,这种ODLOF做控制集以及传统网络互联,还有OFCONTROLLER研发。

最后这是我们对技术的展望,包括我们希望更多的看到我们的大流量,实际上基于大流量的芯片的检测,并且告诉应用层做处理,我们不希望在系统的层面消耗过多的资源,另外我们也是想,我们更关注的是25、50、100G的演进,实际上他倡导的联盟做的项目,把很多交换的芯片抽象到一个接口上面,使你的开发迭代更加的简单。

第三,说的抽象层,我跟大家倡议的,我们做这个联盟非常好的,今天的芯片厂商非常的多,ODM厂商更多,我们都要面对很多厂商的硬件,比如,今天给我们厂商发这种标准,他们按这个标准做的时候,使我们上层应用操作更简单,迭代更快。

另外我们做4G层的产品,和共有业务相关的硬件级的产品和平台,和我们产品更好的结合,未来想开放更多的IPO的开发,基于我们硬件平台进行他的开发创新,加快产品的迭代。

好的时间的关系,我今天的演讲到这,谢谢大家!

本文来源2015 SDN/NFV大会会议速记稿,不代表本站观点及立场。

想要获得更多关于大会的即时信息请关注SDNLAB

时间: 2024-08-11 03:34:20

百度SDN实践与思考的相关文章

中国联通SDN/NFV的思考与实践

编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商.服务提供商等业界巨头纷纷参与此次大会.中国联通技术部技术战略处经理裴小燕发表了题为<中国联通SDN/NFV的思考与实践>的演讲. 大家中午好!我简单的介绍,汇报一下中国联通对SDN/NFV的思考.我是制订公司发展战略的工作,因此借用网络上流行的话"世界很大,我们要去看看".我汇报的技术层面东西比较少,主要分享一下,我们去世界看看的一些结果. 关于运营商对于NFV的一些需求,我不

SDN 实践之floodlight控制器统计流量种类

SDN 实践之floodlight控制器统计流量种类 @温州大学12网工蒋暕青.郑明社 在floodlight控制器统计流量的基础上接着把packed-in流量的种类也区分一下.counter这个类琢磨了一个月终于有些会用了. 下面贴代码: 分两个.java 1. package edu.wzu.steve.trafficanalyser; import java.util.ArrayList; import java.util.Collection; import java.util.Hash

自动化接口用例从 1 到 1000 过程中的实践和思考

引言 当一个新人刚加入公司的时候,我们通常告诉新人怎么去写一个自动化用例:从工程配置到如何添加接口.如何使用断言,最后到如何将一个用例运行起来. 而在实际工作和业务场景中,我们常常面临着需要编写和组织一堆用例的情况:我们需要编写一个业务下的一系列的自动化接口用例,再把用例放到持续集成中不断运行.面临的问题比单纯让一个用例运行起来复杂的多. 本人加入公司不到一年,从写下第 1 个 case 开始,持续编写和运行了 1000 多个 case ,在这过程中有了一些思考.在本文中,和大家探论下如何编写大

基于Neutron的Kubernetes SDN实践经验之谈

首先,向大家科普下Kubernetes所选择的CNI网络接口,简单介绍下网络实现的背景. CNI即Container Network Interface,是一套容器网络的定义规范,包括方法规范.参数规范.响应规范等等.CNI只要求在容器创建时为容器分配网络资源.删除容器时释放网络资源.CNI与调用者之间的整个交互过程如下图所示: CNI实现与外界的交互都通过进程参数和环境变量传递,也只要求输出结果符合CNI规范即可,与实现语言也没什么特殊要求.比如Calico早期版本就使用Python实现了CN

关于百度云的一些思考

起因:不太常用网盘,今天蹲厕所前想拷个PDF到ipad上,用了女朋友的百度云 过程1:偶然的发现,PC端上传异常快,没有等待的过程基本上(PDF大小137M),鄙人2M的渣带宽,怎么也得有个几分钟上传的过程吧 过程2:ipad开始同步离线文件,直接就开始了下载,根本没有等待的过程 猜想:从过程1来看,显然是云端并没接收我的PDF,PDF源文件是网上下的较流行的电子书,未做修改.想来是通过计算hash值或其他方式指向云端的已有资源 实验:为证实猜想1,将PDF与一私人文件打包,再次共享,果然在短暂

【优秀博文】知乎服务化的实践与思考

作者:fleuria链接:https://zhuanlan.zhihu.com/p/24044342来源:知乎著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处. 服务化是知乎几年来技术演进故事里的一个主角,公司规模从几十人到几百人,在监控.tracing.框架.容器等基础设施从无到有的同时,也扩展出多个后端技术团队.在服务化演进的过程里,我们也进行了一些新的思考. 服务化的愿景 「微服务」 是业内最近两三年业内很火的 buzzword,迁移到微服务架构,大多强调这些好处: 松耦

百度地图的O2O思考:从工具化到服务化

前言:在O2O时代,每个地图都在画自己的O2O生态圈.在这个生态圈里,代理服务商.系统架构供应商.服务提供商.金融支付供应商与消费者有机地结合在一起. 百度世界大会上,李彦宏带着新产品“度秘”又秀了一把技术帝是如何做服务的,同时,百度不出意外地将各产品布局落子O2O服务.其中,作为O2O服务入口的百度地图打出了突破基础功能,向生活服务平台转型的迭代核心. 作为出行工具,地图时刻都在为人们提供出行的便利.传统的移动端数字地图服务,基本是围绕LBS功能开发上线的.作为地图这样的产品,在移动互联网 时

Java 小记 — RabbitMQ 的实践与思考

前言 本篇随笔将汇总一些我对消息队列 RabbitMQ 的认识,顺便谈谈其在高并发和秒杀系统中的具体应用. 1. 预备示例 想了下,还是先抛出一个简单示例,随后再根据其具体应用场景进行扩展,我觉得这样表述条理更清晰些. RabbitConfig: @Configuration public class RabbitConfig { @Bean public Queue callQueue() { return new Queue(MQConstant.CALL); } } Client: @Co

今日头条在消息服务平台和容灾体系建设方面的实践与思考

mPass 企业租户微服务开发平台 业务背景 今日头条的服务大量使用微服务,容器数目巨大,业务线繁多, Topic 的数量也非常多.另外,使用的语言比较繁杂,包括 Python,Go, C++, Java, JS 等,对于基础组件的接入,维护 SDK 的成本很高. 引入 RocketMQ 之前采用的消息队列是 NSQ 和 kafka , NSQ 是纯内存的消息队列,缺少消息的持久性,不落盘直接写到 Golang 的 channel 里,在并发量高的时候 CPU 利用率非常高,其优点是可以无限水平