Yarn_资源调度器

  1. 概述

    资源调度器是Hadoop YARN 中最核心的组件之一, 它是ResourceManager 中的一个插拔式服务组件,负责整个集群资源的管理和分配。主要有两种多用户资源调度器的设计思路:第一种在一个物理集群上虚拟多个Hadoop 集群, 这些集群各自拥有全套独立的Hadoop 服务,典型的代表是HOD( Hadoop On Demand )调度器(Hadoop2.0不再使用);另一种是扩展YARN 调度器, 使之支持多个队列多用户。YARN资源调度器提供了三种可用资源调度器, 分别是FIFO ( First In First Out )、Capacity Scheduler 和Fair Scheduler。

  2. 资源调度模型

    (1)双层资源调度模型
    YARN 采用了双层资源调度模型:在第一层中, ResourceManager 中的资源调度器将资源分配给各个ApplicationMaster ;在第二层中, ApplicationMaster 再进一步将资源分配给它内部的各个任务。
    在YARN 中,资源分配过程可概括为以下7 个步骤:
    步骤I NodeManager 通过周期性心跳汇报节点信息。
    步骤2 ResourceManager 为NodeManager 返回一个心跳应答,包括需释放的Container列表等信息。
    步骤3 ResourceManager 收到来自NodeManager 的信息后, 会触发一个NODE UPDATE事件。
    步骤4 ResourceScheduler 收到NODE UPDATE 事件后,会按照一定的策略将该节点上的资源(步骤2中有释放的资源)分配各应用程序,并将分配结果放到-个内存数据结构中。
    步骤5 应用程序的ApplicationMaster 向ResourceManager 发送周期性的心跳,以领取最新分配的Container.
    步骤6 ResourceManager 收到来自ApplicationMaster 心跳信息后,为它分配的container将以心跳应答的形式返回给ApplicationMaster 。
    步骤7 ApplicationMaster 收到新分配的container 列表后,会将这些Container 进一步分配给它内部的各个任务。

    (2)资源保证机制
    在分布式计算中,资源调度器需选择合适的资源保证这样的机制:当应用程序申请的资源暂时无法保证时, 是优先为应用程序预留一个节点上的资源直到累计释放的空闲资源满足应用程序需求(称为“增量资源分配” ,即Incremental placement ),还是暂时放弃当前资源、直到出现一个节点剩余资源一次性满足应用程序需求(称为“ 一次性资源分配” , allor nothing )。这两种机制均存在优缺点, 对于增量资源分配而言,资源预留会导致资源浪费,降低集群资源利用率,而一次性资源分配则会产生饿死现象, 即应用程序可能永远等不到满足资源需求的节点出现。YARN 采用了增量资源分配机制, 尽管这种机制会造成浪费, 但不会出现饿死现象(假设应用程序不会永久占用某个资源, 它会在一定时间内释放占用的资源)。

    ( 3)资源分配算法
    为了支持多维资源调度,YARN资源调度器采用了主资源公平调度算法( Dominant Resource Fairness, DRF) , 该算法扩展了最大最小公平(max-min fairness )算法, 使其能够支持多维资源的调度。在DRF算法中, 将所需份额(资源比例)最大的资源称为主资源, 而DRF的基本设计思想则是将最大最小公平算法应用于主资源上,进而将多维资源调度问题转化为单资源调度问题, 即DRF总是最大化所有主资源中最小的。
    假设系统中共有9个CPU和18 GB RAM, 有两个用户(或者框架)分别运行了两种任务,需要的资源量分别为<1 CPU, 4 GB>和<3 CPU, I GB>。对于用户A, 每个任务要消耗总CPU的1/9(份额)和总内存的2/9, 因而A的主资源为内存;对于用户B, 每个任务要消耗总CPU的1/3和总内存的1/18, 因而B的主资源为CPU。DRF将最大化所有用户的主资源。最终,A获取的资源量为<3 CPU, 12 GB>, 可运行3个任务;而B获取的资源量为<6 CPU, 2GB>, 可运行2个任务。

  3. 资源抢占模型

    在资源调度器中,每个队列可设置一个最小资源量和最大资源量,其中,最小资源量是资源紧缺情况下每个队列需保证的资源量,而最大资源量则是极端情况下队列也不能超过的资源使用量。资源抢占发生的原因则完全是由于“最小资源量” 这一概念。通常而言,为了提高资源利用率,资源调度器(包括Capacity Scheduler 和Fair Scheduler )会将负载较轻的队列的资源暂时分配给负载重的队列(即最小资源量并不是硬资源保证,当队列不需要任何资源时,并不会满足它的最小资源量,而是暂时将空闲资源、分配给其他需要资源的队列),仅当负载较轻队列突然收到新提交的应用程序时,调度器才进一步将本属于该队列的资源分配给它。但由于此时资源可能正被其他队列使用,因此调度器必须等待其他队列释放资源后,才能将这些资源“ 物归原主” ,这通常需要一段不确定的等待时间。为了防止应用程序等待时间过长,调度器等待一段时间后若发现资源并未得到释放,则进行资源抢占。

  4. Capacity Scheduler

    以队列为单位划分资源, 每个队列可设定一定比例的资源最低保证和使用上限,同时,每个用户也可设定一定的资源使用上限以防止资源滥用。而当一个队列的资源有剩余时,可暂时将剩余资源共享给其他队列。Capacity Scheduler 主要有以下几个特点:
    ❑ 容量保证。管理员可为每个队列设置资源最低保证和资源使用上限, 而所有提交到该队列的应用程序共享这些资源。
    ❑ 灵活性。如果一个队列中的资源有剩余,可以暂时共享给那些需要资源的队列,而一旦该队列有新的应用程序提交,则其他队列释放的资源会归还给该队列。相比于HOD调度器, 这种资源灵活分配的方式可明显提高资源利用率。
    ❑ 多重租赁。支持多用户共享集群和多应用程序同时运行。为防止单个应用程序、用户或者队列独占集群中的资源, 管理员可为之增加多重约束(比如单个应用程序同时运行的任务数等)。
    ❑ 安全保证。每个队列有严格的ACL列表规定它的访问用户, 每个用户可指定哪些用户允许查看自己应用程序的运行状态或者控制应用程序(比如杀死应用程序)。此外, 管理员可指定队列管理员和集群系统管理员。
    ❑ 动态更新配置文件。管理员可根据需要动态修改各种配置参数, 以实现在线集群管理。

  5. Fair Scheduler

    与Capacity Scheduler的不同在于:
    ❑ 资源公平共享。在每个队列中,Fair Scheduler可选择按照FIFO、Fair或DRF策略为应用程序分配资源。其中,Fair策略是一种基于最大最小公平算法实现的资源多路复用方式,默认情况下,每个队列内部采用该方式分配资源。这意味着,如果一个队列中有两个应用程序同时运行,则每个应用程序可得到1/2的资源;如果三个应用程序同时运行,则每个应用程序可得到1/3的资源。
    ❑ 支持资源抢占。当某个队列中有剩余资源时,调度器会将这些资源共享给其他队列,而当该队列中有新的应用程序提交时,调度器要为它回收资源。为了尽可能降低不必要的计算浪费,调度器采用了先等待再强制回收的策略,即如果等待一段时间后尚有未归还的资源,则会进行资源抢占:从那些超额使用资源的队列中杀死一部分任务,进而释放资源。
    ❑ 负载均衡。Fair Scheduler提供了一个基于任务数目的负载均衡机制,该机制尽可能将系统中的任务均匀分配到各个节点上。此外,用户也可以根据自己的需要设计负载均衡机制。
    ❑ 调度策略配置灵活。Fair Scheduler允许管理员为每个队列单独设置调度策略(当前支持FIFO、Fair或DRF三种)。
    ❑ 提高小应用程序响应时间。由于采用了最大最小公平算法,小作业可以快速获取资源并运行完成。
    Fair Scheduler的配置选项包括两部分其中一部分在yam-site.xml中, 主要用于配置调度器级
    别的参数;另外一部分在一个自定义配置文件(默认是fair-scheduler.xml )中, 主要用于配置各个队列的资源量、权重等信息。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值