admin管理员组

文章数量:1612065

目录

    • CapacityScheduler
      • 1 CapacityScheduler介绍
      • 2 启用CapacityScheduler
      • 3 设置队列
        • 3.1 队列特性
        • 3.2 队列间调度
        • 3.3 ACLs控制队列权限
      • 4 定义队列映射策略Mapping Policies
        • 4.1 为用户和组配置到特定队列的队列映射
        • 4.2 为用户和组配置到同名队列的队列映射
        • 4.3 启用默认队列映射的重写
      • 5使用队列管理群集资源
      • 6 设置队列优先级
      • 7 资源分配流程
      • 8 资源分配流程示例
      • 9 设置User Limits
      • 10 应用资源预约Application Reservations
      • 11 设置灵活的调度策略
        • 11.1 FIFO and Fair Sharing 策略示例
        • 11.2 配置队列排序策略Configure Queue Ordering Policies
        • 11.3 排序策略的最佳实践Best Practices for Ordering Policies
      • 12 启动和停止队列Start and Stop Queues
      • 13 设置应用程序限制 Set Application Limits
      • 14 启用抢占 Enable Preemption
        • 14.1 抢占工作流程 Preemption Workflow
        • 14.2 配置抢占 Configure Preemption
      • 15 启用优先级调度 Enable Priority Scheduling
      • 16 为应用程序优先级配置ACLs ACLs for Application Priorities
      • 17 启用队列内抢占 Enable Intra-Queue Preemption
        • 17.1 用于配置队列内抢占的属性 Properties for Configuring Intra-Queue Preemption
        • 17.2 基于应用优先级的队列内抢占 Intra-Queue Preemption Based on Application Priorities
        • 17.3 基于用户限制的队列内抢占 Intra-Queue Preemption based on User Limits

CapacityScheduler

内容来自HDP3.1.4

1 CapacityScheduler介绍

可以在用户和用户组间使用CapacityScheduler调度策略共享集群资源。
在yarn中最小的资源调度单元就是queue。
在CapacityScheduler下每一个队列如下属性：

  • A short queue name. 短队列名称
  • A full queue path name. 全路径队列名称
  • A list of associated child-queues and applications.
  • The guaranteed capacity of the queue. 队列的保证资源
  • The maximum capacity of the queue. 队列的最大资源
  • A list of active users and their corresponding resource allocation limits.
  • The state of the queue. 队列的状态
  • Access control lists (ACLs) governing access to the queue.

2 启用CapacityScheduler

设置ResourceManager的调度算法为CapacityScheduler

$ vi /etc/hadoop/conf/yarn-site.xml
<property>
 <name>yarn.resourcemanager.scheduler.class</name>
 <value>
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
 </value>
</property>

3 设置队列

3.1 队列特性

分层队列特性，有两种类型队列：父队列和叶队列。

  • 父队列支持跨组织和子组织管理资源。它们可以包含更多的父队列或叶队列。他们自己不直接接受任何提交的申请。
  • 叶队列是位于父队列下并接受应用程序的队列。叶队列没有任何子队列，因此没有以“.queues”结尾的任何配置属性。
  • 有一个不属于任何组织的顶级父root队列，而是表示集群本身。
  • 通过使用父队列和叶队列，管理员可以为各个组织和子组织指定容量分配。
3.2 队列间调度
  • 分层队列先确保每个组织队列的guranteed资源，如果有剩余资源先在组织的子队列之间共享，再在属于其它组织的队列共享资源。
  • root队列了解如何在第一级父队列之间分配集群容量，并在其每个子队列上调度。
  • 每个父队列都将其容量约束应用于其所有子队列。(我的理解父队列容量是所有子队列的容量的和)
  • 叶队列保存active应用程序（可能来自多个用户）的列表，并以FIFO（先进先出）的方式调度资源，同时遵守为单个用户指定的容量限制。
3.3 ACLs控制队列权限

  • 应用程序只能提交到叶队列级别，但对父队列设置的ACL限制将应用于其所有子队列。

  • 启用acl，需要/etc/hadoop/conf/yarn-site.xml中yarn.acl.enable=true默认为false。

  • acl是通过设置/etc/haoop/conf/capacity-scheduler.xml，格式"user1,user2 group1,group2",逗号分隔的user列表，一个空格，然后是逗号分隔的group列表。

      <property>
<name>yarn.scheduler.capacity.root.default.acl_submit_applications</name>
    <value>*</value>
    <description>
      The ACL of who can submit jobs to the default queue.
    </description>
  </property>

    root队列的acl_submit_applications默认值是yarn,也就是只有yarn用户可向该队列提交应用。
    acl_submit_applications的值也可以设为"*"，所有用户及用户组都可以向该队列提交应用，或者设为空格" "，禁止向该队列提交。

  • 如前所述，父队列上的ACL设置将应用于其所有子队列。因此，如果父队列使用“*”（星号）值（或未指定）允许访问所有用户和组，则其子队列不能限制访问。类似地，在限制对子队列的访问之前，必须首先将父队列设置为“”（空格字符）以阻止对所有用户和组的访问。
    如下：如果想对子队列support进行限制，必须先将父队列设为空格

    <property>
 <name>yarn.scheduler.capacity.root.acl_submit_applications</name>
 <value> </value>
