Hadoop：容量调度程序

用途

本文件描述了 CapacityScheduler，它是一个 Hadoop 可插拔调度程序，它允许多个租户安全地共享大型集群，以便在分配容量的约束下及时地为其应用程序分配资源。

概述

CapacityScheduler 被设计为以一种对操作员友好的方式运行 Hadoop 应用程序作为共享的多租户集群，同时最大化集群的吞吐量和利用率。

传统上，每个组织都有自己的私有计算资源集，该资源集具有足够的能力来满足组织在高峰或接近高峰条件下的 SLA。这通常会导致平均利用率低下以及管理多个独立集群（每个组织一个）的开销。在组织之间共享集群是运行大型 Hadoop 安装的经济高效的方式，因为这使他们能够在不创建私有集群的情况下享受规模经济的好处。但是，组织担心共享集群，因为他们担心其他人会使用对其 SLA 至关重要的资源。

CapacityScheduler 旨在允许共享大型集群，同时为每个组织提供容量保证。核心思想是 Hadoop 集群中的可用资源在多个组织之间共享，这些组织根据其计算需求共同为集群提供资金。一个额外的好处是，组织可以访问其他组织未使用的任何多余容量。这以经济高效的方式为组织提供了弹性。

跨组织共享集群需要对多租户提供强有力的支持，因为必须保证每个组织的容量和安全保障，以确保共享集群不受单个流氓应用程序或用户或其集合的影响。CapacityScheduler 提供了一组严格的限制，以确保单个应用程序或用户或队列无法消耗集群中不成比例的资源量。此外，CapacityScheduler 对单个用户和队列的已初始化和待处理应用程序施加限制，以确保集群的公平性和稳定性。

CapacityScheduler 提供的主要抽象是队列的概念。这些队列通常由管理员设置，以反映共享集群的经济性。

为了进一步控制和预测资源共享，CapacityScheduler 支持层次队列，以确保在允许其他队列使用空闲资源之前，在组织的子队列之间共享资源，从而为给定组织的应用程序在共享空闲资源方面提供亲和性。

功能

CapacityScheduler 支持以下功能

  • 分层队列 - 支持队列层次结构，以确保在允许其他队列使用空闲资源之前，资源在组织的子队列之间共享，从而提供更多的控制和可预测性。

  • 容量保证 - 队列被分配网格容量的一部分，这意味着一定容量的资源将可供它们使用。提交到队列的所有应用程序都将能够访问分配给该队列的容量。管理员可以配置对分配给每个队列的容量的软限制和可选的硬限制。

  • 安全性 - 每个队列都有严格的 ACL，用于控制哪些用户可以向各个队列提交应用程序。此外，还有保障措施以确保用户无法查看和/或修改其他用户的应用程序。此外，还支持按队列和系统管理员角色。

  • 弹性 - 可以将空闲资源分配给任何超过其容量的队列。当未来某个时间点容量低于运行队列的需求时，随着在这些资源上计划的任务完成，它们将被分配给容量低于运行队列的应用程序（也支持抢占）。这确保了资源以可预测且弹性的方式提供给队列，从而防止集群中出现人工资源孤岛，这有助于提高利用率。

  • 多租户 - 提供了一套全面的限制，以防止单个应用程序、用户和队列垄断队列或整个集群的资源，以确保集群不会不堪重负。

  • 可操作性

    • 运行时配置 - 队列定义和属性（如容量、ACL）可以在运行时由管理员以安全的方式更改，以最大程度地减少对用户的影响。此外，还为用户和管理员提供了一个控制台，用于查看系统中分配给各个队列的当前资源。管理员可以在运行时“添加其他队列”，但除非队列已停止且没有待处理/正在运行的应用程序，否则不能在运行时“删除”队列。

    • 排空应用程序 - 管理员可以在运行时“停止”队列，以确保在现有应用程序运行到完成时，不能提交新的应用程序。如果队列处于已停止状态，则不能向自身或其任何子队列提交新的应用程序。现有应用程序继续完成，因此队列可以正常地排空。管理员还可以启动已停止的队列。

  • 基于资源的调度 - 支持资源密集型应用程序，其中应用程序可以选择性地指定高于默认值的高资源需求，从而适应具有不同资源需求的应用程序。目前，内存是支持的资源需求。

  • 基于默认或用户定义放置规则的队列映射接口 - 此功能允许用户根据一些默认放置规则将作业映射到特定队列。例如，基于用户和组或应用程序名称。用户还可以定义自己的放置规则。

  • 优先级调度 - 此功能允许提交应用程序并以不同的优先级进行调度。较高的整数值表示应用程序的较高优先级。当前，仅 FIFO 排序策略支持应用程序优先级。

  • 绝对资源配置 - 管理员可以为队列指定绝对资源，而不是提供基于百分比的值。这为管理员提供了更好的控制，以便为给定队列配置所需的资源量。

  • 叶队列的动态自动创建和管理 - 此功能支持自动创建叶队列，并结合队列映射，当前支持基于用户组的队列映射，以将应用程序放置到队列中。调度程序还支持基于在父队列上配置的策略对这些队列进行容量管理。

配置

设置 ResourceManager 以使用 CapacityScheduler

要配置 ResourceManager 以使用 CapacityScheduler，请在 conf/yarn-site.xml 中设置以下属性

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

