Hadoop学习：HDFS HA原理及安装

共计 5144 个字符，预计需要花费 13 分钟才能阅读完成。

早期的 Hadoop 版本，NN 是 HDFS 集群的单点故障点，每一个集群只有一个 NN, 如果这个机器或进程不可用，整个集群就无法使用。为了解决这个问题，出现了一堆针对 HDFS HA 的解决方案（如：Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode 等 ）; 在 HA 具体实现方法不同的情况下，HA 框架的流程是一致的, 不一致的就是如何存储和管理日志。在 Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN 把 EditLog 写到这个共享的存储日志的地方，Standby NN 去读取日志然后执行，这样 Active 和 Standby NN 内存中的 HDFS 元数据保持着同步。一旦发生主从切换 Standby NN 可以尽快接管 Active NN 的工作; 在 HDP2.4 安装图文详细教程(五)：集群及组件安装 章节使用 ambari 创建 cluster 时，默认并未启用 hdfs ha, 可以通过 ambari 管理界面进行安装

目录：

SPOF（single point of failure）方案回顾
hadoop2.x ha 原理
hadoop2.x ha 详述
hadoop2.x Federation
ha 安装配置

SPOF 方案回顾：

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

- PrimaryNN 与 StandbyNN 之间通过 NFS 来共享 FsEdits、FsImage 文件，这样主备 NN 之间就拥有了一致的目录树和 block 信息；而 block 的位置信息，可以根据 DN 向两个 NN 上报的信息过程中构建起来。这样再辅以虚 IP，可以较好达到主备 NN 快速热切的目的。但是显然，这里的 NFS 又引入了新的 SPOF
- 在主备 NN 共享元数据的过程中，也有方案通过主 NN 将 FsEdits 的内容通过与备 NN 建立的网络 IO 流，实时写入备 NN，并且保证整个过程的原子性。这种方案，解决了 NFS 共享元数据引入的 SPOF，但是主备 NN 之间的网络连接又会成为新的问题

hadoop2.X ha 原理:

hadoop2.x 之后，Clouera 提出了 QJM/Qurom Journal Manager，这是一个基于 Paxos 算法实现的 HDFS HA 方案，它给出了一种较好的解决思路和方案, 示意图如下：
基本原理就是用 2N+ 1 台 JN 存储 EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有 N 台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法
在 HA 架构里面 SecondaryNameNode 这个冷备角色已经不存在了，为了保持 standby NN 时时的与主 Active NN 的元数据保持一致，他们之间交互通过一系列守护的轻量级进程 JournalNode
任何修改操作在 Active NN 上执行时，JN 进程同时也会记录修改 log 到至少半数以上的 JN中，这时 Standby NN 监测到 JN 里面的同步 log 发生变化了会读取 JN 里面的修改 log，然后同步到自己的的目录镜像树里面，如下图：
当发生故障时，Active 的 NN 挂掉后，Standby NN 会在它成为 Active NN 前，读取所有的 JN 里面的修改日志，这样就能高可靠的保证与挂掉的 NN 的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的
QJM 方式来实现 HA 的主要优势：

1. 不需要配置额外的高共享存储，降低了复杂度和维护成本
2. 消除 spof
3. 系统鲁棒性 (Robust: 健壮) 的程度是可配置
4. JN 不会因为其中一台的延迟而影响整体的延迟，而且也不会因为 JN 的数量增多而影响性能（因为 NN 向 JN 发送日志是并行的）

hadoop2.x ha 详述：

datanode 的 fencing: 确保只有一个 NN 能命令 DN。HDFS-1972 中详细描述了 DN 如何实现 fencing

1. 每个 NN 改变状态的时候，向 DN 发送自己的状态和一个序列号
2. DN 在运行过程中维护此序列号，当 failover 时，新的 NN 在返回 DN 心跳时会返回自己的 active 状态和一个更大的序列号。DN 接收到这个返回则认为该 NN 为新的 active
3. 如果这时原来的 active NN 恢复，返回给 DN 的心跳信息包含 active 状态和原来的序列号，这时 DN 就会拒绝这个 NN 的命令

客户端 fencing：确保只有一个 NN 能响应客户端请求，让访问 standby nn 的客户端直接失败。在 RPC 层封装了一层，通过 FailoverProxyProvider 以重试的方式连接 NN。通过若干次连接一个 NN 失败后尝试连接新的 NN，对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间
Hadoop 提供了 ZKFailoverController 角色，部署在每个 NameNode 的节点上，作为一个deamon 进程, 简称 zkfc，示例图如下：
FailoverController 主要包括三个组件:

