基于队列迁移的数据中心紧急任务动态调度方法

李 炜

（武汉大学人民医院信息中心，湖北 武汉 430060）

伴随着因特网和硬件设备的发展，数据中心作为一种基础设施来部署各种应用，其规模经历了独立数据中心、异地多数据中心和边缘小型数据中心3 个层次的演变。 当今的数据中心不仅规模越来越大，粒度也会越来越细。 数据中心解决紧急任务需要降低成本，大大缩短数据中心建设周期，这也是边缘数据中心和应急容灾机房的理想选择，已为整个市场所接受，甚至成为国外数据中心发展的一个趋势[1]。 如微软和谷歌，已经开始大规模部署容器化数据中心解决方案。 数据中心在云平台下采用标准化机房，相对于同一地区的传统数据中心，云平台系列的建造成本大大降低[2]。 数据中心紧急任务动态调度是一种预配置的、可随时移动到任何位置紧急任务解决方案，它只需要电力和网络就能正常工作， 这节省了大量的土地审批和工厂建设资金，也节约了成本。

对此学者进行大量研究，任良育等[3]提出基于任务复制与冗余消除的多核调度方法，该方法复制任务的先驱者和先驱者的思想，减少了调度长度和处理器空闲时间， 并且在不增加调度长度的前提下，通过合并簇和减少冗余任务，降低了处理器数目和处理器负载。 周亮等[4]提出基于能量感知的OLSR 协议任务调度研究，OLSR 协议具有动态、标准化、可扩展等优点，是灾场应急通信网任务调度的首选路由协议。 对消息泛洪机制和消息广播机制进行了改进， 并在此基础上引入能量感知策略，实现了具有能量感知的最小MPR 集选择方法， 完成任务调度。 上述方法可将任务难度系数降至最低，但存在复制过度、资源浪费等问题。 日益复杂的商用云平台使任务在云环境中的动态调度成为一个具有挑战性的问题。 在上述研究的基础上，研究了基于队列迁移的数据中心紧急任务动态调度方法，提出紧急任务动态调度模型，充分发挥模型中每个模块的作用，对数据中心紧急任务动态调度提供方案，有效完成计算资源利用率，满足迁移条件下的紧急任务动态调度。

1 云平台紧急任务动态调度过程

用户请求、调度控制、资源利用、收集和存储反馈信息、后台优化是云平台紧急任务动态调度的主要过程，主要过程如下所示：云用户通过Web 向云服务供应商支付服务费，得到授权功能，授权后提交所对应的服务紧急任务请求；接收到请求后，云平台动态调度管理中心将向相应的数据中心发送请求，基于用户所处的地理位置信息、发出的请求所属服务类型和所对应的数据动态调度管理中心， 需要选择按动态调度方法执行要求分配具体服务；在客户服务运行期间，动态调度中心会在后台提供优化服务， 使云平台紧急任务动态调度过程达到最佳状态[5]，让云客户对云平台资源的使用更加合理。 图1 显示了云平台环境中紧急任务动态调度模型。

图1 紧急任务动态调度模型Fig.1 Emergency task dynamic scheduling model

在图1 中显示的模型主要包括5 个模块：第1 模块为用户组；第2 模块为接收、预处理单元和紧急任务分类器； 第3 模块为动态调度器；第4 模块为数据中心管理器；第5 模块为数据中心/执行器。

1） 用户组。

根据云平台下用户服务需求，如基础结构服务中获取不同服务类型。 用户可以提交预处理单元中的工作，能得到相应的回馈，企业中使用的云平台服务需要客户支付服务费[6]。

2） 接收、预处理单元和紧急任务分类器。

这两个单元的作用是获得用户紧急任务，对其进行预处理和分类。 其中接收、预处理单元主要负责接收不同紧急任务以及前期处理，紧急任务分类器主要功能是把紧急任务依据属性的不同进行分类。 基于服务类型，将任务划分为不同等级的紧急任务，然后将划分后的紧急任务动态调度到中心相应的队列中[7-8]。

3） 动态调度器。

动态调度器即动态调度所使用的程序，运行原理是从接收、预处理单元和紧急任务分类器中获得动态调度的数据信息[9]。 动态调度器主要功能是完成最优映射紧急任务到处理单元，一定程度上可以决定如何优化紧急任务，达到满足动态调度目标的要求[10]。

4） 数据中心管理器。

该部分的功能主要是发挥中心动态调度的作用，是数据信息的集散的重要场所，起到控制作用。软件收集每一个处理单元的最新执行信息，并提供对动态调度器有利的信息[11-12]。

5） 数据中心/执行器。

