OpenFlow分布式部署设计方案的应用分析

夏仕俊

（国网上海市电力公司 信息通信公司，上海 200122）

1 设计方案背景

网络设计的简约化和简单化，促使了网络的飞速增长和不断创新，但网络本身仍然相当难以改变，并且极其脆弱和难以管理。这些问题的根源是在整个网络中的所有交换机和路由器上运行的控制层过于复杂［1］。为了缓解这个问题，2008年美国斯坦福大学提出了一种新型网络架构SDN（Software Defined Network），它的核心技术是OpenFlow技术，它将网络设备控制面与数据面分离，灵活实现对网络流量的控制，是SDN中一种最具革命性的数据平面抽象技术。

OpenFlow提出了解耦控制（决策制定）和数据（数据包转发）层，将控制功能委托给1个逻辑上集中的控制器［2］。这种分离，简化了对网络控制逻辑的修改，使数据层和控制层独立地发展和伸缩，并且显著地降低了数据层元素的开销［3］。因而，OpenFlow成功地吸引了大量厂商［4］。

为简单起见，OpenFlow最初的设计和实施只使用单个控制器。正如文献［5］所说，基于OpenFlow的单个控制器，给各个交换机安装包处理规则集，规则集实现客户端网络流的引导以达到服务的负载均衡。然而，随着部署Open-Flow的生产网络数量和规模的增大，整个网络依赖单一的控制器变得不可行了。首先，随着交换机数量的增长，与集中控制器之间的控制流量增加；其次，如果网络直径较大，无论在哪里放置控制器，都会有交换机遇到网络流建立时的长延迟；最后，由于系统受限于控制器的处理能力，随着网络规模的增加，网络流的需求增加，导致网络流建立的时间显著增加。

提出1种新的设计理念和实现方法，它为OpenFlow提供分布式的基于事件的控制层，使得网络运营商在管理网络里部署任意数量的控制器；在提高可扩展性的同时，保持网络控制逻辑集中，即所有控制器共享统一的网络级视图，响应请求本地化，而不需要主动联系任何远程节点，从而减少网络流建立的时间。此外，不需要对Open-Flow的标准做任何改动，只需要对现有的控制应用做少量修改［4］。新方案保证无循环转发，并免疫网络分割和组件故障。此外，它使得Open-Flow可以增加管理区域，以便于其能够与其他独立管理的OpenFlow区域互联。

2 目前分布式控制设计的问题

目前，分布式控制的一种典型设计是FlowVisor［6］。FlowVisor通过将网络资源切片并委派每个不同切片的控制，到1个不同的控制器，以使多个控制器在1个OpenFlow的网络中并存；另一种典型设计是分布式存储控制器的状态，并启用独立控制器的本地缓存。即使决策可以通过只询问本地缓存来实现，也难免有些流量需要从远程控制器进行状态检索，以致占用一些控制层的服务时间。此外，这种设计需要修改应用程序来将状态存储在分布式数据存储区。

将方案作为NOx（一种OpenFlow控制器平台）的1个应用来实现［7］。这个应用负责同步各控制器的网络级视图（通过传播特定的本地控制器事件），将指向间接控制交换机的OpenFlow命令重定向到该交换机相应的控制器，将回应从交换机重定向回发起请求的控制器，并使用发布／订阅消息模式来进行控制器间通信。

3 设计与实现

采用OpenFlow分布式部署方案的网络，由作为转发单元的OpenFlow交换机、NOx控制器和作为控制器间通信服务的事件传播系统组成。所有控制器都按照标准的网络级视图，运行相同的控制器软件和应用程序集，而每个交换机连接到其接近的最佳控制器。一旦控制器出现故障，受影响的交换机重新配置连接到1个附近的活动控制器。每个控制器直接管理连接到它的交换机，通过与其他控制器通信进行调整或查询，间接地管理其余交换机。采用OpenFlow分布式部署方案的系统结构框图如图1所示。

图1 系统结构框图

为了实现控制器之间网络级视图的一致性，在每个控制器中的控制器应用程序实例，通过1个发布／订阅系统发布会改变系统状态的事件，其他控制器重播所有已发布的事件来重建状态。采用这种设计理念是基于以下4个方面：一是控制器网络级视图的任何改变都源于1个网络事件，单个事件可能会影响多个应用程序的状态，因此随着应用数量增长的直接状态同步所带来的流量增长需要控制；二是只有非常小部分网络事件会更改网络级视图（数千台主机的网络上，每秒大概发生几十次事件），多数网络事件（如事件数据包）只请求服务（如路由服务）；三是除非针对同1个交换机，事件的时间顺序不影响网络级视图；四是应用程序只需最低限度地修改，以动态地识别影响它们状态的事件。

3.1 事件传播机制

