【Ambari】yarn資源調度之CapacityScheduler

本文轉載自查看原文 2021-06-30 23:25 224 hadoop/ yarn

【Ambari】yarn資源調度之CapacityScheduler

- CapacityScheduler

CapacityScheduler

內容來自HDP3.1.4

1 CapacityScheduler介紹

可以在用戶和用戶組間使用CapacityScheduler調度策略共享集群資源。
在yarn中最小的資源調度單元就是queue。
在CapacityScheduler下每一個隊列如下屬性：

A short queue name. 短隊列名稱
A full queue path name. 全路徑隊列名稱
A list of associated child-queues and applications.
The guaranteed capacity of the queue. 隊列的保證資源
The maximum capacity of the queue. 隊列的最大資源
A list of active users and their corresponding resource allocation limits.
The state of the queue. 隊列的狀態
Access control lists (ACLs) governing access to the queue.

2 啟用CapacityScheduler

設置ResourceManager的調度算法為CapacityScheduler

1 $ vi /etc/hadoop/conf/yarn-site.xml
2 <property>
3  <name>yarn.resourcemanager.scheduler.class</name>
4  <value>
5 org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
6  </value>
7 </property>

3 設置隊列

3.1 隊列特性

分層隊列特性，有兩種類型隊列：父隊列和葉隊列。

父隊列支持跨組織和子組織管理資源。它們可以包含更多的父隊列或葉隊列。他們自己不直接接受任何提交的申請。
葉隊列是位於父隊列下並接受應用程序的隊列。葉隊列沒有任何子隊列，因此沒有以“.queues”結尾的任何配置屬性。
有一個不屬於任何組織的頂級父root隊列，而是表示集群本身。
通過使用父隊列和葉隊列，管理員可以為各個組織和子組織指定容量分配。

3.2 隊列間調度

分層隊列先確保每個組織隊列的guranteed資源，如果有剩余資源先在組織的子隊列之間共享，再在屬於其它組織的隊列共享資源。
root隊列了解如何在第一級父隊列之間分配集群容量，並在其每個子隊列上調度。
每個父隊列都將其容量約束應用於其所有子隊列。(我的理解父隊列容量是所有子隊列的容量的和)
葉隊列保存active應用程序（可能來自多個用戶）的列表，並以FIFO（先進先出）的方式調度資源，同時遵守為單個用戶指定的容量限制。

3.3 ACLs控制隊列權限

應用程序只能提交到葉隊列級別，但對父隊列設置的ACL限制將應用於其所有子隊列。
啟用acl，需要/etc/hadoop/conf/yarn-site.xml中yarn.acl.enable=true默認為false。

acl是通過設置/etc/haoop/conf/capacity-scheduler.xml，格式"user1,user2 group1,group2",逗號分隔的user列表，一個空格，然后是逗號分隔的group列表。

1   <property>
2 <name>yarn.scheduler.capacity.root.default.acl_submit_applications</name>
3     <value>*</value>
4     <description>
5       The ACL of who can submit jobs to the default queue.
6     </description>
7   </property>

root隊列的acl_submit_applications默認值是yarn,也就是只有yarn用戶可向該隊列提交應用。
acl_submit_applications的值也可以設為"*"，所有用戶及用戶組都可以向該隊列提交應用，或者設為空格" "，禁止向該隊列提交。
如前所述，父隊列上的ACL設置將應用於其所有子隊列。因此，如果父隊列使用“*”（星號）值（或未指定）允許訪問所有用戶和組，則其子隊列不能限制訪問。類似地，在限制對子隊列的訪問之前，必須首先將父隊列設置為“”（空格字符）以阻止對所有用戶和組的訪問。
如下：如果想對子隊列support進行限制，必須先將父隊列設為空格

1 <property>
2  <name>yarn.scheduler.capacity.root.acl_submit_applications</name>
3  <value> </value>
4 </property>
5 
6 <property>
7  <name>yarn.scheduler.capacity.root.support.acl_submit_applications</name>
8  <value>sherlock,pacioli cfo-group</value>
9 </property>

可以使用單獨的ACL來控制各級隊列的管理administration。隊列administrators可以提交應用到隊列，終止隊列中的應用，並獲取隊列中有關任何應用程序的信息（而普通用戶不能查看其他用戶應用程序的所有詳細信息）。
管理員acl是使用acl_administrate_queue屬性配置的。如果未指定，則此屬性的ACL將從父隊列繼承。例如，以下屬性將root acl_administrate_queue值設置為“”（空格字符）以阻止對所有用戶和組的訪問，並將其子“support”隊列的管理員訪問權限授予用戶“sherlock”和“pacioli”以及“cfo-group”組的成員：

1 <property>
2  <name>yarn.scheduler.capacity.root.acl_administer_queue</name>
3  <value> </value>
4 </property>
5 
6 <property>
7  <name>yarn.scheduler.capacity.root.support.acl_administer_queue</name>
8  <value>sherlock,pacioli cfo-group</value>
9 </property>

