YARN學習總結

前言

YARN（Yet Another Resource Manage，另一種資源協調者）是hadoop-0.23版本引入的的一個新的特性，可以說它是對原有Hadoop Mapreduce（Hadoop 1.0）架構的一種里程碑式的改革。它在整個Hadoop生態體系中負責資源管理和作業調度，支持各類分布式應用程序的執行。

本文檔的大部分內容參考於Apache Hadoop 2.7.2——YARN官方網站，是對網站內容的翻譯加上本人自己的理解，有些內容可能會因為本人的知識水平和英文水平有限而導致理解上存在偏差或不足的地方，還望指正。

概況

Apache Hadoop YARN 是一種新的 Hadoop 資源管理器，它是一個通用資源管理系統，可為上層應用提供統一的資源管理和調度。它將Hadoop 1.0架構中的JobTracker的兩塊主要功能（資源管理和任務生命周期管理）拆分成了兩個單獨的組件：ResourceManager和Application Master。它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。

本篇文檔主要從以下幾個方面介紹YARN。

• MRv1架構及其存在的缺陷
• YARN架構及其優點
• 調度器（Scheduler）
• RM重啟機制（ResourceManager Restart）
• RM高可用（ResourceManager HA）
• YARN常用命令

1. MRv1架構及其存在的缺陷

1.1 MapReduce和HDFS簡介

在第一代Hadoop系統中，一個Hadoop集群可以分解為兩個抽象實體：MapReduce計算引擎和分布式文件系統(HDFS)。其中MapReduce引擎能夠在整個集群上執行Map和Reduce任務並報告結果，而HDFS分布式文件系統則提供了一種存儲模式，可跨節點復制數據以進行處理。HDFS一般由一個NameNode和多個DataNode組成，其中NameNode是文件系統的主系統，提供元數據服務來執行數據分發和復制，而DataNode是實際儲存數據的節點。客戶端通過連接NameNode來請求對文件的元數據的訪問或修改，而實際的數據復制存儲都是發生在DataNode。

• 查看NameNode所在機器：

  查看hadoop-home/etc/hadoop/hdfs-site.xml的配置文件。

• 查看DataNode所在機器及狀態信息：

  在hadoop-home/bin目錄下執行命令./hdfs dfsadmin -report。

1.2 MRv1架構分析

圖1 MRv1的架構

圖1所示是Hadoop 1.0的架構，它的架構體系主要由一個Job Tracker進程和多個TaskTracker進程組成。

其中JobTracker主要負責：

• 調度從客戶端提交的任務
• 跟蹤各個TaskTrackers的資源使用情況（可用的map/reduce插槽數）
• 監控各個任務的執行情況，包括指導TaskTracker啟動任務、重啟失敗任務。

TaskTrackers主要負責：

• 執行各個map和reduce任務
• 向JobTracker匯報任務的執行情況。

當一個客戶端向一個Hadoop集群發出一個請求時，此請求由JobTracker管理。JobTracker與NameNode聯合將工作分發到離它所處理的數據盡可能近的位置。JobTracker將Map和Reduce任務安排到一個或多個TaskTracker上的可用插槽中。TaskTracker與DataNode一起對來自DataNode的數據執行Map和Reduce任務。當Map和Reduce任務完成時，TaskTracker會告知JobTracker，后者確定所有任務何時完成並最終告知客戶作業已完成。

1.3 MRv1架構存在的缺陷

在實踐中，依據Yahoo!，在集群中有5000個節點和40000個任務同時運行時，會出現一定的不可預測性，其中最大的一個問題就是會出現“級聯故障”。

從我個人的理解，第一代Hadoop系統存在的缺陷主要可以歸納為三個方面：

1.3.1 中心化管理，對JobTracker過分依賴

從圖1中我們可以看到，整個集群只有一個JobTracker，既要負責整個集群的資源調度，又要負責監控各個計算節點的任務的執行情況。所有的客戶端要通過JobTracker來提交應用，然后將應用的各個map/reduce任務安排到TaskTracker的不同插槽中執行。這種中心化的管理，當水平擴展的計算節點非常多時，JobTracker的負載會非常繁重。如果JobTracker發生故障，結果將是災難性的。

1.3.2 資源利用率低

在MRv1中，計算資源（內存、cpu）是以插槽的形式存在於TaskTracker中，插槽的數量、每個插槽的大小、甚至是分別用於map和resuce任務的插槽的數量都是由集群管理員配置的。考慮以下兩種場景，就可以體會資源的浪費：

• 一個計算節點中有10個map slot和10個 reduce slot。但是當前的應用需要執行100個map任務，只需要執行1個resuce任務。顯然，10個map slot會被完全占滿，而reduce slot會處於完全空閑狀態。由於它們相互不兼容，即map任務不能占用reduce的插槽，這就導致了嚴重的資源浪費。
• 一個slot包含10G的內存，但是我的一個任務只要求1G內存。由於每個slot的大小是固定的，這就可能會導致一個任務所需的內存遠小於slot的容量，從而造成資源浪費。