设置队列

etc/hadoop/capacity-scheduler.xml 是 CapacityScheduler 的配置文件。

CapacityScheduler 有一个名为 root 的预定义队列。系统中的所有队列都是根队列的子队列。

可以通过使用逗号分隔的子队列列表配置 yarn.scheduler.capacity.root.queues 来设置更多队列。

CapacityScheduler 的配置使用称为队列路径的概念来配置队列的层次结构。队列路径是队列层次结构的完整路径，从root开始，以 .（点）作为分隔符。

可以通过配置旋钮来定义给定队列的子队列：yarn.scheduler.capacity.<queue-path>.queues。除非另有说明，否则子队列不会直接从父队列继承属性。

这里有一个示例，其中有三个顶级子队列 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>

队列属性

  • 资源分配
属性 说明
yarn.scheduler.capacity.<queue-path>.capacity 队列容量以百分比 (%) 形式表示为浮点数（例如 12.5）或绝对资源队列最小容量。在每个级别，所有队列的容量总和必须等于 100。但是，如果配置了绝对资源，则子队列的绝对资源总和可能小于其父绝对资源容量。如果存在空闲资源，队列中的应用程序可能会消耗超过队列容量的资源，从而提供弹性。
yarn.scheduler.capacity.<queue-path>.maximum-capacity 队列最大容量以百分比 (%) 形式表示为浮点数或绝对资源队列最大容量。这限制了队列中应用程序的弹性。1) 值介于 0 和 100 之间。2) 管理员需要确保每个队列的绝对最大容量 >= 绝对容量。此外，将此值设置为 -1 会将最大容量设置为 100%。
yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent 如果存在资源需求，每个队列都会对分配给用户的资源百分比实施限制。用户限制可以在最小值和最大值之间变化。前者（最小值）设置为此属性值，后者（最大值）取决于已提交应用程序的用户数。例如，假设此属性的值为 25。如果两个用户已向队列提交应用程序，则没有一个用户可以使用超过 50% 的队列资源。如果第三个用户提交应用程序，则没有一个用户可以使用超过 33% 的队列资源。如果用户数为 4 或更多，则没有一个用户可以使用超过 25% 的队列资源。100 的值表示不实施用户限制。默认值为 100。值指定为整数。
yarn.scheduler.capacity.<queue-path>.user-limit-factor 可以配置队列容量的倍数，以允许单个用户获取更多资源。默认情况下，此值设置为 1，这确保单个用户永远无法获取超过队列配置的容量，无论集群有多空闲。值指定为浮点数。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb 资源管理器中为每个容器请求分配内存的最大限制。此设置将覆盖群集配置 yarn.scheduler.maximum-allocation-mb。此值必须小于或等于群集最大值。
yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores 资源管理器中为每个容器请求分配虚拟核心的最大限制。此设置将覆盖群集配置 yarn.scheduler.maximum-allocation-vcores。此值必须小于或等于群集最大值。
yarn.scheduler.capacity.<queue-path>.user-settings.<user-name>.weight 计算队列中用户的用户限制资源值时使用此浮点值。此值将对队列中的每个用户进行加权，使其比队列中的其他用户多或少。例如，如果用户 A 在队列中应获得比用户 B 和 C 多 50% 的资源，则此属性将针对用户 A 设置为 1.5。用户 B 和 C 的默认值为 1.0。
  • 使用绝对资源配置进行资源分配

CapacityScheduler 支持配置绝对资源，而不是以百分比提供队列容量。如上文 yarn.scheduler.capacity.<queue-path>.capacity 和 yarn.scheduler.capacity.<queue-path>.max-capacity 的配置部分中所述，管理员可以指定绝对资源值，例如 [memory=10240,vcores=12]。这是一个有效配置，表示 10GB 内存和 12 个虚拟核心。

  • 正在运行和待处理的应用程序限制

CapacityScheduler 支持以下参数来控制正在运行和待处理的应用程序

属性 说明
yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications 系统中可以同时处于活动状态（正在运行和待处理）的应用程序的最大数量。每个队列的限制与其队列容量和用户限制成正比。这是一个硬限制，当达到此限制时提交的任何应用程序都将被拒绝。默认值为 10000。可以通过 yarn.scheduler.capacity.maximum-applications 为所有队列设置此值，也可以通过设置 yarn.scheduler.capacity.<queue-path>.maximum-applications 按队列覆盖此值。预期整数值。
yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent 群集中可用于运行应用程序主服务器的最大资源百分比 - 控制并发活动应用程序的数量。每个队列的限制与它们的队列容量和用户限制成正比。指定为浮点数 - 即 0.5 = 50%。默认值为 10%。这可以通过 yarn.scheduler.capacity.maximum-am-resource-percent 为所有队列设置，也可以通过设置 yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent 按队列逐个覆盖
yarn.scheduler.capacity.max-parallel-apps / yarn.scheduler.capacity.<queue-path>.max-parallel-apps 可以同时运行的最大应用程序数。与 maximum-applications 不同，达到此限制时不会拒绝应用程序提交。相反，它们会一直处于 ACCEPTED 状态，直到它们有资格运行。这可以通过 yarn.scheduler.capacity.max-parallel-apps 为所有队列设置，也可以通过设置 yarn.scheduler.capacity.<queue-path>.max-parallel-apps 按队列逐个覆盖。预计为整数值。默认情况下，没有限制。最大并行应用程序限制是队列层次结构中的继承属性，这意味着最低值将被选为层次结构中每个分支中强制执行的限制。