4 定義隊列映射策略Mapping Policies

管理員可以指定默認映射策略，即用戶提交的應用程序自動提交到哪個隊列。
如果使用默認映射策略,用戶提交應用時可不指定隊列。
使用多個隊列映射的時候用逗號分隔，調度器按從左到右順序處理映射，以確定先使用哪一個。

隊列映射定義在capacity-scheduler.xml中：

 1   <property>
 2     <name>yarn.scheduler.capacity.queue-mappings</name>
 3     <value></value>
 4     <description>
 5       A list of mappings that will be used to assign jobs to queues
 6       The syntax for this list is [u|g]:[name]:[queue_name][,next mapping]*
 7       Typically this list will be used to map users to queues,
 8       for example, u:%user:%user maps all users to queues with the same name
 9       as the user.
10       可以為用戶（使用“u”）或一組用戶（使用“g”）定義隊列映射分配。
11     </description>
12   </property>

4.1 為用戶和組配置到特定隊列的隊列映射

1 u:user1:queueA        用戶user1默認提交到隊列queueA
2 g:group1:queueB        組group1默認提交到隊列queueB
3 
4 <property>
5   <name>yarn.scheduler.capacity.queue-mappings</name>
6   <value>u:maria:engineering,g:webadmins:weblog</value>
7 </property>
8 用戶meria提交的應用優先提交到隊列engineering。即使meria屬於組webadmins也優先提交到engineering

4.2 為用戶和組配置到同名隊列的隊列映射

1 u:%user:%primary_group        指定用戶將所有應用程序提交到與所在組同名的隊列
2 u:%user:%user                 指定用戶提交應用到自己同名隊列

假設用兩個組，marketing和engineering：
marketing: angela rahul dmitry
engineering: maria greg

1 <property> 
2   <name>yarn.scheduler.capacity.queue-mappings</name>
3   <value>u:%user:%primary_group</value> 
4 </property>

那么marketing組下成員Angela/rahul/dmitry提交的應用到marketing隊列。同理，engineering組下成員maria/greg提交的應用到marketing隊列。

4.3 啟用默認隊列映射的重寫

capacity-scheduler.xml中默認是false不允許重寫的,如果啟用改為true

 1 <property>
 2     <name>yarn.scheduler.capacity.queue-mappings-override.enable</name>
 3     <value>false</value>
 4     <description>
 5       If a queue mapping is present and override is set to true, it will override the queue value specified
 6       by the user. This can be used by administrators to place jobs in queues
 7       that are different than the one specified by the user.
 8       The default is false - user can specify to a non-default queue.
 9     </description>
10 </property>

5使用隊列管理群集資源

使用隊列來管理集群資源，以平衡來自不同用戶的多個應用程序的資源需求。
由於集群總容量可能會有所不同，因此資源配置值可使用百分比表示。
在capacity-scheduler.xml配置
如下：6:1:3的比例分配集群資源，engineering：60%，support：10%，30%

1 Property: yarn.scheduler.capacity.root.engineering.capacity
2 Value: 60
3 
4 Property: yarn.scheduler.capacity.root.support.capacity
5 Value: 10
6 
7 Property: yarn.scheduler.capacity.root.marketing.capacity
8 Value: 30

如果希望指定為每個隊列指定資源絕對值，可如下設置：

1 Property: yarn.scheduler.capacity.root.engineering.capacity
2 Value: [memory=10240,vcores=12,yarn.io/gpu=4]
3 
4 Property: yarn.scheduler.capacity.root.support.capacity
5 Value: [memory=10240,vcores=12,yarn.io/gpu=4]
6 
7 Property: yarn.scheduler.capacity.root.marketing.capacity
8 Value: [memory=10240,vcores=12,yarn.io/gpu=4]

如果不提供內存或vcore值，則使用父隊列的資源值。

如果想實現資源可彈：
將maximum capacity指定為浮點百分比值。必須將maximum capacity設置為高於或等於每個隊列的absolute capacity。該值設置為-1，將maximum capacity設置為100%。在下面的示例中，engineering隊列的最大容量設置為70%。

1 Property: yarn.scheduler.capacity.root.engineering.maximum-capacity
2 Value: 70

6 設置隊列優先級

對於長時間運行的應用程序和需要大容器(container)的應用程序，必須啟用搶占(preemption)以正確應用YARN隊列優先級。
即使啟用了搶占功能，在某些用例中，如果不設置優先級，應用程序可能無法訪問群集資源：

Long-running 長時間運行的應用程序–如果不設置優先級，則資源容量不足且資源使用率相對較低的隊列中的長時間運行的應用程序可能無法釋放群集資源，直到它們完成運行。
需要大型容器的應用程序–對於需要大型容器的應用程序，Long-running長期運行的應用程序的問題更加嚴重。對於short-running短期運行的應用程序，以前的容器最終可能會完成運行，並為具有大型容器的應用程序釋放集群資源。但是對於群集中運行時間較長的服務，大型容器可能永遠不會在任何節點上獲得足夠大的資源。
Hive LLAP – Hive LLAP（低延遲分析處理）使您可以近實時地以低延遲運行Hive查詢。為確保低延遲，應將用於LLAP的隊列的優先級設置為較高的優先級，尤其是在您的集群中包含運行時間較長的應用程序時。

要設置用於Hive LLAP的隊列,在 Ambari dashboard中Hive > Config > Settings ,在Interactive Query Queue 下拉菜單中選擇一個隊列，詳細信息參見Hive Performance Tuning guide.
例如，下圖顯示了一個具有3個節點的群集，該群集具有長期運行的20 GB容器。LLAP守護程序需要90 GB的群集資源，但不會發生搶占，因為可用隊列的容量不足，相對資源使用率較低。在任何節點上只有80 GB可用空間時，LLAP必須等待長時間運行的應用程序完成才能訪問群集資源。

先決條件：
為了應用YARN隊列優先級，您必須啟用搶占。
在YARN Queue Manager 界面，選擇隊列，然后給priority給一個值，默認為0，值越大，優先級越高。

然后點擊Actions > Save and Refresh Queues

7 資源分配流程

在調度過程中，按當前已使用容量的順序對層次結構中任何級別的隊列進行排序，並且可用資源從當前服務不足程度最高的隊列開始分配。
僅就容量capacities而言，資源調度具有以下工作流程：

隊列服務不足(under-served)的情況越多，它在資源分配期間獲得的優先級越高。服務不足的隊列是已用容量與集群總容量之比最小的隊列。
- 任何父隊列的已用容量被遞歸定義為其所有后代隊列的已用容量的總和。
- 葉隊列的已用容量是該隊列中運行的所有應用程序的已分配容器所使用的資源量。
一旦決定將當前可用的空閑資源提供給父隊列，則將基於先前描述的已用容量概念，遞歸地進行進一步的調度，以確定哪個子隊列可以使用這些資源。
在每個葉隊列內部進行進一步的調度，以按FIFO順序將資源分配給應用程序。
- 這也取決於locality,user level limits, and application limits.
- 一旦選擇了葉隊列中的應用程序，調度也將在該應用程序內進行。應用程序可能具有不同的資源請求優先級。
為了確保彈性，已配置但由於需求不足而未被任何隊列使用的容量會自動分配給需要資源的隊列。

8 資源分配流程示例

假設一個100節點的群集，每個節點為YARN容器分配了10 GB的內存，集群的總容量為1000 GB（1 TB）。

根據之前描述的配置，Engineering組織將分配60％的群集容量，即600 GB的絕對容量。同樣，為Support組織分配了100 GB，而Marketing組織獲得了300 GB。

在Engineering組織下，capacity以1：4的比例在Development團隊和QA團隊之間分配。因此，Development獲得了120 GB的空間，480 GB分配給QA。
現在考慮以下事件時間表：

最初，整個“Engineering”隊列是空閑的，沒有任何應用程序在運行，而“Support”和“Marketing”隊列則用完了他們的全部容量。
用戶Sid和Hitesh首先將應用程序提交到“development”葉隊列。它們的應用程序具有彈性，可以與群集中可用的所有資源一起運行，也可以與群集資源的子集一起運行（取決於資源使用情況）。
- 即使為“development”隊列分配了120 GB，Sid和Hitesh仍被允許占用120 GB，總計240 GB。
- 盡管事實上“development”隊列被配置為以120 GB的容量運行，還是會發生這種情況。Capacity Scheduler允許彈性共享群集資源，以更好地利用可用群集資源。由於“engineering”隊列中沒有其他用戶，因此Sid和Hitesh被允許使用可用的免費資源。
接下來，用戶Jian Zhijie和Xuan向“development”葉子隊列提交更多應用程序。即使每個限制為120 GB，隊列中的總已用容量仍為600 GB-基本上接管了分配給“ qa”葉隊列的所有資源。
用戶Gupta現在將應用程序提交到“ qa”隊列。由於集群中沒有可用的空閑資源，他的應用程序必須等待。
- 考慮到“development”隊列正在利用所有可用的群集資源，Gupta可能會或可能不會立即取回其“ qa”隊列的保證容量–這取決於是否啟用了搶占。
隨着Sid，Hitesh，Jian，Zhijie和Xuan的應用程序運行完畢並且資源可用，新可用的Containers將分配給Gupta的應用程序。

這將繼續進行，直到群集穩定在“development”和“ qa”隊列的預期資源使用率達到1：4為止。

從此示例中，您可以看到，粗魯的(obusive)的用戶有可能連續提交應用程序，從而將其他隊列鎖定在資源分配中，直到容器完成運行或被搶占為止。為了避免這種情況，Capacity Scheduler支持限制任何隊列的彈性增長。例如，要限制“development”隊列獨占“engineering”隊列容量，管理員administrator可以設置最大容量屬性：

1 Property: yarn.scheduler.capacity.root.engineering.development.maximum-capacity
2 Value: 40

