YARN資源調度策略之Capacity Scheduler

什么是capacity scheduler

Capacity Scheduler調度器以隊列為單位划分資源。簡單通俗點來說，就是一個個隊列有獨立的資源，隊列的結構和資源是可以進行配置的，如下圖：

default隊列占30%資源，analyst和dev分別占40%和30%資源；類似的，analyst和dev各有兩個子隊列，子隊列在父隊列的基礎上再分配資源。

隊列以分層方式組織資源,設計了多層級別的資源限制條件以更好的讓多用戶共享一個Hadoop集群，比如隊列資源限制、用戶資源限制、用戶應用程序數目限制。隊列里的應用以FIFO方式調度，每個隊列可設定一定比例的資源最低保證和使用上限，同時，每個用戶也可以設定一定的資源使用上限以防止資源濫用。而當一個隊列的資源有剩余時，可暫時將剩余資源共享給其他隊列。

特性

Capacity調度器具有以下的幾個特性：

• 層次化的隊列設計，這種層次化的隊列設計保證了子隊列可以使用父隊列設置的全部資源。這樣通過層次化的管理，更容易合理分配和限制資源的使用。
• 容量保證，隊列上都會設置一個資源的占比，這樣可以保證每個隊列都不會占用整個集群的資源。
• 安全，每個隊列有嚴格的訪問控制。用戶只能向自己的隊列里面提交任務，而且不能修改或者訪問其他隊列的任務。
• 彈性分配，空閑的資源可以被分配給任何隊列。當多個隊列出現爭用的時候，則會按照比例進行平衡。
• 多租戶租用，通過隊列的容量限制，多個用戶就可以共享同一個集群，同時保證每個隊列分配到自己的容量，提高利用率。
• 操作性，yarn支持動態修改調整容量、權限等的分配，可以在運行時直接修改。還提供給管理員界面，來顯示當前的隊列狀況。管理員可以在運行時，添加一個隊列；但是不能刪除一個隊列。管理員還可以在運行時暫停某個隊列，這樣可以保證當前的隊列在執行過程中，集群不會接收其他的任務。如果一個隊列被設置成了stopped，那么就不能向他或者子隊列上提交任務了。
• 基於資源的調度，協調不同資源需求的應用程序，比如內存、CPU、磁盤等等。

配置

開啟調度器

在ResourceManager中配置它要使用的調度器，配置方式是修改conf/yarn-site.xml，設置屬性：

    yarn.resourcemanager.scheduler.class   
    org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

配置隊列

調度器的核心就是隊列的分配和使用了，修改conf/capacity-scheduler.xml可以配置隊列。
Capacity調度器默認有一個預定義的隊列——root,所有的隊列都是它的子隊列。隊列的分配支持層次化的配置，使用.來進行分割，比如yarn.scheduler.capacity..queues

下面是配置的樣例，比如root下面有三個子隊列:

<property> <name>yarn.scheduler.capacity.root.queues> <value>a,b,c> <description>The queues at the this level (root is the root queue). > > <property> <name>yarn.scheduler.capacity.root.a.queues> <value>a1,a2> <description>The queues at the this level (root is the root queue). > > <property> <name>yarn.scheduler.capacity.root.b.queues> <value>b1,b2,b3> <description>The queues at the this level (root is the root queue). > >

隊列屬性

yarn.scheduler.capacity..capacity

它是隊列的資源容量占比(百分比)。系統繁忙時，每個隊列都應該得到設置的量的資源；當系統空閑時，該隊列的資源則可以被其他的隊列使用。同一層的所有隊列加起來必須是100%。

yarn.scheduler.capacity..maximum-capacity

隊列資源的使用上限。由於系統空閑時，隊列可以使用其他的空閑資源，因此最多使用的資源量則是該參數控制。默認是-1，即禁用。

yarn.scheduler.capacity..minimum-user-limit-percent

每個任務占用的最少資源。比如，你設置成了25%。那么如果有兩個用戶提交任務，那么每個任務資源不超過50%。如果3個用戶提交任務，那么每個任務資源不超過33%。如果4個用戶提交任務，那么每個任務資源不超過25%。如果5個用戶提交任務，那么第五個用戶需要等待才能提交。默認是100，即不去做限制。

yarn.scheduler.capacity..user-limit-factor

每個用戶最多使用的隊列資源占比，如果設置為50.那么每個用戶使用的資源最多就是50%。

運行和提交應用限制

yarn.scheduler.capacity.maximum-applications
yarn.scheduler.capacity..maximum-applications

設置系統中可以同時運行和等待的應用數量。默認是10000.

yarn.scheduler.capacity.maximum-am-resource-percent
yarn.scheduler.capacity..maximum-am-resource-percent

設置有多少資源可以用來運行app master，即控制當前激活狀態的應用。默認是10%。

隊列管理

yarn.scheduler.capacity..state

隊列的狀態，可以使RUNNING或者STOPPED.如果隊列是STOPPED狀態，那么新應用不會提交到該隊列或者子隊列。同樣，如果root被設置成STOPPED，那么整個集群都不能提交任務了。現有的應用可以等待完成，因此隊列可以優雅的退出關閉。

yarn.scheduler.capacity.root..acl_submit_applications

訪問控制列表ACL控制誰可以向該隊列提交任務。如果一個用戶可以向該隊列提交，那么也可以提交任務到它的子隊列。

yarn.scheduler.capacity.root..acl_administer_queue

