云社区 博客 博客详情

《云数据中心网络与SDN:技术架构与实现》——2.2 转控分离——白盒的曙光

华章计算机 发表于 2019-06-06 14:02:51 2019-06-06
0
0

【摘要】 本书摘自《云数据中心网络与SDN: 技术架构与实现》——书中第2章,第2.2.1节,作者是张晨。

2.2 转控分离——白盒的曙光

早在2003年,IETF就提出了一种名为ForCES的框架,将转发元件与控制元件分离,然后通过标准的接口实现控制,旨在加速转发平面和控制平面的创新。ForCES中,转发元件被称为FE,控制元件被称为CE,CE通过ForCES协议来控制FE的转发。CE和FE间在物理位置上没有必然的联系,可以位于一个机箱里通过背板互联,也可以通过以太网或者IP进行远端的互联。一个FE可以同时连接多个CE以实现主备或者负载均衡,CE和FE间的对应关系由CE-Manager和FE-Manager进行协商。ForCES框架下的工作流程分为Pre-association和Post-association两个阶段。Pre-association阶段中,首先CE-Manager和FE-Manager间会交换CE、FE的列表,然后CE-Manager告诉CE与之关联的FE的信息,FE-Manager告诉FE与之关联的CE的信息。Post-association阶段中,首先在CE和FE间进行认证、握手、能力协商和初始化配置,然后ForCES协议的通道就建立起来了。通道上的信令主要包括FE向CE发送不知道如何处理的数据报文、FE向CE转发入向的控制报文、CE向FE发送转发表、CE向FE发送出向控制报文、CE向FE请求一些统计数据等。ForCES协议只规范Post-association阶段的交互,Pre-association阶段的交互则不在ForCES协议的范围内。

可以看到,ForCES协议和OpenFlow在基本设计思路上是完全一致的。不过ForCES并没有像OpenFlow一样火起来,为什么?一方面,时机不够成熟,当时通信领域如日中天,OTT们还没有与设备厂商们掰手腕的想法,ForCES想法虽好但太过于超前了。另一方面,找错了切入点,ForCES的倡导者大多来自于高校和Intel,然而面向的却是IP设备,厂商在IP这块有绝对的话语权,当然不会放任ForCES胡来。厂商们为什么抵制ForCES?因为ForCES从根上动摇了厂商的利益。

网络设备这一块,从主板、交换芯片这些硬件到操作系统、协议实现这些软件,向来都是各路厂商自成体系,从硬件到软件一并都做了。这个模式有什么问题吗?试想如果WinTel不是两个公司的联盟,而是一家公司的话,PC肯定做不到今天这样普及,如果浏览器、游戏、即时通信等软件都被——操作系统套牢,PC上的应用也不可能像今天一样丰富。

很遗憾,网络设备这一块并没有形成WinTel的格局。软硬件的一体化,意味着用户不仅不清楚各个环节的成本,很多时候还要在买回盒子以后为软件的授权(License)另外付费。对于软件本身,用户也不知道它的实现细节,想要加一些新的功能必须依赖于厂商来做定制化。严密的技术封锁压制了市场竞争,网络设备长期由几个巨头把控,他们在分享着庞大的市场需求的同时,还能够获得高昂的产品利润。这些优势都得益于控制与转发的紧密耦合,也就是说,并不是厂商不接受ForCES转控分离的概念,而是他们不愿意将转控分离进行开放。一旦开放式的分离,就意味着软硬件的进一步分工成为可能,产业链必然面临重构。

不过,任何行业的发展都无法摆脱精细化分工的必然趋势,ForCES搞错了时机与切入点,但是没过几年需求就出现了。2005年前后,Google、Amazon这些OTT巨头的业务开始迅速扩展,对于服务器、存储和网络这些基础设施要进行大规模的建设。这些互联网巨头和电信运营商不同,他们对新技术的态度是更为开放的。首先,他们的技术能力非常强,对厂商不存在什么依赖感,一贯的路数是所有东西都自己来做,如果服务器、存储都能自己来做,网络为什么不行呢?而且,相比于运营商骨干网上的IP设备,数据中心在新建时存量设备的压力也比较小。于是,他们开始着手自己研发数据中心的交换机。

Google摸索出来的思路可以概括为以下三点。

1)从商用芯片公司买芯片,交换机上的软件自己来做。

2)采用CLOS结构进行整体组网,从Scale-Up转向Scale-Out。

3)部分控制逻辑集中化,和计算、存储统一管理编排。

从Google的角度来看,上述思路的最终目的都脱离不开降低成本。

1)和芯片公司谈好合作,根据芯片公司提供的SDK自己来做操作系统和协议栈,不用再为盒子中很多不必要的功能买单。

2)Scale-Out的思路中不再围绕网络中的大盒子进行组网,将一个大盒子分解成多个小盒子,容量不够了就再加一台设备,设备坏掉了就用任何其他设备顶替掉,总体上可以大幅度降低CAPEX。

3)集中式控制可以增强自动化的能力,还可以提供更好的流量调度与可视化,虽然开发集中式控制有一定的前期研发成本,但从长期来看是可以降低OPEX的。

然而,从传统网络设备厂商的角度来看,上述都是对传统网络的巨大冲击,Google的设备上将没有任何厂商的色彩,成了“白盒”,这可绝对不是什么好的兆头。