設置好此設置后，“development”隊列的用戶仍然可以超過其120 GB的容量，但是分配給他們的空間不會超過“engineering”父隊列的40％（即600 GB的40％= 240 GB）。

capacity和maximum-capacity屬性可用於控制使用YARN群集的組織和子組織之間的共享和彈性。管理員Administrators應平衡這些屬性，以避免造成使用率損失的嚴格限制，並避免過多的跨組織共享。

使用可以在運行時動態更改capacity和maximum-capacity設置yarn rmadmin -refreshQueues。

9 設置User Limits

minimum-user-limit-percent設置分配給每個葉隊列用戶的最小資源百分比。
例如，要在五個用戶之間平等共享“services”葉隊列容量，可以將minimum-user-limit-percent屬性設置為20％：

1 Property: yarn.scheduler.capacity.root.support.services.minimum-user-limit-percent
2 Value: 20

此設置確定了，任何用戶的隊列容量份額可以縮減的最小限制。無論是否有此限制，如果有可用的空閑資源，任何用戶都可以進入隊列並獲得比其分配的份額更多的份額。

下表顯示了用戶將作業提交到minimum-user-limit-percent=20％的隊列時，如何調整隊列資源：

對於連續提交多個作業的單個用戶，以相同的方式調整隊列資源。如果沒有其他用戶正在請求隊列資源，則第一個作業將獲得隊列容量的100％。當用戶提交第二份作業時，每個作業將獲得隊列容量的50％。當用戶提交第三份作業時，每個作業將獲得隊列容量的33％。如果第二個用戶隨后提交了作業，則每個作業將獲得隊列容量的25％。當所有用戶提交的作業總數達到五個時，每個作業將獲得20％的隊列容量，隨后的用戶必須等待隊列容量釋放（假設未啟用搶占）。
- Capacity Scheduler還通過減少用戶數量管理資源。隨着用戶應用程序的運行完成，其他具有突出要求的現有用戶開始收回該共享。
- 請注意，盡管在用戶之間進行了共享，但是Capacity Scheduler的FIFO應用程序調度順序不會更改。這樣可以保證用戶無法通過連續提交新的應用程序來壟斷隊列。首先提交的應用程序（以及相應的用戶）始終具有比之后提交的應用程序更高的優先級。
Capacity Scheduler的葉隊列也可以使用該 user-limit-factor屬性來控制用戶資源分配。此屬性表示任何單個用戶最多可以消耗的隊列容量的fraction，而不管集群中是否有空閑資源。

1 Property: yarn.scheduler.capacity.root.support.user-limit-factor
2 Value: 1

默認值“ 1”表示隊列中的任何單個用戶最多只能占用隊列的配置容量。這樣可以防止單個隊列中的用戶在群集中的所有隊列之間獨占資源。將該值設置為“ 2”會將隊列的用戶限制為隊列配置容量的兩倍。將其設置為0.5會限制任何用戶使用超出隊列容量一半的資源。

可以在運行時使用來動態更改這些設置yarn rmadmin - refreshQueues。

10 應用資源預約Application Reservations

對於資源密集型應用程序，如果節點的可用容量可以滿足特定應用程序的需求，那么 Capacity Schedule將在該群集節點上創建預留。這樣可以確保僅該特定的應用程序使用資源，直到完成應用程序預訂為止。

Capacity Schedule負責將群集中的可用資源與應用程序的資源需求進行匹配。很多時候，會發生調度周期，以至於即使節點上有空閑資源，它們的大小也無法滿足在隊首的應用等待資源的需求。高內存應用程序通常會發生這種情況，這些應用程序對容器Containers的資源需求比群集中運行的典型應用程序要大得多。這種不匹配會導致這些資源密集型應用程序匱乏。

Capacity Scheduler 預約功能可解決此問題，如下所示：

當節點報告有容器完成時， Capacity Scheduler 會根據capacity和maximum capacity設置選擇適當的隊列來利用新可用的資源。
在該選定隊列中，Capacity Scheduler以FIFO順序和user limits一起查看應用程序。一旦找到需要的應用程序，Capacity Scheduler將嘗試查看節點的可用容量是否可以滿足該應用程序的要求。
如果大小不匹配，Capacity Scheduler將立即在節點上為應用程序所需的容器創建預留。
為節點上的應用程序進行預留后，Capacity Scheduler不會將這些資源用於任何其他隊列，應用程序或容器，直到完成應用程序預留為止。
當足夠的容器完成運行時，在其上進行預留的節點將報告，以使該節點上的總可用容量現在與預留大小匹配。發生這種情況時，Capacity Scheduler將預留標記為已完成，將其刪除，然后在節點上分配一個Container。
在某些情況下，另一個節點可以滿足應用程序所需的資源，因此應用程序不再需要第一個節點上的保留容量。在這種情況下，只需取消預訂即可。

為了防止預留數量以無限制的方式增長，並避免任何潛在的調度死鎖，Capacity Scheduler在每個節點上一次只能維護一個活動預留。

11 設置靈活的調度策略

