CN108616569B - 一种面向分布式计算应用的光多播请求调度方法 - Google Patents

Abstract

本发明公开了一种面向分布式计算应用的光多播请求调度方法，属于计算机通信领域。首先构建面向分布式计算应用的光多播请求调度平台，收集数据信息并进行分组；若某个分组达到触发条件，则信息组发送到调度触发模块；然后计算该组的宽度提交给光资源分配与多播请求计算调度模块，并按照宽度为每个该组进行实际分配，将分配结果分别提交给多播请求分配模块、拓扑调整模块与剩余光资源填充模块。多播请求分配模块与拓扑调整模块通过专用控制信道，建立OCS连接，启动传输相应的多播请求。最后剩余光资源填充模块优先从宽度较小的多播请求组中选择可用的多播请求。本发明大幅度提升了分布式计算应用的性能，网络性能好，提高了分布式计算应用的性能。

Description

一种面向分布式计算应用的光多播请求调度方法

技术领域

本发明属于计算机通信领域，具体是一种面向分布式计算应用的光多播请求调度方法。

背景技术

现今的数据中心网络中往往运行着大量分布式计算应用，这些分布式计算应用运行在数据中心的多台服务器或虚拟机中，往往被网络带宽制约，即计算性能受制于物理机之间的网络通信。如何解决数据中心中的网络通信，从而提升分布式计算应用的性能，是现在学术界一个非常重视的问题。

所述的分布式计算应用有一个共同的特点：往往包含大量的一对多流量。比如在MapReduce过程中reducer向HDFS写存储数据时以及在一些分布式机器学习算法同步参数时，使用的网络流量往往数据量比较大，存在时间比较长，因此这一类网络流量是分布式计算应用的网络需求的重要组成部分，对分布式计算应用的性能影响很大。

现有的分布式计算架构往往将数据中心网络看作一个黑盒子，通过上层应用的对网络的封装来传输类似的流量。比如Hadoop使用自己定义的分布式存储系统HDFS来进行数据的备份，使用管道流量的传输方式进行这种一对多流量的传输；Spark使用类似BT的P2P方式来处理这样的一对多流量。但是这种实现方法是低效的，有待改进。

现有比较好的方法就是使用基于光纤耦合器的光交换系统来处理一对多的流量传输问题。因为光耦合器可以支持对光信号的复制，所以非常适合传输一对多的多播流量。如图1所示，该设备是以一个大型的光交换矩阵为基础，光交换矩阵上的一些光端口连接到数据中心的ToR交换机(Top of Rack Switch，即机顶交换机)上，另一些端口连接到了一些光耦合器上。通过对光口的重配置，该多播设备可以将数据中心内的任意ToR传输出来的多播流量传输到光耦合器上进行复制，然后再传输到其对应的目的地ToR上，从而完成一对多的网络流量传输。

由于光传输的大容量，大带宽，低时延和低能耗等优点，使用这种方式在支持数据中心中的一对多的多播请求时很有优势。值得注意的是，除了这个设备之外，基于光耦合器的光交换系统都是可以支持多播的。只要将相应的多播数据输入到耦合器的源端，然后将耦合器的输出端连接到相应多播的目的地即可。

但是，在这种光交换系统中，其网络传输的方式与电路交换不同，它的传输方式是基于光路电路交换(OCS)的，因此在这种系统中的光多播请求的控制与调度存在着光资源分配的问题。比如，如果数据中心中每一个ToR上只有一个光收发射机，在建立了一个源ToR与数个目的ToR的OCS连接后，这个源ToR就不能给没有建立OCS连接的其他ToR发送光多播数据了。但是在电网络中，由于所有的数据都是通过电交换机进行交换的，就不会存在这样的光资源约束。因此，只有通过适当的OCS连接的重构，以及将光多播请求进行合理调度，才能最大程度上发挥光多播系统的优势，从而提高分布式计算应用的性能。

基于这个光多播设备来解决数据中心的网络问题，已有现有研究在国际会议或期刊中发表过文章，但是现有的多播请求调度方法都是只考虑网络性能，或者只考虑到多播请求本身。并没有考虑到分布式应用的实际需求，这就导致了虽然这些技术可以让数据中心中的多播请求的完成速度有一定的提升，或者让数据中心网络性能有些许提升，但是最终分布式计算应用的性能却没有达到很好的效果。

