Hadoop Namenode HA方案比较

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