yarn的学习之2-容量调度器和预订系统

本文翻译自 http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html

和http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html

1、目的

本文主要描述容量调度器，它是一个可拔插的插件，负责为所有的应用按照特定的限制分配资源。

2、概览

cs（译注：为了便于写，把CapacitiesScheduler编写为cs)的目的就是能够让hadoop应用以操作员友好的方式运行，并能够最大化集群的吞吐和利用。

以往，每个组织都有自己私有的计算资源，并且这些资源具有足够的容量来满足不同时段组织的SLA。这通常会导致交叉的平均利用，并会让管理有点不堪重负，因为如果组织多的话，那么集群也会很多。在不同组织之间共享hadoop集群是比较划算的行为，因为不需要创建私有的集群。然后，每个组织都会关心共享的事情，因为大家都担忧其他组织过分使用集群资源。

cs能够让应用共享集群，并保证应用的资源需求（译注：保证各个应用预先分配的资源，例如不会用着用着，然后发生cpu都被其它应用霸占了之类的事情.并不是说能够让每个应用都可以畅快地使用所有的资源)。中心思想就是共享。此外还有一个不一样的好处，某个时刻某个组织可以使用其它其它组织的资源--换言之，组织可以弹性利用资源。

cs提供一系列严格的限制来确保单个的应用/用户/队列无法消费过量的资源。此外，cs对用户或者队列的初始/挂起应用做某种限制，这样可以确保集群的公平和稳定。

cs的首要概念是队列(queues).这些队列由管理员设置，队列可以实现共享集群的共享经济。

为了提供对资源的进一步的控制，和共享的可预见性，cs支持分层队列（译注：原文hierarchical ），确保在其它队列可以利用空闲资源之前，特定组织的队列（包括子队列）可以共享资源，由此特定组织的的应用可以更好地共享空闲资源。

译注：

1. sla,这里并非指hadoop的服务级别授权，而是指“服务级别协议”，具体可以参考http://www.sohu.com/a/111043704_120672  ，但可以简单理解为“需求”
2. 这个小节的中心思想就是:cs,共享，队列，分层队列，确保

3、特性

• Hierarchical Queues - 分层队列。确保在其它队列可以利用空闲资源之前，特定组织的队列（包括子队列）可以共享资源，由此特定组织的的应用可以更好地共享空闲资源

• Capacity Guarantees -容量保证。系统分配给队列分配容量的一部分，这部分就归特定队列处置。队列中的应用都可以访问分配给队列的容量。管理员可以为队列配置软限制和可选的硬限制

• Security -安全。每个队列都有严格的ACLs，acls控制谁可以提交应用到队列中。此外，一个用户不能看/修改其它用户队列的应用。

• Elasticity - 弹性。任何队列可以利用空闲资源，即使已经超过了自身的限额。

• Multi-tenancy - 多租户。有各种设置来保证资源不会被独占，大家可以共享。

• Operability  --可操作

  • 运行时配置 - 队列定义和属性（如容量），ACLS可以在运行时由管理员以安全的方式修改。此外为管理员和用户提供了一个控制台，通过控制台可以查看当前资源的分配。管理员可以在运行时添加队列，但不能删除正在运行的队列。（译注：如果这样，只能先停止应用了或者先停止队列）
  • 释放应用- 管理员可以在运行时stop队列，但正在运行得应用可以一致运行到完成，而新的应用不能加入队列。如果队列处于STOPPED状态，那么就无法添加新应用到队列或者子队列上。这样管理员可以优雅地停止队列.  此外，管理员可以启动正在停止中(STOPPED)的队列.

• Resource-based Scheduling（基于资源的调度） - 支持资源密集应用（译注：简而言之就是可以不同需求给予不同资源）. 目前支持的资源只有内存。

• Queue Mapping based on User or Group - 基于用户/组的队列映射  。换言之，不同的用户或者组所提到的作业会对应到不同队列，适当程度简化了操作。

• Priority Scheduling 优先权调度-  不同应用可以按照不同的优先权调度。应用的优先权值越大，优先级越高。目前，应用优先权只支持FIFO策略。译注：应该指的是在先按照优先权排序的情况下，最大优先权的的可以进入FIFO堆栈，但绝对不能插队。

4、配置

4.0 使用容量调度器

