hdfs高可用性（HDFS High Availability）

Hadoop2.2.0中HDFS的高可用性实现原理

http://www.iteblog.com/archives/833

官方文档

http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-High-Availability-Guide/cdh4hag_topic_2_1.html

http://kicklinux.com/quorum-based-storage-ha/

我自己参考官方文档，翻译总结CDH4中HDFS高可用性的实现原理

CDH4 主要采用两种方案：

注：Cloudera建议采用Quorum-based Storage来作为HA的解决方案，因为Shared storage using NFS只在CDH4中支持，CDH5不支持。如果想从NFS转换成Quorum-based Storage，请看http://www.cloudera.com/content/cloudera-content/cloudera-docs/CDH4/latest/CDH4-High-Availability-Guide/cdh4hag_topic_2_7.html#concept_ddg_ryd_cm_unique_1

Quorum-based Storage

在 HDFS的集群中，存在NameNode单点故障(a single point of failure)，Quorum-based Storage方法大体上是：增加journalnode节点部署Quorum Journal Manager，通过quorum来进行日志管理。NameNode Active将editlog写入到journalnode，Standby NameNode读取journalnode的日志并应用到本地。当NameNode Active不可用时，Standby NameNode在执行完全部journalnode上的日志后变为Active状态。

继6月份推出CDH4后，Cloudera于本月推出了CDH4.1版(2013-08)（注：Cloudera每年会推出一个新的CDH版本，并且大约每隔3个月会对当前的CDH作一次更新）。除了常规的补丁和性能改善，这一更新包含了关于HDFS和安全性方面的几个特性，值得关注一下。

在CDH4提供的HDFS HA实现机制里，一对Name Node共享NFS目录。现在CDH4.1则添加了基于一组Quorum存储并使用一种叫作Quorum Journal Manager(QJM)的新机制。在这种新机制里，为了使备用节点（Standby node）与活动节点（Active node）同步，两个节点与一组独立的守护进程JournalNodes通信。当主节点中的namespace发生任何修改，它则生成一系列日志记录，并把它记录在大部分JournalNodes中。备用节点只能读取这些在JournalNodes中的文件，当这些文件已发生变化，备用节点则将读取这些变化并应用到自己的namespace。在故障转移过程中，备用节点在切换成主节点前，会保证它已经将log文件中的内容都应用到自己的namespace中。这样就保证了namespace的状态与故障发生前一致了。

为了提供一个快速的故障转移，备用节点应该有关于集群中blocks位置的最新信息。为了达到这个目标，在DataNode中应该配置两个NameNode（active，standby），并通过心跳向他们发送block的位置信息。

为了保证HA Cluster的正确操作，保证集群中在任何时刻只有一个NameNodes是非常重要的，否则，namespace将面临着数据丢失或者其他不正确的结果。为了确保Namespace状态正确和防止所谓的 "split-brain scenario,"，JournalNodes只允许在一时刻只有一个节点能够编辑这些文件也就是只能有一个节点充当writer。在故障转移过程中，备用主节点想要变成主节点，只需要简单将其角色改为writer，这样就有效的保证了只有一个活动节点，让新的主节点安全地进行故障转移。

和共享NFS目录这种被动的纯存储机制相比， JournalNodes能够防止接受多个NameNode同时对其写操作（所以 “fencing”这一步骤不是必须的）。不过，采用该机制实现HA的集群就变成了必须依赖于JournalNode　Quorum才能正常工作。在这一点上，和HBase对Zookeeper的依赖有点类似。如果NameNode无法获取JournalNode Quorum，HDFS则会无法格式化或无法启动，会提示如下错误信息：

10/21/12 01:01:01 WARN namenode.FSEditLog: Unable to determine input streams from QJM to [10.0.1.10:8485, 10.0.1.10:8486, 10.0.1.10:8487]. Skipping. java.io.IOException: Timed out waiting 20000ms for a quorum of nodes to respond.

不过，这些JournalNode的负载不大，建议是可以运行在Master daemon的机器上。

在配置方面，除了常规HA外，需要指定JournalNode Quorum和JournalNode用于存储的目录位置。这两者分别通过“dfs.namenode.shared.edits.dir”和“dfs.journalnode.edits.dir”来指定。

- Data Encryption

在安全性方面，CDH4.1加入了支持对 MRv1/MRv2 的Shuffle数据和Web UIs进行加密，以及对所有通过网络传输的HDFS数据进行加密。

Shared Storage Using NFS

为了使备用节点（Standby node）与活动节点（Active node）同步，这种实现方案需要两个节点可以访问一个共享存储设备（例如, an NFS mount from a NAS）.

当主节点（Active node)对任何namespace进行了修改，它将产生一系列日志，并将这些log记录编辑成log文件存储在共享目录中。备用节点一直关注着这个目录，当log文件一被编辑，备用节点则将这些改变应用到自己的namespace中。在故障转移过程中，备用节点在切换成主节点前，会保证它已经将log 文件中的内容都应用到自己的namespace中。这样就保证了namespace的状态与故障发生前一致了。

为了保证HA Cluster的正确操作，保证集群中在任何时刻只有一个NameNodes是非常重要的，否则，namespace将面临着数据丢失或者其他不正确的结果。为了确保Namespace状态正确和防止所谓的 "split-brain scenario,"，管理员必须配置至少一种防护方法来防止多个节点对共享文件的编辑。在故障转移过程中，如果它不能验证先前的主节点已经放弃了活动状态，这个防护进程则负责切断先前主节点对共享文件的编辑，让新的主节点安全地进行故障转移。

Important:

When you use Quorum-based Storage, only one NameNode will ever be allowed to write to the JournalNodes, so there is no potential for corrupting the file system metadata in a "split-brain" scenario. But when a failover occurs, it is still possible that the previous Active NameNode could serve read requests to clients - and these requests may be out of date - until that NameNode shuts down when it tries to write to the JournalNodes. For this reason, it is still desirable to configure some fencing methods even when using Quorum-based Storage.

来源：https://www.cnblogs.com/shihuai355/p/3894186.html

标签

HDFS

namespace

可用性