Page 317 - 《软件学报》2020年第12期
P. 317

周墨颂  等:一种云环境中的动态细粒度资源调度方法                                                        3983


         经过严密计算之后,FGM 压缩 A1,A2 和 B1 的 CPU 资源分配,使 3 个任务并行执行.A1 和 A2 结束之后,B1 将解
         除压缩分配状态,获得足够资源.轻微的资源压缩以完成时间为代价,提高了服务器的资源使用率和任务并行数
         量,因此,负载任务第 2 阶段的完成时间延长而负载整体完成时间缩短.FGM 调度的负载理论上可在 4.05 时间左
         右完成,相比图 2 中的调度结果,在资源利用率和负载完成时间上均有很大提升.

                               CPU  (Core)                Memory  (GB)
                             4                         8

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

                                     Fig.3    Results of fine-grained scheduling
                                          图 3   细粒度资源调度结果

             本文方法的创新及特色之处在于:
             •   分执行阶段按需求匹配资源,细化资源量和时间的匹配粒度,以避免资源碎片和过度分配.任务资源需
                求根据相似任务运行时信息推测得到,执行阶段依据任务资源需求划分得到;
             •   根据计算资源特性,将资源分为可压缩资源和不可压缩资源两类.必要时对任务所需的可压缩资源进
                行一定程度的压缩分配,以提高计算资源使用率和任务并行数目;
             •   通过运行时资源监控、分配策略调整、调度约束检查等机制调节资源压缩和细粒度调度,保证资源使
                用率和性能.
             本文所提的细粒度资源调度方法可以有效解决负载资源需求具有多样性和动态性环境中因现有固定、粗
         粒度的资源分配方式引发的资源碎片和过度分配问题.本文在细粒度资源调度方法的基础上实现了细粒度资
         源调度器.多种环境下的测试结果显示:细粒度调度器可以在不影响公平性且调度响应时间可接受的前提下,解
         决资源碎片、过度分配等问题,提高资源利用率和性能.

         1    相关工作
             近年来,云计算领域发展迅速,关于云计算资源管理平台及调度算法的研究越来越多.
                   [7]
             Hadoop 是采用集中式调度架构的开源云计算平台,它将计算节点上的资源均分到固定数目的 slot 中,并
         将 slot 分配给 MapReduce [23] 任务.云计算负载的资源需求具有多样性           [1,8−13] ,而 Hadoop 忽略资源需求的多样性,
         因此,任务执行过程中很容易产生资源碎片造成资源浪费.
             Yarn [18] 是从 Hadoop 发展而来的云计算资源管理平台,它采用双层调度架构解耦资源管理和应用逻辑,支持
         多种应用负载.Fuxi    [19] 是阿里巴巴公司提出的资源管理、作业调度系统,它通过增量式资源管理、错误恢复等机
         制,解决了大规模集群调度可扩展性和错误容忍等问题.Fuxi 在资源管理中定义了调度单元,资源申请以调度单
         元为单位进行.Borg     [20] 是谷歌公司用于管理由上万节点集群的管理系统,Borg 基于资源申请进行调度,用户分别
         以千分之一核、字节为单位申请 CPU、内存和磁盘资源.但是,Borg 在分配资源时以 0.5 核和 1GB 内存为粒度,
         将用户请求的资源量向上取整决定实际分配量.本文和 Borg 均将资源分为了可压缩和不可压缩两种,但是 Borg
         只将该特性应用在了资源回收方式的决策中,而并未应用在资源分配中.
             Yarn,Fuxi 和 Borg 均采用基于资源请求的机制决定资源分配量,但是分配量在任务执行期间不再变化.由于
                                                   [1]
         资源申请量通常由人为指定或采用资源最大使用量 ,而任务资源使用不会时刻保持在峰值,因此资源申请量
   312   313   314   315   316   317   318   319   320   321   322