数据中心网络风险规避算法的设计

郑爱媛

(福建商学院 信息工程系，福建 福州，350012)

0 引言

互联网+时代，DCN作为云计算和存储的核心网络基础设施连接着大量服务器集群[1]。由于数据业务不可预见，构建DCN时将链路中数据流量的峰值作为网络带宽建设的目标。随着云技术、虚拟技术、物联网技术不断融合发展，海量宽带数据流量将以指数级呈现在DCN上，因此业界纷纷着手研究如何控制DCN风险以确保数据业务的QoS[2]。

就网络结构而言，采用多根树型胖树拓扑的传统网络中，由于存在核心层交换机无法应对突发网络重载的风险而无法推广。因此，采用多路由层次型胖树拓扑无疑是首选方案。该方案下的边缘层和汇聚层归属于不同的集群，两个层的交换机彼此相连，汇聚层仅和核心层部分交换节点互连，此举可使DCN平台上的服务器集群高效率地转发数据流量载荷。从控制层面来说，传统网络在实施控制功能前需事先在全网中部署路由算法，并将数据流转发模块和路由模块统一在一起；网络设备定义的接口不具开放性；数据流转发只对请求节点负责而缺乏对最优路由的计算选择。因此，实现高效控制无疑要将控制模块独立于转发模块，以便使控制器统一管理设备资源和网络资源，进而规避网络风险。基于上述分析，本文提出一种软件定义网络(SDN)架构下DCN风险规避的控制算法。

1 风险规避思想

SDN有别于传统网络架构，将控制模块和转发模块分离，如图1所示。其中Ryu控制单元根据网络实时状态为每个条数据流估算出最佳转发路由并下发至转发层中的OpenFlow交换机[3]，交换机更新流表后再转发该数据流。整个转发过程的实施为：首先，突发数据包载荷到访OpenFlow交换机，由于交换机既有的流表中并未包含与该突发数据包匹配的流表项，于是交换机向控制层中的Ryu控制器提交请求为该突发数据包估算出转发的路由；其次，Ryu控制器计算出该突发数据包的转发路由并响应给转发层中交换机；然后，交换机在其内存流表中添加该流表项；最后为该突发数据包载荷执行转发动作。显然，SDN架构可用于应对突发网络中突发数据流的匹配请求，同时采用层次型胖树拓扑结构的DCN所具备的多径路由特征也很适合SDN优势的发挥。

图1 SDN体系架构 Fig.1 SDN architecture

但是，受限于转发层中交换机寻址存储器有限的流表项储存空间[4]，以及控制层中Ryu控制器响应数据包转发路由计算请求的规模，往往存在新生突发数据流无法被顺利地分配到流表项的风险，使得新生突发数据流无法被顺利转发，最终导致阻塞率、丢包率、传输时延等与服务质量(QoS)相关的指标劣化。尤其在忙碌时段DCN重载情形下甚至可能引发全网瘫痪。基于此，本文从交换机存储空间流表优化的角度提出一种控制机制来规避突发数据包无法被分配到流表项的风险。该机制主要通过统计转发层中交换机存储空间内的流表闲置资源以及控制层中Ryu控制单元闲置的计算资源，然后根据突发数据流特性，计算出分配流表项过程中的闲置超时Tidle的最优值来删除无用的流表项，进而优化整张流表，提高突发数据流和流表项的匹配成功率，实现快速转发。同时通过计算并设置闲置超时Tidle的最优值，可充分地利用Ryu控制器的计算资源改善数据包转发路由计算请求的响应率。这样的控制机制不仅能优化整个DCN，也可充分地应对突发网络潜在的流表资源匮乏的风险。

2 风险规避原理

根据交换技术原理，突发载荷流量被划分成多个子集抵达交换机。当网络为该突发载荷流量分配足够带宽资源进行传输时，将该突发载荷流量子集记作DP{DP1,DP2,…DPn-1,DPn}，且服从帕累托分布，并定义帕累托分布参数τ、M、α[5]；当网络未能为该突发载荷流量授予足够带宽而等候交换机响应时，在这等候期间流表项暂时闲置，将闲置的时间间距子集记作Itn{It1,It2,…,Itn-1,Itn}，遵循负指数F分布。于是，在突发网络重载环境下上述两个子集遵循函数：

(2.1)

(2.2)

根据上述分析可知，在网络未能为该突发载荷流量授予足够带宽而等候交换机响应的情形下，如果流表项闲置的时间间隔长度Itn值超过了超时值Tidle，则交换机中的流表项将被剔除；相反，如果流表项闲置的时间间隔长度Itn值低于超时值Tidle，流表项则被保存下来。

(2.3)

显然，在闲置的时间间距子集Itn{It1,It2,...,Itn-1,Itn}内，当无效的等待时间U(It,Tidle)越长，闲置流表项规模越大，交换机中流表的匹配率也就越低，网络出现QoS异常的风险也就越高。为了描述无效等待时间对交换机流表生存性的影响力，对无效的等待时间做归一化表征[7]：

(2.4)

(2.5)

3 风险规避策略

