hadoop之yarn詳解（框架進階篇）

   前面在hadoop之yarn詳解（基礎架構篇）這篇文章提到了yarn的重要組件有ResourceManager，NodeManager，ApplicationMaster等，以及yarn調度做業的運行過程，Yarn將它的功能分爲兩層：負責資源管理的平臺層，葉稱爲第一層調度，以及二級調度的框架來協調應用程序的執行。運行在獨立節點上的ResourceManager和NodeManager一塊兒組成了yarn的核心且構成這個平臺，ApplicationMaster和相應的Container一塊兒組成了yarn的應用程序。那麼這些組件具體的包含一些什麼呢？又是根據什麼通訊的呢？

這篇文章主要進一步闡述yarn幾個重要組件的重要成分，以及各個部分之間的通訊狀況。

1、ResourceManager

ResourceManager主要涉及到與客戶端、ApplicationMaster以及NodeManager的通訊組件、一些重要的組件，如ApplicationManager，scheduler等、以及安全相關組件。

1.一、Resourcemanager和客戶端的交互通訊

1.1.一、Client Service

該服務實現了基本的客戶端到ResourceManager的接口ApplicationClientProtocol。該組件處理全部來自客戶端到Resourcemanager的遠程調用（RPC）通訊。主要有以下操做：

一、應用程序的提交
二、應用程序的終止
三、獲取應用程序，隊列，集羣統計，用戶ACL及更多信息
四、在安全模式下，Client Server確保全部來自用戶的請求都已認證過（好比kerberos認證），對於不能經過kerberos認證的，則經過resourcemanager代理令牌進行安全通訊

1.1.二、Administration Service

爲了確保管理員的請求不會被用戶請求所有佔有，提升優先級的操做指令。該組件的的通訊協議是ResourceManagerAdministrationProtocol，主要包括以下一些操做：

一、刷新隊列：好比對隊列的增長，中止，屬性修改
二、刷新ResourceManager節點列表：好比增長和移除節點
三、添加新用戶，添加/更新管理員的ACL，修改超級用戶列表等

1.1.三、Application ACL Manager

管理每一個應用程序的ACL，確保它們獲得實施。能夠配置參數yarn.acl.enable爲true開啓應用程序的ACL

1.1.四、ResourceManager Web Application和WEB Service

ResourceManager有一個web應用程序用來輸出集羣的狀態信息，指標，節點活躍列表，健康，非健康節點列表。應用程序的列表，它們的狀態和結果。

1.二、ResourceManager和應用程序交互通訊

咱們知道應用程序主要有ApplicationMaster進行監控，因此在這裏Resourcemanager與應用程序的交互主要是與ApplicationMaster的交互。

1.2.一、ApplicationMaster Service

該組件響應來自全部的ApplicationMaster的請求，實現了ApplicationMasterProtocol協議。這是ApplicationMaster和Resourcemanager通訊協議，該組件的主要任務以下：

一、註冊新的ApplicationMaster
二、來自任意正在結束的ApplicationMaster的終止/取消註冊請求
三、認證來自不一樣ApplicationMaster的請求，確保只有合法的ApplicationMaster發送請求給ResourceManager中的應用程序
四、獲取來自全部運行ApplicationMaster的container的分配和釋放請求，異步轉發給yarn調度器
五、該組件還確保在任意時候任意ApplicationMaster只有一個線程能夠發送請求給ResourceManager

1.2.二、ApplicationMaster存活監控

   這個監視器跟蹤每一個ApplicationMaster的最後心跳時間，若是在指定時間間隔內（默認10分鐘）沒有產生心跳，則在ResourceManager認爲該ApplicationMaster超時，而且，全部分配給該ApplicationMaster的container也會被標記爲死亡，Resourcemanager會在一個新的container中從新調用一個ApplicationMaster實例，默認兩次重試

1.三、ResourceManager與NodeManager交互通訊

1.3.一、Resource Tracker Service

該組件負責響應來自全部節點的RPC調用（心跳），實現了ResourceTracker接口並和全部的NodeManager通訊。主要負責：

一、註冊新節點
二、接收前面註冊節點的心跳
三、確保只有「合法」的NodeManager和ResourceManager通訊

