一种面向云数据中心的多租户策略驱动型软件定义网络方法

摘要

本发明属于云计算和新型网络技术领域，具体为一种面向云数据中心的多租户策略驱动型软件定义网络方法。具体步骤包括：租户策略定义，限定用户自定义策略的权限，策略冲突解决，策略文件解析与执行；本发明通过策略定义来配置网络，租户能够以直观的方式来定义自己的虚拟网络、虚拟防火墙等，而不必通过编写程序或者利用软件定义网络控制器所提供的编程接口；将云计算平台的管理和SDN控制器的管理统一起来；通过策略的解析来管理网络，能够获得更好的效率，节省软件定义网络控制器的CPU等计算资源，并减少控制器处理租户请求的时间。本发明在保证用户友好性的前提下，能够接近本地API调用的性能，同时大大优于RESTAPI调用的性能。

说明书

技术领域

本发明属于云计算和数据中心网络技术领域，具体涉及一种面向云数据中心的多租户策略驱动型软件定义网络方法。 

背景技术

在当前将软件定义网络运用于云数据中心管理的研究中存在若干问题，主要是管理员管理逻辑复杂、不易实现，SDN控制器效率不高，租户不能定义自己的网络策略等。而参考亚马逊等一些公有云平台，大多都是通过租户自定义策略的方式来管理云计算中租户的各项资源。所以，本发明设计的出发点在于云数据中心对于网络的管理同样可以使用策略驱动的方式，并且，将原有的策略进行扩展后，很容易对不同类型的策略进行统一的整合，并进行统一的解析与执行。这样，就简化了云数据中心平台的管理，将所有的策略平台统一为一个策略解析平台，将原来的SDN控制器与云控制器进行有效的整合，使得整个云数据中心平台只有一个统一的管理器，以达到统一管理、方便使用的目的。 

在当前的SDN管理中，可以通过两种方式来管理网络，即通过本地API调用的方式和通过REST API调用的方式。但是，这两种方式均存在一定的问题。通过本地API调用的方式，其扩展性不强，且要求专业性较强，需要管理员通过编写程序的方式来管理网络，这就使得普通的租户不能参与自定义的网络管理；而基于REST API的方式，虽然用户友好性有一定的提高，但是仍然达不到使得租户能够自定义策略的程度，同时，通过REST API调用时，客户端会将同一种类型的OpenFlow指令仍然拆分为多个HTTP请求来发送，这样就限制了其处理能力，同时造成了很大的处理延时。 

所以，我们的设计提出基于多租户的策略驱动型软件定义网络解决方法，通过对已有的存储、计算策略等进行扩展，定义出了网络管理策略。基于Floodlight控制器，将网络管理策略与原有策略的整合，达到了策略统一定义、统一解析、统一执行的目的。并且，支持租户可以自定义策略，并不需要每个管理请求都发送给管理员，再由管理员进行操作，这样就创造了更大的灵活性。同时，因为SDN相关的策略与原有策略可以整合到同一个策略文件中，这样就将SDN的管理与原有云数据中心平台的管理整合了起来，形成了一个统一管理平台，这样也能大大降低管理复杂性。 

因此，本发明侧重于面向云数据中心的多租户策略驱动型软件定义网络方法。 

经对现有技术的文献检索发现，在SDN概念提出之后不久，NOX项目刚刚提出之时，Tavakoli等提出要将NOX应用于数据中心[Tavakoli A,Casado M,Koponen T,et al.Applying NOX to the Datacenter[C]HotNets.2009.]。Tavakoli在该文献中指出数据中心的网络面临的主要需求有以下几点：可扩展性；资源位置独立性；高服务质量；中间件支持；监控与排错的支持。传统的数据中心网络架构不能很好地同时支持这些特性，而将NOX稍加扩展即可将其很好地应用于数据中心网络，并且能很好地支持以上所述的各类特性。Banikazemi等在文献中[Banikazemi M,Olshefski D,Shaikh A,et al.Meridian:an sdn platform for cloud network services[J].Communications Magazine,IEEE,2013,51(2):120-127.]中提出的Meridian则强调SDN在云计算整合过程中的服务功能。在云计算应用过程中，虚拟子网、多租户隔离、路由路径优化等各种需求被提了出来，而将SDN直接应用于云计算环境时却没有一个很好的协调机制来协调SDN控制器和云控制器。Meridian是这样一种模型，它对外隐藏内部实现，仅提供针对云计算平台的API，用于云计算管理器进行相应的操作，例如路径优化、访问控制策略设定等。但是，Meridian提供的API与云计算管理器之间是紧耦合的关系，不够灵活。 

云计算环境的一大特点是多租户，而各租户均希望自己的子网与其他租户的子网之间能有效地隔离，于是也有一些研究文轩专注于利用SDN来构建云计算环境中的虚拟网络[Azodolmolky S,Wieder P,Yahyapour R.SDN-based cloud computing networking[C]Transparent Optical Networks(ICTON),201315th International Conference on.IEEE,2013:1-4。 

Malik M S,Montanari M,Huh J H,et al.Towards SDN enabled network control delegation in clouds[C]Dependable Systems and Networks(DSN),201343rd Annual IEEE/IFIP International Conference on.IEEE,2013:1-6；Bakshi K.Considerations for Software Defined Networking(SDN):Approaches and use cases[C]Aerospace Conference,2013IEEE.IEEE,2013:1-9.]综合这些论文，其基本论点都是通过SDN来管理物理网络，利用SDN灵活、方便管理的特点，调用SDN控制器的API，在SDN之上来构建虚拟网络。利用SDN来构建虚拟网络有多方面的优点，首先，云管理员可方便地进行子网的划分：云管理员只需要定义好虚拟网络各子网、网关等信息，再将这些配置信息通过SDN控制器下发到OpenFlow交换机建立相应的流表即可，这正是SDN中“软件定义”的优势。而在传统网络环境中，则需要云管理员直接对各个路由器和交换机进行配置，而通过SDN，云管理员同样可通过“软件定义”的方式来设置各虚拟子网的安全策略，因为 SDN控制器掌握了全网络的所有信息，所以可用来方便地进行安全策略规则的验证工作，并且可以很容易地将规则在底层的交换机、路由机和防火墙等中间件上建立起来。但是目前的问题是SDN控制器提供的API接口还没有统一的标准，因此上层网络管理软件需要与多个SDN控制器的API进行交互，这带来了集成的难度。 

发明内容

本发明的目的在于提出一种操作灵活性大、管理复杂性低的面向云数据中心的多租户策略驱动型软件定义网络方法。 

本发明的提出的面向云数据中心的多租户策略驱动型软件定义网络方法。具体步骤为： 

第一步:租户策略自定义 

通过自定义的租户策略，SDN控制器和云管理器不需要从不同的数据库中读取租户相关的管理数据，而只需要通过统一的接口解析租户的策略即可，这样即达到了整合SDN控制器和云管理器的目的。通过租户自定义策略，自然地满足租户自定义、个性化策略的需求，并且能够将虚拟机放置策略、存储策略、网络策略等整合到同一个策略文件中进行定义，方便了租户的统一管理。 

为了在策略解析时获得更大的自由度，本发明在定义策略时通过“继承”对原有Amazon的AWS声明进行了扩展，发展出了SIStatement(SDN Integrated Statement，集成了SDN的声明)，声明中各个部分的继承关系如图1所示。 

其中，新定义的SIStatement对于原有声明是一种继承关系，其中的子项“Condition”和“Effect”可以沿用与原有声明相同的定义，所以没有进行扩展。扩展的子项为“SIPrincipal”、“SIAction”、“SIResource”三项，下面分别叙述对这三项的定义。 

SIPrincipal:对于原有Principal的扩展，其基本形式为： 

“SIPricipal”:{“SDN”:”TenantUserXXX”}, 

其中的“SDN”关键字表明这项声明是一项与SDN有关的操作，以示与原有声明中存储等相关操作的区分，其后的租户账户名可沿用原有账户定义，以实现与原有策略的统一。 

SIAction:对于原有可操作类型的扩展，代表与网络管理相关的可进行的操作，例如：创建虚拟网络时，定义为： 

“SIAction”:”CreateVirtualNetwork”, 

