Hadoop高级之HDFS&YARN HA架构剖析

Hadoop高级之HDFS&YARN HA架构剖析

1.为什么要用集群

​ 学习过程中我们只需要单点就够了,学习需要用到集群的时候可以使用便宜的商业集群.在企业里边肯定是使用的集群.我们自己部署的伪分布式,每个角色都是一个进程.

2.HDFS:

1. NN(NameNode): master(老大)

2. SNN(Secondary NameNode):checkpoint secondary,默认一个小时的checkpoint,只能恢复checkpoint内的数据；如果一个小时一个checkpoint，那么就会有丢掉一小时的数据的风险

3. DN(DataNode):

   如果NN节点挂了,就不能提供对外服务,所有与NN交互的任务都会中断,所以一般在集群部署两个NN节点(实时的,任何时刻只有一台active对外,另外一台是standby实时备份,随时准备着从standby切换到active的对外服务),NN1跟NN2

   NN1 (active) hdfs://ip1:9000/

   NN2 (standy) hdfs://ip2:9000/

   如果NN1在11:00因为某个原因挂了,这时候NN2会在那一刹那切换到active状态,对外提供服务.

   无感知的: 整个过程是无感知的,比如说NN1挂了,NN2切换为active,或者是NN2挂了,NN1切换为active状态,并不需要关注哪个节点是active的.

   命名空间: nameservice1,CDH里默认的nameservice1,生产上面叫做dw(dataware 数仓)

   命名空间 图:

   在执行操作命令 hdfs dfs -ls hdfs://RUOZEG6/ 的时候会找配置文件core-site.xml hdfs-site.xml的配置参数中随机找到一个NN来判断这个NN是否为active，是则继续执行命令，否则切换为另一个NN。

   

HDFS的HA的进程: 3台机器

hadoop001: ZK NN ZKFC JN DN

hadoop002: ZK NN ZKFC JN DN

hadoop003: ZK JN DN

ZK(zookeeper.apache.org):部署了三个节点的集群,做机器的选举,选举那台机器作为active跟standby.

正常来说20台节点,部署5台ZK节点

*注意,ZK集群的机器一定是奇数(2n+1)台;若果是20~100台节点,一般部署7/9/11台,如果是>100台机器,一般是部署11台;但是,并不是说生产上ZK节点越多越好,当出现选举动作的时候,如果节点多了,进行选举投票的动作就会变多,时间就越长,对外提供服务也会变慢.(如果资源不够,ZK的选举受影响,NN的active/standby也会受影响,standby会不能切换到active状态,这时候就是ZK太忙了)

如果有几百台节点,ZK部署的机器上只部署ZK一个进程,防止其他进程抢占zk进程资源,让ZK的运行不受影响,避免造成选举延迟或失败

NN:节点包括两台机器 fsimage跟editlog,读写请求的记录以及路径

JN(journalNode):用于active/standby nn节点间的数据同步(NN节点的日志管理进程),一般也是部署奇数个(2n+1),要根据HDFS的请求量及数据量;如果hdfs的数据量打,并频繁的读写,jn的数据就要多一点,反则少一点,可以跟ZK的数量保持一致.

HDFS HA架构图:

图解:

DN:同时向NN1 NN2发送心跳和块报告,active跟standby节点都要发送。

心跳的间隔时间参数及块报告参数

dfs.heartbeat.interval：DN的心跳检测时间间隔，默认3秒(hdfs-site.xml)
dfs.blockreport.intervalMsec：控制DN定期将当前该结点上所有的BLOCK信息报告给NN的时间间隔，默认21600000ms = 6小时 (hdfs-site.xml)

ACTIVE NN: 操作记录写到自己的editlog,同时将editlog写入JN集群,接收DN的心跳和块报告

STANDBY NN: 同时接收JN集群的日志，显示读取执行log操作(重演)，使得自己的元数据和active nn节点保持一致,接收DN的心跳和块报告

ZKFC(zookeeper failover control): 单独的进程,监控NN监控健康状态,向zk集群定期发送心跳，使得自己可以被选举;当自己被zk选举为active的时候，zkfc进程通过RPC协议调用使NN节点的状态变为active,对外提供实时服务，是无感知的。

