第七章 YARN框架概述與集群部署

第七章YARN框架概述與集群部署1YARN集群安裝部署ApacheHadoopYARN框架概述YARN角色組件、架構(gòu)32目錄數(shù)據(jù)、程序、運(yùn)算資源（內(nèi)存、CPU）三者組在一起，才能完成數(shù)據(jù)的計(jì)算處理過程。在單機(jī)環(huán)境下，三者之間協(xié)調(diào)配合不是太大問題。為了應(yīng)對(duì)海量數(shù)據(jù)的處理場(chǎng)景，Hadoop軟件出現(xiàn)并提供了分布式處理思想。分布式環(huán)境下的三者如何協(xié)調(diào)好將成為關(guān)鍵。通過對(duì)Hadoop版本演進(jìn)的簡(jiǎn)單回顧，可以讓我們知道YARN的產(chǎn)生和發(fā)展簡(jiǎn)史，洞悉YARN發(fā)展進(jìn)程。YARN產(chǎn)生和發(fā)展簡(jiǎn)史背景很多Hadoop的早期用戶使用Hadoop的方式與在眾多主機(jī)上運(yùn)行桌面應(yīng)用程序類似。

在少量幾個(gè)節(jié)點(diǎn)上手工建立一個(gè)集群；

將數(shù)據(jù)載入Hadoop分布式文件系統(tǒng)（HDFS）；

通過運(yùn)行MapReduce任務(wù)來運(yùn)算并獲得結(jié)果；

