<samp id="wckti"></samp>
<var id="wckti"></var>
  • <rt id="wckti"></rt>

    <rt id="wckti"><bdo id="wckti"></bdo></rt><strong id="wckti"><noscript id="wckti"></noscript></strong>
  • 當前位置:聯(lián)升科技 > 技術(shù)資訊 > 開(kāi)發(fā)技術(shù) >

    Yarn調度器(Scheduler)詳解

    2021-01-29    作者: 老董    來(lái)源:Java大數據與數據倉庫    閱讀: 次

    本文轉載自微信公眾號「Java大數據與數據倉庫」,作者老董。轉載本文請聯(lián)系Java大數據與數據倉庫公眾號。 
    目錄
    1. Yarn調度器介紹
    FIFO(先進(jìn)先出調度器)
    Capacity(容量調度器)
    Fair(公平調度器)
    Fair與Capacity區別
    2.Yarn調度器配置
    Fair
    Capacity配置(默認配置)
    FIFO
    理想情況下,我們應用對Yarn資源的請求應該立刻得到滿(mǎn)足,但現實(shí)情況資源往往是有限的,特別是在一個(gè)很繁忙的集群,一個(gè)應用資源的請求經(jīng)常需要等待一段時(shí)間才能的到相應的資源。在Yarn中,負責給應用分配資源的就是Scheduler。其實(shí)調度本身就是一個(gè)難題,很難找到一個(gè)完美的策略可以解決所有的應用場(chǎng)景。為此,Yarn提供了多種調度器和可配置的策略供我們選擇。YARN架構如下:

    ResourceManager(RM):負責對各NM上的資源進(jìn)行統一管理和調度,將AM分配空閑的Container運行并監控其運行狀態(tài)。對AM申請的資源請求分配相應的空閑Container。主要由兩個(gè)組件構成:調度器(Scheduler)和應用程序管理器(Applications Manager)。
    調度器(Scheduler):調度器根據容量、隊列等限制條件(如每個(gè)隊列分配一定的資源,最多執行一定數量的作業(yè)等),將系統中的資源分配給各個(gè)正在運行的應用程序。調度器僅根據各個(gè)應用程序的資源需求進(jìn)行資源分配,而資源分配單位是Container,從而限定每個(gè)任務(wù)使用的資源量。Scheduler不負責監控或者跟蹤應用程序的狀態(tài),也不負責任務(wù)因為各種原因而需要的重啟(由ApplicationMaster負責)??傊?,調度器根據應用程序的資源要求,以及集群機器的資源情況,為用程序分配封裝在Container中的資源。調度器是可插拔的,例如CapacityScheduler、FairScheduler。(PS:在實(shí)際應用中,只需要簡(jiǎn)單配置即可)
    應用程序管理器(Application Manager):應用程序管理器負責管理整個(gè)系統中所有應用程序,包括應用程序提交、與調度器協(xié)商資源以啟動(dòng)AM、監控AM運行狀態(tài)并在失敗時(shí)重新啟動(dòng)等,跟蹤分給的Container的進(jìn)度、狀態(tài)也是其職責。ApplicationMaster是應用框架,它負責向
    ResourceManager協(xié)調資源,并且與NodeManager協(xié)同工作完成Task的執行和監控。MapReduce就是原生支持的一種框架,可以在YARN上運行Mapreduce作業(yè)。有很多分布式應用都開(kāi)發(fā)了對應的應用程序框架,用于在YARN上運行任務(wù),例如Spark,Storm等。如果需要,我們也可以自己寫(xiě)一個(gè)符合規范的YARN application。
    NodeManager(NM):NM是每個(gè)節點(diǎn)上的資源和任務(wù)管理器。它會(huì )定時(shí)地向RM匯報本節點(diǎn)上的資源使用情況和各個(gè)Container的運行狀態(tài);同時(shí)會(huì )接收并處理來(lái)自AM的Container 啟動(dòng)/停止等請求。ApplicationMaster(AM):用戶(hù)提交的應用程序均包含一個(gè)AM,負責應用的監控,跟蹤應用執行狀態(tài),重啟失敗任務(wù)等。
    Container:是YARN中的資源抽象,它封裝了某個(gè)節點(diǎn)上的多維度資源,如內存、CPU、磁盤(pán)、網(wǎng)絡(luò )等,當AM向RM申請資源時(shí),RM為AM返回的資源便是用Container 表示的。YARN會(huì )為每個(gè)任務(wù)分配一個(gè)Container且該任務(wù)只能使用該Container中描述的資源。
    1. Yarn調度器介紹
    1.1. FIFO (先進(jìn)先出調度器)
    FIFO Scheduler把應用按提交的順序排成一個(gè)隊列,這是一個(gè)先進(jìn)先出隊列,在進(jìn)行資源分配的時(shí)候,先給隊列中最頭上的應用進(jìn)行分配資源,待最頭上的應用需求滿(mǎn)足后再給下一個(gè)分配,以此類(lèi)推。FIFO Scheduler是最簡(jiǎn)單也是最容易理解的調度器,也不需要任何配置,但它并不適用于共享集群。大的應用可能會(huì )占用所有集群資源,這就導致其它應用被阻塞。在共享集群中,更適合采用Capacity Scheduler或Fair Scheduler,這兩個(gè)調度器都允許大任務(wù)和小任務(wù)在提交的同時(shí)獲得一定的系統資源。下面“Yarn調度器對比圖”展示了這幾個(gè)調度器的區別,從圖中可以看出,在FIFO 調度器中,小任務(wù)會(huì )被大任務(wù)阻塞。

    1.2. Capacity (容量調度器)
    yarn-site.xml中默認配置的資源調度器。而對于Capacity調度器,有一個(gè)專(zhuān)門(mén)的隊列用來(lái)運行小任務(wù),但是為小任務(wù)專(zhuān)門(mén)設置一個(gè)隊列會(huì )預先占用一定的集群資源,這就導致大任務(wù)的執行時(shí)間會(huì )落后于使用FIFO調度器時(shí)的時(shí)間。用這個(gè)資源調度器,就可以配置yarn資源隊列,這個(gè)后面后介紹用到。

    1.3. Fair (公平調度器)
    Fair調度器的設計目標是為所有的應用分配公平的資源(對公平的定義可以通過(guò)參數來(lái)設置)。在上面的“Yarn調度器對比圖”展示了一個(gè)隊列中兩個(gè)應用的公平調度;當然,公平調度在也可以在多個(gè)隊列間工作。舉個(gè)例子,假設有兩個(gè)用戶(hù)A和B,他們分別擁有一個(gè)隊列。當A啟動(dòng)一個(gè)job而B(niǎo)沒(méi)有任務(wù)時(shí),A會(huì )獲得全部集群資源;當B啟動(dòng)一個(gè)job后,A的job會(huì )繼續運行,不過(guò)一會(huì )兒之后兩個(gè)任務(wù)會(huì )各自獲得一半的集群資源。如果此時(shí)B再啟動(dòng)第二個(gè)job并且其它job還在運行,則它將會(huì )和B的第一個(gè)job共享B這個(gè)隊列的資源,也就是B的兩個(gè)job會(huì )用于四分之一的集群資源,而A的job仍然用于集群一半的資源,結果就是資源最終在兩個(gè)用戶(hù)之間平等的共享。在Fair調度器中,我們不需要預先占用一定的系統資源,Fair調度器會(huì )為所有運行的job動(dòng)態(tài)的調整系統資源。當第一個(gè)大job提交時(shí),只有這一個(gè)job在運行,此時(shí)它獲得了所有集群資源;當第二個(gè)小任務(wù)提交后,Fair調度器會(huì )分配一半資源給這個(gè)小任務(wù),讓這兩個(gè)任務(wù)公平的共享集群資源。
    a) 公平調度器,就是能夠共享整個(gè)集群的資源
    b) 不用預先占用資源,每一個(gè)作業(yè)都是共享的
    c) 每當提交一個(gè)作業(yè)的時(shí)候,就會(huì )占用整個(gè)資源。如果再提交一個(gè)作業(yè),那么第一個(gè)作業(yè)就會(huì )分給第二個(gè)作業(yè)一部分資源,第一個(gè)作業(yè)也就釋放一部分資源。再提交其他的作業(yè)時(shí),也同理。。。。也就是說(shuō)每一個(gè)作業(yè)進(jìn)來(lái),都有機會(huì )獲取資源。

    1.4. Fair Scheduler與Capacity Scheduler區別
    資源公平共享:在每個(gè)隊列中,Fair Scheduler可選擇按照FIFO、Fair或DRF策略為應用程序分配資源。Fair策略即平均分配,默認情況下,每個(gè)隊列采用該方式分配資源
    支持資源搶占:當某個(gè)隊列中有剩余資源時(shí),調度器會(huì )將這些資源共享給其他隊列,而當該隊列中有新的應用程序提交時(shí),調度器要為它回收資源。為了盡可能降低不必要的計算浪費,調度器采用了先等待再強制回收的策略,即如果等待一段時(shí)間后尚有未歸還的資源,則會(huì )進(jìn)行資源搶占;從那些超額使用資源的隊列中殺死一部分任務(wù),進(jìn)而釋放資源
    負載均衡:Fair Scheduler提供了一個(gè)基于任務(wù)數的負載均衡機制,該機制盡可能將系統中的任務(wù)均勻分配到各個(gè)節點(diǎn)上。此外,用戶(hù)也可以根據自己的需求設計負載均衡機制
    調度策略靈活配置:Fiar Scheduler允許管理員為每個(gè)隊列單獨設置調度策略(當前支持FIFO、Fair或DRF三種)
    提高小應用程序響應時(shí)間:由于采用了最大最小公平算法,小作業(yè)可以快速獲取資源并運行完成
    2.Yarn調度器配置
    yarn資源調度器是在yarn-site.xml中配置。
    2.1. Fair Scheduler
    Fair Scheduler的配置選項包括兩部分:
    一部分在yarn-site.xml中,主要用于配置調度器級別的參數
    一部分在一個(gè)自定義配置文件(默認是fair-scheduler.xml)中,主要用于配置各個(gè)隊列的資源量、權重等信息。
    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使用的調度器插件類(lèi)名;Fair Scheduler對應的是: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>開(kāi)啟資源搶占,default is True</description> 
    </property> 
    <property> 
        <name>yarn.scheduler.fair.user-as-default-queue</name> 
        <value>true</value> 
        <description>設置成true,當任務(wù)中未指定資源池的時(shí)候,將以用戶(hù)名作為資源池名。這個(gè)配置就實(shí)現了根據用戶(hù)名自動(dòng)分配資源池。default is True</description> 
    </property> 
    <property> 
        <name>yarn.scheduler.fair.allow-undeclared-pools</name> 
        <value>false</value> 
        <description>是否允許創(chuàng )建未定義的資源池。如果設置成true,yarn將會(huì )自動(dòng)創(chuàng )建任務(wù)中指定的未定義過(guò)的資源池。設置成false之后,任務(wù)中指定的未定義的資源池將無(wú)效,該任務(wù)會(huì )被分配到default資源池中。,default is True</description> 
    </property> 
    <!– scheduler end –> 
    2.1.2 fair-scheduler.xml
    假設在生產(chǎn)環(huán)境Yarn中,總共有四類(lèi)用戶(hù)需要使用集群,production、spark、default、streaming。為了使其提交的任務(wù)不受影響,我們在Yarn上規劃配置了四個(gè)資源池,分別為production,spark,default,streaming。并根據實(shí)際業(yè)務(wù)情況,為每個(gè)資源池分配了相應的資源及優(yōu)先級等,default用于開(kāi)發(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"> 
            <!-- 對于特定用戶(hù)的配置:production最多可以同時(shí)運行的任務(wù) --> 
            <maxRunningApps>100</maxRunningApps> 
        </user> 
        <user name="default"> 
            <!-- 對于默認用戶(hù)配置最多可以同時(shí)運行的任務(wù) --> 
            <maxRunningApps>10</maxRunningApps> 
        </user> 
     
        <!-- users max running apps --> 
        <userMaxAppsDefault>50</userMaxAppsDefault> 
        <!--默認的用戶(hù)最多可以同時(shí)運行的任務(wù) --> 
        <queuePlacementPolicy> 
            <rule name="specified"/>  
            <rule name="primaryGroup" create="false" /> 
            <rule name="secondaryGroupExistingQueue" create="false" /> 
            <rule name="default" queue="default"/> 
        </queuePlacementPolicy> 
    </allocations> 
    參數介紹:
    minResources:最少資源保證量,設置格式為“X mb, Y vcores”,當一個(gè)隊列的最少資源保證量未滿(mǎn)足時(shí),它將優(yōu)先于其他同級隊列獲得資源,對于不同的調度策略(后面會(huì )詳細介紹),最少資源保證量的含義不同,對于fair策略,則只考慮內存資源,即如果一個(gè)隊列使用的內存資源超過(guò)了它的最少資源量,則認為它已得到了滿(mǎn)足;對于drf策略,則考慮主資源使用的資源量,即如果一個(gè)隊列的主資源量超過(guò)它的最少資源量,則認為它已得到了滿(mǎn)足。
    maxResources:最多可以使用的資源量,fair scheduler會(huì )保證每個(gè)隊列使用的資源量不會(huì )超過(guò)該隊列的最多可使用資源量。
    maxRunningApps:最多同時(shí)運行的應用程序數目。通過(guò)限制該數目,可防止超量Map Task同時(shí)運行時(shí)產(chǎn)生的中間輸出結果撐爆磁盤(pán)。
    weight:資源池權重,主要用在資源共享之時(shí),weight越大,拿到的資源越多。比如一個(gè)pool中有20GB內存用不了,這時(shí)候可以共享給其他pool,其他每個(gè)pool拿多少,就是由權重決定的
    aclSubmitApps:可向隊列中提交應用程序的Linux用戶(hù)或用戶(hù)組列表,默認情況下為“*”,表示任何用戶(hù)均可以向該隊列提交應用程序。需要注意的是,該屬性具有繼承性,即子隊列的列表會(huì )繼承父隊列的列表。配置該屬性時(shí),用戶(hù)之間或用戶(hù)組之間用“,”分割,用戶(hù)和用戶(hù)組之間用空格分割,比如“user1, user2 group1,group2”。
    aclAdministerApps:允許管理任務(wù)的用戶(hù)名和組;一個(gè)隊列的管理員可管理該隊列中的資源和應用程序,比如可殺死任意應用程序。
    minSharePreemptionTimeout :最小共享量搶占時(shí)間。如果一個(gè)資源池在該時(shí)間內使用的資源量一直低于最小資源量,則開(kāi)始搶占資源。
    schedulingMode/schedulingPolicy:隊列采用的調度模式,可以是fifo、fair或者drf。
    管理員也可為單個(gè)用戶(hù)添加maxRunningJobs屬性限制其最多同時(shí)運行的應用程序數目。此外,管理員也可通過(guò)以下參數設置以上屬性的默認值:
    userMaxJobsDefault:用戶(hù)的maxRunningJobs屬性的默認值。
    defaultMinSharePreemptionTimeout :隊列的minSharePreemptionTimeout屬性的默認值。
    defaultPoolSchedulingMode:隊列的schedulingMode屬性的默認值。
    fairSharePreemptionTimeout:公平共享量搶占時(shí)間。如果一個(gè)資源池在該時(shí)間內使用資源量一直低于公平共享量的一半,則開(kāi)始搶占資源。
    這樣,每個(gè)用戶(hù)組下的用戶(hù)提交任務(wù)時(shí)候,會(huì )到相應的資源池中,而不影響其他業(yè)務(wù)。隊列的層次是通過(guò)嵌套
    元素實(shí)現的。所有的隊列都是root隊列的孩子,即使沒(méi)有配到元素里。Fair調度器中的隊列有一個(gè)權重屬性(這個(gè)權重就是對公平的定義),并把這個(gè)屬性作為公平調度的依據。在這個(gè)例子中,當調度器分配集群7.5,1,1,0.5資源給production,spark,streaming,default時(shí)便視作公平,這里的權重并不是百分比。注意,對于在沒(méi)有配置文件時(shí)按用戶(hù)自動(dòng)創(chuàng )建的隊列,它們仍有權重并且權重值為1。每個(gè)隊列內部仍可以有不同的調度策略。隊列的默認調度策略可以通過(guò)頂級元素進(jìn)行配置,如果沒(méi)有配置,默認采用公平調度。盡管是Fair調度器,其仍支持在隊列級別進(jìn)行FIFO調度。每個(gè)隊列的調度策略可以被其內部的元素覆蓋,在上面這個(gè)例子中,default隊列就被指定采用fifo進(jìn)行調度,所以,對于提交到default隊列的任務(wù)就可以按照FIFO規則順序的執行了。需要注意,spark,production,streaming,default之間的調度仍然是公平調度。每個(gè)隊列可配置最大、最小資源占用數和最大可運行的應用的數量。
    Fair調度器采用了一套基于規則的系統來(lái)確定應用應該放到哪個(gè)隊列。在上面的例子中,元素定義了一個(gè)規則列表,其中的每個(gè)規則會(huì )被逐個(gè)嘗試直到匹配成功。例如,上例第一個(gè)規則specified,則會(huì )把應用放到它指定的隊列中,若這個(gè)應用沒(méi)有指定隊列名或隊列名不存在,則說(shuō)明不匹配這個(gè)規則,然后嘗試下一個(gè)規則。primaryGroup規則會(huì )嘗試把應用放在以用戶(hù)所在的Unix組名命名的隊列中,如果沒(méi)有這個(gè)隊列,不創(chuàng )建隊列轉而嘗試下一個(gè)規則。當前面所有規則不滿(mǎn)足時(shí),則觸發(fā)default規則,把應用放在default隊列中。
    當然,我們可以不配置queuePlacementPolicy規則,調度器則默認采用如下規則:
    <queuePlacementPolicy> 
          <rule name="specified" /> 
          <rule name="user" /> 
    </queuePlacementPolicy> 
    上面規則意思是除非隊列被準確的定義,否則會(huì )以用戶(hù)名為隊列名創(chuàng )建隊列。還有一個(gè)簡(jiǎn)單的配置策略可以使得所有的應用放入同一個(gè)隊列(default),這樣就可以讓所有應用之間平等共享集群而不是在用戶(hù)之間。這個(gè)配置的定義如下:
    <queuePlacementPolicy> 
         <rule name="default" /> 
    </queuePlacementPolicy> 
    實(shí)現上面功能我們還可以不使用配置文件,直接設置yarn.scheduler.fair.user-as-default-queue=false,這樣應用便會(huì )被放入default 隊列,而不是各個(gè)用戶(hù)名隊列。另外,我們還可以設置yarn.scheduler.fair.allow-undeclared-pools=false,這樣用戶(hù)就無(wú)法創(chuàng )建隊列了。
    當一個(gè)job提交到一個(gè)繁忙集群中的空隊列時(shí),job并不會(huì )馬上執行,而是阻塞直到正在運行的job釋放系統資源。為了使提交job的執行時(shí)間更具預測性(可以設置等待的超時(shí)時(shí)間),Fair調度器支持搶占。搶占就是允許調度器殺掉占用超過(guò)其應占份額資源隊列的containers,這些containers資源便可被分配到應該享有這些份額資源的隊列中。需要注意搶占會(huì )降低集群的執行效率,因為被終止的containers需要被重新執行??梢酝ㄟ^(guò)設置一個(gè)全局的參數yarn.scheduler.fair.preemption=true來(lái)啟用搶占功能。此外,還有兩個(gè)參數用來(lái)控制搶占的過(guò)期時(shí)間(這兩個(gè)參數默認沒(méi)有配置,需要至少配置一個(gè)來(lái)允許搶占Container):
    minSharePreemptionTimeout 
    fairSharePreemptionTimeout 
    如果隊列在minimum share preemption timeout指定的時(shí)間內未獲得最小的資源保障,調度器就會(huì )搶占containers。我們可以通過(guò)配置文件中的頂級元素</defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout></defaultminsharepreemptiontimeout>為所有隊列配置這個(gè)超時(shí)時(shí)間;我們還可以在元素內配置元素來(lái)為某個(gè)隊列指定超時(shí)時(shí)間。</defaultminsharepreemptiontimeout>
    與之類(lèi)似,如果隊列在fair share preemption timeout指定時(shí)間內未獲得平等的資源的一半(這個(gè)比例可以配置),調度器則會(huì )進(jìn)行搶占containers。這個(gè)超時(shí)時(shí)間可以通過(guò)頂級元素<defaultfairsharepreemptiontimeout style="font-size: inherit;color: inherit;line-height: inherit;">和元素級元素分別配置所有隊列和某個(gè)隊列的超時(shí)時(shí)間。上面提到的比例可以通過(guò)<defaultfairsharepreemptionthreshold style="font-size: inherit;color: inherit;line-height: inherit;">(配置所有隊列)和(配置某個(gè)隊列)進(jìn)行配置,默認是0.5。</defaultfairsharepreemptionthreshold></defaultfairsharepreemptiontimeout>
    需要注意的是,所有客戶(hù)端提交任務(wù)的用戶(hù)和用戶(hù)組的對應關(guān)系,需要維護在ResourceManager上,ResourceManager在分配資源池時(shí)候,是從ResourceManager上讀取用戶(hù)和用戶(hù)組的對應關(guān)系的,否則就會(huì )被分配到default資源池。在日志中出現”UserGroupInformation: No groups available for user”類(lèi)似的警告。而客戶(hù)端機器上的用戶(hù)對應的用戶(hù)組無(wú)關(guān)緊要。
    每次在ResourceManager上新增用戶(hù)或者調整資源池配額后,需要執行下面的命令刷新使其生效.
    yarn rmadmin -refreshQueues yarn rmadmin -refreshUserToGroupsMappings
    動(dòng)態(tài)更新只支持修改資源池配額,如果是新增或減少資源池,則需要重啟Yarn集群.
    Fair Scheduer各資源池配置及使用情況,在ResourceManager的WEB監控頁(yè)面上也可以看到: http://ResourceManagerHost:8088/cluster/scheduler

    2.2 Capacity 配置
    hadoop2.7默認使用的是Capacity Scheduler容量調度器
    yarn-site.xml
    <property> 
      <name>yarn.resourcemanager.scheduler.class</name> 
      <value>org.apache.hadoop.yarn.server.resourcemanager.capacity.CapacityScheduler</value> 
    </property> 
    Capacity 調度器允許多個(gè)組織共享整個(gè)集群,每個(gè)組織可以獲得集群的一部分計算能力。通過(guò)為每個(gè)組織分配專(zhuān)門(mén)的隊列,然后再為每個(gè)隊列分配一定的集群資源,這樣整個(gè)集群就可以通過(guò)設置多個(gè)隊列的方式給多個(gè)組織提供服務(wù)了。除此之外,隊列內部又可以垂直劃分,這樣一個(gè)組織內部的多個(gè)成員就可以共享這個(gè)隊列資源了,在一個(gè)隊列內部,資源的調度是采用的是先進(jìn)先出(FIFO)策略。
    一個(gè)job可能使用不了整個(gè)隊列的資源。然而如果這個(gè)隊列中運行多個(gè)job,如果這個(gè)隊列的資源夠用,那么就分配給這些job,如果這個(gè)隊列的資源不夠用了呢?其實(shí)Capacity調度器仍可能分配額外的資源給這個(gè)隊列,這就是“彈性隊列”(queue elasticity)的概念。
    在正常的操作中,Capacity調度器不會(huì )強制釋放Container,當一個(gè)隊列資源不夠用時(shí),這個(gè)隊列只能獲得其它隊列釋放后的Container資源。當然,我們可以為隊列設置一個(gè)最大資源使用量,以免這個(gè)隊列過(guò)多的占用空閑資源,導致其它隊列無(wú)法使用這些空閑資源,這就是”彈性隊列”需要權衡的地方。
    假設我們有如下層次的隊列:
    root 
    ├── prod 
    └── dev 
        ├── eng 
        └── science 
    下面是一個(gè)簡(jiǎn)單的Capacity調度器的配置文件,文件名為capacity-scheduler.xml。在這個(gè)配置中,在root隊列下面定義了兩個(gè)子隊列prod和dev,分別占40%和60%的容量。需要注意,一個(gè)隊列的配置是通過(guò)屬性yarn.sheduler.capacity..指定的,代表的是隊列的繼承樹(shù),如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兩個(gè)相同容量的子隊列。dev的maximum-capacity屬性被設置成了75%,所以即使prod隊列完全空閑dev也不會(huì )占用全部集群資源,也就是說(shuō),prod隊列仍有25%的可用資源用來(lái)應急。我們注意到,eng和science兩個(gè)隊列沒(méi)有設置maximum-capacity屬性,也就是說(shuō)eng或science隊列中的job可能會(huì )用到整個(gè)dev隊列的所有資源(最多為集群的75%)。而類(lèi)似的,prod由于沒(méi)有設置maximum-capacity屬性,它有可能會(huì )占用集群全部資源。Capacity容器除了可以配置隊列及其容量外,我們還可以配置一個(gè)用戶(hù)或應用可以分配的最大資源數量、可以同時(shí)運行多少應用、隊列的ACL認證等。
    關(guān)于隊列的設置,這取決于我們具體的應用。比如,在MapReduce中,我們可以通過(guò)mapreduce.job.queuename屬性指定要用的隊列。如果隊列不存在,我們在提交任務(wù)時(shí)就會(huì )收到錯誤。如果我們沒(méi)有定義任何隊列,所有的應用將會(huì )放在一個(gè)default隊列中。
    注意:對于Capacity調度器,我們的隊列名必須是隊列樹(shù)中的最后一部分,如果我們使用隊列樹(shù)則不會(huì )被識別。比如,在上面配置中,我們使用prod和eng作為隊列名是可以的,但是如果我們用root.dev.eng或者dev.eng是無(wú)效的。
    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> 


    相關(guān)文章

    我們很樂(lè )意傾聽(tīng)您的聲音!
    即刻與我們取得聯(lián)絡(luò )
    成為日后肩并肩合作的伙伴。

    行業(yè)資訊

    聯(lián)系我們

    13387904606

    地址:新余市仙女湖區仙女湖大道萬(wàn)商紅A2棟

    手機:13755589003
    QQ:122322500
    微信號:13755589003

    江西新余網(wǎng)站設計_小程序制作_OA系統開(kāi)發(fā)_企業(yè)ERP管理系統_app開(kāi)發(fā)-新余聯(lián)升網(wǎng)絡(luò )科技有限公司 贛ICP備19013599號-1   贛公網(wǎng)安備 36050202000267號   

    微信二維碼
    五月天婷婷在线观看历史|国产欧美日韩免费一区二区|亚洲成a∨人片在无码|欧美日韩不卡一区二区三区中文字|每日更新国产精品视频|成年人在线观看视频免费|亚洲A片一区二区三区在线观看

    
    

    <samp id="wckti"></samp>
    <var id="wckti"></var>
  • <rt id="wckti"></rt>

    <rt id="wckti"><bdo id="wckti"></bdo></rt><strong id="wckti"><noscript id="wckti"></noscript></strong>