Hadoop-03 Yarn

YARN - ResourceManager

負責全局的資源管理和任務調度,把整個集羣當成計算資源池,只關注分配,不管應用,且不負責容錯

  • 資源管理

以前資源是每個節點分成一個個的Map slot和Reduce slot,現在是一個個Container,每個Container可以根據需要運行ApplicationMaster、Map、Reduce或者任意的程序。
以前的資源分配是靜態的,目前是動態的,資源利用率更高

Container是資源申請的單位,一個資源申請格式:<resource-name, priority, resource-requirement, number-of-containers>, resource-name:主機名、機架名或*(代表任意機器), resource-requirement:目前只支持CPU和內存

用戶提交作業到ResourceManager,然後在某個NodeManager上分配一個Container來運行ApplicationMaster,ApplicationMaster再根據自身程序需要向ResourceManager申請資源

YARN有一套Container的生命週期管理機制,而ApplicationMaster和其Container之間的管理是應用程序自己定義的

  • 任務調度

只關注資源的使用情況,根據需求合理分配資源
Scheluer可以根據申請的需要,在特定的機器上申請特定的資源(ApplicationMaster負責申請資源時的數據本地化的考慮,ResourceManager將盡量滿足其申請需求,在指定的機器上分配Container,從而減少數據移動)

  • 內部結構
    在這裏插入圖片描述

Client Service: 應用提交、終止、輸出信息(應用、隊列、集羣等的狀態信息)

Adaminstration Service: 隊列、節點、Client權限管理

ApplicationMasterService: 註冊、終止ApplicationMaster, 獲取ApplicationMaster的資源申請或取消的請求,並將其異步地傳給Scheduler, 單線程處理

ApplicationMaster Liveliness Monitor: 接收ApplicationMaster的心跳消息,如果某個ApplicationMaster在一定時間內沒有發送心跳,則被任務失效,其資源將會被回收,然後ResourceManager會重新分配一個ApplicationMaster運行該應用(默認嘗試2次)

Resource Tracker Service: 註冊節點, 接收各註冊節點的心跳消息

NodeManagers Liveliness Monitor: 監控每個節點的心跳消息,如果長時間沒有收到心跳消息,則認爲該節點無效, 同時所有在該節點上的Container都標記成無效,也不會調度任務到該節點運行

ApplicationManager: 管理應用程序,記錄和管理已完成的應用

ApplicationMaster Launcher: 一個應用提交後,負責與NodeManager交互,分配Container並加載ApplicationMaster,也負責終止或銷燬

YarnScheduler: 資源調度分配, 有FIFO(with Priority),Fair,Capacity方式

ContainerAllocationExpirer: 管理已分配但沒有啓用的Container,超過一定時間則將其回收

YARN - NodeManager

  • Node節點下的Container管理

啓動時向ResourceManager註冊並定時發送心跳消息,等待ResourceManager的指令
監控Container的運行,維護Container的生命週期,監控Container的資源使用情況
啓動或停止Container,管理任務運行時的依賴包(根據ApplicationMaster的需要,啓動Container之前將需要的程序及其依賴包、配置文件等拷貝到本地)

  • 內部結構
    在這裏插入圖片描述
    NodeStatusUpdater: 啓動向ResourceManager註冊,報告該節點的可用資源情況,通信的端口和後續狀態的維護

ContainerManager: 接收RPC請求(啓動、停止),資源本地化(下載應用需要的資源到本地,根據需要共享這些資源)

PUBLIC: /filecache

PRIVATE: /usercache//filecache

APPLICATION: /usercache//appcache//(在程序完成後會被刪除)

ContainersLauncher: 加載或終止Container

ContainerMonitor: 監控Container的運行和資源使用情況

ContainerExecutor: 和底層操作系統交互,加載要運行的程序

YARN - ApplicationMaster

單個作業的資源管理和任務監控

具體功能描述:

  • 計算應用的資源需求,資源可以是靜態或動態計算的,靜態的一般是Client申請時就指定了,動態則需要ApplicationMaster根據應用的運行狀態來決定
  • 根據數據來申請對應位置的資源(Data Locality)
  • 向ResourceManager申請資源,與NodeManager交互進行程序的運行和監控,監控申請的資源的使用情況,監控作業進度
  • 跟蹤任務狀態和進度,定時向ResourceManager發送心跳消息,報告資源的使用情況和應用的進度信息
  • 負責本作業內的任務的容錯

ApplicationMaster可以是用任何語言編寫的程序,它和ResourceManager和NodeManager之間是通過ProtocolBuf交互,以前是一個全局的JobTracker負責的,現在每個作業都一個,可伸縮性更強,至少不會因爲作業太多,造成JobTracker瓶頸。同時將作業的邏輯放到一個獨立的ApplicationMaster中,使得靈活性更加高,每個作業都可以有自己的處理方式,不用綁定到MapReduce的處理模式上

如何計算資源需求

一般的MapReduce是根據block數量來定Map和Reduce的計算數量,然後一般的Map或Reduce就佔用一個Container

如何發現數據的本地化

數據本地化是通過HDFS的block分片信息獲取的

YARN - Container

基本的資源單位(CPU、內存等)
Container可以加載任意程序,而且不限於Java
一個Node可以包含多個Container,也可以是一個大的Container
ApplicationMaster可以根據需要,動態申請和釋放Container

YARN - Failover

失敗類型

  • 程序問題
  • 進程崩潰
  • 硬件問題

失敗處理

任務失敗

  • 運行時異常或者JVM退出都會報告給ApplicationMaster
  • 通過心跳來檢查掛住的任務(timeout),會檢查多次(可配置)才判斷該任務是否失效
  • 一個作業的任務失敗率超過配置,則認爲該作業失敗
  • 失敗的任務或作業都會有ApplicationMaster重新運行

ApplicationMaster失敗
ApplicationMaster定時發送心跳信號到ResourceManager,通常一旦ApplicationMaster失敗,則認爲失敗,但也可以通過配置多次後才失敗

一旦ApplicationMaster失敗,ResourceManager會啓動一個新的ApplicationMaster
新的ApplicationMaster負責恢復之前錯誤的ApplicationMaster的狀態(yarn.app.mapreduce.am.job.recovery.enable=true),這一步是通過將應用運行狀態保存到共享的存儲上來實現的,ResourceManager不會負責任務狀態的保存和恢復

Client也會定時向ApplicationMaster查詢進度和狀態,一旦發現其失敗,則向ResouceManager詢問新的ApplicationMaster

NodeManager失敗
NodeManager定時發送心跳到ResourceManager,如果超過一段時間沒有收到心跳消息,ResourceManager就會將其移除

任何運行在該NodeManager上的任務和ApplicationMaster都會在其他NodeManager上進行恢復

如果某個NodeManager失敗的次數太多,ApplicationMaster會將其加入黑名單(ResourceManager沒有),任務調度時不在其上運行任務

ResourceManager失敗
通過checkpoint機制,定時將其狀態保存到磁盤,然後失敗的時候,重新運行

通過zookeeper同步狀態和實現透明的HA

可以看出,一般的錯誤處理都是由當前模塊的父模塊進行監控(心跳)和恢復。而最頂端的模塊則通過定時保存、同步狀態和zookeeper來ֹ實現HA

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章