AvatarNode系统

NameNode是一个单一故障点，而Hadoop自身的HA机制回复耗时较长，以Backup Node为例，一个1.5亿文件规模的HDFS系统，NameNode重启服务最少需要20~45分钟，这对于24x7 uptime来说是难以接受的。在这个前提下，facebook提出了HDFS的热备份机制AvatarNode，力图达到秒级迁移

 

系统架构

---

 

AvatarNode的系统架构如下图所示，包括一个Primary AvatarNode、一个Standby AvatarNode 、一个NFS服务器、多个DataNodes以及多个 Client

 

· Primary AvatarNode是对外提供服务的Namenode

· Standby AvatarNode也运行一个NameNode进程，与Priamry AvatarNode的内存元数据同步，当primary无法服务时，代替primary对外提供服务

· Primary和Standby通过NFS服务器进行元数据同步，Primary顶起向NFS共享目录写入日志，Standby顶起读入NFS共享目录中的日志记录至内存进行合并，保证Primary和Standby的内存元数据完全一致

· DataNodes定期向primary和standby发送心跳报文

· Clients提供客户端

 

AvatarNode的特点：

---

 

① 采用两个Namenode进行元数据同步，同时Datanode向两个NameNode发送心跳报文，这样确保Standby AvatarNode内存元数据与Primary AvatarNode内存数据完全一致，因此切换成功后就可以对外提供服务，大大缩短了HA时间

② AvatarNode使用的NFS服务器有可能成为新的SPOF，但是实测中NFS出现硬件顾航的几率及其小

③ AvatarNode在性能上优于BackupNode。在backup机制中，Namenode每产生一条日志记录，除了自身同步，还要等待Backup Node接收，然后在内存中更新元数据，再写入磁盘后，才算结束。对于AvatarNOde，Primary只要将日志写入NFS即可，不用同步Standby写入，因此效率要高很多。

④ AvatarNode采用了wrapper模式，尽可能的继承了Namenode的功能和特性，在此基础上做新的开发，便于HDFS与AvatarNode的维护。

 

AvatarNode的相关描述：

---

 

1.首先关于Avatar方案对于Hadoop的备份是对Dfs的的单点备份，并不包括Mapred，因为Hadoop本身就不存在处理jobtracker单点故障的机制。

2.AvatarNode继承自Namenode，而并非对Namenode的修改，AvatarDataNode同样亦如此。故Avatar的启动机制是独立于Hadoop本身的启动机制。

3.在Avatar方案中，SecondaryNamenode的职责已包括在Standby节点中，故不需要再独立启动一个SecondaryNamenode。

4.AvatarNode必须有NFS的支持，用以实现两个节点间事务日志(editlog)的共享。

5.FB提供的Avatar源码中暂时并不能实现Primary和Standby之间的自动切换，可以借助于Zookeeper的lease机制来实现自动切换。

6.Primary和Standby之间的切换只包括从Standby切换到Primary，并不支持从Primary状态切换到Standby状态。

7.AvatarDataNode并不使用VIP和AvatarNode通信，而是直接与Primary及Standby通信，故需要使用VIP漂移方案来屏蔽两个节点间切换过程中的IP变换问题。有关与Zookeeper的整合，官方称将在之后的版本发布。