Hadoop Namenode HA方案比较

原创 2012年03月23日 16:00:42

      我们来分析一下业界普遍关注的HDFS Namenode高可用解决方案,这些方案的提出无非都是想解决Namenode设计上的单点故障。这些方案按照部署类型可划分为主从(Master-Slave)和集群(Cluster),其中主从根据状态的一致程度又细分为冷备、温备和热备,按照切换方式可划分为人工切换和自动切换,按照数据同步方式可划分为共享存储和复写。 下图列举了目前HadoopHA方案,接下来我们对各种方案进行详细的介绍:


     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即可。整个流程可在秒~分钟级别完成。


    BackupNode是社区版Hadoop 0.21提供的一种高可用方案。它不仅实现了SecondaryNameNode的功能,还是实现了复写功能,即同时向Active Namenode和Standby Namenode写入EditLog,这样也避免了共享存储会遇到的“IO Fencing”问题。如果Standby意外宕机,Active Namenode会把EditLog备份到其他的地方。但是,BackupNode只能算主从温备,因为Datanode只会向Active Namenode汇报和保持心跳,一旦Active Namenode发生故障,需要人工切换到BackupNode上,并且需要在BackupNode上把BlocksMap状态完全构建起来,这样的切换时间在分钟~小时级别。


   Cloudera于2012年3月发布了CDH4B1(beta)版本,它的实现思路跟AvatarNode类似,目前也只支持人工切换,所不同的是,为了保证集群中只有一个Active Namenode,该版本显式的提供了Fencing机制。在进行人工切换时,它会先通过常规方式将Active Namenode关闭,如果失败便使用Fencing配置指定的方式强行关闭该进程,成功后才设定新的Active Namenode,否则返回失败信息。在CDH4B1为Fencing机制提供了两种方法:sshfence和shell,sshfence实现了通过SSH方式登录到目标机器上杀死Active Namenode进程,而shell方式可以调用管理员自己开发的脚本来实现Fencing。

   Heartbeat+DRBD方式是通过Linux系统提供的工具来实现Hadoop Namenode的高可用性。该方案通过Heartbeat心跳监控,DRBD实现共享存储,每个服务器都需要配备双网卡,其中的一个网卡用于心跳网络。Client通过虚拟IP与ActiveNamenode进行通信,一旦系统检测到ActiveNamenode失去心跳(宕机或进程崩溃),则进行Failover切换,切换以后新的ActiveNamenode获得了原来ActiveNamenode的虚拟IP,来接收Client的服务请求。不过,新的ActiveNamenode需要重新恢复内存状态,切换时间较长。

    在社区版HDFS的路线演进中,HA Branch是一个很重要的分支,目前HA Branch已经跟Hadoop 0.23的主干进行了合并。出于灵活性考虑,社区提出了多种高可用性方案,现在实现的是通过共享存储和Zookeeper来实现主从热备,如下图所示,不过通过BookKeeper来实现复写的方案被认为是长期看好的,当然这也需要BookKeeper团队的配合。BookKeeper是一个高性能的可靠的预写入日志系统,通过它可以实现EditLog在Active Namenode和Standby Namenode上的复写,从而取代它们之间的共享存储。社区版的方案推荐采用独立的FailoverController进程和Zookeeper来监控Active Namenode和Standby Namenode的状态和主从选举,也可以采用Linux HA和其他的Quorum服务来实现。


相关文章推荐

Namenode HA原理详解(脑裂)

Namenode HA原理详解 社区hadoop2.2.0 release版本开始支持NameNode的HA,本文将详细描述NameNode HA内部的设计与实现。   为什么要Nameno...

大数据实战下笔记——Hadoop NameNode HA的原理

NameNode高可用整体(HA)框架NameNode的主备切换NameNode的共享存储 一.NameNode高可用整体框架 组件: 两个NameNode,一个在Active上,一个在S...
  • xqclll
  • xqclll
  • 2016年08月21日 23:00
  • 1120

Hadoop-2.7.0中HDFS NameNode HA实现综述

一、原理      HDFS中NameNode等的HA是基于ZooKeeper实现的。它应用了ZooKeeper集群的如下功能或特性:      1、只要半数以上节点还存活,就继续能对外提供服务;  ...

Hadoop双namenode配置搭建(HA)

配置双namenode的目的就是为了防错,防止一个namenode挂掉数据丢失,具体原理本文不详细讲解,这里只说明具体的安装过程。Hadoop HA的搭建是基于Zookeeper的,关于Zookeep...
  • Trigl
  • Trigl
  • 2017年02月14日 17:31
  • 2848

HDFS中namenode的HA高可用机制

一、HDFS namenode HA需要实现:HA主备切换,同步元数据,防止脑裂 主备切换: 1. hadoop内部为每个namenode进程另外配置一个进程,叫DFSZKFailoverCo...

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

一、HDFS的高可用性 1.概述          本指南提供了一个HDFS的高可用性(HA)功能的概述,以及如何配置和管理HDFS高可用性(HA)集群。本文档假定读者具有对HDFS集群的组件和节...

apache hadoop namenode的HA搭建

apache hadoop namenode的HA搭建

Namenode HA原理详解(脑裂)

Namenode HA原理详解(脑裂) 目录(?)[+] Namenode HA原理详解 社区hadoop2.2.0 release版...

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

BK是一个可靠的日志流记录系统,用于将系统产生的日志(也可以是其他数据)记录在BK集群上,由BK这个第三方Storage保证数据存储的可靠和一致性。典型场景是系统写write-ahead log,即先...

Hadoop2.x通过Zookeeper实现NameNode HA方案集群搭建-实践版

配置静态IP 执行vi /etc/sysconfig/network-scripts/ifcfg-eth0,注:每个节点IP不一样 DEVICE=eth0 HWADDR=00:0C:29:B4:3...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Hadoop Namenode HA方案比较
举报原因:
原因补充:

(最多只允许输入30个字)