您还可以按用户逐个限制并行应用程序的数量。

属性 说明
yarn.scheduler.capacity.user.max-parallel-apps 所有用户可以同时运行的最大应用程序数。默认值是无限的。
yarn.scheduler.capacity.user.<username>.max-parallel-apps 特定用户可以同时运行的最大应用程序数。这会覆盖全局设置。

这些限制的评估按以下顺序进行

  1. maximum-applications 检查 - 如果超过限制，则立即拒绝提交。

  2. max-parallel-apps 检查 - 接受提交，但应用程序不会转换到 RUNNING 状态。它会一直处于 ACCEPTED 状态，直到满足队列/用户限制。

  3. maximum-am-resource-percent 检查 - 如果运行的应用程序主服务器过多，则应用程序会一直处于 ACCEPTED 状态，直到有足够的空间为止。

  • 队列管理和权限

CapacityScheduler 支持以下参数来管理队列

属性 说明
yarn.scheduler.capacity.<queue-path>.state 队列的状态。可以是 RUNNING 或 STOPPED 之一。如果队列处于 STOPPED 状态，则不能向自身或其任何子队列提交新应用程序。因此，如果根队列为 STOPPED，则不能向整个集群提交应用程序。现有应用程序继续完成，因此队列可以正常耗尽。值指定为枚举。
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications 控制谁可以向给定队列提交应用程序的ACL。如果给定的用户/组对给定队列或层次结构中的某个父队列具有必要的 ACL，则他们可以提交应用程序。如果未指定，此属性的ACL会从父队列继承。如果在此列表中的用户名之前加上波浪号 (~)，则真实用户的 ACL 将允许代理用户向队列提交。
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue 控制谁可以管理给定队列上的应用程序的ACL。如果给定的用户/组对给定队列或层次结构中的某个父队列具有必要的 ACL，则他们可以管理应用程序。如果未指定，此属性的ACL会从父队列继承。如果在此列表中的用户名之前加上波浪号 (~)，则真实用户的 ACL 将允许代理用户管理队列中的应用程序。

注意：ACL 的形式为 user1,user2 space group1,group2。特殊值 * 表示任何人。特殊值 space 表示没有人。如果未指定，则根队列的默认值为 *。

  • 基于用户或组、应用程序名称或用户定义的放置规则的队列映射

CapacityScheduler 支持以下参数来配置基于用户或组、用户和组或应用程序名称的队列映射。用户还可以定义自己的放置规则

属性 说明
yarn.scheduler.capacity.queue-mappings 此配置指定用户或组到特定队列的映射。您可以将单个用户或用户列表映射到队列。语法：[u or g]:[name]:[queue_name][,next_mapping]*。此处，u or g 指示映射是针对用户还是组。用户的值为 u，组的值为 g。name 指示用户名或组名。要指定提交应用程序的用户，可以使用 %user。queue_name 指示应用程序必须映射到的队列名称。要指定与用户名相同的队列名称，可以使用 %user。要指定与用户所属主组名称相同的队列名称，可以使用 %primary_group。辅助组可以引用为 %secondary_group
yarn.scheduler.queue-placement-rules.app-name 此配置指定了 application_name 到特定队列的映射。您可以将单个应用程序或应用程序列表映射到队列。语法：[app_name]:[queue_name][,next_mapping]*。其中，app_name 指示您想要进行映射的应用程序名称。queue_name 指示应用程序必须映射到的队列名称。要将当前应用程序的名称指定为 app_name，可以使用 %application。
yarn.scheduler.capacity.queue-mappings-override.enable 此函数用于指定是否可以覆盖用户指定的队列。这是一个布尔值，默认值为false。

示例

以下示例分别涵盖单个映射。对于以逗号分隔的值进行的多重映射，评估将从左到右进行，并且将使用第一个有效的映射。以下示例顺序已根据在多重映射情况下运行时的实际执行顺序记录。

 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%primary_group.%user</value>
    <description>Maps users to queue with the same name as user but
    parent queue name should be same as primary group of the user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%secondary_group.%user</value>
    <description>Maps users to queue with the same name as user but
    parent queue name should be same as any secondary group of the user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:%user:%user</value>
    <description>Maps users to queues with the same name as user</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user2:%primary_group</value>
    <description>user2 is mapped to queue name same as primary group</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user3:%secondary_group</value>
    <description>user3 is mapped to queue name same as secondary group</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user1:queue1</value>
    <description>user1 is mapped to queue1</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>g:group1:queue2</value>
    <description>group1 is mapped to queue2</description>
 </property>
 ...
 <property>
    <name>yarn.scheduler.capacity.queue-mappings</name>
    <value>u:user1:queue1,u:user2:queue2</value>
    <description>Here, <user1> is mapped to <queue1>, <user2> is mapped to <queue2> respectively</description>
 </property>

  <property>
    <name>yarn.scheduler.queue-placement-rules.app-name</name>
    <value>appName1:queue1,%application:%application</value>
    <description>
      Here, <appName1> is mapped to <queue1>, maps applications to queues with
      the same name as application respectively. The mappings will be
      evaluated from left to right, and the first valid mapping will be used.
    </description>
  </property>
  • 应用程序的队列生命周期

    CapacityScheduler 支持以下参数来应用生命周期

