现有HDFS HA解决方案
HDFS的HA的解决方案，主要是从使用者的角度出发，提高元数据的可靠性，减少NameNode服务恢复时间。提高元数据的可靠性措施主要是对元数据进行备份，HDFS自身就具有多种机制来确保元数据的可靠性。
减少NameNode服务恢复时间的措施有两种思路：
第1种基于NameNode重启恢复服务的方式，对NameNode自身的启动过程进行分析，优化加载过程，减少启动时间；
第2种则是启动一个NameNode的热备（Warm standby）节点，当主节点不能正常服务时，由热备节点进行接替，此时主备切换时间成为服务恢复时间。
从效率上分析，第1种思路尽管进行了优化，但NameNode的启动时间仍受文件系统规模的限制，第2种则突破了这种限制。
现有比较成熟的HA解决方案有：
Hadoop的元数据备份方案
Hadoop的Secondary NameNode方案[3]
Hadoop的Checkpoint Node方案[4]
Hadoop的Backup Node方案[5]
DRDB方案[6]
Facebook的Avatarnode方案[7]
下面将依次介绍。
Hadoop的元数据备份方案
该方案利用Hadoop自身的Failover措施（通过配置dfs.name.dir），NameNode可以将元数据信息保存到多个目录。通常的做法，选择一个本地目录、一个远程目录（通过NFS进行共享），当NameNode发生故障时，可以启动备用机器的NameNode，加载远程目录中的元数据信息，提供服务。
优点
Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。
元数据有多个备份，可有效保证元数据的可靠性，并且内容保持最新状态。
元数据需要同步写入多个备份目录，效率低于单个NameNode。
缺点
该方案主要是解决元数据保存的可靠性问题，但没有做到热备，HDFS恢复服务时，需要重新启动NameNode，恢复时间与文件系统规模成正比。
NFS共享的可靠性问题，如果配置的多个目录中有任何一个目录的保存因为异常而阻塞，将会导致整个HDFS的操作阻塞，无法对外提供正常服务。
Hadoop的Secondary NameNode方案
该方案启动一个Secondary NameNode节点，该节点定期从NameNode节点上下载元数据信息（元数据镜像fsimage 和元数据库操作日志edits），然后将fsimage和edits进行合并，生成新的fsimage（该fsimage就是Secondary NameNode下载时刻的元数据的Checkpoint），在本地保存，并将其推送到NameNode，同时重置NameNode上的edits。
优点
Hadoop自带机制，成熟可靠，使用简单方便，无需开发，配置即可。
Secondaryary NameNode定期做Checkpoint，可保证各个Checkpoint阶段的元数据的可靠性，同时，进行fsimage与edits的合并，可以有效限制edits的大小，防止其无限制增长。
缺点
没有做到热备，当NameNode无法提供服务时，需要重启NameNode，服务恢复时间与文件系统规模大小成正比。
Secondary NameNode保存的只是Checkpoint时刻的元数据，因此，一旦NameNode上的元数据损坏，通过Checkpoint恢复的元数据并不是HDFS此刻的最新数据，存在一致性问题。
Hadoop的Checkpoint Node方案
Checkpoint Node方案与Secondary NameNode的原理基本相同，只是实现方式不同。该方案利用Hadoop的Checkpoint机制进行备份，配置一个Checkpoint Node。该节点会定期从Primary NameNode中下载元数据信息（fsimage+edits），将edits与fsimage进行合并，在本地形成最新的Checkpoint，并上传到Primary NameNode进行更新。
当NameNode发生故障时，极端情况下（NameNode彻底无法恢复），可以在备用节点上启动一个NameNode，读取Checkpoint信息，提供服务。
优点
使用简单方便、无需开发、配置即可。
元数据有多个备份。
缺点
没有做到热备、备份节点切换时间长。
Checkpoint Node所做的备份，只是最后一次Check时的元数据信息，并不是发生故障时最新的元数据信息，有可能造成数据的不一致。
Hadoop的Backup Node方案
利用新版本Hadoop自身的Failover措施，配置一个Backup Node，Backup Node在内存和本地磁盘均保存了HDFS系统最新的名字空间元数据信息。如果NameNode发生故障，可用使用Backup Node中最新的元数据信息。
优点
简单方便、无需开发、配置即可使用。
Backup Node的内存中对当前最新元数据信息进行了备份（Namespace），避免了通过NFS挂载进行备份所带来的风险。
Backup Node可以直接利用内存中的元数据信息进行Checkpoint，保存到本地，与从NameNode下载元数据进行Checkpoint的方式相比效率更高。
NameNode 会将元数据操作的日志记录同步到Backup Node，Backup Node会将收到的日志记录在内存中更新元数据状态，同时更新磁盘上的edits，只有当两者操作成功，整个操作才成功。这样即便NameNode上的元数据发生损坏，Backup Node的磁盘上也保存了HDFS最新的元数据，从而保证了一致性。
缺点
高版本（0.21以上）才支持。
许多特性还处于开发之中，例如：当NameNode无法工作时，Backup Node目前还无法直接接替NameNode提供服务，因此当前版本的Backup Node还不具有热备功能，也就是说，当NameNode发生故障，目前还只能通过重启NameNode的方式来恢复服务。
Backup Node的内存中未保存Block的位置信息，仍然需要等待下面的DataNode进行上报，因此，即便在后续的版本中实现了热备，仍然需要一定的切换时间。
当前版本只允许1个Backup Node连接到NameNode。
DRDB方案
利用DRDB机制进行元数据备份。
当NameNode发生故障时，可以启动备用机器的NameNode，读取DRDB备份的元数据信息，提供服务。
优点
DRDB是一种较为成熟的备份机制。
元数据有多个备份、并且保持最新状态。
由于备份的工作交由DRDB完成，对于一条新的日志记录，NameNode无需同步写入多个备份目录，因而NameNode在效率上优于Hadoop的元数据备份方案。
缺点
没有做到热备、备份节点切换时间长。
需要引入新的机制、由此带来一定的可靠性问题。
FaceBook的AvatarNode方案
利用FaceBook提出的Avatar Node机制。
Active Node作为Primary NameNode对外提供服务。Standby Node处于Safe mode模式，在内存中保存Primary NameNode最新的元数据信息。Active Node和Standby Node通过NFS共享存储进行交互。DataNode同时向Active Node和Standby Node发送Block location信息。当管理员确定Primary NameNode发生故障后，将Standby Node切换为Primary NameNode。由于Standby Node内存中保存了所有元数据的最新信息，因此可直接对外提供服务，大大缩短了切换时间。
优点
提供热备、切换时间大大缩短。
FaceBook已将其集成到自己维护的Hadoop代码中，并部署到了自己的集群使用。
缺点
修改了部分源码、增加了一定的复杂性，并在软件的维护性上带来一定问题。
参考资料较少。
只提供一个备份节点。
方案优缺点比较
综上所述，HDFS HA方案比较如表1.1所示。
表1.1 HDFS HA方案比较
方案名称 | 切换时间 | 元数据 一致性 | 是否做 checkpoint | 使用 复杂度 | 成熟度 | 相关 资料 |
元数据备份 | 长 | 一致 | 否 | 低 | 高 | 较多 |
Secondary NameNode | 长 | 不一定 | 是 | 中 | 高 | 较多 |
Checkpoint Node | 长 | 不一定 | 是 | 中 | 高 | 较少 |
Backup Node | 中 | 一致 | 是 | 中 | 中 | 较少 |
DRDB | 长 | 一致 | 否 | 高 | 高 | 多 |
AvatarNode | 短 | 一致 | 是 | 高 | 高 | 少 |
其中"元数据备份方案"不能单独使用，因为在系统运行期间，没有相应的Checkpoint机制，会造成日志的无限制增长，因此需要和Secondary NameNode、Checkpoint Node或Backup Node配合使用。
"DRDB方案"同样如此。
而对于Secondary NameNode、Checkpoint Node机制，它们只有Checkpoint的功能，而不能保存实时的元数据，因此需要在Namenode上配置元数据备份路径来保存实时元数据。
对于Backup Node，虽然它可以实时保存元数据，但为防止Backup Node成为一个单点，也需要在NameNode上配置元数据备份路径，保存在本地进行备份。
总结
元数据备份方案使用简单方便，在功能上可替代DRDB；
Backup Node是 Checkpoint Node的升级版，效率更高；
Secondary NameNode在低版本的Hadoop中就已存在。
因此用户实际上可选择的HA组合方案为：
（1）元数据备份+ Secondary NameNode
这种方案适用于目前Hadoop 的所有版本，属于冷备，切换时间长。由于Secondary NameNode自身并不实时保存元数据，一旦NameNode上的元数据损坏，将无法恢复到最新的元数据，因此采用元数据备份机制，在NameNode上需要配置多个目录进行备份，常见的做法是再配置一个NFS节点，共享一个目录进行备份。
（2）元数据备份+ Backup Node
这种方案只有在0.21.0以上版本才支持，目前的实现只支持冷备，切换时间长，自身实时保存元数据，不需要NFS节点。
（3）元数据备份+ AvatarNode
这种方案需要打Patch（补丁包），而且只支持特定的版本（0.20）或者使用FaceBook自身的Hadoop版本，切换时间短，需要一个NFS节点作为Active节点和Standby节点的数据交互节点。总之，如果当前Hadoop的版本较低，同时也不允许升级版本的话，可以选择第1种方案；如果版本较新（在0.21.0以上），第2种方案优于第1种；如果对HA切换时间有严格要求的话，则需要选择第3种方案。第1种方案比较简单，资料较多，本书将不再说明，后面着重讲述第2种和第3种方案。
