SDN实践分享（十）：SDN控制器性能测试

该篇文章系SDN实战团微信群（团长张宇峰@brocade）组织的线上技术分享整理而成，本次由全球SDN测试认证中心的张攀给大家分享SDN控制器性能测试。

嘉宾介绍
--------------------------------------------------------------------------

张攀

2013年加入SDN测试认证中心，工程师，带领团队开发测试工具。同时任ONF测试工作组副主席，在ONF和IETF内写标准，推动测试方法标准化。喜欢编程，网络和英语。
--------------------------------------------------------------------------
Hello大家晚上好，昨天刚刚吃完冬至的饺子，现在打嗝还带有淡淡的茴香余韵。明天又正好是平安夜，原本只能靠和美帝开电话会议丰富夜生活的朋友们终于拥有了西体中用的选择。在中西方两大节日的夹攻之下，以及不远处元旦春节的渊渟岳峙之前，一切deadline都显得那么力不从心。但张老师给布置的作业始终占据着我Todo list的最高优先级，并以附丽其上的人格魅力孤独地抗衡着浮动的人心。于是今晚我就在这里向大家汇报一下近期关于SDN控制器性能测试的工作内容，希望明天可以给这个Todo item打上一个气定神闲的勾勾。

稍微自我介绍一下吧，张攀，忝列80后最后一期，供职于天地互连全球SDN测试认证中心，也兼任ONF测试工作组副主席。在公司内带队开发测试软件和新业务，在外带领国际标准组织内的同仁撰写标准，搭建认证体系。平时就喜欢闷头写代码，闷头看书，闷头练习英语口语，工作后新填的爱好是闷头写邮件和闷头交换名片。好在公司写字楼电梯早高峰不好挤，每天仰颏爬25层，才免去了颈椎之患。

本次分享的SDN控制器性能测试的内容，本意是想先在ONF内标准化，但以标准组织的工作效率，新一茬茴香长出来也出不了一个标准，所以决定甩开ONF单干。本月初的时候发布了一个SDN控制器性能测试的白皮书，介绍了测试方法，并附上了定量的测试结果，希望能在控制器用户选型的时候具有参考意义。本次分享的内容绝大部分都是该白皮书的节选，希望能得到实战团内诸位方家的指正。

SDN技术最大的特点，就是这是一种由用户驱动的技术。用户希望通过SDN的部署，解决他们的问题；但新技术部署本身就是一个充满问题的过程。我们作为测试认证机构，工作的目的并不仅仅是为了写写标准文档，贴贴认证logo，而是为了解决用户部署中的实际问题。围绕这一中心我们已经做了很多工作，控制器性能测试自然也是以“解决问题”为核心任务的。作为一种可以解决问题的方法，自然也就为其自身赋予了必要性。

粗略总结一下运营商，网络公司等SDN用户在部署中可能会遇到的问题。一是互操作性的问题，不同厂商的设备需要互联互通，交换机要和自己定制的控制器互联互通，这些是最基本的要求，但在最开始的部署中，一定也会存在问题。对此我们的解决方案是标准化。拿OF1.3举例来说，如果SDN用户选择了不同厂商的设备，很容易导致互操作性的问题。为了解决这一问题，我们推行了OF1.3一致性测试认证，写了规范标准，自己开发了测试工具，并搭建了认证体系，取得认证的设备在OF1.3协议实现方面是一致的，确保了厂商设备实现的标准化，进而在很大程度上帮助SDN用户解决了互操作性的问题。目前国内的华为中兴华三神码等厂商都已有数款设备取得了该认证，还有更多的设备在测试认证的过程之中。

除了互操作性之外，SDN用户更关注的是SDN这项技术许诺的可以带来的种种好处。我们有很多词汇可以代指这些好处：灵活、智能、自动化、可编程、资源池化，业务感知等等。但这些好处的取得，全都依赖于SDN网络中的核心组件——控制器是不是给力。作为以中央管控的方式管理整张网络的大脑，控制器的性能关乎整个网络的性能表现。为了帮助SDN用户真正享受到SDN带来的利益，我们设计推行了一套SDN控制器性能测试方案，以定量的方式将控制器的关键性能指标呈现出来，以供用户参考。目前仅针对Openflow 1.3这一南向协议。