属性 说明
yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime 提交到队列的应用程序的最大生命周期（以秒为单位）。小于或等于零的任何值都将被视为已禁用。默认值为 -1。如果配置了正值，则提交到此队列的任何应用程序在超过配置的生命周期后都将被终止。用户还可以在应用程序提交上下文中指定每个应用程序的生命周期。但是，如果用户生命周期超过队列的最大生命周期，则将覆盖用户生命周期。这是即时配置。注意：此功能可以在队列层次结构的任何级别设置。子队列将继承其父队列的值，除非在子队列级别覆盖。值 0 表示没有最大生命周期，并且将覆盖父队列的最大生命周期。如果未设置此属性或将其设置为负数，则此队列的最大生命周期值将从其父队列继承。
yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime 提交到队列的应用程序的默认生命周期（以秒为单位）。小于或等于零的任何值都将被视为已禁用。如果用户未提交具有生命周期值的应用程序，则将采用此值。这是即时配置。此功能可以在队列层次结构的任何级别设置。子队列将继承其父队列的值，除非在子队列级别覆盖。如果设置为小于或等于 0，则队列的最大值也必须为无限。默认生命周期不能超过最大生命周期。

应用程序优先级的设置。

应用程序优先级仅适用于 FIFO 排序策略。默认排序策略是 FIFO。

应用程序的默认优先级可以在群集级别和队列级别。

  • 集群级优先级：任何以高于集群最大优先级提交的应用程序，其优先级都将重置为集群最大优先级。$HADOOP_HOME/etc/hadoop/yarn-site.xml 是集群最大优先级的配置文件。
属性 说明
yarn.cluster.max-application-priority 定义集群中的最大应用程序优先级。
  • 叶级队列优先级：每个叶级队列都由管理员提供默认优先级。对于任何未指定优先级的提交应用程序，都将使用队列的默认优先级。$HADOOP_HOME/etc/hadoop/capacity-scheduler.xml 是队列级优先级的配置文件。
属性 说明
yarn.scheduler.capacity.root.<leaf-queue-path>.default-application-priority 定义叶级队列中的默认应用程序优先级。

注意：当应用程序移至不同的队列时，应用程序的优先级不会改变。

容量调度器容器抢占

CapacityScheduler 支持从资源使用量超过其保证容量的队列中抢占容器。需要在 yarn-site.xml 中启用以下配置参数，以支持应用程序容器的抢占。

属性 说明
yarn.resourcemanager.scheduler.monitor.enable 启用一组定期监视器（在 yarn.resourcemanager.scheduler.monitor.policies 中指定），这些监视器会影响调度程序。默认值为 false。
yarn.resourcemanager.scheduler.monitor.policies 与调度程序交互的 SchedulingEditPolicy 类的列表。配置的策略需要与调度程序兼容。默认值为 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy，该值与 CapacityScheduler 兼容

当为 yarn.resourcemanager.scheduler.monitor.policies 配置 ProportionalCapacityPreemptionPolicy 类时，可以在 yarn-site.xml 中配置以下配置参数来控制容器的抢占

属性 说明
yarn.resourcemanager.monitor.capacity.preemption.observe_only 如果为 true，则运行该策略，但不会通过抢占和终止事件影响集群。默认值为 false
yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval 调用此 ProportionalCapacityPreemptionPolicy 策略之间的毫秒数。默认值为 3000
yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill 从应用程序请求抢占到终止容器之间的毫秒数。默认值为 15000
yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round 单个轮次中抢占的资源最大百分比。通过控制此值，可以限制从集群中回收容器的速度。在计算出总的所需抢占后，此策略会在此限制内缩小其规模。默认值为 0.1
yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity 超过目标容量且被忽略以进行抢占的最大资源量。这定义了目标容量周围的死区，有助于防止在计算出的目标平衡周围出现抖动和振荡。高值会减慢达到容量的时间，并且（在没有自然完成的情况下）可能会阻止收敛到保证容量。默认值为 0.1
yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor 给定计算出的抢占目标，考虑自然过期的容器，并仅抢占此增量百分比。这决定了进入死区（MAX_IGNORED_OVER_CAPACITY）的几何收敛速度。例如，终止因子为 0.5 将在 5 * #WAIT_TIME_BEFORE_KILL 内回收几乎 95% 的资源，即使没有自然终止。默认值为 0.2

CapacityScheduler 支持 capacity-scheduler.xml 中的以下配置，以控制提交到队列的应用程序容器的抢占。

属性 说明
yarn.scheduler.capacity.<queue-path>.disable_preemption 此配置可以设置为 true，以选择性地禁用提交到给定队列的应用程序容器的抢占。此属性仅在通过将 yarn.resourcemanager.scheduler.monitor.enable 配置为 true 且将 yarn.resourcemanager.scheduler.monitor.policies 配置为 ProportionalCapacityPreemptionPolicy 来启用系统范围抢占时才适用。如果未为队列设置此属性，则属性值将从队列的父级继承。默认值为 false。
yarn.scheduler.capacity.<queue-path>.intra-queue-preemption.disable_preemption 此配置可设置为 true，以选择性地禁用提交到给定队列的应用程序容器的队列内抢占。此属性仅在通过将 yarn.resourcemanager.scheduler.monitor.enable 配置为 true、yarn.resourcemanager.scheduler.monitor.policies 配置为 ProportionalCapacityPreemptionPolicy 以及 yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.enabled 配置为 true 来启用系统范围抢占时才适用。如果未为队列设置此属性，则属性值将从队列的父级继承。默认值为 false。

