Page 316 - 《软件学报》2020年第12期

3982 Journal of Software 软件学报 Vol.31, No.12, December 2020

[2]
高性能计算平台通常基于 core 分配资源 ,而云计算平台常常基于一种资源(通常为内存)或者将两种固定
量的计算资源捆绑定义为 slot,并以 slot 作为资源分配的单位 [3−7] ,这均属于粗粒度的资源分配方式.由于负载对
资源的需求具有多样性 [1,8−13] ,基于固定单位的资源分配方式很容易产生资源碎片而造成资源浪费.一些研
究 [14,15] 按资源偏好将负载分为 CPU 密集型和 IO 密集型两种,并在调度中使不同资源偏好的负载一起执行,以减
少资源碎片造成的浪费.还有一些研究采用动态调整 slot 数目来避免资源碎片,但是这并未有效解决问题,未经
过严密计算而改变 slot 数目或者将负载分为若干类互补执行,极易造成不良的资源共享或资源过度分配.有些
资源(比如 CPU)的不良共享会导致任务之间竞争资源,最终造成执行时间大幅增加 [16] .在数据中心中,超过 53%
的落后任务是由不良共享引发的高资源利用率造成的,并且 4%~6%的非正常任务影响着 37%~49%的作业,造
成作业完成时间的大幅延长 [17] .而有些资源(比如内存)的过度分配会直接导致任务失败或者服务器崩溃.
Yarn [18] ,Fuxi [19] ,Borg [20] 等资源管理平台和 Apollo [11] ,Omega [12] ,Tetris [13] ,DRF [21] ,Carbyne [22] 等调度算法基于
资源申请分配固定量资源,以避免资源碎片、过度分配等问题.由于资源申请量通常由人为指定,资源申请量与
[1]
实际使用量之间存在差异 .另外,任务资源使用量波动很大,不会始终保持在峰值.使用任务最大资源使用量作
[8]
为申请量时,资源申请量与实际使用量之间依然存在差异 .因此,资源管理平台或者调度器按照资源申请量进
行分配时,资源碎片依然存在.基于资源申请的分配方式很难取得高资源利用率,该方式一定程度上限制了集群
[8]
计算资源利用率 .举例来说,有任务 A 和 B,其执行阶段及资源需求如图 1 所示.假设服务器配置为 4 核 CPU 和
8GB 内存,任务 A1,A2,B1 依次到达,则基于资源申请的调度结果如图 2 所示,其中,阴影部分为资源碎片.当任务
A1,A2 分配计算资源之后,CPU 资源剩余 2 核,不满足 B1 的资源需求.因此,任务 B1 只能等待计算资源,最终负载
在 7 单位时间内完成.

Fig.1 Resource requirements and durations of tasks execution stages
图 1 任务资源阶段的资源需求及持续时间

CPU (Core) Memory
4 8 (GB)
资源碎片
3 6

2 4
A2.S1 A2.S2 A2.S1 A2.S2
1 2
A1.S1 A1.S2 B1.S1 B1.S2 A1.S1 A1.S2 B1.S1 B1.S2
1 2 3 4 5 6 7 Time 1 2 3 4 5 6 7 Time

Fig.2 Results of request-based scheduling
图 2 基于资源申请的调度结果

针对上述云计算平台中,资源管理和作业调度中存在的问题,本文提出一种细粒度资源调度方法(fine-
grained method,简称 FGM).该方法分阶段匹配资源需求和可用资源,细化资源匹配粒度,并在分配中根据资源特
性压缩资源需求,进一步提高资源利用率和负载性能.对于前文例子中的负载,细粒度资源调度的结果如图 3 所
示.FGM 推测任务的资源需求,并将任务划分为两个执行阶段;之后,FGM 按照任务各执行阶段的资源需求及持
续时间分别匹配资源.FGM 在向 A1 和 A2 分配其实际所需资源量之后,剩余 CPU 资源不满足 B1 的资源需求.