Hadoop FairScheduler

時間 2019-11-06

原文原文鏈接

目標

本文檔描述FairScheduler，一個容許YARN應用程序公平共享集羣資源的調度插件。node

概述web

公平調度是一個分配資源給全部application的方法，平均來看，是隨着時間的進展平等分享資源的。下一代Hadoop可調度多資源類型。默認的，FairScheduler只基於內存的公平調度策略。它能夠配置爲包括內存和cpu的調度，採用Ghodsi等開發的主資源公平算法。當只有一個application運行時，該application使用整個集羣。當其餘應用程序提交以後，釋放出來的資源分配給新的application，因此每一個application最終會獲得大體相同量的資源。不像默認的hadoop調度器，它由一個應用程序的隊列組成，這讓短應用在合理的時間內結束而不是長時間存活引發系統調度飢餓。它仍是在必定數量用戶間共享集羣的一個合理方法。最後，公平分享也能夠與應用程序優先級一塊兒工做——優先級用做決定每一個應用程序應該得到的總資源的比例的權重。算法

調度器組織應用程序進入「隊列」，並公平共享這些隊列間的資源。默認的，全部用戶共享一個叫作「default」的隊列。若是一個應用程序在容器資源請求中列出了一個隊列，那麼這個請求將被提交到該隊列。經過配置也能夠基於包含在請求中的用戶名來分配隊列。對於每個隊列，經過一個調度策略用於在運行的應用程序中共享資源。默認是基於內存的公平共享，可是也能夠配置FIFO和多資源的DRF。隊列能夠編排成層級結構以便拆分資源，而且能夠經過權重配置分享集羣特定比例的資源。apache

另外爲了提供公平共享，Fairscheduler容許爲隊列分配最小共享份額，這對確保特定用戶、組、產品應用始終得到足夠的資源很是有用。當隊列包含應用時，它至少要得到共享最小份額，可是當隊列不須要它徹底保證的份額時，多出的部分拆分給其餘運行中的應用程序。這就讓調度器既保證了隊列的容量，又能夠在這些隊列不包含應用程序時高效的利用資源。併發

FairScheduler默認讓全部app運行，可是它也能經過配置文件限制每一個用戶、隊列的運行app的數量。這對用戶一次必須提交幾百app或者想要提高性能（若是一次運行過多app會引發建立過多的中間數據，或者過多的上下文切換）時頗有用。限制app不會引發後續的提交app失敗，只會在調度器的隊列中等待，直到某些用戶較早的app結束。app

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

Fair Scheduler支持層級隊列。全部的隊列都從屬於一個叫作「root」的隊列。可用的資源採用典型的公平調度方式在root隊列的子隊列中分佈。而後，子隊列將分配給他們的資源採用相同的方式分佈到他們的子隊列中。App只在葉子隊列上調度。經過在分配文件中放置隊列做爲他們雙親的子元素，能夠將隊列指定爲其餘隊列的子隊列。oop

隊列的名稱已其雙親的名稱做爲開頭，用句點（"."）做爲分隔符.因此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中存在的特定插件如今還不支持。其中，是使用自定義的策略在特定應用程序上調整優先級「提高」。spa

自動放置應用程序到隊列插件

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>

配置

定製化FairScheduler一般會引發兩個文件的變動。首先調度器層面的選項能夠經過在配置目錄下yar-site.xml文件中增長配置項進行設置。其次，在大多數狀況下用戶將想要建立一個分配文件代表存在哪些隊列，以及它們的相應權重和容量。這個分配文件每10秒重載一次，所以容許在運行時進行修改。

yarn-site.xml中能夠被放置的屬性

屬性描述

`yarn.scheduler.fair.allocation.file`	分配文件的路徑。分配文件是一個xml，描述隊列以及它們的屬性，補充特定的默認策略。這個文件必須是下一節描述的xml格式。若是指定了一個相對路徑，將會在classpath下搜索這個文件（一般在hadoop的conf目錄下）。默認是fair-scheduler.xml.
`yarn.scheduler.fair.user-as-default-queue`	在隊列名未指定的狀況下，是否使用用戶名做爲分配的默認隊列名。若是本項設置爲「false」或者未設置，全部的做業擁有一個共享的默認隊列，名爲「default」。默認值爲true.若是一個隊列的放置策略已經在分配文件中指定，本屬性將會被忽略。
`yarn.scheduler.fair.preemption`	是否使用搶佔。默認是false。
`yarn.scheduler.fair.preemption.cluster-utilization-threshold`	啓動搶佔後的資源利用率閾值。利用率是計算全部資源中容量使用的最大比率。默認值是0.8f。
`yarn.scheduler.fair.sizebasedweight`	是否基於獨立app的大小爲其分配共享資源，而不是不顧全部app的大小都分配相等的共享資源。當設置爲true時，app的權重是app的全部請求內存的天然對數加權，除以以2爲底的天然對數。默認值爲false.
`yarn.scheduler.fair.assignmultiple`	是否容許一次心跳中進行多容器分配。默認是false.
`yarn.scheduler.fair.max.assign`	若是assignmultiple 設置爲true，一次心跳最多分配的容器數量。默認爲-1，表示不限制。
`yarn.scheduler.fair.locality.threshold.node`	對於請求在特定節點的容器的apps，自從最後一次容器分配以後等待接受配置到其餘節點的調度機會次數。表達式爲0到1之間的浮點數，做爲集羣大小的因子，是錯過的調度機會。默認值爲-1.0意思是不錯過任何調度機會。當應用程序請求某個節點上資源時，它能夠接受的可跳過的最大資源調度機會。當按照分配策略，可將一個節點上的資源分配給某個應用程序時，若是該節點不是應用程序指望的節點，可選擇跳過該分配機會暫時將資源分配給其餘應用程序，直到出現知足該應用程序需的節點資源出現。一般而言，一次心跳錶明一次調度機會，而該參數則表示跳過調度機會佔節點總數的比例，默認狀況下，該值爲-1.0，表示不跳過任何調度機會。
`yarn.scheduler.fair.locality.threshold.rack`	對於請求在特定機架的容器的apps，自從最後一次容器分配等待接受配置到其餘機架的調度機會數量。表達式爲0到1之間的浮點數，做爲集羣大小的因子，是錯過的調度機會。默認值爲-1.0意思是不錯過任何調度機會。
`yarn.scheduler.fair.allow-undeclared-pools`	若是設置爲true，application提交時能夠建立新的隊列，要麼是由於application指定了隊列，或者是按照user-as-default-queue放置到相應隊列。若是設置爲false，任什麼時候間一個app要放置到一個未在分配文件中指定的隊列，都將被放置到「default」隊列。默認是true。若是一個隊列放置策略已經在分配文件中指定，本屬性將會被忽略。
`yarn.scheduler.fair.update-interval-ms`	默認值500ms，鎖住調度器從新進行計算做業所需資源的間隔

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」的元素替代.

隊列訪問控制列表

訪問控制列表(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爲除"*"以外的其餘值.

管理

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 限制，本次移動將會失敗。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。