JN(journalNode):用于active/standby nn节点间的数据同步(NN节点的日志管理进程),standby会重演active的状态（操作记录editlog ) ;standby NN读取JN的时候是随机选择写入成功一台来读取active NN的状态进行重演.

过程:

1.client客户端提交请求(put/get/ls/cat)到命名空间(nameservice)

2.命名空间去找对应的NN节点,找到那台状态为active的NN节点(如果第一次找的是standby NN,就会回过头来找另外一台NN),找到之后就会在active NN进行真正的请求.

3.NN会将操作记录写入到自己的editlog中,同时将记录写给jn集群日志

4.standby NN节点实时的读jn集群日志,并应用到本身,使得自己的元数据和active nn节点保持一致,这个操作称为 重演

5.同时,所有DN会向两个NN发送心跳以及块报告

6.ZKFC监控NN监控健康状态,并向zk集群定期发送心跳,使得两台NN可以被选举

7.当active NN节点挂了,ZK集群就会检测到,进行选举动作,standby NN被选举为active,zkfc进程通过RPC协议调用将standby NN切换为active NN,对外提供实时服务

HA是为了解决单点问题
通过JN集群共享状态
通过ZKFC选举active
监控NN状态，自动备援。

3.YARN:

1. RM(ResourceManager): master(老大)

2. NM(NodeManager):

   HDFS的读写请求跟YARN的提交job请求都需要通过master节点,但是大数据节点架构都是主从架构,也就是master-slave架构,比如说hdfs的读写请求都是先经过NN节点,但是 hbase 的读写请求不是经过master.

hadoop001:zk rm(zkfc) nm

hadoop002:zk rm(zkfc) nm

hadoop003:zk nm

**RMStateStore:**HDFS的日志操作记录存储在JN日志集群中,而YARN的操作记录则是存储在RMStateStore中,RMStateStore则是存储在zk的/rmstore目录下.

1.avtiveRM会向这个目录写App信息

2.当active RM挂了,另外一个standby RM通过ZKFC选举成功为active,会从/rmstore读取相应的作业信息,从新构建作业的内存信息,开始接收NM的内存心跳,并且接收客户端的作业提交请求

ZKFC: 线程 ,只作为RM进程的一个线程而非独立的进程存在(这与hdfs的ZKFC不同)

RM:

1.启动的时候会向ZK的目录/rmstore 目录写locak文件,写成功就为active,rm节点的zkfc线程会一直监控lock文件是否存在,如果不存在,就会写一个lock文件,写成功的就是active

2.接收client的请求,接收和监控NM的资源状况的汇报,负责资源的分配跟调度

3.启动跟监控APPMASTER on NM节点的container.

applicationsmanager 运行在RM

applicationmaster 运行在NM的container容器里,作业的主程序

NM:

运行task计算,上报资源,汇报task进度

YARN HA架构图:

图解:

过程:

1.client提交job,会先去命名空间找RM节点,如果第一次去的是standby RM节点,会回过头来找另外一台机器active RM,如果第一次去的就是active RM节点就继续往下走(这与hdfs一开始找active NN类似)

2.当 RM启动的时候会向ZK集群目录写一个lock文件,写成功就是active状态,写失败就是standby状态,所有的RM节点的zkfc线程会一直监控lock文件是否存在,如果不存在,就会试图去创建lock文件,哪个RM创建成功,哪个就是active RM

3.同时RM也会接受client请求,接收跟监控NM的资源状况的汇报,负责资源的分配跟调度,然后启动跟监控applicationmaster on NM节点的container

4.当active RM挂了,另外一个standby RM通过ZKFC选举成功为active,然后从/rmstore读取相应的作业信息,从新构建作业的内存信息,开始接收NM的内存心跳,并且接收客户端的作业提交请求

为什么和hdfs的ZKFC不同呢？

因为mr只是作业；挂了重新启动构建资源就可以；而HDFS会丢数据。所以zkfc在yarn里是线程，在hdfs是独立进程。图里的nm只和active的RM通信而不会和standby的rm通信；这里的原因也是作业挂了重新启动构建资源即可而不会像hdfs里的DN时刻和两个NN通信。

NM不会向standby RM汇报,因为当active RM挂了,另外一个standby RM通过ZKFC选举成功为active,会从/rmstore读取相应的作业信息,从新构建作业的内存信息,开始接收NM的内存心跳,并且接收客户端的作业提交请求