开放网络操作系统ONOS性能评估.docx
《开放网络操作系统ONOS性能评估.docx》由会员分享，可在线阅读，更多相关《开放网络操作系统ONOS性能评估.docx（21页珍藏版）》请在冰豆网上搜索。
开放网络操作系统ONOS性能评估
开放网络操作系统ONOS性能评估
标签：
开放,网络,操作系统,性能
目录
目标3
通用实验设置4
测试工具4
测试环境配置5
ONOS软件环境5
实验A＆B-拓扑（Switch,Link）发现时延测试5
目标5
配置和方法—交换机连接/断开的延迟6
设置和方法—链路up/down的延迟7
结果8
分析和总结10
实验C：
intentinstall/remove/re-route延迟测试11
目的11
配置和方法—batchintent安装与退出12
配置和方法--intentRe-route13
结果14
分析和总结16
实验D：
IntentsOperation吞吐量16
目标16
设置和方法16
结果18
分析和结论18
实验E：
Flow子系统迸发吞吐量测试19
目的19
配置及方法19
具体实验参数设置20
分析与结论21
目标
ONOS是一个网络控制器。
applications通过intentAPIs与ONOS进行交互。
ONOS通过其南向适配层控制数据网络的转发（例如，openflow网络）。
ONOS控制层与数据转发层之间是ONOS流子系统，ONOS流子系统是将applicationintens转换为openflow流规则的重要组成部分。
ONOS也是一个分布式系统，至关重要的是ONOS分布式架构使其性能随着集群数量增加而提高。
这份评估报告将ONOS看作一个整体的集群系统，计划从应用和操作环境两个角度去评估ONOS性能。
我们设计了一系列的实验，测试在各种应用和网络环境下ONOS的延迟和吞吐量。
并通过分析结果，我们希望提供给网络运营商和应用开发商第一手资料去了解ONOS的性能。
此外，实验的结果将有助于开发人员发现性能瓶颈并优化。
下图把ONOS分布式系统作为一个整体，介绍了关键的测试点。
图中包括如下性能测试点:
延迟：
▪A-交换机连接/断开;
▪B-link启用/断开;
▪C-intent的批量安装/删除/路径切换;
吞吐量：
▪D-intent操作;
▪E-link事件（测试暂缓）;
▪F–迸发流规则安装。
通用实验设置
集群规模性能测试：
ONOS最突出的特点是其分布式架构。
因此，ONOS性能测试的一个关键方面是比较和分析不同集群大小下ONOS的性能。
所有的测试用例将以ONOS集群节点数量为1,3,5,7展开。
测试工具
为了展示ONOS的本质特征，使测试不受测试仪器的瓶颈限制，我们采用了一些比较实用的工具进行实验。
所有实验，除了与Openflow协议交互的交换机和端口及其它相关的，我们在ONOS的适配层部署了一套NullProviders与ONOScore进行交互。
NullProviders担任着生成device,link,host以及大量的流规则的角色。
通过使用NullProviders,我们可以避免并消除Openflow适配和使用真实设备或者模拟的Openflow设备所存在的潜在的性能瓶颈。
同时，我们也部署了一些负载生成器，这样可以使应用或者网络接口生成高强度的负载去触及ONOS的性能极限。
这些生成器包括：
1.Intentperformance生成器“onos-app-intent-perf”，它与intentAPI交互,生成intent安装/删除操作，并根据ONOS可承受的最高速度自我调节生成的Intent操作的负载。
2.流规则安装Python脚本工具与ONOSflowsubsystem交互去安装和删除subsystem中的流规则。
3.NullLinkProvider中的link事件（闪烁）生成器，可以迅速提升发送速度到ONOS所能承受的极限并依此速率发送linkup/down信息给ONOScore。
4.此外，我们在"topology-events-metrics"和"intents-events-metrics"应用中利用计数器去获取关键事件的时间戳与处理速率来方便那些时间及速度相关的测试。
我们将在后续的每个不同的测试过程中详细介绍这些生成器的配置。
测试环境配置
A7台集群实验所需要的裸服务器。
每个服务器的规格如下：
▪双IntelXeonE5-2670v2处理器为2.5GHz-10核心/20超线程内核
▪32GB1600MHz的DDR3DRAM
▪1Gbps的网络接口卡
▪Ubuntu的14.04OS
▪集群之间使用ptpd同步
ONOS软件环境
▪JavaHotSpot（TM）（TM）64-BitserverVM;version1.8.0_31
▪JAVA_OPTS=“${JAVA_OPTS：
-Xms8G-Xmx8G}”
▪onos-1.1.0snapshot:
▪a31e13471ee626abce2bc43c413fab17586f4fc3
▪其他的具体与用例相关的ONOS参数将在具体的用例中进行说明
下面将具体介绍每个用例的细节配置，测试结果讨论及分析。
实验A＆B-拓扑（Switch,Link）发现时延测试
目标
本实验是测试ONOS控制器在不同规模的集群环境中是如何响应拓扑事件的，测试拓扑事件的类型包括：
1）交换机连接或断开ONOS节点
2）在现有拓扑中链路的up和down
ONOS作为一个分布式的系统架构，多节点集群相比于独立节点可能会发生额外的同步拓扑事件的延迟。
除了限制独立模式下的延迟时间，也要减少由于onos集群间由于EW-wise通信事件产生额外延时。
配置和方法—交换机连接/断开的延迟
下面的图表说明了测试设置。
一个交换机连接事件，是在一个“floating”（即没有交换机端口和链路）的OVS（OF1.3）上通过“set-controller”命令设置OVS桥连接到onos1控制器。
我们在OF控制层面网络上使用tshark工具捕捉交换机上线的时间戳，ONOSDevice和Graph使用“topology-event-metrics”应用记录时间戳。
通过整理核对这些时间戳，我们得出从最初的事件触发到ONOS在其拓扑中记录此事件的“端到端”的时序曲线。
所需得到的几个关键时间戳如下：
1.设备启动连接时间点t0，tcpsyn/ack；
2.OpenFlow协议的交换：
▪t0->ONOSFeaturesReply；
▪OVSFeaturesReply->ONOSRoleRequest;（ONOS在这里处理选择主备控制器）；
▪ONOSRoleRequest->OVSRoleReply–OF协议的初始交换完成。
3.ONOScore处理事件的过程：
▪OF协议交换完成后触发DeviceEvent；
▪本地节点的DeviceEvent触发Topology（Graph）Event。
同样的，测试交换机断开事件，我们使用ovs命令“del-controller”断开交换机与它连接的ONOS节点，捕获的时间戳如下：
1.OVStcpsyn/fin（t0）;
2.OVStcpfin;
3.ONOSDeviceEvent;
4.ONOSGraphEvent（t1）.
交换机断开端到端的延迟为（T1-T0）
当我们增大ONOS集群的大小，我们只连接和断开ONOS1上的交换机，并记录所有节点上的事件时间戳。
集群的整体延迟是GraphEvent报告中最迟的节点的延时时间。
在我们的测试脚本中，我们一次测试运行多个迭代（例如，20次迭代）来收集统计结果。
设置和方法—链路up/down的延迟
测试一条链接up/down事件的延迟，除了我们用两个OVS交换机创建链路（我们使用mininet创建一个简单的两个交换机的线性拓扑结构）外，我们使用了与交换机连接测试的类似方法。
这两个交换机的主控权属于ONOS1。
参照下面的图表。
初步建立交换机-控制器连接后，设置一个交换机的接口up或down，我们通过端口up或down事件来触发此测试。
一些关键的时间戳记录，如下所述：
1.交换机端口up/down,t0；
2.OVS向ONOS1发送OFPortStatusUpdate消息；
2a.在端口up的情况下，ONOS通过给每个OVS交换机发送链路发现消息来产生链路发现事件，同时ONOS收到其他交换机发送的OpenflowPacketIn消息。
3.ONOScore处理事件过程：
由OFportstatus消息引起的Device事件;（ONOS处理）
链路down时，LinkEvent由DeviceEvent触发在本地节点产生，链路up时，LinkEvent是在链路发现PacketIn/out完成后产生的；（主要时间都是在OFP消息和ONOS处理上）
本地节点生成GraphEvent。
（ONOS处理）
类似于交换机的连接测试，我们认为在GraphEvent中登记的集群中最迟的节点的延时时间为集群的延迟。
结果
Switch-addEvent:
LinkUp/DownEvent：
分析和总结
SwitchConnect/DisconnectEvent：
当一个交换机连接到ONOS时，明显的时延划分为以下几个部分：
1.链路发现的中时延最长的部分，是从最初的tcp连接到ONOS收到Openflowfeatures-replay消息。
进一步分析数据包（在结果图中未示出），我们可以看到大部分时间是花在初始化控制器与交换机的OpenFlow握手阶段，ONOS等待OVS交换机响应它的features_request。
而这个时延很大程度上不是由ONOS的处理引起的。
2.其次是在"OFPfeaturereply->OFProlerequest"部分，这部分时延也会随着ONOS集群规模增加而增加，其主要花费在ONOS给新上线的交换机选择主控权上，这是由于单节点的ONOS只需在本地处理，而多节点的集群环境中，集群节点之间的通信将会带来这个额外的延时
3.接着便是从OpenFlow握手完成（OFProlereply）到ONOS登记一个DeviceEvent的过程中消耗的时延。
这部分的时延也受多节点ONOS配置影响，因为此事件需要ONOS将其写入DeviceStore。
4.最后一个延时比较长的是ONOS在本地处理来着Devicestore的Deviceevent到向Graph中注册拓扑信息事件的部分。
断开交换机时，随着ONOS集群规模的增大ONOS触发Device事件的时延将略有增加。
总之，在OpenFlow消息交换期间，OVS对feature-request的响应时延占据了交换机建立连接事件中，整体时延的绝大部分。
接着，ONOS花费约9毫秒处理主控权选。
最后，ONOS在多节点集群环境下，由于各节点之间需要通信选举主节点，交换机上/下线时延将都会增加。
LinkUp/DownEvents:
此次测试，我们首先观察到的是，链路up事件比链路down事件花费更长的时间。
通过时延分析，我们可以看到OVS的端口up事件触发了ONOS特殊的行为链路发现，因此，绝大多数时延主要由处理链路发现事件引起。
与单节点的ONOS相比这部分时延受集群节点的影响也比较大。
另外，大多数ONOScore花费在向Graph登记拓扑事件上的时延在个位数的ms级别。
在大部分的网络操作情况下，虽然整体拓扑事件的低延迟是可以被容忍的，但是交换机/链路断开事件却至关重要，因为它们被更多的看作是applications的adverseevents。
当ONOS能更快速的检测到linkdown/up事件时，pplications也就能更快速的响应此adverseevents，我们测试的此版本的ONOS具有在个位数ms级发现switch/linkdown事件的能力。
实验C：
intentinstall/remove/re-route延迟测试
目的
这组测试旨在得到ONOS当一个application安装，退出多种批大小的intents时的延迟特性（即响应时间）。
同时也得到ONOS路径切换事件的延时特性，即最短路径不可用，已安装的intent由于路径改变而需要重路由时所花费的时延。
这是一个ONOS的全方位系统测试，从ONOS的NBAPI经过intent和flowsubsystem到ONOS的SBAPI；采用NullProvider代替OpenflowAdaptor进行测试。
这组测试结果将向网络运营商和应用开发者提供当operatingintents时applications所期望的响应时间以及intents批的大小和集群数量的大小对时延的影响的第一手资料。
配置和方法—batchintent安装与退出
参考下图，我们用ONOS内置的app“push-test-intent”从ONOS1并通过ONOS1的intentAPI推进一个批的点对点intents。
“push-test-intent”工具构造一系列的基于终点的，批大小和applicationid的intents。
然后通过intentAPI发送这些intents请求。
当成功安装所有的intents时，返回延迟（响应时间）。
随后退出这些intents并返回一个退出响应时间。
当intents请求被发送时，ONOS内部转换intents到流规则并写入相应的分布式存储来分发intents和流表。
参考下图，特别是我们的实验中，intents被构建在一个端到端的7个线性配置的交换机上，也就是说所有intents的入口是从S1的一个端口和它们的出口是S7的一个端口。
（我们使用在拓扑中额外的交换机S8进行intentre-route测试，这个测试后续描述）。
我们通过NullProviders来构建交换机（NullDevices），拓扑（NullLinks）和流量（NullFlows）。
当增大集群节点数量时，我们重新平均分配switch的主控权到各个集群节点。
在这个实验中，我们将使用如下指标来衡量ONOS性能：
▪所有安装的intents是6hops点到点intents；
▪Intent批的大小：
1，10，100，1000，5000intents；
▪测试次数：
每个用例重复测试20次（4次预测试之后统计）；
▪集群规模大小从1到3，5，7个节点。
配置和方法--intentRe-route
同样参照上图，intentre-route延迟是一个测试ONOS在最短路径不可用的情况下，重新安装所有intents到新路径的速度。
测试顺序如下：
1.我们通过“push-test-intents-i”选项预安装不会自动退出的intents在线性最短路径上。
然后我们通过修改NullProvider链路定义文件模拟最短路径的故障。
当新拓扑被ONOS发现时，我们通过检查ONOS日志获取触发事件的初始时间戳t0；
2.由于6-hop最短路径已不可用。
ONOS切换到通过S8的7-hop备份路径。
Intent和流系统响应该事件，退出旧intents并删除旧流表（因为ONOS当前实现，所有intents和流已不可重新使用）。
3.接下来，ONOS重新编译intents和流，并安装。
在验证所有intents确实被成功安装后，我们从“Intents-events-metrics”捕获最后的intent安装时间戳（t1）。
4.我们把（t1-t0）作为ONOS重路由intent（s）的延迟。
5.测试脚本迭代的几个参数：
a.Intent初始安装的批大小：
1,10,100,1000和5000intents；
b.每个测试结果统计的是运行20次的结果平均值（4个预测试之后开始统计）；
c.ONOS集群规模从1,到3,5,7节点。
结果
分析和总结
我们从这个实验中得出结论：
1.正如预期，与单节点的ONOS相比，多个节点的ONOS集群由于EW-wise通信的需要延迟比较大
2.小批intents（1-100）,不计批大小时，其主要的延时是一个固定的处理时延，因此当批大小增大，每一个intent安装时间减少，这就是时延大批的优点。
3.批大小非常大的情况下（如5000），随着集群大小增加（从3到7），延迟减少，其主要是由于每个节点处理较小数量的intents；
4.Re-routeing延时比初始化安装和退出的延迟都小。
实验D：
IntentsOperation吞吐量
目标
本项测试的目的是衡量ONOS处理intentsoperations请求的能力。
SDN控制器其中一个重要用例就是允许agileapplications通过intents和流规则频繁更改网络配置。
作为一款SDN控制器，ONOS应该具有高水平的intents安装和撤销处理能力。
ONOS使用的分布式架构,随着集群规模的增加，理应能够维持较高的intentoperation吞吐量。
设置和方法
下图描述了测试方法：
本测试使用工具"intent-perf"来产生大量的Intentsoperation请求。
这个intent-perf工具可以在ONOS集群环境中的任何一个节点激活并使用。
这个工具在使用过程中有个三个参数需要配置：
▪numKeys–唯一的intents数量,默认40,000;
▪cyclePeriod–intents安装和撤销的周期（时间间隔），默认1000ms;
▪numNeighbors–程序运行时，发送到各个集群节点的方式。
0表示本节点；-1表示所有的集群节点
当intent-perf在ONOS节点运行时，以恒定的速率产生大量的、ONOS系统可以支持的intents安装撤销请求。
在ONOS日志中或clirequest中，会周期性的给出总体的intents处理吞吐量。
持续运行一段时间后，我们可以观察到在集群的某个或某些节点总体吞吐量达到了饱和状态。
总体吞吐量需要包含intents安装撤销操作。
统计所有运行intent-perf这个工具的ONOS节点上的吞吐量并求和，从而得到ONOS集群的总体吞吐量。
intent-perf只产生"1-hop"的intents，即这些intents被编译而成的流表的出口和入口都是在同一个交换机上，所以Nullproviders模块不需要生成一个健全的拓扑结构。
特别是本实验中，我们使用两个相邻的场景。
首先，设置numNeighbors=0，这种场景下，intent-perf只需要为本地的ONOS节点产生的intents安装和撤销请求，从而把intents的东西向接口通信降至最低；其次，设置numNeighbors为-1后，intent-perf生成器产生的intents安装和撤销请求需要分发到所有的ONOS集群节点，这样会把东西向接口的通信量最大化。
本次测试持续进行了300秒的负载测试，统计集群的总体吞吐量。
其他的参数使用默认值。
结果
分析和结论
通过本次实验得出结论如下：
1.我们看到在ONOS的intentsoperations测试中一个明显趋势：
总体吞吐量随着集群节点的增加而增加；
2.在流表子系统测试中集群的场景对吞吐量的影响微乎其微。
实验E：
Flow子系统迸发吞吐量测试
目的
如前面所提到的，流子系统是onos的一个组成部分，其作用是将Intents转换成可以安装到openflow交换机上的流规则。
另外，应用程序可以直接调用其北向api来注入流规则。
使用北向api和intent框架是此次性能评估的关键。
另外，此次实验不但给我们暴漏了端到端Intentperformance的性能缺陷，而且展示了当直接与流规则子系统交互时对应用的要求。
配置及方法
为了产生一批将被onos安装删除的流规则，我们使用脚本“flow-tester.py”。
实际上这些脚本是onos工具执行的一部分。
具体位置在（$ONOS_ROOT/tools/test/bin）目录下。
执行这个脚本将触发onos安装一套流规则到所控制的交换机设备，当所有流规则安装成功之后将会返回一个时延时间。
这个脚本也会根据接收的一系列的参数去决定这个测试怎么运行。
这些参数如下：
▪每个交换机所安装的流规则的数量
▪邻居的数量-由于交换机的连接的控制器并非本地的onos节点，需要onos本地节点同步流规则到（除了运行脚本的onos本地节点之外的）onos节点
▪服务的数量-运行onos脚本的节点数量，即产生流规则的onos节点数量
下图简要的描述了测试的配置：
从下图可以看出，onos1，onos2是运行onos脚本产生流规则的两个服务器；当两个流生成服务器生成流给两个邻居，也就是所生成的流规则被传递到两个与之相邻的节点安装。
（因为这个流规则属于被邻居节点控制器的交换机）。
我们使用了NullProvider作为流规则的消费者，绕过了使用Openflow适配器和真实的或者模拟的交换机存在的潜在的性能限制。
具体实验参数设置
▪NullDevices的数量保持常量35不变，然后被平均的分配到集群中的所有节点，例如，当运行的集群中有5个节点，每个节点将控制7个NullDevices;
▪集群一共安装122500条流规则-选择这个值其一是因为它足够大，其二，它很容易平均分配到测试中所使用的集群节点。
这也是工具“flow-tester.py”计算每个交换机所安装的流规则数量的一个依据。
▪我们测试了2个关联场景：
1）邻居数量为0，即所有的流规则都安装在产生流的服务器上场景；2）邻居数量为-1，即每个节点给自己以及集群中的其它节点产生流规则
▪测试集群规模1,3,5,7
▪响应时间为4次预测试之后20次的的测试时间统计整合得出
备注：
版本发布的时候，ONOS核心仍然采用Hazelcast作为存储协议来备份流规则。
实验表明，使用Hazelcast协议作为备份，可能导致流规则安装速率频繁迸发增长。
在这一系列实验中，我们通过修改发布版本如下路径的代码关闭了流规则备份。
（$ONOS_ROOT/core/store/dist/src/main/java/org/onosproject/store/flow/impl/DistributedFlowRuleStore.java）
分析与结论
通过测试，可以得出如下系统性能测试结论：
1.根据测试数据显示，当配置N=0时，与配置N=“all”相比，系统有更高的吞吐量。
也就是说当生成的流规则只安装给本地ONOS节点控制器的设备时，流子系统的性能比安装给所有ONOS节点控制的设备时高。
因为，ONOS节点之间的EW-wise通信存在开销/瓶颈。
即，当配置N=“all”时，性能低，符合预期值。
2.总的来说，这两种情况下通过增大集群节点数量测试，吞吐量随着集群数量的增加有明显的提高。
但是这种提高是非线性的。
例如，N=“all”与N=“0”相比，当节点间需要通信同步时，平稳增加的性能趋于平缓。
3.设置N=“all”与N=“0”获得的类似的性能数据说明，EW-wise通信没有成为ONOSintentoperation性能的瓶颈
升级会员 