基于OpenFlow南向协议的SDN控制器性能测试方法及定量分析

张 攀 杨 虹

引言

随着软件定义网络(Software Defined Network,SDN)成为网络世界的新的范式转移，控制平面和转发平面的分离让后者得到了极大的简化，繁重的处理和计算工作都迁移至控制平面。作为控制平面的核心组件，控制器在全局网络性能中扮演决定性角色。鉴于SDN网络的实验或商业部署已经展开，网络用户将控制器的性能当作一个越来越重要的衡量标准。

作为目前业界关注的焦点，SDN控制器的性能关系到SDN技术是否可以兑现新技术带来的承诺。为满足网络用户需求，本文介绍SDN控制器性能的详细测试方法，以及以某一款开源控制器为例的定量测试结果，以便给出结果的标准呈现形式。所有测试例都针对OpenFlow 1.3[1]这一SDN南向协议。

本文介绍的测试方法可以在实验室中复现，可为所有关心SDN控制器性能的用户提供标准化的测试过程及测试例设计依据[2]。同时，在本文中提供了示例控制器在特定硬件平台上的定量测试结果，详细介绍了结果的分析过程和结论。可为评估控制器性能的用户，提供必要及有效的参考[3]。

2 环境设计

2.1 设计目标

本文介绍的测试方法旨在以定量的方式测量SDN控制器以下几个方面的性能。

1)控制通道容量。控制器连接交换机的最大数目，关系到整个SDN网络的可拓展性。

2)拓扑发现时间。该功能是SDN控制器需要实现的基本功能之一，本文介绍的测试方法可以测量其在不同规模、不同拓扑连接方式下完成网络拓扑发现所需的时间。

3)拓扑响应时间。SDN控制器针对拓扑变化事件，比如Port Down/Up等事件的侦测及响应时间，可以衡量SDN控制器对网络链路的控制能力。

4)被动流表下发速率。即控制器根据既定策略下发流表的速率。可以衡量控制器对上层网络策略的执行能力。

5)被动Packet_out消息下发速率。Packet_out消息是OpenFlow协议中主要的消息类型之一，在实际网络运营中关系到LLDP、ARP等协议的应用。其下发速率也是需要定量测量的指标之一。

在给出测试方法之外，仍会对实际的测量结果加以分析，介绍其结果的定量分析方法。同时，本文也将尝试对比分析控制器在单点运行模式以及集群运行模式下，同一性能指标的变化，其变化的特点以及所揭示出的控制器的特质，将为SDN网络用户提供参考。

2.2 被测控制器设计

为完成设计目标，一款开源控制器被选为示例被测控制器。它是目前流行的开源控制器之一，支持多种功能，例如设备管理、拓扑管理、链路管理、集群、图形用户界面以及多种SDN应用。它的OpenFlow 1.3南向协议消息处理性能是我们关注的内容。在本次搭建的测试环境里，我们设置了三台完全相同的虚拟机，每一虚拟机上都运行着一个完全相同的控制器节点实例。

2.3 硬件环境设计

为更好地比较控制器集群运行模式的实验结果，本次设计硬件环境为单台物理机运行多台虚拟机的模式，控制器运行于虚拟机中。详细配置如下。

物理机：

虚拟机：

2.4 控制器运行模式设计

为得到控制性能更完善的信息，定义了两种控制器运行模式。

1)单点运行模式。一个控制器节点实例运用于一个虚拟机之上。

2)集群运行模式。每一个虚拟机各运营一个控制器节点实例，三个分布式的，运营在不同虚拟机上的控制器实例组合成控制器集群，共同工作。

2.5 测试建议

1)隔离建议。所有的测试都建议执行于实验室环境和隔离的网络之中，以防外界的干扰对测试结果造成影响。

2)连接建议。被测控制器建议与测试工具直接连接，防止中间设备引入延迟或失效，导致测试结果不准确。

3)迭代建议。每一测试例都建议迭代执行10次以上，分别记录最大值、最小值和平均值。可以更全面地体现控制器的性能。

4)负载均衡验证建议。当控制器以集群模式运行时，建议分别记录各节点实例的CPU、内存使用率，以便检测在压力之下，控制器集群是否可以进行负载分担。

3 性能测试例及结果

3.1 控制通道容量测试

1)测试目的。测量控制器可以同时建立的OpenFlow 1.3通道的最大数目。

2)测试前提。

①被测控制器可以分别运行于单点模式和集群模式。

②被测控制器和模拟交换机都可以通过OpenFlow Echo request/reply消息维持控制通道的连接。

3)测试拓扑。如图1所示。

图1 控制通道容量测试示例拓扑

4)测试方法。

①以单点模式启动被测控制器。

②以不同拓扑连接的模拟交换机开始建立与被测控制器的OpenFlow 1.3连接。

