NameNode最关键的问题在于有单点的风险,一旦NameName挂掉,整个HDFS都无法提供服务。大脑坏掉了,身体也是无法行动的。
对于高可用的方案,业界一般通常使用两种类型的手段。
1:主备(Master-Slave)
2:集群(Cluster)
无论是HDFS或者其他存储、应用、服务要达到高可用基本都脱离不了这些方案。太阳底下基本没有太大的新鲜事,不同之处在于处理整体的架构前提下的细节会不一样。
一般来说,主备的方案主要涉及到
1:切换方式。
2:主备数据同步方式。
具体的方案如下列表:
名称 部署类型 切换方式 数据同步
AvatarNode 主从热备 人工 共享存储
BackupNode 主从温备 人工 复写
Cloudera CDH4B1 主从冷备 人工 共享存储
Heartbeat+DRBD 主从冷备 人工|自动 共享存储
BookKeeper 主从热备 人工|自动 复写
AvatarNode
是FaceBook最早的方案 ,也是目前使用方式最普遍的方式,在这里推荐淘宝hadoop集群负责人的博客,里面有提到一些。http://luoli523.com/
其主要核心描述如下:
1、谁是当前NameNode保持在zookeeper中。
2、主NameNode和备NameNode通过共享存储NFS来进行数据备份(fsimage和editlog)。
3、备NameNode帮助主NameNode做checkpoint。(将某个时间的镜像元数据和后续的操作变成新的镜像)
4、DataNode汇报BlockList的时候同时汇报给主NameNode和备NameNode。
FaceBook的github开源地址可参见https://github.com/facebook/hadoop-20
出问题的时候需要人工介入,先干掉主NameNode,再将虚拟IP指向备NameNode。实际上这部分某种程度是可以自动完成的,但是使用自动的方式后问题在于无法真实判断当前的操作合理性。所以人工干预带来的风险会更小,切换过程理论在分钟内。在这里,也推荐看淘宝开源的TFS(taobao file system)地址
:http://code.taobao.org/p/tfs/src/,
如图观看,TFS如何处理NameNode挂掉的问题:
NameServer一台为主,一台为备,主机绑定到对外vip,提供服务;当主机器宕机后,迅速将vip绑定至备份NameServer,将其切换为主机,对外提供服务。图中的HeartAgent就完成了此功能。
BackupNode
BackupNode是社区版本Hadoop0.21中提供的方案,和第一种方案相比备份方案相比区别在于:
1、DataNode只向主NameNode汇报。
2、主备数据一致性通过复写来保证。(主要避免NFS共享中(IO Fencingde 的问题)
结构如下:
缺陷在于,主故障切换的时候需要构建BlockMap,会花费相当长的时间。
Cloudera
Cloudera和AvatarNode方案类似,区别在于提供了Fencingde 机制。
Heartbeat
Heartbeat方案通过Linux下的工具来实现,利用Heartbeat做心跳检测,DRBD实现数据共享。
BookKeeper
BookKeeper方案已经合并到0.23分支中,FaceBook、淘宝等公司已经在对其进行调研。
BookKeeper主要是避免两个问题:
1、共享存储的可靠性,如果共享存储挂了。数据无法同步、备NameNode无法正常工作。(一般是主本地一份editlog,共享存储一份)
2、当主备都认为自己是主的时候(脑裂),共享存储的数据无法正常同步。这也是为什么AvatarNode方式切换的时候要先干掉主NameNode,也就是我们常说的IOFencing问题。
BookKeeper实际上是一种日志系统以帮助记录EditLog,BookKeeper自己注重了日志的可靠性等问题。如下图:
如上图:
1、每一个服务器称为一个Bookie。
2、每一个日志流为一个Ledger。
3、BookKeeper自动会将数据备份到其他机器。
4、元数据存储在ZooKeeper中。
最后,用哪种方法其实并不重要,关键是解决在自己场景下的问题。每一种方法的点可能都会成为最终HDFS集群中NameNode的一个特性。