根據您的要求在Capacity Scheduler中設置FIFO（先進先出）或公平調度策略。

Capacity Scheduler中的默認排序策略是FIFO（先進先出）。FIFO通常可以很好地用於可預測的周期性批處理作業。但有時對於按需或探索性工作負載而言效果不佳。對於這些類型的工作，Fair Sharing(公平共享)通常是更好的選擇。靈活的調度策略使您可以在每個隊列的基礎上為不同類型的工作負載分配FIFO或Fair 排序策略。

11.1 FIFO and Fair Sharing 策略示例

FIFO（先進先出）和Fair Sharing策略在批處理作業 batch jobs 和臨時作業 ad hoc jobs中的工作方式不同。
批處理示例

在此示例中，兩個隊列具有相同的可用資源。一種使用FIFO排序策略，另一種使用Fair Sharing公平共享策略。用戶將三個作業一個接一個地提交到每個隊列中，等待足夠長的時間以開始每個作業。第一個作業使用隊列中資源限制的6x，第二個使用4x，最后一個使用2x。
在FIFO隊列中，6x作業將開始並運行到完成，然后4x作業將開始並運行到完成，然后是2x作業。他們將以6x，4x，2x的順序開始和結束。
在公平隊列中，將開始6x作業，然后是4x作業，然后是2x作業。所有這三個將同時運行，每個使用1/3的可用應用程序資源。它們通常按以下順序完成：2x，4x，6x。

臨時加批處理示例

在此示例中，使用10倍隊列資源的作業正在運行。作業完成一半后，同一用戶將啟動第二個作業，所需的隊列資源為原來的1倍。

在FIFO隊列中，10x作業將運行，直到不再使用所有隊列資源（例如，映射階段完成），然后1x作業將開始。
在公平隊列中，1x作業將盡快開始，運行和完成-通過消耗從10x作業中獲取資源。

11.2 配置隊列排序策略Configure Queue Ordering Policies

您可以在capacity-scheduler.xml中將 Queue Ordering Policies屬性配置為fifo 或fair中的。

Ordering policies在capacity-scheduler.xml中配置。要基於每個隊列指定排序策略，請將以下屬性設置為 fifo或fair。默認設置為 fifo。

1 <property>
2   <name>yarn.scheduler.capacity.<queue-path>.ordering-policy</name>
3   <value>fair</value>
4 </property>

您可以使用以下屬性來啟用基於大小的資源分配加權。當此屬性設置為時true，隊列資源將根據其大小分配給各個應用程序，而不是為所有應用程序提供均等的隊列資源，而不管大小如何。默認設置為false。

1 <property>
2 <name>yarn.scheduler.capacity.<queue-path>
3 .ordering-policy.fair.enable-size-based-weight</name>
4 <value>true</value>
5 </property>

11.3 排序策略的最佳實踐Best Practices for Ordering Policies

在配置排序策略時，必須考慮與隊列中的應用程序和資源可用性相關的因素。

排序策略是按隊列配置的，默認排序策略設置為FIFO。通常，Fairness最適合按需，交互式或探索性工作負載，而FIFO可以更有效地用於可預測的重復批處理。您應該將這些不同類型的工作負載隔離到使用適當的排序策略配置的隊列中。
在同時支持大型和小型應用程序的隊列中，大型應用程序可能會“餓死”（無法接收足夠的資源）。為了避免這種情況，請為不同大小的作業使用不同的隊列，或者使用基於大小的加權來減少排序邏輯傾向於較小應用程序的自然趨勢。
使用該 yarn.scheduler.capacity..maximum-am-resource-percent 屬性限制在隊列中運行的並發應用程序的數量，以避免出現同時運行太多應用程序的情況。每個隊列的限制與它們的隊列容量和用戶限制成正比。此屬性被指定為浮點型，例如：0.5 = 50％。默認設置為10％。可以使用該yarn.scheduler.capacity.maximum-am-resource-percent屬性為所有隊列設置此屬性，每個隊列中設置的 yarn.scheduler.capacity..maximum-am-resource-percent會覆蓋掉yarn.scheduler.capacity.maximum-am-resource-percent設置的。

12 啟動和停止隊列Start and Stop Queues

YARN中的隊列可以處於兩種狀態：RUNNING或STOPPED。RUNNING狀態表示隊列可以接受應用程序提交，而STOPPED隊列不接受應用程序提交。任何已配置隊列的默認狀態為RUNNING。

在Capacity Scheduler中，父隊列，葉隊列和root隊列都可以停止。為了使應用程序在任何葉隊列中被接受，必須一直運行層次結構中直到根隊列的所有隊列。這意味着，如果父隊列停止，則該層次結構中的所有后代隊列均處於非活動狀態，即使它們自己的狀態為RUNNING。

下面的示例將“support”隊列的state屬性的值設置為RUNNING：

1 Property: yarn.scheduler.capacity.root.support.state
2 Value: RUNNING

管理員Administrators可以出於多種原因使用該功能來停止和清空隊列中的應用程序，例如在停用隊列並將其用戶遷移到其他隊列時。管理員可以在運行時停止隊列，所以在當前應用程序運行完成時，不會允許任何新的應用程序。現有應用程序可以繼續運行直到完成運行，因此可以在不影響最終用戶的情況下優雅地清空隊列。

管理員Administrators還可以通過修改state配置屬性，然后使用刷新隊列來重新啟動已停止的隊列 yarn rmadmin -refreshQueues。

13 設置應用程序限制 Set Application Limits

為避免由於不可管理的負載（由惡意用戶或意外負載導致）而導致系統崩潰，通過 Capacity Scheduler ，您可以對同時處於active狀態（both running and pending）的應用程序總數設置靜態的，可配置的限制任何一次。

用maximum-applications屬性配置，默認值為10,000。

1 Property: yarn.scheduler.capacity.maximum-applications
2 Value: 10000

在任何特定隊列中運行應用程序的限制是該總限制的一小部分，與它的容量成比例。這是一個硬限制，這意味着一旦隊列達到該限制，該隊列中的任何新應用程序都將被拒絕，客戶端將必須等待並稍后重試。可以使用以下配置屬性在每個隊列上顯式覆蓋此限制：

1 Property: yarn.scheduler.capacity.<queue-path>.maximum-applications
2 Value: absolute-capacity * yarn.scheduler.capacity.maximum-applications

還有另一個資源限制，可用於設置專門分配給ApplicationMaster的集群資源的最大百分比。該maximum-am-resource-percent屬性的默認值為10％，並且存在此屬性是為了避免跨應用程序死鎖，因為在該死鎖中集群中的大量資源完全由運行ApplicationMasters的Container占用。此屬性還間接控制集群中並發運行的應用程序的數量，每個隊列限制為與其容量成比例的正在運行的應用程序的數量。

1 Property: yarn.scheduler.capacity.maximum-am-resource-percent
2 Value: 0.1

與最大應用程序一樣，此限制也可以基於每個隊列被覆蓋：

1 Property: yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent
2 Value: 0.1

所有這些限制確保了沒有單個應用程序，用戶或隊列會導致災難性故障，也不會壟斷群集並導致群集性能過度下降。

14 啟用搶占 Enable Preemption

Capacity Scheduler Preemption允許優先級較高的應用程序搶占優先級較低的應用程序。

可能發生一種情況，其中隊列具有保證的群集資源級別，但是必須等待運行應用程序，因為其他隊列正在利用所有可用資源。如果啟用了搶占，則優先級較高的應用程序不必等待，因為優先級較低的應用程序已占用了可用容量。啟用搶占功能后，服務不足的隊列幾乎可以立即開始聲明其分配的群集資源，而不必等待其他隊列的應用程序完成運行。

14.1 搶占工作流程 Preemption Workflow

搶占由一組容量監視器策略(capacity monitor policies)控制，必須通過將yarn.resourcemanager.scheduler.monitor.enable屬性設置為true來啟用該策略。這些容量監視器策略基於定義的容量分配，以可配置的間隔去搶占，並且以盡可能合適的方式進行。Containers只是在萬不得已時才被殺死的。
下圖演示了搶占工作流程：

14.2 配置搶占 Configure Preemption

Capacity Schedule在yarn-site.xmlr中配置各種屬性以設置應用程序搶占。

在ResourceManager主機上/etc/hadoop/conf/yarn-site.xml 中的以下屬性用於啟用和配置搶占。

1 Property: yarn.resourcemanager.scheduler.monitor.enable
2 Value: true
3 Description: Setting this property to "true" enables Preemption. It enables a set of periodic monitors that affect the Capacity Scheduler. This default value for this property is "false" (disabled).
4 將此屬性設置為“ true”將啟用搶占。它啟用了一組定期監視器，這些監視器會影響Capacity Scheduler。此屬性的默認值是“ false”（禁用）。

1 Property: yarn.resourcemanager.scheduler.monitor.policies
2 Value:
3 org.apache.hadoop.yarn.server.resourcemanager.monitor.capacity.ProportionalCapacityPreemptionPolicy
4 Description: The list of SchedulingEditPolicy classes that interact with the scheduler. The only policy currently available for preemption is the “ProportionalCapacityPreemptionPolicy”.
5 與調度程序交互的SchedulingEditPolicy類的列表。當前唯一可用於搶占的策略是“ ProportionalCapacityPreemptionPolicy”。

1 Property: yarn.resourcemanager.monitor.capacity.preemption.monitoring_interval
2 Value: 3000
3 Description: The time in milliseconds between invocations of this policy. Setting this value to a longer time interval will cause the Capacity Monitor to run less frequently.
4 兩次調用該策略之間的時間（以毫秒為單位）。將此值設置為較長的時間間隔將導致容量監視器的運行頻率降低。