1. HealthMonitor: 监控 NameNode 是否处于 unavailable 或 unhealthy 状态。当前通过 RPC 调用 NN 相应的方法完成
2. ActiveStandbyElector: 管理和监控自己在 ZK 中的状态
3. ZKFailoverController 它订阅 HealthMonitor 和 ActiveStandbyElector 的事件，并管理 NameNode 的状态

ZKFailoverController 主要职责：

1. 健康监测：周期性的向它监控的 NN 发送健康探测命令，从而来确定某个 NameNode 是否处于健康状态，如果机器宕机，心跳失败，那么 zkfc 就会标记它处于一个不健康的状态
2. 会话管理：如果 NN 是健康的，zkfc 就会在 zookeeper 中保持一个打开的会话，如果 NameNode 同时还是 Active 状态的，那么 zkfc 还会在 Zookeeper 中占有一个类型为短暂类型的 znode，当这个 NN 挂掉时，这个 znode 将会被删除，然后备用的 NN，将会得到这把锁，升级为主 NN，同时标记状态为 Active
3. 当宕机的 NN 新启动时，它会再次注册 zookeper，发现已经有 znode 锁了，便会自动变为 Standby 状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置 2 个 NN
4. master 选举：如上所述，通过在 zookeeper 中维持一个短暂类型的 znode，来实现抢占式的锁机制，从而判断那个 NameNode 为 Active 状态

hadoop2.x Federation：

单 Active NN 的架构使得 HDFS 在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN 进程使用的内存可能会达到上百 G，NN 成为了性能的瓶颈
常用的估算公式为 1G 对应 1 百万个块，按缺省块大小计算的话，大概是 64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有 1KB/block)
为了解决这个问题,Hadoop 2.x 提供了 HDFS Federation, 示意图如下：
多个 NN 共用一个集群里的存储资源，每个 NN 都可以单独对外提供服务
每个 NN 都会定义一个存储池，有单独的 id，每个 DN 都为所有存储池提供存储
DN 会按照存储池 id 向其对应的 NN 汇报块信息，同时，DN 会向所有 NN 汇报本地存储可用资源情况
如果需要在客户端方便的访问若干个 NN 上的资源，可以使用客户端挂载表，把不同的目录映射到不同的 NN，但 NN 上必须存在相应的目录
设计优势：

1. 改动最小，向前兼容；现有的 NN 无需任何配置改动；如果现有的客户端只连某台 NN 的话，代码和配置也无需改动
2. 分离命名空间管理和块存储管理
3. 客户端挂载表：通过路径自动对应 NN、使 Federation 的配置改动对应用透明

思考：与上面 ha 方案中介绍的最多 2 个 NN 冲突？

ha 安装配置：

关于 NameNode 高可靠需要配置的文件有 core-site.xml 和hdfs-site.xml
关于 ResourceManager 高可靠需要配置的文件有 yarn-site.xml ( 参数配置及说明见第四章)
操作的过程可通过 ambarir 的管理界面提供的 “enable NameNode HA” 完成, 如下图：
系统要求：至少 3 台以上 zookeeper 服务器，在原来基础上，将 hdp2\hdp3\R 作为 zookeeper
停止 HBase 所有服务，设置 JN 安装在 host，及 standby NN 节点主机，如下图：
按默认配置安装的 secondary NN 将去被删除，同时安装 standby NN, 在 R、hdp1、hdp2 上配置 JN 服务，如下：
登陆至 active NN (hdp4), 执行下面的命令
命令： sudo su hdfs -l -c ‘hdfs dfsadmin -safemode enter’（进入安全模式）
命令：sudo su hdfs -l -c ‘hdfs dfsadmin -saveNamespace’（create checkpoint)
ambari 检测到 NN 进入安全模式并且 checkpoint 后进入组件配置，如图：
初始化 JN 节点，进入 hdp4, 执行命令：sudo su hdfs -l -c ‘hdfs namenode -initializeSharedEdits’
ambari 检测到初始化成功后，进入下一步，如图 start component
手工初始化 NN HA Metadata, 登陆 hdp4 主机，命令如下：
命令：sudo su hdfs -l -c ‘hdfs zkfc -formatZK’
登陆到 standy NN (R), 执行命令：
命令：sudo su hdfs -l -c ‘hdfs namenode -bootstrapStandby’
成功执行上面命令后，点击“下一步”，开始 HA 安装，成功后如图:
回到 ambari 面板