创建虚拟防火墙访问控制列表ACL时，定义为： 

“SIAction”:”CreateFireWallACL” 

通过此方式进行定义，”SIAction”项可以进行任意的扩展，比如如果需要进行QoS控制时，只需要在此处定义相应的操作项，并在后续的策略解析模块进行解析即可，这样就增加了系统的可扩展性。 

SIResource：扩展了原声明中的“资源项”，此处资源项的值与”SIAction”操作项的值相关，需要根据操作项进行相应的修改。举例说明如下，当“SIAction”为创建虚拟网络时，其后续的资源项例如： 

即在资源项中定义了当创建虚拟网络时，与虚拟网络相关的各项细节。其中包括虚拟网络的唯一标识符guid，虚拟网络的名字，虚拟网络的网关和虚拟网络中所包含的虚拟机的MAC地址。 

同时，SIResource项可以包含多个分段，也就是说，可以包含同一租户下的多个虚拟子网的定义。这样，在同一个策略声明中，就可以同时创建多个虚拟子网，而不用分别创建策略文件，这样方便了租户进行管理。 

另一个典型例子是，当“SIAction”为创建虚拟防火墙访问控制列表ACL时，其后续的资源项例如： 

可以看出，此时SIResource中包含的资源说明是防火墙ACL规则，上述示例中的第一项规则为允许两台主机之间的TCP80端口的访问，第二项规则为拒绝ICMP协议的所有访问。 

通过在SIResource资源项中定义防火墙ACL规则，就实现了用户自定义的访问控制策略。 

同样，在SIResource中定义的ACL规则项目也是可以无限扩展的，租户只需要添加更多的ACL规则项即可，这些规则可在后续的策略解析模块中进行解析，并通过多线程方式进行实现，以达到提升效率的目的。 

通过以上方式进行继承和扩展，就构成了与SDN相关的完整的策略定义。 

第二步:限定用户自定义策略的权限 

当策略被定义以后，一个很自然的问题是，如何限制用户自定义策略的权限，并且保证管理员拥有对网络的最终管理权。 

在OpenFlow协议白皮书中指出，在流表中建立的每一个流表项均包含一个“优先级(Priority)”值，优先级的取值范围为0～255，其中，数字越大，表示优先级越高。基于此，同样可以对各租户策略赋予不同的优先级，同时预设一些管理员策略，并保证管理员策略的优先级总是大于租户策略优先级，这样就限制了租户策略的权限和使用范围。 

基于两段式优先级的定义与处理，并结合OpenFlow协议中优先级的取值范围，可定义管理员策略的优先级取值为[128,255]，定义租户策略的优先级取值范围为(0,127]，这样，即使租户的策略有任何越过权限的恶意行为，因为其优先级总是比管理员策略的优先级低，所以在OpenFlow流表中不会被匹配到，也就不会执行，所以不会对整个网络产生 损害。 

本发明中，除了租户能定义相应的策略，管理员同样能定义一些管理策略。对管理员策略的描述与租户策略不同，管理员策略侧重于原子操作(Atom Action)定义和默认策略描述。原子操作是指是网络管理中的一些最基本的、不可被分割的操作，例如允许连接、创建路由表项、链路带宽设定、禁止某一端口通信等。而租户策略是按应用场景来定义，例如租户“创建虚拟子网”这一策略可分割成多个允许建立连接(虚拟子网的虚拟机之间)、设置路由表项等多个原子操作。原子操作之间按实际操作顺序和管理优先级指定优先级的值，例如当“创建虚拟子网”时，“允许连接”的优先级应该于“设置路由表项”，因为如果不允许连接，也就没有必要再设置或查询路由表项了。在“创建虚拟子网”完成后，如果租户同时叠加了访问控制列表策略，比如禁止80端口访问，则可以设置一个优先级比“设置路由表项”更低的“禁止端口访问”项，这样，虚拟机之间除了80端口以外，都能进行正常的通信。通过这种方式，管理员可以按需定制所有的原子操作类型及其优先级。 

租户策略的优先级分为基本优先级加偏移量(shift)两部分。基本优先级是根据应用场景预先设定的固定值，例如“创建虚拟子网”一般先于“创建访问控制列表”执行，所以可以设定“创建虚拟子网”的固定优先级比“创建访问控制列表”高。 