1 Property: yarn.resourcemanager.monitor.capacity.preemption.max_wait_before_kill
2 Value: 15000
3 Description: The time in milliseconds between requesting a preemption from an application and killing the container. Setting this to a higher value will give applications more time to respond to preemption requests and gracefully release Containers.
4 從應用程序請求搶占到終止容器之間的時間（以毫秒為單位）。將此值設置為較高的值將使應用程序有更多時間響應搶占請求並優雅地釋放容器。

1 Property: yarn.resourcemanager.monitor.capacity.preemption.total_preemption_per_round
2 Value: 0.1
3 Description: The maximum percentage of resources preempted in a single round. You can use this value to restrict the pace at which Containers are reclaimed from the cluster. After computing the total desired preemption, the policy scales it back to this limit. This should be set to (memory-of-one-NodeManager)/(total-cluster-memory). For example, if one NodeManager has 32 GB, and the total cluster resource is 100 GB, the total_preemption_per_round should set to 32/100 = 0.32. The default value is 0.1 (10%).
4 單回合中可搶占的最大資源百分比。您可以使用此值來限制從群集回收Containers的速度。計算完所需的總搶占后，策略會將其重新擴展到此限制。應將其設置為(memory-of-one-NodeManager)/(total-cluster-memory)。例如，如果一個NodeManager擁有32 GB，並且群集總資源為100 GB，則total_preemption_per_round應設置為32/100 = 0.32。默認值為0.1（10％）。

1 Property: yarn.resourcemanager.monitor.capacity.preemption.natural_termination_factor
2 Value: 1.0
3 Description: Similar to total_preemption_per_round, you can apply this factor to slow down resource preemption after the preemption target is computed for each queue (for example, “give me 5 GB back from queue-A”). For example, if 5 GB is needed back, in the first cycle preemption takes back 1 GB (20% of 5GB), 0.8 GB (20% of the remaining 4 GB) in the next, 0.64 GB (20% of the remaining 3.2 GB) next, and so on. You can increase this value to speed up resource reclamation. The recommended value for this parameter is 1.0, meaning that 100% of the target capacity is preempted in a cycle.
4 類似於total_preemption_per_round，在為每個隊列計算了搶占目標之后，可以應用此因子來減慢資源搶占（例如，“從隊列A中退回5 GB”）。例如，如果需要5 GB，則在第一個周期中，搶占將收回1 GB（5 GB的20％），在下一個周期中收回0.8 GB（其余4 GB的20％），在0.64 GB（其余3.2 GB的20％）中搶占。 GB），依此類推。您可以增加此值以加快資源回收。此參數的建議值為1.0，這意味着一個循環中將搶占100％的目標容量。

15 啟用優先級調度 Enable Priority Scheduling

您可以使用“優先級調度”以運行更高的優先級YARN應用程序，而與群集中已經在運行的其他應用程序無關。YARN會向運行優先級較低的應用程序分配更多資源給運行優先級較高的應用程序。優先級調度使您可以在提交時和在運行時動態設置應用程序的優先級。

優先級調度僅適用於FIFO（先進先出）排序策略。FIFO是默認的Capacity Scheduler訂購策略。

步驟：

1.設置群集的最大優先級和葉隊列級別的優先級。
- Cluster maximum priority：在yarn-site.xml文件中設置以下屬性，以定義集群中應用程序的最大優先級：
```
1 yarn.cluster.max-application-priority
```

- 優先級大於此設置的所有提交的應用程序都將其優先級重置為 yarn.cluster.max-application-priority 值。
- Leaf queue-level priority：在capacity-scheduler.xml文件中設置以下屬性，以定義葉子隊列中的默認應用程序優先級：
  
  yarn.scheduler.capacity.root..default-application-priority
  默認應用程序優先級用於沒有指定優先級的任何提交的應用程序。
2.使用yarn application -appID命令行選項或集群應用程序REST API來設置已運行的應用程序的優先級。
- yarn application -appID -updatePriority <優先級>
- 群集應用程序優先級API

16 為應用程序優先級配置ACLs ACLs for Application Priorities

配置優先級ACLs，以確保只有選定用戶可以將指定優先級的應用程序提交到隊列。您必須在葉隊列級別配置這些優先級ACLs。
如果已經為用戶訪問葉隊列配置了ACL，則該隊列的優先級ACL只能包括那些有權訪問該隊列的用戶。
在capacity-scheduler.xml文件中設置以下屬性以設置優先級ACL：

 1 <property>
 2     <name>yarn.scheduler.capacity.<leaf-queue-path>.acl_application_max_priority</name>
 3     
 4     <value>[user={username} group={groupname} max_priority={priority} default_priority={priority}]
 5     </value>
 6     
 7     <description>
 8       The ACL of users who can submit applications with configured priority.
 9     </description>
10 </property>

以下示例說明如何為用戶maria和組hadoop的用戶配置優先級ACLs ：

1 yarn.scheduler.capacity.root.queue1.acl_application_max_priority=[user=maria group=hadoop max_priority=7 default_priority=4
2 ]

該用戶maria和該hadoop 組的用戶可以提交應用的最高優先級為7。

17 啟用隊列內搶占 Enable Intra-Queue Preemption

