HDFS namenode 高可用(HA)搭建指南 QJM方式 ——本质是多个namenode选举master,用paxos实现一致性

  1. 云栖社区>
  2. 博客>
  3. 正文

HDFS namenode 高可用(HA)搭建指南 QJM方式 ——本质是多个namenode选举master,用paxos实现一致性

桃子红了呐 2017-11-15 17:42:00 浏览1126
展开阅读全文

一、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发送日志是并行的)。

 

摘自:http://blog.csdn.net/dangyifei/article/details/8920164













本文转自张昺华-sky博客园博客,原文链接:http://www.cnblogs.com/bonelee/p/6516424.html,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
桃子红了呐
+ 关注