当租户策略被解析时，其策略文件被分解成为原子操作来执行，实际最终优先级值为固定优先级值加上偏移量。偏移量定义为管理员原子操作优先级与基本值之差，因为管理员策略的优先级取值范围是[128,255]，所以基本值固定为128。这样产生的问题是，租户策略固定优先级值加上偏移量后，值可能大于128，超出了(0,127]这一取值范围。解决方法是，将租户策略固定优先级和管理员策略优先级同时再限定在一个更小范围，例如固定优先级取值(0,32]，原子策略优先级取值[128,223]，这样就可以保证租户固定策略优先级加上偏移量后不大于128。将这一限定值命名为limit，则策略优先级定义表如下所示： 

表1策略优先级详细定义及取值范围 

定义原子操作为A，其优先级为P[A]，固定优先级类型为a，固定优先级值为p[a]，则处理租户策略时赋予每一操作实际优先级(Priority)的算法如下表所示： 

表2处理租户策略实际优先级算法 

如表2所示，首先计算原子操作偏移量，再在处理租户策略的过程中，首先判断其固定优先级，通过固定优先级加上偏移量，产生租户策略中每一项原子操作的最终优先级，这一优先级的值能确保属于(0,127]，这个值必定比管理员所定义的策略的优先级值小。 

从策略定义和算法1可以看出，租户策略的优先级不通过租户来定义，而是通过策略的解析来自动完成。这样，即使租户在策略中定义了一些危险的操作，也能通过优先级定义使其操作的优先级低于管理员策略，而管理员可以通过定义优先级较高的安全策略来使用租户策略不被执行，这样，就确保了租户策略只能在一定范围内被执行，也就限定了租户权限。 

第三步:策略冲突解决方法 

因为租户自定义策略中的"SIResource"项是针对租户自己的资源来定义，所以不同租户之间的资源没有交叉，不同租户之间的策略在大多数情况下都不会发生冲突。但是租户 策略仍然在某些情况下发生冲突，例如当租户需要保留某条链路的带宽时，假设三个租户A、B、C分别需要保留50Mbit/s带宽，而真实物理链路带宽只有100Mbit/s，这时就不能满足所有租户的需求，此时策略不能被正确执行的情况就可以看作是租户策略之间发生了冲突。 

当租户之间策略发生冲突时，需要用管理员默认策略进行处理。在表1定义的策略优先级范围中，(255-limit,255]被定义为管理员默认策略的优先级取值范围，即管理员通过最高的优先级来定义一些默认策略，以便能解决所有可能出现的冲突。因为管理员默认策略的优先级最高，所以能保证被执行。系统处理租户策略冲突的算法如下： 

表3处理租户策略冲突算法 

根据OpenFlow的技术白皮书，每一项OpenFlow流表的优先级取值范围为0～255，所以当某个OpenFlow交换机中流表项目数超过255时，必然有至少两个流表项的优先级取值范围相同。当前OpenFlow协议对优先级相同的处理规则是：遍历OpenFlow流表，当遇到优先级匹配时即应用该项，而不再进行后续的遍历。而这种处理方式是最简单的，它以流表项目插入流表的顺序为基准进行遍历查找，这种插入与查找对于流表项的出现顺序来说几乎是随机的。所以，表3所示的算法在此基础上增加了一层处理：当检测到策略冲突 后，首先判断这个冲突是否是被管理员预定义策略所解决的，例如，当租户所申请的保留带宽超过物理链路带宽时，管理员可定义将所有租户的实际带宽按申请带宽的比例分配，这样就解决了某一个冲突问题，这一冲突问题的解决方法在算法中定义为Unit-Function()函数方法，定义不同的Unit-Function()方法即可解决不同的策略冲突问题；而当有一些冲突没有办法被管理员策略所解决时，则直接应用管理员所定义的全局默认策略，即策略优先级的值范围在(255-limit,255]之间的策略。这种策略以安全性最大化为原则，因为其优先级值最大，所以在OpenFlow流表中会最先被匹配到，需要尽量保持其影响范围最小：比如默认策略为当有80端口访问策略冲突时禁止所有80端口的通信，这几乎将禁止掉所有租户之间80端口的访问权，但是也保证了管理员对网络的完全控制，避免租户策略的冲突导致不可预测的情况发生。最后，如果管理员也未定义相应的最终管理策略，则赋予某一项操作的优先级为0，在OpenFlow流表中优先级为0表示流表中最后被匹配的项，它能保证整体策略对网络的影响最低。 

