在之前的Hadoop版本中，是不存在ResourceManager, NodeManager的概念的，此時，只有JobTracker以及TaskTracker的概念。
但是，此時，在功能上，耦合度很高。YARN作為一個資源調度平臺，卻不是一個通用的平臺，而是緊緊和MapReduce結合在一起。
后來，Hadoop的開發團隊終于意識到，應當把YARN和MapReduce的實現獨立出來，讓YARN能夠作為一個通用的資源調度平臺。
而當Hadoop的開發團隊把YARN抽離出來之后，之后YARN就是一片欣欣向榮的景象了。后來出現的好多分布式調度系統，都支持在YARN上進行調度。比如，Spark就同時支持YARN，Mesos等。
所以，在這篇文章中，我們將會介紹，再將YARN單獨抽離出來之后，形成的三個組件-ResourceManager, NodeManager以及ApplicationMaster，它們各自的職責。
ResourceManager
YARN中，最重要的一個組件就是ResourceManager。實際上，嚴格來說，YARN只包含兩個組件，ResourceManager以及NodeManager。而ApplicationMaster只是一個YARN的客戶端。所以，在YARN中，實際上是不信任ApplicationMaster的。因為ApplicationMaster可以由用戶自己實現，可能存在危險。
ResourceManager包含了很多組件，我們將它們分成幾大類，和Client進行交互的組件，和ApplicationMaster交互的組件，和NodeManager交互的組件，其他核心組件，以及和安全相關的組件。
和Client進行交互的組件
ClientRMService: 這個組件，是用于接收Client的請求的一個組件。舉例來說，我們編寫的Job，在提交到ResourceManager上運行的時候，實際上就是和ClientService進行交互的。
AdminService: 這個組件，用于接收來自Administrator的請求。為什么不把它和前面的ClientRMService放在一起呢？因為對于ClientRMService來說，可能會存在太多請求而導致請求遲遲得不到處理。但是，對于Administrator的請求來說，是不能出現這種情況的。于是，就把它們兩個分開來。
ApplicationACLsManager: 這個組件，是用于驗證Client提交的Application的。它會驗證用戶是否有權限執行操作等。
RMWebApp: 這個組件用于提供一個Web界面，其中包含了Application信息，集群中可用資源等信息。各位應該對這個界面都不陌生。
和ApplicationMaster交互的組件
-
ApplicationMasterService: 這個組件，會接收ApplicationMaster發送來的信息。主要有以下幾個:
- ApplicationMaster的注冊信息
- 驗證ApplicationMaster發送來的請求
- 從ApplicationMaster接收分配和釋放資源的請求，并轉發給YarnScheduler
AMLivelinessMonitor: 這個組件會接收ApplicationMaster的心跳信息，來確認ApplicationMaster是否還存活。如果在設置的檢測間隔內沒有受到來自ApplicationMaster的心跳信息，那么就會認為這個ApplicationMaster已經掛掉了。然后，會重啟一個ApplicationAttempt并重新調度它。
和NodeManager交互的組件
- ResourceTrackerService: NodeManager會不斷地向ResourceManager發送心跳信息，這個組件就是接收這些信息的。它會做這么幾件事：
- 注冊新的Node
- 從注冊過的Node上，接收心跳信息
- 確保只有有效的Node能夠和ResourceManager進行交互
在注冊了一個新的Node之后, ResourceManager就會給NodeManager發送一個和安全性相關的master key。然后，NodeManager用這個master key來驗證ApplicationMaster發送給他的分配Container的請求。
這個master key也不是會一直不變的，為了防止惡意的ApplicationMaster破解master key并向NodeManager提交惡意的Container，所以這個master key會每隔一段時間變一次，并發送給NodeManager.
ResourceTrackerService會將有效的heartbeat轉發給YARNScheduler,然后YARNScheduler會根據集群中可用的資源，進行容器的分配。
NMLivelinessMonitor: 這個組件，會根據NodeManager最后發送的heartbeat的時間，以及設置好的檢測間隔，進行Node的有效性檢查。一旦認為某個Node已經過期了，那么就會將在這個Node上運行的Container標記為dead狀態，并在其他的正常的節點上進行調度。一旦一個Node已經過期，那么就不會再為這個Node分配任何容器。直到它恢復正常。
NodeListManager: 這個組件維護著一個Node白名單以及Node黑名單。啟動時，它們分別被從'yarn.resourcemanager.nodes.include-path'以及'yarn.resourcemanager.nodes.exclude-path'中讀取。當一個白名單中的Node被Administrator手動撤銷，那么它就會進入到Node黑名單中。
其他核心組件
除了上面我們已經介紹的一些組件，還有一些比較核心的組件。
- ApplicationsManager: 這個組件維護著一個可以Application的列表。當一個Client提交一個Application的時候，ResourceManager首先會驗證，這個Application需要的資源是否不合適，然后驗證這個Application是否已經被加載過了。最終，ResourceManager會將它提交到Scheduler.
這個組件也負責在一個Application完成后以及被完全清理之前，管理它們。當一個Application完成后，它會生成一個ApplicationSummary，并將它記錄到daemon的日志文件中。
ResourceManager中有一個屬性-'yarn.resourcemanager.max-completed-applications'，這個屬性控制ResourceManager最多能夠維護多少個已經完成但沒有被清理的Application。這就相當于一個FIFO隊列，一旦超過了這個閾值，最早的Application就會被從這個隊列中清除。
- ApplicationMasterLauncher: 即使在YARN中，Container的加載，都是由ApplicaitonMaster告訴NodeManager，來加載的。但是，對于ApplicationMaster這個容器，比較特殊，它是由ResourceManager直接告訴NodeManager去加載的。而ApplicationMasterLauncher就是負責這個工作的。
在ApplicationMasterLauncher的內部，有一個線程池，用于啟動ApplicationMaster。它不僅會為新提交的Application啟動ApplicationMaster，也會為那些失敗的ApplicationAttempt重啟一個ApplicationMaster。在一個Application完成后，它也負責告訴NodeManager來清理ApplicationMaster.
YarnScheduler: 這個組件負責將Application分配到對應的隊列上。它會基于CPU，內存，磁盤等進行調度。
ContainerAllocationExpirer: 這個組件用于確保為ApplicationMaster分配的Container,都會被加載。
由于ApplicationMaster是不被信任的，它可能會申請任意多的Container，而并不分配，只是惡意的導致ResourceManager無法為新的Application分配Container.
所以，這個組件如果在一段時間之內，不能從NodeManager上，接收到ResourceManager已經分配的Container的heartbeat，就會認為這個Container已經掛掉了，并告訴ResourceManager讓這個Container過期。
另外，一個容器的過期時間，也會被編碼到和Container相對應的ContainerToken中，并一同發送給NodeManager。這樣可以防止NodeManager來加載已經過期的容器。
但是，我們也可以看到，除非NodeManager和ResourceManager的時鐘同步，否則這會導致一些我們不希望看到的錯誤。
和安全相關的組件
- RMContainerTokenSecretManager: 這個組件，負責為Container生成ContainerToken，并維護這些信息。
ContainerToken中維護著和這個Container相關的一些信息，并且被加密過。由于ApplicationMaster是不被信任的，所以我們需要ContainerToken，讓NodeManager來驗證這個Container是否確實是ResourceManager分配的，以及是否確實就是在這個NodeManager上運行的，等其他信息。
ContainerToken中，包含下面的信息:
Container ID
NodeManager address
Application submitter
Resource
Expiry timestamp
Master key identifier: ResourceManager生成的一個安全密鑰
ResourceManager identifier: 由于在ResourceManager分配給ApplicationMaster容器之后，以及這個容器被從NodeManager啟動之前，ResourceManager可能掛掉并啟動了一個新的。為了避免這種情況，就需要ResourceManager將它的ID也編碼到ContainerToken中。如果一個NodeManager重啟，它會停掉之前運行的所有的Container，NodeManager也會拒絕運行由以前的ResourceManager分配的Container.
AMRMTokenSecretManager: 這個組件為每個ApplicationMaster都生成一個Token。ResourceManager會通過這個Token驗證每個來自ApplicationMaster的請求。
ApplicationMaster可以通過本地化過的文件，'ApplicationConstants.CONTAINER_TOKEN_FILE_ENV_NAME'，來獲得這個Token文件。
NMTokenSecretManager: ApplicationMaster通過NMToken來和NodeManager進行通訊。
RMDelegationTokenSecretManager: 這個組件負責為Client生成一個token.
DelegationTokenManager: 這個組件負責在Kerberos驗證中，為已提交的Application生成一個新的Token.
ResourceManager總結
從上面的組件我們可以看到，ResourceManager的主要功能，就是分配ApplicationMaster，為ApplicationMaster分配容器，以及監控NodeManager的狀態和集群中的可用資源。
NodeManager
NodeManager的任務包括：
- 和ResourceManager保持同步
- 跟蹤Node的狀態
- 監控Container的生命周期，監控Container使用的資源
- 管理Distributed Cache
- 管理Container生成的日志
- 執行一些可能被不同的YARN application使用到的輔助的Service
在NodeManager注冊到ResourceManager之后，它就會不間斷的向ResourceManager發送heartbeat，如果ResourceManager有需要它執行的指令，就作為響應發送給它。
在ResourceManager收到NodeManager的heartbeat并處理完之后，對應這個NodeManager的Container，就會在下一次ApplicationMaster給ResourceManager發送heartbeat時，作為ResourceManager的響應，發送給ApplicationMaster.
在NodeManager加載一個Container之前，它需要本地化需要的Resource，包括數據文件，可執行文件，shell script等。這些Resource可能有能夠在不同用戶之間共享的Resource，有能夠在相同用戶不同Application之間共享的Resource，以及只能夠被這一個Container使用的Resource.
NodeManager也可以在ResourceManager的指示下，殺掉Container。當處于下面的幾種場景中時，NodeManager就可能Kill掉一個Container:
- ResourceManager告訴它，Application已經完成了
- Scheduler決定搶占這個Container，并將它分配給另一個Application或者用戶
- NodeManager檢測到，這個Container使用的資源已經超過了ContainerToken中指定的那些資源的限制
當一個Container完成時，NodeManager會清除它在本地存儲的數據。當一個Application完成時，NodeManager會刪除全部跟它相關的Container的數據。
NodeManager組件
- NodeStatusUpdater: 在一個NodeManager被注冊到ResourceManager時，這個NodeManager會告訴ResourceManager一些信息，比如NodeManager上Web Server以及RPC Server監聽的端口。而ResourceManager會告訴NodeManager一些和安全相關的信息，比如，master key，NodeManager用它來驗證ApplicationMaster提交給它的Container.
在NodeManager注冊完以后，在后面的通訊中，NodeStatusUpdater會告訴ResourceManager，NodeManager上的Container的狀態，NodeManager上剛啟動的Container，以及完成的Container.
ResourceManager也可以通過和這個組件的溝通，讓NodeManager Kill掉一個Container。
當一個Application結束后，ResourceManager會告訴NodeManager來清理掉和Application相關的一切信息。并且會將每個Application的日志聚合到一個文件系統中。
- ContainerManager: 這個組件又包含了幾個其他的部分：RPC Server, Web Server, ResourceLocalizationService, ContainersLauncher, AuxServices, ContainersMonitor, LogHandler.
其中RPC Server接收來自ApplicationMaster的請求，來運行或者停止一個Container。
ResourceLocalizationService會將Resource進行本地化，根據不同的Resource visibility - PUBLIC, APPLICATION, PRIVATE，會執行不同的本地化操作。
ContainersLauncher內部維護了一個線程池，來準備并且啟動Container。當RPC Server接收到一個Clean up的請求，或者NodeStatusUpdater接收到一個Clean up的請求，它也會對Container進行 Clean up的操作。每個啟動或者Clean up的操作，都是在一個線程中執行的，并且直到對應的操作完成才會返回。所以，不同Container之間是相互不影響的。
AuxiliaryServices是一些可插拔的Services。有的時候，NodeManager上的現有的Services不能完全滿足我們的需求，比如，我們上面提到過，在一個Container完成之后，NodeManager會清理掉它占用的本地資源。在MapReduce中，這明顯不合理，Mapper的輸出還要傳送給Reducer呢。
所以，YARN通過這樣一種方式，讓我們可以自己配制一些Service，來增強它的功能。
AuxiliaryServices，會在Application第一次啟動Container，每個Container的啟動和結束，以及Application完成時收到通知，并執行其中預定義的操作。
在一個Container啟動時，AuxiliaryServices相關的信息，會返回給ApplicationMaster。這樣，ApplicationMaster就能夠接收AuxliaryServices中我們希望它知道的信息。比如，在MapReduce中，會通過這種方式獲得ShuffleHandler的端口信息。
ContainersMonitor會監控Container占用的資源是否超過了給它配制的最大值，如果是，則將它Kill掉。
Log Handler負責決定是在這個NodeManager保存Container的日志，還是將它壓縮打包之后，上傳到某個文件系統上。
ContainerExecutor: 負責從操作系統層面啟動Container。
NodeHealthCheckerService: 這個組件會通知經常執行預先配制的檢查腳本，來檢查Node是否有問題。此外，它還可以通過創建臨時文件的方式，檢查Node的磁盤是否有問題。每一次這個信息修改，都會被發送給NodeStatusUpdater。最后被發送給ResourceManager.
ContainerTokenSecretManager: 用于驗證ApplicationMaster讓NodeManager啟動的Container,都經過ResourceManager驗證過。
Web Server: 提供一個Web界面，里面包含了Application列表，Node狀態，Container日志等信息。
ApplicationMaster
一旦ApplicationMaster成功啟動后，那么它就要做這些事情：
- 和ResourceManager保持連接，定期向ResourceManager發送heartbeat
- 計算一個Application需要的Resource
- 通過ResourceRequest的形式，跟ResourceManager溝通，讓ResourceManager給它分配Container
- 和NodeManager溝通來加載Container
- 跟蹤Container的狀態
- 處理Container故障或者Node故障的問題
當ApplicationMaster注冊到ResourceManager時，它可以向ResourceManager發送IPC address或者Web URL. 而ResourceManager作為響應，會返回給它一些它需要的信息，比如，ResourceManager能夠接受的最小以及最大的Resource的限制, Application的ACL等。
在ApplicationMaster成功注冊到ResourceManager之后，它就需要不間斷地向ResourceManager發送心跳信息，保證ResourceManager知道它還存活。
如果ApplicationMaster積累了足夠多的ResourceRequest，或者已經到了再次發送heartbeat的時候了，那么它就會通過heartbeat信息，將這些ResourceRequest發送給ResourceManager.
ResourceRequest是ApplicationMaster發送給ResourceManager的用于請求Resource的一個數據結構。它包含了:
- Priority of the request
- Resource location。當前接受一臺主機的名稱或者一個機架的名稱。有一個比較特殊的值，"*"代表任何主機或者機架都可以。
- 請求的各種資源。比如內存，CPU。
- Container的數量，以及對應的Priority和Resource location.
- relaxLocality flag。這個flag用于告訴ResourceManager如果不能在指定的Resource location上面分配，是否選擇一個與它相鄰的。
當ApplicationMaster從ResourceManager中取到Container之后，它就開始在NodeManager上真正啟動這個Container。
ApplicationMaster會構造一個ContainerLaunchContext對象，這個對象中，包含了運行一個Container所需要的全部信息，比如，ResourceManager分配給這個容器的Resource，一些token，Container要執行的命令，環境變量等。它既可以一個一個地啟動這些Container，也可以一次把它們全部啟動起來。
在NodeManager接收到AppliationMaster的請求之后，它會發送一個列表作為響應，里面包含了已經成功啟動的Container，以及失敗的Container，以及NodeManager上全部AuxiliaryService相關的元數據。
ApplicationMaster也可以告訴NodeManager來停止Contaienr，通過發送一個StopContainersRequest，這個請求包含了要停止的Container的ID。NodeManager會回復一個StopContainersResponse，告訴ApplicationMaster哪些Container已經成功停止。
此外，處理Container失敗的情況，是Application的責任. YARN只是將集群中的資源暴露給Application。
所以，ApplicationMaster需要觀察Container的狀態，exit code，以及一些診斷信息。例如，當MapReduce ApplicationMaster知道一個Container失敗之后，它會不斷重試這個Map或者Reducer，通過跟ResourceManager溝通分配Container。直到達到了指定的最大重試閾值。
此外，ApplicationMaster也需要在它自己發生錯誤并恢復后，恢復之前的Applicaiton的信息。當一個ApplicationMaster發生錯誤之后，ResourceManager只會啟動一個新的ApplicationAttempt，并為其分配一個ApplicationMaster。這個新的ApplicationMaster應該能夠自動檢索舊的ApplicationMaster中的Application的信息。當然，如果從頭再運行一個也是可以的。但是畢竟性能可能低一些。
在MapReduce中，ApplicationMaster會恢復已經完成的Task，而那些在ApplicationMaster恢復過程中仍在運行的Task，則會被Kill掉。
當一個ApplicationMaster已經完成了它的全部工作之后，它應該向ResourceManager發送一個FinishApplicationRequest的請求，來取消注冊。在這個請求中，ApplicationMaster可以告訴ResourceManager一個IPC以及Web URL，讓Client能夠檢索這個Application的歷史信息。
總結
在這篇文章中，我們詳細闡述了ResourceManager，NodeManager以及ApplicationMaster的作用。