预留属性

  • 预留管理和权限

CapacityScheduler 支持以下参数来控制预留的创建、删除、更新和列出。请注意，任何用户都可以更新、删除或列出自己的预留。如果启用了预留 ACL 但未定义，则每个人都可以访问。在以下示例中，<queue> 是队列名称。例如，要将预留 ACL 设置为管理默认队列上的预留，请使用属性 yarn.scheduler.capacity.root.default.acl_administer_reservations

属性 说明
yarn.scheduler.capacity.root.<queue>.acl_administer_reservations 控制谁可以管理给定队列的预留的 ACL。如果给定的用户/组在给定队列上具有必要的 ACL，或者他们可以提交、删除、更新和列出所有预留。如果未指定，此属性的 ACL 不会从父队列继承。
yarn.scheduler.capacity.root.<queue>.acl_list_reservations 控制谁可以列出给定队列的预留的 ACL。如果给定的用户/组在给定队列上具有必要的 ACL，则他们可以列出所有应用程序。如果未指定，此属性的 ACL 不会从父队列继承。
yarn.scheduler.capacity.root.<queue>.acl_submit_reservations 控制谁可以提交给定队列的预留的 ACL。如果给定的用户/组在给定队列上具有必要的 ACL，则他们可以提交预留。如果未指定，此属性的 ACL 不会从父队列继承。

使用 CapacityScheduler 配置 ReservationSystem

CapacityScheduler 支持 ReservationSystem，允许用户提前预留资源。应用程序可以通过在提交期间指定 reservationId 来在运行时请求预留的资源。可以在 yarn-site.xml 中为 ReservationSystem 配置以下配置参数。

属性 说明
yarn.resourcemanager.reservation-system.enable 必填 参数：在 ResourceManager 中启用 ReservationSystem。预期布尔值。默认值为 false，即默认情况下未启用 ReservationSystem。
yarn.resourcemanager.reservation-system.class 可选 参数：ReservationSystem 的类名。根据配置的调度程序选择默认值，即如果配置了 CapacityScheduler，则为 CapacityReservationSystem。
yarn.resourcemanager.reservation-system.plan.follower 可选 参数：在计时器上运行的 PlanFollower 的类名，并将 CapacityScheduler 与 Plan 同步，反之亦然。根据配置的调度程序选择默认值，即如果配置了 CapacityScheduler，则为 CapacitySchedulerPlanFollower。
yarn.resourcemanager.reservation-system.planfollower.time-step 可选 参数：PlanFollower 计时器的毫秒频率。预期长值。默认值为 1000。

ReservationSystem 与 CapacityScheduler 队列层次结构集成，目前可以为任何 LeafQueue 配置。CapacityScheduler 支持以下参数来调整 ReservationSystem

属性 说明
yarn.scheduler.capacity.<queue-path>.reservable 必填 参数：向 ReservationSystem 指示队列的资源可供用户预留。预期布尔值。默认值为 false，即默认情况下未在 LeafQueues 中启用预留。
yarn.scheduler.capacity.<queue-path>.reservation-agent 可选 参数：用于确定 ReservationAgent 实现的类名，该实现将尝试将用户的预留请求放入 Plan 中。默认值为 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy。
yarn.scheduler.capacity.<queue-path>.reservation-move-on-expiry 可选 参数，用于向 ReservationSystem 指定当关联预留过期时，是否应将应用程序移至或终止到父可预留队列（如上所述）。预期布尔值。默认值为 true，表示应用程序将移至可预留队列。
yarn.scheduler.capacity.<queue-path>.show-reservations-as-queues 可选 参数，用于在调度程序 UI 中显示或隐藏预留队列。预期布尔值。默认值为 false，即隐藏预留队列。
yarn.scheduler.capacity.<queue-path>.reservation-policy 可选 参数：用于确定 SharingPolicy 实现的类名，该实现将验证新预留是否不会违反任何不变量。默认值为 org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy。
yarn.scheduler.capacity.<queue-path>.reservation-window 表示 SharingPolicy 将验证计划中的约束是否得到满足的时间（以毫秒为单位）的可选参数。预期为长整型值。默认值为一天。
yarn.scheduler.capacity.<queue-path>.instantaneous-max-capacity 可选参数：SharingPolicy 允许单个用户预留的任何时间的最大容量，以浮点数表示的百分比 (%)。默认值为 1，即 100%。
yarn.scheduler.capacity.<queue-path>.average-capacity 可选参数：SharingPolicy 允许单个用户预留的平均允许容量，以浮点数表示的百分比 (%)，将在 ReservationWindow 中聚合。默认值为 1，即 100%。
yarn.scheduler.capacity.<queue-path>.reservation-planner 可选参数：用于确定 Planner 实现的类名，如果 Plan 容量低于（由于计划维护或节点故障）用户预留的资源，则将调用该类名。默认值为 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner，它将扫描 Plan 并按相反的接受顺序（LIFO）贪婪地删除预订，直到预留的资源在 Plan 容量内
yarn.scheduler.capacity.<queue-path>.reservation-enforcement-window 表示 Planner 将验证计划中的约束是否得到满足的时间（以毫秒为单位）的可选参数。预期为长整型值。默认值为一小时。

