Hadoop FairScheduler

目標

本文檔描述FairScheduler，一個允許YARN應用程式公平共用集群資源的調度插件。

概述

公平調度是一個分配資源給所有application的方法，平均來看，是隨著時間的進展平等分享資源的。下一代Hadoop可調度多資源類型。預設的，FairScheduler只基於記憶體的公平調度策略。它可以配置為包括記憶體和cpu的調度，採用Ghodsi等開發的主資源公平演算法。當只有一個application運行時，該application使用整個集群。當其他應用程式提交之後，釋放出來的資源分配給新的application，所以每個application最終會得到大致相同量的資源。不像預設的hadoop調度器，它由一個應用程式的隊列組成，這讓短應用在合理的時間內結束而不是長時間存活引起系統調度饑餓。它還是在一定數量用戶間共用集群的一個合理方法。最後，公平分享也可以與應用程式優先順序一起工作——優先順序用作決定每個應用程式應該獲得的總資源的比例的權重。

調度器組織應用程式進入“隊列”，並公平共用這些隊列間的資源。預設的，所有用戶共用一個叫做“default”的隊列。如果一個應用程式在容器資源請求中列出了一個隊列，那麼這個請求將被提交到該隊列。通過配置也可以基於包含在請求中的用戶名來分配隊列。對於每一個隊列，通過一個調度策略用於在運行的應用程式中共用資源。預設是基於記憶體的公平共用，但是也可以配置FIFO和多資源的DRF。隊列可以編排成層級結構以便拆分資源，並且可以通過權重配置分享集群特定比例的資源。

另外為了提供公平共用，Fairscheduler允許為隊列分配最小共用份額，這對確保特定用戶、組、產品應用始終獲得足夠的資源非常有用。當隊列包含應用時，它至少要獲得共用最小份額，但是當隊列不需要它完全保證的份額時，多出的部分拆分給其他運行中的應用程式。這就讓調度器既保證了隊列的容量，又可以在這些隊列不包含應用程式時高效的利用資源。

FairScheduler預設讓所有app運行，但是它也能通過配置文件限制每個用戶、隊列的運行app的數量。這對用戶一次必須提交幾百app或者想要提升性能（如果一次運行過多app會引起創建過多的中間數據，或者過多的上下文切換）時很有用。限制app不會引起後續的提交app失敗，只會在調度器的隊列中等待，直到某些用戶較早的app結束。

具有插件式策略的層級隊列

Fair Scheduler支持層級隊列。所有的隊列都從屬於一個叫做“root”的隊列。可用的資源採用典型的公平調度方式在root隊列的子隊列中分佈。然後，子隊列將分配給他們的資源採用相同的方式分佈到他們的子隊列中。App只在葉子隊列上調度。通過在分配文件中放置隊列作為他們雙親的子元素，可以將隊列指定為其他隊列的子隊列。

隊列的名稱已其雙親的名稱作為開頭，用句點（"."）作為分隔符.所以root隊列下的名為"queue1"的隊列會被稱為“root.queue1”,位於“parent1”隊列下的“queue2”隊列會被稱為"root.parent1.queue2".當提到隊列時，名稱中的root部分是可選的，所以queue1可以被稱為"queue1",queue2可以被稱為“parent1.queue2”.

另外，FairScheduler允許為不同的隊列設置不同的個性化策略，允許採用用戶想要的方式共用隊列的資源。個性化策略可以通過繼承 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy來構建。 內置的FifoPolicy, FairSharePolicy (預設的), 以及DominantResourceFairnessPolicy策略可以方便的使用。在原始的（MR1）FairScheduler中存在的特定插件現在還不支持。其中，是使用自定義的策略在特定應用程式上調整優先順序“提升”。

自動放置應用程式到隊列

Fairscheduler允許管理員配置策略，將提交的應用程式放置到相應的隊列。放置依賴於提交的用戶和組，以及應用程式傳過來的申請中的隊列信息。一個策略由一組規則組成，這些規則對進來的應用程式進行一系列的分類。每個規則要麼放置應用程式到一個隊列，或者拒絕它，又或者繼續交由下一個規則。關於如何配置這些策略可以參考下麵分配文件格式。

安裝

要使用FairScheduler首先要在yarn-site.xml中指定相應的調度器class。

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

配置

yarn-site.xml中可以被放置的屬性

Allocation file格式

分配文件必須是XML格式。格式包含5類元素：

• 隊列元素：描述隊列。隊列元素可以設定一個可選的屬性‘type’，當它設置為‘parent’時表示它是一個父隊列。當我們想創建一個父隊列但是不想配置任何子隊列時可以採用這種方式。每個隊列元素可以包含下麵的屬性：

