开放网络操作系统 ONOS Blackbird 性能评估

Question

ONOS 是一个网络控制器。applications 通过 intent APIs 与 ONOS 进行交互。ONOS 通过其南向适配层控制数据网络的转发（例如，openflow 网络）。ONOS 控制层与数据转发层之间是 ONOS 流 子系统，ONOS 流子系统是将 application intens 转换为 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 的适配层部署了一套 Null Providers 与 ONOS core 进行交互。Null Providers 担任着生成 device,link,host 以及大量的流规则的角色。通过使用 Null Providers,我们可以避免并消除 Openflow 适配和使用真实设备或者模拟的 Openflow 设备所存在的潜在的性能瓶颈。

同时，我们也部署了一些负载生成器，这样可以使应用或者网络接口生成高强度的负载去触及 ONOS 的性能极限。
这些生成器包括：
1.Intent performance 生成器“onos-app-intent-perf”，它与 intent API 交互,生成 intent 安装/删除操作，并根据 ONOS 可承受的最高速度自我调节生成的 Intent 操作的负载。
2.流规则安装 Python 脚本工具与 ONOS flow subsystem 交互去安装和删除 subsystem 中的流规则。
3.Null LinkProvider 中的 link 事件（闪烁）生成器，可以迅速提升发送速度到 ONOS 所能承受的极限并依此速率发送 link up/down 信息给 ONOS core。
4.此外，我们在"topology-events-metrics" 和"intents-events-metrics" 应用中利用计数器去获取关键事件的时间戳与处理速率来方便那些时间及速度相关的测试。

我们将在后续的每个不同的测试过程中详细介绍这些生成器的配置。

测试环境配置

A 7 台 集群实验所需要的裸服务器。每个服务器的规格如下：

• 双 Intel Xeon E5-2670v2 处理器为 2.5GHz - 10 核心/20 超线程内核
• 32GB1600MHz 的 DDR3 DRAM
• 1Gbps 的网络接口卡
• Ubuntu 的 14.04 OS
• 集群之间使用 ptpd 同步

ONOS 软件环境

• Java HotSpot(TM) （TM）64-Bit server VM; version 1.8.0_31
• JAVA_OPTS=“${JAVA_OPTS： - Xms8G-Xmx8G}”
• onos-1.1.0 snapshot:
• 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 工具捕捉交换机上线的时间戳，ONOS Device 和 Graph 使用“topology-event-metrics”应用记录时间戳。通过整理核对这些时间戳，我们得出从最初的事件触发到 ONOS 在其拓扑中记录此事件的“端到端”的时序曲线。

所需得到的几个关键时间戳如下：
1.设备启动连接时间点 t0，tcp syn/ ack；

2.OpenFlow 协议的交换：

• t0 -> ONOS Features Reply；
• OVS Features Reply -> ONOS Role Request; (ONOS 在这里处理选择主备控制器)；
• ONOS Role Request -> OVS Role Reply –OF 协议的初始交换完成。

3.ONOS core 处理事件的过程：

• OF 协议交换完成后触发 Device Event；
• 本地节点的 Device Event 触发 Topology (Graph) Event。

同样的，测试交换机断开事件，我们使用 ovs 命令“del-controller”断开交换机与它连接的 ONOS 节点，捕获的时间戳如下：

1.OVS tcp syn/fin (t0);
2.OVS tcp fin;
3.ONOS Device Event;
4.ONOS Graph Event (t1).

交换机断开端到端的延迟为（T1 - T0）

当我们增大 ONOS 集群的大小，我们只连接和断开 ONOS1 上的交换机，并记录所有节点上的事件时间戳。集群的整体延迟是 Graph Event 报告中最迟的节点的延时时间。在我们的测试脚本中，我们一次测试运行多个迭代（例如，20 次迭代）来收集统计结果。

设置和方法—链路 up/down 的延迟

测试一条链接 up / down 事件的延迟，除了我们用两个 OVS 交换机创建链路（我们使用 mininet 创建一个简单的两个交换机的线性拓扑结构）外，我们使用了与交换机连接 测试的类似方法。这两个交换机的主控权属于 ONOS1。参照下面的图表。初步建立交换机-控制器连接后，设置一个交换机的接口 up 或 down，我们通过端 口 up 或 down 事件来触发此测试。
一些关键的时间戳记录，如下所述：
1. 交换机端口 up/down, t0；
2. OVS 向 ONOS1 发送 OF PortStatus Update 消息；
2a.在端口 up 的情况下，ONOS 通过给每个 OVS 交换机发送链路发现消息来产生链路发现事件，同时 ONOS 收到其他交换机发送的 Openflow PacketIn 消息。

3.ONOS core 处理事件过程：
由 OF port status 消息引起的 Device 事件; （ONOS 处理）
链路 down 时，Link Event 由 Device Event 触发在本地节点产生，链路 up 时，Link Event 是在链路发现 PacketIn/out 完成后产生的；（主要时间都是在 OFP 消息和 ONOS 处理上）
本地节点生成 Graph Event。（ONOS 处理）