1.3.3 單一應用限制

第一代Hadoop架構中，限制了應用只能以Hadoop MapReduce的形式執行。無法支持Storm、Spark、Giraph等其他分布式應用程序，限制了資源共享。

2. YARN架構及其優點

YARN架構引入的核心思想就是將“資源管理”和“任務調度監控”這兩大塊主要功能拆分成兩個獨立的進程。在該思想的指導下，在YARN的架構中有了一個全局的ResourceManager和每個應用獨有的ApplicationMaster。在YARN中，每個應用由一個單獨的任務或由多個任務構成的有向無環圖（DAG）組成。

2.1 YARN的架構及其重要組件

圖2 YARN的架構

從圖2可用看到，YARN的架構主要由五部分組件組成：ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）、Container、Client。

2.1.1 ResourceManager

在YARN中，ResourceManager的主要作用是管理和分配資源。它的主要職責有：

• 跟蹤各個可用的NodeManager節點及其可用資源
• 分配可用資源給各個應用及其任務
• 監控各個ApplicationMaster的健康狀況，並負責啟動和重啟失敗的AM

實際上，RM也可以拆分成兩個主要組成部分：Scheduler和ApplicationsManager。

Scheduler根據一定的限制（資源容量、隊列、數據位置、ACL等）負責給各個在集群運行的應用分配資源。它是一個純資源的調度器，不會去對應用的狀態執行監控或是跟蹤。並且，它不保障當任務因為應用或硬件出現故障而導致失敗時去重啟失敗的任務。它僅基於應用所需要的資源來執行調度。

Scheduler還是一個可插拔的組件，當前Hadoop提供了幾種不同的現成的調度器，如CapacityScheduler和FairScheduler等，它們根據不同的算法在不同的隊列和應用間分配集群的資源。

而ApplicationsManager負責接受任務提交，協商用於啟動應用的ApplicationMaster所需的第一個container，並且提供當AM出現故障時重啟AM container的服務。

2.1.2 NodeManager

NodeManager是MRv1架構中TaskTracker的一種更加普通和高效的版本。它沒有固定數量的map和reduce插槽，而是擁有許多動態創建的資源容器。容器的大小取決於它所包含的資源量（內存、CPU、磁盤和網絡IO）。目前，僅支持內存和CPU。未來可使用cgroups來控制磁盤和網絡IO。NodeManager的主要職責有：

• 以container的形式提供任務計算所需要的資源
• 管理在container中執行的任務的資源使用

一個節點上的容器數量，由配置參數與專用於從屬后台進程和操作系統的資源以外的節點資源總量（比如總CPU數和總內存）共同決定。MRv1通過插槽管理Map和Reduce任務的執行，而NodeManager管理抽象容器，這些容器代表着可供一個特定應用程序使用的針對每個節點的資源。

2.1.3 ApplicationMaster

當一個應用程序從client提交到ResourceManager，RM就會啟動一個稱為ApplicationMaster的輕量級進程來協調應用程序內的所有任務的執行，它管理着該應用程序的整個生命周期。每個特定的在集群運行的應用程序都會由一個特定的AM來管理。它的主要職責有：

• 協調一個應用程序內的所有任務的執行
• 向RM請求各個任務執行所需要的資源(container)
• 監視任務執行狀況，重啟失敗的任務
• 在任務完成后注銷容器

ApplicationMaster和屬於它的應用程序的任務，都是在受NodeManager控制的資源容器container中運行的。

ApplicationMaster可在容器內運行任何類型的任務。例如，MapReduce ApplicationMaster請求一個容器來啟動map或reduce任務，而Giraph ApplicationMaster請求一個容器來運行Giraph任務。它還支持用戶實現一個自定義的ApplicationMaster來運行特定的任務，進而可以發明出一種全新的分布式應用程序框架。

在YARN中，MapReduce降級為一個分布式應用程序的一個角色，現在稱為MRv2，運行在YARN之上。實際上，在hadoop-2.x版本的API設計中，保持了對hadoop-1.x版本MapReduce的兼容，所有的舊的MapReduce任務都可以不需要作任何改變就可以運行在YARN之上。

2.1.4 Container

在YARN中，資源是以容器container的形式提供給各個應用程序的任務。它是一個抽象的概念，主要包含內存、CPU、磁盤和網絡IO。每個特定任務的執行都是在一個給定的container中完成。container的主要特性有：

• 運行不同類型的任務（包含ApplicationMaster本身）
• 動態創建，具有不同的大小（內存、cpu等）

2.1.5 Client

Client，即YARN客戶端，通過它可以向RM發送各種不同的請求，用於向RM提交不同類型的應用程序，並且還可以通過它向RM發送一些控制命令，如查詢應用的狀態，停止應用等。

2.2 YARN的工作流程

YARN中的應用程序的提交處理，可以依次分為以下步驟：