• • minResources:  隊列有權享有的最小資源，採用"X mb, Y vcores”"的形式。對於單一資源公平策略，vcores的值將被忽略。如果一個隊列的最小共用未能得到滿足，那麼它將會在相同parent下其他隊列之前獲得可用資源。在單一資源公平策略下，一個隊列如果它的記憶體使用量低於最小記憶體值則認為是未滿足的。在DRF策略下，如果一個隊列的主資源是低於最小共用的話則認為是未滿足的。如果有多個隊列未滿足的情況，資源分配給相關資源使用量和最小值之間比率最小的隊列。註意一點情況，有可能一個隊列處於最小資源之下，但是在它提交application時不會立刻達到最小資源，因為已經在運行的job會使用這些資源。
  • maxResources: 一個隊列允許的最大資源，採用“X mb, Y vcores”的形式。對於單一資源公平策略，vcores的值會被忽略。一個隊列永遠不會分配資源總量超過這個限制。
  • maxRunningApps: 限制隊列一次運行的apps數量。
  • maxAMShare：限制隊列用於運行Application Master的資源比例。這個屬性只能用於葉子隊列。比如，如果設置為1.0f，那麼在這個隊列的AMs可以占用100%的記憶體和CPU的公平共用。這個值為-1.0f將會禁用該特性並且amShare不會進行校驗。預設值是0.5f。
  • weight: 與其他隊列非比例的分享集群。權重預設是1，權重是2的隊列將會收到接近預設權重2倍的資源。
  • schedulingPolicy：任一隊列都可以設置調度策略。允許的值包括“fifo”，“fair”，“drf”或者其他任何繼承org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy的類。預設是“fair”。如果為"fifo"，提交時間較早的apps優先分配容器，但是如果集群在滿足較早的apps請求之後剩餘足夠的空間，提交較晚的apps可能併發運行。
  • aclSubmitApps：可以提交apps到隊列的用戶或者組的列表。要獲得更多信息可以參考下麵的ACLs部分，關於列表的格式和ACLs如何發揮作用。
  • aclAdministerApps：可以管理隊列的用戶或者組列表。當前唯一的管理動作就是殺死應用程式。要獲得更多信息可以參考下麵的ACLs部分，關於列表的格式和ACLs如何發揮作用。
  • minSharePreemptionTimeout：隊列處在最小共用之下，在嘗試搶占其他隊列的資源之前的秒數。如果不設置，隊列將會總其父隊列繼承這個值。
  • fairSharePreemptionTimeout：隊列處在最小公平共用閾值之下，在嘗試搶占其他隊列的資源之前的秒數。如果不設置，隊列將會總其父隊列繼承這個值。
  • fairSharePreemptionThreshold：隊列的公平共用搶占閾值。如果隊列等待fairSharePreemptionTimeout之後沒有接收到fairSharePreemptionThreshold*fairShare的資源，它被允許從其他隊列搶占資源。如果不設置，隊列將會總其父隊列繼承這個值。

• User elements：設置對單獨用戶行為的管理。它們可以包含單一屬性：maxRunningApps，對特定用戶可以運行的apps的數量限制。

• A userMaxAppsDefault element：設置任意用戶（沒有特定限制的用戶）運行app的預設最大數量限制。

• A defaultFairSharePreemptionTimeout element：設置root隊列的公平共用搶占的預設超時時間；可以被root隊列下的fairSharePreemptionTimeout 設置覆蓋。

• A defaultMinSharePreemptionTimeout element：設置root隊列的預設最小共用搶占超時時間；可以被root隊列下minSharePreemptionTimeout覆蓋。

• A defaultFairSharePreemptionThreshold element：設置root隊列的公平共用搶占的預設閾值；可以被root隊列下的fairSharePreemptionThreshold 覆蓋。

• A queueMaxAppsDefault element：設置隊列的預設運行app數量限制；可以被任一隊列的maxRunningApps元素覆蓋。

• A queueMaxAMShareDefault element:設置隊列的預設AM共用資源限制；可以被任一隊列的maxAMShare 元素覆蓋。

• A defaultQueueSchedulingPolicy element：設置隊列的預設調度策略；可以在任一隊列中設置schedulingPolicy 進行覆蓋該預設值。預設值為“fair”。