分布式计算应用的本质需求应该是任务的完成时间，即从应用的使用者角度来看，并不关心这个系统内的网络状况，只要这个应用完成的速度快，则这个应用效果就是好的。为了探究分布式计算应用真正的网络需求与网络特性，文献1：一种集群应用的网络抽象；Mosharaf Chowdhury,Ion Stoica；2012年10月提出了一种关联流的思想；该文章指出，数据中心中的一个任务的完成时间是由该任务所产生的所有流中最慢传输完成的一个流决定的。也就是说，在考虑分布式计算应用的网络需求时，应该同时考虑来自于同一个应用的所有流。想要让分布式计算应用的性能好，就需要让所有来自同一个应用的流都尽快完成，而不是单独考虑网络中每一个流的完成时间。由于分布式计算应用会产生大量的网络流量请求，而这些网络流量请求往往包含大量一对多的流传输；提高分布式计算应用的关键点就在于如何协同调度这些来自同一个应用的所有一对多的流，使他们都能尽快传输完成。

但是现在所有的光多播设备调度方法都没有考虑到这个因素。比如，文献2：为数据中心网络设计的光多播系统；Payman Samadi,Varun Gupta,Junjie Xu,Howard Wang,Gil Zussman,and Keren Bergman；2015年提出了光多播系统optical multicast system(OMS)，其中使用优先传输数据量最大的多播请求的方法；文献[3]：通过光多播加速高性能数据分析应用；YitingXia,T.S.Eugene Ng,Xiaoye Steven Sun；2015年提出的Blast中采用的方法是：先求得对每个多播请求来说每个光接收机需要接收的数据量，然后优先传输光接收机需要接收的数据量较多的多播请求；文献4：为加速高性能数据中心应用设计的混合光电多播；Jinzhen Bao,Baokang Zhao,Dezun Dong,Zhenghu Gong；2017年8月提出的HERO则采用FIFO的方式优先传输先到的多播请求。这些系统中的调度算法都是仅仅考虑到了单个多播的性能或者整个网络的性能，而并没有考虑到分布式计算应用的性能。虽然文献5：为光数据中心交换设计的基于可调性约束的多播调度；Kamran Keykhosravi,HoumanRastegarfar,Erik Agrell；2017年3月提出了专门针对这一类光多播系统的调度方法，但该文献也仅仅考虑到时延和吞吐量性能。归根结底，这些方法都没有切实地考虑到应用本身的需求，而只是从数据中心网络的角度考虑的。

因此，在实际的分布式计算应用中，虽然以上的方法可以很好地提高网络的性能，以及一定程度上提高分布式计算应用的性能，但并没有从本质上考虑到应用的需求，也没有考虑到数据中心中多播请求的关联性，所以这些方法难以使分布式计算应用达到很优的性能。

但是，如果直接使用文献1中的思想来调度该系统中的多播请求，也难以适用。因为该文献中提出的调度策略是针对于传统的电交换网络的，文献中的网络模型是假设整个网络是一个大型的电交换机，在此基础之上提出的调度策略。这种策略没有考虑到光交换网络中光资源的限制的问题，因此并不适用。

发明内容

本发明针对上述问题，提出了一种面向分布式计算应用的光多播请求调度方法；同时考虑到了分布式计算应用的网络需求，以及光交换网络的资源限制。针对基于光耦合器的光交换系统，通过对到来的多播请求进行分组，以及对每个分组定义与计算新的指标，然后进行调度。该调度方法可以解决上述现有方法中的不足，从而很大程度上减少分布式计算应用的完成时间，从而提高数据中心中分布式计算应用的性能。

所述的面向分布式计算应用的光多播请求调度方法，具体步骤如下：

步骤一、首先构建面向分布式计算应用的光多播请求调度平台；

所述的光多播请求调度平台部署在服务器上或者有计算功能的专用网络控制单元上；包括多播请求信息收集与分组模块、调度触发模块、多播请求组宽度计算模块、光资源分配与多播请求计算调度模块、多播请求分配模块、拓扑调整模块以及剩余光资源填充模块。

为了防止数据信道拥塞造成控制信息的延迟，该调度平台通过专用控制信道连接数据中心中的交换设备和服务器；同时通过专用控制信道连接光交换系统。

步骤二、多播请求信息收集与分组模块通过专用控制信道收集数据中心中ToR上的收发机端口数目的信息，以及来自分布式计算应用的多播请求信息，并进行分组。

