Hadoop NameNode单点问题解决方案之一 AvatarNode

我们遇到的情况
Hadoop NameNode存在单点问题。这个问题会影响分布式平台24*7运行。先说说我们的情况吧。
我们的团队负责管理一个1200节点的集群(总大小12PB),目前是运行版本为Hadoop 0.20,transaction logs写入一个共享的NFS filer(注:NetApp NFS Filer)。
经常遇到需要中断服务的问题是给hadoop打补丁。 DataNode打补丁比较简单,不会造成服务中断,每次对其中的一部分DataNode部署新的代码、重启,就OK了。 问题是需要给NameNode部署新的代码时,NodeNode重启需要花费1个小时,这期间所有的Hadoop服务都不能运行。这是不可忍受的,所以我们就想着把NameNode有个备份。我们的解决方案可以保证在1分钟内切换完成。 

当时HDFS BackupNode在Hadoop 0.20中还不能用,升级Hadoop 0.20也不是一个很好的选择。这个升级部署之前,需要花费大量时间做测试。
经过仔细的分析现状和可能的解决方案。我们设计了一个简单的解决方案:
  a. 目前我们有两个NameNode 一个Primary NameNode和一个Standby Nodenode,我们不用担心split-brain-scenario(可以想想精神分裂) 和 IO-fencing(这个名词不太了解)。OP能保证Primary NameNode完全down后,Standby NameNode才能被切换。
  b. 我们不想修改NameNode的任何代码,只想基于HDFS构建一个软件层来保证HA。我们需要一个deamon来切换Primary和Standby.
词语“Avatar”的意思是实体的变体,所以借用这个词,把NameNode的wrapper称为AvatarNode。AvatarNode完全继承NameNode,所以NameNode的优点它都完全具备。


AvatarNode介绍

AvatarNode完全封装NameNode。AvatarNode运行有两种模式Primary Avatar或者standby Avatar. 如果启动运行在Primary Avatar模式,那么它就和当前NameNode功能完全一样,其实运行的代码就是NameNode的代码。运行Primary Avatar模式的AvatarNode机器,保存HDFS事务日志(editlog)到一个共享的NFS。在另外一台机器上,启动AvatarNode的另一个实例,运行在Standby Avatar模式。
Standby AvatarNode封装了NameNode和SecondaryNameNode。Standby AvatarNode持续的从共享的NFS filer中读取HDFS editlog,并持续的把这些事务推送到Standby AvatarNode中NameNode实例。Standby AvatarNode中的NameNode运行在SafeMode。原因是不能让它负责NameNode的工作,但是必须保持和NameNode同步的NameNode Metadata信息。

HDFS客户端访问NameNode通过一个虚拟IP(Virtual IP Address,注:这块其实可以用zookeeper来取代).当发生故障需要快速切换时,管理员会在机器M1上杀掉Primary AvatarNode进程,然后在机器M2上设置Standby AvatarNode作为Primary Avatar。Standby AvatarNode会保证把所有提交的事务都处理完,因为Standby AvatarNode会重新打开edit log,并处理完文件中所有的事务.这个假设是基于NFS-v3支持close-to-open cache coherency semantics。Standby AvatarNode把所有NFS filer上的事务处理完之后,退出SafeMode模式。管理员将M2的VIP换为M1,这样所有的HDFS客户端的请求会提交到M2的实例上。这个failover一般情况只需要几秒钟。
另外根本不需要单独一台SecondaryNameNode。 AvatarNode在Standby avatar模式时,可以履行SecondaryNameNode的职责。Standby AvatarNode持续的处理从Primary Avantar来的所有的事务,在处理事务日志的空闲间隙会唤醒SecondaryNameNode进程,创建并上传一个新的checkpoint,Copy到Primary AvatarNode, 接着再回来处理事务日志。

AvatarDataNode介绍

AvatarDataNode基于Hadoop 0.20中DataNode。AvatarDataNode需要发送block报告和block接受报告到两个AvatarNode。AvatarDataNode不使用VIP和AvatarNode连接。(HDFS客户端通过VIP连接AvatarNode)。另一个可选方 案是,Primary AvatarNode转发block reports到Standby AvatarNode。没有采用可选方案是因为这种方法需要添加复杂代码到Primary AvatarNode,Primary AvatarNode需要对block reports进行缓存和控制部分流
Hadoop DataNode已经具备发送blockReceived信息到NameNode功能,我们扩展了这个功能使得发送这个消息到两个节点(Primary and Standby AvatarNodes)。


这个方案在切换过程中对于客户端的影响

HDFS客户端读取一个文件时,它会首先取得所有的文件块以及copy的位置并缓存起来,这样的话这个方案不会影响HDFS读操作。
当HDFS客户端写文件时failover发生会有什么后果呢?
Hadoop 0.20 NameNode的策略是当文件写完成,关闭后才会将新分配的块记录到metadata。这表明当failover发生的时候,正在写文件会在failover成功之后抛出IO exception错误,这个使用了Map/Reduce的容错能力,框架会重做任何失败的任务。这中解决方案在HBase中也不回出问题,因为Hbase在一个事务完成之后要有sync/hflush操作。由于map/reduce框架和Hbase的策略,使得failover事件也不会影响HDFS的写操作。

其他的HA方案

大家说让我比较一下AvatarNode HA实现和Hadoop with DRBD and Linux HA.这两种方法都是需要主节点写事务日志到一个共享的硬件。不同点是,Standby AvatarNode是一个热备而DRBD-LinuxHA是一种冷备份。AvatarNode对于5亿文件的failover时间是1分钟,但是DRBD-LinuxHA可能需要一个小时。AvatarNode可以热备的原因就是它封装了一个NameNode的实例并且这个实例会从DataNode接受信息,这使得metadata的状态是最新的

你可能感兴趣的:(NameNode)