OpenStack中SDN泛谈1 (Neutron&ODL&ONOS)

专栏的初衷就是介绍OpenStack中SDN的种种，这个主题可以说是对题的。类似的题目很多前辈都说过，我也在这用一个系列来发表一下自己粗浅的观点吧。这个主题会在4月19日北京国家会议中心全球开源年会做一个简短的报告，先在知乎上分享一下吧。

网络的管控能力直接决定了计算集群的规模和性能，这不仅适用于传统的数据中心，也适用于虚拟化的云数据中心。OpenStack作为私有云IaaS的事实标准，其网络模块也一直是各个厂商和使用者关注的重点。

OpenStack Neutron

OpenStack自己官方的网络项目是Neutron，Neutron有着自己的一套网络实现方案：基于linux namespace，构建一个个相对独立的虚拟网络功能单元。通过这些网络功能单元提供OpenStack所需要的网络服务。前几年有争论说Neutron到底是不是SDN，不知道现在还有没有这样的争论？在我看来，Neutron就是SDN，因为它实现了网络资源的可编程控制，并且实现了网络控制层和数据转发层的分离，这个我在SDN闲聊里面曾经说过。基于OpenFlow的SDN方案只是狭义的SDN概念。

Neutron在自己的实现之外，也考虑了第三方功能的兼容，例如2层的功能被抽象到了ML2的mechanism driver，各个网络功能被抽象到了对应的service plugin。第三方SDN只需要实现相应的mechanism driver和service plugins，就能接入到OpenStack Neutron。进而在整个OpenStack环境下使用。Neutron的架构如下图所示：

抛开第三方SDN接入实现不说，单看Neutron的实现。Neutron大体上可以分成两个部分，Neutron server和agents。

Neutron server

Neutron的北向（northbound）接口，DB接口。Neutron server实现了网络数据模型的抽象，和基于这些抽象模型的业务逻辑。Neutron server有整个OpenStack的虚拟网络信息，有关网络的可达信息和统计数据的计算都将在Neutron server进行。Neutron server可以部署多个，以达到HA的效果，并达到水平扩展的目的。从划分Controller nodes，Network nodes和Compute nodes的角度来说，Neutron server属于Controller nodes。

Agents

Neutron的南向（southbound）接口。这里的agents指的是各种agents，例如DHCP agent，L3 agent，ovs-agent，metadata-agent，l2gw-agent等等。可以看出来，Neutron的具体网络功能是由一个个agent完成。Agents可以是Network nodes的一部分，也可以是Compute nodes的一部分，具体要看是什么agent，并且网络是集中式的还是分布式的。

RPC（Remote Procedure Call）

Neutron server与agents之间通过双向的RPC进行数据交互。也就是上面图中的message queue。

DB（Database）

Neutron通常与OpenStack其他项目共用一种SQL数据库。Neutron server是Neutron中与DB有交互的进程或者服务。

总结

OpenStack Neutron是OpenStack社区活跃的项目之一，集中了大量的工程师参与开发，也是各大公司重点投资的项目。在OpenStack场景下，Neutron的代码质量和一定用例下的稳定性，是其他SDN方案不能比的。不过它并不是完美的。

单看OpenStack Neutron，它不能提供一套完善的网络解决方案，早在Kilo版本，曾经在Neutron代码库中的LBaaS，VPNaaS，FWaaS的功能代码就被分离出Neutron。从那时起，OpenStack Neutron项目自身就致力于只提供2-3层网络服务，4-7层服务由Neutron的子项目提供。开源项目一个大问题就是开发碎片化，因为没有统一的管理。Neutron这样的拆分，能降低核心代码的管理难度，但无疑也加剧了碎片化的程度。分离出去的子项目发展不均衡，很多项目活跃度大大降低。

另一方面，基于SQL和RPC的网络计算实现，以及一些其他的实现细节，使得Neutron在大规模部署时表现不尽如人意。虽然近有一些文章和测试为Neutron的实现正名，但是具体的转变还是需要等待时间的验证。

总的来说，不像Ceph之于存储，OpenStack中不存在（包括Neutron自身的实现）一个压倒一切的SDN实现。这就导致各个厂商更热衷于在OpenStack中推广自家的SDN方案，而不是在一起开发一个默认的厂商中立的SDN方案（例如Neutron的默认实现）。这进而分散了Neutron的开发力量，使得Neutron的默认实现进步变得缓慢。

从现在的趋势来看，我认为OpenvSwitch已经是OpenStack的默认网络底层实现，根据之前的一项调查，有48%的OpenStack用户使用OpenvSwitch。OpenvSwitch社区自身也热衷于为OpenStack提供网络底层。上层网络方案上，各个厂商希望自己能够引领OpenStack的SDN实现，像Cisco，Midokura，Juniper，Huawei分别推出自己的SDN，甚至OVS也在推自己的SDN方案。这些SDN的共同特点是各自实现了4-7层的网络服务支持，有些也提供了更优化的2-3层实现。

接下来看看这些SDN吧。

OpenDayLight

ODL项目成立于2013年4月，是由Linux基金会管理管理的开源SDN项目。项目的目的是提供一个开放的，全功能的，厂商中立的SDN解决方案。目前ODL有超过40个公司作为成员，例如Cisco，IBM，Huawei等。乐观人士认为：ODL对networking的意义就像Linux对computing的意义一样。