按照分布式计算应用中属于同一个应用的多个多播请求分为一组。

步骤三、针对各个分组，判断某个分组中多播请求的个数是否达到触发条件，如果是，多播请求信息收集与分组模块将完整的该多播请求信息组发送到调度触发模块，进入步骤四；否则，继续等待新到达的多播请求；

触发条件被定义为：当有一个新的分布式计算应用的所有多播请求都到齐，则达到触发条件。

步骤四、调度触发模块发出指令给多播请求组宽度计算模块，计算该多播请求组的宽度提交给光资源分配与多播请求计算调度模块。

计算宽度的具体步骤如下：

步骤401、针对完整的多播请求组m，获取该组m的所有源ToR节点与所有目的ToR节点；

源ToR节点名称为：S1,S2…Sn；目的ToR节点名称为：D1,D2…Dn。

步骤402、对某一个源节点S/目的节点D，找到该节点需要发送/接收的属于多播请求组m的所有多播请求，并分别记录大小；

多播请求为：q1,q2…qn，对应的大小为s1,s2…sn。

步骤403、在该源节点S/目的节点D中，将该节点上所有多播请求从大到小逐一虚拟分配到没有请求的光发射机/接收机中，并记录每个发射机/接收机中所需要传输的流量。

假设该源节点S/目的节点D中有k个光发射机/接收机，记为t1,t2…tk/r1,r1…rk；

发射机/接收机需要传输的流量，记为T1,T2…Tk/R1,R2…Rk。

当源节点S/目的节点D上所有多播请求数量小于光发射机/接收机数量时，没有分配的光发射机/接收机所需要传输的流量记录为0。

步骤404、将发射机/接收机按需要传输的流量从小到大排序；并判断是否还有剩余的多播请求，如果有，将剩下的多播请求按顺序逐个虚拟分配到排序后的发射机/接收机中，并更新要传输的流量T/R，直到该组的所有多播请求都被分配完毕。否则，直接更新要传输的流量T/R；

步骤405、根据更新后该源节点S/目的节点D最大的流量T/R，计算所需发送的最小时间Q；

步骤406、对该多播请求组m所有ToR源节点和目的节点，分别求出每个节点的最小时间Q值；

步骤407、选择所有Q值的最大值作为该多播请求组m的宽度W。

步骤五、重复上述步骤，在触发时刻计算系统中所有没完成传输的多播请求组m1,m2….mn对应的宽度W1,W2…Wn进行后续实际分配；

步骤六、光资源分配与多播请求计算调度模块按照宽度为每个多播请求组进行实际分配，并将分配结果分别提交给多播请求分配模块、拓扑调整模块与剩余光资源填充模块。

根据多播请求分组的宽度，在有限的光资源下，优先分配宽度较小的多播请求组，直到光资源用完为止。有限的光资源包括每个ToR的光收发机资源限制和光多播设备上的耦合器数量限制。

具体步骤如下：

步骤601、建立拓扑图G(v,e)，同时初始化每个ToR上光收发机的数量k以及光耦合器的数量z；

v为顶点，图中每个节点v代表被提交的每个多播请求。e为边，即多播请求之间的约束，如果两个多播请求有相同源节点或相同目的节点，则在这两个多播请求所表示的点之间建立连接e，记录建立好的图为G(v,e)的初始状态。

步骤602、从所有多播请求组m1,m2….mn中选择最小宽度W的且包含未分配的多播请求的多播请求组m*；

初始时刻所有多播请求组m1,m2….mn中均为未分配的多播请求。

步骤603、依次选择多播请求组m*中未分配的多播请求q进行处理，且每处理一个多播请求，光耦合器z自减1；

具体处理过程为：针对当前选取的多播请求q，判断对应的点是否在拓扑图G中，如果是，则将多播请求q加入到分配结果集Y中直接进行实际分配，并将代表多播请求q的点以及与其有连边的点都从拓扑图G删除；每分配一个多播请求q就需要消耗一个光耦合器。

步骤604、判断光耦合器z是否大于0，如果是，进入步骤605；否则，结束算法并返回结果集Y；

步骤605、继续选择下一个多播请求q，返回步骤603做同样处理，直到m*中没有可以继续分配的多播请求；

步骤606、判断拓扑图G中是否还有剩余的点，且系统中还有未分配的多播请求组，如果是，进入步骤607；否则，进入步骤608；