通过表3中算法的处理，提供了比默认OpenFlow流表中对优先级冲突时默认动作的一种更好的解决方案，解决了当租户自定义策略发生冲突时OpenFlow流表发生优先级混淆的问题。 

第四步:策略文件解析与执行 

本发明重点设计了一个策略模块，策略模块负责策略文件读取、策略文件解析、策略文件执行等子模块。策略文件被解析后，最终还是调用本地Java API在物理网络上执行相应的操作。 

策略模块中维护着一个策略文件系统，策略文件系统可以从云管理器中直接读取策略，也可以接受租户直接向策略文件系统中写入策略。策略模块的工作流程是，由策略文件维护系统维护着整个策略文件系统，同时有策略文件监控模块对策略文件的变化进行监控。当监控到文件系统变化时，即意味着有相关操作需要执行。此时，策略文件解析模块读取发生变化的策略文件，对策略文件进行解析，将解析后的相关参数传到策略文件执行模块，由策略文件执行模块进行最终的执行。 

在当前我们设计方法的原型实现系统中，已经实现了“创建虚拟子网”和“创建虚拟防火墙ACL”这两种典型应用场景，当然，也可以添加更多的应用场景，只需在策略文件解析子模块中添加更多相应的执行器即可。对于相关模块的详细说明，在后续章节中进行。 

(1)系统总体处理流程 

整个策略模块开始执行时，系统总体处理流程如图2所示。 

对系统处理流程的详细描述如表4所示。 

表4系统处理流程算法描述 

如图2和表4所示，首先，由策略文件监控系统循环监控文件变化情况，当策略文件未发生变化时，继续循环监控；当策略文件发生变化时，则通知策略文件解析与执行(调用Executor接口)模块，并调用策略文件解析模块进行解析与执行。在策略文件解析模块中，判断操作类型，并执行相应的操作。策略解析模块的解析与执行操作完成后，返回监控流程，并进行下一次的监控循环。 

(2)策略文件解析与执行 

对策略文件的解析如图3所示。 

对策略文件解析与执行的详细描述如表5所示： 

表5策略文件解析模块算法 

策略文件解析子模块开始工作时，首先读取发生变化的策略文件，再对其进行初步解析，将其中与SDN相关的操作提取出来，交由后续流程进行执行，再将其它原有AWS系统的操作(例如创建文件等存储相关的操作)交由原有的云管理器进行执行。这样便实现了SDN控制器与云管理器的策略的统一管理与解析，但是执行时是在相对独立的线程中进行。 

在策略解析子模块提取出SDN操作后，再判断相关的操作，操作类型可以是“创建虚拟子网”或“创建虚拟防火墙ACL”，也可以是其它新增的自定义的操作类型。对于每一种操作，在线程池中开启一个新的线程来执行。在线程池中，有一个任务统一执行器对所有线程进行管理，任务统一执行器中定义了一个统一的任务执行接口，不管是“创建虚拟子网”，还是“创建虚拟防火墙ACL”，均实现了这个接口。每个操作子模块通过实现任务统一执行器的执行接口来实现系统的良好扩展性。通过此种方式，任务统一执行器只需调用接口方法即可实现任务的统一管理与执行，并在运行时决定实现调用的方法，这样便实现了接口的统一管理，并实现了系统的可扩展性。 

最后，各实际任务执行器再调用本地Java API，实现相关任务的最终执行。这样，便实现了整个发明的系统功能，通过定义策略文件，并监控策略文件的变化，调用相关的操作子模块进行操作，并最终调用本地API在实际的物理网络上进行相应的管理工作，以实现通过SDN控制器来管理网络的目的。 

