Yarn的資源調度策略
理想情況下,我們對Yarn的資源申請應該立即得到滿足,但實際情況下整個集群的資源總量是有限的,這時就依賴資源調度器對資源進行調度了.
但在實際過程中,資源的調度策略本身就是一個難題,很難有一個完美的調度策略可以適用與所有的情況,為此Yarn提供了三種調度器讓我們自行選擇適用
FIFO調度器
這種調度會把所有資源申請放入一個隊列先進先出.這是最簡單的調度,也不需要任何配置,但這種調度器不適用共享集群環境.原因很簡單,先入的大任務,會卡死后面的資源申請.
Capacity調度器
Capacity調度說明
這種調度運行多個組織共享集群,每個組織都可以獲得集群的一部分計算能力.
通過為每一個組織都設置一個隊列(隊列樹),再為每個隊列都分配一定的集群資源,這樣集群就可以為多個組織同時提供服務了.
在每個隊列之內,資源將進行垂直划分,這樣每個組織的成員將可以共享隊列內部的資源.但在隊列內部,依然是先進先出策略.
如果某個組織的資源已經全部用完而又急需分配,Yarn可能會將其它隊列資源分配給它,這就是彈性隊列,這時需要為隊列設置一個最大資源使用量,防止搶奪太多的空閑資源
Capacity使用說明
conf/yarn-site.xml 配置啟用Capacity調度器
yarn.resourcemanager.scheduler.class 設置為 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
conf/capacity-scheduler.xml配置具體的隊列樹,一個例子如下:
<!--資源分配限制-->
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b</value>
<description>根節點下定義a,b兩個子隊列</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.queues</name>
<value>a1,a2</value>
<description>隊列a之下再定義a1,a2兩個子隊列</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.queues</name>
<value>b1</value>
<description>隊列b之下定義b1子隊列</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.capacity</name>
<value>40</value>
<description>int,定義a隊列總體使用40%的資源</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.maximum-capacity</name>
<value>60</value>
<description>int,定義a隊列最多使用60%的資源(彈性隊列情況),如果設為-1則表示禁止彈性隊列情況</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.minimum-user-limit-percent</name>
<value>25</value>
<description>int,定義a隊列中對單一用戶而言最多使用隊列25%的資源(多個用戶搶占,資源緊張發生爭用時),如果設為100則表示不禁止單個用戶使用上限</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.user-limit-factor</name>
<value>1.5</value>
<description>float,定義a隊列對單一用戶而言最多使用隊列maximum-capacity*1.5的資源(單個或少量用戶,資源大量空閑的時候)</description>
</property>
<!--任務&應用程序運行限制-->
<property>
<name>yarn.scheduler.capacity.maximum-applications</name>
<value>100</value>
<description>int,定義整個隊列樹的每個隊列同時運行或者等待的最大任務數.(硬性限制,之外的請求將直接拒絕),默認10000</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.maximum-applications</name>
<value>200</value>
<description>int,對隊列a或子隊列同時運行或者等待的最大任務數.(硬性限制,之外的請求將直接拒絕),默認10000</description>
</property>
<property>
<name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
<value>0.1</value>
<description>float,定義整個隊列樹的可用於運行的ApplicationMaster的最大百分比資源(一般用於限制應用程序的並發限制),默認0.1(10%)</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.maximum-am-resource-percent</name>
<value>0.1</value>
<description>float,對隊列a或子隊列的可用於運行的ApplicationMaster的最大百分比資源(一般用於限制應用程序的並發限制),默認0.1(10%)</description>
</property>
<!--隊列管理&權限-->
<property>
<name>yarn.scheduler.capacity.root.b.state</name>
<value>STOPPED</value>
<description>RUNNING,STOPPED 設定隊列狀態.如果隊列被設定為停止,則不能提交任何應用程序給它以及它的子隊列</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.acl_submit_applications</name>
<value>*</value>
<description>限制哪些用戶可以向隊列a提交應用程序,*表示不限</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.acl_administer_queue</name>
<value>*</value>
<description>限定哪些用戶可以管理隊列a中的應用程序</description>
</property>
<!--其它-->
<property>
<name>yarn.scheduler.capacity.resource-calculator</name>
<value>org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator</value>
<description>資源比較調度器設置.默認為DefaultResourseCalculator只用內存比較,DominantResourceCalculator多維比較</description>
</property>
<property>
<name>yarn.scheduler.capacity.node-locality-delay</name>
<value>5</value>
<description>為錯過調度機會的任務建立局部處理容器,應設置為集群節點數量,默認為40</description>
</property>
Fair調度器
Fair調度器力求讓所有用戶公平(加權公平)的獲得資源.
Fair調度器的配置文件fair-scheduler.xml文件
若沒有這個配置文件,調度器會在用戶提交第一個應用時為其自動創建一個隊列，隊列的名字就是用戶名，所有的應用都會被分配到相應的用戶隊列中
啟用公平調度器
yarn-site.xml
<property> <name>yarn.resourcemanager.scheduler.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value> </property>
yarn-site.xml公平調度配置節:
yarn.scheduler.fair.allocation.file 公平調度配置文件地址,默認為 fair-scheduler.xml
yarn.scheduler.fair.user-as-default-queue 是否使用用戶名作為默認隊列名稱,如果隊列名稱沒有指定。如果這個設置為“false”或未設置,所有工作有一個共享的默認隊列,命名為“默認”。默認值為true。如果隊列安置政策是在配置文件中,該屬性將被忽略
yarn.scheduler.fair.preemption 是否使用資源搶占,默認為false
yarn.scheduler.fair.preemption.cluster-utilization-threshold 在該閾值之后發生搶占,默認為0.8
yarn.scheduler.fair.sizebasedweight 在隊列內部分配資源時,默認采用公平輪詢的策略分配資源,該配置將改變策略為按照應用程序資源需求數目分配資源,即應用程序需求越多,分配的資源越多.默認為false
yarn.scheduler.fair.assignmultiple 是否啟動批量分配功能.當一個節點出現大量資源時,可以一次分配完成,也可以多次分配完成。默認值為false
yarn.scheduler.fair.max.assign 如果啟動批量分配功能,則指定一次分配的最大Container數量。默認為-1沒有限制
yarn.scheduler.fair.locality.threshold.node 當應用程序請求某個節點上資源時，它可以接受的可跳過的最大資源調度機會.默認情況下，該值為-1.0，表示不跳過任何調度機會
當按照分配策略，可將一個節點上的資源分配給某個應用程序時，如果該節點不是應用程序期望的節點，可選擇跳過該分配機會暫時將資源分配給其他應用程序，直到出現滿足該應用程序需的節點資源出現。
通常而言，一次心跳代表一次調度機會，而該參數則表示跳過調度機會占節點總數的比例
yarn.scheduler.fair.locality.threshold.rack 當應用程序請求某個機架上資源時，它可以接受的可跳過的最大資源調度機會。默認值為-1.0時表示沒有通過任何調度的機會
yarn.scheduler.fair.allow-undeclared-pools 禁止自動創建(提交隊列不存在)隊列。默認值為true。如果隊列安置政策是在配置文件中,該屬性將被忽略
yarn.scheduler.fair.update-interval-ms 鎖定的時間間隔調度器,重新計算需求,並檢查是否將搶占間隔時間。默認為500毫秒
yarn.scheduler.increment-allocation-mb 內存規整化單位，默認是1024，這意味着，如果一個Container請求資源是1.5GB，則將被調度器規整化為ceiling(1.5 GB / 1GB) * 1G=2GB
yarn.scheduler.increment-allocation-vcores：虛擬CPU規整化單位，默認是1，含義與內存規整化單位類似
隊列配置文件(可以在運行時完成修改最小共享，資源限制，權重，超時搶占以及隊列調度策略等。調度器會每個10-15秒重載修改后的該配置文件):
quque
minResources:最少資源保證量，設置格式為“X mb, Y vcores”
當一個隊列的最少資源保證量未滿足時，它將優先於其他同級隊列獲得資源，對於不同的調度策略（后面會詳細介紹），最少資源保證量的含義不同，
對於fair策略，則只考慮內存資源，即如果一個隊列使用的內存資源超過了它的最少資源量，則認為它已得到了滿足；對於drf策略，則考慮主資源使用的資源量，即如果一個隊列的主資源量超過它的最少資源量，則認為它已得到了滿足
maxResources:一個隊列允許的最大資源，采用“X mb, Y vcores”的形式。對於單一資源公平策略，vcores的值會被忽略。一個隊列永遠不會分配資源總量超過這個限制
maxRunningApps:最多同時運行的應用程序數目。通過限制該數目，可防止超量Map Task同時運行時產生的中間輸出結果撐爆磁盤
maxAMShare:限制隊列用於運行Application Master的資源比例。這個屬性只能用於葉子隊列。比如，如果設置為1.0f，那么在這個隊列的AMs可以占用100%的內存和CPU的公平共享。這個值為-1.0f將會禁用該特性並且amShare不會進行校驗。默認值是0.5f
weight:與其他隊列非比例的分享集群。權重默認是1，權重是2的隊列將會收到接近默認權重2倍的資源
schedulingPolicy:任一隊列都可以設置調度策略。允許的值包括“fifo”，“fair”，“drf”或者其他任何繼承.默認fair
aclSubmitApps:可以提交apps到隊列的用戶或者組的列表。要獲得更多信息可以參考下面的ACLs部分，關於列表的格式和ACLs如何發揮作用
aclAdministerApps：可以管理隊列的用戶或者組列表。當前唯一的管理動作就是殺死應用程序。要獲得更多信息可以參考下面的ACLs部分，關於列表的格式和ACLs如何發揮作用
minSharePreemptionTimeout：隊列處在最小共享之下，在嘗試搶占其他隊列的資源之前的秒數。如果不設置，隊列將會總其父隊列繼承這個值
fairSharePreemptionTimeout：隊列處在最小公平共享閾值之下，在嘗試搶占其他隊列的資源之前的秒數。如果不設置，隊列將會總其父隊列繼承這個值
fairSharePreemptionThreshold：隊列的公平共享搶占閾值。如果隊列等待fairSharePreemptionTimeout之后沒有接收到fairSharePreemptionThreshold*fairShare的資源，它被允許從其他隊列搶占資源。如果不設置，隊列將會總其父隊列繼承這個值
User
maxRunningApps:對特定用戶可以運行的apps的數量限制
userMaxAppsDefault:設置任意用戶（沒有特定限制的用戶）運行app的默認最大數量限制
defaultFairSharePreemptionThreshold:設置root隊列的公平共享搶占的默認閾值；可以被root隊列下的fairSharePreemptionThreshold 覆蓋
queueMaxAppsDefault:設置隊列的默認運行app數量限制；可以被任一隊列的maxRunningApps元素覆蓋
queueMaxAMShareDefault:設置隊列的默認AM共享資源限制；可以被任一隊列的maxAMShare 元素覆蓋
defaultQueueSchedulingPolicy:設置隊列的默認調度策略；可以在任一隊列中設置schedulingPolicy 進行覆蓋該默認值。默認值為“fair”
queuePlacementPolicy:包含一個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
一個公平調度隊列設置的例子如下:
<?xml version="1.0"?> <allocations> <queue name="sample_queue"> <minResources>10000 mb,0vcores</minResources> <!--最少資源保證量，設置格式為“X mb, Y vcores”--> <maxResources>90000 mb,0vcores</maxResources> <!--最多可以使用的資源量--> <maxRunningApps>50</maxRunningApps> <!--最多同時運行的應用程序數目。通過限制該數目，可防止超量Map Task同時運行時產生的中間輸出結果撐爆磁盤--> <maxAMShare>0.1</maxAMShare> <weight>2.0</weight> <schedulingPolicy>fair</schedulingPolicy> <!--隊列采用的調度模式，可以是fifo、fair或者drf--> <queue name="sample_sub_queue"> <!--定義子隊列--> <aclSubmitApps>charlie</aclSubmitApps> <minResources>5000 mb,0vcores</minResources> </queue> </queue> <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault> <!—- Queue 'secondary_group_queueue' 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>
公平調度與計算能力調度的區別:
公平調度的單位本質是pool,而計算能力調度的單位本質是queue.由此帶來公平調度和計算能力調度在處理調度,資源爭奪等等方面的不同.
因為計算能力調度是queue,所以其內部只能是FIFO的方式調度,雖然可以設置優先級,但是也不可以發生搶占,所以爭奪形式為彈性隊列暫時借用其它隊列資源(也必須始終保持FIFO).
而公平調度的本質是pool(通常就是用戶),所以其調度方式既可以是權重也可以是FIFO.而在得不到最小資源的情況下可以殺死其它並行的任務來搶奪資源(此時其它任務不是失敗而是阻塞等待重啟)
參考: http://han-zw.iteye.com/blog/2322189