2018-10-17 09:30

　　杨志华：大家早上好，很高兴来到数据中心网络分会场，我们今天要分享的内容都是常年做网络的BAT、运营商用户及行业大厂给大家准备的，希望大家有什么想法、建议随时给我们提出来。另外因为时间关系，我们每个演讲之后允许在场观众提一个问题，其他的更多的欢迎线下沟通。

　　下午我们还有个圆桌论坛，也请到了相关专家进行讨论，大家可以一起现场共同探讨。另外我们在ODCC展台也有现场的凤凰发行版展示，6家芯片厂商的白盒硬件都在运行凤凰发行版软件，大家也可以现场感受。

　　今天的第一个话题是我跟大家分享的MSDC网络进化论，主要是几个方面，一个是从ODCC看到的行业背景与挑战，另外超大规模数据中心下的挑战趋势，以及未来我们能跟大家一起做什么。

　　我们做网络的就要谈需求，有很多人在讨论金融业务、社交业务、电商业务、云业务，对网络有不同的需求，这是非常重要的方面。如果站在更高层面来看，业务需求有更顶层的看法，很有代表性的一点就是看你的业务是否是全栈业务，就是你所在的公司对这个业务，从基础设施到中间件、数据库、用户接入是不是都包括。

　　这一类全栈业务相对来说没有这么高要求，大家可以想一想，这些业务的同学可以用很多层面相互补充，有很多层次很多地方可以发挥，自己可以做很多工作，这时候对网络要求没那么高，当然网络稳定性也是至关重要的。

　　其他的一些非全栈业务就完全不一样了，最典型的是公有云业务，能掌控的方面基本只能到虚拟机操作系统层面。第三方业务部署在公有云的IaaS系统上，从用户接入到数据库都是第三方自主的，这时候就发现业务能掌控的层次就比较少了，这是非常大的差异，这时候业务对网络的要求就会更多更高。从大的背景来看，将来会有越来越多的非全栈业务，尤其是云计算、大数据、人工智能，都讲平台化，这时候可能就会面临这方面挑战。

　　看这个业务背景大家可以体会到，如果业务背景的要求是寸土必争，那你怎么去满足业务需求呢？还是十多年前，二十年前就成熟的的东西搞定吗？不可能的。而且寸土必争的含义是什么？是非常典型的“既要、又要、还要”，就跟去4S店买车一样，既要有奔驰的安全性又要有宝马的操控性，还要有吉利的廉价，那是买不到这样的车的。但是在网络领域我们是可以部分实现的。

　　当我们可以自己打造自己所需要的网络，自己掌握了网络技术栈的时候，就可以在很大程度上实现“既要又要还要”。

　　所以我们今天看网络的变化，如果说达尔文的进化论是适者生存，今天整个行业网络进化的方式就变成了技术栈的掌控。大的技术方向都是逐渐朝着有利于最终用户技术掌控的方向发展。

　　技术掌控不应该是大公司巨头做的事情吗？我们能做吗？5年前可能做不了，但是现在我们已经有了很多基础，在这个基础之上我们可以做很多事情。

　　今天技术趋势是有利于拥护掌握技术栈的方向，举几个例子。第一个在数据中心里单芯片Box替代框式设备。传统框式设备至少都是两级芯片的clos结构，我们简化之后变成每个设备一个芯片的节点，这样一个变化导致数据中心内部流量端到端的跳数从11跳变5跳，如果竞争对手是5Hops的话，你是11Hops，你这个仗还没打就输了一半，时延时别人的2倍还多，成本是它的几倍。

　　这时候很多人会说，单芯片盒子就能做大数据中心了吗？当然可以。比如说今天12.8T的芯片可以作出128*100G的box，对于大部分人来说是够了，另外架构上还可以有一些scale out设计。甚有人说单芯片密度够不高用于汇聚会缩小数据中心规模，这方面也可以做一些扩展，大家有兴趣的话我们可以私下讨论，这是第一个大的趋势。