修改yarn-site.xml

yarn.resourcemanager.scheduler.class    取值  org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

4.1 配置队列

etc/hadoop/capacity-scheduler.xml

cs有个预定义的队列root。所有的队列都是这个队列的子队列。

其它队列可以通过yarn.scheduler.capacity.root.queues配置，多个队列以逗号分隔。

使用队列路径来设定队列的层级。队列路径必须是全路径，以root开始，使用点号作为分隔符。

特定的子队列可以使用以下形式定义yarn.scheduler.capacity.<queue-path>.queues。子队列并不继承上级队列的属性，除非有特别说明。

以下是一个例子，有3个顶级子队列a,b,c。a，b有一些子队列：

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>a,b,c</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.queues</name>
  <value>a1,a2</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.b.queues</name>
  <value>b1,b2,b3</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

4.2 队列属性

• 资源分配

属性	描述
yarn.scheduler.capacity.<queue-path>.capacity	容量百分比，可以有小数位。但所有队列的和必须是100。但如果系统有空闲资源，队列中的应用实际是可能耗费比限定的份儿跟多的资源，这就是弹性。
yarn.scheduler.capacity.<queue-path>.maximum-capacity	队列允许使用的最大份额百分比。默认-1，就是不允许。
yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent	队列中用户的资源下限（百分比-但必须是整数）。用户实际使用的资源可能介于两个限制点之间。一个队列可能包含了多个用户的应用，那么如果一个队列有2个提交了应用的用户， 那么可以限制50,3个就是33,3个就是25，诸如此类。如果设置为100（默认），那么就是不做限制，这样占先用。
yarn.scheduler.capacity.<queue-path>.user-limit-factor	定义某个用户可以使用的容量倍数。默认是1，就是队列容量的全部。这个值可以带小数。 译注：这应该是一个<=1的值。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb	资源可以管理器分配给容器的最大内存（分配对队列的最大内存）。这个设置会覆盖 yarn.scheduler.maximum-allocation-mb。但必须小于等于集群的最大限额。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores	最大的虚拟核(virtual core).覆盖 yarn.scheduler.maximum-allocation-vcores，但必须小于等于后者。

• 运行和挂起应用

Property	Description
yarn.scheduler.capacity.maximum-applications yarn.scheduler.capacity.<queue-path>.maximum-applications	系统并发的正在运行和挂起的应用总数，默认是10000. yarn.scheduler.capacity.<queue-path>.maximum-applications可以覆盖 yarn.scheduler.capacity.maximum-applications的值，但值只能小于等于后者。 取值为整数。
yarn.scheduler.capacity.maximum-am-resource-percent yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent	am可以使用的最大资源百分比（用于并发的活动应用）。取值为浮点数，例如0.5，表示50%。 yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent可以覆盖 yarn.scheduler.capacity.maximum-am-resource-percent，但取值必须小于等于后者。

译注：每一行，有两个属性

• 队列管理和权限

Property	Description
yarn.scheduler.capacity.<queue-path>.state	设置队列的状态，可以是RUNNING/STOPPED.如果是后者，则队列不能增加新应用，但现有运行得应用可以一致运行到结束。
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications	队列提交应用权限列表acl--控制谁可以提交应用。如果用户/组有队列（或者升级队里的）acl权限，那么就可以提交应用。 如果没有设定，那么从其上级继承。
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue	控制谁可以管理队列的应用。 其它方式同上一行属性。 译注：原文没有说如何管理。停止，删除？

注：这个acl的格式不同于hdfs文件的acl格式。*表示任何人，space表示没有人。对于root队列来说，如果没有设定，默认是*

• 基于用户/组的队列隐射

Property	Description
yarn.scheduler.capacity.queue-mappings	语法 [u or g]:[name]:[queue_name][,next_mapping]* 列表可以多个，之间以逗号分隔。 %user放在[name]部分，表示已经提交应用的用户。 如果队列名称和用户一样，那可以使用%user表示队列。 如果队列名称和用户主组一样，可以使用%primary_group表示队列。 译注：这个语法有点怪异
yarn.scheduler.capacity.queue-mappings-override.enable	定义针对特定用户的队列是否可以被覆盖。默认是false. 译注：没有说明如何覆盖

例子：