③逐步增加交换机的数量，直到最大数目Nm，记录每一步的内存占用量。

④等待5分钟，确保已建立的控制通道稳定。

⑤在集群模式下迭代该测试过程。

5)测试结果。

①单点模式。本次测试采用三种拓扑连接方式：即Linear拓扑、Ring拓扑和Grid拓扑。如果建立的控制通道稳定并且每一个模拟控制器都收到了来自被测控制器的正确配置(安装默认流表)，那么此时记录的内存使用量即视为有效数据。默认情况下，控制器会下发两个针对ARP和LLDP数据包的流表给交换机，如果有交换机没收到这两条流表，我们即认为此时的交换机数目已超过最大数目，并将此时内存使用情况标记为N/A。详细的平均内存使用情况如图2所示。

②集群模式。在集群模式下，三个节点的内存使用量需要分别表示。该模式下，采用了两种拓扑：Linear拓扑和Ring拓扑。从测试结果可以看出，即便是存在一个leader节点，三个节点的内存使用量也大致相同，并且在每一个的总量上也稍稍高于单点模式。分析认为这是由于每一个节点都需要建立与全部交换机的控制通道，同时加入额外的集群同步机制；因此，可建立控制通道的数量并没有得到极大提升。详细结果如图3所示。

3.2 拓扑发现时间

1)测试目的。测量在不同网络拓扑和不同交换机数量下的控制器拓扑发现时间。

2)测试前提。

①被测控制器可以分别运行于单点模式和集群模式。被测控制器可以无差错地支持拓扑发现功能。

②默认的Table-miss流表的动作必须为上送控制器，或交换机有预先安装的针对拓扑发现消息的流表。

3)测试拓扑。如图4所示。

图2 单点模式测试结果

图3 控制通道容量集群模式测试结果

图4 拓扑发现时间测试示例拓扑

4)测试方法。

①以单点模式启动被测控制器。

②模拟交换机开始建立与被测控制器的连接。

③记录时间Tstart为控制器开启拓扑发现服务的时间。

④记录时间Tfout为控制器发出第一个包含LLDP数据包的Packet_out消息的时间。

⑤记录时间Tfin为控制器收到第一个Packet_in消息的时间。

⑥记录时间Tlin为最后一个由模拟交换机发出的Packet_in消息的时间。

⑦记录时间Tend为控制器完成拓扑发现的时间。

⑧取得拓扑发现时间为T=Tend - Tstart。

⑨同时计算Tfout - Tstart(Tinit)，为控制器初始化拓扑发现服务时间，Tfin - Tfout (Ttool)和Tlin -Tfin(Tnode)为使用不同测试工具和不同拓扑、节点数目的变动时间。Tend - Tlin(Tproc)为控制器处理LLDP消息并生成拓扑发现结果的处理时间。

⑩在不同拓扑连接方式，不同节点数目下迭代该测试。

在集群模式下迭代该测试。

5)测试结果。

①单点模式。本次测试采用了三种不同的拓扑类型，Linear拓扑、Ring拓扑和Grid拓扑。从测试结果来看，Tinit和Ttool两个时间间隔在不同情况下基本保持恒定，这两个时间分别为60±5ms和1ms，在下述的图标中并不容易被观察到。Tnode和Tproc与节点数量成正比，同时远大于Tinit和Ttool两个时间间隔。详细结果见图5所示。

图5 拓扑发现时间单点模式测试结果

②集群模式。在集群模式下，采用了相同的三种拓扑连接类型。Tinit和Ttool与在单点模式下的测试结果相同。当节点数量相对较小时，Tproc比单点模式要长，主要由于节点间同步进程的额外开销。当节点数量较大时(100～300)，Tproc的时间减小，由于集群增加的计算能力成为了主要的影响因素。根据测试过程中的抓包记录，只有leader节点通过Packet_out消息发送LLDP数据包，但是交换机将Packet_in消息分别发送给三个节点，因此，Tnode时间在集群模式下增长。所以全局的拓扑发现时间在不同的测试环境下，可能增加也可能增长。同时可以发现拓扑发现时间与交换机连接的拓扑类型有密切关系。详细测试结果如图6所示。

3.3 拓扑事件响应时间测试

1)测试目的。测量被测控制器对拓扑变化事件的响应时间。这些事件包括Port up/down和Switch up/down。在本测试例中不仅检测控制器对这些事件的侦测时间，同时也包括整套拓扑更新动作的完成时间。

图6 拓扑发现时间集群模式测试结果

2)测试前提。

①被测控制器可以分别运行于单点和集群模式。

②被测控制器可以无差错地支持拓扑发现功能。

③默认的Table-miss流表的动作必须为上送控制器，或交换机有预先安装的针对拓扑发现消息的流表。

3)测试拓扑。如图7所示。