叶队列的动态自动创建和管理

CapacityScheduler 支持在已配置为启用此功能的父队列下自动创建叶队列。

  • 通过队列映射设置动态自动创建的叶队列

yarn.scheduler.capacity.queue-mappings 中列出的用户组队列映射需要指定一个附加的父队列参数，以标识需要在哪个父队列下创建自动创建的叶队列。有关更多详细信息，请参阅上面的基于用户或组的队列映射部分。请注意，此类父队列还需要启用子队列的自动创建，如以下动态叶队列创建和管理的父队列配置部分中所述

示例

 <property>
   <name>yarn.scheduler.capacity.queue-mappings</name>
   <value>u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1.%user</value>
   <description>
     Here, u:%user:parent1.%user mapping allows any <user> other than user1,
     user2 to be mapped to its own user specific leaf queue which
     will be auto-created under <parent1>.
   </description>
 </property>
  • 动态叶队列自动创建和管理的父队列配置

动态队列自动创建和管理功能与 CapacityScheduler 队列层次结构集成，目前可以为 ParentQueue 配置为自动创建叶队列。此类父队列不支持其他预配置队列与自动创建的队列共存。CapacityScheduler 支持以下参数以启用队列的自动创建

属性 说明
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.enabled 必填参数：指示CapacityScheduler需要为指定的父队列启用自动叶队列创建。预期布尔值。默认值为false，即默认情况下不会在ParentQueue中启用自动叶队列创建。
yarn.scheduler.capacity.<queue-path>.auto-create-child-queue.management-policy 可选参数：用于确定AutoCreatedQueueManagementPolicy实现的类名，该实现将在该父队列下动态管理叶队列及其容量。默认值为org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.queuemanagement.GuaranteedOrZeroCapacityOverTimePolicy。用户或组可以在有限的时间内向自动创建的叶队列提交应用程序，然后停止使用它们。因此，在父队列下自动创建的叶队列数量可能多于其保证容量。当前策略实现根据父队列上的容量可用性和叶队列中的应用程序提交顺序，以尽力而为的方式分配配置的容量或零容量。
  • 使用CapacityScheduler配置自动创建的叶队列

已启用自动叶队列创建的父队列支持自动创建的叶队列的自动配置的模板参数配置。自动创建的队列支持除队列 ACL、绝对资源配置之外的所有叶队列配置参数。队列 ACL 当前从父队列继承，即它们无法在叶队列模板上配置

属性 说明
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.capacity 必填参数：指定自动创建的叶队列的最小保证容量。当前，自动创建的叶队列不支持绝对资源配置
yarn.scheduler.capacity.<queue-path>.leaf-queue-template.<leaf-queue-property> 可选参数：对于可以在自动创建的叶队列上配置的其他队列参数，如 maximum-capacity、user-limit-factor、maximum-am-resource-percent … - 请参阅队列属性部分

示例

 <property>
   <name>yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled</name>
   <value>true</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity</name>
    <value>5</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity</name>
    <value>100</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor</name>
    <value>3.0</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy</name>
    <value>fair</value>
 </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.GPU.capacity</name>
    <value>50</value>
 </property>
 <property>
     <name>yarn.scheduler.capacity.root.parent1.accessible-node-labels</name>
     <value>GPU,SSD</value>
   </property>
 <property>
     <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels</name>
     <value>GPU</value>
  </property>
 <property>
    <name>yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels.GPU.capacity</name>
    <value>5</value>
 </property>
  • 自动创建的队列管理的调度编辑策略配置

管理员需要将其他org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.QueueManagementDynamicEditPolicy调度编辑策略指定为当前调度编辑策略列表，并在yarn.resourcemanager.scheduler.monitor.policies配置中以逗号分隔的字符串形式指定。有关更多详细信息，请参阅上面的Capacity Scheduler 容器抢占部分

属性 说明
yarn.resourcemanager.monitor.capacity.queue-management.monitoring-interval 调用此 QueueManagementDynamicEditPolicy 策略之间的毫秒数。默认值为 1500

其他属性

  • 资源计算器
属性 说明
yarn.scheduler.capacity.resource-calculator 在调度程序中比较资源时要使用的 ResourceCalculator 实现。默认值，即 org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator，仅使用内存，而 DominantResourceCalculator 使用 Dominant-resource 比较多维资源，如内存、CPU 等。需要一个 Java ResourceCalculator 类名。
  • 数据局部性

容量调度程序利用延迟调度来遵守任务位置限制。位置限制有 3 个级别：节点本地、机架本地和非交换机。当无法满足位置限制时，调度程序会计算错失机会的次数，并等待此次数达到阈值，然后将位置限制放宽到下一级别。可以在以下属性中配置阈值

