揭祕Apache Hadoop YARN,第四部分:公平調度隊列基礎

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

http://blog.cloudera.com/blog/2016/06/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basics/

在本系列的第3部分中,簡單介紹了Fair Scheduler,它是Apache Hadoop YARN(Cloudera推動)中的調度程序之一。在第4部分中,我們將討論大多數隊列屬性,它們使用的一些示例以及它們的限制。

揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

隊列屬性

默認情況下,Fair Scheduler使用單個默認隊列。也可以創建其他隊列並設置相應的屬性對集群上應用程序的運行方式進行更精細的控制。

FairShare

FairShare是YARN集群資源的一個度量。我們將使用 <memory>來表示FairShare有100GB內存和25個核心。

Share Weights

<weight>Numerical Value 0.0 or greater

1.權重決定了隊列相對於其同級的資源量。例如:

  • 一個大小為1000GB和200vcore的YARN群集
  • 隊列X的權重為0.25
  • 所有其他隊列的組合權重為0.75
  • 隊列X的FairShare為<memory>

2. 如果隊列或其子隊列中的一個具有至少一個活動應用程序,則對隊列執行計算的FairShare。如果群集上有等量的可用資源,則可以直接使用。否則,等待其他隊列完成後才可使用資源。

3. 權重是相對於集群的,所以FairShare隨集群資源變化而變化。

4. 這是進行隊列資源分配的推薦方法。

資源約束(Resource Constraints)

有兩種類型的資源約束

<minresources>20000 mb, 10 vcores
<maxresources>2000000 mb, 1000 vcores

注意:

1. minResources限制是一個軟限制。只要隊列總資源需求大於或等於minResources需求,它就會強制執行,並且只要滿足以下條件,它將獲得至少指定的數量:

  • 空閒資源可以從其他隊列搶佔
  • 所有minResources的總和不大於集群的總資源。

2.maxResources限制是一個硬限制,意味著它不斷強制執行。具有此屬性的隊列及其任何子代隊列使用的總資源必須遵守該屬性。

3.不推薦使用minResources/maxResources,有幾個缺點:

  • 值是靜態值,因此如果群集大小更改,則它們需要更新.
  • maxResources限制集群的利用率,因為隊列無法佔用集群上超過配置的maxResources的任何可用資源。
  • 如果隊列的minResources大於其FairShare,則它可能影響其他隊列的FairShare。

4.在過去,一個指定minResources時使用搶佔更快地獲得一塊資源。這不再是必要的,因為基於FairShare的搶佔已經顯著改善。我們將在後面更詳細地討論這個問題。

應用限制(Limiting Applications)

有兩種方法來限制隊列上的應用程序:

<maxrunningapps>10
<maxamshare>0.3

note:

1.maxRunningApps限制是一個硬限制。隊列使用的總資源及任何子級和後代隊列必須遵守該屬性

2.maxAMShare限制是一個硬限制。此分數表示允許為ApplicationMasters分配的隊列資源的百分比。

  • maxAMShare方便在運行大量應用程序的非常小的集群上設置。
  • 默認值為0.5。此默認值確保一半的資源可用於運行非AM容器。

用戶和管理員

這些屬性用於限制誰可以提交到隊列,誰可以管理隊列上的應用程序(即kill)

<aclsubmitapps>user1,user2,user3,... group1,group2,...
<acladministerapps>userA,userB,userC,... groupA,groupB,...

note:如果yarn.acl.enable在yarn-site.xml中設置為true,那麼除了aclAdministerApps隊列屬性之外,yarn.admin.acl屬性還將被視為有效管理員的列表。

隊列安置策略(Queue Placement Policy)

配置隊列後,隊列放置策略將有以下功能:

  • 當應用程序提交到集群時,將每個應用程序分配到相應的隊列。
  • 可定義哪種類型的隊列可以被“實時”創建。

隊列放置策略告知Fair Scheduler將應用程序放置在隊列中的何處:

<queueplacementpolicy>
<rule>
<rule>
<rule>
.
.

如上策略,會優先匹配Rule #1 ,如果匹配Rule #1 失敗,接著匹配Rule #2,直到匹配成功。有一套預定義好的規則供選擇,他們可以任意組合成一個流程。最後一個規則必須是一個結束規則(terminal rule), 可以是默認規則或者拒絕規則。

如果未設置隊列放置策略,則FairScheduler將使用基於屬性的默認規則,yarn-site.xml文件中的yarn.scheduler.fair.user-as-default-queue和yarn.scheduler.fair.allow-undeclared-pools屬性。

特殊:使用"create"屬性即時創建隊列

所有隊列放置策略規則允許一個稱為create的XML屬性,該屬性可以設置為“true”或“false”。例如:

<rule>

如果create屬性為true,則允許該規則通過特定規則確定的名稱(如果它不存在)創建隊列。如果create屬性為false,則不允許規則創建隊列,隊列布置將移至下一個規則。

具體的隊列安置策略

本節給出了可用的每種類型的隊列放置策略的示例,並提供了調度程序如何確定哪個應用程序到哪個隊列(或應用程序是否創建新隊列)的流程圖。

