Hadoop 2.0 NameNode HA和Federation实践

苍天有泪

　　转载于http://www.sizeofvoid.net/hadoop-2-0-namenode-ha-federation-practice-zh/
　　一、背景
　　天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案，由于行业的特殊性，客户对服务的可用性有着非常高的要求，而HDFS长久以来都被单点故障的问题所困扰，直到Apache Hadoop在2012年5月发布了2.0的alpha版本，其中MRv2还很不成熟，可HDFS的新功能已经基本可用，尤其是其中的的High Availability(以下简称HA)和Federation。Cloudera也于7月制作了CDH4.0.1，包含了Hadoop 2.0的诸多新功能和组件，于是我们就基于CDH4.0.1进行了HA和Federation的测试。
　　此工作由我和同事张军、钱兴会共同完成。
　　二、为什么需要HA和Federation

• 　　单点故障
  　　在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结
  
  
  
  • 　　Secondary NameNode。它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。
    
  • 　　Backup NameNode (HADOOP-4539)。它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。
    
  • 　　手动把name.dir指向NFS。这是安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。
    
  • 　　Facebook AvatarNode。Facebook有强大的运维做后盾，所以Avatarnode只是Hot Standby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似，从时间上来看，Hadoop 2.0应该是借鉴了Facebook的做法。
    
  • 　　还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，Linux HA，VMware的FT等等。
    
  
  
• 　　集群容量和集群性能
  　　单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop 2.0里的HDFS Federation就是为了解决这两个问题而开发的。
  

　　三、Hadoop 2.0里HA的实现方式

　　图片来源： HDFS-1623 设计文档
　　图片作者： Sanjay Radia, Suresh Srinivas
　　在这个图里，我们可以看出HA的大致架构，其设计上的考虑包括：

• 　　利用共享存储来在两个NN间同步edits信息。
  　　以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析
  
• 　　DataNode(以下简称DN)同时向两个NN汇报块信息。
  　　这是让Standby NN保持集群最新状态的必需步骤，不赘述。
  
• 　　用于监视和控制NN进程的FailoverController进程
  　　显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。
  
• 　　隔离(Fencing)，防止脑裂，就是保证在任何时候只有一个主NN，包括三个方面：
  
  
  
  • 　　共享存储fencing，确保只有一个NN可以写入edits。
    
  • 　　客户端fencing，确保只有一个NN可以响应客户端的请求。
    
  • 　　DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。
    
  
  

　　四、Hadoop 2.0里Federation的实现方式

　　图片来源： HDFS-1052 设计文档
　　图片作者： Sanjay Radia, Suresh Srinivas
　　这个图过于简明，许多设计上的考虑并不那么直观，我们稍微总结一下

• 　　多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务
  
• 　　每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储
  
• 　　DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况
  
• 　　如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录
  

　　这样设计的好处大致有：

• 　　改动最小，向前兼容
  
  
  
  • 　　现有的NN无需任何配置改动.
    
  • 　　如果现有的客户端只连某台NN的话，代码和配置也无需改动。
    
  
  
• 　　分离命名空间管理和块存储管理
  
  
  
  • 　　提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
    
  • 　　统一的块存储管理保证了资源利用率
    
  • 　　可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证
    
  
  
• 　　客户端挂载表
  
  
  
  • 　　通过路径自动对应NN
    
  • 　　使Federation的配置改动对应用透明
    
  
  

　　五、测试环境
　　以上是HA和Federation的简介，对于已经比较熟悉HDFS的朋友，这些信息应该已经可以帮助你快速理解其架构和实现，如果还需要深入了解细节的话，可以去详细阅读设计文档或是代码。这篇文章的主要目的是总结我们的测试结果，所以现在才算是正文开始。
　　为了彻底搞清HA和Federation的配置，我们直接一步到位，选择了如下的测试场景，结合了HA和Federation：