</property>

<property>
 <name>yarn.scheduler.capacity.root.support.acl_submit_applications</name>
 <value>sherlock,pacioli cfo-group</value>
</property>

  • 可以使用单独的ACL来控制各级队列的管理administration。队列administrators可以提交应用到队列，终止队列中的应用，并获取队列中有关任何应用程序的信息（而普通用户不能查看其他用户应用程序的所有详细信息）。
    管理员acl是使用acl_administrate_queue属性配置的。如果未指定，则此属性的ACL将从父队列继承。例如，以下属性将root acl_administrate_queue值设置为“”（空格字符）以阻止对所有用户和组的访问，并将其子“support”队列的管理员访问权限授予用户“sherlock”和“pacioli”以及“cfo-group”组的成员：

    <property>
 <name>yarn.scheduler.capacity.root.acl_administer_queue</name>
 <value> </value>
</property>

<property>
 <name>yarn.scheduler.capacity.root.support.acl_administer_queue</name>
 <value>sherlock,pacioli cfo-group</value>
</property>

4 定义队列映射策略Mapping Policies

  • 管理员可以指定默认映射策略，即用户提交的应用程序自动提交到哪个队列。
  • 如果使用默认映射策略,用户提交应用时可不指定队列。
  • 使用多个队列映射的时候用逗号分隔，调度器按从左到右顺序处理映射，以确定先使用哪一个。
  • 队列映射定义在capacity-scheduler.xml中：
      <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value></value>
    <description>
      A list of mappings that will be used to assign jobs to queues
      The syntax for this list is [u|g]:[name]:[queue_name][,next mapping]*
      Typically this list will be used to map users to queues,
      for example, u:%user:%user maps all users to queues with the same name
      as the user.
      可以为用户（使用“u”）或一组用户（使用“g”）定义队列映射分配。
    </description>
  </property>
4.1 为用户和组配置到特定队列的队列映射
u:user1:queueA		用户user1默认提交到队列queueA
g:group1:queueB		组group1默认提交到队列queueB

<property>
  <name>yarn.scheduler.capacity.queue-mappings</name>
  <value>u:maria:engineering,g:webadmins:weblog</value>
</property>
用户meria提交的应用优先提交到队列engineering。即使meria属于组webadmins也优先提交到engineering
4.2 为用户和组配置到同名队列的队列映射
u:%user:%primary_group		指定用户将所有应用程序提交到与所在组同名的队列
u:%user:%user 				指定用户提交应用到自己同名队列

假设用两个组，marketing和engineering：
marketing: angela rahul dmitry
engineering: maria greg

<property> 
  <name>yarn.scheduler.capacity.queue-mappings</name>
  <value>u:%user:%primary_group</value> 
</property>

那么marketing组下成员Angela/rahul/dmitry提交的应用到marketing队列。同理，engineering组下成员maria/greg提交的应用到marketing队列。

4.3 启用默认队列映射的重写

capacity-scheduler.xml中默认是false不允许重写的,如果启用改为true

<property>
    <name>yarn.scheduler.capacity.queue-mappings-override.enable</name>
    <value>false</value>
    <description>
      If a queue mapping is present and override is set to true, it will override the queue value specified
      by the user. This can be used by administrators to place jobs in queues
      that are different than the one specified by the user.
      The default is false - user can specify to a non-default queue.
    </description>
</property>

5使用队列管理群集资源

使用队列来管理集群资源，以平衡来自不同用户的多个应用程序的资源需求。
由于集群总容量可能会有所不同，因此资源配置值可使用百分比表示。
在capacity-scheduler.xml配置
如下：6:1:3的比例分配集群资源，engineering：60%，support：10%，30%

Property: yarn.scheduler.capacity.root.engineering.capacity
Value: 60

Property: yarn.scheduler.capacity.root.support.capacity
Value: 10

Property: yarn.scheduler.capacity.root.marketing.capacity
Value: 30

如果希望指定为每个队列指定资源绝对值，可如下设置：

Property: yarn.scheduler.capacity.root.engineering.capacity
Value: [memory=10240,vcores=12,yarn.io/gpu=4]

Property: yarn.scheduler.capacity.root.support.capacity
Value: [memory=10240,vcores=12,yarn.io/gpu=4]

Property: yarn.scheduler.capacity.root.marketing.capacity
Value: [memory=10240,vcores=12,yarn.io/gpu=4]

如果不提供内存或vcore值，则使用父队列的资源值。

