Hadoop namenode 高可用(HA)搭建指南 QJM方式

200次阅读

没有评论

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

一、HDFS 的高可用性

1. 概述

本指南提供了一个 HDFS 的高可用性（HA）功能的概述，以及如何配置和管理 HDFS 高可用性 (HA) 集群。本文档假定读者具有对 HDFS 集群的组件和节点类型具有一定理解。有关详情，请参阅 Apache 的 HDFS 的架构指南。

http://Hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html

2. 背景

CDH4 之前，在 HDFS 集群中 NameNode 存在单点故障（SPOF）。对于只有一个 NameNode 的集群，如果 NameNode 机器出现故障，那么整个集群将无法使用，直到 NameNode 重新启动。

NameNode 主要在以下两个方面影响 HDFS 集群:

(1). NameNode 机器发生意外，比如宕机，集群将无法使用，直到管理员重启 NameNode

(2). NameNode 机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS 的 HA 功能通过配置 Active/Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将 NameNode 很快的切换到另外一台机器。

3. 架构

HDFSHA 的解决方案可谓百花齐放，Linux HA, VMware FT, sharedNAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode 等等。目前普遍采用的是 shard NAS+NFS，因为简单易用，但是需要提供一个 HA 的共享存储设备。而社区已经把基于 QJM/Quorum Journal Manager 的方案 merge 到 trunk 了，clouderea 提供的发行版中也包含了这个 feature，这种方案也是社区在未来发行版中默认的 HA 方案。

在 HA 具体实现方法不同的情况下，HA 框架的流程是一致的。不一致的就是如何存储和管理日志。在 Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN 把 EditLog 写到这个共享的存储日志的地方，Standby NN 去读取日志然后执行，这样 Active 和 Standby NN 内存中的 HDFS 元数据保持着同步。一旦发生主从切换 Standby NN 可以尽快接管 Active NN 的工作（虽然要经历一小段时间让原来 Standby 追上原来的 Active，但是时间很短）。

说到这个共享的存储日志的地方，目前采用最多的就是用共享存储 NAS+NFS。缺点有：1）这个存储设备要求是 HA 的，不能挂掉；2）主从切换时需要 fencing 方法让原来的 Active 不再写 EditLog，否则的话会发生 brain-split，因为如果不阻止原来的 Active 停止向共享存储写 EditLog，那么就有两个 Active NN 了，这样就会破坏 HDFS 的元数据了。对于防止 brain-split 问题，在 QJM 出现之前，常见的方法就是在发生主从切换的时候，把共享存储上存放 EditLog 的文件夹对原来的 Active 的写权限拿掉，那么就可以保证同时至多只有一个 Active NN，防止了破坏 HDFS 元数据。

Clouera 为解决这个问题提出了 QJM/Qurom Journal Manager，这是一个基于 Paxos 算法实现的 HDFS HA 方案。QJM 的结构图如下所示：

QJM 的基本原理就是用 2N+ 1 台 JournalNode 存储 EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有 N 台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法的，可以参考 http://en.wikipedia.org/wiki/Paxos_(computer_science)。

用 QJM 的方式来实现 HA 的主要好处有：1）不需要配置额外的高共享存储，这样对于基于 commodityhardware 的云计算数据中心来说，降低了复杂度和维护成本；2）不在需要单独配置 fencing 实现，因为 QJM 本身内置了 fencing 的功能；3）不存在 Single Point Of Failure；4）系统鲁棒性的程度是可配置的（QJM 基于 Paxos 算法，所以如果配置 2N+ 1 台 JournalNode 组成的集群，能容忍最多 N 台机器挂掉）；5）QJM 中存储日志的 JournalNode 不会因为其中一台的延迟而影响整体的延迟，而且也不会因为 JournalNode 的数量增多而影响性能（因为 NN 向 JournalNode 发送日志是并行的）。

————————————– 分割线 ————————————–

相关阅读：

Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm

Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm

Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm

Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm

单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm

搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm

————————————– 分割线 ————————————–

更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-05/101178p2.htm

二、HDFS(HA)软硬件配置

1. 硬件

