Hadoop2.0架构及其运行机制，HA原理

一、Hadoop2.0架构

1.架构图

以上是hadoop2.0的架构图，根据hadoop1.0的不足，改进而来。
1.NameNode节点，由原先的一个变成两个,解决单点故障问题
2.JournalNode集群，处理EditLog将原先的SecondaryNode的工作接手过来，同时保证了一致性，避免由宕造成数据不统一
3.DataNode节点，所有的DataNode同时向两个NameNode汇报数据信息
4.FailoverController，处于NameNode上的一个单独的进程，负责NameNode的主备切换，避免但节点故障
5.ZK集群，确保NameNode主节点的唯一性，避免出现双主的情况

2.HA

1)NameNode主备切换

在NameNode启动的时候，会在节点上启动一个ZKFailoverController独立进程(以下简写ZKFC);改进程启动时，会创建HeathMonitor(以下简写HM)和ActiveStandbyElector(以下简写ASE)两个组件，并在两个组件中注册对应的回调方法。
1⃣️：HM初始化完成后，调用NameNode的HAServiceProtocolRPC方法，对NameNode进行健康检查，主要检查NameNode的两种状态：
HealthMonitor.State
HealthMonitor.State 是通过 HAServiceProtocol RPC 接口的 monitorHealth 方法来获取的，反映了 NameNode 节点的健康状况，主要是磁盘存储资源是否充足。

NITIALIZING：HealthMonitor 在初始化过程中，还没有开始进行健康状况检测；
SERVICE_HEALTHY：NameNode 状态正常；
SERVICE_NOT_RESPONDING：调用 NameNode 的 monitorHealth 方法调用无响应或响应超时；
SERVICE_UNHEALTHY：NameNode 还在运行，但是 monitorHealth 方法返回状态不正常，磁盘存储资源不足；
HEALTH_MONITOR_FAILED：HealthMonitor 自己在运行过程中发生了异常，不能继续检测 NameNode 的健康状况，会导致 ZKFailoverController 进程退出；

HAServiceStatus
通过 HAServiceProtocol RPC 接口的 getServiceStatus 方法来获取的，主要反映的是 NameNode 的 HA 状态，包括：

INITIALIZING：NameNode 在初始化过程中；
ACTIVE：当前 NameNode 为主 NameNode；
STANDBY：当前 NameNode 为备 NameNode；
STOPPING：当前 NameNode 已停止；

2⃣️：当检测到NameNode的状态发生变化时，通过回调方法汇报给ZKFC
3⃣️：ZKFC根据NameNode的状态判断是否需要进行主备切换操作，如果需要执行下一步骤
4⃣️：ZKFC使用ASE来进行主备切换
5⃣️：ASE通过与ZK集群的交互来完成主备切换

参与选举的节点的ASE将尝试向ZK集群中创建一个/hadoop-ha//ActiveStandbyElectorLock临时节点
根据ZK的写一致性，最终只会又一个节点创建成功，则创建成功的节点即为主节点，其余为备份节点
同时ASE通过回调方法将这个结果告诉ZKFC
6⃣️：ZKFC调用HAServiceProtocolRPC切换NameNode的状态

2)watcher监听

在尝试往ZK集群中写入/hadoop-ha//ActiveStandbyElectorLock后，所有的ASE会向ZK中注册一个Watcher节点来监视/hadoop-ha//ActiveStandbyElectorLock这个临时节点，
即监视NodeDeleted事件
当NameNode的状态异常时，ZKFC会主动删除当前在ZK上建立的节点/hadoop-ha//ActiveStandbyElectorLock
而NameNode的Watcher监听到NodeDeleted这个事件之后，触发主备切换选举流程，并在主备切换成功后，修改NameNode状态
如果时Active的NameNode整个机器宕机的话，ZK上/hadoop-ha//ActiveStandbyElectorLock也会被自动删除，从而触发主备切换

3)脑裂问题

