Hadoop FairScheduler

目标

本文档描述FairScheduler，一个容许YARN应用程序公平共享集群资源的调度插件。

 

概述

公平调度是一个分配资源给全部application的方法，平均来看，是随着时间的进展平等分享资源的。下一代Hadoop可调度多资源类型。默认的，FairScheduler只基于内存的公平调度策略。它能够配置为包括内存和cpu的调度，采用Ghodsi等开发的主资源公平算法。当只有一个application运行时，该application使用整个集群。当其余应用程序提交以后，释放出来的资源分配给新的application，因此每一个application最终会获得大体相同量的资源。不像默认的hadoop调度器，它由一个应用程序的队列组成，这让短应用在合理的时间内结束而不是长时间存活引发系统调度饥饿。它仍是在必定数量用户间共享集群的一个合理方法。最后，公平分享也能够与应用程序优先级一块儿工做——优先级用做决定每一个应用程序应该得到的总资源的比例的权重。

调度器组织应用程序进入“队列”，并公平共享这些队列间的资源。默认的，全部用户共享一个叫作“default”的队列。若是一个应用程序在容器资源请求中列出了一个队列，那么这个请求将被提交到该队列。经过配置也能够基于包含在请求中的用户名来分配队列。对于每个队列，经过一个调度策略用于在运行的应用程序中共享资源。默认是基于内存的公平共享，可是也能够配置FIFO和多资源的DRF。队列能够编排成层级结构以便拆分资源，而且能够经过权重配置分享集群特定比例的资源。

 

另外为了提供公平共享，Fairscheduler容许为队列分配最小共享份额，这对确保特定用户、组、产品应用始终得到足够的资源很是有用。当队列包含应用时，它至少要得到共享最小份额，可是当队列不须要它彻底保证的份额时，多出的部分拆分给其余运行中的应用程序。这就让调度器既保证了队列的容量，又能够在这些队列不包含应用程序时高效的利用资源。

FairScheduler默认让全部app运行，可是它也能经过配置文件限制每一个用户、队列的运行app的数量。这对用户一次必须提交几百app或者想要提高性能（若是一次运行过多app会引发建立过多的中间数据，或者过多的上下文切换）时颇有用。限制app不会引发后续的提交app失败，只会在调度器的队列中等待，直到某些用户较早的app结束。

 

具备插件式策略的层级队列

Fair Scheduler支持层级队列。全部的队列都从属于一个叫作“root”的队列。可用的资源采用典型的公平调度方式在root队列的子队列中分布。而后，子队列将分配给他们的资源采用相同的方式分布到他们的子队列中。App只在叶子队列上调度。经过在分配文件中放置队列做为他们双亲的子元素，能够将队列指定为其余队列的子队列。

队列的名称已其双亲的名称做为开头，用句点（"."）做为分隔符.因此root队列下的名为"queue1"的队列会被称为“root.queue1”,位于“parent1”队列下的“queue2”队列会被称为"root.parent1.queue2".当提到队列时，名称中的root部分是可选的，因此queue1能够被称为"queue1",queue2能够被称为“parent1.queue2”.

另外，FairScheduler容许为不一样的队列设置不一样的个性化策略，容许采用用户想要的方式共享队列的资源。个性化策略能够经过继承 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy来构建。 内置的FifoPolicy, FairSharePolicy (默认的), 以及DominantResourceFairnessPolicy策略能够方便的使用。在原始的（MR1）FairScheduler中存在的特定插件如今还不支持。其中，是使用自定义的策略在特定应用程序上调整优先级“提高”。

 

 

自动放置应用程序到队列

Fairscheduler容许管理员配置策略，将提交的应用程序放置到相应的队列。放置依赖于提交的用户和组，以及应用程序传过来的申请中的队列信息。一个策略由一组规则组成，这些规则对进来的应用程序进行一系列的分类。每一个规则要么放置应用程序到一个队列，或者拒绝它，又或者继续交由下一个规则。关于如何配置这些策略能够参考下面分配文件格式。

安装

要使用FairScheduler首先要在yarn-site.xml中指定相应的调度器class。

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

配置

定制化FairScheduler一般会引发两个文件的变动。首先调度器层面的选项能够经过在配置目录下yar-site.xml文件中增长配置项进行设置。其次，在大多数状况下用户将想要建立一个分配文件代表存在哪些队列，以及它们的相应权重和容量。这个分配文件每10秒重载一次，所以容许在运行时进行修改。