风险规避目标旨在通过统计转发层中交换机的流表资源响应度、控制层中Ryu控制单元的计算资源响应度和突发数据流量载荷对转发层和控制层资源的依赖度[8]，分析出闲置超时Tidle的最优值，使突发数据流量载荷在短期内被顺利转发，排除因阻塞率、丢包率、传输时延等指标劣化而导致全网瘫痪的风险。

据此分析，将突发数据流量载荷对全网资源的依赖度Y(It,Tidle)描述为C·ar(It,Tidle)+S·u(It,Tidle)，可得闲置超时Tidle的最优值为：

Tidle=argmin[C·ar(It,Tidle)+S·u(It,Tidle)]

(2.6)

4 风险规避评估

4.1 评估模型

风险规避策略效能的评估在Mininet 2.2.1环境中开展。评估采用4元胖树的拓扑结构，含16个终端和20个OpenSwitch交换机。通过调用命令：$sudo mn --custom ～ /mininet/custom/fattree.py -topo=mytopo -switch=ovsk--mac --controller=remote, ip=Ryu控制器远程主机IP地址，port=6633，使Ryu控制单元和Mininet运行在两个主机上。借助于灌包软件Iperf协作生成突发数据流量载荷。载荷在区间[10Mb/s，106Mb/s]内呈现线性递增的趋势。每次突发数据流量生成时间间隔为5sec.，每个突发数据流量载荷长度为60 sec.。每个OpenSwitch交换机上的突发数据流量载荷规模不超过106条，并遵循0.05的负指数参数。

同时，OpenSwitch交换机提供2Gbit/s的带宽资源，其流表存储空间为2 000条，其中转发数据流的阈值缺省为70%。

目前，在基于SDN架构的DCN[10]上实施数据流转发请求的策略有动态链路均衡算法和多路由均衡算法。因此评估方案从突发数据流请求响应度、交换机流表使用率、全网吞吐量三个方面将风险规避策略与动态链路均衡算法、多路由均衡算法做出对比。

4.2 评估方案

(1)突发数据流请求响应度

由前文描述可知，当突发网络处于轻载时，控制层中Ryu控制单元计算资源较为充裕，完全可以响应OpenSwitch交换机上的突发数据流子集向上层提交的转发路由计算请求；反之，当突发网络处于重载时，随着Ryu控制单元计算资源耗尽，响应度势必减弱。这样的特征在如图2所示的三种算法策略仿真曲线图中均得到了体现。同时，由于三种算法策略对突发数据流采用不同的处理方式，使得各自产生突发数据流子集规模也不一致，向Ryu控制单元提交转发路由计算的请求机会也有所差异。相对于多路由均衡算法和动态链路均衡算法，本文提出的风险规避机制能够结合突发数据流特征优化Ryu控制单元计算资源，为相同规模的突发数据流量载荷子集提供更多的响应度。

图2 三种算法策略下突发数据流请求响应度Fig.2 Response of burst data stream requests under three algorithms

(2)交换机流表使用率

如图3所示，当突发网络中生成的突发数据流规模较小时，转发层中OpenSwitch交换机内的流表空间存放的流表项能够良好地满足数据流子集的适配请求。随着突发数据流规模线性递增，后续的突发数据流无法从有限的流表资源中得到匹配的机会，只能向上层控制单元提交请求等候控制器为其分配流表项，这样的情形显著降低了流表资源的使用率。较之传统算法，本文提出的风险规避机制通过一定的计算机制设定最优化的超时值，从而显著改善了OpenSwitch交换机内的流表资源使用率。

图3 三种策略下交换机流表使用率 Fig.3 Utilization of switch flow table under three policies

(3)全网吞吐量

理论上，网络吞吐量与突发数据流载荷流量呈正比。然而受限于设备和网络性能，实际吞吐量并不总是呈现递增趋势，而是在达到一定峰值后有所减缓。图4所示的本组实验结果总体上也符合这样的规律。图中不难看出，随着负载增至10 000，动态链路均衡算法首先达到了峰值。数据流量进一步增加，阻塞也变得愈加严重，使得整体吞吐量下降。相对于多路由均衡算法，本文提出的风险规避机制能够结合突发数据流量载荷实时特征，统计其对全网资源的依赖度来高效管理OpenSwitch交换机内的流表项和Ryu控制单元计算资源，从而使得在相同网络环境参数下，表现出了吞吐量优越性。

图4 三种策略下全网吞吐量Fig.4 Network throughput under three policies

5 结论

DCN在传统的算法机制下存在丢包、拥塞等QoS异常现象。本文借助SDN架构优势，将其部署在DCN中并提出一种风险规避算法，该算法结合突发数据流特征，通过计算OpenFlow交换机资源和Ryu控制器资源来求解超时优化值，以便顺利转发突发数据流从而达到化解网络阻塞和丢包的风险。该风险规避算法借助Floodlight和Mininet环境展开模拟评估，实验表明，相对于动态均衡算法和多路由均衡算法，该机制在突发数据流请求响应度、交换机流表使用率、网络吞吐量等方面具有良好的优势。