本文是对Hadoop官方文档：Hadoop: Capacity Scheduler的翻译与Hadoop权威指南上知识的总结。
Capacity Scheduler是Hadoop的一个可插拔的调度组件，允许多租户安全地共享一个大型集群，以便在分配容量的约束下及时分配其应用程序的资源。
Capacity Scheduler被设计为以一种操作程序友好的方式将Hadoop应用程序作为共享的多租户集群运行，同时最大化集群的吞吐量和利用率。
传统分布式环境，每个组织都有自己的私有计算济源，这些计算资源集在峰值或接近峰值的情况下有足够的能力满足组织的SLA。在组织之间共享集群是运行大型Hadoop安装的一种经济有效的方式，因为这允许它们在不创建私有集群的情况下获得规模经济的好处。然而，组织关心共享集群，因为他们担心其他人使用对他们的SLA至关重要的资源。
跨组织共享群集需要对多租户提供强有力的支持，因为必须保证每个组织的容量和安全防护措施，以确保共享群集不受单个恶意应用程序或用户或其组的侵害。所述CapacityScheduler提供了一组严格的限制，以确保单个应用程序或用户或队列不能在集群中消耗的资源的量不成比例。另外，CapacityScheduler还限制了单个用户和队列中已初始化和待处理的应用程序，以确保集群的公平性和稳定性。
CapacityScheduler提供的主要抽象是队列的概念。这些队列通常由管理员设置，以反映共享群集的经济性。为了提供对资源共享的进一步控制和可预测性，CapacityScheduler支持*分层队列，*以确保在允许其他队列使用免费资源之前，在组织的子队列之间共享资源。
Capacity Scheduler支持以下特性:
STOPPED状态，则无法将新应用程序提交给它自己或其任何子队列。现有的应用程序继续完成，因此，队列可以排出正常。管理员还可以启动已停止的队列。要配置ResourceManager使用Capacity Schedule，需要在yarn-site.xml中设置:
| Property | Value |
|---|---|
yarn.resourcemanager.scheduler.class | org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler |
etc/hadoop/capacity-scheduler.xml是CapacityScheduler的配置文件。所述CapacityScheduler有一个称为队列根。系统中的所有队列都是根队列的子级。通过配置yarn.scheduler.capacity.root.queues并使用逗号分隔的子队列列表来设置其他队列。
<property>
<name> yarn.scheduler.capacity.root.queues </ name>
<value> a，b，c </ value>
<description>此级别上的队列（root是根队列）。
</ description>
</property>
<property>
<name> yarn.scheduler.capacity.root.a.queues </ name>
<value> a1，a2 </ value>
<description>此级别上的队列（root is the root queue）。
</ description>
</property>
<property>
<name> yarn.scheduler.capacity.root.b.queues </ name>
<value> b1，b2，b3 </ value>
<description>此级别的队列（root is the root queue）。
</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>.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-vcore。这个值必须小于或等于集群的最大值。 |
| 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。 .capacity和yarn.scheduler.capacity。 .max-capacity一样，管理员可以指定一个绝对资源值，例如[memory = 10240， vcores = 12]。这是有效的配置，指示10GB内存和12个VCore。
capacity调度器支持以下参数来控制运行和挂起的应用程序：
| 属性名 | 描述 |
|---|---|
yarn.scheduler.capacity.maximum-applications | 系统中可以同时处于活动状态(运行和挂起)的应用的最大值。每个队列上的限制与它们的队列容量和用户限制成正比。这是一个硬限制，当达到此限制时提交的任何申请都将被拒绝。默认是10000。yarn.scheduler.capacity.maximum-applications为所有队列设置 |
| yarn.scheduler.capacity.<queue-path>.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 | - |
| 属性名 | 描述 |
|---|---|
| yarn.scheduler.capacity.<queue-path>.state | 队列的状态。可以是RUNNING或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将从父队列继承。 |
一个访问控制列表的形式为用户1，用户2，空间 1组，第2组。
capacity scheduler支持以下参数来配置基于用户或组、用户&组或应用程序名称的队列映射。用户也可以定义自己的放置规则:
| 属性名 | 描述 |
|---|---|
| yarn.scheduler.capacity.queue-mappings | 此配置指定用户或组到特定队列的映射。您可以将单个用户或用户列表映射到队列。语法:[u or g]:[name]:[ queue_name],[next_mapping]。这里，u或g表示映射是针对用户还是针对组。值为用户u，组g。name表示用户名或组名。要指定已提交应用程序的用户，可以使用%user。queue_name表示必须映射应用程序的队列名称。若要指定与用户名相同的队列名，可以使用%user。要将队列名称指定为与用户所属的主组的名称相同，可以使用%primary_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: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.
</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>
| 属性名 | 描述 |
|---|---|
| yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime | 应用提交到调度器队列的最大生命周期(单位：秒)。任何小于或等于零的值都将被视为禁用。对于这个队列中的所有应用，这将是一个严格的时间限制。如果配置了正值，则提交到此队列的任何应用程序将在超过配置的生存期后被杀死。用户还可以在应用提交上下文中指定每个应用的生存期。但是，如果超过队列的最大生存期，则会覆盖用户级别生存期。注意:配置过低的值会很快杀死应用程序。此特性仅适用于叶队列。 |
| yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime | 应用的默认生存期，以秒为单位提交到队列。任何小于或等于零的值都将被视为禁用。如果用户没有提交具有生存期值的应用，则将接受此值。 |
应用程序优先级仅与FIFO排序策略一起使用。默认排序策略是FIFO。
应用程序的默认优先级可以在集群级别和队列级别：
cluster-max优先级的应都将重置为cluster-max优先级。$HADOOP_HOME/etc/hadoop/yarn-site.xml是集群最大优先级的配置文件。| 属性名 | 描述 |
|---|---|
| yarn.cluster.max-application-priority | 定义集群中的最大应用优先级 |
$HADOOP_HOME/etc/hadoop/capacity-scheduler.xml是队列级优先级的配置文件。| Property | Description |
|---|---|
yarn.scheduler.capacity.root..default-application-priority | 设置子队列默认优先级 |
Capacity Scheduler利用“ 延迟调度”来遵守任务局部性约束。有3个级别的位置限制：节点本地，机架本地和关闭交换机。当无法满足本地性时，调度程序会计算错过的机会的数量，并等待此计数达到阈值，然后再将本地性约束放宽到下一个级别。可以在以下属性中配置阈值：
| 属性 | 描述 |
|---|---|
| yarn.scheduler.capacity.node-locality-delay | CapacityScheduler尝试调度机架本地容器之后错过的调度机会的数量。通常，应将其设置为群集中的节点数。默认情况下，在一个机架中设置大约40个节点数。期望为正整数。 |
| yarn.scheduler.capacity.rack-locality-additionaldelay | 在节点局部性延迟机会之外的其他错过的调度机会数，此后CapacityScheduler尝试调度交换机外容器。默认情况下，此值设置为-1，在这种情况下，将基于公式$\frac{L\times C}{N}$计算分配错位容器的错过机会的数量，其中L是在以下位置指定的位置（节点或机架）的数量资源请求，C是请求的容器数，N是集群的大小。 |
内容来源于网络，如有侵权，请联系作者删除！