Hadoop2.0 Namenode HA实现方案介绍及汇总

基于社区最新release的Hadoop2.2.0版本，调研了hadoop HA方面的内容。hadoop2.0主要的新特性(Hadoop2.0稳定版2.2.0新特性剖析)：

  1. hdfs snapshots: apache官方对hdfs snapshots说明
  2. namenode federation: namenode在集群规模大了之后会成为性能瓶颈，尤其是内存使用量急剧增大，同时hdfs所有元数据信息的读取和操作都要与namenode通信。而联邦模式解决的就是namenode的可扩展性问题。更多内容可以参看hadoop
    2.0 namenode HA实战和federation实践     下图是我画的HA和Federation部署图。每个namesevice映射了HDFS中部分实际路径，可以单独给Client提供服务，也可以由Client通过Client Mount Table来访问若干NS。图中每个NS里有一个active NN和一个standby NN，这部分HA会在下面介绍。每个NS对应了一个Pool，Pool对应的DN是该NS可以访问的DN id的集合。这样做到可扩展，带来的好处有很多，比如后续添加的NS不会影响之前的NS等。联邦部署适合大规模集群，一般规模不大的情况下不需要使用。下面主要介绍HA的内容。
  3. namenode单点故障解决方案。NN现在的HA解决方案主要思路是提供一个保存元数据信息的地方，保证editlog不会丢失。董的这篇HA单点故障解决方案总结中介绍了从解决MRv1的Jobtracker HA，到HDFS HA，再到还未正式发布的YARN
    RM HA解决方案的异同，各自采用的共享存储系统有所不同，主要原因是HA的解决方案难度取决于Master自身记录信息的多少和信息可重构性。共享存储系统主要有NFS，ZK，BookKeeper，QJM。其中已经发行版本里默认使用的QJM(Quaro Journal Manager)。QJM是Cloudera公司提出的，在QJM出现前，如果在主从切换的这段时间内出现脑裂，破坏HDFS元数据的时候，常见方式是去掉activeNN的写权限来保证最多只有一个active NN。QJM本质上是Paxos算法的实现，通过启动2N+1个JournalNode来写editlog，当其中大于N个Node写成功时候认为本次写成功，且允许容忍N以下个Node挂掉。QJM实现及源码分析可以参考基于QJM的HDFS
    HA原理及代码分析    。QJM和BKJM(借助BookKeeper实现的JM)都是将editlog信息写在磁盘上，这点也是与NFS方案的区别，且NFS相对而言其实更重量级，本身是一个需要独立维护的东西，而QJM是已经实现的默认方案，配置方法在官方里也可以找到，很详细。BKJM正在实现中且长期看好。关于BookKeeper相关的JIRA进展可以参考BookKeeper Option For NN HA。所以总结来说推荐使用QJM和BKJM，且他们的原理比较相似。再给出HDFS JIRA上一份cloudera员工给的Quorum-Journal Design设计文档，地址为https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf
  4. hdfs symbo links将在2.3.0里发布。类似linux文件系统的软链接。相关资料可以参考理解 Linux 的硬链接与软链接  硬连接和软连接的原理

其实现在的HA方案，很大程度上参考的是Facebook的AvatarNode的NN HA方案，只是他是手动的。Facebook的AvatarNode是业界较早的Namenode HA方案，它是基于HDFS 0.20实现的，如下图所示。

由于采用的是人工切换，所以实现相对简单。AvatarNode对Namenode进行了封装，处于工作状态的叫Primary Avatar，处于热备状态的叫Standby Avatar(封装了Namenode和SecondaryNameNode)，两者通过NFS共享EditLog所在目录。在工作状态下，Primary Avatar中的Namenode实例接收Client的请求并进行处理，Datanode会向Primary和Standby两个同时发送blockReport和心跳，Standby Avatar不断地从共享的EditLog中持续写入的新事务，并推送给它的Namenode实例，此时Standby
Avatar内部的Namenode处于安全模式状态，不对外提供服务，但是状态与Primary Avatar中的保持一致。一旦Primary发生故障，管理员进行Failover切换：首先将原来的Primary进程杀死(避免了“Split Brain”和“IO Fencing”问题)，然后将原来的Standby设置为Primary，新的Primary会保证回放完成所有的EditLog事务，然后退出安全模式，对外接收服务请求。为了实现对客户端透明，AvatarNode主从采用相同的虚拟IP，切换时将新的Primary设置为该虚拟IP即可。整个流程可在秒~分钟级别完成。可以参考FaceBook
2011年的论文 Apache Hadoop Goes Realtime at Facebook 里面专门有一节讲到HA AvatarNode的设计。

在董的博客里还谈到hadoop 2.0尚未解决的问题，提到namenode的热备现在只能是一个，且共享存储系统也只能有一套，本质上还是单点故障，其实是做了一层转移。YARN的HA还没解决。多资源存储可能存在潜在问题。这里关于YARN RM的HA的话，可以继续跟进JIRA上的情况，JIRA地址为https://issues.apache.org/jira/browse/YARN-149，里面有RM
HA的设计思路，最新的两篇文档：YARN ResourceManager Automatic Failover 和 RM
HA Phase1: Cold Standby 关注这个问题的朋友可以跟进关注一下。