步骤607、从未分配的组中选择有最小宽度的多播请求组m*，返回步骤603；否则，进入步骤608；

步骤608、拓扑图G中没有剩余的点，或系统中所有多播请求组都已经被分配过，则记录每个TOR上的剩余光收发机数量k自减1。

步骤609、判断是否k！＝0，如果是，将拓扑图G(v,e)还原为初始状态，删除Y中已经记录的所有多播请求所代表的点，保留与其有连边的点，返回步骤602。否则，k＝＝0，结束算法，返回分配结果集Y。

步骤七、多播请求分配模块与拓扑调整模块通过专用控制信道，控制光交换系统建立OCS连接，同时通知相应的ToR与服务器启动传输结果集Y中的多播请求。

步骤八、当某多播请求传输完成后，数据中心的服务器将告知剩余光资源填充模块，该模块尝试根据上一次的宽度计算结果，优先从宽度较小的多播请求组中选择可用的多播请求。

如果没有任何可用的多播请求，就不做操作。

本发明的优点在于：

1)、一种面向分布式计算应用的光多播请求调度方法，结合了关联流思想，考虑到了分布式计算应用的实际需求，对多播请求进行分组调度，可以大幅度提升分布式计算应用的性能。

2)、一种面向分布式计算应用的光多播请求调度方法，考虑到了光收发机的光资源约束，通过建模合理地分配光资源进行光多播请求的调度，使网络性能好，同时提高分布式计算应用的性能。

附图说明

图1是本发明现有的大型光交换矩阵的结构示意图。

图2是本发明一种面向分布式计算应用的光多播请求调度方法流程图。

图3是本发明构建面向分布式计算应用的光多播请求调度平台的示意图。

图4是本发明对每个多播请求进行分配并计算该多播请求组的宽度方法流程图。

图5是本发明按照宽度为每个多播请求组进行实际分配的方法流程图。

图6是本发明所提方法与现有技术随着多播请求数量的增长平均完成时间的对比图。

图7是本发明所提方法与现有技术随着每个ToR上光收发机数量的增长平均完成时间的对比图。

具体实施方式

下面将结合附图和实施例对本发明作进一步的详细说明。

本发明提出了一种面向分布式计算应用的光多播请求调度方法；涉及分布式计算、光交换技术、数据中心网络、网络控制与调度装置，具体是在数据中心的光多播系统里如何调度分布式计算应用中频繁出现的多播请求的一种方法。同时考虑到了分布式计算应用的网络需求，以及光交换网络的资源限制。在该方法中，针对基于光耦合器的光交换系统，通过对到来的多播请求进行分组，以及对每个分组定义与计算新的指标，然后进行调度；可以解决现有方法中的不足，从而很大程度上减少分布式计算应用的完成时间，从而提高数据中心中分布式计算应用的性能。

如图2所示，具体步骤如下：

步骤一、首先构建面向分布式计算应用的光多播请求调度平台；

所述的光多播请求调度平台如图3所示，部署在服务器上或者有计算功能的专用网络控制单元上；包括多播请求信息收集与分组模块、调度触发模块、多播请求组宽度计算模块、光资源分配与多播请求计算调度模块、多播请求分配模块、拓扑调整模块以及剩余光资源填充模块。

为了防止数据信道拥塞造成控制信息的延迟，该调度平台通过专用控制信道连接数据中心中的交换设备和服务器；同时通过专用控制信道连接光交换系统。

步骤二、多播请求信息收集与分组模块通过专用控制信道收集数据中心中ToR上的收发机端口数目的信息，以及到达的来自分布式计算应用的多播请求信息，并进行分组。

按照分布式计算应用中属于同一个应用的多个多播请求分为一组。

由于一个分布式计算应用的最终完成时间是由最晚完成的一个流量请求决定的，在调度时，只有建立起流量请求之间的关联性，才能更合理地分配与调度这些流量请求。因此，如果一个分布式计算应用中包含了多个光多播请求，则需要将这些光多播请求分为一组，在对他们进行分配与调度时需要考虑他们之间的关联性。在这一步中，有一些关键信息应该由分布式计算应用上报给多播请求信息收集与分组模块：

1.每一个分布式应用启动时应当告诉该模块这个分布式计算应用的id，以及这个应用包含多少个多播请求；

2.对于每一个多播请求，应用所需要上报的信息应该包括：多播的源主机ip，多播的所有目的主机ip，需要传输的数据量大小s，以及这个多播请求所属的任务id号。

