大数据实战第三课-HDFS#YARN HA架构剖析

一、导读

二、HDFS HA（一）

• 2.1 为什么要使用集群环境
• 2.2 单节点对比HA
• 2.3 NameSpace图解

三、HDFS HA（二）

四、HDFS HA架构剖析

• 4.1 HA架构设立目的

五、YARN HA架构剖析

六、预留作业

一、导读

本次课程主要是：Hadoop HA架构部署、基于阿里云，选择按量付费，准备100块RMB足以上完整个项目。

• 自己电脑开三台虚拟机部署

二、HDFS HA（一）

2.1、为什么要使用集群环境？

• 正常学习过程中使用单点就够了；但是在企业中必然是集群环境，学习过程中时伪分布式部署；

如下图每一个角色都是一个进程。

HDFS进程	YARN进程
NameNode（老大）	ResourceManager（老大）
SecondaryNameNode	NodeManager
DataNode

单节点的问题：
思考？

• 所有读写请求都通过老大，yarn的请求也是经过老大，老大（Master）的角色挂了怎么办？

大数据的所有组件都是主从架构，master-slave

扩展eg：面试中的坑

• 比如hdfs读写请求先是先经过NameNode节点；但是在HBase中（暂时理解它为数据库），HBase的读写请求并不是经过它的老大master，至于它的读写流程，有Hbase视频，Hbase中建表、删表语句经过master

2.2、单节点对比HDFS HA架构

在单节点HDFS中，NN节点挂了，就不能对外提供服务（读、写）

	==> -put（上传一个文件）、-get 、 -text
	==>	在生产中，我们至少需要配置两个NN节点（实时），意味着：当前对外提供服务的只有两台中的一台机器，另外一台机器是随时待命的。
	==> 对比SNN，SNN仅仅做到的是每一小时的checkpoint，比如中午12:00做了checkpoint，此时NN节点挂了，过了半小时，这半小时的数据是丢失的，SNN无法恢复

所以在企业中，肯定是两个NN节点（它是实时的，任何时刻只有一台机器active对外提供服务，另外一台机器是实时备份的，随时准备着从standby切换为active，来对外提供服务）

NN1	NN2
active(假设11:00时，NN1挂了)	standby(NN2节点会切换为active状态)
访问URL: hdfs://ip1:9000/	访问URL：hdfs://ip2:9000

注意点1：

• NN2 从standby切换为active状态是无感知的，NN2、NN1可以来回的切换active状态 ；他们可以来回的切，我们不需要关注他们的状态

**注意点2：**在项目代码、shell脚本中，伪分布式我们直接指定机器ip；问题：那在HA架构中，NN1节点挂了，那怎么去切换为NN2的IP ？？active <==> standby状态切换又是不可知的，那怎么解决呢？？

1、对于单节点部署，/和hdfs://hadoop002:9000/是一样的。
hdfs dfs -ls /
hdfs dfs -ls hdfs://hadoop002:9000/

2、在代码、shell脚本中，我们强行指定ip，对于状态切换（standby --> active），我们总不能去手动修改ip。
NN1		active	11:00	hdfs://ip1:9000
NN2		standby	active	hdfs://ip2:9000

场景：

• 生产中使用IP1，IP1提供对外服务，但是IP1断电了；HA自动将IP2的状态由standby切换为active，不可能手动去改这个IP；此时抛出概念：
  ==> 命名空间：nameservice 扩展：在CDH中它是默认的.
• 在生产中也叫DW --> 数仓datawarehouse

2.3、NameSpace图解

图解：

1）、hadoop001机器上NN1节点、hadoop002机器上NN2节点，这两个都是进程；
2）、命名空间RUOZEG6，它不是以进程的形式存在；
3）、当我们使用hdfs dfs -ls hdfs://RUOZEG6时，它会去找core-site.xml和hdfs-site.xml这两个参数文件，这两个参数文件中配置了这两个机器挂载在命名空间下。
4）、两种情况，使用了这个命令：hdfs dfs -ls hdfs://RUOZEG6，第一次发送给hadoop002上的NN2节点，结果发现它是standby状态，于是它返回至命名空间又发送到hadoop001上的NN1节点，发现它是active状态，就能读了；第二种情况就是直接发送到hadoop001上的NN1节点上，就可以直接操作了。

在hdfs伪分布式部署中，以下命令可以查询hdfs上文件：
hdfs dfs -ls 
hdfs dfs -ls /
hdfs dfs -ls hdfs://10.0.0.132:9000/					
//我们只部署一台伪分布式机器，要指定那台机器的IP，

三、HDFS HA（二）

HA进程：

在我们学习过程中，正常是部署3台机器。

Hadoop三台机器部署HDFS HA所需要的组件如下：

hadoop001	hadoop002	hadoop003
NN	NN
DN	DN	DN
ZK	ZK	ZK
JN	JN	JN
ZKFC	ZKFC

在HDFS伪分布式中，NN节点中有fsimage和editlog（存放读、写请求的记录）两个文件。

3台机器都要部署ZK（选举谁做active，谁做standby）

问题点：

• ZK集群是做选举的，选举谁做active和standby，并不是ZK部署的越多越好，当出现故障的时候，ZK进行投票选举，ZK节点越多也就意味着投票的时间越长，对外提供的服务越慢，对于及时性服务来说是致命的。

• 我们要达到实时，引出JN节点，jounalNode，它是做两个节点间日志同步的。

• 我们active的机器挂了，另外一台standby的机器怎么感知如何切换，需要依赖于ZKFC进程来切换。

总结：

