SDN控制器测试专题五:Floodlight性能测试报告(上)

       上一篇重点介绍了《SDN控制器测试专题四:Floodlight南向接口测试报告()》,给出了控制器的功能测试结果。本篇将根据确定的性能测试项,对floodlight控制器性进行逐项测试验证,并会给出测试结果。

测试目的

验证floodlight v1.0控制器的以下几个性能情况:

 ■验证控制器支交换机上线的最大规模;

 ■验证控制器支持的交换机上线的最佳数量;

 ■验证控制器流表下发的速度;

 ■验证控制器流表下发时延;

 ■验证控制支持的最大流表数量;

 ■验证控制器mac地址的学习速度;

 ■验证控制器在大规模交换机上线情况下的网络拓扑更新速度;

性能测试的必要性

        控制器负责整个SDN网络的集中化控制,肩负着掌控全网视图,改善全网资源的重要作用。但由于控制能力的集中化,也就意味着控制器很容易成为未来全网的性能瓶颈。为了防患于未然,进行控制器性能测试,全面了解控制器产品的性能状况,提供可靠的性能指标,显得尤为重要。

性能瓶颈分析

       SDN控制器通过南向网络控制器技术对整个网络中的设备进行了集中化的管控与调度。包括链路发现,拓扑管理,策略制定和表项下发。

3.1 SDN控制器的工作流程

SDN控制器的工作流程如下:


1)控制器与交换机建立ofchannel通道,控制器通过ofchannel控制和管理交换机。

 2)当交换机收到一个数据包且流表中没有匹配条目,交换机会将数据包封装在packet_in消息发送给控制器,此时数据包会缓存在交换机中等待处理。

 3)控制器收到packet_in消息后,可以发送flow_mod消息向交换机写一个流表项,并且将flow_mod消息中buffer_id字段设置为packet_in消息中的buffer_id值。从而控制器向交换机写入了一条与数据包相关的流表项,并且指定该数据包按照该流表项的action列表处理。但是并不是所有的数据包都需要向交换机中添加一条流表项来匹配处理,网络中还存在多种数据包,它出现的数量很少(如ARP,IGMP等),以至于没有必要通过流表项来指定这一类数据包的处理法,此时控制器可以使用packet_out消息,告诉交换机某一个数据包如何处理。

3.2 性能瓶颈分析

    通过分析sdn网络的工作流程,可知控制器通过响应packet_in消息发送packet_out/flow_mod消息的速度是非常重要的,它的快慢直接影响了控制器拓扑发现,流表下发,mac地址学习能力,甚至整个网络的性能。而且SDN网络中通常采用反应式流安装,控制器的响应时间直接影响着流安装的处理速度,本文将重点测试在负载不同的情况下控制器处理packet_in消息的吞吐量和响应时间。同时也关注控制器支持创建openflow连接的能力与拓扑更新的速度。

测试环境硬件配置

测试执行

5.1 验证控制器支交换机上线的最大规模

5.1.1 测试目的

验证控制器所能接入交换机的最大数量。

5.1.2 测试拓扑





本测试项目未完,后续测试结果可点此查看原文



猜你喜欢

转载自blog.csdn.net/SDNLAB/article/details/44059631