其中，源与目的ip用来判断源与目的节点所在的ToR位置，传输数据量是计算多播请求组宽度的参数，任务id号和应用中多播请求的个数是用来对多播请求进行分组的。

步骤三、针对各个分组，多播请求信息收集与分组模块判断某个分组中多播请求的个数是否达到触发条件，如果是，多播请求信息收集与分组模块将完整的该多播请求信息组发送到调度触发模块，进入步骤四；否则，继续等待新到达的多播请求；

由于资源分配的计算以及光资源的分配需要一定的时延，如果频繁地运行来重新分配资源，会对网络造成很大的压力。因此，需要一个合适的触发条件，使得调度触发模块只在合适的时候触发。由于一个分布式计算应用中的所有计算节点不可能同时启动或完成他们的计算任务，因此属于同一个分布式计算应用的多个多播请求不会同时到达，而当这个分布式计算应用的所有多播请求没有全部到达时，控制器就无法知道这个分布式应用所产生的多播请求组的完整属性，这时对这些多播求情进行分配调度就是低效的。因此触发条件被定义为：当有一个新的分布式计算应用的所有多播请求都到齐，则达到装置触发条件；也就是达到应用层告知的各个分组的多播请求个数阈值，该值由应用层决定。

步骤四、调度触发模块发出指令给多播请求组宽度计算模块，通知该模块计算该多播请求组的宽度提交给光资源分配与多播请求计算调度模块。

当多播请求组宽度计算模块收到调度触发模块的指令，它将搜集触发时刻每个多播请求在相关ToR上需要收发的数据量。根据这些信息，逐个计算每个多播请求组的宽度。

触发时刻之前已经被分配与传输的多播请求的剩余数据量大小需要由分布式计算应用告知多播请求信息收集与分组模块。只有获取实时的多播请求信息，才能做出最有效的分配与调度。由于多播请求之间存在关联性，仅仅是针对单个多播请求来做处理和调度是没有意义的，需要计算每个多播请求组在有限的光资源下至少需要多少时间才能传输完成，记这个时间为这个多播请求组的宽度W。如果可以计算出这个指标，根据把需要耗时较小的任务优先完成的思想，便可以获得接近最优的平均任务完成时间。由于ToR上有光收发机数量的限制，网络系统不可能一下就把一个多播请求组的所有多播请求都发送出去，因此必须要知道这个多播请求组是在哪个ToR上遇到了瓶颈，并且求出由于这个瓶颈的存在，在不考虑有其他多播请求组干预的情况下，这个多播请求组需要多长时间才能完成它的传输。想知道这个时间，首先需要计算出对于某一个多播请求分组来说，在与其相关的某一个ToR(如果这个多播请求组中的任一个多播请求的源目的节点中包含一个ToR，则称这个ToR为相关ToR)上完全将该多播请求组的所有流量请求都发送或者接收完毕所需的最小时间Q。对这个多播请求组的所有相关ToR都计算Q值，这一个多播请求组的宽度W定义为这个多播请求组所有Q值的最大值。

如图4所示，具体步骤如下：

步骤401、针对完整的多播请求组m，获取该组m的所有源ToR节点与所有目的ToR节点；

源ToR节点名称为：S1,S2…Sn；目的ToR节点名称为：D1,D2…Dn。

步骤402、对某一个源节点S/目的节点D，找到该节点需要发送/接收的属于多播请求组m的所有多播请求，并分别记录大小；

多播请求为：q1,q2…qn，对应的大小为s1,s2…sn。

步骤403、在该源节点S/目的节点D中，将该节点上所有多播请求从大到小逐一虚拟分配到没有请求的光发射机/接收机中，并记录每个发射机/接收机中所需要传输的流量。

假设该源节点S/目的节点D中有k个光发射机/接收机，记为t1,t2…tk/r1,r1…rk；

发射机/接收机需要传输的流量，记为T1,T2…Tk/R1,R2…Rk。

当源节点S/目的节点D上所有多播请求数量小于光发射机/接收机数量时，没有分配的光发射机/接收机所需要传输的流量记录为0。

步骤404、将发射机/接收机按需要传输的流量从小到大排序；并判断是否还有剩余的多播请求，如果有，将剩下的多播请求按顺序逐个从大到小虚拟分配到排序后的发射机/接收机中，并更新要传输的流量T/R，直到该组的所有多播请求都被分配完毕。否则，直接更新要传输的流量T/R；

