NodeManager介紹

原文連接： http://blog.csdn.net/zhangzhebjut/article/details/37730013

參考文檔: https://blog.csdn.net/u013384984/article/details/80738128

          https://hortonworks.com/blog/how-to-plan-and-configure-yarn-in-hdp-2-0

 

一 概述

 

        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、端口號、對外的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.客戶端將應用程序所需的文件資源(外部字典、JAR包、二進制文件)提交到HDFS上。

      2.客戶端將應用程序提交到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組件負責接受並處理該請求。

 

  7.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進入運行階段。

  

  7.2  Container啓動

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

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

 

  7.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等）的機制，最初由Google工程師提出，後來被整合進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等。