百度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大会会议速记稿，不代表本站观点及立场。

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