規則:specified

  • 規則概括:直接制定應用的隊列
  • 配置示例:<rule>
  • hadoop 命令執行隊列:hadoop jar mymr.jar app1 -Dmapreduce.job.queuename="root.myqueue"
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則: user

  • 規則概括: 以應用程序提交者的用戶名作為隊列名。例如,如果Fred是用戶啟動YARN應用程序,則流程圖中的隊列將為root.fred。
  • 配置示例:<rule>
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則:primaryGroup

  • 規則概括:將應用程序分配到以用戶所屬的主組(通常是第一個組)命名的隊列。例如,如果啟動應用程序的用戶屬於Marketing組,則流程圖中的隊列將為root.marketing。
  • 配置示例:<rule>
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則:secondaryGroupExistingQueue

  • 規則概括:將應用程序分配到以用戶所屬的第一個有效輔助組(換句話說,不是主組)命名的隊列。例如,如果用戶屬於輔助組market_eu,market_auto,market_germany,則流程圖中的隊列將迭代.
  • 配置示例:<rule>
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則: nestedUserQueue

  • 規則概括:在除root以外的其他隊列下創建用戶隊列。 “其他隊列”由nestedUserQueue規則所包含的規則確定。
  • 配置模板:
<rule>



  • 配置示例:
<rule>
<rule>

  • 此規則創建user隊列,但在root隊列之外的隊列下。首先評估內部隊列放置策略,然後在下面創建user隊列。注意,如果nestedUserQueue規則沒有設置屬性create =“true”,那麼只有在特定用戶隊列已經存在的情況下才能提交應用程序。
  • 流程圖:
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則:default

  • 規則概括:定義默認隊列
  • 配置示例:<rule>
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

規則:reject

  • 規則概括:拒絕應用程序提交,這通常用作最後一個規則。
  • 配置:<rule>
  • Note: 如果標準hadoop jar命令被此規則拒絕,則會出現錯誤消息java.io.IOException: Failed to run job : Application rejected by queue placement policy
  • 流程圖
揭秘Apache Hadoop YARN,第四部分:公平調度隊列基礎

應用程序狀態

如本系列的第一篇分所述,應用程序包括一個或多個任務,每個任務在容器中運行。本系列文章中,應用程序可以是以下四種狀態之一:

pending 應用程序還未被分配container.

active 應用程序運行在一個或多個container中.

starving 應用程序資源請求為滿足.

finished 所有任務完成.

樣例:在群集中運行程序

假設我們有一個總資源的兩個隊列的YARN集群:root.busy(weight = 1.0)和root.sometimes_busy(weight 3.0)。通常有四種感興趣的情景:

場景 A: busy隊列跑滿了應用程序,sometimes_busy隊列有少量正在運行的應用程序(例如10%,即 <memory>)。然後,大量應用程序在相對較短的時間內添加到sometimes_busy隊列中。 somet_busy中的所有新應用程序將處於待處理狀態,並且等待busy隊列中的容器完成後才能變為活動狀態. 如果busy隊列中的任務很短,那麼somet_busy隊列中的應用程序不會等待很長時間才能獲取容器分配。反之需要等待很長時間。 還有就是,當somet_busy隊列中的應用程序變為活動狀態時,busy隊列中的許多正在運行的應用程序將需要更長的時間才能完成。

場景 B: busy和sometimes_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隊列。

配置搶佔(Preemption)公平調度

在yarn-site.xml文件中配置以下屬性,開啟搶佔

<property>yarn.scheduler.fair.preemption
<value>true

然後,在您的FairScheduler分配文件中,可以通過fairSharePreemptionThreshold和fairSharePreemptionTimeout在隊列上配置搶佔,如下面的示例所示。 fairSharePreemptionTimeout是隊列在fairSharePreemptionThreshold情況下的秒數,之後它將嘗試搶佔容器從其他隊列獲取資源。

<allocations>
<queue>
<weight>1.0

<queue>
<weight>3.0
<fairsharepreemptionthreshold>0.50
<fairsharepreemptiontimeout>60


<queueplacementpolicy>
<rule>
<rule>


回想一下,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隊列。

1.不會發生反向搶佔,因為在busy列上沒有設置搶佔屬性。

2.搶佔不會從somet_busy隊列中的應用程序A中刪除容器,並將它們分配給somet_busy隊列中的應用程序B.

3. 如果一個隊列或者他的祖先隊列都沒有設置fairSharePreemptionTimeout ,並且defaultFairSharePreemptionTimeout 也沒有設置,這個隊列優先權不會生效,即使設置了。

(注意:我們不會在隊列上配置minResources和minSharePreemptionTimeout)目前推薦使用FairShare搶佔。)

擴展閱讀

要獲得有關Fair Scheduler的更多信息,請查看在線文檔(Apache Hadoop和CDH版本可用)。

結論

1.有許多屬性可以在隊列上設置。這包括限制資源,限制應用程序,設置用戶或管理員以及設置調度策略。

2.隊列配置文件還應包括隊列放置策略。隊列放置策略定義如何將應用程序分配給隊列。

3.在隊列中運行的應用程序可以將應用程序保持在pending或starving狀態的不同隊列中。在Fair Scheduler中配置搶佔可以更快地調整這些不平衡。


分享到:


相關文章: