在软件定义网络(SDN)中，控制器是网络架构中至关重要的一个点，它处在网络应用和网络设备之间。对网络专业人士来说，集中化的控制器担负着控制平面的作用，而控制平面就是传统上各种分布式路由协议如BGP和OSPF等驻留的所在。

目前，我们仍处在SDN的初期阶段，众多的组织和厂商都在想方设法力图控制或者支配SDN的发展，因此出现了大量可供选择的控制器也就不足为奇了。一般而言，SDN控制器可以分成如下一些类别：

● 科研用SDN控制器项目

● 厂商支持的开源SDN控制器项目

● 有特定用途、厂商专用的控制器产品

事实上，一些刚刚知道SDN的用户可能会因为选择的众多而不知所措。

但如果作更进一步的审视，我们就会看到在SDN控制器市场上，有一个趋势逐渐清晰——那就是控制器的整合。尽管仍然有很多不同类型的控制器在售卖，但却开始缓慢而明确地看到了两个关键性的集合点，而且都是在开源社区出现的。一个是Linux基金会的OpenDaylight(ODL)项目。另一个则是ON.Lab的开放网络操作系统(ONOS)。

这种整合趋势是SDN发展进程中非常重要的一步。

●控制器太多已经阻碍了SDN在企业中的普及。因为在初期阶段，很好有企业会去押宝某个SDN控制器，尤其是还要围绕该平台构建一个新的业务策略，这就更得慎而又慎了。因此，整合就意味着企业可以作出选择，依靠某个控制器长期运转了。

●对互操作性感兴趣的厂商也会因控制器太多而受到影响。但是，随着ODL和ONOS被广泛接受，厂商便可选择其中一种来开发自己的控制器，又不会冒自己的产品最终可能成为孤儿的风险。

●一些SDN应用开发商早就在采取“坐等”的态度，因为要支持一个能在多种控制器平台上运行的应用，时间和资金成本都不会少。一旦整个行业基本稳定在ODL和ONOS上之后，应用开发商便可为这些平台推出相应的产品。

此外，科研用SDN控制器项目也并非什么贡献都没有。科研院所在这方面的努力至少在概念验证、尝试各种新的想法方面是很有用的。只不过它们不是为规模化工作而设计的，也不可能适用于企业或服务提供商可能有的所有SDN用例。

另外，某家厂商所设计的垂直整合型控制器一般只用于它们自己的生态系统，它需要特殊的堆栈，在统一的产品线中才能工作。这些厂商专用的控制器不太可能长期存在下去，因为它们总是有可能需要与其他厂商的产品相互集成或者互操作。

这并不是一件坏事。在用户的网络中有空间可以容纳不只一台控制器，这主要取决于想要解决的问题以及所使用的产品。不过让人感兴趣的是，有一部分整合运动来自厂商。有不少厂商主要基于开源项目，特别是基于OpenDaylight来开发自己的控制器。

下面我们就来看一看整合趋势下的这两种SDN控制器的发展情况。

1、OpenDaylight(ODL)

OpenDaylight项目形成于2013年，可以说是一个开放的厂商联合体，主要目的是要研发模块化SDN控制器。这个项目是真正开源的，任何人都可以贡献有用的代码、文档、或想法，共同利用IRC论坛参与项目，尤其可公开访问各类会议、维基条目等等，来推动项目的进展。

ODL对自己初期的巨大成功相当满意，而且还不断有厂商加入进来，贡献代码，参与治理进程。ODL刚刚庆祝了两周岁生日，在此过程中，它所取得的几个关键性成就包括：

-20个ODL用户组，成员多达千余人

-实际部署案例，涉及各类组织，如科研院所、电信厂商以及政府部门等

-对基于YANG的建模逐渐达成了一致，YANG是一个描述网络设备的配置和状态的标准(IETF)模块化方式

-设置策略，力图将现实世界的商业策略转换成网络配置

对于策略设置而言，虽然大多数人都认为，必须以可编程方式去定义含义不清的策略概念，但是策略本身充满着挑战。要将一个策略概念翻译成一个特定的任务要求，就需要在具有不同功能的各种网络设备之上构建一个复杂的抽象层。这一抽象层的目的是：如何才能最好地表达出策略意图?如何最好地抽象出该意图?在定义策略时，需要哪些配置步骤去满足这种有着特定表述方式的，或者仅仅是有暗示内容的策略呢?又该如何让设备自己去决定怎样满足策略的要求呢?