如果想实现资源可弹：
将maximum capacity指定为浮点百分比值。必须将maximum capacity设置为高于或等于每个队列的absolute capacity。该值设置为-1，将maximum capacity设置为100%。在下面的示例中，engineering队列的最大容量设置为70%。

Property: yarn.scheduler.capacity.root.engineering.maximum-capacity
Value: 70

6 设置队列优先级

对于长时间运行的应用程序和需要大容器(container)的应用程序，必须启用抢占(preemption)以正确应用YARN队列优先级。
即使启用了抢占功能，在某些用例中，如果不设置优先级，应用程序可能无法访问群集资源：

  • Long-running 长时间运行的应用程序–如果不设置优先级，则资源容量不足且资源使用率相对较低的队列中的长时间运行的应用程序可能无法释放群集资源，直到它们完成运行。

  • 需要大型容器的应用程序–对于需要大型容器的应用程序，Long-running长期运行的应用程序的问题更加严重。对于short-running短期运行的应用程序，以前的容器最终可能会完成运行，并为具有大型容器的应用程序释放集群资源。但是对于群集中运行时间较长的服务，大型容器可能永远不会在任何节点上获得足够大的资源。

  • Hive LLAP – Hive LLAP（低延迟分析处理）使您可以近实时地以低延迟运行Hive查询。为确保低延迟，应将用于LLAP的队列的优先级设置为较高的优先级，尤其是在您的集群中包含运行时间较长的应用程序时。

要设置用于Hive LLAP的队列,在 Ambari dashboard中Hive > Config > Settings ,在Interactive Query Queue 下拉菜单中选择一个队列，详细信息参见Hive Performance Tuning guide.
例如，下图显示了一个具有3个节点的群集，该群集具有长期运行的20 GB容器。LLAP守护程序需要90 GB的群集资源，但不会发生抢占，因为可用队列的容量不足，相对资源使用率较低。在任何节点上只有80 GB可用空间时，LLAP必须等待长时间运行的应用程序完成才能访问群集资源。

先决条件：
为了应用YARN队列优先级，您必须启用抢占。
在YARN Queue Manager 界面，选择队列，然后给priority给一个值，默认为0，值越大，优先级越高。

然后点击Actions > Save and Refresh Queues

7 资源分配流程

在调度过程中，按当前已使用容量的顺序对层次结构中任何级别的队列进行排序，并且可 用资源从当前服务不足程度最高的队列开始分配。
仅就容量capacities而言，资源调度具有以下工作流程：

  • 队列服务不足(under-served)的情况越多，它在资源分配期间获得的优先级越高。服务不足的队列是已用容量与集群总容量之比最小的队列。

    • 任何父队列的已用容量被递归定义为其所有后代队列的已用容量的总和。

    • 叶队列的已用容量是该队列中运行的所有应用程序的已分配容器所使用的资源量。

  • 一旦决定将当前可用的空闲资源提供给父队列，则将基于先前描述的已用容量概念，递归地进行进一步的调度，以确定哪个子队列可以使用这些资源。

  • 在每个叶队列内部进行进一步的调度，以按FIFO顺序将资源分配给应用程序。

    • 这也取决于locality,user level limits, and application limits.

    • 一旦选择了叶队列中的应用程序，调度也将在该应用程序内进行。应用程序可能具有不同的资源请求优先级。

  • 为了确保弹性，已配置但由于需求不足而未被任何队列使用的容量会自动分配给需要资源的队列。

8 资源分配流程示例

假设一个100节点的群集，每个节点为YARN容器分配了10 GB的内存，集群的总容量为1000 GB（1 TB）。

根据之前描述的配置，Engineering组织将分配60％的群集容量，即600 GB的绝对容量。同样，为Support组织分配了100 GB，而Marketing组织获得了300 GB。

在Engineering组织下，capacity以1：4的比例在Development团队和QA团队之间分配。因此，Development获得了120 GB的空间，480 GB分配给QA。
现在考虑以下事件时间表：

  • 最初，整个“Engineering”队列是空闲的，没有任何应用程序在运行，而“Support”和“Marketing”队列则用完了他们的全部容量。

  • 用户Sid和Hitesh首先将应用程序提交到“development”叶队列。它们的应用程序具有弹性，可以与群集中可用的所有资源一起运行，也可以与群集资源的子集一起运行（取决于资源使用情况）。

    • 即使为“development”队列分配了120 GB，Sid和Hitesh仍被允许占用120 GB，总计240 GB。

    • 尽管事实上“development”队列被配置为以120 GB的容量运行，还是会发生这种情况。Capacity Scheduler允许弹性共享群集资源，以更好地利用可用群集资源。由于“engineering”队列中没有其他用户，因此Sid和Hitesh被允许使用可用的免费资源。

  • 接下来，用户Jian Zhijie和Xuan向“development”叶子队列提交更多应用程序。即使每个限制为120 GB，队列中的总已用容量仍为600 GB-基本上接管了分配给“ qa”叶队列的所有资源。

  • 用户Gupta现在将应用程序提交到“ qa”队列。由于集群中没有可用的空闲资源，他的应用程序必须等待。

    • 考虑到“development”队列正在利用所有可用的群集资源，Gupta可能会或可能不会立即取回其“ qa”队列的保证容量–这取决于是否启用了抢占。

  • 随着Sid，Hitesh，Jian，Zhijie和Xuan的应用程序运行完毕并且资源可用，新可用的Containers将分配给Gupta的应用程序。

