本文详细介绍了Hadoop中的Capacity Scheduler调度器，它允许多租户共享集群资源。阐述了其设计目标、功能，如分层队列、容量保证等，还说明了配置方法，包括队列设置、属性配置等，以及容器抢占、预留属性等内容，最后介绍了活动信息查看和配置更改方式。
Hadoop Capacity Scheduler 调度用法官网权威示例详解:
文章目录
目的
本文档介绍了CapacityScheduler，它是Hadoop中的一种可插拔调度器，允许多个租户在分配容量的约束条件下及时地共享一个大型集群来分配资源。
概述
CapacityScheduler旨在以操作员友好的方式运行Hadoop应用程序作为一个共享的多租户集群，同时最大限度地提高集群的吞吐量和利用率。
传统上，每个组织都有自己的专用计算资源，这些资源具有足够的容量以满足组织在峰值或接近峰值条件下的SLA。这通常导致平均利用率较低，并且管理多个独立集群的开销很高，每个组织一个集群。在组织之间共享集群是运行大型Hadoop安装的一种经济有效的方式，因为这使得它们能够在不创建私有集群的情况下获得规模经济效益的好处。但是，组织担心共享集群，因为他们担心其他人使用对他们的SLA至关重要的资源。
CapacityScheduler的设计目标是允许在给每个组织提供容量保证的同时共享一个大型集群。其核心思想是将Hadoop集群中的可用资源共享给多个共同资助集群的组织，这些组织根据自己的计算需求进行资助。另一个好处是组织可以访问其他人未使用的任何额外容量。这以一种经济高效的方式为组织提供了弹性。
在组织之间共享集群需要对多租户的强大支持，因为每个组织必须得到容量保证，并确保共享集群对于单个错误应用程序、用户或者多个应用程序、用户而言是安全的。CapacityScheduler提供了一系列严格的限制，以确保单个应用程序、用户或队列无法在集群中消耗不成比例的资源量。此外，CapacityScheduler对来自单个用户和队列的初始化和挂起的应用程序设置了限制，以确保集群的公平性和稳定性。
CapacityScheduler提供的主要抽象是队列的概念。这些队列通常由管理员设置，以反映共享集群的经济情况。
为了进一步控制和预测资源的共享，CapacityScheduler支持分层队列，以确保资源在组织的子队列之间共享，然后允许其他队列使用空闲资源，从而为给定组织的应用程序共享空闲资源提供亲和性。
功能
CapacityScheduler支持以下功能：
- 分层队列：支持队列之间的层次结构，以确保在其他队列被允许使用空闲资源之前，组织的子队列之间共享资源，从而提供更多的控制和可预测性。
- 容量保证：为队列分配一定比例（百分比）或绝对资源队列的最小容量。所有提交到队列的应用程序都可以访问队列分配的容量。管理员可以为每个队列配置软限制和可选的硬限制。
- 安全性：每个队列都有严格的ACL（访问控制列表），控制谁可以向单个队列提交应用程序。此外，还有安全措施，以确保用户无法查看和/或修改其他用户的应用程序。还支持队列级别和系统管理员角色。
- 弹性：可以将空闲资源分配给超过其容量的任何队列。当未来某个时间点上运行低于容量的队列上的任务完成时，如果这些资源需要来自该队列的需求，则会将它们分配给运行低于容量的队列上的应用程序（也支持抢占）。这样可以以可预测和弹性的方式为队列提供资源，从而防止集群中的人为资源隔离。
- 多租户：提供了一套全面的限制，以防止单个应用程序、用户和队列垄断队列或整个集群的资源，以确保集群不会被压垮。
- 可操作性：
- 运行时配置：管理员可以在运行时以安全的方式更改队列定义和属性，以最小化对用户的干扰。还提供了一个控制台供用户和管理员查看系统中各个队列当前分配的资源。管理员可以在运行时添加其他队列，但除非队列处于STOPPED状态且没有待处理/运行中的应用程序，否则不能在运行时删除队列。
- 应用程序排空：管理员可以在运行时停止队列，以确保现有的应用程序运行完成后，无法提交新的应用程序。如果队列处于STOPPED状态，则无法将新的应用程序提交给其自身或任何子队列。现有的应用程序继续运行，因此队列可以优雅地排空。管理员还可以启动已停止的队列。
- 基于资源的调度：支持资源密集型应用程序，其中应用程序可以选择指定比默认值更高的资源要求，从而适应具有不同资源要求的应用程序。目前，只支持内存资源要求。
- 基于默认规则或用户定义规则的队列映射接口：此功能允许用户根据一些默认放置规则将作业映射到特定队列。例如，基于用户和组，或者基于应用程序名称。用户还可以定义自己的放置规则。
- 优先级调度：此功能允许提交和调度具有不同优先级的应用程序。较高的整数值表示较高的优先级。目前，仅支持FIFO排序策略的应用程序优先级。
配置
配置ResourceManager使用CapacityScheduler
要配置ResourceManager使用CapacityScheduler，请在conf/yarn-site.xml中设置以下属性：
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>
设置队列
etc/hadoop/capacity-scheduler.xml是CapacityScheduler的配置文件。
CapacityScheduler有一个预定义的根队列（root）。系统中的所有队列都是根队列的子队列。
可以通过配置yarn.scheduler.capacity.root.queues属性以逗号分隔的子队列列表来设置更多的队列。
CapacityScheduler的配置使用了称为队列路径的概念来配置队列的层次结构。队列路径是队列层次结构的完整路径，从根队列开始，以点（.）作为分隔符。
可以使用配置参数yarn.scheduler.capacity..queues来定义给定队列的子队列。子队列不会直接从父队列继承属性，除非另有说明。
以下是一个示例，其中有三个顶级子队列a、b和c，以及a和b的一些子队列：
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b,c</value>
<description>The queues at 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 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 this level (root is the root queue).</description>
</property>
队列属性
资源分配
| Property | Description |
|---|---|
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％的资源，则将此属性设置为1.5。用户B和C将默认为1.0。 |
使用绝对资源配置进行资源分配
CapacityScheduler支持使用绝对资源配置而不是以百分比提供队列容量。如上所述，对于yarn.scheduler.capacity.<queue-path>.capacity和yarn.scheduler.capacity.<queue-path>.max-capacity的配置，管理员可以指定一个绝对资源值，例如[内存=10240，虚拟内核数=12]。这是有效的配置，表示10GB内存和12个VCores。
运行和挂起应用程序限制
CapacityScheduler支持以下参数来控制运行和挂起的应用程序：
| Property | Description |
|---|---|
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 | 特定用户可以同时运行的最大应用程序数。这将覆盖全局设置。 |
这些限制的评估按以下顺序进行：
maximum-applications检查 - 如果超过了限制，则立即拒绝提交。max-parallel-apps检查 - 接受提交，但应用程序不会转换为RUNNING状态。它保持在ACCEPTED状态，直到满足队列/用户限制。maximum-am-resource-percent检查 - 如果有太多的Application Masters在运行，则应用程序保持在ACCEPTED状态，直到有足够的空间。
队列管理和权限
CapacityScheduler支持以下参数来管理队列：
| Property | Description |
|---|---|
yarn.scheduler.capacity.<queue-path>.state | 队列的状态。可以是RUNNING或STOPPED之一。**如果队列处于STOPPED状态，则无法将新的应用程序提交给它自身或其任何子队列。因此，如果根队列处于STOPPED状态，则无法向整个集群提交应用程序。**现有的应用程序继续完成，因此队列可以平稳地排空。指定为枚举值。 |
yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications | 控制谁可以向给定队列提交应用程序的ACL。如果给定的用户/组在给定队列或层次结构中的任何一个父队列上具有必要的ACL，则可以提交应用程序。如果在此列表中的用户名前面加上波浪符（~），则实际用户的ACL将允许代理用户提交到队列。 |
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue | 控制谁可以管理给定队列上的应用程序的ACL。如果给定的用户/组在给定队列或层次结构中的任何一个父队列上具有必要的ACL，则可以管理应用程序。如果在此列表中的用户名前面加上波浪符（~），则实际用户的ACL将允许代理用户管理队列上的应用程序。 |
注意：ACL的格式为user1，user2 space group1，group2。 表示任何人。 空格表示没有人。如果未指定，则根队列的默认值为。
基于用户、组、应用程序名称或用户定义的放置规则的队列映射
CapacityScheduler支持以下参数来基于用户、组、用户和组或应用程序名称进行队列映射。用户还可以定义自己的放置规则：
| Property | Description |
|---|---|
yarn.scheduler.capacity.queue-mappings | 此配置指定将用户或组映射到特定队列。您可以将单个用户或一组用户映射到队列。语法：[u or g]:[name]:[queue_name][,next_mapping]*。这里，u或g表示映射是为用户还是组。值为u表示用户，值为g表示组。name表示用户名或组名。要指定提交应用程序的用户，可以使用%user。queue_name表示要将应用程序映射到的队列名称。要将队列名称指定为与用户名相同，请使用%user。要将队列名称指定为与用户所属的主要组名相同，请使用%primary_group。次要组可以引用为%secondary_group。 |
yarn.scheduler.queue-placement-rules.app-name | 此配置指定将应用程序名称映射到特定队列。您可以将单个应用程序或一组应用程序映射到队列。语法：[app_name]:[queue_name][,next_mapping]*。这里，app_name表示要进行映射的应用程序名称。queue_name表示要将应用程序映射到的队列名称。要将当前应用程序的名称作为app_name，请使用%application。 |
yarn.scheduler.capacity.queue-mappings-override.enable | 此功能用于指定是否可以覆盖用户指定的队列。这是一个布尔值，默认值为false。 |
CapacityScheduler配置示例
以下示例涵盖了单个映射的配置。在存在多个映射并使用逗号分隔值的情况下，评估将从左到右进行，并且将使用第一个有效的映射。下面的示例顺序是基于运行时实际执行顺序记录的，在存在多个映射的情况下。
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:%user:%primary_group.%user</value>
<description>将用户映射到与用户名相同的队列，但父级队列名称应与用户的主要组相同</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:%user:%secondary_group.%user</value>
<description>将用户映射到与用户名相同的队列，但父级队列名称应与用户的任何次要组相同</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:%user:%user</value>
<description>将用户映射到与用户名相同的队列</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user2:%primary_group</value>
<description>将user2映射到与主要组相同的队列名称</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user3:%secondary_group</value>
<description>将user3映射到与次要组相同的队列名称</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1</value>
<description>将user1映射到queue1</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>g:group1:queue2</value>
<description>将group1映射到queue2</description>
</property>
<property>
<name>yarn.scheduler.capacity.queue-mappings</name>
<value>u:user1:queue1,u:user2:queue2</value>
<description>在这里，<user1>映射到<queue1>，<user2>映射到<queue2></description>
</property>
<property>
<name>yarn.scheduler.queue-placement-rules.app-name</name>
<value>appName1:queue1,%application:%application</value>
<description>
这里，<appName1>映射到<queue1>，将应用程序映射到与应用程序名称相同的队列。映射将从左到右进行评估，并使用第一个有效的映射。
</description>
</property>
上述示例中的配置是用于配置CapacityScheduler的队列映射和队列规则。根据用户、用户组和应用程序名称，可以将其映射到不同的队列。您可以根据实际需求进行修改和扩展。
应用程序的队列生命周期
CapacityScheduler支持以下参数来控制应用程序的生命周期：
| 属性 | 描述 |
|---|---|
| yarn.scheduler.capacity..maximum-application-lifetime | 提交到队列的应用程序的最大生命周期（以秒为单位）。任何小于等于零的值将被视为禁用。默认值为-1。如果配置了正值，则超过配置的生命周期的应用程序将被终止。用户还可以在应用程序提交上下文中指定每个应用程序的生命周期。但是，如果用户生命周期超过队列最大生命周期，则会覆盖用户指定的值。这是一个即时配置。注意：此功能可以在队列层次结构的任何级别进行设置。子队列将继承其父队列的值，除非在子级别上覆盖。值为0表示无最大生命周期，并将覆盖父级的最大生命周期。如果未设置此属性或将其设置为负数，则此队列的最大生命周期值将继承自其父级。 |
yarn.scheduler.capacity.root..default-application-lifetime | 提交到队列的应用程序的默认生命周期（以秒为单位）。任何小于等于零的值将被视为禁用。如果用户未提交带有生命周期值的应用程序，则将采用此值。这是一个即时配置。此功能可以在队列层次结构的任何级别进行设置。子队列将继承其父队列的值，除非在子级别上覆盖。如果设置为小于等于0，则队列的最大值也必须是无限的。默认生命周期不能超过最大生命周期。
应用程序优先级设置
应用程序优先级仅在FIFO排序策略下工作。默认的排序策略是FIFO。
应用程序的默认优先级可以在集群级别和队列级别进行设置。
集群级别优先级：
通过配置文件$HADOOP_HOME/etc/hadoop/yarn-site.xml中的yarn.cluster.max-application-priority参数来定义集群中的最大应用程序优先级。
队列级别优先级：
每个叶子队列都提供了默认的优先级，由管理员指定。如果用户没有指定优先级，则将使用队列的默认优先级。
请注意，当应用程序移动到不同的队列时，其优先级不会更改。
容器抢占
容量调度器支持对资源使用超过保证容量的队列中的容器进行抢占。为了支持应用程序容器的预抢占，需要在yarn-site.xml中启用以下配置参数：
<property>
<name>yarn.resourcemanager.scheduler.monitor.enable</name>
<value>true</value>
<description>启用一组周期性监视器，这些监视器会影响调度器。默认值为false。</description>
</property>
<property>
<name>yarn.resourcemanager.scheduler.monitor.policies</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy</value>
<description>与调度器交互的一组SchedulingEditPolicy类。配置的策略需要与调度器兼容。默认值为org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy，它与CapacityScheduler兼容。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.observe_only</name>
<value>false</value>
<description>如果设置为true，则运行策略，但不会对集群进行抢占和杀死事件的影响。默认值为false。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval</name>
<value>3000</value>
<description>此ProportionalCapacityPreemptionPolicy策略的调用之间的时间间隔（以毫秒为单位）。默认值为3000。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill</name>
<value>15000</value>
<description>从请求预抢占到杀死容器之间的时间间隔（以毫秒为单位）。默认值为15000。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round</name>
<value>0.1</value>
<description>单个轮次中抢占的资源百分比的最大值。通过控制此值，可以控制从群集中重新获取容器的速度。在计算出总的期望抢占量后，策略会在此限制范围内进行缩减。默认值为0.1。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.max_ignored_over_capacity</name>
<value>0.1</value>
<description>忽略的目标容量之上的最大资源量。这定义了目标容量周围的死区，有助于防止在计算出的目标平衡周围产生抖动和振荡。较高的值会降低到达容量所需的时间，并且（除非自然完成）可能会阻止达到保证容量。默认值为0.1。</description>
</property>
<property>
<name>yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor</name>
<value>0.2</value>
<description>给定计算的抢占目标，考虑容器自然过期，并只对此百分比的增量进行抢占。这确定了进入死区（MAX_IGNORED_OVER_CAPACITY）的几何收敛速度。例如，终止因子为0.5将在5 * #WAIT_TIME_BEFORE_KILL内回收近95%的资源，即使没有自然终止。默认值为0.2。</description>
</property>
上述配置参数用于控制容器抢占的行为。您可以根据实际需求进行调整和优化。
预留属性
预留管理和权限
CapacityScheduler支持以下参数来控制预留的创建、删除、更新和列出。请注意，任何用户都可以更新、删除或列出自己的预留。如果启用了预留的ACL但未定义，则每个人都将具有访问权限。在下面的示例中，<queue>是队列名称。例如，要将预留ACL设置为管理默认队列上的预留，请使用属性yarn.scheduler.capacity.root.default.acl_administer_reservations。
<property>
<name>yarn.scheduler.capacity.root.<queue>.acl_administer_reservations</name>
<value>admin_user, admin_group</value>
<description>用于控制谁可以管理给定队列的预留的ACL。如果给定的用户/组对给定队列具有必要的ACL，或者他们可以提交、删除、更新和列出所有预留。如果未指定该属性，则从父队列继承其值。</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.<queue>.acl_list_reservations</name>
<value>user1, group1</value>
<description>用于控制谁可以列出给定队列的预留的ACL。如果给定的用户/组对给定队列具有必要的ACL，则他们可以列出所有预留。如果未指定该属性，则从父队列继承其值。</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.<queue>.acl_submit_reservations</name>
<value>user2, group2</value>
<description>用于控制谁可以提交给定队列的预留的ACL。如果给定的用户/组对给定队列具有必要的ACL，则他们可以提交预留。如果未指定该属性，则从父队列继承其值。</description>
</property>
配置ReservationSystem与CapacityScheduler
CapacityScheduler支持ReservationSystem，允许用户提前预留资源。应用程序可以在运行时通过指定预留ID来请求预留的资源。以下配置参数可以在yarn-site.xml中进行配置。
<property>
<name>yarn.resourcemanager.reservation-system.enable</name>
<value>true</value>
<description>启用ReservationSystem在ResourceManager中。布尔值。默认值为false，即默认情况下未启用ReservationSystem。</description>
</property>
<property>
<name>yarn.resourcemanager.reservation-system.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityReservationSystem</value>
<description>ReservationSystem的类名。默认值根据配置的调度器选择，默认情况下为CapacityReservationSystem。</description>
</property>
<property>
<name>yarn.resourcemanager.reservation-system.plan.follower</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.CapacitySchedulerPlanFollower</value>
<description>在计时器上运行并使CapacityScheduler与计划之间同步的PlanFollower的类名。默认值根据配置的调度器选择，默认情况下为CapacitySchedulerPlanFollower。</description>
</property>
<property>
<name>yarn.resourcemanager.reservation-system.planfollower.time-step</name>
<value>1000</value>
<description>PlanFollower计时器的时间间隔（以毫秒为单位）。长整型值。默认值为1000。</description>
</property>
ReservationSystem与CapacityScheduler集成，并可配置在任何叶子队列上进行预创建。CapacityScheduler支持以下参数来调整ReservationSystem：
<property>
<name>yarn.scheduler.capacity.<queue-path>.reservable</name>
<value>true</value>
<description>指示ReservationSystem可以预留指定父队列的资源。布尔值。默认值为false，即默认情况下未启用预留功能。</description>
</property>
<property>
<name>yarn.scheduler.capacity.<queue-path>.reservation-agent</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.GreedyReservationAgent</value>
<description>用于确定预留请求的计划实施的类名。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.GreedyReservationAgent。</description>
</property>
上述参数用于控制预留系统的行为。您可以根据需求进行自定义和调整。
动态自动创建和管理叶子队列
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>
这里，u:%user:parent1.%user的映射允许任何<user>（不包括user1、user2）被映射到其自己的特定用户叶子队列，
该队列将自动创建在<parent1>下面。
</description>
</property>
用于动态叶子队列自动创建和管理的父队列配置
动态队列自动创建和管理功能与CapacityScheduler队列层次结构集成，并可以为父队列配置自动创建叶子队列。这样的父队列不支持与自动创建队列同时存在的其他预配置队列。CapacityScheduler支持以下参数以启用队列的自动创建功能。
| 属性 | 描述 |
|---|---|
| yarn.scheduler.capacity..auto-create-child-queue.enabled | 必需参数：指示CapacityScheduler是否需要为指定的父队列启用自动创建叶子队列功能。期望布尔值。默认值为false，即默认情况下未启用ParentQueue中的自动创建叶子队列。 |
| yarn.scheduler.capacity..auto-create-child-queue.management-policy | 可选参数：用于确定AutoCreatedQueueManagementPolicy的实现的类名，该策略将在此父队列下动态管理叶子队列及其容量。默认值为org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.queuemanagement.GuaranteedOrZeroCapacityOverTimePolicy。用户或组可能会提交应用程序到自动创建的叶子队列，但仅限于有限的时间并停止使用它们。因此，自动创建的队列数量可能会超过父队列的保证容量。当前策略的实现基于父队列上的可用容量和应用程序提交顺序，根据最佳努力分配已配置的或零容量。 |
使用CapacityScheduler配置自动创建的叶子队列
已启用自动创建叶子队列的父队列支持模板参数的配置，以自动配置自动创建的叶子队列。自动创建的队列支持除队列ACL和绝对资源配置之外的所有叶子队列配置参数。队列ACL当前从父队列继承，即无法在叶子队列模板上进行配置。
| 属性 | 描述 |
|---|---|
| yarn.scheduler.capacity..leaf-queue-template.capacity | 必需参数：指定自动创建的叶子队列的最小保证容量。目前不支持在自动创建的叶子队列上进行绝对资源配置。 |
| yarn.scheduler.capacity..leaf-queue-template. | 可选参数：用于在自动创建的叶子队列上配置的其他队列参数，例如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使用主要资源来比较多维资源，例如内存、CPU等。期望一个Java ResourceCalculator类名。 |
数据本地性
Capacity Scheduler利用延迟调度来满足任务本地性约束。有三个级别的本地性约束：节点本地、机架本地和离开本地。调度程序计算无法满足本地性的机会数，并在达到阈值之前等待此计数以放宽下一级别的本地性约束。可以在以下属性中配置阈值：
| 属性 | 描述 |
|---|---|
| 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的配置
安装和配置完成后，您可以在启动YARN集群后从Web界面上查看它。
以正常方式启动YARN集群。
打开ResourceManager Web界面。
/scheduler网页应显示各个队列的资源使用情况。
更改队列配置
可以通过文件或API的两种方式进行更改队列/调度程序属性和添加/删除队列。此行为可以通过yarn.scheduler.configuration.store.class在yarn-site.xml中进行更改。可能的值是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..state来停止。请参阅“队列管理和权限”部分。在删除父队列之前，所有子队列都不应该有任何正在运行/挂起的应用程序，并且必须停止父队列。
步骤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，即不再可以通过文件更新配置。 |
有关如何通过REST更改调度程序配置的示例，请参阅YARN资源管理器REST API，并在YARN命令参考中查看如何通过命令行更改调度程序配置的示例。
更新容器（实验性——API可能会在未来发生更改）
一旦应用程序主节点从资源管理器接收到容器，它可以请求资源管理器更新容器的某些属性。
目前仅支持两种类型的容器更新：
资源更新：应用程序主节点可以请求RM更新容器的资源大小。例如：将容器从2GB、2个vcore的容器更改为4GB、2个vcore的容器。
ExecutionType更新：应用程序主节点可以请求RM更新容器的ExecutionType。例如：将执行类型从GUARANTEED更改为OPPORTUNISTIC，反之亦然。
这是通过AM在AllocateRequestProto中的updated_containers字段中填充UpdateContainerRequestProto类型的列表来实现的。AM可以在同一个allocate调用中进行多个容器更新请求。
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;
}
如上述枚举所限制的那样，调度程序目前支持在一个更新请求中更改容器的资源或executionType。
AM还必须提供它从RM接收到的最新ContainerProto。这是RM将尝试更新的容器。
如果RM能够更新请求的容器，则更新后的容器将以UpdatedContainerProto类型的updated_containers列表字段的形式返回，该字段包含在同一allocate调用的AllocateResponseProto返回值中或在随后的某个调用中。
UpdatedContainerProto的模式如下：
message UpdatedContainerProto {
required ContainerUpdateTypeProto update_type = 1;
required ContainerProto container = 2;
}
它指定了对容器执行的容器更新类型，并指定了容器对象，其中包含已更新的令牌。
然后，AM可以使用容器令牌要求相应的NM启动容器（如果容器尚未启动）或使用更新的令牌更新容器。
减少资源和降低ExecutionType的容器更新是自动完成的，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”:“Fri Jul 05 14:41:09 CST 2019”}}。
使用参数“actions=get”将不会启用记录，而是直接从缓存中获取历史应用程序活动。
如果没有指定actions参数，默认操作是“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界面
活动信息可在RM Web界面上的应用程序尝试页面中获得，其中聚合和显示了未完成请求。只需单击刷新按钮即可获取最新的活动信息。
-------------------------------------------- | ------------------------------------------------------ |
| 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界面
活动信息可在RM Web界面上的应用程序尝试页面中获得，其中聚合和显示了未完成请求。只需单击刷新按钮即可获取最新的活动信息。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
