百度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的开发，基于我们硬件平台进行他的开发创新，加快大家产品的迭代。
好的时间的关系，我今天的演讲到这，谢谢大家！