运行在不同硬件平台上的控制器会有不同的性能表现，但无论硬件的性能如何强劲，也很少会有在实际部署中只部署一个控制器的用户。更多的情况，是将多台控制器组合成集群运行。在我们的白皮书中，没有控制器与硬件平台纵向或横向的比较，而是比较了同一控制器单点运行和三台集群运行的性能差异。每一个节点运行的硬件平台都是完全一致的。从而为用户搭建控制器集群提供了参考。我们的每一个测试例，也都会分别在单点模式和集群模式下执行，并对比分析了结果。

在测试之前有几个关于执行测试的建议：1. 测试的网络与外界的网络物理隔离，以防止外界的报文对测试环境和结果产生干扰。2.测试仪与运行控制器的服务器直接连接，以防止中间设备产生非必要的时延和失效。3.每一测试例建议迭代执行10次以上，记录最大值，最小值以及平均值。4. 在集群模式运行时，记录各个节点的CPU和内存使用率，检测是否在压力之下集群具备loadbalance机制。

白皮书里一共包含有将近10个测试例，限于篇幅，着重向大家介绍其中的三个，包括测试拓扑、测试方法、结果呈现以及结果对比。第一个是Control channel capacity test，目的是测量出一个控制器能同时建立的最大的OpenFlow channel的数量。

不同数量的交换机以不同的拓扑建立与控制器的连接，直到达到最大数目并保持稳定连接。记录数量增长过程中的内存使用情况。下面是结果柱状图：

三组柱状图分别代表不同的Topo类型，不同的颜色代表不同的交换机的数量。上面的数字是内存使用的数量。需要指出的是在最左边Linear Topo那一组，800和1000个交换机的时候数字都是N/A，这代表在该数量下，交换机已无法和控制器建立稳定的连接。下面我们将三台控制器组合成集群模式，重新进行这一测试。对于集群模式，用户可能怀有如下的期望：最大连接数增加，单点平均内存消耗减小。事实是不是这样呢？我们看一下结果：

与上副图不同，这次的结果都是Linear Topo的结果。三组柱状图则分别代表组成集群的三个不同的节点，不同的颜色还是代表不同的交换机数量。我们可以观察到，在集群模式下，刚才不能稳定建立连接的800个交换机也可以稳定了，这应该符合用户的第一点期望。但观察内存使用情况，我们发现每一个节点内存的使用不但没有下降，反而略有升高。我们推测是由于每个控制器都需要掌握全部的拓扑情况，同时还有节点间的同步线程占用了额外的内存空间。虽然数量增加了，但内存占用也同样增加，该性质可能会给用户在可拓展性方面带来问题。

以上的示例可以用来说明测试方法和测试结果的组织方式，也可以在结果分析中得出供SDN用户参考的结论。在这之后还有介绍拓扑发现时间，拓扑事件侦测时间等测试例，但限于篇幅就不再赘述，下面介绍本次的第二个测试例，Reactive Flow Setup Rate，也就是常说的流表下发速率。

由测试工具以Packet_in消息上送对应的ARP_request/reply消息，控制器接收之后进行2层学习，然后下发双向连通的流表。上送ARP消息的速率会影响控制器下发流表的速率，所以我们选择了几个不同的上送速率，然后分别测量控制器的下发速率。下面是单点模式下的测试结果：

每一组柱状图代表不同的ARP消息个数总量，不同的颜色代表不同的上送速率（个/秒）。可以看出上送速率在200-400之间时流表下发速率与上送速率正相关，当速率达到500时下发速率没有显着变化。但当速率达到600，下发速率出现显着下降，即认为此时控制器已出现overload，影响了性能表现。如此可以为SDN用户评估自己的网络性能时给出定量的依据。

