1 ResourceManager元件

1.1 客戶端和ResourceManager互動

使用者和平臺第一互動點為客戶端和ResourceManager的互動，涉及以下元件

1.1.1 Client Service

該元件處理所有客戶端到ResourceManager的遠端過程呼叫（RPC）通訊，包括：

• 應用程式提交
• 應用程式終止
• 獲取應用程式、佇列、叢集統計、使用者ACL及更多資訊

ClientService在安全模式下確保使用者請求都經過認真，且通過訪問控制列表對使用者進行授權。不支援認證的客戶端也提供了ResourceManager代理令牌

1.1.2 Administration Service

管理員的操作需要比一般使用者優先順序更高，因此設計該介面，可以處理以下的操作：

• 重新整理佇列，例如增加新佇列，停止佇列，重新配置佇列等
• 重新整理ResourceManager處理的節點列表，例如節點的安裝或退役
• 新增新使用者組，新增、更新管理員ACL，修改超級使用者列表

1.1.3 Application ACL Manager

管理每個應用程式的ACL，使用者可以通過ApplicationSubmissionContext資訊的一部分指定ACL

1.2 應用程式和ResourceManager的通訊

應用程式被接納後，它負責拉起ApplicationMaster的狀態機，ApplicationMaster啟動後和ResourceManager通過以下元件通訊

1.2.1 ApplicationMaster Service

負責響應ApplicationMaster的所有請求，實現ApplicationMasterProtocol協議，負責以下任務：

• 註冊ApplicationMaster
• ApplicationMaster的終止、取消註冊請求
• 認證ApplicationMaster的所有請求
• 獲取ApplicationMaster的Container分配和釋放請求，轉發給YARN排程器

ApplicationMaster Service保證ApplicationMaster任意時間點只有一個執行緒向ResourceManager傳送請求

1.2.2 ApplicationMaster存活監控

跟蹤每個ApplicationMaster以及它最後的心跳時間，超過設定值沒有心跳的ApplicationMaster被認為死亡

1.3 節點和ResourceManager的通訊

ResourceManager和節點通訊涉及的元件如下

1.3.1 Resource Tracker Service

個人感覺類似於ApplicationMaster Service，主要負責：

• 註冊新節點
• 接收前面註冊節點的心跳
• 確保只有合法節點和ResourceManager通訊

新節點註冊後，ResourceManager傳送安全相關的主鍵，NodeManager需要驗證ApplicationMaster提交的NodeManager令牌和Container令牌，主鍵會滾動更新，在心跳中NodeManager會獲得這些更新

Rosource Tracker Service轉發合法的心跳給YARN排程器，YARN排程器根據資源請求做排程決定

1.3.2 NodeManager存活監控

跟蹤每個節點的識別符號和最後心跳資訊，最後心跳時間超時的節點被標記為死亡

1.3.3 Nodes-List Manager

是ResourceManager記憶體中的一個集合，包括有效的節點和被排除的節點

1.4 ResourceManager核心元件

除了與外界通訊的不同元件，還有一些核心元件如下

1.4.1 ApplicationsManager

負責管理已經提交的應用程式集合。檢查應用程式規格，拒絕資源請求不合法的應用，然後確定應用程式ID是否已經被使用，最後把應用程式轉給排程器

該元件還負責記錄管理結束的應用程式，在日誌中記錄ApplicationSummary

儲存一個已結束應用程式的快取，以便使用者請求應用程式的資料

1.4.2 ApplicationMaster Launcher

ApplicationMaster本身的Container是ResourceManager申請並在NodeManager上拉起的，該元件維護一個執行緒池且和NodeManager通訊來拉起Applicationmaster（新的或之前失敗的ApplicationMaster），它也在應用結束時告訴NodeManager清理ApplicationMaster

1.4.3 YarnScheduler

YARN排程器給執行的應用程式分配資源，預設排程器為Capacity排程器

1.4.4 ContainerAllocationExpirer

為防止惡意程式申請Container而不使用，該元件包含一個分配但未啟動的Container列表，超時不啟動的Container被判定為死亡

1.5 ResourceManager安全相關的元件

安全元件負責管理令牌和私鑰，對各個RPG介面的請求進行認證和授權

1.5.1 ContainerToken SecretManager

管理Container令牌，該令牌通過ApplicationMaster路由到NodeManager以防直接傳送給NodeManager帶來的顯著延遲（只有Container分配後，ResourceManager才能生成ContainerToken）

ApplicationMaster可能傳遞錯誤資訊給NodeManager偽造CPU或核心數量，因此ResourceManager在Container令牌里加密了Container相關資訊，令牌包括下面欄位：

