Hadoop - YARN NodeManager 剖析

一 概述

         NodeManager是執行在單個節點上的代理 ，它管理Hadoop集羣中單個計算節點，功能包含與ResourceManager保持通訊，管理Container的生命週期、監控每個Container的資源使用(內存、CPU等）狀況、追蹤節點健康情況、管理日誌和不一樣應用程序用到的附屬服務等。

         NodeManager是YARN中單個節點的代理， 它需要與應用程序的ApplicationMaster和集羣管理者ResourceManager交互;它從ApplicationMaster上接收有關Container的命令並執行(比方啓動、中止Contaner);向ResourceManager彙報各個Container執行狀態和節點健康情況，並領取有關Container的命令（比方清理Container）。

 

二 基本職能

  兩個基本的協議 ResourceTrackerProtocol協議 和  ContainerManagementProtocol協議

  

  2.1 ResourceTrackerProtocol協議

     a.registerNodeManager

        註冊本身,需要告訴RM本身的host ip、port號、對外的tracking url以及本身擁有的資源總量（當前支持內存和虛擬內存兩種資源)。

     b.nodeHearbeat

         NodeManager啓動後,經過RPC協議向ResourceManager註冊、彙報結點健康情況和Container執行狀態，並領取ResourceManager下達的命令，包含又一次初始化、清理Container佔用資源等。

  2.2 ContainerManagementProtocol協議

        應用程序的ApplicationMaster經過RPC協議向NodeManager發起針對Container的相關操做，包含啓動Container、殺死Container、獲取Container運行狀態。

        ApplicationMaster可以將Container相關操做經過RPC的方式第一時間告訴NodeManager。

        主要提供了三個RPC函數：

             1.startContainer 有一個參數封裝了Container啓動所需要的本地資源、環境變量、運行命令、Token等信息。

             2.stopContainer AM經過該RPC要求NodeManager中止(殺死)一個Container。該函數有一個StopContanerRequest類型的參數，用於指定待殺死的Container ID.

             3.getContainerStatus:ApplicationMaster經過該RPC獲取一個Container的執行狀態。該函數參數類型爲GetContaineStatusRequest,封裝了目標Container 的ID。

   注：1.NodeManager與ApplicationMaster之間採用了"push模型"，ApplicationMaster可以將Container相關操做(啓動、查詢、中止）第一時間告訴NodeManager。相比於"push 模型"。可以大大減小時間延遲。

           2.ApplicationMaster可以經過三種方式獲取Container的運行狀態

                 a.經過與RM的心跳信息      b.Container彙報給AM   c.AM向NM進行查詢

三  NodeManger內部架構

                                                        

                                           

                                                                                             

                                                                        NodeManager 內部組件

 介紹一下NodeManager內部的組織結構和基本的模塊

 3.1 NodeStatusUpdater

       NodeStatusUpdater是NodeManager與ResourceManager通訊的惟一通道。當NodeManager啓動時，該組件向ResourceManager註冊。並彙報節點上可用的資源(該值在執行過程當中再也不彙報）；以後,該組件週期性與ResourceManager通訊，彙報各個Container的狀態更新。包含節點上正執行的Container、已完畢的Container等信息。同一時候ResouceManager會返回待清理Container列表、待清理應用程序列表、診斷信息、各類Token等信息。

3.2 ContainerManager

        ContainerManager是NodeManager中最新核心的組件之中的一個。它由多個子組件構成，每個子組件負責一部分功能，它們協同工做組件用來管理執行在該節點上的所有Container,其主要包括的組件例如如下：

        RPCServer  實現了ContainerManagementProtocol協議，是AM和NM通訊的惟一通道。

ContainerManager從各個ApplicationMaster上接受RPC請求以啓動新的Container或者中止正在執行的Contaier。

        ResourceLocalizationService 負責Container所需資源的本地化。能夠依照描寫敘述從HDFS上下載Container所需的文件資源，並儘可能將他們分攤到各個磁盤上以防止出現訪問熱點。此外，它會爲下載的文件加入訪問控制權限，併爲之施加合適的磁盤空間使用份額。

         ContainerLaucher 維護了一個線程池以並行完畢Container相關操做。比方殺死或啓動Container。 啓動請求由AM發起。殺死請求有AM或者RM發起。

         AuxServices  NodeManager贊成用戶經過配置附屬服務的方式擴展本身的功能，這使得每個節點可以定製一些特定框架需要的服務。

附屬服務需要在NM啓動前配置好，並由NM統一啓動和關閉。

典型的應用是MapReduce框架中用到的Shuffle HTTP Server，其經過封裝成一個附屬服務由各個NodeManager啓動。

          ContainersMonitor 負責監控Container的資源使用量。爲了實現資源的隔離和公平共享，RM 爲每個Container分配必定量的資源，而ContainerMonitor週期性的探測它在執行過程當中的資源利用量。一旦發現Container超過它贊成使用的份額上限，就向它發送信號將其殺死。這可以避免資源密集型的Container影響到同節點上的其它正在執行的Container。

       注：YARN僅僅有對內存資源是經過ContainerMonitor監控的方式加以限制的。對於CPU資源，則採用輕量級資源隔離方案Cgroups.

3.3 NodeHealthCheckservice

        結點健康檢查。NodeHealthCheckSevice經過週期性地執行一個本身定義的腳步和向磁盤寫文件檢查節點健康情況，並經過NodeStatusUpdater傳遞給ResouceManager.而ResouceManager則依據每個NodeManager的健康情況適當調整分配的任務數目。一旦RM發現一個節點處於不健康的狀態，則會將其增長黑名單，此後再也不爲它分配任務，直到再次轉爲健康狀態。需要注意的是。節點被增長黑名單後，正在執行的Container仍會正常執行，不會被殺死。

            第一種方式經過管理員本身定義的Shell腳步。

（NM上專門有一個週期性任務運行該腳步，一旦該腳步輸出以"ERROR"開頭的字符串，則以爲結點處於不健康狀態）

            另一種是推斷磁盤好壞。（NM上專門有一個週期性任務檢測磁盤的好壞，假設壞磁盤數據達到必定的比例。則以爲結點處於不健康的狀態）。

3.4  DeleteService  

        NM 將文件的刪除功能服務化，即提供一個專門的文件刪除服務異步刪除失效文件，這樣可以避免同步刪除文件帶來的性能開銷。

3.5  Security 

       安全模塊是NM中的一個重要模塊。它由兩部分組成。各自是ApplicationACLsManager 確保訪問NM的用戶是合法的。ContainerTokenSecretManger:確保用戶請求的資源是被RM受權過的。

3.6  WebServer 

       經過Web界面向用戶展現該節點上所有應用程序執行狀態、Container列表、節點健康情況和Container產生的日誌等信息。

三 分佈式緩存

    

        相似於MRv1中的Distrubuted Cache。其主要做用就是將用戶應用程序運行時所需的外部文件資源本身主動透明的下載緩存到各個節點，從而省去了用戶手動部署這些文件麻煩。

     YARN分佈式緩存工做流程例如如下:

      1.client將應用程序所需的文件資源(外部字典、JAR包、二進制文件)提交到HDFS上。

      2.client將應用程序提交到RM上。

      3.RM將與某個NM進行通訊，啓動應用程序AM，NM收到命令後，首先從HDFS上下載文件(緩存),而後啓動AM。

      4.AM與RM通訊，以請求和獲取計算資源。

      5.AM收到新分配到的計算資源後，與相應的NM通訊，以啓動任務。

      6.假設應用程序第一次在該節點上啓動任務，NM首先從HDFS上下載文件緩存到本地，而後啓動任務。

      7.NM興許收到啓動任務請求後，假設文件已在本地緩存。則直接運行任務，不然等待文件緩存完畢後再啓動。

   

        各個節點上的緩存文件由相應的NM管理和維護。

    注：在Hadoop中，分佈式緩存並不是將文件緩存到集羣中各個節點的內存中，而是將文件緩存到各個節點的磁盤上，以便運行任務時直接從磁盤上讀取文件。

      資源的可見性分爲三類：

           PUBLIC: 節點上所有用戶共享該資源

           PRIVATE: 節點上的同一用戶的所有應用程序共享該資源
          APPLICATION:節點上同一應用程序的所有Container共享，默認狀況下，MapReduce做業的split元信息文件job.splimetainfo和屬性文件job.xml的可見性是Application的。

      上面不一樣可見性是經過設置特殊文件夾的位置和文件夾權限實現的。

      NM的資源分類

         ARCHIVE:歸檔文件   

         FIFE:普通文件   

         PATTERN：以上兩種文件的混合體，有多種類型文件存在。

      

      注：1.YARN是經過比較resource、type、timestamp和pattern四個字段是否一樣來推斷兩個資源請求是否一樣的。假設一個已經被緩存到各個節點上的文件被用戶改動了。則下次使用時會本身主動觸發一次緩存更新。以又一次從HDFS上下載文件。

               2.分佈式緩存完畢的主要功能是文件下載，涉及大量的磁盤讀寫。所以整個過程採用了異步併發模型加快文件下載速度，以免同步模型帶來的性能開銷。

四 文件夾結構

        NodeManager上的文件夾可分爲兩種:數據文件夾和日誌文件夾，當中數據文件夾用於存放運行Container所需的數據(比方可運行程序或JAR包、配置文件等)和運行過程當中產生的暫時數據。

       NM在每個磁盤上爲該做業建立一樣的文件夾結構，且採用輪詢的調度方式將文件夾（磁盤）分配給不一樣的Container的不一樣模塊以免干擾。

考慮到一個應用程序的不一樣Container之間存在依賴，爲了不提早清除已經完畢的Container輸出的中間數據破壞應用程序的設計邏輯。YARN統一規定，僅僅有當應用程序執行結束後。才統一清楚Container產生的中間數據。

       日誌文件夾用於存放Container執行時輸出的日誌。NM提供了按期清除和日誌彙集轉存兩種日誌清理機制，默認狀況下，採用的是按期清除機制，該任務由LogHandler組件完畢。

五 狀態機管理

        NodeManager維護了三類狀態機。各自是:Application、Container和LocalizedResource,它們均直接或者間接參與維護一個應用程序的生命週期。

       當NodeManager收到來自某個應用程序第一次Container啓動命令時。會建立一個Application狀態機跟蹤該應用程序在該結點上的生命週期，而每個Container的執行過程相同由一個狀態機維護。

此外Application所需的資源(比方文本文件、JAR包、歸檔文件等）需要從HDFS上下載，每個資源的下載過程均由一個狀態機LocalizedResouce維護和跟蹤。

     

       NM上Application維護的信息是ResourceManager端Application信息的子集。這有利於對一個節點上的同一個Application的所有Container進行統一管理（比方記錄每一個Application執行在該節點上的Container列表。殺死一個Application的所有Container等）。它實際的實現類是ApplicationImpl，該類維護了一個Application狀態機，記錄了Application可能存在的各個狀態以及致使狀態間轉換的事件。需要注意的是NM上的Application生命週期與ResourceManager上Application的生命週期是一致的。

      

       LocalizedResource是NodeManager中維護一種「資源」(資源文件、JAR包、歸檔文件等外部文件資源)生命週期的數據結構。它維護了一個狀態。記錄了"資源"可能存在的各類狀態以及致使狀態間轉換的事件。

       

六 Container 生命週期剖

       Container啓動過程主要經歷三個階段:資源本地化、啓動並執行Container和資源清理。

        Container的啓動命令是由各個ApplicationMaster經過RPC函數ContainerManagementProtocol#startContainer向NodeManager發起的，NodeManager中的ContainerManager組件負責接受並處理該請求。

  6.1 資源本地化

       資源本地化指的是準備Containers執行所需的環境， 主要是分佈式緩存機制完畢的工做。功能包含初始化 各類服務組件、建立工做文件夾、從HDFS下載執行所需的各類資源(比方文本文件、JAR包、可執行文件)等。資源本地化主要是由兩部分組成，各自是 應用程序初始化和Container本地化。

當中，應用程序初始化的工做是初始化各種必需的服務組件（比方日誌記錄組件LogHandler、資源狀態追蹤組件LocalResouceTrackerImpl)，供興許Container使用，一般由Application的第一個Container完畢。Container本地化則是建立工做文件夾，從HDFS上下載各種文件資源。

     

     注：1. YARN資源分爲PUBLIC PRIVATE 和 APPLICATION三類。不一樣級別的資源對不一樣用戶和應用程序的訪問權限不一樣，這也直接致使資源的本地化方式不一樣。它們的本地化由ResouceLocalizationSevice服務完畢，但內部由不一樣的線程負責機載。

            2.兩種類型的Container: 一種是該Container是ApplicationMaster發送到給節點的第一個Container。還有一種則不是第一個Container.

       

       資源本地化過程可歸納爲：在NodeManager上。同一個應用程序的所有ContainerImpl異步併發向資源下載服務ResourceLocalizationService發送待下載的資源。而ResourceLocationService下載完一類資源後，將通知依賴該資源的所有Container。

一旦一個Container依賴的資源已經所有下載完畢，則該Container進入執行階段。

  

6.2  Container啓動

       由ContainersLauncher服務完畢。該服務將進一步調用插拔式組件ContainerExecutor，YARN提供了兩種ContainerExecutor,一種是DefaultContainerExecutor一種是LinuxContainerExecutor.

         主要過程可歸納爲:將待執行的Container所需的環境變量和執行命令寫到Shell腳本launch_container.sh中，並將啓動該腳本的命令寫入default_container_executor.sh中。而後經過執行該腳步啓動Container.

6.3  資源清理

        是資源本地化的逆過程。它負責清理各類資源，它們均由ResouceLocalizatonService服務完畢。

         Container執行完畢後(可能成功或者失敗),NM需回收它佔用的資源，這些資源主要是Container執行時使用的暫時文件。它們的來源主要是ResourceLocalizationService和ContainerExecutor兩個服務/組件，當中。ResourceLocalizationService將數據HDFS文件下載到本地。ContainerExecutor爲Container建立私有工做文件夾。並保存一些暫時文件(比方Container進程pid文件).所以，Container資源清理過程主要是通知這兩個組件刪除暫時文件夾。

     注：由於每個NM上僅僅負責處理一個應用程序的部分任務，所以它沒法知道一個應用程序什麼時候完畢，該信息僅僅有控制着全部消息的RM知道，所以當一個應用程序執行結束時。需要由它廣播給各個NM。再進一步由NM清理應用程序佔用的全部資源。包含產生的中間數據。

七 資源隔離

       資源隔離是指爲不一樣的應用任務提供可獨立使用的計算資源以免它們之間互相干擾。當前存在很是多種資源隔離技術，比方硬件虛擬化、虛擬機、Cgroups、Linux Container等。YARN對內存資源和CPU資源的管理採用的不一樣的資源隔離方案。

       對於內存資源。它是一種限制性資源，它的量的大小直接決定的應用程序的死活。YARN採用了進程監控的方案控制內存資源使用量，一旦發現它超過約定的資源量。就將其殺死。

       還有一種可選的方案則是基於輕量級資源隔離技術Cgroups,Cgroups是Linux內核提供的彈性資源隔離機制，可以嚴格限制內存的使用上限，一旦進程使用資源量超過事先定義的上限值，則可將其殺死。

對於CPU資源，它是一種彈性資源。它的量的大小不會直接影響應用程序的死活，所以採用了Cgroups。

       Cgroups（Control Groups)是Linux 內核提供的一種可以限制、記錄、隔離進程組所使用的物理資源(如CPU、內存、IO等）的機制。最初由Googleproject師提出，後來被整合進Linux內核。

Cgroups最初的目的是爲資源管理提供一個統一的框架。既整合現有的cpuset等子系統，也爲將來新的子系統提供接口。以使得Cgoups適合多種應用場景，從單個進程的資源控制到實現操做系統層次的虛擬化的應用場景均支持。

總結起來，Cgroups提供了已下功能： 

       1.限制進程組使用的資源量。

       2.進程組的優先級控制，比方，可以使用CPU子系統爲某個進程組分配特定CPU share.

       3.對進程組使用的資源量進行記帳  4.進程控制。比方將某個進程組掛起和恢復。

        YARN使用了Cgroups子系統中的CPU和Memory子系統。CPU子系統用於控制Cgroups中所有的進程可以使用的CPU時間片。Memory子系統可用於限定一個進程的內存使用上限，一旦超過該限制，將以爲它爲OOM，會將其殺死。

      對於內存資源隔離，YARN採用了與MRv1這樣的基於線程監控的資源控制方式，這樣作到的主要出發點是：這樣的方式更加靈活。且能夠防止內存驟增驟降致使內存不足而死掉。

      對於CPU資源隔離。YARN採用了輕量級的Cgroups。

      注:默認狀況下，NM未啓用不論什麼CPU資源隔離機制。假設想要啓用該機制，需使用LinuxContainerExecutor,它能夠以應用程序提交者的身份建立文件，執行Container和銷燬Container.

八 小結

       NodeManager做爲資源管理系統YARN的一個重要服務，它的主要功能包含節點健康情況檢測、分佈式緩存機制、文件夾結構管理、狀態機管理、Container生命週期、資源隔離機制等機制。NM管理的是Container而不是任務，一個Container中可能執行着各類任務。但是對NM而言是透明的。它僅僅負責Container相關操做。比方管理Container的生命週期。即啓動Container、監控Container和清理Container等