Hadoop 文档

General

Common

HDFS

MapReduce

MapReduce REST APIs

YARN

YARN REST APIs

YARN Service

Submarine

Hadoop Compatible File Systems

Auth

Tools

Reference

Configuration

目的

本文档介绍了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.class org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

设置队列

etc / hadoop / capacity-scheduler.xmlCapacityScheduler的配置文件。

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

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

CapacityScheduler的配置使用称为队列路径的概念来配置队列的层次结构。该队列路径是队列的层次结构的完整路径,开始于,有。(点)作为分隔符。

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

这是一个示例,其中包含三个顶级子队列abc以及一些ab子队列:

<属性>
  <name> yarn.scheduler.capacity.root.queues </ name>
  <value> a,b,c </ value>
  <description>此级别上的队列(root是根队列)。
  </ description>
</ property>

<属性>
  <name> yarn.scheduler.capacity.root.a.queues </ name>
  <value> a1,a2 </ value>
  <description>此级别上的队列(root是根队列)。
  </ description>
</ property>

<属性>
  <name> yarn.scheduler.capacity.root.b.queues </ name>
  <value> b1,b2,b3 </ value>
  <description>此级别上的队列(root是根队列)。
  </ description>
</ property>

队列属性

  • 资源分配
属性 描述
yarn.scheduler.capacity。<队列路径> .capacity 队列容量(以百分比(%)为单位)(例如浮点数(例如12.5))或绝对资源队列最小容量。每个级别上所有队列的容量总和必须等于100。但是,如果配置了绝对资源,则子队列的绝对资源总和可能小于其父代绝对资源容量。如果有可用资源,则队列中的应用程序可能会消耗比队列容量更多的资源,从而提供弹性。
yarn.scheduler.capacity。<queue-path>。最大容量 最大队列容量(以百分比(%)为单位)或作为绝对资源队列最大容量。这限制了队列中应用程序的弹性。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。<队列路径>。用户设置。<用户名> .weight 在为队列中的用户计算用户限制资源值时,将使用此浮点值。此值将使每个用户比队列中的其他用户更多或更少的权重。例如,如果用户A在队列中接收的资源比用户B和C多50%,则用户A的此属性将设置为1.5。用户B和C的默认属性为1.0。
  • 使用绝对资源配置的资源分配

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

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

所述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在每个队列中被覆盖-百分
  • 队列管理和权限

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

属性 描述
yarn.scheduler.capacity。<队列路径> .state 队列的状态。可以是RUNNINGSTOPPED之一。如果队列处于STOPPED状态,则无法将新应用程序提交给它自己或其任何子队列。因此,如果队列已停止,则无法将应用程序提交到整个集群。现有的应用程序继续完成,因此,队列可以排出正常。值指定为Enumeration。
yarn.scheduler.capacity.root。<队列路径> .acl_submit_applications ACL谁可以控制哪些提交申请到给定队列。如果给定用户/组在给定队列或层次结构中的父队列之一上具有必要的ACL,则他们可以提交应用程序。ACL的该属性从父队列继承如果没有指定。
yarn.scheduler.capacity.root。<队列路径> .acl_administer_queue ACL谁可以控制哪些管理给定队列的应用程序。如果给定用户/组在给定队列或层次结构中的父队列之一上具有必要的ACL,则他们可以管理应用程序。ACL的该属性从父队列继承如果没有指定。

注:一个访问控制列表的形式为用户1用户2 空间 1组第2组。*的特殊值表示任何人空间的特殊价值意味着没有人。如果未指定,默认值是*用于根队列。

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

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

属性 描述
纱线计划程序容量队列映射 此配置指定用户或组到特定队列的映射。您可以将单个用户或用户列表映射到队列。语法:[u或g]:[name]:[queue_name] [,next_mapping] *。在此,u或g表示映射是针对用户还是针对组。用户的值为u,组的值为gname表示用户名或组名。要指定提交了申请的用户,可以使用%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