　　这张图里有个概念是前面没有说明的，就是NameService。Hadoop 2.0里对NN进行了一层抽象，提供服务的不再是NN本身，而是NameService(以下简称NS)。Federation是由多个NS组成的，每个NS又是由一个或两个(HA)NN组成的。在接下里的测试配置里会有更直观的例子。
　　图中DN-1到DN-6是六个DataNode，NN-1到NN-4是四个NameNode，分别组成两个HA的NS，再通过Federation组合对外提供服务。Storage Pool 1和Storage Pool 2分别对应这两个NS。我们在客户端进行了挂载表的映射，把/share映射到NS1，把/user映射到NS2，这个映射其实不光是要指定NS，还需要指定到其上的某个目录，稍后的配置中大家可以看到。
　　下面我们来看看配置文件里需要做哪些改动，为了便于理解，我们先把HA和Federation分别介绍，然后再介绍同时使用HA和Federation时的配置方式，首先我们来看HA的配置：
　　对于HA中的所有节点，包括NN和DN和客户端，需要做如下更改：
　　HA，所有节点，hdfs-site.xml
　　dfs.nameservices
　　ns1
　　提供服务的NS逻辑名称，与core-site.xml里的对应
　　

　　

　　dfs.ha.namenodes.${NS_ID}
　　nn1,nn3
　　列出该逻辑名称下的NameNode逻辑名称
　　

　　

　　dfs.namenode.rpc-address.${NS_ID}.${NN_ID}
　　host-nn1:9000
　　指定NameNode的RPC位置
　　

　　

　　dfs.namenode.http-address.${NS_ID}.${NN_ID}
　　host-nn1:50070
　　指定NameNode的Web Server位置
　　

　　以上的示例里，我们用了${}来表示变量值，其展开后的内容大致如下：
　　dfs.ha.namenodes.ns1
　　nn1,nn3
　　

　　

　　dfs.namenode.rpc-address.ns1.nn1
　　host-nn1:9000
　　

　　

　　dfs.namenode.http-address.ns1.nn1
　　host-nn1:50070
　　

　　

　　dfs.namenode.rpc-address.ns1.nn3
　　host-nn3:9000
　　

　　

　　dfs.namenode.http-address.ns1.nn3
　　host-nn3:50070
　　

　　与此同时，在HA集群的NameNode或客户端还需要做如下配置的改动：
　　HA，NameNode，hdfs-site.xml
　　dfs.namenode.shared.edits.dir
　　file:///nfs/ha-edits
　　指定用于HA存放edits的共享存储，通常是NFS挂载点
　　

　　

　　ha.zookeeper.quorum
　　host-zk1:2181,host-zk2:2181,host-zk3:2181,
　　指定用于HA的ZooKeeper集群机器列表
　　

　　

　　ha.zookeeper.session-timeout.ms
　　5000
　　指定ZooKeeper超时间隔，单位毫秒
　　

　　

　　dfs.ha.fencing.methods
　　sshfence
　　指定HA做隔离的方法，缺省是ssh，可设为shell，稍后详述
　　

　　HA，客户端，hdfs-site.xml
　　dfs.ha.automatic-failover.enabled
　　true
　　或者false
　　

　　

　　dfs.client.failover.proxy.provider.${NS_ID}
　　org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
　　指定客户端用于HA切换的代理类，不同的NS可以用不同的代理类
　　以上示例为Hadoop 2.0自带的缺省代理类
　　

　　最后，为了方便使用相对路径，而不是每次都使用hdfs://ns1作为文件路径的前缀，我们还需要在各角色节点上修改core-site.xml：
　　HA，所有节点，core-site.xml
　　fs.defaultFS
　　hdfs://ns1
　　缺省文件服务的协议和NS逻辑名称，和hdfs-site里的对应
　　此配置替代了1.0里的fs.default.name
　　

　　接下来我们看一下如果单独使用Federation，应该如何配置，这里我们假设没有使用HA，而是直接使用nn1和nn2组成了Federation集群，他们对应的NS的逻辑名称分别是ns1和ns2。为了便于理解，我们从客户端使用的core-site.xml和挂载表入手：
　　Federation，所有节点，core-site.xml