Hadoop HA

一. 为什么需要 HA 和 Federation
1.1单点故障
在 Hadoop 2.0 之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结

• Secondary NameNode: 它不是HA,它是阶段性合并edits和fsimage,以缩短集群启动的时间.当NameNode(以下简称NN)失效时,Secondary并无法立刻提供服务,Secondary NN甚至无法保证数据的完整性,如果NN数据丢失话,在上一次合并的系统的改动会丢失.
• Backup NameNode(HADOOP-4539):它在内存中复制NN当前的状态,算是Warm Standby,可也就仅限于此，并没有 failover 等。它同样是阶段性的做 checkpoint，也无法保证数据完整性。
• 手动name. dir 指向NFS: 这是安全的Cold Standby, 可以保证元数据不丢失,但集群的恢复完全靠手动.
• Facebook AvatarNode: FaceBook有强大的运维做后盾,所以Avatarnode只是Hot Standby,并没有自动切换,当主 NN 失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟 IP 映射到 Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和 Hadoop 2.0 里的 HA 非常相似，从时间上来看，Hadoop 2.0 应该是借鉴了 Facebook 做法
• 还有若干解决方案，基本都是依赖外部的HA机制，譬如 DRBD，Linux HA，VMware 的 FT 等等

---

1.2 集群容量和集群性能
单 NN 的架构使HDFS在集群扩展性和性能都有潜在的问题;

• NN进程使用的内存可能会达到上百个G
  常用的估算公式为 1G 对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。

• 所有的元数据信息的读取和操作都需要与NN进行通信
  譬如客户端的 addBlock、getBlockLocations，还有 DataNode 的 blockRecieved、sendHeartbeat、blockReport。

当集群大到一定程度后，NN 成为了性能的瓶颈。 Hadoop 2.0 里的 HDFS Federation 就是为了解决这两个问题而开发的。

二. Hadoop 2.0三个系统的简介

1. Hadoop 1.0 内核主要由两个分支组成: MapReduce 和HDFS,众所周知,这两个系统的设计缺陷是单点故障问题, 即MR的JobTracker 和HDFS的nameNode两个核心服务均存在单点问题,该问题在很长时间内没有解决，这使得 Hadoop 在相当长时间内仅适合离线存储和离线计算。但这些问题在 Hadoop 2.0 中得到了非常完整的解决。
2. Hadoop 2.0内核由三个分支组成, 分别是HDFS, MapReduce 和Yarn, 而Hadoop生态系统中的其他系统,比如 HBase、Hive、Pig 等，均是基于这三个系统开发的。这三个系统均采用简单的 master/slaves 架构，其中 master 是单点故障。

2.1 HDFS 基础架构
仿照gooleGFS实现分布式存储系统,由NameNode和DateNode两种服务组成,其中 NameNode 是存储了元数据信息（fsimage）和操作日志（edits），由于它是唯一的，其可用性直接决定了整个存储系统的可用性。

1.NameNode(Master)
- 管理HDFS
- 接收客户端请求，比如：上传文件、下载文件
- 维护文件的元信息（fsimage文件）和操作日志（edits文件）
2.DateNode(Slaver)
- NameNode 和 client 的指令进行储存或者检索 block, 并且周期性的向NameNode 节点报告它存了那些文件的block

2.2 YARN 基础架构
Hadoop 2.0 中新引入的资源管理系统,它的引入使得Hadoop补在局限于MapReduce 一类计算,而是支持多样化的计算框架。它是由两类服务组成,分别是ResourceManager 和NodeManger, 其中, ResourceManager作为整个系统的唯一组件,存在单点故障的问题.
a. ResourceManager(RM)
接收客户端任务请求,接收和监控NodeManager(NM)的资源情况汇报,负责资源的分配与调度,启动和监控Application(AM)

b. NodeManager
节点上的资源管理,启动Container运行 task 计算,上报资源, container情况给RM好任务处理情况给AM
c. ApplicationMaster
单个Application(Job) 的task管理和调度,向RM进行资源的申请,向NM发出 launch Container指令,接收NM的task处理状态信息.NodeManger
d. Web Application Proxy
用于防止 Yarn 遭受 Web 攻击, 本身ResourceManger的一步分,可通过配置独立进程.ResourceManager Web 的访问基于守信用户,当Application Master 运行与一个非守信用户,其提供给 ResourceManager 的可能是非受信连接，Web Application Proxy 可以阻止这种连接提供给 RM
e. Job History Server
NodeManager 在启动的时候回初始化LogAggregationService 服务, 改服务会在把本机执行的container log(在 container 结束的时候)收集并存放到HDFS指定的目录下.ApplicationMaster 会把 jobhistory 信息写到 hdfs 的 jobhistory 临时目录下, 并在结束的时候把 jobhisoty 移动到最终目录, 这样就同时支持了 job 的 recovery.History 会启动 web 和 RPC 服务, 用户可以通过网页或 RPC 方式获取作业的信息

2.3 MapReducer

目前存在两种实现MapReduce 实现,分别是
可独立运行的MapReduce:
它由两类服务组成，分别是JobTracker 和 TaskTraker, 其中 JobTracker 存在单点故障问题，本文提到的单点故障实际上是第一种实现中JobTracker的单点故障。

MapReduce On Yarn
在这种实现中，每个作业独立使用一个作业跟踪器（ApplicationMaster），彼此之间不再相互影响，不存在单点故障问题。

三. Hadoop 架构

先说当前 Hadoop 单点故障的解决进度，截止本文发布时，HDFS 单点故障已经解决，且提供了两套可行方案；MapReduce 单点故障（JobTracker）由 CDH4（CDH4 同时打包了 MRv1 和 MRv2，这里的单点故障指的是 MRv1 的单点问题）解决，且已经发布；YARN 单点故障也已经解决了