例:

 <属性>
   <name> yarn.scheduler.capacity.queue-mappings </ name>
   <value> u:user1:queue1,g:group1:queue2,u:%user:%user,u:user2:%primary_group </ value>
   <说明>
     这里,<user1>映射到<queue1>,<group1>映射到<queue2>, 
     将用户映射到与用户同名的队列,<user2>被映射 
     将分别与<primary group>相同的名称排队。映射将是
     从左到右计算,将使用第一个有效映射。
   </ description>
 </ property>

  <属性>
    <name> yarn.scheduler.queue-placement-rules.app-name </ name>
    <value> appName1:queue1,%application:%application </ value>
    <说明>
      在这里,<appName1>映射到<queue1>,将应用程序映射到具有
      分别与应用程序同名。映射将是
      从左到右计算,将使用第一个有效映射。
    </ description>
  </ property>
  • 应用程序的队列生存期

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

属性 描述
yarn.scheduler.capacity。<queue-path>。最大应用寿命 提交到队列的应用程序的最长生存时间(以秒为单位)。任何小于或等于零的值将被视为禁用。对于此队列中的所有应用程序来说,这将是一个艰难的时限。如果配置了正值,则超过配置的生存期后,提交到此队列的任何应用程序都将被终止。用户还可以在应用程序提交上下文中指定每个应用程序的生存期。但是,如果用户生存期超过队列的最大生存期,它将被覆盖。它是时间点配置。注意:配置太低的值将导致应用程序更快被杀死。此功能仅适用于叶队列。
yarn.scheduler.capacity.root。<队列路径> .default-application-lifetime 提交到队列的应用程序的默认生存期(以秒为单位)。任何小于或等于零的值将被视为禁用。如果用户尚未提交具有生存期值的应用程序,则将使用此值。它是时间点配置。注意:默认生存期不能超过最大生存期。此功能仅适用于叶队列。

设置应用程序优先级。

应用程序优先级仅与FIFO排序策略一起使用。默认排序策略是FIFO。

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

  • 群集级优先级:提交的优先级大于cluster-max优先级的任何应用程序都将其优先级重置为cluster-max优先级。$ HADOOP_HOME / etc / hadoop / yarn-site.xml是cluster-max优先级的配置文件。
属性 描述
yarn.cluster.max应用优先级 定义集群中的最大应用程序优先级。
  • 叶子队列级别优先级:每个叶子队列均由管理员提供默认优先级。队列的默认优先级将用于没有指定优先级的所有提交的应用程序。$ HADOOP_HOME / etc / hadoop / capacity-scheduler.xml是队列级优先级的配置文件。
属性 描述
yarn.scheduler.capacity.root。<叶队列路径> .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类的列表。配置的策略需要与调度程序兼容。默认值为与CapacityScheduler兼容的org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy

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

属性 描述
yarn.resourcemanager.monitor.capacity.preemption.observe_only 如果为true,请运行该策略,但不会通过抢占和终止事件影响群集。默认值为假
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

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

属性 描述
yarn.scheduler.capacity。<队列路径> .disable_preemption 可以将此配置设置为true以有选择地禁用对提交到给定队列的应用程序容器的抢占。仅当通过将yarn.resourcemanager.scheduler.monitor.enable配置为true并将yarn.resourcemanager.scheduler.monitor.policies配置为ProportionalCapacityPreemptionPolicy启用系统范围的抢占时,此属性才适用。如果未为队列设置此属性,则该属性值将从队列的父级继承。默认值为false。
yarn.scheduler.capacity。<队列路径>。队列内抢占.disable_preemption 可以将此配置设置为true,以选择性地禁用提交给定队列的应用程序容器的队列内抢占。仅当通过将yarn.resourcemanager.scheduler.monitor.enable配置为true,将yarn.resourcemanager.scheduler.monitor.policies设置ProportionalCapacityPreemptionPolicyyarn.resourcemanager.monitor.capacity.preemption.intra-queue启用系统范围的抢占时,此属性才适用-preemption.enabledtrue。如果未为队列设置此属性,则该属性值将从队列的父级继承。默认值为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。<队列> .acl_list_reservations ACL控制谁可以列出对给定队列的预订。如果给定用户/组在给定队列上具有必要的ACL,则他们可以列出所有应用程序。此属性的ACL 没有,如果没有指定从父队列继承。
yarn.scheduler.capacity.root。<queue> .acl_submit_reservations ACL控制谁可以给定队列提交预订。如果给定的用户/组在给定的队列中具有必要的ACL,则他们可以提交保留。此属性的ACL 没有,如果没有指定从父队列继承。