数据中心/执行器是云平台紧急任务动态调度过程中核心环节，发挥着重要作用，它主要负责为客户服务，它主要由虚拟集群、大量存储资源和以处理单元为主的计算资源构成。数据中心/执行器也可以记录每个处理单元的运行状态[13]，例如每一个虚拟机或设备的当前紧急任务完成状态，每个处理单元需要完成在紧急任务队列中提取到的相应紧急任务[14]。

2 数据中心紧急任务动态调度

根据云平台紧急任务动态调度模型，使优化操作可以从后台完成，可以将任务请求发送到动态调度中心对应的队列中，从而获得最优映射[15]。然而在该过程中，各个节点处理能力却是有限的，为此需确定数据处理紧急任务时间特征，由此设计紧急任务动态调度方案。

2.1 数据处理紧急任务控制动态调度节点模型

在云平台下，各节点的处理能力是有限的，因为数据中心需要获取现有机房中的大部分数据。 在大规模数据中，节点阻塞将限制导致云平台系统模块分析数据能力，且处理时间将延长[16]。为了解决这一问题，需要在对应节点上采用动态调度方法调整紧急任务，一定程度上提高设定目标与动态调度紧急任务的完成率，减少了处理紧急任务节点的阻塞[17]，防止过程中可能出现的问题发生。 图2 显示了控制动态调度节点模型。

图2 控制动态调度节点模型Fig.2 Control dynamic scheduling node model

由图2 可知，以数据的提取-转换-装入过程为例，数据需要使各个数据源在系统中所处位置相分离， 将提取到的数据储存到云平台中各个节点上，在必要时控制动态调度节点，分析动态调度紧急任务所产生的数据。 同时，由于数据源存在差异，还需要对数据格式进行标准化处理[15]。 数据源平台可以优先进行信息采集， 然后对采集到的信息进行监测，区分出不同处理需求的数据，针对分析完成的处理紧急任务，以此进行分类。

2.2 数据处理紧急任务时间特征

数据推送过程中对时间的要求有所差异，依据不同预置模块对此差异的特点[19]，以控制动态调度节点模型为前提，需要优先考虑时间因素，对紧急任务时间的分配需优先分析，在时间最优级选择时需优先处理， 保证数据推送的及时性及安全性，大部分预先设定的模块化数据均包含时间属性，它的时间特性可以记录如下

式中：Wi，j为紧急任务时间数据节点。 综上所述，构建不同的紧急任务时间特征，对紧急任务动态调度方案进行了设计。

2.3 紧急任务动态调度方案设计

优化数据处理紧急任务的排序，使其呈现最佳状态，确保重要紧急任务得到处理，提高系统处理性能，一定程度上可以减少数据处理过程中的阻塞和损失。 一般情况下，在控制紧急任务动态调度节点过程中，预计紧急任务需要等待系统资源被动态调度处理后才可以继续进行动态调度，而预设行为需要相应的操作流程支持完成，从而产生额外的延迟问题，因此采用非预设动态调度策略更有利于紧急任务动态调度方法的完成[20]。 紧急任务处理的难易会带来时间上的差异，为了适应处理紧急任务在时间上的变化，还需要对数据处理紧急任务进行动态排序，从而避免出现无限优先级问题。

数据处理紧急任务在控制动态调度节点中可分为以下3 种状态：①紧急任务执行状态，即在计划中的但还未完成的紧急任务； ②等待执行状态，即已在队列中进行了处理，但尚未分配系统资源和正在等待的作业；③调节紧急任务意味着新的处理紧急任务刚到队列，现在正在进行调节。

在远程交互队列执行处理紧急任务时，考虑迁移动态调度问题，设计了如图3 所示的迁移过程。

图3 控制动态调度节点队列迁移过程Fig.3 Control dynamic scheduling node queue migration process

通过选取动态调度节点，并引入节点期望紧急任务数Lj作为衡量节点工作状态的指标

式中：lj为节点紧急任务数量；m 为区域节点数量；rj为节点资源数量。

动态调度流程如下：

步骤1 紧急任务动态调度器在处理需要动态调度的紧急任务前， 需要根据资源状态和每个节点的预期紧急任务数来确定和选择动态调度目标节点。

步骤2 确定和选择动态调度目标节点后，通过处理发送紧急任务完成队列调整。 若完成队列调整后紧急任务达到设定的紧急任务数量值，则此刻对应节点紧急任务数量指标为lj＜Lj，此时需要创建一个新队列，转移处理紧急任务。

步骤3 转移处理紧急任务后， 需要判断是否已达到设定的情况，如果没有，则需先处理数据；否则， 分析传输紧急任务的优先级和队列中优先级。在这两个优先级中存在以下两种情况：

1） 传递紧急任务具有比所有队列优先级更大的优先级，如果处理器处于空闲状态，那么需要直接处理，并提交相关紧急任务；如果处理器是在忙碌状态时，那么需要在下一个周期处理紧急任务；