本发明通过策略定义来配置网络，能够获得多方面的好处。首先，租户能够通过策略以直观的方式来定义自己的虚拟网络、虚拟防火墙等，而不必通过编写程序或者利用软件定义网络控制器所提供的编程接口。其次，软件定义网络中的策略能够与类似亚马逊AWS等云计算平台中的用户访问策略、对象存储策略等策略进行有机的整合，这样通过定义统一的策略，就可以将云计算平台的管理和SDN控制器的管理统一起来，方便云计算管理员进行管理。最后，通过策略的解析而不是通过调用网络服务器编程接口(本地API或REST API)来管理网络，能够获得更好的效率，它能够在一定程度上节省软件定义网络控制器的CPU等计算资源，并显著地减少控制器处理租户请求的时间。 

本发明通过实验验证了多租户策略驱动型软件定义网络方法的有效性，并且在创建虚拟子网和增加每租户子网数量这两种典型应用场景下，对比了策略驱动型、本地API调用、REST API调用这三种情形下的SDN控制器性能，证明了策略驱动型软件定义网络方法在保证用户友好性的前提下，能够接近本地API调用的性能，同时大大优于REST API调用的性能。 

附图说明

图1为SIStatement对于原有声明的继承关系。 

图2为策略模块系统执行流程图。 

图3为策略文件解析子模块工作流程图。 

图4为测试创建虚拟子网功能的有效性。 

图5为测试禁止端口通信的有效性。 

图6为测试禁止某一协议通信的有效性。 

图7为创建虚拟网络-增加子网内主机数量时的系统处理时间。 

图8为创建虚拟网络-增加子网内主机数量时的系统负载增加量。 

图9为增加每租户子网数量时的系统处理时间。 

图10为创建虚拟网络-增加每租户子网数量时的系统负载增加量。 

图11面向云数据中心的多租户策略驱动型软件定义网络方法总体框图。 

具体实施方式

(1)实验方式 

针对面向云数据中心的多租户策略驱动型软件定义网络方法Policy-driven Software Defined Networking Method-PDSDN的实验验证分为功能验证和性能验证两部分，功能验证通过一些典型应用场景测试PDSDN系统的有效性，性能验证测试在多租户并发操作环境下PDSDN系统的性能。 

(2)功能验证 

功能验证实验通过Openstack云平台进行。在Openstack的neutron网络管理模块中，可通过插件支持外部的SDN控制器。在当前Openstack Havana版本的实现中，已支持的SDN控制器有Floodlight、Ryu等。因为PDSDN系统基于Floodlight开发，所以也能被Openstack Floodlight插件识别，能够很好地与Openstack平台结合起来。 

实验所采用的Openstack版本为Havana版，部署于三个节点之上，每个节点的服务器硬件配置为：型号：DELL PowerEdge R720,CPU：Intel-Xeon E5-2650,内存：32GB。每一台服务器的操作系统均为Ubuntu12.04LTS64bit版。 

三台服务器的角色分配为，第一台用作云控制器(Cloud Controller)和一些Openstack核心服务；第二台作neutron网络管理节点和计算节点；第三台专用作计算节点。这样的角色分离能方便在实验过程中很好监测网络流量，受篇幅所限，实验部分不能穷举出所有的应用场景进行验证，下面通过三个典型应用场景验证PDSDN方法的有效性。 

(2.1)创建虚拟子网 

在Openstack中创建两个租户Tenant1和Tenant2，每个租户分别创建两个虚拟机，分别为vm1、vm2和vm3、vm4，如下表所示。 

租户 虚拟机 Tenant1 vm1、vm2 Tenant2 vm3、vm4

表6功能验证实验中租户虚拟机列表 

当未设定任何虚拟子网时，4个虚拟机之间互相都能通信，如图4所示，实验中通过iperf工具测量“vm1-vm2”、“vm3-vm4”、“vm1-vm3”这三对虚拟机之间的UDP传输的最大速率。物理交换机的传输速率为100Mbit/s，设定虚拟交换机的最大速率与物理交换机相同，均为100Mbit/s。 

实验开始时，3对虚拟机之间都能通信，在实验开始大约20秒后，创建租户策略文件，租户1将其2个虚拟机放在其虚拟子网中，租户2也将其2个虚拟机放在其虚拟子网 中，此时可以看出，租户1的vm1和租户3的vm3之间因为不属于同一子网，所以不能进行通信，此时它们之间的数据传输速率为0。而“vm1-vm2”和“vm3-vm4”之间则分享了带宽，在45秒时，删除租户策略文件，即删除租户的虚拟子网，此时“vm1-vm3”又能进行正常的通信，三对虚拟机之间分享带宽。这个实验证明了“租户创建虚拟子网”的有效性。 

(2.2)禁止特定端口的通信 

在“创建虚拟防火墙ACL”场景中，可定义的其中一项策略是禁止某一端口的通信。如图5所示，测试场景为租户1的vm1和vm2之间的通信，同样用iperf工具进行测量，测试UDP传输带宽，在两台虚拟机之间通过5001和5002两个端口分别建立两个UDP数据流。在实验开始时，两个独立的UDP数据流分享带宽，然后创建租户1的“创建虚拟防火墙ACL”策略，在策略中定义禁止5002端口的访问。于是从实验中看到，基于5002端口的UDP数据传输速率降为0，而基于5001端口的UDP流则独享了带宽。之后，再删除租户1的策略，则两个UDP流重新分享带宽。从本实验可以证明“禁止某一端口通信”的有效性。 

(2.3)禁止特定协议的通信 

在“创建虚拟防火墙ACL”场景中，另一项可定义的策略项为禁止基于某一协议(TCP、UDP、ICMP等)的通信。如图6所示，测试场景为租户1的vm1和vm2之间的通信，同样用iperf工具进行测量，同时建立一个TCP流和一个UDP流。从图6可以看出，因为UDP中没有速率限制，所以UDP流的传输速率会大大高于TCP流的传输速率。大约从20秒开始，创建租户1的“创建虚拟防火墙ACL”策略，在策略中定义禁止所有UDP协议的通信，则可以看出，UDP流的数据传输速率降为0，而TCP流则独享的带宽。之后，删除租户1的策略，可以看出，UDP流重新能够进行数据传输，并且传输速率恢复到接近于策略定义之前的水平。这个实验证明了“禁止基于某一协议的通信”的有效性。 

(3)性能验证 

PDSDN方法是对Floodlight的扩展，所以它本质上也是一个SDN控制器。采用运行SDN控制器的常用方式，将其运行于一台物理机上，这样能保证SDN控制器的性能。物理机的配置信息为：CPU:Intel Core i7,内存：8GB DDR3，操作系统：Ubuntu 12.04 64位。 

对于模拟云计算环境中大规模的虚拟交换机和虚拟主机，实验通过Mininet[50]来进行仿真。Mininet是基于Linux内核的轻量级网络模拟器，它能够在一台Linux物理机中 模拟出上千个虚拟交换机以及和虚拟交换机相连的虚拟主机，以模拟真实云环境中的虚拟机和虚拟主机，用以进行系统负载测试。在本文中选用的用来搭建Mininet环境的主机为一台物理主机，物理主机的配置信息为：CPU:Intel Xeon E5-2650,内存：32GB，操作系统：Ubuntu 12.04 64位。 

在PDSDN方法实现中，已经实现了两种最广泛应用的子模块：“创建虚拟子网”和“创建虚拟防火墙访问控制列表ACL”。为了测试PDSDN系统的性能，测试针对以上两个模块进行。在两个模块的运行过程中，均有一些变量的变化可能引起系统性能和负载的变化，以下对这两个模块分别进行实验。 

实验中测量的参数有两种：系统处理时间或系统负载变化的增加量。系统处理时间是指操作开始之时到相关操作完全完成的时间，其中，基于本地API调用的系统处理时间即是指编写完应用程序之后，在SDN控制器中运行此程序所需的时间。PDSDN系统的系统处理时间是指，租户在客户端定义好自定义策略，将策略通过HTTP请求发送到PDSDN，再由PDSDN系统进行处理的时间。基于REST API调用的系统处理时间是指租户在客户端调用REST API，通过发送HTTP请求，再由SDN控制器对所有请求进行处理的时间。 

系统负载变化的增加量通过测量CPU处理时间的增长率来表征。CPU处理时间增长率的计算方式如下： 