1、生产上比如20台集群：通常选举5台做ZK，ZK数量必然是（2n+1），偶数的话数量持平，无法做选举。
集群规模是20~100台的话：根据情况部署7/9/11台ZK；
集群规模>100台的话经验值11台。

但是：

• 并不是ZK节点在生产上越多越好，ZK是进行投票选举的，节点越多选举所需的时间越长，它对外提供服务就越慢，对于及时性服务来说是致命的。

2、未来你有幸入职的公司大，上来公司就有几百台集群节点，建议单独为ZK进程部署一台机器，如果这台机器有其它进程（会占用内存、CPU），就会影响ZK选举效率。

ZK是最底层的，掌握着HA的命门，如果ZK繁忙，就会导致standby ==> active切换不了active。

zookeeper.apache.org
jounalNode（做两个节点间数据同步用）
jounalNode部署多少台合适？考虑HDFS的数据量及请求量，可以跟ZK保持一致。

四、HDFS HA架构剖析

HDFS HA架构图：

图解：

1、jounalnode：节点的数量要根据HDFS的请求量及数据量，如果有频繁的请求，集群是接收数据的，有数据经常有读写请求；如果HDFS很悠闲，搞个几台就行；如果集群是20台，保持跟ZK节点设置的一致就行；J总公司公司jounalnode部署了7台，hdfs老是对外提供服务的话可以搞多一点。

2、ZKFC：概念：ZK选举过后通知zkfc把另一台机器切换为active

注意点：
1）DN会向两个NN都会发送消息。
2）ZKFC（zookeeperfailovercontrol）是进程，进程和线程的区别：ps -ef查看到的就是进程；进程是由1个或1个以上的线程组成的。
3）ZKFC肯定是跟NN节点绑定在一起的

4.1 HA架构设立的目的

1. HA是为了解决单点文题
2. 通过JN集群共享状态
3. 通过ZKFC选举active
4. 监控状态，自动备援
5. DN：同时向NN1、NN2发送心跳和块报告
6. ACTIVE NN：操作记录写到自己的editlog，同时写JN集群，接收DN的心跳和块报告
7. standby NN：同时接收JN集群的日志，显示读取执行log操作（重演），使得自己的元数据和active NN的节点保持一致，同时也会接收心跳和块报告。
8. JounalNode：用于active 、standby NN节点的同步数据，一般部署（2n+1）台
9. ZKFC：单独的进程，职责是监控NN的健康状态，向ZK集群定期发送心跳，使得自己可以被选举；当自己被ZK选举为active的时候，zkfc进程通过RPC协议调用使得NN节点的状态变为active；对外提供实时服务，是无感知的。

HDFS HA架构总结：

• 我们通过client端提交put、get请求的时候，通过命名空间RUOZEG6去找active的机器，找到active的机器进行真正的请求；（读写请求的操作记录editlog自己写一份同时将请求写到journalnode日志节点），NN的standby节点会把操作记录实时应用到本身（重演）；同时DN会发送心跳及块报告给两个NN。

思考： DN只向active的NN1节点汇报，那当active的NN1挂了，NN2怎么响应呢。

五、YARN HA架构剖析

3台阿里云机器：

hadoop001	hadoop002	hadoop003
zk	zk	zk
rm(zkfc)	rm(zkfc)
nm	nm	nm

解释：
ZKFC：线程，只作为RM进程的一个线程而非独立的进程存在。

RMStateStore：存储在zk的/rmstore目录下，activeRM会向这个目录写APP信息。

1. activeRM会向这个目录写APP信息
2. 当activeRM挂了，另外一个standby RM通过ZKFC选举成功为active，会从/rmstore读取相应的作业信息重新构建作业的内存信息，启动内部的服务，开始接收NM的心跳，构建集群的资源信息，并且接收客户端的作业提交请求。

RM：
1)、启动的时候会向ZK的目录/rmstore写lock文件，写成功就为active，rm节点的zkfc会一直监控这个lock文件是否存在，假如不存在，就为active，否则为standby.
2）、接收client的请求，接收和监控NM的资源状况和汇报，负责资源的分配和调度.
3）、启动和监控APPMASTER on NM节点的container
在HDFS-HA架构中，jounalnode日志节点来存储状态；在YARN-HA中，状态是存储在RMStsteStore中：存储在zk的/rmStore下。

applicationsManager：运行在RM进程中；
applicationmaster：运行在NM进程中的container容器里，是作业的主程序；

**NM：**节点资源的管理，启动容器运行task计算，上报资源，汇报进度

思考：

• ZKFC为什么仅仅是做了一个线程，而非以进程的方式，大数据中作业是可以挂的，重新启动下就行。

小结：当我们RM进程启动的时候，会向ZK集群写一个lock文件，写成功就是active，写失败就是standby；RM的节点会一直监控lock文件的存在，如果lock文件不存在，就会视图去创建lock文件，哪台机器创建成功，那它就是active状态；RM还会接收client的请求，接收NM节点的资源状况。

回顾面试问题：
1、ZKFC是进程还是线程？线程
2、/rmstore存储位置	zk集群的目录

六、预留作业

YARN HA架构博客、HDFS HA架构博客

作业1：心跳的参数是什么，间隔时间是什么？
块报告的参数是什么，时间是多少？

name	value	description
dfs.namenode.heartbeat.recheck-interval	300000	This time decides the interval to check for expired datanodes. With this value and dfs.heartbeat.interval, the interval of deciding the datanode is stale or not is also calculated. The unit of this configuration is millisecond.

• This time decides the interval（间隔） to check for expired（过期） datanodes. With this value and dfs.heartbeat.interval, the interval of deciding the datanode is stale（陈腐、不新鲜的） or not is also calculated（计算）. The unit of this configuration（配置） is millisecond.