步骤405、根据更新后该源节点S/目的节点D最大的流量T/R，计算所需发送的最小时间Q；

步骤406、对该多播请求组m所有ToR源节点和目的节点，分别求出每个节点的最小时间Q值；

步骤407、选择所有Q值的最大值作为该多播请求组m的宽度W。

这个宽度是指这个多播请求组在现有的光资源下到底至少需要多少时间才能传送完。对于每个多播请求组，都可以计算得到它们相应的W值。

步骤五、重复上述步骤，在触发时刻计算系统中所有没完成传输的多播请求组m1,m2….mn对应的宽度W1,W2…Wn进行后续实际分配；

步骤六、光资源分配与多播请求计算调度模块按照宽度为每个多播请求组进行实际分配，并将分配结果分别提交给多播请求分配模块、拓扑调整模块与剩余光资源填充模块。

根据多播请求分组的宽度，在有限的光资源下，优先分配宽度较小的多播请求组，直到光资源用完为止。有限的光资源包括每个ToR的光收发机资源限制和光多播设备上的耦合器数量限制。

优先传送宽度最小的多播组请求将对数据中心内分布式计算应用的性能有所提升。但是，光交换系统与电交换有一些不同，比如存在光收发机端口有限制，光链路资源的限制。虽然知道了哪些多播请求组应该优先分配，但是如何落到分配每个多播请求，以及如何合理地分配光资源以使得更多的多播请求可以被传输，还是一个需要解决的问题。为了以优化分布式计算应用为目的，并将有收发机冲突的多播请求在有限的光资源情况下合理分配下去，如图5所示，具体步骤如下：

步骤601、建立拓扑图G(v,e)，同时初始化每个ToR上光收发机的数量k以及光耦合器的数量z；

v为顶点，图中每个节点v代表被提交的每个多播请求。e为边，即多播请求之间的约束，如果两个多播请求有相同源节点或相同目的节点，则在这两个多播请求所表示的点之间建立连接e，记录建立好的图为G(v,e)的初始状态。

步骤602、从所有多播请求组m1,m2….mn中选择最小宽度W的且包含未分配的多播请求的多播请求组m*；

初始时刻所有多播请求组m1,m2….mn中均为未分配的多播请求。

步骤603、依次选择多播请求组m*中未分配的多播请求q进行处理，且每处理一个多播请求，光耦合器z自减1；

具体处理过程为：针对当前选取的多播请求q，判断对应的点v是否在拓扑图G中，如果是，则将多播请求q加入到分配结果集Y中直接进行实际分配，并将代表多播请求q的点v以及与其有连边的点都从拓扑图G删除；每分配一个多播请求q就需要消耗一个光耦合器。

步骤604、判断光耦合器z是否大于0，如果是，进入步骤605；否则，光多播设备中没有更多可用的光耦合器，结束算法并返回结果集Y；

步骤605、继续选择下一个多播请求q，返回步骤603做同样处理，直到m*中没有可以继续分配的多播请求；

步骤606、判断拓扑图G中是否还有剩余的点，且系统中还有未分配的多播请求组，如果是，进入步骤607；否则，进入步骤608；

步骤607、从未分配的组中选择下一个最小宽度的多播请求组m*，返回步骤603；否则，进入步骤608；

步骤608、拓扑图G中没有剩余的点，或系统中所有多播请求组都已经被分配过，则记录每个TOR上的剩余光收发机数量k自减1。

步骤609、判断是否k！＝0，如果是，将拓扑图G(v,e)还原为初始状态，删除Y中已经记录的所有多播请求所代表的点，保留与其有连边的点，返回步骤602。否则，k＝＝0，结束算法，返回分配结果集Y。

得到分配结果集Y后，光资源分配与多播请求计算调度模块将计算结果告知多播请求分配模块、拓扑调整模块与剩余光资源填充模块，从而进行对数据中心网络中多播请求的控制，以及光交换系统的控制。

步骤七、多播请求分配模块与拓扑调整模块通过专用控制信道，控制光交换系统建立OCS连接，同时通知相应的ToR与服务器启动传输结果集Y中的多播请求。

在这一过程中，多播请求分配模块与拓扑调整模块根据分配结果对网络进行实际的操作。

步骤八、当某任意多播请求传输完成后，数据中心的服务器将告知剩余光资源填充模块，该模块尝试根据上一次的宽度计算结果，优先从宽度较小的多播请求组中选择可用的多播请求。

如果没有任何可用的多播请求，就不做操作。

一旦有多播请求完成了，网络系统中的光交换资源就会有一部分空闲下来。为了充分利用光交换资源，将查看在现有的多播请求中有没有可以直接分配的多播请求。按照之前计算的多播请求组的宽度从大到小搜索所有多播请求，如果有能够利用空闲的光交换资源传输的多播请求，则将该请求直接分配下去。当然，也有可能虽然有一部分光交换资源空闲下来了，仍然没有任何多播请求可以在这样有限的空闲资源下被安置和调度到系统中，这时就不做操作。与此同时，该装置应当继续从分布式计算应用中收集到达的多播请求信息，如果有新的多播请求组完整到达了，该装置将重新对所有的多播请求进行分配与调度。

对本发明进行仿真，并与现有的方法相对比，对分布式计算应用的平均完成时间有明显的改善。在仿真中，整个数据中心包含100个ToR，每个ToR有40个服务器与之相连。假设光链路速率为10Gbps。随机生成了一定数量的多播请求，这些多播请求的流量大小服从500Mbits到2.5Gbits之间的均匀分布，他们的目的地个数服从2到10之间的均匀分布。

假设这些多播请求同时到达，并且不会有新的多播请求到达，从而对比本发明与以往的多播请求调度方法的效果。然后，仿真中将这些多播请求随机分组为多播请求组。一个多播请求组包含2到10个多播请求。仿真中假设光多播设备的耦合器有25个，每个耦合器都有足够多的端口来支持仿真中的多播请求。因为一个多播请求组的完成时间可以直接反应一个分布式计算应用的网络传输完成时间，在仿真中，一个多播请求组就代表一个分布式计算应用。

如图6所示，当固定每个ToR上有1个光收发机，然后改变系统中到达的多播请求的数量，从图中可以看出，随着系统中的存在的多播请求量增加，本发明的方法优势也较以往的方法提升更加明显。

图7中展示的结果是当固定系统中有500个多播请求，然后改变每个ToR上的光收发机数量得到的。可以看出，在有耦合器数量限制的情况下，随着每个ToR上光收发机数量的增加，光多播设备上的耦合器会被全部占用。在相同有限的光交换资源下，本方法可以比以往的方法明显减少分布式计算应用的耗时。

Claims (3)

1.一种面向分布式计算应用的光多播请求调度方法，其特征在于，具体步骤如下：

步骤一、首先构建面向分布式计算应用的光多播请求调度平台；

所述的光多播请求调度平台部署在服务器上或者有计算功能的专用网络控制单元上；包括多播请求信息收集与分组模块、调度触发模块、多播请求组宽度计算模块、光资源分配与多播请求计算调度模块、多播请求分配模块、拓扑调整模块以及剩余光资源填充模块；

为了防止数据信道拥塞造成控制信息的延迟，该调度平台通过专用控制信道连接数据中心中的交换设备和服务器；同时通过专用控制信道连接光交换系统；

步骤二、多播请求信息收集与分组模块通过专用控制信道收集数据中心中ToR上的收发机端口数目的信息，以及来自分布式计算应用的多播请求信息，并进行分组；

步骤三、针对各个分组，判断某个分组中多播请求的个数是否达到触发条件，如果是，多播请求信息收集与分组模块将完整的多播请求信息组发送到调度触发模块，进入步骤四；否则，继续等待新到达的多播请求；

步骤四、调度触发模块发出指令给多播请求组宽度计算模块，计算该多播请求组的宽度提交给光资源分配与多播请求计算调度模块；

计算宽度的具体步骤如下：

步骤401、针对完整的多播请求组m，获取该组m的所有源ToR节点与所有目的ToR节点；

源ToR节点名称为：S1,S2…Sn；目的ToR节点名称为：D1,D2…Dn；

步骤402、对某一个源节点S/目的节点D，找到该节点需要发送/接收的属于多播请求组m的所有多播请求，并分别记录大小；

多播请求为：q1,q2…qn，对应的大小为s1,s2…sn；

步骤403、在该源节点S/目的节点D中，将该节点上所有多播请求从大到小逐一虚拟分配到没有请求的光发射机/接收机中，并记录每个发射机/接收机中所需要传输的流量；

假设该源节点S/目的节点D中有k个光发射机/接收机，记为t1,t2…tk/r1,r1…rk；