如公式1所示，系统开始稳定运行后，不进行任何(“创建虚拟子网”等)操作，只是将SDN控制器或SDN控制器启动，此时测量一段时间的控制器进程占用的CPU处理时间，求出单位时间内的平均值，此CPU占用时间定义为“操作开始前CPU占用时间”。在某一项操作开始后，例如开始创建虚拟子网后，再测量一段时间的控制器进程占用的CPU处理时间，求出单位时间内的平均值，此CPU占用时间定义为“操作开始后CPU占用时间”。将这两个时间按公式5-1所示进行计算，就得出了CPU处理时间的增长率。从以上计算过程可以看出，“CPU处理时间增长率”这个结果只具有相对的含义，而不具有绝对值方面的意义，它反映了当进行某一项网络管理操作(例如“创建虚拟子网”)时，由于PDSDN系统需要进行策略解析与执行、或SDN控制器需要对用户请求进行处理而造成的CPU处理时间的增长，也就反映了系统在执行某项操作时相对于系统平稳运行时CPU负载的增加量。 

(3.1)性能验证：创建虚拟子网 

在创建虚拟子网时，对于整个云计算平台来说，有3种变量：总租户数量、每租户的子网数量和每子网中的虚拟机数量。对这三种变量来说，可能同时发生变化。为了实验的定性研究，在以下三个实验中，分别固定两个变量，使另一个变量发生变化进行测试。 

测试的指标有两种，分别是系统处理时间和系统负载变化量，其定义如上文所述。 

测试对象为三种方式的调用，分别为：基于本地API的调用，基于策略的PDSDN系统调用，基于REST API的调用。 

设定同时进行并发操作的租户数量为10个，每个租户有5个子网需要建立或更新，设置子网内的主机数量为10～100个，测定同时进行并发操作的系统处理时间，如图7所示。 

同时，测定系统负载的增加量(由于PDSDN系统与调用本地API时造成的系统负载增加量基本一致，图8中仅显示PDSDN系统与调用REST API时的对比)。 

从图7系统处理时间可以看出，当子网内主机数量增加时，PDSDN的延时比调用本地API略大，但是同时也大大小于调用REST API时的系统处理时间。并且，当子网内主机数量增长时，系统处理时间并没有同时线性增长。 

从图8系统负载增加量可以看出，PDSDN系统造成的系统负载增加仅为40％至60％左右，而调用REST API时造成的系统负载增加量大约在120％至180％之间，说明PDSDN系统的处理性能较REST API调用更好，能够节省SDN控制器的CPU资源。 

(3.2)性能验证：增加每租户子网数量 

另一种实验环境设定是假设租户数量不变，而每租户的子网数量增加，同时每个子网中的虚拟机个数保持不变。这一环境设定测试每租户的子网数量增加时，系统的处理延时和系统负载的变化量。 

如图9所示，增加每租户子网数量时，调用本地API、PDSDN系统、调用REST API三种情况下的系统处理时间均随着子网数量的增加而近似线性增加。同时，PDSDN的延时比调用本地API大，但是同时也小于调用REST API时的系统处理时间。 

将此图与图7对比，可以看出，增加子网内主机数量时，调用本地API时的处理时间接近于常数，并没有明显的变化。而增加每租户的子网数量时，调用本地API时的处理时间随子网数量而近似线性增加，说明每租户的子网数量是限制系统处理时间的一个瓶颈。 

图10显示创建虚拟网络-增加每租户子网数量时的系统负载增加量。从图10可以看出，当每租户内子网数量增加时，PDSDN系统的负载增加量也少于采用REST API时的情况。将图8和图10进行比较，可以看出在增加每租户子网数量时，PDSDN系统和基于REST API的系统在负载的增加量上，均大于增加子网内主机数量的情况。进一步说明，增加每租户子网数量时，系统负载的增加量较大，每租户的子网数量可能成为系统处理的一个瓶颈。 

附表说明： 

表1策略优先级详细定义及取值范围。 

表2处理租户策略实际优先级算法。 

表3处理租户策略冲突算法。 

表4系统处理流程算法描述。 

表5策略文件解析模块算法。 

表6功能验证实验中租户虚拟机列表。