（1）用戶通過client向RM提交應用程序

（2）RM在接收到一個新的應用程序后，會先選擇一個container用於啟動該應用程序特有的AM

（3）AM啟動后，向RM請求運行應用程序所需要的資源

（4）RM會盡可能地分配AM所請求的資源的容器，表達為容器ID和主機名

（5）AM根據給定的容器ID和主機名，要求對應的NodeManager使用這些資源啟動一個特定於應用程序的任務。

（6）NodeManager啟動任務，並監視該任務使用資源的健康狀況。

（7）AM持續監視任務的執行情況。

（8）當任務執行完成時，AM會向RM匯報並注銷執行任務的容器，以及注銷自己。

下面這幅流程圖描述了上述過程：

圖3 YARN中的應用程序提交流程

2.3 YARN各個組件之間的關系小結

2.3.1 ResourceManager負責管理ApplicationMaster

（1）RM不會對應用程序內的任務執行作任何監視，但它會檢查AM的健康狀況。如果AM失敗，RM可在一個新容器中重新啟動它。

（2）RM實際上由兩部分組成：Scheduler和ApplicationsManager

（3）Scheduler負責調度，分配應用程序需要的資源。在指定的機器上分配Container，從而減少數據移動。包含FairScheduler、CapacityScheduler等。

（4）ApplicationsManager負責接受任務提交，協商用於啟動AM的container，提供重啟AM container的服務。

2.3.2 AM負責向RM請求應用所需的資源，要求NodeManager啟動任務

每個應用程序有自己特定的AM，AM負責管理應用的整個生命周期，它會監視應用的所有任務的執行情況，並負責重啟失敗的任務。當應用的所有任務執行完成時，會向RM匯報，然后注銷任務所需的容器，並注銷自己。

2.3.3 NodeManager負責管理容器資源container

NodeManager不會監視任務的具體執行情況，但它會監視容器中的資源使用情況。舉例而言，如果一個容器消耗的內存比最初分配的更多，它就會結束該容器。

2.3.4 NodeManager與RM的通信，是為了同步資源情況。

2.3.5 AM與RM的通信，是為了同步任務的運行情況。

2.4 YARN相對MRv1的優勢（個人觀點）

這一節與1.3中MRv1架構的缺陷相對應：

2.4.1 去中心化單進程管理。

在YARN中將原來MRv1的JobTracker的職責（資源調度和任務監視、追蹤、管理）分為兩個獨立的守護進程，ResourceManager和ApplicationMaster。其中ResourceManager負責管理整個集群的資源，負責給每個應用分配資源，並通過NodeManager監控各個節點的資源狀態。且在YARN中已經實現了RM的高可用，具有更好的穩定性。而ApplicationMaster負責各個應用的整個生命周期，每個單獨的應用對應一個單獨的ApplicationMaster，管理和監視各個應用的子任務的執行，並負責重啟失敗的任務。

相對於以前一個JobTracker既要負責資源的管理調度，又要監視所有任務的執行，YARN中將任務執行狀況監視的職能分發到多個不同的ApplicationMaster去管控，將各個計算節點的資源狀況也交由各個節點的NodeManager自己去管控。RM只要負責整個集群的資源協調。

2.4.2 提升資源利用效率

在MRv1中，在集群配置時管理員會為每個TaskTrackers設置固定數量的槽，每個任務(map或reduce)在一個特定的槽上運行。而每個槽的內存分配是固定的，當一個任務使用較少內存時會使得一部分內存資源的浪費，而這部分空閑的內存也不能夠分配給其他等待的任務。此外，由於分配的槽限定了該槽只能運行map任務或只能運行reduce任務，互相不可替代，這就可能會導致一種極端的情形：當該計算節點上有大量的map任務，而沒有reduce任務時，此時即使該節點上的map槽已經被占滿，而reduce槽全為空閑狀態，也不能在reduce槽上運行map任務。反之亦然。

而在YARN中，所有的資源申請由ApplicationMaster去向RM申請，各個應用程序（如MR、Spark）各自實現的、對應的特定AM會包含其所需要的資源信息。

另外，AM根據該應用需要的資源，如果該任務是“小任務”（默認情況下，小於10個mapper且只有一個reducer且輸入大小小於一個HDFS塊的任務），AM會選擇在與它相同的JVM上直接運行，從而大大減少了請求資源、數據移動等額外的開銷；如果不是小任務，會根據任務需要的資源向RM申請相對應的資源，RM根據集群中的資源狀況向其分配合適的、且包含所需資源的container，告知AM用於執行其任務的資源容器containerId.

在YARN中，資源是動態分配的，大大提高了資源利用率。

2.4.3 支持跨應用的分布式集群