然后拆掉集群。這種方式的一部分原因是沒有在HadoopHDFS上持久存儲(chǔ)數(shù)據(jù)的迫切需求，另一部分原因是沒有共享數(shù)據(jù)和計(jì)算結(jié)果的動(dòng)機(jī)。YARN產(chǎn)生和發(fā)展簡(jiǎn)史背景AdHoc應(yīng)當(dāng)理解為專用的、特定的意思（數(shù)倉領(lǐng)域中常理解為即席）。AdHoc集群時(shí)代標(biāo)志著Hadoop集群的起源，集群以AdHoc、單用戶方式建立。后來，隨著私人集群的使用和Hadoop容錯(cuò)性的提高，持久的HDFS集群出現(xiàn)，并且實(shí)現(xiàn)了HDFS集群的共享，把常用和感興趣的數(shù)據(jù)集載入HDFS共享集群中。當(dāng)共享HDFS成為現(xiàn)實(shí)，還沒實(shí)現(xiàn)共享的計(jì)算平臺(tái)就成為關(guān)切對(duì)象。不同于HDFS，為多個(gè)組織的多個(gè)用戶簡(jiǎn)單設(shè)置一個(gè)共享MapReduce集群并非易事。尤其是集群下的物理資源的共享很不理想。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段0：AdHoc集群為了解決集群條件下的多租戶問題，Yahoo發(fā)展并且部署了稱為“HadooponDemand”的平臺(tái)。HadoopOnDemand(HOD)是一個(gè)能在大規(guī)模物理集群上供應(yīng)虛擬Hadoop集群的系統(tǒng)。在已經(jīng)分配的節(jié)點(diǎn)上，HOD會(huì)啟動(dòng)MapReduce和HDFS守護(hù)進(jìn)程來響應(yīng)用戶數(shù)據(jù)和應(yīng)用的請(qǐng)求。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段1：HOD集群主要特點(diǎn)：用戶可以使用HOD來同時(shí)分配多個(gè)MapReduce集群。缺點(diǎn)包括：無法支持?jǐn)?shù)據(jù)本地化、資源回收效率低、無動(dòng)態(tài)擴(kuò)容縮容能力，多租戶共享延遲高等。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段1：HOD集群共享MapReduce計(jì)算集群就是Hadoop1.x版本里的主要架構(gòu)模型。主要組件JobTracker：一個(gè)中央守護(hù)進(jìn)程，負(fù)責(zé)運(yùn)行集群上的所有作業(yè)。TaskTracker：系統(tǒng)里的從進(jìn)程，根據(jù)JobTracker的指令來執(zhí)行任務(wù)。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段2：共享計(jì)算集群主要弊端：JobTracker身兼多職、壓力大（作業(yè)數(shù)據(jù)管理、作業(yè)狀態(tài)記錄、作業(yè)調(diào)度）、可靠性和可用性欠缺（JobTracker單點(diǎn)故障）、計(jì)算模型單一（不能萬物皆MapReduce）。且MapReduce框架本身需要迭代優(yōu)化。但是計(jì)算和資源管理綁定在了一起，使得MapReduce的演變比較困難。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段2：共享計(jì)算集群針對(duì)共享計(jì)算集群，JobTracker需要徹底地重寫，才能解決擴(kuò)展性的主要問題。但是，這種重寫即使成功了，也不一定能解決平臺(tái)和用戶代碼的耦合問題，也不能解決用戶對(duì)非MapReduce編程模型的需求。如果不做重大的重新設(shè)計(jì)，集群可用性會(huì)繼續(xù)被捆綁到整個(gè)系統(tǒng)的穩(wěn)定性上。拆分MapReduce，剝離出資源管理成為單獨(dú)框架，YARN閃亮登場(chǎng)，MapReduce專注于數(shù)據(jù)處理，兩者解耦合。YARN被設(shè)計(jì)用以解決以往架構(gòu)的需求和缺陷的資源管理和調(diào)度軟件。YARN產(chǎn)生和發(fā)展簡(jiǎn)史Hadoop演進(jìn)階段--階段3：YARN集群可擴(kuò)展性：可以平滑的擴(kuò)展至數(shù)萬節(jié)點(diǎn)和并發(fā)的應(yīng)用?？删S護(hù)性：保證集群軟件的升級(jí)與用戶應(yīng)用程序完全解耦。多租戶：需要支持在同一集群中多個(gè)租戶并存，同時(shí)支持多個(gè)租戶間細(xì)顆粒度地共享單個(gè)節(jié)點(diǎn)。位置感知：將計(jì)算移至數(shù)據(jù)所在位置。高集群使用率：實(shí)現(xiàn)底層物理資源的高使用率。YARN產(chǎn)生和發(fā)展簡(jiǎn)史對(duì)YARN的需求安全和可審計(jì)的操作：繼續(xù)以安全的、可審計(jì)的方式使用集群資源?？煽啃院涂捎眯裕壕哂懈叨瓤煽康挠脩艚换?、并支持高可用性對(duì)編程模型多樣化的支持：支持多樣化的編程模型，需要演進(jìn)為不僅僅以MapReduce為中心。靈活的資源模型：支持各個(gè)節(jié)點(diǎn)的動(dòng)態(tài)資源配置以及靈活的資源模型。向后兼容：保持現(xiàn)有的MapReduce應(yīng)用程序的向后兼容性。YARN產(chǎn)生和發(fā)展簡(jiǎn)史對(duì)YARN的需求ApacheHadoopYARN（YetAnotherResourceNegotiator，另一種資源協(xié)調(diào)者）是一種新的Hadoop資源管理器。YARN是一個(gè)通用資源管理系統(tǒng)和調(diào)度平臺(tái)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度。

它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。YARN簡(jiǎn)介簡(jiǎn)介如何理解通用資源管理系統(tǒng)和調(diào)度平臺(tái)？資源管理系統(tǒng)：集群的硬件資源，和程序運(yùn)行相關(guān)，比如內(nèi)存、CPU等。調(diào)度平臺(tái)：多個(gè)程序同時(shí)申請(qǐng)計(jì)算資源如何分配，調(diào)度的規(guī)則（算法）。通用：不僅僅支持MapReduce程序，理論上支持各種計(jì)算程序。YARN不關(guān)心你干什么，只關(guān)心你要資源，在有的情況下給你，用完之后還我。YARN簡(jiǎn)介簡(jiǎn)介可以把HadoopYARN理解為相當(dāng)于一個(gè)分布式的操作系統(tǒng)平臺(tái)，而MapReduce等計(jì)算程序則相當(dāng)于運(yùn)行于操作系統(tǒng)之上的應(yīng)用程序，YARN為這些程序提供運(yùn)算所需的資源（內(nèi)存、CPU等）。Hadoop能有今天這個(gè)地位，YARN可以說是功不可沒。因?yàn)橛辛薡ARN，更多計(jì)算框架可以接入到HDFS中，而不單單是MapReduce，正式因?yàn)閅ARN的包容，使得其他計(jì)算框架能專注于計(jì)算性能的提升。HDFS可能不是最優(yōu)秀的大數(shù)據(jù)存儲(chǔ)系統(tǒng)，但卻是應(yīng)用最廣泛的大數(shù)據(jù)存儲(chǔ)系統(tǒng)，YARN功不可沒。YARN簡(jiǎn)介簡(jiǎn)介Hadoop從1到2的過程中，最大的變化就是拆分MapReduce，剝離出新的單獨(dú)組件：YARN。Hadoop3系列架構(gòu)整體和2系列一致。在Hadoop1中，MapReduce（MRv1）負(fù)責(zé):數(shù)據(jù)計(jì)算、資源管理，身兼多職。在Hadoop2中，MapReduce（MRv2）負(fù)責(zé)數(shù)據(jù)計(jì)算，YARN負(fù)責(zé)資源管理。YARN與MRv1區(qū)別概述MRv1包括三個(gè)部分運(yùn)行時(shí)環(huán)境（JobTracker和TaskTracker）、編程模型（MapReduce）、數(shù)據(jù)處理引擎（Map