发射机/接收机需要传输的流量，记为T1,T2…Tk/R1,R2…Rk；

当源节点S/目的节点D上所有多播请求数量小于光发射机/接收机数量时，没有分配的光发射机/接收机所需要传输的流量记录为0；

步骤404、将发射机/接收机按需要传输的流量从小到大排序；并判断是否还有剩余的多播请求，如果有，将剩下的多播请求按顺序逐个虚拟分配到排序后的发射机/接收机中，并更新要传输的流量T/R，直到该组的所有多播请求都被分配完毕；否则，直接更新要传输的流量T/R；

步骤405、根据更新后该源节点S/目的节点D最大的流量T/R，计算所需发送的最小时间Q；

步骤406、对该多播请求组m所有ToR源节点和目的节点，分别求出每个节点的最小时间Q值；

步骤407、选择所有Q值的最大值作为该多播请求组m的宽度W；

步骤五、重复上述步骤，在触发时刻计算系统中所有没完成传输的多播请求组m1,m2….mn对应的宽度W1,W2…Wn进行后续实际分配；

步骤六、光资源分配与多播请求计算调度模块按照宽度为每个多播请求组进行实际分配，并将分配结果分别提交给多播请求分配模块、拓扑调整模块与剩余光资源填充模块；

根据多播请求分组的宽度，在有限的光资源下，优先分配宽度较小的多播请求组，直到光资源用完为止；有限的光资源包括每个ToR的光收发机资源限制和光多播设备上的耦合器数量限制；

具体步骤如下：

步骤601、建立拓扑图G(v,e)，同时初始化每个ToR上光收发机的数量k以及光耦合器的数量z；

v为顶点，图中每个节点v代表被提交的每个多播请求；e为边，即多播请求之间的约束，如果两个多播请求有相同源节点或相同目的节点，则在这两个多播请求所表示的点之间建立连接e，记录建立好的图为G(v,e)的初始状态；

步骤602、从所有多播请求组m1,m2….mn中选择最小宽度W的且包含未分配的多播请求的多播请求组m*；

初始时刻所有多播请求组m1,m2….mn中均为未分配的多播请求；

步骤603、依次选择多播请求组m*中未分配的多播请求q进行处理，且每处理一个多播请求，光耦合器z自减1；

具体处理过程为：针对当前选取的多播请求q，判断对应的点是否在拓扑图G中，如果是，则将多播请求q加入到分配结果集Y中直接进行实际分配，并将代表多播请求q的点以及与其有连边的点都从拓扑图G删除；每分配一个多播请求q就需要消耗一个光耦合器；

步骤604、判断光耦合器z是否大于0，如果是，进入步骤605；否则，结束算法并返回结果集Y；

步骤605、继续选择下一个多播请求q，返回步骤603做同样处理，直到m*中没有可以继续分配的多播请求；

步骤606、判断拓扑图G中是否还有剩余的点，且系统中还有未分配的多播请求组，如果是，进入步骤607；否则，进入步骤608；

步骤607、从未分配的组中选择有最小宽度的多播请求组m*，返回步骤603；否则，进入步骤608；

步骤608、拓扑图G中没有剩余的点，或系统中所有多播请求组都已经被分配过，则记录每个TOR上的剩余光收发机数量k自减1；

步骤609、判断是否k!＝0，如果是，将拓扑图G(v,e)还原为初始状态，删除Y中已经记录的所有多播请求所代表的点，保留与其有连边的点，返回步骤602；否则，k＝＝0，结束算法，返回分配结果集Y；

步骤七、多播请求分配模块与拓扑调整模块通过专用控制信道，控制光交换系统建立OCS连接，同时通知相应的ToR与服务器启动传输结果集Y中的多播请求；

步骤八、当某多播请求传输完成后，数据中心的服务器将告知剩余光资源填充模块，该模块尝试根据上一次的宽度计算结果，优先从宽度较小的多播请求组中选择可用的多播请求。

2.如权利要求1所述的一种面向分布式计算应用的光多播请求调度方法，其特征在于，所述的步骤二中，按照分布式计算应用中属于同一个应用的多个多播请求分为一组。

3.如权利要求1所述的一种面向分布式计算应用的光多播请求调度方法，其特征在于，所述的步骤三，触发条件的定义为：当有一个新的分布式计算应用的所有多播请求都到齐，则达到触发条件。