在MRv1原先的架構中，只支持Hadoop MapReduce一種應用程序，而在YARN中沒有這種限制。NodeManager分配的container沒有限制執行的任務的類型，container只負責提供任務所需要的資源。任何應用程序只要實現其對應的Application Master就可以在YARN上執行。這樣不同的應用程序(mr，spark，storm等)在同一個集群上運行，共用相同的底層存儲服務（HDFS），給相互之間的資源訪問共享提供了很大的便利，減少了資源相互傳輸復制的很大開銷。另外相對來說更“環保”，只需要部署和維護一套環境，減少了機器資源的占用和運維成本。

3. 調度器（Scheduler）

3.1 Capacity Scheduler

3.1.1 What is Capacity Scheduler?

一個可插拔的調度器（scheduler），它允許不同租戶安全地共享一個大的集群，使得它們的應用（applications）可以在分配資源的約束下及時地分配到資源。

3.1.2 關鍵詞

• queue
• hierarchical queues / sub-queue

3.1.3 概況

Capacity Scheduler是為了在共享、多租戶的集群下以一種操作友好的方式，同時又能最大化吞吐量和集群利用率，來運行Hadoop應用而設計的。

傳統情況下，各個租戶擁有它們自己獨有的計算資源集，從而擁有充足的資源滿足其極限或接近極限條件下的SLA。這通常會導致較低的平均利用率以及管理多個獨立集群的開銷（一個租戶一個集群）。在各個租戶之間共享集群是運行多個大型Hadoop實例的一種具有成本效益的方式，因為可以不需要去創建獨立的集群，從而獲得大規模的經濟收益。但是，租戶們又會擔心共享同一個集群，因為他們擔心其他使用這些資源的機構對於它們自己的SLA非常重要。

設計Capacity Scheduler是為了在共享一個大集群的情況下同時又可以保障各個租戶各自的資源使用。核心思想是將Hadoop集群中的可用資源在各個租戶之間共享，而這些租戶分別根據自己的計算需求共同資助這個集群。這樣帶來的好處是一個租戶可以使用超過其資源上限的資源（當其他租戶的資源空閑時）。這樣租戶（使用資源）變得更有彈性，並且提高了資源使用效率。

在不同機構間共享集群迫使對“多租戶”提出了強烈需求，因為每個機構的資源必須得到保證並且安全保障。為了保證公平性和穩定性，Capacity因此對每個應用/隊列的資源使用作了限制。

核心概念——隊列（queues），這些隊列通常是由hadoop管理員配置，來反映各個租戶的利益。

為了提供未來控制和可預見性，Capacity Schedule提供了按等級划分的隊列來保障資源可以在一個機構的不同子隊列里共享。

3.1.4 Capacity Schedule支持的特性

（1）Hierarchical Queues 分等級的隊列

保證在其他隊列可使用免費資源之前，使得這部分資源可以在相同組織的不同子隊列間共享。從而提供更好的可控性和可預測性。

（2）Capacity Guarantees 資源保證。

所有提交到隊列的應用都可以使用隊列的資源

（3）Security 安全性。

每個隊列有嚴格的ACL控制，每個隊列允許哪些用戶提交應用，並且用戶不能查看和修改其他用戶的應用。並支隊列管理員和系統管理員角色。

（4）Elasticity 伸縮性

空閑的資源可以分配給其他隊列。

（5）Multi-tenancy 多租戶

全面的限制條件保證任一單獨的應用，或單獨的用戶，或單獨的隊列不會壟斷整個隊列或集群的資源。

（6）Operability 可操作性

• Runtime Configuration 可運行時修改配置，包括更改capacity，ACL，甚至增加隊列。但是不能刪除隊列。
• Drain applications 停止隊列，隊列中正在執行的任務會繼續執行直到完成，但是該隊列及其子隊列都不會再接受新的任務。當然，管理員也可以啟動停止的隊列。

（7）Resource-based Scheduling

對一些資源要求較高的應用，支持可調節地滿足其不同程度的資源需求。當前僅支持資源的維度為：“內存”

（8）Queue Mapping based on User or Group

根據用戶或組，將job映射到特定的隊列執行。

3.1.5 配置方式

（1）RM配置

通過下面配置可以使RM使用CapacityScheduler:
在conf/yarn-site.xml中加入：

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>

（2）隊列配置

CapacityScheduler的配置文件為etc/hadoop/capacity-scheduler.xml。它擁有一個預先定義的隊列root，所有隊列都是root隊列的子隊列。

隊列的配置：yarn.scheduler.capacity.root.queues，以逗號分隔。示例：

<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>a,b,c</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.a.queues</name>
  <value>a1,a2</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

<property>
  <name>yarn.scheduler.capacity.root.b.queues</name>
  <value>b1,b2,b3</value>
  <description>The queues at the this level (root is the root queue).
  </description>
</property>

其中a，b，c為root隊列的子隊列；a1，a2為a的子隊列；b1，b2，b3為b的子隊列。

其他的關於Capacity Scheduler的配置可參考Capacity Scheduler。

3.2 Fair Scheduler

3.2.1 簡介

