Hadoop&Hbase 备份方案--AvatarNode
Hadoop&Hbase 备份方案
--AvatarNode
需求
实现namenode的双机热备，保证Hadoop&Hbase的高可用性（HA）。
方案描述
当主namenode所在服务器宕机的时候，其服务和数据可迅速，完整，无缝的迁移到备份namenode从而保证hadoop集群的高可用性，持续的向外提供服务。
测试环境
虚拟机5台（1G内存，40G硬盘，ubuntu操作系统，Hadoop-0.20.2）
hadoop1-virtual-machine1 10.10.11.250 AvatarNode(Primary)
hadoop2-virtual-machine5 10.10.11.152 AvatarDataNode
hadoop3-virtual-machine1 10.10.11.160 AvatarDataNode
hadoop4-virtual-machine5 10.10.11.184 AvatarDataNode
hadoop5-virtual-machine1 10.10.12.25 AvatarNode(Standby)
测试步骤
1．部署好Hadoop(AvatarNode部署详情见部署文档)集群环境，。
2．启动集群，此时AvatarNode(Primary)正常向外提供服务，AvatarNode(Standby)处于safemode状态，只可读，不可写。
3．存储数据，集群正常使用。
4．Kill掉AvatarNode(Primary)线程（模拟Primary节点宕机）。
5．升级AvatarNode(Standby)为Primary（切换时间很短只需几秒）。
6．集群正常服务，数据未丢失。
问题及可行性分析
1. 该方案可以实现AvatarNode(Primary)故障时与AvatarNode(Standby)的迅速切换，同时可以保证数据的完整性，切换过程中不会有数据丢失，称得上为真正意义上的热备。
2. 该方案虽然可以实现AvatarNode(Primary)与AvatarNode(Standby)的快速切换，但目前还不支持自动切换，可以借助于zookeeper的lease机制实现。同时由于Primary与Standby的转换只能是由Standby转换成Primary，并不支持由Primary降级为Standby，所以暂时不支持二次故障。也就是说由Standby升级为Primary的节点发生故障时，不支持切换。
3. 该方案必须借助于NFS实现AvatarNode(Primary)与AvatarNode(Standby)之间事务日志的共享，故存在NFS故障的问题。
4. 该方案AvatarDataNode并不使用VIP和AvatarNode通信，而是直接与Primary及Standby通信，故需要使用VIP漂移方案来屏蔽两个节点间切换过程中的IP变换问题，挂载Hbase时更需如此。