yarn-site.xml中能够被放置的属性

属性 描述

yarn.scheduler.fair.allocation.file	分配文件的路径。分配文件是一个xml，描述队列以及它们的属性，补充特定的默认策略。这个文件必须是下一节描述的xml格式。若是指定了一个相对路径，将会在classpath下搜索这个文件（一般在hadoop的conf目录下）。默认是fair-scheduler.xml.
yarn.scheduler.fair.user-as-default-queue	在队列名未指定的状况下，是否使用用户名做为分配的默认队列名。若是本项设置为“false”或者未设置，全部的做业拥有一个共享的默认队列，名为“default”。默认值为true.若是一个队列的放置策略已经在分配文件中指定，本属性将会被忽略。
yarn.scheduler.fair.preemption	是否使用抢占。默认是false。
yarn.scheduler.fair.preemption.cluster-utilization-threshold	启动抢占后的资源利用率阈值。利用率是计算全部资源中容量使用的最大比率。 默认值是0.8f。
yarn.scheduler.fair.sizebasedweight	是否基于独立app的大小为其分配共享资源，而不是不顾全部app的大小都分配相等的共享资源。当设置为true时，app的权重是app的全部请求内存的天然对数加权，除以以2为底的天然对数。默认值为false.
yarn.scheduler.fair.assignmultiple	是否容许一次心跳中进行多容器分配。默认是false.
yarn.scheduler.fair.max.assign	若是assignmultiple 设置为true，一次心跳最多分配的容器数量。默认为-1，表示不限制。
yarn.scheduler.fair.locality.threshold.node	对于请求在特定节点的容器的apps，自从最后一次容器分配以后等待接受配置到其余节点的调度机会次数。表达式为0到1之间的浮点数，做为集群大小的因子，是错过的调度机会。默认值为-1.0意思是不错过任何调度机会。 当应用程序请求某个节点上资源时，它能够接受的可跳过的最大资源调度机会。当按照分配策略，可将一个节点上的资源分配给某个应用程序时，若是该节点不是应用程序指望的节点，可选择跳过该分配机会暂时将资源分配给其余应用程序，直到出现知足该应用程序需的节点资源出现。一般而言，一次心跳表明一次调度机会，而该参数则表示跳过调度机会占节点总数的比例，默认状况下，该值为-1.0，表示不跳过任何调度机会。
yarn.scheduler.fair.locality.threshold.rack	对于请求在特定机架的容器的apps，自从最后一次容器分配等待接受配置到其余机架的调度机会数量。表达式为0到1之间的浮点数，做为集群大小的因子，是错过的调度机会。默认值为-1.0意思是不错过任何调度机会。
yarn.scheduler.fair.allow-undeclared-pools	若是设置为true，application提交时能够建立新的队列，要么是由于application指定了队列，或者是按照user-as-default-queue放置到相应队列。若是设置为false，任什么时候间一个app要放置到一个未在分配文件中指定的队列，都将被放置到“default”队列。默认是true。若是一个队列放置策略已经在分配文件中指定，本属性将会被忽略。
yarn.scheduler.fair.update-interval-ms	默认值500ms，锁住调度器从新进行计算做业所需资源的间隔

 

Allocation file格式

 

分配文件必须是XML格式。格式包含5类元素：

• 队列元素：描述队列。队列元素能够设定一个可选的属性‘type’，当它设置为‘parent’时表示它是一个父队列。当咱们想建立一个父队列可是不想配置任何子队列时能够采用这种方式。每一个队列元素能够包含下面的属性：