该测试同样针对集群进行。用户对集群的期望是，有更高的速率和压力承载能力。执行测试的时候似乎也显示出了期望的结果，但在结果分析和统计阶段我们发现了问题。在集群模式下，交换机要和三个控制器节点同时建立连接，所有的APR消息都需要复制三份，同时上送给三个节点。每个节点都可能处理该消息，但只能由一个节点下发生成的流表。但我们观察到，当速率达到400的时候，出现了多个节点下发相同流表的情况，即一些流表重复安装，虽然提高了速率，但是都是无效的动作。因此集群的测试结果不能作为有效数据计入，也说明该控制器在同步机制方面存在一定缺陷。

上面是今天介绍的最后一个测试例，Reactive Path Setup Time，也就是链路建立时间。由不同数量的交换机组成不同的拓扑，在拓扑的最远端连接两个模拟的终端。完成拓扑发现之后，终端1发送ARP_request并由连接的交换机通过Packet_in上送，此时记为T1。控制器会将该APR_request消息通过Packet_out发送给终端2，终端2立即回复APR_reply消息，同样由Packet_in上送控制器。之后控制器会下发连通的流表，收到最后一条Flow_mod消息的时间记为T2，由此可以求出链路建立的时间。

下面是单点控制器的测试结果：

每一组柱状图代表不同的交换机数量，不同的颜色代表两种不同的拓扑类型，数字代表链路建立的时间。建立时间与节点数目正相关，不同的拓扑对建立时间也存在影响，定性分析与定量分析的结果相吻合。针对集群模式，用户会期望有更短的建立时间，但因为集群间同步机制的出现，实际测试中我们发现链路建立的时间反而是延长了，同时在分析阶段发现了与上一个测试例相同的问题：一些流表重复下发。因此集群的测试结果也不能作为有效数据计入统计。

以上是对三个测试例的简要介绍，我们的工作还有很多可以再细化的地方。比如不同场景下的流表下发速率，比如针对VxLAN等Overlay技术，以及后续的安全测试等等。新的进展和成果都会以各种形式汇报给大家，白皮书下载链接：http://www.sdnctc.com/public/download/Performance.pdf

分享到此结束，谢谢大家！
Q&A

Q1：集中式控制器 在实验中有多少台交换机就不太行了？
A1:我们是用了三个节点，linear topo到800个有些交换机就收不到echo了

Q2:有的用户比较关心 从控制器中读取信息的数据效率？请问有没有什么方法可以测试呢？ 我目前的想法可能是直接向三个控制器同时发get请求 然后看看处理效率？但是这样并不能给出一个很好的衡量集群处理效率？请问可以提供一些思路吗？或者有没有什么能够给三点集群进行一个总的衡量 而不是三点分开来的衡量？
A2:您说的是北向接口的测试内容吗？北向方面的因为各家控制器实现都不一样，所以目前我们除了自己写一个app然后看log之外也没什么太好的方法。以ODL来说如果我记得没错的话是可以在log里看到它各个节点收到get请求以及回复该请求的时间的,北向会是未来的一个工作重点，但目前缺少标准以及接口支持，只能针对比较主流的实现做特定的设计.

Q3: 除了时间的间隔之外 还有什么属性能够来衡量北向接口吗？或者有没有什么能够给三点集群进行一个总的衡量 而不是三点分开来的衡量？
A3:时间间隔就相当于是时延 还可以从吞吐量 比如同时发送大量的请求，看看是否可以正常工作来衡量,当然如果是性能范畴之外的，还可以检测北向接口策略冲突控制器是否会侦测，是否能调用system call等安全方面衡量.比如吞吐量就是给集群一个总的衡量，以一定速率发送请求，观察集群是否可以处理

Q4:那就是还需要一个 把请求分流的东东？
A4:我认为是这样的，北向的测试实现一般都是自己写app，这个app就可以分流这些请求

Q5:下发流表的latency你们用什么方法测？纯of转发和传统二层转发latency能差多少？从第一个arp包发出算。
A5:主动是指从北向请求下发流表，如果不算交换机安装流表的时间只看下发的时间，latency就是控制器收到请求的时间和of channel发送了flow mod的时间差 被动是控制器收到packet_in经过上层app处理之后下发的flow mod，latency就是packet_in和flow mod的时间差

--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。

声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。