大数据技术 yarn的学习之2-容量调度器和预订系统-职坐标

大数据技术 yarn的学习之2-容量调度器和预订系统

沉沙 2018-09-29 来源：阅读 1755 评论 0

摘要：本篇教程探讨了大数据技术 yarn的学习之2-容量调度器和预订系统，希望阅读本篇文章以后大家有所收获，帮助大家对大数据技术的理解更加深入。

本篇教程探讨了大数据技术 yarn的学习之2-容量调度器和预订系统，希望阅读本篇文章以后大家有所收获，帮助大家对大数据技术的理解更加深入。

1、目的

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

2、概览

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

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

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

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

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

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

注：

    sla,这里并非指hadoop的服务级别授权，而是指“服务级别协议”，具体可以参考//www.sohu.com/a/111043704_120672  ，但可以简单理解为“需求”
    这个小节的中心思想就是: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..queues。子队列并不继承上级队列的属性，除非有特别说明。

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

  yarn.scheduler.capacity.root.queues
  a,b,c
  The queues at the this level (root is the root queue).


  yarn.scheduler.capacity.root.a.queues
  a1,a2
  The queues at the this level (root is the root queue).


  yarn.scheduler.capacity.root.b.queues
  b1,b2,b3
  The queues at the this level (root is the root queue).


4.2 队列属性

    资源分配

属性描述
yarn.scheduler.capacity..capacity

容量百分比，可以有小数位。但所有队列的和必须是100。但如果系统有空闲资源，队列中的应用实际是可能耗费比限定的份儿跟多的资源，这就是弹性。
yarn.scheduler.capacity..maximum-capacity

队列允许使用的最大份额百分比。默认-1，就是不允许。
yarn.scheduler.capacity..minimum-user-limit-percent

队列中用户的资源下限（百分比-但必须是整数）。用户实际使用的资源可能介于两个限制点之间。一个队列可能包含了多个用户的应用，那么如果一个队列有2个提交了应用的用户，

那么可以限制50,3个就是33,3个就是25，诸如此类。如果设置为100（默认），那么就是不做限制，这样占先用。
yarn.scheduler.capacity..user-limit-factor

定义某个用户可以使用的容量倍数。默认是1，就是队列容量的全部。这个值可以带小数。

注：这应该是一个<=1的值。
yarn.scheduler.capacity..maximum-allocation-mb

资源可以管理器分配给容器的最大内存（分配对队列的最大内存）。这个设置会覆盖 yarn.scheduler.maximum-allocation-mb。但必须小于等于集群的最大限额。
yarn.scheduler.capacity..maximum-allocation-vcores

最大的虚拟核(virtual core).覆盖 yarn.scheduler.maximum-allocation-vcores，但必须小于等于后者。

     运行和挂起应用

Property Description

yarn.scheduler.capacity.maximum-applications

yarn.scheduler.capacity..maximum-applications

系统并发的正在运行和挂起的应用总数，默认是10000.

yarn.scheduler.capacity..maximum-applications可以覆盖

yarn.scheduler.capacity.maximum-applications的值，但值只能小于等于后者。

取值为整数。

yarn.scheduler.capacity.maximum-am-resource-percent

yarn.scheduler.capacity..maximum-am-resource-percent

am可以使用的最大资源百分比（用于并发的活动应用）。取值为浮点数，例如0.5，表示50%。

yarn.scheduler.capacity..maximum-am-resource-percent可以覆盖

yarn.scheduler.capacity.maximum-am-resource-percent，但取值必须小于等于后者。

        注：每一行，有两个属性

    队列管理和权限

Property Description
yarn.scheduler.capacity..state

设置队列的状态，可以是RUNNING/STOPPED.如果是后者，则队列不能增加新应用，但现有运行得应用可以一致运行到结束。
yarn.scheduler.capacity.root..acl_submit_applications

队列提交应用权限列表acl--控制谁可以提交应用。如果用户/组有队列（或者升级队里的）acl权限，那么就可以提交应用。

如果没有设定，那么从其上级继承。
yarn.scheduler.capacity.root..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.

注：没有说明如何覆盖

     例子：


        yarn.scheduler.capacity.queue-mappings
       u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group

         Here,  is mapped to ,  is mapped to ,
         maps users to queues with the same name as user,  is mapped
         to queue name same as  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主组名称一样的队列上。



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

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..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..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,但又没有定义，那么任何人都可以操作。

在下面这个例子中，是队列名称。
Property Description
yarn.scheduler.capacity.root.default.acl_administer_reservations  设置默认队列的管理acl
yarn.scheduler.capacity.root..acl_administer_reservations

这个ACL具有全部权限：创建，删除，修改和列出。这个权限不继承上级的，除非有特定说明（注：如何特别说明）

注：文档并没有给出acl的示例。但根据本文多次出现过的经验来看，也许是“u:user1:queue1,g:group1:queue2”这样形式的。
yarn.scheduler.capacity.root..acl_list_reservations

查看权限。

这个权限不继承上级的，除非有特定说明（注：如何特别说明）
yarn.scheduler.capacity.root..acl_submit_reservations

提交（创建）

这个权限不继承上级的，除非有特定说明（注：如何特别说明）

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

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..reservable

是否可以预订（非空）

默认false(不可以）

注：因为设置就是为了预订，所以一般设定为true
yarn.scheduler.capacity..reservation-agent

预订代理（类名），用于确定预订代理是否已经实现。

默认值：org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy.
yarn.scheduler.capacity..reservation-move-on-expiry

可选参数

当有关的预订过期后，应用是否要移动到上级可预订的队列（或者是被杀掉）

默认是true.
yarn.scheduler.capacity..show-reservations-as-queues

可选参数

是否在调度器UI中显示预订队列。

默认false（不显示）
yarn.scheduler.capacity..reservation-policy

预订策略类（可选参数）

用于确定共享策略是否实现了，这个共享策略负责验证新的预订没有破坏标准。

默认值是org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy.
yarn.scheduler.capacity..reservation-window

预留窗口(可选参数）

单位毫秒（必须是整数）

共享策略类在这个窗口内会验证计划中约束是否通过。

默认是1天（86400000)
yarn.scheduler.capacity..instantaneous-max-capacity

瞬间最大容量（可选参数）

实际是任意时间，单位是比率（但不是百分比）

共享策略允许单个用户保留的最大容量

默认是1，也就是100%.
yarn.scheduler.capacity..average-capacity

平均容量（可选参数）

在预订窗口内，共享策略允许单个用户保留的平均容量。

默认是1（100%）
yarn.scheduler.capacity..reservation-planner

预订计划执行程序（类，可选）

用于确认计划程序的实现情况，如果计划容量低于用于预订的，那么这个类会被激活。

默认值 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner

这个类被激活后，会扫描计划，并按照LIFO的顺序尽可能地移除预留的容量，直到预留的资源达到了计划要求。

注：LIFO--即后进先出。
yarn.scheduler.capacity..reservation-enforcement-window

预留强制窗口（可选）

计划程序在这个时间窗口内，会验证计划限定是否被满足了。

整数类型，单位毫秒

默认是1小时即3600000

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

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

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

  预订系统更多的内容可以参阅 //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集群吗？

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 系统包含适应/脱离集群容量的机制。包括如果可能就移动预留，或者拒绝一些最小量的请求