• Container ID: Container的唯一識別符號，NodeManager使用該資訊與應用程式繫結，防止另外一個應用啟動該Container
• NodeManager地址: 目標NodeManager的地址，避免應用程式去不相關的NodeManager上啟動Container
• 應用程式提交者: 使用者名稱，NodeManager以這個使用者身份執行所有Container相關活動
• 資源: 通知NodeManager關於Container的每一個資源總量
• 超時時間戳: 檢視這個時間戳決定Container令牌是否仍然合法
• 主鍵識別符號: NodeManager用來驗證Container令牌。ResourceManager生成一個金鑰並和NodeManager共享，金鑰滾動更新，NodeManager記住新舊金鑰，根據主鍵識別符號確定正確的金鑰
• ResourceManager識別符號: 如果在分配Container後，ApplicationMaster重啟了，為了確保NodeManager區分新舊ResourceManager而有的欄位

1.5.2 AMRMToken金鑰管理器

為防止惡意程式模仿一個ApplicationMaster傳送排程請求，ResourceManager使用AMRMToken令牌認證ApplicationMaster的請求

1.5.3 NMToken金鑰管理器

ApplicationMaster使用NMToken管理跟一個NodeManager的連線，該令牌由ResourceManager生成

1.5.4 RMDelegation Token金鑰管理器

負責給客戶端生成令牌，由此令牌和ResourceManager通訊

1.5.5 DelegationToken Renewer

在安全模式下，ResourceManager通過Kerberos認證，且提供代表應用程式更新檔案系統令牌的服務，該元件負責在應用程式執行期間更新應用程式的令牌（不理解，存疑，待日後研究）

2 NodeManager元件

2.1 NodeStatusUpdater

負責和ResourceManager通訊

NodeManager剛啟動時，該元件向ResourceManager註冊，傳送本節點的可用資源、Web Server和RPC Server的監聽埠。ResourceManager傳送用於驗證Container的KEY。後續該元件還繼續向ResourceManager提供Container的相關資訊

ResourceManager還可以通過該元件通知NodeManager殺死Container。當應用程式結束時，ResourceManager都會通知NodeManager清理應用程式的資源，發起日誌聚集

2.2 ContainerManager

NodeManager的核心元件

2.2.1 RPC Server

負責和ApplicationMaster通訊

接受ApplicationMaster關於Container的請求，和其他安全模組協同對請求進行認證和鑑權。記錄Container的所有操作，並記錄日誌。

2.2.2 資源本地化服務

下載Container需要的檔案資源，儘可能將檔案分散到各個可用磁碟上，還對下載檔案進行訪問控制和使用率控制。PUBLIC的資原始檔儲存在公共快取，通過一組稱為Public-Localizer的執行緒池處理，該執行緒池執行在NodeManager內部的地址空間。PRIVATE的資源儲存在使用者快取內，通過ContainerLocalizer的獨立程序完成，並不在NodeManager內部完成

2.2.3 Containers Launcher

維護用於準備及拉起Container的執行緒池，該元件也負責Container的清理工作，每個Container操作都由一個執行緒獨立完成，因此一個NodeManager內的所有Container是隔離的

2.3 輔助服務

可以在NodeManager啟動前配置一組可插拔的輔助服務，例如，Map和Reduce任務間傳輸中間資料的ShuffleHandler。當應用程式的第一個Container啟動、任何Container啟動或完成、應用程式完成時，都要通知輔助服務

2.3.1 Containers Monitor

監控Container執行過程中的資源使用率，超出資源分配值的Container會被該元件殺掉

2.3.2 Log Handler

儲存Container日誌在本地磁碟或上傳檔案系統

2.3.3 Container Executor

放置Container需要的檔案和目錄，啟動和清理Container相關程序

2.3.4 Node Health Checker Service

檢測節點健康度，通過NodeStatusUpdater傳遞給ResourceManager

2.4  安全元件

2.4.1 Application ACLs Manager

維護ACL

2.4.2 ContainerToken SecretManager

驗證啟動Container的請求是否合法（顧名思義應該是通過Token）

2.4.3 NMToken SecretManager

通過NMToken驗證所有來自API的請求

2.4.4 Web Server

展示在給定時間點的應用程式、Container列表、節點健康、Container日誌等（應該是平時用於查詢的網頁端業務組價）

3 ApplicationMaster

3.1 功能概述

應用程式被提交後在ResourceManager中申請一個Container來啟動引導程序。一旦分配了Container，ApplicationMaster的啟動器將直接與NodeMaanger通訊來啟動該Container，整個ApplicationMaster生命週期內的與其他部分互動如圖所示，注意ApplicationMaster本身也是一個Container

更詳細的敘述上篇博文已經寫過https://blog.csdn.net/jiangxuege/article/details/81558975

3.2 活躍

ApplicationMaster的第一個操作是向ResourceManager註冊，告知ResourceManager它的IPC地址和網頁URL。ResourceManager返回YARN接受的資源大小範圍、應用程式的ACL等資訊

註冊成功後，ApplicationMaster需要傳送心跳資訊，心跳資訊超時會被ResourceManager認為停止執行並被殺死

3.3 資源需求

應用程式需要的資源分為靜態和動態

在提交申請時能確定，且ApplicationMaster執行後不會產生變化的資源稱為靜態資源，否則稱為動態資源

資源需求明確後，ApplicationMaster傳送請求到ResourceManager的排程器請求分配Container

3.4 排程

ApplicationMaster積累足夠資源請求或計時器超時，就通過API allocate向ResourceManager傳送心跳（不知道這裡為什麼又不以元件的方式講了），任何時刻只有一個執行緒可以呼叫allocate

ApplicationMaster通過ResourceRequest請求特定資源，ResourceRequest可能包含resourceAsks、Container ID或containersToBeReleased（先前從排程器分配但現在不再需要的Container）。響應資訊包含新分配的Container列表、自ApplicationMaster和ResourceManager上次互動以來完成的應用程式相關的Container狀態、叢集中可用資源。ApplicationMaster可以根據Container的相關資訊進行相關操作，還可以根據叢集資源調節未來資源請求

ApplicationMaster有兩種方式請求排程資源：

• 告知ResourceManager所有的資源請求，讓全域性排程器做所有決定
• 動態互動，讓排程器採取全域性排程，並根據資源可用性和應用程式業務邏輯，對分配的Container再做一次排程。例如，MapReduce的ApplicationMaster收到一個Container時，將該Container與待執行的Map任務匹配，首先嚐試資料本地區域性性的任務，然後嘗試有機架區域性性的任務（不理解，存疑，是否是ApplicationMaster自己承擔了一部分排程任務）

3.5 排程協議

資源請求時ResourceRequest包含以下要素：

• 請求的優先順序
• 資源被分配的位置，即機器名和機架名
• 資源大小
• Container數目
• relaxLocality，布林值，決定Container是否必須嚴格遵循資源分配位置

3.6 啟動Container

啟動Container前構造ContainerLaunchContext物件，該物件包括分配資源的大小、安全令牌、啟動Container的執行命令、程序環境、必要檔案等。ApplicationMaster通過NodeManager通訊，逐一啟動Container，也可以批量執行

NodeManager通過StartContainerResponse迴應，該回應包含啟動成功的Container列表、失敗的Container ID異常、allServicesMetaData對映（附加服務的名字到它們相應的元資料，這是個啥，不明）

ApplicationMaster可以向NodeManager傳送StopContainersRequest，NodeManager通過類似的StopContainersResponse迴應，該回應包含成功停止的Container列表、每個失敗請求的Container ID異常

ApplicationMaster退出時，ResourceManager殺死所有正在執行的Container

3.7 完成的Container

ResourceManager以事件形式通知ApplicationMaster某個Container結束，ApplicationMaster收集已完成的Container資訊並進行後續處理

3.8 協調和輸出提交

框架如果支援多個Container爭奪資源或輸出提交，ApplicationMaster為他們提供同步原語，以便只有一個Container搶佔資源或輸出

3.9 退出時清理

ApplicationMaster完成工作後，向ResourceManager傳送FinishApplicationRequest登出，然後做一些清理工作

4 YARN Container

4.1 Container執行環境

YARN中的Container代表在應用中的一個工作單元（說好的一種資源分配的形式呢），根據執行時是否可以解析，Container包括的資訊分為靜態資訊和動態資訊

靜態資訊如下：

• ApplicationMaster在ContainerLaunchContext（CLC）中描述Container啟動時所需庫和依賴，Container啟動時，這些依賴已經通過NodeManager的本地化模組下載
• 輸入、輸出路徑和檔案系統URL是配置的一部分，可以通過環境變數、命令列引數、本身作為本地資源傳來的配置檔案配置
• 環境變數ApplicationConstants.Environment.LOCAL_DIRS可以決定Container輸出目錄
• 環境變數ApplicationConstants.LOG_DIR_EXPANSION_VAR指向日誌目錄
• API ApplicationConstants.Environment儲存了NodeManager記錄下的使用者名稱、主目錄、Container ID等資訊，Container可以檢視這些資訊
• 環境變數ApplicationConstants.CONTAINER_TOKEN_FILE_ENV_NAME指向了儲存安全令牌的檔案

動態資訊如下：

• ApplicationMaster的URL在故障恢復時會動態變化，可以與ResourceManager通訊得到
• ApplicationMaster可以協調Container的輸出位置以及相應的輔助服務，並向Container提供這些資訊
• HDFS NameNode的位置在故障恢復後變化，可以通過配置來查詢NameNode位置

4.2 與ApplicationMaster通訊

Container並不向NodeManager彙報任何資訊，也不需要向ApplicationMaster彙報資訊，很多情況下Container只是獨立地執行。如果應用程式需要通訊，則需要將Container配置成某種程序間通訊，與ApplicationMaster互動