YARN Capacity Scheduler怎么實現

這篇文章主要講解了“YARN Capacity Scheduler怎么實現”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“YARN Capacity Scheduler怎么實現”吧！

特點

以隊列為單位劃分資源，每個隊列可設定一定比例的資源最低保證和使用上限，同時，每個用戶也可設定一定的資源使用上限以防止資源濫用。而當一個隊列的資源有剩余時，可暫時將剩余資源共享給其他隊列。總之，Capacity Scheduler主要有以下幾個特點：

• 容量保證：管理員可為每個隊列設置資源最低保證和資源使用上限，而所有提交到該隊列的應用程序共享這些資源

• 靈活性：如果一個隊列中的資源有剩余，可以暫時共享給那些需要資源的隊列，而一旦該隊列有新的應用程序提交，則其他隊列釋放的資源會歸還給該隊列

• 多重租賃：支持多用戶共享集群和多應用程序同時運行。為防止單個應用程序、用戶或隊列獨占集群中的資源，管理員可為之增加多重約束（比如單個應用程序同時運行的任務數等）

• 安全保證：每個隊列有嚴格的ACL列表規定它的訪問用戶，每個用戶可指定哪些用戶允許查看自己應用程序的運行狀態或者控制應用程序（比如殺死應用程序）。此外，管理員可指定隊列管理員和集群系統管理員

• 動態更新配置文件：管理員可根據需要動態修改各種配置參數，以實現在線集群管理

Capacity Scheduler的功能

1. Capacity Scheduler有自己的配置文件，即存放在conf目錄下的capacity-scheduler.xml

2. 在Capacity Scheduler的配置文件中，隊列queueX的參數Y的配置名稱為yarn.scheduler.capacity.queueX.Y

3. 資源分配相關參數：

• capacity：隊列的最小資源容量（百分比）。注意，所有隊列的容量之和應小于100

• maximum-capacity：隊列的資源使用上限

• minimum-user-limit-percent：每個用戶最低資源保障（百分比）

• user-limit-factor：每個用戶最多可使用的資源量（百分比）

4. 限制應用程序數目的相關參數：

• maximum-applications：集群或者隊列中處于等待和運行狀態的應用程序數目上限，這是一個強限制項，一旦集群中應用程序數目超過該上限，后續提交的應用程序將被拒絕。默認值為10000。Hadoop允許從集群和隊列兩個方面該值，其中，集群的總體數目上限可通過參數yarn.scheduler.capacity.maximum-applications設置，默認為10000，而單個隊列可通過參數yarn.scheduler.capacity.<queue-path>.maximum-applications設置適合自己的值

• maximum-am-resource-percent：集群中用于運行應用程序ApplicationMaster的資源比例上限，該參數通常用于限制處于活動狀態的應用程序數目。所有隊列的ApplicationMaster資源比例上限可通過參數yarn.scheduler.capacity.maximum-am-resource-percent設置，而單個隊列可通過參數yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent設置適合自己的值

5. 隊列訪問權限控制

• state：隊列狀態，可以為STOPPED或者RUNNING。如果一個隊列處于STOPPED狀態，用戶不可以將應用程序提交到該隊列或者它的子隊列中。類似的，如果root隊列處于STOPPED狀態，則用戶不可以向集群提交應用程序，但正在運行的應用程序可以正常運行結束，以便隊列可以優雅地退出

• acl_submit_application：限定哪些用戶/用戶組可向給定隊列中提交應用程序。該屬性具有繼承性，即如果一個用戶可以向某個隊列提交應用程序，則它可以向它所有子隊列中提交應用程序

• acl_administer_queue：為隊列指定一個管理員，該管理員可控制該隊列的所有應用程序，比如殺死任意一個應用程序等。同樣，該屬性具有繼承性，如果一個用戶可以向某個隊列中提交應用程序，則它可以向它的所有子隊列中提交應用程序

6. 當管理員需動態修改隊列資源配置時，可修改配置文件conf/capacity-scheduler.xml，然后運行“yarn rmadmin -refreshQueues”

7. 當前Capacity Scheduler不允許管理員動態減少隊列數目，且更新的配置參數值應是合法值，否則會導致配置文件加載失敗

Capacity Scheduler實現

應用程序初始化

1. 應用程序被提交到ResourceManager之后，ResourceManager會向Capacity Scheduler發送一個SchedulerEventType.APP_ADDED事件，Capacity Scheduler收到該事件后，將為應用程序創建一個FiCaSchedulerApp對象跟蹤和維護該應用程序的運行時信息，同時將應用程序提交到對應的葉子隊列中，葉子隊列會對應用程序進行一系列合法性檢查。只有通過這些合法性檢查，應用程序才算提交成功，這些合法性包括以下幾個方面：

   
   

• 應用程序所屬用戶擁有該葉子隊列的應用程序提交權限

• 隊列及其父隊列當前處于RUNNING狀態（遞歸檢查）