这些都是很复杂的问题，好在ODL就是行业内一个探讨策略定义的重要项目之一。OpenStack的Congress项目也是聚焦策略定义的另一个关键的开源项目。思科同样表达了它对策略定义的观点，并向开源社区提交了它的OpFlex协议。

虽然有人批评ODL的成员“厂商太多，用户太少”，但ODL已部分解决了这一问题，成立了一个ODL咨询小组。ODL的执行董事Neela Jacques对该咨询组的表述是，“汇集了业界的思想领袖、工程师，以及领导着金融、企业、电信和云服务商的顶尖架构师们。”该小组将为“路线图、功能优先顺序以及用例的开发提供指导。”因为ODL的所有会议都有记录，因此咨询小组的所有讨论内容都是公开的，任何人都可以查阅。

ODL一直在持续不断地进行软件升级，但主版本只发布过两个，即2014年2月发布的氢(Hydrogen)版和2014年9月发布的氦(Helium)版。目前最新的版本是2015年3月发布的氦-SR3。

该项目的发展势头很好，不断有新的代码在开发和维护，不断有大量的合作伙伴加入进来提供各种支持。不过更让人感兴趣的事实是，有些厂商正以ODL为基础开发他们自己的控制器。

例如博科的Vyatta控制器就是基于OpenDaylight开发的。博科正计划将控制器代码回馈给该项目以便改进ODL。极进网络的OneController也是基于OpenDaylight开发的，而且已经有用户在其网站上进行部署了，例如康涅狄格州的恩菲尔德小镇，还有玛丽山大学等。

思科的开放SDN控制器同样是基于OpenDaylight开发的。思科一直是该项目的主要贡献者，同时也是白金合作伙伴，其他白金合作伙伴还有博科、思杰、戴尔、爱立信、惠普、英特尔和红帽。

还有两款面向运营商的OpenDaylight控制器是Ciena的多层广域网控制器和ConteXtream的ContexNet。当然还有其他厂商基于OpenDaylight开发的控制器，这些都说明OpenDaylight正在被业界广泛接受。而且，企业和服务商的用例也开始出现。

2、开放网络操作系统(ONOS)

然而，正获得业界广泛支持的并非只有OpenDaylight这一个开源控制器项目。最近几个月来，ON.Lab的开放网络操作系统(ONOS)项目也已引起了业界的广泛兴趣，且有了长足的进步。根据ON.Lab最新的一份简报透露，在ONOS打算解决的一些关键问题中，最明确的一个问题就是应用扩展。SDN控制器的可扩展性一直是众多网络所担心的一个问题，更是服务商尤其担心的问题。

为什么控制器的扩展会成为一个问题?因为在单个x86盒子上运行的控制器应用会受到诸如本地CPU、内存、总线架构和存储I/O等能力的限制。一旦单一系统出现性能瓶颈时，该应用不可能跳出盒子去运行。要想让只为单一盒子运行而设计的应用进行扩展，就需要一个规模更大的盒子。网络从业者都知道，这意味着需要一个颇具颠覆性的升级过程。将一个应用迁移到一个更大的盒子上是一种挑战，即便在虚拟计算环境中亦是如此。

分布式计算系统是通过将应用以跨多个系统的分布方式运行在一个逻辑架构中来解决扩展问题的。扩展应用就意味着要增加更多的系统，而不再只是升级单个的系统。

ONOS的目标是创建这样一个SDN控制器，它可以处理每秒高达100万条的路径设置，以及每秒多达600万次的网络状态操作。换句话说，ONOS控制器需要面对如何定义一个非常庞大的网络路径库及其变化的问题。单盒架构已经无法适应这样的需求，于是带有分布式控制器架构的ONOS就应运而生了。

这并不是说其他的SDN控制器架构不重视扩展的需求。有些SDN架构可通过创建多个SDN域，然后进行联邦治理来处理负载的分布问题。在这种架构中，每个域由一个单独的控制器集群来管理，控制器集群负责与其他的域交换数据，从而形成一个联邦。这不是分布式计算模式，而是一连串管理各个域的集中化控制器集群彼此间相互通信而已。

