一种用于DCN中的自适应请求分批调度方法

摘要

本发明公开了一种用于DCN中的自适应请求分批调度方法，在汇聚服务器发送请求时，依据网络拥塞状态动态调整下一批发送请求的个数，使得并发连接数控制在交换机缓存能够容纳的程度内。本发明可以让数据中心应用更加合理地使用网络可用带宽，避免发送方TCP连接频繁超时，从而提升应用性能。

说明书

技术领域

本发明涉及一种用于DCN(数据中心网络，Data CenterNetwork)中的自适应请求分批调度方法。 

背景技术

近年来，数据中心己成为当前政府、企业和单位信息化建设的核心组成部分，用于提供各类分布式应用、计算和存储等服务。通过建立数据中心，一方面这些组织可以对各种计算资源进行动态分配，另一方面利用大型的数据中心可以获得规模经济效应。因此，越来越多的应用与服务被迁移到数据中心中，利用数据中心强大的计算和存储能力来提供大并发的数据服务。而这些数据服务都依赖于数据中心网络(Data CenterNetworks，DCN)提供支持。数据中心网络是连接数据中心服务器和存储设备的信息交换网络，承担着数据中心海量数据的传输和交换的重要任务。 

数据中心网络虽然具有超高带宽、超低延时的特性，但仍使用传统TCP进行传输控制。由于传统TCP主要适用于广域网络，而广域网在带宽和延时上与数据中心网络有着很大的差异，如果继续沿用传统TCP，那么不仅无法最大限度的发挥数据中心网络的通信能力，还会带来很多无法预知的问题。 

在数据中心的典型服务应用，如大规模瞬时的数据密集查询、文件系统读写、MapReduce等网络流量较大、或者高并发的同步并发流，极易造成某些路径瞬时成为瓶颈，网络将不可避免地发生拥塞，引起数据丢包，最终导致TCP超时。这种情况下，拥塞发生的突发性、传统TCP协议的超时时间(默认最小200ms)与数据中心往返传输延时(90％小于1ms)的不匹配等因素，导致拥塞时网络吞吐率急剧下降，出现TCP Incast问题。而且这种拥塞持续时间相对短暂，网络流量以及拥塞节点分布都难以预侧和确定。 

针对数据中心网络的TCP Incast问题，很多文献都提出了相应的改进办法。这其中有DCTCP协议，它使用ECN机制将网络的拥塞程度反馈回发送方以提 前降低发送速率来达到控制交换机队列占用量的目的，不仅降低了包的排队延时而且还能够有效的提高交换机应付突发拥塞的能力。但是，随着并发数的不断增加，只靠拥塞窗口并不能有效的进行拥塞控制，应用性能依然会因为TCP超时而急剧下降。因为即使拥塞窗口减小到最小值1，在过多的TCP连接并发通信时，交换机入口速率依然远大于出口速率，最终占满瓶颈链路交换机缓存，并导致丢包甚至超时。 

ICTCP通过接收方获得的流量信息来调节通告窗口从而控制发送速率。但是，ICTCP同样作为一种基于窗口的传输层控制协议，它也会面临和DCTCP一样的问题。当并发程度过高时，即使按最小的拥塞窗口1来发送依然会造成丢包和超时。 

RS是一种根据缓存大小和服务器请求单元(SRU)大小估计最优并发数的方法。该方法在没有背景流情况下能够很好的工作，但是在数据中心动态的背景流负载下，交换机缓存被背景流占据，使得RS最优并发数估计不准确。所以该方法依然不能够有效的缓解TCP Incast问题。 

因此，力求让数据中心应用能够有效的利用可用带宽，又要尽量能够适应动态的背景流负载，是一个亟待解决的问题。 

发明内容

本发明所要解决的技术问题是提供一种用于DCN中的自适应请求分批调度方法，该用于DCN中的自适应请求分批调度方法能有效解决高并发带来的大量数据包涌入瓶颈链路交换机进而产生的吞吐量崩溃。 

发明的技术解决方案如下： 

一种用于DCN中的自适应请求分批调度方法，包括以下步骤： 

步骤一：初始化； 

将批大小n初始化为1；所述的批大小即为一批的请求数目； 

设置批大小增长门限QSthreshold＝工作服务器数目N； 

将拥塞标志CI清零； 

汇聚服务器向工作服务器群发出第一批请求；【此时n＝1，即发出一个请求】 

步骤二：汇聚服务器在收到所请求的数据块以后，自适应调整下一批的批大 小n，即根据拥塞情况计算下一批的批大小n； 

步骤三：发出下一批请求，请求数目为n，并返回步骤二。 

所述步骤二中：接收端在收到TCP报文时，判断TCP报文是否按序到达，如果出现乱序报文则将拥塞标记CI置为1，否则CI维持原值0；当上一批所请求的数据块全部传输完成之后，检测CI的值，如果CI＝0，则增加n； 

n增大时，通过下式计算n值： 

$n=\left(\begin{array}{cc}n+1& n<\mathrm{QSthreshold}\\ n+\frac{1}{n}& n\ge \mathrm{QSthreshold}\end{array}\right)$

【这个公式的含义说明：当前批大小小于增长门限QSthreshold时，可以在链路负载较轻时快速地增加批大小，提高带宽利用率；当批大小大于QSthreshold时，此时链路负载利用接近饱和，批大小以平缓的增长以避免严重拥塞。】 

如果CI＝1，则按下式减小n和门限QSthreshold： 

$\left(\begin{array}{c}n=\frac{n}{2}\\ \mathrm{QSthreshold}=n\end{array}\right)$【这个公式的含义说明：通过降低批大小和门限来避免下一批请求通信时产生的拥塞】 

其中，QSthreshold为减半之后的n。 

步骤三中，按照步骤二中计算的n，发出下一批的个请求，并将CI清零后返回步骤二；其中，表示下取整。 

有益效果： 

本发明的用于DCN中的自适应请求分批调度方法，在汇聚服务器发送请求时，依据网络拥塞状态动态调整下一批发送请求的个数，使得并发连接数控制在交换机缓存能够容纳的程度内。本发明可以让数据中心应用更加合理地使用网络可用带宽，避免发送方TCP连接频繁超时，从而提升应用性能。 

本发明的技术效果在于：初始化时，批大小n小于门限QSthreshold，每当汇聚服务器收到当前批请求中所回应的所有回应，快速增长批大小，以探测可用带宽。每当收到乱序包后，说明已经链路已经拥塞，减小批大小和门限。此时，由于批大小大于等于门限QSthreshold，所以缓和的增加批大小，从而让数据流 更合理的使用网络可用带宽，以保证能够适应背景流负载。 

实测表面本方法解决拥塞的效果是明显的，详见实施例。 

附图说明

图1为用于DCN中的自适应请求分批调度方法的流程图； 

图2为数据中心Incast场景示意图。 

图3(a)为服务请求单元大小为16kbytes时，不同协议和方法的随着发送发数目增加的吞吐量，其中本发明命名为ARS； 

图3(b)为服务请求单元大小为24kbytes时，不同协议和方法的随着发送发数目增加的吞吐量； 

图3(c)为服务请求单元大小为32kbytes时，不同协议和方法的随着发送发数目增加的吞吐量； 

图4(a)为服务请求单元大小为16kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着发送发数目增加的吞吐量，其中本发明命名为ARS； 

图4(b)为服务请求单元大小为24kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着发送发数目增加的吞吐量； 

图4(c)为服务请求单元大小为32kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着发送发数目增加的吞吐量； 

图5(a)为服务请求单元大小为16kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着背景流强度增加的吞吐量，其中本发明命名为ARS； 

图5(b)为服务请求单元大小为24kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着背景流强度增加的吞吐量； 

图5(c)为服务请求单元大小为32kbytes，并且有指数分布的背景流存在时，不同协议和方法的随着背景流强度增加的吞吐量。 

具体实施方式

以下将结合附图和具体实施例对本发明做进一步详细说明： 

实施例1： 

参见图1，图1为本发明的流程图，一种用于DCN中的自适应请求分批调度方法，包括以下步骤： 

步骤一：初始化； 

将批大小n初始化为1；所述的批大小即为一批的请求数目； 

设置批大小增长门限QSthreshold＝工作服务器数目N； 

将拥塞标志CI清零； 

汇聚服务器向工作服务器群发出第一批请求； 

步骤二：汇聚服务器在收到所请求的数据块以后，自适应调整下一批的批大小n，即根据拥塞情况计算下一批的批大小n； 

步骤三：发出下一批请求，请求数目为n，并返回步骤二。 

所述步骤二中：接收端在收到TCP报文时，判断TCP报文是否按序到达， 

如果出现乱序报文则将拥塞标记CI置为1，否则CI维持原值0；当上一批 

所请求的数据块全部传输完成之后，检测CI的值，如果CI＝0，则增加n； 

n增大时，通过下式计算n值： 

$n=\left(\begin{array}{cc}n+1& n<\mathrm{QSthreshold}\\ n+\frac{1}{n}& n\ge \mathrm{QSthreshold}\end{array}\right);$

如果CI＝1，则按下式减小n和门限QSthreshold： 

$\left(\begin{array}{c}n=\frac{n}{2}\\ \mathrm{QSthreshold}=n\end{array}\right);$

其中，QSthreshold为减半之后的n。 

步骤三中，按照步骤二中计算的n，发出下一批的个请求，并将CI清零后返回步骤二；其中，表示下取整。 

本发明利用NS2.35网络仿真平台来实现，并进行了性能测试。 

图2展示了发生TCP Incast的典型拓扑，它通常包含三个层次的交换机和路由器结构：架顶(Top-of-the-Rack，ToR)交换机，汇聚交换机和汇聚路由器。图2中也给出了机架内部的例子。数据中心应用中，为了保证服务的高扩展性和可 靠性，应用数据通常是切分储存在不同的服务器，各服务器存储的数据片段被称为服务器请求单元(ServerRequestUnit，SRU)。通常，数据中心内部按照以下方式进行通信：汇聚服务器向所有工作服务器发送数据请求。各服务器收到请求后，将传输所拥有的数据片段SRU。汇聚服务器收到所有请求的SRU后，将数据合并或者处理，然后发出下一轮请求。 

图3为没有背景流的实验，实验拓扑和图2所示的Incast场景示意图一致。多个服务器连接到同一交换机，交换机缓存设置为512个包。所有链路的速率均设置为1Gbps。包大小为1000bytes。RTO_min参照目前主流的Linux系统设置为200ms。我们在SRU大小为16kbytes、24kbytes和32kbytes的三种情况下进行测试。 

从图3(a)、(b)和(c)看出，在传统TCP协议下，当工作服务器数量增加到35的时候，应用的吞吐量就出现了明显的崩溃，导致应用性能急剧下降。DCTCP通过交换机ECN标记来达到精确的拥塞控制，相对TCP来说，在相同发送方数量下，吞吐量有很大的提升。但是，在工作服务器数量过高的情况下，由于基于窗口的TCP协议粒度不够，仍然会出现Incast吞吐量崩溃问题。RS通过计算最优并发数来进行分批请求调度，在本场景中达到了非常好的性能。本发明ARS在本场景中通过自适应请求调度方法，同样取得了不错的性能。 

图3是有背景流的情况下，不同协议的对比测试。在本场景中，我们用600Mbps的指数分布的On/OffUDP流来模拟数据中心内部复杂的背景流负载。其他环境设置与图3种一致。 

从图4(a)、(b)和(c)看出，TCP和DCTCP在有背景流的情况下，工作服务器数量大于50之后，都出现了吞吐量崩溃。因为背景流导致瓶颈链路拥塞严重，使得TCP和DCTCP频繁丢包，最终TCP超时并且导致应用性能急剧下降。同时，能观察到采用RS方法，也出现了吞吐量崩溃。这是因为RS的最有并发数的估计方法交换机缓存大小有关，由于背景流的占据了缓存的很大一部分，导致等效的交换机缓存实际上大大缩小，所以原来的估计方法高估了链路容量导致了吞吐量下降。本发明ARS在有背景流的环境中能够根据拥塞情况自适应的调整批大小，以此合理的利用可用带宽，有效的缓解了Incast吞吐量崩溃。 

图5同样是在有背景流的情况下，设置工作服务器数量为恒定的100台，通 过改变背景流速率大小来测试不同方法在不同背景流强度下的性能。我们对200Mbps、400Mpbs、600Mbps和800Mbps分别进行了测试。其他环境测试均与图2种一致。 

从图5(a)、(b)和(c)看出，工作服务器数量达到100台，TCP和DCTCP由于基于窗口的拥塞控制协议的限制，吞吐量与链路带宽相比几乎下降了2个数量级。RS的请求调度方法也随着背景流负载的加重，出现了明显的吞吐量崩溃。在图5(a)中，由于较小的SRU产生的Incast崩溃越明显，此时SRU只有16kbytes，RS几乎只有本发明一半的性能。图5(b)和(c)中，随着SRU的增大，RS性能在200Mbps和400Mbps的情况下，性能与本发明相近。但是，当背景流负载的速率增加到600Mbps和800Mbps时，依然出现了明显的性能下降。本发明ARS通过自适应的方式调度分批请求，在上述的情况下，均能够有效的利用可用带宽，未出现明显的应用层吞吐量崩溃。