这将继续进行，直到群集稳定在“development”和“ qa”队列的预期资源使用率达到1：4为止。

从此示例中，您可以看到，粗鲁的(obusive)的用户有可能连续提交应用程序，从而将其他队列锁定在资源分配中，直到容器完成运行或被抢占为止。为了避免这种情况，Capacity Scheduler支持限制任何队列的弹性增长。例如，要限制“development”队列独占“engineering”队列容量，管理员administrator可以设置最大容量属性：

Property: yarn.scheduler.capacity.root.engineering.development.maximum-capacity
Value: 40

设置好此设置后，“development”队列的用户仍然可以超过其120 GB的容量，但是分配给他们的空间不会超过“engineering”父队列的40％（即600 GB的40％= 240 GB）。

capacity和maximum-capacity属性可用于控制使用YARN群集的组织和子组织之间的共享和弹性。管理员Administrators应平衡这些属性，以避免造成使用率损失的严格限制，并避免过多的跨组织共享。

使用可以在运行时动态更改capacity和maximum-capacity设置yarn rmadmin -refreshQueues。

9 设置User Limits

minimum-user-limit-percent设置分配给每个叶队列用户的最小资源百分比。
例如，要在五个用户之间平等共享“services”叶队列容量，可以将minimum-user-limit-percent属性设置为20％：

Property: yarn.scheduler.capacity.root.support.services.minimum-user-limit-percent
Value: 20

此设置确定了，任何用户的队列容量份额可以缩减的最小限制。无论是否有此限制，如果有可用的空闲资源，任何用户都可以进入队列并获得比其分配的份额更多的份额。

下表显示了用户将作业提交到minimum-user-limit-percent=20％的队列时，如何调整队列资源 ：

  • 对于连续提交多个作业的单个用户，以相同的方式调整队列资源。如果没有其他用户正在请求队列资源，则第一个作业将获得队列容量的100％。当用户提交第二份作业时，每个作业将获得队列容量的50％。当用户提交第三份作业时，每个作业将获得队列容量的33％。如果第二个用户随后提交了作业，则每个作业将获得队列容量的25％。当所有用户提交的作业总数达到五个时，每个作业将获得20％的队列容量，随后的用户必须等待队列容量释放（假设未启用抢占）。
    • Capacity Scheduler还通过减少用户数量管理资源。随着用户应用程序的运行完成，其他具有突出要求的现有用户开始收回该共享。
    • 请注意，尽管在用户之间进行了共享，但是Capacity Scheduler的FIFO应用程序调度顺序不会更改。这样可以保证用户无法通过连续提交新的应用程序来垄断队列。首先提交的应用程序（以及相应的用户）始终具有比之后提交的应用程序更高的优先级。
  • Capacity Scheduler的叶队列也可以使用该 user-limit-factor属性来控制用户资源分配。此属性表示任何单个用户最多可以消耗的队列容量的fraction，而不管集群中是否有空闲资源。
    Property: yarn.scheduler.capacity.root.support.user-limit-factor
Value: 1
    默认值“ 1”表示队列中的任何单个用户最多只能占用队列的配置容量。这样可以防止单个队列中的用户在群集中的所有队列之间独占资源。将该值设置为“ 2”会将队列的用户限制为队列配置容量的两倍。将其设置为0.5会限制任何用户使用超出队列容量一半的资源。

可以在运行时使用来动态更改这些设置yarn rmadmin - refreshQueues。

10 应用资源预约Application Reservations

对于资源密集型应用程序，如果节点的可用容量可以满足特定应用程序的需求，那么 Capacity Schedule将在该群集节点上创建预留。这样可以确保仅该特定的应用程序使用资源，直到完成应用程序预订为止。

Capacity Schedule负责将群集中的可用资源与应用程序的资源需求进行匹配。很多时候，会发生调度周期，以至于即使节点上有空闲资源，它们的大小也无法满足在队首的应用等待资源的需求。高内存应用程序通常会发生这种情况，这些应用程序对容器Containers的资源需求比群集中运行的典型应用程序要大得多。这种不匹配会导致这些资源密集型应用程序匮乏。