1.3.二、NodeManager的存活監控

     該組件會跟蹤每個節點的標識符（ID）和它最後的心跳時間，在指定時間間隔（10分鐘）內沒有向Resourcemanager發送心跳，Resourcemanager會認爲該NodeManager死亡，在當前節點的container也會被標記爲死亡，而不糊有新的container在該節點被調度了，一旦該節點從新啓動，並註冊，就回從新參與調度

1.3.三、Nodes-List Manager

    該組件是ResourceManager在內存中的一個集合，包括有效的節點和被排除的節點，經過讀取yarn.resourcemanager.nodes.include-path和yarn.resourcemanager.nodes.exclude-path查看主機配置，根據這些文件初始化節點列表。

1.四、ResourceManager的核心組件

1.4.一、ApplicationManager

   該組件負責管理已提交應用程序的集合，在應用程序提交後，檢查是否合法，是否有節點有足夠的資源運行ApplicationMaster，是有應用程序ID有衝突，若是有一個不符合要求，則會拒絕ApplicationMaster的啓動。

   負責記錄和管理已結束的應用程序，過一段時間才從ResourceManager中清除，保存一個已經結束應用程序的緩存，以便用戶請求這些應用程序的數據，yarn.resourcemanager.max-completed-applications配置存儲已結束的應用程序的最大數量。

1.4.二、ApplicationMaster Launcher

       ResourceManager申請container，並在NodeManager上準備和啓動ApplicationMaster，而其餘的container都是由ApplicationMaster發起的。該組件主要維護一個線程池來設置環境，且和NodeManager通訊拉起提交應用程序的ApplicationMaster。也會在一個程序正常結束做者要強行終止時。負責告訴NodeManager來清理ApplicationMaster--主要是殺掉主要進程

1.4.三、YarnScheduler

    負責給正在運行的應用程序分配資源，是基於應用程序的資源需求來執行調度功能，這些資源包括內存，cpu等，後期會有磁盤以及網絡，GPU等。

1.4.四、ContainerAllocationExpirer

    負責確保Container最終被ApplicationMaster使用，並在相應的NodeManager上拉起，該組件包含一個已分配但尚未在相應的NodeManager上啓動的Container列表，對任意的Container，在指定的時間間隔（默認10分鐘）內，若是相應的NodeManager尚未報告給ResourceManager該Container已經運行，則在ResourceManager中斷定該Container死亡且超時。

1.五、ResourceManager安全相關組件

ResourceManager有一系列的安全組件叫作SecretManager，負責管理令牌和私鑰，這些令牌和私鑰用來對各個RPC接口上的請求進行認證和受權。

1.5.一、ContainerToken SecretManager

    負責管理ContainerToken，ResourceManager提供個ApplicationMaster的一個特殊令牌集合，這樣ApplicationMaster能夠在特定的節點上申請Container，在一個Container啓動以前，咱們不能信任ApplicationMaster傳遞正確的信息到NodeManager。爲了不這個問題，ResourceManager發送給ApplicationMaster以前在Container令牌里加密了Container的相關信息，一個Container的令牌主要包括以下內容：

一、Container ID
二、NodeManager地址
三、應用程序提交者
四、資源（內存，CPU等）
五、超時時間戳
六、主鍵標識符
七、ResourceManager標識符

1.5.二、AMRMToken 祕鑰管理器

    只有ApplicationMaster能夠以Container的形式請求資源，爲了不惡意程序模擬ApplicationMaster請求資源，ResourceManager使用AMRMToken令牌，每個ApplicationAttempt對一個令牌，祕鑰管理器在本地內存中保存每一個令牌知道ApplicationMaster結束，在此期間，能夠用這些令牌認證來自ApplicationMaster進程請求。

1.5.三、NMToken祕鑰管理器

來個啓動Container的請求進行受權，這些請求來自ApplicationMaster。只有在啓動Container而創建的ApplicationMaster到NodeManager的鏈接中有效。

1.5.四、RMDelegationToken 祕鑰管理

該組件是ResourceManager代理令牌的祕鑰管理器，負責給客戶端生成代理令牌，該令牌能夠傳遞給想要和ResourceManager通訊可是沒有通過Kerberos認證的應用程序

