HDFS_HA方案优缺点比较
原文：http://book.51cto.com/art/201205/339043.htm
《高可用性的HDFS-Hadoop分布式文件系统深度实践》
2012-05-29 11:31 文艾/王磊 清华大学出版社
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组合方案为：
- 元数据备份+ Secondary NameNode
这种方案适用于目前Hadoop 的所有版本，属于冷备，切换时间长。由于Secondary NameNode自身并不实时保存元数据，一旦NameNode上的元数据损坏，将无法恢复到最新的元数据，因此采用元数据备份机制，在NameNode上需要配置多个目录进行备份，常见的做法是再配置一个NFS节点，共享一个目录进行备份。
- 元数据备份+ Backup Node
这种方案只有在0.21.0以上版本才支持，目前的实现只支持冷备，切换时间长，自身实时保存元数据，不需要NFS节点。
- 元数据备份+ AvatarNode
这种方案需要打Patch（补丁包），而且只支持特定的版本（0.20）或者使用FaceBook自身的Hadoop版本，切换时间短，需要一个NFS节点作为Active节点和Standby节点的数据交互节点。
总之，如果当前Hadoop的版本较低，同时也不允许升级版本的话，可以选择第1种方案；如果版本较新（在0.21.0以上），第2种方案优于第1种；如果对HA切换时间有严格要求的话，则需要选择第3种方案。第1种方案比较简单，资料较多，本书将不再说明，后面着重讲述第2种和第3种方案。