YARN HA 架构分析
规划
YARN HA
hadoop001：zk rm(zkfc) nm
hadoop002：zk rm(zkfc) nm
hadoop003：zk nm
ZKFC: 线程 只作为RM进程的一个线程而非独立的进程存在
架构
图1 YARN-HA
RM：:
1.启动时候会向ZK的/rmstore目录写lock文件，写成功就为active，否则standby.
rm节点zkfc会一直监控这个lock文件是否存在，假如不存在，就为active，否则为standby.
2.接收client的请求，接收和监控NM的资源状况的汇报，负载资源的分配和调度。
3.启动和监控APPMASTER on NM节点的container。
**ZK：**存储RMStateStore。选举activeRM。
RMStateStore: 存储在zk的/rmstore目录下。
1.activeRM会向这个目录写APP信息
2.当activeRM挂了，另外一个standby RM通过ZKFC选举成功为active，会从/rmstore读取相应的作业信息。
重新构建作业的内存信息，启动内部的服务，
开始接收NM的心跳，构建集群的资源信息，并且接收客户端的作业提交请求。
NM:
节点资源的管理 、启动容器运行task计算 、上报资源
RM故障转移
ResourceManager HA通过一个主从架构实现 - 在任意时刻，总有一个RM是active的，而一个或更多的RM处于待机状态等待随时成为活动。触发活动的转换的条件是通过admin命令行或者在自动故障转移启用的情况下通过集成的故障切换控制器触发。
手动转换和故障切换
当自动故障切换没有启用时，管理员需要手动切换众多RM中的一个成为活动的。为了从一个RM到其他RM进行故障切换，做法通常是先将现在的主动的RM切为待机状态，然后再选择一个待机切为活动。所有这些都可以通过“yarn rmadmin”的命令行完成。
自动故障转移
RM有一个选项可以嵌入使用动物园管理员的ActiveStandbyElector来决定哪个RM成为活跃。当主动挂掉或者不响应时，另一个RM会自动被选举为主动然后接管集群。注意，并不需要像HDFS一样运行一个隔离的ZKFC守护进程，因为对于嵌入到RM中的ActiveStandbyElector表现出来就是在做故障检查领导状语从句选举，不用单独的ZKFC。
RM故障转移是客户端，ApplicationMaster和NodeManager处理
当存在多个RM时，客户端和节点使用的配置（yarn-site.xml）应该列出所有RM。客户端，应用程序管理器（AM）和节点管理器（NM）尝试以循环方式连接到RM，直到它们到达活动RM。如果活动停止，他们将恢复循环轮询，直到他们点击“新”活动。此默认重试逻辑实现为org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider。您可以通过实现org.apache.hadoop.yarn.client.RMFailoverProxyProvider并将yarn.client.failover-proxy-provider的值设置为类名来覆盖逻辑。
恢复以前的active-RM状态
随着ResourceManger重新启用，RM被晋升为活动状态负载RM内部状态，并继续从以前的主动离开的地方尽可能多地取决于RM重启功能操作。为先前提交给RM的每个托管应用程序生成一个新尝试。应用程序可以定期检查点，以避免丢失任何工作。必须从两个活动/备用RM中可见状态存储。目前，有两种用于持久性的RMStateStore实现 - FileSystemRMStateStore和ZKRMStateStore。该ZKRMStateStore隐式允许在任何时间点对单个RM进行写访问，因此是在HA群集中使用的推荐存储。当使用ZKRMStateStore时，不需要单独的防护机制来解决潜在的裂脑情况，其中多个RM可能潜在地承担活动角色。使用ZKRMStateStore时，建议不要在Zookeeper群集上设置“ zookeeper.DigestAuthenticationProvider.superDigest ”属性，以确保zookeeper admin无权访问YARN应用程序/用户凭据信息。
ResourceManager HA与NameNode HA的区别：
在namenode HA是一个active，一个standby节点
但是resourcemanager HA是一个active 和多个standby节点。
脑裂问题
同NameNode HA。