Hadoop：容量调度程序

目的

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

概述

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

传统上，每个组织都拥有自己的一组私有计算资源，这些计算资源具有足够的容量来满足组织在峰值或接近峰值条件下的SLA。这通常会导致较差的平均利用率和管理多个独立集群的开销，每个组织一个。在组织之间共享群集是运行大型Hadoop安装的一种经济有效的方式，因为这样可以在不创建私有群集的情况下获得规模经济效益。但是，组织担心共享群集，因为他们担心其他人使用对其SLA至关重要的资源。

该CapacityScheduler被设计为允许共享一个大集群，同时给予每一个组织能力的保证。中心思想是Hadoop集群中的可用资源由多个组织共享，这些组织根据其计算需求共同为集群提供资金。组织可以访问其他人未使用的多余容量，这是一个额外的好处。这为组织提供了具有成本效益的弹性。

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

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

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

特点

该CapacityScheduler支持以下功能：

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

  • 容量保证 - 在某种程度的资源可供其使用的意义上，将队列分配给电网容量的一小部分。提交到队列的所有应用程序都可以访问分配给队列的容量。管理员可以为分配给每个队列的容量配置软限制和可选硬限制。

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

  • 弹性 - 可以将超出其容量的任何队列分配给免费资源。当在未来某个时间点运行低于容量的队列需要这些资源时，随着在这些资源上调度的任务完成，它们将被分配给运行在容量以下的队列上的应用程序（也支持抢占）。这确保了资源以可预测和弹性的方式可用于队列，从而防止集群中的资源孤岛有助于利用。

  • 多租户 - 提供全面的限制，以防止单个应用程序，用户和队列独占整个队列或集群资源，以确保集群不会被淹没。

  • 可操作性

    • 运行时配置 - 管理员可以在运行时以安全的方式更改队列定义和属性（如容量，ACL），以最大限度地减少对用户的干扰。此外，还为用户和管理员提供了一个控制台，以查看系统中各种队列的当前资源分配。管理员可以在运行时添加其他队列，但不能在运行时删除队列。

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

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

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

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

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

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

配置

设置ResourceManager以使用CapacityScheduler

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

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

设置队列

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

所述CapacityScheduler有一个称为预定队列root 。系统中的所有队列都是 root 队列的子节点。

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

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

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

下面是一个示例，其中包含三个顶级子队列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<ueue-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可确保单个用户永远不会超过队列配置的容量，无论群集的空闲程度如何。值被指定为float。
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。
  • 使用Absolute Resources配置的资源分配

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

  • 运行和待定应用程序限制

所述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-percen
  • 队列管理和权限

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

属性描述
yarn.scheduler.capacity.<queue-path>.state

队列的状态。可以是RUNNING或STOPPED之一。如果队列处于STOPPED状态，则无法将新应用程序提交给自身或其任何子队列。因此，如果 root  队列是STOPPED，则不能将任何应用程序提交给整个群集。现有应用程序继续完成，因此可以优雅地排空队列。值指定为

枚举。

yarn.scheduler.capacity.root.<queue-path>.acl_submit_applications控制谁可以将应用程序提交到给定队列的ACL。如果给定用户/组在给定队列上具有必要的ACL，或者在层次结构中具有一个父队列，则他们可以提交应用程序。ACL的该属性是从父队列继承如果没有指定。
yarn.scheduler.capacity.root.<queue-path>.acl_administer_queue用于控制谁可以向队列中提交应用程序。如果给定用户/组在给定队列上具有指定的的ACL，或者在层次结构中具有一个父队列，则它们可以提交应用程序。如果没有指定的话ACL的该属性是从父队列继承。

注：An ACL is of the form user1,user2 space group1,group2. The special value of * implies anyone。

 The special value of space implies no one. The default is * for the root queue if not specified.

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

所述CapacityScheduler支持以下参数来配置基于 user or group, user & group, or application name 的队列映射。用户还可以定义自己的放置规则：

属性描述
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。
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此函数用于指定是否可以覆盖用户指定的队列。这是一个boolean 值 ，默认值为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>
  • 应用程序的队列生命周期

    所述CapacityScheduler支持以下参数，以应用程序的生命周期：

