揭秘Apache Hadoop YARN,第4部分:公平调度队列基础[译]

在本系列的第3部分中,快速介绍了Fair Scheduler,它是Apache Hadoop YARN(Cloudera推动)中的调度程序之一。在第4部分中,我们将讨论大多数队列属性,它们使用的一些示例以及它们的限制。

队列属性

默认情况下,Fair Scheduler使用单个默认队列。可以创建其他队列并设置相应的属性对集群上应用程序的运行方式进行更精细的控制。

FairShare

FairShare是YARN集群资源的一个数量。我们将使用来表示FairShare有100GB内存和25个核心。

Share Weights

数值0.0或更高

Notes:

1.权重决定了队列相对于其同级的资源量。例如,给定如下:
  一个大小为1000GB和200vcore的YARN群集
  队列X的权重为0.25
  所有其他队列的组合权重为0.75
  队列X将具有的FairShare
2.如果队列或其子队列中的一个具有至少一个活动应用程序,则对队列执行计算的FairShare。如果群集上有等量的可用资源,则可以直接使用。否则,等待其他队列完成后才可使用资源。
3.权重相对于集群,因此FairShare随集群资源变化而变化。
4.这是执行队列资源分配的推荐方法。

Resource Constraints

有两种类型的资源约束

20000 mb, 10 vcores
2000000 mb, 1000 vcores

Notes:

1.minResources限制是一个软限制。只要队列总资源需求大于或等于minResources需求,它就会强制执行,并且只要满足以下条件,它将至少获得指定的数量:
  空闲资源可以从其他队列抢占
  所有minResources的总和不大于集群的总资源。
2.maxResources限制是一个硬限制,意味着它不断强制执行。具有此属性的队列及其任何子代队列使用的总资源必须遵守该属性。
3.不推荐使用minResources/maxResources,有几个缺点:
  值是静态值,因此如果群集大小更改,则它们需要更新.
  maxResources限制集群的利用率,因为队列无法占用集群上超过配置的maxResources的任何可用资源。
  如果队列的minResources大于其FairShare,则它可能影响其他队列的FairShare。
4.在过去,一个指定minResources时使用抢占更快地获得一块资源。这不再是必要的,因为基于FairShare的抢占已经显着改善。我们将在后面更详细地讨论这个问题。

Limiting Applications

有两种方法来限制队列上的应用程序:

Notes:

1.maxRunningApps限制是一个硬限制。队列使用的总资源及任何子级和后代队列必须遵守该属性
2.maxAMShare限制是一个硬限制。此分数表示允许为ApplicationMasters分配的队列资源的百分比。
  maxAMShare方便在运行大量应用程序的非常小的集群上设置。
  默认值为0.5。此默认值确保一半的资源可用于运行非AM容器。

Users and Administrators

这些属性用于限制谁可以提交到队列,谁可以管理队列上的应用程序(即kill)。

user1,user2,user3,... group1,group2,...
userA,userB,userC,... groupA,groupB,...

注意:如果yarn.acl.enableyarn-site.xml中设置为true,那么除了aclAdministerApps队列属性之外,yarn.admin.acl属性还将被视为有效管理员的列表。

Queue Placement Policy

配置队列后,队列放置策略将满足以下目的:

  • 当应用程序提交到集群时,将每个应用程序分配到相应的队列。
  • 可定义哪种类型的队列可以被“实时”创建。

队列放置策略告知Fair Scheduler将应用程序放置在队列中的何处:

原文代码缺失,后面相关文字暂不做翻译

will match against “Rule #1” and if that fails, match against “Rule #2” and so on until a rule matches. There are a predefined set of rules from which to choose and their behavior can be modeled as a flowchart. The last rule must be a terminal rule, which is either the default rule or the reject rule.

如果未设置队列放置策略,则FairScheduler将使用基于属性的默认规则,yarn-site.xml文件中的yarn.scheduler.fair.user-as-default-queueyarn.scheduler.fair.allow-undeclared-pools属性。

特殊:使用“create”属性即时创建队列

