Facebook如何使用Avartarnode提升HDFS可靠性

在不久前的Hadoop峰会上，Facebook的工程师Andrew Ryan分享了他们如何使用Namenode和Avatarnode提升HDFS可靠性的方法。Ryan从2009年开始，就参与到了Facebook的Hadoop开发中。在他的帮助下，Facebook的Hadoop和HDFS数据基础设施，从一个数据中心的单个600TB集群，发展到了多个数据中心超过100多个HDFS集群。

Ryan首先分析了HDFS的Namenode机制。

图：Namenode，单点故障点

在HDFS中，客户端通过Namenode服务器完成文件系统的元数据操作，并与一个Datanode池通信，以发送和接受文件系统数据。数据在多个Datanode上都有复制，因此一个Datanode宕机不会出现数据丢失，对集群也不应是致命问题。

但是Namenode就不是这样，所有的元数据操作都要通过它完成。如果Namenode不可用，任何客户端就无法从HDFS完成读写操作，虽然客户端仍可以从Datanode中读出单个数据块，但是整个HDFS就处于宕机状态，所有依赖于HDFS的用户和应用就无法正常工作。 

因此，HDFS Namenode是一个单点故障点（SPOF）。

Ryan指出：在Facebook，他们希望知道这个问题的影响范围，并尝试找出解决这个问题的方法。

Data Warehouse是Facebook最大的HDFS部署之一，他们用其完成传统的HadoopMapReduce工作：有一些非常大的集群运行MapReduce批处理。由于集群很大，Namenode的负载非常高，CPU、内存、磁盘和网络都常常处于很大的压力之下。他们的统计发现：在Data Warehouse发生的问题中，41%是由HDFS造成的，这也是最大的问题肇因。

Ryan接下来指出：如果能有某种高可用的Namenode方案，也许能防止10%的Data Warehouse问题和突发的宕机时间，这仍然是一个巨大的胜利，因为这让他们可以执行计划好的软件与硬件维护操作。实际上，他们估计这可以减少他们50%计划好的宕机时间，而之前在这些时间里集群都是不可用的。

下图是他们的高可用Namenode HDFS架构的简化版本。

图：高可用的Namenode

在这个架构中，客户端可以与Primary Namenode或是Standby Namenode通信，Datanode也可以向这两个服务器发送块报告，实现了高可用的Namenode——Avatarnode。

Ryan提到：Facebook在两年前就开始研究Avatarnode。现在，这已经是一个开源项目，提供高可用的Namenode，支持热切换。目前，在Facebook中，Avatarnode已经进入生产环境，并运行在他们最大的Hadoop Data Warehouse集群中。

Avatarnode是一个双节点的、高可用的Namenode，需要手工完成故障切换。它将现有的Namenode代码包装在一个Zookeeper层中。Avatarnode的基本概念包括：

• Primary Avatarnode和Standby Avatarnode角色可互换。
• 当前的Primary Avatarnode主机名保存在Zookeeper中。
• 修改后的Datanode的块报告要同时发送给Primary Avatarnode和Standby Avatarnode。
• 修改后的HDFS客户端在开始每次事务前，要检查Zookeeper，如果以此事务失败，要再次检查Zookeeper。即使Avatarnode发生故障切换，一次写操作也可以得以完成。

图：客户端视角

图：Datanode视角

Ryan指出：接下来，他们要进一步提升Avatarnode，并将其整合在一个通用的高可用框架中，使之能够完成不需人工参与的、自动化的、安全的故障切换。

读者可以访问GitHub上Facebook发布的Hadoop版本，其中包括Avatarnode源代码。

除了Facebook之外，还有其他公司也致力于解决这个问题，包括：

• Appistry，2010年就发布了一个完全分布式的文件系统
• MapR的Hadoop版本也提供高可用的文件系统
• Apache的Hadoop 2.0中，也包括了Cloudera的最新发布版本

InfoQ的读者，不知道您对如何解决Namenode高可用问题有何意见和看法？欢迎在评论中分享您的经验。