Hadoop 2.0 中 NameNode/ResourceManager HA 总结

本文部分转自 董的博客《Hadoop 2.0中单点故障解决方案总结》

一. 为什么需要 HA 和 Federation

1.1 单点故障

在 Hadoop 2.0 之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结

• Secondary NameNode
  它不是 HA，它只是阶段性的合并 edits 和 fsimage，以缩短集群启动的时间。当 NameNode (以下简称NN )失效的时候，Secondary NN 并无法立刻提供服务，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 基础架构

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

1. NameNode（Master）

• 命名空间管理：命名空间支持对 HDFS 中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作
• 块存储管理

2. DataNode（Slaver）

• namenode 和 client 的指令进行存储或者检索 block，并且周期性的向 namenode 节点报告它存了哪些文件的 block

2.2 YARN 基础架构

Hadoop 2.0 中新引入的资源管理系统，它的引入使得 Hadoop 不再局限于 MapReduce 一类计算，而是支持多样化的计算框架。它由两类服务组成，分别是 ResourceManager 和 NodeManager，其中，ResourceManager 作为整个系统的唯一组件，存在单点故障问题。

1. ResourceManager(RM)

• 接收客户端任务请求，接收和监控 NodeManager(NM) 的资源情况汇报，负责资源的分配与调度，启动和监控 ApplicationMaster(AM)

2. NodeManager

• 节点上的资源管理，启动 Container 运行 task 计算，上报资源、container 情况给RM和任务处理情况给 AM。

3. ApplicationMaster

• 单个 Application(Job) 的 task 管理和调度，向 RM 进行资源的申请，向 NM 发出 launch Container 指令，接收 NM 的 task 处理状态信息。NodeManager

4. Web Application Proxy

• 用于防止 Yarn 遭受 Web 攻击，本身是 ResourceManager 的一部分，可通过配置独立进程。ResourceManager Web 的访问基于守信用户，当 Application Master 运行于一个非受信用户，其提供给 ResourceManager 的可能是非受信连接，Web Application Proxy 可以阻止这种连接提供给 RM

5. Job History Server

• NodeManager 在启动的时候会初始化 LogAggregationService 服务, 该服务会在把本机执行的 container log (在 container 结束的时候)收集并存放到 hdfs 指定的目录下。ApplicationMaster 会把 jobhistory 信息写到 hdfs 的 jobhistory 临时目录下, 并在结束的时候把 jobhisoty 移动到最终目录, 这样就同时支持了 job 的 recovery.History 会启动 web 和 RPC 服务, 用户可以通过网页或 RPC 方式获取作业的信息

2.3 MapReduce

目前存在两种 MapReduce 实现，分别是

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

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

三. Hadoop HA 架构

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

3.1 HDFS 的 HA 架构

使用 Active NameNode，Standby NameNode 两个结点解决单点问题，两个结点通过 JounalNode 共享状态，通过 ZKFC 选举 Active ，监控状态，自动备援。

1. Active NameNode：

• 接受 client 的 RPC 请求并处理，同时写自己的 Editlog 和共享存储上的 Editlog，接收 DataNode 的 Block report, block location updates 和 heartbeat；

2. Standby NameNode：

• 同样会接到来自 DataNode 的 Block report, block location updates 和 heartbeat，同时会从共享存储的 Editlog 上读取并执行这些 log 操作，使得自己的 NameNode 中的元数据（Namespcae information + Block locations map）都是和 Active NameNode 中的元数据是同步的。所以说 Standby 模式的 NameNode 是一个热备（Hot Standby NameNode），一旦切换成 Active 模式，马上就可以提供 NameNode 服务

3. JounalNode：

• 用于Active NameNode ， Standby NameNode 同步数据，本身由一组 JounnalNode 结点组成，该组结点基数个，支持 Paxos 协议，保证高可用，是 CDH5 唯一支持的共享方式（相对于 CDH4 促在NFS共享方式）

4. ZKFC：

• 监控 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 的组件

1. MasterHADaemon

• 与 Master 服务运行在同一个进程中，可接收外部 RPC 命令，以控制 Master 服务的启动和停止

2. SharedStorage

• 共享存储系统，active master 将信息写入共享存储系统，而 standby master 则读取该信息以保持与 active master 的同步，从而减少切换时间。
• 常用的共享存储系统有 zookeeper（被YARN HA采用）、NFS（被HDFS HA采用）、HDFS（被 MapReduce HA 采用）和类 bookeeper 系统（被 HDFS HA 采用）

3. ZKFailoverController

• 基于 Zookeeper 实现的切换控制器，主要由两个核心组件构成：ActiveStandbyElector 和 HealthMonitor
• ActiveStandbyElector 负责与 zookeeper 集群交互，通过尝试获取全局锁，以判断所管理的 master 进入 active 还是 standby 状态
• HealthMonitor 负责监控各个活动 master 的状态，以根据它们状态进行状态切换

4. Zookeeper集群

• 核心功能通过维护一把全局锁控制整个集群有且仅有一个 active master。
• 如果 ShardStorge 采用了 zookeeper，则还会记录一些其他状态和运行时信息。

3.5 Hadoop HA 需要考虑的问题

1. 脑裂（brain-split）
脑裂是指在主备切换时，由于切换不彻底或其他原因，导致客户端和 Slave 误以为出现两个 active master，最终使得整个集群处于混乱状态。解决脑裂问题，通常采用隔离 (Fencing) 机制，包括三个方面：

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

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

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

3.6 Hadoop HA 小结

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

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