<property>
        <name>yarn.scheduler.capacity.queue-mappings</name>
       <value>u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group</value>
      <description>
         Here, <user1> is mapped to <queue1>, <group1> is mapped to <queue2>,
         maps users to queues with the same name as user, <user2> is mapped
         to queue name same as <primary group> respectively. The mappings will be
        evaluated from left to right, and the first valid mapping will be used.

u:%user:%user  ---已经提交应用的用户，映射到和用户名称一样的队列上。

u:user2:%primary_group --user2提交的应用映射到user2主组名称一样的队列上。        
      </description>
    </property>

译注：如果用户组并不多，队列也不多，建议还是使用简单的语法，而不要使用带%的，后者有点混，而且还不知道是否会导致异常。

4.3 配置应用优先权

应用优先和FIFO排序策略一起工作。

Default priority for an application can be at cluster level and queue level.

应用的默认优先权可以设定集群或者队列级别。

• 集群级别 : 定义了整个集群的最大优先权（整数值），具体原因的优先全如果大于它，那么就以集群最大优先权为准。.  $HADOOP_HOME/etc/hadoop/yarn-site.xml 配置了这个值.

Property	Description
yarn.cluster.max-application-priority	Defines maximum application priority in a cluster.

• 叶子队列级别 : $HADOOP_HOME/etc/hadoop/capacity-scheduler.xml 可以配置这个叶子级别的。

Property	Description
yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority	Defines default application priority in a leaf queue.

注意: 如果应用移动到不同的队列，其优先权不会改变

4.4 容量调度容器抢占

cs支持容器抢占，就是如果有一些队列使用了超限的资源，那么这些超限的资源是可以被抢走的。

• yarn-site.xml 的配置

Property	Description
yarn.resourcemanager.scheduler.monitor.enable	启用监视程序。默认不启用 译注：应该设置为true
yarn.resourcemanager.scheduler.monitor.policies	监视策略 默认值是 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy

如果yarn.resourcemanager.scheduler.monitor.policies的取值是org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy

• 那么可以配置一下属性（同样是在yarn-site.xml中）