（1）脑裂是怎么产生的
如果ZK客户端机器负载过高，或者正在进行JVM Full GC，那么可能会导致客户端到ZK的服务端心跳不能正常发出，一旦这个时间持续超过了配置的Session Timeout参数的话，ZK服务端会认为session已经过期，从而将客户端的Session关闭，形成假死。假死有可能会造成分布式系统常说的双主或脑裂现象
（2）脑裂现象
我们假设以下NameNode1(Active)、NameNode2(Standby)。如果某一时刻NameNode1赌赢的ZKFC进程发生了假死现象，那么ZK会认为NamoNode1已经挂掉了，启动主备切换流程，NameNode2会以Active状态运行。
但是NameNode1此时可能仍然处于Active状态正常运行，即使ZKFC在随后恢复正常，并且感知ZK的session已经关闭，但是由于网络或者CPU调度的不确定性，仍有可能NameNode1会以Active的状态运行一段时间，而在这段时间内会正常对外提供服务。而这种情况对NameNode数据要求非常高的系统来说，是灾难性的，数据发生错乱，且无法恢复
（2）怎么解决脑裂现象
官方给出一个解决办法隔离fencing；就是把久的Active的NameNode隔离起来使其不能提供服务。
主要有以下几步：
1⃣️：找出出现假死的现象；
辨别出假死是我们执行隔离的前提，也是会出现脑裂的前提。在ASE选出成功创建/hadoop-ha//ActiveStandbyElectorLock临时节点的时候，也会在ZK中创建一个/hadoop-ha//ActiveBreadCrumb的持久节点，这个节点保存了ActiveNameNode的地址信息。
2⃣️：处理异常情况
正常关闭ZK Session的时候，临时节点和持久节点都会被删除，但是如果在异常情况下Session被关闭，例如ZK客户端的假死，那么临时节点会被删除，但是持久节点不会删除。当另一个NameNode选主成功是，会发现这个遗留的节点，从而对该节点进行fencing
3⃣️隔离fencing操作

• 回调ZKFC注册的fenceOldActive方法，尝试对旧的NameNode进行fencing；
• 先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态
• transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施：
  sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；
  shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离；

3.组件

1.HDFS

2.MapReduce

3.Yarn

1.组件

• client
• Container
  1⃣️yarn对字段做的一种抽象
  2⃣️由NodeManager启动和管理，并被其监控
  3⃣️由ResourceManager进行调度
• ResourceManager
  1⃣️系统中仅存在一个ResourceManager
  2⃣️Scheduler/定时调度器；负责向应用程序分配资源，但是它不做监控以及应用程序的状态跟踪，并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序
  3⃣️ApplicationManager/应用管理器；应用程序管理器负责接收新任务，协调并提供在ApplicationMaster容器失败时的重启功能
• ApplicationMaster
  每个应用程序的ApplicationMaster负责从Scheduler申请资源，以及跟踪这些资源的使用情况以及任务的监控
• NodeManager
  NodeManager是ResourceManager在每台机器上的代理，负责容器的管理，并监控他们资源使用情况（cpu，内存，磁盘及网络等），以及向ResourceManager/Scheduler提供这些资源使用报告

  2.调度流程

  
  1⃣️Client向Yarn提交Application
  2⃣️ResourceManager向NodeManager通信，为Application分配第一个Container，并在这个Container中运行应用程序对应的ApplicationMaster
  3⃣️ApplicationMaster启动后，会对作业进行拆分，拆分出可以运行在一个或多个Container的task，然后向ResourceManager申请运行程序的Container，并发送心跳
  4⃣️申请到Container后，ApplicationMaster会和对应的NodeManager通信，将作业发送到对应的Container并运行（Map或Reduce任务）
  5⃣️Container会向ApplicationMaster发送心跳，汇报自身情况。任务完成后，ApplicationMaster向对应的NodeManager注销并释放容器资源
  资料：Hadoop HA 深度解剖