使用CapacityScheduler配置ReservationSystem

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

属性 描述
纱线资源管理器保留系统启用 必填参数:在ResourceManager中启用ReservationSystem。预期为布尔值。默认值为false,即默认情况下未启用ReservationSystem
yarn.resourcemanager.reservation-system.class 可选参数:ReservationSystem的类名。根据配置的调度程序选择默认值,即,如果配置了CapacityScheduler,则为CapacityReservationSystem
纱线资源管理器预订系统计划追随者 可选参数:在计时器上运行的PlanFollower的类名称,并将CapacitySchedulerPlan同步,反之亦然。根据配置的调度程序选择默认值,即,如果配置了CapacityScheduler,则为CapacitySchedulerPlanFollower
纱线资源管理器预订系统计划员时间步长 可选参数: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 在Scheduler 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 可选参数,表示如果计划中的约束得到满足,SharePointPolicy将验证的时间(以毫秒为单位)。预期长值。默认值为一天。
纱线计划程序容量<队列路径>。瞬时最大容量 可选参数:随时以百分比(%)表示的最大容量,这是SharingPolicy允许单个用户保留的浮点数。默认值为1,即100%。
yarn.scheduler.capacity。<队列路径>。平均容量 可选参数:平均允许容量,该百分比将在ReservationWindow上以百分比(%)的形式聚合为SharingPolicy允许单个用户保留的浮点数。默认值为1,即100%。
yarn.scheduler.capacity。<queue-path> .reservation-planner 可选参数:将用于确定Planner实施的类名, 如果Plan容量低于(由于计划的维护或节点故障转移)用户保留的资源,则将调用该类名。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner,它扫描计划并按相反的接受顺序(LIFO)贪婪地删除保留,直到保留的资源在计划容量之内
yarn.scheduler.capacity。<queue-path> .reservation-enforcement-window 可选参数,表示计划器将验证是否满足计划中的约束的时间(以毫秒为单位)。预期长值。默认值为一小时。

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

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

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

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

例:

 <属性>
   <name> yarn.scheduler.capacity.queue-mappings </ name>
   <value> u:user1:queue1,g:group1:queue2,u:user2:%primary_group,u:%user:parent1。%user </ value>
   <说明>
     在这里,u:%user:parent1。%user映射允许除user1之外的任何<user>,
     将user2映射到其自己的用户特定叶队列,该队列
     将在<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。<队列路径> .leaf-queue-template.capacity 必选参数:指定自动创建的叶子队列的最小保证容量。当前在自动创建的叶子队列上不支持绝对资源配置
yarn.scheduler.capacity。<queue-path> .leaf-queue-template。<叶队列-属性> 可选参数:有关可在自动创建的叶子队列上配置的其他队列参数,例如最大容量,用户限制因子,最大资源百分比...-请参阅“ 队列属性”部分

例:

 <属性>
   <name> yarn.scheduler.capacity.root.parent1.auto-create-child-queue.enabled </ name>
   <value> true </ value>
 </ property>
 <属性>
    <name> yarn.scheduler.capacity.root.parent1.leaf-queue-template.capacity </ name>
    <value> 5 </ value>
 </ property>
 <属性>
    <name> yarn.scheduler.capacity.root.parent1.leaf-queue-template.maximum-capacity </ name>
    <value> 100 </ value>
 </ property>
 <属性>
    <name> yarn.scheduler.capacity.root.parent1.leaf-queue-template.user-limit-factor </ name>
    <value> 3.0 </ value>
 </ property>
 <属性>
    <name> yarn.scheduler.capacity.root.parent1.leaf-queue-template.ordering-policy </ name>
    <value>公平</ value>
 </ property>
 <属性>
    <name> yarn.scheduler.capacity.root.parent1.GPU.capacity </ name>
    <value> 50 </ value>
 </ property>
 <属性>
     <name> yarn.scheduler.capacity.root.parent1.accessible-node-labels </ name>
     <value> GPU,SSD </ value>
   </ property>
 <属性>
     <name> yarn.scheduler.capacity.root.parent1.leaf-queue-template.accessible-node-labels </ name>
     <value> GPU </ value>
  </ 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配置中的逗号分隔字符串。有关更多详细信息,请参阅上面的“ 容量调度程序”容器抢占部分