AWS的思路没有对外公开,但是整体的思路和Google应该是类似的。如果说Google关上门研究“黑科技”,设备厂商们作为“外人”没什么可说的,那么AWS于2012年将10亿美元的大单给了独立的白盒厂家,而没有选择Cisco,这可是公开向市场释放了白盒商用的信号,白盒开始正式走入了人们的视野。可以说2012年就是白盒交换机的“元年”。

相比于Google和AWS,Facebook起步要晚一些,直到2010年才开始自建数据中心,但是FB马上在2011年就有了一个大动作——成立开放计算项目(Open Compute Project,OCP),旨在开源数据中心所有的软硬件设计,想去掉所有传统的服务器和存储厂商,网络厂商自然也“不能幸免”。OCP可谓一鸣惊人,ATT、Verizon、微软、Rackspace、高盛这些体量的用户陆续加入。“白盒”也终于找到了组织,Intel、Broadcom、Mellanox这些商用芯片厂家开始开放芯片的SDK,Cumulus、BigSwitch、Pica8开始推广白盒的软件,Quanta、Accton这些ODM厂商开始跟进白盒的硬件集成与组装。Cisco和Juniper抵挡不过潮流,也在2015年初加入了OCP。随着Google于2016年加入OCP,OCP的影响力已经越来越大。不过AWS目前还没有动静,听闻他们甚至打算开始自己做芯片了,看来技术上的领先优势仍然是比较大的。

既然是分工,那么原来一家通吃的活就要分给不同的人家去做。分工后是什么样子呢?主要拆解成了4个部分,从下向上依次是芯片、机箱、操作系统以及控制与管理软件,如图2-1所示。下面分别从这4个部分对转控分离目前的进展进行具体的介绍。

image.png

图2-1 白盒的技术堆栈

2.2.1 芯片级开放

1. OpenNSL与OF-DPA

ASIC主要来讲讲Broadcom。Broadcom在SDN方向上主要供应的是Trident和Tomhawk两款ASIC,为OpenFlow和Overlay专门做了一些设计上的优化,目前大部分的白盒都是基于这两款芯片在做。ASIC的软件接口方面,Broadcom实际上与很多高校和OTT都有合作,允许他们通过Broadcom的SDK来进行开发,只不过要签NDA(NonDisclosure Agreement)。OCP来了之后,Broadcom把SDK进行了二次包装,然后开源出来贡献给了OCP,面向传统的L2/L3协议栈的API叫作OpenNSL,面向OpenFlow的API叫作OF-DPA。图2-2a是交换机本地的应用程序通过调用OpenNSL API来控制芯片的行为,图2-2b是通过JSON-RPC在远端调用OpenNSL API。图2-3是OpenFlow Agent收到远端控制器的OpenFlow消息后,在交换机本地转化成OF-DPA API来控制芯片的行为。

image.png

图2-2 交换机本地的应用调用OpenNSL API以及远端通过JSON-RPC调用OpenNSL API

image.png

图2-3 OpenFlow到OF-DPA的转换

OF-DPA内部实际上用的还是OpenNSL的库,不过向上提供的API不一样罢了。OpenNSL和OF-DPA提供的接口分别如图2-4和图2-5所示。之所以把OpenNSL和OF-DPA的API列在下面,是想要告诉读者一件事情,就是白盒的能力最后还是受限于芯片提供的API的,并不是控制器让做什么盒子就能做什么。


2. SAI

除了Broadcom以外,ASIC这一领域的选手还有Intel、Melllanox以及Cavium,国内的盛科这几年也逐渐打响了名声。转发的应用为ASIC写Adaptor可不是一件容易的事,有这么多的ASIC厂家,应用如果每移植到一个新的ASIC上去就要重写一次Adaptor,效率就太低了,于是又有人想了一个法子,在各家ASIC的SDK(比如Broadcom的OpenNSL)之上再做一层统一的抽象,ASIC厂商需要根据这层抽象把自家的SDK适配进去,这样转发的应用就可以在不同的ASIC间进行无缝移植了,这就是微软提出的SAI(Switch Abstraction Interface)。

image.png

图2-4 Broadcom OpenNSL提供的API

image.png

图2-5 Broadcom OF-DPA提供的API

SAI的架构如图2-6所示,其中ASIC SDK被称为Adaptor,一个Adaptor会根据SAI将ASIC中不同的功能适配到不同的Adapter Host中,Adaptor Host可以看作对不同ASIC中特定功能的抽象。Adaptor Host的概念说起来比较抽象,具体一点来说,MAC转发和IP转发是两个不同的Adaptor Host,一个ASIC如果既支持L2又支持L3,那么其SDK就需要把L2功能和L3功能分别适配到MAC Adaptor Host和IP Adaptor Host中,而不同ASIC的L2功能都会适配到MAC Adaptor Host中(熟悉ONOS的读者应该比较容易理解,Adaptor Host和Subsystem是类似的作用)。虽然SAI目前还不是很成熟,但是它对于转控分离的意义十分重大,目前已经有很多ASIC厂商提供了对于SAI的支持。

image.png

图2-6 SAI对不同的ASIC SDK进行抽象


登录后可下载附件,请登录或者注册

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
评论文章 //点赞 收藏 0
点赞
分享文章到微博
分享文章到朋友圈

上一篇:《KVM实战:原理、进阶与性能调优》一1.4.3 HyperV

下一篇:《云数据中心网络与SDN:技术架构与实现》——2.2.2 操作系统级开放

评论 (0)


登录后可评论,请 登录注册

评论