360SDN.COM

首页/Hadoop/列表

Hadoop 3.0新特性:多namenode支持

来源:顶级程序员  2017-09-19 09:20:20    评论:0点击:

点击上方蓝色字体关注「顶级程序员」

介绍

Apache Hadoop 3.0-alpha1已经在不久前发布,在新版本的Hadoop中,添加了不少的新特性,其中增加了多NameNode的支持。Hadoop目前的版本只支持最多两个NameNode - 包括一个主NameNode和一个备NameNode。在没有任何一个Namenode挂起时,这种方案是高可靠的,但如果万一其中任何一个NameNode挂起了,那么这种方案就会变成非高可靠(non-HA)。

Hadoop在技术上是被设计成可以容忍任何单节点的故障。而且很多组件,包括HBASE等,要求能够容忍任何两个节点的故障,但是NameNode却是个例外。

在集群中再添加一个备NameNode意味着我们可以以最小代价在Hadoop部署中减轻“双节点挂起则集群挂起”这种情况的风险,同时仍然保持跟原来Hadoop部署(一个主NameNode和一个备NameNode)相同的性能。

注意:下面NameNode将简写成NN

 

概况

Hadoop 3.0中,增加了多NN支持的新特性,即支持多个备NN同时运行。比如通过配置3NN5JournalNodes,集群就可以容忍两个节点的挂起,而非像以前一样只能容忍一个节点挂起。

官方说明中,现在已经更新怎么配置超过两个NNHDFShigh-availability documentation

总的来说,新增加的备NN扮演的角色和原来的备NN几乎一样,只有一点点的差别。所有的NN配置方式都和之前一样,包括它们的idRPCHTTP地址等。每个备NN也还会追踪edit logsharedBKQJM方式)并和FS合并更新。

以前的方案中,备NN会尝试在每个配置的时间间隔里把最新的FSImage上传到主NN。但如果有多个备NN,就会需要一个叫“先写先赢”的原则,所有的备NN都会尝试把image上传但只有拥有最新更新的imageNN会成功,其它的NN会放弃上传但它们仍然会在本地合并日志并且周期性的检查是否应该把image上传到主NN

 

限制

这种多NN的部署要求运行的NN不超过5个,3-5个比较合适。理由有如下三个:

第一:有ZooKeeper的限制,所有NN必须在低至10s内竞争获得“active锁”。

第二:有带宽的限制。每个备NN都会追踪edit log,意味着日志需要从一个节点传输到其它所有节点。而且每个备NN都会周期性的上传最新的FSImage到主NN,保证更新。最后DN的块汇报也需要传输到所有NN

第三:在配置每个NN时有一定的物理开销。我们需要时刻保持每个NN有相同的配置,但当有3个或更多的NN时,即使有自动化配置方式,这样的操作仍然会变得有点笨重。

 

如何实施

配置:

对第三个、第四个和第五个的NN配置跟现在的NN是一模一样的。主要的不同在于需要找到一组的NN,我们会返回一个NN的列表。

 

Active/Standby状态:

Active/Standby状态由ZKFCs进行竞争”active决定,然后监听这个锁。这种竞争锁的方式在10s内完成是可行的。

ZKFailoverController:

Active状态切换可以由手工触发,就是当你触发一个备NN切换时它就会变成主NN。当进行这项操作时它会礼貌的要求其它备NN不要尝试切换。这种方式在多NN中变成:使用多NN代理要求每个NN在一段时间内放弃竞选。

有可能出现第一个NN(在我们完成要求最后一个NN放弃竞选之前)超出放弃active状态竞选的时间,在这种情况下,那你触发变成active状态的NN将在领导竞选中失败。目前在appach官方文档”MultipleStandby NameNodes”中表示这个问题在现有协议框架中还没有解决办法,最终的解决方式还得等Hadoop 3.0正式版本发布后见分晓。

 

CheckPointing:

CheckPointing是通过从备NN到主NNREST指令管理的。首先备NN会生成FSImage文件,然后请求主NN基于txn id下载FSImage。但这在多NN中会出现问题,因为我们不想在不同的备NN中多次下载相同的FSImageFSImage合并更新的整体流程如下图:



StandbyCheckpointer:

当一个备NN成功的完成一次checkpoint,它会在内部把自己标记成“primary check pointer”,这是一个boolean型的标记。在之后的迭代检查中,它会用这个标记,还有其它的一些属性决定它是否应该再次发送上传请求到主NN

具体的逻辑如下:

 

Boolean sendRequest = needCheckpoint || isPrimaryCheckPointer ||secsSinceLast  >=  checkpointConf.getQuietPeriod()

 

解释一下,这里只有满足“需要checkpoint请求(比如正在进行一次rollback checkpoint)”或“primary check pointer”或“已经过了quiet时间”里其中一个条件,就会发送上传请求。

quiet时间”保证了不会阻止其它NN的上传请求,而且这段时间可能会有很多同时发生的上传,同时防止主NNFSImage没有及时更新。目前,这种检查只是基于时间线,但是以后可以扩展到基于edits

注意,FSImage总是会在备NN的本地生成更新,即使可能不会把他传到主NN,这样可以保证一旦发生主备切换时,FSImage是最新的。

ImageServlet:

GetImageServletdoGet方法目前支持取FSImage(getimage),取日志(getedit)和存FSImage(putimage)。保存FSImage需要更多的参数,它的流程很有趣,Secondary NameNode发送一个HTTP请求到主NN,启动主NN上一个HTTP客户端到Secondary NameNode上去下载FSImage,下载需要的一些信息,都放在从NNHTTP请求中。

在多NN中保持了向所有NN发送下载请求的机制,但备NN会回复“HttpServletResponse.SC_EXPECTATION_FAILED”来表明它们不是主NN;如果主NN中已经存在这次下载请求的txn或者它正在其它节点下载,那它会回复“HttpServletResponse.SC_CONFLIC”表明这次请求已经落后了,这种方式可以把请求上传的NN置于放弃上传的状态。

 

总结

    这里我们对Hadoop 3.0NameNode的新特性做了一次预览,借此宏观了解新特性,但毕竟正式版本还没有发布,所以此文档内容可能跟正式发布版本有些差别,欢迎及时指正。

 

作者介绍

蒋涉权,毕业于北京理工大学,大数据工程师,研究领域分布式计算,数据挖掘,算法,其中主要研究HDFSSpark,目前就职于某大型设备商公司。

联系方式:13534051019,邮箱:sekingme@163.com


参考资料:

  1. https://issues.apache.org/jira/browse/HDFS-6440

  2. https://issues.apache.org/jira/secure/attachment/12677453/Multiple-Standby-NameNodes_V1.pdf

  3. http://hadoop.apache.org/docs/r3.0.0-alpha1/index.html

  4. http://hadoop.apache.org/docs/r3.0.0-alpha1/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

下图是广告

阅读原文

为您推荐

友情链接 |九搜汽车网 |手机ok生活信息网|ok生活信息网|ok微生活
 Powered by www.360SDN.COM   京ICP备11022651号-4 © 2012-2016 版权