• 隊列當前已提交的應用程序數目未達到管理員設定的上限

• 應用程序所屬用戶提交的應用程序數目未超過管理員設定的上限

資源調度

當ResourceManager收到來自NodeManager發送的心跳信息后，將向Capacity Scheduler發送一個SchedulerEventType.NODE_UPDATE事件，Capacity Scheduler收到該事件后，會依次進行以下操作：

1. 處理心跳信息：NodeManager發送的心跳信息中有兩類信息需資源調度器處理，一類是最新啟動的Container，另一類是運行完成的Container，具體如下：

• 對于最新啟動的Container，資源調度器需向ResourceManager發送一個RMContainerEventType.LAUNCHED，進而將該Container從超時監控隊列中刪除。當資源調度器為ApplicationMaster分配一個Container后，為了防止ApplicationMaster長時間不使用該Container造成資源浪費，它會將該Container加入一個超時監控隊列中。如果一段時間內，該隊列中的Container仍未被使用，則資源調度器會回收該Container

• 對于運行完成的Container，資源管理器將回收它使用的資源，以便接下來對這些資源進行再分配
  處理完以上兩類信息后，Capacity Scheduler將節點上的空閑資源分配給應用程序

2. 資源分配

            1. Container主要包含5類信息：

• 優先級

• 期望資源所在節點

• 資源量

• Container數目

• 是否松弛本地性（即是否在沒有滿足節點本地性資源時，選擇機架本地性資源）

2. 資源調度器收到資源申請后，將暫時將這些數據請求存放到一個數據結構中，以等待空閑資源出現后為其分配合適的資源

3.  當一個節點上有空閑資源時，它會依次選擇隊列、應用程序和container（請求）使用該資源




• 步驟1：選擇隊列

• 從根隊列開始，按照它的子隊列資源使用率由小到大依次遍歷各個子隊列。如果子隊列為葉子隊列，則依次按照步驟2和步驟3中的方法在隊列中選出一個Container（請求），否則以該子隊列為根隊列，重復以上過程，直到找到一個合適的隊列并退出

• 注意：上述“隊列資源使用率”計算方法為用已經使用的資源量除以最小隊列資源容量（由管理員配置）。對于非葉子隊列，它的已使用資源量是各個子隊列已使用資源量之和

• 步驟2：選擇應用程序

• 在步驟1中選中一個葉子隊列后，Capacity Scheduler按照提交時間對子隊列中的應用程序進行排序（實際排序時用的是Applition ID，提交時間越早的應用程序，Application ID越小），選擇最早提交的 Application 分配資源

• 步驟3：選擇Container（請求）

• 對于同一個應用程序，它請求的Container可能是多樣化的，涉及不同的優先級、節點、資源量和數量。當選中一個應用程序后，Capacity Scheduler將嘗試優先滿足優先級高的Container。對于同一類優先級，優先選擇滿足本地性的Container，它會依次選擇node local、rack local和no local的Container

4. Capacity Scheduler有兩種比較器用以比較兩個資源的大小（比如比較用戶當前使用的資源量是否超過了設置的上限資源量），默認是DefaultResourceCalculator，它只考慮內存資源。另外一種是DominantResourceCalculator，它采用了DRF比較算法，同時考慮內存和CPU兩種資源。管理員可通過參數yarn.scheduler.capacity.resource-calculator設置資源比較器


5.  其他事件處理




• APP_REMOVED：在多種情況下Capacity Scheduler將收到該事件，包括應用程序正常結束、應用程序被殺死等。Capacity Scheduler收到該事件后，首先會向所有未運行完成的Container發送一個RMContainerEventType.KILL事件，以釋放正在使用的Container；然后才會將應用程序相關數據結構從內存中移除

• NODE_ADDED：當集群中動態加入一個節點時（比如管理員動態擴充集群規模或者節點斷開后又復活等），Capacity Scheduler將收到該事件。Capacity Scheduler收到該事件后，只需在相應數據結構中記錄NodeManager信息并增加系統總資源量即可

• NODE_REMOVED：當集群中動態移除一個節點時（比如管理員動態移除節點或者節點在一定事件內未匯報心跳而被ResourceManager移除集群），Capacity Scheduler將收到該事件。Capacity Scheduler收到該事件后，除了移除NodeManager信息并減少系統總資源外，還需向所有正運行的Container發送一個RMContainerEventType.KILL事件，以清空相關信息

• CONTAINER_EXPIRED：當Capacity Scheduler將一個Container分配給ApplicationMaster后，ApplicationMaster在一定時間內必須使用該Container，否則ResourceManager將進行強制回收，此時會觸發一個CONTAINER_EXPIRED事件

感謝各位的閱讀，以上就是“YARN Capacity Scheduler怎么實現”的內容了，經過本文的學習后，相信大家對YARN Capacity Scheduler怎么實現這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！