属性 说明
yarn.scheduler.capacity.node-locality-delay 错失调度机会的次数，在达到此次数后，CapacityScheduler 会尝试调度机架本地容器。通常，此次数应设置为集群中的节点数。默认情况下，将设置大约为一个机架中的节点数，即 40。预期为正整数。
yarn.scheduler.capacity.rack-locality-additional-delay 超过 node-locality-delay 的额外错失调度机会的次数，在达到此次数后，CapacityScheduler 会尝试调度非交换机容器。默认情况下，此值设置为 -1，在这种情况下，分配非交换机容器的错失机会数将根据以下公式计算：L * C / N，其中L是资源请求中指定的位置（节点或机架）数，C是请求的容器数，N是集群的大小。

请注意，如果 YARN 与文件系统分开部署，则应禁用此功能，因为位置限制没有意义。可以通过将yarn.scheduler.capacity.node-locality-delay设置为-1来实现此目的，在这种情况下，将忽略请求的位置限制。

  • 每个 NodeManager 心跳的容器分配

CapacityScheduler 支持以下参数来控制可以在每个 NodeManager 心跳中分配多少个容器。可以通过yarn rmadmin -refreshQueues刷新这些参数。

属性 说明
yarn.scheduler.capacity.per-node-heartbeat.multiple-assignments-enabled 是否允许在一个 NodeManager 心跳中进行多个容器分配。默认为 true。
yarn.scheduler.capacity.per-node-heartbeat.maximum-container-assignments 如果multiple-assignments-enabled为 true，则可以在一个 NodeManager 心跳中分配的最大容器数。默认值为 100，这将每个心跳的容器分配最大数限制为 100。将此值设置为 -1 将禁用此限制。
yarn.scheduler.capacity.per-node-heartbeat.maximum-offswitch-assignments 如果multiple-assignments-enabled为 true，则可以在一个 NodeManager 心跳中分配的最大非交换机容器数。默认为 1，表示在一个心跳中只允许一个非交换机分配。

查看 CapacityScheduler 的配置

安装和配置完成后，可以在从 Web UI 启动 YARN 集群后查看它。

  • 以正常方式启动 YARN 集群。

  • 打开ResourceManager Web UI。

  • /scheduler 网页应显示各个队列的资源使用情况。

更改队列配置

可以通过两种方式（通过文件或 API）来更改队列/调度程序属性以及添加/删除队列。此行为可以通过 yarn-site.xml 中的 yarn.scheduler.configuration.store.class 进行更改。可能的值有：file，允许通过文件修改属性；memory，允许通过 API 修改属性，但不会在重启时保留更改；leveldb，允许通过 API 修改属性并将更改存储在 leveldb 后备存储中；zk，允许通过 API 修改属性并将更改存储在 zookeeper 后备存储中。默认值为 file。

通过文件更改队列配置

要通过文件编辑，您需要编辑 conf/capacity-scheduler.xml 并运行 yarn rmadmin -refreshQueues。

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

通过文件删除队列

步骤 1：停止队列

