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

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

一、ResourceManager

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

1.1、Resourcemanager和客戶端的互動通訊

1.1.1、Client Service

該服務實現了基本的客戶端到ResourceManager的介面ApplicationClientProtocol。該元件處理所有來自客戶端到Resourcemanager的遠端呼叫（RPC）通訊。主要有如下操作：

1、應用程式的提交

1.1.2、Administration Service

為了確保管理員的請求不會被使用者請求全部佔有，提高優先順序的操作指令。該元件的的通訊協議是ResourceManagerAdministrationProtocol，主要包括如下一些操作：

1、重新整理佇列：比如對佇列的增加，停止，屬性修改
2、重新整理ResourceManager節點列表：比如增加和移除節點

1.1.3、Application ACL Manager

管理每個應用程式的ACL，確保它們得到實施。可以配置引數yarn.acl.enable為true開啟應用程式的ACL

1.1.4、ResourceManager Web Application和WEB Service

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

1.2、ResourceManager和應用程式互動通訊

我們知道應用程式主要有ApplicationMaster進行監控，所以在這裡Resourcemanager與應用程式的互動主要是與ApplicationMaster的互動。

1.2.1、ApplicationMaster Service

該元件響應來自所有的ApplicationMaster的請求，實現了ApplicationMasterProtocol協議。這是ApplicationMaster和Resourcemanager通訊協議，該元件的主要任務如下：

1、註冊新的ApplicationMaster
2、來自任意正在結束的ApplicationMaster的終止/取消註冊請求
3、認證來自不同ApplicationMaster的請求，確保只有合法的ApplicationMaster傳送請求給ResourceManager中的應用程式
4、獲取來自所有執行ApplicationMaster的container的分配和釋放請求，非同步轉發給yarn排程器
5、該元件還確保在任意時候任意ApplicationMaster只有一個執行緒可以傳送請求給ResourceManager

1.2.2、ApplicationMaster存活監控

   這個監視器跟蹤每個ApplicationMaster的最後心跳時間，如果在指定時間間隔內（預設10分鐘）沒有產生心跳，則在ResourceManager認為該ApplicationMaster超時，並且，所有分配給該ApplicationMaster的container也會被標記為死亡，Resourcemanager會在一個新的container中重新呼叫一個ApplicationMaster例項，預設兩次重試

1.3、ResourceManager與NodeManager互動通訊

1.3.1、Resource Tracker Service

該元件負責響應來自所有節點的RPC呼叫（心跳），實現了ResourceTracker介面並和所有的NodeManager通訊。主要負責：

1、註冊新節點
2、接收前面註冊節點的心跳
3、確保只有“合法”的NodeManager和ResourceManager通訊

1.3.2、NodeManager的存活監控

     該元件會跟蹤每一個節點的識別符號（ID）和它最後的心跳時間，在指定時間間隔（10分鐘）內沒有向Resourcemanager傳送心跳，Resourcemanager會認為該NodeManager死亡，在當前節點的container也會被標記為死亡，而不糊有新的container在該節點被排程了，一旦該節點重新啟動，並註冊，就回重新參與排程

1.3.3、Nodes-List Manager

    該元件是ResourceManager在記憶體中的一個集合，包括有效的節點和被排除的節點，通過讀取yarn.resourcemanager.nodes.include-path和yarn.resourcemanager.nodes.exclude-path檢視主機配置，根據這些檔案初始化節點列表。

1.4、ResourceManager的核心元件

1.4.1、ApplicationManager

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

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

1.4.2、ApplicationMaster Launcher

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

1.4.3、YarnScheduler

    負責給正在執行的應用程式分配資源，是基於應用程式的資源需求來執行排程功能，這些資源包括記憶體，cpu等，後期會有磁碟以及網路，GPU等。

1.4.4、ContainerAllocationExpirer

    負責確保Container最終被ApplicationMaster使用，並在相應的NodeManager上拉起，該元件包含一個已分配但還沒有在相應的NodeManager上啟動的Container列表，對任意的Container，在指定的時間間隔（預設10分鐘）內，如果相應的NodeManager還沒有報告給ResourceManager該Container已經執行，則在ResourceManager中判定該Container死亡且超時。

1.5、ResourceManager安全相關元件

ResourceManager有一系列的安全元件叫做SecretManager，負責管理令牌和私鑰，這些令牌和私鑰用來對各個RPC介面上的請求進行認證和授權。

1.5.1、ContainerToken SecretManager

    負責管理ContainerToken，ResourceManager提供個ApplicationMaster的一個特殊令牌集合，這樣ApplicationMaster可以在特定的節點上申請Container，在一個Container啟動之前，我們不能信任ApplicationMaster傳遞正確的資訊到NodeManager。為了避免這個問題，ResourceManager傳送給ApplicationMaster之前在Container令牌里加密了Container的相關資訊，一個Container的令牌主要包括如下內容：

1、Container ID
2、NodeManager地址
3、應用程式提交者
4、資源（記憶體，CPU等）
5、超時時間戳
6、主鍵識別符號
7、ResourceManager識別符號

1.5.2、AMRMToken 祕鑰管理器

    只有ApplicationMaster可以以Container的形式請求資源，為了避免惡意程式模擬ApplicationMaster請求資源，ResourceManager使用AMRMToken令牌，每一個ApplicationAttempt對一個令牌，祕鑰管理器在本地記憶體中儲存每個令牌知道ApplicationMaster結束，在此期間，可以用這些令牌認證來自ApplicationMaster程序請求。

1.5.3、NMToken祕鑰管理器

來個啟動Container的請求進行授權，這些請求來自ApplicationMaster。只有在啟動Container而建立的ApplicationMaster到NodeManager的連線中有效。