• • minResources:  队列有权享有的最小资源，采用"X mb, Y vcores”"的形式。对于单一资源公平策略，vcores的值将被忽略。若是一个队列的最小共享未能获得知足，那么它将会在相同parent下其余队列以前得到可用资源。在单一资源公平策略下，一个队列若是它的内存使用量低于最小内存值则认为是未知足的。在DRF策略下，若是一个队列的主资源是低于最小共享的话则认为是未知足的。若是有多个队列未知足的状况，资源分配给相关资源使用量和最小值之间比率最小的队列。注意一点状况，有可能一个队列处于最小资源之下，可是在它提交application时不会马上达到最小资源，由于已经在运行的job会使用这些资源。
  • maxResources: 一个队列容许的最大资源，采用“X mb, Y vcores”的形式。对于单一资源公平策略，vcores的值会被忽略。一个队列永远不会分配资源总量超过这个限制。
  • maxRunningApps: 限制队列一次运行的apps数量。
  • maxAMShare：限制队列用于运行Application Master的资源比例。这个属性只能用于叶子队列。好比，若是设置为1.0f，那么在这个队列的AMs能够占用100%的内存和CPU的公平共享。这个值为-1.0f将会禁用该特性而且amShare不会进行校验。默认值是0.5f。
  • weight: 与其余队列非比例的分享集群。权重默认是1，权重是2的队列将会收到接近默认权重2倍的资源。
  • schedulingPolicy：任一队列均可以设置调度策略。容许的值包括“fifo”，“fair”，“drf”或者其余任何继承org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy的类。默认是“fair”。若是为"fifo"，提交时间较早的apps优先分配容器，可是若是集群在知足较早的apps请求以后剩余足够的空间，提交较晚的apps可能并发运行。
  • aclSubmitApps：能够提交apps到队列的用户或者组的列表。要得到更多信息能够参考下面的ACLs部分，关于列表的格式和ACLs如何发挥做用。
  • aclAdministerApps：能够管理队列的用户或者组列表。当前惟一的管理动做就是杀死应用程序。要得到更多信息能够参考下面的ACLs部分，关于列表的格式和ACLs如何发挥做用。
  • minSharePreemptionTimeout：队列处在最小共享之下，在尝试抢占其余队列的资源以前的秒数。若是不设置，队列将会总其父队列继承这个值。
  • fairSharePreemptionTimeout：队列处在最小公平共享阈值之下，在尝试抢占其余队列的资源以前的秒数。若是不设置，队列将会总其父队列继承这个值。
  • fairSharePreemptionThreshold：队列的公平共享抢占阈值。若是队列等待fairSharePreemptionTimeout以后没有接收到fairSharePreemptionThreshold*fairShare的资源，它被容许从其余队列抢占资源。若是不设置，队列将会总其父队列继承这个值。

• User elements：设置对单独用户行为的管理。它们能够包含单一属性：maxRunningApps，对特定用户能够运行的apps的数量限制。

• A userMaxAppsDefault element：设置任意用户（没有特定限制的用户）运行app的默认最大数量限制。

• A defaultFairSharePreemptionTimeout element：设置root队列的公平共享抢占的默认超时时间；能够被root队列下的fairSharePreemptionTimeout 设置覆盖。

• A defaultMinSharePreemptionTimeout element：设置root队列的默认最小共享抢占超时时间；能够被root队列下minSharePreemptionTimeout覆盖。

• A defaultFairSharePreemptionThreshold element：设置root队列的公平共享抢占的默认阈值；能够被root队列下的fairSharePreemptionThreshold 覆盖。

• A queueMaxAppsDefault element：设置队列的默认运行app数量限制；能够被任一队列的maxRunningApps元素覆盖。

• A queueMaxAMShareDefault element:设置队列的默认AM共享资源限制；能够被任一队列的maxAMShare 元素覆盖。

• A defaultQueueSchedulingPolicy element：设置队列的默认调度策略；能够在任一队列中设置schedulingPolicy 进行覆盖该默认值。默认值为“fair”。

