分享

百度为什么做SDN?需求是什么?



编者按:2015中国SDN/NFV大会在北京召开,本次大会围绕SDN/NFV展开讨论,来自运营商、服务提供商等业界巨头纷纷参与此次大会。百度公司系统部副总监张诚发表了题为《百度SDN实践与思考》的演讲。
谢谢大家!谢谢组委会的组织!今天因为时间比较的有限,我讲的信息稍微多一些,时间上提醒我一下。今天跟大家分享的主题是“百度SDN实践与思考”,更多的是在过往七八年的时间,百度在SDN的尝试,以及在工程上的一些经验。
pt-004-zhangcheng-12-2015-04-23.jpg

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

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

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

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

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

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

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

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

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

20150423-004-3.jpg

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

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

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

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

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

20150423-004-4.jpg

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

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

20150423-004-2.jpg

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

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

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

另外拥塞的监控,我们很多人基于SFLOW收集数据,很少建立好的模型,剔除到你的没有用的数据。
这是我们在工程产品上的例子,这是基于X86+DPDK的软件。这是我们百度自己研发的交换机,OS是我们自己研发的,加上ODMBOX,我们所有的都是用在我们百度自研的交换机。我现在在ODL的实践联盟里面,这是一个方向,我们在不断的尝试,我们和腾讯阿里在这个事情上不断的推进。

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

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

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

另外我们做4G层的产品,和共有业务相关的硬件级的产品和平台,和我们产品更好的结合,未来想开放更多的IPO的开发,基于我们硬件平台进行他的开发创新,加快产品的迭代。
好的时间的关系,我今天的演讲到这,谢谢大家!



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





欢迎加入about云群371358502、39327136,云计算爱好者群,亦可关注about云腾讯认证空间||关注本站微信

没找到任何评论,期待你打破沉寂

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

推荐上一条 /2 下一条