Task和Reduce

Task）.JobTracker負(fù)責(zé)資源和任務(wù)的管理與調(diào)度，TaskTracker負(fù)責(zé)單個(gè)節(jié)點(diǎn)的資源管理和任務(wù)執(zhí)行。MRv1將資源管理和應(yīng)用程序管理兩部分混雜在一起，使得它在擴(kuò)展性、容錯(cuò)性和多框架支持等方面存在明顯缺陷。YARN與MRv1區(qū)別MRv1介紹MRv2重用了MRv1中的編程模型和數(shù)據(jù)處理引擎。但運(yùn)行時(shí)環(huán)境（resourcemanager、nodemanager）被完全重寫,由YARN來專管資源管理和任務(wù)調(diào)度。并且YARN將程序內(nèi)部具體管理職責(zé)交給一個(gè)叫做ApplicationMaster的角色。自己專心于集群資源管理，成為一個(gè)通用的資源管理系統(tǒng)。YARN與MRv1區(qū)別YARN介紹1YARN集群安裝部署ApacheHadoopYARN框架概述YARN角色組件、架構(gòu)32目錄ApacheHadoopYARN是一個(gè)標(biāo)準(zhǔn)的Master/Slave集群（主從架構(gòu)）。其中ResourceManager（RM）為Master，NodeManager（NM）為Slave。常見的是一主多從集群，也可以搭建RM的HA高可用集群。YARN集群角色、部署規(guī)劃集群角色--概述RM是YARN中的主角色，決定系統(tǒng)中所有應(yīng)用程序之間資源分配的最終權(quán)限，即最終仲裁者。RM接收用戶的作業(yè)提交，并通過NodeManager分配、管理各個(gè)機(jī)器上的計(jì)算資源。資源以Container形式給與。此外，RM還具有一個(gè)可插拔組件-scheduler，負(fù)責(zé)為各種正在運(yùn)行的應(yīng)用程序分配資源，根據(jù)策略進(jìn)行調(diào)度。YARN集群角色、部署規(guī)劃集群角色--ResourceManager（RM）NM是YARN中的從角色，一臺(tái)機(jī)器上一個(gè)，負(fù)責(zé)管理本機(jī)器上的計(jì)算資源。NM根據(jù)RM命令，啟動(dòng)Container容器、監(jiān)視容器的資源使用情況。并且向RM主角色匯報(bào)資源使用情況。YARN集群角色、部署規(guī)劃集群角色--NodeManager（NM）理論上YARN集群可以部署在任意機(jī)器上，但是實(shí)際中，通常把NodeManager和DataNode部署在同一臺(tái)機(jī)器上。（有數(shù)據(jù)的地方就有可能產(chǎn)生計(jì)算，移動(dòng)程序的成本比移動(dòng)數(shù)據(jù)的成本低）作為ApacheHadoop的一部分，通常會(huì)把YARN集群和HDFS集群一起搭建。YARN集群角色、部署規(guī)劃集群部署規(guī)劃服務(wù)器運(yùn)行角色masternamenodedatanoderesourcemanager

nodemanagernode1secondarynamenodedatanodenodemanagernode2datanodenodemanagerResourceManager負(fù)責(zé)資源管理和應(yīng)用的調(diào)度，是YARN的核心組件，存在單點(diǎn)故障的問題。ResourceManagerRestart重啟機(jī)制是使RM在重啟動(dòng)時(shí)能夠使Yarn集群正常工作的特性，并且使RM的出現(xiàn)的失敗不被用戶知道。重啟機(jī)制并不是自動(dòng)幫我們重啟的意思。所以說不能解決單點(diǎn)故障問題。YARNRM重啟機(jī)制概述不開啟RM重啟機(jī)制現(xiàn)象如果RM出現(xiàn)故障重啟之后，之前的信息將會(huì)消失。正在執(zhí)行的作業(yè)也會(huì)失敗。YARNRM重啟機(jī)制演示不保留工作RM重啟機(jī)制只保存了application提交的信息和最終執(zhí)行狀態(tài)，并不保存運(yùn)行過程中的相關(guān)數(shù)據(jù)，所以RM重啟后，會(huì)先殺死正在執(zhí)行的任務(wù)，再重新提交，從零開始執(zhí)行任務(wù)。保留工作RM重啟機(jī)制保存了application運(yùn)行中的狀態(tài)數(shù)據(jù)，所以在RM重啟之后，不需要?dú)⑺乐暗娜蝿?wù)，而是接著原來執(zhí)行到的進(jìn)度繼續(xù)執(zhí)行。YARNRM重啟機(jī)制保留工作與不保留工作的區(qū)別當(dāng)Client提交一個(gè)application給RM時(shí)，RM會(huì)將該application的相關(guān)信息存儲(chǔ)起來，具體存儲(chǔ)的位置是可以在配置文件中指定的，可以存儲(chǔ)到本地文件系統(tǒng)上，也可以存儲(chǔ)到HDFS或者是Zookeeper上，此外RM也會(huì)保存application的最終狀態(tài)信息(failed，killed，finished),如果是在安全環(huán)境下運(yùn)行，RM還會(huì)保存相關(guān)證書文件。當(dāng)RM被關(guān)閉后，NodeManager(以下簡(jiǎn)稱NM)和Client由于發(fā)現(xiàn)連接不上RM，會(huì)不斷的向RM發(fā)送消息，以便于能及時(shí)確認(rèn)RM是否已經(jīng)恢復(fù)正常，當(dāng)RM重新啟動(dòng)后，它會(huì)發(fā)送一條re-sync(重新同步)的命令給所有的NM和ApplicationMaster(以下簡(jiǎn)稱AM)，NM收到重新同步的命令后會(huì)殺死所有的正在運(yùn)行的containers并重新向RM注冊(cè)，從RM的角度來看，每臺(tái)重新注冊(cè)的NM跟一臺(tái)新加入到集群中NM是一樣的。AM收到重新同步的命令后會(huì)自行將自己殺掉。接下來，RM會(huì)將存儲(chǔ)的關(guān)于application的相關(guān)信息讀取出來，將在RM關(guān)閉之前最終狀態(tài)為正在運(yùn)行中的application重新提交運(yùn)行。YARNRM重啟機(jī)制Non-work-preservingRMrestart與不保留工作不同的地方在于，RM會(huì)記錄下container的整個(gè)生命周期的數(shù)據(jù)，包括application運(yùn)行的相關(guān)數(shù)據(jù)，資源申請(qǐng)狀況，隊(duì)列資源使用狀況等數(shù)據(jù)。當(dāng)RM重啟之后，會(huì)讀取之前存儲(chǔ)的關(guān)于application的運(yùn)行狀態(tài)的數(shù)據(jù)，同時(shí)發(fā)送re-sync的命令，與第一種方式不同的是，NM在接受到重新同步的命令后并不會(huì)殺死正在運(yùn)行的containers，而是繼續(xù)運(yùn)行containers中的任務(wù)，同時(shí)將containers的運(yùn)行狀態(tài)發(fā)送給RM，之后，RM根據(jù)自己所掌握的數(shù)據(jù)重構(gòu)container實(shí)例和相關(guān)的application運(yùn)行狀態(tài)，如此一來，就實(shí)現(xiàn)了在RM重啟之后，緊接著RM關(guān)閉時(shí)任務(wù)的執(zhí)行狀態(tài)繼續(xù)執(zhí)行。YARNRM重啟機(jī)制Work-preservingRMrestartRM的重啟機(jī)制本質(zhì)上是將RM內(nèi)部的狀態(tài)信息寫入外部存儲(chǔ)介質(zhì)中。在RM啟動(dòng)時(shí)會(huì)初始化狀態(tài)信息的目錄，當(dāng)Application運(yùn)行時(shí)會(huì)將相關(guān)的狀態(tài)寫入對(duì)應(yīng)的目錄下。如果RM發(fā)生故障切換或者重啟，可以通過外部存儲(chǔ)進(jìn)行恢復(fù)。RM狀態(tài)存儲(chǔ)的實(shí)現(xiàn)是RMStateStore抽象類，YARN對(duì)RMStateStore提供了幾種實(shí)例：YARNRM重啟機(jī)制RM狀態(tài)數(shù)據(jù)的存儲(chǔ)介質(zhì)RM的所有狀態(tài)信息存儲(chǔ)在ZooKeeper的/rmstore/ZKRMStateRoot下；主要保存了RM資源預(yù)留信息、應(yīng)用信息，應(yīng)用的Token信息，RM版本信息。YARNRM重啟機(jī)制ZKRMStateStoreReservationSystemRoot#RM的資源預(yù)留系統(tǒng)，對(duì)應(yīng)的實(shí)現(xiàn)是ReservationSystem接口的子類。

RMAppRoot#Application信息，對(duì)應(yīng)的實(shí)現(xiàn)是RMApp接口的子類。

AMRMTokenSecretManagerRoot#ApplicationAttempt的Token信息，RM會(huì)將每個(gè)Token保存在本地的內(nèi)存中，直到應(yīng)用程序運(yùn)行完成為止，并保存到ZooKeeper存儲(chǔ)以供重新啟動(dòng)。對(duì)應(yīng)的實(shí)現(xiàn)是AMRMTokenSecretManager類。

EpochNode#RM的保存工作重啟的時(shí)間信息。每次RM重新啟動(dòng)時(shí)，紀(jì)元都會(huì)增加。它用于確保ContainerId的唯一性。對(duì)應(yīng)的實(shí)現(xiàn)是Epoch抽象類。

RMDTSecretManagerRoot#一個(gè)特定于RM的委托令牌保密管理器。保密管理器負(fù)責(zé)生成和接受每個(gè)令牌的密碼。

RMVersionNode#RM的版本信息。yarn-site.xml配置啟用RM重啟功能，使用Zookeeper進(jìn)行轉(zhuǎn)態(tài)數(shù)據(jù)存儲(chǔ)。YARNRM重啟機(jī)制配置<property>

<name>hadoop.zk.address</name>

<value>:2181,:2181,:2181</value>

</property>

<property>

<name>yarn.resourcemanager.recovery.enabled</name>

<value>true</value>

</property>

<property>

<name>yarn.resourcemanager.store.class</name>

<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>