所有队列放置策略规则允许一个称为create的XML属性,该属性可以设置为“true”或“false”。例如:

原文代码缺失

如果create属性为true,则允许该规则通过特定规则确定的名称(如果它不存在)创建队列。如果create属性为false,则不允许规则创建队列,队列布置将移至下一个规则。

队列放置规则

本节给出了可用的每种类型的队列放置策略的示例,并提供了调度程序如何确定哪个应用程序到哪个队列(或应用程序是否创建新队列)的流程图。

Rule: specified

  • Summary: 直接制定队列名。
  • Example rule in XML: <rule name="specified"/>
  • Example Hadoop command specifying queue: hadoop jar mymr.jar app1 -Dmapreduce.job.queuename="root.myqueue"
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f1.png

Rule: user

  • Summary: 以应用程序提交者的用户名作为队列名。例如,如果Fred是用户启动YARN应用程序,则流程图中的队列将为root.fred
  • Example rule in XML: <rule name="user"/>
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f2.png

Rule: primaryGroup

  • Summary: 将应用程序分配到以用户所属的主组(通常是第一个组)命名的队列。例如,如果启动应用程序的用户属于Marketing组,则流程图中的队列将为root.marketing
  • Example rule in XML: <rule name="primaryGroup"/>
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f3.png

Rule: secondaryGroupExistingQueue

  • Summary: 将应用程序分配到以用户所属的第一个有效辅助组(换句话说,不是主组)命名的队列。例如,如果用户属于辅助组market_eumarket_automarket_germany,则流程图中的队列将迭代并查找队列root.market_euroot.market_autoroot.market_germany
  • Example rule in xml: <rule name="secondaryGroupExistingQueue"/>
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f4.png

Rule: nestedUserQueue

  • Summary: 在除root以外的其他队列下创建用户队列。 “其他队列”由nestedUserQueue规则所包含的规则确定。
  • Template: 此处又没代码。。。
  • Example rule in XML: 此处又没代码。。。
  • Note: 此规则创建user队列,但在root队列之外的队列下。首先评估内部队列放置策略,然后在下面创建user队列。注意,如果nestedUserQueue规则没有设置属性create =“true”,那么只有在特定用户队列已经存在的情况下才能提交应用程序。
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f5.png

Rule: default

  • Summary:定义默认队列.
  • Example rule in XML: <rule name="default" queue="default" />
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f6.png

Rule: reject

  • Summary: 拒绝应用程序提交,这通常用作最后一个规则。
  • Example rule in XML: <rule name="reject"/>
  • Note: 如果标准hadoop jar命令被此规则拒绝,则会出现错误消息java.io.IOException: Failed to run job : Application rejected by queue placement policy
  • Flowchart:

http://blog.cloudera.com/wp-content/uploads/2016/05/yarn4-f7.png

应用程序状态

如本系列的第一篇分所述,应用程序包括一个或多个任务,每个任务在容器中运行。本系列文章中,应用程序可以是以下四种状态之一:

  • pending 应用程序还未被分配container.
  • active 应用程序运行在一个或多个container中.
  • starving 应用程序资源请求为满足.
  • finished 所有任务完成.

样例:在群集中运行程序

假设我们有一个总资源的两个队列的YARN集群:root.busy(weight = 1.0)和root.sometimes_busy(weight 3.0)。通常有四种感兴趣的情景:

  • 场景 A: busy队列跑满了应用程序,sometimes_busy队列有少量正在运行的应用程序(例如10%,即)。然后,大量应用程序在相对较短的时间内添加到sometimes_busy队列中。 somet_busy中的所有新应用程序将处于待处理状态,并且等待busy队列中的容器完成后才能变为活动状态. 如果busy队列中的任务很短,那么somet_busy队列中的应用程序不会等待很长时间才能获取容器分配。反之需要等待很长时间。 还有就是,当somet_busy队列中的应用程序变为活动状态时,busy队列中的许多正在运行的应用程序将需要更长的时间才能完成。
  • 场景 B: busysometimes_busy队列都跑满或接近跑满应用程序的时候。 在这种情况下,集群将保持完全利用。每个队列将使用其公平共享,busy队列占用队集群资源的25%,而使用其余75%的资源都给somet_busy队列。

