Hadoop-2.4.1学习之高可用ResourceManager

原创 2014年12月04日 16:33:15

       在Hadoop-2.4之前,Yarn中的ResourceManager也是单点故障中的,就像Hadoop-1.x中的NameNode,由于Hadoop-2.X已经支持NameNode的HA(高可用性),那么自然也要在hadoop的某个版本中实现ResourceManager的HA,否则又会招致一些事后诸葛亮的诟病。本文将介绍RM的高可用性,并详细学习如何配置和使用该特性。就像NameNode的HA一样,ResourceManager的HA也是通过冗余的Active/Standby ResourceManagers消除单点故障所存在的问题。

      RM的HA架构如下(引自官方图片),该图所展示的架构与NameNode有很多相似之处,比如支持自动或手动的故障转移,使用ZooKeeper保存Active RM的状态等。


      ResourceManager的HA是通过Active/Standby架构实现的,在任何时间点只有一个RM处于active状态,而剩余的RM(一个或多个)则处于standby状态,时刻准备着接管active的工作。可以通过在CLI输入命令或者在自动故障转移启动的前提下通过集成的故障转移控制器实现standby到active的转换,也就是手动故障转移和自动故障转移。

      在没启用自动故障转移的情况下,管理员必须手动地将处于standby状态的RMs之一转换为active状态。手动故障转移必须首先将原先处于active的RM转换为standby状态,然后再将一个standby RM转换为active,具体的命令为:yarn rmadmin。在自动故障转移方面,RM与NameNode略有不同,RM不需要运行单独的守护进程ZKFC,这是因为RM有内置的基于ZooKeeper的ActiveStandbyElector类用于在active RM宕机或者无响应时自动选择哪个standbyRM将做为active RM,因为该类实现了ZKFC的功能。

      当存在多个RMs时,需要在yarn-site.xml中罗列所有RMs,这是因为客户端、ApplicationMasters (AMs) 和NodeManagers (NMs)以循环的方式尝试连接RM直到连接上active RM。当active RM不可用时,再按照循环的方式尝试连接RMs,直到遇上新的active RM。默认的尝试逻辑由org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider实现,可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider接口和设置yarn.client.failover-proxy-provider的值为新类以覆盖默认逻辑。

      如果也启用了RM的重启特性,正在变为active状态的RM能够加载RM的内部状态和尽可能多的继续先前active RM遗留的操作。将为每个之前提交到RM的应用程序提交新的尝试,应用程序可以周期性地进行检查点以避免丢失任何工作。状态存储必须对于Active/Standby RMs都是可见的,正如之前已经了解的,目前提供了两个状态存储:FileSystemRMStateStore和ZKRMStateStore,建议在RM HA集群中使用后者做为状态存储。

      正如Hadoop大部分特性都可以通过配置参数进行设置一样,RM的HA也可以通过下表中的参数进行设置(更详细的信息可以参考yarn-default.xml):

参数

描述

yarn.resourcemanager.zk-address

ZooKeeper服务器的地址(主机:端口号),既用于状态存储也用于内嵌的leader-election

yarn.resourcemanager.ha.enabled

是否启用RM HA,默认为false(不启用)。

yarn.resourcemanager.ha.rm-ids

RMs的逻辑id列表,用逗号分隔,如:rm1,rm2

yarn.resourcemanager.hostname.rm-id

每个rm-id的主机名,rm-id的值包含在上面的参数值中。

yarn.resourcemanager.ha.id

可选项,用于标识RM。如果设置了,管理员需要确保所有的RMs在配置中都有自己的ID

yarn.resourcemanager.ha.automatic-failover.enabled

是否启用自动故障转移。默认情况下,在启用HA时,启用自动故障转移。

yarn.resourcemanager.ha.automatic-failover.embedded

启用内置的自动故障转移。默认情况下,在启用HA时,启用内置的自动故障转移。

yarn.resourcemanager.cluster-id

集群的Idelector使用该值确保RM不会做为其它集群的active

yarn.client.failover-proxy-provider

Clients, AMsNMs使用该类故障转移到active RM

yarn.client.failover-max-attempts

FailoverProxyProvider尝试故障转移的最大次数。

yarn.client.failover-sleep-max-ms

