关闭

Hadoop Namenode HA方案比较

标签: hadoopbranch存储shelllinuxfacebook
6305人阅读 评论(0) 收藏 举报

      我们来分析一下业界普遍关注的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服务来实现。


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:46551次
    • 积分:660
    • 等级:
    • 排名:千里之外
    • 原创:19篇
    • 转载:0篇
    • 译文:0篇
    • 评论:2条
    最新评论