3.1 HDFS 的HA 架构

使用Active NameNode, Standby NameNode 两个节点解决单点问题,两个节点通过JounlNode共享状态,通过ZKFC选举Active,监控状态,自动备援.
1. Active NameNode:
接收client 的RPC请求并处理,同时写自己的Editlog和共享存储上的Editlog,接收DataNode的Blockreport, block location updates 和heartbeat
2. Standby NameNode:
同样接到来自Data的 Block report, block location updates和 heartbeat, 同时会从共享存储的Editlog上读取并执行这些lo0g操作,使得自己的 NameNode 中的元数据（Namespcae information + Block locations map）都是和 Active NameNode 中的元数据是同步的。所以说 Standby 模式的 NameNode 是一个热备（Hot Standby NameNode），一旦切换成 Active 模式，马上就可以提供 NameNode 服务3. JounalNode:
用于Active NameNode, Standby NameNode 同步数据, 本身一组JounalNode节点组成, 该组节点基数个,支持Paxos协议,保证 高可用
4. ZFKC:
监控NameNode进程, 自动备援

3.2 YARN 的HA 架构

• ResourceManager HA 由一对 Active，Standby 结点构成，通过 RMStateStore 存储内部数据和主要应用的数据及标记。目前支持的可替代的 RMStateStore 实现有：基于内存的 MemoryRMStateStore，基于文件系统的 FileSystemRMStateStore，及基于 zookeeper 的 ZKRMStateStore
• ResourceManager HA 的架构模式同 NameNode HA 的架构模式基本一致，数据共享由 RMStateStore，而 ZKFC 成为 ResourceManager 进程的一个服务，非独立存在。

3.3 Hadoop HA 解决方案架构
总体来说, Hadoop 中的HDFS, MapReduce和Yarn的单点故障解决方案架构是完全一致的,分为
手动模式: 指由管理员通过命令进行备注切换,这通常在服务升级时有用
自动模式:自动模式可降低运维成本,但存在潜在危险.

3.4 构成Hadoop HA的组件
MasterHADarmon
与Master服务运行在同一进程中,可接收外部RPC命令,以控制Master 服务的启动和停止
SharedStorage
共享存储系统, active master 将信息写入共享存储系统,而standby master 则读取改信息以保持与active master的同步,从而减少切换时间
常用的共享存储系统有zookeeper(被YARNHA采用). NFS被(HDFSHA采用), HDFS(被MapReduceHA采用)
ZKFailoverController
基于Zookeeper实现的切换控制,主要由两个核心组件构成:
ActiveStandbyElector 负责与 zookeeper集群交互,通过尝试获取全局锁,以判断管理的maste进入active还是standby状态
HealthMonitor 负责监控各个活动 master 的状态，以根据它们状态进行状态切换
Zookeeper集群
核心功能通过维护一把全局锁控制整个集群有且仅有一个active master.
如果ShareStorge采用了zookeeper,则还会记录一些其他状态和运行时信息

---

3.5 Hadoop HA 需要考虑的问题
1.脑裂(brain-split)
脑裂是指在主备切换是,由于切换不彻底或其他原因,导致客户端和Slave误以为出现两个active master,最终使得整个集群处于混乱状态.解决脑裂问题,通常采用隔离机制,包括是哪个方面:

• 共享存储 fencing: 确保只有一个Master 往共享存储中写数据
• 客户端 fencing: 确保只有一个Master 可以响应客户端的请求
• Salve fencing: 确保只有一个Master可以向Slaver下发命令

Hadoop 公共库中对外提供了两种 fenching 实现，分别是 sshfence 和 shellfence（缺省实现），其中 sshfence 是指通过 ssh 登陆目标 Master 节点上，使用命令 fuser 将进程杀死（通过 tcp 端口号定位进程 pid，该方法比 jps 命令更准确），shellfence 是指执行一个用户事先定义的 shell 命令（脚本）完成隔离。

2.切换对外透明
为了保证整个切换是对外透明的,Hadoop应保证所有客户端和Slave能自动重定向到新的active master上,这通常通过若干次尝试连接旧master不成功后,在重新尝试连接master完成的,整个过程有一定的延迟.在新版的HadoopRPC中,用户可自行设置RPC客户端尝试机制,尝试次数和尝试超过时时间等参数

3.6 Hadoop HA小结
总体上看,MapReduce HA 和YARN 类似, 但共享存储系统采用的zookeeper.之所以采用Zookeeper这种轻量级”存储系统”(需要注意的是,zookeeper设计目的并不是储存,而是提供分布式协调服务,但它的确可以安全可靠的储存少量数据以解决分布式环境下多个服务之间 的数据共享问题),是由于YARN的大部分信息可以通过NameManaer和Application的心跳信息进行动态重构,而ResourceManger本身只需记录少量信息到Zookeeper上即可.

总体上讲, HA 解决的难度取决于Master自身记录的多少和信息可重构性,如果记录的信息非常庞大且不可动态重构,比如NameNode,则需要一个可靠性与性能均很高的共享储存系统,而如果Master保存很多信息,但绝大多数可与性能均很高的共享储存系统,二如果Master保存很多信息,但绝大多数可通过Slave动态重构,则HA解决方法容易得多,典型代表的是MapReduce和Yarn.从另一个角度来看,由于计算框架对信息丢失不是非常敏感,比如一个已经完成的任务信息丢失,只需要重算即可获取,使得计算框架的HA设计难度远低于存储类系统.