• A queuePlacementPolicy element:包含一個Rule元素列表用於告訴調度器如何放置app到隊列。Rule生效順序與列表中的順序一致。Rule可以含有參數。所有Rule接受"create"參數，用於標明該規則是否能夠創建新隊列."Create"預設值為true;如果設置為false並且Rule要放置app到一個allocations file沒有配置的隊列，那麼繼續應用下一個Rule。最後的Rule絕不能執行Continue。合法的規則是：

  • specified：app放置到它請求的隊列。如果沒有請求隊列，例如它指定"default",執行continue。如果app請求隊列以英文句點開頭或者結尾，例如 “.q1” 或者 “q1.” 將會被拒絕.
  • user:app按照提交用戶名放置到同名的隊列。用戶名中的英文句點將會被“_dot_”替換，如對於用戶"first.last"的隊列名是"first_dot_last".
  • primaryGroup:app放置到與提交用戶primary group同名的隊列。用戶名中的英文句點將會被“_dot_”替換，如對於組"one.two"的隊列名是"one_dot_two".
  • secondaryGroupExistingQueue：app放置到與提交用戶所屬的secondary group名稱相匹配的隊列。第一個與配置相匹配的secondary group將會被選中。組名中的英文句點會被替換成“_dot_”,例如用戶使用“one.two”作為他的secondary groups將會放置到“one_dot_two”隊列，如果這個隊列存在的話。
  • nestedUserQueue: app放置到根據隊列中嵌套規則建議的用戶名同名的隊列中。這有些類似於UserRule，在‘nestedUserQueue’規則中不同的是用戶隊列可以創建在任意父隊列下，而'user'規則只能在root隊列下創建用戶隊列。有一點需要註意，nestedUserQueue 規則只有在嵌入規則返回一個父隊列時才會生效。用戶可以通過設置 隊列的‘type’屬性為 ‘parent’ 來配置父隊列，或者在隊列下至少配置一個葉子。
  • default: app放置到default規則中指定的 ‘queue’屬性對應的隊列。如果 ‘queue’屬性沒有指定，app放置到 ‘root.default’ 隊列.
  • reject:拒絕app.

  以下給出 allocation file的一個樣例：

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>

  <!-- Queue 'secondary_group_queue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  </queue>
  
  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>
  
  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

為了保持與原始的FairScheduler的向後相容，“queue”元素可以用名為“pool”的元素替代.

隊列訪問控制列表

備註：分隔符是空格。要只是指定ACL組，該值需要以空格開頭.

root隊列的ACLs預設是"*"，因為ACLs是向下傳遞的，意思是每個用戶都可以對每一個隊列提交和殺死App。要啟動嚴格的方訪問，修改root隊列的ACL為除"*"之外的其他值.

管理

Fair Scheduler通過一些機制提供運行時的管理功能：

運行時修改配置

通過編輯allocation file可以在運行時完成修改最小共用，資源限制，權重，超時搶占以及隊列調度策略等。調度器會每個10-15秒重載修改後的該配置文件.

通過web UI進行監控

當前應用、隊列以及公平共用都可以通過ResourceManager的web UI查看，地址在http://*ResourceManager URL*/cluster/scheduler。

在web UI上可以看到每個隊列的以下欄位：

• Used Resources-隊列已經分配的容器的資源之和。

• Num Active Applications-隊列中已經接受到至少一個容器的應用程式數量。

• Num Pending Applications-隊列中還沒有接受任何一個容器的應用程式的數量。

• Min Resources-配置的授予隊列的最小資源。

• Max Resources - 配置的隊列允許的最大資源.

• Instantaneous Fair Share - 隊列的資源的瞬時公平共用。這些共用只考慮活動的隊列（那些有運行中程式的），而且被調度決策所使用。當其他隊列沒有使用某些資源時，隊列可以被分配到超過他shares的資源。一個隊列的資源消費處在或者低於它的瞬時公平份額將不會有容器被搶占。

• Steady Fair Share-隊列的固定公平份額，無論這些隊列是否活躍。他們很少被計算和修改，除非配置或者容量發生變化。他們意思是提供資源可視化。

隊列間移動應用程式

Fair Scheduler 支持移動一個運行中的應用程式到另外一個隊列。這個可以用於移動一個重要的應用程式到較高優先順序隊列，或者移動一個不重要的應用程式到一個較低優先順序的隊列。通過運行 yarn application -movetoqueue appID -queue targetQueueName可以移動運行中的應用程式。

當應用程式移動到一個隊列，出於公平考慮，它的現存的分配計算會變成新隊列的資源分配。如果加入被移動的應用程式的資源超出目標隊列的maxRunningApps 或者maxResources 限制，本次移動將會失敗。