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

标签：请求   经验   uri   安全   结束   port   lang   primary   格式   

本文翻译自  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 队列属性

• 资源分配

•  运行和挂起应用

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

• 队列管理和权限

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

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

     例子：

     <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 配置了这个值.

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

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

4.4 容量调度容器抢占

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

• yarn-site.xml 的配置

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

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

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

• 保留管理

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

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

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

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

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

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

•  yarn-site.xml 中的配置

• capacity-scheduler.xml中的配置

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

  译注：具体如何预订，并不是仅仅这几个参数。实际实现的时候，还需要结合一些其它操作,例如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 其它属性

• 资源计算器

• 数据本地性

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.脱离（完结）

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

标签：请求   经验   uri   安全   结束   port   lang   primary   格式   

原文地址：http://www.cnblogs.com/lzfhope/p/7081754.html