Hadoop HA方案调研

色破飞机

　　原文成文于去年（2012.7.30），已然过去了一年，很多信息也许已经过时，不保证正确，与Hadoop学习笔记系列一样仅为留做提醒。
　　-----
　　针对现有的所有Hadoop HA方案进行调研，以时间为线，总结如下：
1. BackupNode方案：
    08年时开源社区已经开始着手解决Namenode单点问题，随之出来的第一个方案是BackupNode方案。基于0.20版，并合并进入0.21版；参见Apache JIRA HADOOP-4539 [1]
    该方案思路为：将NameNode产生的editLog（对文件系统元数据的修改）通过网络复写到BackupNode的内存中，再由BackupNode对接收的editLog重放操作，从而保持BackupNode与NameNode的image数据结构一致。
    该方案的问题在于：

• 切换时间长；因为复写的editLog中不包含block信息，因而BackupNode内存中blockMap为空，在切换后需要等待DataNode重连并重传所有的block信息；需要时间在分钟级；
  
• 没有提供自动failover机制；BackupNode是对NameNode的元数据进行实时备份，可以用来提供只读服务，却不能在NameNode失败后接替其工作；可以人工介入修改ip从而恢复服务；
  

　　
    注：
    如果要减少切换时间，需要再增加逻辑以实现对block信息的转发，增加代码复杂性同时会遇到缓存、流控等问题，Facebook的AvatarNode方案因这些原因考虑而放弃了block信息的转发[4]；

2. DRBD LinuxHA方案：
    DRBD技术很早已有，用于Hadoop HA方案的时间不可考；
    DRBD LinuxHA方案通过操作系统级的高可用配置实现NameNode节点的高可用，它将NameNode本应写入本地磁盘的editLog和fsImange文件通过DRBD方案写到了其它节点的磁盘上，从而保证元数据信息不丢失；配置方案参考[2]；
    该方案信赖LinuxHA的心跳机制实现节点监控和切换，但切换时间很长，因为备机在切换后需要重新加入image并等待DataNode重连接并重传block信息；
    在AvatarNode方案说明中，AvatarNode作者对DRBD方案的评价是：冷备(code standby)方案，耗时极长，在一个有50,000,000文件的集群中，通过DRBD方案切换需要约1h；
3. AvatarNode方案：
    Facebook内部使用的热备(host standby)HA方案，在10年贡献到开源社区，参见Apache JIRA HDFS-976[3]；当时Facebook Hadoop集群规模为1200节点12PB参见[4]；
    AvatarNode方案基于apache hadoop 0.20版，其尽量不修改原有NameNode代码，在现有代码之上通过封装已有代码和通过成熟的技术实现高可用。
    AvatarNode方案的思路为：

• 使用一个共享的NFS服务来保存NameNode（Primary Avatar）的editLog，Standby Avatar从editLog尾部读取最新的修改，重放进自己的内存数据结构；
  
• AvatarDatanode同时向Primary和Standby汇报block信息（包括blockReport和blockReceived）；因block信息的转发需要解决缓存、流控等问题，会极大增加代码复杂度，因而放弃转发的实现；
  
• 客户端通过虚拟ip访问NameNode服务，当Standby Avatar与Primary Avatar进行切换时，通过配置该ip实现对客户端访问的透明；
  

　　
    该方案的优点为：切换时间很快，在秒级范围实现切换（