属性描述
yarn.scheduler.capacity.<queue-path>.maximum-application-lifetime在几秒钟内提交到队列的应用程序的最长生命周期。任何小于或等于零的值都将被视为已禁用。对于此队列中的所有应用程序，这将是一个艰难的时间限制。如果配置了正值，那么提交到此队列的任何应用程序将在超过配置的生存期后被终止。用户还可以在应用程序提交上下文中指定每个应用程 但如果超过队列最长生命周期，则会覆盖用户生命周期。它是时间点配置。注意：配置太低的值将导致更快地终止应用程序。此功能仅适用于叶队列。
yarn.scheduler.capacity.root.<queue-path>.default-application-lifetime在几秒钟内提交到队列的应用程序的默认生存期。任何小于或等于零的值都将被视为已禁用。如果用户尚未提交具有生命周期值的应用程序，则将采用此值。它是时间点配置。注意：默认生命周期不能超过最长生命周期。此功能仅适用于叶队列。

设置应用程序优先级。

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

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

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

注意：将应用程序移动到其他队列时，不会更改应用程序的优先级。

Capacity Scheduler容器抢占

该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-site.xml中配置以下配置参数，以便在为yarn.resourcemanager.scheduler.monitor.policies配置ProportionalCapacityPreemptionPolicy类时控制容器的抢占。

属性描述
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支持能力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的类名。根据配置的Scheduler选择默认值，即如果配置了CapacityScheduler，则它是CapacityReservationSystem。
yarn.resourcemanager.reservation-system.plan.follower可选参数：在计时器上运行的PlanFollower的类名，并将CapacityScheduler与计划同步，反之亦然。根据配置的Scheduler选择默认值，即如果配置了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实现的类名，该类 将尝试将用户的预留请求放入计划中。默认值为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可选参数：平均允许容量，它将在ReservationWindow上以百分比（％）聚合，作为SharingPolicy允许单个用户保留的浮点数。默认值为1，即100％。
yarn.scheduler.capacity <queue-path> .reservation-planner可选参数：将用于确定计划程序实现的类名， 如果计划容量低于（由于计划维护或节点故障）用户保留资源，将调用该计划程序的实现。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner，它扫描计划并以相反的接受顺序（LIFO）贪婪地删除预留，直到预留资源在计划容量内
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 ... - Refer Queue Properties部分

例：

 <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-calculatorResourceCalculator实现，用于比较调度程序中的资源。默认情况下，org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator仅使用Memory，而DominantResourceCalculator使用Dominant-resource来比较多维资源，如内存，CPU等。需要Java ResourceCalculator类名。
  • 数据位置

Capacity Scheduler利用延迟调度来履行任务局部性约束。局部性约束有3个级别：节点本地，机架本地和交换机。当不能满足地点时，调度程序计算错失的机会的数量，并且在将地点约束放松到下一级别之前等待该计数达到阈值。可以在以下属性中配置阈值：

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

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

  • 每个NodeManager心跳的容器分配

该CapacityScheduler支持以下参数来控制多少容器可以在每个节点管理器心跳进行分配。

属性描述
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心跳中分配的最大容器数量。默认为-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 网页应该表现出个人队列的资源使用。

更改队列配置

更改 queue/scheduler 程序属性以及 adding/removing  队列可以通过文件或API两种方式完成。可以通过yarn-site.xml中的yarn.scheduler.configuration.store.class 更改此行为。可能的值是file，它允许通过文件修改属性; 内存，允许通过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

通过 via 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 Resource Manager REST API ;有关如何通过命令行更改调度程序配置的示例，请参阅YARN命令参考。

 

更新容器（实验 - API将来可能会更改）

一旦Application Master从资源管理器接收到Container，它就可以请求资源管理器更新容器的某些属性。

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

  • 资源更新：AM可以请求RM更新容器的资源大小。例如：将容器从2GB，2个vcore容器更改为4GB，2个vcore容器。
  • ExecutionType Update：AM可以请求RM更新容器的ExecutionType。例如：将执行类型从GUARANTEED更改为OPPORTUNISTIC，反之亦然。

这是通过AM 在AllocateRequestProto中填充updated_containers字段（类型为UpdateContainerRequestProto的列表）来促进的。AM可以在同一个分配调用中发出多个容器更新请求。

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能够更新所请求的容器，则将在相同分配调用的AllocateResponseProto返回值或后续调用之一中的UpdatedContainerProto类型的updated_containers列表字段中返回更新的容器。

UpdatedContainerProto的架构如下：

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

它指定在Container上执行的容器更新类型以及更新的容器更新后的容器对象。

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

该DECREASE_RESOURCE和DEMOTE_EXECUTION_TYPE容器会自动更新-在上午并没有明确要问网管降低容器的资源。其他更新类型要求AM明确要求NM更新容器。

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

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生