为了传播控制器事件给其他控制器，方案使用发布／订阅消息模式。发布／订阅系统必须提供发布事件的持久性存储（提供有保证的事件交付），保持同1个控制器发布事件的顺序，并能免疫网络分割（比如，每个分割必须独立继续运行并在重新连接时实现同步）；应尽量减少传播事件所需的跨站点的流量，即1个站点的控制器应该从附近的控制器得到大多数其他站点的更新，以避免跨区域链接的拥塞；应加强访问控制，以确保访问拥有授权。

使用WheelFS可实现1个满足上述要求的分布式发布／订阅系统［8］。当然，也可使用任何满足上述要求的其他发布／订阅系统。WheelFS分布式文件系统旨在为分布式应用提供灵活的广域存储。它带来了应用程序的可控性、一致性、耐久性以及根据语义线索的要求放置数据的能力。语义线索可以直接嵌入在路径名中，以改变文件系统的行为。在WheelFS中，目录表示信道以及文件表示信息。为检测消息的到达，控制器应用程序会定期轮询目录，以检测改变。

每个控制器订阅网络中的数据信道、控制信道以及自身信道，并被授予权限，以发布和订阅信息。控制器将本地网络和应用事件发布到数据信道中。针对1个特定的控制器事件和OpenFlow命令在相应的控制器的信道内发布。此外，每个控制器必须在控制信道周期性地通告自己，以便实现控制器发现故障和检测故障。这些信道的访问控制是通过发布／订阅系统执行的。

2018年全国高考生物试题大多提供特定情境，学生通过运用科学思维，结合从题干中获取的信息和所学知识解决问题，进一步实现对学生生物核心素养的评价考查。

WheelFS的使用使得本部署方案能够免疫网络分割。一旦网络被分割，每个分割上WheelFS继续独立运作。每个分割上的控制器不再接收其他分割控制器的信息，认为它们都失联了。分割重新连接后，两个分割中的WheelFS节点被重新同步。控制器会得到分割断开时其他分割中所有发生的事件，经过重播后使得所有控制器的网络级视图重新一致。

3.2 控制器应用的主要功能

本方案基于NOx平台实现，作为一种NOx应用运行，用以确保所有的控制器都具有一致的网络级视图。每个控制器运行1个应用程序实例，实现时需要对核心控制器代码进行小的改动，主要是为客户提供合适的钩子来截获命令和序列化事件。主要功能和过程如下：

1）初始化 在NOx启动时，应用程序启动WheelFS客户端和存储服务，订阅该网络的数据信道和控制信道，并开始在控制信道周期性地通告本身。该通告间隔必须比网络控制器间最高的回合时间大。通告消息包含有关该控制器的信息包括直接控制交换机的标识符信息。

2）发布事件 应用捕获所有NOx内置事件以及程序在应用中注册的事件。然后，对本地产生并影响控制器状态的事件进行序列化和发布。为此，应用程序必须标记影响其状态的事件。此外，应用程序应该找出它们发起的非内置事件的父事件。这样一来，可以跟踪每1个高级别活动到底层较低级别的事件并传播它。使用这种方法，可以确保传播的事件的数量，仅限于局部控制器产生的OpenFlow的消息事件的数量。发布的消息的名称包含源控制器标识符和发布者的本地事件标识符，有效地将控制器之间的消息命名空间划分，避免了任何写冲突的可能性。此外，消息的缓存副本（文件）在系统中永远保持最新。

3）事件回放 应用重播所有发布的事件，这是因为源控制器在应用的帮助下有选择地进行过滤，只发布其他控制器重建应用程序状态所需的活动。当网络上的数据信道或控制器本身的信道收到新消息时，应用反序列这一消息并触发它。

4）重定向针对非本地交换机的命令 控制器只能对直接连接到它的交换机进行编程。为了编程非直接控制的交换机，当OpenFlow的消息即将被发送到这样的交换机时，应用程序将拦截并发布命令到网络的控制信道。已发布消息的名称包含源控制器的标识符、目标交换机标识符以及本地命令标识符。

5）代理OpenFlow消息和答复 获取针对其控制下交换机的命令消息，并将其发送到目标交换机。为了将答复返回源控制器，应用程序保持消息的事务标识符（XID）和源控制器标识符之间的映射。应用程序检查由控制器本地产生OpenFlow的消息事件的XID。如果1个事件的XID在XID控制器映射中被发现，则该事件停止进一步处理，并发布到网络上的数据信道。该消息的名称中包含两个控制器的标识符。初始的源控制器获取回执并重放事件。

4 控制器应用的要求

对于大多数控制器应用，只需动态标记影响其状态的事件。他们中的一些基于某种要求则必须进行修改，以确保在时序事件重排和控制器视图瞬时冲突时的正确操作，并保证可扩展性，以便独立管理的OpenFlow网络实现互连。

1）事件重排 除了那些针对同1个实体的控制应用外，应用的正确操作不能依赖于事件的时间顺序，因为不同的控制器以不同的顺序感知事件。此外，对网络分割免疫，意味着控制应用要在不牺牲正确性的前提下，容忍无序事件传递（甚至滞后几个小时）。这是因为每个分割在重新连接时才被告知其他分割的状态。

2）正确性 控制器之间的瞬态不一致可能导致有冲突的决策。因此，为了确保在所有状况下正确操作，控制应用程序必须将请求转发给权威的控制器。给定的权威控制器是该数据流源交换机的管理控制器。以交换／路由应用程序为例：为了确保无循环转发，流路径必须由管理数据流的源交换机的控制器建立。其他控制器如果收到1个流发起事件，必须将请求重定向到该流的权威控制器。

3）测量应用 主动查询交换机的应用表现，因为查询数量随着控制器的数量线性增长。这样的应用程序必须改为分布式的方式，对控制器集合进行划分，将查询分配到各个划分并在各划分间交换结果（封装在自定义事件里）。

4）网络互联 连接两个独立管理的基于本方案的OpenFlow网络（区），控制器应用程序需要进行修改，以进行区域感知，侦听来自方案的区域发现事件，实施用策略语言声明的区域策略，并与邻近区域通过提供发布／订阅服务的安全通道交流更新。应用程序应该把更新封装在自定义事件里，并传播到邻近地区。

5 分析评估

进行评估，要求测试时保证控制器之间不一致性，在有限范围内可以支持网络动态的最高水平。在实验中，使用10台服务器，每台服务器配备了千兆网卡，既是 WheelFS客户机，又是存储节点。每个NOx实例每秒处理大约30KB的流安装。通过应用发布的事件，只影响控制器的状态，不引发与控制器的任何交互。因此，使用本方案，网络运营商可以很容易地添加更多的控制器来处理流事件，同时保持流配置等待时间最小。

各个控制器的操作由于不依赖于其它的控制器，即使在重同步负载的状况下仍能继续操作。在给定的1个控制器之间有界不一致窗口下，为找到本方案可以处理的事件数量，以独立的WheelFS为基准，找出3KB大小可以读写文件的数量（样本是XML格式的序列化数据路径联通事件）。为此，使用实现的应用程序代码来衡量需要读取和反序列化1000个这样文件的时间（拥有最终一致性），以及序列化和写（写在本地，不等待与副本同步）同样文件的时间。每个测试做了10次，取平均值的结果。本方案每秒可以读取和反序列化987个，或者序列化并写入233个这样的事件。在这种状况下，限制因素是读取数，因为多个控制器可以同时进行发布（写）。

基于以上分析，假设有足够的控制带宽，在网络变化触发事件数量低于大约1000个／s时，本方案可以保证控制器间的不一致性是在可控范围内。可以通过修改WheelFS或设计替代的发布／订阅系统，以提高实验方案的性能。

6 结语

介绍了1种基于OpenFlow的分布式控制应用设计方案和实现，使OpenFlow可以部署在数据中心和企业网络一类的任务关键型网络中。使网络运营商可以根据自己的需求部署任何数量的控制器来调整控制层的性能。此外，它使网络控制逻辑集中化，每个控制器的决策本地化，以减少控制层的响应时间。在NOx基础上实现的本方案应用，通过传播影响控制器状态的事件来同步控制器的网络级视图。

选择通过重播事件建立状态，尽量减少同步控制器状态所需的控制流量，避免了在应用程序的状态中发生冲突的可能性，并最大限度地减少了应用程序进行修改的负担。本方案对网络分割和组件故障免疫，最大限度地减少了跨区域控制流量，并允许独立管理的OpenFlow网络互连。

［1］ Greenberg A，Hjalmtysson G，Maltz D A，et al.Clean slate 4Dapproach to network control and management.SIGCOMM Computer Communication Review 35，5（2005），54.

［2］ McKeown N，Anderson T，Balakrishnan H，et al.Open-Flow：enabling innovation in campus networks.SIGCOMM Computer Communication Review 38，2 （2008），69-74.

［3］ Naous J，Erickson D，Covington G A，et al.Implementing an OpenFlow switch on the NetFPGA platform.In ANCS（2008），M.A.Franklin，D.K.Panda，and？D.Stiliadis，Eds.，ACM，1-9.

［4］ OpenFlow Consortium.http：／／openflowswitch.org／.

［5］ Wang R，Butnariu D，Rexford J.OpenFlow-based server load balancing gone wild.Proceedings of the 11th USENIX conference on Hot topics in management of internet，cloud，and enterprise networks and services［J］.USENIX Association，2011：12-12.

［6］ Sherwood R，Gibb G，et al.FlowVisor：A Network Virtu-alization Layer.Tech.Rep.OPENFLOW-TR-2009-01，OpenFlow Consortium，October 2009.

［7］ Gude N，Koponen T，Pettit J，et al.NOx：towards an operating system for networks［J］.SIGCOMM Computer Communication Review2008，38（3）：105-110.

［8］ Stribling J，Sovran Y，Zhang I，et al.Flexible，wide-area storage for distributed systems with WheelFS.In Proceed-ings of the 6th USENIX Symposium on Networked Systems Design and Implementation（NSDI’09）（Boston，MA，A-pril 2009）.