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实现对客户端访问的透明；
该方案的优点为：切换时间很快，在秒级范围实现切换（<1分钟）；
该方案的缺点为：
- 不实现自动failover，切换由OP人工介入；作者对该点的解释为：Hadoop集群的停机主要是由升级需要引起的，因而升级时由OP手工进行failover操作，从而也不需要担心脑裂问题；AvatarNode方案不会应对意外故障导致的集群停机；（自从公司线上Hadoop集群4月19号完成内存GC bug修复稳定之后，6次停机（数据来源OP升级通告）中仅有一次是由意外故障导致，其余都因为NameNode升级操作；AvatarNode方案作者说法与公司集群状况基本吻合；）
- 依赖NFS服务，
- NFS服务读写性能差；AvatarNode方案作者对该点解释为：Facebook使用了一台NetApp的NAS服务器保存AvatarNode的元数据，性能很高。
- HA风险转嫁给NFS服务器；NFS服务器停机带来的后果未知；
- 大多Linux的NFS客户端实现有问题，如果不进行正确的配置，在某些意外情况下（NFS服务器停机）NameNode可能被卡住且无法恢复；
4. HDFS HA Branch方案系列
11年HDFS HA成为一条独立的分支进行讨论研究并最終合并进入0.23版主干，参见Apache JIRA HDFS-1623 [5]；
该方案考虑了多种可选的解决途径，例如：使用共享NFS存储或editLog复写、使用LinuxHA ResourceManager 或 Zookeeper FailoverController；甚至之前的BackupNode方案也被包含其中；
最被看好的是BookKeeper[6]复写方案＋Zookeeper FailoverController；
BookKeeper复写方案依赖BookKeeper团队实现的分布式日志服务来保存NameNode的editLog；
Zookeeper FailoverController可以实现对Active/Standby NameNode的状态监控和主从选举；
该方案对block信息的处理与AvatarNode类似：DataNode都明确知道系统中所有NameNode的存在，向它们分别汇报block信息；
优点：社区主干代码，支持较好；可选择性丰富；
缺点：根据不同子方案需要单独评估缺点；引入模块较多，分析评估升级代价较大；
注：
CDH4方案来源于HA Branch方案系列，在元数据存储上采用了共享NFS存储的方式[7]，缺点与AvatarNode相同；
5. Quorum-based方案
因为主干HA方案中对NFS或BookKeeper的依赖问题，12年时开源社区又出现了一套基于Quorum的HA方案，见HDFS-3077[8]；
该方案的思想是：
- 集群中启动三个JournalNode；
- 集群中每个NameNode上同时运行一个QuorumJournalManager组件；通过Hadoop IPC向JournalNode写入editLog；
- 当QJM写editLog前，首先要保证没有其它QJM在写editLog，从而保证当发生脑裂时，editLog的写入依然是安全的；这一点的实现是通过QJM成为写者时（其NameNode成为Active节点时）分配唯一的epoch号，并广播给所有JournalNode，JournalNode在执行写editLog操作前对請求者QJM的epoch号进行检查；epoch号的申请也是经过JN和QJM的仲裁同意的；
- 当QJM写editLog前，同样需要保证之前editLog在所有JN上一致；例如如果一个QJM写过程中发生失败，则几个JN的editLog的尾部很可能不同，新的QJM成为写者时，需要对这些不一致的editLog进行同步，仲裁后保证一致；
- 当QJM写editLog时，只要JN中的大部分（2/3）成功，就算成功；可以继续执行后续操作；
仅关心了editLog的存储问题，其它技术细节默认沿用主干HA方案；
优点：对第三方模块、特殊硬件无依赖；
缺点：仍在开发中，无法评估；
参考：
［1］：Apache JIRA HADOOP-4539，https://issues.apache.org/jira/browse/HADOOP-4539
［2］：Cloudera hadoop-ha-configuration Blog，http://www.cloudera.com/blog/2009/07/hadoop-ha-configuration/
［3］：Apache JIRA HDFS-976，https://issues.apache.org/jira/browse/HDFS-976
［4］：AvatarNode Description，https://issues.apache.org/jira/secure/attachment/12435811/AvatarNodeDescription.txt
［5］：Apache JIRA HDFS-1623，https://issues.apache.org/jira/browse/HDFS-1623
［6］：BookKeeper，http://zookeeper.apache.org/bookkeeper/
［7］：CDH4 HA，http://www.cloudera.com/blog/2012/03/high-availability-for-the-hadoop-distributed-file-system-hdfs/
［8］：Apache JIRA HDFS-3077，https://issues.apache.org/jira/browse/HDFS-3077