隊列內搶占(Intra-queue )可根據已配置的用戶限制(user limits)或應用程序優先級(application priorities)幫助有效地在隊列內分配資源。

隊列內搶占通過防止發生以下情況來防止隊列中的資源不平衡：

較低優先級的應用程序消耗隊列中的所有可用資源，從而使較高優先級的應用程序資源匱乏。
少數用戶消耗了整個隊列的容量，從而使其他用戶無法提交更高優先級的應用程序。盡管根據配置的限制，所有用戶都有資格使用隊列的資源，但仍可能發生這種情況。

17.1 用於配置隊列內搶占的屬性 Properties for Configuring Intra-Queue Preemption

默認情況下，YARN隊列啟用隊列內搶占。此外，您可以通過應用程序優先級(application priorities)或配置的用戶限制(user limits)來配置隊列內搶占的順序。

您可以在yarn-site.xml中為隊列內搶占配置以下屬性的值：

Property	Description
yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.enabled	是否為隊列啟用隊列內搶占。默認值true
yarn.resourcemanager.monitor.capacity.preemption.intra-queue-preemption.preemption-order-policy	指定隊列可以搶占資源的順序。根據您的要求，可以將此屬性配置為以下值之一：userlimit-first：以根據配置的用戶限制啟動隊列內搶占。這是默認值。priority-first：以根據應用程序優先級啟動隊列內搶占。

17.2 基於應用優先級的隊列內搶占 Intra-Queue Preemption Based on Application Priorities

根據應用程序優先級在隊列上啟用搶占可確保較高優先級的應用程序可以在需要時從較低優先級的應用程序中搶占資源。

沒有啟用搶占的隊列上資源消耗的示例：

考慮一個root.qA.capacity配置為70％的隊列qA 。按以下順序提交的申請：

用戶提交優先級為p1的應用程序app1。因為沒有其他應用程序在隊列上運行，所以app1使用隊列上可用的大部分資源。
app1開始運行后不久，用戶提交了另一個與app1具有相同優先級的應用程序app2。在這種情況下，app2使用隊列上剩余的資源。
用戶提交具有更高優先級p3的第三應用程序app3。
如果未在隊列上啟用搶占，則優先級較低的應用程序app1和app2會消耗隊列的所有可用容量，而優先級較高的應用程序app3則資源不足。

下表說明了三個應用程序之間的資源分配：

啟用搶占的隊列上資源消耗的示例：

考慮與前面的示例相同的隊列和具有優先級的應用程序。

如果在隊列上啟用了基於應用程序優先級的搶占，則會從app1和app2中搶占資源，以便運行更高優先級的app3。

下表說明了啟用搶占時三個應用程序之間的資源分配：

17.3 基於用戶限制的隊列內搶占 Intra-Queue Preemption based on User Limits

在基於用戶限制的隊列上啟用搶占可確保將資源提交到特定隊列的所有用戶之間均勻分配資源。

沒有啟用搶占的隊列上資源消耗的示例
考慮一個root.qA.capacity配置為100％和 minimum-user-limit-percent配置為33％的隊列qA 。這意味着向隊列提交應用程序的前三個用戶每個都可以使用至少33％的隊列資源。如果這三個用戶已經按照指定使用了隊列的資源，則任何其他用戶都必須等待資源分配后再提交應用程序。

考慮按以下順序提交的申請：

用戶u1提交具有優先級p1的應用程序app1。因為沒有其他應用程序在隊列上運行，所以app1使用隊列上可用的大部分資源。
app1開始運行后不久，用戶u2和u3大約同時在同一時間提交了應用程序app2和app3，優先級為p1。在這種情況下，app2和app3使用保留在隊列中的資源。
如果未在隊列上啟用搶占，則盡管app2和app3的優先級與app1相同，但它們不會消耗隊列上的資源份額。

下表說明了三個應用程序之間的資源分配：

開啟搶占的隊列上的資源消耗示例
考慮與前面的示例相同的隊列和具有優先級的應用程序。

如果在隊列上啟用了基於用戶限制的搶占，則將從app1中搶占資源以使app2和app3運行。

下表說明了啟用搶占時三個應用程序之間的資源分配：

相關鏈接：

Hortonworks 文檔
https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.4/data-operating-system/content/manage_cluster_capacity_with_queues.html
yarn-resource-managerment
https://pivotalhd.docs.pivotal.io/docs/yarn-resource-management.html
yarn-capacity相關文章
http://bigdatadecode.club/[%E8%AF%91]Yarn-capacity.html
apache hadoop相關配置解釋
https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html#Setting_up_queues

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 YARN資源調度器畫圖詳解yarn的資源調度流程 Yarn的三種資源調度機制 Hadoop學習之路(8)Yarn資源調度系統詳解 5、基礎篇-資源調度 Spark 資源調度及任務調度 kubernetes Pod資源調度之污點和容忍 Android系統“資源調度框架” k8s的pod的資源調度 kubernetes Pod資源調度之優先(搶占)調度