NameNode 机器，Active、Standby 应该具有相同的硬件

2. 软件

(1)core-site.xml

<property>

<name>fs.defaultFS</name>

<value>hdfs://mycluster</value>

</property>

<property>

<name>ha.zookeeper.quorum</name>

<value>master,slave1,slave2,pcmk104,pcmk108</value>

</property>

(2)hdfs-site.xml

1. dfs.nameservices 注意与 core-site.xml 中的 fs.defaultFS 中的 value 保持一致

<property>

<name>dfs.nameservices</name>

<value>mycluster</value>

</property>

2. dfs.ha.namenodes.mycluster 每个 namenode 在名称服务中的唯一标识

<property>

<name>dfs.ha.namenodes.mycluster</name>

<value>nn1,nn2</value>

</property>

3. 两个结点的 rpc 地址

<property>

<name>dfs.namenode.rpc-address.mycluster.nn1</name>

<value>master:54310</value>

</property>

<property>

<name>dfs.namenode.rpc-address.mycluster.nn2</name>

<value>pcmk104:54310</value>

</property>

4. servicerpc 地址

<property>

<name>dfs.namenode.servicerpc-address.mycluster.nn1</name>

<value>master:53310</value>

</property>

<property>

<name>dfs.namenode.servicerpc-address.mycluster.nn2</name>

<value>pcmk104:53310</value>

</property>

5.http 通信地址

<property>

<name>dfs.namenode.http-address.mycluster.nn1</name>

<value>master:50070</value>

</property>

<property>

<name>dfs.namenode.http-address.mycluster.nn2</name>

<value>pcmk104:50070</value>

</property>

6. 我们采用 3 个 journalnode 节点存储元数据，这是他们的 IP 与端口

<property>

<name>dfs.namenode.shared.edits.dir</name>

<value>qjournal://master:8485;pcmk104:8485;slave1:8485/mycluster</value>

</property>

7. journaldata 的存储路径

<property>

<name>dfs.journalnode.edits.dir</name>

<value>/home/Hadoop/journaldata/</value>

</property>

8. 该类用来判断哪个 namenode 处于生效状态

<property>

<name>dfs.client.failover.proxy.provider.mycluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>

</property>

9. 打开自动切换 namenode 的功能

<property>

<name>dfs.ha.automatic-failover.enabled</name>

<value>true</value>

</property>

10. 运行脚本实现安全机制

<property>

<name>dfs.ha.fencing.methods</name>

<value>shell(/bin/true)</value>

</property>

一、HDFS 的高可用性

1. 概述

本指南提供了一个 HDFS 的高可用性（HA）功能的概述，以及如何配置和管理 HDFS 高可用性 (HA) 集群。本文档假定读者具有对 HDFS 集群的组件和节点类型具有一定理解。有关详情，请参阅 Apache 的 HDFS 的架构指南。

http://Hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html

2. 背景

CDH4 之前，在 HDFS 集群中 NameNode 存在单点故障（SPOF）。对于只有一个 NameNode 的集群，如果 NameNode 机器出现故障，那么整个集群将无法使用，直到 NameNode 重新启动。

NameNode 主要在以下两个方面影响 HDFS 集群:

(1). NameNode 机器发生意外，比如宕机，集群将无法使用，直到管理员重启 NameNode

(2). NameNode 机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS 的 HA 功能通过配置 Active/Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将 NameNode 很快的切换到另外一台机器。

3. 架构

HDFSHA 的解决方案可谓百花齐放，Linux HA, VMware FT, sharedNAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode 等等。目前普遍采用的是 shard NAS+NFS，因为简单易用，但是需要提供一个 HA 的共享存储设备。而社区已经把基于 QJM/Quorum Journal Manager 的方案 merge 到 trunk 了，clouderea 提供的发行版中也包含了这个 feature，这种方案也是社区在未来发行版中默认的 HA 方案。