設置隊列的管理員的ACL控制，管理員可以控制隊列的所有應用程序。同樣，它也具有繼承性。

注意： ACL的設置是user1,user2 group1,group2這種格式。如果是則代表任何人。空格表示任何人都不允許。默認是.

其他屬性

yarn.scheduler.capacity.resource-calculator

資源計算方法，默認是org.apache.hadoop.yarn.util.resource.DefaultResourseCalculator,它只會計算內存。DominantResourceCalculator則會計算內存和CPU。

yarn.scheduler.capacity.node-locality-delay

調度器嘗試進行調度的次數。一般都是跟集群的節點數量有關。默認40（一個機架上的節點數）
一旦設置完這些隊列屬性，就可以在web ui上看到了。可以訪問下面的連接：
xxx:8088/scheduler

修改隊列配置

如果想要修改隊列或者調度器的配置，可以修改

vi $HADOOP_CONF_DIR/capacity-scheduler.xml

修改完成后，需要執行下面的命令：

$HADOOP_YARN_HOME/bin/yarn rmadmin -refreshQueues

注意：

• 隊列不能被刪除，只能新增。
• 更新隊列的配置需要是有效的值
• 同層級的隊列容量限制相加需要等於100%。
• 如果希望自己的任務調度到queue1隊列，只需在啟動任務時指定：mapreduce.job.queuename參數為queue1即可，默認為default隊列

ACL設置的一個坑

Hadoop Yarn集群使用隊列進行任務調度和資源分配，同時支持使用ACL控制隊列允許指定用戶提交，配置中支持兩種操作的acl權限配置acl_administer_queue和acl_submit_applications。按照語意，如果要控制是否能提交作業，只要配置隊列的acl_submit_applications屬性即可，按照文檔，也就是這個意思。

從源碼發現其實不是的，只要有administer權限的，就能提交作業：

@Override public void submitApplication(ApplicationId applicationId, String userName, String queue) throws AccessControlException { // Careful! Locking order is important! // Check queue ACLs UserGroupInformation userUgi = UserGroupInformation.createRemoteUser(userName); if (!hasAccess(QueueACL.SUBMIT_APPLICATIONS, userUgi) && !hasAccess(QueueACL.ADMINISTER_QUEUE, userUgi)) { throw new AccessControlException("User " + userName + " cannot submit" + " applications to queue " + getQueuePath()); } 

如果要限制用戶對queue的權限root queue一定要設置，不能只設置leaf queue。因為權限是根權限具有更高的優先級，看代碼注釋:

// recursively look up the queue to see if parent queue has the permission  

意思是說檢查用戶是否有權限時，是先看leaf queue（如default）有沒有權限，如果沒有，再往上找父節點（root）看有沒有權限，如果有，成功提交任務。
如果不設置root.acl_submit_applications和root.acl_administer_queue時，默認所有leaf節點都會有所有權限，即在leaf節點設置的一切acl都無效。

所以一定要在capacity-scheduler.xml中配置:

<property> <name>yarn.scheduler.capacity.root.acl_submit_applications> <value> > > <property> <name>yarn.scheduler.capacity.root.acl_administer_queue> <value> > > 

按上面配置以后，root節點拒絕所有人提交job，這樣就可以由leaf節點直接控制權限了。

Queue Mapping設置

 該項設置用於指定哪些用戶/用戶組的任務提交到哪個隊列。具體有以下幾種方式：

1、直接映射具體用戶到具體隊列，格式為 u:user1:queueA ，用於表示user1這個用戶提交到queueA這個隊列

2、直接映射具體用戶組到具體隊列，格式為 g:group1:queueB，表示屬於group1組的用戶提交的任務都皎到queueB這個隊列

3、用戶和用戶組混合一起指定，格式為 u:user1:queueA,g:group1:queueB，舉如下示例

<property>
  <name>yarn.scheduler.capacity.queue-mappings</name>
  <value>u:maria:engineering,g:webadmins:weblog</value>
</property>
這表明maria用戶的任務將提交到engineering這個隊列，屬於webadmins用戶組的用戶提交的任務將提交到weblog隊列----因此，即使maria也屬於webadmins用戶組，但提交的任務仍舊提交到engineering隊列（從左到右先后順序）

4、組名和隊列名相同情況下的配置格式：u:%user:%primary_group

假設有"marketing" and "engineering" 2個組，在 "marketing"中, 有3個用戶: "angela", "rahul", and "dmitry"；在 "engineering"中, 有2個用戶: "maria" and "greg"，對應如下配置

<property>
  <name>yarn.scheduler.capacity.queue-mappings</name>
  <value>u:%user:%primary_group</value>
</property>
"angela", "rahul", and "dmitry"這3個用戶提交的任務都會提交到marketing隊列中，"maria" and "greg"這2個用戶提交的任務都會提交到engineering隊列中

5、用戶名和隊列名相同情況下的配置格式 ：u:%user:%user

是否開啟覆蓋默認Queue Mappings

在上述 Queue Mappings已經設置好了的情況下，如果開啟覆蓋，則用戶在提交應用程序的時候，可以手動指定提交隊列，覆蓋默認配置；反之，即使用戶提交時候指定了提交隊列，也會被忽略

開啟方法：在capacity-scheduler.xml中修改如下配置，把value改為true即可

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

 

官網參考：https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.6.0/bk_yarn-resource-management/content/default_queue_mapping_based_on_user_or_group.html