软件定义网络多控制器平台研究

魏明军++张文娜

摘要：文章针对软件定义网络单一控制器的处理能力不能满足需求的扩展性问题及当前分布式多控制器平台无法根据实际情况改变服务的问题，在控制层面上提出设计服务抽象层，对抽象服务层在控制器应用中对底层的操作或者应用之间交互设计的可行性进行实验验证及测试。

关键词：软件定义网络；多控制器；服务抽象层

传统的网络体系结构是分布式的，每个网络设备都拥有相对独立的操作系统和控制层面。设备与设备之间通过分布式的网络协议交换信息和数据，导致网络的管理和配置工作越来越繁冗和复杂。通过现有网络，管理人员实现创新和升级部署新的网络结构变得越来越困难。因此需要一种新的体系结构，这种结构能分类控制数据动态，实现转发与控制。

软件定义网络（Software-Defined Networking）作为一个新兴的网络体系结构受到广泛的关注。文章针对软件定义网络、可扩展性问题、性能评价问题及其相关部分测试方法问题，对单一控制器处理能力不足以及当前分布式解决方案无法根据实际情况改变服务架构的问题，提出了控制平台架构模型。并对已有的架构进行分析和总结，在该模型的基础上设计服务抽象架构控制器，并对该控制器进行了功能和性能测试。

1 传统网络与软件定义网络对比

1.1 软件定义网络的特点

软件定义网络（SoftwareDefined Networking）通过控制与转发的分离、开放的南北向接口、集中式的控制平面获取网络的全局信息，并根据业务需求对网络资源进行动态的全局调配和优化。这一举措大大提高了网络控制的灵活性，使可管理、可编程、可动态改变的网络成为可能，从而实现网络流量的灵活控制，为核心网络及应用的创新提供了良好的平台。

1.2 传统网络与软件定义网络对比

传统的互联网体系结构是分布式的，每个网络设备都拥有相对独立的操作系统和控制层面，设备与设备之间通过分布式的网络协议交换信息和数据，其结构有几点不足：①网络设备复杂。②配置困难。

1.3 网络特征和底层操作系统绑定，很难添加新特性。

软件定义网络平台以OpenFlow为主，OpenFlow从转发设备中分离控制逻辑的方法使数据平面具备了灵活的设备添加和升级的能力。

2 多控制器实验平台简介

2.1 多控制器架构分析

多控制器SDN网络的典型做法是将网络划分成多个控制区域，每个区域由1个控制器控制。现有的多控制器架构从网络的划分方式来看，可以分为水平式多控制器架构和层次化多控制器架构2类。

2.2 控制器放置问题分析

分布式地部署多个控制器是解决SDN网络的性能、可扩展性以及可靠性问题的重要手段之一。然而，多个控制器的存在也面临着其他新挑战，其中最关键的问题就是如何选择控制器的数量以及控制器的放置位置。当前的研究工作主要从几个方面来考虑控制器的放置方案：基于传输延时的控制器放置方式，基于可靠性的控制器放置方式，基于其他指标的控制器放置方式。

2.3 软件定义网络控制平台的可靠性分析

SDN采用逻辑上集中式的方式对网络进行管理与控制，为了解决集中控制环境中的故障问题，在网络部署多个控制器是解决SDN控制平面可靠性问题的重要手段。SDN控制平面中的故障可以分为控制器故障以及传输控制流的节点或者链路的故障。为了克服控制器的故障，主要通过控制器的被动或主动复制技术来提高SDN控制平面的可靠性。而在克服传输控制流的节点或链路的故障方面，则主要通过路径保护或者路径恢复的方式来提高SDN控制平面的可靠性。多控制器平台涉及架构设计、控制器放置等方面问题。针对这些问题，文章结合现有研究分类，通过分析、总结，可深入了解多控制器平台存在的问题，并提出解决方案，为之后抽象服务层的设计奠定理论基础。

3 实验方案

为了解决集中式控制平台的处理能力有限、全局视图信息的收集代价过大等问题，文章采用多控制器满足需求。控制器应该对应用透明，即不论服务如何变化，应用的编写方式是一致的。也就是说，当底层服务发生变化时，原有的应用无需任何修改。要做到这一点，则要求底层协议更改更为慎重，对应用也必须相对透明。

3.1 服务抽象层

设计采用服务抽象层做到这一点，可以采用如下的设计思路：服务抽象层可以动态链接控制器应用与南向协议提供基本的网络服务，如使用类似拓扑管理模块，实现拓扑构建和设备发现的功能。抽象层提供的服务由控制器基于应用或者网络设备提供的功能为基础构建，基于应用对服务的请求服务抽象层映射到对应的控制器插件，选取恰当的南向协议与给定的网络设备实现通信。

服务抽象层在服务和插件间流程设计方案举例：①当一个支持OpenFlow协议的插件接收到一个ARP请求数据包，需要分派此数据包到ARP处理程序。②协议插件将调用数据包输出服务接口，将数据包传输到服务抽象层。③ARP处理程序，将登记注册到监听数据包服务接口，在上一步中服务抽象层接收到的数据包将被移交到ARP处理程序对应的应用中。④该应用程序现在可以处理此数据包。通过以上分析结合软件定义网络现状，对软件定义网络多控制器平台进行理论分析并进行设计验证。

3.2 多控制平台下网络拓扑实验验证。

控制器为应用提供了逻辑集中的物理网络拓扑视图，为了网络应用直接管理网络规则策略，控制器支持网络设备转发规则的变化。和大部分控制器一样，控制器使用LLDP报文发现的设备连接来构建网络拓扑结构。拓扑视图选项提供了交换机和主机拓扑的图形视图。在抽象服务控制的多控制器拓扑中各个管理对应控制器存储和设备，包括设备的功能和可达性信息等。这些信息由控制器存储并且由拓扑管理器管理。其他构件组成包括ARP处理程序、主机探索器、设备管理器、交换机管理器等协助拓扑管理器生成网络拓扑数据库。

3.3 多控制平台下服务抽象实验验证。

①实验环境配置。在已经安装Mininet环境的机器中启动Mininet，对应地配置多个主机和交换机。在控制器层启动一个简单的转发包应用，它通过ARP包来探测连接到网络的每个主机，并给交换机安装规则，让网包能顺利转到各个主机。通过拖动设备，形成逻辑拓扑，并保存配置。②实验分析。因为控制器是寄存在服务器中，所以当做好类似以上的配置之后，首先要连接控制器，通过控制器应答的状态信息来了解网络运行情况，其中应答201表明操作成功。为了叙述直观简洁，文章在试验中配置了3台交换机，每台交换机上使用的南向协议不同。③获取删除主机信息（见图卜图3）。

利用仿真实验进行验证可以得出结论：通过获取拓扑信息，配置与获取用户链接信息，获取、删除主机信息等实验操作，验证抽象服务层在控制器应用中对底层的操作或者应用之间交互设计的可行性。真正实现了多控制器多协议支持和对应用的透明，不论服务如何变化，应用的编写方式一致。

4 结语

文章利用实验平台，对软件定义网络以及多控制器平台相关问题进行仿真论证，实现服务抽象架构的多控制器平台，服务抽象层可以动态链接控制器应用与南向协议提供基本的网络服务，如使用类似拓扑管理模块，完成构建拓扑和发现设备功能。服务抽象层与控制器插件是相互独立的并且是相耦合的，这样就可以实现灵活升级网络协议或应用。endprint