软件定义网络(SDN)是一种新型的网络架构，它使用一个集中控制器来控制数据层面的数据流。这种新方案使网络管理更容易，并能够节约成本。云计算技术的进步促进了云管理工具的发展，OpenStack就是云管理工具的代表。它使用网络组件Neutron(原来是Quantum)提供网络虚拟化服务，允许租户创建和管理虚拟网络，并且提供标准化的插件架构，便于连接SDN控制器。但是Neutron的扩展性不好，不能满足虚拟化环境的动态特性，并且对网络资源的控制是有限的。SDN可以为Neutron提供附加功能，如集中控制、无缝网络、多租户和网络可伸缩性。
在本文中，我们将测试SDN控制器和OpenStack集成的功能和可用性;调查分析业界对SDN与OpenStack集成的看法;利用商业调查结果和测试用例来突出SDN使用的障碍、预算分配、OpenStack分布和SDN控制器等主题。这将帮助我们评估SDN和OpenStack是否能够作为一个IaaS解决方案。
1 研究的问题
SDN和OpenStack可以一起推动IaaS的发展吗?
我们将研究的问题划分成3个子问题。
1)SDN和OpenStack集成的***方案是什么?
2)行业和社区对SDN和OpenStack的观点是什么?
3)SDN和OpenStack集成后的性能和功能可以满足行业需求吗?
2 集成SDN与OpenStack
2.1 OpenStack
2010年7月，Rackspace和NASA启动开源的云管理软件OpenStack。这是创新软件项目的集合，为快速供应、创造和管理公有云和私有云中的虚拟设备提供了一个架构，本质上是作为基础设施即服务(IaaS)。所有服务协同使用API来提供灵活和可扩展的云解决方案。它也有许多项目在孵化阶段，并在社区分阶段开发并发布。图1显示了OpenStack9个主要的模块。
图1 OpenStack架构
- Nova(Compute)：为云用户提供虚拟服务器。
- Neutron(Networking)：为OpenStack的Compute节点管理的接口设备提供网络服务(虚拟网络服务)。
- Object Storage(Swift)：存储和检索数据(图片、文件、文档)。
- Block Storage(Cinder)：为用户虚拟机提供持久的块存储服务。
- Image(Glance)：为Compute节点提供一个虚拟镜像。
- Dashboard(Horizon)：提供了基于web的图形用户界面(GUI)，让云管理员和租户(用户)来管理OpenStack。
- Identity(Keystone)：它存储的信息为OpenStack提供身份验证和授权服务。
- Celiometer：通过监视和测量OpenStack云的使用来计费、设置标准和统计。
- Heat：通过调用适当的API来管理云应用。
2.2 Neutron的功能
Neutron添加了一层虚拟的网络服务让租户(用户)构建自己的虚拟网络。Neutron是对网络的虚拟化，该网络可以从一个地方移动到另一个地方，而不会影响现有的连接。它可以进一步解释为一个网络管理服务，为创建和管理虚拟网络公开了一组可扩展的API(通过创建虚拟网络为OpenStack Compute节点上的虚拟机提供网络服务)。Neutron的插件架构为开源社区或第三方服务提供API。Neutron还允许供应商研究和添加新的插件，提供先进的网络功能。
目前，Neutron的虚拟网络服务没有传统网络成熟。下图描述了与Neutron组件交互的代理。组成Neutron的元素如下：
Neutron-server是python虚拟光驱, 是OpenStack网络运行在Network节点的主过程。
Plugin agents和Neutron插件一起管理虚拟交换机，Plugin agents依赖Neutron插件。
DHCP agent是Neutron的一部分，为租户的网络提供DHCP服务。
L3 agent负责层3和NAT转发来获得租户虚拟机的外部访问。
SDN services：这些服务为租户网络提供附加的功能，通过API与plugin agents或neutron-server进行交互。
图2 Neutron和SDN集成代理
在大规模、高密度、多租户云环境中，Neutron的性能会下降。Neutron的低扩展能力还不能紧跟云环境的动态特性，但它提供了插件将SDN 控制器集成到OpenStack，达到将应用程序从IP地址、VLAN和端口等网络环境中分离的目的，并且能够节省时间和降低运营成本。
2.3 SDN及其与OpenStack的集成
引入SDN主要是克服Neutron的缺陷，SDN是一种网络技术,通过集中的可编程控制平面来管理整个数据平面。这样网络运营商和供应商可以控制和管理自己的虚拟化资源和网络。SDN是一种新型的网络模式，允许硬件和操作系统之间以及物理/虚拟网元和操作系统之间通过开放API通信。
SDN模型中的网络操作系统(NOS)，例如OpenDaylight、RYU、Floodlight和POX，负责提供网络和其当前状态的一个完整视图。同时NOS也负责管理网络变化，并将这些变化通知到网络硬件和物理/虚拟网络应用程序中。底层网络的变化来自于运行在NOS上的网络应用程序 (Neutron API, REST/JSON, Java RPC)，NOS通过北向API与应用程序通信，通过南向API管理和控制底层物理和虚拟硬件，使用的南向协议包括OpenFlow、OVSDB 、 OF-config和XMPP等。
SDN控制器以插件方式集成到Neutron中并提供集中式管理,有利于OpenStack网络通过API提高网络的可编程性。SDN控制器，像 OpenDaylight、Ryu和Floodlight等使用各自的插件让Neutron和SDN控制器交互。下图给出了SDN集成到 OpenStack的大体思路。
图3 SDN集成到OpenStack
OpenDaylight使用北向Rest API通过网络节点的二层插件与Neutron通信。RYU通过北向REST API将Neutron节点的RYU插件和RYU控制器连接，使用Compute节点的RYU代理和RYU插件交互。OpenDaylight和RYU都使用Open vSwitch数据库(OVSDB)和南向OpenFlow协议与计算(nova)节点的虚拟交换机交互。
#p#
3 研究方法
通过回答三个子问题来回答主要研究的问题，如下分两步解决子问题。
首先分别评估独立部署OpenStack和其集成SDN控制器的性能和功能，这将解答子问题1和3。其次，组织开展一次商业调查，参与者是OpenStack和SDN社区的成员，这将帮助了解行业内对这两种技术的观点。
以下是测试床的主要组件
1)OpenStack分布
2)SDN控制器
3)硬件(服务器，交换机)
为本次研究选择一种OpenStack分布，测试参数主要包括如下：易于安装、可扩展性、开放性、社区支持、文档、成本因素。选择好合适的 OpenStack分布后，我们部署了一个多节点的OpenStack，其中一台服务器上部署计算节点，另一台服务器部署控制器、Neutron、 nova组件和glance。我们根据节点的功能分配资源(RAM、Storage，CPU)。
选择与OpenStack集成的SDN控制器需要研究的参数如下：开源、实现的语言、GUI、支持平台、OpenFlow版本、OpenStack Neutron组件、行业支持。
基于以上的结论，我们选择如表1所示规格开发测试床。
表1 测试环境的参数
我们基于VMware ESXi在控制器和Compute节点部署Havana版本的OpenStack。
图4 SDN和OpenStack集成(测试床)
为了回答第二个子问题，我们通过商业调查来了解SDN和OpenStack在行业内的状态。 通过使用“SoGo Survey”调查工具在社会媒体网站(Facebook和LinkedIn)粘贴调查链接，并访问业内专家。我们还采访了研究SDN和 OpenStack 的专家了解目前情况和未来的趋势，用数据分析工具得出调查结果。
回答第三个子问题，验证SDN控制器和OpenStack集成的性能和功能是否满足行业内的需求。我们用一系列的测试用例验证和评估SDN控制器和OpenStack的集成。测试用例如下：
表2 数据平面测试用例
表3 功能测试用例
#p#
4 研究结果
图5的调查结果显示，73.68%的受访者相信OpenStack和SDN会一起推动未来的基础设施及服务(IaaS)。
图5 SDN与OpenStack集成的未来(商业调查)
为了确定***个子问题的答案，我们比较了基于预定义参数的不同的OpenStack分布，表4显示了不同OpenStack分布的评估结果。
表4 不同OpenStack的比较
图6的调查结果显示，OpenStack开源安装和DevStack是***的版本。
图6 被调查者对OpenStack分布的选择(商业调查)
根据表2和图6的调查结果，我们选择DevStack作为本次调研的OpenStack分布。
为了选择SDN控制器，我们调研当前流行的几种开源SDN控制器，并且根据预定义参数比较其性能。表5显示了比较结果，之后我们会继续采用商业调查方式来肯定该调研结果。
表5 SDN控制器比较
商业调查的受访者***OpenDaylight、其次是Floodlight来提高Neutron的功能。综合图7和表5，我们选择OpenDaylight和RYU控制器集成到DevStack环境。
图7 受访者对SDN控制器的选择
为了确定第二子问题的答案，我们分析了商业调查结果。结果表明，45%的受访者认为SDN和Neutron满足他们组织的IaaS需要(图8)。
图8 受访者对SDN和Neutron前景的观点
当被问及OpenStack集成SDN后，SDN的哪些特性可以提高时(如图9)，大约50%的参与者支持多租户、网络可扩展性、网络可视性和无缝网络等功能。
图9 OpenStack集成SDN后可以提高的性能
当被问及目前采用SDN遇到的障碍，52%的参与者认为“当前产品不成熟”是一个主要的障碍。39%参与者认为“缺乏适当的资源评估SDN”(图10)。
图10 采用SDN的障碍(商业调查)
当被问及是否愿意将SDN(图11)添加到到他们的实际网络，42%的参与者是“非常愿意”或“完全愿意”，同时其他42%比较愿意对他们的产品做出显著的改变来支持SDN。
图11 SDN在生产网络中的接受度
当被问及对SDN的预算分配，60%的受访者愿意将他们主要的经费用于SDN部署(图12)。
图12 部署SDN的预算分配(商业调查)
为了评估集成SDN和OpenStack的性能和功能，我们使用***个研究子问题的结果(OpenDaylight和RYU控制器与DevStack结合)进行数据平面和功能测试。测试用例的结果如表6和7所示：
表6 数据平面测试
表7 功能测试
从上面的测试用例结果可以帮助我们确定当前OpenDaylight和RYU控制器集成到OpenStack的程度。
#p#
5 结果讨论
根据研究结果，我们选择DevStack作为OpenStack的搭建方式。DevStack由于提供了高度可扩展的和灵活的测试环境，所以可以根据我们的要求迅速重建。而较多人选择的OpenStack开源分布安装是一个复杂的安装过程，很难扩展。其他的选择如Mirantis和RDO不满足研究需求。接下来我们对四个流行的开源SDN控制器进行比较，我们***OpenDaylight和RYU而不是POX和 Floodlight。因为POX不支持与OpenStack的集成，并且Floodlight和DevStack(OpenStack)集成会出现各种问题阻碍我们进行进一步的测试。
我们根据商业调查结果分析该行业对SDN和OpenStack的看法。我们的被调查者相信SDN和Neutron一起可以满足他们的IaaS需求。参与者觉得SDN给OpenStack带来了一些特性，如网络可视性、无缝的网络和网络可扩展性，这些从我们的测试结果得以验证。但受访者担心SDN控制器是不成熟的，评估起来也相当困难。SDN控制器集成OpenStack还不成熟，我们在测试阶段验证了这个结果。调查的结果还显示在未来几年，受访者有意愿改变他们的生产网络并分配大部分的预算支持SDN。从我们的商业调查结果显示参与者对SDN集成OpenStack有很高的接受度。
分析数据平面测试结果时，我们观察到在吞吐量、流量延迟和单向的TCP传输等参数上，OpenDaylight落后RYU，但 OpenDaylight在功能和可用性上比RYU更好。这两个控制器通过了第三层的功能测试，VM迁移测试和容错测试。然而，随着虚拟机数量的增加，控制器无法执行，我们在测试部署遇到意想不到的失败，证明这是一个不稳定的解决方案。从我们的测试、研究发现，SDN控制器目前每秒可以处理大约1000条流。另一方面，一个数据中心每秒处理大约100000条流。这清楚地表明当前SDN控制器的功能和数据中心的需求差距很大。此外，在集成SDN和 OpenStack的过程中若出现了问题，我们可以参考的文档资源很有限。
尽管SDN和OpenStack集成是一个进化的IaaS解决方案，但目前在高利用率的环境下不可靠，所以不能用于生产环境。不过即使当前 OpenStack和SDN有很多约束，但我们坚信，这两种技术将推动IaaS的未来发展，因为它们的功能正迅速发展，行业的接受度也很高。根据我们的调查结果推断产业愿意投资他们主要的IT预算来部署这些技术。所有这些特性将有助于推动控制器和OpenStack性能开发的快速发展,有助于推动IaaS 的未来。
6 结论
基于已有的技术和商业调查结果，我们知道SDN集成OpenStack仍没有完全成功，还有很多需要改进。这主要是因为集成解决方案还欠完备，特性集不完整，编排不可靠和相关文档匮乏。行业内认为SDN在性能和功能上仍滞后于传统的网络基础设施，同时OpenStack目前还没有能力与市面上的商业产品竞争，像亚马逊网络服务(AWS)、微软Azure、VMWare云等。然而SDN和OpenStack有大量的开发者基础和行业支持，我们相信在大约两年的开发和测试后，OpenStack和SDN集成将达到生产准备的要求并被广泛采用。我们相信，匹配行业需求的性能和功能将成为OpenStack 和SDN一起推动IaaS未来的关键因素。SDN和OpenStack中网络功能的虚拟化的引入将扩大IaaS的接受度。