那么,如何避免场景A这种情况?

一个解决方案是在busy队列上设置maxResources。假设maxResources属性在忙队列上设置为相当于集群的25%。由于maxResources是硬限制,所以忙碌队列中的应用程序将始终限制为总计25%。因此,在可以使用100%的集群的情况下,集群利用率实际上更接近35%(对于somet_busy队列为10%,对于busy队列为25%)。

方案A将显着改进,因为集群上有多的可用资源,只能在somet_busy队列中使用,但是平均集群利用率可能很低。

更多FairShare定义

Steady FairShare:队列的理论FairShare值。此值根据群集大小和群集中队列的权重计算。
Instantaneous FairShare:调度程序为集群中每个队列计算的FairShare值。此值与Steady FairShare的区别有两种:
  空队列未分配任何资源。
  当所有队列都达到或超过容量时,此值等于Steady FairShare。
Allocation:等于队列中所有正在运行的应用程序使用的资源的总和。

后面我们把Instantaneous FairShare简称为FairShare

抢占(Preemption) 案例

之前的场景可以表述如下:

场景 A

  • sometimes_busy队列被分配了 ,FairShare值为
  • busy队列被分配了 FairShare值为 .

场景 B

  • 两个队列的Instantaneous FairShare等于其Steady FairShare。

在场景A中,您可以看到两个队列在分配和其FairShare之间的不平衡。当容器从busy队列中释放并分配给sometimes_busy队列时,资源的平衡缓慢执行。

通过打开抢占,Fair Scheduler可以killbusy队列中的容器,并将它们更快地分配到sometimes_busy队列。

配置抢占公平调度

yarn-site.xml文件中配置以下属性

yarn.scheduler.fair.preemption
true

然后,在您的FairScheduler分配文件中,可以通过fairSharePreemptionThreshold和fairSharePreemptionTimeout在队列上配置抢占,如下面的示例所示。 fairSharePreemptionTimeout是队列在fairSharePreemptionThreshold情况下的秒数,之后它将尝试抢占容器从其他队列获取资源。

此处又没代码。。。

回想一下,somet_busy队列的FairShare是。这两个新属性告诉FairScheduler,somet_busy队列将在开始抢占之前等待60秒。如果在那段时间,它没有收到其资源中的50%的FairShare,FairScheduler可以开始杀死在busy队列中的容器,并将它们分配到sometimes_busy队列。

注意事项:

1.fairSharePreemptionThreshold的值应该大于0.0(设置为0.0将关闭抢占),不能大于1.0。
2.此配置中的抢占将会占用busy列中的容器,并将它们分配给sometimes_busy队列。
  不会发生反向抢占,因为在busy列上没有设置抢占属性。
  抢占不会从somet_busy队列中的应用程序A中删除容器,并将它们分配给somet_busy队列中的应用程序B.

(注意:我们不会在队列上配置minResourcesminSharePreemptionTimeout)目前推荐使用FairShare抢占。)

扩展阅读

要获得有关Fair Scheduler的更多信息,请查看在线文档(Apache HadoopCDH版本可用)。

结论

1.有许多属性可以在队列上设置。这包括限制资源,限制应用程序,设置用户或管理员以及设置调度策略。
2.队列配置文件还应包括队列放置策略。队列放置策略定义如何将应用程序分配给队列。
3.在队列中运行的应用程序可以将应用程序保持在pending或starving状态的不同队列中。在Fair Scheduler中配置抢占可以更快地调整这些不平衡。

下一步

第5部分将提供具体的示例,如作业优先级,以及如何使用队列及其属性来处理这种情况。

Ray Chiang是Cloudera的软件工程师。

Dennis Dawson是Cloudera的高级技术撰稿人。

原文地址Untangling Apache Hadoop YARN, Part 4: Fair Scheduler Queue Basics

打赏支持:支付宝/微信,感谢赏口饭吃