Capacity Scheduler 预约功能可解决此问题，如下所示：

  • 当节点报告有容器完成时， Capacity Scheduler 会根据capacity和maximum capacity设置选择适当的队列来利用新可用的资源。

  • 在该选定队列中，Capacity Scheduler以FIFO顺序和user limits一起查看应用程序。一旦找到需要的应用程序，Capacity Scheduler将尝试查看节点的可用容量是否可以满足该应用程序的要求。

  • 如果大小不匹配，Capacity Scheduler将立即在节点上为应用程序所需的容器创建预留。

  • 为节点上的应用程序进行预留后，Capacity Scheduler不会将这些资源用于任何其他队列，应用程序或容器，直到完成应用程序预留为止。

  • 当足够的容器完成运行时，在其上进行预留的节点将报告，以使该节点上的总可用容量现在与预留大小匹配。发生这种情况时，Capacity Scheduler将预留标记为已完成，将其删除，然后在节点上分配一个Container。

  • 在某些情况下，另一个节点可以满足应用程序所需的资源，因此应用程序不再需要第一个节点上的保留容量。在这种情况下，只需取消预订即可。

为了防止预留数量以无限制的方式增长，并避免任何潜在的调度死锁，Capacity Scheduler在每个节点上一次只能维护一个活动预留。

11 设置灵活的调度策略

根据您的要求在Capacity Scheduler中设置FIFO（先进先出）或公平调度策略。

Capacity Scheduler中的默认排序策略是FIFO（先进先出）。FIFO通常可以很好地用于可预测的周期性批处理作业。但有时对于按需或探索性工作负载而言效果不佳。对于这些类型的工作，Fair Sharing(公平共享)通常是更好的选择。灵活的调度策略使您可以在每个队列的基础上为不同类型的工作负载分配FIFO或Fair 排序策略。

11.1 FIFO and Fair Sharing 策略示例

FIFO（先进先出）和Fair Sharing策略在批处理作业 batch jobs 和临时作业 ad hoc jobs中的工作方式不同。
批处理示例

  • 在此示例中，两个队列具有相同的可用资源。一种使用FIFO排序策略，另一种使用Fair Sharing公平共享策略。用户将三个作业一个接一个地提交到每个队列中，等待足够长的时间以开始每个作业。第一个作业使用队列中资源限制的6x，第二个使用4x，最后一个使用2x。

  • 在FIFO队列中，6x作业将开始并运行到完成，然后4x作业将开始并运行到完成，然后是2x作业。他们将以6x，4x，2x的顺序开始和结束。

  • 在公平队列中，将开始6x作业，然后是4x作业，然后是2x作业。所有这三个将同时运行，每个使用1/3的可用应用程序资源。它们通常按以下顺序完成：2x，4x，6x。

临时加批处理示例

在此示例中，使用10倍队列资源的作业正在运行。作业完成一半后，同一用户将启动第二个作业，所需的队列资源为原来的1倍。

  • 在FIFO队列中，10x作业将运行，直到不再使用所有队列资源（例如，映射阶段完成），然后1x作业将开始。

  • 在公平队列中，1x作业将尽快开始，运行和完成-通过消耗从10x作业中获取资源。

11.2 配置队列排序策略Configure Queue Ordering Policies

您可以在capacity-scheduler.xml中将 Queue Ordering Policies属性配置为fifo 或fair中的。

Ordering policies在capacity-scheduler.xml中配置。要基于每个队列指定排序策略，请将以下属性设置为 fifo或fair。默认设置为 fifo。

<property>
  <name>yarn.scheduler.capacity.<queue-path>.ordering-policy</name>
  <value>fair</value>
</property>

您可以使用以下属性来启用基于大小的资源分配加权。当此属性设置为时true，队列资源将根据其大小分配给各个应用程序，而不是为所有应用程序提供均等的队列资源，而不管大小如何。默认设置为false。

<property>
<name>yarn.scheduler.capacity.<queue-path>
.ordering-policy.fair.enable-size-based-weight</name>
<value>true</value>
</property>
11.3 排序策略的最佳实践Best Practices for Ordering Policies

在配置排序策略时，必须考虑与队列中的应用程序和资源可用性相关的因素。

  • 排序策略是按队列配置的，默认排序策略设置为FIFO。通常，Fairness最适合按需，交互式或探索性工作负载，而FIFO可以更有效地用于可预测的重复批处理。您应该将这些不同类型的工作负载隔离到使用适当的排序策略配置的队列中。

  • 在同时支持大型和小型应用程序的队列中，大型应用程序可能会“饿死”（无法接收足够的资源）。为了避免这种情况，请为不同大小的作业使用不同的队列，或者使用基于大小的加权来减少排序逻辑倾向于较小应用程序的自然趋势。

  • 使用该 yarn.scheduler.capacity..maximum-am-resource-percent 属性限制在队列中运行的并发应用程序的数量，以避免出现同时运行太多应用程序的情况。每个队列的限制与它们的队列容量和用户限制成正比。此属性被指定为浮点型，例如：0.5 = 50％。默认设置为10％。可以使用该yarn.scheduler.capacity.maximum-am-resource-percent属性为所有队列设置此属性，每个队列中设置的 yarn.scheduler.capacity..maximum-am-resource-percent会覆盖掉yarn.scheduler.capacity.maximum-am-resource-percent设置的 。