• A queuePlacementPolicy element:包含一个Rule元素列表用于告诉调度器如何放置app到队列。Rule生效顺序与列表中的顺序一致。Rule能够含有参数。全部Rule接受"create"参数，用于标明该规则是否可以建立新队列."Create"默认值为true;若是设置为false而且Rule要放置app到一个allocations file没有配置的队列，那么继续应用下一个Rule。最后的Rule毫不能执行Continue。合法的规则是：

  • specified：app放置到它请求的队列。若是没有请求队列，例如它指定"default",执行continue。若是app请求队列以英文句点开头或者结尾，例如 “.q1” 或者 “q1.” 将会被拒绝.
  • user:app按照提交用户名放置到同名的队列。用户名中的英文句点将会被“_dot_”替换，如对于用户"first.last"的队列名是"first_dot_last".
  • primaryGroup:app放置到与提交用户primary group同名的队列。用户名中的英文句点将会被“_dot_”替换，如对于组"one.two"的队列名是"one_dot_two".
  • secondaryGroupExistingQueue：app放置到与提交用户所属的secondary group名称相匹配的队列。第一个与配置相匹配的secondary group将会被选中。组名中的英文句点会被替换成“_dot_”,例如用户使用“one.two”做为他的secondary groups将会放置到“one_dot_two”队列，若是这个队列存在的话。
  • nestedUserQueue: app放置到根据队列中嵌套规则建议的用户名同名的队列中。这有些相似于UserRule，在‘nestedUserQueue’规则中不一样的是用户队列能够建立在任意父队列下，而'user'规则只能在root队列下建立用户队列。有一点须要注意，nestedUserQueue 规则只有在嵌入规则返回一个父队列时才会生效。用户能够经过设置 队列的‘type’属性为 ‘parent’ 来配置父队列，或者在队列下至少配置一个叶子。
  • default: app放置到default规则中指定的 ‘queue’属性对应的队列。若是 ‘queue’属性没有指定，app放置到 ‘root.default’ 队列.
  • reject:拒绝app.

  如下给出 allocation file的一个样例：

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>

  <!-- Queue 'secondary_group_queue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  </queue>
  
  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>
  
  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

为了保持与原始的FairScheduler的向后兼容，“queue”元素能够用名为“pool”的元素替代.

 

队列访问控制列表

访问控制列表(ACLs)容许管理员控制谁能对特定队列执行操做。这些用户经过aclSubmitApps 和aclAdministerApps属性配置，能够设置在每一个队列上。当前惟一支持的管理性操做就是杀死app。任何可以管理管理的人也均可以向该队列提交app.这些属性的值像 “user1,user2 group1,group2” 或者“ group1,group2”的格式。若是用户或者组是在队列的ACLs中或者在这个队列的任意祖先的ACLs中，那么他对该队列的操做是被容许的。因此，若是queue2 在queue1内部，而且user1 在queue1的ACL中，user2 在queue2的ACL中，那么两个用户均可以向queue2提交app.

备注：分隔符是空格。要只是指定ACL组，该值须要以空格开头.

root队列的ACLs默认是"*"，由于ACLs是向下传递的，意思是每一个用户均可以对每个队列提交和杀死App。要启动严格的方访问，修改root队列的ACL为除"*"以外的其余值.

管理

Fair Scheduler经过一些机制提供运行时的管理功能：

 

运行时修改配置

经过编辑allocation file能够在运行时完成修改最小共享，资源限制，权重，超时抢占以及队列调度策略等。调度器会每一个10-15秒重载修改后的该配置文件.

 

经过web UI进行监控

当前应用、队列以及公平共享均可以经过ResourceManager的web UI查看，地址在http://*ResourceManager URL*/cluster/scheduler。

 

在web UI上能够看到每一个队列的如下字段：

• Used Resources-队列已经分配的容器的资源之和。

• Num Active Applications-队列中已经接受到至少一个容器的应用程序数量。

• Num Pending Applications-队列中尚未接受任何一个容器的应用程序的数量。

• Min Resources-配置的授予队列的最小资源。

• Max Resources - 配置的队列容许的最大资源.

• Instantaneous Fair Share - 队列的资源的瞬时公平共享。这些共享只考虑活动的队列（那些有运行中程序的），并且被调度决策所使用。当其余队列没有使用某些资源时，队列能够被分配到超过他shares的资源。一个队列的资源消费处在或者低于它的瞬时公平份额将不会有容器被抢占。

• Steady Fair Share-队列的固定公平份额，不管这些队列是否活跃。他们不多被计算和修改，除非配置或者容量发生变化。他们意思是提供资源可视化。

队列间移动应用程序

Fair Scheduler 支持移动一个运行中的应用程序到另一个队列。这个能够用于移动一个重要的应用程序到较高优先级队列，或者移动一个不重要的应用程序到一个较低优先级的队列。经过运行 yarn application -movetoqueue appID -queue targetQueueName能够移动运行中的应用程序。

当应用程序移动到一个队列，出于公平考虑，它的现存的分配计算会变成新队列的资源分配。若是加入被移动的应用程序的资源超出目标队列的maxRunningApps 或者maxResources 限制，本次移动将会失败。