而ONOS控制器架构则遵循着一种真正的分布式计算模式，这个集中的控制器操作系统是跨多个控制器节点分布的。乍一看似乎跟上述系统差别不大，但这微妙的差别却非常重要。有了ONOS，一个单一的、分布式的ONOS实例便可维持一个网络状态的统一的全局视图。

ONOS与ODL的明显差异化还表现在其目标客户群为服务商。虽然它并不排斥企业用户，但其中的很多网络架构看上去都与服务商的网络架构相似，ONOS也和众多的服务商一样拥有全球化规模和超高节点连接。ONOS还从一开始就宣称它会让厂商的最终用户们参与进来，这对ODL来说是个不小的冲击，因为业界一直在诟病后者太过于厂商驱动了。

虽然企业的IT部门不太可能采纳ONOS，但至少在今天看来，这种分布式控制器架构还是令人印象深刻的。感觉ODL存在SDN扩展瓶颈的企业也许会想在其环境中测试一下ONOS，看看这种架构能否满足他们的需求。

ONOS在2015年3月发布的第二版叫黑鸟(Blackbird)。ONOS的第3版叫红衣主教(Cardinal)，2015年6月2日起可用。ONOS意图让自己的发布周期比ODL更快(大约每季度一次)，尽管其中没有太多可以像ODL的主版本那样的“新的”内容。

ONOS的一些现实用例也已经可以看到，例如前不久在Internet2一些区段网络中的部署。参与ONOS的重要厂商和机构包括AT&T、NTT、SK电信、Ciena、思科、爱立信、富士通、华为、英特尔、NEC、开放网络基金会(OpenFlow的维护机构)、Infoblox和其他一些企业等。

ONOS另一个让人感兴趣的地方就是它与OPNFV项目的关系，这一项目正在为服务商使用网络功能虚拟化(NFV)构建一个框架。ON.Lab在今年5月8日宣布已批准启动了一个项目，将打通OPNFV框架和ONOS。这样的合作非常及时，因为OPNFV也正处于初期阶段。双方的合作意味着ONOS有可能很好地映射到OPNFV的构建中去，如此而形成的平台将能够让服务商们既可以拥有扩展性，又可拥有功能性。

3、整合对用户意味着什么?

对于网络服务的消费者来说，SDN控制器的整合至少可以提供两个关键性的好处。

开发者们现在可以毫无顾虑地开始编写SDN应用了，因为他们对未来将使用什么样的控制器心中有底了。他们编写的应用既可以在ODL的开源发行版本上运行，也可以在网络厂商们基于ODL所推出的各种控制器上运行。这就等于说，编写ODL应用是一个值得进入的市场了。

当然，这也并不是说未来为一些专用的厂商控制器(例如思科的APIC或者惠普的VAN)编写应用是不值当的，只是说这些厂商专用的控制器只代表一个较小的市场，应用开发者们要想靠它们赚大钱是不太容易的。而对于网络服务的消费者来说，既然ODL尚在初期阶段就有了这么好的市场渗透率，那么随着时间的推移，他们就能看到越来越多的SDN应用在市场上出现。

今后，业界的努力将确定SDN如何发展以及如何运营。我们可能需要超越只对技术细节的关注，转而关注对运营影响的研究。SDN对厂商来说之所以一直未能形成一个市场，就在于现在的SDN并不是很多用户觉得他们想要的那种样子。换句话说，SDN本身可能并不是一个卖点。相反地，SDN只是提升运营效率，增加网络新功能的一个催化剂。

概括而言，SDN就是一组工具，你可以对它感兴趣，但普通的网络从业人员要想从中获益却并不容易。而控制器的整合就意味着业界对这样一种SDN架构的普遍认同，这种架构可允许来自众多厂商的复杂的和成熟的SDN产品形成一个市场。当这种情况出现时，我们就将会看到SDN被广泛采用。

但我们也不能高兴得太早。当厂商与最终用户共同创建SDN的长远未来时，关于SDN的各种争论仍将继续，所采取的立场或提出的建议仍然会有得有失。不过一些初期的成果已然浮现，在接下来的12个月内，SDN的发展将带来各种美好的承诺。

作者：何妍 

来源：51CTO