类似于交换机的连接测试，我们认为在 Graph Event 中登记的集群中最迟的节点的延时时间为集群的延迟。

结果

Switch-add Event:

Link Up/Down Event：

分析和总结

Switch Connect/Disconnect Event：

当一个交换机连接到 ONOS 时，明显的时延划分为以下几个部分：
1.链路发现的中时延最长的部分，是从最初的 tcp 连接到 ONOS 收到 Openflow features-replay 消息。进一步分析数据包（在结果图中未示出），我们可以看到大部分时间是花在初始化控制器与交换机的 OpenFlow 握手 阶段，ONOS 等待 OVS 交换机响应它的 features_request。而这个时延很大程度上不是由 ONOS 的处理引起的。

2.其次是在"OFP feature reply -> OFP role request"部分，这部分时延也会随着 ONOS 集群规模增加而增加，其主要花费在 ONOS 给新上线的交换机选择主控权上，这是由于单节点的 ONOS 只 需在本地处理，而多节点的集群环境中，集群节点之间的通信将会带来这个额外的延时

3.接着便是从 OpenFlow 握手完成(OFP role reply) 到 ONOS 登记一个 Device Event 的过程中消耗的时延。这部分的时延也受多节点 ONOS 配置影响，因为此事件需要 ONOS 将其写入 Device Store。
4.最后一个延时比较长的是 ONOS 在本地处理来着 Device store 的 Device event 到向 Graph 中注册拓扑信息事件的部分。

断开交换机时，随着 ONOS 集群规模的增大 ONOS 触发 Device 事件的时延将略有增加。

总之，在 OpenFlow 消息交换期间，OVS 对 feature-request 的响应时延占据了交换机建立连接事件中，整体时延的绝大部分。接 着，ONOS 花费约 9 毫秒处理主控权选。最后，ONOS 在多节点集群环境下，由于各节点之间需要通信选举主节点，交换机上/下线时延将都会增加。

Link Up/Down Events:

此次测试，我们首先观察到的是，链路 up 事件比链路 down 事件花费更长的时间。通过时延分析，我们可以看到 OVS 的端口 up 事件触发了 ONOS 特 殊的行为链路发现，因此，绝大多数时延主要由处理链路发现事件引起。与单节点的 ONOS 相比这部分时延受集群节点的影响也比较大。另外，大多数 ONOS core 花费在向 Graph 登记拓扑事件上的时延在个位数的 ms 级别。

在大部分的网络操作情况下，虽然整体拓扑事件的低延迟是可以被容忍的，但是交换机/链路断开事件却至关重要，因为它们被更多的看作是 applications 的 adverse events。当 ONOS 能更快速的检测到 link down/up 事件时，pplications 也就能更快速的响应此 adverse events，我们测试的此版本的 ONOS 具有在个位数 ms 级发现 switch/link down 事件的能力。

实验 C ：intent install/remove/re-route 延迟测试

目的

这组测试旨在得到 ONOS 当一个 application 安装，退出多种批大小的 intents 时的延迟特性（即响应时间）。

同时也得到 ONOS 路径切换事件的延时特性，即最短路径不可用，已安装的 intent 由于路径改变而需要重路由时所花费的时延。这是一个 ONOS 的 全方位系统测试，从 ONOS 的 NB API 经过 intent 和 flow subsystem 到 ONOS 的 SB API；采用 Null Provider 代替 Openflow Adaptor 进行测试。

这组测试结果将向网络运营商和应用开发者提供当 operating intents 时 applications 所期望的响应时间以及 intents 批的大小和集群数量的大小对时延的影响的第一手资料。

配置和方法—batch intent 安装与退出

参考下图，我们用 ONOS 内置的 app“push-test-intent”从 ONOS1 并通过 ONOS1 的 intent API 推进一个批的点对点 intents。“push-test-intent”工具构造一系列的基于终点的，批大小和 application id 的 intents。然后通过 intent API 发送这些 intents 请求。当成功安装所有的 intents 时，返回延迟（响应时间）。随后退出这些 intents 并返回一个退出响应时间。当 intents 请求被发送时，ONOS 内部转换 intents 到流规则并写入相应的分布式存储来分发 intents 和流表。

参考下图，特别是我们的实验中，intents 被构建在一个端到端的 7 个线性配置的交换机上，也就是说所有 intents 的入口是从 S1 的一个端口 和它们的出口是 S7 的一个端口。（我们使用在拓扑中额外的交换机 S8 进行 intent re-route 测试，这个测试后续描述）。我们通过 Null Providers 来构建交换机（Null Devices），拓扑（Null Links）和流量（Null Flows）。

当增大集群节点数量时，我们重新平均分配 switch 的主控权到各个集群节点。

在这个实验中，我们将使用如下指标来衡量 ONOS 性能：

• 所有安装的 intents 是 6hops 点到点 intents；
• Intent 批的大小：1，10，100，1000，5000 intents；
• 测试次数：每个用例重复测试 20 次（4 次预测试之后统计）；
• 集群规模大小从 1 到 3，5，7 个节点。

配置和方法--intent Re-route