1.5.五、RMDelegationToken Renewer

在安全模式下，ResourceManager是經過Kerberos認證的，且提供應用表明程序跟新文件系統令牌服務

2、NodeManager

2.一、主要職責

一、保持與ResourceManager同步
二、跟蹤節點的健康情況
三、管理節點各個Container得我生命週期，監控每一個Container的資源使用狀況
四、管理分佈式緩存（對Container所需的Jar,庫文件的本地文件系統緩存）
五、管理各個Container生成日誌
六、不一樣的yarn應用程序可能須要的輔助服務

2.二、相關組件

2.2.一、NodeStatusUpdater

       在NM剛啓動的時候，該組件會向ResourceManager註冊，發送本節點的可用資源，以及NodeManager的Web Server和RPC Server的監聽端口，在註冊的過程當中，向NodeManager發出安全相關的key，NodeManager將這個key做爲ApplicationMaster的請求Container認證，後續通訊則是向ResourceManager更新Container的信息。而ResourceManager能夠經過該組件通知NodeManager殺死某個正在運行中的Container。只要ResourceManager上的任何應用程序的結束，都會想NodeManager發出信號，要求清理該應用程序在本節點上對應的資源，而後發起應用程序日誌的聚合。

2.2.二、ContainerManager

是NodeManager的核心組件，包含多個子組件，各個子組件分擔管理運行在節點上的Container所須要的功能。

2.2.三、資源本地化服務

負責安全的下載和組織Container所要的各類文件資源，會盡量的將文件分散到各個能夠磁盤上，還強制對下載文件進行訪問控制，並適當加入使用率限制。

2.2.五、Container Launcher

維護一個線程池，用於儘快的準備和拉起Container，以及用於清理須要清理的Container進程

2.2.六、Container Monitor

     在Container的整個運行過程當中監控它的資源使用率，每一個Container都被ResourceManager分配必定的資源，若是Container超出了資源的分配值，該組件就會殺死該Container，避免不受控制的Container影響同一個節點上的正常Container的運行。

2.2.七、Log Handler

保存Container的日誌在本地磁盤上，或者將它們打包上傳到一個文件系統上

2.2.八、Container Executor

與底層操做系統交互，安全的放置Container所須要的文件和目錄，隨後以一個安全的方式啓動和清理Container相關進程

2.2.九、Node Health Check Server

按期運行腳本對接點健康進行檢查，任何健康值的改變都會發給NodeStatusUpdater，並傳給ResourceManager

2.2.十、NodeManager安全組件

Application ACLs Manager：
NodeManager須要對用戶API設置門禁指定某些用戶訪問

ContainerToken SecretManager：
同ResourceManager中的同樣，驗證各類請求，確保Container的請求是ResourceManager受權的

MNToken SecretManager ：
驗證全部來自於API的請求，保證這些請求都是MNToken認證的

Web Server：
展現在給定時間點，一個節點上運行的應用程序和Container列表，節點健康度相關信息，以及Container生成的日誌。

還有些RPC相關組件以及輔助功能的組件。

3、ApplicationMaster

3.一、職責

一、初始化後向ResourceManager報告本身活躍信息的進程
二、計算應用程序的資源需求
三、將資源需求轉換爲yarn調度器能夠識別的ReqsourceReqest
四、與調度器協調申請資源
五、與NodeManager合做使用分配的Container
六、跟蹤Container的狀態，監控它們的進程
七、對Container或節點失敗的狀況進行處理，在必要狀況下從新申請資源

3.二、註冊

一、當ApplicationMaster啓動以後會向ResourceManager進行註冊，在註冊的過程當中，會告訴ResourceManager它本身的IPC地址和網頁URL，IPC地址是面向客戶端的服務地址，URL方便客戶端經過HTTP獲取應用程序的狀態和信息。

二、在相應註冊的時候，ResourceManager會給ApplicationMaster返回一些有用的信息，如Yarn接收資源大小的範圍，與用戶提交應用程序相關的ACL。

