[RM HA 2] Hadoop 2.0 ResourceManager HA原理
2014-01-22 11:19
169 查看
继上篇文章验证Cloudera RM HA功能后,现在开始分析Cloudera RM HA的原理。
计划外的机器挂掉
计划内的如软件和硬件升级等.
RM 的作业信息存储在ZK的/rmstore下,Active RM向这个目录写App信息。
RM启动的时候会通过向ZK的/hadoop-ha目录下写一个Lock文件,写成功则成为Active,否则为Standby,Standby RM会一直监控Lock文件是否存在,如果不存在则会试图去创建,即争取成为Active RM。
当Active RM挂掉,另外一个Standby RM成功转换为Active RM后,会从/rmstore读取相应的作业信息,重新构建作业的内存信息。然后启动内部服务,开始接收NM的心跳,构建集群资源信息,并接收客户端提交作业的请求等。
社区trunk版本当前也已经支持RM HA,但只支持手动切换,不支持Auto Failover。社区的基本原理和Cloudera RM HA类似,其架构图如下图所示:
对比Cloudera RM HA的架构图,仅少了Auto Failover部分。
服务端RM HA的关键部分主要为RMStateStore和ZKFailoverController。RMStateStore是实现RM状态存储的基类,主要包括存储和加载RM状态等方法。实现类主要包括FileSystemRMStateStore和ZKRMStateStore。类图如下图所示。
ZKFailoverController中维护着ActiveStandbyElector和HealthMonitor,ActiveStandbyElector主要工作是。
1. 初始化时在ZK上创建一个Lock文件,
2. Standby RM运行过程中监控ZM上的Lock文件是否存在。
HealthMonitor的主要工作是检查自己(RM)的健康状态,通过HAServiceStatus提供的getServiceStatus()和monitorHealth()方法,如果自己健康的,则会试图创建Lock文件,按照结果成为active或standby。下图是ZKFailoverController的类图,图中可以看出,Cloudera的Hadoop版本中,NameNode、Jobtracker和ResourceManager都采用相同的Auto Failover机制。
其中ClientRMProxy,代理ApplicationClientProtocol、ApplicationMasterProtocol、ResourceManagerAdministrationProtocol,实现 Yarn client、AM与RM的连接。ServerRMProxy提供给NM连接RM使用。代理ResourceTracker。
设计目标
主要目的是为了解决两种问题计划外的机器挂掉
计划内的如软件和硬件升级等.
架构
流程:两个RM, 启动的时候都是standby, 进程启动以后状态未被加载, 转换为active后才会加载相应的状态并启动服务. RM的状态通过配置可以存储在zookeeper, HDFS上。Standby转换到active可以通过命令或开启auto failover。RM 的作业信息存储在ZK的/rmstore下,Active RM向这个目录写App信息。
RM启动的时候会通过向ZK的/hadoop-ha目录下写一个Lock文件,写成功则成为Active,否则为Standby,Standby RM会一直监控Lock文件是否存在,如果不存在则会试图去创建,即争取成为Active RM。
当Active RM挂掉,另外一个Standby RM成功转换为Active RM后,会从/rmstore读取相应的作业信息,重新构建作业的内存信息。然后启动内部服务,开始接收NM的心跳,构建集群资源信息,并接收客户端提交作业的请求等。
社区trunk版本当前也已经支持RM HA,但只支持手动切换,不支持Auto Failover。社区的基本原理和Cloudera RM HA类似,其架构图如下图所示:
对比Cloudera RM HA的架构图,仅少了Auto Failover部分。
服务端RM HA的关键部分主要为RMStateStore和ZKFailoverController。RMStateStore是实现RM状态存储的基类,主要包括存储和加载RM状态等方法。实现类主要包括FileSystemRMStateStore和ZKRMStateStore。类图如下图所示。
ZKFailoverController中维护着ActiveStandbyElector和HealthMonitor,ActiveStandbyElector主要工作是。
1. 初始化时在ZK上创建一个Lock文件,
2. Standby RM运行过程中监控ZM上的Lock文件是否存在。
HealthMonitor的主要工作是检查自己(RM)的健康状态,通过HAServiceStatus提供的getServiceStatus()和monitorHealth()方法,如果自己健康的,则会试图创建Lock文件,按照结果成为active或standby。下图是ZKFailoverController的类图,图中可以看出,Cloudera的Hadoop版本中,NameNode、Jobtracker和ResourceManager都采用相同的Auto Failover机制。
客户端的实现机制
在RM HA之前,客户端与RM的通信直接使用ApplicationClientProtocol等协议,增加RM HA后,客户端使用RetryPolicy,它提供了一种重试机制,但一个RM连不上,则会Failover到另外一台RM上。具体的实现方法是采用动态代理模式,增加RMProxy实现retry方式连接RM。下图是RMProxy的类图。其中ClientRMProxy,代理ApplicationClientProtocol、ApplicationMasterProtocol、ResourceManagerAdministrationProtocol,实现 Yarn client、AM与RM的连接。ServerRMProxy提供给NM连接RM使用。代理ResourceTracker。
相关文章推荐
- 配置Hadoop2.xx的高可用(Hadoop2.0 HA)
- Hadoop 2.0 NameNode HA和Federation实践
- Hadoop 2.0 – HA功能中ZKFC对NN状态的控制
- hadoop2.0 HA的主备自动切换
- hadoop2.0 HA的主备自动切换
- Hadoop 2.0 NameNode HA和Federation实践
- Hadoop2.0的HA介绍
- Hadoop 2.0 NameNode HA和Federation实践
- Hadoop2.0的HA介绍
- Hadoop2.0的HA介绍
- hadoop2.0 QJM方式的HA的配置
- Hadoop 2.0 Yarn代码:RM与NM代码_心跳驱动服务分析_1 初始阶段(Job提交前)
- hadoop2.0 federation与HA的配置
- Hadoop2.0的HA介绍
- Hadoop 2.0 – HA功能中ZKFC对NN状态的控制
- Hadoop 2.0 NameNode HA和Federation实践
- Hadoop学习六:YARN的RM做HA
- Hadoop 2.0 中 NameNode/ResourceManager HA 总结
- Hadoop 2.0 HA高可用集群安装配置
- Hadoop系列-YARN RM HA 高可用集群