同样参照上图，intent re-route 延迟是一个测试 ONOS 在最短路径不可用的情况下，重新安装所有 intents 到新路径的速度。

测试顺序如下：

1.我们通过“push-test-intents -i”选项预安装不会自动退出的 intents 在线性最短路径上。然后我们通过修改 Null Provider 链路定义文件模拟最短路径的故障。当新拓扑被 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 和 5000 intents；
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：Intents Operation 吞吐量

目标

本项测试的目的是衡量 ONOS 处理 intents operations 请求的能力。SDN 控制器其中一个重要用例就是允许 agile applications 通过 intents 和流规则频繁更改网络配置。作为一款 SDN 控制器，ONOS 应该具有高水平的 intents 安装和撤销处理能 力。ONOS 使用的分布式架构, 随着集群规模的增加，理应能够维持较高的 intent operation 吞吐量。

设置和方法

下图描述了测试方法：

本测试使用工具"intent-perf"来产生大量的 Intents operation 请求。这个 intent-perf 工具可以在 ONOS 集群环境中的任何一个节点激活并使用。这个工具在使用过程中有个三个参数需要配置：

• numKeys – 唯一的 intents 数量, 默认 40,000;
• cyclePeriod – intents 安装和撤销的周期（时间间隔），默认 1000ms;
• numNeighbors –程序运行时，发送到各个集群节点的方式。0 表示本节点；-1 表示所有的集群节点

当 intent-perf 在 ONOS 节点运行时，以恒定的速率产生大量的、ONOS 系统可以支持的 intents 安装撤销请求。在 ONOS 日志中或 cli request 中，会周期性的给出总体的 intents 处理吞吐量。持续运行一段时间后，我们可以观察到在集群的某个或某些节点总体吞吐量达到了饱和状 态。总体吞吐量需要包含 intents 安装撤销操作。统计所有运行 intent-perf 这个工具的 ONOS 节点上的吞吐量并求和，从而得到 ONOS 集群 的总体吞吐量。

intent-perf 只产生"1-hop" 的 intents，即这些 intents 被编译而成的流表的出口和入口都是在同一个交换机上，所以 Null providers 模块不需要生成一个健全的拓扑结构。

特别是本实验中，我们使用两个相邻的场景。首先，设置 numNeighbors = 0，这种场景下，intent-perf 只需要为本地的 ONOS 节点产生的 intents 安装和撤销请求，从而把 intents 的东西向接口通信降至最 低；其次，设置 numNeighbors 为-1 后，intent-perf 生成器产生的 intents 安装和撤销请求需要分发到所有的 ONOS 集群节点，这样会把东西向接口的通信量最大化。本次 测试持续进行了 300 秒的负载测试，统计集群的总体吞吐量。其他的参数使用默认值。

结果

分析和结论

通过本次实验得出结论如下：
1.我们看到在 ONOS 的 intents operations 测试中一个明显趋势：总体吞吐量随着集群节点的增加而增加；
2.在流表子系统测试中集群的场景对吞吐量的影响微乎其微。

实验 F：Flow 子系统迸发吞吐量测试

目的

如前面所提到的，流子系统是 onos 的一个组成部分，其作用是将 Intents 转换成可以安装到 openflow 交换机上的流规则。另外，应用程序 可以直接调用其北向 api 来注入流规则。使用北向 api 和 intent 框架是此次性能评估的关键。另外，此次实验不但给我们暴漏了端到端 Intent performance 的性能缺陷，而且展示了当直接与流规则子系统交互时对应用的要求。

配置及方法

为了产生一批将被 onos 安装删除的流规则，我们使用脚本“flow-tester.py”。实际上这些脚本是 onos 工具执行的一部分。具体位置 在（$ONOS_ROOT/tools/test/bin）目录下。执行这个脚本将触发 onos 安装一套流规则到所控制的交换机设备，当所有流规则安装成 功之后将会返回一个时延时间。这个脚本也会根据接收的一系列的参数去决定这个测试怎么运行。这些参数如下：

• 每个交换机所安装的流规则的数量
• 邻居的数量-由于交换机的连接的控制器并非本地的 onos 节点，需要 onos 本地节点同步流规则到（除了运行脚本的 onos 本地节点之外的）onos 节点
• 服务的数量-运行 onos 脚本的节点数量，即产生流规则的 onos 节点数量

下图简要的描述了测试的配置：

从下图可以看出，onos1，onos2 是运行 onos 脚本产生流规则的两个服务器；当两个流生成服务器生成流给两个邻居，也就是所生成的流规则被传递到两个与之相邻的节点安装。（因为这个流规则属于被邻居节点控制器的交换机）。

我们使用了 Null Provider 作为流规则的消费者，绕过了使用 Openflow 适配器和真实的或者模拟的交换机存在的潜在的性能限制。

具体实验参数设置

• Null Devices 的数量保持常量 35 不变，然后被平均的分配到集群中的所有节点，例如，当运行的集群中有 5 个节点，每个节点将控制 7 个 Null Devices;
• 集群一共安装 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 通信没有成为 ONOS intent operation 性能的瓶颈。