Hadoop中一個可插拔的調度器，允許YARN中的應用在同一個大的集群中公平地共享資源。

• 公平調度

  默認情況下，公平調度器是基於內存的公平調度，也可以配置為同時基於內存和cpu的公平調度（使用Ghodsi等人提出的新概念Dominant Resource Fairness）。當只有一個應用在運行時，該應用會占用整個集群的資源；當有其他應用也提交到集群時，一些資源就會釋放出來分配給這些新的應用，使得每個應用最終會獲得大體相同的資源數量。

• 隊列

  支持queue，使得queue中的每個應用的資源公平分配。默認情況下，所有用戶共享一個稱為“default”的隊列。默認是給予內存的公平調度，也可以配置為FIFO或Dominant Resource Fairness的多種資源調度模式。隊列可以被划分為不同的等級並且被設置不同的權重。

• 最少份額保障VS最大化集群資源使用

  還可以給每個隊列分配受保障的最少資源份額，以保障一部分用戶的應用可以始終得到充足的資源。如果某個隊列擁有一些正在運行的應用，那么該隊列就可以確保獲得設定的最少資源份額，但是如果該隊列獲得的這部分最少資源份額超過了該隊列的所有應用所需的資源，超出的資源也可以被划出去給其它正在執行的應用使用。這就使得調度器在保證各個隊列的各自所需資源的同時又可以提高整個集群的資源使用效率。

• 限制每個用戶和每個隊列並行執行的應用數

  通過配置文件可以限制每個用戶和每個隊列並行執行的應用數，以防止某個用戶可能同時提交上百個應用，進而可能導致過多的即時數據創建或過多的上下文轉換。通過限制單個用戶並行執行的應用數，使得一部分應用等待之前的應用執行完成后再開始執行，可以防止這種情況下的一些應用失敗。

3.2.2 Hierarchical queues with pluggable policies

所有的隊列是從一個稱為"root"的隊列分化出來的，即所有隊列都是root隊列的孩子隊列。隊列的命名以它的父親隊列開頭，以句號分隔。舉例：root隊列下的一個子隊列queue1的命名方式為"root.queue1"；queue1下的子隊列queue2命名為"root.queue1.queue2"。當引用一個隊列時，root可以被隱藏，比如"queue1"就指代了"root.queue1"，"queue1.queue2"就指代了"root.queue1.queue2"。

不同隊列還允許使用不同的調度策略，通過擴展類org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy類可以實現定制化的策略。FifoPolicy、FairSharePolicy(default)、DominantResourceFairnessPolicy是幾種已經內置的策略。

需要注意的是，MRv1中的Fair Scheduler有一些policy在YARN中還不支持。

3.2.3 Automatically placing applications in queues

管理員可以配置一些policy使得針對特定的用戶或屬於特定組的用戶提交的應用自動放入到合適的隊列中。每個policy由許多規則組成，每個應用提交時按照policy中由上至下的順序適配合適的規則。

3.2.4 部署

在yarn-site.xml中配置:

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

查看YARN配置的方法：查看/hadoop_home/etc/hadoop/yarn-site.xml

3.2.5 配置

兩種配置方式：

• 全局配置：影響整個調度器，在yarn-site.xml中配置
• 局部配置：創建allocation file列出存在的隊列，及其各自的權重和資源容量。

allocation file每隔10秒重載一次，使得可以在運行中更新配置。

3.2.6 管理方式

三種管理方式：

• 運行時更新配置：更改allocation file

• 通過RM web UI監控：http://ResourceManagerURL/cluster/scheduler

  每個隊列可監控的項：

  • 已使用的資源：已分配給containers的資源總和
  • 活躍的應用數：至少被分配了一個container的應用數
  • 待定的應用數：進入了隊列，但還未分配到任何container的應用數
  • 最小資源：隊列配置的受保障的最小資源
  • 最大資源：隊列配置的允許獲得的最大資源
  • Instantaneous Fair Share ——consider only actives queues（those with running applications）
  • Steady Fair Share --consider all queues

  備注：最后兩種的含義不太明白。

• 在隊列中移動應用

  允許將一個正在運行的應用移到另一個隊列。根據應用的重要性人為地將其移到更高或更低優先級的隊列中執行。移動的命令：

  yarn application -movetoqueue appID -queue targetQueueName
  

  為了計算公平性，如果一個應用被移動了隊列，該應用當前被分配的資源會計算到新的隊列，而不再計入舊隊列。受到新隊列的最大並行運行應用數或最大資源的限制，移動應用到新的隊列的操作可能會失敗。

其他的關於Fair Scheduler的配置可參考Fair Scheduler。

3.3 Capacity Scheduler與Fair Scheduler的比較

3.3.1 資源分配模型

無論哪種調度器，它們的核心資源分配模型都是一樣的。調度器維護一群隊列的信息，用戶可以向一個或多個隊列提交應用。每次NodeManager心跳的時候，調度器根據一定的規則選擇一個隊列，再在隊列上選擇一個應用，嘗試在這個應用上分配資源。

不同的是，不同的調度器在選擇隊列的方式以及選擇應用的方式上有所不同。

3.3.2 調度器比較

調度器	CapacityScheduler	FairScheduler
設計目的	多租戶下，最大化集群的吞吐和利用率	多租戶下，強調用戶公平地共享資源
隊列組織方式	無論父隊列還是子隊列都會有資源參數限制，子隊列的資源限制計算是基於父隊列的。應用提交到葉子隊列。	每個葉子隊列有最小共享量，最大資源量和最大活躍應用數。
隊列ACL限制	可以限制應用提交權限和隊列開關權限，父子隊列間的ACL會繼承	可以限制應用提交權限和隊列開關權限，父子隊列間的ACL會繼承
隊列排序算法	按照隊列的資源使用量最小的優先	公平排序算法
應用選擇算法	先進先出	先進先出或公平排序

4. RM重啟機制（ResourceManager Restart）

4.1 簡介

RM作為YARN中最核心的組建，管理和調度着整個YARN集群中的資源。它的可靠性對所有在YARN集群上運行的應用都至關重要。這一章介紹RM的重啟機制，該機制保障了應用在RM發生重啟后可以繼續可靠執行並且不會被終端用戶察覺。

RM的重啟機制的發展經歷了兩個階段：

1. 階段1： 非工作保存（non-work-preserving）

   該階段通過可插拔的狀態持久化組建使得RM可以將應用的狀態和重要信息持久化。當RM重啟時從持久化組建中恢復應用的信息然后重新執行之前運行的應用。保障了用戶不需要再重新提交應用。

2. 階段2: 工作保存（work-preserving）

   該階段通過結合來自NodeManagers的各個container狀態信息和來自ApplicationMasters的各個container請求信息，聚焦於讓RM重啟時可以重建RM的運行狀態。與階段1的核心區分是，RM重啟之前運行的那些應用不會在RM重起后被kill，從而保證了應用不會因為RM的故障而停止工作。

個人小結：RM主要是負責管理整個集群的資源信息，以及調度不同應用到不同的計算節點上去執行。它自己不負責任務的執行，所以其宕機並不會影響正在執行的應用的繼續執行。當RM重啟時如果可以重新同步各個節點的資源使用狀態和任務運行狀態即可繼續正常工作。

4.2 Feature

4.2.1 階段1: Non-work-preserving RM restart

在Hadoop2.4.0發行的時候，只有階段1實現了。簡要描述階段1的過程如下：

1. RM通過state-store在client提交應用時記錄application metadata（如ApplicationSubmissionContext等），並記錄應用完成時的狀態（如failed,killed,finished），以及保存用戶的私密信息（如security keys, tokens）在一個安全的環境。
2. 任何時候RM停止了工作，當它重啟時重新載入state-store中的信息，重新提交RM停止工作前那些會完成的應用。
3. NodeManager和client會持續發送心跳信息給RM直到RM恢復。當RM恢復時，會根據心跳信息給所有的NM和AM發送一個重啟同步的命令。
4. 在Hadoop2.4.0發行時，NM和AM對RM的同步命令的處理方式如下：NM會kill它管理的所有container，然后重新向RM注冊。從RM的視角，這些重新注冊的NM就跟新加入的NM一樣；而AM則會立即停止。
5. 在RM完成重載所有應用的metadata、credential信息到內存后，它會為每個未完成的應用重新創建新的AM，然后重新執行應用。

這種方式會導致之前正在執行的應用的工作丟失。

疑問：並不是所有應用都是允許被重復執行的，這些任務怎么辦？

4.2.2 階段2: Work-preserving RM restart

隨着Hadoop2.6.0的發布，RM重啟的功能得到了加強，解決了之前存在的必須kill執行中應用的缺陷。

除了階段1完成的狀態持久化工作之外，階段2聚焦於重建YRAN集群的整個運行時狀態，主要是核心調度器scheduler（跟蹤所有containers的生命周期，應用的headroom以及資源請求，隊列的資源使用情況等）的狀態。這樣使得RM不需要kill AM以及從頭開始重跑應用。應用可以直接與RM同步恢復執行。

在這個階段，NM繼續管理containers，並發送containers的狀態給新的RM。RM通過吸納containers的信息，重建container實例以及相關聯的應用的調度狀態。同時，AM需要重新發送未完成的資源請求給RM，因為RM可能已經丟失了這些未完成的請求。編寫應用的作者使用AMRMClient庫與RM通信，不需要去考慮AM重新發送資源請求的部分，這些已經包含在庫本身了。

疑點： RM宕機時，AM和NM發現其宕機了，contaner中的應用是會繼續執行還是暫停等待RM恢復？——更合理的方式應該是暫停執行

4.3 配置

1. Enable RM Restart

<property>
    <name>yarn.resourcemanager.recovery.enabled</name>
    <value>true</value>
</property>

2. Configure the state-store for persisting the RM stats

<property>
    <name>yarn.resourcemanager.store.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
</property>

可選值：

• org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore
• org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore
• org.apache.hadoop.yarn.server.resourcemanager.recovery.LeveldbRMStateStore

默認是第二種，基於Hadoop文件系統（HDFS或本地FS）。
但是只有第一種ZKRMStateStore方式可以支持RM HA。

3. Configurations for Zookeeper based state-store implementation

<property>
    <name>yarn.resourcemanager.zk-address</name>
    <value>classb-ds-bigdata9.server.163.org:2181,classb-ds-bigdata10.server.163.org:2181,classb-ds-bigdata11.server.163.org:2181</value>
</property>
<property>
    <name>yarn.resourcemanager.zk-state-store.parent-path</name>
    <value>/rmstore-hp8</value>
</property>

其他的關於ResourceManager Restart的配置可參考ResourceManager Restart。

5. RM高可用（ResourceManager HA）

5.1 簡介

這一章簡單介紹RM的高可用特性，以及如何配置和使用該特性。RM負責集群的資源管理，和應用（如MapReduce作業）的調度。在Hadoop2.4發行前，RM是整個YARN集群的一個單點故障（single point of failure）。高可用特性以一對Active/Standby RM的形式增加了備份，從而有效避免了單點故障的風險。

5.2 RM HA架構

圖4 RM-HA Architecuture

RM高可用通過Active/Standby的架構實現。在任一時間點，只有一個RM處於Active狀態，但可以有一個或多個RM處於Standby模式。一個Standby狀態的RM想成為Active，有兩種方式：

• 接收來自client的管理員命令
• 通過集成的failover-controller自動成為Active

5.2.1 手動故障轉移（Manual transitions and failover）

當自動failover沒有開啟時，管理員可以手動的轉移RM的狀態。通過"yarn rmadmin"命令先將Active-RM轉為Standby狀態，然后將一個Standby-RM轉為Active。

5.2.2 自動故障轉移（Automative failover）

RM可以委托基於Zookeeper的主從選舉器（ActiveStandbyElector）來決定哪個RM可以成為Active。當Active-RM宕機了變得無響應時，另一個RM可以自動成為Active然后接管之前的工作。

需要注意的是，跟HDFS中的情形不同，不需要再去起一個單獨的Zookeeper FC進程，因為ActiveStandbyElector已經嵌入到里RM中作為一個失敗檢測器和主選舉器（leader elector）。

5.2.3 Client, ApplicationMaster and NodeManager on RM failover

當存在多個RM時，各個客戶端和節點使用的配置文件（yarn-site.xml）中必須列出所有的RM。Client、AM、NodeManager在連接RM時，會以“圓桌輪詢”（round-robin）的方式一個個去遍歷各個RM，直到命中Active-RM。當一個Active-RM出故障里，它們又會繼續以“圓桌輪詢”的方式繼續尋找新的Active-RM。這塊默認的重試邏輯在org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider中實現。你也可以重寫這一塊邏輯，然后設置配置文件中yarn.client.failover-proxy-provider的值為你重寫的類名。

5.2.4 恢復之前的active-RM的狀態

隨着之前介紹的RM重啟機制的應用，RM可以在失敗后重新啟動時從state-store中恢復到失敗之前的狀態。而基於Zookeeper的RM高可用和使用基於Zookeeper的state-store相得益彰，我們只要保證Zookeeper上存儲RM狀態信息的節點對所有的Active/Standby RM都可見即可。並且，ZKRMStateStore實現了在任一時間點只允許單個RM節點擁有寫的權限。所以，在使用RM HA的集群，強烈推薦使用基於Zookeeper的state-store。

5.3 部署

5.3.1 配置

大部分的高可用特性都有眾多可調的參數。下面是一些常用的重要的參數。yarn-default.xml中包含了完整的參數列表，想要了解更多的其他參數可以去查閱yarn-default.xml。對於state-store的配置可以去看前一章的RM Restart。

Configureation Properties	Description
yarn.resourcemanager.zk-address	ZK地址，同時用於state-store和內置選主器。
yarn.resourcemanager.ha.enabled	啟用RM HA.
yarn.resourcemanager.ha.rm-ids	指定RM的邏輯ID.如：rm1,rm2。
yarn.resourcemanager.hostname.rm-id	為每個rm-id，指定默認host。
yarn.resourcemanager.address.rm-id	指定client提交作業時的專屬host（即ApplicationsManager地址）。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.scheduler.address.rm-id	指定AM請求資源的host(即Scheduler地址)。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.resource-tracker.address.rm-id	指定NodeManager連接RM的端口。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.admin.address.rm-id	指定接收管理員命令的host。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.webapp.address.rm-id	設定webapp的host。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.webapp.https.address.rm-id	設定webapp的https host。設置后，會覆蓋hostname.rm-id配置。
yarn.resourcemanager.ha.automatic-failover.enabled	啟用自動失敗轉移（failover）。如果HA啟用了，該設置會默認啟用
yarn.resourcemanager.ha.automatic-failover.embedded	使用內嵌的選主器來推薦Active RM。如果HA啟用了，該設置會默認啟用
yarn.resourcemanager.cluster-id	集群的id，供選主器使用，以防選擇Active RM給錯誤的集群。
yarn.client.failover-proxy-provider	指定Client、AM、NM取輪詢Active RM時的處理邏輯類。
yarn.client.failover-max-attempts	最大輪詢嘗試次數。