三、註冊成功後，ApplicationMaster週期性的向ResourceManager發送心跳確認本身的活躍狀態和將康狀態，若是在指定時間內（默認10分鐘,由參數yarn.am.liveness-monitor.expiry-interval-ms控制）沒有發送心跳給ResourceManager，則認爲中止，將會被殺死，在配置該參數的時候，要考慮這個參數不能大於ApplicationMaster所在該節點失效的時間，節點失效的時間由參數yarn.nm.liveness-monitor.expiry-interval-ms控制，默認也是10分鐘

3.三、資源申請

一、ApplicationMaster成功穩定的運行後，應用程序須要弄清楚本身的資源需求，是動態的呢，仍是靜態的。

靜態資源指的是在提交申請的時候，大多數狀況由客戶端肯定，並且ApplicationMaster運行後就不會改變了。
動態資源指的是在運行的過程當中肯定請求資源的數量。
當資源需求明確後，ApplicationMaster就會發送請求到調度器，而後安排分配的Container進行所需的工做

二、明確資源需求後，ApplicationMaster經過調用API allocate向ResourceManager請求資源，這裏每一個ApplicationMaster中只有一個線程能夠調用API allocate，這些調用在ResourceManager中被串行化，解決多個線程調用請求資源，致使每一個線程看到ResourceManager的全局資源不一致的問題。

三、在請求資源的過程當中，ApplicationMaster經過一系列的resourceAsks，Container ID,或containerToBeReleased的ResourceRequest請求特定的資源，containerToBeReleased指的是以前調度器已經分配可是如今不須要的Container，其中響應信息會包括新分配的Container列表，自從ApplicationMaster和ResourceManager上次的交互完成的應用程序相關Container狀態，集羣可用資源的使用上限。ApplicationMaster能夠根據Container的狀態，收集Container完成的信息，處理失敗的Container。

ApplicationMaster請求和調度資源的方式有兩種：
告知ResourceManager全部的資源需求，讓全局調度器作決定
與ResourceManager交互，讓調度器採起全局調度，並根據資源的可用性和應用程序的業務邏輯性，對分配的Container再一次調度。

四、請求後，ApplicationMaster將收到以Container形式分配的特定節點的資源，基於從ResourceManager獲得的Container，ApplicationMaster能夠爲其執行計劃的一部分的任務分配Container，若是資源不夠用，則ApplicationMaster會繼續請求資源，若是資源知足時，更新請求發送給ResourceManager。

在ApplicationMaster請求資源的過程當中，ApplicationMaster負責計算應用程序的資源需求，並把它們轉換爲調度器可以理解的ResourceRequest對象。該對象會包括以下要素：

一、請求的優先級
二、請求資源的位置，機架，機器名等
三、資源大小，天天Container的大小
四、Container的數目
五、布爾變量（relaxLocality，默認爲true）表示是否本地鬆弛，指本地沒有資源能夠請求同機架的機器資源

四、Container啓動和中止

     在ApplicationMaster獲取到資源以後，就能夠根據需求啓動Container了，可是在啓動Container以前，首先會根據須要構造一個ContainerLauncherContext對象。該對象包含分配資源的大小，安全令牌，啓動Container的命令，進程環境，必要的二進制文件/jar包/共享對象等。該對象與NOdeManager通訊，逐一啓動Container，也能夠批量運行，向NodeManager調用StartContainerRequest來啓動Container。

     NodeManager經過StartContainerResponse迴應，迴應內容主要有：成功啓動的Container列表，每一個失敗的StartContainerRequest對應的Container ID到異常的映射。這樣ApplicationMaster就能獲取到已提交但未啓動的Container以及Container的更新狀態，ApplicationMaster經過與NodeManager交互啓動、中止Container，獲取Container的狀態。

    ApplicationMaster能夠向NodeManager發送StopContainerRequest來中止Container，該請求主要包含：Container ID，NodeManager經過StopContainerResponse迴應，包含成功中止的Container以及每一個失敗請求中Container ID到異常的映射。

當ApplicationMaster退出時，ResourceManager會殺死正在運行沒有被ApplicationMaster顯示終止的Container。

當Container結束時，ResourceManager以事件的形式通知ApplicationMaster，ResourceManager並不關心Container的狀態。

 

更多hadoop生態文章見： hadoop生態系列

 

參考：

《hadoop yarn權威指南》《hadoop技術內幕深刻yarn架構設計與實現原理》