总结

本文参考了网上一些资深研究者的博客资料和HDFS JIRA上的一些内容，整理了一下NN HA方面的几种实现方式，也提供了更多细致和详细的内容链接。

(全文完)

时间： 2024-10-30 20:26:36

Hadoop2.0 Namenode HA实现方案介绍及汇总的相关文章

BookKeeper设计介绍及其在Hadoop2.0 Namenode HA方案中的使用分析

BookKeeper背景 BK是一个可靠的日志流记录系统,用于将系统产生的日志(也可以是其他数据)记录在BK集群上,由BK这个第三方Storage保证数据存储的可靠和一致性.典型场景是系统写write-ahead log,即先把log写到BK上,再对log做处理,比如将log写到内存的数据结构中.BookKeeper同时适用于任何单点写入并要求保证高性能和数据不丢失(Strong Durabilty Guarantees)的场景. BK诞生于Hadoop2.0的namenode HA.在Hado

Hadoop 2.0 NameNode HA和Federation实践

一.背景 天云趋势在2012年下半年开始为某大型国有银行的历史交易 数据备份及查询提供基于Hadoop的技术解决方案,由于行业的特殊性,客户对服 务的可用性有着非常高的要求,而HDFS长久以来都被单点故障的问题所困扰,直 到Apache Hadoop在2012年5月发布了2.0的alpha版本,其中MRv2还很不成熟,可 HDFS的新功能已经基本可用,尤其是其中的的High Availability(以下简称HA) 和Federation.Cloudera也于7月制作了CDH4.0.1,包含了H

Hadoop-2.7.0中HDFS NameNode HA实现之DFSZKFailoverController、ZKFailoverController（一）

一.简介       DFSZKFailoverController是Hadoop-2.7.0中HDFS NameNode HA实现的中心组件,它负责整体的故障转移控制等.它是一个守护进程,通过main()方法启动,继承自ZKFailoverController. 二.实现流程       1.启动        通过main()方法启动,如下: /** * 进程启动的main()方法 */ public static void main(String args[]) throws Except

Hadoop-2.7.0中HDFS NameNode HA实现综述

一.原理       HDFS中NameNode等的HA是基于ZooKeeper实现的.它应用了ZooKeeper集群的如下功能或特性:       1.只要半数以上节点还存活,就继续能对外提供服务:       2.ZooKeeper通过Paxos算法提供了leader选举功能,其它follower learn leader:       3.ZooKeeper提供了watcher机制,只要ZooKeeper上znode增减,或内容发生变化,或其子znode有增减,客户端都可以通过注册的wat

【干货】Apache Hadoop 2.8 完全分布式集群搭建超详细过程，实现NameNode HA、ResourceManager HA高可靠性

最近在自己的笔记本电脑上搭建了Apache Hadoop分布式集群,采用了最新的稳定版本2.8,并配置了NameNode.ResourceManager的HA高可用,方便日常对Hadoop的研究与测试工作.详细的搭建过程如下: 1.安装docker,创建docker容器,用于搭建hadoop节点 docker真是个好东西啊,当要在自己的笔记本上搭建分布式集群时,由于CPU.内存.磁盘有限,无法在VMware上虚拟出太多节点,这时使用docker创建几个容器,就能轻松搭建一个分布式集群了. (1)

这可能是最全的 Redis 集群方案介绍了

由于Redis出众的性能,其在众多的移动互联网企业中得到广泛的应用.Redis在3.0版本前只支持单实例模式,虽然现在的服务器内存可以达到100GB.200GB的规模,但是单实例模式限制了Redis没法满足业务的需求(例如新浪微博就曾经用Redis存储了超过1TB的数据).Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版.各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案.

PHP 7.0新增加的特性介绍

?? 运算符(NULL 合并运算符) 把这个放在第一个说是因为我觉得它很有用.用法: $a = $_GET['a'] ?? 1;它相当于: <?PHP $a = isset($_GET['a']) ? $_GET['a'] : 1; 我们知道三元运算符是可以这样用的: $a ?: 1但是这是建立在 $a 已经定义了的前提上. ?? 运算符(NULL 合并运算符) 把这个放在第一个说是因为我觉得它很有用.用法: $a = $_GET['a'] ?? 1; 它相当于: <?php $a = iss

Hadoop2.6.0子项目hadoop-mapreduce-examples的简单介绍

引文 学习Hadoop的同学们,一定知道如果运行Hadoop自带的各种例子,以大名鼎鼎的wordcount为例,你会输入以下命令: hadoop org.apache.hadoop.examples.WordCount -D mapreduce.input.fileinputformat.split.maxsize=1 /wordcount/input /wordcount/output/result1 当然,有些人还会用以下替代方式: hadoop jar share/hadoop/mapre

高可用之0——各种方案介绍

oracle 主要有3中高可用的方案,下面分别描述下: 1.RAC 多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储.这个系统可以容忍单机/或是多机失败. 不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内.如果机房出故障,比如网络不通,那就坏了.所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故. 2.DG Data Guard这个方案就适合多机房的.