ODL controller是一个纯软件的实现，基于Java+OSGI，运行在自己的JVM中，理论上，任何支持Java的设备都能运行ODL。采用OSGI作为框架，基于这点可以看出ODL内部是一个个相对独立的模块。ODL项目开始的定位是SDN controller，在它的第三个版本（Lithium版本），ODL将自己的定位变成了SDN Platform。也就是说ODL的定位开始转变成以SDN为核心构建生态系统。

ODL的架构大致如下，可以分为三层。

• Application Layer：逻辑业务层，不关心底部网络设备，网络协议的实现。通过RESTful接口和OSGI接入到Control Layer。
  
• Coordination，Control Layer：对应SDN控制器，实现网络功能，并将抽象网络模型转换成实际的网络底层数据，并下发到网络设备。Control Layer连接了Application Layer和Network Device Layer。使得Application Layer不必关心Network Device的变化性，而只需要关心业务逻辑，另一方面，同一个application通过Control Layer可以适配多种Network Device。
  
• Network Device Layer：网络设备层，各种各样的网络设备和网络协议，以及接入到ODL的plugin。

OpenStack Neutron通过networking-odl项目接入到OpenDayLight，目前networking-odl的架构如下图所示：

前面说过Neutron server可以部署多个，以达到HA和水平扩展的目的。ODL接入OpenStack Neutron也考虑了多个Neutron server的情况。Networking-odl包括了同步DB和通过RESTful API访问OpenDayLight。在OpenDayLight也加入了适配Neutron的module。OpenDayLight的详细架构如下图所示：

简单看一下ODL的架构组成部分：

ODL southbound protocol

ODL用来支持多种网络协议和网络设备的多个plugin的集合，通过OSGI框架与Service Abstraction Layer连接。为了支持OpenStack Neutron的接入，在ODL southbound protocol中加入了OVSDB的支持。ODL南向协议不仅支持OpenFlow，还支持很多其他协议，因此ODL可以认为是广义上的SDN。

Service Abstraction Layer

ODL中，SAL是重要的组成部分。SAL接收从Controller Platform来的service request，通过自身的plugin manager找到合适的plugin，也就是southbound protocol，进而通过这个plugin操作特定的网络设备。另一方面，SAL接收network devices的消息，通过plugin manager抽象消息，再转发给northbound模块。SAL是做northbound和southbound的实际转换工作。

Controller Platform

包含了Basic Network Service Function和Platform Service Function。前者是基本网络功能，后者是厂商平台对应的模块。为了适配OpenStack Neutron，在Platform Service Function中有一个OVSDB Neutron模块。

Northbound APIs

为Cloud Orchestrator和application提供接口。接口包括了RESTful和OSGI。

总结

论知名度，ODL可以说是负盛名的SDN，Linux基金会管理，各大厂商支持，使得它从诞生开始就是正规军。OpenDayLight和OpenStack的结合也是Neutron 前PTL Kyle Mestery极力推动下的结果。从其定位可以看出，它的功能也比较完善，现在也有基于OpenDayLight的解决方案（Cisco等厂商）在售或者部署在数据中心。

另一方面，ODL项目较为庞大，代码行数多，子项目多，ODL在Boron版本的子项目依赖如下图所示，可以看出还是比较复杂的。

并且，Cisco是背后的主要推动者，因此项目一定程度是由Cisco控制。作为开源项目，ODL文档也饱受诟病。综上所述，ODL的门槛要高一些，如果要落地，还是需要一个专业的团队支撑。

ONOS

ONOS（Open Network Operating System），是2014年由ON.Lab（Open Networking Lab）发起的一个开源项目（注，ON.Lab 去年底宣布与ONF合并，所以ONOS以后可能会看到是ONF支持的项目）。ONOS专门针对service provider场景，目的是提供一个SDN系统。这是一个与ODL有很多类似地方的项目。

• 它们都支持都是Linux基金会管理的项目
  
• 它们都基于OSGI实现
  
• 它们都支持多种南向协议，属于广义上的SDN
  
• 都是HA，模块化，可扩展的SDN
  

ONOS通过networking-onos项目与OpenStack集成。不过这个项目的参与度似乎很低。可见其与OpenStack的集成并不好。ONOS也是提供一个分层的结构，北向提供REST API，南向兼容多种网络协议和控制协议，简单看一下这个项目的架构吧。

可以分成三层：

• Provider：支持多种网络协议和控制协议，连接网络设备，并且读取网络设备的信息，向上发送的Manager。
  
• Manager：承上启下，连接Application和Provider。Store也位于这一层，store负责同步多个ONOS实例之间的数据。
  
• Application：ONOS的上层，业务逻辑层。

Services/Subsystems

ONOS由多个Service或者Subsystem组成，每个Subsystem由多个OSGI模块组成，这些模块分布在ONOS的三层中。ONOS的Service／Subsystem如下图所示：

总结

基于networking-onos的状态，讨论ONOS在OpenStack中的应用似乎意义不大。前面讲过ODL和ONOS的共同点，实际中有什么区别？ONOS的定位就是给SP用的SDN，例如电信运营商，因此AT&T将ONOS部署成local SDN controller，将ODL部署成global SDN controller。因为通常在电信应用场景下，环境是是多层的，可能不只一种SDN存在于大环境下。