Property	Description
yarn.resourcemanager.monitor.capacity.preemption.observe_only	眼观手不动-不抢也不杀事件。默认是false. 译注：应该设置为true
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval	监视间隔（轮询/扫描间隔），默认是3000毫秒。
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill	从发出抢占请求到杀掉容器的时间，默认是15000毫秒
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round	一个回合中，抢占的最大的资源百分比。通过控制这个值，就可以限制从集群申请容器的步伐。 在计算总的期望抢占（需求）后，策略会要求总和必须小于=这个值。默认是0.1 译注：这个比率必须乘以100，才是百分比。
yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity	如果无法抢占那么多，那么可以少抢多少？ 这个值积极的一面是可以防止可能无法抢到。 如果这个值比较高，那么可能无法那么快抢到需要的容量。默认是0.1
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor	自然终止抢占百分比(差额）. 对于一个计算过的抢占， 由于容器自然过期，那么就只会抢占这个比率的差额。 这个确定了几何比率（这个比率和MAX_IGNORED_OVER_CAPACITY有关）。 李I如，如果因子是0.5(就是5%），那么差额就是95%. 那么在 5 * #WAIT_TIME_BEFORE_KILL间隔内，就会申请几乎95%的资源，即使没有自然终止（其它的应用或者容器）。 默认值是0.2（2%）。 译注：这个定义挺奇怪的。

• capacity-scheduler.xml 中关于已经属于队列的应用容器抢占配置 。

Property	Description
yarn.scheduler.capacity.<queue-path>.disable_preemption	是否禁止抢占已经属于队列的应用容器。 仅当以下两个属性设置如下的时候，本属性才启用： yarn.resourcemanager.scheduler.monitor.enable = true yarn.resourcemanager.scheduler.monitor.policies = org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy 如果特定队列没有设定，就从上级队列继承。 默认是false(译注：就是可以抢)

• 保留管理

cs可以通过参数来控制创建，删除，更新和列出预留信息。注意，任何人都可以这么做，只要有权限（自己的可以操纵自己的）。如果有启用预留acl,但又没有定义，那么任何人都可以操作。

在下面这个例子中，<queue>是队列名称。

Property	Description
yarn.scheduler.capacity.root.default.acl_administer_reservations	设置默认队列的管理acl
yarn.scheduler.capacity.root.<queue>.acl_administer_reservations	这个ACL具有全部权限：创建，删除，修改和列出。 这个权限不继承上级的，除非有特定说明（译注：如何特别说明） 译注：文档并没有给出acl的示例。但根据本文多次出现过的经验来看，也许是“u:user1:queue1,g:group1:queue2”这样形式的。
yarn.scheduler.capacity.root.<queue>.acl_list_reservations	查看权限。 这个权限不继承上级的，除非有特定说明（译注：如何特别说明）
yarn.scheduler.capacity.root.<queue>.acl_submit_reservations	提交（创建） 这个权限不继承上级的，除非有特定说明（译注：如何特别说明）

译注：上表的属性中包含了<queue>而不是<queue-path>,当时原文作者的疏忽所致。本人认为，这应该修改为<queue-path>更好，更容易理解，也可以保持全文一致。

4.5 使用容量调度器配置预订系统

cs支持预订系统-允许用户预留资源。

应用可以在运行时（提交）设定 reservationId，以请求保留的资源。

• yarn-site.xml 中的配置

Property	Description
yarn.resourcemanager.reservation-system.enable	是否启用预订(非空） 默认为否(false) 取值true/false
yarn.resourcemanager.reservation-system.class	预订类（可选） 如果没有设置，就直接取 yarn-site.xml中yarn.resourcemanager.scheduler.class属性值。 译注：cs的话，就取 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
yarn.resourcemanager.reservation-system.plan.follower	PlanFollower类名，用于定时同步cs（可选参数） 取值和yarn.resourcemanager.scheduler.class属性值有关。 如果cs，那么取值org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacitySchedulerPlanFollower
yarn.resourcemanager.reservation-system.planfollower.time-step	PlanFollower定时器的间隔(毫秒-整数，可选参数）。 默认是1000毫秒

• capacity-scheduler.xml中的配置

cs支持预订，而且可以在任意叶子队列上配置。

Property	Description
yarn.scheduler.capacity.<queue-path>.reservable	是否可以预订（非空） 默认false(不可以） 译注：因为设置就是为了预订，所以一般设定为true
yarn.scheduler.capacity.<queue-path>.reservation-agent	预订代理（类名），用于确定预订代理是否已经实现。 默认值：org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.
yarn.scheduler.capacity.<queue-path>.reservation-move-on-expiry	可选参数 当有关的预订过期后，应用是否要移动到上级可预订的队列（或者是被杀掉） 默认是true.
yarn.scheduler.capacity.<queue-path>.show-reservations-as-queues	可选参数 是否在调度器UI中显示预订队列。 默认false（不显示）
yarn.scheduler.capacity.<queue-path>.reservation-policy	预订策略类（可选参数） 用于确定共享策略是否实现了，这个共享策略负责验证新的预订没有破坏标准。 默认值是org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.
yarn.scheduler.capacity.<queue-path>.reservation-window	预留窗口(可选参数） 单位毫秒（必须是整数） 共享策略类在这个窗口内会验证计划中约束是否通过。 默认是1天（86400000)
yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity	瞬间最大容量（可选参数） 实际是任意时间，单位是比率（但不是百分比） 共享策略允许单个用户保留的最大容量 默认是1，也就是100%.
yarn.scheduler.capacity.<queue-path>.average-capacity	平均容量（可选参数） 在预订窗口内，共享策略允许单个用户保留的平均容量。 默认是1（100%）
yarn.scheduler.capacity.<queue-path>.reservation-planner	预订计划执行程序（类，可选） 用于确认计划程序的实现情况，如果计划容量低于用于预订的，那么这个类会被激活。 默认值 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner 这个类被激活后，会扫描计划，并按照LIFO的顺序尽可能地移除预留的容量，直到预留的资源达到了计划要求。 译注：LIFO--即后进先出。
yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window	预留强制窗口（可选） 计划程序在这个时间窗口内，会验证计划限定是否被满足了。 整数类型，单位毫秒 默认是1小时即3600000

译注：具体如何预订，并不是仅仅这几个参数。实际实现的时候，还需要结合一些其它操作,例如yarn关于rm的REST API

也许以后，yarn自己会提供cli工具直接申请预订并提交作业，目前来看，需要通过编程来实现。

但很多时候，如果不直接使用yarn的话，也不需要考虑这个，例如使用spark,presto的时候，它们可以和yarn一起部署。

预订系统更多的内容可以参阅http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html

4.6 其它属性

• 资源计算器

Property	Description
yarn.scheduler.capacity.resource-calculator	资源计算器类-比较调度器中的资源。 例如org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator仅仅计算内存，而DominantResourceCalculator会使用内存，cpu等等。 译注：目前还是使用 org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator 吧。 因为有关的实现主要基于内存的。 yarn的资源管理还是比较初级的。

• 数据本地性

Property	Description
yarn.scheduler.capacity.node-locality-delay	节点局部性延迟 在cs企图调度本地机栈容器后(失败），还可以错过错过多少次的调度次数。 通常设置为集群节点数。 默认情况下，应该设置为基站中节点数，例如40（一个机栈可能有40台）。 译注：调度器在本地机栈找资源，可以在机栈内的节点一个个找过去。所以可以尝试那么多次。 由于没有看有关的代码，并不清楚具体如何一个个找的。

4.7 回顾容量调度器配置

一旦按照配置完毕，这些配置可以通过yarn的WEB-UI来查看：

• 以常规模式启动yarn

• 打开rm的web-ui

• 找到 /scheduler 页面，就可以看到队列和有关资源.

5、修改队列配置

修改队列属性，添加队列是非常简单。只需要编辑conf/capacity-scheduler.xml,并执行 yarn rmadmin -refreshQueues

$ vi $HADOOP_CONF_DIR/capacity-scheduler.xml
$ $HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues

注意:  队列不能删除，但可以添加新的，更新也是可以的。  

译注：不需要修改所有节点上的，因为rmadmin会自动做那个事情。此外如何删除队列？难道要靠重配，重启yarn集群吗？

以下内容翻译自 http://hadoop.apache.org/docs/r2.8.0/hadoop-yarn/hadoop-yarn-site/ReservationSystem.html

6、预订系统

译注：本文已经省略掉一些原文的内容

流程图

典型预订流程：

• Step 0       用户提交一个预订创建请求，并接收到一个响应，响应包含一个ReservationId（预订ID)

• Step 1      用户提交一个预订请求（使用 Reservation Definition Language (RDL) --预定定义语言）和预订ID，请求包括诸如资源和暂时约束（例如截止时间）。这个提交可以使用编程方式完成，编程方式包括使用客户端到RM的协议或者RM REST api  。如果相同的RDL内容和预订ID提交做了多次，但是是无用的，系统不会创建新的预留，虽然系统的提示是成功的。如果仅仅RDL不同，那么会被拒绝。

• Step 2    预订系统启动一个预订代理（ReservationAgent,上图绿色的。译注：原文说绿色，但本文看到的是蓝色的），从PLAN（计划中）找一可用的分配，所谓PLAN(计划）就是一个数据结构，记录了所有已经接收的预订和系统中的可用资源。

• Step 3    共享策略提供一个途径来强制收到的预留是恒定的（至少是符合要求的），而这个收到的可能是潜在会被拒绝的。 例如，CapacityOvertimePolicy会允许用户的瞬时最大容量，但一段时间内又会做一定的限制 。例如用户的瞬时请求可以是50%的集群容量，但在24小时内，均值不能超过10% 。

• Step 4   成功验证后，预订系统会返回给用户一个预订ID（可以比作一张车票）

• Step 5   当预订时间到达，部件PlanFollower（后续计划程序）把计划的状态推送给调度器 ，推送方式是动态创建/ 调整/销毁队列。

• Step 6   然后用户可以提交一个或者多个作业给预留队列，提交的时候只需要简单地包含预订ID即可。

• Step 7  调度器会提供一些容器（这些容器已经预先创建，用于满足预订需求）。在预订限制内，用户可以随意使用资源。

• Step 8 系统包含适应/脱离集群容量的机制。包括如果可能就移动预留，或者拒绝一些最小量的请求

 译注：总体上预订的实现分为几个步骤：

      1.预订

      2.执行，包含提交计划和调整共享。

      3.脱离（完结）