YARN Capacity Scheduler怎么實現(xiàn)

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

特點

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

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

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

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

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

• 動態(tài)更新配置文件：管理員可根據(jù)需要動態(tài)修改各種配置參數(shù)，以實現(xiàn)在線集群管理

Capacity Scheduler的功能

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

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

3. 資源分配相關參數(shù)：

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

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

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

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

4. 限制應用程序數(shù)目的相關參數(shù)：

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

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

5. 隊列訪問權限控制

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

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

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

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

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

Capacity Scheduler實現(xiàn)

應用程序初始化

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

   
   

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

• 隊列及其父隊列當前處于RUNNING狀態(tài)（遞歸檢查）

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

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

資源調(diào)度

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

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

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

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

2. 資源分配

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

• 優(yōu)先級

• 期望資源所在節(jié)點

• 資源量

• Container數(shù)目

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

2. 資源調(diào)度器收到資源申請后，將暫時將這些數(shù)據(jù)請求存放到一個數(shù)據(jù)結(jié)構中，以等待空閑資源出現(xiàn)后為其分配合適的資源

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




• 步驟1：選擇隊列

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

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

• 步驟2：選擇應用程序

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

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

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

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


5.  其他事件處理




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

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

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

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

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