OpenFlow性能测试目前依然处于起步阶段,虽然有少数的开源工具用于测试OpenFlow性能,但是比较OpenFlow产品的性能还没有一个标准。思博伦测试仪提出了对这些SDN产品的一个测试标准,作者对思博伦OpenFlow性能测试白皮书进行整理翻译,本文翻译1-5.1小节,其他章节的翻译会在下篇发布。
目录
1 摘要
2 为什么OpenFlow性能测试是必需的
3 本文参数
4 OpenFlow性能测试目标与挑战
5 OpenFlow性能测试注意事项
■5.1 表容量测试
■5.2 Flow-Mod性能
■5.3 Packet In/Out性能
■5.4 Table-miss流表项性能
■5.5 流量统计测试
■5.6 OpenFlow定时器测试
■5.7 管道处理性能
6 开始OpenFlow的性能测试
1 摘要
测试一个交换机的过程就是验证它是否符合开放式网络基金会(ONF)的OpenFlow规范的过程,这点很容易理解,也已经被标准化了。在装备适当的实验室里有一套交换机,运行一套标准的一致性测试,并假定它已经通过ONF组织正式认可的OpenFlow协议。
OpenFlow的性能测试目前依然处于起步阶段,虽然有少数的开源工具用于测试OpenFlow性能,并且这些工具也开始出现在商用测试产品中,但是比较OpenFlow产品的性能还没有一个标准。然而构建SDN产品的网络供应商和部署的企业需要知道一个标准,不仅要达到OpenFlow规范,也要能按照期望来执行。本文阐述了OpenFlow的性能测试的重要性,并介绍了测试方法,企业可以用来做他们自身的OpenFlow性能测试。
2 为什么OpenFlow性能测试是必需的
OpenFlow是一个标准,ONF针对交换机提出了符合规范的严格要求,但并没有考虑到现实环境中的性能。OpenFlow控制器和交换机在性能方面会有许多差异,假如在部署中选择了错误的产品可能会造成灾难性的后果。唯一避免这种情况的可靠办法就是通过全面的性能测试。
3 本文参数
OpenFlow解决方案中包括一个或多个控制器、交换机,对终端用户来说,系统的整体性能是最重要的,这就需要系统制造商和集成商单独评估每个部件的性能来选择最佳的部件。
本文重点介绍以太网交换机的测试(以后篇幅中将继续讨论控制器和整个系统测试)。本文描述的例子将集中于硬件交换机,这比测试软件交换机性能更加复杂和有趣。不同于软件交换机在标准服务器上运行,硬件交换机使用加速吞吐量的集成电路ASIC。尽管如此,这里所描述的方法同样可以应用到软件交换机。
最后,虽然有多个版本的OpenFlow协议,本文将着重于OpenFlow1.3.0,因为它包含多表管道处理和组表,它是一种常用的版本,它提供了用于测试的核心概念,这个概念可以更新和应用在OpenFlow1.4.0及更高版本。
4 OpenFlow性能测试目标与挑战
OpenFlow的性能测试不同于传统交换机测试,它不完全集中在数据包转发性能。OpenFlow性能测试体现在交换机处理flow-mod消息的速度,以及通过OpenFlow管道的正交分组包的处理。(更多内容,尽在SDNLAB)flow-mod是一种短暂握手的OpenFlow消息,它由控制器发送到交换机来添加、修改、删除交换机转发表中的规则。一旦OpenFlow的“规则”被写入交换机的硬件转发表中,数据包以一定的线速进行转发,这个线速度可以用来检验交换机的性能。OpenFlow管道是指在OpenFlow 1.1.0引入的报文转发平面的多个流表。数据包现在可以处理多个匹配,并执行多种操作,如数据包的修改并转发到目标端口。
一个交换机的性能可能会因为部署方案的不同而不同。(更多内容,尽在SDNLAB)例如,控制器如何快速的添加新流到交换机的转发表是OpenFlow性能度量的关键。使用OpenFlow实现一个以太网交换节点可能每秒只需要一些OpenFlow新流,而想利用OpenFlow实现动态IP路由,可能需要每秒数百个新流。
因此,测量控制器每秒可以发送并安装到交换机转发表的flow-mod数量是很重要的。这条管线的瓶颈通常发生在交换机内部,交换机的CPU和存储该转发表中的专用集成电路ASIC之间。不同的交换机之间的性能测试结果可以相差很大,从每秒几条flow-mod到每秒几百条flow-mod,甚至在同一个交换机中固件升级前后的差距也是很大的。
5 OpenFlow性能测试注意事项
我们已经确定了六个测试指标来衡量以太网交换机的OpenFlow性能。他们是:
■表容量测试
■Flow-mod性能
■Packet in/out性能
■Table-miss流表项性能
■流量统计测试
■管道处理性能
对于每一个测试,用于测试的设备必须要能仿真OpenFlow控制器的行为,而且它也应该能连接到交换机数据平面上的端口。在这种方式中,测试设备可以向交换机发送数据包,以验证由模拟控制器下发的转发规则是否正确安装并实施。
5.1表容量测试
OpenFlow1.3.0被设计为采用TCAM实现一个或多个表的规则(流),TCAM是一种存储器,被几乎所有的交换机使用,它首先搜索内存中的内容而不是存储中的内容。不同的交换机具有不同的TCAM大小,TCAM的使用量由不同供应商的优化技术和插入的流规则决定。
为了避免混淆,当讨论OpenFlow表容量时,指的是“全部12元组匹配”,也就是OpenFlow规则相匹配的所有12个报头域。一些交换机厂商也支持掩盖表容量的优化法,如将只匹配二层报头字段的OpenFlow规则放到二层内存而不是TCAM。
从广义上讲,表容量测试需要验证流的安装、确定一个表何时用满,计算出全表中有多少流,并在每个表中重复测试该过程。
更具体地说,测试每一个以太网交换机OpenFlow表容量时,你需要考虑以下几点:
■对于不同的表容量的测试—一定要对不同匹配域进行满负载测试,如除了完整12元组匹配外的2层和3层匹配,以此检查是否有任何的优化。
■验证多个表的规模—确定交换机支持的表的数目(例如255),给每个表发送flow mod,然后在不同的匹配域中再次运行满负载测试。
■验证流是否已安装—提供以下3个验证选项增加准确性。
选项1:发送flow-mod消息并只需等待TCP确认,以确认该交换机接收到该消息。
选项2:在flow-mod消息后发送barrier request消息。如果交换机发送barrier replay,这意味着交换机已经完全处理此flow-mod消息。
选项3:发送flow-mod并增加数据平面的验证。这种方法能确认流安装的准确时间,也能验证在软件或硬件中流是否被转发。供应商使用软件转发来增加表的大小和容量,但是它可以显著影响数据包的吞吐量。使用测试方法,如用IETF RFC-2544验证数据包匹配每个流的转发性能。
■确定流表是否已满—在每个表安装流,直到交换机发出错误码(ofp_error_msg with OFPET_FLOW_MOD_FAILED, ALL_TABLES_FULL, or OVERLAP)指明表满的原因,一定要设置足够大的数据流的超时时间,以保证在测试过程中流不会超时并被交换机删除。
■统计成功安装流的数目—检查测试控制器的计数,并给交换机发送一个流状态请求(flow stats request),来验证每个表中安装了多少流。确认交换机和测试模块数量是否相同。
■确认流表已满之前决定每次插入流的数量—使用较小的步长可以提高准确性但花费的时间也长。最好的做法是在开始的时候使用大的步长找到表的大体容量范围,然后用小的步长,以确定更准确的计数。
OpenFlow的组表需要额外的特殊考虑。组表是和流表分开的,并单独存储在存储器中。其中流表倾向于测量匹配规则,每个组表对应一个“组标识符”。组表除了可以测量bucket中的单个action,还可以测量与单一“组标识符”相关联的“buckets”,或测量“组标识符”相关联的action列表。
组类型“indirect”将很多进来的数据包与一个单一的action进行匹配,例如一个默认的路由条目。对于这种组类型,可以用前面列出的几个注意事项进行组表规模测试。对于组类型“all”,它包含多种action集合,在流验证方法下选项3是首选的方法,该方法能够确认所有的action是否都按照给定的action集合被执行。在这种设定下,这种组类型会为集合中的每个action复制一个数据包,所以组表的规模和能采取的action数量直接相关,不仅仅是“group identifier”在流表中有匹配的流表项 。
本文来源于SDNLAB,可点击此阅读原文。如果您对本文感兴趣,可参与以下互动方式获得更多实时资讯。
(1) 微博(http://weibo.com/sdnlab/)
(2) 微信(账号:SDNLAB)
(3) QQ群
SDN研究群(214146842)
OpenDaylight研究群(194240432)