故障转移间的最大休眠时间(单位:毫秒)。

yarn.client.failover-retries

每个尝试连接到RM的重试次数。

yarn.client.failover-retries-on-socket-timeouts

socket超时时,每个尝试连接到RM的重试次数。

      下面是RM故障转移的简单配置示例,在该示例中启用了HA,那么也就启用了自动故障转移。

<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>master1</value>
 </property>
 <property>
   <name>yarn.resourcemanager.hostname.rm2</name>
   <value>master2</value>
 </property>
 <property>
   <name>yarn.resourcemanager.zk-address</name>
   <value>zk1:2181,zk2:2181,zk3:2181</value>
 </property>

      正如上面提到的,hadoop也为管理员提供了CLI的方式管理RM HA,但在没有启用HA的情况下,下面的命令是不可用的:

[hadoop@hadoop ~]$ yarn rmadmin -getServiceState
Cannot run -getServiceState when ResourceManager HA is not enabled
[hadoop@hadoop ~]$ yarn rmadmin -transitionToStandby
Cannot run -transitionToStandby when ResourceManager HA is not enabled

      假设已经启用了HA,那么就可以通过CLI的方式查看RM的状态和手动进行故障转移,假设yarn.resourcemanager.ha.rm-ids的值为rm1和rm2:

$ yarn rmadmin -getServiceState rm1
 active
$ yarn rmadmin -getServiceState rm2
 standby

      手动故障转移必须在自动故障转移禁用的前提下执行,否则会出现split-brain的情形或者其它不正确的状态,手动故障转移的命令为:

$ yarn rmadmin -transitionToStandby rm1

相关文章推荐

hadoop2解决 NameNode 单点故障问题的 高可用集群配置

以前用hadoop2.2.0只搭建了hadoop的高可用,但在hadoop2.2.0中始终没有完成YARN HA的搭建,直接下载了hadoop最新稳定版本2.6.0完成了YARN HA及HADOOP ...

spark 1.1.0 编译使用 & 爬坑记录

虽然1.2.1版本也已经出来了,估计还是有很多人在用1.1.0或者1.0.0 版本。所以把编译和使用1.1.0版本时遇到的一些问题和解决思路写在这里,供参考。 因为我们对cdh版本的hadoop做了一...

spark on yarn 的那些坑

在公司6个节点的测试集群运行得好好的,结果也很正常,然后放上60个节点的预生产环境,我勒个擦,搞了我两天,主要是生产环境的那些家伙不配合,一个问题搞得拖啊拖 ,首先是安全认证问题,截取一两个有意义的吧...

Kylin build cube step 2 报错

Hive 1.2.1 HBase 0.98Kylin 1.5.1 Hadoop 2.5.1 2016-08-14 13:45:34,681 INFO  [pool-3-thread-4] ...

Hadoop系列-YARN RM HA 高可用集群

三 ResourceManager HA集群 3.1修改 yarn-site.xml   3.2 yarn-site.xml分发到其他节点 scpyarn-site.xml hadoop@had...

hadoop系列文档4-配置Yarn高可用HA

背景 之前有一篇高可用HDFS HA的配置文档,此文档类似上次,介绍如何配置高可用Yarn’s ResourceManager,在hadoop中默认只有一个ResourceManger,现在增加一个节...

(12)ResourceManager高可用性

介绍建筑 RM故障转移恢复以前的活跃RM的状态 部署 配置管理命令ResourceManager Web UI服务网页服务 介绍 本指南概述了YARN的ResourceMan...

Resourcemanager HA

1.官网resourcemanager HA  Introduction This guide provides an overview of High Availability of...

HDFS 和 YARN 的 HA 故障切换

一 非 HDFS HA 集群转换成 HA 集群 二 HDFS 的 HA 自动切换命令 1 获得当前 NameNode 的 active 和 standby 状态 2 NameNode 的 active...

Hadoop2的ResourceManager高可用配置

Hadoop 2.2没怎么关注过,太新,bug太多。2.4出来以后关注了一些东西,比如2.4里面直接带了ResourceManager的高可用,这点比较吸引人。之前2.2没注意有没有,貌似是没有,然后...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Hadoop-2.4.1学习之高可用ResourceManager
举报原因:
原因补充:

(最多只允许输入30个字)