本文轉(zhuǎn)載自微信公眾號「Java大數(shù)據(jù)與數(shù)據(jù)倉庫」,作者老董。轉(zhuǎn)載本文請聯(lián)系Java大數(shù)據(jù)與數(shù)據(jù)倉庫公眾號。
目錄
1. Yarn調(diào)度器介紹
FIFO(先進先出調(diào)度器)
Capacity(容量調(diào)度器)
Fair(公平調(diào)度器)
Fair與Capacity區(qū)別
2.Yarn調(diào)度器配置
Fair
Capacity配置(默認配置)
FIFO
理想情況下,我們應(yīng)用對Yarn資源的請求應(yīng)該立刻得到滿足,但現(xiàn)實情況資源往往是有限的,特別是在一個很繁忙的集群,一個應(yīng)用資源的請求經(jīng)常需要等待一段時間才能的到相應(yīng)的資源。在Yarn中,負責(zé)給應(yīng)用分配資源的就是Scheduler。其實調(diào)度本身就是一個難題,很難找到一個完美的策略可以解決所有的應(yīng)用場景。為此,Yarn提供了多種調(diào)度器和可配置的策略供我們選擇。YARN架構(gòu)如下:
ResourceManager(RM):負責(zé)對各NM上的資源進行統(tǒng)一管理和調(diào)度,將AM分配空閑的Container運行并監(jiān)控其運行狀態(tài)。對AM申請的資源請求分配相應(yīng)的空閑Container。主要由兩個組件構(gòu)成:調(diào)度器(Scheduler)和應(yīng)用程序管理器(Applications Manager)。
調(diào)度器(Scheduler):調(diào)度器根據(jù)容量、隊列等限制條件(如每個隊列分配一定的資源,最多執(zhí)行一定數(shù)量的作業(yè)等),將系統(tǒng)中的資源分配給各個正在運行的應(yīng)用程序。調(diào)度器僅根據(jù)各個應(yīng)用程序的資源需求進行資源分配,而資源分配單位是Container,從而限定每個任務(wù)使用的資源量。Scheduler不負責(zé)監(jiān)控或者跟蹤應(yīng)用程序的狀態(tài),也不負責(zé)任務(wù)因為各種原因而需要的重啟(由ApplicationMaster負責(zé))??傊?,調(diào)度器根據(jù)應(yīng)用程序的資源要求,以及集群機器的資源情況,為用程序分配封裝在Container中的資源。調(diào)度器是可插拔的,例如CapacityScheduler、FairScheduler。(PS:在實際應(yīng)用中,只需要簡單配置即可)
應(yīng)用程序管理器(Application Manager):應(yīng)用程序管理器負責(zé)管理整個系統(tǒng)中所有應(yīng)用程序,包括應(yīng)用程序提交、與調(diào)度器協(xié)商資源以啟動AM、監(jiān)控AM運行狀態(tài)并在失敗時重新啟動等,跟蹤分給的Container的進度、狀態(tài)也是其職責(zé)。ApplicationMaster是應(yīng)用框架,它負責(zé)向
ResourceManager協(xié)調(diào)資源,并且與NodeManager協(xié)同工作完成Task的執(zhí)行和監(jiān)控。MapReduce就是原生支持的一種框架,可以在YARN上運行Mapreduce作業(yè)。有很多分布式應(yīng)用都開發(fā)了對應(yīng)的應(yīng)用程序框架,用于在YARN上運行任務(wù),例如Spark,Storm等。如果需要,我們也可以自己寫一個符合規(guī)范的YARN application。
NodeManager(NM):NM是每個節(jié)點上的資源和任務(wù)管理器。它會定時地向RM匯報本節(jié)點上的資源使用情況和各個Container的運行狀態(tài);同時會接收并處理來自AM的Container 啟動/停止等請求。ApplicationMaster(AM):用戶提交的應(yīng)用程序均包含一個AM,負責(zé)應(yīng)用的監(jiān)控,跟蹤應(yīng)用執(zhí)行狀態(tài),重啟失敗任務(wù)等。
Container:是YARN中的資源抽象,它封裝了某個節(jié)點上的多維度資源,如內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等,當(dāng)AM向RM申請資源時,RM為AM返回的資源便是用Container 表示的。YARN會為每個任務(wù)分配一個Container且該任務(wù)只能使用該Container中描述的資源。
1. Yarn調(diào)度器介紹
1.1. FIFO (先進先出調(diào)度器)
FIFO Scheduler把應(yīng)用按提交的順序排成一個隊列,這是一個先進先出隊列,在進行資源分配的時候,先給隊列中最頭上的應(yīng)用進行分配資源,待最頭上的應(yīng)用需求滿足后再給下一個分配,以此類推。FIFO Scheduler是最簡單也是最容易理解的調(diào)度器,也不需要任何配置,但它并不適用于共享集群。大的應(yīng)用可能會占用所有集群資源,這就導(dǎo)致其它應(yīng)用被阻塞。在共享集群中,更適合采用Capacity Scheduler或Fair Scheduler,這兩個調(diào)度器都允許大任務(wù)和小任務(wù)在提交的同時獲得一定的系統(tǒng)資源。下面“Yarn調(diào)度器對比圖”展示了這幾個調(diào)度器的區(qū)別,從圖中可以看出,在FIFO 調(diào)度器中,小任務(wù)會被大任務(wù)阻塞。
1.2. Capacity (容量調(diào)度器)
yarn-site.xml中默認配置的資源調(diào)度器。而對于Capacity調(diào)度器,有一個專門的隊列用來運行小任務(wù),但是為小任務(wù)專門設(shè)置一個隊列會預(yù)先占用一定的集群資源,這就導(dǎo)致大任務(wù)的執(zhí)行時間會落后于使用FIFO調(diào)度器時的時間。用這個資源調(diào)度器,就可以配置yarn資源隊列,這個后面后介紹用到。
1.3. Fair (公平調(diào)度器)
Fair調(diào)度器的設(shè)計目標是為所有的應(yīng)用分配公平的資源(對公平的定義可以通過參數(shù)來設(shè)置)。在上面的“Yarn調(diào)度器對比圖”展示了一個隊列中兩個應(yīng)用的公平調(diào)度;當(dāng)然,公平調(diào)度在也可以在多個隊列間工作。舉個例子,假設(shè)有兩個用戶A和B,他們分別擁有一個隊列。當(dāng)A啟動一個job而B沒有任務(wù)時,A會獲得全部集群資源;當(dāng)B啟動一個job后,A的job會繼續(xù)運行,不過一會兒之后兩個任務(wù)會各自獲得一半的集群資源。如果此時B再啟動第二個job并且其它job還在運行,則它將會和B的第一個job共享B這個隊列的資源,也就是B的兩個job會用于四分之一的集群資源,而A的job仍然用于集群一半的資源,結(jié)果就是資源最終在兩個用戶之間平等的共享。在Fair調(diào)度器中,我們不需要預(yù)先占用一定的系統(tǒng)資源,F(xiàn)air調(diào)度器會為所有運行的job動態(tài)的調(diào)整系統(tǒng)資源。當(dāng)?shù)谝粋€大job提交時,只有這一個job在運行,此時它獲得了所有集群資源;當(dāng)?shù)诙€小任務(wù)提交后,F(xiàn)air調(diào)度器會分配一半資源給這個小任務(wù),讓這兩個任務(wù)公平的共享集群資源。
a) 公平調(diào)度器,就是能夠共享整個集群的資源
b) 不用預(yù)先占用資源,每一個作業(yè)都是共享的
c) 每當(dāng)提交一個作業(yè)的時候,就會占用整個資源。如果再提交一個作業(yè),那么第一個作業(yè)就會分給第二個作業(yè)一部分資源,第一個作業(yè)也就釋放一部分資源。再提交其他的作業(yè)時,也同理。。。。也就是說每一個作業(yè)進來,都有機會獲取資源。
1.4. Fair Scheduler與Capacity Scheduler區(qū)別
資源公平共享:在每個隊列中,F(xiàn)air Scheduler可選擇按照FIFO、Fair或DRF策略為應(yīng)用程序分配資源。Fair策略即平均分配,默認情況下,每個隊列采用該方式分配資源
支持資源搶占:當(dāng)某個隊列中有剩余資源時,調(diào)度器會將這些資源共享給其他隊列,而當(dāng)該隊列中有新的應(yīng)用程序提交時,調(diào)度器要為它回收資源。為了盡可能降低不必要的計算浪費,調(diào)度器采用了先等待再強制回收的策略,即如果等待一段時間后尚有未歸還的資源,則會進行資源搶占;從那些超額使用資源的隊列中殺死一部分任務(wù),進而釋放資源
負載均衡:Fair Scheduler提供了一個基于任務(wù)數(shù)的負載均衡機制,該機制盡可能將系統(tǒng)中的任務(wù)均勻分配到各個節(jié)點上。此外,用戶也可以根據(jù)自己的需求設(shè)計負載均衡機制
調(diào)度策略靈活配置:Fiar Scheduler允許管理員為每個隊列單獨設(shè)置調(diào)度策略(當(dāng)前支持FIFO、Fair或DRF三種)
提高小應(yīng)用程序響應(yīng)時間:由于采用了最大最小公平算法,小作業(yè)可以快速獲取資源并運行完成
2.Yarn調(diào)度器配置
yarn資源調(diào)度器是在yarn-site.xml中配置。
2.1. Fair Scheduler
Fair Scheduler的配置選項包括兩部分:
一部分在yarn-site.xml中,主要用于配置調(diào)度器級別的參數(shù)
一部分在一個自定義配置文件(默認是fair-scheduler.xml)中,主要用于配置各個隊列的資源量、權(quán)重等信息。
2.1.1 yarn-site.xml
yarn-site.xml介紹
<!– scheduler start –>
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
<description>配置Yarn使用的調(diào)度器插件類名;Fair Scheduler對應(yīng)的是:org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</description>
</property>
<property>
<name>yarn.scheduler.fair.allocation.file</name>
<value>/etc/hadoop/conf/fair-scheduler.xml</value>
<description>配置資源池以及其屬性配額的XML文件路徑(本地路徑)</description>
</property>
<property>
<name>yarn.scheduler.fair.preemption</name>
<value>true</value>
<description>開啟資源搶占,default is True</description>
</property>
<property>
<name>yarn.scheduler.fair.user-as-default-queue</name>
<value>true</value>
<description>設(shè)置成true,當(dāng)任務(wù)中未指定資源池的時候,將以用戶名作為資源池名。這個配置就實現(xiàn)了根據(jù)用戶名自動分配資源池。default is True</description>
</property>
<property>
<name>yarn.scheduler.fair.allow-undeclared-pools</name>
<value>false</value>
<description>是否允許創(chuàng)建未定義的資源池。如果設(shè)置成true,yarn將會自動創(chuàng)建任務(wù)中指定的未定義過的資源池。設(shè)置成false之后,任務(wù)中指定的未定義的資源池將無效,該任務(wù)會被分配到default資源池中。,default is True</description>
</property>
<!– scheduler end –>
2.1.2 fair-scheduler.xml
假設(shè)在生產(chǎn)環(huán)境Yarn中,總共有四類用戶需要使用集群,production、spark、default、streaming。為了使其提交的任務(wù)不受影響,我們在Yarn上規(guī)劃配置了四個資源池,分別為production,spark,default,streaming。并根據(jù)實際業(yè)務(wù)情況,為每個資源池分配了相應(yīng)的資源及優(yōu)先級等,default用于開發(fā)測試目的.
ResourceManager上fair-scheduler.xml配置如下:
<?xml version="1.0"?>
<allocations>
<queue name="root">
<aclSubmitApps></aclSubmitApps>
<aclAdministerApps></aclAdministerApps>
<queue name="production">
<minResources>8192mb,8vcores</minResources>
<maxResources>419840mb,125vcores</maxResources>
<maxRunningApps>60</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>7.5</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>production</aclAdministerApps>
</queue>
<queue name="spark">
<minResources>8192mb,8vcores</minResources>
<maxResources>376480mb,110vcores</maxResources>
<maxRunningApps>50</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<weight>1</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>spark</aclAdministerApps>
</queue>
<queue name="default">
<minResources>8192mb,8vcores</minResources>
<maxResources>202400mb,20vcores</maxResources>
<maxRunningApps>20</maxRunningApps>
<schedulingMode>FIFO</schedulingMode>
<weight>0.5</weight>
<aclSubmitApps>*</aclSubmitApps>
<aclAdministerApps>*</aclAdministerApps>
</queue>
<queue name="streaming">
<minResources>8192mb,8vcores</minResources>
<maxResources>69120mb,16vcores</maxResources>
<maxRunningApps>20</maxRunningApps>
<schedulingMode>fair</schedulingMode>
<aclSubmitApps>*</aclSubmitApps>
<weight>1</weight>
<aclAdministerApps>streaming</aclAdministerApps>
</queue>
</queue>
<user name="production">
<!-- 對于特定用戶的配置:production最多可以同時運行的任務(wù) -->
<maxRunningApps>100</maxRunningApps>
</user>
<user name="default">
<!-- 對于默認用戶配置最多可以同時運行的任務(wù) -->
<maxRunningApps>10</maxRunningApps>
</user>
<!-- users max running apps -->
<userMaxAppsDefault>50</userMaxAppsDefault>
<!--默認的用戶最多可以同時運行的任務(wù) -->
<queuePlacementPolicy>
<rule name="specified"/>
<rule name="primaryGroup" create="false" />
<rule name="secondaryGroupExistingQueue" create="false" />
<rule name="default" queue="default"/>
</queuePlacementPolicy>
</allocations>
參數(shù)介紹:
minResources:最少資源保證量,設(shè)置格式為“X mb, Y vcores”,當(dāng)一個隊列的最少資源保證量未滿足時,它將優(yōu)先于其他同級隊列獲得資源,對于不同的調(diào)度策略(后面會詳細介紹),最少資源保證量的含義不同,對于fair策略,則只考慮內(nèi)存資源,即如果一個隊列使用的內(nèi)存資源超過了它的最少資源量,則認為它已得到了滿足;對于drf策略,則考慮主資源使用的資源量,即如果一個隊列的主資源量超過它的最少資源量,則認為它已得到了滿足。
maxResources:最多可以使用的資源量,fair scheduler會保證每個隊列使用的資源量不會超過該隊列的最多可使用資源量。
maxRunningApps:最多同時運行的應(yīng)用程序數(shù)目。通過限制該數(shù)目,可防止超量Map Task同時運行時產(chǎn)生的中間輸出結(jié)果撐爆磁盤。
weight:資源池權(quán)重,主要用在資源共享之時,weight越大,拿到的資源越多。比如一個pool中有20GB內(nèi)存用不了,這時候可以共享給其他pool,其他每個pool拿多少,就是由權(quán)重決定的
aclSubmitApps:可向隊列中提交應(yīng)用程序的Linux用戶或用戶組列表,默認情況下為“*”,表示任何用戶均可以向該隊列提交應(yīng)用程序。需要注意的是,該屬性具有繼承性,即子隊列的列表會繼承父隊列的列表。配置該屬性時,用戶之間或用戶組之間用“,”分割,用戶和用戶組之間用空格分割,比如“user1, user2 group1,group2”。
aclAdministerApps:允許管理任務(wù)的用戶名和組;一個隊列的管理員可管理該隊列中的資源和應(yīng)用程序,比如可殺死任意應(yīng)用程序。
minSharePreemptionTimeout :最小共享量搶占時間。如果一個資源池在該時間內(nèi)使用的資源量一直低于最小資源量,則開始搶占資源。
schedulingMode/schedulingPolicy:隊列采用的調(diào)度模式,可以是fifo、fair或者drf。
管理員也可為單個用戶添加maxRunningJobs屬性限制其最多同時運行的應(yīng)用程序數(shù)目。此外,管理員也可通過以下參數(shù)設(shè)置以上屬性的默認值:
userMaxJobsDefault:用戶的maxRunningJobs屬性的默認值。
defaultMinSharePreemptionTimeout :隊列的minSharePreemptionTimeout屬性的默認值。
defaultPoolSchedulingMode:隊列的schedulingMode屬性的默認值。
fairSharePreemptionTimeout:公平共享量搶占時間。如果一個資源池在該時間內(nèi)使用資源量一直低于公平共享量的一半,則開始搶占資源。
這樣,每個用戶組下的用戶提交任務(wù)時候,會到相應(yīng)的資源池中,而不影響其他業(yè)務(wù)。隊列的層次是通過嵌套
元素實現(xiàn)的。所有的隊列都是root隊列的孩子,即使沒有配到元素里。Fair調(diào)度器中的隊列有一個權(quán)重屬性(這個權(quán)重就是對公平的定義),并把這個屬性作為公平調(diào)度的依據(jù)。在這個例子中,當(dāng)調(diào)度器分配集群7.5,1,1,0.5資源給production,spark,streaming,default時便視作公平,這里的權(quán)重并不是百分比。注意,對于在沒有配置文件時按用戶自動創(chuàng)建的隊列,它們?nèi)杂袡?quán)重并且權(quán)重值為1。每個隊列內(nèi)部仍可以有不同的調(diào)度策略。隊列的默認調(diào)度策略可以通過頂級元素進行配置,如果沒有配置,默認采用公平調(diào)度。盡管是Fair調(diào)度器,其仍支持在隊列級別進行FIFO調(diào)度。每個隊列的調(diào)度策略可以被其內(nèi)部的元素覆蓋,在上面這個例子中,default隊列就被指定采用fifo進行調(diào)度,所以,對于提交到default隊列的任務(wù)就可以按照FIFO規(guī)則順序的執(zhí)行了。需要注意,spark,production,streaming,default之間的調(diào)度仍然是公平調(diào)度。每個隊列可配置最大、最小資源占用數(shù)和最大可運行的應(yīng)用的數(shù)量。
Fair調(diào)度器采用了一套基于規(guī)則的系統(tǒng)來確定應(yīng)用應(yīng)該放到哪個隊列。在上面的例子中,元素定義了一個規(guī)則列表,其中的每個規(guī)則會被逐個嘗試直到匹配成功。例如,上例第一個規(guī)則specified,則會把應(yīng)用放到它指定的隊列中,若這個應(yīng)用沒有指定隊列名或隊列名不存在,則說明不匹配這個規(guī)則,然后嘗試下一個規(guī)則。primaryGroup規(guī)則會嘗試把應(yīng)用放在以用戶所在的Unix組名命名的隊列中,如果沒有這個隊列,不創(chuàng)建隊列轉(zhuǎn)而嘗試下一個規(guī)則。當(dāng)前面所有規(guī)則不滿足時,則觸發(fā)default規(guī)則,把應(yīng)用放在default隊列中。
當(dāng)然,我們可以不配置queuePlacementPolicy規(guī)則,調(diào)度器則默認采用如下規(guī)則:
<queuePlacementPolicy>
<rule name="specified" />
<rule name="user" />
</queuePlacementPolicy>
上面規(guī)則意思是除非隊列被準確的定義,否則會以用戶名為隊列名創(chuàng)建隊列。還有一個簡單的配置策略可以使得所有的應(yīng)用放入同一個隊列(default),這樣就可以讓所有應(yīng)用之間平等共享集群而不是在用戶之間。這個配置的定義如下:
<queuePlacementPolicy>
<rule name="default" />
</queuePlacementPolicy>
實現(xiàn)上面功能我們還可以不使用配置文件,直接設(shè)置yarn.scheduler.fair.user-as-default-queue=false,這樣應(yīng)用便會被放入default 隊列,而不是各個用戶名隊列。另外,我們還可以設(shè)置yarn.scheduler.fair.allow-undeclared-pools=false,這樣用戶就無法創(chuàng)建隊列了。
當(dāng)一個job提交到一個繁忙集群中的空隊列時,job并不會馬上執(zhí)行,而是阻塞直到正在運行的job釋放系統(tǒng)資源。為了使提交job的執(zhí)行時間更具預(yù)測性(可以設(shè)置等待的超時時間),F(xiàn)air調(diào)度器支持搶占。搶占就是允許調(diào)度器殺掉占用超過其應(yīng)占份額資源隊列的containers,這些containers資源便可被分配到應(yīng)該享有這些份額資源的隊列中。需要注意搶占會降低集群的執(zhí)行效率,因為被終止的containers需要被重新執(zhí)行??梢酝ㄟ^設(shè)置一個全局的參數(shù)yarn.scheduler.fair.preemption=true來啟用搶占功能。此外,還有兩個參數(shù)用來控制搶占的過期時間(這兩個參數(shù)默認沒有配置,需要至少配置一個來允許搶占Container):
minSharePreemptionTimeout
fairSharePreemptionTimeout
如果隊列在minimum share preemption timeout指定的時間內(nèi)未獲得最小的資源保障,調(diào)度器就會搶占containers。我們可以通過配置文件中的頂級元素</defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout>為所有隊列配置這個超時時間;我們還可以在元素內(nèi)配置元素來為某個隊列指定超時時間。</defaultminsharepreemptiontimeout>
與之類似,如果隊列在fair share preemption timeout指定時間內(nèi)未獲得平等的資源的一半(這個比例可以配置),調(diào)度器則會進行搶占containers。這個超時時間可以通過頂級元素<defaultfairsharepreemptiontimeout style="font-size: inherit;color: inherit;line-height: inherit;">和元素級元素分別配置所有隊列和某個隊列的超時時間。上面提到的比例可以通過<defaultfairsharepreemptionthreshold style="font-size: inherit;color: inherit;line-height: inherit;">(配置所有隊列)和(配置某個隊列)進行配置,默認是0.5。</defaultfairsharepreemptionthreshold></defaultfairsharepreemptiontimeout>
需要注意的是,所有客戶端提交任務(wù)的用戶和用戶組的對應(yīng)關(guān)系,需要維護在ResourceManager上,ResourceManager在分配資源池時候,是從ResourceManager上讀取用戶和用戶組的對應(yīng)關(guān)系的,否則就會被分配到default資源池。在日志中出現(xiàn)”UserGroupInformation: No groups available for user”類似的警告。而客戶端機器上的用戶對應(yīng)的用戶組無關(guān)緊要。
每次在ResourceManager上新增用戶或者調(diào)整資源池配額后,需要執(zhí)行下面的命令刷新使其生效.
yarn rmadmin -refreshQueues yarn rmadmin -refreshUserToGroupsMappings
動態(tài)更新只支持修改資源池配額,如果是新增或減少資源池,則需要重啟Yarn集群.
Fair Scheduer各資源池配置及使用情況,在ResourceManager的WEB監(jiān)控頁面上也可以看到: http://ResourceManagerHost:8088/cluster/scheduler
2.2 Capacity 配置
hadoop2.7默認使用的是Capacity Scheduler容量調(diào)度器
yarn-site.xml
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.capacity.CapacityScheduler</value>
</property>
Capacity 調(diào)度器允許多個組織共享整個集群,每個組織可以獲得集群的一部分計算能力。通過為每個組織分配專門的隊列,然后再為每個隊列分配一定的集群資源,這樣整個集群就可以通過設(shè)置多個隊列的方式給多個組織提供服務(wù)了。除此之外,隊列內(nèi)部又可以垂直劃分,這樣一個組織內(nèi)部的多個成員就可以共享這個隊列資源了,在一個隊列內(nèi)部,資源的調(diào)度是采用的是先進先出(FIFO)策略。
一個job可能使用不了整個隊列的資源。然而如果這個隊列中運行多個job,如果這個隊列的資源夠用,那么就分配給這些job,如果這個隊列的資源不夠用了呢?其實Capacity調(diào)度器仍可能分配額外的資源給這個隊列,這就是“彈性隊列”(queue elasticity)的概念。
在正常的操作中,Capacity調(diào)度器不會強制釋放Container,當(dāng)一個隊列資源不夠用時,這個隊列只能獲得其它隊列釋放后的Container資源。當(dāng)然,我們可以為隊列設(shè)置一個最大資源使用量,以免這個隊列過多的占用空閑資源,導(dǎo)致其它隊列無法使用這些空閑資源,這就是”彈性隊列”需要權(quán)衡的地方。
假設(shè)我們有如下層次的隊列:
root
├── prod
└── dev
├── eng
└── science
下面是一個簡單的Capacity調(diào)度器的配置文件,文件名為capacity-scheduler.xml。在這個配置中,在root隊列下面定義了兩個子隊列prod和dev,分別占40%和60%的容量。需要注意,一個隊列的配置是通過屬性yarn.sheduler.capacity..指定的,代表的是隊列的繼承樹,如root.prod隊列,一般指capacity和maximum-capacity。
<?xml version="1.0"?>
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues(/&eae)
<value>prod,dev</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.queues</tta*e>
<value>eng,science</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.prod.capacity</name>
<value>40</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.capacity</name>
<value >60</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.maximuin-capacity</name>
<value>75</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.eng.capacity</name>
<value >50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.dev.science.capacity</name>
<value >50</value>
</property>
</configuration>
我們可以看到,dev隊列又被分成了eng和science兩個相同容量的子隊列。dev的maximum-capacity屬性被設(shè)置成了75%,所以即使prod隊列完全空閑dev也不會占用全部集群資源,也就是說,prod隊列仍有25%的可用資源用來應(yīng)急。我們注意到,eng和science兩個隊列沒有設(shè)置maximum-capacity屬性,也就是說eng或science隊列中的job可能會用到整個dev隊列的所有資源(最多為集群的75%)。而類似的,prod由于沒有設(shè)置maximum-capacity屬性,它有可能會占用集群全部資源。Capacity容器除了可以配置隊列及其容量外,我們還可以配置一個用戶或應(yīng)用可以分配的最大資源數(shù)量、可以同時運行多少應(yīng)用、隊列的ACL認證等。
關(guān)于隊列的設(shè)置,這取決于我們具體的應(yīng)用。比如,在MapReduce中,我們可以通過mapreduce.job.queuename屬性指定要用的隊列。如果隊列不存在,我們在提交任務(wù)時就會收到錯誤。如果我們沒有定義任何隊列,所有的應(yīng)用將會放在一個default隊列中。
注意:對于Capacity調(diào)度器,我們的隊列名必須是隊列樹中的最后一部分,如果我們使用隊列樹則不會被識別。比如,在上面配置中,我們使用prod和eng作為隊列名是可以的,但是如果我們用root.dev.eng或者dev.eng是無效的。
2.3 FIFO Scheduler
yarn-site.xml文件
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.fifo.FifoScheduler</value>
</property>