部署集群的原因
如果我们采用单点的伪分布式部署,那么NN节点挂了,就不能对外提供服务。集群的话,存在两个NN节点,一个挂了,另外一个从standby模式直接切换到active状态,实时对外提供服务(读写)。在生产上,避免出现对外服务中断的情况,所以会考虑采用集群部署。
HDFS HA (High availability)
单点式伪分布:
NN
SNN secondary 1小时checkpoint
DN
HDFS HA:
NN active
NN standby 实时备份
DN
JN : JounalNode 日志
ZKFC : zookeeperFailoverController(控制NN为active还是standby)
图解如下:
![](https://i-blog.csdnimg.cn/blog_migrate/c77ed77fd7e846c718c66523d46f2077.png)
- 过程分析
客户端上输入一个命令,然后NNactive节点把这个命令操作记录写到自己的editlog,同时JN集群也会写一份,NNstandby节点实时接收JN集群的日志,先是读取执行log操作(重演),使得自己的元数据和activeNN节点保持一致,同时两个NN节点都接受DN的心跳和blockreport。ZKFC监控NN的健康状态,向ZK定期发送心跳,使自己可以被选举;当自己被ZK选举为主的时候,zkfc进程通过RPC调用使NN的状态变为active,对外提供实时服务。 - zookeeper 软件
学习中:使用三台
生产上:50台规模以下 :7台
50~100 9/11台 >100 11台
zk的部署是2n+1的方式。是选举式投票原理,所以要配置奇数台(zk并不是越多越好,因为考虑到zk越多,选举谁做active的时间就会越长,会影响效率) - ZKFC zookeeperFailoverController:
在hdfs HA 中,它属于单独的进程,负责监控NN的健康状态,向ZK定期发送心跳,使自己可以被选举;当自己被ZK选举为主的时候,zkfc进程通过RPC调用使NN的状态变为active,对外提供实时服务,这是无感知的。 - 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来解决这个问题。 - 命名空间
生产上HA命令是通过命令空间访问的
命名空间 :nameservice 在HA中其实并不关心哪台机器是standby 哪台是active。一般都是如下访问:
命名空间 :nameservice: ruozeclusterg5
hdfs dfs -ls hdfs://ruozeclusterg5/ 其实就相当于上图中把两个NN节点包起来,而对外提供的就为ruozeclusterg5,内部进行active的选举,所以外部调用的时候并不关心哪个是active,只会用ruozeclusterg5去访问,至于谁是active,内部会解决。 - ActiveNN:
操作记录写到自己的editlog,同时JN集群也会写一份;接收 DN的心跳和blockreport - StandbyNN:
接收JN集群的日志,先是读取执行log操作(重演),使得自己的元数据和activenn节点保持一致,接收 DN的心跳和blockreport。 - 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 机器上,这个是要看具体机器的配置及数量,按需分配
Yarn HA
图解如下:
![](https://i-blog.csdnimg.cn/blog_migrate/33780e738d42d588f4fac208d43f9951.png)
-
zkfc是在RM里面的,只作为RM进程的一个线程而非独立的守护进程来独立存在。这个涉及到一个概念,线程
在yarn HA中,zkfc是线程,也就是RM进程的一个线程。所谓进程就是jps 、 ps-ef | grep xxx 能够查看到的,而线程 属于一个进程的里面的 除非特殊命令和工具才能看到。 包含至少一个线程。 -
RMStateStore:
a.RM把job信息存在在ZK的/rmstore下(类似hdfs的根目录,zk也有自己的根目录),activeRM会向这个目录写app信息
b.当active RM挂了,另外一个standby RM通过zkfc选举成功为active,会从/rmstore读取相应的作业信息。 重新构建作业的内存信息,启动内部服务(apps manager 和资源调度),开始接收NM的心跳,构建集群的资源信息,并且接收客户端的作业提交请求。 -
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) -
NM:
节点的资源管理,启动container运行task计算,上报资源,汇报task进度给AM (ApplicationMaster)
yarn HA 和hdfs HA之间的区别
- hdfs中zkfc是属于进程。yarn中zkfc是属于RM进程中的一个线程
- dn和nm的区别:DN会同时给NN active和standby都发送心跳包和块报告。NM只会向NN active发送心跳包
- hdfs HA集群启动的进程顺序:
- 架构: