三：Fair Scheduler 公平調度器

參考資料：
http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/FairScheduler.html
http://han-zw.iteye.com/blog/2322189 (轉載其部分內容)

1.介紹
2.隊列分層
3.配置
3.1配置yarn-site.xml
3.2 Allocation file格式
3.3 隊列訪問控制列表
4.管理
4.1 運行時修改配置
4.2通過web UI進行監控
4.3隊列間移動應用程序

1.介紹

FairScheduler是yarn的一個調度器,支持多用戶並行執行任務.默認情況下, FairScheduler只對內存執行調度管理,需要對CPU也進程調度管理的話使用Ghodsi et al的"Dominant Resource Fairness"(CDH5.7似乎已經支持CPU調度).特點:

1. 允許資源共享,即當一個APP運行時,如果其它隊列沒有任務執行,則可以使用其它隊列(不屬於該APP的隊列),當其它隊列有APP需要資源時再將占用的隊列釋放出來.所有的APP都從資源隊列中分配資源.
2. 默認情況下,所有任務使用一個隊列default;
3. 如果任務指定了一個隊列,則在該隊列中提交任務.
4. 可以根據提交任務的用戶名來分配隊列.
5. 可以設置隊列最小資源,保證用戶可以啟動任務.
6. 當隊列中有任務,該隊列將至少獲得最小資源.當隊列資源使用不完時,可以給其它隊列使用.
7. 默認不限制每個隊列和用戶可以同時執行的app數量.可以配置來限制隊列和用戶並行執行的app數量.限制並行執行APP數量不會導致任務提交失敗,超出的app會在隊列中等待.
8. 當隊列不能滿足最小資源時,可以從其它隊列搶占.

2.隊列分層

FairScheduler支持子隊列,所有隊列的父隊列是"root"隊列.子隊列又可以分配子隊列(在allocation file里添加).子隊列繼續父隊列的名字,如'q1'這個子隊列的名字實際上是'root.q1',同樣,如果q2是q1的子隊列,則q2的名字為'root.q1.q2'.此外,用戶可以自定義隊列的資源分配情況,需要繼承"org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy"這個類.FifoPolicy\FairSharePolicy\DominantResourceFairnessPolicy(DRF)三種策略已經保含在FairScheduler中隨時可以使用.

3.配置

有兩個配置文件yarn-site.xml和allocation file,前者用來FairScheduler的核心參數,后面配置子隊列\用戶等參數.

3.1配置yarn-site.xml

參數	默認值	說明
yarn.scheduler.fair.allocation.file	Hadoop conf directory	allocation file的路徑.XML格式,默認名字是fair-scheduler.xml
yarn.scheduler.fair.user-as-default-queue	true	當沒有指定隊列名時,是否使用用戶名做為應用程序的隊列名.設置為false或不設置,則所有未知隊列的應用程序就會使用default隊列.
yarn.scheduler.fair.preemption	false	當隊列沒有達到分配的最小資源時,是否搶很搶占其它隊列的資源.
yarn.scheduler.fair.preemption.cluster-utilization-threshold	0.8f	啟用資源搶占后,可以使用的集群最大資源量.搶占優先級最低,id最大的container
yarn.scheduler.fair.sizebasedweight	false	是否根據任務需要的資源權重來分配資源.默認一個隊列中所有的任務用的資源都是相同的.設置為true,app的權重是app的所有請求內存的自然對數加權，除以以2為底的自然對數。
yarn.scheduler.fair.assignmultiple	false	批量分配資源,是否允許一次心跳中進行多容器分配
yarn.scheduler.fair.dynamic.max.assign	true	開啟批量分配資源后,一次可以分配未分配資源的一半給容器
yarn.scheduler.fair.max.assign	-1	如果開啟批量而yarn.scheduler.fair.dynamic.max.assign又設置為true時,一次分配的container的個數,默認分-1不開啟指分配
yarn.scheduler.fair.locality.threshold.node	-1	在特定節點上申請資源的程序,當本節點無法滿足資源申請時,忽略轉移到其它節點上申請的概率因子,默認是-1,不忽略任務機會
yarn.scheduler.fair.locality.threshold.rack	-1	同上,節點改為機架
yarn.scheduler.fair.allow-undeclared-pools	true	在任務提交時是否允許創建不存在的新隊列.當為false時,任務指定了不存在的隊列則將在default中執行
yarn.scheduler.fair.update-interval-ms	500ms	調度器重新計算資源的時間間隔
yarn.scheduler.increment-allocation-mb	1024mb	調度器分配的內存增量單位,每次至少新增加這么多內存,四舍五入
yarn.scheduler.increment-allocation-vcores	1	同上,增加的核心數

3.2 Allocation file格式

(以下內容轉載自http://han-zw.iteye.com/blog/2322189)
分配文件必須是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的一個樣例：

<pre style="font-family: monospace; font-size: 1em;"><?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>
</pre>

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

3.3 隊列訪問控制列表

訪問控制列表(ACLs)允許管理員控制誰能對特定隊列執行操作。這些用戶通過aclSubmitApps 和aclAdministerApps屬性配置，可以設置在每個隊列上。當前唯一支持的管理性操作就是殺死app。任何能夠管理管理的人也都可以向該隊列提交app.這些屬性的值像 “user1,user2 group1,group2” 或者“ group1,group2”的格式。如果用戶或者組是在隊列的ACLs中或者在這個隊列的任意祖先的ACLs中，那么他對該隊列的操作是被允許的。所以，如果queue2 在queue1內部，並且user1 在queue1的ACL中，user2 在queue2的ACL中，那么兩個用戶都可以向queue2提交app.

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

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

4.管理

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

4.1 運行時修改配置

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

4.2通過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-隊列的固定公平份額，無論這些隊列是否活躍。他們很少被計算和修改，除非配置或者容量發生變化。他們意思是提供資源可視化。

4.3隊列間移動應用程序

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

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

來自為知筆記(Wiz)