12 启动和停止队列Start and Stop Queues

YARN中的队列可以处于两种状态：RUNNING或STOPPED。RUNNING状态表示队列可以接受应用程序提交，而STOPPED队列不接受应用程序提交。任何已配置队列的默认状态为RUNNING。

在Capacity Scheduler中，父队列，叶队列和root队列都可以停止。为了使应用程序在任何叶队列中被接受，必须一直运行层次结构中直到根队列的所有队列。这意味着，如果父队列停止，则该层次结构中的所有后代队列均处于非活动状态，即使它们自己的状态为RUNNING。

下面的示例将“support”队列的state属性的值设置为RUNNING：

Property: yarn.scheduler.capacity.root.support.state
Value: RUNNING

管理员Administrators可以出于多种原因使用该功能来停止和清空队列中的应用程序，例如在停用队列并将其用户迁移到其他队列时。管理员可以在运行时停止队列，所以在当前应用程序运行完成时，不会允许任何新的应用程序。现有应用程序可以继续运行直到完成运行，因此可以在不影响最终用户的情况下优雅地清空队列。

管理员Administrators还可以通过修改state配置属性，然后使用刷新队列来重新启动已停止的队列 yarn rmadmin -refreshQueues。

13 设置应用程序限制 Set Application Limits

为避免由于不可管理的负载（由恶意用户或意外负载导致）而导致系统崩溃，通过 Capacity Scheduler ，您可以对同时处于active状态（both running and pending）的应用程序总数设置静态的，可配置的限制任何一次。

用maximum-applications属性配置，默认值为10,000。

Property: yarn.scheduler.capacity.maximum-applications
Value: 10000

在任何特定队列中运行应用程序的限制是该总限制的一小部分，与它的容量成比例。这是一个硬限制，这意味着一旦队列达到该限制，该队列中的任何新应用程序都将被拒绝，客户端将必须等待并稍后重试。可以使用以下配置属性在每个队列上显式覆盖此限制：

Property: yarn.scheduler.capacity.<queue-path>.maximum-applications
Value: absolute-capacity * yarn.scheduler.capacity.maximum-applications

还有另一个资源限制，可用于设置专门分配给ApplicationMaster的集群资源的最大百分比。该maximum-am-resource-percent属性的默认值为10％，并且存在此 属性是为了避免跨应用程序死锁，因为在该死锁中集群中的大量资源完全由运行ApplicationMasters的Container占用。此属性还间接控制集群中并发运行的应用程序的数量，每个队列限制为与其容量成比例的正在运行的应用程序的数量。

Property: yarn.scheduler.capacity.maximum-am-resource-percent
Value: 0.1

与最大应用程序一样，此限制也可以基于每个队列被覆盖：

Property: yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
Value: 0.1

所有这些限制确保了没有单个应用程序，用户或队列会导致灾难性故障，也不会垄断群集并导致群集性能过度下降。

14 启用抢占 Enable Preemption

Capacity Scheduler Preemption允许优先级较高的应用程序抢占优先级较低的应用程序。

可能发生一种情况，其中队列具有保证的群集资源级别，但是必须等待运行应用程序，因为其他队列正在利用所有可用资源。如果启用了抢占，则优先级较高的应用程序不必等待，因为优先级较低的应用程序已占用了可用容量。启用抢占功能后，服务不足的队列几乎可以立即开始声明其分配的群集资源，而不必等待其他队列的应用程序完成运行。

14.1 抢占工作流程 Preemption Workflow

抢占由一组容量监视器策略(capacity monitor policies)控制，必须通过将yarn.resourcemanager.scheduler.monitor.enable属性 设置为true来启用该策略。这些容量监视器策略基于定义的容量分配，以可配置的间隔去抢占，并且以尽可能合适的方式进行。Containers只是在万不得已时才被杀死的。
下图演示了抢占工作流程：

14.2 配置抢占 Configure Preemption

Capacity Schedule在yarn-site.xmlr中配置各种属性以设置应用程序抢占。

在ResourceManager主机上/etc/hadoop/conf/yarn-site.xml 中的以下属性用于启用和配置抢占。

Property: yarn.resourcemanager.scheduler.monitor.enable
Value: true
Description: Setting this property to "true" enables Preemption. It enables a set of periodic monitors that affect the Capacity Scheduler. This default value for this property is "false" (disabled).
将此属性设置为“ true”将启用抢占。它启用了一组定期监视器，这些监视器会影响Capacity Scheduler。此属性的默认值是“ false”（禁用）。

Property: yarn.resourcemanager.scheduler.monitor.policies
Value:
org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy
Description: The list of SchedulingEditPolicy classes that interact with the scheduler. The only policy currently available for preemption is the “ProportionalCapacityPreemptionPolicy”.
与调度程序交互的SchedulingEditPolicy类的列表。当前唯一可用于抢占的策略是“ ProportionalCapacityPreemptionPolicy”。