图7 拓扑时间相应时间测试示例拓扑

4)测试方法。

①以单点模式启动被测控制器。

②以不同拓扑连接的模拟交换机开始建立与被测控制器的OpenFlow 1.3连接。

③等待直至拓扑发现完成。

④手动关闭交换机的某一端口。

⑥记录时间T1为控制器收到通知消息的时间。

⑦记录时间T2为控制器完成拓扑重新发现的时间。

⑧取得拓扑事件响应时间T = T2 - T1。

⑨在不同拓扑、不同交换机数量下迭代执行该测试。

⑩在集群模式下迭代执行该测试。

5)测试结果。

①单点模式。本次测试中采用了两种拓扑连接模式，Ring拓扑和Hub-spoke拓扑。从测试结果看来，Port up/down事件相对于Switch up/down事件，被测服务器响应的时间更短。对拓扑影响更大的Port down事件比Port up事件响应的时间更长。针对Port down事件的响应时间甚至超过了10秒，被测控制器在该方面还有很大的提升空间。图8中，Port down/up事件的时间单位是秒，Switch up/down事件的时间单位是毫秒。

图8 拓扑事件响应时间单点模式测试结果

②集群模式。在集群模式下，采用了三种拓扑连接模式。从测试结果来看，拓扑变化事件的响应时间展现出不可控的特性。集群节点之间的同步进程、拓扑类型以及集群内部的拓扑发现机制(发送LLDP数据包的时间间隔)，所有这些有影响的变量都让测试结果出现了随机性。没有人可以断言集群模式下的控制器响应时间更短，或拓扑中节点数量越小越容易响应。这也是网络用户在真实部署SDN网络时可能遇到的问题。详细测试结果如图9所示。

图9 拓扑事件响应时间集群模式测试结果

3.4 被动流表下发速率测试

1)测试目的。测量被测控制器被动流表下发最大速率。

2)测试前提。①被测控制器可以分别运行于单点模式和集群模式。②被测控制器可以无差错地支持拓扑发现功能。③默认的Table-miss流表的动作必须为上送控制器。④一个SDN应用需要在控制器之上运行，响应流表下发的需求，并能以最大可能的速率下发流表。

3)测试拓扑。如图10所示。

图10 被动流表下发速率测试示例拓扑

4)测试方法。

①以单点模式启动被测控制器。

②模拟交换机开始建立与被测控制器的OpenFlow 1.3连接。

③等待直至拓扑发现完成。

④被测控制器运行L2 Learning Switch应用。

⑤一定数量M的ARP_request消息通过Packet_in消息上送控制器。

⑥当控制器下发Packet_out消息结束之后，模拟交换机以一定速率通过Packet_in消息上送对应的ARP_Reply消息。

⑦记录时间Tf为模拟交换机收到的一个Flow_mod消息的时间。

⑧记录时间Tl为模拟交换机收到的最后一个Flow_mod消息的时间。

⑨确保所有的APR_reply消息都被控制器正确回应。

⑩求出被动流表下发速率R=M/(Tl-Tf)。

以不同的模拟交换机APR_reply上送速率迭代该测试。

在集群模式下迭代该测试。

5)测试结果。

①单点模式。在该测试中，一个模拟交换机连接被测控制器。测试工具被配置为以不同的速率上送Packet_in消息。在一些特定的配置下，被测控制器不能为每一条APR_Reply消息都下发两条双向连通的流表，但是实际流表下发数量还是被统计并作为有效数据。当上送速率在一定范围之内时，被测控制器流表下发速率与上送速率呈正相关关系。当上送速率超过某一阈值之后，流表下发速率显著下降，可认为此时被测控制器出现过载。APR消息的总数对流表下发的速率没有影响。详细测试结果请参照图11。

图11 被动流表下发速率单点模式测试结果

②集群模式。在集群模式，模拟交换机产生的每一个Packet_in消息都复制三份，分别发给集群中的三个节点，但只期望三个节点中的一个下发对应的两条双向连通的流表。在测试结果分析阶段，发现有两个或两个以上的节点同时下发了相同的流表。换言之，一部分ARP_request/reply消息，控制器集群一共下发了四条或六条，互相重复的流表。这很大程度上是由于集群节点之间的同步进程未能正确地完成同步工作引起的。根据OpenFlow 1.3.4协议，如果Flow_mod消息中设定了CHECK_OVERLAP标志位，这还会导致交换机返回错误消息。所以针对集群模式的测试结果不能作为有效的结果。

3.5 被动Packet_out消息下发速率测试

1)测试目的。测量被测控制器最大被动Packet_out消息下发速率。

2)测试前提。①被测控制器可以分别运行于单点模式和集群模式。②被测控制器可以无差错地支持拓扑发现功能。③默认的Table-miss流表的动作必须为上送控制器。④一个SDN应用需要在控制器之上运行，响应发送Packet_out的请求，并能以最大可能的速率下发Packet_out消息。