</property>開啟RM重啟機(jī)制現(xiàn)象如果RM出現(xiàn)故障重啟之后，如果是不保留工作的重啟，作業(yè)重新執(zhí)行，如果是保留工作的重啟，作業(yè)繼續(xù)執(zhí)行。YARNRM重啟機(jī)制演示ResourceManager負(fù)責(zé)資源管理和應(yīng)用的調(diào)度，是YARN的核心組件，集群的主角色。在Hadoop2.4之前，ResourceManager是YARN群集中的SPOF（SinglePointofFailure，單點(diǎn)故障）。為了解決RM的單點(diǎn)故障問題，YARN設(shè)計(jì)了一套Active/Standby模式的ResourceManagerHA架構(gòu)。YARNHA集群背景Hadoop官方推薦方案：基于Zookeeper集群實(shí)現(xiàn)YARNHA。YARNHA集群架構(gòu)實(shí)現(xiàn)HA集群的關(guān)鍵是：主備之間狀態(tài)數(shù)據(jù)同步、主備之間順利切換（故障轉(zhuǎn)移機(jī)制）針對(duì)數(shù)據(jù)同步問題，可以通過zk來存儲(chǔ)共享集群的狀態(tài)數(shù)據(jù)。因?yàn)閦k本質(zhì)也是一個(gè)小文件存儲(chǔ)系統(tǒng)。針對(duì)主備順利切換，可以手動(dòng)，也可以基于zk自動(dòng)實(shí)現(xiàn)。YARNHA集群架構(gòu)第一種：手動(dòng)故障轉(zhuǎn)移管理員使用命令手動(dòng)進(jìn)行狀態(tài)切換。第二種：自動(dòng)故障轉(zhuǎn)移RM可以選擇嵌入基于Zookeeper的ActiveStandbyElector來實(shí)現(xiàn)自動(dòng)故障轉(zhuǎn)移。YARN的自動(dòng)故障轉(zhuǎn)移不需要像HDFS那樣運(yùn)行單獨(dú)的ZKFC守護(hù)程序，因?yàn)锳ctiveStandbyElector是一個(gè)嵌入在RM中充當(dāng)故障檢測(cè)器和Leader選舉的線程，而不是單獨(dú)的ZKFC守護(hù)進(jìn)程。YARNHA集群故障轉(zhuǎn)移機(jī)制創(chuàng)建鎖節(jié)點(diǎn)：在ZooKeeper上會(huì)創(chuàng)建一個(gè)叫做ActiveStandbyElectorLock的鎖節(jié)點(diǎn)，所有的RM在啟動(dòng)的時(shí)候，都會(huì)去競(jìng)爭(zhēng)寫這個(gè)臨時(shí)的Lock節(jié)點(diǎn)，而ZooKeeper能保證只有一個(gè)RM創(chuàng)建成功。創(chuàng)建成功的RM就切換為Active狀態(tài)，沒有成功的RM則切換為Standby狀態(tài)。注冊(cè)Watcher監(jiān)聽：Standby狀態(tài)的RM向ActiveStandbyElectorLock節(jié)點(diǎn)注冊(cè)一個(gè)節(jié)點(diǎn)變更的Watcher監(jiān)聽，利用臨時(shí)節(jié)點(diǎn)的特性（會(huì)話結(jié)束節(jié)點(diǎn)自動(dòng)消失），能夠快速感知到Active狀態(tài)的RM的運(yùn)行情況。準(zhǔn)備切換：當(dāng)Active狀態(tài)的RM出現(xiàn)故障（如宕機(jī)或網(wǎng)絡(luò)中斷），其在ZooKeeper上創(chuàng)建的Lock節(jié)點(diǎn)隨之被刪除，這時(shí)其它各個(gè)Standby狀態(tài)的RM都會(huì)受到ZooKeeper服務(wù)端的Watcher事件通知，然后開始競(jìng)爭(zhēng)寫Lock子節(jié)點(diǎn)，創(chuàng)建成功的變?yōu)锳ctive狀態(tài)，其他的則是Standby狀態(tài)。YARNHA集群故障轉(zhuǎn)移原理（基于zk自動(dòng)切換）Fencing(隔離)：在分布式環(huán)境中，機(jī)器經(jīng)常出現(xiàn)假死的情況（常見的是GC耗時(shí)過長(zhǎng)、網(wǎng)絡(luò)中斷或CPU負(fù)載過高）而導(dǎo)致無法正常對(duì)外進(jìn)行及時(shí)響應(yīng)。如果有一個(gè)處于Active狀態(tài)的RM出現(xiàn)假死，其他的RM剛選舉出來新的Active狀態(tài)的RM，這時(shí)假死的RM又恢復(fù)正常，還認(rèn)為自己是Active狀態(tài)，這就是分布式系統(tǒng)的腦裂現(xiàn)象，即存在多個(gè)處于Active狀態(tài)的RM，可以使用隔離機(jī)制來解決此類問題。YARN的Fencing機(jī)制是借助ZooKeeper數(shù)據(jù)節(jié)點(diǎn)的ACL權(quán)限控制來實(shí)現(xiàn)不同RM之間的隔離。創(chuàng)建的根ZNode必須攜帶ZooKeeper的ACL信息，目的是為了獨(dú)占該節(jié)點(diǎn)，以防止其他RM對(duì)該ZNode進(jìn)行更新。借助這個(gè)機(jī)制假死之后的RM會(huì)試圖去更新ZooKeeper的相關(guān)信息，但發(fā)現(xiàn)沒有權(quán)限去更新節(jié)點(diǎn)數(shù)據(jù)，就把自己切換為Standby狀態(tài)。YARNHA集群故障轉(zhuǎn)移原理（基于zk自動(dòng)切換）安裝好zookeeper集群詳細(xì)安裝步驟可參考附件資料。YARNHA集群搭建步驟修改yarn-site.xmlYARNHA集群搭建步驟<!--刪除下面這個(gè)配置-->

<property>

<name>yarn.resourcemanager.hostname</name>

<value></value>

</property><property>

<name>yarn.resourcemanager.hostname.rm2</name>

<value></value>

</property>

<property>

<name>yarn.resourcemanager.webapp.address.rm1</name>

<value>:8088</value>

</property>

<property>

<name>yarn.resourcemanager.webapp.address.rm2</name>

<value>:8088</value>

</property>

<property>

<name>yarn.resourcemanager.ha.automatic-failover.enabled</name>

<value>true</value>

</property>

<property>

<name>hadoop.zk.address</name>

<value>:2181,:2181,:2181</value>

</property>

<property>

<name>yarn.resourcemanager.recovery.enabled</name>

<value>true</value>

</property>

<property>

<name>yarn.resourcemanager.store.class</name>

<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>

</property><!--增加下面配置--><property>

<name>yarn.resourcemanager.ha.enabled</name>

<value>true</value>

</property>

<property>

<name>yarn.resourcemanager.cluster-id</name>

<value>cluster1</value>

</property>

<property>

<name>yarn.resourcemanager.ha.rm-ids</name>

<value>rm1,rm2</value>

</property>

<property>

<name>yarn.resourcemanager.hostname.rm1</name>

<value></value>

</property>

集群同步y(tǒng)arn-site.xml配置文件YARNHA集群搭建步驟cd/export/server/hadoop-3.1.4/etc/hadoop/

scp-ryarn-site.xmlnode2:$PWD

scp-ryarn-site.xmlnode3:$PWD在node1上，啟動(dòng)yarn集群，可以發(fā)現(xiàn)啟動(dòng)了兩個(gè)RM進(jìn)程YARNHA集群?jiǎn)?dòng)查看HAYARN集群狀態(tài)YARNHA集群狀態(tài)查看yarnrmadmin-getAllServiceState

yarnrmadmin-getAllServiceStaterm1

yarnrmadmin-getAllServiceStaterm2分別登陸兩個(gè)RM所在機(jī)器的WebUI頁面在輸入node2:8088，回車之后會(huì)自動(dòng)跳轉(zhuǎn)到node1:8888.因?yàn)閚ode1是的是Active狀態(tài)，只有Active對(duì)外提供服務(wù)。YARNHA集群WebUI查看強(qiáng)制殺死節(jié)點(diǎn)的RM，基于ZooKeeper的ActiveStandbyElector自動(dòng)故障轉(zhuǎn)移策略將節(jié)點(diǎn)的RM選舉為Active狀態(tài)，表示故障轉(zhuǎn)移配置正確。YARNHA集群自動(dòng)故障切換在非自動(dòng)故障切換的YARN集群下進(jìn)行手動(dòng)故障切換可以使用命令進(jìn)行故障轉(zhuǎn)移切換。手動(dòng)故障切換命令yarnrmadmin-failoverrm1rm2

將rm1（）故障轉(zhuǎn)移到rm2（）需要注意，自動(dòng)切換開啟的情況下，手動(dòng)切換不可用。YARNHA集群手動(dòng)故障切換1YARN集群安裝部署ApacheHadoopYARN框架概述YARN角色組件、架構(gòu)32目錄YARN架構(gòu)體系官方架構(gòu)圖ResourceManagerNodeManagerApplicationMaster（AppMstr）ClientContainer容器（資源的抽象）YARN架構(gòu)體系官方架構(gòu)圖中出現(xiàn)的概念集群物理層面App層面YARN3大組件MR作業(yè)狀態(tài)匯報(bào)Container（Map|ReduceTask）-->Container（MrAppMaster）MR作業(yè)提交Client-->RM節(jié)點(diǎn)的狀態(tài)匯報(bào)NM-->RM資源的申請(qǐng)MrAppMaster-->RMYARN架構(gòu)體系核心交互流程ResourceManager（RM）YARN集群中的主角色，決定系統(tǒng)中所有應(yīng)用程序之間資源分配的最終權(quán)限，即最終仲裁者。接收用戶的作業(yè)提交，并通過NM分配、管理各個(gè)機(jī)器上的計(jì)算資源。NodeManager（NM）Y