Property: yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval
Value: 3000
Description: The time in milliseconds between invocations of this policy. Setting this value to a longer time interval will cause the Capacity Monitor to run less frequently.
两次调用该策略之间的时间（以毫秒为单位）。将此值设置为较长的​​时间间隔将导致容量监视器的运行频率降低。

Property: yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill
Value: 15000
Description: The time in milliseconds between requesting a preemption from an application and killing the container. Setting this to a higher value will give applications more time to respond to preemption requests and gracefully release Containers.
从应用程序请求抢占到终止容器之间的时间（以毫秒为单位）。将此值设置为较高的值将使应用程序有更多时间响应抢占请求并优雅地释放容器。

Property: yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round
Value: 0.1
Description: The maximum percentage of resources preempted in a single round. You can use this value to restrict the pace at which Containers are reclaimed from the cluster. After computing the total desired preemption, the policy scales it back to this limit. This should be set to (memory-of-one-NodeManager)/(total-cluster-memory). For example, if one NodeManager has 32 GB, and the total cluster resource is 100 GB, the total_preemption_per_round should set to 32/100 = 0.32. The default value is 0.1 (10%).
单回合中可抢占的最大资源百分比。您可以使用此值来限制从群集回收Containers的速度。计算完所需的总抢占后，策略会将其重新扩展到此限制。应将其设置为(memory-of-one-NodeManager)/(total-cluster-memory)。例如，如果一个NodeManager拥有32 GB，并且群集总资源为100 GB，则total_preemption_per_round应设置为32/100 = 0.32。默认值为0.1（10％）。

Property: yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor
Value: 1.0
Description: Similar to total_preemption_per_round, you can apply this factor to slow down resource preemption after the preemption target is computed for each queue (for example, “give me 5 GB back from queue-A”). For example, if 5 GB is needed back, in the first cycle preemption takes back 1 GB (20% of 5GB), 0.8 GB (20% of the remaining 4 GB) in the next, 0.64 GB (20% of the remaining 3.2 GB) next, and so on. You can increase this value to speed up resource reclamation. The recommended value for this parameter is 1.0, meaning that 100% of the target capacity is preempted in a cycle.
类似于total_preemption_per_round，在为每个队列计算了抢占目标之后，可以应用此因子来减慢资源抢占（例如，“从队列A中退回5 GB”）。例如，如果需要5 GB，则在第一个周期中，抢占将收回1 GB（5 GB的20％），在下一个周期中收回0.8 GB（其余4 GB的20％），在0.64 GB（其余3.2 GB的20％）中抢占。 GB），依此类推。您可以增加此值以加快资源回收。此参数的建议值为1.0，这意味着一个循环中将抢占100％的目标容量。

15 启用优先级调度 Enable Priority Scheduling

您可以使用“优先级调度”以运行更高的优先级YARN应用程序，而与群集中已经在运行的其他应用程序无关。YARN会向运行优先级较低的应用程序分配更多资源给运行优先级较高的应用程序。优先级调度使您可以在提交时和在运行时动态设置应用程序的优先级。

优先级调度仅适用于FIFO（先进先出）排序策略。FIFO是默认的Capacity Scheduler订购策略。

步骤：

  • 1.设置群集的最大优先级和叶队列级别的优先级。

    • Cluster maximum priority：在yarn-site.xml文件中设置以下属性， 以定义集群中应用程序的最大优先级：

      yarn.cluster.max-application-priority

      优先级大于此设置的所有提交的应用程序都将其优先级重置为 yarn.cluster.max-application-priority 值。

    • Leaf queue-level priority：在capacity-scheduler.xml文件中设置以下属性， 以定义叶子队列中的默认应用程序优先级：

      yarn.scheduler.capacity.root..default-application-priority
      默认应用程序优先级用于没有指定优先级的任何提交的应用程序。

  • 2.使用yarn application -appID命令行选项或集群应用程序REST API来设置已运行的应用程序的优先级。

    • yarn application -appID -updatePriority <优先级>
    • 群集应用程序优先级API

16 为应用程序优先级配置ACLs ACLs for Application Priorities

配置优先级ACLs，以确保只有选定用户可以将指定优先级的应用程序提交到队列。您必须在叶队列级别配置这些优先级ACLs。
如果已经为用户访问叶队列配置了ACL，则该队列的优先级ACL只能包括那些有权访问该队列的用户。
在capacity-scheduler.xml文件中设置以下属性以设置优先级ACL：

<property>
    <name>yarn.scheduler.capacity.<leaf-queue-path>.acl_application_max_priority</name>
    
    <value>[user={username} group={groupname} max_priority={priority} default_priority={priority}]
    </value>
    
    <description>
      The ACL of users who can submit applications with configured priority.
    </description>
</property>

以下示例说明如何为用户maria和组hadoop的用户配置优先级ACLs ：

yarn.scheduler.capacity.root.queue1.acl_application_max_priority=[user=maria group=hadoop max_priority=7 default_priority=4
]

该用户maria和该hadoop 组的用户可以提交应用的最高优先级为7。

17 启用队列内抢占 Enable Intra-Queue Preemption

队列内抢占(Intra-queue )可根据已配置的用户限制(user limits)或应用程序优先级(application priorities)帮助有效地在队列内分配资源。

队列内抢占通过防止发生以下情况来防止队列中的资源不平衡：

  • 较低优先级的应用程序消耗队列中的所有可用资源，从而使较高优先级的应用程序资源匮乏。
  • 少数用户消耗了整个队列的容量，从而使其他用户无法提交更高优先级的应用程序。尽管根据配置的限制，所有用户都有资格使用队列的资源，但仍可能发生这种情况。
17.1 用于配置队列内抢占的属性 Properties for Configuring Intra-Queue Preemption

默认情况下，YARN队列启用队列内抢占。此外，您可以通过应用程序优先级(application priorities)或配置的用户限制(user limits)来配置队列内抢占的顺序。

您可以在yarn-site.xml中为队列内抢占配置以下属性的值 ：

PropertyDescription
yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.enabled是否为队列启用队列内抢占。默认值true
yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.preemption-order-policy指定队列可以抢占资源的顺序。根据您的要求，可以将此属性配置为以下值之一：userlimit-first：以根据配置的用户限制启动队列内抢占。这是默认值。priority-first：以根据应用程序优先级启动队列内抢占。
17.2 基于应用优先级的队列内抢占 Intra-Queue Preemption Based on Application Priorities

根据应用程序优先级在队列上启用抢占可确保较高优先级的应用程序可以在需要时从较低优先级的应用程序中抢占资源。

没有启用抢占的队列上资源消耗的示例：

考虑一个root.qA.capacity配置为70％的队列qA 。按以下顺序提交的申请：

  1. 用户提交优先级为p1的应用程序app1。因为没有其他应用程序在队列上运行，所以app1使用队列上可用的大部分资源。
  2. app1开始运行后不久，用户提交了另一个与app1具有相同优先级的应用程序app2。在这种情况下，app2使用队列上剩余的资源。
  3. 用户提交具有更高优先级p3的第三应用程序app3。
    如果未在队列上启用抢占，则优先级较低的应用程序app1和app2会消耗队列的所有可用容量，而优先级较高的应用程序app3则资源不足。

下表说明了三个应用程序之间的资源分配：

启用抢占的队列上资源消耗的示例：
考虑与前面的示例相同的队列和具有优先级的应用程序。

如果在队列上启用了基于应用程序优先级的抢占，则会从app1和app2中抢占资源，以便运行更高优先级的app3。

下表说明了启用抢占时三个应用程序之间的资源分配：

17.3 基于用户限制的队列内抢占 Intra-Queue Preemption based on User Limits

在基于用户限制的队列上启用抢占可确保将资源提交到特定队列的所有用户之间均匀分配资源。

没有启用抢占的队列上资源消耗的示例
考虑一个root.qA.capacity配置为100％和 minimum-user-limit-percent配置为33％的队列qA 。这意味着向队列提交应用程序的前三个用户每个都可以使用至少33％的队列资源。如果这三个用户已经按照指定使用了队列的资源，则任何其他用户都必须等待资源分配后再提交应用程序。

考虑按以下顺序提交的申请：

  1. 用户u1提交具有优先级p1的应用程序app1。因为没有其他应用程序在队列上运行，所以app1使用队列上可用的大部分资源。
  2. app1开始运行后不久，用户u2和u3大约同时在同一时间提交了应用程序app2和app3，优先级为p1。在这种情况下，app2和app3使用保留在队列中的资源。
    如果未在队列上启用抢占，则尽管app2和app3的优先级与app1相同，但它们不会消耗队列上的资源份额。

下表说明了三个应用程序之间的资源分配：

开启抢占的队列上的资源消耗示例
考虑与前面的示例相同的队列和具有优先级的应用程序。

如果在队列上启用了基于用户限制的抢占，则将从app1中抢占资源以使app2和app3运行。

下表说明了启用抢占时三个应用程序之间的资源分配：

相关链接：

  1. Hortonworks 文档
    https://docs.cloudera/HDPDocuments/HDP3/HDP-3.1.4/data-operating-system/content/manage_cluster_capacity_with_queues.html
  2. yarn-resource-managerment
    https://pivotalhd.docs.pivotal.io/docs/yarn-resource-management.html
  3. yarn-capacity相关文章
    http://bigdatadecode.club/[%E8%AF%91]Yarn-capacity.html
  4. apache hadoop相关配置解释
    https://hadoop.apache/docs/stable/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html#Setting_up_queues

本文标签： 资源AmbariyarnCapacityScheduler

版权声明：本文标题：【Ambari】yarn资源调度之CapacityScheduler 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://m.elefans.com/xitong/1728619416a1166155.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。