如果我们采用单点的伪分布式部署，那么NN节点挂了，就不能对外提供服务。集群的话，存在两个NN节点，一个挂了，另外一个从standby模式直接切换到active状态，实时对外提供服务（读写）。在生产上，避免出现对外服务中断的情况，所以会考虑采用集群部署。

单点式伪分布：
NN
SNN secondary 1小时checkpoint
DN
HDFS HA：
NN active
NN standby 实时备份
DN
JN ： JounalNode 日志
ZKFC ： zookeeperFailoverController（控制NN为active还是standby）
图解如下：

1. 过程分析
   客户端上输入一个命令，然后NNactive节点把这个命令操作记录写到自己的editlog，同时JN集群也会写一份，NNstandby节点实时接收JN集群的日志，先是读取执行log操作（重演），使得自己的元数据和activeNN节点保持一致，同时两个NN节点都接受DN的心跳和blockreport。ZKFC监控NN的健康状态，向ZK定期发送心跳，使自己可以被选举；当自己被ZK选举为主的时候，zkfc进程通过RPC调用使NN的状态变为active，对外提供实时服务。
2. zookeeper 软件
   学习中：使用三台
   生产上：50台规模以下 ：7台
   50~100 9/11台 >100 11台
   zk的部署是2n+1的方式。是选举式投票原理，所以要配置奇数台（zk并不是越多越好，因为考虑到zk越多，选举谁做active的时间就会越长，会影响效率）
3. ZKFC zookeeperFailoverController：
   在hdfs HA 中，它属于单独的进程，负责监控NN的健康状态，向ZK定期发送心跳，使自己可以被选举；当自己被ZK选举为主的时候，zkfc进程通过RPC调用使NN的状态变为active，对外提供实时服务，这是无感知的。
4. hdfs dfs -ls /命令
   hdfs dfs -ls / 的 ‘/’相当于hdfs://ip:9000/的简写。所以在集群环境中用这个命令就应该考虑ip具体是哪个机器的，所以用简写就代表是所在的那台机器。举例如下
   NN1 active–>挂了 IP地址为192.168.1.100
   NN2 standby 192.168.1.101
   假如我们在192.168.1.100机器上用hdfs dfs -ls / 那么就相当于hdfs dfs -ls hdfs://192.168.1.100:9000/ ,但是假如这台机器挂了，我们再通过hdfs dfs -ls / 或者hdfs dfs -ls hdfs://192.168.1.100:9000/ 来执行命令已经不行了。如果说把其输入命令改为hdfs dfs -ls hdfs://192.168.1.101:9000/ 去访问虽然可以，但是生产上并不太可能，因为很多程序都已经打包好，不可能再去改这个命令行的对应的机器的IP地址。那么，就有了一个对应的命名空间 ：nameservice来解决这个问题。
5. 命名空间
   生产上HA命令是通过命令空间访问的
   命名空间 ：nameservice 在HA中其实并不关心哪台机器是standby 哪台是active。一般都是如下访问：
   命名空间 ：nameservice: ruozeclusterg5
   hdfs dfs -ls hdfs://ruozeclusterg5/ 其实就相当于上图中把两个NN节点包起来，而对外提供的就为ruozeclusterg5，内部进行active的选举，所以外部调用的时候并不关心哪个是active，只会用ruozeclusterg5去访问，至于谁是active，内部会解决。
6. ActiveNN：
   操作记录写到自己的editlog,同时JN集群也会写一份；接收 DN的心跳和blockreport
7. StandbyNN:
   接收JN集群的日志，先是读取执行log操作（重演），使得自己的元数据和activenn节点保持一致，接收 DN的心跳和blockreport。
8. JounalNode:
   用于 active standby nn节点的同步数据，部署是2n+1个(3个/5个–>7个)JounalNode节点出问题比较少。最容易出问题的就是NNactive状态，比如出现网络抖动导致延迟，这样就可能会出现误认为active 节点挂掉，把standby节点提升为active,这时候就可能出现两个active节点。但是这种概率非常低，因为生产上一般采用局域网，不太会网络波动出现这种问题，但也有可能出现。还有一种情况就是两个NN都是standby状态，然后切不起来active，那么这两种情况下就会出现问题。所以并不能说在生产上HA就是万无一失的。

HA是为了解决单点问题，两个NN通过JN集群共享状态，通过ZKFC 选举active，ZKFC监控状态，自动备援,DN会同时向active standby nn发送心跳和块报告.HDFS HA的部署方法有：NameNode HA With QJM （相当于共享日志，生产上推荐的就是QJM这种）和 NameNode HA With NFS （相当于共享存储目录）

hadoop001
NN
ZKFC(与NN部署在同一台机器上)
DN
JN
ZK
hadoop002
NN
ZKFC(与NN部署在同一台机器上)
DN
JN
ZK
hadoop003
DN
JN
ZK
生产上的集群：
假如还有几台空机器hadoop004-010 那么就可以把001 002 上部署的DN拿下来，部署在hadoop004-010 机器上，这个是要看具体机器的配置及数量，按需分配

图解如下：

1. zkfc是在RM里面的，只作为RM进程的一个线程而非独立的守护进程来独立存在。这个涉及到一个概念，线程
   在yarn HA中，zkfc是线程，也就是RM进程的一个线程。所谓进程就是jps 、 ps-ef | grep xxx 能够查看到的，而线程 属于一个进程的里面的 除非特殊命令和工具才能看到。 包含至少一个线程。

2. RMStateStore:
   a.RM把job信息存在在ZK的/rmstore下（类似hdfs的根目录，zk也有自己的根目录），activeRM会向这个目录写app信息
   b.当active RM挂了，另外一个standby RM通过zkfc选举成功为active，会从/rmstore读取相应的作业信息。 重新构建作业的内存信息，启动内部服务（apps manager 和资源调度），开始接收NM的心跳，构建集群的资源信息，并且接收客户端的作业提交请求。

3. RM:
   a.启动时候的会向ZK的目录?写个lock文件，写成功的话，就为active，否则为standby。然后standby rm节点会一直监控这个lock文件是否存在，假如不存在，就试图创建，假如成功就为active。
   b.接收client的请求。接收和监控NM的资源状况汇报，负载资源的分配和调度。
   c.启动和监控ApplicationMaster(AM) on NM的container（运行在NM上面的容器里面）
   注：ApplicationsManager RM
   ApplicationMaster 是JOB的老大 运行在NM的container （相当于spark的driver）

4. NM:
   节点的资源管理，启动container运行task计算，上报资源，汇报task进度给AM （ApplicationMaster）

1. hdfs中zkfc是属于进程。yarn中zkfc是属于RM进程中的一个线程
2. dn和nm的区别：DN会同时给NN active和standby都发送心跳包和块报告。NM只会向NN active发送心跳包
3. hdfs HA集群启动的进程顺序：
4. 架构：