HDFS Namenode HA:为什么要使用NFS而不是简单地在两者之间复制?

时间:2012-06-13 23:26:16

标签: hadoop hdfs high-availability

查看Facebook用于为HDFS Namenode提供HA的AvatarNode解决方案,我不明白使用NFS的原因。令我感到困惑的是,无论如何,NFS必须复制以实现HA。主要必须写入NFS并刷新以获得HA。为什么不简单地在主要和辅助节点之间打开套接字通道,并对辅助Namenode执行相同的写入操作。它将是(大约)相同数量的网络流量,并且似乎具有相同的复制语义。

所以问题是,为什么不这样做?

我认为有一个原因可能是NFS存在,因此问题实现起来可能更简单。但考虑到在主要和次要之间使用原始套接字通道(显而易见)的简单性,将写入流接口(即文件)的相同信息写入NFS,我仍然不知道为什么这不是完成了。

当然,必须有一些很好的理由选择使用我在扶手椅分析中缺少的NFS。

3 个答案:

答案 0 :(得分:2)

我不知道,但我同意这似乎是一个非常奇怪的选择,我真的想不出任何其他原因,但是负责修复某些东西的团队有一个功能正常的NFS设置用于其他一些用途。但根据我的经验,我认为NFS是另一个失败的单点,并且不会选择这样的情况。

答案 1 :(得分:1)

有趣的问题。我在AvatarNodes上发现了这篇文章:http://hadoopblog.blogspot.com/2010/02/hadoop-namenode-high-availability.html

在我看来,AvatarNode允许您在名称节点关闭时最小化停机时间,并在不到一分钟的时间内使用新名称节点进行备份。

来自hadoop documentation

The term "secondary name-node" is somewhat misleading. It is not a name-node in the   
sense that data-nodes cannot connect to the secondary name-node, and in no event it can 
replace the primary name-node in case of its failure.

由于辅助名称节点不能充当名称节点,因此在恢复或启动新名称节点时会出现长时间停机的可能性。

AvatarNode可以充当辅助节点和主节点,只需切换VIP即可实现快速故障转移。

关于为什么使用NFS而不是套接字,帖子说

It is guaranteed that the Standby AvatarNode ingests all committed transactions because    
it reopens the edits log and consumes all transactions till the end of the file; this 
guarantee depends on the fact that NFS-v3 supports close-to-open cache coherency 
semantics.

我认为这是在名称节点关闭并保持与HDFS编辑数据的一致性时最小化数据丢失的问题。有关近乎开放的一致性保证的更多信息,请访问:http://nfs.sourceforge.net/#faq_a8

答案 2 :(得分:0)

哈尔,this可能会回答你的问题(特别是“踢开罐头”)......