在删除叶队列之前，叶队列不应有任何正在运行/待处理的应用，并且必须通过更改 yarn.scheduler.capacity.<queue-path>.state 来停止。请参阅 [队列管理和权限](CapacityScheduler.html#Queue Properties) 部分。在删除父队列之前，其所有子队列不应有任何正在运行/待处理的应用，并且必须停止。父队列也需要停止

步骤 2：删除队列

从文件中删除队列配置并按上述方式运行刷新

通过 API 更改队列配置

通过 API 编辑使用调度程序配置的后备存储。要启用此功能，可以在 yarn-site.xml 中配置以下参数。

注意：此功能处于 alpha 阶段，可能会发生更改。

属性 说明
yarn.scheduler.configuration.store.class 要使用的后备存储类型，如 上文所述。
yarn.scheduler.configuration.mutation.acl-policy.class 可以配置 ACL 策略来限制哪些用户可以修改哪些队列。默认值为 org.apache.hadoop.yarn.server.resourcemanager.scheduler.DefaultConfigurationMutationACLPolicy，它只允许 YARN 管理员进行任何配置修改。另一个值是 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.conf.QueueAdminConfigurationMutationACLPolicy，它只允许在调用者是队列管理员的情况下修改队列。
yarn.scheduler.configuration.store.max-logs 配置更改会记录在后备存储中（如果使用 leveldb 或 zookeeper）。此配置控制要存储的最大审计日志数，在超过时删除最旧的日志。默认值为 1000。
yarn.scheduler.configuration.leveldb-store.path 使用 leveldb 时，配置存储的存储路径。默认值为 ${hadoop.tmp.dir}/yarn/system/confstore。
yarn.scheduler.configuration.leveldb-store.compaction-interval-secs 使用 leveldb 时，以秒为单位压缩配置存储的时间间隔。默认值为 86400，即一天。
yarn.scheduler.configuration.zk-store.parent-path 使用 zookeeper 时，配置存储相关信息的 zookeeper 根节点路径。默认值为 /confstore。

注意：通过 yarn.scheduler.configuration.store.class 启用调度程序配置变更时，将禁用 yarn rmadmin -refreshQueues，即不再可以通过文件更新配置。

请参阅 YARN 资源管理器 REST API，了解如何通过 REST 更改调度程序配置，以及 YARN 命令参考，了解如何通过命令行更改调度程序配置。

更新容器（实验性 - API 可能在未来发生更改）

应用程序主服务器从资源管理器接收容器后，它可以请求资源管理器更新容器的某些属性。

目前仅支持两种类型的容器更新

  • 资源更新：应用程序主服务器可以请求资源管理器更新容器的资源大小。例如：将容器从 2GB、2 个 vcore 容器更改为 4GB、2 个 vcore 容器。
  • 执行类型更新：应用程序主服务器可以请求资源管理器更新容器的执行类型。例如：将执行类型从 GUARANTEED 更改为 OPPORTUNISTIC，反之亦然。

应用程序主服务器通过填充 updated_containers 字段来实现此目的，该字段是 AllocateRequestProto 中的 UpdateContainerRequestProto 类型列表。应用程序主服务器可以在同一分配调用中进行多个容器更新请求。

UpdateContainerRequestProto 的架构如下

message UpdateContainerRequestProto {
  required int32 container_version = 1;
  required ContainerIdProto container_id = 2;
  required ContainerUpdateTypeProto update_type = 3;
  optional ResourceProto capability = 4;
  optional ExecutionTypeProto execution_type = 5;
}

ContainerUpdateTypeProto 是一个枚举

enum ContainerUpdateTypeProto {
  INCREASE_RESOURCE = 0;
  DECREASE_RESOURCE = 1;
  PROMOTE_EXECUTION_TYPE = 2;
  DEMOTE_EXECUTION_TYPE = 3;
}

如上枚举所限，调度程序目前支持在一个更新请求中更改容器的资源更新或执行类型。

应用程序主服务器还必须提供从资源管理器接收到的最新 ContainerProto。这是资源管理器将尝试更新的容器。

如果 RM 能够更新请求的容器，则将返回更新的容器，在 AllocateResponseProto 返回值中类型为 UpdatedContainerProto 的 updated_containers 列表字段中，该返回值属于同一分配调用或后续调用之一。

UpdatedContainerProto 的架构如下

message UpdatedContainerProto {
  required ContainerUpdateTypeProto update_type = 1;
  required ContainerProto container = 2;
}

它指定在容器上执行的容器更新类型和包含更新令牌的更新容器对象。

然后，AM 可以使用容器令牌要求相应的 NM 启动容器（如果尚未启动容器）或使用更新令牌更新容器。

DECREASE_RESOURCE 和 DEMOTE_EXECUTION_TYPE 容器更新是自动的 - AM 不必明确要求 NM 减少容器的资源。其他更新类型要求 AM 明确要求 NM 更新容器。

如果 yarn.resourcemanager.auto-update.containers 配置参数设置为 true（默认情况下为 false），则 RM 将确保所有容器更新都是自动的。

活动

调度活动是用于在某些关键调度路径上进行调试的活动消息，它们可以通过 RESTful API 记录和公开，对调度程序性能的影响很小。目前，支持两种类型的活动：调度程序活动和应用程序活动。

调度程序活动

调度程序活动包括调度周期中的有用调度信息，说明调度程序如何分配容器。调度程序活动 REST API (http://rm-http-address:port/ws/v1/cluster/scheduler/activities) 提供了一种启用记录调度程序活动并从缓存中获取它们的方法。为了消除性能影响，调度程序会在调度周期结束时自动禁用记录活动，您可以再次查询 RESTful API 以获取最新的调度程序活动。

有关查询参数、输出结构和调度程序活动的示例，请参阅 YARN 资源管理器 REST API。

应用程序活动

应用程序活动包括指定应用程序的有用调度信息，说明如何满足或跳过要求。应用程序活动 REST API (http://rm-http-address:port/ws/v1/cluster/scheduler/app-activities/{appid}) 提供了一种在几秒钟内启用记录指定应用程序的应用程序活动或从缓存中获取历史应用程序活动的方法，可以通过“actions”参数指定可用的操作，包括“refresh”和“get”。

  • 带参数“actions=refresh”的查询将启用记录指定应用程序的应用程序活动一段时间（默认为 3 秒），并获得简单的响应，如：{“appActivities”:{“applicationId”:“application_1562308866454_0001”,“diagnostic”:“Successfully received action: refresh”,“timestamp”:1562308869253,“dateTime”:“2019 年 7 月 5 日星期五下午 2:41:09 CST”}}。
  • 带参数“actions=get”的查询不会启用记录，而是直接从缓存获取历史应用程序活动。
  • 如果没有指定操作参数，则默认操作为“refresh,get”，这意味着将执行“refresh”和“get”。

请参阅 YARN 资源管理器 REST API 以了解有关应用程序活动的查询参数、输出结构和示例。

配置

CapacityScheduler 支持以下参数来控制缓存大小和调度程序/应用程序活动的过期时间。

属性 说明
yarn.resourcemanager.activities-manager.cleanup-interval-ms 以毫秒为单位的活动清理间隔。默认为 5000。
yarn.resourcemanager.activities-manager.scheduler-activities.ttl-ms 以毫秒为单位的调度程序活动生存时间。默认为 600000。
yarn.resourcemanager.activities-manager.app-activities.ttl-ms 以毫秒为单位的应用程序活动生存时间。默认为 600000。
yarn.resourcemanager.activities-manager.app-activities.max-queue-length 应用程序活动的队列最大长度。默认为 100。

Web UI

活动信息可在 RM Web UI 上的应用程序尝试页面中获得，其中会汇总和显示未完成的请求。只需单击刷新按钮即可获取最新的活动信息。