2） 传递紧急任务的优先级与当前团队中所有队列优先级相同，则先处理该队列中紧急任务。该情况下如果有一个紧急任务等待处理， 而上一个紧急任务在处理期限后仍没有完成， 那么在短期限制内将会执行新紧急任务。 上一个未完成紧急任务需要迁移到一个节点上，避免节点出现丢失现象。

步骤4 通过控制动态调度节点队列迁移过程，完成所有节点动态调度，由此实现基于队列迁移的数据中心紧急任务动态调度方法。

3 实验结果分析

Cloud Sim 是由Melbourne 大学和Gridbus 项目团队于2009 年共同推出的一个功能强大的云计算环境模拟软件。Cloud Sim 扩展了基于Grid Sim 的基于Java 的离散事件模拟包，并在Grid Sim 现有的体系结构上进行开发；Cloud Sim 可以在Windows 和Linux 等多种系统平台上运行。 这一部分首先应用Cloud Sim 模拟器模拟和创建云计算环境，然后对其可用资源的分方法进行模拟仿真。 紧急任务动态调度测试实验是通过模拟测试平台中的控制动态调度节点完成的。 为了模拟突发数据和保障实验的准确性，对比文献[3]基于任务复制调度方法和文献[4]基于能量感知调度方法，和本文提出的基于队列迁移的数据中心紧急任务动态调度方法进行实验验证。

3.1 任务调度完成数量

以任务调度完成数量为研究对象，分别使用能量感知调度方法、基于任务复制调度方法和基于队列迁移调度方法分析任务调度完成数量，结果如图4 所示。

图4 3 种方法任务调度完成数量对比分析Fig.4 Comparative analysis of the task numbers scheduled by three methods

由图4 可知，使用基于能量感知调度方法无法完成全部任务，在任务数为7 万个时，仅完成不到5万个的任务数量； 使用基于任务复制调度方法也无法完成全部任务，在任务数为7 万个时，完成6 万个的任务数量； 使用基于队列迁移调度方法能够完成全部任务。 这是由于本文基于队列迁移调度方法在控制紧急任务动态调度节点过程中， 预设紧急任务等待系统资源被动态调度处理， 然后继续进行动态调度，在预设行为过程中，制定相应的操作流程，采用非预设动态调度策略完成紧急任务动态调度， 一定程度上有助于任务的完成； 而文献中基于能量感知调度方法和基于任务复制调度方法未考虑此因素。

3.2 紧急任务完成率

以紧急任务完成率为研究对象，分别使用3 种方法分析紧急任务完成率，结果如图5 所示。

图5 3 种方法紧急任务完成率对比分析Fig.5 Comparative analysis of sudden task completion rate of three methods

由图5 可知，使用基于能量感知调度方法任务完成率随着任务数的增加，完成率低于50%，说明任务完成效果较差；使用基于任务复制调度方法随着任务数的增加，完成率低于80%，说明任务完成效果一般；使用队列迁移调度方法任务完成率随着任务数的增加，完成率在95%以上，说明任务完成效果较好。 这是因为本文方法在控制动态调度节点队列迁移过程中，选取动态调度节点，并引入节点期望紧急任务数作为衡量节点工作状态的指标，有利于提高紧急任务的完成率。

3.3 截止期错失率

在集群平均负载不同的情况下，截止期错失率也随之发生改变。 以截止期错失率为研究对象，分别使用3 种方法分析紧急任务完成率，结果如图6 所示。

图6 3 种方法截止期错失率对比分析Fig.6 Comparison and analysis of deadline error rate of three methods

由图6 可知，使用基于能量感知调度方法和基于任务复制调度方法截止错失率始终高于45%，而使用队列迁移调度方法截止错失率始终低于18%，具有良好动态调度效果。 这是因为本文方法在处理紧急任务时间特性上，将重要因素视为紧急任务完成有效时间，其次考虑所需要的等待时间，使数据处理紧急任务时间特征整体得到有效控制，有利于降低紧急任务截止期错失率。

4 结论

为实现对紧急任务运行时间的有效控制，充分利用云平台资源，提出了基于队列迁移的数据中心紧急任务动态调度方法。

1） 该策略需先获取各计算资源初始分配方案，并通过采用动态调整方法，有效地提高了计算资源利用率。 在云平台服务期间，通过对空闲计算资源进行紧急任务迁移动态调度，从而将满足迁移条件的其他任务迁移到该资源内。

2） 对现有数据中心设计缺陷进行系统深入研究，尤其针对应用特点和新用户需求，结合局内机房及现场特点， 对新能源使用方式进行系统模块化创新。 针对紧急任务动态调度需求，需依据实际的管理流程，并通过全过程模式进行创新、优化和完善。

3） 针对紧急任务动态调度需求， 需依据实际的管理流程，并通过全过程模式进行创新、优化和完善。