属性 描述
纱线资源管理器监视容量队列管理监视间隔 两次调用此QueueManagementDynamicEditPolicy策略之间的时间(以毫秒为单位)。默认值为1500

其他特性

  • 资源计算器
属性 描述
yarn.scheduler.capacity.resource-calculator 用于在调度程序中比较资源的ResourceCalculator实现。默认值即org.apache.hadoop.yarn.util.resource.DefaultResourceCalculator仅使用内存,而DominantResourceCalculator使用Dominant-resource比较多维资源(例如Memory,CPU等)。应该使用Java ResourceCalculator类名。
  • 数据局部性

Capacity Scheduler利用“ 延迟调度”来遵守任务局部性约束。有3个级别的位置限制:节点本地,机架本地和关闭交换机。当无法满足本地性时,调度程序会计算错过的机会的数量,并等待此计数达到阈值,然后再将本地性约束放宽到下一个级别。可以在以下属性中配置阈值:

属性 描述
yarn.scheduler.capacity.node-locality-delay CapacityScheduler尝试调度机架式本地容器之后错过的调度机会的数量。通常,应将其设置为群集中的节点数。默认情况下,在一个机架中设置大约40个节点数。期望为正整数。
yarn.scheduler.capacity.rack-locality-additionaldelay 在节点局部性延迟机会之外的其他错过的调度机会数,此后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。
纱线计划程序容量每节点心跳最大容器分配 如果启用了multiple-assignments,则为true,则可以在一个NodeManager心跳中分配的最大容器数量。默认值为100,它将每个心跳的最大容器分配数量限制为100。将此值设置为-1将禁用此限制。
纱线计划程序容量每节点心跳最大关闭开关分配 如果启用了multiple-assignments的值为true,则可以在一个NodeManager心跳中分配的最大交换机外容器数量。默认值是1,表示一次心跳中仅允许进行一次交换机外分配。

查看CapacityScheduler的配置

一旦安装和配置完成,您就可以在从Web-ui启动YARN群集之后进行检查。

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

  • 打开ResourceManager Web UI。

  • /调度网页应该表现出个人队列的资源使用。

更改队列配置

更改队列/调度程序属性和添加/删除队列可以通过两种方式完成,即文件或API。可以通过yarn-site.xml中的yarn.scheduler.configuration.store.class更改此行为。可能的值是file,它允许通过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:停止queue列

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

步骤2:删除queue列

如上所述,从文件中删除队列配置并运行刷新

通过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 Commands Reference

更新容器(实验性-API将来可能会更改)

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

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

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

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

UpdateContainerRequestProto的架构如下:

消息UpdateContainerRequestProto {
  必需int32 container_version = 1;
  必需ContainerIdProto container_id = 2;
  必需的ContainerUpdateTypeProto update_type = 3;
  可选的ResourceProto功能= 4;
  可选的ExecutionTypeProtoexecution_type = 5;
}

ContainerUpdateTypeProto是一个枚举:

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

受上述枚举约束,调度程序当前支持在一个更新请求中更改容器的资源更新或执行类型。

AM还必须提供从RM收到的最新ContainerProto。这是RM将尝试更新的容器。

如果RM能够更新请求的容器,则将在相同的分配调用或后续调用之一的AllocateResponseProto返回值中类型为UpdatedContainerProtoUpdated_containers列表字段中返回已更新的容器。

UpdatedContainerProto的架构如下:

消息UpdatedContainerProto {
  必需的ContainerUpdateTypeProto update_type = 1;
  所需的ContainerProto容器= 2;
}

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

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

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

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