在 HA 具体实现方法不同的情况下，HA 框架的流程是一致的。不一致的就是如何存储和管理日志。在 Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN 把 EditLog 写到这个共享的存储日志的地方，Standby NN 去读取日志然后执行，这样 Active 和 Standby NN 内存中的 HDFS 元数据保持着同步。一旦发生主从切换 Standby NN 可以尽快接管 Active NN 的工作（虽然要经历一小段时间让原来 Standby 追上原来的 Active，但是时间很短）。

说到这个共享的存储日志的地方，目前采用最多的就是用共享存储 NAS+NFS。缺点有：1）这个存储设备要求是 HA 的，不能挂掉；2）主从切换时需要 fencing 方法让原来的 Active 不再写 EditLog，否则的话会发生 brain-split，因为如果不阻止原来的 Active 停止向共享存储写 EditLog，那么就有两个 Active NN 了，这样就会破坏 HDFS 的元数据了。对于防止 brain-split 问题，在 QJM 出现之前，常见的方法就是在发生主从切换的时候，把共享存储上存放 EditLog 的文件夹对原来的 Active 的写权限拿掉，那么就可以保证同时至多只有一个 Active NN，防止了破坏 HDFS 元数据。

Clouera 为解决这个问题提出了 QJM/Qurom Journal Manager，这是一个基于 Paxos 算法实现的 HDFS HA 方案。QJM 的结构图如下所示：

QJM 的基本原理就是用 2N+ 1 台 JournalNode 存储 EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有 N 台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法的，可以参考 http://en.wikipedia.org/wiki/Paxos_(computer_science)。

用 QJM 的方式来实现 HA 的主要好处有：1）不需要配置额外的高共享存储，这样对于基于 commodityhardware 的云计算数据中心来说，降低了复杂度和维护成本；2）不在需要单独配置 fencing 实现，因为 QJM 本身内置了 fencing 的功能；3）不存在 Single Point Of Failure；4）系统鲁棒性的程度是可配置的（QJM 基于 Paxos 算法，所以如果配置 2N+ 1 台 JournalNode 组成的集群，能容忍最多 N 台机器挂掉）；5）QJM 中存储日志的 JournalNode 不会因为其中一台的延迟而影响整体的延迟，而且也不会因为 JournalNode 的数量增多而影响性能（因为 NN 向 JournalNode 发送日志是并行的）。

————————————– 分割线 ————————————–

相关阅读：

Ubuntu 13.04 上搭建 Hadoop 环境 http://www.linuxidc.com/Linux/2013-06/86106.htm

Ubuntu 12.10 +Hadoop 1.2.1 版本集群配置 http://www.linuxidc.com/Linux/2013-09/90600.htm

Ubuntu 上搭建 Hadoop 环境（单机模式 + 伪分布模式）http://www.linuxidc.com/Linux/2013-01/77681.htm

Ubuntu 下 Hadoop 环境的配置 http://www.linuxidc.com/Linux/2012-11/74539.htm

单机版搭建 Hadoop 环境图文教程详解 http://www.linuxidc.com/Linux/2012-02/53927.htm

搭建 Hadoop 环境（在 Winodws 环境下用虚拟机虚拟两个 Ubuntu 系统进行搭建）http://www.linuxidc.com/Linux/2011-12/48894.htm

————————————– 分割线 ————————————–

更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2014-05/101178p2.htm

三、HDFS(HA)初始化

1. 格式化 NameNode

设定所有的必要配置项后，必须首先同步两个 NameNode 上的元数据。如果是新建的 HDFS 集群，则应首先格式化一个 NameNode

（1）在格式化 NameNode 之前先启动 journalnode 服务

进入 bin 目录执行 ./hdfs journalnode

注意：在每一台 journalnode 机上都需要启动该服务。

检查服务是否正常可以访问 master:8480,slave1:8480,pcmk104:8480 来验证。启动后若出现异常，格式化 NameNode 之后就好了。

（2）格式化 NameNode

进入 bin 目录执行 ./hdfs namenode –format

2 启动 Hadoop

在 sbin 目录下执行 ./start-dfs.sh 启动 hadoop 集群。

查看页面 http://pcmk104:50070 和 http://master:50070/ 应该一个处于 active 状态一个处于 standby 状态。