3)测试拓扑。如图12所示。

图12 被动Packet_out速率示例拓扑

4)测试方法。

①以单点模式启动被测控制器。

②模拟交换机开始建立与被测控制器的OpenFlow 1.3连接。

③等待直至拓扑发现完成。

④被测控制器运行L2 Learning Switch应用。

⑤模拟交换机以一定速率，通过Packet_in消息上送一定数量M的ARP_request消息。

⑥记录时间T1为模拟交换机收到第一个包含上送ARP_request的Packet_out消息的时间。

⑦记录时间T2为模拟交换机收到的最后一个Packet_out消息的时间。

⑧确保所有的APR_request消息都被控制器以Packet_out消息下发。

⑨求出被动Packet_out消息下发速率R=M/(T2-T1)。

⑩以不同的模拟交换机APR_request上送速率迭代该测试。

在集群模式下迭代该测试。

5)测试结果。

①单点模式。在该测试中，一个模拟交换机连接被测控制器。APR_request消息总数被设定为恒定值(1K)，但会以不同的上送速率进行迭代测试。与上一个流表下发速率测试例不同，Packet_out消息下发速率并没有随着APR_request消息上送速率的增加而增加。在该测试例的结果分析阶段，被测控制器在下发Packet_out消息时发现有大量的TCP重传，使下发速率在上送速率超过200个/秒时出现了显著下降。即便如此，实际的Packet_out下发速率也被认为是有效数据。详细测试结果请参照图13。

图13 单点模式测试结果

②集群模式。在集群模式下，情况与上一测试例类似。每一个上送的ARP_request消息封装于Packet_in消息之中，并复制三份，分别发给三个集群节点。每一个ARP_request消息都只期望有一个对应的Packet_out消息回应。但在该测试结果分析阶段，某些ARP_request消息被发现由多个控制器节点分别回应了相同的Packet_out消息。换言之，在集群模式下，Packet_out消息的总数比上送的APR_request消息多(大约为其1.5倍)，某些APR_request被重复泛洪多次。这一现象，同样是由控制器集群节点间同步机制不能正确完成工作所致。因该现象不但没有正确完成所需的工作，同时又浪费了现有的网络资源，所以其测试数据不能作为有效的测试结果。这也同样是网络用户可能在部署SDN网路时遇到的问题。

4 总结

本文介绍了一些SDN控制器的性能测试方法及对测试结果的定量分析[4]。意在着重介绍测试方法及结果的呈现形式。这些测试例，都是依据网络用户的实际场景和需求制定的。一个开源SDN[5]控制器被选择为示例被测控制器，以便提供定量的结果呈现方式和分析过程。总结测试结果，被测控制器在单点模式下可以稳定运行，尽管一些方面的性能仍需要加强，但其已经可以作为一个小规模的SDN网络的控制器。反观集群模式，控制器节点间的同步机制还未成熟。这或将导致过重的管理开支甚至是控制行为错误，从而最终引发网络失效。文中介绍的性能测试方法，任何需要获得控制器确切性能参数的个人或组织都可以在实验环境中复现。

本文介绍的性能测试例被认为是这项工作的一个起点。对每一个测试例来说，都可以添加更详细的配置，同时新的测试例也将会不断地被介绍进这项工作中来。当前，性能测试仅仅关注于南向接口，并且仅有一个特定版本的OpenFlow协议被提及。未来，北向接口的性能也将会纳入测试范畴。每一项测试例都可以用于SDN用户评估网络的实际部署情况，并成为其控制器选型的指标与依据。

参考文献

[1]Open Networking Foundation OpenFlow switch protocol 1.3.4[EB/OL].(2014-3-27)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/onf-specifications/open fl ow/open fl ow-switchv1.3.4.pdf

[2]Open Networking Foundation Conformance Test Specification For OpenFlow Switch Specification v1.3.4 Basic Single Table Conformance Test Profile[EB/OL].(2015-4-15)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/working-groups/OpenFlow1.3.4TestSpecification-Basic.pdf

[3]Team of Rivals: Aligning Technology & Market Drivers in an Open-Source Standards Testing Program[EB/OL].(2013-10-5)[2015-12-10].Rick Bauer Ron Milford Zhen Li https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/team-of-rivals.pdf

[4]The Evolution of SDN and OpenFlow:A Standards Perspective[EB/OL].(2014-1-26)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdn-resources/IEEE-papers/evolution-of-sdn-and-of.pdf

[5]When Open Source Meets Network Control Planes[EB/OL].(2012-12)[2015-12-10].https://www.opennetworking.org/images/stories/downloads/sdnresources/IEEE-papers/when-os-meets-nc-controlplanes.pdf