5.3.2 Admin commands

在hadoop-current/bin或yarn-current/bin目錄下可以執行一些HA相關命令：

（1）yarn rmadmin -getServiceState rmId 獲取rmId對應的RM狀態

示例：

hadoop@classb-ds-bigdata9:~/hadoop-current/bin$ ./yarn rmadmin -getServiceState rm1
active
hadoop@classb-ds-bigdata9:~/hadoop-current/bin$ ./yarn rmadmin -getServiceState rm2
standby

（2）yarn rmadmin -transitionToStandby rmId 切換rmId對應的RM的狀態為Standby

（3）yarn rmadmin -transitionToActive rmId 切換rmId對應的RM的狀態為Standby

需要注意的是，當automatic failover設置為enabled時，默認不能使用手動的狀態轉移命令。如果非要強制使用，可以加-forcemanual參數（不推薦，須謹慎）。

6. YARN常用命令

6.1 簡介

YARN的命令通過bin/yarn腳本命令執行。不帶任何參數直接執行yarn命令，可以打印所有命令的描述。運行yarn命令的標准姿勢是：yarn COMMAND COMMAND_OPTIONS。按照命令的使用場景可以划分為兩個不同的類型：User Commands和Administration Commands。

6.2 User Commands

用戶使用的一些有用命令。

6.2.1 application

使用方式： yarn application [options]
常用的參數：

Options	Description
-list	默認列出所有未完成(SUBMITTED, ACCEPTED, RUNNING)的應用
-appStates	與-list配合使用，用於過濾應用的狀態（多個狀態用逗號分隔）。如：yarn application -list -appStates ALL
-appTypes	與-list配合使用，用於過濾應用類型。如：yarn application -list -appTypes MAPREDUCE
-kill	殺死應用
-status	獲取應用的狀態

備注： 有效的應用狀態包括：ALL, NEW, NEW_SAVING, SUBMITTED, ACCEPTED, RUNNING, FINISHED, FAILED, KILLED。 有效的應用類型包括SPARK、MAPREDUCT等。

6.2.2 applicationattempt

使用方式： yarn application [options]

Options	Description
-list	列出該應用的每次attempt信息
-status	列出應用的某次attempt的狀態信息

6.2.3 yarn classpath

使用方式：yarn application [options]
打印獲取hadoop jar以及一些庫文件所必需的class path。

6.2.4 container

使用方式：yarn container [options]

Options	Description
-list	列出應用的某次attempt的的container信息
-status	打印container的狀態

6.2.5 jar

使用方式: yarn jar [mainClass] args...

將YARN的代碼綁定在jar文件中，通過命令行來執行。

6.2.6 logs

使用方式：yarn logs [options]

Options	Description
-applicationId	查看指定應用的日志
-appOwner	按照AppOwner過濾日志，默認是當前用戶
-containerId -nodeAddress	查看指定container的日志

6.2.7 node

使用方式：yarn node [options]

Options	Description
-list	列出所有運行中的計算節點。
-all	與-list配合使用，列出所有計算節點。如：yarn node -list -all
-states	與-list配合使用，按states過濾，多個states則用逗號分隔
-status	查看指定Node的狀態信息

備注：啟動/關閉NodeManager的方式略有調整：

• 關閉NodeManager：sudo ~/yarn-current/sbin/yarn-daemon.sh stop nodemanager
• 啟動NodeManager：sudo ~/yarn-current/sbin/yarn-daemon.sh start nodemanager

6.2.8 queue

使用方式：yarn queue [options]

Options	Description
-status	顯示隊列的狀態。

6.2.9 version

使用方式：yarn version
查看Hadoop的版本。

6.3 Administration Commands

管理員使用的一些有用命令。

6.3.1 daemonlog

使用方式：yarn daemonlog [options]

Options	Description
-getlevel host:httpport	查看運行在指定主機的進程的某個類的log等級
-setlevel host:httpport	設置對應的log level

6.3.2 nodemanager

使用方式：yarn nodemanager
啟動NodeManager

6.3.3 proxyserver

使用方式：yarn proxyserver
啟動web代理服務器

6.3.4 resourcemanager

使用方式：yarn resourcemanager [options]

Options	Description
format-state-store	啟動RM，同時格式化RMStateStore。

注意：format-state-store參數只能在RM不在運行狀態時使用。

其他更多的命令可以參考YARN Command。