本文共 2760 字，大约阅读时间需要 9 分钟。

体搭建过程

在Hadoop 2.0之前，单点故障是一个普遍存在的问题。为了解决这一问题，开发者尝试了多种方法，包括Secondary NameNode、Backup NameNode和手动配置等。然而，这些方法都存在一定的局限性，无法在故障发生时保证数据的连续性。Facebook等大公司在这一领域积累了宝贵的经验，这些经验对Hadoop 2.0的设计有了直接的启发。

为什么需要HA和Federation

1. 单点故障

在Hadoop 2.0之前，单点故障是HDFS的主要问题之一。虽然尝试了多种方案，但都未能完全解决这一问题。例如，Secondary NameNode虽然可以缩短集群启动时间，但在主NameNode失效时无法保证数据的完整性。Backup NameNode同样存在类似问题。Facebook的解决方案——使用虚拟IP手动切换主NameNode——虽然可靠，但需要管理员干预，且无法自动切换。

2. 集群容量和集群性能

单NameNode架构在集群扩展和性能上存在瓶颈。随着集群规模的扩大，NameNode的内存使用会急剧增加，成为性能的关键点。此外，元数据的读写操作也会成为集群的主要负载。Hadoop 2.0通过Federation（联邦）解决了这些问题。

Hadoop 2.0里HA的实现方式

在Hadoop 2.0中，HA通过ZooKeeper FailoverController（ZKFC）实现。主要设计点包括：

• 共享存储：用于同步NameNode的编辑信息，确保数据一致性。
• 数据节点向NameNode汇报：确保所有节点保持最新状态。
• 防止脑裂：通过共享存储和网络隔离机制，保证只有一个主NameNode。

Hadoop 2.0里Federation的实现方式

Federation通过多个NameService（NameService）组成一个集群，每个NameService由一个或两个NameNode组成。主要设计点包括：

• 多个NameService共享存储资源：每个NameService有独立的存储池。
• 客户端挂载表：通过路径映射，客户端可以方便地访问多个NameService上的数据。

Federation的优势在于：

• 向前兼容：现有配置无需修改，客户端无需额外配置。
• 分离命名空间和块存储：支持多种文件系统和应用。
• 良好的扩展性：通过挂载表实现灵活的存储路径。

测试环境

我们的测试环境包括6个DataNode和4个NameNode，组成两个HA集群，通过Federation对外提供服务。客户端通过挂载表映射到不同的NameService。

配置说明

HA配置

     
    
     dfs.nameservices
      
    
     ns1, ns2
    
   
     
    
     dfs.ha.namenodes.ns1
      
    
     nn1, nn3
    
   
     
    
     dfs.ha.namenodes.ns2
      
    
     nn2, nn4
    
   
     
    
     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
    
   
     
    
     dfs.namenode.rpc-address.ns2.nn2
      
    
     host-nn2:9000
    
   
     
    
     dfs.namenode.http-address.ns2.nn2
      
    
     host-nn2:50070
    
   
     
    
     dfs.namenode.rpc-address.ns2.nn4
      
    
     host-nn4:9000
    
   
     
    
     dfs.namenode.http-address.ns2.nn4
      
    
     host-nn4:50070
    
   

Federation配置

     
    
     dfs.nameservices
      
    
     ns1, ns2
    
   
     
    
     dfs.namenode.rpc-address.ns1
      
    
     host-nn1:9000
    
   
     
    
     dfs.namenode.http-address.ns1
      
    
     host-nn1:50070
    
   
     
    
     dfs.namenode.rpc-address.ns2
      
    
     host-nn2:9000
    
   
     
    
     dfs.namenode.http-address.ns2
      
    
     host-nn2:50070
    
   

测试结果

HA测试表明：

• ZKFC主动释放锁：切换时间5-8秒，客户端偶尔有重试，但未失败。
• ZK锁超时：切换时间15-20秒，客户端重试率较高，偶有失败，但数据完整性保障。

HA推荐配置

• ZooKeeper超时间隔：10000 ms。
• 隔离方法：通过脚本控制NFS iptables，确保原主NameNode无法访问。

客户端重试机制

客户端重试逻辑在org.apache.hadoop.io.retry.RetryPolicies.FailoverOnNetworkExceptionRetry中实现，支持多次重试，重试间隔随机在500-15000 ms之间。

未尽事宜

关于15%的失败率，主要原因是Standby NameNode在切换时尝试重置文件租赁，导致LeaseExpiredException。这种安全性设计可能会影响客户端体验，但为了数据完整性，这是必要的权衡。

转载地址：http://enuk.baihongyu.com/