什么是高可用性？
高可用集群是指以减少服务中断时间为目的的服务器集群技术。
高可用性HA（HighAvailability）指的是通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。
高可用性（HA）的功能：
1、软件故障监测与排除
2、备份和数据保护
- |
3、管理站能够监视各站点的运行情况，能随时或定时报告系统运行状况，故障能及时报告和告警，并有必要的控制手段
4、实现错误隔离以及主、备份服务器间的服务切换
背景分析：
HDFS的高可用性（HA）是Hadoop的一个缺点，不管是HDFS还是Map-Reduce，都是采用单master的方式，集群中的其他机器都是与一台中心机器进行通信，如果这个中心机器挂了，集群就只有不工作了(不一定数据会丢失，但是至少需要重启等等工作)，让可用性变得更低。这个一般叫做单点失败 (single point of failure,SPOF)。本文通过比较Hadoop各版的改变还查看对这个问题的解决方案。
问题描述：
解决Namenode结点宕机时导致的集群不可用, 增强HDFS的高可用性
方案描述：
在Hadoop0.23.1版本以前，当Namenode所在服务器宕机时，可利用Namenode备份的元数据重构新的Namenode来投入使用。
方案一：
Hadoop本身提供了可利用secondaryNamenode的备份数据来恢复Namenode的元数据的方案，但因为checkpoint(在每次checkpoint的时候secondaryNamenode才会合并并同步Namenode的数据)的问题，secondaryNamenode的备份数据并不能时刻保持与Namenode同步，即在Namenode宕机的时候secondaryNamenode会丢失一段时间的数据，这段时间取决于checkpoint的周期。可以减小checkpoint的周期来减少数据的丢失量，但由于每次checkpoint很耗性能，而且这种方案也不能从根本上解决数据丢失的问题。
缺点：secondaryNamenode的备份数据并不能时刻保持与Namenode同步，不能从根本上解决数据丢失的问题。
方案二：
Hadoop提供的另一种方案就是NFS(网络文件系统)，一种即时备份Namenode元数据的方案，设置多个data目录（包括NFS目录），让Namenode在持久化元数据的时候同时写入多个目录，这种方案较第一种方案的优势是能避免数据的丢失（这里我们暂时不讨论NFS本身会丢失数据的可能性，毕竟这种几率很小很小）。
缺点：
1.namenode的IP映射及访问问题，重新构造namenode可能导致客户端访问IP不一致，但可以在备用namenode投入使用的时候，配置其IP和原namenode一致
2.NFS服务器宕机导致集群瘫痪，可配置NFS集群来确保NFS的可用性。
3.重新构造namenode的时延问题，不能确保故障发生时能立即投入使用，对于需要即时使用的项目建议采用namenode热备方案。这是最关键的，会有中断。这对于高可用性集群是不可接受的
注：方案一和二选自：http://www.linuxidc.com/Linux/2012-06/63558.htm
方案三：
用Vmware搭建虚拟集群，对NameNode节点进行镜像备份，如果NameNode挂掉，那么立刻换上镜像备份的机器，使其可用性变高。
缺点：这个不是Hadoop内置的解决方案，而且Vmware这一套东西也并不便宜。
注：这个方案三，我并不熟悉，只是知道有，但还没试过。引自: http://www.linuxidc.com/Linux/2012-06/63563.htm-
Hadoop 2.0.0-alpha版本给出的解决方案
方案四：
在同一个集群中配置两个的Namenode，其中一个处于活动状态，当发生崩溃时，可以快速的转移到冗余的Namenode上。
在一个典型的高可用性集群上，两个NameNode被配置在两个分开的机器上。在任何时刻，这两个NameNode只能有一个处于活动状态，而另一个处于备用状态。这在集群中处于活动状态的NameNode负责全部客户端的请求，而处于备用状态的NameNode时刻备份着活动NameNode中的数据，以便在活动的NameNode崩溃时提供一个快速的失效备援。
在当前的Hadoop2.0.0版式本中，提供了一种机制可以使处于备用状态的Namenode中的数据与处于活动状态的Namenode中的数据同步，这种机制的实现必须需要这两个NameNode可访问在一个共享存储设备(比如：来自NAS上的NFS)上的目录。这种限制在将来的版本中极有可能会放松。
当namespace被处于活动状态的NameNode修改时，这个修改操作被持久化的写入到共享目录里的一个编辑日志文件里。而处于备用状态的NameNode不断的查看这个共享目录中的编辑日志文件，一旦发现这个编辑日志文件有变化，就把它们拷贝到自己的namespace里。当处于活动状态的NameNode崩溃时，处于备用状态的NameNode代替崩溃的NameNode成为处于活动状态的NameNdoe，而在此之前处于备用状态的NameNode会确保它从共享目录中全部读取了编辑日志中的记录，这样就确保了在失效备援以前这两个NameNode中的namespace是完全同步的。
为提供快速的失效备援， 需要处于备份状态的NameNode结点有集群中块位置的最新信息，为了实现这一点，处于这两个NameNode管理的所有DataNodes，都需要向这两个NameNode发送块信息和心跳信息。
对正确操作高可用性的集群而言，至关重要的一点，是在在任何时刻这两个NameNode只参有一个NameNode处于活动状态，否则namespace将会处于不一致状态，这将会导致数据丢失或其他不可知结果。为了保证这点和防止“split-brain”场景的出现，管理员必须至少设置一个方法对共享存储进行保护。当失效备援时，如果不能验证先前处于活动状态的NameNode结点被它已经放弃了活动状态，那先前设置的保护方法有责任切断先前处于活动状态的Namenode的访问共享编辑日志文件的通道。这可以阻止先前处于活动状态Namenode对namespace的修改，并且允许当前新的处于活动状态的NameNode安全的处理失效备援。
注意：当前只实现了手动的失效备援，这意味着高可用的NameNodes没有自动识别活动的NameNode崩溃的能力，只能依靠操作员手动的恢复。自动失败的检测和恢复会在未来的版本中实现。
方案四：所需的硬件资源：
为了部署一个HA群集，应该准备以下几点：
NameNode machines – 运行活动和备份的NameNode结点的机器应该有相同的配置。
Shared storage – 需要有一个让两个NameNode都可以读/写的共享目录，通常，这是一个远程文件管理器，它支持NFS并且安置在每一个NameNode machines上。当前只支持单共享编辑目录。因此，系统的可用性就被共享目录的可用性限制了，因此为了清除掉所有的SPOF问题，这需要冗余的共享编辑目录。
这方案四就是Hadoop 2.0.0-alpha要做的事，但是当前只实现了手动的失效备援，这意味着高可用的NameNodes没有自动识别活动的NameNode崩溃的能力，只能依靠操作员手动的恢复。自动失败的检测和恢复会在未来的版本中实现。