1.5.4、RMDelegationToken 祕鑰管理

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

1.5.5、RMDelegationToken Renewer

在安全模式下，ResourceManager是通過Kerberos認證的，且提供應用代表程式跟新檔案系統令牌服務

二、NodeManager

2.1、主要職責

1、保持與ResourceManager同步
2、跟蹤節點的健康狀況
3、管理節點各個Container得我生命週期，監控每個Container的資源使用情況
4、管理分散式快取（對Container所需的Jar,庫檔案的本地檔案系統快取）
5、管理各個Container生成日誌
6、不同的yarn應用程式可能需要的輔助服務

2.2、相關元件

2.2.1、NodeStatusUpdater

       在NM剛啟動的時候，該元件會向ResourceManager註冊，傳送本節點的可用資源，以及NodeManager的Web Server和RPC Server的監聽埠，在註冊的過程中，向NodeManager發出安全相關的key，NodeManager將這個key作為ApplicationMaster的請求Container認證，後續通訊則是向ResourceManager更新Container的資訊。而ResourceManager可以通過該元件通知NodeManager殺死某個正在執行中的Container。只要ResourceManager上的任何應用程式的結束，都會想NodeManager發出訊號，要求清理該應用程式在本節點上對應的資源，然後發起應用程式日誌的聚合。

2.2.2、ContainerManager

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

2.2.3、資源本地化服務

負責安全的下載和組織Container所要的各種檔案資源，會盡可能的將檔案分散到各個可以磁碟上，還強制對下載檔案進行訪問控制，並適當加入使用率限制。

2.2.5、Container Launcher

維護一個執行緒池，用於儘快的準備和拉起Container，以及用於清理需要清理的Container程序

2.2.6、Container Monitor

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

2.2.7、Log Handler

儲存Container的日誌在本地磁碟上，或者將它們打包上傳到一個檔案系統上

2.2.8、Container Executor

與底層作業系統互動，安全的放置Container所需要的檔案和目錄，隨後以一個安全的方式啟動和清理Container相關程序

2.2.9、Node Health Check Server

定期執行指令碼對接點健康進行檢查，任何健康值的改變都會發給NodeStatusUpdater，並傳給ResourceManager

2.2.10、NodeManager安全元件

Application ACLs Manager：
NodeManager需要對使用者API設定門禁指定某些使用者訪問

ContainerToken SecretManager：
同ResourceManager中的一樣，驗證各種請求，確保Container的請求是ResourceManager授權的

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

Web Server：
展示在給定時間點，一個節點上執行的應用程式和Container列表，節點健康度相關資訊，以及Container生成的日誌。

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

三、ApplicationMaster

3.1、職責

1、初始化後向ResourceManager報告自己活躍資訊的程序
2、計算應用程式的資源需求
3、將資源需求轉換為yarn排程器可以識別的ReqsourceReqest
4、與排程器協調申請資源
5、與NodeManager合作使用分配的Container
6、跟蹤Container的狀態，監控它們的程序
7、對Container或節點失敗的情況進行處理，在必要情況下重新申請資源

3.2、註冊

1、當ApplicationMaster啟動之後會向ResourceManager進行註冊，在註冊的過程中，會告訴ResourceManager它自己的IPC地址和網頁URL，IPC地址是面向客戶端的服務地址，URL方便客戶端通過HTTP獲取應用程式的狀態和資訊。

2、在相應註冊的時候，ResourceManager會給ApplicationMaster返回一些有用的資訊，如Yarn接收資源大小的範圍，與使用者提交應用程式相關的ACL。

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

3.3、資源申請

1、ApplicationMaster成功穩定的執行後，應用程式需要弄清楚自己的資源需求，是動態的呢，還是靜態的。

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

2、明確資源需求後，ApplicationMaster通過呼叫API allocate向ResourceManager請求資源，這裡每個ApplicationMaster中只有一個執行緒可以呼叫API allocate，這些呼叫在ResourceManager中被序列化，解決多個執行緒呼叫請求資源，導致每個執行緒看到ResourceManager的全域性資源不一致的問題。

3、在請求資源的過程中，ApplicationMaster通過一系列的resourceAsks，Container ID,或containerToBeReleased的ResourceRequest請求特定的資源，containerToBeReleased指的是之前排程器已經分配但是現在不需要的Container，其中響應資訊會包括新分配的Container列表，自從ApplicationMaster和ResourceManager上次的互動完成的應用程式相關Container狀態，叢集可用資源的使用上限。ApplicationMaster可以根據Container的狀態，收集Container完成的資訊，處理失敗的Container。

ApplicationMaster請求和排程資源的方式有兩種：
告知ResourceManager所有的資源需求，讓全域性排程器做決定
與ResourceManager互動，讓排程器採取全域性排程，並根據資源的可用性和應用程式的業務邏輯性，對分配的Container再一次排程。

4、請求後，ApplicationMaster將收到以Container形式分配的特定節點的資源，基於從ResourceManager得到的Container，ApplicationMaster可以為其執行計劃的一部分的任務分配Container，如果資源不夠用，則ApplicationMaster會繼續請求資源，如果資源滿足時，更新請求傳送給ResourceManager。

在ApplicationMaster請求資源的過程中，ApplicationMaster負責計算應用程式的資源需求，並把它們轉換為排程器能夠理解的ResourceRequest物件。該物件會包括如下要素：

1、請求的優先順序
2、請求資源的位置，機架，機器名等
3、資源大小，每天Container的大小
4、Container的數目
5、布林變數（relaxLocality，預設為true）表示是否本地鬆弛，指本地沒有資源可以請求同機架的機器資源

4、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架構設計與實現原