　　从这个意义上说，将来数据中心设备的选择会极简，只要选择大容量单芯片做Box就可以了，这比框式设备难度降低了很多倍，这是第一个趋势。

　　第二个趋势就是Small Buffer芯片，不管是理论上还是实践，其实今天数据中心内部设备的主流都是往这方面转移，好处是成本可以大幅降低，落地周期更短。

　　为什么要用Small Buffer设备呢？这是斯坦福大学的一个研究结果供大家参考。如果Flow数量很少，或者Flow之间强同步，拥塞的时候Buffer可以按照时延和带宽计算。对于核心级设备，整个数据中心的流量flow数量很多，而且很多没有强同步性。理论上可以证明，比单一流或者同步流的需求有flow数量平方根除数的关系。如果有100个flow，Buffer就是原来的1/10。如果是非常轻载几乎没有拥塞的话，Buffer的数量还可以大幅减少。如果有兴趣的话也可以研究一下数据中心的流量，甚至可以看一下设备Buffer的情况。

　　以往我们会选deep buffer设备，感觉保险一些，某种程度上是这样，但是面对业务“既要又要还要”的时候就要做更仔细的考虑了。

　　另外软硬件的解耦，软硬件周期、特点、发展速度都不一样，紧耦合在一起的时候哪个都很难做到最好。解耦之后可以有更多硬件的选择，不管是标准化硬件的还是自己定制，都可以。软件方面既可以使用第三方软件，也可以自己研发，商业厂商也许也可以单独提供。有这样越来越多的选择。在设备层面上就可以有自己的选择和控制，也可以由自己的研发。以往传统运维层面上顶多是通过SNMP、Netconf等应用级接口来做。现在不仅可以基于API做还可以自己根据自己的需求，做一些在代码层面的定制，当然也可以用一些标准化组件。

　　除了刚才说的这些之外，还有什么长远的好处呢？可以掌控自己的稳定性和运维能力。比如说，从运维角度，网络变更、系统升级是免不了的，但是传统上来说可能会有问题，设备不通了、系统重启会导致业务中断，我们希望有一种技术说改完之后重启一下但是不断流，从专业术语上来说warmboot温启动。

　　这有一定的难度，但是从芯片角度来讲很长时间以来都是可以支持的，十多年前商业厂商就有类似ISSU这种高大上的专业技术，但是需要双引擎支持，在Box级别设备上做不到。但今天开源社区软件，比如SONiC就在开发中，今天基于开源社区的基础我们是可以实现的。

　　如果我们再细看的话，列出来的这些领域里还有很多，比如说我们做网络软件的通常会碰到DPDK/XDP加速需求，一种趋势Kernel Bypass，另外一种是保留Kernel原有的功能，包括安全这方面。这方面我们不做详细讨论了，有兴趣的话我们可以有更多的线下讨论机会。

　　谈了这么多，我们ODCC能给大家提供什么呢？

　　一方面我们会在开放硬件方面做一些工作，从AOC包括开放光模块方面都会制定技术规范，在国际标准基础上有一些细化，通过有些关键参数来保障互联互通的兼容性。也有一些会员贡献交换机硬件设计，会把逻辑设计告诉大家，甚至还有一些更深入的细节。更进一步，我们在工作组层面希望将来做白盒硬件标准技术规范，包括最佳实践的设计建议。这时候大家可以依据技术规范最佳实践选择相应的市场白盒，也可以在这个基础上再做一些定制。

　　软件方面我们开展了一年，初衷就是希望推动在今天软硬件解耦的趋势下解决软件方面的问题，我们自己如果要独立研发一款交换机软件的话难于上青天，因为投入非常大。但是今天我们基于开源社区相对变得容易了。SONiC及在此基础的凤凰发行版，大的互联网公司都在开发代码，都在用，大家可以借鉴，既可以直接使用也可以进一步参与代码开发，站在巨人的肩膀上可以走得更远。

　　我分享的部分就到这里。